U opštem slučaju, softverski sistem, pored samih programa, sadrži i hardver, a obično se smatra da je okružen drugim softverskim i hardverskim sistemima.

Životni ciklus softverskog sistema obično se shvata kao čitav period postojanja softverskog sistema, počevši od trenutka kada je razvijen inicijalna koncepcija sistema i završava se kada sistem zastari. Koncept ``životni ciklus"" koristi se kada se očekuje da će softverski sistem imati prilično dug životni vijek, za razliku od eksperimentalnog programiranja u kojem se programi pokreću nekoliko puta i ne koriste ponovo.

Životni ciklus se tradicionalno modelira kao niz uzastopnih faza (ili faza, faza). Trenutno ne postoji opšteprihvaćena podela životnog ciklusa softverskog sistema na faze. Nekada je pozornica istaknuta kao zasebna tačka, ponekad je uključena kao sastavni dio veće pozornice. Radnje koje se izvode u jednoj ili drugoj fazi mogu se razlikovati. Nema ujednačenosti u nazivima ovih faza. Stoga ćemo prvo pokušati da opišemo neki generalizovani životni ciklus softverskog sistema, a zatim ćemo demonstrirati nekoliko primera različitih životnih ciklusa, ukazujući na analogije iz ovog generalizovanog ciklusa.

Faze životnog ciklusa softvera

Životni ciklus softvera je period razvoja i rada softvera, koji obično uključuje sljedeće faze: -1- nastajanje i istraživanje ideje; -2- analiza i projektovanje zahteva; -3- programiranje; -4- testiranje i otklanjanje grešaka; -5- stavljanje programa na snagu; -6- rad i održavanje; -7- kraj rada.

Treba napomenuti da razbijanje životnog ciklusa na faze ponekad pomaže da se prikriju neki važni aspekti kreiranja softvera; Ovo se posebno odnosi na tako neophodan proces kao što je iterativna implementacija različitih faza životnog ciklusa kako bi se ispravile greške, promijenile odluke koje su se pokazale pogrešnim ili uzele u obzir promjene u ukupnim zahtjevima za sistem.

Primjeri opisa životnog ciklusa

Pogledajmo nekoliko opisa životnog ciklusa softvera, koji će poslužiti kao neka vrsta komentara o fazama generalizovanog životnog ciklusa.

U domaćim regulatornim dokumentima (na primjer, GOST ESPD), usvojena je sljedeća podjela na faze, koja je data uz naznaku analogija sa liste date na početku odjeljka:

razvoj tehničkih specifikacija (faze 1 i 2);

tehnički projekat (treća faza do 3.2.1 uključujući);

radni nacrt (3.2.2, 4.2.1 i, dijelom, 4.2, 4.3);

pilot implementacija (4.2 i 4.3);

puštanje u rad u komercijalni rad (faza 5);

industrijski rad (faza 6).

Takav opis je zasnovan na tehnologiji razvoja hardvera i stoga ne uzima u potpunosti u obzir sve karakteristične karakteristike dizajna softvera. Čini se da je prikladniji opis životnog ciklusa softvera 12 faza, koje su veoma slične fazama generalizovanog životnog ciklusa (vidi sliku 1.1). U zagradama iza naziva faze naveden je analog iz generalizovanog ciklusa. Gotovo sve faze završavaju provjerom rezultata dobivenih u odgovarajućoj fazi.

Rice. 1.1 Primjer životnog ciklusa softverskih sistema

Pokretanje i planiranje projekta (faza 1). Utvrđuju se potrebne radnje, planovi i organizacija upravljanja projektom.

Određene su mjere kako bi se osiguralo kontinuirano izvršavanje faza životnog ciklusa.

Analiza ciljnih zahtjeva (2.1).

Utvrđuju se opšte karakteristike sistema koje on mora zadovoljiti, bez uzimanja u obzir načina implementacije.

Idejni dizajn softvera (3.2.1). Određivanje specifičnih softverskih komponenti koje će biti razvijene i implementirane u konačni sistem. Provjera dosljednosti ovog skupa komponenti s općim zahtjevima softvera. Određivanje funkcionalnih, operativnih i testnih zahtjeva za svaku specifičnu komponentu.

Detaljni dizajn softvera (3.2.2). U smislu softverskih konstrukcija koje se koriste, napravljen je opis kako će se razvijati svaka specifična komponenta.

Opisani su načini upotrebe svake komponente u sistemu.

Softversko kodiranje i testiranje (4.1.1 i 4.1.2). Izrada, testiranje pojedinačnih modula, dokumentacija i prihvatanje softverskih komponenti koje čine softverski sistem.

Integracija softvera (dio 4.2). Testiranje performansi i funkcionalne kompletnosti softverskih delova sistema u predvidljivom okruženju (hardver i okruženje).

Integracija sistema (4.3). Testiranje performansi i funkcionalne kompletnosti dijelova cjelokupnog sistema u cjelini.

Prijem i isporuka sistema (5). Sistem prihvata kupac i sistem mu se isporučuje.

Rad i održavanje sistema (6). Izdavanje narednih verzija ili verzija sistema, za kojima se potreba javlja zbog otklanjanja nedostataka, testiranja izmijenjenih zahtjeva itd.

Završetak projekta (7). Formiranje post-originalnog modela projektnih akcija sa analizom prednosti, nedostataka i sl. i njihovo korištenje kao osnova za unapređenje razvojnog procesa.

Kao sljedeći primjer, razmotrite nekompletan životni ciklus softvera, bez faza rada i održavanja (vidi sliku 1.2). Ova opcija ne fiksira redoslijed faza ili faza, već predlaže listu radnji koje se moraju izvršiti tokom životnog ciklusa softvera. Ove radnje se mogu raščlaniti ili, obrnuto, grupirati u različite faze, u zavisnosti od specifičnih uslova. Mogu se razlikovati sljedeće faze životnog ciklusa softverskih sistema (u zagradama su, kao i prije, analogi iz generaliziranog modela ciklusa):

faza planiranja, koja određuje i koordinira aktivnosti na razvoju softverskog sistema (faza 1);

razvojna faza u kojoj se kreira softverski sistem:

izjava o problemu (faza 2),

dizajn (3),

dobijanje izvršnog koda (4.1.1, 4.3);

integrisana faza koja osigurava ispravku, verifikaciju i utvrđivanje kompletnosti softverskog sistema, kao i njegovo izdavanje. Ova faza uključuje verifikaciju, praćenje konfiguracije sistema, procjenu kvaliteta i provjeru interakcije između faza. Iz naziva ove faze jasno je da se ona izvodi u sprezi sa drugim fazama tokom životnog ciklusa sistema.

Rice. 1.2 Opcija za pojednostavljeni životni ciklus softverskog sistema.

Odsustvo integrisane faze u opštem životnom ciklusu ne znači da se verifikacija sprovodi samo tamo gde je to jasno naznačeno u nazivu faze (na primer, 4.2.1 i 4.2). Svaka faza se može smatrati završenom samo kada se rezultati dobijeni u ovoj fazi smatraju zadovoljavajućim, a za to je potrebno provjeriti rezultate u svakoj fazi. U sažetom životnom ciklusu, neke provjere su istaknute kao zasebne stavke kako bi se demonstrirao povećani obim, složenost i važnost ovih provjera.

Redoslijed faza životnog ciklusa za različite softverske sisteme određen je karakteristikama kao što su funkcionalnost, složenost, veličina, stabilnost, korištenje prethodno dobijenih rezultata, strategija koja se razvija i hardver.

Na sl. 1.3. prikazuje redoslijed faza razvoja softvera za pojedine komponente jednog softverskog sistema sa različitim životnim ciklusima.

Rice. 1.3 Redoslijed faza razvoja softverskih komponenti

Za komponentu W, iz skupa sistemskih zahtjeva za jedan proizvod, formira se podskup zahtjeva koji se odnosi na ovu komponentu, ti zahtjevi se koriste prilikom formiranja projekta za softversku komponentu, ovaj projekat se implementira u izvorni kod, a zatim komponenta je integrisana sa hardverom. Komponenta X prikazuje upotrebu prethodno razvijenog softvera. Komponenta Y pokazuje upotrebu jednostavne pojedinačne funkcije koja se može kodirati direktno na osnovu zahtjeva softvera. Komponenta Z pokazuje upotrebu strategije prototipa. Tipično, ciljevi izrade prototipa su bolje razumijevanje softverskih zahtjeva i smanjenje tehničkih i razvojnih rizika u kreiranju finalnog proizvoda. Početni zahtjevi se koriste kao osnova za dobijanje prototipa. Ovaj prototip se pretvara u okruženje tipično za specifičnu razvojnu upotrebu sistema. Rezultat transformacije su rafinirani podaci koji se koriste za kreiranje konačnog softverskog proizvoda.

Gotovo sve faze životnog ciklusa su kombinovane sa verifikacijom.

Razvoj softvera je nemoguć bez razumijevanja takozvanog životnog ciklusa softvera. Prosječan korisnik to možda ne mora znati, ali je preporučljivo savladati osnovne standarde (kasnije će se reći zašto je to potrebno).

Šta je životni ciklus u formalnom smislu?

Životni ciklus bilo koje aplikacije obično se podrazumijeva kao vrijeme njenog postojanja, počevši od faze razvoja pa do trenutka potpunog napuštanja upotrebe u odabranom polju primjene, pa do potpunog povlačenja aplikacije iz upotrebe.

Jednostavno rečeno, informacioni sistemi u obliku programa, baza podataka ili čak „operativnih sistema“ su traženi samo ako su podaci i mogućnosti koje pružaju ažurni.

Smatra se da se definicija životnog ciklusa ni na koji način ne odnosi na testiranje aplikacija, kao što su beta verzije, koje su najnestabilnije u radu. Sam životni ciklus softvera zavisi od mnogih faktora, među kojima jednu od glavnih uloga ima okruženje u kojem će se program koristiti. Međutim, moguće je identifikovati opšte uslove koji se koriste u definisanju koncepta životnog ciklusa.

Početni zahtjevi

• izjava o problemu;
• analiza međusobnih zahtjeva budućeg softvera za sistem;
• dizajn;
• programiranje;
• kodiranje i kompilacija;
• testiranje;
• otklanjanje grešaka;
• implementacija i održavanje softverskog proizvoda.

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

Standardi procesa životnog ciklusa softvera

Među sistemima koji unaprijed određuju uslove i zahtjeve za takve procese, danas možemo navesti samo tri glavna:

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

Za drugi međunarodni standard postoji ruski analog. Ovo je GOST R ISO/IEC 12207-2010, koji je odgovoran za sistemski i softverski inženjering. Ali životni ciklus softvera opisan u oba pravila je u suštini identičan. Ovo se objašnjava prilično jednostavno.

Vrste softvera i ažuriranja

Inače, za većinu trenutno poznatih multimedijalnih programa oni su sredstvo za čuvanje osnovnih parametara konfiguracije. Upotreba softvera ovog tipa je, naravno, prilično ograničena, ali razumijevanje općih principa rada s istim media playerima neće škoditi. A evo i zašto.

U stvari, oni uključuju životni ciklus softvera samo na nivou ažuriranja verzije samog plejera ili instaliranja kodeka i dekodera. A audio i video transkoderi su sastavni atributi svakog audio ili video sistema.

Primjer baziran na FL Studiju

U početku se virtuelni studijski sekvencer FL Studio zvao Fruity Loops. Životni ciklus softvera u njegovoj početnoj modifikaciji je istekao, ali je aplikacija donekle transformisana i dobila svoj sadašnji oblik.

Ako govorimo o fazama životnog ciklusa, prvo, u fazi postavljanja problema postavljeno je nekoliko obaveznih uslova:

• kreiranje modula bubnjeva sličnog ritam mašinama kao što je Yamaha RX, ali koristeći jednokratne semplove ili sekvence u WAV formatu, snimljene uživo u studijima;
• integracija u Windows operativne sisteme;
• mogućnost izvoza projekta u WAV, MP3 i OGG formatima;
• Kompatibilnost projekata sa dodatnom aplikacijom Fruity Tracks.

U fazi razvoja korišteni su alati programskog jezika C. Ali platforma je izgledala prilično primitivno i nije krajnjem korisniku pružila potreban kvalitet zvuka.

S tim u vezi, u fazi testiranja i otklanjanja grešaka, programeri su morali pratiti put njemačke Steinberg korporacije i primijeniti podršku za Full Duplex način rada u zahtjevima za glavni zvučni drajver. Kvalitet zvuka je postao viši i omogućava vam da mijenjate tempo, visinu i primjenjujete dodatne FX efekte u realnom vremenu.

Završetkom životnog ciklusa ovog softvera smatra se izlazak prve zvanične verzije FL Studija, koji je, za razliku od svojih predaka, već imao interfejs punopravnog sekvencera sa mogućnošću uređivanja parametara na virtuelnom 64 -kanalna mikserska konzola sa neograničenim dodavanjem audio i MIDI zapisa.

Nije tu stalo. U fazi upravljanja projektom uvedena je podrška za povezivanje plug-ina VST formata (prvo druga, a zatim treća verzija), koji je svojevremeno razvio Steinberg. Grubo govoreći, bilo koji virtuelni sintisajzer koji podržava VST-host bi se mogao povezati na program.

Nije iznenađujuće da bi uskoro bilo koji kompozitor mogao koristiti analoge "hardverskih" modela, na primjer, kompletne setove zvukova nekada popularnog Korg M1. Dalje - više. Upotreba modula kao što su Addictive Drums ili univerzalni Kontakt plugin omogućila je reprodukciju živih zvukova pravih instrumenata snimljenih sa svim nijansama artikulacije u profesionalnim studijima.

Istovremeno, programeri su pokušali da postignu maksimalan kvalitet kreiranjem podrške za ASIO4ALL drajvere, za koje se pokazalo da su glava i ramena iznad Full Duplex režima. U skladu s tim, brzina prijenosa je također porasla. Danas, kvalitet izvezene audio datoteke može biti 320 kbps pri frekvenciji uzorkovanja od 192 kHz. A ovo je profesionalni zvuk.

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

Perspektive razvoja

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

Nepotrebno je reći da bilo koji programer softvera nije zainteresiran za stvaranje kratkotrajnog proizvoda za koji je malo vjerovatno da će preživjeti na tržištu nekoliko godina. Dugoročno, svi gledaju na njegovu dugoročnu upotrebu. To se može postići na različite načine. Ali, u pravilu, gotovo svi se svode na izdavanje ažuriranja ili novih verzija programa.

Čak iu slučaju Windows OS-a, takvi trendovi se mogu vidjeti golim okom. Malo je vjerovatno da će danas postojati barem jedan korisnik koji koristi sisteme poput modifikacija 3.1, 95, 98 ili Millennium. Njihov životni ciklus je završio nakon izdavanja XP-a. Ali verzije servera zasnovane na NT tehnologijama su i dalje relevantne. Čak je i Windows 2000 danas ne samo vrlo relevantan, već u nekim instalacijskim ili sigurnosnim parametrima čak i nadmašuje najnovija dostignuća. Isto važi i za NT 4.0 sistem, kao i za specijalizovanu modifikaciju Windows Servera 2012.

Ali u odnosu na ove sisteme, podrška je i dalje deklarisana na najvišem nivou. Ali nekada senzacionalna Vista očigledno doživljava pad svog ciklusa. Ne samo da se ispostavilo da je nedovršen, već je u njemu bilo toliko grešaka i propusta u njegovom sigurnosnom sistemu da se može samo nagađati kako je tako neodrživo rješenje moglo biti pušteno na tržište softvera.

Ali ako kažemo da razvoj softvera bilo koje vrste (kontrolnog ili aplikativnog) ne miruje, možemo samo reći da se danas ne tiče samo računarskih sistema, već i mobilnih uređaja, u kojima su tehnologije koje se koriste često ispred računarski sektor. Pojava procesorskih čipova baziranih na osam jezgri nije najbolji primjer? Ali ne može se svaki laptop pohvaliti da ima takav hardver.

Neka dodatna pitanja

Što se tiče razumevanja životnog ciklusa softvera, sasvim je proizvoljno reći da se on završio u određenom trenutku, jer softverski proizvodi i dalje imaju podršku programera koji su ih kreirali. Umjesto toga, završetak se odnosi na naslijeđene aplikacije koje ne ispunjavaju zahtjeve modernih sistema i ne mogu raditi u njihovom okruženju.

Ali čak i ako se uzme u obzir tehnološki napredak, mnogi od njih mogu uskoro postati neodrživi. Tada ćete morati donijeti odluku ili da objavite ažuriranja ili da u potpunosti revidirate cijeli koncept koji je prvobitno ugrađen u softverski proizvod. Otuda i novi ciklus, koji podrazumeva promenu početnih uslova, razvojnog okruženja, testiranje i moguću dugoročnu upotrebu u određenom području.

Ali u kompjuterskoj tehnologiji danas se prednost daje razvoju automatizovanih upravljačkih sistema (ACS), koji se koriste u proizvodnji. Čak i operativni sistemi, u poređenju sa specijalizovanim programima, gube.

Ista okruženja zasnovana na Visual Basicu ostaju mnogo popularnija od Windows sistema. I uopće ne govorimo o aplikativnom softveru za UNIX sisteme. Što reći ako gotovo sve komunikacijske mreže istih Sjedinjenih Država rade isključivo za njih. Inače, sistemi poput Linuxa i Androida također su prvobitno kreirani na ovoj platformi. Stoga, najvjerovatnije, UNIX ima mnogo više izgleda od ostalih proizvoda zajedno.

Umjesto totala

Ostaje dodati da su u ovom slučaju dati samo opći principi i faze životnog ciklusa softvera. U stvari, čak i prvobitno postavljeni zadaci mogu veoma značajno varirati. Shodno tome, razlike se mogu uočiti u drugim fazama.

Ali osnovne tehnologije za razvoj softverskih proizvoda i njihovu kasniju podršku treba da budu jasne. U ostalom treba uzeti u obzir specifičnosti softvera koji se kreira, okruženja u kojima on treba da radi, mogućnosti programa koji se pružaju krajnjem korisniku ili proizvodnji i još mnogo toga.

Osim toga, ponekad životni ciklusi mogu ovisiti o relevantnosti razvojnih alata. Ako, na primjer, programski jezik zastari, niko neće pisati programe zasnovane na njemu, a još manje ih implementirati u automatizovane sisteme kontrole proizvodnje. Ovdje čak ni programeri ne dolaze do izražaja, već trgovci koji moraju pravovremeno reagirati na promjene na tržištu računara. A takvih specijalista nema toliko u svijetu. Visokokvalificirani kadrovi koji mogu držati prst na pulsu tržišta postaju najtraženiji. A oni su često takozvani “sivi kardinali” od kojih zavisi uspjeh ili neuspjeh određenog softverskog proizvoda u IT polju.

Oni možda ne razumeju uvek suštinu programiranja, ali su jasno u stanju da odrede modele životnog ciklusa softvera i trajanje njihove upotrebe, na osnovu globalnih trendova u ovoj oblasti. Učinkovito upravljanje često daje opipljivije rezultate. Da, barem PR tehnologije, oglašavanje itd. Korisniku možda neće trebati neka aplikacija, ali ako se aktivno reklamira, korisnik će je instalirati. Ovo je već, da tako kažem, podsvjesni nivo (isti efekat 25. kadra, kada se informacija stavlja u svijest korisnika nezavisno od njega).

Naravno, takve tehnologije su zabranjene u svijetu, ali mnogi od nas i ne slute da se i dalje mogu koristiti i na određeni način utjecati na podsvijest. Pogledajte samo cijenu “zombifikacije” od strane informativnih kanala ili internetskih stranica, a da ne spominjemo upotrebu moćnijih sredstava, kao što je izlaganje infrazvuku (ovo je korišteno u jednoj opernoj produkciji), zbog čega osoba može doživjeti strah ili neprikladne emocije.

Vraćajući se softveru, vrijedi dodati da neki programi koriste zvučni signal prilikom pokretanja kako bi privukli pažnju korisnika. I, kao što istraživanje pokazuje, takve aplikacije su održivije od drugih programa. Naravno, životni ciklus softvera se takođe povećava, bez obzira na to koja mu je funkcija prvobitno dodeljena. I, nažalost, mnogi programeri to koriste, š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 identifikaciju takvih prijetnji. Za sada je ovo samo teorija, ali, prema nekim analitičarima i stručnjacima, ostalo je vrlo malo do praktične primjene. Ako već stvaraju kopije neuronskih mreža ljudskog mozga, šta onda reći?

Zdravo, dragi stanovnici Habrovska! Mislim da će nekome biti zanimljivo da se prisjeti koji su modeli razvoja, implementacije i korištenja softvera postojali ranije, koji modeli se uglavnom koriste sada, zašto i šta je to zapravo. Ovo će biti moja mala tema.

U stvari, šta je to životni ciklus softvera- niz događaja koji se dešavaju sa sistemom tokom njegovog kreiranja i dalje upotrebe. Drugim riječima, ovo je vrijeme od početnog trenutka stvaranja bilo kojeg softverskog proizvoda do kraja njegovog razvoja i implementacije. Životni ciklus softvera može se predstaviti u obliku modela.

Model životnog ciklusa softvera- struktura koja sadrži akcione procese i zadatke koji se provode tokom razvoja, upotrebe i održavanja softverskog proizvoda.
Ovi modeli se mogu podijeliti u 3 glavne grupe:

1. Inženjerski pristup
2. Uzimajući u obzir specifičnosti zadatka
3. Savremene tehnologije brzog razvoja

Pogledajmo sada postojeće modele (podklase) i procijenimo njihove prednosti i nedostatke.

Model kodiranja i eliminacije grešaka

Potpuno jednostavan model, tipičan za studente. Po ovom modelu većina studenata razvija, recimo, laboratorijske radove.
Ovaj model ima sljedeći algoritam:

1. Izjava o problemu
2. Izvršenje
3. Provjera rezultata
4. Ako je potrebno, prijeđite na prvu tačku

Model takođe strašno zastarjelo. Tipičan je za 1960-1970-e, tako da praktično nema prednosti u odnosu na sljedeće modele u našoj recenziji, ali su nedostaci očigledni. Spada u prvu grupu modela.

Model životnog ciklusa softvera vodopada (vodopad)

Algoritam ove metode, koji prikazujem na dijagramu, ima niz prednosti u odnosu na algoritam prethodnog modela, ali ima i niz značajan nedostatke.

Prednosti:

• Sekvenciona implementacija faza projekta po strogo utvrđenom redosledu
• Omogućava vam da ocijenite kvalitetu proizvoda u svakoj fazi

Nedostaci:

• Nema povratnih informacija između faza
• Ne odgovara stvarnim uslovima razvoja softverskog proizvoda

Spada u prvu grupu modela.

Kaskadni model sa srednjim upravljanjem (whirlpool)

Ovaj model je po algoritmu gotovo ekvivalentan prethodnom modelu, međutim, ima povratne veze sa svakom fazom životnog ciklusa, što dovodi do vrlo značajnog nedostatka: 10 puta povećanje troškova razvoja. Spada u prvu grupu modela.

V model (test-driven razvoj)

Ovaj model ima algoritam bliži modernim metodama, ali i dalje ima niz nedostataka. To je jedna od glavnih praksi ekstremnog programiranja.

Model zasnovan na razvoju prototipa

Ovaj model je baziran na razvoju prototipova i prototipa proizvoda.
Izrada prototipa koristi se u ranim fazama životnog ciklusa softvera:

1. Pojasniti nejasne zahtjeve (UI prototip)
2. Odaberite jedno od niza idejnih rješenja (implementacija scenarija)
3. Analizirajte izvodljivost projekta

Klasifikacija prototipova:

1. Horizontalno i vertikalno
2. Jednokratna i evolutivna
3. papir i storyboards

Horizontalno prototipovi - modeliraju isključivo korisničko sučelje bez utjecaja na logiku obrade i bazu podataka.
Vertical prototipovi - testiranje arhitektonskih rješenja.
Jednokratna prototipovi - za brzi razvoj.
Evolucijski prototipovi su prva aproksimacija evolucionog sistema.

Model pripada drugoj grupi.

Spiralni model životnog ciklusa softvera

Spiralni model je proces razvoja softvera koji kombinuje i dizajn i inkrementalnu izradu prototipa kako bi se kombinovale prednosti koncepta odozdo prema gore i odozgo prema dole.

Prednosti:

• Dobijte rezultate brzo
• Povećana konkurentnost
• Promjena zahtjeva nije problem

Nedostaci:

• Nedostatak regulacije pozornice

Treća grupa uključuje modele kao što su ekstremno programiranje(XP) SCRUM, inkrementalni model(RUP), ali bih o njima u posebnoj temi.

Hvala vam puno na pažnji!

Životni ciklus programa.

Životni ciklus softvera je vremenski period koji počinje od trenutka donošenja odluke o potrebi kreiranja softverskog proizvoda i završava kada se potpuno ukloni iz upotrebe. Ovaj ciklus je proces izgradnje i razvoja softvera.

Faze životnog ciklusa:

2. Dizajn

3. Implementacija

4. Montaža, ispitivanje, testiranje

5. Implementacija (puštanje)

6. Pratnja

Postoje 2 slučaja proizvodnje softvera: 1) Softver se pravi za određenog kupca. U tom slučaju morate primijenjeni zadatak pretvoriti u programski. Morate razumjeti kako funkcionira okruženje koje treba biti automatizirano (analiza poslovnog procesa). Kao rezultat, pojavljuje se specifikacija dokumentacije zahtjeva, koja ukazuje na to koje specifične zadatke treba izvršiti. riješeno i pod kojim uslovima. Ovaj posao obavlja sistemski analitičar (analitičar poslovnih procesa).

2) Softver je razvijen za tržište. Morate provesti marketinško istraživanje i pronaći koji proizvod nije na tržištu. Ovo dolazi sa velikim rizikom. Cilj je razviti specifikaciju zahtjeva.

Dizajn

Cilj je odrediti opštu strukturu (arhitekturu) softvera. Rezultat je specifikacija softvera. Ovaj posao obavlja sistemski programer.

Implementacija

Pisanje programskog koda. Implementacija uključuje razvoj, testiranje i dokumentaciju.

Montaža, testiranje, testiranje

Kompilacija svega što su napravili različiti programeri. Testiranje cjelokupnog softverskog paketa. Otklanjanje grešaka – pronalaženje i otklanjanje uzroka grešaka. Ispitivanje – pojašnjenje tehničkih karakteristika. Kao rezultat toga, garantirano je da će program raditi.

Implementacija (izdanje)

Implementacija – kada rade za jednog kupca. Uključuje postavljanje programa na lokaciji kupca, obuku kupca, konsultacije, otklanjanje grešaka i očiglednih nedostataka. Softver mora biti otuđen - korisnik može raditi sa softverom bez učešća autora.

Izdanje – kada se softver razvija za tržište. Počinje sa fazom beta testiranja. Resp. verzija - beta verzija. Alfa testiranje je testiranje od strane ljudi iz iste organizacije koji nisu bili uključeni u razvoj programa. Beta testiranje je proizvodnja nekoliko kopija softvera i slanje potencijalnim kupcima. Cilj je ponovo provjeriti razvoj softvera.

Ako se na tržište pusti suštinski novi softver, moguće je nekoliko beta testova. Nakon beta testiranja - izdavanje komercijalne verzije.

Pratnja

Otklanjanje grešaka uočenih tokom rada. Pravljenje nebitnih poboljšanja. Akumulacija prijedloga za razvoj sljedeće verzije.

Modeli životnog ciklusa

1. Vodopad („vodopad“, kaskadni model)

2. Izrada prototipa

Prvo, ne razvija se sam softverski proizvod, već njegov prototip koji sadrži rješenje za glavne probleme s kojima se susreću programeri. Nakon uspješnog završetka razvoja prototipa, pravi se softverski proizvod razvija po istim principima. Prototip vam omogućava da bolje razumete zahteve za program koji se razvija. Koristeći prototip, kupac također može preciznije formulirati svoje zahtjeve. Programer ima priliku, koristeći prototip, da klijentu predstavi preliminarne rezultate svog rada.

3. Iterativni model

Zadatak je podijeljen na podzadatke i redoslijed njihove implementacije je određen tako da svaki sljedeći podzadatak proširuje mogućnosti softvera. Uspjeh značajno ovisi o tome koliko su zadaci podijeljeni u podzadatke i kako je redoslijed odabran. Prednosti: 1) mogućnost aktivnog učešća kupca u razvoju, ima mogućnost da razjasni svoje zahteve tokom razvoja; 2) mogućnost testiranja novorazvijenih dijelova zajedno sa prethodno razvijenim, što će smanjiti troškove složenog otklanjanja grešaka; 3) tokom razvoja možete započeti implementaciju u dijelovima.

Standardi životnog ciklusa softvera

• GOST 34.601-90
• ISO/IEC 12207:1995 (ruski ekvivalent - GOST R ISO/IEC 12207-99)

Metodologije razvoja softvera

• Racionalni objedinjeni proces (RUP).
• Microsoft Solutions Framework (MSF). Uključuje 4 faze: analizu, dizajn, razvoj, stabilizaciju, uključuje korištenje objektno orijentisanog modeliranja.
• Ekstremno programiranje ( Ekstremno programiranje, XP). Metodologija se zasniva na timskom radu i efikasnoj komunikaciji između naručioca i izvođača tokom celog projekta razvoja IP. Razvoj se provodi korištenjem sukcesivno usavršavanih prototipova.

Standard GOST 34.601-90

Standard GOST 34.601-90 predviđa sljedeće faze i faze stvaranja automatiziranog sistema:

1. Formiranje zahtjeva za govornike
   1. Pregled objekta i opravdanost potrebe izgradnje nuklearne elektrane
   2. Formiranje korisničkih zahtjeva za zvučnike
   3. Izrada izvještaja o završetku radova i prijave za razvoj NEK
2. Razvoj koncepta AC
   1. Proučavanje objekta
   2. Obavljanje potrebnog istraživačkog rada
   3. Razvoj opcija AC koncepta i odabir opcije koncepta AC koja zadovoljava zahtjeve korisnika
   4. Izrada izvještaja o obavljenom radu
3. Projektni zadaci
   1. Izrada i odobravanje tehničkih specifikacija za izgradnju nuklearnih elektrana
4. Nacrt dizajna
   1. Izrada idejnih rješenja za sistem i njegove dijelove
5. Tehnički projekat
   1. Razvoj projektantskih rješenja za sistem i njegove dijelove
   2. Izrada dokumentacije za sistem zvučnika i njegove dijelove
   3. Izrada i izrada dokumentacije za nabavku komponenti
   4. Izrada projektnih zadataka u susjednim dijelovima projekta
6. Radna dokumentacija
   1. Izrada radne dokumentacije za NEK i njene dijelove
   2. Razvoj i prilagođavanje programa
7. Puštanje u rad
   1. Priprema objekta automatizacije
   2. Obuka osoblja
   3. Kompletan set zvučnika sa isporučenim proizvodima (softver i hardver, softverski i hardverski sistemi, informacioni proizvodi)
   4. Građevinski i instalaterski radovi
   5. Puštanje u rad
   6. Izvođenje preliminarnih ispitivanja
   7. Izvođenje probnog rada
   8. Izvođenje testova prihvata
8. AC podrška.
   1. Izvođenje radova u skladu sa garantnim obavezama
   2. Postgarantni servis

Skica, tehnički projekti i radna dokumentacija konzistentna su konstrukcija sve preciznijih projektantskih rješenja. Moguće je isključiti fazu „Projekt skice“ i pojedinačne faze rada u svim fazama, objediniti faze „Tehnički projekat“ i „Radna dokumentacija“ u „Tehnički detaljni projekat“, izvoditi različite faze i raditi paralelno , i uključiti dodatne.

Ovaj standard nije u potpunosti prikladan za trenutna dešavanja: mnogi procesi nisu dovoljno reflektovani, a neke odredbe su zastarjele.

ISO/IEC 12207/ standard i njegova primjena

Standard ISO/IEC 12207:1995 “Informaciona tehnologija – Procesi životnog ciklusa softvera” je glavni regulatorni dokument koji reguliše sastav procesa životnog ciklusa softvera. Definira strukturu životnog ciklusa koja sadrži procese, aktivnosti i zadatke koji se moraju završiti tokom kreiranja softvera.

Svaki proces je podijeljen na skup akcija, svaka akcija na skup zadataka. Svaki proces, aktivnost ili zadatak inicira i izvršava drugi proces po potrebi i ne postoje unaprijed određene sekvence izvršavanja. Veze između ulaznih podataka su sačuvane.

Procesi životnog ciklusa softvera

• osnovno:
  • Akvizicija (radnje i zadaci kupca koji kupuje softver)
  • Isporuka (radnje i zadaci dobavljača koji isporučuje kupca softverskim proizvodom ili uslugom)
  • Razvoj (radnje i zadaci koje izvodi programer: izrada softvera, izrada projektne i operativne dokumentacije, priprema materijala za testiranje i obuku itd.)
  • Rad (radnje i zadaci operatera - organizacije koja upravlja sistemom)
  • Održavanje (radnje i zadaci koje obavlja prateća organizacija, odnosno služba podrške). Podrška - izmjena softvera u cilju ispravljanja grešaka, poboljšanja produktivnosti ili prilagođavanja promjenjivim radnim uvjetima ili zahtjevima.
• Auxiliary
  • Dokumentacija (formalizovani opis informacija kreiranih tokom životnog ciklusa softvera)
  • Upravljanje konfiguracijom (primjena administrativnih i tehničkih procedura tokom životnog ciklusa softvera za određivanje statusa softverskih komponenti i upravljanje njihovim modifikacijama).
  • Osiguranje kvaliteta (pružanje garancija da su informacioni sistem i procesi njegovog životnog ciklusa u skladu sa specificiranim zahtjevima i odobrenim planovima)
  • Verifikacija (utvrđivanje da softverski proizvodi koji su rezultat neke radnje u potpunosti zadovoljavaju zahtjeve ili uslove nametnute prethodnim radnjama)
  • Certifikacija (utvrđivanje potpunosti usklađenosti navedenih zahtjeva i kreiranog sistema sa njihovom specifičnom funkcionalnom namjenom)
  • Zajednička procjena (procjena statusa radova na projektu: kontrola planiranja i upravljanja resursima, osobljem, opremom, alatima)
  • Revizija (utvrđivanje usklađenosti sa zahtjevima, planovima i uslovima ugovora)
  • Rješavanje problema (analiza i rješavanje problema, bez obzira na njihovo porijeklo ili izvor, koji se otkriju tokom razvoja, rada, održavanja ili drugih procesa)
• Organizacijski
  • Kontrola (radnje i zadaci koje može izvršiti svaka strana koja upravlja svojim procesima)
  • Kreiranje infrastrukture (izbor i održavanje tehnologije, standarda i alata, izbor i instalacija hardvera i softvera koji se koriste za razvoj, rad ili održavanje softvera)
  • Poboljšanje (procjena, mjerenje, kontrola i poboljšanje procesa životnog ciklusa)
  • Obuka (početna obuka i naknadni stalni razvoj osoblja)

