Životni ciklus po počinje u ovom trenutku. Koncept životnog ciklusa softvera. Neka dodatna pitanja

Anotacija.

Uvod.

1. Životni ciklus NA

Uvod.

Riley Koraci procesa programiranja

Uvod.

1.1.1. Formulacija problema.

1.1.2. Dizajn rješenja.

1.1.3. Kodiranje algoritma.

1.1.4. Programska podrška.

1.1.5. Softverska dokumentacija.

Zaključak na stavak 1.1

1.2. Definicija ZhTsPO prema Lehmanu.

Uvod.

1.2.1 Definicija sustava.

1.2.2. Provedba.

1.2.3. Servis.

Zaključak na točku 1.2.

1.3. Faze i radovi programa životnog ciklusa prema Boehmu

1.3.1. kaskadni model.

1.3.2. Ekonomska opravdanost kaskadni model.

1.3.3. Poboljšanje kaskadnog modela.

1.3.4. Definicija faza životnog ciklusa.

1.3.5. Osnovni rad na projektu.

Književnost.

Uvod

Industrijska primjena računala i sve veća potražnja za programima postavili su hitne zadatke za značajno povećanje produktivnost razvoja softvera, razvoj industrijskih metoda za planiranje i projektiranje programa, prijenos organizacijskih, tehničkih, tehničkih, ekonomskih i socio-psiholoških metoda, obrazaca i metoda iz sfere materijalne proizvodnje u sferu računala. Kompleksan pristup procesima razvoja, rada i održavanja softvera postavljaju se brojni gorući problemi, čije će rješenje ukloniti "uska grla" u dizajnu programa, smanjiti vrijeme završetka, poboljšati izbor i prilagodbu. postojeće programe, a možda i odrediti sudbinu sustava s ugrađenim računalima.

U praksi razvoja velikih softverskih projekata često nema jedinstven pristup na procjenu troškova rada, uvjeta rada i troškova materijala, što koči povećanje produktivnosti razvoja softvera, te u konačnici - učinkovito upravljanježivotni ciklus softvera. Budući da program bilo koje vrste postaje proizvod (osim, možda, obrazovnih, mock-up programa), pristup njegovoj proizvodnji trebao bi biti u mnogočemu sličan pristupu proizvodnji industrijskih proizvoda, a pitanja dizajna softvera postaju iznimno važna . Ova ideja je temelj B.U. Boehm "Inženjerski dizajn softver“, koji smo koristili prilikom pisanja ovog teksta seminarski rad. U ovoj se knjizi softverski dizajn odnosi na proces stvaranja dizajna softverskog proizvoda.

1 Životni ciklus softvera

UVOD

LCPE je kontinuirani proces koji počinje od trenutka donošenja odluke o potrebi izrade softvera i završava u trenutku njegovog potpunog povlačenja iz rada.

Postoji nekoliko pristupa definiranju faza i aktivnosti životnog ciklusa softvera (SLLC), koraka procesa programiranja, vodopada i spiralnih modela. Ali svi sadrže zajedničke temeljne komponente: iskaz problema, dizajn rješenja, implementacija, održavanje.

Najpoznatija i najpotpunija je možda struktura životnog ciklusa prema Boehmu, koja uključuje osam faza. Kasnije će biti detaljnije predstavljen.

Jedna od mogućih opcija može biti opis gornje razine prema Lehmanu, koja uključuje tri glavne faze i predstavlja opis programa životnog ciklusa u najopćenitijem slučaju.

I, za promjenu, evo koraka procesa programiranja koje je predstavio D. Riley u knjizi “Using the Modula-2 Language”. Ova je ideja, po mom mišljenju, vrlo jednostavna i poznata i s njom ćemo započeti.

1.1 Koraci Riley procesa programiranja

Proces programiranja uključuje četiri koraka (slika 1):

prikaz problema, tj. dobivanje odgovarajuće ideje o tome koji bi zadatak program trebao obavljati;

projektiranje rješenja već postavljenog problema (općenito je takvo rješenje manje formalno od konačnog programa);

programsko kodiranje, odnosno prevođenje projektiranog rješenja u program koji se može izvoditi na stroju;

programsku podršku, tj. kontinuirani proces popravljanja grešaka u programu i dodavanja novih značajki.

Riža. 1. Četiri koraka programiranja.

Programiranje počinje od trenutka kada korisnik, tj. netko tko treba program za rješavanje problema postavlja problem Sistemski analitičar. Korisnik i analitičar sustava zajednički definiraju iskaz problema. Potonji se zatim prenosi algoritamist koji je odgovoran za projektiranje rješenja. Rješenje (ili algoritam) je slijed operacija čije izvođenje dovodi do rješenja problema. Budući da algoritam često nije prilagođen za izvođenje na stroju, treba ga prevesti u strojni program. Ovu operaciju izvodi enkoder. Za naknadne izmjene programa odgovoran je prateći programer. I sistemski analitičar, i algoritmist, i koder, i prateći programer - svi su oni programeri.

U slučaju velikog softverskog projekta, broj korisnika, analitičara sustava i algoritama može biti značajan. Osim toga, možda će biti potrebno vratiti se na prethodne korake zbog nepredviđenih okolnosti. Sve ovo služi kao dodatni argument u korist pažljivog dizajna softvera: rezultati svakog koraka trebaju biti potpuni, točni i razumljivi.

1.1.1 Izjava problema

Jedan od najvažnijih koraka u programiranju je postavljanje problema. Funkcionira kao ugovor između korisnika i programera(a). Kao i zakonski loše sastavljen ugovor, loša izjava o misiji je beskorisna. S dobrom postavkom problema, i korisnik i programer jasno i nedvosmisleno predstavljaju zadatak koji treba izvršiti, tj. u ovom slučaju se uzimaju u obzir interesi i korisnika i programera. Korisnik može planirati korištenje softvera koji još nije izrađen, na temelju saznanja da može. Dobra postavka problema služi kao osnova za oblikovanje njegovog rješenja.

