Design, Development, Testing

and Acceptance

Chapter 63
63.1 Waterfall Model
63.2 Structured Programming
63.3 Software Design
63.4 Module Design
63.5 Walkthroughs
63.6 Software Development
63.7 Support Tools
63.8 Test Specifications
63.9 Test Methods
63.10 Module Testing
63.11 Software Integration
63.12 System Integration
63.13 Acceptance Testing
63.14 Project Management
63.15 Personnel Management
63.16 Comments

As with previous chapters, this one addresses the 63.1 Waterfall Model
turnkey scenario and covers the design, develop-
ment and testing of the system. These activities An understanding of the system life-cycle provides
are carried out by the supplier, as indicated in Ta- the basis for this chapter: it is detailed in the draft
ble 59.1, the end user becoming involved again at standard IEC 61713. In essence, a system develop-
ment project is broken down into logical stages,
the acceptance stage. This chapter concentrates on
the application software since hardware design for as depicted in the form of the so-called waterfall
process control,which comprises the configuration model of Figure 63.1. There is a direct correspon-
of the supplier’s standard units, is invariably rela- dence between the various design and develop-
tively straightforward. For a more thorough treat- ment stages and the testing and integration stages
ment of the issues the reader is again referred to with which they are aligned.
the STARTS handbook (1989), the IEE guidelines The waterfall model is generic in the sense that
(1990) and the GAMP guide (1995). it applies to any system development of which there
is a large software component. It is particularly ap-
propriate for projects where the application soft-
ware is to be developed and it can be presumed that
standard system software (tools, operating system,
etc.) exists. The model does largely apply to pro-
 500 63 Design, Development, Testing and Acceptance

Formulate URS

Develop DFS System acceptance

Design hardware Integrate system

Design software Integrate software

Design modules Test modules

Develop software

Fig. 63.1 Waterfall model of system life cycle

cess automation projects, although some stages are cation. Modules are then integrated, i.e. combined
much more significant than others. Nevertheless, in groups as appropriate, and tested against those
all the stages do exist and the model provides a parts of the software design that applies. The soft-
useful framework for any project. ware can then be installed on the system hardware
Starting with the DFS, it breaks the project and system integration tests carried out. Finally,
down into a hardware design and a software de- the integrated system can be tested against the DFS
sign. It might seem odd that hardware design is for acceptance purposes.
included in what is essentially the software life cy- The principal advantage of the waterfall model
cle but this is necessary because, ultimately, the is that each stage is defined in terms of its deliver-
software has to be integrated with the hardware ables, i.e. designs, test procedures, code, etc. and is
for testing and acceptance purposes. not complete until the deliverables have fully mate-
Software design essentially consists of parti- rialised. The stages therefore can be considered as
tioning, or decomposing, the software require- project milestones. If metrics exist for each mile-
ments for the system into sub-systems or modules. stone, they can be used to quantify progress with
The modules are autonomous, as far as is reason- the project.
ably practicable, so that they can be developed in- As a general rule, the next stage of a project
dependently of each other. It follows that a major should not start until its previous stage is com-
consideration at the software design stage is the in- plete, but it is important not to apply this rule too
teractions between the modules and the interface rigidly. If the specification for a standalone module
between the modules and the rest of the system. Of has been completed, there is no reason why cod-
particular interest here is the control of modules, ing of the software for that module cannot start,
such as their mode of operation, and the flow of even though other module specifications are in-
data and status information between them. complete.
For every module a detailed specification is de- Sometimes, software development requires a
veloped in terms of its functionality and data re- certain amount of experimentation to establish the
quirements. The software for each module is de- general design concepts.The rigid staged approach
veloped and tested against that module’s specifi- of the waterfall model is inappropriate for this and
 63.2 Structured Programming 501

prototyping should be allowed to proceed with the 1

minimum of formal procedures until the concepts
become established. Then, the discipline of devel-
oping design specifications and formal testing is
2 5 9 10
imposed.
The waterfall model encourages a structured
approach to software development. It should be
evident that for each stage there has to be a care- 3 4 6 8 11 13 15
ful analysis of the design requirements prior to the
detailed software design itself. 7
12 14

Fig. 63.2 A structure chart for decomposition of requirements

