Hva menes med livssyklusen til et programvaresystem. Program livssyklus

Merknad.

Introduksjon.

1. Programvarens livssyklus

Introduksjon.

Riley-programmeringsprosesstrinn

Introduksjon.

1.1.1. Formulering av problemet.

1.1.2. Løsningsdesign.

1.1.3. Algoritmekoding.

1.1.4. Programstøtte.

1.1.5. Programvaredokumentasjon.

Konklusjon til punkt 1.1

1.2. Definisjon av ZhTsPO 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 verk av livssyklusprogrammet ifølge Boehm

1.3.1. kaskade modell.

1.3.2. Økonomisk underbyggelse av kaskademodellen.

1.3.3. Forbedring av kaskademodellen.

1.3.4. Definisjon av livssyklusfaser.

1.3.5. Grunnarbeid på prosjektet.

Litteratur.

Introduksjon

Den industrielle bruken av datamaskiner og den økende etterspørselen etter programmer har satt presserende oppgaver for en betydelig økning i programvareutviklingsproduktivitet, utvikling av industrielle metoder for planlegging og utforming av programmer, overføring av organisatoriske, tekniske, tekniske, økonomiske og sosiopsykologiske teknikker, mønstre og metoder fra sfæren av materialproduksjon til sfæren av datamaskiner. En kompleks tilnærming til prosessene for utvikling, drift og vedlikehold av programvare fremsatt en rekke presserende problemer, hvis løsning vil eliminere "flaskehalsene" i utformingen av programmer, redusere gjennomføringstiden, forbedre utvalget og tilpasningen av eksisterende programmer, og kanskje bestemme skjebnen til systemer med innebygde datamaskiner.

I praksisen med å utvikle store programvareprosjekter er det ofte ingen enhetlig tilnærming til evaluering av lønnskostnader, arbeidsvilkår og materialkostnader, noe som hindrer økningen i produktiviteten til programvareutvikling, og til slutt effektiv styring av programvarens livssyklus. Siden et program av noe slag blir et produkt (unntatt kanskje pedagogiske, mock-up-programmer), bør tilnærmingen til produksjonen på mange måter være lik tilnærmingen til produksjonen av industrielle produkter, og problemer med programvaredesign blir ekstremt viktige . Denne ideen ligger til grunn for B.U. Boehm "Engineering Software Design", som vi brukte når vi skrev denne semesteroppgaven. I denne boken refererer programvaredesign til prosessen med å lage et design for et programvareprodukt.

1 Programvarens livssyklus

INTRODUKSJON

LCPE er en kontinuerlig prosess som starter fra det øyeblikket det tas en beslutning om behovet for å lage programvare og slutter i det øyeblikket den er fullstendig trukket ut av drift.

Det er flere tilnærminger for å definere fasene og aktivitetene til programvarens livssyklus (SLLC), programmeringsprosesstrinn, fossefall og spiralmodeller. Men de inneholder alle vanlige grunnleggende komponenter: problemformulering, løsningsdesign, implementering, vedlikehold.

Den mest kjente og komplette er kanskje strukturen til livssyklusen ifølge Boehm, som inkluderer åtte faser. Det vil bli presentert mer detaljert senere.

Et av de mulige alternativene kan være beskrivelsen av det øvre nivået ifølge Lehman, som inkluderer tre hovedfaser og representerer beskrivelsen av livssyklusprogrammet i det mest generelle tilfellet.

Og for en endring, her er trinnene i programmeringsprosessen presentert av D. Riley i boken "Using the Modula-2 Language". Denne ideen, etter min mening, er veldig enkel og kjent, og vi starter med den.

1.1 Riley-programmeringsprosesstrinn

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 stilt problem (generelt sett er en slik løsning mindre formell enn det endelige programmet);

programkoding, dvs. oversettelse av den utformede løsningen til et program som kan kjøres på en maskin;

programstøtte, dvs. en pågående prosess med å fikse feil i programmet og legge til nye funksjoner.

Ris. 1. Fire programmeringstrinn.

Programmering starter fra det øyeblikket da bruker, dvs. noen som trenger et program for å løse et problem, utgjør et problem system analytiker. Brukeren og systemanalytikeren definerer i fellesskap problemstillingen. Sistnevnte overføres deretter algoritmist hvem som er ansvarlig for utforming av løsningen. En løsning (eller algoritme) er en sekvens av operasjoner, hvis utførelse fører til løsning av et problem. Siden algoritmen ofte ikke er tilpasset for å bli utført på en maskin, bør den oversettes til et maskinprogram. Denne operasjonen utføres av koderen. Den medfølgende programmereren er ansvarlig for senere endringer i programmet. Og systemanalytikeren, og algoritmen, og koderen, og den medfølgende programmereren - de er alle programmerere.

