Full levetid for produktbruk. Programmere livssyklus

Federal Agency om teknisk regulering og metrologi i Russland 03/01/2012 i stedet for GOST R ISO / IEC 12207-99, standard GOST R ISO / IEC 12207-2010 " Informasjonsteknologi... System- og programvareteknikk. Livssyklusprosesser for programvare ", identisk med den internasjonale standarden ISO / IEC 12207: 2008" System- og programvareteknikk - Programvaresyklusprosesser ".

Denne standarden, ved bruk av veletablert terminologi, etablerer generell struktur livssyklusprosesser for programvare som kan målrettes i programvareindustrien. Standarden definerer prosesser, aktiviteter og oppgaver som brukes i anskaffelsen programvareprodukt eller tjenester, så vel som i levering, utvikling, bruk for det tiltenkte formålet, vedlikehold og avslutning av bruken av programvareprodukter.

Programvare livssyklus prosesser

Standarden grupperer de forskjellige aktivitetene som kan utføres i løpet av livssyklusen. programvaresystemer, i syv prosessgrupper. Hver av livssyklusprosessene i disse gruppene er beskrevet i form av mål og ønskede resultater, lister over handlinger og oppgaver som må utføres for å oppnå disse resultatene.

• avtale prosesser - to prosesser;
• prosesser med organisatorisk støtte for prosjektet - fem prosesser;
• prosjektprosesser - syv prosesser;
• tekniske prosesser - elleve prosesser;
• prosesser for implementering av programvare - syv prosesser;
• programvarestøtteprosesser - åtte prosesser;
• prosesser for gjenbruk av programvare - tre prosesser.
• Grunnleggende:
  • Innkjøp (handlinger og oppgaver for kundens innkjøpsprogramvare)
  • Levering (handlinger og oppgaver fra leverandøren som forsyner kunden et programvareprodukt eller en tjeneste)
  • Utvikling (handlinger og oppgaver utført av utvikleren: programvareutvikling, design og operativ dokumentasjon, utarbeidelse av test- og opplæringsmateriell, etc.)
  • Drift (operatørens handlinger og oppgaver - organisasjonen som driver systemet)
  • Eskorte (handlinger og oppgaver utført av eskorteorganisasjonen, det vil si eskorte tjenesten). Vedlikehold - gjøre endringer i programvaren for å fikse feil, forbedre ytelsen eller tilpasse seg endrede arbeidsforhold eller krav.
• Datterselskap
  • Dokumentasjon (formalisert beskrivelse av informasjon opprettet i løpet av programvarens livssyklus)
  • Konfigurasjonsadministrasjon (anvendelse av administrative og tekniske prosedyrer gjennom programvarens livssyklus for å bestemme tilstanden til programvarekomponenter, administrere endringene).
  • Kvalitetssikring (sikre at IS og dets livssyklusprosesser oppfyller de spesifiserte kravene og godkjente planer)
  • Bekreftelse (fastsettelse av at programvareprodukter, som er resultatene av en eller annen handling, tilfredsstiller fullt ut kravene eller betingelsene forårsaket av de tidligere handlingene)
  • Sertifisering (bestemmelse av fullstendigheten av samsvar med de spesifiserte kravene og det opprettet systemet med deres spesifikke funksjonelle formål)
  • Felles vurdering (vurdering av status for prosjektet: kontroll av planlegging og forvaltning av ressurser, personell, utstyr, verktøy)
  • Revisjon (bestemmelse av overholdelse av krav, planer og vilkår i kontrakten)
  • Problemløsning (analysere og løse problemer, uavhengig av opprinnelse eller kilde, som oppdages under utvikling, drift, vedlikehold eller andre prosesser)
• Organisatorisk
  • Kontroll (handlinger og oppgaver som kan utføres av enhver part som kontrollerer sine egne prosesser)
  • Oppretting av infrastruktur (valg og vedlikehold av teknologi, standarder og verktøy, valg og installasjon av maskinvare og programvare som brukes til utvikling, drift eller vedlikehold av programvare)
  • Forbedring (vurdering, måling, kontroll og forbedring av livssyklusprosesser)
  • Opplæring (grunnopplæring og påfølgende kontinuerlig faglig utvikling av personell)

Hver prosess involverer en rekke handlinger. For eksempel dekker anskaffelsesprosessen følgende trinn:

1. Starte et oppkjøp
2. Utarbeidelse av søknadsforslag
3. Utarbeidelse og endring av kontrakten
4. Leverandør tilsyn
5. Aksept og fullføring av arbeid

Hver handling inkluderer en rekke oppgaver. For eksempel bør utarbeidelsen av budforslag omfatte:

1. Dannelse av systemkrav
2. Dannelse av en liste over programvareprodukter
3. Setter betingelser og avtaler
4. Beskrivelse av tekniske begrensninger (miljøet til systemet fungerer osv.)

Stadier av programvarens livssyklus, forholdet mellom prosesser og stadier

Programvare livssyklusmodell - en struktur som definerer sekvensen av utførelse og forholdet mellom prosesser, handlinger og oppgaver gjennom hele livssyklusen. Livssyklusmodellen avhenger av detaljene, omfanget og kompleksiteten til prosjektet og detaljene i forholdene der systemet er opprettet og fungerer.

GOST R ISO / IEC 12207-2010 tilbyr ikke en spesifikk livssyklusmodell. Dens bestemmelser er felles for alle livssyklusmodeller, metoder og teknologier for å skape IP. Den beskriver strukturen i livssyklusprosesser uten å spesifisere hvordan du skal implementere eller utføre aktivitetene og oppgavene som inngår i disse prosessene.

Programvarens livssyklusmodell inkluderer:

1. Stadier;
2. Arbeidsresultater på hvert trinn;
3. Viktige hendelser er fullføringspunkter og beslutningstaking.

Figur: 5.2.

Disse aspektene er:

1. det kontraktsmessige aspektet som kunden og leverandøren inngår kontraktsforhold og implementere anskaffelses- og leveringsprosesser;
2. aspektet ved ledelse, som inkluderer handlinger for å administrere personene som deltar i programvarens livssyklus (leverandør, kunde, utvikler, operatør, etc.);
3. det operasjonelle aspektet, inkludert operatørens handlinger for å tilby tjenester til brukerne av systemet;
4. det tekniske aspektet, som inneholder handlinger fra en utvikler eller støttetjeneste for å løse tekniske problemer knyttet til utvikling eller modifisering av programvareprodukter;
5. aspektet ved støtte assosiert med implementering av støtteprosesser der støttetjenester gir de nødvendige tjenestene til alle andre deltakere i arbeidet. I dette aspektet kan man skille aspektene ved programvarekvalitetsstyring, inkludert kvalitetssikringsprosesser, verifisering, sertifisering, felles vurdering og revisjon.

Organisasjonsprosesser utføres på bedriftsnivå eller på nivået for hele organisasjonen som helhet, og skaper grunnlag for implementering og kontinuerlig forbedring av livssyklusprosesser for programvare.

5.6. Modeller og stadier av programvarens livssyklus

Livssyklusmodellen forstås som en struktur som bestemmer sekvensen for utførelse og innbyrdes forhold mellom prosesser, handlinger og oppgaver i løpet av livssyklusen til programvaren. Livssyklusmodellen avhenger av detaljene, omfanget og kompleksiteten til prosjektet og detaljene i forholdene der systemet er opprettet og fungerer.

ISO / IEC 12207 gir ikke en spesifikk livssyklusmodell og programvareutviklingsmetoder. Dens bestemmelser er felles for alle livssyklusmodeller, metoder og teknologier for programvareutvikling. Standarden beskriver strukturen til programvarens livssyklusprosesser, men spesifiserer ikke hvordan man skal implementere eller utføre handlingene og oppgavene som er inkludert i disse prosessene.

Livssyklusmodellen for en hvilken som helst spesifikk programvare bestemmer arten av prosessen med opprettelsen, som er et sett med arbeid bestilt i tide, sammenkoblet og samlet i trinn (faser) av arbeidet, hvis ytelse er nødvendig og tilstrekkelig til å lage programvare som oppfyller de spesifiserte kravene.

Fasen (fasen) av programvareopprettelse forstås som en del av programvarelagringsprosessen, begrenset av en viss tidsramme og slutter med utgivelsen av et bestemt produkt (programvaremodeller, programvarekomponenter, dokumentasjon osv.), Bestemt av kravene spesifisert for dette trinnet. Stadiene av programvareutvikling skiller seg ut av grunner til rasjonell planlegging og organisering av arbeidet, og slutter med de spesifiserte resultatene. Livssyklusen til programvaren inkluderer vanligvis følgende trinn:

1. dannelse av programvarekrav;
2. design (utvikling av et systemprosjekt);
3. implementering (kan deles inn i underfaser: detaljert design, koding);
4. testing (kan deles inn i frittstående og komplisert testing og integrering);
5. igangkjøring (implementering);
6. drift og vedlikehold;
7. avvikling.

Noen eksperter introduserer en ekstra innledende fase - mulighetsstudie systemer. Dette refererer til programvaren og maskinvaresystemet som programvare blir opprettet, kjøpt eller endret for.

Stadiet for dannelse av programvarekrav er en av de viktigste og bestemmer for en betydelig (til og med avgjørende!) Grad av suksessen til hele prosjektet. Begynnelsen på dette trinnet er å skaffe en godkjent og validert systemarkitektur med inkludering av grunnleggende avtaler for distribusjon av funksjoner mellom maskinvare og programvare. Dette dokumentet bør også inneholde en bekreftelse av den generelle forståelsen av programvarens funksjon, inkludert grunnleggende avtaler om distribusjon av funksjoner mellom personen og systemet.

Stadiet for dannelse av programvarekrav inkluderer følgende trinn.

1. Planlegge arbeidet før arbeidet med et prosjekt. Hovedoppgavene til scenen er definisjonen av utviklingsmål, en foreløpig økonomisk vurdering av prosjektet, bygging av en arbeidsplan, opprettelse og opplæring av en felles arbeidsgruppe.
2. Gjennomføre en kartlegging av aktivitetene til en automatisert organisasjon (objekt), innenfor rammen som den foreløpige identifiseringen av kravene til det fremtidige systemet utføres, bestemme organisasjonens struktur, bestemme listen over målfunksjoner i organisasjonen, analysere fordelingen av funksjoner etter avdelinger og ansatte, identifisere funksjonelle interaksjoner mellom avdelinger, informasjonsflyt i og mellom avdelinger , eksternt i forhold til organisering av objekter og ekstern informasjonspåvirkning, analyse av eksisterende automatiseringsverktøy i organisasjonen.

Å bygge en modell av organisasjonens (objekt) aktivitet, sørge for behandling av kartleggingsmateriell og bygge to typer modeller:

• en "AS-IS" ("as is") -modell som gjenspeiler den nåværende situasjonen i organisasjonen på tidspunktet for undersøkelsen og lar deg forstå hvordan den fungerer denne organisasjonen, samt identifisere flaskehalser og formulere forslag for å forbedre situasjonen;
• modell "TO-BE" ("hvordan det skal være"), som gjenspeiler ideen om nye teknologier i organisasjonen.

Hver av modellene skal inneholde en komplett funksjonell og informasjonsmodell over organisasjonens aktiviteter, samt (om nødvendig) en modell som beskriver dynamikken i organisasjonens atferd. Merk at de konstruerte modellene har uavhengig praktisk betydning, uavhengig av om virksomheten vil utvikle og implementere et informasjonssystem, siden de kan brukes til å trene ansatte og forbedre virksomhetens forretningsprosesser.

Resultatet av fullførelsen av stadiet for dannelse av programvarekrav er programvarespesifikasjoner, funksjonelle, tekniske og grensesnittspesifikasjoner, for hvilke deres fullstendighet, testbarhet og gjennomførbarhet er bekreftet.

Designfasen inkluderer følgende trinn.

1. Utvikling av et programvaresystemprosjekt. På dette stadiet blir det gitt svar på spørsmålet "Hva skal det fremtidige systemet gjøre?", Nemlig: systemets arkitektur, dets funksjoner, eksterne driftsforhold, grensesnitt og distribusjon av funksjoner mellom brukere og systemet, krav til programvare og informasjonskomponenter, sammensetningen av utøvere og tidsfrister bestemmes. utvikling, programvare feilsøkingsplan og kvalitetskontroll.

   Grunnlaget for systemprosjektet er dannet av modellene til det designede systemet, som er basert på "TO-BE" -modellen. Resultatet av utviklingen av et systemprosjekt bør være en godkjent og bekreftet spesifikasjon av programvarekrav: funksjonelle, tekniske og grensesnittspesifikasjoner der deres fullstendighet, testbarhet og gjennomførbarhet er bekreftet.

2. Utvikling av et detaljert (teknisk) prosjekt. På dette stadiet utføres selve programvaredesignen, inkludert utformingen av systemarkitekturen og detaljert design. Dermed blir svaret gitt på spørsmålet: "Hvordan bygge et system slik at det oppfyller kravene?"

Resultatet av den detaljerte utformingen er utviklingen av en bekreftet programvarespesifikasjon, inkludert:

• dannelse av et hierarki av programvarekomponenter, intermodulære grensesnitt for data og kontroll;
• spesifikasjon av hver programvarekomponent, navn, formål, forutsetninger, størrelser, anropssekvens, inndata og utdata, feil utganger, algoritmer og logikkretser;
• dannelse av fysiske og logiske datastrukturer ned til nivået på individuelle felt;
• utvikling av en plan for distribusjon av databehandlingsressurser (CPU-tid, minne osv.);
• verifisering av fullstendighet, konsistens, gjennomførbarhet og gyldighet av kravene;
• foreløpig integrasjons- og feilsøkingsplan, brukerhåndbok og godkjenningstestplan.

Fullføringen av det detaljerte designfasen er gjennom

Det bør starte med å definereLivssyklus programvare (Software Life Cycle Model) er en periode som begynner fra det øyeblikket du tar en beslutning om å lage et programvareprodukt og slutter i øyeblikket det er fullstendig pensjonert. Denne syklusen er prosessen med å bygge og utvikle programvare.

Livssyklusmodeller for programvare

Livssyklusen kan representeres som modeller. For tiden er de vanligste:fallende, trinnvis (iscenesatt modell med mellomkontroll ) og spiral livssyklusmodeller.

Kaskademodell

Kaskademodell (eng. fossemodell) Er en modell av programvareutviklingsprosessen, hvis livssyklus ser ut som en strøm som sekvensielt går gjennom fasene til kravanalyse og design. implementering, testing, integrering og support.

Utviklingsprosessen implementeres ved hjelp av en ordnet sekvens av uavhengige trinn. Modellen antar at hvert påfølgende trinn begynner etter fullføring av forrige trinn. I alle trinn i modellen utføres hjelpeprosesser og organisasjonsprosesser og aktiviteter, inkludert prosjektledelse, vurdering og kvalitetsstyring, verifisering og validering, konfigurasjonsstyring og dokumentasjonsutvikling. Som et resultat av fullførelsen av trinnene dannes mellomprodukter som ikke kan endres i påfølgende trinn.

Livssyklusen er tradisjonelt delt inn i følgende hovedtematrinn:

1. Kravsanalyse,
2. Design,
3. Koding (programmering),
4. Testing og feilsøking,
5. Drift og vedlikehold.

Fordeler med modellen:

• stabilitet i kravene gjennom hele utviklingens livssyklus;
• det dannes et komplett sett på hvert trinn prosjektdokumentasjonsom oppfyller kriteriene for fullstendighet og konsistens;
• sikkerheten og klarheten til trinnene i modellen og enkel anvendelse;
• trinnene i arbeidet utført i en logisk rekkefølge tillater planlegging av fullføringstid for alt arbeid og tilsvarende ressurser (monetære, materielle og menneskelige).

Ulemper ved modellen:

• kompleksiteten i en klar formulering av krav og umuligheten av deres dynamiske endring gjennom hele livssyklusen;
• lav fleksibilitet i prosjektledelse;
• sekvensen av den lineære strukturen i utviklingsprosessen, som et resultat, å returnere til tidligere trinn for å løse nye problemer fører til økte kostnader og forstyrrelser i arbeidsplanen;
• uegnet mellomprodukt for bruk;
• umulighet av fleksibel modellering av unike systemer;
• sen påvisning av monteringsproblemer på grunn av samtidig integrering av alle resultater ved slutten av utviklingen;
• utilstrekkelig brukerdeltakelse i etableringen av systemet - helt i begynnelsen (når du utvikler krav) og til slutt (under akseptanstester);
• brukere kan ikke være sikre på kvaliteten på produktet som blir utviklet før slutten av hele utviklingsprosessen. De har ikke muligheten til å vurdere kvaliteten, fordi du ikke kan se det ferdige produktet av utviklingen;
• det er ingen måte for brukeren å bli vant til systemet gradvis. Læringsprosessen finner sted på slutten av livssyklusen, når programvaren allerede er tatt i bruk;
• hver fase er en forutsetning for implementering av påfølgende handlinger, noe som gjør denne metoden til et risikabelt valg for systemer som ikke har noen analoger, fordi den egner seg ikke til fleksibel modellering.

Det er vanskelig å implementere Waterfall Life Cycle Model på grunn av kompleksiteten i programvareutvikling uten å gå tilbake til de forrige trinnene og endre resultatene for å eliminere problemene som oppstår.

Omfanget av fossemodellen

Begrensningen av omfanget av fossemodellen bestemmes av dens ulemper. Bruken er mest effektiv i følgende tilfeller:

1. når du utvikler prosjekter med klare, uforanderligelivssyklus krav, forståelig implementering og teknisk metode;
2. når du utvikler et prosjekt med fokus på å bygge et system eller produkt av samme type som tidligere utviklet av utviklere;
3. når du utvikler et prosjekt relatert til opprettelse og utgivelse av en ny versjon av et eksisterende produkt eller system;
4. når du utvikler et prosjekt relatert til overføring av et eksisterende produkt eller system til en ny plattform;
5. når du utfører store prosjekter som involverer flere store utviklingsteam.

Inkrementell modell

(trinnvis modell med mellomkontroll)

Inkrementell modell (eng. økning - øke, inkrement) innebærer utvikling av programvare med en lineær trinnsekvens, men i flere trinn (versjoner), dvs. med den planlagte forbedringen av produktet for hele tiden til livssyklusen for programvareutvikling tar slutt.

