Razvoj softvera je nemoguć bez razumijevanja tzv. životnog ciklusa softvera. Običan korisnik to možda i ne treba znati, ali je poželjno naučiti osnovne standarde (kasnije će biti rečeno zašto je to potrebno).
Što je životni ciklus u formalnom smislu?
Pod životnim ciklusom bilo kojeg, uobičajeno je razumjeti vrijeme njegovog postojanja, počevši od faze razvoja pa do trenutka potpuni neuspjeh od uporabe u odabranom području primjene do potpunog uklanjanja aplikacije iz uporabe.
Jednostavno rečeno, informacijski sustavi u obliku programa, baza podataka ili čak operativnih sustava traženi su samo ako su podaci i mogućnosti koje pružaju relevantni.
Vjeruje se da se definicija životnog ciklusa ni na koji način ne odnosi na testne aplikacije, poput beta verzija, koje su najnestabilnije u radu. Sam životni ciklus softvera ovisi o mnogim čimbenicima, među kojima jednu od glavnih uloga ima okolina u kojoj će se program koristiti. Međutim, može se razlikovati općim uvjetima poslovanja koristi se u definiranju koncepta životnog ciklusa.
Početni zahtjevi
- formulacija problema;
- analiza međusobnih zahtjeva budućeg softvera prema sustavu;
- oblikovati;
- programiranje;
- kodiranje i kompilacija;
- testiranje;
- uklanjanje pogrešaka;
- implementacija i održavanje softverskog proizvoda.
Razvoj softvera sastoji se od svih gore navedenih faza i ne može proći bez barem jedne od njih. Ali za kontrolu takvih procesa uspostavljeni su posebni standardi.
Standardi procesa životnog ciklusa softvera
Među sustavima koji unaprijed određuju uvjete i zahtjeve za takve procese, danas se mogu navesti samo tri glavna:
- GOST 34.601-90;
- ISO/IEC 12207:2008;
- Oracle CDM.
Za drugu međunarodni standard postoji ruski ekvivalent. Ovo je GOST R ISO / IEC 12207-2010, koji je odgovoran za sustave i softversko inženjerstvo. Ali životni ciklus softver, opisan u oba pravila, u biti je identičan. Ovo se objašnjava prilično jednostavno.
Vrste softvera i ažuriranja
Usput, za većinu trenutno poznatih multimedijskih programa oni su sredstvo za spremanje glavnih konfiguracijskih parametara. Upotreba ove vrste softvera je, naravno, prilično ograničena, ali razumijevanje općih načela rada s istim medijskim playerima ne boli. I zato.
Zapravo, oni imaju životni ciklus softvera samo na razini razdoblja ažuriranja za verziju samog playera ili instalacije kodeka i dekodera. A audio i video transkoderi bitni su atributi svakog audio ili video sustava.
Primjer temeljen na FL Studiju
U početku se virtualni studio-sekvencer FL Studio zvao Fruity Loops. Životni ciklus Softver je u primarnoj modifikaciji istekao, ali je aplikacija donekle transformirana i poprimila sadašnji oblik.
Ako govorimo o fazama životnog ciklusa, u početku, u fazi postavljanja zadatka, postavljeno je nekoliko obveznih uvjeta:
- stvaranje modula bubnja sličnog ritam mašinama poput Yamahe RX, ali korištenjem pojedinačnih uzoraka ili WAV sekvenci snimljenih uživo u studiju;
- integracija u Windows operativne sustave;
- mogućnost izvoza projekta u WAV, MP3 i OGG formate;
- kompatibilnost projekta s dodatnom aplikacijom Fruity Tracks.
U fazi razvoja korišteni su alati programskih jezika C. Ali platforma je izgledala prilično primitivno i nije dopuštala krajnjem korisniku potrebna kvaliteta zvuk.
S tim u vezi, u fazi testiranja i otklanjanja pogrešaka, programeri su morali slijediti put njemačke korporacije Steinberg i primijeniti podršku za Full Duplex način rada u zahtjevima za glavni upravljački program zvuka. Kvaliteta zvuka postala je viša i omogućuje vam promjenu tempa, visine tona i primjenu dodatnih FX efekata u stvarnom vremenu.
Kraj životnog ciklusa ovog softvera smatra se izdavanjem prvog službena verzija FL Studio, koji je, za razliku od svojih predaka, već imao punopravno sučelje sekvencera s mogućnošću uređivanja parametara na virtualnoj 64-kanalnoj konzoli za miješanje s neograničenim dodavanjem audio zapisa i MIDI zapisa.
Ovo nije bilo ograničeno. U fazi upravljanja projektom uvedena je podrška za povezivanje dodataka u VST formatu (prvo druga, a zatim treća verzija), koju je Steinberg svojevremeno razvio. Grubo govoreći, bilo koji virtualni sintesajzer koji podržava VST-host mogao bi se spojiti na program.
Nije iznenađujuće da bi uskoro bilo koji skladatelj mogao koristiti analoge "željeznih" modela, na primjer, kompletan set zvukova nekada popularnog Korga M1. Dalje više. Korištenje modula poput Addictive Drums ili univerzalnog Kontakt plug-ina omogućilo je reprodukciju živih zvukova pravih instrumenata snimljenih sa svim nijansama artikulacije u profesionalnim studijima.
Istodobno, programeri su pokušali postići maksimalnu kvalitetu stvaranjem podrške za ASIO4ALL upravljačke programe, koji su se pokazali glavom i ramenima iznad Full Duplex moda. Sukladno tome, bitrate se također povećao. Do danas, kvaliteta izvezene audio datoteke može biti 320 kbps pri brzini uzorkovanja od 192 kHz. Ovo je profesionalni zvuk.
Što se početne verzije tiče, njen životni ciklus bi se mogao nazvati potpuno završenim, ali takva je izjava relativna, jer je aplikacija samo promijenila ime i dobila nove mogućnosti.
Izgledi razvoja
Koje su faze životnog ciklusa softvera već je jasno. Ali razvoj takvih tehnologija vrijedi spomenuti zasebno.
Nepotrebno je reći da bilo koji programer softvera nije zainteresiran za stvaranje kratkotrajnog proizvoda za koji je malo vjerojatno da će ostati na tržištu nekoliko godina. U budućnosti svi gledaju na njegovu dugoročnu upotrebu. To se može postići različiti putevi. Ali, u pravilu, gotovo svi se svode na izdavanje ažuriranja ili novih verzija programa.
Čak iu slučaju Windowsa takvi se trendovi mogu vidjeti golim okom. Malo je vjerojatno da će danas postojati barem jedan korisnik koji koristi sustave poput modifikacija 3.1, 95, 98 ili Millennium. Njihov životni ciklus završio je nakon izlaska XP verzije. Ali verzije poslužitelja temeljene na NT tehnologijama i dalje su relevantne. Čak i Windows 2000 danas nije samo vrlo ažuran, nego čak i nadmašuje najnovija dostignuća u nekim instalacijskim ili sigurnosnim parametrima. Isto vrijedi i za sustav NT 4.0, kao i za specijaliziranu modifikaciju Windows Servera 2012.
Ali u odnosu na te sustave, podrška se još uvijek deklarira na samom visoka razina. Ali senzacionalna Vista u svoje vrijeme očito doživljava pad ciklusa. Ne samo da se pokazalo nedovršenim, već je bilo toliko grešaka u sebi i rupa u njegovom sigurnosnom sustavu da se može samo nagađati kako je takvo neodrživo rješenje moglo biti pušteno na tržište softvera.
Ali ako govorimo o tome da razvoj softvera bilo koje vrste (upravljačkog ili aplikativnog) ne miruje, on je jedino moguć. Uostalom, danas se ne radi samo o računalni sustavi, i Mobilni uredaji u kojem su primijenjene tehnologije često ispred računalnog sektora. Pojava procesorskih čipova temeljenih na osam jezgri - nego ne najviše najbolji primjer? Ali ne može se svako prijenosno računalo pohvaliti takvim hardverom.
Neka dodatna pitanja
Što se tiče razumijevanja životnog ciklusa softvera, moguće je reći da je završio u određenom trenutku, vrlo je uvjetno, jer softverski proizvodi još uvijek imaju podršku programera koji su ih stvorili. Umjesto toga, kraj se odnosi na naslijeđene aplikacije koje ne ispunjavaju zahtjeve moderni sustavi i ne mogu raditi u svom okruženju.
Ali čak i uzimajući u obzir tehnički napredak mnoge od njih uskoro bi mogle postati neodržive. Tada ćete morati donijeti odluku o izdavanju ažuriranja ili o potpunoj reviziji cjelokupnog koncepta koji je izvorno ugrađen u softverski proizvod. Otuda i novi ciklus koji podrazumijeva promjenu početnih uvjeta, razvojnog okruženja, testiranje i moguću dugoročnu primjenu na određenom području.
Ali u računalnoj tehnologiji danas se prednost daje razvoju automatiziranih sustava upravljanja (ACS), koji se koriste u proizvodnji. Čak i operativni sustavi, u usporedbi sa specijaliziranim programima, gube.
Ista okruženja temeljena na Visual Basicu ostaju mnogo popularnija od Windows sustava. Pritom uopće ne govorimo o aplikacijskom softveru za UNIX sustave. Što mogu reći, ako gotovo sve komunikacijske mreže istih Sjedinjenih Država rade isključivo za njih. Usput, sustavi poput Linuxa i Androida također su izvorno stvoreni na ovoj platformi. Stoga, najvjerojatnije, UNIX ima puno više izgleda od ostalih proizvoda zajedno.
Umjesto totala
Ostaje još dodati da ovaj slučaj dano samo generalni principi i faze životnog ciklusa softvera. Zapravo, čak se i početni zadaci mogu značajno razlikovati. Sukladno tome, razlike se mogu uočiti u drugim fazama.
Ali osnovne tehnologije za razvoj softverskih proizvoda s njihovim naknadnim održavanjem trebaju biti jasne. Za ostalo treba voditi računa o specifičnostima softvera koji se izrađuje, okolinama u kojima bi trebao raditi, te mogućnostima programa koji se isporučuju krajnjem korisniku ili proizvodnji i još mnogo toga.
Osim toga, ponekad životni ciklusi mogu ovisiti o relevantnosti razvojnih alata. Ako, primjerice, neki programski jezik zastari, nitko neće pisati programe na temelju njega, štoviše - implementirati ih u automatizirani sustavi upravljanje proizvodnjom. Tu čak ne dolaze do izražaja programeri, već marketingaši koji moraju pravovremeno reagirati na promjene na tržištu računala. A takvih stručnjaka u svijetu nema toliko. Najtraženiji su visokokvalificirani kadrovi sposobni držati korak s tržištem. A upravo su oni često takozvani "sivi kardinali" o kojima ovisi uspjeh ili neuspjeh određenog softverskog proizvoda u IT području.
Iako ne razumiju uvijek bit programiranja, jasno su sposobni odrediti modele životnog ciklusa softvera i trajanje njihove uporabe, na temelju svjetskih trendova u ovom području. Učinkovito upravljanje često daje opipljivije rezultate. Da, barem PR tehnologije, oglašavanje itd. Korisnik možda neće trebati neku aplikaciju, ali ako se aktivno reklamira, korisnik će je instalirati. To je već, da tako kažemo, podsvjesna razina (isti učinak 25. okvira, kada se informacije stavljaju u um korisnika bez obzira na njega samog).
Naravno, takve tehnologije su zabranjene u svijetu, ali mnogi od nas niti ne shvaćaju da se one ipak mogu koristiti i utjecati na podsvijest na određeni način. Što vrijedi “zombificiranje” informativnih kanala ili internetskih stranica, a da ne govorimo o korištenju moćnijih sredstava, poput izlaganja infrazvuku (to je korišteno u jednoj opernoj produkciji), zbog čega čovjek može osjetiti strah ili neadekvatne emocije.
Vraćajući se na softver, vrijedi dodati da neki programi koriste zvučni signal pri pokretanju kako bi privukli pozornost korisnika. Studije pokazuju da su takve aplikacije održivije od drugih programa. Naravno, produžava se i životni ciklus softvera, bez obzira kojoj funkciji je izvorno dodijeljen. I to, nažalost, koriste mnogi programeri, što izaziva sumnju u zakonitost takvih metoda.
Ali nije na nama da sudimo o tome. Moguće je da će se u bliskoj budućnosti razviti alati za prepoznavanje takvih prijetnji. Zasad je to samo teorija, ali, prema nekim analitičarima i stručnjacima, prije praktična aplikacija ostalo je vrlo malo. Ako već stvaraju kopije neuronskih mreža ljudskog mozga, što onda reći?
Riža. 5.2.
Ovi aspekti su:
- ugovorni aspekt u koji ulaze kupac i dobavljač ugovorni odnos te implementirati procese nabave i nabave;
- upravljački aspekt, koji uključuje upravljačke radnje osoba koje sudjeluju u životnom ciklusu softvera (dobavljač, kupac, programer, operater itd.);
- aspekt rada, koji uključuje radnje operatora za pružanje usluga korisnicima sustava;
- 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;
- aspekt podrške povezan s provedbom procesa podrške, putem kojih službe podrške pružaju potrebne usluge svim ostalim sudionicima u radu. U ovom aspektu može se izdvojiti aspekt upravljanja kvalitetom softvera, uključujući procese osiguranja kvalitete, verifikacije, certifikacije, zajedničke procjene i audita.
Organizacijski procesi odvijaju se na korporativnoj razini ili na razini cijele organizacije kao cjeline, stvarajući osnovu za implementaciju i kontinuirano poboljšanje procesa životnog ciklusa softvera.
5.6. Modeli i faze životnog ciklusa softvera
Model životnog ciklusa softvera shvaća se kao struktura koja određuje redoslijed izvršavanja i odnos procesa, akcija i zadataka tijekom životnog ciklusa softvera. Model životnog ciklusa ovisi o specifičnostima, opsegu i složenosti projekta te specifičnim uvjetima u kojima sustav nastaje i radi.
Norma ISO/IEC 12207 ne predlaže određeni model životnog ciklusa i metode razvoja softvera. Njegove odredbe zajedničke su svim modelima životnog ciklusa, metodama i tehnologijama razvoja softvera. Standard opisuje strukturu procesa životnog ciklusa softvera, ali ne specificira kako implementirati ili izvesti aktivnosti i zadatke uključene u te procese.
Model životnog ciklusa bilo kojeg specifičnog softvera određuje prirodu procesa njegovog stvaranja, koji je skup radova poredanih u vremenu, međusobno povezanih i objedinjenih u fazama (fazama), čija je implementacija neophodna i dovoljna za stvaranje softvera koji zadovoljava navedene zahtjeve.
Faza (faza) stvaranja softvera shvaća se kao dio procesa stvaranja softvera, ograničen nekim vremenskim okvirom i završava izdavanjem određenog proizvoda (softverski modeli, softverske komponente, dokumentacija itd.), određen navedenim zahtjevima za ovu fazu. Izdvojene su faze izrade softvera iz razloga racionalnog planiranja i organizacije rada, a završavaju navedenim rezultatima. Životni ciklus softvera obično uključuje sljedeće faze:
- formiranje softverskih zahtjeva;
- projektiranje (izrada projekta sustava);
- implementacija (može se podijeliti na pod-korake: detaljni dizajn, kodiranje);
- testiranje (može se podijeliti na samostalno i sveobuhvatno testiranje i integracija)
- puštanje u rad (implementacija);
- rad i održavanje;
- razgradnja.
Neki stručnjaci uvode dodatnu početnu fazu - Studija izvodljivosti sustava. Ovo se odnosi na softverski i hardverski sustav za koji je softver kreiran, kupljen ili modificiran.
Faza formiranja softverskih zahtjeva jedna je od najvažnijih i u velikoj mjeri (čak i odlučujuće!) određuje uspjeh cijelog projekta. Početak ove faze je dobivanje odobrene i odobrene arhitekture sustava uz uključivanje osnovnih dogovora o raspodjeli funkcija između hardvera i softvera. Ovaj dokument također treba sadržavati potvrdu opće ideje o funkcioniranju softvera, uključujući glavne sporazume o raspodjeli funkcija između osobe i sustava.
Faza formiranja softverskih zahtjeva uključuje sljedeće faze.
- Planiranje rada prije projekta. Glavni zadaci pozornice su definiranje razvojnih ciljeva, preliminarni ekonomska procjena projekt, izrada rasporeda rada, stvaranje i obuka zajedničke radne skupine.
- Provođenje istraživanja aktivnosti automatizirane organizacije (objekta), u okviru kojeg se provodi preliminarna identifikacija zahtjeva za budući sustav, određivanje strukture organizacije, određivanje popisa ciljnih funkcija organizacije, analiza raspodjela funkcija po odjelima i zaposlenicima, identificiranje funkcionalne interakcije između odjela, tokovi informacija unutar odjela i između njih, objekti izvan organizacije i vanjski informacijski utjecaji, analiza postojećih sredstava automatizacije aktivnosti organizacije.
- model "KAKO JEST" ("kakav jest") koji odražava trenutno stanje stvari u organizaciji u vrijeme ankete i omogućuje vam da razumijete kako organizacija funkcionira, kao i da identificirate uska grla i formulirate prijedloge za poboljšanje situacija;
- Model "TO-BE" ("kao što bi trebalo biti"), odražava ideju novih tehnologija rada organizacije.
Izgradnja modela aktivnosti organizacije (objekta), koji predviđa obradu anketnih materijala i izgradnju dvije vrste modela:
Svaki od modela treba sadržavati cjeloviti funkcionalni i informacijski model aktivnosti organizacije, kao i (ako je potrebno) model koji opisuje dinamiku ponašanja organizacije. Napominjemo da su konstruirani modeli od samostalnog praktičnog značaja, neovisno o tome razvija li poduzeće i implementira informacijski sustav, budući da se mogu koristiti za obuku zaposlenika i unapređenje poslovnih procesa poduzeća.
Rezultat završetka faze formiranja programskih zahtjeva su softverske specifikacije, funkcionalne, tehničke i specifikacije sučelja, za koje se potvrđuje njihova cjelovitost, provjerljivost i izvedivost.
Faza projektiranja uključuje sljedeće korake.
Izrada projekta softverskog sustava. U ovoj fazi daje se odgovor na pitanje "Što bi budući sustav trebao raditi?", a to su: arhitektura sustava, njegove funkcije, vanjski uvjeti funkcioniranje, sučelja i raspodjela funkcija između korisnika i sustava, zahtjevi za softverske i informacijske komponente, sastav izvođača i vrijeme razvoja, plan otklanjanja pogrešaka i kontrole kvalitete softvera.
Osnova projekta sustava su modeli projektiranog sustava koji su izgrađeni na modelu "TO-BE". Rezultat razvoja projekta sustava treba biti odobrena i potvrđena specifikacija softverskih zahtjeva: funkcionalnih, tehničkih i specifikacija sučelja, za koje se potvrđuje njihova cjelovitost, provjerljivost i izvedivost.
- Izrada izvedbenog (tehničkog) projekta. U ovoj fazi se provodi stvarni dizajn softvera, uključujući dizajn arhitekture sustava i detaljni dizajn. Time je dan odgovor na pitanje: "Kako izgraditi sustav tako da zadovoljava zahtjeve?"
Rezultat detaljnog dizajna je razvoj provjerene specifikacije softvera, uključujući:
- formiranje hijerarhije programskih komponenti, međumodulnih sučelja za podatke i kontrolu;
- specifikacija svake softverske komponente, naziv, svrha, pretpostavke, veličine, redoslijed poziva, ulazni i izlazni podaci, pogrešni izlazi, algoritmi i logički sklopovi;
- formiranje fizičkih i logičkih struktura podataka do razine pojedinih polja;
- izrada plana raspodjele računalnih resursa (vrijeme središnjih procesora, memorije i dr.);
- provjera potpunosti, dosljednosti, izvedivosti i valjanosti zahtjeva;
- preliminarni plan integracije i otklanjanja pogrešaka, korisnički priručnik i plan prihvatljivog testiranja.
Završetak faze detaljnog dizajna je od kraja do kraja
Anotacija.
Uvod.
1. Životni ciklus softvera
Uvod.
Riley Koraci procesa programiranja
Uvod.
1.1.1. Formulacija problema.
1.1.2. Dizajn rješenja.
1.1.3. Kodiranje algoritma.
1.1.4. Programska podrška.
1.1.5. Softverska dokumentacija.
Zaključak na stavak 1.1
1.2. Definicija ZhTsPO prema Lehmanu.
Uvod.
1.2.1 Definicija sustava.
1.2.2. Provedba.
1.2.3. Servis.
Zaključak na točku 1.2.
1.3. Faze i radovi programa životnog ciklusa prema Boehmu
1.3.1. kaskadni model.
1.3.2. Ekonomska opravdanost kaskadni model.
1.3.3. Poboljšanje kaskadnog modela.
1.3.4. Definicija faza životnog ciklusa.
1.3.5. Osnovni rad na projektu.
Književnost.
Uvod
Industrijska primjena računala i sve veća potražnja za programima postavili su hitne zadatke za značajno povećanje produktivnost razvoja softvera, razvoj industrijskih metoda za planiranje i projektiranje programa, prijenos organizacijskih, tehničkih, tehničkih, ekonomskih i socio-psiholoških metoda, obrazaca i metoda iz sfere materijalne proizvodnje u sferu računala. Kompleksan pristup procesima razvoja, rada i održavanja softvera postavljaju se brojni gorući problemi, čije će rješenje ukloniti "uska grla" u dizajnu programa, smanjiti vrijeme završetka, poboljšati izbor i prilagodbu. postojeće programe, a možda i odrediti sudbinu sustava s ugrađenim računalima.
U praksi razvoja velikih softverskih projekata često nema jedinstven pristup na procjenu troškova rada, uvjeta rada i troškova materijala, što koči povećanje produktivnosti razvoja softvera, te u konačnici - učinkovito upravljanježivotni ciklus softvera. Budući da program bilo koje vrste postaje proizvod (osim, možda, obrazovnih, mock-up programa), pristup njegovoj proizvodnji trebao bi biti u mnogočemu sličan pristupu proizvodnji industrijskih proizvoda, a pitanja dizajna softvera postaju iznimno važna . Ova ideja je temelj B.U. Boehm "Software Engineering Design", koji smo koristili da ovo napišemo seminarski rad. U ovoj se knjizi softverski dizajn odnosi na proces stvaranja dizajna softverskog proizvoda.
1 Životni ciklus softvera
UVOD
LCPE je kontinuirani proces koji počinje od trenutka donošenja odluke o potrebi izrade softvera i završava u trenutku njegovog potpunog povlačenja iz rada.
Postoji nekoliko pristupa definiranju faza i aktivnosti životnog ciklusa softvera (SLLC), koraka procesa programiranja, vodopada i spiralnih modela. Ali svi sadrže zajedničke temeljne komponente: iskaz problema, dizajn rješenja, implementacija, održavanje.
Najpoznatija i najpotpunija je možda struktura životnog ciklusa prema Boehmu, koja uključuje osam faza. Kasnije će biti detaljnije predstavljen.
Jedna od mogućih opcija može biti opis gornje razine prema Lehmanu, koja uključuje tri glavne faze i predstavlja opis programa životnog ciklusa u najopćenitijem slučaju.
I, za promjenu, evo koraka procesa programiranja koje je predstavio D. Riley u knjizi “Using the Modula-2 Language”. Ova je ideja, po mom mišljenju, vrlo jednostavna i poznata i s njom ćemo započeti.
1.1 Koraci Riley procesa programiranja
Proces programiranja uključuje četiri koraka (slika 1):
prikaz problema, tj. dobivanje odgovarajuće ideje o tome koji bi zadatak program trebao obavljati;
projektiranje rješenja već postavljenog problema (općenito je takvo rješenje manje formalno od konačnog programa);
programsko kodiranje, odnosno prevođenje projektiranog rješenja u program koji se može izvoditi na stroju;
programsku podršku, tj. kontinuirani proces popravljanja grešaka u programu i dodavanja novih značajki.
Riža. 1. Četiri koraka programiranja.
Programiranje počinje od trenutka kada korisnik, tj. netko tko treba program za rješavanje problema postavlja problem Sistemski analitičar. Korisnik i analitičar sustava zajednički definiraju iskaz problema. Potonji se zatim prenosi algoritamist koji je odgovoran za projektiranje rješenja. Rješenje (ili algoritam) je slijed operacija čije izvođenje dovodi do rješenja problema. Budući da algoritam često nije prilagođen za izvođenje na stroju, treba ga prevesti u strojni program. Ovu operaciju izvodi enkoder. Za naknadne izmjene programa odgovoran je prateći programer. I sistemski analitičar, i algoritmist, i koder, i prateći programer - svi su oni programeri.
U slučaju velikog softverskog projekta, broj korisnika, analitičara sustava i algoritama može biti značajan. Osim toga, možda će biti potrebno vratiti se na prethodne korake zbog nepredviđenih okolnosti. Sve ovo služi kao dodatni argument u korist pažljivog dizajna softvera: rezultati svakog koraka trebaju biti potpuni, točni i razumljivi.
1.1.1 Izjava problema
Jedan od najvažnijih koraka u programiranju je postavljanje problema. Funkcionira kao ugovor između korisnika i programera(a). Kao i zakonski loše sastavljen ugovor, loša izjava o misiji je beskorisna. S dobrom postavkom problema, i korisnik i programer jasno i nedvosmisleno predstavljaju zadatak koji treba izvršiti, tj. u ovom slučaju se uzimaju u obzir interesi i korisnika i programera. Korisnik može planirati korištenje softvera koji još nije izrađen, na temelju saznanja da može. Dobra postavka problema služi kao osnova za oblikovanje njegovog rješenja.
Formulacija problema (specifikacija programa); u biti znači točan, potpun i razumljiv opis onoga što se događa kada se određeni program izvrši. Korisnik obično na računalo gleda kao na crnu kutiju: nije mu bitno kako računalo radi, već je bitno da računalo može raditi ono što korisnika zanima. Fokus je na interakciji između čovjeka i stroja.
Karakteristike dobre izjave problema:
Točnost, tj. isključenje svake dvosmislenosti. Ne bi trebalo biti upitno kakav će biti izlaz programa za bilo koji ulaz.
potpunost, tj. razmatranje svih opcija za dati unos, uključujući pogrešan ili neočekivan unos, i određivanje odgovarajućeg izlaza.
Jasnoća, tj. trebao bi biti razumljiv i korisniku i analitičaru sustava, budući da je iskaz problema jedini ugovor između njih.
Često su zahtjevi za točnošću, potpunošću i jasnoćom u sukobu. Stoga je mnoge pravne dokumente teško razumjeti jer su napisani formalnim jezikom koji vam omogućuje da određene odredbe formulirate s najvećom preciznošću, isključujući čak i najbeznačajnija odstupanja. Na primjer, neka pitanja na ispitnim listićima ponekad su formulirana tako precizno da student provede više vremena razumijevajući pitanje nego odgovarajući na njega. Štoviše, učenik možda uopće neće shvatiti glavno značenje pitanja zbog velikog broja detalja. Najbolja izjava problema je ona koja postiže ravnotežu sva tri zahtjeva.
Standardni oblik iskaza problema.
Razmotrite sljedeću izjavu problema: "Unesite tri broja i ispišite brojeve redom."
Takva izjava ne zadovoljava gore navedene zahtjeve: nije ni precizna, ni potpuna, ni razumljiva. Doista, trebaju li brojevi biti uneseni jedan po retku ili svi brojevi u jednom retku? Znači li izraz "redom" redoslijed od najvećeg prema najmanjem, od najmanjeg prema najvećem ili istim redoslijedom kojim su uvedeni.
Očito je da takva izjava ne odgovara na mnoga pitanja. Ako uzmemo u obzir odgovore na sva pitanja, tada će izjava problema postati rječita i teško razumljiva. Stoga D. Riley predlaže korištenje standardnog obrasca za postavljanje problema koji osigurava maksimalnu točnost, potpunost, jasnoću i uključuje:
naziv zadatka (shematska definicija);
pogreške (neuobičajene mogućnosti unosa izričito su navedene kako bi se korisnicima i programerima prikazalo radnje koje će stroj poduzeti u takvim situacijama);
primjer ( dobar primjer može prenijeti bit problema, kao i ilustrirati razne slučajeve).
Primjer. Prikaz problema u standardnom obliku.
TITULA
Razvrstaj tri cijela broja.
OPIS
Ulaz i izlaz tri cijela broja, poredana od najmanjeg prema najvećem.
Upisuju se tri cijela broja, po jedan broj u svakom redu. U ovom slučaju, cijeli broj je jedan ili više uzastopnih decimalne znamenke, ispred kojeg može stajati znak plus "+" ili znak minus "-".
Ispisuju se tri unesena cijela broja, a sva tri se prikazuju u istom retku. Susjedni brojevi odvajaju se razmakom. Brojevi se prikazuju od najmanjeg prema najvećem, s lijeva na desno.
1) Ako se unese manje od tri broja, program čeka dodatni unos.
Životni ciklus softvera - vremensko razdoblje koje počinje od trenutka donošenja odluke o potrebi izrade softverskog proizvoda i završava u trenutku njegovog potpunog povlačenja iz rada.
Procesi životnog ciklusa softvera:
Osnovni, temeljni,
Pomoćni,
Organizacijski.
Glavni:
1. Nabava - radnje i zadaci kupca koji kupuje softver;
2. Isporuka - aktivnosti i zadaci dobavljača koji isporučuje kupcu softverski proizvod ili uslugu;
3. Razvoj - radnje i zadaci koje provodi programer: izrada softvera, izrada projektne i pogonske dokumentacije, priprema materijala za testiranje i obuku;
4. Rad - radnje i zadaće operatera organizacije koja upravlja sustavom;
5. Održavanje - unošenje promjena u softver kako bi se ispravile greške, poboljšale performanse ili prilagodile promjenjivim radnim uvjetima ili zahtjevima.
Pomoćni:
1. Dokumentacija - formalizirani opis informacija nastalih tijekom životnog ciklusa softvera;
2. Upravljanje konfiguracijom - primjena administrativnih i tehničkih postupaka tijekom životnog ciklusa softvera za određivanje stanja komponenti softvera, upravljanje njegovim izmjenama;
3. Osiguranje kvalitete - osiguravanje da softver i procesi njegovog životnog ciklusa budu u skladu s navedenim zahtjevima i odobrenim planovima;
4. Verifikacija - utvrđivanje da softverski proizvodi u potpunosti zadovoljavaju zahtjeve ili uvjete zbog prethodnih radnji;
5. Certifikacija - utvrđivanje potpunosti usklađenosti navedenih zahtjeva i izrađenog sustava s njihovom specifičnom funkcionalnom namjenom;
6. Zajednička procjena - procjena stanja rada na projektu: kontrola planiranja i upravljanja resursima, kadrovima, opremom, alatima;
7. Revizija - utvrđivanje usklađenosti sa zahtjevima, planovima i uvjetima ugovora;
8. 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:
1. Upravljanje - radnje i zadaci koje može obavljati svaka strana koja upravlja svojim procesima;
2. Stvaranje infrastrukture - izbor i održavanje tehnologije, standarda i alata, odabir i instalacija hardvera i softvera koji se koristi za razvoj, rad ili održavanje softvera;
3. Poboljšanje - procjena, mjerenje, kontrola i poboljšanje procesa životnog ciklusa;
4. Osposobljavanje - početno osposobljavanje i naknadno kontinuirano stručno usavršavanje osoblja.
Godine 2002. objavljen je standard za procese životnog ciklusa sustava (ISO/IEC 15288 Procesi životnog ciklusa sustava). U izradi norme sudjelovali su stručnjaci iz različitih područja: sistemskog inženjerstva, programiranja, upravljanja kvalitetom, ljudskih resursa, sigurnosti itd. praktično iskustvo izgradnja sustava u vladinim, komercijalnim, vojnim i akademskim organizacijama. Standard je primjenjiv na široku klasu sustava, ali mu je glavna svrha podržati stvaranje računalnih sustava.
Prema seriji ISO/IEC 15288, sljedeće skupine procesa trebaju biti uključene u strukturu životnog ciklusa:
1. Ugovorni procesi:
Akvizicija (in-house rješenja ili vanjska rješenja dobavljača);
Isporuka (interna rješenja ili rješenja vanjskih dobavljača);
2. Procesi poduzeća:
Kontrolirati okoliš poduzeća;
Upravljanje ulaganjima;
IP upravljanje životnim ciklusom;
Upravljanje resursima;
Kontrola kvalitete;
3. Procesi dizajna:
Planiranje projekta;
Evaluacija projekta;
Kontrola projekta;
Upravljanje rizicima;
Upravljanje konfiguracijom;
Upravljanje protokom informacija;
Donošenje odluka.
4. Tehnički procesi:
Definicija zahtjeva;
Analiza zahtjeva;
Razvoj arhitekture;
implementacija;
Integracija;
Verifikacija;
Tranzicija;
Certifikacija;
iskorištavanje;
Pratnja;
Raspolaganje.
5. Posebni procesi:
Definiranje i uspostavljanje međusobnih odnosa polazeći od zadataka i svrhe.
Uspostavljanje osnovnih procesa životnog ciklusa IP softvera (ISO/IEC 15288)
| Proces (izvršitelj procesa) | Radnje | Ulaz | Proizlaziti |
| Akvizicija (kupac) | - Iniciranje - Priprema prijedloga ponuda - Priprema ugovora - Kontrola aktivnosti dobavljača - Prihvat IP-a | - Odluka o početku rada na implementaciji IP - Rezultati ankete o radnjama kupaca - Rezultati analize IP tržišta/natječaja - Isporuka / razvojni plan - Sveobuhvatno testiranje IP | - Studija izvodljivosti za implementaciju IS - Projektni zadatak za IS - Ugovor o nabavi/razvoju - Akti o prijemu faza radova - Akt o prijemnim ispitivanjima |
| Isporuka (IS programer) | - Iniciranje - Odgovor na ponude - Priprema ugovora - Planiranje izvedbe - IP opskrba | - Projektni zadatak za IS - Odluka uprave o sudjelovanju u razvoju - Rezultati natječaja - Projektni zadatak za IS - Plan upravljanja projektom - Izrađen IS i dokumentacija | - Odluka o sudjelovanju u razvoju - Komercijalne ponude/ ponuda - Ugovor o nabavi/razvoju - Plan upravljanja projektom - Implementacija/prilagodba - Izvješće o prijemnom ispitivanju |
| Razvoj (IS developer) | - Priprema - Analiza zahtjeva IS - Dizajn arhitekture IS - Razvoj softverskih zahtjeva - Dizajn softverske arhitekture - Detaljni dizajn softvera - Kodiranje i testiranje softvera - Integracija softvera i testiranje kvalifikacije softvera - Integracija IS i kvalificirano testiranje IS | - Projektni zadatak za IS - Projektni zadatak za IS, model životnog ciklusa - Podsustavi IS - Specifikacije zahtjeva za komponente softvera - Arhitektura softvera - Detaljni materijali za dizajn softvera - Plan integracije softvera, testovi - Arhitektura IS, softver, dokumentacija za IS, testovi | - Korišteni model životnog ciklusa, razvojni standardi - Plan rada - Sastav podsustava, hardverske komponente - Specifikacije zahtjeva za softverske komponente - Sastav softverskih komponenti, sučelja s bazom podataka, plan integracije softvera - Projekt baze podataka, specifikacije sučelja između softvera komponente, zahtjevi za testove - Tekstovi modula Softver, radnje autonomnog testiranja - Ocjena usklađenosti programskog kompleksa sa zahtjevima TOR-a - Ocjena usklađenosti softvera, baza podataka, tehnički kompleks i set dokumentacije prema zahtjevima TOR-a |
Faze razvoja sustava (ISO/IEC 15288)
CPC: Izradite projektni zadatak za projekt "Queue" na web stranici www.mastertz.ru
Modeli životnog ciklusa softvera:
1. kaskada,
2. spirala,
3. iterativni.
Kaskadni modelživotni ciklus (“model vodopada”, engleski waterfall model) predložio je 1970. Winston Royce. Omogućuje sekvencijalnu provedbu svih faza projekta u strogo utvrđenom redoslijedu. Prijelaz na sljedeću fazu znači potpuni završetak rada u prethodnoj fazi.
Zahtjevi definirani u fazi formiranja zahtjeva strogo su dokumentirani u obliku projektnog zadatka i fiksni za cijelo vrijeme trajanja razvoja projekta.
Svaka faza kulminira izdavanjem cjelovitog skupa dokumentacije koja je dovoljna da razvoj nastavi drugi razvojni tim.
|
|
spiralni model(engleski spiralni model) razvio je Barry Boehm sredinom 1980-ih. Temelji se na klasičnom ciklusu PDCA (planiraj-učini-provjeri-djeluj) Edwarda Deminga. Kod korištenja ovog modela softver se izrađuje u nekoliko iteracija (spiralnih zavoja) izradom prototipa.
Prototip je aktivna softverska komponenta koja implementira pojedinačne funkcije i vanjska sučelja.
Svaka iteracija odgovara izradi fragmenta ili verzije softvera, pri čemu se specificiraju ciljevi i karakteristike projekta, procjenjuje kvaliteta dobivenih rezultata i planira rad sljedeće iteracije.
Riža. 21. Spiralni model životnog ciklusa softvera
U svakoj iteraciji ocjenjuje se sljedeće:
1. Rizik prekoračenja uvjeta i troškova projekta;
2. Potreba za izvođenjem još jedne iteracije;
3. Stupanj potpunosti i točnosti razumijevanja zahtjeva za sustav;
4. Svrsishodnost prekida projekta.
Jedan primjer implementacije spiralnog modela je RAD.
Osnovni principi RAD-a:
1. Komplet alata trebao bi biti usmjeren na smanjenje vremena razvoja;
2. Izrada prototipa za razjašnjavanje zahtjeva kupaca;
3. Ciklus razvoja: svaka nova verzija proizvoda temelji se na procjeni rezultata rada prethodne verzije od strane kupca;
4. Minimiziranje vremena razvoja verzije prijenosom gotovih modula i dodavanjem funkcionalnosti novoj verziji;
5. Razvojni tim mora blisko surađivati, svaki član mora biti spreman obavljati višestruke odgovornosti;
6. Upravljanje projektom treba minimizirati trajanje razvojnog ciklusa.
Iterativni model: prirodni razvoj kaskadnog i spiralnog modela doveo je do njihove konvergencije i nastanka modernog iterativnog pristupa, koji je racionalna kombinacija ovih modela.
Riža. 22. Iterativni model životnog ciklusa softvera
Životni ciklus softvera
Životni ciklus softvera je vremensko razdoblje koje počinje od trenutka donošenja odluke o potrebi izrade softverskog proizvoda i završava u trenutku njegovog potpunog povlačenja iz rada. (IEEE Std 610.12)
Potreba za određivanjem faza životnog ciklusa softvera (LC) nastala je zbog želje programera da poboljšaju kvalitetu softvera optimalnim upravljanjem razvojem i korištenjem različitih mehanizama kontrole kvalitete u svakoj fazi, od postavljanja zadataka do izrade softvera. Najopćenitiji prikaz životnog ciklusa softvera je model u obliku osnovnih faza – procesa koji uključuju:
Analiza sustava i obrazloženje softverskih zahtjeva;
Idejni (skica) i detaljni (tehnički) dizajn softvera;
Razvoj programskih komponenti, njihova integracija i općenito otklanjanje programskih pogrešaka;
Testiranje, probni rad i replikacija softvera;
Redoviti rad softvera, održavanje rada i analiza rezultata;
Održavanje softvera, njegove izmjene i poboljšanja, izrada novih verzija.
Ovaj model je općeprihvaćen i odgovara i domaćim regulatorni dokumenti u području razvoja softvera, te inozem. Sa stajališta osiguranja tehnološke sigurnosti, preporučljivo je detaljnije razmotriti značajke prikaza faza životnog ciklusa u stranim modelima, budući da je strani softver najvjerojatniji nositelj softverskih nedostataka sabotažni tip.
Standardi životnog ciklusa softvera
GOST 34.601-90
ISO/IEC 12207:1995 (ruski analog - GOST R ISO/IEC 12207-99)
Grafički prikaz modela životnog ciklusa omogućuje vizualno isticanje njihovih značajki i nekih svojstava procesa.
U početku je kreiran kaskadni model životnog ciklusa u kojem su glavne faze započinjale jedna za drugom korištenjem rezultata prethodni radovi. Omogućuje sekvencijalnu provedbu svih faza projekta u strogo utvrđenom redoslijedu. Prijelaz na sljedeću fazu znači potpuni završetak rada u prethodnoj fazi. Zahtjevi definirani u fazi formiranja zahtjeva strogo su dokumentirani u obliku projektnog zadatka i fiksni za cijelo vrijeme trajanja razvoja projekta. Svaka faza kulminira izdavanjem cjelovitog skupa dokumentacije koja je dovoljna da razvoj nastavi drugi razvojni tim. Netočnost bilo kojeg zahtjeva ili njegovo netočno tumačenje kao rezultat dovodi do činjenice da se morate "vratiti" u ranu fazu projekta, a potrebna revizija ne samo da izbacuje projektni tim iz rasporeda, već često dovodi do kvalitativno povećanje troškova i, moguće je, do prekida projekta u obliku u kojem je izvorno zamišljen. Glavna zabluda autora modela vodopada je pretpostavka da dizajn prolazi cijeli proces jednom, da je dizajnirana arhitektura dobra i laka za korištenje, da je dizajn implementacije razuman, a da se greške u implementaciji lako otklanjaju testiranje. Ovaj model pretpostavlja da će sve pogreške biti koncentrirane u implementaciji, pa se stoga njihovo uklanjanje događa ravnomjerno tijekom testiranja komponenti i sustava. Stoga model vodopada za velike projekte nije baš realan i može se učinkovito koristiti samo za stvaranje malih sustava.
Najspecifičniji je spiralni model životnog ciklusa. Ovaj model fokusiran je na iterativni proces početne faze oblikovati. U tim fazama, koncepti, specifikacije zahtjeva, preliminarni i detaljni dizajn. U svakom krugu specificira se sadržaj rada i koncentrira se izgled softvera koji se izrađuje, procjenjuje se kvaliteta dobivenih rezultata i planira rad sljedeće iteracije. U svakoj iteraciji ocjenjuje se sljedeće:
Rizik prekoračenja uvjeta i troškova projekta;
Potreba za izvođenjem još jedne iteracije;
Stupanj potpunosti i točnosti razumijevanja zahtjeva za sustav;
Svrsishodnost prekida projekta.
Standardizacija životnog ciklusa softvera provodi se u tri smjera. Prvi smjer organiziraju i potiču Međunarodna organizacija za normizaciju (ISO - International Standard Organisation) i Međunarodna elektrotehnička komisija (IEC - International Electro-technical Commission). Na ovoj razini provodi se standardizacija najčešćih tehnoloških procesa koji su važni za međunarodnu suradnju. Drugi smjer aktivno razvija u SAD-u Institut inženjera elektrotehnike i elektronike (IEEE - Institute of Electrotechnical and Electronics Engineers) zajedno s Američkim nacionalnim institutom za standarde (ANSI). Standardi ISO/IEC i ANSI/IEEE uglavnom su savjetodavne prirode. Treći smjer potiče Ministarstvo obrane SAD-a (Department of Defence-DOD). Standardi DOD-a obvezni su za tvrtke koje rade u ime Ministarstva obrane SAD-a.
Za dizajn softvera za složeni sustav, posebno sustav u stvarnom vremenu, preporučljivo je koristiti model životnog ciklusa cijelog sustava koji se temelji na integraciji svih poznata djela unutar razmatranih osnovnih procesa. Ovaj model je namijenjen za korištenje u planiranju, rasporedu, upravljanju različitim softverskim projektima.
Preporučljivo je skup faza ovog modela životnog ciklusa podijeliti u dva dijela, koji se značajno razlikuju po značajkama procesa, tehničkim i ekonomskim karakteristikama i čimbenicima koji na njih utječu.
U prvom dijelu životnog ciklusa provodi se analiza sustava, dizajn, razvoj, testiranje i testiranje softvera. Opseg radova, njihova složenost, trajanje i druge karakteristike u ovim fazama značajno ovise o objektu i okruženju razvoja. Proučavanje takvih ovisnosti za različite klase softvera omogućuje predviđanje sastava i glavnih karakteristika rasporeda rada za nove verzije softvera.
Drugi dio životnog ciklusa, koji odražava podršku za rad i održavanje softvera, relativno je slabo vezan uz karakteristike objekta i razvojnog okruženja. Opseg rada u ovim fazama je stabilniji, a njihova složenost i trajanje mogu značajno varirati, a ovise o masovnosti primjene softvera. Za bilo koji model životnog ciklusa, osiguranje visoke kvalitete softverskih sustava moguće je samo uz korištenje reguliranog tehnološki proces u svakoj od ovih faza. Takav proces podržavaju alati za automatizaciju razvoja, koje je preporučljivo odabrati među postojećim ili izraditi uzimajući u obzir razvojni objekt i njemu odgovarajući popis radova.
