SOFTWARE PROCESS MODELS

The software engineering approach requires that the process of developing a software
product be planned and structured. However, this does not mean that all projects will be
executed in exactly the same manner. On the contrary, there are several SDLC process
models which are available to the software engineer.

The process models we will cover are:

● The Waterfall Approach
● The Fountain Approach
● Evolutionary Development
● Formal Transformation
● Re-use Oriented Approach

Other approaches (we will not explicitly cover these)

● Rational Unified Approach ● Incremental Development
● Agile software Development ● Boehm's Spiral Model

A Software Process is as a set of activities, methods, and practices that people use to
develop and maintain software; and a software process model (or life cycle model) is a
simplified but abstract representation of a software process. A model describes, in
varying details, the organisation of the elements of a process, and provides a definition of
the process which can be used for evaluation and improvement. A software process
model therefore describes one possible approach to the development of a software
product and is a form of standardization.

The Process Models

 Computer Science Unit 2 Module 2

5. The Waterfall Approach

Often considered the classic approach to the systems/software development life cycle, the
waterfall model describes a development method that is linear and sequential. It takes
the SDLC activities of specification, design, development, validation and evolution, and
represents them as separate and distinct process phases.

Waterfall stages :

-Requirements
specification (analysis
and definition)

- System and software

design

- Implementation and
unit testing

- Integration and system

testing

- Operation and
maintenance

Fig. 46 – The Waterfall Model

Imagine a waterfall going down the side of a steep mountain. Once the water has flowed
over the edge of the cliff and has begun its journey down the side of the mountain, it
cannot turn back. It is the same with waterfall development.

In the Waterfall Model then, there are distinct activities and goals for each phase of
development. The following phase cannot begin until the previous phase has finished.
Each phase is expected to produce a specific outcome and subsequent work is based on
the outcome of the previous phase. Once a phase of development is completed it is
'signed off' on, and the development proceeds to the next phase. No turning back is
allowed.
The waterfall model is the best-known and oldest process model and is known as a plan
driven process.

[2]
 C-A Jardette

Pros
- allows for departmentalization and managerial control. A schedule can be set with
deadlines for each stage of development and a product can proceed through the
development process in an orderly manner; the staged development cycle enforces
discipline
- The emphasis on requirements and design before writing any line of code ensures
minimal wastage of time and effort and reduces the risk of schedule slippage, or of
customer expectations not being met.
- Getting the requirements and design out of the way first also improves quality; it's much
easier to catch and correct possible flaws at the design stage than at the testing stage, after
all the components have been integrated and tracking down specific errors is more
complex.
- because the first two phases end in the production of a formal specification, the waterfall
model can aid efficient knowledge transfer when team members are dispersed in different
locations
- Theoretically, the product can be delivered on time.

Cons
- The waterfall model does not allow for much reflection or revision. Once an application
is in the testing stage, it is very difficult to go back and change something that was not
well-thought out in the concept stage. It is almost impossible to accommodate changes
after the process is underway.
- Another criticism revolves around the model's implicit assumption that designs can be
feasibly translated into real products; this sometimes runs into roadblocks when
developers actually begin implementation. Often, designs that look feasible on paper turn
out to be expensive or difficult in practice, requiring a re-design and hence destroying the
clear distinctions between phases of the traditional waterfall model
- Some criticisms also centre on the fact that the waterfall model implies a clear division of
labour between, say, "designers", "programmers" and "testers"; in reality, such a division
of labour in most software firms is neither realistic nor efficient.

Implications
- It is very important to gather all possible requirements during the first phase of
requirements collection and analysis. If not all requirements are obtained at once the
subsequent phases will suffer from it. Usually though, only a part of the requirements is
known at the beginning as customers are unable to fully articulate what they want from a
system.
- Iterations are only meant to happen within a particular phase. If the process is kept
according to the book this tends to shift the solution of problems into later phases which
eventually results in a bad system design. Instead of solving the root causes the tendency
is to patch problems with inadequate measures.

[3]
 Computer Science Unit 2 Module 2

- There may be a very big "Maintenance" phase at the end. The waterfall process model
only allows for a single run through the activities. All defects detected during
development then have to be fixed in the maintenance/evolution phase.

