Právo a právo
Životný cyklus softvéru Životný cyklus softvér
- časový úsek, ktorý začína okamihom prijatia rozhodnutia o potrebe vytvorenia softvérového produktu a končí okamihom jeho úplného stiahnutia z prevádzky. (IEEE Std 610.12) Potreba určiť fázy životného cyklu softvéru (LC) je spôsobená túžbou vývojárov zlepšiť kvalitu softvéru optimálne ovládanie
vývoj a používanie rôznych mechanizmov kontroly kvality v každej fáze, od formulácie problému až po softvérovú podporu autora. Najvšeobecnejším znázornením životného cyklu softvéru je model vo forme základných etáp – procesov, medzi ktoré patria:
Systémová analýza a zdôvodnenie softvérových požiadaviek;
Predbežný (návrh) a podrobný (technický) návrh softvéru;
Vývoj softvérových komponentov, ich integrácia a ladenie softvéru ako celku;
Testovanie, skúšobná prevádzka a replikácia softvéru;
Pravidelná prevádzka softvéru, podpora prevádzky a analýzy výsledkov;
Údržba softvéru, jeho úpravy a vylepšovanie, tvorba nových verzií. Tento model je všeobecne akceptovaný a vyhovuje tak domácim predpisom v oblasti vývoja softvéru, ako aj zahraničným. Z hľadiska zaistenia technologickej bezpečnosti je vhodné podrobnejšie zvážiť vlastnosti znázornenia štádií životného cyklu v zahraničných modeloch, keďže ide o cudzie softvér
Štandardy životného cyklu softvéru
GOST 34.601-90
ISO/IEC 12207:1995 (ruský ekvivalent - GOST R ISO/IEC 12207-99)
Grafické znázornenie modelov životného cyklu umožňuje jasne zvýrazniť ich vlastnosti a niektoré vlastnosti procesov.
Spočiatku bol vytvorený kaskádový model životného cyklu, v ktorom hlavné etapy začali jedna po druhej s využitím výsledkov predchádzajúcej práce. Zabezpečuje postupnú realizáciu všetkých etáp projektu v presne stanovenom poradí. Prechod do ďalšej fázy znamená úplné dokončenie práce v predchádzajúcej fáze. Požiadavky stanovené vo fáze tvorby požiadaviek sú prísne zdokumentované vo forme technických špecifikácií a zaznamenávajú sa počas celého vývoja projektu. Každá fáza vyvrcholí vydaním kompletného súboru dokumentácie, ktorý je dostatočný na to, aby vo vývoji mohol pokračovať ďalší vývojový tím. Nepresnosť akejkoľvek požiadavky alebo jej nesprávna interpretácia má za následok, že je potrebné sa „vrátiť“ do ranej fázy projektu a požadované prepracovanie nielen vychýli projektový tím z harmonogramu, ale často vedie ku kvalitatívnemu zvýšeniu náklady a prípadne do ukončenia projektu v podobe, v akej bol pôvodne zamýšľaný. Hlavnými mylnými predstavami autorov vodopádového modelu sú predpoklady, že projekt raz prejde celým procesom, navrhnutá architektúra je dobrá a ľahko použiteľná, návrh implementácie je rozumný a chyby pri implementácii sa dajú ľahko odstrániť testovaním. Tento model predpokladá, že všetky chyby sa budú koncentrovať pri implementácii, a preto k ich odstraňovaniu dochádza rovnomerne pri testovaní komponentov a systému. Teda vodopádový model pre veľkých projektov nie je príliš realistický a dá sa efektívne použiť len na vytváranie malých systémov.
Najšpecifickejší je špirálový model životného cyklu. Tento model sa zameriava na iteratívny proces počiatočných fáz návrhu. V týchto fázach sa postupne vytvárajú koncepty, špecifikácie požiadaviek, predbežné a podrobné návrhy. Na každom kroku sa objasňuje obsah práce a sústreďuje sa vzhľad vytváraného softvéru, hodnotí sa kvalita získaných výsledkov a plánuje sa práca ďalšej iterácie. Pri každej iterácii sa vyhodnocujú:
Riziko prekročenia termínov projektu a nákladov;
Potreba vykonať ďalšiu iteráciu;
Stupeň úplnosti a presnosti pochopenia systémových požiadaviek;
Možnosť ukončenia projektu.
Štandardizácia životného cyklu softvéru prebieha v troch smeroch. Prvý smer organizuje a stimuluje Medzinárodná organizácia pre normalizáciu (ISO - International Standard Organization) a Medzinárodná elektrotechnická komisia (IEC - International Electro-technical Commission). Na tejto úrovni sa uskutočňuje štandardizácia najvšeobecnejších technologických procesov, ktoré sú dôležité pre medzinárodnú spoluprácu. Druhý smer aktívne rozvíja v USA Institute of Electrical and Electronics Engineers (IEEE) spolu s American National Standards Institute (ANSI). Normy ISO/IEC a ANSI/IEEE majú predovšetkým poradný charakter. Tretí smer stimuluje Ministerstvo obrany USA (DOD). Normy DOD sú povinné pre spoločnosti pracujúce pre Ministerstvo obrany USA.
Pre návrh softvéru komplexný systém, najmä systémov v reálnom čase, je vhodné použiť celosystémový model životného cyklu založený na kombinácii všetkých známych prác v rámci uvažovaných základných procesov. Tento model je určený na použitie pri plánovaní, plánovaní a riadení rôznych softvérových projektov.
Súbor etáp tohto modelu životného cyklu je vhodné rozdeliť na dve časti, ktoré sa výrazne líšia vlastnosťami procesov, technickými a ekonomickými charakteristikami a faktormi, ktoré ich ovplyvňujú.
V prvej časti životného cyklu systémová analýza, návrh, vývoj, testovanie a testovanie softvéru. Rozsah práce, jej zložitosť, trvanie a ďalšie charakteristiky v týchto fázach výrazne závisia od objektu a vývojového prostredia. Štúdium takýchto závislostí pre rôzne triedy softvéru nám umožňuje predpovedať zloženie a hlavné charakteristiky pracovných plánov pre nové verzie softvéru.
Druhá časť životného cyklu, reflektujúca podporu prevádzky a údržby softvéru, pomerne slabo súvisí s charakteristikami objektu a vývojového prostredia. Rozsah práce v týchto fázach je stabilnejší, ale ich pracovná náročnosť a trvanie sa môžu výrazne líšiť a závisia od rozšíreného používania softvéru. Pre každý model životného cyklu, poskytovanie vysoká kvalita softvérových balíkov je možné len pri použití regul technologický postup v každej z týchto fáz. Tento proces je podporovaný nástrojmi automatizácie vývoja, ktoré je vhodné vybrať z dostupných alebo ich vytvoriť s prihliadnutím na objekt vývoja a jemu adekvátny zoznam prác.
Anotácia.
Úvod.
1. Životný cyklus softvéru
Úvod.
Kroky procesu programovania Riley
Úvod.
1.1.1. Vyhlásenie o probléme.
1.1.2. Návrh riešenia.
1.1.3. Kódovanie algoritmov.
1.1.4. Programová podpora.
1.1.5. Softvérová dokumentácia.
Záver k bodu 1.1
1.2. Definícia LCPO podľa Lehmana.
Úvod.
1.2.1 Definícia systému.
1.2.2. Implementácia.
1.2.3. servis.
Záver k článku 1.2.
1.3. Fázy a práca LCPO podľa Boehma
1.3.1. Kaskádový model.
1.3.2. Ekonomické opodstatnenie kaskádového modelu.
1.3.3. Vylepšenie kaskádového modelu.
1.3.4. Stanovenie fáz životného cyklu.
1.3.5. Hlavná práca na projekte.
Literatúra.
Úvod
Priemyselné využitie počítačov a rastúci dopyt po programoch predstavujú naliehavé výzvy, ktoré treba výrazne zvýšiť produktivita vývoja softvéru, rozvoj priemyselných metód plánovania a tvorby programov, prenos organizačných, technických, technických, ekonomických a sociálno-psychologických techník, vzorov a metód zo sféry materiálovej výroby do sféry využitia počítačov. Integrovaný prístup do procesov vývoja, prevádzky a údržby softvéru predložil množstvo naliehavých problémov, ktorých riešením sa odstránia úzke miesta pri navrhovaní programov, skráti sa čas dokončenia práce, zlepší sa výber a prispôsobenie existujúcich programov a možno sa určí osud systémov so zabudovanými počítačmi.
V praxi vývoja veľkých softvérových projektov často neexistuje jednotný prístup na hodnotenie mzdových nákladov, termínov prác a materiálových nákladov, čo bráni zvyšovaniu produktivity vývoja softvéru a v konečnom dôsledku aj efektívnemu riadeniu životného cyklu softvéru. Keďže program akéhokoľvek typu sa stáva produktom (snáď okrem vzdelávacích, prototypových programov), prístup k jeho výrobe by mal byť v mnohom podobný prístupu k výrobe priemyselných produktov a otázky dizajnu programu sa stávajú mimoriadne dôležitými. Táto myšlienka je jadrom knihy B.W. Boehmovo „Softvérové inžinierstvo“, ktoré sme použili na napísanie tohto článku práca v kurze. V tejto knihe sa softvérový dizajn vzťahuje na proces vytvárania dizajnu softvérového produktu.
1 Životný cyklus softvéru
ÚVOD
LCPO je nepretržitý proces, ktorý sa začína od okamihu prijatia rozhodnutia o potrebe vytvorenia softvéru a končí okamihom jeho úplného vyradenia z prevádzky.
Existuje niekoľko prístupov k určovaniu fáz a činností životného cyklu softvéru (SLC), krokov procesu programovania, kaskádových a špirálových modelov. Všetky však obsahujú spoločné základné komponenty: vyhlásenie o probléme, návrh riešenia, implementácia, údržba.
Najznámejšia a najkompletnejšia je snáď štruktúra procesu životného cyklu podľa Boehma, ktorý zahŕňa osem fáz. Podrobnejšie bude predstavený v budúcnosti.
Jednou z možných možností by mohol byť popis na najvyššej úrovni podľa Lehmana, ktorý zahŕňa tri hlavné fázy a predstavuje popis životného cyklu v najvšeobecnejšom prípade.
A pre spestrenie uvádzame kroky procesu programovania, ktoré predstavil D. Riley v knihe „Using the Modula-2 Language“. Táto myšlienka je podľa môjho názoru veľmi jednoduchá a známa a začnime ňou.
1.1 Kroky v procese programovania Riley
Úvod
Proces programovania zahŕňa štyri kroky (obrázok 1):
vyjadrenie problému, t.j. získanie primeraného pochopenia toho, akú úlohu by mal program vykonávať;
navrhnutie riešenia už uvedeného problému (vo všeobecnosti je takéto riešenie menej formálne ako výsledný program);
programové kódovanie, t. j. preklad navrhnutého riešenia do programu, ktorý je možné vykonať na stroji;
programová podpora, t.j. prebiehajúci proces odstraňovania problémov s programom a pridávania nových funkcií.
Ryža. 1.Štyri kroky programovania.
Programovanie začína od momentu, kedy užívateľ, t.j. niekto, kto potrebuje program na vyriešenie problému, uvádza problém systémový analytik. Používateľ a systémový analytik spoločne definujú vyhlásenie o probléme. Ten sa potom prenáša algoritmista, ktorý je zodpovedný za návrh riešenia. Riešenie (alebo algoritmus) predstavuje postupnosť operácií, ktorých vykonanie vedie k riešeniu problému. Keďže algoritmus často nie je vhodný na vykonanie na počítači, mal by byť preložený do strojového programu. Túto operáciu vykonáva kódovač. Správca je zodpovedný za následné zmeny programu. programátor. A systémový analytik, algoritmus, kódovač a sprievodný programátor - to všetko sú programátori.
V prípade veľkého softvérového projektu môže byť počet používateľov, systémových analytikov a algoritmistov významný. Okrem toho môže byť potrebné vrátiť sa k predchádzajúcim krokom v dôsledku nepredvídaných okolností. Toto všetko slúži ako dodatočný argument v prospech starostlivého návrhu softvéru: výsledky každého kroku by mali byť úplné, presné a zrozumiteľné.
1.1.1 Vyhlásenie o probléme
Jedným z najdôležitejších krokov v programovaní je definovanie problému. Funguje ako zmluva medzi používateľom a programátorom (programátormi). Rovnako ako právne zle vypracovaná zmluva, aj zle napísané vyhlásenie o probléme je zbytočné. Pri dobrom zadaní problému užívateľ aj programátor jasne a jednoznačne predstavujú úlohu, ktorú je potrebné vykonať, t.j. v tomto prípade sa berú do úvahy záujmy používateľa aj programátora. Používateľ si môže naplánovať používanie softvéru, ktorý ešte nebol vytvorený, na základe znalosti toho, čo dokáže. Dobré vyjadrenie problému slúži ako základ pre formuláciu jeho riešenia.
Vyhlásenie o probléme (špecifikácia programu); v podstate znamená presný, úplný a zrozumiteľný popis toho, čo sa stane, keď sa spustí konkrétny program. Používateľ sa zvyčajne pozerá na počítač ako na čiernu skrinku: pre neho nezáleží na tom, ako počítač funguje, ale dôležité je, čo počítač dokáže, čo používateľa zaujíma. V tomto prípade je hlavná pozornosť zameraná na interakciu človeka so strojom.
Charakteristiky dobrého vyhlásenia o probléme:
Presnosť, t.j. odstránenie akejkoľvek nejednoznačnosti. Nemali by existovať žiadne otázky o tom, aký bude výstup programu pre daný vstup.
Úplnosť, t.j. zváženie všetkých možností pre daný vstup, vrátane chybného alebo neúmyselného vstupu, a určenie vhodného výstupu.
Jasnosť, t.j. musí byť zrozumiteľné pre používateľa aj pre systémového analytika, pretože vyhlásenie o probléme je jedinou zmluvou medzi nimi.
Požiadavky na presnosť, úplnosť a jasnosť sú často v rozpore. Mnohé právne dokumenty sú teda ťažko zrozumiteľné, pretože sú napísané vo formálnom jazyku, čo umožňuje formulovať určité ustanovenia s mimoriadnou presnosťou, s vylúčením akýchkoľvek menších nezrovnalostí. Napríklad niektoré otázky v písomných prácach sú niekedy formulované tak presne, že študent strávi viac času porozumením otázky, ako jej zodpovedaním. Študent navyše nemusí pochopiť ani hlavný zmysel otázky kvôli veľkému množstvu detailov. Najlepšia formulácia problému je taká, ktorá dosahuje rovnováhu všetkých troch požiadaviek.
Štandardná forma vyhlásenia o probléme.
Zamyslite sa nad nasledujúcim problémom: „Zadajte tri čísla a vypíšte čísla v poradí.“
Takéto vyhlásenie nespĺňa vyššie uvedené požiadavky: nie je presné, ani úplné, ani zrozumiteľné. Naozaj, mali by sa čísla zadávať jedno na riadok alebo všetky čísla na jeden riadok? Znamená výraz „v poradí“ zoradenie od najväčšieho po najmenšie, od najmenšieho po najväčšie alebo rovnaké poradie, v akom boli uvedené?
Je zrejmé, že takéto vyhlásenie neodpovedá na mnohé otázky. Ak vezmeme do úvahy odpovede na všetky otázky, potom sa vyhlásenie o probléme stane podrobným a ťažko pochopiteľným. Preto D. Riley navrhuje použiť na nastavenie problému štandardný formulár, ktorý zaisťuje maximálnu presnosť, úplnosť, prehľadnosť a zahŕňa:
názov úlohy (schematická definícia);
všeobecný popis (stručné zhrnutie úlohy);
chyby (neobvyklé možnosti vstupu sú explicitne uvedené, aby ukázali používateľom a programátorom, aké akcie by stroj vykonal v takýchto situáciách);
príklad ( dobrý príklad môže vyjadriť podstatu problému, ako aj ilustrovať rôzne prípady).
Príklad. Vyhlásenie problému v štandardnej forme.
NAME
Triedenie troch celých čísel.
POPIS
Vstup a výstup troch celých čísel zoradených od najmenšieho po najväčšie číslo.
Zadávajú sa tri celé čísla, jedno číslo na riadok. Celé číslo je jedna alebo viac po sebe nasledujúcich desatinných číslic, ktorým môže predchádzať znamienko plus „+“ alebo znamienko mínus „–“.
Vytlačia sa tri zadané celé čísla, pričom všetky tri sa vytlačia na rovnaký riadok. Susedné čísla sú oddelené medzerou. Čísla sa zobrazujú od najmenšieho po najväčšie, zľava doprava.
1) Ak zadáte menej ako tri čísla, program čaká na ďalšie zadanie.
2) Iné vstupné riadky ako prvé tri sa ignorujú.
3) Ak niektorý z prvých troch riadkov obsahuje viac ako jedno celé číslo, program sa ukončí a zobrazí hlásenie.
v elektrotechnike). Táto norma definuje štruktúru životného cyklu obsahujúcu procesy, činnosti a úlohy, ktoré musia byť dokončené pri vytváraní softvérového systému.V tomto štandarde PS (resp softvérový produkt) je definovaný ako súbor počítačové programy, postupy a prípadne súvisiacu dokumentáciu a údaje. Proces je definovaný ako súbor vzájomne súvisiacich akcií, ktoré transformujú niektoré vstupné dáta na výstup (G. Myers to nazýva preklad dát). Každý proces je charakterizovaný určitými úlohami a metódami na ich riešenie. Na druhej strane je každý proces rozdelený na súbor akcií a každá akcia na súbor úloh. Každý proces, akcia alebo úloha je iniciovaná a vykonávaná iným procesom podľa potreby a neexistujú žiadne vopred určené sekvencie vykonávania (samozrejme pri zachovaní spojení naprieč vstupnými dátami).
Je potrebné poznamenať, že v Sovietskom zväze a potom v Rusku bola tvorba softvéru (softvéru) spočiatku, v 70. rokoch minulého storočia, regulovaná normami GOST ESPD ( Jednotný systém programová dokumentácia - séria GOST 19.ХХХ), ktoré boli zamerané na triedu relatívne jednoduchých maloobjemových programov vytvorených jednotlivými programátormi. V súčasnosti sú tieto normy koncepčne a formálne zastarané, doba ich platnosti uplynula a ich používanie je nevhodné.
Procesy tvorby automatizované systémy(AS), ktorý zahŕňa softvér, sú regulované normami GOST 34.601-90 " Informačné technológie. Súbor noriem pre automatizované systémy. Etapy tvorby", GOST 34.602-89 "Informačné technológie. Súbor noriem pre automatizované systémy. Referenčné podmienky na vytvorenie automatizovaného systému“ a GOST 34.603-92 „Informačné technológie. Typy testovania automatizovaných systémov." Mnohé ustanovenia týchto noriem sú však zastarané a iné nie sú dostatočne reflektované na to, aby sa dali použiť na seriózne projekty na vytvorenie PS. Preto je pri domácom vývoji vhodné využívať moderné medzinárodné štandardy.
Podľa norma ISO/ IEC 12207 sú všetky procesy životného cyklu softvéru rozdelené do troch skupín (obr. 5.1).
Ryža. 5.1.
Skupiny definujú päť hlavných procesov: akvizíciu, dodávku, vývoj, prevádzku a podporu. Osem pomocných procesov zabezpečuje vykonávanie hlavných procesov, a to dokumentáciu, konfiguračný manažment, zabezpečenie kvality, overovanie, certifikácia, spoločné hodnotenie, audit, riešenie problémov. Štyri organizačné procesy poskytujú manažment, infraštruktúru, zlepšovanie a učenie.
5.2. Hlavné procesy životného cyklu PS
Proces akvizície pozostáva z akcií a úloh zákazníka, ktorý si softvér kupuje. Tento proces pokrýva tieto činnosti:
- začatie akvizície;
- príprava návrhov ponúk;
- príprava a úprava zmluvy;
- dohľad nad činnosťou dodávateľa;
- prijatie a dokončenie práce.
Začatie akvizície zahŕňa nasledujúce úlohy:
- určenie potrieb zákazníka na získanie, vývoj alebo zlepšenie systému, softvérových produktov alebo služieb;
- prijímanie rozhodnutí týkajúcich sa získavania, vývoja alebo zlepšovania existujúceho softvéru;
- kontrola dostupnosti potrebnú dokumentáciu, záruky, certifikáty, licencie a podpora v prípade nákupu softvérového produktu;
- príprava a schválenie akvizičného plánu vrátane systémových požiadaviek, typu zmluvy, zodpovednosti zmluvných strán a pod.
Návrhy žiadostí musia obsahovať:
- požiadavky na systém;
- zoznam softvérových produktov;
- podmienky akvizície a dohody;
- technické obmedzenia (napríklad na operačné prostredie systému).
Ponuky sa zasielajú vybranému dodávateľovi alebo viacerým dodávateľom v prípade výberového konania. Dodávateľ je organizácia, ktorá uzatvorí zmluvu so zákazníkom na dodávku systému, softvéru alebo softvérovej služby za podmienok uvedených v zmluve.
Príprava a úprava zmluvy zahŕňa tieto úlohy:
- určenie postupu pri výbere dodávateľa objednávateľom vrátane kritérií hodnotenia návrhov od možných dodávateľov;
- výber konkrétneho dodávateľa na základe analýzy návrhov;
- príprava a záver dohody s dodávateľom;
- vykonávanie zmien (v prípade potreby) zmluvy počas jej realizácie.
Dohľad nad činnosťami dodávateľa sa vykonáva v súlade s opatreniami stanovenými v procesoch spoločného hodnotenia a auditu. Počas akceptačného procesu sa pripravia a vykonajú potrebné testy. Ukončenie prác podľa zmluvy sa vykonáva pri splnení všetkých akceptačných podmienok.
Proces dodávky zahŕňa činnosti a úlohy vykonávané dodávateľom, ktorý dodáva zákazníkovi softvérový produkt alebo službu. Tento proces zahŕňa nasledujúce kroky:
- začatie dodávky;
- príprava odpovede na návrhy ponúk;
- príprava zmluvy;
- plánovanie prác na základe zmluvy;
- vykonávanie a kontrola zmluvných prác a ich vyhodnocovanie;
- dodanie a dokončenie prác.
Iniciácia dodávky spočíva v tom, že dodávateľ posúdi ponuky a rozhodne sa, či súhlasí s uvedenými požiadavkami a podmienkami alebo ponúkne svoje (odsúhlasené). Plánovanie zahŕňa nasledujúce úlohy:
- rozhodovanie dodávateľa o vykonaní prác samostatne alebo so zapojením subdodávateľa;
- vypracovanie plánu riadenia projektu dodávateľom obsahujúceho organizačnej štruktúry projekt, rozdelenie zodpovednosti, technické požiadavky do vývojového prostredia a zdrojov, manažmentu subdodávateľov a pod.
Proces vývoja zahŕňa akcie a úlohy vykonávané vývojárom a pokrýva prácu na vytváraní softvéru a jeho komponentov v súlade so špecifikovanými požiadavkami. Patrí sem príprava projektovej a prevádzkovej dokumentácie, príprava materiálov potrebných na testovanie výkonu a kvalitu softvérových produktov, materiály potrebné na organizáciu školení personálu a pod.
Proces vývoja zahŕňa nasledujúce kroky:
- prípravné práce;
- analýza systémových požiadaviek;
- návrh architektúry systému;
- Analýza softvérových požiadaviek;
- Návrh softvérovej architektúry;
- podrobný návrh softvéru;
- kódovanie a testovanie softvéru;
- integrácia softvéru;
- testovanie kvalifikácie softvéru;
- systémová integrácia;
- testovanie kvalifikácie systému;
- inštalácia softvéru;
- akceptácia softvéru.
Prípravné práce začínajú výberom modelu životného cyklu softvéru, ktorý zodpovedá rozsahu, významu a zložitosti projektu. Činnosti a úlohy vývojového procesu musia zodpovedať zvolenému modelu. Developer musí vybrať, prispôsobiť podmienkam projektu a použiť štandardy, metódy a vývojové nástroje, ako aj vypracovať plán vykonávania prác.
Analýza požiadaviek na systém zahŕňa určenie jeho funkčnosti, užívateľské požiadavky, požiadavky na spoľahlivosť, bezpečnosť, požiadavky na externé rozhrania, výkon atď. Systémové požiadavky sa posudzujú na základe kritérií uskutočniteľnosti a testovateľnosti.
Návrh architektúry systému zahŕňa určenie komponentov jeho hardvéru (hardvéru), softvéru a operácií vykonávaných personálom obsluhujúcim systém. Architektúra systému musí zodpovedať systémovým požiadavkám a akceptovaným štandardom a praktikám návrhu.
Analýza požiadaviek na softvér zahŕňa určenie nasledujúce charakteristiky pre každý softvérový komponent:
- funkčnosť vrátane výkonnostných charakteristík a prevádzkového prostredia komponentu;
- externé rozhrania;
- špecifikácie spoľahlivosti a bezpečnosti;
- ergonomické požiadavky;
- požiadavky na používané údaje;
- požiadavky na inštaláciu a akceptáciu;
- požiadavky na užívateľskú dokumentáciu;
- požiadavky na prevádzku a údržbu.
Požiadavky na softvér sa posudzujú na základe kritérií zhody s požiadavkami na systém ako celok, realizovateľnosti a testovateľnosti.
Návrh softvérovej architektúry zahŕňa nasledujúce úlohy pre každý softvérový komponent:
- transformácia softvérových požiadaviek na architektúru, ktorá na vysokej úrovni definuje štruktúru softvéru a zloženie jeho komponentov;
- vývoj a dokumentácia softvérových rozhraní a databáz (DB);
- vývoj predbežnej verzie užívateľskej dokumentácie;
- vývoj a dokumentácia predbežných testovacích požiadaviek a plánu integrácie softvéru.
Podrobný návrh softvéru zahŕňa nasledujúce úlohy:
- popis softvérových komponentov a rozhraní medzi nimi na nižšej úrovni postačujúcej na následné kódovanie a testovanie;
- vývoj a dokumentovanie podrobného návrhu databázy;
- aktualizácia (v prípade potreby) užívateľskej dokumentácie;
- vývoj a dokumentácia testovacích požiadaviek a plánu testovania softvérových komponentov;
Kódovanie a testovanie softvéru zahŕňa nasledujúce úlohy:
- kódovanie a dokumentovanie každého softvérového komponentu a databázy, ako aj príprava súboru testovacích postupov a údajov na ich testovanie;
- testovanie každého softvérového a databázového komponentu z hľadiska zhody s požiadavkami na ne, po čom nasleduje dokumentácia výsledkov testov;
- aktualizácia dokumentácie (ak je to potrebné);
- aktualizovať plán integrácie softvéru.
Integrácia softvéru zahŕňa zostavenie vyvinutých softvérových komponentov v súlade s plánom integrácie a testovania pre agregované komponenty. Pre každý z agregovaných komponentov sú vyvinuté testovacie súbory a testovacie postupy na overenie každej z kvalifikačných požiadaviek počas následného kvalifikačného testovania. Kvalifikačná požiadavka je súbor kritérií alebo podmienok, ktoré musia byť splnené, aby sa kvalifikovali softvérový produkt ako spĺňajúce jeho špecifikácie a pripravené na použitie v teréne.
Testovanie kvalifikácie softvéru vykonáva vývojár v prítomnosti zákazníka (
Proces prevádzky pokrýva činnosti a úlohy organizácie prevádzkovateľa prevádzkujúcej systém. Proces operácie zahŕňa nasledujúce kroky.
Prípravné práce, ktoré zahŕňajú operátora, ktorý vykonáva tieto úlohy:
- plánovanie činností a prác vykonávaných počas prevádzky a stanovovanie prevádzkových noriem;
- stanovenie postupov na lokalizáciu a riešenie problémov, ktoré vznikajú počas prevádzky.
- Prevádzkové testovanie vykonávané pre každé nasledujúce vydanie softvérového produktu, po ktorom je toto vydanie uvedené do prevádzky.
- Vlastná prevádzka systému, ktorá sa vykonáva v prostredí na to určenom v súlade s užívateľskou dokumentáciou.
- analýza problémov a požiadaviek na úpravu softvéru (analýza správ o probléme alebo žiadosti o úpravu, posúdenie rozsahu, nákladov na úpravu, výsledného efektu, posúdenie realizovateľnosti úpravy);
- úprava softvéru (vykonávanie zmien komponentov a dokumentácie softvérového produktu v súlade s pravidlami procesu vývoja);
- overenie a prijatie (v zmysle integrity upraveného systému);
- prenos softvéru do iného prostredia (konverzia programov a údajov, paralelná prevádzka softvéru v starom a novom prostredí po určitú dobu);
- vyradenie softvéru z prevádzky rozhodnutím zákazníka za účasti prevádzkujúcej organizácie, podpornej služby a používateľov. V rovnakom čase softvérové produkty a dokumentácia podlieha archivácii v súlade s dohodou.
Životný cyklus softvéru
Jedným zo základných pojmov metodológie návrhu softvéru je koncept jeho životného cyklu softvéru (SO). Životný cyklus softvéru je nepretržitý proces, ktorý sa začína od okamihu rozhodnutia o potrebe jeho vytvorenia a končí okamihom jeho úplného vyradenia z prevádzky.
Hlavné normatívny dokument reguluje životný cyklus softvéru medzinárodný štandard ISO/IEC 12207 (ISO - Medzinárodná organizácia pre normalizáciu - Medzinárodná organizácia o normalizácii, IEC - International Electrotechnical Commission - International Commission on Electrical Engineering). Definuje štruktúru životného cyklu obsahujúcu procesy, činnosti a úlohy, ktoré je potrebné vykonať pri tvorbe softvéru. V tomto štandarde Softvér (softvérový produkt) je definovaný ako súbor počítačových programov, postupov a prípadne súvisiacej dokumentácie a údajov. Proces je definovaný ako súbor vzájomne súvisiacich akcií, ktoré transformujú niektoré vstupné dáta na výstupné dáta. Každý proces je charakterizovaný určitými úlohami a metódami ich riešenia, vstupnými údajmi získanými z iných procesov a výsledkami.
Štruktúra životného cyklu softvéru podľa normy ISO/IEC 12207 je založená na troch skupinách procesov:
· hlavné procesy životného cyklu softvéru (nákup, dodávka, vývoj, prevádzka, podpora);
· pomocné procesy, ktoré zabezpečujú implementáciu hlavných procesov (dokumentácia, konfiguračný manažment, zabezpečenie kvality, overovanie, certifikácia, hodnotenie, audit, riešenie problémov);
· organizačné procesy(projektový manažment, tvorba projektovej infraštruktúry, definovanie, hodnotenie a zlepšovanie samotného životného cyklu, školenia).
Modely životného cyklu softvéru
Model životného cyklu- štruktúra, ktorá určuje postupnosť vykonávania a vzťah fáz a fáz vykonávaných počas celého životného cyklu. Model životného cyklu závisí od špecifík softvéru a špecifických podmienok, v ktorých je vytvorený a funguje. Hlavné modely životného cyklu sú nasledovné.
1. Kaskádový model(do 70. rokov XX. storočia) určuje sekvenčný prechod do ďalšej etapy po dokončení predchádzajúcej.
Tento model sa vyznačuje automatizáciou jednotlivých nesúvisiacich úloh, ktorá nevyžaduje informačnú integráciu a kompatibilitu, softvérové, technické a organizačné rozhranie.
Dôstojnosť: dobré ukazovatele z hľadiska času vývoja a spoľahlivosti pri riešení jednotlivých problémov.
Chyba: Nevzťahuje sa na veľké a zložité projekty kvôli variabilite systémových požiadaviek počas dlhého obdobia návrhu.
2. Iteračný model(70-80-te roky XX storočia) zodpovedá technológii dizajnu „zdola nahor“. Umožňuje opakovaný návrat do predchádzajúcich fáz po dokončení ďalšej fázy;
Model umožňuje zovšeobecnenie získaných konštrukčných riešení jednotlivých problémov na celosystémové riešenia. V tomto prípade je potrebné revidovať predtým formulované požiadavky.
dôstojnosť: schopnosť rýchlo vykonať úpravy projektu.
Chyba: pri veľkom počte iterácií sa zvyšuje čas návrhu, vznikajú nezrovnalosti v konštrukčných riešeniach a dokumentácii a dochádza k zámene funkčnej a systémovej architektúry vytvoreného softvéru. Potreba prerobiť starý alebo vytvoriť nový systém môže nastať ihneď po realizačnej alebo prevádzkovej fáze.
3. Špirálový model(80-90-te roky XX storočia) zodpovedá technológii dizajnu „zhora nadol“. Zahŕňa použitie prototypu softvéru, ktorý umožňuje rozšírenie softvéru. Návrh systému cyklicky opakuje cestu od detailovania požiadaviek k detailnému programovému kódu.
Pri návrhu architektúry systému sa najprv určí zloženie funkčných subsystémov a vyriešia sa celosystémové problémy (organizácia integrovanej databázy, technológia na zber, prenos a ukladanie informácií). Potom sa formulujú jednotlivé problémy a vyvíja sa technológia na ich riešenie.
Pri programovaní sa najskôr vyvinú hlavné softvérové moduly a potom moduly, ktoré vykonávajú jednotlivé funkcie. Najprv je zabezpečená interakcia modulov medzi sebou a s databázou a následne implementácia algoritmov.
Výhody:
1. zníženie počtu opakovaní a následne počtu chýb a nezrovnalostí, ktoré je potrebné opraviť;
2. skrátenie času návrhu;
3. zjednodušenie tvorby projektovej dokumentácie.
Chyba: vysoké nároky na kvalitu celosystémového úložiska ( spoločná základňa konštrukčné údaje).
Základom je špirálový model technológie rýchleho vývoja aplikácií alebo technológia RAD (rýchly vývoj aplikácií), ktorá zahŕňa aktívnu účasť koncových používateľov budúceho systému na procese jeho tvorby. Hlavné fázy informačného inžinierstva sú nasledovné:
· Analýza a plánovanie informačnej stratégie. Používatelia sa spolu so špecializovanými vývojármi podieľajú na identifikácii problémovej oblasti.
· Dizajn. Používatelia sa pod vedením vývojárov podieľajú na technickom návrhu.
· Stavebníctvo. Vývojári navrhujú pracovnú verziu softvéru pomocou jazykov 4. generácie;
· Implementácia. Vývojári školia používateľov na prácu v novom softvérovom prostredí.
Ryža. 5.2.
Ide o tieto aspekty:
- zmluvný aspekt, pri ktorom zákazník a dodávateľ vstupujú do zmluvných vzťahov a realizujú procesy obstarávania a dodávky;
- manažérsky aspekt, ktorý zahŕňa manažérske činnosti osôb podieľajúcich sa na životnom cykle softvéru (dodávateľ, zákazník, vývojár, prevádzkovateľ a pod.);
- prevádzkový aspekt, ktorý zahŕňa činnosti prevádzkovateľa pri poskytovaní služieb používateľom systému;
- inžiniersky aspekt, ktorý obsahuje činnosti vývojára alebo podpornej služby na riešenie technických problémov spojených s vývojom alebo úpravou softvérových produktov;
- aspekt podpory spojený s implementáciou podporných procesov, prostredníctvom ktorých podporné služby poskytujú potrebné služby všetkým ostatným účastníkom diela. V tomto aspekte môžeme vyzdvihnúť aspekt manažérstva kvality softvéru, ktorý zahŕňa procesy zabezpečenia kvality, overovanie, certifikáciu, spoločné hodnotenie a audit.
Organizačné procesy sa realizujú na podnikovej úrovni alebo na úrovni celej organizácie ako celku, čím vytvárajú základ pre implementáciu a neustále zlepšovanie procesov životného cyklu softvéru.
5.6. Modely a fázy životného cyklu softvéru
Model životného cyklu softvéru sa chápe ako štruktúra, ktorá definuje postupnosť vykonávania a vzťahy procesov, akcií a úloh počas životného cyklu softvéru. Model životného cyklu závisí od špecifík, rozsahu a zložitosti projektu a konkrétnych podmienok, v ktorých systém vzniká a funguje.
Norma ISO/IEC 12207 neponúka konkrétny model životného cyklu a metódy vývoja softvéru. Jeho ustanovenia sú všeobecné pre všetky modely životného cyklu, metódy a technológie vývoja softvéru. Norma popisuje štruktúru procesov životného cyklu softvéru, ale nešpecifikuje, ako implementovať alebo vykonávať akcie a úlohy zahrnuté v týchto procesoch.
Model životného cyklu každého konkrétneho softvéru určuje charakter procesu jeho tvorby, čo je súbor prác usporiadaných v čase, vzájomne prepojených a spojených do etáp (fáz), ktorých realizácia je nevyhnutná a postačujúca na vytvorenie softvéru, ktorý spĺňa špecifikované požiadavky.
Etapa (fáza) tvorby softvéru sa chápe ako súčasť procesu tvorby softvéru, ohraničená určitým časovým rámcom a končiaca vydaním konkrétneho produktu (modely softvéru, softvérové komponenty, dokumentácia a pod.), určená požiadavkami špecifikované pre túto etapu. Etapy tvorby softvéru sa rozlišujú z dôvodov racionálneho plánovania a organizácie práce, ktorá končí konkrétnymi výsledkami. Životný cyklus softvéru zvyčajne zahŕňa nasledujúce fázy:
- tvorba softvérových požiadaviek;
- dizajn (vývoj projektu systému);
- implementácia (možno rozdeliť na čiastkové etapy: podrobný návrh, kódovanie);
- testovanie (možno rozdeliť na samostatné a integrované testovanie a integráciu);
- uvedenie do prevádzky (realizácia);
- prevádzka a údržba;
- vyraďovanie z prevádzky.
Niektorí odborníci zavádzajú ďalšiu počiatočnú fázu - analýza uskutočniteľnosti systémov. Máme tu na mysli hardvérový a softvérový systém, pre ktorý sa softvér vytvára, kupuje alebo upravuje.
Etapa formovania softvérových požiadaviek je jednou z najdôležitejších a podstatnou (až rozhodujúcou!) mierou rozhoduje o úspechu celého projektu. Začiatkom tejto etapy je získanie schválenej a overenej architektúry systému vrátane základných zmlúv o rozdelení funkcií medzi hardvér a softvér. Tento dokument musí obsahovať aj potvrdenie všeobecná myšlienka o fungovaní softvéru vrátane základných zmlúv o rozdelení funkcií medzi osobou a systémom.
Fáza generovania softvérových požiadaviek zahŕňa nasledujúce fázy.
- Plánovanie práce pred prácou na projekte. Hlavnými cieľmi etapy je stanovenie rozvojových cieľov, predbežné ekonomické hodnotenie projekt, zostavenie harmonogramu prác, vytvorenie a zaškolenie spoločnej pracovnej skupiny.
- Uskutočnenie prieskumu činnosti automatizovanej organizácie (objektu), v rámci ktorého sa vykoná predbežná identifikácia požiadaviek na budúci systém, určenie štruktúry organizácie, určenie zoznamu cieľových funkcií organizácie, analýza rozdelenia funkcií medzi oddeleniami a zamestnancami, identifikácia funkčných interakcií medzi oddeleniami, informačné toky v rámci oddelení a medzi nimi, objekty mimo organizácie a vonkajšie informačné vplyvy, analýza existujúcich prostriedkov automatizácie činností organizácie.
- model „AS-IS“ („tak ako je“), ktorý odráža aktuálny stav v organizácii v čase prieskumu a umožňuje pochopiť, ako organizácia funguje, ako aj identifikovať úzke miesta a formulovať návrhy na zlepšenie situácia;
- model "TO-BE" ("ako by to malo byť"), odrážajúci myšlienku nových technológií pre organizáciu.
Konštrukcia modelu činnosti organizácie (objektu), ktorá zahŕňa spracovanie prieskumných materiálov a zostavenie dvoch typov modelov:
Každý z modelov by mal obsahovať kompletný funkčný a informačný model činnosti organizácie, ako aj (v prípade potreby) model popisujúci dynamiku správania organizácie. Všimnite si, že zostavené modely sú nezávislé praktický význam bez ohľadu na to, či podnik bude vyvíjať a implementovať informačný systém, pretože s ich pomocou môžete školiť zamestnancov a zlepšovať obchodné procesy podniku.
Výsledkom ukončenia etapy generovania softvérových požiadaviek sú softvérové špecifikácie, funkčné, technické a rozhrania, u ktorých je potvrdená ich úplnosť, overiteľnosť a realizovateľnosť.
Fáza návrhu zahŕňa nasledujúce fázy.
Vývoj projektu softvérového systému. V tejto fáze je daná odpoveď na otázku „Čo treba urobiť“. budúci systém? ", menovite: architektúra systému, jeho funkcie, vonkajšie prevádzkové podmienky, rozhrania a distribúcia funkcií medzi užívateľmi a systémom, požiadavky na softvér a informačné zložky, zloženie účinkujúcich a termíny vývoja, plán ladenia softvéru a kontrola kvality.
Základ projektu systému tvoria modely navrhnutého systému, ktoré sú postavené na modeli „TO-BE“. Výsledkom vypracovania projektu systému musí byť schválená a potvrdená špecifikácia softvérových požiadaviek: funkčné, technické a špecifikácie rozhrania, pri ktorých je potvrdená ich úplnosť, overiteľnosť a realizovateľnosť.
- Vypracovanie podrobného (technického) projektu. V tejto fáze sa realizuje samotný návrh softvéru vrátane návrhu architektúry systému a detailného návrhu. Je teda daná odpoveď na otázku: "Ako postaviť systém tak, aby spĺňal požiadavky?"
Výsledkom detailného návrhu je vývoj overenej softvérovej špecifikácie vrátane:
- vytvorenie hierarchie softvérových komponentov, intermodulárne rozhrania pre dáta a správu;
- špecifikácia každého softvérového komponentu, názov, účel, predpoklady, rozmery, sekvencia volaní, vstupné a výstupné dáta, chyby výstupy, algoritmy a logické obvody;
- formovanie fyzických a logických dátových štruktúr až na úroveň jednotlivých polí;
- vypracovanie plánu distribúcie výpočtových zdrojov (čas centrálneho procesora, pamäť atď.);
- overenie úplnosti, konzistentnosti, realizovateľnosti a platnosti požiadaviek;
- predbežný plán integrácie a ladenia, plán používateľskej príručky a akceptačné testovanie.
Dokončenie fázy podrobného návrhu je od začiatku do konca
Načítava sa...
