This excerpt, taken from Rebecca M. Riordan's book "Designing effective database systems," describes the processes involved in the analysis and design of database systems, starting with project life cycles. You can download the entire chapter here.
Life cycle models
Once upon a time, systems analysts used a paradigm for the development
process known as the waterfall model. There are several versions of this
model.
The process begins with systems analysis, sometimes called requirements
analysis, since it focuses on what the organization and the users
require the system to do. Once the systems analysis has been completed
and approved, the entire system is designed in detail. This phase is followed
by planning and budgeting, and then the entire system is built, tested, and
released. At least it is in theory.
The waterfall model is aesthetically pleasing. Each activity is completed
and approved before the next one is begun, and the model allows a fine
degree of control over budgets, staffing, and time. Deliver a waterfall
project on time and on budget, and your clients will probably love you.
The problem, of course, is that reality is hardly ever this neat. The
model assumes that all the information required to complete a task is avail-able
during the performance of that task, and makes no allowance for new
information coming to light later in the process. With the possible exception
of very small systems (the sort of thing you can design and build for yourself
over the course of a long weekend), this situation is unlikely in the extreme.
The waterfall model also doesn't allow for changes in business
requirements during the course of the project. To assume that a system
that met the business needs at the beginning of a project will still meet
them at the end of a two- or three-year development process is foolhardy.
Your clients will not love you for delivering a useless system, even if it is
on time and on budget.
Understand, however, that the activities identified in the waterfall
model are perfectly sound. In fact, omitting any of them from a development
project is a recipe for disaster. The problem with the model is its linearity,
its assumption that each phase need never be re-examined once it
has been completed.
Several alternative life cycle models have been proposed to deal with
the problems in the waterfall model. The spiral model assumes multiple
iterations of the waterfall, each one expanding the scope of the previous
iteration.
The problem with the spiral model is that, when strictly applied, the
entire scope of the project is not considered until very late in the development
project, and there is a (not insignificant) chance that later iterations
will invalidate earlier work. This has always seemed to me a recipe for blown
budgets and frustrated developers. The situation is particularly dangerous
for database projects, where expansions in scope can change the semantics of
the data, which requires a change to the database schema, and a change in
the database schema can require unexpected -- and unpredictable -- changes
throughout the system.
The model that I prefer for large systems, and use in my own work, is
variously described as incremental development or evolutionary development.
In this model, which is in many ways simply a variation on the spiral
model, the preliminary analysis is performed for the entire system, not just
a portion of it. This is followed by an architectural design, again of the
whole system. The goal of the architectural design is to define individual
components that can be implemented more or less independently, and to
describe the interactions and interdependencies between these components.
The detailed design and implementation of each component is then
performed using whichever model seems most appropriate. I use the spiral
model for this phase because it allows greater flexibility
in design and implementation.
Read the rest of the chapter here.
