CHAPTER-2

A GENERIC VIEW OF PROCESS

 Chapter Overview
• What? A software process – a series of predictable
steps that leads to a timely, high-quality product.
• Who? Managers, software engineers, and customers.
• Why? Provides stability, control, and organization to
an otherwise chaotic activity.
• Steps? A handful of activities are common to all
software processes, details vary.
• Work product? Programs, documents, and data.
• Correct process? Assessment, quality deliverable.
2.1 Software Engineering-A Layered
Technology

tools
methods
process model
a “quality” focus
QUALITY:-

Any engineering approach must rest on an

Organizational commitment to quality.

The bedrock that supports software engineering is

a quality focus.
PROCESS:-
Process defines a frame work that must be
established for effective delivery of software
engineering technology.
The software process forms the basis for
management control of software projects and
establishes the context in which technical methods
are applied, work products( documents, models,
data,
reports, forms, etc.) are produced, milestones are
established, quality is ensured and change is
properly
managed.
METHODS:-
S/W engineering methods provide the technical
“how to’ s” for building s/w.
Methods encompass a broad array of tasks
that include communication, requirements
analysis, design modeling, program
construction, testing and support.
Tools:-

Software technology tools provide automated or

semi-automated support for the process and the
methods.

When tools are integrated so that information

created by one tool can be used by another, a
system for the software development, called
Computer-Aided Software engineering is
established.
 2.2 A Process Frame Work

A Process framework establishes the foundation

for a complete software process identifying a small
number of framework activities that are applicable
to all software projects, regardless of their size or
complexity.
 A Common Process
Framework
process framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities

The process framework encompasses a set of Umbrella

activities that are applicable across the entire software
process.
The following generic (common) process framework is
applicable to the vast majority of software projects:

 Communication (customer collaboration and

requirement gathering)
 Planning (establishes engineering work plan,
describes technical risks, lists resource
requirements, work products produced, and
defines work schedule)
 Modeling (creation of models to help developers
and customers understand the requires and
software design)
 Construction (code generation and testing)
 Deployment (software delivered for customer
evaluation and feedback)
 Umbrella Activities
 Software project management
 Formal technical reviews
 Software quality assurance
 Software configuration management
 Document preparation and production
 Reusability management
 Measurement
 Risk management
 Attributes for Comparing Process Models
 Overall flow and level of interdependencies among tasks
 Degree to which work tasks are defined within each
framework activity
 Degree to which work products are identified and
required
 Manner in which quality assurance activities are applied
 Manner in which project tracking and control activities
are applied
 Overall degree of detail and rigor of process description
 Degree to which stakeholders are involved in the project
 Level of autonomy given to project team
 Degree to which team organization and roles are
prescribed
 2.3 Capability Maturity Model Integration
(CMMI)
 The CMMI defines each process area in terms
of “specific goals” and the “specific practices”
required to achieve these goals.
 Specific goals establish the characteristics
that must exist if the activities implied by a
process area are to be effective.
 Specific practices refine a goal into a set of
process-related activities.
 The CMMI represents a process
meta-model in two different ways:
1. Continuous model
2. Staged model.
 Capability levels:-
Level 0: Incomplete.
The Process area is either not performed or
does not achieve all goals and objectives
defined by the CMMI for level 1 capability.

Level 1: Performed.
All of the specific goals of the process area
have been satisfied. Work tasks required to
produce defined work production are being
conducted.
Level 2: Managed.

All work associated with the process

area conforms to an organizationally defined policy;
All people doing the work have access to adequate
resources to get the job done;
Stakeholders are actively involved in the process
area as required;
All work tasks and work products are “monitored,
controlled, and reviewed;
Level 3: Defined.

The process is “tailored from the organization’s set

of standard processes according to the
organization’s tailoring guidelines, and contributes
work products, measures, and other
process-improvement information to the
organizational process assets” .
Level 4: Quantitatively managed.
“Quantitative objectives for quality and
process performance are established and
used as criteria in managing the process”.

Level 5: Optimized.
The process area is adapted and optimized using
quantitative means to meet changing customer
needs and to continually improve the efficacy of
the process area under consideration.
The specific goals (SG) and specific practices (SP)
defined for project planning are:-
SG 1: Establish estimates
SP: 1. Estimate the scope of the project
2.Establish estimates of work product and
task attributes.
3. Define project life cycle.
4. Determine estimates of effort and cost.
SG 2: Develop a project plan
SP: 1. Establish the budget and schedule
2. Identify project risks
3. Plan for data management.
4. Plan for project resources.
5. Plan for needed knowledge and
skills.
6. Plan stakeholder involvement.
7. Establish the project plan.
SG 3: Obtain commitment to the plan
SP: 1. Review plans that affect the
project.
2. Reconcile work and resource levels.
3. Obtain plan commitment.
The Generic goals (GG) and practices (GP) for the
project planning process area are:
GG 1: Achieve specific goals
GP: 1. Perform base practices.

GG 2: Institutionalize a managed process

GP: 1. Establish an organizational policy
2. Plan the process.
3. Provide resources.
4. Assign responsibility.
5. Train people.
 6. Manage configurations.
7. Identify and involve relevant
stakeholders.
8. Monitor and control the process.
9. Objectively evaluate adherence.
10. Review status with higher level
management.

GG 3: Institutionalize a defined process

GP: 1. Establish a defined process.
2. Collect improvement information.
GG 4: Institutionalize a quantitatively managed
process.
GP: 1. Establish quantitative objectives for the
project.
2. Stabilize subprocess performance.

GG 5: Institutionalize a Optimizing process.

GP: 1. Ensure continuous process
improvement.
2. Correct root cause of problems.
 2.4 Process Patterns
 Process Patterns define a set of activities, actions, work
task , work products and /or related behaviours.
 Templates or methods for describing important
characteristics of software processes .
 Examples:- Customer Communication( Process activity )
Analysis( An action )
Requirement gathering( Process task )
Design model ( Work Product )
 Software teams can combine software patterns to
construct processes that best meet the needs of specific
projects
Generic software pattern elements :-
• Pattern Name
• Intent (objective of pattern)
• Type
• Task pattern (defines engineering action or
work task)
• Stage pattern (defines framework activity for
the process)
• Phase pattern (defines sequence or flow of
framework activities that occur within process
• Initial context (describes conditions that must be
present prior to using pattern)
 Problem (The Problem to be solved by the
pattern is described).
 Solution (describes how to implement pattern
correctly)
 Resulting context (describes conditions that
result when pattern has been implemented
successfully)
 Related patterns (links to patterns directly
related)
 Known uses/examples (instances in which
pattern is applicable)
 2.5 Process Assessment
The Process should be assessed to ensure that
it meets a set of basic process criteria that have
been shown to be essential for a successful
software engineering.
Many different assessment option are available.
-SCAMPI
-CBA IPI
-SPICE
-ISO 9001:2000
Standard CMMI Assessment Method for
Process Improvement (SCAMPI):-
It provides a five-step process assessment model
that incorporates initiating, diagnosing, acting,
establishing learning.

CMM-Based Appraisal for Internal Process

Improvement (CBA IPI):-
Provides a diagnostic technique for assessing the
relative maturity of a software organization.
SPICE (ISO/IE15504):-
 SPICE (ISO/IE15504) standard defines a set of
requirements for process assessment

ISO 9001:2000:-
 ISO 9001:2000 for Software defines
requirements for a quality management system
that will produce higher quality products and
improve customer satisfaction
 Assessment and Improvement

Software Process

Identifies Is examined Identifies

Modifications by capabilities and
to risk of
Software Process
Assessment

Leads to Leads to

Software Process Capability

Improvement Determination
Motivates
 2.6 Personal and Team Process Models

1. Personal Software Process (PSP):-

The Personal Software Process (PSP)

emphasizes personal measurement of both the
work product that is produced and the resultant
Quality of the work product .
What is PSP?
The Personal Software Process shows engineers
how to
1. Manage the quality of their projects.
2. Make commitments they can meet.
3. Improve Estimating and Planning.
4. Reduce defects in their products.

The PSP can be used by engineers as a guide to a

disciplined and structured approach to developing
software.
The PSP can be applied to many parts of the
software development process, including
 small-program development
 requirement definition
 document writing
 systems tests
 systems maintenance

 enhancement of large software systems

The PSP process model defines the five
framework activities:
1. Planning:- This activity isolates requirements.
2. High-Level Design:-External Specifications.
3. High-Level Design Review:-Formal verification.
4. Development:- The component level design.
5. Postmortem:- The effectiveness of the process
is determined.
2. Team Software Process (TSP):-
The goal of TSP is to build a “Self-Directed”
Project team that organizes itself to produce high-
quality software.
What is TSP?
The Team Software Process (TSP), along
with the Personal Software Process (PSP),
helps the high-performance engineer to
1. Ensure quality software products
2. Create secure software products
3. Improve process management in an
organization
Objectives of TSP:-
 Build self-directed teams that plan and track
their work, establish goals, and own their
processes and plans
 Show managers how to coach and motivate their
teams and maintain peak performance
 Accelerate software process improvement by
making Level 5 behavior normal and expected
 Provide improvement guidance to high-maturity
organizations
 Facilitate university teaching of industrial team
skills
TSP defines the following framework activities:
1. Launch
2. High-Level Design
3. Implementation
4. Integration and test
5. Postmortem.
Each project is “launched” using a sequence of tasks
To establish a solid basis for starting the project.

 Review project objectives with management and

agree on and document team goals.
 Establish team roles.
 Define the team’s development process.
 Make a quality plan and set quality targets.
 Plan for the needed support facilities.
 Make a development plan for the entire project.
 Make detailed plans for each engineer for the
next phase.
 Merge the individual plans into a team plan.
 Rebalance team workload to achieve a minimum
overall schedule.
 Assess project risks and assign tracking
responsibility for each key risk.
 2.7 Process Technology Tools

 Used to adapt process models to be used by

software project team
 Allow organizations to build automated models of
common process framework, task sets, and
umbrella activities
 These automated models can be used to
determine workflow and examine alternative
process structures
 Tools can be used to allocate, monitor, and even
control all software engineering tasks defined as
part of the process model
2.8 Process and Product.