软件工程课后习题答案

软件工程课后习题答案

Chapter1

1.1)The definition for software presented in Section 1.2 applies to the Web sites. There are, however, subtle

differences between a Web site and conventional software. Among the most important are that the content that a Web site presents is considered to be part of the Web Application while that data processed by conventional software is often considered to be separate from the processing functions delivered.

1.4)Who would have thought that software would lead to: (1) a change in the dating habits of many young

people (Internet dating); (2) the way people communicate (cell phones); (3) methods of warfare (cyberweapons); (4) the diagnosis of diseases (MRIs and related computer-based diagnostic devices), and (5) the manner in which people acquire and enjoy media (music, DVDs, etc.).

1.6)The Law of Conservation of Familiarity: As the system evolves the users engineers, developers all those

associated must have the complete knowledge of the content and behavior to achieve satisfactory results.

Increase in growth may diminish that knowledge (mastery); hence the average increase in growth remains invariant as the system evolves.

1.7)Many modern applications change frequently before they are presented to the end user and then after the

first versions have been used. A few ways to build software to stop deterioration due to change would be: ?Make sure that software is designed so that changes in one part of a program do not create side-effects in another part of the program.

?Make sure that software is designed so that it does not depend on external devices or systems that are likely to change with time.

?Make sure test cases and results are archived and available so that the software can be retested when changes are made.

?Make sure you spend time understanding what the customer wants.

1.8)The two broadest categories encompass risks associated with economic loss and risks to the well being

of people. It might be a good idea to select five risks (culled from the sources noted) and present them to the class. Look for humorous as well as serious risks.

1.9)The same approach to software engineering can be applied for each of the six categories, but it must be

adapted to accommodate the special requirements of each category.

1.10)There are literally dozens of real life circumstances to choose from. For example, software errors that

have caused major telephone networks to fail, failures in avionics that have contributed to plane crashes, computer viruses (e.g., Michelangelo) that have caused significant economic losses and attacks on major e-commerce sites.

1.11)The Law of Declining Quality: The quality of systems will decline unless they are maintained by various

procedures to adapt to the environmental changes. This concept is similar to the “deterioration”

discussed in Problem 1-5.

1.12)The Law of Conservation of Organizational Stability: The average effective global activity rate is

invariant over the lifetime of a product.

Chapter 2

2.1)

2.2) Process assessment examines the software process used by an organization to determine whether it is

effective in achieving software engineering goals. The assessment characterizes the current practice

within an organizational unit in terms of the capability of the selected processes. The SPICE

(ISO/IEC15504) standard defines a set of requirements for software process assessment. To accomplish the assessment, SPICE specifies a “reference model” that examines the purpose and measurable

objectives of the proc ess (the “process dimension”) and the set of process attributes that should be

present (the “capability dimension”).

2.4) Task Set for Communication Activity: A task set would define the actual work to be done to accomplish

the objectives of a software engineering action. For the communication activity these are:

1.Make a list of stakeholders for the project

2.Invite all the stakeholders to an informal meeting

3.Ask them to make a list of features and functions

4.Discuss requirements and build a final list

5.Prioritize requirements and note the areas that stakeholders are uncertain of

These tasks may be expanded for a complex software project, they may then consider the following: ?To conduct a series of specification meetings, build a preliminary list of functions and features based on stakeholder input.

?To build a revised list of stake holder requirements use quality function deployment techniques to priotize the requirements.

?Note constraints and restrictions on the system.

?Discuss methods for validating system.

2.5) The CMMI represents a process metamodel in 2 different ways—the continuous and the staged model.

The pros of the CMMI: comprehensive, addressing virtually every aspect of process; well-organized;

adopted widely. The cons: voluminous; overkill for many types of projects; agility is questionable.

Although the spirit of the CMMI should always be adopted, each process must be adapted to meet the needs of the project team and to achieve high quality in the end product. The requirements of the CMMI should be applied to all process models, but failure to meet a specific criterion should not necessarily mean that the process is “bad.” It may be that the CMMI is right in situations in which an organizational culture is amendable to the standard process models and management is committed to making it a success. However it may be too much for an organization to successfully assimilate. This means that CMMI which is right for one company culture may not be right for another.

2.6) Process framework is applicable to all the projects; hence the same framework activities are applied for

all projects, regardless of the project’s size or complexity. A process framework involves heavy communication with the customer to gather requirements; this activity establishes a plan for the software engineering work that follows. It involves creation of models that will assist the developer and the customer to understand the requirements and design them; it thereby involves construction (code generation and error testing). It finally provides feedback based on the evaluation.

2.7) Umbrella activities occur throughout the software process but they are not necessarily applied evenly

across the process. For example, there is a heavy concentration on risk analysis during project planning, and risk analysis is then revisited during later framework activities, but it is not applied evenly during these activities. On theother hand, SQA is applied fairly evenly for all process activities.

2.8) The support phase is applied differently for embedded software. In most cases, embedded software is

defined and developed, but once it is placed in its host environment, it is not likely to change until a new release of the product occurs.

2.9)

a)Designers should ask users:

?What do you want this product to accomplish?

?What key outputs are produced by the software?

?What functions and features are you looking for?

?What outputs, functions and features are likely to change over the next 6 months, 1 year.

?Are there any questions that I should have asks that I didn’t?

?How will you determine if what we built is what you wanted?

b)Users should ask as designers:

?Have I made my needs clear to you?

?Do we have the tools and people with skills required for the development?

?Are the requirements properly defined, are additional requirements needed.

?Are the product features and functions achievable in the allotted time?

?Have you talked to other classes of users?

c)Users should ask themselves about the software product that is to be built:

?Have I asked for more than I’ll really need?

?Have I set deadlines that are unrealistic?

?Am I unsure of certain functions and features?

?Would a prototype be helpful for certain functions and features?

?Am I committed to work with the software designers over the long haul?

d)Designers should ask themselves about software product that is to be built and the process that will used

to build it:

?Do I understand the scope and purpose of the software?

?Do I understand the design issues and constraints?

?What tools are to be used?

?Do I understand the technology and business area that the software is to address?

?Have we established quality criteria that can be used to judge our work?

2.11) Scripts define specific process activities (i.e., project launch, design, implementation, integration and

system testing, postmortem) and other more detailed work functions (e.g., development planning, requirements development, software configuration management, and unit test) that are part of the team process. Scripts maybe beneficial when a team need guidance in planning and tracking its work, establishing goals, and defining effective task sets for technical activities. For experienced teams, however, the script may preclude “on-the-fly” adaptation that is often necessary in agile environments. 2.12) The Personal Software Process (PSP) emphasizes personal measurement of both the work product that

is produced and the resultant quality of the work product. The PSP process model defines five

framework activities: planning, high-level design, high-level design review, development, and

postmortem. In addition PSP makes the practitioner responsible for project planning (e.g.,

estimating and scheduling) and empowers the practitioner to control the quality of all software work

products that are developed.

Chapter 3

3.1) Any software project that has significant functionality that must be delivered in a very tight (too tight)

time frame is a candidate for the incremental approach. The idea is to deliver functionality in increments.

Example: a sophisticated software product that can be released to the marketplace with only partial functionality—new and improved versions to follow! For example, word-processing software developed using the incremental paradigm might deliver basic file management, editing and document production functions in the first increment; more sophisticated editing and document production capabilities in the second increment; spelling and grammar checking in the third increment, and advanced page layout capability in the fourth increment. The process flow for any increment may incorporate the prototyping paradigm. Incremental development is particularly useful when staffing is unavailable for a complete implementation by the business deadline that has been established for the project.

3.2) The waterfall model is appropriate for projects with the following characteristics: (1) the problem is well

understood (requirements are well-defined); (2) the delivery date is realistic; (3) it’s unlikely that major

changes in requirements will be requested as the project proceeds. Specific examples might be: (1) a well understood modification to an existing program; (2) a straightforward implementation of a numerical

calculation or business rule, even if it’s complex; (3) a constrained enhancement to an existing program.

3.3) If the plan is to have a prototype evolve into a delivered application, more rigorous design rules and

SQA procedures must be applied from the beginning. In addition, the prototype must be designed with

extensibility in mind and must be implemented using a programming environment that is amenable to

production system development. Initially, the prototype serves as a mechanism for identifying software

requirements. Once a working prototype is built, it becomes the skeleton (framework) for extensions that will cause it to evolve into a production system.

3.4) RAD assumes that a project can be modularized in a manner that allows major functionality to be

delivered within a 60 – 90 day time frame. Although this is often the case, there are situations in which

timelines are longer. In addition, RAD assumes that sufficient human resources will be available to

develop the increments in parallel. This may not be the case.

3.5) Software applications that are relatively easy to prototype almost always involve human-machine

interaction and/or heavy computer graphics. Other applications that are sometimes amenable to

prototyping are certain classes of mathematical algorithms, subset of command driven systems and other applications where results can be easily examined without real-time interaction. Applications that are

more difficult to prototype include control and process control functions, many classes of real-time

applications and embedded software.

3.6) The real question that a paper should address is: How do we develop a process that can accommodate

many of the chaotic attributes of modern software development? The authors suggest processes that are

“focused on flexibility and extensibility rather than on high quality” and admit that this approach is

“scary.” No doubt! In fact, I believe it is a recipe for disaster. With the exception of certain widely used

PC operating systems (that will remain nameless) quality does appear to be a reasonable harbinger of

successful software. A program that is “flexible and extensible” will not succeed if it fails regularly and

behaves unpredictably. It should be noted that much has been written about “good enough” software.

That’s OK as long as the word “good” is emphasized.

3.7) Process models can be combined. Each model suggests a somewhat different process flow, but all

perform the same set of generic framework activities: communication, planning, modeling,

construction, and deployment.

For example the linear sequential model can serve as a useful process model in situations where

requirements are fixed and work is to proceed to completion in a linear manner. In cases, where the

developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system,

or the form that human-machine interaction should take. In these, and many other situations, a

prototyping model may offer the best approach. In other cases, an incremental approach may make

sense and the flow of Spiral model may be efficient. Special process models take on many of the

characteristics of one or more of the tradition.

3.8) A software engineering workflow is distributed across all UP phases. In the context of UP, a workflow is

analogous to a task set. That is, a workflow identifies the tasks required to accomplish an important

software engineering action and the work products that are produced as a consequence of successfully

completing the tasks. UP workflow is conducted for every software project, whereas the five UP phases

do not necessarily occur in a sequence, but rather with staggered concurrency. It is likely in the UP that

at the same time the construction, transition, and production phases are being conducted, work may have already begun on the next software increment.

3.9) Stated simply, the concurrent process model assumes that different parts of a project will be different

stages of completeness, and therefore, different software engineering activities are all being performed concurrently. The challenge is to manage the concurrency and be able to assess the status of the project.

3.10) The advantages of developing a software in which quality is” good enough” is that the product or

software will meet the deadline, it may however lead to delivery of software that is low in quality and requires time to improve the quality. When speed is emphasized over the product quality, the process may lead to many flaws—the software may require more testing, design and implementation rework. 3.11) It is possible to use mathematical techniques to prove the correctness of software components and

even entire programs (see Chapter 28). However, for complex programs this is a very time

consuming process. It is not possible to prove the correctness of any non-trivial program using

exhaustive testing.

3.13) Customer required properties or areas of technical interest often span the entire software architecture.

When these properties, referred as “concerns,” cut across multiple system functions, features, and

information, they are often referred to as “crosscutting concerns.” Aspect-oriented software

development, often referred to as aspect-oriented programming (AOP), is a relatively new software

engineering paradigm that provides a process and methodological approach for defining, specifying,

designing, and constructing aspects—“mechanisms beyond subroutines and inheritance for

localizing the expression of a crosscutting concern.” a

3.14) UML provides the necessary technology to support object-oriented (and conventional) software

engineering practice, but it does not provide the process framework to guide project teams in their

application of the technology. The Unified Process is a framework for software engineering using

UML. Today, the Unified Process and UML are used on projects of all kinds. However, they are not

the same thing. UML is a modeling notation and language. UP is a process framework in which

UML may be applied as part of software engineering activities.

3.15) As work moves outward on the spiral, the product moves toward a more complete state and the level of

abstraction at which work is performed is reduced (i.e., implementation specific work accelerates as we move further from the origin).

Chapter 6

6.2) You might suggest the following systems: an airport, your university, an on-line bank, a retail store,

an e-commerce site. As an example consider a university:

University

Academic programs

Degree granting programs-undergraduate

Degree granting programs-undergraduate

Professional education

Continuing education

Administrative Departments

Registrar ….

Courses

Faculty

Infrastructure Maintenance …

6.4) The data architecture refers to corporate data, its organization, and the relationships between

individual corporate data elements. For example, a telephone billing system might draw on elements

that include customer information, rate tables, calling logs and so forth. Application architecture

defines the functional hierarchy that is required to realize the goals and objectives of a large

information system. Technology infrastructure identify the hardware and software backbone (e.g.,

client/server, operating system type) that enable the system to function.

6.5) There is less likelihood of miscommunication when the developer is the system engineer, but there is

high likelihood of "creeping enhancements" and the possibility of building a system that doesn’t meet

customer’s needs because perceptions of need are incorrect. When the customer is the system

engineer, the likelihood is that technical issues may be omitted, but it is likely that customer need will

be more accurately reflected. When an outside third party is the system engineer, communication

bandwidth between developer and customer must be very high. It’s likely that things will fall into the

cracks. However, the third party may be an expert, hence better overall quality of the system model.

The ideal system engineer is technically expert in system engineering, has full understanding of the

customer business/product domain, and understands the development environment (and leaps tall

buildings in a single bound!).

6.6) Consider the CLSS described in this chapter. Additional questions:

?What has been done to accomplish this task previously?

?Couldn’t sorting occur as the boxes were packed?

?Is the number of different parts (and boxes) likely to increase or decrease?

?Are all boxes the same size and weight?

?What is the environment in which this system will sit (e.g., corrosive, high temperature, dusty, etc.)? Allocations: (4) Bar code reader and PC. PC prints destination on screen and a human operator does the placement into the bin; (5) Human reads box and speaks destination into voice recognition system

that controls and automated shunt.

6.7) The assumptions, simplifications, limitations, constraints, and preferences are, of course, dependent

on the system that is chosen. In general, assumptions should be kept to a minimum, the higher the

number of assumptions, the higher the project risk; simplification are worthwhile, but only if they do not change the nature of system functions and features or the data that the system manipulates;

limitations are determined as part of requirements gathering and help to bound the system; constraints dictate the design approach, and preferences help to guide design alternatives that are chosen.

6.9) Use a large dictionary or thesaurus. Common synonyms: scheme, organization, classification,

structure, organism, None are really on the mark.

6.10) There are many cases where complete specification is impossible early in a project. In some of

these, it is necessary to prototype before a formal specification can be developed. Examples are:

?Sophisticated analytical models that must be researched and developed—delay until requirements specification or even design!

?Sometimes, specific hardware/software interfaces—delay until requirements, but no later!

?Certain performance constraints—delay until requirements, but no later!

6.11) The SCD represents how information flows from external sources (entities) into the system itself

and then outward to external sinks (entities). Entities within each of the five functional areas

represented as part of the SCD (Figure 6.4) should be represented.

6.12) In many instances a computer-based system is actually a "software only" system. That is, an

existing standard computer, operating system and I/O environment are to be used. In such cases, the

System Specification can be eliminated in lieu of a Software Requirements Specification. There are

also situations in which a system prototype (either real or paper) is much more effective than a

specification.

Chapter 7

7.2) In reality, the customer and the developer enter into a process of negotiation, where the customer

may be asked to balance functionality, performance, and other product or system characteristics

against cost and time to market. The intent of this negotiation is to develop a project plan that meets

the needs of the customer while at the same time reflecting the real-world constraints (e.g., time,

people, budget) that have been placed on the software team, Unfortunately, each customer has his

own priorities and views. These views are not necessarily consistent.

7.3) Feasibility analysis within the context of the inception function is to identify a working description

of the project’s scope and then assess whether the scope can be achieved within the context of

management and technical constraints. In essence, feasibility analysis (during inception) defines a

business case for an idea and identifies the breadth and depth of the market that the product is to

address.

7.4) You might try using an approach like QFD that makes use customer interviews and observation,

surveys, and examination of historical data (e.g., problem reports) as raw data for the requirements

gathering activity. These data are then translated into a table of requirements—called the customer

voice table—that is reviewed with the customers later. A variety of diagrams, matrices, and

evaluation methods are then used to extract expected requirements.

However, if the customer refuses to work with you, it’s time to get both your management and the customer’s management involved. If they don’t have the time to help define the software, they probably won’t

have the inclination to use it.

7.5) Software engineers want to begin building something, so they sometimes give requirements

analysis short shrift. In addition, understanding the requirements of a problem is among the most

difficult tasks that a software engineer face since requirements change, are sometime contradictory

and are often difficult to enunciate clearly. Hence, software engineers want to get through the

requirements engineering activity and get on with the “real engineering work.” A mistake!

In situations in which the problem is relatively small and reasonably well understood, an abbreviated approach may be chosen. For more complex problems with many requirements, every task defined

for comprehensive requirements engineering should be performed rigorously. Requirements

engineering builds a bridge to design and construction and cannot be skipped.

7.6) Guidelines should be consistent with information presented in Section 7.4 and should stress

establish a collaborative atmosphere. To summarize:

?meetings are conducted and attended by both software engineers and customers.

?rules for preparation and participation are established.

?an agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free flow of ideas.

? a "facilitator" (can be a customer, a developer, or an outsider) controls the meeting.

? a "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used.

?the goal is to identify the problem, propose elements of the solution, negotiate different approaches, and specify a preliminary set of solution requirements in an atmosphere that is conducive to the

accomplishment of the goal.

7.7) The first set of context-free questions focuses on the customer and other stakeholders, the overall goals,

and the benefits. For example, the requirement engineer might also ask:

?Who is paying for this work?

?What is the name of a contact person in each customer group?

?Do you know of any other business that has solved this problem successfully?

7.8) The best negotiations strive for a “win-win” result, therefore, if the customer feels he has won,

that does make you a master negotiator. If the customer feel duped or forced into agreement, it’s

unlikely that a collaborative atmosphere will be established. The project will suffer as a result.

7.10) The customer for information systems is often another department in the same company—often

referred to as the "user department." The customer for computer-based products is typically the

marketing department! The customer for computer-based systems may be an internal department,

marketing or an outside entity (e.g., a government agency, another company, an end-user).

7.11) The intent of the analysis model is to provide a description of the required information, functional,

and behavioral domains for a computer-based system. The model changes dynamically as software

engineers learn more about the system to be built, and stakeholders understand more about what

they really require. For that reason, the analysis model is a snapshot of requirements at any given

time.

7.12) First, the nature of the error is determined. If it is an omission, additional information must be added.

If the error is due to ambiguity, the customer and developer must work to clarify matters. If the

error is due to inconsistency, a more consistent presentation is developed; if the error is due to a bad

interpretation of customer need, further discussion with the customer are warranted.

7.14) Anyone who has done requirements engineering on more than a few software projects begins to

notice that certain things reoccur across all projects within a specific application domain. These

can be called “analysis patterns” and represent something (e.g., a class, a function, a behavior)

within the application domain that can be reused when modeling many applications.

7.15) Extensions provide an indication of how the scenario reacts when things go awry (e.g., bad data are

input) or when a specific action (not described in the body of the use-case) is taken.

7.16) A “Win-Win situation is one in which the customer wins by getting the system or product that

satisfies the majority of the customer’s needs and the software team wins by working to realistic

and achievable budgets and deadlines.

7.17) The specific elements of the analysis model are dictated by the analysis modeling method that is to

be used; however the four elements of an analysis model are:

?Scenario-based elements. The system is described from the user’s point of view using a scenario-based approach.

?Class-based elements. Ea ch usage scenario implies a set of “objects” that are manipulated as an actor interacts with the system. These objects are categorized into classes—a collection of things

that have similar attributes and common behaviors.

?Behavioral elements. The behavior of a computer-based system can have a profound effect on the design that is chosen and the implementation approach that is applied. Therefore, the analysis

model must provide modeling elements that depict behavior.

?Flow-oriented elements. Information is transformed as it flows through a computer-based system.

The system accepts input in a variety of forms; applies functions to transform it; and produces

output in a variety of forms.

Chapter 8

8.1) Structured analysis begins with a consideration of the data objects that the system must manipulate.

In structured analysis the data objects are described with a data dictionary and the entity relation

diagram (ERD) depicts relationships between data objects. The flow and transformation of data

through a system are represented using the data fow diagram (DFD). The structured analysis also

incorporates a behavioral modeling notation called the state transition diagram (STD). In the object

oriented analysis model, class-based elements model the objects that the system will manipulate, the operations that will be applied to the objects to effect the manipulation, relationships (some

hierarchical) between the objects, and the collaborations that occur between the classes that are

defined. In addition the OO model represents the behavior of objects and the behavior of the system as a whole.

8.2) It is possible to develop an effective analysis model without developing all four elements shown in

Figure 8-3. However, each element presents a different view of the problem to be solved, and

therefore provides the ability to see potential problems, inconsistencies or omissions more clearly.

In addition, if all four elements of the analysis model are developed, the transition to design is

simplified.

8-3) The analysis model will serve as the basis for design and construction of the domain objects. It is possible to begin coding after the objects and attributes are defined, and relationships are known.

However, the design will suffer as a result because explicit architectural design will not have been

considered; interfaces will have been developed in a haphazard manner, and global data structures

will not have been explicitly designed.

8.4) Domain analysis is an on-going software engineering activity that is not connected to any one

software project. The intent is to find analysis patterns that are widely used within a specific

application domain and to identify a set of objects and classes that characterize the domain.

8.5) Many infrastructure requirements are not visible in the problem or business domain. For example,

what functions are required to manage global data, what functions are required to implement

network communication; what functions are required to implement a user interface.

8.6) Be certain to emphasize the fact that all data-objects and relationships MUST be customer visible.

Attributes should be reviewed to be certain that they properly reflect the requirements of the

system.

8.7) At the context level, be certain to show external entities, major input and output data objects and an

major data store (e.g., a database) that is externally visible to users of the system.

8.8) The various elements of the analysis model (e.g., use-cases, analysis classes) are categorized in a

manner that packages them as a grouping—called an analysis package. To illustrate the use of

analysis packages, consider the video game discusses briefly in this chapter. As the analysis model

for the video game is developed, a large number of classes are derived. These can be grouped as a

series of packages.

8.9) The CSPEC should focus on the behavioral aspects of the system. First, you must identify the

events that cause the system to behave in a specific manner. Next, you’ll have to represent the

manner in which event are handled (the CSPEC). PSPECs are developed for every bubble at the

lowest level of the DFDs. The PSPEC should describe the processing performed by the bubble

(transform). Be sure to emphasize the importance of a hierarchical approach to function partitioning when functions are defined.

8.10) You might approach the problem using the grammatical parse described in this chapter. The

following data objects should be identified for PHTRS:

?Pothole data

o Identifying number

o Street address

o Size

o Location in street

o District

o Repair priority

?Work order data:

o Pothole location

o Size

o Repair crew ID number

o Number of people in crew

o Equipment assigned

o Hours applied

o Hole status

o Amount of filler used

o Cost of repair

o Damage data

