cmmi v1.3 and quality attributes - norauskypsi.comnorauskypsi.com/cmmi v1.3 and quality...

CMMI® V1.3 and Quality AttributesCMMI V1.3 and Quality Attributes

Society for Software QualitySociety for Software QualityFebruary 22, 2011

C bilit M t it M d l CMM CMM I t ti d CMMI i t d i th U S P t t d T d k Offi

Gary F. NorauskyCapability Maturity Model, CMM, CMM Integration, and CMMI are registered in the U.S. Patent and Trademark Office.

SCAMPI is service mark of Carnegie Mellon University.

© 2011 Norausky Process Solutions, Inc. All rights reserved.

AgendaModel ChangesArchitecture Centric FocusArchitecture Centric FocusQuality Attribute HighlightsConclusion


ObjectivesPresent a high level discussion of the changes in CMMI V1.3changes in CMMI V1.3Describe briefly the architecture-centric focus of CMMI V1 3focus of CMMI V1.3Discuss the “quality attribute” thread

P A i CMMI V1 3across Process Areas in CMMI V1.3

© 2011 Norausky Process Solutions, Inc.

All rights reserved.

Model Changesg


Modern Engineering ApproachesHow is CMMI V1.3 so different than previous versions?

Points to considerEngineering content of CMMI-DEV V1.2 is ten years oldProcess Areas (PAs) in previous versions rarely addressed:

– Quality attributesAll ti f d t biliti t l i t– Allocation of product capabilities to release increments

– Product lines– Technology maturation (and obsolescence)– Agile methodsAgile methods

Updated the glossary to include new terms (and modified some old terms), including quality attribute, architecture, and definition of required functionality and quality attributesUpdated the informative material in all three model to bring more balance to functional and quality attribute requirements (non-functional requirements)


Generic Practices ChangesCMMI v1.2GP1.1 Perform Specific PracticesGP2.1 Establish an Organizational Policy

CMMI v1.3GP1.1 Perform Specific PracticesGP2.1 Establish an Organizational Policyg y

GP2.2 Plan the ProcessGP2.3 Provide ResourcesGP2.4 Assign ResponsibilityGP2.5 Train PeopleGP2 6 Manage Configurations

g yGP2.2 Plan the ProcessGP2.3 Provide ResourcesGP2.4 Assign ResponsibilityGP2.5 Train PeopleGP2 6 C t l W k P d tGP2.6 Manage Configurations

GP2.7 Identify and Involve Relevant StakeholdersGP2.8 Monitor and Control the ProcessGP2.9 Objectively Evaluate AdherenceGP2.10 Review Status with Higher Level Management

GP2.6 Control Work ProductsGP2.7 Identify and Involve Relevant StakeholdersGP2.8 Monitor and Control the ProcessGP2.9 Objectively Evaluate AdherenceGP2.10 Review Status with Higher Level Management

GP3.1 Establish a Defined ProcessGP3.2 Collect Improvement Information

g gGP3.1 Establish a Defined ProcessGP3.2 Collect Process Related Experiences

GP4.1 Establish Quantitative Objectives for the ProcessGP4.1 Establish Quantitative Objectives for the ProcessGP4.2 Stabilize Subprocess PerformanceGP5.1 Ensure Continuous Process ImprovementGP5.2 Correct Root Causes of Problems

Eliminated



Process Area Changes

Causal Analysis and Resolution (CAR)Configuration Management (CM)Decision Analysis and Resolution (DAR)

Causal Analysis and Resolution (CAR)Configuration Management (CM)Decision Analysis and Resolution (DAR)

CMMI v1.2 CMMI v1.3

Decision Analysis and Resolution (DAR)Integrated Project Management +IPPD (IPM)+IPPD)Measurement and Analysis (MA)Organizational Innovation and Deployment (OID)Organizational Process Definition +IPPD (OPD)+IPPD)Organizational Process Focus (OPF)

