软件工程课后习题答案.doc

软件工程课后习题答案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 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 22.1)Pattern: 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 communication (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 areas 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.Resulting 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 data 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 recommended 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 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 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 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 waysthe 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 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 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 didnt? 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 Ill 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 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 functionalitynew 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) its 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 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 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. Thats 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 flawsthe 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.” a3.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 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 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 sy