Formulacija problema (specifikacija programa); u biti znači točan, potpun i razumljiv opis onoga što se događa kada se određeni program izvrši. Korisnik obično na računalo gleda kao na crnu kutiju: nije mu bitno kako računalo radi, već je bitno da računalo može raditi ono što korisnika zanima. Fokus je na interakciji između čovjeka i stroja.

Karakteristike dobre izjave problema:

Točnost, tj. isključenje svake dvosmislenosti. Ne bi trebalo biti upitno kakav će biti izlaz programa za bilo koji ulaz.

potpunost, tj. razmatranje svih opcija za dati unos, uključujući pogrešan ili neočekivan unos, i određivanje odgovarajućeg izlaza.

Jasnoća, tj. trebao bi biti razumljiv i korisniku i analitičaru sustava, budući da je iskaz problema jedini ugovor između njih.

Često su zahtjevi za točnošću, potpunošću i jasnoćom u sukobu. Stoga je mnoge pravne dokumente teško razumjeti jer su napisani formalnim jezikom koji vam omogućuje da određene odredbe formulirate s najvećom preciznošću, isključujući čak i najbeznačajnija odstupanja. Na primjer, neka pitanja na ispitnim listićima ponekad su formulirana tako precizno da student provede više vremena razumijevajući pitanje nego odgovarajući na njega. Štoviše, učenik možda uopće neće shvatiti glavno značenje pitanja zbog velikog broja detalja. Najbolja izjava problema je ona koja postiže ravnotežu sva tri zahtjeva.

Standardni oblik iskaza problema.

Razmotrite sljedeću izjavu problema: "Unesite tri broja i ispišite brojeve redom."

Takva izjava ne zadovoljava gore navedene zahtjeve: nije ni precizna, ni potpuna, ni razumljiva. Doista, trebaju li brojevi biti uneseni jedan po retku ili svi brojevi u jednom retku? Znači li izraz "redom" redoslijed od najvećeg prema najmanjem, od najmanjeg prema najvećem ili istim redoslijedom kojim su upisani.

Očito je da takva izjava ne odgovara na mnoga pitanja. Ako uzmemo u obzir odgovore na sva pitanja, tada će izjava problema postati rječita i teško razumljiva. Stoga D. Riley predlaže korištenje standardnog obrasca za postavljanje problema koji osigurava maksimalnu točnost, potpunost, jasnoću i uključuje:

naziv zadatka (shematska definicija);

Opći opis (Sažetak zadaci);

pogreške (neuobičajene mogućnosti unosa izričito su navedene kako bi se korisnicima i programerima prikazalo radnje koje će stroj poduzeti u takvim situacijama);

primjer ( dobar primjer može prenijeti bit problema, kao i ilustrirati razne slučajeve).

Primjer. Prikaz problema u standardnom obliku.

TITULA

Razvrstaj tri cijela broja.

OPIS

Ulaz i izlaz tri cijela broja, poredana od najmanjeg prema najvećem.

Upisuju se tri cijela broja, po jedan broj u svakom redu. U ovom slučaju, cijeli broj je jedan ili više uzastopnih decimalne znamenke, ispred kojeg može stajati znak plus "+" ili znak minus "-".

Ispisuju se tri unesena cijela broja, a sva tri se prikazuju u istom retku. Susjedni brojevi odvajaju se razmakom. Brojevi se prikazuju od najmanjeg prema najvećem, s lijeva na desno.

1) Ako se unese manje od tri broja, program čeka dodatni unos.

Razvoj softvera je nemoguć bez razumijevanja tzv. životnog ciklusa softvera. Običan korisnik to možda i ne treba znati, ali je poželjno naučiti osnovne standarde (kasnije će biti rečeno zašto je to potrebno).

Što je životni ciklus u formalnom smislu?

Pod životnim ciklusom bilo kojeg, uobičajeno je razumjeti vrijeme njegovog postojanja, počevši od faze razvoja pa do trenutka potpuni neuspjeh od uporabe u odabranom području primjene do potpunog uklanjanja aplikacije iz uporabe.

Jednostavno rečeno, informacijski sustavi u obliku programa, baza podataka ili čak operativnih sustava traženi su samo ako su podaci i mogućnosti koje pružaju relevantni.

Vjeruje se da se definicija životnog ciklusa ni na koji način ne odnosi na testne aplikacije, poput beta verzija, koje su najnestabilnije u radu. Sam životni ciklus softvera ovisi o mnogim čimbenicima, među kojima jednu od glavnih uloga ima okolina u kojoj će se program koristiti. Međutim, može se razlikovati općim uvjetima poslovanja koristi se u definiranju koncepta životnog ciklusa.

Početni zahtjevi

• formulacija problema;
• analiza međusobnih zahtjeva budućeg softvera prema sustavu;
• oblikovati;
• programiranje;
• kodiranje i kompilacija;
• testiranje;
• uklanjanje pogrešaka;
• implementacija i održavanje softverskog proizvoda.

Razvoj softvera sastoji se od svih gore navedenih faza i ne može proći bez barem jedne od njih. Ali za kontrolu takvih procesa uspostavljeni su posebni standardi.

Standardi procesa životnog ciklusa softvera

Među sustavima koji unaprijed određuju uvjete i zahtjeve za takve procese, danas se mogu navesti samo tri glavna:

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

Postoji ruski analog za drugi međunarodni standard. Ovo je GOST R ISO / IEC 12207-2010, koji je odgovoran za sustave i softversko inženjerstvo. Ali životni ciklus softvera opisan u oba pravila u biti je identičan. Ovo se objašnjava prilično jednostavno.

Vrste softvera i ažuriranja

Usput, za većinu trenutno poznatih multimedijskih programa oni su sredstvo za spremanje glavnih konfiguracijskih postavki. Upotreba ove vrste softvera je, naravno, prilično ograničena, ali razumijevanje općih načela rada s istim medijskim playerima ne boli. I zato.

Zapravo, oni imaju životni ciklus softvera samo na razini razdoblja ažuriranja za verziju samog playera ili instalacije kodeka i dekodera. A audio i video transkoderi bitni su atributi svakog audio ili video sustava.

