Dnes jsme pro vás připravili další ze série článků o softwarovém inženýrství, avšak poněkud netradiční. Přemysl Brada, odborný asistent Katedry informatiky a výpočetní techniky Fakulty aplikovaných věd Západočeské univerzity v Plzni, se zabývá softwarovým inženýrstvím a strávil skoro dva roky na univerzitách v Sheffieldu a v Manchesteru. Kromě jiného jsme se jej zeptali, jak se liší používání softwarového inženýrství u nás a ve Velké Británii.
Ing. Přemysl Brada, MSc, pracuje jako odborný asistent na
Katedře informatiky a výpočetní techniky Fakulty aplikovaných věd Západočeské univerzity v Plzni. Zabývá se především softwarovým inženýrstvím a internetovými technologiemi. V jednom z předmětů, které vyučuje, se snaží předat studentům základní informace o softwarovém inženýrství a o jeho důležitosti.
Strávil jste skoro dva roky na univerzitách v Manchesteru a v Sheffieldu. Na jakých softwarových projektech jste se tam podílel?
Protože šlo primárně o studium, nikoliv práci, týkaly se softwarové projekty především studia. V Manchesteru šlo pouze o krátký, jednosemestrový pobyt a vlastně žádný projekt jako takový tam nebyl. V Sheffieldu jsem absolvoval dva projekty. Jeden se jmenoval Maxiprojekt a úzce souvisel s dvousemestrovým předmětem, jehož cílem bylo osahat si, naučit se praktické postupy vývoje softwaru. Téma Maxiprojektu bylo Distance Learning Infrastructure, architektura pro vzdálené vyučování. Hlavním cílem nebyl vlastně software, ale analýza možností infrastruktury za předpokladu, že je určitý počet studentů rozesetý po světě a situace vyžaduje příslušné síťové prvky, servery a obsah, který mají studenti nastudovat. Druhý projekt probíhal v rámci mojí tamní diplomové práce, a byl dělaný u externího zadavatele. Nazýval se Inflight Entertainment System a šlo o systém pro zábavu pasažérů v letadlech. Mojí prací byl pilotní projekt analýzy a implementace tohoto systému prostřednictvím objektově orientované metodiky pana Booche, čili jednak jsem studoval tuto metodiku a jednak se naučil pracovat s příslušnými CASE nástroji pro analýzu a návrh. Na závěr jsem dělal kostru implementace v C++.
Jak tyto projekty skončily, resp. jsou dnes reálně nasazeny?
Maxiprojekt skončil tak, že zadavatel z katedry si ho prohlédl a udělal si rámcovou představu, co by asi bylo potřeba, ale pokud vím, projekt neměl žádný praktický dopad. Druhý projekt, Inflight Entertainment System, byl poměrně kladně přijat, zadavatelská firma jej vzala jako pilotní a čerpala z něj poučky, jak vlastně dělat objektovou analýzu a návrh.
Jakým projektem se zabýváte v současnosti?
Momentálně pracuji na implementaci některých částí své disertační práce, což je analýza a parsování zdrojových textů v jazyce IDL pro CORBA komponenty. Souvisí to obecně s použitím softwarových komponent.
V Anglii hrají důležitou roli vládní zakázky
Můžete srovnat anglický přístup k softwarovému inženýrství s českým?
Nemám dostatečné praktické srovnání, ale myslím si, že u nás byl nástup softwarového inženýrství o něco pozdější, takže firmy v 90. letech se jej spíše učily a všechno bylo poněkud divočejší. Dnes se situace konsolidovala, navíc softwarové firmy se různě spojují a jsou větší, a začínají používat softwarový proces důkladněji. Hlavně v Praze existují velké softwarové domy, které převzaly používání mnohých metodik. Myslím si tedy, že se přístup v zásadě neliší.
Liší se nějak zásadně proces vývoje softwaru v Anglii a u nás?
Možná je trochu rozdíl v tom, že v Británii funguje částečně podobný systém jako v USA. Spočívá v tom, že vláda je poměrně velkým zadavatelem softwarových projektů. Firmy pracující na vládních zakázkách musí povinně dodržovat určité metodiky a standardy, hlavně procesní. To pak vede k vývoji a rozvoji nových metodik, například metodika SSADM byla právě vyvinuta v průběhu práce na vládní zakázce, stejně jako řada dalších standardů.
Co považujete za svou nejinspirativnější anglickou zkušenost?
A co vám po návratu způsobilo největší zklamání? To je dobrá otázka:-) Největší zklamání mi způsobily fronty u přepážek na poštách. V Anglii jsou pošty organizovány tak, že je N přepážek, které jsou si rovny, kdežto u nás je N přepážek a každá je specializovaná. U některých pak paní za okénkem čeká a nikoho nemá, u jiných je třicet lidí.
A kromě pošt?
V Anglii jsem vlastně poprvé viděl web. Bylo to v devadesátém čtvrtém roce, kdy nastával jeho největší boom. Přestože jsem tam studoval primárně softwarové inženýrství, poznal jsem tam internetové technologie a ty mě nepustily dodnes, internetové aplikace a publikování na webu mě od té doby hodně přitahuje.
V softwarovém inženýrství nebyla jedna konkrétní věc, která by na mě nějak hodně zasvítila, nicméně za důležitou považuji kombinovanou zkušenost Maxiprojektu, týmové práce studentů, kterou se teď snažím aplikovat v softwarovém inženýrství, které učím. Kromě toho jsem viděl, jak lze objektové metodiky aplikovat na reálné softwarové projekty. To mě tak trochu nasměrovalo a v oblasti softwarového inženýrství mě to od té doby asi nejvíce zajímá.
Trendem v softwarovém inženýrství je maximální zkrácení doby analýzy
Sledujete obecné trendy, kterými se řídí SWI?
Vypozoroval jste v poslední době nějaký odklon od klasických definic 70. let?
Trendy samozřejmě musím sledovat a myslím si, že v posledních čtyřech letech se v softwarovém inženýrství objevily dvě významné oblasti. Jedna je výzkum a praxe v oblasti softwarových architektur. Návrh architektury, tedy hrubého členění softwaru na subsystémy a komponenty a způsoby jejich vazeb, je vzat jako samostatná disciplína. Je snaha dát návrhu formálnější pravidla, notace a podobně, aby byl přechod od analýzy k implementaci trochu organizovanější.
A ten druhý trend?
Druhý trend, který je dosti zřetelný, je v metodikách. Někdy ke konci devadesátých let vznikla v objektových metodikách práce od firmy Rational pod názvem Rational Unified Process, což je komplexní metodika pro velké softwarové projekty, která měla snahu pokrýt moderní softwarový proces (inkrementální, iterativní vývoj s objektovými nástroji a s využitím znovupoužitelných komponent). Zpočátku se autoři metodiky snažili udělat ji přizpůsobitelnou různým projektů a potřebám a tento trend určité škálovatelnosti procesu je pořád výraznější. Vznikly varianty Rational Unified Process pro malé projektové týmy (například čtyřčlenné). Viděl jsem i pokus definovat open source development jako instanci Rational Unified Process. Je k tomu připojená také snaha o přístup k vývoji, kterému se říká extrémní programování (extreme programming), což je vývoj postavený ne od analýzy k implementaci, ale jakoby obráceně. Hlavní důraz je kladen na implementaci a na to, aby byl co nejsnáze a nejrychleji vyvinutý „chodivý“ software s tím, že není udělaný kompromis v jeho kvalitě a analýze požadavků. Vývoj se točí okolo hodně krátkých iterací, přičemž vývojáři pracují ve velmi těsně svázaném týmu, kde jeden doslova kouká pod ruku druhému, navzájem si kontrolují svou práci a dávají připomínky. Navíc mají velmi blízko po ruce představitele zákazníka, se kterým mohou on-line konzultovat. Zvláště u internetových aplikací bývají obvykle týmy menší a potřebují velmi krátký čas pro vytvoření funkční implementace. Ve velkých firmách pak existuje třeba několik takovýchto menších týmů.
Zdá se tedy, že ustupuje trend věnovat čím dále více času analýze a návrhu?
Nemyslím si, že ustupuje do pozadí význam analýzy jako takové. Spíše se ukazuje, že je potřeba více provázat analýzu s procesem implementace. Souvisí to s problémem, který v softwarovém inženýrství byl vždy: změny a nestabilita požadavků. Obvykle se na začátku stanoví požadavky a provede se kompletní analýza, a pak zákazník za 14 dní nebo za rok přijde s tím, že to chce trochu jinak. To je permanentní stav. Je tudíž vidět spíše odklon od způsobu „udělat to najednou, kompletně celé dobře a pak implementovat“ k tomu, že se analýza s implementací navzájem prolínají. Dělají se kratší iterace, které zahrnují jak analýzu nějaké úzké třídy funkcí systému, tak jejich bezprostřední implementaci.
Co je důvodem tohoto změněného pohledu na vývoj?
Softwarový svět je k němu nucen tím, že jednak konkurence je za rohem a je schopna totéž udělat ve velmi krátké době a jednak zákazníci chtějí software hned, zvláště dnes, v čase internetu. Myslím si, že to není ideální stav, protože může někdy dojít k roztříštění projektu, a může tím trpět kvalita softwaru. Nastává to v případech, ve kterých se zanedbá jedno ze základních paradigmat extrémního programování – důkladné, průběžné testování. Zároveň s analýzou se vytváří testy a na nich se implementace průběžně ověřuje. Pokud se tato fáze zanedbá, rozhodně se to vymstí – ale stejná situace je u klasických vývojových modelů, třeba u vodopádového. Pokud na testování nezbude čas, otestuje software až zákazník – a je z toho trapas.
Open-source projekty si mohou dovolit „luxus“ software důkladně otestovat
Jaký je Váš názor na nejrůznější systémy řízení kvality a například na certifikát ISO 9000?
Myslím si, že mají svůj význam, ale jak praví jeden z článků na toto téma, pokud se firma o kvalitu snaží, není problémem získat certifikát ISO 9000 tak jako tak. Je-li naopak snahou získat certifikát ISO 9001, nemusí to vyústit v kvalitní softwarový proces. A neplatí to jen pro softwarové firmy, ale pro libovolné průmyslové podniky. Myslím, že snaha o certifikaci je dobře míněná (ať již podle ISO 9001 nebo podle jiných systémů, např. v Británii funguje analogický systém Tick IT, který začal ještě dřív než ISO 9001, nebo Capability Maturity Model a s ním spojené certifikace od Carnegie Melon), ale certifikace sama nic nezaručí. Klíčové je, jestli firma a hlavně její management má potřebu tlačit na kvalitní softwarový vývoj. Pokud tuto potřebu má, najde si k tomu prostředky, protože je jich poměrně dost, pokud nemá a chce jen certifikát, může to mít určitý dopad, nicméně nebude to zabudované do kultury firmy a do procesu vývoje a tudíž to může mít jen přechodné výsledky. Kvalita je prostě o tom chtít ji dělat. Chce-li někdo vyrábět kvalitně, dá tomu potřebný čas, výroba možná bude trvat déle a výsledek bude stát víc peněz, ale bude se vědět o tom, že dílo je kvalitní.
Dbát na kvalitu tedy musí samozřejmě všichni, ale začínat by se asi mělo na pozicích nejvyšších?
Přesně tak. V managementu firmy je hnací motor, tam vzniká posvěcení veškerých aktivit, tam tkví místo, které má pravomoci učinit vše reálným. Bude-li se o kvalitu snažit jednotlivý programátor, samozřejmě v rámci svých možností může, ale nebude to mít globální efekt. V programu bude prostě jeden kvalitní modul a dost.
Jak hodnotíte obecně kvalitu současného softwaru?
Předpovídáte lepší budoucnost komerčním systémům nebo spíše produktům open-source komunity? Kvalita současného softwaru je různá, tak jako tomu bylo vždycky a tak, jak je to se vším. Po mém soudu se nedá úplně říct, že komerční systém je lepší nebo horší. Open-source má tu jednu výhodu, že tím, že není komerční, není tlačen k dodání v co nejkratší době. Open-source projekty si tudíž mohou dovolit ten „luxus“ software otestovat, s tím, že ještě mají k dispozici velké množství testerů, kteří to volně zkouší. To si myslím, že je hlavní důvod, proč open-source software je povětšinou kvalitní. Není třeba to udělat teď hned, protože konkurence nás předběhne. Kromě toho to většinou dělají lidé, které to baví a kteří mají sami zájem udělat software dobře, protože jejich kód bude někdo číst a může si o něm myslet své.
A komerční systémy?
Myslím, že v komerční sféře je naopak ta výhoda, že je dost peněz na mechanismy pro zajištění kvality. Pokud se k tomu větší firma rozhodne (u malých firem je to obtížné), má na to zdroje, může si dovolit financovat kvalitní lidi, může si dovolit vychovávat své zaměstnance, může si dovolit nakoupit kvalitní nástroje, protože bez těch se to dělat nedá. Třeba analýza se bez kvalitních CASE nástrojů dneska dělá hodně špatně a open-source v tomhle nemá takové možnosti, neboť kvalitní CASE nástroje se pohybují opravdu v řádu statisíců korun. Čili k tomu jsou hmotné předpoklady, ale myslím si, že to někdy spíše hoří na obchodní stránce věci, protože obchodník tlačí na to, aby už to bylo prodané. Ale jsou firmy typu IBM nebo HP, které produkují poměrně kvalitní software, za který se nemusí stydět. To, že Sun Microsystems byl ochoten uvolnit kódu Solarisu, také svědčí o tom, že se za ten kód nestydí. Myslím, že by nebylo dobré hodnotit softwarový svět jen podle toho, že Microsoft Office se občas chová podivně nebo že produkuje špatný HTML kód.
Poznámka: tolik první část rozhovoru. Jeho dokončení, které se týká akademického světa, provázanosti univerzit s reálným životem a s komerční sférou, a které opět srovnává situaci v našich podmínkách se stavem v Anglii, si budete moci přečíst za týden.
