Ako napísať návrh na vývoj softvéru

Ako napísať úspešný návrh na vývoj softvéru.

Kevin Languedoc

Účelom návrhu na vývoj softvéru je poskytnúť riešenie, ktoré bude čitateľné podnikateľom, takže je jednoduché a vecné; držte sa čo najviac od technických podmienok. Nasledujúci prehľad je možné použiť ako taký na prípravu úspešného návrhu vývoja softvéru. Je dôležité mať na pamäti, že ľudia, ktorým sa chystáte predložiť návrh, nemajú veľa času na prečítanie zdĺhavého dokumentu. Môžete si to odo mňa vziať, za 20 a viac rokov, čo som pracoval v informačných technológiách, som napísal stovky návrhov: podnikatelia chcú len toľko informácií, aby im umožnili urobiť informované rozhodnutie.

Ak odpovedáte na žiadosť o ponuku (RFP) a musíte rešpektovať určitý rozsah stránok, pretože stránky sú predtlačené alebo vás obsahové požiadavky nútia mať príliš dlhý návrh, zvážte použitie zhrnutia. nižšie som pridal časť s popisom, ako ju pripraviť.

Dĺžka návrhu

Videl som šablóny a diskusie, ktoré obhajujú návrhy, ktoré platia pre 50 stránok. Verte mi, že po piatej strane stratíte záujem obchodného manažéra. Len čo bude návrh prijatý, budú projektové dokumenty prirodzene podrobnejšie, pretože budú určené projektovému tímu a budú funkčnými plánmi systému. To platí pre väčšinu klientov, ale (áno, vždy existuje), ak je návrh odpoveďou na žiadosť o ponuku (RFP), musíte ju dodržiavať. Vláda alebo vojenská agentúra pravdepodobne bude mať prísne pokyny na prípravu návrhu vývoja softvéru a môže obsahovať niekoľko stránok (10, 20, 30, 50 alebo viac) v závislosti od zložitosti systému.Toto pravidlo stále platí pre veľké organizácie, ktoré môžu mať proces formálneho návrhu, najmä ak sú verejnou spoločnosťou a musia dodržiavať všetky predpisy alebo normy Sarbannes-Oxley alebo ISO.

Zhrnutie

Ak má návrh viac ako 20 strán, môžete zvážiť poskytnutie Zhrnutia, ktoré je jednou stránkou častí návrhu. Môžete dokonca poskytnúť zhrnutie vo formáte PowerPoint. Ak plánujete použiť zhrnutie v prezentácii návrhu vývoja softvéru, predložte návrh pomocou zhrnutia a výkonný riaditeľ si môže návrh prečítať neskôr, napríklad počas služobného letu.

Šablóna

Nasledujúca osnova je skutočne dobrá šablóna, ktorú môžete použiť na prípravu vlastného návrhu vývoja softvéru. Pri príprave návrhu mám vždy na pamäti pravidlo Elevator Pitch a vy by ste mali tiež. Výška výťahu v zásade stanovuje, že váš návrh by nemal byť oveľa dlhší ako čas potrebný na vyvezenie výťahu z prízemia do najvyššieho poschodia budovy, keď budete musieť predložiť návrh.

názov projektu

S podnadpisom alebo súhrnnými informáciami o návrhu

Návrh by mal mať názov a podkapitolu zhrňujúcu súvislosti návrhu softvéru. Ďalej uvádzate názov divízie, služby, oddelenia alebo organizácie, pre ktoré je projekt určený.

Ak odpovedáte na žiadosť o ponuku (RFP), uveďte všetky informácie, ktoré sú požadované alebo sú v zozname žiadostí uvedené ako povinné. Videl som tiež RFP, ktoré požadujú, aby ste okrem názvu na prvú stránku vložili podpisy schválenia, ale v tomto príklade som podpisy vložil na stránku so sekciou Zmeny.

Obsah

Na nasledujúcej stránke by ste mali zahrnúť obsah so zoznamom hlavných častí návrhu. Ak návrh presahuje päť strán alebo ak to požaduje RFP, môžete voliteľne uviesť čísla strán.

Schválenia

Táto časť je pre proces rozhodujúca, či už sa jedná o odpoveď na žiadosť o cenovú ponuku alebo z tejto šablóny alebo z iného zdroja. Táto časť dokumentuje potvrdenia, že projekt je zahájený, a poskytuje záväznú dohodu medzi rôznymi členmi projektu. Nikdy by ste nemali zahájiť projekt, kým nezískate všetky potrebné podpisy a nebudete mať záväzok od projektového šampióna a zainteresovaných strán zahájiť projekt. V opačnom prípade sa môžete ocitnúť vo väzbe, ak je projekt zrušený alebo ak sa zmení rozsah projektu alebo výsledky.

So zavedenými schváleniami je oveľa ťažšie uskutočniť zmeny v rozsahu a výsledkoch, a ak dôjde k sporom, podpísané schválenia poskytnú jasné (alebo) pochopenie toho, na čom sa dohodli. Samozrejme, vždy existuje otázka výkladu.

Schválenia by mali obsahovať meno osoby, jej titul, nasledovaný jej podpisom a nakoniec dátum podpisu dokumentu.



názov	Názov / rola	Podpis	Dátum

Zmeny

V časti Zmeny sa nachádza denník všetkých zmien, ktoré boli alebo budú vykonané v dokumente Návrh vývoja softvéru. Nezdokumentuje žiadne zmeny rozsahu samotného projektu ani žiadneho iného aspektu projektu. Sekcia Zmeny by mala obsahovať minimálne meno osoby, ktorá zmenu vykonala, dátum zmeny a komentár alebo popis zmeny.



Autor	Dátum zmeny	Popis alebo komentár

Slovník a skratky

Uveďte zoznam všetkých výrazov alebo skratiek a ich definícií. Nepredpokladajte, že každý pozná význam výrazov alebo skratkových slov, najmä ak plánujete využiť externých konzultantov a tieto výrazy sú interné a sú zakomponované do vašej firemnej kultúry a jazyka. Každá organizácia má svoje vlastné jazykové výrazy a skratky. Je v poriadku ich používať v návrhu, pokiaľ sú riadne zdokumentované.

Ak sa používajú aj akronymy špecifické pre dané odvetvie, musia byť tiež zdokumentované, aby každý jasne pochopil význam výrazov a skratiek a vytvoril lepšiu interpretáciu.

Nasledujúce skratky pochádzajú z aktuálnej šablóny. Sú uvedené ako príklad.

Žiadosť o ponuku
ROI: Návratnosť investícií
CAGR: Zložená ročná miera rastu
IT: Informačné technológie
CAPEX: Kapitálové výdavky
MJ: Merná jednotka

Rozsah

Rozsah návrhu by mal na vysokej úrovni načrtnúť celkové podrobnosti projektu, čo je zahrnuté a vylúčené. Rozsah by mal obsahovať celkový popis, dĺžku projektu, hlavné ciele. Čo sa snažíte dosiahnuť touto investíciou do navrhovaného projektu vývoja softvéru.

Časová os

Táto časť bude obsahovať začiatočný a konečný dátum (odhadovaný). Nezabudnite zabudovať vyrovnávaciu pamäť a naplánujte si nepredvídané udalosti. Dobrým pravidlom je pridať na svoju časovú os 75% vyrovnávaciu pamäť.

Členovia projektu

Členmi projektu by mali byť šampión projektu a zainteresované strany. Šampión je zvyčajne výkonný pracovník, ktorý riadi celkový projekt a rozpočet. Zainteresovanou stranou je zvyčajne interný promotér alebo sponzor. Môžu byť tiež šampiónmi v závislosti od rozsahu projektu alebo typu organizácie, ktorá požaduje návrh vývoja softvéru. Zvyšný zoznam obsahuje typické úlohy, ktoré ľudia v projekte vykonávajú.

Nasledujúce informácie sú poskytované len ako príklad typu rolí, ktoré môžu mať účastníci projektu. Niektorí ľudia môžu mať viac ako jednu rolu. V závislosti od rozsahu projektu môže byť zoznam členov projektu veľmi zdĺhavý alebo rovnaká osoba môže zastávať rôzne úlohy.

Zoznam by mal obsahovať všetky informácie, ktoré správne identifikujú osobu, jej úlohu v projekte, spôsob, ako ju dosiahnuť a aké sú jej zodpovednosti. Môžete zahrnúť ďalšie informácie v závislosti od RFP alebo typu organizácie, s ktorou budete pracovať, a od jej interných politík.



Člen tímu	Rola	Kontaktné informácie	Zodpovednosti
	Majster
	Zainteresovaná strana
	Projektový manažér
	Architekt
	Analytik
	Vývojár

Obchodná príležitosť

Väčšina šablón, ktoré sú k dispozícii, definuje túto sekciu ako „Obchodný problém“ alebo „Vyhlásenie o probléme“, často som sa však stretol s vedúcimi pracovníkmi, ktorí sa urážajú nad tým, že majú problém vo svojej obchodnej jednotke alebo procese. Pamätám si, ako ma jedna riaditeľka doslova vyhodila z kancelárie, pretože som uviedol, že opravujeme proces, a povedala mi, že to nebude niekto z IT (informačných technológií), kto bude diktovať, ak má problém s jej procesmi alebo nie.

So znením teda buďte opatrní. Vždy používam výraz „obchodná príležitosť“, pretože nakoniec návrh reaguje na obchodnú príležitosť na zlepšenie procesu, podporu procesu alebo automatizáciu procesu



Obchodné vyhlásenie	Ako systém vyhovie požiadavke
Ovplyvnený obchodný proces, situácia, problém	Ako navrhované riešenie zlepší cieľovú oblasť podnikania
Aká potreba sa rieši	Ako to bude riešiť súčasný projekt

Prehľad riešení

V časti Prehľad riešení môžete poskytnúť prehľad systému na vysokej úrovni. Tento prehľad môže obsahovať navigačnú mapu, ak sa návrh týka webovej stránky alebo webovej aplikácie. Môžete tiež zahrnúť vývojový diagram toku procesu. Môžete tiež zahrnúť diagram hlavných komponentov systému.

Cieľom je poskytnúť osobe, ktorá rozhoduje, dostatok informácií, aby pochopil, čo tento systém je, ako bude fungovať a aké sú hlavné stavebné prvky. Toto je samozrejme iba usmernenie, pretože organizácia môže mať formálny formát, ktorý definuje, čo budete musieť v návrhu poskytnúť, najmä ak jednáte s vládnou agentúrou alebo ministerstvom obrany.

Funkcie a výsledky

Táto časť poskytuje mechanizmus na mapovanie prvkov navrhovaného systému na hmatateľné výsledky. Videl som aj túto časť, ktorá obsahuje časový odhad na dokončenie dodávky, ale nerád ju používam, pretože je príliš obmedzujúca a vytvára väzbu. Pri práci na projekte sa dodávky nemusia zhodovať presne tak, ako je to zapísané., takže ak ste sa zaviazali na papieri dokončiť dodanie do určitého času, odstráni alebo zníži sa akákoľvek elasticita neskôr, keď skutočne robíte projekt.

Ďalším stĺpcom, ktorý je možné pridať, je vydanie, do ktorého patrí dodávka. Je to užitočné, ak bude projekt dodaný po dlhšiu dobu a bude vydaných niekoľko vydaní. To platí aj pre agilný alebo štíhly projekt, kde každá funkcia alebo užívateľský príbeh patrí k vydaniu.

Koncept je jednoduchý; pre každú vlastnosť v systéme uveďte jej názov, krátky popis a to, ktorý výstup uspokojí požiadavku na vlastnosť.



Funkcia	Popis	Doručiteľný

Rozpočet a NI

Rozpočet a ROI je pre niektorých vedúcich pracovníkov pravdepodobne najdôležitejšou časťou. Všetci túžia vedieť, koľko ich bude stáť systém alebo aký veľký dopad bude mať tento projekt na rozpočet ich rezortu. Platí to najmä vtedy, ak projekt nebol zahrnutý do Capexu na začiatku fiškálneho roka.

