Reference: Sommerville, Softwarové inženýrství, 10. vydání, kapitola 2

Softwarový proces je strukturovaný soubor činností potřebných k vývoji softwarového systému. Všimněte si, že hovoříme o „softwarovém procesu“ — nikoli o „procesu vývoje softwaru“.“

Existuje mnoho různých druhů softwarových procesů, ale každý z nich zahrnuje tyto čtyři typy základních činností:

• Specifikace softwaru – definování toho, co má systém dělat;
• Návrh a implementace softwaru – definování organizace systému a implementace systému;
• Ověřování softwaru – kontrola, zda dělá to, co zákazník chce;
• Vývoj softwaru – změna systému v reakci na měnící se potřeby zákazníka.

Model softwarového procesu je abstraktní reprezentace procesu. Představuje popis procesu z určitého konkrétního pohledu. Když popisujeme a diskutujeme o softwarových procesech, obvykle hovoříme o činnostech v těchto procesech, jako je specifikace datového modelu, návrh uživatelského rozhraní atd. a pořadí těchto činností.Popisy procesů mohou také obsahovat:

• Produkty, což jsou výsledky činnosti procesu;
• Role, které odrážejí odpovědnosti lidí zapojených do procesu;
• Před- a po-podmínky, což jsou tvrzení, která jsou pravdivá před a po provedení činnosti procesu nebo vytvoření produktu.

Procesy řízené plánem jsou procesy, v nichž jsou všechny činnosti procesu předem naplánovány a pokrok se měří podle tohoto plánu. V agilních procesech je plánování přírůstkové a je snazší měnit proces podle měnících se požadavků zákazníka. V praxi většina praktických procesů zahrnuje prvky jak plánem řízených, tak agilních přístupů.

Vodopádový model Model řízený plánem. Oddělené a samostatné fáze specifikace, návrhu softwaru, implementace, testování a údržby. Inkrementální vývoj Specifikace, vývoj a validace se prolínají. Systém je vyvíjen jako řada verzí (inkrementů), přičemž každá verze rozšiřuje funkčnost verze předchozí. Může být plánovaný nebo agilní. Integrace a konfigurace Na základě existence značného počtu opakovaně použitelných komponent/systémů. Proces vývoje systému se zaměřuje spíše na integraci těchto komponent do systému než na jejich vývoj od nuly. Může být řízený plánem nebo agilní.

V praxi je většina velkých systémů vyvíjena pomocí procesu, který zahrnuje prvky ze všech těchto modelů.

Ve vodopádovém modelu jsou identifikovány samostatné fáze:

Analýza a definice požadavků Služby, omezení a cíle systému jsou stanoveny konzultací s uživateli systému. Poté jsou podrobně definovány a slouží jako specifikace systému. Návrh systému a softwaru Proces návrhu systému přiřazuje požadavky buď hardwarovým, nebo softwarovým systémům stanovením celkové architektury systému. Návrh softwaru zahrnuje identifikaci a popis základních abstrakcí softwarového systému a jejich vztahů. Implementace a testování jednotek V této fázi je návrh softwaru realizován jako soubor programů nebo programových jednotek. Testování jednotek zahrnuje ověření, zda každá jednotka splňuje svou specifikaci. Integrace a testování systému Jednotlivé programové jednotky nebo programy jsou integrovány a testovány jako kompletní systém, aby se zajistilo splnění požadavků na software. Po testování je softwarový systém dodán zákazníkovi. Provoz a údržba Obvykle (i když ne nutně) se jedná o nejdelší fázi životního cyklu. Systém je nainstalován a uveden do praktického provozu. Údržba zahrnuje opravu chyb, které nebyly odhaleny v předchozích fázích životního cyklu, zdokonalování implementace systémových jednotek a rozšiřování služeb systému podle toho, jak jsou objevovány nové požadavky.

Hlavní nevýhodou vodopádového modelu je obtížné přizpůsobení se změnám po zahájení procesu. V zásadě platí, že fáze musí být dokončena před přechodem do další fáze. Mezi problémy vodopádového modelu patří:

Obtížné řešení změn Nepružné rozdělení projektu do jednotlivých fází ztěžuje reakci na měnící se požadavky zákazníka, proto je tento model vhodný pouze tehdy, když jsou požadavky dobře pochopeny a změny budou v průběhu procesu návrhu poměrně omezené. Jen málo podnikových systémů má stabilní požadavky. Velmi málo reálných aplikací Vodopádový model se většinou používá u velkých projektů systémového inženýrství, kdy se systém vyvíjí na několika místech. za těchto okolností pomáhá plánovitost vodopádového modelu koordinovat práci.

Výhody inkrementálního vývoje:

Nižší náklady na změny Snižují se náklady na přizpůsobení se měnícím se požadavkům zákazníka. Množství analýz a dokumentace, které je třeba přepracovat, je mnohem menší, než je nutné u vodopádového modelu. Častá zpětná vazba Je snazší získat zpětnou vazbu od zákazníka na provedenou vývojovou práci. Zákazníci se mohou vyjádřit k ukázkám softwaru a zjistit, kolik toho bylo implementováno. Rychlejší dodání Je možné rychlejší dodání a nasazení užitečného softwaru zákazníkovi. Zákazníci mohou software používat a získat z něj hodnotu dříve, než je to možné při vodopádovém procesu.

Problémy s inkrementálním vývojem (z pohledu managementu):

Proces není viditelný Manažeři potřebují pravidelné výstupy pro měření pokroku. Pokud jsou systémy vyvíjeny rychle, není nákladově efektivní vytvářet dokumenty, které odrážejí každou verzi systému. Struktura systému má tendenci se zhoršovat s přidáváním nových inkrementů Pokud se nevynakládá čas a peníze na refaktorizaci za účelem zlepšení softwaru, mají pravidelné změny tendenci poškozovat jeho strukturu. Začlenění dalších změn softwaru se stává stále obtížnějším a nákladnějším.

Tento přístup je založen na systematickém opakovaném použití, kdy jsou systémy integrovány z existujících komponent nebo systémů COTS (Commercial-off-the-shelf) Fáze procesu zahrnují:

• Analýzu komponent;
• Modifikaci požadavků;
• Návrh systému s opakovaným použitím;
• Vývoj a integraci.

Znovupoužití je dnes standardním přístupem k budování mnoha typů podnikových systémů.

Typy softwarových komponent:

• Webové služby, které jsou vyvinuty podle standardů služeb a které jsou k dispozici pro vzdálené volání.
• Soubory objektů, které jsou vyvinuty jako balíček pro integraci s komponentovým rámcem, jako je .NET nebo J2EE.
• Samostatné komerční systémy (COTS), které jsou konfigurovány pro použití v určitém prostředí.

Skutečné softwarové procesy jsou vzájemně provázané posloupnosti technických, kolaborativních a manažerských činností s celkovým cílem specifikovat, navrhnout, implementovat a testovat softwarový systém.

Čtyři základní procesní činnosti specifikace, vývoje, validace a vývoje jsou v různých vývojových procesech organizovány odlišně. Ve vodopádovém modelu jsou organizovány postupně, zatímco v inkrementálním vývoji se prolínají.

Specifikace softwaru Proces stanovení toho, jaké služby jsou požadovány a jaká jsou omezení pro provoz a vývoj systému. Proces inženýrství požadavků:

• Studie proveditelnosti: je technicky a finančně proveditelné vybudovat systém
• Zjišťování a analýza požadavků: co zainteresované strany systému požadují nebo očekávají od systému
• Specifikace požadavků: podrobné definování požadavků
• Validace požadavků: kontrola platnosti požadavků

Návrh a implementace softwaru Proces převodu specifikace systému na spustitelný systém.

• Návrh softwaru: návrh softwarové struktury, která realizuje specifikaci;
• Implementace: převod této struktury do spustitelného programu;

Činnosti návrhu a implementace spolu úzce souvisejí a mohou se prolínat. Činnosti návrhu zahrnují:

• Návrh architektury: určení celkové struktury systému, hlavních komponent (někdy nazývaných subsystémy nebo moduly), jejich vztahů a způsobu jejich rozložení.
• Návrh rozhraní: definování rozhraní mezi komponentami systému.
• Návrh komponent: vezměte každou komponentu systému a navrhněte, jak bude fungovat.
• Návrh databáze: navrhněte datové struktury systému a způsob jejich reprezentace v databázi.

Ověřování softwaru Ověřování a validace (V & V) má prokázat, že systém odpovídá své specifikaci a splňuje požadavky zákazníka systému.

• Validace: vytváříme správný produkt (to, co zákazník chce)
• Ověřování: vytváříme správný produkt

V & V zahrnuje procesy kontroly a přezkoumání a testování systému. Testování systému zahrnuje spuštění systému pomocí testovacích případů, které jsou odvozeny ze specifikace skutečných dat, jež má systém zpracovávat. Testování je nejčastěji používanou činností V & V a zahrnuje následující fáze:

• Vývojové testování nebo testování komponent: jednotlivé komponenty se testují samostatně; komponenty mohou být funkce nebo objekty nebo souvislá seskupení těchto entit.
• Systémové testování: testování systému jako celku, zvláště důležité je testování vznikajících vlastností.
• Akceptační testování: testování s daty zákazníka s cílem ověřit, zda systém splňuje jeho potřeby.

Vývoj softwaru Software je ze své podstaty flexibilní a může se měnit. Jak se mění požadavky v důsledku měnících se obchodních okolností, musí se vyvíjet a měnit i software, který podporuje podnikání. ačkoli existovala hranice mezi vývojem a evolucí (údržbou), je to stále méně důležité, protože stále méně systémů je zcela nových.

Změny jsou nevyhnutelné u všech velkých softwarových projektů.změny v podnikání vedou k novým a změněným požadavkům na systémNové technologie otevírají nové možnosti pro zlepšení implementace.měnící se platformy vyžadují změny aplikací.změny vedou k přepracování, takže náklady na změny zahrnují jak přepracování (např.např. opětovnou analýzu požadavků), tak i náklady na implementaci nových funkcí.

Dvě strategie pro snížení nákladů na přepracování:

Předcházení změnám Softwarový proces zahrnuje činnosti, které mohou předvídat možné změny dříve, než je nutné provést významné přepracování. Například může být vyvinut prototyp systému, aby se zákazníkům ukázaly některé klíčové funkce systému. Tolerance změn Proces je navržen tak, aby bylo možné přizpůsobit se změnám s relativně nízkými náklady. to obvykle zahrnuje určitou formu přírůstkového vývoje. Navrhované změny mohou být realizovány v přírůstcích, které ještě nebyly vyvinuty. Pokud to není možné, pak může být nutné změnit pouze jeden přírůstek (malou část systému) tak, aby zahrnoval změnu.

Prototyp je počáteční verze systému sloužící k demonstraci konceptů a vyzkoušení možností návrhu. Prototyp lze použít:

• v procesu inženýrství požadavků, který pomáhá při získávání a ověřování požadavků;
• v procesech návrhu k prozkoumání možností a vývoji návrhu uživatelského rozhraní;
• v procesu testování k provádění zpětných testů.

Přínosy prototypování:

• Zlepšení použitelnosti systému.
• Blíže odpovídá skutečným potřebám uživatelů.
• Zlepšení kvality návrhu.
• Zlepšení udržovatelnosti.
• Snížení náročnosti vývoje.

Prototypy mohou být založeny na jazycích nebo nástrojích pro rychlé prototypování. Mohou zahrnovat vynechání funkčnosti:

• Prototyp by se měl zaměřit na oblasti produktu, které nejsou dobře pochopeny;
• Kontrola a obnova chyb nemusí být v prototypu zahrnuta;
• Zaměřit se spíše na funkční než nefunkční požadavky, jako je spolehlivost a bezpečnost.

Prototypy by měly být po vývoji vyřazeny, protože nejsou dobrým základem pro produkční systém:

• Může být nemožné vyladit systém tak, aby splňoval nefunkční požadavky;
• Prototypy jsou obvykle nedokumentované;
• Struktura prototypu je obvykle degradována rychlými změnami;
• Prototyp pravděpodobně nebude splňovat běžné organizační standardy kvality.

Spíše než dodat systém jako jednu dodávku je vývoj a dodávka rozdělena do inkrementů, přičemž každý inkrement dodává část požadované funkčnosti.Požadavky uživatelů jsou prioritizovány a požadavky s nejvyšší prioritou jsou zahrnuty do prvních inkrementů. jakmile je vývoj inkrementu zahájen, požadavky jsou zmrazeny, ačkoli požadavky na pozdější inkrementy se mohou dále vyvíjet.

Výhody inkrementální dodávky:

• S každým inkrementem lze dodat hodnotu pro zákazníka, takže funkčnost systému je k dispozici dříve.
• Včasné přírůstky fungují jako prototyp, který pomáhá získat požadavky pro pozdější přírůstky.
• Menší riziko celkového selhání projektu.
• Služby systému s nejvyšší prioritou bývají nejvíce testovány.

Problémy inkrementální dodávky:

• Většina systémů vyžaduje sadu základních zařízení, která jsou využívána různými částmi systému. Vzhledem k tomu, že požadavky jsou podrobně definovány až v okamžiku, kdy má být inkrement implementován, může být obtížné určit společná zařízení, která jsou potřebná pro všechny inkrementy.
• Podstatou iterativních procesů je, že specifikace se vyvíjí společně se softwarem. To je však v rozporu s modelem zadávání zakázek v mnoha organizacích, kde je kompletní specifikace systému součástí smlouvy o vývoji systému.

Mnoho softwarových společností se obrátilo na zlepšování softwarových procesů jako na způsob, jak zvýšit kvalitu svého softwaru, snížit náklady nebo urychlit vývojové procesy. Zlepšování procesů znamená pochopení stávajících procesů a jejich změnu s cílem zvýšit kvalitu produktu a/nebo snížit náklady a dobu vývoje.

Přístup založený na vyspělosti procesů Zaměřuje se na zlepšování procesů a řízení projektů a zavádění správné praxe softwarového inženýrství. Úroveň vyspělosti procesů odráží míru přijetí správné technické a řídicí praxe v procesech vývoje softwaru v organizaci. Agilní přístup Zaměřuje se na iterativní vývoj a snižování režijních nákladů v softwarovém procesu. Hlavními charakteristikami agilních metod jsou rychlé dodání funkčnosti a schopnost reagovat na měnící se požadavky zákazníků.

Činnosti zlepšování procesu tvoří nepřetržitý cyklus se zpětnou vazbou:

• Měření jednoho nebo více atributů softwarového procesu nebo produktu. Tato měření tvoří základní linii, která pomáhá rozhodnout, zda bylo zlepšení procesu účinné.
• Analyzujte stávající proces a identifikujte případná úzká místa.
• Změňte proces tak, abyste odstranili některé ze zjištěných nedostatků procesu. Ty se zavedou a cyklus pokračuje sběrem dat o účinnosti změn.

Měření procesu

• Pokud je to možné, měly by se shromažďovat kvantitativní údaje o procesu.
• Měření procesu by se mělo použít k posouzení zlepšení procesu.
• Metriky mohou zahrnovat:
  • Čas potřebný k dokončení činností procesu, např.např. kalendářní čas nebo úsilí k dokončení činnosti nebo procesu.
  • Zdroje potřebné pro procesy nebo činnosti, např. celkové úsilí v člověkodnech.
  • Počet výskytů určité události, např. počet zjištěných závad.

Model zralosti schopností SEI

• Počáteční: V podstatě nekontrolovaný
• Opakovatelný: Definované: Definované a používané postupy řízení produktu
• Definované: Definované a používané postupy a strategie řízení procesů
• Řízené: Optimalizující: Definovány a používány strategie řízení kvality
• Optimalizující: Strategie zlepšování procesů definovány a používány