Proces vývoje softwaru. Vývoj softwaru

Apple by nikdy nevydal iPhone, nebýt vývoje sovětských a ruských vědců. Mluvil o tom publicista zdroje Rusvesna Aleksey Gumilyov, podle kterého byl „jablečný“ smartphone „prostě nacpaný existujícími dobrotami, jejichž původ leží v Rusku“.

Možná jste ještě neslyšeli, že to byli Američané, kdo porazil nacisty, jako první létali do vesmíru a že to byli oni, kdo přišel se vším nejlepším. Mobilní telefony a internet jsou tím, co se moderní mladá generace snaží pozvednout autoritu Ameriky.

A nikdo si nemyslel, že rodiště těchto vynálezů v Rusku? Nechť ne v podobě, v jaké je známe dnes, ale je to tak. I první americký mobil měl velikost domácího mixéru a dálkový ovladač vážil 12 kg. To ale není americký nález, ale sovětský. V roce 1957 vynalezl mobilní telefon Kupriyanovich.

"Obrovské množství všech vynálezů pochází ze sovětského nebo postsovětského Ruska."

Housenka, tramvaj, letadlo, vrtulník, padák, balistická střela, kosmická loď, první satelit Země, vesmírná stanice, měsíční rover, elektronový mikroskop, transplantace orgánů, umělé orgány, první jaderná elektrárna na světě, vodíková energie a mnoho dalšího - to všechno vymysleli Rusové. Vše od žárovky vymysleli Rusové. Nemluvě o elementárním svařování kovů, bez kterého by americké tanky a další vojenské harampádí působily naprosto mizerně a zcela napěchované nýty.

Rádio, televize, animace, videorekordér, foto a video záznam, bezdrátový řídicí systém a dokonce i počítač – to vše je srdcem dnešních amerických gadgetů. Všechny vynálezy byly modernizovány celým světem a ztratily původní vzhled a funkčnost, kterou vidíme dnes.

To nejsou zdaleka všechny inovace, které si Američané přivlastnili a shrnuli: "Rusové degradovali a my jsme vynalezli iPhone." Ano, tento iPhone nebyl vynalezen v USA, byl prostě nacpaný existujícími housky, jejichž původ leží v Rusku. Všechny tyto buchty neměly světový patent, protože se jednalo o tajný vojenský vývoj Unie.

Pak se tyto housky rozptýlily po světě a v Asii, Americe a Evropě byly modernizovány a redukovány a nedostatek patentu umožnil přivlastnit si jejich vynález. Co je sakra Steve Jobs, když je klidný? Řekněte také, že osobně vyráběl elektronické obvody a seděl s kouřící páječkou v ruce. Drtivá většina elektronické náplně všech gadgetů bez výjimky (i iPhone také) se vyrábí a montuje pod jedno tělo v Číně.

Jak vidíte, Amerika si přivlastnila vše, co Rusko vytvořilo.

Typický projekt zahrnuje následující fáze vývoje softwaru:

• analýza požadavků projektu;
• design;
• implementace;
• testování výrobků;
• implementace a podpora.

Analýza požadavků projektu

V této fázi jsou formulovány cíle a záměry projektu, identifikovány základní entity a vztahy mezi nimi. To znamená, že je vytvořen základ pro další návrh systému.

V rámci této fáze se nejen evidují požadavky zákazníka, ale také se uskutečňuje jejich formování - pro zákazníky je vybráno optimální řešení jejich problémů, stanoven požadovaný stupeň automatizace a nejdůležitější obchodní procesy. pro automatizaci jsou identifikovány.

Při analýze požadavků se stanoví podmínky a náklady na vývoj softwaru, vytvoří se a podepíše TOR pro vývoj softwaru.

Design

Na základě předchozí fáze se provede návrh systému. Tato návrhová metodologie kombinuje dekompozici objektů, techniky pro reprezentaci fyzických, logických, ale i dynamických a statických modelů systému.

Během návrhu se vyvíjejí návrhová rozhodnutí pro výběr platformy, kde bude systém jazyka nebo implementačních jazyků fungovat, jsou přiřazeny požadavky na uživatelské rozhraní a je určen nejvhodnější DBMS. Vyvíjí se funkční specifikace softwaru: je vybrána architektura systému, specifikovány hardwarové požadavky, sada org. opatření, která jsou nezbytná pro implementaci softwaru, a také seznam dokumentů upravujících jeho používání.

Implementace

Tato fáze vývoje softwaru je organizována v souladu s modely evolučního typu životního cyklu softwaru. Při vývoji se využívá experimentování a analýzy, staví se prototypy, jak celého systému, tak jeho částí. Prototypy poskytují příležitost ponořit se hlouběji do problému a učinit všechna nezbytná rozhodnutí o návrhu v rané fázi návrhu. Taková rozhodnutí mohou ovlivnit různé části systému: vnitřní organizaci, uživatelské rozhraní, řízení přístupu atd. V důsledku implementační fáze se objeví pracovní verze produktu.

Testování produktu

Testování úzce souvisí s takovými fázemi vývoje softwaru, jako je návrh a implementace. V systému jsou zabudovány speciální mechanismy, které umožňují otestovat systém na shodu s požadavky na něj, zkontrolovat návrh a dostupnost potřebného balíku dokumentace.

Výsledkem testování je odstranění všech nedostatků systému a závěr o jeho kvalitě.

Implementace a podpora

Implementace systému obvykle zahrnuje následující kroky:

• instalace systému,
• školení uživatelů,
• vykořisťování.

Ke každému vývoji je připojen kompletní balík dokumentace, který zahrnuje popis systému, uživatelské příručky a pracovní algoritmy.

Podporu pro fungování softwaru by měla provádět skupina technické podpory vývojáře.

Materiál není vyčerpávající a slouží pouze k seznámení se s hlavními problémy, které v této oblasti existují. Pro více informací o spolupráci kontaktujte naše manažery nebo volejte na níže uvedené číslo.

Čau Habr. Jmenuji se Vladimir Razuvaev, jsem vedoucím oddělení podnikového poradenství. Náš tým se zavázal pomáhat klientům pochopit a spravovat hodnotu softwarových aktiv. V tomto příspěvku navrhuji mluvit o interním rozvoji, který je tak či onak v téměř každé společnosti.

Text je rozdělen do tří částí. V první budu mluvit o pěti důležitých krocích k formalizaci takového vývoje. Tato formalizace pomůže společnosti nejen zajistit práva k tomuto vývoji, ale také sníží právní rizika spojená s „odposlechem“ práv k softwaru bývalými zaměstnanci, jakož i ekonomická rizika nesprávného zaúčtování softwaru jako aktiva. . Z druhé části bude zřejmé, jaká práva mají programátoři přímo k softwarovému produktu vytvořenému pro společnost. A ve třetí části vysvětlím, proč je tak důležité správně provádět dokumenty a jaká rizika může vývojářská společnost čelit.

Zkušenosti z posledních tří let ukazují, jak se změnil přístup firem k internímu rozvoji. I jednoduchý software „na koleni“ je vnímán jako druh entity, která má svou hodnotu. V některých společnostech se pod vlivem politiky substituce importu zvýšila i hodnota vnitřního vývoje: software napsaný vlastním týmem programátorů je pro ně alternativou k zahraničním produktům, které jim často už jsou z hlediska funkčnosti dost blízké. Ať je to jakkoli, organizace se snaží formalizovat interní vývoj – vidíme to na počtu relevantních požadavků na naše oddělení.

Pět kroků k formalizaci vlastního vývoje

Krok první. V rámci pracovní smlouvy formalizujte funkce zaměstnanců a zdůrazněte, že mezi povinnosti zaměstnance patří vývoj úředních prací, počítačových programů, databází atp. Zkontrolujte také pracovní smlouvu, která již byla stranami podepsána - může se jednat o standardní dokument, ve kterém nemusí být uvedeny doložky o vývoji servisních prací. V takovém případě uzavřete s vývojářem dodatečnou dohodu, která by se měla zaměřit na funkční úkoly specialisty a také předepsat vlastnictví vznikajících výhradních práv společnosti zaměstnavateli. Ve smlouvě musí být také uveden postup pro placení autorských odměn za vytvořené počítačové programy. Autorská odměna může být zahrnuta do mzdy, prémií nebo jiných druhů věcných pobídek.

