Proces vývoje softwaru - Software development process

V softwarového inženýrství , je proces vývoje softwaru je proces dělení vývoje softwaru práci do menších, souběžných nebo postupných kroků nebo dílčí procesy ke zlepšení designu , produktový management a projektové řízení . Je také známý jako životní cyklus vývoje softwaru ( SDLC ). Metodika může zahrnovat předdefinování konkrétních výstupů a artefaktů, které jsou vytvořeny a dokončeny projektovým týmem za účelem vývoje nebo údržby aplikace.

Většina moderních vývojových procesů může být vágně popsána jako agilní . Mezi další metodiky patří vodopád , prototypování , iterativní a přírůstkový vývoj , spirálový vývoj , rychlý vývoj aplikací a extrémní programování .

„Model“ životního cyklu je někdy považován za obecnější termín pro kategorii metodik a „proces“ vývoje softwaru za konkrétnější termín pro odkaz na konkrétní proces zvolený konkrétní organizací. Existuje například mnoho specifických procesů vývoje softwaru, které odpovídají modelu spirálového životního cyklu. Pole je často považováno za podmnožinu životního cyklu vývoje systémů .

Dějiny

Rámec metodologie vývoje softwaru (také známý jako SDM) se objevil až v šedesátých letech minulého století. Podle Elliotta (2004) lze životní cyklus vývoje systémů (SDLC) považovat za nejstarší formalizovaný metodický rámec pro budování informačních systémů . Hlavní myšlenkou SDLC bylo „usilovat o rozvoj informačních systémů velmi promyšleným, strukturovaným a metodickým způsobem, který vyžaduje každou fázi životního cyklu –– od vzniku myšlenky až po dodání konečného systému –– být prováděny rigidně a postupně "v kontextu aplikovaného rámce. Hlavním cílem tohoto metodického rámce v 60. letech 20. století bylo „vyvinout ve velkém měřítku funkční obchodní systémy v době velkých obchodních konglomerátů. Činnosti informačních systémů se točily kolem náročných rutin zpracování dat a zkracování čísel “.

Metodologie, procesy a rámce sahají od konkrétních proskriptivních kroků, které může organizace použít přímo v každodenní práci, až po flexibilní rámce, které organizace používá k vytváření vlastní sady kroků přizpůsobených potřebám konkrétního projektu nebo skupina. V některých případech organizace „sponzor“ nebo „údržba“ distribuuje oficiální sadu dokumentů, které tento proces popisují. Mezi konkrétní příklady patří:

70. léta 20. století
80. léta 20. století
90. léta 20. století
2000s

2010s

Je pozoruhodné, že od DSDM v roce 1994 byly všechny metodiky na výše uvedeném seznamu kromě RUP agilní metodiky - přesto mnoho organizací, zejména vlád, stále používá pre -agilní procesy (často vodopád nebo podobné). Softwarový proces a kvalita softwaru spolu úzce souvisí; v praxi byly pozorovány některé neočekávané aspekty a efekty

Mezi nimi byl v open source zaveden další proces vývoje softwaru . Přijetí těchto osvědčených postupů, známých a zavedených procesů v mezích společnosti, se nazývá vnitřní zdroj .

Prototypování

Softwarové prototypování je o vytváření prototypů, tj. Neúplných verzí vyvíjeného softwarového programu.

Základní principy jsou:

  • Prototypování není samostatnou, úplnou metodikou vývoje, ale spíše přístupem k vyzkoušení konkrétních funkcí v kontextu úplné metodiky (jako je přírůstkový, spirálový nebo rychlý vývoj aplikací (RAD)).
  • Pokusy o snížení inherentního rizika projektu rozdělením projektu na menší segmenty a poskytnutím větší snadnosti změny během procesu vývoje.
  • Klient je zapojen do celého procesu vývoje, což zvyšuje pravděpodobnost přijetí konečné implementace klientem.
  • Zatímco některé prototypy jsou vyvíjeny s očekáváním, že budou vyřazeny, v některých případech je možné se vyvinout z prototypu na pracovní systém.

Abyste se vyhnuli řešení špatných problémů, je nutné základní porozumění základnímu obchodnímu problému, ale to platí pro všechny softwarové metodiky.

Metodiky

Agilní vývoj

„Agilní vývoj softwaru“ označuje skupinu rámců vývoje softwaru založenou na iteračním vývoji, kde se požadavky a řešení vyvíjejí prostřednictvím spolupráce mezi samoorganizujícími se vícefunkčními týmy. Termín byl vytvořen v roce 2001, kdy byl formulován Agilní manifest .

