Životný cyklus softvéru (Software life cycle). Životný cyklus softvérových systémov Pojem životného cyklu programu a jeho fázy

Téma: Klasické a flexibilné modely LCPP: definícia, popis, charakteristické znaky, postupnosť etáp. Metódy výberu modelu LCPP pri vývoji softvéru pre rôzne tematické oblasti.

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:

1. tvorba softvérových požiadaviek;
2. dizajn (vývoj projektu systému);
3. implementácia (možno rozdeliť na čiastkové etapy: podrobný návrh, kódovanie);
4. testovanie (možno rozdeliť na offline a komplexné testovanie a integrácia);
5. uvedenie do prevádzky (realizácia);
6. Prevádzka a údržba;
7. 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 by mal obsahovať aj potvrdenie o všeobecnom chápaní fungovania 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.

1. 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áce, vytvorenie a zaškolenie spoločnej pracovnej skupiny.
2. 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úce fondy automatizáciu činností organizácie.

Konštrukcia modelu činnosti organizácie (objektu), ktorá zahŕňa spracovanie prieskumných materiálov a zostavenie dvoch typov modelov:

• 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.

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 sa v podniku bude vyvíjať a implementovať informačný systém, pretože s ich pomocou je možné š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.

1. Vývoj projektu softvérového systému. V tejto fáze je daná odpoveď na otázku „Čo by mal robiť budúci systém?“, a to: architektúra systému, jeho funkcie, vonkajšie prevádzkové podmienky, rozhrania a distribúcia funkcií medzi používateľmi a systémom, požiadavky na softvér a informačné zložky, zloženie účinkujúcich a termíny sú určené vývojom, plánom ladenia softvéru a kontrolou 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ť.

2. 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é štruktúryúdaje 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.

Zavŕšením fázy podrobného návrhu je komplexná kontrola projektu alebo kritická analýza projektu blok po bloku.

Realizačná etapa – ukončenie nasledujúcich prác.

1. Vypracovanie overenej podrobnej špecifikácie každého podprogramu (blok nie viac ako 100 počiatočných príkazov jazyka na vysokej úrovni).

   Externé špecifikácie musia obsahovať tieto informácie:

   • názov modulu – označuje názov, ktorý sa používa na volanie modulu (pre modul s viacerými vstupmi musí byť pre každý vstup samostatná špecifikácia);
   • funkcia – je uvedená definícia funkcie alebo funkcií vykonávaných modulom;
   • zoznam parametrov (počet a poradie) odovzdaných modulu;
   • vstupné parametre – presný popis všetkých dát, ktoré modul vracia (musí byť definované správanie modulu za akýchkoľvek vstupných podmienok);
   • vonkajšie efekty (vytlačenie správy, prečítanie požiadavky z terminálu a pod.).
2. Navrhovanie modulovej logiky a programovacích (kódovacích) modulov.
3. Kontrola správnosti modulov.
4. Testovacie moduly.
5. Popis databázy až po úroveň jednotlivých parametrov, znakov a bitov.
6. Plán prijímacích skúšok.
7. Návod na použitie.
8. Predbežný plán integrácie a ladenia. Obsah nasledujúcich etáp sa v podstate zhoduje s príslušnými procesmi životného cyklu softvéru. Vo všeobecnosti sa technologické etapy rozlišujú na základe úvah o rozumnom a racionálnom plánovaní a organizácii práce. Možný vzťah medzi fázami práce a procesmi životného cyklu softvéru je znázornený na obrázku.

Ryža. 1.

Typy modelov životného cyklu softvéru

Model vodopádu (klasický životný cyklus)

Tento model vďačí za svoj vzhľad W. Royceovi (1970). Model má aj iné meno – vodopád. Zvláštnosťou modelu je, že prechod do ďalšej fázy sa uskutoční až po úplnom dokončení práce v predchádzajúcej fáze; Za dokončené etapy sa nevracajú žiadne platby.

Požiadavky na vyvinutý softvér, stanovené vo fázach tvorby a analýzy, sú prísne zdokumentované vo forme technických špecifikácií a zaznamenávajú sa počas celého vývoja projektu. Každá etapa končí vydaním kompletnej dokumentácie (TOR, EP, TP, RP), ktorá je dostatočná na to, aby vo vývoji mohol pokračovať ďalší vývojový tím. Kritériom kvality vývoja pri tomto prístupe je presnosť plnenia technických špecifikácií. Hlavným zameraním vývojárov je dosiahnutie optimálnych hodnôt technické vlastnosti vyvinutý softvér - výkon, množstvo obsadenej pamäte atď.

Výhody kaskádový model:

• v každej fáze sa vygeneruje kompletný súbor projektovej dokumentácie, ktorá spĺňa kritériá úplnosti a konzistentnosti;
• etapy práce vykonávané v logickom slede umožňujú naplánovať načasovanie dokončenia všetkých prác a zodpovedajúce náklady.

Kaskádový prístup sa dobre osvedčil pri konštrukcii softvérových systémov, na ktoré môžu byť všetky požiadavky úplne a jasne formulované už na začiatku projektu. Pokiaľ toto všetko kontrolujú normy a rôzne akceptačné komisie štátu, schéma funguje dobre.

Nedostatky kaskádový model:

• Chyby sa identifikujú a odstraňujú iba v štádiu testovania, čo môže trvať veľa času;
• skutočné projekty často vyžadujú odchýlky od štandardnej postupnosti krokov;
• cyklus je založený na presnej formulácii počiatočných požiadaviek na softvér, v skutočnosti sú na začiatku projektu požiadavky zákazníka stanovené len čiastočne;
• výsledky práce sú zákazníkovi k dispozícii až po dokončení projektu.

Iteračný model životného cyklu PS

S rastom komerčných projektov sa ukázalo, že nie vždy je možné detailne rozpracovať návrh budúceho systému, keďže mnohé aspekty jeho fungovania v dynamických oblastiach činnosti (podnikania) sa pri vytváraní systému menia. Bolo potrebné zmeniť proces vývoja, aby sa zabezpečilo, že potrebné korekcie budú vykonané po dokončení ktorejkoľvek fázy vývoja. Takto sa objavil iteračný model životného cyklu PS, nazývaný model so stredným riadením alebo model s cyklickým opakovaním fáz.

V iteratívnom modeli môžu byť nedostatky dizajnu a programovania odstránené neskôr čiastočným návratom do predchádzajúcej fázy. Čím nižšia je miera detekcie chýb, tým drahšia je oprava. Ak sa náklady na úsilie potrebné na zistenie a odstránenie chýb vo fáze kódovania vezmú ako jedna, potom náklady na identifikáciu a odstránenie chýb vo fáze vývoja požiadaviek budú 5- až 10-krát nižšie a náklady na identifikáciu a odstránenie chýb pri fáza údržby bude 20-krát menšia.

V takejto situácii nadobúda veľký význam fáza formulovania požiadaviek, vypracovania špecifikácií a vytvorenia plánu systému. Za všetky následné zmeny dizajnu sú osobne zodpovední softvéroví architekti. Objem dokumentácie dosahuje tisíce strán a počet schvaľovacích stretnutí je enormný. Mnoho projektov nikdy neopustí fázu plánovania a upadne do „paralýzy analýzy“. Jedným z možných spôsobov eliminácie takýchto situácií je prototypovanie.

Rozloženie

Zákazník často nevie formulovať požiadavky na vstup, spracovanie alebo výstup dát pre budúci softvérový produkt. Vývojár môže pochybovať o vhodnosti produktu pre operačný systém, o forme dialógu s používateľom alebo o účinnosti algoritmu. V takýchto prípadoch je vhodné použiť prototypovanie. Hlavným účelom prototypovania je odstrániť neistotu v požiadavkách zákazníkov. Layout (prototypovanie) je proces vytvárania modelu požadovaného produktu.

Model môže mať nasledujúce formy.

1. Rozloženie papiera (nakreslený diagram dialógu človek-stroj) alebo rozloženie na počítači.
2. Pracovné rozloženie, ktoré implementuje niektoré z požadovaných funkcií.
3. Existujúci program, ktorého výkon je potrebné zlepšiť.

Ako je znázornené na obrázku, prototypovanie je založené na opakovaných iteráciách zahŕňajúcich klienta a vývojára.

Postupnosť akcií počas prototypovania je znázornená na obrázku. Prototypovanie začína zhromaždením a objasnením požiadaviek na vytváraný softvérový systém. Vývojár a zákazník spoločne určujú ciele softvéru, stanovujú, ktoré požiadavky sú známe a ktoré je potrebné ďalej definovať. Potom sa vykoná rýchly návrh. Zameriava sa na vlastnosti, ktoré by mali byť viditeľné pre používateľa. Rýchly dizajn vedie ku konštrukcii rozloženia. Rozloženie posúdi zákazník a použije sa na objasnenie softvérových požiadaviek. Iterácie pokračujú, kým maketa neodhalí všetky požiadavky zákazníka a neumožní dizajnérovi pochopiť, čo je potrebné urobiť.

Výhodou prototypovania je schopnosť zabezpečiť, aby boli určené kompletné systémové požiadavky. Nevýhody rozloženia:

• zákazník si môže pomýliť dizajn s produktom;
• vývojár si môže pomýliť maketu s produktom.

Treba vysvetliť podstatu nedostatkov. Keď zákazník uvidí fungujúcu verziu softvéru, prestane si uvedomovať, že pri hľadaní fungujúcej verzie softvéru zostáva veľa problémov s kvalitou a kvalitou nevyriešených. pohodlie podpory systémov. Keď o tom vývojár povie zákazníkovi, odpoveďou môže byť rozhorčenie a požiadavka rýchlej transformácie rozloženia na funkčný produkt. To má negatívny vplyv na riadenie vývoja softvéru.

Na druhej strane, na rýchle získanie funkčného rozloženia vývojár často robí určité kompromisy. Napríklad programovací jazyk alebo operačný systém nemusia byť najvhodnejšie. Pre jednoduchú demonštráciu možno použiť neefektívny (jednoduchý) algoritmus. Po určitom čase vývojár zabudne na dôvody, prečo tieto nástroje nie sú vhodné. Výsledkom je, že do systému je integrovaná aj zďaleka nie ideálna zvolená možnosť.

Pred zvážením iných modelov životného cyklu softvéru, ktoré boli nahradené kaskádový model, mali by sme sa zamerať na stratégie navrhovania softvérových systémov. Je to stratégia návrhu softvéru, ktorá do značnej miery určuje model životného cyklu softvéru.

Stratégie návrhu softvéru

Existujú tri stratégie navrhovania softvérových systémov:

• jeden priechod (kaskádová stratégia diskutovaná vyššie) – lineárna postupnosť fáz návrhu;
• prírastkovú stratégiu. Na začiatku procesu sú definované všetky užívateľské a systémové požiadavky, zvyšok návrhu prebieha ako postupnosť verzií. Prvá verzia implementuje časť plánovaných funkcií, ďalšia verzia implementuje pridané vlastnosti atď., kým sa nezíska úplný systém;
• evolučnej stratégie. Systém je tiež zostavený ako postupnosť verzií, ale nie všetky požiadavky sú definované na začiatku procesu. Požiadavky sa spresňujú pri vývoji verzií. Charakteristiky stratégií návrhu softvéru v súlade s požiadavkami normy IEEE/EIA 12207 sú uvedené v tabuľke 1.

Prírastkový model

Inkrementálny model je klasickým príkladom inkrementálnej dizajnovej stratégie. Spája prvky sekvenčného modelu vodopádu s iteratívnou filozofiou rozloženia (navrhnutý B. Boehmom ako vylepšenie kaskádový model). Každá lineárna sekvencia tu vytvára dodaný softvérový prírastok. Napríklad softvér na spracovanie textu v 1. prírastku (verzii) implementuje základné funkcie spracovania súborov, editačné a dokumentačné funkcie; v 2. prírastku - zložitejšie možnosti úprav a dokumentácie; v 3. prírastku – kontrola pravopisu a gramatiky; v 4. prírastku – možnosti rozloženia stránky.

Výsledkom prvého prírastku je základný produkt, ktorý implementuje základné požiadavky (hoci mnohé pomocné požiadavky zostávajú neimplementované). Ďalší plán prírastkov zahŕňa úpravu základného produktu, aby poskytoval ďalšie funkcie a funkcie.

Svojou povahou je prírastkový proces iteratívny, ale na rozdiel od prototypovania poskytuje prírastkový model pracovný produkt pri každom prírastku.

Schéma takéhoto modelu životného cyklu softvéru je znázornená na obrázku. Jednou z moderných implementácií inkrementálneho prístupu je extrémne programovanie (zamerané na veľmi malé prírastky funkčnosti).

Špirálový model softvéru životného cyklu

Špirálový model je klasickým príkladom aplikácie evolučnej dizajnovej stratégie. Model (autor B. Boehm, 1988) vychádza z najlepšie vlastnosti klasický životný cyklus a prototypovanie, ku ktorému sa pridáva nový prvok – analýza rizík, ktorá v týchto paradigmách chýba. Model definuje štyri akcie, reprezentované štyrmi kvadrantmi špirály.

1. Plánovanie – definovanie cieľov, možností a obmedzení.
2. Analýza rizika – analýza možností a rozpoznanie/výber rizika.
3. Dizajn – vývoj produktu ďalšej úrovne.
4. Hodnotenie – zákaznícke hodnotenie aktuálnych výsledkov návrhu.

Integračný aspekt špirálový model je zrejmé, ak vezmeme do úvahy radiálny rozmer špirály. S každou iteráciou sa viac a viac stavia do špirály plné verzie PS. V prvom otočení špirály sa stanovia počiatočné ciele, možnosti a obmedzenia, rozpozná sa a analyzuje riziko. Ak analýza rizík ukáže neistotu v požiadavkách, vývojárovi a zákazníkovi pomôže prototypovanie, ktoré sa používa v kvadrante dizajnu.

Simulácia sa môže použiť na ďalšiu identifikáciu problematických a spresnených požiadaviek. Zákazník hodnotí inžiniersku (projektovú) prácu a dáva návrhy na úpravu (kvadrant hodnotenia zákazníka). Ďalšia fáza plánovania a analýzy rizík je založená na návrhoch zákazníka. V každom špirálovom cykle sa výsledky analýzy rizík formujú vo forme „pokračovať, nepokračovať“. Ak je riziko príliš veľké, projekt môže byť zastavený.

Vo väčšine prípadov špirála pokračuje, pričom každý krok posúva vývojárov smerom k všeobecnejšiemu modelu systému. Každý špirálový cyklus vyžaduje dizajn (pravý dolný kvadrant), ktorý je možné realizovať klasickým životným cyklom alebo prototypovaním. Všimnite si, že počet rozvojových aktivít (prebiehajúcich v pravom dolnom kvadrante) sa zvyšuje, keď sa vzďaľujeme od stredu špirály.

Tieto akcie sú očíslované a majú nasledujúci obsah:

1. – zhromažďovanie počiatočných požiadaviek a plánovanie projektu;
2. – rovnaká práca, ale na základe odporúčaní zákazníka;
3. – analýza rizík založená na počiatočných požiadavkách;
4. – analýza rizík na základe reakcie zákazníka;
5. – prechod na integrovaný systém;
6. – počiatočné usporiadanie systému;
7. – ďalšia úroveň rozloženia;
8. – navrhnutý systém;
9. – posúdenie zákazníkom.

Výhody špirálový model:

1. najreálnejšie (vo forme evolúcie) odráža vývoj softvér;
2. umožňuje explicitne brať do úvahy riziko v každom štádiu vývoja vývoja;
3. zahŕňa krok systematický prístup do iteratívnej vývojovej štruktúry;
4. používa simuláciu na zníženie rizika a zlepšenie softvérových produktov.

Nedostatky špirálový model:

• porovnávacia novinka (neexistuje dostatočná štatistika o účinnosti modelu);
• zvýšené požiadavky na zákazníka;
• Ťažkosti s monitorovaním a riadením času vývoja.

Špirálový model procesu vývoja je dnes najbežnejší. Jeho najznámejšie varianty sú RUP (Rational Unified Process) od Rational a MSF (Microsoft Solution Framework). Ako modelovací jazyk sa používa UML (Unified Modeling Language). Predpokladá sa, že vytvorenie systému sa bude vykonávať iteratívne, pohybuje sa v špirále a prechádza rovnakými fázami, pričom na každom kroku objasňuje vlastnosti budúceho produktu. Zdá sa, že teraz je všetko v poriadku: plánuje sa len to, čo sa dá predvídať, vyvíja sa to, čo sa plánuje, a používatelia sa začínajú s produktom oboznamovať vopred, pričom majú možnosť vykonať potrebné úpravy.

To si však vyžaduje veľmi veľké finančné prostriedky. Skutočne, ak predtým bolo možné vytvárať a rozpúšťať skupiny špecialistov podľa potreby, teraz sa na projekte musia neustále zúčastňovať všetci: architekti, programátori, testeri, inštruktori atď. Navyše úsilie rôznych skupín musí byť synchronizované, odrážať včasné rozhodnutia o dizajne a vykonávať potrebné zmeny.

Rational Unified Process

Racionálne jednotný proces(Rational Unified Process, RUP) je jednou z najlepších metodík vývoja softvéru. Na základe skúseností z mnohých úspešných softvérových projektov vám RUP umožňuje vytvárať komplexné softvérové ​​systémy založené na metódach priemyselného vývoja. Pozadie rozvoja RUP sa datuje od začiatku 80. rokov minulého storočia. v spoločnosti Rational Software. Začiatkom roku 2003 Rational získal IBM. Jedným z hlavných pilierov, o ktorý sa RUP opiera, je proces vytvárania modelov pomocou Unified Modeling Language (UML).

RUP je jednou zo špirálových metodík vývoja softvéru. Metodológia je podporovaná a vyvinutá spoločnosťou Rational Software. Ako modelovací jazyk v spoločná základňa znalosti, používa sa Unified Modeling Language (UML). Iteračný a prírastkový vývoj softvéru v RUP zahŕňa rozdelenie projektu na niekoľko projektov, ktoré sa vykonávajú postupne, pričom každá iterácia vývoja je jasne definovaná súborom cieľov, ktoré sa musia dosiahnuť na konci iterácie. Finálna iterácia predpokladá, že množina cieľov iterácie sa musí presne zhodovať so množinou cieľov špecifikovaných zákazníkom produktu, to znamená, že musia byť splnené všetky požiadavky.

Proces zahŕňa vývoj modelov; iterácia vývojového cyklu jednoznačne zodpovedá konkrétnej verzii softvérového modelu. Každá iterácia obsahuje ovládacie prvky životný cyklus softvéru: analýza a návrh (modelovanie), implementácia, integrácia, testovanie, implementácia. V tomto zmysle je RUP implementáciou špirálový model, aj keď pomerne často zobrazovaný vo forme tabuľkového grafu..

Tento obrázok predstavuje dva rozmery: horizontálna os predstavuje čas a ukazuje časové aspekty životného cyklu procesu; vertikálna os predstavuje disciplíny, ktoré definujú fyzickú štruktúru procesu. Môžete vidieť, ako sa dôraz v projekte mení v priebehu času. Napríklad skoré iterácie trávia viac času požiadavkami; v neskorších iteráciách sa viac času venuje implementácii. Horizontálna os je tvorená časovými úsekmi - iteráciami, z ktorých každé je samostatným vývojovým cyklom; Účelom cyklu je priniesť určité vopred určené hmatateľné zlepšenie konečného produktu, ktoré je užitočné z pohľadu zainteresovaných strán.

Na časovej osi je životný cyklus rozdelený do štyroch hlavných fáz.

1. Inception – formovanie konceptu projektu, pochopenie toho, čo tvoríme, pochopenie produktu (vízie), vypracovanie biznis plánu (business case), príprava prototypu programu alebo čiastkového riešenia. Toto je fáza zhromažďovania informácií a analýzy požiadaviek, definovanie obrazu projektu ako celku. Cieľom je získať podporu a financie. V záverečnej iterácii je výsledkom tejto fázy technická špecifikácia.
2. Návrh, vývoj (Spracovanie) - objasnenie plánu, pochopenie toho, ako ho tvoríme, navrhovanie, plánovanie potrebných akcií a zdrojov, detailné rozpracovanie funkcií. Etapa končí vykonateľnou architektúrou, keď sú urobené všetky architektonické rozhodnutia a zohľadnené riziká. Spustiteľná architektúra je spustený softvér, ktorý demonštruje implementáciu základných architektonických rozhodnutí. V konečnej iterácii ide o technický projekt.
3. Implementácia, tvorba systému (konštrukcia) je etapa rozširovania funkčnosti systému, ktorá je súčasťou architektúry. V konečnej iterácii ide o pracovný návrh.
4. Implementácia, nasadenie (Transition). Vytvorenie finálnej verzie produktu. Fáza predstavenia produktu, dodanie produktu konkrétnemu užívateľovi (replikácia, dodávka a školenie).

Vertikálnu os tvoria disciplíny, z ktorých každá môže byť podrobnejšie opísaná z hľadiska vykonávaných úloh, úloh, ktoré sú za ne zodpovedné, produktov, ktoré sa do úloh dodávajú ako vstup a uvoľňujú sa počas ich implementácie atď.

Pozdĺž tejto osi sú kľúčové disciplíny životného cyklu RUP, ktoré sa v ruštine často nazývajú procesy, aj keď to z pohľadu tejto metodológie podporovanej nástrojmi IBM (a/alebo tretích strán) nie je úplne pravda.

1. Podniková analýza a modelovanie (Business modeling) zabezpečuje implementáciu princípov modelovania s cieľom študovať podnikanie organizácie a zhromažďovať poznatky o ňom, optimalizovať obchodné procesy a rozhodovať o ich čiastočnej alebo úplnej automatizácii.
2. Riadenie požiadaviek spočíva v preberaní informácií od zainteresovaných strán a ich prekladaní do súboru požiadaviek, ktoré definujú obsah vyvíjaného systému a podrobne uvádzajú očakávania toho, čo by mal systém robiť.
3. Analýza a návrh zahŕňa postupy na transformáciu požiadaviek na prechodné opisy (modely), ktoré predstavujú, ako by sa tieto požiadavky mali implementovať.
4. Implementácia zahŕňa vývoj kódu, testovanie na úrovni vývojárov a integráciu komponentov, subsystémov a celého systému podľa stanovených špecifikácií.
5. Testovanie sa venuje posudzovaniu kvality vytvoreného produktu.
6. Nasadenie zahŕňa činnosti, ktoré prebiehajú pri dodávaní produktov zákazníkom a sprístupnení produktu koncovým používateľom.
7. Konfiguračný manažment a manažment zmien (Configuration management) sa venuje synchronizácii medziproduktov a finálnych produktov a riadeniu ich vývoja počas projektu a hľadaniu skrytých problémov.
8. Projektový manažment sa venuje plánovaniu projektov, riadeniu rizík, monitorovaniu pokroku a priebežnému vyhodnocovaniu kľúčových ukazovateľov.
9. Environmentálny manažment zahŕňa prvky vytvárania prostredia rozvoja informačného systému a podpory projektových aktivít.

V závislosti od špecifík projektu je možné použiť akékoľvek nástroje od IBM Rational, ako aj od tretích strán. RUP odporúča dodržať šesť postupov na úspešný rozvoj projektu: iteratívny vývoj; riadenie požiadaviek; používanie modulárnych architektúr; vizuálne modelovanie; kontrola kvality; sledovanie zmien.

Neoddeliteľnou súčasťou RUP sú artefakty (artefakt), precedensy (precedent) a role (role). Artefakty sú niektoré z produktov projektu, ktoré sú generované alebo používané v projekte pri práci na konečnom produkte. Precedensy sú postupnosti akcií vykonávaných systémom na získanie pozorovateľného výsledku. V skutočnosti je artefaktom každý výsledok práce jednotlivca alebo skupiny, či už ide o analytický dokument, modelový prvok, súbor kódu, testovací skript, popis chyby atď. Za vytvorenie sú zodpovední určití špecialisti. jedného alebo druhého typu artefaktu. RUP teda jasne definuje zodpovednosti – roly – každého člena vývojového tímu v tej či onej fáze, teda kedy a kto má ten či onen artefakt vytvoriť. Celý proces vývoja softvérového systému je v RUP považovaný za proces vytvárania artefaktov – od dokumentov prvotnej analýzy až po spustiteľné moduly, užívateľské príručky atď.

Na počítačovú podporu procesov RUP vyvinula spoločnosť IBM širokú škálu nástrojov:

• Rational Rose – CASE- vizuálny modelovací nástroj informačné systémy, ktorý má schopnosť generovať prvky kódu. Špeciálna edícia produktu - Rational Rose RealTime - vám umožňuje získať spustiteľný modul ako výstup;
• Rational Requisite Pro je nástroj na správu požiadaviek, ktorý vám umožňuje vytvárať, štruktúrovať, uprednostňovať, sledovať a kontrolovať zmeny požiadaviek, ktoré vznikajú v ktorejkoľvek fáze vývoja komponentov aplikácie;
• Rational ClearQuest je produkt na správu zmien a sledovanie defektov v projekte (sledovanie chýb), ktorý sa úzko integruje s nástrojmi na testovanie a správu požiadaviek a poskytuje jednotné prostredie na vzájomné prepojenie všetkých chýb a dokumentov;
• Rational SoDA je produkt na automatické generovanie projektovej dokumentácie, ktorý umožňuje nastaviť firemný štandard pre vnútropodnikové dokumenty. Je tiež možné uviesť dokumentáciu podľa existujúcich noriem (ISO, CMM);
• Rational Purify, Rational Quantify Rational PureCoverage, – nástroje na testovanie a ladenie;
• Rational Visual Quantify je nástroj na meranie výkonu pre vývojárov aplikácií a komponentov programujúcich v C/C++, Visual Basic a Java; pomáha identifikovať a odstraňovať úzke miesta vo výkone softvéru;
• Rational Visual PureCoverage – automaticky identifikuje oblasti kódu, ktoré sa netestujú;
• Rational ClearCase je produkt na správu konfigurácie softvéru (Rational's Software Configuration Management, SCM), ktorý umožňuje kontrolu verzií všetkých projektových dokumentov. S jeho pomocou môžete udržiavať viacero verzií projektov súčasne a rýchlo medzi nimi prepínať. Rational Requisite Pro podporuje aktualizácie a sledovanie zmeny v požiadavkách na vývojový tím;
• SQA TeamTest - nástroj automatizácia testov;
• Rational TestManager je systém správy testov, ktorý spája všetky nástroje, artefakty, skripty a údaje súvisiace s testovaním;
• Rational Robot - nástroj na vytváranie, úpravu a automatické spúšťanie testov;
• SiteLoad, SiteCheck – nástroje na testovanie webových stránok na výkon a prítomnosť nefunkčných odkazov;
• Rational PerformanceStudio – meria a predpovedá charakteristiky výkonu systému.

Táto sada produktov sa neustále zdokonaľuje a rozširuje. Napríklad najnovší produkt IBM Rational Software Architect (RSA) je súčasťou IBM Software Development Platform, sady nástrojov, ktoré podporujú životný cyklus vývoja softvérových systémov. Produkt IBM Rational Software Architect je určený na vytváranie modelov vyvíjaných softvérových systémov pomocou jednotného modelovacieho jazyka UML 2.0, predovšetkým modelov architektúry vyvíjanej aplikácie. RSA však kombinuje funkcie softvérových produktov ako Rational Application Developer, Rational Web Developer a Rational Software Modeler, čím umožňuje architektom a analytikom vytvárať rôzne pohľady na vyvíjaný informačný systém pomocou jazyka UML 2.0 a vývojárom vykonávať vývoj. J2EE, XML, webové služby atď.

Podľa princípov RUP vám Rational Software Architect umožňuje vytvárať potrebné modely v rámci pracovných postupov disciplín, ako sú:

• obchodné analýzy a modelovanie (obchodné modelovanie);
• riadenie požiadaviek;
• analýza a návrh (Analýza a návrh);
• implementáciu.

Rational Software Architect navyše podporuje vývoj riadený modelom (MDD), ktorý vám umožňuje modelovať softvér pomocou rôzne úrovne abstrakcie s sledovateľnosťou.

MSF (Microsoft Solution Framework)

V roku 1994, v snahe dosiahnuť maximálny dopad z IT projektov, Microsoft vydal súbor smerníc pre efektívny návrh, vývoj, implementáciu a údržbu riešení postavených na základe jeho technológií. Tieto znalosti sú založené na skúsenostiach, ktoré spoločnosť Microsoft získala pri práci na veľkých projektoch vývoja a údržby softvéru, na skúsenostiach konzultantov spoločnosti Microsoft a na tom najlepšom, čo odvetvie IT doteraz nazhromaždilo. To všetko je prezentované vo forme dvoch vzájomne súvisiacich a doplnkových oblastí znalostí: Microsoft Solutions Framework (MSF) a Microsoft Operations Framework (MOF).

Je potrebné poznamenať, že spoločnosť Microsoft vyvinula techniky na aplikované a špecializované použitie založené na všeobecných metódach Lekárov bez hraníc. Okrem toho spoločnosť Microsoft certifikuje odborníkov špeciálne pre aplikované znalosti v používaní MSF (napríklad certifikácia MCTS 74-131 pre odbornosť v technikách projektového riadenia). Predtým, ako sa naučíte metódy Lekárov bez hraníc, musíte najprv určiť, na ktorú aplikáciu Lekárov bez hraníc sa odvolávate.

Najpopulárnejšie možnosti aplikácie Lekárov bez hraníc vyvinuté spoločnosťou Microsoft sú:

• metodika implementácie riešení v oblasti projektového manažmentu;
• Metodológia riadenia IT projektov založená na metodikách MSF a Agile.

Dôležitosť aplikovaných verzií Lekárov bez hraníc zdôrazňuje skutočnosť, že v „čistej verzii“ Microsoft vo svojich IT projektoch nepoužíva samotnú metodiku Lekárov bez hraníc. Projekty Microsoft Consulting Services využívajú hybridnú metodiku MSF a Agile. Napriek vonkajším významným rozdielom v aplikovaných verziách MSF vyvinutých odborníkmi spoločnosti Microsoft, základ metód MSF pre nich zostáva spoločný a odráža všeobecné metodologické prístupy k riadeniu iteratívnych projektov.

MOF je navrhnutý tak, aby organizáciám, ktoré vytvárajú kritické IT riešenia založené na produktoch a technológiách spoločnosti Microsoft, poskytoval technické poradenstvo na dosiahnutie ich spoľahlivosti, dostupnosti, pohodlie podpory(podporovateľnosť) a spravovateľnosť (manažovateľnosť). MF rieši otázky súvisiace s organizáciou personálu a procesov; technológie a riadenie v komplexných, distribuovaných a heterogénnych IT prostrediach. MOF je založené na najlepších výrobných postupoch zhromaždených v knižnici IT infraštruktúry (ITIL), zostavenej Centrálnou počítačovou a telekomunikačnou agentúrou, agentúrou vlády Spojeného kráľovstva.

Vytvorenie podnikového riešenia v rámci prideleného času a rozpočtu si vyžaduje overený metodický rámec. Lekári bez hraníc poskytujú osvedčené metodiky plánovania, navrhovania, vývoja a implementácie úspešných IT riešení. Vďaka svojej flexibilite, škálovateľnosti a nedostatku pevných pokynov môžu Lekári bez hraníc splniť potreby organizácie alebo projektového tímu akejkoľvek veľkosti. Metodológia Lekárov bez hraníc pozostáva z princípov, modelov a disciplín pre riadenie personálu, procesov, technologické prvky a otázky súvisiace so všetkými týmito faktormi, ktoré sú typické pre väčšinu projektov. Lekári bez hraníc pozostávajú z dvoch modelov a troch disciplín. Sú podrobne popísané v 5 whitepaperoch. Je lepšie začať študovať MSF s modelmi (model projektového tímu, procesný model) a potom prejsť na disciplíny (disciplína projektového manažmentu, disciplína riadenia rizík, disciplína manažmentu školenia).

Procesný model MSF predstavuje všeobecnú metodiku vývoja a implementácie IT riešení. Zvláštnosťou tohto modelu je, že vďaka svojej flexibilite a absencii striktne stanovených postupov je možné ho použiť pri vývoji veľmi širokého spektra IT projektov. Tento model kombinuje vlastnosti dvoch štandardných výrobných modelov: vodopád a špirála. Procesný model v MSF 3.0 bol pridaný k ďalšiemu inovatívnemu aspektu: pokrýva celý životný cyklus vytvárania riešenia, od jeho počiatočného bodu až po implementáciu. Tento prístup pomáha projektovým tímom zamerať sa na obchodnú hodnotu riešenia, pretože táto návratnosť sa stáva reálnou až po dokončení implementácie a začatí používania produktu.

Proces Lekárov bez hraníc je zameraný na „míľniky“ – kľúčové body projektu, ktoré charakterizujú dosiahnutie akéhokoľvek významného (priebežného alebo konečného) výsledku v jeho rámci. Tento výsledok je možné posúdiť a analyzovať, čo znamená odpovede na otázky: „Dospel projektový tím k jasnému pochopeniu cieľov a rozsahu projektu?“, „Je akčný plán dostatočne pripravený?“, „Je produkt spĺňa schválenú špecifikáciu?“, „Spĺňa riešenie potreby zákazníka?“ atď.

Procesný model Lekárov bez hraníc zohľadňuje neustále zmeny požiadaviek projektu. Predpokladá, že vývoj riešenia by mal pozostávať z krátkych cyklov, ktoré vytvárajú progresívny pohyb od najjednoduchších verzií riešenia až po jeho finálnu podobu.

Procesný model Lekárov bez hraníc má tieto vlastnosti:

• fázový a míľnikový prístup;
• iteračný prístup;
• integrovaný prístup k tvorbe a implementácii riešení.

Procesný model zahŕňa tieto hlavné fázy vývojového procesu:

• vývoj koncepcií (predstavovanie);
• plánovanie (Plánovanie);
• rozvoj;
• stabilizácia;
• implementácia (Deploying).

Okrem toho existuje veľké množstvo prechodných míľnikov, ktoré ukazujú dosiahnutie určitého pokroku počas projektu a rozkladajú veľké segmenty práce na menšie, pozorovateľné oblasti. Pre každú fázu procesného modelu MSF definuje:

• čo (ktoré artefakty) je výsledkom tejto fázy;
• na čom každý klaster rolí v tejto fáze pracuje.

V rámci MSF sa kód, dokumentácia, návrhy, plány a iné pracovné materiály vytvárajú spravidla iteračnými metódami. Lekári bez hraníc odporúčajú, aby ste začali s vývojom riešenia vytvorením, testovaním a implementáciou jeho základných funkcií. Potom sa do riešenia pridávajú ďalšie a ďalšie nové funkcie. Táto stratégia sa nazýva stratégia tvorby verzií. Hoci vydanie jednej verzie môže byť postačujúce pre malé projekty, odporúča sa, aby ste nepremeškali príležitosť vytvoriť viacero verzií jedného riešenia. S vytváraním nových verzií sa vyvíja funkcionalita riešenia.

Iteratívny prístup k vývojovému procesu si vyžaduje použitie flexibilného spôsobu udržiavania dokumentácie. Živé dokumenty sa musia meniť tak, ako sa vyvíja projekt a menia sa požiadavky na konečný produkt. Lekári bez hraníc ponúkajú množstvo štandardných šablón dokumentov, ktoré sú artefaktmi každej fázy vývoja produktu a možno ich použiť na plánovanie a riadenie procesu vývoja.

Riešenie nemá žiadnu obchodnú hodnotu, kým nie je implementované. Práve z tohto dôvodu obsahuje procesný model MSF celý životný cyklus tvorby riešenia vrátane jeho implementácie – až do momentu, kedy riešenie začne prinášať hodnotu.

Mali by sme začať definovanímŽivotný cyklus softvér(Software Life Cycle Model) je časový úsek, ktorý začína okamihom rozhodnutia o vytvorení softvérového produktu a končí okamihom jeho úplného vyradenia z prevádzky. Tento cyklus je proces budovania a vývoja softvéru.

Modely životného cyklu softvéru

Životný cyklus možno znázorniť vo forme modelov. V súčasnosti sú najbežnejšie:kaskáda, prírastkové (stupňovitý model so stredným riadením ) A špirálamodely životného cyklu.

Kaskádový model

Kaskádový model(Angličtina) model vodopádu) je model procesu vývoja softvéru, ktorého životný cyklus vyzerá ako tok, ktorý postupne prechádza fázami analýzy a návrhu požiadaviek. implementácia, testovanie, integrácia a podpora.

Proces vývoja sa realizuje prostredníctvom usporiadanej postupnosti nezávislých krokov. Model predpokladá, že každý nasledujúci krok začína po úplnom dokončení predchádzajúceho kroku. Vo všetkých krokoch modelu sa vykonávajú pomocné a organizačné procesy a práce, vrátane projektového riadenia, hodnotenia a riadenia kvality, overovania a certifikácie, riadenia konfigurácií a tvorby dokumentácie. V dôsledku dokončenia krokov sa vytvárajú medziprodukty, ktoré sa v nasledujúcich krokoch nedajú meniť.

Životný cyklus sa tradične delí na nasledujúce hlavnéetapy:

1. Analýza požiadaviek,
2. dizajn,
3. kódovanie (programovanie),
4. Testovanie a ladenie,
5. Prevádzka a údržba.

Výhody modelu:

• stabilita požiadaviek počas celého životného cyklu vývoja;
• v každej fáze sa vygeneruje kompletný súbor projektovej dokumentácie, ktorá spĺňa kritériá úplnosti a konzistentnosti;
• istota a jasnosť krokov modelu a jednoduchosť jeho aplikácie;
• etapy práce vykonávané v logickom slede umožňujú plánovať načasovanie dokončenia všetkých prác a zodpovedajúcich zdrojov (peňažných, materiálnych a ľudských).

Nevýhody modelu:

• ťažkosti s jasnou formuláciou požiadaviek a nemožnosť ich dynamickej zmeny počas celého životného cyklu;
• nízka flexibilita v riadení projektov;
• podsekvencia lineárna štruktúra vývojový proces, v dôsledku toho návrat k predchádzajúcim krokom k riešeniu vznikajúcich problémov vedie k zvýšeným nákladom a narušeniu pracovného harmonogramu;
• nevhodnosť medziproduktu na použitie;
• nemožnosť flexibilného modelovania jedinečných systémov;
• Neskoré odhalenie problémov s montážou v dôsledku súčasnej integrácie všetkých výsledkov na konci vývoja;
• nedostatočná účasť používateľov na tvorbe systému - na samom začiatku (pri vývoji požiadaviek) a na konci (pri akceptačných testoch);
• používatelia si nemôžu byť istí kvalitou vyvíjaného produktu, kým sa nedokončí celý vývojový proces. Nemajú možnosť posúdiť kvalitu, pretože nie je možné vidieť hotový vývojový produkt;
• užívateľ nemá možnosť postupne si zvyknúť na systém. Proces učenia sa nastáva na konci životného cyklu, keď už bol softvér uvedený do prevádzky;
• každá fáza je predpokladom pre následné činnosti, čo robí túto metódu riskantnou voľbou pre systémy, ktoré nemajú analógy, pretože nie je vhodný na flexibilné modelovanie.

Implementácia kaskádového modelu životného cyklu je náročná z dôvodu zložitosti vývoja softvérového systému bez návratu k predchádzajúcim krokom a zmeny ich výsledkov, aby sa eliminovali vznikajúce problémy.

Rozsah použitia kaskádového modelu

Obmedzenie rozsahu aplikácie kaskádového modelu je určené jeho nedostatkami. Jeho použitie je najúčinnejšie v nasledujúcich prípadoch:

1. pri vývoji projektov s jasným, nemennýmživotný cyklus požiadavky, zrozumiteľná implementácia a technické metódy;
2. pri vývoji projektu zameraného na vybudovanie systému alebo produktu rovnakého typu, ktorý už predtým vývojári vyvinuli;
3. pri vývoji projektu súvisiaceho s vytvorením a vydaním novej verzie existujúceho produktu alebo systému;
4. pri vývoji projektu súvisiaceho s prevodom existujúceho produktu alebo systému na novú platformu;
5. pri realizácii veľkých projektov, na ktorých sa podieľa niekoľko veľkých vývojových tímov.

Prírastkový model

(model krok za krokom so stredným ovládaním)

Prírastkový model(Angličtina) prírastok- zvýšenie, prírastok) znamená vývoj softvéru s lineárnou postupnosťou etáp, ale v niekoľkých prírastkoch (verziách), t.j. s plánovanými vylepšeniami produktu po celú dobu, kým sa neskončí životný cyklus vývoja softvéru.

Vývoj softvéru prebieha v iteráciách so spätnou väzbou medzi jednotlivými fázami. Medzietapové úpravy umožňujú zohľadniť skutočné vzájomné ovplyvňovanie výsledkov vývoja v rôznych etapách, pričom životnosť každej etapy sa predlžuje na celú dobu vývojové obdobie.

Na začiatku práce na projekte sa určia všetky základné požiadavky na systém a rozdelia sa na viac a menej dôležité. Systém sa potom vyvíja postupne, aby vývojár mohol využiť údaje získané pri vývoji softvéru. Každý prírastok by mal do systému pridať určitú funkčnosť. V tomto prípade sa vydanie začína komponentmi s najvyššou prioritou. Keď sú časti systému identifikované, vezmite si prvú časť a začnite ju podrobne popisovať pomocou najvhodnejšieho postupu. Zároveň je možné objasniť požiadavky na ďalšie časti, ktoré boli zmrazené v aktuálnom súbore požiadaviek na túto prácu. V prípade potreby sa k tejto časti môžete vrátiť neskôr. Ak je diel hotový, je doručený klientovi, ktorý ho môže použiť pri svojej práci. To umožní zákazníkovi objasniť požiadavky na nasledujúce komponenty. Potom vyvinú ďalšiu časť systému. Kľúčovými krokmi v tomto procese je jednoduchá implementácia podmnožiny softvérových požiadaviek a zdokonaľovanie modelu v rámci série po sebe nasledujúcich vydaní, až kým nebude softvér úplne implementovaný.

Životný cyklus tohto modelu je typický pri vývoji zložitých a komplexných systémov, pri ktorých existuje jasná vízia (ako na strane zákazníka, tak aj na strane vývojára), aký by mal byť konečný výsledok. Vývoj verzie sa vykonáva z rôznych dôvodov:

• neschopnosť zákazníka financovať celý nákladný projekt naraz;
• developerovi chýbajú potrebné zdroje na realizáciu zložitého projektu v krátkom čase;
• požiadavky na fázovú implementáciu a prijatie produktu koncovými užívateľmi. Implementácia celého systému naraz môže spôsobiť odmietnutie medzi jeho používateľmi a iba „spomaliť“ proces prechodu na nové technológie. Obrazne povedané, možno jednoducho „nestrávia veľký kus, takže ho treba nasekať a dať po častiach“.

Výhody A nedostatkyTento model (stratégie) sú rovnaké ako pri vodopáde (klasický model životného cyklu). Ale na rozdiel od klasickej stratégie môže zákazník vidieť výsledky skôr. Na základe výsledkov vývoja a implementácie prvej verzie môže mierne zmeniť požiadavky na vývoj, upustiť od neho, prípadne ponúknuť vývoj pokročilejšieho produktu s uzavretím novej zmluvy.

Výhody:

• náklady vzniknuté v dôsledku zmien v požiadavkách používateľov sa znížia, opätovná analýza a množstvo dokumentácie je výrazne znížené v porovnaní s vodopádovým modelom;
• Je jednoduchšie získať spätnú väzbu od klienta o vykonanej práci - klienti môžu vyjadriť svoje pripomienky k hotovým dielom a môžu vidieť, čo sa už urobilo. Pretože Prvé časti systému sú prototypom systému ako celku.
• klient má možnosť rýchlo získať a osvojiť si softvér – klienti môžu realizovať skutočné výhody zo systému skôr, ako by to bolo možné pri vodopádovom modeli.

Nevýhody modelu:

• manažéri musia neustále merať pokrok v procese. v prípade rýchleho vývoja by ste nemali vytvárať dokumenty pre každú minimálnu zmenu verzie;
• štruktúra systému má tendenciu zhoršovať sa pri pridávaní nových komponentov – neustále zmeny narúšajú štruktúru systému. Aby sa tomu zabránilo, refaktoring si vyžaduje dodatočný čas a peniaze. Zlý dizajn spôsobuje, že neskoršia zmena softvéru je obtiažna a nákladná. A prerušený životný cyklus softvéru vedie k ešte väčším stratám.

Schéma vám neumožňuje rýchlo zohľadniť vznikajúce zmeny a objasnenia softvérových požiadaviek. Koordinácia výsledkov vývoja s používateľmi sa vykonáva iba v bodoch plánovaných po ukončení každej etapy práce a Všeobecné požiadavky k softvéru sa zaznamenávajú vo forme technických špecifikácií po celú dobu jeho tvorby. Používatelia tak často dostávajú softvér, ktorý nezodpovedá ich skutočným potrebám.

Špirálový model

Špirálový model:Životný cyklus - pri každom otočení špirály sa vytvorí ďalšia verzia produktu, vyjasnia sa požiadavky projektu, určí sa jeho kvalita a naplánuje sa práca ďalšieho otočenia. Osobitná pozornosť sa venuje počiatočným fázam vývoja - analýze a návrhu, kde sa testuje a zdôvodňuje realizovateľnosť určitých technických riešení prostredníctvom vytvárania prototypov.

Tento model je proces vývoja softvéru, ktorý kombinuje dizajn a prírastkové prototypovanie s cieľom spojiť výhody konceptov zdola nahor a zhora nadol, pričom kladie dôraz na skoré štádiá životného cyklu: analýzu a návrh.Výrazná vlastnosť Tento model venuje osobitnú pozornosť rizikám ovplyvňujúcim organizáciu životného cyklu.

Vo fáze analýzy a návrhu sa vytváraním prototypov overuje realizovateľnosť technických riešení a miera uspokojenia potrieb zákazníkov. Každé otočenie špirály zodpovedá vytvoreniu funkčného fragmentu alebo verzie systému. To vám umožní objasniť požiadavky, ciele a charakteristiky projektu, určiť kvalitu vývoja a naplánovať prácu ďalšieho otočenia špirály. Týmto spôsobom sa prehĺbia a dôsledne špecifikujú detaily projektu a vo výsledku sa vyberie rozumná možnosť, ktorá uspokojí skutočné požiadavky zákazníka a privedie sa k realizácii.

Životný cyklus na každom otočení špirály - možno použiť rôzne modely proces vývoja softvéru. V konečnom dôsledku je výstupom hotový výrobok. Model kombinuje schopnosti prototypového modelu amodel vodopádu. Vývoj po iteráciách odráža objektívne existujúci špirálovitý cyklus vytvárania systému. Neúplné dokončenie práce v každej fáze vám umožňuje prejsť do ďalšej fázy bez toho, aby ste čakali na úplné dokončenie práce v súčasnej. Hlavnou úlohou je čo najrýchlejšie ukázať používateľom systému fungujúci produkt, čím sa aktivuje proces upresňovania a dopĺňania požiadaviek.

Výhody modelu:

• umožňuje rýchlo ukázať používateľom systému funkčný produkt, čím sa aktivuje proces objasňovania a dopĺňania požiadaviek;
• umožňuje zmeny požiadaviek počas vývoja softvéru, čo je typické pre väčšinu vývojov vrátane štandardných;
• model umožňuje flexibilný dizajn, pretože stelesňuje výhody vodopádového modelu a zároveň umožňuje iterácie vo všetkých fázach toho istého modelu;
• umožňuje získať spoľahlivejší a stabilnejší systém. Ako sa softvér vyvíja, pri každej iterácii sa objavujú a opravujú chyby a slabé stránky;
• tento model umožňuje používateľom aktívne sa podieľať na plánovaní, analýze rizík, návrhu a hodnotení;
• riziká zákazníkov sú znížené. Zákazník môže dokončiť vývoj neperspektívneho projektu s minimálnymi finančnými stratami;
• Spätná väzba od používateľov k vývojárom sa vyskytuje s vysokou frekvenciou a na začiatku modelu, čo zaisťuje vytvorenie požadovaného produktu vysokej kvality.

Nevýhody modelu:

• ak je projekt nízkorizikový alebo má malú veľkosť, model môže byť drahý. Hodnotenie rizika po každej špirále je spojené s vysokými nákladmi;
• Životný cyklus modelu má zložitú štruktúru, takže jeho použitie vývojármi, manažérmi a zákazníkmi môže byť zložité;
• špirála môže pokračovať donekonečna, keďže každá reakcia zákazníka na vytvorenú verziu môže generovať nový cyklus, ktorý odďaľuje koniec projektu;
• veľký počet medzicyklov môže viesť k potrebe spracovania dodatočnej dokumentácie;
• použitie modelu sa môže ukázať ako drahé a dokonca nedostupné, pretože čas. čas strávený plánovaním, predefinovaním cieľov, vykonávaním analýz rizík a vytváraním prototypov môže byť nadmerný;
• Môže byť ťažké definovať ciele a míľniky, ktoré naznačujú pripravenosť pokračovať v procese rozvoja do ďalšej a

Hlavným problémom špirálového cyklu je určenie momentu prechodu do ďalšej fázy. Na vyriešenie tohto problému sú pre každú fázu zavedené časové obmedzenia.životný cyklus a prechod prebieha podľa plánu, aj keď nie sú dokončené všetky plánované práce.Plánovanievytvorených na základe štatistických údajov získaných v predchádzajúcich projektoch a osobná skúsenosť vývojárov.

Rozsah použitia špirálového modelu

Použitie špirálového modelu sa odporúča v nasledujúcich prípadoch:

• pri vývoji projektov využívajúcich nové technológie;
• pri vývoji novej série produktov alebo systémov;
• pri vývoji projektov s očakávaným významné zmeny alebo dodatky k požiadavkám;
• realizovať dlhodobé projekty;
• pri vývoji projektov, ktoré si vyžadujú preukázanie kvality a verzií systému alebo produktu v krátkom časovom období;
• pri vývoji projektov. na ktoré je potrebné kalkulovať náklady spojené s posudzovaním a riešením rizík.

Štandardy životného cyklu softvéru

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

Norma GOST 34 .601-90

Iteračný model

Alternatívou k sekvenčnému modelu je takzvaný iteračný a prírastkový model vývoja. iteračný a prírastkový vývoj, IID ), ktorý dostal aj od T. Gilba v 70. rokoch. názov evolučný model. Tento model je tiež tzv iteračný model A prírastkový model .

Model IID zahŕňa rozdelenie životného cyklu projektu na postupnosť opakovaní, z ktorých každá pripomína „miniprojekt“, vrátane všetkých vývojových procesov použitých na vytvorenie menších častí funkcionality v porovnaní s projektom ako celkom. Účel každého iterácií- získanie pracovnej verzie softvérového systému vrátane funkcionality definovanej integrovaným obsahom všetkých predchádzajúcich a aktuálnych iterácií. Výsledok finálnej iterácie obsahuje všetky požadované funkcie produktu. Po dokončení každej iterácie teda produkt dostane prírastok - prírastok- svojim schopnostiam, ktoré sa následne rozvíjajú evolučne. Iteratívnosť, inkrementálnosť a evolúcia sú v tomto prípade vyjadrením rovnakého významu v rôznych slovách z mierne odlišných uhlov pohľadu.

Ako hovorí T. Gilb, „evolúcia je technika navrhnutá na vytvorenie zdania stability. Šance úspešného tvorenia komplexného systému sa maximalizuje, ak sa implementuje v sérii malých krokov a ak každý krok obsahuje jasne definovaný úspech, ako aj možnosť „vrátiť sa“ do predchádzajúcej úspešnej fázy v prípade zlyhania. Pred uvedením všetkých zdrojov určených na vytvorenie systému do činnosti má vývojár možnosť získať spätnú väzbu z reálneho sveta a opraviť možné chyby v projekte“.

Prístup IID má tiež svoje negatívne stránky, ktorá v podstate - zadná strana výhod. Po prvé, holistické pochopenie schopností a obmedzení projektu veľmi dlho chýbalo. Po druhé, pri opakovaní musíte vypustiť časť práce vykonanej predtým. Po tretie, svedomitosť odborníkov pri výkone práce stále klesá, čo je psychologicky vysvetliteľné, pretože u nich neustále prevláda pocit, že „všetko sa dá aj tak prerobiť a vylepšiť neskôr“.

Rôzne varianty iteračného prístupu sú implementované vo väčšine moderných vývojových metodík (RUP, MSF,).

Špirálový model

Každá iterácia zodpovedá vytvoreniu fragmentu alebo verzie softvéru, pri ktorej sa vyjasnia ciele a charakteristiky projektu, posúdi sa kvalita získaných výsledkov a naplá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.

Je dôležité pochopiť, že špirálový model nie je alternatívou k evolučnému modelu (model IID), ale špeciálne vyvinutou verziou. Bohužiaľ, špirálový model sa často buď mylne používa ako synonymum pre evolučný model vo všeobecnosti, alebo sa (nemenej chybne) označuje ako úplne nezávislý model spolu s IID.

Charakteristickým rysom špirálového modelu je osobitná pozornosť venovaná rizikám ovplyvňujúcim organizáciu životného cyklu a kontrolných bodov. Boehm formuluje 10 najbežnejších (podľa priority) rizík:

1. Nedostatok špecialistov.
2. Nereálne termíny a rozpočet.
3. Implementácia nevhodnej funkcionality.
4. Navrhovanie nesprávneho používateľského rozhrania.
5. Perfekcionizmus, zbytočná optimalizácia a pilovanie detailov.
6. Neustály prúd zmien.
7. Nedostatok informácií o externých komponentoch, ktoré definujú prostredie systému alebo sa podieľajú na integrácii.
8. Nevýhody v práci vykonávanej externými (vo vzťahu k projektu) zdrojmi.
9. Nedostatočný výkon výsledného systému.
10. Medzera v kvalifikácii odborníkov v rôznych oblastiach.

Dnešný špirálový model definuje nasledujúcu všeobecnú množinu kontrolných bodov:

1. Concept of Operations (COO) - koncepcia (použitie) systému;
2. Ciele životného cyklu (LCO) - ciele a obsah životného cyklu;
3. Life Cycle Architecture (LCA) - architektúra životného cyklu; tu možno hovoriť o pripravenosti koncepčnej architektúry cieľového softvérového systému;
4. Počiatočná prevádzková spôsobilosť (IOC) - prvá vytvorená verzia produktu vhodná na skúšobnú prevádzku;
5. Final Operational Capability (FOC) je hotový produkt, nasadený (nainštalovaný a nakonfigurovaný) pre reálnu prevádzku.

Metodiky vývoja softvéru

• Microsoft Solutions Framework (MSF). Zahŕňa 4 fázy: analýza, návrh, vývoj, stabilizácia, zahŕňa použitie objektovo orientovaného modelovania.
• Extrémne programovanie Extrémne programovanie, XP). Metodika je založená na tímovej práci, efektívna komunikácia medzi zákazníkom a dodávateľom počas celého projektu vývoja IP. Vývoj prebieha pomocou postupne zdokonaľovaných prototypov.
• ESPD - komplex štátne normy Ruská federácia, ktorým sa ustanovujú vzájomne súvisiace pravidlá pre tvorbu, dizajn a obeh programov a programovej dokumentácie.

Literatúra

• Bratiščenko V.V. Návrh informačných systémov. - Irkutsk: Vydavateľstvo BGUEP, 2004. - 84 s.
• Vendrov A.M. Návrh softvéru pre ekonomické informačné systémy. - M.: Financie a štatistika, 2000.
• Grekul V.I., Denishchenko G.N., Korovkina N.L. Návrh informačných systémov. - M.: Internetová univerzita informačných technológií- INTUIT.ru, 2005.
• Mišenin A.I. Teória ekonomických informačných systémov. - M.: Financie a štatistika, 2000. - 240 s.

Poznámky

Nadácia Wikimedia. 2010.

Životný cyklus softvéru je časový úsek, ktorý začína okamihom prijatia rozhodnutia o potrebe vytvorenia softvérového produktu a končí okamihom jeho úplného vyradenia z prevádzky.

Procesy životného cyklu softvéru:

základné,

pomocný,

Organizačné.

Základné:

1. Akvizícia – úkony a úlohy zákazníka nakupujúceho softvér;

2. Dodávka – úkony a úlohy dodávateľa, ktorý dodáva zákazníkovi softvérový produkt alebo službu;

3. Vývoj - úkony a úlohy vykonávané vývojárom: tvorba softvéru, projektová a prevádzková dokumentácia, príprava testovacej a vzdelávacie materiály;

4. Prevádzka – činnosti a úlohy prevádzkovateľa organizácie prevádzkujúcej systém;

5. Údržba – vykonávanie zmien v softvéri s cieľom opraviť chyby, zvýšiť produktivitu alebo prispôsobiť zmeneným prevádzkovým podmienkam alebo požiadavkám.

Pomocný:

1. Dokumentácia – formalizovaný popis informácií vytvorených počas životného cyklu softvéru;

2. Konfiguračný manažment – ​​používanie administratívnych a technických postupov počas celého životného cyklu softvéru na zisťovanie stavu softvérových komponentov a riadenie jeho modifikácií;

3. Zabezpečenie kvality – zabezpečenie toho, aby softvér a procesy jeho životného cyklu spĺňali špecifikované požiadavky a schválené plány;

4. Overovanie – určenie čoho softvérové ​​produkty plne spĺňať požiadavky alebo podmienky určené predchádzajúcimi opatreniami;

5. Certifikácia – zisťovanie úplnosti zhody špecifikovaných požiadaviek a vytvoreného systému s ich konkrétnym funkčným účelom;

6. Spoločné hodnotenie – hodnotenie stavu prác na projekte: kontrola plánovania a riadenia zdrojov, personálu, vybavenia, nástrojov;

7. Audit – zisťovanie súladu s požiadavkami, plánmi a podmienkami zmluvy;

8. Riešenie problémov – analýza a riešenie problémov, bez ohľadu na ich pôvod alebo zdroj, ktoré sa objavia počas vývoja, prevádzky, údržby alebo iných procesov.

organizačné:

1. Kontrola – činnosti a úlohy, ktoré môže vykonávať ktorákoľvek strana riadiaca jej procesy;

2. Tvorba infraštruktúry – výber a údržba technológie, štandardov a nástrojov, výber a inštalácia hardvéru a softvér používané na vývoj, prevádzku alebo údržbu softvéru;

3. Zlepšenie – hodnotenie, meranie, kontrola a zlepšovanie procesov životného cyklu;

4. Školenie – úvodné školenie a následný sústavný odborný rozvoj personálu.

V roku 2002 bola zverejnená norma pre procesy životného cyklu systému (ISO/IEC 15288 Procesy životného cyklu systému). Na vývoji normy sa podieľali špecialisti z rôznych oblastí: systémové inžinierstvo, programovanie, manažérstvo kvality, ľudskými zdrojmi, bezpečnosť a pod. Zohľadnili sa praktické skúsenosti s vytváraním systémov vo vládnych, komerčných, vojenských a akademických organizáciách. Norma je použiteľná pre širokú triedu systémov, ale jej hlavným účelom je podporovať vytváranie počítačových systémov.

Podľa normy radu ISO/IEC 15288 by štruktúra životného cyklu mala zahŕňať nasledujúce skupiny procesy:

1. Zmluvné procesy:

Akvizícia (interné alebo externé riešenia dodávateľa);

Dodávka (interné riešenia alebo riešenia externých dodávateľov);

2. Podnikové procesy:

Podnikový environmentálny manažment;

Investičný manažment;

riadenie životného cyklu IS;

Riadenie zdrojov;

Kontrola kvality;

3. Projektové procesy:

Plánovanie projektu;

Hodnotenie projektov;

Projektová kontrola;

Riadenie rizík;

Konfiguračný manažment;

Riadenie toku informácií;

Robiť rozhodnutia.

4. Technické procesy:

Definícia požiadaviek;

Analýza požiadaviek;

Vývoj architektúry;

Implementácia;

integrácia;

Overovanie;

Prechod;

certifikácia;

Vykorisťovanie;

eskort;

Dispozícia.

5. Špeciálne procesy:

Identifikácia a nadviazanie vzťahov na základe úloh a cieľov.

Tvorba základných procesov životného cyklu pre softvér IP (ISO/IEC 15288)

Etapy vývoja systému (ISO/IEC 15288)

SRS: Vytvorte technické špecifikácie pre projekt „Queue“ na webovej stránke www.mastertz.ru

Modely životného cyklu softvéru:

1. kaskáda,

2. špirála,

3. iteratívny.

Kaskádový modelživotný cyklus („model vodopádu“, anglický model vodopádu) navrhol v roku 1970 Winston Royce. 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.

Špirálový model(anglický špirálový model) bol vyvinutý v polovici 80. rokov 20. storočia Barrym Boehmom. Je založený na klasickom cykle PDCA (plan-do-check-act) Williamsa Edwarda Deminga. Pri použití tohto modelu sa softvér vytvára v niekoľkých iteráciách (špirálových otáčkach) metódou prototypovania.

Prototyp je funkčný softvérový komponent, ktorý implementuje jednotlivé funkcie a externé rozhrania.

Každá iterácia zodpovedá vytvoreniu fragmentu alebo verzie softvéru, pri ktorej sa vyjasnia ciele a charakteristiky projektu, posúdi sa kvalita získaných výsledkov a naplánuje sa práca ďalšej iterácie.

Ryža. 21. Špirálový model životného cyklu softvéru

Pri každej iterácii sa vyhodnocujú:

1. Riziko prekročenia termínov projektu a nákladov;

2. Potreba vykonať ďalšiu iteráciu;

3. Stupeň úplnosti a presnosti pochopenia systémových požiadaviek;

4. Uskutočniteľnosť ukončenia projektu.

Jedným príkladom implementácie špirálového modelu je RAD.

Základné princípy RAD:

1. Súbor nástrojov by mal byť zameraný na minimalizáciu času vývoja;

2. Vytvorenie prototypu na objasnenie požiadaviek zákazníka;

3. Vývojový cyklus: každá nová verzia produktu je založená na zákazníckom hodnotení výsledkov predchádzajúcej verzie;

4. Minimalizácia času vývoja verzie prenesením hotových modulov a pridaním funkcií do Nová verzia;

5. Vývojový tím by mal úzko spolupracovať, každý člen by mal byť ochotný vykonávať viacero zodpovedností;

6. Projektový manažment by mal minimalizovať čas vývojového cyklu.

Iteračný model: Prirodzený vývoj kaskádových a špirálových modelov viedol k ich zbližovaniu a vzniku moderného iteračného prístupu, ktorý predstavuje racionálnu kombináciu týchto modelov.

Ryža. 22. Iteračný model životného cyklu softvéru

Životný cyklus softvéru. Etapy a míľniky

Životný cyklus IS je séria udalostí, ktoré sa vyskytujú v systéme počas procesu jeho tvorby a používania.

Etapa- časť procesu tvorby softvéru, ohraničená určitým časovým rámcom a končiaca vydaním konkrétneho produktu (modely, softvérové ​​komponenty, dokumentácia), určená požiadavkami špecifikovanými pre túto etapu.

Životný cyklus sa tradične modeluje ako určitý počet po sebe nasledujúcich štádií (alebo štádií, fáz). V súčasnosti neexistuje všeobecne akceptované rozdelenie životného cyklu softvérového systému na etapy. Niekedy je etapa zvýraznená ako samostatný bod, niekedy je zahrnutá ako integrálna súčasť väčšej etapy. Akcie vykonané v jednej alebo druhej fáze sa môžu líšiť. V názvoch týchto etáp nie je jednotnosť.

Tradične sa rozlišujú tieto hlavné fázy životného cyklu softvéru:

Analýza požiadaviek,

dizajn,

kódovanie (programovanie),

Testovanie a ladenie,

Prevádzka a údržba.

Životný cyklus softvéru. Kaskádový model

kaskádový model (70-80 rokov) ≈ zahŕňa prechod do ďalšej fázy po úplnom dokončení prác na predchádzajúcej fáze,

Hlavným úspechom kaskádového modelu je úplnosť etáp. To umožňuje plánovať náklady a termíny. Okrem toho sa tvorí projektovej dokumentácie, úplné a konzistentné.

Kaskádový model je použiteľný pre malé softvérové ​​projekty s jasne definovanými a nemennými požiadavkami. Reálny proces môže odhaliť zlyhania v ktorejkoľvek fáze, čo vedie k návratu do jednej z predchádzajúcich fáz. Model výroby takéhoto softvéru je kaskádový návrat

Životný cyklus softvéru. Krokový model so stredným ovládaním

krokový model so stredným riadením (80-85) ≈ iteračný model vývoja softvéru so spätnoväzbovými slučkami medzi fázami. Výhodou tohto modelu je, že medzistupňové úpravy poskytujú menšiu pracovnú náročnosť v porovnaní s kaskádovým modelom; životnosť každého štádia sa však predĺži počas celého obdobia vývoja,

Hlavné fázy riešenia problému

Účelom programovania je popísať procesy spracovania údajov (ďalej len procesy).

Dáta sú prezentáciou faktov a myšlienok vo formalizovanej forme, vhodné na prenos a spracovanie v určitom procese a informácia je význam, ktorý sa dáva údajom, keď sú prezentované.

Spracovanie údajov je vykonávanie systematického sledu akcií s údajmi. Dáta sú prezentované a uložené na pamäťových médiách.

Súbor dátových nosičov používaných na akékoľvek spracovanie dát sa nazýva informačné prostredie (dátové médium).

Súbor údajov obsiahnutých v každom okamihu v informačnom prostredí - stav informačného prostredia.

Proces možno definovať ako postupnosť po sebe nasledujúcich stavov nejakého informačného prostredia.

Opísať proces znamená určiť postupnosť stavov informačného prostredia. Aby sa požadovaný proces vygeneroval automaticky na akomkoľvek počítači podľa daného popisu, je potrebné, aby bol tento popis formalizovaný.

Kritériá kvality softvéru

Komerčný produkt (produkt, služba) musí spĺňať požiadavky spotrebiteľa.

Kvalita je objektívna charakteristika produktu (produktu, služby), ukazujúca mieru spokojnosti spotrebiteľa

Vlastnosti kvality:

› Výkon– systém funguje a implementuje požadované funkcie.

› Spoľahlivosť– systém funguje bez porúch alebo porúch.

› Obnoviteľnosť.

› Efektívnosť– systém implementuje svoje funkcie najlepším možným spôsobom.

› Ekonomická efektívnosť– minimálne náklady na konečný produkt s maximálnym ziskom.

Vlastnosti kvality:

› S prihliadnutím na ľudský faktor- jednoduchosť používania, rýchlosť osvojenia si práce so softvérom, nenáročnosť na údržbu, vykonávanie zmien.

› Prenosnosť(mobilita) – prenosnosť kódu na inú platformu alebo systém.

› Funkčná úplnosť– možno najkompletnejšia implementácia externých funkcií.

› Presnosť výpočtu

Vlastnosti algoritmu.

Efektívnosť znamená možnosť získať výsledok po vykonaní konečného počtu operácií.

Istota spočíva v zhode získaných výsledkov bez ohľadu na používateľa a použité technické prostriedky.

Hromadný charakter spočíva v možnosti aplikácie algoritmu na celú triedu podobných problémov, ktoré sa líšia špecifickými hodnotami počiatočných údajov.

Diskrétnosť - možnosť rozdelenia procesu výpočtov predpísaných algoritmom do samostatných etáp, možnosť výberu sekcií programu s určitou štruktúrou.

Spôsoby opisu algoritmov

Existujú nasledujúce spôsoby, ako opísať (prezentovať) algoritmy:

1. slovný opis;

2. popis algoritmu pomocou matematických vzorcov;

3. grafický popis algoritmu vo forme blokovej schémy;

4. popis algoritmu pomocou pseudokódu;

5. kombinovaná metóda zobrazenia algoritmu pomocou verbálnych, grafických a iných metód .

6. pomocou Petriho sietí.

Slovný popis Algoritmus je popis štruktúry algoritmu v prirodzenom jazyku. Napríklad k domácim spotrebičom je zvyčajne priložený návod na obsluhu, t.j. slovný popis algoritmu, podľa ktorého by sa toto zariadenie malo používať.

Grafický popisalgoritmu vo forme blokového diagramu je popis štruktúry algoritmu pomocou geometrických útvarov s komunikačnými čiarami.

Vývojový diagram algoritmu je grafickým znázornením metódy riešenia problému, ktorá používa špeciálne symboly na znázornenie operácií.

Symboly, ktoré tvoria blokovú schému algoritmu, sú určené GOST 19.701-90. Tento GOST zodpovedá medzinárodnému štandardu pre návrh algoritmov, preto sú vývojové diagramy algoritmov navrhnuté v súlade s GOST 19.701-90 jednoznačne chápané v rôznych krajinách.

Pseudokód– popis štruktúry algoritmu v prirodzenom, ale čiastočne formalizovanom jazyku. Pseudokód používa niektoré formálne konštrukcie a bežné matematické symboly. Neexistujú žiadne prísne pravidlá syntaxe pre písanie pseudokódu.

Pozrime sa na jednoduchý príklad. Predpokladajme, že je potrebné popísať algoritmus zobrazovania na obrazovke monitora najvyššia hodnota z dvoch čísel.

Obrázok 1 - Príklad popisu algoritmu vo forme blokovej schémy

Popis rovnakého algoritmu v pseudokóde:

2. Zadajte čísla: Z, X

3. Ak Z > X, potom Výstup Z

4. V opačnom prípade výstup X

Každá z uvedených metód zobrazovania algoritmov má svoje výhody a nevýhody. Napríklad verbálna metóda je verbálna a chýba jej prehľadnosť, ale umožňuje lepšie opísať jednotlivé operácie. Grafická metóda je viac názorná, často však vzniká potreba opísať niektoré operácie verbálnou formou. Preto je pri vývoji zložitých algoritmov lepšie použiť kombinovanú metódu.

Typy algoritmov

lineárny;

vetvenie;

cyklický.

· Lineárny algoritmus- súbor príkazov (inštrukcií) vykonávaných postupne jeden po druhom.

· Algoritmus vetvenia- algoritmus obsahujúci aspoň jednu podmienku, ako výsledok kontroly, ktorý počítač poskytuje prechod na jeden z dvoch možných krokov.

· Okruhový algoritmus- algoritmus, ktorý zahŕňa opakované opakovanie tej istej akcie (rovnaké operácie) na nových počiatočných údajoch. Väčšina metód výpočtu a počítania možností je zredukovaná na cyklické algoritmy. Programový cyklus - postupnosť príkazov (séria, telo cyklu), ktoré možno vykonávať opakovane (pre nové zdrojové dáta), kým nie je splnená určitá podmienka.

C. Typy údajov.

Dátový typ je popis rozsahu hodnôt, ktoré môže mať premenná určeného typu. Každý typ údajov sa vyznačuje:
1. počet obsadených bajtov (veľkosť)
2. rozsah hodnôt, ktoré môže premenná tohto typu nadobudnúť.

Všetky typy údajov možno rozdeliť na nasledujúce typy:
1. jednoduché (skalárne) a komplexné (vektorové) typy;
2. základné (systémové) a užívateľské (definované užívateľom).
V jazyku SI je systém základných typov tvorený štyrmi dátovými typmi:
1. symbolický,
2. celé číslo,
3. jedna presnosť skutočná,
4. dvojitá presnosť skutočné.

Štruktúra programu C.

1. Operátory jazyka C++

Operátori riadia proces vykonávania programu. Sada operátorov jazyka C++ obsahuje všetky riadiace konštrukcie štruktúrovaného programovania.
Zložený príkaz je ohraničený zloženými zátvorkami. Všetky ostatné výroky sa končia bodkočiarkou.
Prázdny operátor – ;
Prázdny príkaz je výrok pozostávajúci iba z bodkočiarky. Môže sa objaviť kdekoľvek v programe, kde syntax vyžaduje príkaz. Vykonanie prázdneho príkazu nemení stav programu.
Zložený operátor – (...)
Výsledkom zloženého príkazu je vykonávať príkazy, ktoré obsahuje, postupne, pokiaľ príkaz výslovne neprenáša kontrolu na iné miesto v programe.
Vyhlásenie o zaobchádzaní s výnimkami

skús (<операторы> }
chytiť (<объявление исключения>) { <операторы> }
chytiť (<объявление исключения>) { <операторы> }
...
chytiť (<объявление исключения>) { <операторы> }

Podmienený operátor

ak (<выражение>) <оператор 1>

Prepnúť operátora

prepínač (<выражение>)
(prípad<константное выражение 1>: <операторы 1>
prípad<константное выражение 2>: <операторы 2>
...
prípad<константное выражение N>: <операторы N>
}
Príkaz switch sa používa na výber jednej z niekoľkých alternatívnych ciest pre vykonávanie programu. Vyhodnotenie príkazu switch začína vyhodnotením výrazu, po ktorom sa riadenie prenesie na príkaz označený konštantným výrazom rovným hodnotenej hodnote výrazu. Výstup z príkazu switch sa vykoná príkazom break. Ak sa hodnota výrazu nerovná žiadnemu konštantnému výrazu, riadenie sa prenesie na príkaz označený predvoleným kľúčovým slovom, ak nejaké existuje.
Slučkový operátor s predpokladom

zatiaľ čo (<выражение>) <оператор>

Operátor slučky s dodatočnou podmienkou

robiť<оператор>zatiaľ čo<выражение>;
V jazyku C++ sa tento operátor líši od klasickej implementácie slučky s post-podmienkou v tom, že ak je výraz pravdivý, slučka pokračuje, a nie opúšťa slučku.
Operátor krokovej slučky

pre ([<начальное выражение>];
[<условное выражение>];
[<выражение приращения>])
<оператор>
Telo príkazu for sa vykonáva, kým sa podmienený výraz nestane nepravdivým (rovná sa 0). Počiatočné a prírastkové výrazy sa zvyčajne používajú na inicializáciu a úpravu parametrov slučky a iných hodnôt. Počiatočný výraz sa vyhodnotí raz pred prvým testovaním podmieneného výrazu a prírastkový výraz sa vyhodnotí po každom vykonaní príkazu. Ktorýkoľvek z troch výrazov hlavičky slučky a dokonca aj všetky tri možno vynechať (len nezabudnite vynechať bodkočiarky). Ak je podmienený výraz vynechaný, považuje sa za pravdivý a cyklus sa stáva nekonečným.
Operátor slučky krok za krokom v jazyku C++ je flexibilná a pohodlná konštrukcia, preto sa operátor slučky s podmienkou while používa v jazyku C++ veľmi zriedka, pretože vo väčšine prípadov je pohodlnejšie použiť operátora for.
Operátor prestávky

prestávka;
Operátor break preruší vykonávanie príkazov while, do, for a switch. Môže byť obsiahnutý iba v tele týchto vyhlásení. Riadenie sa prenesie na operátora programu, ktorý nasleduje po prerušení. Ak je príkaz break napísaný vo vnorených príkazoch while, do, for, switch, potom ukončí iba príkaz, ktorý ho bezprostredne obklopuje.
operátor pokračovania

ďalej;
Operátor pokračovania prenáša riadenie na ďalšiu iteráciu v rámci while, do, pre operátory slučky. Môže byť obsiahnutý iba v tele týchto vyhlásení. V príkazoch do a while začína ďalšia iterácia vyhodnotením podmieneného výrazu. V príkaze for sa ďalšia iterácia začína vyhodnotením výrazu prírastku a potom sa vyhodnotí podmienený výraz.
Operátor návratu

vrátiť [<выражение>];
Príkaz return ukončí vykonávanie funkcie, ktorá ho obsahuje, a vráti riadenie volajúcej funkcii. Riadenie sa prenesie do bodu volajúcej funkcie

If (logický výraz)

operátor;

If (logický výraz)

operátor_1;

operátor_2;

<логическое выражение> ? <выражение_1> : <выражение_2>;

Ak je hodnota logického výrazu pravdivá, potom sa vyhodnotí výraz_1, v opačnom prípade sa vyhodnotí výraz_2.

prepínač (celočíselný výraz)

case value_1:

príkaz_sekvencia_1;

case value_2:

príkaz_sekvencia_2;

case value_n:

príkaz_sekvencia_n;

predvolene:

operator_sequence_n+1;

Pobočka predvolená nedá sa opísať. Vykoná sa, ak nie je splnený žiadny z vyšších výrazov.

Operátor slučky.

Turbo C má nasledujúce konštrukcie, ktoré vám umožňujú programovať cykly: kým, rob, kým A pre . Ich štruktúru možno opísať takto:

Slučka na kontrolu stavu v hornej časti:

Operátor výberu

Ak akcie, ktoré chcete vykonať v programe, závisia od hodnoty nejakej premennej, môžete použiť operátor select. V C++ však možno ako premenné v operátore výberu použiť iba číselné premenné. Vo všeobecnosti vyzerá záznam operátora výberu takto:

prepínač (variabilný)
{
hodnota prípadu 1:
akcie1
prestávka;

case value2:
akcie2
prestávka;
...

predvolene:
predvolené akcie
}

Kľúčové slovo prestávka musí byť pridaná na koniec každej vetvy. Zastaví spustenie operácie výberu. Ak ho nezapíšete, po vykonaní akcií z jednej výberovej vetvy bude pokračovať vykonávanie akcií z nasledujúcich vetiev. Niekedy je však táto vlastnosť výberu užitočná, napríklad ak potrebujete vykonať rovnaké akcie pre rôzne hodnoty premennej.

prepínač (variabilný)
{
hodnota prípadu 1:
case value2:
akcie1
prestávka;

hodnota prípadu 3:
akcie2
prestávka;
...
}

Príklad použitia select:

int n, x;
...
prepínač(n)
{
prípad 0:
prestávka; //ak je n 0, tak nevykonávame žiadne akcie

prípad 1:
prípad 2:
prípad 3:
x = 3* n; //ak je n 1, 2 alebo 3, vykonajte nejaké akcie
prestávka;

prípad 4:
x = n; //ak n je 4, potom vykonajte ďalšie akcie
prestávka;

predvolene:
x = 0; //pre všetky ostatné hodnoty n vykonajte predvolené akcie
}

C.Cycle: cyklus s parametrom

Všeobecná forma záznamy

pre (inicializácia parametrov; kontrola koncového stavu; oprava parametrov) (

blok operácií;

for - parametrická slučka (slučka s pevným počtom opakovaní). Na organizáciu takéhoto cyklu je potrebné vykonať tri operácie:

§ inicializácia parametrov- priradenie počiatočnej hodnoty parametru cyklu;

§ kontrola koncového stavu- porovnanie hodnoty parametra s určitou hraničnou hodnotou;

§ korekcia parametrov- zmena hodnoty parametra pri každom prechode tela slučky.

Tieto tri operácie sú napísané v zátvorkách a oddelené bodkočiarkou (;). Parameter slučky je zvyčajne celočíselná premenná.
Inicializácia parametra nastane iba raz - keď sa spustí cyklus for. Podmienka ukončenia sa kontroluje pred každým možným vykonaním tela slučky. Keď sa výraz stane nepravdivým (rovná sa nule), cyklus sa skončí. Parameter sa upraví na konci každého vykonania tela slučky. Parameter sa môže zvýšiť alebo znížiť.

Príklad

#include
int main() (

for(num = 1; num< 5; num++)

printf("num = %d\n",num);

Si. Slučka s predpokladom

Všeobecný záznamový formulár

while(výraz) (

blok operácií;
}

Ak je výraz pravdivý (nerovná sa nule), vykoná sa blok operácií uzavretý v zložených zátvorkách a výraz sa znova skontroluje. Postupnosť akcií pozostávajúcich z kontroly a vykonania bloku operácií sa opakuje, až kým sa výraz nestane nepravdivým (rovná sa nule). V tomto prípade sa slučka opustí a vykoná sa operácia nasledujúca za operátorom slučky.

Príklad

int k=5;
int i=1;
int suma=0;
kým<=k) {

Pri konštrukcii while cyklu je potrebné zahrnúť konštrukty, ktoré menia hodnotu testovaného výrazu tak, že sa nakoniec stane nepravdivým (rovnajúcim sa nule). V opačnom prípade bude slučka bežať napríklad donekonečna (nekonečná slučka).

blok operácií;
}

while je cyklus s podmienkou, takže je dosť možné, že telo cyklu sa nevykoná ani raz, ak sa v čase prvej kontroly kontrolovaná podmienka ukáže ako nepravdivá.

Si. Slučka s dodatočnou podmienkou

Slučka s do...pri postcondition

Všeobecný záznamový formulár

blok operácií;

) while(výraz);

Slučka s dodatočnou podmienkou

Cyklus do...while je cyklus s postpodmienkou, kde sa pravdivosť výrazu kontroluje po vykonaní všetkých operácií zahrnutých v bloku ohraničenom zloženými zátvorkami. Telo cyklu sa vykonáva, kým sa výraz nestane nepravdivým, tj telo cyklu s post-podmienkou sa vykoná, hoci len raz.

Slučku do...while je lepšie použiť v prípadoch, keď je potrebné dokončiť aspoň jednu iteráciu, alebo keď k inicializácii objektov zapojených do kontroly podmienky dôjde v tele cyklu.

Príklad. Zadajte číslo od 0 do 10

#include
#include
int main() (

system("chcp 1251");

printf("Zadajte číslo od 0 do 10: ");

scanf("%d", &num);

) while((č< 0) || (num > 10));

printf("Zadali ste číslo %d", num);

getchar(); getchar();

Definovanie funkcií

Pozrime sa na definíciu funkcie pomocou súčtovej funkcie ako príkladu.

V C a C++ nemusia byť funkcie definované, kým sa nepoužijú, ale musia byť predtým deklarované. Ale aj po tomto všetkom musí byť táto funkcia nakoniec definovaná. Prototyp funkcie a jej definícia sú potom spojené a funkcia môže byť použitá.

Ak bola funkcia predtým deklarovaná, musí byť definovaná s rovnakou návratovou hodnotou a dátovými typmi, inak sa vytvorí nová, preťažená funkcia. Všimnite si, že názvy parametrov funkcií nemusia byť rovnaké.