The SESAME projectby Keith Southwell

A large proportion of Logica's work is concerned with thedevelopment of software. It is therefore fundamental that themethods and tools used are geared to the production of high-quality software in an efficient manner. Project SESAME wasinitiated in 1983 to ensure that this continues to happen in theface of the rapid improvements which are now taking place insoftware technology. This paper describes: the history of theproject and its objectives; the approach adopted to introducing newtechnology, covering the organisational issues raised and thetrade-offs between persuasion and compulsion; the choices madein specific areas of software engineering tools and methods, andthe reasons for these choices; the activities carried out, includingthe documents provided to Logica staff and the trainingprogramme which has been initiated; the implications for otherareas such as quality standards; and the lessons that have beenlearned.

1 Introduction

Introducing new technology into a largeorganisation is a major undertaking,whatever the field. The wjy in which it isdone must take as much account of theorganisation as of the technology. Indesigning systems we rightly put muchemphasison startingwith a requirementsanalysis. However, in prescribing tech-

nology forourown use,weareoften readyto promote a packaged solution with theminimum of analysis.

The main characteristics of Logica'sorganisation in this context are diversityand devolution. We develop software for atremendous range of applications, pro-cessors and operating systems, in manydifferent languages. Indeed, we win a sig-nificant proportion of our work because

Fig. 1 Distribution of Logica's offices

212

of just this flexibility. We have over 30offices (see Fig. 1) around the world,almost all of which engage in softwaredevelopment in their own right. Many ofthese offices have a considerablemeasure of independence, as indeed dothe major operating companies in the UK.

For some years now, we have had com-pany-wide standards for project manage-ment, documentation, quality manage-ment, and so on, and these provide acommon framework for all the workwhich we carry out. However, because ofthe diversity of that work, and the variedrequirements imposed by many of ourclients, there has been little attempt at acorporate level to standardise, forexample, on a single programming lan-guage or a particular type of computer.

In view of the developments which hadbeen taking place in software engineer-ing, however, we began in 1982 to look forways in which we could go about intro-ducing this new technology in a system-atic way across all our operations while, atthe same time, paying due regard to thevariety of our work. These deliberationsled, in mid-1983, to the setting up of Pro-ject SESAME. The objective of this projectis simple: to improve Logica's effective-ness in developing software. At that time,it was seen as a two-year initiative; sincethen it has been extended indefinitely.While, on the one hand, it has becomeclear that the time scales involved in sucha large-scale initiative are longer than twoyears, on the other hand the project wasby that time an accepted and valuable partof the company's operation.

One of the most difficult decisions wehad to take was not so much what toolsand methods we should introduce, buthow to go about introducing them. Wedecided to adopt an approach that helpedto answer both questions at the sametime. The conventional approach would, Isuppose, have been to carry out anexhaustive study of the requirements ofthe different operating units, and of thetools and methods available, resulting in apolicy document which would then beimplemented. An alternative approachwould have been to identify a number ofpilot projects which could then serve as anexample to the rest of the company.

Instead, we decided that we would havethe greatest chance of success if we wereto see our role as one of promotion and

Software Engineering Journal November 1986

education rather than one of deciding andimplementing policy. We also believedthat the amount of standardisationachieved by this route need be no less(and possibly even more!) than thatachieved by a direct attempt to imposestandards. A uniform approach emergesas a result of consistently applying anagreed SESAME policy when we makerecommendations. This policy is, how-ever, free to evolve in the light of experi-ence and technological developments.

2 Strategic issues

2.1 Criteria for success

The main objectives being pursued are:

• reduced development effort• reduced development time scales• improved ability to predict effort andtime scales.

It is difficult to produce a useful quantita-tive demonstration that these objectiveshave been achieved, for the followingreasons:

• The only reliable measure of product-ivity currently available is that of lines ofcode or statements produced in a giventime. Many of the real productivity gainswill be achieved by avoiding the need toproduce much of the code, so that focus-ing on statements per day as a measureof productivity improvement will be mis-leading. Function points provide a usefulapproach to productivity measurement,but we do not feel that this approach isadvanced enough to provide a solution tothe problem at the moment.• Much of the technology is progress-ing at a rate which means that, even ifsuch information were to be obtained, itwould serve only to demonstrate that lastyear's tools were better than those of theprevious year; what you really want toknow is the effect of next year's tools.

It nevertheless seems to us self-evidentthat one should continually seek toimprove effectiveness by a variety ofmeans, including improved tools andmethods, computer facilities, training andeducation.

The ability to predict effort and timescales is in many ways just as important asthe ability to reduce them. This improvedpredictability results both from the bettertools and methods themselves, and frombetter estimating models. In due course, itwill also improve our ability to measureimprovements in productivity.

To put all this in context, a 10% savingon one large project, or indeed a 10%price increase as a result of better estima-ting, would pay at a stroke for the whole ofSESAME to date. If you take, for example,a Cocomo view of project costs, such a

10% change is almost at the noise level.We also believe that the full effects of

SESAME will not be visible until five yearsafter its inception. A whole sequence ofthings needs to happen:

• one has to decide which tools andmethods to promote• people have to be made aware of thisand the ideas must be sold to them• appropriate projects on which to startimplementing new ideas have to be found• those projects have to go throughtheir formative stages• the projects have to be carried out.

It will be five years before sufficient pro-jects have been through this cycle so thatit can be said with confidence that theorganisation has been transformed.

Furthermore, it will be one or two yearsbefore there is any visible evidence thatthe organisation is on the right road.Within Logica, SESAME is only nowreaching the state where it has the almostunanimous support of our operatingcompanies.

2.2 Organisation

There was considerable discussionover whether a central group should becreated and what its relationship shouldbe to the rest of the organisation.

The arguments for a central group arethat:

• people who understand the issues arean extremely scarce resource• a single closely knit group of peoplewill learn more quickly by being able tobounce ideas off each other• they will be able to promote a com-pany-wide approach.

The arguments against are that:

• there is a danger that they becomeremote from the real issues and from theviews of people working on projects• in order for progress to be made,people at all levels throughout the organ-isation must have the feeling that they arebringing about change under their owninitiative, and because they want it.

We believe that any organisation whichignores either of these viewpoints will notsucceed. We therefore have a centralgroup which, nevertheless, aims to bringabout change by keeping close to themain development activities and ensuringthat the motivation is there beforeproceeding.

Having decided to establish a centralgroup, one has to decide how it shouldrelate to the rest of the organisation. Theapproach on SESAME has been that wehave no power, but good communication

Software Engineering Journal November 1986

lines. The communication lines havebeen as follows:

• For the first two years, we had accessto a steering committee (all main boarddirectors) both as a group and asindividuals.• Our situation, with a rather ill definedposition in the organisation but visibleboard level backing, has made it fairlyeasy to approach anyone in any of ouroperating companies, from the managingdirector down.• The initial members of the SESAMEteam were long standing members ofLogica with good contacts in theorganisation.

Because we have no power, people'sreadiness to listen to us has largelydepended on what we said, how we said it,and whether they had any interest in thesubject, rather than on their distance fromus on the organisation chart, either ver-tically or horizontally.

Where we have succeeded in bringingabout change it has been by makingpeople better informed. As a result, theycould take their own decisions to intro-duce new approaches and were betterable to respond to pressures from theirclients or staff to do things differently.

Where we have succeeded in spreadinga uniform approach, it has been by mak-ing it easier for people to do things thatway (for example easier to get hold of onetool rather than another) or by publicisingthe fact that several other projects werealready using a particular method. Doingwhat everyone else has chosen to do oftenhas its attractions.

2.3 Standardisation

We believe that any organisation needsto decide where it should standardise, andwhere it should allow people to do as theychoose.

Standardisation is necessary for manyreasons. However, if you try to standardiseeverything you will grind to a halt. Stan-dardisation can sometimes be the enemyof progress. Therefore, in order to bringabout change, one must precede everycall for standardisation by asking: 'Is itreally necessary?"

We are currently in the process ofre-writing our standards. This work isdescribed in more detail below. However,the main point is that there will be a muchsmaller set of mandatory standards thanat present, and they will concentrate onfundamentals, rather than details. Theywill contain statements such as 'y°u w ' "have a project plan and quality plan; it willidentify the deliverable items', and so on.We believe we can enforce that withoutconstraining our operations unduly.

At the same time, individual operating

213

companies will be free to be more con-straining if they so choose. Furthermore,we shall offer them a set of more detailedstandards which they may choose toadopt if they wish. We hope they will find iteasier to do so, if we do our job well. Theimportant point is that they are in com-mand of their own destiny— their successis not judged on the basis of conformitywith arbitrary details.

2.4 Choice of projects

One view is that one should not experi-ment on the important projects. After all,large projects have never had any prob-lems in the past . . ..

What we are actually trying to achieve istwo things:

• that new and experimentalapproaches should be tried out on small-ish projects by committed enthusiasts,and that the results should be widelydisseminated• that large important projects shouldmake use of the best of current practice —on such projects, the main battle is oftento avoid all the apparent reasons for notdoing the obvious.

3 SESAME'S activities

3.1 The reports

Over the past three years we havedeveloped a collection of around 50reports addressing a wide range of soft-ware engineering topics. Each of thesereports, when first produced, is dis-tributed to about 200 key staff throughoutthe company, and is freely available toanyone in the company who asks for acopy. I am sure that many copies remainunread; equally, however, we know thatthe reports are generally widely used, andconstitute almost certainly our mostpowerful single means of creating andmaintaining awareness of software engin-eering issues.

The reports are in general concernedwith providing practical information ontools and methods to allow staff to decidewhether to use them, to help them todecide which to use, and to tell themwhere to obtain training, further infor-mation, and so on. They cover five mainareas:

• software methods, covering both thegeneral principles of structured analysis,

structured design, finite-state machinesetc. on the one hand, and specificmethods such as S$ADM and JSD on theother• tools and support environments,covering both tools for specific purposes(for example testing) and sets of tools forparticular environments (for exampleVAX/VMS and UNIX)• fourth-generation tools' for rapiddevelopment of information systems• tools and methods for estimatingand project planning• workstations (these reports are con-cerned mainly with advice on obtaining abasic level of automated support in situ-ations where more sophisticated tools arenot available).

Fig. 2 shows the range of the reports wehave produced.

Reports on methods:

At the top level, one of the first reportswe produced was a 'SESAME methodsportfolio". This report contains briefdescriptions and classifications of a rangeof methods and techniques as diverse asstructured programming and SSADM.

Reports on fourth-generation tools

Fourth-generation tools: an introductionFourth-generation tools for workstationsFourth-generation tools for

minicomputersFourth-generation tools for mainframes

Reports on workstations

Workstations and workstation toolsThe Apple MacintoshTho IRM PP rannoi iic iDivi " o rdnyt;

Integrated software packages forworkstations

Portable workstations

Reports on project planning andcontrol

Project planning toolsProject Manager WorkbenchLogica productivity dataSoftware cost estimation using CocomoImplementing Cocomo on a spreadsheetPrompt II

SESAME reports: family tree

Reports on project supportenvironments

Programming support environmentsAda and her APSEPerspectiveSoftware tools to aid testing

Reports on UNIX

UNIX-based project supportpn\/irnnmpntQCl IVM \Jl II 1 ICI 1 tO

Experience of UNIX within LogicaUNIX tutorialUse of Make and SCCS for

configuration control

Reports on VAX/VMS

VMS-based PSEsExperience of VAX VMS in LogicaConfiguration control for VAX VMS

Reports on Tandem/Guardian

Experience in Logica of developingTandem applications

Tandem-based PSEs

Reports on methods

SESAME methods portfolioFormal reviewsJackson structured programmingFinite-state machinesProgram and data structuringModule testing and analysisStructured analysi

design3 and structured

MascotSSADMIDEF (SADT)Petri netsJackson system developmentAn approach to formalised functional

specificationApproaches to software design

Fig. 2 SESAME reports: family tree

214 Software Engineering Journal November 1986

Managing system development

The role of the project managerProject life cyclesProject planning, control and reportingSoftware development economics and estimatingQuality and configuration management

System specification and design

The development process (including prototyping,incremental development etc.)

Requirements specifications, functionalspecifications and design specifications

Tools and methods for analysis and designFourth-generation tools and their impactPerformance and reliabilityThe interactions between all of these

i k

Project support environmentsManaging software teamsContracts and change controlProcurement and subcontractorsDocumentation and security

Structured programmingtechniques

Program structuringData structuring and data hidingInformal proofs of correctnessMeasures of complexityTesting techniques and toolsDebugging techniques and tools

t

Validation, verification and testing

Validation and verification of specificationsModule testingIntegration, system testing and acceptance testing >Formal reviewsTools for testingManaging and documenting validation, verification and testing

Fig. 3 SESAME 'technology awareness' courses

The implication was that we were provid-ing the analyst or designer with a 'port-folio' of methods from which to choose.As time has progressed, it has becomeclear, not only that time has moved on,but also that:

• a more structured document wouldhave benefits over the essentially one-dimensional list provided initially (seeSection 4.2)

• the majority of readers were lookingfor fairly specific recommendations.

Accordingly, we are currently producing acomplete replacement for this initialreport, which will be entitled 'Methods foranalysis and design'. A complementaryreport covering Tools for analysis anddesign'is also in preparation.

In addition to these top-level reports, wehave a range of reports describing individ-ual methods. These cover:

• Jackson structured programming• Mascot• SSADM• SADT/IDEF• Jackson system development• Yourdon structured analysis anddesign• formal methods (VDM, Z, OBJ etc.)• Petri nets• finite-state machines,

as well as the more general topics of:

• formal reviews (inspection andwalkthroughs)• program and data structuring• module testing and analysis• structured analysis and design.

Each of these reports aims to cover:

• a description of the methods (typically30 pages)• experience and implications for use inLogica• tools, literature and training available.

Reports on support environments:

The reports on project support environ-ments fall into two categories:

• recommendations for sets of tools forsome of the operating systems mostcommonly used for system developmentin Logica• a number of other reports coveringtopics which do not easily fit in the abovereports.

In the first category, we have producedreports covering VAX/VMS, UNIX andTandem/Guardian. For each of thesethere are at least two basic reports (forexample 'UNIX-based project supportenvironments', and 'Experience of UNIXwithin Logica). In addition there are somesubsidiary reports covering topics such asconfiguration control tools in more detail.

In the second category, we have pro-duced reports on:

• purpose-built support environments(Perspective, Maestro)• Ada and Ada project supportenvironments• tools to aid testing.

Reports on fourth-generation tools:

One of the principal difficulties whichpeople encounter in approaching 'fourth-generation tools' is to establish how all thevarious offerings which are described assuch relate to each other. For this reason,we produced a report (subsequently com-prehensively re-written) which cate-gorises types of tools in terms of what theyaim to achieve, who they are aimed at(end-users, developers etc.) and whatfacilities they offer. This 'Introduction tofourth-generation tools' is then sup-plemented by three further reports com-paring individual products:

• 'Fourth-generation tools for main-frames', describing the major systemsaimed at IBM and other mainframes• 'Fourth-generation tools for mini-computers', describing systems aimedtypically at the DEC VAX and comparablemachines• 'Fourth-generation tools for work-stations', covering tools aimed at single-user systems.

Software Engineering Journal November 1986 215

qualitymanual

mandates provides

mandatorystandards •provides

OADepartment

definesrequirementsfor I

provides

qualityplans • mandates •

optionalstandards

provides

project

mandates

-provides •project-specificstandards

Fig. 4 Logica standards

Reports on estimating andplanning:

This area has in some ways been one ofthe easier ones to address, since the sub-ject matter is probably the most widelyapplicable.

For estimating, we have used Cocomofor some time, but have also felt the lackof an easily accessible, distributable guideto its use. This has been addressed byproducing 'Software cost estimationusing Cocomo', which aims to makeusers self-sufficient for day-to-day use.We have also produced 'ImplementingCocomo on a spreadsheet' to assist staffwho do not have access to SyCo (see Sec-tion 3.6).

In order to allow staff to consider therelative merits of different estimatingmethods, and to discuss these withclients, we are also producing 'Softwareestimating methods', which comparesCocomo with Slim, Price-S and Albrecht's'function points'.

Our approach to project planning toolsis described in Section 4.5. We have pro-duced reports covering both 'ProjectManager Workbench' and a review of'Project planning tools' covering toolscosting from £100 to £100000.

Finally, we have recently produced areport on Prompt II, the project manage-ment approach adopted by the UKGovernment Central Computer and Tele-communications Agency (CCTA).

3.2 Education and training

One of the decisions we had to take washow to divide our scarce resourcesbetween education and training. By edu-

cation we mean increasing staff aware-ness of the overall software engineeringcontext within which they are carrying outtheir work; by training we mean impartinga specific skill. Historically, the Logica cul-ture has been one in which staff are con-tinually acquiring new knowledge as partof their work. There is no automaticexpectation that a training course isneeded whenever any new skill or know-ledge is needed. We therefore decidedthat our priority should be on education.

At the same time there is also a need fortraining as such, particularly where thecompany as a whole needs to increase itsstock of skill or knowledge in a relativelycomplex new area. Ada is likely to be agood example over the next year or two.After several experiments we concludedthat there was a need for four types ofeducation and training:

• Technology awareness' courses:This range of courses aims to cover thewhole of the software development pro-cess for all types of systems. There arefour courses, entitled:

• 'Managing system development"• 'System specification and design"• 'Validation, verification and testing'• 'Structured programming tech-

niques'.Each of these courses aims to provide anintegrated view of its subject, drawingtogether both traditional approaches andmore recent developments. The syllabusfor these courses is shown in Fig. 3.• Training courses: These will typicallybe longer courses (one or two weeks)aimed at imparting detailed knowledgeand skills in a given method or other topic.There is a need for a wider range of such

courses, and often the need for themdepends on particular project require-ments. They may also be in an area wherewe are short of in-house skills. We havetherefore tended to rely to a greater extenton external suppliers for such courses. Insome cases individuals have attendedexternal courses; in others we have askedan external supplier to organise a coursespecially for Logica. One notable excep-tion is SSADM, where we have our ownfive-day in-house course, which has nowbeen delivered on a number of occasions.

• Seminars: The courses describedabove are courses in the usual sense ofthe term, with experienced staff impartinginformation to less experienced staff. Wealso felt there was a need to organiseevents where experience in particularareas could be shared by senior staff with-out it being surrounded by all of the intro-ductory material which forms part of theTechnology awareness' courses. Wehave therefore organised a number ofone-day seminars on topics such as'Fourth-generation tools in Logica', 'Soft-ware methods in Logica', and 'Develop-ment environments in Logica'. Each ofthese consists of a series of presentationsby project staff from different parts of thecompany on their experiences. Theexpectation is that each of these eventswill be repeated (updated on eachoccasion) at approximately annualintervals.

• A training centre: For some of thetools which we are promoting, we decidedthat the best approach was to allow staff togain hands-on experience. To this end weset up a training centre where staff canuse self-tuition material to gain experi-ence of tools at their own speed. Themajority of the tools in the training centreare those where ease of use is an import-ant selling point. The emphasis is there-fore on tools for project planning, analysisand design which run on single-userworkstations. The training centre is nowheavily used, however, and in the future Isee it expanding to include more sophisti-cated hardware and software.

A by-product of the training centre isthat spare time on the workstations isrented to projects. In practice, this hasalso served to promote the use of bettertools, since it allows projects to adopt atool at short notice; this is particularly use-ful in the preparation of proposals, wherean outline design and plan often have tobe produced extremely quickly.

3.3 Promotion and support

The main way in which we go aboutgetting new technology into use hasmuch in common with a sales and mar-keting operation. There is no central com-pulsion to use SESAME's services andrecommendations. Operating units and

216 Software Engineering Journal November 1986

projects will only use our services if theyare convinced of the benefits (this con-trasts with the company quality systemand standards which apply to all of ourwork, and are mandatory).

Our promotion activities have beenaimed at ensuring everyone is aware ofwhat we are doing, of the tools andmethods available, and of the benefitswhich they bring. In order to achieve aswide a coverage as possible, we use sev-eral approaches, and aim at all levels ofthe organisation. The approachesinclude:

• the reports described above, whichare widely distributed• a newsletter published every fewmonths and distributed to all staff,worldwide• an annual 'open day' (actually twodays this year) at which we demonstrate awide range of tools (this is effectively anin-house tools fair)• the seminars described above• regular presentations to managementconferences, divisional meetings etc.• an information pack given to newemployees.

We aim to influence all levels of the com-pany directly, rather than working solelythrough the management chain.

Having created awareness in this way,we need to help staff to apply the newtechnology. The reports and educationactivities create the basic climate andinformation, but many situations arisewhere specific advice and assistance areneeded to help staff apply tools andmethods on projects. We are thereforealways available to answer questions ofthis kind, and are increasingly spendingextended periods of time with such pro-jects, helping them to plan their develop-ment strategy. Over the next year or two,we plan to build a team of staff who canspend a significant part of their time onsuch activities.

3.4 Quality standards

Inevitably, as new tools and methodshave begun to be applied, difficulties havearisen in attempting to reconcile thesenew practices with our existing standardsand quality system. Logica, in commonwith a number of other companies, has itsquality system regularly audited by the GKMinistry of Defence and the British Stan-dards Institute. If the procedures and con-trols which we are using do not conformto those described in the agreed stan-dards, we may lose the approval to docertain types of work.

In a more general context, it is clearlyessential for the orderly running of a com-pany such as Logica to operate to adefined set of procedures. Departing from

File/Print Edit

st

7

if

s

| LINE1 PRINTER

1t LETTERf; QUALITYL< PRINTERs

•*

PC

— ^

I £1 UMUU1UI.UI"

.ayout Diagram Search

s LOCflL COMPUTER

S.

PC

^ T" *

NETWORKSERVER

PC

1

—

mm

o

L

Q | fir

D

O{ai

j

rows

*

GC

n> <j

0

o)

Q Q

i

11 Finite State

RLEINITIALISATION

3

c

^ ^ ^ ^

C

PACE . ^

N3=E ^ \

I .

M

PARSER

RLE ACCESSERROR

ABORT

LEf&ED

NOSTATEMENTS,OR COVMENT

Machine

COMPILATIONRNSHED

ENDCFINPUT RLE

ClOSERLE

ANYOTHER ^ ^ - ^ C f B JCHARACTER^ \ OOwMENT

SAVE FOR COVMENT DONOTHNG• PARSER DEUMfTER \

mMTTHNR "~ ^ JtCFENCOVMENT

W DONCmHTG

COVMENTDEUMrTER

DONOTHNG

ROLLOWNGCOVMENT

COVMENTUNE

LreESO^T^—I

ANYOTHERCHARACTEB

ANYOTHERCHARACTER

IGNORE

Fig. 5 MacCadd in use

these, even for the best of reasons, can.breed confusion.

Conflicts can occur at all levels, fromthe fundamental (for example use of adifferent project life cycle) to the trivial (forexample use of a different form). For thisreason, among others, it was decidedabout a year ago to begin re-structuringour standards. SESAME is carrying outthis work in co-operation with the QualityAssurance Department. The fundamentalproblem was that the detailed assistancewhich the existing standards provide alsoled to the difficulties described above.

We therefore decided to move towardsa two-level set of standards, consisting of:

• a small set of mandatory standardscovering the essential requirementswhich any project must satisfy ('the workmust be planned' etc.).• a larger set of optional standardscovering detailed procedures — theseprovide ways of satisfying the mandatorystandards, and are defined for an individ-ual project in a quality plan.

This structure (shown in Fig. 4) will allow

Software Engineering Journal November 1986 217

us to generate as many different optionalstandards as we choose (provided thatthey satisfy the mandatory standards).Thus we can have optional standardsbased on different life cycles, differentmethods, and so on.

The development of the optional stan-dards will continue indefinitely. However,the basic framework of mandatory stan-dards is now approaching completion.Once it is in force, it will provide a muchmore satisfactory context within which tointroduce new technologies.

3.5 Data collection

It has been clear from the start of theproject that we should be as quantitativeas possible in our approach and that, inorder to do so, we needed to collect data,particularly on productivity. Tell everyoneto collect data and send it to you' was thefrequent cry.

However, we were concerned not tocreate a rule which would be largelyignored (because of its cost), and that thedata we acquired should be of highquality. Effort statistics were no problem— we know how much effort we put intoeach project. Code was more difficult. It iseasy to guess the amount of code in asystem. It is also easy to be a factor of twoout — if the results are used to estimatefuture work, this can be expensive.

Eventually, therefore, we initiated a pro-gramme in which we help selected pro-jects to count the amount of code whichthey have delivered (by system compo-nent). As part of this programme, we pro-duced a set of code-counting programs,which serve two purposes:

• they fix the definition of a line of code(or DSI in Cocomo parlance) for a givenlanguage• they mechanise the counting process.

By these means, we now have data onnearly 20 major projects, and the infor-mation is continually growing.

3.6 Tool development

SESAME was not initiated primarily todevelop tools. Indeed, we had a fairlyexplicit brief that our main task was toimprove software development effective-ness by applying existing technology,rather than embarking on a longer-termresearch and development programme.However, there have been two particularsituations where, on the one hand, wecould see a desperate need for a goodtool, and on the other hand we believedthat the technology was available to pro-duce that tool cost-effectively:

• MacCadd (Macintosh Computer-Aidcd Definition and Design) aims to

give considerably more assistance (andtherefore better cost effectiveness) in pro-ducing and maintaining software dia-grams than is provided by a simplediagram editor (for example MacDraw). Itwas our perception that the tedium ofdrawing and maintaining neat diagramswas one of the main barriers to the use ofmany of the methods we were promoting,and that we would only overcome this witha cheap tool such as MacCadd. We there-fore developed one (see Fig. 5).

The MacCadd family comprises a gen-eral diagram editor (termed the 'sketch-pad') and four tools which supportspecific diagram types: data flow dia-grams, structure diagrams, MascotActivity-Channel-Pool (ACP) diagrams,and state transition diagrams. The sketch-pad has a range of 28 different symbols,any of which can be incorporated into anetwork diagram. They may be con-nected together using a wide variety ofarrow types. This version assigns nomeaning to the particular symbol shapes,and you are free to use them in any wayyou like.

In the diagram-specific tools, MacCaddknows the rules governing the diagramtypes, and will only allow diagrams to becreated in accordance with those rules.The data flow diagram tool, for example,has four symbols (process, datastore,external and side) and only allows you todraw legal flows between these.• SyCo is an implementation ofCocomo based on Symphony. When webegan developing SyCo, there was, sur-prisingly, no support tool for Cocomo thatwas commercially available in the UK. Webelieved that the spreadsheet idiom wasideally suited to this purpose, and therehad in fact been one or two do-it-yourselfspreadsheet implementations of Cocomoaround the company for some time. How-ever, we also believed that a simplespreadsheet implementation was tooerror prone (for the user) for us to pro-mote it confidently for general use.

Symphony allowed us to set up form-based data entry on top of the basicspreadsheet model, thereby allowing usto combine the desired user interface(based on forms and suitable data vali-dation) with the desired underlyingspreadsheet model, resulting in a low-cost user-friendly implementation ofCocomo.

4 The technology

4.1 Life cycles

For some years, the Logica standardshave defined a system development pro-ject life cycle. This life cycle follows theusual sequence of project initiation, defi-nition, design, coding, testing, and so on.Inevitably, some of the approaches pro-moted by SESAME have not slotted easily

into this framework. Prototyping, develop-ment using fourth-generation tools,methods such as JSD, and so on all causethe basic conventional life cycle to becalled into question.

This issue is being addressed in ourwork on a new set of standards (see Sec-tion 3.4). Meanwhile, we are promoting aview of the life cycle which retains thebasic concepts of the conventionalapproach but which allows far more flexi-bility within it. For example, it is nowacknowledged that system developmentsmay need to iterate one or more timesover some of the activities, and that over-lap between activities (for example defi-nition, design and coding) is perfectlyacceptable provided it occurs in a control-led way. The basic framework for systemdevelopment projects is shown in Fig. 6.

4.2 Analysis and design

Analysis and design are probably theareas where 'software engineering' as it ispopularly understood has made greatestprogress into the everyday life of the soft-ware developer. Before describing theapproach we have adopted it is worthcommenting on two underlying issues:

• the relationship between tools andmethods• the relationship between specificationand analysis.

Methods and tools:

Tools and methods for analysis anddesign are beginning to interact in aninteresting way. Gntil recently, methodshad little tool support, and it was valid toput almost all the emphasis on themethods. Conversely, this lack of toolsupport had almost certainly constrainedthe use and development of methods.Now that good tools are beginning toappear it almost seems as if, in relativelywell established areas, many of the futuredevelopments will be in additional toolfacilities, which will in effect define themethod.

Before proceeding further, I shouldprobably acknowledge that, in commonwith the rest of the software community,we often say methodology when we meanmethod and method when we mean no-tation. Indeed these habits are reinforcedby some of our clients who will not take usseriv usly unless we talk about rneth-odok es. I will avoid offending sen-sibiliti. by sticking to methods, but I amafraid I nay actually say methods when allI really mean is notations.

Analysis and specification:

The relationship between 'analysis' and'specification' is becoming an important

218 Software Engineering Journal November 1986

This diagram shows inter-relationships between activities and outputs

Note that this does not represent an actual project plan —in practice activitieswill overlap and iteration may be necessary

procurementspecifications

maintenancedocumentationstatement of

requirements

KEY:

activity

output produced during activity

—depe'-:dencyAoutput f r o m a c t : v ! t v )

co Fig. 6 Basic system development project framework

one as we increasingly use 'analysismethods' within the context of fixed-pricedevelopment contracts. The traditionalview of a specification has been that itspecifies the inputs and outputs and therelationship between them (as well as allsorts of other things like performance,security, and so on). In principle, there wasthen a well defined specification of whatwe had to supply. The disadvantage, ofcourse, was that no-one (except for asmall band of very competent, methodi-cal analysts) really had any way of check-ing it for internal consistency, consistencywith the rest of the world, and so on.

Methods have arisen to address thisproblem. However, they often ignore orpay only lip service to all the topics typi-cally covered by a functional specificationor requirements specification. The speci-fications' which they generate, particularlyin inexperienced hands, are certainly valu-able but are models of some aspects ofthe system (and also of the real world, ifyou are lucky), rather than specificationsin the traditional sense. This is an issuewhich has emerged during the practicaluse of methods, and on which we need todo more work.

The methods we use:

We tend to see things in terms of ahierarchy of methods. At the bottom levelthere are a number of basic methods (ornotations) such as data flow diagrams,entity relationship diagrams, state tran-sition diagrams, program design lan-guages, and so on, which can be relativelyeasily adopted by a project without thisrequiring too fundamental a re-appraisalof the way in which they are carrying outthe project. Each of these comes in vari-ous flavours, with different-shaped boxesetc., but basically there is a fairly smallnumber of commonly used ways of look-ing at a system from different viewpoints.

At the top level, there are a number ofmethods which aim to do more than this.They usually aim to integrate a number ofsuch basic methods, probably with someunderlying data dictionary, and todescribe the processes which need to becarried out in order to execute a projectusing these basic methods or notations.Elxamples are SSADM (structured sys-tems analysis and design method,adopted by the CCTA) and JSD (Jacksonsystem development). Some of these,such as JSD, go somewhat further anddepart more fundamentally from the tra-ditional approach to carrying out projects.

For a number of reasons, we have notattempted to standardise company-wideon one of the relatively all embracingmethods. SSADM could be a candidatefor example given its CCTA backing. How-ever, it would offer little help and somedistraction to use SSADM on, forexample, a real-time system with no

database component. Moreover, SSADMis completely unknown in some of ouroverseas markets.

Furthermore, integrating somemethods with our own existing projectand documentation procedures is non-trivial — we need to avoid destroying theframes of reference which our staff cur-rently have for carrying out projects. Amore flexible evolutionary approach hastherefore been adopted. First, we activelyencourage all our staff to use the basicmethods wherever they are applicable. Inparticular, these include:

• all the components of structured anal-ysis and structured design, as proposedby de Marco, Gane and Sarson, Yourdonet al. — at this stage we have notattempted to push staff towards any ofthese in particular, but the time for someattempt at standardisation is probablyapproaching• finite-state machines or state tran-sition diagrams — we believe that thisapproach is a valuable aid to clear think-ing in the definition and design of systemsat all levels, and deserves to be used muchmore widely than it has been.

To encourage the use of such methodswe have also developed our own tools(MacCadd — see Section 3.6 above) toovercome the resistance to drawing andmaintaining large quantities of diagrams.

Secondly, there is beginning to bemuch more interest in the more allembracing methods. Having becomeconvinced of the benefits of the basicmethods, staff are now wanting to applythem as an integrated package. At thesame time there is often client pressure tobe seen to use some such overall method.Over the next two years, I can see the twopressures coming together (alqng withthe availability of better tools) to bringabout a major increase in the use of suchmethods.

So far, SSADM has been the mostwidely used method of this kind. Becauseit integrates the most widely used basicmethods for database-oriented systemsinto a relatively traditional life cycle, it caneasily be appreciated by most staff. Ibelieve that it will probably continue to bethe front runner for some time. There is,however, an increasing desire to have acomparable method for real-time sys-tems. I can see two contenders emerging:

• Mascot 3, which has now beenlaunched by the (JK Ministry of Defence, isa major advance over earlier versions ofMascot.• The approach to analysis and designfor real-time systems now being taught inYourdon courses (and presented in a setof books) integrates 'traditional' struc-tured analysis and design with a state tran-sition view of the system.

There is also interest in JSD for all kinds ofsystems, owing in particular to theemphasis which it places on modellingthe real world within which the system is tooperate.

4.3 Development environments

For practical purposes, developmentenvironments currently fall into two cate-gories. On the one hand, there are thespecial-purpose support environments,such as, in very different fields, Perspec-tive and Maestro. On the other hand thereare the more general-purpose operatingsystems such as VAX/VMS on which a col-lection of tools can be assembled for agiven project or group of projects.

In practice, most of our work is carriedout on the second type of developmentsystem, although there are signs that thescene is changing. Because of this, thedevelopment environment used normallydepends very much on what is availablefor the equipment concerned (althoughincreasingly that equipment is chosen,partly at least, on the basis of the develop-ment environment available). We havetherefore produced our recommend-ations in a number of forms:

• We have produced recommendationsfor the sets of tools which should be usedon those environments which we usemost frequently. At present these rec-ommendations cover VAX/VMS, Tandem,and GN1X. Future work is likely to extendthis list to cover IBM mainframes andStratus systems. These reports coverareas such as project databases, config-uration control, and so on, as well as anytools specific to that environment whichneed to be highlighted.• We have produced reports on specificcategories of tool which are often rela-tively independent of the developmentenvironment. One example is Testingtools', where we evaluate and recommendstatic analysers, dynamic analysers andtest harnesses.• We also provide information on par-ticular environments such as Maestro,Perspective, Ada development environ-ments and microprocessor developmentsystems such as Lands, to allow informeddecisions to be taken in situations wheresuch systems are appropriate.

4.4 Fourth-generation tools

Although we have used a wide range ofsuch tools, in different situations, this is anarea in which we have found it more diffi-cult to produce definitive recommend-ations. On the one hand, in the rightsituation, major benefits are clearly avail-able from the use of fourth-generationtools. On the other hand, many of themhave very different characteristics; in this

220 Software Engineering Journal November 1986

area more than most others, it is essentialto evaluate the potential candidatesagainst the requirement. In the case of amismatch, the net effect can certainly benegative; in the case of a good match, theeffects can be very positive.

4.5 Project planning andestimating

In contrast to the situation described inSection 4.4 above, planning and estimat-ing are probably the areas where we havebeen most able to produce definitive rec-ommendations. This is probably not sur-prising, since they are the areas whichdepend least on the application and thetechnology of the particular project.

For project planning and control ofsmall to medium projects, Project Man-ager Workbench (PMW) is beginning tobe widely used, and is coming close tobeing a de facto standard. For large pro-jects, more powerful tools are needed,and this is an area where work is beingcarried out at present. The decision is byno means clear-cut. Although tools suchas Artemis-PC and Kernel provide morepowerful and flexible facilities than PMW,the fact that they are considerably moreexpensive both in terms of hardware andsoftware is not the only disadvantage.Because of their greater power, the initialeffort involved in learning how to usethem and in setting up the project plan isalso somewhat greater.

For estimating, Cocomo is widely used,although there are also pockets of enthu-siasm for other models. As describedabove, we have produced our own imple-mentation of Cocomo (SyCo), and thesigns are that this will provide the boostneeded to make use of Cocomo into acompletely routine operation. As onemight expect, Cocomo has been foundmore directly applicable in projects usinga conventional high-level language andfollowing a fairly traditional life cycle thanit has in projects using fourth-generationlanguages, and in product development

where a large part of the job is interfacingwith existing code.

5 Lessons learned

Some of the lessons we have learned arementioned in other parts of the paper.Collected together below are the mes-sages which are important for anyone elseembarking on a similar initiative:

• No large software development oper-ation can be changed overnight— plan-ning cycles are often longer than onerealises:

• educating and training large quan-tities of staff in a large busy organisationwill take a long time — usually measuredin years rather than months

• procuring and installing hardwareneeded to support new tools will alsooften take years rather than months for alarge organisation

• large projects cannot changecourse in mid-stream — many newapproaches need to wait for new projectsbefore they can be applied.• There is a need to sell new ideas at alllevels of the organisation — commitmentis needed from all staff and all levels in themanagement hierarchy. One uncommit-ted manager can block progress in thewhole area for which he is responsible,despite any amount of enthusiasm aboveand below him.• New tools and methods generatestrong views in the software world, bothfor and against. Most of these views arebased on a narrow view of the world andon limited experience. We have encoun-tered enough projects in which significantgains have been experienced to be con-vinced that new approaches do provideopportunities for much improved effec-tiveness. We have also seen enoughcounter-examples to warn us againstusing any approach in a situation forwhich it is inappropriate.

• Project staff almost always need helpin applying new approaches in the contextof existing standards and procedures.Even where there is no conflict, the exactcorrespondence between similar con-cepts in different approaches needs to bedefined in an unambiguous way.• While a central initiative is essential toavoid duplication of effort and to provideco-ordination, it does not necessarilyimply complete standardisation acrossthe whole organisation. A centralco-ordinating group can take a company-wide view to establish where there is:

D scope for standardisation arisingfrom common requirements

D a need for standardisation to saveresources, or to aid transfer of infor-mation etc.,or alternatively:

D no real need or benefit fromstandardisation.In the latter case individual departmentsshould have as much freedom as possiblein planning their own future.• Highly motivated staff are much moreproductive. If staff feel that the organis-ation is helping them to fulfil their poten-tial, they will be motivated. If they feelsubmerged by bureaucracy, they will bedemotivated. The emphasis should there-fore be on giving staff the tools theybelieve they need in order to do their jobwell. Education can of course developtheir views on this subject.

6 Acknowledgments

SESAME could not have succeeded with-out the support of many of Logica'sdirectors, managers, and staff, or withoutthe contributions of the staff of SESAMEitself. In the latter category, David Bowers,John Jones and Martyn Ould made par-ticularly significant contributions to thefirst three years. This paper, however,contains my own personal views ratherthan those of Logica as a whole.

K. Southwell is Director of Operations with Logica Cambridge Limited. 64 Newman Street,London W1A 4SE, England.

Software Engineering Journal November 1986 221