Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky katedra informačních technologií. Návrh metodického rámce IS/ICT

Transkript

1 Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky katedra informačních technologií Návrh metodického rámce IS/ICT doktorská disertační práce Doktorand: Školitel: Obor: Ing. Alena Buchalcevová Doc. Ing. Norbert Žid, CSc. Informatika Praha, listopad 2003 ALENA BUCHALCEVOVÁ, LISTOPAD

2 Prohlášení Prohlašuji, že disertační práci na téma Návrh metodického rámce IS/ICT jsem vypracovala samostatně. Použitou literaturu a podkladové materiály uvádím v přiloženém seznamu literatury. V Praze 10.listopadu 2003 Ing. Alena Buchalcevová ALENA BUCHALCEVOVÁ, LISTOPAD

3 Děkuji svému školiteli Doc. Ing. Norbertu Židovi, CSc. za vedení této práce. ALENA BUCHALCEVOVÁ, LISTOPAD

4 Abstrakt: Práce je zaměřena na metodiky pro vývoj, údržbu a provoz informačních systémů, které jsou označovány jako metodiky budování IS/ICT. Nejprve jsou analyzovány existující metodiky a jsou navržena kritéria umožňující stávající metodiky kategorizovat. Tato kategorizace metodik a navržený metapopis metodik umožňují strukturovaně přistupovat k detailní analýze metodik a vybrané metodiky jednotně charakterizovat. Podrobně jsou analyzovány dva hlavní metodické proudy, které jsou označovány jako rigorózní metodiky a agilní metodiky. Cílem práce je navrhnout metodický rámec pro budování informačního systému firmy, tedy metametodiku zahrnující vzory metodik určené pro různé typy řešení (vývoj nového informačního systému, rozvoj informačního systému, nasazování typového aplikačního softwarového vybavení), pro různé problémové domény a různé typy projektů. Kromě rigorózních a agilních metodik jsou v práci analyzovány další zdroje, ze kterých vychází návrh metodického rámce, zejména metodika MMDIS, Referenční model MKIT, Modelem řízená architektura (Model Driven Architecture) a Architektura orientovaná na služby (Service Oriented Architecture). Návrh metodického rámce definuje principy metodického rámce, jeho architekturu, prvky, klasifikaci metodických vzorů a metamodel. Obsah metodického vzoru je dokumentován na příkladě vzoru M02 Nový objektově orientovaný vývoj obecného software vlastními silami. Metodický rámec definuje i procesy vytvoření metodiky pro konkrétní projekt. Klíčová slova: metodika, metametodika, informační systém, metodický rámec, metodický vzor, architektura informačního systému, proces, softwarové inženýrství, řízení, služba, model, rigorózní metodika, agilní metodika, kategorizace metodik ALENA BUCHALCEVOVÁ, LISTOPAD

5 Abstract: Dissertation focus is on Information System Development, Upgrade and Operation Methodologies named as Information System Building Methodologies. First existing methodologies are analyzed and categorization criteria specified. This categorization and methodologies metadescription enable structured approach to detailed Methodologies analysis and uniform characterization. Two main methodological streams Rigorous and Agile Methodologies are in detail analyzed. Dissertation goal is proposal of Methodological Framework for IS/ICT Building, e.g. Metamethodology encompasses Methodological Patterns for various solution types (new IS development, IS evolution, TASW implementation), various problem domains and various project types. Except Rigorous and Agile Methodologies other sources for Methodological Framework proposal are analyzed Multidimensional Management and Development of Information System, IS/ICT Management Model MKIT, Model Driven Architecture, Service Oriented Architecture. Methodological Framework proposal specifies principles, architecture and metamodel of this framework and Methodology Patterns hierarchy. Methodology Pattern content is documented by defining Methodology Pattern for New object oriented own common software development. Methodological Framework defines also processes for concrete methodology construction. Key words: Methodology, Metamethodology, Information System, Methodological Framework, Methodological Pattern, IS/ICT Architecture, Process, Software Engineering, Management, Rigorous Methodology, Agile Methodology, Methodology Categorization ALENA BUCHALCEVOVÁ, LISTOPAD

6 Zusammenfassung: Die Dissertation beschäftigt sich mit Methodiken für Entwicklung, Instandhaltung und Betrieb der Informationssysteme, die IS/ICT Aufbaumethodiken genannt werden. Es werden hier bestehende Methodiken analysiert und die Kategorienkriterien verwendet. Durch diese Kategorienkriterien und Meta Methodikbeschreibung ist es möglich strukturierten und einheitlichen Zugriff zur Methodikenanalyse zu realisieren. Es wird eine umständliche Analyse zweier Hauptmethodikenkategorien durchgeführt, die rigorose und agile Methodiken genannt werden. Im Hauptteil der Dissertation wird der Methodische Rahmen für IS/ICT definiert. Es handelt sich um Meta Methodik, die methodischen Formeln für verschiedene Lösungstypen (neue IS/ICT Entwicklung, IS/ICT Erweiterung, TASW Einsatz), Problembereiche und Projekttypen enthält. Es werden nicht nur rigorose und agile Methodiken analysiert, sondern auch andere für den methodischen Rahmen wichtige Quellen MMDIS Methodik, MKIT Modell, Model Driven Architecture, Service Oriented Architecture. Der Methodische Rahmen für IS/ICT definiert Prinzipien, Struktur, Elemente und Meta Modelle des Rahmens und Hierarchie der methodischen Formeln. Es wird hier auch ein Beispiel der methodischen Formel eingeführt, und zwar die Formel Neue objektorientierte eigene Softwareentwicklung. In dem Rahmen sind auch Meta Prozesse für spezifische Methodikkonstruktion definiert. Schlüsselwörter: Methodik, Meta Methodik, Informationssystem, Methodischer Rahmen, methodische Formel, IS/ICT Struktur, Prozess, Softwareingenieurwesen, Steuerung, Modelle, rigoros Methodik, agil Methodik, Methodikenkategorie ALENA BUCHALCEVOVÁ, LISTOPAD

7 Obsah 1 ÚVOD Cíle disertační práce Východiska řešení Struktura práce Analýza současného stavu budování IS/ICT Návrh kategorizace metodik Analýza vybraných metodik a dalších zdrojů Návrh metodického rámce MEFIS Metody dosažení cílů práce Použitá terminologie Stav řešení problematiky v ČR a ve světě Oblasti řešené problematiky, které nejsou v práci obsaženy Přínosy disertační práce Typografické konvence SOUČASNÝ STAV METODIK BUDOVÁNÍ IS/ICT Součásti podnikové informatiky Faktory ovlivňující metodiky budování IS/ICT Specifika budování IS/ICT Složitost vývoje software Procesy vývoje software jsou empirické procesy Vývoj software jako kooperativní hra Software jako metaprodukt Kategorizace metodik Kritérium Zaměření metodiky Kritérium Rozsah metodiky Kritérium Váha metodiky Kritérium Typ řešení Kritérium Doména Kritérium Přístup k řešení Metapopis metodiky Shrnutí kapitoly RIGORÓZNÍ A AGILNÍ METODIKY Rigorózní metodiky Capability Maturity Model for Software (SW-CMM) Identifikace metodiky a zdrojů Definice základních pojmů Charakteristika metodiky Instance CMM PSP a TSP Hodnocení metodiky Metodika OPEN Identifikace metodiky a zdrojů Charakteristika metodiky Hodnocení metodiky Metodika Rational Unified Process Identifikace metodiky a zdrojů Charakteristika metodiky Hodnocení metodiky Metodika Enterprise Unified Process Identifikace metodiky a zdrojů Charakteristika metodiky Hodnocení metodiky Agilní metodiky Manifest pro agilní vývoj software...42 ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 7

8 3.2.2 Dynamic Systems Development Method (DSDM) Identifikace metodiky a zdrojů Charakteristika metodiky Hodnocení metodiky Adaptive Software Development (ASD) Identifikace metodiky a zdrojů Charakteristika metodiky Hodnocení metodiky Lean development Identifikace metodiky a zdrojů Charakteristika metodiky Hodnocení metodiky Feature-Driven Development (FDD) Identifikace metodiky a zdrojů Charakteristika metodiky Hodnocení metodiky Crystal metodiky Identifikace metodiky a zdrojů Charakteristika metodiky Hodnocení metodiky Scrum Identifikace metodiky a zdrojů Charakteristika metodiky Hodnocení metodiky Extrémní programování (XP) Identifikace metodiky a zdrojů Charakteristika metodiky Hodnocení metodiky Agilní modelování Identifikace metodiky a zdrojů Charakteristika metodiky Hodnocení metodiky Porovnání rigorózních a agilních metodik Shrnutí kapitoly ZDROJE PRO NÁVRH METODICKÉHO RÁMCE MMDIS Fáze vývoje IS/ICT Konceptuální model MMDIS Zhodnocení metodiky MMDIS a návrh jejího rozšíření Modely řízení informatiky Zhodnocení rigorózních metodik z pohledu návrhu metodického rámce Zhodnocení agilních metodik z pohledu návrhu metodického rámce Učící se organizace Teorie komplexních adaptivních systémů Firemní kultura Lidský faktor Komunikace Architektura IS/ICT Modelem řízená architektura Orientace na služby Služby informatiky Architektura orientovaná na služby Shrnutí kapitoly METODICKÝ RÁMEC IS/ICT MEFIS Metodický rámec jako metametodika Zaměření metodického rámce MEFIS Charakteristiky metodického rámce MEFIS Orientace na služby Celopodnikové hledisko a integrace...73 ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 8

9 5.3.3 Integrace perspektivy řízení a perspektivy softwarově inženýrské Podpora různých typů řešení Podpora řízení znalostí Rozlišování úrovní abstrakce Rozlišování mezi typem prvku a instancí prvku Metodické vzory Využívání principů a praktik agilních metodik Vazba na systémy hodnocení softwarových procesů Klasifikace metodických vzorů Klasifikační kritérium Doména Klasifikační kritérium Typ řešení Klasifikační kritérium Způsob řešení Klasifikační kritérium Přístup k řešení Projektová klasifikační hlediska Architektura MEFIS Prvky metodických vzorů Fáze Dimenze Role Principy Praktiky Procesy Činnosti Techniky Nástroje Produkty Metriky Standardy Vzory Obecný metodický vzor Principy obecného metodického vzoru Princip sladění IS/ICT s podnikovými procesy Princip orientace na služby s podporou globální architektury Princip rozlišování úrovní abstrakce Princip integrace Princip prvořadé úlohy lidí Princip modelem řízeného budování IS/ICT Metodický vzor Nový objektově orientovaný vývoj obecného software vlastními silami Metamodel metodického rámce MEFIS Shrnutí kapitoly ÚROVEŇ METAMETODIKY METODICKÉHO RÁMCE Metaprincipy MEFIS Metaprocesy MEFIS Customizace metodického rámce pro organizaci Vytvoření metodiky pro konkrétní projekt Výběr metodického vzoru Prvotní návrh metodiky Přizpůsobování metodiky v průběhu projektu Udržování báze metodik Analýzy a vyhodnocování projektů Rozvoj báze metodických vzorů Shrnutí kapitoly ZÁVĚRY Zhodnocení dosažení cílů práce Specifikace vlastního přínosu v návrhu metodického rámce MEFIS Aplikace výsledků práce Náměty pro další vědecké zkoumání SEZNAM POUŽITÉ LITERATURY SEZNAM POUŽITÝCH POJMŮ A ZKRATEK ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 9

10 SEZNAM POUŽITÝCH OBRÁZKŮ, GRAFŮ A TABULEK Seznam obrázků Seznam tabulek SEZNAM PŘÍLOH Příloha 1 Klíčové oblasti procesů (KPA) a cíle na jednotlivých úrovních zralosti CMM Příloha 2 Principy a praktiky agilního modelování Příloha 3 Porovnání rigorózních a agilních metodik Příloha 4 Porovnání technik použitelných pro modelování architektury Příloha 5 Metapopis vybraných rigorózních a agilních metodik Příloha 6 Metodický vzor M02 Nový objektově orientovaný vývoj obecného software vlastními silami Příloha 7 Role vzoru M02 Nový objektově orientovaný vývoj obecného software vlastními silami Příloha 8 Principy vzoru M02 Nový objektově orientovaný vývoj obecného software vlastními silami Příloha 9 Praktiky softwarově inženýrské vzoru M02 Nový objektově orientovaný vývoj obecného software vlastními silami Příloha 10 Procesy vzoru M02 Nový objektově orientovaný vývoj obecného software vlastními silami ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 10

11 1 Úvod Tato doktorská disertační práce se zabývá metodikami budování informačních systémů a informačních a komunikačních technologií (IS/ICT). Je řešena jako součást Výzkumného záměru Katedry informačních technologií VŠE a měla by být dále rozvíjena v rámci grantového projektu Řízení inovace informačního systému firmy s využitím metodického rámce KIT, jehož návrh byl v letošním roce podán na GAČR. 1.1 Cíle disertační práce Na základě výzkumného záměru katedry a jejích rozvojových úkolů byly definovány následující cíle disertační práce. Hlavní cíl disertační práce Hlavním cílem disertační práce je navrhnout metodický rámec pro budování informačního systému firmy, který odráží současné trendy v informačních technologiích i metodických přístupech. Metodický rámec je chápán jako uspořádaná skupina metodik 1, které jsou zaměřeny jak na vývoj nového informačního systému, tak na rozvoj informačního systému i nasazování typového aplikačního softwarového vybavení. Metodiky pokrývají celý životní cyklus informačního systému 2 včetně procesů na úrovni celé organizace a jsou specializovány na různé problémové domény 3 a různé typy projektů. Dílčí cíle disertační práce Od hlavního cíle práce jsou odvozeny dílčí cíle práce: charakterizovat současný stav v oblasti metodik budování informačních systémů ve světě i v České republice, definovat kritéria kategorizace existujících metodik vývoje informačních systémů, analyzovat a kategorizovat nejvýznamnější současné metodiky a architektonické přístupy, definovat koncept metodického rámce a jeho charakteristiky, navrhnout a popsat architekturu metodického rámce, definovat prvky metodik a způsob jejich sdílení, definovat metamodel metodického rámce, definovat postup využití metodického rámce při vytvoření metodiky pro konkrétní projekt. 1.2 Východiska řešení Práce vychází především z metodiky MMDIS (Multidimensional Management and Development of Information System), která je vyvíjena od začátku 90. let na Katedře informačních technologií VŠE Praha 4. Autorka je dobře obeznámena s touto metodikou, neboť ji vyučuje a využívala ji i na projektech v praxi. Práce vychází i z dalších metodických materiálů, které na KIT vznikly, jako je Referenční model řízení informatiky, na jehož rozšíření se autorka také podílela 5. Při vymezení termínů v oblasti metodik autorka mimo jiných zdrojů vychází 1 respektive metodických vzorů (pojem metodický vzor viz 5.4) 2 od globální strategie podniku až po provoz a údržbu 3 například systémy ERP(Enterprise Resource Planning), Business Intelligence, workflow, elektronické podnikání a další 4 viz [Voříšek,1992], [Voříšek,1997], [Dohnal,Pour,1999], [Novotný,2003] 5 doplnění procesů metodiky COBIT do Referenčního modelu řízení informatiky ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 11

12 z terminologického slovníku pro oblast informatiky, který byl na Katedře informačních technologií vytvořen. Při analýze existujících metodik a řešení hlavního cíle práce se autorka opírala o své praktické zkušenosti s vývojem programových systémů 6. Od začátku 90 let se věnuje objektově orientovanému přístupu jak v oblasti programování, tak i v oblasti analýzy a návrhu a metodikám vytváření informačních systémů. Práce vychází proto také z vlastních publikací autorky [Buchalcevová,Pavlíčková,2002], [Buchalcevová,Stanovská,Šimůnek,2002] a příspěvků na konferencích [Buchalcevová,Drbohlav,1999], [Buchalcevová,2002], [Buchalcevová,2003], [Buchalcevová,SI2003], 1.3 Struktura práce Práce je rozdělena do čtyř logických celků, které zachycuje obrázek 1.1 a které jsou rozepsány v následujících podkapitolách. obrázek 1.1: Struktura disertační práce Analýza současného stavu budování IS/ICT Smysl hlavního cíle disertační práce, návrhu metodického rámce MEFIS 7, je odvozen ze současné situace v metodikách budování informačních systémů. Tato situace je analyzována v kapitole 2 Současný stav metodik budování IS/ICT Návrh kategorizace metodik Na základě zjištění, že ve světové odborné literatuře neexistuje odpovídající kategorizace metodik spojených s vytvářením informačních systémů, jsou navržena kritéria umožňující metodiky kategorizovat. Popis těchto kritérií a kategorie metodik jsou uvedeny v podkapitole 2.4 Kategorizace metodik Analýza vybraných metodik a dalších zdrojů Navržená kategorizace metodik a metapopis metodiky umožňují strukturovaně přistupovat k detailní analýze metodik a vybrané metodiky jednotně charakterizovat. V současnosti se v odborné literatuře věnované 6 byla spoluřešitelem typového aplikačního software - subsystém Pracovníci a mzdy a Metainformačního systému 7 Methodological framework for IS/ICT systems blíže viz kapitola 5 Metodický rámec IS/ICT MEFIS ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 12

13 metodickým přístupům k vývoji informačních systémů i na praktických projektech můžeme setkat se dvěma hlavními metodickými proudy, které jsou označovány jako rigorózní metodiky a agilní metodiky. V kapitole 3 Rigorózní a agilní metodiky je nejprve definováno přiřazení těchto proudů k navržené kategorizaci metodik a potom jsou analyzovány a porovnány nejvýznamnější metodiky obou skupin. V kapitole 4 Zdroje pro návrh metodického rámce jsou souhrnně charakterizovány zdroje, které nejvíce ovlivnily návrh metodického rámce Návrh metodického rámce MEFIS Kapitola 5 Metodický rámec IS/ICT MEFIS obsahuje popis vlastního řešení metodického rámce. Definuje základní charakteristiky metodického rámce, jeho architekturu, prvky a metamodel. Definuje klasifikaci metodických vzorů a obsah metodického vzoru dokumentuje na příkladě vzoru M02 Nový objektově orientovaný vývoj obecného software vlastními silami, který je uveden v podkapitole 5.8 a v přílohách V kapitole 6 Úroveň metametodiky metodického rámce jsou definovány principy vytvoření metodiky a procesy při odvození metodiky pro konkrétní projekt. 1.4 Metody dosažení cílů práce Postup dosažení hlavního cíle práce byl rozdělen do výše uvedených dílčích cílů, které určují základní strukturu disertační práce. Charakteristika současné situace v oblasti metodik budování informačních systémů je výsledkem analýzy mnoha článků a výzkumných zpráv 8, jakož i publikací zabývajících se v širším kontextu situací ve společnosti začátkem nového tisíciletí 9. Na základě analýzy celé řady světových i několika českých metodik zabývajících se problematikou vývoje informačních systémů, dospěla autorka k závěru, že neexistuje komplexní kategorizace těchto metodik. Na základě podrobné analýzy těchto metodik, jejich porovnání a vlastních zkušeností, navrhla autorka kritéria umožňující komplexní kategorizaci existujících metodik a kategorie metodik. Na základě této kategorizace potom navrhla metapopis metodiky. Navržená kategorizace pak byla uplatněna při výběru metodik, které byly podrobně analyzovány. Docházelo ke kritické analýze získaných poznatků z hlediska vymezených cílů práce (zejména s ohledem na jejich využití pro naplnění hlavního cíle práce návrh metodického rámce) a jejich následné syntéze na základě dostupných pramenů, vlastních zkušeností a názorů autorky práce. Výsledkem syntézy poznatků je vlastní návrh metodického rámce MEFIS. Ve světové teoretické literatuře se můžeme setkat s rámci (frameworks) pro metodiky či softwarové procesy, ale jejich pojetí je mnohem užší. Autorce se nepodařilo v literatuře nalézt řešení, které by bylo srovnatelné s navrženým metodickým rámcem. Hlavním problémem práce tedy bylo popsat východiska, strukturu a obsah metodického rámce a podmínky jeho aplikace tak, aby bylo možné navržený metodický rámec vědecky přijmout jako možný přístup k budování IS/ICT, a tak umožnit i jeho aplikaci v konkrétních praktických případech. Problematika budování IS/ICT je velmi rozsáhlá. Metodický rámec je z hlediska architektury, prvků, základních principů a klasifikace metodických vzorů zaměřen na celou oblast IS/ICT včetně provozu informačních systémů. Je tak vytvořen základ pro další rozvoj tohoto rámce a doplňování specifických metodických vzorů. Podrobné rozpracování metodického vzoru potom autorka zaměřila na oblast, se kterou má praktické zkušenosti, tedy oblast objektově orientovaného vývoje. Základní metody, které byly použity při návrhu metodického rámce byly metody abstrakce, generalizace specializace a metamodelování. Princip metodik samotných je založen na 8 zejména [Metagroup,2002], [Metagroup,6/2003], [Metagroup,7/2003], [Fowler,Highsmith], [Infotech] 9 zejména [Drucker,2001], [Gibson], [Vodáček,1999] ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 13

14 abstrakci od konkrétních detailů a zachycení podstaty problémů. Metodický rámec jako metametodika jde v aplikaci metody abstrakce ještě dál. Metodický rámec je popsán ve formě metamodelu, a tak je možné jej dále rozvíjet. Metoda generalizace specializace byla použita pro definování obecných vlastností metodického rámce a návrh obecného metodického vzoru jako vzoru, který definuje prvky společné ostatním metodickým vzorům. Na základě specializace jsou potom doplňovány specifické prvky do doménových metodických vzorů. Z původních analýz a návrhů byl text zkrácen tak, aby byly dostatečně výstižně a kompaktně popsány důležité principy, ale zároveň aby text zůstal v dostatečné míře srozumitelný. Doplňkové materiály, které by mohly rušit plynulou čitelnost textu, jsou připojeny ve formě příloh práce. 1.5 Použitá terminologie Definice použitých termínů a zkratek jsou uvedeny souhrnně v závěru práce v kapitole Seznam použitých pojmů a zkratek. Oblast IS/ICT nemá v některých případech obecně uznávané české ekvivalenty pro vybrané anglické termíny 10. V těchto případech je proto uveden anglický ekvivalent termínu v závorce za jeho českým překladem, některé názvy metodik jsou ponechány v angličtině. Protože terminologie v oblasti informačních systémů i metodik pro jejich vytváření není ustálená a jednotná, jsou v této v této podkapitole vymezeny základní termíny tak, aby při jejich použití v dalším textu byl jasný jejich význam. Jedná se o termíny v oblasti předmětu metodik, tedy budovaného systému, a termíny týkající se samotných metodik. Základním termínem v oblasti předmětu metodik je informační systém. Termín informační systém 11, respektive zkratka IS/ICT se používá již delší dobu a je zaveden i v české odborné literatuře. V současnosti, kdy se IS/ICT stávají integrální součástí podnikových procesů, se můžeme setkat zejména v anglicky psané odborné literatuře s novými termíny celopodnikové systémy na bázi ICT (Enterprise ICT Systems), celopodniková softwarově intenzivní řešení (Enterprise Software Intensive Solutions) a dalšími. Tyto termíny jsou velmi výstižné v anglickém jazyce, ale obtížně se překládají do češtiny a jejich české překlady se zatím dostatečně nevžily. Proto budu v práci používat zažitý termín informační systém respektive IS/ICT, i když jsem si vědoma, že nevyjadřuje dokonale současné chápání informatiky jako neoddělitelné součásti celého systému organizace včetně spojení s jinými organizacemi 12. Informační systém zahrnuje jak automatizované, tak neautomatizované činnosti. Automatizované činnosti podporuje software 13, tedy programové vybavení. V anglicky psané odborné literatuře je pojem software či zkratka SW používán často a přenáší se i do české odborné literatury. V kontextu vývoje software se používá také termín programový systém. Programovým systémem je chápán softwarový produkt, který je tvořen množinou programových jednotek (modulů, objektů, komponent, služeb) a jejich vzájemných vazeb. [Buchalcevová,Stanovská,Šimůnek,2003]. Analytická část práce spočívá v rozboru řady existujících zahraničních metodik. Při jejich popisu jsou použity termíny, které se v těchto metodikách používají, a je definován jejich vztah k termínům zavedeným pro potřeby této práce V oblasti metodik samotných je třeba vymezit především pojem metodika. Metodika představuje v obecném smyslu souhrn metod a postupů pro realizaci určitého úkolu. V anglických textech se používá termín methodology, který není do češtiny překládán jednotně. Někteří autoři používají pojem metodika, jiní pojem metodologie. Chápu pojem metodologie jako nauku o metodikách, a proto budu ve své práci používat pro 10 například Service Oriented Architecture 11 Informační systém je systém jehož prvky jsou informační a komunikační technologie, data a lidé. Cílem informačního systému je efektivní podpora informačních a rozhodovacích procesů na všech úrovních řízení organizace (podniku). [KIT,2003] 12 Mluvíme o integraci aplikací - Enterprise Application Integration. 13 Programy, procedury a pravidla pro zpracování konkrétní úlohy na počítači neboli pokyny počítači, jak má danou úlohu řešit. Program je napsán v programovacím jazyku (např. Java, C, Pascal, Cobol, assembler). Software se dělí na základní (operační systém, databázový systém, komunikační systém) a aplikační. [KIT,2003] ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 14

15 vyjádření metod, postupů a dalších prvků termín metodika. Předmětem mé disertační práce jsou metodiky, které se zabývají vývojem a údržbou informačního systému. Tyto metodiky bývají označovány v některých zdrojích jako metodiky vývoje IS/ICT. Protože se zaměřuji kromě vývoje nového řešení také na metodiky pro nasazení hotových řešení, rozšíření řešení a integraci stávajících řešení, označuji tyto metodiky jako metodiky budování IS/ICT. Při vymezení pojmu metodika budování IS/ICT vyjdu z definice uvedené v metodice MMDIS, podle které je metodika tvořena obecně uznávanými postupy a návody, které popisují činnosti při analýze, návrhu, vývoji, nasazování software stejně jako činnosti spojené s řízením projektu. Cílem metodiky je formalizovat postupy, definovat zodpovědnosti a pravidla komunikace [Voříšek,1997]. Tato definice je rozvedena například v [Řepa,1999] a vymezuje metodiku tvorby informačního systému jako doporučený souhrn etap, přístupů, zásad, postupů, pravidel, dokumentů, řízení, metod, technik a nástrojů pro tvůrce informačních systémů, který pokrývá celý životní cyklus informačních systémů. Metodika by se měla vztahovat na všechny prvky informačního systému, na pracovníky, data, software, hardware, organizační procedury, ekonomické otázky spojené s vývojem a provozem systému, doporučené dokumenty, způsoby řízení v jednotlivých fázích životního cyklu systému. Podle této definice se metodika tvorby informačního systému zaměřuje na oblast spojenou jak s vývojem, tak s provozem informačního systému. Vývoj a provoz informačního systému je obtížné oddělit, neboť některé části informačního systému (subsystémy, moduly, komponenty, služby aj.) jsou v daném okamžiku v provozu, některé jsou rozvíjeny, některé jsou vytvářeny nově a všechny musí být dohromady integrovány. Proto metodiky budování IS/ICT pokrývají jak oblast vývoje, tak provozu IS/ICT. Problematikou provozu IS/ICT se však nezabývají v celé šíři, neboť je tato oblast řešena v rámci metodik pro řízení informatiky (například COBIT, ITIL blíže viz 4.2). Termín metodika budování IS/ICT je pro účely této práce vymezen následovně: Metodika budování IS/ICT definuje principy, procesy, praktiky, role, techniky, nástroje a produkty používané při vývoji, údržbě a provozu informačního systému, a to jak z hlediska softwarově inženýrského, tak z hlediska řízení. Kromě pojmu metodika se můžeme setkat s pojmy proces a softwarový proces. Mnohé metodiky mají slovo proces přímo ve svém názvu 14. Existují metodiky hodnocení softwarových procesů, mluví se o zlepšování softwarových procesů apod. Softwarový proces je v kontextu těchto přístupů definován jako sada činností, metod, praktik a transformací, které lidé používají pro vývoj a údržbu software a dalších s tím spojených produktů (projektových plánů, návrhů, testovacích případů apod.) [Paulk]. Pojem softwarový proces je v této práci používán jen v rámci popisu zahraničních metodik, které tento pojem zavádějí (například Capability Maturity Model viz. podkapitola 3.1.1), v ostatních částech práce je spíše používán pojem proces informatiky tak, jak je zaveden v podkapitole 2.1. V některých zdrojích je pojem softwarový proces používán jako synonymum metodiky. V této práci je však metodika pojímána v širším smyslu a kromě procesů zahrnuje další prvky 15. Ve významu popisu procesů, které probíhají při vývoji, údržbě a provozu IS/ICT, dávám přednost pojmu metodika, který mnohem lépe vyjadřuje skutečnost, že jeho náplní je popis procesů. Naproti tomu pojem proces může znamenat jak popis procesu, tak i již probíhající proces. Pro vyjádření skutečně probíhajícího procesu používám pojem instance procesu. V disertační práci je zaveden pojem metaproces. Metaproces reprezentuje proces, který probíhá při aplikaci metodiky, tedy vytvoření a přizpůsobení metodiky pro konkrétní projekt. 14 příkladem je metodika Rational Unified Process, Open Process, Object-Oriented Software Process a další, které jsou popsány v kapitole 3 Rigorózní a agilní metodiky. 15 například principy, praktiky, znalosti a další prvky popisované v podkapitole 5.6 ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 15

16 Hlavním cílem disertační práce je návrh metodického rámce. Pojem metodický rámec je definován pro účely této práce a vychází z principu rámce a aplikačního rámce tak, jak je používán při objektově orientovaném vývoji 16. Metodický rámec (Methodology framework) je kolekce metodických vzorů pro různé domény, typy řešení a způsoby řešení spolu s principy a procesy pro vytvoření konkrétní metodiky. 1.6 Stav řešení problematiky v ČR a ve světě Složitost tvorby informačních systémů, kterou se podrobněji zabývám v podkapitole 2.3 Specifika budování IS/ICT, se již dlouhou dobu snaží řešit metodiky budování informačních systémů. I přes existenci a zavádění mnoha různých metodik, je stále velmi mnoho projektů vývoje informačních systémů neúspěšných. Dle výsledků výzkumu společnosti Standish Group v roce 2000 splňovalo kritéria úspěšnosti 17 jen 28% všech projektů na vývoj aplikací. [Johnson,2001] Standish Group na základě svých průzkumů definuje také 10 faktorů, které mají největší význam pro úspěch IS/ICT projektů, mezi kterými je i existence formální metodiky. Tyto skutečnosti ukazují význam metodiky pro úspěch IS/ICT projektu a s ohledem na současný stav IS/ICT projektů naléhavou potřebu zabývat se oblastí metodik. Metodik, které se zabývají budováním IS/ICT je velké množství. Problém však spočívá v tom, že nejsou dostatečně a jednotně popsány ani rozumně kategorizovány. Většinou se jedná o metodiky zaměřené jen na určitou fázi budování informačního systému 18, na určitou věcnou oblast, na určitý typ projektu a podobně. Zároveň nejsou definována kritéria pro výběr vhodné metodiky pro určitý typ projektu ani postupy pro její přizpůsobení na konkrétní podmínky firmy a projektu. V poslední době se myšlenky na výběr vhodné metodiky a její přizpůsobení začínají ve světě objevovat 19, v podmínkách České republiky však nejsou tyto přístupy systematicky popsány ani používány. V rámci diplomové práce [Šťovíček,2002], na které se autorka podílela jako vedoucí práce, byl prováděn průzkum využití vývojových nástrojů a dalších skutečností spojených s vývojem software ve firmách na území České republiky. Průzkum byl realizován formou dotazníku realizovaného jako dynamická webová aplikace na podzim roku Formou elektronické pošty bylo osloveno cca 300 firem z oblasti IT 20. Jedna z otázek průzkumu byla zaměřena na použití metodik v IT firmách. 63% firem uvedlo, že nepoužívají žádnou metodiku. 17% firem, které používají nějakou metodiku, přitom využívá vlastní metodiky respektive modifikace obecných metodik. I když průzkum prováděný v této diplomové práci nelze pokládat s ohledem na poměrně nízkou odezvu 21 za průkazný, přesto částečně odráží situaci s používáním metodik v České republice. Porovnáme-li tyto výsledky s výsledky prezentované ve zprávě 2003 Worldwide IT Benchmark Report společnosti META Group [Metagroup,2002], v níž se uvádí, že 51,6% všech respondentů používá při vývoji informačních systémů metodiku, vidíme zaostávání České republiky v používání metodik. Přitom stejná zpráva [Metagroup,2002] uvádí i pět faktorů, které mají při budování IS/ICT v současnosti nejvyšší prioritu. Mezi těmito faktory je na čtvrtém místě uvedeno řízení projektu 22 respektive zlepšování softwarových procesů 23, tedy faktory, které spadají do oblasti metodik budování IS/ICT. Nejen výsledky tohoto průzkumu, ale i zkušenosti mnoha projekčních manažerů prezentované v odborných publikacích 24 ukazují na velký význam metodik pro úspěch softwarových projektů. Tuto skutečnost si začínají informační manažeři ve světe uvědomovat. 16 Rámec (Framework) je kolekce abstraktních a konkrétních tříd a vztahů mezi nimi, která představuje základ návrhu subsystému. Z rámce se specializací tříd vytvářejí konkrétní instance, které tvoří konkrétní aplikaci. Aplikační rámec (Application framework) je potom množina abstraktních a konkrétních tříd pro určitou aplikační doménu. 17 úspěšnost byla definována tak, že projekt je dokončen včas, dle rozpočtu a se všemi specifikovanými funkcemi 18 například objektově orientovaný návrh systému 19 například [Cockburn,MetPerProj], [Ambler,DP], [Highsmith,2002] 20 jako zdroj byla použita databáze České společnosti pro systémovou integraci (ČSSI) a webové prezentace podniků, dále byly vybrány firmy ze žebříčku TOP100 firem ČR 21 14% obeslaných respondentů odpovědělo 22 dle hodnocení respondentů z USA 23 dle hodnocení respondentů z ostatních zemí světa mimo USA 24 zejména [Highsmith,2002], [Cockburn,Learn] ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 16

