Process Models

-MS. SWATI VARMA

 A generic process framework for SE

 Communication- communicate with customers & other stakeholders

 Planning – creates a map/ project plan
 Modeling
 Analysis of requirements
 Design
 Construction
 Code generation
 Testing
 Deployment
 Delivery
2
Framework activity:
e.g. Communication,

A
Implementation etc.

Each framework activity is

populated by a set of s/w generic
process
engg actions

model
Each s/w engg action is
defined by a task set
 4

Process Flow
Process Flow
Process Flow
Process patterns

 Teams often encounter common problems

 It is useful if proven solutions to these problems are available
 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.
 It provides a template- a method for describing problem solutions
 Template

 Pattern name: A meaningful name is assigned

 Forces: environment & the issues that make the problem visible
 Type: Stage Pattern (activity), Task Pattern(SE action), Phase
Pattern(Process)
 Initial context: describes the conditions under which pattern applies
 Problem: the specific problem to be solved
 Solution
 Resulting Context: describes the conditions that will result once the pattern
is successfully implemented
 Related patterns: list of all process patterns that are directly related to this.
 Known uses & example: specific instance in which pattern is available.
8
 Process Pattern Types

 Stage patterns—defines a problem associated with a framework

activity for the process.
 Task patterns—defines a problem associated with a software
engineering action or work task and relevant to successful software
engineering practice
 Phase patterns—define the sequence of framework activities that
occur with the process, even when the overall flow of activities is
iterative in nature.

9
 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
 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

 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.

11
SEI-CMM

 In recent years, there has been a significant emphasis on “process

maturity”
 Software Engineering Institute- Capability Maturity Model (SEI-CMM)
 SEI approach provides a measure of global effectiveness of a company’s
s/w engg practices & establishes 5 process maturity levels.
SEI-CMM

❑ Level 1: Initial
 S/w process is adhoc & occasionally even chaotic
 Few processes are defined
 Success depends on individual effort
❑ Level 2: Repeatable
 Basic project management processes are established to track cost,
schedule & functionality
 Necessary process discipline is in place to repeat successes on similar
applications, but they are not defined or documented
SEI-CMM

❑ Level 3: Defined
 The s/w process is documented, standardized & integrated into an
organization wide s/w processes.
 It includes all characteristics defined for level 2.
❑ Level 4: Managed
 Measures are collected
 The software process & products are understood & controlled using
detailed measures
 It includes all characteristics of level 3
SEI-CMM

❑ Level 5: Optimizing
 Continuous process improvement is enabled by quantitative feedback
 Innovative ideas & technologies are implemented
 It includes all characteristics of level 4
Software Process Models

 Means development strategy

 A process model for s/w engg is chosen based on
 The nature of the project & application
 Methods & tools to be used
 Controls & deliverables that are required
Prescriptive Process Models

 “how to do” models

 They are used as guidelines or frameworks to organize & structure how s/w
development activities should be performed and in what order.
 Defines a distinct set of activities, actions, tasks, milestones & work products
that are required to engineer high quality software
 Activities may be linear, incremental, or evolutionary
Waterfall model

 Also called as classic life cycle model

 It is a systematic sequential approach
 Used when requirements are well understood
 Used when we work on known projects or enhancements
Waterfall model

1. Communication
 Understand information domain, functionality, behavior, performance &
interface
 Requirements are documented & reviewed with the customer
2. Planning
 Estimating
 Scheduling
 Tracking
Waterfall model

3. Modeling
 It translates requirements into a representation of the software
 Design is documented & becomes part of the s/w configuration
 Focusses on data structures, s/w architecture, interface representation &
procedural detail
4. Construction
 Design is translated into a machine readable format
 After code generation testing begins
 Testing is done to uncover errors & to check the functionality
Waterfall model

5. Deployment
 s/w is deployed
 s/w will undergo change because
 Errors will be encountered
 Change required because of external environment e.g. change required
