290 Softeare Project Managenent

" Step 4: ldentify the products and activities of the project lt is atthis point thatthe entry,
requirements are identified for each activity. This is described later in this chapter. ,exil and process
" Step 8: Review and publicize plan At this stage the overall quality aspects of the
reviewed. project plan are
13.3 The Importance of SoftwareQuality
We would expect quuality to be aconcern of all producers of goods and services. However, the
teristics of software create special demands. special charac-
" lncreasing criticality of software The final customer or user is naturally anxious about the oon
quality of software, especially its reliability. This is increasingly so as organizations rely more on th
computer systems and software is used in more safety-critical applications, for example to contl
aircraft.

" The intangibility of sofware can make it difficult to know that a project task was completed satiste.
torily. Task outcomes can be made tangible by demanding that the developer produce 'deliverables' th
can be examined for quality.
" Accumulating errors during sofbware development As computer system development comprises stes
where the output from one step is the input to the next, the errors in the later deliverables will be added
to those in the earlier steps, leading to an accumulating detrimental effect. In general, the later in a
project that an error is found the more expensive it will be to fix. In addition, because the number of
errors in the system is unknown, the debugging phases of a project are particularly difficult to control.
For these reasons quality management is an essential part of effective overall project management.
13.4 Defining Software Quality
In Chapter 1we noted that a system has functional, quality and resource requirements. Functional require
ments define what the system is to do, the resource requirements specify allowable costs and the quality
requirements state how well this system is to operate.

EXERCISE 13.1)

At Brightmuth College. Brigette has to select the best off-the-shelf payroll package for the college.
How should she go about this in a methodical manner?
One elenment of the approach could be the identification of criteria against which payroll packages are
to be iudged. What might these criteria be? How could you check the extent to which packages matcn
these criteria?

Some qualities of a software product reflect the external view of software held by users, as in the case of
usability. These external qualities have to be mapped to internal factors of which the developers would
thus
be aware. It could be argued, for example, that well-structured code is likely to have fewer errorS and
improve reliability.
 Software Oualily 291

is notenough.
If we are tojudge whether aNystem mects our requirements we necd io be

measureIUst
elate the number ofl units to the maximum possible, The The BS I5O/EC
the
of faults in a progran, lor example, is related to the sizec of 16939:2007 standard
Sysloms and softwae
offoults pperthousand lnes of code is more helplul than total ongineering- moa
Bromonl procoss has
codifled nany of the
measures for aparticular quality helps to clarily and comnunicate what praclices discussed in
ttofind when we this section.
quality really is, What is being asked is, in cflect, how do we know
ht
havebeensuccesstul?"
where we can measure the quality directly, or indirect, where the thing being
The easures may be direct, indicator that
number of
the quality is present. For example, the mightbe
NINUred is not the quality itsell but an application
received by a help desk abouthow oneoperates a particular software
CNuiries by users
usability.
ah indirect measurementof its
measurements they effectively set targets for project team members,
When project managers identifyquality quality is always meaningful. For
improvement in the measured
example, the
so care has to be taken that an thorough the
inspections could be counted, on the grounds that the more
number of errors found in program by allowing
errors willbe discovered. This count could, ofl course, be improved quite the
inspection process, themore earlier-which is not
go through to the inspection stage rather than eradicating them
more errors to
pont. quality
a specific quality characteristic in a software product then a
the necd for
Whenthere is concern about minimum details should be drafted:
specitication with the following
definition/description: definition of thequality characteristic:
"
scale:the unit of measurement; exists:
test of theextent to which the attribute quality compensated
" test: the practical which might be acceptable if other characteristics
worst value
" minimallyacceptable: the product would have to be rejected outof hand:
lorit, and belowwhich
the
planned the quality measurement value should lie:
of values within which it is
" target range: the range
applies currently.
" now: the valuethat EXERCISE 13.2

package. Give particular attentionto the way that

specifications for a word processing
Suggest quality conducted.
attributes couldbe
practical tests of these
measurements applicable to a quality characteristic. For example, in the case of
There could be several measured in terms of:
reliability, this might be is Usable:
particular time interval that a system
availability: the percentage of a
divided by the number of failures:
tine between failures: the total service time
or the proba
Coilure on demand: the probability that a system will not be available at the time required
fail:
transaction will
bility that a
support activity:the number of fault reports that are generated and processed.
292 Software Project Management

EXERCISE 13.3
The enhanced IOE maintenance jobs system has been installed, and is normally available to
8.00 a.mn. until 6.00 p.m. from Monday to Friday. Over afour-week period the system was users from
for one whole day because of problems with a disk drive and was not available on two other
days until unavailable
10.00 in the morning because of problems with overnight batch processing runs.
service?
What were the availability and the mean time between failures of the

Maintainability can be Associated with reliability is maintainability, which is how quickly a

seen from two differ
ent perspectives. The detected, can be corrected. Akey component of this is changeability, whifaulcht, isoncehe
before an
user will be concerned ease with hich the software can be modified. However, amendment can be
with the elapsed time made, the fault has to be diagnosed. Maintainability can therefore be e seen as change.
between a fault being ability plus a new quality, analysability, which is the ease with which causes of failure
detected and it being
corrected, while the can be identified.
software development
managers will be con
cerned about the efort
involved.
B8 1SO9126
Over the years, various listsof software quality characteristics have been put forward
Currently, in the UK,
the main ISO 9126
such as those of James McCalland of Barry Boehm. Adifficulty has been the lck
standard is known as of agreed definiions of the qualities of good software. The term 'maintainability
BS ISO/IEC 9126 has been used, for example, to refer to the ease with which an error can be located
1:2001. This is supple and corrected in a piece of software, and also in a wider sense to include the ease
mented by some tech
nical reports' (TRs), of making any changes. For some, robustness has meant the software's tolerance
published in 2003, of incorrect input, while for others it has meant the ability to change program code
which are provisional without introducing errors. The ISO 9126 standard was first introduced in 1991 to
standards.At the
time of writing,a new tackle the question of the definition of software quality. The original 13-page document
standard in this area, was designed as a foundation upon which further, more detailed, standards could be
1SO25000, is being built. The ISO 9126 sandards documents are now very lengthy. Partly this is because
developed.
people with differing motivations might be interested in software quality, namely:
" acquirers who are obtaining software from external suppliers;h
developers who are building a software product;
. independent evaluators who are assessing the quality of asoftware product, not for themselves but ior
acommunity of users -for example, those who might Use aparticular type of software tooi as part o
their professional practice.
ISO 9126 has separate documents to cater for these three sets of needs. Despite the size of this set of documei
tation, it relates only to the definition of software quality attributes. A separate standard, ISO 14598, descriDe
the procedures that should be carried out when assessing the degree to which a software product contorist
ISO14598
the selected ISO 9126 quality characteristics. This might seem unnecessary, but it is argued that inISO
those
could be used to carry out an assessment using a different set of quality characteristics from
9126 if circumstances required it.
9126 alsointro
The difference between internal and external quality attributes has already been noted. ISOidentified:
duces another type of quality - quality in uSe - for which the following elements have been
 Softoare Quality 293

