SOFTWARE QUALITY MODULE-5

INTRODUCTION
➢While quality is generally agreed to be 'a good thing', in practice what
is meant by the 'quality' of a system can be vague.

➢ We need to define precisely what qualities we require of a system.

➢Quality software refers to a software which is reasonably bug or

defect free, is delivered in time and within the specified budget, meets
the requirements and/or expectations, and is maintainable.
THE PLACE OF SOFTWARE QUALITY IN PROJECT PLANNING

➢Quality will be of concern at all stages of project planning and execution, but will be of particular
interest at the following points in the Step Wise framework (Figure 13.1).
➢Identify project scope and objectives Some objectives could relate to the qualities of the
application to be delivered.
➢ Identify project infrastructure Within this step, identifies installation standards and procedures.
Some of these will almost certainly be about quality.
Analyse project characteristics The application to be implemented is examined to see if it has
➢

any special quality requirements.

Identify the products and activities of the project It is at this point that the entry, exit and process
➢

requirements are identified for each activity.

Review and publicize plan At this stage the overall quality aspects of the project plan are
➢

reviewed.
THE IMPORTANCE OF SOFTWARE QUALITY
➢We would expect quality to be a concern of all producers of goods and
services. However, the special characteristics of software create special
demands.
➢ Increasing criticality of software
➢The intangibility of software
➢Accumulating errors during software development
➢ Increasing criticality of software- The final customer or user is naturally anxious about the

general quality of software, especially its reliability. This is increasingly so as organizations

rely more on their computer systems and software is used in more safety-critical applications,
for example to control aircraft.

➢The intangibility of software can make it difficult to know that a project task was completed
satisfactorily. Task outcomes can be made tangible by demanding that the developer produce
'deliverables' that can be examined for quality.
➢Accumulating errors during software development As computer system development
comprises steps 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.
 DEFINING SOFTWARE QUALITY
➢Functional requirements 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.
➢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 be aware.
➢Defining quality is not enough. If we are to judge whether a system meets our
requirements we need to be able to measure its qualities.
➢A good measure must relate the number of units to the maximum possible.
➢ When there is concern about the need for a specific quality characteristic in a software
product then a quality specification with the following minimum details should be drafted:

➢ definition/description: definition of the quality characteristic;

➢ scale: the unit of measurement

➢ test: the practical test of the extent to which the attribute quality exists;

➢ minimally acceptable: the worst value which might be acceptable if other characteristics
compensated for it, and below which the product would have to be rejected out of hand;

➢ target range: the range of values within which it is planned the quality measurement value
should lie;

➢ now: the value that applies currently.

 There could be several measurements applicable to a quality characteristic. For
example, in the case of reliability, this might be measured in terms of:

➢ availability: the percentage of a particular time interval that a system is usable;

mean time between failures: the total service time divided by the number of
➢

failures;
failure on demand: the probability that a system will not be available at the time
➢

required or the probability that a transaction will fail;

➢ support activity: the number of fault reports that are generated and processed
➢Associated with reliability is maintainability, which is how
quickly a fault, once detected, can be corrected.
➢ A key component of this is changeability, which is the ease with
which the software can be modified. However, before an
amendment can be made, the fault has to be diagnosed.
➢Maintainability can therefore be seen as changeability plus a
new quality,
➢ analysability, which is the ease with which causes of failure can
be identified.
QUALITY MODEL-ISO 9126
➢ The ISO 9126 standards documents are now very lengthy. Partly this is because people with
differing motivations might be interested in software quality, namely:

➢acquirers who are obtaining software from external suppliers;

➢developers who are building a software product;

➢independent evaluators who are assessing the quality of a software product, not for themselves but
for a community of users
➢ The difference between internal and external quality attributes has already been noted.

➢ ISO 9126 also introduces another type of quality - quality in use - for which the following elements have
been identified:

➢effectiveness: the ability to achieve user goals with accuracy and completeness;

➢productivity: avoiding the excessive use of resources, such as staff effort, in achieving user goals;

➢safety: within reasonable levels of risk of harm to people and other entities such as business, software,
property and the environment;