because of new OS or peripheral device or some government policy
 Because customer requires functional or performance enhancements
 s/w support reapplies each of the preceeding phases to an existing program.
The Waterfall Model

 Oldest model but understood by upper management

 Used when requirements are well understood, and risk is low
 Workflow is in a linear fashion
 Used often with well defined adaptations or enhancements

22
Waterfall Model

Disadvantages/ Problems
 Real projects rarely follow the sequential flow.
 Difficult for customers to state all requirements upfront
 Doesn’t support iterations, so changes can cause confusion
 Working version is available late in the project time span
 A major blunder if undetected can be disastrous
 Linear nature leads to “blocking states” where some team members must
wait for others to complete dependent task.
 The V-Model

24
The V-Model

 Variation of waterfall model

 Depicts relationship of quality assurance actions to the actions
associated with communication, modeling & construction (SDLC )
 Once the code is generated team moves up the right side of the
V, performing a series of tests.
 There is no fundamental difference between waterfall & V-model
 It provides a way of visualizing how verification and validation
actions are applied to earlier engineering work.
 Verification – review of requirements
 Validation – testing
 If a defect is detected early, cheaper it is to fix it.
Incremental Process Models

 The incremental model combines elements of linear and parallel process

flows
 i.e. combines elements of the waterfall model applied in an iterative
fashion
 Two Models
 Incremental Model
 Rapid Application Development (RAD) Model
 27

The
Incremental
Model
Incremental Model

 There may be a need to provide a limited set of software functionality to

users quickly and then refine and expand in later software releases
 Designed to produce the software in increments.
 Used when requirements are well understood
 Multiple independent deliveries are identified
 Iterative in nature
 Also useful when staffing is too short
Incremental Model

 The first increment is often a core product.

 That is, basic requirements are addressed but many supplementary
features (some known, others unknown) remain undelivered.
 The core product is used by the customer for evaluation.
 As a result of use and/or evaluation, a plan is developed for the next
increment.
Incremental Model

E.g.Word-processing software
 First increment- basic file management, editing, and document
production functions
 Second increment - more sophisticated editing and document production
capabilities
 Third increment - spelling and grammar checking
 Fourth increment - advanced page layout capability
RAD Model

 RAD is an incremental s/w development process model that emphasizes

on short development cycle.
 Used when we have sufficient teams(people) but not sufficient time or
when time is short
 If requirements are well understood & project scope is constrained, then
RAD team can develop within 60 to 90 days
RAD Model
RAD
Business modeling – information
flow among business function is
modeled
Specify what information is
required, what it generates,
where information goes etc.
Data Modeling- data objects,
their characteristics &
relationships
Process Modeling - Processes
acts on data objects (create,
delete)
RAD Model

Drawbacks
 Human Resource
 Commitment from human resource
 Not all applications are appropriate for RAD i.e. modularization is required
 New technology – RAD not useful
Evolutionary Models

 Evolutionary- means relating to a process of gradual change & development

 Software like all complex system evolves over a period of time,
 Business & product requirements often change as development proceeds,
making a straight-line path unrealistic
 Business pressure/competitors
 Evolutionary models are iterative in naure
 More complete versions of the software are delivered with every iteration
 Used when we know the core requirements but not extensions
Evolutionary Models

Process Models
1. Prototyping
2. Spiral
3. Concurrent
Prototyping Model

 It is often used with other process models

 It can also be used as stand alone process model
Prototyping Model

 Often customer & developer both are unsure of certain things like:
 Customer unsure of i/p or o/p requirements, processing, etc
 In some cases developer is unsure of certain algorithms, adaptability of an
OS or how human machine interaction should take place
 Quick
Qu ick p lan
plan
Com m unicat ion
communication

Prototyping MoModeling
d e lin g

Model Quick design

Qu ick d e sig n

Deployment
Deployment
De live r y&
delivery
feedback
& Fe e dback Const r uct ion
Construction
ofof prototype
pr ot ot ype
Disadvantages/Problems

 Prototype is held together with “chewing gum & bailing wires”

 So the software quality & long term maintainability is not considered
 The developer often makes implementation compromises
 An inappropriate programming language or OS is used because it is available &
