Skip to content
Textbook Guides

Solution Manual for Software Engineering: A Practitioner's Approach, 9th Edition

Learn faster with Solution Manual for Software Engineering: A Practitioner's Approach, 9th Edition, a complete textbook breakdown tailored for students.

Preview 16 of 107 pages

See the first 16 pages exactly as they appear in the document.

  1. Page 1
    Read page 1 as text

    S olutions: Chapter 1: S oftware and Software Engineering 1.1) Classic examples include the use of "digital automobile dashboards" to impart a high tech, high quality images. Appliances that "think;" the broad array of consumer electronics; personal computers (today, differentiated more by their software function than the hardware), industrial instrumentation and machines. All e - commerce applications are differentiated by software. 1.2) This is a good problem for classroom discussion (time permitting). Rather than focusing on cliché' ridden (albeit important) issues of privacy, quality of life, etc., you might want to discuss "techno fright" and how software can help to exacerbate or reme dy it. Another interesting possibility is to use Neumann's "Risks" column in SEN to key discussion. You might also consider new attempts at software - based ‘cash’ economies, new modes of interactive entertainment, virtual reality, e - commerce, etc. 1.3) It takes software so long to be finished , because of following reasons a) Facilities are not available on line. b) Development tools do not work as expected. c) Customer insists on the new requirements, requiring redesign and rework. d) Product depends on the government regulations that change unexpectedly. e) Strict requirements for compatibility with existing system require more testing, design, and implementation then expected. f) Requirements to operate under multiple operating systems take longer to satisfy than expected. g) Software project risk management takes more time then expected. h) Dependency on a technology that is still under development lengthens the schedule. Development costs are high : a) Unacceptably low quality requires more testing, design and implementation work to correct then expected. b) Development of the wrong software functions requires redesign and implementation. c) Development of the wrong user interface results in redesign and implementation. d) Development of extra software functions that are not required extends the schedule. We can’t find errors before we give the software to our customer because of the following reasons; a) Product depends on government regulation, which changes unexpectedly. b) Product depends on draft technical standards, which change unexpectedly. c) New development personnel sometimes are added late in the project.

  2. Page 2
  3. Page 3
    Read page 3 as text

    d) Conflicts within teams sometimes results in poor communication and hence poor design e) Sabotage by project management results in efficient scheduling and ineffective planning. f) Sometimes the furnished components are poor quality resulting in extra testing, design and integration work and in extra customer – relationship management. We continue to have difficulty in measuring progress as software is developed as; a) Sometimes the purpose of the project is not clear. b) There are a lot of business risks involved. c) If the product built is not fitted well. d) We need to review our work continuously. e) A time check has to be maintained. f) Project team has to be thorough and organized throughout the process. 1.4) Many modern applications change frequently before they are presented to the end user and then after the first versions have been used. The few ways to build software to stop deterioration due to change would be: Gather the required information. Designer and customer define the overall objectives for the software. Identify the known requirements. After building a prototype the developer uses an existing program fragment, this will help the working program to complete quickly. To maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations. Documents should be developed in a timely manner, to do this documentation standards are defined and mechanisms are established. Review works done up to a particular stage. There should be a backup person for every critical team member. Check whether the risk aversion steps are being properly applied or not. Check whether the necessary information for future risk analysis is necessary to collect. 1.5) The same approach to software engineering can be applied for each of the seven categories. Each of these “new challenges” will undoubtedly have effects (for business people, software engineers, and end - users) that cannot be predicted today. However, software engineers can prepare by instantiating a process that is agile and adaptable enough to a ccommodate dramatic changes in technology and business rules that are sure to come over the next decade. 1.6) 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

  4. Page 4
    Read page 4 as text

    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.7) Process framework is applicable to all the projects; hence the same work tasks are applied for all projects, regardless of their size or complexity. A process framework involves heavy communication with the customer to gather requirements; this activity es tablishes 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 test ing). It finally provides feedback based on the evaluation. 1.8) The umbrella activities occur throughout the software process they are applied evenly across the process, the analysis encompass a set of work tasks ( eg . requirement gathering, elaboration, negotiation specification and validation ) . A process framework has a set of umbrella activities that are applicable across the entire software process. These activities include Software project tracking and control, Risk management, Software quality assurance, and formal technical reviews, measur ement, Software configura tion management, reusability management and work product preparation and production.

  5. Page 5
    Read page 5 as text

    Solutions: Chapter 2 : Process Models . 2 .1) a) Designers should ask users: Is the product satisfactory, or does it require redesign or rework? Was user input solicited, to avoid the product being unsatisfactory and requiring rework? Is there a need for new requirements? Is the product larger than estimated? Do the modules require more testing, design and implemen t ation work to correct tha n expected? b) Users should ask as designers: Is the scope clear? Do we have the tools and people with skills required for the development? Are the requirements properly defined, are additional requirements needed. Are the specified areas of the product more time consuming than usual? Does the module require more testing, design? c) Users should ask themselves about the software product that is to be built: What is the scope and purpose of the software product? Is the product larger than estimated? Are the best people available? Is the staff committed and possess skills required? Will the turnover among staff members be low enough to allow continuity? d) Designers should ask themselves about software product that is to be built and the process that will used to build it: Scope and purpose of the document? What tools are to be used? What are the objectives and risk aversion priorities? What will be the steps for risk analysis, identification, estimation, and evaluation and management? 2 .2) a) Linear process flow does not accommodate change well, but can be good if a team is building a routine product similar to something they have done before b) Iterative process flow handles change better by building in opportunities to reviews the intermediate work products as they are developed. Often used when building systems involving technologies that are new to the development team. c) Evolutionary process models are often adopted for projects (e.g. WebApps) that need to be developed in a rapid, but controlled manner that avoids unnecessary rework. d) Parallel process flow has the potential to allow self - contained work products to be developed simultaneously for systems that are composed of subsystems.

  6. Page 6
    Read page 6 as text

    2 .3) Task Set for Communication Activity: A task set would define the actual work t o be done to accomplish the objectives of a software engineering action. For the communication activity these are: Make a list of stakeholders for the project Invite all the stakeholders to an informal meeting Ask them to make a list of features and functions Discuss requirements and build a final list Prioritize requirements and note the areas that he is uncertain of These tasks may be larger for a complex software project, they may then include 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 prio ri tize the requirements. Note constraints and restrictions on the system. Discuss methods for validating system. 2 . 4) Pattern Name. Conflicting Stakeholder Requirements Intent. This pattern describes an approach for resolving conflicts between stakeholders during the communication framework activity. Type. Stage pattern Initial context. (1) Stakeholders have been identified; (2) Stakeholders and software engineers have established a collaborative communication; (3) overriding software problem to be solved by the software teams has been established; (4) initial understandi ng of project scope, basic business requirements and project constraints has been developed. Problem. Stakeholders request mutually conflicting features for the software product under development. Solution. All stakeholders asked to prioritize all known system requirements, with resolution being to keep the stakeholder requirements with highest priorities and/or the most votes. Resulting Context. A prioritized list of requirements approved by the stakeholders is established to guide the software team in the creation of an initial product prototype. Related Patterns. Collaborative - guideline definition, Scope - isolation, Requirements gathering, Constraint Description, Requirements unclear Known Uses/Examples. Communication is mandatory throughout the software project.

  7. Page 7
    Read page 7 as text

    2.5) The waterfall model is amenable to the projects that focus on the attributes such as the data structures, software architecture, and procedural detail and interface characterization of objects. 2.6) 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 difficult to prototype include control and process control functions, many classes of real - time applications and emb edded software. 2.7) 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). 2.8) The 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 delivery/feedback. 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 Sp iral model may be efficient. Special process models take on many of the characteristics of one or more of the tradition. 2.9) The advantages of developing software in which quality is ”good enough” is that the product or software will meet the deadline, it may however lead to the delivery of software that is low in quality and requires time to improper the quality. When speed is emphasized over the product quality it may lead to many flaws, the software may require more testing, design and implementation work then done. Requirements may be poorly defined and may need to continuously change. Half hearted and speed may cause the ris k management to fail to detect major project risks .Too little quality may result in quality problems and later rework.

  8. Page 8
    Read page 8 as text

    2.10) 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. 2.11) UML provides the necessary technology to support object - oriented software engineering practice, but it does not provide the process framework to guide project teams in their application of the technology. Over the next few years, Jacobs on, Rumbaugh and Booch developed the Unified Process , a framework for object - oriented software engineering using UML. Today, the Unified Process and UML are widely used on OO projects of all kinds.

  9. Page 9
    Read page 9 as text

    Solutions: CHAPTER 3 : PROCESS AND AGILITY 3 .1) One situation in which one or more of the four “values” could get a software team into trouble would be Responding to change over following a plan, In many situations, we no longer are able to define requirements fully before the project begins. Software engineers must be agile enough to respond to a fluid business environment or else they might land up in trouble. 3 .2) Agility can be applied to any software process. However, to accomplish this, it is essential that the process be designed in a way that allows the project team to adapt tasks and to streamline them, conduct planning in a way that understands the fluidity of an agile development approach, eliminate all but the most essential work products and keep them lean, and emphasize an incremental delivery strategy that gets working software to the customer as rapidly as feasible for the product type and operational environment. 3 .3) Both iterative and a gile process models deliver software increments followed by customer feedback and revision. Because the increments are small and the customer feedback is prompt, it is relatively easy to incorporate the changes in the next software increment. Yes, f or example, XP is an iterative process that incorporate s adaptive cycle planning, relatively rigorous requirement gathering methods, and an iterative development cycle that incorporates customer focus groups and formal technical reviews as real - time feedback mechanisms. It is possible but unlikely that anything but a trivial project would be completed in one iteration or sprint. 3 . 4 ) One more “agility principle” that would help a software engineering team become ev en more maneuverable would be, “A team should know whose skills suit a particular project, and get these people on their project, for software development to become more effective”, and ”Communication is the key, the consumer and developer should constantly be communicating even if they are geographically separated, they can web talk”. 3 . 5 ) Requirements change so much, that it is difficult to predict in advance which software requirements will persist and which will change. It is equally difficult to predict how customer priorities will change as the project proceeds. It is often difficult for people to verbalize their software needs until they see a working prototype and realize that they had forgotten to consider something important. 3 . 6 ) Most agile process models recommend face - to - face communication. Yet today, members of a software team and their customers may be geographically separated from one another in that case Communication is the key, the consumer and developer should constantly be communicating even if they are geographically separated, they can webtalk or talk over the phone every now and then or write emails, use chatting as the, means or a medium of conference call communication where 2 and more people can talk to each other at the same time.

  10. Page 10
    Read page 10 as text

    3 . 7 ) Answers will vary 3 . 8 ) XP encourages refactoring — a construction technique that is also a design technique. Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves the internal structure. A central notion in XP is that design occurs both before and after coding commences. Refactoring means that design occurs continuously as the system is constructed a key concept during the coding activity is pair programming. XP recommends that two people work together at one computer workstation to create code for a story. This provides a mechanism for real - time problem solving (two heads are often better than one) and real - time quality assurance.

  11. Page 11
    Read page 11 as text

    Solution: Chapter 18 : SOFTWARE SECURITY ENGINEERING 4 .1 The spiral model can be thought of as an evolutionary prototyping model with risk assessment element, the goal is to create an extensible prototype each time the process is iterated, early testing is essential. In XP the stakeholders and developers work together to group the most important user stories into a prototype that will become the next release of the software and determine its completion date. 4 .2 A nswers will vary. 4 .3 A nswers will vary. 4 .4 The best way to get historic data is from measures made during the completion of similar projects done previously by the same development team. Alternatively you might be able to find useful historic data from searching the internet for similar projects th at ma y have been documented in public software repositories. 4 .5 Answers will vary. 4 . 6 Answers will vary . 4 .7 Determine values of the quality measures selected foe the current prototype, the revised times and cost estimates, and assess the risk of failing to meet stakeholder expectations. 4 .8 Reactive maintenance activities involve changes to software to repair problems discovered after delivery to customers or to adapt it to changes made to the run - time environment after deployment. Proactive maintenance activities are scheduled and planned for in an attempt to make changes to the software before customers experience any problems – this includes improving software quality and removing defects before users report them .

  12. Page 12
    Read page 12 as text

    Solutions: CHAPTER 5 : HUMAN ASPECTS OF SOFTWARE ENGINEERING 5 .1) Answers will vary. 5 .2) Using agreed upon standards and written requirements as the basis of feedback to team member helps to make comment about a work product deficiency makes it less personal to its creator. 5 .3) Communication barriers are often created by allowing individuals to operate without coordinating their activities with fellow team members. Requiring team members to communicate only through the team leader is never a good idea. 5 . 4 ) Answers will vary. 5 . 5 ) Distance can make it harder to get in touch with team members (e.g. there may be 12 or more hour difference in time of day). Team members living in different countries have different experiences, different cultural expectations, and may speak different l anguages. Coordination efforts become paramount in importance to the success of the project. Effective communication requires a message to be sent, to be received, and to be responded to. Any one of this points of failure can prevent effective exchange of information among team members and stakeholders.

  13. Page 13
    Read page 13 as text

    Solutions Chapter 6 : PRINCIPLES THAT GUIDE PRACTICE 6 .1) It is possible to be agile and maintain a quality focus, if the team focus is to deliver the best possible increment to customer and to react to the customer feedback in a responsible manner. 6 .2 ) Answers will vary 6 .3) A large problem is easier to solve if it is subdivided in to a collection of elements each of which delivers a distinct functionality that can be developed, and in some cases validated, independently of other concerns. 6 . 4 ) It is necessary to “move on” because communication , like any software engineering activity, takes time. Rather than iterating endlessly, the people who participate should recognize that many topics require discussion and that “moving on” is sometimes the best way to achieve communication agility. 6 . 5 ) ” Negotiation” for the communication activity works best when both parties win. Sets of guidelines that focus solely on negotiation are many instances in which the software engineer and the customer must negotiate functions and features, priorities, and deli very dates. If the team has collaborated well, all parties have a common goal. Therefore, negotiation will demand compromise from all parties. 6 . 6 ) The software design model is the equivalent of an architect’s plans for a house. It begins by representing the totality of the thing to be built (e.g., a three - dimensional rendering of the house) and slowly refines the thing to provide guidance for constru cting each detail (e.g., the plumbing layout). Similarly, the design model that is created for software provides a variety of different views of the system, hence it is always necessary. 6 . 7 ) A successful test is one that uncovers an as - yet - undiscovered error. 6.8 ) Feedback is important to the software team, because it provides the information that can be used to correct modeling mistakes, change misinterpretations, and add features or functions that were inadvertently omitted.

  14. Page 14
    Read page 14 as text

    Solution Ch apter 7 : UNDERSTANDING REQUIREMENTS 7 .1) Understanding the requirements of a problem is among the most difficult tasks that a software engineer face since requirements change continuously, hence they tend to pay little attention to it. In some cases, an abbreviated approach may be chosen. In others, every task defined for comprehensive requirements engineering must be performed rigorously. Requirements engineering builds a bridge to design and construction and cannot be skipped. 7 .2 ) 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 ta ble 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. 7 .3 ) 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 negotia tion 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, this rarely happens, each custome r has his own views. These views donot match each customer, time is another constraint that matters, each customer may not have time to meet the developer and give the requirements, this further increases the problem. 7 . 4 ) Answers will vary 7 . 5 ) Answers will vary 7 . 6 ) Answers will vary 7 . 7 ) Answers will vary 7 . 8 ) Answers will vary 7 . 9 ) A “Win - Win situation is where 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 .1 0 ) When the requirement validation uncovers an error, it has each requirement against a set of checklist questions. It then has a review team looking into it. The review team includes software engineers, customers, users, and other stakeholders who examine the specification looking for errors in content or interpretation, areas where clarification may

  15. Page 15
    Read page 15 as text

    be required, missing information, inconsistencies (a major problem when large products or systems are engineered), conflicting requirements, or unrealistic (unachievable) requirements.

  16. Page 16
    Read page 16 as text

    Solutions Chapter 8 : MODELING REQUIREMENTS MODE LING – A RECOMMENDED APPROACH 8 .1) 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. 8 .2) As we know that complete specification of requirements may not be possible at the start stage. The customer may be unsure of precisely what is required. The developer may be unsure that a specific approach will properly accomplish function and performa nce. These realities mitigate in favor of an iterative approach to requirements analysis and modeling. The analyst should model what is known and use that model as the basis for design of the software increment that is produced as part of process iteratio n. The types of requirements are not visible in these domains may be what functions must the system perform, what behaviors does the system exhibit, what interfaces, are attributes defined, and what constraints apply? 8 . 3 ) Answers will vary 8 . 4 ) Answers will vary 8 . 5 ) Answers will vary 8 . 6 ) Answers will vary 8.7) Answers will vary 8.8) Answers will vary 8.9) Answers will vary 8.10) State diagrams depict the state of the system and show how events affect system states. Sequence diagrams indicate how events cause transitions from object to object.

91 more pages in the full document

Unlock it once and it stays in your library, ready to chat with or turn into flashcards.

Unlock the full document

More Information Technology study materials

See all

Study this document with CramX

Once it is in your library, every tool can work from it.