63.2 Structured Programming
2. Data flow diagrams. These are an analysis tool,
Structured programming is an approach to analy- the basic components of which are as depicted
sis and design that is strongly advocated by soft- in Figure 63.3. The circles indicate a process
ware scientists. The two most commonly referred that adds to, modifies or deletes data within the
to methods are due to Jackson and Yourdon: both module and the arrows indicate the direction of
are consistent with the waterfall model. Their ap- flow into or out of the processes. Boxes indicate
proach comprises: an external entity: a person or another module
outside the boundary of the module being stud-
• Decomposition of complex systems into simpler ied. External entities originate or receive data
sub-systems or modules. being processed by the module. Rectangles in-
• Analysing, designing and implementing the in- dicate data storage,either of a temporary nature
terfaces between the modules. or a permanent data file.
• Analysing,designing and implementing the pro-
cesses that go on within the modules.
process
Structured programming relies heavily upon di-
agrammatic representations of structures, data process
flows and processes:
process
external
1. Structure charts. These depict the decomposi- entity
tion of the software requirements into modules,
as shown in Figure 63.2, and show the over-
all software structure. In particular, they in- data storage
external
dicate the relationships between the modules, entity
i.e.. whether they are in parallel or sequential.
Each module is controlled by the next highest Fig. 63.3 The components of a data flow diagram
in the structure.The convention is that modules
would be executed in the order depicted unless It is important to appreciate that data flow di-
the logic within the modules determines other- agrams do not indicate how the a module is to
wise. be physically realised. They can be developed
The approach of decomposition first, followed independent of any hardware considerations.
by the detailed design of individual modules, is 3. Process descriptions. Once a data flow diagram
often referred to as being “top-down”. is complete, the operations that go on within
 502 63 Design, Development, Testing and Acceptance

each process have to be specified in sufficient 63.3 Software Design

detail to provide a basis for complete and un-
ambiguous coding to be developed. It doesn’t Starting with the DFS, and assuming the hardware
matter how they are articulated: the purists ad- design exists, the application software may be de-
vocate both decision tables and decision trees signed. Remembering that the objective is to de-
but, in practice, the most common means of compose the software requirements into modules
that are as autonomous as is practicable, the top
representation are pseudo code, sequence flow
diagrams (SFD) and sequential function charts down approach of Figure 63.2 prevails. First, the
(SFC). All of these are described in Chapter 29. application software is categorised according to the
software types supported by the system, typically:
A sacred cow in structured programming is the • Configurable for analogue functions such as
avoidance of jumps in program flow, other than control schemes, loops and channels.
forwards. Thus designs in pseudocode should • Semi-configurable for displays, logs, etc.
avoid the use of “goto” and “jump to” label types • Procedural for sequencing, batch process con-
of construct. Branching has to be realised implic- trol, etc.
itly by means of the conditional and iterative con- • High level language for more esoteric applica-
structs, and the nesting thereof. This prevents the tions.
development of spaghetti code and makes for eas- For the configurable software, design is essen-
ier understanding, testing, etc. tially a question of identifying every analogue con-
Another important principle is that each sub- trol scheme, decomposing each into control loops,
module, e.g. phase, should have a single entry and channels, etc. and allocating them to modules as
exit back to its parent module which makes for appropriate. Similarly for discrete devices, logic
good maintainability. This point is fundamental to functions and channels. The subsequent module
the S88 concept of creating procedures and/or op- design is straightforward.
erations by configuring pre-defined phases from a For the semi-configurable software, module
library. design is almost trivial. It is essentially a question
The concepts of structured programming are of identifying the displays,trends,etc. required and
applicable to process automation, but only to a grouping them as appropriate within the display
limited extent. That is because the majority of hierarchy as described in Chapter 42.
projects are based on an existing control system, For the procedural software, the top down
such as a DCS, SCADA or PLC, chosen through the approach of structured programming applies re-
vendor selection process. Such systems have their sulting in structure charts. Decomposition into
own software environments and support exten- modules is largely determined by the software
sive standard software, both for both configurable structures supported by the system. For example,
functions and procedural code. These impose their using S88 constructs,decomposition of procedures
own structure on the application software design. would typically be into operations and phases ac-
Structured programming is therefore most cording to the methodology outlined in Chapter 37.
useful in relation to those parts of a project that are The decomposition is a non-trivial task because,
not structured a priori. The obvious example is in as emphasised in Chapter 37, great care has to be
the use of higher level language programs used for taken in defining the boundaries between entities
realising more advanced aspects of process control, such that the correct relationships between the
in optimisation for example. procedural and physical models are established.
Note that the phases are identified by name and
function only at this software design stage.
 63.4 Module Design 503

