Corso di Laurea Magistrale
in
Ingegneria Informatica
Module B-Software Systems
Engineering
a.a. 2012-2013
Gigliola Vaglini
11
Quality management
Lecture 6
1
Software Quality Fundamentals
• Software engineers are expected to share a
•
commitment to software quality as part of their
culture.
Ethics can play a significant role in software quality,
the culture, and the attitudes of software engineers.
The IEEE Computer Society and the ACM [IEEE99]
have developed a code of ethics and professional
practice based on eight principles to help software
engineers reinforce attitudes related to quality and
to the independence of their work.
3
Cont.
• For any engineered product, there are many
•
desired qualities relevant to a particular
perspective of the product, to be discussed
and determined at the time that the product
requirements are set down.
Quality characteristics may be required or
not, or may be required to a greater or lesser
degree, and trade-offs may be made among
them.
4
2
Software quality management
 Concerned with ensuring that the required level of quality
is achieved in a software product.
 Three principal concerns:
 At the organizational level, quality management is concerned
with establishing a framework of organizational processes and
standards that will lead to high-quality software.
 At the project level, quality management involves the application
of specific quality processes and checking that these planned
processes have been followed.
 At the project level, quality management is also concerned with
establishing a quality plan for a project. The quality plan should
set out the quality goals for the project and define what
processes and standards are to be used.
5
5
Quality management activities
 Quality management provides an independent check on
the software development process.
 The quality management process checks the project
deliverables to ensure that they are consistent with
organizational standards and goals
 The quality team should be independent from the
development team so that they can take an objective
view of the software. This allows them to report on
software quality without being influenced by software
development issues.
6
6
3
Quality management and
software development
7
7
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.
8ì
4
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.
ì
9ì
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.
ì
10ì
5
Software 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 incomplete and often
inconsistent.
 The focus may be ‘fitness for purpose’ rather than
specification conformance.
ì
11ì
Software fitness for purpose
 Have programming and documentation standards been
followed in the development process?
 Has the software been properly tested?
 Is the software sufficiently dependable to be put into
use?
 Is the performance of the software acceptable for normal
use?
 Is the software usable?
 Is the software well-structured and understandable?
ì
12
6
Software quality attributes
Safety
Understandability
Portability
Security
Testability
Usability
Reliability
Adaptability
Reusability
Resilience
Modularity
Efficiency
Robustness
Complexity
Learnability
13
Quality conflicts
 It is not possible for any system to be optimized for all of
these attributes – for example, improving robustness
may lead to loss of performance.
 The quality plan should therefore define the most
important quality attributes for the software that is being
developed.
 The plan should also include a definition of the quality
assessment process, an agreed way of assessing
whether some quality, such as maintainability or
robustness, is present in the product.
14
7
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.
 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.
15
Process-based quality
16
8
Software standards
 Standards define the required attributes of a product or
process. They play an important role in quality
management.
 Standards may be international, national, organizational
or project standards.
 Product standards define characteristics that all software
components should exhibit e.g. a common programming
style.
 Process standards define how the software process
should be enacted.
17
Importance of standards
 Encapsulation of best practice- avoids repetition of past
mistakes.
 They are a framework for defining what quality means in
a particular setting i.e. that organization’s view of quality.
 They provide continuity - new staff can understand the
organisation by understanding the standards that are
used.
18
9
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 form
filling work is often involved to maintain the
documentation associated with the standards.
19
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 specialized tool
support. Excessive clerical work is the most
significant complaint against standards.
 Web-based forms are not good enough.
20
10
ISO 9001 standards framework
 An international set of standards that can be used as a
basis for developing quality management systems.
 ISO 9001, the most general of these standards, applies
to organizations that design, develop and maintain
products, including software.
 The ISO 9001 standard is a framework for developing
software standards.
 It sets out general quality principles, describes quality processes
