Životni ciklus softvera (Software life cycle). Životni ciklus programa Pojam životnog ciklusa programa i njegovih faza

Tema: Klasični i fleksibilni LCPP modeli: definicija, opis, razlikovna obilježja, slijed faza. Metode odabira LCPP modela pri razvoju softvera za različita tematska područja.


Izvor informacija https://www.intuit.ru/studies/courses/3632/874/print_lecture/14297

Modeli i faze životnog ciklusa softvera

Model životnog ciklusa softvera shvaća se kao struktura koja definira redoslijed izvršavanja i odnose 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 nudi određeni model životnog ciklusa i metode razvoja softvera. Njegove su odredbe općenite za sve modele životnog ciklusa, metode i tehnologije razvoja softvera. Standard opisuje strukturu procesa životnog ciklusa softvera, ali ne specificira kako implementirati ili izvesti akcije 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 kombiniranih u stupnjeve (faze), č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 određenim vremenskim okvirom i završava izdavanjem određenog proizvoda (softverski modeli, softverske komponente, dokumentacija itd.), određen zahtjevima određeno za ovu fazu. Izdvojene su faze izrade softvera iz razloga racionalnog planiranja i organizacije rada koji završava zadanim 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 podfaze: detaljni dizajn, kodiranje);
  4. testiranje (može se podijeliti na samostalno i integrirano testiranje i integraciju);
  5. puštanje u rad (implementacija);
  6. rad i održavanje;
  7. razgradnja.

Neki stručnjaci uvode dodatnu početnu fazu - analiza izvodljivosti sustava. Ovdje mislimo na hardverski i softverski sustav za koji se kreira, kupuje ili modificira softver.

Faza formiranja softverskih zahtjeva jedna je od najvažnijih i u značajnoj (čak odlučujućoj!) mjeri određuje uspjeh cijelog projekta. Početak ove faze je primitak odobrene i potvrđene arhitekture sustava, uključujući osnovne dogovore o raspodjeli funkcija između hardvera i softvera. Ovaj dokument također mora sadržavati potvrdu opća ideja o funkcioniranju softvera, uključujući osnovne dogovore o raspodjeli funkcija između osobe i sustava.

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

  1. Planiranje rada prije rada na projektu. Glavni ciljevi faze su određivanje razvojnih ciljeva, preliminarno 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 raspodjele funkcija među odjelima i zaposlenicima, identifikacija funkcionalnih interakcija između odjela, tokovi informacija unutar i između odjela, objekti izvan organizacije i vanjski informacijski utjecaji, analiza postojećih sredstava za automatizaciju aktivnosti organizacije.

    3. Izrada modela aktivnosti organizacije (objekta), koja uključuje obradu anketnog materijala i izradu dvije vrste modela:

    • model "KAKO JEST" ("kakav jest"), koji odražava trenutno stanje stvari u organizaciji u vrijeme ankete i omogućuje razumijevanje kako organizacija funkcionira, kao i identificiranje uskih grla i formuliranje prijedloga za poboljšanje situacija;
    • model "TO-BE" ("kako bi trebalo biti"), odražavajući ideju o novim tehnologijama za organizaciju.

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. Imajte na umu da konstruirani modeli imaju neovisne praktični značaj, bez obzira hoće li poduzeće razviti i implementirati informacijski sustav, jer uz njihovu pomoć možete osposobiti zaposlenike i poboljšati poslovne procese poduzeća.

Rezultat završetka faze generiranja 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 faze.

  1. Izrada projekta softverskog sustava. U ovoj fazi daje se odgovor na pitanje “Što treba učiniti”. budući sustav?", naime: arhitektura sustava, njegove funkcije, vanjski radni uvjeti, sučelja i raspodjela funkcija između korisnika i sustava, zahtjevi za softver i informacijske komponente, sastav izvođača i rokovi izrade, plan debugiranja softvera i kontrole kvalitete.

    Osnovu projekta sustava čine modeli projektiranog sustava koji se grade po modelu “TO-BE”. Rezultat razvoja projekta sustava mora biti odobrena i potvrđena specifikacija programskih 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 se daje 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, intermodularnih sučelja za podatke i upravljanje;
  • specifikacija svake softverske komponente, naziv, svrha, pretpostavke, dimenzije, redoslijed poziva, ulazni i izlazni podaci, pogreške 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šnjeg procesora, memorija itd.);
  • provjera potpunosti, dosljednosti, izvedivosti i valjanosti zahtjeva;
  • preliminarni plan za integraciju i uklanjanje pogrešaka, plan za korisnički priručnik i testiranje prihvatljivosti.

Završetak faze detaljnog dizajna je kontrola projekta od kraja do kraja ili kritična analiza projekta blok po blok.

Faza provedbe – završetak sljedećih radova.

  1. Razvoj provjerene detaljne specifikacije svake potprograma (blok od najviše 100 početnih jezičnih naredbi visoke razine).

    Vanjske specifikacije moraju sadržavati sljedeće informacije:

    • naziv modula - označava naziv koji se koristi za pozivanje modula (za modul s više ulaza moraju postojati posebne specifikacije za svaki ulaz);
    • funkcija – dana je definicija funkcije ili funkcija koje obavlja modul;
    • popis parametara (broj i redoslijed) proslijeđenih modulu;
    • ulazni parametri – točan opis svih podataka koje vraća modul (mora biti definirano ponašanje modula pod svim ulaznim uvjetima);
    • vanjski učinci (ispis poruke, čitanje zahtjeva s terminala itd.).
  2. Projektiranje logike modula i programiranje (kodiranje) modula.
  3. Provjera ispravnosti modula.
  4. Testiranje modula.
  5. Opis baze podataka do razine pojedinačnih parametara, znakova i bitova.
  6. Plan prijemnog ispita.
  7. Upute za korištenje.
  8. Preliminarni plan za integraciju i otklanjanje pogrešaka. Sadržaj sljedećih faza u osnovi se podudara s odgovarajućim procesima životnog ciklusa softvera. Općenito, tehnološke faze razlikuju se polazeći od razumnog i racionalnog planiranja i organizacije rada. Mogući odnos između faza rada i procesa životnog ciklusa softvera prikazan je na slici.


Riža. 1.

Vrste modela životnog ciklusa softvera

Model vodopada (klasični životni ciklus)

Ovaj model svoj izgled duguje W. Royceu (1970.). Model ima i drugo ime - vodopad. Posebnost modela je da se prijelaz na sljedeću fazu provodi tek nakon što je rad u prethodnoj fazi potpuno završen; Nema povrata novca za završene etape.


Riža. 2.