Krok dva. Vždy zadávejte zakázku na vývoj počítačového programu. Přísně vzato, jakýkoli vývoj by měl začínat tím. Zadání je zpracováno ve volné formě. Obsahuje cíle konkrétního projektu, jehož vývoj se plánuje zahájit, a také nějaký stručný popis funkcionality nebo úkolů, které bude aplikace řešit. Naprosto ideální je, když jsou servisní úlohy připraveny pro konkrétní moduly vyvíjeného řešení a obsahují kompletní a jasné zadání pro každý modul. Pokud takový dokument není k dispozici, doporučuje se vypracovat jej pro aktuální projekty, nebo vypracovat nový pro vývoj již dříve vyvinutého produktu, ve kterém by mělo být navíc uvedeno vlastnictví výhradních práv společnosti. Našim zákazníkům usnadňujeme život a nabízíme jim hotové šablony, ale psát můžete i ve volné formě.

Je v pořádku, pokud jste nevytvořili servisní úlohu v předchozích fázích vývoje. Váš produkt je jistě ve vývoji a má smysl začít s nácvikem zadání již při vývoji produktu. V tomto případě formulujte zadání tak, aby bylo zřejmé z kontextu: dokončuje se stávající řešení, na kterém se dříve pracovalo. Pokud byly pracovní úkoly formulovány tak či onak, bylo by užitečné provést jejich audit – buď samostatně, nebo s pomocí zapojeného konzultanta. To vám umožní pochopit, zda je vše v pořádku s dokumenty, pokud ne, dejte je do pořádku. Musíte pochopit, že váš vlastní software, který nemá dokumenty, bude kontrolními orgány vnímán jako pirátský. A to jsou zbytečná rizika, která žádná firma nepotřebuje.

Krok tři. Ujistěte se, že vývojář (pokud existuje) nebo vedoucí týmu (pokud máte vývojové oddělení) pro vás připraví poznámku o provedení úkolu. Obsahuje informace o funkčnosti vyvíjeného modulu, případně o funkčnosti produktu jako celku. V oběhu by také měla být teze, že softwarový produkt je připraven k provozu. Memorandum fakticky dokumentuje skutečnost plnění služebního úkolu a je obdobou aktu převzetí a předání.

Krok čtyři. Speciálně jmenovaná komise na základě memoranda analyzuje možnost přijetí softwarového produktu do zkušebního nebo komerčního provozu, po jehož absolvování je na základě akceptačního certifikátu vytvořen příkaz organizace k převedení tohoto softwaru do komerčního provozu.

Krok pět. Po příkazu organizace, že je produkt uveden do provozu, byste měli připravit příkaz k uvedení softwaru do rozvahy, určení jeho počátečních nákladů, životnosti atd. Jak na to? Je nutné vytvořit odbornou radu, která v rámci projednávání funkčnosti softwaru vydá doporučení a odhady související s cenou softwaru. Doporučení odborníků je lepší formulovat formou protokolu, který je pak třeba předat účetnímu oddělení. Počáteční náklady jsou stanoveny nezávisle developerskou společností a nejčastěji zahrnují přímo přímé náklady. Nepřeceňujte náklady na software, protože. po registraci bude společnost muset platit daně, které budou záviset na počátečních nákladech. Podrobná pravidla pro tvorbu informací o nehmotném majetku organizací v účetnictví a účetní závěrce stanoví RAS 14/2007 (Účetní řád „Účtování o nehmotném majetku“, příloha vyhlášky Ministerstva financí Ruské federace ze dne 27. prosince, 2007 č. 153n).

Takže, aby byl interní vývoj plně formalizován, musí být chráněn následujícími dokumenty:

1. Zadání služby
2. Memorandum o splnění úkolu
3. Akt převzetí softwarového produktu do provozu ve společnosti
4. Objednávka na uvedení softwaru do rozvahy

Dobře provedený formalizační proces promění vnitropodnikový vývoj v softwarové aktivum. Z právního a účetního hlediska je tímto způsobem získán nehmotný majetek, který zvyšuje kapitalizaci společnosti. Navzdory svému nehmotnému stavu má softwarové aktivum mnoho společného s konvenčním majetkem, ale především je to jeho cena. Firma může vydělávat např. převodem nevýhradních práv k softwarovému produktu na jiné společnosti/uživatele nebo jeho používáním v organizaci, optimalizací nákladů na úkoly, které dříve nebyly automatizovány, snížením mzdových nákladů na jejich implementaci. Pokud je tento vývoj drahým produktem, výrazně zvýší kapitalizaci společnosti.

