Livssyklusen til et informasjonssystem. Stadier av livssyklusen til et teknisk system
i elektroteknikk). Denne standarden definerer strukturen til livssyklusen, og inneholder prosessene, aktivitetene og oppgavene som må utføres under opprettelsen av PS.I denne PS-standarden (eller programvare) er definert som et sett med dataprogrammer, prosedyrer og muligens tilhørende dokumentasjon og data. Prosessen er definert som et sett med innbyrdes relaterte handlinger som transformerer noen inndata til utdata (G. Myers kaller dette dataoversettelse). Hver prosess er preget av visse oppgaver og metoder for deres løsning. På sin side er hver prosess delt inn i et sett med handlinger, og hver handling er delt inn i et sett med oppgaver. Hver prosess, handling eller oppgave initieres og utføres av en annen prosess etter behov, og det er ingen forhåndsbestemte utførelsessekvenser (selvfølgelig, mens inngangsdataforbindelsene opprettholdes).
Det skal bemerkes at i Sovjetunionen, og deretter i Russland, ble opprettelsen av programvare (programvare) opprinnelig, på 70-tallet av forrige århundre, regulert av GOST ESPD-standardene (Unified System for Program Documentation - GOST 19.XXX serie), som var fokusert på klassen relativt enkle programmer lite volum laget av individuelle programmerere. For tiden er disse standardene utdaterte konseptuelt og i form, deres gyldighet er utløpt og bruken er upassende.
Prosessene for å lage automatiserte systemer (AS), som også inkluderer programvare, er regulert av GOST 34.601-90 standarder " Informasjonsteknologi. Sett med standarder for automatiserte systemer. Skapelsesstadier", GOST 34.602-89 "Informasjonsteknologi. Sett med standarder for automatiserte systemer. Teknisk oppgave for å lage et automatisert system" og GOST 34.603-92 "Informasjonsteknologi. Typer tester av automatiserte systemer". Imidlertid er mange bestemmelser i disse standardene utdaterte, mens andre ikke reflekteres nok til å brukes til seriøse prosjekter for opprettelse av PS. Derfor er det tilrådelig å bruke moderne internasjonale standarder i innenlandsk utvikling.
I samsvar med ISO / IEC 12207-standarden er alle livssyklusprosesser for programvare delt inn i tre grupper (fig. 5.1).
Ris. 5.1.
Fem hovedprosesser er definert i gruppene: anskaffelse, forsyning, utvikling, drift og vedlikehold. Åtte delprosesser sikrer gjennomføringen av hovedprosessene, nemlig dokumentasjon, konfigurasjonsstyring, kvalitetssikring, verifisering, validering, felles vurdering, revisjon, problemløsning. De fire organisasjonsprosessene gir styring, infrastrukturbygging, forbedring og læring.
5.2. Hovedprosessene i livssyklusen til PS
Anskaffelsesprosessen består av aktivitetene og oppgavene til kunden som kjøper programvaren. Denne prosessen dekker følgende aktiviteter:
- initiering av anskaffelse;
- utarbeidelse av søknadsforslag;
- utarbeidelse og justering av kontrakten;
- tilsyn med leverandørens aktiviteter;
- aksept og fullføring av arbeid.
Oppkjøpsinitiering inkluderer følgende oppgaver:
- fastsettelse av kundens behov for anskaffelse, utvikling eller forbedring av systemet, programvareprodukter eller tjenester;
- ta en beslutning om anskaffelse, utvikling eller forbedring av eksisterende programvare;
- kontrollere tilgjengeligheten av nødvendig dokumentasjon, garantier, sertifikater, lisenser og støtte ved kjøp av et programvareprodukt;
- utarbeidelse og godkjenning av anskaffelsesplan, herunder systemkrav, kontraktstype, partenes ansvar mv.
Bud må inneholde:
- Systemkrav;
- liste over programvareprodukter;
- vilkår for anskaffelse og avtale;
- tekniske begrensninger (for eksempel på driftsmiljøet til systemet).
Tilbud sendes til en valgt leverandør eller flere leverandører ved anbud. En leverandør er en organisasjon som inngår en kontrakt med en kunde om levering av et system, programvare eller programvaretjeneste på vilkårene spesifisert i kontrakten.
Utarbeidelse og justering av kontrakten omfatter følgende oppgaver:
- fastsettelse av kunden av prosedyren for valg av leverandør, inkludert kriterier for å evaluere forslagene fra mulige leverandører;
- valg av en spesifikk leverandør basert på analyse av forslag;
- forberedelse og konklusjon leverandørkontrakter;
- å gjøre endringer (om nødvendig) i kontrakten i prosessen med implementeringen.
Leverandørens ytelse overvåkes i samsvar med handlingene forutsatt i de felles vurderings- og revisjonsprosessene. Under akseptprosessen utarbeides og utføres nødvendige tester. Fullføring av arbeid under kontrakten utføres i tilfelle tilfredsstillelse av alle akseptbetingelser.
Leveringsprosessen dekker aktivitetene og oppgavene utført av en leverandør som forsyner en kunde med et programvareprodukt eller en tjeneste. Denne prosessen inkluderer følgende trinn:
- levering initiering;
- forberede et svar på bud;
- utarbeidelse av kontrakten;
- kontrakt arbeid planlegging;
- utførelse og kontroll av kontraktsmessige arbeider og deres evaluering;
- levering og ferdigstillelse av arbeider.
Igangsettingen av leveransen består i leverandørens vurdering av tilbudsforslagene og avgjørelsen om de skal samtykke i kravene og betingelsene som er satt eller tilby sine egne (avtalt). Planlegging inkluderer følgende oppgaver:
- ta en beslutning fra leverandøren om utførelse av arbeid på egen hånd eller med involvering av en underleverandør;
- utvikling av leverandøren av en prosjektledelsesplan som inneholder prosjektets organisasjonsstruktur, avgrensning av ansvar, tekniske krav til utviklingsmiljø og ressurser, ledelse av underleverandører mv.
Utviklingsprosessen sørger for aktivitetene og oppgavene som utføres av utvikleren, og dekker arbeidet med å lage programvare og dens komponenter i henhold til spesifiserte krav. Dette inkluderer utarbeidelse av design- og driftsdokumentasjon, utarbeidelse av nødvendige materialer for ytelsestesting, og kvaliteten på programvareprodukter, materiell nødvendig for å organisere opplæring av personalet, etc.
Utviklingsprosessen inkluderer følgende trinn:
- forberedende arbeid;
- analyse av kravene til systemet;
- systemarkitektur design;
- analyse av krav til programvare;
- programvarearkitektur design;
- detaljert programvaredesign;
- programvarekoding og testing;
- programvareintegrasjon;
- programvarekvalifikasjonstesting;
- system integrasjon;
- kvalifikasjonstesting av systemet;
- installasjon av programvare;
- programvare aksept.
Det forberedende arbeidet begynner med valg av en programvarelivssyklusmodell som passer til prosjektets skala, betydning og kompleksitet. Aktivitetene og oppgavene i utviklingsprosessen bør være i samsvar med den valgte modellen. Utbygger skal velge, tilpasse seg forutsetningene for prosjektet og bruke de standarder, metoder og metoder som er avtalt med kunden. utviklingsverktøy, samt utarbeide en arbeidsplan.
Analyse av kravene til systemet innebærer definisjon av dets funksjonalitet, tilpassede krav, krav til pålitelighet, sikkerhet, krav til eksterne grensesnitt, ytelse m.m. Systemkrav vurderes basert på gjennomførbarhetskriterier og etterprøvbarhet under testing.
Utformingen av systemarkitekturen består i å bestemme komponentene til utstyret (maskinvare), programvare og operasjoner utført av personellet som betjener systemet. Systemets arkitektur må samsvare med systemkravene og aksepterte designstandarder og praksis.
Programvarekravanalyse innebærer å bestemme følgende egenskaper for hver programvarekomponent:
- funksjonalitet, inkludert ytelsesegenskaper og driftsmiljø for komponenten;
- eksterne grensesnitt;
- pålitelighets- og sikkerhetsspesifikasjoner;
- ergonomiske krav;
- krav til dataene som brukes;
- krav til installasjon og aksept;
- krav til brukerdokumentasjon;
- krav til drift og vedlikehold.
Programvarekravene vurderes ut fra kriteriene om samsvar med kravene til systemet som helhet, gjennomførbarhet og etterprøvbarhet under testing.
Programvarearkitekturdesign inkluderer følgende oppgaver for hver programvarekomponent:
- transformasjon av programvarekrav til en arkitektur som definerer høy level programvarestruktur og sammensetning av komponentene;
- utvikling og dokumentasjon av programgrensesnitt for programvare og databaser (DB);
- utvikling av en foreløpig versjon av brukerdokumentasjon;
- utvikling og dokumentasjon av forutsetninger for tester og programvareintegrasjonsplan.
Detaljert programvaredesign inkluderer følgende oppgaver:
- beskrivelse av programvarekomponenter og grensesnitt mellom dem på et lavere nivå, tilstrekkelig for påfølgende koding og testing;
- utvikle og dokumentere en detaljert databasedesign;
- oppdatering (om nødvendig) brukerdokumentasjon;
- utvikling og dokumentasjon av testkrav og en plan for testing av programvarekomponenter;
Programvarekoding og testing inkluderer følgende oppgaver:
- koding og dokumentering av hver komponent i programvaren og databasen, samt utarbeidelse av et sett med testprosedyrer og data for å teste dem;
- teste hver komponent av programvaren og databasen for samsvar med kravene til dem, etterfulgt av dokumentasjon av testresultatene;
- oppdatering av dokumentasjon (om nødvendig);
- oppdatering av programvareintegrasjonsplanen.
Programvareintegrasjon sørger for montering av de utviklede programvarekomponentene i samsvar med integrasjons- og testplanen for de aggregerte komponentene. For hver av de aggregerte komponentene utvikles testsuiter og testprosedyrer for å teste hver av kompetansene i påfølgende ferdighetstesting. Et kvalifikasjonskrav er et sett med kriterier eller betingelser som må oppfylles for å kvalifisere. programvare som samsvarer med spesifikasjonene og klar til bruk i felten.
Kvalifikasjonstesting av programvare utføres av utvikleren i nærvær av kunden (
Driftsprosessen dekker aktivitetene og oppgavene til organisasjonen til operatøren som driver systemet. Driftsprosessen inkluderer følgende trinn.
Forberedende arbeid, som inkluderer å utføre følgende oppgaver av operatøren:
- planlegge aktiviteter og arbeid utført under drift, og sette operasjonelle standarder;
- fastsettelse av prosedyrer for lokalisering og løsning av problemer som oppstår under drift.
- Driftstesting utført for hver neste utgave av programvareproduktet, hvoretter denne utgaven overføres til drift.
- Selve driften av systemet, som utføres i miljøet beregnet for dette i henhold til brukerdokumentasjonen.
- analyse av problemer og forespørsler om programvareendring (analyse av meldinger om et problem som har oppstått eller en forespørsel om modifikasjon, vurdering av skalaen, kostnadene for modifikasjon, resulterende effekt, vurdering av muligheten for modifikasjon);
- programvaremodifisering (gjøre endringer i programvareproduktkomponenter og dokumentasjon i samsvar med reglene for utviklingsprosessen);
- verifisering og aksept (med hensyn til integriteten til systemet som endres);
- overføring av programvare til et annet miljø (konvertering av programmer og data, parallell drift av programvare i det gamle og nye miljøet i en viss tidsperiode);
- dekommisjonering av programvaren etter kundens beslutning med deltakelse av driftsorganisasjonen, vedlikeholdstjenesten og brukerne. Samtidig er programvareprodukter og dokumentasjon gjenstand for arkivering i henhold til kontrakten.
Livssyklusen er ikke en eksistensperiode, men en prosess med suksessive endringer i tilstanden, på grunn av typen påvirkninger som produseres (R 50-605-80-93).
Begrepet "systemlivssyklus" forstås vanligvis som evolusjonen nytt system i form av flere ledd, inkludert slike viktige stadier som konsept, utvikling, produksjon, drift og endelig avvikling. :70
Encyklopedisk YouTube
1 / 5
Video 22. Programvarens livssyklus. Stadier av programvareutvikling. klassisk modell programvare utvikling
"Livssyklus til et system eller prosjekt" - opplæring nr. 2.
Produktets livssyklus.mp4
Defekt livssyklus
Organisasjonens livssyklus
Undertekster
Historien om konseptet
Begrepet livssyklus dukket opp på slutten av 1800-tallet. som et kompleks av ideer som inkluderer ideene om arv og utvikling på individ- og organismenivå, samt tilpasning, overlevelse og utryddelse på nivå med individuelle arter og hele populasjoner av levende organismer.
Generiske livssyklusmodeller for systemet
Det er ingen enkelt livssyklusmodell som tilfredsstiller kravene til enhver mulig oppgave. Ulike standardorganisasjoner, offentlige etater og ingeniørmiljøer publiserer sine egne modeller og teknologier som kan brukes til å konstruere modellen. Derfor er det upassende å hevde eksistensen av en mulig algoritme for å bygge en modell. Likevel kan enhver livssyklusmodell deles inn i en rekke grunnleggende trinn som vil reflektere individuelle viktige stadier.
Noen systemingeniører foreslår å vurdere en systemlivssyklusmodell basert på følgende tre kilder: US Department of Defense (DoD) Logistics Management Model (DoD 5000.2), ISO/IEC 15288-modellen og National Society of Professional Engineers (NSPE) modell.). :71
ISO/IEC 15288 Generisk livssyklusmodell
I henhold til standarden er prosessene og aktivitetene i livssyklusen definert, hensiktsmessig konfigurert og brukt i løpet av livssyklusstadiet, for å fullt ut tilfredsstille målene og resultatene på dette stadiet. kan være involvert i ulike stadier av livssyklusen. ulike organisasjoner. Det er ingen enkelt universell modell for systemlivssykluser. Visse stadier av livssyklusen kan være fraværende eller tilstede, avhengig av hvert enkelt tilfelle av systemutvikling. :34
Følgende livssyklusstadier ble gitt som eksempel i standarden:
- Designstadiet.
- Utviklingsstadiet.
- Produksjonsstadiet.
- Søknadsstadiet.
- Søknadsstøttestadiet.
- Stadium for opphør av bruk og avskrivning.
2008-versjonen av standarden (ISO/IEC 15288:2008) inkluderer ikke eksempler på livssyklusstadier.
US Department of Defense Generisk livssyklusmodell
For å håndtere risikoen ved bruk av avansert teknologi, og for å minimere kostbare tekniske eller ledelsesmessige feil, har det amerikanske forsvarsdepartementet utviklet en veiledning som inneholder alle nødvendige prinsipper systemutvikling. Disse prinsippene er inkludert i en spesiell liste over direktiver - DoD 5000.
DoD Logistics Management System Life Cycle Model består av fem stadier:71:
- analyse;
- teknologiutvikling;
- ingeniør- og produksjonsutvikling;
- produksjon og distribusjon;
- drift og støtte.
National Society of Professional Engineers (NSPE) System Life Cycle Reference Model
Denne modellen er tilpasset utvikling av kommersielle systemer. Denne modellen er hovedsakelig fokusert på utvikling av nye produkter, vanligvis resultatet av teknisk fremgang. NSPE-modellen er alternativ utsikt på den amerikanske DoD-versjonsmodellen. Livssyklusen i henhold til NSPE-modellen er delt inn i seks stadier:72:
- konsept;
- teknisk implementering;
- utvikling;
- kommersiell validering og pre-produksjon;
- fullskala produksjon;
- sluttproduktstøtte.
Produktets livssyklusmodell i henhold til R 50-605-80-93
I veiledende dokument R 50-605-80-93 er livssyklusen til et industriprodukt, inkludert militærutstyr, nøye utarbeidet.
For sivile industriprodukter foreslås følgende trinn:
- forskning og design;
- produksjon;
- sirkulasjon og implementering;
- utnyttelse eller forbruk.
Som en del av livssyklusen til sivile industriprodukter, foreslås det å vurdere 73 typer arbeid og 23 typer interessenter («arbeidsdeltakere» i dokumentets terminologi).
For militære industriprodukter foreslås følgende trinn:
- forskning og utvikling begrunnelse;
- utvikling;
- produksjon;
- utnyttelse;
- overhaling.
Som en del av livssyklusen til militærindustriprodukter foreslås det å vurdere 25 typer arbeid og 7 typer interessenter (deltakere i arbeidet).
Generisk programvare livssyklusmodell
Stadiene i systemets livssyklus og deres komponentfaser, presentert i figuren "Systemets livssyklusmodell", refererer til flertallet av komplekse systemer, inkludert de som inneholder programvare med en betydelig mengde funksjonalitet på komponentnivå. I programvareintensive systemer, der programvaren utfører nesten alle funksjoner (som i moderne finansielle systemer, i systemer for bestilling av flybilletter, på det globale Internett, etc.), som regel er livssykluser like i innhold, men er ofte komplisert av iterative prosesser og prototyping. :72-73
Hovedstadier av systemets livssyklus (Kossiakoff, Sweet, Seymour, Biemer)
Som vist i systemets livssyklusmodell, inneholder systemets livssyklusmodell 3 stadier. De to første stadiene er utvikling, og den tredje etappen dekker etterutvikling. Disse stadiene viser de mer generelle overgangene fra stat til stat, i livssyklusen til et system, og viser også endringer i typen og omfanget av aktiviteter involvert i systemutvikling. Etappene er:73:
- konseptutviklingsstadiet;
- stadium av teknisk utvikling;
- etter utviklingsstadiet.
Konseptutviklingsstadiet
Formålet med konseptutviklingsstadiet er å evaluere nye muligheter innen bruksområdet for systemet, utvikle foreløpige Systemkrav og mulige designløsninger. Det konseptuelle designutviklingsstadiet begynner med realiseringen av behovet for å lage et nytt system eller modifisere et eksisterende. Stadiet inkluderer begynnelsen av forskningen av fakta, planleggingsperioden, de økonomiske, tekniske, strategiske og markedsmessige grunnlagene for fremtidige handlinger vurderes. Det er en dialog mellom interessenter og utbyggere. :
Hovedmål for konseptutviklingsstadiet: :74
- Gjennomføre studier for å fastslå hva som er nødvendig for et nytt system, samt for å etablere teknisk og økonomisk gjennomførbarhet av dette systemet.
- Utforsk potensielle systemkonsepter og formuler og valider et sett med systemytelseskrav.
- Velg det mest attraktive systemkonseptet, bestem dets funksjonelle egenskaper, og lag en detaljert plan for de påfølgende stadiene av design, produksjon og operativ utrulling av systemet.
- Utvikle enhver ny teknologi som passer for det valgte systemkonseptet og valider dens evne til å møte behovene.
Stadium av teknisk utvikling
Det tekniske utviklingsstadiet refererer til prosessen med å designe et system for å implementere funksjonene formulert i systemkonseptet til en fysisk implementering som kan støttes og drives med suksess i driftsmiljøet. Systemteknikk er først og fremst opptatt av retningen for utvikling og design, grensesnittadministrasjon, utvikling av testplaner, og bestemmer hvordan avvik i systemytelse som ikke er verifisert under testing og evaluering skal korrigeres på riktig måte. Hovedtyngden av ingeniørvirksomheten utføres på dette stadiet.
Hovedmålene for den tekniske utviklingsfasen er:74:
- Utføre ingeniørutvikling av en systemprototype som oppfyller ytelses-, pålitelighets-, vedlikeholds- og sikkerhetskrav.
- Design et system som er brukbart og demonstrer dets operative egnethet.
Stadium etter utvikling
Etterutviklingsstadiet består av aktiviteter utenfor systemutviklingsperioden, men krever fortsatt betydelig støtte fra systemingeniørene, spesielt når det oppstår uforutsette problemer som må løses så raskt som mulig. I tillegg krever teknologifremskritt ofte interne servicesystemoppgraderinger, som kan være like avhengige av systemutvikling som konseptet og ingeniørstadiene.
Etterutviklingsstadiet av et nytt system begynner etter en vellykket operasjon med testing og evaluering av dette systemet (aksepttesting), utgivelse til produksjon og påfølgende operativ bruk. Inntil større utbygging er fullført, vil systemutvikling fortsette å spille en viktig støtterolle.
Begrepet livssyklus er en av enkle konsepter designmetodikk informasjonssystemer. Livssyklusen til et informasjonssystem er en kontinuerlig prosess som starter! fra det øyeblikket beslutningen om å opprette et informasjonssystem tas og slutter i det øyeblikket det fullstendig trekkes ut av drift.
ISO/IEC 12207-standarden definerer et livssyklusrammeverk som inneholder prosessene, aktivitetene og oppgavene som må utføres under opprettelsen av et informasjonssystem. I henhold til denne standarden er livssyklusstrukturen basert på tre grupper av prosesser:
1. hovedprosessene i livssyklusen (anskaffelse, forsyning, utvikling, drift, vedlikehold);
2. hjelpeprosesser som sikrer gjennomføring av hovedprosessene (dokumentasjon, konfigurasjonsstyring, kvalitetssikring, verifisering, attestering, vurdering, revisjon, problemløsning);
3. organisasjonsprosesser (prosjektledelse, opprettelse av prosjektinfrastruktur, definisjon, evaluering og forbedring av selve livssyklusen, opplæring).
Blant de viktigste livssyklusprosessene er utvikling, drift og vedlikehold av størst betydning. Hver prosess er preget av visse oppgaver og metoder for deres løsning, innledende data; oppnådd på forrige trinn, og resultatene.
1. Utvikling
Utviklingen av et informasjonssystem omfatter alt arbeid med utvikling av informasjonsprogramvare og dets komponenter i henhold til spesifiserte krav. Informasjonsprogramvareutvikling inkluderer også:
1. registrering av design og driftsdokumentasjon;
2. forberedelse av materialer som er nødvendig for å teste skjulte programvareprodukter;
3. utvikling av materiell som er nødvendig for organisering av personalopplæring.
Utvikling er en av de viktigste prosessene i livssyklusen til et informasjonssystem og inkluderer som regel strategisk planlegging, analyse, design og implementering (programmering).
2. Drift
Operativt arbeid kan deles inn i forberedende og hovedarbeid. Forberedelsene inkluderer:
1. konfigurere databasen og brukerarbeidsstasjonene;
2. gi brukere driftsdokumentasjon;
3. opplæring av personalet.
Hoved Vedlikeholdsarbeid inkludere;
1. Direkte drift;
2. lokalisering av problemer og eliminering av deres årsaker;
3. modifikasjon av programvare;
4. utarbeidelse av forslag til forbedring av systemet;
5. utvikling og modernisering av systemet.
3. Eskorte
Tjenester teknisk støtte spiller en svært fremtredende rolle i livet til ethvert bedriftsinformasjonssystem. Tilgjengelighet av kvalifisert Vedlikehold på driftsstadiet av informasjonssystemet er nødvendig tilstand for å løse oppgavene som er tildelt den. Dessuten kan feil fra vedlikeholdspersonell føre til åpenbare eller skjulte økonomiske tap som kan sammenlignes med kostnadene for selve informasjonssystemet.
Livssyklusmodeller
Livssyklusmodellen forstås som en struktur som bestemmer rekkefølgen av utførelse og forholdet mellom prosesser, aktiviteter og oppgaver utført gjennom hele livssyklusen. Livssyklusmodellen avhenger av informasjonssystemets spesifikke egenskaper og forholdene der sistnevnte er skapt og opererer.
Til dags dato er de mest brukte følgende hovedlivssyklusmodeller:
1. oppgavemodell;
2. kaskademodell (eller systemisk) (70-85);
3. spiralmodell (nåværende).
Oppgavemodell
Når man utvikler et system "bottom-up" fra individuelle oppgaver til hele systemet (oppgavemodell), går en enkelt tilnærming til utvikling uunngåelig tapt, det oppstår problemer med informasjonsdokking av individuelle komponenter. Som regel, ettersom antall oppgaver øker, øker vanskelighetene, du må hele tiden endre allerede eksisterende programmer og datastrukturer. Utviklingshastigheten til systemet bremser ned, noe som bremser utviklingen av selve organisasjonen. Men i noen tilfeller kan denne teknologien være passende:
Ekstremt haster (det er nødvendig at i det minste på en eller annen måte blir oppgavene løst; da må du gjøre alt på nytt);
Eksperiment og tilpasning av kunden (algoritmene er ikke klare, løsninger famles ved prøving og feiling).
Den generelle konklusjonen er at det er umulig å lage et tilstrekkelig stort effektivt informasjonssystem på denne måten.
Cascade modell
I de tidlige, ikke veldig store homogene informasjonssystemene, var hver applikasjon en enkelt helhet. For å utvikle denne typen applikasjoner ble det brukt en kaskademetode. Dens hovedkarakteristikk er inndelingen av hele utviklingen i etapper, og overgangen fra et trinn til det neste skjer først etter at arbeidet med den nåværende er fullstendig fullført (fig. 2). Hvert stadium kulminerer med utgivelsen av et komplett sett med dokumentasjon, tilstrekkelig til at utviklingen kan fortsettes av et annet utviklingsteam.
De positive sidene ved å bruke kaskadetilnærmingen er som følger:
på hvert trinn dannes et komplett sett prosjektdokumentasjon, som oppfyller kriteriene for fullstendighet og konsistens;
stadiene av arbeidet utført i en logisk sekvens lar deg planlegge tidspunktet for fullføringen av alt arbeid og de tilsvarende kostnadene.
Ris. . Fossutbyggingsordning
Fossefallstilnærmingen har vist seg i å bygge informasjonssystemer der alle krav helt i begynnelsen av utviklingen kan formuleres ganske nøyaktig og fullstendig for å gi utviklere friheten til å implementere dem best mulig fra et teknisk synspunkt. Denne kategorien inkluderer komplekse oppgjørssystemer, sanntidssystemer og andre lignende oppgaver. I prosessen med å bruke denne tilnærmingen ble det imidlertid oppdaget en rekke av dens mangler, først og fremst forårsaket av det faktum at den virkelige prosessen med å lage systemer aldri passet helt inn i en så rigid ordning. I skapelsesprosessen var det et konstant behov for å gå tilbake til tidligere stadier og avklare eller revidere tidligere beslutninger tatt. Som et resultat tok selve prosessen med å lage programvare neste visning(Fig. 3):
Ris. 3. Den virkelige prosessen med programvareutvikling i henhold til kaskadeordningen
Den største ulempen med kaskadetilnærmingen er en betydelig forsinkelse i å oppnå resultater. Koordinering av resultatene med brukere utføres bare på punktene som er planlagt etter fullføring av hvert trinn i arbeidet, kravene til informasjonssystemer "fryses" i form av en teknisk oppgave for hele opprettelsen. Dermed kan brukere sende inn sine kommentarer først etter at arbeidet med systemet er fullstendig fullført. Hvis kravene ikke er nøyaktig oppgitt eller endret over en lang periode med programvareutvikling, ender brukerne opp med et system som ikke oppfyller deres behov. Modeller (både funksjonelle og informasjonsmessige) av et automatisert objekt kan bli foreldet samtidig med deres godkjenning. Essens systemtilnærming for utviklingen av en IS er dens dekomponering (partisjonering) til automatiserte funksjoner: systemet er delt inn i funksjonelle delsystemer, som igjen er delt inn i underfunksjoner, delt inn i oppgaver, og så videre. Partisjoneringsprosessen fortsetter opp til spesifikke prosedyrer. Samtidig beholder det automatiserte systemet et helhetlig syn der alle komponenter henger sammen. Dermed har denne modellen hovedfordelen med systematisk utvikling, og de største ulempene er trege og dyre.
spiralmodell
For å overvinne disse problemene ble det foreslått en spiral livssyklusmodell (fig. 4), som fokuserer på de innledende stadiene av livssyklusen: analyse og design. På disse stadiene testes gjennomførbarheten av tekniske løsninger ved å lage prototyper. Hver sving av spiralen tilsvarer opprettelsen av et fragment eller en versjon av programvaren, hvor målene og egenskapene til prosjektet er spesifisert, kvaliteten bestemmes, og arbeidet med neste sving av spiralen er planlagt. Dermed blir detaljene i prosjektet utdypet og konsekvent konkretisert, og som et resultat velges et rimelig alternativ som bringes til implementering.
Utvikling ved iterasjoner gjenspeiler den objektivt eksisterende spiralsyklusen for systemoppretting. Ufullstendig fullføring av arbeidet på hvert trinn lar deg gå videre til neste trinn uten å vente på fullstendig ferdigstillelse av arbeidet på den nåværende. Med iterativ utvikling kan det manglende arbeidet fullføres i neste iterasjon. Hovedoppgaven er å vise brukere av systemet et brukbart produkt så raskt som mulig, og dermed aktivere prosessen med å avklare og supplere krav.
Hovedproblemet med spiralsyklusen er å bestemme tidspunktet for overgangen til neste trinn. For å løse det er det nødvendig å innføre tidsbegrensninger for hvert av stadiene i livssyklusen. Overgangen går etter planen, selv om ikke alt planlagt arbeid er gjennomført. Planen er utarbeidet på grunnlag av statistiske data innhentet i tidligere prosjekter, og personlig erfaring utviklere.
Figur 4. Spiralmodell av livssyklusen til IS
En av de mulige tilnærmingene til programvareutvikling innenfor rammen av spirallivssyklusmodellen er i det siste utbredt metodikk for rask applikasjonsutvikling RAD (Rapid Application Development). Dette begrepet er vanligvis forstått som en programvareutviklingsprosess som inneholder 3 elementer:
et lite team med programmerere (fra 2 til 10 personer);
kort, men nøye utarbeidet produksjonsplan (fra 2 til 6 måneder);
en iterativ syklus der utviklere, etter hvert som applikasjonen begynner å ta form, etterspør og implementerer i produktet kravene mottatt gjennom interaksjon med kunden.
Programvarens livssyklus i henhold til RAD-metodikken består av fire faser:
1. fase av kravdefinisjon og analyse;
2. designfase;
3. implementeringsfase;
4. implementeringsfase.
Forelesning 6. Klassifisering av informasjonssystemer
Informasjon System- et sammenkoblet sett med midler, metoder og personell som brukes til å lagre, behandle og utstede informasjon i interessen for å nå målet
Skalaklassifisering
Etter skala er informasjonssystemer delt inn i følgende grupper:
1. singel;
2. gruppe;
3. bedrift.
Enkelte informasjonssystemer implementeres, som regel, på en frittstående personlig datamaskin (nettverket brukes ikke). Et slikt system kan inneholde flere enkle applikasjoner knyttet til et felles informasjonsfond, og er laget for drift av én bruker eller en gruppe brukere som deler én. arbeidsplass. Lignende applikasjoner kan lages ved å bruke det såkalte skrivebordet eller lokale systemer databasebehandling (DBMS). Blant de lokale DBMSene er de mest kjente Clarion, Clipper, FoxPro, Paradox, dBase og Microsoft Access.
Gruppeinformasjonssystemer er fokusert på kollektiv bruk av informasjon av medlemmer av arbeidsgruppen og er oftest bygget på grunnlag av et lokalnettverk. Disse applikasjonene er utviklet ved hjelp av databaseservere (også kalt SQL-servere) for arbeidsgrupper. Det er ganske et stort nummer av ulike SQL-servere, både kommersielle og gratis. Blant dem er de mest kjente databasetjenerne Oracle, DB2, Microsoft SQL Server, InterBase, Sybase, Informix.
Bedriftsinformasjonssystemer er en utvikling av systemer for arbeidsgrupper, de er fokusert på store selskaper og kan støtte geografisk spredte noder eller nettverk. I utgangspunktet har de en hierarkisk struktur på flere nivåer. Slike systemer er preget av en klient-server-arkitektur med spesialisering av servere eller en flernivåarkitektur. Ved utvikling av slike systemer kan de samme databaseserverne brukes som ved utvikling av gruppeinformasjonssystemer. Men i store informasjonssystemer er de mest brukte serverne Oracle, DB2 og Microsoft SQL Server.
For konsern- og bedriftssystemer økes kravene til driftssikkerhet og datasikkerhet betydelig. Disse egenskapene tilveiebringes ved å opprettholde integriteten til data, lenker og transaksjoner i databaseserverne.
Klassifisering etter omfang
I henhold til omfanget av informasjonssystemer er vanligvis delt inn i fire grupper:
1. transaksjonsbehandlingssystemer;
2. beslutningssystemer;
3. informasjons- og referansesystemer;
4. kontorinformasjonssystemer.
Transaksjonsbehandlingssystemer, i sin tur, i henhold til effektiviteten til databehandling, er delt inn i batchinformasjonssystemer og operasjonelle informasjonssystemer. I informasjonssystemer organisatoriske avdelinger modusen for online transaksjonsbehandling råder, for å reflektere oppdatert tilstanden til fagområdet til enhver tid, og batchbehandling opptar en svært begrenset del.
Beslutningsstøttesystemer - DSS (Decision Support Systeq) - er en annen type informasjonssystemer der, ved hjelp av ganske komplekse spørringer, data velges og analyseres i forskjellige seksjoner: tidsmessige, geografiske og andre indikatorer.
Omfattende klasse informasjons- og referansesystemer basert på hypertekstdokumenter og multimedia. Slike informasjonssystemer har fått den største utviklingen på Internett.
Klasse kontorinformasjonssystemer har som mål å oversette papirdokumenter til elektronisk skjema, kontorautomatisering og dokumenthåndtering.
Klassifisering etter organisasjon
I henhold til organisasjonsmetoden er gruppe- og bedriftsinformasjonssystemer delt inn i følgende klasser:
1. systemer basert på filserverarkitektur;
2. systemer basert på klient-server-arkitektur;
3. systemer basert på en flernivåarkitektur;
4. systemer basert på Internett/Intranett-teknologier.
I ethvert informasjonssystem er det mulig å identifisere de nødvendige funksjonelle komponentene som bidrar til å forstå begrensningene til ulike informasjonssystemarkitekturer.
Filserverarkitektur trekker bare ut data fra filer slik at flere brukere og applikasjoner bare legger til en mindre belastning på CPU. Hver ny klient legger til prosessorkraft til nettverket.
Klient-server-arkitektur er designet for å løse problemene med filserverapplikasjoner ved å skille applikasjonskomponenter og plassere dem der de vil fungere mest effektivt. En funksjon ved klient-server-arkitekturen er bruken av dedikerte databaseservere som forstår spørringer i Structured Query Language SQL (Structured Query Language) og søker, sorterer og samler informasjon.
For tiden har klient-server-arkitekturen blitt anerkjent og mye brukt som en måte å organisere applikasjoner for arbeidsgrupper og informasjonssystemer på bedriftsnivå. Denne organiseringen av arbeidet øker effektiviteten av applikasjonskjøring ved å bruke egenskapene til databaseserveren, avlaste nettverket og sikre dataintegritetskontroll.
Lagdelt arkitektur ble utviklingen av klient-server-arkitekturen og består i sin klassiske form av tre nivåer:
1. Det nedre laget er klientapplikasjonene som har et programmeringsgrensesnitt for å kalle applikasjonen i mellomlaget;
2. det midterste laget er en applikasjonsserver;
3. Toppnivået er en ekstern spesialisert databaseserver.
Trelagsarkitekturen balanserer ytterligere belastningen på tvers av forskjellige verter og nettverk, fremmer spesialisering av applikasjonsutviklingsverktøy og eliminerer manglene til tolags klient-server-modellen.
Under utvikling teknologier Internett/intranett hovedvekten så langt er på utvikling av programvareverktøy. Samtidig mangler det utviklet verktøy for å utvikle applikasjoner som fungerer med databaser. En kompromissløsning for å lage praktiske og enkle å bruke og vedlikeholde informasjonssystemer som fungerer effektivt med databaser var kombinasjonen av Internett / Intranett-teknologi med en flernivåarkitektur. I dette tilfellet har strukturen til informasjonsapplikasjonen følgende form: nettleser - applikasjonsserver - databaseserver - dynamisk sideserver - webserver.
I henhold til arten av den lagrede informasjonen er databaser delt inn i saklig og dokumentarer. Hvis vi trekker en analogi med eksemplene på informasjonsdepoter beskrevet ovenfor, er faktografiske databaser arkivskap, og dokumentardatabaser er arkiver. Faktadatabaser lagrer kort informasjon i et strengt definert format. Dokumentardatabaser inneholder alle slags dokumenter. Og det kan ikke bare være det tekstdokumenter men også grafikk, video og lyd (multimedia).
Automatisert kontrollsystem (ACS) er et sett med maskinvare og programvare, sammen med organisasjonsstrukturer(enkeltpersoner eller et team), som gir styring av et objekt (kompleks) i et industrielt, vitenskapelig eller sosialt miljø.
Tildel informasjonssystemer for utdanningsledelse (for eksempel personell, søker, student, bibliotekprogrammer). Automatiserte systemer for Vitenskapelig forskning(ASNI), som er programvare- og maskinvaresystemer som behandler data som kommer fra forskjellige typer forsøksanlegg og måleinstrumenter, og på grunnlag av deres analyse tilrettelegge for oppdagelsen av nye effekter og mønstre Datastøttede designsystemer og geografiske informasjonssystemer.
system kunstig intelligens, bygget på grunnlag av høykvalitets spesialkunnskap om et bestemt fagområde (innhentet fra eksperter - spesialister på dette feltet), kalles et ekspertsystem. Ekspertsystemer - en av få typer kunstig intelligenssystemer - er mye brukt og har funnet praktisk anvendelse. Det er ekspertsystemer for militære anliggender, geologi, ingeniørvitenskap, informatikk, romteknologi, matematikk, medisin, meteorologi, industri, jordbruk, ledelse, fysikk, kjemi, elektronikk, juss, etc. Og bare det faktum at ekspertsystemer forblir svært komplekse, dyre og, viktigst av alt, høyt spesialiserte programmer, hindrer deres enda bredere distribusjon.
Ekspertsystemer (ES) er dataprogrammer, opprettet for å utføre den typen aktiviteter som er innenfor makten til en menneskelig ekspert. De fungerer på en måte som etterligner oppførselen til en menneskelig ekspert, og skiller seg betydelig fra presise, velbegrunnede algoritmer og ligner ikke de matematiske prosedyrene til de fleste tradisjonelle utviklinger.
1. IP livssyklus og dens struktur. 2
1.1 Stadier av IS livssyklus.. 3
1.2 IS livssyklusstandarder.. 4
2. Livssyklusmodeller. 6
2.1 Typer IS-livssyklusmodeller .. 6
2.2 Fordeler og ulemper med IS livssyklusmodeller.. 8
3. Prosesser i IP-livssyklusen ......................................... .... ................... elleve
3.1 Grunnleggende livsløpsprosesser. elleve
3.2 Støtte livssyklusprosesser. tretten
3.3 Organisatoriske prosesser.. 14
Liste over brukt litteratur.. 16
Livssyklusen til et informasjonssystem er en tidsperiode som begynner fra det øyeblikket det tas en beslutning om behovet for å opprette et informasjonssystem og slutter i det øyeblikket det fullstendig trekkes ut av drift.
Begrepet livssyklus er et av de grunnleggende konseptene i metodikken for utforming av informasjonssystemer.
Inbeskriver prosessen med å lage og vedlikeholde systemer i form av en IS-livssyklus (LC), som representerer den som en viss sekvens av stadier og prosesser utført på dem. For hvert trinn bestemmes sammensetningen og rekkefølgen av utført arbeid, oppnådde resultater, metodene og midlene som er nødvendige for å utføre arbeidet, rollene og ansvaret til deltakerne, etc.. En slik formell beskrivelse av livssyklusen til IS gjør det mulig å planlegge og organisere prosessen med kollektiv utvikling og sikre styring av denne prosessen.
Den komplette livssyklusen til et informasjonssystem inkluderer som regel strategisk planlegging, analyse, design, implementering, implementering og drift. Generelt kan livssyklusen igjen deles inn i en rekke stadier. I prinsippet er denne inndelingen i stadier ganske vilkårlig. Vi vil vurdere et av alternativene for en slik divisjon som tilbys av Rational Software Corporation, et av de ledende selskapene på programvaremarkedet for utviklingsverktøy for informasjonssystemer (blant dem Rational Rose universal CASE-verktøyet fortjener stor popularitet).
1.1 Stadier av IP-livssyklusen
Stage - en del av prosessen med å lage en IS, begrenset av en viss tidsramme og slutter med utgivelsen av et spesifikt produkt (modeller, programvarekomponenter, dokumentasjon), bestemt av kravene spesifisert for dette stadiet. Forholdet mellom prosesser og stadier bestemmes også av IS-livssyklusmodellen som brukes.
I henhold til metodikken som tilbys av Rational Software, er livssyklusen til et informasjonssystem delt inn i fire stadier.
Grensene for hvert trinn bestemmes av bestemte tidspunkter hvor det er nødvendig å ta visse kritiske beslutninger og derfor oppnå visse hovedmål.
1) Innledende fase
På det første stadiet omfanget av systemet etableres og grensebetingelsene fastsettes. For å gjøre dette er det nødvendig å identifisere alle eksterne objekter som det utviklede systemet skal samhandle med, og å bestemme arten av denne interaksjonen på et høyt nivå. I den innledende fasen identifiseres alle funksjonsevnene til systemet, og en beskrivelse av de viktigste av dem er laget.
2) Foredlingsstadium
På foredlingsstadiet gjennomføres en analyse av bruksområdet, og det arkitektoniske grunnlaget for informasjonssystemet utvikles.
Når du tar beslutninger angående arkitekturen til systemet, er det nødvendig å ta hensyn til systemet som utvikles som helhet. Dette betyr at det er nødvendig å beskrive det meste av funksjonaliteten til systemet og ta hensyn til forholdet mellom dets individuelle komponenter.
På slutten av avklaringsstadiet gjennomføres en analyse arkitektoniske løsninger og måter å eliminere de viktigste risikofaktorene i prosjektet.
3) Byggetrinn
På designstadiet utvikles et ferdig produkt, klart for overføring til brukeren.
På slutten av dette stadiet bestemmes ytelsen til den utviklede programvaren.
4) Idriftsettelsesstadiet
På idriftsettelsesstadiet overføres den utviklede programvaren til brukerne. Når man bruker det utviklede systemet under reelle forhold, oppstår det ofte ulike typer problemer som krever ekstra arbeidå gjøre justeringer av det utviklede produktet. Dette er vanligvis forbundet med oppdagelse av feil og mangler.
Ved slutten av overleveringsfasen skal det fastslås om utviklingsmålene er nådd eller ikke.
1.2 IP livssyklusstandarder
Moderne nettverk er utviklet på grunnlag av standarder, noe som gjør det mulig å sikre for det første deres høye effektivitet og for det andre muligheten for deres interaksjon med hverandre.
Blant de mest kjente standardene er følgende:
GOST 34.601-90 - gjelder for automatiserte systemer og etablerer stadier og stadier av deres opprettelse. I tillegg inneholder standarden en beskrivelse av arbeidsomfanget på hvert trinn. Stadier og stadier av arbeidet, nedfelt i standarden, er mer i tråd med kaskade-livssyklusmodellen.
ISO / IEC 12207 (International Organization of Standardization / International Electrotechnical Commission) 1995 - en standard for prosesser og livssyklusorganisering. Gjelder alle typer tilpasset programvare. Standarden inneholder ikke beskrivelser av faser, stadier og stadier.
Rational Unified Process (RUP) tilbyr en iterativ utviklingsmodell som inkluderer fire faser: starte, utforske, bygge og distribuere. Hver fase kan brytes ned i stadier (iterasjoner) som resulterer i en utgivelse for intern eller ekstern bruk. Passasjen gjennom fire hovedfaser kalles utviklingssyklusen, hver syklus avsluttes med generering av en versjon av systemet. Hvis arbeidet med prosjektet ikke stopper etter det, fortsetter det resulterende produktet å utvikle seg og går igjen gjennom de samme fasene. Essensen av arbeid innenfor rammen av RUP er opprettelse og vedlikehold av modeller basert på UML.
Microsoft Solution Framework (MSF) ligner på RUP, inkluderer også fire faser: analyse, design, utvikling, stabilisering, er iterativ, involverer bruk av objektorientert modellering. Leger Uten Grenser er mer fokusert på utvikling av forretningsapplikasjoner enn RUP.
Ekstrem programmering (XP). Extreme Programming (den nyeste blant metodene som vurderes) ble dannet i 1996. Metodikken er basert på teamarbeid, effektiv kommunikasjon mellom kunde og entreprenør gjennom hele prosjektet for utvikling av IP, og utvikling utføres ved bruk av suksessive svært raffinerte prototyper.
2. Livssyklusmodeller
IS livssyklusmodellen er en struktur som bestemmer rekkefølgen av utførelse og forholdet mellom prosesser, handlinger og oppgaver gjennom livssyklusen. Livssyklusmodellen avhenger av prosjektets spesifikke, skala og kompleksitet og de spesifikke forholdene som systemet er skapt og fungerer under.
LC IS-modellen inkluderer:
resultatene av arbeidet på hvert trinn;
nøkkelhendelser - punkt for fullføring av arbeid og beslutningstaking.
Livssyklusmodellen reflekterer ulike stater system, fra det øyeblikket behovet for denne IS oppstår og slutter med det øyeblikket den er helt ute av bruk.
2.1 Typer IP-livssyklusmodeller
Følgende livssyklusmodeller er for tiden kjent og brukt:
Kaskademodellen (fig. 2.1) sørger for sekvensiell utførelse av alle prosjektstadier i en strengt fastsatt rekkefølge. Overgangen til neste trinn betyr fullstendig fullføring av arbeidet på forrige trinn.
Etappevis modell med mellomstyring (fig. 2.2). IS-utvikling utføres i iterasjoner med sykluser tilbakemelding mellom stadier. Inter-stage justeringer gjør det mulig å ta hensyn til den reelle gjensidige påvirkningen av utviklingsresultater på ulike stadier; levetiden til hvert av stadiene er strukket for hele utviklingsperioden.
Spiralmodell (fig. 2.3). Ved hver sving av spiralen opprettes neste versjon av produktet, kravene til prosjektet spesifiseres, kvaliteten bestemmes, og arbeidet med neste sving er planlagt. Spesiell oppmerksomhet er gitt til de innledende stadiene av utviklingen - analyse og design, hvor gjennomførbarheten av visse tekniske løsninger kontrolleres og begrunnes gjennom opprettelse av prototyper (prototyping).
Ris. 2.1. Kaskademodell av livssyklusen til IP
Ris. 2.2. Etappevis modell med mellomstyring
Ris. 2.3. Spiralmodell av livssyklusen til IP
I praksis er to hovedlivssyklusmodeller mest brukt:
kaskademodell (typisk for perioden 1970-1985);
spiralmodell (typisk for perioden etter 1986.).
2.2 Fordeler og ulemper med IP livssyklusmodeller
I tidlige prosjekter med ganske enkle IC-er, var hver applikasjon en enkelt, funksjonelt og informasjonsmessig uavhengig enhet. For å utvikle denne typen applikasjoner viste kaskademetoden seg å være effektiv. Hver etappe ble avsluttet etterpå full gjennomføring og dokumentasjon av alle planlagte arbeider.
Livssyklusen til et informasjonssystem er en tidsperiode som begynner fra det øyeblikket det tas en beslutning om behovet for å opprette et informasjonssystem og slutter i det øyeblikket det fullstendig trekkes ut av drift.
Begrepet livssyklus er et av de grunnleggende konseptene i metodikken for utforming av informasjonssystemer.
Inbeskriver prosessen med å lage og vedlikeholde systemer i form av en IS-livssyklus (LC), som representerer den som en viss sekvens av stadier og prosesser utført på dem. For hvert trinn bestemmes sammensetningen og rekkefølgen av utført arbeid, oppnådde resultater, metodene og midlene som er nødvendige for å utføre arbeidet, rollene og ansvaret til deltakerne, etc.. En slik formell beskrivelse av livssyklusen til IS gjør det mulig å planlegge og organisere prosessen med kollektiv utvikling og sikre styring av denne prosessen.
Den komplette livssyklusen til et informasjonssystem inkluderer som regel strategisk planlegging, analyse, design, implementering, implementering og drift. Generelt kan livssyklusen igjen deles inn i en rekke stadier. I prinsippet er denne inndelingen i stadier ganske vilkårlig. Vi vil vurdere et av alternativene for en slik divisjon, som tilbys av Rational Software Corporation, et av de ledende selskapene på programvaremarkedet for utviklingsverktøy for informasjonssystemer (blant dem Rational Rose universal CASE-verktøyet fortjener stor popularitet).
IP livssyklus stadier
Stage - en del av prosessen med å lage en IS, begrenset av en viss tidsramme og slutter med utgivelsen av et spesifikt produkt (modeller, programvarekomponenter, dokumentasjon), bestemt av kravene spesifisert for dette stadiet. Forholdet mellom prosesser og stadier bestemmes også av IS-livssyklusmodellen som brukes.
I henhold til metodikken som tilbys av Rational Software, er livssyklusen til et informasjonssystem delt inn i fire stadier.
Grensene for hvert trinn er definert av bestemte tidspunkter hvor det er nødvendig å ta visse kritiske beslutninger og derfor oppnå visse nøkkelmål.
1) Innledende fase
I det innledende stadiet etableres systemets omfang og grensebetingelsene fastsettes. For å gjøre dette er det nødvendig å identifisere alle eksterne objekter som det utviklede systemet skal samhandle med, og å bestemme arten av denne interaksjonen på et høyt nivå. I den innledende fasen identifiseres alle funksjonsevnene til systemet, og en beskrivelse av de viktigste av dem er laget.
2) Foredlingsstadium
På foredlingsstadiet gjennomføres en analyse av bruksområdet, og det arkitektoniske grunnlaget for informasjonssystemet utvikles.
Når du tar beslutninger angående arkitekturen til systemet, er det nødvendig å ta hensyn til systemet som utvikles som helhet. Dette betyr at det er nødvendig å beskrive det meste av funksjonaliteten til systemet og ta hensyn til forholdet mellom dets individuelle komponenter.
På slutten av avklaringsstadiet gjennomføres en analyse av arkitektoniske løsninger og måter å eliminere hovedrisikofaktorene i prosjektet.
3) Byggetrinn
På designstadiet utvikles et ferdig produkt, klart for overføring til brukeren.
På slutten av dette stadiet bestemmes ytelsen til den utviklede programvaren.
4) Idriftsettelsesstadiet
På idriftsettelsesstadiet overføres den utviklede programvaren til brukerne. Når det utviklede systemet brukes under reelle forhold, oppstår det ofte ulike typer problemer som krever ekstra arbeid for å gjøre justeringer av det utviklede produktet. Dette er vanligvis forbundet med oppdagelse av feil og mangler.
Ved slutten av overleveringsfasen skal det fastslås om utviklingsmålene er nådd eller ikke.
IP livssyklusstandarder
Moderne nettverk er utviklet på grunnlag av standarder, noe som gjør det mulig å sikre for det første deres høye effektivitet og for det andre muligheten for deres interaksjon med hverandre.
Blant de mest kjente standardene er følgende:
GOST 34.601-90 - gjelder for automatiserte systemer og etablerer stadier og stadier av deres opprettelse. I tillegg inneholder standarden en beskrivelse av arbeidsomfanget på hvert trinn. Stadier og stadier av arbeidet, nedfelt i standarden, er mer i tråd med kaskade-livssyklusmodellen.
ISO / IEC 12207 (International Organization of Standardization / International Electrotechnical Commission) 1995 - en standard for prosesser og livssyklusorganisering. Gjelder alle typer tilpasset programvare. Standarden inneholder ikke beskrivelser av faser, stadier og stadier.
Rational Unified Process (RUP) tilbyr en iterativ utviklingsmodell som inkluderer fire faser: starte, utforske, bygge og distribuere. Hver fase kan brytes ned i stadier (iterasjoner) som resulterer i en utgivelse for intern eller ekstern bruk. Passasjen gjennom fire hovedfaser kalles utviklingssyklusen, hver syklus avsluttes med generering av en versjon av systemet. Hvis arbeidet med prosjektet ikke stopper etter det, fortsetter det resulterende produktet å utvikle seg og går igjen gjennom de samme fasene. Essensen av arbeid innenfor rammen av RUP er opprettelse og vedlikehold av modeller basert på UML.
Microsoft Solution Framework (MSF) ligner på RUP, inkluderer også fire faser: analyse, design, utvikling, stabilisering, er iterativ, involverer bruk av objektorientert modellering. Leger Uten Grenser er mer fokusert på utvikling av forretningsapplikasjoner enn RUP.
Ekstrem programmering (XP). Extreme Programming (den nyeste blant metodene som vurderes) ble dannet i 1996. Metodikken er basert på teamarbeid, effektiv kommunikasjon mellom kunde og entreprenør gjennom hele IP-utviklingsprosjektet, og utviklingen utføres ved hjelp av sekvensielt raffinerte prototyper.
spiral livssyklus kaskade