The “Lifecycle” of Software.

offbeatnothingSoftware and s/w Development

Dec 2, 2013 (3 years and 10 months ago)

65 views

The “Lifecycle” of Software.

Chapter 5

Alternatives to the Waterfall
Model


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
activities.


Many times, resources are put on the most
difficult problems first, leading to the
nickname “hardest
-
part
-
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!)

Requirements


During the requirements phase, activities
revolve around the definition of the
problem.


These activities usually include interviews
with end
-
users, recording requirements
information, exploration of any existing
workflows or systems, use
-
case
identification, and so on.

Specification


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
requirements.


The output of this phase is information suitable for
partitioning into a design (and testing!)

Design


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
systems.


The output from this phase is module
specifications suitable for development of code.

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


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
release.

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
production.

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
procedure


Author: Producer of software artifact (code,
specification, design, test, whatever).


Inspectors: Critical reviewers of artifact.


Recorder: Records comments from
inspectors.


Moderator: Keeps the discussion “on
topic”.

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
“escalate”.


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
“unit.”)

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
feelings!

Maintenance Throughout the
Lifecycle


“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


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
control!


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
Lifecycle


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
man
-
month (effort).