Primjer temeljen na FL Studiju

U početku se virtualni studio-sekvencer FL Studio zvao Fruity Loops. Životni ciklus softvera u primarnoj modifikaciji je istekao, ali je aplikacija donekle transformirana i poprimila sadašnji oblik.

Ako govorimo o fazama životnog ciklusa, u početku, u fazi postavljanja zadatka, postavljeno je nekoliko obveznih uvjeta:

• stvaranje modula bubnja sličnog ritam mašinama poput Yamahe RX, ali korištenjem pojedinačnih uzoraka ili WAV sekvenci snimljenih uživo u studiju;
• integracija u Windows operativne sustave;
• mogućnost izvoza projekta u WAV, MP3 i OGG formate;
• kompatibilnost projekta s dodatnom aplikacijom Fruity Tracks.

U fazi razvoja korišteni su alati programskih jezika C. Ali platforma je izgledala prilično primitivno i nije dopuštala krajnjem korisniku potrebna kvaliteta zvuk.

S tim u vezi, u fazi testiranja i otklanjanja pogrešaka, programeri su morali slijediti put njemačke korporacije Steinberg i primijeniti podršku za Full Duplex način rada u zahtjevima za glavni upravljački program zvuka. Kvaliteta zvuka postala je viša i omogućuje vam promjenu tempa, visine tona i primjenu dodatnih FX efekata u stvarnom vremenu.

Kraj životnog ciklusa ovog softvera smatra se izdavanjem prvog službena verzija FL Studio, koji je, za razliku od svojih predaka, već imao punopravno sučelje sekvencera s mogućnošću uređivanja parametara na virtualnoj 64-kanalnoj konzoli za miješanje s neograničenim dodavanjem audio zapisa i MIDI zapisa.

Ovo nije bilo ograničeno. U fazi upravljanja projektom uvedena je podrška za povezivanje dodataka u VST formatu (prvo druga, a zatim treća verzija), koju je Steinberg svojevremeno razvio. Grubo govoreći, bilo koji virtualni sintesajzer koji podržava VST-host mogao bi se spojiti na program.

Nije iznenađujuće da bi uskoro bilo koji skladatelj mogao koristiti analoge "željeznih" modela, na primjer, kompletan set zvukova nekada popularnog Korga M1. Dalje više. Korištenje modula poput Addictive Drums ili univerzalnog Kontakt plug-ina omogućilo je reprodukciju živih zvukova pravih instrumenata snimljenih sa svim nijansama artikulacije u profesionalnim studijima.

Istodobno, programeri su pokušali postići maksimalnu kvalitetu stvaranjem podrške za ASIO4ALL upravljačke programe, koji su se pokazali glavom i ramenima iznad Full Duplex moda. Sukladno tome, bitrate se također povećao. Do danas, kvaliteta izvezene audio datoteke može biti 320 kbps pri brzini uzorkovanja od 192 kHz. Ovo je profesionalni zvuk.

Što se početne verzije tiče, njen životni ciklus bi se mogao nazvati potpuno završenim, ali takva je izjava relativna, jer je aplikacija samo promijenila ime i dobila nove mogućnosti.

Izgledi razvoja

Koje su faze životnog ciklusa softvera već je jasno. Ali razvoj takvih tehnologija vrijedi spomenuti zasebno.

Nepotrebno je reći da bilo koji programer softvera nije zainteresiran za stvaranje kratkotrajnog proizvoda za koji je malo vjerojatno da će ostati na tržištu nekoliko godina. U budućnosti svi gledaju na njegovu dugoročnu upotrebu. To se može postići različiti putevi. Ali, u pravilu, gotovo svi se svode na izdavanje ažuriranja ili novih verzija programa.

Čak iu slučaju Windowsa takvi se trendovi mogu vidjeti golim okom. Malo je vjerojatno da će danas postojati barem jedan korisnik koji koristi sustave poput modifikacija 3.1, 95, 98 ili Millennium. Njihov životni ciklus završio je nakon izlaska XP verzije. Ali verzije poslužitelja temeljene na NT tehnologijama i dalje su relevantne. Čak i Windows 2000 danas nije samo vrlo ažuran, nego čak i nadmašuje najnovija dostignuća u nekim instalacijskim ili sigurnosnim parametrima. Isto vrijedi i za sustav NT 4.0, kao i za specijaliziranu modifikaciju Windows Servera 2012.

Ali u odnosu na te sustave, podrška se još uvijek deklarira na samom visoka razina. Ali senzacionalna Vista u svoje vrijeme očito doživljava pad ciklusa. Ne samo da se pokazalo nedovršenim, već je bilo toliko grešaka u sebi i rupa u njegovom sigurnosnom sustavu da se može samo nagađati kako je takvo neodrživo rješenje moglo biti pušteno na tržište softvera.

Ali ako govorimo o tome da razvoj softvera bilo koje vrste (upravljačkog ili aplikativnog) ne miruje, on je jedino moguć. Uostalom, danas se ne radi samo o računalni sustavi, i Mobilni uredaji u kojem su primijenjene tehnologije često ispred računalnog sektora. Pojava procesorskih čipova temeljenih na osam jezgri - nego ne najviše najbolji primjer? Ali ne može se svako prijenosno računalo pohvaliti takvim hardverom.

Neka dodatna pitanja

Što se tiče razumijevanja životnog ciklusa softvera, moguće je reći da je završio u određenom trenutku, vrlo je uvjetno, jer softverski proizvodi još uvijek imaju podršku programera koji su ih stvorili. Umjesto toga, kraj se odnosi na naslijeđene aplikacije koje ne ispunjavaju zahtjeve moderni sustavi i ne mogu raditi u svom okruženju.

Ali čak i uzimajući u obzir tehnički napredak mnoge od njih uskoro bi mogle postati neodržive. Tada ćete morati donijeti odluku o izdavanju ažuriranja ili o potpunoj reviziji cjelokupnog koncepta koji je izvorno ugrađen u softverski proizvod. Otuda i novi ciklus koji podrazumijeva promjenu početnih uvjeta, razvojnog okruženja, testiranje i moguću dugoročnu primjenu na određenom području.

