Proces vývoje softwaru

Proces vývoje softwaru (anglicky software development process) je v softwarovém inženýrství proces členění práce při vývoji softwaru na různé fáze s cílem zkvalitnit proces návrhu softwaru, správu softwaru a řízení softwarového projektu. Celý proces vývoje softwaru se také nazývá životní cyklus vývoje softwaru (anglicky software development life cycle, SDLC). Metodika může zahrnovat i předběžnou definici určitých dodávaných položek a artefaktů, které projektový tým vytváří a dokončuje pro vývoj nebo údržbu aplikace.[1]

Většinu moderních procesů vývoje lze vágně popsat jako agilní metodiky. K jiným metodikám patří vodopádový model, prototypování, iterativní a inkrementální vývoj, spirálový vývoj, Rapid Application Development a extrémní programování.

Někdy je „model“ životního cyklu považován za obecnější termín pro kategorii metodik, a „proces“ vývoje softwaru za konkrétnější označení určitého procesu používaného nějakou organizací. Existuje například mnoho konkrétních procesů vývoje softwaru, které odpovídají spirálovému modelu životního cyklu. Proces vývoje softwaru je často považován za část životního cyklu vývoje systému.

Historie

Metodiky vývoje softwaru (anglicky software development methodology, SDM) se začaly objevovat až od konce 60. let 20. století. Podle Elliotta (2004) lze za nejstarší formalizovanou metodiku pro vytváření informačních systémů považovat životní cyklus vývoje systému (anglicky Systems Development Life Cycle, SDLC). Hlavní myšlenkou SDLC bylo „velmi promyšleně, strukturovaně a metodicky sledovat vývoj informačních systémů, aby každá fáze životního cyklu – od počáteční myšlenky po doručení výsledného systému – byla v rámci použité metodiky (frameworku) provedena přesně a postupně“.[2] V 60. letech 20. století byl hlavním cílem tohoto metodického přístupu „vývoj rozsáhlých funkčních firemních systémů pro éru velkých obchodních konglomerátů. Činnost informačních systémů té doby byla zaměřena na zpracování hromadných dat a intenzivní numerické výpočty.“[3]

Metodiky, procesy a frameworky sahají od určitých předepsaných činností, které může organizace provádět při své každodenní činnosti, až po flexibilní frameworky, které organizace používají pro vytváření vlastních postupů přizpůsobených potřebám určitého projektu nebo skupiny. „Sponzor“ nebo „vedení“ organizace obvykle distribuuje oficiální sadu dokumentů popisujících tento proces. Příkladem jsou následující metodiky:

70. léta 20. století
  • Strukturované programování od roku 1969
  • Cap Gemini SDM, původně z PANDATA, jehož první anglický překlad byl publikován v roce 1974. SDM znamená Systém Development Methodology
80. léta 20. století
  • Structured systems analysis and design method (SSADM, strukturovaná analýza systémů a metoda návrhu) od roku 1980
  • Information Requirement Analysis/Soft systems methodology (analýza informačních požadavků a metodika softwarových systémů)
90. léta 20. století
2000-2009
po roce 2010
  • Scaled Agile Framework (SAFe)
  • Large-Scale Scrum (LeSS)
  • DevOps

Za povšimnutí stojí, že počínaje DSDM v roce 1994 byly všechny uvedené metodiky kromě RUP agilní – i když mnoho organizací, zvláště vlád, stále používá starší procesy (často vycházející z vodopádového modelu). Platí, že softwarový proces a kvalita softwaru se vzájemně ovlivňují; v praxi byly pozorovány některé neočekávané aspekty a účinky.[4]

Další proces vývoje softwaru byl vytvořen v oblasti otevřeného softwaru a svobodného softwaru. Přijetí těchto nejlepších známých praktik a vytvoření procesů uvnitř hranic společnosti se nazývá InnerSource.

Prototypování

Softwarové prototypování je založeno na vytváření prototypů, neboli částečných verzí softwaru.

Základní principy jsou:[1]

  • Prototypování není samostatná, úplná, vývojová metodika, ale spíše přístup, při kterém se zkoušejí určité vlastnosti v rámci úplné metodiky (např. inkrementální, spirálový nebo rapid application development (RAD)).
  • Usiluje o omezení inherentního projektového rizika rozdělením projektu na menší segmenty a usnadněním změn během procesu vývoje.
  • Zákazník nebo klient je zapojen do celého procesu vývoje, což zvyšuje šanci, že přijme konečnou implementaci.
  • Zatímco u některých prototypů se očekává, že přispějí k ujasnění směru vývoje, a pak budou zahozeny, v některých případech je možné z prototypu vyvíjet cílový systém.

Prototypování klade důraz na přístup, že pro zabránění řešení nesprávných problémů, je nutné důkladné pochopení podstaty obchodního problému.

Metodiky

Agilní vývoj
Podrobnější informace naleznete v článku Agilní metodiky.

„Agilní vývoj softwaru“ je skupina metodik vývoje softwaru založených na iterativním vývoji, kde se požadavky a řešení postupně vyvíjejí těsnou spoluprací mezi samoorganizujícími se multifunkčními týmy. Termín se objevil v roce 2001, kdy byl formulován Agilní manifest.

Agilní metodiky jsou založeny na iterativním vývoji, ale usilují o odlehčenější a více na lidi zaměřený přístup než tradiční metodiky. Agilní procesy v základu zahrnují iteraci a neustálou zpětnou vazbu, které vedou k postupnému zjemňování a doručování softwarového systém.

K agilním metodikám patří:

Průběžná integrace
Podrobnější informace naleznete v článku Průběžná integrace.

Průběžná integrace (anglicky Continuous integration, CI) je založena na častém (několikrát za den) slučování pracovních kopií jednotlivých vývojářů do sdílené větve.[5] Průběžnou integraci jako první navrhl a pojmenoval Grady Booch ve své metodice z roku 1991,[6] který však neobhajoval slučování několikrát za den. Koncept průběžné integrace převzalo extrémní programování (XP), v němž se má slučování uskutečňovat vícekrát za den.

Inkrementální vývoj

Pro zkombinování lineárních a iterativních metodik vývoje systému jsou přijatelné různé metody, přičemž primárním cílem každé z nich je omezení inherentního rizika projektu jeho rozkladem na menší segmenty a usnadňování změn v průběhu vývojového procesu.

Existují tři hlavní varianty inkrementálního vývoje:[1]

  1. Provádí se řada mini-vodopádů, přičemž všechny fáze vodopádového modelu se provádí pouze pro malou část systému, před postupem k dalšímu přírůstku nebo
  2. Před začátkem evolučního, mini-vodopádového modelu vývoje s dílčími přírůstky jsou definovány celkové požadavky
  3. Počáteční softwarový koncept, analýza požadavků a návrh architektury a jádra systému jsou definovány pomocí vodopádového modelu, na který navazuje inkrementální implementace, která je zakončena instalací výsledné verze plně funkčního systému.

Rapid Application Development
Podrobnější informace naleznete v článku Rapid Application Development.
Model Rapid Application Development (RAD)

Rapid Application Development (RAD) je metodika vývoje softwaru, která upřednostňuje iterativní vývoj a velmi rychlou konstrukci prototypů místo velkého plánování. „Plánování“ vývoje softwaru pomocí RAD se střídá se samotným psaním softwaru. Obecně odstranění předběžného plánování umožňuje, aby software bal vytvářen mnohem rychleji a usnadňuje reakci na změny požadavků.

Proces RAD začíná vývojem předběžných datových modelů a modelů obchodního procesu pomocí strukturovaných technik. V další fázi jsou požadavky ověřeny pomocí prototypování, přičemž dochází ke zjemňování dat a modelů procesu. Tyto fáze se iterativně opakují; další vývoj vede k tomu, že „kombinované obchodní požadavky a popis technického návrhu je použit pro zkonstruování nových systémů“.[7]

Název RAD byl nejdříve používán pro popis procesu vývoje softwaru, který zavedl James Martin v roce 1991. Podle Whitten (2003) jde o sloučení různých strukturovaných technik, zvláště inženýrství informačních technologií řízených daty, s technikami prototypování pro urychlení vývoje softwarových systémů.[7]

