chris clarke
software development that works…or something
Origins of Waterfall Software Development
April 9, 2007 on 7:14 pm | In Uncategorized |No-one knows the exact origin of the term ‘waterfall’. It was apparently coined when someone looked at a diagram in Dr. Winston Royce’s paper and remarked it resembled a waterfall. In fact the origin of the entire ‘waterfall model’ of software development is very sketchy. It is said to originate from a misunderstanding of the paper Managing the Development of Large Software Systems, written by Dr. Winston Royce in 1970.
Artists Impression of Dr. Winston Royce.
The story goes that somehow Royce’s initial diagram of a process which did not work was adopted as what we now know as the ‘waterfall model’. And was later adopted as a US Department of Defense standard (DOD-STD-2617) in 1985 and shipped across Europe in to Government and Defence projects though NATO.
From what I understand about the waterfall model, and from what I was taught, you proceed through each of the phases once, and each phase must be completed and perfected before moving on to the next. However, reading Royce’s paper, he makes it abundantly clear, on page 2, that this is not a good idea:
The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.
Royce then goes on to present five steps which can help prevent such a thing happening:
- Complete the coding design before analysis and coding begins - The paper was written in a time when there were a lot of technical constraints, on data size, execution time etc… Royce had found that these things had become problems later on in projects so he introduced this stage before the Analysis stage in an attempt to catch these problems earlier. A program designer would take part in the Analysis phase making the customer aware of storage, timing, and operational constraints.
- Documentation must be current and complete - Royce was a stickler for documentation - he used it to try and control projects and make sure that they met requirements and interface definitions. One interesting thing he mentions is that programmers should not test their own code and in this respect he saw documentation as a kind of acceptance criteria for how the software should behave - so that a separate team of testers could test the software according to the documentation.
- Do the job twice if possible - Royce advocated the whole lifecycle process be repeated in miniature at the start of the project in order to:
… quickly sense the trouble spots in the design, model them, model their alternatives, forget the straightforward aspects of the design which aren’t worth studying at this early point, and finally arrive at an error-free program.
- Testing must be planned, controlled and monitored - The previous three steps were targeted at uncovering as many bugs as possible before hitting the test phase. In this phase, Royce recommends some methods of uncovering more problems including code review.
- Involve the customer - Royce wanted to involve the customer as much as possible to ensure the software was closer to what the customer wanted however, in his diagrams the customer is mainly involved during design and then at the end of the project.
Having read Royce’s paper, I don’t think the document has been misunderstood as stated from several sources, I think the versions of most projects match quite closely to Royce’s guidelines - plenty of documentation, plenty of analysis and design, strict adherance to specification documents and customer involvement missing at important points. I suspect that even ‘Doing it twice’, which seems like a good idea, has been proposed during a waterfall project, but probably dismissed as a waste of time and money.
I think Royce was trying to improve a software development process which was pretty immature at the time. The most common process which people were using at the time, looked a lot like this:
Royce exposed a lot of the hidden stuff that happened around this, including important practices such as testing. He also had a lot of the right motivation to catch problems earlier and involve the customer more. Although some of his ideas have perhaps been proven to be not so helpful in the long run.
No Comments yet »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Origins of Waterfall Software Development
April 9, 2007 on 7:14 pm | In Uncategorized |No-one knows the exact origin of the term ‘waterfall’. It was apparently coined when someone looked at a diagram in Dr. Winston Royce’s paper and remarked it resembled a waterfall. In fact the origin of the entire ‘waterfall model’ of software development is very sketchy. It is said to originate from a misunderstanding of the paper Managing the Development of Large Software Systems, written by Dr. Winston Royce in 1970.
Artists Impression of Dr. Winston Royce.
The story goes that somehow Royce’s initial diagram of a process which did not work was adopted as what we now know as the ‘waterfall model’. And was later adopted as a US Department of Defense standard (DOD-STD-2617) in 1985 and shipped across Europe in to Government and Defence projects though NATO.
From what I understand about the waterfall model, and from what I was taught, you proceed through each of the phases once, and each phase must be completed and perfected before moving on to the next. However, reading Royce’s paper, he makes it abundantly clear, on page 2, that this is not a good idea:
The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.
Royce then goes on to present five steps which can help prevent such a thing happening:
- Complete the coding design before analysis and coding begins - The paper was written in a time when there were a lot of technical constraints, on data size, execution time etc… Royce had found that these things had become problems later on in projects so he introduced this stage before the Analysis stage in an attempt to catch these problems earlier. A program designer would take part in the Analysis phase making the customer aware of storage, timing, and operational constraints.
- Documentation must be current and complete - Royce was a stickler for documentation - he used it to try and control projects and make sure that they met requirements and interface definitions. One interesting thing he mentions is that programmers should not test their own code and in this respect he saw documentation as a kind of acceptance criteria for how the software should behave - so that a separate team of testers could test the software according to the documentation.
- Do the job twice if possible - Royce advocated the whole lifecycle process be repeated in miniature at the start of the project in order to:
… quickly sense the trouble spots in the design, model them, model their alternatives, forget the straightforward aspects of the design which aren’t worth studying at this early point, and finally arrive at an error-free program.
- Testing must be planned, controlled and monitored - The previous three steps were targeted at uncovering as many bugs as possible before hitting the test phase. In this phase, Royce recommends some methods of uncovering more problems including code review.
- Involve the customer - Royce wanted to involve the customer as much as possible to ensure the software was closer to what the customer wanted however, in his diagrams the customer is mainly involved during design and then at the end of the project.
Having read Royce’s paper, I don’t think the document has been misunderstood as stated from several sources, I think the versions of most projects match quite closely to Royce’s guidelines - plenty of documentation, plenty of analysis and design, strict adherance to specification documents and customer involvement missing at important points. I suspect that even ‘Doing it twice’, which seems like a good idea, has been proposed during a waterfall project, but probably dismissed as a waste of time and money.
I think Royce was trying to improve a software development process which was pretty immature at the time. The most common process which people were using at the time, looked a lot like this:
Royce exposed a lot of the hidden stuff that happened around this, including important practices such as testing. He also had a lot of the right motivation to catch problems earlier and involve the customer more. Although some of his ideas have perhaps been proven to be not so helpful in the long run.
No Comments yet »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Powered by Cheese.
RSS Entries Feed.
RSS Comments Feed
^Top^