evolutionary differences between cmm for software and the cmmi · india sepg 2001 cmm to cmmi...

India SEPG 2001CMM to CMMI Evolution

Evolutionary DifferencesEvolutionary DifferencesBetween CMM for SoftwareBetween CMM for Software

and the CMMIand the CMMI

CMM to CMMI Evolution - 2version KI Special© 2001 Kasse Initiatives, LLC

WelcomeWelcome

Wilkommen

Bienvenido

WelKom

Bienvenue

BienvenutoVälkommen

TervetuloaWitamy

Huan Yín

? ? ? ? S ? ??S? ? ?



Adapting anAdapting anAn IntegratedAn Integrated

ApproachApproach


Why an IntegratedWhy an IntegratedApproach?Approach?

u Software Engineering is not considered anengineering discipline throughout the worldwhen compared to electrical engineering,mechanical engineering, and civil engineering

u Software Engineering’s brief history has beenfilled with problems:³Cost overruns³Schedule slippage³Poor performance compared to specification³Unsatisfied customers



Why an IntegratedWhy an IntegratedApproach? - 2Approach? - 2

u Software is becoming such a large factor in thesystems that are being built today that it isvirtually impossible to logically separate the twodisciplines

u Demands for software-intensive systems havebeen growing steadily in the government andcommercial marketplaces

u Some organizations have developed “productlifecycles” that include systems, software,hardware, marketing, manufacturing, etc.

³Motorola Microsystems - 1985


Why an IntegratedWhy an IntegratedApproach? - 4Approach? - 4

u AT&T realized an increase in productivity andproduct quality by creating integrated teamsthat forced marketing, systems, software, andhardware representatives to work together andbe accountable as a team for the delivery of theproduct – 1990

u Integrating Systems and Software engineeringactivities enabled Ford Aerospace to regain itscompetitive position in the command andcontrol market place and reach CMM Level 3 atthe same time – 1989 - 1992



The CMMThe CMMExplosionExplosion


The CMM ExplosionThe CMM Explosion

u The first CMM (CMM v1.0) was developed forsoftware and released in August 1990

u Based on this success and the demand fromother interests CMMs were developed for otherdisciplines and functions³Systems Engineering³People³Integrated Product Development³Software Acquisition³Software Quality Assurance³Measurement³Others…….



The CMM Explosion - 2The CMM Explosion - 2

u While organizations found these various CMMsto be useful they also found them to be:³Overlapping³Contradicting³Lacking clean, understandable interfaces³Lacking standardization³Displaying different levels of detail

u In addition, many organizations also had todeal with ISO 9001 Audits or TickIT auditsbased on ISO 9000-3

u This resulted in expensive, confusing andconflicting process improvement programs


The CMMIThe CMMIProjectProject



The CMMI ProjectThe CMMI Project

u The CMM Integration Project was formed to:³Establish a framework to integrate current and

future models³Build an initial set of integrated models

u The source models that served as the basis forthe CMMI include:³CMM for Software v2.0 Draft C³EIA – 731 Systems Engineering³IPD CMM (IPD) v0.98a


CMMI OverviewCMMI Overview

Process is unpredictable,poorly controlled, and reactive

Process is characterized for projects and is oftenreactive

Process is characterizedfor the organization andis proactive

Process is measuredand controlled

Focus is on quantitativecontinuous processimprovement

Level Process Characteristics

Requirements ManagementProject Planning

Product and Process Quality Assurance

Configuration Management

Project Monitoring and ControlSupplier Agreement Management

Quantitative Project ManagementOrganizational Process Performance

Causal Analysis and ResolutionOrganizational Innovation and Deployment

Process Areas

Requirements Development Technical Solution

Product IntegrationValidation

Verification Organizational Process FocusIntegrated Project Management

Initial

Managed

Defined

Quantitatively Managed

Optimizing

Measurement and Analysis

Organization Process DefinitionOrganizational TrainingRisk ManagementDecision Analysis & Resolution



The Evolution ofThe Evolution ofCMM intoCMM into

CMMICMMI


RequirementsRequirementsManagementManagement

u Bi-Directional Traceability is now explicitlyasked for in Requirements Management³Hard to determine if the delivered product matches

the requirements and approved requirementschange requests and nothing more withoutrequirements traceability³Always been necessary but not clearly demanded