Na Habrého byla opakovaně vznesena otázka důležitosti registrace žádostí u Rospatent. Podle mého názoru je to velmi žádoucí, protože certifikát Rospatent nepopisuje softwarový produkt jako takový, ale souhrn jeho vlastností, které určují jeho hodnotu pro uživatele. Investováním peněz a času do ochrany aplikace můžete do jisté míry ochránit svůj vývoj před opakováním. Důležité: Během registrace Rospatent provádí formální kontrolu přijaté žádosti, ale neprovádí detailní kontrolu softwarového produktu. Správná příprava žádosti o ochranu duševního vlastnictví softwarového produktu je tedy opravdu jiný příběh. Zároveň podotýkám, že v souladu se současnou legislativou Ruska není státní registrace počítačového programu povinná. To znamená, že nelze říci, že pokud si počítačový program nezaregistrujete u Rospatentu, nebudete moci chránit svá práva k němu, protože, opakuji, autorská práva vznikají na základě vytvoření produktu, a nikoli tím, na základě jeho registrace kdekoli byl.

Co může běžný vývojář očekávat?

Vezměte prosím na vědomí, že pokud zaměstnavatel ve fázi vývoje nebo do tří let poté prohlásí, že softwarový produkt je obchodním tajemstvím, je zakázáno sdělovat jakékoli informace o softwaru.

Proč je papírování důležité?

Představte si situaci, kdy přijde kontrola do firmy, která odhalí nesrozumitelný „levý“ software, ke kterému neexistuje žádná dokumentace potvrzující jeho licenci. Výmluva „naši programátoři to vyvinuli“ v tomto případě nefunguje, jsou potřeba podpůrné dokumenty. Bez nich může společnosti hrozit zabavení hardwaru a softwaru, dokud se okolnosti nevyjasní. Je pravděpodobné, že společnost dříve nebo později prokáže, že tento software je jejich vlastním vývojem, ale úsilí a čas strávený nad tím nejsou úměrné rizikům kontinuity podnikání, která společnost může podstoupit. Takový horor místo závěru.

Pokud máte nějaké dotazy - napište do komentářů, pokusím se odpovědět.

V IT pracuji posledních 15 let, i když s programováním jsem začal mnohem dříve. Mým hlavním zaměřením jako systémového architekta bylo organizování vývoje softwaru, vývoj konceptů a architektury na vysoké úrovni a dohled nad implementací konceptu v průběhu projektu. Kromě řízení vývoje softwaru a tvorby architektury se čas od času zabývám řešením složitých technických problémů a psaním některých kritických úseků kódu, kde je nutná znalost jazyka a vývojového prostředí samotného, ​​ale také jejich vnitřní organizace, která někdy přináší nemilá překvapení. .

Projekty, na kterých pracuji, se nejčastěji týkají vývoje zakázkového nebo investičního softwaru. Musel jsem také pracovat s embedded software a programy zaměřenými na vydávání „hitů“ (kterým lehkou rukou Joela Spolského dále říkám herní software, i když ve skutečnosti mají některé herní projekty blíže k investičním projektům).

Vlastní software může být pro interního nebo externího zákazníka. Zákazník získává výhradní práva na vyvinutý systém a práce na vývoji systému mohou být v budoucnu převedeny na jiného dodavatele.

Na rozdíl od zakázkového softwaru si práce na investičním softwaru provádí zhotovitel sám za peníze interního nebo externího investora. Práva k systémovému kódu zůstávají zpravidla vývojáři, což stimuluje neustálou práci na vylepšování jejich produktu a konzistentní vydávání verzí s pokročilejšími funkcemi.

Firmware je dodáván s hardwarem a je, zhruba řečeno, neudržitelný, protože stažení šarže zařízení výrobcem je velmi nákladné, a proto výjimečné.

Vývoj herních hitů také prakticky neobsahuje doprovodnou fázi. Kromě toho uživatelé herních programů, i když se potýkají s chybou ve hře, velmi zřídka stahují aktualizovanou verzi. Proto má vývoj her zpravidla svou vlastní ekonomiku a svůj vlastní vývojový proces.

Našimi zákazníky jsou úřady, velké státní a komerční organizace a samozřejmě my sami. Proto, pokud jde o zakázkový software, často existuje určitý rozdíl v našem procesu mezi vývojem produktů pro interní a externí zákazníky. V tomto článku uvedu některé nuance. Úroveň formalizace vztahů se zákazníkem se velmi liší projekt od projektu. Obecně platí, že čím větší rozpočet projektu, tím vyšší formalita. Odběratel státu nebo velké obchodní podniky (zejména se státní účastí) mají zpravidla legislativní omezení tvorby, zadávání zakázky a přijímání výsledků práce. Dalším omezením velkých organizací je fakt, že jejich personál, který je zdrojem požadavků a hlavním uživatelem našich systémů, má velmi omezenou dostupnost pro účinkující, už jen z důvodu jejich vytíženosti. U malých organizací však míra formalizace klesá a někdy jde až do opačného extrému, kdy je nedostatečná míra odpovědnosti zákazníka v rámci projektu.

