Quality Management & Process Improvement. Quality Management. Software quality management. What is quality?

Quality Management

&

Process Improvement

Beatrice Åkerblom beatrice@dsv.su.se

Quality Management

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 everyone"s responsibility.

What is quality?

!_{Quality, simplistically, means that a}

product should meet its specification.

!_{This is problematical for software}

systems

~ _{There is a tension between customer}

quality requirements (efficiency, reliability, etc.) and developer quality requirements (maintainability, reusability, etc.);

~ _{Some quality requirements are difficult}

to specify in an unambiguous way;

~ _{Software specifications are usually}

The quality

compromise

! _{We cannot wait for specifications to}

improve before paying attention to quality management.

! _{We must put quality management}

procedures into place to improve quality in spite of imperfect specification.

5

Scope of quality

management

!_{Quality management is particularly}

important for large, complex systems. The quality documentation is a record of progress and supports continuity of development as the development team changes.

!_{For smaller systems, quality}

management needs less documentation and should focus on establishing a quality culture.

6

Quality management

activities

! _{Quality assurance}

~ _{Establish organisational procedures}

and standards for quality.

! _{Quality planning}

~ _{Select applicable procedures and}

standards for a particular project and modify these as required.

! _{Quality control}

~ _{Ensure that procedures and standards}

are followed by the software development team.

! _{Quality management should be separate}

from project management to ensure independence.

Process and product

quality

!_{The quality of a developed product is}

influenced by the quality of the production process.

!_{This is important in software}

development as some product quality attributes are hard to assess.

!_{However, there is a very complex and}

poorly understood relationship between software processes and product quality.

Process-based quality

! _{There is a straightforward link between}

process and product in manufactured goods.

! _{More complex for software because:}

~ _{The application of individual skills and}

experience is particularly important in software development;

~ _{External factors such as the novelty of}

an application or the need for an accelerated development schedule may impair product quality.

! _{Care must be taken not to impose}

inappropriate process standards - these could reduce rather than improve the product quality.

9

Process-based quality

10 Define process Develop_product Assess product_quality

Standardise process Improve process Quality OK No Yes

Practical process

quality

! _{Define process standards such as how}

reviews should be conducted, configuration

management, etc.

! _{Monitor the development process to}

ensure

that standards are being followed.

! _{Report on the process to project}

management and software procurer.