cfectiveness:the ability to achieve user goals with accuracy and completeness:

prodctivin: avoiding the excessive use of resources, such as statf effort, in achieving user goals;
safery:within reasonable levels of risk of karm to people and other entities such as business, software,
environment:
propertyandthe
satisfaction: smiling users.
context includes not just those who operate the system containing the softvare, but also those
sers'inthis
Usetain andenhance the software. The idea of quality in use underlines how the required quality of
use. For instance. in the IOE
fware is an attribute not just of the software but also of the context of
oio. suppose the maintenance job reporting procedure varies considerably, dependingSayon that the type of
IOE. 95oof
inment being serviced, because different inputs are needed to calculate the cost to
software is
Purently involve maintaining photocopiers and 5% concern maintenance of printers. If the
operational system.
iten for this application, then despite good testing, some erors might still get into the
as faults become rarer. If there
As these are reported and corrected, the software would become more 'mature
processed, there could be an increase
uere arapid switch so that more printer maintenance jobs were being
of the software code for printer mainte
in renorted faults as coding bugs in previously less heavily used parts transactions. Thus, changes to software
ance were flushed out by the larger number of printer maintenance
ISe involve changes to quality requirements.
IS0 9126 identifies six major external software quality characteristics:
"functionality, which covers the functions that a software
product provides to satisfy user needs:
its level of performance:
reliability, which relates to the capability of the software to maintain
use the software:
c lLsability, which relates to the effort needed to
resources used when the software is executed:
" efficiency, which relates to the physical
changes to the software:
maintainabiliry, which relates to the effort needed to the make
software to be transfered to a different environment.
"portability, which relates to the ability of the
thev clarify
9126 suggests sub-characteristics for each of the primary characteristics. They are useful as
ISO
characteristics.
What is meant by each of the main
Sub-characteristics
Characteristic
Suitability
Functionality
Accuracy
Interoperability
Functionality compliance
Security

software adheres to application -related standards

Functionality compliance' refers to the degree to which the requirements. Since the original 1999 draft a
auditing
or legal requirements. Typically these could be to all six ISO external characteristics. In each case
Sub-characteristic called 'compliance' has been added
apply to the particular quality attribute.
his refers to any specific standards that might
Interoperability
"Interoperability' is a good illustration of the efforts of ISO 9126 to clarify terminology.
9126 have chosen this
refers to the ability of the software to interact with other systems. The framers of ISO
 294 Software Project Management characteristic
Compatibility' because thelatter causes
confusion with the
referred to by IS0
word rather than
9126 as 'replaceability' (see below).
Sub-characteristics
Characteristic
Maturity
Reliability
Fault tolerance

Recoverability
Reliability compliance

faults in a software product, the implication being that the

'Maturity' refers to the frequency of
failure due to uncovered and removed. It is also
more the software has been used, the
more faults will have
distinguished
been
from 'security' which
describes the interesting
control of
to note that 'recoverability has been clearly
access to a system.

Sub-characteristics
Characteristic

Usability Understandability
Learnability
Operability
Attractiveness

Usability compliance

softwaretoolcould be easy to learn but time

Note how learnability' is distinguished from 'operability'. A This might be fine for a package used
consuming to use because, say, it uses a large number of nested menus.
case learnability' has been
intermittently, but not where the system is used for many hours each day. In this
incorporated at the expense of operability'.
Attractiveness' is a recent addition to the sub-characteristics of usability and is especially important where
entertainment
users are not compelled to use a particular software product, as in the case of games and other
products.
Characteristic Sub-characteristics

Efficiency Time behaviour

Resource utilization
Efficiency compliance
Maintainability Analysability
Changeability
Stability
Testability
Maintainability compliance
 Softaere Qality 295
Analysability is the ease with whichthe cause of afailure can be deternined. Changeability isthe quality
flexibility': the latter name is a better one as changeability has a different connotation in
call
thatothers
English-it mightimply that the suppliers of the software are always changing it!
plain
'Stability', onthe other
hand, does not refer to software never changing: it means that there is a low isk of a
modificationtothe software having unexpected effects.

Characteristic Sub-characteristics

Portability Adaptability
Installability
Coexistence

Replaceability
Portability compliance

have a bearing on portability.

Portability compliance relates to those standards that to many software/hardware
Anew version of a
word processing pack
language common
The use of a standard programming Replaceability' refers to the factors that age might read the 6
environments would be an example of this. ones.
documents produced
old software components and the new by previous versions
give 'upwards compatibility' between definition. and thus be abie to
Downwards' compatibility is not implied by the replace them but pre
to share resources with other software ViOuS versions might
Coexistence' refers to the ability of thesoftware involved. not be able to read all G)
direct data passing is necessarily
Components; unlike 'interoperability'. no
documents created by
Variation in the new version
provides guidelines for the use of the quality characteristics. product is
ISO 9126 characteristics depending on the type of
the importance of different quality the software product have been established, the
stressed. Once the requirements for
following steps are suggested: will be of
qualiry characteristic for the application Thus reliability real-time
each
1. Judge the importance of -critical systems while effhciency will be important for some
particular concern with safety
the oualinies
systems.
measurements within the ISO 9126 framework relevant tomeasurement.
2. Select the external quality mean time between failures would be an important
prioritized above Thus for reliability time behaviour. response time would be an
obvious
more specifically
while for efficiency, and
example. the
satisfaction For response time, for
measurement.
onto ratings that reflect user
3. Map measurements Table 13.1.
mappings might be as in intermediate products in which they annear
This
neasurements and the
4. ldentify the relevant internal software was being developed, rather than existing
software being
would only be important where assessed duning
software, the likely quality of the fhnal product would need to be sofware
evaluated. For new the
quality in question was time behaviour, at
development. For example, where the externaltransaction could be produced by examining the software
design stage an estimated execution time for a in a typicalexecution of the transaction. In our view
codeand calculating the time for each instruction characteristics and measurements suggested in
external quality
the mappings between internal and
296 Softoare Project Management
the ISO 9126 standard are the least convincing elements in the approach. The part of the standard that
provides guidance at this point is a 'technical report' which is less authoritative than a full standard. It
concedes that mapping external andinternai measurements can be difficult and that validation to check
that there is a meaningful correlation between thetwo in a specific environment needs to be done. This
reflects a real problem in the practical world of software development ofexamining code structure and
attempting to predict accurately externalqualities such as reliability.
Irom that
IABLE 13.1 Mapping measurements to user satisfaction

Response time (seconds) Rating

<2 Exceeds expectation

2-5 Within the target range

6-10 Minimally acceptable

>10 Unacceptable

