Programvarens livssyklus

Livssyklusen til programvare , i informatikk , og spesielt i programvareteknikk , refererer til måten en utviklingsmetodikk bryter ned aktiviteten med å lage programvareprodukter til koordinerte underoppgaver, hvis endelige resultat er realiseringen av selve produktet og all dokumentasjon knyttet til det: typiske faser inkluderer studie eller analyse, design , konstruksjon , testing , utvikling, installasjon , vedlikehold og utvidelse, [1] alt av en eller flere programvareutviklere .

Programvareutvikling er en svært kompleks og omfattende prosedyre i alle dens faser, som noen ganger krever at mange programvareutviklere fullføres innen rimelig eller forhåndsbestemt tid; noen ganger blir et programvareprosjekt utført av et fellesskap av brukere distribuert i et aktivt nettverk gjennom en diskusjonsgruppe , slik det for eksempel skjer for ulike Linux-distribusjoner ; når et programvareprosjekt utvikler et annet med utgangspunkt i samme type program, men utført av et annet fellesskap, snakker vi om en gaffel .

Historie

Opptredenen i litteraturen og i praksisen med programvareutvikling av konseptet "livssyklus" kan gjøres til å falle sammen med fødselen av programvareteknikk , da det representerer en historisk passasje fra programvareutvikling forstått som en "håndverksaktivitet" (dvs. betrodd den frie kreativiteten til enkeltpersoner) til en mer industriell tilnærming , der opprettelsen av programvareprogrammer og systemer betraktes som en kompleks prosess som krever passende planlegging, kontroll og dokumentasjon (som tradisjonelt forekommer i de mer modne ingeniørsektorene ) . [2]

Til syvende og sist kan denne overgangen spores tilbake til den økte kompleksiteten til systemene, fremveksten av et reelt programvaremarked, samt nye og strengere kvalitetskrav , knyttet til for eksempel bruk av IT-systemer i kritiske sammenhenger (kraftverk, romfartssystemer, våpen og så videre). Dette perspektivskiftet begynte å skje historisk mellom slutten av 1960-tallet og begynnelsen av det følgende tiåret . Siden den gang har forskning på disse spørsmålene vært ekstremt produktiv i både industri og akademia. Ofte krever kompleksiteten til et programvareprosjekt overvåking eller ledelse av en eller flere prosjektledere av selskapets backoffice .

Beskrivelse

Nesten alle programvarelivssyklusmodeller innebærer å bryte ned utviklingsprosessen i lignende (om ikke identiske) sett med aktiviteter. Skillene mellom ulike livssykluser fremheves på andre aspekter, for eksempel:

Dokumentasjonen av produktene til de ulike deloppgavene spiller også en vesentlig rolle i alle programvarelivssykluser; utformingen av dokumentasjonen er derfor regulert på samme måte som nevnte virksomhet. Programvaredesignfasene er:

Analyse

Analysen er den foreløpige undersøkelsen av konteksten programvareproduktet må passe inn i, på egenskapene eller kravene som det må utvise og muligens av kostnadene og logistiske aspekter ved realiseringen; denne fasen kan brytes ned i underaktiviteter som mulighetsanalyse , applikasjonsdomeneanalyse og modellering , kravanalyse og så videre. I en bredere forstand kan det sies at analysen tar sikte på å definere (så nøyaktig som mulig) problemet som skal løses. Denne fasen består også av datainnsamling gjennom intervjuer mellom kunde/ klient og relaterte utviklere. På slutten av fasen vil det lages et dokument som beskriver egenskapene til systemet, dette dokumentet kalles et funksjonsspesifikasjonsdokument .

Design

I designaktiviteten er de vesentlige linjene i programvareproduktstrukturen definert i henhold til kravene som fremheves av analysen, vanligvis privilegiet til en programmereranalytiker . Selv utformingen kan brytes ned i deloppgaver, fra den arkitektoniske utformingen til den detaljerte utformingen . Det kan sies at designet har som formål å definere (på et visst detaljnivå) løsningen av problemet. I denne fasen vil det bli utviklet et dokument som vil tillate å ha en definisjon av den generelle strukturen (høynivåarkitektur) og en definisjon av egenskapene til de enkelte komponentene ( moduler ).

Implementering

Implementeringen , også kalt utvikling eller koding av programvareproduktet, er fasen av realisering av programvaren, som konkretiserer programvareløsningen gjennom programmeringen , det vil si skriving av programmer av programmerere eller utviklere.

Organisasjon