Notwithstanding the fact that it is considered old-fashioned and simplistic, the waterfall
model is a popular version of the systems development life cycle for software
engineering.
Note though that the waterfall approach should only be used when the requirements are
well understood and are unlikely to change radically during the development process.

6. Evolutionary Development
The approach in this
model, sees the activities
of specification,
development and
validation being
interleaved with each
other. An initial system is
rapidly developed from
very abstract specifications
(a prototype). This is then
refined with customer
input to produce a system
which satisfies the
customer's needs. The
system may then be delivered. Fig. 47 – Evolutionary Development
Alternatively, it may be re-implemented
using a more structured approach
to produce a more robust and maintainable system.

Generally, the early versions of the system include the most important or most urgent
functionality. Each increment of the system then incorporates some more of the
functionality needed by the users. Evolutionary development is also called incremental
development and is now one of the most common process models in use.

Evolutionary development including rapid prototyping

Rapid Prototyping is a technique for providing a reduced functionality or a limited

[4]
 C-A Jardette

performance version of a software system early in its development in order to test out key
features of the product. Evolutionary development therefore by definition involves the
production, and use, of prototypes. The use of quickly developed prototypes means that
early end-user participation in the software process is accommodated/encouraged. A
prototype can be discarded (throw away prototyping) after the requirements are deemed
to be fully understood and a more structured product built, or it itself can form the basis
for the final product.

Comparison of Evolutionary Development with the Waterfall Model

- Evolutionary development is seen as better than waterfall for most business, e-
commerce and personal systems because it reflects the way we solve problems. We rarely
work out a complete problem solution in advance but instead we move towards solutions
in a series of steps, backtracking when we make a mistake.

- By making software incrementally, the cost of accommodating further customer

requirements is reduced, making it cheaper to make the system overall
- Getting customer feedback is built into the system and they can actually use and
comment on an actual product.
- There is more rapid delivery and deployment

Disadvantages
- The process is not visible. Documentation of the project's rapid changes is difficult and
so progress is also sometimes difficult to measure.
- system structure degrades as new increments are added. As time goes on incorporating
further software changes become increasingly difficult and costly (poor maintainability).
These problems are especially acute for large, complex, long-life systems where different
teams develop different parts of the system.

There is typically a four-step process for prototyping:

1. Identify initial requirements: In this step, the software publisher decides what the
software will be able to do. The publisher considers who the user will likely be
and what the user will want from the product, then the publisher sends the project
and specifications to a software designer or developer.
2. Develop initial prototype: In step two, the developer will consider the
requirements as proposed by the publisher and begin to put together a model of
what the finished product might look like. An initial prototype may be as simple
as a drawing on a whiteboard, or it may consist of sticky notes on a wall, or it may
be a more elaborate working model.

[5]
 Computer Science Unit 2 Module 2

3. Review: Once the prototype is developed, the publisher has a chance to see what
the product might look like; how the developer has envisioned the publisher's
specifications. In more advanced prototypes, the end consumer may have an
opportunity to try out the product and offer suggestions for improvement. This is
what we know of as beta testing.
4. Revise: The final step in the process is to make revisions to the prototype based on
the feedback of the publisher and/or beta testers.

Steps 3 and 4 are repeated until the parties are satisfied with the product.

7. The Fountain Approach

The fountain model recognizes that
although some activities can't start
before others -- such as you need a
design before you can start coding –
that there is still a considerable
overlap of activities throughout the
development cycle. The Fountain
model has all the steps of the waterfall
approach, however at any step it
allows a fallback to an earlier step.
Moving through a number of steps
and falling back one or more steps,
performed repeatedly, is far more
flexible than the Waterfall model
making the Fountain model a logical
improvement on that model. The
Fountain model is regarded as a
highly iterative approach. (Named
after the water fountain concept where
the water rises to the top and then falls
only to be used again)

Fig. 48 – The Fountain Model

Notice the overlap in the early stages

The basic steps include:

[6]
 C-A Jardette

- User requirements analysis

- Requirements specifications
- Design
- Coding
- Testing and Integration
- Operation
- Maintenance and Evolution

The advantages of this model are :

- Not having to freeze the requirements too soon, so requirements which are
discovered later can still be incorporated
- Many more interactions between design and requirements
- Able to start the coding earlier as all requirements do not have to be specified
first

Disadvantage of the fountain model

- difficult to commit to set times for delivering modules of the system

