Softwareprototyping

FromWikipedia,thefreeencyclopedia

Softwareprototypingistheactivityofcreatingprototypesofsoftwareapplications,i.e.,incomplete
versionsofthesoftwareprogrambeingdeveloped.Itisanactivitythatcanoccurinsoftwaredevelopment
andiscomparabletoprototypingasknownfromotherfields,suchasmechanicalengineeringor
manufacturing.
Aprototypetypicallysimulatesonlyafewaspectsof,andmaybecompletelydifferentfrom,thefinal
product.
Prototypinghasseveralbenefits:Thesoftwaredesignerandimplementercangetvaluablefeedbackfrom
theusersearlyintheproject.Theclientandthecontractorcancompareifthesoftwaremadematchesthe
softwarespecification,accordingtowhichthesoftwareprogramisbuilt.Italsoallowsthesoftware
engineersomeinsightintotheaccuracyofinitialprojectestimatesandwhetherthedeadlinesand
milestonesproposedcanbesuccessfullymet.Thedegreeofcompletenessandthetechniquesusedinthe
prototypinghavebeenindevelopmentanddebatesinceitsproposalintheearly1970s.[6]

Contents
1 Overview
2 Outlineoftheprototypingprocess
3 Dimensionsofprototypes
3.1 HorizontalPrototype
3.2 VerticalPrototype
4 Typesofprototyping
4.1 ThrowawayPrototyping
4.2 EvolutionaryPrototyping
4.3 Incrementalprototyping
4.4 Extremeprototyping
5 Advantagesofprototyping
6 Disadvantagesofprototyping
7 Bestprojectstouseprototyping

7.1 Dynamicsystemsdevelopmentmethod
7.2 Operationalprototyping
7.3 Evolutionarysystemsdevelopment
7.4 Evolutionaryrapiddevelopment
8 Tools
8.1 Screengenerators,designtools&SoftwareFactories
8.2 Applicationdefinitionorsimulationsoftware
8.3 RequirementsEngineeringEnvironment
8.4 LYMB
8.5 Nonrelationalenvironments
8.6 PSDL
9 Notes
10 References

Overview
Theoriginalpurposeofaprototypeistoallowusersofthesoftwaretoevaluatedevelopers'proposalsfor
thedesignoftheeventualproductbyactuallytryingthemout,ratherthanhavingtointerpretandevaluate
thedesignbasedondescriptions.Prototypingcanalsobeusedbyenduserstodescribeandprove
requirementsthathavenotbeenconsidered,andthatcanbeakeyfactorinthecommercialrelationship
betweendevelopersandtheirclients.[1]Interactiondesigninparticularmakesheavyuseofprototypingwith
thatgoal.
Thisprocessisincontrastwiththe1960sand1970smonolithicdevelopmentcycleofbuildingtheentire
programfirstandthenworkingoutanyinconsistenciesbetweendesignandimplementation,whichledto
highersoftwarecostsandpoorestimatesoftimeandcost.Themonolithicapproachhasbeendubbedthe
"Slayingthe(software)Dragon"technique,sinceitassumesthatthesoftwaredesigneranddeveloperisa
singleherowhohastoslaytheentiredragonalone.Prototypingcanalsoavoidthegreatexpenseand
difficultyofchangingafinishedsoftwareproduct.
ThepracticeofprototypingisoneofthepointsFrederickP.Brooksmakesinhis1975bookTheMythical
ManMonthandhis10yearanniversaryarticleNoSilverBullet.

AnearlyexampleoflargescalesoftwareprototypingwastheimplementationofNYU'sAda/EDtranslator
fortheAdaprogramminglanguage.[2]ItwasimplementedinSETLwiththeintentofproducingan
executablesemanticmodelfortheAdalanguage,emphasizingclarityofdesignanduserinterfaceover
speedandefficiency.TheNYUAda/EDsystemwasthefirstvalidatedAdaimplementation,certifiedon
April11,1983.[3]

Outlineoftheprototypingprocess
Theprocessofprototypinginvolvesthefollowingsteps
1. Identifybasicrequirements
Determinebasicrequirementsincludingtheinputandoutputinformationdesired.Details,such
assecurity,cantypicallybeignored.
2. DevelopInitialPrototype
Theinitialprototypeisdevelopedthatincludesonlyuserinterfaces.(SeeHorizontalPrototype,
below)
3. Review
Thecustomers,includingendusers,examinetheprototypeandprovidefeedbackonadditions
orchanges.
4. ReviseandEnhancethePrototype
Usingthefeedbackboththespecificationsandtheprototypecanbeimproved.Negotiation
aboutwhatiswithinthescopeofthecontract/productmaybenecessary.Ifchangesare
introducedthenarepeatofsteps#3and#4maybeneeded.

Dimensionsofprototypes
NielsensummarizesthevariousdimensionofprototypesinhisbookUsabilityEngineering:

HorizontalPrototype
Acommontermforauserinterfaceprototypeisthehorizontalprototype.Itprovidesabroadviewofan
entiresystemorsubsystem,focusingonuserinteractionmorethanlowlevelsystemfunctionality,suchas
databaseaccess.Horizontalprototypesareusefulfor:
Confirmationofuserinterfacerequirementsandsystemscope,
Demonstrationversionofthesystemtoobtainbuyinfromthebusiness,
Developpreliminaryestimatesofdevelopmenttime,costandeffort.

VerticalPrototype

Averticalprototypeisamorecompleteelaborationofasinglesubsystemorfunction.Itisusefulfor
obtainingdetailedrequirementsforagivenfunction,withthefollowingbenefits:
Refinementdatabasedesign,
Obtaininformationondatavolumesandsysteminterfaceneeds,fornetworksizingandperformance
engineering,
Clarifycomplexrequirementsbydrillingdowntoactualsystemfunctionality.

Typesofprototyping
Softwareprototypinghasmanyvariants.However,allthemethodsareinsomewaybasedontwomajor
typesofprototyping:ThrowawayPrototypingandEvolutionaryPrototyping.

ThrowawayPrototyping
Alsocalledcloseendedprototyping.ThrowawayorRapidPrototypingreferstothecreationofamodelthat
willeventuallybediscardedratherthanbecomingpartofthefinaldeliveredsoftware.Afterpreliminary
requirementsgatheringisaccomplished,asimpleworkingmodelofthesystemisconstructedtovisually
showtheuserswhattheirrequirementsmaylooklikewhentheyareimplementedintoafinishedsystem.
RapidPrototypinginvolvedcreatingaworkingmodelofvariouspartsofthesystemataveryearly
stage,afterarelativelyshortinvestigation.Themethodusedinbuildingitisusuallyquiteinformal,
themostimportantfactorbeingthespeedwithwhichthemodelisprovided.Themodelthenbecomes
thestartingpointfromwhichuserscanreexaminetheirexpectationsandclarifytheirrequirements.
Whenthishasbeenachieved,theprototypemodelis'thrownaway',andthesystemisformally
developedbasedontheidentifiedrequirements.[7]
ThemostobviousreasonforusingThrowawayPrototypingisthatitcanbedonequickly.Iftheuserscan
getquickfeedbackontheirrequirements,theymaybeabletorefinethemearlyinthedevelopmentofthe
software.Makingchangesearlyinthedevelopmentlifecycleisextremelycosteffectivesincethereis
nothingatthatpointtoredo.Ifaprojectischangedafteraconsiderableamountofworkhasbeendonethen
smallchangescouldrequirelargeeffortstoimplementsincesoftwaresystemshavemanydependencies.
Speediscrucialinimplementingathrowawayprototype,sincewithalimitedbudgetoftimeandmoney
littlecanbeexpendedonaprototypethatwillbediscarded.
AnotherstrengthofThrowawayPrototypingisitsabilitytoconstructinterfacesthattheuserscantest.The
userinterfaceiswhattheuserseesasthesystem,andbyseeingitinfrontofthem,itismucheasiertograsp
howthesystemwillwork.
itisassertedthatrevolutionaryrapidprototypingisamoreeffectivemannerinwhichtodealwith
userrequirementsrelatedissues,andthereforeagreaterenhancementtosoftwareproductivity
overall.Requirementscanbeidentified,simulated,andtestedfarmorequicklyandcheaplywhen
issuesofevolvability,maintainability,andsoftwarestructureareignored.This,inturn,leadstothe
accuratespecificationofrequirements,andthesubsequentconstructionofavalidandusablesystem
fromtheuser'sperspectiveviaconventionalsoftwaredevelopmentmodels.[8]
Prototypescanbeclassifiedaccordingtothefidelitywithwhichtheyresembletheactualproductinterms
ofappearance,interactionandtiming.OnemethodofcreatingalowfidelityThrowawayPrototypeisPaper
Prototyping.Theprototypeisimplementedusingpaperandpencil,andthusmimicsthefunctionofthe

actualproduct,butdoesnotlookatalllikeit.AnothermethodtoeasilybuildhighfidelityThrowaway
PrototypesistouseaGUIBuilderandcreateaclickdummy,aprototypethatlookslikethegoalsystem,but
doesnotprovideanyfunctionality.
NotexactlythesameasThrowawayPrototyping,butcertainlyinthesamefamily,istheusageof
storyboards,animaticsordrawings.Thesearenonfunctionalimplementationsbutshowhowthesystem
willlook.
Summary:Inthisapproachtheprototypeisconstructedwiththeideathatitwillbediscardedandthefinal
systemwillbebuiltfromscratch.Thestepsinthisapproachare:
1. Writepreliminaryrequirements
2. Designtheprototype
3. Userexperiences/usestheprototype,specifiesnewrequirements
4. Repeatifnecessary
5. Writethefinalrequirements