known
 An inefficient algorithm may be implemented
Prototyping Model

Should we throw away the prototype?

Prototyping Model

 Customer & developer both agree that the prototype is built to serve as a
mechanism for defining requirements
 It is then discarded at least in part & actual s/w is engineered
Spiral Model

 Proposed by Barry Boehm

 It couples iterative nature of prototyping with controlled & systematic
aspects of waterfall model
 The system is developed in a series of evolutionary releases.
 During early iterations – the release might be a model or prototype.
 During later iterations- more complete versions of the software are
produced.
 Risk is considered at each revolution
 planning
estimation
scheduling
risk analysis

communication

modeling
analysis Spiral
Model
design
start

deployment
construction
delivery code
feedback test
Spiral Model

 Each pass through the planning phase might result in adjustments to the
project plan.
 Cost & schedule are adjusted based on feedback derived from the
customer after delivery
 Even the no. of iterations may be adjusted
 Spiral model doesn’t end when the s/w is delivered
 It is adapted throughout the life of the s/w
Spiral Model

 First circuit – concept development project

 Second circuit – new product development
 Third circuit- product enhancements
 Fourth circuit- product maintenance
Advantages

 Realistic approach
 Prototyping is used as a risk reduction mechanism
Disadvantages

 Difficult to convince customer that this approach is controllable

 It also demands considerable risk assessment expertise & relies on this
expertise for success
Concurrent Development Model

➢ Concurrent development model is applicable to all types of software

development processes.
➢ All software engineering activities exists concurrently but reside in different
states.
➢ Gives very clear picture of current state of the project.
➢ Easy to use and easy to understand
Disadvantage:
➢ It requires excellent and updated communication between team members.
This may not be achieved all the time.
 none

Modeling act ivit y

represent s t he st at e
Under of a sof t ware engineering
act ivit y or t ask
development

Concurrent
Model
A wait ing
changes

The activity Modeling may

be in one of the following Under review
states.
Under
revision

Baselined

Done
Concurrent Model

For example,
 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.
SPECIALIZED PROCESS MODELS

➢ Component-Based Development
➢ Aspect-Oriented Software Development
Component-Based Development

➢ Component-Based development—the process to apply when

reuse is a development objective
➢ Commercial off-the-shelf (COTS) Software components, can be
used when Software is to be built.
➢ The component-based development model incorporates many of
the characteristics of the spiral model.
➢ The component-based development model leads to Software
reuse, and reusability provides with a number of measurable
benefits.
Component-Based Development

The component-based development model incorporates the following steps:

➢ Available component-based products are researched and evaluated for
the application domain in question.
➢ Component integration issues are considered.
➢ Software architecture is designed to accommodate the components.
➢ Components are integrated into the architecture.
➢ Comprehensive testing is conducted to ensure proper functionality.
Aspect Oriented Software Development

 AOSD—provides a process and methodological approach for defining,

specifying, designing, and constructing aspects
Concern
Abstraction
AO Programming

Object
OO Programming Abstraction
Function
Abstraction

Procedural Programming
It isolates secondary or supporting functions from the main program’s business logic
Aspect Oriented Software Development

 Concern
➢ A specific requirement or consideration that must be
addressed in order to satisfy the overall system goal

➢ Two types of Concern

➢ Core Concern
➢ Cross cut Concern
Aspect Oriented Software Development

 Core concerns
 Central functionality of a Business logic
 Customer and Account management, Inter-banking transactions,
ATM transactions
 Crosscut concerns
 System-level, peripheral requirements (multiple modules)
 Persistence of all entities, Transaction integrity, Authorization of
access to various services, Logging, Security, Error checking, Policy
enforcement
Aspect Oriented Software Development

➢ The idea behind AOP is “Separation of concern”

