98 % zakázek neúspěšných? Ještě že máme softwarové inženýrství!

Než si povíme, kdy a jak softwarové inženýrství vlastně vzniklo, prozradíme si, co vlastně tento pojem znamená. Dovolím si za tím účelem nejprve ocitovat definici, kterou vyprodukoval v roce 1989 Fritz Bauer:

„Softwarové inženýrství je zavedení a používání řádných inženýrských principů tak, abychom dosáhli ekonomické tvorby software, který je spolehlivý a pracuje účinně na dostupných výpočetních prostředcích.“

V této krátké a výstižné definici je skryto všechno podstatné, co softwarové inženýrství obsahuje, čím se zabývá a o co se snaží. Pokusme se ji trochu dekódovat a analyzovat.

Úkolem programátora (přičemž v dnešní době má spíše smysl hovořit o softwarové firmě) zdaleka není jen napsat program. Jeho (či její) práce by se měla řídit řadou důležitých aspektů, jejichž souhrn popisuje právě softwarové inženýrství. Především: softwarové inženýrství nedbá jen na vlastní zavedení určitých inženýrských principů, ale pokouší se nabádat i k jejich dodržování. Mezi těmito dvěma pojmy je samozřejmě poměrně dramatický rozdíl: zavést lze kdeco, dokonce se (poměrně s úspěchem) můžeme tvářit, že se to používá, nicméně pokud to fyzicky není pravda, výsledky budou pravděpodobně vypadat podle toho. Typickou ukázkou je tzv. certifikát řízení jakosti (pocházející ze soustavy standardů ISO 9000), který může společnost po splnění mnoha podmínek a po absolvování auditu získat: tento certifikát je jistě dobrým začátkem a jeho získání může firmě přinést důležitý náskok před konkurencí. Řada lidí si ale představuje, že pouhým získáním tohoto certifikátu (kterému se budeme podrobně věnovat v některém z příštích článků) se automaticky a jaksi samovolně stane jeho firma efektivnější, úspěšnější a konkurenceschopnější. Jde samozřejmě o omyl, protože pokud se firma nebude o kvalitu skutečně starat, nepomůže jí ani celá baterie certifikátů.

Dalším pojmem obsaženým v definici je ekonomická tvorba softwaru. O významu slova „ekonomická“ panují zřejmě poněkud zkreslené představy. Obvyklý (skoro se mi chce napsat „český“) způsob uvažování může vést k názoru, že „ekonomická“ v tomto případě (a koneckonců i ve všech jiných případech) znamená levně vyvinout, draze prodat a neplatit daně. Samozřejmě, podobného cíle se jistě snaží dosáhnout každá společnost, ať již více či méně drsnými metodami, nicméně zdaleka v něm není obsaženo vše podstatné. Konkrétně v případě softwaru musíme zahrnout do pojmu „ekonomický“ mnoho dalších faktorů: je nutné vhodně sestavit vývojový tým (nesmí mít málo/mnoho členů, měl by obsahovat vhodné osobnostní typy), důležitá je volba správného vývojového nástroje/operačního systému, je třeba provést úvahu „vyvinout/koupit“, důležité je nalézt společnou řeč se zadavatelem (úspora se promítne v budoucnu), je třeba uvažovat o budoucí údržbě/rozšiřování programu (dnes někde při vývoji uspoříme pár tisíc a za tři roky nás to bude stát měsíc času), mnohem více než u jiných druhů „zboží“ musíme uvažovat směrem dopředu – není vhodné snažit se ušetřit třeba na důkladné analýze problému… Takových bodů bychom nalezli celou řadu (většině se budeme podrobně věnovat v příštích článcích) a všechny můžeme zahrnout do pojmu „ekonomická tvorba“, protože zanedbání kteréhokoliv z nich povede k ekonomickým (i jiným) ztrátám – buď ihned, nebo v budoucnu.

Definice dále hovoří o tom, že vytvořený software má být spolehlivý a má účinně pracovat na dostupných technologických zařízeních. O tom se asi netřeba dlouze rozepisovat: opět se dostáváme zpět k tomu, že nestačí napsat program, ale výsledná aplikace by měla splňovat požadavky uživatelů a nikoliv potencionálních hackerů. Navíc by měla efektivně využívat dostupné zdroje – ať již hardwarové, softwarové, personální či jiné.