u Requirements Management is expected tooperate in parallel with RequirementsDevelopment and offer support as newrequirements are discovered and requirementschange requests are made



RD

RM

The Requirements ManagementThe Requirements Managementand Requirements Developmentand Requirements DevelopmentPartnershipPartnership


RequirementsRequirementsManagement - 2Management - 2

u Requirements cannot be managed effectivelywithout bi-directional requirements traceability

u A requirement is traceable if:³You know the source of each requirement³Why the requirement exists³What requirements are related to it³How that requirement relates to other information

such as systems designs, implementations, anduser documentation

u Traceability information is used to find otherrequirements which might be affected byproposed changes



Project PlanningProject Planning

u There is a heavier emphasis on having adetailed Work Breakdown Structure

u Includes a focus on the project having thenecessary Knowledge and Skills to execute theproject according to the estimations and plan

u Data Management or the planning andmaintaining of project data items and theircontents has been added to the list of projectmanagement concerns


Data ManagementData Management

u Requires administrative control of project data,both deliverable and non-deliverable³Some large, critical projects demand that even

Engineering Notebooks with daily entries be placedunder control for audit purposes³Covers all other forms of data such as CD-ROMs,

Disks, Notebooks, etc³Part of Project Planning process area



Project Planning - 2Project Planning - 2

u Estimation focuses on size and complexitywhile effort and cost, and schedule aredetermined and established respectively basedon the size estimation

u Estimate size and/or relative difficulty orcomplexity

u Determine the project effort and cost based onthe size and complexity estimations

u Establish and maintain the project schedulebased on the size and complexity estimations



u The identification and involvement of stakeholders isan important evolution of the “all affected groups”statement that appeared frequently in the SWCMM

u The required plan for stakeholder interaction includes:

³List of all relevant stakeholders

³Rationale for stakeholder involvement

³Expected roles and responsibilities

³Relationships between stakeholders

³Relative importance of stakeholder to project success byphase

³Resources needed to ensure relevant stakeholder interaction

³Schedule for phasing of stakeholder interaction




u The commitment process is now explicitlydefined in Specific Practice 3.3


Project Monitoring andProject Monitoring andControlControl

u Monitoring Commitments has also beenelevated to specific practice level - (SP 1.2)

u Monitoring Risks and Stakeholder Involvementis also more strongly emphasized in the CMMIcompared to the SWCMM

u Monitoring Stakeholder Involvement is explicitlybrought out and enables the Generic Practice2.6 – Identify and Involve RelevantStakeholders



Process and ProductProcess and ProductQuality AssuranceQuality Assurance

u Stresses the objective evaluation of productsas well as processes!!

u Evaluation criteria must be established basedon business objectives³What will be evaluated?³When or how often will a process be evaluated?³How will the evaluation be conducted?³Who must be involved in the evaluation?


ConfigurationConfigurationManagementManagement

u The idea of “Software Library” has beenreplaced by the more encompassing“Configuration Management System”

u A configuration management systemincludes:³The storage media

³The procedures

³The tools for accessing the configuration system



Supplier AgreementSupplier AgreementManagementManagement

u Replaces the initial ideas found in SubcontractManagement

u Now incorporates the original intent ofSubcontract Management as well as lessonslearned over the past 7 years ☺


Supplier AgreementSupplier AgreementManagement - 2Management - 2

Project

SisterDivisions

Other Projectsin Business

Unit

Off-the-ShelfProducts

Subcontractors

Contractors



Measurement andMeasurement andAnalysisAnalysis

u Provides a description of a measurementinitiative that involves the following:³Specifying the objectives of measurement and

analysis such that they are aligned with establishedinformation needs and business objectives

³Defining the measures to be used, the datacollection process, the storage mechanisms, theanalysis processes, the reporting processes, andthe feedback processes³Implementing the collection, storage, analysis, and

presentation of the data³Providing objective results that can be used in

making business judgments and taking appropriatecorrective actions


Measurement andMeasurement andAnalysis - 2Analysis - 2

u An organization that barely passes theMeasurement and Analysis Common Featurerequirements of CMM for Software would notpass the measurement requirements of CMMI

u Sets up the organization to evolve itsmeasurement program from basic projectmanagement measures to those based on theorganization’s set of standard processes tostatistical control of selected subprocessesaccording to the organization’s business needs



RequirementsRequirementsDevelopmentDevelopment

u The concepts presented in RequirementsDevelopment are consistent with very modernpublications on Requirements Engineering

u Clearly defines the need for identification andcare of stakeholders

u Incorporates the interface ideas of SystemsEngineering and Software Engineering withregards to gathering, analyzing, documenting,and maintaining requirements found in CMMfor Software v1.1 and expands on them


RequirementsRequirementsDevelopment -2Development -2

u Requirements Development together with TechnicalSolution truly shows the recursive and iterative natureof developing requirements:

Stakeholder Needs

Customer Requirements

Product and ProductComponent Requirements

Requirements Analysis

Derived Requirements

Allocation to ProductFunctions and ProductComponents includingObjects, People,and associated Processesor People



RequirementsRequirementsDevelopment - 3Development - 3

u The Requirements Development PA includes adescription of developing an operationalconcept and operational scenarios to refineand discover new requirements, needs, andconstraints that include the interaction of theproduct, the end user and the environment

u It also includes a strong focus on interfacerequirements

u It suggests the use of models, simulations, andprototyping to perform risk assessments toreduce the cost and risk of productdevelopment

u It is very tightly coupled to the TechnicalSolution process area


RequirementsRequirementsDevelopment - 4Development - 4

u It emphasizes the idea of starting the processof requirements validation very early in theproduct lifecycle



Spiral Model of theSpiral Model of theProduct RequirementsProduct RequirementsEngineering ProcessEngineering Process

START

Requirements elicitation

Requirements validationRequirements documentation

Requirements analysisand negotiation

Agreedrequirements

Draft Requirementsdocument

Requirementsdocument and

validation report

Informal statement ofrequirements

Decision point:accept documentor re-enter spiral

Gerald Kotonya and Ian Sommerville, Requirements Engineering, John Wiley and Sons, 1998


Technical SolutionTechnical Solution

u Technical Solution practices apply not only tothe product and product components but alsoto services and product-related processes

u Technical Solutions are presented as beingdeveloped interactively with product orproduct component requirements definition

u Technical Solution stresses the need fordeveloping alternative solutions



Technical Solution - 2Technical Solution - 2((Engineer in Quality)Engineer in Quality)

u To engineer in quality means to add quality tosoftware during the engineering process

u To achieve this, software engineers must beaware of quality requirements at the same timethey are building the functional requirements

u Quality requirements thus take on the samerelationship to the product as functionalrequirements do

u If we engineer quality in, we add quality to theproduct as we build it


Technical Solution - 3Technical Solution - 3

u Quality Factors (e.g., maintainability,expandability, reliability) were discussed in theCMM/SW Level 4 KPA Software QualityManagement – “Quality goals for the project’ssoftware products are defined, monitored, andrevised throughout the software lifecycle”

u CMMI discusses the quality factors first inRequirements Development and emphasizestheir importance in Technical Solution



Technical Solution - 4Technical Solution - 4

u Design criteria are often established to ensurethat the product or product component exhibitsone or more of the following quality attributes:³Modularity³ Clarity³Maintainability³ Expandability³ Portability³ Efficiency³ Reliability³ Security³ Usability³ Scalability


Product IntegrationProduct Integration

u Product Integration presents the concepts toachieve complete product integration throughprogressive assembly of product components,in one stage or in incremental stages,according to a defined integration strategy

u It stresses the careful analysis and selection ofthe optimum integration strategy³The basis for effective product integration is an

integration strategy that uses combinations oftechniques in an incremental manner



Product Integration - 2Product Integration - 2

u It points out the need to establish and maintainthe environment required to support theintegration of the product components

u It introduces the concept of product componentand product assembly Checkout, to evaluateits performance and suitability

u It presents the idea of applying (ProductIntegration, Verification, and Validation) insuccessive triplets until the product is ready forpackaging and delivery


Product Integration - 3Product Integration - 3

u It stresses the effective management of allinterfaces to ensure that all interfaces will becomplete and compatible³Interface descriptions

³Interface data

u Packaging and Delivery is specifically calledout in Specific Practice 3.4 – an improvementover the information provided in the SWCMM

u Inspecting Product Elements Upon Receipt isan activity that is not well done in the industrytoday and deserves the attention that is nowdefined in the CMMI!



VerificationVerification

u Verification is used to assure that selectedwork products meet their specifiedrequirements