in general and lays out the organizational standards and
procedures that should be defined. These should be
documented in an organizational quality manual.
21
ISO 9001 core processes
22
11
ISO 9001 and quality
management
23
ISO 9001 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.
24
12
Standard di processo
25
Process quality:ISO 12207
• The International Standard was published
August 1, 1995. The following (17) countries
participated in the development of the
standard: Australia, Brazil, Canada, Czech
Republic, Denmark, Finland, France, Germany,
Ireland, Italy, Japan, Korea, The
Netherlands, Spain, Sweden, the United
Kingdom, and the United States of America.
26
13
Architecture
• The architecture is built with a set of
processes and interrelationships among these
processes.
• Not only one process
27
Processes characteristics
• Modularity. The processes are modular;
that is, they are maximally cohesive and
minimally coupled to the practical
extent feasible. An individual process is
dedicated to a unique function.
• Responsibility. A process is considered
to be the responsibility of a party in the
software life cycle. In other words,
each party has certain responsibilities.
28
14
Processes structure
• Each process is further designed in
terms of its own constituent activities,
each of which is further designed in
terms of its constituent tasks.
• An activity under a process is a set of
cohesive tasks.
• A task is a set of elementary or atomic
actions. A task consumes inputs (data,
information, control) and produces
outputs (data, information, control).
29
Process hierarchy
30
15
The model
• There are defined 17 Processes (+ 1
“special” process)
• 74 Activities
• 224 Tasks
– Each task is defined by requirements,
selfdeclaration, recommendation,
permissible action
31
Cont.
• The processes are grouped into three broad classes:
•
•
•
primary; supporting; and organizational.
Primary processes are the prime movers in the life
cycle; they are acquisition, supply, development,
operation, and maintenance.
Supporting processes are documentation,
configuration management, quality assurance, joint
review, audit, verification, validation, and problem
resolution. A supporting process supports another
process in performing a specialized function.
Organizational processes are management,
infrastructure, improvement, and training. An
organization may employ an organizational process to
establish, control, and improve a life cycle process.
32
16
Processes hierarchy
33
The tailoring process
• Tailoring is deletion of non-applicable or
in-effective processes, activities, and
tasks.
• A process, an activity, or a task, that is
not contained in the standard but is
pertinent to a project, may be included
in the agreement or contract.
• It should be noted that this process
itself, however, cannot be tailored.
34
17
Primary processes
• Acquisition Process. This process defines the
•
activities and tasks of the acquirer, that
contractually acquires software product or service.
The acquirer represents the needs and requirements
of the users.
Supply Process. This process contains the activities
and tasks of the supplier. The process may be
initiated either by a decision to prepare a proposal to
answer an acquirer's request for proposal or by
signing and entering into a contract or an agreement
with the acquirer to provide a software service. The
process continues with the identification of
procedures and resources needed to manage and
assure the service.
35
Primary processes
• Development Process. This process contains
the activities and tasks of the developer of
software. The development process is
intended to be employed as a methodology for
developing prototypes (or for studying the
requirements and design of a product) or as a
process to produce products.
36
18
Primary processes
• Operation Process. This process contains the
•
activities and tasks of the operator of a software
system. The process covers the operation of the
software and operational support to users.
Maintenance Process. The maintenance process
contains the activities and tasks of the maintainer.
This process is activated when a system undergoes
modifications to code and associated documentation
due to an error, or the need for an improvement or
adaptation. The objective is to modify an existing
system while preserving its integrity. Whenever a
software product needs modifications, the
development process is invoked to effect and
complete the modifications properly. The process
ends with the retirement of the system.
37
Support processes
• Documentation Process. This is a process for
recording information produced by a life cycle
process. The process defines the activities,
which plan, design, develop, edit, distribute
and maintain those documents needed by all
concerned such as managers, engineers and
users of the system.
38
19
Support processes
• Configuration Management Process. This
process is employed to identify, define, and
baseline software items in a system; to
control modifications and releases of the
items; to record and report the status of the
items and modification requests; to ensure
the completeness and correctness of the
items; and to control storage, handling and
delivery of the items.
39
Support processes
• Verification Process. This process provides the
•
evaluations related to verification of a product or
service of a given activity. Verification determines
whether the requirements for a system are complete
and correct and that the outputs of an activity fulfill
the requirements or conditions imposed on them in
the previous activities. The process covers
verification of process, requirements, design, code,
integration, and documentation.
Validation Process. Validation determines whether
the final, as-built system fulfills its specific intended
use. The extent of validation depends upon the
project's criticality.
40
20
Support processes
• Joint Review Process. This process
provides the framework for interactions
between the reviewer and the reviewee.
They may as well be the acquirer and
the supplier respectively. At a joint
review, the reviewee presents the
status and products to the reviewer for
comment (or approval).
41
Support processes
• Quality Assurance Process. This process provides
•
the framework for independently and objectively
assuring (the acquirer or the customer) of compliance
of products or services with their contractual
requirements and adherence to their established
plans. To be unbiased, software quality assurance is
provided with the organizational freedom from
persons directly responsible for developing the
products or providing the services.
Audit Process. This process provides the framework
for formal, contractually established audits of a
supplier's products or services. At an audit, the
auditor assesses the auditee's products and activities
with emphasis on compliance to requirements and
plans. An audit may well be conducted by the acquirer
on the supplier.
42
21
Support processes
• Problem Resolution Process. This process
provides the mechanism for instituting a
closed-loop process for resolving problems
and taking corrective actions to remove
problems as they are detected. In addition,
the process requires identification and
analysis of causes and reversal of trends in
the reported problems. The term "problem"
includes non-conformance.
43
Organizational processes
• Management Process. This process defines the
•
generic activities and tasks of the manager of a
software life cycle process, such as the acquisition
process, supply process, operation process,
maintenance process, or supporting process.
Infrastructure Process. This process defines the
activities needed for establishing and maintaining an
underlying infrastructure for a life cycle process.
This process has the following activities: Process
implementation; Establishment of the infrastructure;
and Maintenance of the infrastructure. The
infrastructure may include hardware, software,
standards, tools, techniques, and facilities.
44
22
Organizational processes
• Improvement Process. The standard provides the
•
basic, top-level activities that an organization (that
is, acquisition, supply, development, operation,
maintenance, or a supporting process) needs to
assess, measure, control, and improve its life cycle
process.
Training Process. This process may be used for
identifying and making timely provision for acquiring
or developing personnel resources and skills at the
management and technical levels. The process
requires that a training plan be developed, training
material be generated, and training be provided to
the personnel in a timely manner.
45
Processi primari
23
Acquisition process
47
Acquisition process
48
24
Supply process
49
Development process
50
25
Operation process
51
Maintenance process
52
26
Esempio di analisi approfondita
• Esercizio: analisi dell’attività dell’
acquisition process
53
54
27
Attività di Initiation
55
Attività di Initiation
56
28
Attività di Initiation
57
Attività di Request for proposal
58
29
Attività di Preparazione e update
del contratto
59
Attività di Monitoraggio
60
30
Attività di Acceptance e
completion
61
62
31
Cosa la norma non dice
63
Limiti della norma
64
32
Product quality and process
quality
• Quality can be seen from the point of
view of the resulting software product
and from the point of view of the
production process
• There are standard for both the
aspects, even if to state the quality of
software product is a bit dangerous.
65
Standard specifici di prodotto
• Esistono per alcune categorie di
prodotti:
– compilatori
– protocolli di comunicazione
66
33
Primo modello di qualità
• Il primo modello (McCall 1977) si basava su
•
•
•
tre usi di un prodotto sw:
Da utente (si ha una vista esterna del sw)
Da sviluppatore (si ha una vista interna del sw)
Da controllore (si ha bisogno di scale e metodi
di misura)
67
Modello attuale
• La necessità di uno standard di qualità
porta alla introduzione dell’ISO/IEC
9126 (prima versione 1991)
• An attempt to give a schema for defining the
software product quality.
68
34
Il modello ISO 9126
69
L'approccio alla qualità della
norma
• la qualità del processo contribuisce a
•
•
•
migliorare la qualità del prodotto
la qualità del prodotto contribuisce a
migliorare la qualità in uso
controllare e migliorare il processo è un
mezzo per migliorare la qualità del prodotto
valutare e migliorare la qualità del prodotto
migliora la qualità in uso
70
35
• Fa distinzione fra attributi che caratterizzano la qualità vista
dall’utente ed attributi che caratterizzano la qualità vista in
produzione
– caratteristiche esterne
– caratteristiche interne
• Il modello ha tre livelli
– Caratteristiche
– Sottocaratteristiche
– Metriche
• Le caratteristiche esterne sono organizzate in 2 livelli
– … le caratteristiche del secondo livello sono in relazione con quelle
del primo in base ad una gerarchia che definisce i legami
– … le caratteristiche del secondo livello sono anche in relazione con le
caratteristiche interne
71
Product quality: ISO 9126
• Six basic characteristics are defined from
the point of view of the user:
–
–
–
–
–
–
Functionality
Reliability
Usability
Efficiency
Maintainability
Portability
72
36
External characteristics and subcharacteristics
73
Quality evaluation
• Each sub-characteristic must be
associated with a metric to be
quantitatively evaluated
74
37
ISO 9126 (cont.)
75
Quality in use
• Quality in use: specific users through
the software product are able to obtain
specific objectives with effectiveness,
productivity, safety and satisfaction in
a specific operational environment
• It was introduced in the release 1.2
76
38
77
78
39
79
80
40
81
82
41
83
Metriche per la manutenibilità
84
42
Internal characteristics
• Internal characteristics are 38
and are bind to the external
sub-characteristics
•
•
•
•
•
•
•
•
•
•
•
•
•
Completness
Access control
Informativeness
Self-descriptiveness
Instrumentability
Expressiveness
Data-commonality
Self-containedness
Communication-commonality
Well-equipmentness
Traceability
Timeliness
Robustness
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Integrity
Modularity
Simplicity
Coherency
Accessibility
Uniformity
Accuracy
Hierarchieness
Consistency
Metaphorability
Attractiveness
Access audit
Memorability
Conciseness
Choosability
Guideability
85
86
43
Limiti dei modelli di qualità
87
Conclusioni
88
44
Conclusioni
89
90
45
Reviews and inspections
 A group examines part or all of a process or system and