Vágně řečeno – softwarové inženýrství je souhrn pojmů, postupů a činností, jejichž porozumění, používání a provádění by mělo zajistit efektivnější tvorbu software a především komplexnější pohled na celý proces vývoje. Pokud vlastními silami programujete malou, specializovanou aplikaci pro konkrétního uživatele a velmi úzké použití, nemusíte nutně dodržovat vše, co vám softwarové inženýrství doporučuje. Hlavní síla tohoto oboru spočívá spíše v zavádění systému, pořádku a struktury do rozsáhlejších projektů, na kterých spolupracuje více vývojářů. Jak již bylo naznačeno, softwarové inženýrství se nezabývá pouze vlastním procesem vývoje (tedy psaním programového kódu), ale zahrnuje mnoho dalších navazujících oblastí, komunikací se zákazníky počínaje a etikou softwarového inženýra konče.

Tolik tedy k pojmu softwarové inženýrství. Nyní pojďme učinit krátkou exkurzi do minulosti. Nejprve se pokusíme definovat základní etapy vývoje softwaru a vzápětí si prozradíme, jaké hlavní důvody vedly ke vzniku softwarového inženýrství.

Vývoj softwaru lze (hrubě) rozčlenit do několika základních etap, které naznačují, jak zesilovalo volání po určitém souhrnu systematických postupů:

• Etapu do poloviny 60. let minulého století můžeme směle nazvat jakýmisi pionýrskými léty. Programátoři této doby byli za prvé šťastlivci, kteří měli přístup k (tehdy velmi drahému) hardwaru, a za druhé nadšenci, kteří vytvářeli zpravidla jednoúčelové programy ušité „na míru“ danému počítači a dané architektuře. O nějakém komplexním, řízeném přístupu k vývoji nemůže být samozřejmě ani řeči. Vytvořené programy byly zpravidla neudržovatelné a neměnné, koneckonců byly často navždy „vypáleny“ do trvalé paměti. Po softwarovém inženýrství nikdo příliš nevolá.
• Na přelomu 60. a 70. let se začínají objevovat první náznaky jakýchsi snah, později ústících ve vznik softwarového inženýrství. Téma „softwarové inženýrství“ se dokonce objevuje na konferenci NATO v roce 1969. Vznikají pojmy „návrh shora dolů“, „modularita“ atd. Začíná být chápan význam správně složeného týmu.
• V době do konce 70. let už softwarové inženýrství skutečně vzniká. Tvorba programů začíná být častějším jevem, hardware se stává dostupnější a výpočetní technika je používanější. Začínají se vytvářet první interaktivní či víceuživatelské aplikace, jsou vidět první databáze a knihovny. Zároveň ovšem vystupují do popředí první zásadní chyby, problémy s dodávkami, nedokončené projekty – vývoj softwaru není nijak řízen a neexistují žádné zavedené postupy. V letech 1976 – 1977 se však již začínají využívat mnohé dnes známé techniky softwarového inženýrství, např. specifikace, návrh, architektura, testování, zajištění kvality, modely životního cyklu apod.
• V 80. letech, zároveň s rozvojem softwaru jako takového, se masivně rozvíjí i softwarové inženýrství.
• V roce 1997 (!!!) je softwarové inženýrství uznáno jako obor s certifikátem v USA.

Už tedy víme, v kterém období se obor softwarové inženýrství začíná formovat, možná však stále není dostatečně jasné, proč vlastně. Pojďme se podívat, co se dělo před jeho nástupem, v době tzv. softwarové krize. Jejími charakteristickými znaky bylo neúnosné prodlužování a prodražování projektů, nízká kvalita programů, nesnadnost/nemožnost údržby a inovací, špatná produktivita práce programátorů… Již skoro nesmrtelnou se stala historka, podle které ze všech zakázek pro americkou vládu, které měly hodnotu mnoho milionů dolarů, bylo přes 40 % zakázek dodáno, ale nikdy nebylo úspěšně použito, zhruba 25 % bylo zaplaceno, leč nebylo nikdy dodáno, asi 15 % bylo po drastických úpravách zahozeno. Pouze necelá tři procenta projektů byla po úpravách použita a jen asi dvě procenta produktů mohla být použita beze změny.