Druhou stránkou našich zakázkových projektů jsou vysoké nároky na funkčnost. Jedná se o vysoké zatížení všech systémů a velké geografické rozložení a vysoké požadavky na přesnost výpočtů s velmi omezeným časovým rámcem. V našich projektech jsou často prvky výzkumné práce a kreativního hledání zaměřeného na řešení netriviálních konstrukčních problémů. Někdy musíme v rámci stejného vývojového procesu kombinovat různé metodiky, například vložením jedné nebo více fází téměř čistého scrumu do celkového procesu, blízkého RUP, čímž vznikne něco jako projekt v projektu. To nám umožňuje udržet zapojení uživatelů na nízké úrovni vzhledem k povaze projektu s flexibilitou vývoje tváří v tvář vysoké nejistotě požadavků. V tomto ohledu je pro mě důležitá právě přípravná fáze, během které si můžete zvolit potřebnou metodiku a vybudovat optimální vývojový proces. Jeden z příkladů využití agilní metodiky jsem popsal v článku „Aplikace agile při vývoji projektu pro vládního zákazníka“ .

Jako příklad práce na investičním projektu mohu uvést vývoj integrovaného bezpečnostního systému, který jsme vytvořili jako „krabicový“ produkt. Pod mým vedením byly postupně vydány čtyři verze tohoto systému, jejichž uživateli byly různé komerční a vládní organizace, včetně moskevské radnice, AFK Sistema, bank, obchodních center a samozřejmě naše vlastní kancelář. První verze nebyla příliš úspěšná, ale měli jsme strategii vývoje, která nám umožnila úspěšně zachytit trh a přežít těžké časy krize. Zkušenosti z práce na tomto a několika dalších investičních projektech byly také zohledněny při utváření vývojového procesu, který používám.

Náš proces je sledem určitých fází. Mnou uváděná klasifikace softwaru je provedena pouze proto, aby ukázala možný rozdíl v organizaci vývoje různých softwarových nástrojů. Při přehledu procesu vývoje se zaměřím pouze na rozdíly v samotném procesu s ohledem na různé typy softwaru. Musíme však pamatovat na to, že rozdíly mezi vývojovými procesy různých typů softwaru jsou mnohem hlubší, takže při plánování každé fáze je třeba vzít v úvahu tyto nuance.

Je důležité pochopit, že přechod procesu z jedné fáze do druhé nemá jasné hranice. Práce na další fázi zpravidla začíná, když je dokončeno 80–90 % práce na předchozí fázi. To platí zejména pro vývoj požadavků, kdy v některých případech dochází k odstranění nejistoty až na konci projektu. Přítomnost takové nejistoty v projektu je samozřejmě významným rizikem a měla by být pod neustálou kontrolou.

Proces vývoje softwaru na zakázku

Obrázek 1. Proces vývoje softwaru na zakázku.

Práce na projektu začínají přípravnou fází. Účelem etapy je vytvořit koncept budoucího systému na základě návrhů zákazníka a na základě tohoto konceptu posoudit relevantnost a proveditelnost projektu. Pokud o přilákání dodavatele rozhoduje zákazník na základě soutěže, pak přípravná fáze je vlastně fází přípravy potenciálního dodavatele na výběrové řízení, včetně tvorby potřebné dokumentace.

Není třeba ztrácet čas a zdroje na projektu, jehož koncept je uznán jako nevyžádaný nebo nerealizovatelný. Tento projekt musí být dokončen. V některých případech je nutná určitá iterační práce se zákazníkem, aby se opravila koncepce projektu, dokud se buď nedosáhne přijatelné rovnováhy mezi požadavky zákazníka a náklady dodavatele, nebo se rozhodne o omezení práce.

Projekt, jehož koncept vypadá přijatelně pro implementaci, vstupuje do fáze vývoje požadavků. V této fázi musí dodavatel sestavit seznam všech výslovných i skrytých potřeb zákazníka. Často se ukazuje, že zákazník buď nerozhodl o svých potřebách, nebo jsou jeho potřeby ve vzájemném rozporu, s možnostmi zákazníka nebo s možnostmi zhotovitele. Cílem etapy je identifikovat všechny skryté potřeby, vyřešit konflikty požadavků, vytvořit holistické technické řešení a analyzovat proveditelnost připravovaného řešení.