Når det gjelder et stort programvareprosjekt, kan antallet brukere, systemanalytikere og algoritmer være betydelig. I tillegg kan det være nødvendig å gå tilbake til tidligere trinn på grunn av uforutsette omstendigheter. Alt dette tjener som et tilleggsargument til fordel for nøye programvaredesign: resultatene av hvert trinn skal være fullstendige, nøyaktige og forståelige.

1.1.1 Redegjørelse av problemet

Et av de viktigste trinnene i programmering er å sette et problem. Den fungerer som en kontrakt mellom brukeren og programmereren(e). Som en juridisk dårlig utformet kontrakt, er en dårlig oppdragserklæring ubrukelig. Med en god problemstilling representerer både bruker og programmerer klart og entydig oppgaven som skal utføres, d.v.s. i dette tilfellet tas hensyn til både brukerens og programmererens interesser. Brukeren kan planlegge å bruke programvaren som ennå ikke er opprettet, basert på kunnskapen om at den kan. En god beskrivelse av problemet tjener som grunnlag for dannelsen av løsningen.

Formulering av problemet (programspesifikasjon); betyr i hovedsak 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 en svart boks: det spiller ingen rolle for ham hvordan datamaskinen fungerer, men det er viktig at datamaskinen kan gjøre det brukeren er interessert i. Fokus er på samspillet mellom menneske og maskin.

Kjennetegn på en god problemstilling:

Nøyaktighet, dvs. utelukkelse av enhver tvetydighet. Det bør ikke være noen tvil om hva utgangen av programmet vil være for en gitt inngang.

fullstendighet, dvs. vurdere alle alternativer for en gitt input, inkludert feilaktig eller uventet input, og bestemme riktig utgang.

Klarhet, dvs. det bør være forståelig for både brukeren og systemanalytikeren, siden problemformuleringen er den eneste kontrakten mellom dem.

Ofte er kravene til nøyaktighet, fullstendighet og klarhet i konflikt. Derfor er mange juridiske dokumenter vanskelige å forstå fordi de er skrevet på et formelt språk som lar deg formulere visse bestemmelser med den største presisjon, og ekskluderer selv de mest ubetydelige avvik. For eksempel er noen spørsmål på eksamensoppgaver noen ganger formulert så presist at studenten bruker mer tid på å forstå spørsmålet enn å svare på det. Dessuten kan det hende at studenten ikke forstår hovedbetydningen av spørsmålet i det hele tatt på grunn av det store antallet detaljer. Den beste problemformuleringen er den som oppnår en balanse mellom alle tre kravene.

Standardformen for problemstilling.

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

En slik uttalelse tilfredsstiller ikke kravene ovenfor: den er verken presis, komplett eller forståelig. Faktisk, bør tallene skrives inn ett per linje, eller alle tallene på én linje? Betyr uttrykket "i rekkefølge" rekkefølge fra størst til minste, fra minste til største, eller samme rekkefølge som de ble lagt inn i.

Det er åpenbart at en slik uttalelse ikke svarer på mange spørsmål. Hvis vi tar i betraktning svarene på alle spørsmålene, vil problemstillingen bli ordrik og vanskelig å forstå. Derfor foreslår D. Riley å bruke standardskjemaet for å sette problemet, som sikrer maksimal nøyaktighet, fullstendighet, klarhet og inkluderer:

oppgavenavn (skjematisk definisjon);

generell beskrivelse (kort redegjørelse for oppgaven);

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

eksempel (et godt eksempel kan formidle essensen av problemet, samt illustrere forskjellige tilfeller).

Eksempel. Redegjørelse av problemet i standardskjemaet.

TITTEL

Sorter tre heltall.

BESKRIVELSE

Inndata og utdata for tre heltall, sortert fra minste til største.

Tre heltall legges inn, ett tall per linje. I dette tilfellet er et heltall ett eller flere påfølgende desimalsiffer, som kan innledes med et plusstegn "+" eller et minustegn "-".

De tre angitte heltallene blir utgitt, med alle tre vist på samme linje. Tilstøtende tall er atskilt med et mellomrom. Tall vises fra minste til største, fra venstre til høyre.

1) Hvis mindre enn tre tall legges inn, venter programmet på ytterligere inntasting.

