The “Lifecycle” of Software.

offbeatnothingSoftware and s/w Development

Dec 2, 2013 (4 years and 7 months ago)


The “Lifecycle” of Software.

Chapter 5

Alternatives to the Waterfall

The “Waterfall” model can mislead:
boundaries between phases are not always
distinct, nor are the “activies” in the phases
strictly exclusive.

The Waterfall model is not the only model
there is!

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

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

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
nickname “hardest
first” development.

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
with end
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
executable code.

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
“smoke test.”


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

Software inspection

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
doing this.

Simply put, software inspection uses “many
eyes” to check work as it is released for

Inspection works

It has been demonstrated many times that
software inspection traps defects early in
the process.

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
procedure (cont’d)

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
forms exist.

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
fix defects.

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

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
are distributed!

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

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
is man
months (or weeks, or whatever.)

A man
month might well fit into a week: four
engineers working for one
week (schedule) is a
month (effort).