Někdy vede upřesnění požadavků k revizi koncepce projektu. Pokud se po vyjasnění všech požadavků nepodaří nalézt přijatelné technické řešení, musí být projekt zkrácen nebo odložen o nějakou dobu v očekávání přijatelnějších okolností.

Pokud je nalezeno technické řešení, umělec pokračuje ve vývoji architektury budoucího systému. Účelem etapy je definovat špičkovou logickou a fyzickou architekturu, která plně pokryje všechny požadavky zákazníka. Při vývoji architektury se přezkoumává a dolaďuje koncepce, požadavky a předběžné technické řešení, což umožňuje předcházet nejnebezpečnějším rizikům.

Po dokončení návrhu architektury je nutné znovu zrevidovat hlavní parametry projektu a rozhodnout, zda je zhotovitel schopen projekt dokončit. Ve fázi vývoje architektury je užitečné opustit zbytečné a příliš těžkopádné funkce. Optimalizace architektonického řešení často pomáhá vejít se do přijatelných parametrů projektu. V ostatních případech je nutné radikálnější omezení funkčnosti vyvíjeného systému. Nicméně i zastavení projektu v této fázi, pokud k němu dojde z dobrých důvodů, by mělo být vnímáno jako vítězství: pokračování prací v tomto případě může vést pouze k ještě větším ztrátám.

Pokud byla nalezena rovnováha a byla vytvořena přijatelná architektura systému, může dodavatel přejít k implementaci a dodávce systému. Realizace může probíhat v jedné nebo více fázích. Pro malé projekty může být zcela přijatelné jednostupňové dodání všech funkcí systému. Čím větší je však projekt, tím vyšší jsou závislosti subsystémů v rámci vytvářeného systému. Za těchto podmínek by měla být implementace rozdělena do několika etap tak, aby na konci každé etapy měl vývojový tým připravený produkt k dodání. Zároveň by nejdůležitější, základní funkce měly být vyvinuty v rané fázi a doplňky, které fungují nad těmito základními komponentami, by měly být implementovány později. V tomto případě budou v prvních fázích opraveny pro systém nejnebezpečnější chyby a výrazně se sníží riziko, že aplikační funkčnost systému bude založena na nestabilním základě.
Po dodání kompletně dokončeného systému se zakázkový softwarový projekt obvykle přesune do fáze beta. Účelem této etapy je prověřit kvalitu vyvinutého systému v reálných provozních podmínkách. Zpravidla v této fázi performer spolu se zákazníkem měří kvantitativní metriky, které umožňují určit kvalitu vytvořeného systému. Nejprve se kontrolují funkční vlastnosti kvality, poté nefunkční. Pokud se vyskytnou nesrovnalosti, interpret opraví systémový kód.

Plně odladěný a vyladěný systém je uveden do komerčního provozu. Zhotovitel musí systém zpravidla doprovázet minimálně v záruční době. Zjištěné nesrovnalosti by měly být opraveny. Uživatelé a pracovníci zákaznického servisu by měli dostat rychlou poradenskou podporu.

Konečně přichází okamžik, kdy systém zákazníkovi z jakéhokoli důvodu přestane vyhovovat. Systém je nyní v procesu vyřazování z provozu. U zakázkového softwaru však tato fáze není vždy relevantní, protože zákazník může využít svých výhradních práv k systému a odvolat dodavatele z další údržby a vývoje systému ještě dříve, než se to stane irelevantní.

Každý projekt nakonec skončí. Fáze ukončení projektu si klade za cíl analyzovat výsledky, provést změny ve vývojovém procesu na základě získaných zkušeností a doplnit vývojovou znalostní základnu o nová efektivní řešení a upozornění, stejně jako o nové běžně dostupné komponenty, které lze použít v budoucí projekty.

Zbývá poznamenat ještě dvě fáze vývojového procesu. Stává se, že okolnosti nedovolí pokračovat v realizaci projektu, ale výsledky odvedené práce ukazují, že projekt může mít budoucnost. Uzavírat takový projekt je předčasné. Proto místo úplného zastavení práce může dodavatel dočasně pozastavit projektové aktivity a opravit dosažené výsledky. Jakmile to okolnosti dovolí, může být projekt obnoven přestavbou infrastruktury, návratem vývojářů do projektu a obnovením stavu projektu. Je však důležité obnovit práci od bodu, kdy byl projekt přerušen, opětovným auditem dosažených výsledků.

Proces vývoje investičního softwaru

Obrázek 2. Proces vývoje investičního softwaru.

Jak je snadné vidět, při vývoji investičního softwaru probíhají stejné fáze, které byly diskutovány výše pro proces vývoje softwaru na zakázku. Rozdíl je ale v tom, že fáze se nevztahují na celý produkt, ale na samostatnou verzi produktu. Výjimkou je fáze ukončení projektu: projekt nelze dokončit, dokud se pracuje na alespoň jedné verzi produktu.

Věnujte pozornost zahájení práce na další verzi produktu. Tento okamžik nastává, jakmile je dokončena fáze tvorby architektury aktuální vývojové verze. Předtím se v požadavcích a fázích architektury obvykle diskutuje o tom, které funkce by měly být implementovány v aktuální verzi a které by měly být přesunuty do budoucnosti. A teprve až budou požadavky na aktuální verzi formulovány, zkontrolovány a potvrzeny architekturou systému, má smysl přemýšlet o další verzi.

Navíc po vývoji architektury mají analytici a architekti projektu zpravidla určitou svobodu jednání, protože hlavní břemeno leží na programátorech během fází dodávky. Tuto svobodu lze využít k vypracování konceptu a požadavků na další verzi.

V zásadě můžete začátek prací na další verzi odložit na pozdější datum. Je například celkem přijatelné nejprve uvést aktuální verzi do experimentálního nebo i komerčního provozu a až poté začít pracovat na verzi další. Musíte si ale uvědomit, že takové řešení není v případě vysoké konkurence použitelné: prostě vás předběhnou a vytlačí vás z trhu. Rozhodnutí musí být učiněno na základě celé řady okolností, které ovlivňují vaše podnikání.

Když už mluvíme o procesu vývoje investičního softwaru, musíte pochopit, že práce na několika verzích má řadu explicitních a skrytých vzájemných závislostí mezi paralelními větvemi procesu.

Nejprve je třeba provést opravy nekonzistencí zjištěných v dřívější verzi ve verzi, kde byly objeveny, a ve všech pozdějších verzích, včetně těch ve vývoji. To platí nejen pro programový kód, ale také pro všechny ostatní artefakty projektu: technickou a uživatelskou dokumentaci, systém nápovědy, odhady a pracovní plány atd. Kromě toho musí být opravy provedeny okamžitě, protože nebudete moci snížit náklady na opravy, ale pokud nebudou provedeny okamžitě, mohou se jejich náklady v pozdějších fázích zvýšit o desítky nebo dokonce stovkykrát.

Za druhé, pro paralelní práci na několika verzích je zapotřebí speciální projektová infrastruktura, včetně organizace správy verzí kódu a dokumentace, kontroly úloh a nekonzistence, automatických sestav a testovacích nástrojů atd. Práce na jedné verzi produktu by neměla blokovat provádění úloh na jiných verzích jen proto, že infrastruktura projektu neumožňuje spouštění dvou procesů sestavení současně pro různé verze produktu.

Zvláštní pozornost by měla být věnována testovacím stolicím: měly by nasadit všechny verze produktu, které byly vydány dříve (alespoň ty verze, které jsou podporovány), a všechny verze, které jsou aktuálně vyvíjeny.

Za třetí, stejní účastníci mohou být zapojeni do práce na několika verzích současně. Existuje vysoké riziko, že klíčová osoba uvízne v práci na jedné verzi programu a umožní značné časové překročení úkolů souvisejících s jinou verzí.

Za čtvrté, existuje opačná situace, kdy personál pracující na jedné verzi neví nic o tom, jaká rozhodnutí jsou přijímána v rámci práce na druhé verzi. Část problému je odstraněna, pokud jsou opravy veškeré dokumentace a kódu okamžitě distribuovány do všech pozdějších verzí, jak jsem uvedl výše. Tato záležitost by se však neměla omezovat pouze na opravy. Je nutné, aby tým pracující na jedné verzi chápal, proč byla učiněna určitá rozhodnutí při práci na jiné verzi. K tomu je zapotřebí znalostní báze pro vývojáře – speciální informační systém, který by měl popisovat všechny problémy, se kterými se vývojáři při práci na konkrétní verzi produktu setkali, a jak tyto problémy řešit. Znalostní báze by měla zasílat upozornění všem účastníkům projektu, když dorazí nové záznamy. Je nemožné nechat volný průběh interakce dvou týmů pracujících na různých verzích stejného produktu.