Agilní vývoj softwaru využívá jako základ iterativní vývoj, ale hájí lehčí a více na lidi zaměřený pohled než tradiční přístupy. Agilní procesy zásadně zahrnují iteraci a nepřetržitou zpětnou vazbu, kterou poskytuje k postupnému zdokonalení a dodání softwarového systému.

Agilní model také zahrnuje následující procesy vývoje softwaru:

Nepřetržitá integrace

Kontinuální integrace je postup, kdy několik pracovních dní sloučí všechny pracovní kopie vývojáře do sdílené hlavní řady . Grady Booch nejprve pojmenoval a navrhl CI ve své metodě z roku 1991 , ačkoli neobhajoval integraci několikrát denně. Extreme Programming (XP) přijal koncept CI a zastával integraci více než jednou denně - možná až desítkykrát denně.

Přírůstkový vývoj

Pro kombinování metodik vývoje lineárních a iteračních systémů jsou přijatelné různé metody, přičemž primárním cílem každé z nich je snížit inherentní riziko projektu rozdělením projektu na menší segmenty a poskytnutím větší snadnosti změny během vývojového procesu.

Existují tři hlavní varianty přírůstkového vývoje:

  1. Provádí se řada mini-vodopádů, kde jsou všechny fáze vodopádu dokončeny pro malou část systému, než přejdete k dalšímu přírůstku, nebo
  2. Celkové požadavky jsou definovány před pokračováním k evolučnímu, mini-vodopádovému vývoji jednotlivých přírůstků systému, popř
  3. Počáteční koncepce softwaru, analýza požadavků a návrh architektury a jádra systému jsou definovány pomocí programu Waterfall, po kterém následuje přírůstková implementace, která vrcholí instalací finální verze, funkčního systému.

Rychlý vývoj aplikací

Rapid Application Development (RAD) Model

Rapid application development (RAD) je metodika vývoje softwaru, která místo velkého množství plánování předem upřednostňuje iterativní vývoj a rychlou konstrukci prototypů . „Plánování“ softwaru vyvinutého pomocí RAD je prokládáno samotným psaním softwaru. Absence rozsáhlého předběžného plánování obecně umožňuje software psát mnohem rychleji a usnadňuje změnu požadavků.

Proces rychlého vývoje začíná vývojem předběžných datových modelů a modelů obchodních procesů pomocí strukturovaných technik . V další fázi jsou požadavky ověřovány pomocí prototypování, případně k upřesnění datových a procesních modelů. Tyto fáze se opakují iterativně; další vývoj má za následek „kombinované obchodní požadavky a prohlášení o technickém návrhu, které budou použity pro konstrukci nových systémů“.

Termín byl poprvé použit k popisu procesu vývoje softwaru, který zavedl James Martin v roce 1991. Podle Whittena (2003) jde o sloučení různých strukturovaných technik , zejména datově řízeného inženýrství informačních technologií , s technikami prototypování pro urychlení vývoje softwarových systémů .

Základní principy rychlého vývoje aplikací jsou:

  • Klíčovým cílem je rychlý vývoj a dodávka vysoce kvalitního systému za relativně nízké investiční náklady.
  • Pokusy o snížení inherentního rizika projektu rozdělením projektu na menší segmenty a poskytnutím větší snadnosti změny během procesu vývoje.
  • Snaží se rychle vyrábět vysoce kvalitní systémy, především prostřednictvím iterativního prototypování (v jakékoli fázi vývoje), aktivního zapojení uživatelů a počítačových vývojových nástrojů. Mezi tyto nástroje mohou patřit stavitelé grafického uživatelského rozhraní (GUI), nástroje CASE ( Computer Aided Software Engineering ), systémy pro správu databází (DBMS), programovací jazyky čtvrté generace , generátory kódu a objektově orientované techniky.
  • Klíčový důraz je kladen na splnění obchodních potřeb, zatímco technologická nebo inženýrská dokonalost má menší význam.
  • Řízení projektu zahrnuje upřednostnění vývoje a definování termínů dodání nebo „časových rámců“. Pokud projekt začne uklouzávat, je kladen důraz na snížení požadavků tak, aby odpovídaly časovému plánu, nikoli na prodloužení termínu.
  • Obecně zahrnuje návrh společné aplikace (JAD), kde se uživatelé intenzivně podílejí na návrhu systému , a to budováním konsensu buď ve strukturovaných dílnách, nebo elektronicky usnadněnou interakcí.
  • Aktivní zapojení uživatelů je nezbytné.
  • Iterativně produkuje produkční software, na rozdíl od prototypu zahození.
  • Vytváří dokumentaci nezbytnou k usnadnění budoucího vývoje a údržby.
  • Do tohoto rámce lze vložit standardní systémové analýzy a metody návrhu.