➢satisfaction: smiling users

ISO 9126 identifies six major external software quality characteristics:
➢ functionality, which covers the functions that a software product provides to satisfy user needs;

➢ reliability, which relates to the capability of the software to maintain its level of performance;

➢ usability, which relates to the effort needed to use the software;

➢ efficiency, which relates to the physical resources used when the software is executed;

➢ maintainability, which relates to the effort needed to the make changes to the software;

➢ portability, which relates to the ability of the software to be transferred to a different environment
ISO 9126 suggests sub-characteristics for each of the primary characteristics. They are useful
as they clarify what is meant by each of the main characteristics.
➢'Functionality compliance' refers to the degree to which the software adheres
to application-related standards or legal requirements.
➢ Typically these could be auditing requirements.
➢Since the original 1999 draft, a sub-characteristic called 'compliance' has
been added to all six ISO external characteristics.
➢ In each case, this refers to any specific standards that might apply to the
particular quality attribute.
➢'Interoperability' is a good illustration of the efforts of ISO 9126 to clarify
terminology.
➢'Interoperability' refers to the ability of the software to interact with other
systems.
➢ The framers of ISO 9126 have chosen this word rather than 'compatibility'
because the latter causes confusion with the characteristic referred to by ISO
9126 as 'replaceability’ (see below).
➢'Maturity' refers to the frequency of failure due to faults in a software
product, the implication being that the more the software has been used, the
more faults will have been uncovered and removed.
➢ It is also interesting to note that 'recoverability' has been clearly
distinguished from 'security' which describes the control of access to a
system.
➢ How 'learnability' is distinguished from 'operability'. A software tool could
be easy to learn but time-consuming to use because, say, it uses a large
number of nested menus.
➢ This might be fine for a package used intermittently, but not where the
system is used for many hours each day. in this case learnability' has been
incorporated at the expense of 'operability’.
➢ 'Attractiveness' is a recent addition to the sub-characteristics of usability
and is especially important where users are not compelled to use a
particular software product, as in the case of games and other entertainment
products
➢ 'Analysability' is the ease with which the cause of a failure can be determined.

➢ 'Changeability' is the quality that others call 'flexibility': the latter name is a better one as
'changeability' has a different connotation in plain English - it might imply that the suppliers
of the software are always changing it!

➢ 'Stability', on the other hand, does not refer to software never changing: it means that there is
a low risk of a modification to the software having unexpected effects.
➢ 'Portability compliance' relates to those standards that have a bearing on portability. The use of
a standard programming language common to many software/hardware environments would be
an example of this. 'Replaceability' refers to the factors that give 'upwards compatibility'
between old software components and the new ones. 'Downwards' compatibility is not implied
by the definition.

➢ 'Coexistence' refers to the ability of the software to share resources with other software
components; unlike 'interoperability', no direct data passing is necessarily involved.
➢ ISO 9126 provides guidelines for the use of the quality characteristics.

➢ Variation in the importance of different quality characteristics depending

on the type of product is stressed.

➢ Once the requirements for the software product have been established,
the following steps are suggested:
1. Judge the importance of each quality characteristic for the application Thus
reliability will be of particular concern with safety-critical systems while
efficiency will be important for some real-time systems.
2. Select the external quality measurements within the ISO 9126 framework
relevant to the qualities prioritized above Thus for reliability mean time between
failures would be an important measurement, while for efficiency, and more
specifically 'time behaviour', response time would be an obvious measurement.
3. Map measurements onto ratings that reflect user satisfaction For response time,
for example, the mappings might be as in Table 13.1.
4 Identify the relevant internal measurements and the intermediate
products in which they appear This would only be important where software
was being developed, rather than existing software being evaluated. For new
software, the likely quality of the final product would need to be assessed
during development.

5 Overall assessment of product quality To what extent is it possible to

