Engineering Software Products An Introduction To M
Engineering Software Products An Introduction to M
Exam (elaborations)
Engineering Software Products An Introduction to Modern Software Engineering 1st Edition By Ian Sommerville (Solution of Execrcises)
136 views 2 purchases
Course
Engineering Software Products An Introduction to M
Institution
Engineering Software Products An Introduction To M
Engineering Software Products An Introduction to Modern Software Engineering, 1e Ian Sommerville (Solution of Execrcises)
Engineering Software Products An Introduction to Modern Software Engineering, 1e Ian Sommerville (Solution of Execrcises)Test Bank, Exam Bank, Solutions Manual, Instructor Ma...
31. Solutions to exercises 1.1 Briefly describe the fundamental difference between project-based and product-based software engineering. The most important difference is that in project-based software engineering there is an external client for the software who is responsible for specifying their needs as ‘requirements’. For products, the owner of the product is responsible for specifying its features and may change this specification in response to schedule pressure or technical difficulties. 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 specific customer needs. 2. Software product lines are designed for evolution so that the needs of different clients can be accommodated. While evolution is important for software products, issues such as performance and usability are usually more important. 3. Product updates are more complex for software product lines as it is important to check that 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’ for that software product. WHAT: An open-learning environment that allows teachers to configure the set of tools and 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 the administration 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 than simply technical specialists? Because they have to interface and interact with a wide range of people who may not be technical experts. Typically this will include potential users, company managers and managers of companies who are potential customers for the product. Of course, they also have to interact with the development team so must understand technical issues that may be important. 1.5 You are a software product manager for a company developing educational software products based around scientific simulations. Explain why it is important to develop a product roadmap 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. The product is a simulation system so teachers need to have time to evaluate it before deciding on (Engineering Software Products An Introduction to Modern Software Engineering, 1e Ian Sommerville)
(Solution to Exercises) 4whether or not it suits their needs. Typically, schools and colleges work around an academic year, 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 of that year at the latest as teachers and instructors cannot be guaranteed to be available during the vacation. All institutions have a purchasing process and there may be several weeks between a decision to purchase and the delivery of the software. Therefore, if the software is not available in the first three calendar months of the year, it is probably impossible to evaluate, 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 possible funders what your software can do. It is much easier to explain to them why your company 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 that you 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. NoSQL databases) that you might use in your product. 4. Developing a prototype helps you understand the overall structure of your system. This is helpful in deciding how to decompose your final implementation into fundamental software units, such as services. 52. Solutions to exercises 2.1 Explain why it is important that software products are developed and delivered quickly. Why is it sometimes sensible to deliver an unfinished product and then issue new versions of that product after delivery? It is important to develop and deliver software products quickly because of the dynamic and competitive market and because of the need for a company to generate revenue as soon as possible. If you don’t deliver quickly, then a competitive product may be introduced first and capture 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 of people, premises etc. as soon as possible otherwise there may be insufficient funding to run the company. Delivering an unfinished product may make sense because it introduces your product to customers and gives them a chance to embed it in their way of working. They are therefore more 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 the accelerated development and delivery of software products. The fundamental objectives of agile software engineering are incremental development and delivery of software and minimising activities such as documentation that do not contribute directly to the delivery of the software. These lead to accelerated development because incremental development means that changes can be accommodated during the development process with only minimal product rework. Rework is a major factor in slowing down delivery. Minimising ancillary activities means that the team can spend its time on delivering software and so can complete it more quickly. 2.3 Give three reasons why Extreme Programming (XP) is envisaged by its developers is not widely used. 1. XP fails to provide guidance on how projects should be managed and organized - it simply suggests that teams should be self-organizing. The reality of software development in businesses is that there needs to be a clear interface between the development team and the wider organization and someone who takes responsibility for everyday management tasks. 2. Pair programming is a fundamental part of XP but it is contrary to the way that many organizations work and is sometimes disliked by developers. There is no definitive evidence 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, it is impractical in many circumstances to find a representative customer who has time for such 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 6releases that potential customers can try and then provide feedback. Comment on this idea and suggest why it may not be acceptable to the system’s users. This issue exemplifies the problem with incremental delivery. There are some processes where all of the functionality of a system is needed and users prefer to stick with their existing system 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 are therefore unlikely to want to experiment or become involved in the agile development process. 2.5 Explain why the product owner is an essential role in a Scrum development team. How might a development team that is working in an environment where there are no external customers (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 potential customers for the software and they have to represent the needs and wishes of these customers to the team. Failure to do this properly will lead to software that does not do what customers want and so is unlikely to be successful. In a situation where there are no external customers, the problem is that the whole team have ideas about what the software is required to do. While it may seem that appointing a team member as a product owner is an alternative, the reality is that individuals will always question their authority as they are no more qualified than anyone else to say what should and shouldn’t be in the product. Rather than a ‘product owner’ a possible alternative is a ‘product discussion’ where the team 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 make proposals for the work of that iteration. At the end of the meeting, if there is no consensus on what proposals should be accepted, the team should vote and the proposals that get the highest 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 a demonstrator 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 finish incomplete software. The circumstances where this rule might be relaxed is when the aim of the sprint is to gather information rather than to create working software. So, if the sprint is developing a throw-away prototype, this does not need to be shippable; alternatively if some new
The benefits of buying summaries with Stuvia:
Guaranteed quality through customer reviews
Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.
Quick and easy check-out
You can quickly pay through credit card or Stuvia-credit for the summaries. There is no membership needed.
Focus on what matters
Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!
Frequently asked questions
What do I get when I buy this document?
You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.
Satisfaction guarantee: how does it work?
Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.
Who am I buying these notes from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller tutorsection. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $14.49. You're not tied to anything after your purchase.