Programvareutvikling utføres i iterasjoner med sykluser tilbakemelding mellom trinn. Trinnvise justeringer gjør det mulig å ta hensyn til den virkelig eksisterende gjensidige påvirkningen av utviklingsresultatene på forskjellige stadier, levetiden til hvert trinn strekkes over hele utviklingsperioden.

I begynnelsen av arbeidet med et prosjekt blir alle grunnleggende krav til systemet bestemt, delt inn i mer og mindre viktig. Etter det er systemet utviklet i henhold til prinsippet om trinn, slik at utvikleren kan bruke dataene som er innhentet under programvareutvikling. Hvert trinn skal legge til litt funksjonalitet i systemet. Utgivelsen starter med komponenter med høyest prioritet. Når delene av systemet er definert, tar de den første delen og begynner å detaljere den ved hjelp av den mest passende prosessen. Samtidig er det mulig å avklare kravene til andre deler som er frosset inn i gjeldende sett med krav til dette arbeidet. Om nødvendig kan du gå tilbake senere til denne delen. Hvis en del er klar, blir den levert til klienten som kan bruke den i arbeidet. Dette vil gjøre det mulig for kunden å avklare kravene til følgende komponenter. Deretter utvikler de neste del av systemet. De viktigste trinnene i denne prosessen er å bare implementere en delmengde av programkravene og avgrense modellen i en serie påfølgende utgivelser til programvaren er fullt implementert.

Livssyklusen til denne modellen er typisk for utvikling av komplekse og komplekse systemer, som det er en klar visjon for (både fra kundens side og fra utviklersiden) om hva det endelige resultatet skal være. Versjonsutvikling utføres av forskjellige grunner:

• kunden kan ikke umiddelbart finansiere hele det dyre prosjektet;
• mangel på utvikler nødvendige ressurser å implementere et komplekst prosjekt på kort tid;
• krav til trinnvis implementering og produktutvikling av sluttbrukere. Innføringen av hele systemet på en gang kan føre til avvisning blant brukerne og bare "bremse" prosessen med overgang til ny teknologi. Figurativt sett kan de ganske enkelt “ikke fordøye et stort stykke, så det må knuses og gis i deler”.

Fordeler og begrensninger denne modellen (strategien) er den samme som fossen (klassisk livssyklusmodell). Men i motsetning til den klassiske strategien, kan kunden se resultatene tidligere. Allerede basert på resultatene av utviklingen og implementeringen av den første versjonen, kan han endre kravene til utvikling litt, forlate den eller tilby utvikling av et mer perfekt produkt med inngåelsen av en ny kontrakt.

Fordeler:

• kostnadene som påløper på grunn av endrede brukerkrav reduseres, omanalyse og innsamling av dokumentasjon reduseres betydelig sammenlignet med fossemodellen;
• det er lettere å få tilbakemeldinger fra klienten om utført arbeid - klienter kan komme med kommentarer om de ferdige delene og se hva som allerede er gjort. Fordi de første delene av systemet er prototypen til systemet som helhet.
• kunden har evnen til raskt å skaffe seg og mestre programvaren - kunder kan få reelle fordeler fra systemet tidligere enn det som ville være mulig med en fossemodell.

Ulemper ved modellen:

• ledere må kontinuerlig måle fremdriften i prosessen. i tilfelle rask utvikling, bør du ikke opprette dokumenter for hver minste versjonsendring;
• strukturen til systemet har en tendens til å forverres når nye komponenter legges til - konstante endringer forstyrrer systemets struktur. For å unngå dette tar det ekstra tid og penger til refactoring. Dårlig struktur gjør programvaren vanskelig og kostbar å endre. En avbrutt programvares livssyklus fører til enda større tap.

Ordningen tillater ikke å ta raskt hensyn til de nye endringene og avklaring av programvarekrav. Koordinering av utviklingsresultater med brukere utføres bare på punkter planlagt etter fullføring av hvert trinn i arbeidet, og generelle Krav til programvare er fikset i skjemaet tekniske spesifikasjoner for hele opprettelsestiden. Dermed mottar brukere ofte en PP som ikke oppfyller deres reelle behov.

Spiralmodell

Spiralmodell: Livssyklus - ved hver sving av spiralen opprettes neste versjon av produktet, kravene til prosjektet avklares, kvaliteten bestemmes og arbeidet med neste sving planlegges. Spesiell oppmerksomhet er gitt til de første stadiene av utviklingen - analyse og design, hvor muligheten for visse tekniske løsninger blir kontrollert og begrunnet gjennom prototyping.

Denne modellen er en programvareutviklingsprosess som kombinerer både design og trinnvis prototyping for å kombinere fordelene med et bottom-up og top-down konsept, med fokus på de innledende stadiene i livssyklusen: analyse og design.Karakteristisk trekk denne modellen er et spesielt fokus på risikoer som påvirker organiseringen av livssyklusen.

På analyse- og designstadiene bekreftes gjennomførbarheten av tekniske løsninger og graden av kundetilfredshet gjennom prototyping. Hver sving av spiralen tilsvarer opprettelsen av et brukbart fragment eller versjon av systemet. Dette lar deg avklare kravene, målene og egenskapene til prosjektet, bestemme kvaliteten på utviklingen og planlegge arbeidet til neste spiralrunde. Dermed blir detaljene i prosjektet utdypet og konsekvent konkretisert, og som et resultat velges et rimelig alternativ som oppfyller kundens faktiske krav og blir brakt til implementering.

Livssyklus ved hver spiralsving - forskjellige modeller av programvareutviklingsprosessen kan brukes. Til slutt er sluttproduktet et ferdig produkt. Modellen kombinerer egenskapene til prototypemodellen ogfossemodell... Utvikling av iterasjoner gjenspeiler den objektivt eksisterende spiralsyklusen til systemopprettelsen. Ufullstendig fullføring av arbeidet på hvert trinn lar deg gå videre til neste trinn, uten å vente på fullført arbeid på det nåværende. Hovedoppgaven er å vise systembrukerne et fungerende produkt så snart som mulig, og derved aktivere prosessen med å spesifisere og supplere kravene.

Fordeler med modellen:

• lar deg raskt vise brukere av systemet et brukbart produkt, og derved aktivere prosessen med å avklare og supplere krav;
• tillater endrede krav til programvareutvikling, som er typisk for de fleste utviklinger, inkludert standard;
• modellen gir muligheten for fleksibel design, siden den legemliggjør fordelene med fossemodellen, og samtidig er gjentakelser tillatt gjennom alle faser av den samme modellen;
• lar deg få et mer pålitelig og stabilt system. Når programvaren utvikler seg, blir feil og svakheter oppdaget og løst ved hver iterasjon;
• denne modellen lar brukerne delta aktivt i planleggings-, risikoanalyse-, utviklings- og vurderingsaktiviteter;
• kundens risiko reduseres. Kunden kan fullføre utviklingen av et kompromissløst prosjekt med minimale økonomiske tap for seg selv;
• tilbakemeldinger fra brukere til utviklere gjøres med høy frekvens og i de tidlige stadiene av modellen, som sikrer oppretting av ønsket produkt av høy kvalitet.

Ulemper ved modellen:

• hvis prosjektet har lav risiko eller liten størrelse, kan modellen være dyr. Risikovurdering etter hver spiral er dyr;
• Livssyklusen til en modell har en komplisert struktur, så det kan være vanskelig for utviklere, ledere og kunder å bruke den;
• spiralen kan fortsette på ubestemt tid, siden hver kundesvar på den opprettet versjonen kan generere en ny syklus, som forsinker fullføringen av prosjektet;
• et stort antall mellomliggende sykluser kan føre til behov for ytterligere dokumentasjonsbehandling;
• bruk av modellen kan være kostbart og til og med uoverkommelig fordi tid. brukt på planlegging, omdefinering av mål, utføring av risikoanalyse og prototyping kan være overdreven;
• det kan være vanskelig å definere mål og milepæler som indikerer vilje til å fortsette utviklingsprosessen i neste og

Hovedproblemet med spiralsyklusen er å bestemme når du skal gå til neste trinn. For å løse det innføres tidsfrister for hvert av trinnene.livssyklus og overgangen fortsetter som planlagt, selv om ikke alt det planlagte arbeidet er fullført.Planlegger produsert på grunnlag av statistiske data innhentet i tidligere prosjekter og personlig erfaring utviklere.

Spiral Model Applications

Bruk av spiralmodellen er tilrådelig i følgende tilfeller:

• når du utvikler prosjekter som bruker ny teknologi;
• når du utvikler en ny serie produkter eller systemer;
• når du utvikler prosjekter med forventede vesentlige endringer eller tillegg til kravene;
• å gjennomføre langsiktige prosjekter;
• når du utvikler prosjekter som krever demonstrasjon av kvalitet og versjoner av et system eller produkt over en kort periode;
• når du utvikler prosjekter. som det er nødvendig å beregne kostnadene knyttet til vurdering og løsning av risiko.

Kommentar.

Introduksjon.

1. Programvares livssyklus

Introduksjon.

Riley programmering prosess trinn

Introduksjon.

1.1.1. Formulering av problemet.

1.1.2. Løsningsdesign.

1.1.3. Algoritmekoding.

1.1.4. Vedlikehold av programmet.

1.1.5. Programvaredokumentasjon.

Konklusjon til punkt 1.1

1.2. Definisjon av ZHCPO ifølge Lehman.

Introduksjon.

1.2.1 Systemdefinisjon.

1.2.2. Gjennomføring.

1.2.3. Service.

Konklusjon til punkt 1.2.

1.3. Faser og arbeid av ZhCPO ifølge Boehm

1.3.1. Fossmodell.

1.3.2. Den økonomiske begrunnelsen for fossemodellen.

1.3.3. Forbedring av fossemodellen.

1.3.4. Bestemmelse av livssyklusens faser.

1.3.5. Grunnleggende arbeid med prosjektet.

Litteratur.

Introduksjon

Den industrielle bruken av datamaskiner og den økende etterspørselen etter programvare har gitt presserende oppgaver å øke betydelig produktivitet for programvareutvikling, utvikling av industrielle metoder for planlegging og design av programmer, overføring av organisatoriske og tekniske, tekniske, økonomiske og sosiopsykologiske teknikker, mønstre og metoder fra materialproduksjonssfæren til datamaskinens bruk. En kompleks tilnærming til prosesser for utvikling, drift og vedlikehold av programvare fremmet en rekke presserende problemer, hvis løsning vil eliminere "flaskehalser" i utformingen av programmer, redusere tiden for fullføring av arbeidet, forbedre valg og tilpasning eksisterende programmer, og vil kanskje avgjøre skjebnen til systemer med innebygde datamaskiner.

I praksis med å utvikle store programvareprosjekter er det ofte ingen ensartet tilnærming til estimering av arbeidskraftkostnader, tidspunkt for arbeid og materialkostnader, noe som hindrer økningen i produktivitet for programvareutvikling, og til slutt - effektiv styring av programvarens livssyklus. Siden et program av en hvilken som helst type blir et produkt (unntatt kanskje pedagogiske, modellprogrammer), bør tilnærmingen til produksjonen i mange henseender være lik tilnærmingen til produksjon av industriprodukter, og problemene med å designe programmer blir ekstremt viktige. Denne ideen er kjernen i B.W. Boehms "Software Engineering", som vi brukte til å skrive dette semesteroppgave... I denne boken refererer programvaredesign til prosessen med å lage et programvareproduktdesign.

1 Livssyklus for programvare

INTRODUKSJON

Livssyklusprogram er en kontinuerlig prosess som begynner fra det øyeblikket det tas en beslutning om behovet for å lage programvare, og slutter i det øyeblikket det fullstendig trekkes ut av tjenesten.

Det er flere tilnærminger for å definere faser og aktiviteter i programvarens livssyklus (LCP), trinn i programmeringsprosessen, fossefall og spiralmodeller. Men de inneholder alle vanlige grunnleggende komponenter: problemstilling, løsningsdesign, implementering, vedlikehold.

Den mest berømte og komplette, kanskje, er strukturen til livssyklus-senteret ifølge Boehm, som inkluderer åtte faser. Hun vil bli presentert i fremtiden mer detaljert.

Et av de mulige alternativene er beskrivelsen av det øvre nivået i følge Lehmann, som inkluderer tre hovedfaser og presenterer en beskrivelse av livssyklusen til livet i det mest generelle tilfellet.