According to ISO 9126, measurements that might act as indicators of the final quality of the software
can be taken at different stages of the development life cycle. For products at the early stages these
indicators might be qualitative. They could, for example, be based on checklists where compliance
with predefîined criteria is assessed by expert judgement. As the product nears completion, objective,
quantitative, measurements would increasingly be taken.
5. Overall assessment ofproduct qualiry To what extent is it possible to combine ratings for different
quality characteristics into asingle overallrating for the software? Afactor which discourages attempts
atcombining the assessments of different quality characteristics is that they can, in practice,be measured
in very different ways,which makes comparison and combination difficult. Sometimes the presence
of one quality could be to the detriment of another. For example, the efficiency characteristics of time
behaviour and resource utilization could be enhanced by exploiting the particular characteristics of the
operating system and hardware environments within which the software will perform. This, however,
would probably be at the expense of portability.
Itwas noted above that quality assessment could be carried out for a number of different reasons: to
assist software development, acquisition or independent assessment.
During the development of a software product, the assessment would be driven by the need to focus the
minds of the developers on key quality requirements. The aim would be to identify possible weaknesses
early on and there would be no need for an overall quality rating.
TABLE 13.2 Mapping response times onto user satisfaction

Response time(seconds) Quality score

<2 5

2-3 4

(Contd)
 Software Quality 297

Coma) The problem here is

to map an objective 6
3 measurement onto an
4-5
indicator of customer
satisfaction which is
6-7 2
subjective.
6
8-9

potential users are assessing a number of different software products in order to choose the best one,
here some idea
me will be along the lines that product A is more satisfactory than product B or C. Here
satisfaction might be
ive satisfaction exiSts and there is a justification in trying to model how this
product must reach or be
nd One approach recognizes some mandatory quality rating levels which adesirable but not essential.
td. regardless of how good it is otherwise. Other characteristics might be
based on having
lhese auser satisfaction rating could be allocated in the range, say. 0-5. This could be different levels
to
different measurement values
nobiective measurement of some function and then relating
13.2.
ofIser satistaction - see Table
could be assigned to reflect how important
Along with the rating for satisfaction, a rating in the range 1-5, say,
ach qualitycharacteristic was. The scores for each quality could betogiven
due weight by multiplying it by its
obtain an overall score for the product.
importance weighting. These weighted scores can then be summed
preference. For example, two products might be
The scores for various products are then put in the order of importance of each of these qualities might be
compared as to usability, efficiency and maintainability. The
of 5. Quality tests might result in the situation
ated as 3, 4 and 2, respectively, out of a possible maximum
shown in Table 13.3.

TABLE 13.3 Weighted quality scores

Product B
ProductA
Product quality Importance
rating (a)
Quality score Weighted score Quality score Weighted score
(a X b) (e) (a X c)
(b)
3 3

Usability 8 8
2
4
Efficiency 3 6 2
Maintainability 17 19
Overall
behalf of a user community as a whole. For example, aprofes-
assessment can be made on
Finally,
a quality
sional body might assesssoftware
tools that support the working practices of its members. Unlike the selection
assessmentof thesoftware indenen
by an individualuser/purchaser, this is an attempt to produce an objective
environment. Itis clear that the result of such an exercise would vary considerably
user
dently of a particularweightings givento each software characteristic, and different users could have different
depending on the
equiremnents. Caution would be
needed here.
298 Softuare Project Management

13.6 Product and Process Metrics

We have already discussed in Section 13.4 that the users assess the quality of a software product based on
Its external attributes. whereas during development, the developers assess the product's quality based on
Various internal attributes. We can also say that during development, the developers can ensure the quality
of asoftware product based on a measurement of the relevant internal attributes. Theintermal attributes may
measure either somne aspects of the product (called product or of the development process (called prOcess

understand the basic differences between productand process metrics.

metrics). Let us metrics help measure the characteristics of a product being developed. Afew examples of
" Product
product metrics and the specific product characteristics that they measure are the following: the LOC
and function pont metrics are used to measure size, the PM (person-month) metricis used to measure
the effort required to develop a product, and the time required to develop the product is measured in
months.
" Process metrics help measure how adevelopment process is performing. Examples of procesSS metrics
are review effectiveness, average number of defects found per hour of inspection, average defect
during testing per LOC. and a
correction time, productivity, average number of failures detected
number of latent defects per line of code in the developed product.

13.7 Product versus Process Quality Management

The measurements described above relate to products. With a product-based approach to planning and control
However
as advocated by the PRINCE2 project management method, this focus on products is convenient.
we saw that it is often easier to measure these product qualities in a completed computer application rather
than during its development. Trying to use the attributes of intermediate products created at earlier stages to
predict the quality of the final application is difficult. An alternative approach is to scrutinize the quality of
the processes used to develop software product.
The system development process comprises a number of activities linked so that the
Note that Extreme
Programming advo output from one activity is the input to the next (Figure 13.2). Errors can enter the
cates suggest that the
extra effort needed
process at any stage. They can be caused either by defects in a process, as when
to amend software at software developers make mistakes in the logic of their software, or by information
later stages can be not passing clearly and accurately between development stages.
exaggerated and is, in
any case, often justi Errors not removed atearly stages become more expensive to correct at later stages.
fied as adding value to
Each development step that passes before the error is found increases the amount of
the software.
rework needed. An error in the specification found in testing will mean rework at al
the stages between specification and testing. Each successive step of development is also more detailed and
less able to absorb change.
Errorsshould therefore be eradicated by careful examination of the deliverables of each step before they dre
passed on. One way of doing this is by having the following process requirements for each step.
"Entry requirements, which have to be in place before an activity can start. An example would betesting
thata
comprehensive set of test data and expected results be prepared and approved before program
can commence.
" Implementation requirements, which define how the process is to be conducted. In the testingphase,
for example, it could be laid down that whenever an error is found and mustbe
corrected, all test runs
repeated, even those that have previously been found to run correctly.
 Softoare Quality 299

Specify
program

Program
specification

Design
program
Create test data
and expected
Program results
design

Code
program

Program
test data
Program

Test
program

Testing
report

sequence of processes and deliverables These requirements

FIGURE 13.2 An example of the may be laid out in
installation standards.
deerned to have
be fulfiiled before an activity is
or a Software Quality
requirements, which have to recognized as being Plan may be drawn up
e Exit for the testing phase to be for the specific project
been completed. For example, with no outstanding
have been run successfully if it is a major one.
compieted, alltests will have to
erTOrs.
EXERCISE 13.4)

exit conditions for

entry conditions for one activity be different from the
In what cases might the
immediately precedes it?
another activity that
EXERCISE 13.5

and exit requirementsfor the process code program shown in Figure 13.2?
What might be the entry
 300 Software Project Management

13.8 Quality Management Systems