➢ AOP builds upon Existing Methodologies (OOP, Procedural

programming), augmenting them with concepts and constructs in
order to modularize crosscutting concerns.

➢ Separation of concern is the key idea in AOP.

i.e. each concern is developed independent of other concerns.
Aspect Oriented Software Development

 Separation of concern provides reduction in problems like changing

the code, readability, traceability because every concern is
independent.
What is concern?
 Concerns may consists of algorithms, procedures, objects, and many
other tools.
Agile
Development
What is “Agility”?

➢ Effective (rapid and adaptive) response to change

➢ Effective communication among all stakeholders
➢ Drawing the customer onto the team
➢ Organizing a team so that it is in control of the work performed
Yielding …
Rapid, incremental delivery of software
Agility and the Cost of Change
Agility Principles - I

1. Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness
change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months,
with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face–to–face conversation.
Agility Principles - II

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self–organizing
teams.
12. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.
 Human Factors

Key traits must exist among the people on an agile team and the team itself:
➢ Competence.
➢ Common focus.
➢ Collaboration.
➢ Decision-making ability.
➢ Fuzzy problem-solving ability.
➢ Mutual trust and respect.
➢ Self-organization.
Extreme
Programming

 It is the most widely

used approach for
agile s/w development
 Kent Beck –is an
American software
engineer and the
creator of extreme
programming
XP Values

Kent Beck has defined a set of 5 values

1. Communication
2. Simplicity
3. Feedback
4. Courage
5. Respect
XP Values

1. Communication
 For effective communication: XP emphasizes close, informal collaboration
between customers & developers
 Use of metaphors (a story that everyone, customers, programmers &
managers, can tell about how the system works)
XP Values

2. Simplicity
 To achieve simplicity, XP restricts developers to design only for immediate
needs rather than future needs
 Idea is to create a simple design that can be easily implemented in code
 Refactoring should be used: refactoring is to improve the internal structure
of a design w/o changing its external functionality or behavior
XP Values

3. Feedback
 Feedback is derived from 3 sources
1)The implemented software itself, 2)the customer, and 3)other software team
members.
 S/w – using effective testing strategies
 The rest results provides the team with feedback
 Unit testing is the primary testing strategy
 As an increment is delivered, the user stories or use cases that are implemented by
the increment are used as a basis for acceptance tests.
 The degree to which the s/w implements the o/p function, behavior of the use case
is a form of feedback
 As new requirements are added(iterative planning), the team provides the
customer with rapid feedback regarding cost & schedule impact
XP Values

4. Courage
 Beck says that strict adherence to XP practices demands courage
(discipline).
 There is often pressure to design for future requirements.
 Most software teams succumb, arguing that “designing for tomorrow” will
save time and effort in the long run.
 An agile XP team must have the discipline (courage) to design for today
 As future requirements may change dramatically, thereby demanding
substantial rework
XP Values

5. Respect
 By following each of these values, the agile team inculcates respect
among it members, between other stakeholders and team members, for
the software and for the XP process.
 The Manifesto for Agile Software Development

“We are uncovering better ways of developing software by doing it and helping
others do it. Through this work we have come to value:
•Individuals and interactions over processes and tools
•Working software over comprehensive documentation
•Customer collaboration over contract negotiation
•Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the
left more.”

Kent Beck et al
74
The XP
Process
 Uses OO approach
 4 framework activities:
 Planning
 Design
 Coding
 Testing
 Extreme Programming (XP)

 The most widely used agile process

 XP Planning
 Begins with listening & then creation of “user stories”
 Story consists of required output, features & functionalities
 Each story is written by customer & is placed on index card
 The customer assigns a value (i.e., a priority) to the story
 Agile team assesses each story and assigns a cost
 Customer is asked to split the story into smaller stories & assignment of value &
cost happens again

76
Extreme Programming (XP)

 Stories are grouped to for a deliverable increment

 A commitment is made on delivery date
 After the first increment “project velocity” is calculated
 It is used to help define subsequent delivery dates for other increments
