Proces vývoje softwaru () 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 (). 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.

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 () 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 (). 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ě“. 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.“

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í Objektově orientované programování (OOP) vyvinuté na začátku 60. let 20. století se stalo dominantním přístupem k programování v polovině 90. let 20. století Rapid Application Development (RAD), od roku 1991 Dynamic systems development method (DSDM), od roku 1994 Scrum, od roku 1995 Team software process, od roku 1998 Rational Unified Process (RUP) firmy IBM; od roku 1998 Extrémní programování, od roku 1999 2000-2009 Agile Unified Process (AUP), jehož autorem je Scott Ambler; od roku 2005 Disciplined Agile Delivery (DAD) – nahrazuje AUP 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.

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:

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

„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ří:

Dynamic systems development method (DSDM) Kanban Scrum

Průběžná integrace

Průběžná integrace () 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. Průběžnou integraci jako první navrhl a pojmenoval Grady Booch ve své metodice z roku 1991, 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:

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

náhled|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ů“.

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ů.Whitten, Jeffrey L.; Lonnie D. Bentley, Kevin C. Dittman. (2003). Systems Analysis and Design Methods. 6. vydání. .

Základní principy Rapid Application Development jsou:

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 náhled|400px|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:

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.“Barry Boehm (1996)., "A Spiral Model of Software Development and Enhancement". In: ACM SIGSOFT Software Engineering Notes (ACM) 11(4):14-24, August 1986 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.Richard H. Thayer, Barry W. Boehm (1986). Tutorial: software engineering project management. Computer Society Press of the IEEE. p.130 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.Barry W. Boehm (2000). Software cost estimation with Cocomo II: Volume 1.

Vodopádový vývoj

náhled|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:

Analýza požadavků, jejímž cílem je specifikace softwarových požadavků Návrh softwaru Implementace Testování softwaru Systémová integrace, pokud existuje více subsystémů Nasazení softwaru (nebo instalace) Údržba softwaru