EvolutionaryPrototyping
EvolutionaryPrototyping(alsoknownasbreadboardprototyping)isquitedifferentfromThrowaway
Prototyping.ThemaingoalwhenusingEvolutionaryPrototypingistobuildaveryrobustprototypeina
structuredmannerandconstantlyrefineit.ThereasonforthisisthattheEvolutionaryprototype,when
built,formstheheartofthenewsystem,andtheimprovementsandfurtherrequirementswillbebuilt.
WhendevelopingasystemusingEvolutionaryPrototyping,thesystemiscontinuallyrefinedandrebuilt.
"evolutionaryprototypingacknowledgesthatwedonotunderstandalltherequirementsandbuilds
onlythosethatarewellunderstood."[5]
Thistechniqueallowsthedevelopmentteamtoaddfeatures,ormakechangesthatcouldn'tbeconceived
duringtherequirementsanddesignphase.
Forasystemtobeuseful,itmustevolvethroughuseinitsintendedoperationalenvironment.A
productisnever"done"itisalwaysmaturingastheusageenvironmentchangesweoftentryto
defineasystemusingourmostfamiliarframeofreferencewherewearenow.Wemake
assumptionsaboutthewaybusinesswillbeconductedandthetechnologybaseonwhichthebusiness
willbeimplemented.Aplanisenactedtodevelopthecapability,and,soonerorlater,something
resemblingtheenvisionedsystemisdelivered.[9]
EvolutionaryPrototypeshaveanadvantageoverThrowawayPrototypesinthattheyarefunctionalsystems.
Althoughtheymaynothaveallthefeaturestheusershaveplanned,theymaybeusedonaninterimbasis
untilthefinalsystemisdelivered.
"Itisnotunusualwithinaprototypingenvironmentfortheusertoputaninitialprototypetopractical
usewhilewaitingforamoredevelopedversionTheusermaydecidethata'flawed'systemisbetter
thannosystematall."[7]
InEvolutionaryPrototyping,developerscanfocusthemselvestodeveloppartsofthesystemthatthey
understandinsteadofworkingondevelopingawholesystem.

Tominimizerisk,thedeveloperdoesnotimplementpoorlyunderstoodfeatures.Thepartialsystemis
senttocustomersites.Asusersworkwiththesystem,theydetectopportunitiesfornewfeaturesand
giverequestsforthesefeaturestodevelopers.Developersthentaketheseenhancementrequestsalong
withtheirownandusesoundconfigurationmanagementpracticestochangethesoftware
requirementsspecification,updatethedesign,recodeandretest.[10]

Incrementalprototyping
Thefinalproductisbuiltasseparateprototypes.Attheendtheseparateprototypesaremergedinanoverall
design.Bythehelpofincrementalprototypingwecanreducethetimegapbetweenuserandsoftware
developer.

Extremeprototyping
ExtremePrototypingasadevelopmentprocessisusedespeciallyfordevelopingwebapplications.
Basically,itbreaksdownwebdevelopmentintothreephases,eachonebasedontheprecedingone.The
firstphaseisastaticprototypethatconsistsmainlyofHTMLpages.Inthesecondphase,thescreensare
programmedandfullyfunctionalusingasimulatedserviceslayer.Inthethirdphase,theservicesare
implemented.TheprocessiscalledExtremePrototypingtodrawattentiontothesecondphaseofthe
process,whereafullyfunctionalUIisdevelopedwithverylittleregardtotheservicesotherthantheir
contract.

Advantagesofprototyping
Therearemanyadvantagestousingprototypinginsoftwaredevelopmentsometangible,some
abstract.[11]
Reducedtimeandcosts:Prototypingcanimprovethequalityofrequirementsandspecificationsprovided
todevelopers.Becausechangescostexponentiallymoretoimplementastheyaredetectedlaterin
development,theearlydeterminationofwhattheuserreallywantscanresultinfasterandlessexpensive
software.[8]
Improvedandincreaseduserinvolvement:Prototypingrequiresuserinvolvementandallowsthemtosee
andinteractwithaprototypeallowingthemtoprovidebetterandmorecompletefeedbackand
specifications.[7]Thepresenceoftheprototypebeingexaminedbytheuserpreventsmany
misunderstandingsandmiscommunicationsthatoccurwheneachsidebelievetheotherunderstandswhat
theysaid.Sinceusersknowtheproblemdomainbetterthananyoneonthedevelopmentteamdoes,
increasedinteractioncanresultinafinalproductthathasgreatertangibleandintangiblequality.Thefinal
productismorelikelytosatisfytheuser'sdesireforlook,feelandperformance.

Disadvantagesofprototyping
Using,orperhapsmisusing,prototypingcanalsohavedisadvantages.

Insufficientanalysis:Thefocusonalimitedprototypecandistractdevelopersfromproperlyanalyzingthe
completeproject.Thiscanleadtooverlookingbettersolutions,preparationofincompletespecificationsor
theconversionoflimitedprototypesintopoorlyengineeredfinalprojectsthatarehardtomaintain.Further,
sinceaprototypeislimitedinfunctionalityitmaynotscalewelliftheprototypeisusedasthebasisofa
finaldeliverable,whichmaynotbenoticedifdevelopersaretoofocusedonbuildingaprototypeasa
model.
Userconfusionofprototypeandfinishedsystem:Userscanbegintothinkthataprototype,intendedto
bethrownaway,isactuallyafinalsystemthatmerelyneedstobefinishedorpolished.(Theyare,for
example,oftenunawareoftheeffortneededtoadderrorcheckingandsecurityfeatureswhichaprototype
maynothave.)Thiscanleadthemtoexpecttheprototypetoaccuratelymodeltheperformanceofthefinal
systemwhenthisisnottheintentofthedevelopers.Userscanalsobecomeattachedtofeaturesthatwere
includedinaprototypeforconsiderationandthenremovedfromthespecificationforafinalsystem.If
usersareabletorequireallproposedfeaturesbeincludedinthefinalsystemthiscanleadtoconflict.
Developermisunderstandingofuserobjectives:Developersmayassumethatuserssharetheirobjectives
(e.g.todelivercorefunctionalityontimeandwithinbudget),withoutunderstandingwidercommercial
issues.Forexample,userrepresentativesattendingEnterprisesoftware(e.g.PeopleSoft)eventsmayhave
seendemonstrationsof"transactionauditing"(wherechangesareloggedanddisplayedinadifferencegrid
view)withoutbeingtoldthatthisfeaturedemandsadditionalcodingandoftenrequiresmorehardwareto
handleextradatabaseaccesses.Usersmightbelievetheycandemandauditingoneveryfield,whereas
developersmightthinkthisisfeaturecreepbecausetheyhavemadeassumptionsabouttheextentofuser
requirements.Ifthedeveloperhascommitteddeliverybeforetheuserrequirementswerereviewed,
developersarebetweenarockandahardplace,particularlyifusermanagementderivessomeadvantage
fromtheirfailuretoimplementrequirements.
Developerattachmenttoprototype:Developerscanalsobecomeattachedtoprototypestheyhavespenta
greatdealofeffortproducingthiscanleadtoproblemslikeattemptingtoconvertalimitedprototypeintoa
finalsystemwhenitdoesnothaveanappropriateunderlyingarchitecture.(Thismaysuggestthat
throwawayprototyping,ratherthanevolutionaryprototyping,shouldbeused.)
Excessivedevelopmenttimeoftheprototype:Akeypropertytoprototypingisthefactthatitissupposed
tobedonequickly.Ifthedeveloperslosesightofthisfact,theyverywellmaytrytodevelopaprototype
thatistoocomplex.Whentheprototypeisthrownawaythepreciselydevelopedrequirementsthatit
providesmaynotyieldasufficientincreaseinproductivitytomakeupforthetimespentdevelopingthe
prototype.Userscanbecomestuckindebatesoverdetailsoftheprototype,holdingupthedevelopment
teamanddelayingthefinalproduct.
Expenseofimplementingprototyping:thestartupcostsforbuildingadevelopmentteamfocusedon
prototypingmaybehigh.Manycompanieshavedevelopmentmethodologiesinplace,andchangingthem
canmeanretraining,retooling,orboth.Manycompaniestendtojustjumpintotheprototypingwithout
botheringtoretraintheirworkersasmuchastheyshould.
Acommonproblemwithadoptingprototypingtechnologyishighexpectationsforproductivitywith
insufficienteffortbehindthelearningcurve.Inadditiontotrainingfortheuseofaprototyping
technique,thereisanoftenoverlookedneedfordevelopingcorporateandprojectspecificunderlying
structuretosupportthetechnology.Whenthisunderlyingstructureisomitted,lowerproductivitycan
oftenresult.[13]

Bestprojectstouseprototyping
Ithasbeenarguedthatprototyping,insomeformoranother,shouldbeusedallthetime.However,
prototypingismostbeneficialinsystemsthatwillhavemanyinteractionswiththeusers.
Ithasbeenfoundthatprototypingisveryeffectiveintheanalysisanddesignofonlinesystems,
especiallyfortransactionprocessing,wheretheuseofscreendialogsismuchmoreinevidence.The
greatertheinteractionbetweenthecomputerandtheuser,thegreaterthebenefitisthatcanbe
obtainedfrombuildingaquicksystemandlettingtheuserplaywithit.[7]
Systemswithlittleuserinteraction,suchasbatchprocessingorsystemsthatmostlydocalculations,benefit
littlefromprototyping.Sometimes,thecodingneededtoperformthesystemfunctionsmaybetoointensive
andthepotentialgainsthatprototypingcouldprovidearetoosmall.[7]
Prototypingisespeciallygoodfordesigninggoodhumancomputerinterfaces."Oneofthemostproductive
usesofrapidprototypingtodatehasbeenasatoolforiterativeuserrequirementsengineeringandhuman
computerinterfacedesign."[8]

Dynamicsystemsdevelopmentmethod
DynamicSystemsDevelopmentMethod(DSDM)[18]isaframeworkfordeliveringbusinesssolutionsthat
reliesheavilyuponprototypingasacoretechnique,andisitselfISO9001approved.Itexpandsuponmost
understooddefinitionsofaprototype.AccordingtoDSDMtheprototypemaybeadiagram,abusiness
process,orevenasystemplacedintoproduction.DSDMprototypesareintendedtobeincremental,
evolvingfromsimpleformsintomorecomprehensiveones.
DSDMprototypesmaybethrowawayorevolutionary.Evolutionaryprototypesmaybeevolved
horizontally(breadththendepth)orvertically(eachsectionisbuiltindetailwithadditionaliterations
detailingsubsequentsections).Evolutionaryprototypescaneventuallyevolveintofinalsystems.
ThefourcategoriesofprototypesasrecommendedbyDSDMare:
Businessprototypesusedtodesignanddemonstratesthebusinessprocessesbeingautomated.
Usabilityprototypesusedtodefine,refine,anddemonstrateuserinterfacedesignusability,
accessibility,lookandfeel.
Performanceandcapacityprototypesusedtodefine,demonstrate,andpredicthowsystemswill
performunderpeakloadsaswellastodemonstrateandevaluateothernonfunctionalaspectsofthe
system(transactionrates,datastoragevolume,responsetime,etc.)
Capability/techniqueprototypesusedtodevelop,demonstrate,andevaluateadesignapproachor
concept.
TheDSDMlifecycleofaprototypeisto:
1. Identifyprototype
2. Agreetoaplan
3. Createtheprototype
4. Reviewtheprototype

Operationalprototyping
OperationalPrototypingwasproposedbyAlanDavisasawaytointegratethrowawayandevolutionary
prototypingwithconventionalsystemdevelopment."Itoffersthebestofboththequickanddirtyand
conventionaldevelopmentworldsinasensiblemanner.Designersdeveloponlywellunderstoodfeaturesin
buildingtheevolutionarybaseline,whileusingthrowawayprototypingtoexperimentwiththepoorly
understoodfeatures."[5]
Davis'beliefisthattotryto"retrofitqualityontoarapidprototype"isnotthecorrectapproachwhentrying
tocombinethetwoapproaches.Hisideaistoengageinanevolutionaryprototypingmethodologyand
rapidlyprototypethefeaturesofthesystemaftereachevolution.
Thespecificmethodologyfollowsthesesteps:[5]
Anevolutionaryprototypeisconstructedandmadeintoabaselineusingconventionaldevelopment
strategies,specifyingandimplementingonlytherequirementsthatarewellunderstood.
Copiesofthebaselinearesenttomultiplecustomersitesalongwithatrainedprototyper.
Ateachsite,theprototyperwatchestheuseratthesystem.
Whenevertheuserencountersaproblemorthinksofanewfeatureorrequirement,theprototyper
logsit.Thisfreestheuserfromhavingtorecordtheproblem,andallowshimtocontinueworking.
Aftertheusersessionisover,theprototyperconstructsathrowawayprototypeontopofthebaseline
system.
Theusernowusesthenewsystemandevaluates.Ifthenewchangesaren'teffective,theprototyper
removesthem.
Iftheuserlikesthechanges,theprototyperwritesfeatureenhancementrequestsandforwardsthem
tothedevelopmentteam.
Thedevelopmentteam,withthechangerequestsinhandfromallthesites,thenproduceanew
evolutionaryprototypeusingconventionalmethods.
Obviously,akeytothismethodistohavewelltrainedprototypersavailabletogototheusersites.The
OperationalPrototypingmethodologyhasmanybenefitsinsystemsthatarecomplexandhavefewknown
requirementsinadvance.

Evolutionarysystemsdevelopment
EvolutionarySystemsDevelopmentisaclassofmethodologiesthatattempttoformallyimplement
EvolutionaryPrototyping.Oneparticulartype,calledSystemscraftisdescribedbyJohnCrinnioninhis
book:EvolutionarySystemsDevelopment.
Systemscraftwasdesignedasa'prototype'methodologythatshouldbemodifiedandadaptedtofitthe
specificenvironmentinwhichitwasimplemented.
Systemscraftwasnotdesignedasarigid'cookbook'approachtothedevelopmentprocess.Itisnow
generallyrecognised[sic]thatagoodmethodologyshouldbeflexibleenoughtobeadjustabletosuit
allkindsofenvironmentandsituation[7]
ThebasisofSystemscraft,notunlikeEvolutionaryPrototyping,istocreateaworkingsystemfromthe
initialrequirementsandbuilduponitinaseriesofrevisions.Systemscraftplacesheavyemphasison
traditionalanalysisbeingusedthroughoutthedevelopmentofthesystem.

Evolutionaryrapiddevelopment
EvolutionaryRapidDevelopment(ERD)[12]wasdevelopedbytheSoftwareProductivityConsortium,a
technologydevelopmentandintegrationagentfortheInformationTechnologyOfficeoftheDefense
AdvancedResearchProjectsAgency(DARPA).
FundamentaltoERDistheconceptofcomposingsoftwaresystemsbasedonthereuseof
components,theuseofsoftwaretemplatesandonanarchitecturaltemplate.Continuousevolutionof
systemcapabilitiesinrapidresponsetochanginguserneedsandtechnologyishighlightedbythe
evolvablearchitecture,representingaclassofsolutions.Theprocessfocusesontheuseofsmall
artisanbasedteamsintegratingsoftwareandsystemsengineeringdisciplinesworkingmultiple,often
parallelshortdurationtimeboxeswithfrequentcustomerinteraction.
KeytothesuccessoftheERDbasedprojectsisparallelexploratoryanalysisanddevelopmentof
features,infrastructures,andcomponentswithandadoptionofleadingedgetechnologiesenabling
thequickreactiontochangesintechnologies,themarketplace,orcustomerrequirements.[9]
Toelicitcustomer/userinput,frequentscheduledandadhoc/impromptumeetingswiththestakeholdersare
held.Demonstrationsofsystemcapabilitiesareheldtosolicitfeedbackbeforedesign/implementation
decisionsaresolidified.Frequentreleases(e.g.,betas)aremadeavailableforusetoprovideinsightinto
howthesystemcouldbettersupportuserandcustomerneeds.Thisassuresthatthesystemevolvesto
satisfyexistinguserneeds.
Thedesignframeworkforthesystemisbasedonusingexistingpublishedordefactostandards.Thesystem
isorganizedtoallowforevolvingasetofcapabilitiesthatincludesconsiderationsforperformance,
capacities,andfunctionality.Thearchitectureisdefinedintermsofabstractinterfacesthatencapsulatethe
servicesandtheirimplementation(e.g.,COTSapplications).Thearchitectureservesasatemplatetobe
usedforguidingdevelopmentofmorethanasingleinstanceofthesystem.Itallowsformultiple
applicationcomponentstobeusedtoimplementtheservices.Acoresetoffunctionalitynotlikelyto
changeisalsoidentifiedandestablished.
TheERDprocessisstructuredtousedemonstratedfunctionalityratherthanpaperproductsasawayfor
stakeholderstocommunicatetheirneedsandexpectations.Centraltothisgoalofrapiddeliveryistheuse
ofthe"timebox"method.Timeboxesarefixedperiodsoftimeinwhichspecifictasks(e.g.,developingaset
offunctionality)mustbeperformed.Ratherthanallowingtimetoexpandtosatisfysomevaguesetof
goals,thetimeisfixed(bothintermsofcalendarweeksandpersonhours)andasetofgoalsisdefinedthat
realisticallycanbeachievedwithintheseconstraints.Tokeepdevelopmentfromdegeneratingintoa
"randomwalk,"longrangeplansaredefinedtoguidetheiterations.Theseplansprovideavisionforthe
overallsystemandsetboundaries(e.g.,constraints)fortheproject.Eachiterationwithintheprocessis
conductedinthecontextoftheselongrangeplans.
Onceanarchitectureisestablished,softwareisintegratedandtestedonadailybasis.Thisallowstheteam
toassessprogressobjectivelyandidentifypotentialproblemsquickly.Sincesmallamountsofthesystem
areintegratedatonetime,diagnosingandremovingthedefectisrapid.Userdemonstrationscanbeheldat
shortnoticesincethesystemisgenerallyreadytoexerciseatalltimes.

Tools

Efficientlyusingprototypingrequiresthatanorganizationhavepropertoolsandastafftrainedtousethose
tools.Toolsusedinprototypingcanvaryfromindividualtoolslike4thgenerationprogramminglanguages
usedforrapidprototypingtocomplexintegratedCASEtools.4thgenerationvisualprogramminglanguages
likeVisualBasicandColdFusionarefrequentlyusedsincetheyarecheap,wellknownandrelativelyeasy
andfasttouse.CASEtools,supportingrequirementsanalysis,liketheRequirementsEngineering
Environment(seebelow)areoftendevelopedorselectedbythemilitaryorlargeorganizations.Object
orientedtoolsarealsobeingdevelopedlikeLYMBfromtheGEResearchandDevelopmentCenter.Users
mayprototypeelementsofanapplicationthemselvesinaspreadsheet.
Aswebbasedapplicationscontinuetogrowinpopularity,sotoo,havethetoolsforprototypingsuch
applications.FrameworkssuchasBootstrap,Foundation,andAngularJSprovidethetoolsnecessaryto
quicklystructureaproofofconcept.Theseframeworkstypicallyconsistofasetofcontrols,interactions,
anddesignguidelinesthatenabledeveloperstoquicklyprototypewebapplications.

Screengenerators,designtools&SoftwareFactories
Alsocommonlyusedarescreengeneratingprogramsthatenableprototyperstoshowuserssystemsthat
don'tfunction,butshowwhatthescreensmaylooklike.[4]DevelopingHumanComputerInterfacescan
sometimesbethecriticalpartofthedevelopmenteffort,sincetotheuserstheinterfaceessentiallyisthe
system.
Softwarefactoriescangeneratecodebycombiningreadytousemodularcomponents.Thismakesthem
idealforprototypingapplications,sincethisapproachcanquicklydeliverprogramswiththedesired
behaviour,withaminimalamountofmanualcoding.

Applicationdefinitionorsimulationsoftware
AnewclassofsoftwarecalledalsoApplicationdefinitionorsimulationsoftwareenableuserstorapidly
buildlightweight,animatedsimulationsofanothercomputerprogram,withoutwritingcode.Application
simulationsoftwareallowsbothtechnicalandnontechnicaluserstoexperience,test,collaborateand
validatethesimulatedprogram,andprovidesreportssuchasannotations,screenshotandschematics.Asa
solutionspecificationtechnique,ApplicationSimulationfallsbetweenlowrisk,butlimited,textor
drawingbasedmockups(orwireframes)sometimescalledpaperbasedprototyping,andtimeconsuming,
highriskcodebasedprototypes,allowingsoftwareprofessionalstovalidaterequirementsanddesign
choicesearlyon,beforedevelopmentbegins.Indoingso,risksandcostsassociatedwithsoftware
implementationscanbedramaticallyreduced.[5]
Tosimulateapplicationsonecanalsousesoftwarewhichsimulaterealworldsoftwareprogramsfor
computerbasedtraining,demonstration,andcustomersupport,suchasscreencastingsoftwareasthose
areasarecloselyrelated.Therearealsomorespecialisedtools.[6][7][8]