Ali u računalnoj tehnologiji danas se prednost daje razvoju automatizirani sustavi sustavi upravljanja (ACS), koji se koriste u proizvodnji. Čak i operativni sustavi, u usporedbi sa specijaliziranim programima, gube.

Ista okruženja temeljena na Visual Basicu ostaju mnogo popularnija od Windows sustava. Pritom uopće ne govorimo o aplikacijskom softveru za UNIX sustave. Što mogu reći, ako gotovo sve komunikacijske mreže istih Sjedinjenih Država rade isključivo za njih. Usput, sustavi poput Linuxa i Androida također su izvorno stvoreni na ovoj platformi. Stoga, najvjerojatnije, UNIX ima puno više izgleda od ostalih proizvoda zajedno.

Umjesto totala

Ostaje još dodati da ovaj slučaj dano samo generalni principi i faze životnog ciklusa softvera. Zapravo, čak se i početni zadaci mogu značajno razlikovati. Sukladno tome, razlike se mogu uočiti u drugim fazama.

Ali osnovne tehnologije za razvoj softverskih proizvoda s njihovim naknadnim održavanjem trebaju biti jasne. Za ostalo, treba voditi računa o specifičnostima softvera koji se izrađuje, okolinama u kojima bi trebao raditi, te mogućnostima programa koji se daju krajnjem korisniku ili proizvodnji i još mnogo toga.

Osim toga, ponekad životni ciklusi mogu ovisiti o relevantnosti razvojnih alata. Ako, primjerice, neki programski jezik zastari, nitko neće pisati programe na temelju njega, štoviše - implementirati ih u automatizirane sustave upravljanja u proizvodnji. Tu čak ne dolaze do izražaja programeri, već marketingaši koji moraju pravovremeno reagirati na promjene na tržištu računala. A takvih stručnjaka u svijetu nema toliko. Najtraženiji su visokokvalificirani kadrovi sposobni držati korak s tržištem. A upravo su oni često takozvani "sivi kardinali" o kojima ovisi uspjeh ili neuspjeh određenog softverskog proizvoda u IT području.

Iako ne razumiju uvijek bit programiranja, jasno su sposobni odrediti modele životnog ciklusa softvera i trajanje njihove uporabe, na temelju svjetskih trendova u ovom području. Učinkovito upravljanje često daje opipljivije rezultate. Da, barem PR tehnologije, oglašavanje itd. Korisnik možda neće trebati neku aplikaciju, ali ako se aktivno reklamira, korisnik će je instalirati. To je već, da tako kažemo, podsvjesna razina (isti učinak 25. okvira, kada se informacije stavljaju u um korisnika bez obzira na njega samog).

Naravno, takve tehnologije su zabranjene u svijetu, ali mnogi od nas niti ne shvaćaju da se one ipak mogu koristiti i utjecati na podsvijest na određeni način. Što vrijedi “zombificiranje” informativnih kanala ili internetskih stranica, a da ne govorimo o korištenju moćnijih sredstava, poput izlaganja infrazvuku (to je korišteno u jednoj opernoj produkciji), zbog čega čovjek može osjetiti strah ili neadekvatne emocije.

Vraćajući se na softver, vrijedi dodati da neki programi koriste zvučni signal pri pokretanju kako bi privukli pozornost korisnika. Studije pokazuju da su takve aplikacije održivije od drugih programa. Naravno, produžava se i životni ciklus softvera, bez obzira kojoj funkciji je izvorno dodijeljen. I to, nažalost, koriste mnogi programeri, što izaziva sumnju u zakonitost takvih metoda.

Ali nije na nama da sudimo o tome. Moguće je da će se u bliskoj budućnosti razviti alati za prepoznavanje takvih prijetnji. Zasad je to samo teorija, ali, prema nekim analitičarima i stručnjacima, prije praktična aplikacija ostalo je vrlo malo. Ako već stvaraju kopije neuronskih mreža ljudskog mozga, što onda reći?

Riža. 5.2.

Ovi aspekti su:

1. ugovorni aspekt u koji ulaze kupac i dobavljač ugovorni odnos te implementirati procese nabave i nabave;
2. upravljački aspekt, koji uključuje upravljačke radnje osoba koje sudjeluju u životnom ciklusu softvera (dobavljač, kupac, programer, operater itd.);
3. aspekt rada, koji uključuje radnje operatora za pružanje usluga korisnicima sustava;
4. inženjerski aspekt, koji sadrži radnje programera ili službe podrške za rješavanje tehničkih problema povezanih s razvojem ili modificiranjem softverskih proizvoda;
5. aspekt podrške povezan s provedbom procesa podrške, putem kojih službe podrške pružaju potrebne usluge svim ostalim sudionicima u radu. U ovom aspektu može se izdvojiti aspekt upravljanja kvalitetom softvera, uključujući procese osiguranja kvalitete, verifikacije, certifikacije, zajedničke procjene i audita.

Organizacijski procesi odvijaju se na korporativnoj razini ili na razini cijele organizacije kao cjeline, stvarajući osnovu za implementaciju i kontinuirano poboljšanje procesa životnog ciklusa softvera.

5.6. Modeli i faze životnog ciklusa softvera

Model životnog ciklusa softvera shvaća se kao struktura koja određuje redoslijed izvršavanja i odnos procesa, akcija i zadataka tijekom životnog ciklusa softvera. Model životnog ciklusa ovisi o specifičnostima, opsegu i složenosti projekta te specifičnim uvjetima u kojima sustav nastaje i radi.

Norma ISO/IEC 12207 ne predlaže određeni model životnog ciklusa i metode razvoja softvera. Njegove odredbe zajedničke su svim modelima životnog ciklusa, metodama i tehnologijama razvoja softvera. Standard opisuje strukturu procesa životnog ciklusa softvera, ali ne specificira kako implementirati ili izvesti aktivnosti i zadatke uključene u te procese.