Niekedy, aj keď bol projekt v rozpočte, môže mať prednosť pred súčasným návrhom iný projekt a finančné prostriedky môžu byť odklonené od plánovaného zdroja. Na výkonnej a riadiacej úrovni sa často deje trochu politických hádok, aby sa projekt dostal do praxe, a často existujú nepredvídané okolnosti, ktoré môžu mať prednosť pred plánovanými projektmi.

Buďte teda pripravení spolupracovať so svojimi zainteresovanými stranami na rokovaniach alebo buďte flexibilní a proaktívni, aby ste poskytli pracovné riešenie, ak situácia v rozpočte pôjde bokom. Je lepšie prispôsobiť projekt rozpočtovej realite, a to dokonca aj rozložením výsledkov systému na dlhšie časové obdobie alebo dokonca od projektu odísť. Je oveľa lepšie odísť pešo, ako pracovať na projekte, nedostávať výplaty a uchýliť sa k súdnym sporom.

Nasledujúca tabuľka slúži iba na demonštračné účely a slúži len na predstavu o spôsobe prípravy rozpočtu. Prirodzene, budete musieť pridať svoje vlastné riadkové položky, aby sa zmestili do vášho projektu. Potom vyplníte množstvo, jednotkovú cenu, mernú jednotku a celkovú sumu riadkovej položky. Potom v dolnej časti porovnajte súčty riadkových položiek.

Takto získate dobrý obraz o investíciách potrebných na realizáciu softvérového projektu. Väčšina vedúcich pracovníkov, s ktorými som pracoval, rád vie, aká bude miera návratnosti alebo koľko bude tento projekt stáť v priebehu času, preto sem uvádzam aj jednoduchú hodnotu návratnosti investícií a CAGR, buď s použitím svojich vlastných odhadov a predpokladov (ktoré musia byť vysvetlené) v návrhu alebo pomocou poskytnutých odhadov a predpokladov.



Položka projektu	Množstvo	Jednotková cena	UoM	Celkom
Softvérová licencia
Stroj (y)
Serverová licencia
Licencia na databázu
Konzultant pre rozvoj
Projektový manažment
Školenie (čas + materiály)

Výpočet NI je veľmi jednoduchý. Vzorec je v zásade zisky - náklady vydelené nákladmi. Vzorec je uvedený nižšie:

Jedinou nevýhodou je, že výpočet neberie do úvahy čas, takže návratnosť investícií je dobrá pre krátkodobé projekty, ale pre dlhodobejšie projekty všeobecne uvádzam CAGR (Compound Annual Growth Rate). Výpočet CAGR je medziročná miera návratnosti pre určitý časový okamih.

CAGR

Vzorec CAGR je:

Prvá časť je rozdelenie konečnej hodnoty na začiatočnú. Výsledok sa v priebehu investovaných rokov zvýši na hodnotu 1. Výsledná hodnota sa odčíta o 1.

Výhody

V tejto časti uvádzate zoznam obchodných výhod, ktoré softvérový projekt poskytne. Môžu byť uvedené v odrážke, pokiaľ zodpovedajú celkovým cieľom. Mali by demonštrovať, ako softvér alebo systém zvýši obchodnú hodnotu.

Stručne povedané, ako bude navrhované riešenie pomáhať podnikaniu, aby bolo úspešnejšie a dosiahlo svoje ciele? Používajte pozitívne slová a vety.

Obmedzenia

V časti obmedzenia by sa mali uviesť všetky hmotné a nehmotné obmedzenia, ktoré môžete predvídať. To sa môže týkať vybavenia, niektorého sezónneho faktora, ako je odstavenie výrobného závodu, ktoré väčšina závodov robí napríklad ako príklad.

Pokúste sa obmedziť obmedzenia alebo ich vykresliť ako minimálnych. Neuvádzajte zoznam negatívnych aspektov softvéru alebo systému, prípadne ak potrebujete, poskytnite riešenia, ktoré ich nahradia.