Programvarens livssyklus

Programvarens livssyklus er en tidsperiode som starter fra det øyeblikket en beslutning tas om behovet for å lage et programvareprodukt og slutter i det øyeblikket det fullstendig trekkes ut av drift. (IEEE Std 610.12)

Behovet for å bestemme stadiene i programvarens livssyklus (LC) skyldes utviklernes ønske om å forbedre kvaliteten på programvaren gjennom optimal utviklingsstyring og bruk av ulike kvalitetskontrollmekanismer på hvert trinn, fra oppgaveinnstilling til programvareforfatterstøtte . Den mest generelle representasjonen av programvarens livssyklus er en modell i form av grunnleggende stadier - prosesser, som inkluderer:

Systemanalyse og begrunnelse av programvarekrav;

Foreløpig (skisse) og detaljert (teknisk) programvaredesign;

Utvikling av programvarekomponenter, deres integrasjon og programvarefeilsøking generelt;

Testing, prøvedrift og replikering av programvare;

Regelmessig drift av programvaren, vedlikehold av drift og analyse av resultatene;

Vedlikehold av programvare, modifisering og forbedring av den, opprettelse av nye versjoner.

Denne modellen er generelt akseptert og overholder både innenlandske forskriftsdokumenter innen programvareutvikling og utenlandske. Fra et synspunkt for å sikre teknologisk sikkerhet, er det tilrådelig å vurdere mer detaljert funksjonene i representasjonen av stadiene i livssyklusen i utenlandske modeller, siden det er utenlandsk programvare som er den mest sannsynlige bæreren av programvarefeil i sabotasjetype.

Programvarelivssyklusstandarder

GOST 34.601-90

ISO/IEC 12207:1995 (russisk analog - GOST R ISO/IEC 12207-99)

Grafisk representasjon av livssyklusmodeller lar deg visuelt fremheve funksjonene deres og noen egenskaper ved prosesser.

Opprinnelig ble det laget en kaskademodell av livssyklusen, der store stadier begynte etter hverandre ved å bruke resultatene fra tidligere arbeid. Den sørger for sekvensiell implementering av alle stadier av prosjektet i en strengt fastsatt rekkefølge. Overgangen til neste trinn betyr fullstendig fullføring av arbeidet på forrige trinn. Kravene som er definert på kravdannelsesstadiet er strengt dokumentert i form av oppdrag og faste for hele varigheten av prosjektutviklingen. Hvert stadium kulminerer med utgivelsen av et komplett sett med dokumentasjon som er tilstrekkelig til at utviklingen kan fortsettes av et annet utviklingsteam. Unøyaktigheten av ethvert krav eller dets ukorrekte tolkning som et resultat fører til at du må "rulle tilbake" til den tidlige fasen av prosjektet og den nødvendige revisjonen slår ikke bare prosjektgruppen ut av planen, men fører ofte til en kvalitativ økning i kostnader og, det er mulig, til avslutning av prosjektet i den formen det opprinnelig ble unnfanget. Hovedfeilen til forfatterne av fossefallmodellen er antakelsen om at designet går gjennom hele prosessen én gang, den utformede arkitekturen er god og enkel å bruke, utformingen av implementeringen er rimelig, og feil i implementeringen er lett eliminert med testing. Denne modellen forutsetter at alle feil vil være konsentrert i implementeringen, og derfor skjer eliminering av dem jevnt under komponent- og systemtesting. Dermed er fossefallsmodellen for store prosjekter lite realistisk og kan kun effektivt brukes til å lage små systemer.

Den mest spesifikke er spiralmodellen for livssyklusen. I denne modellen er oppmerksomheten fokusert på den iterative prosessen i de innledende stadiene av design. På disse stadiene lages konsepter, kravspesifikasjoner, foreløpig og detaljert design sekvensielt. Ved hver runde spesifiseres innholdet i arbeidet og utseendet til programvaren som lages konsentreres, kvaliteten på de oppnådde resultatene vurderes, og arbeidet med neste iterasjon planlegges. Ved hver iterasjon blir følgende evaluert:

Risikoen for å overskride vilkårene og kostnadene for prosjektet;

Behovet for å utføre en ny iterasjon;

Graden av fullstendighet og nøyaktighet for å forstå kravene til systemet;

Hensiktsmessigheten av å avslutte prosjektet.

