Software Development Process Models

Steven J Zeil

Last modified: Oct 19, 2015

Abstract

Each development organization has its own working process that it
evolves for how it gets software development done. In this lesson, we
look at the constituent steps that make up typical instances of these
processes, and will survey some of the more common arrangments of
those steps into a software development process model:

• the Waterfall Model
• Iterative and Incremental Models
• The Spiral Model
• The Rational Unified Process
• Agile models

1. Software Development Process Models

Abstract

Each development organization has its own working process that it
evolves for how it gets software development done.

Although that might sound chaotic, in practice there is pretty broad
consensus on what the constituent steps are that make up the entire
process. So it becomes a matter of arranging those steps, of tweaking the
details, and especially of settling on the relative emphasis and level
of detail in these steps.

The arrangements that companies arrive at are seldom entirely
innovative. Instead, they fall into a few standard patterns, which we
will survey in this lesson.

A software development process model (SDMP), a.k.a., a
software life-cycle model, is the process by which an
organization develops software.

• Projects typically broken into phases
• There are varying criteria for entering or exiting each phase

1.1 Common Activities

Although there are many models (in theory, one per development team),
there is pretty broad agreement on what needs to go on during this
process:

1. Recognition of problem / need / opportunity
2. Feasibility study
3. Analysis of requirements
4. Design of system
5. Implementation
6. Testing
7. Deployment
8. Maintenance

Different SDPMs will divide these activities among phases in different ways.

Let’s talk about a few of these in more detail.

Analysis of Requirements

• Examine existing system.

  • How does it work?
  • What are its shortcomings?
• Propose a new system
  • Enumerate precisely what the new system will do

“System” here is used in its generic sense: a collection of people,
organizations, machines, and procedures for getting things
done. There’s almost always an existing system, even if it is totally
un-automated.

If you are a follower of Object-Oriented (OO) approaches, you have a
deep conviction that studying and, ultimately, simulating an existing
system is a fundamental principle of software development. OO
developers never ask the question “Is it possible to build a system
that does X?”. That’s because the existing system serves as an
existence proof — they’re already doing X, so we start by
understanding and then simulating what they are doing now.

Common Documents from Requirements Analysis

• Feasibility report
• Software Requirements Specification (SRS)
  • Detailed statement of problem
  • Functional requirements
  • Constraints on the system

We’ll look at requirements in more detail in a later section.

Design

“Design” means deriving

a solution which satisfies the software requirements.

Commonly recognized subproblems include

• architectural design

  ,

  • the collection of decisions that need to be common to all components.

    Examples of architectural design decisions would be

    • Will the system run on a single machine or be
      distributed over multiple CPUs?
    • Will outputs be stored in a file or in a
      database?
    • How will run-{}time errors be handled?

• high-level

  design,

  • dividing the system into components, and

• low-level

  design

  • choosing the data structures and algorithms for a single component.

A possible breakdown of design activities

You are probably pretty familiar already with procedures for doing high-level
and low-level design. Architectural design, on the other hand, is
something that is seldom worth worrying about in the scale of
projects addressed within an academic semester.

The breakdown shown in this picture is probably more elaborate than
you would have attempted, though the component ideas should,
considered separately, be clear enough.

The diagram here suggests a fairly document-heavy process typical of
Waterfall, our first process model.

Maintenance

Maintenance is another practice that seldom arises in academic
projects. Normally, when you do an assignment for a course, you’re
completely done with at the end of the semester. Keeping it working,
adding new functionality, etc., is not a concern.

But you’ve certainly seen how operating systems, application programs,
games, and many other software products are subject to an ongoing
process of bug fixes, enhancements, and new releases.

Maintenence can have a number of forms:

• Corrective

  • fixing problems
• Adaptive
  • changes in environment
• Perfective
  • adding features
  • improving performance
• Preventative
  • refactoring to improve maintainability

    • Refactoring

      is a change made that preserves
      the current behavior of the system.

2. The Waterfall Model

• The best known process model
  • dates from 1970’s
  • though widely derided, it remains widely used
    • and its terminology forms the basis for almost all discussions of other SDPMs

• Defining characteristic: movement from phase to phase is always
  forward (downhill), irreversible