Proces vývoje vestavěného softwaru

Řekněme, že vydáváte software pro chladničky. Jakmile je software dodán výrobci, začnou se po světě trousit desítky tisíc zařízení a vy netušíte, kde skončí. A pokud jedna z chladniček selže vinou vašeho softwaru, pak je snazší zaplatit pokutu, než vrátit chladničku do továrny a provést diagnostiku. Samozřejmě je možné vyškolit inženýry pro dealerství, kteří mohou provést diagnostiku na místě a vyměnit firmware vašeho systému, ale stále je to velmi drahé.

Při vývoji vestavěného softwaru tedy vzniká několik důležitých omezení najednou.

Za prvé, dodávka probíhá pouze v rámci jedné etapy: nikdo do zařízení nezabuduje napůl fungující program.

Za druhé, při dodání musíte věnovat zvláštní pozornost kvalitě programu, protože od chvíle, kdy je zaveden do železné krabice, bude velmi obtížné jej změnit. Zvláštní pozornost je třeba věnovat fázi pilotního provozu, kdy je program implementován v omezené dávce zařízení a tato zařízení procházejí komplexními testy v různých provozních režimech. Musíte shromáždit co nejvíce informací o chování vašeho systému, analyzovat tyto informace a vylepšit software.

Za třetí, když se zařízení s vaším softwarem dostane do série, máte velmi malou příležitost opravit chyby. Ve skutečnosti jsou takové opravy možné pouze v případě vadného softwaru, který vede k nefunkčnosti celé šarže zařízení, kvůli čemuž bude výrobce nucen tuto šarži stáhnout a vy tak získáte velkou černou skvrnu na své pověsti. .

Konečně, za čtvrté, neexistuje žádná fáze vyřazování z provozu pro vestavěný software. Program se se zařízením jednoduše vyhodí. Jakmile tedy vyprší záruční doba pro dávku zařízení, ve kterých běží váš software, můžete projekt uzavřít.

Proces vývoje firmwaru je znázorněn na obrázku 3.

Obrázek 3 Proces vývoje vestavěného softwaru.

Proces vývoje hry

Dalším faktorem, díky kterému vyniká herní produkce, je fakt, že hra je pro uživatele zajímavá buď do doby, než projde poslední úrovní, nebo do chvíle, kdy dojde k fatální chybě. To znamená, že si druhou verzi hry nekoupí ani si ji zdarma nestáhne, jen aby opravil pár chyb.

Tyto faktory ovlivňují proces vývoje herního softwaru. Proces je znázorněn na obrázku 4.

Obrázek 4. Proces vývoje herního softwaru.

Je třeba poznamenat následující vlastnosti procesu vývoje herního softwaru.

V první řadě je při výrobě her nesmírně důležitá kvalita konceptu. Pokud vám koncept hry neumožňuje vytvořit hit, pak další práce postrádá smysl. Pro vývoj herního softwaru je typická situace, kdy většina projektů končí v přípravné fázi.

Požadavky a vývoj architektury pro herní software často znovu využívá poučení z předchozích projektů. V tomto ohledu dostává další váhu také fáze ukončení projektu, kdy musí být veškerý užitečný vývoj zaznamenán ve znalostní bázi vývojářů.

Dodávka herního softwaru probíhá v rámci jediné fáze. I když se nejprve vytvoří určité jádro, „motor“ herního systému, nelze jeho fungování ověřit bez implementace celé funkčnosti systému.

Pro herní software neexistují žádné betaverze ani fáze vyřazování z provozu. Hry jdou okamžitě do prodeje a po použití je uživatel jednoduše smaže, protože o ně ztratí zájem.

Závěr

Podotýkám, že zde zvažovaný procesní diagram je výsledkem zobecnění mých osobních zkušeností s vývojem různých softwarových nástrojů. Jako každé zobecnění je moje schéma abstrakcí. A jako každá abstrakce má své hranice použitelnosti. Toto schéma nemůžete bezmyšlenkovitě aplikovat na konkrétní projekt. Je důležité pochopit, že každý projekt má své vlastní nuance, které ovlivňují organizaci vývojového procesu. A proto je nutné pro každý projekt upravit zde uvedené schéma a v některých případech bude nutné vyvinout zásadně odlišný přístup.