Standardisering av programvarens livssyklus utføres i tre retninger. Den første retningen er organisert og stimulert av International Organization for Standardization (ISO – International Standard Organization) og International Electrotechnical Commission (IEC – International Electro-technical Commission). På dette nivået gjennomføres standardisering av de vanligste teknologiske prosessene som er viktige for internasjonalt samarbeid. Den andre retningen utvikles aktivt i USA av Institute of Electrical and Electronics Engineers (IEEE - Institute of Electrotechnical and Electronics Engineers) sammen med American National Standards Institute (ANSI). ISO/IEC- og ANSI/IEEE-standardene er for det meste rådgivende. Den tredje retningen stimuleres av det amerikanske forsvarsdepartementet (Department of Defence-DOD). DOD-standarder er obligatoriske for firmaer som jobber på vegne av det amerikanske forsvarsdepartementet.

For å designe programvare for et komplekst system, spesielt et sanntidssystem, er det tilrådelig å bruke en systemomfattende livssyklusmodell basert på å kombinere alle kjente arbeider innenfor rammen av de vurderte grunnleggende prosessene. Denne modellen er ment for bruk i planlegging, planlegging, administrasjon av ulike programvareprosjekter.

Det er tilrådelig å dele settet med stadier av denne livssyklusmodellen i to deler, som er vesentlig forskjellige i egenskapene til prosessene, tekniske og økonomiske egenskaper og faktorer som påvirker dem.

I første del av livssyklusen gjennomføres systemanalyse, design, utvikling, testing og testing av programvare. Utvalget av verk, deres kompleksitet, varighet og andre egenskaper på disse stadiene avhenger i betydelig grad av objektet og utviklingsmiljøet. Studiet av slike avhengigheter for ulike klasser av programvare gjør det mulig å forutsi sammensetningen og hovedkarakteristikkene til arbeidsplaner for nye versjoner av programvare.

Den andre delen av livssyklusen, som reflekterer støtte for drift og vedlikehold av programvare, er relativt svakt knyttet til egenskapene til objektet og utviklingsmiljøet. Omfanget av arbeid på disse stadiene er mer stabilt, og deres kompleksitet og varighet kan variere betydelig, og avhenge av masseapplikasjonen av programvaren. For enhver livssyklusmodell er det kun mulig å sikre høy kvalitet på programvaresystemer hvis en regulert teknologisk prosess brukes på hvert av disse stadiene. En slik prosess støttes av utviklingsautomatiseringsverktøy, som det er tilrådelig å velge fra eksisterende eller lage under hensyntagen til utviklingsobjektet og listen over arbeider som er passende for det.

Merknad.

Introduksjon.

1. Programvarens livssyklus

Introduksjon.

Riley-programmeringsprosesstrinn

Introduksjon.

1.1.1. Formulering av problemet.

1.1.2. Løsningsdesign.

1.1.3. Algoritmekoding.

1.1.4. Programstøtte.

1.1.5. Programvaredokumentasjon.

Konklusjon til punkt 1.1

1.2. Definisjon av ZhTsPO 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 verk av livssyklusprogrammet ifølge Boehm

1.3.1. kaskade modell.

1.3.2. Økonomisk underbyggelse av kaskademodellen.

1.3.3. Forbedring av kaskademodellen.

1.3.4. Definisjon av livssyklusfaser.

1.3.5. Grunnarbeid på prosjektet.

Litteratur.

Introduksjon

1 Programvarens livssyklus

INTRODUKSJON

LCPE er en kontinuerlig prosess som starter fra det øyeblikket det tas en beslutning om behovet for å lage programvare og slutter i det øyeblikket den er fullstendig trukket ut av drift.

Den mest kjente og komplette er kanskje strukturen til livssyklusen ifølge Boehm, som inkluderer åtte faser. Det vil bli presentert mer detaljert senere.

1.1 Riley-programmeringsprosesstrinn

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 stilt problem (generelt sett er en slik løsning mindre formell enn det endelige programmet);

programkoding, dvs. oversettelse av den utformede løsningen til et program som kan kjøres på en maskin;

programstøtte, dvs. en pågående prosess med å fikse feil i programmet og legge til nye funksjoner.

Ris. 1. Fire programmeringstrinn.

Programmering starter fra det øyeblikket da bruker, dvs. noen som trenger et program for å løse et problem, utgjør et problem system analytiker. Brukeren og systemanalytikeren definerer i fellesskap problemstillingen. Sistnevnte overføres deretter algoritmist hvem som er ansvarlig for utforming av løsningen. En løsning (eller algoritme) er en sekvens av operasjoner, hvis utførelse fører til løsning av et problem. Siden algoritmen ofte ikke er tilpasset for å bli utført på en maskin, bør den oversettes til et maskinprogram. Denne operasjonen utføres av koderen. Vedlikeholderen er ansvarlig for senere endringer i programmet. Programmerer. Og systemanalytikeren, og algoritmen, og koderen, og den medfølgende programmereren - de er alle programmerere.

