Solution Manual for Engineering Software Products: An Introduction to Modern Software Engineering, 1st Edition

Page 1 of 11

Solution Manual for Engineering Software Products: An Introduction to Modern Software Engineering, 1st Edition - Page 1 preview image

1ENGINEERING SOFTWARE PRODUCTSSOLUTIONS TO EXERCISES

Page 2 of 11

Solution Manual for Engineering Software Products: An Introduction to Modern Software Engineering, 1st Edition - Page 2 preview image

Page 3 of 11

Solution Manual for Engineering Software Products: An Introduction to Modern Software Engineering, 1st Edition - Page 3 preview image

31. Solutions to exercises1.1 Briefly describe the fundamental difference between project-based and product-basedsoftware engineering.The most important difference is that in project-based software engineering there is anexternal client for the software who is responsible for specifying their needs as‘requirements’. For products, the owner of the product is responsible for specifying itsfeatures and may change this specification in response to schedule pressure or technicaldifficulties.1.2 What are three important differences between software products and software product lines.1.There is a single version of a software product for all customers in a particular market.For software product lines, every delivered product is different and adapted to specificcustomer needs.2.Software product lines are designed for evolution so that the needs of different clients canbe accommodated. While evolution is important for software products, issues such asperformance and usability are usually more important.3.Product updates are more complex for software product lines as it is important to checkthat these do not interfere with every client version of the software.1.3 Based on the vision example for the iLearn system, identify the ‘WHAT, WHO and WHY’ forthat software product.WHAT: An open-learning environment that allows teachers to configure the set of toolsand resources available to teachers and students to meet the specific needs of these users.WHO: Teachers and other educators.WHY: Because existing learning environments are inflexible with a focus on theadministration of learning rather than the learning process itself.1.4 Why do software product managers have to be generalists with a range of skills rather thansimply technical specialists?Because they have to interface and interact with a wide range of people who may not betechnical experts. Typically this will include potential users, company managers andmanagers of companies who are potential customers for the product. Of course, they alsohave to interact with the development team so must understand technical issues that may beimportant.1.5 You are a software product manager for a company developing educational softwareproducts based around scientific simulations. Explain why it is important to develop a productroadmap so that final product releases are available in the first three months of the year.The market for this software is science departments in schools and colleges. Theproduct is a simulation system so teachers need to have time to evaluate it before deciding on

Page 4 of 11

Solution Manual for Engineering Software Products: An Introduction to Modern Software Engineering, 1st Edition - Page 4 preview image

4whether or not it suits their needs. Typically, schools and colleges work around an academicyear, which starts in September and runs through till May or June.Therefore, to use the product in a new academic year, it has to be installed by June ofthat year at the latest as teachers and instructors cannot be guaranteed to be available duringthe vacation. All institutions have a purchasing process and there may be several weeksbetween a decision to purchase and the delivery of the software. Therefore, if the software isnot available in the first three calendar months of the year, it is probably impossible toevaluate, purchase, install and test the product in time for the new academic year.1.6 Why should you develop a prototype before you start developing a new software product?You should always develop a prototype system for four reasons:1.If you are looking for funding for your product development, a prototype shows possiblefunders what your software can do. It is much easier to explain to them why yourcompany is worth investing in if they can see customer benefits.2.A prototype can be used for initial customer experimentation to see if the features thatyou propose to include are genuinely useful and likely to be used by customers.3.You can use a prototype to investigate the feasibility of technologies (e.g. NoSQLdatabases) that you might use in your product.4.Developing a prototype helps you understand the overall structure of your system. This ishelpful in deciding how to decompose your final implementation into fundamentalsoftware units, such as services.

Page 5 of 11

Solution Manual for Engineering Software Products: An Introduction to Modern Software Engineering, 1st Edition - Page 5 preview image

52. Solutions to exercises2.1 Explain why it is important that software products are developed and delivered quickly. Whyis it sometimes sensible to deliver an unfinished product and then issue new versions of thatproduct after delivery?It is important to develop and deliver software products quickly because of the dynamicand competitive market and because of the need for a company to generate revenue as soon aspossible. If you don’t deliver quickly, then a competitive product may be introduced first andcapture the market. Customers are reluctant to change after they have made a decision.Furthermore, product development is expensive and there is a need to try and cover costs ofpeople, premises etc. as soon as possible otherwise there may be insufficient funding to runthe company.Delivering an unfinished product may make sense because it introduces your product tocustomers and gives them a chance to embed it in their way of working. They are thereforemore likely to commit to a finished version when it has been completed.2.2 Explain why the fundamental objectives of agile software engineering are consistent with theaccelerated development and delivery of software products.The fundamental objectives of agile software engineering are incremental developmentand delivery of software and minimising activities such as documentation that do notcontribute directly to the delivery of the software. These lead to accelerated developmentbecause incremental development means that changes can be accommodated during thedevelopment process with only minimal product rework. Rework is a major factor in slowingdown delivery. Minimising ancillary activities means that the team can spend its time ondelivering software and so can complete it more quickly.2.3 Give three reasons why Extreme Programming (XP) is envisaged by its developers is notwidely used.1.XP fails to provide guidance on how projects should be managed and organized - itsimply suggests that teams should be self-organizing. The reality of softwaredevelopment in businesses is that there needs to be a clear interface between thedevelopment team and the wider organization and someone who takes responsibility foreveryday management tasks.2.Pair programming is a fundamental part of XP but it is contrary to the way that manyorganizations work and is sometimes disliked by developers. There is no definitiveevidence that pair programming is more effective than individual developers.3.While the idea of embedding a customer in the development team is an attractive one, itis impractical in many circumstances to find a representative customer who has time forsuch involvement.2.4 You are developing a software product to help manage student admissions in a university.Your agile development team suggests that they should develop this as a number of small

Page 6 of 11

Solution Manual for Engineering Software Products: An Introduction to Modern Software Engineering, 1st Edition - Page 6 preview image

6releases that potential customers can try and then provide feedback. Comment on this idea andsuggest why it may not be acceptable to the system’s users.This issue exemplifies the problem with incremental delivery. There are some processeswhere all of the functionality of a system is needed and users prefer to stick with their existingsystem rather than experiment with an untried new system. They are too busy to ‘play around’with unfinished software as they are working on tasks that have a strict deadline. They aretherefore unlikely to want to experiment or become involved in the agile developmentprocess.2.5 Explain why the product owner is an essential role in a Scrum development team. Howmight a development team that is working in an environment where there are no externalcustomers (e.g. a student project team) reproduce this product owner role?The product owner is an essential role because they are the interface with the potentialcustomers for the software and they have to represent the needs and wishes of these customersto the team. Failure to do this properly will lead to software that does not do what customerswant and so is unlikely to be successful.In a situation where there are no external customers, the problem is that the whole teamhave ideas about what the software is required to do. While it may seem that appointing ateam member as a product owner is an alternative, the reality is that individuals will alwaysquestion their authority as they are no more qualified than anyone else to say what should andshouldn’t be in the product.Rather than a ‘product owner’ a possible alternative is a ‘product discussion’ where theteam meet at the start of each iteration and discuss what they will do during that iteration.This should be a short, time-bounded meeting where everyone has the opportunity to makeproposals for the work of that iteration. At the end of the meeting, if there is no consensus onwhat proposals should be accepted, the team should vote and the proposals that get thehighest number of votes should be implemented.2.6 Why is it is important that each sprint should normally produce a ‘potentially shippable’product increment? When might the team relax this rule and produce something that is not‘ready to ship’?It is important to product a potentially shippable product increment for three reasons:1.This means that there is always a high quality version of the software available as ademonstrator for potential customers and funders.2.The software should be reliable so can be used as a basis for future development, reused,etc.3.If people leave the team, new people are not faced with the problem of trying to finishincomplete software.The circumstances where this rule might be relaxed is when the aim of the sprint is togather information rather than to create working software. So, if the sprint is developing athrow-away prototype, this does not need to be shippable; alternatively if some new

Page 7 of 11

Solution Manual for Engineering Software Products: An Introduction to Modern Software Engineering, 1st Edition - Page 7 preview image

