Nice article, though i completely disagree. While Waterfall may have some problems, there's no reason to throw out the baby with the bathwater.
The Waterfall method is not just to get requirements and start coding. Waterfall works within the overall code writing process, which includes designing the code itself. Pseudocode is the best way to do it, though it unfortunately is unpopular. The idea is, get the requirements, find a solution (specification), design the code (pseudocode), and then code flawless software.
The major issue here is not the coding. It is that the customers rarely know what they want. They think they do, but they don't. They'll know it when they see it. So, they sign off on a requirements document, without really knowing what the product will be. The issue, however, is not the requirements document. It's that the requirements and specifications are often converged into one document. That's bad.
The solution to that is to have both a requirements document and a specification document. But, what are they? A requirements documents states the problem that needs solving, and a determination of what is required to solve it. Hence the name requirements. It is written by the customer, as it is their way of communication what they need. For example: we need an accounting system to handle internal spending. Then go into details about the requirements, not the solution. Meetings are then had to understand the requirements. When the document is completely understood, it should need no further change.
The specification document is completely different. First, it is written by the development (or UI) team. It specifies a solution, including things like mockup screenshots and anything else that the customer will interface with. No backend information need be mentioned, unless the customer will be using that too. This document specifies how it will respond and what it will produce.
Often, this is called a Use Case document. However, Use Cases are subsidiary to the specification. The specification mentioned every aspect, whereas Use Case to a subset of them. Though, enough Use Case documents could be used in lieu of a specification.
The specification document generally goes through many cycles. Alternatively, mockups can go through the cycles with a specification document written at the end. Either way, there are many cycle. The Agile method has much to offer here. Design the UI quickly, and with the customer involved every step of the way. The customer will see it, experience it, and respond. Now the customers know what they want, and can agree to the final look.
After that, design is done. Design the data model, if there is one, and how the code will work. And go from there. As the customer doesn't care how it works, reviewing the various phases with the customer achieves nothing. Just release it when it is done.
Overall, Waterfall works well. However, if the steps are not followed, nothing will work. All Agile does is minimize the damage, but takes longer and works against consistency in the backend.
In reply to Re: Beyond Agile: Subsidiarity as a Team and Software Design Principle
by chacham
in thread Beyond Agile: Subsidiarity as a Team and Software Design Principle
by einhverfr
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |