US Export Regulations, ITAR and CMMI How to turn a Requirement into a Competitive Advantage

1
US Export Regulations, ITAR and CMMI How to
turn a Requirement into a Competitive Advantage
Danish-American Business Forum And FAD November
2008
Tim Kasse Kasse Initiatives LLC1 972 - 987 -
7706 USA 45 72 19 42 18 Europe
2
Welcome
????
WelKom
Huan Yín
Bienvenido
Bienvenue
Wilkommen
????S ???S???
Bienvenuto
Välkommen
Witamy
Tervetuloa
3
Agenda

• The Quality Premise (7)
• Engineering Competency
• Focusing on Quality Management and Process
  Improvement
• The Commitment to Quality and Process Improvement
• Process Management Context and Concepts

4
Agenda - 2

• Business Objectives Leading the Improvement
  Process (29)
• Supporting Senior Managements Vision
• Supporting the Organizations Business Objectives
• Supporting the Organizations Measurement
  Objectives
• Supporting Project Managers to Manage and Control
  Better

5
Agenda - 3

• CMMI as a Standard for Professionalism (41)
• Process Improvement Concepts
• Characteristics of Maturity
• Multiple Views of the CMMI (Look and Feel of the
  CMMI)
• In-Depth View at a Few Select Process Areas
• Why Base Your Organizations Process Improvement
  Success on the CMMI?
• CMMI Framework
• Constellations (CMMI-ACQ CMMI-SVC)
• A Final Illustration (Agile vs. Plan-driven
  Development)

6
Agenda - 4

• And Now to turn your Requirements into a
  Competitive Advantage (135)
• Process Improvement Model
• Support For A Process Improvement Initiative
• Summary
• Improvement is Not Easy Help is Available

7
The Quality Premise
8
Engineering Competency

• Inability to manage the engineering processes
• Lack of engineering discipline - cited by
  managers at all levels
• Quality functions are not well understood and
  poorly implemented throughout the lifecycle
• Quality Assurance vs. Quality Control
• Configuration Status Accounting
• Configuration Auditing
• Unit Testing
• Peer Reviews (Inspections and Structured
  Walkthroughs)
• Setting Quality Goals for the Project
• Needed use of Standards

9
Engineering Competency - 2

• Measurement programs are implemented late and
  poorly oriented
• Project measurement objectives not connected to
  organizations measurement objectives
• Focus on number of counts such as number or
  requirements or number of defects but
  segmentation of data for trend analysis and
  process improvement is rare
• Efficiency and effectiveness measurements are
  rarely implemented
• People are most often hired to satisfy a
  particular project need
• Not based on understanding of core competencies
  needed to support business objectives
• People are hired without an acceptable percentage
  of core competency skills
• People not hired for their learning ability

10
Focusing onQuality Management and Process
Improvement
11
Focusing on Process Improvement Quality
Management?

• Establish a common understanding of the
  customers requirements between the customer and
  the project
• Establish reasonable plans for performing the
  life-cycle activities and for managing the
  project
• Provide adequate visibility into the actual
  progress so that management can take effective
  actions when the projects performance deviates
  significantly from the projects plans

12
Focusing on Process Improvement Quality
Management? - 2

• Provide Management with adequate visibility into
  the processes being used by the project and of
  resulting quality of the products being built
• Select and manage qualified suppliers leading to
  collaborators and partners
• Develop the skills and knowledge of the
  individuals so they can perform their roles
  effectively and efficiently

13
Additional Benefits
14
Additional Benefits of Focusing on Process
Improvement

• Increased control of costs and ability to predict
  development cycle length and costs
• Ability to remove defects early and efficiently
  from the life-cycle work products
• Reduced rework leading to reduced development
  cycle time
• Increased predictability and control of product
  quality
• Enhanced ability to make cost-benefit tradeoffs
  of development methodologies, technologies, and
  processes

15
Additional Benefits of Focusing on Process
Improvement - 2

• Enhanced ability to make risk management
  decisions based on quantitative data
• More time available for top people to spend on
  problems requiring creative energy
• Knowledge retention and expansion
• Satisfied Customers

16
The Commitment to Quality and Process Improvement
17
The Commitment to Quality and Process Improvement
Starts With Top Management

• General Douglas McArthur, Supreme Commander of
  the Allied Powers in Japan after World War II is
  credited for the start of the focus on true
  quality But he did it by accident
• MacArthur wanted a large number of highly
  reliable radios manufactured fast, at a
  reasonable cost in order to put one in every
  Japanese home to broadcast American propaganda
• The Japanese manufacturing companies could not do
  it
• Called Census Bureau in United States Wanted
  Walter A. Shewhart man who developed the theory
  of statistical control of quality
• He brought the best in statistical quality
  control to Japan to teach the Japanese top
  management to focus first on quality
• Homer M. Sarasohn
• Charles W. Protzman
• Dr. W. Edwards Deming (Former Graduate Student
  recommended by Dr. Walther Shewhart)

18
The Commitment to Quality and Process Improvement
Starts With Top Management - 2

• Total Quality Management Axiom
• Shewhart (Control Charts Plan-Do-Check-Act)
• Deming (Demings 14 Points) Japan)
• Juran (Pareto Principle - Performance through
  Quality Leadership Voice of the Customer)
• Crosby (ITT Basis for CMM 5-Level Model)
• Feigenbaum (GE Total Quality Control)
• Sarasohn Protzman (Taught Statistical Quality
  Control to Japanese manufacturers)
• Ishikawa (Fish Bone Diagrams)
• Taguchi (Loss Function)

19
Process Management Context and Concepts
20
Key Concepts Upon Which the CMM/CMMI Is Based
Capability Maturity Model Integration (CMMI) v1.1
Quality Management 1940s to
Walter Shewhart
Process Architecture 1985 RonRadice
1990s - Deming, Juran, Crosby
ISO 15504 (SPICe)
Statistical Quality Control 1930s
Scientific Management 1880s
Fredrick Taylor (1856 - 1915)
Scientific Method

1900 1910 1920 1930 1940 1950 1960 1970
1980 1990 2000 2008
B.C. thru 1870s
Democratic Values
Capability Maturity Model 1990s to present
Humphrey, Paulk, Curtis, Weber, et al
Software Development 1960s to
Change Management Concepts 1920s
present - Dijkstra, Knuth, Royce,
Capability Maturity Model Integration (CMMI) v1.2
Mills, Fagan, Yourdon, Boehm
Kurt Lewin (1890 - 1947)
21
Scientific Method

• Purpose - What do you want to find out?
• Hypothesis - What do you think will happen?
• Materials - What do you need to use?
• Procedures - What will you do to find out?
  (Process)
• Observations - What happened? (gathering data)
• Conclusions - What did you learn?

Contributions include Data based, process
defined, repeatable, lessons learned captured for
future use, build on previous results
22
Democratic Values

• Individuals have rights
• Individuals cooperate most effectively when their
  mutual consent and benefit is involved, not when
  coerced or threatened
• Everyone can contribute ideas to solve common
  problems

23
Scientific Management

• Theory of management promoted by Fredrick Taylor,
  from the 1880s thru 1915
• Science, not rule of thumb
• Harmony, not discord
• Cooperation, not individualism
• Maximum output, not restricted output
• Development of each person to his/her greatest
  efficiency and prosperity
• Simplify and optimize tasks
• Taylor was an authoritarian and expert mode
  consultant whose methods were later abused

24
Change Management Concepts

• Kurt Lewin was an experimental social
  psychologist - action research
• Lewin wed scientific thinking to democratic
  values and gave birth to participative
  management.
• . . . diagnosis does not mean just finding the
  problem, but doing it in such a way as to build
  commitment for action.
• . . . we are likely to modify our own behavior
  when we participate in problem analysis and
  solution and likely to carry out decisions we
  have helped make.

Quotes from Productive Workplaces by Marvin
Weisbord, 1987
25
Statistical Quality Control
26
Quality Management Concepts

• Participative statistical process control
• Quality first
• Process management
• Senior management involvement
• Management is responsible for the system
• Continuous improvement
• Plan, Do, Check, Act (PDCA)

27
Process Management Premise
The quality of an engineering system is governed
by the quality of the process used to develop
and maintain it or Greater maturity leads
to better capability which contributes to the
production of better systems
28
You Cannot Inspect Quality Into a Product

• You cannot inspect quality into a product.
  Quality comes from improvement of the process

29
Business Objectives Leading the Improvement
Process
30
Supporting Senior Managements Vision
31
Vision

• The purpose of the visionary questions is to make
  sure that the improvement program is aligned with
  senior managements vision