Any non-trivial high level language applications structured, perhaps too much so for design pur-
could be decomposed into modules according to poses, but are directly executable.
the principles of structured programming. How-
ever, these are few and far between: for most sys- For high level language applications the same ba-
tems the emphasis is overwhelmingly on the con- sic approach of developing a data flow diagram
figurable and procedural categories. for each module is appropriate, as per Figure 63.3,
The software design provides the basis for de- resulting in detailed designs for each of the sub-
veloping specifications used for testing the mod- modules identified.
ules at the software integration stage. It also pro-
vides the basis for any preliminary COOP studies,
as described in Chapter 54.
63.5 Walkthroughs
A design walkthrough helps to verify that a mod-
63.4 Module Design ule’s design fulfils the requirements of the DFS.
A formal meeting, i.e. one that is minuted, is ar-
For configurable functions the design is relatively ranged between the designer of the module, the
mechanical. For each module standard function team leader, and one or two other team members
blocks are identified which, when configured, will whose own designs interface to the module un-
realise the functionality required. The detailed de- der consideration. The relevant documentation is
sign comes in the specification of the correspond- circulated prior to the meeting and the designer
ing data blocks. The design thus consists of config- “walks” the team through the design. It is impor-
uration diagrams and database tables. Examples tant that there be a constructive attitude during
are provided in Chapters 44–46. this process: designers are often overly sensitive to
For sequencing applications the detailed de- criticism! Such walkthroughs provide the opportu-
sign is much more involved. The basic approach nity to ensure that the module’s functionality and
of developing a data flow diagram for each mod- interfaces are correct. It is not uncommon for such
ule applies, as per Figure 63.3. This may not be walkthroughs to lead to significant design changes.
necessary for every module: it all depends on the If the process and/or plant is of a hazardous
complexity of the module and the structure im- nature and malfunctions and/or mal-operation of
posed by the system.Noting that a module typically the control system can potentially contribute to the
equates to an S88 operation, the processes (circles) occurrence of hazardous events, then the design
identified in the data flow diagrams may be re- of the application software should be subject to a
lated to phases and/or steps. These then have to be formal COOP study rather than to a simple walk-
specified in detail, normally by means of pseudo through. This is as described in Chapter 54.
code, SFDs and SFCs, all of which are described in
Chapter 29:
• Pseudocode: typically simple structured English
language. This is relatively easy to write and un-
63.6 Software Development
derstand and converts readily into code such as Configuration and coding can commence once the
structured text. module designs and module test specifications are
• Sequence flow diagrams: probably the most pop- complete. These clearly have to use the standard
ular means which are also easy to write and functions and languages supported by the target
understand. They give the impression of being system.
structured but are in fact free format. It is important to encourage good configura-
• Sequential function charts. These are the high- tion and coding practices since these make the ap-
est level of the IEC 61131 languages and are very plication software more understandable and hence
 504 63 Design, Development, Testing and Acceptance

easier to modify and maintain. To this end, sup- only does this speed up software development but
pliers will have documented guidelines for good also encourages conformance with the guidelines.
practice in addition to their normal programming CMS automatically provides a complete ver-
manuals and the quality procedures must ensure sion control system by logging all changes between
their adherence. one version of a program and the next, record-
As a module is being configured or coded, the ing parent-offspring relationships. Also, the appli-
programmer should be encouraged to check it as cation software comprises many modules, several
carefully as possible.Upon completion,the module thousand is not uncommon, most of which are re-
should be informally checked for consistency with alised by separate programs.So,another important
the module design and conformance with the rele- feature of CMS is its system build facility which
vant guidelines and standards. This will generally ensures that when the application software is com-
involve the programmer and team leader only. It is piled, no programs are inadvertently omitted and
not necessary at this stage, but does no harm, to the latest version of each is used.Version control is
refer to the test specification. fundamental to quality procedures.
Other benefits of IPSE include:
• Availability of all software on-line, both for
63.7 Support Tools product and project management.
Both computer aided software engineering (CASE) • Ability to develop application software away
tools and integrated programming support envi- from the target machine.
ronments (IPSE) exist to support the development • Automatic file back up.
of software and can make a major contribution • Sophisticated configuration and text editing fa-
to the quality and cost effectiveness of the prod- cilities.
uct. CASE tools alone are little used by suppliers • Logging of standard software faults and fixes.
involved in application software development: the • Facility to test software using simulated I/O sig-
principal benefits are realised from an IPSE. nals and track the response.
CASE tools are computer based means of devel- • File ownership enabled by grouping of files on
oping and maintaining all the documentation gen- user/account/project basis.
erated during the life cycle of a software project. • File protection based on ownership and access
This includes both data flow diagrams, so good privileges for users and projects.
quality graphics are essential, and pseudocode. A
particularly powerful CASE feature is the ability There is evidence that use of an IPSE for applica-
to enable executable prototypes to be developed tion software development increases efficiency by
from user generated displays. Thus, for example, some 25% compared with conventional means.
the structured text could be automatically gener-
ated from a sequential function chart.
Typically,an IPSE is a network of PCs with soft-
63.8 Test Specifications
ware for supporting both software development It is at the software design stage of the waterfall
and project management. In addition to CASE model, where the interactions between the mod-
tools, an IPSE provides a language sensitive edi- ules are first considered, that the test specifications
tor (LSE) and a code management system (CMS). for each module are formulated. They will almost
The LSE is used for code development. It pro- certainly have to be refined and expanded in the
vides templates of standard language constructs light of the detailed module designs. Many of the
for the programmer, based on the supplier’s guide- requirements for testing will not be identified,
lines for good practice. These can be cut, pasted or cannot be resolved, until the detailed module
and edited as appropriate for the program. So, not design stage.
 63.9 Test Methods 505