u Verification assures “You built it right”

u Expects a verification strategy that addressesthe specific actions, resources, andenvironments that will be required for workproduct verification to be developed³Developed concurrently and iteratively with the

product and product component designs


Verification - 2Verification - 2

uCaptures the ideas of using:³Peer Reviews³Load, stress and performance testing³Functional decomposition based testing³Simulation³Prototypes³Observations and demonstrations³Operational scenario testing

as they apply to ensuring that the requirementsare being addressed at each phase of thedevelopment lifecycle from a systems, andsoftware point of view



ValidationValidation

u Validation is used to demonstrate that aproduct or product component fulfills itsintended use when placed in its intendedoperational environment

u Validation assures “You built the right thing”


Risk ManagementRisk Management

u The concepts inherent to Risk Managementfinally made it to Process Area status³Risk Identification³Risk Assessment³Risk Analysis³Risk Prioritization³Risk Mitigation³Risk Contingency Planning

u The ideas behind Risk Contingency Planningand Risk Mitigation have been merged but aredefinitely clearer



Decision and AnalysisDecision and Analysis

u Decision and Analysis presents the concepts ofidentifying alternatives to issues that have asignificant impact on meeting objectives,analyzing the alternatives, and selecting oneor more alternatives that best supportprescribed objectives

u Decision and Analysis is a new concept for thesoftware world whose time has certainly come


Criteria for UsingCriteria for UsingFormal DecisionFormal DecisionAnalysis TechniquesAnalysis Techniques

u Decision and Analysis helps determine which issuesshould be examined by formal decision analysis –typical criteria for when to require formal decisionmaking includes:³When a decision is directly related to topics assessed as

being of medium or high risk

³When a decision is related to changing work productsunder configuration management

³When a decision would cause schedule delays over acertain percentage or specific amount of time

³When a decision has an impact on the ability to achieveproject objectives

³When a decision’s costs are reasonable compared to thedecision’s impact



Assistance fromAssistance fromOperations ResearchOperations Research

u Understanding decision making models fromOperations Research can help in making fulluse of this Process Area³Linear Optimization Models Simplex Method for executive decision making

³Stochastic Programming Models³Dynamic Optimization Models³Unbounded Horizon Models³Queuing Decision Models


Organizational ProcessOrganizational ProcessDefinitionDefinition

u The wording for this process area has changedsubtly but significantly from that of the SWCMM³Establish and maintain a usable set of

organizational process assets including theorganization’s set of standard processes³Acknowledges that an organization may utilize more

than one standard process to handle its productlines and business needs

u Process Database evolved into OrganizationalMeasurement Repository



Integrated ProjectIntegrated ProjectManagementManagement

u Integrated Project Management takes on the aspects ofIntegrated Software Management and IntergroupCoordination that were found in the SWCMM³ The project is conducted using a defined process that is tailored

from the organization's set of standard processes

u It also emphasizes the need to proactively integrate theconcepts in the Project Plan and all supporting planssuch as:³Quality assurance plans³Configuration management plans³Risk management strategy³ Verification strategy³ Validation strategy³ Product integration plans


Organizational ProcessOrganizational ProcessPerformancePerformance

u The Organizational Process Performanceprocess area was developed to helporganizations set the stage for quantitativeprocess management:³Baselines and models that characterize

the expected process performance of theorganization's set of standard processes areestablished and maintained



Performance BaselinesPerformance Baselines

u The organization’s process performancebaselines measure performance for theorganization’s set of standard processes atvarious levels including:³Individual processes (e.g., test case inspection

element)

³Sequence of connected processes

³Processes for the complete lifecycle

³Processes for developing individual work products


PerformancePerformanceBaselines - 2Baselines - 2

u There may be several process performancebaselines to characterize performance forsubgroups of the organization – Examplesinclude:³Product Line

³Application domain

³Complexity

³Team size

³Work product size



Quantitative ProjectQuantitative ProjectManagementManagement

u This Process Area combines the concepts ofQuantitative Process Management andSoftware Quality Management from theSWCMM point of view

u The concepts of quantitative management andstatistical process control are strongly presentin this process area.

u Quantitative Project Management is tightlycoupled with Organizational ProcessPerformance, taking standard processmeasures from it to achieve stability ofsubprocesses and providing information backto it once the statistical control boundaries areestablished


