Choosing Among the Spiral Model, UP, and XP

There are different criteria for choosing a software development method. From the human perspective, the main criterion of choice is communication. There is little doubt that persons using XP communicate better within a team. Therefore, the Spiral Model and UP can be used among teams , to communicate key elements of the overall product. XP can be used within teams, which will quickly shake out to form more than a dozen groups, in the case of the largest team, or around four groups, in the case of 30 developers.

One of the chief criticisms of XP is that it does not scale up. For a group of 300, or even 30, XP does not seem to be the choice. However, a quick poll of practitioners reveals that they interact daily with an average of eight teammates. A typical XP team is 6 to 10. Therefore, size hardly matters in choosing among the Spiral Model, UP, and XP.

We demonstrate here the decisions required to choose among the three development methods for an actual project, albeit one that started before any of the methods existed.

At one time, there was a big aerospace contractor that specialized in fixed-wing aircraft. It obtained a contract for a helicopter and put some of its best engineers on the project. Everything seemed the same as previous business, except now the wings would be spinning. There were some strict requirements, some of which were immutable, like gross weight, 7,500 pounds , and flyaway cost, $7,500,000. Seemingly, to maintain this theme of sevens, seven processors were required, none being so close together that a single anti-aircraft round could disable the aircraft. Six were used for various parts of the system; the seventh was a hot spare, meaning that it was powered up, but empty except for the operating system. The remainder of the code was on several nonvolatile ( core !) memories hidden in the bowels of the ship.

This system was dedicated to software for navigation and weapons delivery. Everyone on the project thought that this would be relatively simple, since they had done such a system before. How different could navigation be between a fixed and rotary -winged aircraft? How different could weapons delivery be? It turned out to be quite different. None of the weapons were the same, and the helicopter flew lower and slower than any military fixed-wing aircraft. In addition, congressional representatives with oversight of this helicopter kept changing from two pilots to one and back again, while insisting on the same weight and cost ”which meant constant redesigning .

Once it was clear that the engineers knew only a little about this type of aircraft, a Spiral Model approach was thought to be the best, so that engineers could start with some key but largely unknown components and then calibrate budget and estimation. Even with the Spiral Model, deliveries were too far between to address congressional changes. UP was chosen , as it consists of iterations within phases.

Concurrent with this could be a way of learning something new about the system with a small team using XP, chosen largely for its speed. The project team initially had to build software for a standard government processor that had words 16 bits in length. Due to the long development time, nobody expected this processor to remain the same. Even government foot -dragging could not cause any change to Moore s Law (processor power doubles every 18 months). Therefore, a small team worked on porting the software to a 32-bit machine, and doing occasional prototypes . XP is well suited to what that group would be doing.

To recap, the team was relatively ignorant of helicopters, so the Spiral Model approach would help build a kernel of the software and calibrate previously successful estimation methods. Each spiral would consist of a UP lifecycle. UP was chosen since it represents an entire software production cycle each spiral, and is iterative itself. The parallel development, consisting of products that would never be delivered, was an XP project. This way, the team could react quickly to requirements changes, like one to two pilots.

One thing on this project was known: it would last a long time ” years , maybe decades. This almost certainly eliminates XP from consideration for the core software. The core software development would need heavy documentation to be passed to different developers.

Task  

Which life cycle method would you use for a nuclear reactor controller? Why?