软件工程课后习题答案goxk.docx

《软件工程课后习题答案goxk.docx》由会员分享，可在线阅读，更多相关《软件工程课后习题答案goxk.docx（14页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件工程课后习题答案Chapter11.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 Applic

2、ation 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

3、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, d

4、evelopers 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 fre

5、quently 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 th

6、e 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

7、 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) T

8、he 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 tel

9、ephone 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 maint

10、ained 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 22.1)Pa

11、ttern: CommunicationIntent:To establish a collaborative relationship with the customer in an effort to define project scope, business requirements and other project constraints.” Type: Stage patternInitial context: (1) Appropriate stakeholders have been identified and are willing to participate in c

12、ommunication (2) Stakeholders agree that a problem exists and that software may provide a solution Problem: Requirements must be elicited from stakeholders and organized in a way that can be used by software engineers. All stakeholders must collaborate to define requirements and to identify those ar

13、eas where requirements are uncertain.Solution:Each stakeholder must develop a description of the functions, features, information and behavior that are exhibited by the software. To accomplish this, a structured, facilitated meeting is conducted. For more details, see Sections 7.3, 7.4 and 7.5.Resul

14、ting Context:When this pattern has been successfully completed, basic information required for the development of an analysis model has been acquired and documented in some manner. Use-cases (user scenarios) have been developed, along with basic descriptions of system function and behavior and the d

15、ata objects that are to be manipulated and/or produced/Related Patterns: Conducted a meeting; requirement gathering; developing use-cases; building a mini-spec; negotiating requirements, prioritization. Known Uses/Examples: Communication is mandatory at the beginning of every software project; is re

16、commended throughout the software project; and is mandatory once the deployment activity is underway.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 pr

17、actice 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 objec

18、tives of the process (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 com

19、munication 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 unce

20、rtain 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 fun

21、ction 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 waysthe continuous and the staged model. The pros of the CMMI: comprehensive, addressing virtual

22、ly 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

23、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 proces

24、s 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 fr

25、amework activities are applied for all projects, regardless of the projects 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 t

26、hat 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 ne

27、cessarily 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 even

28、ly 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 as

29、k 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 didnt

30、? 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 featu

31、res 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 Ill really need? Have I set deadlines that are unrealistic? Am I unsure of certain functions and feat

32、ures? 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

33、 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

34、.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

35、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)

36、 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 practitione

37、r 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 33.1)Any software project that has significant functionality that must be delivered in a very tight (too tight) time fram

38、e 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 functionalitynew and improved versions to follow! For example, word-processing software developed usi

39、ng 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 c

40、apability 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 waterfa

41、ll 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) its unlikely that major changes in requirements will be requested as the project proceeds. Specific examples might be:

42、(1) a well understood modification to an existing program; (2) a straightforward implementation of a numerical calculation or business rule, even if its 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 rig

43、orous 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 f

44、or 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

45、 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 p

46、rototype 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

47、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 chao

48、tic 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

49、 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. Thats OK as long as the word “good” is emphasized.3.7)