An outcome of project analysis will be

selection of the most appropriate

methodologies & technologies.
Methodologies include techniques like OO
development, Matlab and Java,J2EE,JSP(Java
server pages)
Technologies might include an appropriate
application-building and automated testing
environment.
 A structured set of activities required to develop a
software system
Specification;
Design;
Validation;
Evolution.
A software process model is an abstract
representation of a process. It presents a description
of a process from some particular perspective.
 In order to achieve an outcome, the system will
have to execute one or more activities, that is its
process.
To create a final product there are number of
activities. These can be organized in different
ways and we call these process models.
A major part of planning will be choosing
development methods and slotting them into an
overall process model.
Planner needs not only to select methods, but
also to specify how each method is to be applied.
 Software process models are general
approaches for organizing a project into
activities.

Help the project manager and his or her team to

decide:
What work should be done;
In what sequence to perform the work.
The models should be seen as aids to thinking,
not rigid prescriptions of the way to do things.
Each project ends up with its own unique plan.
 The waterfall model
Separate and distinct phases of specification and
development.
Evolutionary development
Specification, development and validation are
interleaved.
Component-based software engineering
The system is assembled from existing components.
There are many variants of these models e.g. formal
development where a waterfall-like process is used
but the specification is a formal specification that is
refined through several stages to an implementable
design.
 Also known as one-shot or once-through.

There are sequence of activities working from

top to bottom.

The classic way of looking at Software engg.

that accounts for the importance of
requirements, design and quality assurance.
 The model suggests that software engineers should
work in a series of stages.

Before completing each stage, they should perform

quality assurance (verification and validation).

The waterfall model also recognizes, to a limited

extent, that you sometimes have to step back to
earlier stages.
 Requirements analysis and definition
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance
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.
 Inflexible partitioning of the project into distinct
stages makes it difficult to respond to changing
customer requirements.
Therefore, this model is only appropriate when the
requirements are well-understood and changes will
be fairly limited during the design process.
Few business systems have stable requirements.
The waterfall model is mostly used for large systems
engineering projects where a system is developed at
several sites.
 It is the extension of waterfall model

The V-Model demonstrates the relationships

between each phase of the development life
cycle and its associated phase of testing.

The V-model deploys a well-structured

method in which each phase connected by
the detailed documentation of the previous
phase.
 verification and validation performed simultaneously.

save the time duration.

cost will be lesser.

Disadvantage
Any risk/contigencies are not analyzed during the v- model
Itexplicitly embraces prototyping and an
iterative approach to software development.
Start by developing a small prototype.
Followed by a mini-waterfall process, primarily to
gather requirements.
Then, the first prototype is reviewed.
In subsequent loops, the project team performs
further requirements, design, implementation and
review.
The first thing to do before embarking on each new
loop is risk analysis.
Maintenance is simply a type of on-going
development.
 It promotes reuse of existing software in
early stages of development.
Allows quality objectives to be formulated
during development.
Provides preparation for eventual evolution of
the software product.
Eliminates errors and unattractive
alternatives early.
 Demands considerable risk-assessment
expertise
It has not been employed as much proven
models (e.g. the WF model) and hence may
prove difficult to sell to the client (esp.
where a contract is involved)
that this model is controllable and efficient.
[More study needs to be done in this regard]
Itshows software development as a series of
hills, each representing a separate loop of the
spiral.
Shows that loops, or releases, tend to overlap each
other.
Makes it clear that development work tends to
reach a peak, at around the time of the deadline for
completion.
Shows that each prototype or release can take
different amounts of time to deliver;
differing amounts of effort.
 Exploratory development
Objective is to work with customers and to evolve a
final system from an initial outline specification.
Should start with well-understood requirements
and add new features as proposed by the customer.
Throw-away prototyping
Objective is to understand the system
requirements. Should start with poorly understood
requirements to clarify what is really needed.
 Problems
Lack of process visibility like testing;
Systems are often poorly structured;
Special skills (e.g. in languages for rapid
prototyping) may be required.
Applicability
For small or medium-size interactive systems;
For parts of large systems (e.g. the user interface);
For short-lifetime systems.
 Based on systematic reuse where systems are
integrated from existing components or
COTS (Commercial-off-the-shelf) systems.
Process stages
Component analysis;
Requirements modification;
System design with reuse;
Development and integration.
This approach is becoming increasingly used
as component standards have emerged.
 Rather than deliver the system as a single delivery,
the development and delivery is broken down into
increments with each increment delivering part of
the required functionality.

User requirements are prioritised and the highest

priority requirements are included in early
increments.
 Customer value can be delivered with each
increment so system functionality is available
earlier.
Early increments act as a prototype to help
elicit requirements for later increments.
Lower risk of overall project failure.
The highest priority system services tend to
receive the most testing.