I de fleste tilfeller skiller programmererne som tar seg av implementeringen ut minst to aktiviteter knyttet til implementeringen: implementeringen av de individuelle modulene , som utgjør systemet, og integreringen av disse modulene for å danne det overordnede systemet. For eksempel kan en skrivebordsapplikasjon deles inn i tre grunnleggende komponenter: brukergrensesnittet (GUI), behandlingslogikk og databehandling. Vanligvis foregår utviklingen av koden til en applikasjon lokalt på utviklerens PC som vil være i stand til å utføre en første testfase for å verifisere godheten eller ikke av utdataene til programmet som utføres.

Sluttproduktet av denne fasen kalles vanligvis alfaversjonen av programvaren, mens den neste betaversjonen er den som inkluderer korreksjonene og forbedringene som er foreslått av tilbakemeldingene fra testerne (eller testerne ) i neste fase kalt, faktisk, testing, frem til distribusjon av den nyeste versjonen som oppfyller de nødvendige funksjonsspesifikasjonene.

Teknologi

Implementeringsfasen involverer ofte en rekke teknologier knyttet ikke bare til produktet, men også til prosessen som skaper det. Når det gjelder produktet, krever skriving av programmer minst ett programmeringsspråk , noen av dets biblioteker , men involverer ofte andre språk, for eksempel skripting , og andre teknologier som databaser eller selve Internett .

Implementeringsprosessen kan derimot ikke se bort fra en editor for å skrive kildekoden, og en kompilator eller en tolk for å teste utførelse av koden; automatiske bygge- eller feilsøkingsverktøy brukes ofte . Skrivingen av produktdokumentasjonen, på den annen side, kan genereres automatisk fra kommentarene skrevet i kildekoden gjennom passende verktøy, takket være verktøy som Doxygen eller Javadoc . Hvis implementeringen utføres av et team av utviklere, assisteres koordineringen deres vanligvis av revisjonskontrollsystemer (f.eks. Subversion eller GIT ), som identifiserer hver mellomversjon av produktet.

Noen ganger er noen, eller mange, av teknologiene som er nødvendige for produksjon tilgjengelig i et integrert utviklingsmiljø , en applikasjon som forener verktøyene programmereren trenger, eller i utviklingssett (SDK-er), en distribusjon av dokumentasjon og implementering av en språkprogrammering eller plattform.

Testing

Testing eller testing , privilegiet til en eller flere testere , består i verifisering og validering av hvor mye (målbarhet) programvareproduktet som er implementert oppfyller kravene identifisert av analysen. Den relaterte støtteinfrastrukturen som brukes i denne fasen kalles et testmiljø ; med andre ord, testing evaluerer riktigheten i forhold til spesifikasjonene . Også for testing kan de to underoppgavene med å teste de enkelte modulene og teste det integrerte systemet identifiseres ; videre kan ytterligere deloppgaver identifiseres for hvert aspekt av programvareproduktet som skal testes: funksjonstesting , ytelsestesting , bruddtesting , regresjonstesting , sikkerhetstesting , tilgjengelighetstesting , aksepttesting , etc. . I tilfelle av manglende overholdelse av spesifikasjonene, går programvaren, sammen med dokumentet om uregelmessighetene eller feilene, tilbake til utviklerne med oppgaven å løse problemene som er funnet ved også å feilsøke programvaren. Generelt håndteres driftsavvik gjennom spesiell programvare for rapportering av uregelmessigheter , også kalt billett- eller feilsporingssystemer , som registrerer problemene som er rapportert til utviklingsteamet og forenkler organisering, klassifisering og administrasjon (f.eks. Bugzilla , Mantis , Atlassian Jira , etc.) .

Utgivelse og igangkjøring

Når programvaren har bestått testene i testfasen, publiseres den i en endelig versjon og gjøres tilgjengelig, i henhold til reglene for den valgte brukslisensen , for hvem som helst eller kun for kjøpere. Fasen med installasjon og igangkjøring av programvaren produsert på driftsplattformene kalles distribusjon .

Noen ganger settes programvaren også i drift , det vil si installasjon og konfigurasjon av programvareproduktet i utførelsesinfrastrukturen som kan brukes av brukere, kalt drifts- eller produksjons- eller driftsmiljø. Avhengig av kompleksiteten til denne infrastrukturen, kan implementeringen brytes ned i ulike delaktiviteter; faktisk kan det variere fra den enkle kopien av en fil, til den "passende kopien" av mange filer organisert i et komplekst hierarki av kataloger og programvarekomponenter, muligens distribuert på annen maskinvare .

Vedlikehold