7technology such as a new type of database is being tested, there should be no expectation ofproducing finished software.2.7 Explain why estimating the work required to complete a product backlog item using effort in‘person-hours’ or ‘person-days’ can lead to significant variations between the estimated effortand the actual effort to implement that item.Team members have differing ability and experience. What one team member mightcomplete in 10 hours, might take another 20 hours. Teams will always tend to defer to moresenior members when making estimates and, because they are experienced, they mayunderestimate the time needed by more junior members to finish the work.2.8 Explain why daily scrums are likely to reduce the time that is normally required for newteam members to become productive.Daily scrums are a mechanism for information exchange where the whole team candiscuss issues. New team members attending a scrum are not only provided with updates onprogress and problems faced by the team, the meeting also means they can ask questionswithout feeling that they are interrupting the work of other team members.2.9 One of the problems with self-organising teams is that more experienced team memberstend to dominate discussions and therefore to influence the team’s way of working. Suggestways to reduce this problem.Two ways in which this problem might be reduced:1.All team-members propose solutions and issues anonymously on post-it notes and theseare all discussed by the team.2.More junior members of the team are asked to lead discussions on issues rather thanalways relying on senior team members.2.10 Scrum has been designed for use by a team of 5-8 people working together to develop asoftware product. What problems might arise if you try to use Scrum for student team projectswhere a group work together to develop a program. What parts of Scrum could be used in thissituation?Problems and issues1.No explicit product manager1.2.ScrumMaster is unlikely to be experienced in using Scrum so can’t really act as acoach1.3.Difficulties in arranging daily Scrums because team members are not full-time buthave class commitments.1.4.The project goal is not usually to produce shippable software but a workingperhaps incomplete demonstrator.1.5.Inexperienced team unlikely to be able to make accurate estimatesAspects of Scrum that can be used:1.6.Product backlogii.Time-boxed sprints producing demonstrable software in each sprint

Page 8 of 11

Solution Manual for Engineering Software Products: An Introduction to Modern Software Engineering, 1st Edition - Page 8 preview image

8iii.Regular all-team meetings to discuss problems and agree on backlog items

Page 9 of 11

Solution Manual for Engineering Software Products: An Introduction to Modern Software Engineering, 1st Edition - Page 9 preview image

93. Solutions to exercises3.1 Using the input/action/output template that I introduced at the beginning of this chapter,describe two features of software that you commonly use such as an editor or a presentationsystem.Change name feature of program editor:Input: The name of a variable or a function that has to be changed and the new name forthe variable or function.Action: All of the instances of that name in the current scope are replaced with the newname ie the name change may be restricted to within a function or can be a global change.Activation: User chooses the ‘Change name’ command from the Refactoring menuOutput: A program with the new names replacing the old namesRemove dust spots feature of a photo editor.Input: A photograph plus a selection where the command should apply. The size of dustspot that should be removed.Action: Within the selected area, the program identifies dust spots and replaces the spotpixels with adjacent pixels.Activation: User choice from Restore Photo menu.Output: The input photograph without dust spotsFormat documentInput: A document annotated with Markdown mark-up commands+ a style sheetdefining how commands should be styledAction: Formats the document according to the mark-up specification and the stylechosenActivation: From the Format document menu or keyboard shortcutOutput: A PDF representation of the document formatted according to the style sheet3.2 Explain why it is helpful to develop a number of personas representing types of system userbefore you move on to write scenarios of how the system will be used.It is important to write personas to represent the different types of user that you thinkwill use the system so that you can imagine the type of system feature that they are likely touse and they level of complexity in features that they can deal with. Writing personas alsohelps you empathise with users and makes you think about how they would react to usingyour software.

Page 10 of 11

Solution Manual for Engineering Software Products: An Introduction to Modern Software Engineering, 1st Edition - Page 10 preview image