Decision Analysis and Resolution (DAR)Integrated Project Management (IPM)Measurement and Analysis (MA)Organizational Performance Management (OPM)Organizational Process Definition (OPD)Organizational Process Focus (OPF)

New

g ( )Organizational Process Performance (OPP)Organizational Training (OT)Product Integration (PI)Project Monitoring and Control (PMC)Project Planning (PP)

g ( )Organizational Process Performance (OPP)Organizational Training (OT)Product Integration (PI)Project Monitoring and Control (PMC)Project Planning (PP)

Process and Product Quality Assurance (PPQA)Quantitative Project Management (QPM)Requirements Development (RD)Requirements Management (REQM)Risk Management (RSKM)S li A M (SAM)

Process and Product Quality Assurance (PPQA)Quantitative Project Management (QPM)Requirements Development (RD)Requirements Management (REQM)Risk Management (RSKM)S li A M (SAM)Supplier Agreement Management (SAM)

Technical Solution (TS)Validation (VAL)Verification (VER)

Supplier Agreement Management (SAM)Technical Solution (TS)Validation (VAL)Verification (VER)

Note: The Integrated Product and Process Development (IPPD) addition has been removed and in its place teaming practices were added



g p ( ) p g pthat are not optional.

CMMI-DEV PAs by Category

Project ManagementIntegrated Project Management (IPM)Project Monitoring and Control (PMC)

Process ManagementOrganizational Process Definition (OPD)Organizational Process Focus (OPF) Project Monitoring and Control (PMC)

Project Planning (PP)Quantitative Project Management (QPM)Requirements Management (REQM)Risk Management (RSKM)

Organizational Process Focus (OPF)Organizational Performance Management (OPM)Organizational Process Performance (OPP)Organizational Training (OT)

g ( )(+) Supplier Agreement Management (SAM)

EngineeringProduct Integration (PI)

SupportCausal Analysis and Resolution (CAR)Configuration Management (CM)Decision Analysis and Resolution (DAR) Product Integration (PI)

Requirements Development (RD)Technical Solution (TS)Validation (VAL)Verification (VER)

Measurement and Analysis (MA)Process and Product Quality Assurance (PPQA)

Verification (VER)

For the V1.3 release, REQM was moved from “Engineering” to “Project Management.”g g j g


CMMI V1.2 SunsettingSunset date for CMMI V1.2 is November 30, 2011Organizations may continue to use both the CMMI V1.2 model and SCAMPI A method for their appraisals until that time and those appraisals will be valid for three years from the appraisal datevalid for three years from the appraisal date

Between now and the V1.2 sunset date, organizations may use either V1.2 or V1.3 and either SCAMPI A MDD V1.2 or V1.3 – and in any combination:V1.3 and in any combination:

CMMI Model Appraisal MethodV1.2 SCAMPI A MDD V1.2V1.2 SCAMPI A MDD V1.3V1.3 SCAMPI A MDD V1.2V1 3 SCAMPI A MDD V1 3



V1.3 SCAMPI A MDD V1.3

CMMI V.3 Upgrade TrainingThe model upgrade training is available on-line