RequirementsEngineeringEnvironment
"TheRequirementsEngineeringEnvironment(REE),underdevelopmentatRomeLaboratorysince1985,
providesanintegratedtoolsetforrapidlyrepresenting,building,andexecutingmodelsofcriticalaspectsof
complexsystems."[15]

RequirementsEngineeringEnvironmentiscurrentlyusedbytheAirForcetodevelopsystems.Itis:
anintegratedsetoftoolsthatallowssystemsanalyststorapidlybuildfunctional,userinterface,and
performanceprototypemodelsofsystemcomponents.Thesemodelingactivitiesareperformedto
gainagreaterunderstandingofcomplexsystemsandlessentheimpactthatinaccuraterequirement
specificationshaveoncostandschedulingduringthesystemdevelopmentprocess.Modelscanbe
constructedeasily,andatvaryinglevelsofabstractionorgranularity,dependingonthespecific
behavioralaspectsofthemodelbeingexercised.[15]
REEiscomposedofthreeparts.Thefirst,calledprotoisaCASEtoolspecificallydesignedtosupportrapid
prototyping.ThesecondpartiscalledtheRapidInterfacePrototypingSystemorRIP,whichisacollection
oftoolsthatfacilitatethecreationofuserinterfaces.ThethirdpartofREEisauserinterfacetoRIPand
protothatisgraphicalandintendedtobeeasytouse.
RomeLaboratory,thedeveloperofREE,intendedthattosupporttheirinternalrequirementsgathering
methodology.Theirmethodhasthreemainparts:
Elicitationfromvarioussources(users,interfacestoothersystems),specification,andconsistency
checking
Analysisthattheneedsofdiverseuserstakentogetherdonotconflictandaretechnicallyand
economicallyfeasible
Validationthatrequirementssoderivedareanaccuratereflectionofuserneeds.[15]
In1996,RomeLabscontractedSoftwareProductivitySolutions(SPS)tofurtherenhanceREEtocreate"a
commercialqualityREEthatsupportsrequirementsspecification,simulation,userinterfaceprototyping,
mappingofrequirementstohardwarearchitectures,andcodegeneration"[16]Thissystemisnamedthe
AdvancedRequirementsEngineeringWorkstationorAREW.

LYMB
LYMB[17]isanobjectorienteddevelopmentenvironmentaimedatdevelopingapplicationsthatrequire
combininggraphicsbaseduserinterfaces,visualization,andrapidprototyping.

Nonrelationalenvironments
Nonrelationaldefinitionofdata(e.g.usingCachorassociativemodels)canhelpmakeenduser
prototypingmoreproductivebydelayingoravoidingtheneedtonormalizedataateveryiterationofa
simulation.Thismayyieldearlier/greaterclarityofbusinessrequirements,thoughitdoesnotspecifically
confirmthatrequirementsaretechnicallyandeconomicallyfeasibleinthetargetproductionsystem.

PSDL
PSDLisaprototypedescriptionlanguagetodescriberealtimesoftware.[9]TheassociatedtoolsetisCAPS
(ComputerAidedPrototypingSystem).[10]Prototypingsoftwaresystemswithhardrealtimerequirements
ischallengingbecausetimingconstraintsintroduceimplementationandhardwaredependencies.PSDL
addressestheseissuesbyintroducingcontrolabstractionsthatincludedeclarativetimingconstraints.CAPS
usesthisinformationtoautomaticallygeneratecodeandassociatedrealtimeschedules,monitortiming
constraintsduringprototypeexecution,andsimulateexecutioninproportionalrealtimerelativetoasetof

parameterizedhardwaremodels.Italsoprovidesdefaultassumptionsthatenableexecutionofincomplete
prototypedescriptions,integratesprototypeconstructionwithasoftwarereuserepositoryforrapidly
realizingefficientimplementations,andprovidessupportforrapidevolutionofrequirementsand
designs.[11]