BS EN ISO
At IOE, 9001:2000
a decision might be made to use an outside contractor to produce the annual maintenance contract,
subsystem. A natural concern would be the standard of the contractor's deliverables Quality control wou
involve the Tigorous testing of all the software produced by the contractOr, insisting on rework where defects,
are found. This would be very time-consuming. An alternative approach would focus on quality aSSurance. ln
this case IOE would check that the contractors themselves were carrying out effective quality control. Akey
management
element of this would be ensuring that the contractor had the right quality system
in place.
Various national and international standards bodies,including the British Standards Institution (BSI), have
engaged in the creation of standards for quality management systems. The British Standard is now caled
BS EN ISO 9001:2000. which is identicaltothe international standard, ISO 9001:2000. Standards such as
the ISO 9000 series try to ensure that a monitoring and control system to check quality is in place. They are
concerned with the certification of the development process, not of the end-product as in the case of crash
ISO 9000 series
electrical appliances with their familiar CE marks. Standards in the relate to
helmets and
software development.
quality systems in general and not just those in
management system (QMS) and its terminolae.
ISO 9000describes the fundamental features of a quality products and the provISIOn of services IS0
of
ISO 9001describes how a QMS can be applied to the creation
9004 applies to process improvement.
standards. Stephen Halliday, writing in The
There has been some controversy over the value of these
imply that the final product is
Observer, had misgivings that these standards are taken by many customers to goimp
of the produc
of a certified standard although, as Halliday says, 'It has nothing to do with the qualityhowever low they may
them,
out of the gate. You set down your own specifications and just have tomaintain
be'Obtaining certification can be expensive and time-consuming which can put smaller, but still well-un.
businesses at a disadvantage. Finally, there has been a concern that a preoccupation with certification might
distract attention from the real problems of producing quality products. This would be another example of
means-ends inversion, discussed in Chapter 4.
Putting aside these reservations, let us examine how the standard works. First, we identify those things to be
the subject of quality requirements. We then puta system in place which checks that the requirements are
being fulfilled and corrective action taken when necessary.

An overview of BS EN ISO 9001:2000QMS requirements

The standard is built on a foundation of the following principles:
Remember that these
" understanding the requirements of customers so that they can be met. or even
Ostandards are de
signed for all kinds of exceeded:
production - not just " leadership to provide the unity of ppurpose and direction needed to achievequaliy
software development.
objectives;
" involvement of staff at all levels;
" afocus on the individual processes which create intermediate or deliverable products and services;
" afocus on the systems of interrelated processes that create delivered products and services:
 Software Quality 301