?Tracking data:

o Citizen’s name

o Citizen’s address

o Citizens phone number

o Type of damage

o Dollar claim

This problem is amenable to data flow and object-oriented analysis approaches.

8.11) Encapsulation: Packaging an object’s variables within the protective custody of its methods is

called encapsulation. It is used to hide unimportant implementation details from other objects.

Inheritance can be explained as: A subclass Z inherits all of the attributes and operations associated

with its super class, (or parent) Y. This means that all data structures and algorithms originally

designed and implemented for Y are immediately available for Z.

8.12) Be certain the information flow continuity is maintained from level to level; that the level of

abstraction for bubbles within the DFD (at a specific level) is consistent; and that the grammatical

parse focuses on meaningful data objects and transformations.

8.13) The state diagrams presented that depict the state behavior of a system represent externally

observable events and states.. State diagrams for analysis classes are a component of the behavioral

model and represent the states associated with a specific analysis class. See Figure 8.20 as an

example.

8.14) Using the general text-based description of the PHTRS system, parse the description to isolate

candidate classes. Apply the criteria noted in Section 8.7.1 to define actual classes from the

candidates; specify attributes for each class; define operations for the class. For example, classes

defined for the PHTRS system might be: Citizen, PotHole, and WorkOrder. The attributes for

PotHole might be location, size, repairCrewID, crewSize, equipmentAssigned, hoursApplied, status,

fillerUsed, and repairCost. Operations for PotHole might be: assignCrew, defineStatus, selectSize,

specifyLocation, …

8.17) In many instances, two analysis classes are related to one another in some fashion, much like two

data objects may be related to one another. In UML these relationships are called associations. In

many instances, a client-server relationship exists between two analysis classes. In such cases, a

client-class depends on the server-class in some way and a dependency relationship is established.

8.18) First, develop an general text-based description of the PHTRS system. Parse the description to

isolate functions and features. Write an information narrative use case for each interactive function.

Now, develop a UML use-case diagram (similar in structure for the one shown in Figure 8.6) that

depicts each of the use-cases for PHTRS.

Chapter 9

9.1) The intent of software design is to apply a set of principles, concepts, and practices that lead to the

development of a high quality system or product. The goal of design is to create a model of

software that will implement all customer requirements correctly and bring delight to those who use

it.

9.2) Yes, but the design is conducted implicitly — often in a haphazard manner. During design (in a

software engineering context) we develop representations (models) of programs—not the programs

themselves.

9.3) Software Architecture is the structure or organization of program components (modules), the manner in

which these components interact, and the structure of data that are used by the components. In a broader sense, however, components can be generalized to represent major system elements and their

interactions.

9.5) CreditCard → validate; check-limit; charge-against EngineeringDrawing →scale; draw; revise

WebSite →add-page; access; add-graphic

9.6) We create a functional hierarchy and as a result refine the problem. For example, considering the

check writer, we might write:

?Refinement 1: Write dollar amount in words

?Refinement 2: Procedure write amount;Validate amount is within bounds;Parse to determine each dollar unit;Generate alpha representation; end write_amount

?Refinement 3:

o procedure write_amount;

?do while checks remain to be printed

?if dollar amount > upper amount bound

?then print "amount too large error message;

?else set process flag true;

?endif;

?determine maximum significant digit;

?do while (process flag true and significant digits remain)

?set for corresponded alpha phrase;

?divide to determine whole number value;

?concatenate partial alpha string;

?reduce significant digit count by one;

?enddo

?print alpha string;

?enddo

o end write_amount

9.7) In some time-critical applications, monolithic implementation may be required. However, design

can and should occur as if the software was to be implemented modularly. Then "modules" are

coded in-line.

9.8) As an example, we consider an IntermittentWindshieldWiper capability in an automobile:

Pattern name— IntermittentWindshieldWiper

Intent—allows the driver to cause the windshield wipers to operate intermittently, with intermittent timing defined using a time-setting device such as a ring-dial on the wiper control arm.

Also-known-as—TimedWipers, WiperControl

Motivation—there are many situations in which precipitation is significant enough to warrant removal from the windshield, but not heavy enough to warrant continuous wiper operation.

Applicability—integrated into all luxury automobiles and other automobiles that provide the feature as an option

Structure—WiperControlArm, Timer, WiperActuator

Participants—WiperControlArm: turnOn, turnoff, setWiperSpeed, setTimingLevel

Collaborations— WiperControlArm defines the attributes of the controls that are used by the driver;

Timer implements a clocking function that collaborates with the timing controlset using

WiperControlArm; WiperActuator sends control signals to the servomechanism the controls

the wiper motor.

Consequences—the primary “design force” is the number of wiper timing levels and/or whether the timing level can be set on a continuous scale

Related patterns—none

9.9) Information hiding can be related to both coupling and cohesion concepts. By limiting the

availability of information to only those modules that have absolute need, coupling between

modules is inherently reduced. In general, isolation of information predicates isolation of function;

therefore, cohesion of individual modules can also be improved

9.10) There are cases in which different parts of a problem are interrelated in a manner that makes

separate considerations more complex than combined considerations. Highly coupled problems

exhibit this characteristic. However, continuing combination of problem parts cannot go on

indefinitely because the amount of information exceeds one's ability to understand. Therefore, when (9-2) is not true, modularity may still exist, but the problem is better understood by considering it

monolithically.

9.11) External world, compiler, and operating system coupling will affect software portability adversely.

As an example, consider a program that has been designed to make use of special graphics features of an intelligent display. If the software is moved to a system without this type of display, major

design and code modifications may be required.

9.12) To develop a complete design model, the software team develops each element of the model

iteratively. Each iteration provides additional detail and refinement. Quality is assessed for each

element of the design model—data design, architecture, user interface, and component-level

design_after tasks associated with the creation of these work products have been completed.

9.14) Quality is assessed by conducting a series of formal technical reviews (FTRs) and then assessing

the design against a set of quality criteria that have been pre-established. A FTR is a meeting

conducted by members of the software team. Usually 2, 3 or 4 people participate depending on the

scope of the design information to be reviewed. Each person plays a role: the review leader plans

the meeting, sets an agenda, and the runs the meeting; the recorder takes notes so that nothing is

missed, the producer is the person whose work product (e.g., the design of a software component) is being reviewed. At the end the team decides future action to the design.

Chapter 10

10.3) A data warehouse is a global repository for information gathered from many corporate sources

(databases). A database is generally a single data store that addressed a specific set of information

needs within a business

10.5) Hierarchical: dataflow, call return, layer

Non-hierarchical: data centered, object-oriented

Non-hierarchical architectures are probably best implemented using object-oriented and event

driven programming techniques.

10.6) A compete design of the PHTRS system can be accomplished the architectural design model

elements discussed in this chapter, Because the application is driven by the data architecture that is

chosen, you should begin with a detailed data design. Following that, design classes and related

architectural information should be represented.

10.9) When transform mapping is used where transaction mapping should be used, two problems arise: (1)

the program structure tends to become top heavy with control modules—these should be eliminated;

(2) significant data coupling occurs because information associated with one of many "processing

actions" must be passed to an outgoing path. Classic examples include: many engineering analysis

algorithms, many process control applications, some commercial applications. Look for a

well-developed DFD and correct mapping to program structure.

10.10) Many people define architectural style and architectural pattern as being one in the same (a general

system model used as the starting point for system design). A framework might be defined by some

people as a set of classes providing a general solution to a problem that can be refined to create an

application or subsystem.

10.11) Data centered architecture: airline reservation system; library catalog system; hotel booking system

Data flow architecture: any engineering/scientific application where computation is the major

function

Call and return architecture: any I-P-O application

Object-oriented architectures: GUI-based applications; any OO application

Layered architecture: any application in which the application functions must be decoupled from

the underlying OS or network detail. Client server software is often layered.

10.12) The concepts of styles and patterns occur for buildings and software at both macroscopic and

microscopic levels. For example, overall styles (center-hall colonial, A-frame) can be found in a

house. These represent macroscopic styles. Lower-level microscopic patterns (for a house) can be

found in categories of wood molding, fireplace designs, windows, etc.

Chapter 11

11.1) Guard-condition is written in Object Constraint Language (OCL) and specifies a condition that must be

met before the event can occur, and action expression defines an action that occurs as the transition takes place.

11.2) Like object-oriented components, traditional software components are derived from the analysis model.

In this case, however, the data flow-oriented element of the analysis model serves as the basis for the

derivation. Each transform (bubble) represented at the lowest levels of the data flow diagram is mapped (Section 10.6) into a module hierarchy. Control components (modules) reside near the top of the

hierarchy (architecture) and problem domain components tend to reside toward the bottom of the

hierarchy. To achieve effective modularity, design concepts like functional independence are applied as components are elaborated.

11.3) The Open-Closed Principle (OCP) states module [component] should be open for extension but closed

for modification. The designer creates the designer should specify the component in a way that allows it to be extended (within the functional domain that it addresses) without the need to make internal (code

abstractions that serve as a buffer between the functionality that is likely to be extended and the design

class itself.

11.4) External coupling occurs when a component communicates or collaborates with infrastructure

components (e.g., operation system functions, database capability, telecommunication functions).

Although this type of coupling is necessary, it should be limited to a small number of components or

classes within a system. Software must communicate internally and externally. Therefore, coupling is a

fact of life. However, the designer should work to reduce coupling whenever possible and understand the ramifications of high coupling when it cannot be avoided.

11.5) Dependency Inversion Principle (DIP) states, depend on abstractions. Do not depend on concretions. The

more a component depends on other concrete components (rather than on abstractions such as an

interface), the more difficult it will be to extend.

11.6) Within the context of component-level design for object-oriented systems, cohesion implies that a

component or class encapsulates only attributes and operations that are closely related to one another and to the class or component itself. Components that highly cohesive are insulated from relying on services provided by other components will make their implementation and maintenance of easier.

11.7) Coupling is a qualitative measure of the degree to which classes are connected to one another. As classes

(and components) become more interdependent, coupling increases. A benefit of low coupling if the ease among components is the ease with which components can be modified without affected the behavior of other components.

11.8) Some possibilities for infrastructure components might be user interface classes, data storage subsystem,

physics engine in a video game, etc.

11.9) Component-level design defines the data structures, algorithms, interface characteristics, and

communication mechanisms allocated to each software component. In object-oriented languages (e.g.

Java or Smalltalk) components are classes or objects. In traditional languages (e.g. C or Fortran)

components are functions or procedures. In mixed languages like C++ components might be either

functions or classes.

11.10) Public attributes are data that are visible and accessible to all other components, private attributes are

only visible and accessible within the component in which they are defined. They are used to enforce

data encapsulation and information hiding.

11.12) Databases and files normally transcend the design description of an individual component. In most cases,

these persistent data stores are initially specified as part of architectural design. However, as design

elaboration proceeds, it is often useful to provide additional detail about the structure and organization of these persistent data sources. The term persistent means that the data exist before the application is

executed and after it has terminated execution.

11.13) Factoring is the process of distributing the control a decision-making of the system so that the top-level

modules perform control functions and the low-level modules perform all input, processing, and output

work. In stepwise refinement a program is developed by successively refining levels of procedural detail.

For traditional software development they are very similar.

11.16) To conduct component-level design in this context, classes are elaborated by specifying messaging

details, identifying appropriate interfaces, elaborating attributes and defining data structures to

implement them, describing processing flow within each operation, and representing behavior at a class

or component level. In every case, design iteration (refactoring) is an essential activity.

Chapter 12

12.1) When response time is unpredictable, the user becomes impatient and re-attempts the command

requested or tries another command. In some cases, this can create queuing problems (for commands)

and in extreme cases, cause loss of data or even a system failure. Research has shown that users can

tolerate up to 50% variation in response rates for applications they are familiar with. For unfamiliar

