Figure 1.The PSS-05-0 Document Tree
Almost exactly twenty years ago, in May 1977, ESA's Board for Software Standardisation and Control (BSSC) was established. Since that time, the BSSC has produced a highly successful software engineering standard, first issued in 1984, which has been applied extensively in ESA. This article describes the development and validation of ESA Software Engineering Standards, as well as a version of the standards for use in small projects - the so-called PSS-05 "lite". The results of comparing the ESA Software Engineering Standards with international standards such as ISO 9001/9000-3 and ISO 12207 are summarised. Work in progress is discussed, in particular the production of a guide on the application of PSS-05-0 in projects using object-oriented technology, together with future plans.
The origin of the ESA Software Engineering Standards goes back to the software development circumstances in the Agency in the mid 1970s. At two of its main support establishments, ESA was embarking on a number of ambitious projects involving the development of large amounts of software. At ESTEC these were mainly for the design and implementation of spacecraft, and, at ESOC, for the support of spacecraft operations and data processing. A number of these developments were in application areas which were new to the Agency at the time. The staff involved in software development were often brilliant engineers, able to find innovative solutions to problems. However, they were not used to working in a project environment with rigorous cost and schedule constraints. Each followed his own methods and there was little project discipline.
One of the founders of the ESA Board for Software Standardisation and Control, its first Chairman, and a co- author of this article, joined the Agency in 1975 and was nominated as project manager of a very critical software development activity at ESOC, namely to support a mission, the launch of which was imminent. The ground system involved a spacecraft control system, and extensive facilities for processing and other handling of the payload data. It was evident that the project was late. In addition, there were major hardware and operating system problems. While the developers were desperately waiting for improvements on the hardware side, an initial idea was to reduce requirements and to proceed directly with the implementation of only those requirements essential for the launch of the satellite. But what were the requirements? There were no written requirements - at best, some could partly be retrieved from minutes of meetings. All the rest were in the minds of the project engineers. How could cost and schedule be guaranteed under these circumstances? This was a project manager's worst nightmare!
The first reaction to the situation was the decision to stop any further development and require the software engineers to put into writing their understanding of what the requirements were. This was a very unpopular decision, particularly since the management hierarchy was sceptical of a radical measure such as suspending development on a high- profile project which was already late. However, it worked - with the list of written requirements, it was possible to select those needed for launch and then proceed with the development of a minimal system. The remainder of the system was completed when the satellite was already in orbit. Thus, disaster was averted.
Then came the second reaction, "We never want to find ourselves in this situation again!". This is the seed from which the BSSC, and consequently, the ESA Software Engineering Standards grew.
Problems similar to these were also experienced at ESTEC, and little by little, other software managers came to the conclusion that an effort had to be made to define a methodology which would enable:
The next battle was to establish the need to set up a group of software experts to define the methodology. In 1977 an agreement was finally reached, and the Board for Software Standardisation was nominated by the ESA Director General. However, many staff had an odd image of this Board as more of an informatics police squad, chasing and booking errant software developers for infringements of software engineering laws. For this reason, the words "and Control" were added to the name of the Board. In fact, the BSSC's emphasis has always been on the production of standards - never having had the resources to act in a "policing" role.
The initial reactions to the BSSC were rather negative. A frequent comment was, "Our software is special, and therefore we need special methods, so thanks, but no thanks," or words to that effect. One project manager even asserted, "Our software is very large, so we don't need any special methodology."! The initial target given to the Board was to complete its work within three months, which only goes to emphasise the generally poor understanding of the software engineering discipline at the time.
In spite of this discouraging environment and unrealistic schedule, the meetings of the Board were very constructive from the beginning. A conscious decision was taken to disregard the opposition, to concentrate on a realistic targets and to seek the help of the few supporters in ESA.
As an initial realistic task, it was decided to define the software life cycle and its phases. This resulted in initial guidelines for the procurement of software, issued at the beginning of 1978. These had the immediate and very beneficial effect of establishing a common terminology. Managers, engineers, administrators and legal experts were then able to speak the same language, using terms such as "user requirements", "software requirements", "architectural design" and "detailed design" as a part of their common vocabulary.
The next step was to produce a set of documents, each covering one specific phase of the software life cycle. These documents became known as "pink documents", after the colour of paper on which they were printed. In each of them the major milestones and the practices applicable in the phase were defined. Useful information was derived from other software engineering standards, most notably those of the Institute of Electrical and Electronic Engineers (IEEE), used as a primary source of terminology and definitions.
As the standards were put into use, people started to realise their benefits and opposition gradually decreased. By the end of 1982, a full set of documents was available covering the complete software life cycle. This set was adopted as the standard for all software development in the Agency. Two years later, all of the pink documents were bound together in a single volume. An extensive survey was carried out in which comments and improvement proposals were solicited from ESA, the aerospace industry and the software industry. This led to the first complete version of the ESA Software Engineering Standards (called ESA BSSC (84)1, Issue 1), a single slim volume identifying a relatively compact set of some 200 mandatory practices as well as recommended practices and advisory material. After a three-year period during which the complete set of standards was extensively used, a further review and update took place resulting in a fully mature standard which was then published as ESA PSS-05-0, Issue 1, January 1987, consequently becoming part of the ESA System of Procedures, Standards and Specifications (PSS). The ESA PSS series covers all applicable ESA engineering and product assurance standards. PSS-05-0 Issue 2 appeared in February 1991, again following an extensive review and update process.
Following Issue 2, work started on a comprehensive set of guides giving detailed advice on all aspects of the standards. These were published as PSS documents between 1991 and 1995. The PSS-05-0 Document Tree is shown in Figure 1.
Figure 1.The PSS-05-0 Document Tree
The PSS-05-0 standard and guides, Software Engineering Standards and Software Engineering Guides, respectively, have been republished by Prentice-Hall in the context of ESA's Technology Transfer Programme.
A number of organisations from outside the space domain have adapted these standards for their own use since the Prentice-Hall publications. These include DERA (who have developed a standard for system engineering based upon the Software Engineering Standards), CERN, JRC and GSI, just to mention a few. Additionally, a Software Engineering Standards User Group (SESUG) has been set up outside the Agency to serve the interests of the groups' organisations.
ESA's Board for Software Standardisation and Control (BSSC) was formally established in May 1977 in an "Instruction from the Director General of ESA" (ESA/ADMIN(77)18, May 1977).
BSSC responsibilities
The BSSC is responsible for:
Another task appears in the BSSC Terms of Reference, namely the establishment of an Agency-wide library of application software. However, local specialist software libraries already exist within the Agency and are maintained by their users directly. Supervision of an Agency-wide library involving extensive effort to provide user support, version control, up- to-date documentation etc., simply turned out to be an impractical proposition within the rather modest staffing envisaged.
Membership
The BSSC currently has 7 members, all of whom work part-
time on the committee. Mr C. Mazza was the chairman from 1977
to 1995. Since 1995, the committee has been co- chaired by Mr
M. Jones (ESOC) and Mr U. Mortensen (ESTEC).
The PSS-05-0 standard
The PSS-05-0 standard describes the processes involved in the complete life cycle of a single software project from its inception to the retirement of the software. The standard is split into two parts:
The phases are each defined in terms of inputs, outputs and activities. Figure 2 shows these phases, inputs and outputs schematically.
Figure 2. The PSS-05-0 production process
The way in which these phases are put together is referred to as a "life-cycle model". The simplest is the waterfall model, in which the phases follow one another in sequence. PSS-05-0 does not prescribe any particular model, but it suggests three life-cycle models: waterfall, incremental and evolutionary. Figure 2 in effect corresponds to the waterfall model. The incremental model, which splits the detailed design phase into manageable chunks, is shown in Figure 3.
Figure 3. Incremental development lifecycle
As mentioned earlier there are some 200 mandatory practices. These are split roughly equally between the product standards and the procedure standards. The text defines what has to be done and gives some advice on how to follow the practices. This makes PSS-05-0 easily readable and readily applicable. Templates are provided for all the major documents, plans and forms.
PSS-05-0 does not prescribe any particular software engineering method or tool. Each project manager is left to decide which methods and tools are to be used, although it is mandatory that appropriate methods be adopted. Such methods would include, for example, software requirements analysis methods and design methods.
PSS-05-0 "lite"
PSS-05-0 can be too heavy if used for small projects.
Here, "small" means a project for which one or more of the
following applies:
Experience shows that simplifications are possible for such projects. In PSS-05-0 "Lite", known more formally as the Guide to Applying the ESA Software Engineering Standards to Small Projects (BSSC(96)2), a number of strategies suitable for small projects producing non-critical software are described, along with possible ways of tailoring the mandatory requirements to these small projects. This includes the possibility of combining and simplify the various management documents.
The BSSC has made comparisons of PSS-05-0 with two major international standards: ISO 9000 and ISO/IEC 12207. Initially, the reason for this was to determine to what extent the practices of the ESA Software Engineering Standards could be used to implement the requirements of these other standards. Another benefit of the comparisons was a greater understanding of the other standards and the identification of potential improvements to the ESA Software Engineering Standards.
The technique used to carry out this type of comparison is to list the requirements of the standard being compared and identify which ESA Software Engineering Standards products or processes result in compliance. The relation between PSS-05-0 and ISO 9000 is illustrated by the diagram in Figure 4. The large circles represent the set of requirements in ISO 9000 and the mandatory practices in PSS-05-0. Categories of compliance are as follows:
Figure 4. Relationships between ISO 9000 and PSS-05-0
PSS-05-0 and the ISO Quality Standard (ISO 9000)
The report BSSC(96)1 documents the comparison of PSS-05-0
and ISO 9001 and its associated software guide ISO 9000-3.
ISO 9001 is the internationally accepted standard for quality assurance for all manufacturing and production industries. The standard defines the requirements that suppliers must fulfil to ensure that they deliver quality products. ISO 9001 applies to all types of products: hardware, software, processed materials and services. ISO 9000-3 is the accepted interpretation of the ISO 9001 requirements for software products. ISO 9001 and ISO 9000-3 both state what has to be done rather than how. Organisations themselves are responsible for defining how to fulfil the ISO requirements. Organisations can obtain ISO 9000 accreditation by a process involving independent audits of its practices and projects.
ESA PSS-05-0 defines a set of practices for making software products. These practices can be used to implement the requirements of ISO 9001.
BSSC(96)1 demonstrates that:
Examples of ISO 9001 certified quality management systems exist based upon the ESA Software Engineering Standards.
PSS-05-0 and the ISO Software Engineering Standard
(ISO/IEC 12207)
The ISO Software Engineering Standard ISO/IEC 12207 was
published in 1995. It is a comprehensive high-level standard,
which supplies a framework against which organisations can
check their existing standards. It is also permissible to
tailor ISO/IEC 12207 to an organisation's specific needs by
removing, adding or extending requirements. A comparison of
PSS-05-0 with ISO/IEC 12207 has been carried out using the
same approach as that for ISO 9000. The broad conclusions are
that for the ISO/IEC 12207 processes which are within the
scope of PSS-05-0 (such as development), PSS-05-0
comprises very good coverage and there are no conflicts. The
details will be in a report to be issued shortly as BSSC(97)1.
Work is on-going in a number of areas:
For reasons of brevity, and because work in the last two areas is in a very early stage, we restrict the discussion to the first two items only.
PSS-05-0 and object-oriented methods
What are object-oriented methods? While PSS-05-0 does not
prescribe any particular development method, it reflects, to a
certain extent, the methods prevalent at the time it was
written. These were mostly based on functional decomposition,
in which a top-down breakdown of the functions of the system
is made. Data is separated from functions and handled
individually, e.g. in data flow diagrams or data structure
specifications. In the early 1990s, object-oriented methods
began to become popular, and since this time have evolved
through application in many different software projects. They
are now replacing the functional decomposition methods; most
of the recent computer science or information technology
graduates have been trained in these techniques and one or
more of the associated computer languages. Object-oriented
thinking has also penetrated outside the software engineering
community: for example the various tables, queries, forms,
etc., in the widespread database package Microsoft Access, are
objects. Object-oriented methods are much more mature than
they were even 4 or 5 years ago, although there is still room
for growth.
In contrast to functional decomposition, data structures and functions in object-oriented methods are grouped together into classes. The data attached to a class are called the attributes and the functions performed within the class are called methods or services. Broadly, the advantages of object- oriented methods are:
Can PSS-05 be applied to projects using object-oriented methods? A guide is under preparation which explains the application of PSS-05-0 in conjunction with object-oriented (OO) methods. The preliminary results of this work prove that PSS-05-0 can be applied without difficulty to projects using object-oriented methods and only the wording of a few of the mandatory practices referring to functions or functional breakdown (in the SR and AD phases) need modification. In addition, given the more continuous nature of OO development, recommendations will be given on matters such as determining the end of a phase, which (among other things) is related to the content and level of detail of the modelling carried out in the various development phases.
Some OO methods have recommended feedback loops between analysis, design and implementation phases. These would appear to be excluded by the life-cycle models covered in PSS-05-0. However, from a management viewpoint, it is essential to maintain the PSS-05-0 concept of well-defined development phases, each terminated by a verifiable milestone. This discipline is essential for the successful development of software systems, especially large ones, and fully borne out by the experience on ESA projects following PSS-05-0 and using object-oriented methods.
This general conclusion is almost certainly applicable to any good software engineering standard. It is also important to point out that if a method cannot be used with the organisation's software engineering standard, it should not be used at all - otherwise the method becomes a pretext for anarchy.
Coding guides
C++ and C have taken over as the languages of choice for
most new software implementations in the ground segments of
space projects. For on-board software, Ada or C are the
programming languages normally used by ESA projects. C++ and
Ada are object-oriented or object-based languages, associated
with the object-oriented methods discussed earlier.
Coding guides on C/C++ and Ada are in preparation, the initial work of drafting the guides having been delegated to working groups made up of specialists in these languages. These coding guides are expected to be issued as BSSC pink documents in 1997.
It should be clear from this article that PSS-05-0 is a very successful standard. The BSSC has played an important role in promoting it, both through its various publications and through its responsibility in monitoring its application. PSS-05-0 has served to create a common software engineering culture in ESA.
It is also clear from experience that developing such a standard is a lengthy process (it took 7 years to reach the maturity of BSSC(84)1), and acceptance by the community also takes time. This acceptance should not be taken for granted - an unworkable standard cannot be imposed. Developers of new software engineering standards should take note.
As a result of the ESA Council decision, no new issues of PSS documents will be released, although existing PSS standards remain in force until the relevant ECSS standards are available or adopted. This, of course, also applies to PSS-05- 0 which remains in force and will be maintained as the mandatory standard for all ESA software projects until such time as ECSS-E-40 is approved for application in the Agency. A plan will be prepared for the introduction of ECSS-E-40. It is anticipated that this will include tests using the ECSS-E-40 standard in selected ESA projects. A detailed standard, practice-oriented, at the level of, for example, the current ESA Software Engineering Standards, would be expected as a requirement for the implementation of ECSS-E-40. It would also be expected that other organisations (e.g. national space agencies, space industry) might use their own standards as implementations of ECSS-E-40.
It should be noted that within the Agency there will be a continuing need for a PSS-05-0 type standard for much of the software development in the Agency which is not directly part of a space project, e.g. ground infrastructure software, administrative software and technology studies.
ESA Bulletin Nr. 90.