Software Process Models: A system too large for one person to build is usually also too large to build without an overall plan that coordinates the people working on it, the tasks that need to be done, and the artifacts that are produced. Researchers and practitioners have identified a number of software development process models for this coordination. Here are some of the main ones.
These process models are alternatives, but not exclusive ones: most describe different aspects of a process, and it is common for a development group to be following two or more simultaneously. For example,
- The sashimi process is a way of organising a waterfall with feedback.
- Bohemia's spiral model example uses prototyping as the model for each cycle, and portions of a waterfall model for the delivered system stage of the prototyping model.
- an incremental process often uses a sashimi process for its Produce a build stage.
Code-and-fix
This simple process is often said to be what unsophisticated developers follow spontaneously . It provides no guidance for dividing up the task of producing software. It doesn't distinguish the various development artifacts (they may not even be present, except for the code).
In this process, developers write code, fix the problems they notice, and repeat. There is no guidance to help developers converge to an appropriate result
Sequential processes
Sequential processes divide up software development by the distinguished activities of software development, each one associated with a distinct kind of artifact (Table below), and then do one after another in some pattern. The activities and artifacts have a linear dependency relationship: each activity's artifacts depend on the artifacts produced by the activities above it in the table, and if a higher artifact changes, all lower artifacts may have to change to match it. This chain of dependence affects all software development; in processes that don't produce all these artifacts, such as XP in which requirements and specifications are not produced, the kind of knowledge that would go into the absent artifact still participates in the chain of dependence.
Activity
|
Artifacts
|
|---|---|
Requirements
|
Requirements
and specification
|
Architecture
|
The
system architecture, division into modules, and module interfaces
|
Implementation
|
The
source code
|
Testing
|
The
module, subsystem, system, and acceptance tests
|
Deployment
|
The
distribution package
|
Maintenance
|
Bug
reports and modified artifacts
|
Prototyping
In this approach, an initial prototype is produced (by whatever development process is desired) and used by stakeholders in order to validate the requirements and identify problems and promising solutions. The prototype must exhibit at least enough of the eventual system's intended characteristics for the stakeholders to evaluate it, but typically a prototype will run slower, lack the desired functionality, and afford only incomplete functionality. The final system is then developed from scratch (again by whatever process is desired) benefiting from the lessons learned.
The use of prototypes has been common in engineering and in less formal approaches for building just about anything. For building physical objects, a prototype is often a model at reduced scale.
Cyclical processes
In contrast to sequential processes, in which a list of distinguished activities are done one after another, cyclical processes do the same thing over and over. The goal is that each cycle brings the development closer to its successful completion. The various cyclical processes choose different things to do over and over, and may have specific relations between successive cycles.
Spiral
The spiral software process is a cyclical model whose steps are not the activities of development (requirements, architecture, etc.) but rather four phases for addressing whatever problem has the greatest risk of causing the development to fail. For each cycle, developers follow these phases: 1. Each cycle addresses the highest-risk problem that the developers face. Determine the objectives of this cycle, the alternative solutions that may be considered, and the constraints that must be met. 2. Evaluate the alternatives. For each one, identify the risks involved and (if possible) figure out how to resolve them. 3. Develop the solution to this cycle's problem, and verify that it is acceptable. 4. Plan the phases of the next cycle (including, of course, deciding which problem now constitutes the highest risk).
Notice that at the end of each cycle, the developers have a product. Initially this product may be an overall concept; as the spiral process goes through successive cycles, the product becomes an implementation. Figure 7 shows an example application of the spiral process to a system's development. This figure is Boehm's original figure from his 1988 paper.
In the first (innermost) cycle of the example, beginning in the upper left quadrant,
1. the developers determine the objectives of the system;
2. then they do a risk analysis and produce a prototype as the second phase (evaluate alternatives, identify and resolve risks);
3. developers then do simulations (using the prototype), model problematic aspects, and run benchmarks. before choosing a concept of operation (probably we would call this an overview of the system); and finally
4. developers make a plan for determining the system's requirements and generally for the system's entire development and operational life.
In the second cycle of the example, developers determine the cycle's objectives, etc., and perform a more substantial risk analysis, then produce a second prototype. As in every cycle, they then do simulations, etc. In this cycle, they next develop and validate requirements for the system. In the planning phase they produce a plan for the development.
In the third cycle, the highest current risk is determined to be the software's architecture and design. The developers perform a risk analysis and produce yet another prototype (the third one). After further simulations, etc., the developers produce an architecture and design and validate and verify them. Finally, they plan the integration and testing.
In the fourth cycle, developers focus on detailed design and implementation. As always, they do a risk analysis and produce a prototype; this prototype is an operational one that can be evaluated in terms of the system's eventual operation. After simulations, etc., developers produce a detailed design; implement the modules and unit-test them; integrate the modules (probably in several steps at several levels) and test the results; and put the system through its acceptance test. At this point development may have reached a successful conclusion; if not, another cycle will be needed.
Unified
The Rational Unified Process or is perhaps the only one discussed here whose use was and is promoted and supported by a specific company whose business is based on it (Rational Software, now owned by IBM). RUP can be characterised as a spiral process, with each iteration driven by risk mitigation, within which the activities follow a waterfall or sashimipattern.
Iterations are grouped into four successive phases, one or more iterations per phase, in which first the early activities, then progressively later activities, are dominant:
- Inception
- Elaboration
- Construction
- Transition
and the activities are categorised into nine disciplines, comprising six engineering disciplines:
- Business Modelling
- Requirements
- Analysis and Design
- Implementation
- Test
- Deployment
and three supporting disciplines whose activities cross-cut the engineering disciplines:
1. Environment 2. Configuration and Change Management 3. Project Management
The distinctive features of RUP are in the details of its prescriptions for requirements, analysis, and design (specifically in how development knowledge from one artifact type directs the next kind), beneath the level of abstraction of software processes, and are not discussed here. The name Rational Unified Process arose from the history of the company promoting it. The company was originally named Rational Machines and produced Ada development tools in the 1980s. In the 1990s Rational hired or bought the company of each of the three prominent object-oriented methodology proponents (Booch, Rumbaugh, and Jacobson), whose competing design notations and processes and were analogous but distinct, after which they developed a single notation and a single process unifying the concepts behind all three, namely and RUP.
Incremental
An incremental process is one in which the functionality of the desired system is divided into small increments that are implemented and delivered one after another in quick succession. Each increment is chosen so that it expands on the previous one, and is small enough to produce quickly.The most important functionality is implemented first, in the earlier increments (Royce1990-tapm). The initial increment produces a running system that does next to nothing, but [does] it correctly (Brooks p.267). Builds are frequent, typically daily.
An incremental process has several advantages:
- Stakeholders start seeing results early, with the first increment, and are calmed.
- Developers start seeing results early, too, and are encouraged.
- If the system isn't turning out as the stakeholders expected, everyone finds out sooner.
- Short increment cycle times mean development is less likely to get seriously off track (there isn't time to).
- Daily build cycles mean each developers is forced to focus and fix bugs as they arise.
- Because everyone has to focus on what is important in order to prioritise system features and allocate them to increments, stakeholders and developers tend not to waste time on inessentials.
- Each increment (if well chosen) is of manageable size for the developers.
- Everyone is happier because the system is visibly working (incomplete, but working) from the beginning.
- Virtually all modern development processes are incremental.
The test-driven software process is the one followed for agile development, extreme programming, and similar approaches. It is an incremental approach in which each increment is defined by a new test. Each iteration of the cycle produces a running system that passes all its tests (Williams+Maximilien+Vouk2003-tddd).
- The cycle begins when a test is added for a new desired behaviour.
- The developers run all the tests on the current system; the new test is required to fail. It should fail, because it tests a behaviour that hasn't been implemented yet. The failure of the new test indicates that it isn't accidentally testing for something the software already does, or that a mistake in the new test makes it always succeed.
- If the new test doesn't fail, the developers have to back up, figure out why, and fix the test so it fails.
- The developers repeatedly write some code, and run the tests again; this may go on for some time. Typically some of the old tests will fail as the new code changes how the system behaves, until the system is fixed so that it passes all the old tests again. The old tests are acting as regression tests.
- Eventually the new code successfully implements the new behaviour without breaking any of the old behaviour, and the system passes all its tests.
- Of course, at this point the system works but its architecture and module design may be bad. If necessary, the developers refactor the system (change the form of the code without changing its meaning, or what it does) until the architecture and design are good enough.
- Now the system works properly (for the behaviours requested so far) and its architecture and design are fine. The stakeholders can try it out to see if they like what there is so far. If the system is good enough for the stakeholders, the development is complete. If not, the stakeholders request a new behaviour and the cycle begins again.
Agile describes a group of related development processes that are usually presented in opposition to traditional development processes such as the waterfall and spiral models. Agile development is characterised by an emphasis on small teams of skilled individual developers, changing requirements, frequent version deliveries, daily contact with stakeholders, possibly with one or more captive stakeholders that sit with the team constantly, and face-to-face interactions. See http://agilemanifesto.org/ for the principles behind agile development.
A related approach from the 1980's, Rapid Application Development or RAD, was similar to agile development in many ways but (as far as I can determine) was not test-driven.
Extreme Programming
Perhaps the most prominent agile methodology is the test-driven Extreme Programming, or (Beck2000-epee). In XP, a group of up to about a dozen highly-skilled developers and a stakeholder sit in the same room. The developers work in pairs. Requirements are expressed as tests, and the tests are the requirements. There is no documentation and no artefacts other than the tests and the code. Everything else is handled by face-to-face discussions (thus the need for everyone to be in one room).
Scrum.
The Scrum process organises development into a sequence of sprints, each of which results in a potentially usable product with an added increment of function. The tasks for each sprint are set, in consultation with a stakeholder representative, during a sprint planning meeting and cannot be added to during the sprint. Each task is typically expressed as a user story. Each sprint is time boxed: the end date of the sprint does not change. Tasks that can't be accomplished in time are returned by the team to the backlog for future consideration.
During a sprint, the team has a brief Daily Scrum meeting, facilitated by the designated Scrum master, in which team members say what they did yesterday, what they are going to do today, and what obstacles are in their way. No brainstorming or discussion is allowed; anything other than answering the three questions is deferred to meetings among the specific people involved. Scrum uses the sashimi process for the work process, and has some agile characteristics but is not test-driven and does not involve daily contact with stakeholders.
Takeuchi and Nonaka (1986) use the metaphor of rugby, and talk of moving the scrum downfield [p.138] to describe all members of a team moving en masse towards their goal, but don't specifically describe a scrum process. The Scrum software process appears to have been first described by DeGrace and Stahl (1990), who say it originated in camera and automobile development, and introduce it with If Scrum were applied to software development, it would go something like this. Beedle et al. (1999) and Rising and Janoff (2000) are important early reports on Scrum for software development.