applications users become anxious after 15-30 second unexpected delays (the half-life of their short term memory).

12.2) Examples might be:

?If the user desires, display shortcut command sequences on the screen at all times.

?Provide the facilities for "hints" when a WebApp requires password input

12.3) Answers will vary; typical questions to be added:

?Where are audio prompts used and for what purpose?

?Are content object generated dynamically?

?Are there constraints on the placement of graphical objects?

?Are there screen size limitations that dictate placement of content?

?Is there a mechanism for magnification of screen content?

12.4) Examples might be:

?Use color consistently, e.g., red for warning messages, blue for informational content.

?Provide keyword driven on-line help.

12.7) Examples might be:

?Catch potential interaction errors before they do "undoable" damage.

?Allow the user to customize screen layout as well as commands.

?Make use of breakaway menus so that common functions are always readily available.

Chapter 13

13.1) The most common problem in the creation of an ITG is getting and keeping good people. In addition,

hostility between the ITG and the software engineering group can arise if the interaction between groups is not properly managed. Finally, the ITG may get involved in a project too late—when time is short and

a thorough jo

b of test planning and execution cannot be accomplished. An ITG and an SQA group are

not necessarily the same. The ITG focuses solely on testing, while the SQA group considers all aspects

of quality assurance.

13.2) Verification focuses on the correctness of a program by attempting to find errors in function or

performance. Validation focuses on "conformance to requirements—a fundamental characteristic of

quality.

13.3) A highly coupled module interacts with other modules, data and other system elements. Therefore its

function is often dependent of the operation of those coupled elements. In order to thoroughly unit test

such a module, the function of the coupled elements must be simulated in some manner. This can be

difficult and time consuming.

13.4) Developer, if customer acceptance test is planned. Both developer and customer (user) if no further tests

are contemplated. An independent test group is probably the best alternative here, but it isn’t one of the

choices.

13.5) It is not always possible to conduct thorough unit testing in that the complexity of a test environment to

accomplish unit testing (i.e., complicated drivers and stubs) may not justify the benefit. Integration

testing is complicated by the scheduled availability of unit-tested modules (especially when such

modules fall behind schedule). In many cases (especially for embedded systems) validation testing for

software cannot be adequately conducted outside of the target hardware configuration. Therefore,

validation and system testing are combined.

13.7) The availability of completed modules can affect the order and strategy for integration. Project status

must be known so that integration planning can be accomplished successfully.

13.8) A single rule covers a multitude of situations: All data moving across software interfaces (both external

and internal) should be validated (if possible).

Advantages: Errors don't "snowball."

Disadvantages: Does require extra processing time and memory (usually a small price to pay).

13.10) No. If a module has 3 or 4 subordinates that supply data essential to a meaningful evaluation of the

module, it may not be possible to conduct a unit test without "clustering" all of the modules as a unit.

Chapter 14

14.2) For specific input, an error occurs internally resulting in:

1) Improper data placed in a global data area;

2) Improper flags that will be tested in a subsequent series of tests;

3) Improper hardware control that can only be uncovered during system test; yet "correct" output is produced.

14.5) Because each subclass of a given class is applied within the context of private attributes and operations

(and the fact that these private attributes and operations) can add complexity), subclasses must be

retested in their operational context. Test cases can be reused, but it is important to extend them to

address the private attributes and operations of the subclass.

14.6) In addition to those objectives:

a) A successful test demonstrates compliance with function and performance;

b) A successful test uncovers documentation errors;

c) A successful test uncovers interfacing problems;

d) A successful test demonstrates an understanding of program architecture, data structure, interface design

and procedural design;

e) A successful test establishes an entry into a test case database that may later be used for regression testing.

14.10) No, even an exhaustive test (if it were possible) may be unable to uncover performance problems and

errors in the specification of the software. In this case both input and output "equivalence classes" are

considered. For each class, the student should identify boundaries based on numeric ranges, elements of

a set, system commands, etc. This can be a paper exercise in which test cases for a GUI for some well

know application are derived.

14.11) The class encapsulates data and the operations that manipulate the data. Since these are packaged as a

unit, testing just the methods one-by-one would be sterile and would not uncover errors associated with

messaging, responsibilities and collaborations.

Chapter 16

16.1) The key here is to recognize that "content" spans a wide array of media including text, graphics,

animation, audio, and video. Even within a specific media type (e.g., video), we encounter many

different formats and presentation modes.

16.4) In addition to the attributes noted at the beginning of this chapter, WebApps have the following

specialized characteristics:

Customizable - each user is often given the opportunity of customizing the information presented to his/her won needs Dependent (interoperable) – the content of the WebApp may be dependent of the content of other WebApps (e.g., hot links to other Web sites) that are not under the control of the WebApp developer

Responsive – users can "comment" on the WebApp in real-time and expect a timely response to their query/comments.

16.5) The principle that would work well for a two-year e-Project (involving dozens of people) that will build

a major e-Commerce system for an automobile company would be: Continuous attention to technical

excellence and good design enhances agility. This is the basis of many good engineering practices. The

metrics of technical excellence and good design are not stated, leaving them open to interpretation.

The principle that would work well for a two month e-Project that will build an informational site for a small real estate firm would be: Business people and developers must work together daily throughout the project.

This is common business practice in successful organizations. The definition of the customer is

restrictive in many of the agile process methods, especially when building products rather than projects.

The granularity of the interaction is the issue. If the customer is co–located, direct daily interaction is

possible. If not, then some other form of communication is necessary. Documentation then plays a more significant role.

16.6) Answers will vary but several important risks that should be considered during the development of a new

e-commerce application designed to sell mobile phones and service directly over the Web would be:

?Are users be willing to purchases mobile phones and services over the Web?

?What will happen if the database used to support the WebApp fails during operation?

?Does the project team possess the technical skills needed to implement the application?

?Does the company have the user support staff needed to assist user who have problems using the system to order mobile phones and services?

?Will the web site be able to handle the projected user load?

?Are users subject abnormal privacy violation risks as a result of using this system?

?What aspects of the site have the highest security risks?

16.7) WebE process models (discussed in detail in section 16.3) embrace the agile development philosophy

(Chapter 4). Agile development emphasizes a lean development approach that incorporates rapid

development cycles. Even when rapid cycle times dominate development thinking, it is important to

recognize that the problem to be solved must still be analyzed, a design should be developed,

implementation should proceed in an incremental fashion, and an organized testing approach must be

initiated. However, these framework activities must be defined within a process that (1) embraces

change; (2) encourages the creativity and independence of development staff and strong interaction with WebApp stakeholders; (3) builds systems using small development teams, and (4) emphasizes

evolutionary or incremental development using short development cycles.

Chapter 18

18.1) Answers will vary, but the gist your answer may be that requirements will change constantly and it will

be impossible to solidify the analysis model. However, the argument does not apply in all situations. If

the WebApp is large, has lots of users, or is critical to the business case of the customer then analysis

modeling is essential to ensure the quality of the resulting WebApp (no matter how tight the delivery

schedule).

18.2) Analysis modeling focuses on four fundamental aspects of the problem: content, interaction, function,

and configuration. Content analysis identifies content classes and collaborations (UML class diagrams).

Interaction analysis describes basic elements of user interaction, navigation and the system behaviors

that occur as a consequence (UML use-case diagrams, sequence diagrams, and state diagrams). Function analysis defines the WebApp functions that are performed for the user and the sequence of processing

that occurs as a consequence (UML activity diagrams). Configuration analysis identifies the operational environment(s) in which the WebApp is to reside (UML deployment diagrams). The analysis of a

potential Web application focuses on three important questions: (1) what information or content is to be presented or manipulated; (2) what functions are to be performed for the end-user, and (3) what

behaviors will the WebApp exhibit as it presents content and performs functions? The answers to these

questions are represented as part of any analysis model.

18.3) Answers will vary. For a book seller, user categories might be: a book browser, a new book buyer, a

used book buyer, a new customer, an existing customer, a customer who need support, a gift buyer, etc.

18.4) Use-cases are developed for each user category described in the user hierarchy. In the context of Web

engineering, the use-case itself is relatively informal - a narrative paragraph that describes a specific

interaction between a user and the WebApp. Packages are sets of functions needed to be implemented

for each use-case to accommodate each category of users.

18.5) Comprehensible - all stakeholders understand the purpose of the package

Cohesive - the package addresses functions that are closely related to one another

Loosely coupled - functions or classes within the package collaborate with one another, but collaboration outside the package are kept to a minimum.

Hierarchically shallow - deep functional hierarchies are difficult to navigate and hard for end-users to

understand; therefore, the number of levels within a use-case hierarchy should be minimized whenever 18.9) Typical issues: change the way major functions are selected; change the layout of the home page. Chapter 19

19.6) The architectural designer must identify content architecture and WebApp architecture. Content architecture focuses on the manner in which content objects (or composite objects such as Web pages) are structured for presentation and navigation. WebApp architecture addresses the manner in which the

application is structured to manage user interaction, handle internal processing tasks, effect navigation, and present content.

19.7) The most important of quality attributes for WebApps are usability, functionality, reliability, efficiency, and maintainability. This provides a useful basis for assessing the quality of Web-based systems. These are largely the same quality attributes that are important for every computing application. User will not use application that is hard to use, if an alternative is available. Users are primarily interested in applications that meet their functional expectations. People would prefer to use software that is reliable and efficient. Software engineers can make better use of their work time, if software is easy to maintain.

19.9) Some additional questions to the WebApp Design—Quality Checklist presented in Section 19.1.1 would be:

?Is it easy to navigate the site and to determine where one is at any time?

?Is the content of every page cohesive—that is, does all content on a page have an obvious relationship to other content on the page. Is it easy to determine what the relationship is?

?C an the scope and depth of content be easily determined to ensure that it meets the user’s needs?

?Can the background and authority of the content’s authors be easily identified?

?Is it possible to determine the currency of the content, the last update and what was updated?

?Are the content and its location stable (i.e., will it remain at the referenced URL?)?

19.10) Aesthetic design, also called graphic design, describes the “look and feel” of the WebApp and includes color schemes, geometric layout, text size, font and placement, the use of graphics and related aesthetic decisions. A set of graphic design guidelines provide the basis for a design approach. However, usability and not appearance is what bring most users back a web site. The appropriate mix of aesthetics, content, and technology will vary depending upon the nature of the WebApp, and as a consequence the design activities that are emphasized will also vary. Occasionally, a web site may be designed for entertainment only. In this case aesthetic design might be the dominant philosophy to follow.

19.11) A class named Order would be developed. The class would likely be an aggregation that would incorporate identifying information about the customer (a Customer class. Reference to a list of SafeHome components that have been ordered ( a BoM class), pricing information (a Pricing class or attributes within a BoM class) and other similar information. A set of operations might include placeOrder(), verifyOrder(), processPayment(), shipOrder().

19.13) Answers may vary, but in general the students argue in favor of using MVC. The

Model-View-Controller (MVC) architecture is one of a number of suggested WebApp infrastructure models that decouples the user interface from the WebApp functionality and informational content. The model (sometimes referred to as the “model object”) contains all application specific content and processing logic, including all content objects, access to external data/information sources, and all processing functionality that are application specific.

19.14) Navigation design represents the navigational flow between content objects and for all WebApp functions. Navigation semantics are defined by describing a set of navigation semantic units. Each unit is composed of ways of navigations and navigational links and nodes. Navigation syntax depicts the mechanisms used for effecting the navigation described as part of the semantics.

19.16) Answer will vary. To illustrate the development of an NSU, consider the use-case, select SafeHome components,

Use-case: select SafeHome components