• Milestones are set at each phase transition
  • schedule deadlines
  • required reports
  • required approval to move on

The waterfall model gets its name from the fact that the first
diagrams of this process illustrated it as a series of terraces over
which a stream flowed, cascading down from one level to another. The
point of this portrayal was that water always flows downhill — it
can’t reverse itself. Similarly, the defining characteristic of the
waterfall model is the irreversible forward progress from phase to
phase.

Waterfall is often criticized as inflexible, in large part because of
that irreversible forward motion. Many organizations, in practice,
will do a kind of “waterfall with appeals”, allowing developers to
revisit and revise decisions and documents from earlier phases after
jumping through a number of deliberately restrictive hoops.

2.1 Verification & Validation

Most of the activities in Waterfall are familiar, with the possible
exception of requirements analysis, which we will be looking at in
more detail in a later lesson.

For now, I want to look at Verification and Validation (V&V).

Verification & Validation: assuring that a software system
meets the users’ needs.

The principle objectives are:

• The discovery of defects in a system
• The assessment of whether or not the system is usable in an
  operational situation.

What’s the Difference?

• Verification:

  • “Are we building the product right” (Boehm)
  • The software should conform to its (most recent) specification
• Validation:
  • “Are we building the right product”
  • The software should do what the user really requires

Verification is essentially looking for mistakes in our most recent
bit of work by comparing what we have now to the most recent
“official” document defining our system.

Validation is a return to first principles, comparing what we have now
to what we (or our customers) originally wanted.

You might think that, in a process divided into steps, if we do each
step “correctly”, then the entire sequence must be “correct”. In
practice, though, the accumulation of small errors can lead to massive
alterations over time. (That’s
not just a matter for programmers.)

Most V&V activities mix verification and validation together to
different degrees.

Testing

• Testing

  is the act of executing a program with selected data to
  uncover bugs.

  • As opposed to

    debugging

    , which is the process of finding
    the faulty code responsible for failed tests.

• Testing is the most common, but not the only form of V&V

Industry figures of 1–3 faults per 100 statements are quite common.

Is testing verification or validation? A great deal depends on how we
decide whether the test output is correct. If we do this by viewing
the data ourselves and looking for things that jump out to our eyes as
“wrong”, then we are doing mainly validation. On the other hand, if
part of our design process was to set up a set of tests with files of
their expected outputs, and we are simply comparing the actual output
files to the expected output files, then we are doing more
verification.

2.2 Testing throughout the Waterfall

Testing stages

• Unit Test: Tests of individual subroutines and modules,

  • usually conducted by the programmer.

• Integration Test

  : Tests of “subtrees” of the total project
  hierarchy chart (groups of subroutines calling each other).

  • generally a team responsibility.

• System Test

  : Test of the entire system,

  • supervised by team leaders or by V&V specialists.
  • Many companies have independent teams for this purpose.

• Regression Test: Unit/Integration/System tests that are repeated after a change has been made to the code.

• Acceptance Test: A test conducted by the customers or their representatives to decide whether to purchase/accept a developed system.

Not just in one phase

Although the waterfall model shows V&V as a
separate phase near the end, we know that some forms of V&V occur
much earlier.

• Requirements are validated in consultation with the customers.
• Unit testing occurs during Implementation, etc.

So this phase of the waterfall model really describes system and
acceptance testing.

A Still-broader View

Even the “V&V V” does not capture the full context of V&V:

• Requirements must be validated
• Designs may be validated & verified
• Maintenence changes are tested

2.3 Advantages of Waterfall

• Linear structure is easy to understand
• Development progress is easily estimated and explicitly documented
• Widely known
• Scales well

2.4 Disadvantages of Waterfall

• Inflexible: corrections limited to current phase
• In some projects, requirements are not known or understood early in
  the life-cycle
• Working version of system is only available near the end
• Often becomes a documentation mill

3. Iterative/Incremental Development

• A variety of related approaches
  • a counter-reaction to what many believe to be an overly rigid,
    management-focused, waterfall model
• emphasize quick cycles of development,
  usually with earlier and more user-oriented validation
