Life Cycle Concept Considered Harmful, McCracken, D and Jackson, M, 1982.
As one can probably tell from the heading, this article is another critic of the life cycle concept. The paper describes a conventional waterfall model at the start of the paper with 10 steps involved (there are many variations to the SDLC, but they are all considered waterfall models). They criticise the waterfall model on 3 grounds;
3. "The life cycle concept rigidifies thinking" and so becomes less permeable to change. Change is inevitable in SW development, particularly as time goes on and progress is made. The process opens up to the customer and portrays images of what they then believe to be possible or not, what they want the system to do and what it shouldn't do.
The authors suggest two alternatives to the SDLC, which resemble insights from other authors that I have discussed in other readings. The first alternative they offer is to build a prototype from very early on in the process. This draws from the pilot model discussed by Royce, and also draws on the idea that objectives are more robust than requirements or specifications. The suggest that the "prototype itself furnishes the specifications"
The authors also suggest a process of design involving the end user at all stages of design, and propose these stages "Implement, design, specify, re-design, re-implement" This provides end user with product increments thought to be potentially useful, where they can learn capabilities of the tool, design and specification of the desired system.
There seems to be a recurring theme in Software development literature. That is, the sdlc, while it may provide guidance, is not without its flaws. It is not receptive to changes that will inevitably occur. Changes in requirements and specifications, and changes in the environment. In order to manage such change, involving the end user from phase 1 of development through to the final product is advised. Within the literature I have studied, many are also crtitical of the lack of feedback channels. Feedback keeps design parralell with what end users want. Finally, many authors have recommended pilot products, or prototypes, or working product increments. The SDLC is by no means a useless tool, however some variation in the process is to be expected if it is to be considered a success.
Reference: McCracken, D, and Jackson, M, (1982), "Life Cycle Concept Considered Harmful", Software Engineering Notes, Vol 7, No. 2, April 1982
As one can probably tell from the heading, this article is another critic of the life cycle concept. The paper describes a conventional waterfall model at the start of the paper with 10 steps involved (there are many variations to the SDLC, but they are all considered waterfall models). They criticise the waterfall model on 3 grounds;
- The life cycle is "a project management structure imposed on system development", it"assumes a life cycle so rudimentary as to be vacuous". They even refer to the model as "foolish" with regards to future education on SW development.
- "The life cycle concept perpetuates our failure to bridge the communication gap between end user and system analyst". The authors state that the SDLC ignores such things as the following - (1) eliminate the need for communication (is the author suggesting we all become programmers and analysts here, as he describes "the widest possible development of systems by end-users themselves", (2) Involvement of the end user in all phases of development, (3) systems requirements can't be stated fully in advance. Generally, the customer does not know what they want until you tell them.
3. "The life cycle concept rigidifies thinking" and so becomes less permeable to change. Change is inevitable in SW development, particularly as time goes on and progress is made. The process opens up to the customer and portrays images of what they then believe to be possible or not, what they want the system to do and what it shouldn't do.
The authors suggest two alternatives to the SDLC, which resemble insights from other authors that I have discussed in other readings. The first alternative they offer is to build a prototype from very early on in the process. This draws from the pilot model discussed by Royce, and also draws on the idea that objectives are more robust than requirements or specifications. The suggest that the "prototype itself furnishes the specifications"
The authors also suggest a process of design involving the end user at all stages of design, and propose these stages "Implement, design, specify, re-design, re-implement" This provides end user with product increments thought to be potentially useful, where they can learn capabilities of the tool, design and specification of the desired system.
There seems to be a recurring theme in Software development literature. That is, the sdlc, while it may provide guidance, is not without its flaws. It is not receptive to changes that will inevitably occur. Changes in requirements and specifications, and changes in the environment. In order to manage such change, involving the end user from phase 1 of development through to the final product is advised. Within the literature I have studied, many are also crtitical of the lack of feedback channels. Feedback keeps design parralell with what end users want. Finally, many authors have recommended pilot products, or prototypes, or working product increments. The SDLC is by no means a useless tool, however some variation in the process is to be expected if it is to be considered a success.
Reference: McCracken, D, and Jackson, M, (1982), "Life Cycle Concept Considered Harmful", Software Engineering Notes, Vol 7, No. 2, April 1982