Softmake's Software Development System - Lifecycle

What is a lifecycle?

The "full software development lifecycle" could describe the period from initial recognition of the need for a software application to the time version 5.63 is uninstalled off the last user's computer. It is the "process" of software development (which includes maintenance). Here "software development lifecycle", or just "lifecycle", will refer to the shorter period between integer releases, e.g. between initial idea and 1.0, between 2.0 and 3.0, or for analogous periods of development for websites.

We do well to distinguish:

1. Lifecycle taxonomy: a categorization of the development activities; from
2. Lifecycle method (aka "the process"): structuring the development activities are over time. E.g Evolutionary Prototyping; Throwaway Prototyping; Spiral; below Waterfall; Staged Release.

Different software projects will generally warrant different lifecycle taxonomies and methods. However, we have a default lifecycle taxonomy and method to serve as a starting point for departure.

Default lifecycle taxonomy

Table notes:

1. Developer System Synchronization: For projects requiring more than one developer disparate Software Development Systems need to be resolved. For example, Okcana's preferred Software Development System is extreme programming; Jack's preference is for Rapid Application Development. We need to mesh these. For a justification see Meta Issues, Who Does Methodology?
2. Wireframes: A diagram of the basic structure of a web page or pages. For example, Menu type and placement, footer and headers, logos, and page title. Content and graphic design is excluded.
3. You, the client, sign off the specification as representing what you wish. We quote against this specification.
4. Acceptance Testing: Automatic and/or user conducted testing (directed by the developer) to verify to you, the client, that the system works according to specification.

Default lifecycle method

The pure, or "classic", waterfall model is rightly satirised. When Winston Royce coined the "waterfall" lifecycle (Managing the Development of Large Software Systems, Proceedings of IEEE WESCON, August 1970, 1-9. Accessed 2021-06-23) he did so in order to illustrate an alternative. A pure waterfall lifecycle method is not wise.

However in avoiding the traps of the pure waterfall lifecycle method we don't have to abandon the model entirely.

Minimally, and as mentioned under Rapid Development System, regardless of which lifecycle method you choose the subphases identified in Pure Waterfall are essential to software development (McConnell 1996 p143). To succeed you can't avoid these subphases. We choose to give more detail by further subdividing those subphases and grouping them into phases, as above.

Our default lifecycle method is a modified waterfall method combined from:

1. Waterfall with overlapping subphases. "Sashimi" (McConnell 1996 p143).
2. Waterfall with to-and-fro between the subphases. Although we have overlap and to-and-fro between the subphases, we will be able to make progress visible by identifying the which subphase we have arrived at. That is, progression maintains a large degree of linearity.
3. Waterfall with risk reduction in the specification phase. (See "Waterfall with risk reduction" McConnell 1996 p146).
4. Throwaway prototyping. This can be considered to be a requirements solicitation method. It is the chief tool to reduce risk in the specification phase.
5. A Specification Gateway. The build phase doesn't start until the specification is signed off by the client.

This lifecycle method is partly justified under A Simplified History Of Software Development.

Feature 2. is worth expanding on:

Any lifecycle must allow some to-and-fro between the software development subphases.

Many authors have written about this necessity. That to-and-fro is required can perhaps be best understood through Jack Reeve's lens. Everything is design:

The overwhelming problem with software development is that everything is part of the design process. Coding is design, testing and debugging are part of design, and what we typically call software design is still part of design...

On any software project of typical size, problems like these are guaranteed to come up. Despite all attempts to prevent it, important details will be overlooked...

Programming is a design activity...

There are other design activities -- call them top level design, module design, structural design, architectural design, or whatever. A good software design process recognizes this and deliberately includes the steps...

In software engineering, we desperately need good design at all levels. In particular, we need good top level design. The better the early design, the easier detailed design will be...

All design activities interact.

What is Software Design?, Jack W. Reeves, C++ Journal - 1992, accessed 2021-06-23. Emphasis original.

If everything is understood as design it becomes apparent why to-and-fro between the subphases may be needed regardless of what formal subphase you are currently in.

For example, when you are in the nominal "code" subphase you may unearth a design choice. It may be necessary to phone the client: a kind of jumping back to the requirements gathering subphase.

Conversely, during the nominal "requirements gathering" subphase the options you can offer the client will depend on what's technically feasible. You may have to do some experimental coding (known as a "design spike" in extreme programming) to determine those options: a kind of jumping ahead to the code subphase.

References

• McConnell, Steve. 1996. *Rapid Development: Taming Wild Software Schedules*. 1st edition. http://www.amazon.com/Rapid-Development-Steve-McConnell/dp/1556159005. Microsoft Press, 1996-07-02.

Updates

• 2021-06-23. Some updating of links.