Model životnog ciklusa bilo kojeg specifičnog softvera određuje prirodu procesa njegovog stvaranja, koji je skup radova poredanih u vremenu, međusobno povezanih i objedinjenih u fazama (fazama), čija je implementacija neophodna i dovoljna za stvaranje softvera koji zadovoljava navedene zahtjeve.

Faza (faza) stvaranja softvera shvaća se kao dio procesa stvaranja softvera, ograničen nekim vremenskim okvirom i završava izdavanjem određenog proizvoda (softverski modeli, softverske komponente, dokumentacija itd.), određen navedenim zahtjevima za ovu fazu. Izdvojene su faze izrade softvera iz razloga racionalnog planiranja i organizacije rada, a završavaju navedenim rezultatima. Životni ciklus softvera obično uključuje sljedeće faze:

1. formiranje softverskih zahtjeva;
2. projektiranje (izrada projekta sustava);
3. implementacija (može se podijeliti na pod-korake: detaljni dizajn, kodiranje);
4. testiranje (može se podijeliti na samostalno i sveobuhvatno testiranje i integracija)
5. puštanje u rad (implementacija);
6. rad i održavanje;
7. razgradnja.

Neki stručnjaci uvode dodatnu početnu fazu - Studija izvodljivosti sustava. Ovo se odnosi na softverski i hardverski sustav za koji je softver kreiran, kupljen ili modificiran.

Faza formiranja softverskih zahtjeva jedna je od najvažnijih i u velikoj mjeri (čak i odlučujuće!) određuje uspjeh cijelog projekta. Početak ove faze je dobivanje odobrene i odobrene arhitekture sustava uz uključivanje osnovnih dogovora o raspodjeli funkcija između hardvera i softvera. Ovaj dokument također treba sadržavati potvrdu opće ideje o funkcioniranju softvera, uključujući glavne sporazume o raspodjeli funkcija između osobe i sustava.

Faza formiranja softverskih zahtjeva uključuje sljedeće faze.

1. Planiranje rada prije projekta. Glavni zadaci pozornice su definiranje razvojnih ciljeva, preliminarni ekonomska procjena projekt, izrada rasporeda rada, stvaranje i obuka zajedničke radne skupine.
2. Provođenje istraživanja aktivnosti automatizirane organizacije (objekta), u okviru kojeg se provodi preliminarna identifikacija zahtjeva za budući sustav, određivanje strukture organizacije, određivanje popisa ciljnih funkcija organizacije, analiza raspodjela funkcija po odjelima i zaposlenicima, identificiranje funkcionalne interakcije između odjela, tokovi informacija unutar odjela i između njih, objekti izvan organizacije i vanjski informacijski utjecaji, analiza postojećih sredstava automatizacije aktivnosti organizacije.

Izgradnja modela aktivnosti organizacije (objekta), koji predviđa obradu anketnih materijala i izgradnju dvije vrste modela:

• model "KAKO JEST" ("kakav jest") koji odražava trenutno stanje stvari u organizaciji u vrijeme ankete i omogućuje vam da razumijete kako organizacija funkcionira, kao i da identificirate uska grla i formulirate prijedloge za poboljšanje situacija;
• Model "TO-BE" ("kao što bi trebalo biti"), odražava ideju novih tehnologija rada organizacije.

Svaki od modela treba sadržavati cjeloviti funkcionalni i informacijski model aktivnosti organizacije, kao i (ako je potrebno) model koji opisuje dinamiku ponašanja organizacije. Napominjemo da su konstruirani modeli od samostalnog praktičnog značaja, neovisno o tome razvija li poduzeće i implementira informacijski sustav, budući da se mogu koristiti za obuku zaposlenika i unapređenje poslovnih procesa poduzeća.

Rezultat završetka faze formiranja programskih zahtjeva su softverske specifikacije, funkcionalne, tehničke i specifikacije sučelja, za koje se potvrđuje njihova cjelovitost, provjerljivost i izvedivost.

Faza projektiranja uključuje sljedeće korake.

1. Izrada projekta softverskog sustava. U ovoj fazi daje se odgovor na pitanje "Što bi budući sustav trebao raditi?", a to su: arhitektura sustava, njegove funkcije, vanjski uvjeti funkcioniranje, sučelja i raspodjela funkcija između korisnika i sustava, zahtjevi za softverske i informacijske komponente, sastav izvođača i vrijeme razvoja, plan otklanjanja pogrešaka i kontrole kvalitete softvera.

   Osnova projekta sustava su modeli projektiranog sustava koji su izgrađeni na modelu "TO-BE". Rezultat razvoja projekta sustava treba biti odobrena i potvrđena specifikacija softverskih zahtjeva: funkcionalnih, tehničkih i specifikacija sučelja, za koje se potvrđuje njihova cjelovitost, provjerljivost i izvedivost.

2. Izrada izvedbenog (tehničkog) projekta. U ovoj fazi se provodi stvarni dizajn softvera, uključujući dizajn arhitekture sustava i detaljni dizajn. Time je dan odgovor na pitanje: "Kako izgraditi sustav tako da zadovoljava zahtjeve?"

Rezultat detaljnog dizajna je razvoj provjerene specifikacije softvera, uključujući:

• formiranje hijerarhije programskih komponenti, međumodulnih sučelja za podatke i kontrolu;
• specifikacija svake softverske komponente, naziv, svrha, pretpostavke, veličine, redoslijed poziva, ulazni i izlazni podaci, pogrešni izlazi, algoritmi i logički sklopovi;
• formiranje fizičkih i logičkih struktura podataka do razine pojedinih polja;
• izrada plana raspodjele računalnih resursa (vrijeme središnjih procesora, memorije i dr.);
• provjera potpunosti, dosljednosti, izvedivosti i valjanosti zahtjeva;
• preliminarni plan integracije i otklanjanja pogrešaka, korisnički priručnik i plan prihvatljivog testiranja.

