There are two different alternatives to the system life cycle learned during our last lecture: prototyping and RAD (rapid applications development).
However, after searching information in the internet, I found there is not only prototyping and RAD but also consists of Build-and-fix, Extreme programming, Spiral and also Iterative.
Build-and-Fix Model
The build-and-fix model was adopted from an earlier and simpler age of hardware product development. Those of us who bought early Volkswagen automobiles in the 1950s and ’60s remember it well. As new models were brought out and old models updated, the cars were sold apparently without benefit of testing, only to be tested by the customer. This always works best in a monopolistic or semimonopolistic environment, in which the customer has limited access to alternative vendors.
Build-and-Fix Software Development Model
Waterfall Model
The classic waterfall model was introduced in the 1970s by Win Royce at Lockheed. It is so named because it can be represented or graphically modeled as a cascade from establishing requirements, to design creation, to program implementation, to system test, to release to customer. It was a great step forward in software development as an engineering discipline.
Waterfall Model for Software Development
Rapid Prototyping Model
Rapid prototyping has long been used in the development of one-off programs, based on the familiar model of the chemical engineer’s pilot plant. A throwaway prototype approach is often used if the goal is to test the implementation method, language, or end-user acceptability. If this technology is completely viable, the prototype may become the basis of the final product development, but normally it is merely a vehicle to arrive at a completely secure functional specification. From that point on the process is very similar to the waterfall model. The major difference between this and the waterfall model is not just the creation of the operational prototype or functional subset; the essence is that it be done very quickly—hence the term rapid prototyping.
Rapid Prototyping Model
Incremental Model
The incremental model recognizes that software development steps are not discrete. These builds are not the versions released to the public but are merely staged compilations of the developing system at a new level of functionality or completeness. The incremental model is a variant of the waterfall and rapid prototyping models. It is intended to deliver an operational-quality system at each build stage, but it does not yet complete the functional specification.
Incremental Model
Extreme Programming
Extreme Programming (XP) is a rather recent development of the incremental model that puts the client in the driver’s seat. Each feature or feature set of the final product envisioned by the client and the development team is individually scoped for cost and development time. The client then selects features that will be included in the next build (again, a build is an operational system at some level of functionally) based on a cost-benefit analysis. This development model is distinguished by its flexibility because it can work in the face of a high degree of specification ambiguity on the user’s part.
Extreme Programming Model
Sources: http://www.extremeprogramming.org.
Spiral Model
The spiral model, developed by Dr. Barry Boehm, is an enhancement of the waterfall/rapid prototype model, with risk analysis preceding each phase of the cascade. This model has been successfully used for the internal development of large systems and is especially useful when software reuse is a goal and when specific quality objectives can be incorporated. It does depend on being able to accurately assess risks during development. This depends on controlling all factors and eliminating or at least minimizing exogenous influences. Like the other extensions of and improvements to the waterfall model, it adds feedback to earlier stages. This model has seen service in the development of major programming projects over a number of years, and is well documented in publications by Boehm and others.
Spiral Model
Object-Oriented Programming
Object-Oriented Programming (OOP) technology is not a software development model. It is a new way of designing, writing, and documenting programs that came about after the development of early OOP languages such as C++ and Smalltalk. However, OOP does enhance the effectiveness of earlier software development models intended for procedural programming languages, because it allows the development of applications by slices rather than by layers. The central ideas of OOP are encapsulation and polymorphism, which dramatically reduce complexity and increase program reusability.
Round-Tripping Model
Iterative Development or Evolutionary Model
The iterative development model is the most realistic of the traditional software development models. Rather than being open-loop like build-and-fix or the original waterfall models, it has continuous feedback between each stage and the prior one. Occasionally it has feedback across several stages in well-developed versions. In its most effective applications, this model is used in an incremental iterative way. That is, applying feedback from the last stage back to the first stage results in each iteration’s producing a useable executable release of the software product. A lower feedback arrow indicates this feature, but the combined incremental iterative method schema is often drawn as a circle. It has been applied to both procedural and object-oriented program development.
Iterative Model of Software Development
Comparison of Various Life-Cycle Models
Table 1.1 Comparison of Traditional Software Development Models
| Model | Pros | Cons |
| Build-and-fix | OK for small one-off programs | Useless for large programs |
| Waterfall | Disciplined, document-driven | Result may not satisfy client |
| Rapid prototyping | Guarantees client satisfaction | May not work for large applications |
| Extreme programming | Early return on software development | Has not yet been widely used |
| Spiral | Ultimate waterfall model | Large system in-house development only |
| Incremental | Promotes maintainability | Can degenerate to build-and-fix |
| OOP | Supported by IDE tools | May lack discipline |
| Iterative | Can be used by OOP | May allow overiteration |
No comments:
Post a Comment