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

Page 1 of 16

Solution Manual for Software Engineering: A Practitioner's Approach, 9th Edition - Page 1 preview image

Solutions: Chapter 1: Softwareand Software Engineering1.1)Classic examples include the use of "digital automobile dashboards" to impart a hightech, high quality images. Appliances that "think;" the broad array of consumerelectronics; personal computers (today, differentiated more by their software functionthan the hardware), industrial instrumentation and machines. All e-commerceapplications are differentiated by software.1.2)This is a good problem for classroom discussion (time permitting). Rather thanfocusing 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 exacerbateor remedy it. Another interesting possibility is to use Neumann's "Risks" column inSEN to key discussion. You might also consider new attempts at software-based‘cash’economies,newmodesofinteractiveentertainment,virtualreality,e-commerce, etc.1.3)It takes software so long to be finished, because of following reasonsa)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 moretesting, design, and implementation then expected.f)Requirements to operate under multiple operating systems take longer tosatisfy than expected.g)Software project risk management takes more timethen expected.h)Dependency on a technology that is still under development lengthens theschedule.Development costs are high:a)Unacceptablylowqualityrequiresmoretesting,designandimplementation work to correct then expected.b)Development of the wrong software functions requires redesign andimplementation.c)Developmentofthewronguser interface results inredesignandimplementation.d)Development of extra software functions that are not required extendsthe schedule.We can’t find errors before we give the software to our customer because ofthe following reasons;a)Product depends on government regulation, which changes unexpectedly.b)Productdependsondrafttechnicalstandards,whichchangeunexpectedly.c)New development personnel sometimes are added late in the project.

Page 2 of 16

Solution Manual for Software Engineering: A Practitioner's Approach, 9th Edition - Page 2 preview image

Page 3 of 16

Solution Manual for Software Engineering: A Practitioner's Approach, 9th Edition - Page 3 preview image

d)Conflicts within teams sometimes results in poor communication andhence poor designe)Sabotage by project management results in efficient scheduling andineffective planning.f)Sometimes the furnished components are poor quality resulting in extratesting, design and integration work and in extra customer–relationshipmanagement.We continue to have difficulty in measuring progress as software isdeveloped 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 enduser and then after the first versions have been used. The few ways to build softwareto 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 willhelp the working program to complete quickly.To maintain and improve our technical competence and to undertake technologicaltasks for others only if qualified by training or experience, or after full disclosure ofpertinent limitations.Documents should be developed in a timely manner, to do this documentationstandards 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 tocollect.1.5)The same approach to software engineering can be applied for each of the sevencategories.Each of these “new challenges” will undoubtedly have effects (forbusiness people, software engineers, and end-users) that cannot be predicted today.However, software engineers can prepare by instantiating a process that is agile andadaptable enough to accommodate dramatic changes in technology and business rulesthat 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

Page 4 of 16

Solution Manual for Software Engineering: A Practitioner's Approach, 9th Edition - Page 4 preview image

that have contributed to plane crashes, computer viruses (e.g., Michelangelo) thathave 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 areapplied for all projects, regardless of their size or complexity. A process frameworkinvolves heavy communication with the customer to gather requirements; thisactivity establishes a plan for the software engineering work that follows. It involvescreation of models that will assist the developer and the customer to understand therequirements and design them; it thereby involves construction (code generation anderror testing). It finally provides feedback based on the evaluation.1.8)The umbrellaactivities occur throughout the software process they are applied evenlyacross the process, the analysis encompass a set of work tasks(eg.requirementgathering,elaboration,negotiationspecificationandvalidation).Aprocessframework has a set of umbrella activities that are applicable across the entiresoftware process. These activities include Software project tracking and control, Riskmanagement,Softwarequalityassurance,andformaltechnicalreviews,measurement, Software configuration management, reusability management andwork product preparation and production.

Page 5 of 16

Solution Manual for Software Engineering: A Practitioner's Approach, 9th Edition - Page 5 preview image

Solutions: Chapter2:ProcessModels.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 requiringrework?Is there a need for new requirements?Is the product larger than estimated?Do the modules require more testing, design andimplementation work to correctthan 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 theprocess 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 evaluationand management?2.2)a)Linear process flow does not accommodate change well, but can be good if ateam is building a routine product similar to something they have done beforeb)Iterative process flow handles change better by building in opportunities toreviews the intermediate work products as theyare developed. Often used whenbuilding systems involving technologies that are new to the development team.c)Evolutionary process models are often adopted for projects (e.g. WebApps) thatneed to be developed in a rapid, but controlled manner that avoids unnecessaryrework.d)Parallel process flow has the potential to allow self-contained work productstobe developedsimultaneouslyfor systems that are composed of subsystems.

Page 6 of 16