combine ratings for different quality characteristics into a single overall rating
for the software? A factor which discourages attempts at combining 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
two products might be compared as to usability, efficiency and maintainability. The importance of each
of these qualities might be rated as 3, 4 and 2, respectively, out of a possible maximum of 5. Quality
tests might result in the situation shown in Table 13.3.
PRODUCT VERSUS PROCESS QUALITY MANAGEMENT
➢Easier to measure 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.
➢Errors can enter the process at any stage.
➢They can be caused either by defects in a process, as when software developers make
mistakes in the logic of their software, or by information not passing clearly and
accurately between development stages.
➢Errors not removed at early stages become more expensive to correct at later stages.
➢ Each development step that passes before the error is found increases the amount of
rework needed.
➢An error in the specification found in testing will mean rework at all the stages
between specification and testing.
➢Each successive step of development is also more detailed and less able to absorb
change.
➢Errors should therefore be eradicated by careful examination of the deliverables of
each step before they are 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.
➢Implementation requirements, which define how the process is to be
conducted
➢Exit requirements, which have to be fulfilled before an activity is deemed to
have been completed.
QUALITY MANAGEMENT SYSTEMS- BS ENISO 9001:2000

➢At IOE, a decision might be made to use an outside contractor to produce

the annual maintenance contracts subsystem.
➢A natural concern would be the standard of the contractor's deliverables.
➢Quality control would involve the rigorous 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
 AN OVERVIEW OF BS EN ISO 9001:2000 QMS REQUIREMENTS

The standard is built on a foundation of the following principles:

➢understanding the requirements of customers so that they can be met, or even exceeded;

➢leadership to provide the unity of purpose and direction needed to achieve quality objectives;

➢involvement of staff at all levels;

➢a focus on the individual processes which create intermediate or deliverable products and services;

➢a focus on the systems of interrelated processes that create delivered products and services;

➢continuous improvement of processes;

➢decision making based on factual evidence;

➢building mutually beneficial relationships with suppliers.

 These principles are applied through cycles which involve the following activities:

1. determining the needs and expectations of the customer;

2. establishing a quality policy, that is, a framework which allows the organization's objectives in relation
to quality to be defined;

3. design of the processes which will create the products (or deliver the services) which will have the
qualities implied in the organization's quality objectives;

4. allocation of the responsibilities for meeting these requirements for each element of each process;

5. ensuring that resources are available to execute these processes properly;

6. design of methods for measuring the effectiveness and efficiency of each process in contributing to the
organization's quality objectives;

7. gathering of measurements;

8. identification of any discrepancies between the actual measurements and the target values;

9. analysis and elimination of the causes of discrepancies.

 The procedures above should be designed and executed so that there is continual improvement. They
should, if carried out properly, lead to an effective QMS. More detailed ISO 9001 requirements include:

■ Documentation of objectives, procedures (in the form of a quality manual), plans, and records
relating to the actual operation of processes. The documentation must be subject to a change
control system that ensures that it is current. Essentially one needs to be able to demonstrate to an
outsider that the QMS exists and is actually adhered to.

■ Management responsibility-the organization needs to show that the QMS and the processes that
produce goods and services conforming to the quality objectives are actively and properly managed.

■ Resources - an organization must ensure that adequate resources, including appropriately trained
staff and appropriate infrastructure, are applied to the processes.
Production should be characterized by:

• planning; determination and review of customer requirements;

• effective communications between the customer and supplier;

• design and development being subject to planning, control and review;

• requirements and other information used in design being adequately and clearly recorded;

• design outcomes being verified, validated and documented in a way that provides sufficient information for those who
have to use the designs;

• changes to the designs should be properly controlled;

• adequate measures to specify and evaluate the quality of purchased components;

• production of goods and the provision of services should be under controlled

• conditions to ensure adequate provision of information, work instruction, equipment, measurement devices, and post-
delivery activities;

• measurement - to demonstrate that products conform to standards, and the QMS is effective, and to improve the
effectiveness of processes that create products or services
 PROCESS CAPABILITY MODELS