Završetak faze detaljnog dizajna je od kraja do kraja

1. ožujka 2012. Savezna agencija za tehničku regulaciju i mjeriteljstvo Ruske Federacije usvojila je standard GOST R ISO / IEC 12207-2010 umjesto GOST R ISO / IEC 12207-99 " Informacijska tehnologija. Inženjering sustava i softvera. Procesi životnog ciklusa softvera”, istovjetan međunarodnoj normi ISO/IEC 12207:2008 “Sustav i softversko inženjerstvo – Procesi životnog ciklusa softvera”.

Ova norma, koristeći ustaljenu terminologiju, uspostavlja ukupna struktura procesi životnog ciklusa softvera koji se mogu koristiti kao referenca u softverskoj industriji. Norma definira procese, aktivnosti i zadatke koji se koriste u nabavi softverskog proizvoda ili usluge, kao iu isporuci, razvoju, namjeravanoj uporabi, održavanju i ukidanju softverskih proizvoda.

Procesi životnog ciklusa softvera

Standardne grupe različite vrste aktivnosti koje se mogu obavljati tijekom životnog ciklusa programski sustavi, u sedam grupa procesa. Svaki od procesa životnog ciklusa unutar ovih grupa opisan je u smislu svrhe i željenih rezultata, popisa radnji i zadataka koje treba izvršiti da bi se postigli ti rezultati.

• procesi dogovora - dva procesa;
• procesi organizacijske podrške projektu - pet procesa;
• projektni procesi - sedam procesa;
• tehnički procesi - jedanaest procesa;
• procesi implementacije softvera - sedam procesa;
• procesi programske podrške - osam procesa;
• procesi ponovne upotrebe softvera - tri procesa.
• Glavni:
  • Akvizicija (radnje i zadaci kupca koji kupuje softver)
  • Isporuka (aktivnosti i zadaci dobavljača koji isporučuje kupcu softverski proizvod ili uslugu)
  • Razvoj (radnje i zadaci koje obavlja programer: izrada softvera, izrada projektne i operativne dokumentacije, priprema materijala za testiranje i obuku itd.)
  • Rad (radnje i zadaci operatera - organizacije koja upravlja sustavom)
  • Održavanje (radnje i zadaci koje obavlja prateća organizacija, odnosno služba održavanja). Održavanje - izmjene softvera kako bi se ispravile greške, poboljšale performanse ili prilagodile promjenjivim radnim uvjetima ili zahtjevima.
• Pomoćni
  • Dokumentacija (formalizirani opis informacija stvorenih tijekom životnog ciklusa softvera)
  • Upravljanje konfiguracijom (primjena administrativnih i tehničkih postupaka tijekom životnog ciklusa softvera za određivanje stanja komponenti softvera, upravljanje njegovim izmjenama).
  • Osiguranje kvalitete (osiguranje da su IS i procesi njegovog životnog ciklusa u skladu s navedenim zahtjevima i odobrenim planovima)
  • Verifikacija (utvrđivanje da programski proizvodi, koji su rezultat neke radnje, u potpunosti zadovoljavaju zahtjeve ili uvjete zbog prethodnih radnji)
  • Certifikacija (utvrđivanje potpunosti usklađenosti navedenih zahtjeva i izrađenog sustava s njihovom specifičnom funkcionalnom namjenom)
  • Zajednička procjena (procjena stanja rada na projektu: kontrola planiranja i upravljanja resursima, osobljem, opremom, alatima)
  • Revizija (utvrđivanje usklađenosti sa zahtjevima, planovima i uvjetima ugovora)
  • Rješavanje problema (analiza i rješavanje problema, bez obzira na njihovo porijeklo ili izvor, koji su otkriveni tijekom razvoja, rada, održavanja ili drugih procesa)
• Organizacijski
  • Upravljanje (aktivnosti i zadaci koje može obavljati bilo koja strana koja upravlja svojim procesima)
  • Stvaranje infrastrukture (odabir i održavanje tehnologije, standarda i alata, odabir i instalacija hardvera i softvera koji se koristi za razvoj, rad ili održavanje softvera)
  • Poboljšanje (procjena, mjerenje, kontrola i poboljšanje procesa životnog ciklusa)
  • Obuka (početna obuka i kasniji kontinuirani razvoj osoblja)

Svaki proces uključuje niz aktivnosti. Na primjer, postupak akvizicije obuhvaća sljedeće korake:

1. Inicijacija akvizicije
2. Priprema ponuda
3. Priprema i prilagodba ugovora
4. Nadzor dobavljača
5. Prijem i završetak radova

Svaka radnja uključuje niz zadataka. Na primjer, priprema ponuda treba uključivati:

1. Formiranje zahtjeva za sustav
2. Formiranje popisa programskih proizvoda
3. Postavljanje uvjeta i dogovora
4. Opis tehničkih ograničenja (radno okruženje sustava, itd.)

Faze životnog ciklusa softvera, odnos između procesa i faza

Model životnog ciklusa softvera- strukturu koja određuje redoslijed izvršavanja i odnos procesa, akcija i zadataka tijekom životnog ciklusa. Model životnog ciklusa ovisi o specifičnostima, opsegu i složenosti projekta te specifičnim uvjetima u kojima sustav nastaje i radi.

Norma GOST R ISO/IEC 12207-2010 ne nudi određeni model životnog ciklusa. Njegove odredbe zajedničke su svim modelima životnog ciklusa, metodama i tehnologijama za stvaranje IP-a. Opisuje strukturu procesa životnog ciklusa bez specificiranja kako implementirati ili izvesti aktivnosti i zadatke uključene u te procese.

Model životnog ciklusa softvera uključuje:

1. faze;
2. Rezultati rada u svakoj fazi;
3. Ključni događaji - točke završetka rada i donošenja odluka.

u elektrotehnici). Ova norma definira strukturu životnog ciklusa, koja sadrži procese, aktivnosti i zadatke koji se moraju izvršiti tijekom stvaranja PS-a.