Analysis:
Its strengths are that it supports iteration within phases, allows parallelism
between phases (overlapped activities), and it is an incremental development.
And its weakness is that it may degrade into code-a-bit test-a-bit which requires
frequent iterations and refinements. However, for OOP programming, the
overlapping between activities reduces maintenance effort.
Though it would be a bit inappropriate for small projects, it has the flexibility to
fall back on any phase if some problems arise in between any of the previous
phases. It also works well where the requirements keep on changing frequently.
Even if there is an error in the understanding of the client requirements, those can
be easily rectified without much loss of project time for not very huge systems.

[7]
 Computer Science Unit 2 Module 2

8. Formal Transformation

Fig. 49- Formal Transformation

For more than 30 years, theoretical computer scientists have been advocating this
approach, which is steeped in mathematics, to software development. Using this model,
the developer converts the requirements from the customer into a formal mathematical
system specification, then use automated tools to generate the executable program from
the formal specifications through a series of transformations. These transformations are
'correctness preserving', meaning that you can be sure that the developed program meets
its specification. The implication of this is that no unit testing is necessary.
Formal methods use predictive logic and set theory and proponents of this model claim
that their use lead to more reliable and safer systems.

The stages of formal transformation are

- requirements definition
- formal specification
- formal transformation (one or more iterations)
- integration and system testing

Concerns
- There is a need for specialized skills and training to apply the techniques
- It is difficult to formulate some aspects of a system in terms of mathematical functions
(such as
the user interface)
- Writing formal methods is time consuming and costly
- End-users can not comment on the designs as they cannot interpret formal specifications

Applicability
- Used in the production of critical systems especially those where safety or security is
paramount.

[8]
 C-A Jardette

Fig. 50 - Part of the Formal Specifications for an address book system

Note that the formal methods model is not really a complete model but is a different
approach to the design and implementation phases of the SDLC.

9. Reuse Model
This technique assumes that parts of the system as we want it to be, already exist. The
premise behind the Reuse Model therefore, is that systems should be built using existing
components, as opposed to custom-building new components. The system development
process focuses on integrating these parts rather than developing them from scratch. This
technique is also called component based software engineering.

Within the Reuse Model, libraries of software modules are maintained that can be copied
for use in any system. These components are of two types: procedural modules and
database modules. When building a new system, the developer will borrow a copy of a
module from the system library and then plug it into a function or procedure. If the
needed module is not available, the developer will build it, and store a copy in the system
library for future usage. If the modules are well engineered, the developer, with minimal
changes, can implement them.

[9]
 Computer Science Unit 2 Module 2

The Reuse Model is clearly suited to Object-Oriented computing environments, which

have become one of the premiere technologies in today's system development industry.

Fig. 51 – Reuse Model Steps

Some of the steps in the Reuse Model are :

• Definition of Requirements. Initial system requirements are collected.

• Identification, collection and analysis of components. The objects, which can
support the necessary system components, are identified and evaluated.
• Requirements Refinement. Requirements are further refined as a more detailed
version of the system is being assembled.

Problems/Challenges Associated with the Reuse Model

- A general criticism of the Reuse Model is that it is limited to use in object-oriented
development environments. Although this environment is rapidly growing in popularity,
it is currently used in only a minority of system development application
- Tends to lead to a compromise in requirements

Advantages of the Reuse Model

- Saves time / product is delivered faster
- Saves money

Software houses can operate with this model in mind and when they are creating new
modules in a project they can design them such that they can be stored as functional
modules which they could reuse in future not yet identified projects.

[10]
 C-A Jardette

In Conclusion :

The waterfall model

• Separate and distinct phases of specification and development.

• The main drawback of the waterfall model is the difficulty of

accommodating change after the process is underway. One phase has to be
complete before moving onto the next phase

Evolutionary development

• Specification, development and validation are interleaved.

Fountain Model

• Allowing return to, and reworking of, previous phases as development

progresses

Formal Development

• a waterfall-like process is used but the specification is a formal

specification that is refined through several stages to an implementable
design which uses mathematical algorithms to prove correctness

Component-based software engineering

• The system is assembled from existing components.

[11]
 Computer Science Unit 2 Module 2

Alternatives to the models we have examined include joint application development

(JAD), rapid application development (RAD), synch and stabilize, build and fix, and
the spiral model.

[12]