17 Situace v podmínkách ČR je, jak bylo uvedeno výše, horší. Důvody této skutečnosti mohou být různé, ale jsem přesvědčena, že mezi hlavní důvody patří: nedostatek českých metodik 25, neboť většina metodik je v angličtině a nejsou lokalizovány do češtiny, metodiky se zpravidla šíří na komerční bázi a České firmy nechtějí či nemohou vydávat prostředky na nákup metodik, problémy s aplikací metodik zejména, pokud jsou v angličtině 26. Proto si myslím, že je třeba zejména v podmínkách ČR v oblasti metodik vývoje IS/ICT ještě mnoho udělat. A tato disertační práce by v tom měla pomoci. 1.7 Oblasti řešené problematiky, které nejsou v práci obsaženy Problematika budování informačních systémů je velmi rozsáhlá. Disertační práce nemůže tuto oblast zpracovat v celé šíři detailně. Hlavní cíl práce, návrh metodického rámce, je zaměřen na metodické zajištění celé oblasti IS/ICT vývoje, údržby i provozu IS/ICT. Záměrem je, aby navržená struktura a architektura metodického rámce umožňovala postupné doplňování specifických metodických vzorů pro různé domény, různé typy řešení IS/ICT i jeho provozu. Pro návrh koncepce metodického rámce je tedy předmětem řešení celá oblast IS/ICT, ale pro detailní zpracování metodického vzoru bylo třeba řešení záměrně zúžit, aby bylo možné jít do potřebných detailů. 1.8 Přínosy disertační práce Přínosy práce pro teorii v práci jsou charakterizovány zvláštnosti software jako základní části informačního systému a popsány různé pohledy na procesy probíhající při budování informačního systému (podkapitola 2.3 Specifika budování IS/ICT), v práci jsou analyzovány současné metodiky budování IS/ICT (kapitola 3 Rigorózní a agilní metodiky a kapitola 4 Zdroje pro návrh metodického rámce), v práci je definována vícekriteriální kategorizace existujících metodik a struktura metapopisu metodik (podkapitola 2.4 Kategorizace metodik 2.5 Metapopis metodiky), v práci je navržen nový (v takovém pojetí nepublikovaný) metodický rámec (kapitola 5 Metodický rámec IS/ICT MEFIS a 6 Úroveň metametodiky metodického rámce, který zahrnuje: o definici charakteristik metodického rámce (podkapitola 5.3 Charakteristiky metodického rámce MEFIS), o návrh architektury metodického rámce (podkapitola 5.5 Architektura MEFIS), o metamodel metodického rámce (podkapitola 5.9 Metamodel metodického rámce MEFIS), o klasifikaci metodických vzorů pro různé domény, typy řešení, způsoby řešení a různé projekty (podkapitola 5.4 Klasifikace metodických vzorů), o principy a procesy pro vytvoření metodiky pro konkrétní projekt na základě vybraného vzoru (podkapitola 6.1 Metaprincipy MEFIS a 6.2 Metaprocesy MEFIS), 25 z českých metodik mohu uvést například metodiky Objektově orientované metodiky a technologie (OOMT) viz [Drbal,1997], Multidimensional Management and Development of Information System (MMDIS) viz podkapitola 4.1, Business Object Relation Modeling (BORM) viz [Polák,Merunka,Carda] 26 Obecně existuje u vývojářů spíše odpor k metodikám a dodržování přesných postupů. Tento odpor je o to větší, pokud jsou postupy anglicky. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 17

18 o naplnění metodického rámce je dokumentováno na příkladě metodického vzoru Nový objektově orientovaný vývoj obecného software vlastními silami (podkapitola 5.8 Metodický vzor Nový objektově orientovaný vývoj obecného software vlastními silami). Přínosy práce pro praxi metodický rámec mohou využít firmy, které dodávají nebo vlastními silami vytvářejí informační systém ve smyslu výběru adekvátního postupu, metodický rámec může být využit při standardizaci v rámci Informačního systému státní správy (ISVS), metodický rámec může být základem pro budování znalostní báze metodik v českém jazyce, přizpůsobených podmínkám budování IS/ICT v České republice a jednotně klasifikovaných, návrh metodického rámce lze využít pro vytvoření aplikace na údržbu, prezentaci a výběr metodických vzorů, metodické vzory je možné použít pro výuku v kurzech softwarového inženýrství. 1.9 Typografické konvence V textu disertační práce se často vyskytují odkazy na různé metodiky a jejich části 27. Protože se jedná o názvy, jsou uváděny s velkým písmenem a kurzívou, aby byly dobře odlišitelné od ostatního textu. Stejně tak jsou kurzívou označeny odkazy na části této práce jména kapitol, podkapitol a podobně. 27 jako například fáze, dimenze, procesy a podobně. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 18

19 2 Současný stav metodik budování IS/ICT Smyslem této kapitoly je definovat místo budování IS/ICT v rámci podnikové informatiky (podkapitola 2.1 Součásti podnikové informatiky), charakterizovat současný stav v oblasti metodik budování IS/ICT a faktory, které jej ovlivňují. Tyto faktory charakterizuji v podkapitole 2.2 Faktory ovlivňující metodiky budování IS/ICT. Mnohé rysy metodik a problémy s jejich aplikací jsou dány zvláštnostmi vývoje software. Snažím se proto tyto zvláštnosti charakterizovat (podkapitola 2.3 Specifika budování IS/ICT) a položit tak základ pro jejich zohlednění v návrhu metodického rámce. Pro snazší orientaci, popis a výběr metodiky je třeba metodiky kategorizovat. Protože jsem ve zdrojích, které jsem analyzovala, nenalezla vhodnou kategorizaci, definovala jsem kategorizaci vlastní. Tato kategorizace je popsána v podkapitole 2.4 Kategorizace metodik. a na jejím základě jsem navrhla strukturu metapopisu metodiky. 2.1 Součásti podnikové informatiky Oblast budování IS/ICT, kterou se zabývám ve své disertační práci, můžeme chápat jako součást podnikové informatiky. Termín podniková informatika můžeme vymezit jako systém informačních a komunikačních technologií, dat a lidí, jehož cílem je efektivní podpora informačních a rozhodovacích procesů a procesů správy a využívání znalostí na všech úrovních řízení podniku [Vodáček,Rosický,1997]. Podniková informatika představuje souhrn zdrojů, procesů a služeb IS/ICT, což můžeme vyjádřit obrázkem 2.1. obrázek 2.1: Součásti podnikové informatiky zdroj [Novotný,2003] Pro správnou funkci podnikové informatiky musí být k dispozici určité zdroje, mezi které můžeme zařadit zejména technologickou infrastrukturu (hardware, počítačová síť, základní software), aplikační software, data, spotřební materiál a obslužný personál a další. Díváme-li se na podnikovou informatiku z procesního pohledu, můžeme vymezit procesy informatiky. Procesem, ve smyslu podnikového procesu, se rozumí řízená posloupnost činností, spojená definovaným účelem, s cílem vyprodukovat definovaný výstup (produkt, službu) [KIT,2003]. Procesy informatiky jsou procesy, které jsou spojeny s IS/ICT jako například analýza a návrh, řízení konfigurací", řízení projektů" apod. Služby informatiky představují definované rozhraní, které propojuje procesy informatiky ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 19

20 s podnikovými procesy [Novotný,2003]. Podíváme-li se na vnitřní strukturu procesů informatiky, můžeme definovat základní druhy procesů například tak, jak ukazuje obrázek 2.2. obrázek 2.2: Hrubý procesní model informatiky zdroj [Novotný,2003] Na obrázku 2.2 jsou zachyceny procesy informatiky v členění na hlavní, podpůrné a řídící procesy. V rámci těchto typů procesů můžeme definovat skupiny procesů a typové procesy (zkráceno dle [Novotný,2003]): hlavní procesy procesy, jejichž prostřednictvím se poskytují služby podnikové informatiky, podpůrné procesy poskytují podporu pro procesy hlavní (pro jednotlivé služby) i pro procesy řídící: podpora uživatelů například správa požadavků, podpora uživatelů(help desk), podpora provozu například konfigurační řízení, poskytování zdrojů, provoz infrastruktury, řešení problémů a incidentů, podpora rozvoje vývoj aplikačního programového vybavení, akvizice, změnové řízení, podpora prostředí metodika, měření, audit, dokumentace, jakost, školení, bezpečnost, ekonomika. řídící procesy strategické řízení informatiky, řízení zdrojů, řízení procesů informatiky, řízení služeb, řízení bezpečnosti, řízení rizik, řízení jakosti, řízení dostupnosti atd. V kontextu výše uvedeného členění procesů informatiky se v rámci své disertační práce zaměřuji pouze na část těchto procesů. Jde zejména o procesy, které jsou označeny na obrázku 2.2 jako podpora rozvoje, které ale souvisejí i s dalšími procesy v oblasti podpory provozu, uživatelů i prostředí a samozřejmě s procesy řídícími. 2.2 Faktory ovlivňující metodiky budování IS/ICT Chceme-li pochopit význam a úlohu metodik budování informačních systémů, je třeba se podívat na současný stav jak v oblasti IS/ICT, tak v celé společnosti. Nacházíme se na prahu nové doby, kterou velice pěkně charakterizoval Rowan Gibson v knize Nový obraz budoucnosti: Kdysi v šedesátých a počátkem sedmdesátých let si byli lidé všeobecně jisti tím, kam máme namířeno a jak se tam dostaneme. Úspěšné korporace, silné poválečné ekonomiky a dávno zavedené instituce se řítily směrem k budoucnosti jako velké luxusní limuzíny na ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 20

21 široké a prázdné dálnici. Měly dojem, že před sebou vidí dlouhou přímou silnici, táhnoucí se ke vzdálenému obzoru, silnici, po níž mohou cestovat prakticky stejně jako po té, kterou nechaly za sebou. Když se dnes díváme do budoucnosti, ani trochu si nejsme jisti tím, kam máme vlastně namířeno a jak se tam dostaneme. Konec dvacátého století představuje konec celého určitého řádu věcí, konec průmyslového paradigmatu. Vidíme před sebou svět plný chaosu a nejistoty, svět stále rychlejších změn, svět, kde základem ekonomiky nebude půda, peníze ani suroviny, ale intelektuální kapitál. Abychom se mohli po tomto světě pohybovat nemůžeme mít luxusní limuzínu, ale jiné vozidlo s jiným stylem řízení něco jako džíp, s pohonem na čtyři kola, které dokáže rychle měnit směr jízdy, pohybovat se v neznámém prostředí. Ale také potřebujeme mít jasný cíl cesty vizi, kam se chceme dostat [Gibson]. Tato výstižná charakteristika doby, v níž žijeme, nám ukazuje faktory, které ovlivňují fungování podniků i jiných organizací a zprostředkovaně ovlivňují i IS/ICT. Turbulentní změny prostředí, globalizace ekonomiky, rostoucí konkurence představují vnější vlivy. Organizace mění ale i způsob řízení, direktivní řízení je nahrazováno vůdcovstvím, prosazují se procesní přístupy, klíčovou roli začíná hrát řízení znalostí a řízení změn. obrázek 2.3:Faktory ovlivňující metodiky budování IS/ICT Všechny tyto faktory nutně ovlivňují informační systém. K nim se připojuje velmi rychlý vývoj informačních a komunikačních technologií, který vyžaduje specializaci vývojářů, neustálé učení, týmovou práci, častý upgrade software. Budování dnešních IS/ICT je ovlivněno i úrovní stávajícího informačního systému. Informační systémy dnes nevznikají na zelené louce, ale musí integrovat stávající systémy v rámci podniku, ale i systémy mezi podniky. Tyto úvahy jsou názorně zachyceny na obrázku 2.3. Obrázek zachycuje oblasti, které ovlivňují metodiky budování IS/ICT. Klíčovou oblastí je oblast označená na obrázku 2.3 jako IS/ICT, která je ovšem velmi úzce spojena s podnikovými procesy, neboť smyslem informačních systémů je právě podpora podnikových procesů. Současný stav IS/ICT a navrhovaný budoucí stav IS/ICT potom mají vliv na procesy budování IS/ICT 28. Jedná se o skutečné procesy, které v organizaci probíhají. Popisem těchto procesů se zabývají metodiky budování IS/ICT. Metodiky jsou ovlivněny jednak faktory, které působí ve všech výše zmíněných oblastech, jednak dalšími oblastmi, kterými je řízení a řídící procesy, informační a komunikační technologie a samozřejmě ekonomické prostředí, které působí na všechny oblasti zachycené na obrázku jsou chápány jako podmnožina procesů informatiky viz 2.1 ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 21

22 2.3 Specifika budování IS/ICT V této podkapitole se pokusím zamyslet nad faktory, které ovlivňují procesy budování IS/ICT. Je třeba poznamenat, že většina metodik v oblasti IS/ICT i většina odborné literatury se zaměřuje na vývoj nového informačního systému. Přitom v dnešní době je hlavním úkolem zejména rozvoj stávajících systémů, implementace typových programových řešení, integrace dílčích řešení do celopodnikového systému. Touto oblastí se většinou metodiky nezabývají, i když se v poslední době začínají objevovat články a publikace na toto téma. Ať jde tedy o nový vývoj, rozvoj, implementaci typového řešení, cílem a výsledkem je vždy implementované programové vybavení software. V této podkapitole se zaměřím právě na software a jeho zváštnosti jako produktu i zvláštnosti jeho vývoje (software development) 29. Vývoj software nemá ve srovnání s ostatními odvětvími dlouhou historii. Na celou historii vývoje software můžeme pohlížet jako na boj se složitostí. Na jedné straně se do tohoto boje nasazují stále výkonnější nástroje 30, na druhé straně však stále rostou požadavky na software 31. Složitost vývoje software je tedy stále jeho hlavním atributem a také jednou z příčin velkého počtu neúspěšných softwarových projektů. V následujících odstavcích se pokusím zamyslet nad některými zvláštnostmi vývoje software, které by měly metodiky budování IS/ICT akcentovat Složitost vývoje software Složitost vývoje software (software development) je ovlivněna jak prostředím vývoje, tak cílovým prostředím. Proměnnými veličinami při vývoji software jsou dle [Scrum2]: dostupnost kvalifikovaných specialistů (pro nové technologie, nástroje, metody a domény je malý počet kvalifikovaných odborníků), stabilita technologie pro implementaci (nové technologie jsou méně stabilní), stabilita a schopnosti nástrojů, efektivnost používaných metod, dostupnost expertů na věcnou oblast i technologii, nová funkcionalita a její vztah k existující funkcionalitě, metodika a její flexibilita, konkurence, čas, zdroje, další proměnné. Celková složitost vývoje software je funkcí těchto proměnných, přičemž tyto proměnné se v průběhu projektu mění: složitost = f(proměnné prostředí vývoje + proměnné cílového prostředí) Roste-li složitost projektu, je třeba zařazovat do procesu více kontrolních prvků, řídit rizika apod Procesy vývoje software jsou empirické procesy Software má mnoho aspektů, které jej odlišují od jiných produktů, a proto je i proces jeho vývoje odlišný. Již několik desetiletí se potýkáme s tzv. softwarovou krizí, kterou slibují řešit různé přístupy. Ty se zaměřují na 29 účelově zúžím v této podkapitole svou pozornost pouze na vývoj nového řešení. 30 dnes máme k dispozici programovací jazyky třetí i čtvrté generace, vizuální vývojová prostředí, knihovny tříd, komponent, aplikační rámce pro určité třídy úloh, generátory aplikací či průvodce na tvorbu aplikací 31 rozsah, kvalita, rychlost vývoje, flexibilita, přívětivost a další ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 22

23 zlepšování procesů při vývoji software, slibují významné zlepšení produktivity, ale zpravidla jej nedosahují, protože předpokládají, že procesy při vývoji software je možné plně definovat a konzistentně opakovat, což předpokládá definovatelnost a opakovatelnost: problému, řešení, nositelů řešení vývojářů, prostředí. Tyto předpoklady však dle [Scrum2] a zastánců agilních přístupů při vývoji software neplatí. V mnoha případech není možné definovat problém na začátku projektu, protože požadavky na aplikaci nejsou přesně specifikovány a nebo se mění. Opakovatelnost řešení předpokládá, že je možné plně specifikovat architekturu a návrh. Také vývojáři nejsou stejní, ale liší se svými schopnostmi a znalostmi. Liší se i prostředí, ve kterém vývoj probíhá. Vývoj software tak probíhá v podmínkách chaosu a je to velmi složitý proces. Nelze jej tedy předem plně popsat, ale je nutné jej průběžně monitorovat a přizpůsobovat se změnám. Vývoj software tedy není definovaný proces, ale proces empirický Vývoj software jako kooperativní hra Tradiční rigorózní přístupy pohlížejí na vývoj software jako na inženýrskou disciplínu. Alistair Cockburn [Cockburn,CGM] pohlíží na vývoj software jako na kooperativní hru s omezenými zdroji založenou na invenci a komunikaci. Jako příklad kooperativní hry uvádí tým horolezců. Jejich hra má jasný cíl, je kooperativní a konečná. Podobně je to i s vývojem software. Vývoj software má primární cíl dodat software, který splňuje požadavky uživatelů. Sekundárním cílem je připravit se pro další hru. Další hrou je rozvoj systému nebo vývoj nového systému. Pokud neuspějeme v primárním cíli, je sekundární cíl bezpředmětný. Z toho pohledu nemá smysl dodávat perfektní dokumentaci, když nedodáme fungující software. Na druhé straně úspěšné splnění primárního cíle nemusí znamenat úspěch v sekundárním cíli, což ovlivňuje úspěch v dalších hrách. Uvažujeme-li tedy o vývoji software jako kooperativní hře, musíme řešit otázku, kolik z omezených zdrojů (lidí, času a peněz) použít. Snažíme se podporovat invenci a komunikaci a tak dosáhnout stejného efektu s menšími zdroji. Je třeba vážit užitečnost každé práce a tak dospějeme k myšlence, že model nemusí být kompletní nebo aktuální, aby byl dostatečně užitečný. To vysvětluje skutečnost, že mnohé projekty končí úspěšně, i když nemají kompletní dokumenty a přesné procesy. Uspěly proto, že lidé se správně rozhodli ukončit práci na určitém dokumentu v okamžiku, kdy dosáhli jeho dostatečnosti a dříve než začala klesat jeho návratnost. Dokumenty návrhu nemusí podle Cockburna nutně perfektně odpovídat kódu, plán projektu nemusí přesně odpovídat stavu projektu, důležitý je především fungující systém odpovídající požadavkům zákazníků Software jako metaprodukt Velmi zajímavou charakteristiku software uvedl Clemens Szyperski, významný odborník v oblasti komponentového vývoje, ve svém článku pro LogOn Experts Corner [Szyperski,11/2002]: Software se liší od jiných produktů díky svým netechnickým aspektům. Dodávka software je spíše než dodávkou finálního produktu dodávkou plánu pro produkt. Na počítače se můžeme dívat jako na plně automatizované továrny, které přijímají tyto plány a vytvářejí z nich instance. V tomto smyslu je software metaprodukt. Stejně tak je to i s komponentami. Je tedy velmi důležité rozlišovat mezi software a jeho instancemi podobně jako je třeba rozlišovat mezi nákresem a produktem nebo mezi geny a živým tvorem. Zatímco toto rozlišení je jasně dáno v jiných disciplínách, software se zdá být dost soft, aby tyto rozdíly toleroval. Plány mohou být parametrizovány, rekurzivně aplikovány, škálovány, opakovaně instanciovány. Nic z toho není možné provést s instancemi. Jinými slovy software je generický metaprodukt, který může být použit pro vytvoření celé rodiny instancí. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 23

24 2.4 Kategorizace metodik Hlavní problém, se kterým se při zkoumání metodik budování IS/ICT setkáme, spočívá v tom, že těchto metodik je velké množství, nejsou dobře kategorizovány ani jednotným způsobem popsány. Tato skutečnost velmi znesnadňuje vyhledání vhodné metodiky pro určitý typ projektu. Proto jsem se nejprve pokusila identifikovat objektivní příčiny existence různých metodik a na základě těchto skutečností navrhnout kategorizaci metodik budování IS/ICT. Identifikovala jsem následující objektivní příčiny existence různých metodik, které jsem popsala v [Buchalcevová,2003]: různé technologie vyžadují různé techniky a metody, Objektově orientované metodiky vyhovují projektům, které využívají objektově orientované technologie, datově orientované metodiky vyhovují datově orientovaným aplikacím a tak podobně. organizace se liší firemní kulturou, Mnohé implementace metodik selhávají, protože nepočítají s firemní kulturou. Firemní kultura může být s některými přístupy v rozporu, jiné může naopak podporovat. Při implementaci metodiky v organizaci je třeba analyzovat její firemní kulturu. každý jedinec je jedinečný, Primárním faktorem při vývoji informačního systému jsou lidé. Metodiky však tuto skutečnost dostatečně nezohledňují. Lidé nejsou zaměnitelné součástky, každý má jiné znalostní zázemí, jiným způsobem dosahuje cíle. Proto není možné vytvořit jedinou metodiku vhodnou pro všechny, ale je třeba ji přizpůsobit konkrétním lidem, jejich znalostem a schopnostem. každý tým je jedinečný, Jedinečnost jedinců nutně vede k jedinečnosti týmů. projekty se liší velikostí týmu, Pro relativně malý počet lidí stačí relativně malá metodika. projekty se liší svou důležitostí, Vytváření systému pro řízení letového provozu vyžaduje jinou metodiku než mzdová agenda a také metriky úspěchu těchto dvou projektů jsou odlišné. Možných klasifikací systémů z hlediska důležitosti je více. Jedna z možných je uvedena v podkapitole projekty se liší podle postavení produktu na trhu, Pro produkt vstupující na trh se zpravidla nepoužívá žádná metodika a nebo jen velmi lehká metodika. Naproti tomu pro produkt zavedený na trhu je možné aplikovat rigorózní metodiku 32 s přesně popsanými procesy. Produkt, který představuje konkurenční výhodu pro organizaci, je třeba vyvinout rychle a uplatní se zpravidla agilní metodiky 33. projekt existuje v rámci určitého specifického vnějšího prostředí. Některé projekty musí odpovídat pravidlům pro státní zakázky, některé projekty jsou vázány na dodavatele a jeho požadavky, mají přesně stanovený rozpočet, čas apod. Výše uvedené skutečnosti vedou k nutnosti existence různých metodik budování IS/ICT. Metodiky se liší podle toho, jakou část životního cyklu postihují, jak přesně a jakým způsobem definují jednotlivé kroky při budování informačního systému. V rámci disertační práce jsem definovala vícekriteriální kategorizaci metodik budování IS/ICT. 32 Rigorózní metodiky jsou definovány v kapitole Agilní metodiky jsou definovány v kapitole 3. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 24

25 Tato kategorizace je založena na 6 kritérích: 1. Zaměření metodiky 2. Rozsah metodiky 3. Váha metodiky 4. Typ řešení 5. Doména 6. Přístup k řešení Základním kritériem, které ovlivňuje působnost dalších kritérií je kritérium Zaměření metodiky, které je popsáno v následující podkapitole Kritérium Zaměření metodiky Za základní kritérium rozlišení metodik budování IS/ICT považuji skutečnost, zda je metodika zaměřena na budování IS/ICT celé organizace a nebo jen na jednotlivý projekt. Na základě tohoto kritéria jsem navrhla dvě kategorie metodik globální metodiky a projektové metodiky, které uvádí tabulka 2.1. Kritérium Zaměření metodiky kód EM PM význam globální metodiky (Enterprise Methodologies) metodiky zaměřené na vývoj, provoz i řízení celopodnikového IS/ICT projektové metodiky metodiky pro vývoj respektive zavedení informačního systému v určité oblasti tabulka 2.1: Kritérium Zaměření metodiky Většina publikovaných metodik patří do kategorie projektových metodik. Jsou to metodiky, které se zaměřují na vývoj, rozvoj či zavedení software v rámci jednoho projektu, pro určitý subsystém. V poslední době roste význam integrace aplikací (Enterprise Application Integration, EAI) s důrazem na globální architekturu. S tím roste i význam globálních metodik. Do kategorie globálních metodik můžeme zařadit i metodiku MMDIS, která je od začátku 90 let rozvíjena na Katedře informačních technologií VŠE v Praze a kterou blíže charakterizuji v podkapitole 4.1. Globální metodikou je i Model zralosti (CMM) charakterizovaný v podkapitole V oblasti globálních metodik se také významně angažuje organizace OMG, která v roce 2001 přišla se svou strategickou iniciativou Model Driven Architecture (MDA), kterou analyzuji v kapitole Působnost aplikace dalších kritérií vychází z rozdělení metodik dle kritéria Zaměření metodiky. Některá kritéria lze aplikovat jak na globální metodiky, tak na projektové metodiky (kritérium Rozsah metodiky, kritérium Váha metodiky). Ostatní kritéria se aplikují v rámci kategorie projektových metodik respektive té části globální metodiky, která odpovídá projektovému řešení (obrázek 2.4) Kritérium Rozsah metodiky Rozsahem metodiky se zpravidla chápe počet fází životního cyklu informačního systému, které metodika pokrývá. Pro potřeby kategorizace metodik budování IS/ICT definuji rozsah metodiky budování IS/ICT jako průnik tří hledisek, kterými jsou: fáze životního cyklu, role, dimenze. Vyšla jsem přitom z pojetí Cockburna [Cockburn,MetSpace], podle kterého určují rozsah metodiky tři hlediska - fáze životního cyklu, role na projektu a činnosti. Vzhledem k tomu, že za významnější než činnosti považuji pohled na vyvíjený systém z různých dimenzí tak, jak jsou chápány v metodice MMDIS (blíže viz 4.1), nahradila ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 25

26 jsem hledisko činností dimenzemi. Myslím si totiž, že explicitní zaměření na dimenze je velmi důležitým rysem metodiky a řada metodik pokrývá jen několik málo dimenzí. obrázek 2.4: Působnost kritérií kategorizace metodik Fáze životního cyklu určují, kde v rámci životního cyklu metodika začíná a kde končí. Pro kategorizaci metodik jsem použila fáze životního cyklu převzaté z metodiky MMDIS [Voříšek,1997] (tabulka 2.2). Některé metodiky pokrývají oblasti od počátečního obchodního rozhovoru až po údržbu. Většina komerčně publikovaných metodik vývoje software se zabývá většinou jen fázemi detailní analýzy, návrhu a implementace. Budování IS/ICT je složitý proces, který vyžaduje spolupráci celé řady specialistů. Proto definují metodiky role jako typové skupiny pracovníků. Podle toho, na které role je metodika zaměřena, můžeme metodiky rozlišit. Příklad rolí definovaných pro metodický vzor M02 Nový objektově orientovaný vývoj obecného software vlastními silami je uveden v příloze 7. Fáze životního cyklu zkratka název fáze GST globální strategie IST informační strategie UST úvodní studie GAN globální analýza a návrh DAN detailní analýza a návrh IMP implementace ZAV zavádění PUR provoz a údržba tabulka 2.2: Fáze životního cyklu Některé metodiky se zabývají pouze jednou či několika málo dimenzemi. Vývoj software má však celou řadu aspektů a je tedy účelné na něj pohlížet z různých dimenzí. S dimenzemi pracuje explicitně metodika MMDIS, která rozlišuje obsahové dimenze a dimenze, které se aplikují na metodiku samotnou rozdělení do fází, dokumentační dimenze, metodická apod. Při specifikaci kritéria rozsahu metodiky uvažuji jen dimenze vyvíjeného systému. Přehled dimenzí uvádí tabulka 2.3. Oproti dimenzím definovaným v MMDIS [Voříšek,1997], jsou dimenze částečně upraveny. Bližší vysvětlení obsahu jednotlivých dimenzí je uvedeno v podkapitole 4.1 MMDIS. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 26

27 Dimenze vyvíjeného systému dimenze zkratka význam hardware HW typy, parametry a počty počítačů, periferních zařízení, komunikačních sítí a dalších technických prostředků technologie TECH platforma (operační systém), architektura programového systému, SŘBD, technologie middleware apod. data/informace DATA obsah a struktura datové základny a její fyzické uložení funkce/procesy FUN procesy probíhající v podniku a možnost jejich podpory informačním systémem, funkce informačního systému uživatelské rozhraní UI uživatelské rozhraní systému pracovní PRA potřebná struktura pracovníků organizační/legislativní ORG specifikace zákonů, norem a směrnic, které musí být při tvorbě IS/ICT respektovány ekonomická EKO zahrnuje finanční náklady tvorby a provozu IS/ICT a přínosy podniku z užití IS/ICT, zdroje tabulka 2.3: Specifikace dimenzí pro kritérium Rozsah metodiky Kritérium Rozsah metodiky lze aplikovat jak na globální metodiky, tak na projektové metodiky. Rozsah globální metodiky znázorňuje obrázek 2.5, rozsah metodiky projektu obrázek 2.6 metodika projektu Kritérium Váha metodiky obrázek 2.5: Rozsah globální metodiky V poslední době se můžeme setkat s rozlišováním metodik na lehké metodiky a těžké metodiky. Již toto označení nás přivádí k pojmu váha metodiky. Při vymezení pojmu váha metodiky vycházím z definice Cockburna [Cockburn,MetSpace], [Cockburn,MetPerProj], který zavádí charakteristiky metodiky, které označuje zkratkou PARTS precision, accuracy, relevance, tolerance, scale. Význam těchto charakteristik vysvětluje tabulka 2.4. Od charakteristik, které uvádí tabulka 2.4, jsou potom odvozeny pojmy velikost, hustota a váha metodiky. Velikost metodiky (methodology size) vyjadřuje počet kontrolních prvků obsažených v metodice. Hustota metodiky (methodology specific density) vyjadřuje míru podrobnosti a těsnost tolerance metodiky a požadovanou detailnost a konzistenci prvků. Váha metodiky (methodology weight) je potom součin velikosti metodiky a hustoty metodiky.[cockburn,metspace] Velikost metodiky závisí na velikosti týmu. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 27

28 obrázek 2.6: Rozsah metodiky projektu Charakteristiky metodiky charakteristika angl. ekvivalent význam podrobnost precision vyjadřuje, do jaké podrobnosti (hloubky) se metodika daným tématem zabývá přesnost accuracy vyjadřuje, jak přesně je dané téma zpracováno relevance relevance určuje, zda se metodika zabývá určitým tématem tolerance tolerance jak mnoho odchylek povolit měřítko scale definuje míru zaostření (můžeme sbalit několik položek tak, že tvoří jedinou položku) tabulka 2.4: Charakteristiky metodiky Pro relativně malý počet lidí stačí relativně malá metodika. S lehčí metodikou pracují lidé produktivněji, a tak mohou obsáhnout větší problém. Jestliže je na druhé straně do projektu zapojeno více lidí, potřebují větší koordinaci a tedy i větší (těžší) metodiku. Rozvoj metodik vedl ke vzniku velmi propracovaných metodik s přesně definovanými procesy, činnostmi a artefakty. Tyto metodiky se označují jako rigorózní nebo těžké metodiky a blíže jsou charakterizovány v podkapitole 3.1. V poslední době se začínají prosazovat lehké metodiky, které definují spíše principy a praktiky než podrobné procesy. Tyto metodiky jsou označovány jako agilní a jsou charakterizovány v podkapitole Kritérium Typ řešení Při realizaci informačního systému se nevyvíjí vždy nový software, ale často se implementuje typový aplikační software 34. Je zřejmé, že metodika implementace typového aplikačního software se liší od metodiky vývoje nového software. Ale i při vývoji software existují odlišnosti. Vývoj software dnes neprobíhá zpravidla od začátku, ale často se rozšiřuje stávající řešení a nebo se provádí integrace řešení. V dnešní době se některé části IS/ICT zajišťují také formou Application Service Provision 35 či jiné formy outsourcingu 36. Z toho důvodu je přidána 34 Příkladem typového aplikačního software je například SAP R3, BAAN, SIEBEL a další. 35 Application Service Provision, poskytování aplikačních služeb. Jedna z forem outsourcingu. Specializovaná firma (Application Service Provider) na vlastní informační a komunikační technologii provozuje služby, které nabízí k použití externím zákazníkům. Zákazník je k aplikaci obvykle připojen přes Internet [KIT,2003]. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 28

29 hodnota užití řešení. Pokud se zabýváme globální metodikou, jejímž cílem je vybudování integrovaného celopodnikového IS/ICT, jedná se o integraci řešení. Navržené hodnoty kritéria Typ řešení uvádí tabulka 2.5. Kritérium Typ řešení kód význam NEW vývoj nového řešení ( na zelené louce) INT integrace řešení UPG rozvoj a rozšíření řešení (upgrade) TYP customizace a implementace typového řešení USE užití řešení tabulka 2.5: Kritérium Typ řešení Kritérium Doména Kritérium Doména se aplikuje na projektové metodiky. Metodika pro vytvoření datového skladu a nebo vybudování workflow je jiná než vývoj klasické aplikace. Proto jsem jako další kritérium kategorizace metodik budování IS/ICT navrhla kritérium Doména. Doména představuje určitou předmětnou oblast, respektive určitou skupinu podnikových procesů, na jejichž podporu je informační systém vytvářen. Při specifikaci domén vycházím z aplikační architektury IS/ICT, jejíž zobecněné schéma uvádí obrázek 2.7. Obecné schéma architektury IS/ICT znázorňuje jednotlivé části informačního systému. V současné době se IS/ICT soustřeďuje kromě podpory procesů v organizaci zejména na řízení externích vztahů se zákazníky, dodavateli a dalšími partnery. Řízení vztahů se zákazníky, tzv. CRM (Customer Relationship Management), zahrnuje technickou a softwarovou podporu kontaktních center pro zákazníky, elektronickou podporu prodeje, podporu marketingu apod. Řízení dodavatelských řetězců SCM (Supply Chain Management) se zabývá řízením celého řetězce dodávky od dodavatele prvotních produktů a surovin přes celou řadu výrobních a obchodních mezičlánků až po dodávku konečnému zákazníkovi a má úzkou vazbu na aplikace progresivních plánovacích procedur APS (Advanced Planning and Scheduling). Elektronické obchodování (e_commerce) představuje podporu provádění obchodní transakce (nebo její části) prostředky IS/ICT (typicky i Internetem) a příslušnými aplikačními programy (ASW) [KIT,2003]. Jádrem informačního systému jsou dnes již v jistém smyslu klasické integrované aplikační systémy ERP (Enterprise Resource Planning), které pokrývají všechny nebo většinu oblastí podnikového řízení. Podporu všech základních řídících a administrativních operací podniku zajišťuje software pro interní infrastrukturu podniku kancelářské systémy, aplikace pro řízení pracovních toků (workflow), aplikace a technologie pro správu dokumentů (Content management) a také elektronické vzdělávání (e learning). Na nejvyšším místě je ve schématu umístěn blok tzv. business intelligence, který představuje komplex aplikací podporující analytické a rozhodovací aktivity vedoucích pracovníků podniku manažerské aplikace, aplikace datových skladů a datových tržišť, dolování dat. Na základě aplikační architektury IS/ICT (obrázek 2.7) a analýzy řady publikací, které se zabývají různými typy informačních systémů 37, jsem odvodila domény, tedy problémové oblasti, které mají specifické rysy ovlivňující procesy při budování informačního systému v dané oblasti. Tyto domény uvádí tabulka 2.6 a obrázek 2.8 znázorňuje dle jejich umístění vztah k architektuře IS/ICT. 36 Strategický organizační nástroj. Přesun odpovědnosti za oblast činností podniku na externí specializovanou firmu - poskytovatele; zpravidla včetně zaměstnanců a vlastnictví aktiv; především za účelem zaměření na hlavní činnost, dosažení náležité úrovně kvality v oblasti, případně úspory nákladů [KIT,2003]. 37 například [Basl,2002], [Dohnal,2002], [Dohnal,Pour,1997] ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 29

30 Vlastníci, management IS/IT firmy Dodavatelé, obchodní partneři Business Intelligence, manažerské aplikace e_business e_business SCM/APS SCM/APS ERP Prodej, nákup, sklady, výroba Finance, Controlliing,.. Zdroje (personál, majetek), CRM CRM e_business e_business Zákazníci - ek. subjekty, koncoví zákazníci Interní Interní infrastruktura infrastruktura Obchodníci, referenti, obchodní zástupci, kontaktní centrum obrázek 2.7 : Aplikační architektura IS/ICT firmy zdroj [Dohnal,Pour,1997] obrázek 2.8: Domény IS/ICT Kromě jednotlivých aplikačních domén je připojena ještě doména, EAI Integrace podnikových aplikací, která akcentuje integrační hledisko a zaměřuje se na vytvoření integrovaného celopodnikového systému. Protože jsou domény definovány pro potřeby kategorizace metodik, je připojena ještě doména obecný software, která zahrnuje blíže nespecifikovanou problémovou oblast. Kritérium Doména kód název význam BIN Business Intelligence datové sklady, analýzy dat, dolování dat CRM Customer Relationship Management řízení vztahů se zákazníky CSW obecný software tato doména zahrnuje software, u kterého nemá smysl zabývat se specifickými rysy ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 30

31 Kritérium Doména CTM Content Management řízení obsahu EAI Enterprise Application Integration integrace podnikových aplikací ECO e commerce elektronické obchodování ELE e learning elektronické vzdělávání ERP Enterprise Resource Planning ERP systémy OIS Office Information System kancelářské systémy SCM Supply Chain Management řízení dodavatelských řetězců WKF wokflow automatizace podnikových procesů, oběh dokumentů tabulka 2.6: Kritérium Doména Kritérium Přístup k řešení Kritérium Přístup k řešení má smysl aplikovat jen v rámci projektových metodik 38, a to zejméná pro řešení typu nový vývoj respektive rozšíření řešení. Toto kritérium zohledňuje základní paradigma, na kterém je metodika založena. V současnosti se můžeme setkat s těmito hlavními přístupy k vývoji software: strukturovaný vývoj, rychlý vývoj aplikací (Rapid Application Development, RAD), objektově orientovaný vývoj (zahrnuje i komponentový vývoj). Určitý přístup může být aplikován buď ve všech hlavních vývojových fázích analýza, návrh, implementace a nebo je možné přístupy v jednotlivých fázích kombinovat. Běžně se například používá objektová analýza a RAD návrh a implementace. Na základě kombinací přístupů, které se nejčastěji v praxi používají, jsem nadefinovala hodnoty kritéria Přístup k řešení uvedené v tabulce 2.7. Kritérium Přístup k řešení kód ST RS RO OO OR význam strukturovaný vývoj vývoj založený na strukturované analýze, strukturovaném návrhu a strukturované implementaci RAD vývoj se strukturovanou analýzou analýza probíhá strukturovaně, návrh a implementace se provádí pomocí RAD nástrojů RAD vývoj s objektovou analýzou analýza se provádí objektově, ale návrh a implementace je pomocí RAD nástrojů objektový vývoj ve všech fázích provádí se objektově orientovaná analýza, objektově orientovaný návrh i objektová implementace s persistentními objekty objektový vývoj s relační databází provádí se objektově orientovaná analýza, objektově orientovaný návrh i objektová implementace, ale data jsou uložena v relační databázi tabulka 2.7: Kritérium Přístup k řešení 2.5 Metapopis metodiky Na základě výše uvedených kritérií jsem navrhla strukturu popisu metodiky metainformace o metodice, která je uvedena v tabulce 2.8. Tato struktura je potom využita k popisu metodik analyzovaných v kapitole 3. Metapopisy těchto metodik jsou uvedeny v příloze respektive části globální metodiky, která odpovídá projektu ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 31

32 Struktura popisu metodiky položka ID metodiky Název metodiky Zkratka Autoři Rok vzniku Zaměření Rozsah Váha metodiky Typ řešení Doména Přístup k řešení Slovní charakteristika Poznámka význam, hodnoty číselníku EM PM fáze dimenze role LM MM HM NEW INT UPG TYP USE globální metodika projektová metodika vyjmenovat fáze, které pokrývá GST, IST, UST, GAN, DAN, IMP, ZAV, PUR vyjmenovat dimenze, které pokrývá HW, TECH, DAT, FUN, UI, PRA, ORG, EKO vyjmenovat role, které pokrývá lehká střední těžká určit doménu (např. CRM, ERP, BI,...) ST RS RO OO OR tabulka 2.8: Struktura popisu metodiky 2.6 Shrnutí kapitoly vývoj nového řešení (na zelené louce) integrace řešení rozvoj a rozšíření řešení (upgrade) implementace typového řešení užití řešení strukturovaný vývoj RAD vývoj se strukturovanou analýzou RAD vývoj s objektovou analýzou objektový vývoj ve všech fázích objektový vývoj s relační databází Kapitola charakterizuje současný stav v oblasti metodik budování IS/ICT a faktory, které tyto metodiky ovlivňují. V podkapitole 2.4 Kategorizace metodik jsou definovány objektivní příčiny existence různých metodik a kritéria pro kategorizaci existujících metodik budování IS/ICT. Na základě těchto kritérií je navržena struktura metapopisu metodiky, která je dále využita pro popis analyzovaných metodik. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 32

33 3 Rigorózní a agilní metodiky V současnosti můžeme sledovat dva hlavní proudy v metodických přístupech, které jsou označovány jako rigorózní metodiky a agilní metodiky. Hlavním kritériem, které tyto dva proudy odlišuje, je kritérium Váha metodiky (podkapitola Kritérium Váha metodiky), ale liší se i jinými hledisky, která jsou posuzována v podkapitole 3.3 Porovnání rigorózních a agilních metodik. V této kapitole jsou oba přístupy charakterizovány a nejvýznamnější metodiky obou skupin jsou popsány. Kromě stručné charakteristiky metodiky a popisu myšlenek, na kterých je založena, jsou všechny popisované metodiky doplněny metapopisem, jehož struktura byla navržena v podkapitole 2.5 Metapopis metodiky. V rámci metapopisu je definováno zařazení metodik do příslušných kategorií definovaných v podkapitole 2.4 Kategorizace metodik, a tak je možné metodiky zhodnotit a porovnat. 3.1 Rigorózní metodiky Rigorózní metodiky vycházejí z přesvědčení, že procesy při budování IS/ICT lze popsat, plánovat, řídit a měřit. Snaží se tedy podrobně a přesně definovat jednotlivé procesy, činnosti a vytvářené produkty, a tak bývají velmi objemné 39. Rigorózní metodiky jsou zpravidla založeny na sériovém (vodopádovém) vývoji, kdy jsou definovány detailní procedury, které mají vývojáři realizovat víceméně sekvenčně. Zpětnou vazbu je možné realizovat mezi fázemi prostřednictvím řízení změn. 40 Některé rigorózní metodiky jsou založeny na iterativním a inkrementálním vývoji 41. Obsahují tedy přesně definované procesy, které jsou však realizovány iterativním způsobem. Jako příklad rigorózních iterativních metodik lze uvést metodiky OPEN, Rational Unified Process (RUP), Enterprise Unified Process (EUP), které jsou charakterizovány v podkapitolách Metodika OPEN, Metodika Rational Unified Process, Metodika Enterprise Unified Process. V rámci rigorózních metodik tvoří samostatnou kategorii metodiky pro hodnocení softwarových procesů 42 (Software Process Assesment). Jsou realizovány zejména v rámci projektu SPICE, který představuje hlavní mezinárodní iniciativu pro podporu vývoje mezinárodního standardu pro hodnocení softwarových procesů. Výsledky projektu byly publikovány jako standard ISO/IEC TR 15504:1998 Software Process Assesment [SPICE]. Vznik tohoto standardu nebyl podnícen požadavky vývoje software, ale požadavky na akvizice softwarových firem. Pokračováním projektu SPICE je projekt OOSPICE (Software Process Improvement and Cabability Determination for Object Oriented/Component Based Software Development), který je financován z prostředků Evropské unie. Zaměřuje se na zlepšování softwarových procesů pro komponentový vývoj aplikací (Component Based Development, CBD). Metodiky hodnocení softwarových procesů jsou založeny na přesvědčení, že kvalita procesu určuje kvalitu produktu, a proto popisují postupy, které umožňují hodnotit úroveň zralosti těchto procesů. Nejznámější z těchto metodik je Model zralosti (Capability Maturity Model), který je charakterizován v podkapitole Capability Maturity Model for Software (SW-CMM) Capability Maturity Model for Software (SW-CMM) Nejznámějším příkladem hodnocení softwarových procesů 43 je Model zralosti SW (Capability Maturity Model for Software) označovaný zkratkou SW CMM. 39 mohou mít rozsah 500 až 800 stran 40 Příkladem je Capability Maturity Model (CMM). 41 Iterativní vývoj představuje opakované (iterativní) provádění jednotlivých fází při vývoji IS. Výsledkem každé iterace je funkční verze systému. Současné metodiky doporučují velmi krátké iterace (dny). Iterativní vývoj může probíhat buď pro celý systém, jehož funkčnost se v jednotlivých iteracích rozšiřuje, a nebo ve spojení s inkrementálním vývojem (systém se vyvíjí po přírůstcích). [KIT,2003] 42 Pojem softwarový proces je vymezen v pojem softwarový proces je vymezen v 1.5 a ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 33

34 Identifikace metodiky a zdrojů Model zralosti SW byl vyvinut za účelem hodnocení dodavatelů softwarových řešení pro ministerstvo obrany USA Institutem pro softwarové inženýrství (Software Engineering Institute SEI), který je součástí Carnegie Mellon University. V současné podobě a struktuře je dostupný od roku V souvislosti s SW CMM byly vytvořeny i další modely, zejména Systems Engineering Capability Model (SECM) a Integrated Product Development Capability Maturity Model (IPD CMM). Organizace, které zaváděly více modelů hodnocení procesů se dostávaly do problémů s jejich integrací. Proto byl vytvořen Integrační model zralosti (Capability Maturity Model Integration, CMMI), který spojuje a rozšiřuje výše uvedené modely a podporuje dva způsoby zlepšování průběžný a postupný. První verze CMMI modelu byla publikována v prosinci roku 2000, v současnosti je k dispozici verze 1.1 [CMMI]. Z hlediska zaměření disertační práce je předmětem mého zájmu zejména model SW CMMI. Tento model vychází z modelu SW CMM, zachovává všechny jeho principy a většinu klíčových oblastí procesů 44 a přidává některé nové oblasti procesů zejména na úrovni zralosti 3 a vyšších. Model CMMI je komplexní, je definován jak pro průběžné (continuos) zlepšování procesů, tak pro postupné (staged) zlepšování a jeho rozbor a popis by zabral mnoho stran. Navíc tento model je nový a organizace jej teprve začínají zavádět. Naproti tomu model SW CMM je zaveden v celé řadě firem, je pro něj k dispozici velké množství dokumentace a navazují na něj i další metodiky jako například PSP a TSP (viz podkapitola ) Proto podrobnější rozbor zaměřím na model SW CMM Definice základních pojmů V rámci metodik hodnocení softwarových procesů se používá určitá terminologie, kterou se snažím zachovávat i při popise těchto metodik. V této podkapitole jsou základní pojmy vysvětleny, vycházím přitom z [Paulk]. Softwarový proces můžeme definovat jako sadu činností, metod, praktik a transformací, které lidé používají pro vývoj a údržbu software a dalších s tím spojených produktů (projektových plánů, návrhů, testovacích případů apod.) 45. Jak organizace vyzrává, softwarové procesy jsou lépe definovány a jsou konzistentnější v rámci celé organizace. Schopnost softwarového procesu (Software Process Capability) popisuje okruh očekávaných výsledků, které mohou být dosaženy následováním softwarového procesu je to nástroj pro určení výstupů budoucích projektů. Výkon softwarového procesu (Software Process Performance) představuje skutečné výsledky dosažené následováním softwarového procesu. Vztah mezi schopností a výkonem nemusí být přímo úměrný. Například přechod na novou technologii zvyšuje schopnost procesu, ale je spojen s nutností zaškolení pracovníků a může vést k poklesu výkonu procesu. Úroveň zralosti (Maturity Level) je dobře definované prostředí pro evoluční dosahování zralých softwarových procesů. Každá úroveň představuje vrstvu pro kontinuální zlepšování procesů a zahrnuje sadu cílů, které, stabilizují určitý prvek softwarového procesu. Zralost softwarového procesu (Software Process Maturity) je dosažena, pokud je určitý proces explicitně definován, řízen, měřen, kontrolován a je efektivní. Zralost softwarových procesů vede ke zvýšení produktivity a kvality a zvyšuje se výkon procesu. Když organizace dosáhne zralosti softwarových procesů, vede to k jejich institucionalizaci prostřednictvím politik, standardů a organizačních struktur. Hodnocení softwarového procesu (Software Process Assesment) je hodnocení stavu softwarových procesů v organizaci. Provádí je vyškolený tým softwarových profesionálů s cílem určit procesy s nejvyšší prioritou a vytvořit organizační podporu pro jejich zlepšení. Klíčová oblast procesů (Key Process Area) oblast, která má podstatný význam z hlediska zlepšení softwarových procesů. 44 pojem klíčová oblast procesů je vymezen v Softwarové procesy jsou podmnožinou procesů informatiky, které byly definovány v podkapitole 2.1. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 34

35 Charakteristika metodiky Model SW CMM definuje 5 úrovní zralosti softwarových procesů organizace. Na základě definované zralosti procesů se identifikuje několik nejdůležitějších oblastí pro zlepšení procesů, na které se organizace zaměří. Smysl CMM je dokumentován na rozdílu mezi nezralými a zralými organizacemi. V nezralé organizaci jsou dle autorů CMM procesy při vývoji software výsledkem improvizace. I když nějaké procesy existují, nelze je opakovat a předvídat, organizace pouze reaguje na vzniklé problémy a napravuje chyby. Plány a rozpočty jsou překračovány, protože nejsou založeny na realistických odhadech. Při snaze dodržet čas, dochází ke snižování kvality. V nezralé organizaci neexistuje objektivní základ pro určení kvality produktu a pro řešení problémů, a proto je obtížné kvalitu produktu zajistit. Činnosti, které mají kvalitu zvýšit se často z důvodu nedostatku času neprovádějí. Na druhé straně zralá organizace je dle autorů CMM schopna řídit procesy při vývoji software a to v rámci celé organizace. Pro přechod od chaotických procesů ke zralým disciplinovaným softwarovým procesům slouží CMM. Stupňovitá struktura CMM vychází z prací Waltra Shewarta, který v roce 1930 definoval principy statistické kontroly kvality, které byly dále rozvinuty v pracích Deminga a Jurana [Paulk]. Neustálé zlepšování procesů je založeno na mnoha malých evolučních krocích. CMM představuje rámec, který organizuje tyto evoluční kroky do 5 úrovní zralosti tak, jak ukazuje obrázek 3.1. V následujících odstavcích je podrobněji charakterizováno chování organizací na jednotlivých úrovních zralosti. obrázek 3.1: 5 úrovní zralosti SW CMM zdroj [Paulk] 1. Počáteční úroveň (initial) Softwarové procesy jsou náhodné a chaotické. Organizace na této úrovni zralosti nemají stabilní prostředí pro vývoj a údržbu software, reagují pouze na vzniklé problémy. Schopnost softwarových procesů na úrovni 1 nelze předpovídat, protože se procesy neustále mění. Schopnost procesů závisí na schopnostech jednotlivců a liší se s jejich znalostmi a kvalifikací. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 35

36 2. Opakovatelná úroveň (repeatable) Organizace na této úrovni zralosti mají definovány politiky řízení projektu a vybudovány procedury pro jejich implementaci. Plánování a řízení nových projektů je založeno na zkušenostech s podobnými projekty. Cílem úrovně 2 je zavedení efektivního řízení softwarových procesů. Efektivní proces je dokumentovaný, vyžadovaný, měřitelný, lidé jsou pro něj vyškoleni a proces je možné zlepšovat. Cíle projektu jsou realistické, jsou založeny na výsledcích předcházejících projektů a požadavcích současného projektu. Manažeři sledují náklady, plán a funkcionalitu, problémy jsou identifikovány hned při vzniku, jsou definovány projektové standardy a dohlíží se na jejich dodržování. Schopnost softwarových procesů na úrovni 2 může být definována jako disciplinovaná. 3. Definovaná úroveň (defined) Organizace na této úrovni zralosti má definovány, dokumentovány a standardizovány procesy pro řízení i inženýrské činnosti, které jsou navzájem integrovány v rámci celé organizace. Je definován Standardní softwarový proces organizace, který je potom přizpůsobován na podmínky jednotlivých projektů. Tím vzniká Softwarový proces projektu. Zaměstnanci i manažeři jsou vyškoleni pro plnění rolí v procesech. Schopnost softwarových procesů na úrovni 3 může být definována jako standardní a konzistentní, protože jak činnosti inženýrské, tak činnosti řízení jsou stabilní a opakované. 4. Řízená úroveň (managed) Organizace na této úrovni zralosti má stanoveny detailní metriky softwarových procesů a kvality produktu. Data z projektů se uchovávají v databázi a analyzují. Kontrola projektů je zajištěna odhalováním odchylek od definovaných mezí. Schopnost softwarových procesů na úrovni 4 může být definována jako predikovatelná, protože proces je měřitelný a operuje v rámci měřitelných mezí. 5. Optimalizovaná úroveň (optimizing) Organizace na této úrovni zralosti disponuje prostředím pro kontinuální zlepšování procesů. Organizace identifikuje slabé a silné stránky procesů předem ve snaze zabránit vzniku problémů. Data o efektivnosti softwarových procesů jsou používána pro analýzy přínosů nových technologií a navrhovaných změn softwarových procesů v organizaci. Jsou identifikovány inovace, které využívají nejlepší praktiky softwarového inženýrství a jsou přenášeny do celé organizace. Týmy na úrovni 5 analyzují defekty, aby určily jejich příčiny. Softwarové procesy jsou vyhodnocovány, aby se předešlo defektům, které nastaly v jiných projektech. Schopnost softwarových procesů na úrovni 5 může být definována jako kontinuálně se zlepšující. Kromě úrovně 1 je každá úroveň zralosti dekomponována do několika klíčových oblastí procesů (Key Process Area, KPA), které určují, na jaké procesy by se měla organizace zaměřit. Klíčové oblasti procesů modelu SW CMM jsou popsány v tabulce 3.1. Každá KPA je popsána klíčovými praktikami, které zajišťují splnění cílů dané oblasti procesů. Klíčové praktiky popisují infrastrukturu a činnosti, které přispívají k nejefektivnější implementaci dané KPA. Podrobnější charakteristika KPA na jednotlivých úrovních zralosti modelu SW CMM je uvedena v příloze 1. Dosažení určité úrovně zralosti představuje zlepšení možností monitorování stavu softwarových procesů. Tuto skutečnost ilustruje obrázek 3.2. Pro organizaci na úrovni zralosti 1 představují softwarové procesy černou skříňku. Protože sled činností není dostatečně definován, manažeři mohou jen obtížně určit stav projektu. Požadavky vstupují do softwarového procesu nekontrolovatelným způsobem. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 36

37 úroveň klíčové oblasti procesů 2 SW procesy spojené s vytvořením základních prvků řízení projektu: řízení požadavků plánování softwarových projektů sledování softwarových projektů řízení subdodávek zajištění kvality software řízení konfigurací 3 projekční i organizační hlediska procesů přes všechny projekty, tedy v celé organizaci: zaměření na procesy na úrovni organizace definice procesů na úrovni organizace program školení integrace software softwarové inženýrství koordinace mezi skupinami kontroly 4 vytvoření a kvantitativní podpora SW procesů a vytvářených SW produktů: řízení kvantitativních procesů řízení kvality 5 neustálé měřitelné zlepšování SW procesů: prevence defektů řízení technologických změn řízení změn procesů tabulka 3.1: Klíčové oblasti procesů modelu SW CMM obrázek 3.2: Sledování průběhu procesů na jednotlivých úrovních zralosti modelu SW CMM zdroj [Paulk] ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 37

38 Na úrovni 2 jsou již zavedeny základní praktiky řízení projektu, což umožňuje zjišťovat stav procesu v bodech přechodu projektových milnících. Vedení však stále nemůže detailně sledovat průběh procesů a pouze reaguje na vzniklé problémy. Softwarové procesy na úrovni 3 zpřístupňují interní strukturu bloků, která reprezentuje způsob, jakým jsou standardní softwarové procesy organizace aplikovány na určitý projekt. Jak manažeři, tak inženýři znají své role a odpovědnosti v rámci procesu. Vedení se proaktivně připravuje na rizika, která mohou nastat. Na úrovni 4 jsou softwarové procesy kontrolovány kvantitativně. Manažeři mohou měřit pokrok a problémy a mají objektivní, kvantitativní základ pro rozhodování. Jejich schopnost předpovídat výsledky roste a proměnlivost procesů se zmenšuje. Na úrovni 5 dochází k řízenému zlepšování softwarových procesů Instance CMM PSP a TSP Organizace, které zaváděly CMM, měly problémy s aplikací CMM principů. Proto Watts Humprey definoval v r.1989 metodiku Personal Software Process (PSP), která popisuje procesy a praktiky určené pro softwarové inženýry, které mají zlepšit práci jednotlivců a podpořit procesy CMM [Humprey,PSP]. Na vyšších úrovních zralosti CMM se však ukázala potřeba zlepšit také práci týmů. Proto byla vytvořena metodika Team Software Process (TSP). TSP je plně definovaný a měřitelný proces, který mohou týmy používat pro plánování své práce, plnění plánů a kontinuální zlepšování procesů vývoje software. TSP je definován množinou procesních skriptů, které popisují všechny aspekty plánování projektu a vývoje produktu v rámci 4 fází požadavky, vysokoúrovňový design, implementace, integrace a testování. TSP poskytuje týmům explicitní postupy, jak dosáhnout definovaných cílů a jeho nejdůležitější přínos spočívá v tom, že pomáhá týmu řídit své pracovní prostředí dává týmu zodpovědnost za plánování své práce a vytvoření kvalitního produktu co nejrychleji a nejefektivněji. [McAndrews] Hodnocení metodiky CMM představuje množinu veřejných kritérií, která popisují charakteristiky zralé softwarové organizace. Tato kritéria mohou být využita pro zlepšení procesů vývoje a údržby software nebo pro hodnocení rizika najímání subdodavatelů pro softwarový projekt. Z metapopisu metodiky SW CMM, který je uveden v příloze 5, vyplývá, že CMM je metodika globální, zaměřená na procesy v rámci celé organizace. Je to metodika těžká, definuje softwarové procesy tak, aby mohly být opakovány. Je zaměřena především na řízení softwarových procesů, méně pak na softwarově inženýrské postupy. Definuje jednotlivé oblasti procesů a cíle, které mají být dosaženy, tedy co by měly organizace dělat, ale nepopisuje způsob jejich dosažení, jak by to měly dělat. Definice způsobu, jak naplnit cíle klíčových oblastí procesů definovaných v SW CMM, je potom předmětem metodiky PSP na úrovni jednotlivců a TSP na úrovni týmů. CMM, PSP, TSP tak tvoří integrovaný třídimenzionální rámec pro zlepšování procesů. Hodnocení využitelnosti metodiky CMM pro návrh metodického rámce je uvedeno v podkapitole Metodika OPEN Identifikace metodiky a zdrojů Object oriented Process, Environment and Notation je veřejně přístupná metodika podporující celý životní cyklus vývoje IS/ICT. Je zaměřena zejména na vývoj objektově orientovaných a komponentových aplikací. Své kořeny má tato metodika v projektu COMMA (Common Object Methodology Metamodel Architecture), jehož cílem bylo vytvořit metamodely většiny metodik a metod objektově orientované analýzy a designu, na jejichž základech měl být poté vystavěn univerzální metodický prostředek. Klíčovými osobnostmi, které se zasloužili o vytvoření a rozšíření OPEN jsou Brian Henderson Sellers, Meilir Page Jones, Ian Graham a Donald Firesmith a další osobnosti organizované v konsorciu OPEN, mezinárodním seskupení více než 35 metodiků, vědeckých pracovníků, dodavatelů CASE nástrojů a vývojářů [OPEN]. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 38

39 Charakteristika metodiky Metodika OPEN definuje procesní rámec, známý pod názvem OPEN Process Framework (OPF). Jde o procesní metamodel, ze kterého mohou být generovány instance specifické pro organizaci. Každá taková instance je vytvořena výběrem činností, úloh a technik (tří hlavních tříd na metaúrovni) a jejich specifickou konfigurací. Tento proces je označován jako konstrukce procesu (process construction). Metodika dále rozlišuje přizpůsobení procesu (process tailoring), které spočívá v přizpůsobení činností a úloh tak, aby maximálně vyhovovaly problémové doméně. Tímto způsobem je OPEN flexibilní, může se přizpůsobit jak doméně, tak konkrétnímu projektu a zohlednit dovednosti členů týmu, kulturu organizace, požadavky specifické pro každou doménu. OPEN může být použit pro malé projekty, stejně jako pro velké, klíčové projekty. OPEN poskytuje podporu pro celý životní cyklus softwarové aplikace. Jeho součástí je řízení projektu a rámec pro znovupoužitelnost, podporuje modelování podnikových procesů, zaměřuje se na kvalitu software a použití metrik. Proto má těsné vazby s CMM a OOSPICE. OPF obsahuje velké množství metatříd, které jsou seskupeny do 5 hlavních skupin pracovní jednotky, pracovní produkty, producenti, etapy, jazyky. Tyto metatřídy vytvářejí knihovnu komponent OPEN, ze které se vytvářejí a skládají instance metodiky. Pracovní jednotky jsou představovány činnostmi, úlohami a technikami. Činnosti (activities) určují, co je třeba udělat, ale neurčují jak. Činnosti se člení na úlohy (tasks), které mají rozsah takový, aby je mohl realizovat jeden vývojář nebo malý tým v relativně krátkém čase. Techniky potom určují, jak se úlohy provádějí. K těmto třem základním skupinám metatříd se připojují etapy různých druhů (fáze, životní cykly, milníky) a jazyky (přirozený jazyk, modelovací jazyky, programovací jazyky). Pro modelování je možné zvolit UML nebo OML (OPEN Modeling Language) Hodnocení metodiky V příloze 5 je uveden metapopis metodiky OPEN, ze kterého můžeme shrnout, že OPEN je velmi podrobně popsaná metodika, která je ovšem zaměřena pouze na úroveň projektu a orientovaná pouze na objektově orientovaný a komponentový vývoj nového řešení. Přínosné jsou myšlenky vytváření konkrétní metodiky z metatříd, které jsou součástí OPF. Hodnocení metodiky OPEN s ohledem na možnosti využití některých myšlenek pro návrh metodického rámce MEFIS je uvedeno v podkapitole Metodika Rational Unified Process Identifikace metodiky a zdrojů Metodika Rational Unified Process (RUP) je softwarový inženýrský proces, který představuje disciplinovaný přístup přiřazující úkoly a odpovědnosti v organizaci zabývající se vývojem software [RUP]. Metodika Rational Unified Process vznikla spojením přístupu Rational a metodiky Objectory Process Ivara Jacobsona. Nejprve byla nazvána Rational Objectory Process a v roce 1998 pak byla doplněna a přejmenována na Rational Unified Process. Rational Unified Process je specializací obecnějšího procesu, který popsali Ivar Jacobson, Grady Booch a James Rumbaugh v knize The Unified Software Development Process [Jacobson,Booch,Rumbaugh] Charakteristika metodiky Metodika Rational Unified Process je založena na tzv. nejlepších praktikách softwarového vývoje [RUP]: iterativní vývoj, řízení požadavků použití komponentové architektury, vizuální modelování, kontrola kvality software, řízení změn. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 39

40 Proces vývoje software je možné popsat v rámci dvou dimenzí, které odpovídají osám na obrázku 3.3. Horizontální osa představuje dynamický pohled na proces, který je vyjádřen pomocí cyklů, fází, iterací a milníků. Vertikální osa reprezentuje statické hledisko procesu, popis činností, artefaktů, pracovníků a pracovních toků. Na obrázku 3.3 je na vertikální ose znázorněno 9 tzv. disciplín 46, které představují logické seskupení činností definovaných v RUP. Graf ukazuje podíl jednotlivých disciplín v různých fázích projektu. Fáze Disciplíny Obchodní modelování Požadavky Analýza a návrh Implementace Testování Zavedení Konfigurační management Řízení projektu Prostředí obrázek 3.3: Fáze a disciplíny RUP [RUP] Životní cyklus software je rozdělen na cykly. Předmětem každého cyklu je nová verze produktu. Jeden vývojový cyklus je v RUP rozdělen do 4 po sobě jdoucích fází: Počáteční fáze (Inception), Elaborační fáze (Elaboration), Konstrukční fáze (Construction), fáze Nasazení (Transition). Cílem Počáteční fáze je definice cílů projektu, požadavků, sestavení harmonogramu projektu (plán iterací), odhad nákladů projektu a definice rizik. Součástí této fáze může být vytvoření modelu nebo jednoduchého prototypu, na kterém se ověří, zda je možné se zvolenou technologií a pomocí zvolených nástrojů klíčové požadavky splnit. Počáteční fáze končí rozhodnutím, zda je projekt za daných požadavků, dostupných technologií, zdrojů a rozpočtu možné realizovat. Cílem Elaborační fáze je definovat architekturu systému. V této fázi by měl být vytvořen prototyp, který ověří všechny architektonické principy a umožní zpřesnění plánu realizace systému. Měly by být definovány komponenty, které je třeba vyvinout pro opakované použití. Obsahem Konstrukční fáze je návrh a realizace systému včetně testování. Prosazuje se pokud možno paralelní vývoj. Cílem fáze Nasazení je zajistit, aby uživatelé mohli systém používat. Součástí této fáze je školení uživatelů, předání dokumentace, vytvoření help desk atd. Každá fáze je uzavřena milníkem časovým okamžikem, ve kterém musí být splněny cíle fáze a dochází k rozhodování Hodnocení metodiky Metapopis metodiky RUP je uveden v příloze 5. Metodika Rational Unified Process patří mezi rigorózní metodiky, neboť podrobně definuje procesy a činnosti při vývoji software. Zaměřuje se pouze na vývoj nového řešení realizovaný objektově orientovaným způsobem. Podstatným nedostatkem metodiky RUP je její zaměření pouze 46 později jsou v RUP označovány jako core process workflows ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 40

41 na úroveň projektu, nepostihuje tedy procesy a činnosti, které jdou za hranice jednoho projektu jako řízení portfolia projektů, vytváření globální architektury, znovupoužitelnost na úrovni organizace a další. Metodika má poměřně malý rozsah 47, neboť se zaměřuje pouze na vývoj řešení, ne na jeho provoz a údržbu, a pouze na softwarově inženýrské role a dimenze. Silnou stránkou metodiky Rational Unified Process je její integrace s CASE nástroji firmy Rational, které podporují především oblast analýzy a návrhu, testování, konfigurační management a správu požadavků. Tato výhoda ale může být z hlediska otevřenosti a obecnosti považována na druhé straně za nevýhodu, neboť činí metodiku RUP závislou na vývojových nástrojích. V České republice je metodika RUP distribuována firmou Unicorn, která zajišťuje i školení a podporu. K nevýhodám metodiky RUP patří, že není lokalizována do češtiny, je velmi rozsáhlá 48 a je poměrně drahá. Metodika Rational Unified Process je dodávána jako produkt. Jde o znalostní bázi s webovým rozhraním a sadu nástrojů na přizpůsobení procesu a šablon do nástrojů firmy Rational. V současné době se tvůrci metodiky RUP snaží o promítnutí některých myšlenek agilních metodik a odlehčení metodiky RUP, ale stále je to těžká metodika. Hodnocení využitelnosti metodiky RUP pro návrh metodického rámce je uvedeno v podkapitole Metodika Enterprise Unified Process Identifikace metodiky a zdrojů Enterprise Unified Process (EUP) představuje rozšíření metodiky Rational Unified Process (RUP) a pochází z dílny Scotta W. Amblera [Ambler,AMT] Charakteristika metodiky Metodika Enterprise Unified Process rozšiřuje metodiku RUP ve dvou směrech. První směr představuje rozšíření na úroveň celé organizace. EUP definuje novou disciplínu Infrastructure Management, která zahrnuje procesy realizované přes projekty 49. Druhý směr rozšíření metodiky RUP představuje připojení fáze Production, jejíž náplní je provoz a údržba systému, a fáze Retirement, která popisuje činnosti nutné při odstranění produktu z používání [Ambler,AMT] Hodnocení metodiky Na základě metapopisu metodiky EUP, který je uveden v příloze 5, je možné konstatovat, že metodika EUP překonává některá omezení metodiky RUP 50. EUP je globální metodikou, je tedy zaměřena na budování informačního systému na úrovni celé organizace, což umožňuje postihnout takové procesy jako řízení portfolia projektů, znovupoužitelnosti na úrovni celé organizace, vytváření globální architektury apod. Významné je i další zvětšení rozsahu metodiky EUP ve smyslu zařazení fází pro provoz, údržbu a odstranění produktu. EUP ovšem stejně jako RUP zůstává zaměřen jen na malou množinu rolí a dimenzí 51 a pouze na objektově orientovaný vývoj nového řešení respektive rozvoj řešení. 47 ve smyslu kritéria Rozsah metodiky zavedeného v jde o těžkou metodiku 49 příkladem jsou procesy jako řízení znovupoužitelnosti, řízení portfolia projektů, řízení softwarového procesu, globální architektura 50 zejména její projektové zaměření a zaměření pouze na vývoj ne na provoz a údržbu 51 pouze role a dimenze úzce spjaté se softwarovým inženýrstvím ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 41

42 3.2 Agilní metodiky Změny technologií, ekonomického prostředí a požadavky na extrémně rychlé vybudování IS/ICT či jeho části vyžadují změny v metodikách. Tradiční rigorózní metodiky přestávají v nových podmínkách vyhovovat. Jak řekl děkan ekonomické fakulty Univerzity v Trentu Enrico Zaninotto na konferenci XP2002 v Sardinii: Softwarový průmysl se snaží napodobovat metody organizace průmyslové výroby, které byly již překonány a v 70 letech byly nahrazeny štíhlou výrobou, podobně jako extrémní programování a agilní procesy nyní nahrazují rigorózní přístupy [Schwaber,SB]. V současnosti se tedy začínají prosazovat metodiky, které umožňují vytvořit řešení velmi rychle a pružně jej přizpůsobovat měnícím se požadavkům. Tyto metodiky jsou označovány jako agilní. Agilita je požadavkem dnešní doby. Agilní organizace se nesnaží potlačovat změny, ale naopak změn využívají, snaží se na ně reagovat lépe než konkurence a vytvářejí změny, na které konkurence neumí adekvátně reagovat. Agilní metodiky představují ve své podstatě reengineering procesů při budování IS/ICT. Když byl v 90. letech prosazován reengineering v podnikových procesech, dostala jedna osoba 52 plnou kontrolu nad celým procesem. Podobně agilní přístup k vývoji software dává jednomu vývojáři plnou kontrolu nad všemi fázemi 53 procesu vývoje od přímé komunikace se zákazníkem při sběru požadavků až k realizaci. Jak řekl jeden ze zakladatelů procesního reengineeringu Michael Hammer: Musíme začít z úplně opačného konce. Tím, co potřebujeme jsou vysoce výkonné procesy, ty musí být jednoduché. A jednoduché procesy vyžadují složité pracovní funkce. To znamená, že je třeba, aby jednotlivci vykonávali větší kus práce. Širší pracovní náplně vyžadují intelektuálně vyspělejší jedince. Musíme se vrátit ke koncepci, v níž se lidé nesoustředí na jednotlivý úkon, na svou izolovanou činnost, ale na konečný výsledek. A co k tomu konečnému výsledku vede? Ne individuální pracovní úkon, ale soubor úkonů proces. Vzhledem k tomu, že procesy nemohou zajišťovat jednotlivé osoby, vracíme se ke koncepci týmu skupiny lidí s kolektivní odpovědností za vytvoření konečného výsledku. [Gibson] Agilní metodiky jsou metodiky projektové 54 a jsou zaměřeny na vývoj nového řešení (nikoli na údržbu a provoz). Proto je v nich používán pojem vývoj software. Při popise těchto metodik tento pojem používám také Manifest pro agilní vývoj software V únoru 2001 se sešli nejvýznamnější představitelé nových přístupů k vývoji software, byla vytvořena Aliance pro agilní vývoj software a podepsán Manifest agilního vývoje software. Manifest obsahuje 4 deklarace hodnot, přičemž prvky na levé straně mají větší relativní význam než prvky na pravé straně. Manifest uvádí ( přeloženo dle [Fowler,Highsmith]: Odhalili jsme lepší způsob vývoje software, sami jej používáme a chceme pomoci i ostatním, aby jej používali. Z toho pohledu dáváme přednost: individualitám a komunikaci před procesy a nástroji, provozuschopnému software před obsažnou dokumentací, spolupráci se zákazníkem před sjednáváním kontraktu, reakci na změnu před plněním plánu. Manifest tedy deklaruje zásadní principy, které je třeba při vývoji software uplatňovat. Tyto principy byly dále podrobněji rozpracovány. V následujících bodech jsou vysvětleny hlavní principy agilních metodik (zpracováno dle [Fowler,Highsmith]): 52 vlastník procesu 53 fáze vývoje v rámci jednoho projektu respektive jednoho přírůstku 54 dle kategorizace zavedené v ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 42

43 1. Nejvyšší prioritou je uspokojovat zákazníky včasnou a kontinuální dodávkou software, který jim přináší hodnotu. Zákazníka nezajímají dokumenty, UML 55 diagramy nebo integrace stávajících systémů, ale zajímá jej, zda dostane fungující software v každé iteraci a zda poskytovaná funkcionalita uspokojí jeho potřeby. Tradiční přístupy předpokládají, že splnění plánu = úspěch projektu = hodnota pro zákazníka. V dnešní době je však nutné, aby hodnota pro zákazníka byla prověřována často, protože je předmětem změny. 2. Změny požadavků je možné provést i v pozdějších fázích vývoje, neboť změna může poskytnout zákazníkovi konkurenční výhodu. Agilní přístup se snaží realizovat změny efektivně a řídit rizika negativních dopadů. Je třeba realizovat krátké iterace (od dvou týdnů do dvou měsíců) a na jejich konci dodávat fungující software. Iterativní vývoj je prosazován i tradičními metodikami, agilní přístupy však kladou důraz na zkrácení cyklu dodávky. 3. Uživatelé a vývojáři spolupracují denně na projektu. Mnoho zákazníků chce nakupovat software podobně jako automobil. Mají představu o jeho vlastnostech, dohodnou cenu a zaplatí. Agilní přístupy počítají s radikální změnou konceptu specifikace požadavků. Vycházejí z toho, že není možné dohodnout a podepsat požadavky na začátku projektu. Místo toho na začátku projektu definují hrubé požadavky, které jsou předmětem neustálých změn. Aby je bylo možné zpodrobnit, je třeba vést častá jednání s uživateli. Denní frekvence těchto jednání je možná překvapivá, ale má podtrhnout nutnost permanentně zajišťovat souhlas a spoluúčast uživatelů na definování požadavků a přenést odpovědnost za projekt na uživatele. 4. Motivovaní jedinci, kteří mají podmínky a podporu vedení, jsou klíčovým faktorem úspěchu projektu. I když nasadíme všechny možné prostředky a nástroje, jsou to nakonec lidé, kteří rozhodují o úspěchu či neúspěchu projektu. 5. Nejefektivnějším způsobem přenosu informací v rámci vývojového týmu je vzájemná konverzace. Agilním metodikám bývá vytýkána nedostatečná dokumentace. Dokumentace není ale cílem projektu, jejím smyslem je pochopení problému, kterého se mnohem lépe, rychleji a s menšími náklady dosáhne používáním přímých technik komunikace. Blíže viz podkapitola Komunikace. 6. Primární mírou úspěchu je fungující software. Plnění plánu, dokumentace návrhu, existence kódu to vše nestačí pro úspěch projektu. Je třeba mít fungující systém. 7. Agilní procesy předpokládají udržitelný vývoj. Vývoj software je běžně realizován s dlouhými přesčasy a prací přes víkend, což zákonitě snižuje produktivitu vývoje. Udržitelný vývoj znamená vymezit pracovní prostor (cca 40 hodin týdně), v jehož rámci zůstane tým v dobré kondici. 8. Stálá pozornost perfektnímu technickému řešení i návrhu. I když se agilní přístupy podobají rychlému vývoji aplikací (RAD 56 ) v rychlosti a flexibilitě, je zde velký rozdíl v kvalitě návrhu a řešení. Agilní přístupy zdůrazňují kvalitu návrhu, protože je nezbytná pro realizaci změn. Návrh není samostatnou etapou, která je plně dokončena před zahájením implementace, ale je to iterativní činnost prováděná v průběhu projektu. 9. Jednoduchost řešení, tj. umění maximalizovat množství neudělané práce, je zásadní. Při vývoji software můžeme použít množství postupů a metod. V agilních projektech je kladen důraz na jednoduché postupy a minimalizaci, protože jednoduché řešení se snáze mění. 55 UML - Unified Modeling Language viz podkapitola Rapid Application Developmnent ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 43

44 10. Nejlepší architektury, požadavky a návrhy vznikají ze samoorganizujících se týmů. Tento princip zdůrazňuje kreativitu lidí, častou komunikaci a přizpůsobování metodiky. Pod hlavičku agilních metodik jsou zahrnovány tyto metodiky a přístupy, které jsou v následujících odstavcích stručně charakterizovány: Dynamic Systems Development Method (DSDM), Adaptive Software Development ( ASD), Feature Driven Development (FDD), Extrémní programování (Extreme Programming, XP), Lean Development, Scrum, Crystal metodiky, Agilní modelování (Agile Modeling) Dynamic Systems Development Method (DSDM) Identifikace metodiky a zdrojů Metodika Dynamic Systems Development Method (DSDM) vznikala ve Velké Británii v první polovině 90 let. Rozvoj metodiky a její rozšiřování má na starosti DSDM konsorcium 57. DSDM má ze všech agilních metodik nejlépe propracovaná školení a dokumentaci a získala popularitu jak v Evropě, tak i v USA. Popis metodiky je možné nalézt v [DSDM], [Highsmith,2000], [AgileMet] Charakteristika metodiky Metodika DSDM představuje rozšíření praktik rychlého vývoje aplikací (RAD). Její charakteristiky lze odvodit ze slov, která tvoří název metodiky. Slovo dynamic reprezentuje schopnost přizpůsobit se změnám v průběhu procesu vývoje. Slovo systems bychom dnes spíše nahradili slovem solutions ve smyslu obchodního řešení. Písmeno D původně reprezentující slovo development, bychom dnes mohli nahradit slovem delivery, které akcentuje význam dodaného řešení. Také poslední písmeno M bychom místo slova method možná lépe vyjádřili slovem model. I tento posun výkladu zkratky ukazuje neustálý vývoj metodiky. DSDM je postaveno na 9 principech [DSDM]: aktivní zapojení uživatele, tým musí mít pravomoc rozhodovat, zaměření na časté dodávky produktů, klíčovým kritériem pro přijetí dodávky je podpora obchodních cílů, iterativní a inkrementální vývoj jako nástroj postupného přibližování k žádoucímu řešení, je třeba umožnit změny v průběhu vývoje, požadavky jsou definovány na hrubé úrovni, testování je integrováno v průběhu celého životního cyklu, důraz je kladen na spolupráci mezi členy týmu. Proces vývoje v DSDM je rozdělen do třech hlavních fází Functional Model, Design and Build a Implementation, kterým předchází Feasibility Study a Business Study. Hlavní fáze probíhají iterativně. Obsahem 57 zdroj ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 44

45 iterace Functional Model je sběr a prototypování funkčních požadavků 58. Většina požadavků je dokumentována jako prototypy. Ve fázi Design and Build jsou prototypy zpodrobňovány, tak aby podporovaly všechny požadavky (i nefunkční) a je navrhováno řešení. Náplní fáze Implementation je realizace navrženého řešení, zhodnocení projektu, školení uživatelů a další činnosti Hodnocení metodiky Metodika DSDM je projektovou metodikou, která je zaměřena zejména na softwarově inženýrskou oblast, méně se zabývá oblastí řízení. Je zaměřena pouze na vývoj nového řešení, kombinuje přístup rychlého vývoje aplikací (Rapid Application Development) s objektově orientovaným vývojem. Základní technikou používanou při analýze a návrhu je prototypování. Přínosem metodiky je řízení jejího rozvoje, propagace, školení a implementace. Metapopis metodiky DSDM je uveden v příloze Adaptive Software Development (ASD) Identifikace metodiky a zdrojů Metodika Adaptive Software Development (ASD) představuje filosofické zázemí pro agilní metodiky. Autorem je Jim Highsmith. Popis metodiky je možné nalézt v [Highsmith,2000],[AgileMet] Charakteristika metodiky Metodika je silně ovlivněna teorií komplexních adaptivních systémů (blíže viz 4.6), která pomáhá pochopit nepředvídatelnost a neustálé změny. Těmto změnám se nesmíme bránit, ale musíme se na ně adaptovat. Proto je v metodice ASD statický životní cyklus Plan Design Build ( Plánování Návrh Realizace ), typický pro tradiční metodiky, nahrazen dynamickým cyklem Speculate Collaborate Learn. Základem tohoto dynamického životního cyklu je kontinuální učení a hybnou silou jsou neustálé změny. V klasickém životním cyklu je nejobtížnější fáze plánování. Plán ze své podstaty brání inovacím a produkuje výsledky, které jsou sice plánovány, ale nejsou potřebné. Spekulace dává mnohem více prostoru pro změny, přiznává nejistotu, podporuje zkoumání a experimentování. Plánování se provádí, ale v mnohem menší míře. Při klasickém postupu jsou odchylky od plánu chápány většinou jako chyby, ASD v nich vidí příležitosti k učení. Druhou podstatnou součástí adaptivního životního cyklu je spolupráce (Collaboration). Pro vytváření současných aplikací je třeba sebrat velké množství informací, analyzovat je a aplikovat na řešení problému. Je to dáno jednak velkým množstvím různých technologií, které je třeba spojit v rámci aplikace, potřebami integrace s ostatními aplikacemi, velkým množstvím věcných znalostí. Jde o mnohem větší objem informací než je schopen jedinec zvládnout, a proto je rozhodující schopnost spolupracovat. Týmy musí spolupracovat na řešení technických problémů i věcných požadavků, musí zlepšovat své rozhodovací schopnosti a řada rozhodnutí musí být delegována na úroveň týmu. Toto rozhodování závisí na třetí složce adaptivního životního cyklu učení. Musíme své znalosti neustále prověřovat, učit se z minulých chyb i úspěchů. Adaptivní životní cyklus má následující charakteristiky: zaměřuje se na poslání, Pro celou řadu projektů 59 může být konečný výsledek neurčitý, ale poslání bývá zřejmé. Poslání slouží jako průvodce při specifikaci požadavků a určuje spíše hranice než přesný cíl. Poslání je třeba také neustále zpřesňovat. 58 zaznamenávají se i nefunkční požadavky 59 například elektronického obchodu ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 45

46 výsledná aplikace je složena z částí (komponent), Adaptivní životní cyklus se zaměřuje na výsledky, ne na činnosti. Výsledky jsou identifikovány jako komponenty aplikace. Komponenta v tomto kontextu je chápána jako skupina vlastností, která je dodána v rámci iterativního cyklu, odpovídá tedy přírůstku. iterativní vývoj, Iterativní cyklus zdůrazňuje refaktorizaci, je třeba vyvíjet postupně a mít zpětnou vazbu od uživatelů. stanovení termínu dodávky, Otázka času je také důležitá. Nestačí jen definovat konečný termín, ale je třeba trvale ovlivňovat vytváření výsledků a časové mezníky přehodnocovat. řízení rizik, tolerantní ke změnám. obrázek 3.4: Základní adaptivní životní cyklus zdroj [Highsmith,7/2000] Na obrázku 3.4 je zachycen životní cyklus metodiky ASD. Cyklus se skládá ze tří fází Spekulace, Spolupráce a Učení. Předmětem fáze Spekulace jsou činnosti spojené se zahájením projektu, určení termínu ukončení projektu, optimálního počtu iterací, náplně každé iterace. V rámci fáze Spolupráce probíhá paralelně vývoj komponent a výsledkem jsou fungující komponenty. V rámci fáze Učení je třeba zhodnotit kvalitu řešení z pohledu zákazníka i z hlediska technologického, fungování týmu, používané praktiky a stav projektu Hodnocení metodiky Metodika ASD je určena pro projekty charakterizované vysokou rychlostí, velkými změnami a neurčitostí [Highsmith,7/2000]. Je to lehká metodika, která se zabývá nejen oblastí softwarově inženýrskou, ale i oblastí řízení a přináší nový přístup k řízení nazvaný Leadership Collaboration management. ASD je projektovou metodikou zaměřenou na objektově orientovaný a komponentový vývoj nového řešení. Přínosem metodiky je zdůraznění fáze učení. Metapopis metodiky ASD je uveden v příloze Lean development Identifikace metodiky a zdrojů Metodika Lean development, jejímž autorem je Robert Charette, je aplikací principů známých jako Lean Manufacturing a Total Quality Management na oblast vývoje software. Popis metodiky je možné nalézt v [Charette,2002], [Highsmith,2000], [AgileMet]. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 46

47 Charakteristika metodiky Lean Development je termín, který pochází ze sféry výroby štíhlá výroba (lean production) a uplatňoval se zejména v 80. letech. Lean development ztělesňuje koncept dynamické stability. Schopnost přizpůsobit se rychle a efektivně požadavkům (dynamická část) je spojena se schopností vytvářet stabilní, neustále se zlepšující vnitřní procesy, které mají obecnou platnost a přizpůsobují se přes široký okruh produktů. Cílem Lean development je vytváření software tolerantního ke změnám s třetinovou lidskou prací, s třetinovým časem, s třetinou investic do nástrojů a metod, s třetinovou námahou přizpůsobit se novému tržnímu prostředí. Následující přehled ukazuje aplikaci 10 pravidel štíhlé výroby na oblast vývoje software: Pravidlo 1: Odstranit zbytečné. Aplikace tohoto pravidla znamená odstranit vše, co nepřináší hodnotu konečnému produktu. Dokumenty, diagramy a modely vytvářené při vývoji software pohlcují zdroje, ale nejsou nutnou součástí finálního produktu. Pravidlo 2: Minimalizovat zásoby (minimalizovat artefakty). Zásobou při vývoji software je dokumentace, která není součástí finálního produktu. Nejlepší přístup, jak minimalizovat dokumentaci, je dosáhnout určité úrovně abstrakce v dokumentaci. Místo 100 stran detailní specifikace stačí 10 stran pravidel a dokumentace odchylek. Pravidlo 3: Maximalizovat tok (zkrátit čas vývoje). Jestliže je třeba zkrátit dobu vývoje, je třeba redukovat práci na procesu. Iterativní vývoj je aplikací tohoto principu při vývoji software. Pravidlo 4: Vývoj tažený poptávkou (rozhodovat co nejpozději). Praktiky vývoje software, které dokáží přizpůsobit dodávku software požadavkům uživatelů, představují v měnícím se prostředí konkurenční výhodu. Uživatelé nejsou schopni definovat své současné potřeby, natož budoucí. Pokud je návrh zařazen na začátku životního cyklu, s největší pravděpodobností se dostane do rozporu s požadavky. Pravidlo 5: Pracovníci s rozhodovací pravomocí (rozhodovat co nejníže). Vývojáři musí chápat, jak jejich práce přispívá celkovému cíli, musí vědět, co mají vykonat a do kdy, a musí mít možnost rozhodovat. Pravidlo 6: Uspokojovat požadavky zákazníků (nyní i v budoucnu). Nejčastější důvody neúspěchu projektů byly způsobeny chybějícími, nekompletními nebo nesprávnými požadavky. Metodiky vývoje software na to odpověděly praktikami detailní specifikace uživatelských požadavků, které uživatel potvrdí. Uživatel ale není schopen předem dohlédnout všechny potřeby. Úplná specifikace požadavků trvá dlouho, a tak se zvyšuje riziko, že zjištěné požadavky nebudou odpovídat skutečným potřebám. Pravidlo 7: Zavést zpětnou vazbu. Lean development vychází z toho, že pokud není možné definovat detailně všechny požadavky předem, je třeba zavést zpětnou vazbu a doplňovat je postupně. To ale znamená provádět změny v průběhu vývoje. Pravidlo 8: Odstranit lokální optimalizaci. V době neustálých změn nemá smysl optimalizovat stávající řešení. Pravidlo 9: Partnerství s dodavateli. Důležitá je hodnota pro zákazníka, pro urychlení a zlepšení kvality je možné nakupovat komponenty. Pravidlo 10: Vybudovat kulturu pro neustálé zlepšování Hodnocení metodiky Zatímco většina agilních metodik se zabývá taktickou úrovní, Lean Development se zaměřuje spíše na strategickou úroveň a má těsné vazby na podnikovou strategii. Lean Development je nástrojem přechodu na podnikání tolerantní ke změnám (change tolerant bussiness) a risk entrepreneurship. Podobně jako metodika ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 47

48 Scrum je Lean Development zaměřen zejména na řízení vývoje software, méně pak na softwarově inženýrskou oblast. Metapopis metodiky je uveden v příloze Feature-Driven Development (FDD) Identifikace metodiky a zdrojů Metodika Feature Driven Development (FDD), jejímiž autory jsou Jeff De Luca a Peter Coad, je agilní metodika, která zachovává procesní řízení a zdůrazňuje úlohu modelování 60 při vývoji. Popis metodiky je možné nalézt v [FDD], [Highsmith,2000], [AgileMet] Charakteristika metodiky Metodika FDD je založena na iterativním vývoji, který je řízen užitnými vlastnostmi produktu (feature driven). Vývoj začíná vytvořením celkového modelu a pokračuje posloupností dvoutýdenních iterací, ve kterých se provádí návrh i realizace pro jednotlivé užitné vlastnosti. Užitná vlastnost (feature) je malý výsledek užitečný z pohledu zákazníka, je srozumitelný, měřitelný a realizovatelný spolu s dalšími v rámci dvoutýdenní iterace. FDD se skládá z 5 procesů, které jsou zachyceny na obrázku 3.5: vytvoření celkového objektového modelu (Develop an Overall Model), sestavení seznamu užitných vlastností (Build a Features List), plánování pro užitnou vlastnost (Plan by Feature), návrh pro užitnou vlastnost (Design by Feature), realizace pro užitnou vlastnost (Build by Feature). obrázek 3.5: Procesy FDD zdroj [FDD] FDD stejně jako ostatní agilní metodiky nepřeceňuje význam procesů při vývoji. Cílem musí být fungující produkt, ne splnění předepsaného procesu. Přesto považuje za vhodné definovat "lehký" proces, který je popsán cca na 2 stránkách textu. Takto definovaný proces umožňuje škálovat metodiku i na větší projekty, rychleji zapojit nové zaměstnance, stanovit priority, zaměřit se na přínosné výsledky a ponechat stranou drobnosti. Popis procesu by měl být co nejkratší, doporučuje se použít vzor ETVX: Entry, Task, Verification, exit: specifikovat jasně vstupní kritéria pro proces, vyjmenovat úkoly (u každého úkolu uvést název, kdo se jej účastní, zda je povinný, popis úkolu), 60 Jedním z důvodů je, že Peter Coad je majitel firmy Togethersoft (nyní součástí Borland), která se specializuje na nástroje pro integraci objektového modelování a implementace. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 48

49 nástroje verifikace, výstupní podmínky procesu hmatatelné výstupy Hodnocení metodiky Podobně jako ostatní agilní metodiky je FDD projektová metodika zaměřená na objektově orientovaný vývoj nového software. Na rozdíl od ostatních agilních metodik však podporuje procesy, byť poměrně lehké, a modelování (vytvoření celkového modelu) před implementací. Spolu s modelováním podporuje také používání CASE nástrojů. Z toho důvodu jsem ji zařadila mezi středně těžké metodiky viz. metapopis metodiky FDD v příloze Crystal metodiky Identifikace metodiky a zdrojů Crystal je rodina metodik, které jsou určeny pro různé typy projektů. Autorem je Alistair Cockburn. Popis metodiky je možné nalézt v [Cockburn, MetPerProj], [Cockburn,Cryst], [Highsmith,2000], [AgileMet] Charakteristika metodiky Název rodiny metodik je inspirován drahokamem, který má různé plošky, jejichž vzhled závisí na jádru, ze kterého jsou vybroušeny. Jádro rodiny metodik představují hodnoty a principy, zatímco každá ploška představuje určitou množinu prvků technik, rolí, nástrojů a standardů. Všechny metodiky z rodiny Crystal jsou postaveny na stejných hodnotách síla komunikace a lehkost produktu. Jednotlivé prvky metodiky se vylaďují pro každý projekt. Výběr příslušné metodiky z rodiny určuje velikost projektu (počet členů týmu) a důležitost systému. Jednotlivé metodiky jsou pojmenovány podle barev, nejlehčí je Clear, potom následuje Yellow, Orange, Red, Maroon, Blue, Violet atd. Například Orange je D40 metodika, to znamená, že je určena pro týmy do 40 lidí, kteří sedí v jedné budově a pracují na projektu, který může znamenat větší ztrátu peněz Hodnocení metodiky obrázek 3.6: Rodina metodik Crystal zdroj [CockCryst] Crystal představuje skupinu metodik pro různé druhy projektů, které se liší důležitostí, velikostí týmu a tím, na co je projekt optimalizován. Jde tedy o rámec metodik. Všechny metodiky patří do kategorie projektových metodik ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 49

50 a jsou opět zaměřeny na objektově orientovaný vývoj nového řešení. Přínosem rámce metodik je princip škálování podle typu projektu a důraz na lidský faktor. Metapopis metodik Crystal je uveden v příloze Scrum Identifikace metodiky a zdrojů Metodiku Scrum vyvinul Ken Schwaber a Jeff Sutherland, později spolupracoval Mike Beedle. Popis metodiky je možné nalézt v [Scrum2], [Highsmith,2000], [AgileMet] Charakteristika metodiky Ken Schwaber byl expertem v rigorózních, procesně orientovaných metodikách používaných koncem 80. a počátkem 90. let. Postupně si začal uvědomovat, že detailní metodiky s přesnými fázemi, kroky, úlohami a činnostmi mají podstatné nedostatky. Základem přístupu Scrum je přesvědčení, že vývoj software není definovaný proces, jak rigorózní metodiky předpokládají, ale empirický proces a vyžaduje tedy úplně odlišný styl řízení. Název Scrum byl vybrán podle skrumáže (mlýna) v rugby a má ukázat, že metodika Scrum je podobně jako hra rugby adaptivní, rychlá a samoorganizující. Metodika Scrum je zaměřena hlavně na oblast řízení projektu. Vývoj probíhá v 30 denních iteracích nazývaných Sprint, ve kterých se dodává vybraná množina užitných vlastností. Klíčovou praktikou je používání každodenních 15 minutových denních porad (Scrum Meetings) pro koordinaci a integraci prací. Scrum se skládá ze 4 fází jak ukazuje tabulka 3.2. fáze plánovací fáze (planning phase) vynášecí fáze (staging phase) fáze vývoje (development phase) fáze dodávky (release phase) popis specifikují se první požadavky, plán dodávek a architektonická a obchodní vize do souboru požadavků (backlog) jsou připojeny nefunkční požadavky jeden nebo více týmů dodává funkcionalitu s nejvyšší prioritou každých 30 dní, na konci každé iterace tým předvede výsledek předání produktu uživatelům tabulka 3.2: Fáze metodiky Scrum Předmětem první a poslední fáze jsou definované procesy, jsou určeny jejich vstupy, výstupy i procesy transformace. Vyjadřují explicitní znalost a jejich provádění je lineární. Fáze vývoje (Sprint) je naproti tomu empirický proces. Většinu činností v této fázi nelze identifikovat a řídit. Tato fáze je chápána jako černá skříňka, která vyžaduje vnější řízení. Pravidla pro 30 denní Sprint jsou jednoduchá. Členové týmu se zapíší k úkolům, každý pracuje na splnění cíle Sprintu a každý se účastní denních porad. Denní porady (Scrum meetings) představují realizaci principu zlepšení komunikace a zapojení zákazníků. Denní porady mají informační charakter a jsou velmi efektivně řízeny. Umožňují monitorovat stav projektu a zaměřit se na to, co je třeba udělat pro úspěch projektu a jak řešit problémy. Denní porady se konají ve stejný čas na stejném místě trvají maximálně 30 minut (optimálně 15 minut). Porady řídí Scrum Master, účastní se jich všichni členové týmu a navštěvují je manažeři. Na poradách musí každý účastník zodpovědět tři otázky: které položky dokončil od minulé porady, které nové úkoly má řešit, jaká vidí omezení a překážky pro řešení úkolů. Denní porady dovolují týmu sdílet znalosti. Silnou stránkou metodiky Scrum je, že explicitně snižuje chaos při vývoji tím, že stabilizuje úkoly pro 30 denní Sprint. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 50

51 Hodnocení metodiky Scrum je metodika kategorie projektových metodik zaměřená především na řízení projektu. Chápe procesy při vývoji software jako empirické procesy, které není možné předvídat, ale je nutné je monitorovat. K tomu poskytuje praktiky jako denní porady, monitorování Sprintu (30 denní iterace) pomocí Backlog graph a další. Metodika Scrum je popsána jako jazyk vzorů (pattern language). Metapopis metodiky Scrum je uveden v příloze Extrémní programování (XP) Identifikace metodiky a zdrojů Extrémní programování je metodika pro malé až středně velké týmy (2 10 programátorů), které vyvíjejí software a musí se vyrovnat se zadáním, které se rychle mění nebo není jasné. Autory metodiky jsou Kent Beck, Ward Cunningham a Ron Jeffries. Popis metodiky je možné nalézt v [Beck,2002], [Highsmith,2000], [AgileMet] Charakteristika metodiky Extrémní programování vychází z principů a postupů běžných při vývoji software, které však dovádí do extrémů: pokud se osvědčují revize zdrojového textu, budeme kód neustále revidovat (párové programování), jestliže se osvědčuje testování, budou všichni vývojáři neustále testovat (testování jednotek) a testovat budou také zákazníci (testování funkcionality), osvědčuje-li se návrh, zařadíme jej jako každodenní činnost (refaktorizace), pokud se osvědčuje jednoduchost, vždy zvolíme nejjednodušší řešení, které vyhovuje požadovaným funkcím (to nejjednodušší, co ještě může fungovat), jsme-li přesvědčeni o důležitosti architektury, budou ji všichni neustále definovat a rozpracovávat (metafora), jestliže jsme přesvědčeni o důležitosti testování integrace, budeme integrovat a testovat několikrát denně (nepřetržitá integrace), pokud se osvědčují krátké iterace, uděláme je opravdu krátké: vteřiny, minuty a hodiny nikoli týdny, měsíce a roky (plánovací hra). Extrémní programování zdůrazňuje hodnotu společného, jednoduchost, odezvu a odvahu. Důležitými aspekty XP jsou nový pohled na náklady změny, důraz na kvalitu technického řešení jako výsledku refaktorizace a vytváření testů před kódováním Hodnocení metodiky Extrémní programování je velmi lehká metodika, která zavádí specifické praktiky jako párové programování, refaktorizace, testy před kódováním a další. Principy a praktiky se týkají jak oblasti softwarově inženýrské, tak i řízení a organizace. I když jde o nejznámější z agilních metodik, přesto je jejím základem velmi disciplinovaný proces, který není ovšem podrobně popisován, ale je realizován velmi kvalifikovanými a disciplinovanými vývojáři za podpory vývojových nástrojů (pro refaktorizaci a testování). Metodika je vhodná pro malé centralizované týmy. Metapopis metodiky Extrémní programování je uveden v příloze Agilní modelování Identifikace metodiky a zdrojů Agilní modelování (dříve nazývané Extrémní modelování, XM) je metodika založená na praktikách, principech a hodnotách, které jsou odvozeny z hodnot metodiky Extrémní programování. Není to ucelená metodika, ale je to sada principů a praktik věnovaných modelování jako nedílné součásti vývoje software. Agilní modelování tak ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 51

52 může být začleněno jak do tradičních metodik (například RUP), tak do agilních metodik (například Scrum, XP, apod.) Autorem je Scott Ambler. Popis metodiky je možné nalézt v [Ambler,8/2001SD], [Ambler,4/2001SD], [Ambler,AMWP] Charakteristika metodiky Modelování je základní součástí vývoje software jak v tradičních metodikách, tak v agilních metodikách. Modelování je prosazováno standardizačními organizacemi jako OMG a IEEE, výrobci CASE nástrojů a vývojových nástrojů a je součástí většiny metodik. V praxi se ale často neprovádí. Příčinou mohou být tzv. mýty o modelování, jak je formuloval Scott Ambler v [Ambler,8/2001SD]. Velmi častým a dosti nebezpečným mýtem je představa, že modelování je totožné s dokumentací. Vývojáři nechtějí ztrácet čas vytvářením dokumentace, a tak nemodelují a díky tomu produkují systémy nízké kvality. Ve skutečnosti je možné mít modely, které nejsou dokumenty a dokumenty, které nejsou modely. Náčrtky na kusu papíru, obrázky na tabuli, CRC 61 karty, nákresy uživatelského rozhraní, to nejsou dokumenty, ale přesto představují hodnotné modely. Modelování plní podobnou úlohu jako plánování. Při plánování není hodnotou plán samotný, ale proces plánování. Stejně tak při modelování nejde o model jako takový, ale o vlastní proces modelování. Druhý mýtus přeceňuje význam modelů vytvořených předem. Jeho zastánci věří, že je možné namodelovat vše předem a správně. Výsledkem je potom obrovské množství dokumentace místo fungujícího software. Tento mýtus je spojen s běžnou praxí zmrazení požadavků na začátku životního cyklu. To vede k tomu, že dodané systémy neodpovídají skutečným potřebám uživatelů, protože dochází ke změnám prostředí, mění se požadavky uživatelů, mění se priority podnikání a uživatelé teprve po dodávce části systému jej pochopí. Lepší než zmrazit požadavky a riskovat neúspěch je uchopit změnu a odpovědět na ni. Dalším mýtem je zmrazení návrhu. Předpokládá se, že návrh je správný a je třeba se jej držet. Dalším mýtem při modelování je představa, že je nutné používat CASE nástroj, který nejlépe zvládne složité modely. Mnohdy je ale účinnější vytvářet jednoduché modely, které zachycují jen důležité informace místo nepodstatných detailů. O překonání výše uvedených mýtů se snaží Agilní modelování. Principy a praktiky agilního modelování jsou uvedeny v příloze 2 [Ambler,8/2001SD], [Ambler,4/2001SD], [Ambler,AMWP] Hodnocení metodiky Agilní modelování je lehká metodika, která vychází z prověřených modelovacích technik, ale přizpůsobuje je agilním přístupům. Přínosem metodiky Agilní modelování nejsou techniky modelování jako takové, ale to, jakým způsobem jsou aplikovány. Agilní model je takový model, který plní svůj účel, je pochopitelný, je dostatečně přesný, je dostatečně konzistentní, je dostatečně detailní, přináší kladnou hodnotu a je co možná nejjednodušší. Metapopis metodiky Agilní modelování je uveden v příloze Porovnání rigorózních a agilních metodik Rigorózní a agilní metodiky představují dvě skupiny metodik, které vycházejí z odlišných předpokladů a odlišného chápání procesu vývoje software. To má za následek jiný obsah a zaměření těchto metodik a určuje i projekty, na které je vhodné tyto metodiky aplikovat. Tuto skutečnost jsem se pokusila vyjádřit obrázkem 3.7. Podrobné srovnání rigorózních a agilních metodik je uvedeno v příloze 3, kde jsou porovnány obě katedorie cca z 20 různých hledisek. I když jsou východiska, obsah, přístupy i použití rigorózních a agilních metodik na první pohled velmi rozdílné a jejich zastánci vystupují zpravidla antagonisticky, je možné oba přístupy určitým způsobem kombinovat. Rigorózní metodiky je možné odlehčit a aplikovat v jejich rámci některý z agilních přístupů. Velmi zdařilý popis aplikace základních principů agilních metodik v metodice RUP můžeme nalézt v [Kroll]. Dalším příkladem propojování rigorózních a agilních metodik je aplikace metodiky Agilní modelování v RUP, která je 61 Class Responsibility Collaboration - metoda pro zjišťování odpovědností tříd. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 52

53 popsána v [Ambler,2001AM]. Na druhé straně, pokud potřebujeme použít agilní metodiky na větší projekty či projekty s větší důležitostí, je třeba je více formalizovat, zařadit více dokumentace apod. Agilní metodiky jsou v převážné většině zaměřeny na vývoj nového řešení a to jen na úrovni jednoho projektu. V poslední době se objevuje snaha aplikovat agilní přístupy i na úpravy řešení a integraci řešení a stejně tak na některé metodiky patřící do kategorie globálních metodik. 3.4 Shrnutí kapitoly obrázek 3.7: Srovnání rigorózních a agilních metodik V této kapitole byly popsány vybrané světové metodiky v kontextu jejich zařazení mezi rigorózní či agilní metodiky. Jednotlivé metodiky byly stručně charakterizovány a byly popsány jejich klíčové principy a inspirující přístupy. Jednotný popis dle struktury navržené v 2.5 je uveden v příloze 5. Obě skupiny metodik byly porovnány. Hodnocení využitelnosti agilních metodik pro návrh metodického rámce je uvedeno v podkapitole 4.4. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 53

54 4 Zdroje pro návrh metodického rámce Hlavním cílem disertační práce je návrh metodického rámce, který definuje procesy probíhající při vytvoření metodiky pro konkrétní projekt a poskytuje vzory metodik pro typové problémové oblasti a projekty. Tento metodický rámec jsem nazvala MEFIS Methodology Framework for IS/ICT Systems Metodický rámec IS/ICT a podrobně je popsán v kapitole 5 Metodický rámec IS/ICT MEFIS. Na základě analýzy různých metodických přístupů a trendů v oblasti budování IS/ICT 62 jsem vybrala zdroje, ze kterých čerpám při návrhu metodického rámce: metodika MMDIS, referenční modely řízení informatiky, rigorózní metodiky (OPEN, RUP, OOSP, CMM, PSP, TSP), agilní metodiky (Crystal, ASD, FDD, Scrum, Agilní modelování, XP), teorie učící se organizace, teorie komplexních adaptivních systémů, firemní kultura, přístupy zdůrazňující úlohu lidského faktoru, přístupy zdůrazňující úlohu globální architektury IS/ICT, Modelem řízená architektura, Architektura orientovaná na služby. Jednotlivé zdroje jsou v této kapitole charakterizovány. Základním východiskem pro návrh metodického rámce MEFIS je metodika MMDIS. Základní charakteristiku této metodiky obsahuje podkapitola 4.1. Zároveň jsem se pokusila zhodnotit metodiku MMDIS z pohledu současných požadavků na metodiky a navrhnout možné oblasti jejího rozvoje. Některé z nich jsou potom zohledněny v návrhu MEFIS. Metodiky budování IS/ICT musí nutně akcentovat řídící procesy v informatice. Řízením informatiky se zabývají samostatné metodiky, které obsahují modely řízení informatiky. Jedním z těchto modelů je Referenční model MKIT vytvořený Katedře informačních technologií, který charakterizuji v podkapitole 4.2. V kapitole 3 jsem charakterizovala podstatu rigorózních a agilních metodik a podrobněji popsala nejvýznamnější metodiky obou kategorií. V podkapitolách 4.3 a 4.4 hodnotím tyto metodiky z pohledu požadavků na metodický rámec MEFIS. Metodika budování IS/ICT odráží vývoj ve společnosti, ekonomice, řízení, ICT technologiích a dalších oblastech. Může tedy čerpat z nových přístupů, které se v těchto oblastech objevují. Jak zaznělo i na konferenci Systémová integrace 2003 [Chocholatý], mezi nejvýznamnější teorie, které v posledních letech ovlivnily vývoj v různých oblastech patří teorie učící se organizace (podkapitola 4.5), teorie komplexních adaptivních systémů (podkapitola 4.6) a výzkumy v oblasti firemní kultury (podkapitola 4.7). Z trendů v oblasti metodických přístupů, které by měla současná metodika akcentovat, považuji za významnou zejména iniciativu Modelem řízená architektura (Model Driven Architecture) a Architektura orientovaná na služby (Service Oriented Architecture). Tyto přístupy jsou také blíže charakterizovány v podkapitolách 4.10 Modelem řízená architektura a Architektura orientovaná na služby. 62 Některé závěry analýzy jsou shrnuty v kapitolách 2 a 3. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 54

55 4.1 MMDIS Metodika MMDIS (Multidimensional Management and Development of Information System) je od roku 1992 vyvíjena na Katedře informačních technologií VŠE v Praze 63. Dle kategorizace uvedené v podkapitole 2.4 Kategorizace metodik ji můžeme zařadit mezi globální metodiky, protože pokrývá všechny fáze životního cyklu, všechny dimenze a různé role. V dnešní době bychom ji mohli označit jako lehkou či agilní metodiku, protože nepředepisuje detailně jednotlivé kroky budování IS/ICT, resp. jednotlivé kroky při realizaci projektu, ale je především návodem na způsob uvažování. V tom spočívá velká aktuálnost metodiky i přes její více než desetiletou existenci. Zároveň MMDIS zdůrazňuje specifika každého projektu a nutnost přizpůsobení metodiky. Zaměření metodiky na celou organizaci s sebou nutně přináší i důraz na architekturu budovaného IS/ICT a systémovou integraci. Vybudovat IS/ICT nelze dle MMDIS na základě preference jednoho hlediska tvorby a provozu IS/ICT (např. datového, funkčního, hardwarového, organizačního apod.), ale je třeba uvažovat současně více hledisek. Proto je charakteristickým rysem metodiky MMDIS multidimenzionalita, tj. řešení IS/ICT souběžně ze všech pohledů, které ovlivňují efektivitu IS/ICT. MMDIS rozlišuje dvě základní skupiny dimenzí vývoje IS/ICT [Voříšek,1997]: 1. první skupina dimenzí reprezentuje úrovně integrace IS/ICT, použitou úroveň abstrakce a časovou dimenzi řešení. Tato skupina dimenzí se v MMDIS promítá do jednotlivých fází vývoje IS/ICT (Globální strategie, Informační strategie, Úvodní studie, atd.), 2. druhá skupina dimenzí zahrnuje ty dimenze IS/ICT, které se aplikují v každé fázi vývoje IS/ICT a které představují různé pohledy na vyvíjený systém i samotný proces vývoje. Jedná se o tyto obsahové dimenze IS/ICT : informační/datová (inf), procesní/funkční (pro), ekonomická/finanční (eko), organizační/legislativní (org), pracovní/sociální/etická (pra), softwarová (sw), hardwarová (hw), metodická (met), dokumentační (dok) a manažerská (mng) Fáze vývoje IS/ICT Metodika MMDIS definuje 8 fází životního cyklu informačního systému. Úvodní dvě fáze reprezentují strategickou úroveň řízení IS/ICT. Východiskem pro návrh IS/ICT je Globální strategie (GST), která určuje hlavní směry a priority rozvoje organizace. Na tuto fázi navazuje Informační strategie (IST), jejímž cílem je navrhnout celkovou koncepci IS/ICT organizace tak, aby byly optimálně podpořeny celopodnikové cíle definované v GST, a navrhnout jednotlivé kroky realizace této koncepce jednotlivé projekty. Projekty, které byly definovány ve fázi Informační strategie, se obvykle realizují v šesti fázích: Úvodní studie, Globální analýza a návrh, Detailní analýza a návrh, Implementace, Zavádění, Provoz a údržba. Úvodní studie (UST), nazývaná též studie proveditelnosti, je zaměřena na detailní posouzení realizovatelnosti požadavků na projekt a na variantní návrh koncepce řešení projektu. Globální analýza a návrh (GAN) vychází z koncepce stanovené v Úvodní studii a vymezuje projektovaný systém na konceptuální úrovni, tj. úrovni nezávislé na implementačním prostředí aplikace a technologické platformě. Detailní analýza a návrh (DAN) transformuje konceptuální úroveň návrhu do technologické, která závisí na zvoleném implementačním a provozním prostředí aplikace. Náplní Implementace (IMP) je transformace technologické úrovně návrhu do implementační úrovně, tj. například realizace fyzického návrhu databáze v konkrétním SŘBD, implementace v určeném implementačním prostředí, testování jednotlivých programových modulů, testování celého programového systému a kompletace dokumentace. Ve fázi Zavádění (ZAV) se instaluje systém, transformuje se datová základna, školí se uživatelé aplikace a realizuje se zkušební provoz aplikace. Úspěšné završení fáze zavádění končí akceptací a uzavřením projektu vývoje. Provoz a údržba (PUR) 63 viz [Voříšek,1992], [Voříšek,1997], [Dohnal,Pour,1999], [Novotný,2003] ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 55

56 P2 P2 NÁVRH METODICKÉHO RÁMCE IS/ICT je fází, která je již mimo projekt vývoje, ve které je aplikace provozována a ve které jsou dosahovány přínosy, z důvodu kterých byl projekt v informační strategii navržen a v předcházejících fázích realizován Konceptuální model MMDIS Jestliže IS/ICT má mít všechny atributy konzistentního a integrovaného IS/ICT, pak při jeho tvorbě je třeba respektovat všechny výše popsané dimenze. Metodika MMDIS proto kombinuje ve svém konceptuálním modelu obě skupiny řešitelských dimenzí viz obrázek 4.1. Z konceptuálního modelu řešení IS/ICT vyplývá další charakteristická vlastnost metodiky MMDIS v každé fázi řešení je informační systém analyzován a navrhován z hlediska všech dimenzí a jejich vzájemných vazeb. Fáze se liší pouze úrovní podrobnosti analýzy a návrhu. Klasické metodiky zahrnují řešení informační, procesní, softwarové a hardwarové dimenze, ale obvykle nepostihují v plné míře dimenzi organizační, pracovní a ekonomickou. Současně je třeba si uvědomit že váha, resp. významnost určité dimenze se v jednotlivých fázích mění. Například organizační a ekonomická dimenze mají podstatně větší váhu v úvodních fázích (GST, IST, UST), zatímco softwarová a hardwarová dimenze mají naopak větší váhu v závěrečných fázích (GAN, DAN, IMP) řešení IS/ICT. Jednotlivé fáze vývoje IS/ICT určují základní kroky postupu řešení IS/ICT. Metodika MMDIS dále doporučuje rámcový postup v jednotlivých fázích řešení IS/ICT. GST IST MtS US GAN DAN n PROJEKTU (některé z nich v provozu) IM ZA mng dok P Pn P1 met Pn hw PU provozovaný IS inf sw pro eko org pra obrázek 4.1: MMDIS třírozměrné schéma konceptuálního modelu zdroj [Voříšek,1997] ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 56

57 4.1.3 Zhodnocení metodiky MMDIS a návrh jejího rozšíření Podíváme-li se na metodiku MMDIS z pohledu současné úrovně informačních technologií a nejnovějších metodických přístupů, můžeme ji hodnotit velmi kladně. Základní principy, na kterých je metodika MMDIS postavena, zůstávají i přes více než desetiletou dobu její existence platné. Multidimenzionální pohled na budovaný systém je i v současnosti vhodným nástrojem, jak zajistit komplexnost a integritu řešení, a je málo metodik, které jej explicitně zdůrazňují. Globální zaměření metodiky na celou organizaci, důraz na architekturu celého IS/ICT a jeho integraci, spojení IS/ICT s podnikovými procesy v organizaci, tyto principy MMDIS plně odpovídají nejnovějším požadavkům na metodiky. Také princip tří architektur, který MMDIS deklaruje, tedy oddělení analytického (konceptuálního) pohledu od pohledu návrhu a implementace plně odpovídá myšlence, na které je postavena iniciativa organizace OMG Modelem řízená architektura (Model Driven Architecture). I když základní principy metodiky MMDIS jsou nadále platné, je třeba tuto metodiku dále rozvíjet. Jako možné oblasti rozvoje metodiky MMDIS vidím následující: rozpracovat metodiku v kontextu Modelem řízené architektury (MDA), provést mapování jednotlivých fází na modely MDA, rozpracovat detailní postupy pro objektově orientovaný, komponentový vývoj a vývoj orientovaný na služby, definovat kritéria pro vytváření instance metodiky pro konkrétní projekt, zapojit do MMDIS myšlenky agilních metodik, navázat metodiku na postupy hodnocení softwarových procesů (například CMM), rozpracovat metodické postupy specifické pro jednotlivé předmětné oblasti, definovat metamodel metodiky, vytvořit aplikaci na udržování metodiky, její prezentaci a podporu vytvoření konkrétní instance Některé z výše uvedených oblastí rozvoje jsem se pokusila řešit v návrhu metodického rámce MEFIS (kapitola 5 Metodický rámec IS/ICT MEFIS). 4.2 Modely řízení informatiky Význam pojmu podniková informatika byl vysvětlen v podkapitole 2.1 Součásti podnikové informatiky. Řízení podnikové informatiky se zabývá řízením jednotlivých dílčích částí 64 i jejich vzájemných vazeb a pokud má být efektivní, mělo by využívat model řízení podnikové informatiky. Prvky, které jsou součástí modelu řízení podnikové informatiky, jsou charakterizovány v [Novotný,2003]. Protože naplnění celého modelu řízení informatiky je velmi náročné, byly vytvořeny určité předlohy, které již obsahují typické konfigurace řešení jednotlivých částí systému řízení podnikové informatiky. Tyto předlohy jsou označovány jako referenční modely řízení informatiky a k nejznámějším ve světě patří modely CMMI, COBIT a ITIL. Model CMMI, respektive jeho součást SW CMM, byl popsán v podkapitole Capability Maturity Model for Software (SW-CMM). Referenční model COBIT (Control Objectives for Information and Related Technology) se skládá z modelu procesů, ke kterým jsou připojeny metriky jejich efektivnosti, a umožňuje tak hodnocení úrovně provádění procesů informatiky. ITIL (IT Infrastructure Library) je rozsáhlý soubor postupů řízení podnikové informatiky prostřednictvím služeb vydaný britskou vládní agenturou Central Computer and Telecommunications Agency (CCTA), která je součástí Office of Government Commerce (OGC). Bližší rozbor i srovnání těchto referenčních modelů je možné nalézt v [Novotný,2003]. 64 jednotlivých procesů, služeb, zdrojů ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 57

58 Kromě výše uvedených světových referenčních modelů řízení informatiky je k dispozici také Referenční model MKIT, který byl vytvořen na Katedře informačních technologií VŠE v Praze. Teoretický rámec modelu MKIT vznikl již v roce 1995, v letech byl model přepracován do současné podoby. Referenční model MKIT se skládá z modelu procesů podnikové informatiky (procesy strategického, taktického a operativního řízení), systému evidence zdrojů podnikové informatiky a katalogu služeb podnikové informatiky. Všechny tyto části jsou propojeny do strukturovaného referenčního modelu řízení podnikové informatiky (blíže viz [Novotný,2003]). Jak bylo uvedeno v podkapitole 2.1 Součásti podnikové informatiky, oblast budování IS/ICT je částí podnikové informatiky, a její řízení je předmětem modelu MKIT. Tím je určena těsná vazba mezi Referenčním modelem MKIT a Metodickým rámcem IS/ICT, jehož návrh je hlavním cílem této disertační práce. Tato vazba se projevuje tím, že Metodický rámec IS/ICT v sobě integruje jak oblast softwarového inženýrství, tak oblast řízení. Na obrázku 4.2 je zachycena architektura řízení IS/ICT dle MKIT, která znázorňuje hlavní funkční domény řízení IS/ICT. Řízení systémových vlastností (3) Rozvoj služeb a organizace (4) Řízení disponibility (1) Strategické řízení IS/IT Taktické řízení IS/IT (2) Zadávání, plánování a koordinace projektů IS/IT - řízení aplikací Řízení zdrojů IS/IT (5) Řízení ekonomiky - finančních zdrojů (5) Řízení personálních zdrojů v IS/IT (6) Řízení datových zdrojů (7) Řízení technologických zdrojů (ZSW, HW, komunikace) Business Intelligence Externí vazby C R M Marketing Řízení produktu (8) Řízení jednotlivých projektů Operativní řízení IS/IT (9) Řízení provozu IS/IT a správa sítě Ekonomika obrázek 4.2: Celková architektura řízení IS/ICT zdroj [Dohnal,Pour,1999] Metodický rámec se zaměřuje zejména na oblasti: 1. Strategické řízení IS/IT 2. Zadávání a koordinace projektů IS/IT 8. Řízení projektů. 4.3 Zhodnocení rigorózních metodik z pohledu návrhu metodického rámce V podkapitole 3.1 Rigorózní metodiky byly popsány některé významné současné metodiky zařazované do kategorie rigorózních metodik. V této podkapitole jsou zhodnoceny tři nejvýznamnější rigorózní metodiky z pohledu jejich využití pro návrh metodického rámce. Metodiky CMM, OPEN či RUP jsou velmi podrobné a mohlo by se zdát, že dostatečně popisují problematiku budování IS/ICT. Ale cíl, který jsme si určili pro ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 58

59 metodický rámec, je mnohem komplexnější a žádná z těchto metodik jej nepokrývá plně. Některé principy těchto metodik však byly inspirací pro návrh metodického rámce, ale jsou zařazeny do nového rámce. Model zralosti SW (Capability Maturity Model for Software, SW CMM), který byl popsán v podkapitole je na rozdíl od metodik RUP a OPEN zaměřen na procesy v rámci celé organizace a dle kategorizace metodik uvedené v podkapitole 2.4 jej můžeme tedy zařadit mezi globální metodiky. Z hlediska MEFIS je zajímavý princip definování standardního softwarového procesu pro organizaci a jeho přizpůsobování na jednotlivé projekty. CMM však nedefinuje kritéria tohoto přizpůsobování ani nerozlišuje specifika vývoje pro jednotlivé domény a různé typy vývoje. Metodika Rational Unified Process (RUP) je velmi kvalitní, ověřená metodika zaměřená na objektově orientovaný a komponentový vývoj aplikací. Z hlediska možností jejího využití pro návrh metodické rámce má však následující omezení: zaměřuje se na procesy jen v rámci jednoho projektu nikoli na procesy v rámci celé organizace, zaměřuje se pouze na nový vývoj software (zejména objektově orientovaný), nezabývá se rozvojem řešení, integrací aplikací ani implementací typového aplikačního programového vybavení, nerozlišuje domény a jejich specifika, v kontextu současných přístupů se nezaměřuje explicitně na služby, zdůrazňuje sice nutnost přizpůsobení na podmínky organizace a projektu, ale tyto procesy nejsou explicitně popsány. Metodika OPEN a OPEN Process Framework (OPF) jsou postaveny na podobných principech jako navrhovaný metodický rámec 65. OPF definuje principy odvození konkrétní metodiky z knihovny metodických prvků. Metodika OPEN je však opět zaměřena jen na úroveň projektu, ne na celou organizaci, zabývá se jen vývojem nového řešení, nezabývá se zvláštnostmi vývoje v jednotlivých doménách a není zaměřena explicitně na služby Zhodnocení agilních metodik z pohledu návrhu metodického rámce V podkapitole 3.2 Agilní metodiky byly popsány společné principy agilních metodik a jednotlivé metodiky této kategorie. Agilní metodiky se začínají v současnosti prosazovat a mají významné úspěchy, ale je třeba si uvědomit, že jsou vhodné jen pro určité typy projektů. Nemohou tedy obsáhnout celou oblast, která je předmětem řešení v metodickém rámci. V podstatě všechny tyto metodiky jsou zaměřeny pouze na úroveň projektu 67 a nepostihují procesy probíhající na úrovni celé organizace. Většina těchto metodik 68 se také distancuje od používání nástrojů pro modelování a dalších nástrojů podporujících proces vývoje, což je nyní i předmětem jejich kritiky [Orr]. Mnohé myšlenky agilních metodik jsou ale přínosné a je vhodné je v návrhu metodického rámce využít. Jde zejména o zaměření na principy a praktiky, pouze lehké procesy, principy a praktiky metodiky Agilní modelování, refaktorizace, zaměření na lidi a přímou komunikaci, účelnost dokumentace a další. 4.5 Učící se organizace Pojem učící se organizace je velice široký a může být vykládán různě. Nejčastěji představuje flexibilní organizace, které jsou charakterizovány rychlou reakcí a adaptací na změnu. Dee Hock nazval takovou organizaci 65 byť vznikaly nezávisle 66 viz metapopis metodiky OPEN uvedený v příloze 5, 67 patří tedy do kategorie projektových metodik 68 s výjimkou metodiky FDD ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 59

60 chaordickou, jelikož spojuje chaos a pořádek a z chaosu vytváří řád. [Gibson] Učící se organizaci charakterizuje Peter Senge:... organizations where people continually expand their capacity to create the results they truly desire, where new and expansive patterns of thinking are nurtured, where collective aspiration is set free, and where people are continually learning to see the whole together [Gibson], [Senge]. Teorie učící se organizace rozlišuje mezi individuálními znalostmi jednotlivců a znalostmi vlastněnými skupinou. Individuální učení vede k individuálním znalostem, učení organizace vede ke kolektivním znalostem. Mezi těmito dvěma skupinami vlastností vzniká konflikt, který je ale považován za pozitivní prvek, který podporuje inovaci a kreativitu. Všechny fáze učení mají charakter samoorganizování a nelze je jednoduše řídit. Komunity sehrávají základní roli při vývoji a sdílení kolektivních znalostí organizace. Klíčovými prvky učící se organizace jsou její intelektuální rozmanitost a existence vhodné firemní kultury. Moderní metodiky se snaží zapojit učení jako základní prvek zajišťující aplikaci metodiky a její kontinuální rozvoj. 4.6 Teorie komplexních adaptivních systémů Teorie komplexních adaptivních systémů se zabývá studiem samovzniku uspořádaného chování v neuspořádaných systémech. Výsledky zkoumání komplexních systémů ukazují, že nejvíce tvořivé fáze systému leží někde mezi pořádkem a chaosem, na hraně chaosu. Systémy operující v blízkosti této hrany vykazují velkou tvořivost a produkují nové způsoby chování, které se následně rozšíří do celého systému [Mařík]. Komplexní systémy jsou otevřené a mají silnou zpětnou vazbu. Znalosti podle teorie komplexních adaptivních systémů mohou být reprezentovány jako pravidla, jimiž se jednotliví agenti systému řídí ve svém neustálém hledání způsobů, jak se úspěšně přizpůsobovat měnícímu se prostředí [Highsmith,2002]. 4.7 Firemní kultura Firemní kultura se v poslední době stává předmětem výzkumů a námětem řady publikací například [Mullins]. Firemní kultura představuje soubor hodnot, přesvědčení návyků, paradigmat, rituálů, strategických cílů, které určují způsob každodenního chování všech pracovníků společnosti. Firemní kultura se projevuje jednáním, které všichni podvědomě prosazují. Souvisí tak s implicitními hodnotami sdílenými skupinou lidí s hodnotami, které určují, co je důležité, co je dobré a co je správné. Firemní kultura se týká skupinových hodnot. Je třeba se zabývat i jednotlivci, neboť v současnosti se mění úloha lidí v pracovním procesu. V podkapitole 4.8 Lidský faktor uvádím některé myšlenky zabývající se lidským faktorem. Podle Moore existují 4 základní typy firemní kultury, které jsou charakterizovány v tabulce 4.1 [Highsmith,2002]. Druh firemní kultury kultura kompetence kultura spolupráce kultura kontroly kultura kultivace význam příklady organizací zaměřuje se na vykonání práce, na kvalifikaci, individuální odpovědnost Microsoft vyzdvihuje komunikaci a spolupráci Hewlett-Packard důraz na pořádek a předvídatelnost, přesné postupy, kontroly IBM podnikavá přirozenost start up společnosti v Silicon Valley tabulka 4.1: Typy firemní kultury Firemní kultura je důležitým faktorem ovlivňujícím výběr vhodné metodiky budování IS/ICT. V metodickém rámci se projevuje při přizpůsobení metodického rámce na podmínky organizace tak, jak je popsáno v podkapitole Customizace metodického rámce pro organizaci. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 60

61 4.8 Lidský faktor V dobách průmyslové revoluce plnili lidé roli zaměnitelné součástky v přesně popsaných a vykonávaných výrobních postupech. Tomuto způsobu práce odpovídalo i přísné direktivní řízení. Současná doba však vyžaduje novou roli lidí. Jak říká Stephen Covey: Chcete-li dosáhnout obrovského zvýšení výkonnosti lidí, musíte zásadně změnit svůj způsob pohledu na lidi. Musíte věřit, že lidé jsou nejcennějšími aktivy organizace a být přesvědčeni, že jsou schopni neuvěřitelných výkonů. Musíte lidem pomoci, aby v tom, co dělají nalezli smysl a naplnění. Lidé nechtějí být organizací využíváni, chtějí být správci svých vlastních zdrojů, chtějí mít pocit, že osobně přispívají k něčemu, co má nějaký smysl. A právě v takových podmínkách se dostaví skutečná motivace a skutečné naplnění. [Gibson] Úloha lidí se tedy mění, roste význam znalostí a kvalifikace lidí. Tato změna souvisí s prosazováním procesních přístupů, které vyžadují složité pracovní funkce vykonávané kvalifikovanými jedinci. Tato skutečnost se projevuje v celé společnosti. Pro budování IS/ICT platí dvojnásob. Bohužel většina metodik budování IS/ICT tento fakt nezohledňuje. Význam lidí při vývoji software zdůrazňují agilní metodiky zejména pak Alistair Cockburn. V řadě článků 69 se A. Cockburn zabývá vlastnostmi lidí, které by měly metodiky vývoje software zohlednit. Příklady těchto vlastností uvádí tabulka 4.2. obecné charakteristiky lidé se navzájem liší lidé dobře pracují podle příkladů, vzorů lidé jednají podle odměny osobní profil člověka silně ovlivňuje schopnost vykonávat určité činnosti silné stránky lidí + lidé mají schopnost dívat se kolem, + lidé mají iniciativu + lidé dělají, co je třeba, i když to proces neříká + lidé mají schopnost komunikovat slabé stránky lidé mají potíže chovat se konzistentně lidé dávají přednost konzervativnímu chování před novými přístupy lidé jsou schopni uchovat jen omezený objem informací lidé mají potíže s dodržováním disciplíny lidé dělají chyby tabulka 4.2: Silné a slabé lidské vlastnosti Vlastnosti uvedené v tabulce 4.2 je třeba využít při návrhu metodiky 70. Důležité je umožnit lidem osobní komunikaci a poskytnout jim dostatek času na přemýšlení. Slabé stránky lidí, zejména potíže s konzistentním chováním vysvětlují, proč přesné a podrobné metodiky nevedou k dobrým a stejným výsledkům. Lidé mohou dělat věci opakovaně, ale nikdy ne úplně stejně. Definováním procesů krok po kroku předpokládáme, že ze stejných vstupů získáme stejný výstup. Ale reakce lidí se mohou lišit a to z nejrůznějších důvodů, které často vůbec nesouvisí s vykonávanou činností. Poznatek, že lidé dobře pracují podle příkladů a vzorů není doposud v metodikách dostatečně zohledněn 71. Dokumentace založená na příkladech také zatím není běžnou součástí 69 například [Cockburn,HF] 70 například omezení psané dokumentace ve prospěch přímé komunikace 71 Jde o použití takových technik jako CRC karty, případy užití (use case), náčrtky uživatelského rozhraní, které jsou lidem blízké a rozumějí jim. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 61

62 metodik. Metodiky by se měly zaměřit na procesy, které zohledňují fakt, že lidé dělají chyby a že preferují chovat se konzervativně Komunikace Budování IS/ICT je složitý proces, ve kterém rozhodující úlohu hraje komunikace mezi členy týmu, s vedením, zákazníky a sponzory. Komunikace je složitá a nikdy není perfektní a kompletní. Její složitost spočívá v tom, že příjemce musí překonat mezeru mezi svým myšlenkovým zázemím, svými zkušenostmi a znalostmi a myšlenkovým zázemím nositele sdělení. Nositel sdělení vysvětlí základní koncept a potom čeká, až si příjemce sdělení vybuduje na základě své zkušenosti most, který překlene uvedenou mezeru. Pokud komunikace probíhá mezi lidmi se stejným znalostním zázemím, stačí pár vět a vše je jasné. Komunikace tak velmi závisí na sdílené zkušenosti. Tradiční metodiky však požadují především písemnou dokumentaci. Tvůrce takové dokumentace neví přesně, pro koho je určena, jaké má její příjemce znalostní zázemí a jak podrobná tedy dokumentace musí být. A.Cockburn specifikuje 5 forem komunikace a uvádí jejich efektivnost (obrázek 4.3). Nejefektivnější je osobní komunikace dvou lidí, která má tyto charakteristiky: fyzická blízkost (vizuální podněty, timing, 3dimenzionalita, vůně), různé způsoby komunikace (gesta, slova, mimika), hlasové zabarvení a načasování, otázky a odpovědi v reálném čase, otázky signalizují nedostatečné vysvětlení nebo místo, kde chybí zázemí posluchače Cockburn ukazuje, co se stane, když odstraníme tyto charakteristiky komunikace, jednu po druhé. Odstraníme-li fyzickou blízkost, můžeme využít například komunikace přes videokonferenci. Odstraníme-li gesta, ale ponecháme hlasové charakteristiky, můžeme použít telefon. Odstraníme-li časování a hlasové charakteristiky, ale ponecháme možnost klást otázky, získáme komunikaci přes elektronickou poštu. Odstraníme-li možnost klást otázky a odpovídat, dostaneme se k videozáznamům a audiozáznamům. Nakonec po odstranění všech výhod osobní komunikace nám zůstává papír. Vidíme tedy, že písemná komunikace je tou nejméně efektivní formou komunikace, přesto je právě v metodikách budování IS/ICT velmi často požadována jako základní nástroj komunikace. Snahou metodik tedy musí být posun komunikace v týmu směrem k efektivnějším formám. Důležité je také rozlišovat mezi dokumentací a pochopením. Účelem dokumentace je komunikace a pochopení daného problému. Tuto úlohu může mnohem efektivněji splnit přímá komunikace mezi lidmi. Pokud není přímá komunikace možná, je třeba využít dalších forem, které se dnes již začínají při budování IS/ICT prosazovat jako videozáznamy, videokonference apod. Důležité je podporovat komunikaci všemi dostupnými prostředky, zkvalitňovat komunikační kanály, využívat různé formy komunikace, využívat vizualizace, zrychlovat komunikaci a dbát na její obsah. 4.9 Architektura IS/ICT V současném vysoce konkurenčním prostředí představuje IS/ICT rozhodující faktor, který ovlivňuje úspěšnost organizací. Jde o to, aby IS/ICT plně podporoval podnikové procesy a pomáhal realizovat jejich potenciál [Helland,6/2003]. Aby to bylo možné, je třeba vytvořit: integrovanou a interoperabilní platformu, která bude podporovat vývoj, nasazení, provoz a eventuelně odstranění jednotlivých softwarových prvků a jejich integraci s ostatními, architekturu IS/ICT, která bude umožňovat spojování prvků do celku. 72 jsou to procesy řízení rizik, iterativní vývoj, inkrementální vývoj. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 62

63 obrázek 4.3: Formy komunikace podle [Cockburn,MetSpace] Architektura IS/ICT představuje významný faktor úspěšného IS/ICT. Význam architektury IS/ICT bývá odvozován od role architektury ve stavebnictví a urbanistice. Chápání architektur se v mnohých publikacích liší. Vycházím z metodiky MMDIS, která rozlišuje dvě úrovně architektur IS/ICT globální architekturu a dílčí architektury. Globální architektura je hrubým návrhem celého IS/ICT. Dílčí architektury jsou pak detailnějšími návrhy IS/ICT z hlediska různých dimenzí. Jedná se o tyto dílčí architektury dle [Voříšek,1997] : funkční architektura, která je návrhem hierarchie funkcí systému, procesní architektura, která je návrhem procesů v podniku, datová architektura, která je návrhem datové základny, technologická architektura rozhoduje o technologickém řešení, softwarová architektura určuje, z jakých softwarových modulů (komponent, objektů) bude informační systém postaven a jaké budou jejich vazby, hardwarová architektura určuje typy, počty a vzájemné vazby hardwarových komponent. S rostoucím významem služeb v rámci IS/ICT bychom měli přidat i architekturu služeb. Výše uvedený přístup poměrně přesně odděluje jednotlivé dílčí architektury. Je ovšem zřejmé, že se jednotlivé dílčí architektury navzájem ovlivňují. Někdy se setkáme s chápáním architektury programových systémů jako s propojením softwarové a technologické architektury ve výše uvedeném smyslu. Globální architektura (Enterprise architecture) zachycuje strukturu a procesy na úrovni celé organizace. Model globální architektury je reprezentací těchto struktur a procesů. Dobrý architektonický model zachycuje organizaci z různých pohledů a akcentuje i změny v budoucnu. Přínos vytváření globální architektury spočívá ve vyšší kvalitě výsledného řešení, větší rychlosti řešení a menších nákladech. Tím, že vytvoříme globální architekturu IS/ICT, umožníme vývojářům vytvářet systémy, které pracují navzájem konzistentně a efektivně. Systém také mnohem lépe odpovídá potřebám, protože vývojáři pracují se znalostí obecných obchodních vizí a celkové infrastruktury. Výsledná řešení jsou rychlejší, protože důležitá rozhodnutí již byla realizována, byla vytvořena celková infrastruktura pro komunikaci, sdílení zdrojů apod. Globální architektura explicitně ukazuje, jakou funkcionalitu a jaká data je možné znovupoužít v rámci organizace. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 63

64 Výhody vytváření globální architektury jsou zřejmé, přesto se v praxi setkáváme s řadou problémů, které pramení z neexistence řízení budování IS/ICT v rámci celé organizace. Řídí se jen jednotlivé projekty, projektové týmy neznají globální architekturu, nepracují s architekty, nemají v týmu nikoho, kdo by je s architekturou seznámil. Když už architektura existuje, bývá často zastaralá nebo úzce zaměřená, často se za architektonický model vydává jen datový model. Architektura bývá většinou prezentována ve formě modelů. Pro modelování architektury systému lze použít různé techniky, jejichž přednosti a nedostatky jsou uvedeny v příloze 4: standardní modelovací jazyk Unified Modeling Language (UML), Model Driven Architecture, Zachman Framework, metodiky jako Enterprise Unified Process (EUP). V současnosti se při návrhu architektury uplatňují také vzory. Architektonické vzory vyjadřují základní strukturální schéma uspořádání softwarových systémů, poskytují množinu předdefinovaných subsystémů, specifikují odpovědnosti, zahrnují pravidla pro uspořádání vztahů mezi nimi. Vzory poskytují mocný slovník pro komunikaci mezi architekty a návrháři. Znalost a pochopení vzoru přenáší znalost a zkušenost, která je ve vzoru obsažena. [MSESP]. Pro analýzu a návrh architektury softwarového systému je možné použít také metody, které definoval Institut softwarového inženýrství (SEI): Architecture Tradeoff Analysis Method SM (ATAM), Quality Attribute Workshop (QAW), Attribute Driven Design (ADD). Tyto metody jsou založeny na myšlence, že pro architekturu software jsou určující kvalitativní požadavky (jako výkon, bezpečnost, modifikovatelnost, spolehlivost a použitelnost). Návrh architektury spočívá v aplikaci tzv. architektonických taktik. Architektonická taktika reprezentuje návrhové rozhodnutí, které umožňuje dosáhnout určité hodnoty atributu kvality. V technické zprávě [Bachmann,2002] je popsána analýza taktik pro atribut kvality modifikovatelnost při vývoji. Snahou je stanovit, jaký bude čas a náklady nutné na provedení určité změny. Každému modulu je přiřazena jeho váha, která odráží relativní obtížnost jeho modifikace. např. modul, který je snadné změnit bude mít váhu 1, obtížně měnitelný modul bude mít váhu 5. Součet vah všech modulů, které musí být změněny z důvodu implementace změny určuje vliv změny. V současnosti jsou v oblasti architektur dominující dva trendy. Modelem řízená architektura (Model Driven Architecture) a Architektura orientovaná na služby (Service Oriented Architecture), které podrobněji charakterizuji v následujících podkapitolách Modelem řízená architektura Myšlenky, na kterých je založena Modelem řízená architektura (Model Driven Architecture, MDA) nejsou nijak nové. Možnost oprostit se od technologických problémů a zaměřit se na věcné problémy s sebou přinesl už vznik jazyka Cobol a rozvoj strukturovaných metod v 60. letech 20.století. Je příznačné, že myšlenky oddělení analytického (konceptuálního) pohledu od pohledu návrhu a implementace jsou jedním ze stěžejních principů 73 metodiky MMDIS. 73 Princip tří architektur ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 64

65 Myšlenka MDA vychází ze skutečnosti, že množství změn v systému klesá, postupujeme-li na vyšší úrovně abstrakce. Dopady neustálých změn v oblasti technologií je možné omezit jen na část modelu na jeho nižší vrstvy, zatímco Platformově nezávislý model (Platform Independent Model PIM) zůstane nezměněn. Při MDA vývoji se nejprve vytvoří Platformově nezávislý model, který reprezentuje věcnou funkcionalitu a chování systému. Pomocí MDA nástrojů se provádí mapování na zvolenou platformu a generování Platformově specifického modelu (Platform Specific Model PSM). Z jednoho Platformově nezávislého modelu je možné provést mapování do různých technologií 74. Nakonec se generuje implementační kód pro příslušnou technologii. MDA nástroje umožňují také zpětné inženýrství (reverse engineering), a tak je možné vytvořit modely stávajících systémů, které je potom možné integrovat do nových platforem. V tomto smyslu představuje MDA nový pohled na integraci podnikových aplikací a je jedním z nástrojů pro její realizaci. Součástí MDA generátorů jsou i návrhové vzory, které tak lze v řešení automatizovaně aplikovat. Na obrázku 4.4 je znázorněna hierarchie modelů používaných v rámci MDA. Modely vyznačené výplní představují konkrétní modely, které se při vývoji dle MDA vytvářejí. Ostatní modely jsou abstraktní a představují pouze logické členění. Obchodní model (Business Model) popisuje věcné aspekty dané problémové oblasti bez ohledu na to, zda budou automatizovány, Model systému (System Model) pak popisuje počítačový systém. Logický model (Logical Model) zachycuje logiku systému prostřednictvím modelu tříd a modelu chování, zatímco Fyzický model (Physical Model) popisuje fyzické artefakty a zdroje používané při vývoji a provozu soubory s modely, soubory zdrojového kódu, spustitelné soubory, archivní soubory. Model požadavků (Requirements Model) popisuje počítačový systém z uživatelského pohledu a nebere v úvahu technologické aspekty řešení, zatímco Výpočetní model (Computational Model) popisuje počítačový systém včetně technologických aspektů řešení. Klíčovou úlohu v MDA plní Platformově nezávislý model (Platform Independent Model, PIM) a Platformově specifický model (Platform Specific Model, PSM). PIM představuje konceptuální model dané problémové oblasti, který je nezávislý na platformě. Platformou se rozumí určitý jazyk, technologie middleware a jim odpovídající inženýrské přístupy. Při mapování PIM na určitou platformu vznikají nejen artefakty příslušné platformy 75, ale také Platformově specifický model, který mnohem lépe zachytí sémantiku řešení pro specifickou platformu. obrázek 4.4: Taxonomie modelů v MDA podle [Frankel] 74 například Corba, Java/EJB, XML/SOAP 75 například Interface Definition Language( IDL) ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 65

66 Platformově specifický model reprezentuje jak věcnou, tak technologickou sémantiku aplikace. Je to stále UML 76 model, ale vyjádřený v dialektu UML, který se označuje UML profil. UML profil odráží technologické prvky cílové platformy [Frankel]. MDA zahrnuje následující standardy OMG týkající se modelování: XML metadata Interchange (XMI), Unified Modeling Language (UML), Common Warehouse Metamodel (CWM), Meta Object Facility (MOF), Základem MDA je modelovací jazyk UML Unified Modeling Language. UML je grafická notace pro modelování, standard definovaný organizací OMG již v roce Silná stránka UML spočívá v jeho metamodelu a v možnosti převodu modelů do XML na základě standardu XMI. UML není jeden jazyk, ale základ pro rodinu jazyků. UML obsahuje vestavěný mechanismus pro rozšíření 77, který umožňuje definovat a používat dodatečné modelovací konstrukty a vytvářet tak dialekty UML nazývané UML profily. UML profil představuje definovanou množinu stereotypů a připojených hodnot, které rozšiřují elementy UML metamodelu a je základem pro tvorbu platformově specifických modelů. K dispozici jsou například následující UML profily: UML profile for Corba defnuje mapování z PIM do PSM pro technologii CORBA, UML profile for EDOC jazyk pro modelování spolupráce komponent a podnikových procesů nezávislý na middleware, definuje Enterprise Collaboration Architecture a mapování z PIM do webových služeb, UML profile for EAI profil pro systémy komunikující pomocí zpráv. Meta Object Facility (MOF) je jazyk pro vyjádření konstruktů modelů, tedy metajazyk. Používá stejné modelovací konstrukty pro Diagram tříd jako UML, a tak je možné používat pro jeho tvorbu běžné modelovací nástroje podporující UML. MOF akceptuje realitu, kdy různé modely vyjadřují různé pohledy na systém. Tyto různé modelovací jazyky je však třeba popsat jednotným způsobem a takovým univerzálním způsobem, jak popsat různé modelovací konstrukty, je právě MOF. Architektura MOF je tvořena 4 metaúrovněmi, jak ukazuje tabulka 4.3. úroveň úroveň M3 úroveň M2 úroveň M1 úroveň M0 popis MOF, množina konstruktů pro definici metamodelů metamodely definované pomocí konstruktů MOF, např. UML, CWM, CCM modely tvořené instancemi konstruktů M2 metamodelu, např třída Zákazník apod objekty a data, tj. instance konstruktů M1 modelu, např. zákazník Jan Novák tabulka 4.3: Úrovně MOF Common Warehouse Metamodel (CWM) je standard definovaný pomocí MOF. Standardizuje databázové modelovací jazyky tak, že si nástroje různých výrobců mohou vyměňovat datové modely, pravidla transformace dat, analytické specifikace. Strategická iniciativa OMG Model Driven Architecture představuje renesanci myšlenek, které byly proklamovány při tvorbě software již dlouhou dobu. Převratný vývoj v technologiích a silný důraz na efektivnost prostředků vložených do informačních technologií však v současné době vytvářejí příznivé klima pro realizaci těchto myšlenek. Navíc jsou tyto myšlenky prosazovány organizací, která má dlouholeté zkušenosti s definováním standardů (UML, CORBA). Cílem MDA je zachovat investice vložené do informačních technologií tím, že se vývojáři zaměří na vytváření platformově nezávislých modelů, které reprezentují věcnou oblast a nejsou dotčeny 76 charakteristika UML dále 77 stereotypy a připojené hodnoty ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 66

67 změnami v technologiích. Z těchto modelů potom s využitím MDA nástrojů, které se dnes již začínají objevovat, budou automatizovaně generovány platformově specifické modely i vlastní implementace Orientace na služby Snaha o zefektivnění informačních technologií a důraz na přínosy v podnikových procesech vede stále více k prosazování konceptu služeb. V následující podkapitole je vymezen pojem služba informatiky, uvedena možná kategorizace služeb a blíže charakterizovány aplikační služby Služby informatiky Služba informatiky je definována jako ucelený definovaný výstup procesů informatiky poskytovaný jejím interním i externím zákazníkům. Služby jsou výsledkem kombinace konkrétních instancí procesů a zdrojů, které probíhají v oblasti informatiky [Bruckner,2001]. Obsahem služby je znovupoužitelná část podnikového procesu, která se může spojovat s ostatními službami. Služby se tak stávají prostředkem realizace znovupoužitelnosti. Zájem o znovupoužitelnost se objevil s nástupem objektově orientovaného a komponentového přístupu a jeho podstatou bylo vytváření tříd a komponent pro znovupoužití. V praxi se však tato myšlenka plně neprosadila a tak můžeme nyní sledovat její další vývojový stupeň znovupoužitelnost na úrovni služeb. Firmy totiž investovaly velké prostředky do informačních technologií a usilují o co nejvyšší návratnost těchto investic. Služby informatiky lze členit podle několika hledisek [Novotný,2003]: Podle typu služby: aplikační služby zejména se jedná o služby, jejichž obsahem je poskytovaná funkcionalita aplikací IS/ICT, infrastrukturní služby služby, které realizují infrastrukturu pro služby aplikační, ostatní služby služby, které zajišťují koordinaci a řízení činností apod. Podle existence uživatele: služby uživatelské jsou poskytovány uživatelům, služby neuživatelské nemají uživatele (např. správa a provoz). Podle poskytovatele služby: interně poskytované služby, externě zajišťované služby. Podle formy agregace: hlavní (komplexní) jsou předmětem smlouvy,, dílčí jsou poskytovány v rámci hlavních nebo jiných služeb. V kontextu návrhu metodického rámce IS/ICT se soustředím především na aplikační služby. V této oblasti se koncept služeb začíná teprve prosazovat. Aplikační služby mají různou granularitu. Službou může být celý typový aplikační software nebo určitý modul, ale také služba malé granularity, kterou lze integrovat do různých řešení 78. Aplikační služby jsou mostem mezi podnikovými procesy na jedné straně a technologiemi pro jejich podporu na straně druhé. Dnes jsou k dispozici technologie umožňující sdílení služeb například webové služby (Web services). Obchodní aspekt služeb však sahá za hranice technologie pro podporu služeb, a to ke konceptu 78 například autorizace kreditních karet ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 67

68 orientace na služby. Orientace na služby je v podstatě způsob podnikání, který odhaluje důležitost partnerství a zaměřuje se na smlouvy mezi partnery v obchodním procesu. Služby informatiky jsou v naprosté většině případů formalizovány prostřednictvím tzv. Dohody o úrovni poskytovaných služeb SLA 79 ([Učeň,2001]). SLA je pojem, který primárně vznikl jako nástroj měření úrovně externě poskytovaných služeb 80. Nyní se však používá i pro formalizaci podmínek poskytování služby mezi podnikovou informatikou a ostatními útvary podniku (interní poskytování služeb informatiky). Naměřené hodnoty SLA potom podmiňují výši plateb za provedené služby, resp. uplatnění sankcí. SLA je stěžejním stavebním kamenem rozhraní mezi odběratelem a poskytovatelem informatických služeb (bez ohledu na použitý obchodní model informatiky) [Novotný,2003]. V dnešním světě plném spojování firem a realizace formou subdodávek roste význam orientace na služby. Aplikační služba se stává komoditou, která se kupuje, prodává a dodává podobně jako jiné druhy služeb. Konzument služby se nezajímá o implementační detaily. Implementace se může u různých dodavatelů lišit, i když dodávají stejnou službu. Vidíme tu tedy nový projev základního objektového principu zapouzdření. Specifikace služby musí být stejně jako jiné kontrakty mezi poskytovatelem a konzumentem přesná a jednoznačná. Ekonomické aspekty orientace na služby jsou velmi závažné v dlouhodobém horizontu. Společnost Meta Group je přesvědčena [Metagroup,6/2003], že jedním z nejdůležitějších trendů v informatice v následující dekádě bude právě orientace na služby. Zvýšení produktivity, kterou orientace na služby slibuje, je jen špičkou ledovce obchodních přínosů služeb. Orientace na služby je především věcí efektivnosti podnikání a jeho agility. To, co služby slibují přinést, není jen otázkou technologie, ale do značné míry ovlivňuje i metodiky vývoje a nasazení IS/ICT. Ačkoli se technologie i ekonomické prostředí za poslední desetiletí dramaticky změnily, metodiky většinou s těmito změnami nepočítají. Většina metodik byla navržena pro prostředí, kde se aplikace vyvíjejí od začátku, ne pro prostředí založené na službách, kde je třeba řešení poskládat z různých zdrojů většinou s minimem nového vývoje. Na aplikační službu se můžeme dívat ze dvou pohledů vnějšího a vnitřního. Vnější pohled se týká technologické neutrality. Stejná služba může být nabízena prostřednictvím různých technologií a může být využita v různých podnikových procesech. Vnitřní pohled se týká implementace. Stejná služba může být realizována různými způsoby. Implementaci je možné změnit aniž by to ovlivnilo vnější pohled na službu. To nám umožňuje porovnávat a vyhodnocovat alternativní implementace stejné služby a vybrat nejlepší. Dalším přínosem orientace na služby je sladění dlouhodobé vize se současnou realitou. Vnější pohled na služby je spojen s modelováním procesů jako sady služeb. Vnitřní pohled je spojen s využíváním existujících softwarových zdrojů. Stávající systémy (Legacy) mohou být zpřístupněny jako služba a tak je možné rychle získat přínos z minulých investic. Současný zájem o aplikační služby je spojen zejména s technologií webových služeb a organizace začínají implementovat určité funkčnosti ve formě webových služeb. Často však pouze obalí existující komponenty a nabízejí je v podobě webových služeb. Tento přístup ke službám jde zdola a není dostačující. Je třeba se zaměřit na přístup shora, který vyžaduje změny v architektuře IS/ICT. Je třeba zavést Architekturu orientovanou na služby (Service Oriented Architecture, SOA). Podstatou této architektury jsou volně spřažené (loosely coupled) na standardech založené služby [Bloomberg]. Tyto architektury kromě nových architektonických přístupů vyžadují i novou roli v organizaci roli architekta orientovaného na služby. 79 Vytvořena z původního anglického termínu Service Level Agreement. 80 v rámci outsourcingu, ASP, servisní smlouvy apod. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 68

69 Architektura orientovaná na služby Architektura orientovaná na služby (Service Oriented Architecture, SOA) je přístup k distribuovanému zpracování, který pohlíží na softwarové zdroje jako na služby dostupné na síti. Takové architektury nejsou novinkou. Komponentové architektury jako CORBA a DCOM jsou postaveny na stejné myšlence, ale potýkají se s vážnými problémy. Za prvé jsou těsně spřažené (tightly coupled), což znamená, že oba konce distribuovaného spojení se musí dohodnout na detailech programového rozhraní. Změna kódu objektu pak vyžaduje odpovídající změnu v kódu, který tento objekt používá. Za druhé jsou tyto architektury proprietární. DCOM je kontrolován firmou Microsoft, CORBA je sice založena na obecných standardech, ale v praxi jsou její implementace proprietární a vzájemně nekompatibilní. Webové služby (Web Services) představují evoluční vývoj, který odstraňuje nedostatky komponentových architektur. Technologie webových služeb je tvořena množinou průmyslových standardů založených na XML, které specifikují komunikační protokol (SOAP), jazyk pro definici (WSDL) a registr pro publikování a vyžádání služby (UDDI) [Allen,3/2003]. Webové služby jsou tedy standardní a volně spřažené, což odděluje účastníky distribuované interakce tak, že změna na jedné straně nezpůsobí selhání na straně druhé. Kombinace těchto dvou klíčových principů znamená, že firmy mohou implementovat webové služby bez znalosti konzumentů těchto služeb a naopak. Síla a flexibilita, kterou může Architektura orientovaná na služby organizaci nabídnout je významná. Pokud se organizace oprostí od své současné infrastruktury a nabídne funkcionalitu ve formě webových služeb, potom konzumenti těchto služeb (ať ve vlastním podniku nebo obchodní partneři) mohou k těmto službám přistupovat nezávisle na technologii. Architektura orientovaná na služby je postavena na těchto klíčových principech: podnikové procesy řídí služby a služby řídí technologii 81, obchodní agilita je základním požadavkem 82, úspěšná Architektura orientovaná na služby se stále vyvíjí. Atraktivnost služeb spočívá ve zvýšení produktivity IS/ICT řešení, snížení nákladů vývoje a nasazení a zkrácení času uvedení na trh. Dalším cílem je vyšší přínos z IS/ICT řešení. Architektura orientovaná na služby je důležitá pro podniky, protože představuje rámec, který sjednocuje obchodní model s technologiemi a realizuje funkcionalitu zajišťující efektivní podnikání. Bez Architektury orientované na služby se IS/ICT stávají nepropojenou kolekcí balíků, funkcí a obrazovek, které konzumují stále rostoucí zdroje na údržbu a rozvoj. Architektura orientovaná na služby zavádí přímý vztah mezi obchodními operacemi a aplikačními službami, a tak zjednodušuje údržbu systému a jeho refaktorizaci na bázi služeb Shrnutí kapitoly V této kapitole byly charakterizovány hlavní zdroje, ze kterých jsem čerpala při návrhu metodického rámce MEFIS, zejména metodika MMDIS a Referenční model řízení informatiky, které byly vytvořeny na Katedře informačních technologií VŠE a které metodický rámec rozvíjí. Kromě rigorózních a agilních metodik, které byly charakterizovány v kapitole 3 Rigorózní a agilní metodiky jsou to architektonické přístupy, zejména Modelem řízená architektura (Model Driven Architecture) a Architektura orientovaná na služby (Service Oriented Architecture). Další zdroje jsou obecnějšího rázu jako teorie učící se organizace, teorie komplexních adaptivních systémů, firemní kultura a lidský faktor. 81 ve skutečnosti služby fungují jako abstraktní vrstva mezi podnikovými procesy a technologií 82 schopnost odpovídat na změny požadavků je novým klíčovým požadavkem, celá architektura musí požadavek byznys agility respektovat ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 69

70 5 Metodický rámec IS/ICT MEFIS Předmětem této kapitoly je popis návrhu Metodického rámce IS/ICT (Methodology Framework for IS/ICT Systems) MEFIS. Metodický rámec představuje metametodiku, na metaúrovni jej tvoří principy a procesy pro vytvoření konkrétní metodiky na základě vzorů a přizpůsobení metodiky v průběhu projektu. Metodický rámec dále obsahuje metodické vzory určené pro různé problémové oblasti, typy řešení, typy projektů a další hlediska. 5.1 Metodický rámec jako metametodika V předcházejících kapitolách jsem porovnávala různé metodiky pro budování IS/ICT. Metodika budování IS/ICT zpravidla obsahuje popis procesů, které probíhají při vývoji a údržbě informačních systémů 83. Pokud popisujeme procesy, které probíhají při vytvoření metodiky, dostáváme se na úroveň metametodiky. Tyto vztahy znázorňuje obrázek 5.1. obrázek 5.1: MEFIS jako metametodika Ve své disertační práci jsem navrhla metodický rámec MEFIS Methodology Framework for IS/ICT Systems Metodický rámec IS/ICT. Metodický rámec definuje základní principy vytvoření metodiky, fáze a procesy probíhající při vytvoření a přizpůsobení metodiky a databázi metodických vzorů. Principy a procesy uplatňující se při vytvoření či přizpůsobení konkrétní metodiky představují metaúroveň. Metodické vzory pak představují úroveň metodiky. Rozdělení metodického rámce na úroveň metametodiky a metodiky znázorňuje obrázek 5.2. V této kapitole je popsán koncept metodického rámce a metodické vzory. Metaprincipy a metaprocesy jsou popsány v kapitole Zaměření metodického rámce MEFIS Metodiky budování IS/ICT popisují procesy probíhající při vývoji a údržbě informačních systémů. Tyto procesy představují podmnožinu procesů informatiky, které byly charakterizovány v podkapitole 2.1 Součásti podnikové informatiky. Procesy informatiky zahrnují procesy tří typů hlavní, podpůrné a řídící procesy. Tyto tři typy procesů 83 kromě toho obsahuje i další prvky jako principy, praktiky, techniky apod. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 70

71 jsou ve vzájemných vazbách a ovlivňují se. Z pohledu procesů informatiky se toto ovlivňování projevuje ve dvou směrech: procesy informatiky svými výsledky musí podporovat hlavní procesy, procesy informatiky zahrnují jak věcné (softwarově inženýrské) procesy, tak procesy řídící. obrázek 5.2: Úrovně metametodiky a metodiky v MEFIS obrázek 5.3: Zaměření MEFIS Tyto závěry je třeba zohlednit při návrhu metodiky pro budování IS/ICT a jsou zohledněny i při návrhu metodického rámce. Další otázkou je, zda by měl být metodický rámec zaměřen pouze na budování a rozvoj informačního systému a nebo také na provoz informačního systému. Vzhledem k velké provázanosti obou oblastí ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 71

72 a ke skutečnosti, že není možné oddělit vývoj 84 systému či jeho části a jeho provoz 85, navrhla jsem metodický rámec pokrývající vývoj i provoz IS/ICT, přičemž specifika vývoje či provozu jsou řešena v rámci specializace metodických vzorů, která je základem metodického rámce (viz podkapitola 5.4 Klasifikace metodických vzorů. Obrázek 5.3 zachycuje zaměření Metodického rámce IS/ICT, který pokrývá jak oblast vývoje, tak oblast provozu IS/ICT a zahrnuje jak hledisko softwarově inženýrské, tak hledisko řízení. Spojení těchto dvou hledisek v metodickém rámci MEFIS je jeho klíčovým rysem (blíže viz 5.3.3). 5.3 Charakteristiky metodického rámce MEFIS Na základě rozboru současného stavu v oblasti IS/ICT, který jsem popsala v kapitole 2 Současný stav metodik budování IS/ICT, a současných metodických přístupů, z nichž nejvýznamnější jsou charakterizovány v kapitole 3 Rigorózní a agilní metodiky a kapitole 4 Zdroje pro návrh metodického rámce, jsem definovala základní charakteristiky metodického rámce MEFIS, které jsou v následujících odstavcích diskutovány: orientace na služby, celopodnikové hledisko a integrace, integrace perspektivy řízení a perspektivy softwarově inženýrské, podpora různých typů řešení, podpora řízení znalostí, rozlišování úrovní abstrakce, rozlišování mezi typem prvku a instancí prvku, metodické vzory, využívání principů a praktik agilních metodik, vazba na systémy hodnocení softwarových procesů Orientace na služby Metodický rámec je zaměřen na budování IS/ICT orientovaného na služby, jehož výsledky jsou vztaženy k podnikovým procesům. Ekonomická recese probíhající v současné době vede k omezování výdajů na informační a komunikační technologie. Organizace jsou nuceny se zabývat návratností prostředků vložených do IS/ICT. Snaha o zefektivnění informatiky a důraz na přínosy v podnikových procesech vedou stále více k prosazování konceptu služeb. Definice služby byla uvedena v podkapitole Služby informatiky. Jeden z nejdůležitějších rysů služby je, že mnohem lépe zapadá do podnikových procesů a pomáhá řešit dlouhodobý problém sladění IS/ICT a podnikových procesů. Podle průzkumu společnosti Meta Group za rok 2002 se požadavek na sladění informatiky a podnikových procesů (Business Alignment ) objevil mezi 5 nejdůležitějšími faktory v informatice. V USA se tento faktor umístil na druhém místě ihned za snižováním nákladů do informatiky, v ostatním světě pak na třetím místě za zvýšením produktivity a snížením nákladů. [Metagroup,2002]. Služby se zatím prosadily spíše při provozu IS/ICT v souvislosti s outsourcingem 86, ale dle posledních průzkumů společnosti Meta Group [Metagroup,6/2003] se koncept služeb ukazuje jako nezbytný i při budování IS/ICT. 84 respektive nasazení 85 zejména v kontextu přírůstkového, komponentového vývoje a vývoje zaměřeného na služby 86 Outsourcing je stav (nebo činnost k němu vedoucí, kdy vstup, který by firma získala z vlastního zdroje, koupí od jiného (podnikatelského subjektu jako službu (nebo zboží) [Bruckner,Vorisek] ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 72

73 5.3.2 Celopodnikové hledisko a integrace Většina organizací má již v dnešní době automatizovány hlavní oblasti své činnosti. Požadavkem dnešní doby je integrace těchto ostrůvků automatizace do jediného systému. Zatímco dříve byly informační systémy nahrazovány novými, dnes se začíná prosazovat názor, že je třeba stávající systémy, které dobře pracují, propojit s ostatními a zpřístupnit je například přes webové rozhraní. To je jeden z úkolů systémové integrace. Systémová integrace představuje způsob, jak umožnit technologiím ve stále se měnícím informatickém prostředí spolu komunikovat. Jak řekl Richard Soley, předseda a CEO OMG 87, ve své úvodní přednášce na OMG konferenci Integrate 2003: Integrace je problém, který nemůžeme odsunout. [Soley,2000]. Integrace není jen technologický problém, ale je to také obchodní problém. S požadavkem integrace systémů úzce souvisí nutnost celopodnikového (Enterprise) pohledu. Metodický rámec MEFIS zdůrazňuje celopodnikový pohled zejména v těchto oblastech: všechny metodické vzory patří do kategorie globálních metodik 88, je definována nová fáze 89 Řízení a koordinace projektů, která je zaměřena na realizaci procesů na celopodnikové úrovni blíže viz podkapitola Fáze Integrace perspektivy řízení a perspektivy softwarově inženýrské Metodika budování IS/ICT se musí zaměřovat jak na softwarově inženýrské procesy, tak na procesy řídící. Pokud organizace používá metodiku, která se zabývá pouze softwarově inženýrskými procesy, a vedle toho metodiku zaměřenou na řízení projektů, může se dostat do problémů se vzájemnými vazbami obou metodik. Metodický rámec IS/ICT v sobě proto integruje jak řídící procesy, tak procesy softwarově inženýrské. Řídící procesy představují perspektivu řízení, softwarově inženýrské procesy pak představují perspektivu softwarově inženýrskou. Význam perspektivy řízení v rámci procesů informatiky se zvyšuje a tuto skutečnost si uvědomují vedoucí pracovníci informatických firem. Podle výsledků průzkumu společnosti META Group 77% organizací uvedlo, že klíčovým problémem v roce 2003 je nedostatečná kvalifikace jejich pracovníků v řízení projektu. Předchozí průzkumy zaměřené na projektové manažery ukázaly, že 16% organizací nemá žádnou způsobilost v řízení projektu, 22 % organizací spoléhá na ad hoc řízení a jen 2% organizací vyžaduje u svých vedoucích projektů povinnou certifikaci v řízení projektu [Metagroup,2003] Podpora různých typů řešení Metodický rámec IS/ICT pokrývá jak oblast vývoje řešení, tak oblast zavádění typových aplikačních řešení, tak i v poslední době se rozvíjející oblast užívání řešení na bázi ASP či jiné formy outsourcingu. Přitom v oblasti vývoje řešení se nezaměřuje jen na nová řešení, ale také rozšiřování stávajících řešení a integraci řešení. Specifika tvorby výše uvedených typů řešení jsou řešena v rámci doménových a projektových metodických vzorů, blíže viz podkapitola 5.4 Klasifikace metodických vzorů Podpora řízení znalostí Metodický rámec je vytvářen, rozvíjen a využívám v rámci poznatků řízení znalostí. Metodik pro budování IS/ICT je velké množství, jsou různé pro různé oblasti, různé typy aplikací, různý rozsah životního cyklu. Abychom mohli tyto metodiky rozumně použít, je třeba jim přiřadit kontext a přeměnit je na znalosti. Jak bylo uvedeno v příspěvku na konferenci Systémová integrace 2003 znalosti = informace + kontext [Hujňák,SI2003]]. Metodický rámec 87 standardizační organizace Object Management Group 88 dle kritéria uvedeného v Kritérium Zaměření metodiky 89 nová vzhledem k fázím metodiky MMDIS ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 73

74 MEFIS obsahuje bázi metodických vzorů, které jsou jednotně klasifikovány. Organizace si metodické vzory přizpůsobuje svým potřebám a doplňuje o zkušenosti s jejich aplikací. Tímto způsobem si buduje znalostní bázi a učící se metodiku Rozlišování úrovní abstrakce Významným principem metodiky MMDIS, jak bylo uvedeno v podkapitole 4.1, je Princip tří architektur [Řepa,1999]. Tento princip v souladu s Modelem řízenou architekturou (Model Driven Architecture, podkapitola 4.10) zdůrazňuje nutnost vytvořit nejprve konceptuální na platformě nezávislý model a teprve v další fázi do něj promítat specifika daná platformou. Když se podíváme na důvody, které vedly k jeho vzniku, potom je to především snaha zachovat investice vložené do IS/ICT i přes velmi rychlý vývoj informačních a komunikačních technologií. V MEFIS je tento princip uplatněn jako princip obecného metodického vzoru (podkapitola ). Navíc je myšlenka oddělení platformových specifik uplatněna v samotném konceptu metodického rámce, neboť metodické vzory jsou definovány jako nezávislé na platformě vývoje (vývojových nástrojích). Specifika vývojové platformy je možné zahrnout do specializovaných metodických vzorů pro určitou vývojovou platformu 90 a nebo promítnout specifika vývojové platformy až při aplikaci metodického vzoru a vytvoření metodiky pro konkrétní projekt tak, jak je to popsáno v podkapitole Promítnutí specifik vývojové platformy. Tímto způsobem se zachovají investice vložené do metodiky i při změně vývojové platformy Rozlišování mezi typem prvku a instancí prvku Řada problémů s různým chápáním termínů používaných při budování IS/ICT i s výkladem obsahu metodik je způsobena nerozlišováním mezi třídou a instancí třídy, a to nejen v kontextu objektově orientovaného programování. Metoda abstrakce, která je podstatou tohoto odlišování, je základní metodou při analýze jak v oblasti vědeckého zkoumání, tak i při praktické činnosti. Metodický rámec MEFIS je postaven na rozlišování mezi typem a instancí a to na různých úrovních 91. Toto rozlišování usnadňuje vlastní návrh metodického rámce a zvyšuje jeho srozumitelnost Metodické vzory Základním východiskem pro definování metodického rámce je myšlenka, že metodika není jediná, ale každý projekt vyžaduje specifickou metodiku. Aby bylo možné takovou specifickou metodiku vytvořit poskytuje MEFIS metodické vzory (Methodology Patterns). Již volba termínu vzor evokuje nutnost aplikace vzoru a jeho přizpůsobení na podmínky konkrétního projektu. Význam používání vzorů při vývoji software, ať už návrhových vzorů (Design Patterns) či architektonických vzorů (Architecture Patterns), stále roste. Metodický rámec MEFIS je ovlivněn vzory ve dvou směrech: struktura MEFIS je inspirována myšlenkou vzorů a základem MEFIS jsou metodické vzory, základní praktikou, na které je založen vzor M02 Nový objektově orientovaný vývoj obecného software vlastními silami je využívání návrhových vzorů (viz přílohy 6 10). Metodické vzory, které jsou základem metodického rámce, myšlenkově vycházejí z konceptu návrhových vzorů. Návrhové vzory reprezentují efektivní a vyzkoušené řešení určitých jednoduchých problémů. Tato jednoduchá řešení je možné kombinovat a skládat, a tak realizovat i složitá řešení. Vzory poskytují obecný slovník a taxonomii pro vývojáře a architekty a jsou prostředkem, jak zajistit znovupoužitelnost architektury, návrhu a implementačních rozhodnutí. Koncept návrhových vzorů se objevil začátkem 90 let a od roku 1995, kdy byla 90 definovaných jako potomky základních platformově nezávislých metodických vzorů 91 například softwarový systém a instance softwarového systému, metodika a instance metodiky, třída a instance třídy ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 74

75 publikována kniha Design Patterns: Elements od Reusable Object Oriented Software, jejíž autoři jsou označováni jako Gang of Four, se rychle prosazuje. 92 V oblasti vzorů je k dispozici velké množství zdrojů, publikací i materiálů přístupných na internetu. Výhodou vzorů je definovaná a používaná struktura vzoru. Současně se objevují i snahy o klasifikaci vzorů. Velmi dobré uspořádání a klasifikaci vzorů poskytuje například [MSESP]. Identifikuje vztahy mezi vzory, zařazuje je do skupin a definuje různé úrovně abstrakce a různé pohledy na vzory. Protože považuji koncept vzorů za velmi přínosný a jsem přesvědčena, že jeho role při vývoji software se bude neustále posilovat, zvolila jsem koncept metodických vzorů za základní prvek metodického rámce Využívání principů a praktik agilních metodik Agilní metodiky, které byly charakterizovány v kapitole 3 Rigorózní a agilní metodiky, se stále více prosazují. Je třeba si uvědomit, že jsou vhodné jen pro určité typy projektů. Koncept metodických vzorů pro různé typy projektů umožňuje definovat lehké metodiky založené na agilních přístupech a zároveň metodické vzory, které jsou bližší rigorózním metodikám. Ovšem i v tomto případě je účelné využít alespoň některé myšlenky agilních přístupů. Tento trend můžeme sledovat i ve světě, kde se doporučují kombinace rigorózních metodik s agilními Vazba na systémy hodnocení softwarových procesů Metodický rámec má rozhraní na systémy hodnocení softwarových procesů 94. Systémy hodnocení softwarových procesů, které byly popsány v podkapitole 3.1 Rigorózní metodiky, představují mezinárodní standard umožňující hodnotit zralost softwarových procesů v organizaci a na základě tohoto zjištění se zaměřit na určitou oblast, kterou je třeba zlepšit. Procesy definované v metodickém rámci proto musí mít vazbu na úrovně zralosti CMM. 5.4 Klasifikace metodických vzorů V rámci metodického rámce MEFIS jsem definovala metodické vzory různých typů. Základním vzorem je obecný metodický vzor, od kterého jsou odvozeny vzory pro jednotlivé domény a typy projektů. Každý metodický vzor, kromě obecného, je zařazen v rámci definovaných klasifikačních kritérií. Tím je určen kontext daného vzoru, který umožňuje vyhledat odpovídající vzor a aplikovat jej pro konkrétní projekt. Klasifikace metodických vzorů vychází z kritérií pro kategorizaci metodik, která jsem popsala v podkapitole 2.4 Kategorizace metodik, ale je upravena pro potřeby metodického rámce. Základními kritérii pro klasifikaci metodických vzorů jsou : doména, typ řešení, způsob řešení, přístup k řešení Klasifikační kritérium Doména Pojem doména byl vymezen v podkapitole Kritérium Doména. Budování klasického ERP 95 systému, datového skladu či aplikace elektronického podnikání se liší jak v postupu, v činnostech i použitých technikách. Proto jsou v rámci metodického rámce definovány základní principy, praktiky a procesy společné pro všechny předmětné oblasti. Tyto prvky tvoří náplň obecného metodického vzoru. Dále jsou definovány pro jednotlivé 92 V roce 2003 vyšla tato kniha i v českém překladu [Gamma,2003]. 93 například kombinace Agilního modelování a metodiky RUP. 94 například CMM 95 Enterprise Resource Planning ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 75

76 domény tzv. doménové metodické vzory, které zachycují specifika příslušných domén. Domény, které se pro klasifikaci metodických vzorů využívají, uvádí tabulka 2.6 v podkapitole Kritérium Doména Klasifikační kritérium Typ řešení Dalším základním klasifikačním kritériem metodických vzorů je kritérium Typ řešení. Postup při vývoji nového systému je jiný než při implementaci typového řešení a nebo rozšiřování stávajícího řešení. Hodnoty klasifikačního kritéria Typ řešení uvádí tabulka 2.5 v podkapitole Kritérium Typ řešení Klasifikační kritérium Způsob řešení Třetím základním klasifikačním kritériem pro metodické vzory je kritérium Způsob řešení. Toto kritérium rozlišuje mezi řešením vlastními silami a řešením zajišťovaným formou vytěsnění (outsourcingu) a jeho hodnoty jsou uvedeny v tabulce 5.1. Způsob řešení kód IN OUT význam vlastní outsourcing tabulka 5.1: Hodnoty kritéria Způsob řešení Klasifikační kritérium Přístup k řešení Zejména pro nově vytvářené řešení hraje významnou roli kritérium Přístup k řešení. Toto kritérium zohledňuje základní paradigma použité při řešení, tedy objektově orientovaný přístup, strukturovaný přístup nebo přístup rychlého vývoje aplikací (RAD) a to s ohledem na jednotlivé fáze životního cyklu. Hodnoty klasifikačního kritéria Přístup k řešení uvádí tabulka 2.7 v podkapitole Na základě těchto čtyř hlavních klasifikačních kritérií je vytvořena hierarchie metodických vzorů viz obrázek 5.4. Další odlišnosti projektů jsou řešeny projektovými klasifikačními hledisky, která jsou popsána v následující podkapitole. <<Abstract>> ObecnyMetVzor Dom enovymetvz or SpecDom enovymetvzor obrázek 5.4: Hierarchie metodických vzorů Obecný metodický vzor je předkem všech vzorů, to znamená, že obsahuje prvky, které jsou společné pro všechny metodické vzory. Definuje základní řídící strukturu metodiky - členění na fáze a brány. Doménový metodický vzor je určen pro určitou doménu například ERP, CRM či další. Tento metodický vzor je specializací obecného metodického vzoru, to znamená, že dědí všechny prvky z tohoto vzoru, může měnit jejich chování a přidávat další prvky. Specifický doménový metodický vzor postihuje odlišnosti vývoje řešení pro určitou předmětnou oblast, dále odlišnosti budování nového řešení, rozvoje řešení, integrace či nasazení typového řešení a to v závislosti na tom, zda jde o vlastní či vytěsněné řešení. Zohledňuje i přístup k řešení, tj. strukturovaný přístup či objektově orientovaný. Využívá tedy všechna čtyři základní klasifikační kritéria - doména, typ vývoje, způsob vývoje a přístup k vývoji. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 76

77 5.4.5 Projektová klasifikační hlediska Projektový metodický vzor je specifický pro určitý typ projektu. Projekty se liší podle důležitosti budovaného systému (aplikace, služby), velikosti týmu, kvalifikace lidí v týmu a dalších charakteristik projektu. Tato hlediska jsou v MEFIS označována jako projektová klasifikační hlediska. Základními projektovými hledisky jsou Důležitost systému a Velikost týmu. Projekt systému pro řízení vesmírné lodi se určitě liší od projektu vytvoření webové prezentace. Proto jsou definovány projektové metodické vzory určené pro různé kategorie aplikací rozlišené podle důležitosti. Důležitost projektu bývá posuzována z různých hledisek. Pro účely této disertační práce jsem zvolila kategorizaci uvedenou v tabulce 5.2. Kritériem pro kategorizaci je závažnost negativních dopadů, které vzniknou v případě, kdy systém není možné z důvodu výpadku, či neplánované odstávky používat. Tyto negativní dopady jsou hodnoceny prostřednictvím tzv. cost of downtime neboli finančním vyjádřením dopadů jedné hodiny neplánované odstávky. Z tohoto pohledu se jako významná kategorie uvádí Mission Critical systémy, tedy systémy kritické pro poslání organizace. Jedná se o IS/ICT systémy, které mají přímý vliv na úspěšnost podnikání. V případě, že tento systém není možné z důvodu výpadku, či neplánované odstávky používat, dochází například k těmto negativním dopadům [Kubat]: přímý finanční dopad na obrat (ztráta konkrétního obchodního případu), narušení cash flow, penále, vícenáklady, negativní publicita (banky, GSM operátoři, maloobchodní řetězce), narušení spokojenosti zákazníka (služby), nesplnění závazků zákazníkům, snížení produktivity, bezpečnostní rizika. Příkladem Mission Critical systémů mohou být finanční či bankovní systémy, systémy pro řízení výroby, CRM 96 systémy, systémy elektronického obchodu, pokladní systémy, SCM 97 systémy, podpora rozhodování, elektronická pošta apod. Kritérium Důležitost systému kód kategorie vysvětlení D doplňkový systém, entertainment selhání systému není nijak kritické, lze nahradit ručně příklad systémy na podporu nákupu, infrastrukturní programy F P Z systém podporující fungování organizace mission support systém kritický pro poslání mission critical systém, na kterém závisí životy lidí life critical selhání systému má dopady, které jsou nepříjemné, příklad výplata chybné mzdy, zaplacení chybné částky na faktuře selhání systému může vést k bankrotu příklad bankovní systém selhání systému může mít za následek ztrátu lidského života příklad atomová elektrárna, řízení letového provozu tabulka 5.2: Hodnoty kritéria Důležitost systému Druhým projektovým klasifikačním hlediskem je Velikost týmu. Toto hledisko významně ovlivňuje zejména váhu metodiky. Blíže viz Kritérium Váha metodiky. Navrhla jsem členění uvedené v tabulce Customer Relationship Management 97 Supply Chain management ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 77

78 Velikost týmu kód význam 10 do 10 členů týmu 20 do 20 členů týmu 50 do 50 členů týmu 100 do 100 členů týmu 500 do 500 členů týmu tabulka 5.3: Hodnoty kritéria Velikost týmu Spojením kritérií Důležitost systému a Velikost týmu dostáváme kritérium Důležitost velikost, jehož hodnoty tvoří matici, ve které znamená posun směrem doprava a nahoru nutnost zvýšení formalit v rámci metodiky, tedy vyšší váhu metodiky. V tabulce 5.4 jsou vyjádřeny hodnoty tohoto kritéria a intenzitou barvy je vyznačena váha metodiky použité pro daný typ projektu. Čím tmavší barva, tím těžší musí být metodika. Toto kritérium se používá jako základ pro určení projektových metodických vzorů v MEFIS. důležitost / velikost týmu do 10 do 20 do 50 do 100 do 500 ztráta života life critical pád firmy mission critical fungování firmy mission support doplněk, komfort entertainment 5.5 Architektura MEFIS Z P F D Z10 Z20 Z50 Z100 Z500 P10 P20 P50 P100 P500 F10 F20 F50 F100 F500 D10 D20 D50 D100 D500 tabulka 5.4: Hodnoty kritéria Důležitost velikost týmu Základním požadavkem na vybudování dobrého IS/ICT je návrh jeho architektury. Také dobrý metodický rámec musí mít architekturu, aby bylo jasné, jaké jsou vazby jednotlivých prvků, jejich součinnost a jak slouží společnému cíli vytvoření efektivní metodiky přizpůsobené pro konkrétní projekt. Architektura metodického rámce MEFIS odráží požadavky na současné metodiky. Základem architektury je výše zmíněné spojení softwarově inženýrské perspektivy a perspektivy řízení. Druhým velmi důležitým rysem promítajícím se do architektury MEFIS je důsledné a explicitní oddělení vrstvy celopodnikové a vrstvy jednotlivých projektů. Toto oddělení vrstev se projevuje v základních prvcích metodického rámce ve fázích a procesech a promítá se do všech metodických vzorů. Třetím klíčovým aspektem architektury MEFIS je specializace metodických vzorů pro jednotlivé domény a typy projektů. Obrázek 5.5 zachycující architekturu MEFIS ukazuje ještě další podstatný rys celého metodického rámce vazbu na podnikové procesy. 5.6 Prvky metodických vzorů Metodické vzory v rámci MEFIS jsou tvořeny řadou prvků, které jsou zachyceny na obrázku 5.6. Při návrhu prvků jsem čerpala z prací A. Cockburna, zejména [Cockburn,JIT] a [Cockburn,MetPerProj]. Prvky metodických vzorů MEFIS jsou definovány v rámci obecného metodického vzoru a potom upraveny pro jednotlivé doménové a projektové vzory. V následujících odstavcích jsou prvky metodických vzorů charakterizovány. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 78

79 obrázek 5.5 Architektura MEFIS Fáze obrázek 5.6: Prvky metodik v MEFIS Základní prvek obecného metodického vzoru, který přebírají všechny metodické vzory, představují fáze životního cyklu a brány jako přechody mezi jednotlivými fázemi. Členění na fáze je základem většiny metodik v oblasti budování IS/ICT. Globální metodiky tak, jak byly vymezeny v 2.4.1, mají zpravidla větší počet fází než metodiky zaměřené na jeden projekt, a kromě toho je odlišná i granularita fází. Některé metodiky využívají pouze čtyři fáze Specifikace požadavků, Analýza, Návrh, Implementace, jiné používají podrobnější členění. V návrhu fází pro metodický rámec MEFIS vycházím z fází definovaných v metodice MMDIS [Vorisek,1997]. Nově je přidán koncept bran. Koncept fází a bran reprezentuje prolínání dvou základních perspektiv MEFIS softwarově inženýrské perspektivy a perspektivy řízení. Členění na fáze a přechody mezi fázemi jsou předmětem perspektivy řízení, zatímco vlastní náplň fází (procesy a techniky softwarového inženýrství) reprezentují softwarově ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 79

80 inženýrskou perspektivu. Brány jsou explicitně odděleny od fází, čímž zdůrazňují akt řízení a rozhodování. Koncept fází a bran platí pro celou organizaci, je rámcem pro všechny projekty. Díky jednotnému pohledu na fáze může vedení organizace sledovat postup prací na jednotlivých projektech, vytvářet portfolio projektů, synchronizovat projekty, jejichž komponenty musí být integrovány. Hlavní fáze životního cyklu IS/ICT jsou znázorněny na obrázku 5.7. fáze životního cyklu brány obrázek 5.7: Fáze a brány metodických vzorů MEFIS Za klíčové považuji explicitní rozdělení fází do dvou vrstev celopodnikové vrstvy a vrstvy jednotlivých projektů. V současné době, kdy roste význam integrace na úrovni podniku i mezi podniky, roste zákonitě význam celopodnikové vrstvy. Z toho důvodu jsem ke dvěma celopodnikovým fázím definovaným již v MMDIS (fáze Globální strategie a Informační strategie) přidala novou fázi Řízení a koordinace projektů. Tato fáze probíhá paralelně s jednotlivými projekty a je zaměřena na celopodnikové procesy informatiky jako například Návrh celopodnikové architektury, Řízení znovupoužitelnosti apod. Pro každý projekt probíhají fáze Úvodní studie až Provoz a údržba. Předmětem řešení v některých fázích je celé projektové řešení 98, jiné fáze se potom provádějí v rámci iterativního a přírůstkového vývoje pro každý přírůstek samostatně. MEFIS je stejně jako mnoho současných metodik založen na přírůstkovém vývoji 99. Proto je důležité specifikovat pro každou fázi předmět řešení, což znázorňuje obrázek 5.8. Předmětem řešení ve fázi Úvodní studie a Globální analýza a návrh je celé projektové řešení. Součástí fáze Globální analýza a návrh je vymezení přírůstků a fáze Detailní analýza a návrh, Implementace a Zavedení probíhají samostatně pro každý přírůstek. Na obrázku 5.7 jsou vyznačeny brány, které představují kontrolované přechody mezi fázemi: brána GST, brána IST, brána UST, brána GAN, brána IMP, brána ZAV. Jak bylo uvedeno výše, fáze DAN a IMP probíhají pro každý přírůstek samostatně a jsou velmi těsně propojeny. Z toho důvodu není na závěr fáze DAN definována brána, ale kontrola a rozhodování o dalším postupu se provádí až na závěr fáze Implementace. Konkrétní naplnění fází a specifikace obsahu bran pro metodický vzor M02 Nový objektově orientovaný vývoj obecného software vlastními silami je uvedeno v příloze Termínem projektové řešení rozumím část IS/ICT, která je předmětem projektu. 99 Přírůstkový neboli inkrementální vývoj je jedním z přístupů k tvorbě informačního systému. Celý systém je v průběhu projektu rozdělen na jednotlivé samostatně realizovatelné části a poté je vyvíjen po těchto částech (přírůstcích). Každý přírůstek prochází jednotlivými fázemi vývoje (analýza přírůstku, návrh, implementace) relativně samostatně (kontrolují se vazby na ostatní přírůstky). Každá verze přírůstkově vytvářeného systému musí být provozuschopná. Cílem je co nejrychlejší dosažení přínosů systému a snížení rizik jeho vývoje. [KIT,2003] ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 80

81 5.6.2 Dimenze obrázek 5.8: Předmět řešení pro jednotlivé fáze MEFIS V podkapitole 4.1 MMDIS byly uvedeny základní myšlenky metodiky MMDIS, na kterou návrh metodického rámce navazuje. Základním charakteristickým rysem metodiky MMDIS je multidimenzionální přístup k procesu budování IS/ICT. V metodice MMDIS jsou definovány jednak obsahové dimenze a jednak dimenze, které se aplikují na metodiku samotnou (rozdělení do fází, dokumentační dimenze, metodická dimenze apod.). V návrhu metodického rámce MEFIS jsem význam pojmu dimenze zúžila jen na dimenze, které se týkají vyvíjeného systému (řešení). Dimenze vlastní metodiky (její výběr, přizpůsobení apod.) jsou řešeny v rámci principů a procesů metametodiky. Dimenze vyvíjeného systému jsou částečně pozměněny. MEFIS definuje následující dimenze: hardwarová technologická (platforma, architektura, middleware, SŘBD) datová funkční/procesní uživatelské rozhraní pracovní organizační/legislativní ekonomická Oproti obsahovým dimenzím metodiky MMDIS, byla softwarová dimenze nahrazena dimenzí technologickou, která zahrnuje jak operační systém, síťové technologie, tak databázový systém a celou řadu technologií patřících do kategorie middleware 100. Dimenze funkční a procesní jsou spojeny a vyjadřují funkce respektive procesy cílového systému. Nově je doplněna dimenze uživatelské rozhraní, jejímž předmětem je interakce uživatele se systémem, zejména návrh uživatelského rozhraní. Uživatelské rozhraní programových systémů je jedním 100 V počítačovém průmyslu je termín middleware používán pro označení jakéhokoli programu, který slouží pro spojení jiných, zpravidla už existujících programů, a nebo jako prostředník mezi nimi. Typicky jde o propojení na různé databázové systémy nebo komunikaci mezi komponentami [TERMSKIT]. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 81

82 z klíčových faktorů, které ovlivňují úspěšnost a použitelnost daného systému. S příchodem grafického uživatelského rozhraní (GUI) se nesmírně rozšířily jak možnosti vývojářů, tak uživatelů. Uživatel již není nucen vykonávat příkazy v předem určeném pořadí, ale stává se sám nositelem veškerého dění. Je to uživatel, který určuje, jaké akce bude provádět v jakém pořadí, s jakými objekty [Buchalcevová,Drbohlav,1999]. Webové uživatelské rozhraní ve srovnání s klasickým GUI rozhraním znamená podstatné omezení možností, které je ale na druhé straně vyváženo velkou dostupností. Současně dochází na poli webového uživatelského rozhraní k rychlému vývoji a sbližování jeho možností s možnostmi standardního GUI rozhraní Role Role představují typové skupiny pracovníků charakterizované vykonáváním obdobných činností. Fyzicky může jeden člověk zastávat více rolí. Role mají definované odpovědnosti. Odpovědnosti rolí zahrnují jak provádění určitých činností, tak vlastnictví určitých produktů. Protože MEFIS spojuje perspektivu softwarově inženýrskou a perspektivu řízení, můžeme podle tohoto hlediska kategorizovat i role. MEFIS navíc explicitně rozlišuje vrstvu celopodnikovou a vrstvu jednotlivých projektů. Proto jsem definovala kategorie rolí podle dvou hledisek: perspektivy metodického rámce softwarově inženýrská a řízení, vrstvy celopodniková, vrstva projektů. Kombinací těchto hledisek získáme kategorie uvedené v tabulce 5.5. K těmto čtyřem kategoriím rolí jsou připojeny ještě role zájmových skupin a doménové role. K rolím zájmových skupin patří zákazníci, které můžeme rozdělit do dvou základních skupin [Bruckner,2001]: uživatel ten, který využívá definovaných služeb informatiky, sponzor ten, kdo rozhoduje o využití nabízených služeb (v jakém rozsahu budou využívány) ten, kdo služby "platí". Příklady rolí pro metodický vzor M02 Nový objektově orientovaný vývoj obecného software vlastními silami jsou uvedeny v příloze 7. vrstva / perspektiva softwarově inženýrská řízení celopodniková celopodnikové role SW inženýrské celopodnikové role řídící projektů SW inženýrské role v projektu řídící role v projektu tabulka 5.5: Kategorie rolí Principy Princip je dle [Voříšek,MMDIS] myšlenkový přístup k chápání a analýze problému a s ním spojené zásady (pravidla) řešení problému. Moderní metodiky, zejména agilní, ustupují od přesného definování procesů, činností a kroků a místo toho se snaží definovat základní principy, které je třeba uplatňovat. Realizace principu se potom může v konkrétních případech lišit. V podkapitole Principy obecného metodického vzoru jsou definovány základní principy platné pro všechny metodické vzory. Specifické doménové vzory potom přidávají další principy respektive modifikují obecné principy v kontextu specifické domény. Příkladem je princip Přírůstkový vývoj založený na službách, který je součástí metodického vzoru M02 Nový objektově orientovaný vývoj obecného software vlastními silami a je uveden v příloze Praktiky Moderní metodiky se vedle principů soustřeďují také na praktiky. Praktiky na rozdíl od procesů více akcentují realitu a primárně se zaměřují na lidi. Zatímco procesy vyjadřují explicitní (popsanou) znalost, praktiky ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 82

83 zapouzdřují interní tacit znalosti. Praktiky jsou formulovány lidmi, kteří danou činnost skutečně vykonávají, a tak zahrnují i zkušenost. Často se nejen v metodikách setkáme s pojmem best practices nejlepší praktiky. Například metodika Rational Unified Process je dle autorů metodiky založena na nejlepších praktikách softwarového vývoje. [RUP] Vzhledem k tomu, že pojem nejlepší praktika je dle mého názoru relativní a nejlepší je pouze v určitém kontextu a pro určitý projekt, je v MEFIS použit pouze pojem praktika. Zatímco agilní metodiky prosazují praktiky jako protipól procesů a náhradu za procesy, v metodickém rámci MEFIS jsou definovány jak procesy, tak praktiky, které se při realizaci procesů uplatňují. Procesy jsou ovšem definovány jako velmi lehké, přesto se snaží zachytit explicitní znalosti a jsou tak základem pro opakovatelnost procesů. Praktiky pak tyto lehké procesy doplňují a poukazují na zkušenosti a osvědčené přístupy při vývoji software. Praktiky mohou být různé a je vhodné je kategorizovat. Vyšla jsem z rozdělení praktik v [Highsmith,2002] a dělím praktiky do třech kategorií: praktiky pro spolupráci určují, jak členové týmu komunikují navzájem, se zákazníky a s vedením, tyto praktiky jsou klíčové pro škálování metodiky na větší projekty, praktiky pro řízení projektu určují, jak jsou projekty řízeny a monitorovány, praktiky pro vývoj určují, jaké postupy a techniky používat při vývoji (rozvoji, nasazení). Praktiky jsou popisovány v jednotné struktuře. V příloze 9 jsou popsány praktiky projektového vzoru M02 Nový objektově orientovaný vývoj obecného software vlastními silami Procesy Procesy definované v rámci metodických vzorů MEFIS jsou ty procesy informatiky, které probíhají při vývoji, údržbě a provozu IS/ICT. Proces v tomto kontextu představuje sadu činností, technik, praktik, které lidé používají pro vývoj a údržbu IS/ICT a produkty (plány, dokumenty, modely, kód, testovací případy atd.), se kterými při těchto činnostech pracuje. Proces probíhá v několika fázích, ale s různou intenzitou. Zatímco fáze probíhají sekvenčně, procesy probíhají uvnitř fází iterativně. Procesy projektového vzoru M02 Nový objektově orientovaný vývoj obecného software vlastními silami jsou popsány v příloze Činnosti Činnosti jsou jednotky práce, ze kterých se skládá proces. Činnosti se odkazují na role 101 a popisují, jak tyto role komunikují 102, co vytvářejí 103 a jakým způsobem 104. Popis až do úrovně činností by měl být realizován v projektových metodických vzorech pro projekty s větší důležitostí a velikostí týmu. Lehké projektové metodické vzory vystačí s principy, procesy a praktikami Techniky Technika dle [Řepa,1999] určuje, jak se dobrat požadovaného výsledku. Zpravidla určuje přesný postup jednotlivých činností, způsob použití nástrojů, varianty rozhodnutí v určitých situacích a co z nich vyplývá, vymezuje obor působnosti atd. Podobně jako někteří autoři 105 budu chápat techniku jako synonymum metody. Příkladem technik je procesní modelování, normalizace datové základny, CRC modelování a další. Pro vykonání 101 například analytik, návrhář, tester, uživatel, jaké praktiky spolupráce používají 103 jaké produkty 104 jaké praktiky vývoje používají 105 například [Cockburn,MetSpace] ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 83

84 určité činnosti může být použito více technik. Vlastní popis technik by neměl být součástí metodiky, ale metodika se na určitou techniku pouze odkazuje Nástroje Nástroje představují automatizované prostředky, které podporují jednotlivé techniky, činnosti a procesy. Nejčastěji se používají nástroje pro datové modelování, modelování procesů, objektové modelování a samozřejmě vývojové nástroje. Nástroje však mohou podporovat i ostatní fáze životního cyklu informačního systému. Jedná se o nástroje pro řízení požadavků, testovací nástroje, nástroje pro dokumentaci a nápovědu, nástroje pro správu verzí a týmovou spolupráci a další nástroje. Použití automatizovaných nástrojů podporujících budování IS/ICT představuje často kritický faktor úspěchu projektu, jak ukazují závěry uvedené například v [Kernochan,3/2003]. Nástroje podporující budování IS/ICT zajišťují dodržování standardů a pravidel pro tvorbu kvalitního software, zjednodušují složité požadavky a umožňují lepší řízení projektu. Současný trend směřuje k velmi silné integraci jednotlivých nástrojů různých dodavatelů a využívání nástrojů pro podporu celého životního cyklu vývoje. Metodický rámec v rámci jednotlivých metodických vzorů podporuje používání nástrojů při budování IS/ICT. Současně však zdůrazňuje hledisko dostatečnosti metodiky, to znamená, že není nutné například všechny modely vytvářet kompletní a v CASE nástrojích. Je třeba vždy vážit náklady a smysl těchto produktů. Tento princip je popsán například v rámci praktiky Efektivní modelování v příloze 9. Metodický rámec MEFIS podporuje znovupoužitelnost nejen tak, že ji zohledňuje v rámci metodických vzorů, ale samotný koncept metodického rámce je založen na znovupoužitelnosti jednotlivých prvků metodiky, respektive metametodiky. Znovupoužitelnosti metodických vzorů se dosahuje také důsledným oddělením metodiky nezávislé na vývojové platformě a vývojových nástrojích a platformově závislé metodiky. Platformově nezávislá metodika je tak použitelná pro projekty probíhající s různými vývojovými nástroji. Zároveň je třeba platformově nezávislou metodiku přizpůsobit vývojové platformě blíže viz Produkty Jako produkty označuje MEFIS artefakty, které jsou vytvářeny, modifikovány nebo užívány v rámci procesů 107. Produkty jsou používány rolemi jako vstup pro vykonání nějaké činnosti a jako výsledek činností. Produkty mohou mít různé formy dokumenty 108, modely 109, zdrojový kód, spustitelný kód apod. Metodické vzory se při popise vstupů a výstupů fází a procesů odkazují na produkty viz příloha Metriky Metrika IS/ICT je přesně vymezený ukazatel nebo hodnotící kriterium, který je používán k hodnocení úrovně efektivnosti či jakosti konkrétní oblasti IS/ICT nebo k hodnocení podnikového výkonu nebo k hodnocení úrovně podpory podnikového procesu prostředky IS/ICT. Přesným vymezením metriky se rozumí definovaný postup, který se použije pro získání hodnoty metriky (metoda měření) a definice způsobu, jakým budou získané hodnoty mezi sebou porovnávány (měřící stupnice). [KIT,2003] Metriky jsou nedílnou součástí procesů v MEFIS. Podrobný rozbor metrik a návrh metrik pro referenční model MKIT je uveden v [Novotný,2003]. 106 Pokud je pro metodiku realizována aplikace, může zpřístupňovat popis techniky uložený například v databázi technik. 107 plán projektu, Use case model, model tříd a další 108 například specifikace požadavků 109 například model tříd ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 84

85 Standardy Standardy jsou publikované dokumenty vytvořené na základě dohod a zahrnující technické specifikace nebo jiná přesná kritéria důsledně uplatňované jako pravidla, směrnice nebo charakteristické definice, které zaručují, že materiály, produkty, procesy a služby splní své poslání. [KIT,2003] Standardy představují velmi důležitou součást metodiky. Metodika musí určit, jaké standardy se budou používat, případně je může upravit. Příkladem může být třeba notace pro modelování UML, která je velmi podrobná a všezahrnující a bývá účelné specifikovat její podmnožinu. Je třeba definovat, programové konvence, konvence pro nápovědu a dokumentaci, standardy pro schvalování apod Vzory V posledním desetiletí se začíná prosazovat vývoj založený na vzorech (Pattern Based Development), který umožňuje navrhovat software rychleji, v lepší kvalitě a využívat znovupoužitelnosti. Vývojář může pracovat na vyšší úrovni abstrakce a aplikuje vzory, které popisují obecné řešení opakujících se problémů při návrhu. Může se tak soustředit na řešení věcných problémů, místo aby řešil problémy architektonické a technologické. Vzory zapouzdřují specifickou znalost architektury, platformy a technologie a pomáhají vytvářet znovupoužitelný kód. Když architekti propojí vzory a vytvoří rámec vzorů, mohou podstatně snížit čas potřebný na vývoj aplikace ve srovnání s vývojem od začátku. Význam vzorů pro vývoj software se ještě umocňuje, pokud vzory využíváme ve spojení s modely. Modely zjednodušují podnikové procesy a vzory zjednodušují technologii [Blankers]. MEFIS velmi silně podporuje koncept vzorů. V rámci metodického vzoru M02 Nový objektově orientovaný vývoj obecného software vlastními silami je popsána praktika Využívání návrhových vzorů (příloha 9). Cílem procesu Řízení znovupoužitelnosti, popsaného v příloze 10, je budovat celopodnikovou databázi vzorů, která vychází z obecných vzorů, zahrnuje přizpůsobené vzory a doplňuje vzory nové. 5.7 Obecný metodický vzor Obecný metodický vzor je základem, od kterého jsou odvozeny všechny ostatní metodické vzory. Použijemeli terminologii objektového přístupu, pak je obecný metodický vzor předkem všech metodických vzorů, které z něj dědí vlastnosti a chování. Obecný metodický vzor definuje principy, praktiky a základní řídící strukturu (rozdělení na fáze a brány) platné pro všechny metodické vzory. Obecný metodický vzor není v současné době plně definován. Je definováno rozdělení na fáze a brány (podkapitola Fáze) a principy (podkapitola Principy obecného metodického vzoru). Praktiky obecného metodického vzoru nejsou definovány, protože se předpokládá, že budou specifikovány na základě zobecnění praktik jednotlivých doménových metodických vzorů, jejichž vytvoření přesahuje rámec této disertační práce Principy obecného metodického vzoru Význam pojmu princip a role principů v metodikách budování IS/ICT byla vysvětlena v podkapitole Principy. Metodický rámec MEFIS je rozšířením metodiky MMDIS, a proto akceptuje 8 základních principů metodiky MMDIS: multidimenzionalita, integrace, vrstvenost, flexibilita, otevřenost, standardizace, kooperace, měřitelnost (metriky) [Voříšek,MMDIS]. V kontextu zaměření na oblast budování IS/ICT a ve snaze akcentovat současné trendy v IS/ICT i metodikách, které byly diskutovány v kapitole 4 Zdroje pro návrh metodického rámce, jsem definovala následující další principy, které je třeba uplatňovat ve všech metodických vzorech: sladění IS/ICT s podnikovými procesy, orientace na služby s podporou globální architektury, integrace, ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 85

86 rozlišování úrovní abstrakce, prvořadá úloha lidí, modelem řízené budování IS/ICT Princip sladění IS/ICT s podnikovými procesy Současná ekonomická recese významně ovlivňuje i oblast ICT. Jak bylo uvedeno již v podkapitole 5.3.1, výdaje na informatiku se snižují, naopak se požaduje vyšší kvalita, kratší čas a přínosy ICT v podnikání. Jedním z prostředků, jak zlepšit kvalitu a přínosy IS/ICT pro podnik je potřeba sladit ICT s podnikovými procesy. Jde o to, aby čas a prostředky vynaložené na projekty v oblasti IS/ICT měly přímý vliv na podnikání. IS/ICT je třeba spojit s podnikovými procesy a hodnotit úspěch zavedení IS/ICT podle toho, jak se projeví v podnikání organizace. Nástrojem tohoto sladění jsou globální strategie a informační strategie organizace Princip orientace na služby s podporou globální architektury V současné době dochází k renesanci komponentového vývoje a znovupoužitelnosti. Smyslem však nejsou technologické komponenty, ale komponenty pro podnikání služby. Vymezení pojmu služba a orientace na služby při budování IS/ICT byly diskutovány v podkapitole 4.11 Orientace na služby. Zaměření na služby je podstatnou charakteristikou metodického rámce a bylo uvedeno v podkapitole Orientace na služby podporovaná globální architekturou se projevuje v několika rovinách: specifikace služeb IS/ICT je základem pro specifikaci požadavků na řešení 110, vývoj aplikace jako interní služba nebo vytěsněná služba (outsourcing vývoje), architektura orientovaná na služby (SOA) jako spojovací článek mezi podnikovými procesy a technologickým řešením (blíže viz podkapitola Architektura orientovaná na služby Princip rozlišování úrovní abstrakce Princip rozlišování úrovní abstrakce je uplatněním Principu tří architektur metodiky MMDIS [Řepa,1999] a konceptu Model řízená architektura (MDA) popsaného v podkapitole 4.10 Modelem řízená architektura. Použití tohoto principu je dokumentováno v metodickém vzoru M02 Nový objektově orientovaný vývoj obecného software vlastními silami v rámci fáze Detailní analýza a návrh v příloze 6 a v rámci procesu Analýza a návrh v příloze Princip integrace Současný stav v IS/ICT je charakterizován posunem od programování zaměřeného na aplikace (Application centric programming) k programování zaměřenému na podnik ( Enterprise centric programming). Ještě v nedávné době byla cílem automatizace jednotlivých oblastí v rámci organizace. Jednotlivé zautomatizované oblasti se ale překrývají ve svých funkcích, zpracovávají duplicitní informace a spotřebovávají vzácné zdroje na řešení podobných problémů opakovaně. Proto nastává nutnost integrace dílčích aplikací do integrovaného řešení v rámci organizace a integraci mezi organizacemi (s dodavateli, se zákazníky apod.) Princip prvořadé úlohy lidí Jak bylo uvedeno v podkapitole 4.8 Lidský faktor, lidé jsou prvořadým faktorem při budování IS/ICT a metodiky to musí zohledňovat. Je třeba, aby metodika poskytovala lidem podporu při jejich tvůrčí práci, umožňovala jim samostatně řešit problémy a rozhodovat. Sebedokonalejší procesy nenahradí znalosti a kvalifikaci lidí. Proto je třeba vést lidi k získávání potřebných znalostí a dovedností a zároveň zavádět takové praktiky, které jim umožní převzít implicitní znalosti od zkušenějších kolegů. 110 Podle Service Level Agreement (SLA) je možné odvodit požadavky na systém. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 86

87 Princip modelem řízeného budování IS/ICT Nároky kladené na IS/ICT se stále zvyšují (systémy jsou složitější, je třeba je vytvářet rychle a přizpůsobovat je změnám, technologie se rychle mění, je třeba snižovat náklady, zvyšovat kvalitu apod.). Za této situace je řešením pracovat na vyšší úrovni abstrakce, oprostit se od detailů implementace a zabývat se řešením věcných problémů. K vyjádření věcných problémů slouží modely (dle MDA platformově nezávislé či konceptuální modely). Tyto modely zůstávají nedotčeny změnami technologií a pokud jsou k dispozici odpovídající nástroje, je možné je automatizovaně transformovat na modely specifické pro určitou platformu a implementaci. Tyto transformace často využívají vzorů. Taková kombinace je účelná, protože modely zjednodušují podnikové procesy a vzory zjednodušují technologii. Kombinace modelů a vzorů umožňuje dosahovat vyšší produktivity práce, zajišťuje vyšší kvalitu produktu. 5.8 Metodický vzor Nový objektově orientovaný vývoj obecného software vlastními silami Koncept metodických vzorů je ilustrován na příkladě metodického vzoru M02, který jsem nazvala Nový objektově orientovaný vývoj obecného software vlastními silami. Zařazení tohoto vzoru v rámci klasifikace definované v podkapitole 5.4 Klasifikace metodických vzorů je následující: Doména: CSW obecný software Typ řešení: NEW vývoj nového řešení Způsob řešení: IN vlastní vývoj Přístup k řešení: OO objektově orientovaný vývoj ve všech fázích Výběr metodického vzoru určeného pro realizaci byl ovlivněn mým zaměřením na oblast objektově orientovaného vývoje. Při naplňování metodického vzoru jsem vycházela ze svých zkušeností s objektově orientovaným vývojem software, z metodiky MMDIS 111 a dalších materiálů vytvářených na KIT v rámci vědeckého záměru, z firemních metodik pro vývoj software 112 a z dalších zdrojů, které byly diskutovány v kapitole 4 Zdroje pro návrh metodického rámce. Metodický vzor Nový objektově orientovaný vývoj obecného software vlastními silami je uveden v rámci příloh této disertační práce (přílohy 6 10). Příloha 6 obsahuje vlastní metodický vzor, přílohy 7 10 obsahují další prvky metodického vzoru (role, principy, praktiky, procesy). Příloha 6: Metodický vzor M02 Nový objektově orientovaný vývoj obecného software vlastními silami V této příloze je popsán metodický vzor M02 ve struktuře: metapopis vzoru o identifikace jednoznačný identifikátor a název vzoru, o klasifikace hodnoty klasifikačních kritérií, která byla definována v 5.4, o o účel vzoru charakteristika předmětné oblasti, respektive typu projektu, pro který je metodický vzor určen, vztah k jiným vzorům předchůdci vzoru a vzory se kterými vzor souvisí (odkazuje se na některé jejich části), názvy principů, praktik a procesů, které jsou součástí vzoru, 111 popsané v [Voříšek,1997], [Řepa,1999] 112 například metodika Aquasoft [Stanovská,Sedláček] ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 87

88 fáze MEFIS pro každou fázi IST až PUR její náplň ve struktuře: o název fáze, o účel fáze co je cílem fáze, o náplň v rámci jednotlivých dimenzí náplň fáze (činnosti) jsou uváděny v rámci jednotlivých dimenzí vyvíjeného systému, které byly zavedeny v 5.6.2, o vstupy fáze produkty, které jsou potřeba pro činnosti vykonávané v rámci fáze o výstupy fáze produkty, které jsou výsledkem činností v dané fázi o kritické faktory úspěchu, o brána 113 specifikace hodnotících kritérií pro úspěšné ukončení fáze. Další součásti metodického vzoru Nový objektově orientovaný vývoj obecného software vlastními silami jsou uvedeny v samostatných přílohách: Příloha 7: Role vzoru M02 nový objektově orientovaný vývoj obecného software vlastními silami Role jsou definovány v členění podle kategorií definovaných v podkapitole 5.6.3: celopodnikové role SW inženýrské, celopodnokové role řídící, role zájmových skupin, doménové role, SW inženýrské role v projektu, řídící role v projektu, další role v projektu. Příloha 8: Principy vzoru M02 Nový objektově orientovaný vývoj obecného software vlastními silami Metodický vzor M02 přebírá principy obecného metodického vzoru uvedené v podkapitole Principy obecného metodického vzoru a přidává princip Přírůstkový vývoj založený na službách. Příloha 9: Praktiky softwarově inženýrské vzoru M02 Nový objektově orientovaný vývoj obecného software vlastními silami V příloze 9 jsou definovány příklady softwarově inženýrských praktik, které jsou do značné míry inspirovány praktikami agilních metodik, zejména metodiky Agilní modelování [Ambler,AMWP] [Ambler,6/2003SD] a Extrémní programování [Beck,2002], které byly charakterizovány v a 3.2.8: Efektivní modelování, Efektivní dokumentace, Extrémní testování, Využívání návrhových vzorů. Příloha 10: Procesy vzoru M02 Nový objektově orientovaný vývoj obecného software vlastními silami V příloze 10 jsou popsány procesy metodického vzoru Nový objektově orientovaný vývoj obecného software vlastními silami ve struktuře: vazba na CMM zda je daný proces definován v modelu SW CMM a na jaké úrovni zralosti, cíle procesu jaké jsou cíle, které daný proces naplňuje, 113 Brána není definována pro všechny fáze viz ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 88

89 zodpovědnost role, která odpovídá za proces, vstupy procesu produkty, které jsou na vstupu procesu, výstupy procesu produkty, které jsou výstupem procesu, techniky, které je možné použít pro realizaci procesu, poznámky, náplň procesu činnosti zařazené v rámci jednotlivých fází MEFIS (IST až PUR), kritické faktory úspěchu. V příloze 10 jsou popsány následující procesy: Modelování podnikových procesů, Návrh globální architektury, Řízení portfolia projektů, Řízení požadavků, Specifikace služeb, Analýza a návrh, Implementace, Testování, Předání do užívání, Řízení znovupoužitelnosti, Řízení konfigurací, Řízení změn, Řízení projektu. 5.9 Metamodel metodického rámce MEFIS V podkapitole 4.10 Modelem řízená architektura byl stručně charakterizován modelovací jazyk UML (Unified Modeling Language) a metajazyk Meta Object Facility (MOF), tedy jazyk, ve kterém je možné jazyky 114 modelovat. Jak uvádí [Hřebejk,Řepa] předpona meta v oblasti modelování zpravidla vyjadřuje skutečnost, že nějaký systém, model popisuje (na vyšší úrovni) jiné systémy, jiné modely. V současnosti se metamodelování začíná prosazovat, protože umožňuje zejména: formalizovaně a jednotně vyjádřit prvky a vztahy v rámci modelovaných systémů, snáze porovnat jednotlivé systémy, na základě zabudovaných konstruktů rozšiřovat systémy, sdílet data mezi modely. Z výše uvedených důvodů je metodický rámec MEFIS také popsán metamodelem. Metamodel MEFIS představuje standardizované vyjádření navrženého metodického rámce, poskytuje tak jednoznačnou interpretaci a umožňuje další rozvoj. Metamodel tvoří Diagram tříd (Class diagram) 115 jazyka UML vytvořený v CASE nástroji Rational Rose. Z důvodu omezení rozměru stránek a rozsahu práce je metamodel zjednodušen a rozdělen na několik částí. Protože některé atributy prvků nabývají přesně specifikovaných hodnot (výčet hodnot), jsou na obráku 5.9 definovány tyto hodnoty jako prvky výčet (Enumeration). Obrázek 5.10 zachycuje základní prvky 114 jako například UML, ERD, DFD a další 115 Diagram tříd v UML se shoduje s MOF. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 89

90 metodického rámce a vztahy mezi nimi. Obrázek 5.11 modeluje obsah metodického vzoru a obrázek 5.12 zachycuje hierarchii metodických vzorů MEFIS. Obrázek 5.13 potom ukazuje složky celého metodického rámce MEFIS. <<Enumeration>> IDFaze GST IST RKP UST GAN DAN IMP ZAV PUR <<Enumeration>> IDPerspektivy riz swi <<Enumeration>> IDBrany brgst brist brust brgan brimp brzav <<Enumeration>> DruhPraktiky spol riz vyvoj <<Enumeration>> IDDimenze hw tech data fun ui pra org eko <<Enumeration>> IDVrstvy ent proj obrázek 5.9: Výčtové typy Metrika idmetriky nazev typ vypocet 0..n 0..n Cinnost idcinnosti nazev popis 0..n Technika idtechniky nazev 0..n popis 0..n 0..n Nastroj idnastroje nazev typ Vrstva idvrstvy nazev 1 Brana idbrany nazev kriteria ObsahFazeDimenze obsah +nasledujici +predchazejici Faze idfaze nazev ucel n 0..n 0..n Produkt idproduktu nazev popis 0..n +vstupy/vystupy ObsahProcesFaze obsah 0..n 0..n Role idrole kategorie nazev odpovednost 1 0..n Proces idprocesu nazev cmm cíl poznamky +zodpovida 0..n Vzor 0..n idvzoru 0..n nazev Standard ucel idstandardu popis nazev dokument Dimenze iddimenze nazev +CSF faze 0..n CSF 0..n idcsf nazev 0..n Prakt ika idpraktiky nazev ucel uvahy doporuceni zkusenosti druhpraktiky Princip idprincipu Perspektiva 0..n 0..n idperspektivy nazev nazev 0..n n popis obrázek 5.10:Prvky MEFIS ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 90

91 Faze idfaze nazev ucel Proces idprocesu nazev cmm cíl poznamky n 0..n <<Abstract>> ObecnyMetVzor idvzoru ucel 0..n 0..n 0..n Praktika idpraktiky nazev ucel uvahy doporuceni zkusenosti druhpraktiky 0..n Princip 0..n idprincipu nazev popis obrázek 5.11: Obsah metodického vzoru <<Abstract>> KlasKriterium KlasifDulezitostVelikost kod vyznam KlasifDomena kod vyznam KlasifTypReseni kod vyznam <<Abstract>> ObecnyMetVzor idvzoru ucel KlasifZpusobReseni kod vyznam ProjektovyMetVzor DomenovyMetVzor KlasifPristupkReseni kod vyznam SpecDomenovyMetVzor MetodikaProjektuPS ProjMetVzorPS SpecifikaPlatformy obrázek 5.12: Struktura metodických vzorů ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 91

92 Metaproces idmetaproc nazev popis BazeMetodik BazeProjDat n MEFIS Metaprincip idmetaprincipu nazev popis n BazeVzoru 1..n <<Abstract>> ObecnyMetVzor idvzoru ucel obrázek 5.13: Struktura MEFIS 5.10 Shrnutí kapitoly Tato kapitola je jádrem disertační práce. Popisuje Metodický rámec IS/ICT, jehož návrh je hlavním cílem práce. Nejprve bylo vysvětleno pojetí metodického rámce jako metametodiky (podkapitola 5.1) a vymezena úroveň metametodiky, kterou tvoří metaprincipy a metaprocesy. Báze metodických vzorů představuje úroveň metodiky a definuje principy a procesy metodiky. Specializace metodik pro určité domény, typy řešení, způsoby řešení a pro určité typy projektů je řešena pomocí jednotné klasifikace a hierarchie metodických vzorů, která byla popsána v podkapitole 5.4. Dále byly definovány charakteristiky metodického rámce (podkapitola 5.3) a jeho architektura (podkapitola 5.5). V podkapitole 5.6 byly definovány prvky metodických vzorů, zejména fáze a dimenze. Principy platné pro všechny metodické vzory byly uvedeny v podkapitole Příklad naplnění metodického vzoru byl uveden pro metodický vzor M02 Nový objektově orientovaný vývoj obecného software vlastními silami v podkapitole 5.8, která se odkazuje na přílohy disertační práce V podkapitole 5.9 je uveden metamodel metodického rámce MEFIS. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 92

93 6 Úroveň metametodiky metodického rámce V podkapitole 5.4 Klasifikace metodických vzorů byl popsán koncept metodických vzorů a jejich klasifikace. Metodické vzory reprezentují úroveň metodiky v MEFIS. Při vytvoření metodiky pro konkrétní projekt je třeba vybrat vhodný metodický vzor z báze metodických vzorů, vytvořit jeho instanci a dále ji upravit. Tyto činnosti jsou součástí určitých procesů a uplatňují se při nich určité principy, které jsou označeny jako metaprocesy a metaprincipy. Tuto skutečnost ilustruje obrázek 5.2. Popisem metaprincipů a metaprocesů se zabývá tato kapitola. 6.1 Metaprincipy MEFIS Při vytváření metodiky ve formě metodického vzoru i konkrétní metodiky pro určitý projekt je třeba respektovat určité principy. Při formulaci těchto principů jsem vycházela z principů, které popsal A. Cockburn ve svých článcích [Cockburn,MetSpace] a [Cockburn,MetPerProj] a které doplnil J.Highsmith ve své knize [Highsmith,2002]. MEFIS definuje následující metaprincipy: Metaprincip 1: Dávat přednost interaktivní osobní komunikaci před ostatními formami komunikace. Význam interaktivní komunikace byl diskutován v podkapitole 4.8. Tvůrci metodik by si měli uvědomovat přínosy, které představuje osobní komunikace a navrhovat metodiky tak, aby byl pro tuto formu komunikace dostatečný prostor 116. Metaprincip 2: Velikost týmu a váha metodiky jsou přímo úměrné. Význam pojmu váha metodiky byl vysvětlen v podkapitole Čím je větší počet lidí v týmu, tím roste i objem komunikace mezi nimi. Efektivnost komunikace na osobu s růstem objemu komunikace klesá. Jestliže je metodika způsobem koordinace lidí a řízením jejich komunikace, pak s počtem lidí na projektu musí růst i váha metodiky. Z toho vyplývá, že nemůžeme očekávat, že metodika určená pro malý tým bude správně fungovat pro velký tým. Metaprincip 3: Relativně malé zvýšení váhy metodiky vede k relativně většímu objemu nákladů projektu. Jedná se o jeden z nejdůležitějších metaprincipů, který má velký vliv na úspěch projektu. Můžeme konstatovat, že pro relativně malý počet lidí stačí relativně lehká metodika. S lehčí metodikou pracují lidé produktivněji a mohou tak adresovat větší problém. Na druhé straně, jestliže je do projektu zapojeno více lidí, potřebují více koordinace a tedy i těžší metodiku. Těžší metodika snižuje jejich produktivitu, takže je třeba více lidí pro vykonání stejné práce. Váha metodiky roste naštěstí pomaleji než velikost projektu, takže je možné dosáhnout správného bodu, ve kterém určitý počet lidí může řešit daný problém a současně zvládnout koordinaci. Je ovšem velmi obtížné určit na začátku projektu velikost problému, který je třeba řešit, a určit počet lidí, který postačí pro vyřešení tohoto problému. Druhou nepříjemností je skutečnost, že existuje hranice velikosti problému, který může být řešen s určitým počtem lidí. Tato hranice je vyšší pro velký tým s těžší metodikou než pro malý tým s lehkou metodikou. To znamená, že při určité velikosti problému je třeba mít velký tým a těžkou metodiku. 116 Zatím se totiž metodiky zaměřují většinou na komunikaci písemnou. ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 93

94 Metaprincip 4: Větší váha metodiky je vyžadována na projektu, kde neodhalený defekt způsobí větší škodu (větší důležitost systému). Tento metaprincip zohledňuje kritérium Důležitost systému viz podkapitola Čím je vytvářený systém důležitější pro organizaci, tím těžší musí být metodika pro jeho vytvoření i za cenu vyšších nákladů. Metaprincip 5: Disciplína není formalita, proces není dovednost, dokumentace není pochopení. Tento metaprincip ukazuje nutnost rozlišení mezi dokumentací a pochopením. Poslední výzkumy ukazují, že typický dokument Specifikace požadavků představuje jen 15 20% pochopení, kterého je třeba pro vývoj [Highsmith,2002]. Za této situace musí být dokument Specifikace požadavků jen startovacím bodem a pochopení je třeba dosáhnout na základě komunikace mezi lidmi. Disciplína je nutná, ale může být i neformální. Sebedokonalejší procesy nenahradí dovednosti a kvalifikaci lidí. Tento metaprincip odráží myšlenky agilních přístupů. Metaprincip 6: Zvýšení zpětné vazby a komunikace snižuje potřebu meziproduktů. Potřeba meziproduktů je často vyvolána nemožností přímé komunikace. Protože analytik nemůže komunikovat s návrhářem přímo, vytvoří model a doufá, že mu návrhář porozumí. Jenže modely a množství psané dokumentace nemohou stejně zajistit plné pochopení, navíc jejich tvorba je velmi nákladná. Metaprincip 7: Činnosti, které nejsou úzkým místem, mohou být neefektivní a může to vést ke zvýšení průtoku. Goldratt ve své teorii omezení [Basl,Majer,Šmíra] ukazuje, že nemá smysl usilovat o efektivnost ve všech činnostech. Naopak neefektivnost v některých činnostech skutečně může vést ke zvýšení průtoku (k rychlejší dodávce). To znamená, že lidé, kteří realizují činnosti, které nejsou úzkým místem, musí dělat vše pro minimalizaci času v činnostech v úzkém místě. Metaprincip 8: Zaměření na průtok Je třeba se zaměřit především na ty kroky, které tvoří hodnotu a eliminovat kroky, které hodnotu nepřidávají. Metaprincip 9: Větší formalita metodiky může být vyžadována z bezpečnostních či právních důvodů. 6.2 Metaprocesy MEFIS Metodický rámec IS/ICT, který byl charakterizován v kapitole 5, představuje ucelený rámec metodických přístupů používaných při budování IS/ICT. Tento rámec je v podstatě vzorem, který je třeba přizpůsobit na podmínky organizace a vytvořit tak metodický rámec organizace. Zároveň je třeba tento metodický rámec udržovat, rozvíjet a využívat, to znamená na základě metodických vzorů vytvářet metodiky pro konkrétní projekty. Všechny tyto činnosti jsou součástí metaprocesů, tedy procesů jejichž předmětem je metodický rámec nebo jeho části (například metodické vzory). V následující části disertační práce jsou výše zmíněné metaprocesy charakterizovány. Metodický rámec je reprezentován kolekcí metodických vzorů, které tvoří bázi metodických vzorů. Kromě báze metodických vzorů je vhodné udržovat v organizaci i bázi metodik, které byly vytvořeny pro konkrétní projekty tak, aby je bylo možné dále využívat, zaznamenávat v nich zkušenosti a podobně. Kromě báze metodik doporučuji udržovat i bázi projektových dat, která by obsahovala data konkrétního projektu a sloužila pro analýzy projektů, zdroj pro odhady nákladů, času, pracnosti budoucích projektů (obrázek 6.1). ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 94

95 obrázek 6.1: Báze znalostí MEFIS V MEFIS jsou definovány následující metaprocesy, které zachycuje obrázek 6.2: customizace metodického rámce pro organizaci, vytvoření metodiky pro konkrétní projekt, udržování báze metodik, analýzy a vyhodnocování metodik, rozvoj báze metodických vzorů. V dalším textu jsou tyto metaprocesy charakterizovány. obrázek 6.2: Metaprocesy MEFIS Customizace metodického rámce pro organizaci Metodický rámec MEFIS je vzorem, který je třeba přizpůsobit na podmínky organizace. Toto přizpůsobení je určováno: ALENA BUCHALCEVOVÁ, LISTOPAD 2003 STRANA 95