ACCA P3 Business Analysis - 2010 - Study text - Emile Woolf Publishing
Подождите немного. Документ загружается.
Chapter 13: Business strategy and quality initiatives
© EWP Go to www.emilewoolfpublishing.com for Q/As, Notes & Study Guides 345
Quality in the development of information systems
Why good quality software is important for IS systems
The quality triangle for new information systems
Software quality assurance
Quality assurance and quality control in IS/IT system development
The V life cycle model
Advantages of using the V life cycle model
The Capability Maturity Model
4 Quality in the development of information systems
4.1 Why good quality software is important for IS systems
The term ‘IS/IT system’ is used to mean an information system that is provided
through a computer system or computer network. IS/IT systems can be extremely
important for business strategy.
Important new strategic developments might depend on the development and
implementation of a major new IS/IT system.
IS/IT systems can deliver significant added value, through greater efficiency
and lower costs, of improved service standards (such as speed and reliability).
Successful IS/IT systems can give an entity a sustainable competitive advantage
over competitors, when the IS/IT system is developed internally as a ’bespoke’
or ‘tailor-made’ system. It might take competitors a long time, and cost them a
lot of money, to copy a rival’s bespoke system.
Developing a major new IS/IT system can expose an entity to considerable risk, in
the event that the new system development goes wrong. A new system might be
implemented late or might cost more than expected. More significantly, a new
system might fail to do what it was designed for. Instead of providing competitive
advantage, a failed IS/IT system might reduce the quality of products or services to
customers. This could put the entity at a serious competitive disadvantage to its
rivals.
Quality features of software
When a new system is developed, the user wants the software to be of a high
quality. Software can be assessed according to several quality characteristics.
It should function correctly. The software should function in the way specified
in the user requirements for the system. If software does not function as
intended, the user may have an inefficient or an ineffective system that fails to
achieve all its objectives.
It should be robust. Software is robust if it operates without faults, and the
system does not ‘crash’ continually. A system may crash, for example, because it
Paper P3: Business analysis
346 Go to www.emilewoolfpublishing.com for Q/As, Notes & Study Guides © EWP
cannot handle the work load. When a system ‘crashes’ (or when ‘the system is
down’) the user’s operations come to a halt.
It should be fairly free from ‘bugs’. Software may contain ‘bugs’ that do not
cause a system crash, but that result in data being processed incorrectly, or input
being rejected. It is virtually impossible to write software for a bespoke system
that is ‘bug-free’, but in good quality software, the bugs are relatively few in
number and not serious.
It should be user-friendly. User-friendliness has been described in an earlier
chapter. If software is not user-friendly, the user may be reluctant to use it, and
some of its useful functions may not be used at all.
The quality of software can also be assessed in terms of conformity to requirements,
reliability, usability and degree of excellence.
Conformity to requirements. Software should do what it is supposed to do, and
conform to the user’s requirements. What the user requires from the IS/IT
system and what is formally specified are not always the same, because there
might be weaknesses in the formal specification for the new system. A good
quality IS/IT system is therefore one that meets user requirements, so that the
user does not have to ask for amendments and changes to the system after it has
been introduced. The problem of failure to meet user requirements can be
reduced through suitable user acceptance testing (explained later).
Reliability. The IS/IT system should be reliable. This is not simply a matter of
eliminating errors in programs. Systems might suffer in practice from excessive
‘down time’ and insufficient availability to the user. Excessive system downtime
might possibly be due to the fact that it was not properly designed to handle
such a large volume of processing.
Usability. As explained above, good quality in software can also be measured by
its user-friendliness and the ease with which users are able to use it.
Degree of excellence. The quality of an IS/IT system can also be judged by
factors such as:
- whether it is relatively easy to maintain
- whether it is flexible and can be adapted for other uses, and
- whether it can be expanded to handle a larger volume of ‘traffic’ or
transactions.
4.2 The quality triangle for new information systems
In view of the importance of many bespoke IS/IT systems for business strategy,
quality management is a key issue in IS/IT system development. New system
development projects must meet certain targets or standards. Quality in IS
development relates to three factors:
cost
time
performance.
Chapter 13: Business strategy and quality initiatives
© EWP Go to www.emilewoolfpublishing.com for Q/As, Notes & Study Guides 347
Cost
‘Cost’ as a quality factor in systems development means developing a new IS/IT
system on budget, without overspending. If costs exceed budget, there is a risk that
the system will fail to provide the required return on investment.
Time
‘Time’ in new system development means that the system should be developed and
implemented on time (on schedule). Delays can be expensive, especially when there
is a competitive advantage in implementing a new system ahead of similar systems
that competitors might be developing.
Quality
‘Quality’ here means that a system should meet its design specifications, and
perform to the standards that are expected of it.
Compromise between cost, time and performance quality
When new IS/IT systems are designed and developed, a compromise must usually
be made between cost, time and performance specifications. However, once the
specifications for a new system have been agreed, with an associated budget for
expenditure and time schedule for completion, management should try to ensure
that the system is designed and implemented within budget and on schedule and
that it meets its performance specifications.
4.3 Software quality assurance
Software Quality Assurance (SQA) can be defined as a planned and systematic
approach to achieving quality in software development, by means of adherence to
standards:
for software products, and in software development processes and procedures,
and
for the evaluation and testing of software.
SQA includes ensuring obtaining assurance that standards are established and
applied throughout the life cycle for software development or acquisition.
Cost
Quality Time
Paper P3: Business analysis
348 Go to www.emilewoolfpublishing.com for Q/As, Notes & Study Guides © EWP
Standards provide a framework for developing new software, and they provide
established criteria or benchmarks for comparison with actual development and
control processes.
There should be quality assurance ‘approval points’ at certain stages throughout an
IS/IT development project, where an SQA evaluation of the project is made in
relation to the applicable standards.
New software should be both validated and verified before it is implemented.
Validation means ensuring that the software is designed to do what the user
requires it to do.
Verification means ensuring that the software conforms to its design.
4.4 Quality assurance and quality control in IS/IT system development
There are external quality standards for software development. As indicated above,
standard procedures and processes are an important part of quality assurance. The
benefits of IT Standards are:
to ensure conformity to best IT practice throughout the organisation and in the
industry (quality assurance): this will ensure that the desired quality of software
and IS system is achieved
to control computer system operations and practices, and to encourage
continuous improvement.
The application of IS standards means that:
well-established industry-wide procedure standards are applied
standard documentation is produced for system design and program design
program coding is developed in accordance with standards
testing is carried out in accordance with recognised standards.
IT Standards cover all aspects of IT development and operations, including:
hardware and software procurement
control and security procedures
systems development and implementation, including testing
documentation.
Whereas quality assurance is concerned with the application of suitable procedures
and methods to achieve quality, quality control is concerned with testing.
Quality control in IS/IT system development involves regular testing software
and systems against the desired quality standards, design specifications and
user requirements. It involves a formal use of testing and acting on the results of
the tests.
Quality assurance in IS/IT system development goes beyond quality control. It
is concerned with the application of processes, methods and documentation
standards, whereas quality control focuses on what comes out of the process.
Chapter 13: Business strategy and quality initiatives
© EWP Go to www.emilewoolfpublishing.com for Q/As, Notes & Study Guides 349
4.5 The V life cycle model
The V life cycle model for IS/IT system development is commonly used to ensure
that appropriate quality assurance is exercised at each stage of a new IS/IT system
development project. The model gets its name because the stages of design and
testing for a bespoke IS/IT system can be shown in a ‘V’ model, as follows.
(The name ‘V’ model comes from the shape.)
The V model shows the stages of system development, and the associated (dynamic)
testing for each of those stages. (Dynamic tests are tests on the software itself. They
involve tests of individual programs or the system as a whole, to check whether
these meet the specifications. Unit testing, systems testing and acceptance testing
are all examples of dynamic testing.)
The stages in developing a new system are shown on the left hand side of the V,
starting at the top left hand side and moving down to the bottom of the V.
The stages in testing and implementation are shown on the right hand side,
starting at the bottom of the V and moving up to the top right hand side.
Feasibility study
A feasibility study is carried out into the potential benefits of a new IS/IT system.
The purpose of the study is to assess whether a new IS/IT system is feasible, what it
would do, the benefits that it would provide and the time required for
implementation. The study should include a financial evaluation of the proposed
information system. A report is prepared for the department or business unit that
will be responsible for the new system, and a decision is taken to go ahead with the
system development (or decide not to go ahead).
Analysis
The next stage in the system development is the preparation of an outline
specification for the new system. This outline design specification states in greater
detail than the feasibility study report what the system should be capable of doing,
and what it should cost to develop and operate.
Paper P3: Business analysis
350 Go to www.emilewoolfpublishing.com for Q/As, Notes & Study Guides © EWP
Design
After a system has been defined by an outline specification, it is then planned in
greater detail, by systems analysts. The total system is divided into units
(programs), and specifications are prepared for how the units should integrate to
produce the required output for the system as a whole. For example, the design of a
bespoke accounts system might be prepared with separate programs or modules for
the main ledger, receivables ledger, payables ledger, cost accounting, payroll,
management information and so on. The output from this stage of the development
is a detailed system specification.
Program specification
When the system has been specified in detail, and divided into separate programs
or modules, a specification must be prepared for each individual program. This
specification is used by the software programmers to write each program.
Coding
When the individual program specifications have been prepared and approved, the
next stage is to write the programs. Coding is the activity at the bottom of the V.
The activities that follow on the right-hand side of the V are all testing activities.
Unit testing
Unit testing is the first stage of testing. Each individual program (‘unit’ of the total
system) is tested in isolation. Unit testing of individual programs is also called
program testing. The purpose of unit testing is to test whether the program as
written meets the requirements set out in the program specification. (The program
specification is on the same line of the model as unit testing, on the left-hand side of
the V.)
Dynamic testing on a program is carried out by creating test input data for the
program and comparing the actual output from the tests against the expected
output.
Example
A simple example of planning a test on software would be a test on a field of data
input for the month of the year. The program may specify that the month must be
two digits, between 01 and 12. The person testing the program may decide to carry
out several tests to confirm that the program will process input into this field of
data correctly. He might do this by devising a test with six test items, as follows.
Test item: Entry in the
‘month’ field of data
Expected output Actual test
output
04 Entry accepted.
11 Entry accepted.
01 Entry accepted.
00 ‘Invalid entry’ message on screen. Entry not accepted.
7 ‘Invalid entry’ message on screen. Entry not accepted.
14 ‘Invalid entry’ message on screen. Entry not accepted.
Chapter 13: Business strategy and quality initiatives
© EWP Go to www.emilewoolfpublishing.com for Q/As, Notes & Study Guides 351
Devising suitable and comprehensive tests is difficult, because very large quantities
of test data would be required to test a program comprehensively. However, the
tester should try to devise specific tests that are as comprehensive as possible.
Successful program tests are unlikely to provide a complete assurance that a system
will function according to specifications. There are several reasons for this.
Program tests are tests on individual programs. They do not test how individual
programs within the system interact with each other. Integration tests/system
tests (including performance tests) are needed to check whether the system as a
whole functions according to specifications.
It is usually impossible to devise test items for every logical combination of
possible inputs, because there will be too many to test. Since testing cannot cover
100% of all possible situations, there will always be a risk that the software will
not perform properly to specifications. This is a major reason why software
errors are commonly found after a system has been implemented operationally
(after systems tests and user acceptance tests, although these tests may uncover
some errors that the program testing failed to identify.)
The user may eventually try to use the system in a way that was not predicted,
and may input data or instructions that cause the system to fail.
Integration testing
Integration testing follows after unit testing. Integration tests are tests to check
whether the program modules or units are fully integrated with each other. A
program might work as specified in isolation, but it might not work when it is
operating with other programs in the system. The testing aims at trying to ensure
that:
The individual programs in the system integrate with each other properly. For
example, the tests should show that data transferred from one program to
another is not lost or corrupted in the transfer process.
The system interfaces correctly with other systems, if this is a user requirement.
The system performs as required.
The tests should include devising items of test data to process through the system,
and checking whether the input has been processed correctly, that the data files are
correct and that output from the system is also as expected.
Integration testing can also be defined as a test that the system software as written
meets the detailed design specifications prepared by the systems analysts. (The
design specification is on the same line of the model as integration testing, on the
left-hand side of the V.)
System testing
System testing may be carried out at the same time as integration testing. System
testing is concerned with making sure that the system meets its performance
objectives and that it will perform to the user’s expectations, does what it is
supposed to do, is user-friendly and robust. Taken together, integration testing and
Paper P3: Business analysis
352 Go to www.emilewoolfpublishing.com for Q/As, Notes & Study Guides © EWP
systems testing provide a check that the system that was specified has been
delivered.
Load testing or stress testing might be an element of system testing. This type of
test is carried out to see how the system performs when it is required to process
large amounts of transactions or handle large numbers of terminals concurrently.
The system is tested under extreme conditions (conditions of ‘stress’). The purpose
of stress testing is to check that the system is capable of handling an unusually large
volume of transactions within a short period of time, without performance being
adversely affected. For example, a network system with 50 terminals might be
tested to see how it performs if all 50 terminals are demanding access to a central
server at the same time. Stress testing is also called load testing.
Tests might find, for example, that processing times deteriorate significantly when
the system has to process large volumes of data, or response times might become
much longer when the system is responding to inputs from a large number of
terminals. In some cases, tests might find that the system crashes during load
testing/performance testing.
At the end of successful system testing, the system is handed over to the user for
testing.
Acceptance testing
Systems tests check whether a system meets the specifications for the system that
have been developed by the systems analysts. The system specifications are based
on what the systems designers consider to be the user’s requirements.
Acceptance testing, in contrast, provides an opportunity for the user to test whether
the system meets the original business objectives for the system. These may differ
from the formal system specifications, where the design is flawed or where the user
specifications were inexact.
Acceptance testing is the final stage of testing. The tests are carried out by the user’s
staff, using the hardware for the system when it becomes operational.
In other words, the purpose of acceptance testing is to test whether the system
successfully delivers what was requested in the feasibility study. (The feasibility
study is on the same line of the model as acceptance testing, on the left-hand side of
the V.)
At the end of successful acceptance testing, the new system is ready for
implementation.
There are two main aspects to user acceptance testing:
functionality testing. This is testing by the user to ensure that the system
performs all the functions that it is supposed to, as specified in the system
requirements.
usability testing. This is testing to see how easy the system is to learn and use.
Chapter 13: Business strategy and quality initiatives
© EWP Go to www.emilewoolfpublishing.com for Q/As, Notes & Study Guides 353
In addition, since acceptance testing usually involves testing the system with large
amounts of test data, it also provides an opportunity to:
identify more errors in the software or system design that were not discovered
during program tests or system tests, and
train the staff of the computer user in how to operate the system.
Acceptance testing may discover errors and weaknesses in the system that are not
identified by system testing:
Users may input data or commands in ways that the systems designers did not
anticipate, and error conditions may be found that had not been provided for by
systems testing.
The user’s staff may test for ‘real world problems ‘ - conditions and situations
that the systems designers did not anticipate in the system design.
Acceptance testing may test the system with larger volumes of data that systems
testing. This increases the likelihood that some software errors will be found that
the program and systems testing did not find.
Testing with larger volumes of test data may also provide useful performance
testing of the system (processing speeds, response times, ability to handle
processing loads without crashing).
Acceptance testing on the actual hardware that the system will use may find that
there is incompatibility between the software and the hardware, that earlier tests
were unable to check.
The user is able to test the ‘usability’ of the system, and identify features that
should be made more user-friendly.
4.6 Advantages of using the V life cycle model
The V model therefore maps each stage of ‘dynamic testing’ on the right-hand side
of the V to a corresponding stage of system development on the left-hand side of the
V. The advantages of the V model are as follows:
Tests are performed against specifications that are pre-determined at each stage
of the IS/IT project development.
It specifies who is responsible for testing at each stage. For example, users will
carry out acceptance testing; programmers will carry out unit testing.
It sets out coherent and consistent stages for the testing process.
It defines the testing that must be done at each stage before development can
progress. There’s no point jumping to an integration test if the units do not work
properly.
Testing is high on the agenda from the start of the project. It becomes much
more expensive to correct software as projects progress, so testing should start at
the earliest stages possible.
The V model, if properly applied, therefore helps to ensure system quality.
Paper P3: Business analysis
354 Go to www.emilewoolfpublishing.com for Q/As, Notes & Study Guides © EWP
The importance of planning and documenting each test
All tests should be planned. The test plans, and the results of the tests, should be
documented.
Tests on software and systems must be planned for several reasons:
The person carrying out the tests has to make sure that the program or system
meets its specifications. To do this, specific tests must be devised. Each part of
the specification must be tested. In software testing, all logical combinations of
input or processing conditions must be tested. Planning is needed to make sure
that nothing is overlooked.
A test is a check on whether a program or the system will work in the way that
should be expected. A program or system works properly only if it processes
data in the way that it is expected. To carry out the check, it is necessary to
compare the actual output from a program or system, and compare it with the
output that should be expected.
Test plans can be documented, and the results of each test recorded to confirm
that the software or system passed each test successfully. Errors that are found
in the tests should also be recorded, and further tests should be planned and
recorded after the error has been corrected. The documentation of testing
provides a record that the testing has been successfully completed.
Planning tests provides a system for control over testing procedures and
systems. If an error is found after testing has been completed, the test plans and
results can be checked to find out why the error was not identified in testing.
Presumably, when errors are not found in testing, the tests were not thorough.
4.7 The Capability Maturity Model
The Capability Maturity Model (CMM) was developed by the Software Engineering
Institute (SEI) of Carnegie Mellon University. It describes how entities develop
software. The model recognises five stages that entities progress through as they
become more sophisticated in their use of IT.
The CMM concentrates on evaluating an entity’s ability to perform its software
development processes successfully and it gives guidance on how to improve these
capabilities. The model is therefore often referred to as the Capability Maturity
Model Integration (CMMI) process.
The CMM identifies 5 levels of capability in processes. This applies to all processes,
but in particular to the development of new software (IS/IT systems). Entities are
encouraged to move up to a higher level, and the model provides guidance for an
entity that is at one level on the best way of moving up to the next level.
The objective of SEI was to bring discipline to the development of software. This
should result in better-quality software that could be developed in a more
predictable way so that there is a greater chance of staying within the cost, quality
time constraints. The approach relies on:
Identifying current capability level.
Identifying required or desired capabilities of the next level.