PROCONCEPT: an evolutionary A. Howard...PROCONCEPT: an evolutionary prototyping methodology for managing systems development A. Howard Faculty of Information and Engineering Systems,

PROCONCEPT: an evolutionary

prototyping methodology for managing

systems development

A. Howard

Faculty of Information and Engineering Systems,

Leeds Metropolitan University, Leeds, LS6 3QS,

UK

ABSTRACT

In spite of its well-documented advantages overother systems development approaches,prototyping is still viewed in many commercialorganisations as an unsuitable approach forlarge-scale systems development. Many managersprefer to stick to traditional lifecycle projectphases with a detailed user requirementsdocument as the starting point for thedevelopment effort. Prototyping is seen as anunstructured exercise which is difficult to planand control. In order for the approach to gainwider acceptance the discipline of a methodologyis required. Methodologies provide frameworksfor the management of projects and enhance thequality of both the system development processand the software products produced. This paperdiscusses the background to, rationale for,phases, tasks and deliverables from a proposedevolutionary prototyping methodology.

INTRODUCTION

Prototyping is an approach to system developmentwhich attempts to demonstrate how a system orcomponent of a computer-based system willfunction in its environment. Users find suchdemonstrations extremely helpful in visualisingwhat proposed systems will do for them.Developers find them helpful in establishing thefeasibility of construction of a system orsystem component. Several authors (e.g Jenkins[1], Gomaa [2], Iggulden [3], Rowen [4]) referto the difficulties experienced by users invisualising on the basis of a system

Transactions on Information and Communications Technologies vol 9, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517

90 Software Quality Management

specification document what systems will do forthem. Jenkins takes this further by assertingthat one explicit assumption of the prototypingapproach is that people can tell you what theydon't like about an existing system more easilythan they can tell you what they think theywould like in an imaginary one. This assertionhas been well-corrobated by failures in thetraditional SDLC. Not knowing what can be done,and how easily or otherwise, leaves users at adisadvantage when attempting to describe whattheir system should do.

Prototyping restores users to a position ofinfluence where they have greater involvement insystem development. It has been used in threedifferent areas:-

1 . To assist in understanding,communicating and specifying userrequirements

2. To verify the feasibility of systemdesign

3. As an iterative tool in systemdevelopment where the prototypegradually evolves into the finalproduct.

Prototyping is strong in areas where othermethodologies are weak. It supports the end-user as well as the development professional.West [5] identifies five key factors whichhighlight the advantages of the prototypingapproach. The factors are collaboration,communication, conceptualisation, change andconsensus. Collaboration in order to forge apartnership between users and developers whichfocuses on producing quality, useful systems andavoids antagonism and contractual arguments.Communication so that developers and usersunderstand each others problems and speak thesame language. Conceptualisation to help usersand developers agree conceptual models of therequired system(s). Change is frequently seenas something to be avoided in systemdevelopment. In reality it is an inevitableconsequence of turbulent business and real-worldenvironments and has to be embraced into systemsdevelopment philosophy. Consensus in systemdevelopment has usually been based onspecification documents and has frequently beenreached to neither developers nor users ultimate


Building Quality into Software 91

satisfaction. Appleton [6] points out thatprototyping incorporates the process ofdiscovery into systems development. It assumesthat the pre-specification of exact requirementsis not always possible as they are increasinglydynamic and a certain amount of trial and erroris required to get things right.

In spite of the advantages of prototypingover the sequential development process itsusage has been restricted by a number offactors. These include:

1. Sceptism about the approach

2. Problems over the systemspecification document and itsrole in the prototyping process

3. The lack of a suitableprototyping methodology andsupporting tools

4. The difficulty in managing adynamic and flexible systemdevelopment approach

5. The lack of commitment toprototyping by seniordevelopment staff

6. Difficulties in integratingprototyping into existing systemdevelopment methodologies

It is felt that most of these objections canbe overcome by the development of a coherentprototyping development methodology. Themethodology needs to be teachable, manageable,acceptable to project sponsors, users anddevelopers, and provide a framework for theselection and development of support tools.

SCOPE OF PROTOTYPING

A number of reasons have been put forward forthe development of prototypes. The mostfrequent arguments used refer to:-

* Evaluating the feasibility of proposedsystems

* Identifying and verifying userrequirements



* Improving the understanding of userissues

* Evaluating the performancecharacteristics of technical issues

* Encouraging management and usersupport by demonstration of aprototype and its capabilities

Blum [7] discusses five areas in whichprototypes can be used to gain experience forsystem developers. The areas are userinteraction, systems flow, data models,algorithms and user involvement. Blum pointsout that users often have a poor understandingof how a process is performed for them by thecomputer-based system they are using. Prototypescan serve as a vehicle for defining andvalidating the algorithms they rely on. Datamodels can be prototyped to check forcompleteness, access paths and current andfuture information reguirements. Userinteraction and involvement act as catalysts forthe developer to discover the real needs of thesystem and to ensure enthusiastic useracceptance of the outcomes. Comprehensiveunderstanding of systems flow enables theidentification of principal events, unexpectedevents and likely bottlenecks in systemsutilisation. Each flow can be tested forrobustness and unexpected outcomes.

Crinnion [8] identifies five types ofprototype each with different levels offunctionality. For each type of prototype anumber of iterations and versions are requiredin the system development process. The firsttype of prototype is an initial prototypeconcentrating on the HCI and basicfunctionality. The second is a completenessprototype which includes the results ofadditional analysis to ensure that all userrequirements have been identified. A controlsprototype then follows which includes designdecisions resulting from a controls audit.Fourthly there is a combination prototype whichlinks several separate prototype models, andfinally a performance prototype optimised togive the best operational performance.

The scope of prototyping has also beendiscussed from a number of perspectives notdirectly connected with prototype construction



but important nevertheless in terms of anoverall appreciation of the possibilities forthe approach. Earl [9] argues that part of aninformation systems department's budget shouldbe allocated for prototyping ideas from anorganisation's staff. The best applicationsideas may not come from centralised strategicplanning but from experimentation. Mason [10]suggests that prototyping could be used forestablishing the future computing environmentfor an organisation. Using scenario-basedprototyping the most appropriate corporate-wideIT environment could be modelled. Tillman [11]argues that although prototyping is userfocused, some users are not able to pinpoint theunderlying principles of a system or to see itin a wider context than their own narrow view.The solution in his view is to have managementcommunicate their overall vision of the system.Without this vision we may make the samemistakes in prototyping as are made in othermethods. These mistakes include automatingmanual processes which are fundamentally poorlydesigned for automation, customising processeswithout consistency, and perpetuating currentorganisational structures. Sobol and Kagan [12]published some research into which systemdevelopers are most likely to prototype. Notsurprisingly perhaps they found that youngerdevelopment staff are more likely to prototype.They also found a correlation betweensupervisory responsibilities and use of theapproach. Staff with less managementresponsibility were more likely to prototype,possibly pointing to a recognition of thedifficulties in managing the approach.Prototypers were also found to be much moreuser-oriented, reinforcing the essential userinvolvement aspect of the approach.

PROBLEM CONTEXTS FOR PROTOTYPING

Most system developers accept that there is nosingle development approach or methodology thatis applicable in every project situation. Eachproject has its own characteristics which renderit suitable or unsuitable for one or otherdevelopment method. Different methods emphasisedifferent aspects or phases of the developmentprocess. Structured methodologies such as SSADMconcentrate on producing highly visible,meticulously documented system requirementspecifications. Strategy-oriented methodologiessuch as Information Engineering concentrate on



justifying and prioritising information systemdevelopments in terms of an organisation'scritical success factors and business plans.Software development methodologies focus on thedesign and construction of the softwarecomponents of systems. Matching the developmentapproach and methodology to the appropriateproblem situation is an important issue forsystem developers.

The guestion arises as to which types ofproject or problem situation is prototypingapplicable to. Two of the main factors inmaking this decision are system complexity anduser participation. Simple systems arecategorised by a relatively small number ofcomponents, stability of function and well-defined behaviour and structure. Complexsystems contain large numbers of components, aredynamic and their behaviour and structure aredifficult to analyse. User participation can becategorised as either unitary, pluralistic orcoercive. Unitary users agree on ends and meansand act in accordance with agreed objectives.Pluralistic user groups do not necessarily agreeupon ends and means. Cohersive user groupsdefinitely do not agree on ends and means andmay not be willing to compromise. Theparticular strengths of prototyping would appearto point towards its main usage in complex-unitary, simple-pluralistic and complex-pluralistic problem contexts. For furtherdiscussion of this and other methodologycategorisation and selection approaches refer toAvison and Fitzgerald [13], Olle [14], Flood andJackson [15], Howard [16] and McGinnes [17].

MANAGING THE PROTOTYPING PROCESS

System developers are continually presented withnew methods, technigues and tools which promiseto improve their productivity and increase theeffectiveness of the systems developed. Unlessthe usage and application of these new ideas iswell-managed, however, what may result is chaosand substantially worse maintenance problems inthe future. Prototyping is no exception to thisrule. Evolutionary prototyping in particularcan only take place in a strictly managedproject environment. The flexibility inrequirements determination and systemimplementation provided by prototyping presentsproject managers with the very difficultchallenge of how to plan, organise and control



a dynamic development environment. It is mucheasier to work with a detailed, up-frontrequirements specification and to adhere tospecific lifecycle stages. The justification forthe increased management effort is that thesystems produced will be more relevant toorganisational requirements, will require lessadaptive maintenance and will have committedusers who feel a greater sense of ownership oftheir systems.

The methodology used is a key issue in themanagement of a project. It identifies tasks,resources required and milestones in a project.A good methodology is capable of being appliedsuccessfully to higher level and more complexproblems as the learning curve develops. Anapproach that can be extended and generalisedhas greater power than one that is restricted toparticular domains. Once a methodology isestablished tools to support and manage theprocess can be selected or developed. Ifprototyping is to become a major force in systemdevelopment a methodology is required which hasthe support of managers, users, project sponsorsand developers. PROCONCEPT is proposed as sucha methodology.

RATIONALE BEHIND THE PROCONCEPT METHODOLOGY

Within the engineering profession, prototypesare used to demonstrate the feasibility ofdesign concepts and to modify these conceptswhere necessary and beneficial so that theinitial concept or a variant of it can berealised in a production model. Iggulden [3]points out that the general notion of prototypesis closely related to the concept of modellingand that models have three different uses:-

1. Simulation, where parts of the realworld are abstracted and modelled

2. Realisation (or feasibility) with themodel showing that the underlyingideas are consistent

3. Idealisation, a standard or idealagainst which other forms of the basicidea can be measured

A concept prototype fits in well with theidea of a simulation model. Realisation equatesto an engineering prototype. The idea of a



standard or ideal model against which otherconcepts or working prototypes can be comparedis applicable to concept, engineering andproduction prototypes.

Models can be text-based, diagrammatic,physical, mathematical or philosophical.Prototyping should make use of whichever type ofmodel is most appropriate in the circumstances.Most developers usually make the assumption thata prototype is a partially complete workingphysical model of an internal or externalcomponent of a system. Mason [10] questionswhether a prototype actually needs physicalembodiment in the early stages of development.To concentrate entirely on physical modelsdenies the prototyper access to a wide varietyof other models which could be just as effectivein the development process.

Heisler et alia [18] point out that userrequirements documents concentrate on theplanned activities of a system such as datainput, core processing and reporting. Unplannedor failure mode activities are added later bythe system developers to cater for non-functional requirements. Whilst therequirements document focuses on the functionalrequirements of the system, often the realcomplexity of system development relates to thenon-functional activities. This observationsupports a multi-phase prototyping approach.The concept prototype can concentrate on thecentral logical requirements of the system. Atthe engineering prototype stage non-functionalsystem components can be identified andprototyped.

A phased prototyping approach has beenhinted at by several authors in the prototypingliterature (e.g Carpenter [19], Carey and Mason[20], Tillman [11] ). PROCONCEPT builds on thisidea and identifies the tasks to be performed ineach phase.

THE PROCONCEPT METHODOLOGY

PROCONCEPT is a three phase, evolutionarymethodology which can be applied to systemdevelopment projects within an establishedprototyping infrastructure. It can be appliedto either new developments or to maintenanceprojects. The methodology provides a logicalframework for the developers, telling them what



to do not how to do it. In this way it providesthe opportunity for developers to be creativeand innovative within a manageable framework.

Phase 1: Concept PrototypingThe purpose of the concept prototyping phase isto eliminate conceptual misunderstandings in theproposed system. Concept prototypingconcentrates on the fundamental purpose of thesystem not on technical detail. The conceptprototype is gradually expanded and refined asthe project participants increase theircomprehension of the proposed system. Inbuilding the concept prototype the userinterface is emphasised in order to maximiseuser feedback. Internal components will in themain be prototyped in later phases once theoverall system concept desirability andfeasibility has been established. The mainpurposes of the concept prototype can besummarised as follows:-

1. To establish the initial scenario

2. To determine what the user wants anddoesn't want from the system

3. To determine whether or not theconcept is feasible

4. To identify how the proposed systemwill integrate with existing ones

5. To assess user reaction to initialprototypes

6. To ascertain initial estimates ofeffort, cost, resources anddevelopment time

Because it is the high-level ethos of thesystem that is under investigation in conceptprototyping it is essential that userinvolvement is at a sufficiently high level thatparticipants have a proper overview ofrequirements and the authority to makedecisions. The tasks within the conceptprototyping phase and the deliverables aredescribed in table 1.



PHASE 1 CONCEPT PROTOTYPING

1. Establish preliminary concept or idea2. Set up concept prototyping team3. Develop the concept or expand the idea4. Agree the overall strategy, tools and

techniques for this phase5. Establish the components for

prototyping - which aspects of theproposed system will be prototyped inphase 1 and how

6. Initiate developer/user relationships forthis phase

7. Agree timetable for this phase8. Build initial concept prototype

components9. Exercise prototypes10. Revise and review prototypes (repeat as

necessary)11. Link prototype components as required12. Exercise overall concept prototype13. Revise and review overall concept

prototype (repeat as necessary)14. Document concept prototype model and

requirements15. Estimate and document the resources

required for the engineering prototypephase

16. Review the concept prototype and furtherdevelopment requirements with the projectsponsors

17. Obtain authorisation to proceed to thenext phase

18. Hold team review of concept prototypingphase

Deliverables

1. Brief description of system concept andobjectives

2. Concept prototype model and requirements3. Estimate of resources required for

engineering prototyping phase

Table 1 Tasks and Deliverables Within ConceptPrototyping Phase

Phase 2: Engineering PrototypingThe purpose of the engineering prototyping phaseis to determine the feasibility of constructionof all system components and to ensure that theyconform to the requirements of users. Earlyengineering prototypes should emphasise system



interfaces. Later prototype versions can dealwith internal components once the interfacerequirements have been established. Engineeringprototyping ensures that:-

1. Developers know how user requirementswill be met

2. Prototypes meet specifications

3. System components are durable fortesting

4. Engineering implications for systemcomponents are fully understood

5. Key architectural decisions are takenfor the proposed system

6. In-house testing can be performed

7. End-users have a fuller picture of thesystem

The tasks and deliverables for this phase aredescribed in table 2.

Phase 3: Production PrototypingThe purpose of the production prototyping phaseis to produce a complete working model ofrequirements which can be reproduced for as manyinstallations as required. The productionprototype becomes the initial version of thesystem. The tasks and deliverables for thisphase are described in table 3. The mainpurposes of this phase are:-

1 . To make any changes to the engineeringprototype components which arenecessary for production purposes

2. To ensure complete implementation andintegration of all system components

3. Final stress testing of the system

4. To produce required systemdocumentation

5. Controlled release of the system inthe user environment



PHASE 2 ENGINEERING PROTOTYPING

Tasks

1. Set up engineering prototyping team2. Review documentation, models and

requirements from phase 13. Agree the overall strategy, tools and

techniques for this phase4. Establish the non-functional requirements

of the system eg. audit trails, errorprocessing, maintenance requirements etc.

5. Identify all the system components forengineering prototyping

6. Initiate developer/user relationships forthis phase

7. Agree timetable for this phase8. Build engineering prototype components9. Exercise, revise and review prototypes

(repeat as necessary)10. Link prototype components as required11. Exercise overall engineering prototype12. Revise and review overall engineering

prototype (repeat as necessary)13. Document the engineering prototype14 Identify and list those features of the

engineering prototype requiring specialattention when the production prototypeis being produced

15. Estimate and document the resourcesrequired for the production prototypingphase

16. Review the engineering prototype and theproduction requirements with the projectsponsors

17. Obtain authorisation to proceed to thenext phase

18. Hold team review of engineeringprototyping phase

Deliverables

1. Description of required system structureand functional and non-functionalrequirements

2. Engineering prototype model3. List of features requiring special

attention in the production prototypingphase

4. Estimate of resources required forproduction prototyping phase

Table 2 Tasks and Deliverables WithinEngineering Prototyping Phase



PHASE 3 PRODUCTION PROTOTYPING

Tasks

1. Set up production prototyping team2. Review documentation, models and

requirements from phase 23. Agree the overall strategy, tools and

techniques for this phase4. Initiate developer/user relationships for

this phase5. Agree timetable for this phase6. Build production prototype components7. Exercise, stress test and revise

components (repeat as necessary)8. Link prototype components as required9. Exercise, stress test and revise overall

production prototype (repeat asnecessary)

10. Fully document production prototype11. Release production prototype12. Hold review of production prototyping

phase

Deliverables

1. Final working prototype (version 0) ofrequired system

2. Full system documentation(operational/user/training)

Table 3 Tasks and Deliverables Within ProductionPrototyping Phase

REACTION TO THE METHODOLOGY FROM DEVELOPERS

PROCONCEPT has generally been welcomed by thosedevelopers and project managers who have comeinto contact with it. Developers who do notcurrently utilise prototyping have requestedmore details about techniques used to prototypeand how the process is actually conducted.Developers who currently use prototyping haverequested more information about potential toolsto support the various tasks within themethodology and about prototyping strategyformulation. Many developers have beenintrigued by the proposal that a prototype doesnot necessarily need to be a physical model.More details have been requested about thefollowing aspects of the methodology.:-

* Composition of teams for each phase



* Identification of suitable componentsfor prototyping

* The construction of concept prototypes

* Stress testing of prototypes

* Costing the prototyping process

* Documentation of prototypes

* Configuration management in PROCONCEPT

* Modelling techniques other thanphysical modelling

Whilst it is intended that PROCONCEPT shouldremain a methodological framework within whichdevelopers can exhibit their own creativity itis apparent that some developers prefer settechniques for the performance of each task.There are arguments for and against theprescriptive approach. These will be consideredcarefully as further versions of the methodologyare developed.

CONCLUSION

The sequential system development process is notappropriate for many large-scale computer-basedsystem projects where requirements are complexand susceptible to change. Developers and usersmust form a partnership to develop systems thatmeet corporate and user objectives. A dynamicdevelopment approach is required which embraceschange and extensive user involvement.Evolutionary prototyping is such an approach butits adoption has been restricted by the lack ofa clear, concise, teachable and manageablemethodology by which projects can be progressed.PROCONCEPT provides an easily understandableframework which overcomes these objections. Thetwo basic risk elements in system developmentare addressed. The application risk: will thesystem satisfy user needs and performbeneficially for them, is dealt with in theconcept prototyping phase. The technical risk:can a system be built which meets user needs, isaddressed in the engineering prototyping phase.The PROCONCEPT methodology has been welcomed bydevelopers and project managers as it ensuresthat the implemented system meets userrequirements at the time of release. Systemmaintenance is aided by the detailed learning



process that has taken place between users anddevelopers during the three development phases.

REFERENCES

1 . Jenkins, A.M., *Prototyping: A Methodologyfor the Design and Development of ApplicationSystems' Discussion Paper No. 227, Division ofResearch, Graduate School of Business, IndianaUniversity, April 1983.2. Gomaa, H., * Prototypes - Keep Them or ThrowThem Away?' State of the Art Report onPrototyping Pergamon Infotech Ltd, pp. 41-53,1986.3. Iggulden, D., \Prototyping Developments'State of the Art Report on Prototyping PergamonInfotech Ltd, pp. 56-63, 1986.4. Rowen, R.B., ^Software Project ManagementUnder Incomplete and Ambiguous Specifications'IEEE Transactions on Engineering Management,Vol. 37, No. 1, pp. 10-21, 1990.5. West, M.G., *Taxonomy of Prototyping - Toolsand Methods for Database, Decision Support andTransaction Systems' State of the Art Report onPrototyping Pergamon Infotech Ltd, pp. 105-120,1986.6. Appleton, D.S., *Prototyping' ProceedingsGUIDE 57 Session No. DP-7252, November, 19837. Blum, B.I., *Application SystemsPrototyping' State of the Art Report onPrototyping Pergamon Infotech Ltd, pp. 5-14,1986.8. Crinnion, J., \The Systems Implications of4GLs Journal of Information Technology, Vol. 4,No. 2, pp. 71-80, 1989.9. Earl, M.J., \Putting It in its Place: APolemic for the Nineties' Journal of InformationTechnology, Vol. 7, pp. 100-108, 1992.10. Mason, R.E.A., \Prototyping in SoftwareEngineering - Prototyping the Future' State ofthe Art Report on Prototyping Pergamon InfotechLtd, pp. 75-88, 1986.11. Tillman, G. , "Prototyping for the RightResults' Datamation, pp. 42-46, April, 1989.12. Sobol, M.G., and Kagan, A., *Which SystemsAnalyst are More Likely to Prototype' Journal ofInformation Systems Management, Vol. 6, No. 3,pp. 36-43, 1989.13. Avison, D., Fitzgerald, G. , InformationSystems Methodologies Blackwell Scientific,1991 .14. Olle, T.W., Information SystemsMethodology, Addison-Wesley, 1991.



15. Flood, R.L., Jackson, M.C., CreativeProblem Solving: Total Systems Intervention,Wiley, 1991 .16. Howard, A.W., "Methodology Selection Grids'Computing Notebook, Sept., 1992.17. McGinnes, S., "A Framework for theComparative Evaluation of Information SystemsMethodologies pp. 43-56, Proceedings of the Confon the Theory, Use and Integrative Aspects of ISMethodologies, Edinburgh, 1993.18. Heisler, K.G., Tsai, W.T., Ramamoorthy,C.V., \ Integrating the Role of RequirementsSpecification into the Process of Prototyping',pp. 348-357, Proceedings of the 22nd AnnualConference on Systems Sciences, Hawaii, 1989.19. Carpenter, R.A., \Designing and DevelopingAdaptive Information Systems' ComputerTechnology Review, pp. 19-29, Spring/Summer,1982.20. Carey, T.T., Mason, R.E.A., \InformationSystems Prototyping: Techniques, Tools andMethodologies' pp. 177-191, Proceedings of INFORCONFERENCE, 1983.


Documents

PROCONCEPT: an evolutionary A. Howard...PROCONCEPT: an evolutionary prototyping methodology for managing systems development A. Howard Faculty of Information and Engineering Systems,