The WebApp will recommend product components (e.g., control panels, sensors, cameras) and other features (e.g., PC-based functionality implemented in software) for each room and exterior entrance. If I request alternatives, the WebApp will provide them, if they exist. I will be able to get descriptive and pricing information for each product component. The WebApp will create and display a bill-of-materials as I select various components. I’ll be able to give the bill-of-materials a name and save it for future reference (see

use-case: save configuration).

The underlined items in the use-case description represent classes and content objects that will be incorporated into one or more NSUs that will enable a new customer to perform the scenario described in the select SafeHome components use-case.

软件工程概论课后答案解析

第1章软件与软件工程的概念 1、1 举出您所知道的应用软件的例子。 办公软件、游戏软件、财务软件、银行软件、人事管理软件、工资管理软件、学籍管理软件等。 1、2 认为“软件就就是程序,软件开发就就是编程序。”这种观点就是否正确？为什么？ 认为“软件就就是程序,软件开发就就是编程序。”这种观点就是错误的。 首先,软件就是计算机系统中与硬件相互依存的另一部分,它就是包括程序,数据及其相关文档的完整集合,程序只就是软件的组成部分之一;其次,在软件开发中,编程只就是软件开发过程的一个阶段。 1、3 如果将软件开发比作高楼大厦的建造,可以将软件的设计比作什么？ 可以将软件的设计比作建筑设计,软件设计的成果相当于建筑设计的设计图纸。 1、4 什么就是软件危机？它有哪些典型表现？为什么会出现软件危机？ 软件危机:软件危机就是指在计算机软件的开发与维护过程中所遇到的一系列严重问题。 典型表现: (1)对软件开发成本与进度的估计常常很不准确。 (2)用户对“已完成的”软件系统不满意的现象经常发生。 (3)软件产品的质量往往靠不住。 (4)软件常常就是不可维护的。 (5)软件通常没有适当的文档资料。 (6)软件成本在计算机系统总成本中所占的比例逐年上升。 (7)软件开发生产率提高的速度,既跟不上硬件的发展速度,也远远跟不上计算机应用迅 速普及深入的趋势。 产生软件危机的原因:除了软件本身的特点,其原因主要有以下几个方面: (1) 缺乏软件开发的经验与有关软件开发数据的积累,使得开发工作计划很难制定。 (2) 软件人员与用户的交流存在障碍,使得获取的需求不充分或存在错误。 (3) 软件开发过程不规范。如,没有真正了解用户的需求就开始编程序。 (4) 随着软件规模的增大,其复杂性往往会呈指数级升高。需要很多人分工协作,不仅涉及技 术问题,更重要的就是必须有科学严格的管理。 (5) 缺少有效的软件评测手段,提交给用户的软件的质量不能完全保证。

软件工程课后习题参考答案

1.简述软件开发的本质。 答:软件开发的本质就是实现问题空间的概念和处理逻辑到解空间的概念和处理逻辑之间的映射。P19 2.简述实施软件开发的基本途径。 答:实施软件开发的基本途径是系统建模。所谓系统建模，是指运用所掌握的知识，通过抽象，给出该系统的一个结构——系统模型。P19 3.简述何谓模型以及软件开发中所涉及的模型。 答:模型是一个抽象。该抽象是在意图所确定的角度和抽象层次对物理系统的一个描述，描述其中的成分和成分之间所具有的特定语义的关系，还包括对该系统边界的描述。 软件开发中所涉及的模型可分为两大类，一类称为概念模型，描述了系统是什么；另一类统称为软件模型，描述了实现概念模型的软件解决方案。 4.简述软件开发所涉及的两大类技术。 答:软件开发所涉及的两大类技术为:一是求解软件的开发逻辑，二是求解软件的开发手段。 5、简述需求与需求规约的基本性质。 答:需求的基本性质:1) 必要的，该需求是用户所要求的。2)无歧义的，该需求只能用一种方式解释。3)可测的，该需求是可进行测试的。4)可跟踪的，该需求可从一个开发阶段跟踪到另一个阶段。5)可测量的，该需求是可测量的。 需求规约的基本性质:1)重要性和稳定性程度:按需求的重要性和稳定性，对需求进行分级。2)可修改的:在不过多地影响其他需求的前提下，可以容易地修改一个单一需求。 3)完整的:没有被遗漏的需求。4)一致的:不存在互斥的需求。 6、简述软件需求的分类。

答:软件需求可以分为两大类:一类是功能需求，一类是非公能需求，而非公能需求可 7、举例说明功能需求和非功能需求之间的基本关系。 答: 非功能需求可作用于一个或多个功能需求，例如 非功能需求可作用于一个或多个功能需求 其中，非功能需求1作用于功能需求1和功能需求3等；非功能需求2作用于功能需求2等。P24 8、有哪几种常用的初始需求发现技术 答:有5种常用的需求发现技术:自悟、交谈、观察、小组会和提炼。P26 9、简述需求规约的3种基本形式。 (1) 非形式化的需求规约。非形式化的需求规约即以一种自然语言来表达需求规约，如同使用一种自然语言写了一篇文章。(2) 半形式化的需求规约。半形式化的需求规约即以半形式化符号体系(包括术语表、标准化的表达格式等)来表达需求规约。(3)形式化的需求规约。形式化的需求规约即以一种基于良构数学概念的符号体系来编制需求规约，一般往往伴有解释性注释的支持。 P29 10、简述软件需求规约的内容和作用。 答:软件需求规约的内容有:引言、总体描述、特定需求、附录、索引。P28 需求规约的作用可概括为以下4点:1)需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现。2)对于项目的其余大多数工作，需求规约是一个管理控制点。3)对于产品/系统的设计，需求规约是一个正式的、受控的起始点。4)需求规约是创建产品验收测试计划和用户指南的基础。P31 11、简述需求规约在项目开发中的基本作用。 答:需求规约的作用可概括为以下4点:1)需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现。2)对于项目的其余大多数工作，需求

土木工程概论复习题库

工程管理之《土木工程概论》（06393）复习题库 一、单选题 1、目前世界最高的大厦在 C:阿联酋 2、十八层的房屋建筑属于D:高层建筑 3、建筑工程设计程序正确的是 A:方案设计→初步设计→技术设计→施工图设计 4、房屋建筑结构中的楼板通常是属于哪种基本构件A:受弯构件 5、下面哪个级别的建筑物的耐久性和重要程度最高A:一级建筑物 6、桥梁的下部结构由组成A:桥墩、桥台、基础 7、上海杨浦大桥属于D:斜拉桥 8、某大厦建成后存在严重质量问题，不得不爆破拆除，这说明工程项目具有D:不可逆转性的特征 9、也称片石，是采石场由爆破直接获得的形状不规则的石块 B:毛石 10、第一座依照现代钢框架结构原理建造起来的高层建筑是D:芝加哥家庭保险公司大厦 11、将建筑物从屋顶、墙面、楼层、基础等构件全部断开，即使建筑物的相邻部位也互不牵制，从而避免建筑物开裂的是 B:沉降缝 12、作为跑道和土质地面之间过渡用，主要用来减少飞机一旦冲出或偏离跑道时有损坏的危险C:跑道道肩 13、在地形图上或地面上选定线路的走向，并确定线路的空间位置过程是C:铁路定线 14、跨越码头与人工岛之间的连接通道被称为C:栈桥 15、在正常条件下，一条道路在单位时间内可通过的车辆数，称为道路 C:通行能力 16、下列关于高速铁路模式的说法哪一种是错误的 C:德国ICE模式：全部修建新线，旅客列车专用 17、下面港口堆场的分类是正确的D:按货物种类及使用特点分类：散货堆场、件杂货堆场、集装箱堆场 18、主干路的设计年限为C:20年 19、是建造各类工程设施的科学技术的总称 A:土木工程 20、是关于事物的基本原理和事实的有组织、有系统的知识B:科学 21、美国金门大桥是世界上第一座单跨超过千米的大桥、它属于D:悬索桥 22、桥梁按受力特点和结构体系主要分为C:梁式桥、拱桥、悬索桥、刚架桥、斜拉桥、组合体系桥 23、桥墩的作用是 B:支承在其左右两跨上部结构通过支座传来的竖直力和水平力 24、下列建筑中采用成束筒结构的是D:美国西尔斯塔楼 25、当建筑物建造在土层性质差别较大的地基上，可在房屋适当的位置设置垂直缝隙，将建筑物从屋顶、墙面、楼层、基础等构件全部断开，划分为若干个刚度较好的单元，从而避免建筑物开裂的构造是 B:沉降缝 26、工程项目管理难度最大的阶段是工程项目的A:实施阶段 27、上海东方明珠电视塔属于D:高耸结构建筑 28、是一种带状的、三维空间的人工构造物，它常和桥梁、涵洞、隧道等构成统一的工程实体，是供各种车辆和行人通行的工程设施 B:道路 29、是利用不适合种田的山泥，废土，砂等，加入少量水泥或石灰作固结剂及微量外加剂和适量水混合搅拌压制成型，自然养护或蒸养一定时间制成的 B:非烧结粘土砖 30、用于门窗等洞口上部用以承受洞口上部荷载的梁是 C:过梁 31、在港口中，对于汽车和装卸流动机械共同行驶的道路宽度一般不应小于C:10～12m 32、在路堤的路肩边缘以下、路堑路基面两侧的侧沟外，因填挖而形成的斜坡面，称为C:路基边坡 33、是由人工或机械开采出的较规则的六面体石块A:料石 34、地下铁道的施工方法主要分为两大类A:明挖法、暗挖法 35、高速公路定线的原则包括 B:路线与城市应有一定距离 36、道路的设计标高高于整个自然地面，需全部填土形成路基的是 A:路堤 37、轨道间宽度1435mm的轨道是 A:标准轨 38、下面哪个组成属于港口水域 D:港池、锚地、进港航道

软件工程课后习题答案

软件工程课后习题答案 习题1 略。 习题2 略。 习题3 略。 习题4 2.在什么情况下应该使用形式化说明技术？使用形式化说明技术时应遵守哪些准则？ 人们在理解用自然语言描述得规格说明时,容易产生二义性。为了克服非形式化方法得缺点,人们把数学引入软件开发工程,创造了基于数学得形式化说明技术。 应用形式化方法得准则: (1)应该选用释放得表示方法; (2)应该形式化,但不要过分形式化; (3)应该估算成本; (4)应该有形式化方法顾问随时提供咨询; (5)不应该放弃传统得开发方法; (6)应该建立详尽得文档; (7)不应该放弃质量标准; (8)不应该盲目依赖形式化方法; (9)应该测试、测试再测试; (10)应该重用。 4.用有穷状态机说明自动化图书馆流通系统

习题5 略。 习题6 略。 习题7 略。 习题8 略。 习题9 1.什么就是面向对象方法学？它有哪些优点？ 面向对象方法学,就是尽可能模拟人类习惯得思维方式,使开发软件得方法与过程尽可能接近人类认识世界解决问题得方法与过程,从而使得实现解法得解空间(也称为求解域)与描述问题得问题空间(也称为问题域)在结构上尽可能一致。 优点: 1.与人类习惯得思维方法一致; 2.稳定性好; 3.可重用性好; 4.较易开发大型软件产品; 5.可维护性好 10.建立订货系统得用例模型。 分析如下:从对这个订货系统得需求可以知道,仓库管理员通过放在仓库中得终端把零件入库/出库市事务报告给订货系统,系统接受到事务信息之后应该处理事务;采购员需要使用订货系统提供得产生报表功能,以获取订货报表。综上所述,用例如下: 习题10 1．用面向对象方法分析研究本书习题2第2题中描述得储蓄系统,试建立它得对象模型、动态模型与功能模型。

软件工程导论课后习题答案