Solution Manual for Software Engineering: A Practitioner's Approach, 9th Edition - Page 6 preview image

2.3)Task Set for Communication Activity: A task set would define the actual worktobe done to accomplish the objectives of a software engineering action. For thecommunication activity these are:Make a list of stakeholders for the projectInvite all the stakeholders to an informal meetingAsk them to make a list of features and functionsDiscuss requirements and build a final listPrioritize requirements and note the areas that he is uncertain ofThese tasks may be larger for a complex software project, they may thenincludeTo conduct a series of specification meetings, build a preliminary list offunctions and features based on stakeholder input.To build a revised list of stake holder requirementsUse quality function deployment techniques to prioritize the requirements.Note constraints and restrictions on the system.Discuss methods for validating system.2.4)Pattern Name.Conflicting Stakeholder RequirementsIntent. This pattern describes an approach for resolving conflicts between stakeholdersduring the communication framework activity.Type. Stage patternInitial context. (1) Stakeholders have been identified; (2) Stakeholders and softwareengineers have established a collaborative communication; (3) overriding softwareproblem to be solved by the software teams has been established; (4) initialunderstanding of project scope, basic business requirements and project constraintshas been developed.Problem. Stakeholders request mutually conflicting features for the software product underdevelopment.Solution. All stakeholders asked to prioritize all known system requirements, withresolution being to keep the stakeholder requirements with highest priorities and/orthe most votes.Resulting Context. A prioritized list of requirements approved by the stakeholders isestablished to guide the software team in the creation of an initial productprototype.RelatedPatterns.Collaborative-guidelinedefinition,Scope-isolation,Requirementsgathering, Constraint Description, Requirements unclearKnown Uses/Examples. Communication is mandatory throughout the software project.

Page 7 of 16

Solution Manual for Software Engineering: A Practitioner's Approach, 9th Edition - Page 7 preview image

2.5)The waterfall model is amenable to the projects that focus on the attributes such asthe data structures, software architecture, and procedural detail and interfacecharacterization of objects.2.6)Software applications that are relatively easy to prototype almost always involvehuman-machine interaction and/or heavy computer graphics. Other applicationsthat are sometimes amenable to prototyping are certain classes of mathematicalalgorithms, subsetof command driven systems and other applications where resultscan be easily examined without real-time interaction. Applications that are difficultto prototype include control and process control functions, many classes of real-time applications and embedded software.2.7)As work moves outward on the spiral, the product moves toward a more completestate and the level of abstraction at which work is performed is reduced (i.e.,implementation specific workaccelerates as we move further from the origin).2.8)The process models can be combined,each model suggests a somewhat differentprocess flow, but all perform the same set of generic framework activities:communication, planning, modeling, construction, and delivery/feedback.For example the linear sequential modelcan serve as a useful process model insituations where requirements are fixed and work is to proceed to completion ina linear manner. In cases, where the developer may be unsure of the efficiency ofan algorithm, the adaptability of an operating system,or the form that human-machineinteractionshouldtake.Inthese,andmanyothersituations,aprototyping model may offer the best approach. In other cases, an incrementalapproach may make sense and the flow of Spiral model may be efficient.Specialprocess 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 thatthe product or software will meet the deadline, it may however lead to the deliveryof software that is low in quality and requires time to improper the quality. Whenspeed isemphasized over the product quality it may lead to many flaws, thesoftware may require more testing, design and implementation work then done.Requirements may be poorly defined and may need to continuously change. Halfhearted and speed may cause the risk management to fail to detect major projectrisks .Too little quality may result in quality problems and later rework.

Page 8 of 16

Solution Manual for Software Engineering: A Practitioner's Approach, 9th Edition - Page 8 preview image

2.10)It is possible to use mathematical techniques to prove the correctness of softwarecomponents and even entire programs (see Chapter 28). However, for complexprograms this is a very time consuming process. It is not possible to prove thecorrectness of anynon-trivial program using exhaustive testing.2.11)UML provides the necessary technology to support object-oriented softwareengineering practice, but it does not provide the process framework to guideproject teams in their application of the technology. Over the next few years,Jacobson, Rumbaugh and Booch developed theUnified Process, a frameworkfor object-oriented software engineering using UML. Today, the UnifiedProcess and UML are widely used on OO projects of all kinds.

Page 9 of 16

Solution Manual for Software Engineering: A Practitioner's Approach, 9th Edition - Page 9 preview image

