Software
Engineering
Software Process and Models
Mian Ahmed Shafiq
Software Process
Process Series of predictable steps - a
road map that helps create a
timely and high quality entity
Software Process is a framework
Software for the tasks that are required to
Process build high quality software to
create timely and high quality
result
Software Process
■Software process is a collection of
activities, actions and tasks that are
performed when some work is to be
created
■ An activity strives to achieve broad
objective(e.g., communication with
stakeholders)
■ An action encompasses a set of tasks that
produce a major work product (e.g.,
construction )
■ A task focuses on a small, well defined
objective (e.g., testing)
Software Process
Each software engineering
process is populated by software
action/activities
Each software engineering action
is defined by a task set.
Task set identifies the work tasks
that are to be completed, the
work products that will be
produced, the quality assurance
points that will be required and
the milestones that will be used
4
Software Process
■Generic process framework for
software engineering encompasses
five activities
■Communication
■ with customer, identify project objectives,
gather requirements to define software
features and functions
■Planning
■ Software project plan
■ Define technical tasks, risks, resources
required, work product, and the work
Software Process
■Generic process framework for
software engineering encompasses
five activities
■Modeling
■ Create sketch, what it looks like
architecturally
■Construction
■ Code generation and testing
■Deployment
■ Deliver to customer to evaluate delivered
Software Process
■For small project
■Communication activity encompasses
■ Make contact with stakeholder via
telephone
■ Discuss requirements and take notes
■ Organize notes into written statement of
requirements
■ Email stakeholder for review and approval
Software Process
■Umbrella activities
■Software project tracking and control
■Risk management
■Software quality assurance
■Technical reviews
■Configuration management
■Reusability management
Software Process
• Software project tracking and control
●allows the software team to assess progress
against the project plan and take any necessary
action to maintain the schedule.
• Risk management
●assesses risks that may affect the outcome of the
project or the quality of the product.
Software Process
• Software quality assurance
●defines and conducts the activities required to
ensure software quality.
• Technical reviews
●assesses software engineering work products in an
effort to uncover and remove errors before they are
propagated to the next activity.
Software Process
• Software configuration management
●manages the effects of change throughout
the software process.
• Reusability management
●defines criteria for work product reuse and
establishes mechanisms to achieve
reusable components.
Process Flow
■Describes how framework activities and the actions
and tasks that occur within each framework
activities are organized with respect to sequence
and time
Communicatio
n Construction
Planning
Deployment
Modeling
Process Flow
A linear process flow executes each
of the five framework activities in
sequence, beginning with
communication and culminating
with deployment
Process Flow
An iterative process flow repeats
one or more of the activities before
proceeding to the next
Process Flow
An evolutionary
process flow
executes the
activities in a
“circular” manner.
Each circuit
through the five
activities leads to a
more complete
version
of the software
Process Flow
A parallel process flow
executes one or more
activities in parallel
with other activities
(e.g., modeling for
one aspect of the
software might be
executed in parallel
with construction of
another aspect of the
software).
Software Process
Models
17
18
Waterfall Model
Waterfall Model
Also known as the classic life cycle or Linear
Sequential model.
It suggests a systematic, sequential approach to
software development that begins at the
system level and progress through analysis,
design, coding, testing and support.
Waterfall Model
• Used when
●The requirements of a problem are reasonably well
understood
●When work flows from communication through deployment
in a reasonably linear fashion.
V-model
V-model
■ A variation in the representation of the waterfall model
is called V-model
■ In reality there is no fundamental difference between
classical lifecycle and the V-model
■ V model provides a way of visualizing how verification
and validation actions are applied to earlier engineering
work
■ It is also known as Verification and
Validation model. V- Model is an extension of the
waterfall model and is based on association of a testing
phase for each corresponding development stage.
■ V-model depicts the relationship of quality assurance
actions to the actions associated with all the phases.
Disadvantages
• Real projects rarely follow the sequential flow that
the model proposes.
• It is often difficult for the customer to state all
requirements explicitly.
• A working version of the program will not be
available until late in the project time span.
• Linear nature leads to “blocking states”.
Coping with change
• Change is inevitable in all large software projects.
●Business changes lead to new and changed system
requirements
●New technologies open up new possibilities for improving
implementations
●Changing platforms require application changes
Chapter 2 Software Processes
• Change leads to rework so the costs of change
include both rework (e.g. re-analysing requirements)
as well as the costs of implementing new
functionality
25
Reducing the costs of rework
• Change avoidance, where the software process
includes activities that can anticipate possible
changes before significant rework is required.
●For example, a prototype system may be developed to show
some key features of the system to customers.
• Change tolerance, where the process is designed so
Chapter 2 Software Processes
that changes can be accommodated at relatively low
cost.
●This normally involves some form of incremental
development. Proposed changes may be implemented in
increments that have not yet been developed. If this is
impossible, then only a single increment (a small part of the
system) may have be altered to incorporate the change.
26
The Incremental
Model
27
The incremental model
• There are situations in which initial software
requirements are reasonably well defined
• Additionally, there may be compelling need to
provide a limited set of software functionality
to users quickly and then refine and expand on that
functionality in later software releases
• In such case you choose a process model that is
designed to produce that software in increments
Incremental model
1st increment is often a core product, basic requirements are
addressed
Planning for the next increment
Repeat until complete product is produced
The incremental model
• The problem is broken into increments, and each
increment is tackled as a linear sequence
• Further increments can either be done after the
previous ones, or can overlap with the previous ones
• Incremental delivery focuses on the delivery of an
operational product with each increment
• Early increments are stripped-down versions of the
final product
The incremental model
• For example, word-processing software developed
using increments paradigm might deliver basic file
management, editing, and document
production functions in the first increment
• Second increment: more sophisticated editing
and document production capabilities
• Third: spelling and grammer checking
• Fourth: Advanced page layout
Incremental model advantages
●Early delivery is guaranteed
●Progress of the whole project is not delayed if one of the
resources is not available for part of it
●Particularly useful when staffing is unavailable for a
complete implementation
●Early increments can be implemented with fewer people
●If the core product is well received, then additional staff
(if required) can be added to implement the next
increment.
●In addition, increments can be planned to manage
technical risks.
Evolutionary
Process Models
33
Evolutionary Process Models
●Business and product requirements change (creeping
requirements)
●Above issues cannot be handled by linear sequential model
●Evolutionary process models produce an increasingly more
complete version of the software with each iteration.
●a set of core product or system requirements is well
understood, but the details of product or system extensions
have yet to be defined. (Product evolves over time)
●Evolutionary models are iterative. They are characterized in
a manner that enables you to develop increasingly more
complete versions of the software.
●Two Models
●Prototyping Model
●Spiral Model
35
Prototyping
• Often, a customer defines a set of general objectives for
software, but does not identify detailed requirements for
function and features
• A quick design focuses on what the customer will see. From
this, a prototype is constructed
• The user evaluates it and improvements are made
• This continues in an iterative fashion until a satisfactory
product is achieved
• Ideally, prototype serves as a mechanism for identifying
software requirements
• No cost constraints
Prototyping
Quicker
design focuses
on a
representation
of aspects
visible to end
users.
e.g. human
interface layout
or output
display formats
Benefits
• Misunderstandings between developers and
users identified
• Incomplete requirements found
• A working system is available quickly to
demonstrate feasibility
• Used as a basis for writing the specification
for production of quality software
Problems
▪ Customer excepts a working model in a short
time putting pressure on the team.
▪ Developer may compromise speed for efficiency
(complex efficiency)
▪ In-focused customer may cause the system to
either never completed or to take too much
time
The Spiral model
• Boehm’s (1988) spiral model couples the iterative
nature of prototyping with the controlled and
systematic aspects of the linear sequential model.
• Software is developed in a series of incremental
releases.
• During the early releases, there may be just a
paper model, but the system becomes increasingly
more complete.
• Unlike any of the other models, this model keeps
revisiting the system throughout its lifetime.
Spiral model
SPIRAL MODEL
(CONT…)
• It is used when SW development is risky
• RISK → having chances of loss, the probability of uncertainty is
high (threat)
Uncertainty
• Risk
• It is very costly Loss Scope
Quality
(Triple
Cost constraints) Time
42
The Spiral model
• The first circuit around the spiral might result in
development of a product specification
• Subsequent passes around the spiral might be used
to develop a prototype
• When high risk involve we use this model
• The following might progressively more
sophisticated version of the software
• Unlike other process models tha tend when
software is delivered, spiral can adapt to apply
throughout the life of s/w
SPIRAL ONT…
(C )
Planning based Risk analysis based
or customer or customer
comments comments
Risk Analysis on Initial
Initial Requirements Requirements
Initial prototype
Next Level prototype
Go or no-go
decisions
Engineered System
44
45
46
47
Differences between Spiral and
Incremental Model
• Both models, incremental and spiral offer partial
deliveries to the customer at different phases
BUT ….
• The Incremental Model focuses on the delivery
of a fully-tested production code in a step-by-
step fashion; each step adds more functionality
• The Spiral Model focuses on the development
of prototypes at each stage which will be used
only for information gathering and then throw-
away
The RAD model
Rapid Application Development
• RapidApplication Development is an adaptation of
linear sequential software development process
model that emphasises an extremely short
development cycle.
•A component-based construction approach is used.
• Touse this approach, the project scope must be
constrained and the requirements should be well
understood.
•A task that should take no more than ninety days to
complete is modelled, generated and implemented.
• There
can be several teams working on different
components during this ninety day time-box
RAD model
Advantages of RAD
• Less time
• Reusability
Problems with RAD
• For large, scalable projects, RAD requires sufficient
human resources to create the right number of RAD
teams
• RAD requires developers and customers who are
committed to the rapid-fire activities necessary to
complete a system in this time frame, or failure will
result.
• RAD is not suitable for many project types.
Concurrent Model
54
Concurrent Model
• Figure above provides a schematic representation of one Software engineering
task within the modeling activity for the concurrent process model. The
activity – modeling- may be in any one of the states noted at any given time.
• All activities exist concurrently but reside in different states.
• For example, early in the project the communication activity has completed its
first iteration and exists in the awaiting changes state. The modeling
activity which existed in the none state while initial communication was
completed now makes a transition into underdevelopment state.
• If, however, the customer indicates the changes in requirements must be
made, the modeling activity
• moves from the under development state into the awaiting changes
state.
• The concurrent process model defines a series of events that will trigger
transitions from state to state for each of the Software engineering activities, 55
Specialized Process
Models
56
Specialized Process Models
• Component based development—the process to
apply when reuse is a development objective
• Formal methods—emphasizes the mathematical
specification of requirements
• Aspect-Oriented Software Development (AOSD)—
provides a process and methodological approach for
defining, specifying, designing, and constructing
aspects
• Unified Process—a “use-case driven, architecture-
centric, iterative and incremental” software process
closely aligned with the Unified Modeling Language 57
Unified Process
58
The Rational Unified Process
• A modern generic process derived from the work on
the UML and associated process.
• Brings together aspects of the 3 generic process
models discussed previously.
• Normally described from 3 perspectives
●A dynamic perspective that shows phases over time;
●A static perspective that shows process activities;
●A proactive perspective that suggests good practice.
59
Phases in the Rational Unified
Process
60
RUP phases
• Inception
●Establish the business case for the system.
• Elaboration
●Develop an understanding of the problem domain and
the system architecture.
• Construction
●System design, programming and testing.
• Transition
●Deploy the system in its operating environment.
61
RUP iteration
• In-phase iteration
●Each phase is iterative with results developed
incrementally.
• Cross-phase iteration
●As shown by the loop in the RUP model, the whole
set of phases may be enacted incrementally.
62
Static workflows in the Rational
Unified Process
Workflow Description
Business modelling The business processes are modelled using business use
cases.
Requirements Actors who interact with the system are identified and use
cases are developed to model the system requirements.
Analysis and design A design model is created and documented using
architectural models, component models, object models
and sequence models.
Implementation The components in the system are implemented and
structured into implementation sub-systems. Automatic
code generation from design models helps accelerate this
process.
63
Static workflows in the Rational
Unified Process
Workflow Description
Testing Testing is an iterative process that is carried out in conjunction with
implementation. System testing follows the completion of the
implementation.
Deployment A product release is created, distributed to users and installed in their
workplace.
Configuration and This supporting workflow managed changes to the system (see in the
change management later Chapters).
Project management This supporting workflow manages the system development (see in the
later Chapters).
Environment This workflow is concerned with making appropriate software tools
available to the software development team.
64
RUP good practice
• Develop software iteratively
●Plan increments based on customer priorities and
deliver highest priority increments first.
• Manage requirements
●Explicitly document customer requirements and keep
track of changes to these requirements.
• Use component-based architectures
●Organize the system architecture as a set of reusable
components.
65
RUP good practice
• Visually model software
●Use graphical UML models to present static and
dynamic views of the software.
• Verify software quality
●Ensure that the software meet’s organizational
quality standards.
• Control changes to software
●Manage software changes using a change
management system and configuration
management tools.
66
Key points
• Processes should include activities to cope with
change. This may involve a prototyping phase that
helps avoid poor decisions on requirements and
design.
• Processes may be structured for iterative development
and delivery so that changes may be made without
disrupting the system as a whole.
• The Rational Unified Process is a modern generic
process model that is organized into phases (inception,
elaboration, construction and transition) but separates
activities (requirements, analysis and design, etc.) from
these phases.
67
Personal Software Process (PSP)
• Planning. This activity isolates requirements and develops both size and
resource estimates. In addition, a defect estimate (the number of defects
projected for the work) is made. All metrics are recorded on worksheets or
templates. Finally, development tasks are identified and a project schedule is
created.
• High-level design. External specifications for each component to be
constructed are developed and a component design is created. Prototypes are
built when uncertainty exists. All issues are recorded and tracked.
• High-level design review. Formal verification methods (Chapter 21) are applied
to uncover errors in the design. Metrics are maintained for all important tasks and
work results.
• Development. The component level design is refined and reviewed. Code is
generated, reviewed, compiled, and tested. Metrics are maintained for all
important tasks and work results.
• Postmortem. Using the measures and metrics collected (this is a substantial
68
amount of data that should be analyzed statistically), the effectiveness of the
process is determined. Measures and metrics should provide guidance for
modifying the process to improve its effectiveness.
Team Software Process (TSP)
• Build self-directed teams that plan and track their work,
establish goals, and own their processes and plans. These can
be pure software teams or integrated product teams (IPT) of
three to about 20 engineers.
• Show managers how to coach and motivate their teams and
how to help them sustain peak performance.
• Accelerate software process improvement by making CMM
Level 5 behavior normal and expected.
● The Capability Maturity Model (CMM), a measure of the effectiveness of
a software process, is discussed in Chapter 30.
• Provide improvement guidance to high-maturity organizations.
69
• Facilitate university teaching of industrial-grade team skills.
Summary
70
Any Questions???
71
Read Chapter 2 from Book
72