Vedlikehold inkluderer de underoppgavene som er nødvendige for endringer i programvareproduktet etter distribusjon, for å korrigere ytterligere feil gjennom patcher ( korrigerende vedlikehold ) , tilpasse det til nye driftsmiljøer ( adaptivt vedlikehold eller miljømigrering), utvide funksjonaliteten ( evolusjonært vedlikehold ) eller konvertere implementeringen av den i en annen struktur (f.eks . migrering av rammeverk eller plattform ). Vedlikehold påvirker kostnadene for et estimat som er rundt 60 % av totale kostnader. Enhver endring av programvaren innebærer nødvendigvis behov for nye tester, både knyttet til eventuelle nye funksjoner som er introdusert, og rettet mot å verifisere at endringene som er gjort ikke har kompromittert eksisterende funksjoner ( regresjonstesting ).

Dokumentasjon

Parallelt med utviklingsfasene nevnt ovenfor, er det vanlig og god praksis at design-, utviklings- og testteamet utarbeider tilhørende programvaredokumentasjon som vil følge med programvaren i sluttfasen eller under selve de enkelte fasene for å støtte neste fase. ...

Programvareinspeksjon

Hver beskrevet programvareutviklingsfase kan falle inn i den såkalte programvareinspeksjonen .

Utviklingsstadier

Pre-alfa

Pre-alfa-versjonen refererer til alle aktivitetene som er utført under programvareprosjektet før de formelle testene. Disse aktivitetene kan omfatte kravanalyse, programvaredesign, programvareutvikling og enhetstesting. I typisk åpen kildekode-utvikling finnes det flere typer pre-alfa-versjoner.

Alfa

Alfaversjonen identifiserer programvaren som er under utvikling, hvis funksjoner ennå ikke er fullstendig implementert og som absolutt har en lang rekke feil som må fikses.

Vanligvis under utviklingen av en programvare gjøres flere alfaversjoner, i noen tilfeller (spesielt når det gjelder åpen kildekode) offentlige, for å introdusere nye funksjoner i programvaren som det er nødvendig å kontrollere funksjonen grundig. Alfaversjonene er derfor å anse som ufullstendige og mangler noen funksjoner og ofte ustabile og derfor ikke egnet for sluttbrukeren.

Beta

Betaversjonen er ikke definitiv programvare, men allerede testet av eksperter og gjort tilgjengelig for et større antall brukere (vanligvis sluttbrukere), som stoler på nettopp deres uforutsigbare handlinger som kan bringe frem nye feil eller inkompatibiliteter i selve programvaren. [3]

Publikasjon

Når den er publisert, er programvaren generelt kjent som en "stabil versjon". Den formelle termen avhenger ofte av metoden: fysiske medier, nettversjon eller en nettapplikasjon.

Utgivelse til produksjon (RTM)

Begrepet release to manufacturing ( RTM ), (GA) brukes når produktet distribueres til publikum.

Det brukes vanligvis i visse sammenhenger for masseproduksjon i detaljhandel - i motsetning til en spesialisert programvareproduksjon eller -prosjekt i en kommersiell eller offentlig produksjon eller distribusjon - der programvare selges som en del av en pakke i et maskinvaresalg og vanligvis programvaren og relatert maskinvare vil til slutt være tilgjengelig og solgt til stor skala / offentlig i utsalgssteder for å indikere at programvaren har nådd et definert kvalitetsnivå og er klar for massedistribusjon. RTM kan også i andre sammenhenger bety at programvare er levert til en kunde for installasjon eller distribusjon til relaterte sluttbrukerdatamaskiner eller datamaskiner. Begrepet definerer ikke leveringsmekanismen eller volumet; det står bare at kvaliteten er tilstrekkelig for massedistribusjon.

General Availability (GA)

Generell tilgjengelighet eller General Availability , ( GA ) er markedsføringsfasen der alle nødvendige markedsføringsaktiviteter er fullført og et programvareprodukt er tilgjengelig for kjøp, men avhengig av språk, region, tilgjengelighetselektronikk enn media. [4] Kommersialiseringsaktiviteter kan inkludere sikkerhets- og samsvarstesting, samt lokalisering og verdensomspennende tilgjengelighet. Tiden mellom RTM og GA kan gå fra en uke til måneder, i noen tilfeller, før en generelt tilgjengelig utgivelse kan deklareres på grunn av tiden som kreves for å fullføre alle markedsføringsaktivitetene som kreves av GA.

Utgivelse til web (RTW)

Utgivelse til nettet ( RTW ) er en måte å sende programvare som bruker Internett til distribusjon. Produsenten produserer ikke fysiske medier i denne typen distribusjonsmekanismer. Nettversjoner blir mer vanlige ettersom Internett-bruken øker.

Programvareutviklingsprosesser

De fleste metoder for programvareutvikling består, i det minste i prinsippet, av et modelleringsspråk og en prosess.

  1. Modelleringsspråket er notasjonen som brukes av metoder for å uttrykke designkarakteristikker ;
  2. prosessen er listen over indikasjoner angående trinnene som skal tas for å produsere selve prosjektet.