第一章 一、什么是软件危机？它有哪些典型表现？为什么会出现软件危机？ 软件危机是指在计算机软件开发、使用与维护过程中遇到的一系列严重问题和难题。它包括两方面：如何开发软件，已满足对软件日益增长的需求；如何维护数量不断增长的已有软件。 软件危机的典型表现： (1) 对软件开发成本和进度的估计常常很不准确。常常出现实际成本比估算成本高出一个数量级、实际进度比计划进度拖延几个月甚至几年的现象。而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量。这些都降低了开发商的信誉，引起用户不满。 (2) 用户对已完成的软件不满意的现象时有发生。 (3) 软件产品的质量往往是靠不住的。(4) 软件常常是不可维护的。 (5) 软件通常没有适当的文档资料。文档资料不全或不合格，必将给软件开发和维护工作带来许多难以想象的困难和难以解决的问题。 (6) 软件成本、软件维护费在计算机系统总成本中所占比例逐年上升。 (7) 开发生产率提高的速度远跟不上计算机应用普及的需求。 软件危机出现的原因： (1) 来自软件自身的特点：是逻辑部件，缺乏可见性；规模庞大、复杂，修改、维护困难。 (2) 软件开发与维护的方法不当：忽视需求分析；认为软件开发等于程序编写；轻视软件维护。 (3) 供求矛盾将是一个永恒的主题：面对日益增长的软件需求，人们显得力不从心。 二、假设自己是一家软件公司的总工程师，当把图给手下的软件工程师们观看，告诉他们及时发现并改正错误的重要性时，有人不同意这个观点，认为要求在错误进入软件之前就清楚它们是不现实的，并举例说：“如果一个故障是编码错误造成的，那么，一个人怎么能在设计阶段清除它呢？”应该怎么反驳他？ 答：在软件开发的不同阶段进行修改付出的代价是很不相同的，在早期引入变动，涉及的面较少，因而代价也比较低；在开发的中期，软件配置的许多成分已经完成，引入一个变动要对所有已完成的配置成分都做相应的修改， 不仅工作量大，而且逻辑上也更复杂，因此付出的代价剧增；在软件“已经完成”是在引入变动，当然付出的代价更高。一个故障是代码错误造成的，有时这种错误是不可避免的，但要修改的成本是很小的，因为这不是 整体构架的错误。 三、什么是软件工程？它有哪些本质特征？怎样用软件工程消除软件危机？ 1993年IEEE的定义：软件工程是：①把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件；②研究①中提到的途径。 软件工程的本质特征： (1) 软件工程关注于大型程序(软件系统)的构造(2) 软件工程的中心课题是分解问题，控制复杂性(3) 软件是经 常变化的，开发过程中必须考虑软件将来可能的变化 (4) 开发软件的效率非常重要，因此，软件工程的一个重要课题就是，寻求开发与维护软件的更好更有效的方法和工具 (5) 和谐地合作是开发软件的关键(6) 软件必须有效地支持它的用户 (7) 在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人(完成一些工作)消除软件危机的途径： (1) 对计算机软件有一个正确的认识(软件≠程序） (2) 必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目 (3) 推广使用在实践中总结出来的开发软件的成功技术和方法 (4) 开发和使用更好的软件工具 四、简述结构化范型和面向对象范型的要点，并分析他们的优缺点。 1. 传统方法学：也称为生命周期方法学或结构化范型。优点：把软件生命周期划分成基干个阶段，每个阶段的任务相对独立，而且比较简单，便于不同人员分工协作，从而降低了整个软件开发过程的困难程度。缺点：当软件规模庞大时，或者对软件的需求是模糊的或会承受时间而变化的时候，开发出的软件往往不成功；而且维护起来仍然很困难。 2. 面向对象方法学：优点：降低了软件产品的复杂性；提高了软件的可理解性；简化了软件的开发和维护工作；促进了软件重用。 五、1-5 根据历史数据可以做出如下的假设： 对计算机存储容量的需求大致按下面公式描述的趋势逐年增加：M=(Y-1960) 存储器的价格按下面公式描述的趋势逐年下降：P1=×(美分/位) 如果计算机字长为16位，则存储器价格下降的趋势为：P2=×(美元/字) 在上列公式中Y代表年份，M是存储容量(字数)，P1和P2代表价格。

土木工程概论习题汇总(答案)

土木工程概论复习题汇总 一；填空题。 1. 砖按生产工艺分—烧结砖—和非烧结砖。 2. 砂一般分为天然砂和—人工砂________ 。 3. 配置混凝土时应优先选用—中砂______ 。 4. 所谓灰是指石灰_和石膏。 5. 土木工程中使用的钢材是指_线材_______ 和型材。 6. 水泥按其用途及性能分为通用水泥、_专用水泥_、特性水泥。 7. 普通混凝土是由水泥、 _粗骨料_、细骨料、和 _水—拌合，经硬化而成的一种人 造石材。 8. 绝热材料按其成分分为无机材料和_有机材料_。 9. 将上部结构的荷载传给土地基，连接上部结构与地基土的下部结构称为—基 础__ 。 10. 常用工程地质测绘方法有相片成图法和 _实地测绘法—。 11. 通常把位于天然地基上，埋置深度小于5m的一般基础以及埋深度虽超过5m 但小于基础宽度的大尺寸基础，统称为天然地基上的_____ 浅基础。 12. 刚性基础通常由砖、毛石、_素混凝土 _、和灰土等材料做成。 13. 建筑物的基础分为刚性基础和柔性基础，钢筋混凝土基础属于—柔性________ 基 础。 14. 浅基础一般分为单独基础，_条形基础_、伐板基础和箱形基础、壳体基础。 15. 埋置深度大于_ 5米______ 或大于基础宽度的基础，称为深基础。 16. 桩按荷载传递方式分为端承桩和 _摩擦桩_。 17. 建筑物的基本构建可分为梁、板、—柱_、拱。 18. 梁和板都是工程结构中的 _受弯—构件。 19. 梁按支撑方式可分为—简支梁_、悬臂梁和连续梁。 20. 柱是工程结构中的 _ 受压—构件。 21. 框架结构承受—竖向—荷载能力强，但承受水平荷载能力差。 22. 当前我国的公路等级按照其使用任务、功能和适应的交通量分为_ 5 —个等 级。

软件工程导论课后题

1-5、根据历史数据可以做出如下的假设： 对计算机存储容量的需求大致按下面公式描述的趋势逐年增加：M=4080e0.28(Y-1960) 存储器的价格按下面公式描述的趋势逐年下降：P1=0.3×0.72Y-1974(美分/位) 如果计算机字长为16位，则存储器价格下降的趋势为：P2=0.048×0.72Y-1974(美元/字) 在上列公式中Y代表年份，M是存储容量(字数)，P1和P2代表价格。 基于上述假设可以比较计算机硬件和软件成本的变化趋势。要求计算： (1) 在1985年对计算机存储容量的需求估计是多少?如果字长为16位，这个存储器的价格是多少? (2) 假设在1985年一名程序员每天可开发出10条指令，程序员的平均工资是每月4000美元。如果一条指令为一个字长，计算使存储器装满程序所需用的成本。(3) 假设在1995年存储器字长为32位，一名程序员每天可开发出30条指令，程序员的月平均工资为6000美元，重复(1)、(2)题。

2-4 目前住院病人主要由护士护理，这样做不仅需要大量护士，而且由于不能随时观察危重病人的病情变化，还会延误抢救时机。某医院打算开发一个以计算机为中心的患者监护系统，请分层次地画出描述本系统功能的数据流图。 医院对患者8监护系统的基本要求是随时接收每个病人的生理信号(脉搏、体温、血压、心电图等)，定时记录病人情况以形成患者日志，当某个病人的生理信号超出医生规定的安全范围时向值班护士发出警告信息，此外，护士在需要时还可以要求系统印出某个指定病人的病情报告。 从问题陈述可知，本系统数据源点是“病人”和“护士”，他们分别提供生理信号和要求病情报告的信息。进一步分析问题陈述，从系统应该“定时记录病人情况以形成患者日志”这项要求可以想到，还应该有一个提供日期和时间信息的“时钟”作为数据源点。 从问题陈述容易看出，本系统的数据终点是接收警告信息和病情报告的护士。 系统对病人生理信号的处理功能主要是“接收信号”、“分析信号”和“产生警告信息”。 此外，系统还应该具有“定时取样生理信号”、“更新日志”和“产生病情报告”的功能。 为了分析病人生理信号是否超出了医生规定的安全范围，应该存储“患者安全范围”信息。此外，定时记录病人生理信号所形成的“患者日志”，显然也是一个数据存储。

软件工程习题答案参考

软件工程 绪论 1.什么是软件危机为什么会产生软件危机 答：软件危机是指在计算机软件的开发和维护过程中遇到的一系列严重问题。(1).软件维护费用急剧上升，直接威胁计算机应用的夸大。 (2).软件生产技术进步缓慢 2.什么是软件生产工程化工程化生产方法与早期的程序设计方法主 要差别在哪里 答：结构化程序设计地出现，使许多产业界认识认识到必须把软件生产从个人化方式改变为工程化。采用工程的概念、原理、技术和方法开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程，同时这也是工程化生产方法。 3.分别说明（1）软件开发方法与开发工具；（2）软件技术与软件管 理的相互关系。 答：（1）工具和方法，是软件开发技术的两大支柱，它们密切相关。当一种方法提出来并证明有效后，往往随之研制出相应的工具，来帮助实现和推行这种方法。新方法在推行初期，总有人不愿接受和采用。若将新方法融合于工具之中，使人们通过使用工具来了解新方法，就能更快促进新方法的推广。（2）在工业生产中，即使有先进的技术和设备，管理不善的企业也不能获得良好的效益。软件在生产中不能按质按时完成计划，管理混乱往往是其中的重要原因。所以对于

一个理想的软件工程环境，应该同时具备技术和管理两个方面。 4.试从你的亲身实践，谈谈软件工具在软件开发中的作用。 答：用C++开发一个软件，是校园一卡通的模块。首先，要在编辑程序支持下在计算机中输入源程序。然后编译程序，把源程序翻译成目标程序。如果发现错误，就重新调入编辑程序对源程序进行修改。编译通过后，再调用连接程序吧所有通过了编译目标程序连同与之有关的程序连接起来，构成一个能在计算机上运行的可执行软件。编译程序，编辑程序，连接程序以及支持他们的计算机操作系统，都属于软件工具。离开这些工具，软件开发就是去了支持，变得十分困难和低效，甚至不能运行。 5.什么是软件工程环境谈谈你对环境重要性的认识。答：方法与工具相结合，再加上配套的软、硬件支持就形成环境。例如在批处理时代，用户开发的程序是分批送入计算机中心的计算机的，有了错误，就得下机修改。程序员对自己写的程序只能继续地跟踪，思路经常被迫中断，效率难于提高。分时系统的使用，使开发人员从此能在自己的终端上跟踪程序的开发，仅此一点，就明显提高了开发的效率。 6. 何谓面向对象软件工程简述它与传统软件工程在各型软件开发中的作用。 答：以面向对象程序设计为基础。 7. 软件按规模大小可分成哪几类简述软件工程中各型软件开发中的作用。 答：按规模分为极小、小、中、大、甚大、极大。（1）中小型软件：

土木工程概论习题答案

土木工程概论习题 第一章绪论 1.1土木工程概论课程的任务 1、简述土木工程的概念及其包含的内容。 答：概念：土木工程是建造各类工程设施的科学技术的总称，它即指工程建设的对象，即建在地上、地下、水中的各种工程设施，也指所应用的材料、设备和所进行的勘探设计、施工、保养、维修等技术。 包含的内容：基础工程、房屋建筑工程、交通土建工程、桥梁工程、港口工程、地下工程、水利水电工程。 1.2土木工程发展历史概述 1、简述古代土木工程的特点。 答：没有系统的设计理论，主要依靠经验 2、简述近代土木工程的特点。 答：（1）、有了比较系统的设计理论，如1683年意大利学者伽利略发表了“关于两门新科学的对话”，首次用公式表达了梁的设计理论；1687年牛顿总结出力学三大定律，为土木工程奠定了力学分析基础；1825年，法国的纳维于1825年建立了土木工程中结构设计的容许应力法。（2）、从材料方面讲，1824年波特兰水泥发明；1867年钢筋混凝土开始应用于土木工程；1859年转炉法炼钢发明 3、简述现代土木工程的特点。 答：（1）、功能要求多样化：由于电子技术，精密机械，生物基因工程，航空航天等高技术工业的发展，许多工业建筑提出了恒湿、恒温、防微震、防腐蚀、防辐射、防磁、无微尘等要求，并向跨度大、分隔灵活、工厂花园化的方向发展。 （2）、城市建设立体化：经济发展、人口增多，造成城市用地紧张、交通拥挤。 （3）、交通工程快速化：市场经济要求运输系统快速、高效，现代化技术的进步提供了条件。（4）、工程设施大型化 1.2土木工程的未来 1、目前土木工程面临的形势有哪些？ 答：（1）、世界正经历工业革命以来的有一次重大变革，这便是信息（包括计算机、通信、网络等）工业的迅猛发展，可以预计人类的生产、生活方式将会发生重大变化。 （2）、航空、航天事业等高科技事业的发展，月球上已经留下了人类的足迹，对火星及太阳系内外星空的探索已取得了巨大进步。 （3）、地球上居住人口激增，目前世界人口已经达60亿，预计21世纪末，人口要接近百亿。地球上的资源有限，日益浩劫 （4）、生态环境受到严重破坏，随着工业的发展、技术的进步，人类的生存环境却日益恶化。 2、未来土木工程的发展趋势？ 答：（1）、重大工程项目将陆续兴建 （2）、土木工程将向太空、海洋、荒漠地开拓 （3）、工程材料向轻质、高强、多功能化发展 传统材料的改性、化学合成材料的应用 （4）、设计方法精确化，设计工作自动化 （5）、信息和智能化技术全面引人土木工程

软件工程概述习题及答案

第一章软件工程概述 一. 填空题 1. 软件的发展过程, , , . 2. 基于软件的工作方式,软件可以划分为, , , . 3. 在软件发展的第四阶段计算机体系结构迅速地从环境转变为环境. 4. 在计算机系统中,软件是, 而硬件是. 5. 软件危机是在软件发展第阶段末期，随着第代计算机和诞而产生。 6. 文档一般可分为面向的文档，面向的文档，面向的文档和面向的文档。 7. 软件生存期若分为三个大的阶段，，. 8. 它是经过阶段评审后的软件配置成分（各个阶段产生的文档或程序代码）。 9. 在软件的生存周期开发阶段要经三个步骤, , 。 10. 瀑布模型是以文档为驱动、适合于的软件项目的模型。 11. 螺旋模型将开发过程分为几个螺旋周期，在每个螺旋周期内为，， 和四个步骤。 12. 软件开发的螺旋模型综合了瀑布模型和演化模型的优点，还增加了____。采用螺旋模型时，软件开发沿着螺线自内向外旋转，每转一圈都要对____ 进行识别和分析，并采取相应的对策。螺旋线第一圈的开始点可能是一个____ 。从第二圈开始，一个新产品开发项目开始了，新产品的演化沿着螺旋线进行若干次迭代，一直运转到软件生命期结束。 13. 软件开发模型, , , , , . 14. 软件工程面临的问题有, , , . 15. 面向对象方法学把客观世界的事物或实体都看成对象,把对象作为分析设计的元素,把所有对象都划分成对象类,类可以派生和. 16．基于软件的功能划分可以把软件划分为, ,和。 17．计算机系统发展的早期所形成的一系列错误概念和做法，已经严重地阻碍了计算机软件的开发，甚至有的根本无法维护，只能提前报废，造成大量人力、物力的浪费，从而导致软件危机。为了研究解决的方法，计算机科学技术领域中的一门新兴的学科逐步形成了，这就是。18．软件工程是指导的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，这就是软件工程。 19．为了开发出低成本高质量的软件产品，软件工程学应遵守以下基本原则：, ,和, 。 20．原型模型是从需求分析开始。软件开发者和用户在一起定义，说明需求，并规划出定义的区域。然后快速设计软件中对用户/客户可见部分的表示。快速设计导致了原形的建造，原形由用户/客户评估，并进一步求精。

软件工程课后参考答案

第一章 1.1什么是计算机软件？软件的特点是什么？ 计算机软件是指计算机系统中的程序及其文档 软件的特点： ●软件是一种逻辑实体，而不是有形的系统元件，其开发成本和进度难以准确地估算。 ●软件是被开发的或被设计的，没有明显的制造过程，一旦开发成功，只需复制即可， 但其维护的工作量大。 ●软件的使用没有硬件那样的机械磨损和老化问题。 1.2简述软件的分类，并举例说明 1.系统软件 系统软件居于计算机系统中最接近硬件的一层，其他软件一般都通过系统软件发挥作用。例如：编译软件、操作系统。 2.支撑软件 支撑软件是支撑软件的开发和维护的软件。例如：数据库管理系统、网络软件、软件工具、软件开发环境。 3.应用软件 应用软件是特定应用领域专用的软件。例如：工程/科学计算机软件、嵌入式软件、产品线软件、Web应用软件、人工智能软件。 1.3简述软件语言的分类，并举例说明。 1.需求定义语言 是用于书写软件需求定义的语言。例如：PSL/PSA。 2.功能性语言 是用于书写软件功能规约的语言，通常又称为功能规约语言。例如：广谱语言、Z 语言。 3.设计性语言 是用于书写软件设计规约的语言。例如：PDL。 4.实现性语言 也称为程序设计语言，是用于书写计算机程序的语言。例如：C、java、PROLOG、FORTRAN、COBOL、Modula。 5.文档语言 是用于书写软件文档的语言。通常用自然语言或半形式化语言书写。 1.4什么是软件工程？ 软件工程是应用计算机科学、数学及管理科学等原理，开发软件的工程。软件工程借鉴传统工程的原则、方法，以提高质量、降低成本为目的。 1.5简述软件工程的基本原则。 软件工程原则包括围绕工程设计、工程支持和工程管理所提出的以下4条基本原则。 1.选取适宜的开发模型 必须认识需求定义的易变性，采用适宜的开发模型，保证软件产品满足用户的要求。 2.采用合适的设计方法

土木工程概论习题汇总[1]

土木工程概论习题汇总

一、单项选择题 1、（）是双向行车道、中央设有分车带、进出口一般全控制或部分控制，为城市大量、长距离、快速交通服务。 A、快速道； B、主干道； C、次干道； D、支道。 2、公路路基的（）形式有路堤、路堑和半填半挖三种。 A、功能； B、结构； C、平面布置； D、横断面。 3、下列哪一项不属于公路的技术标准（）。 A、几何标准； B、载重标准； C、净空标准； D、速度标准。 4、我国已建成的高速公路总里程已居世界第（）位。 A、一； B、二； C、三； D、四。 5、（）沿线有安全设施、交通管理设施、服务性设施、环境美化设施。 A、高速公路； B、城市道路； C、乡村公路； D、县乡公路。 6、（）设施一般为高速公路入口控制、交通监控设施。服务性设施一般有综合性服务站、小型休息点、停车场等。 A、安全； B、交通管理； C、服务性； D、环境美化。 7、（）设施一般包括标志(如警告、限制、指示标志等)、标线、护栏、隔离设施、照明及防眩设施、视线诱导设施。 A、安全； B、交通管理； C、服务性； D、环境美化。 8、（）分为：快速道、主干道、次干道、支道、居住区道路、风景区道路、白行车专用道。 A、高速公路； B、城市道路； C、乡村公路； D、县乡公路。 9、公路基本（）形式有：全挖式、台口式和半山洞式。 A、涵洞； B、排水； C、遂道； D、路堑。 10、（）是指一条道路在单位时间内，道路与交通正常条件下，保持一定速度安全行驶时，可通过的车辆数。 A、高速公路； B、城市道路； C、通行能力； D、交通能力。 11、第一条完全用于客货运输而且有特定时间行驶列车的铁路，是（）年通车的英国利物浦与曼彻斯特之间的铁路，这条铁路全长为563 km。 A、1830； B、1863； C、1892； D、1919。 12、高速铁路的信号与（）是高速列车安全、高密度运行的基本保证。 A、灯光系统； B、控制系统； C、路基； D、铁路平顺度。

软件工程课后习题答案

软件工程课后习题答案 第一章 一、什么是软件危机？它有哪些典型表现？为什么会出现软件危机？ 软件危机是指在计算机软件开发、使用与维护过程中遇到的一系列严重问题和难题。它包括两方面：如何开发软件，已满足对软件日益增长的需求；如何维护数量不断增长的已有软件。软件危机的典型表现： (1) 对软件开发成本和进度的估计常常很不准确。常常出现实际成本比估算成本高出一个数量级、实际进度比计划进度拖延几个月甚至几年的现象。而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量。这些都降低了开发商的信誉，引起用户不满。 (2) 用户对已完成的软件不满意的现象时有发生。 (3) 软件产品的质量往往是靠不住的。 (4) 软件常常是不可维护的。 (5) 软件通常没有适当的文档资料。文档资料不全或不合格，必将给软件开发和维护工作带来许多难以想象的困难和难以解决的问题。

(6) 软件成本、软件维护费在计算机系统总成本中所占比例逐年上升。 (7) 开发生产率提高的速度远跟不上计算机应用普及的需求。软件危机出现的原因： (1) 来自软件自身的特点：是逻辑部件，缺乏可见性；规模庞大、复杂，修改、维护困难。 (2) 软件开发与维护的方法不当：忽视需求分析；认为软件开发等于程序编写；轻视软件维护。 (3) 供求矛盾将是一个永恒的主题：面对日益增长的软件需求，人们显得力不从心。 二、假设自己是一家软件公司的总工程师，当把图1.1给手下的软件工程师们观看，告诉他们及时发现并改正错误的重要性时，有人不同意这个观点，认为要求在错误进入软件之前就清楚它们是不现实的，并举例说：“如果一个故障是编码错误造成的，那么，一个人怎么能在设计阶段清除它呢？”应该怎么反驳他？ 答：在软件开发的不同阶段进行修改付出的代价是很不相同的，在早期引入变动，涉及的面较少，因而代价也比较低；在开发的中期，软件配置的许多成分已经完成，引入一个变动要对所有已完成的配置成分都做相应的修改， 不仅工作量大，而且逻辑上也更复杂，因此付出的代价剧增；在软件“已经完成”是在引入变动，当然付出的代价更高。一个故障是代码错误造成的，有时这种错误是不可避免的，但要修改的成本是很小的，因为这不是整体构架的错误。

软件工程概论课后习题答案

软件工程概论郑人杰等版 第1章软件与软件工程的概念 1.1 举出你所知道的应用软件的例子。 办公软件、游戏软件、财务软件、银行软件、人事管理软件、工资管理软件、学籍管理软件等。 1.2 认为“软件就是程序，软件开发就是编程序。”这种观点是否正确？为什么？ 认为“软件就是程序，软件开发就是编程序。”这种观点是错误的。 首先，软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合，程序只是软件的组成部分之一；其次，在软件开发中，编程只是软件开发过程的一个阶段。 1.3 如果将软件开发比作高楼大厦的建造，可以将软件的设计比作什么？ 可以将软件的设计比作建筑设计，软件设计的成果相当于建筑设计的设计图纸。 1.4 什么是软件危机？它有哪些典型表现？为什么会出现软件危机？ 软件危机：软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。 典型表现： (1)对软件开发成本和进度的估计常常很不准确。 (2)用户对“已完成的”软件系统不满意的现象经常发生。 (3)软件产品的质量往往靠不住。 (4)软件常常是不可维护的。 (5)软件通常没有适当的文档资料。 (6)软件成本在计算机系统总成本中所占的比例逐年上升。 (7)软件开发生产率提高的速度，既跟不上硬件的发展速度，也远远跟不上计算机应用 迅速普及深入的趋势。 产生软件危机的原因：除了软件本身的特点，其原因主要有以下几个方面： (1) 缺乏软件开发的经验和有关软件开发数据的积累，使得开发工作计划很难制定。 (2) 软件人员与用户的交流存在障碍，使得获取的需求不充分或存在错误。 (3) 软件开发过程不规范。如，没有真正了解用户的需求就开始编程序。 (4) 随着软件规模的增大，其复杂性往往会呈指数级升高。需要很多人分工协作，不仅涉及 技术问题，更重要的是必须有科学严格的管理。

《土木工程概论》复习题及标准答案

《土木工程概论》复习题及答案

————————————————————————————————作者：————————————————————————————————日期：

《土木工程概论》复习题及答案 一、填空题 1、土木工程包括、、 和等工程。 2、土木工程结构中常用的结构及构件形式包括、、 、和等。 3、钢筋混凝土结构主要包括框架结构体系、、、 等。 4、特种结构包括烟囱、、、、 、等。 5、桥梁结构主要包括、、、、 等。 6、我国第一条开工建设的高速公路是。 7、隧道工程的施工方法有和等几种。 8．工程规范分为，、和四级。 9．土木工程抗灾主要是和工程结构在受灾以后的 与等。 10．建设程序是指建设项目从、、、 、、到竣工验收，投入生产的整个建设过程中，各项工作必须遵守先后次序的法则。 11、岩石按成因分为、、。 12、路基可分为、和三种。 13、3级以上的地震称，5级以上的地震称。 14．项目管理基本目标有三个最主要的方面：， 和。 15．建设监理是指受的委托对或 进行监督和管理的活动。 16．建设项目管理的核心内容可概括为“三控制、二管理、一协调”，即、、、、、 和。 17．年月日国家建设部颁发了 《》，这是我国第一个建设监理的法规性文件。 18．工程建设监理的中心任务是、和。 答案： 1、建筑工程、道路工程、桥梁工程、给水排水工程、地下工程、铁路工程、隧道工程、港口工程、机场工程（任意4个即可） 2、墙、板、梁、柱、拱、壳、杆（填出5个即可） 3、剪力墙结构体系、框架剪力墙结构体系、筒体结构体系

4、冷却塔、水池、水塔、料斗、筒仓、桅杆结构（填出其中5个即可） 5、梁式桥、桁架桥、拱桥、刚架桥、悬索桥、斜拉桥（填出其中5个即可） 6、沈阳至大连高速公路 7、明挖、暗挖、盖挖、顶进、盾构（填出其中2个即可） 8．全国性的建设规范，地方性建设规范，地方性建设规章，各主管机构制定的规范。9．工程结构抗灾，检测，加固。 10．立项、报建；可行性研究；选择建设地点；编制设计任务书；编制勘察设计文件；建设施工 11、岩浆岩、沉积岩、变质岩。 12、路堤、路堑、半挖半填。 13、有感地震，破坏性地震。 14．专业目标，工期目标，费用目标。 15．监理单位、建设单位、工程建设全过程、项目实施阶段。 16．进度控制、质量控制、费用控制、合同管理、信息管理、组织协调。 17．1989、7、28、《建设监理试行规定》。 18．工程质量控制、工程投资控制、建设工期控制。 二、不定项选择题 1，土木工程包括（） A,工程建设的对象 B,工程应用的材料设备 C,工程中进行的勘测设计D, 工程施工 2，砖、瓦、砂、石、灰属于（） A,地方材料 B,结构材料 C,功能材料 D,工程材料 3，工程地质勘查的目的主要有（） A,查明工程地质条件 B,分析存在的地质问题 C,寻找适宜的施工地区 D,对建筑地区做出地质评价 4，属于建筑基本构件的有（） A, 板 B, 梁 C, 柱 D, 桩 5，中国的北京故宫属于（） A, 钢结构 B, 砖石结构 C, 木结构 D, 钢筋混凝土结构 6，土木工程全面引入信息和智能化技术大致表现在（） A, 信息化施工 B, 智能化建筑 C, 智能化交通 D, 工程分析仿真系统 7，砖砌体中使用的砂粒直径应小于（） A, 1.5 mm B, 2 mm C, 2.5 mm D, 3 mm 8，可用于制造砂浆的胶凝材料是（） A, 石灰 B, 水泥 C, 沥青 D, 石膏 9，浅基础按基础刚度的不同可分为（） A, 刚性基础 B, 柔性基础 C, 扩展基础 D, 拓展基础 10，现在发现我国古代曾使用过的地基处理方法有（） A, 夯实法 B, 预压法 C, 搅拌法 D, 振冲法 答案：1ABCD 2A 3ABD 4ABC 5C 6ABCD 7C 8ABD 9AC 10A 三、单项选择题

软件工程课后习题答案第五版

软件工程课后习题答案第五版 《软件工程导论》课后习题答案 第一章软件工程概论 1．什么是软件危机？ 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题表现在以下几个方面： (1)用户对开发出的软件很难满意。 (2)软件产品的质量往往靠不住。 (3)一般软件很难维护。 (4)软件生产效率很低。 (5)软件开发成本越来越大。 (6)软件成本与开发进度难以估计。

(7)软件技术的发展远远满足不了计算机应用的普及与深入的需要。 2．为什么会产生软件危机？ (1) 开发人员方面，对软件产品缺乏正确认识，没有真正理解软件产品是一个完整的配置组成。造成开发中制定计划盲目、编程草率，不考虑维护工作的必要性。 (2) 软件本身方面，对于计算机系统来说，软件是逻辑部件，软件开发过程没有统一的、公认的方法论和规范指导，造成软件维护困难。 (3) 尤其是随着软件规模越来越大,复杂程度越来越高,原有软件开发方式效率不高、质量不能保证、成本过高、研制周期不易估计、维护困难等一系列问题更为突出，技术的发展已经远远不能适应社会需求。 3．怎样克服软件危机？ (1) 充分吸收和借鉴人类长期以来从事各种工程项目中积累的行之有效的有效原理、概念、技术与方法，特别是吸取几十年来人类从事计算机硬件研究和开发的经验教训。在开发软件的过程中努力作到良好的组织，严格的管理，相互友好的协作。

(2) 推广在实践中总结出来的开发软件的成功的技术和方法，并研究更好、更有效的技术和方法，尽快克服在计算机系统早期发展阶段形成的一些错误概念和作法。 (3) 根据不同的应用领域，开发更好的软件工具并使用这些工具。将软件开发各个阶段使用的软件工具集合成一个整体，形成一个很好的软件开发支环环境。 总之为了解决软件危机，既要有技术措施(方法和工具)，又要有必要的组织管理措施。 4.构成软件项目的最终产品： 应用程序、系统程序、面向用户的文档资料和面向开发者的文档资料。 5．什么是软件生存周期？ 软件生存周期是指从软件定义、开发、使用、维护到淘汰的全过程。 6．软件生存周期为什么划分成阶段？ (1) 任何一个阶段的具体任务不仅独立，而且简单，便于不同人员分工协作，从而降低整个软件开发工作的困难程度。

软件工程导论第六章课后答案

计算机科学与技术 第六章习题答案 4、图6.18给出的程序流程图代表一个非结构化的程序，问： （1）为什么说它是非结构化的？ （2）设计一个等价的结构化程序。 （3）在（2）题的设计中使用附加的标志变量flag了吗？若没有，再设计一个使用flag的程序；若用了，再设计一个不用flag的程序。 图6.18 一个非结构化程序 答：（1）图示程序的循环控制结构有两个出口，不符合结构程序的定义，因此是非结构化的程序。 （2）设计的等价结构化程序盒图如下所示：

（3）在第（2）题中没有使用标志变量flag，设计使用附加的标志变量flag，将上述程序改成等价的结构化程序，如下盒图所示： 7、某交易所规定给经纪人的手续费计算方法如下：总手续费等于基本手续费加上与交易中的每股价格和股数有关的附加手续费。如果交易总金额少于1000元，则等于手续费为交易金额的8.4%；如果交易总金额在1000元到10000元之间，则基本手续费为交易金额的5%，再加34元；如果交易总金额超过10000元，则基本手续费为交易金额的4%加上134元。当每股售价低于14元时，附加手续费为基本手续费的5%，除非买进、卖出的股数不是100的倍数，在这种情况下附加手续费为基本手续费的9%。当每股售价在14元到25元之间时，附加手续费为基本手续费的2%，除非交易的股数不是100的倍数，在这种情况下附加手续费为基本手续费的6%。当每股售价超过25元时，如果交易的股数零散（即，不是100的倍数），则附加手续费为基本手续费的4%，否则附加手续费为基本手续费的1%。要求：（1）用判定表表示手续费的计算方法。（2）用判定树表示手续费的计算方法。答：（1）用判定表表示手续费的计算方法如下所

软件工程课后习题答案

第一章 1.1举出至少5个例子来说明“意外效应法则”在计算机软件方面的应用。 答：典型的例子包括使用“数字汽车仪表板”的软件，赋予高科技，高品质的图像的软件；如广泛的消费类电子产品的软件；个人电脑，工业仪器仪表和机器的软件。软件分化出的在电子商务方面的应用。 1.2举例说明软件对社会的影响（包括正面影响和负面影响）。 答：这是一个很好的课堂讨论问题（如果时间允许），而不是专注于老生常谈的（但很重要）隐私问题，生活质量等问题。您可能想要讨论关于”技术恐惧“方面的问题，软件也许会使它恶化但也可能减少”技术恐惧“。另一个有趣的方面是使用诺依曼的“风险”列在中做重点讨论。你也可以考虑基于软件的“现金”经济，新模式的互动娱乐，虚拟现实，电子商务等方面来思考软件对社会的影响。 1.3针对1.1节提出的5个问题，请给出你的答案，并与同学讨论。 答：软件需要如此长的开发时间： a）设施不上线 b）开发工具并不如预期般运作 c）客户提出的新要求，需要重新设计和返工 d）产品依赖于政府的规定，被意外更改。 e）严格的要求，与现有系统的兼容性需要超过预期更多的测试，设计和实现。 f）多个操作系统下运行的任务需求比预期需要更长的时间。 g）软件项目风险管理比预期需要更多的时间。 h）依赖的技术仍处于开发阶段，从而延长日程安排。 开发成本高： a）比当时预期低得令人无法接受的质量，需要进行更多的测试，设计和实施工作。 b）制定了错误的软件功能需要重新设计和实施。 c）开发错误的用户界面，而导致重新设计和实施。 d）开发了不需要的额外的软件功能而延长了开发日程安排。 在将软件交付顾客使用之前，我们无法找到所有错误： a）产品依赖于政府监管，意外而改变。 b）产品技术标准草案，会意外更改。 c）有时会在项目后期添加新的开发人员。 d）因为团队内的冲突有时会导致沟通不畅，而产生糟糕的设计。 e）破坏高效调度产生的项目管理成果和无效的规划 f）有时装备部件质量差，导致额外的测试，设计和集成工作和管理额外的客户关系。 软件开发和维护的过程仍旧难以度量： a）有时该项目的目的是不明确。 b）有大量的业务所涉及的风险。 c）如果产品内置没有装好。 d）我们需要不断检讨我们的工作。 e）进行维护检查的时间。 f）在整个软件开发过程中要彻底组织项目团队。 1.4在交付最终用户之前，或者首个版本投入使用之后，许多应用程序都会有频繁的变更。