• Where does senior management think the
  organization will be in the next year, and in the
  next two to five years?
• What products will be in the mainstream?
• Who will the competitors be?
• Where will the collaborators or strategic
  alliance partners come from?
• From what industry will they come from?
• What technology changes are expected and/or will
  be required to support the vision?

32
Vision - 2

• What does the organizational structure have to be
  to support this vision?
• Who will the organizations suppliers be?
• What kind of organizational culture would you
  like to have to support this vision?
• What are the quality goals that are expected to
  be realized?
• How will a Process Improvement Initiative based
  on the CMMI and other related models and
  standards support this vision?
• What skills will your workforce need to support
  the vision?
• What skills will you as the Senior Management
  Team need to support the vision?

33
Supporting the Organizations Business
Objectives
34
Business Objectives

• For a focus on Process Improvement to be
  successful, it must be tied to the organizations
  business objectives
• What are the organizations highest priorities?
• What business consequences have resulted from
  weak or ineffective focus on quality management
  functions?
• What action is being taken to correct the cause?
• How can a focus on Process Improvement support
  the organizations business objectives

35
Business Objectives - 2

• Examples of Business Objectives
• Reduce time to market
• Reduce system errors that are discovered by
  customers
• Improve delivery time
• Increase quality of products
• Find and fix software defects once and only once
• Reduce project risks
• Gain control of suppliers
• Improve service delivery
• Improve service availability and capacity
• Shorten find to fix repair rate

36
The Bottom Line

• Process improvement should be done to help the
  businessnot for its own sake.

• In God we trust,
• all others bring data.
• - W. Edwards Deming

37
Supporting the Organizations Measurement
Objectives
38
Measurement Objectives

• An organizations measurement objectives might
  be
• Reduce time to delivery to a specified percentage
• Reduce total lifecycle costs of new products by a
  percentage
• Deliver specified functionality by a specified
  increased percentage
• Improve prior levels of quality by reducing the
  number of defects of type A that get shipped with
  the product
• Improve prior customer satisfaction ratings by a
  specified percentage compared to past ratings

39
Supporting Project Managers to Manage and
Control Better
40
Process Improvement What Value to Project
Managers?

• What measurable value will the process
  improvement initiative bring to the project
  managers who bear the line responsibility for
  product delivery?
• More accurate schedules?
• Higher productivity of developers?
• Better quality products?
• Traceable requirements?
• Controlled configuration items?
• Reviews focused on critical components?
• Better control of suppliers?
• Reduction in potential risks?

41
CMMI as a Standardfor Professionalism
42
Process Improvement Concepts
43
A Definition of Process

• Process can be defined as a set of activities,
  methods, practices, and transformations that
  people use to develop and maintain
  software/systems and the associated products
• (e.g., project plans, design documents,
  components, prototypes, code, test cases, user
  manuals, etc.)
• Process in its simplest form is a blending or
  transformation of inputs such as people,
  materials, equipment, methods, and environment
  into outcomes

44
Process in Perspective
PEOPLE
PROCESS
TECHNOLOGY
45
Business Process Perspective
CUSTOMER
Business Objectives
People
Quality Products and Services
Process
Architecture
Organization
Technology
46
Characteristics of Maturity
47
Characteristics of an Immature Process

• Ad hoc process improvised by practitioners and
  their management
• Not rigorously followed or enforced
• Highly dependent on current practitioners
• Product quality difficult to predict
• Likely cost and schedule problems due to
  ineffective estimating
• Product functionality and quality often
  compromised in order to meet schedule
• Use of new technology risky

48
Characteristics of a Mature Process

• Defined and documented
• Understood
• Being used
• Living
• Supported visibly by management
• Clear definition and understanding of roles and
  responsibilities throughout project and
  organization
• Well controlled - process fidelity is audited and
  enforced
• Consistent with the way work actually gets done
• Measured
• Supported by technology

49
Multiple Views of the CMMI
50
Quality Management Maturity Grid
51
IBM Software Process Grid
Traditional Awareness Knowledge Skill
Integrated 5 (lowest) 4 3 Wisdom
2 Management System 1
Maturity
Attributes
not defined or defined but used defined but
static defined and leading edge
and used inconsistently improving integrated
into Bus.

• Process
• Methodologies
• Adherence to practices
• Tools
• Change control
• Data gathering
• Communication and use of data
• Goal setting
• Quality focus
• Customer focus
• Technical awareness

From A programming process study by Ron Radice,
et al. in IBM Systems Journal Vol 24, No 2
52
A Maturity Framework

• Maturity Level Key actions required to advance to
  the next level
• Optimized
• Managed Automate process data collection, turn
  management focus from product to process
• Defined Process Measures, Process Database,
  Measurement support, Product Quality targets and
  assessment
• Repeatable Process Group, Process Architecture,
  Software Engineering methods and technologies
• Initial Project Management, Management Oversight,
  Product Assurance, Change Control

Summarized from Characterizing the Software
Process A Maturity Framework by Watts Humphrey,
SEI-87-TR-11
53
CMMI Organization of Process Areas
Quantitative Project Management
Integrated Teaming Concepts
54
CMMI-DEV Overview
55
Process Capability Prediction
56
Management Visibility by Maturity Level
57
Technology Implications of Process Maturity
58
People Implications of Process Maturity
59
Customer Satisfaction Impacts of Maturity
60
Measurement Implications of Process Maturity
61
Risk Implications of Process Maturity
62
In-Depth Look At a Few Select Process Areas
63
Supplier Agreement Management(SAM)
64
Supplier Management Overview
Open Source
Other Projects in Business Unit
Sister Divisions
Project
Off-the-Shelf Products
Contractors (Resource Hiring)
Collaboration To Partner
Reuse Components
Subcontractors
Outsourcing
65
Process ImprovementforSoftware,Hardware,
Systems,and Businessbased onCMMI
66
Why Base Your Organizations Process Improvement
Success on the CMMI?

• First and foremost the emphasis is on developing
  processes and changing cultures to show a
  measurable benefit for the organizations
  business objectives and vision
• Provides a framework from which to organize and
  prioritize management, engineering, people, and
  business activities
• Supports the coordination of multi-disciplined
  activities that may be required to successfully
  build a product
• Adds Engineering Systems Think back into
  building systems

67
Laws of Engineering Systems Thinking

• Systems Thinking is a discipline for seeing the
  whole
• In all of the projects phases/stages, and along
  the systems life, the systems engineer has to
  take into account
• The customers organization vision, goals, and
  tasks
• The customers requirements and preferences
• The problem to be solved by the system and the
  customers needs
• The whole has to be seen as well as the
  interaction between the systems elements
• Iterative or recursive thinking must replace the
  traditional linear thinking

68
Laws of Engineering Systems Thinking - 2

• The solution is not always an engineering one
  remember to always take into account
• Business and economic costs
• Reuse or utilization of products and
  infrastructure already developed
• Organizational, managerial, political, and
  personal considerations
• The end user must be considered as a major part
  of the system
• At each stage the human element must be
  considered

69
Why Base Your Organizations Process Improvement
Success on the CMMI? - 2

• Software / Hardware / Systems processes are often
  able to be adapted for other organizational
  departments such as Human Resources, Finance,
  Marketing, Computer Services and Contract
  Management
• Provides the basis for an organization to develop
  and control its own project management and
  engineering processes so that it can, in
  addition, manage the results of its suppliers
  processes
• Ensures identification and control of an
  organizations core competencies
• Enables an organization to competitively
  posture itself in todays fast changing world

70
Why Base Your Organizations Process Improvement
Success on the CMMI? - 3

• The CMMI v1.2 captures lessons learned from use
  of the CMM for Software, CMMI v1.1 and other
  standards and models over the past 15 years
• Requirements Development, Technical Solution,
  Requirements Management, Product Integration,
  Verification, and Validation
• Decision Analysis and Resolution
• Project Management and Integrated Project
  Management
• Supplier Agreement Management
• Measurement and Analysis
• Risk Management
• Integrated Product and Process Development
• Organizational Process Focus
• Organizational Process Definition

71
Why Base Your Organizations Process Improvement
Success on the CMMI? - 4

• The CMMI supports
• Systems Engineering
• Software Engineering
• Hardware Engineering
• Electrical Engineering
• Mechanical Engineering
• Optical Engineering
• Electro-Optical
• Electro-Magnetics
• Electro-Mechanical
• Hydraulics
• Manufacturing
• Glass Factories
• Embedded Systems
• Information Systems
• Information Technology
• Banks and Insurance Companies
• Medical Systems
• .

72
CMMI Framework
73
The CMMI Framework

• The CMMI Framework is the structure that
  organizes the components used in generating
  models, training materials, and appraisal
  methods.
• The CMMI Product Suite is the full collection of
  models, training materials, and appraisal methods
  generated from the CMMI Framework.
• A Constellation is the subset of the CMMI Product
  Suite relevant to improvement in a particular
  area of interest. Currently, there are three
  constellations
• Development
• Acquisition
• Services

74
Constellations
75
Constellations

• The components in the CMMI Framework are
  organized into groupings, called constellations,
  which facilitate construction of approved models.
• CMMI-DEV v1.2 serves as the basis for the CMMI
  for Development constellation.
• CMMI-ACQ v1.2 serves as the basis for the CMMI
  for Acquisition constellation
• CMMI-SVC v.9b is the current draft of the CMMI
  for Services constellation

76
Constellations 2
CMMI Constellation is a subset of the CMMI
Product Suite relevant to improvement in a
particular area of Interest (Development,
Acquisition, and Services)
77
CMMI-ACQ v1.2

• The purpose of CMMI for Acquisition is to extend
  the CMMI Framework to cover the acquisition of
  products and services
• A CMMI for Acquisition model will improve
  consistency and payoff for acquisition
  organizations because it will include acquisition
  practices that are useful, but not covered in the
  CMMI for Development models

78
CMMI-SVC v.9b

• The purpose of CMMI for Services is to extend the
  CMMI Framework to cover the provision of services
• A CMMI for Services model will improve
  consistency and value for service organizations
  because it will include service deployment
  practices that are not covered by the current
  CMMI model

79
What Is a Service?

• Products may be delivered in a variety of forms,
  including artifacts (e.g., hardware, software, or
  user documentation), services (e.g., training,
  maintenance, or operational support), and
  combinations of these.
• A service is a product that is intangible and
  non-storable.
• Inputs to CMMI-SVC include
• ITIL - Information Technology Infrastructure
  Library
• ISO/IEC 20000 Information Technology Service
  Management
• COBIT - Control Objects for Information and
  related Technology
• ITSCMM - Information Technology Services
  Capability Maturity Model

80
CMMI Framework Models

• The model portion of the CMMI Framework is
  composed of the following
• CMMI Model Foundation (CMF)
• Shared material
• Constellation-specific material
• The CMMI Model Foundation (CMF) provides an
  internally consistent set of core components that
  apply to every constellation or model.
• All CMMI models use the model foundation without
  deleting or changing any of its content

81
CMMI Framework Models -2

Model Portion of the CMMI Framework
Model Foundation
Shared CMMI Material
Development Specific Materials
Acquisition Specific Materials
Services Specific Materials
82
Core Process Areas -2
CMMI-SVC provides guidance for those providing
services within organizations and to external
customers
CMMI-DEV provides guidance for measuring,
monitoring, and managing development processes
16 Core Process Areas used in all
CMMI-ACQ provides guidance to enable informed and
decisive acquisition leadership
83
A Final IllustrationAgile vs. Plan-driven
Development
84
Agile Manifestofor Software Development
85
Manifesto for AgileSoftware 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

86
Requirements for Successful Agile Product
Development

• Agile methods universally need close
  relationships with the customer and users of the
  systems under development
• Requirements and Validation are dependent on the
  customers describing, prioritizing, and refining
  their needs throughout the development
• Very few customers can do that!
• The cycle of building functionality, obtaining
  feedback, and evolving the system based on that
  feedback is highly dependent on an informed and
  involved customer
• The customer establishes acceptance criteria and
  tests
• This is definitely the way it should be but.

87
Requirements for Successful Agile Product
Development - 2

• Agile methods require a critical mass of highly
  motivated knowledgeable team members
• Since documentation and design are kept to a
  minimum, the ability for team members to retain
  and act on tacit knowledge is crucial
• An Agile culture change is also required
• Pair programming requires practitioner comfort
  and acceptance of working closely with another
  developer and NOT thinking on their own
• It depends on management acceptance that two
  people working together can be more productive
  and adapt more rapidly than two working alone

88
Requirements for Successful Agile Product
Development - 3

• Agile approaches require continuous process and
  technical improvement
• This is often a GREAT challenge, since most
  information in agile approaches
• Is NOT documented
• Is maintained in the developers mental
  experience base
• Is more difficult to analyze systematically
• Is more difficult to share with the rest of the
  organization

89
Plan-Driven Methods
90
Based on Mainline Engineering Disciplines

• Plan-driven methods are based on concepts from
  the mainline engineering fields
• These methods approach development in a
  requirements/design/build paradigm with standard
  well-defined processes that organizations
  continuously improve

91
Genesis of Plan-Driven Approaches

• Plan-driven approaches are based on the systems
  engineering and quality disciplines
• Satellites, manned spacecraft, ballistic missiles
  and other space systems demanded the tenets of
  systems engineering to coordinate the large
  numbers of interoperating components, not
  necessarily produced by a single company or group
  of workers

92
Genesis of Plan-Driven Approaches - 2

• From individual military branch standards to
  DoD-STD-2167 to MIL-STD-498, the U.S Department
  of Defense issued many monolithic standards and
  procedures in an effort to reign in the chaos
  that it saw in companies that were delivering
  systems with software that did not meet
  requirements or work in the operational
  environment

93
Characteristics of Plan-Driven Methods

• Plan-driven methods are characterized by a
  systematic engineering approach to software
• Carefully adheres to specific processes in moving
  software through a series of representations from
  requirements to finished code
• There is a concern for completeness of
  documentation at every step of the way so that
  thorough verification of each representation may
  be accomplished after the fact

94
Characteristics of Plan-Driven Methods - 2

• The original tendency was to view the software
  development cycle as waterfall from the concept
  to the end product
• Win Royce developed the Waterfall model in 1972
  for Systems Engineering that included feedback
  loops at each step that was, in general ignored
  by the software community
• Today most software developers and software
  development companies are being directed to use
  incremental and evolutionary processes
• The mandate to document and maintain traceability
  across requirements, design, and code is still
  strong

95
Incremental Development Processes
Reuse Library (Data, Specs, Designs,
Methodologies, Tools)
Partition Plan and Define Repetition Sample
Business Models and Architecture
Block 5
Block 4
Block 3
High-Level FD/ORD (User Involved) Concept/Design
Systems Engineering Reuse Strategy Identify
COIC/CMF
Block 2
Needed Project (MNS) Development Strategy
Detailed Design (User Involved)
Block 1
Detailed Design (User Involved)
Accelerated Development (Code Generation)
Developer Testing
Executing Processes
User Review
OTE
Milestone IV
Milestone II
Milestone 0
Milestone I
Milestone III
96
EVOLUTIONARY MODEL 1ST Generation
97
EVOLUTIONARY MODEL 2nd Generation
98
Product Discipline Implies Process Definition and
Improvement

• The definition and management of processes is key
  to plan-driven methods
• Plan-driven methods are almost always associated
  with process improvement and organizational
  learning

99
Strengths of Plan-Driven Methods

• The strengths of plan-driven methods are in the
  comparability and repeatability that
  standardization brings
• How to perform specific processes and how to
  format specific work products is defined
• People are trained in the organizational
  processes allowing them to know where to look for
  information and how to go about estimating common
  work

100
Strengths of Plan-Driven Methods - 2

• The amount of information maintained about the
  processes at the organizational level means
• Managers can move personnel quickly between
  projects
• A loss of key personnel will not necessarily doom
  a project
• This is a characteristic of an organization that
  has achieved CMMI ML 3
• The CMMI is an example of a Plan-driven approach!

101
Requirements for Successful Plan-Driven Product
Development

• Plan-driven methods require
• Visible Management support in the use and
  improvement of the processes
• Organizational infrastructure
• An environment where practitioners understand the
  importance of common processes to their personal
  work and the success of the organization

102
Requirements for Successful Plan-Driven Product
Development - 2

• Processes must have the active support of the
  participants
• Practitioners must be well trained in both the
  practice and philosophy of the plan-driven
  approach
• Practitioners must accept that a certain amount
  of allegiance to the processes and measures is
  necessary to support
• Their ongoing project
• Future projects
• Other projects and individuals throughout the
  organization
• While creativity is always encouraged, individual
  creativity totally outside of the process
  definitions can lead to chaos and unnecessary
  rework

103
Recursive Nature of RequirementsDevelopment
104
CMMI Support of Agile

• Agile methods are often both iterative and
  concurrent
• Recursion of engineering PAs (e.g. RD, TS)
  supports iterative development
• Broader scope allows multiple disciplines and
  approaches for different components
• Agile for emerging or rapidly evolving components
• Plan-driven for well-understood or regulated
  components

Used with Permission of Richard Turner Using
CMMI to Balance Agile and Plan-driven Methods
Nov 2003
105
Customer, Product, and Product Component
Requirements
Operational Concepts Scenarios Are Applied to
Customer Requirements To Develop or Evolve the
Systems Requirements
Operational Concept Scenarios
Quality Assurance
End User
Marketing
Product and Product Component Requirements
Derived Requirements
Customer Requirements
Regulatory Agencies
(Stakeholder Requirements)
(Systems Requirements)
Customer
Independent Test
Definition of Functionality
Developers Management
(Functional Architecture)
Stakeholders
(Early Phase Requirements Validation)
106
Customer, Product, and Product Component
Requirements - 2
EE, ME, S/W, Optics, Hydraulics, Manufacturing
Product Requirements Allocated to Functions /
Disciplines
Quality Assurance
End User
Marketing
Services
Product and Product Component Requirements
Customer Requirements
Regulatory Agencies
(Stakeholder Requirements)
(Systems Requirements)
People
Customer
Independent Test
Developers Management
Processes
Stakeholders
(Early Phase Requirements Validation)
(Reallocation of Systems Requirements)
107
Spiral Model of the Product Requirements
Engineering Process
Informal statement of requirements
Decision point accept document or re-enter spiral
Requirements elicitation
Requirements analysis and negotiation
START
Requirements document and validation report
Agreed requirements
Requirements validation
Requirements documentation
Gerald Kotonya and Ian Sommerville, Requirements
Engineering, John Wiley and Sons, 1998
Draft Requirements document
108
And now to turn your Requirement into a
Competitive Advantage
109
Process Improvement Model
110
Process Improvement Model (PIM)
Appraisal of the Engineering Process
2
Commitment to Process Improvement
1
Infrastructure and Plans for Process
Improvement
3
Implementation of Process Improvements
4
111
Diagnostic
Strategy for PI Initiative
Progress Check
Assessment
Evaluation
Sponsorship
Define Staff SPI Infrastructure
Appraisal
Visioning/ Business Objectives
Train Improvement Staff
Identification of PI Staffing
Prioritize Improvement Effort
Expectation Setting
Commitment
Planning
Plan Improvement Process (Action Plan)
Investigation and Awareness Training
Implementation
Refine Piloted Processes as Necessary
Pilot New/ Revised Processes
Define New Processes OR
Propose Next Improvement Actions
Adopt New or Revised Processes for Project Needs
Institutionalize New/Revised Processes
Review/Revise Existing Processes
Evaluate Piloted Processes
112
Support For A Process Improvement Initiative
113
KI's Integrated Approach to Process Improvement
PMI
RUP
SCRUM
CMMI
SIX SIGMA
LEAN
ISO
SPICE
Assessment
AGILE
Action Planning (Incremental Approach)
ITIL
Training
Handholding Coaching Support for Methods and Tools
114
Summary

• The CMMI has evolved from contributions of
  engineers, managers, and social psychologists
  over the past 100 years
• The multiple views of the CMMI contribute to the
  picture that process improvement must concern
  itself with people, technology, measurement,
  risk, and customer satisfaction if an
  organizations business objectives are to be
  supported with the CMMI-based process improvement
  initiative

115
Summary - 2

• Many of the upgrades fought for in the CMM for
  Software over the past 15 years are resident in
  the CMMI
• The CMMI provides the Engineering Systems Think
  that the CMM for Software lacked
• The CMMI also demands more engineering discipline
  to be applied to product development
• There is a natural bridge from CMM to ISO
  90012000 to CMMI

116
Summary - 3

• Process improvement requires the cooperation of
  all levels of management and the practitioners
• Process improvement initiatives must support
  senior managements vision and the organizations
  business objectives
• Process improvement must show measurable business
  results not just satisfy a CMMI Model
• Process improvement means change in the
  organizations processes and culture

117
Improvement is Not Easy but..Help is Available
118
Tim Kasse

• CEO and Principal Consultant of Kasse Initiatives
• Visiting Scientist - Software Engineering
  Institute
• Visiting Fellow - Institute for Systems Science /
  National University of Singapore
• Author of Action Focused Assessment for Software
  Process Improvement
• Author of Practical Insight Into CMMI

119
Practical Insight Into CMMI 2nd Edition (Sept
2008)
120
Delta Axiom
121
Delta Axiom - 2