Projekty informačních systémů

Branislav LACKO

Úvod

Projekty návrh a realizace podnikových automatizovaných informačních systémů (dle IS – informační systém) jsou velmi častými projekty ve všech firmách a institucích. Zkušenosti z úspěšných IT projektů ukazují, že je nutné pro jejich úspěch v maximálně možné míře využívat současné projektové řízení [1, 2, 4]. (Pozn. Na tomto portálu viz text „Současné projektové řízení)

Dnes se přitom, zejména v západních zemích (USA, GB, F, D atd.), upustilo od nahodilého a intuitivního přístupu k jejich navrhování. Na základě dobrých zkušeností se strukturovanými metodami návrhu a realizace IS jakými byly např. (MERISE - F, IDEF – USA [7,8], SSADM - GB [5, 6]), byla vyvinuta metoda RUP, založená na objektově orientovaném přístupu ke tvorbě softwaru pro IS, která je v současnosti celosvětově používána. V poslední době byla vyvinuty nové metody na základě využití agilního přístupu k tvorbě informačních systémů [12] pro menší projektové týmy (firmy) a pro urychlení vývoje IS.

Současné používané přístupy a postupy

IBM Rational Unified Process (RUP) je metodika vývoje softwaru [10, 11], která zvyšuje produktivitu vývojového týmu a umožňuje všem jeho členům využívat ty nejlepší prověřené postupy. Tento online návod zavádí téměř dvacetileté zkušenosti společnosti IBM Rational (dříve Rational Software Corp.) s vývojem softwaru do každodenní práce vašeho týmu prostřednictvím průvodců, šablon a příkladů všech klíčových aktivit, se kterými se při vývoji setkáváte. IBM Rational Unified Process zvyšuje efektivitu vaší práce:

  • přístupem, který sjednocuje tým
  • v praxi prověřenými nejlepšími praktikami softwarového vývoje
  • metodologií vývoje, která se jednoduše zavádí
  • snižováním rizika a zvyšováním předvídatelnosti softwarového vývoje
  • poskytováním kontroly nad plány a možnostmi dodání
  • zlepšováním týmové komunikace

 

Použití metody RUP je snadné také díky online průvodci, který pomáhá vývojářům (ale nejen jim) při provádění všech běžných aktivit v průběhu vývojového cyklu od řízení projektu, modelování business procesů a řízení požadavků až po architekturu vývoje, vizuální modelování, tvorbu dokumentace, ověřování kvality a řízení změn. IBM RUP je prezentován ve formátu HTML, což umožňuje platformově nezávislý přístup přes firemní intranet a grafickou navigaci umožňující uživatelům snadný přístup ke všem průvodcům a šablonám zvyšujícím produktivitu. Lze si vybrat, zda budeme sledovat informace vzhledem k dané roli, či vzhledem k úkolu.

RUP podporuje šest nejlepších praktik, které umožňují efektivní vývoj vysoce kvalitních aplikací:

  • iterativní vývoj zmírňující riziko v počátcích projektu
  • efektivní řízení požadavků
  • vizuální modelování pomáhající řídit komplexní vztahy a závislosti
  • na komponentách založené pružné architektury
  • kontrola kvality v průběhu celého cyklu
  • řízení změn v softwaru

RUP vychází z předpokladu, že u současných rozsáhlých systémů není možné na začátku přesně definovat celý problém, navrhnout řešení, provést implementaci a až na závěr, kdy je spotřebována většina přidělených finančních prostředků, celý systém otestovat. Proto RUP používá tzv. iterativní cyklus vývoje aplikace:

 

Obr. 1 Iterativní cyklus vývoje SW

 

 

 


1.Iterace                        2. Iterace                   -  -  -  -  -     N-tá iterace

                                                  Obr. 2 Postup vývoje IS v iteracích