103.3 Based on your own experience of school and the teachers you knew, write a persona for ahigh school science teacher who is interested in building simple electronic systems and usingthese in class teaching.Iona is 27 and has been a high-school science teacher in Portobello High School nearEdinburgh, Scotland for 4 years. Her father was an electronic engineer and introduced her tobuilding home electronic systems when she was 10. She enjoys building and using thesesystems and often builds systems with her students. She did a degree in Physics at AberdeenUniversity and as part of that course, learned to program in Python. She normally teachesphysics but sometimes helps with computer science classes. Outside of work, she enjoys rockclimbing and cooking and is very interested in the science of cooking.One of the problems that Iona has is that getting simple electronic construction tasksover to students is time-consuming and takes up a lot of lesson time. She primarily wants touse the iLearn system to integrate video into her teaching where she plans to make videosdemonstrating completed systems and how-to videos showing simple tasks like choosingresistors, etc.3.4 Extend Jack’s scenario, shown in Table 3.5, to include a section where students record audioreminiscences from their older friends and relatives and include them in the iLearn system.The following text might be added to the scenario:The audio reminiscences are collected by students from older relatives and friends. Theclass discuss a list of questions that they can ask and students are issued with digitalrecorders to capture these from friends and relatives. Once they have made the recordings,information is added about who is involved and their role in the fishing industry. Therecordings are then uploaded to the iLearn system as audio files.Obviously, there are many possible acceptable answers to this question.3.5 What do you think are the weaknesses of scenarios as a way of envisaging how users mightinteract with a software system?There are three major weaknesses of the scenario-based approach:1.They may be too specific. Even if your scenarios are based on potential system users, it isvery difficult to know if these represent ways of using the system that are general ratherthan specific to this type of user.2.They may be incomplete. The scenario presents a high-level view of interactions. You cannever know if your set of scenarios are missing something that would be important tosome users. They also may not cover essential features such as security features.3.Lack of detail. Some interactions may involve detailed actions by users but these tend tobe missed out in scenarios as they make them too long and tedious to read.3.6 Starting with Jack’s scenario, derive four user stories about the use of the iLearn system byboth students and teachers.

Page 11 of 11

Solution Manual for Engineering Software Products: An Introduction to Modern Software Engineering, 1st Edition - Page 11 preview image

11As a teacher, I want to be able to quickly review student’s photographs before they areadded to the system to check that they do not include copyright material from other sources.As a teacher, I want students to be able to access information on the fishing industryfrom sources such as newspaper archives.As a student, I want to be able to create short vignettes where a series of photos areshown alongside an audio reminiscence.As a student, I want to be able to edit and merge audio files.3.7 What do you think are the weaknesses of user stories when used to identify system featuresand how they work?The problem with user stories is that users tend to focus exclusively on how they mightuse the system to do the things they want to do. They do not think of things that may beneeded (such as backups) that are essential but which users prefer to ignore.3.8 Explain why domain knowledge is important when identifying and designing productfeatures.Domain knowledge is very important because the features of the product must begeared to addressing common problems and actions from that domain. For example, if thedomain is managing dental records, you need to know what dentists include in a dental recordand how they use these records when planning treatment.3.9 Suggest how a development team might avoid ‘feature creep’ when they are faced withmany different suggestions for new features to be added to a product.Ways to avoid feature creep:1.Look for overlaps in suggested features and try to merge features into a single feature2.Check that feature suggestions do not overlap with existing features and that there is noway to do the same thing using existing features3.Look at the generality of suggested features and choose features that providefunctionality that is likely to be widely used rather than very specific functionality4.Review feature suggestions with a domain expert to see how useful they are likely to be3.10 Based on Elena’s scenario, shown in Table 3.7, use the method of highlighting phrases inthe scenario to identify four features that might be included in the iLearn system.1.A feature to set up a dedicated learning environment for a subject or class.2.A feature to configure that environment by adding tools and services that will be madeavailable to all users.3.A feature to create sub-environments that contain a subset of the tools/services and whoseuse is confined to specific sub-groups.4.A feature that makes it possible for an environment to be reviewed by a specified groupof users before it is made generally available.

Preview Mode

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

Report

Learning Tools

Writing Tools

Browse Resources

Solution Manual for Engineering Software Products: An Introduction to Modern Software Engineering, 1st Edition - Page 1

Study Now!

Document Details

Related Documents

ENGR 111 Spring 2025 ScheduleFeb 19

MyOakton Instructions Change Term View Placement I

Computer Assembling Plant Design

Reliability Analysis and Maintenance Strategies for Complex Systems and Components

Analysis and Calculations of Resistances, Wire Sizes, and Magnetomotive Force in DC Machine Field Windings

ECET105 � Digital Fundamentals Homework Assignment #5

INDE 2333 Engineering Statistics I Practice Exam 2

Test Bank for Automotive Service Management, 3rd edition

Solution Manual For Refrigeration and Air Conditioning Technology, 8th Edition

Solution Manual for Sensors and Actuators: Engineering System Instrumentation, 2nd Edition

Company

Explore

Study Tools