Vyvíjíte web půl roku? Konkurence mezitím spustila dva jiné...

Vyvíjíme-li webovou aplikaci, je jedním ze základních požadavků rychlost. Děláte web půl roku? Konkurence mezitím spustila dva jiné. Zdálo by se, že požadavek na rychlost je v přímém rozporu s klasickými metodologiemi softwarového inženýrství, které kladou důraz na podrobnou analýzu, robustní návrh, dlouhodobé testování a další „zdržující“ kroky. Lze tedy použít softwarové inženýrství pro malé projekty, typicky internetové? Existují vhodné metodologie?
Na Živě jsme se již softwarovým inženýrstvím před časem zabývali. Řekli jsme si, že softwarové inženýrství je souhrn metod použitelných při vývoji softwaru, díky nimž je vývoj efektivnější a výsledek lépe odpovídá představám zákazníků. Softwarové inženýrství za dobu své existence dalo vzniknout celé řadě konkrétních metodologií a modelů životních cyklů. Řada z nich se používá dodnes, i přesto, že jsou obecně známé jejich nedostatky. Jiné, které jsou určeny ke konkrétním účelům, jsou používány i v případech, pro něž se nehodí. Zdálo by se, že softwarové inženýrství, které pomohlo v 70. a 80. letech zažehnat softwarovou krizi, přestává nalézat řešení pro určité typy problémů. Tyto problémy se hromadí a postupně nabývají na rozměrech.

Situace na trhu se softwarem se změnila

Určitě se nedočkáme další softwarové krize. Je však nutné si uvědomit, že celá řada klasických softwarově-inženýrských technik (především metodologií) postupně přestává být použitelná. Co je hlavním důvodem?

Situace na trhu se softwarem se změnila. Vývoj softwaru už není v rukách pár desítek nadšenců a profesionálů, kteří tvořívali prakticky jediné osazenstvo úzké komunity vývojářů. V dnešní době se vývojem zabývá „kdekdo“; snižuje se věk proniknutí do programování, díky expanzi vizuálních programovacích nástrojů a technik typu Rapid Application Development dokáže „napsat program“ neuvěřitelná šíře lidí. Pomiňme nyní otázku, kterou si stále častěji kladou příslušníci komunity profesionálních vývojářů, a sice, zda je to dobře. Podíváme-li se na celý problém z hlediska progresivního „uživatele“ dnešního světa, nemůžeme si odpovědět jinak, než že jakékoliv rozšíření možností, jakékoliv přiblížení náročných problémů běžnému lidu, jakákoliv integrace běžných uživatelů s vývojem je pozitivní, už z důvodu prohlubování všeobecné vzdělanosti.

Více lidí, více problémů

Co je však důsledkem uvedených jevů? Vývoj softwaru (v obecném slova smyslu, včetně třeba vývoje webů) je činnost velmi žádaná a lze předpokládat, že poptávka i nadále poroste. Ještě rychleji však roste počet lidí, kteří jsou více či méně schopni tuto poptávku uspokojit. Právě vývoj webových projektů je oblastí, v níž si (s trochou nadsázky) začínají konkurovat žáci základních škol.

Klasické softwarově-inženýrské techniky jsou založeny na rigorózních postupech, které vycházejí z důkladné analýzy problému a z propracovaného, neprůstřelného návrhu. Nelze zpochybnit, že tento model je v obecném případě jednoznačně nejlepší. Vždy lze očekávat, že výsledek vzešlý z podrobného splynutí s problémem bude kvalitnější než plod vypěstovaný na neprozkoumané půdě.

Nejen dobře ale hlavně rychle

Na pořadu dne je však jiná otázka: vyplatí se nám to? Je skvělé, že napíšeme dokonalou, skvěle rozšiřitelnou, robustní internetovou databázovou aplikaci. Jenže než proplujeme klasickými fázemi analýzy, návrhu, implementace a testování, mezi nimiž navíc budou bujet byrokratické operace typu schvalovacích řízení, riskové analýzy, plánování konfiguračního managementu, oficiálních firemních porad a podobně, vzniknou přinejmenším dva další websity, na nichž poběží podobný systém. Můžeme se utěšovat tím, že náš systém je lepší. Můžeme si pozvat ke konzultaci českého génia Járu Cimrmana, který nás jistě ujistí o tom, že „o tak uchvátané prvenství není co stát“. Zatvrzelí zákazníci se však navzdory těmto neoddiskutovatelným faktům vesele registrují u obou horších konkurencí a z nevysvětlitelných důvodů odmítají přejít na náš geniální systém.

Něco je špatně! Aby nedošlo k mylné interpretaci: příčinou tohoto katastrofického scénáře není softwarové inženýrství. Selhal lidský faktor, konkrétně manažer projektu, který zřejmě zaspal dobu a nepochopil, že používat vodopádový model životního cyklu pro internetový projekt je projevem čirého bláznovství.

Svět se změnil

Klasické techniky softwarového inženýrství se týkají situace, která byla platná před deseti-dvaceti lety. Software byl vyvíjen spíše většími, organizovanými, stabilními týmy. Důraz, který se kladl na kvalitu, byl stále ještě způsoben obavou o to, aby se neopakovalo cosi jako softwarová krize, která přidusila vývoj programů před nástupem softwarového inženýrství. Zákazník si raději počkal trochu déle (nic jiného mu ani nezbývalo, konkurence bylo málo), ale očekával kvalitní výsledek.