The key issues that must be addressed for each In relation to the waterfall model,at the lower levels
module, and for logical groupings of modules, of module testing and software integration, testing
are the: tends to be done by means of simulation,especially
• Functionality of the module. if the development is IPSE based in the first place.
• Expected outcomes for given input scenarios. Physical means tend to be used at the higher lev-
• Data to which the module requires access. els of the model, especially where the end-user is
• Initialisation of the module in terms of data and involved for acceptance purposes.
status information. However, it is worth noting that physical means
• Basis for entering and exiting a module. require access to the system’s hardware which can
• Means of controlling the module’s mode, e.g. become a project bottleneck. Testing by means of
run, hold, stop, etc. simulation decouples testing from hardware avail-
• Data within the module that is accessed and/or ability. This means that simulation based testing
changed by other modules. of modules and software integration can start ear-
• Scope for the module producing invalid results. lier and in parallel to hardware testing. There is
• Robustness of the module at handling/rejecting much evidence that this approach can substan-
invalid inputs. tially reduce the time scale and cost of system
development.
There should be a separate test specification for Testing by simulation means testing the func-
each module, and it must be possible to relate an tionality of the module with simulated I/O signals.
individual test to the module to which it belongs. The principle is simple: known simulated inputs
Each specification must specify the test environ- are applied to the module, separately or in combi-
ment,the tests themselves,test inputs and expected nation as appropriate, the module is executed, and
outputs.All the tests for a particular module should the real outputs are tested for expected values.
be held in a single document which bears the mod- Analogue I/O signals are created by setting val-
ule name for traceability. Note that these are differ- ues of signals in the database at known values
ent from the test specifications required for soft- and either holding them constant, applying step
ware integration. changes, or ramping them up or down at user de-
The module test specifications cannot be fina- fined rates. Feedback can be established by con-
lised until the detailed module design is complete, necting outputs to inputs and incorporating scal-
and software development should not commence ing factors, lags and delays to provide some dy-
until the test specifications have been formally ap- namics. Discrete I/O signals are simply set true or
proved. These test specifications are the basis for false in specified combinations and orders, often
module testing and for the software integration driven by a user defined table.
specifications. As such, they become an integral A powerful extension to this, supported by
part of the software quality procedures. more sophisticated systems, is to use the appli-
cation software to test itself. Thus, for example,
the sequence executive (SEX) enables a sequence
to be run in a test mode in which the sequence
63.9 Test Methods is disconnected from the real I/O. Analogue loops
Testing is realised by means of a mixture of sim- and discrete devices are automatically closed with
ulation and physical methods. The methods used pre configured lags, delays, ramps, etc. to emu-
vary according to availability of equipment, to the late the plant. Alternatively, inputs can be config-
functionality of the system, to the time scale and ured not to respond to check faulty device opera-
size of the project, and in accordance with what tion. The sequence is then executed and a monitor
was agreed by the end-user in the DFS. There is no tool, as described in Chapter 41, used to observe
single correct approach. progress.
 506 63 Design, Development, Testing and Acceptance