Základní principy Rapid Application Development jsou:[1]

  • Klíčovým cílem je rychlý vývoj a doručení systému vysoké kvality za relativně nízkou cenu.
  • Snaží se o omezení inherentního projektového rizika rozkladem projektu na menší segmenty a usnadňováním změn v průběhu vývojového procesu.
  • Cíle pro vytváření vysoce kvalitních systémů rychle, primárně iterativním prototypováním (v jakékoli fázi vývoje), aktivní zapojení uživatele a automatizovaných vývojových nástrojů. K těmto nástrojům patří buildery grafického uživatelského rozhraní (GUI), CASE nástroje, systémy pro správu databází (DBMS), programovací jazyky čtvrté generace, generátory kódu a objektově orientované techniky.
  • Hlavní důraz je na plnění obchodních potřeb, zatímco technologická nebo inženýrská kvalita má menší význam.
  • Projektové řízení zajišťuje prioritizaci vývoje a definování termínů doručení neboli „timeboxů“. Pokud se projekt začíná opožďovat, důraz je kladen na omezování požadavků, tak aby se neopozdilo dodání, ne posouvání termínů.
  • Obecně zahrnuje Joint application design (JAD), kde uživatelé se intenzivně účastní návrhu systému, vytvářením konsenzu buď při strukturovaných workshopech, nebo při elektronické komunikaci.
  • Aktivní zainteresování uživatele je nezbytné
  • Iterativně produkuje produkční software, na rozdíl od zahazovacího prototypu.
  • Vytváří nezbytnou dokumentaci, aby se umožnil budoucí vývoj a správa.
  • Do této metodiky lze zapracovat standardní systémovou analýzu a metody návrhu.

Spirálový vývoj
Spirálový model (Boehm, 1988)

V roce 1988 publikoval Barry Boehm formální „spirálový model“ vývoje softwarového systému, který kombinuje některé klíčové aspekty vodopádového modelu a metodiky Rapid Application Development s cílem zkombinovat výhody konceptů shora dolů a zdola nahoru. Poskytl důraz na klíčovou oblast, o které se mnozí domnívají, že byla jinými metodikami přehlížena: promyšlená iterativní analýza rizik vhodná zvláště pro rozsáhlé a složité systémy.

Základní principy spirálového modelu:[1]

  • Zaměřuje se na vyhodnocení a minimalizaci rizik projektu jeho rozdělením na menší segmenty a usnadňováním změn v průběhu vývojového procesu; poskytuje možnosti vyhodnocení rizik a zvážení pokračování v projektu v každém bodě jeho životního cyklu.
  • „V každém cyklu se dosahuje postupu stejnou posloupností kroků, pro každou část produktu a pro každou úroveň detailu, od dokumentu popisujícího celkový koncept fungování až po kódování každého jednotlivého programu.“[8]
  • Při každém oběhu spirály se prochází čtyřmi kvadranty: (1) určení cíle, alternativ a omezení iterace; (2) vyhodnocení alternativ; identifikace a řešení rizik; (3) vývoj a verifikace dodávaných položek v rámci iterace; a (4) plánování další iterace.[9]
  • Každý cyklus je třeba zahájit identifikací zainteresovaných osob a jimi stanovených „podmínek úspěšné realizace“ a zakončit vyhodnocením a návrhem změn.[10]

Vodopádový vývoj
Podrobnější informace naleznete v článku Vodopádový model.
Působnost/činnosti procesu vývoje softwaru reprezentována ve vodopádovém modelu. Existuje několik dalších modelů, které reprezentuje tento proces.

Vodopádový model je sekvenční přístup k vývoji softwaru, ve kterém je vývoj vnímán jako neustálý tok (podobný vodopádu) několika fázemi, typicky:

Jako první formální popis metody je často citován článek, který publikoval Winston W. Royce[11] v roce 1970 ačkoli Royce v tomto článku termín „vodopádový“ nepoužil. Royce tento model prezentoval jako ukázku chybného, nefungujícího modelu.[12]

Základní principy jsou:[1]

  • Projekt je rozdělen na sekvenční fáze, z nichž některé se mohou překrývat a je možné i prolínání mezi fázemi.
  • Důraz je na plánování, časové rozvrhy, cílová data, rozpočet a implementaci celého systému najednou.
  • Tight řídit je udržována po dobu života projektu přes široký napsaný dokumentace, formální revize a schvalování/podepisování zákazníkem (uživatelem) a informace technologie správa objevující se na konci většiny fází před začátkem další fáze. Psaná dokumentace je explicitní dodávanou položkou každé fáze.