Og for en forandring - vi gir trinnene i programmeringsprosessen presentert av D. Riley i boken "Using the Module-2 language". Denne ideen er etter min mening veldig enkel og kjent, og vi vil begynne med den.

1.1 Trinn i Riley-programmeringsprosessen

Introduksjon

Programmeringsprosessen inkluderer fire trinn (fig. 1):

problemstilling, dvs. få en tilstrekkelig ide om hvilken oppgave programmet skal utføre;

utforme en løsning på et allerede utpekt problem (generelt er en slik løsning mindre formell enn det endelige programmet);

koding av programmet, dvs. oversettelse av den designede løsningen til et program som kan kjøres på maskinen;

vedlikehold av programmet, dvs. en pågående prosess med feilsøking av programmet og tilsetning av nye funksjoner.

Figur: 1. Fire trinn for programmering.

Programmering starter fra det øyeblikket da bruker, dvs. den som trenger programmet for å løse problemet, presenterer problemet system analytiker. Brukeren og systemanalytikeren definerer i fellesskap problemstillingen. Sistnevnte overføres deretter algoritmistsom er ansvarlig for å utforme løsningen. En løsning (eller algoritme) representerer en sekvens av operasjoner, hvis utførelse fører til en løsning på et problem. Siden algoritmen ofte ikke er tilpasset for å kjøre på en maskin, må den oversettes til et maskinprogram. Denne operasjonen utføres av koderen. Vedlikeholderen er ansvarlig for påfølgende endringer i programmet. programmerer. En systemanalytiker, en algoritmist, en koder og en medfølgende programmerer er alle programmerere.

I tilfelle et stort programvareprosjekt kan antall brukere, systemanalytikere og algoritmer være betydelig. I tillegg kan det være nødvendig å gå tilbake til de forrige trinnene på grunn av uforutsette omstendigheter. Alt dette legger til argumentet for nøye programvaredesign: resultatene av hvert trinn må være fullstendige, nøyaktige og forståelige.

1.1.1 Problemstilling

Et av de viktigste trinnene i programmering er problemdefinisjon. Det fungerer som en kontrakt mellom brukeren og programmereren (e). Som en juridisk dårlig skrevet kontrakt, er dårlig problemstilling ubrukelig. Med en god formulering av oppgaven representerer både brukeren og programmereren tydelig og utvetydig oppgaven som må utføres, dvs. i dette tilfellet tas hensynet til både brukeren og programmereren. Brukeren kan planlegge å bruke programvare som ennå ikke er opprettet, basert på kunnskapen om at den kan. En god formulering av problemet tjener som grunnlag for dannelsen av løsningen.

Formulering av problemet (programspesifikasjon); betyr egentlig en nøyaktig, fullstendig og forståelig beskrivelse av hva som skjer når et bestemt program kjøres. Brukeren ser vanligvis på datamaskinen som om det var en svart boks: det spiller ingen rolle for ham hvordan datamaskinen fungerer, men det som betyr noe er hva datamaskinen kan gjøre for brukeren. Fokuset er på menneske-maskin-interaksjon.

Kjennetegn ved en god oppgaveerklæring:

Nøyaktighet, dvs. eliminering av enhver tvetydighet. Det burde ikke være spørsmål om hva resultatet av programmet vil være for en gitt inngang.

Fullstendighet, dvs. vurderer alle alternativene for en gitt inngang, inkludert feil eller utilsiktet inngang, og bestemmer riktig utgang.

Klarhet, dvs. det skal være forståelig for både brukeren og systemanalytikeren, siden uttalelsen om problemet er den eneste kontrakten mellom dem.

Ofte er kravet om nøyaktighet, fullstendighet og klarhet i konflikt. For eksempel er mange juridiske dokumenter vanskelige å forstå fordi de er skrevet på et formelt språk som lar deg formulere visse bestemmelser ekstremt nøyaktig, unntatt eventuelle mindre avvik. For eksempel er noen spørsmål på eksamensbilletter noen ganger så presise at studenten bruker mer tid på å forstå spørsmålet enn å svare på det. Videre kan det hende at studenten ikke fatter hovedets betydning av spørsmålet i det hele tatt på grunn av det store antallet detaljer. Den beste formuleringen av problemet er den som oppnår en balanse mellom alle tre kravene.

Standardformen for problemstillingen.

Tenk på følgende problemstilling: "Skriv inn tre tall og skriv ut tallene i rekkefølge."

Denne formuleringen oppfyller ikke kravene ovenfor: den er verken presis, fullstendig eller forståelig. Skal tallene skrives inn ett per linje eller alle tallene på en linje? Betyr uttrykket "i rekkefølge" rekkefølgen fra høyeste til laveste, laveste til høyeste, eller samme rekkefølge som de ble introdusert i.

Åpenbart svarer en slik formulering ikke på mange spørsmål. Hvis vi tar hensyn til svarene på alle spørsmålene, vil uttalelsen om problemet bli ordentlig og vanskelig å forstå. Derfor foreslår D. Riley å bruke et standardskjema for å sette problemet, som gir maksimal nøyaktighet, fullstendighet, klarhet og inkluderer:

oppgavens navn (skjematisk definisjon);

generell beskrivelse (kort redegjørelse for problemet);

feil (uvanlige inputalternativer er eksplisitt oppført for å vise brukere og programmerere hva maskinen vil ta i slike situasjoner);

eksempel ( godt eksempel kan formidle essensen av problemet, og også illustrere ulike tilfeller).

Eksempel. Problemstilling i standardform.

NAVN

Sortering av tre heltall.

BESKRIVELSE

Angi og send ut tre heltall, sortert fra laveste til høyeste.

Tre heltall skrives inn, ett tall per linje. I dette tilfellet er et heltall ett eller flere desimaltegn, som kan innledes med et plusstegn "+" eller et minustegn "-".

De tre angitte heltallene vises, med alle tre på en linje. Skil tilgrensende tall med et mellomrom. Tallene vises fra laveste til høyeste, fra venstre til høyre.

1) Hvis mindre enn tre tall er tastet inn, venter programmet på ytterligere inndata.

2) Andre inngangslinjer enn de tre første ignoreres.

