Software Quality Management

Quality Defined (continued)

Two kinds of quality are sought out
Quality of design
The characteristic that designers specify for an item This encompasses requirements, specifications, and the design of the system

Quality of conformance (i.e., implementation)

The degree to which the design specifications are followed during manufacturing This focuses on how well the implementation follows the design and how well the resulting system meets its requirements

Quality also can be looked at in terms of user satisfaction

User satisfaction = compliant product + good quality + delivery within budget and schedule

Software quality management

Concerned with ensuring that the required level of quality is achieved in a software product. Involves defining appropriate quality standards and procedures and ensuring that these are followed. Should aim to develop a quality culture where quality is seen as everyones responsibility.

Software Quality:
Kitchen ham (1989 b) refers to software quality fitness for needs and claims quality involves matching expectations. Two features of a piece of quality software:
Conformance to its specification Fitness for its intended purpose.

The Department of Defense (DOD, 1985) in the USA defines software quality as the degree to which the attributes of the software enable it to perform its intended end use.

Conformance to requirements
Requirements must be clearly stated such that they cannot be misunderstood. Then, during software development measurements are taken regularly to determine conformance to those requirements. The nonconformances are regarded as defects the ABSENCE of QUALITY .

Fitness for use

It takes customers requirements and expectations into account, which involves whether the products or services fit their uses. Different customers may use the product in different ways, it means that products must possess multiple elements of fitness for use.

Problems with software

Software was particularly problematical for the following reasons: Software has no physical existence The lack of knowledge of client needs at the start The change of client needs over time The rapid rate of change on both hardware and software The high expectations of customers, particularly with respect to adaptability.

Customers view of quality

Quality is the customers perceived value of the product he or she purchased, based on variety of variables such as price, performance, reliability and satisfaction. Satisfaction after the purchase of the product is the ultimate validation that the product conforms to customers requirements and is fit for use

Views of Quality

User What I want? Fast response Control information Easy to use help menus Available as required Exception data Reacts to business change Designer Good specification Technically correct Fits within systems structure Easy to maintain Difficult for user to manage Fast development Low maintenance Well documented

Quality parameters
IBM CUPRIMDSO
Capability(functionality) Performance Installability Documentation Usability Reliability Maintainability Service and overall

Hewlett-Packard FURPS
[Functionality, usability, reliability, performance and serviceability]

Total Quality Management (TQM)

Originally coined in 1985 by the Naval Air Systems Command It represents a style of management aimed at achieving long term success by linking quality and customer satisfaction.

Key elements of TQM

