Chapter 2

A Generic View
of
Process

Software Engineering: A Practitioner’s Approach, 6th edition

1
 Contents
• Overview
• What is Engineering and Software Engineering?
• Need and Importance
• Software Paradigms
• Software Engineering – A Layered Technology
• A Process Framework
• The CMMI ( Capability Maturity Model Integration)
• Personal and Team Process Models
 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 disordered 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.

Software process is a framework for the tasks that are required

3
 Engineering
• Engineering is all about developing products, using well-
defined, scientific principles and methods.
 Software Engineering
Software Engineering (Fritz Bauer ):
The establishment and use of sound
engineering principles in order to obtain
economically software that is reliable and
works efficiently on real machines.
Software Engineering (IEEE Standard 610.12-
1990):
(1)The application of a systematic,
disciplined, quantifiable approach to the
development, operation, and maintenance of
software; that is, the application of
engineering to software.
(2)The study of approaches as in (1)
Boehm defines SE as 'the practical application
 Why you need it?
Need arises because of higher rate of change in
user requirements and environment.
•Large software
•Scalability
•Cost
•Dynamic Nature
•Quality Management
Importance of SE
 Software Paradigms
Software paradigms refer to the methods and steps, which
are taken while designing/developing the software.
Software Development Paradigm
•Requirement gathering
•Software design
•Programming
Software Design Paradigm
•Design
•Maintenance
•Programming
Programming Paradigm
•Coding
•Testing
•Integration
 A Layered
Technology
Software Engineering

tools

methods

process model

a “quality” focus

9
 A Process Framework
• Establishes the foundation for
a complete software process
identifying small number of
framework activities that are
applicable to all software
projects, regardless of their
size or complexity.
• Encompasses a set of
umbrella activities that are
applicable across the entire
software process.
A Software
Process
Framework
(Cont.) 11
Generic Framework and Umbrella Activities
Generic Process Umbrella Activities
Framework Activities
- Software Project Tracking and Control
- Communication - Risk Management
- Planning - Software Quality Assurance
- Modeling - Formal Technical Reviews
- Measurement
- Construction
- Software Configuration Management
- Deployment
- Reusability Management
- Work Product Preparation and
Production
The Process Model: Adaptability
• The framework activities will always be
applied on every project... BUT
• The tasks (and degree of rigor) for each
activity will vary based on:
– the type of project
– characteristics of the project
– common sense judgment; concurrence of
the project team
The CMMI (The Capability Maturity Model Integration)
• Represents a process meta-model in two different
ways: (1) as a continuous model; (2) as a staged model;
• It was developed by SEI (Software Engineering Institute)
• 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.
 Levels of CMMI
• Level 0: Incomplete – the process area (e.g., requirements management) is either not
performed or does not achieve all goals and objectives
• Level 1: Performed - All of the specific goals of the process area (as defined by the
CMMI) have been satisfied and work tasks required to produce to define work
products are being conducted.
• Level 2: Managed - all capability level 1 criteria have been satisfied, all work tasks and
work products are “monitored, controlled, and reviewed; and are evaluated by
people”.
• Level 3: Defined - all capability level 2 criteria have been achieved and the process is
“tailored from the organization’s set of standard processes and contributes work
products, measures, and other process-improvement information”.
• Level 4: Quantitatively managed - All capability level 3 criteria have been achieved and
the process area is controlled and improved using measurement and quantitative
assessment.
• Level 5: Optimized - All capability level 4 criteria have been achieved and the process
area is adapted and optimized using quantitatively (statistical) to meet changing
customer needs and to continually improve the efficacy of the process area under
consideration.
Process Areas to Achieve Maturity Models

16
 CMMI – Specific Goals and Practices
project planning is one of eight process areas defined by the CMMI for “project management”
category having the following specific goals (SG) and the associated specific practices (SP) such as
•SG 1 Establish Estimates
- SP 1.1-1 Estimate the Scope of the Project
- SP 1.2-1 Establish Estimates of Work Product and Task Attributes
- SP 1.3-1 Define Project Life Cycle
- SP 1.4-1 Determine Estimates of Effort and Cost
•SG 2 Develop a Project Plan
- SP 2.1-1 Establish the Budget and Schedule
- SP 2.2-1 Identify Project Risks
- SP 2.3-1 Plan for Data Management
- SP 2.4-1 Plan for Project Resources
- SP 2.5-1 Plan for Needed Knowledge and Skills
- SP 2.6-1 Plan Stakeholder Involvement
- SP 2.7-1 Establish the Project Plan
•SG 3 Obtain Commitment to the Plan
- SP 3.1-1 Review Plans That Affect the Project
- SP 3.2-1 Reconcile Work and Resource Levels
- SP 3.3-1 Obtain Plan Commitment
 CMMI – Generic Goals and Practices
The generic goals (GG) and practices (GP) for the
project planning process area are GG 4 Institutionalize a Quantitatively
GG 1 Achieve Specific Goals Managed Process
- GP 1.1 Perform Base Practices - GP 4.1 Establish Quantitative Objectives for
GG 2 Institutionalize a Managed Process the Process
- GP 2.1 Establish an Organizational Policy - GP 4.2 Stabilize Sub-process Performance
- GG 5 Institutionalize an Optimizing Process
- GP 2.2 Plan the Process
- GP 5.1 Ensure Continuous Process
- GP 2.3 Provide Resources
Improvement
- GP 2.4 Assign Responsibility
- GP 5.2 Correct Root Causes of Problems
- GP 2.5 Train People
- GP 2.6 Manage Configurations
- GP 2.7 Identify and Involve Relevant Stakeholders
- GP 2.8 Monitor and Control the Process
- GP 2.9 Objectively Evaluate Adherence
- GP 2.10 Review Status with Higher-Level Management
GG 3 Institutionalize a Defined Process
- GP 3.1 Establish a Defined Process
- GP 3.2 Collect Improvement Information
Personal and Team Process Models
• The best software process is one that is close to the people who
will be doing the work.
• In an ideal setting, you would create a process that best fits
your needs, and at the same time, meets the broader needs of
the team and the organization – Personal Software Process
(PSP)
• The team itself can create its own process, and at the same
time meet the narrower needs of individuals and the broader
needs of the organization – Team Software Process (TSP)
• Both require hard work, training, and coordination, but both
are achievable – Watts Humphrey [HUM97 and HUM00]
 Personal Software Process (PSP)
• Recommends five framework activities:
– Planning
– High-level design
– High-level design review
– Development
– Postmortem
• Stresses the need for each software engineer to
identify errors early and as important, to understand
the types of errors.
 Team Software Process (TSP)
• Build self-directed teams that plan and track their work,
establish goals, and own their processes and plans.
• It is a pure software team or integrated product team (IPT)
of 3 to about 20 engineers.
• Show managers how to coach and motivate their teams and
how to help them to sustain at peak performance.
• Accelerate software process improvement by making CMM
Level 5 behavior normal and expected.
• Provide improvement guidance to high-maturity
organizations.
• Facilitate university teaching of industrial-grade team skills.