Waterfall Method
The waterfall method is a variation of the systems development life cycle model used in software engineering. The method is seen as the classical approach to the systems development life cycle and essentially is a linear and sequential approach to software design. Each stage of the waterfall method has distinct goals and once those goals are met, the development moves on. The name from this method comes from its biggest draw back. Once water has passed over the edge of the waterfall it cannot go back, similarly, once a stage has been completed there is no going back to it (searchVB.com).
To the side (fig.1) is a diagram showing the several stages of the waterfall method. This shows clearly the linearity of this method. While this is one of its weaknesses it is also one of its strengths. Each stage can be designated to a separate team allowing for greater control on the project. The whole process can have deadlines set for each stage which should, in theory, make for the project being delivered on time. The stages of the waterfall method are as follows:
Fig 1. A diagram of the waterfall method (taken from the Monash University website)
Requirements
"The first and most obvious element of the analysis stage is the collection of business requirements" (Builder.com). The business needs are then determined by the project team, and requirements prioritized in terms of things that must be present as opposed to those things that are nice to have. (builder.com)
Design
The design phase is where the business requirements start to be translated into an IT solution. Decisions are made in terms of the underlying technology. For instance, will this be a Web application or client/server? Will the development require COBOL, Visual Basic, or Java? Will we use SQL Server, Oracle, or DB2? The technology utilized will be based on the needs of the project and the current technology architecture used by the company. Online processes are translated into screens and workflow definitions. Batch processes are defined. Online screen and report layouts are built. Basically, the entire solution is built on paper or using design tools. When this phase is complete, the solution can be turned over to the programmers to start implementing the solution in code (Builder.com).
The other thing that happens at this point is that the strategy documents are fleshed out into more detailed planning documents. For instance, the Training Strategy is used as input to create a Training Plan. The Training Plan describes in detail what classes will be built, who will build them, who will teach them, who will be taught, where the training will be held, what the outline of the classes is etc. Basically, just as the solution is designed, the training is also being designed in detail. Likewise, a Testing Plan, Data Conversion Plan, and Implementation Plan are created to guide the detailed activities necessary for construction.
Implementation
The fully tested solution is now ready to be implemented. This could be as easy as saying that we are now live, or it could be as complicated as integrating a complex series of related applications across multiple locations – it could be a huge project by itself, almost. However, if an Implementation Strategy and Implementation Plan has been made, this now becomes a matter of execution. Implementation may still be complex, but at least you don't have to figure out everything from scratch. Depending on the timing of the project, their may also be training at this point (builder.com).
Evaluation/Maintenance
At this point the end-users evaluate the product. Does the software suit their needs? Does it fill all the requirements? It is likely at this stage that the users will identify things that are needed that have been missed or extras that they'd like. This is where maintenance comes in. Maintaining consists of two things in the instance of the waterfall method. Firstly it's making sure everything runs smoothly but, because being able to change the software is a practical impossibility with the waterfall method it involves going back to the beginning again and coding a solution to the problems or shorting comings of the current iteration of the software (Builder.com).
Agile Method
The agile method is a low-overhead method that minimizes risk by making sure that software engineers focus on smaller areas of work. It emphasises values and principles rather than processes. Agile methods work in cycles, typically of a week or a month, and at the end of each cycle, the priorities of the project are re-evaluated. This is similar to iterative methodologies which also re-evaluate at regular intervals.
The four main principles of the agile methods as described by the Agile Alliance are to value:
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
(www.agilemanifesto.org)
Poinsignon (2002) points out the main difference between Agile methods and classic methods, which he says is that
"the paradigm is predictability for classic and adaptability for Agile."
Agile methods try to keep overheads such as rationale, justification, documentation and meetings as low as possible. One of the key elements of reducing these overheads is ‘replacing before-the-fact permissions with after-the-fact forgiveness' (Thefreedictionary.com). As a result, agile methods are mainly seen to benefit small teams where the requirements are often changing, rather than larger projects.
An example of the way that overheads are reduced might be that of AgileSoftwareDevelopment (http://c2.com/cgi/wiki?AgileSoftwareDevelopment) where only the edits that return the project to a testable state are performed, meaning that everything is tested that is relevant to a module after ‘the fewest possible edits' (The Real Definition of Agile).
Alistair Cockburn sums agile methods up fairly neatly, by describing them as being "both light and sufficient, where lightness means maneuverability and sufficiency means facilitating future development" (The Real Definition of Agile). Cockburn then goes on to identify five "sweet spots" to characterize agility, relating to things such as team size and composition, frequency of feedback and other similar characteristics.
Finally, to sum up this definition of agile, the words of Ken Schwaber at an eWorkshop in 2002:
"...it is based on empirical methods rather than defined methods. Defined methods are when you plan what you want and then enforce it. Agile, you lightly plan what you want and then adapt to what you get." - First eWorkshop on Agile Methods
An example of an Agile Method: Extreme Programming (XP)
Extreme Programming is defined by its creators as a deliberate and disciplined approach to software development (extremeprogramming.org). It has its emphasis on teamwork and customer satisfaction, which is what has given XP its success in the software design field. There are four essential ways that the creators feel XP improves a software project:
- Communication between customers and other team members;
- Simple, clean designs;
- Feedback as a result of beginning software testing on day one;
- Delivery to the customer as early as possible, and the implementation of suggested changes (extremeprogramming.org).
In essence, extreme programming is a bit like BBC Bitesize – by cutting down the big picture into smaller chunks, it is easier to digest and work out. The basis of this idea of simplicity is in the belief that those who say that software engineered to be simple and elegant is no longer valuable – are wrong.
Extreme Programming is governed by a set of rules and practices listed on their website. These are broken down into planning, designing, coding and testing. To briefly sum up, however, the planning begins with a user story, written by the customer. The project is then divided up into iterations, and fixes carried out as necessary. The design is kept as simple as possible, using CRC cards for design sessions and reducing risks with spike solutions. Through the coding, the customer must always be available, and all production code (coded after the unit test) is pair programmed. Integration occurs as often as possible, only one pair at a time. During testing it is important that all code must have unit tests to pass before it is released, and when bugs are found then new tests are created.
Fig. 2 A diagram of the Extreme Programming methodology (Source: http://extremeprogramming.org)
In summary, XP is a software methodology that gains its success from an emphasis on simplicity, customer involvement and teamwork (extremeprogramming.org).
Why an agile method would be more appropriate than a Waterfall method for the next C++ project
There are reasons to support both waterfall and agile methods. However, after looking more closely at these it will be clear why an agile method is the more appropriate choice in this case.
First, and most important: as mentioned earlier, once one stage of the waterfall method has been completed, going backwards is practically impossible. This of course makes most software designed and implemented under the waterfall method harder to change with the times and user needs. The common fix to this problem is to go back and design an entirely new system, which is both costly and inefficient. It must be noted here, however, that there is a view that says the waterfall method was in fact designed to be iterative (Presson on CMM) although this is a minority viewpoint. The agile methods, on the other hand do, as the word agile suggests, adapt to change. Their approach to software design and implementation is one which means that at the end of each stage you have a logical program, designed from the outset to cope and adapt with new ideas and to change easily. This may involve a modular approach to the programming, so that if changes are necessary the whole program does not need to be rewritten, thus reducing the overheads. This is also useful when looking at upgrading programs.
Another major advantage of agile methods is that not only do you have a launchable product after each stage, but the program is also tested at the end of each stage. This means that bugs are caught sooner in the development cycle, and as such can be eliminated and new tests brought in to double-check for them. This is very different to the waterfall method whereby the product is tested only at the end, and due to the nature of the waterfall method it is difficult to change the program when bugs are found in this test, as the program has been written by this stage.
Due to its modular nature, therefore, object-orientated design and programming, such as C++, is much more suited to agile methodology. For example, you would be able to design a C++ project in terms of objects, and code these as separate modules, thus allowing you to test them before integration to reduce the number of bugs you have to deal with when testing the final project.
As already discussed, when using agile methodology you will always have a working model that you can release, whereas with the waterfall method there will only be one main release. Therefore, if this main release has a problem delays will occur, which does not help customer satisfaction. When using agile methods, however, a working program can be released on time although it may not always fulfil the entire specification. This would therefore be useful for a C++ project as the manager would be able to be continually updated with progress.
The agile method can always be changed to the end-user's liking. If the specification of the project is changed, therefore, this is allowed for in the adaptability of agile methodology, which means that customers are easily accommodated. This is not possible in the waterfall method, as already mentioned, where a change in the requirements would mean that the project would have to start all over again.
Both methodologies allow for some sort of departmentalisation. In the case of waterfall, this can be done at each stage, while in the case of agile each module of coding can be delegated to separate groups. This means that both methods are fairly quick as several parts can be done at once, although it is used more effectively in agile methodologies than in waterfall methodologies which still require you to go through each stage in turn.
On the plus side, waterfall has defined stages and elements of said stages and allows for thorough planning especially for deployment, so when you do get a product finished deploying can often be a matter of executing the agreed plan.
To conclude, the adaptability of the agile methodology makes it the sound choice for the next C++ software development project to be carried out. Although the waterfall method does lend itself to a logical design, implementation and deployment, its lack of future proofing is also a major drawback. As a result, I would choose to use an agile methodology such as extreme programming.
References:
searchVB.com
Builder.com
Monash University website
The Agile Manifesto
AgileSoftwareDevelopment
The Free Dictionary
Poinsignon, E (2002) Introduction to Agile Method Movement
Cockburn, A The real definition of Agile
Schwaber, K (08/04/2002) cited in The First eWorkshop on Agile Methods
Extreme Programming.org
Presson, S Presson on CMM
Written by s33r (11 December 2004)
C/O of Knowledge-Bank Tutorial Writers
This article was originally published by CyberArmy.net in the CyberArmy Library.
|
|