0% found this document useful (0 votes)
9 views52 pages

SE ProcessImprovement0

This document discusses software process improvement, focusing on the principles, characteristics, and cycles involved in enhancing software quality and productivity. It outlines the importance of measuring and analyzing software processes, the relationship between process and product quality, and introduces the SEI's CMMI framework for process capability. Additionally, it emphasizes the Goal-Question-Metric paradigm for effective process improvement and the classification of processes based on their formality.

Uploaded by

siraj
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views52 pages

SE ProcessImprovement0

This document discusses software process improvement, focusing on the principles, characteristics, and cycles involved in enhancing software quality and productivity. It outlines the importance of measuring and analyzing software processes, the relationship between process and product quality, and introduces the SEI's CMMI framework for process capability. Additionally, it emphasizes the Goal-Question-Metric paradigm for effective process improvement and the classification of processes based on their formality.

Uploaded by

siraj
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 52

Process Improvement

Unit 5 Chapter 28

SESSION # 1

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 1


Topics


Process attributes/characteristics

The process improvement cycle

Process and product quality

The SEI’s CMMI framework

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 2


Objectives


Understand the principles of software process improvement

Understand how process factors influence quality and productivity of
software developers

Acquire skills to develop models of software processes

Understand the notion of process capability and the CMMI process
improvement model

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 3


Software Process

• Software process is a set of activities that leads to the production of


software product
• Software development process activities
• Step 1: Software specification
• Step 2: Software design and implementation
• Step 3: Software validation
• Step 4: Software Evolution
•  The result of the above four steps is a software product
• Has attributes and quality is measurable

• Software process(es) are inherently complex


• Each of these step include different software engineering practices, methods, tools
& techniques
• They have attributes or characteristics
• It is possible to measure and control a processes using attributes

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 4


Process attributes / characteristics

1. Understandability: Explicit definition and easiness to understand


2. Visibility: Culmination of clear results & progress visible externally

3. Supportability: Use of CASE tools to support process activities


4. Acceptability: Is process acceptable & usable by engineers responsible for
producing the product

5. Reliability: Can process errors be avoided or trapped before they


result in product errors?

6. Robustness: Can the process continue despite unexpected problems


7. Maintainability: Can the process evolve to reflect changing organizational
requirements or to make process improvements

1. Rapidity: How fast can the process be completed – cycle time

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 5


Process improvement cycle

• Process Improvement is performed in a cyclic manner:

1. Process measurement
• Attributes of current project processes are measured
• Aim is to improve process improvement goals

2. Process analysis
• Process is assessed to identify
• Bottlenecks
• Weaknesses
• Process model describing the process are developed

3. Process change
• Changes identified during analysis are introduced

Underlying principle: If we can measure then we can control ! ! !

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 6


Process attributes

Time sheet management system

1.Employee
1. Create time sheet entry
2. Save time sheet
3. Submit time sheet
4. Validate time sheet – immediate
manager
5. Month end calculations

2.Manager
1. Approve time sheet

Process attributes Process Quality Metric


Process Quality Factor 1. Number of uses cases
1.Understandability
2.Visibility 2. Number of Use case clear
1.Understandability and understandable
3.Reliable
2.Visibility 3. Requirements category
4.Robust
4.Maintainable 4. Number of requirements in
5.Maintainable
each category

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 7


Software Quality Model

Process Attributes Process metrics


1.Understandability Product metrics
2.Visibility
3.Supportability
4.Acceptability
5.Reliable
6.Robust
7.Maintainable Project metrics
8.Rapidity Ex: Software Quality Factors
1.Correctness, unambiguous
Clear
1.Reliability,
2.Usability
3.Integrity A software quality model is a defined set
4.Efficiency of characteristics, and of relationships
5.Maintainability, between them, which provides a framework
6.Flexibility for specifying quality requirements and
7.testability, evaluating quality (ISO/IEC 25000:2005)
8.portability, (ISO/IEC, 2011).
9.reusability,
10.interoperability
©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 8
Correlating Product & Process Measurement for Process
Improvement

• How to select these measures  Given by Goal Question - Paradigm

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 9


Software Process Measurement - Metric

• A software metric is a measure of software characteristics which are measurable or


countable. Software metrics are valuable for many reasons, including measuring
software performance, planning work items, measuring productivity, and many other uses.
Metrics can be classified into three categories:
• Process metrics
• Used to improve software development/maintenance: such as development time,
productivity, quality
 Applying this in the model it will provide indicators of process quality

• Product metrics:
• Product metrics describe the characteristics of the product such as size, complexity, design
features, performance, and quality level.
 Applying this in the model it will provide indicators of product quality

• Project metrics:
• Metrics used by project manager to check project's progress such as schedule, cost, quality,
resources which can indicate projects progress status
 Applying this in the model it will provide indicators of project quality

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 10


Process analysis
Example requirements process

• Requirements process – 1
1. Define problem statement -
0.5d
2. Meet customer obtain requirements - 2d
3. Meet internal engineers discuss SRS plan - 2d
4. Prepare SRS document - Engineer - Reqs clearly numbered -4
d
5. Review with internal engineer – Ver / Val - 2d
6. Review # 1 with customer– Verification - 2d
7. Update SRS, Internal engineers review - 2d
8. Baseline - 1d
9. Validate & Approve SRS for Design  promote to design stage – 1d
Total days – cycle time – rapidity - 16.5 days

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 11


Process analysis
Example requirements process

• Requirements process – 2 Improved


1. Define problem statement - 1d
2. Meet customer obtain requirements - 1d
3. Meet internal engineers discuss SRS plan - 1d
4. Brainstorm and obtain viewpoints -1d
5. Prepare SRS document - By Team leader - Reqs clearly numbered -2
d
6. Perform requirement analysis and review all use cases -1d
7. Review with internal engineer – Ver / Val - 1d
8. Review with customer as many times needed – Verification - 1d
9. Update SRS, Internal engineers review - 1d
10. Baseline - 0d
11. Validate and pass if total errors are less than 5 - Team leader - 1d
12. Approve SRS for Design  promote to design stage – 1d
Total days – cycle time – rapidity - 12 days

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 12


Example requirements work product analysis
result metric data

Requirements process – v1 Requirements process – v2 Improved -


interim product review report interim product review report
Work product measurements: Work product measurements:

•5 Unclear requirements •0 Unclear requirements


•10 Ambiguous requirements •0 Ambiguous requirements
• Maintainability •View point documented
• Lacks integrity
•Use cases diagrams clear and good
•No use cases diagrams
• Low clarity of flow
• Low visibility
•7 Implicit requirements not reviewed with •2 Implicit requirements not clear will be
customer clear during design
•TOTAL DEFECTS: 22 •TOTAL DEFECTS: 2

Work product quality factors: Work product quality factors:


Software quality, Requirements clarity, Software quality, Requirements clarity,
Visibility for design implementation, Visibility for design implementation,
Traceability Traceability
©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 13
Example requirements process analysis

Requirements process – v1 Requirements process – v2


Improved

• 10 Steps - 16.5 days cycle time • 12 Steps - 12 days cycle time


• Meeting with customer – 1 • Meeting with customer – 1
• Meeting with internal team – 1 • Meeting with internal team – 1
• Brain storm & vide points session - 1
• SRS preparation - Engineer • SRS preparation - Team leader
• Analysis - Requirements & uses case
• Review with customer – 1 • Review with customer – 1 + as required
• Review/Update internal team – 1 • Review/update internal team – 2
• Validate,
• Criteria < 5 total errors – Team leader

• Validate and approve • Approve and pass to next stage

Understandable, Visible, Robust, Reliable, Understandable, Visible, Robust, Reliable,


Robust, rapidity,  Cost ? Robust, rapidity,  Cost ?

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 14


Process improvement

• Process improvement was introduced by Edward Deming's an American


engineer during his work with Japanese industry, Introduced concepts of
• Continuous process improvement
• Statistical quality control and process repeatability

• Approach:
• Measure the number of product defects and relate the defects to the process

• Objective:
• Reduce the number of product defects by improving the process

• Watts Humphry:
• Process and product relationship is obvious
• Product quality depends upon the quality of process used to develop the product
• Improve the process to make less defects  this will improve the product quality

• Two aspects  “Intellectual Capability of resource” and ”the process used”

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 15


Software Quality
• Quality software is reasonably bug or defect free, delivered on time
and within budget, meets requirements and/or expectations, and is
maintainable. ISO 8402-1986 standard defines quality as “the totality
of features and characteristics of a product or service that bears its
ability to satisfy stated or implied needs.”

• Quality factors: McCall proposed correctness, reliability, usability,


integrity, efficiency, maintainability, flexibility, testability, portability,
reusability, interoperability factors. A quality criterion is an attribute
of a quality factor that is related to software development.
• ISO 9126

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 16


Goal-Question-Metric Paradigm

• Process improvement requires to quantify process, measure and


analyze to determine if process improvement is achieved

• Difficulty in process improvement


• What to measure and how to use ?

• Approach  Goal – Question – Metric paradigm


• By Basili & Rombach

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 17