3) Hvis noen av de tre første linjene inneholder mer enn ett heltall, avsluttes programmet og viser en melding.

Programvareutvikling er umulig uten å forstå den såkalte livssyklusen til programvaren. En vanlig bruker trenger kanskje ikke å vite dette, men det er ønskelig å lære de grunnleggende standardene (det vil bli sagt senere hvorfor dette er nødvendig).

Livssyklus hva er det i en formell forstand?

Under livssyklusen til enhver er det vanlig å bety tidspunktet for dets eksistens, fra utviklingsstadiet til øyeblikket for fullstendig avvisning av bruk i det valgte applikasjonsfeltet, opp til fullstendig tilbaketrekking av applikasjonen fra bruk.

For å si det enkelt, informasjonssystemer i form av programmer, databaser eller til og med "operativsystemer" er bare etterspurt hvis dataenes relevans og mulighetene de gir.

Det antas at definisjonen av en livssyklus ikke på noen måte gjelder testapplikasjoner, for eksempel betaversjoner, som er de mest ustabile i produksjonen. Selve programvarens livssyklus avhenger av mange faktorer, blant hvilke en av hovedrollene spilles av miljøet der programmet skal brukes. Det er imidlertid mulig å skille ut generelle forhold som brukes til å definere begrepet livssyklus.

Innledende krav

• formulering av problemet;
• analyse av gjensidige krav til fremtidig programvare for systemet;
• design;
• programmering;
• koding og kompilering;
• testing;
• feilsøking;
• implementering og vedlikehold av et programvareprodukt.

Programvareutvikling består av alle trinnene ovenfor og kan ikke klare seg uten minst en av dem. Men for å kontrollere slike prosesser etableres spesielle standarder.

Programvare livssyklus prosessstandarder

Blant systemene som forhåndsbestemmer betingelsene og kravene til slike prosesser, kan vi i dag bare nevne tre hoved:

• GOST 34.601-90;
• ISO / IEC 12207: 2008;
• Oracle CDM.

For det andre internasjonal standard det er en russisk analog. Dette er GOST R ISO / IEC 12207-2010, som er ansvarlig for system- og programvareteknikk. Men programvarens livssyklus som er beskrevet i begge reglene, er i det vesentlige identisk. Dette forklares ganske enkelt.

Typer programvare og oppdateringer

Forresten, for de fleste av de nå kjente multimedieprogrammene er de middel til å lagre de grunnleggende konfigurasjonsparametrene. Bruken av denne typen programvare er selvfølgelig ganske begrenset, men å forstå de generelle prinsippene for å jobbe med de samme mediaspillerne skader ikke. Og det er derfor.

Faktisk er programvarens livssyklus i dem bare fastsatt på nivået av oppdateringsperioden for versjonen av selve spilleren eller installasjonen av kodeker og dekodere. Og lyd- og video-transkodere er viktige egenskaper for lyd- eller videosystemer.

Eksempel basert på FL Studio-program

Den originale virtuelle sequenceren til FL Studio ble kalt Fruity Loops. Livssyklusen til programvaren i den første endringen har utløpt, men applikasjonen har blitt noe transformert og fått sin nåværende form.

Hvis vi snakker om stadiene i livssyklusen, var det for det første på tidspunktet for problemstillingen satt flere forutsetninger:

• lage en trommemodul som ligner på rytmemaskiner som Yamaha RX, men ved hjelp av one-shot prøver eller WAV-sekvenser spilt inn i live studio;
• integrering i oS Windows;
• muligheten til å eksportere et prosjekt i WAV-, MP3- og OGG-formater;
• kompatibilitet av prosjekter med tilleggsprogrammet Fruity Tracks.

På utviklingsstadiet ble midlene til programmeringsspråk "C" brukt. Men plattformen så ganske primitiv ut og ga ikke sluttbrukeren ønsket kvalitet høres ut.

I denne forbindelse måtte utviklerne på scenen for testing og feilsøking følge banen til det tyske selskapet Steinberg og bruke Full Duplex-modusstøtte i kravene til hovedlyddriveren. Lydkvaliteten ble forbedret og tillatt å endre tempo, tonehøyde og bruke ekstra FX-effekter i sanntid.

Avslutningen på livssyklusen til denne programvaren anses å være utgivelsen av den første offisielle versjonen av FL Studio, som i motsetning til forfedrene allerede hadde et fullverdig sequencer-grensesnitt med muligheten til å redigere parametere på en virtuell 64-kanals miksekonsoll med ubegrenset tillegg av lydspor og MIDI-spor.

Dette var ikke slutten på det. På stadium av prosjektledelse ble det introdusert støtte for tilkobling av plugin-moduler i VST-formatet (først den andre og deretter den tredje versjonen), en gang utviklet av Steinberg. Grovt sett kan enhver virtuell synthesizer som støtter VST-vert være koblet til programmet.

Ikke overraskende kunne snart enhver komponist bruke analoger av "jern" -modeller, for eksempel komplette sett med lyder fra den en gang så populære Korg M1. Dessuten. Bruken av moduler som Addictive Drums eller den allsidige Kontakt-plugin-modulen tillot reproduksjon av live lyder fra virkelige instrumenter, spilt inn med alle nyanser av artikulasjon i profesjonelle studioer.

Samtidig prøvde utviklerne å oppnå maksimal kvalitet ved å skape støtte for ASIO4ALL-drivere, som viste seg å være hode og skuldre over Full Duplex-modus. Følgelig har bithastigheten også økt. I dag er kvaliteten på den eksporterte lydfil kan være 320 kbps ved 192 kHz samplingsfrekvens. Og dette er profesjonell lyd.

Når det gjelder første versjon, kan livssyklusen kalles helt ferdig, men denne uttalelsen er relativ, siden applikasjonen bare har endret navn og fått nye muligheter.

Utviklingsutsikter

Det er allerede klart hva stadiene i programvarens livssyklus er. Men utviklingen av slike teknologier er verdt å nevne separat.

Det er unødvendig å si at noen programvareutvikler ikke er interessert i å lage et flyktig produkt som neppe vil være på markedet i flere år. På lang sikt ser alle på den langsiktige bruken. Dette kan oppnås på forskjellige måter. Men som regel koker nesten alle av dem utgivelsen av oppdateringer eller nye versjoner av programmer.

