区四届人大五次会议建议目录

百度 　　乡村振兴战略是社会主义新农村建设的升华版。

Proces vyvoje softwaru (anglicky software development process) je v softwarovém in?enyrství proces ?lenění práce p?i vyvoji softwaru na r?zné fáze s cílem zkvalitnit proces návrhu softwaru, správu softwaru a ?ízení softwarového projektu. Cely proces vyvoje softwaru se také nazyvá ?ivotní cyklus vyvoje softwaru (anglicky software development life cycle, SDLC). Metodika m??e zahrnovat i p?edbě?nou definici ur?itych dodávanych polo?ek a artefakt?, které projektovy tym vytvá?í a dokon?uje pro vyvoj nebo údr?bu aplikace.

Vět?inu moderních proces? vyvoje lze vágně popsat jako agilní metodiky. K jinym metodikám pat?í vodopádovy model, prototypování, iterativní a inkrementální vyvoj, spirálovy vyvoj, 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“ vyvoje 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? vyvoje softwaru, které odpovídají spirálovému modelu ?ivotního cyklu. Proces vyvoje softwaru je ?asto pova?ován za ?ást ?ivotního cyklu vyvoje systému.

Historie

Metodiky vyvoje 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 vyvoje systému (anglicky Systems Development Life Cycle, SDLC). Hlavní my?lenkou SDLC bylo ?velmi promy?leně, strukturovaně a metodicky sledovat vyvoj informa?ních systém?, aby ka?dá fáze ?ivotního cyklu – od po?áte?ní my?lenky po doru?ení vysledné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 ?vyvoj rozsáhlych funk?ních firemních systém? pro éru velkych obchodních konglomerát?. ?innost informa?ních systém? té doby byla zamě?ena na zpracování hromadnych dat a intenzivní numerické vypo?ty.“

Metodiky, procesy a frameworky sahají od ur?itych p?edepsanych ?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?sobenych 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í anglicky 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á analyza systém? a metoda návrhu) od roku 1980
• Information Requirement Analysis/Soft systems methodology (analyza informa?ních po?adavk? a metodika softwarovych 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 softwarovy proces a kvalita softwaru se vzájemně ovlivňují; v praxi byly pozorovány některé neo?ekávané aspekty a ú?inky.

Dal?í proces vyvoje softwaru byl vytvo?en v oblasti otev?eného softwaru a svobodného softwaru. P?ijetí těchto nejlep?ích známych praktik a vytvo?ení proces? uvnit? hranic spole?nosti se nazyvá InnerSource.

Prototypování

Softwarové prototypování je zalo?eno na vytvá?ení prototyp?, neboli ?áste?nych verzí softwaru.

Základní principy jsou:

• Prototypování není samostatná, úplná, vyvojová 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álovy 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 vyvoje.
• Zákazník nebo klient je zapojen do celého procesu vyvoje, co? zvy?uje ?anci, ?e p?ijme kone?nou implementaci.
• Zatímco u některych prototyp? se o?ekává, ?e p?ispějí k ujasnění směru vyvoje, a pak budou zahozeny, v některych p?ípadech je mo?né z prototypu vyvíjet cílovy systém.

Prototypování klade d?raz na p?ístup, ?e pro zabránění ?e?ení nesprávnych problém?, je nutné d?kladné pochopení podstaty obchodního problému.

Metodiky

Agilní vyvoj

Podrobněj?í informace naleznete v ?lánku Agilní metodiky.

?Agilní vyvoj softwaru“ je skupina metodik vyvoje softwaru zalo?enych na iterativním vyvoji, kde se po?adavky a ?e?ení postupně vyvíjejí těsnou spoluprací mezi samoorganizujícími se multifunk?ními tymy. Termín se objevil v roce 2001, kdy byl formulován Agilní manifest.

Agilní metodiky jsou zalo?eny na iterativním vyvoji, ale usilují o odleh?eněj?í a více na lidi zamě?eny 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

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í jednotlivych vyvojá?? do sdílené větve. Pr?bě?nou integraci jako první navrhl a pojmenoval Grady Booch ve své metodice z roku 1991, ktery 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í vyvoj

Podrobněj?í informace naleznete v ?lánku Iterativní a inkrementální vyvoj.

Pro zkombinování lineárních a iterativních metodik vyvoje 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 vyvojového procesu.

Existují t?i hlavní varianty inkrementálního vyvoje:

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 vyvoje s díl?ími p?ír?stky jsou definovány celkové po?adavky
3. Po?áte?ní softwarovy koncept, analyza po?adavk? a návrh architektury a jádra systému jsou definovány pomocí vodopádového modelu, na ktery navazuje inkrementální implementace, která je zakon?ena instalací vysledné 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 vyvoje softwaru, která up?ednostňuje iterativní vyvoj a velmi rychlou konstrukci prototyp? místo velkého plánování. ?Plánování“ vyvoje softwaru pomocí RAD se st?ídá se samotnym 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á vyvojem p?edbě?nych datovych model? a model? obchodního procesu pomocí strukturovanych 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?í vyvoj vede k tomu, ?e ?kombinované obchodní po?adavky a popis technického návrhu je pou?it pro zkonstruování novych systém?“.

Název RAD byl nejd?íve pou?íván pro popis procesu vyvoje softwaru, ktery zavedl James Martin v roce 1991. Podle Whitten (2003) jde o slou?ení r?znych strukturovanych technik, zvlá?tě in?enyrství informa?ních technologií ?ízenych daty, s technikami prototypování pro urychlení vyvoje softwarovych systém?.

Základní principy Rapid Application Development jsou:

• Klí?ovym cílem je rychly vyvoj 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 vyvojové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 vyvoje), aktivní zapojení u?ivatele a automatizovanych vyvojovych 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?enyrská kvalita má men?í vyznam.
• Projektové ?ízení zaji??uje prioritizaci vyvoje 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 strukturovanych 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í vyvoj a správa.
• Do této metodiky lze zapracovat standardní systémovou analyzu a metody návrhu.