Solutions: CHAPTER3:PROCESS AND AGILITY3.1)Onesituation in which one or more of the four “values” could get a software teaminto trouble would beResponding to change over following a plan,In many situations,we no longer are able to define requirements fully before the project begins. Softwareengineers must be agile enough to respond to a fluid business environment or else theymight land up in trouble.3.2) Agility can be applied to any software process. However, to accomplish this, it isessential that the process be designed in a way that allows the project team to adapt tasksand to streamline them, conduct planning in a way that understands the fluidity of anagile development approach, eliminate all but the most essential work products and keepthem lean, and emphasize an incremental delivery strategy that gets working software tothe customer as rapidly as feasible for the product type and operational environment.3.3)Both iterative and agile process models deliver software increments followed bycustomer feedback and revision. Because the increments are small and the customerfeedback is prompt, it is relatively easy to incorporate the changes in the next softwareincrement.Yes, for example,XPisan iterative process that incorporatesadaptive cycleplanning,relativelyrigorousrequirementgatheringmethods,andaniterativedevelopment cycle that incorporates customer focus groups and formal technical reviewsas real-time feedback mechanisms.It is possible but unlikely that anything but a trivialproject would be completed in one iteration or sprint.3.4)One more “agility principle” that would help a software engineering team becomeeven more maneuverable would be,“Ateam should know whose skills suit a particularproject, and get these people on their project, for software development to become moreeffective”,and”Communicationisthekey,theconsumeranddevelopershouldconstantly be communicating even if they are geographically separated, they can webtalk”.3.5)Requirements change so much,that it is difficult to predict in advance whichsoftware requirements will persist and which will change. It is equally difficult to predicthow customer priorities will change as the project proceeds. It is often difficult for peopleto verbalize their software needs until they see a working prototype and realize that theyhad 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 fromone another in that caseCommunication is the key, the consumer and developer shouldconstantly be communicating even if they are geographically separated, they can webtalkor talk over the phone every now and then or write emails, use chatting as the, means or amedium of conference call communication where 2 and more people can talk to eachother at the same time.

Page 10 of 16

Solution Manual for Software Engineering: A Practitioner's Approach, 9th Edition - Page 10 preview image

3.7) Answers will vary3.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 notalter the external behavior of the code yet improves the internal structure. A centralnotion in XP is that design occurs both before and after coding commences. Refactoringmeans that design occurs continuously as the system is constructed a key concept duringthe coding activity is pair programming. XP recommends that two people work togetherat one computer workstation to create code for a story. This provides a mechanism forreal-time problem solving (two heads are often better than one) and real-time qualityassurance.

Page 11 of 16

Solution Manual for Software Engineering: A Practitioner's Approach, 9th Edition - Page 11 preview image

Solution: Chapter18:SOFTWARESECURITY ENGINEERING4.1The spiral model can be thought of as an evolutionary prototyping modelwith risk assessment element, the goal is tocreate an extensible prototypeeach time the process is iterated, early testing is essential.In XP thestakeholders and developers work together to group the most importantuser stories into a prototype that will become the next release of the softwareand determine its completion date.4.2Answers will vary.4.3Answers will vary.4.4The best way to get historic data is from measures made during the completion ofsimilar projects done previously by the same development team. Alternatively youmight be able to find useful historic data from searching the internet for similarprojects that mayhave been documented in public software repositories.4.5Answers will vary.4.6Answers will vary.4.7Determine values of the quality measures selected foe the current prototype, therevised times and cost estimates, and assess the risk of failing to meet stakeholderexpectations.4.8Reactive maintenance activities involve changes to software to repair problemsdiscovered after delivery to customers or to adapt it to changes made to the run-timeenvironmentafter deployment. Proactive maintenance activities are scheduled andplanned for in an attempt to make changes to the software before customersexperience any problems–this includes improving software quality and removingdefects before users report them.

Page 12 of 16

Solution Manual for Software Engineering: A Practitioner's Approach, 9th Edition - Page 12 preview image

Solutions: CHAPTER5:HUMAN ASPECTS OF SOFTWARE ENGINEERING5.1)Answers will vary.5.2) Using agreed upon standards and written requirements as the basis of feedback to teammember helps to make comment about a work product deficiency makes it less personal toits creator.5.3)Communication barriers are often created by allowing individuals to operate withoutcoordinating their activities with fellow team members. Requiring team members tocommunicate 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 12or more hour difference in time of day). Team members living in different countries havedifferent experiences, different cultural expectations, and may speak different languages.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 respondedto. Any one of this points of failurecan prevent effective exchangeof information amongteam members and stakeholders.

Page 13 of 16

Solution Manual for Software Engineering: A Practitioner's Approach, 9th Edition - Page 13 preview image

Solutions Chapter6: PRINCIPLES THAT GUIDE PRACTICE6.1)It is possible to be agile and maintain a quality focus, if the team focus is to deliverthe best possible increment to customerand to react to the customer feedback in aresponsible manner.6.2)Answers will vary6.3)A large problem is easier to solve if it is subdivided into a collection of elementseach of whichdeliversadistinct functionality that can be developed, and in some casesvalidated, independently of other concerns.6.4) It is necessary to “move on” because communication, like any software engineeringactivity, takes time. Rather than iterating endlessly, the people who participate shouldrecognize that many topics require discussion and that “moving on” is sometimes the bestway to achieve communication agility.6.5) ”Negotiation” for the communication activity works best when both parties win. Setsof guidelines that focus solely on negotiation are many instances in which the softwareengineer and the customer must negotiate functions and features, priorities, and deliverydates. 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. Itbegins by representing the totality of the thing to be built (e.g., a three-dimensionalrendering of the house) and slowly refines the thing to provide guidance for constructingeach detail (e.g., the plumbing layout). Similarly, the design model that is created forsoftware 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 itprovides the information thatcan be used to correct modeling mistakes, change misinterpretations, and add features orfunctions that were inadvertently omitted.

Page 14 of 16

Solution Manual for Software Engineering: A Practitioner's Approach, 9th Edition - Page 14 preview image

Solution Chapter7: UNDERSTANDING REQUIREMENTS7.1) Understanding the requirements of a problem is among the most difficult tasks that asoftware engineer face since requirements change continuously, hence they tend to paylittle attention to it. Insome cases, an abbreviated approach may be chosen. In others, everytask defined for comprehensive requirements engineering must be performed rigorously.Requirements engineering builds a bridge to design and construction and cannot beskipped.7.2) You might try using an approach like QFD that makes use customer interviews andobservation, surveys, and examination of historical data (e.g., problem reports) as raw datafor the requirements gathering activity. These data are then translated into a table ofrequirements—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 expectedrequirements.7.3) In reality, the customer and the developer enter into a process of negotiation, wherethe customer may be asked to balance functionality, performance, and other product orsystem characteristics against cost and time to market. The intent of this negotiation is todevelop a project plan that meets the needs of the customer while at the same time reflectingthe real-world constraints (e.g., time, people, budget) that have been placed on the softwareteam, Unfortunately, this rarely happens, each customer has his own views. These viewsdonot match each customer, time is another constraint that matters, each customer may nothave time to meet the developer and give the requirements, this further increases theproblem.7.4) Answers will vary7.5) Answers will vary7.6) Answers will vary7.7) Answers will vary7.8) Answers will vary7.9) A “Win-Win situation is where the customer wins by getting the system or productthat satisfies the majority of the customer’s needs and the software team wins by workingto realistic and achievable budgets and deadlines.7.10) When the requirement validation uncovers an error, it has each requirement againsta set of checklist questions. It then has a review team looking into it. The review teamincludes software engineers, customers, users, and other stakeholders who examinethespecification looking for errors in content or interpretation, areas where clarification may

Page 15 of 16

Solution Manual for Software Engineering: A Practitioner's Approach, 9th Edition - Page 15 preview image

be required, missing information, inconsistencies (a major problem when large products orsystemsareengineered),conflictingrequirements,orunrealistic(unachievable)requirements.

Page 16 of 16

Solution Manual for Software Engineering: A Practitioner's Approach, 9th Edition - Page 16 preview image

Solutions Chapter8:MODELINGREQUIREMENTS MODELING–ARECOMMENDED APPROACH8.1) The analysis model will serve as the basis for design and construction of the domainobjects. It is possible to begin coding after the objects and attributes are defined, andrelationships are known.8.2) As we know that complete specification of requirements may not be possible at thestart stage. The customer may be unsure of precisely what is required. The developer maybe unsure that a specific approach will properly accomplish function and performance.These realities mitigate in favor of an iterative approach to requirements analysis andmodeling. The analyst should model what is known and use that model as the basis fordesign of the software increment that is produced as part of process iteration. The types ofrequirements are not visible in these domains may be what functions must the systemperform, what behaviors does the system exhibit, what interfaces, are attributes defined,and what constraints apply?8.3)Answers will vary8.4) Answers will vary8.5) Answers will vary8.6) Answers will vary8.7) Answers will vary8.8) Answers will vary8.9) Answers will vary8.10) State diagrams depict the state of the system and show how events affect systemstates. Sequence diagramsindicate how events cause transitions from object to object.

Preview Mode

This document has 107 pages. Sign in to access the full document!

Report

Learning Tools

Writing Tools

Browse Resources

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

Study Now!

Document Details

Related Documents

DevOps and Its Importance Study Notes

Veeam Certified Engineer VMCE-V12

Modules 1 - 3 Basic Network Connectivity and Commu

Notes CCNA

CCNA 200-301 Portable Command Guide 5th Edition 20

CCNA 200-301 Portable Command Guide 5th Edition 22

CCNA 200-301 Portable Command Guide 5th Edition 36

Foundations of Novell Networking Section 26

Modulo 7 DHCPv4

Build and troubleshooting Integration Challenge

Company

Explore

Study Tools