Vodopádový model je tradiční inženýrský přístup aplikovaný na oblast vývoje softwaru. Striktně vodopádový přístup zapovídá opakování a revize jakékoli předchozí fáze, jakmile je jednou dokončena. Tato „nepružnost“ čistě vodopádového modelu je předmětem kritiky lidí podporujících jiné, „flexibilnější“, modely. Několik rozsáhlých projektů pro vládní úřady, které překročily rozpočet, nebyly dokončeny včas, případně jejich výsledky neodpovídaly požadavkům kvůli přístupu Big Design Up Front, vedlo k široké kritice vodopádového modelu. Proto byl ouze pokud contractually požadovaný, vodopádový model bylo z větší části nahrazený novější verzí flexibilnější a versatile metodika vyvinuté konkrétně pro vývoj softwaru. Viz Kritika vodopádového modelu.

Další metodiky

K dalším vysokoúrovňovým metodikám řízení softwarového projektu patří:

  • Behavior-driven development a řízení obchodních procesů[13]
  • Chaos model – Hlavní pravidlem je vždy začínat řešení od nejzávažnějšího problému.
  • Incremental funding methodology (IFM) – iterativní přístup
  • Lightweight methodology (odlehčená metodika) – obecný termín pro metody, které mají pouze několik málo pravidel a praktik
  • Structured systems analysis and design method (strukturovaná analýza systémů a metoda návrhu) – jedna z verzí vodopádového přístupu
  • Slow programming je součástí hnutí Slow movement, které zdůrazňuje pečlivou a postupnou práci bez (nebo s minimálními) časovými tlaky. Pomalé programování se snaží zabránit chybám a příliš rychlým rozvrhům vydání.
  • V-Model (vývoj softwaru) – rozšíření vodopádového modelu
  • Unified Process (UP) je iterativní metodika vývoje softwaru, založená na Unified Modeling Language (UML). UP organizuje vývoj softwaru do čtyř fází, z nichž každá se skládá z jedné nebo více proveditelných iterací softwaru, v jedné z následujících fází vývoje: inception, elaboration, construction, and guidelines. Existuje mnoho nástrojů a výrobků, které mají umožňovat implementaci UP. Jeden z nejoblíbenějších verzí UP je Rational Unified Process (RUP).

Meta-modely procesu

Některé „modely procesů“ jsou abstraktní popisy pro vyhodnocování, porovnávání a zlepšování určitého procesu používaného firmou.

  • ISO/IEC 12207 je mezinárodní norma popisující metoda pro výběr, implementaci a monitorování životního cyklu softwaru.
  • Jedním z vedoucích modelů je Capability Maturity Model Integration (CMMI) založený na ověřených nejlepších postupech. Nezávislá hodnocení oceňují jednotlivé organizace, jak dobře používají své definované procesy, nehodnotí však kvalitu těchto procesů nebo vytvářený software. CMMI byl nahrazen CMM.
  • ISO 9000 popisuje standardy formálně organizovaného procesu výroby a metody řízení a sledování postupu. Ačkoli norma byla původně vytvořena pro výrobní sektor, byly ISO 9000 standardy aplikovány také na vývoj softwaru. Stejně jako CMMI nezaručuje certifikace podle ISO 9000 kvalitu konečného výsledku, ale pouze to, že byly dodrženy formalizované obchodní procesy.
  • ISO/IEC 15504 Information technology — Process assessment také známý jako Process Improvement Capability Determination (SPICE), je „rámec pro hodnocení softwarových procesů“. Tento standard je cílen na vytvoření jasného modelu pro proces porovnání. SPICE se používá podobně jako CMMI. Modeluje procesy řízení, kontroly, vedení a monitorování vývoje softwaru. Tento model pak se používá pro měření, co vývojářská firma nebo projektový tým skutečně dělá při vývoji softwaru. Tyto informace jsou analyzovány, aby se odhalila slabá místa a dosáhlo zlepšení. Také se identifikuje silná místa, která se reprodukují nebo zabudovávají do postupů obvyklých v příslušné organizaci nebo týmu.
  • ISO/IEC 24744 Software Engineering — Metamodel for Development Methodologies, je metamodel metodik vývoje softwaru založený na potenčních typech (anglicky power type) používaných v Unified Modeling Language
  • SPEM 2.0 vytvořený skupinou Object Management Group
  • Soft systems methodology – obecná metoda pro zlepšování řídicích procesů
  • Method engineering – obecná metoda pro zlepšování procesů v informačních systémech