An alternative IPSE based means of testing mod- The order in which the function blocks, or al-
ules is to write a separate test program which is gorithms, are executed in a loop can be critical
designed to exercise the module thoroughly and and should be tested carefully. Some systems
to log the response. The test program consists of have a loop testing facility which allows each
a string of commands written to vary the inputs, algorithm to be run in turn and the result in-
or order and combination of inputs, in a speci- spected. This is particularly helpful for check-
fied way. It can also include commands for testing ing calculations.
the effect of fault conditions, change of mode, etc. It is also normal to test out the non-control
The module being tested and the test program are functionality of loops and/or schemes at this
run simultaneously: both interact with the same stage. This embraces initialisation, fail-safe fea-
database values. tures, mode changes, fallback options, etc.
Testing by physical means requires that the hard- For configuration tests, in addition to equip-
ware of the system being delivered is available. ment listed above, extensive use is made of the
Or, if the application software only is being tested, configurator and editor tools as described in
then some equivalent development system must be Chapter 41.
available. The following test methods apply: Loop dynamics may be tested using the system
itself to simulate plant dynamics, using holds,
1. I/O channels: for each channel, input or out- steps and ramps as described above. However,
put, analogue or discrete, the signal must be
the testing of loop dynamics is normally de-
exercised over its full range and the expected
ferred until commissioning when the loop tun-
outcome observed. For example, varying an
ing itself is carried out.
analogue input enables the functioning of the
3. Sequences. The basic approach is to exercise
channel itself to be tested, the database values
the sequence by simulating inputs, analogue or
and the I/O function blocks’ operation to be
checked, and the changes observed at the oper- discrete, as appropriate and observing the se-
ator interface as appropriate. quence’s response. It is important that the se-
The equipment required for these tests is rela- quence be tested both for likely as well as for un-
tively simple. In general, signal generators are likely, but nevertheless possible, combinations
used for producing known inputs, e.g. 4–20 mA, of inputs.
0/10 V, etc. which are then observed using the In terms of equipment, the easiest approach is
system’s database editor and/or display sys- to use that listed above together with the sys-
tem. The system itself is used for generating tem’s own group displays and mimic diagrams.
outputs which are observed using ammeters An obvious proviso is that the test boxes con-
and/or voltmeters. Additionally, for testing dis- tain enough switches and lamps to simulate the
crete I/O, switches and lamps are used. I/O of any single sequence.
Note that this procedure simultaneously tests An alternative, but more expensive approach,
the functioning of the I/O channel hardware, is to construct a simple mimic out of plant
database entries, function block operation and P&I diagrams glued onto hardboard. Stuck
the user interface. Clearly there is scope for onto the mimic in the correct functional places
combining aspects of hardware testing with are switches for discrete inputs and lamps for
software integration. discrete outputs, together with potentiometers
2. Configuration: given that the I/O channels have and ammeters for analogue signals if appropri-
themselves been tested, the remainder of con- ate. These are then hardwired to the I/O cards
figuration testing focuses on the functionality and can be used for checking I/O signals instead
of the analogue loops and the logic of the dis- of test boxes. Sequences are checked by manu-
crete devices. The time taken to perform this ally operating the mimic’s switches and poten-
testing thoroughly is often underestimated. tiometers in response to the sequence driven
 63.10 Module Testing 507

lamps, setpoint ramps, etc. This approach pro- It is normal practice for module testing to be car-
vides a very good overview of all the sequences, ried out independent of the system software or in-
is tangible to the end-user during acceptance, deed the hardware. Typically it is a mixture of pa-
and is a valuable operator training tool. per based testing and software based simulation.
For sequence testing access to a monitor tool, Paper based testing involves careful and systematic
also described in Chapter 41, is essential. checking of all the detail of the module against its
An SFD or SFC is a useful vehicle for recording specification. Simulation means testing the func-
test progress. Each part is highlighted once it tionality of the module with simulated I/O signals,
has been successfully tested and any untested almost certainly within the IPSE.
backwaters are easily identifiable.

63.10 Module Testing 63.11 Software Integration

This is best done in three stages.The first two stages Once the modules have been tested individually,
involve the programmer who developed the soft- they must be integrated and tested to check that
ware for the module working alone as the tester. they communicate effectively. There are two as-
The third stage involves both the tester and a wit- pects to this: the interactions between the various
ness. It is usual practice for the witness to be an- modules, both configurable and procedural, and
other of the supplier’s employees: the interfaces between the modules and the rest of
the system.
1. The software is carefully inspected and thor- The interfaces with the rest of the system can
oughly tested against that module’s test speci- only meaningfully be established if the application
fication in an informal sense. Errors are identi- software is tested under the operating system being
fied and corrected as appropriate. supplied, with the major system software packages
2. The software is formally tested against that as described in Chapter 41. This requires that the
module’s test specification. Formal recording hardware is available, or that some equivalent de-
of the results of the various tests in the spec- velopment system is available for testing purposes,
ification is done at this stage and any re-work or that the IPSE is capable of emulating the operat-
and re-test are also recorded. ing system. Any of these scenarios is acceptable: it
It is not inconceivable that faults in the test depends on the time scales involved, availability of
specification itself will be found. Any amend- equipment and systems, and what has been agreed
ments to such must obviously be subject to for- with the end-user.
mal change control (as opposed to version con- The software integration test specification
trol) procedures and properly recorded. should be based upon the software design and held
3. The software is formally spot tested by the wit- in a single integration test schedule. The testing is
ness who verifies that the test results recorded best done by introducing modules one by one. The
are valid. This is done on a sample basis with specification should be sufficiently flexible to en-
more detailed checks carried out if inconsis- able the order in which modules are introduced to
tencies are revealed. be changed. Thus, if unexpected interactions are
The witness should be sufficiently familiar with revealed, or an interface is found to be faulty, in-
the project to be able to make judgements about tegration can be switched to a different sub-set of
the effectiveness of the testing and to suggest modules whilst corrections are made.
additional tests if necessary. Any faults found Both positive and negative testing should be
should be handed back to the programmer for provided for. Positive testing checks for desired
correction and re-testing. module interface functionality and, since this is
 508 63 Design, Development, Testing and Acceptance

known, these tests can be specified. Negative test- ous acceptance tests necessary to satisfy that agree-
ing tests for undesired module interactions. These ment should be combined into a single acceptance
cannot be predicted and hence negative tests can- test schedule and agreed with the end-user.
not be specified, other than to be aware of unex- FAT is essentially a question of proving to the
pected behaviour during normal testing and sys- end-user that the application software running un-
tem use. If this occurs, the cause should be identi- der the real-time operating system on the hardware
fied, corrected, and tests added to the integration of the target system with simulated I/O is correct
test schedule to prove that the fault has been cor- and functioning in accordance with the DFS.
rected. It is good practice for the supplier to run
through the complete FAT schedule prior to the
end-user’s visit. These tests should be formally
recorded too and any faults corrected and re-
63.12 System Integration tested.
The end-user’s role in FAT is to verify that the
Assuming that hardware acceptance has been com-
testing and integration has been carried out prop-
pleted, system integration is simply a question of
erly and thoroughly, i.e. the emphasis is on ver-
installing the application software on the target
ification. The supplier will have recorded the re-
system and checking that it works under the real-
sults of all module tests, software and system in-
time operating system. Provided that the applica-
tegration, and pre-acceptance tests. The end-user
tion software has passed the software integration
should only need to do spot checks on a represen-
stage, and the correct version of the operating sys-
tative and random sample of the tests. Provided all
tem is used, there is little scope for things going
the spot checks verify those already recorded,there
wrong. The system is then ready for acceptance
is a basis for confidence that the system has been
testing.
thoroughly tested and works to specification.
The above presumes that the project concerns
Another school of thought is that all software
development of application software only, and that
and system integration tests should be witnessed
it is being integrated in an environment of proven
and verified by the end-user. This can be a very
system software. Where there is much scope for
time consuming operation which is open to mis-
things going wrong is if the project has required
use by end-users who have not properly articulated
changes to the system software. This can give rise
their requirements in the DFS.Acceptance provides
to unexplained and/or unexpected interactions
an opportunity to correct this functionality at the
which can be very difficult to identify. The golden
expense of the supplier.This is contrary to a quality
rule is to avoid changes to system software at all
approach and contractual fair play as, apart from
costs.
other considerations, changes made at this stage
invariably have major implications on the software
design with consequent re-work.
63.13 Acceptance Testing
As explained in Chapter 62, acceptance is nor-
mally a two-stage process: factory acceptance test-
ing (FAT) and works acceptance testing. At this
63.14 Project Management
stage of the waterfall model,it is factory acceptance So far, this chapter has concentrated on technical
that is of concern. Works acceptance is covered in aspects of the software life cycle. However, there is
Chapter 64. a commercial basis to the cycle too, and the design,
The basis for acceptance should have been development and testing of application software
agreed and incorporated within the DFS. The vari- has to be managed carefully. The key issues are
 63.14 Project Management 509