! _{Don"t use inappropriate practices simply}

because standards have been established.

Quality assurance

and standards

!_{Standards are the key to effective quality}

management.

!_{They may be international, national,}

organisational or project standards.

!_{Product standards define}

characteristics that all components should exhibit e.g. a common programming style.

!_{Process standards define how the}

Importance of

standards

! _{Encapsulation of best practice- avoids}

repetition of past mistakes.

! _{They are a framework for quality}

assurance processes - they involve checking compliance to standards.

! _{They provide continuity - new staff can}

understand the organisation by understanding the standards that are used.

13

Product and process

standards

14

Product standards Process standards

Design review form Design review conduct

Requirements document structure Submission of documents to CM

Method header format Version release process

Java programming style Project plan approval process

Project plan format Change control process

Change request form Test recording process

Problems with

standards

! _{They may not be seen as relevant and}

up-to-date by software engineers.

! _{They often involve too much}

bureaucratic form filling.

! _{If they are unsupported by software}

tools, tedious manual work is often involved to maintain the documentation associated with the standards.

Standards

development

!_{Involve practitioners in development.}

Engineers should understand the rationale underlying a standard.

!_{Review standards and their usage}

regularly.

Standards can quickly become outdated and this reduces their credibility amongst practitioners.

!_{Detailed standards should have}

associated tool

support. Excessive clerical work is the most

ISO 9000

! _{An international set of standards for}

quality management.

! _{Applicable to a range of organisations}

from manufacturing to service industries.

! _{ISO 9001 applicable to organisations}

which design, develop and maintain products.

! _{ISO 9001 is a generic model of the}

quality process that must be instantiated for each organisation using the standard.

17

ISO 9001

18

Management responsibility Quality system

Control of non-conforming products Design control Handling, storage, packaging and delivery

Purchasing

Purchaser-supplied products Product identification and traceability Process control Inspection and testing Inspection and test equipment Inspection and test status Contract review Corrective action Document control Quality records Internal quality audits Training

Servicing Statistical techniques

ISO 9000 certification

! _{Quality standards and procedures}

should be documented in an organisational quality manual.

! _{An external body may certify that an}

organisation"s quality manual conforms to ISO 9000 standards.

! _{Some customers require suppliers to be}

ISO 9000 certified although the need for flexibility here is increasingly recognised.

ISO 9000 and quality

management

Project 1

quality plan quality planProject 2 quality planProject 3 Project qualitymanagement Organisation quality manual ISO 9000 quality models Organisation quality process

is used to develop instantiated as

instantiated as

documents

Documentation

standards

! _{Particularly important - documents are}

the tangible manifestation of the software.

! _{Documentation process standards}

~ _{Concerned with how documents}

should be developed, validated and maintained.

! _{Document standards}

~ _{Concerned with document contents,}

structure, and appearance.

! _{Document interchange standards}

~ _{Concerned with the compatibility of}

electronic documents. 21

Documentation

process

22 Create

initial draft Reviewdraft

Incorporate review comments Re-draft document Proofread

text final draftProduce final draftCheck

Layout

text Reviewlayout print mastersProduce copiesPrint Stage 1: Creation Stage 2: Polishing Stage 3: Production Approved document Approved document

Document standards

! _{Document identification standards}

~ _{How documents are uniquely}

identified.

! _{Document structure standards}

~ _{Standard structure for project}

documents.

! _{Document presentation standards}

~ _{Define fonts and styles, use of logos,}

etc.

! _{Document update standards}

~ _{Define how changes from previous}

versions are reflected in a document.

Quality planning

!_{A quality plan sets out the desired}

product qualities and how these are assessed and defines the most significant quality attributes.

!_{The quality plan should define the quality}

assessment process.

!_{It should set out which organisational}

standards should be applied and, where necessary, define new standards to be used.

Quality plans

! _{Quality plan structure}

~ _{Product introduction;}

~ _{Product plans;}

~ _{Process descriptions;}

~ _{Quality goals;}

~ _{Risks and risk management.}

! _{Quality plans should be short, succinct}

documents

~ _{If they are too long, no-one will read}

them.

25

Software quality

attributes

26

Safety Understandability Portability

Security Testability Usability

Reliability Adaptability Reusability

Resilience Modularity Efficiency

Robustness Complexity Learnability

Quality control

! _{This involves checking the software}

development process to ensure that procedures and standards are being followed.

! _{There are two approaches to quality}

control

~ _{Quality reviews;}

~ _{Automated software assessment and}

software measurement.

Quality reviews

!_{This is the principal method of validating}

the quality of a process or of a product.

!_{A group examines part or all of a}

process or system and its documentation to find potential problems.

!_{There are different types of review with}

different objectives

~ _{Inspections for defect removal}

(product);

~ _{Reviews for progress assessment}

(product and process);

~ _{Quality reviews (product and}

Types of review

29

Review type Principal purpose

Design or program

inspections To detect detailed errors in the requirements, design or code. A checklist ofpossible errors should drive the review. Progress reviews To provide information for management about the overall progress of the project. This is b oth a process and a product review and is concerned with costs, plans and schedules.

Quality reviews To carry out a t echnical analysis of product components or documentation to find mismatches between the specification and the component design, code or documentation and to ensure that defined quality standards have been followed.

Quality reviews

!_{A group of people carefully examine part}

or all of a software system and its associated documentation.

!_{Code, designs, specifications, test plans,}

standards, etc. can all be reviewed.

!_{Software or documents may be 'signed}

off' at a review which signifies that progress to the next development stage has been approved by management.

30

Review functions

! _{Quality function - they are part of the}

general quality management process.

! _{Project management function - they}

provide information for project managers.

! _{Training and communication function -}

product knowledge is passed between development team members.

Quality reviews

!_{The objective is the discovery of system}

defects and inconsistencies.

!_{Any documents produced in the process}

may be reviewed.

!_{Review teams should be relatively small}

and reviews should be fairly short.

!_{Records should always be maintained of}

Review results

! _{Comments made during the review}

should be classified

~ _{No action. No change to the software}

or documentation is required;

~ _{Refer for repair. Designer or}

programmer should correct an identified fault;

~ _{Reconsider overall design. The}

problem identified in the review impacts other parts of the design. Some overall judgement must be made about the most cost-effective way of solving the problem;

! _{Requirements and specification errors}

may have to be referred to the client.

33

Software

measurement and

metrics

!_{Software measurement is concerned}

with deriving a numeric value for an attribute of a software product or process.

!_{This allows for objective comparisons}

between techniques and processes.

!_{Although some companies have}

introduced measurement programmes, most organisations still don"t make systematic use of software measurement.

!_{There are few established standards in}

this area.

34

Software metric

! _{Any type of measurement which relates}

to a software system, process or related documentation

~ _{Lines of code in a program, the Fog}

index, number of person-days required to develop a component.

! _{Allow the software and the software}

process to be quantified.

! _{May be used to predict product attributes}

or to control the software process.

! _{Product metrics can be used for general}

predictions or to identify anomalous components.

Predictor and control

metrics

Management decisions Control measurements Software process Predictor measurements Software product

Metrics assumptions

37

! _{A software property can be measured.}

! _{The relationship exists between what we}

can measure and what we want to know. We can only measure internal attributes but are often more interested in external software attributes.

! _{This relationship has been formalised}

and validated.

! _{It may be difficult to relate what can be}

measured to desirable external quality attributes.

Internal and external

attributes

38 Reliability Number of procedure parameters Cyclomatic complexity

Program size in lines of code Number of error

messages Length of user manual Maintainability

Usability Portability

The measurement

process

! _{A software measurement process may}

be part of a quality control process.

! _{Data collected during this process}

should be maintained as an organisational resource.

! _{Once a measurement database has}

been established, comparisons across projects become possible.

Product measurement

process

Measure component characteristics Identify anomalous measurements Analyse anomalous components Select components to be assessed Choose measurements to be made

Data collection

! _{A metrics programme should be based}

on a set of product and process data.

! _{Data should be collected immediately}

(not in retrospect) and, if possible, automatically.

! _{Three types of automatic data collection}

~ _{Static product analysis;}

~ _{Dynamic product analysis;}

~ _{Process data collation.}

41

Data accuracy

!_{Don"t collect unnecessary data}

~ _{The questions to be answered should}

be decided in advance and the required data identified.

!_{Tell people why the data is being}

collected.

~ _{It should not be part of personnel}

evaluation.

!_{Don"t rely on memory}

~ _{Collect data when it is generated not}

after a project has finished.

42

Product metrics

! _{A quality metric should be a predictor of}

product quality.

! _{Classes of product metric}

~ _{Dynamic metrics which are collected}

by measurements made of a program in execution;

~ _{Static metrics which are collected by}

measurements made of the system representations;

~ _{Dynamic metrics help assess efficiency}

and reliability; static metrics help assess complexity, understandability and maintainability.

Dynamic and static

metrics

!_{Dynamic metrics are closely related to}

software quality attributes

~ _{It is relatively easy to measure the}

response time of a system

(performance attribute) or the number of failures (reliability attribute).

!_{Static metrics have an indirect}

relationship with quality attributes

~ _{You need to try and derive a}

relationship between these metrics and properties such as complexity, understandability and maintainability.

Software product

metrics

45

Software metric Description

Fan in/Fan-out Fan-in is a measure of the number of functions or methods that call some other function or method (say X). Fan-out is the number of functions that are called by function X. A high value for fan-in means that X i s tightly coupled to the rest of the design and changes to X will have extensive knock-on effects. A high value for fan-out suggests that the overall complexity of X m ay be high because of the complexity of the control logic needed to coordinate the called components.

Length of code This is a measure of the size of a program. Generally, the larger the size of the code of a component, the more complex and error-prone that component is likely to be. Length of code has been shown to be one of the most reliable metrics for predicting error-proneness in components.

Cyclomatic complexity This is a measure of the control complexity of a p rogram. This control complexity may be related to program understandability. I discuss how to compute cyclomatic complexity in Chapter 22.

Length of identifiers This is a measure of the average length of distinct identifiers in a p rogram. The longer the identifiers, the more likely they are to be m eaningful and hence the more understandable the program.

Depth of conditional

nesting This is a measure of the depth of nesting of if-statements in a program. Deeply nested ifstatements are hard to understand and are potentially error-prone. Fog index This is a measure of the average length of words and sentences in documents. The higher

the value for the Fog index, the more difficult the document is to understand.

Object-oriented

metrics

46 Object-oriented metric Description Depth of inheritance tree

This represents the number of discrete levels in the inheritance tree where sub-classes inherit attributes and operations (methods) from super-sub-classes. The deeper the inheritance tree, the more complex the design. Many different object classes may have to be understood to understand the object classes at the leaves of the tree.

Method fan-in/fan-out

This is directly related to fan-in and fan-out as described above and means essentially the same thing. However, it may be appropriate to make a distinction between calls from other methods within the object and calls from external methods.

Weighted methods per class

This is the number of methods that are included in a class weighted by the complexity of each method. Therefore, a simple method may have a complexity of 1 and a large and complex method a much higher value. The larger the value for this metric, the more complex the object class. Complex objects are more likely to be more difficult to understand. They may not be logically cohesive so cannot be reused effectively as super-classes in an inheritance tree. Number of

overriding operations

This is the number of operations in a super-class that are over-ridden in a sub-class. A high value for this metric indicates that the super-class used may not be an appropriate parent for the sub-class.

Measurement

analysis

! _{It is not always obvious what data}

means

~ _{Analysing collected data is very}

difficult.

! _{Professional statisticians should be}

consulted if available.

! _{Data analysis must take local}

circumstances into account.

Measurement

surprises

!_{Reducing the number of faults in a}

program leads to an increased number of help desk calls

~ _{The program is now thought of as}

more reliable and so has a wider more diverse market. The percentage of users who call the help desk may have decreased but the total may increase;

~ _{A more reliable system is used in a}

different way from a system where users work around the faults. This leads to more help desk calls.

Process Improvement

Process improvement

!_{Understanding existing processes and}

introducing process changes to improve product quality, reduce costs or accelerate schedules.

!_{Most process improvement work so far}

has focused on defect reduction. This reflects the increasing attention paid by industry to quality.

!_{However, other process attributes can}

also be the focus of improvement

50

Process attributes

Process

characteristic Description

Understandability To what extent is the process explicitly defined and how easy is it t o understand the process definition?

Visibility Do the process activities culminate in clear results so that the progress of the process is externally visible?

Supportability To what extent can CASE tools be used to support the process activities?

Acceptability Is t he defined process acceptable to and usable by the engineers responsible for producing the software product?

Reliability Is the process designed in such a way that process errors are avoided or trapped before they result in product errors?

Robustness Can the process continue in spite of unexpected problems? Maintainability Can the process evolve to reflect changing organisational requirements

or identified process improvements?

Rapidity How fast can the process of delivering a system from a given specification be completed?

The process

improvement cycle

Analyse Measure Change

Process improvement

stages

! _{Process measurement}

~ _{Attributes of the current process are}

measured. These are a baseline for assessing improvements.

! _{Process analysis}

~ _{The current process is assessed and}

bottlenecks and weaknesses are identified.

! _{Process change}

~ _{Changes to the process that have}

been identified during the analysis are introduced.

53

Process and product

quality

!_{Process quality and product quality are}

closely related and process

improvement benefits arise because the quality of the product depends on its development process.

!_{A good process is usually required to}

produce a good product.

!_{For manufactured goods, process is the}

principal quality determinant.

!_{For design-based activity, other factors}

are also involved especially the capabilities of the designers.

54

Principal product

quality factors

Product quality Development technology

Cost, time and schedule Process

quality Peoplequality

Quality factors

!_{For large projects with !average"}

capabilities, the development process determines product quality.

!_{For small projects, the capabilities of the}

developers is the main determinant.

!_{The development technology is}

particularly significant for small projects.

!_{In all cases, if an unrealistic schedule is}

Process classification

! _Informal

~ _{No detailed process model.}

Development team chose their own way of working.

! _Managed

~ _{Defined process model which drives}

the development process.

! _Methodical

~ _{Processes supported by some}

development method such as the RUP.

! _Supported

~ _{Processes supported by automated}

CASE tools. 57

Process applicability

58 Prototypes Short-lifetime systems 4GL business systems Small/medium-sized systems Informal process Large systems Long-lifetime products Managed process Well-understood application domains Re-engineered systems Methodical process

Process choice

! _{Process used should depend on type of}

product which is being developed

~ _{For large systems, management is}

usually the principal problem so you need a strictly managed process;

~ _{For smaller systems, more informality}

is possible.

! _{There is no uniformly applicable process}

which should be standardised within an organisation

~ _{High costs may be incurred if you force}

an inappropriate process on a development team;

~ _{Inappropriate methods can also}

increase costs and lead to reduced quality.

Process tool support

Informal

process Managedprocess Methodicalprocess Improvingprocess

Specialised tools Analysis and design workbenches Project management tools Configuration management tools Generic tools

Process

measurement

! _{Wherever possible, quantitative process}

data should be collected

~ _{However, where organisations do not}

have clearly defined process standards this is very difficult as you don"t know what to measure. A process may have to be defined before any measurement is possible.

! _{Process measurements should be used}

to assess process improvements

~ _{But this does not mean that}

measurements should drive the improvements. The improvement driver should be the organisational

objectives.

61

Classes of process

measurement

!_{Time taken for process activities to be}

completed

~ _{E.g. Calendar time or effort to complete}

an activity or process.

!_{Resources required for processes or}

activities

~ _{E.g. Total effort in person-days.}

!_{Number of occurrences of a particular}

event

~ _{E.g. Number of defects discovered.}

62

Goal-Question-Metric

Paradigm

! _Goals

~ _{What is the organisation trying to}

achieve? The objective of process improvement is to satisfy these goals.

! _Questions

~ _{Questions about areas of uncertainty}

related to the goals. You need process knowledge to derive these.

! _Metrics

~ _{Measurements to be collected to}

answer the questions.

Process analysis and

modelling

!_{Process analysis}

~ _{The study of existing processes to}

understand the relationships between parts of the process and to compare them with other processes.

!_{Process modelling}

~ _{The documentation of a process which}

records the tasks, the roles and the entities used;

~ _{Process models may be presented}

Process analysis and

modelling

! _{Study an existing process to understand}

its activities.

! _{Produce an abstract model of the}

process. You should normally represent this graphically. Several different views (e.g. activities, deliverables, etc.) may be required.

! _{Analyse the model to discover process}

problems. This involves discussing process activities with stake-holders and discovering problems and possible process changes.

65

Process analysis

techniques

!_{Published process models and process}

standards

~ _{It is always best to start process}

analysis with an existing model. People then may extend and change this.

!_{Questionnaires and interviews}

~ _{Must be carefully designed.}

Participants may tell you what they think you want to hear.

!_{Ethnographic analysis}

~ _{Involves assimilating process}

knowledge by observation. Best for in-depth analysis of process fragments rather than for whole-process understanding. 66

Process model

elements 1

Activity (shown as a round-edged rectangle with no drop shadow)

An activity has a clearly defined objective, entry and exit conditions. Examples of activities are preparing a set of test data to test a module, coding a fu nction or a module, proof-reading a document, etc. Generally, an activity is atomic i.e. it is the responsibility of one person or group. It is not decomposed into sub-activities.

Process (shown as a round-edged rectangle with drop shadow)

A p rocess is a set of activities which have some coherence and whose objective is generally agreed within an organisation. Examples of processes are requirements analysis, architectural design, test planning, etc.

Deliverable (shown as a rectangle with drop shadow)

A deliverable is a tangible output of an activity that is predicted in a project plan.

Condition (shown as a parallelogram )

A condition is either a pre-condition that must hold before a process or activity can start or a post-condition that holds after a process or activity has finished.

Process model

elements 2

Role (shown as a circle with drop shadow)

A role is a bounded area of responsibility. Examples of roles might be configuration manager, test engineer, software designer, etc. One person may have several different roles and a s ingle role may be associated with several different people.

Exception (not shown in examples here but may be represented as a double edged box)

An exception is a description of how to modify the process if some anticipated or unanticipated event occurs. Exceptions are often undefined and it is left to the ingenuity of the project managers and engineers to handle the exception.

Communication (shown as an arrow)

An interchange of information between people or between people and supporting computer systems. Communications may be informal or formal. Formal communications might be the approval of a deliverable by a p roject manager; informal communications might be the interchange of electronic mail to resolve ambiguities in a document.

The module testing

activity

Test module Signed-off test record Module test data Module specification Module compiles without syntax errors

All defined tests run on module Test engineer Pre-condition Input Process Role Post-condition Outputs Responsible for 69

Activities in module

testing

Prepare test data according to specification Read module

specification Submit test datafor review Review test data TEST DATA PREPARATION

Read and understand module interface Checkout module

from configuration management system

Prepare test harness for module Compile testharness MODULE TEST HARNESS PREPARATION

Incorporate module with test harness

Run approved tests on module

Record test results for regression tests TEST EXECUTION

Write report on module testing including details of discovered problems

Submit report for approval results to CMSubmit test TEST REPORTING

70

Process exceptions

! _{Software processes are complex and}

process models cannot effectively represent how to handle exceptions:

~ _{Several key people becoming ill just}

before a critical review;

~ _{A breach of security that means all}

external communications are out of action for several days;

~ _{Organisational reorganisation;}

~ _{A need to respond to an unanticipated}

request for new proposals.

! _{Under these circumstances, the model is}

suspended and managers use their initiative to deal with the exception.

Process change

!_{Involves making modifications to existing}

processes.

!_{This may involve:}

~ _{Introducing new practices, methods or}

processes;

~ _{Changing the ordering of process}

activities;

~ _{Introducing or removing deliverables;}

~ _{Introducing new roles or}

responsibilities.

!_{Change should be driven by measurable}

The process change

process

Process

model Process changeplan Trainingplan improvementsFeedback on Revised processmodel Identify

improvements improvementsPrioritise process changesTune Introduce process change Train engineers 73

Process change

stages

!_{Improvement identification.} !_{Improvement prioritisation.}

!_{Process change introduction.}

!_{Process change training.}

!_{Change tuning.}

74

The CMMI framework

! _{The CMMI framework is the current}

stage of work on process assessment and improvement that started at the Software Engineering Institute in the 1980s.

! _{The SEI"s mission is to promote software}

technology transfer particularly to US defence contractors.

! _{It has had a profound influence on}

process improvement

~ _{Capability Maturity Model introduced in}

the early 1990s.

~ _{Revised maturity framework (CMMI)}

introduced in 2001.

Process capability

assessment

!_{Intended as a means to assess the}

extent to which an organisation"s processes follow best practice.

!_{My providing a means for assessment, it}

is possible to identify areas of weakness for process improvement.

!_{There have been various process}

assessment and improvement models but the SEI work has been most influential.

! _Initial

~ _{Essentially uncontrolled}

! _Repeatable

~ _{Product management procedures}

defined and used

! _Defined

~ _{Process management procedures and}

strategies defined and used

! _Managed

~ _{Quality management strategies defined}

and used

! _Optimising

~ _{Process improvement strategies}

defined and used

The SEI capability

maturity model

77

Problems with the

CMM

!_{Practices associated with model levels}

~ _{Companies could be using practices}

from different levels at the same time but if all practices from a lower level were not used, it was not possible to move beyond that level

!_{Discrete rather than continuous}

~ _{Did not recognise distinctions between}

the top and the bottom of levels

!_{Practice-oriented}

~ _{Concerned with how things were done}

(the practices) rather than the goals to be achieved.

78

The CMMI model

! _{An integrated capability model that}

includes software and systems engineering capability assessment.

! _{The model has two instantiations}

~ _{Staged where the model is expressed}

in terms of capability levels;

~ _{Continuous where a capability rating is}

computed.

CMMI model

components

!_{Process areas}

~ _{24 process areas that are relevant to}

process capability and improvement are identified. These are organised into 4 groups.

!_Goals

~ _{Goals are descriptions of desirable}

organisational states. Each process area has associated goals.

!_Practices

~ _{Practices are ways of achieving a goal}

-- however, they are advisory and other approaches to achieve the goal may be used.

CMMI process areas

1

Process management Organisational process definition Organisational process focus Organisational training Organisational process performance Organisational innovation and deployment Project management Project planning

Project monitoring and control Supplier agreement management Integrated project management Risk management Integrated teaming Quantitative project management

81

CMMI process areas

2

Engineering Requirements management

Requirements development Technical solution Product integration Verification Validation

Support Configuration management

Process and product quality management Measurement and analysis Decision analysis and resolution Organisational environment for integration Causal analysis and resolution

82

CMMI goals

Goal Process area

Corrective actions are managed to closure when the project’s performance or results deviate significantly from the plan.

Specific goal in Project Monitoring and Control

Actual performance and progress of the project is monitored against the project plan.

Specific goal in project monitoring and control The requirements are analysed and

validated and a definition of the required functionality is developed.

Specific goal in requirements development. Root causes of defects and other

problems are systematically determined. Specific goal in causalanalysis and resolution. The process is institutionalised as a

defined process. Generic goal

CMMI practices

Practice Associated goal Analyse derived requirements to ensure that they are necessary and sufficient

Validate requirements to ensure that the resulting product will perform as intended in the user’s environment using multiple techniques as appropriate.

The requirements are analysed and validated and a definition of the required functionality is developed.

Select the defects and other problems for analysis. Perform causal analysis of selected defects and other problems and propose actions to address them.

Root causes of defects and other problems are systematically determined.

Establish and maintain an organisational policy for planning and performing the requirements development process.

Assign responsibility and authority for performing the process, developing the work products and providing the services of the requirements development process.

The process is institutionalised as a defined process.

CMMI assessment

! _{Examines the processes used in an}

organisation and assesses their maturity in each process area.

! _{Based on a 6-point scale:}

~ _{Not performed;} ~ _Performed; ~ _Managed; ~ _Defined; ~ _{Quantitatively managed;} ~ _Optimizing. 85

The staged CMMI

model

!_{Comparable with the software CMM.}

!_{Each maturity level has process areas}

and goals. For example, the process area associated with the managed level include:

~ _{Requirements management;}

~ _{Project planning;}

~ _{Project monitoring and control;}

~ _{Supplier agreement management;}

~ _{Measurement and analysis;}

~ _{Process and product quality}

assurance.

86

The staged CMMI

model

Level 3 Defined Level 2 Managed Level 1 Initial Level 4 Quantitatively managed Level 5 Optimizing

Institutional practices

!_{Institutions operating at the managed}

level should have institutionalised practices that are geared to standardisation.

~ _{Establish and maintain policy for}

performing the project management process;

~ _{Provide adequate resources for}

performing the project management process;

~ _{Monitor and control the project}

planning process;

~ _{Review the activities, status and}

The continuous CMMI

model

! _{This is a finer-grain model that considers}

individual or groups of practices and assesses their use.

! _{The maturity assessment is not a single}

value but is a set of values showing the organisations maturity in each area.

! _{The CMMI rates each process area from}

levels 1 to 5.

! _{The advantage of a continuous}

approach is that organisations can pick and choose process areas to improve according to their local needs.

89

A process capability

profile

Project monitoring and control Supplier agreement management Risk management Configuration management Requirements management Verification Validation 1 2 3 4 5 90

End of Today

"

s

Lecture