Carlo Mazza, Jon Fairclough, Bryan Melton, Daniel De Pablo, Adriaan Scheffer, & Richard Stevens
Prentice-Hall, 1994.
Carlo Mazza, Jon Fairclough, Bryan Melton, Daniel De Pablo, Adriaan Scheffer, & Richard Stevens
Prentice-Hall, 1994.
ISBN 0-13-106568-8
formerly European Space Agency’s PSS-05-0 Standards
(Issue 2, 1991; BSSC version 1984)
Buy it from Amazon.com
Buy it from Amazon.co.uk
Carlo Mazza, Jon Fairclough, Bryan Melton, Daniel De Pablo, Adriaan Scheffer, Richard Stevens, Michael Jones and Gianfranco Alvisi
Prentice-Hall, 1996.
ISBN 0-13-449281-1
This little book, simple and direct in style, has a special resonance among software and requirements engineers -- at least if they have a long memory -- because it enshrines the discovery of a way out of the 'software crisis'.
It -- more precisely, ESA's PSS-05-0 Software Engineering Standards -- represents the European Space Agency's response to years of getting software that failed to live up to expectations. Time after time, ESA found that it ordered hardware and software, and then, sure enough, the software was late, too expensive, and didn't work as required. Why was it so much more difficult to get software than hardware? Rockets and satellites were complex, but the problems were in the main understood and could be overcome. But software ... now there was trouble.
It is true that ESA's big cousin across the Atlantic, NASA, had devised excellent systems engineering standards at the time of the Apollo moon-walking project. But PSS-05-0 represents our very own, home-grown European learning curve. There is another reason, too, for finding it interesting: out of the painful experiences of procuring satellite control software grew the determination to do things better that led Richard Stevens to leave ESA (he was at ESRIN, and on the PSS-05 committee) and found QSS, the company that launched the DOORS requirements management tool (now Telelogic DOORS). The tool has become the market leader; the DOORS success story is due in large part to its rootedness in experience -- in other words, its fitness for purpose.
The original ESA version is dotted with the organisation's somewhat strange terminology, so the Prentice-Hall version is more accessible (if less redolent of history). What remains, however, is a lean, compact little book with a simple, clear message: software must be specified properly, and then designed and tested to its specifications.
This message is reflected directly in the book's structure. Part 1, Product Standards, steps the reader through the software life cycle, which is taken to be a user requirements definition phase, a software requirements definition phase, a detailed design and production phase, a transfer phase, and not least an operations and maintenance phase.
As an aside, the O&M phase was rather well understood by ESA, as Maintenance was one of those words that meant different things to different people. To the software contractor of the old days, it meant time and money to make the software do what it was supposed to, given that it was highly unlikely to have been adequate at the time it was hastily accepted. When out publicising DOORS, Richard used to joke 'You want $100M worth of software developed by next month, and you don't have any acceptance criteria defined for it? I can deliver it!' -- and it was funny because it was far too close to the truth.
It is said by the slanderous that the software houses used to play 'chicken' with each other, each waiting to see when one of the others involved in a major satellite job would blink and admit they simply didn't have enough time to complete their software. The company would be fined and given more time, and all the others would breathe a sigh of relief and use the time -- fully paid by the Agency, of course, to maintain the teams in operational readiness -- to implement what they had left out of their software, which was probably a substantial part of the required functionality. And of course, the funding for all of this came out of the luckless 'Maintenance' budget.
Part 2 of the book, Procedure Standards, covers lifecycle and software project management, configuration management including change control, verification and validation, and quality assurance.
Part 3 consists of Appendices, notably including a set of templates for all the software project documents (URD, SRD, and so on), and for all the forms used to handle software problems and changes in a disciplined way. Many of these are still useful today, though of course people are more likely to use them with a software tool such as DOORS than with the photocopier that was de rigueur back in the '80s.
The style of the standards is, as you might expect, extremely prescriptive:
The developer shall construct an implementation-independent model of what is needed by the user. This is called a 'logical model', and it is used to produce the software requirements.
This has the virtues of confident simplicity and didactic clarity, doesn't it? These are not bad things for project teams floundering amongst misunderstood requirements, budget pressure, and Software Problem Reports.
PSS-05-0, then, introduced a disciplined sequence of activities to ESA's contractors, large and small. It was simple to apply and it made a dramatic difference to software quality, the improvement recorded precisely in the Agency's Project History Document database. The document templates helped to make compliance 'automatic' -- contractors simply started every project with the information shovelled into the right heaps, so everyone could see that things were in order.
Its weaknesses? The standard does not consider the wider systems context to any great extent: it largely assumes that software is new and stand-alone, so that it can be build based on its specifications alone -- though the Interface Control Document bears witness to a bigger picture. It pays relatively little attention to stakeholders, considering 'users' to be a simple and well-defined concept. And despite a page or two discussing incremental delivery and evolutionary development, along with prototyping, it is basically expected that all the requirements are knowable up front:
The URD and SRD must be 'complete' documents. This means that all known requirements must be included when they are produced. Nevertheless, it is possible that new requirements may arise after the URD and SRD have been approved...Design integrity should not be compromised when new requirements are incorporated.
That 'should' is telling. It couldn't be made a mandatory 'shall' as the requirement was not exactly measurable and verifiable: how do you tell when the tiny change you are making is in fact compromising the design? So it was made an advisory 'should', even though the problem of controlling change lies at the heart of the Standards! Michael Jackson has notably criticised the use of grammatical moods to indicate requirement priority. At the time, though, without significant tool support (and I recall making my own homespun traceability and requirement management system using Microsoft Access for an ESA project) there was little alternative to the 'shall' approach.
Iteration and more rapid styles of development, allowing requirements to be gathered repeatedly and changes to be incorporated more gracefully, were anathema to an organisation that had had its fingers badly burnt by poor software and commercial practices. It may be that today we have moved on, and are confident enough in our ability to control rapidly-changing requirements with suitable tool support, dynamic architectures, and responsive project management that we can smile at the rigidities of an earlier generation. Or perhaps not.
This book will be useful to systems and software engineers, quality engineers, configuration managers and project managers responsible for setting up and managing the structure of software projects. It will also be of interest to students and lecturers in software engineering, and to practitioners interested in the background to their professional disciplines.
The associated book of Guides to the Software Engineering Standards is more detailed, less prescriptive, and contains much more discussion. It should be useful to engineers who are implementing standards on their own projects. On a historical note, I had a hand in writing the Guide to Detailed Design and Production; if I recall rightly, I wrote the accounts of the relative merits of various programming languages, amongst other things.
© Ian Alexander 2003
You may also like:
