Vývoj rychlosti internetu - Internet-Speed Development
Vývoj rychlosti internetu je Agilní vývoj softwaru vývojová metoda využívající kombinovanou spirálový model /model vodopádu s každodenními sestaveními zaměřenými na vývoj produktu s vysokou rychlostí.
Byl vyvinut na konci devadesátých let, protože vývoj softwaru se rychle měnil. Společnosti měly problémy s dodáváním produktů se správnými požadavky v době plánované na projekt a jako takové přecházely na agilnější metody vývoje softwaru. Více podrobností o tom, jak byla vyvinuta metoda rychlosti internetu, lze vidět na evoluční mapě v dokumentu Abrahamssona.[1]
Hlavní myšlenky vývoje rychlosti internetu
Jedním z největších problémů softwarového inženýrství je to, že se požadavky rychle mění a byla vytvořena metoda vývoje rychlosti internetu, aby se přizpůsobila této situaci. Cílem je spojit dva hlavní standardy v modelech softwarového inženýrství, a to spirálový model a model vodopádu do nového modelu a na tomto novém modelu založit novou metodu softwarového inženýrství. Hlavní nevýhodou modelu vodopádu bylo, že byl velmi tuhý a ne příliš flexibilní, pokud jde o změny v požadavcích, zatímco nevýhodou spirálového modelu bylo, že nebyl příliš strukturovaný. Myšlenkou vývoje rychlosti internetu je, že kombinace těchto modelů vyústí v metodu, která nemá tyto nevýhody a je lepší metodou pro použití v situacích, kdy se požadavky mohou rychle měnit, ale projekt musí být proveden ve strukturovaném způsob.
Cíl metody
Cílem metody vývoje rychlosti internetu je umožnit vývojářům softwaru provádět projekt strukturovaným způsobem, ale stále se umět přizpůsobit potřebám zákazníka. Jeho cílem je dodat softwarový produkt v krátké době prostřednictvím intenzivního vývoje. Metoda poskytuje prostředky k dodání plně implementovaného systému a má také způsoby, jak určit pokrok v projektu pomocí milníků. Jedna z hlavních verzí této metody je vytvořena společností Microsoft a nazývá se Microsoft Solutions Framework.
Koncepty za metodou vývoje rychlosti internetu
První koncept, který je pro rozvoj rychlosti internetu velmi důležitý, je vytvoření vize a rozsah (projektový management). To znamená, že na začátku projektu je vytvořena globální definice systému, která vysvětluje, co systém chce být a co je v rozsahu a co ne. Toto je jeden ze základních kroků, protože dává vývojářům několik pokynů, co bude systém, aniž by zamrzly jakékoli požadavky. Rozsah lze dokumentovat v a prohlášení o vizi.
Dalším velmi důležitým konceptem v rámci této metody je správa rozsahu. Rozsah je třeba spravovat během celého projektu, aby se tomu zabránilo plíživý rozsah což má za následek zpoždění. Rozsah bude stanoven brzy a změny rozsahu (jako přidání dalších funkcí, které byly nejprve zvažovány nad rámec projektu) budou vyhodnoceny a buď přijaty, nebo zamítnuty. Lze provést změny v oboru, ale to bude vždy ovlivněno kompromisem mezi funkcemi, zdroji a časem.
Metoda vývoje rychlosti internetu se velmi liší od tradičních metod, a proto využívá principy agilní metody. Zaměřuje se na přizpůsobení požadavkům a vychází ze základních principů vývoje agilního softwaru.
Vývoj rychlosti internetu se také zaměřuje na použití jedné architektury pevné architektury, ze které je produkt postaven, a do značné míry se spoléhá na nástroje ke zvýšení rychlosti vývoje.
Další základní koncepcí vývoje rychlosti internetu je, že se také zaměřuje na využívání malých týmů. Myšlenka je, že všechny projekty lze rozdělit na menší aktivity, které lze často provádět paralelně. Menší týmy se často mohou více soustředit na svůj úkol a je snazší určit odpovědnost a sledovat pokrok v rámci projektu.
Posledním konceptem diskutovaným v této položce vývoje rychlosti internetu je koncept paralelního vývoje. Tento koncept v podstatě znamená, že veškerý vývoj softwaru probíhá co nejčastěji paralelně. To umožní velmi rychlý vývoj a umožní menším týmům se co nejvíce soustředit na své vlastní vlastnosti, což má dobrý výsledek v kvalitě. Aby bylo zajištěno, že menší týmy budou spolupracovat na vytvoření konečného systému, je nutné často synchronizovat jejich vývoj. To lze provést pomocí denní sestavení což znamená, že všichni vývojáři zkontrolují svůj kód na konci dne, po kterém je vytvořeno sestavení, které lze poté vyhodnotit a otestovat, aby bylo možné sledovat pokrok. Po dokončení funkce v zabudování je třeba otestovat a vylepšit, což se někdy nazývá proces synchronizace a stabilizace. Vyvinuté funkce jsou synchronizovány s sestavením a testovány. Po těchto testech budou všechny chyby opraveny a funkce může být vylepšena, aby fungovala lépe (což je stabilizační část).
Vývoj rychlosti internetu je založen na agilních principech a jako takový má mnoho podobností Extrémní programování, Racionální jednotný proces, DSDM a Vývoj řízený funkcemi. Vývoj rychlosti internetu se však od těchto metod liší, protože zahrnuje také rozsáhlejší plánování řízení rizik a jako velmi důležitý cíl projektu má kvalitu.[2] Fáze vývoje rychlosti internetu také ukazuje některé podobnosti s open-source software vývojový model, protože mnoho vývojářů po celém světě může být součástí vývojového procesu z důvodu komunikace prostřednictvím Internetu a používání úložišť pro ukládání kódu a dokumentace.
Fáze vývoje rychlosti internetu
Model za touto metodou vypadá takto:
Obrázek 1: Fázový modelTento model ukazuje pět základních fází metody. Tyto fáze budou vysvětleny v následujících částech této položky. Fáze jsou: předvídání, plánování, vývoj, stabilizace a nasazení. Po dokončení tohoto cyklu je připravena verze systému a začíná nový cyklus vytváření nové verze. Fáze jsou vysvětleny v následujících částech a jsou zobrazeny prostřednictvím a meta-modelování technika. Další podrobnosti o multiplicitách a konceptech v kontextu projektu lze později vidět v celkovém datovém modelu.
Fáze předvídání
Fázi předvídání lze modelovat následovně:
Obrázek 2: Představení fázového procesního / datového modelu
| Aktivita | Definice (zdroj) |
|---|---|
| Analyzujte požadavky | Během fáze předvídání musí být identifikovány a analyzovány obchodní požadavky. „Ty jsou ve fázi plánování upřesňovány přísněji.“ (Procesní model Lékařů bez hranic)[3] |
| Definujte cíle a omezení | "Předvídání vytvořením pohledu na vysoké úrovni na cíle a omezení projektu." (MSF Process model)[3] |
| Tým formuláře | Vytvoření základního týmu. |
| Vytvořte vizi / rozsah | "Příprava a dodání dokumentu vize / rozsahu." (MSF Process model)[3] |
| Vytvořit posouzení rizik | "Během fáze předvídání připravuje tým dokument o riziku a představuje hlavní rizika." (Procesní model Lékařů bez hranic)[3] |
Tabulka 1: Předvídání aktivit
Základní činnosti prováděné ve fázi předvídání jsou analýza požadavků, sestavení týmu pro projekt, stanovení rizik a rozsahu projektu. Z požadavků a cílů projektu je vytvořen dokument Vision / Scope. Tento dokument popisuje, jaký má být produkt při dodání. Neobsahuje velmi podrobné funkce produktu.
| Pojem | Definice (zdroj) |
|---|---|
| VIZE / OBLAST PŮSOBNOSTI | "Dokument definující vizi a rozsah." (MSF Process model)[3] |
| VIDĚNÍ | “Viděníje neomezený pohled na to, jaké řešení může být. “ (Procesní model Lékařů bez hranic)[3] |
| ROZSAH | “Rozsah identifikuje část (části) vize, které lze dosáhnout v rámci omezení projektu. “ (MSF Process model)[3] |
| DOKUMENT O POSOUZENÍ RIZIK | „Standardizovaný dokument pro hodnocení rizik“ (Disciplína řízení rizik Lékařů bez hranic)[4] |
| PRIORITIZOVANÝ SEZNAM RIZIK | „Podrobné informace o riziku, včetně stavu projektu, kontextu, hlavní příčiny a metrik použitých pro stanovení priorit (pravděpodobnost, dopad, expozice), jsou pro každé riziko často zaznamenány ve formuláři prohlášení o riziku.“ (Disciplína řízení rizik Lékařů bez hranic)[4] |
| PLÁNOVÁNÍ RIZIK | "Překlad seznamu prioritních rizik do akčních plánů." (Disciplína řízení rizik Lékařů bez hranic)[4] |
| DOKUMENT O STRUKTURĚ PROJEKTU | „Dokument o struktuře projektu obsahuje informace o tom, jak je tým organizován a kdo hraje, jaké role a má konkrétní odpovědnost. Dokument o struktuře projektu také objasňuje řetězec odpovědnosti vůči zákazníkovi a určeným kontaktním místům, které má projektový tým se zákazníkem. Ty se mohou lišit v závislosti na okolnostech projektu. “ (MSF Process model)[3] |
| ORGANIZACE TÝMU | "Informace o organizaci týmu." (MSF Process model)[3] |
| KONTAKTNÍ BODY | "Určená kontaktní místa, která má projektový tým se zákazníkem." (Procesní model Lékařů bez hranic)[3] |
| ROLE TÝMU | "Definice, kdo hraje jakou roli a má konkrétní zodpovědnost." (Procesní model Lékařů bez hranic)[3] |
Tabulka 2: Koncepty ve fázi předvídání
Fáze plánování
Obrázek 3: Procesní / datový model fáze plánování
| Aktivita | Definice (zdroj) | |
|---|---|---|
| Definujte požadavky | Na začátku plánovací fáze tým analyzuje a dokumentuje požadavky v seznamu nebo nástroji. Požadavky spadají do čtyř kategorií: obchodní požadavky, uživatelské požadavky, provozní požadavky a systémové požadavky (požadavky samotného řešení). “ (MSF Process model)[3] | |
| Stopové požadavky na funkce | „Jak tým postupuje při navrhování řešení a vytváření funkčních specifikací, je důležité jej udržovat sledovatelnost mezi požadavky a funkcemi. Sledovatelnost nemusí být prováděna individuálně. Zachování sledovatelnosti slouží jako jeden ze způsobů, jak zkontrolovat správnost návrhu a ověřit, zda návrh splňuje cíle a požadavky řešení. “ (MSF Process model[3] | |
| Definujte funkční specifikaci | "Tým připravuje funkční specifikaci." (MSF Process model[3] | |
| Vytvořit plánování | Odhadněte rizika | Tým vytvoří odhad rizika. |
| Odhad nákladů | Tým vytvoří odhad nákladů. | |
| Vytvářejte pracovní plány | Tým vytváří pracovní plány. | |
| Vytvořit plány | Tým vytváří plány. | |
| Vytvořit design | Vytvořte model případu použití | "Začíná to systematickou analýzou." uživatelské profily (nazývané také „persony“), které popisují různé typy uživatelů a jejich pracovní funkce (provozní zaměstnanci jsou také uživatelé). Mnoho z toho se často děje během fáze předvídání. Ty jsou rozděleny do řady scénáře použití, kde se konkrétní typ uživatele pokouší dokončit typ aktivity, jako je registrace recepce v hotelu nebo správa uživatelských hesel pro správce systému. Nakonec je každý scénář použití rozdělen do konkrétní posloupnosti úkolů, známých jako případy užití, které uživatel provádí k dokončení této činnosti. Říká se tomu „storyboarding“. “ (MSF Process model[3] |
| Vytvořte koncepční návrh | Tvorba koncepčního návrhu. | |
| Vytvořte logický design | Vytvoření logického návrhu. | |
| Vytvořte fyzický design | Vytvoření fyzického designu. | |
| Vytvořit architekturu | Vytvoření architektury produktu. | |
Tabulka 3: Plánovací činnostiVe fázi plánování je z požadavků vytvořena funkční specifikace. Vybrané funkce jsou zahrnuty v této specifikaci (a Metoda MoSCoW se často používá pro funkce, aby mohly být snadněji upřednostňovány). V této fázi je také vytvořen základní návrh a plánování. Návrh však v této fázi není zmrazen, protože ve fázi vývoje mohou být provedeny změny.
| Pojem | Definice (zdroj) |
|---|---|
| SEZNAM POŽADAVKŮ | Dokumentace požadavků v seznamu nebo nástroji. “ (MSF Process model[3] |
PLÁN ŘÍZENÍ RIZIK | Dokument o tom, jak tým plánuje implementovat proces řízení rizik v rámci projektu. “ (Disciplína řízení rizik Lékařů bez hranic[4] ) |
| HLAVNÍ PLÁN PROJEKTU | Všechno plány jsou synchronizovány a prezentovány společně jako plán hlavního projektu. “ (MSF Process model[3] |
| PRACOVNÍ PLÁNY | Plán nebo plány pro plnění, která se vztahují k roli a účastní se týmových plánovacích setkání. “ (MSF Process model[3] |
| ODHADY NÁKLADŮ | Odhad nákladů na projekt. |
| PLÁNY | Časové odhady a časové plány pro dodávky. “ (MSF Process model[3] |
| ROZVRH HLAVNÍHO PROJEKTU | The různé plány jsou poté synchronizovány a integrovány do časového plánu projektu amaster. “ (MSF Process model[3] |
| FUNKČNÍ SPECIFIKACE | The funkční specifikace podrobně popisuje, jak jednotlivé prvky mají vypadat a chovat se. Popisuje také architekturu a návrh všech funkcí. “ (MSF Process model[3] |
Tabulka 4: Koncepty ve fázi plánování
Fáze vývoje
Obrázek 4: Vývoj fázového procesního / datového modelu
| Aktivita | Definice (zdroj) |
|---|---|
| Vyvíjejte funkce | Vytváření komponent řešení (dokumentace i kód). “ (MSF Process model)[3]Zahrnuje také testování po každodenním sestavení, opravu chyb a vyhodnocení funkcí. |
| Vytvořit denní sestavení | Vytvoření sestavení po pracovním dni. |
| Dokončit rozsah | V tomto milníku jsou všechny funkce kompletní a řešení je připraveno pro externí testování a stabilizaci. “ (Procesní model Lékařů bez hranic)[3] |
| Rozvíjet infrastrukturu | Infrastruktura je vyvinuta. “ (MSF Process model)[3] |
Tabulka 5: Rozvojové aktivityNejdůležitější činností ve vývojové fázi je vývoj funkcí. Kromě implementace těchto funkcí je v této fázi dokončen také rozsah. Během vývoje mohou být do produktu přidány nové funkce, ale jakmile bude rozsah dokončen, budou funkce zmrazeny a připraveny k testování a stabilizaci. V této fázi je také vyvinuta infrastruktura, což znamená, že jsou identifikovány síťové struktury a definovány servery, jako je například databázový server.
| Pojem | Definice (zdroj) |
|---|---|
| INSTALAČNÍ SKRIPTY A NASTAVENÍ KONFIGURACE PRO ZAVEDENÍ | Soubor skriptů a nastavení potřebných pro instalaci / spuštění produktu. |
| INSTALAČNÍ SKRIPTY | Skripty potřebné k instalaci produktu. |
| NASTAVENÍ KONFIGURACE | Vlastnosti konfigurace produktu. |
| PRVKY PODPORA VÝKONU | Prvky, které podporují výkon produktu (další databáze, servery atd.). |
| SPECIFIKACE TESTU A PŘÍPADY TESTU | Specifikace testů a testovacích případů použitých k ověření produktu. |
| FUNKČNÍ SPECIFIKACE | Funkční specifikace podrobně popisuje, jak má každá funkce vypadat a chovat se. Popisuje také architekturu a design všech funkcí. “ (MSF Process model)[3] |
| ZDROJOVÝ KÓD A VÝKONNOSTI | Kombinace zdrojového kódu a spustitelných souborů. |
| ZDROJOVÝ KÓD | Zdrojový kód produktu. |
| VYKONATELNÝ | Spustitelný soubor vytvořený zdrojovým kódem. |
Tabulka 5: Koncepty ve fázi vývoje
stabilizační fáze
Obrázek 5: Procesní / datový model stabilizační fáze
| Aktivita | Definice (zdroj) |
|---|---|
| Testování | Testování během této fáze klade důraz na používání a provoz v realistických podmínkách prostředí. “ (Procesní model Lékařů bez hranic)[3] |
| Vyřešte chyby | Tým se zaměřuje na řešení a třídění (stanovení priorit) chyb a přípravu řešení na vydání. “ (MSF Process model)[3] |
| Nasadit pilota | Jakmile bude sestavení považováno za dostatečně stabilní, aby bylo kandidátem na vydání, je řešení nasazeno do pilotní skupiny. “ (MSF Process model)[3] |
| Posouzení | Po přezkoumání a schválení je řešení připraveno k plnému nasazení do živého produkčního prostředí. “ (MSF Process model)[3] |
Tabulka 6: Stabilizační činnostiMezi hlavní činnosti patří testování a řešení chyb. Jakmile je verze sestavení považována za dostatečně stabilní pro pilota, je vytvořena a nasazena pilotní verze. Z tohoto pilota se buď vrátí zpět do testovací / stabilizační smyčky, nebo bude schválen a přezkoumán.
| Pojem | Definice (zdroj) |
|---|---|
| VÝSLEDKY TESTU A ZKUŠEBNÍ NÁSTROJE | Shromažďování výsledků testů a nástrojů používaných k testování. |
| VÝSLEDKY TESTŮ | Výsledky provedených testů. |
| ZKUŠEBNÍ NÁSTROJE | Nástroje používané k testování. |
| ZLATÉ UVOLNĚNÍ | Verze použitá pro závěrečnou kontrolu. |
| POZNÁMKY K VYDÁNÍ | Poznámky k verzi. |
| ZDROJOVÝ KÓD A VYKONÁVATELNÝ | Kombinace zdrojového kódu a spustitelných souborů. |
| ZDROJOVÝ KÓD | Zdrojový kód produktu. |
| VYKONATELNÝ | Spustitelný soubor vytvořený zdrojovým kódem. |
| RECENZE MILESTONE | Přezkoumání finální verze a projektových dokumentů. |
| PROJEKTOVÉ DOKUMENTY | Sbírka všech projektových dokumentů. |
Tabulka 7: Koncepty ve fázi stabilizace
fáze nasazení
Obrázek 6: Procesní / datový model fáze nasazení
| Aktivita | Definice (zdroj) |
|---|---|
| Nasadit hlavní komponenty | Nasazení všech komponent potřebných produktem (jako jsou databázové servery, poštovní servery atd.) |
| Nasazení řešení na místě | U systémů šitých na míru zde dochází k nasazení produktu (u softwarových produktů lze přeskočit). |
| Stabilizujte nasazení | Řešení, monitorování a zlepšování nasazených komponent. |
| Přeneste projekt do provozu a podpory | Přenos všech dokumentů a kódu do provozního a podpůrného týmu. |
| Získejte konečné schválení od zákazníka | Zákazník musí souhlasit s tím, že tým splnil své cíle, než může prohlásit, že řešení je ve výrobě, a uzavřít projekt. To vyžaduje stabilní řešení a jasně stanovená kritéria úspěchu. Aby bylo řešení považováno za stabilní, musí být zavedeny vhodné provozní a podpůrné systémy. “ (Procesní model Lékařů bez hranic)[3] |
| Projděte si projekt | Závěrečná revize projektu. |
Tabulka 8: Zaváděcí aktivityHlavní aktivitou ve fázi nasazení je instalace infrastruktury potřebné ke spuštění produktu (nasazení serverů atd.). Dokumenty jsou také finalizovány a přeneseny do oddělení provozu a podpory, je vytvořena znalostní báze a produkt a projekt jsou zkontrolovány zákazníkem (je-li relevantní) a projektovým týmem.
| Pojem | Definice (zdroj) |
|---|---|
| POSTUPY A PROCESY | Shromažďování postupů a procesů. |
| POSTUPY | Soubor postupů, které mají být použity pro instalaci a provoz výrobku. |
| PROCESY | Soubor procesů, které mají být použity pro instalaci a provoz produktu. |
| ZNALOSTNÍ ZÁKLAD, ZPRÁVY, KNIHOVNY | Sbírka znalostní báze, zprávy a deníky. |
| ZNALOSTNÍ ZÁKLAD | Znalostní databáze spojená s produktem. |
| ZPRÁVY | Zprávy spojené s produktem. |
| DENÍKY | Deníky související s produktem. |
| ÚLOŽIŠTĚ DOKUMENTŮ | Úložiště všech dokumentů. |
| ZÁVĚREČNÁ VERZE VŠECH PROJEKTOVÝCH DOKUMENTŮ | Konečné verze projektových dokumentů. |
| INFORMAČNÍ SYSTÉMY PROVOZU A PODPORY | Systémy používané týmy provozu a podpory spojené s produktem. |
| ÚDAJE O SPOKOJNOSTI ZÁKAZNÍKA / UŽIVATELE | Shromažďování údajů od zákazníka / uživatele o jeho spokojenosti s produktem. |
| DEFINICE DALŠÍCH KROKŮ | Popis dalších kroků, které je třeba podniknout při vývoji produktu. |
| ZPRÁVA O UKONČENÍ PROJEKTU | Závěrečná zpráva o produktu, projektu a přechodu na provoz a podporu. |
Tabulka 9: Koncepty ve fázi zavádění
Celkový datový model
Obrázek 7: Celkový datový modelTento datový model zobrazuje všechny koncepty s multiplicitami a vztahy v úplném kontextu projektu.
Nástroje pro použití s vývojem rychlosti internetu
- Nástroje pro kreslení (příklady: Microsoft Visio, Rational Rose, Dia ) Pro vytváření diagramů.
- Textové procesory (příklady: Microsoft Word, OpenOffice.org Writer, AbiWord, Calligra Words ) Pro vytváření textových dokumentů, jako je prohlášení o vizi nebo dokument rozsahu.
- Tabulky (příklady: Microsoft Excel, OpenOffice.org Calc, Číselný, Calligra Sheets ) Pro vytváření prioritních seznamů rizik a kalkulaci nákladů.
- Nástroje projektu (příklady: Microsoft Project, OpenProj, Gnome Planner, Calligra plán ) Pro plánování projektových aktivit.
- Databáze a nástroje pro správu databází (příklady: MS SQL Server, MySQL, Oracle, PostgreSQL ) Pro vytváření znalostních bází.
- Automatizované testovací nástroje (příklady: Testovací skripty) Pro provádění testů po každém denním sestavení.
Viz také
- Agilní vývoj softwaru
- Inkrementální a iterativní vývoj
- Rámec řešení Microsoft
- Metoda vývoje dynamických systémů (DSDM)
- Metoda MoSCoW
Poznámky
- ^ Pekka Abrahamsson, Juhani Warsta, Mikko T. Siponen, Jussi Ronkainen 2003
- ^ Jak ukazuje článek Zusera, Heila a Grecheninga.
- ^ A b C d E F G h i j k l m n Ó str q r s t u proti w X y z aa ab ac inzerát Bílá kniha Microsoft Solutions June 2002
- ^ A b C d Bílá kniha o disciplíně Microsoft Risk Management Discipline
Reference
- Microsoft červen 2002 Microsoft Solutions Framework (bílá kniha) Microsoft Press
- Microsoft June 2002 MSF Risk Management Discipline v.1.1 (White Paper) Microsoft Press
- Wolfgang Zuser, Stefan Heil, Thomas Grechenig 2005 Vývoj a záruka kvality softwaru v RUP, MSF a XP - Srovnávací studie Proceedings of the 2005 workshop on Quality Quality
- Pekka Abrahamsson, Juhani Warsta, Mikko T. Siponen, Jussi Ronkainen 2003 Nové směry agilních metod: srovnávací analýza ICSE
- Michael A. Cusumano, David B. Yoffie 1999 Vývoj softwaru v internetovém čase 32 IEEE
- Balasubramaniam Ramesh, Jan Pries-Heje 2002 Internetové softwarové inženýrství: Jiná třída procesů Annals of Software Engineering 14 169–195