The “Lifecycle” of Software.
Alternatives to the Waterfall
The “Waterfall” model can mislead:
boundaries between phases are not always
distinct, nor are the “activies” in the phases
The Waterfall model is not the only model
The spiral model
The “Sprial” model suggests that activities
might be repeated: that is, during the
software lifecycle there are several
“waterfall” model cycles.
The software is finished only when a
predefined level or risk has been satisfied!
Exploratory programming is for the
development of programs in environments
where the requirements are volatile or there
are no expert “customers”
As the requirements are explored using
code, when a satisfactory product is
achieved, the project is complete.
Opportunistic development is driven more
by a business model, in which allocated
resources drive the rate of development and
Many times, resources are put on the most
difficult problems first, leading to the
The Phases of Development
The phases of development are not exclusive. For
instance, design can legitimately happen during
the requirements phase.
Ideally, though, the activities reserved to other
phases are kept to a minimum
The general phases are: requirements,
specification, design, coding, and testing.
(Maintenance is not included in this discussion,
but be aware that it exists!)
During the requirements phase, activities
revolve around the definition of the
These activities usually include interviews
users, recording requirements
information, exploration of any existing
workflows or systems, use
identification, and so on.
The specification phase involves translating the
information from the requirements phase into a
more structured form.
In addition, analysis usually takes place, which
systematically explores the requirements for
conflicts, or identifies missing or incorrect
The output of this phase is information suitable for
partitioning into a design (and testing!)
During design, a software architecture is
developed, and the specified requirements are
partitioned into the design.
The architecture can be developed formally (as in
the case of SA/SD), or can be laid down based on
experience acquired from developing similar
The output from this phase is module
specifications suitable for development of code.
The coding phase translates the design (and
as a result, the specification), into
The output from the coding phase is code
suitable for testing. Typically, this means
that it compiles, links, and satisfactorily
passes a subset of sets, sometimes called a
Testing compares the developed code to the
requirements and specifications, using a set
of specifically designed tests.
The problems found during testing (defects,
or “bugs”), are turned back over to the
development team for correction, then the
test activity begins again with the next
One of the best ways to catch software
defects is to find them before they are “built
into” the system.
Software inspection provides a method for
Simply put, software inspection uses “many
eyes” to check work as it is released for
It has been demonstrated many times that
software inspection traps defects early in
Inspection can be used on every software
artifact: requirements, specifications,
design, code, and even tests.
The participants and the
Author: Producer of software artifact (code,
specification, design, test, whatever).
Inspectors: Critical reviewers of artifact.
Recorder: Records comments from
Moderator: Keeps the discussion “on
The participants and the
Inspectors take turn critiquing a page, module,
function, or whatever has been agreed upon as a
“unit”. Recorder records inspectors comments.
Author may ask for elaboration or points,
moderator make sure discussion doesn’t
Next instructor critiques the same page, and so on
until all instructors have critiqued the “unit”.
The cycle begins again with the next page (or
Inspection is expensive
Inspection is “expensive” in resources.
Time is required to prepare the materials,
study the materials, and attend the review.
Other activities must halt while the
inspection activities occur.
What can an individual do?
In the event that an entire “formal” inspection is
prohibitive (four people minimum), alternative
Work with another engineer to perform a scaled
down version of the inspection.
This can work if both engineers are experienced in
inspection, and have a good handle on their ego,
as well as a sensitivity to the other person’s
Maintenance Throughout the
“Maintenance” is “corrective” action: in
essence, updating documents (and code) to
The “defects” may be a changed
requirement, design element, or test.
These changes can have an impact on may
software artifacts, so they need to be
updated, or “maintained.”
Debugging can reveal problems that are
really ‘bugs’ in the specification: it behaves
exactly as specified, but it is wrong!
Inspections can also be considered
“debugging”, and can also uncover design
flaws, specification flaws, and so on.
Configuration management is not just version
Configuration management outlines how a change
moves through a review process, how changes to
documents are made, and how changed documents
This make sure every group has a chance to assess
the impact of a change before it is made!
Managing a Development
Fundamental questions pop up during
software development: Are we on track?
Do we have enough people? What are the
current issues and problems?
A few simple tools can help with some of
these basic questions, and any software
engineer can put these together at any time.
Progress reports can be prepared by the
individual or team to outline basic ‘status’.
These reports contain basic information
essential to management: what was done
this week, what is planned for next, and
what obstacles have been encountered.
Dividing effort among the phases
Knowing how effort escalates during the
development process, and knowing how this effort
relates to the calendar is important for managers!
Remember, schedule is calendar
days, while effort
months (or weeks, or whatever.)
month might well fit into a week: four
engineers working for one
week (schedule) is a