its documentation to find potential problems.
 Software or documents may be 'signed off' at a
review which signifies that progress to the next
development stage has been approved by
management.
 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 standards).
91
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.
92
46
The software review process
93
Reviews and agile methods
 The review process in agile software development is
usually informal.
 In Scrum, for example, there is a review meeting after each
iteration of the software has been completed (a sprint review),
where quality issues and problems may be discussed.
 In extreme programming, pair programming ensures that
code is constantly being examined and reviewed by
another team member.
 XP relies on individuals taking the initiative to improve
and refactor code. Agile approaches are not usually
standards-driven, so issues of standards compliance are
not usually considered.
94
47
Program inspections
 These are peer reviews where engineers examine the
source of a system with the aim of discovering
anomalies and defects.
 Inspections do not require execution of a system so may
be used before implementation.
 They may be applied to any representation of the system
(requirements, design,configuration data, test data, etc.).
 They have been shown to be an effective technique for
discovering program errors.
95
Inspection checklists
 Checklist of common errors should be used to
drive the inspection.
 Error checklists are programming language
dependent and reflect the characteristic errors that are
likely to arise in the language.
 In general, the 'weaker' the type checking, the larger the
checklist.
 Examples: Initialisation, Constant naming, loop
termination, array bounds, etc.
96
48
An inspection checklist (a)
Fault class
Inspection check
Data faults
 Are all program variables initialized before their values are used?
 Have all constants been named?
 Should the upper bound of arrays be equal to the size of the
Control faults
Input/output faults







array or Size -1?
If character strings are used, is a delimiter explicitly assigned?
Is there any possibility of buffer overflow?
For each conditional statement, is the condition correct?
Is each loop certain to terminate?
Are compound statements correctly bracketed?
In case statements, are all possible cases accounted for?
If a break is required after each case in case statements, has it
been included?
 Are all input variables used?
 Are all output variables assigned a value before they are output?
 Can unexpected inputs cause corruption?
97
An inspection checklist (b)
Fault class
Inspection check
Interface faults
 Do all function and method calls have the correct number
of parameters?
 Do formal and actual parameter types match?
 Are the parameters in the right order?
 If components access shared memory, do they have the
same model of the shared memory structure?
Storage
faults
management
 If a linked structure is modified, have all links been
correctly reassigned?
 If dynamic storage is used, has space been allocated
correctly?
 Is space explicitly deallocated after it is no longer
required?
Exception
faults
management
 Have all possible error conditions been taken into
account?
98
49
Agile methods and inspections
 Agile processes rarely use formal inspection or peer
review processes.
 Rather, they rely on team members cooperating to check
each other’s code, and informal guidelines, such as
‘check before check-in’, which suggest that programmers
should check their own code.
 Extreme programming practitioners argue that pair
programming is an effective substitute for inspection as
this is, in effect, a continual inspection process.
 Two people look at every line of code and check it before
it is accepted.
99
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.
100
50
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 persondays 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.
101
Use of measurements
 To assign a value to system quality attributes
 By measuring the characteristics of system components, such as
their cyclomatic complexity, and then aggregating these
measurements, you can assess system quality attributes, such
as maintainability.
 To identify the system components whose quality is substandard
 Measurements can identify individual components with
characteristics that deviate from the norm. For example, you can
measure components to discover those with the highest
complexity. These are most likely to contain bugs because the
complexity makes them harder to understand.
102
51
Metrics assumptions
 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.
103
Problems with measurement in
industry
 It is impossible to quantify the return on investment of
introducing an organizational metrics program.
 There are no standards for software metrics or standardized
processes for measurement and analysis.
 In many companies, software processes are not standardized
and are poorly defined and controlled.
 Most work on software measurement has focused on codebased metrics and plan-driven development processes.
However, more and more software is now developed by
configuring ERP systems or COTS.
 Introducing measurement adds additional overhead to
processes.
104
52
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.
105
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.
106
53
Static software product
metrics
Software metric
Description
Fan-in/Fan-out
Fan-in is a measure of the number of functions or
methods that call another 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 is 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 may 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.
107
Static software product
metrics
Software metric
Description
Cyclomatic complexity This is a measure of the control complexity of a program.
This control complexity may be related to program
understandability. I discuss cyclomatic complexity in
Chapter 8.
Length of identifiers
This is a measure of the average length of identifiers
(names for variables, classes, methods, etc.) in a
program. The longer the identifiers, the more likely they
are to be meaningful 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 if-statements are hard to
understand and potentially error-prone.
Fog index
This is a measure of the average length of words and
sentences in documents. The higher the value of a
document’s Fog index, the more difficult the document is
to understand.
108
54
The object-oriented metrics
Object-oriented
metric
Description
Weighted methods
per class (WMC)
This is the number of methods in each 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 difficult
to understand. They may not be logically cohesive, so cannot be reused
effectively as superclasses in an inheritance tree.
Depth of inheritance This represents the number of discrete levels in the inheritance tree where
tree (DIT)
subclasses inherit attributes and operations (methods) from superclasses. The
deeper the inheritance tree, the more complex the design. Many object classes
may have to be understood to understand the object classes at the leaves of the
tree.
Number of children
(NOC)
This is a measure of the number of immediate subclasses in a class. It measures
the breadth of a class hierarchy, whereas DIT measures its depth. A high value
for NOC may indicate greater reuse. It may mean that more effort should be
made in validating base classes because of the number of subclasses that
depend on them.
109
The object-oriented metrics
Object-oriented
metric
Description
Coupling between
object classes
(CBO)
Classes are coupled when methods in one class use methods or instance
variables defined in a different class. CBO is a measure of how much coupling
exists. A high value for CBO means that classes are highly dependent, and
therefore it is more likely that changing one class will affect other classes in the
program.
Response for a
class (RFC)
RFC is a measure of the number of methods that could potentially be executed
in response to a message received by an object of that class. Again, RFC is
related to complexity. The higher the value for RFC, the more complex a class
and hence the more likely it is that it will include errors.
Lack of cohesion in
methods (LCOM)
LCOM is calculated by considering pairs of methods in a class. LCOM is the
difference between the number of method pairs without shared attributes and the
number of method pairs with shared attributes. The value of this metric has been
widely debated and it exists in several variations. It is not clear if it really adds
any additional, useful information over and above that provided by other metrics.
110
55
Software component analysis
 System component can be analyzed separately using a
range of metrics.
 The values of these metrics may then compared for
different components and, perhaps, with historical
measurement data collected on previous projects.
 Anomalous measurements, which deviate significantly
from the norm, may imply that there are problems with
the quality of these components.
111
The process of product
measurement
112
56
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.
113
La qualità totale
57
Vari aspetti della qualità
115
La qualità totale
• Il concetto di Qualità è legato alla definizione di Qualità di Prodotto
tramite:
–
–
–
–
–
un’accurata scelta delle materie prime
un’attenta fase di progettazione
l’utilizzo di maestranze esperte e qualificate
tecniche di lavorazione orientate all’eccellenza del risultato
un severo ed efficace Controllo Qualità
• Il concetto di Qualità Totale o TQM (Total Quality Management) sta
•
•
invece ad indicare che i concetti e le tecniche del Controllo Qualità
devono essere estesi ed applicati a tutti i settori aziendali (CWQC =
Company Wide Quality Control) con l’obiettivo di raggiungere
l’eccellenza.
La Qualità Totale rappresenta un potente strumento di gestione per
raggiungere gli obiettivi dell’organizzazione.
Si passa da una visione a breve termine di “Profitto prima di tutto” ad
una a più lungo termine di “Qualità prima di tutto”.
116
58
La qualità totale
• La qualità di un sistema software è largamente
•
determinata dalla qualità del processo usato per la sua
produzione e manutenzione.
TQM pone al centro dell’attenzione i processi, in
particolare è l’applicazione di metodi quantitativi e di
risorse umane per il miglioramento:
– dei materiali e dei servizi usati da un’organizzazione;
– di tutti i processi che si sviluppano nell’organizzazione;
– del livello con il quale vengono soddisfatti i bisogni del
cliente.
117
Cambio di mentalità in azienda
118
59
La pianificazione della qualità
119
La pianificazione della qualità
120
60
L’assicurazione della qualità
121
L’assicurazione della qualità
122
61
Il controllo della qualità
123
Improvement models
Lecture 7
62
Process improvement
 Many software companies have turned to software