making sensible estimates of the time and effort tify resources allocated to individual modules. A
required at each stage, planning the deployment of detailed Gantt type of chart for software imple-
both human and equipment resources, monitoring mentation should be developed showing the tasks
progress against milestones, ensuring that deliver- for which each programmer is responsible, with
ables materialise and that quality procedures are milestones. It is most important that these are re-
adhered to. alistic and should, for example, include holidays
Estimates of the software effort involved will and allow for management effort and programmer
have been made as part of the tendering process. efficiency: refer to Tables 61.1 and 61.2. Depending
Metrics were provided in Chapter 61, together with on the timescales involved and the resources avail-
an example calculation. They allow for the cost of able, it may be necessary to do some critical path
design, development, testing and documentation analysis.
of the software. However, they do not distinguish With the project plan in place and resources
between these activities and, for project manage- allocated, progress must be measured.As the mod-
ment purposes, a further breakdown is required. ules progress through the life cycle, time sheets
A typical split in relation to the waterfall model is are kept of the various activities against the mile-
given in Table 63.1. Note that the split may vary stones, to an accuracy of say one hour. Deliverables
according to the relative amounts of configurable are used to measure completion of milestones.This
and procedural software. Nevertheless, it gives a data is then used to monitor progress against the
good feel for the proportion of effort required to budget on a daily/weekly basis. The monitoring
complete each stage, both for the overall project process lends itself to spreadsheet analysis with
and for an average module. deadlines, estimates, lapsed times, efficiencies, etc.
broken down against individuals, activities, mile-
Table 63.1 Application software stones, etc. Some useful metrics for this are listed
costs vs project stage in Table 63.2.
It is also useful to present progress to date
Stage % graphically.The project plan represents the desired
Design software 20
progress and can be used to draw a graph of tar-
get progress. Actual progress can be plotted on the
Design modules 15
same graph week by week. A complex project may
Develop software 30
have an implementation phase of a year or longer
Test modules 20 and several teams working in parallel. Morale is
Integrate software 15 often a problem after several months into such a
project and progress graphs can be used to advan-
Given the overall estimates of the software effort tage to demonstrate that progress is being made
predicted in the tendering process, and the above and to introduce an element of competition be-
split, it is possible to assign reasonably accurate tween the teams.
estimates for the effort required for each stage for The above time sheet data can also be used, at
each module. It follows that an important manage- the end of the project,to refine the metrics.Average
ment task, at the software design stage, is to make values can be calculated for the different activities
estimates of the effort required for each milestone and the metrics achieved determined. These can
for each module. be compared with the metrics used for prediction
A project plan is required. This essentially al- and fed back into the estimating process. Similarly,
locates human resources, and perhaps equipment the split between the stages can be determined and
too, to the project. Initially the resource estimates refined for future use.
will be of a global nature but when the software It is very important that this analysis be car-
design is complete it should be possible to iden- ried out: the feedback is invaluable in ensuring
 510 63 Design, Development, Testing and Acceptance

Table 63.2 Metrics for progress vs activity

Activity Rate per person

Configurable functions and database blocks:

Develop and test control functions 15 I/O channels/day
Other configurable functions:
Develop and test group displays, trends, etc. 30 tags/day (total)
Develop and test historic data. 50 tags/day
Semi-configurable graphics:
Develop and test new mimics 0.75 mimics/day
Modify and test old mimics 2.0 mimics/day
Procedural code:
Produce flowcharts: SFD and/or SFCs 4 pages/day
Modify and draw new SFDs and/or SFCs 8 pages/day
Walthrough sequence designs 15 pages/day
Review (COOP) of SFDs, SFCs, etc. 5 pages/day
Develop (code) new sequences 3 pages/day
Modify old sequences 5 pages/day
Compile, link and print sequences 10 pages/day
Test sequences 4 pages/day
Other semi-configurable functions:
Develop and check recipe parameter lists 4 lists/day
Develop and test new batch reports 0.2 reports/day
Modify and test old batch reports 0.5 reports/day
Notes:
1 page of sequence code is approximately 30 instructions, rungs or actions.
Use in this table of the words design, develop and test is deliberate and consistent
with the waterfall model of Figure 63.1.
The metrics in this table are different from those in Chapter 61 because the latter
also allow for specification, management, acceptance and also commissioning.

that the metrics used for estimating remain use- 63.15 Personnel Management
ful, effective and relevant. Also, the software man-
It should be obvious that a successful project is
ager should produce an end of project report. This
critically dependant upon the availability of suffi-
should contain an overview of the problems en-
cient human resource and its sensible deployment.
countered during the project and how these may
The resource required is estimated along the lines
be avoided in future. The outcome of such deliber-
of the worked example in Section 61.6, taking into
ations may result in proposals to modify existing
account experience, management effort, and so on.
procedures, standards and guidelines.
The deployment of that resource in terms of plan-
ning and metrics is covered in the section above
on project management. However, organisation of
the human resource is a separate issue.
 63.16 Comments 511

