This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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.
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
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
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)
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
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)
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
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
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. 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.
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.
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
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
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
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
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
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 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
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
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.