Kde hledat příčiny tehdejší krize? Jistě by bylo možné najít celou řadu důvodů, z nichž každý by sehrál velmi důležitou roli, nejhroznější však byl asi fakt, že se všechny pěkně vesměs kombinovaly a podporovaly, takže výsledkem byla katastrofální neefektivita vytváření (větších) programových systémů. Tyto důvody si vyjmenujeme a pokusíme se srovnat je s aktuálním, dnešním stavem:

• Špatná komunikace, a to na všech úrovních: zákazník/analytik (koneckonců žádná funkce „analytik“ ani neexistovala), analytik/vývojář, vývojář/jiný vývojář, vývojář/šéf. Dnes je funkce analytika ceněna více než funkce vývojáře a nutnost komunikace si (snad) uvědomují všechny zainteresované strany.
• Nesprávný přístup jednotlivých osob k vývoji (hlavním cílem programátora bylo často „vyřádit se“, předvést se, seberealizovat – spokojen měl být on, nikoliv zákazník). Dnes jsou používány například systémy CRM (Customer Relationship Management, systém řízení vztahů se zákazníky), manažeři si uvědomují nutnost uspokojit především zákazníka a tlačí programátory k tomu, aby pracovali pro tým a ne pro sebe.
• Nesprávné odhady, opět ve všech směrech: odhady času, ceny, rozsahu, efektivity. Kladení hlavního důrazu na fázi psaní kódu a z něj plynoucí podcenění verzování, zálohování, testování betaverzí apod. Dnes například víme, že firmy, které skutečně dbají na kvalitu svých výstupů, mají průměrný nárůst 10–30 řádek programového kódu na programátora a den, přesto však často vytvoření optimálního odhadu činí (a zřejmě bude vždy činit) problémy.
• S minulým bodem souvisí i špatné plánování –bylo velmi obtížné vypracovat takový plán projektu, který byl přijatelný pro zákazníka a splnitelný pro vývojáře (ostatně to je velmi obtížné i dnes). Jednak neexistovaly empiricky ověřené příklady, ze kterých by se vyšlo, ale jednak se nikdo ani nepokoušel plán pořádně zpracovat – vycházelo se z představy, že se to nějak stihne. Vývoj obecně probíhal trochu „hurá“ metodou – po zadání bezprostředně následovalo bezhlavé bušení do klávesnic. Pravda, některé zděděné postupy se dají velmi obtížně změnit, proto není tento přístup nijak ojedinělý ani dnes:)
• Velmi nízká produktivita práce programátorů. Programátoři se zabývali vším možným, jen ne tím, co by bylo třeba. Zaměřovali své úsilí nesprávným směrem, snažili se co nejrychleji sepsat co nejvíce řádků programového kódu – a mnohdy se jim to skutečně dařilo (před programátory této doby musíme v každém případě smeknout!). Chybějící či špatné řízení však ve výsledku zapříčinilo, že vývoj trval dlouho a byl drahý; bez ohledu na to, jak rychle dokázali vývojáři dodat fragmenty zdrojového kódu. Dnes je v týmu zastoupena celá řada rolí, přičemž každý by měl provádět to, v čem je nejsilnější a pro tým nejprospěšnější.
• Neznalost základních pravidel (případně nedůvěra v pravidla), jež dnes již bereme víceméně za etalony pravdy, např. přidáním dalších lidí do zpožděného projektu způsobíme jeho další zpoždění, apod.
• Podcenění hrozeb, které se při vývoji vyskytovaly: mnohé problémy mohly být vyřešeny s minimálními náklady hned v jejich zárodku, nicméně málokdo jejich náznakům přikládal důležitost („to nebude problém“, „to vyřešíme nakonec“, „Franta to nepozná“, apod.). Dnes se v určitých fázích vývoje naopak všemi silami snažíme odhalit chyby, o kterých nevíme a které třeba ani nepředpokládáme.
• Nezvládnuté či nepoužívané technologie, případně představa, že zavedením nové technologie se jaksi samy od sebe vyřeší všechny stávající potíže. Tato představa však mnohdy přetrvává do dneška.

Tolik tedy stručný pohled do temného dávnověku vývoje softwaru. Věřím, že jste historickou procházku do dob před vznikem softwarového inženýrství absolvovali s nadhledem. Je dobré si uvědomit, že ačkoliv situace na poli řízení vývoje není ani dnes zcela růžová, bývaly doby, kdy vše vypadalo mnohem hůře. Ale – jak prohlásil jeden optimistický softwarový inženýr – důvody pro naději jsou reálné:)