Customer focus: It includes customers wants and needs, gathering requirements, and measuring and managing customers satisfaction. Process: The objective is to reduce process variation and to achieve continuous process improvement [both business process and product development process.

Key elements of TQM

Human side of quality Focus areas include leadership, management commitment, total participation, employee empowerment, and other social, psychological and human factors. Measurement and analysis The objective is to drive continuous improvement in all quality parameters by the goal oriented measurement system

Total Quality Management

Total Quality Management Continuous Improvement

Customer Focus

Process Improvement

Human Side of Quality

Metrics, Models, Measurements, and Analysis

Software Quality Assurance & Software Quality Control

Dimensions of Quality
Accessibility:The degree to which software can be used comfortably by a wide variety of people, including those who require assistive technologies like screen magnifiers or voice recognition. Compatibility:The suitability of software for use in different environments like different Operating Systems, Browsers, etc.

Concurrency:The ability of software to service multiple requests to the same resources at the same time.
Efficiency:The ability of software to perform well or achieve a result without wasted energy, resources, effort, time or money. Functionality: The ability of software to carry out the functions as specified or desired.

Dimensions of Quality
Installability:The ability of software to be installed inspecified environment. Localizability:The ability of software to be used in different languages, time zones etc. Maintainability:The ease with which software can be modified (adding features, enhancing features, fixing bugs, etc) Performance:The speed at which software performs under a particular load. Portability:The ability of software to be transferred easily from one location to another.

Dimensions of Quality
Reliability: The ability of software to perform a required function under stated conditions for stated period of time without any errors. Scalability: The measure of softwares ability to increase or decrease in performance in response to changes in softwares processing demands. Security: The extent of protection of software against unauthorized access, invasion of privacy, theft, loss of data, etc.

Testability: The ability of software to be easily tested.

Usability: The degree of softwares ease of use.

Cost of Quality
The cost of quality includes all costs incurred in the pursuit of quality or in performing quality-related activities. Quality costs may be divided into the following:
Prevention cost Appraisal cost Failure cost

Prevention Cost
Prevention costs include:
quality planning formal technical reviews test equipment training

Appraisal Cost
Appraisal costs include activities to gain insight into product condition the first time through each process. Examples of appraisal costs include
in-process and inter-process inspection equipment calibration and maintenance testing

Failure Cost
Failure costs may be subdivided into internal failure costs and external failure costs. Internal failure costs include:
rework repair failure mode analysis

External failure costs include:

complaint resolution product return and replacement help line support warranty work

Quality Assurance
A set of activities designed to ensure that the development and/or maintenance process is adequate to ensure a system will meet its objectives. QA is process oriented - Quality Assurance makes sure you are doing the right things, the right way.

Quality Assurance
It includes the following activities:
Process definition and implementation Auditing Training Effecting continuous improvement

The quality management system under which the software system is created is normally based on one or more of the following models/standards:
CMM Six Sigma ISO 9000

Quality Assurance Benefits

Quantitative
Reduced costs Greater efficiency Better performance Less unplanned work Fewer disputes Improved visibility and predictability Reduced risk Problems show up earlier Better quality Improved customer confidence Portable and reusable product Better control over contracted products

Qualitative

Quality Control
A set of activities designed to evaluate a developed work product QC is product oriented - Quality Control makes sure the results of what you've done are what you expected.

Quality Control
Software Quality Control (SQC) is a set of activities for ensuring quality in software products. It includes the following activities: Reviews
Requirement Review Design Review Code Review Deployment Plan Review Test Plan Review Test Cases Review Unit Testing Integration Testing System Testing Acceptance Testing

Testing

Does Quality Assurance Remove Need for Quality Control?

QC is required after QA is done. While in QA we define the processes, policies, strategies, establish standards, developing checklists etc. to be used and followed through out the life cycle of a project. And while in QC we follow all those defined processes, standards and policies to make sure that the project has been developed with high quality and at least meets customers expectations. QA does not assure quality, rather it creates and ensures the processes are being followed to assure quality. QC does not control quality, rather it measures quality. Quality control activities are focused on the deliverable itself. Quality assurance activities are focused on the processes used to create the deliverable.

Difference
Criteria Software Quality Assurance (SQA) Software Quality Control (SQC) SQA is a set of activities for ensuring quality in software engineering processes (that ultimately result in quality in software products). The activities establish and evaluate the processes that produce products. Process focused Prevention oriented SQC is a set of activities for ensuring quality in software products. The activities focus on identifying defects in the actual products produced. Product focused Detection oriented

Definition

Focus Orientation

Breadth
Scope

Organization wide
Relates to all products that will ever be created by a process Process Definition and Implementation Audits Training

Product/project specific
Relates to specific product Reviews Testing

Activities

Software Quality Assurance & Software Quality Control

Dimensions of Quality
Accessibility:The degree to which software can be used comfortably by a wide variety of people, including those who require assistive technologies like screen magnifiers or voice recognition. Compatibility:The suitability of software for use in different environments like different Operating Systems, Browsers, etc.

Concurrency:The ability of software to service multiple requests to the same resources at the same time.
Efficiency:The ability of software to perform well or achieve a result without wasted energy, resources, effort, time or money. Functionality: The ability of software to carry out the functions as specified or desired.

Dimensions of Quality
Installability:The ability of software to be installed inspecified environment. Localizability:The ability of software to be used in different languages, time zones etc. Maintainability:The ease with which software can be modified (adding features, enhancing features, fixing bugs, etc) Performance:The speed at which software performs under a particular load. Portability:The ability of software to be transferred easily from one location to another.

Dimensions of Quality
Reliability: The ability of software to perform a required function under stated conditions for stated period of time without any errors. Scalability: The measure of softwares ability to increase or decrease in performance in response to changes in softwares processing demands. Security: The extent of protection of software against unauthorized access, invasion of privacy, theft, loss of data, etc.

Testability: The ability of software to be easily tested.

Usability: The degree of softwares ease of use.

Cost of Quality
The cost of quality includes all costs incurred in the pursuit of quality or in performing quality-related activities. Quality costs may be divided into the following:
Prevention cost Appraisal cost Failure cost

Prevention Cost
Prevention costs include:
quality planning formal technical reviews test equipment training

Appraisal Cost
Appraisal costs include activities to gain insight into product condition the first time through each process. Examples of appraisal costs include
in-process and inter-process inspection equipment calibration and maintenance testing

Failure Cost
Failure costs may be subdivided into internal failure costs and external failure costs. Internal failure costs include:
rework repair failure mode analysis

External failure costs include:

complaint resolution product return and replacement help line support warranty work

Quality Assurance
A set of activities designed to ensure that the development and/or maintenance process is adequate to ensure a system will meet its objectives. QA is process oriented - Quality Assurance makes sure you are doing the right things, the right way.

Quality Assurance
It includes the following activities:
Process definition and implementation Auditing Training Effecting continuous improvement

The quality management system under which the software system is created is normally based on one or more of the following models/standards:
CMM Six Sigma ISO 9000

Quality Assurance Benefits

Quantitative
Reduced costs Greater efficiency Better performance Less unplanned work Fewer disputes Improved visibility and predictability Reduced risk Problems show up earlier Better quality Improved customer confidence Portable and reusable product Better control over contracted products

Qualitative

Quality Control
A set of activities designed to evaluate a developed work product QC is product oriented - Quality Control makes sure the results of what you've done are what you expected.

Quality Control
Software Quality Control (SQC) is a set of activities for ensuring quality in software products. It includes the following activities: Reviews
Requirement Review Design Review Code Review Deployment Plan Review Test Plan Review Test Cases Review Unit Testing Integration Testing System Testing Acceptance Testing

Testing

Does Quality Assurance Remove Need for Quality Control?

QC is required after QA is done. While in QA we define the processes, policies, strategies, establish standards, developing checklists etc. to be used and followed through out the life cycle of a project. And while in QC we follow all those defined processes, standards and policies to make sure that the project has been developed with high quality and at least meets customers expectations. QA does not assure quality, rather it creates and ensures the processes are being followed to assure quality. QC does not control quality, rather it measures quality. Quality control activities are focused on the deliverable itself. Quality assurance activities are focused on the processes used to create the deliverable.

Difference
Criteria Software Quality Assurance (SQA) Software Quality Control (SQC) SQA is a set of activities for ensuring quality in software engineering processes (that ultimately result in quality in software products). The activities establish and evaluate the processes that produce products. Process focused Prevention oriented SQC is a set of activities for ensuring quality in software products. The activities focus on identifying defects in the actual products produced. Product focused Detection oriented

Definition

Focus Orientation

Breadth
Scope

Organization wide
Relates to all products that will ever be created by a process Process Definition and Implementation Audits Training

Product/project specific
Relates to specific product Reviews Testing

Activities

FURPS
The model, developed at Hewlett-Packard, was first publicly elaborated by Grady and Caswell in 1992. FURPS is an acronym representing a model for classifying software quality attributes (functional and non-functional requirements): The + was later added to the model after various campaigns at HP to extend the acronym to emphasize various attributes.

FURPS+ model
FURPS is a checklist for requirements: Functional (features, capabilities, security) Usability (human factors, help, documentation) Reliability (frequency of failure, recoverability, predictability) Performance (response time, throughput, accuracy, availability, resource usage) Supportability (adaptability, maintainability, internationalization, configurability)

Whats with the + in FURPS+?

And dont forget. Implementation (resource limitation, language and tools, hardware) Interface (constraints posed by interfacing with external systems) Operations (system management in its operational setting) Packaging (for example, a physical box) Legal (licensing)

Classifying Requirements (FUPRS)

Functionality Usability Reliability Performance Supportability + Design requirements Implementation requirements Interface requirements Physical requirements

FURPS+ - Functionality
All functional requirements Usually represent main product features
E.g. Order Processing requirements

Can also be architecturally significant

Auditing, Licensing, Localization, Mail, Online help, Printing, Reporting, Security, System management, Workflow

FURPS+
Usability
User interface issues such as accessibility, aesthetics and consistency

Reliability
Availability, accuracy, recoverability

Performance
Throughput, response time, recovery time, start-up time

Supportability
Testability, adaptability, maintainability, compatibility, configurability, installability, scalability and

localizability

FURPS+
Design requirement
Constrains the design E.g. a relational database is required

Implementation requirement
Constrains the coding or construction E.g. required standards, platform or implementation language

Interface requirement
A requirement to interact with an external item

Physical requirement
A physical constraint imposed on the hardware used to house the

system; for example, shape, size and weight

Classifying Requirements
The product will support multiple human languages
is a supportability requirement

The persistence will be handled by a relational database

is a design requirement

The database will be Oracle 8i

is an implementation requirement

The system will run 7 days a week, 24 hours a day

is a reliability requirement

An online help system is required

is a functional requirement

All presentation logic will be written in Visual Basic

is an implementation requirement

Boehms Software Quality Model

Introduced in 78. Boehm has defined three levels of quality attributes: Primary uses Intermediate constructs Primitive constructs This model is similar to Mc Call but also includes hardware performance that are missing in Mc Call. Model reflects: What user want with S/w Product Uses of Resources Is Software easy to learn and use Is well designed, well coded, easily tested & Maintained

Boehms Software Quality Model

Portability
Device Independence

As it Utility

Reliability
Efficiency

Completeness
Accuracy Consistency Device Efficiency Accessibility Communicativeness Legibility Primitive Constructs

General General Utility Utility

Human Engg. Testability

Understandability

Understandability Modifiability Intermediate Constructs

Primary Uses

ISO-9126
Single Model to standardize the Quality factors since 1980. It makes easier to compare products. It encompasses Six major attributes contributing the Quality Functionality: Characteristics related with the achievement of purpose Reliability: Capability of Software to maintain the performance of S/w Usability: Effort required to use the software Efficiency: Relationship b/w level of performance & amount of resources Maintainability: Effort needed to make modification, improvement Portability: Transfer of One software to another one

ISO-9001/9002

1. 2. 3. 4. 5. 6. 7.

It is heavily documented driven standard ISO-9001 has 20 Clauses, that laid down the guidelines for the development of QA system. These guidelines defines essential feature of SQA Steps that have taken to set up the ISO-9001 standard are:
Commitment of Quality by highest level of Mgmt. Identifying the procedure to develop the S/w and Test. Acceptance of Software by Customer Delivery and Installation Maintenance Support activities viz documentation Maintenance of s/w, Training NC Control and CAPA.

ISO-9001/9002- Check List

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Quality Policy Management Review Quality System Procedure Contract Review Design Control Document Control Purchasing Software identification and Traceability Purchase supplied Product Process Control Inspection and Testing Inspection Measuring and Testing Equipments Test Status Control of Non Confirming Products CAPA Handling Storage and Delivery Quality Records Internal Quality Audit Training Software Maintenance Service & Statistical Techniques.

QUALITY SYSTEMS FOR SOFTWARE DEVELOPMENT

SEI/CMM
The Software Engineering Institute (SEI) is a federally funded research and development center sponsored by the U.S. Department of Defense and operated by Carnegie Mellon University. CERT and CMM are registered in the U.S. Patent and Trademark Office.

11/18/1999

62

QUALITY SYSTEMS FOR SOFTWARE DEVELOPMENT

The CMM provides a

well-defined evolutionary path

toward becoming a mature software organization.

Each level is a layer in a foundation for continuous process improvement.

11/18/1999

63

QUALITY SYSTEMS FOR SOFTWARE DEVELOPMENT

Over-all Goals - Determine if the organization or project has effectively implemented the KPA (key process area). - Identify the scope, boundaries, and intent of each KPA. Common Features - Commitment to Perform - Ability to Perform - Measurement and Analysis - Verifying Implementation - Activities Performed

11/18/1999

64

QUALITY SYSTEMS FOR SOFTWARE DEVELOPMENT

Five Capability Maturity Model Levels

Initial

Repeatable
Defined Managed

Optimized
11/18/1999 65

QUALITY SYSTEMS FOR SOFTWARE DEVELOPMENT

Five Capability Maturity Model Levels

There are 18 Key Process Areas distributed over levels Two through five.

There are a total of 343 key practices grouped within the Key Processes according to the common features of one or more Key Indicators.

11/18/1999

66

QUALITY SYSTEMS FOR SOFTWARE DEVELOPMENT

Five Capability Maturity Model Levels

1.Initial
The initial process is often called ad hoc. Organizations in this level are known as having chaotic processes. Outcomes are unpredictable and poorly controlled. Few processes are defined, and success depends primarily upon individual effort and heroics.

11/18/1999

67

QUALITY SYSTEMS FOR SOFTWARE DEVELOPMENT

Five Capability Maturity Model Levels

2. Repeatable
At this level, software engineering management is used to establish basic project management processes to control cost, schedule, and quality of the product. The necessary process disciplines are established to repeat earlier successes on projects with similar applications.

11/18/1999

68

QUALITY SYSTEMS FOR SOFTWARE DEVELOPMENT

Five Capability Maturity Model Levels

3. Defined
In this level there is a documented and implemented standard software process for both management and engineering activities. All projects use an approved, tailored version of the organizations standard software process for developing and maintaining software.

11/18/1999

69

QUALITY SYSTEMS FOR SOFTWARE DEVELOPMENT

Five Capability Maturity Model Levels

4. Managed
In this level process and product are quantitatively measured and managed.

11/18/1999

70

QUALITY SYSTEMS FOR SOFTWARE DEVELOPMENT

Five Capability Maturity Model Levels

5. Optimizing
This level emphasizes continuous, measurable process improvement, which is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies

11/18/1999

71

QUALITY SYSTEMS FOR SOFTWARE DEVELOPMENT

Level 1: Initial
Characteristics
-43.2% of organizations are at this level compared to 75%. -Over commitment is very common at this level. -During crisis, projects typically abandon planned procedures and revert to coding and testing. -Success depends on having an exceptional manager and effective software team.

Percentages based on most recent assessment, since 1995, of 734 organizations compared to percentages advertised in Late 1997
11/18/1999 72

QUALITY SYSTEMS FOR SOFTWARE DEVELOPMENT

Level 2: Repeatable

Characteristics
-34.2% of organizations are at this level compared to 15%. -Software project standards are defined. -Planning and managing new projects is based on similar project experience.

11/18/1999

73

QUALITY SYSTEMS FOR SOFTWARE DEVELOPMENT

Level 3: Defined

Characteristics
- 17.3% of organizations are at this level compared to 8%. - A standard process for developing and maintaining software is documented and used across the organization. - Management has good insight into technical activities.

11/18/1999

74

QUALITY SYSTEMS FOR SOFTWARE DEVELOPMENT

Level 4: Managed

Characteristics
- 4.0% of organizations are at this level compared to 1.5%. - The organization sets quantitative quality goals for both software product and software processes. - All projects productivity and quality are measured for important software process activities.

11/18/1999

75

QUALITY SYSTEMS FOR SOFTWARE DEVELOPMENT

Level 5: Optimized

Characteristics
- 1.4% of organizations are at this level compared to 0.5%. - The organization has the means to identify weaknesses and strengthen the process proactively. - The goal is the prevention of defects.

11/18/1999

76

QUALITY SYSTEMS FOR SOFTWARE DEVELOPMENT

KEY PROCESS AREAS BY MATURITY LEVEL

Initial (1)

Repeatable (2) Requirements Management [6] Software Project Planning Software Project Tracking and Oversight Software subcontract management Software quality assurance Software Configuration management

11/18/1999

77

QUALITY SYSTEMS FOR SOFTWARE DEVELOPMENT

KEY PROCESS AREAS BY MATURITY LEVEL

Defined (3)

Organization Process Focus Organization process definition Training Program Integrated software management Software Product Engineering Intergroup Coordination Peer Reviews

[7]

11/18/1999

78

QUALITY SYSTEMS FOR SOFTWARE DEVELOPMENT

KEY PROCESS AREAS BY MATURITY LEVEL

Managed (4)
Quantitative Process Management Software Quality Management [2]

Optimizing (5) Defect Prevention [3] Technology Change Management Process Change Management

11/18/1999

79

QUALITY SYSTEMS FOR SOFTWARE DEVELOPMENT

Examples of KPA Goals Level 1 - Poorly Planned - No Goals

Level 2 - Repeatable - Goals - Requirements Management 1. System requirements allocated to software are controlled to establish a baseline for software engineering and management use. 2. Software plans, products, and activities are kept consistent with the system requirements allocated to software.

11/18/1999

80

QUALITY SYSTEMS FOR SOFTWARE DEVELOPMENT

Level 3 - Defined - Goals - Organization Process Focus 1. Software process development and improvement activities are coordinated across the organization 2. The strengths and weaknesses of the software processes used are identified relative to a process standard 3. Organization-level process development and improvement activities are planned

11/18/1999

81

QUALITY SYSTEMS FOR SOFTWARE DEVELOPMENT

Level 4 - Managed - Goals - Quantitative Process Managment 1. The quantitative process management activities are planned 2. The process performance of the projects defined software process is controlled quantitatively.

3. The process capability of the organizations standard software process is known in quantitative terms.

11/18/1999

82

QUALITY SYSTEMS FOR SOFTWARE DEVELOPMENT

Level 5 - Optimizing - Goals - Defect Prevention 1. Defect Prevention activities are planned

2. Common causes of defects are sought out and identified

3. Common causes of defects are prioritized and systematically eliminated.

11/18/1999

83

Software Process Improvement and Capability Determination (SPICE)

It is also known as ISO/IEC 15504 (Information technology Process assessment) It is a set of technical standards documents for the computer software development process and related business management functions. It is another joint International Organization for Standardization and International Electrotechnical Commission standard. ISO/IEC 15504 initially was derived from process lifecycle standard ISO/IEC 12207 and from maturity models like Bootstrap, Trillium and the CMM.

What is SPICE?
SPICE Software Process Improvement & Capability dEtermination
also known as ISO/IEC 15504 is an international standard for SW process assessments Mainly used in Europe and Australia by the automotive industry

Goal
To provide assessment results that are repeatable, objective, comparable

Future
Automotive SPICE launched in April 2006 its usage will increase mainly driven by HIS (Audi, BMW, Daimler Chrysler, Porsche, Volkswagen), Ford & Volvo, Fiat Each OEM have different target level; if these are not met, then:
Suppliers are requested to improve the development processes In case of high risks/low capability levels, the suppliers are excluded from sourcing

SPICE Goals & Scope

Overall goals of the standard are to encourage organizations to employ proven, consistent and reliable methods for assessing the state of their processes and to use their assessment results as part of a coherent improvement program. The scope is process assessment, process improvement and capability determination. Software process domains to be assessed are:

acquisition, supply development, operation, maintenance, supporting processes and service support.

What is SPICE/ ISO 15504 good for? It is a framework related to processes and process maturity, summarising the experience of small, medium and large companies worldwide
A framework for
Understanding strengths and weaknesses of processes SPI and measurement of SPI Helping the customers understand the maturity of their providers

Helps in harmonising process auditing models

Dr. Balla Katalin Software quality and management - 5. 88

The Goal of Process Assessment & Improvement

Rating
Process Assessment Improvement

The goal of an improvement is to change an organizations processes so that they achieve a higher ability to meet its businesses goals Assessments deliver the input for any improvement by detecting strength and weaknesses in the organizations processes Assessments are also a tool used by customers to ascertain the ability of their suppliers to meet their needs

SPICE Models Structure

Capability

Processes

The reference model architecture for this assessment model is 2-dimensional

Process dimension contains processes in groups Process Capability dimension allows the capability of each process to be measured independently

SPICE Models Structure

Process dimension
Characterized by set of purpose statements which describe in measurable terms what has to be achieved in order to attain the defined purpose of the process

Process Capability dimension

Characterizes the level of capability that an organization unit has attained for a particular process or, May be used by the organization as a target to be attained Represent measurable characteristics necessary to manage a process and improve its capability to perform

Process structure

Process structure

Capability Dimension overview

Level 5 Optimizing process
Level 4 Predictable process Level 3 Established process The process performance is optimized to meet current and future business needs.

The process is performed consistently in practice within defined control limits. The quality of work products is quantitatively known. The process is managed and performed using a defined process. Projects are using a tailored version of the standard process. Base practices of the process are planned and tracked. Products are conformed to standards and requirements. Base practices of the process are performed ad hoc and poorly controlled. Work products of the process are identifiable.

Level 2 Managed process

Level 1 Performed process

Level 1
The purpose of the process is generally achieved Work products proof implementation of base practices No documented process No planning or checks of performance of the process No quality requirements for work product are expressed

Level 2
The performance of the process is planned and checked The responsibility for developing the work products is assigned to a person or team Requirements for the work products are identified, documented and traced Work products are put under configuration management and quality assurance No documented or defined process

Capability Level 1 & 2

Capability Level 3
A documented standard process with tailoring guidelines exists and is used in the project Historical process performance data is gathered Experience from the performance of the process is used for process improvement Resources and needed infrastructure for the performance of the process are identified and made available The process is not yet quantitatively understood or managed Process improvement is reactive

Process Dimension overview

Primary Life Cycle Processes Category
Acquisition Supply Engineering: ENG.4 (Software requirements analysis), ENG.5 (Software design), ENG.6 (Software construction), ENG.7 (Software integration), ENG.8 (Software testing)

Supporting Life Cycle Processes Category

Support: SUP.1 (Quality assurance), SUP.2 (Verification), SUP.8 (Configuration management), SUP.10 (Change request management)

Organizational Life Cycle Process Category

Management: MAN.3 (Project Management), MAN.5 (Risk Management) Process Improvement: PIM.3 (Process Improvement) Reuse: REU.2 (Reuse program management)

Process Attributes
Process innovation Continuous optimization Process measurement Process control Process definition Process deployment Performance management Work product management Process performance

Level 5

Level 4

Level 3

Level 2

Level 1

Level

Attributes

Measure capability levels

The fulfillment of a process attribute (PA) is measured along a scale from 0 100% in the following predefined stages:
N (not achieved): 0 15%
The are no or only very limited indications of PA fulfillment

P (partially achieved): 16 50%

There are some indicators that the PA is implemented to the measured extent. In some aspects the process remains unpredictable, though.

L (largely achieved): 51 85%

There is evidence that the PA is implemented to the measured extend in a useful and systematic way. Process performance might still show some weaknesses

F (fully achieved): 86 100%

There is evidence for a complete and systematic PA execution to the measured extent. Process performance does not show any significant shortcomings due to the analyzed processes

SPICE Assessments
Assessment input: purpose scope constraints qualified assessor extended process definition Process Assessment instrument process indicators process management indicators

Planning

Data collection

Data analysis

Process rating

REPORT

Assessment Process model process purpose practices Assessment output process capability level ratings assessment record

SPICE Assessments results

Zero Defects
Zero Defects was a quality control program originated by the Denver Division of the Martin Marietta Corporation on the Titan Missile program, which carried the Project Gemini astronauts into space in the middle to late 1960s. During the 1990s, large companies in the automotive industry tried to cut costs by reducing their quality inspection processes and demanding that their suppliers dramatically improve the quality of their supplies. This eventually resulted in demands for the "Zero Defects" standard. It is implemented all over the world.

Principles of Zero Defects

1. Quality is conformance to requirements - Every product or service has a requirement: a description of what the customer needs. When a particular product meets that requirement, it has achieved quality, provided that the requirement accurately describes what the enterprise and the customer actually need. 2. Defect prevention is preferable to quality inspection and correction It is based on the observation that it is nearly always less troublesome, more certain and less expensive to prevent defects than to discover and correct them.

Principles of Zero Defects

3. Zero Defects is the quality standard-The third is based on the normative nature of requirements: if a requirement expresses what is genuinely needed, then any unit that does not meet requirements will not satisfy the need and is no good. If units that do not meet requirements actually do satisfy the need, then the requirement should be changed to reflect reality 4. Quality is measured in monetary terms the Price of Nonconformance (PONC) - Phil Crosby believes that every defect represents a cost, which is often hidden. These costs include inspection time, rework, wasted material and labor, lost revenue and the cost of customer dissatisfaction. When properly identified and accounted for, the magnitude of these costs can be made apparent