Svět se však změnil hned několika způsoby. Zákazník sice stále očekává kvalitu, ale odmítá na ni dlouho čekat. V případě internetových projektů navíc často zákazník není předem definován; budoucí uživatelé neví (nebudou vědět), co má systém umět. Programátorské týmy se zmenšují, vzniká ohromné množství menších programů, “tým” je často složen z pěti lidí, výjimkou nejsou ani týmy čítající dva nebo tři programátory. Nejdůležitějším parametrem při vývoji softwaru je rychlost. Hlavní přece je, aby byla aplikace co nejdříve nasazena a mohla získávat uživatele.

Představa, že neexistují žádné vhodné metodiky pro vývoj “malých” aplikací, je ovšem špatná. Lze ji vyvrátit hned dvěma způsoby:

  • Většina “výrobců” klasických metodologií přidává do nových verzí nějaký dodatek, kapitolu, best-practice pro vývoj internetových projektů a pro podporu malých týmů. Jako příklad můžeme uvést třeba metodologii firmy Rational, známý Rational Unified Process, který se díky své rozsáhlosti, propracovanosti a robustnosti příliš na internetové aplikace nehodí. Metodologie je však velmi “ohebná” a umožňuje projektovým manažerům vytvořit si “svou vlastní metodologii” na mírů, podle konkrétních požadavků a možností. Navíc obsahuje hotovou konfiguraci nazvanou “RUP for Small Project”, o obsahu asi není potřeba hovořit. Na svých webových stránkách dále nabízí “white page” týkající se přímo internetových aplikací a jejich vývoji za použití Rational Unified Processu.
  • Vznikají zcela nové metodologie, které se snaží komplexně řešit dnešní požadavky na rychlý a flexibilní vývoj aplikací. Souhrně jsou tyto metodologie nazývány „agile methodologies“ (agilní, hbité metodologie) a asi nejznámnějším představitelem je extrémní programování. Kromě něj však nalézáme i další zajímavé projekty, například vývoj řízený testy (test-driven development). Zajímavou metodologií postavenou na principech agilních metodologií je také například SCRUM Development Process.

V tomto článku se nebudeme zabývat konkrétními metodologiemi. Jejich společným rysem je důraz na sepětí se zákazníkem či zadavatelem, důkladná komunikace, zpětná vazba, kladení zásadní důležitosti na fázi implementace, snaha redukovat dobu potřebnou pro analýzu a návrh a integrovat tyto fáze s implementací, pravidelné vyvíjení prototypů, odvaha zapracovávat změny, snaha o jednoduchost (jaká je nejednodušší varianta, která bude ještě fungovat?) a především velmi důsledné testování. Tyto metodologie se snaží stavět na přirozených principech, k nimž vývojáři více či méně inklinují, aniž o tom vědí (znáte nějakého programátora, který má radost z toho, že nejdřív musí napsat třicetistránkovou specifikaci, a pak teprve může začít programovat? V malých týmech je to běžné.).

Cílem tohoto článku bylo ukázat, že klasické, osvědčené softwarově-inženýrské postupy u určité, specifické třídy projektů, přestávají vyhovovat. Máme však k dispozici nové metodologie, díky nimž je možné učinit i vývoj nové, charakteristické třídy aplikací řízeným, strukturovaným a úspěšným.

Diskuze (63) Další článek: Lákadla CeBITu

Témata článku: Software, Programování, Klasický problém, Plod, Důkladné testování, Konkurence, Čiré bláznovství, Půl roku, Schvalovací řízení, Určitý nedostatek, Podrobné testování, Určitá doba, Známý princip, Development, Malý tým, Rational, Půl, Běžný zákazník, Neoddiskutovatelný fakt, Agile, M/s


Určitě si přečtěte

Pojďme programovat elektroniku: Když už vás ten chumel součástek prostě nebaví

Pojďme programovat elektroniku: Když už vás ten chumel součástek prostě nebaví

** Levné cetky z Asie stojí dolar ** Postavíte s nimi skoro vše od teploměru po spínač zavlažování ** Má to ale jeden háček. Bude to ošklivé a povětšinou nekvalitní

Jakub Čížek | 22

Osudová havárie Concordu: Před 18 lety přišel konec nadzvukových dopravních letadel

Osudová havárie Concordu: Před 18 lety přišel konec nadzvukových dopravních letadel

** Concorde byl nejrychlejším dopravním letadlem ** Atlantik dokázal přeletět za cca 3 až 3,5 hodiny ** Před osmnácti lety tragická havárie provoz těchto letadel prakticky ukončila

David Polesný, Jiří Černý | 37

Zapomeňte na kabely, vědci už mají prototyp 120kW bezdrátové nabíječky pro elektromobily

Zapomeňte na kabely, vědci už mají prototyp 120kW bezdrátové nabíječky pro elektromobily

** Vědci představili prototyp výkonné bezdrátové nabíječky pro elektromobily ** I přes vysoký výkon se pyšní vysokou efektivitou ** Bude budoucnost nabíjení elektromobilů bezdrátová?

Karel Javůrek | 46

Užijte si poslední změny času: Už od března 2019 můžeme mít trvale letní čas

Užijte si poslední změny času: Už od března 2019 můžeme mít trvale letní čas

** Evropská komise přijala legislativní návrh na zrušení střídaní času ** Možná tak v březnu 2019 přesuneme ručičky hodinek naposledy ** Od toho okamžiku bude permanentně platit letní čas

Karel Kilián | 106


Aktuální číslo časopisu Computer

Jak vytvořit a spravovat vlastní web

Velký test herních klávesnic a DVB-T2 tunerů

Vše o formátu RAW

Vybíráme nejlepší základní desku