Some suppliers organise their personnel into rela- the projects group too and tend to be electri-
tively small teams on an industry sector basis: for cal and/or electronic engineers. They report to
example,pulp and paper,utilities,petro-chemicals, the contract manager.
oil, pharmaceuticals, etc. The rationale is that the • System software engineers. Assuming that stan-
team builds up expertise in a sector of activity dard system software only is required, little sys-
and the supplier is able to tender for projects tem software effort is required. These come
in that sector confident of having the experience from the system software group and tend to be
and expertise to follow it through. An alternative computer scientists. They report to the contract
and proven approach is to organise personnel into manager.
larger groups as depicted in Figure 63.4. • Application software manager. This person will
manage the team of application engineers who
Projects/ will design,develop and test the application soft-
Application hardware group ware. The manager must have a good under-
software group standing of the project’s requirements and be
familiar with the various procedures and pro-
cesses involved. Experience of managing similar
Contract manager
projects is essential. This person also reports to
Hardware engineers
the contract manager.
System software engineers
• Application software engineers. Likely to be the
Application s/w manager
largest part of the project team, these are typi-
Application software team
System cally chemical or process engineers: they are best
software group able to understand the application and appreci-
ate the control requirements. Typically they will
Fig. 63.4 Personnel groups for sourcing project teams
have a range of experience and expertise. They
report to the application software manager.
In essence, the expertise is held within three large
groups irrespective of sector. The projects group
There are several advantages of this approach
handles the contracts and accounts for projects. It
as opposed to that based on sectors. Experience
is responsible for managing all aspects of projects
and expertise are spread more evenly within the
apart from the application software. The applica-
groups, it is more flexible and less vulnerable to
tion software group is only involved in turnkey
non-availability of key personnel, and it provides
contracts. The system software group is largely
more variety to individuals. Also, being in larger
concerned with the on-going development of the
groups enables a career structure that is indepen-
system and its functionality.
dent of the vagaries of projects.
For any turnkey project, group members are
seconded to project teams as appropriate as fol-
lows:
• Contract manager.A senior engineer with an un-
63.16 Comments
derstanding of the system’s functionality, expe- This chapter, and previous ones, have addressed
rience of applications similar to the end-users the turnkey scenario in which the application soft-
requirements, and proven project management ware is developed by the supplier on behalf of the
experience. The contract manager’s choice of end-user. The basic issues are unchanged when the
team with the right mix of skills is critical. development is done by a contractor or by the end-
• Hardware engineers. Assuming that standard user instead.The same documents,such as the URS
hardware items only are required,little hardware and DFS, and the same procedures are required.
effort is required. These typically come from There are, however, other considerations.
 512 63 Design, Development, Testing and Acceptance

Often, when a new plant is to be built or a major of applying those systems, and probably has bet-
refurbishment of an existing process undertaken, ter development facilities, tools and procedures.
a main contractor is appointed to handle the whole Also, a supplier has more of a vested interest in
project of which the control system is but a part. the longer term success of an implementation than
Given its strategic position, it is likely that the con- the contractor. Set against that, an established con-
tractor will formulate the URS, handle the tender- tractor should have a breadth of experience of a
ing process with the suppliers,and develop the DFS variety of systems and be well positioned to advise
on behalf of the end-user. The contractor may well the end-user on alternative solutions. Contractors
do the subsequent design and development work tend to produce the cheapest solution, rather than
in-house, simply buying the hardware and system the best, because they are maximising their own
software from the supplier. Alternatively, the con- profit.
tractor may sub-contract the work to the supplier. Irrespective of whether a system is developed
In the latter case, there is scope for confusion over by the contractor or supplier, in either case there
the contractor’s role in managing the project. At will be a contractual relationship with the end-
the very least it is an extra layer of management user. This focuses the mind on costs, deliver-
between the end-user and supplier with potential ables, time scales, and so on. That is not nor-
for confusion and delay. mally the case when systems are developed by
The end-user should think carefully about this the end-user in-house. Whilst few end-users have
relationship.It is not uncommon,and arguably bet- the capability to engineer a system properly them-
ter, for the end-user to deal with the supplier di- selves,relying upon some supplier to provide hard-
rectly. Indeed, many end users have partnership ware and system software, many attempt to do so.
agreements to that effect. In general, a supplier has Such projects are notorious for lack of discipline,
a more in-depth understanding of its systems than under-resourcing, inadequate procedures, incom-
any contractor, has a greater breadth of experience plete documentation, moving goalposts, etc.