Typer af Software Process Modeller

Bygning software er kompliceret. Billede af Flickr.com, courtesy af Aldo Gonzalez

Design, bygge og vedligeholde software programmer tager tid, penge og frem for alt en metode, en linje af angreb.Ellers tusinder og atter tusinde af indbyrdes forbundne opgaver softwareudvikling kræver hurtigt ville gå galt.Som software og dens anvendelsesmuligheder har udviklet sig og multipliceres, så også have de processer, der anvendes til at producere det.

Typer

  • dag i virkeligheden er der hundredvis af udviklingsmodeller, men i praksis mange er varianter på en halv snes grundmodeller.Den mest udbredte er: vandfaldet, spiral, kode-og-fix, rapid prototyping, kommerciel off-the-shelf (COTS) tweaking, smid-væk prototyping, ekstrem programmering (XP), det forenede proces (UP), og den agilebehandle.Beslutte, hvilke at ansætte afhænger i høj grad på fremtidige slutbrugernes krav og forventninger, projektets kompleksitet og efterfølgende drift vedligeholdelse og tidspresset står softwareingeniører.

Betydning

  • Skrivning, montage og test kode er en meget krævende, meget udførlige virksomhed.Den funktion, der edb skal opdeles i sine diskrete dele, opgaver og drift af hver del oversat til linjer kode, og derefter disse blokke af kode, integreret med de omkringliggende blokke og programmet som helhed.Når det er oppe og køre, uforudsete glitches uvægerligt overflade kræver patches og rettelser.Et program med en lang operationelle levetid skal også opdateres med jævne mellemrum.

Ekspert Insight

  • Visse modeller passer nogle organisationer bedre end andre.Uforanderlige miljøer, Frank Kand af London School of Economics observeret, har meget specifikke standardprocedurer.Modeller afhængige af stringent dokumentation og omhyggelige udvikling ligesom vandfald og spiral arbejde bedst her.Men hvis konstant forandring er normen, er en organisation bedre tjent med rapid prototyping.Nogle gange, dog lærer organisationen som den bevæger sig fremad, og softwareudviklere skal beskæftige sig med ubekendte.Her, smid-væk prototyping, udforskende udvikling og agile software processer fungere bedre.

strukturerede processer

  • grundig og tidskrævende, vandfaldet processen "definerer, før det design" og "design før det koder."Brugerbehov dokumenteres og software krav identificeret, så systemets arkitektur er designet;kodning og test følger.Men det er ikke en iterativ proces, en hvor design ideer og kode er gentagne gange revisited og raffineret.Ofte vage brugerkrav kommer tilbage for at hjemsøge udviklere.Under en mere trinvis tilgang, spiral proces styrer denne og andre risici.Hver fase leverer en del af den færdige software.Risici og begrænsninger analyseres og nye tilgange udforskes på forhånd.Udviklere derfor ofte kombinere begge processer.

Ustruktureret Processer

  • End-brugere ofte tilstedeværende udviklere med i bedste fald en sketchy sæt oprindelige krav.Så designere bygge en prototype med klienten, teste det, forfine det og teste det igen, indtil kunden er tilfreds.Sommetider udviklere mangler selv de mest rudimentære sæt ende brugerkrav ved et projekts begyndelse og dermed stole på en on-the-fly, kode-og-fix sonderende proces.COTS anvendes, når tid og finansieringsbegrænsninger vejer tungt.Selvom hensigtsmæssigt, tweaking off-the-shelf software har en ulempe: funktionelle kompromiser ofte skal foretages, og interoperabilitetsproblemer overvundet.

Ressourcer

  • En Beredskab tilgang til Krav Elicitation og systemer;Frank Kand;1988
219
0
1
Anden Computer Software