Solution Manual For Software Engineering, 10th Edition

Page 1 of 16

Solution Manual For Software Engineering, 10th Edition - Page 1 preview image

Software Engineering 10 – Solutions Manual1Software Engineering 10Solutions ManualIANSOMMERVILLE

Page 2 of 16

Solution Manual For Software Engineering, 10th Edition - Page 2 preview image

Page 3 of 16

Solution Manual For Software Engineering, 10th Edition - Page 3 preview image

Software Engineering 10 – Solutions Manual2

Page 4 of 16

Solution Manual For Software Engineering, 10th Edition - Page 4 preview image

Software Engineering 10 – Solutions Manual41Introduction1.2What is the most important difference between generic software productdevelopment and custom software development? What might this mean inpractice for users of generic software products?The essential difference is that in generic software product development, thespecification is owned by the product developer. For custom product development,the specification is owned and controlled by the customer. The implications of thisare significant – the developer can quickly decide to change the specification inresponse to some external change (e.g. a competing product) but, when thecustomer owns the specification, changes have to be negotiated between thecustomer and the developer and may have contractual implications.For users of generic products, this means they have no control over thesoftware specification so cannot control the evolution of the product. The developermay decide to include/exclude features and change the user interface. This couldhave implications for the user’s business processes and add extra training costswhen new versions of the system are installed. It also may limit the customer’sflexibility to change their own business processes.1.3What are the four important attributes that all professional software shouldhave? Suggest four other attributes that may sometimes be significant.Fourimportantattributesaremaintainability,dependability,performanceandusability. Other attributes that may be significant could be reusability (can it bereused in other applications), distributability (can it be distributed over a networkof processors), portability (can it operate on multiple platforms e.g laptop andmobile platforms) and inter-operability (can it work with a wide range of othersoftware systems).Decompositions of the 4 key attributes e.g. dependability decomposes to security,safety, availability, etc. is also a valid answer to this question.

Page 5 of 16

Solution Manual For Software Engineering, 10th Edition - Page 5 preview image

Software Engineering 10 – Solutions Manual51.4Apart from the challenges of heterogeneity, business and social change andtrust and security, identify other problems and challenges that softwareengineering is likely to face in the 21st century (hint: think about theenvironment).Problems and challenges for software engineeringThere are many possible challenges that could be identified. These include:1.Developing systems that are energy-efficient. This makes them more usableon low power mobile devices and helps reduce the overall carbon footprintof IT equipment.2.Developing validation techniques for simulation systems (which will beessential in predicting the extent and planning for climate change).3.Developing systems for multicultural use4.Developing systems that can be adapted quickly to new business needs5.Designing systems for outsourced development6.Developing systems that are resistant to attack7.Developing systems that can be adapted and configured by end-users8.Finding ways of testing, validating and maintaining end-user developedsystems1.5Based on your own knowledge of some of the application types discussedin section 1.1.2, explain, with examples, why different application typesrequire specialized software engineering techniques to support their designand development.Different application types require the use of different development techniques fora number of reasons:1.Costs and frequency of change. Some systems (such as embedded systemsin consumer devices) are extremely expensive to change; others, mustchangefrequentlyinresponsetochangingrequirements (e.g. businesssystems). Systems which are very expensive to change need extensive up-front analysis to ensure that the requirements are consistent and extensivevalidation to ensure that the system meets its specification. This is not cost-effective for systems that change very rapidly.2.The most important ‘non-functional’ requirements. Different systems havedifferent priorities for non-functional requirements. For example, a real-time

Page 6 of 16

Solution Manual For Software Engineering, 10th Edition - Page 6 preview image