1.1.1 Redegjørelse av problemet

Kjennetegn på en god problemstilling:

Nøyaktighet, dvs. utelukkelse av enhver tvetydighet. Det bør ikke være noen tvil om hva utgangen av programmet vil være for en gitt inngang.

fullstendighet, dvs. vurdere alle alternativer for en gitt input, inkludert feilaktig eller uventet input, og bestemme riktig utgang.

Klarhet, dvs. det bør være forståelig for både brukeren og systemanalytikeren, siden problemformuleringen er den eneste kontrakten mellom dem.

Standardformen for problemstilling.

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

oppgavenavn (skjematisk definisjon);

generell beskrivelse (kort redegjørelse for oppgaven);

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

eksempel (et godt eksempel kan formidle essensen av problemet, samt illustrere forskjellige tilfeller).

Eksempel. Redegjørelse av problemet i standardskjemaet.

TITTEL

Sorter tre heltall.

BESKRIVELSE

Inndata og utdata for tre heltall, sortert fra minste til største.

Tre heltall legges inn, ett tall per linje. I dette tilfellet er et heltall ett eller flere påfølgende desimalsiffer, som kan innledes med et plusstegn "+" eller et minustegn "-".

De tre angitte heltallene blir utgitt, med alle tre vist på samme linje. Tilstøtende tall er atskilt med et mellomrom. Tall vises fra minste til største, fra venstre til høyre.

1) Hvis mindre enn tre tall legges inn, venter programmet på ytterligere inntasting.

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

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

Programvarens livssyklus

Et av de grunnleggende konseptene for programvaredesignmetodikk er konseptet med programvarens livssyklus (programvarens livssyklus). Livssyklusen til programvare er en kontinuerlig prosess som starter fra det øyeblikket en beslutning tas om behovet for å lage den og slutter i det øyeblikket den fullstendig trekkes ut av drift.

Det viktigste regulatoriske dokumentet som regulerer livssyklusen til programvare er den internasjonale standarden ISO / IEC 12207 (ISO - International Organization of Standardization - International Organization for Standardization, IEC - International Electrotechnical Commission - International Electrotechnical Commission). Den definerer en livssyklusstruktur som inneholder prosessene, aktivitetene og oppgavene som må fullføres under programvareutvikling. I denne standarden Programvare (programvareprodukt) definert som et sett med dataprogrammer, prosedyrer og eventuelt tilhørende dokumentasjon og data. Prosess er definert som et sett med innbyrdes relaterte handlinger som transformerer noe input til output. Hver prosess er preget av visse oppgaver og metoder for deres løsning, innledende data hentet fra andre prosesser og resultater.

Strukturen til programvarens livssyklus i henhold til ISO/IEC 12207-standarden er basert på tre grupper av prosesser:

hovedprosessene i programvarens livssyklus (anskaffelse, forsyning, utvikling, drift, vedlikehold);

hjelpeprosesser som sikrer implementering av hovedprosessene (dokumentasjon, konfigurasjonsstyring, kvalitetssikring, verifisering, sertifisering, vurdering, revisjon, problemløsning);

organisatoriske prosesser (prosjektledelse, opprettelse av prosjektinfrastruktur, definisjon, evaluering og forbedring av selve livssyklusen, opplæring).

Programvare livssyklusmodeller

Livssyklusmodell- en struktur som bestemmer rekkefølgen av utførelse og forholdet mellom stadier og stadier utført gjennom livssyklusen. Livssyklusmodellen avhenger av spesifikasjonene til programvaren og spesifikasjonene til forholdene der sistnevnte er opprettet og fungerer. De viktigste livssyklusmodellene er som følger.

1. Kaskademodell(frem til 70-tallet av XX-tallet) bestemmer den sekvensielle overgangen til neste trinn etter fullføringen av den forrige.

Denne modellen er preget av automatisering av individuelle urelaterte oppgaver, som ikke krever informasjonsintegrasjon og kompatibilitet, programvare, teknisk og organisatorisk grensesnitt.

Verdighet: god ytelse når det gjelder utviklingstid og pålitelighet ved løsning av individuelle problemer.

Feil: ikke aktuelt for store og komplekse prosjekter på grunn av variasjonen av systemkrav over en lang designperiode.

