DATABASE

NOTES
DB LIFE CYCLE

Database Life Cycle Stages

Database is any software package created and implemented for managing data files in an organized
and digital format. The purpose of any database software is to effectively manage and handle large
sets of data and, for this reason, its development and implementation is carefully observed and
documented so as to avoid any malfunctioning during its operational period. This observation and
documentation process of a database program is formally known as database lifecycle, which
consists of five major stages. These stages of database lifecycle represent the phases through which
this program is actually planned, developed, evaluated and implemented in practical environments.
Moreover, if a problem (or a loophole) is detected at any stage, the lifecycle is rolled-back (or
restarted) to eliminate it, to produce an effective database software.

Planning
The first stage of a database development lifecycle involves collection of necessary
information, and preparation of a theoretical framework regarding the requirements for which
the database program is developed. It is in this stage that a developer plans a platform over
which the database program is to be designed, allocates a budget associated with the process,
and settles a timeline in which the process of development and implementation is to be
completed.

Analysis
The analysis stage involves critical evaluation of the database development planning carried
out beforehand. In this stage, more than one developer (or a team of developers) assesses the
plan of database development against the elements like cost, time-period, development
platform (like programming languages), and forecasted development results, to analyze the
effectiveness associated with the planned database program. In simple terms; this phase
involves analyzing the plan and finding any loopholes that exist within the database
development plan.

1
Design/Development
A database program (after careful planning and analysis) is designed or developed in this
third stage of database lifecycle. It is in this stage that all the logical design parameters of
database operations are finalized, and the program development is carried out under a
specified time period. Upon the completion of this design stage, a complete database software
package is made available, with all the technical limitations and loopholes addressed in the
previous two stages. Furthermore, this finalized version of the database program is usually
checked for its operational effectiveness (in the design/development stage) before its taken
into the next stage of implementation.

Implementation
In this stage, the developed program is implemented over the given set of data values (information)
and its operational parameters are finally brought into action over pre-defined tasks. This means
that, in the implementation stage, the developed database program starts working as user-
controlled software, aimed to manage a pre-existing pool of data for the desired tasks.

Maintenance
The fifth stage of maintenance is usually a prolonged stage, representing the entire period
which is allocated for testing, managing, troubleshooting and maintaining the features of
developed database program. This stage normally begins right after the implementation of a
database program, and lasts until any considerable problem occurs with the database,
requiring it to be re-designed or re-planned for another cycle of implementation.

A development life cycle

Database development is just one part of the much wider field of software engineering, the
process of developing and maintaining software. A core aspect of software engineering is the
subdivision of the development process into a series of phases, or steps, each of which
focuses on one aspect of the development. The collection of these steps is sometimes referred
to as a development life cycle. The software product moves through this life cycle
(sometimes repeatedly as it is refined or redeveloped) until it is finally retired from use.
Ideally, each phase in the life cycle can be checked for correctness before moving on to the
next phase. However, software engineering is a very rich discipline with many different
methods for the subdivision of the development process and a detailed exploration of the
many different ways in which development can be structured is beyond the scope of this
course.

Here, we start with an overview of the waterfall model such as you will find in most
software engineering text books. (Do note that in this course we aim to present database
development principles and techniques that are common to many development methods, not
just the waterfall model.) Figure 4 illustrates a general waterfall model which could apply to
any computer system development. It shows the process as a strict sequence of steps where
the output of one step is the input to the next and all of one step has to be completed before
moving onto the next. However, in reality there is usually some degree of refinement and
feedback as the product proceeds through the development stages (it would be rare to find

2
that each task is performed perfectly and never needs revisiting – although that is one
possibility!).

Figure 4 A general model of system development: the waterfall model

We can use Figure 4 as a means of identifying the tasks that are required, together with the
input and output for each activity. What is important is the scope of the activities, which can
be summarised as follows:

 Establishing requirements involves consultation with, and agreement among,

stakeholders as to what they want of a system, expressed as a statement of
requirements.
 Analysis starts by considering the statement of requirements and finishes by
producing a system specification. The specification is a formal representation of what
a system should do, expressed in terms that are independent of how it may be realised.
 Design begins with a system specification and produces design documents, and
provides a detailed description of how a system should be constructed.
 Implementation is the construction of a computer system according to a given design
document and taking account of the environment in which the system will be
operating (for example specific hardware or software available for the development).
Implementation may be staged, usually with an initial system than can be validated
and tested before a final system is released for use.
 Testing compares the implemented system against the design documents and
requirements specification and produces an acceptance report or, more usually, a list
of errors and bugs that require a review of the analysis, design and implementation

3
 processes to correct (testing is usually the task that leads to the waterfall model
iterating through the life cycle).
 Maintenance involves dealing with changes in the requirements, or the
implementation environment, bug fixing or porting of the system to new
environments (for example migrating a system from a standalone PC to a UNIX
workstation or a networked environment). Since maintenance involves the analysis of
the changes required, design of a solution, implementation and testing of that solution
over the lifetime of a maintained software system, the waterfall life cycle will be
repeatedly revisited.

Exercise 3

The following are problems that have been identified during the testing process in the
development of a new system. In which part of the life cycle do you think these problem
could have originated and been identified by a thorough review following that stage in the
development life cycle?

1. The performance of the system is poor – failing to respond quickly enough to meet
the stated user requirement of interactive, screen-based use.
2. No backup facilities were included to meet the users' requirement of long-term
archival of their data.
3. No user manuals were provided!

Answer

1. The user requirement for interactive, screen-based use forms part of the system
specification, but actual performance can only be identified at implementation time,
when the system has been built and is being evaluated. In the development of some
systems, attempts at performance prediction can occur during the design stage;
however, with database development it is normal to validate such design predictions
at the testing stage.
2. The missing feature was in the requirements, so during analysis, design or
implementation someone has overlooked this requirement. Without further
information it is impossible to say when the feature fell out of the development life
cycle.
3. No user manuals – were they asked for as part of the requirements? If they were then
see the answer to (2). If they weren’t part of the requirements, then such a basic
omission should have been identified at the requirements gathering – user
documentation should be considered as a standard requirement for any new system.