Praxe
Tři základní přístupy aplikované na metodiky vývoje softwaru.

Za léta vývoje se objevilo množství metodik vývoje softwaru s různými přednostmi i slabinami. Určitá metodika nemusí být vhodná pro použití ve všech druzích projektů. Každý z dostupných metodických frameworků jsou nejvhodnější pro určitý druh projektů založených na různých technických, organizačních, projektových a týmových kritériích.[1]

Firmy, které vyvíjejí software implementují různé metodiky, aby si zjednodušily proces vývoje. Někteří velcí zákazníci a kontraktoři, např. zbrojní průmysl USA, podmiňují získání zakázky použitím ratingu založeném na modelování procesů. Mezinárodní norma pro popis metody výběru, implementace a sledování životního cyklu softwaru je ISO/IEC 12207.

Při vytváření metodik vývoje softwaru bylo po desetiletí hlavním úkolem hledání opakovatelných a předvídatelných procesů, které zlepšují produktivitu a kvalitu. Některé se snaží systematizovat nebo formalizovat těžko popsatelnou úlohu návrhu softwaru. Jiné aplikují obecné techniky řízení projektů na oblast navrhování softwaru. Velké množství softwarových projektů nesplnilo očekávání kvůli nedostatečné funkčnosti, vysoké ceně nebo rozvrhu doručení – příklady jsou v seznamu zakázkových softwarových projektů, které selhaly nebo výrazně překročily rozpočet.

Organizace může vytvořit Software Engineering Process Group (SEPG), která je ústředním bodem pro zlepšování procesu. Skupina by měla být složena z praktiků, kteří mají různé dovednosti, aby se stala centrem společného úsilí každého v organizaci, kdo se účastní zlepšování procesu vývoje softwaru.

Určitý vývojový tým může také schválit detaily prostředí pro programování, například jaké integrované vývojové prostředí (IDE) se bude používat a jedno nebo více hlavních programovacích paradigmat, styl zápisu programu nebo volbu určitých softwarových knihoven nebo softwarové frameworky. Tyto detaily obecně nejsou vynuceny volbou modelu nebo obecné metodiky.

Životní cyklus vývoje softwaru (SDLC)

Odkazy

Reference

V tomto článku byl použit překlad textu z článku Software development process na anglické Wikipedii.

  1. Centers for Medicare & Medicaid Services (CMS) Office of Information Service (2008). Selecting a development approach Archivováno 2. 1. 2019 na Wayback Machine. Webarticle. United States Department of Health and Human Services (HHS). Re-validated: March 27, 2008. Retrieved 27 Oct 2008
  2. Elliott 2004, s. 87.
  3. Elliott 2004.
  4. SURYANARAYANA, Girish. Software Process versus Design Quality: Tug of War?. IEEE Software. 2015, roč. 32, čís. 4, s. 7–11. DOI 10.1109/MS.2015.87.
  5. Continuous Integration [online]. Dostupné online.
  6. BOOCH, Grady. Object Oriented Design: With Applications. [s.l.]: Benjamin Cummings, 1991. Dostupné online. ISBN 9780805300918. S. 209.
  7. Whitten, Jeffrey L.; Lonnie D. Bentley, Kevin C. Dittman. (2003). Systems Analysis and Design Methods. 6. vydání. ISBN 0-256-19906-X.
  8. Barry Boehm (1996)., "A Spiral Model of Software Development and Enhancement". In: ACM SIGSOFT Software Engineering Notes (ACM) 11(4):14-24, August 1986
  9. Richard H. Thayer, Barry W. Boehm (1986). Tutorial: software engineering project management. Computer Society Press of the IEEE. p.130
  10. Barry W. Boehm (2000). Software cost estimation with Cocomo II: Volume 1.
  11. Wasserfallmodell > Entstehungskontext, Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. datum přístupu 2007-11-28.
  12. Conrad Weisert, Waterfall methodology: there's no such thing!
  13. LÜBKE, Daniel; VAN LESSEN, Tammo. Modeling Test Cases in BPMN for Behavior-Driven Development. IEEE Software. 2016, roč. 33, čís. 5, s. 15–21. DOI 10.1109/MS.2016.117.

Související články

Literatura
  • ELLIOTT, Geoffrey, 2004. Global Business Information Technology: an integrated systems approach. [s.l.]: Pearson Education.

Externí odkazy
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.