improvementtof processes;
factual evidence:
makingbasedlon
mutuallybeneficial relationships with suppliers.
cycles which involve the following activities:
uilding
, Ithrough
areapplied
wieples
expectations of the customer:
deerminingthe needs and in relation
t
policy, hat is, aframework which allows the organization's objectives
establishingaaquality
defined:
Qualitytobe services) which will have the
o
processes which will create the products (or deliver the
designof the objectives;
1 organization's quality
alies implied in the requirements for each element of each process;
for meeting these
location of the responsibilities
execute these processes properly;
that resources are availableto
5,ensuring effectiveness and efficiency of each process in contributing to the
kdesign of methods for measuring the
onganization's quality objectives;
1. gatheringof measurements:
values;
discrepancies between the actual measurements and the target
8 identification of any
of discrepancies.
9. analysis and elimination of the causes They should,
designed and executed so that there is continual improvement.
The procedures above should be QMS. More detailed ISO 9001requirements include:
to an effective
ifcarried out properly, lead quality manua), plans, and records relating
procedures (in the form of a
Documentation of objectives, documentation must be
that
subject to a change control systemOMS
The
to the actualoperation of processes. needs to be able to demonstrate
to an outsider that the
Essentially one
ensures that it is current.
exists and is actually adhered to. show that the QMS and the processes
that
responsibility- the organization needs to managed.
" Management conforming to the quality objectives are actively and properly
produce goods and services resources, including appropriately
trained staff
must ensure that adequate
" Resources - an organization processes.
appropriate infrastructure, are applied to the
and
characterized by:
"Production should be
planning: customer requirements:
determination and review of supplier:
between the customer and
cffective communications review:
development being subject to planning, control and recorded:
" design and being adequately and clearly
information used in design
" requirements and other validated and documentedin:away that provides sufficient
information
being verified,
" design outcomes to use the designs;
for those who have controlled:
changes to the designs should be properly
" specify and evaluate the quality of purchased components:
measuresto
" adequate goods and the provision of services should be under controlled conditions to ensure
" production of
provision of information, work instruction, equipment, measurement devices, and post-de-
adequate
livery activities;
302 Software Project Management
" measurement - to demonstrate that products conform to standards, and the OMS is effective, and to

processes that create products or services.

lmprove the effectiveness of
EXERCISE
13.6
system testing and subsequent
One of the processes involved in developing software is
a software development
modification toto
organization were to
the application in the light of errors found. If
testing? attempt
to BS EN ISO 9001:2000, how might this affect system
conform

EXERCISE

9001 that have been mentioned, what precautionary steps

Bearing in mind the criticisms of BS ENISO contracted Out to
manager take where some work for which quality is important 1is to be
could a project
9001 accreditation?
an organization which has BS EN ISO

13.9 Process Capability Models

are more meaningtully measured during produet
As compared to the product metrics, the process metrics process-based techniques are very
development. Consequently, to manage quality during development,
15504, and Six Sigma, which are popular
important. In this section, we discuss SEI CMM, CMMI, ISO
process capability models.

Ahistorical perspective
extensive testing of
Before the 1950s, the primary means of realizing quality products was by undertaking product assurance
from
the finished products. However, the emphasis of the quality paradigms later shifted
(extensive testing of the finished product) to process assurance (ensuring that a good quality process is Ised
assumption made by all
for product development). In this context, it needs to be emphasized that a basic
modern quality paradigms is that if an organization's processes are good and are followed rigorously, then the
products developed by using it would certainly be of good quality. Therefore, all modern quality assurance
techniques focus on providing sufficient guidance for recognizing, defining, analysing, and improving the
process.
A good documented process enables setting up of a good quality system. However, to reach the next quany
level, it is necessary to improve the process whenever any shortcomings in it are noticed. It is also necessay
incorporate into the development process any new tools or techniques that may become available. Ihis To
the essential idea behind Total Quality Management (TQM). In a nutshell, TÌM advocates that theContinuous
pro
followed by an organization must continuously be improved through process measurements.
process improvement is achieved Business Process
through process redesign. Aterm related to TQM is
Reengineering (BPR). BPR aims at reengineering the way business is carried out in an organization.

SElcapability maturity model (CMM) in

The United States Department of Defence (US DoD) is one of the largest buyers of software prooducts
whomit
the world. It has often faced difficulties dealing with the quality of performance of vendors, to
 Softeare Quality 303

contracts.The department
ENCd had to live with recurring problems of delivery of low quality products,
edelivery,and
I cost escalations. In this context, DoD worked with the Software Engineering Institute (SEI)
Carnegie Mellon University to develop CMM. Originally, the objective of CMM was to assist DoD in
elopinganneffective software acquisition method by predicting thelikely contractor performance through
eraluationoftheir development practices.
o theDoD contractors began to undertake CMM-based process improvement initiatives as they vied
stof
contracts. It was soon observed that the SEI CMM model helped organizations to actually improve
r DoD u
ie
qualityof :software they developed. These organizations were quickly convinced that adoption of SEI
OMmodel had significant business benefits even when they were developing software for clients other
the DoD
than
Gradually many other commercial organizations began to adopt CMM in their own internal
gprovementinitiatives.

words, CMM is a reference model for appraising a software development organization into one
nsimple qualityof the devel
iive process maturity levels. The maturity level of an organization is aranking of the
nment process used by the organization. This information can be used to predict the most likely outcome of
anTOject that the organization undertakes.
ishould be remembered that SEI CMM can be used in two different ways, viz., capability evaluation and
ocess assessment. Capability evaluation and software process assessment differ in motivation, objective,
and the final use of the result. Capability evaluation essentially concerns assessing the software process
capability of an organization. Capability evaluation is administered by the contract awarding authority, and
work.
therefore the results are indicative of the likely contractor performance if the contractor is awarded a
own
On the other hand, process assessment is used by an organization with the objective of improving its
company.
process capability. Thus, the result of the latter type of assessment is purely for internal use by a
organization and
In process assessment, the quality level is assessed by a team of assessors coming into an
information. It
interviewing the key staff about their practices, using a standard questionnaire to capture specific
recommend
needs to be remembered that in this case, a key objective is not just to assess, but to
different levels of SEICMM have
actions to bring the organization up to a higher process maturity leyel. The
system starting from scratch.
been designed so that it is easy for an organization to slowly ramp up its quality
following five maturity levels.
SEI CMM classifies software development organizations into the
by haphazard activities by
Level 1: InitialA software development organization at this level is characterized
brought aboutby the lack of any definition
the members of project teams. The chaotic activities are primarily
free to follow anyprocess thathe or she
of the development and management processes. Bach developer feels
leaves the organization, the
may like. Due to the chaotic development process practised, when a developer
in understanding the process that was followed for the portion of
new incumbent usually faces great difficultythe
the work that has been completed.
Besides lack of any agreed development processes in the organization,
management process is prevalent. Consequently, time pressure builds up towards the
osystemnatic project leading to low quality
product deliverv time. To cope up with the time pressure, many short cuts are tried out
1 organiza
products. Though project failures and project completion delays are commonplace in these level
projects may get successfully completed. But an analysis of any incidence
tions, yet tit is possible that some
of successful completion of a project w would reveal the heroic efforts put in by some members of the project
team. Thus,, it can be said that the chances of asuccessful project execution by alevel I organization depends
exactly are the members of the development team.
to alarge extent on who
 304 Software Project Management
Level 2: Repeatable Organizations at this level usually practise some basic project management practice
schedule. Further, these organizations make use of
management tools to
SuCh as planning and
keep the
tracking cost

by
and
deliverable

any
items
documented
under configuration
configuralion
control. As level 1 organiZations, level
process. However, the developers usually
As aresult, such an organizationhave
understanding of the
2organizations are characterized
process being followed in the organization.
carough
can usually

Tepeat success on
itsDefined one project on other similar projects.
Level 3: Attthis level, the processes for both management and development activities are defined and
understanding of activities, roles. and
Atthis level, theThere
documented. common
organization
is a
organization-wide
responsibilities,
builds up the capabilities of its employees through periodic training programs.
achieve phase containment of errors.
Also, systematicreviews are practised to
Level 4: Managed/Organizations at this level focus on effectively managing development tasks by collectúng
appropriate process and product metrics. Quantitative quality goals are set for theproducts and processes. At
the time of project completion, it is checked whether the quantitative quality goals for these have been met.
The process metrics are used to check if project activities were performed satisfactorily. In other words, the
rather than improve the process
collected metrics are used to measure and track project performance
Level Optimizing
5: them Organizations operating at this level not only collect process and product metrics ku
analyse to identify scopes for improving and optimizing the various development and management
activities. In other words, these organizations strive for continuous prOcess mprovement. As an example of
resulte
a process optimization that may be made, consider that from an analysis of the process measurement
it is observed that the code reviews are not very effective and a large number of errors are detected onl
during the unit testing. In this case, the review process would be fine-tuned to make it more effective. In 4
level 5organization, the lessons Jearned from specific projects are incorporated in to the process. Continuous
process improvement is achieved both by careful analysis of the procesS measurement results and assimi
lation of innovative ideas and technologies. Level 5 organizations usually have a departiment whose sole
responsibility is to assimilate latest tools and technologies and propagate them across the organization.
Since the processes change continuously in these organizations, it becomes necessary to effectively manage
these changing processes. To effectively manage process changes, level 5 organizations use configuration
management techniques.

Key process areas

Except for level 1, cach maturity level is characterized by several Key Process Areas (KPAS). The KPAs of
a Jevel indicate the areas that an organization at the lower maturity level needs to focus to reach this level.
The KPAs for the differentprocess maturity levels are shown in Table 13.4. Note that level lI has no KPAs
associated with it, since by default all organizations are in level 1.
KPAS provide a way for an organization to gradually improve its quality of over several stages. In ol
words, at each stage of process1 maturity, KPAs identify the key areas on which an organization needstofocus
to take it to the next level of maturity. Each stage has been carefully designed such that one stage enhancesthe
capability already built up. For example, trying to implement a defined process (level 3) before a repea
process (level 2) would be counterproductive as it becomes difficult to follow the defined process due
schedule and budget pressures. In other words, trying to focus on some higher level KPAs without achieving
the lower level KPAs would becounterproductive.
 Softoare Quality 305

(Capability Maturity Model Integration)

MI
|isthesuccessorcof theCapability Maturity Model (CMM). In 2002, CMMI Version 1.Iwas released.
12followed in
2006. The genesis of CMMl is the following. After CMMI was first released in
lirson
adopted and used in many domains other than software development, such as human resource
itwas (HRM). CMMs were developed for disciplines such as systems engineering (SE-CMM).
panagement
management (PCMM), software acquisition (SA-CMM), and others. Although many organizations
models to be useful, they faced difficulties arising from overlap. inconsistencies, as well as
(oundthese is generalized to be applicable to many domains using a
ilegrationofthe models. In this context, CMMl
more abstract than its prede
framework. However, this uniication has resulted in making CMMI much
very generic in nature and even
rs such as CMM. For examnple, all the terminologies that are used are
e wOTd software does not appear in the definition documentation
of CMMI. However, CMMIhas much in
process maturity of CMM.
oanmon with CMM, and also describes the five distinct levels of
TABLE 13.4 CMMI key process areas

Level Key process areas

1. Initial Not applicable

control. supplier
2. Managed Requirements management, project planning and monitoring and product quality
and
agreement management, measurement and analysis, process
assurance, configuration management
integration, verification.
3. Defined Requirements development, technical solution, product
integrated project
validation, organizational process focus and definition, training. management.
integrated supplier
management, risk management, integrated teaming,
environment for integration
decision analysis and resolution, organizational

4. Quantitatively managed Organizational process performance, quantitative project management

resolution
Organizational innovation and deployment, causal analysis and
5. Optimizing

ISO15504 Process assessment

assessment that shares many concepts with
ISO/IEC 15504 is a standard for process standard is designed
The main reference in G
CMMI. The two standards should be compatible. Like CMMI the do this
tne UK for this stan
of software development processes. To
dard is BS ISO/IEC
to provide guidance on the assessment reference model which represents the ideal 15504-1:2004
there mustbe some benchmark or process processes can be compared, Various
development life cycle against which the actual been
reference models could be used but the default is the one described in ISO 12207. which bas
process processes - such as requirements analvsis and
briefy discussed in Chapter 1and which descrnbes the main
development life cycle.
architectural design - in the classic software
attributes - see Table 13.5
Processes are assessed on the basts of nine process
 306 Softuare Project Management
framework for process capability
TABLE 13.5 ISO 15504
Attribute Comments
Level
The process is not
For a process to be
( judged to be at Level
3,for example, Levels
0. Incomplete unsuccessful timplemented or is
1and 2 must also have 1.1 Process The process produces its
been achieved. 1. Performed
process
performance outcomes
dehned
2.1 Performance The process is properly planned
2. Managed management
monitored
process
2.2 Work product Work products are properly
management and reviewed to enSure they defincd
requirements meet
The processes to be carried
3. Established 3.1 Process
definition carefully defined
process
The processes defined above are
executed by properly trained staffproperly
3.2 Process
deployment
4. Predictable 4.1 Process Ouantitatively measurable targets are set
measurement for each sub-process and data collected
process to monitor performance
4.2 Process On the basis of the data collected by
control 4.1 corrective action is taken if there is
unacceptable variation from the targets
5.1 Process As a result of the data collected by 4.1.
5. Optimizing innovation opportunities for improving processes
are identified

5.2 Process The opportunities for process

optimization improvement are properly evaluated
and where appropriate are effectively
implemented

process attribute is being fulfilled they allocate one of the

When assessors are judging the degree to which a
following scores:

Level Interpretation

N- not achieved 0 to 15% achievement

15% to 50% achievement

P- partially achieved
L-largely achieved 50% to 85% achievement

F-fully achieved 85% achievement

 Software Ouality 307
attribute of a process as being at a certain level of achievement, indicators have
to, assessthe process
soder provide evidence for the assessment. For example, say the requirement analysis processes
found that
e organization were being assessed. Assessors might wish to test whether the organization is at Level
dn relatestothere being an established process. The assessor might find a section in aprocedures
which
tothe conduct of requirements. This could be evidence of the process being defined (3.1 in
alrelating might also come across control documents which have been signed off as each step of the
13.5). They
cquirementsanalysis process has been completed. This would indicate that the defined process is actually
kployed(3.2).

Implementingprocess improvement
this section
he CMMI standard has now groWn to over 500 pages. Without getting bogged down in detail,
anlores how the general approach might usefully be enployed. To do this we will take a scenario from
industry.
This
IVWis a company that builds machine tool equipment containing sophisticated control software.
UVW produces
eouipment also produces log files of fault and other performance data in electronic format.
software that can read these log files and produce analysis reports and execute queries.
Both the control and analysis software is produced and maintained by the Software Engineering departrment.
of equipment.
Within this departmentthere are separate teams who deal with the software for different types
designers
Lisa is aSoftware Team Leader in the Software Engineering department with a team of six systems
reporting to her.
maintenance of existing systems for a particular
Her group is responsible for new control systems and the
is sometimes blurred as a new
product line. The dividing line between new development and maintenance create the new
which are modified to
control system often makes use of existing software components
software.
but not faultcorrection and adaptive
Aseparate Systems Testing Group test software for new control systems,
maintenance of released systems.
responsibility for managing
Aproject for a new control system is controlled by a Project Engineer with overall
primarily a software specialist
both the hardware and software sides of the project. The Project Engineer is not
in an advisory capacity. Lisa may.
and would make heayy demands on the Software Team Leader, such as Lisa, respect of different projects,
as aSoftware Team Leader, work for a number of different Project Engineers inSoftware Engineering.
the Head of
but in the UVW organizational chart she is shown as reporting to
software requirement document which is
Anew control system starts with the Project Engineer writing adocument, usually after some amendment.
reviewed bya Software Team Leader, who will then agree to the
they can create system
Acopyof the requirements document will pass to the Systems Testing Group so that
environment.
test cases and a systems test
Lisa. if she were the designated SoftWare Team Leader, would then write an Architecture Design docunent
mapping the requirements to actual softWare components. These would be allocated to Work Packages carried
team.
out by individual members of Lisa's
UVW teams get the software quickly written and uploaded onto the newly developed hardware platform for
initial debugging. The hardware and software engineersS will then invariably have to alter the requirement and
consequently the software ás they find inconsistencies, faults and missing functions. The Systems Testing
 308 Sotaare Project Management
Group should be notified of these changes, but this can be patchy. Once the system seemsto be satistactory to
the developers, it is released to the Systems Testing Group for final testing before shipping t0 cUstomers.

problenms mainly relate to deliveries of software by her group because:

lateand
)
LIsa s work
the Head of Softvware Engineering the Project Leaders may not liaise properl. leading to the over.
same time:
systems andmaintenance jobs at the
COmmitment of resources to both new
the prototype often leads to major nevw requiremnents being identified:
thereinitial
(m)) the
( is no properofcontrol over change requests - the volume of these can sometimes increase the
testing
bevond that originally planned:
demand for software development well of bug ixes.
completion of system testing can be delayed because of the number
(2V)
We can see that there is plenty of scope for improvements. One problem is knowing where to start. However.
approaches like that of CMMI can help us identify the order in which steps in improvement haave to take
to introdee
completion of others. An immediate step would be
place. Some steps need to buildon the to assess the size of the problems even if we
ans.
yet able to solve
planning and
themcontrol.
all. This
Given a wouldat
sottware least enable usformal
requirement, plans enable staff workloadsto be distributed
Tormal
managers to identity emerging problems wia
more carefully. The monitoring of plans would also allow
would make managerS more aware of how chanoa.
particular projects. Effective change control procedures developments wonla
be breached. These process
in the system's functionality can force project deadlines to
13.3 illustrates how a project control system coula
help an organization move from Level 1to Level 2. Figure
be envisaged at the level of maturity.

resources
progress reports

plans

The project process

requirements deliverables

accepted requests change requests

FIGURE 13.3 The project as a 'closed box'

The next step would be to define carefully the processes involved in each stage of the development life cycle
-see Figure 13.4. The steps of defining procedures for each development task and ensuring that they are
actually carried out help to bring an organization up to Level 3.
EXERCISE 13.8,

The diagram in Figure 134 does not show the flows of information needed to indicate howAmend
manag
the
could ensure that the correct amount of staff time is allocated to development activities.
diagram to show these flows.
 Software Quality 309

Hardware
definition

Hardware definition
Hardware
modifications System test error reports
Define software
requirements
Suggested Software Modifications
changes requirement

Review software
Create test cases
requirements

Agreed Agreed software

modifications requirement

Write architecture
design
Change Work packages Test cases
requests

Develop
software

Error Software
modules
reports
System testing
Initial debugging Released
software

FIGURE 13.4 A process diagram

monitored. We can
exist, the behaviour of component processes can be
When more formalized processes
reports generated and system defects detected at the system testing
change infor
see, for example, the numbers of the products passing between processes, we can also collect effortproblems
phase. Apart from information about taken speedily when
enables efective remedial action to be
mation abouteach process itself. This now properily managed, bringing the
organization up to Level 4.
development processes are
are found. The collected is used to improve the process model
management, the ntormation major source
Finally. at Level 5 of process apparent that the changes to software requirements are a
itself. It might. for example, become example, the hardware component of
couldtherefore be taken toimprove this process. For more
of defects. Steps simulated using software tools. This could help the hardware engineers to produce
it against a
test
the systemcould be reduce changes. Itmight even be possible to build control software and
realistic designs and technical problems.
bardware system. This could enable earlier and cheaper resolution of
simulated

Six Sigma
initially developed the six sigma method in the early 1980s. Since then, thousands of
Motorola, USA,
companies aroundthe world have discovered
the benefits of adopting six sigma methodologies. The purpose
 310 Softuare Projet Munagement
can in
of six sigma is to Improve processes to do things better, faster, and at alowe cost. It
improve every facet of business, ic., production, hunan resources, order entry, and
fact, ued to
technical be

qualiSuppor
ty t resulareas,t,
timeliness.
Six sigma becomes applicable to any activity that is concerned with cost, and
Therefore, it is applicable to virtually every industry. Six sigma seeks to improve the quality of
ol
in
outputs by identifying and remnoving the causes of defects and minimizing variability the use ol
It uses many quality management methods, including statistical methods, and requires presence,of
proocess,ces,
pr
experts within the organization (black belts, green belts, ete.).
six sipma
Six sigma is essentially a disciplined, data-driven approach to eliminate defects in any process, The statis.
tical representation of six sigma describes quantitatively how a process is perlorming. To achieve SIX
a process must not produce more than 3.4 defects per million defect opportunities, A six sigma defect is SIgma,
defined as any system behaviour that is not as per customer specifications, Total number of six sigmadefectbe
opportunities is then the total number of cchances for committing an crror. Sigma ofa proceSs can casily
calculated using a six sigma calculator.
As already mentioned, a basic objective of the six sigma methodology is the implementation of a measue
ment-based strategy that focuses on process improvement and variationreduction through the application.,
six sigma improvement methodologies. This is accomplished through the use of two six Sigma sub-mehiod.
ologies: DMAIC and IDMADV. The six sigma DMAIC process (define, measure, analyse, improve, control
IS an improvement system for existing processes falling below specification and looking for incrementi
improvement. The six sigma DMADV process (define, measure, analyse, design, verily) isan improvement
system used to develop new processes or products at six sigma quality levels. Both six Sigma processes are
executed by six sigma green belts and six sigma black belts, and are overseen by six sigma master blak
belts.

Many frameworks exist for implementing the six sigma methodology. Six sigma consultants allover the
world have also developed proprietary methodologies for inmplementing six sigma quality that is based on
various philosophies and tools.

13.10 Techniques to Help Enhance Software Quality

Three main themes emerge inthis discussion of software quality:
Increasing visibility A landmark in the movement towards a focus on software
Gerald Weinberg
((1998) The Psychology quality was Gerald Weinberg's advocacy of 'egoless programming'. Weinberg
of Computer encouraged the simple practice of programmers looking at each other's code.
Programming, Silver
Anniversary Edition,
" Procedural structure At first. programmers were left to get on with writing
Dorset House. programs as best they could. Over the years there has been the growth of method
ologies where every process in the software development cycle has carefully lid
The creation of an down steps.
early working model of
asysten may still be " Checking intermediate stages It is tempting to push forward quickly wilh
useful, as the creation the development of any engineered object until a 'working' model, hoWeve
of prototypes shows. imperfect, has been produced which can then be 'debugged'. The movetowards
quality practices has emphasized checking the correctness of work at its earieh
conceptual, stages.
However, recently focus has shifted from relying solely on checking the products of internediate stages ant
towards building an application as anumberoof smaller, relatively independent components developedquickly
 Software Quality 311
dtestedatan carlystage. This can reduce some of the problems, noted earlier, of attempting to predict the
Iqualityofthe software from carly design documents. It does not preclude careful checking of the
wigoofcomponents,

are
noWBoing to look at some specific techniques, The push towards more visibility has been dominated
WetheincreaSing use of walk-throughs, inspections and reviews. The movement towards a more procedural
Uctureinevitably leads to discussion of structured programmingtechniques and to its later manifestation in
heideas
of clean room' software development.
Theinterestintthe dramaticimprovements made bythe Japanesein product quality has ledto much discussion
the quality techniques they have adopted, such as the use of quality circles, and these will be looked at
briclly.Some of these ideas are variations onthetheme of inspection and clean-room development.

Inspections
nections can be applied to documents produced at any development stage. For instance, test cases need to
kreviewed -their production is usually not a high-profile task even though errors can get through to opera
ional running because of their poor quality.
When apiece of work is completed, copies are distributed to co-workers who examine the work, noting
defects, Amceting then discusses the work anda list of defectsrequiring rework isproduced. The work to be
examined could be, typically, a program listing that is free of compilation errors.
The main problem is
Ourown experience of using this technique has been that: maintaining the com
mitment of participants
itis a very effective way of removing superficial errors; to a thorough examina
tion of the work dis
it motivates developers to produce better structured and self-explanatory tributed to them after
software: the novelty value of
reviews has worn off
" it helps spread good programming practices as the participants discuss specific a little.
pieces of code;
it canenhance team spirit.
The item will usually be reviewed by colleagues who work in the same area, so that This is sometimes
soltware developers. for cxanple, will have their work reviewed by fellow deve| called 'peer review',
opers. To reduce the problems of communication bctween different stages, there may where 'peers' are peo
ple who are equals.
be representatives from the stages preceding and following the one which produced
the work under review.
IBM made the review process more structured and formal, producing statistics to show its effectiveness A
Fagan inspecton (named after the IBM employee who pioneered the technique) is led, not by the author of
moderator'.
the work, but by aspecially trained

lhegeneral principles behind the Fagan method See M. E. Fagan's

deliverables. 6
" Inspectíons are carried out on all major (1976) article 'Design
and code inspections
function errors.
Alltypes of defcct are noted- not just logic or to reduce errors in

" Inspections can be carried out by collagues at all levels except the very top program development',
IBM Systems Journal
Inspections are carried out using a predefined sct of steps. 15(3).
 312 Softuware Project Management
more than two hours.
Inspection meetings do not last for specific training in the
technique.
moderator who has had
he inspection is led by a example, one person will act as a
recorder
and note all
defects found, and have
another defined
will act roles.
as For
reader and take the other participants through the document
" The other participants

under inspection.
process.
Checklists are used to assist the fault-finding
optimal rate of about 100lines an hour.
" Material is inspected at an
of the inspection process can be monitored
Statistics are maintained so that the effectiveness
EXERCISE 13.9

above with pair programming which is

Compare and contrast the peer review process described
advocated as part of extreme programming (XP).

Structured programming and clean-room softwaredevelopment

while the capacity
In the late 1960s, software was seen to be getting more complex
E. W. Dijkstra in 1968 realized that it was
wrote a letter to a of the human mind to hold detail remained limited. It was also
learned computing impossible to test any substantial piece of software completely given the huge number
journal which was en of possible input combinations. Testing, at best, could prove the presence of errors,
titled 'Go To Statement not their absence. Thus Dijkstra and others suggested that the only way to reassure
Considered Harmful'.
This unfortunately led ourselves about the correctness of software was by examining the code.
to the common idea
that structured pro The way to deal with complex systems, it was contended, was to break them down
gramming was simply into components of a size the human mind could comprehend. For a large system
about not using GO
TOs. there would be a hierarchy of components and subcomponents. For this decompo
sition to work properly, each component would have to be self-contained, with only
one entry and exit point.
The ideas of structured programming have been further developed into the ideas of clean-room software
development by people such as the late Harlan Mills of IBM.

Usage profiles reflect

Withthis type of development there are three separate teams:
the need to assess
quality in use as
" aspecification team, which obtains the user requirements and also ausage profle
discussed earlier in estimating the volume of use for each feature in the system:
relation to ISO 9126.
They will be further dis a development team, which develops the code but which does no machine testing
cussed in the Section of the program code produced;
13.11 on testing below. e acertification team, which
carries out testing.ste
Any system is produced in increments - recall Section 4.10 - each of which should be capable of actual
operation by the end-user. The development team does no debugging; instead, all software has to be verified
bythem using mathematical techniques. The argument is that software which is
constructed by made
crude program, which then has test data thrown at it and a series of hit-and-miss amendments throwiie
toit until
it works, is bound to be unreliable.
 Softoare Ouality 313
Secaiosteas cary outthe testing, which is continued until astatístical model shows that the failure
sbeen roduced to 20 20eptable level.

formalmethods
Ceas-tons developent,tmentioned above, uses mathematical verification techniques. These techniques use
mathematically based. specification languages of which Zand VDM are examples. They are
preconditions and potconditions for each procedure. Preconditions define the allowable states,
ofthe data iterns upon which aprocedure is to work. The postconditions define the state of
eprsceing,
aaitems after processing The mathernatical notation should ensure that such aspecification is precise
school
abigos. t sould also be possible to prove mathermatically (in much the same way that at the
the data defined by
eant to prove Pythagorzs theorem) that a particular algorithm will work on effectiveness of the
nons in such a2 Way as to produce the postconditions. Despite the claims of the
rarely used in mainstream
da foal otation to define software specifications for many years now, it is
universities. Anewer development
bve deelopment.This isdespite it being quite widely being taught in Language
Constraint (OCL). It adds precise,
tut say e with more success is the developrment of Object values that would be valid for a
tbigos, detail othe UML models, for example about the ranges of
notation which developers who are familiar
sed tribute. It usesat unarnbiguous, but non-mathematical.
wih lavalikeprograing languages should grasp relatively easily.
Software quality circles
practices.The aim of the Japanese' approach is
Mach inteest has been shown in Japanese software quality process in order to reduce the number of errors that
oexamineand modify theactivities in the development
end-products. Testing and Fagan inspections can assist the removal of errors - but the same
tey have in their products created by a faculty process. By uncovering
the
pes of error coald occur repeatedly in successive
eliminated.
SOCE of errors,this repetition can be
identífication of sources of errors through the formation of quality circles. These can
Statl ate isolved in the are known as
departrments of an organization, including those producing software where they
be set up in all
fwate uality circles (SWOC) an hour a
group of four to ten volunteers working in the same area who meet for, say,leader and
Aauality circle is a group
ientify, analyse and solve their work-related problems. One of their number is the make the quality
Wck o order to
who can advise on procedural matters. In
here cs4 bhean outsider, a facilitator, given.
needs to be
citcle sworkeffectively, training
pressing problem that affects their work. They identify what they think are
Togetterthe auality group select a course of action to remove these causes. Often,
because of resource
becases of the oroblerm and decide on a approval
constraints, they will have to present their ideas to management to obtain
pNsibe organizational
improverment.
befone innplesmenting the process
EXERCISE 13.10

quality circle and a review group?

Wht are the innportant differences between a
 314 Software Project Management is the compilation of most probable error lists. For example, at IJOE, Amanda
might find that the annual maintenance contracts project is being delayed because of errors in the require-
Associated with quality circles
producing alist of
and spend some time identify the
measures most
assembled
ments specifications. The project team could be specifications. This is then usedto which
can reduce the Occurrence of each type of error. They might suggest, for instance, thattest cases be produced
common types of error that occur in requirements
cases should be dry run atat an
and that these test
requirements specificationinspections of requirement speciications.
at the same time as theerequirements inspection.
when conducting
1ne resut is achecklist for use

Lessons learnt reports

its performance is by reiecting on the performanea -e
can improve
Anoner way by which an organization still fresh. This reflection may identify lessons to be
a project at its immediate end when the experience is to write a Lessons Learnt report at the end of the
applied to future projects. Project managers required
from a Post Implementation Review (PIR). A PIR takes place afer a
project. This should be distinguished system, and focuses on the effectiveness of the neW system, rathe.
SIgnihcant period of operation of the new someone who was not involved in the original
The PIR is often produced by
than the original project process. of the PIR will often be changes to
enhance the effer.
project, in order to ensure neutrality. An outcome
tiveness of the installed system.
the project manager as sOon as possible after the
The Lessons Learnt report, on the other hand. is written by
team is often dispersed to new work soon after
completion of the project. This urgency is because the project very little follow-up on
that there is often
the finish of the project. One problem that is frequently voiced is the organization with the responsibility
the recommendationsof such reports, as there is often no body within
and authorityto do