Demonstrate user product

Figure 5.8 illustrates the waterfall process. In practice, there are often arrows jumping back up the waterfall3which makes this model an idealization.

3

Imagine salmon leaping upstream over the rapids. User Needs

Requirements

Design Waterfall Process

Build Test

User Product

5.4.2 Iterative Process

The iterative process is used to deliver a product in increments. The customers define the goals of the product at the beginning of development and are always anxious to have some- thing quickly working. The iterative process provides the product to the customer in parts and provides developers an opportunity to learn about the product and the customer while building the product. This type of process is typically used when there is enough time for developing a project in parts and the customer is eager to provide feedback on the how the product functions while it is being developed. Figure 5.9 illustrates the iterative process.

First Delivery Second Delivery Third Delivery

Figure 5.9 Example of an iterative process with one development team, expressed as a V-chart.

5.4.3 Spiral Process

The spiral process combines many fundamental contents of different process models into a single process. This process works best for projects that have a high risk of failure, such as research projects dealing with developing a new technology. Figure 5.10 illustrates the spi- ral process. Each cycle starts with the steps shown in the upper left quadrant, which are ob- jectives (goals to achieve), constraints (limitations on resources), and alternatives (different approaches to achieve the objectives). The second quadrant (clockwise direction) shows the next steps in the process, which are risk analysis and prototyping. It begins with alter- natives produced in the first quadrant. The developers then use the prototypes to analyze each alternative’s risks and gain more insight. The third quadrant consists of the evaluation and decision making processes, followed by building the solution. The final quadrant con- sists of understanding what to do for the next cycle, which is repeated in the first quadrant. The developers revise the previous phases and create a plan for the next quadrant, review the same, and then decide whether to go ahead with the plan or stop building the project.

5.4.4 Agile Development Methods

The most common agile development methods are scrum, extreme programming, and lean development. These methods seek to deliver the product to the customer in satisfactory condition as early as possible in a continuous manner.

Let’s examine scrum. With scrum, development activity is divided into a series of sprints lasting two to four weeks. At the end of the sprint the team will have a working, de- liverable software product. There are three main types of participants:

䡲 The product owner speaks for the customer. 䡲 The team delivers the product.

䡲 The Scrum Master is responsible for eliminating obstacles from the team’s path.

Each sprint begins with the team members and product owner discussing features from a pri- oritized feature list (the product backlog). The product owner identifies the desired features, and the team estimates which can be delivered within the sprint, adding them to a task list called the sprint backlog. The sprint backlog is frozen for the sprint, so that the team members have clear goals during that development period. Each day during the sprint there is a brief (fif- teen minute) status meeting in which each team member answers three specific questions:

䡲 What have you done since yesterday’s meeting? 䡲 What are you going to do today?

䡲 Are there any issues keeping you from meeting your goals?

The Scrum Master then seeks to address the issues. Finally, each sprint is time-boxed. If a feature is not completed by the end of the sprint, it goes back into the product backlog. One

Acquire Objectives Acquire Constraints Acquire Alternatives

Evalute product Plan the next cycle Continue or stop

Evalute the risk using prototyping

Evalute the risk aversion approach. Build the product of the cycle

of scrum’s main strengths is the short development cycle, which improves the speed of feedback. There are other aspects to scrum which we do not cover here, but further details are available in numerous texts on the subject.

5.4.5 Prototyping

Prototyping is a popular and useful software process, especially when determining the look and feel of the software has a higher priority than its basic functions. One of the drawbacks of the prototyped process is that when the waterfall model of development is used the de- veloper may create something completely different from what the customer expected, since the requirements are gathered only at the beginning of the development process. Thus, pro- totyping is better when it is performed as either an iterative or evolutionary process.

Two basic types of prototypes used are the throw away and evolutionary prototype. In the throw away prototype, developers use a demonstration tool or language. Once the cus- tomer is satisfied with the prototype, the developers throw away the prototype and build the actual product with real programming languages. In the evolutionary prototype, the devel- opers use code from the prototype in the actual system.

5.5 RECAP

䡲 A major risk of software development is starting coding too early. Designing the system and its components before coding reduces development risks significantly, and also provides other benefits.

䡲 Industry follows many (and sometimes differing) processes when developing soft- ware. A process gives a directional path to developing software in an organized manner, and allows the people developing the software and using the software to maintain expectations from the development process at regular intervals.

䡲 Pseudo code and graphical methods to design solutions to a software programming problem allows understanding, resolving, and maintaining logical flow of a pro- gram. They can also be directly included in the documentation for the program. 䡲 Testing is an integral part of software testing and software not subjected to testing

is bound to fail. There are different techniques available for testing which should be applied as appropriate.

5.6 REFERENCES

Ganssle, Jack. “Breakpoints: Jack’s Top Ten.” Embedded Systems Design, December (2006): 61–63. Print. Ganssle, Jack. The Art of Designing Embedded Systems. 2nd ed. Lawrence, KS: Newnes, 2008. Print.

Kernighan, Brian W., and Rob Pike. The Practice of Programming. Indianapolis: Addison-Wesley, 1999. Print.

Koopman, Philip J. Better Embedded System Software. New Castle, PA., Drumnadrochit Education, 2010. Print.

Phillips, Dwayne. The Software Project Manager’s Handbook: Principles That Work at Work. Los Alamitos, CA: John Wiley & Sons, 2004. Print.

5.7 EXERCISES

1. Create a set of requirements for a vending machine which accepts coins and one-