➢Rather than just checking that a system exists to detect faults, we might wish to check that a supplier uses
software development methods and tools likely to produce good quality software. A customer might feel more
confident
➢In the United States, a number of influential capability maturity models (CMM) have been developed at the
Software Engineering
➢Institute (SEI), a part of Carnegie-Mellon University, of which one, SW-CMM, relates specifically to
software development.
➢Recently a new version of CMM, CMM Integration or CMMI, was introduced to bring together models
produced for different environments into a single integrated framework.
➢These models place organizations at one of five levels of process maturity which indicate the sophistication
and quality of their production practices. These levels are defined as follows.
■ Level 1: Initial The procedures followed tend to be haphazard. Some projects may be
successful, but this tends to be because of the skills of particular individuals, including project
managers. There is no level 0 and so any organization would be at this level by default.

■ Level 2: Managed Organizations at this level will have basic project management procedures
in place. However, the way individual tasks are carried out will depend largely on the person
doing it.

■ Level 3: Defined The organization has defined the way that each task in the software
development life cycle should be done.

■ Level 4: Quantitatively managed The products and processes involved in software

development are subject to measurement and control.

■ Level 5: Optimizing Improvement in procedures can be designed and implemented using the
data gathered from the measurement process.
 For each of the levels, apart from the default level 1, key process areas (KPAs) have been identified
as distinguishing the current level from the lower ones. These are listed in Table 13.4.

The assessment is done by a team of assessors coming into the organization and interviewing key
staff about their practices, using a standard questionnaire to capture the information. A key objective is
not just to assess, but to recommend specific actions to bring the organization up to a higher level.
ISO 15504 PROCESS ASSESSMENT
➢ISO/IEC 15504 is a standard for process assessment that shares many
concepts with CMMI.
➢The two standards should be compatible. Like CMMI the standard is
designed to provide guidance on the assessment of software development
processes.
➢To do this there must be some benchmark or process reference model which
represents the ideal development life cycle against which the actual processes
can be compared.
➢When assessors are judging the degree to which a process attribute is being
fulfilled they allocate one of the following scores
ISO 15504 PROCESS ASSESSMENT
➢ISO/IEC 15504 is a standard for process assessment that shares many
concepts with CMMI.
➢ a set of technical standards documents for the computer software
development process and related business management functions.
➢In order to assess the process attribute of a process as being at a certain level of achievement
indicators have to be found that provide evidence for the assessment. For example, say the
requirement analysis processes of an organization were being assessed.
➢Assessors might wish to test whether the organization is at Level 3, which relates to there
being an established process. The assessor might find a section in a procedures manual
relating to the conduct of requirements.
➢This could be evidence of the process being defined (3.1 in Table 13.5).
➢They might also come across control documents which have been signed off as each step of
the requirements analysis process has been completed.
➢This would indicate that the defined process is actually deployed (3.2).
 IMPLEMENTING PROCESS IMPROVEMENT

➢Both the control and analysis software is produced and

maintained by the Software Engineering department.
➢ Within this department there are separate teams who deal with
the software for different types of equipment.
•CMMI can help us identify the order in which steps in improvement have to take place. Some
steps need to build on the completion of others.
•An immediate step would be to introduce more formal planning and control. This would at
least enable us to assess the size of the problems even if we are not yet able to solve them all.
Given a software requirement, formal plans enable staff workloads to be distributed more
carefully. The monitoring of plans would also allow managers to identify emerging problems
with particular projects.
•Effective change control procedures would make managers more aware of how changes in
the system's functionality can force project deadlines to be breached. These process
developments would help an organization move from Level 1 to Level 2.
•Figure 13.3 illustrates how a project control system could be envisaged at the level of
maturity.
•The next step would be to define carefully the processes involved in each stage of the development
lifecycle - 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.
•When more formalized processes exist, the behaviour of component processes can be monitored. We
can see, for example, the numbers of change reports generated and system defects detected at the
system testing phase.
•Apart from information about the products passing between processes, we can also collect effort
information about each process itself. This enables effective remedial action to be taken speedily when
problems are found. The development processes are now properly managed, bringing the organization
up to Level 4.
•Finally, at Level 5 of process management, the information collected is used to improve the
process model itself. It might, for example, become apparent that the changes to software
requirements are a major source of defects. Steps could therefore be taken to improve this
process.
• For example, the hardware component of the system could be simulated using software tools.
This could help the hardware engineers to produce more realistic designs and reduce changes.
It might even be possible to build control software and test it against a simulated hardware
system. This could enable earlier and cheaper resolution of technical problems.
. Figure 13.3 illustrates how a project control system could be envisaged at the level of maturity.
TECHNIQUES TO HELP ENHANCE SOFTWARE QUALITY

