Klasické modely procesu vývoja softvéru. Prehľad procesu vývoja softvéru

Proces vývoja softvéru (angl. software development process, software process) je štruktúra, podľa ktorej sa stavia vývoj softvéru.
Existuje niekoľko modelov takéhoto procesu (metodiky vývoja softvéru), z ktorých každý popisuje svoj vlastný prístup vo forme úloh a/alebo činností, ktoré sa počas procesu odohrávajú.

Existujú nasledujúce hlavné modely procesov alebo metodológie vývoja softvéru:

Kaskádový vývoj alebo vodopádový model - model procesu vývoja softvéru, v ktorom proces vývoja vyzerá ako tok, ktorý postupne prechádza fázami analýzy požiadaviek, návrhu, implementácie, testovania, integrácie a podpory. Ako zdroj názvu „vodopád“ sa často uvádza článok publikovaný W. W. Royceom v roku 1970; smiešne, že samotný Royce použil iteratívny vývojový model a nepoužil ani výraz „vodopád“.
Iteračný vývoj(angl. iterácia - opakovanie) - vykonávanie práce súbežne s priebežnou analýzou získaných výsledkov a úpravou predchádzajúcich etáp práce. Projekt s týmto prístupom v každej fáze vývoja prechádza opakujúcim sa cyklom: Plánovanie - Implementácia - Kontrola - Hodnotenie (angl. cyklus plánuj-urob-kontroluj-konaj).
Počas vývoja sú vždy identifikované dodatočné požiadavky alebo skôr identifikované zmeny. S prijatými technickými riešeniami súvisia aj nové obmedzenia. Práve v iteratívnom vývoji ich možno v plnej miere zohľadniť, keďže práve s týmto prístupom je projektový manažment plne pripravený na zmeny. Iteračný prístup je teraz najbežnejší vďaka svojim zjavným výhodám a v DPGroup sa používajú jeho rôzne variácie.
Iteratívne metódy vývoja softvéru používané spoločnosťou DPGroup:
- Rational Unified Process(RUP) je metodika vývoja softvéru vytvorená spoločnosťou Rational Software.
  RUP je založený na nasledujúcich základných princípoch:
  - Včasná identifikácia a priebežná (až do konca projektu) eliminácia kľúčových rizík.
  - Koncentrácia na splnenie požiadaviek zákazníkov na spustiteľný program (analýza a vytvorenie modelu precedensov).
  - Počas vývoja očakávajte zmeny v požiadavkách, rozhodnutiach o dizajne a implementácii.
  - Architektúra komponentov, ktorá je implementovaná a testovaná v počiatočných fázach projektu.
  - Priebežné zabezpečenie kvality vo všetkých fázach vývoja projektu (produktu).
  - Práca na projekte v úzkom tíme, v ktorom zohrávajú kľúčovú úlohu architekti.
- Agilná metodika vývoja(angl. Agile software development).
  Väčšina agilných metodík má za cieľ minimalizovať riziko znížením vývoja na sériu krátkych cyklov tzv iterácií ktoré zvyčajne trvajú jeden až dva týždne. Každá iterácia sama osebe vyzerá ako miniatúrny softvérový projekt a zahŕňa všetky úlohy potrebné na vytvorenie miniatúrneho rastu funkčnosti: plánovanie, analýza požiadaviek, dizajn, kódovanie, testovanie a dokumentácia. Zatiaľ čo jedna iterácia vo všeobecnosti nestačí na vydanie novej verzie produktu, predpokladá sa, že agilný softvérový projekt je pripravený na vydanie na konci každej iterácie. Na konci každej iterácie tím prehodnotí priority vývoja.
  Agilné metódy kladú dôraz na komunikáciu tvárou v tvár. Väčšina agilných tímov sa nachádza v rovnakej kancelárii, niekedy nazývanej bullpen. Minimálne zahŕňa aj „zákazníkov“ (zákazníkov, ktorí definujú produkt, ako sú produktoví manažéri, obchodní analytici alebo zákazníci). Kancelária môže zahŕňať aj testerov, dizajnérov rozhraní, technických autorov a manažérov. Jednou z najznámejších a najpokročilejších agilných metodík je metodológia.

Viac ako 50 rokov vývoja softvérového inžinierstva, veľké množstvo modely vývoja softvéru. Je zaujímavé načrtnúť analógiu medzi históriou vývoja metód používaných v automatických riadiacich systémoch pre lietadlá a vývojom prístupov k riadeniu softvérových projektov.

"Uvidíme ako to pôjde". Riadiaci systém s otvorenou slučkou. Úplná dôvera v technických lídrov. Zástupcovia firiem sa na projekte prakticky nezúčastňujú. Plánovanie, ak existuje, je neformálne a verbálne. Čas a rozpočet vo všeobecnosti nie sú kontrolované. Analógia: balistický let bez spätnej väzby. Je to možné, ale blízke a nepresné.

"vodopád" alebo model vodopádu. Pevná spätná väzba. Výpočet referenčnej trajektórie (projektový plán), meranie odchýlok, korekcia a návrat na referenčnú trajektóriu. Lepšie, ale nie efektívne.

"Flexibilné riadenie". Výpočet referenčnej trajektórie, meranie odchýlok, výpočet novej prichádzajúcej trajektórie a korekcia na jej dosiahnutie. "Plány nie sú nič, plánovanie je všetko" (Eisenhower, Dwight David)

"Metóda častých dodávok". Navádzanie domov. Výpočet referenčnej trajektórie, meranie odchýlok, špecifikácia cieľa, výpočet novej prichádzajúcej trajektórie a korekcia na jej dosiahnutie.

Klasické metódy riadenia prestávajú fungovať v prípadoch, keď nám štruktúra a vlastnosti riadeného objektu nie sú známe a/alebo sa časom menia. Tieto prístupy tiež nepomôžu, ak aktuálne vlastnosti objektu neumožňujú pohybovať sa s požadovanými vlastnosťami. Napríklad lietadlo nemôže vyvinúť požadované zrýchlenie alebo je zničené neprijateľným preťažením. Podobne, ak projektový tím nedokáže zabezpečiť požadovanú efektivitu a teda neustále pracuje v núdzovom režime, tak to nevedie k zvýšeniu produktivity, ale k odchodu profesionálov z projektu.

Keď štruktúra a vlastnosti riadeného objektu nie sú známe, musíme použiť adaptívne ovládanie, ktorá je okrem priamych riadiacich akcií zameraná na štúdium a zmenu vlastností riadeného objektu. Pokračujeme v analógii s riadením lietadla, ide o výpočet referenčnej trajektórie, meranie odchýlok, spresnenie cieľa, spresnenie riadiaceho objektu, prispôsobenie (nutná zmena) riadiaceho objektu, výpočet nového dráha pádu a korekcia na jej dosiahnutie.

Aby bolo možné pochopiť štruktúru a vlastnosti objektu a ovplyvniť ich tak, aby sa dostali do požadovaného stavu, musí mať projekt dodatočnú spätnú väzbu – adaptačnú slučku.

Je známe, že výkon rôznych programátorov sa môže desaťkrát líšiť. Potvrdzujem, že výkon toho istého programátora sa môže líšiť aj niekoľkonásobne. Dajte najlepšieho bežca na svete do vreca a bude 10-krát horší. Prinúťte najlepšieho programátora, aby vykonal „sizyfovskú prácu“: aby vytvoril dokumentáciu (ktorú spravidla nikto nečíta) kvôli „metodike“ (konkrétne s veľkým M) a jeho produktivita sa zníži 10-krát.

Preto, okrem čisto manažérskych úloh, musí vedúci, ak sa usiluje o dosiahnutie najvyššej produktivity pracovnej skupiny, neustále usilovať o štúdium a zmenu predmetu riadenia: ľudí a ich interakcie.

Modelky(alebo, ako radi hovoria, metodiky) procesy vývoja softvéru sa zvyčajne klasifikujú podľa „váhy“ – počtu formalizovaných procesov (väčšina procesov alebo len tých hlavných) a podrobnosti ich regulácie. Čím viac procesov je zdokumentovaných, čím podrobnejšie sú opísané, tým väčšia je „váha“ modelu.

Najbežnejšie moderné modely procesu vývoja softvéru sú znázornené na obr. 2.3.

Ryža. 2.3. Rôzne modely procesu vývoja softvéru

GOST

GOST 19 „Jednotný systém softvérovej dokumentácie“ a GOST 34 „Štandardy pre vývoj a údržbu automatizovaných systémov“ sú zamerané na konzistentný prístup k vývoju softvéru. Vývoj v súlade s týmito normami sa vykonáva v etapách, z ktorých každá zahŕňa výkon presne definovanej práce a končí vydaním pomerne veľkého počtu veľmi formalizovaných a rozsiahlych dokumentov. Striktné dodržiavanie týchto hostí teda vedie nielen k vodopádovému prístupu, ale vyžaduje si aj veľmi vysoký stupeň formalizácie rozvoja. Na základe týchto štandardov sa v Rusku vyvíjajú softvérové systémy pre vládne objednávky.

V polovici 80. rokov minulého storočia americké ministerstvo obrany usilovne premýšľalo o tom, ako vybrať vývojárov softvéru pre rozsiahle softvérové projekty. Inštitút softvérového inžinierstva, súčasť Carnegie Mellon University, na objednávku armády vyvinul SW-CMM, Capability Maturity Model for Software, ako referenčný model pre organizácie zaoberajúce sa vývojom softvéru.

Tento model definuje päť úrovní zrelosti procesu vývoja softvéru.

1) Počiatočné - proces vývoja je chaotický. Len málo procesov je definovaných a úspech projektov závisí od jednotlivých aktérov.

2) Opakovateľné – sú zavedené základné procesy riadenia projektu: sledovanie nákladov, termínov a funkcionality. Niektoré z procesov potrebných na zopakovanie predchádzajúcich úspechov na podobných projektoch sa zjednodušili.

3) Definované - procesy vývoja softvéru a projektového manažmentu sú popísané a implementované v jednotnom systéme firemných procesov. Všetky projekty využívajú štandardný proces vývoja softvéru a podpory organizácie, prispôsobený konkrétnemu projektu.

4) Riadené – zbierajú sa podrobné kvantitatívne údaje o fungovaní procesov vývoja a kvalite finálneho produktu. Analyzuje sa význam a dynamika týchto údajov.

5) Optimalizovateľné - neustále zlepšovanie procesov je založené na kvantitatívnych údajoch o procesoch a na skúšobnej implementácii nových nápadov a technológií.

Kompletná dokumentácia SW-CMM má približne 500 strán a definuje súbor 312 požiadaviek, ktoré musí organizácia splniť, ak sa plánuje kvalifikovať pre tento štandard na úrovni zrelosti 5.

Rational Unified Process (RUP) vyvinuli Philippe Kruchten, Ivar Jacobson a ďalší v Rational Software ako doplnok k modelovaciemu jazyku UML. Model RUP popisuje abstraktný všeobecný proces, z ktorého by mala organizácia alebo projektový tím vytvoriť špecifický, špecializovaný proces, ktorý je zameraný na jej potreby. Práve táto vlastnosť RUP spôsobuje hlavnú kritiku - keďže to môže byť čokoľvek, nemožno to považovať za nič definitívne. V dôsledku tohto všeobecného dizajnu môže byť RUP použitý ako základ pre najtradičnejší vodopádový štýl vývoja a ako agilný proces.

Microsoft Solutions Framework (MSF) je flexibilný a pomerne ľahký model postavený na iteratívnom vývoji. Atraktívnou črtou Lekárov bez hraníc je silné zameranie na budovanie efektívneho a nebyrokratického projektového tímu. Na dosiahnutie tohto cieľa Lekári bez hraníc ponúkajú skôr neštandardné prístupy k organizačnej štruktúre, rozdeleniu zodpovednosti a princípom interakcie v rámci tímu.

Jeden z najnovších vývojov Inštitútu softvérového inžinierstva Osobný softvérový proces / tímový softvérový proces. Proces osobného softvéru definuje požiadavky na kompetenciu vývojára. Podľa tohto modelu by mal byť každý programátor schopný:

vziať do úvahy čas strávený na projekte;

vziať do úvahy zistené nedostatky;

klasifikovať typy defektov;

odhadnúť veľkosť úlohy;

· vykonávať systematický prístup k opisu výsledkov testov;

plánovať programové úlohy;

Rozdeľte ich podľa času a zostavte pracovný harmonogram.

vykonávať individuálne hodnotenia dizajnu a architektúry;

vykonávať individuálne kontroly kódu;

Vykonajte regresné testovanie.

Team Software Process sa spolieha na samostatne spravované tímy 3-20 vývojárov. Tímy musia:

stanovte si vlastné ciele;

· vytvoriť si vlastný proces a plány;

traťová práca;

Udržujte motiváciu a špičkový výkon.

Dôsledná aplikácia modelu PSP / TSP vám umožňuje urobiť z piatej úrovne CMM normu v organizácii.

Hlavnou myšlienkou všetkých agilných modelov je, že proces vývoja softvéru by mal byť adaptívny. Deklarujú, že ich najvyššou hodnotou je zameranie sa na ľudí a ich interakciu, a nie na procesy a prostriedky. V skutočnosti takzvané agilné metodológie nie sú metodikami, ale súborom praktík, ktoré môžu (alebo nemusia) umožniť efektívny vývoj softvéru založený na iterácii, inkrementálnosti, tímovom samoriadení a prispôsobivosti procesov.

Výber modelu procesu

Ťažké a ľahké modely výrobného procesu majú svoje výhody a nevýhody, ktoré sú uvedené v tabuľke. 2.1.

Tabuľka 2.1

Výhody a nevýhody ťažkých a ľahkých modelov procesov vývoja softvéru

Hmotnosť modelu	klady	Mínusy
ťažký	Procesy sú navrhnuté pre priemernú kvalifikáciu účinkujúcich. Veľká špecializácia interpretov. Nižšie sú uvedené požiadavky na stabilitu tímu. Neexistujú žiadne obmedzenia týkajúce sa objemu a zložitosti prebiehajúcich projektov.	Vyžaduje značné náklady na riadenie. Dlhšie fázy analýzy a návrhu. Formálnejšia komunikácia.
Pľúca	Menšia réžia spojená s riadením projektu, rizikami, zmenami, konfiguráciami. Zjednodušené fázy analýzy a dizajnu, hlavné zameranie na vývoj funkčnosti, kombinácia rolí. neformálna komunikácia.	Efektivita vo veľkej miere závisí od individuálnych schopností, čo si vyžaduje kvalifikovanejší, všestrannejší a stabilnejší tím. Rozsah a zložitosť prebiehajúcich projektov sú obmedzené.

Verí sa, že bieli ľudia nečestne získali kontrolu nad týmito predmetmi. Najznámejšie kulty nákladu stavajú repliky pristávacích dráh, letísk a rádiových veží z kokosových paliem a slamy. Členovia kultu ich budujú vo viere, že tieto stavby pritiahnu dopravné lietadlá (považované za poslov duchov) naplnené nákladom (nákladom). Veriaci pravidelne vykonávajú vojenské cvičenia („drill“) a nejaké vojenské pochody, pričom namiesto pušiek používajú konáre a kreslia na telo rozkazu a nápis „USA“. To všetko preto, aby z neba opäť padali lietadlá a týchto predmetov bolo viac.

Alistair Cowburn, jeden z autorov Agile Manifesto, analyzoval veľmi odlišné softvérové projekty, ktoré boli implementované v rôznych modeloch od úplne ľahkých a „agilných“ až po ťažké (CMM-5) za posledných 20 rokov. Nezistil žiadnu súvislosť medzi úspechom alebo neúspechom projektov a modelmi procesov vývoja, ktoré boli v projektoch použité. Z toho dospel k záveru, že efektívnosť vývoja softvéru nezávisí od modelu procesu a tiež, že:

Každý projekt by mal mať svoj vlastný model procesu vývoja.

Každý model má svoj čas.

To znamená, že neexistuje jediný správny proces vývoja softvéru, v každom novom projekte musí byť proces definovaný zakaždým nanovo, v závislosti od projektu, produktu a personálu, v súlade so „Zákonom 4 P“ (obr. 2.4). Úplne iné procesy by sa mali uplatňovať v projektoch s 5 ľuďmi a projektoch s 500 ľuďmi. Ak je produktom projektu kritický softvér, napríklad riadiaci systém jadrovej elektrárne, potom by sa vývojový proces mal veľmi líšiť od vývoja napríklad stránky „otdokhni.ru“. A napokon, proces vývoja by mal byť organizovaný inak v tíme včerajších študentov a v tíme skúsených odborníkov.

Tím, ktorý projekt začal, nezostáva nezmenený, prechádza určitými fázami formovania a spravidla kvantitatívne rastie s vývojom projektu. Preto sa proces musí neustále prispôsobovať týmto zmenám. Hlavná zásada: nie ľudia by sa mali stavať podľa zvoleného procesného modelu, ale procesný model by mal byť prispôsobený konkrétnemu tímu, aby bola zabezpečená jeho najvyššia efektívnosť.

Ryža. 2.4. "Zákon 4 P". Proces v projekte by mal byť definovaný v závislosti od projektu, produktu a personálu

Skôr než ponúknem prehľad vývojového procesu, ktorý sa vyvinul v dôsledku nahromadenia skúseností za posledné roky, rád by som uviedol niekoľko všeobecných vysvetlení, ktoré sa mi zdajú podstatné.

V IT pracujem posledných 15 rokov, hoci programovať som začal oveľa skôr. Mojím hlavným zameraním ako systémového architekta bolo organizovanie vývoja softvéru, vývoj konceptov a architektúry na vysokej úrovni a dohľad nad implementáciou konceptu počas celého projektu. Okrem manažovania vývoja softvéru a tvorby architektúry sa z času na čas zaoberám riešením zložitých technických problémov a písaním niektorých kritických častí kódu, kde je nevyhnutná znalosť samotného jazyka a vývojového prostredia, ale aj ich vnútornej organizácie, ktorá niekedy prináša nepríjemné prekvapenia. .

Projekty, na ktorých pracujem, sa najčastejšie týkajú vývoja zákazkového alebo investičného softvéru. Musel som pracovať aj s embedded softvérom a programami zameranými na vydávanie „hitov“ (ktoré s ľahkou rukou Joela Spolského ďalej nazývam herný softvér, aj keď v skutočnosti majú niektoré herné projekty bližšie k investičným projektom).

Zákazkový softvér môže byť pre interného alebo externého zákazníka. Zákazník získava výhradné práva na vyvinutý systém a práca na vývoji systému môže byť v budúcnosti prevedená na iného dodávateľa.

Na rozdiel od zákazkového softvéru si práce na investičnom softvéri realizuje zhotoviteľ sám za peniaze interného alebo externého investora. Práva na systémový kód spravidla zostávajú vývojárom, čo stimuluje neustálu prácu na zlepšovaní ich produktu a konzistentné vydávanie verzií s pokročilejšími funkciami.

Firmvér je dodávaný s hardvérom a je, zhruba povedané, neudržovateľný, pretože stiahnutie série zariadení výrobcom je veľmi nákladné, a teda výnimočné.

Vývoj herných hitov tiež prakticky neobsahuje sprievodnú fázu. Okrem toho používatelia herných programov, aj keď čelia chybe v hre, veľmi zriedka sťahujú aktualizovanú verziu. Preto má vývoj hier spravidla svoju vlastnú ekonomiku a svoj vlastný vývojový proces.

Našimi zákazníkmi sú úrady, veľké štátne a komerčné organizácie a samozrejme my sami. Preto, pokiaľ ide o softvér na zákazku, často existuje určitý rozdiel v našom procese medzi vývojom produktov pre interných a externých zákazníkov. V tomto článku poukážem na niektoré nuansy. Úroveň formalizácie vzťahov so zákazníkom sa veľmi líši od projektu k projektu. Vo všeobecnosti platí, že čím väčší rozpočet projektu, tým vyššia formalita. Odberateľ štátu alebo veľké obchodné podniky (najmä s účasťou štátu) majú spravidla legislatívne obmedzenia na vznik, zadávanie zákazky a prijímanie výsledkov práce. Ďalším obmedzením veľkých organizácií je fakt, že ich personál, ktorý je zdrojom požiadaviek a hlavným užívateľom našich systémov, má pre účinkujúcich veľmi obmedzenú dostupnosť, už len z dôvodu ich vyťaženosti. U malých organizácií však miera formalizácie klesá a niekedy ide až do opačného extrému, kde je nedostatočná miera zodpovednosti zákazníka v rámci projektu.

Druhou stránkou našich zákazkových projektov sú vysoké nároky na funkčnosť. Ide o vysoké zaťaženie všetkých systémov a veľké geografické rozloženie a vysoké požiadavky na presnosť výpočtov s veľmi obmedzeným časovým rámcom. V našich projektoch sú často prvky výskumnej práce a kreatívneho hľadania zameraného na riešenie netriviálnych problémov dizajnu. Niekedy musíme kombinovať rôzne metodológie v rámci toho istého vývojového procesu, napríklad vložením jednej alebo viacerých fáz takmer čistého scrumu do celkového procesu, blízkeho RUP, čím vznikne niečo ako projekt v projekte. To nám umožňuje udržať angažovanosť používateľov na nízkej úrovni vzhľadom na povahu projektu s flexibilitou vývoja pri vysokej neistote požiadaviek. V tomto smere je pre mňa dôležitá prípravná fáza, počas ktorej si môžete zvoliť potrebnú metodiku a vybudovať optimálny vývojový proces. Jeden z príkladov využitia agilnej metodiky som popísal v článku “Aplikácia agile pri vývoji projektu pre vládneho zákazníka” .

Ako príklad práce na investičnom projekte môžem uviesť vývoj integrovaného bezpečnostného systému, ktorý sme vytvorili ako „krabicový“ produkt. Pod mojím vedením boli postupne vydané štyri verzie tohto systému, ktorých používateľmi boli rôzne komerčné a vládne organizácie vrátane moskovskej radnice, AFK Sistema, bánk, obchodných centier a, samozrejme, naša vlastná kancelária. Prvá verzia nebola veľmi úspešná, ale mali sme stratégiu rozvoja, ktorá nám umožnila úspešne zachytiť trh a prežiť ťažké časy krízy. Skúsenosti z práce na tomto a niekoľkých ďalších investičných projektoch boli zohľadnené aj pri formovaní procesu vývoja, ktorý používam.

Náš proces je sledom určitých etáp. Mnou uvedená klasifikácia softvéru je urobená len preto, aby ukázala možný rozdiel v organizácii vývoja rôznych softvérových nástrojov. Pri prehľade procesu vývoja sa zameriam len na rozdiely v samotnom procese s ohľadom na rôzne typy softvéru. Musíme však pamätať na to, že rozdiely medzi procesmi vývoja rôznych typov softvéru sú oveľa hlbšie, takže pri plánovaní každej etapy je potrebné brať do úvahy tieto nuansy.

Je dôležité pochopiť, že prechod procesu z jednej fázy do druhej nemá jasné hranice. Spravidla sa práca ďalšej etapy začína, keď je dokončených 80 – 90 % prác na predchádzajúcej etape. Platí to najmä pre vývoj požiadaviek, kedy v niektorých prípadoch k odstráneniu neistoty dochádza až na konci projektu. Samozrejme, prítomnosť takejto neistoty v projekte predstavuje značné riziko a mala by byť pod neustálou kontrolou.

Proces vývoja softvéru na mieru

Prehliadku procesu vývoja začnime najčastejším prípadom – vývojom softvéru na mieru. Schéma procesu je znázornená na obrázku 1.

Obrázok 1. Proces vývoja softvéru na zákazku.

Práce na projekte začínajú prípravnou fázou. Účelom etapy je vytvoriť koncept budúceho systému na základe návrhov zákazníka a na základe tohto konceptu posúdiť relevantnosť a realizovateľnosť projektu. Ak o prilákaní dodávateľa rozhoduje zákazník na základe súťaže, potom prípravná fáza je vlastne fázou prípravy potenciálneho dodávateľa na výberové konanie vrátane vytvorenia potrebnej dokumentácie.

Nie je potrebné strácať čas a zdroje na projekte, ktorého koncept je uznaný ako nevyžiadaný alebo nerealizovateľný. Tento projekt musí byť dokončený. V niektorých prípadoch je potrebná istá opakovaná práca so zákazníkom, aby sa opravila koncepcia projektu, kým sa nedosiahne prijateľná rovnováha medzi požiadavkami zákazníka a nákladmi dodávateľa, alebo kým sa neprijme rozhodnutie o obmedzení práce.

Projekt, ktorého koncepcia vyzerá prijateľne na implementáciu, vstupuje do fázy vývoja požiadaviek. V tejto fáze musí dodávateľ zostaviť zoznam všetkých explicitných a skrytých potrieb zákazníka. Často sa ukazuje, že objednávateľ buď nerozhodol o svojich potrebách, alebo sú jeho potreby vo vzájomnom rozpore, so schopnosťami objednávateľa alebo so schopnosťami zhotoviteľa. Cieľom etapy je identifikovať všetky skryté potreby, vyriešiť konflikty požiadaviek, vytvoriť holistické technické riešenie a analyzovať realizovateľnosť pripraveného riešenia.

Niekedy objasnenie požiadaviek vedie k revízii koncepcie projektu. Ak po objasnení všetkých požiadaviek nie je možné nájsť prijateľné technické riešenie, je potrebné projekt skrátiť alebo odložiť o nejaký čas v očakávaní prijateľnejších okolností.

Ak sa nájde technické riešenie, umelec pokračuje vo vývoji architektúry budúceho systému. Účelom etapy je definovať špičkovú logickú a fyzickú architektúru, ktorá plne pokrýva všetky požiadavky zákazníka. Pri vývoji architektúry sa preveruje a dolaďuje koncept, požiadavky a predbežné technické riešenie, čo umožňuje predchádzať najnebezpečnejším rizikám.

Po dokončení návrhu architektúry je potrebné znovu prehodnotiť hlavné parametre projektu a rozhodnúť, či je dodávateľ schopný projekt dokončiť. Vo fáze vývoja architektúry je užitočné opustiť nepotrebné a príliš ťažkopádne funkcie. Optimalizácia architektonického riešenia často pomáha zapadnúť do prijateľných parametrov projektu. V ostatných prípadoch je potrebné radikálnejšie zníženie funkčnosti vyvíjaného systému. Avšak aj zastavenie projektu v tejto fáze, ak k nemu dôjde z dobrých dôvodov, by sa malo vnímať ako víťazstvo: pokračovanie prác v tomto prípade môže viesť len k ešte väčším stratám.

Ak sa nájde rovnováha a vytvorí sa prijateľná architektúra systému, dodávateľ môže prejsť k implementácii a dodávke systému. Implementácia môže prebiehať v jednej alebo viacerých etapách. Pre malé projekty môže byť celkom prijateľné jednostupňové dodanie všetkých funkcií systému. Čím väčší je však projekt, tým vyššie sú závislosti podsystémov v rámci vytváraného systému. Za týchto podmienok by mala byť implementácia rozdelená do niekoľkých etáp tak, aby na konci každej etapy mal vývojový tím pripravený produkt na dodanie. Zároveň by mala byť najdôležitejšia, základná funkcionalita vyvinutá v počiatočnom štádiu a doplnky, ktoré fungujú nad týmito základnými komponentmi, by mali byť implementované neskôr. V tomto prípade budú v prvých fázach opravené pre systém najnebezpečnejšie chyby a výrazne sa zníži riziko, že aplikačná funkčnosť systému bude založená na nestabilnom základe.
Po dodaní kompletne dokončeného systému sa softvérový projekt na zákazku zvyčajne posúva do fázy beta. Účelom tejto etapy je preveriť kvalitu vyvinutého systému v reálnych prevádzkových podmienkach. Spravidla v tejto fáze vykonávateľ spolu so zákazníkom meria kvantitatívne metriky, ktoré umožňujú určiť kvalitu vytvoreného systému. V prvom rade sa kontrolujú funkčné vlastnosti kvality, potom nefunkčné. Ak sa vyskytnú nezrovnalosti, interpret opraví systémový kód.

Do komerčnej prevádzky je uvedený plne odladený a vyladený systém. Dodávateľ musí spravidla systém sprevádzať minimálne počas záručnej doby. Zistené nezrovnalosti by sa mali opraviť. Používatelia a pracovníci zákazníckeho servisu by mali dostať rýchlu poradenskú podporu.

Konečne prichádza moment, kedy systém prestane zákazníkovi z akéhokoľvek dôvodu vyhovovať. Systém je teraz v procese vyraďovania z prevádzky. V prípade softvéru na zákazku však táto fáza nie je vždy relevantná, pretože zákazník môže využiť svoje výhradné práva na systém a odvolať dodávateľa z ďalšej údržby a vývoja systému ešte skôr, ako sa to stane irelevantným.

Každý projekt sa nakoniec skončí. Fáza ukončenia projektu má za cieľ analyzovať výsledky, vykonať zmeny vo vývojovom procese na základe získaných skúseností a doplniť vedomostnú základňu vývojárov o nové efektívne riešenia a upozornenia, ako aj o nové bežne dostupné komponenty, ktoré možno použiť v budúcich projektov.

Zostáva poznamenať dve ďalšie fázy procesu vývoja. Stáva sa, že okolnosti nedovoľujú pokračovať v realizácii projektu, ale výsledky vykonanej práce ukazujú, že projekt môže mať budúcnosť. Uzavrieť takýto projekt je predčasné. Preto namiesto úplného zastavenia prác môže dodávateľ dočasne pozastaviť projektové aktivity a opraviť dosiahnuté výsledky. Hneď ako to okolnosti dovolia, projekt môže byť obnovený prestavbou infraštruktúry, vrátením vývojárov do projektu a obnovením stavu projektu. Je však dôležité obnoviť prácu od bodu, v ktorom bol projekt prerušený, opätovným auditom dosiahnutých výsledkov.

Proces vývoja investičného softvéru

Proces vývoja investičného softvéru je odlišný v tom, že práca môže prebiehať súčasne na niekoľkých verziách produktu naraz: zatiaľ čo prvá verzia sa udržiava, druhá sa už implementuje a formulujú sa požiadavky na tretiu. Proces je znázornený na obrázku 2.

Obrázok 2. Proces vývoja investičného softvéru.

Ako je ľahké vidieť, pri vývoji investičného softvéru prebiehajú rovnaké fázy, o ktorých sa hovorilo vyššie pri procese vývoja softvéru na zákazku. Rozdiel je však v tom, že etapy sa nevzťahujú na celý produkt, ale na samostatnú verziu produktu. Výnimkou je fáza ukončenia projektu: projekt nemožno dokončiť, kým sa pracuje aspoň na jednej verzii produktu.

Venujte pozornosť začiatku práce na ďalšej verzii produktu. Tento moment nastáva hneď, ako je ukončená fáza tvorby architektúry aktuálnej vývojovej verzie. Predtým sa v požiadavkách a fázach architektúry zvyčajne diskutuje o tom, ktoré funkcie by sa mali implementovať v aktuálnej verzii a ktoré by sa mali presunúť do budúcnosti. A až keď sú požiadavky na aktuálnu verziu sformulované, skontrolované a potvrdené architektúrou systému, má zmysel uvažovať o ďalšej verzii.

Okrem toho po vývoji architektúry majú analytici a architekti projektu spravidla určitú slobodu konania, pretože hlavné bremeno padá na programátorov počas fáz dodávky. Túto slobodu možno využiť na vypracovanie koncepcie a požiadaviek na ďalšiu verziu.

V zásade môžete začiatok prác na ďalšej verzii odložiť na neskorší dátum. Napríklad je celkom prijateľné najskôr uviesť aktuálnu verziu do experimentálnej alebo aj komerčnej prevádzky a až potom začať pracovať na ďalšej verzii. Musíte si však uvedomiť, že takéto riešenie nie je použiteľné v prípade vysokej konkurencie: jednoducho vás predbehnú a vytlačia vás z trhu. Rozhodnutie musí byť urobené na základe celého radu okolností, ktoré ovplyvňujú vaše podnikanie.

Keď už hovoríme o procese vývoja investičného softvéru, musíte pochopiť, že práca na niekoľkých verziách má množstvo explicitných a skrytých vzájomných závislostí medzi paralelnými vetvami procesu.

Po prvé, opravy nezrovnalostí identifikovaných v staršej verzii sa musia vykonať vo verzii, v ktorej boli objavené, a vo všetkých neskorších verziách vrátane tých, ktoré sú vo vývoji. To platí nielen pre programový kód, ale aj pre všetky ostatné artefakty projektu: technickú a užívateľskú dokumentáciu, systém pomoci, odhady a pracovné plány atď. Okrem toho musia byť opravy vykonané okamžite, pretože nebudete môcť znížiť náklady na opravy, ale ak sa opravy nevykonajú okamžite, ich náklady v neskorších fázach sa môžu zvýšiť desaťkrát alebo dokonca stokrát.

Po druhé, pre paralelnú prácu na niekoľkých verziách je potrebná špeciálna projektová infraštruktúra vrátane organizácie správy verzií kódu a dokumentácie, kontroly úloh a nekonzistentnosti, automatických nástrojov na zostavovanie a testovanie atď. Práca na jednej verzii produktu by nemala blokovať vykonávanie úloh na iných verziách len preto, že infraštruktúra projektu neumožňuje spustenie dvoch procesov zostavovania súčasne pre rôzne verzie produktu.

Osobitná pozornosť by sa mala venovať testovacím zariadeniam: mali by nasadiť všetky verzie produktu, ktoré boli vydané skôr (aspoň tie verzie, ktoré sú podporované) a všetky verzie, ktoré sa v súčasnosti vyvíjajú.

Po tretie, tí istí účastníci môžu byť zapojení do práce na niekoľkých verziách súčasne. Existuje vysoké riziko, že kľúčová osoba môže uviaznuť pri práci na jednej verzii programu a pri úlohách súvisiacich s inou verziou môže dôjsť k výraznému prekročeniu času.

Po štvrté, existuje opačná situácia, keď pracovníci pracujúci na jednej verzii nevedia nič o tom, aké rozhodnutia sa prijímajú v rámci práce na druhej verzii. Časť problému je odstránená, ak sú opravy všetkej dokumentácie a kódu okamžite distribuované do všetkých neskorších verzií, ako som uviedol vyššie. Táto záležitosť by sa však nemala obmedzovať len na opravy. Je potrebné, aby tím pracujúci na jednej verzii chápal, prečo boli prijaté určité rozhodnutia pri práci na inej verzii. To si vyžaduje vedomostnú bázu pre vývojárov – špeciálny informačný systém, ktorý by mal popisovať všetky problémy, s ktorými sa vývojári stretli pri práci na konkrétnej verzii produktu, a ako tieto problémy riešiť. Znalostná báza by mala posielať upozornenia všetkým účastníkom projektu, keď prídu nové záznamy. Je nemožné nechať voľný priebeh interakcie dvoch tímov pracujúcich na rôznych verziách toho istého produktu.

Proces vývoja vstavaného softvéru

Ako je uvedené vyššie, vstavaný softvér sa líši od vlastného softvéru v tom, že je mimoriadne náročný na údržbu.

Povedzme, že uvoľníte softvér pre chladničky. Po doručení softvéru výrobcovi sa po svete začnú rozchádzať desaťtisíce zariadení a vy netušíte, kde skončia. A ak jedna z chladničiek zlyhá v dôsledku chyby vášho softvéru, potom je jednoduchšie zaplatiť pokutu, ako vrátiť chladničku do továrne a vykonať diagnostiku. Samozrejme, je možné vyškoliť inžinierov pre predajcov, ktorí dokážu vykonať diagnostiku na mieste a vymeniť firmvér vášho systému, ale stále je to veľmi drahé.

Pri vývoji vstavaného softvéru teda vzniká niekoľko dôležitých obmedzení naraz.

Po prvé, dodávka sa uskutočňuje iba v rámci jednej etapy: nikto do zariadení nezabuduje polovičný pracovný program.

Po druhé, pri dodaní musíte venovať osobitnú pozornosť kvalite programu, pretože od chvíle, keď je vložený do žehličky, bude veľmi ťažké ho zmeniť. Osobitná pozornosť by sa mala venovať fáze pilotnej prevádzky, kedy je program implementovaný v obmedzenom množstve zariadení a tieto zariadenia prechádzajú komplexnými testami v rôznych prevádzkových režimoch. Musíte zhromaždiť čo najviac informácií o správaní vášho systému, analyzovať tieto informácie a vylepšiť softvér.

Po tretie, keď sa zariadenie s vaším softvérom dostane do série, máte veľmi malú príležitosť opraviť chyby. V skutočnosti sú takéto opravy možné iba v prípade chybného softvéru, ktorý vedie k nefunkčnosti celej šarže zariadení, kvôli čomu bude výrobca nútený túto šaržu stiahnuť a vy tak získate veľkú čiernu škvrnu na vašej reputácii. .

Napokon, po štvrté, pre vstavaný softvér neexistuje žiadna etapa vyraďovania z prevádzky. Program sa jednoducho vyhodí spolu so zariadením. Preto, hneď ako uplynie záručná doba pre dávku zariadení, na ktorých beží váš softvér, môžete projekt ukončiť.

Proces vývoja firmvéru je znázornený na obrázku 3.

Obrázok 3 Proces vývoja vstavaného softvéru.

Proces vývoja hry

Herný softvér som vyčlenil vzhľadom na špecifiká ich výroby a prevádzky. Herný softvérový biznis je založený na vydávaní hitov. Jeden úspešný zásah zaplatí náklady na vytvorenie niekoľkých hier, ktoré si používatelia nevšimnú. Preto je proces vývoja jednej hry prepojený s procesmi vývoja iných hier.

Ďalším faktorom, vďaka ktorému vyniká herná produkcia, je fakt, že hra je pre používateľa zaujímavá buď dovtedy, kým neprejde posledným levelom, alebo kým nemá fatálnu chybu. To znamená, že si druhú verziu hry nekúpi a ani si ju nestiahne zadarmo, len aby opravil pár chýb.

Tieto faktory ovplyvňujú proces vývoja herného softvéru. Proces je znázornený na obrázku 4.

Obrázok 4. Proces vývoja herného softvéru.

Mali by ste si všimnúť nasledujúce vlastnosti procesu vývoja herného softvéru.

V prvom rade je pri výrobe hier mimoriadne dôležitá kvalita konceptu. Ak vám koncept hry neumožňuje vytvoriť hit, ďalšia práca je zbytočná. Pre vývoj herného softvéru je typická situácia, keď väčšina projektov končí v prípravnej fáze.

Požiadavky a vývoj architektúry pre herný softvér často opätovne využívajú poznatky získané z predchádzajúcich projektov. V tomto ohľade dostáva dodatočnú váhu aj fáza ukončenia projektu, keď všetky užitočné zmeny musia byť zaznamenané v znalostnej báze vývojárov.

Dodanie herného softvéru prebieha v rámci jednej etapy. Aj keď sa najprv vytvorí určité jadro, „motor“ herného systému, jeho fungovanie nie je možné overiť bez implementácie celej funkcionality systému.

Pre herný softvér neexistujú žiadne beta verzie ani fázy vyraďovania z prevádzky. Hry idú okamžite do predaja a po použití ich používateľ jednoducho vymaže, keďže o ne stratí záujem.

Záver

V rámci článku som sa pokúsil podať prehľad „top levelu“ procesu vývoja aplikačného softvéru. Každá fáza procesu si samozrejme vyžaduje samostatnú diskusiu s povinným zvážením vlastností vyvíjaného softvéru.

Podotýkam, že procesný diagram, o ktorom sa tu uvažuje, je výsledkom zovšeobecnenia mojich osobných skúseností s vývojom rôznych softvérových nástrojov. Ako každé zovšeobecnenie, aj moja schéma je abstrakciou. A ako každá abstrakcia má svoje hranice použiteľnosti. Túto schému nemôžete bezmyšlienkovite použiť na konkrétny projekt. Je dôležité pochopiť, že každý projekt má svoje vlastné nuansy, ktoré ovplyvňujú organizáciu vývojového procesu. Preto je potrebné pre každý projekt prispôsobiť tu prezentovanú schému av niektorých prípadoch bude potrebné vyvinúť zásadne odlišný prístup.

softvérový manažment

Proces vývoja softvéru predstavuje množstvo rôznych činností, metód, techník a krokov používaných na vývoj a vývoj softvéru a súvisiacich produktov (plány projektu, dokumentácia, kód, testy, užívateľská dokumentácia).

V súčasnosti však neexistuje univerzálny proces vývoja softvéru – súbor metód, pravidiel a predpisov vhodných pre softvér akéhokoľvek druhu, pre akúkoľvek spoločnosť, pre tímy akejkoľvek národnosti. Každý súčasný vývojový proces realizovaný určitým tímom v rámci určitého projektu má veľké množstvo vlastností a individualít. Pred začatím projektu je však vhodné naplánovať si pracovný proces, zadefinovať si úlohy a zodpovednosti v tíme, pracovné produkty (stredné a konečné), poradie účasti na ich rozvoji členov tímu a pod.

Proces vývoja softvéru nie je homogénny. Jedna alebo druhá metóda vývoja softvéru spravidla určuje určitú dynamiku nasadenia určitých typov činností, to znamená, že určuje model procesu.

Model je dobrou abstrakciou rôznych metód vývoja softvéru, čo umožňuje ich stručnú, výstižnú a informatívnu prezentáciu. Samotná myšlienka procesného modelu je však jednou z prvých v softvérovom inžinierstve, keď sa verilo, že úspešný model je najdôležitejšou vecou, ktorá prispieva k úspechu vývoja. Neskôr sa zistilo, že existuje mnoho ďalších aspektov (napr. princípy riadenia a rozvoja, štruktúra tímu), ktoré by mali byť definované vo vzájomnom súlade. A začali sa rozvíjať integrované metodiky rozvoja. Existuje však niekoľko klasických modelov procesu vývoja softvéru.

Prvý model, ktorý sa stal všeobecne známym a skutočne štruktúruje proces vývoja, je kaskáda alebo vodopád. Vznikol po konferencii NATO o vede a technike v roku 1968, ktorá sa zaoberala takýmito otázkami, a rozdeľuje proces tvorby softvérového produktu na postupné etapy (treba podotknúť, že ho už používali rôzni vývojári, ale ani počet, ani obsah etáp zjednotený).

Obrázok 1 - Modifikovaný model vývoja softvéru Waterfall

Upravený kaskádový model poskytoval možnosť návratu k predchádzajúcim etapám.

Model vodopádu bol krátko po jeho objavení finalizovaný Winst Royce, pričom zohľadnil vzájomnú závislosť etáp a potrebu návratu k predchádzajúcim stupňom, čo môže byť spôsobené napríklad neúplnými požiadavkami alebo chybami pri zostavovaní úloha. V tejto „reverzibilnej“ forme vodopádový model existoval už dlho a bol základom mnohých projektov (obrázok 1).

Praktické využitie tohto modelu však odhalilo mnohé jeho nedostatky, z ktorých hlavným bolo, že je vhodnejší pre tradičné typy inžinierskych činností ako pre vývoj softvéru. Najmä jedným z najväčších problémov bola jeho „predispozícia“ na prípadné nezrovnalosti medzi výsledným produktom a požiadavkami, ktoré naň boli kladené. Hlavným dôvodom je to, že úplne vytvorený produkt sa objavuje až v neskorších fázach vývoja, ale keďže prácu v rôznych fázach zvyčajne vykonávali rôzni špecialisti a projekt sa presúval z jednej skupiny do druhej, potom podľa princípe poškodeného telefónu sa ukázalo, že výstup nebol celkom taký, ako bol pôvodne zamýšľaný.

Aby sa eliminovali nedostatky vodopádového modelu, bol navrhnutý V-tvarovaný, čiže kĺbový model vývoja softvéru (obrázok 2).

Obrázok 2 - Model vývoja softvéru v tvare V

Model v tvare V umožňuje oveľa väčšiu kontrolu nad výsledkom z hľadiska jeho súladu s očakávaniami, keďže je zameraný na testovanie.

Model v tvare V umožnil výrazne zlepšiť kvalitu softvéru vďaka jeho zameraniu na testovanie a tiež do značnej miery vyriešil problém súladu vytvoreného produktu s požiadavkami kladenými v dôsledku overovacích a certifikačných postupov v počiatočných fázach. vývoja (prerušované čiary na obrázku označujú závislosť úloh fázy plánovania / nastavenia a testovania / akceptácie).

Vo všeobecnosti je však model v tvare V len modifikáciou kaskádového modelu a má veľa svojich nedostatkov. Obe sú najmä zle prispôsobené prípadným zmenám požiadaviek zákazníkov. Ak proces vývoja trvá dlho (niekedy až niekoľko rokov), potom môže byť výsledný produkt pre zákazníka v skutočnosti nepotrebný, keďže jeho potreby sa výrazne zmenili.

Softvér, na rozdiel napríklad od mikročipu, je možné uvádzať do prevádzky po častiach, čo znamená, že je možné ho aj postupne vyvíjať a dodávať zákazníkovi. Toto je základom inkrementálneho modelu, ktorý zabezpečuje fragmentáciu produktu na relatívne nezávislé komponenty, ktoré sa vyvíjajú a uvádzajú do prevádzky samostatne.

Tento model je výhodný pre zákazníka aj tvorcu systému, pretože umožňuje napredovať, rešpektujúc záujmy oboch strán.

Má však svoje nedostatky. Rozdelenie na funkčné bloky ako celok spomaľuje proces, pretože je potrebné zabezpečiť ich interakciu. Pre mnohé riešenia je tento spôsob nepoužiteľný, keďže z nich nie je možné oddeliť jednotlivé komponenty, ktoré je možné dodať a fungovať samostatne. Výrazne narastá aj záťaž riadiaceho personálu z dôvodu komplikovanosti úloh koordinácie prác na jednotlivých komponentoch systému, zvyšujú sa náklady na vykonávanie zmien hotových komponentov, ktoré sú už nainštalované a pracujú u zákazníka.

Špirálový model, ktorý navrhol Barry Boehm v roku 1988, bol významným prelomom v chápaní podstaty vývoja softvéru, hoci kombinuje vodopádový prístup a iteračný proces navrhovania založený na prototypovaní (obrázok 3).

Ryža. 3.

Boehmov špirálový model je zameraný na dizajn, vývoj softvéru je len posledným otočením špirály obvyklého vodopádového modelu, ktorému však predchádza niekoľko iterácií dizajnu založených na prototypovaní – pričom každá iterácia zahŕňa štádium identifikácie a analýzy rizík a najťažšie úlohy.

Keďže špirálový model pokrýva predovšetkým dizajn, vo svojej pôvodnej podobe nebol široko používaný ako metóda riadenia celého životného cyklu vývoja softvéru. Jej hlavná myšlienka, ktorá spočíva v tom, že proces práce na projekte môže pozostávať z cyklov, ktoré prechádzajú rovnakými fázami, však poslúžila ako východisko pre ďalší výskum a stala sa základom najmodernejších modelov procesu vývoja softvéru.

Iteračný model, ktorý prvýkrát navrhol Philip Krachten v roku 1995, kombinuje hlavné výhody špirálových, prírastkových, vodopádových modelov, ako aj vývojové metódy založené na prototypovaní a objektovo orientovanom prístupe (obrázok 4). Získal si veľkú obľubu a v tej či onej forme sa používa v mnohých moderných projektoch.

Obrázok 4 - Iteračný model vývoja softvéru

Podľa iteratívneho modelu existujú štyri hlavné fázy životného cyklu vývoja softvéru (spustenie, výskum, zostavenie a nasadenie). V každej fáze projekt prechádza mnohými iteráciami, ktoré vedú k vytvoreniu funkčných verzií: v počiatočných fázach sa vytvárajú prototypy, špecifikujú sa požiadavky a riešia sa najzložitejšie problémy; finále vedie k vytvoreniu produktu, jeho zdokonaleniu a rozšíreniu funkčnosti.

Iteračný model okrem hlavných fáz rozlišuje ešte dve skupiny procesov: pracovné (riadenie požiadaviek, analýza a návrh, implementácia, testovanie, nasadenie) a pomocné (riadenie konfigurácie a zmien, projekt a proces). Počet a charakter procesov sa líši v závislosti od potrieb vývojára, môžu mať aj svoje cykly, ktoré ani nemusia zodpovedať hlavným fázam. Výsledkom pracovných postupov však vždy je vytváranie verzií produktov.

Iteračný model, podobne ako špirálový model, umožňuje úspešne riadiť riziká. Ak sa počas práce na ďalšej verzii zistí, že mzdové náklady na implementáciu požadovanej funkcionality sú príliš vysoké, potom sa možno vyhnúť prekročeniu rozpočtu a termínom koreláciou priorít vývoja a mzdových nákladov na začiatku každej iterácie. Tento model je teda vhodný pre väčšinu typov softvérových projektov, ale jeho výhody sú badateľné najmä pri práci na produktoch určených pre vstup na voľný trh, vzhľadom na počiatočné zameranie na vydávanie následných verzií.

Za najznámejší a najuznávanejší štandard kvality treba považovať Capability Maturity Model (CMM) – model na hodnotenie úrovne vyspelosti vývojových procesov spolu s jeho derivátmi. Vytvoril ho SEI (Inštitút softvérového inžinierstva), ktorý je financovaný Ministerstvom obrany USA a je štrukturálnou jednotkou Carnegie Mellon University. Prvá oficiálna verzia normy bola vydaná v roku 1993, hoci práca na nej začala oveľa skôr - jej hlavné ustanovenia boli zverejnené už v roku 1986. Úspech CMM bol predurčený viacerými faktormi. Tento štandard bol jedným z prvých, ktorý od začiatku zohľadňoval špecifiká vývoja softvéru. Ukázalo sa, že je to celkom jednoduché a transparentné na pochopenie aj na použitie a reguluje „čo“ a nie „ako“ robiť, a preto bolo vhodné pre rôzne modely životného cyklu, metodiky vývoja a neukladalo žiadne obmedzenia na dokumentáciu. štandardy, nástroje, prostredie a jazyky používané v projektoch. A možno hlavným faktorom, ktorý predurčil obľúbenosť CMM, bola spolupráca SEI s Ministerstvom obrany USA, čo de facto znamenalo využitie štandardu pri realizácii projektov zadávaných týmto rezortom.

Model CMM (tabuľka 1) poskytuje päť úrovní zrelosti, z ktorých každá zodpovedá určitým kľúčovým procesným oblastiam (Key Process Areas, KPA).

Tabuľka 1 - HMM model

Názov úrovne	Kľúčové oblasti procesov
1 - Počiatočné	Ak je organizácia na tejto úrovni, potom pre ňu neexistujú žiadne kľúčové oblasti procesov
2 - Opakujúce sa	Správa konfigurácie softvéru. Zabezpečenie kvality softvérových produktov. Správa zmlúv dodávateľov. Kontrola priebehu projektu. Plánovanie softvérových projektov. Riadenie požiadaviek
3 - Definované	Odborné posudky. Koordinácia interakcií medzi projektovými tímami. Inžinierstvo softvérových produktov. Integrovaná správa softvéru. Program školenia zamestnancov. Definícia organizačného procesu. Rozsah organizačného procesu
4 - Riadené	Riadenie kvality softvéru. Riadenie procesu založené na kvantitatívnych metódach
5 - Optimalizované	Riadenie zmeny procesov. Riadenie technologických zmien. Prevencia defektov

Rozdelenie do úrovní a definícia KPA pre každú z nich umožňuje dôslednú implementáciu CMM s využitím štandardu ako vodidla, čo môže zabezpečiť neustále zlepšovanie v procese vývoja.

Štandard CMM sa ukázal ako veľmi úspešný a následne na jeho základe bola vytvorená celá séria štandardov a dostala nový názov - SW-CMM (Capability Maturity Model for Software), ktorý presnejšie odráža jeho postavenie v pomerne veľkom rodina noriem.

Praktická aplikácia štandardov série CMM však ukázala, že nezabezpečujú bezpodmienečný úspech vo vývoji softvéru. Tieto štandardy neboli navzájom dobre koordinované - súčasná implementácia rôznych modifikácií CMM mohla byť dosť náročná a viedla k zmätku špecialistov organizácií, ktoré tomu čelili.

Taktiež významným problémom CMM je potreba „zosúladiť“ všetky procesy. Ak sa organizácia pokúša certifikovať na určitú úroveň, potom musí zabezpečiť, aby sa na všetky jej procesy uplatnila vhodná úroveň. Aj keď špecifiká, metodika alebo vývojové prvky nemajú určité procesy, ktoré sa majú vykonať, certifikácia si to vyžaduje.

Ďalší problém spôsobuje pozícia, ktorú štandardy CMM zaujali v modernom softvérovom priemysle. Keďže organizácia s vysokou úrovňou v súlade s CMM musí poskytovať vyššiu výkonnosť softvérových produktov ako organizácie s certifikáciou na nižších úrovniach, norma sa začala používať ako výberové kritérium pre účasť v tendroch na vývoj softvéru alebo v projektoch outsourcingu.

Táto situácia je možná v dôsledku nedostatkov certifikačného procesu. Certifikácii nepodlieha celá organizácia ako celok, ale len konkrétny projekt. Nič nebráni tomu, aby organizácia vytvorila „demonštratívny“ projekt, ktorý spĺňa všetky požiadavky vysokých úrovní normy CMM, získa príslušný stupeň certifikácie a deklaruje, že všetky produkty spĺňajú takú a takú úroveň normy.

Nový štandard SEI – Capability Maturity Model Integrated (CMMI) – je integrovaným modelom na hodnotenie úrovne vyspelosti vývojových procesov. Štandard CMMI bol pôvodne vytvorený tak, aby spájal existujúce možnosti CMM a eliminoval prípadné rozpory pri jeho praktickom použití v rôznych oblastiach činnosti high-tech spoločností.

Aby sa eliminovala potreba „zosúladiť“ procesy organizácie a viac sa prispôsobiť jej biznis potrebám, a nie naopak, má štandard CMMI dve formy prezentácie – klasickú, viacúrovňovú, zodpovedajúcu CMM, a nové, nepretržité. Priebežná forma prezentácie nezohľadňuje stupne vyspelosti (Maturity Levels), ale Capability Levels, ktoré sa hodnotia pre jednotlivé procesné oblasti (Process Areas, PA).

Tabuľka 2 poskytuje mapovanie úrovní vyspelosti štandardu CMM, ako aj úrovní vyspelosti vrstvenej prezentácie CMMI a úrovní spôsobilosti nepretržitej prezentácie CMMI.

Tabuľka 2 – Súlad s úrovňami vyspelosti noriem CMM, CMMI

SEI sa vzďaľuje od CMM a na oplátku aktívne podporuje CMMI, pričom sľubuje sprísnenie kontroly nad certifikačným procesom, zníženie nákladov a jeho zatraktívnenie pre malé organizácie; zabezpečenie kompatibility s normami ISO.

V moderných podmienkach nie je prítomnosť certifikátu určitej úrovne CMM / CMMI takým významným faktorom ako pred niekoľkými rokmi a je akceptovaná bez ďalších otázok, snáď s výnimkou projektov realizovaných na základe nariadenia vlády.

Norma ISO/IEC 15504 je určená na hodnotenie procesu vývoja informačných systémov, najmä softvéru. Pôvodne bol navrhnutý tak, aby bol do značnej miery v súlade s priemyselnými štandardmi na hodnotenie procesu vývoja softvéru. Práve táto požiadavka určila podobnosť normy so základnými princípmi CMM / CMMI.

Model zrelosti procesu vývoja softvéru (CMM) vyvinutý Inštitútom softvérového inžinierstva na Carnegie Mellon University navrhuje päť úrovní zrelosti (tabuľka 3). Pomáha organizáciám zvýšiť vyspelosť ich procesov vývoja softvéru a organizácie môžu byť hodnotené a akreditované podľa týchto úrovní.

Tabuľka 3 - Úrovne zrelosti vývoja softvéru

Úroveň 1 - vstupná úroveň	Proces vývoja softvéru je spontánny a iba niekoľko procesov je regulovaných. Úspech vývoja môže závisieť od jednotlivých zamestnancov.
Úroveň 2 - úroveň opakovateľnosti	Vytvorené základné procesy projektového manažmentu na sledovanie nákladov, harmonogramu a funkčnosti.
Úroveň 3 - úroveň regulácie	Proces vývoja softvéru je zdokumentovaný, štandardizovaný a integrovaný so štandardným procesom vývoja softvéru organizácie pre riadenie aj vývojové operácie. Všetky projekty využívajú štandardizovaný proces.
Úroveň 4 – úroveň ovládateľnosti	Zhromažďujú sa podrobné metriky procesu vývoja softvéru a kvality produktu, aby pomohli pochopiť a riadiť proces a produkty.
Úroveň 5 - úroveň optimalizácie	Priebežná optimalizácia procesov je zabezpečená kvantitatívnou spätnou väzbou z procesu az pilotných inovatívnych nápadov a technológií.

Moderné modely a metódy používané v skutočných projektoch vývoja softvéru sú teda veľmi rôznorodé. Každý z nich má svoje výhody, ktoré sa prejavujú vo vhodných podmienkach. Dokonca aj zastaraný model vodopádu je pre niektoré projekty úplne postačujúci. Každý proces má tiež množstvo charakteristík, ktoré obmedzujú oblasť jeho efektívneho využitia. Táto situácia je celkom typická pre vývoj softvéru, kde sa už nahromadilo veľa technológií a techník, ale neexistuje univerzálna metóda, ktorá by bola optimálna pre akúkoľvek úlohu.

S. Archipenkov

Modely (alebo, ako sa radi hovorí, metodológie) procesov vývoja softvéru sú zvyčajne klasifikované podľa "váhy" - počtu formalizovaných procesov (väčšina procesov alebo len tých hlavných) a podrobnosti ich regulácie. Čím viac procesov je zdokumentovaných, čím podrobnejšie sú opísané, tým väčšia je „váha“ modelu.

Najbežnejšie moderné modely procesov vývoja softvéru sú znázornené na obrázku 3.

Obrázok 3 Rôzne modely procesu vývoja softvéru a ich rozdelenie podľa "váhy"

GOST

SW-CMM

Tento model definuje päť úrovní zrelosti procesu vývoja softvéru.

Počiatočné - proces vývoja je chaotický. Len málo procesov je definovaných a úspech projektov závisí od jednotlivých aktérov.
Opakovateľné – zavedené základné procesy riadenia projektu: sledovanie nákladov, termínov a funkčnosti. Niektoré z procesov potrebných na zopakovanie predchádzajúcich úspechov na podobných projektoch sa zjednodušili.
Definované - procesy vývoja softvéru a projektového manažmentu sú popísané a implementované v jednotnom systéme firemných procesov. Všetky projekty využívajú štandardný proces vývoja softvéru a podpory organizácie, prispôsobený konkrétnemu projektu.
Riadené – zhromažďuje podrobné kvantitatívne údaje o fungovaní vývojových procesov a kvalite finálneho produktu. Analyzuje sa význam a dynamika týchto údajov.
Optimalizovateľné – neustále zlepšovanie procesov je založené na kvantitatívnych údajoch o procesoch a na skúšobnej implementácii nových nápadov a technológií.

RUP

Lekári bez hraníc

PSP/TSP

Jeden z najnovších vývojov Inštitútu softvérového inžinierstva Osobný softvérový proces / tímový softvérový proces [ , ]. Proces osobného softvéru definuje požiadavky na kompetenciu vývojára. Podľa tohto modelu by mal byť každý programátor schopný:

vziať do úvahy čas strávený na projekte;
vziať do úvahy zistené nedostatky;
klasifikovať typy defektov;
odhadnúť veľkosť úlohy;
implementovať systematický prístup k opisu výsledkov testov;
plánovať programové úlohy;
rozložiť ich v čase a zostaviť harmonogram prác.
vykonávať individuálne hodnotenia dizajnu a architektúry;
vykonať individuálne overenie kódu;
vykonať regresné testovanie.

Team Software Process sa spolieha na samostatne spravované tímy 3-20 vývojárov. Tímy musia:

stanovte si vlastné ciele;
rozvíjať svoj proces a plány;
traťová práca;
udržať motiváciu a špičkový výkon.

Dôsledná aplikácia modelu PSP / TSP vám umožňuje urobiť z piatej úrovne CMM normu v organizácii.

Agilný

Výber modelu procesu

Ťažké a ľahké modely výrobného procesu majú svoje výhody a nevýhody (tab. 1).

Tabuľka 1. Výhody a nevýhody ťažkých a ľahkých modelov procesov vývoja softvéru

Hmotnosť modelu	klady	Mínusy
ťažký	Procesy sú navrhnuté pre priemernú kvalifikáciu účinkujúcich. Veľká špecializácia interpretov. Nižšie sú uvedené požiadavky na stabilitu tímu. Neexistujú žiadne obmedzenia týkajúce sa objemu a zložitosti prebiehajúcich projektov.	Vyžaduje značné náklady na riadenie. Dlhšie fázy analýzy a návrhu. Formálnejšia komunikácia.
Pľúca	Menšia réžia spojená s riadením projektu, rizikami, zmenami, konfiguráciami. Zjednodušené fázy analýzy a dizajnu, hlavné zameranie na vývoj funkčnosti, kombinácia rolí. neformálna komunikácia.	Efektivita vo veľkej miere závisí od individuálnych schopností, čo si vyžaduje kvalifikovanejší, všestrannejší a stabilnejší tím. Rozsah a zložitosť prebiehajúcich projektov sú obmedzené.

Hmotnosť modelu

klady

Mínusy

ťažký

Procesy sú navrhnuté pre priemernú kvalifikáciu účinkujúcich. Veľká špecializácia interpretov. Nižšie sú uvedené požiadavky na stabilitu tímu.

Neexistujú žiadne obmedzenia týkajúce sa objemu a zložitosti prebiehajúcich projektov.

Vyžaduje značné náklady na riadenie.

Dlhšie fázy analýzy a návrhu.

Formálnejšia komunikácia.

Pľúca

Menšia réžia spojená s riadením projektu, rizikami, zmenami, konfiguráciami.

Zjednodušené fázy analýzy a dizajnu, hlavné zameranie na vývoj funkčnosti, kombinácia rolí. neformálna komunikácia.

Efektivita vo veľkej miere závisí od individuálnych schopností, čo si vyžaduje kvalifikovanejší, všestrannejší a stabilnejší tím.

Rozsah a zložitosť prebiehajúcich projektov sú obmedzené.

Tí, ktorí sa snažia nasledovať modely opísané v knihách, bez toho, aby analyzovali ich použiteľnosť v konkrétnej situácii, indikácie a kontraindikácie, sú prirovnávaní k vyznávačom kultu Cargo - náboženstva uctievačov lietadiel. V Melanézii veria, že západný tovar (cargo, anglicky cargo) je vytvorený duchmi predkov a je určený pre melanézsky ľud. Verí sa, že bieli ľudia nečestne získali kontrolu nad týmito predmetmi. Najznámejšie kulty nákladu stavajú repliky pristávacích dráh, letísk a rádiových veží z kokosových paliem a slamy. Členovia kultu ich budujú vo viere, že tieto stavby pritiahnu dopravné lietadlá (považované za poslov duchov) naplnené nákladom (nákladom). Veriaci pravidelne vedú vojenské cvičenia („drill“) a akési vojenské pochody, pričom namiesto pušiek používajú konáre a kreslia na telo rádu a nápis „USA“. To všetko preto, aby z neba opäť padali lietadlá a týchto predmetov bolo viac.

Alistair Cowburn, jeden z autorov „Manifestu agilného vývoja softvéru“ analyzoval za posledných 20 rokov veľmi odlišné softvérové projekty, ktoré boli realizované podľa rôznych modelov od úplne ľahkých a „agilných“ až po ťažké (CMM-5) [ , ]. Nezistil žiadnu súvislosť medzi úspechom alebo neúspechom projektov a modelmi procesov vývoja, ktoré boli v projektoch použité. Z toho dospel k záveru, že efektívnosť vývoja softvéru nezávisí od modelu procesu a tiež, že:

Každý projekt by mal mať svoj vlastný model procesu vývoja.
Každý model má svoj čas.

To znamená, že neexistuje jediný správny proces vývoja softvéru, v každom novom projekte musí byť proces definovaný zakaždým nanovo, v závislosti od projektu, produktu a personálu, v súlade so „Zákonom 4 P“ (obrázok 4). Úplne iné procesy by sa mali uplatňovať v projektoch s 5 ľuďmi a projektoch s 500 ľuďmi. Ak je produktom projektu kritický softvér, napríklad riadiaci systém pre jadrovú elektráreň, potom by sa vývojový proces mal veľmi líšiť od vývoja napríklad stránky „otdokhni.ru“. A napokon, proces vývoja by mal byť organizovaný inak v tíme včerajších študentov a v tíme skúsených odborníkov.

Obrázok 4. "Zákon 4 P". Proces v projekte by mal byť definovaný v závislosti od projektu, produktu a personálu

Čo je potrebné urobiť pre úspech softvérového projektu

Steve McConnell vo svojej knihe testuje softvérový projekt na prežitie. Ide o 33-bodový kontrolný zoznam, ktorý považujem za potrebné citovať s menšími úpravami. Manažér softvérového projektu by ho mal pravidelne používať na interné audity svojich procesov.

Aby bol softvérový projekt úspešný, musíte:

Jasne stanovené ciele.
Určiť, ako dosiahnuť ciele.
Kontrolovať a riadiť implementáciu.
Analyzujte hrozby a bojujte proti nim.
Vytvorte tím.

Stanovili sme si ciele
1.1. Koncept definuje jasné, jednoznačné ciele.
1.2. Všetci členovia tímu považujú koncept za realistický.
1.3. Projekt má zdôvodnenie ekonomickej efektívnosti.
1.4. Bol vyvinutý prototyp používateľského rozhrania.
1.5. Bola vyvinutá špecifikácia cieľových funkcií softvérového produktu.
1.6. Bola nadviazaná obojsmerná komunikácia s koncovými používateľmi produktu
Určiť, ako dosiahnuť ciele
2.1. Existuje podrobný písomný plán vývoja produktu.
2.2. V zozname projektových úloh sú zahrnuté „drobné“ úlohy (správa konfigurácie, konverzia dát, integrácia s inými systémami).
2.3. Po každej fáze projektu sa aktualizuje harmonogram a rozpočet.
2.4. Rozhodnutia o architektúre a dizajne sú zdokumentované.
2.5. Existuje plán zabezpečenia kvality, ktorý definuje testovanie a kontrolu.
2.6. Bol definovaný plán viacstupňovej dodávky produktu.
2.7. Plán zohľadňuje tréningy, víkendy, dovolenky, sick days.
2.8. Plán a harmonogram projektu schvaľujú všetci členovia tímu.
Kontrolujeme a riadime implementáciu
3.1. Projekt má kurátora. Ide o takého top manažéra výkonnej spoločnosti, ktorý sa osobne zaujíma o úspech tohto projektu.
3.2. Projekt má manažéra a iba jedného!
3.3. Plán projektu definuje „binárne“ míľniky.
3.4. Všetci záujemcovia môžu získať potrebné informácie o priebehu projektu.
3.5. Medzi manažmentom a vývojármi bol vytvorený vzťah založený na dôvere.
3.6. Zavedený postup riadenia zmien pre projekt.
3.7. Boli identifikované osoby zodpovedné za rozhodnutie prijať zmeny v projekte.
3.8. Plán, harmonogram a informácie o stave projektu sú dostupné každému účastníkovi.
3.9. Systémový kód sa skontroluje automaticky.
3.10. Používa sa systém správy defektov.
Analyzujeme hrozby
4.1. Existuje zoznam rizík projektu. Je pravidelne revidovaný a aktualizovaný.
4.2. Projektový manažér sleduje vznik nových rizík.
4.3. Pre každého dodávateľa je určená osoba zodpovedná za spoluprácu s ním.
Práca na budovaní tímu
5.1. Skúsenosti tímu sú dostatočné na dokončenie projektu.
5.2. Tím má dostatočné kompetencie v aplikačnej oblasti.
5.3. Projekt má technického vedúceho.
5.4. Počet zamestnancov je dostatočný.
5.5. Mužstvo má dostatočnú súdržnosť.
5.6. Všetci účastníci sú oddaní projektu.

Hodnotenie a interpretácia testu

Skóre: súčet bodov, každá položka je hodnotená od 0 do 3:

0 - nikdy som o tom ani nepočul;
1 - vypočuté, ale ešte neuplatnené;
2 - aplikovaný čiastočne;
3 - plne aplikované.

Korekčné faktory:

pre malé projekty (do 5 osôb) - 1,5;
pre stredné (od 5 do 20 osôb) - 1,25.

výsledok:

<40 - завершение проекта сомнительно.
40-59 - priemerný výsledok. V priebehu projektu možno očakávať vážne problémy.
60-79 je dobrý výsledok. Projekt bude pravdepodobne úspešný.
80-89 je výborný výsledok. Šanca na úspech je vysoká.
>90 je skvelý výsledok. 100% šanca na úspech.

Tento kontrolný zoznam uvádza, čo je potrebné urobiť pre úspech softvérového projektu, ale neodpovedá na otázku, ako to urobiť. O tom bude zvyšok prednášok.