Spirálovy vyvoj

Spirálovy model (Boehm, 1988)

Podrobněj?í informace naleznete v ?lánku Spirálovy model.

V roce 1988 publikoval Barry Boehm formální ?spirálovy model“ vyvoje softwarového systému, ktery kombinuje některé klí?ové aspekty vodopádového modelu a metodiky Rapid Application Development s cílem zkombinovat vyhody koncept? shora dol? a zdola nahoru. Poskytl d?raz na klí?ovou oblast, o které se mnozí domnívají, ?e byla jinymi metodikami p?ehlí?ena: promy?lená iterativní analyza 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 vyvojové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 celkovy koncept fungování a? po kódování ka?dého jednotlivého programu.“
• 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) vyvoj a verifikace dodávanych polo?ek v rámci iterace; a (4) plánování dal?í iterace.
• Ka?dy cyklus je t?eba zahájit identifikací zainteresovanych osob a jimi stanovenych ?podmínek úspě?né realizace“ a zakon?it vyhodnocením a návrhem změn.

Vodopádovy vyvoj

Podrobněj?í informace naleznete v ?lánku Vodopádovy model.

P?sobnost/?innosti procesu vyvoje softwaru reprezentována ve vodopádovém modelu. Existuje několik dal?ích model?, které reprezentuje tento proces.

Vodopádovy model je sekven?ní p?ístup k vyvoji softwaru, ve kterém je vyvoj vnímán jako neustály tok (podobny vodopádu) několika fázemi, typicky:

• Analyza po?adavk?, jejím? cílem je specifikace softwarovych 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

Jako první formální popis metody je ?asto citován ?lánek, ktery publikoval Winston W. Royce v roce 1970 a?koli Royce v tomto ?lánku termín ?vodopádovy“ nepou?il. Royce tento model prezentoval jako ukázku chybného, nefungujícího modelu.

Základní principy jsou:

• Projekt je rozdělen na sekven?ní fáze, z nich? některé se mohou p?ekryvat 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 ?iroky napsany 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ádovy model je tradi?ní in?enyrsky p?ístup aplikovany na oblast vyvoje softwaru. Striktně vodopádovy 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áhlych projekt? pro vládní ú?ady, které p?ekro?ily rozpo?et, nebyly dokon?eny v?as, p?ípadně jejich vysledky 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?adovany, vodopádovy model bylo z vět?í ?ásti nahrazeny nověj?í verzí flexibilněj?í a versatile metodika vyvinuté konkrétně pro vyvoj softwaru. Viz Kritika vodopádového modelu.

Dal?í metodiky

K dal?ím vysokoúrovňovym metodikám ?ízení softwarového projektu pat?í:

• Behavior-driven development a ?ízení obchodních proces?
• 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) – obecny termín pro metody, které mají pouze několik málo pravidel a praktik
• Structured systems analysis and design method (strukturovaná analyza 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) ?asovymi tlaky. Pomalé programování se sna?í zabránit chybám a p?íli? rychlym rozvrh?m vydání.
• V-Model (vyvoj softwaru) – roz?í?ení vodopádového modelu
• Unified Process (UP) je iterativní metodika vyvoje softwaru, zalo?ená na Unified Modeling Language (UML). UP organizuje vyvoj softwaru do ?ty? fází, z nich? ka?dá se skládá z jedné nebo více proveditelnych iterací softwaru, v jedné z následujících fází vyvoje: inception, elaboration, construction, and guidelines. Existuje mnoho nástroj? a vyrobk?, 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 vyběr, implementaci a monitorování ?ivotního cyklu softwaru.
• Jedním z vedoucích model? je Capability Maturity Model Integration (CMMI) zalo?eny na ově?enych 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á?eny software. CMMI nahradil star?í Capability Maturity Model.
• ISO 9000 popisuje standardy formálně organizovaného procesu vyroby a metody ?ízení a sledování postupu. A?koli norma byla p?vodně vytvo?ena pro vyrobní sektor, byly ISO 9000 standardy aplikovány také na vyvoj softwaru. Stejně jako CMMI nezaru?uje certifikace podle ISO 9000 kvalitu kone?ného vysledku, ale pouze to, ?e byly dodr?eny formalizované obchodní procesy.
• ISO/IEC 15504 Information technology — Process assessment také známy jako Process Improvement Capability Determination (SPICE), je ?rámec pro hodnocení softwarovych 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í vyvoje softwaru. Tento model pak se pou?ívá pro mě?ení, co vyvojá?ská firma nebo projektovy tym skute?ně dělá p?i vyvoji 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? obvyklych v p?íslu?né organizaci nebo tymu.
• ISO/IEC 24744 Software Engineering — Metamodel for Development Methodologies, je metamodel metodik vyvoje softwaru zalo?eny na poten?ních typech (anglicky power type) pou?ívanych v Unified Modeling Language
• SPEM 2.0 vytvo?eny 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 vyvoje softwaru.

Za léta vyvoje se objevilo mno?ství metodik vyvoje softwaru s r?znymi p?ednostmi i slabinami. Ur?itá metodika nemusí byt vhodná pro pou?ití ve v?ech druzích projekt?. Ka?dy z dostupnych metodickych framework? jsou nejvhodněj?í pro ur?ity druh projekt? zalo?enych na r?znych technickych, organiza?ních, projektovych a tymovych kritériích.

Firmy, které vyvíjejí software implementují r?zné metodiky, aby si zjednodu?ily proces vyvoje. 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 vyběru, implementace a sledování ?ivotního cyklu softwaru je ISO/IEC 12207.

P?i vytvá?ení metodik vyvoje softwaru bylo po desetiletí hlavním úkolem hledání opakovatelnych a p?edvídatelnych 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í softwarovych projekt? nesplnilo o?ekávání kv?li nedostate?né funk?nosti, vysoké ceně nebo rozvrhu doru?ení – p?íklady jsou v seznamu zakázkovych softwarovych projekt?, které selhaly nebo vyrazně 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 byt 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 vyvoje softwaru.

Ur?ity vyvojovy tym m??e také schválit detaily prost?edí pro programování, nap?íklad jaké integrované vyvojové prost?edí (IDE) se bude pou?ívat a jedno nebo více hlavních programovacích paradigmat, styl zápisu programu nebo volbu ur?itych softwarovych knihoven nebo softwarové frameworky. Tyto detaily obecně nejsou vynuceny volbou modelu nebo obecné metodiky.

?ivotní cyklus vyvoje softwaru (SDLC)

Odkazy

Reference

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

Související ?lánky

• ?ivotní cyklus vyvoje systém?
• CASE nástroje (některé z těchto nástroj? podporují ur?itou metodiku)
• Seznam filosofií vyvoje softwaru
• Koncept softwarového in?enyrství
• OpenUP
• ?ízení projekt?
• Vyvoj softwaru
• Odhad pracnosti vyvoje softwaru
• ?ivotní cyklus vydání softwaru
• ?ivotní cyklus informa?ního systému
• Vyvoj softwaru
• Návrh shora dol? a zdola nahoru#Matematická informatika

Literatura

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

Externí odkazy

• Obrázky, zvuky ?i videa k tématu Proces vyvoje softwaru na Wikimedia Commons
• Selecting a development approach at cms.hhs.gov.
• Gerhard Fischer, "The Software Technology of the 21st Century: From Software Reuse to Collaborative Software Design", 2001
• Subway map of agile practices at Agile Alliance