2. Iterativ modell(70-80-tallet av det 20. århundre) tilsvarer "bottom-up" designteknologien. Tillater iterativ retur til forrige trinn etter utførelse av neste trinn;

Modellen sørger for generalisering av de oppnådde designløsningene for individuelle oppgaver til systemomfattende løsninger. I dette tilfellet er det behov for å revidere de tidligere formulerte kravene.

Verdighet: muligheten til raskt å gjøre justeringer i prosjektet.

Feil: med et stort antall iterasjoner øker designtiden, det er avvik i designløsninger og dokumentasjon, og funksjons- og systemarkitekturen til den opprettede programvaren er forvirret. Behovet for å redesigne et gammelt eller lage et nytt system kan oppstå umiddelbart etter implementerings- eller driftsfasen.

3. Spiralmodell(80-90-tallet av det 20. århundre) tilsvarer top-down designteknologi. Forutsetter bruk av en programvareprototype som tillater programvareutvidelse. Utformingen av systemet gjentar syklisk veien fra spesifikasjon av krav til spesifikasjon av programkode.

Ved utforming av systemets arkitektur bestemmes først sammensetningen av funksjonelle delsystemer og systemomfattende problemer løses (organisering av en integrert database, teknologi for innsamling, overføring og akkumulering av informasjon). Deretter formuleres individuelle oppgaver og en teknologi for deres løsning utvikles.

Ved programmering utvikles først hovedprogrammodulene, og deretter modulene som utfører individuelle funksjoner. Først samhandler modulene med hverandre og med databasen, og deretter implementeres algoritmene.

Fordeler:

1. redusere antall iterasjoner og, følgelig, antall feil og inkonsekvenser som må rettes;

2. reduksjon av designtid;

3. forenkling av opprettelse av prosjektdokumentasjon.

Feil: høye kvalitetskrav til det systemomfattende depotet (felles designdatabase).

Spiralmodellen ligger til grunn rasker eller RAD-teknologi (rask applikasjonsutvikling), som innebærer aktiv deltakelse fra sluttbrukerne av det fremtidige systemet i prosessen med opprettelsen. Hovedstadiene i informasjonsteknologi er som følger:

· Analyse og planlegging av informasjonsstrategi. Brukere, sammen med spesialutviklere, deltar i identifiseringen av et problemområde.

· Design. Brukere under veiledning av utviklere deltar i teknisk design.

· Design. Utviklere designer en fungerende versjon av programvaren ved å bruke 4. generasjons språk;

· Gjennomføring. Utviklere trener brukere til å jobbe i det nye programvaremiljøet.

Programvareutvikling er umulig uten å forstå den såkalte programvarens livssyklus. 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).

Hva er livssyklusen i formell forstand?

Under livssyklusen til enhver, er det vanlig å forstå tidspunktet for dens eksistens, fra utviklingsstadiet og til øyeblikket for fullstendig oppgivelse av bruk i det valgte bruksområdet, til fullstendig fjerning av applikasjonen fra bruk.

Enkelt sagt er informasjonssystemer i form av programmer, databaser eller til og med operativsystemer etterspurt bare hvis dataene og mulighetene de gir er relevante.

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

Innledende krav

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

Programvareutvikling består av alle de ovennevnte stadiene og kan ikke klare seg uten minst ett av dem. Men for å kontrollere slike prosesser er det etablert spesielle standarder.

Programvarelivssyklusprosessstandarder

Blant systemene som forhåndsbestemmer betingelsene og kravene til slike prosesser, kan i dag bare tre hovednavn nevnes:

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

Det er en russisk analog for den andre internasjonale standarden. Dette er GOST R ISO / IEC 12207-2010, som er ansvarlig for systemer og programvareutvikling. Men programvarens livssyklus beskrevet i begge reglene er i hovedsak identisk. Dette er ganske enkelt forklart.

Typer programvare og oppdateringer

Forresten, for de fleste kjente multimedieprogrammene er de midler til å lagree. Bruken av denne typen programvare er selvfølgelig ganske begrenset, men å forstå de generelle prinsippene for å jobbe med de samme mediespillerne skader ikke. Og det er derfor.

Faktisk har de en programvarelivssyklus bare på nivået av oppdateringsperioden for versjonen av selve spilleren eller installasjonen av kodeker og dekodere. Og lyd- og videotranskodere er essensielle egenskaper for ethvert lyd- eller videosystem.

Eksempel basert på FL Studio

