The supply process

This process mirrors the acquisition process, but documents the activities that a supplier would need to undertake in response to the request of a supplier. Figure D.2 outlines the main activities involved. There will be occasions where the sequence of activities is not that shown and yet other occasions when some of the activities will have to be iterated a number of times.

Initiation The process is started w hen a potential supplier receives an RFP from an acquirer and the supplier decides to bid for the work.

Preparation of a response The supplier, after consulting people with various types of expertise, now prepares a response. This should include proposals about how ISO 12207 is to be tailored for the project in view.

Contract If all goes well, the supplier's proposal w ill make the right impression and lead to acceptance by the acquirer. TTic details of the contract are then negotiated and signed.

Planning The supplier can now draw up a detailed plan of how the work is to be done. The starting point for this will be the requirements as laid dow n in the RFP. You would normally expect this to include the life cycle approach to be applied by the supplier, as this will influence the points during the project at which consultation betw een supplier and acquirer is to take place. If the life cycle has not been stipulated, then it should be selected now as a basis for devising the plan. It will have been noted that earlier the acquirer might have considered, as part of the acquisition process, the options of 'make' versus 'buy' and also whether to use in-house or external sources. ISO 12207 now makes provision for the supplier to make a similar choice, and having done this, to develop a plan accordingly. For example, a contractor who is primarily a hardware specialist might use a software house to write the software required as part of a contract. The general format of the plan is show n in Table D.3.

Execution and control The plan can now be executed. Depending on whether the contract is for systems development, operation, or maintenance, the ISO 12207

Table I) J Contents of a plan

Topics to be covered by a plan project organizational structure engineering (i.e. development) environment: including facilities, standards, procedures and tools work breakdown structure management of quality characteristics management of safety, security and other critical requirements sub-contractor management verification and validation acquirer involvement user involvement risk management security policy - * need-to-know' and *access-to-information% rules arrangements for obtaining any regulatory approvals scheduling, tracking and reporting training process stipulated for development, operation, or maintenance would now be undertaken.

During the execution of the plan, the standard expects the supplier to monitor and control progress and product quality, and to have a mechanism for recording, analysing and resolving the problems that occur. The supplier will also be responsible for passing on requirements that accurately reflect those of the acquirer to any sub-contractors and for ensuring the compliance of sub-contractors with those requirements. The supplier also needs to co-operate fully with any independent verification and validation processes that were laid down in the contract.

Review and evaluation The provisions here are mainly to ensure that the supplier allows the acquirer access to the information needed to review the progress of the project, although the precise extent to which the acquirer has a reviewing role and access to supplier documentation has to be specified in the contract.

Delivery and completion Attention is required in any management plans to the way products are to be delivered and to how any required post-delivery support is to be provided.

D.6 The development process

ISO 12207 sees the development process as being made up of the activities in Figure D.3. Most of the terms used will be familiar to software developers. Some activities address the system as a whole - for example, the analysis of user requirements and the overall design of the interacting components that together should meet those requirements (architecture design in Figure D.3). Others relate to software, which in practice means activities that are repeated for each software item in the system. The standard identifies a hierarchy of software items in a system that are made up of components that, in turn, are made up of software units. The software unit is the basic unit of code, but the precise definition of components and items will depend on the circumstances of a particular project. At the same time that these activities are starting, progressing and terminating in the planned sequence in a project, there should be the continuous background operation of supporting activities, such as configuration management and problem resolution - this is represented in Figure D.3 by the 'process implementation' stream.

Requirements analysts Architecture design

Requirements analysis

Architecture design

Detailed design

Code and test


Qualification test


Qualification test

Installation i

Acceptance support

Figure DJ ISO 12207 development software life cycle.

Once-through' in IS The structure in Figure D.3 implies a 'waterfall', or in ISO 12207 terms a 'once-

12207 equates to one- through' approach. Figure D.4 and Figure D.5 illustrate how these activities can shot in Euromethod. be shuffled to fit an incremental or evolutionary approach to a project. As in the case of Euromethod - see Appendix C - some rather simplistic guidelines are given to help the planner decide which approach to adopt - for example, if the acquirer wants all the system capabilities in the first delivery, an incremental approach would not be advisable!

Figure D.4 Using ISO 12207 activities in an incremental project.

Guidance as to what should he done for each activity is given and the reader who needs this level of detail really should read the standard itself. The general picture that emerges is that for each activity there should be the following pattern:

It is to be hoped that in general the doing and the documenting arc going on in parallel, rather than the documentation following the doing as an easily forgotten afterthought. A prime objective of ISO 12207 is to ensure that appropriate and correct data is recorded.

The evaluation procedure following the carrying out of an activity is usually done by means of a joint review, or. w here testing has taken place, through audits. Reviews can be at a management level where the project is monitored or can be at

Figure Di Using ISO 12207 activities in an evolutionary project.

a technical level where the appropriateness of a particular software product is examined. The technical reviews will look at such considerations as:

• is the product complete - or are some parts missing?

• docs it comply with the standards and the specification?

• have all required changes been carried out?

• will it be an acceptable basis for the next activity?

• do the processes used follow those in the plans, schedules, standards and guidelines for this project?

In addition, some concerns will relate to the products created by specific activities as Table D.4 shows. 11k emphasis in many cases on the 'feasibility of operation and maintenance' is worth noting. The software does not only have to meet the acquirer's functional requirements, it needs to work in the planned operating environment and be easy to modify to meet any new requirements. Making these requirements explicit during development is invaluable.

Operation and maintenance processes

As noted earlier, the ISO 12207 standard also prescribes general processes for operation and maintenance. The interested reader is directed to the standard itself for further details of these.

Table D.4 IS 12207 generic acceptance criteria

System requirements analysis System architecture design Software requirements analysis Software architecture design Software detailed design Software code and test Software integration Software qualification test System integration System qualification test

✓ ✓✓ ✓✓✓✓✓✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓✓✓✓✓

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment