Software Process Model

Deepikaa S.
 Process
• collection of work activities, actions, and tasks that
are performed when some work product is to be
created
• Process framework activities—communication,
planning, modeling, construction, and deployment.
• umbrella activities—project tracking and control,
risk management, quality assurance, configuration
management, technical reviews, and others—are
applied throughout the process.
 Process flow

• Process flow—describes how the framework activities,

actions and tasks that occur within each framework
activity are organized with respect to sequence and time
• Linear process flow
• Iterative process flow
• Evolutionary process flow
• Parallel process flow executes one or more activities in
parallel with other activities
 Linear process flow
• Linear process flow executes each of the five
framework activities in sequence
 Iterative process flow
• Iterative process flow repeats one or more of
the activities before proceeding to the next.
 Evolutionary process flow
• Evolutionary process flow executes the
activities in a “circular” manner.
 Parallel process flow
• Parallel process flow executes one or more
activities in parallel with other activities
 Defining framework
• Each framework activity is populated by a set
of software engineering actions.
• Each software engineering action is defined by
a task set.
• Framework Selection –
 nature of the problem
 characteristics of people working on it
 stackeholders
 Identifying the Task Set
• A task set defines the actual work to be
done to accomplish the objectives of a
software engineering action.
– A list of the task to be accomplished
– A list of the work products to be produced
– A list of the quality assurance filters to be
applied
 Process Patterns
• A process pattern
– describes a process-related problem that is
encountered during software engineering work,
– identifies the environment in which the problem has
been encountered, and
– suggests one or more proven solutions to the problem.
• Stated in more general terms, a process pattern
provides you with a template [Amb98]—a
consistent method for describing problem
solutions within the context of the software
process.
 Process Pattern Types
• Stage patterns—defines a problem associated with a
framework activity for the process. (multiple task
pattern- ex: communication for requirements gathering)
• Task patterns—defines a problem associated with a
software engineering action or work task and relevant
to successful software engineering practice. Ex:
requirements gathering
• Phase patterns—define the sequence of framework
activities that occur with the process, even when the
overall flow of activities is iterative in nature. Ex: spiral
model or prototyping.
 Process Assessment and Improvement
• Standard CMMI Assessment Method for Process Improvement (SCAMPI)
— provides a five step process assessment model that incorporates five
phases: initiating, diagnosing, establishing, acting and learning.
• CMM-Based Appraisal for Internal Process Improvement (CBA IPI)—
provides a diagnostic technique for assessing the relative maturity of a
software organization; uses the SEI CMM as the basis for the assessment
[Dun01]
• SPICE—The SPICE (ISO/IEC15504) standard defines a set of requirements
for software process assessment. The intent of the standard is to assist
organizations in developing an objective evaluation of the efficacy of any
defined software process. [ISO08]
• ISO 9001:2000 for Software—a generic standard that applies to any
organization that wants to improve the overall quality of the products,
systems, or services that it provides. Therefore, the standard is directly
applicable to software organizations and companies. [Ant06]
 Prescriptive Models
• Prescriptive process models advocate an orderly
approach to software engineering
That leads to a few questions …
• If prescriptive process models strive for structure and
order, are they inappropriate for a software world that
thrives on change?
• Yet, if we reject traditional process models (and the
order they imply) and replace them with something
less structured, do we make it impossible to achieve
coordination and coherence in software work?
 The Waterfall Model-classic life cycle

• when the requirements for a problem are well

understood
• When work flows from communication
through deployment in a reasonably linear
fashion.
Contd.
• Most widely used, though no longer state-of-the-art
• Each step results in documentation
• May be suitable for well-understood developments using
familiar technology
• Not suited to new, different systems because of
specification uncertainty
• Difficulty in accommodating change after the process has
started
• Can accommodate iteration but indirectly
• Working version not available till late in process
• Often get blocking states
16
 Advantages
• This model is simple and easy to understand and
use.
• It is easy to manage due to the rigidity of the
model – each phase has specific deliverables and
a review process.
• In this model phases are processed and
completed one at a time. Phases do not overlap.
• Waterfall model works well for smaller projects
where requirements are very well understood.
17
 Disadvantages
• 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.
• No working software is produced until late during the life
cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented
projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a
moderate to high risk of changing.

18
V- Model
 Problems of the Linear Model

 Real project rarely follow the sequential

flow that the model proposes.
 It is often difficult for the customer to state
all requirements.
 The customer must have patience.
 Advantages