Extreme Programming (XP)

 Project velocity – no. of customer stories implemented during the first

release
 Project velocity is used to
1. help estimate delivery dates and schedule for subsequent releases
2. determine whether an overcommitment has been made for all stories across
the entire development project.
 As development proceeds customer can add stories, change the value of
an existing story, split stories, or eliminate them
 Extreme Programming (XP)

 XP Design
 Follows the KIS(keep it simple) principle
 Encourage the use of CRC(Class –Responsibility- Collaborator) cards
 CRC cards are the only design work product produced as part of the XP
process
 For difficult design problems, suggested is creation of “spike solutions”—a
design prototype
 XP develops few work products(CRC, Spike Solution)
 XP encourages “refactoring”—an iterative refinement of the internal
program design
 A central notion in XP is that design occurs both before & after coding.

79
Extreme Programming (XP)

 A CRC card is a physical card

representing a single class.
 Each card lists the class's
name, attributes and
methods (its responsibilities),
and class associations
(collaborations).
Extreme Programming (XP)

 XP Coding
 Recommends the construction of a unit test for a story before coding
commences
 It helps the developers to better focus on the task
 Encourages “pair programming”
 2 people working together at one computer workstation to create code for a
story(real time problem solving) the code is reviewed as it is created(real time
quality assurance)
 Each person takes on slightly different role
 1 person might think about coding details & other might take part in coding
standards)
 Code is then integrated with the work of others
Extreme Programming (XP)

 Integration team will integrate stories

 Sometimes continuous integration is done on a daily basis
 Continuous integration helps to avoid compatibility & interfacing problems
Extreme Programming (XP)

 XP Testing
 All unit tests are executed daily
 Unit test should be automated
 Regression testing should be done, whenever code is modified
 Integration & validation testing
 “Acceptance tests” are defined by the customer and executed to assess
customer visible functionality
Other Agile process models

 Adaptive Software Development (ASD)

 Scrum
 Dynamic Systems Development Method (DSDM)
 Crystal
 Feature Drive Development (FDD)
 Lean Software Development (LSD)
 Agile Modeling (AM)
 Agile Unified Process (AUP)
 SCRUM

 Conceived by Jeff Sutherland and his development team in the early 1990s
 Further development by Schwaber and Beedle
 Scrum—distinguishing features
 Work occurs in “sprints” and is derived from a “backlog” of existing
requirements
 Sprint is basic unit of development in SCRUM
 Sprints are no longer than 1 month & most commonly 2 weeks
 Meetings are very short and sometimes conducted without chairs
 Stand up meetings- track progress and re-plan
 “demos” are delivered to the customer with the time-box allocated
 Testing and documentation are on-going as the product is constructed
85
SCRUM

 It is an agile process model or agile s/w development method

 The framework activities are requirements, analysis, design, evolution, and
delivery.
 For each framework activity, work tasks occur within a process pattern
called a sprint.
 The work conducted within a sprint is modified by the Scrum team.
SCRUM
Process
Flow
SCRUM

Backlog
 A prioritized list of project requirements or features that provide business
value
 Items can be added to the backlog at any time( this is how changes are
introduced)
 The manager assess the backlog & updates priorities as required
SCRUM

Sprint
 Consist of work units that are required to achieve a requirement defined in
the backlog
 Predefined time-box (usually 30 days)
 Changes are not introduced during the sprint
 Hence the sprint allows team members to work in a short-term but stable
environment
SCRUM

SCRUM meetings
 They are short(15 min) meetings, held daily by the SCRUM team (called as
stand up meetings)
 Questions asked & answered
1. What did you do since the last team meeting?
2. What obstacles are you encountering?
3. What do you plan to accomplish by the next team meeting?
 A team leader called a SCRUM master leads the meeting & assess the
responses
 These meetings helps to uncover problem as early as possible
SCRUM

Demos
 Deliver the s/w increment to the customer
 It is demonstrated & then evaluated by the customer