process improvement as a way of enhancing the quality
of their software, reducing costs or accelerating their
development processes.
 Process improvement means understanding existing
processes and changing these processes to increase
product quality and/or reduce costs and development
time.
125
Approaches to improvement
 The process maturity approach, which focuses on
improving process and project management and
introducing good software engineering practice.
 The level of process maturity reflects the extent to which good
technical and management practice has been adopted in
organizational software development processes.
 The agile approach, which focuses on iterative
development and the reduction of overheads in the
software process.
 The primary characteristics of agile methods are rapid delivery of
functionality and responsiveness to changing customer
requirements.
126
63
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.
 For manufactured goods, process is the principal quality
determinant.
 For design-based activities, other factors are also
involved, especially the capabilities of the designers.
127
Factors affecting software
product quality
128
64
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 imposed then
product quality will suffer.
129
Process improvement process
 There is no such thing as an ‘ideal’ or ‘standard’ software
process that is applicable in all organizations or for all
software products of a particular type.
 You will rarely be successful in introducing process
improvements if you simply attempt to change the process to
one that is used elsewhere.
 You must always consider the local environment and culture and
how this may be affected by process change proposals.
 Each company has to develop its own process
depending on its size, the background and skills of its
staff, the type of software being developed, customer
and market requirements, and the company culture.
130
65
Improvement attributes
 You also have to consider what aspects of the process
that you want to improve.
 Your goal might be to improve software quality and so
you may wish to introduce new process activities that
change the way software is developed and tested.
 You may be interested in improving some attribute of the
process itself (such as development time) and you have
to decide which process attributes are the most
important to your company.
131
Process attributes
Process
characteristic
Key issues
Understandability To what extent is the process explicitly defined and how easy is it to
understand the process definition?
Standardization
To what extent is the process based on a standard generic process?
This may be important for some customers who require
conformance with a set of defined process standards. To what extent
is the same process used in all parts of a company?
Visibility
Do the process activities culminate in clear results, so that the
progress of the process is externally visible?
Measurability
Does the process include data collection or other activities that allow
process or product characteristics to be measured?
Supportability
To what extent can software tools be used to support the process
activities?
132
66
Process attributes
Process
characteristic
Key issues
Acceptability
Is the 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 organizational requirements
or identified process improvements?
Rapidity
How fast can the process of delivering a system from a given
specification be completed?
133
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.
134
67
The process improvement cycle
135
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
organizational objectives.
136
68
Process metrics
 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.
137
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.
138
69
GQM questions
 The GQM paradigm is used in process improvement to
help answer three critical questions:
 Why are we introducing process improvement?
 What information do we need to help identify and assess
improvements?
 What process and product measurements are required to
provide this information?
139
The GQM paradigm
140
70
Process analysis
 The study of existing processes to understand the
relationships between parts of the process and to
compare them with other processes.
 Process analysis and process measurement are
intertwined.
 You need to carry out some analysis to know what to
measure, and, when making measurements, you
inevitably develop a deeper understanding of the
process being measured.
141
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 wholeprocess understanding.
142
71
Aspects of process analysis
Process
aspect
Adoption and
standardization
Software
engineering
practice
Organizational
constraints
Questions
Is the process documented and standardized across the
organization? If not, does this mean that any measurements
made are specific only to a single process instance? If processes
are not standardized, then changes to one process may not be
transferable to comparable processes elsewhere in the company.
Are there known, good software engineering practices that are
not included in the process? Why are they not included? Does the
lack of these practices affect product characteristics, such as the
number of defects in a delivered software system?
What are the organizational constraints that affect the process
design and the ways that the process is performed? For example,
if the process involves dealing with classified material, there may
be activities in the process to check that classified information is
not included in any material due to be released to external
organizations. Organizational constraints may mean that possible
process changes cannot be made.
143
Aspects of process analysis
Process aspect
Questions
Communications
How are communications managed in the process? How do
communication issues relate to the process measurements that have
been made? Communication problems are a major issue in many
processes and communication bottlenecks are often the reasons for
project delays.
Is the process reflective (i.e., do the actors involved in the process
explicitly think about and discuss the process and how it might be
improved)? Are there mechanisms through which process actors can
propose process improvements?
How do people joining a development team learn about the software
processes used? Does the company have process manuals and
process training programs?
What aspects of the process are and aren’t supported by software
tools? For unsupported areas, are there tools that could be deployed
cost-effectively to provide support? For supported areas, are the tools
effective and efficient? Are better tools available?
Introspection
Learning
Tool support
144
72
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 goals.
145
The process change process
146
73
Process change stages
 Improvement identification
 This stage is concerned with using the results of the process
analysis to identify ways to tackle quality problems, schedule
bottlenecks or cost inefficiencies that have been identified during
process analysis.
 Improvement prioritization
 When many possible changes have been identified, it is usually
impossible to introduce them all at once, and you must decide
which are the most important.
 Process change introduction
 Process change introduction means putting new procedures,
methods and tools into place and integrating them with other
process activities.
147
Process change stages
 Process change training
 Without training, it is not possible to gain the full benefits of