Goal-Question-Metric Paradigm

• Goals:
• What is the organization trying to achieve ?
• Improved programmer productivity &
• Shorter product development time
• Increase product reliability
• Questions:
• Identify areas of uncertainty to refine the goal
• Answer ”Goal” related questions; such as:
• How to increase number of debugged lines of code
• How to reduce time to finalize requirements
• How to do reliability assessment more effectively
• Metric:
• Measurements that answer questions And Confirm if process improvement has
achieved desired goal
• Based on Experience of engineer / engineer productivity measurement
• Debugged LOC / # of formal communication with stakeholder's
• Each requirement change / number of test required  Product failure

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 18


Process improvement

• Process Improvement involves task of measuring, analyzing


and changing the process with a objective of improving the
existing processes to result in
• Process optimization
• Improving quality
• Reducing defects
• Reducing cost
• etc….

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 19


Why is process Improvement possible ?

• A sound relationship exists between the Software


process and software product quality
• Measurements can be performed on product to assess
product quality level and correlate with process
performance
• Process improvements can be performed based on
current level of Process performance

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 20


Process Improvement
Unit 5 Chapter 28

SESSION # 2

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 21


Why is process Improvement possible ?

• A sound relationship exists between the Software


process and software product quality
• Measurements can be performed on product to assess
product quality level and correlate with process
performance
• Process improvements can be performed based on
current level of Process performance

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 22


Process classification

• Processes are classified based on degree of formality


• Informal processes
• No strict defined process model
• Development team chooses the process they choose to use
• May use formal process such as ; configuration management
• Managed processes
• Defined process model drives the development process
 Process defines related procedures

 Scheduling and relationship between procedures

• Methodical processes
• Defined development method/methods are used
 Ex: object oriented method

• Processes are supported by CASE tool support


• Improving processes
• Quantitative process improvement goals
• Process with inherent improvement objectives
• Process improvement budget allocated

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 23


Process classification

Enables choosing appropriate processes for specific project

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 24


Process analysis and modelling

• Concerned with study existing process


• Develop an abstract process model
• Capture process key characteristics
• Understand the relationship between parts of the process
• Perform qualitative analysis
• Perform quantitative analysis and obtain metric data
• Describe the process using a software process model
• Thus, Enable understanding of process

• Process model: Input  Activities  Output - with roles & responsibility

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 25


Process analysis and modelling
Techniques for process analysis

1. Questionnaire and interview techniques


• Stakeholders using the process are questioned
• Responses are obtained
• Discussion is structured around the process model
• Refined as new information becomes available

2. Ethnography studies
• Understand the nature of software development as human activity
• The indirect (subtle) activities and complexities are understood

 Process model data for process improvement should cover


• Activities, Deliverables, People, Communication, Schedule
• Organization processes that affect the software development

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 26


Process model

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 27


Process model terminology

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 28


Test module – Test Data Preparation

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 29


Test module – Module harness preparation

• Test harness:
• Test execution engine & Test script repository
• Automated test framework
• Test data configured to test program
• Different conditions identified

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 30


Test module – Test execution

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 31


Process – reporting

• Process model should dynamically handle exceptions


• Resource ill and not coming for work
• Breach of computer security

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 32


Process improvement cycle

1. Process measurement

2. Process analysis

3. Process change

Underlying principle: If we can measure then we can control ! ! !

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 33


Process change – Concerns & how to do

• Concerns making modifications to existing process by


• Introducing new practices, methods or tools
• Changing the ordering of the process activities
• Introducing or removing deliverables from process

• Process modifications must be done by


• Setting process goals
• Example: Reduce number of defects during integration testing by 25%
• Process goals should drive the process change

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 34


Process change process

Change process involves five stages


• Improvement identification
• Improvement prioritization
• Process change introduction
• Process change training
• Change tuning

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 35


Process change process

• Improvement identification
• From results of process analysis identify process bottlenecks that affect
• Schedule, cost, quality or cost
• Propose new ways of loosening the bottlenecks to address the problem
• New methods, tools, techniques, procedures etc.

• Improvement prioritization
• Assess possible changes
• Prioritize for implementation based on
• Importance, and need to improve specific process areas
• Understand the cost and impact of changes

• Process change introduction


• Integrate and Implement the changes agreed upon into the process
• Allow time to ensure change are compatible

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 36


Process change process

• Process change training


• Resistance to change is common among all stakeholders
• If process is not used then the quality of product will degrade
• Provide training on the changed process to all users

• Change tuning
• Effectiveness of process changes cannot be observed immediately
• Tuning when minor problems are discovered
• Tuning is done until all users are happy with using the process