Rozvoj vodopádu

Činnosti procesu vývoje softwaru zastoupené v modelu vodopádu . Tento proces představuje několik dalších modelů.

Model vodopádu je postupný přístup k vývoji, ve kterém je vývoj považován za plynulý tok dolů (jako vodopád) několika fázemi, obvykle:

První formální popis metody je často citován jako článek publikovaný Winstonem W. Roycem v roce 1970, přestože Royce v tomto článku nepoužíval výraz „vodopád“. Royce představil tento model jako příklad vadného, ​​nefungujícího modelu.

Základní principy jsou:

  • Projekt je rozdělen do sekvenčních fází, přičemž mezi fázemi je přijatelné určité překrývání a zpětné stříkání.
  • Důraz je kladen na plánování, časové plány, cílová data, rozpočty a implementaci celého systému najednou.
  • Těsná kontrola je udržována po celou dobu životnosti projektu prostřednictvím rozsáhlé písemné dokumentace, formálních recenzí a schválení/odhlášení ze strany vedení uživatelů a informačních technologií, ke kterému dochází na konci většiny fází před zahájením další fáze. Písemná dokumentace je explicitní dodávkou každé fáze.

Model vodopádu je tradiční inženýrský přístup aplikovaný na softwarové inženýrství. Přísný přístup k vodopádu odrazuje od opětovné návštěvy a revize jakékoli předchozí fáze, jakmile bude dokončena. Tato „nepružnost“ v modelu čistého vodopádu byla zdrojem kritiky příznivců jiných „flexibilnějších“ modelů. To bylo široce obviňováno z několika rozsáhlých vládních projektů, které přesahovaly rozpočet, v průběhu času a někdy nedokázaly splnit požadavky kvůli přístupu Big Design Up Front . Kromě případů, kdy je to smluvně vyžadováno, byl model vodopádu do značné míry nahrazen flexibilnějšími a univerzálnějšími metodikami vyvinutými speciálně pro vývoj softwaru. Viz model Kritika vodopádu .

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 modelu vodopádu a metodologie rychlých prototypů ve snaze spojit výhody konceptů shora dolů a zdola nahoru . Poskytovalo důraz v klíčové oblasti, o níž se mnozí domnívali, že byla jinými metodikami opomíjena: záměrná iterativní analýza rizik, zvláště vhodná pro komplexní komplexní systémy.

Základní principy jsou:

  • Důraz je kladen na hodnocení rizik a minimalizaci rizika projektu rozdělením projektu na menší segmenty a poskytnutím větší snadnosti změny během vývojového procesu, jakož i poskytnutím příležitosti vyhodnotit rizika a zvážit zvážení pokračování projektu v průběhu životního cyklu.
  • „Každý cyklus zahrnuje postup stejnou sekvencí kroků, pro každou část produktu a pro každou úroveň jeho zpracování, od celkového konceptu provozního dokumentu až po kódování každého jednotlivého programu.“
  • Každá cesta kolem spirály prochází čtyřmi základními kvadranty: (1) určit cíle, alternativy a omezení iterace; (2) vyhodnotit alternativy; Identifikovat a řešit rizika; (3) vyvíjet a ověřovat výstupy z iterace; a (4) naplánovat další iteraci.
  • Začněte každý cyklus identifikací zúčastněných stran a jejich „podmínek výhry“ a ukončete každý cyklus kontrolou a odhodláním.

Pokročilé metodiky

Mezi další metodiky softwarových projektů na vysoké úrovni patří:

  • Vývoj založený na chování a řízení obchodních procesů
  • Model chaosu - hlavním pravidlem je vždy nejprve vyřešit nejdůležitější problém.
  • Metodika přírůstkového financování - iterativní přístup
  • Lehká metodika - obecný termín pro metody, které mají jen několik pravidel a postupů
  • Metoda analýzy a návrhu strukturovaných systémů - konkrétní verze vodopádu
  • Pomalé programování, jako součást většího pomalého pohybu , klade důraz na pečlivou a postupnou práci bez (nebo minimálních) časových tlaků. Pomalé programování má za cíl vyhnout se chybám a příliš rychlým plánům vydání.
  • V -Model (vývoj softwaru) - rozšíření modelu vodopádu
  • Unified Process (UP) je iterativní metodický rámec pro vývoj 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 spustitelných iterací softwaru v této fázi vývoje: počátek, zpracování, konstrukce a pokyny. Existuje mnoho nástrojů a produktů, které usnadňují implementaci UP. Jednou z populárnějších verzí UP je Rational Unified Process (RUP).
  • Metodika velkého třesku - přístup k malým nebo nedefinovaným projektům, obvykle sestávající z malého až žádného plánování s vysokým rizikem.