Tento přístup je založen na následujících zásadách:

  • rozdělení celého projektu na 4 fáze (každá se skládá z několika iterací se životním cyklem typu “vodopád”)
  • výsledkem každé iterace je spustitelná verze
  • možnost objektivního posouzení stavu projektu
  • rovnoměrnější pracovní vytížení vývojářského týmu (Co nejdříve přináší konkrétní výsledky, snazší sledování průběhu projektu a dodržování stanovených termínů pro jednotlivé iterace.)
  • možnost testování „meziverzí“
  • spolupráce návrhářů s uživateli v průběhu celého projektu
  • včasné rozpoznání nesrovnalostí mezi požadavky, návrhem a implementací (Možnost kontrolovat a hodnotit dílčí části systému, omezuje se riziko vysokých nákladů způsobených úpravami produktu v pozdní fázi vývoje.)

RUP poskytuje proces podporující objektově orientované analýzy, plánování vývoje pro nové aplikace založené na mezinárodním grafickém standardu popisu objektově orientované analýzy a návrhu UML (Unified Modeling Language)

 

Obr. 3 Architektura RUP

 http://en.wikipedia.org/wiki/File:Development-iterative.gif[j4] 

Definice požadavků na vývoj softwaru se opírá o počítačovou podporu produktem Rational RequisitePro (RRP). RRP je mocný, ale snadno ovladatelný nástroj pro správu požadavků v průběhu vývojových projektů. Kombinuje jednoduchost produktu Microsoft Word s obrovskými možnostmi databáze. Jedná se o optimální prostředí pro týmově orientovanou správu požadavků a jejich seskupování na základě priorit. RRP pomůže podnikům lépe porozumět dopadům způsobeným změnami jednotlivých požadavků a analyzovat jejich vliv na ostatní požadavky, což umožní provádět rychlejší a kvalitnější rozhodnutí. Díky integraci s ostatními Rational nástroji přináší RRP možnost rychlejšího přístupu k požadavkům, které mají vliv na konkrétní projekt. Mezi klíčové vlastnosti RequisitePro patří:

  • doplnění oblíbené aplikace MS Word o běžně používané databáze
  • podpora pro definování a sledování vazeb mezi požadavky (pro lepší pochopení dopadu změn)
  • evidence různých typů požadavků a jejich atributů
  • spolupráce s uživateli v průběhu celého projektu
  • včasné rozpoznání nesrovnalostí mezi požadavky, návrhem a implementací (možnost kontrolovat a hodnotit dílčí části systému, omezuje se riziko vysokých nákladů způsobených úpravami produktu v pozdní fázi vývoje)
  • snadnější zapracování změn požadavků

 

RUP používá pro znázornění architektury systému pět pohledů. Jednotlivé pohledy řeší různé aspekty fungování systému, nejsou na sobě však nezávislé a do určité míry se překrývají. Všechny pohledy a modely nemusí být aplikovány pro všechny projekty.

 

Obr. 4 Základní přístupy k RUP

Pro odhadování potřeby pracovníků, času a nákladů se v oblasti ICT používá řada specializovaných postupů a metod např. COCOMO2, UCP, a jiné viz doporučená literatura [3, 4] případně jiné publikace softwarového inženýrství, např. klasická monografie Král-Demner [9].

            Skutečnost, že základní rámcový postup projektu informačního systému je odvozen ze zásad softwarového inženýrství neznamená, že by se neměly stanovit dílčí cíle, projektu naplánovat jednotlivé milníky, ohodnotit plánované činnosti a sestavit jejich posloupnosti činností, analyzovat rizika, provádět pravidelné vyhodnocování stavu projektu atd.   

Nejčastější nedostatky v projektech IS

Uveďme nejčastější nedostatky projektů IS, které jsou opakovaně zjišťovány při různých průzkumech neúspěšných projektů nezávislých analytických firem (Ernst&Young, Standish Group a další):