Selv i tilfelle Windows kan slike trender sees med det blotte øye. Det er knapt en enkelt bruker i dag som bruker systemer som modifikasjoner 3.1, 95, 98 eller Millennium. Livssyklusen deres ble avsluttet etter utgivelsen av XP. Men serverversjoner basert på NT-teknologier er fortsatt relevante. Selv Windows 2000 i dag er ikke bare veldig relevant, men overgår også den siste utviklingen innen noen parametere for installasjon eller sikkerhet. Det samme gjelder NT 4.0, samt en spesialisert modifikasjon av Windows Server 2012.

Men i forhold til disse systemene blir støtte på høyeste nivå fortsatt erklært. Men den oppsiktsvekkende Vista opplever helt klart slutten av syklusen. Ikke bare viste det seg å være uferdig, men det var også så mange feil i seg selv og hull i sikkerhetssystemet at man bare kan gjette hvordan en slik uholdbar løsning kunne ha blitt gitt ut på programvaremarkedet.

Men hvis vi snakker om det faktum at utvikling av programvare av hvilken som helst type (kontroll eller applikasjon) ikke står stille, er det bare mulig. Tross alt gjelder det i dag ikke bare datasystemer, men også mobile enheterder teknologi ofte ligger foran datasektoren. Fremveksten av prosessorbrikker basert på åtte kjerner er ikke mest beste eksempel? Og likevel kan ikke alle bærbare datamaskiner skryte av tilstedeværelsen av slik "maskinvare".

Noen ekstra spørsmål

Når det gjelder forståelsen av programvarens livssyklus, kan det sies at den endte på et bestemt tidspunkt, det kan være veldig betinget, fordi programvareprodukter fortsatt har støtte fra utviklerne som opprettet dem. Snarere henviser slutten til eldre applikasjoner som ikke oppfyller kravene moderne systemer og kan ikke jobbe i sitt miljø.

Men selv med tanke på teknisk fremgang, kan mange av dem vise seg å være uholdbare i nær fremtid. Da må du ta en beslutning enten om utgivelsen av oppdateringer, eller om en fullstendig revisjon av hele konseptet som opprinnelig ble innlemmet i programvareproduktet. Derfor - og en ny syklus som sørger for en endring i de opprinnelige forholdene, utviklingsmiljøet, testing og mulig langvarig bruk i et bestemt område.

Men i datateknologier i dag foretrekkes utvikling av automatiserte kontrollsystemer (ACS), som brukes i produksjonen. Selv operativsystemer er dårligere i forhold til spesialiserte programmer.

Disse samme Visual Basic-miljøene forblir mye mer populære enn Windows-systemer. Og vi snakker ikke i det hele tatt om applikasjonsprogramvare for UNIX-systemer. Hva kan jeg si, hvis praktisk talt alle kommunikasjonsnettverk i de samme USA jobber utelukkende med dem. Forresten, systemer som Linux og Android ble opprinnelig også opprettet på denne plattformen. Derfor, mest sannsynlig, har UNIX mye mer potensial enn resten av produktene til sammen.

I stedet for en total

Det gjenstår å legge til det i i dette tilfellet bare gitt generelle prinsipper og stadier av programvarens livssyklus. Faktisk kan selv de opprinnelige oppgavene variere veldig betydelig. Følgelig kan forskjeller observeres på andre stadier.

Men de grunnleggende teknologiene for utvikling av programvareprodukter med påfølgende vedlikehold bør være tydelige. For resten bør man ta hensyn til detaljene til programvaren som blir opprettet, og miljøene den skal fungere i, og funksjonene til programmene som blir gitt til sluttbrukeren eller produksjonen, og mye mer.

I tillegg kan noen ganger livssykluser avhenge av relevansen av utviklingsverktøy. Hvis for eksempel noe programmeringsspråk blir utdatert, vil ingen skrive programmer basert på det, og enda mer - introdusere dem i automatiserte styringssystemer i produksjonen. Her kommer ikke engang programmerere i forgrunnen, men markedsførere som må svare i tide på endringer i datamaskinmarkedet. Og det er ikke så mange slike spesialister i verden. Høyt kvalifisert personell som kan holde fingeren på pulsen på markedet, blir mest etterspurt. Og de er ofte de såkalte " grå kardinaler»Hvilken suksess eller fiasko for et bestemt programvareprodukt i IT-området avhenger av.

Selv om de ikke alltid forstår essensen av programmering, er de tydelig i stand til å bestemme modellene for programvarens livssyklus og varigheten av applikasjonen, basert på verdens trender på dette området. Effektiv styring gir ofte mer håndgripelige resultater. Ja, i det minste PR-teknologier, reklame osv. Brukeren trenger kanskje ikke noe program, men hvis det blir aktivt annonsert, vil brukeren installere det. Dette er så å si et underbevissthetsnivå (den samme effekten av den 25. rammen når informasjon blir satt inn i bevisstheten til brukeren uavhengig av seg selv).

Selvfølgelig er slike teknologier forbudt i verden, men mange av oss er ikke engang klar over at de fremdeles kan brukes og påvirke underbevisstheten på en bestemt måte. Akkurat hva er "zombie" -nyhetskanalene eller nettsteder, for ikke å nevne bruken av kraftigere midler, for eksempel eksponering for infralyd (dette ble brukt i en operaproduksjon), som et resultat av at en person kan oppleve frykt eller upassende følelser.

Når vi går tilbake til programvaren, er det verdt å legge til at noen programmer bruker et pip når de startes for å tiltrekke brukerens oppmerksomhet. Og som forskning viser, er disse applikasjonene mer levedyktige enn andre programmer. Naturligvis øker livssyklusen til programvaren, uansett hvilken funksjon som tilordnes den i utgangspunktet. Og dette blir dessverre brukt av mange utviklere, noe som reiser tvil om lovligheten av slike metoder.

Men det er ikke for oss å bedømme dette. Kanskje, i nær fremtid, vil det bli utviklet midler for å identifisere slike trusler. Så langt er dette bare en teori, men ifølge noen analytikere og eksperter tidligere praktisk anvendelse det er veldig lite igjen. Hvis de allerede lager kopier av nevrale nettverk i den menneskelige hjerne, hva skal jeg da si?