The database development life cycle

Describes the four common approaches for building database applications: waterfall, rapid prototyping, incremental, and 4GL.

To ensure extensible, flexible and fast applications, database developers should heed tried-and-true software engineering principles. The typical stages of database application development--and indeed all types of development-- include analysis, design, implementation, data conversion, testing, training, and maintenance. This article from InformIT discusses four common approaches to building software applications:

Waterfall

The classic life cycle paradigm is the waterfall approach. Developers perform the software development stages in a rigid linear sequence with no backtracking with this approach.

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.

Summary:

Strengths - Suitable for applications with predictable outputs.

Weaknesses - Copes poorly with fluid requirements. Does not deliver a system until completion.

Rapid Prototyping

With this approach, 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.

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.

Summary:

Strengths - Elicits requirements. Provides milestones. Lets you experiment with troublesome issues.

Weaknesses - There may be business pressures to extend a fragile prototype. Must throw away code.

Incremental Development

Incremental development 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.)

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.

Summary:

Strengths - Delivers useful portions of an application. Provides milestones.

Weaknesses - Some problems are hard to partition. Must complete infrastructure before delivering functionality.

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.

Summary:

Strengths - Developers can build applications rapidly with few errors.

Weaknesses - Many applications do not fit a 4GL. A 4GL is another technology to learn.

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.

To read more of this article click over to InformIT. Registration is required, but it is free.

For More Information


This was first published in June 2001

Dig deeper on Oracle database design and architecture

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchDataManagement

SearchBusinessAnalytics

SearchSAP

SearchSQLServer

TheServerSide

SearchDataCenter

SearchContentManagement

SearchFinancialApplications

Close