Software Process Improvements Based on Capability Maturity Model CMM

1
Software Process Improvements Based on Capability
Maturity Model (CMM)

• ? ? ? ? ?

2
CONTENTS

• Introduction to Software Engineering
• Fundamentals of Process Improvement
• Overview of CMMI Models

3
Course Objectives

• understand the importance of having defined
  process
• understand the rationale for process improvement
• comprehend the CMMI model
• identify ways of applying the CMMI model to
  achieve process improvement

4
(No Transcript)
5
Requirements engineering processes

• Feasibility studies.
• Requirements elicitation and analysis.
• Requirements validation.
• Requirements management.

6
Software requirements

• Functional and non-functional requirements.
• User requirements.
• System requirements.
• The software requirements document.
• Formal Specification

7
System Models

• Context models.
• Behavioural models.
• Data models.
• Object models.

8
Software prototyping

• Prototyping in the software process.
• Rapid prototyping techniques.
• User interface prototyping.

9
Formal Specification

• Formal specification in the software process.
• Interface specification.
• Behavioural specification.

10
DESIGN

• Structured Programming
• Modularity
• Functional Decomposition
• Data Structure Design
• Data Flow Design
• Object-Oriented Design
• User Interface Design
• Formal Development

11
DESIGN

• Architectural design.
• Distributed systems design
• Object-oriented design
• Real-time software design
• Design with Reuse
• User interface design

12
PROGRAMMING PARADIGMS

• The Programming Language
• Object-Oriented Programming (OOP)
• Concurrent Programming

13
VERIFICATION AND VALIDATION

• Verification and validation planning
• Software inspections
• Automated static analysis
• Cleanroom software development

14
Software testing

• Defect testing.
• Integration testing.
• Object-oriented testing

15
Critical systems validation

• Formal methods and critical systems.
• Reliability validation.
• Safety assurance.
• Security assessment.

16
MANAGEMENT

• Managing people
• Limits to thinking.
• Group working.
• Choosing and keeping people.
• The People Capability Maturity Model.
• Software cost estimation
• Productivity.
• Estimation techniques.
• Algorithmic cost modelling.
• Project duration and staffing

17
MANAGEMENT

• Quality management
• Quality assurance and standards.
• Quality planning.
• Quality control.
• Software measurement and metrics.
• Process Improvement.
• Process and product quality.
• Process analysis and modelling.
• Process measurement.
• The SEI Process Capability Maturity Model.
• Process classification

18
Software re-engineering

• Source code translation.
• Reverse engineering.
• Program structure improvement.
• Program modularisation.
• Data re-engineering.

19
Configuration management

• Configuration management planning.
• Change management.
• Version and release management.
• System building.
• CASE tools for configuration management.

20
Software change

• Program evolution dynamics.
• Software maintenance.
• Architectural evolution.

21
Process Models

• Process iteration.
• Software Specification.
• Software design and implementation.
• Software validation.
• Software evolution.
• Automated process support.

22
Project management

• Management activities.
• Project planning.
• Project scheduling.
• Risk management.

23
Software Trends (1)

• Demands for software-intensive systems has been
  growing consistently and steadily
• More and more, software costs dominate these
  systems
• 1995 DoD cost figures
• Software 35.7B
• Hardware 6.8B
• Increasingly, software products and services are
  acquired instead of developed in-house.

24
Software Outsourcing Trend (2)

• Gartner Group
• Worldwide IT outsourcing - reach 1T in 4 years.
• Outsourcing of retail financial services in the
  North America - from 8B in 1998 to 22B in 2002.
• IDC
• IT outsourcing reach 56B in 2000 and 100B
  by 2005.
• Forrester Research
• 64 of all IT outsourcing goes through U.S. based
  companies that have relationships with
  development shops abroad.

25
The State of Software Development

• 2000 US Defense Science Board Study
• 53 of projects were late and over budget, 16
  were on time, 31 were cancelled before
  completion
• There is tremendous growth in software content in
  both manned and unmanned systems
• Software requirements now amount to the bulk of
  the overall specification requirements (65 for
  the B-2 bomber, 80 for the F-22 fighter)

26
The State of Software Engineering

• Most successful projects rely on expertise
  established with similar systems
• Lack of documented processes make repeatability
  difficult
• Development efforts for unprecedented or
  significantly different systems often encounter
  problems.

27
What is the Problem? -1

• Systems are increasingly dependent on software,
  yet the brief history of software development has
  been filled with problems.
• Cost overruns
• Schedule slippage
• Failure to achieve performance objectives
• Can not realize benefits of new technologies and
  tools

28
What is the Problem? -2

• Government, industry, and the marketplace require
  software to be developed
• Better
• Faster
• Cheaper
• The workforce is already stressed out, and
  throwing technology at the problem hasn't worked

29
Ideal Case

• Applying new software methodologies and
  technologies.
• Develop and deliver reliable, usable software
  within budget and schedule commitments
• High Productivity
• High Quality

30
What can be done

• Improved and align the processes and practices of
  system engineers, software engineers, and
  managers.
• Do this by using the CMM Integrated as a basis
  for process improvement program

31
Quality Leverage Points

• Major determinants of product cost, schedule, and
  quality

People
Process
Technology
32
Definition of Process (??)

• Process
• How we do our work
• A set of practices performed to achieve a given
  purpose. May include tools, methods, materials,
  and/or people
• While process is often described as a leg of the
  process-people-technology triad, it may also be
  considered the "glue" that unifies the other
  aspects.

33
Why Focus on Process? - 1

• Everyone realizes the importance of having a
  motivated, quality work force but...
• ... even our finest people can't perform at their
  best when the process is not understood or
  operating "at its best"

34
Why Focus on Process? - 2

• Process provides a constructive, high-leverage
  focus...
• As opposed to a focus on people
• your work force, on the average, is as "good" as
  it is trained to be
• working harder is not the answer
• working smarter, through process, is the answer

35
Why Focus on Process? - 2

• As opposed to a focus on technology
• technology applied without a suitable roadmap
  will not result in significant payoff
• technology provides most benefit in context of
  appropriate process roadmap

36
Why Focus on Process? - 3

• The process management premise
• The quality of a system is highly influenced by
  the quality of the process used to acquire,
  develop, and maintain it
• This premise implies focus on processes as well
  as on product
• This is a long-established practice in
  manufacturing
• Belief in this premise is visible worldwide in
  quality movements in manufacturing and service
  industries, e.g., ISO standards.

37
Why Focus on Process

• Project Management Targets
• Cost
• Development Time
• Productivity
• Quality
• Benefits
• Predictability
• Control
• Effectiveness

38
Process Notation Schemes

• What activities are performed in the process
• Who, Why, When, How
• What inputs must you have
• What outputs do you produce
• How do you measure performance

39
Fuzziness of Software Process

• General Criteria
• Not the complete framework
• I cant tell you precisely, but I know it when I
  see it

40
The Bottom Line-1

• Process improvement should be done to help the
  business not for its own sake

41
The Bottom Line-2

• Improvement means different things to different
  organizations.
• what are your business goals?
• how do you measure process ?
• Improvement is a long-term, strategic effort.
• what is the expected impact on the bottom line?
• How will impact be measured

42
Measurable Benefits

• The available data is taken from software process
  improvement efforts.
• Results Boeing Effort estimation
• variance is between 20 to 20

43
Other Observed Benefits of Process Improvement

• Cited by Hughes, Tinker AFB, Schlumberger,
  Raytheon
• improved working conditions
• improved employee morale
• less turnover
• fewer overtime hours
• better and increased communication
• decreased risk
• increased customer satisfaction

44
A Measurable Return

• Process improvement provides measurable return on
  investment when measured
• Return on software improvement investment
  reported between 51 and 81
• Additional benefit is intangible and cannot be
  easily quantified
• CMMI is a useful tool for guiding improvement

45
CMMI Models to the Rescue

• CMMI models were created to help realize the
  benefits of process improvement

46
CMMI-Based Improvement

• Improve organizational practice to allow people
  to use technology better
• Use a model of successful practices for improving
  development, maintenance and sustainment, and
  management
• CMMI models fill this niche
• based on widely-accepted models with a proven
  history of benefits

47
What is a CMMI Model

• Framework that contains the key elements of
  effective processes for the software engineering
• The model is a structured collection of elements
  of effective processes
• Processes included are those proven by experience
  to be effective within their respective
  environment

48
CMMI models

• A CMMI model provides an integrated view of
  process improvement across multiple disciplines
  (e.g. software engineering and systems
  engineering)
• The CMMI can help
• set process improvement goals and priorities
• provide guidance for quality processes
• provide a yardstick for assessing current
  practices

49
Two important concepts

• Process capability
• Pertains to an individual process
• Organizational maturity
• Pertains to a set of processes

50
Process Capability

• The range of expected results that can be
  achieved by following a process. It can be a
  predictor of future project outcome

upper control limit
lower control limit
51
Low Capability Process

• Highly dependent on current practitioners
• Improvised by practitioners management
• Not rigorously followed
• Results difficult to predict
• Low visibility into progress quality
• Compromise of functionality quality to meet
  schedule
• Use of new technology is risky

52
High Capability Process

• A disciplined approach for development and
  management
• Defined and continuously improving
• Supported by management and others
• Well controlled measured
• Institutionalized

53
Capability vs Performance

• Process Capability the range of expected
  results that can be achieved by following a
  prcess. It can be a predictor of future project
  outcomes.
• Process performance a measure of the actual
  results achieved from following a process on a
  particular project

54
Organizational Maturity

• Represented by the combined capabilities of a set
  of processes
• The particular processes in that set are chosen
  (possibly from a pre-defined set) to meet the
  process improvement needs of an organization

55
Low Organizational Maturity

• Highly dependent on current practitioners
• Improvised by practitioners management
• Not rigorously followed
• Results not predictable

56
High Organizational Maturity

• The set of organizational processes, taken as a
  whole, are of higher capability, i.e.,
• A disciplined approach for development and
  management
• Defined and continuously improving
• Supported by management and others
• Process stays long after those who built it are
  gone

57
Relating Capability and Maturity

• Being at a particular level of organizational
  maturity has process capability implications for
  multiple processes
• Knowing the process capabilities of a collection
  of processes has implications for organizational
  maturity

58
CMMI Model Representations

• An organization may choose to approach process
  improvement from either the
• process capability approach, or the
• organizational maturity approach
• CMMI models support each approach with a
  representation
• process capability approach continuous
  representation
• organizational maturity approach staged
  representation

59
Continuous Representation

• provides maximum flexibility for organizations to
  choose which processes to emphasize for
  improvement

60
Staged Representation

• Provides a pre-defined roadmap for organizational
  improvement based on proven grouping and ordering
  of processes and associated organizational
  relationships.

61
Comparing the Different Representations

• Both representations provide ways of implementing
  process improvement to achieve business goals
• Both representations provides the same essential
  content but are organized in different ways.

62
Models in Perspective

• A model is not a prcess. The model tells you what
  to do, not how to do it
• You must define the process for your organization
  that will likely incorporate other aspects of
  process

63
Process Representation - 1

• Mature processes are documented.
• Question
• What does that documentation look like?
• Answer
• It should depend on the audience
• Two general process representation forms
• formal process representation
• user-oriented process representation

64
Process Representation - 2

• Formal process representation
• audience is primarily process specialists
• detailed and formalized representation
• primarily used for process development, tailoring
  improvement
• user-oriented process representation
• audience is primarily everyday process users
• clear and simple representation
• primarily used for performing the process

65
Process Notation Schemes - 1

• What activities are performed in the process?
• Who does them
• Why are they done
• When are they done
• How are they done
• What inputs must you have
• What outputs do you produce
• How do you measure performance

66
Process Notation Schemes - 2

• Different notation schemes emphasize different
  aspects of a process and, thus, have different
  strengths and weaknesses.
• Different notations may or may not have the
  ability to represent conveniently
• sequencing of activities
• timing of activities
• data flow among activities
• hierarchical detail
• entry and exit criteria
• narrative information

67
Process Notation Schemes - 3

• Other notation scheme attributes
• flexibility
• simplicity
• ease of training and understanding
• availability of tool support

68
Some Common Process Notations

• Data flow diagrams
• Flowcharts
• Decision trees or tables
• Check lists
• etc.

69
A Simple Improvement Process

• Get started.
• Determine where you are.
• Determine where you want to be.
• Make a plan.
• Execute the plan.
• Learn lessons and do it again.

70
IDEAL Model - 1

• Initiating phase
• Stimulus for improvement
• Set context and establish sponsorship
• Establish improvement infrastructure
• Diagnosing phase
• Appraise and characterize current practice
• Develop recommendations and document phase results

71
IDEAL Model - 2

• Establishing phase
• set priorities and strategies
• plan actions
• establish process action team
• Acting phase
• plan, execute, and track installation
• plan and execute pilots
• define processes and measures

72
IDEAL Model - 3

• Learning phase
• document and analyze lessons
• revise organizational approach

73
Using CMMI Models with the IDEAL Model - 1

• Initiating phase
• Knowledge of the CMMI models can provide a
  positive stimulus for improvement and help an
  organization to establish and sustain the
  improvement context.
• Diagnosing phase
• The CMMI models provide a yardstick for
  evaluating organizational maturity.

74
Using CMMI Models with the IDEAL Model - 2

• Establishing phase
• The PAs imply a focus for the process improvement
  teams.
• Acting phase
• CMMI models provide guidance for defining or
  improving processes.
• Learning phase
• Lessons learned are documented and basis for
  revision of organizational approach.

75
Summary

• Process is a key leverage point for improvement.
• Effective process representation is crucial to
  process institutionalization.
• CMM-based improvement programs have provided
  measurable benefits.
• The CMM Integrated can be a useful tool for
  addressing current problems in systems and
  software engineering.

76
A Few Words on Terminology

• There is a great deal of commonality among the
  different CMMI models in different disciplines
  (for example, systems and software engineering).
• This module describes characteristics shared by
  all CMMI staged-representation models, regardless
  of discipline.

77
Overview of CMMI Model

• Objectives
• appreciate the context of CMMI models
• know key terms used in the CMMI staged
  representation
• know the overall structure of the CMMI staged
  representation

78
CMMs

• The first CMM (CMM V1.0) was developed for
  software.
• Based on this success, CMMs were developed for
  the disciplines
• Systems engineering
• People
• Integrated product development
• Software acquisition
• others

79
Eexperiences

• Many organizations found several of these models
  to be useful.
• They also found
• Overlap
• Contradiction
• Lack of clean interfaces
• Lack of standardization
• Different levels of detail
• This resulted in additional expense to process
  improvement programs.

80
Move to Integration - 1

• The CMM Integration Project was formed to
• Build an initial set of integrated models
• Software engineering
• Systems engineering
• Integrated product and process development (IPPD)
• Establish a framework to integrate future models
• Create an integrated set of associated assessment
  and training products

81
Move to Integration - 2

• Source models serving as a basis
• CMM (software) V2.0 Draft C
• EIA 731 (systems engineering)
• IPD CMM (IPD) V0.9a

82
The CMMIProduct Development Team

• Membership from
• Industry
• U.S. government
• Software Engineering Institute
• Highly experienced
• Average of 21 years experience
• From organizations with solid process improvement
  credentials
• Diverse backgrounds represented

83
The CMMI Product Suite

• A framework for generating Integrated products
• Reference models
• Training products
• Assessment methods
• to support product and process improvement
• These products share
• Common terminology
• Common components

84
CMMI Models

• Initial areas of focus (disciplines)
• Systems engineering
• Software engineering
• Systems software engineering
• Systems software engineering integrated
  product and process development (IPPD)
• Representations
• Staged
• Continuous