This first development paradigm is the most direct. In the waterfall paradigm the phases are performed in order. This does not mean that one phase must be finished before the next one begins, but that once a phase is finished it is not returned to.
This paradigm is called the waterfall model because it is like having a fountain with a series of basins at different levels. Water that falls out of one basin fills the one below. Similarly, when one has enough specifications together, even if they are not finished, one can begin design work; once enough of the design is complete, the implementation can begin.
The strength of this paradigm is its simplicity. Its weakness is its assumption that the development can proceed in such an orderly and linear manner. For example, specifications can often change in the middle of a project, because the user was misunderstood, or the implementation of the original specifications would be too expensive, or any number of other reasons. The waterfall paradigm doesn't easily accept such changes.
A prototype, in engineering, is a model of a device that can be used in tests before the production of the device begins. For instance, car makers often design a prototype of a new car that can be driven at test tracks and displayed at auto shows. The information gathered from these can be used to improve the design before the car is produced on the assembly line.
In computer science, a prototype is a rough version of a program, quickly created, that approximates the appearance of the final program but without all the final program's functions. The rapid prototyping paradigm has the programming team create a prototype as early in the process as possible.
This paradigm attempts to overcome some of the weaknesses of the waterfall model. One problem with the waterfall is that it is difficult to get the specifications correct when the user has nothing to look at. Most users are unable to visualize exactly what they want in a program interface, for example, but they will recognize a good interface when they see it. Often, the programming team spends considerable time creating detailed specification documents only to discover some fundamental misunderstanding has rendered much of the work useless.
With rapid prototyping, the team is not obsessive in capturing every detail in the initial specifications. Instead the specifications and design are painted with a broad brush to create a quick prototype. The users are shown the prototype, and their reactions to it help clear up any misunderstandings they may have had. Then more detailed specifications are created and development proceeds from there. Thus, this paradigm progresses through the first three phases twice, once quickly, and then again more slowly and carefully.
Prototyping also helps clarify the design. For example, if the program will use a technique the team hasn't used before, the prototype gives the team experience with the technique in a "throwaway" program. The team may then decide they need more information on the technique and additional training, or they may decide to return to another technique they know better.
One drawback to this paradigm is that creating the prototype adds to the development time. If the prototype uncovers problems in the specifications or design, the time spent on the prototype easily saves time elsewhere. But if the prototype uncovers no major issues, the team may believe the time was wasted. Also, if the prototype is too good - too close to the user's expectations - the users may press to have development continue using the prototype as a base, which horrifies the programming team because the prototype was not carefully built.
In rapid prototyping, the first three phases are performed twice. In the spiral paradigm, the phases of development are repeated over and over. Initially the specifications and design are broad and the resulting implementation is mostly show, much like a prototype.
As development progresses, the documentation becomes more specific and the program more detailed and functional. The term "spiral" is appropriate because it implies that the team circles around the program, coming closer to the desired result with each pass.
The spiral paradigm may seem very similar to rapid prototyping, but there are important differences. With rapid prototyping, the team creates a first program as a demonstration only, while in the spiral paradigm, there is no intention to throw away any of the work that is created. The spiral paradigm, like rapid prototyping, may suffer from a perception of slow progress.
A more recent paradigm that is gaining popularity is extreme programming. This paradigm is built more upon specific tenets than a rigid process plan. Extreme programming requires the programmers to build testing into code modules. That is, when a programmer adds new features to a program, the programmer also adds another block of code to test the first. That way, the entire program can be tested at any time, which aids in regression testing.
Another interesting tenet is team programming. Extreme programmers work in two-person teams sharing one computer. At any given time, one person is programming and the other is checking the work of the first or checking a reference manual.
Our website is not responsible for the information contained by this article. Webworldarticles.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.
This article was sent to us by:
Brendan Stonker at
02122011
1. Useful iPod Touch applications and settings
All articles in this directory are property of their respective authors. Additionally, read our Privacy Policy
© 2010 WebWorldarticles.com - All Rights Reserved. Partners: Gunblade Saga