UML ( Unified Modeling Language ) , for eksempel, er et modelleringsspråk som brukes av prosesser for å lage, organisere, dokumentere produktene som er skapt av fasene som prosessen er sammensatt av. De som, individuelt eller i grupper, jobber med utvikling eller modifikasjon av en programvare, har nødvendigvis en viss tilnærming i forholdet til sine kunder/brukere, i organisering av arbeidet, i valg av teknikker som skal brukes, ta i bruk en prosess.

Enten det er bevisst eller ikke, har hver programvareutvikler (eller gruppe av utviklere) sin egen utviklingsprosess, det vil si sin egen måte å jobbe på, basert på sin egen erfaring, sin egen kultur og den kulturelle og organisatoriske konteksten den er i. opererer..

Historien om suksessene (og fremfor alt feilene) til programvareutviklingsprosjekter har lært at hver utviklingsprosess har sine egne styrker og begrensninger, og at en utviklingsprosess som er utilstrekkelig til de konkrete behovene til det spesifikke prosjektet kan føre til fiasko av selve prosjektet, eller i alle fall misnøye til kunder/brukere og utviklerne selv.

Programvareutviklingssyklusen er i de fleste tilfeller iterativ, og hver iterasjon produserer sin egen utgivelse . Vi lister nedenfor hovedfasene som kan være en del av hver enkelt iterasjon:

  1. Spesifikasjon av krav : hva etterspørres av klienten ;
  2. Mulighetsstudie ( lag eller kjøp );
  3. Analyse og Design hvor vi med analyse mener studiet av hva systemet må gjøre ("logisk" synspunkt) og med design studiet av hvordan systemet må implementeres ("teknisk" synspunkt). De siste årene har det tradisjonelle skillet mellom analyse og design gått i krise.
  4. Implementering ;
  5. Integrasjon og testing .

Mens programvarelivssyklusmodeller opprinnelig bare var konseptuelle verktøy, automatiserer moderne utviklingsmiljøer for programvareutvikling ( CASE ) ofte bruken av en bestemt livssyklus så vel som andre aspekter ved programvareutvikling.

Noen eksempler på programvareutviklingsmetodikk

Kaskademodell

Historisk sett var fossefallmodellen den første programvarelivssyklusmodellen. Det innebærer sekvensiell utførelse av analyse- , design- , utviklings- , test- og vedlikeholdsfasene . [5]

Iterative modeller

Kategorien iterative modeller inkluderer alle utviklingsprosessene som lar deg gå tilbake til en fase av prosedyren som allerede er behandlet tidligere. For hver "iterable" fase har vi en tendens til å starte med et utkast til løsningen som deretter vil bli foredlet i neste trinn.

Inkrementelle og evolusjonære modeller er en spesifikasjon av iterative modeller.

Inkrementelle modeller Evolusjonære modeller

I følge det vanligste synet innen moderne programvareteknikk er fossefallsmodellen ikke lenger egnet for applikasjoner, i hvert fall for de fleste applikasjoner. Blant elementene som har bidratt til nedgangen til denne modellen er økningen i kompleksitet av applikasjoner, introduksjonen av GUIer (som har brakt tidligere mindre brukervennlighetsproblemer til designeres oppmerksomhet ), og fremveksten av nye programmeringsparadigmer og analyse og design metodologier, spesielt de som er relatert til det objektorienterte paradigmet .

Spesielt har en enorm klasse av såkalte evolusjonsmodeller etablert seg, alle basert på den sentrale ideen om å involvere klienten (eller brukeren) mer, med jevne mellomrom sende inn delversjoner eller prototyper av sluttproduktet til ham. En tradisjonell teknikk i denne forstand er for eksempel hurtig prototyping . I denne tankegangen er en av de siste generasjonene de såkalte smidige metodikkene .

Merknader

  1. ^ , ND Birrell og Martyn A. Ould, A Practical Handbook for Software Development , Cambridge University Press, 1988, ISBN 978-0-521-34792-1 . 
  2. ^ Evolution of Software Development , på glennbouchard.com . Hentet 13. april 2022 .
  3. ^ Hva er en betaversjon av en programvare? , på 01net.it . Hentet 17. august 2022 .
  4. ^ Yvan Philippe Luxembourg, Top 200 SAM Terms - A Glossary Of Software Asset Management Terms , OMTCO, 20. mai 2013. Hentet 21. mai 2013 ( arkivert 10. august 2013) .
  5. ^ Programvarens livssyklus: fossefallmodellen , på brainybyte.it . Hentet 17. august 2022 .

Relaterte elementer

Andre prosjekter