QuantitativeQuantitativeManagement ConceptsManagement Concepts

u Quantitative Management is tied to theorganization’s strategic goals for productquality, service quality, and processperformance

u When higher degrees of quality andperformance are demanded, the organizationand projects must determine if they have theability to improve the necessary processes tosatisfy the increased demands



QuantitativeQuantitativeManagementManagementConcepts - 2Concepts - 2

u Achieving the necessary quality and processperformance objectives requires stabilizing theprocesses that contribute most to theachievement of the objectives

u Assuming the technical requirements can bemet, the next decision is to determine if it iscost effective



u Reducing process variation is an importantaspect to quantitative management:³It is important to focus on subprocesses that can be

controlled to achieve a predictable performance

u Statistical process control is often betterfocused on organizational areas such asProduct Lines where there is high similarity ofprocesses, than on the organization’s entire setof products




u Successful application of QuantitativeManagement concepts must look closely to:³The business demands³The capability of existing processes³The ability of the organization to bring processes

and subprocesses under statistical control in a costeffective manner


Quantitative ProjectQuantitative ProjectManagement ConceptsManagement ConceptsReferencesReferences

u Two sources that can help to really understandwhat is behind this Process Area are:³Measuring the Software Process by William Florac

and Anita Carleton.

³Statistical Methods for Software Quality by AdrianBurr and Mal Owen

³Understanding Variation by Donald Wheeler



OrganizationalOrganizationalInnovation andInnovation andDeploymentDeployment

u Combined Process Change Management andTechnology Change Management from theSWCMM point of view

u Just Do It! – Or once one has the innovationideas identified and analyzed against theorganization’s business objectives and costmeasures, get it tried and expanded whereverpossible throughout the organization

u Subpractices are excellent and provide a solidpicture of what is required for this process area


OrganizationalOrganizationalInnovation andInnovation andDeployment OverviewDeployment Overview

u The Organizational Innovation and Deploymentprocess area selects and deploysimprovements that can improve theorganization’s ability to meet its quality andprocess performance objectives

u Quality and process performance objectivesthat this process area might address include:³Improved product quality³Increased productivity³Decreased developed cycle time³Greater customer and end user satisfaction



OrganizationalOrganizationalInnovation andInnovation andDeployment Overview - 2Deployment Overview - 2

u Process and technology improvements that willbe deployed are selected from proposalsbased on the following criteria:³A quantitative understanding of the organization’s

current quality and process performance

³Estimates of the improvement resulting from thedeployment

³The resources and funding available for thatdeployment

³The expected benefits weighed against the cost andimpact to the organization


ConstageduousConstageduousViewpointViewpoint



ConstageduousConstageduousViewpointViewpoint

u CMMI Framework provides the opportunity toapply the principles of both the staged andcontinuous representations in a processimprovement oriented manner or a manner thatmight be labeled “Constageduous”


ConstageduousConstageduousViewpoint - 2Viewpoint - 2

Req

uir

emen

ts E

ng

inee

rin

g

Pro

ject

Pla

nn

ing

Mo

nit

or-

Co

ntr

ol

Qu

alit

y A

ssu

ran

ce

Co

nfi

gu

rati

on

Mg

mt

Ver

ific

atio

nR

evie

w c

ult

ure

çç W

alkt

hro

ug

h çç

PR

Val

idat

ion

Mea

sure

men

t an

d A

nal

ysis

Su

pp

lier

Ag

reem

ent

Man

agem

ent

Ris

k M

anag

emen

t



The Standard BarThe Standard BarHas Been RaisedHas Been Raised

Old StandardHeight

New StandardHeight

The Standard Bar has been raised – Lessonslearned over the past 7 years have now beenincorporated into this integrated CMM

Lessons Learned


Tim KasseTim KasseKasse Initiatives LLCKasse Initiatives LLC

30 West Sheffield Avenue30 West Sheffield AvenueGilbert, Arizona 85233Gilbert, Arizona 85233

U.S.A.U.S.A.Tel: +1 480 855 1101Tel: +1 480 855 1101

E-mail: E-mail: kassetckassetc@@aolaol.com.com

Web Site: www.Web Site: www.kasseinitiativeskasseinitiatives.com.com

evolutionary differences between cmm for software and the cmmi · india sepg 2001 cmm to cmmi...

Documents