Softmake's Software Development System - Softmake's Contributing Principles

First Published (Original Date):

2006-12-28%

Last Modified (Date):

2021-08-08

Datetime Format:

EDTF with spaces.

From this survey of Steve McConnell's Rapid Development and other published Systems we derive our own Software Development System. We add or emphasize a few principles. Some of these are listed below.

Lifecycle

For our default lifecycle taxonomy we find it useful to think of have 16 phases overarched by four "Eras": Specification, Build, Delivery, and Maintenance.

Any lifecycle must allow some to-and-fro between the software development phases. See our default lifecycle method.

People

Ideally, all developers must be part of the whole lifecycle.

At the very least one software developer must be part of the whole lifecycle, from initial client meeting, to requirements gathering, specification writeup, to training, delivery, and maintenance. The Business Analyst to Programmer model is flawed. Furthermore it is preferable, although not necessary, that all software developers on the team be part of the whole lifecycle.

Requirements Solicitation Method

By default our Method for soliciting requirements (and getting them into a specification) is Throwaway Prototyping.

As mentioned under Fourth Generation System throwaway prototyping gives you the best of the Software Engineering and Agile systems.

You get your hands dirty with code and so a more likely to discover issues early;
You can do design spikes. That is, perform technological experiments.
The client and users have something concrete to look and think about whether this is the kind of thing they want;
The specification document may include a straight reference to screenshots of the prototype;

Developer System Synchronisation

There must be time scheduled to synchronize the Software Development System of all the Developers.

A classic mistake is to leave out essential tasks. A software project schedule must allow time for software developers on the team to coming to agreement on the software development system, and methods. That is, software developers must do some methodology. (See also Meta Issues, Who Does Methodology?). This is an essential task often overlooked.

In the following Martin Fowler writes of "process" and "methodology" where we write of "system"

A consequence of self-adaptivity is that you should never expect to find a single corporate methodology [system]. Instead each team should not just choose their own process [system], but should also actively tune their process [system] as they proceed with the project.
The New Methodology, Martin Fowler, last significant update 13 Dec 05, accessed 28 Aug 2006.

You can see a Developer System Synchronisation phase in our Default Lifecycle Taxonomy.

Specification

The software specification can only be completed after requirements gathering, architectural design, and detailed design phase.

There is often confusion about what a "specification" means. It is not the initial thoughts, however detailed and well crafted, that a client may write for a developer. It is not the notes the developer writes up after the first interview with a client. A software specification is properly conceived as:

Expressing consensus between developers and client.
Unique to that developer/client combination.
That which can not be written without interaction between developer and client.

Developers must take responsibility for the requirements and the specification. The developers must produce the specification.

The form it takes can only be directed by the developer. That is, even though parts of the specification may be written by the client it is the developer that must produce the specification.

Developers must take responsibility for drawing out requirements from client and expressing them in the specification. We don't blame the client for being vague, ambiguous, or contradictory about their requirements. We understand that being vague, ambiguous, and contradictory about requirements is a necessary feature, at the beginning, of the development process. It is up to us, as developers, to make the requirements specific, of clear meaning, consistent, and implementable. That's our job not the clients.

Specification document(s) must be completed before the coding phase starts. Client sign-off of the specification is a gateway milestone through which all projects must pass.

The chief exception to a general lack of distinction between phases, and eras, is that the specification must be completed before the coding phase (and the "build" era).

When done properly getting to specification sign off will take 40% to 60% of total project time. See Rapid Development, How long until specification sign off?

Updates

2021-08-08. Minor grammar and spelling fixes.