·         Problémem softwarových projektů bývá, že projektový tým nedovede skloubit metody softwarového inženýrství (tj. jak provádět funkční a datovou analýzu s následným funkčním a datovým modelováním návrhu softwaru pro informační systém) s metodami projektového řízení (Co?, Kdy?, Kdo?, Za kolik?, S jakým rizikem?, S jakým přínosem?, Pro koho?, Za jakých předpokladů?).

·         Velkým problémem je neomluvitelný optimismus při návrhu a řízení projektů ICT u specialistů tohoto oboru

·         Mnoho specialistů IT přeceňuje a upřednostňuje řešení technických otázek, které jsou spojeny s aplikací informačních technologií na úkor prvotního vyřešení architektury plánovaného informačního systému a to základě důkladné analýzy stávajícího stavu. Zde se také projevuje podceňování dohody zásadních standardů, které budou během návrhu používány.

·         Snad nejčastějším problémem je obtížná komunikace mezi zástupci dodavatele a uživatele. Je to v důsledku minimálních schopností IT odborníků k dobré komunikaci a povrchního zájmu uživatelů, kteří tyto záležitosti vnímají jako zdržování a zbytečnost. Nízká znalost organizace procesního řízení na obou stranách ještě více prohlubuje vzniklé komunikační problémy.

·         U velkého množství IT projektů se objevuje fatální selhání o dohodě, jak budou chápány a měřeny přínosy realizovaného IS z pohledu uživatele a to jak z hlediska zákazníka, který často ani není schopen očekávané popsat nebo předpokládá de facto nerealizovatelné přínosy. S tím souvisí i problém kvalitní specifikace cíle (cílů) projektu IS.

·         Obecně lze o velké většiny projektů IS a většiny IT firem vidět buď principiální ignorování současných principů a zásad projektového řízení (často některými IT firmami dokonce veřejné proklamované a prezentované jako jejich přednost), nebo nevyužívání doporučených metod projektového řízení, které je zdůrazňováno velkou specifičností oblasti informačních technologií a specifičností pracovních postupů konkrétní firmy, což (dle IT firmy) znemožňuje používat současné metody projektové řízení.

Zde uvedený výčet není vyčerpávající a uvedené problémy nejsou seřazeny podle nějakého kritéria. Jejich existence v projektu je vždy kritická. Článek ponechává stranou ty případy, kdy se zavádění IS děje ve firmě chaoticky a bez využití zásad projektového řízení i softwarového inženýrství!

Závěr

            Současná informační společnost potřebuje naléhavě v oblasti informačních projektů nastolit situaci, kdy většina projektů bude úspěšných, tedy dosáhne dohodnutých cílů v plánovaném čase s plánovanými náklady v potřebné kvalitě, přičemž realizace projektu a cíle projektu nevyvolají negativní dopady a projekt bude realizován za přijatelných rizik.

            Zdá se, že k tomu bude nutno věnovat ještě mnoho úsilí jak z hlediska využívání softwarového inženýrství, tak využívání projektového řízení.  

Literatura:

  

  1. Schwalbe, K.: Řízení projektů v IT. Computer Press Brno 2011, 632 stran
  2. Komzák, T.: Řízení IT projektů pro úplné začátečníky. Computer Press Brno, 2013, 248 stran
  3. McConnell, S.: Odhadování softwarových projektů (Jak správně určit rozpočet, termíny a zdroje). Computer Press 2006 Brno, 320 stran
  4. Guckenheimer, S. – Perez, J.: Efektivní softwarové projekty. Zoner Press Brno 2009, 255 stran
  5. http://en.wikipedia.org/wiki/Structured_systems_analysis_and_design_method
  6. http://www.ssadm.org
  7. http://en.wikipedia.org/wiki/IDEF
  8. http://www.idef.com/
  9. Král, J. – Dermner, J.: Softwarové inženýrství. Academia 1991 Praha, 324 stran
  10. http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process
  11. http://rational-ug.org/
  12. Buchalcevová, A.: Metodiky budování informačních systémů. Oeconomica 2009 Praha