U ovom PS standardu (ili softver) definiran je kao skup računalni programi, postupcima i eventualno povezanom dokumentacijom i podacima. Proces se definira kao skup međusobno povezanih radnji koje pretvaraju neke ulazne podatke u izlazne podatke (G. Myers to naziva prijevodom podataka). Svaki proces karakteriziraju određeni zadaci i metode za njihovo rješavanje. Zauzvrat, svaki proces je podijeljen u skup akcija, a svaka radnja je podijeljena u skup zadataka. Svaki proces, radnju ili zadatak pokreće i izvršava drugi proces prema potrebi i ne postoje unaprijed određene sekvence izvršenja (naravno, uz održavanje veza ulaznih podataka).

Treba napomenuti da je u Sovjetskom Savezu, a potom iu Rusiji, stvaranje softvera (SW), u početku, 70-ih godina prošlog stoljeća, bilo regulirano GOST ESPD standardima ( jedinstveni sustav softverska dokumentacija - niz GOST 19.XXX), koji su bili usmjereni na klasu relativno jednostavnih programa malog volumena koje su izradili pojedinačni programeri. Trenutno su te norme konceptualno i oblikovno zastarjele, valjanost im je istekla i njihova je uporaba neprikladna.

Procesi stvaranja automatiziranih sustava (AS), koji također uključuju softver, regulirani su standardima GOST 34.601-90 "Informacijska tehnologija. Skup standarda za automatizirane sustave. Faze stvaranja", GOST 34.602-89 "Informacijska tehnologija. A skup standarda za automatizirane sustave. Tehnički zadatak za stvaranje automatiziranog sustava" i GOST 34.603-92 "Informacijska tehnologija. Vrste ispitivanja automatiziranih sustava". Međutim, mnoge odredbe ovih standarda su zastarjele, dok se druge ne odražavaju dovoljno da bi se mogle koristiti za ozbiljne projekte za stvaranje PS-a. Stoga je preporučljivo koristiti suvremene međunarodne standarde u domaćim razvojima.

Prema ISO standard/ IEC 12207, svi procesi životnog ciklusa softvera podijeljeni su u tri skupine (Slika 5.1).

Riža. 5.1.

U skupinama je definirano pet glavnih procesa: nabava, nabava, razvoj, rad i održavanje. Osam potprocesa osigurava izvođenje glavnih procesa, naime dokumentacija, upravljanje konfiguracijom, osiguranje kvalitete, verifikacija, validacija, zajednička procjena, audit, rješavanje problema. četiri organizacijski proces osigurati upravljanje, infrastrukturu, poboljšanje i obuku.

5.2. Glavni procesi životnog ciklusa PS-a

Proces nabave sastoji se od aktivnosti i zadataka kupca koji kupuje softver. Ovaj proces pokriva sljedeće aktivnosti:

1. inicijacija stjecanja;
2. priprema prijedloga prijava;
3. priprema i prilagodba ugovora;
4. nadzor aktivnosti dobavljača;
5. prihvaćanje i završetak posla.

Iniciranje akvizicije uključuje sljedeće zadatke:

1. određivanje od strane kupca njegovih potreba u nabavi, razvoju ili poboljšanju sustava, softverskih proizvoda ili usluga;
2. donošenje odluke o nabavi, razvoju ili poboljšanju postojećeg softvera;
3. provjera dostupnosti potrebna dokumentacija, jamstva, certifikate, licence i podršku u slučaju kupnje softverskog proizvoda;
4. priprema i odobrenje plana akvizicije, uključujući zahtjeve sustava, vrstu ugovora, odgovornosti stranaka itd.

Ponude moraju sadržavati:

1. Zahtjevi sustava;
2. popis softverskih proizvoda;
3. uvjeti stjecanja i dogovora;
4. tehnička ograničenja (na primjer, na radnom okruženju sustava).

Ponude se šalju odabranom dobavljaču ili više dobavljača u slučaju natječaja. Dobavljač je organizacija koja s kupcem sklapa ugovor o isporuci sustava, softvera ili softverske usluge pod uvjetima navedenim u ugovoru.

Priprema i prilagodba ugovora uključuje sljedeće poslove:

1. kupac određuje postupak odabira dobavljača, uključujući kriterije za ocjenu prijedloga mogućih dobavljača;
2. odabir konkretnog dobavljača na temelju analize prijedloga;
3. priprema i zaključak ugovori s dobavljačima;
4. izmjene (ako su potrebne) ugovora u procesu njegove provedbe.

Aktivnosti dobavljača nadziru se u skladu s radnjama navedenim u procesima zajedničke procjene i revizije. Tijekom procesa prihvaćanja pripremaju se i provode potrebna ispitivanja. Završetak radova prema ugovoru provodi se u slučaju zadovoljenja svih uvjeta prihvaćanja.

Proces isporuke pokriva aktivnosti i zadatke koje obavlja dobavljač koji kupcu isporučuje softverski proizvod ili uslugu. Ovaj proces uključuje sljedeće korake:

1. početak isporuke;
2. priprema odgovora na ponude;
3. priprema ugovora;
4. planiranje rada po ugovoru;
5. izvođenje i kontrola ugovorenih radova i njihovo vrednovanje;
6. isporuka i završetak radova.

Početak opskrbe sastoji se u razmatranju ponuda od strane dobavljača i donošenju odluke hoće li se složiti s postavljenim zahtjevima i uvjetima ili će ponuditi vlastite (dogovorene). Planiranje uključuje sljedeće zadatke:

1. donošenje odluke dobavljača o izvođenju radova samostalno ili uz sudjelovanje podizvođača;
2. razvoj od strane dobavljača plana upravljanja projektom koji sadrži organizacijska struktura projekt, podjela odgovornosti, tehnički zahtjevi na razvojno okruženje i resurse, upravljanje podizvođačima itd.

Razvojni proces predviđa aktivnosti i zadatke koje provodi programer, a obuhvaća rad na izradi softvera i njegovih komponenti u skladu sa zadanim zahtjevima. To uključuje izradu projektne i operativne dokumentacije, pripremu materijala potrebnih za ispitivanje učinkovitosti i kvaliteta softverskih proizvoda, materijale potrebne za organiziranje obuke osoblja i sl.