Continuing Process improvement is a continuous iterative process

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 37


Process and Process model

Process definition  Organization focus  Organization vision/mission


•Organization level processes
•Project level processes
• Organization processes

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 38


Process improvement cycle

1. Process measurement

2. Process analysis

3. Process change

Underlying principle: If we can measure then we can control ! ! !

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 39


Process change process

Change process involves five stages


• Improvement identification
• Improvement prioritization
• Process change introduction
• Process change training
• Change tuning

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 40


Process Improvement
Unit 5 Chapter 28

SESSION # 3

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 41


Process Improvement Framework

• Capability maturity model (CMM) (Paulk) (1993 / 1995)


• Software Engineering Institute (SEI)
• Mainly for assessing software contractor(S)
• Taken seriously for process improvement
• Next version is CMMI – Capability maturity model integrated (CMMI)
• Intended for software process improvement (2001)
• Bootstrap project – (1994) Hasse, Kuvaja
• With a purpose of extending CMM model to wider range of companies
• Additional proposals:
• Guidelines for company-wide quality system to support process improvement
• Distinction between organization, methodology and technology
• Base process model (Used by European space agency)

• Software process improvement and capability determination (SPICE)


• ISO/IEC 15504 Information technology – process assessment (1994) Paulk, Korad
• Customer – supplier processes
• Rating scale – Not achieved (0–15%) / Partially achieved (> 15-50%) / Largely achieved (>50-85%) / Fully
achieved (>85-100%)

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 42


Process Improvement Framework - CMM/CMMI

• Maturity Level
• Staged model - 5 Maturity levels, each level is associated with defined processes

• Continuous model - 6 Assessment level for each process (Totally 24 processes)


• Process Areas: Relevant to process capability and improvement
• Process Category
• Process Management - 5 process areas
• Project Management - 7 process areas
• Engineering - 6 process areas
• Support - 6 process areas

• Goals : Desirable state to be attain by an organization


• Generic goals: associated with institutionalization of good practices - Not technical
• Specific goals: associated with process area & define desirable state - Technical

• Practices: Define the ways to achieving a goal – upto 7 GP & SP in each process area
• Generic Practices (GP): organizational practices - Not technical
• Specific Practices (SP): process area technical practices

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 43


Process Improvement Framework - CMM/CMMI

Staged model Continuous model

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 44


Process categories and Process areas

• Process Management
• Organization process definition, Organization process focus, Organization training,
Organization process performance, Organization innovation and deployment

• Project Management
• Sw Project Planning, Sw Project monitoring and control, Sw subcontractor management,
Supplier agreement management, Integrated project management, Risk management,
Integrated teaming, Quantitative project management

• Engineering
• Requirements management, Requirements development, w quality assurance, Sw
configuration management, Technical solution, Product integration, Verification, Validation

• Support
• Configuration management, Process and product quality management, Measurement and
analysis, Decision analysis & resolution, Organizational environment for integration, Causal
analysis and resolution

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 45


Process Improvement Framework
CMMI model Process Goal

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 46


Process Improvement Framework
CMMI model Practices – Associated Goal

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 47


CMM/CMMI Assessment

Assessment involves examining processes and rating on 6 point scale


• Not performed: One or more goals with specific practices is not satisfied
• Performed:
• Process area goals are satisfied
• Scope of work to be performed is explicitly set out
• Work clearly communicated to team members

• Managed:
• Goals are met
• Organization policy is in place for each process
• Documented plan, resource management plan & process monitoring procedure is in place

• Defined: Focus is on organization & deployment of processes


• Each project has managed process
 process is tailored from organization standard process
 Process assets & process measurements collected & used for process improvement

• Quantitatively managed:
• Organization uses statistical & quantitative methods to control sub-processes/process management

•Optimizing:
• Organize & uses product and process measures for process improvement / Trend analysis

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 48


CMM/CMMI Models

1. Staged model:
• 5 Maturity levels
• Each level is associated with defined process area

2. Continuous model:
• 6 Assessment level for each process
• Totally 24 processes

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 49


Process Improvement Framework – CMMI Staged Model

• Maturity Level
• Staged model - 5 Maturity levels, each level is associated with defined processes
• Characterizes by maturity of process practices (generic & specific) in each level

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 50


Process Improvement Framework – CMMI Continuous Model

• Maturity Level
• Continuous model - 24 processes 6 Assessment level for each process
• Characterizes by capability of process (generic & specific practices ) – process profile

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 51


End of Unit 5 and syllabus

Revision Classes for Mse 2, Mse 3 and for


Final Exams,
will start from 18th May with schedule

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 52

You might also like