What ISO 9000 Mandates The requirements for a quality system have been standardized - but many organizations like to think of themselves as unique. So.

Slides:



Advertisements
Similar presentations
Chapter 7: Key Process Areas for Level 2: Repeatable - Arvind Kabir Yateesh.
Advertisements

More CMM Part Two : Details.
How ISO9001 Compares with CMM Mark C. Paulk JAN,1995 CMM version 1.1 ISO9001 July 1994 presented by Zhilan Zhou.
Chapter 2 The Software Process
How to Document A Business Management System
CPIS 357 Software Quality & Testing I.Rehab Bahaaddin Ashary Faculty of Computing and Information Technology Information Systems Department Fall 2010.
Software Development Process Models. The Waterfall Development Model.
Capability Maturity Model (CMM) in SW design
Computer Engineering 203 R Smith Process/Plan Model 7/ Development Process Models Development Process Models are different ways to look at the processes.
1 R&D SDM 1 Software Project Management Capability Maturity Model 2009 Theo Schouten.
CMM Overview - 1 © Paul Sorenson CMPUT Software Engineering refs. IEEE Software, March 1988, 73-79, and IEEE Software, July 1993, (Capability.
Chapter 3 The Structure of the CMM
Quality evaluation and improvement for Internal Audit
CMMI Overview Quality Frameworks.
ISO 9000 Certification ISO 9001 and ISO
Standardization. Introduction A standard is a document. It is a set of rules that control how people should develop and manage materials, products, services,
Capability Maturity Model
OHT 2.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software Quality assurance (SQA) SWE 333 Dr Khalid Alnafjan
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.
Chapter : Software Process
© 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.
UNIT-II Chapter : Software Quality Assurance(SQA)
Chapter 4 Interpreting the CMM. Group (3) Fahmi Alkhalifi Pam Page Pardha Mugunda.
Introduction to Software Quality Assurance (SQA)
Software Project Management Lecture # 8. Outline Chapter 25 – Risk Management  What is Risk Management  Risk Management Strategies  Software Risks.
Capability Maturity Model Part One - Overview. History Effort started by SEI and MITRE Corporation  assess capability of DoD contractors First.
N By: Md Rezaul Huda Reza n
J. R. Burns, Texas Tech University Capability Maturity Model -- CMM n Developed by the Software Engineering Institute (SEI) in 1989 –SEI is a spinoff.
ISO 9000 & TOTAL QUALITY ISO 9000 refers to a group of quality assurance standards established by the International Organization for Standardization.This.
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.
S Q A.
SENG521 (Fall SENG 521 Software Reliability & Testing Software Product & process Improvement using ISO (Part 3d) Department.
Capability Maturity Models Software Engineering Institute (supported by DoD) The problems of software development are mainly caused by poor process management.
Software Engineering Lecture # 17
Capability Maturity Model. History Effort started by SEI and MITRE Corporation  assess capability of DoD contractors First version published in.
1.  Describe an overall framework for project integration management ◦ RelatIion to the other project management knowledge areas and the project life.
CMM Level 2: Repeatable Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Chapter 2 The Software Process Discussion of the Software Process: Process Framework,
Quality Concepts within CMM and PMI G.C.Reddy
Georgia Institute of Technology CS 4320 Fall 2003.
SWEN 5130 Requirements Engineering 1 Dr Jim Helm SWEN 5130 Requirements Engineering Requirements Management Under the CMM.
Paul Hardiman and Rob Brown SMMT IF Planning and organising an audit.
CMMI. 1.Initial - The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual.
QUALITY MANAGEMENT STATEMENT
Ch-1 Introduction The processes used for executing a software project have major effect on quality of s/w produced and productivity achieved in project…
Level 1 Level 1 – Initial: The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends.
Page 1 The Capability Maturity Model (CMM) distinguishes between immature and mature software organizations. Immature software organizations are typically.
COMP 6710 Course NotesSlide 3-0 Auburn University Computer Science and Software Engineering Course Notes Set 3: Software Process Maturity Computer Science.
1 Project Management C53PM Session 3 Russell Taylor Staff Work-base – 1 st Floor
ISO 9001:2000 THE BASICS By The Business Management Systems Department ISO 9000 Essentials.
SOFTWARE PROCESS IMPROVEMENT
Software Engineering (CSI 321) Software Process: A Generic View 1.
CMMI Overview Quality Frameworks. Slide 2 of 146 Outline Introduction High level overview of CMMI Questions and comments.
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.
Submitted By: Tanveer Khan M.Tech(CSE) IVth sem.  The ISO 9000 standards are a collection of formal International Standards, Technical Specifications,
CMMI for Services, Version 1.3
Capability Maturity Model. What is CMM? n CMM: Capability Maturity Model n Developed by the Software Engineering Institute of the Carnegie Mellon University.
CS4311 Spring 2011 Process Improvement Dr
Chapter 10 Software Quality Assurance& Test Plan Software Testing
CMMI Overview Quality Frameworks.
Level 1 Level 1 – Initial: The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends.
Quality management standards
Software Engineering Lecture 16.
Software Engineering I
Capability Maturity Model
Capability Maturity Model
Presentation transcript:

What ISO 9000 Mandates The requirements for a quality system have been standardized - but many organizations like to think of themselves as unique. So how does ISO 9001:2008 allow for the diversity of say, on the one hand, a "Mr. and Mrs." enterprise, and on the other, to a multinational manufacturing company with service components, or a public utility, or a government administration? The answer is that ISO 9001:2008 lays down what requirements your quality system must meet, but does not dictate how they should be met in any particular organization. This leaves great scope and flexibility for implementation in different business sectors and business cultures, as well as in different national cultures. -- ISO

Insuring Compliance 1.The standard requires the organization itself to audit its quality system to verify that it is managing its processes effectively - or, to put it another way, to check that it is fully in control of its activities. 2.In addition, the organization may invite its clients to audit the quality system in order to give them confidence that the organization is capable of delivering products or services that will meet their requirements. ISO 9001:2008 Certificate of Conformity 3.Lastly, the organization may engage the services of an independent quality system certification body to obtain an ISO 9001:2008 Certificate of Conformity. This last option has proved extremely popular in the market-place because of the perceived credibility of an independent assessment. -- ISO

ISO 9001 Contents Section 4 General Requirements Section 5 Management Responsibility Section 6 Resource Management Section 7 Product Realization Section 8 Measurement, Analysis and Improvement

ISO Section 7 - Product Realization 7.1 Product Realization Planning 7.2 Customer Processes Review of Software Product Requirements Review Product Requirements related to Customer Contract 7.3 Software Design and Development 7.4 Purchasing Parts and Components 7.5 Product and Service Provisions tracking builds, deliveries, releases 7.6 Monitoring and Measuring

ISO Section 8 - Measurement, Analysis, and Improvement 8.1 Carry out remedial processes Plan how monitoring, measuring, and analytical processes will be used to demonstrate conformity. Use monitoring, measuring, and analytical processes to demonstrate conformance. 8.2 Monitor and measure quality Monitor and measure customer satisfaction Plan and perform regular internal audits Monitor and measure quality processes Monitor and measure product characteristics. 8.3 Control your nonconforming software products Prevent the delivery or use of nonconforming software products. 8.4 Analyze quality information 8.5 Take required remedial actions

9001 Required Documents 1. Quality Policy 2. Control of Documents 3. Control of Records 4. Internal Audits 5. Control of Nonconforming Product / Service 6. Corrective Action 7. Preventive Action These may go in a single "Quality Manual".

Quality Policy intended for all levels of employees linked to business plan, marketing plan, customer needs measurable objectives Records allows problems to be traced back to causes includes test results, customer comments, etc. actions taken to improve Internal Audits is the system working? what improvements can be made?

Reality Check Does ISO 9001 actually improve software quality? independent studies indicate yes ISO 9001 creates a climate of quality or is this a self-selecting group that only applied for ISO certification because they were already interested in and doing QA?

Not always a good idea Good business judgment is needed to determine ISO9001's proper role for a company. Is certification important to the marketing plans of the company? If not, do not rush to certification. Even without certification, companies should utilize the ISO 9001 model as a benchmark to assess the adequacy of its quality programs. -- Frank Barnes

CMM History Effort started by SEI and MITRE Corporation assess capability of DoD contractors First version published in 1991 closely related to TQM goal is customer satisfaction not required that customer be "delighted"

Some Fundamental Ideas Process improvement is based on small steps, rather than revolutionary innovation. CMM is not exhaustive or dictatorial. CMM focuses on processes that are of value across the organization.

Levels 1. Initial 2. Repeatable 3. Defined 4. Managed 5. Optimizing

Level 1 : The Initial Level ad hoc, sometimes chaotic overcommitment leads to a series of crises during a crisis, projects abandon plans capability is characteristic of individuals, not the organization when a good manager leaves, the success leaves with them

Level 2 : The Repeatable Level Planning is based on experience with similar projects past successes can be repeated Policies for Managing and Implementation installed basic management controls track costs and schedules notice and deal with problems as they arise

Level 3 : The Defined Level Standard Processes defined across the organization and used by all projects standard set of roles, activities, quality tracking, etc each project uses a tailored version of this standard process Training Program is in place to ensure everyone has the skills required for their assigned role

Level 4 : The Managed Level Quantitative Quality Goals for both Products and Processes Organization-wide Process Database meaningful variations in process performance can be distinguished from random noise actions are then taken to correct the situation Products are of predictably high quality

Level 5 : The Optimizing Level Organization has the means to identify weaknesses and strengthen the process proactively teams analyze defects to determine their cause, and disseminate lessons learned throughout the organization major focus on eliminating waste e.g. reduce amount of rework

Defect prevention Technology change management Process change management Quantitative process management Software Quality Management Organization process focus Organization process definition Training program Integrated software management Software product engineering Intergroup coordination Peer Reviews Requirements management Software project planning Software project tracking and oversight Software subcontract management Software quality assurance Software Configuration management Key Process Areas by maturity level This is a somewhat handy hierarchy of activities.

Don't skip levels For example, collecting detailed data (level 4) is meaningless unless the data is from projects that use a consistent process (level 3)

Level Comparison - Risk Level 1 Just do it Level 2 problems are recognized and corrected as they occur Level 3 problems are anticipated and prevented, or impacts minimized Levels 4 and 5 sources of problems are understood and eliminated

Level Comparison - People Level 1 success depends on individual heroics fire fighting is the way of life Level 2 success depends on individuals efforts are supported by management Level 3 people are trained for their role(s) groups work together Levels 4 strong sense of teamwork in every project Level 5 strong sense of teamwork across the organization everyone does process improvement

Level Comparison - Measurement Level 1 ad hoc (if any) data collection and analysis Level 2 individual projects use planning data Level 3 data collected for all processes data shared across projects Levels 4 data standardized across the organization Level 5 data used for process improvement

Defect prevention Technology change management Process change management Quantitative process management Software Quality Management Organization process focus Organization process definition Training program Integrated software management Software product engineering Intergroup coordination Peer Reviews Requirements management Software project planning Software project tracking and oversight Software subcontract management Software quality assurance Software Configuration management Key Process Areas by maturity level

Software Project Planning Goals Goals 1. Software estimates are documented for use in planning and tracking the software project. 2. Software Project activities and commitments are planned and documented. 3. Affected groups and individuals agree to their commitments related to the software project.

Software Project Planning 1. Commitment to Perform Commitment 1 -- A project software manager is designated to be responsible for negotiating commitments and developing the project's software development plan. Commitment 2 -- The project follows a written organizational policy for planning a software project.

This policy typically specifies that: 1. The system requirements allocated to software are used as the basis for planning the software project. 2. The software project's commitments are negotiated between: the project manager, the project software manager, and the other software managers. 3. Involvement of other engineering groups in the software activities is negotiated with these groups and is documented. 4. Affected groups review the software project's: software size estimates, effort and cost estimates, schedules, and other commitments. 5. Senior management reviews all software project commitments made to individuals and groups external to the organization. 6. The project's software development plan is managed and controlled.

Software Project Planning 2. Ability to Perform Ability 1 -- A documented and approved statement of work exists for the software project. Ability 2 -- Responsibilities for developing the software development plan are assigned. Ability 3 -- Adequate resources and funding are provided for planning the software project. Ability 4 -- The software managers, software engineers, and other individuals involved in the software project planning are trained in the software estimating and planning procedures applicable to their areas of responsibility.

The statement of work covers: scope of the work, technical goals and objectives, identification of customers and end users, imposed standards, assigned responsibilities, cost and schedule constraints and goals, dependencies between the software project and other organizations, resource constraints and goals, and other constraints and goals for development and/or maintenance. The statement of work is reviewed by: the project manager, the project software manager, the other software managers, and other affected groups. The statement of work is managed and controlled.

Software Project Planning 3. Activities Performed Activity 1 --The software engineering group participates on the project proposal team. Activity 2 --Software project planning is initiated in the early stages of, and in parallel with, the overall project planning. Activity 3 --The software engineering group participates with other affected groups in the overall project planning throughout the project's life. Activity 4 --Software project commitments made to individuals and groups external to the organization are reviewed with senior management according to a documented procedure. Activity 5 --A software life cycle with predefined stages of manageable size is identified or defined. Activity 6 --The project's software development plan is developed according to a documented procedure. Activity 7 --The plan for the software project is documented. Activity 8 --Software work products that are needed to establish and maintain control of the software project are identified. Activity 9 --Estimates for the size of the software work products (or changes to the size of software work products) are derived according to a documented procedure. Activity Estimates for the software project's effort and costs are derived according to a documented procedure. Activity Estimates for the project's critical computer resources are derived according to a documented procedure. Activity The project's software schedule is derived according to a documented procedure. Activity The software risks associated with the cost, resource, schedule, and technical aspects of the project are identified, assessed, and documented. Activity Plans for the project's software engineering facilities and support tools are prepared. Activity Software planning data are recorded.

Software Project Planning 4. Measurement and Analysis Measurement 1 -- Measurements are made and used to determine the status of the software planning activities. Examples of measurements include: completions of milestones for the software project planning activities compared to the plan; and work completed, effort expended, and funds expended in the software project planning activities compared to the plan.

Software Project Planning 5. Verifying Implementation Verification 1 -- The activities for software project planning are reviewed with senior management on a periodic basis. Verification 2 -- The activities for software project planning are reviewed with the project manager on both a periodic and event-driven basis. Verification 3 -- The software quality assurance group reviews and/or audits the activities and work products for software project planning and reports the results.

and on it goes… The full lists of activities can be found at