➢Three main themes emerge in this discussion of software quality:

➢Increasing visibility
➢Procedural structure
➢Checking intermediate stages
 These themes are fundamental to ensuring high software 3. Facilitates training and onboarding of new team members.
quality. Let's explore each in more detail: 3.Checking Intermediate Stages:
1.Increasing Visibility: 1. Definition: Regularly verifying the progress and quality of
1. Definition: This involves making the progress and current the software at various stages of development.
state of the software development process transparent to all 2. Implementation:
stakeholders. 1. Conducting code reviews and peer reviews.
2. Implementation: 2. Implementing continuous integration and continuous deployment (CI/CD)
pipelines.
1. Use of dashboards and real-time monitoring tools to track progress.
3. Performing unit testing, integration testing, and user acceptance testing
2. Regular updates and reports to keep everyone informed. (UAT).
3. Clear documentation of processes, decisions, and changes. 3. Benefits:
3. Benefits: 1. Detects and addresses issues early in the development cycle.
1. Enhances communication and collaboration. 2. Ensures that the software meets quality standards before proceeding to
2. Helps identify issues early. the next stage.
3. Facilitates better decision-making based on up-to-date information. 3. Provides feedback loops to improve the development process
continuously.
2.Procedural Structure: Focusing on these themes can significantly enhance the
1. Definition: Establishing and adhering to a well-defined set quality of the software, leading to more reliable,
of procedures and standards throughout the software
development lifecycle. maintainable, and user-friendly products.
2. Implementation:
1. Defining and documenting coding standards and guidelines.
2. Implementing development methodologies such as Agile, Scrum, or
Waterfall.
3. Standardizing processes for requirements gathering, design, coding,
testing, and deployment.
3. Benefits:
1. Ensures consistency and predictability in the development process.
2. Reduces the likelihood of errors and omissions.
TECHNIQUES TO HELP ENHANCE SOFTWARE
QUALITY

➢Three main themes emerge in this discussion of software quality:

➢ Increasing visibility A landmark in the movement towards a focus on software quality was Gerald
Weinberg's advocacy of 'egoless programming'. Weinberg encouraged the simple practice of programmers
looking at each other's code.

➢ Procedural structure At first, programmers were left to get on with writing programs as best they could.
Over the years there has been the growth of methodologies where every process in the software development
cycle has carefully laid down steps.

➢ Checking intermediate stages It is tempting to push forward quickly with the development of any
engineered object until a 'working' model, however imperfect, has been produced which can then be
'debugged'. The move towards quality practices has emphasized checking the correctness of work at its
earlier, conceptual, stages.
 number of smaller, relatively independent components developed quickly and tested at an early stage.
This can reduce some of the problems, noted earlier, of attempting to predict the external quality of the
software from early design documents. It does not preclude careful checking of the design of
components.

We are now going to look at some specific techniques. The push towards more visibility has been
dominated by the increasing use of walk-throughs, inspections and reviews. The movement towards a
more procedural structure inevitably leads to discussion of structured programming techniques and to
its later manifestation in the ideas of 'clean-room' software development.

The interest in the dramatic improvements made by the Japanese in product quality has led to much
discussion of the quality techniques they have adopted, such as the use of quality circles, and these will
be looked at briefly. Some of these ideas are variations on the theme of inspection and clean-room
development
INSPECTIONS

➢ Inspections can be applied to documents produced at any development stage. For

instance, test cases need to be reviewed - their production is usually not a high-
profile task even though errors can get through to operational running because of
their poor quality.
➢ When a piece of work is completed, copies are distributed to co-workers who
examine the work, noting defects.
➢ A meeting then discusses the work and a list of defects requiring rework is
produced.
➢ The work to be examined could be, typically, a program listing that is free of
compilation errors.
 Our own experience of using this technique has been that:

■ it is a very effective way of removing superficial errors;

■ it motivates developers to produce better structured and self-explanatory software;

■ it helps spread good programming practices as the participants discuss specific pieces of code;

■ it can enhance team spirit.

IBM made the review process more structured and formal, producing statistics to show its effectiveness.
A Fagan inspection (named after the IBM employee who pioneered the technique) is led, not by the
author of the work, but by a specially trained 'moderator'.
 The general principles behind the Fagan method

■ Inspections are carried out on all major deliverables.

■ All types of defect are noted - not just logic or function errors.

■ Inspections can be carried out by colleagues at all levels except the very top.

■ Inspections are carried out using a predefined set of steps.

■ Inspection meetings do not last for more than two hours.

■ The inspection is led by a moderator who has had specific training in the technique.

■ The other participants have defined roles. For example, one person will act as a recorder and note all defects found,
and another will act as reader and take the other participants through the document under inspection.

■ Checklists are used to assist the fault-finding process.

■ Material is inspected at an optimal rate

■ Statistics are maintained so that the effectiveness of the inspection process can be monitored
STRUCTURED PROGRAMMING AND CLEAN-ROOM SOFTWARE DEVELOPMENT

➢The way to deal with complex systems, it was contended, was to break them down
into components of a size the human mind could comprehend.

➢For a large system there would be a hierarchy of components and subcomponents.

➢For this decomposition 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
 With this type of development there are three separate teams:
■ specification team, which obtains the user requirements and also a usage
profile estimating the volume of use for each feature in the system;
■ development team, which develops the code but which does no machine
testing of the program code produced;
■ certification team, which carries out testing.
➢ Any system is produced in increments - 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 by them using
mathematical techniques.

➢ The argument is that software which is constructed by throwing up a crude program, which then has
test data thrown at it and a series of hit-and-miss amendments made to it until it works, is bound to
be unreliable.

➢ The certification team carry out the testing, which is continued until a statistical model shows that
the failure intensity has been reduced to an acceptable level.
FORMAL METHODS

➢Clean-room development, uses mathematical verification techniques. These techniques use

unambiguous, mathematically based
➢They are used to define preconditions and postconditions for each procedure.
➢Preconditions define the allowable states, before processing, of the data items upon which a
procedure is to work.
➢ The postconditions define the state of those data items after processing. The mathematical
notation should ensure that such a specification is precise and unambiguous.
➢ It should also be possible to prove mathematically that a particular algorithm will work on
the data defined by the preconditions in such a way as to produce the postconditions.
FORMAL METHODS

➢Despite the claims of the effectiveness of the use of a formal notation to define software specifications
for many years now, it is rarely used in mainstream software development.
➢This is despite it being quite widely being taught in universities. A newer development that may meet
with more success is the development of Object Constraint Language (OCL).
➢ It adds precise, unambiguous, detail to the UML models, for example about the ranges of values that
would be valid for a named attribute.
➢It uses an unambiguous, but non-mathematical, notation which developers who familiar with Java-like
programming languages should grasp relatively easily.
SOFTWARE QUALITY CIRCLES

➢ A quality circle is a group of four to ten volunteers working in the same area who meet for, say, an hour a
week to identify, analyse and solve their work-related problems.

➢ One of their number is the group leader and there could be an outsider, a facilitator, who can advise on
procedural matters. In order to make the quality circle work effectively, training needs to be given.

➢ Together the quality group select a pressing problem that affects their work.

➢ They identify what they think are the causes of the problem and decide on a course of action to remove
these causes.

➢ Often, because of resource or possible organizational constraints, they will have to present their ideas to
management to obtain approval before implementing the process improvement.
LESSONS LEARNT REPORTS

➢ Another way by which an organization can improve its performance is by reflecting on the performance of a project at its
immediate end when the experience is still fresh. This reflection may identify lessons to be applied to future projects.