Opprinnelig ble den virtuelle studiosekvenseren FL Studio kalt Fruity Loops. Livssyklusen til programvaren i dens primære modifikasjon er utløpt, men applikasjonen har blitt noe transformert og har fått sin nåværende form.

Hvis vi snakker om stadiene i livssyklusen, ble det satt flere obligatoriske betingelser til å begynne med, på stadiet av å sette oppgaven:

lage en trommemodul som ligner på rytmemaskiner som Yamaha RX, men ved å bruke one-shot samples eller WAV-sekvenser tatt opp live i studioer;
integrering i Windows-operativsystemer;
muligheten til å eksportere prosjektet i WAV-, MP3- og OGG-formater;
prosjektkompatibilitet med tilleggsapplikasjonen Fruity Tracks.

På utviklingsstadiet ble verktøyene til C-programmeringsspråkene brukt. Men plattformen så ganske primitiv ut og ga ikke sluttbrukeren den nødvendige lydkvaliteten.

I denne forbindelse, på stadiet med testing og feilsøking, måtte utviklerne følge veien til det tyske selskapet Steinberg og bruke støtte for full dupleksmodus i kravene til hovedlyddriveren. Kvaliteten på lyden har blitt høyere og lar deg endre tempo, tonehøyde og bruke ekstra FX-effekter i sanntid.

Slutten av livssyklusen til denne programvaren anses å være utgivelsen av den første offisielle versjonen av FL Studio, som, i motsetning til sine forfedre, 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 begrenset. På prosjektledelsesstadiet ble det introdusert støtte for å koble til plug-ins 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-host koble til programmet.

Det er ikke overraskende at enhver komponist snart kan bruke analoger av "jern"-modeller, for eksempel de komplette settene med lyder fra den en gang så populære Korg M1. Dessuten. Bruken av moduler som Addictive Drums eller den universelle Kontakt-pluginen gjorde det mulig å reprodusere livelydene til ekte instrumenter innspilt med alle nyanser av artikulasjon i profesjonelle studioer.

Samtidig prøvde utviklerne å oppnå maksimal kvalitet ved å lage støtte for ASIO4ALL-drivere, som viste seg å være hode og skuldre over Full Duplex-modus. Følgelig økte også bithastigheten. Til dags dato kan kvaliteten på den eksporterte lydfilen være 320 kbps med en samplingshastighet på 192 kHz. Dette er profesjonell lyd.

Når det gjelder den første versjonen, kan livssyklusen kalles fullstendig ferdig, men en slik uttalelse er relativ, siden applikasjonen bare har endret navn og fått nye funksjoner.

Utviklingsutsikter

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

Unødvendig å si at enhver programvareutvikler ikke er interessert i å lage et flyktig produkt som neppe vil forbli på markedet i noen år. I fremtiden ser alle på den langsiktige bruken. Dette kan oppnås på forskjellige måter. Men som regel kommer nesten alle av dem til utgivelsen av oppdateringer eller nye versjoner av programmer.

Selv når det gjelder Windows, kan slike trender sees med det blotte øye. Det er usannsynlig at det i dag vil være minst én bruker som bruker systemer som modifikasjoner 3.1, 95, 98 eller Millennium. Livssyklusen deres tok slutt etter utgivelsen av XP-versjonen. Men serverversjoner basert på NT-teknologier er fortsatt relevante. Selv Windows 2000 i dag er ikke bare veldig oppdatert, men overgår til og med den siste utviklingen innen enkelte installasjons- eller sikkerhetsparametere. Det samme gjelder NT 4.0-systemet, samt en spesialisert modifikasjon av Windows Server 2012.

Men i forhold til disse systemene er det fortsatt erklært støtte på høyeste nivå. Men den oppsiktsvekkende Vista i sin tid opplever helt klart syklusens tilbakegang. Ikke bare viste det seg å være uferdig, men det var så mange feil i seg selv og hull i sikkerhetssystemet at man bare kan gjette hvordan en så uholdbar løsning kunne slippes ut til programvaremarkedet.

Men hvis vi snakker om det faktum at utviklingen av programvare av enhver type (kontroll eller applikasjon) ikke står stille, er det bare mulig fordi det i dag ikke bare gjelder datasystemer, men også mobile enheter, der teknologiene som brukes ofte er foran datasektoren. Fremveksten av prosessorbrikker basert på åtte kjerner - hvorfor ikke det beste eksemplet? Men ikke alle bærbare datamaskiner kan skryte av å ha en slik maskinvare.

Noen tilleggsspørsmål

Når det gjelder forståelsen av programvarens livssyklus, kan det sies at den endte på et visst tidspunkt, den er veldig betinget, fordi programvareprodukter fortsatt har støtte fra utviklerne som har laget dem. Snarere refererer slutten til eldre applikasjoner som ikke oppfyller kravene til moderne systemer og ikke kan fungere i deres miljø.

Men selv med tanke på teknologisk fremgang, kan mange av dem i nær fremtid vise seg å være uholdbare. Det er da du må ta en beslutning om enten å gi ut oppdateringer, eller å fullstendig revidere hele konseptet som opprinnelig ble innlemmet i programvareproduktet. Derav den nye syklusen, som innebærer å endre startbetingelsene, utviklingsmiljøet, testing og mulig langsiktig bruk i et bestemt område.

Men innen datateknologi i dag foretrekkes utviklingen av automatiserte kontrollsystemer (ACS), som brukes i produksjonen. Selv operativsystemer, sammenlignet med spesialiserte programmer, taper.

De samme Visual Basic-baserte miljøene er fortsatt mye mer populære enn Windows-systemer. Og vi snakker ikke om applikasjonsprogramvare for UNIX-systemer i det hele tatt. Hva kan jeg si, hvis nesten alle kommunikasjonsnettverk i samme USA fungerer utelukkende for dem. Forresten, systemer som Linux og Android ble også opprinnelig laget på denne plattformen. Derfor har UNIX mest sannsynlig mye flere muligheter enn andre produkter til sammen.

I stedet for totalt

Det gjenstår å legge til at i dette tilfellet er bare generelle prinsipper og stadier av programvarens livssyklus gitt. Faktisk kan selv de første 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 klare. For resten bør man ta hensyn til spesifikasjonene til programvaren som lages, miljøene den skal fungere i, og mulighetene til programmene som leveres til sluttbrukeren eller produksjonen, og mye mer.

I tillegg kan noen ganger livssykluser avhenge av relevansen til utviklingsverktøy. Hvis for eksempel et programmeringsspråk blir foreldet, vil ingen skrive programmer basert på det, og enda mer - implementere dem i automatiserte produksjonskontrollsystemer. Her kommer ikke engang programmerere, men markedsførere i forgrunnen, som må reagere i tide på endringer i datamarkedet. Og det er ikke så mange slike spesialister i verden. Høyt kvalifisert personell som er i stand til å holde seg à jour med markedet, blir det mest etterspurte. Og det er de som ofte er de såkalte "grå kardinalene", som suksessen eller fiaskoen til et bestemt programvareprodukt på IT-feltet avhenger av.

Selv om de ikke alltid forstår essensen av programmering, er de tydelig i stand til å bestemme programvarelivssyklusmodeller og varigheten av deres bruk, basert på globale trender på dette området. Effektiv ledelse gir ofte mer håndgripelige resultater. Ja, i det minste PR-teknologier, reklame osv. Brukeren trenger kanskje ikke en applikasjon, men hvis den er aktivt annonsert, vil brukeren installere den. Dette er allerede så å si et underbevisst nivå (den samme effekten av den 25. rammen, når informasjon legges inn i brukerens sinn uavhengig av ham selv).

Selvfølgelig er slike teknologier forbudt i verden, men mange av oss skjønner ikke en gang at de fortsatt kan brukes og påvirke underbevisstheten på en bestemt måte. Hva er "zombifiseringen" av nyhetskanaler eller nettsteder verdt, for ikke å nevne bruken av kraftigere midler, for eksempel infralydeksponering (dette ble brukt i en operaproduksjon), som et resultat av at en person kan oppleve frykt eller utilstrekkelig følelser.

For å gå tilbake til programvaren, er det verdt å legge til at noen programmer bruker et lydsignal ved oppstart for å tiltrekke brukerens oppmerksomhet. Og studier viser at slike applikasjoner er mer levedyktige enn andre programmer. Naturligvis øker også livssyklusen til programvaren, uansett hvilken funksjon den opprinnelig ble tildelt. Og dette brukes dessverre av mange utviklere, noe som reiser tvil om lovligheten av slike metoder.

Men det er ikke opp til oss å dømme dette. Det er mulig at det i nær fremtid vil bli utviklet verktøy for å identifisere slike trusler. Så langt er dette bare en teori, men ifølge noen analytikere og eksperter er det svært lite igjen før praktisk anvendelse. Hvis de allerede lager kopier av de nevrale nettverkene til den menneskelige hjernen, hva kan jeg da si?