• Requirements specification, design and implementation are interleaved.
• Each version adds a small amount of additional functionality.

As a counter-reaction to what many believe to be an overly rigid
waterfall model, there are a variety of incremental approaches that
emphasize quick cycles of development, usually with earlier and more
user-oriented validation.

There is a greater emphasis on producing intermediate versions, each
adding a small amount of additional functionality. Some of these are
releases, either external (released outside the
team) or internal (seen only by the team), which may have been planned
earlier.

What’s the difference between iterative and incremental?

• “Iterative” means that we can re-visit decisions, design, and code
  produced in earlier iterative steps.

• “Incremental” means that each iteration produces just a small unit
  of additional functional behavior. We don’t try to build major subsystems of
  the project in a single pass.

  • This often requires a more “vertical” view in which we implement
    a bit of high level control code and pieces of related low-level
    code.

  • As opposed to the “horizontal” approach of working “bottom up”
    and implementing the low-level ADTS, then the code that calls,
    upon them, then …, ending
    with the top-level interface ot the whole program.

  • Or the “horizontal” approach of working “top down”
    and implementing the most abstract code (the GUI or command-line
    interfaces), then functions that they call, then the … ending
    with the lowest-level ADTS that don’t call on anything else.

Iterative versus Incremental Models

• Iterative – we do some set of process steps repeatedly.

  To use a programming analogy, this is iterative:

  while (!done) {
     ⋮
  }
  

• Incremental – we accumulate value in small steps.

  To use a programming analogy, this is incremental:

  total += x;
  

Incremental development is almost always iterative, but you can be
iterative without being incremental.

Variations

• Some projects employ

  throw-away prototyping

  ,
  versions whose code is only used to demonstrate
  and evaluate possibilities.

  • This can lead to insight into poorly understood requirements.

• Evolutionary prototyping keeps the prototypes,
  gradually evolving them into the final deliverable

• Some waterfall projects may employ incremental schemes for parts of
  large systems (e.g., the user interface).

3.1 Advantages

• Ability to explore poorly understood requirements
• Flexibility
• Working implementation is available early.

3.2 Disadvantages

• Poor process visibility (e.g.,
  are we on schedule?),

• Continual small drifts from the main architecture
  leading to poorly structured systems.

• Dead-ends (the local optimization problem)

4. The Spiral Model

1986, Boehm

An iterative approach with a focus on risk management

• Each iteration builds on the earlier ones

• risk: an uncertain outcome with a potential for loss

  Examples:

  • team inexperience
  • inability to meet schedule
  • uncertainty in requirements

Spiral Phases

1. Determine objectives, alternatives and constraints:
   • Define requirements
   • Alternatives (including, e.g., 3rd-party code) identified
   • Constraints defined
2. Identify and resolve risks, evaluate alternatives:
   • Evaluate identified alternatives
   • Identify risks
   • Resolve risks
   • Produce prototype
3. Develop and test
   • Analyze performance of prototype
   • Create & review design, code, test
4. Plan next iteration
   • Often includes customer evaluation of
     prototype or current project iteration

4.1 Advantages of Spiral Model

• Flexible – emphasis on alleviating risks as they are identified
• Considerable opportunity for validation
• Scales well
• Good process visibility
• Working releases/prototypes produced early

4.2 Disadvantages of Spiral Model

• Can be costly (slow?)
• Risk analysis is a specialized skill, but critical to project success

5. Rational Unified Process

• 1997, Jacobsen, Booch, and Rumbaugh,

These three were already some of the biggest names in OOA&D before
they decided to collaborate on a unified version of their previously
distinctive approaches.

Their collaboration coincided with their being hired by Rational
Corp., a major vendor of software development tools. Hence the
“Rational” in RUP refers to the name of the company. It’s not
bragging. They aren’t saying that this is a uniquely intellectual
approach or that Waterfall, Spiral, et. al., are “irrational”.

5.1 Unified Model Phases

• Inception: initial concept

  • Pitching the project concept
  • Usually informal, low details.
  • “Perhaps we should build a … ”
• Elaboration: exploring requirements
  • Adding detail to our understanding of what the system should do.
  • Produces
    • Domain model
    • Analysis model
    • Requirements document
    • Release plan