Notes
1. ^C.MelissaMcclendon,LarryRegot,GerriAkers:TheAnalysisandPrototypingofEffective
GraphicalUserInterfaces.October1996.[3](http://www.umsl.edu/~s980548/gproj1/intro.html)
2. ^D.A.Stacy,professor,UniversityofGuelph.Guelph,Ontario.LecturenotesonRapidPrototyping.
August,1997.[4](http://hebb.cis.uoguelph.ca/~dave/343/Lectures/prototype.html)
3. ^StephenJ.Andriole:InformationSystemDesignPrinciplesforthe90s:GettingitRight.AFCEA
InternationalPress,Fairfax,Virginia.1990.Page13.
4. ^R.Charette,SoftwareEngineeringRiskAnalysisandManagement.McGrawHill,NewYork,
1989.
5. ^AlanM.Davis:OperationalPrototyping:AnewDevelopmentApproach.IEEESoftware,
September1992.Page71.
6. ^ToddGrimm:TheHumanCondition:AJustificationforRapidPrototyping.TimeCompression
Technologies,vol.3no.3.AcceleratedTechnologies,Inc.May1998.Page1.[5]
(http://www.tagrimm.com/publications/arthuman1998.html)
7. ^JohnCrinnion:EvolutionarySystemsDevelopment,apracticalguidetotheuseofprototyping
withinastructuredsystemsmethodology.PlenumPress,NewYork,1991.Page18.
8. ^S.P.Overmyer:Revolutionaryvs.EvolutionaryRapidPrototyping:BalancingSoftware
ProductivityandHCIDesignConcerns.CenterofExcellenceinCommand,Control,
CommunicationsandIntelligence(C3I),GeorgeMasonUniversity,4400UniversityDrive,Fairfax,
Virginia.
9. ^SoftwareProductivityConsortium:EvolutionaryRapidDevelopment.SPCdocumentSPC97057
CMC,version01.00.04,June1997.Herndon,Va.Page6.
10. ^Davis.Page7273.Citing:E.BersoffandA.Davis,ImpactsofLifeCycleModelsofSoftware
ConfigurationManagement.Comm.ACM,Aug.1991,pp.104118
11. ^AdaptedfromC.MelissaMcclendon,LarryRegot,GerriAkers.
12. ^AdaptedfromSoftwareProductivityConsortium.PPS1013.
13. ^JosephE.Urban:SoftwarePrototypingandRequirementsEngineering.RomeLaboratory,Rome,
NY.
14. ^PaulW.Parry.RapidSoftwarePrototyping.SheffieldHallamUniversity,Sheffield,UK.[6]
(http://www.shu.ac.uk/schools/cms/rapid.software.prototyping/rapid.software.prototyping.html)
15. ^Dr.RamonAcosta,CarlaBurns,WilliamRzepka,andJamesSidoran.ApplyingRapidPrototyping
TechniquesintheRequirementsEngineeringEnvironment.IEEE,1994.[7]
(http://www.stsc.hill.af.mil/crosstalk/1994/oct/xt94d10g.html)
16. ^SoftwareProductivitySolutions,Incorporated.AdvancedRequirementsEngineeringWorkstation
(AREW).1996.[8](http://www.sps.com/company/techfocus/modeling/arew.html)
17. ^fromGEResearchandDevelopment.
http://www.crd.ge.com/esl/cgsp/fact_sheet/objorien/index.html
18. ^DynamicSystemsDevelopmentMethodConsortium.http://na.dsdm.org
19. ^AlanDix,JanetFinlay,GregoryD.Abowd,RussellBealeHumanComputerInteraction,Third
edition

References

1. SmithMFSoftwarePrototyping:Adoption,PracticeandManagement.McGrawHill,London(1991).
2. Dewar,RobertB.K.FisherJr.,GeraldA.Schonberg,EdmondFroelich,RobertBryant,StephenGoss,
ClintonF.Burke,Michael(November1980)."TheNYUAdaTranslatorandInterpreter".ACMSIGPLAN
NoticesProceedingsoftheACMSIGPLANSymposiumontheAdaProgrammingLanguage15(11):194201.
doi:10.1145/948632.948659.ISBN0897910303.
3. SofTechInc.,Waltham,MA(19830411)."AdaCompilerValidationSummaryReport:NYUAda/ED,Version
19.7V001".Retrieved20101216.
4. [1](http://garmahis.com/reviews/wireframetools/)ListofcommonUIprototypingtools
5. HowSimulationSoftwareCanStreamlineApplicationDevelopment(http://www.cio.com/article/print/28501)
6. [2](http://konigi.com/node/1416)
7. Top10SimulationToolsforUIDesigners,InformationArchitectsandUsabilitySpecialists(http://uidesign
usability.blogspot.com/2007/03/top10simulationtoolsforui.html)
8. VisioReplacement?YouBetheJudge(http://www.boxesandarrows.com/view/visio_replaceme)
9. LuqiBerzins,Yeh(October1988)."APrototypingLanguageforRealTimeSoftware".IEEETransactionson
SoftwareEngineering14(10):14091423.doi:10.1109/32.6186.
10. LuqiKetabchi(March1988)."AComputerAidedPrototypingSystem".IEEESoftware5(2):6672.
doi:10.1109/52.2013.
11. Luqi(May1989)."SoftwareEvolutionthroughRapidPrototyping".IEEEComputer22(5):1325.
doi:10.1109/2.27953.

Retrievedfrom"https://en.wikipedia.org/w/index.php?title=Software_prototyping&oldid=689363575"
Categories: Softwaredevelopment
Thispagewaslastmodifiedon6November2015,at17:27.
TextisavailableundertheCreativeCommonsAttributionShareAlikeLicenseadditionaltermsmay
apply.Byusingthissite,youagreetotheTermsofUseandPrivacyPolicy.Wikipediaisa
registeredtrademarkoftheWikimediaFoundation,Inc.,anonprofitorganization.