process changes. The engineers involved need to understand
the changes that have been proposed and how to perform the
new and changed processes.
 Change tuning
 Proposed process changes will never be completely effective as
soon as they are introduced. You need a tuning phase where
minor problems can be discovered, and modifications to the
process can be proposed and introduced.
148
74
Process change problems
 Resistance to change
 Team members or project managers may resist the introduction
of process changes and propose reasons why changes will not
work, or delay the introduction of changes. They may, in some
cases, deliberately obstruct process changes and interpret data
to show the ineffectiveness of proposed process change.
 Change persistence
 While it may be possible to introduce process changes initially, it
is common for process innovations to be discarded after a short
time and for the processes to revert to their previous state.
149
Resistance to change
 Project managers often resist process change because
any innovation has unknown risks associated with it.
 Project managers are judged according to whether or not their
project produces software on time and to budget. They may
prefer an inefficient but predictable process to an improved
process that has organizational benefits, but which has shortterm risks associated with it.
 Engineers may resist the introduction of new processes
for similar reasons, or because they see these
processes as threatening their professionalism.
 That is, they may feel that the new pre-defined process gives
them less discretion and does not recognize the value of their
skills and experience.
150
75
Change persistence
 The problem of changes being introduced then
subsequently discarded is a common one.
 Changes may be proposed by an ‘evangelist’ who believes
strongly that the changes will lead to improvement. He or she
may work hard to ensure the changes are effective and the new
process is accepted.
 If the ‘evangelist’ leaves, then the people involved may therefore
simply revert to the previous ways of doing things.
 Change institutionalization is important
 This means that process change is not dependent on individuals
but that the changes become part of standard practice in the
company, with company-wide support and training.
151
Maturity models
• A maturity model can be described as a
structured collection of elements that
describe certain aspects of maturity in an
organization, and aids in the definition and
understanding of the organization's
processes and in the organization
improvement.
152
76
Maturity models
• A maturity model may provide, for example :
–
–
–
–
–
a place to start
the benefit of a community’s prior experiences
a common language and a shared vision
a framework for prioritizing actions
a way to define what improvement means for your
organization.
• A maturity model can be used as a benchmark for
comparison and as an aid to understanding - for
example, for comparative assessment of different
organizations where there is something in common
that can be used as a basis for comparison.
153
• The Capability Maturity Model (CMM) is
the most widely used model of
assesment and improvement. Active
development of this model began in
1986 at the Software Engineering
Institute located at Carnegie Mellon
University in Pittsburgh, Pennsylvania on
behalf of DOD and Mitra Corporation.
154
77
The SEI capability maturity
model
 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
