- Email: [email protected]
The Reasons Why Software has a Bad Name
Copyright © IFAC Experience with the Management of Software Pndet:ts. Heide\berg. FRG . 1986
THE REASONS WHY SOFTWARE HAS A BAD NAME M. Key T erhllology E.'(frlllh'f, Brilish Teit'rolllllllllliralioll s plr. //J.lll'irh. SII[f(Jlk. [ 'K
Abstract: Using System X development experience the paper describes very briefly the total development environment to illustrate the problems of managing software projects. There is an emphasis on how important problems of software management and development were overcome. '!he paper also exposes some of the myths and draws attention to the main weaknesses of the software industries' approach to software development today. Keywords: Management; engineering process; manpower profiles; control points; validation teams; planning. large-scale projects of more than 4 year's duration span the term for which most governments are in office - and political change and uncertainty can be just as damaging as world economic change - how many times have the British and French tried to build a channel tunnel? Thus, what was conceived as a brilliant solution 10 years ago could have been overtaken by events. Hence the last question, "Is the development still worthwile and likely to be so for the foreseeable future?" This is an impor tant question and should be asked regularly.
INTRODUCTION
This paper is fairly wide-ranging in terms of the problems of managing projects which have a large software/firmware component. I t is hoped that it will touch on a few myths and a few home truths. Most of the relevant management experience has been drawn fran a continuous involvement in the evolution of digital switching in British Telecom since 1965, and in particular, the developments of System X. '!here are many facets to managing a large project. Perhaps if we look at the basic management questions which need to be asked for any large software project we can see more clearly how the management of software can so easily go wrong. The important management questions are shown below in Figure 1.
Before any large software project can even be contemplated there must be an infrastructure of experience, of similar or related projects, within the organisation. For example it is difficult to build a Concord if you have not built an aeroplane before, and most companies would not try. In the software industry, some companies do attanpt to leap-frog product generations:with the inevitable consequences.
• What needs to be done?
• How do we get there? • How many people'
The infrastructure will primarily be concerned with the management and quality of product development.
• How long will it take to build?
• How do we record designs and implementations ?
Figure 2 shows how this infrastructure precedes the classical software development life-cycle.
• How do we check that the product is good? • How do we chec k that we are
• M anagement
on schedule?
• Quality
• How do we control changes?
• Requirements
• How do we manage the product in the field?
• Specificat ion
• Is the development still worth
• Design and coding
while'
Fig 1:
• Unit test
Important Management Questions
• Integration
The first thing you notice is that software hardly features in terms of the questions which need to be asked - these are general management problems.
• System test and va lidat ion
Fig 2:
It is easy to produce a list of activities like this, but the implications of these activities are obviously not well understood. This p3.per attempts to highlight sane of the more important aspects.
PROJECT COOCEPTION
The Management questions which are asked above need to be answered dur ing any development. The time at which these questions are asked is very important. Developments which are most at risk are large, canplex systems which inevitably take a long time to complete. But do not be canplacent if you are involved in only 9llallscale developments. Worthwhile improvements will be obtained with a more rigorous management awroach in 9llall-scale projects as well! Many EMSP-H
Software Development Life-cycle
MANAGEMENT STRUCWRE
The whole development needs to be managed by an embryonic management structure which can grow and resporrl to the needs of the project and which will allow co-ordination, progress reporting and rapid decision making to take place effectively. 97
M. Key
98
The structure of the managanent team is critical, but there is no optimum managanent organisation; it depems on circumstances. However, any managanent structure must clearly define a minimum of four areas of managanent responsibility and they are shown here:-
TABIE 1:
Object Code Size k words
Tool
Library
75
Build System -
Planning
Language System for System X
ESG. GME , Collator ,
65
Consolidator , Executor
The target developnent
BT Coral Compile, -
PROCl PROC2 PROC3 PROC4
260
Linker
45
The support for that developnent; am
Lister
20 15
An independent validation team with allegiance to the customer.
Constructs Checker
Source Formatter
How these responsibilities might interrelate are shown in Fig 3.
30
Process Combiner - splitter
100
Software Message Generator - Online / Offline
200 20 150
Debug Emulator -
Test / Debug / Single Proce ss
Interpreter
75
Static Analyser
30
Dynamic Analyser
30
Cross Reference
70
General Ma c ro Processor
SXl
30 200
MSeq
10
Scarab
60 20
Draw Epp
Online
20
Asynchronous link handler - George 3 / CPM
10
Data Compiler
I
Data Decompiler
500
Downloading via synchronous protocol
30
MMI User control macros
45
Model Incident Report database
40
2150
PLANNING
Figure 3 shows one of many subsystems under the control of a Systan Manager. Subsystans were created where function, geography or team size (15-35) would have created a managanent problan if not properly coordinated.
Usually the first thing the management team will do is prcxluce a plan. This is an important first step .•• because "if you do not know where you are goirg you should not be surprised if you em up in the wrong place!" Planning is notoriously difficult am the first plan is bourn to be wrong! Senior management has this uncanny knack of dananding that a prcxluct is in the field by a certain date and then working backwards from there. 'The Mythical Man/Month' (1), tells us that this is often not a sensible way to proceed if you are not prepared to accept the answer: "It can't be done in the time". The idea that certain things cannot be done in less than a given time does not seem to register with some managers. If confronted with this problem it is recanmended that estimating techniques like the PUI'NAM (SLIM) mcxlel (2), or the CCCCMMO mcxlel (3), are used to substantiate your claim.
What is obvious, but does not always happen, is that the support and validation teams need to be set up first to build the support foumations. These support teams are often substantial and they will be involved in the generation of documentation standards, planning standards and estimating techniques, quality procedures am support software developnent. Any deficiencies must be corrected early in the project's life. If you do not believe this look at 'l1IBIE 1. It shows the scope of System X support software developnent.
These mcxlels use data from software related projects of all types. By mapping your project's important parameters into these databases it is possible to predict resources and timescales required. Initially, these estimates are inaccurate, but the accuracy with which project timescales or costs can be estimated improves over a period of time as the project definition is refined. For example the fact that a project is mainly real-time or data processing has a significant impact on the project costs.
In this case much developnent was required to support the high-level language POCORAL. Notice this is much more than a compiler developnent it is a language systan. This support software is comparable in size with the telephone switching application!
One important feature of SLIM, Fig 4, is that the impact of manpower on timescales can be clearly seen. It also shows an Impossible Region. Faced with this evidence it is more difficult for the senior manager to say: "Well, if you can't do it, I will f im someone who can!".
Fig 3:
Management Structure
99
Why Software has a Bad Name DEVELOPMENT TIME (YEARS)
NUMBER OF
SOFTWARE PHASE 1 ENGINEERS I----~I
PHASE 3 PHASE 2
600
400
200
YEAR
Fig 6:
Phased Approach to Manpower Growth
practice, because of staffing difficulties and detailed specification problems, this happens anyway; therefore plan to do it this way. In smaller developments the phased approach may not be inevitable, but there may still be good reasons for having a phased approach. SYSTEM SIZE (000)
Fig 4:
SLIM (PUTNAM)
In my view the primary function of this initial planning phase is to answer the following questions: Can it be done in the time?
Clearly, management must attempt to achieve an em date determined by a market wimow; what it must not do is go into the 'impossible' region of the graph! Therefore, the plans must be realistic in their timescales and have a degree of flexibility which can accommodate slip.
Would a series of prototypes be a better way of proceeding? What long lead time support is required eg standardS, models? What are the main deliverables?
When planning any large project it is necessary to select the appropriate technique from the many available. In System X computerised techniques like Program Evaluation am Review Techniques (PERT) were only found to be useful for identifying relationships between major activities; detailed PERTS seemed to be useless. Bar charts are essential. They allow activities to be allocated to staff, and, when developed further into a Work Plan, enable planned activity durations to be compared with actual durations. Work Plans should be drawn for each major functional grouping in a subsystem. The use of bar charts will allow an approximate project manpower profile to emerge, a bit like the model of manpower am skills in Fig 5. In practice it is more likely to have a shape like Fig 6 (from System X), showing the much slower build-up of staff. Be wary of any project which relies on a rapid build-up of staff!
What development environment is required? What are the approximate development costs? The points raised so far relate equally well to hardware am software systems, although for some particular reason software people seem to think that they can take 'short cuts'! Methods of preventing 'short cuts' are suggested in the Engineering Progress am Performance Reporting Section, later in this paper. As a result of taking 'short cuts' projects with a large software component often fail for the following main reasons: Technical failure Cost - overspem Time - overrun Quality - customer dissatisfaction
Cl>
Q.
o
Inadequate development support (computing power)
Cl>
Co
o Qi .0 E :J
Z
Time
Fig 5:
Manpower Profile
The idea of prototyping am phased development should be discussed at an early stage for complex projects which introduce new concepts or ideas. A prototype may well be necessary to check the usefulness and validity of the new ideas before they are incorporated into the final design. In
Most of these problems emanate from the planning phase of the project! A word of warning on the last point: don't forget both to plan for computing resources am to constantly review your requirements. Fig 7 shows how the need for computing power can grow in large projects. It is also worth noting that because these project timescales are often long it is possible to exploit the performance increase am cost reductions obtained by moving to an improved technology. the project proceeds through its definition phase the plans will become more detailed, am pass through several iterations. Eventually the plans must take on a shape which is going to enable project progress to be established. As
M. Key
100 Load & Power (1904 S Units)
.
T3
,:
"t,
T2
20
.----',
,
15
1------
",
,-,
"
,, ,,
Available Power +, 10
5
year T1. T2. T3 - technology update
Fig 7:
Computing Power
PROJECl' PROGRESS
I I I
, I I I
,---------
'PPR POINT
Take a look again at some of the earlier important manag8llent questions identified in Figure 1.
*
{ EFFORT EXPENDED RECORDED
Where am I going?
'-----1
I MODULE I
Where am I now? What can I do to get back on course if adrift? The plans, which will probably be a combination of PERT and Work Plans will enable the first three questions to be answered, but not the last two. The last two questions need to be looked at in a li ttle more depth because they are fundamental to the successful management of a complex project. Without special provision in the planning and progressing mechanism these questions are almost impossible to answer. ENGINEERING PRCGRESS AND PERFORMANCE REPORTING In System X a scheme called Engineering Progress and Performance Reporting (EPPR) was used. It has the abil i ty to answer the last two questions. EPPR was derived from a sch8lle suggested by the Bechtel Corporation and relies on the following being defined:
An engineering process (Life-cycle) Control points Control point assessment criteria The Engineering Process, Fig 8, represents the decomposition of the syst8ll to an activity hierarchy. There is a corresponding documentation hierarchy (6). One extr8llely important aspect of the engineering process is that it makes software 'visible'. After all, how can you be expected to manage an invisible product? In practice the engineering process is more detailed than shown here. Each activity will produce a ser ies of documents or products which must be reviewed before the activity is
~
-
-
-.....
DOCUMENTS DEFECTS
I_D!~~N_I
How do I get there? How long will it take?
PROOUCT OOCUMENTATlON
Fig 8:
Engineering Process
'complete' • The plans are drawn to expect these deliverables at a particular Control Point. Therefore the plans, which have been produced knowing the engineering process and the achiev8llent metrics for the project, must describe the following and relate to the control points: planned activities activity duration and man days achievement/month (for each activity) total resource profile (men/week) cumulative resource usage (budget) I t is likely that if your project plans do not capture this information your project is likely to end as a failure statistic!
A control point is only considered to be 'complete' when the control point deliverables have been reviewed by one or more people. At the end of the review the manager knows that: appropriate documents have been produced, documents have been reviewed and the necessary quality achieved, reviews linked to plans to produce progress information have been recorded. As a result it becomes more difficult for software engineers to 'cut corners' because they are forced to hand their work to someone else for review. The outline review procedure is shown in Fig 9.
Successful completion of the Control Point is real progress - not illusory - because the deliverable is free of defects as far as it is
101
Why Software has a Bad Name
known. The manpower used to complete the Control Point is known and it can now be compared with the estimated manpower. Developnent teCITI performance obtained from measuring achievement and resources used provides essential feedback data for the estimating models. Iteration for Defects
Standards Guidelines Procedural Tools Guidelines
Input
Output
'Ille personnel involved can be flexible. Any defects detected must be recorded. In practice there are likely to be at least two levels of review. The first will address the technical viability and completeness. 'Ille second reviews at a later date, could be seen as a documentation standards review. It is beneficial for the Validation TeCITI to have a separate reportin::/ structure. 'Ille validation team will be skilled and small and spread out over the total project to act as the devil's advocate. However, they will be able to perform a more thorough assessment job if they are incorporated into the developnent team. Management must not use the peer reviews as a method of assessing staff; in addition they must insist that the peer reviews are done thoroughly, because the overall project cost will relate stron::/ly to the thoroughness with which defects are removed in the early developnent stages. Without this cornnitment to quality it is very easy to pass defects to the teCITI at the next stage! CHANGE CCNI'ROL
Quality Controls
Fig 9:
Review Objectives
The reviewing stage introduces the need to manage chan::/e. Change control is a fundamental problem which is particularly acute in software based systems.
Stage Review Procedure
This information can be used as shown in Fig 10 to monitor and assess performance. Managers can row 'see' what they are supposed to produce in a particular time with a certain amount of labour. Any failure to achieve can be spotted immediately, its impact assessed and corrective action taken if possible. Even if no direct action can improve the situation, plans can be adjusted to take account of the probable delay. PERFORMANCE
'Ille amount of change in any large complex system will be horrendous. Don't forget that by definition the difficult bits are done in software! By way of an example look at the number of language systems that were required for System X, Fig 11. Here, it can be seen that several releases of each lan::/uage system were required for each processor, and this can be a fairly typical situation. PROCESSOR 4
~~~:S)
""
11101:11/1013" ' 1
TOTAL
\,,-i' p.CI-I\~~~9 PERCENTAGE
GOOD
_-- - -
COMPLETE
PRO CESSOR 3
""
""
~
15 I
""
61 62
""
NORMAL
PROCE SSOR 2
V31 VJ '
-----
BAD
1 1 1 1 1
I
MONTHS
£:::,. DELIVERABLE CODE
110110 111 112112113113112112110 110 111 I MEN
Fig 10:
Engineering Progress and Performance Report
Control Point reviews are essential for the success of large software projects. But there are some difficult psychological problems to be overcane i f the technique is to work well. Old habits die hard and as most university trainin::/ is aimed at establishin::/ the individual students capabilities, the sudden change to team capability is difficult for them to accept. In addition, we know there are wide variations in peoples' abilities. How can we make these 'critical' reviews psychologically acceptable, thus allowin::/ the maximum number of defects to be detected? One way is to encourage the 'two heads are better than one' approach and make the procedure obligatory.
\I l l
t t t
I
......
PROC ESSOR I
\'11
,~ , , , , ,
1 1 1 1 1 1 1 1 1 1 ,"22 11123 1 It I
1 1 1 1 1
I, I' I' I: I,
19781 1979
Fig 11:
1 1 1 1 1
",.
t
1 1 1 1 1 1 VI ·, I, I, I' I' I: I,
"'t '"rf
1 1980
1 1 1 1 1 1 1 1 1 1 1 1
I
"" t
""
t
1 1 1 1 1 ~ Vl ~
1 1 1 1 1
1981
I
1982
I
1983
Language System Releases
Each language system had a set of 'bugs' relating to it and it is of course essential that these bugs are recorded and the necessary corrections made to the correct lan::/uage system release. Failure to manage change control effectively can be catastrophic. Large systems create many changes. 'Ille :rocORAL compiler in Fig 12 shows row the number of bugs can become very large, wi th a large number outstandin::/ at any time.
M. Key
102
TOOLSET
FRAMEWORK
'!be developnent will not succeed unless the language system and application software are linked automatically to a compatible target processor, and the defects generated are recordable and trackable. 400
I I
I I
1----:--L"'
I
bugs SUBCONTR AC TORS
Fig 13:
Year
Fig 12: Bugs in Compiler DEVELOPMENI' TOOLS The software developnent technologies and methods of the 1960s and 1970s are now too expensive for many developnents. Unfortunately the software industry has allowed itself to be hi-jacked by academics rather than industrialists. As a result academics have been solving the problems they like solving, like designing a new language or compiler, rather than tackling the real problems facing the industry. ADA will not solve the software management problem! Clearly the developnent of any software project needs certain software tools, like compilers and linkers etc, as identified in TABLE 1. However, the tool set for effective software developnent today needs to be able to integrate the planning functions, specification and design activities, and the programming and testing functions (5). Therefore, the aim should be for a simple, stable support environment which integrates compatible developnents and encourages good management. In recent years much effort has rightly gone into the developnent of Integrated Project Support Environments (IPSE), and UNIX, because of its standardised nature and transportability, has often been at the heart of those systems. The tool set needs to be stretched to include CONFIGURATION MANAGEMENI' to allow systems to be built from a collection of generic software parts. The Engineering Process should capture all these functions. Where large dispersed teams are concerned a suitable communications network must be established to give all teams access to the same developnent facilities. Management's function is to make sure that the appropriate software developnent tool-set which provides effective and regular communication is available when required. Fig 13 is an example of an IPSE with these facilities.
I I
- ---- --WORKB ENCH
Integrated Project Support Environment (IPSE)
However, in the future it is likely that the biggest benefits will come from the dedicated application, by management, of the techiques already mentioned coupled with the computerisation and integration of these ideas. It is a pity that so many computer manufacturers still seem to think that computing is about hardware not software and universities have failed to attack the real management problems of software developnent. Until these attitudes are changed the large, complex system developers will have an uphill struggle and it must not be assumed that all the developnent support can be purchased ready-made. The long-term aim of the software industry must be to provide comprehensive and integrated developnent systems which are transportable. In response to this challenge, British Telecom is developing in collaboration with Imperial Software Technology an IPSE - which you all know stands for: I Produce Software Easier! - and it is called ISTAR (7) •
ACKNOWLECGEMENTS Acknowledgement is made to the Director of Technology Applications, British Telecom, for permission to publish this paper. UNIX is a tradmark of Bell Labs ADA is a trademark of Department of Defence ISTAR is a trademark of Imperial Software Technology REFERENCES 1 Brooks F. P.: (1984), 'Excerpts from The Mythical Man/Month'; Essays on Software Engineering Datamation, December 1984. 2 Putnam, L.H.: (1978), 'A General Empirical Solution to the Macro Softwar e Sizing and Estimating Problem'. IEEE Transaction on Software Engineering, Vol SE-4, No 4, July 1978. 3 Boehm, B.W.: (1981), 'Software Engineering Economics', Prentice-Hall. 4 Kitchenham, B.A.: Taylor, N.R.: (1984), 'Software Cost Models', ICL Technical Journal, May 1984. Loome, S.R.: (1980), System X; Part 3 'Software Developnent Facilities', POEEJ, Vol 73, April 1980. 5
MANAGEMENT IN FUl'URE SOF'IWARE DEVELOPMENI'S In Europe, we are seeing projects unfold which, if they are to succeed, will require all the management skills we can muster. '!be management techniques of System X and other similar projects are relevant for the systems of tomorrow.
Sheekey, B., (1980), System X; Part 4 6 'Developnent Documentation Scheme', POEEJ, Vol 73, July 1980. 7 Dowson, M., (1986), 'An overv iew of ISTAR', Imperial Software Technology, London.
THE REASONS WHY SOFTWARE HAS A BAD NAME M. Key T erhllology E.'(frlllh'f, Brilish Teit'rolllllllllliralioll s plr. //J.lll'irh. SII[f(Jlk. [ 'K
Abstract: Using System X development experience the paper describes very briefly the total development environment to illustrate the problems of managing software projects. There is an emphasis on how important problems of software management and development were overcome. '!he paper also exposes some of the myths and draws attention to the main weaknesses of the software industries' approach to software development today. Keywords: Management; engineering process; manpower profiles; control points; validation teams; planning. large-scale projects of more than 4 year's duration span the term for which most governments are in office - and political change and uncertainty can be just as damaging as world economic change - how many times have the British and French tried to build a channel tunnel? Thus, what was conceived as a brilliant solution 10 years ago could have been overtaken by events. Hence the last question, "Is the development still worthwile and likely to be so for the foreseeable future?" This is an impor tant question and should be asked regularly.
INTRODUCTION
This paper is fairly wide-ranging in terms of the problems of managing projects which have a large software/firmware component. I t is hoped that it will touch on a few myths and a few home truths. Most of the relevant management experience has been drawn fran a continuous involvement in the evolution of digital switching in British Telecom since 1965, and in particular, the developments of System X. '!here are many facets to managing a large project. Perhaps if we look at the basic management questions which need to be asked for any large software project we can see more clearly how the management of software can so easily go wrong. The important management questions are shown below in Figure 1.
Before any large software project can even be contemplated there must be an infrastructure of experience, of similar or related projects, within the organisation. For example it is difficult to build a Concord if you have not built an aeroplane before, and most companies would not try. In the software industry, some companies do attanpt to leap-frog product generations:with the inevitable consequences.
• What needs to be done?
• How do we get there? • How many people'
The infrastructure will primarily be concerned with the management and quality of product development.
• How long will it take to build?
• How do we record designs and implementations ?
Figure 2 shows how this infrastructure precedes the classical software development life-cycle.
• How do we check that the product is good? • How do we chec k that we are
• M anagement
on schedule?
• Quality
• How do we control changes?
• Requirements
• How do we manage the product in the field?
• Specificat ion
• Is the development still worth
• Design and coding
while'
Fig 1:
• Unit test
Important Management Questions
• Integration
The first thing you notice is that software hardly features in terms of the questions which need to be asked - these are general management problems.
• System test and va lidat ion
Fig 2:
It is easy to produce a list of activities like this, but the implications of these activities are obviously not well understood. This p3.per attempts to highlight sane of the more important aspects.
PROJECT COOCEPTION
The Management questions which are asked above need to be answered dur ing any development. The time at which these questions are asked is very important. Developments which are most at risk are large, canplex systems which inevitably take a long time to complete. But do not be canplacent if you are involved in only 9llallscale developments. Worthwhile improvements will be obtained with a more rigorous management awroach in 9llall-scale projects as well! Many EMSP-H
Software Development Life-cycle
MANAGEMENT STRUCWRE
The whole development needs to be managed by an embryonic management structure which can grow and resporrl to the needs of the project and which will allow co-ordination, progress reporting and rapid decision making to take place effectively. 97
M. Key
98
The structure of the managanent team is critical, but there is no optimum managanent organisation; it depems on circumstances. However, any managanent structure must clearly define a minimum of four areas of managanent responsibility and they are shown here:-
TABIE 1:
Object Code Size k words
Tool
Library
75
Build System -
Planning
Language System for System X
ESG. GME , Collator ,
65
Consolidator , Executor
The target developnent
BT Coral Compile, -
PROCl PROC2 PROC3 PROC4
260
Linker
45
The support for that developnent; am
Lister
20 15
An independent validation team with allegiance to the customer.
Constructs Checker
Source Formatter
How these responsibilities might interrelate are shown in Fig 3.
30
Process Combiner - splitter
100
Software Message Generator - Online / Offline
200 20 150
Debug Emulator -
Test / Debug / Single Proce ss
Interpreter
75
Static Analyser
30
Dynamic Analyser
30
Cross Reference
70
General Ma c ro Processor
SXl
30 200
MSeq
10
Scarab
60 20
Draw Epp
Online
20
Asynchronous link handler - George 3 / CPM
10
Data Compiler
I
Data Decompiler
500
Downloading via synchronous protocol
30
MMI User control macros
45
Model Incident Report database
40
2150
PLANNING
Figure 3 shows one of many subsystems under the control of a Systan Manager. Subsystans were created where function, geography or team size (15-35) would have created a managanent problan if not properly coordinated.
Usually the first thing the management team will do is prcxluce a plan. This is an important first step .•• because "if you do not know where you are goirg you should not be surprised if you em up in the wrong place!" Planning is notoriously difficult am the first plan is bourn to be wrong! Senior management has this uncanny knack of dananding that a prcxluct is in the field by a certain date and then working backwards from there. 'The Mythical Man/Month' (1), tells us that this is often not a sensible way to proceed if you are not prepared to accept the answer: "It can't be done in the time". The idea that certain things cannot be done in less than a given time does not seem to register with some managers. If confronted with this problem it is recanmended that estimating techniques like the PUI'NAM (SLIM) mcxlel (2), or the CCCCMMO mcxlel (3), are used to substantiate your claim.
What is obvious, but does not always happen, is that the support and validation teams need to be set up first to build the support foumations. These support teams are often substantial and they will be involved in the generation of documentation standards, planning standards and estimating techniques, quality procedures am support software developnent. Any deficiencies must be corrected early in the project's life. If you do not believe this look at 'l1IBIE 1. It shows the scope of System X support software developnent.
These mcxlels use data from software related projects of all types. By mapping your project's important parameters into these databases it is possible to predict resources and timescales required. Initially, these estimates are inaccurate, but the accuracy with which project timescales or costs can be estimated improves over a period of time as the project definition is refined. For example the fact that a project is mainly real-time or data processing has a significant impact on the project costs.
In this case much developnent was required to support the high-level language POCORAL. Notice this is much more than a compiler developnent it is a language systan. This support software is comparable in size with the telephone switching application!
One important feature of SLIM, Fig 4, is that the impact of manpower on timescales can be clearly seen. It also shows an Impossible Region. Faced with this evidence it is more difficult for the senior manager to say: "Well, if you can't do it, I will f im someone who can!".
Fig 3:
Management Structure
99
Why Software has a Bad Name DEVELOPMENT TIME (YEARS)
NUMBER OF
SOFTWARE PHASE 1 ENGINEERS I----~I
PHASE 3 PHASE 2
600
400
200
YEAR
Fig 6:
Phased Approach to Manpower Growth
practice, because of staffing difficulties and detailed specification problems, this happens anyway; therefore plan to do it this way. In smaller developments the phased approach may not be inevitable, but there may still be good reasons for having a phased approach. SYSTEM SIZE (000)
Fig 4:
SLIM (PUTNAM)
In my view the primary function of this initial planning phase is to answer the following questions: Can it be done in the time?
Clearly, management must attempt to achieve an em date determined by a market wimow; what it must not do is go into the 'impossible' region of the graph! Therefore, the plans must be realistic in their timescales and have a degree of flexibility which can accommodate slip.
Would a series of prototypes be a better way of proceeding? What long lead time support is required eg standardS, models? What are the main deliverables?
When planning any large project it is necessary to select the appropriate technique from the many available. In System X computerised techniques like Program Evaluation am Review Techniques (PERT) were only found to be useful for identifying relationships between major activities; detailed PERTS seemed to be useless. Bar charts are essential. They allow activities to be allocated to staff, and, when developed further into a Work Plan, enable planned activity durations to be compared with actual durations. Work Plans should be drawn for each major functional grouping in a subsystem. The use of bar charts will allow an approximate project manpower profile to emerge, a bit like the model of manpower am skills in Fig 5. In practice it is more likely to have a shape like Fig 6 (from System X), showing the much slower build-up of staff. Be wary of any project which relies on a rapid build-up of staff!
What development environment is required? What are the approximate development costs? The points raised so far relate equally well to hardware am software systems, although for some particular reason software people seem to think that they can take 'short cuts'! Methods of preventing 'short cuts' are suggested in the Engineering Progress am Performance Reporting Section, later in this paper. As a result of taking 'short cuts' projects with a large software component often fail for the following main reasons: Technical failure Cost - overspem Time - overrun Quality - customer dissatisfaction
Cl>
Q.
o
Inadequate development support (computing power)
Cl>
Co
o Qi .0 E :J
Z
Time
Fig 5:
Manpower Profile
The idea of prototyping am phased development should be discussed at an early stage for complex projects which introduce new concepts or ideas. A prototype may well be necessary to check the usefulness and validity of the new ideas before they are incorporated into the final design. In
Most of these problems emanate from the planning phase of the project! A word of warning on the last point: don't forget both to plan for computing resources am to constantly review your requirements. Fig 7 shows how the need for computing power can grow in large projects. It is also worth noting that because these project timescales are often long it is possible to exploit the performance increase am cost reductions obtained by moving to an improved technology. the project proceeds through its definition phase the plans will become more detailed, am pass through several iterations. Eventually the plans must take on a shape which is going to enable project progress to be established. As
M. Key
100 Load & Power (1904 S Units)
.
T3
,:
"t,
T2
20
.----',
,
15
1------
",
,-,
"
,, ,,
Available Power +, 10
5
year T1. T2. T3 - technology update
Fig 7:
Computing Power
PROJECl' PROGRESS
I I I
, I I I
,---------
'PPR POINT
Take a look again at some of the earlier important manag8llent questions identified in Figure 1.
*
{ EFFORT EXPENDED RECORDED
Where am I going?
'-----1
I MODULE I
Where am I now? What can I do to get back on course if adrift? The plans, which will probably be a combination of PERT and Work Plans will enable the first three questions to be answered, but not the last two. The last two questions need to be looked at in a li ttle more depth because they are fundamental to the successful management of a complex project. Without special provision in the planning and progressing mechanism these questions are almost impossible to answer. ENGINEERING PRCGRESS AND PERFORMANCE REPORTING In System X a scheme called Engineering Progress and Performance Reporting (EPPR) was used. It has the abil i ty to answer the last two questions. EPPR was derived from a sch8lle suggested by the Bechtel Corporation and relies on the following being defined:
An engineering process (Life-cycle) Control points Control point assessment criteria The Engineering Process, Fig 8, represents the decomposition of the syst8ll to an activity hierarchy. There is a corresponding documentation hierarchy (6). One extr8llely important aspect of the engineering process is that it makes software 'visible'. After all, how can you be expected to manage an invisible product? In practice the engineering process is more detailed than shown here. Each activity will produce a ser ies of documents or products which must be reviewed before the activity is
~
-
-
-.....
DOCUMENTS DEFECTS
I_D!~~N_I
How do I get there? How long will it take?
PROOUCT OOCUMENTATlON
Fig 8:
Engineering Process
'complete' • The plans are drawn to expect these deliverables at a particular Control Point. Therefore the plans, which have been produced knowing the engineering process and the achiev8llent metrics for the project, must describe the following and relate to the control points: planned activities activity duration and man days achievement/month (for each activity) total resource profile (men/week) cumulative resource usage (budget) I t is likely that if your project plans do not capture this information your project is likely to end as a failure statistic!
A control point is only considered to be 'complete' when the control point deliverables have been reviewed by one or more people. At the end of the review the manager knows that: appropriate documents have been produced, documents have been reviewed and the necessary quality achieved, reviews linked to plans to produce progress information have been recorded. As a result it becomes more difficult for software engineers to 'cut corners' because they are forced to hand their work to someone else for review. The outline review procedure is shown in Fig 9.
Successful completion of the Control Point is real progress - not illusory - because the deliverable is free of defects as far as it is
101
Why Software has a Bad Name
known. The manpower used to complete the Control Point is known and it can now be compared with the estimated manpower. Developnent teCITI performance obtained from measuring achievement and resources used provides essential feedback data for the estimating models. Iteration for Defects
Standards Guidelines Procedural Tools Guidelines
Input
Output
'Ille personnel involved can be flexible. Any defects detected must be recorded. In practice there are likely to be at least two levels of review. The first will address the technical viability and completeness. 'Ille second reviews at a later date, could be seen as a documentation standards review. It is beneficial for the Validation TeCITI to have a separate reportin::/ structure. 'Ille validation team will be skilled and small and spread out over the total project to act as the devil's advocate. However, they will be able to perform a more thorough assessment job if they are incorporated into the developnent team. Management must not use the peer reviews as a method of assessing staff; in addition they must insist that the peer reviews are done thoroughly, because the overall project cost will relate stron::/ly to the thoroughness with which defects are removed in the early developnent stages. Without this cornnitment to quality it is very easy to pass defects to the teCITI at the next stage! CHANGE CCNI'ROL
Quality Controls
Fig 9:
Review Objectives
The reviewing stage introduces the need to manage chan::/e. Change control is a fundamental problem which is particularly acute in software based systems.
Stage Review Procedure
This information can be used as shown in Fig 10 to monitor and assess performance. Managers can row 'see' what they are supposed to produce in a particular time with a certain amount of labour. Any failure to achieve can be spotted immediately, its impact assessed and corrective action taken if possible. Even if no direct action can improve the situation, plans can be adjusted to take account of the probable delay. PERFORMANCE
'Ille amount of change in any large complex system will be horrendous. Don't forget that by definition the difficult bits are done in software! By way of an example look at the number of language systems that were required for System X, Fig 11. Here, it can be seen that several releases of each lan::/uage system were required for each processor, and this can be a fairly typical situation. PROCESSOR 4
~~~:S)
""
11101:11/1013" ' 1
TOTAL
\,,-i' p.CI-I\~~~9 PERCENTAGE
GOOD
_-- - -
COMPLETE
PRO CESSOR 3
""
""
~
15 I
""
61 62
""
NORMAL
PROCE SSOR 2
V31 VJ '
-----
BAD
1 1 1 1 1
I
MONTHS
£:::,. DELIVERABLE CODE
110110 111 112112113113112112110 110 111 I MEN
Fig 10:
Engineering Progress and Performance Report
Control Point reviews are essential for the success of large software projects. But there are some difficult psychological problems to be overcane i f the technique is to work well. Old habits die hard and as most university trainin::/ is aimed at establishin::/ the individual students capabilities, the sudden change to team capability is difficult for them to accept. In addition, we know there are wide variations in peoples' abilities. How can we make these 'critical' reviews psychologically acceptable, thus allowin::/ the maximum number of defects to be detected? One way is to encourage the 'two heads are better than one' approach and make the procedure obligatory.
\I l l
t t t
I
......
PROC ESSOR I
\'11
,~ , , , , ,
1 1 1 1 1 1 1 1 1 1 ,"22 11123 1 It I
1 1 1 1 1
I, I' I' I: I,
19781 1979
Fig 11:
1 1 1 1 1
",.
t
1 1 1 1 1 1 VI ·, I, I, I' I' I: I,
"'t '"rf
1 1980
1 1 1 1 1 1 1 1 1 1 1 1
I
"" t
""
t
1 1 1 1 1 ~ Vl ~
1 1 1 1 1
1981
I
1982
I
1983
Language System Releases
Each language system had a set of 'bugs' relating to it and it is of course essential that these bugs are recorded and the necessary corrections made to the correct lan::/uage system release. Failure to manage change control effectively can be catastrophic. Large systems create many changes. 'Ille :rocORAL compiler in Fig 12 shows row the number of bugs can become very large, wi th a large number outstandin::/ at any time.
M. Key
102
TOOLSET
FRAMEWORK
'!be developnent will not succeed unless the language system and application software are linked automatically to a compatible target processor, and the defects generated are recordable and trackable. 400
I I
I I
1----:--L"'
I
bugs SUBCONTR AC TORS
Fig 13:
Year
Fig 12: Bugs in Compiler DEVELOPMENI' TOOLS The software developnent technologies and methods of the 1960s and 1970s are now too expensive for many developnents. Unfortunately the software industry has allowed itself to be hi-jacked by academics rather than industrialists. As a result academics have been solving the problems they like solving, like designing a new language or compiler, rather than tackling the real problems facing the industry. ADA will not solve the software management problem! Clearly the developnent of any software project needs certain software tools, like compilers and linkers etc, as identified in TABLE 1. However, the tool set for effective software developnent today needs to be able to integrate the planning functions, specification and design activities, and the programming and testing functions (5). Therefore, the aim should be for a simple, stable support environment which integrates compatible developnents and encourages good management. In recent years much effort has rightly gone into the developnent of Integrated Project Support Environments (IPSE), and UNIX, because of its standardised nature and transportability, has often been at the heart of those systems. The tool set needs to be stretched to include CONFIGURATION MANAGEMENI' to allow systems to be built from a collection of generic software parts. The Engineering Process should capture all these functions. Where large dispersed teams are concerned a suitable communications network must be established to give all teams access to the same developnent facilities. Management's function is to make sure that the appropriate software developnent tool-set which provides effective and regular communication is available when required. Fig 13 is an example of an IPSE with these facilities.
I I
- ---- --WORKB ENCH
Integrated Project Support Environment (IPSE)
However, in the future it is likely that the biggest benefits will come from the dedicated application, by management, of the techiques already mentioned coupled with the computerisation and integration of these ideas. It is a pity that so many computer manufacturers still seem to think that computing is about hardware not software and universities have failed to attack the real management problems of software developnent. Until these attitudes are changed the large, complex system developers will have an uphill struggle and it must not be assumed that all the developnent support can be purchased ready-made. The long-term aim of the software industry must be to provide comprehensive and integrated developnent systems which are transportable. In response to this challenge, British Telecom is developing in collaboration with Imperial Software Technology an IPSE - which you all know stands for: I Produce Software Easier! - and it is called ISTAR (7) •
ACKNOWLECGEMENTS Acknowledgement is made to the Director of Technology Applications, British Telecom, for permission to publish this paper. UNIX is a tradmark of Bell Labs ADA is a trademark of Department of Defence ISTAR is a trademark of Imperial Software Technology REFERENCES 1 Brooks F. P.: (1984), 'Excerpts from The Mythical Man/Month'; Essays on Software Engineering Datamation, December 1984. 2 Putnam, L.H.: (1978), 'A General Empirical Solution to the Macro Softwar e Sizing and Estimating Problem'. IEEE Transaction on Software Engineering, Vol SE-4, No 4, July 1978. 3 Boehm, B.W.: (1981), 'Software Engineering Economics', Prentice-Hall. 4 Kitchenham, B.A.: Taylor, N.R.: (1984), 'Software Cost Models', ICL Technical Journal, May 1984. Loome, S.R.: (1980), System X; Part 3 'Software Developnent Facilities', POEEJ, Vol 73, April 1980. 5
MANAGEMENT IN FUl'URE SOF'IWARE DEVELOPMENI'S In Europe, we are seeing projects unfold which, if they are to succeed, will require all the management skills we can muster. '!be management techniques of System X and other similar projects are relevant for the systems of tomorrow.
Sheekey, B., (1980), System X; Part 4 6 'Developnent Documentation Scheme', POEEJ, Vol 73, July 1980. 7 Dowson, M., (1986), 'An overv iew of ISTAR', Imperial Software Technology, London.