Software Engineering 10 – Solutions Manual6control system in an aircraft has safety as its principal priority; an interactivegame has responsiveness and usability as its priority. The techniques used toachieve safety are not required for interactive gaming; the extensive UIdesign required for games is not needed in safety-critical control systems.3.The software lifetime and delivery schedule. Some software systems have arelatively short lifetime (many web-based systems), others have a lifetime oftens of years (large command and control systems). Some systems have tobe delivered quickly if they are to be useful. The techniques used to developshort-lifetime,rapiddeliverysystems(e.g.useofscriptinglanguages,prototyping, etc.) are inappropriate for long-lifetime systems which requiretechniques that allow for long-term support such as design modelling.1.8Discuss whether professional engineers should be certified in the same wayas doctors or lawyers.These are possible discussion points - any discussion on this will tend to be wideranging and touch on other issues such as the nature of professionalism, etc.Advantages of certification•Certificationisasignaltoemployersofsomeminimumlevelofcompetence.•Certification improves the public image of the profession.•Certificationgenerallymeansestablishingandcheckingeducationalstandards and is therefore a mechanism for ensuring course quality.•Certification implies responsibility in the event of disputes. Certifying bodyis likely to be accepted at a national and international level as ‘speaking forthe profession’.•Certification may increase the status of software engineers and attractparticularly able people into the profession.Disadvantages of certification•Certification tends to lead to protectionism where certified members tendnot to protect others from criticism.•Certificationdoesnotguaranteecompetencemerelythataminimumstandard was reached at the time of certification.•Certificationisexpensiveandwillincreasecoststoindividualsandorganisations.•Certification tends to stultify change. This is a particular problem in an areawhere technology developments are very rapid.

Page 7 of 16

Solution Manual For Software Engineering, 10th Edition - Page 7 preview image

Software Engineering 10 – Solutions Manual72Software Processes2.1Giving reasons for your answer based on the type of system beingdeveloped, suggest the most appropriate generic software process modelthat might be used as a basis for managing the development of thefollowing systems:•A system to control anti-lock braking in a car•A virtual reality system to support software maintenance•A university accounting system that replaces an existing system•An interactive travel planning system that helps users plan journeyswith the lowest environmental impact1.Anti-lock braking systemThis is a safety-critical system so requires a lot ofup-front analysis before implementation. It certainly needs a plan-drivenapproachtodevelopmentwiththerequirementscarefullyanalysed.Awaterfall model is therefore the most appropriate approach to use, perhapswith formal transformations between the different development stages.2.Virtual reality systemThis is a system where the requirements will changeand there will be an extensive user interface components. Incrementaldevelopment with, perhaps, some UI prototyping is the most appropriatemodel. An agile process may be used.3.University accounting systemThis is a system whose requirements arefairly well-known and which will be used in an environment in conjunctionwith lots of other systems such as a research grant management system.Therefore, a reuse-based approach is likely to be appropriate for this.4.Interactive travel planning systemSystem with a complex user interface butwhich must be stable and reliable. An incremental development approach isthe most appropriate as the system requirements will change as real userexperience with the system is gained.2.3Consider the integration and configuration process model shown in Figure2.3. Explain why it is essential to repeat the requirements engineeringactivity in the process.

Page 8 of 16

Solution Manual For Software Engineering, 10th Edition - Page 8 preview image

Software Engineering 10 – Solutions Manual8You need to repeat the requirements engineering activity because it is essential toadaptthesystemrequirementsaccordingtothecapabilitiesofthesystem/components to be reused. These activities are:1.An initial activity where you understand the function of the system and setout broad requirements for what the system should do. These should beexpressed in sufficient detail that you can use them as a basis for deciding ofa system/component satisfies some of the requirements and so can bereused.2.Once systems/components have been selected, you need a more detailedrequirements engineering activity to check that the features of the reusedsoftware meet the business needs and to identify changes and additions thatare required.2.4Suggest why it is important to make a distinction between developing theuser requirements and developing system requirements in the requirementsengineering process.There is a fundamental difference between the user and the system requirementsthat mean they should be considered separately.1.The user requirements are intended to describe the system’s functions andfeatures from a user perspective and it is essential that users understandthese requirements. They should be expressed in natural language and maynot be expressed in great detail, to allow some implementation flexibility.The people involved in the process must be able to understand the user’senvironment and application domain.2.The system requirements are much more detailed than the user requirementsand are intended to be a precise specification of the system that may be partofasystemcontract.Theymayalsobeusedinsituationswheredevelopment is outsourced and the development team need a completespecification of what should be developed. The system requirements aredeveloped after user requirements have been established.2.6Explain why change is inevitable in complex systems and give examples(apart from prototyping and incremental delivery) of software processactivities that help predict changes and make the software being developedmore resilient to change.Systemsmustchangebecauseastheyareinstalledinanenvironmenttheenvironment adapts to them and this adaptation naturally generates new/different

Page 9 of 16

Solution Manual For Software Engineering, 10th Edition - Page 9 preview image

Software Engineering 10 – Solutions Manual9systemrequirements.Furthermore,thesystem'senvironmentisdynamicandconstantlygeneratesnewrequirementsasaconsequenceofchangestothebusiness, business goals and business policies. Unless the system is adapted toreflect these requirements, its facilities will become out-of-step with the facilitiesneeded to support the business and, hence, it will become less useful.Examples of process activities that support change are:1.Recording of requirements rationale so that the reason why a requirement isincluded is known. This helps with future change.2.Requirements traceability that shows dependencies between requirementsand between the requirements and the design/code of the system.3.Design modeling where the design model documents the structure of thesoftware.4.Code refactoring that improves code quality and so makes it more amenableto change.2.9Suggest two advantages and two disadvantages of the approach to processmaturity that is embodied in the SEI’s Capability Maturity Framework.Advantages of process improvement frameworks1.The approach provides a means of measuring the state of a process and astructured approach to introducing process improvements.2.It is useful as a way of building on the experience of others in processimprovement.Disadvantages of process improvement frameworks1.Likeanymeasurementsystem,thereisatendencytointroduceimprovements to improve the measured rating rather than concentrate onimprovements that meet real business goals.2.The maturity model approach is expensive and bureaucratic to operate. It isnot really suitable for organisations that use agile development.

Page 10 of 16

Solution Manual For Software Engineering, 10th Edition - Page 10 preview image

Software Engineering 10 – Solutions Manual103Agile SoftwareDevelopment3.2Explain how the principles underlying agile methods lead to the accelerateddevelopment and deployment of software.The principles underlying agile development are:1.Individual and interactions over processes and tools. By taking advantagesof individual skills and ability and by ensuring that the development teamknow what each other are doing, the overheads of formal communicationand process assurance are avoided. This means that the team can focus onthe development of working software.2.Working software over comprehensive documentation. This contributes toaccelerated development because time is not spent developing, checking andmanaging documentation. Rather, the programmer’s time is focused on thedevelopment and testing of code.3.Customer collaboration over contract negotiation. Rather than spendingtime developing, analyzing and negotiating requirements to be included in asystem contract, agile developers argue that it is more effective to getfeedback from customer’s directly during the development about what isrequired. This allows useful functionality to be developed and deliveredearlier than would be possible if contracts were required.4.Respondingtochangeoverfollowingaplan.Agiledevelopersargue(rightly) that being responsive to change is more effective than following aplan-based process because change is inevitable whatever process is used.There is significant overhead in changing plans to accommodate change andthe inflexibility of a plan means that work may be done that is laterdiscarded.

Page 11 of 16

Solution Manual For Software Engineering, 10th Edition - Page 11 preview image

Software Engineering 10 – Solutions Manual113.3Extreme programming expresses user requirements as stories, with eachstory written on a card. Discuss the advantages and disadvantages of thisapproach to requirements description.Advantages of stories:1.They represent real situations that commonly arise so the system willsupport the most common user operations.2.It is easy for users to understand and critique the stories.3.They represent increments of functionality – implementing a story deliverssome value to the user.Disadvantages of stories1.They are liable to be incomplete and their informal nature makes thisincompleteness difficult to detect.2.Theyfocusonfunctionalrequirementsratherthannon-functionalrequirements.3.Representing cross-cutting system requirements such as performance andreliability is impossible when stories are used.4.The relationship between the system architecture and the user stories isunclear so architectural design is difficult.3.6Compare and contrast the Scrum approach to project management withconventional plan-based approaches as discussed in Chapter 23. Yourcomparison should be based on the effectiveness of each approach forplanning the allocation of people to projects, estimating the cost of projects,maintaining team cohesion and managing changes in project teammembership.Planning allocation of people to projectsScrumScrum handles people allocation informally. Team members ‘bid’ for features fromthe product backlog to implement if they think that their expertise is appropriate.Alternatively, the tasks can be allocated by the Scrum master.There is no formal mechanism in Scrum for planning for project memberswith very specific expertise to be temporarily allocated to a team. This need mustbe identified by the Scrum master and he or she has to discuss how the expertisecan be made available.Plan-based development

Page 12 of 16

Solution Manual For Software Engineering, 10th Edition - Page 12 preview image

Software Engineering 10 – Solutions Manual12A project plan is used to identify the parts of the system to be delivered and theseare specified in the requirements document. The expertise required for each partcan then be identified and the allocation of people to projects planned on that basis.Estimating project costsScrumProject costs are estimated based on the required delivery date for the software andpeople working in the Scrum team. The functionality of the system is adjusted sothat some working system will always be delivered for the original cost estimation.Of course, this may not be adequate for the customer and they have to becomeinvolved in rescheduling the delivery of the system.Plan-based developmentProjectcostsarebasedonananalysisofthefunctionalityspecifiedintherequirements document as well as the non-functional requirements of the system.They may be adjusted to reflect team size and delivery schedule. It is normal forcosts to be underestimated and the final project to cost much more than originallyestimated. An average cost for team members is assumed.Maintaining team cohesionScrumTeam member meet daily either face to face or electronically. Extensive informaldiscussions and communications are encouraged.Team members negotiate workto be done from the project backlog.This all leads to a shared feeling of productownership and a very cohesive team.Plan-based developmentTeam cohesion is the responsibility of the project manager and he or she has to takeexplicit actions to encourage this. The general approach relies on formal meetingsthat are relatively infrequent and this does not lead to the development of acohesive team.Managing changes in project team membershipScrumThis is a topic that is rarely discussed in Scrum but is a fundamental problembecause so much information is informal and reliant on people remembering whathas been agreed. When someone leaves, it can be very difficult to bring areplacementteammemberuptospeed,especiallyifverylittleprojectdocumentation is available.Plan-based development

Page 13 of 16

Solution Manual For Software Engineering, 10th Edition - Page 13 preview image

Software Engineering 10 – Solutions Manual13The project management plan is based around expertise rather than individuals andproject documents should be available. Therefore, if a team member leaves, then anew team member with comparable expertise can read what has been done and,after understanding this, should be able to serve as a replacement.3.8Why is it necessary to introduce some methods and documentation fromplan-based approaches when scaling agile methods to larger projects thatare developed by distributed development teams.1.Project planningis often essential when developing software with largerteams to (a) ensure that the right people are available when they are neededto be involved in the development process and (b) ensure that the deliveryschedules of different parts of the system developed by different teams arealigned. This means that if Part A depends on Part B, the schedule shouldensure that Part B is developed before Part A.2.Requirements analysis and documentationis important to decide how todistribute the work across teams and to ensure that each team has someunderstanding of what other teams are doing.3.Design documentationespecially interface specifications are important sothat teams can develop independently without having access to software thatis under development.4.Risk managementmay be required to ensure that all of the teams understandthe risks faced and can organize their work to minimize these risks. Riskmanagement may also be useful to cope with different delivery schedulesused by different teams.3.10It has been suggested that one of the problems of having a user closelyinvolved with a software development team is that they ‘go native’. That is,they adopt the outlook of the development team and lose sight of theneeds of their user colleagues. Suggest three ways how you might avoid thisproblem and discuss the advantages and disadvantages of each approach.1.Involve multiple users in the development team.Advantages are you getmultiple perspectives on the problem, better coverage of user tasks andhencerequirementsandlesslikelihoodofhavinganatypicaluser.Disadvantages are cost, difficulties of getting user engagement and possibleuser conflicts.

Page 14 of 16

Solution Manual For Software Engineering, 10th Edition - Page 14 preview image

Software Engineering 10 – Solutions Manual142.Change the user who is involved with the team. Advantages are, again,multipleperspectives.Disadvantagesareeachusertakestimetobeproductive and possible conflicting requirements from different users.3.Validate user suggestions with other user representatives. Advantages areindependent check on suggestions; disadvantage is that this slows down thedevelopment process as it takes time to do the checks.

Page 15 of 16

Solution Manual For Software Engineering, 10th Edition - Page 15 preview image

Software Engineering 10 – Solutions Manual154RequirementsEngineering4.2Discover ambiguities or omissions in the following statement ofrequirements for part of a ticket-issuing system:An automated ticket machine sells rail tickets. Users select their destinationand input a credit card and a personal identification number. The rail ticketis issued and their credit card account charged. When the user presses thestart button, a menu display of potential destinations is activated, alongwith a message to the user to select a destination and the type of ticketrequired. Once a destination has been selected, the ticket price is displayedand customers are asked to input their credit card. Its validity is checkedand the user is then asked to input their personal identifier (PIN). When thecredit transaction has been validated, the ticket is issued.Ambiguities and omissions include:1.Can a customer buy several tickets for the same destination together or mustthey be bought one at a time?2.Can customers cancel a request if a mistake has been made?3.How should the system respond if an invalid card is input?4.What happens if customers try to put their card in before selecting adestination (as they would in ATM machines)?5.Must the user press the start button again if they wish to buy another ticketto a different destination?6.Should the system only sell tickets between the station where the machine issituated and direct connections or should it include all possible destinations?

Page 16 of 16

Solution Manual For Software Engineering, 10th Edition - Page 16 preview image

Software Engineering 10 – Solutions Manual164.4Write a set of non-functional requirements for the ticket-issuing system,setting out its expected reliability and response time.Possible non-functional requirements for the ticket issuing system include:1.Between 0600 and 2300 in any one day, the total system down time shouldnot exceed 5 minutes.2.Between 0600 and 2300 in any one day, the recovery time after a systemfailure should not exceed 2 minutes.3.Between 2300 and 0600 in any one day, the total system down time shouldnot exceed 20 minutes.All these are availability requirements – note that these vary according to the timeof day. Failures when most people are traveling are less acceptable than failureswhen there are few customers.4.After the customer presses a button on the machine, the display should beupdated within 0.5 seconds.5.The ticket issuing time after credit card validation has been received shouldnot exceed 10 seconds.6.When validating credit cards, the display should provide a status messagefor customers indicating that activity is taking place.This tells the customer that the potentially time consuming activity ofvalidation is still in progress and that the system has not simply failed.7.The maximum acceptable failure rate for ticket issue requests is 1: 10000.Note that this is really ROCOF. I have not specified the acceptable number ofincorrect tickets as this depends on whether or not the system includes tracefacilities that allow customer requests to be logged. If so, a relatively high failurerate is acceptable as customers can complain and get refunds. If not, only a verylow failure rate is acceptable.Obviously, these requirements are arbitrary and there are many otherpossible answers. You simply have to examine their credibility.

Preview Mode

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

Report

Learning Tools

Writing Tools

Browse Resources

Solution Manual For Software Engineering, 10th 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