• Simple and easy to use.
• Testing activities like planning, test designing happens
well before coding. This saves a lot of time. Hence
higher chance of success over the waterfall model.
• Proactive defect tracking – that is defects are found at
early stage.
• Avoids the downward flow of the defects.
• Works well for small projects where requirements are
easily understood.

21
 Disadvantages
• Very rigid and least flexible.
• Software is developed during the
implementation phase, so no early prototypes
of the software are produced.
• If any changes happen in midway, then the
test documents along with requirement
documents has to be updated.

22
 When to use
• The V-shaped model should be used for small
to medium sized projects where requirements
are clearly defined and fixed.
• The V-Shaped model should be chosen when
ample technical resources are available with
needed technical expertise.

23
RAD Model

24
• RAD model is Rapid Application Development
model. It is a type of incremental model.
• In RAD model the components or functions are
developed in parallel as if they were mini projects.
• The developments are time boxed, delivered and
then assembled into a working prototype. 
• This can quickly give the customer something to
see and use and to provide feedback regarding
the delivery and their requirements.
25
 Advantages
• Reduced development time.
• Increases reusability of components
• Quick initial reviews occur
• Encourages customer feedback
• Integration from very beginning solves a lot of 
integration issues.

26
 Disadvantages
• Depends on strong team and individual
performances for identifying business
requirements.
• Only system that can be modularized can be built
using RAD
• Requires highly skilled developers/designers.
• High dependency on modeling skills
• Inapplicable to cheaper projects as cost of modeling
and automated codegeneration is very high.

27
 When to use
• RAD should be used when there is a need to create a
system that can be modularized in 2-3 months of time.
• It should be used if there’s high availability of
designers for modeling and the budget is high enough
to afford their cost along with the cost of automated
code generating tools.
• RAD SDLC model should be chosen only if resources
with high business knowledge are available and there
is a need to produce the system in a short span of
time (2-3 months).
28
The Incremental
Model
incre m e nt # n
Co m m u n i c a t i o n
Pla n nin g

Mo d e lin g
a n a ly s is C o n s t ru c t i o n
d e s ig n
c ode De p l o y m e n t
t es t d e l i v e ry
fe e d b a c k

d e liv e ry o f
incre m e nt # 2 n t h in cre me n t

Co m m u n i c a t i o n
Pla n nin g

Mo d e lin g
a n a ly s is C o n s t ru c t i o n
d e s ig n c ode De p l o y m e n t
t es t d e l i v e ry
fe e d b a c k
d e liv e ry o f
incre m e nt # 1 2 n d in cre me n t

Co m m u n i c a t i o n
Pla n ning
Mo de lin g
a n a ly s is C o n s t ru c t i o n
d e s ig n c od e
d e liv e ry o f
De p l o y m e n t
t es t d e l i v e ry
fe e db a c k

1 st in cre me n t

project calendar t ime

29
• Applies an iterative philosophy to the
waterfall model
• Divide functionality of system into
increments and use a linear sequence of
development on each increment
• First increment delivered is usually the
core product, i.e only basic functionality
• Reviews of each increment impact on
design of later increments
30
 Advantages
• Generates working software quickly and early during
the software life cycle.
• This model is more flexible – less costly to change
scope and requirements.
• It is easier to test and debug during a smaller iteration.
• In this model customer can respond to each built.
• Lowers initial delivery cost.
• Easier to manage risk because risky pieces are
identified and handled during it’d iteration.

31
 Disadvantages
• Needs good planning and design.
• Needs a clear and complete definition of the
whole system before it can be broken down
and built incrementally.
• Total cost is higher than waterfall.

32
 When to use

• This model can be used when the requirements of

the complete system are clearly defined and
understood.
• Major requirements must be defined; however,
some details can evolve with time.
• There is a need to get a product to the market early.
• A new technology is being used
• Resources with needed skill set are not available
• There are some high risk features and goals.

33
Evolutionary Models:
Prototyping
Quick
Q u ic k p l a n

Co m m u n ic a t io n plan
communication

Modeling
Mo d e l in g
Qu ic k d e s ig n
Quick design

De p lo ym e n t
Deployment Construction
De liv e ry
delivery of Co
prototype
& Fe e d b & ac k n s t ru c t io n
feedback Construction
of
of
p roprototype
t o t yp e

34
• Ideally mock-up serves as mechanism for identifying
requirements
• Users like the method, get a feeling for the actual
system
• Less ideally may be the basis for completed product
– prototypes often ignore
quality/performance/maintenance issues
– may create pressure from users on deliver earlier
– may use a less-than-ideal platform to deliver e.g Visual
Basic - excellent for prototyping, may not be as effective
in actual operation