Svaki proces uključuje niz radnji. Na primjer, proces nabavke pokriva sljedeće aktivnosti:

1. Početak akvizicije
2. Priprema ponuda
3. Priprema i usklađivanje ugovora
4. Nadzor nad aktivnostima dobavljača
5. Prijem i završetak radova

Svaka aktivnost uključuje niz zadataka. Na primjer, priprema ponude ponuda treba da uključuje:

1. Formiranje sistemskih zahtjeva
2. Generisanje liste softverskih proizvoda
3. Uspostavljanje uslova i sporazuma
4. Opis tehničkih ograničenja (operativno okruženje sistema, itd.)

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

Model životnog ciklusa softvera- struktura koja određuje redoslijed izvršenja i odnose između procesa, akcija i zadataka kroz životni ciklus. Model životnog ciklusa zavisi od specifičnosti, obima i složenosti projekta i specifičnih uslova u kojima sistem nastaje i funkcioniše.

Standard GOST R ISO/IEC 12207-99 ne nudi specifičan model životnog ciklusa. Njegove odredbe su zajedničke svim modelima životnog ciklusa, metodama i tehnologijama za kreiranje IP-a. On opisuje strukturu procesa životnog ciklusa bez specificiranja kako implementirati ili završiti 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 su tačke završetka posla i donošenja odluka.

Stage- dio procesa kreiranja softvera, ograničen određenim vremenskim okvirom i završava izdavanjem određenog proizvoda (modeli, softverske komponente, dokumentacija), određen zahtjevima navedenim za ovu fazu.

U svakoj fazi može se izvesti nekoliko procesa definisanih standardom GOST R ISO/IEC 12207-99, i obrnuto, isti proces se može izvesti u različitim fazama. Odnos između procesa i faza je također određen modelom životnog ciklusa softvera koji se koristi.

Modeli životnog ciklusa softvera

Model životnog ciklusa je struktura koja definira slijed izvršenja i odnose procesa, radnji i zadataka koji se izvode tokom životnog ciklusa. Model životnog ciklusa zavisi od specifičnosti informacionog sistema i specifičnih uslova u kojima on nastaje i funkcioniše.

Do danas su sljedeći glavni modeli životnog ciklusa postali najrasprostranjeniji:

• Model problema;

• kaskadni model (ili sistem) (70-85);

• spiralni model (sadašnji).

Model problema

Prilikom razvoja sistema "odozdo prema gore" od pojedinačnih zadataka do čitavog sistema (modela zadatka), neminovno se gubi jedinstven pristup razvoju, a problemi nastaju pri povezivanju pojedinih komponenti sa informacijama. Po pravilu, kako se broj zadataka povećava, poteškoće se povećavaju, te je potrebno stalno mijenjati postojeće programe i strukture podataka. Usporava se brzina razvoja sistema, što usporava razvoj same organizacije. Međutim, u nekim slučajevima ova tehnologija može biti preporučljiva:

• Ekstremna hitnost (problemi se moraju nekako riješiti; onda će sve morati ponovo);

• Eksperimentisanje i prilagođavanje kupca (algoritmi nisu jasni, rešenja se pronalaze metodom pokušaja i grešaka).

Opšti zaključak: na ovaj način je nemoguće stvoriti dovoljno veliki, efikasan informacioni sistem.

Kaskadni model

Kaskadni modelživotni ciklus je 1970. godine predložio Winston Royce. Omogućava uzastopnu implementaciju svih faza projekta po strogo utvrđenom redoslijedu. Prelazak u sljedeću fazu znači potpuni završetak radova u prethodnoj fazi (slika 1). Zahtjevi utvrđeni u fazi formiranja zahtjeva striktno su dokumentirani u obliku tehničkih specifikacija i evidentirani za cjelokupni razvoj projekta. Svaka faza kulminira objavljivanjem kompletne dokumentacije koja je dovoljna da omogući nastavak razvoja od strane drugog razvojnog tima.

Pozitivni aspekti korištenja kaskadnog pristupa su sljedeći:

• u svakoj fazi izrađuje se kompletna projektna dokumentacija koja zadovoljava kriterije kompletnosti i konzistentnosti;

• faze rada koje se izvode u logičnom slijedu omogućavaju planiranje vremena završetka svih radova i odgovarajućih troškova.

Faze projekta prema modelu vodopada:

1. Formiranje zahtjeva;
2. Dizajn;
3. Implementacija;
4. Testiranje;
5. Implementacija;
6. Rad i održavanje.

Rice. 1. Kaskadna razvojna shema

Kaskadni pristup se dobro pokazao u izgradnji informacionih sistema, za koje se na samom početku razvoja mogu sasvim precizno i ​​potpuno formulisati svi zahtevi kako bi se programerima dala sloboda da ih što bolje implementiraju sa tehničke tačke gledišta. pogled. Složeni računski sistemi, sistemi u realnom vremenu i drugi slični zadaci spadaju u ovu kategoriju. Međutim, u procesu korištenja ovog pristupa otkriven je niz njegovih nedostataka, uzrokovanih prvenstveno činjenicom da se stvarni proces stvaranja sistema nikada u potpunosti ne uklapa u tako krutu shemu. Tokom procesa kreiranja postojala je stalna potreba za vraćanjem na prethodne faze i pojašnjavanjem ili revizijom ranije donesenih odluka. Kao rezultat toga, stvarni proces kreiranja softvera dobio je sljedeći oblik (slika 2):

Rice. 2. Pravi proces razvoja softvera koristeći vodopad šemu

Glavni nedostatak kaskadnog pristupa je značajno kašnjenje u dobijanju rezultata. Koordinacija rezultata sa korisnicima vrši se samo na tačkama planiranim nakon završetka svake faze rada, zahtjevi za informacionim sistemima su „zamrznuti“ u obliku tehničkih specifikacija za cijelo vrijeme nastanka. Stoga korisnici mogu davati svoje komentare tek nakon što je rad na sistemu u potpunosti završen. Ako su zahtjevi netačno navedeni ili se mijenjaju tokom dugog perioda razvoja softvera, korisnici završavaju sa sistemom koji ne zadovoljava njihove potrebe. Modeli (funkcionalni i informativni) automatiziranog objekta mogu zastarjeti istovremeno s njihovim odobrenjem. Suština sistematskog pristupa razvoju IS-a leži u njegovoj dekompoziciji (raščlanjivanju) na automatizovane funkcije: sistem je podeljen na funkcionalne podsisteme, koji su zauzvrat podeljeni na podfunkcije, podeljeni na zadatke itd. Proces particioniranja nastavlja se sve do specifičnih procedura. U isto vrijeme, automatizirani sistem održava holistički pogled u kojem su sve komponente međusobno povezane. Dakle, glavna prednost ovog modela je sistemski razvoj, a glavni nedostaci su sporost i skup.

Spiralni model

Da bi se ovi problemi prevazišli, predloženo je spiralni modelživotni ciklus (Slika 3), koji je sredinom 1980-ih razvio Barry Boehm. Zasnovan je na početnim fazama životnog ciklusa: analiza i dizajn. U ovim fazama se izvodljivost tehničkih rješenja testira izradom prototipova.

Prototip- komponenta operativnog softvera koja implementira pojedinačne funkcije i eksterna sučelja. Svaka iteracija odgovara kreiranju fragmenta ili verzije softvera, pri čemu se pojašnjavaju ciljevi i karakteristike projekta, ocjenjuje kvalitet dobijenih rezultata i planira rad sljedeće iteracije.

Svaka iteracija predstavlja kompletan razvojni ciklus, što rezultira izdavanjem interne ili eksterne verzije proizvoda (ili podskupa konačnog proizvoda) koja se poboljšava iz iteracije u iteraciju kako bi postala kompletan sistem.

Svaki zavoj spirale odgovara kreiranju fragmenta ili verzije softvera, gdje se razjašnjavaju ciljevi i karakteristike projekta, utvrđuje njegova kvaliteta i planira rad sljedećeg zavoja spirale. Tako se detalji projekta produbljuju i dosljedno preciziraju, te se kao rezultat bira razumna opcija koja se dovodi u realizaciju.

Razvoj po iteracijama odražava objektivno postojeći spiralni ciklus stvaranja sistema. Nepotpuni završetak posla u svakoj fazi omogućava vam da pređete na sljedeću fazu bez čekanja na potpuni završetak posla u trenutnoj. Sa metodom iterativnog razvoja, posao koji nedostaje može se završiti u sljedećoj iteraciji. Glavni zadatak je da se korisnicima sistema što brže pokaže izvodljiv proizvod, čime se aktivira proces razjašnjavanja i dopunjavanja zahtjeva.

Glavni problem spiralnog ciklusa je određivanje trenutka prelaska u sljedeću fazu. Da bi se to riješilo, potrebno je uvesti vremenska ograničenja za svaku fazu životnog ciklusa. Tranzicija se odvija po planu, čak i ako svi planirani radovi nisu završeni. Plan je napravljen na osnovu statističkih podataka dobijenih u prethodnim projektima i ličnog iskustva programera.

Slika 3. Spiralni model životnog ciklusa IC-a

Jedan od mogućih pristupa razvoju softvera u okviru modela spiralnog životnog ciklusa je RAD (Rapid Application Development) metodologija, koja je nedavno postala široko rasprostranjena. Ovaj termin se obično odnosi na proces razvoja softvera koji sadrži 3 elementa:

• mali tim programera (od 2 do 10 ljudi);

• kratak, ali pažljivo razrađen proizvodni raspored (od 2 do 6 mjeseci);

• iterativni ciklus u kojem programeri, kako aplikacija počinje da se oblikuje, traže i implementiraju u proizvod zahtjeve primljene kroz interakciju s kupcem.

Životni ciklus softvera prema RAD metodologiji sastoji se od četiri faze:

• definicija zahtjeva i faza analize;

• faza projektovanja;

• faza implementacije;

• faza implementacije.

U svakoj iteraciji se evaluira sljedeće:

• rizik od prekoračenja projektnih rokova i troškova;
• potreba da se izvrši još jedna iteracija;
• stepen potpunosti i tačnosti razumevanja sistemskih zahteva;
• izvodljivost okončanja projekta.

Prednosti iterativnog pristupa:

• Iterativni razvoj uvelike pojednostavljuje unošenje promjena u projekat kada se promijene zahtjevi kupaca.
• Pri upotrebi spiralnog modela, pojedinačni elementi informacionog sistema se postepeno integrišu u jedinstvenu celinu. Sa iterativnim pristupom, integracija se događa gotovo kontinuirano. Budući da integracija počinje sa manje elemenata, mnogo je manje problema tokom njene implementacije (prema nekim procjenama, kada se koristi model razvoja vodopada, integracija čini do 40% svih troškova na kraju projekta).
• Iterativni razvoj pruža veću fleksibilnost u upravljanju projektima, čineći mogućim taktičke promjene proizvoda koji se razvija.
• Iterativni pristup pojednostavljuje ponovnu upotrebu komponenti (implementira pristup programiranju zasnovan na komponentama). To je zato što je mnogo lakše identificirati zajedničke dijelove projekta kada su već djelimično razvijeni nego pokušati ih identificirati na samom početku projekta. Analiza dizajna nakon nekoliko početnih iteracija otkriva uobičajene komponente za višekratnu upotrebu koje će biti poboljšane u narednim iteracijama.
• Spiralni model omogućava pouzdaniji i stabilniji sistem. To je zato što kako se sistem razvija, greške i slabosti se otkrivaju i ispravljaju na svakoj iteraciji. Istovremeno se mogu podesiti kritični parametri performansi, što je u slučaju kaskadnog modela moguće samo prije implementacije sistema.
• Iterativni pristup omogućava poboljšanje procesa razvoja - analiza koja se sprovodi na kraju svake iteracije omogućava nam da procenimo šta treba da se promeni u razvojnoj organizaciji i da to poboljšamo u sledećoj iteraciji.