Both PRINCE 2 and BS 6079 originated in the United Kingdom and are designed for any type of project. ISO 12207, differs from these in that, firstly, it is international in standing and secondly that it relates specifically to software development.
Broadly speaking, ISO 12207 has as the prime areas of its concern the documentation (or 'software life cycle data' as it calls it) created and used by a software development project and the processes that, during development, will use and update software life cycle data.
It is stressed that this is only an overview and those using the standard in earnest need to refer to the actual standard itself.
D.2 The ISO 12207 approach to software life cycle data
'Documentation' is an issue that is difficult and important, but at the same time rather unexciting. Software developers and users often complain about the lack of documentation, but when it is available it often remains unread. There could be some justification for this reluctance to read documentation as it might well not be up-to-date.
One way to look at a software development project is as an information system in its own right. The project is made up of activities, each of which needs to pass information to and from other activities. As with any conventional information system, there needs to be a common database that can be updated and accessed as required. A key factor in the relative success and failure of the project is clearly going to be the effectiveness of this information system.
However, inappropriate documentation can actually be an obstacle to effective working. ISO 12207 focuses attention on the characteristics of good documentation by firstly defining the purpose of good software life cycle data. This data:
• records information about software products',
• helps make the product usable and maintainable;
• defines processes;
• communicates information;
We have chosen to use the term 'documentation' partly to make indexing easier. 'Documentation' could imply paper-based information but, of course, in practice, it could be held in an electronic form.
IEEE stands for the 'Institute of Electrical and Electronics Engineers', the prestigious US-based organization that has played a key role in setting standards.
The standard lists the characteristics of good documentation as being: unambiguous; complete; verifiable;
consistent - that is, there are no contradictions within it; modifiable;
traceable - the components from which it is derived are easily identifiable; presentable - this means that it is easy to access and view The standard recognizes the following generic types of data held by a project: requirements - what the system is expected to do; design - including details of its structure;
testing - including test strategy and criteria, test cases and results; configuration;
user - including user manuals; management;
quality - including quality plans and procedures.
The ISO 12207 standard does not specify precise formats for this documentation but the IEEE, for example, has produced a cross-reference indicating the relevant IEEE standards for each type of document.
D.3 The ISO 12207 approach to software life cycle processes
The processes that, either as a central objective or as a by-product, generate or update life cycle data are particularly the concern of the standard.
It will be recalled from Appendix A and Appendix B that BS 6079 differed from PRINCE 2 in defining, in theory at least, a project as starting with a concept and ending, after the required system had been both built and operated, with its decommissioning. In practice with BS 6079, however, the detailed procedures suggested for project planning and control focused on the development phase. ISO 12207 identifies five distinct processes:
Clearly, maintenance and operation are processes that genuinely belong to the post-implementation phase of a conventional development project. One justification for the inclusion of these post-implementation activities is that sometimes a customer will contract a supplier both to develop a system and operate it on the customer's behalf. Similarly a software house could be responsible contractually both for the construction of a software-based system and its maintenance after installation. Our attention here is given primarily to the acquisition, supply and development processes. It must be stressed once again that this appendix is intended merely to give an overview. Those intending to use the standard 'in anger' must obtain and study the full document.
Figure D.l ISO 12207processes.
The acquisition process is the set of procedures that a customer for software (or 'acquirer' in ISO 12207 terminology) will go through in order to obtain that software from an external source. The supply process is the opposite side and is the set of procedures that the supplier should adopt in order to satisfy the acquirer's needs. The supplier might use an existing piece of software or might develop new software, in which case they would need to invoke the development process.
Just as in the case of BS 6079, some supporting processes can be identified. These are listed in Table D. 1.
We will now deal briefly with the acquisition, supply, and development processes in turn.
A previous discussion in the chapter on contract management has already mentioned ISO 12207 in this context and so we will avoid going into excessive detail here.
Table D.l ISO 12207 Supporting and organizational processes
Supporting processes Organizational processes
Figure D.2 portrays the main activities that compose the acquisition process. The initiation activity starts with the description of the 'concept' that the acquirer wishes to make real, or the need that the acquirer wishes to satisfy. The requirements of the system then need to be defined by the acquirer. In fact, the acquiring organization could employ an external source to do this for them, but they would still have the responsibility of approving these requirements.
ISO 12207 distinguishes between system requirements and the software requirements that now have to be analysed and documented - software requirements relate to the distinct software components that will make up the delivered system. Once this has been done, a decision needs to be taken about the best way to acquire the software, for example, whether to make or buy. This is analogous to the 'defining the project approach' (SU4) activity in PRINCE 2.
Having made this decision, the acquirer is now in a position to prepare the acquisition plan, detailing the steps needed to acquire the software, taking account of such matters as who is to be responsible, for example, for any maintenance and support. Any inherent risks need to be considered. It is also important that at this point the criteria for final system acceptance, and the methods by which compliance is to be evaluated, be defined and recorded.
Another name for'request Request for proposal (RFP) The groundwork has now been done for the for proposal'is'invitation production of the 'request for proposal' document. This should include sections to tender' on the topics listed in Table D.2.
An important activity in the context of ISO 12207 is the tailoring of the standard for a particular project. In some places in the standard, it is stated that certain process requirements should be 'as specified in the contract'. The precise requirements to be included in the current contract now need to be identified. Depending on the type of product or project, it could be agreed that certain ISO 12207 requirements are to be dropped as not appropriate, while in other cases there could be process requirements above and beyond those in ISO 12207 that need to be documented.
Contract preparation and update Before you can have a contract, you must have a supplier with whom to have the contract. With this in mind, the criteria to be used in selecting the supplier and the method by which the compliance by
Figure D.2 Interaction of acquisition and supply processes.
Request for proposal - contents system requirements scope statement instructions for bidders list of software products control of sub-contracts technical constraints (e.g. the target environment)
potential suppliers with the criteria can be judged have to be set down. Once the preferred supplier has been selected, the final form of the contract between the supplier and acquirer can be negotiated. This often involves some adjustments to the way in which ISO 12207 is to be tailored.
Monitor supplier This will be done using some of the supporting processes listed in Table D.l, namely joint reviews, audit, verification and validation.
Accept completed contract When the supplier finally delivers the product, the acquirer will conduct acceptance tests and if the specified acceptance criteria are satisfied, the completed software can be signed-off as completed.
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 when 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 will make the right impression and lead to acceptance by the acquirer. The 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 down 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 between 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 shown 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
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.
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.
Detailed design o
Code and test
Qualification test o a
Acceptance support o ^
Figure D.3 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 be 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 are 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, where testing has taken place, through audits. Reviews can be at a management level where the project is monitored or can be at
Figure D.5 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?
• does 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. The 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.
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?
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.