Proces razvoja uključuje sljedeće korake:

1. pripremni rad;
2. analiza zahtjeva za sustav;
3. projektiranje arhitekture sustava;
4. analiza zahtjeva za softver;
5. dizajn softverske arhitekture;
6. detaljan dizajn softvera;
7. programsko kodiranje i testiranje;
8. integracija softvera;
9. testiranje kvalifikacije softvera;
10. integracija sustava;
11. testiranje kvalifikacije sustava;
12. instalacija softvera;
13. prihvaćanje softvera.

Pripremni rad započinje odabirom modela životnog ciklusa softvera koji odgovara veličini, značaju i složenosti projekta. Aktivnosti i zadaće razvojnog procesa trebaju biti u skladu s odabranim modelom. Programer mora odabrati, prilagoditi se uvjetima projekta i koristiti standarde, metode i metode dogovorene s kupcem. razvojni alati, kao i izraditi plan rada.

Analiza zahtjeva za sustav uključuje utvrđivanje njegove funkcionalnosti, prilagođeni zahtjevi, zahtjevi za pouzdanost, sigurnost, zahtjevi za vanjska sučelja, performanse itd. Zahtjevi sustava ocjenjuju se na temelju kriterija izvedivosti i provjerljivosti tijekom testiranja.

Projektiranje arhitekture sustava sastoji se od određivanja komponenti njegove opreme (hardvera), softvera i operacija koje obavlja osoblje koje upravlja sustavom. Arhitektura sustava mora ispunjavati zahtjeve za sustav, kao i biti prihvaćena standardi dizajna i metode.

Analiza zahtjeva softvera uključuje određivanje sljedećih karakteristika za svaku komponentu softvera:

1. funkcionalnost, uključujući karakteristike izvedbe i radno okruženje komponente;
2. vanjska sučelja;
3. specifikacije pouzdanosti i sigurnosti;
4. ergonomski zahtjevi;
5. zahtjevi za podatke koji se koriste;
6. zahtjevi za ugradnju i prihvaćanje;
7. zahtjevi za korisničku dokumentaciju;
8. zahtjevi za rad i održavanje.

Softverski zahtjevi ocjenjuju se na temelju kriterija usklađenosti sa zahtjevima za sustav u cjelini, izvedivosti i provjerljivosti tijekom testiranja.

Dizajn softverske arhitekture uključuje sljedeće zadatke za svaku softversku komponentu:

1. transformacija softverskih zahtjeva u arhitekturu koja definira strukturu softvera i sastav njegovih komponenti na visokoj razini;
2. razvoj i dokumentiranje programskih sučelja za softver i baze podataka (DB);
3. izrada preliminarne verzije korisničke dokumentacije;
4. razvoj i dokumentiranje preduvjeta za testove i plan integracije softvera.

Detaljan dizajn softvera uključuje sljedeće zadatke:

1. opis programskih komponenti i sučelja između njih na nižoj razini, dovoljnoj za naknadno kodiranje i testiranje;
2. razvoj i dokumentacija detaljni dizajn Baza podataka;
3. ažuriranje (ako je potrebno) korisničke dokumentacije;
4. razvoj i dokumentiranje zahtjeva za testiranje i plana za testiranje komponenti softvera;

Programsko kodiranje i testiranje uključuje sljedeće zadatke:

1. kodiranje i dokumentiranje svake komponente softvera i baze podataka, kao i priprema skupa testnih postupaka i podataka za njihovo testiranje;
2. testiranje svake komponente softvera i baze podataka na usklađenost sa zahtjevima za njih, nakon čega slijedi dokumentiranje rezultata testiranja;
3. ažuriranje dokumentacije (ako je potrebno);
4. ažuriranje plana integracije softvera.

Integracija softvera osigurava sastavljanje razvijenih softverskih komponenti u skladu s planom integracije i testiranja agregiranih komponenti. Za svaku od agregiranih komponenti razvijeni su paketi testova i testni postupci za testiranje svake kompetencije u naknadnom testiranju stručnosti. Kvalificirani zahtjev je skup kriterija ili uvjeta koji moraju biti ispunjeni da bi se kvalificirali softver u skladu sa svojim specifikacijama i spreman za upotrebu na terenu.

Kvalifikacijsko testiranje softvera provodi programer u prisustvu kupca (

Operativni proces obuhvaća aktivnosti i zadatke organizacije operatora koji upravlja sustavom. Operativni proces uključuje sljedeće korake.

1. Pripremni rad, koji uključuje obavljanje sljedećih zadataka od strane operatera:

   1. planiranje aktivnosti i poslova koji se obavljaju tijekom rada, te postavljanje standarda rada;
   2. određivanje postupaka za lokalizaciju i rješavanje problema koji nastaju tijekom rada.
2. Operativno testiranje provodi se za svako sljedeće izdanje softverskog proizvoda, nakon čega se ovo izdanje prenosi u rad.
3. Stvarni rad sustava koji se odvija u za to predviđenom okruženju u skladu s korisničkom dokumentacijom.
4. analiza problema i zahtjeva za modifikacijom softvera (analiza poruka o nastalom problemu ili zahtjevu za modifikaciju, procjena razmjera, trošak modifikacije, rezultirajući učinak, procjena izvedivosti modifikacije);
5. modificiranje programske opreme (izmjena komponenti i dokumentacije programskog proizvoda u skladu s pravilima razvojnog procesa);
6. provjera i prihvaćanje (u smislu cjelovitosti sustava koji se mijenja);
7. prijenos softvera u drugo okruženje (konverzija programa i podataka, paralelni rad softvera u starom i novom okruženju na određeno vrijeme);
8. stavljanje programske opreme izvan pogona odlukom naručitelja uz sudjelovanje operativne organizacije, službe održavanja i korisnika. Istodobno, programski proizvodi i dokumentacija podliježu arhiviranju sukladno ugovoru.