Zpracovat meta-modely

Některé „ procesní modely “ jsou abstraktní popisy pro hodnocení, porovnávání a zlepšování konkrétního procesu přijatého organizací.

  • ISO/IEC 12207 je mezinárodní norma popisující metodu výběru, implementace a monitorování životního cyklu softwaru.
  • CMMI (CMMI) je jedním z předních modelů a na základě osvědčených postupů. Nezávislá hodnocení hodnotí organizace, jak dobře dodržují definované procesy, nikoli kvalitu těchto procesů nebo vyráběného softwaru. CMMI nahradilo CMM .
  • ISO 9000 popisuje standardy pro formálně organizovaný proces výroby produktu a metody řízení a monitorování pokroku. Ačkoli byla norma původně vytvořena pro výrobní sektor, byly na vývoj softwaru použity také normy ISO 9000. Stejně jako CMMI, certifikace podle ISO 9000 nezaručuje kvalitu konečného výsledku, pouze jsou dodržovány formalizované obchodní procesy.
  • ISO/IEC 15504 Informační technologie - Hodnocení procesů, známé také jako SPICE (Software Process Improvement Capability Determination), je „rámec pro hodnocení softwarových procesů“. Cílem této normy je stanovit jasný model pro porovnávání procesů. SPICE se používá podobně jako CMMI. Modeluje procesy pro správu, řízení, vedení a monitorování vývoje softwaru. Tento model se pak používá k měření toho, co vývojová organizace nebo projektový tým ve skutečnosti dělá během vývoje softwaru. Tyto informace jsou analyzovány za účelem identifikace slabých stránek a zlepšení. Rovněž identifikuje silné stránky, v nichž lze pokračovat nebo je integrovat do běžné praxe pro danou organizaci nebo tým.
  • ISO/IEC 24744 Softwarové inženýrství-Metamodel pro metodiky vývoje , je metamodel pro metodiky vývoje softwaru založený na výkonovém typu.
  • SPEM 2.0 od skupiny Object Management Group
  • Metodika měkkých systémů - obecná metoda pro zlepšování procesů řízení
  • Metodické inženýrství - obecná metoda pro zlepšování procesů informačního systému

V praxi

Tři základní přístupy aplikované na rámce metodologie vývoje softwaru.

V průběhu let se vyvinula řada takových rámců, z nichž každý má své vlastní uznávané silné a slabé stránky. Jeden rámec metodologie vývoje softwaru nemusí být nutně vhodný pro použití ve všech projektech. Každý z dostupných metodických rámců je nejvhodnější pro konkrétní druhy projektů na základě různých technických, organizačních, projektových a týmových úvah.

Organizace pro vývoj softwaru zavádějí metodiky procesů, které usnadňují proces vývoje. Někdy mohou dodavatelé vyžadovat použité metodiky, příkladem je americký obranný průmysl , který k získání zakázek vyžaduje hodnocení založené na procesních modelech . Mezinárodní norma pro popis metody výběru, implementace a monitorování životního cyklu softwaru je ISO/IEC 12207 .

Desetiletí trvajícím cílem bylo najít opakovatelné a předvídatelné procesy, které zlepšují produktivitu a kvalitu. Někteří se snaží systematizovat nebo formalizovat zdánlivě neukázněný úkol při navrhování softwaru. Jiní používají techniky projektového řízení na navrhování softwaru. Velké množství softwarových projektů nesplňuje jejich očekávání, pokud jde o funkčnost, náklady nebo plán dodávek - některé pozoruhodné příklady najdete v Seznamu neúspěšných a přebudovaných zakázkových softwarových projektů .

Organizace mohou vytvořit skupinu Software Engineering Process Group (SEPG), která je ústředním bodem pro zlepšování procesů. Tato skupina, složená z praktických lékařů s různými dovednostmi, je středem úsilí o spolupráci všech v organizaci, kteří se podílejí na zlepšování procesů softwarového inženýrství.

Konkrétní vývojový tým může také souhlasit s podrobnostmi programovacího prostředí, jako je to, jaké integrované vývojové prostředí se používá, a jedním nebo více dominantními programovacími paradigmaty , pravidly programovacího stylu nebo výběrem konkrétních softwarových knihoven nebo softwarových rámců . Tyto detaily obecně nejsou dány volbou modelu nebo obecné metodiky.

Životní cyklus vývoje softwaru (SDLC)

Viz také

Reference

externí odkazy