Chapter 4 Interpreting the CMM. Group (3) Fahmi Alkhalifi Pam Page Pardha Mugunda.

Slides:



Advertisements
Similar presentations
Configuration Management
Advertisements

1 Dr. Ashraf El-Farghly SECC. 2 Level 3 focus on the organization - Best practices are gathered across the organization. - Processes are tailored depending.
Software Quality Assurance Plan
Group 7 - Chapter 3 Steven Shroyer - Introduction, ad hoc, level 2 Xiao Jingshan - Levels 3 and 4 Dusting Marker - Level 5 and example companies Definintions.
Software Quality Assurance Plan
Chapter 7: Key Process Areas for Level 2: Repeatable - Arvind Kabir Yateesh.
More CMM Part Two : Details.
1 Brief Descriptions of CMM KPAs CEN 6070 Summer 2004.
How ISO9001 Compares with CMM Mark C. Paulk JAN,1995 CMM version 1.1 ISO9001 July 1994 presented by Zhilan Zhou.
EPSON STAMPING ISO REV 1 2/10/2000.
Stepan Potiyenko ISS Sr.SW Developer.
Planning a measurement program What is a metrics plan? A metrics plan must describe the who, what, where, when, how, and why of metrics. It begins with.
Secure System Administration & Certification DITSCAP Manual (Chapter 6) Phase 4 Post Accreditation Stephen I. Khan Ted Chapman University of Tulsa Department.
Chapter 3 The Structure of the CMM
DITSCAP Phase 2 - Verification Pramod Jampala Christopher Swenson.
Short Course on Introduction to Meteorological Instrumentation and Observations Techniques QA and QC Procedures Short Course on Introduction to Meteorological.
ISO 9000 Certification ISO 9001 and ISO
CSSE 375 Software Construction and Evolution: Configuration Management
Capability Maturity Model
Configuration Management for Transportation Management Systems Establishing and Maintaining System Integrity.
Release & Deployment ITIL Version 3
CMM Level 3 KPA’s CS4320 Fall Organizational Process Focus (Goals) Software process development and improvement activities are coordinated across.
WHAT IS ISO 9000.
© 1999 Prentice-Hall, Inc. Chap Level 3: Key Processes Defined Group 9: LaTanya Moore Ali Imajat Asim Eldaroty.
The Key Process Areas for Level 2: Repeatable Ralph Covington David Wang.
Integrated Capability Maturity Model (CMMI)
Copyright Course Technology 1999
Introduction to Software Quality Assurance (SQA)
Capability Maturity Model. Reflection Have you ever been a part of, or observed, a “difficult” software development effort? How did the difficulty surface?
N By: Md Rezaul Huda Reza n
Software Project Management Introduction to Project Management.
Software Configuration Management (SCM)
1 Chapter 2 The Process. 2 Process  What is it?  Who does it?  Why is it important?  What are the steps?  What is the work product?  How to ensure.
Software System Engineering: A tutorial
NIST Special Publication Revision 1
1 Process Engineering A Systems Approach to Process Improvement Jeffrey L. Dutton Jacobs Sverdrup Advanced Systems Group Engineering Performance Improvement.
CMM Level 2 KPA’s CS 4320 Fall Requirements Management 1 Goals: – System requirements allocated to software are controlled using a baseline for.
Soft Tech Development Inc. 1 Software Project Tracking A CMM Level 2 Key Process Area Soft Tech Development Inc.
SENG521 (Fall SENG 521 Software Reliability & Testing Software Product & process Improvement using ISO (Part 3d) Department.
Software Engineering Lecture # 17
Certification and Accreditation CS Phase-1: Definition Atif Sultanuddin Raja Chawat Raja Chawat.
Capability Maturity Model. History Effort started by SEI and MITRE Corporation  assess capability of DoD contractors First version published in.
10/16/2015Bahill1 Organizational Innovation and Deployment Causal Analysis and Resolution 5 Optimizing 4 Quantitatively Managed 3 Defined 2 Managed Continuous.
CMM Level 2: Repeatable Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
Managing CMMI® as a Project
Georgia Institute of Technology CS 4320 Fall 2003.
KS3 Phase4 Client Server Monitoring System October 1, 2008 by Stephen, Seema, Kam, Shpetim.
SWEN 5130 Requirements Engineering 1 Dr Jim Helm SWEN 5130 Requirements Engineering Requirements Management Under the CMM.
Copyright  2005 McGraw-Hill Australia Pty Ltd PPTs t/a Australian Human Resources Management by Jeremy Seward and Tim Dein Slides prepared by Michelle.
Purpose: The purpose of CMM Integration is to provide guidance for improving your organization’s processes and your ability to manage the development,
Configuration Management (II) Copyright, 2000 © Jerzy R. Nawrocki Requirements.
 CMMI  REQUIREMENT DEVELOPMENT  SPECIFIC AND GENERIC GOALS  SG1: Develop CUSTOMER Requirement  SG2: Develop Product Requirement  SG3: Analyze.
MSA Orientation – v203a 1 What’s RIGHT with the CMMI?!? Pat O’Toole
Project Management Strategies Hidden in the CMMI Rick Hefner, Northrop Grumman CMMI Technology Conference & User Group November.
SE513 Software Quality Assurance Lecture12: Software Reliability and Quality Management Standards.
Pertemuan 14 Matakuliah: A0214/Audit Sistem Informasi Tahun: 2007.
Capability Maturity Model. CS460 - Senior Design Project I (AY2004)2 Immature Organisations Software processes are often rigorously followed. Organisation.
Cmpe 589 Spring Fundamental Process and Process Management Concepts Process –the people, methods, and tools used to produce software products. –Improving.
Introduction for the Implementation of Software Configuration Management I thought I knew it all !
Configuration Management
Software Quality Control and Quality Assurance: Introduction
Software Configuration Management
TechStambha PMP Certification Training
CMMI – Staged Representation
ISO/IEC IEEE/EIA Software Life Cycle Processes Supporting Life Cycle Processes IEEE Supporting Processes.
Software Engineering Lecture 16.
Capability Maturity Model
Chapter # 8 Quality Management Standards
Capability Maturity Model
Software Reviews.
Presentation transcript:

Chapter 4 Interpreting the CMM

Group (3) Fahmi Alkhalifi Pam Page Pardha Mugunda

CMM Commonsense application of process management and quality improvement concepts to software development and maintenance. Written to address the process of large, complex software efforts. Broad-based agreement by software community of good engineering and management practices.

Interpreting Key Practices Provide a description of essential elements of an effective software process. Set principles that apply to variety of projects and organizations and a range of typical software applications. Although it’s meant to be independent, organizations should map these conventions appropriately to their own projects and business environments.

Terminologies Activity: Any step taken or function performed, both mental or physical, toward achieving some objectives. Activities include all the work the managers and technical staff do to perform the tasks of the project and organization. Audit: An independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria. Commitment: A pact (agreement) that is freely assumed, visible, and expected to be kept by all parties.

Terminologies – Cont. Configuration management: A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements. Goals: A summary of the key practices of a key process area that can be used to determine whether an organization or project has effectively implemented the key process area. The goals signify the scope, boundaries, and intent of each key process area.

Terminologies – Cont. Key practices: The infrastructure and activities that contribute most of the effective implementation and institutionalization of a key process area. Key process area: A cluster of related activities that, when performed collectively, achieve a set of goals considered to be important for establishing process capability. Managed and controlled: The process of identifying and defining software work products that are not part of a baseline and therefore are not placed under configuration management, but that must be controlled for the project to proceed in a disciplined manner.

Terminologies – Cont. Orientation: An overview or introduction to a topic for those overseeing or interfacing with the individuals responsible for performing in the topic area. Periodic review: A review that occurs at specified, regular time interval. Procedure: A written description of a course of action to be taken to perform a given task. Process: A sequence of steps performed for a given purpose, e.g. software development process

Terminologies – Cont. Role: A unit of defined responsibilities that may be assumed by one or more individuals. Software work product: Any artifact created as part of defining, maintaining, or using a software process. They can include process descriptions, plans, procedures, computer programs, and associated documentation, which may or may not be intended for delivery to a customer or end user.

Key Process Area Template Notes:  Goals and common features are delimited by headers. e.g. Goals, Commitments to Perform  Key practices labeled with noun (common feature) and a number. e.g. Commitment 1, Ability 2  Key practices are in Bold type. e.g. A group that is responsible for exists.  Sub-practices preceded by preamble. e.g. key practices that include “according to a documented procedure” are preceded by “This procedure typically specifies that:”  Practices may be followed by boxed text. e.g. elaboration or cross-reference

a key area for Level n: The purpose of is. involves. Goals Goal 1 Goal 2 Commitment to Perform Commitment 1The project follows written organizational policy for. or The organization follows a written policy for. This policy typically specifies that: 1.

Ability to Perform Ability 1A group that is responsible for exists. 1. Ability 2Adequate resources and funding are provided for. 1. Tools to support activities for are made available. Ability 3 are trained. or receive required training. Ability 4 receive orientation in. Examples of tools include: Examples of training include: Examples of orientation include:

Activities Performed Activity are placed under configuration management. Activity 2 according to documented procedure. This procedure typically specifies that: Examples of affected groups include: Refer to the Software Configuration Management key process area. Chapter (7).

undergo peer review. 4. are managed and controlled. Refer to Activity N of the key process area for practices. Refer to the Peer Reviews key process area. Chapter 8 “Managed and controlled” implies that the version of the work product in use at a given time (past or present) is known (i.e. version control), and changes are incorporated in a controlled manner (i.e., change control). If a greater degree of formality than is implied by “managed and controlled” is desired, the work product can be placed under the full discipline of configuration management, as is described in the Software Configuration Management key process area.

Measurement and Analysis Measurement 1Measurements are made and used to determine status of the activities for. Verifying Implementation Verification 1Activities for are reviewed with senior management on a periodic basis. 1. Verification 2Activities for are reviewed with the project manager on both a periodic and event-driven basis. 1. Verification 3Software quality assurance group reviews and/or audits the activities and work products for and reports the results. At a minimum, these reviews and/or audits verify that: 1. Examples of measurements include: Refer to Software Quality Assurance key process area. Chapter 7

Interpreting the Common Features Commitment to Perform Ability to Perform Activities Performed Measurement and Analysis Verifying Implementation

Interpreting the Common Features Commitment to Perform Policy Statements  Written, organizational policy for practices of the key process areas

Interpreting the Common Features Leadership  Assigns leadership roles to key process areas or describes sponsorship activities that are required for the key process area to be successfully institutionalized

Interpreting the Common Features Ability to Perform - the preconditions in the project or organization necessary to implement the software process competently Organizational Structures Resources and Funding Training  Orientation  Prerequisites

Interpreting the Common Features Organizational Structures May need to develop independence or objectivity that may require developing into a special group

Interpreting the Common Features Resources and Funding Access to special skills Adequate funding Access to tools

Interpreting the Common Features Training Informal or formal  Classroom, videos, computer-aided or a formal mentor and apprenticeship programs  Different organizational situations will drive the training needs

Interpreting the Common Features Orientation Overview Prerequisites Items expected to be obtained from outside the realm of the software project

Interpreting the Common Features Activities Performed: Types of Plans  Informal Plans  Formal Plans Documented Procedures System requirements Customer-supplier relationship  Internal  External

Interpreting the Common Features Tracking and taking corrective action vs. managing Reviewed vs. undergoes peer reviews Placed under configuration management vs. managed and controlled

Interpreting the Common Features Measurement and Analysis Quality of the training program Effectiveness of management Functionality and quality of software products

Interpreting the Common Features Verifying Implementation Senior management oversight on a periodic basis Project management oversight  Periodic basis  Event-driven basis Software quality assurance activities

Organizational Structure and Roles Organizational Roles Manager Senior manager Project manager Project software manager First-line software manager Software task leader Staff, software engineering staff, individuals

Organizational Structure and Roles Organizational Structure Organization Project Group

Organizational Structure and Roles CMM referred groups:  Software engineering group  Software related groups  Software engineering process group  System engineering group  System test group  Software quality assurance group  Software configuration management group  Training group

Independence and Organizational Structure Independence should provide: Those individuals should be the “eyes and ears” of senior management Protect the individuals from adverse personnel actions Provide senior management with confidence on results of the project

Understanding Software Process Definition

Process Definition Concepts Requirements that define what process is to be described, An architecture and design that provide information on how the process will be defined, Implementation of the process design in a project or organizational situation, Validation of the process description via measurement, and Deployment of the process into wide spread operation within the organizational or project for which the process is intended

Concepts Related to the Organization’s Software Process Assets Software process assets are a collection of entities maintained by an organization, for use by projects in developing, tailoring, maintaining, and implementing their software process. Any entity that the organization considers useful in performing the activities of process definition and maintenance could be included as a process asset.

Organization’s Software Process Assets The organization establishes and maintains a set of software process assets. The organizations standard software process, The description of software life cycles approve for use, The guidelines and criteria for tailoring the organization’s standard software process.

Organizations Standard Software Process An organizations standard software process is the operational definition of the basic process that guide the establishment of a common software process across the software projects in the organization.

Software Process Architecture The software process architecture is a high level description of the organization’s standard.

Software Process Element A software process element is a constituent of a software process description.

Description of Software Life Cycles Approved for Use A software life cycle is the period of time that begins when a software product is conceived and ends when the software is no longer available for use.

Concepts Related to the Project’s Defined Software Process Description of projects defined software process Stages Tasks Activities Software work products Software products

The Evolution of Processes The management process category contains the project management activities The organizational process category contains the cross process responsibilities. The engineering process category contains the technical activities such as requirement analysis, design, code, and test.

Applying Professional Judgment Professional judgment is necessary for interpreting the key practices and how they contribute to the goals of a key area. To provide complete set of valid principles that apply to a wide range of situations, the key practices are intentionally stated to allow for flexibility.

Applying Professional Judgment The goals of the key process areas provide a structure for making the interpretation. Professional judgment is used to determine whether a specific interpretation or implementation satisfies the goals of key area.

Applying Professional Judgment What are the criteria for a mature software process? It is Defined Documented Trained Practiced Supported

Applying Professional Judgment Both maturity and effectiveness should be interpreted in the context of the business environment and the specific circumstances of the project and the organization.