Software Engineering

Software Process and Models

Software Process
Process Series of predictable steps - a road map
that helps create a timely and high quality
entity

Software Process is a framework for the

Software Process tasks that are required to 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)
 Work Product: Programs, documents and data that are
produced as a consequence of activities
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 product and
provide feedback
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

Communication
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

• 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

Chapter 2 Software Processes

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 that changes

can be accommodated at relatively low cost.

Chapter 2 Software Processes

 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
• Usedas 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-appropriate tools or algorithms may become a part of the system
▪ In-focused customer may cause the system to either never
completed or to take too much time
•e.g.
• Govt. sector
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.
• Unlikeany 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
• Unlikeother 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
• Bothmodels, 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
• Rapid Application 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.
• To use 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
Team # 1
Communication
Project Initiation
Requirement Modeling
Gathering Analysis
Design

Construction
Code
Test
Team # 2

Modeling
Analysis
Planning Design
Estimating
Scheduling Deployment
Tracking Construction
Delivery
Code
Support
Test
Team # n Feedback

Modeling
Analysis
Design

Construction
Code
Test

60 – 90 days
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, actions, or tasks. 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 (UML)
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 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.

68
 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.
• Facilitate university teaching of industrial-grade team skills.
69
Summary

70
Any Questions???

71
Read Chapter 2 from Book

72