155
Capability Maturity Model (CMM)
• The CMM was originally intended as a tool to evaluate
•
•
the ability of government contractors to perform a
contracted software project.
In the case of the CMM the basis for comparison
among organizations would be the organizations'
software development processes.
Though it comes from the area of software
development, it can be, has been, and continues to be
widely applied as a general model of the maturity of
processes.
156
78
Capability Maturity Model
157
Capability Maturity Model Structure
• The Capability Maturity Model involves the
•
•
following aspects:
Maturity Levels: A 5-Level process maturity
continuum - where the uppermost (5th) level
is a notional ideal state where processes
would be systematically managed by a
combination of process optimization and
continuous process improvement.
Key Process Areas: A Key Process Area (KPA)
identifies a cluster of related activities that,
when performed collectively, achieve a set of
goals considered important.
158
79
Struttura dei livelli
• Ciascun livello di maturità è composto da un
•
•
insieme di aree chiavi di processo.
Ciascuna "area chiave" è organizzata in cinque
sezioni dette "Caratteristiche comuni".
Le caratteristiche comuni identificano le
"Pratiche chiavi“ che, quando tutte eseguite,
permettono il raggiungimento dei goal delle
"aree chiavi”.
159
• Ciascuna area chiave definisce un insieme di attività
•
correlate che, quando vengono globalmente sviluppate,
garantiscono che il processo sia al livello di maturità
ad essa associato, … e quindi anche la relativa
capacità.
Queste aree chiave risultano fondamentali ai fini:
– dell’accertamento: se le attività sono sviluppate allora il
processo è al livello associato;
– del miglioramento: se si vuol passare al livello associato si
deve introdurre nel processo lo sviluppo delle attività
associate.
160
80
• In each KPA there are five definitions
identified:
–
–
–
–
–
Goals
Commitment
Ability
Measurement
Verification
• The KPAs are not necessarily unique to CMM,
representing — as they do — the stages that
organizations must go through on the way to
becoming mature.
161
Cont.
• Goals: The goals of a key process area summarize the states
that must exist for that key process area to have been
implemented in an effective and lasting way. The extent to
which the goals have been accomplished is an indicator of how
much capability the organization has established at that
maturity level. The goals signify the scope, boundaries, and
intent of each key process area.
• Common Features: Common features include practices that
implement and institutionalize a key process area. There are five
types of common features: Commitment to Perform, Ability to
Perform, Activities Performed, Measurement and Analysis, and
Verifying Implementation.
• Key Practices: The key practices describe the elements of
infrastructure and practice that contribute most effectively to
the implementation and institutionalization of the KPAs.
162
81
CMM
• The model identifies five levels of process maturity
for an organization:
– Initial (chaotic, ad hoc, heroic) the starting point for use of
a new process.
– Repeatable (project management, process discipline) the
process is used repeatedly.
– Defined (institutionalized) the process is defined/confirmed
as a standard business process.
– Managed (quantified) process management and measurement
takes place.
– Optimizing (process improvement) process management
includes deliberate process optimization/improvement.
163
Capability Maturity Model
• Initial. It is characteristic of processes at this level that they
are (typically) undocumented and in a state of dynamic change,
tending to be driven in an ad hoc, uncontrolled and reactive
manner by users or events. This provides a chaotic or unstable
environment for the processes.
• Requirements flow in. A software product is (usually) produced
by some amorphous process. The product flows out and
(hopefully) works.
• Institutional knowledge tends to be scattered in such
environments, not all of the participants in the processes may
know or understand all of the components that make up the
processes.
164
82
Capability Maturity Model
• Repeatable. Processes and their outputs could be visible to
management at defined points, but results may not always be
consistent. Some basic processes are established to track cost,
schedule, and functionality, and a degree of process discipline is in
place to repeat earlier successes on projects with similar applications
and scope; nevertheless there could still be a significant risk of
exceeding cost and time estimates.
• Requirements and resources flow in. The production of the software
product is visible at defined points. Artifacts of the process are
controlled.
165
Capability Maturity Model
• Defined. There are sets of defined and documented
•
standard processes established and subject to some
degree of improvement over time. These standard
processes are in place and used to establish
consistency of process performance across the
organization.
Roles and responsabilities in the process are
understood. The software product is visible
throughout the software process.
166
83
Capability Maturity Model
• Managed. Using process metrics, management can
•
effectively control the software development. In
particular, management can identify ways to adjust
and adapt the process to particular projects without
measurable losses of quality or deviations from
specifications.
The software production is quantitatively understood
throughout the software process.
167
Capability Maturity Model
• Optimizing. Quantitative process-
•
improvement objectives for the organization
are established, continually revised to reflect
changing business objectives, and used as
criteria in managing process improvement.
The software process is continuously
improved in a controlled manner.
168
84
Capability Maturity Model
• Each level is associated with an
expected performance
• Each level is associated with tools to be
used during the process, for example,
organizational database
169
The CMMI process improvement
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.
170
85
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.
171
Evoluzione del CMM:CMMI
172
86
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.
173
Process areas in the CMMI
Category
Process area
Process management
Organizational process definition (OPD)
Organizational process focus (OPF)
Organizational training (OT)
Organizational process performance (OPP)
Organizational innovation and deployment
(OID)
Project management
Project planning (PP)
Project monitoring and control (PMC)
Supplier agreement management (SAM)
Integrated project management (IPM)
Risk management (RSKM)
Quantitative project management (QPM)
174
87
Process areas in the CMMI
Category
Process area
Engineering
Requirements management (REQM)
Requirements development (RD)
Technical solution (TS)
Product integration (PI)
Verification (VER)
Validation (VAL)
Support
Configuration management (CM)
Process and product quality management (PPQA)
Measurement and analysis (MA)
Decision analysis and resolution (DAR)
Causal analysis and resolution (CAR)
175
Goals and associated practices in
the CMMI
Goal
The requirements are analyzed and
validated, and a definition of the
required functionality is developed.
Associated practices
Analyze derived requirements systematically 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.
Root causes of defects and other
problems are systematically
determined.
Select the critical defects and other problems for analysis.
Perform causal analysis of selected defects and other
problems and propose actions to address them.
The process is institutionalized as a
defined process.
Establish and maintain an organizational policy for planning
and performing the requirements development process.
176
88
Examples of goals in the CMMI
Goal
Process area
Corrective actions are managed to closure Project monitoring and control (specific
when the project’s performance or results goal)
deviate significantly from the plan.
Actual performance and progress of the Project monitoring and control (specific
project are monitored against the project goal)
plan.
The requirements are analyzed and Requirements development (specific goal)
validated, and a definition of the required
functionality is developed.
Root causes of defects and other problems Causal analysis and resolution (specific
are systematically determined.
goal)
The process is institutionalized as a defined Generic goal
process.
177
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.
178
89
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.
179
The CMMI staged maturity model
180
90
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 results of the project planning
process.
181
Una previsione di performance
per ogni livello
182
91
Una tipologia di strumenti per
ogni livello
183
Accertamento
• L’accertamento è condotto mediante una
•
•
analisi dell’azienda (documenti organizzativi,
procedure aziendali) e realizzando interviste
attraverso appositi questionari.
Il SEI ha definito un questionario da
utilizzare che va adattato e tarato alle varie
realtà.
Il questionario è suddiviso in sezioni, quali:
– organizzazione, risorse, personale e formazione,
gestione della tecnologia, standard e procedure,
metriche di processo, raccolta ed analisi dei dati,
controllo processo.
184
92
Accertamento
• Le domande, divise in due categorie (a e b),
•
sono a risposta booleana (Si/No) ed ognuna di
esse, correlata ad una key area, è associata ad
un livello di maturità da 2 a 5.
La regola che determina il livello di maturità è
la seguente:
– La maturità di un processo è di livello i se si
risponde SI all’80% delle domande di tipo a ed al
90% di quelle di tipo b associate ai livelli tra 2 ed i.
• Le risposte vengono verificate e controllate.
185
Domande per il livello 2
186
93
Domande per il livello 2
187
Domande per il livello 2
188
94
Domande per il livello 2
189
Domande per il livello 2
190
95
Come migliorare ad ogni livello
191
Pros
• Prior to the introduction of CMM, there
was no theoretical basis applicable to
process maturity for IT-related
processes.
• CMM has been shown to be well-suited
for organizations wishing to define their
key processes.
192
96
Pros
• 1300 projects involving products of at
least 200 KLOC had been examined to
evaluate the possible saving in the five
levels.
• See the table in the following slide.
• The US Air Force requires level 3
certification from all its contractors.
193
194
97
Cons
• The objective of scientifically managing the software
•
process using defined metrics is difficult to achieve
until Level 4.
The CMM does not help to define the structure of an
effective software development organization. The
CMM contains behaviors or best practices that
successful projects have demonstrated. Thus, being
CMM compliant would not necessarily guarantee that
a project would be successful. However, being
compliant could increase a project's chances of being
successful .
195
Contro
• I clienti sono spesso orientati a
parametri non solo di qualità, ma
piuttosto di rapporto tra qualità e costi
oppure tra qualità costi e tempi.
• Un fornitore di Livello 5 CMM
garantisce davvero che il progetto
software dato in outsourcing si
concluderà in tempo e nel budget ?
196
98
Contro
• Le indagini confermano che livelli CMM più alti sono
•
•
correlati con una minor difettosità del software. I
dati su qualità e livello di maturità mostrano che c’è un
miglioramento indiscutibile nei costi e nel rispetto dei
tempi di completamento dei progetti.
Ma la massima valutazione CMM non necessariamente
garantisce il massimo risparmio per il cliente. Il
fornitore passa i suoi minori costi al cliente?
I fornitori di Livello 5 sono i migliori, dunque hanno la
possibilità di ricaricare di più, non di meno, sui clienti.
Per di più, una valutazione di Livello 5 in qualche caso,
fanno notare gli esperti, potrebbe comportare
investimenti maggiori del necessario.
197
Riassumendo
• Il modello indica ventidue Aree di processi
•
aziendali (Process area) strutturate su cinque
livelli, ognuna con i propri obiettivi generici
(Generic Goal) e specifici (Specific Goal).
Gli obiettivi generici e specifici sono
implementati da una sequenza temporale di
attività generiche (Generic practice) e
specifiche (specific practice), che hanno
determinate tipologie di output (tipical work
product).
198
99
• Il SEI ha constatato che 60 società hanno misurato
miglioramenti delle loro prestazioni in termini di costi, qualità,
produttività e soddisfazione del cliente con miglioramenti
compresi fra il 14% della soddisfazione del cliente al 62% di
incremento della produttività.
• Il CMMI in molti casi si limita a dichiarare quali miglioramenti
dei processi devono essere raggiunti, ma non in quale modo. In
particolare, non indica gli attori, le applicazioni e le strutture
informatiche protagoniste del cambiamento.
• I benefici dell'implementazione di un framework CMMI sono
limitati per piccole organizzazioni. È significativo che il 70.5%
delle società del campione con meno di 25 dipendenti si collochi
al livello 2, mentre il 52.8% di quelle che hanno fra i 1000 e i
2000 dipendenti, si collochi al livello più alto (livello 5:
ottimizzato).
199
• An organization cannot be certified in CMMI; instead, an
organization is appraised. Depending on the type of appraisal,
the organization can be awarded a maturity level rating (1-5) or
a capability level achievement profile.
• Appraisals of organizations using a CMMI model must conform
to the requirements defined in the Appraisal Requirements for
CMMI (ARC) document. There are three classes of appraisals, A,
B and C, which focus on identifying improvement opportunities
and comparing the organization’s processes to CMMI best
practices.
• The Standard CMMI Appraisal Method for Process
Improvement (SCAMPI) is an appraisal method that meets all of
the ARC requirements.
• A class A appraisal is more formal and is the only one that can
result in a level rating. Results of an appraisal may be published
(if the appraised organization approves) on the CMMI Web site
of the SEI.
200
100
• Al momento non esistono authority
•
indipendenti autorizzate a valutare i processi
di altre aziende secondo il CMMI, e la
valutazione è effettuata direttamente dal
SEI.
Il SEI ha valutato secondo il CMMI i processi
di una ventina di aziende informatiche in tutto
il mondo. Fra queste, una decina di aziende
indiane; in Italia, la sola IBM.
201
Statistiche
• SEI has maintained statistics on the "time to move
•
•
up" for organizations adopting the earlier Software
CMM and primarily using the traditional approach.
These statistics indicate that, since 1987, the median
times to move from Level 1 to Level 2 is 23 months,
and from Level 2 to Level 3 is an additional 20
months.
The Software Engineering Institute’s (SEI) Team
Software Process methodology and the Capability
Maturity Modeling framework have been successfully
employed to accelerate progress from Maturity Level
1 to Maturity Level 4. They’ve demonstrated
progressing from Level 1 to Level 4 in 30 months,
which is less than half of the average time it has
taken traditionally.
202
101
References
• Turner & Jain (2002) per un confronto
tra CMMI e metodologie Agile
• Nawrocki e altri (2002) per un
confronto tra CMMI e Extreme
Programming
203
• Interestingly, Turner & Jain (2002) argue that
•
•
•
although it is obvious there are large differences
between CMMI and agile methods, both approaches
have much in common.
They believe neither way is the 'right' way to develop
software, but that there are phases in a project
where one of the two is better suited.
They suggest one should combine the different
fragments of the methods into a new hybrid method.
David J. Anderson (2005) gives hints on how to
interpret CMMI in an agile manner. Other viewpoints
about using CMMI and Agile development are
available on the SEI Web site.
204
102
• To conclude with a similar use of CMMI,
Extreme Programming (XP) has been
evaluated with CMM/CMMI (Nawrocki
et al., 2002).
• The XP requirements management
approach, (which relies on oral
communication), was evaluated as not
compliant with CMMI.
205
103