In the following post https://heraclitusonsoftware.wordpress.com/2008/11/21/software-hypothetical-question-1-given-a-situation-of-perfect-specificationrequirements-how-should-one-go-about-creating-the-piece-of-software/, I asked a hypothetical question; here is my response (so far):
Customer Involvement
In [1], Winston Royce, in 1970, writes of the importance of customer involvement in the development of software.
For some reason what a software design is going to do is subject to wide interpretation even after previous agreement. It is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery. To give the contractor free rein between requirement definition and operation is inviting trouble.
Fred Brooks in 1986 goes further in [2] saying:
Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements. For the truth is, the client does not know what he wants. The client usually does not know what questions must be answered, and he has almost never thought of the problem up the detail necessary for specification. Even the simple answer–“Make the new software system work like our old manual information-processing system” –is in far too simple. One never wants exactly that. Complex software systems are, moreover, things that act, that move, that work. The dynamics of that action are hard to imagine. So in planning any software-design activity, it is necessary to allow for an extensive iteration between the client and the designer as part of the system definition.
I would go a step further and assert that it is really impossible for a client, even working with a software engineer, to specify completely, precisely, and correctly the exact requirements of a modern software product before trying some versions of the product.
Our hypothetical situation removes the core need for customer involvement as outlined by Royce and Brooks above. However we must still expect the customer to be involved in the project for the following reasons:
- The customer has invested money (and time) in the project and will most likely require visibility on the progress of the development
- Even though the specifications were perfect, there is always the possibility that they were implemented incorrectly and somehow this problem has passed through our testing procedures. It is the customer who must finally verify that the implemented behavior is exactly what they required.
It would be extremely risky to not involve the customer and at the start of any project, this should be made clear that customer involvement is so important and an agreement should be made between the customer and development group about what form this involvement will take.
Approach to Analysis/Design
As the specification is perfect, one could argue that it makes sense to perform all the analysis and design up front before considering any implementation. That way we get it all correct in the first go and would be more efficient when it came to the task of writing the code. However there are a few problems with this approach:
- This approach assumes we can create a design for the entire system without making mistakes. This is highly unlikely as the complexity and size of systems grow.
- Typically we are not producing any working software when we are designing.
- Eventually we must implement the design with the technologies that are available. By trying to design the entire system or large majority of it up front, we are not learning anything from creating software with the technologies at hand and feeding that back into our design process.
The truth is that software is complex. And as we progress, we are developing more and more complex systems. The key to being successful at software is to reduce complexity wherever possible. It would make sense then to grow or evolve the system by incrementally developing the system. Thus not all the specification, or analysis or design or implementation or testing needs to be completed, we just need enough specification to get started, enough analysis and design based on what we know, enough implementation to implement this small chunk of the specification and enough testing to verify what we have done so far is correct.
Bibliography
[1] [http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf]
[2] [http://www.virtualschool.edu/mon/SoftwareEngineering/BrooksNoSilverBullet.html]
[2] [http://www.scribd.com/doc/4025086/No-Silver-Bullet-Essence-and-Accidents-of-Software-Engineering]
Heraclitus on software 