软件工程课后习题答案

软件工程课后习题答案Chapter11.1)The definition for software presented in Section 1.2 applies to the Web sites. There are, however, subtledifferences 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 youngpeople (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 thoseassociated 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 thefirst 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 beingof 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 beadapted 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 thathave 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 variousprocedures 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 isinvariant over the lifetime of a product.Chapter 22.1)2.2) Process assessment examines the software process used by an organization to determine whether it iseffective in achieving software engineering goals. The assessment characterizes the current practicewithin 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 measurableobjectives of the proc ess (the “process dimension”) and the set of process attributes that should bepresent (the “capability dimension”).2.4) Task Set for Communication Activity: A task set would define the actual work to be done to accomplishthe objectives of a software engineering action. For the communication activity these are:1.Make a list of stakeholders for the project2.Invite all the stakeholders to an informal meeting3.Ask them to make a list of features and functions4.Discuss requirements and build a final list5.Prioritize requirements and note the areas that stakeholders are uncertain ofThese 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 forall 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 evenlyacross 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 isdefined 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 usedto 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 andsystem 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 thatis produced and the resultant quality of the work product. The PSP process model defines fiveframework activities: planning, high-level design, high-level design review, development, andpostmortem. 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 workproducts that are developed.Chapter 33.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 wellunderstood (requirements are well-defined); (2) the delivery date is realistic; (3) it’s unlikely that majorchanges 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 numericalcalculation 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 andSQA procedures must be applied from the beginning. In addition, the prototype must be designed withextensibility in mind and must be implemented using a programming environment that is amenable toproduction system development. Initially, the prototype serves as a mechanism for identifying softwarerequirements. 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 bedelivered within a 60 – 90 day time frame. Although this is often the case, there are situations in whichtimelines are longer. In addition, RAD assumes that sufficient human resources will be available todevelop the increments in parallel. This may not be the case.3.5) Software applications that are relatively easy to prototype almost always involve human-machineinteraction and/or heavy computer graphics. Other applications that are sometimes amenable toprototyping 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 aremore difficult to prototype include control and process control functions, many classes of real-timeapplications and embedded software.3.6) The real question that a paper should address is: How do we develop a process that can accommodatemany 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 usedPC operating systems (that will remain nameless) quality does appear to be a reasonable harbinger ofsuccessful software. A program that is “flexible and extensible” will not succeed if it fails regularly andbehaves 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 allperform 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 whererequirements are fixed and work is to proceed to completion in a linear manner. In cases, where thedeveloper 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, aprototyping model may offer the best approach. In other cases, an incremental approach may makesense and the flow of Spiral model may be efficient. Special process models take on many of thecharacteristics 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 isanalogous to a task set. That is, a workflow identifies the tasks required to accomplish an importantsoftware engineering action and the work products that are produced as a consequence of successfullycompleting the tasks. UP workflow is conducted for every software project, whereas the five UP phasesdo not necessarily occur in a sequence, but rather with staggered concurrency. It is likely in the UP thatat 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 differentstages 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 orsoftware 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 andeven entire programs (see Chapter 28). However, for complex programs this is a very timeconsuming process. It is not possible to prove the correctness of any non-trivial program usingexhaustive 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, andinformation, they are often referred to as “crosscutting concerns.” Aspect-oriented softwaredevelopment, often referred to as aspect-oriented programming (AOP), is a relatively new softwareengineering paradigm that provides a process and methodological approach for defining, specifying,designing, and constructing aspects—“mechanisms beyond subroutines and inheritance forlocalizing the expression of a crosscutting concern.” a3.14) UML provides the necessary technology to support object-oriented (and conventional) softwareengineering practice, but it does not provide the process framework to guide project teams in theirapplication of the technology. The Unified Process is a framework for software engineering usingUML. Today, the Unified Process and UML are used on projects of all kinds. However, they are notthe same thing. UML is a modeling notation and language. UP is a process framework in whichUML 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 ofabstraction at which work is performed is reduced (i.e., implementation specific work accelerates as we move further from the origin).Chapter 66.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:UniversityAcademic programsDegree granting programs-undergraduateDegree granting programs-undergraduateProfessional educationContinuing educationAdministrative DepartmentsRegistrar ….CoursesFacultyInfrastructure Maintenance …6.4) The data architecture refers to corporate data, its organization, and the relationships betweenindividual corporate data elements. For example, a telephone billing system might draw on elementsthat include customer information, rate tables, calling logs and so forth. Application architecturedefines the functional hierarchy that is required to realize the goals and objectives of a largeinformation 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 ishigh likelihood of "creeping enhancements" and the possibility of building a system that doesn’t meetcustomer’s needs because perceptions of need are incorrect. When the customer is the systemengineer, the likelihood is that technical issues may be omitted, but it is likely that customer need willbe more accurately reflected. When an outside third party is the system engineer, communicationbandwidth between developer and customer must be very high. It’s likely that things will fall into thecracks. 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 thecustomer business/product domain, and understands the development environment (and leaps tallbuildings 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 systemthat controls and automated shunt.6.7) The assumptions, simplifications, limitations, constraints, and preferences are, of course, dependenton the system that is chosen. In general, assumptions should be kept to a minimum, the higher thenumber 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 ofthese, 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 itselfand then outward to external sinks (entities). Entities within each of the five functional areasrepresented 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, anexisting standard computer, operating system and I/O environment are to be used. In such cases, theSystem Specification can be eliminated in lieu of a Software Requirements Specification. There arealso situations in which a system prototype (either real or paper) is much more effective than aspecification.Chapter 77.2) In reality, the customer and the developer enter into a process of negotiation, where the customermay be asked to balance functionality, performance, and other product or system characteristicsagainst cost and time to market. The intent of this negotiation is to develop a project plan that meetsthe 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 hisown 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 descriptionof the project’s scope and then assess whether the scope can be achieved within the context ofmanagement and technical constraints. In essence, feasibility analysis (during inception) defines abusiness case for an idea and identifies the breadth and depth of the market that the product is toaddress.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 requirementsgathering activity. These data are then translated into a table of requirements—called the customervoice table—that is reviewed with the customers later. A variety of diagrams, matrices, andevaluation 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’thave the inclination to use it.7.5) Software engineers want to begin building something, so they sometimes give requirementsanalysis short shrift. In addition, understanding the requirements of a problem is among the mostdifficult tasks that a software engineer face since requirements change, are sometime contradictoryand are often difficult to enunciate clearly. Hence, software engineers want to get through therequirements 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 definedfor comprehensive requirements engineering should be performed rigorously. Requirementsengineering 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 stressestablish 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 theaccomplishment 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’sunlikely 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—oftenreferred to as the "user department." The customer for computer-based products is typically themarketing 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 softwareengineers learn more about the system to be built, and stakeholders understand more about whatthey really require. For that reason, the analysis model is a snapshot of requirements at any giventime.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 theerror is due to inconsistency, a more consistent presentation is developed; if the error is due to a badinterpretation 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 tonotice that certain things reoccur across all projects within a specific application domain. Thesecan 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 areinput) 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 thatsatisfies the majority of the customer’s needs and the software team wins by working to realisticand achievable budgets and deadlines.7.17) The specific elements of the analysis model are dictated by the analysis modeling method that is tobe 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 thingsthat 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 analysismodel 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 producesoutput in a variety of forms.Chapter 88.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 relationdiagram (ERD) depicts relationships between data objects. The flow and transformation of data。