Proces vývoje softwaru na základě cíle - Goal-Driven Software Development Process

Proces vývoje softwaru na základě cíle (HDP) je iterativní a přírůstkové vývoj softwaru technika. I když podobný ostatním moderním procesní modely „HDP se primárně zaměřuje na identifikaci cílů před stanovení požadavků a výslovné využití návrhového přístupu zdola nahoru.

Následující části vycházejí z příspěvku Cílený vývoj softwaru [1] kde byl představen koncept HDP.

Odůvodnění

Prvním argumentem k přijetí principů HDP je aspekt požadavků. Při vývoji softwaru je velká koncentrace na požadavky (např. Typické pro model vodopádu ) způsobuje nadměrné náklady a sníženou kvalitu výsledku, zejména z následujících důvodů:[1]

  • Požadavky obvykle nejsou totožné s obchodními cíli z důvodu omezených znalostí autora o technických možnostech a jejich nákladech - tyto požadavky obvykle zahrnují zbytečné nákladné přání a vylučují technicky jednoduché funkce, které by poskytly podstatný přínos.
  • Formalizace podporovaného obchodního procesu během vývoje obvykle odhalí nesrovnalosti a mezery v tomto procesu, které je třeba vyrovnat změnami samotného procesu nebo role softwarového systému.

Výsledkem těchto dvou efektů je obvykle velké množství požadavků na změny během a po vývoji (s tím spojené překročení času a nákladů), proto je zapojení uživatelů považováno za kritický faktor úspěchu projektu.[2]

Zadruhé, i když je zaveden softwarové procesy zdokonalit požadavky až po implementaci, vývojový proces zaměřený na cíl doporučuje pokusit se najít optimální mapování mezi obchodními cíli a schopnostmi technické platformy v iterativní procesu, stejně s ohledem na a přizpůsobení obchodních cílů a technických aspektů tak, aby došlo k optimálnímu, konvergentní řešení.

Proces vývoje zaměřený na cíl umožňuje zúčastněným stranám:[3]

  • Objevte případy použití, které jsou přizpůsobeny požadavkům podle obchodních cílů
  • Vytvořte most mezi cíli a architekturou IT

Klíčové principy

Proces vývoje softwaru na základě cílů

Identifikace společného cíle

Jak úzce souvisí s Cílová otázka - metrika paradigma, a nejvyšší úrovně je definován jako neformální popis toho, co chce účastník změnit nebo zlepšit ve svém obchodním prostředí, rozložit se na konkrétnější dílčí cíle. S každým cílem je navíc spojena sada otázek, která charakterizuje způsob, jakým bude software po každém testován na definované cíle opakování.

Jelikož se jedná o klíčový princip GDP, společná identifikace cílů spojuje znalosti uživatelů a vývojářů softwaru. Zatímco definice cíle je řízena shora dolů, rozhodování, zda je proveditelný cíl, je orientováno zdola nahoru.

Konvergence shora dolů a zdola nahoru

Více informací viz Design shora dolů a zdola nahoru.

Zatímco orientace shora dolů podporuje horizontální týmovou organizaci, přístupy zdola nahoru se snaží poskytovat zobecněné komponenty nebo služby, což vede k lepší spokojenosti uživatelů.[4] Společná identifikace cílů zavedených HDP umožňuje kombinovat aspekty shora dolů a zdola nahoru („myšlení shora dolů a jednání zdola nahoru” [1]) podporovat artefakty konzistence a umožnění vertikální organizace týmu.

Vertikální organizace týmu

Na rozdíl od horizontálně organizovaných projektových týmů, kde programátoři implementují řešení specifikované týmem modelování, vyžaduje vertikální organizace implikovaná HDP kvalifikované a kvalifikované všeobecné pracovníky. Jak uvedl IBM Rational Unified Process mohou jednotliví vývojáři a by měl mít na projektu více rolí, abyste se vyhnuli zbytečným režijním nákladům a konfliktům.

Role a lidé

Vzhledem ke své vertikální organizaci vyžaduje HDP kvalifikované všeobecné pracovníky se schopností plnit mnoho rolí procesu:

  • Programátoři (zodpovědný za konvergenci shora dolů a zdola nahoru)
  • Obchodní analytici (spolupracovat s programátory při identifikaci cíle a později při testování)
  • Softwaroví architekti (sledujte celý projekt)
  • Projektový manažer (přiřazuje zdroje, sleduje čas a úsilí, vytváří produktivní prostředí)
  • Inženýr požadavků

Minimalizace velikosti projektu

Podle GDP je dalším klíčem k úspěchu u velkých projektů minimalizace velikosti projektu ve všech aspektech, tj. Omezení počtu cílů a softwaru artefakty jako jsou dokumenty, specifikace požadavků, modely atd., ale také omezit počet zaměstnanců, vyhnout se vzájemnému čekání a velikosti kódu.

Minimalizace velikosti vede ke zvýšené udržovatelnosti a proměnlivosti systému na obchodní procesy, protože jsou nejpravděpodobnějším faktorem, který se v budoucnu změní.[5]

Činnosti

Každá iterace začíná identifikací obchodních cílů a jejich priorit a končí spuštěnou verzí softwarového systému odpovídající vybraným cílům.

Zatímco přírůstkový vývoj softwarového systému se provádí také v jiných softwarové procesy, je rozsah iterace HDP rozšířen o diskusi o obchodních cílech po každý iterace, o které se věří, že samotné obchodní cíle dozrávají s dostupností použitelné implementace.[1]

Mezi hlavní činnosti patří:

  1. Identifikace a stanovení priorit cílů (malé skupiny nejvýše 5 osob sestávající ze zúčastněných stran a / nebo obchodních analytiků a programátorů)
  2. Vertikální rozdělení úkolů (vybrané cíle jsou přiřazeny do skupin nejvýše 4 programátorů)
  3. Implementace a testování (testy založené na implementaci během implementace, testy zaměřené na cíl na konci každé iterace)

Tyto aktivity lze také rozdělit do šesti hlavních kroků:[3]

  1. Seskupte obchodní požadavky podle cílů
  2. Formalizujte chování systému řízeného cílem uvnitř procesů
  3. Monitorovat pokrok v realizaci cílů (volitelně)
  4. Přiřaďte odpovědnosti účastníkům procesů
  5. Zapojte chování do architektonické páteře řízené cílem a hrajte
  6. Integrujte aplikační omezení aktérů

Reference

  1. ^ A b C d Schnabel, I .; Pizka, M. „Vývoj softwaru zaměřeného na cíl“. ŠÍT. 2006. IEEE Computer Society. Citováno 2008-12-30.
  2. ^ Zpráva o chaosu. Technická zpráva, Standish Group, 1994.
  3. ^ A b Berkem, Birol (březen – duben 2006). "Jak sladit IT se změnami pomocí UML a podle BMM". Journal of Object Technology. 5 (2): 85–102. doi:10.5381 / jot.2006.5.2.c9. Citováno 2008-12-30.
  4. ^ Pizka, M .; Bauer, A. „Stručná filozofie vývoje softwaru shora dolů a zdola nahoru“. IPWSE. 2004. IEEE Computer Society. Citováno 2008-12-30.
  5. ^ Panas, Löwe, Asmann. Směrem k jednotné architektuře obnovy pro reverzní inženýrství. Proc. Intern. Konf. o softwarovém inženýrství a praxi SERP’03, svazek 1, strany 854–860, Las Vegas, NV, červen 2003. CSREA Press.

externí odkazy