➢ Project managers are required to write a Lessons Learnt report at the end of the project. This should be distinguished from
a Post Implementation Review (PIR).

➢ A PIR takes place after a significant period of operation of the new system, and focuses on the effectiveness of the new
system, rather than the original project process.

➢ The PIR is often produced by someone who was not involved in the original project, in order to ensure neutrality. An
outcome of the PIR will often be changes to enhance the effectiveness of the installed system.
➢The Lessons Learnt report, on the other hand, is written by the project manager as
soon as possible after the completion of the project.
➢ This urgency is because the project team is often dispersed to new work soon after
the finish of the project.
➢One problem that is frequently voiced is that there is often very little follow-up on
the recommendations of such reports, as there is often no body within the
organization with the responsibility and authority to do so.
TESTING

➢The final judgement of the quality of a software application is

whether it actually works correctly when executed.
➢the V-process model was introduced as an extension to the waterfall process
model. Figure 13.5 gives a diagrammatic representation of this model.
➢This stresses the necessity for validation activities that match the activities
creating the products of the project.
The V-process model can be seen as expanding the activity box 'testing' in the waterfall
model. Each step has a matching validation process which can, where defects are found,
cause a loop back to the corresponding development stage and a reworking of the following
steps. Ideally this feeding back should occur only where a discrepancy has been found
between what was specified by a particular activity and what was actually implemented in the
next lower activity on the descent of the V loop.
For example, the system designer might have written that a calculation be carried out in a
certain way. A developer building code to meet this design might have misunderstood what
was required. At system testing stage, the original designer would be responsible for checking
that the software is doing what was specified and this would discover the coder's misreading
of that document.
➢Black box and glass box testing can be distinguished.
➢Acceptance testing is an example of black box testing where the testers would not know about
the internal software structure.
➢They would simply input typical business transactions and see if the software responds in a
way compatible with the user requirements. \
➢With glass box testing the tester is aware of the internal structure and would as a consequence
be able to create test cases that check particular paths through the code. The initial program
testing could be like this. Another distinction is between verification and validation.
➢Verification focuses on the 'truth' or correctness of the application, that is, the extent to which it
follows its specification. Validation focuses more on 'value'-does it do the job for which it was
intended? Program testing may find a perfect match between the code and its specification.
➢Even so, acceptance testing might find that a 'correct' program is useless because of an
incorrect interpretation of the requirements by the designer who drafted the specification.
 When the test cases are run, the tester may raise issues, that is, reports of discrepancies between the
expected and what was found. A means of formally recording these issues and their subsequent history is
needed. A review body adjudicates on the issues. The outcome of this scrutiny would be one of the following:

■ The issue is dismissed on the grounds that there has been a misunderstanding of a requirement by the
tester.

■ The issue is identified as a fault which the developers need to correct - where development is being done
by contractors then they would be expected to cover the cost of the correction.

■ It is recognized that the software is behaving as specified, but the requirement originally agreed is in fact
incorrect - remedying this means adding a new requirement and a contractor could expect to receive
payment for the additional work.
The issue is identified as a fault but is treated as an off-specification - it is decided that the application can be
made operational with the error still in place
▪When corrections are made, tests will need to be repeated. This is where the
additional effort in creating automated test scripts can pay off.
▪ A danger is that a change introduced to correct an error could actually
introduce errors in processes that were previously running correctly.
▪When code changes are made, all tests previously carried out should be rerun.
This is known as regression testing.
QUALITY PLANS

➢Some organizations produce quality plans for each project. These show how
the standard quality procedures and standards laid down in an organization's
quality manual will actually be applied to the project
 A quality plan might have entries for:

■ purpose - scope of plan;

■ list of references to other documents;

■ management arrangements, including organization, tasks and responsibilities;

■ documentation to be produced;
■ standards, practices and conventions;

■ reviews and audits;

■ testing;

■ problem reporting and corrective action;

■ tools, techniques and methodologies;

■ code, media and supplier control;

■ records collection, maintenance and retention;

■ training;

■ risk management - the methods of risk management that are to be used.

END OF MODULE-5