5.2 Unified Model Phases Continued

• Construction: building the software
  • Design & implementation
• Transition: final packaging
  • Activities that can’t be done incrementally during construction,
    e.g.,
    • performance tuning
    • user training

Releases

One task during Elaboration is to plan releases:

• Major phases are divided into increments, each of which
  ends with a release.

• A

  release

  is some
  kind of product that implements some part of the required
  functionality

  • Its existence and/or acceptance by management shows
    that we are ready to move on.
• The

  release plan

  records decisions
  about

  • How many releases there will be
  • What functionality will be added with each
    release
  • When the releases will be made
  • Which releases are internal (i.e., only the development
    team sees them) and which are external

The term “increments” gets used a lot in different models. Sometimes
it refers, as it does here, to the time period during which the next
release of the software is developed. In other cases it refers to the
next version of the software. In other cases it refers to the software
release itself.

5.3 Key Concepts of the RUP

Common Workflows

• Although waterfall and other SDPMs treat analysis, design, etc., as
  one-time phases

• Careful study shows that developers do analysis, design, etc.,

  activities

  continuously.

  • Analysis: what do we need the (currently considered part of the)
    system to do?

  • Design: how do we get it to do that?

  • Implementation: write out that series of design decisions in
    an appropriate notation (e.g., code, diagrams, requirements
    statements)

  • Validation: Is our implementation correct?

For example, deep in the implementation phase of a Waterfall project,
a programmer is assigned a function to implement.

That programmer will

• think carefully about what the function is supposed to do
  (analysis)
• choose an algorithm that will accomplish that (design)
• code the function (implementation)
• unit-test that function (validation).

But we aren’t in the analysis, design, or validation phases.

The diagram on the right is supposed to illustrate that, although the
percentage of time devoted to the activities of analysis, design,
implementation, and validation, none of those activites ever entirely
go away and are, once and for all, done.

A process model may still use some of these same terms as the name for
major phases, but that’s really a different sense of the terms. For
example, the “Design” phase of the Waterfall is when the language in
which we “implement” is the collection of notations and diagrams that we
use for system design. But we still analyze, design, implement, and
validate our Design decisions.

ADIV

In the RUP, all progress is made as continual ADIV cycles

• ADIV: Analysis, Design, Implementation, Validation

An Evolution of Models

RUP supports development via a series of models.

The most important of these are

• Domain Model

  • A model of the application domain as it currently exists,

    before

    we began our new development project.

  • Ensures that the development team understands the world that the
    system will work in.
• Analysis Model
  • A model of how the world will interact with the software system
    that we envision.
  • Expresses

    what

    the system will do
    when it is working.

• Design Model
  • Describes

    how

    we can get the system to do the things the
    analysis model says it should do.

Models Evolved

RUP embraces the

Object-Oriented philosophy

• Every program is a simulation
• The quality of a program’s design is proportional to how
  faithfully the objects and interactions in the program reflect
  those in the real world

• Domain, analysis, and design models all focus on how classes of
  objects interact with one another

• Most of the classes in the design are presumed to have already been
  described as part of the analysis model,

• Most of the classes in the analysis model are presumed to have already been
  described as part of the domain model,

5.4 Advantages of RUP

• Process details are expressed in general terms, allowing local
  customization
• Heavy emphasis on documentation (UML)
• Can embrace incremental releases
• Evolutionary approach can lead to clean implementations

5.5 Disadvantages of RUP

• Process details are expressed in general terms, providing minimal
  guidance and requiring local customization
• Complex
• Heavy documentation can be expensive

6. Agile Methods

A modern variant of incremental development.

Agile development is

• A reaction against heavily-managed, documentation-heavy processes
• A social movement within the software development profession
  • Introduced in the Agile Manifesto
    (2001)

Emphasis Areas

Emphasis is on

• Iterative & incremental development
• Frequent communication with customer representatives
  • Work is organized via “user stories”
• Short “time-boxed” development cycles
• Focus on quality as a matter of professional pride
• Adoption of professional best-practices

We’ll look at Agile in more detail later in the semester, after we
have learned more about these “best practices” that lie at the heart
of the process.