Zahtjevi za razvijeni softver, utvrđeni u fazama formiranja i analize, strogo su dokumentirani u obliku tehničkih specifikacija i evidentirani tijekom cijelog razvoja projekta. Svaka faza završava izdavanjem kompletne dokumentacije (TOR, EP, TP, RP), dostatne da razvoj nastavi drugi razvojni tim. Kriterij kvalitete izrade kod ovog pristupa je točnost ispunjavanja tehničkih specifikacija. Glavni fokus programera je na postizanju optimalnih vrijednosti tehničke karakteristike razvijen softver - performanse, količina zauzete memorije itd.

Prednosti kaskadni model:

  • u svakoj fazi formira se kompletan skup projektna dokumentacija, ispunjavanje kriterija cjelovitosti i dosljednosti;
  • izvedeno u logičan slijed faze rada omogućuju planiranje vremena završetka svih radova i odgovarajućih troškova.

Kaskadni pristup dobro se pokazao u izgradnji softverskih sustava, za koje se svi zahtjevi mogu potpuno i jasno formulirati na samom početku projekta. Sve dok je sve to kontrolirano standardima i raznim državnim prijemnim komisijama, shema dobro funkcionira.

Mane kaskadni model:

  • Pogreške se identificiraju i uklanjaju samo u fazi testiranja, što može potrajati značajno vrijeme;
  • pravi projekti često zahtijevaju odstupanja od standardnog slijeda koraka;
  • ciklus se temelji na preciznoj formulaciji početnih zahtjeva za softver; u stvarnosti, na početku projekta, zahtjevi kupca su samo djelomično određeni;
  • rezultati rada dostupni su naručitelju tek po završetku projekta.

Iterativni model životnog ciklusa PS-a

S porastom komercijalnih projekata postalo je jasno da nije uvijek moguće detaljno razraditi dizajn budućeg sustava, budući da se mnogi aspekti njegovog funkcioniranja u dinamičnim područjima djelatnosti (poslovanja) mijenjaju tijekom izrade sustava. Bilo je potrebno promijeniti proces razvoja kako bi se osiguralo da su potrebni ispravci napravljeni nakon završetka bilo koje faze razvoja. Tako se pojavio iterativni model životnog ciklusa PS, nazvan model s međukontrolom ili model s cikličkim ponavljanjem faza.


Riža. 3.

U iterativnom modelu, nedostaci dizajna i programiranja mogu se kasnije eliminirati djelomičnim povratkom na prethodnu fazu. Što je niža stopa otkrivanja pogreške, to je skuplje popraviti je. Ako se trošak truda potrebnog za otkrivanje i uklanjanje pogrešaka u fazi kodiranja uzme kao jedan, tada će trošak identificiranja i uklanjanja pogrešaka u fazi razvoja zahtjeva biti 5-10 puta manji, a trošak identificiranja i uklanjanja pogrešaka u faza održavanja bit će 20 puta manja.


Riža. 4.

U takvoj situaciji faza formuliranja zahtjeva, izrade specifikacija i izrade plana sustava postaje od velike važnosti. Softverski arhitekti osobno su odgovorni za sve naknadne promjene dizajna. Opseg dokumentacije seže na tisuće stranica, a broj sastanaka za odobravanje je ogroman. Mnogi projekti nikada ne napuste fazu planiranja, padajući u "paralizu analize". Jedan od moguće načine Iznimka u takvim situacijama je izrada prototipa (prototipiranje).

Izgled

Često kupac ne može formulirati zahtjeve za unos, obradu ili izlaz podataka za budući softverski proizvod. Programer može sumnjati u prikladnost proizvoda za operativni sustav, oblik dijaloga s korisnikom ili učinkovitost algoritma. U takvim slučajevima preporučljivo je koristiti prototipe. Glavna svrha izrade prototipova je uklanjanje nesigurnosti u zahtjevima kupaca. Layout (prototyping) je proces izrade modela potrebnog proizvoda.

Model može imati sljedeće oblike.

  1. Raspored na papiru (nacrtani dijagram dijaloga između čovjeka i stroja) ili raspored na računalu.
  2. Radni izgled koji implementira neke od potrebnih funkcija.
  3. Postojeći program čiju izvedbu treba poboljšati.

Kao što je prikazano na slici, izrada prototipova temelji se na ponovljenim ponavljanjima koja uključuju klijenta i programera.


Riža. 5.

Redoslijed radnji tijekom izrade prototipa prikazan je na slici. Izrada prototipova počinje prikupljanjem i razjašnjavanjem zahtjeva za softverski sustav koji se stvara. Programer i kupac zajednički određuju ciljeve softvera, utvrđuju koji su zahtjevi poznati, a koje tek treba definirati. Zatim se provodi brzo projektiranje. Fokusira se na karakteristike koje bi trebale biti vidljive korisniku. Brzi dizajn dovodi do izgradnje izgleda. Izgled procjenjuje kupac i koristi se za pojašnjenje softverskih zahtjeva. Iteracije se nastavljaju sve dok mockup ne otkrije sve zahtjeve kupca i omogući dizajneru da shvati što treba učiniti.

Prednost izrade prototipa je mogućnost da se osigura utvrđivanje kompletnih zahtjeva sustava. Nedostaci rasporeda:

  • kupac može zamijeniti dizajn za proizvod;
  • razvojni programer može zamijeniti model za proizvod.

Treba objasniti suštinu nedostataka. Kada kupac vidi radnu verziju softvera, više ne shvaća da u potrazi za radnom verzijom softvera, mnoga pitanja kvalitete i kvalitete ostaju neriješena. pogodnost podrške sustava. Kada razvojni programer kaže kupcu o tome, odgovor može biti ogorčenje i zahtjev za brzom transformacijom izgleda u radni proizvod. To ima negativan utjecaj na upravljanje razvojem softvera.


Riža. 6.

S druge strane, kako bi brzo dobili radni izgled, programer često čini određene kompromise. Na primjer, programski jezici možda nisu najprikladniji ili operativni sustav. Za jednostavnu demonstraciju može se koristiti neučinkovit (jednostavan) algoritam. Nakon nekog vremena, programer zaboravi na razloge zašto ti alati nisu prikladni. Kao rezultat toga, odabrana opcija daleko od idealne integrirana je u sustav.

Prije razmatranja drugih modela životnog ciklusa softvera koji su zamijenjeni kaskadni model, trebali bismo se usredotočiti na strategije za projektiranje softverskih sustava. Strategija dizajna softvera uvelike određuje model životnog ciklusa softvera.

Strategije dizajna softvera

Postoje tri strategije za projektiranje softverskih sustava:

  • jednostruki prolaz (gore razmotrena kaskadna strategija) – linearni slijed faza projektiranja;
  • inkrementalna strategija. Na početku procesa svi korisnici i zahtjevi sustava, ostatak konstrukcije izvodi se kao niz verzija. Prva verzija implementira dio planiranih značajki, sljedeća verzija implementira dodatne značajke itd. dok se ne dobije kompletan sustav;
  • evolucijska strategija. Sustav je također izgrađen kao niz verzija, ali nisu svi zahtjevi definirani na početku procesa. Zahtjevi se usavršavaju kako se verzije razvijaju. Karakteristike strategija dizajna softvera u skladu sa zahtjevima standarda IEEE/EIA 12207 dane su u tablici 1.

Inkrementalni model

Inkrementalni model klasičan je primjer strategije inkrementalnog dizajna. Kombinira elemente sekvencijalnog modela vodopada s iterativnom filozofijom izgleda (predložio B. Boehm kao poboljšanje kaskadni model). Svaki linearni niz ovdje proizvodi isporučeni softverski inkrement. Na primjer, softver za obradu teksta u prvom koraku (verzija) implementira osnovne funkcije obrade datoteka, funkcije uređivanja i dokumentacije; u 2. inkrementu - složenije mogućnosti uređivanja i dokumentiranja; u 3. koraku – provjera pravopisa i gramatike; u 4. inkrementu – mogućnosti izgleda stranice.

Prvo povećanje rezultira osnovnim proizvodom koji implementira osnovne zahtjeve (iako mnogi pomoćni zahtjevi ostaju neprovedeni). Sljedeći plan povećanja uključuje modificiranje osnovnog proizvoda za pružanje dodatnih značajki i funkcionalnosti.

Po svojoj prirodi, inkrementalni proces je iterativan, ali, za razliku od izrade prototipova, inkrementalni model daje radni proizvod pri svakom inkrementu.

Dijagram takvog modela životnog ciklusa softvera prikazan je na slici. Jedna od modernih implementacija inkrementalnog pristupa je ekstremno programiranje (usmjereno na vrlo male inkremente funkcionalnosti).


Riža. 7.

Spiralni model životnog ciklusa softvera

Spiralni model je klasičan primjer primjene evolucijske strategije dizajna. Model (autor B. Boehm, 1988.) temelji se na najboljim svojstvima klasičnog životnog ciklusa i izrade prototipa, kojemu je dodan novi element - analiza rizika, koja nedostaje u ovim paradigmama. Model definira četiri radnje, predstavljene s četiri kvadranta spirale.


Riža. 8.
  1. Planiranje – definiranje ciljeva, opcija i ograničenja.
  2. Analiza rizika – analiza opcija i prepoznavanje/odabir rizika.
  3. Dizajn – razvoj proizvoda sljedeće razine.
  4. Evaluacija – procjena kupca o trenutnim rezultatima dizajna.

Integracijski aspekt spiralni model je očigledan kada se uzme u obzir radijalna dimenzija spirale. Sa svakim ponavljanjem, sve više i više se gradi u spiralu pune verzije P.S. U prvom zavoju spirale utvrđuju se početni ciljevi, mogućnosti i ograničenja, prepoznaje i analizira rizik. Ako analiza rizika pokaže nesigurnost u zahtjevima, izrada prototipa, koja se koristi u kvadrantu dizajna, dolazi u pomoć razvojnom programeru i kupcu.

Simulacija se može koristiti za daljnju identifikaciju problematičnih i pročišćenih zahtjeva. Naručitelj ocjenjuje inženjerski (dizajnerski) rad i daje prijedloge za izmjene (kvadrant za ocjenu naručitelja). Sljedeća faza planiranja i analize rizika temelji se na prijedlozima korisnika. U svakom spiralnom ciklusu, rezultati analize rizika formiraju se u obliku "nastavi, ne nastavi". Ako je rizik prevelik, projekt se može zaustaviti.

U većini slučajeva spirala se nastavlja, a svaki korak pomiče programere ka višem opći model sustava. Svaki spiralni ciklus zahtijeva dizajn (donji desni kvadrant), koji se može implementirati klasičnim životnim ciklusom ili izradom prototipa. Imajte na umu da se broj razvojnih aktivnosti (koje se događaju u donjem desnom kvadrantu) povećava kako se udaljavamo od središta spirale.

Ove radnje su numerirane i imaju sljedeći sadržaj:

  1. – prikupljanje početnih zahtjeva i planiranje projekta;
  2. – isti rad, ali prema preporuci kupca;
  3. – analiza rizika na temelju početnih zahtjeva;
  4. – analiza rizika na temelju reakcije kupca;
  5. – prijelaz na integrirani sustav;
  6. – početni izgled sustava;
  7. – sljedeća razina izgleda;
  8. – projektirani sustav;
  9. – procjena kupca.

Prednosti spiralni model:

  1. najrealnije (u obliku evolucije) odražava razvoj softver;
  2. omogućuje eksplicitno uzimanje u obzir rizika u svakoj fazi razvoja razvoja;
  3. uključuje korak sustavnog pristupa u strukturi iterativnog razvoja;
  4. koristi simulaciju za smanjenje rizika i poboljšanje softverskih proizvoda.

Mane spiralni model:

  • komparativna novost (nema dovoljno statistike o učinkovitosti modela);
  • povećani zahtjevi za kupca;
  • Poteškoće u praćenju i upravljanju vremenom razvoja.

Spiralni model razvojnog procesa danas je najčešći. Njegove najpoznatije varijante su RUP (Rational Unified Process) tvrtke Rational i MSF (Microsoft Solution Framework). Kao jezik za modeliranje koristi se UML (Unified Modeling Language). Stvaranje sustava trebalo bi se provoditi iterativno, krećući se spiralno i, prolazeći kroz iste faze, u svakom koraku pojašnjavajući karakteristike budućeg proizvoda. Čini se da je sada sve u redu: planira se samo ono što se može predvidjeti, razvija se ono što je planirano, a korisnici se počinju upoznavati s proizvodom unaprijed, imajući priliku napraviti potrebne prilagodbe.

Međutim, za to su potrebna vrlo velika sredstva. Doista, ako je prije bilo moguće stvarati i raspuštati skupine stručnjaka prema potrebi, sada svi moraju stalno sudjelovati u projektu: arhitekti, programeri, testeri, instruktori itd. Štoviše, napori različitih skupina moraju biti sinkronizirani kako bi pravodobno odražavati odluke o dizajnu i izvršiti potrebne promjene.

Racionalni objedinjeni proces

Racionalno unificirani proces(Rational Unified Process, RUP) jedna je od najboljih metodologija razvoja softvera. Na temelju iskustva mnogih uspješnih softverskih projekata, RUP vam omogućuje stvaranje složenih softverskih sustava temeljenih na metodama industrijskog razvoja. Pozadina razvoja RUP-a datira iz ranih 1980-ih. u Rational Software Corporation. Početkom 2003. Rational je preuzeo IBM. Jedan od glavnih stupova na koje se RUP oslanja je proces kreiranja modela pomoću Unified Modeling Language (UML).

RUP je jedna od spiralnih metodologija razvoja softvera. Metodologiju podržava i razvija Rational Software. Kao modelni jezik u zajednička baza znanja, koristi se Unified Modeling Language (UML). Iterativni i inkrementalni razvoj softvera u RUP-u uključuje podjelu projekta na nekoliko projekata koji se provode uzastopno, a svaka razvojna iteracija jasno je definirana skupom ciljeva koji se moraju postići na kraju iteracije. Konačna iteracija pretpostavlja da se skup ciljeva iteracije mora točno podudarati sa skupom ciljeva koje je specificirao kupac proizvoda, odnosno moraju biti ispunjeni svi zahtjevi.

Proces uključuje evoluciju modela; iteracija razvojnog ciklusa jedinstveno odgovara specifičnoj verziji softverskog modela. Svaka iteracija sadrži kontrole životni ciklus softvera: analiza i dizajn (modeliranje), implementacija, integracija, testiranje, implementacija. U tom smislu, RUP je implementacija spiralni model, iako se dosta često prikazuje u obliku tabelarnog grafikona..

Ova slika predstavlja dvije dimenzije: horizontalna os predstavlja vrijeme i prikazuje vremenske aspekte životnog ciklusa procesa; okomita os predstavlja discipline koje definiraju fizičku strukturu procesa. Možete vidjeti kako se naglasak u projektu mijenja tijekom vremena. Na primjer, rane iteracije troše više vremena na zahtjeve; u kasnijim iteracijama više se vremena posvećuje implementaciji. Horizontalnu os čine vremenska razdoblja – iteracije od kojih je svaka neovisni razvojni ciklus; Svrha ciklusa je donijeti neko unaprijed određeno opipljivo poboljšanje konačnog proizvoda koje je korisno sa stajališta dionika.


Riža. 9.

Duž vremenske osi, životni ciklus je podijeljen u četiri glavne faze.

  1. Inception – formiranje koncepta projekta, razumijevanje onoga što stvaramo, razumijevanje proizvoda (vizija), izrada poslovnog plana (business case), izrada prototipa programa ili parcijalnog rješenja. Ovo je faza prikupljanja informacija i analize zahtjeva, definiranja slike projekta u cjelini. Cilj je dobiti podršku i sredstva. U završnoj iteraciji, rezultat ove faze je tehnička specifikacija.
  2. Dizajn, razvoj (razrada) - pojašnjavanje plana, razumijevanje kako ga stvaramo, projektiranje, planiranje potrebnih radnji i resursa, detaljiziranje značajki. Faza završava izvedivom arhitekturom, kada su sve arhitektonske odluke donesene i rizici uzeti u obzir. Izvršna arhitektura je pokrenuti softver koji demonstrira implementaciju osnovne arhitektonska rješenja. U završnoj iteraciji, ovo je tehnički projekt.
  3. Implementacija, stvaranje sustava (Construction) je faza proširenja funkcionalnosti sustava svojstvena arhitekturi. U završnoj iteraciji, ovo je radni nacrt.
  4. Implementacija, implementacija (Tranzicija). Izrada konačne verzije proizvoda. Faza uvođenja proizvoda, isporuka proizvoda određenom korisniku (replikacija, isporuka i obuka).

Vertikalna os sastoji se od disciplina, od kojih se svaka može detaljnije opisati u smislu zadataka koji se obavljaju, uloga odgovornih za njih, proizvoda koji se isporučuju zadacima kao input i oslobađaju tijekom njihove provedbe itd.

Duž ove osi nalaze se ključne discipline životnog ciklusa RUP-a, koje se na ruskom često nazivaju procesima, iako to nije sasvim točno sa stajališta ove metodologije koju podržavaju alati IBM-a (i/ili trećih strana).

  1. Poslovna analiza i modeliranje (Business modeling) osigurava implementaciju principa modeliranja u svrhu proučavanja poslovanja organizacije i prikupljanja znanja o njemu, optimizacije poslovnih procesa i donošenja odluka o njihovoj djelomičnoj ili potpunoj automatizaciji.
  2. Upravljanje zahtjevima odnosi se na uzimanje informacija od dionika i njihovo prevođenje u skup zahtjeva koji definiraju sadržaj sustava koji se razvija i detaljno opisuju očekivanja o tome što bi sustav trebao raditi.
  3. Analiza i dizajn pokrivaju postupke za pretvaranje zahtjeva u posredne opise (modele) koji predstavljaju kako bi se ti zahtjevi trebali implementirati.
  4. Implementacija obuhvaća razvoj koda, testiranje na razini programera i integraciju komponenti, podsustava i cijelog sustava prema utvrđenim specifikacijama.
  5. Testiranje je posvećeno procjeni kvalitete stvorenog proizvoda.
  6. Implementacija pokriva aktivnosti koje se odvijaju u isporuci proizvoda kupcima i stavljanju proizvoda na raspolaganje krajnjim korisnicima.
  7. Upravljanje konfiguracijom i promjenama (Configuration management) posvećeno je sinkronizaciji međuproizvoda i finalnih proizvoda te upravljanju njihovim razvojem tijekom projekta i pronalaženju skrivenih problema.
  8. Upravljanje projektima posvećeno je planiranju projekta, upravljanju rizicima, praćenju napretka i kontinuiranoj evaluaciji ključnih pokazatelja.
  9. Upravljanje okruženjem uključuje elemente kreiranja razvojnog okruženja informacijskog sustava i podršku projektnim aktivnostima.

Ovisno o specifičnostima projekta, mogu se koristiti bilo koji alati IBM Rationala, kao i trećih strana. RUP preporučuje sljedeće šest praksi za uspješan razvoj projekta: iterativni razvoj; upravljanje zahtjevima; korištenje modularnih arhitektura; vizualno modeliranje; kontrola kvalitete; praćenje promjena.

Sastavni dio RUP-a su artefakti (artefact), presedani (precedent) i uloge (roles). Artefakti su neki od proizvoda projekta koji se generiraju ili koriste u projektu tijekom rada na konačnom proizvodu. Precedenti su nizovi radnji koje izvodi sustav kako bi se dobio vidljivi rezultat. Zapravo, svaki rezultat rada pojedinca ili grupe je artefakt, bilo da se radi o dokumentu analize, elementu modela, kodnoj datoteci, testnoj skripti, opisu greške itd. Određeni stručnjaci odgovorni su za stvaranje jedne ili druge vrste artefakta. Dakle, RUP jasno definira odgovornosti - uloge - svakog člana razvojnog tima u jednoj ili drugoj fazi, odnosno kada i tko treba kreirati ovaj ili onaj artefakt. Cjelokupni proces razvoja softverskog sustava u RUP-u se promatra kao proces stvaranja artefakata - od dokumenata inicijalne analize do izvršnih modula, korisničkih priručnika itd.

IBM je razvio širok raspon računalne podrške za RUP procese. alata:

  • Rational Rose – CASE- alat za vizualno modeliranje informacijski sustavi koji imaju mogućnost generiranja kodnih elemenata. Posebno izdanje proizvoda - Rational Rose RealTime - omogućuje vam da kao izlaz dobijete izvršni modul;
  • Rational Requisite Pro je alat za upravljanje zahtjevima koji vam omogućuje kreiranje, strukturiranje, određivanje prioriteta, praćenje i kontrolu promjena zahtjeva koje se pojavljuju u bilo kojoj fazi razvoja komponenti aplikacije;
  • Rational ClearQuest je proizvod za upravljanje promjenama i praćenje nedostataka u projektu (bug tracking), koji se usko integrira s alatima za testiranje i upravljanje zahtjevima te pruža jedinstveno okruženje za međusobno povezivanje svih grešaka i dokumenata;
  • Rational SoDA je proizvod za automatsko generiranje projektne dokumentacije, koji vam omogućuje da postavite korporativni standard za interne dokumente tvrtke. Također je moguće uskladiti dokumentaciju s postojećim standardima (ISO, CMM);
  • Rational Purify, Rational Quantify Rational PureCoverage, – alati za testiranje i otklanjanje pogrešaka;
  • Rational Visual Quantify je alat za mjerenje performansi za programere aplikacija i komponenti koji programiraju u C/C++, Visual Basicu i Javi; pomaže identificirati i ukloniti uska grla u performansama softvera;
  • Rational Visual PureCoverage - automatski identificira područja koda koja se ne testiraju;
  • Rational ClearCase je softverski proizvod za upravljanje konfiguracijom (Rational's Software Configuration Management, SCM) koji omogućuje kontrolu verzija svih projektnih dokumenata istovremeno, brzo se prebacujući između njih i podržavajući ažuriranja promjene u zahtjevima za razvojni tim;
  • SQA TeamTest - alat automatizacija testiranja;
  • Rational TestManager je sustav za upravljanje testiranjem koji objedinjuje sve alate, artefakte, skripte i podatke koji se odnose na testiranje;
  • Rational Robot - alat za kreiranje, modificiranje i automatsko pokretanje testova;
  • SiteLoad, SiteCheck – alati za testiranje performansi web stranica i prisutnost neispravnih veza;
  • Rational PerformanceStudio - Mjeri i predviđa karakteristike performansi sustava.

Ovaj skup proizvoda stalno se poboljšava i proširuje. Na primjer, nedavni IBM-ov Rational Software Architect (RSA) dio je IBM-ove platforme za razvoj softvera, skupa alata koji podržavaju životni ciklus razvoja softverskih sustava. Proizvod IBM Rational Software Architect dizajniran je za izgradnju modela softverskih sustava koji se razvijaju korištenjem jedinstvenog jezika za modeliranje UML 2.0, prvenstveno modela arhitekture aplikacije koja se razvija. Međutim, RSA kombinira funkcije takvih softverskih proizvoda kao što su Rational Application Developer, Rational Web Developer i Rational Software Modeler, čime omogućuje arhitektima i analitičarima da kreiraju različite poglede na razvijeni informacijski sustav koristeći UML 2.0 jezik, a programerima da provode razvoj J2EE , XML, web usluge itd.

Slijedeći načela RUP-a, Rational Software Architect vam omogućuje stvaranje potrebnih modela unutar radnih tijekova disciplina kao što su:

  • poslovna analiza i modeliranje (Poslovno modeliranje);
  • upravljanje zahtjevima;
  • analiza i dizajn (Analysis and Design);
  • implementacija.

Dodatno, Rational Software Architect podržava razvoj vođen modelom (MDD), koji vam omogućuje modeliranje softvera na različitim razinama apstrakcije uz mogućnost praćenja.

MSF (Microsoft Solution Framework)

Godine 1994., u nastojanju da iz IT projekata izvuče maksimum, Microsoft je izdao niz smjernica za učinkovit dizajn, razvoj, implementacija i podrška rješenja izgrađenih na temelju njegovih tehnologija. Ovo znanje temelji se na iskustvu koje je Microsoft stekao tijekom rada velike projekte o razvoju i održavanju softvera, iskustvo Microsoftovih konzultanata i najbolje od onoga što sam skupio u trenutku IT industrija. Sve je to predstavljeno u obliku dva međusobno povezana i komplementarna područja znanja: Microsoft Solutions Framework (MSF) i Microsoft Operations Framework (MOF).

Treba napomenuti da je Microsoft razvio tehnike za primijenjenu i specijaliziranu upotrebu temeljene na općim MSF metodama. Štoviše, Microsoft certificira stručnjake posebno za primijenjena znanja u korištenju MSF-a (na primjer, MCTS 74-131 certifikat za stručnost u tehnikama upravljanja projektima). Prije nego naučite MSF metode, prvo morate odrediti na koju MSF aplikaciju mislite.

Najpopularnije MSF aplikacije koje je razvio Microsoft su:

  • metodologija implementacije rješenja u području upravljanja projektima;
  • Metodologija upravljanja IT projektima temeljena na MSF i Agile metodologijama.

Važnost primijenjenih verzija MSF-a naglašava činjenica da u “čistoj verziji” Microsoft ne koristi samu MSF metodologiju u svojim IT projektima. Projekti Microsoft Consulting Services koriste hibridnu MSF i Agile metodologiju. Unatoč vanjskim značajnim razlikama u primijenjenim verzijama MSF-a koje su razvili Microsoftovi stručnjaci, baza MSF metoda za njih ostaje uobičajena i odražava opće metodološke pristupe iterativnom upravljanju projektima.

MOF je osmišljen kako bi organizacijama koje stvaraju kritična IT rješenja temeljena na Microsoftovim proizvodima i tehnologijama pružila tehničke smjernice za postizanje njihove pouzdanosti, dostupnosti, pogodnost podrške(supportability) i upravljivost (manageability). Ministarstvo financija bavi se pitanjima koja se odnose na organizaciju osoblja i procesa; tehnologije i upravljanje u složenim, distribuiranim i heterogenim IT okruženjima. MOF se temelji na najboljoj praksi proizvodnje prikupljenoj u Knjižnici IT infrastrukture (ITIL), koju je sastavila Central Computer and Telecommunications Agency, agencija vlade Ujedinjenog Kraljevstva.

Stvaranje poslovnog rješenja unutar dodijeljenog vremena i proračuna zahtijeva dokazani metodološki okvir. MSF pruža provjerene metodologije za planiranje, projektiranje, razvoj i implementaciju uspješnih IT rješenja. Zahvaljujući svojoj fleksibilnosti, skalabilnosti i nedostatku krutih uputa, MSF može zadovoljiti potrebe organizacije ili projektnog tima bilo koje veličine. Metodologija MSF-a sastoji se od načela, modela i disciplina za upravljanje ljudima, procesima, tehnološkim elementima i povezanim pitanjima koja su tipična za većinu projekata. MSF se sastoji od dva modela i tri discipline. Oni su detaljno opisani u 5 bijelih knjiga. Bolje je započeti proučavanje MSF-a s modelima (model projektnog tima, model procesa), a zatim prijeći na discipline (disciplina upravljanja projektima, disciplina upravljanja rizicima, disciplina upravljanja obukom).

MSF procesni model predstavlja opću metodologiju za razvoj i implementaciju IT rješenja. Posebnost ovog modela je što se, zbog svoje fleksibilnosti i nepostojanja strogo nametnutih procedura, može koristiti u razvoju vrlo širokog spektra IT projekata. Ovaj model kombinira svojstva dva standardna proizvodna modela: vodopad i spiralu. Modelu procesa u MSF 3.0 dodan je još jedan inovativni aspekt: ​​pokriva cijeli životni ciklus stvaranja rješenja, od njegove početne točke do implementacije. Ovaj pristup pomaže projektnim timovima da se usredotoče na poslovnu vrijednost rješenja, budući da taj povrat postaje stvaran tek nakon što je implementacija dovršena i proizvod se počne koristiti.

MSF proces fokusiran je na "prekretnice" - ključne točke projekta koje karakteriziraju postizanje bilo kojeg značajnog (srednjeg ili konačnog) rezultata unutar njegovog okvira. Taj se rezultat može procijeniti i analizirati, što podrazumijeva odgovore na pitanja: „Je li projektni tim jasnom razumijevanju ciljeva i opsega projekta?", "Je li akcijski plan dovoljno pripremljen?", "Zadovoljava li proizvod odobrenu specifikaciju?", "Zadovoljava li rješenje potrebe kupca?" itd.

MSF procesni model uzima u obzir stalne promjene zahtjevi dizajna. Pretpostavlja se da bi se razvoj rješenja trebao sastojati od kratkih ciklusa koji stvaraju progresivno kretanje od najjednostavnijih verzija rješenja do njegovog konačnog oblika.

Značajke modela MSF procesa su:

  • pristup fazama i prekretnicama;
  • iterativni pristup;
  • integrirani pristup kreiranju i implementaciji rješenja.

Procesni model uključuje sljedeće glavne faze razvojnog procesa:

  • razvoj koncepta (Envisioning);
  • planiranje (Planiranje);
  • razvoj;
  • stabilizacija;
  • implementacija (Deploying).

Osim toga, postoji veliki broj međuprekretnica koje pokazuju postizanje određenog napretka tijekom projekta i raščlanjuju velike segmente rada na manja, vidljiva područja. Za svaku fazu modela procesa MSF definira:

  • što (koji artefakti) je rezultat ove faze;
  • na čemu svaki klaster uloga radi u ovoj fazi.

Unutar MSF-a programski kod, dokumentacija, nacrti, planovi i ostali radni materijali nastaju u pravilu iterativno. MSF preporučuje da počnete razvijati rješenje izgradnjom, testiranjem i implementacijom njegove osnovne funkcionalnosti. Zatim se sve više i više novih značajki dodaje rješenju. Ova se strategija naziva strategijom upravljanja verzijama. Iako izdavanje jedne verzije može biti dovoljno za male projekte, preporučuje se da ne propustite priliku za stvaranje više verzija jednog rješenja. Stvaranjem novih verzija, funkcionalnost rješenja se razvija.

Iterativni pristup razvojnom procesu zahtijeva upotrebu fleksibilnog načina vođenja dokumentacije. Živi dokumenti moraju se mijenjati kako se projekt razvija i zahtjevi za konačni proizvod mijenjaju. MSF nudi niz standardnih predložaka dokumenata koji su artefakti svake faze razvoja proizvoda i mogu se koristiti za planiranje i kontrolu procesa razvoja.

Rješenje nema poslovnu vrijednost dok se ne implementira. Upravo iz tog razloga MSF procesni model sadrži cijeli životni ciklus stvaranja rješenja, uključujući njegovu implementaciju – sve do trenutka kada rješenje počne isporučivati ​​vrijednost.

1. ožujka 2012. Federalna 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 softver“, identično međunarodni standard ISO/IEC 12207:2008 “Sustav i softversko inženjerstvo - Procesi životnog ciklusa softvera”.

Ovaj standard, koristeći utvrđenu terminologiju, uspostavlja opću strukturu procesa životnog ciklusa softvera koji se mogu voditi u industriji softvera. 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 razne vrste aktivnosti koje se mogu obavljati tijekom životnog ciklusa programskih sustava u sedam grupa procesa. Svaki od procesa životnog ciklusa unutar ovih skupina opisan je u smislu ciljeva i željenih rezultata, popisa radnji i zadataka koji se moraju izvršiti da bi se postigli ti rezultati.

  • procesi dogovora - dva procesa;
  • procesi za organizacijsku potporu projekta - 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.
  • Osnovno:
    • Akvizicija (radnje i zadaci kupca koji kupuje softver)
    • Isporuka (radnje i zadaci dobavljača koji kupcu isporučuje softverski proizvod ili uslugu)
    • Razvoj (radnje i zadaci koje obavlja programer: izrada softvera, projektna i pogonska dokumentacija, priprema testa i obrazovni materijali itd.)
    • Rad (radnje i zadaci operatera - organizacije koja upravlja sustavom)
    • Održavanje (radnje i zadaci koje obavlja prateća organizacija, odnosno pomoćna služba). Podrška - izmjene softvera kako bi se ispravile pogreške, poboljšala produktivnost ili prilagodila 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 utvrđivanje statusa komponenti softvera i upravljanje njegovim izmjenama).
    • Osiguranje kvalitete (pružanje jamstava da su informacijski sustav i procesi njegovog životnog ciklusa u skladu s određenim zahtjevima i odobrenim planovima)
    • Provjera (utvrđivanje da softverski proizvodi koji proizlaze iz neke radnje u potpunosti zadovoljavaju zahtjeve ili uvjete nametnute prethodnim radnjama)
    • Certificiranje (utvrđivanje potpunosti usklađenosti navedenih zahtjeva i izrađenog sustava s njihovom specifičnom funkcionalnom namjenom)
    • Zajednička procjena (procjena statusa 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
    • Kontrola (radnje i zadaci koje može izvršiti 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 radnji. Na primjer, postupak akvizicije obuhvaća sljedeće aktivnosti:

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

Svaka aktivnost uključuje niz zadataka. Na primjer, priprema prijedloga ponude trebala bi uključivati:

  1. Formiranje zahtjeva sustava
  2. Generiranje popisa softverskih proizvoda
  3. Uspostavljanje uvjeta i dogovora
  4. Opis tehničkih ograničenja (operativno okruženje sustava, 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 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 dovrš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 točke završetka rada i donošenja odluka.


Riža. 5.2.

Ovi aspekti su:

  1. ugovorni aspekt, u kojem kupac i dobavljač stupaju u ugovorne odnose i provode procese nabave i isporuke;
  2. upravljački aspekt, koji uključuje upravljačke radnje osoba koje sudjeluju u životnom ciklusu softvera (dobavljač, kupac, programer, operater itd.);
  3. operativni aspekt, 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 drugim sudionicima u radu. U ovom aspektu možemo istaknuti aspekt upravljanja kvalitetom softvera koji uključuje procese osiguranja kvalitete, verifikacije, certifikacije, zajedničke procjene i audita.

Organizacijski procesi provode 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 definira redoslijed izvršavanja i odnose 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 nudi određeni model životnog ciklusa i metode razvoja softvera. Njegove su odredbe općenite za sve modele životnog ciklusa, metode i tehnologije razvoja softvera. Standard opisuje strukturu procesa životnog ciklusa softvera, ali ne specificira kako implementirati ili izvesti akcije 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 kombiniranih u stupnjeve (faze), č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 određenim vremenskim okvirom i završava izdavanjem određenog proizvoda (softverski modeli, softverske komponente, dokumentacija itd.), određen zahtjevima određeno za ovu fazu. Izdvojene su faze izrade softvera iz razloga racionalnog planiranja i organizacije rada koji završava zadanim 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 podfaze: detaljni dizajn, kodiranje);
  4. testiranje (može se podijeliti na samostalno i integrirano testiranje i integraciju);
  5. puštanje u rad (implementacija);
  6. rad i održavanje;
  7. razgradnja.

Neki stručnjaci uvode dodatnu početnu fazu - analiza izvodljivosti sustava. Ovdje mislimo na hardverski i softverski sustav za koji se kreira, kupuje ili modificira softver.

Faza formiranja softverskih zahtjeva jedna je od najvažnijih i u značajnoj (čak odlučujućoj!) mjeri određuje uspjeh cijelog projekta. Početak ove faze je primitak odobrene i potvrđene arhitekture sustava, uključujući osnovne dogovore o raspodjeli funkcija između hardvera i softvera. Ovaj dokument također treba sadržavati potvrdu općeg razumijevanja rada softvera, uključujući osnovne dogovore o raspodjeli funkcija između osobe i sustava.

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

  1. Planiranje rada prije rada na projektu. Glavni zadaci faze su određivanje razvojnih ciljeva, preliminarna ekonomska procjena projekta, 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 raspodjele funkcija među odjelima i zaposlenicima, identifikacija funkcionalnih interakcija između odjela, tokovi informacija unutar i između odjela, objekti izvan organizacije i vanjski informacijski utjecaji, analiza postojećih sredstava za automatizaciju aktivnosti organizacije.

    3. Izrada modela aktivnosti organizacije (objekta), koja uključuje obradu anketnog materijala i izradu dvije vrste modela:

    • model "KAKO JEST" ("kakav jest"), koji odražava trenutno stanje stvari u organizaciji u vrijeme ankete i omogućuje razumijevanje kako organizacija funkcionira, kao i identificiranje uskih grla i formuliranje prijedloga za poboljšanje situacija;
    • model "TO-BE" ("kako bi trebalo biti"), odražavajući ideju o novim tehnologijama za organizaciju.

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 konstruirani modeli imaju samostalan praktični značaj, neovisno o tome hoće li se informacijski sustav razvijati i implementirati u poduzeću, budući da je uz njihovu pomoć moguće osposobiti zaposlenike i unaprijediti poslovne procese poduzeća.

Rezultat završetka faze generiranja 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 faze.

  1. Izrada projekta softverskog sustava. U ovoj fazi daje se odgovor na pitanje “Što bi trebao raditi budući sustav?”, odnosno: arhitektura sustava, njegove funkcije, vanjski uvjeti rada, sučelja i raspodjela funkcija između korisnika i sustava, zahtjevi za softver. i informacijske sastavnice, sastav izvođača i rokovi utvrđuju se razvoj, plan otklanjanja programskih pogrešaka i kontrola kvalitete.

    Osnovu projekta sustava čine modeli projektiranog sustava koji se grade po modelu “TO-BE”. Rezultat razvoja projekta sustava mora biti odobrena i potvrđena specifikacija programskih 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 se daje 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, intermodularnih sučelja za podatke i upravljanje;
  • specifikacija svake softverske komponente, naziv, svrha, pretpostavke, dimenzije, redoslijed poziva, ulazni i izlazni podaci, pogreške 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šnjeg procesora, memorija itd.);
  • provjera potpunosti, dosljednosti, izvedivosti i valjanosti zahtjeva;
  • preliminarni plan za integraciju i uklanjanje pogrešaka, plan za korisnički priručnik i testiranje prihvatljivosti.

Završetak faze detaljnog dizajna je od kraja do kraja

Anotacija.

Uvod.

1. Životni ciklus PO

Uvod.

Riley Koraci procesa programiranja

Uvod.

1.1.1. Izjava 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 klauzulu 1.1

1.2. Definicija LCPO prema Lehmanu.

Uvod.

1.2.1 Definicija sustava.

1.2.2. Provedba.

1.2.3. Servis.

Zaključak na klauzulu 1.2.

1.3. Faze i rad LCPO prema Boehmu

1.3.1. Kaskadni model.

1.3.2. Ekonomska opravdanost kaskadni model.

1.3.3. Poboljšanje kaskadnog modela.

1.3.4. Određivanje faza životnog ciklusa.

1.3.5. Glavni rad na projektu.

Književnost.


Uvod

Industrijska primjena računala i sve veća potražnja za programima postavili su hitne zadatke da se značajno povećaju produktivnost razvoja softvera, razvoj industrijskih metoda planiranja i projektiranja programa, prijenos organizacijskih, tehničkih, tehničkih, ekonomskih i socio-psiholoških tehnika, obrazaca i metoda iz sfere materijalne proizvodnje u sferu uporabe računala. Integrirani pristup procesima razvoja, rada i održavanja programske opreme iznio je niz gorućih problema čije će rješenje otkloniti uska grla u dizajnu programa, smanjiti vrijeme završetka rada, poboljšati odabir i prilagodbu postojećih programa, a možda i odrediti sudbina sustava s ugrađenim računalima.

U praksi razvoja velikih softverskih projekata često nema jedinstven pristup na procjenu troškova rada, rokova rada i materijalnih troškova, š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, maketa programa), pristup njegovoj izradi trebao bi u mnogočemu biti sličan pristupu proizvodnji industrijski proizvodi, a pitanja dizajna programa postaju iznimno važna. Ova je ideja u središtu B.W.-ove knjige. Boema" Inženjerski dizajn softver" koji smo koristili prilikom pisanja ovog teksta predmetni rad. U ovoj se knjizi softverski dizajn odnosi na proces stvaranja dizajna softverskog proizvoda.


1 Životni ciklus softvera

UVOD

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

Postoji nekoliko pristupa određivanju faza i aktivnosti životnog ciklusa softvera (SLC), koraka procesa programiranja, kaskadnih 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 procesa životnog ciklusa prema Boehmu, koja uključuje osam faza. U budućnosti će biti detaljnije predstavljen.

Jedan od moguće opcije može poslužiti vrhunski opis po Lehmannu koji uključuje tri glavne faze i predstavlja opis životnog ciklusa u najopćenitijem slučaju.

I, radi raznolikosti, predstavljamo korake 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 počnimo s njom.

1.1 Koraci u Riley procesu programiranja

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

prikaz problema, tj. stjecanje odgovarajućeg razumijevanja zadatka koje program treba obavljati;

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

programsko kodiranje, tj. prevođenje projektiranog rješenja u program koji se može izvršiti na stroju;

programsku podršku, tj. tekući proces rješavanja problema programa 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 navodi problem analitičar sustava. Korisnik i analitičar sustava zajednički definiraju iskaz problema. Potonji se zatim prenosi algoritamist, koji je odgovoran za izradu rješenja. Rješenje (ili algoritam) predstavlja slijed operacija čije izvođenje dovodi do rješenja problema. Budući da algoritam često nije prikladan 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 enkoder, i prateći programer - svi su oni programeri.

U slučaju velikog softverskog projekta, broj korisnika, sistemskih analitičara 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 za pažljivo dizajniranje softvera: rezultati svakog koraka trebaju biti potpuni, točni i razumljivi.

1.1.1 Izjava problema

Jedan od naj važne korake programiranje je iskaz problema. Funkcionira kao ugovor između korisnika i programera(a). Kao i pravno loše sastavljen ugovor, loše napisana izjava o problemu je beskorisna. 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 znanja da može. Dobra izjava problema služi kao osnova za formuliranje njegovog rješenja.

Izjava 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: za njega nije važno kako računalo radi, već je važno što računalo može učiniti što korisnika zanima. U ovom slučaju, glavna pozornost je usmjerena na interakciju čovjeka i stroja.

Karakteristike dobre izjave problema:

Točnost, tj. otklanjanje 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 nenamjeran unos, i određivanje odgovarajućeg izlaza.

Jasnoća, tj. mora 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, što omogućuje da se određene odredbe formuliraju s iznimnom preciznošću, isključujući bilo kakva manja odstupanja. Na primjer, neka pitanja u ispitni listovi Ponekad su formulirani toliko precizno da učenik 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 velika količina pojedinosti. Najbolja formulacija problema je ona koja postiže ravnotežu sva tri zahtjeva.

Standardni oblik prikaza problema.

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

Takva izjava ne zadovoljava gore navedene zahtjeve: nije ni točna, ni potpuna ni razumljiva. Doista, trebaju li se brojevi unositi 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 uvedeni.

Očito, takva izjava ne odgovara na mnoga pitanja. Ako uzmemo u obzir odgovore na sva pitanja, tada će izjava problema postati opširna 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 (shematsko određenje);

opći opis(kratak prikaz problema);

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

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

Primjer. Prikaz problema u standardnom obliku.

IME

Sortiranje tri cijela broja.

OPIS

Ulaz i izlaz tri cijela broja poredana od najmanjeg do najvećeg broja.

Upisuju se tri cijela broja, po jedan broj u svakom redu. Cijeli broj je jedna ili više uzastopnih decimalnih znamenki, ispred kojih može stajati znak plus “+” ili znak minus “–”.

Tri upisana cijela broja su ispisana, a sva tri su ispisana 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.

Životni ciklus softvera je vremensko razdoblje koje počinje od trenutka donošenja odluke o potrebi izrade softverskog proizvoda i završava kada se potpuno povuče iz upotrebe. Ovaj ciklus je proces izgradnje i razvoja softvera.

Faze životnog ciklusa:

2. Dizajn

3. Provedba

4. Montaža, ispitivanje, ispitivanje

5. Implementacija (izdanje)

6. Pratnja

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

2) Softver je razvijen za tržište. Potrebno je provesti istraživanje marketinga i pronađite koji proizvod nije na tržištu. Ovo dolazi s velikim rizikom. Cilj je razviti specifikaciju zahtjeva.

Dizajn

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

Provedba

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

Montaža, testiranje, testiranje

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

Implementacija (izdanje)

Implementacija – kada rade za jednog kupca. Uključuje postavljanje programa na mjestu kupca, obuku kupca, konzultacije, otklanjanje grešaka i očitih nedostataka. Softver mora biti otuđen - korisnik može raditi sa softverom bez sudjelovanja autora.

Izdanje – kada je softver razvijen za tržište. Započinje fazom beta testiranja. Odg. verzija - beta verzija. Alfa testiranje je testiranje od strane ljudi iz iste organizacije koji nisu bili uključeni u razvoj programa. Beta testiranje – izrada više kopija softvera i slanje potencijalni kupci. Cilj je ponovno provjeriti razvoj softvera.

Ako je temeljno novi softver pušten na tržište, moguće je nekoliko beta testova. Nakon beta testiranja - izlazak komercijalne verzije.

Pratnja

Otklanjanje grešaka uočenih tijekom rada. Uvođenje nebitnih poboljšanja. Akumulacija prijedloga za razvoj sljedeće verzije.

Modeli životnog ciklusa

1. Vodopad ("vodopad", kaskadni model)

2. Izrada prototipova

Prvo, ne razvija se sam od sebe softverski proizvod, i njegov prototip koji sadrži rješenje za glavne probleme s kojima se programeri suočavaju. Nakon uspješnog završetka razvoja prototipa, pravi softverski proizvod se razvija koristeći iste principe. Prototip vam omogućuje bolje razumijevanje zahtjeva za program koji se razvija. Korištenjem prototipa kupac također može točnije formulirati svoje zahtjeve. Programer ima priliku, koristeći prototip, predstaviti kupcu preliminarne rezultate svog rada.

3. Iterativni model

Zadatak je podijeljen na podzadatke i određen redoslijed njihove provedbe tako da svaki sljedeći podzadatak proširuje mogućnosti softvera. Uspjeh uvelike ovisi o tome koliko su dobro zadaci podijeljeni na podzadatke i kako je odabran redoslijed. Prednosti: 1) mogućnost aktivnog sudjelovanja kupca u razvoju, on ima priliku razjasniti svoje zahtjeve tijekom razvoja; 2) mogućnost testiranja novorazvijenih dijelova zajedno s prethodno razvijenim, što će smanjiti troškove složenog otklanjanja pogrešaka; 3) tijekom razvoja, možete započeti implementaciju u dijelovima.

Ocjena članka:
1 zvjezdica2 zvjezdice3 zvjezdice4 zvjezdice5 zvjezdica(Još nema ocjena)
Učitavanje...
Podijelite s prijateljima:
Članci na sličnu temu
Zatvoriti
Pronađite na web mjestu
Na primjer: vrste suhozida