35
• Not a silver bullet, but considered to be one of
the best approaches
• Is a realistic approach to the problems of large
scale software development
• Can use prototyping during any phase in the
evolution of product
• Requires excellent management and risk
assessment skills

36
 Advantages
• Users are actively involved in the development
• Since in this methodology a working model of the system
is provided, the users get a better understanding of the
system being developed.
• Errors can be detected much earlier.
• Quicker user feedback is available leading to better
solutions.
• Missing functionality can be identified easily
• Confusing or difficult functions can be identified
Requirements validation, Quick implementation of,
incomplete, but functional, application.

37
 Disadvantages

• Leads to implementing and then repairing way of

building systems.
• Practically, this methodology may increase the
complexity of the system as scope of the system
may expand beyond original plans.
• Incomplete application may cause application not
to be used as the
full system was designed
Incomplete or inadequate problem analysis.

38
 When to use
• Prototype model should be used when the desired system
needs to have a lot of interaction with the end users.
• Typically, online systems, web interfaces have a very high
amount of interaction with end users, are best suited for
Prototype model. It might take a while for a system to be
built that allows ease of use and needs minimal training
for the end user.
• Prototyping ensures that the end users constantly work
with the system and provide a feedback which is
incorporated in the prototype to result in a useable
system. They are excellent for designing good human
computer interface systems.

39
Evolutionary Models: The
planning
Spiral estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery
code
feedback test

40
• Development cycles through multiple (3-6) task regions (6
stage version)
– customer communication
– planning
– risk analysis
– engineering
– construction and release
– customer evaluation
• Incremental releases
– early releases may be paper or prototypes
– later releases become more complicated
• Models software until it is no longer used

41
 Advantages
• High amount of risk analysis hence, avoidance
of Risk is enhanced.
• Good for large and mission-critical projects.
• Strong approval and documentation control.
• Additional Functionality can be added at a
later date.
• Software is produced early in the 
software life cycle.
42
 Disadvantages
• Can be a costly model to use.
• Risk analysis requires highly specific expertise.
• Project’s success is highly dependent on the
risk analysis phase.
• Doesn’t work well for smaller projects.

43
 When to use
• When costs and risk evaluation is important
• For medium to high-risk projects
• Long-term project commitment unwise because
of potential changes to economic priorities
• Users are unsure of their needs
• Requirements are complex
• Significant changes are expected (research and
exploration)
These slides are designed to accompany
Software Engineering: A Practitioner’s
44
Approach, 7/e (McGraw-Hill, 2009). Slides
 Component-based development

• Component-based software engineering (CBSE) is an

approach to software development that relies on reuse
• Components provide a service without regard to where
the component is executing or its programming
language
– A component is an independent executable entity that can be
made up of one or more executable objects
– The component interface is published and all interactions are
through the published interface
• Components can range in size from simple functions to
entire application systems
 Component interfaces

Requires interface Component Provides interface

 Component interfaces
• Provides interface
– Defines the services that are provided by the
component to other components
• Requires interface
– Defines the services that specifies what services
must be made available for the component to
execute as specified
 Printing services component

Requires interface PrintService Provides interface

Print
GetPDfile
GetQueue
PrinterInt Remove
Transfer
Register
Unregister
 CBSE processes
• Component-based development can be integrated
into a standard software process by incorporating a
reuse activity in the process
• However, in reuse-driven development, the system
requirements are modified to reflect the
components that are available
• CBSE usually involves a prototyping or an
incremental development process with components
being ‘glued together’ using a scripting language
 Software reuse
• In most engineering disciplines, systems are
designed by composing existing components
that have been used in other systems
• Software engineering has been more focused
on original development but it is now
recognised that to achieve better software,
more quickly and at lower cost, we need to
adopt a design process that is based on
systematic reuse
 Benefits of reuse
• Increased reliability
– Components exercised in working systems
• Reduced process risk
– Less uncertainty in development costs
• Effective use of specialists
– Reuse components instead of people
• Standards compliance
– Embed standards in reusable components
• Accelerated development
– Avoid original development and hence speed-up production
 Reuse problems
• Increased maintenance costs
• Lack of tool support
• Not-invented-here syndrome
• Maintaining a component library
• Finding and adapting reusable components
Fourth Generation Techniques 4GL

53
 Fourth Generation Techniques 4GL
• Encompasses a broad array of software tools
which automatically generate source code
based on the developer’s specification.
• A viable approach for many different
application areas.
• The time requires to produce software is
greatly reduced.
• They have already become an important
part of software engineering, especially
when coupled with component-based
development approaches.