- Introduction
- Two Scenarios
- Inputs to Development
- Outputs from Development
- Stages of Development
- Development Life Cycle
- Conclusions
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Development Life Cycle
Although our presentation of the software development stages has been linear, the practice need not be (see Reference [2]). There are four common approaches for building database applications, described in the following sections.
Waterfall
The classic lifecycle paradigm is the waterfall approach. As Figure 5 shows, developers perform the software development stages in a rigid linear sequence with no backtracking with this approach.
){kind=link}
Figure 5 Waterfall approach: The waterfall approach is inflexible and unsuitable for most database applications.
The waterfall approach is suitable for well-understood applications with predictable outputs from analysis and design. It is also used in many contractual situations, especially for government projects (regardless of its suitability).
A waterfall is inappropriate for applications with substantial uncertainty in the requirements, which is true for most applications you will encounter. Too many organizations attempt to follow a waterfall when requirements are fluid. This leads to the familiar situation in which developers complain about changing requirements, and the business complains about an inflexible information systems (IS) organization. A waterfall approach also does not deliver a useful system until completion, which makes it difficult to assess progress and correct a project that has gone awry
Rapid Prototyping
With this approach (see Figure 6), you quickly develop a portion of the software, use it, and evaluate it. You then incorporate what you learned and then repeat the cycle. Eventually, you deliver the final prototype as the finished application, or switch to another approach after a few prototypes. You must quickly cycle through prototypes (typically, an iteration every two or three months) for this approach to succeed. Rapid prototyping focuses on the input of user interviews; if you can glean information from other input sources, you can reduce the number of prototypes.
){kind=link}
Figure 6 Rapid prototyping approach: Rapid prototyping facilitates software development by eliciting requirements from users.
Rapid prototyping promotes communication. You learn about the needs of the customer, and the customer learns what automation can provide. Thus, prototyping targets a core difficulty of software development—finding the true requirements. Rapid prototyping provides frequent checkpoints for assuring customers that development is going well. It also lets developers experiment with troublesome aspects of design and implementation. They can test a difficult algorithm, and find whether it works well before committing to a full implementation.
The prototype may be throwaway, or it may be gradually elaborated until you achieve a working system. This is the weakness of rapid prototyping: Often a prototype is unsuitable for enhancement, but you may receive business pressures to enhance it, nonetheless. The key to success is to be prepared to discard early prototypes. Prototypes should be enhanced only if they are successful in the field and have a robust architecture.
Incremental Development
Incremental development (see Figure 7) is similar to the waterfall approach, except that you partition the application and develop portions at a time. Multiple increments are delivered, and the accumulation becomes the finished application. (Contrast this with rapid prototyping, in which each deliverable replaces the preceding code.)
){kind=link}
Figure 7 Incremental development: You deploy multiple pieces of operational software that combine to form the complete application.
An advantage of incremental development is that you have frequent milestones. If you encounter difficulties, you can catch them early and adjust your practices.
The challenge is to find meaningful increments for development—breaking an application into pieces with few interdependencies. Ideally, the interfaces between the increments should be minimal and easy to define. Also, you must perform much up-front analysis; otherwise, subsequent changes can disrupt earlier increments. Most applications require substantial infrastructure effort before useful increments of functionality become apparent to the user. A business may combine several increments before deployment to simplify logistics.
Fourth-Generation Language
A fourth-generation language (4GL) is a framework for straightforward database applications that provides screen layout, simple calculations, and reports. A 4GL raises the level of the implementation medium closer to that of analysis. Analysis work still remains, but less effort is needed for design and implementation. If your application fits the 4GL framework, developers can construct it rapidly with few errors.
The advantage of a 4GL is reuse: Multiple applications leverage the same 4GL software. Typically, a 4GL is purchased from a vendor, so your organization need not develop it. With skillful use, the performance of a 4GL application can be quite good.
The drawback of a 4GL is the rigidity of the framework. Developers become accustomed to the paradigm; they may try to use it for inappropriate applications, such as those with complex computations. 4GLs also lack facilities for reusing application logic; developers must code similar forms repeatedly. 4GLs are sophisticated software and require an investment of time and effort to achieve proficiency.
Combining Approaches
You can combine the various approaches. For example, you might use rapid prototyping to flesh out requirements for difficult portions of incremental development. Sometimes, it is helpful to divide a large system into components and build the components with different approaches.
Table 2 summarizes the strengths and weaknesses of the software lifecycle approaches. There are several good alternatives for coordinating the stages of software development.
Table 2 Comparison of Lifecycle Approaches
|
Approach |
Strengths |
Weaknesses |
|
Waterfall |
Suitable for applications with predictable outputs. |
Copes poorly with fluid requirements. Does not deliver a system until completion. |
|
Rapid prototyping |
Elicits requirements. Provides milestones. Lets you experiment with troublesome issues. |
There may be business pressures to extend a fragile prototype. Must throw away code. |
|
Incremental development |
Delivers useful portions of an application. Provides milestones. |
Some problems are hard to partition. Must complete infrastructure before delivering functionality. |
|
Fourth-generation language |
Developers can build applications rapidly with few errors. |
Many applications do not fit a 4GL. A 4GL is another technology to learn. |