Appraisal Team Members (ATM) who will participate in the high maturity appraisals are required to take the V 3 model training (i e Introduction to CMMIthe V.3 model training (i.e., Introduction to CMMI V1.3) or the V1.3 upgrade training

V1.2 training is sufficient for those ATMs who will participate in appraisals seeking Maturity Level 2 and 3 ratings (i.e., V1.3 upgrade training is not required g ( , pg g qfor ATMs participating in Maturity Level 2 & Maturity Level 3 appraisals)



Architecture-Centric Focus


Architecture Is Important The quality and longevity of a software-reliant system is largely determined by its architecture

In recent studies by OSD, the National Research Council, NASA, and the NDIA, architectural issues

id tifi d t i f ftare identified as a systemic cause of software problems in DoD systems

Capability Maturity Model Integration (CMMI) V1.3 and Architecture-Centric Engineering Webinar 01192011 by

Dr. Lawrence G. Jones & Dr. Michael Konrad


What is Architecture-Centric Engineering?Engineering?

Architecture-Centric Engineering (ACE)is the discipline of using architecture as the focal point for performing ongoing analyses to gain increasing levels of confidence that systems will support their missionsKey PrinciplesKey Principles

Regardless of scale, architecture is the appropriate abstraction for reasoning about business/mission goal satisfactionQ lit tt ib t h d i t i fl t ’Quality attributes have a dominant influence on a system’s architectureArchitectural prescriptions must be demonstrably satisfied by th i l t tithe implementation

Capability Maturity Model Integration (CMMI) V1.3 and Architecture-Centric Engineering Webinar 01192011 by


Dr. Lawrence G. Jones & Dr. Michael Konrad

The Domain of Architecting

ArchitectureQ liti

The “what” The “why”System

FeaturesSatisfiesQualities

ArchitectureRepresentation

Features

Architecture S/WRequirements

System

ConstrainRepresentation

The “how”The “who”

SystemQuality Attributes

Produces DefinesTechnology

Process

The howThe who

ArchitectFollows

Organization

SkillsStakeholders

Defines role

Adapted from SkillsAdapted from Wojtek Kozaczynski


Different Points of ViewArchitecture faces towards strategy, structure and purpose, towards the abstract

Architecture is critical to the realization of many qualities of interest in a system, and these qualities should be designed in and can be evaluated at the architectural levelArchitecture, by itself, is unable to achieve qualities. It provides the foundation for achieving quality, but this foundation will be to no avail if attention is not paid to the detailsdetails

Design faces towards implementation and practice, towards the concrete


Many Views NeededArchitecture is many things to many different interested parties

End userEnd-userCustomerProject managerS stem engineerSystem engineerDeveloperArchitectM i t iMaintainer

Multidimensional realityMultiple stakeholdersp

Multiple views, multiple blueprints


Example of Quality Attribute Views

PerformanceA il biliAvailabilityUsabilitySecurity

End User’s view Time To MarketCost and BenefitsProjected life time B i

Maintainability

Projected life timeTargeted MarketIntegration with Legacy

System

BusinessCommunityview

yPortabilityReusabilityTestability

Developer’s view

SystemRoll back Schedule

y

ISO/IEC 9126-2001 Information Technology – Software Product Quality



Quality Attributes and ViewsQuality attributes have a dominant influence on a system’s architecture

Quality attribute requirements stem from business and mission goalsKey quality attributes need to be characterized inKey quality attributes need to be characterized in a system-specific wayScenarios are a powerful way to characterize quality attributes and represent stakeholder views


Quality Attribute ScenariosA quality attribute scenario is a quality-attribute-specific requirement. It consists of six parts.

Source of stimulus – the entity that generated the stimulusStimulus – a condition that needs to be considered when it arrives at a systemEnvironment – the particular conditions in which the stimulus occursArtifact – the system or the pieces of it that are stimulatedResponse – the activity undertaken after the arrival of the stimulusResponse measure – when the response is occurs, it should espo se easu e e t e espo se s occu s, t s ou dbe measurable in some fashion so that the requirement can be tested


Sample Availability Scenario

Stimulus:

Unanticipated

Artifact:

Process Response:

Inform Operator

Source:

p

Message

Environment:

p

Continue to

Operate

Response Measure:

External to

System

Normal

Operation

No Downtime

Sample availability scenario. An unanticipated external message is received by a process during normal operation. The process informs the operator of the receipt of the message and the system continues with no downtime.



Quality Attribute Roadmap

PrioritizedS i

Refined Scenarios

Tradeoff Alternati es

Design DecisionsScenarios Scenarios Alternatives Decisions

ScenarioGeneration

ScenarioAnalysis

Tradeoff and Risk

Identification

Decisions

Inputs: Architecture requirements, documentation, styles, stakeholders points of view, project constraintsTools: Quality attribute taxonomies, questions, scenarios



Quality Attribute HighlightsQ y g g


Key QuestionMeeting quality attribute requirements: Are they overhead expenses or valueAre they overhead expenses or value propositions?



Quality AttributeCMMI V1.3 Definition

A property of a product or service by which its quality will be p p y p y q yjudged by relevant stakeholders. Quality attributes are characterizable by some appropriate measure.Quality attributes are non-functional, such as timeliness, throughput, responsiveness, security, modifiability, reliability, and usability. They have a significant influence on the architecture.

This term is now included in the Glossary for the first time. This term is intended to supplant others –especially those focusing on only a few dimensions (e.g., “performance”) –to encourage a broader view of non-functional requirements. The term was refined through much effort, as neither ISO 25030 (SQuaRE) nor the original SEI definitions were quite satisfactory. In addition, uses of the term “performance” throughout the model were reviewed for clarity, and where appropriate, revised or qualified.



Adapted from CMMI V1.3 and Architecture-Centric Engineering ©2011 Carnegie Mellon University

Quality Attribute ReferencesCMMI V1.2

The phrase “quality attribute” occurs twoThe phrase quality attribute occurs two timesThe phrase “product attribute” occurs fourThe phrase product attribute occurs fourtimes

CMMI V1 3CMMI V1.3The phrase “quality attribute” occurs eighty-five timeseighty five timesThe phrase “product attribute” occurs threetimes


Quality Attribute Mapping

CMMI v1.2 onlyCMMI v1.2 & v1.3CMMIv1.3 only


Requirements ManagementPoint to consider:

Requirements are kept consistent with architectural approach and q alit attrib te prioritiesapproach and quality attribute priorities



Project PlanningPoint to consider:

The technical approach defines a top-level strategy for de elopment of the prod ct and incl des the f nctionalitdevelopment of the product and includes the functionality and quality attributes expected in the final products


Configuration ManagementPoint to consider:

Functional configuration audits (FCAs): Audits conducted to erif that the de elopment of a config ration item has beenverify that the development of a configuration item has been

completed satisfactorily, that the item has achieved the functional and quality attribute characteristics specified in the functional or allocated baseline and that its operational andfunctional or allocated baseline, and that its operational and support documents are complete and satisfactory


Requirements DevelopmentPoints to consider:

Establishment of the customer functional and quality attribute requirementsDefinition of the required functionality and quality attributesDefinition of the required functionality and quality attributesQuality attribute elicitation workshops with stakeholders

Establish and maintain a prioritization of customer functional and quality attribute requirementsD l hit t l i t t i iti l lit tt ib t dDevelop architectural requirements capturing critical quality attributes and quality attribute measures necessary for establishing the product architecture and design

Architecturally significant quality attributes are identified based on mission and b i d ibusiness drivers. Augment scenarios with quality attribute considerations for the functions (or other logical entities) described in the scenario.

Establish and maintain a definition of required functionality and lit tt ib t (SP 3 2) Thi i S ifi P ti d tquality attributes (SP 3.2). This is a Specific Practice and represents

expected behavior.Formulating architectural requirements that specify how product components are organized and designed to achieve particular end-to-end functional and quality attribute requirement



Technical SolutionPoints to consider:

Evaluating and selecting solutions (sometimes referred to as “design approaches ” “design concepts ” or “preliminary designs”)design approaches, design concepts, or preliminary designs ) that potentially satisfy an appropriate set of allocated functional and quality attribute requirementsAchievement of key quality attribute requirements, such as product y q y q , ptimeliness, safety, reliability, and maintainabilityEstablish the functional and quality attribute requirements associated with the selected set of alternatives as the set of

ll t d i t t th d t tallocated requirements to those product components.Selecting architectural patterns that support the functional and quality attribute requirements, and instantiating or composing those patterns to create the product architecturepatterns to create the product architecture



Product Integration Point to consider:

Criteria can be defined for how the product components are to be erified and the beha iors (f nctionalit and q alitto be verified and the behaviors (functionality and quality attributes) they are expected to have



Integrated Project ManagementPoint to consider:

The critical aspects of the project work environment are, like an other prod ct req irements dri en F nctionalit andany other product, requirements driven. Functionality and quality attributes of the work environment are explored with the same rigor as is done for any other product development projectproject

Note: Quality attributes are not addressed in tailoring guidelines. However this should not be overlookedHowever, this should not be overlooked.



Risk ManagementPoints to consider:

Risk sources are fundamental drivers that cause risks in a project or organi ationproject or organization.

Competing quality attribute requirements that affect solution selection and designTechnical performance risks (e g quality attribute related risksTechnical performance risks (e.g., quality attribute related risks, supportability risks)

Product behavior and operation with respect to functionality or quality attributesor quality attributes



Decision Analysis and ResolutionPoint to consider:

Typical guidelines for determining when to require a formal e al ation processevaluation process

When competing quality attribute requirements would result in significantly different alternative architectures



Quantitative Project ManagementPoints to consider:

Define and document measurable quality and process performance objecti es for the projectperformance objectives for the projectQuality attributes of outputs of the subprocess (e.g., reliability, testability)



Organizational Process ManagementPoint to consider:

Business objectives that this process area might address incl de Impro ed prod ct q alit (e g f nctionalit q alitinclude: Improved product quality (e.g., functionality, quality attributes)



Process Areas without Explicit Quality Attributes ReferencesQuality Attributes References

Project Monitoring and ControlNo indication of corrective actions with regards to quality attributes

Measurement and AnalysisQuality attributes are not explicitly identified as a measurement objectives that would be addressed throughout the project’ lifecycle

Process and Product Quality AssuranceProcess and Product Quality AssuranceNo discussion in the Process Area regarding expected behaviors of PPQA and its relationship to addressing quality attributesGP 2.9 elaboration for Requirements Development provides the only mention of q p p yquality attribute and associated PPQA activities

VerificationVerification approach does not address quality attributes directly, but addresses analyzing or evaluating architectureevaluating architecture Implicitly ensures that the implementation conforms to architecture

ValidationValidation approach does not address quality attributes, but addresses analyzing or evaluating architecture



Conclusion


Possible Paradigm ShiftFocus on product quality through systematic design considerationsTraditional process focus does not really address entire product life cycleProcess compliance is a given – focus on the businessProcess compliance is a given – focus on the business impact of the application

If security is compromised what…If scalability issues are not considered then what…What if some of the quality attributes are not addressed then what…

Unlike the ISO 9001 – Quality management standard, ISO 9126/25000 has not seen widespread usage, but is very supportive of the CMMI V 1 3 quality attribute focusvery supportive of the CMMI V 1.3 quality attribute focus



Six Quality Attribute CharacteristicsFunctionality is the set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs.Reliability is the set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time.U bilit i th t f tt ib t th t b th ff t d d fUsability is the set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users.Efficiency is the set of attributes that bear on the relationshipEfficiency is the set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions.Maintainability is the set of attributes that bear on the effort needed to ymake specified modifications.Portability is the set of attributes that bear on the ability of software to be transferred from one environment.



ISO/IEC 9126-2001 Information Technology – Software Product Quality

The Need of ArchitectureThe Winchester “Mystery” HouseThe Winchester Mystery House

38 years of construction – 147 builders 0 architects

160 rooms – 40 bedrooms, 6 kitchens, 2 basements, 950 doors

65 doors to blank walls, 13 staircases abandoned, 24 skylights in floors



No architectural blueprint exists

Questions?Questions?


Contact Information

Gary F Norausky PresidentGary F. Norausky, PresidentNorausky Process Solutions, Inc.

[email protected]

+1(619) 472 8810( )

www.norauskypsi.com


o aus yps co

cmmi v1.3 and quality attributes - norauskypsi.comnorauskypsi.com/cmmi v1.3 and quality...

Documents