Informační systém pro řízení projektu vývoje software

ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE FAKULTA ELEKTROTECHNICKÁ KATEDRA KYBERNETIKY

DIPLOMOVÁ PRÁCE Informační systém pro řízení projektu vývoje software

Praha, 2002

Jan Breznay

Prohlášení Prohlašuji, že jsem zadanou diplomovou práci zpracoval samostatně s přispěním vedoucího diplomové práce a používal jsem pouze literaturu v práci uvedenou. Prohlašuji, že nemám námitek proti využití výsledků této práce fakultou ani proti zveřejňování nebo půjčování se souhlasem vedoucího diplomové práce. V Praze, dne 24.5.2002

Poděkování Na tomto místě bych chtěl poděkovat Ing. Petru Mikšovskému a Ing. Zdeňku Koubovi za vedení mé diplomové práce. Dále pak děkuji mým rodičům a přátelům, kteří za mnou po celou dobu studia stáli a podporovali mě.

Abstrakt Cílem této práce bylo navrhnout a implementovat informační systém pro řízení projektu vývoje software. Byla vytvořena aplikace, která přes rozhraní sítě internet nabízí komplexní přístup k řešení vývoje zejména rozsáhlých softwarových produktů, vznikajících jako výsledek týmové práce skupiny vývojářů. Základním prvkem v aplikaci je projekt, ke kterému mohou být přiřazeny různé komponenty zefektivňující práci na softwarovém projektu (diskusní fórum, seznam úkolů, seznam chyb, zdrojové kódy a zveřejňování vznikajících produktů). Správa uživatelů je podpořena možností sdružovat uživatele do skupin. Informační systém byl vytvořen pro vývoj aplikací v Gernstnerově laboratoři Katedry kybernetiky.

Abstract This diploma thesis deals with design and implementation of the Information system for software development project control. Designed application provides through the Internet an integrated access to the large-scale software products development. Application is centered on teamwork. Each registered project can own a few of components to assure teamwork to be effective (mail forum, task list, bug list, file releases, source codes). Application provides user management include availability of user groups. The information system is developed for Gernstner laboratory of the Department of Cybernetics.

Obsah Obsah...................................................................................................................... 1 1

Úvod ................................................................................................................. 3

2

Softwarové inženýrství ................................................................................... 4 2.1

Základní pojmy ......................................................................................... 4

2.2

Specifikace požadavků ............................................................................. 7

2.3

Nástroje pro analýzu systému a návrh SW produktu................................ 8

2.3.1

Modely softwarového procesu.......................................................... 8

2.3.1.1

Vodopádový model ...................................................................... 8

2.3.1.2

Prototypování ............................................................................... 9

2.3.1.3

Spirálový model ......................................................................... 10

2.3.1.4

Další modely............................................................................... 10

2.3.2

Nástroje analýzy systému ............................................................... 11

2.3.3

Metody návrhu systému.................................................................. 13

2.3.4

UML................................................................................................ 13

2.3.4.1

Případy užití ............................................................................... 15

2.3.4.2

Diagramy tříd ............................................................................. 16

2.3.4.3

Diagramy objektů ....................................................................... 18

2.3.4.4

Sekvenční diagramy ................................................................... 18

2.3.4.5

Diagramy spolupráce.................................................................. 19

2.3.4.6

Stavové diagramy ....................................................................... 19

2.3.4.7

Diagramy aktivit......................................................................... 20

2.3.4.8

Diagramy komponent ................................................................. 20

2.3.4.9

Diagramy rozmístění .................................................................. 21

2.3.5

SSADM........................................................................................... 21

2.3.5.1 Hlavní složky SSADM............................................................... 22 2.3.5.2

Struktura SSADM ...................................................................... 23

2.3.5.3

Techniky a postupy .................................................................... 24

2.3.5.4

Specifikace požadavků ............................................................... 26

2.3.5.5

Popis života entit ........................................................................ 28

2.3.5.6

Identifikace uživatelských rolí ................................................... 29

2.3.5.7

Identifikace a návrh dialogů ....................................................... 29 1

2.4

3

Řízení projektu vývoje software ............................................................. 30

2.4.1

Metriky softwarového projektu ...................................................... 30

2.4.2

Odhadování a plánování rozsahu projektu...................................... 31

2.4.3

Řízení rizik a zabezpečení kvality softwarového produktu ............ 32

2.4.4

Řízení změn softwarového produktu .............................................. 32

2.4.5

Testování softwaru.......................................................................... 33

2.4.6

Projektový management ................................................................. 34

IS pro řízení projektu vývoje software ....................................................... 36 3.1

Návrh a implementace ISSDPC.............................................................. 37

3.1.1

Specifikace požadavků na ISSDPC ................................................ 37

3.1.2

Vývojový nástroj systému .............................................................. 39

3.1.3

Server ISSDPC ............................................................................... 39

3.1.4

Databáze ISSDPC ........................................................................... 39

3.1.5

Struktura aplikace ........................................................................... 40

3.1.6

Implementace.................................................................................. 41

3.1.7

Inicializace systému ........................................................................ 41

3.2

Popis ISSDPC z pohledu uživatele......................................................... 43

3.2.1

Uživatelské role .............................................................................. 44

3.2.2

Skupiny uživatelů ........................................................................... 45

3.2.3

Registrace uživatele ........................................................................ 47

3.2.4

Přihlášení uživatele do systému a odhlášení................................... 48

3.2.5

Osobní stránka uživatele................................................................. 48

3.2.6

Administrace systému..................................................................... 49

3.2.7

Projekt (Project) ............................................................................. 52

3.2.8

Seznam úkolů (Task list)................................................................. 53

3.2.9

Seznam chyb (Bug list) ................................................................... 56

3.2.10

Diskusní fórum (Mail forum).......................................................... 57

3.2.11

Zveřejněné soubory (Releases)....................................................... 58

3.2.12

Zdrojové kódy (Source codes)........................................................ 59

3.2.13

Přístupová práva k objektům .......................................................... 59

4

Závěr .............................................................................................................. 62

5

Literatura ...................................................................................................... 63

6

Obsah přiloženého CD.................................................................................. 64

7

Přílohy............................................................................................................ 64 2

1 Úvod Se vstupem počítačů do rozmanitých odvětví činnosti člověka nabývá na významu otázka vývoje software jako dílčího nástroje pro realizaci určitých cílů lidského snažení. Počítače jsou využívány pro řešení stále důležitějších a komplexnějších úloh, kdy se hlavními ukazateli stávají zejména spolehlivost a cena. V současné době dosahuje hardware počítačů již takové úrovně, že v aplikacích s počítačovými systémy jsou tyto ukazatele převážně určeny právě softwarovým vybavením. Rozsah úloh řešených za pomoci software byl impulsem ke vzniku vědní disciplíny zvané softwarové inženýrství. Jelikož vývoj téměř každého softwarového produktu je náročnou a rozsáhlou prací, neobejde se bez týmové práce řady spolupracovníků, kteří musí vzájemně sdílet zdrojový kód projektu, na kterém společně pracují. Musí komunikovat, zveřejňovat požadavky, připomínky a návrhy, zveřejňovat své dílčí výsledky apod. Právě k tomuto účelu slouží informační systém pro řízení projektu vývoje software. Kapitola 2 pojednává o softwarovém inženýrství. Nejprve jsou zmíněny základní pojmy problematiky vývoje software se zaměřením na vývoj rozsáhlých softwarových produktů. Kapitola pokračuje tématem specifikace požadavků. Následuje část věnovaná nástrojům pro analýzu systému a návrh softwarového produktu. Jsou zmíněny základní pojmy a metody analýzy a návrhu a poté jsou popsány dvě konkrétní, v praxi používané,

metody

s odlišným

přístupem

k problematice

analýzy

a

návrhu

softwarového produktu. V závěru kapitoly je zmíněn přístup k problematice řízení projektu vývoje software zejména z pohledu manažera projektu. Kapitola 3 popisuje navrženou aplikaci Informačního systému pro řízení projektu vývoje software. Nejprve je popsána analýza, návrh a implementace tohoto systému. Následují informace nutné k uvedení sytému do provozu a kapitola popisující aplikaci z pohledu uživatele. Jsou zmíněny uživatelské role a každý objekt aplikace je popsán z pohledu všech uživatelských rolí. Zvláštní kapitola je věnována nastavování přístupových práv k vytvořeným objektům. V textu je pro názornost umístěno několik obrázků zachycujících aplikaci v různých stavech.

3

2 Softwarové inženýrství Softwarové inženýrství je podle [1] systematický, disciplinovaný a kvalifikovaný přístup k vývoji, provádění a údržbě softwaru.

2.1 Základní pojmy Systém Systém je množina vzájemně souvisejících objektů či komponent, na kterou nahlížíme jako na celek a která byla vytvořena pro určitý účel. Systém je ohraničený a to, co je vně této hranice, se nazývá okolí, s nímž systém interaguje prostřednictvím svých rozhraní. Analýzou systému rozumíme nacházení faktů, zákonitostí a omezení v systému [2]. Projekt Projekt je dobře definovaná posloupnost činností, která má určen začátek a konec. Je zaměřena na dosažení jistého cíle a je uskutečňována pomocí zdrojů – lidí a prostředků. Projekt je specifická nerutinní akce, která vyžaduje plánování, neboť je problematické stanovit jeho časovou a finanční náročnost. Plánování projektu má za cíl důkladně promyslet to, čeho chceme dosáhnout. Slouží také k sestavení časového harmonogramu a rozpočtu projektu [3]. Softwarový proces Softwarový proces je sada postupů, pravidel a norem pro řízení softwarového projektu. Definuje fáze projektu, produkty, role pracovníků a jejich zodpovědnost, kvalitativní kriteria, použití nástrojů včetně šablon. Softwarový produkt Softwarový produkt je správním či řídícím systémem nad systémem základním, definovaným výše, jakožto výsledek softwarového procesu definovaného v předchozím odstavci. IEEE definuje software jako souhrn programů, metod, pravidel a přidružené dokumentace a dat [4]. Softwarový produkt tedy není jenom programem používaným pouze autorem programu s minimem dokumentace. Takový produkt by byl pro

4

uživatele nedostačující. Software podle [5] znamená průmyslově-kvalitní software, kdy uvažujeme, že je předmětem zájmu jak týmu vývojářů, tak uživatelů. Jako takový tedy zahrnuje kromě programů (ve smyslu uvedeném výše) s vhodným uživatelským rozhraním také adekvátní množství dokumentace a před uvedením do provozu byl řádně systematicky testován. Programování ve velkém Při programování rozsáhlých softwarových produktů se jedná o řešení rozsáhlých programových celků, které řídí, ovlivňují či spoluvytvářejí složitý systém. Nelze tedy aplikovat pouze metodiky určené pro programování v malém, kterými jsou zejména programovací techniky pro návrh dat a algoritmů. Při programování ve velkém je nutná dekompozice projektu na menší celky do takové míry, kdy lze využít technik programování v malém. Při řešení rozsáhlého softwarového projektu se tedy uplatní jak programování ve velkém, tak i programování v malém. Vývoj takového projektu je obvykle řešen v etapách, jež jsou součástí životního cyklu softwarového produktu. Životní cyklus softwarového produktu Životní cyklus softwarového produktu začíná prvotní představou o programu a končí ve chvíli stažení produktu z používání. Životní cyklus každého rozsáhlého softwarového produktu by měl vždy obsahovat následující etapy: Specifikace problému je prvním krokem ke vzniku softwarového produktu. Tato etapa spočívá v zadání problému, jeho specifikaci, prvotních návrzích komunikace s programem a v závěru spočívá v testování vytvořené specifikace. Kvalita specifikace ovlivňuje další fáze vývoje produktu, je proto velmi důležitá. Její úspěch je založen zejména na hojné komunikaci řešitelů se zadavatelem. Analýza sytému si klade za cíl vytvoření logického modelu stávajícího a požadovaného sytému. V této fázi vývoje je velice důležitá komunikace mezi pracovníky provádějícími analýzu a zadavateli projektu, neboť nepochopení požadavků zadavatele může vést k rozsáhlým nežádoucím časovým i finančním následkům. Při analýze je výhodné použít grafických technik, díky jejich srozumitelnosti i pro osoby neznalé metod softwarového inženýrství, neboť takovými osobami většinou zadavatelé projektu jsou. V etapě návrhu systému se uplatňují metody programování ve velkém. Je nutná dekompozice problémů na problémy dílčí, návrh metod řešení jednotlivých problémů

5

a návrh podpůrných prostředků. Velmi důležitá je volba metody návrhu systému, neboť právě na ní závisí časová náročnost návrhu a tím i výsledná cena softwarového produktu. Třetí etapou je implementace, při které se uplatní metody programování v malém. Nejprve je nutné provést návrhy reprezentace lokálních dat, návrhy algoritmů realizujících dílčí problémy. Poté následuje zápis kódu programu a jeho modulů ve zvoleném programovacím jazyce a ladění programu. Po odladění jednotlivých komponent následuje jejich syntéza do požadovaných výsledných celků. Nedílnou součástí kvalitního softwarového produktu musí být dokumentace produktu. Obsahuje nejen příručku k používání produktu, ale také dokumentaci k programu samotnému, dokumentaci pro údržbu a modifikace systému a případně další dokumenty k bezproblémovému nasazení, užívání produktu či jeho stažení z užívání. V další etapě následuje testování produktu. Spočívá ve validaci či verifikaci produktu proti specifikaci vzniklé v první etapě vývoje produktu a proti dokumentaci vzniklé v předchozí etapě. Teprve nyní následuje zadavateli nejvíce očekávaná etapa, kterou je nasazení, provoz a údržba produktu. Začíná v předání softwarového produktu včetně potřebné dokumentace zadavateli, případně v instalaci produktu u zadavatele, bylo-li tak ujednáno. V případě potřeby výroba médií a dokumentace, školení k produktu a podpora. Po uvedení rozsáhlého softwarového produktu do fungování následují opravy chyb objevených při provozu systému a opravy v dokumentaci k produktu. Dále pak vývoj a údržba verzí produktu. Po určité době používání softwarového produktu nastane situace, kdy produkt již nevyhovuje požadavkům uživatelů sytému a jediným řešením je návrh systému nového. V takovém případě se softwarový produkt dostává do poslední etapy, kterou je stažení produktu z používání. Je zřejmé a ze zkušeností vyplývá, že vývoj rozsáhlých softwarových produktů se neobejde bez zpětných kroků, kdy je nutné některé etapy opakovat. Z hlediska efektivity vývoje produktu je však žádoucí vyloučit zpětné kroky přes více etap. V některých případech je ovšem nutné zopakovat i celý cyklus. Existuje proto několik modelů životního cyklu, viz. kapitola 2.3.1.

6

Objektově orientované programování Základním pojmem objektově orientovaného programování je objekt. Objekt je v obecném slova smyslu cokoliv, co jsme citem schopni označit jako objekt. Objekt má svou identitu, vlastnosti, chování a zodpovědnost. Abstrakcí objektu vznikne tzv. třída, která je jakousi šablonou pro podobné objekty. Vlastnosti objektů určují data třídy a chování objektu definuje metody třídy. Objekt je tedy instancí třídy a definujeme tzv. zapouzdření, které znamená umístění dat a metod pracujících nad těmito daty do jediného objektu. Objektově orientovanému programování předchází objektově orientovaná analýza systému, která se zabývá zkoumáním systémů z pohledu objektů. Výhodou objektového přístupu je fakt, že identifikované objekty v pojetí uživatelů i programátorů znamenají totéž. Na základě nalezených objektů se definují jejich třídy. Hledají se jejich společné rysy a generalizací lze dospět ke vzniku tříd nových a vytvořit určitou hierarchii, ve které budou mezi třídami existovat vztahy dědičnosti. Potomek třídy tak „zdědí“ vlastnosti a chování rodičovské třídy a rozšíří je o své vlastní. Hierarchie tříd založených na dědičnosti vede ke vzniku spolehlivějšího a přehlednějšího kódu programu oproti kódu, ve kterém nebylo generalizace využito. Rozsáhlost kódu je snížena při zachování funkčnosti.

2.2 Specifikace požadavků Na počátku softwarového procesu vždy stojí specifikace požadavků. Obvykle probíhá v několika krocích, kdy výstupem každého kroku je určitý dokument, sloužící jako podklad pro řešení dalších kroků. V prvém kroku je vytvořen návrh požadavků, který je obvykle nazýván neformální specifikace nebo též odborný článek. Odborný článek by měl být prvním psaným dokumentem, ovšem jako základ smlouvy mezi zadavatelem projektu a řešitelem sám o sobě není dostačující, neboť použití pouze přirozeného jazyka neposkytuje dostatečně přesnou formu vyjádření specifikace požadavků na softwarový produkt. Dalším krokem při specifikaci požadavků je vytvoření funkční specifikace softwarového produktu. Tento dokument musí být mnohem přesnější než odborný článek, a proto je žádoucí použít při jeho vytváření mnohem formálnější notaci.

7

Požadavky se dělí na funkční a nefunkční. Funkční požadavky určují, jak bude program fungovat, ostatní požadavky jsou zahrnuty v požadavcích nefunkčních. Více informací o tomto dělení požadavků lze nalézt v kapitole 2.3.5.4. Specifikaci požadavků lze rozdělit na neformální a formální. Neformální specifikace je vyjádřena přirozeným jazykem. Je proto poměrně dobře srozumitelná i pro uživatele nezabývající se vývojem software (zadavatele projektu), ovšem může obsahovat jisté nedostatky, které nejsou na první pohled zřejmé a projeví se až v dalších etapách vývoje produktu. Velkou část těchto problémů lze eliminovat zápisem požadavků ve formálním jazyce, jehož sémantika je jednoznačně definována. Poměrně universálním nástrojem je jazyk predikátové logiky, který však není v běžné praxi příliš použitelný. Lze však využít jiné prostředky, např. známé z teorie automatu, nebo BacusNaurovu formu. Pokud máme k dispozici podpůrné nástroje pro zpracování formálních specifikací, je možné je využít k validaci a verifikaci specifikace.

2.3 Nástroje pro analýzu systému a návrh SW produktu 2.3.1 Modely softwarového procesu Model softwarového procesu si klade za cíl naznačit možné způsoby průchodu životním cyklem rozsáhlého softwarového produktu. Modelů existuje hned několik, protože různorodost problematiky vývoje software zabraňuje sjednocení postupů do jediné optimální metody.

2.3.1.1

Vodopádový model

Vodopádový model (viz. Obrázek 2.1), též lineární sekvenční model, je základním modelem životního cyklu softwarového produktu. Je složen z činností, které na sebe navazují a vzájemně se neprolínají. Předpokládá, že výchozí požadavky na softwarový produkt se nebudou během vývoje zásadně měnit. Tento model vývoje softwarového produktu popisuje klasický životní cyklus. Má však některé nedostatky, kterými jsou zejména: •

reálné projekty zřídkakdy sledují jednotlivé kroky v předepsaném pořadí

•

pro zadavatele je ve většině případů obtížné přesně specifikovat požadavky

•

provozuschopná verze je k dispozici až po dlouhé době a většinou s časovou prodlevou. 8

Přes všechny zmíněné nedostatky je vodopádový model vhodnou a používanou šablonou pro přístup k vývoji rozsáhlých softwarových produktů a v každém případě je vhodnější, než náhodný, metodicky neřízený přístup k řešení problému.

definice požadavků návrh systému a SW produktu implementace a testování dílčích částí integrace dílčích částí testování celku provoz a údržba

Obrázek 2.1: Vodopádový model životního cyklu softwarového produktu.

2.3.1.2

Prototypování

Prototypování, na rozdíl od vodopádového modelu, již předpokládá, že nemáme podrobně analyzovaný systém a požadavky na systém nejde dostatečně dobře specifikovat předem. Je založeno na vytváření (programování) prototypů, které slouží k modelování některých vlastností systému. Prototyp je částečnou implementací produktu nebo jeho části v logické či fyzické formě, který prezentuje všechna vnější rozhraní. Prototypování umožní jak zadavateli, tak vývojovému týmu ujasnit si a specifikovat požadavky, včetně jejich interpretace. Prototypování je často využíváno i v jiných modelech a sestává z následujících kroků: 1. sběr a analýza dat 2. rychlý návrh 3. tvorba prototypu 4. vyhodnocení prototypu zadavatelem 5. vylepšení návrhu prototypu 6. jestliže zadavatel není spokojen s prototypem, je nutné opakovat od bodu 2 7. je-li zadavatel projektu spokojen, poté následuje úplný návrh.

9

Prototypování lze většinou aplikovat při vývoji menších systémů anebo na úrovni subsystému systému rozsáhlého, neboť prototypování rozsáhlého systému je obtížné a neekonomické.

2.3.1.3

Spirálový model

Spirálový model je založen na kombinaci prototypování a analýzy rizik. Práce na projektu jsou realizovány tak, aby problémy spojené s klasickým vodopádovým modelem byly cílevědomě minimalizovány. Jednotlivé kroky vývoje produktu známé z vodopádového modelu se ve spirále opakují, ale pokud možno na vyšším stupni zvládnutí problematiky. Spirálový model života softwarového produktu začíná v počátku souřadnic. Směrem od středu ubíhá čas. V každé fázi opakování vodopádového modelu (řez spirálou) se provádí identifikace a řešení rizik. Spirálový model je založen na prioritě tvorby verze s vyšší rizikovostí, tedy části produktu s vyšší mírou rizika jsou realizovány dříve. Nevýhodou spirálového modelu je, že nelze přesně stanovit přesné časové termíny a tím pádem ani finanční rozpočet, což jsou ovšem při vývoji software na zakázku velmi důležité ukazatele. Spirálový model je vhodný při vývoji rozsáhlých systémů.

2.3.1.4

Další modely

Další typy modelů softwarového procesu budou zmíněny jen krátce, neboť jsou vesměs založeny na výše zmíněných modelech. RAD model (Rapid Application Development) je založen na aplikaci vodopádového modelu a spočívá v krátkém vývojovém cyklu (doba trvání do 3 měsíců). Je vhodný pro dobře srozumitelné a dobře vymezené problémy s nízkou úrovní rizik. Problém je rozdělen na samostatné moduly, jejichž vývoj je přidělen jednotlivým týmům pracovníků. Rychlý vývojový cyklus je umožněn zejména častým využíváním již hotových softwarových komponent. Přírůstkový (evoluční) model kombinuje vodopádový model s iterativní filosofií. Produkt je vytvářen po částech, tzv. přírůstcích, které jsou funkční, na rozdíl např. od prototypu. První přírůstek je označován jako jádro. Tento model je vhodný pro malý tým a rozsáhlý úkol, jehož vývoj lze zvládnout po částech v předem domluvených termínech.

10

Model skládání komponent je založen na spirálovém modelu a je určen pro technologie s objektovým přístupem k softwarovému procesu. Při vývoji se využívá hotových knihoven tříd objektů. Model souběžného vývoje modeluje vývoj softwarového procesu jako paralelní procesy, kdy jsou jednotlivé komponenty vyvíjeny souběžně. Tento model je vhodný např. pro aplikace typu klient/server. Formální metody vývoje spočívají na formálních specifikacích a podporují formální verifikaci produktů. Praktickému nasazení takových metod zatím brání jejich časové a finanční nároky, nároky na vysokou kvalifikaci řešitelů a jejich obtížnost při komunikaci se zadavatelem projektu. Tzv. techniky čtvrté generace jsou založeny na programování s vysokou úrovní abstrakce. Jejich výhodou je zvýšení produktivity a tím rychlosti vývoje. Nevýhodou některých prostředků určených pro tento způsob vývoje je srovnatelná složitost s programovacími jazyky, užívanými při aplikaci předchozích metod. Další nevýhodou je fakt, že výsledný kód generovaný těmito prostředky nemusí být dostatečně efektivní. Perspektivní metody vývoje software by mohli spočívat ve využití CASE nástrojů ve spojení s modelem skládání komponent.

2.3.2 Nástroje analýzy systému Stěžejní část analýzy systému je založena na tvorbě modelů systému. Důvodem modelování je fakt, že nejsme schopni plně pochopit komplexní systém jako celek. Cílem modelování je porozumět problému, komunikovat prostřednictvím modelů se zadavateli a uživateli. Modely umožní odhalit řadu chyb a opomenutí, simulují složité situace, umožní plánovat návrh a generovat kód. Modely odstraňují možnou jazykovou bariéru a umožňují vidění problému všemi zainteresovanými stranami ze stejného pohledu. V první fázi se modeluje stávající systém, poté následuje tvorba modelu systému požadovaného. Vždy lze na systém pohlížet několika způsoby. Vnikají tak různé pohledy na systém a tedy i různé modely systému. Model by měl hovořit slovníkem uživatele modelu, oddělovat podstatné od podružného a oddělovat koncept a implementaci.

11

Diagramy datových toků Nazývány též procesní modely, diagramy toků práce, funkční modely, bublinové diagramy, ale nejčastěji diagramy datových toků, DFD (Data Flow Diagrams). Představují síťovou reprezentaci systému. Reálné systémy jsou většinou natolik rozsáhlé, že je nelze popsat jediným diagramem. Proto se používá stromová struktura, v jejímž kořeni je tzv. kontextový diagram. Existuje několik druhů notací, přičemž jedna z nepoužívanějších je součástí metody SSADM (viz. kapitola 2.3.5.3). Modely vnějšího chování Tyto modely mohou být reprezentovány např. výše zmíněným kontextovým diagramem, dále potom seznamem událostí, které působí na systém z jeho okolí. Datové modely Datové modely, tzv. E-R diagramy jsou jádrem analýzy při návrhu databázových systémů. Datové modelování se uplatňuje zejména u informačních systémů, neboť tyto systémy pracují z rozsáhlým množstvím dat. Modelují objekty v systému a vztahy mezi nimi pomocí tabulek. Obrázek 2.2 znázorňuje logický model vztahu mezi uživatelem a skupinou uživatelů v příkladu informačního systému. Jeden uživatel může být v několika skupinách uživatelů a současně jedna skupina uživatelů může sdružovat několik uživatelů. kardinalita

N

uživatel

je ve skupině

(1,N)

id uživatele

jméno uživatele

M (1,M)

skupina uživatelů

parcialita id skupiny

primární klíč

primární klíč

Obrázek 2.2: Příklad logického modelu části databáze.

12

jméno skupiny

2.3.3 Metody návrhu systému Obecně rozeznáváme dva možné přístupy k návrhu systému Přístup zdola nahoru je založen na generalizaci. Začíná identifikací a analýzou několika jednoduchých struktur. Snaží se najít jejich společné charakteristiky a chování a zobecnit je tak, aby původní byly jejich speciálními případy. Typickým příkladem, kde je tento přístup aplikován, je objektově orientovaná analýza. Vychází z objektově orientovaného programování. Pohlíží na svět jako na soustavu spolupracujících objektů. Tento přístup je poměrně blízký lidskému chápání a přináší kvalitativní změnu myšlení při návrhu systémů. Výhodou je možnost rychlého paralelního vývoje prototypového softwaru. Nevýhodou je nedostatek ověřených metodických postupů a hlubší zkušenosti s rozsáhlými systémy. Konkrétní metodou využívající přístup k návrhu systému zdola nahoru je UML (Unified Modeling Language), který je popsán v kapitole 2.3.4. Přístup shora dolů je založen naopak na specializaci. Začíná na úrovni komplexního systému, který postupně dekomponuje na subsystémy. Ty jsou dále dekomponovány až na úroveň, kdy je možná implementace. Analytický proces je zobrazitelný stromovou strukturou s originálním systémem v kořeni. Typickým příkladem tohoto postupu je strukturovaná analýza. Je metodicky velmi dobře zvládnuta. Její nevýhodou je absence možnosti ukončit předčasně analýzu a implementovat konkrétní část systému. Konkrétní metodou využívající k návrhu systému metodu přístup shora dolů je SSADM (Structured Systems Analysis and Design Method), která je popsána v kapitole 2.3.5.

2.3.4 UML UML (Unified Modeling Language) je standardizovaným jazykem pro specifikaci, vizualizaci, konstrukci a dokumentování systémů, nejen softwarových. Jeho použití zefektivňuje softwarový proces na základě standardní notace zejména použitím přehledných a snadno pochopitelných diagramů a schémat, čímž snadno překonává sémantickou mezeru mezi vnímáním skutečností uživateli a řešiteli systému. Dále pak slouží ke zlepšení a zpřesnění komunikace mezi členy vývojového týmu (analytici, vývojáři, testeři, vedoucí pracovníci apod.). Jeho výhodou je podpora celého vývojového cyklu software. UML poskytuje pravidla pro pojmenování, rozsah platnosti, rozsah viditelnosti, integritní omezení a provedení modelu.

13

Základní principy UML lze nastínit následujícími body: •

na každý složitý problém je vhodné nahlížet z více úhlů pohledu

•

každý model může být vyjádřen s různou přesností

•

nejlepší modely jsou spojeny s realitou.

Prvky modelů Rozlišujeme prvky struktury, prvky chování a prvky skládání. Prvky struktury tvoří třídy, rozhraní, spolupráce, případy užití, aktivní třída, komponenta, uzel. Prvky chování jsou interakce a stavový diagram. Prvky skládání jsou package a subsystém. Dalším možným prvkem je poznámka. Vztahy mezi prvky jsou popsány závislostmi, asociacemi, dědičností nebo realizací. Způsoby rozšiřování modelů Jedním ze způsobů rozšiřování modelů jsou stereotypy. Stereotyp je šablona určitého typu prvku či vlastnosti. Význam stereotypu definuje autor modelu. Stereotyp se zapisuje mezi závorky

„<<“ a „>>“. Stereotypovaný prvek může mít vlastní

grafickou reprezentaci. Dalšími způsoby rozšíření modelu jsou přidané atributy, což jsou textové informace přidané k jednotlivým prvkům modelu. Někdy je nutné rozšířit vazby v modelu o určitá omezení. Omezení je přídavná informace upřesňující danou vazbu. Zapisuje se do složených závorek. Lze ji psát přirozeným jazykem, ale existuje také formální jazyk, označovaný OCL (Object Constraint Language), sloužící k zápisu omezení k prvkům objektově orientovaného modelu. Na základě takto vyjádřených omezení lze testovat konzistenci modelu. UML definuje následujících devět typů diagramů, popisující různé pohledy na model systému [6]. •

Případy užití, tzv. Use Case diagramy

•

Diagramy tříd

•

Diagramy objektů

•

Diagramy komponent

•

Diagramy rozmístění

14

•

Sekvenční diagramy

•

Diagramy spolupráce

•

Stavové diagramy

•

Diagramy aktivit

Prvních pět typů diagramů modeluje statický pohled

na systém, zbývající

představují pohled dynamický. Diagramy musí být sémanticky konzistentní s dalšími pohledy na systém.

2.3.4.1

Případy užití

Případy užití (Use Cases) zachycují funkce, které systém poskytuje svému okolí a definují využití těchto funkcí. Umožňují zadavateli projektu ověřit, zda systém modelovaný pomocí případů užití splňuje představu o funkcionalitě. Zvyšují porozumění systému a určují jeho rozhraní. Slouží jako základ uživatelské dokumentace a různých testů. Případ užití je popsán dokumentem, který obsahuje jméno, stručný popis, tok událostí (základní, alternativní), speciální požadavky, podmínky před a po případu užití, způsoby rozšíření a vizualizace formou diagramů. Diagramy případu užití jsou tvořeny následujícími UML prvky: •

případy užití jsou ovály, zachycující funkčnosti systému

•

aktéři jsou schematické postavičky, znázorňující aktéry, kteří pracují se systémem (vstupují do něj, používají ho)

•

asociace jsou čáry, představující vazby mezi aktéry a případy užití

•

vztahy jsou čáry opatřené šipkou, určující vazby mezi jednotlivými případy užití.

Každý případ užití představuje určitou funkcionalitu systému, která dává měřitelnou hodnotu uživatelům tohoto systému. Aktéři představují určité zachycení okolí systému. Představují prvky aktivně komunikující se systémem. Aktéry mohou být buď uživatelé, či spíše uživatelské role nebo jiné softwarové systémy. Aktér je stereotypem třídy, je to tedy třída. Pomocí Asociace komunikuje aktér se systémem, vyvolává a účastní se případů užití. U diagramů případů užití obvykle nemají asociace přiřazené jméno.

15

Vztahy mezi případy užití umožňují případům užití vzájemnou spolupráci. Jsou definovány dva typy vztahů – include a extend. Jsou rozlišeny pomocí tzv. stereotypů, v tomto případě se jedná o stereotyp závislosti. Vazba typu include definuje, že případ užití A musí povinně vykonávat to, co případ užití B, případně něco navíc. Vazba extend znamená, že případ užití A rozšiřuje chování B. B může tedy za určitých okolností provádět funkčnost A. V diagramech případů užití lze zavést vazbu dědičnosti. Jedná se o tzv. generalizaci, která je definována mezi rodičem a potomky. Generalizace mezi dvěma případy užití se využívá v případě, že jeden případ užití je podobný druhému, přičemž se liší v malých částech, nikoliv zanedbatelných. Specifikace rodiče je základem specifikace potomků, tedy obsahuje základní kostru použitou ve všech potomcích. Specifikace potomků upřesňují popis rodiče (každý potomek má jinou funkčnost).

2.3.4.2

Diagramy tříd

Diagramy tříd zachycují slovník systému. Třída je zapouzdřením určitých informací a chování. Informace budeme označovat jako atributy třídy a chování jako metody třídy. Atributy třídy představují informace, které instance třídy (objekty) uchovávají. Metody třídy jsou operace, za které je třída zodpovědná, nebo také zprávy, kterým rozumí. Zdrojem atributů třídy jsou věcné znalosti o dané problematice a analýza podrobných požadavků uživatelů. Atributy třídy by měli být atomické, tedy dále nedělitelné, což částečně odpovídá první normální formě E-R modelu. Pokud by měl být atribut strukturovaný, lze ho nahradit vlastní třídou a asociací. Zdrojem pro hledání operací jsou především scénáře analýzy případů užití. Vytváří se model, který zatím nenavrhuje software, ale zjišťuje, co budoucí software musí umět. Mezi třídami mohou existovat různé vztahy. Sdílení informací mezi třídami lze dosáhnout pomocí asociace a agregace. Komunikaci mezi třídami lze zajistit pomocí asociace, agregace a závislostí. Hierarchii tříd lze vybudovat pomocí vazeb asociace, agregace, dědičnosti a realizace interface. Asociace je slabá vazba mezi třídami. Říká to, že dvě třídy mají mezi sebou vztah, tedy o sobě „vědí“. Není-li uvedeno jinak, je tato vazba obousměrná. Asociace může mít své jméno, které většinou dává smysl při čtení jedním směrem. Kreslí se plnou čarou spojující příslušné objekty. 16

Agregace je silnější forma asociace. Představuje vztah mezi celkem a částí. Agregace znázorňuje fakt, že instance části vzniká a zaniká společně s celkem. Agregace se kreslí plnou čarou, která spojujíce dané objekty, přičemž na konci čáry u objektu představujícího celek se kreslí značka ve tvaru kosočtverce. Asociace i agregace je binární vztah mezi třídami. Každý konec této vazby představuje roli, kterou daná třída ve vazbě hraje. Každou roli lze pojmenovat a určit její násobnost (kardinalitu). UML používá mechanismus explicitního vyjádření násobnosti (0..1, 0..*, 1, 1..*). Násobnost role určuje, kolik instancí třídy hrající danou roli existuje vůči jedné instanci na druhé straně. V některých případech je nutné pro vazbu mezi třídami definovat další pravidla či omezení. Omezení jsou většinou poplatná věcné logice a píší se k vazbě do složených závorek. V případě, kdy asociace sama nese nějaké informace, které nejsou atributy ani jedné z asociovaných tříd, umístí se tyto atributy do separátní, tzv. spojovací třídy. Obrázek 2.3 ukazuje příklad spojovací třídy. Třída s atributy asociace je s asociací propojena přerušovanou čarou.

Přístupová práva typ práva

Uživatel

0..*

0..*

Objekt

má právo přístupu k

Obrázek 2.3: Příklad spojovací třídy příslušející vazbě mezi dvěma třídami.

Dalším typem vazby mezi třídami je závislost. Popisuje komunikační vazby mezi třídami a v pozdějších fázích návrhu slouží k odvození datového modelu. Používá se pro vyjádření vztahu mezi poskytovatelem služby a klientem (např. v aplikacích typu klient/server). Znázorňuje se přerušovanou čarou orientovanou k poskytovateli služeb. Vztah mezi třídami podle hierarchie společných vlastností zachycuje vztah generalizace. Znamená dědičnost a značí se plnou čarou s trojúhelníkovou šipkou ve

17

směru k obecnější třídě (předkovi). Obrázek 2.4 ukazuje příklad vztahu dědičnosti mezi třídou nazvanou „objekt“ a třídami odvozenými s názvy „Projekt“ a „Úkol“.

Objekt

Projekt

Úkol

Obrázek 2.4: Příklad vazby dědičnosti mezi dvěma třídami

Potomek dědí celou specifikaci svých předků, tedy atributy i metody třídy. Viditelnost prvků je dána způsobem, jakým jsou děděny. Většina programovacích nástrojů s podporou objektově orientovaného programování podporuje rozdělení atributů a metod tříd do skupin public, protected a private. Prvky ze skupiny public a protected jsou v potomkovi přístupné, private nikoliv. Generalizace je často používána pro definování společného rozhraní tříd, zajištění tzv. polymorfismu. Pro zajištění polymorfismu je však výhodnější pracovat s tzv. interface. Interface je stereotypem, který definuje určitý protokol. V UML je interface značen stejně jako generalizace, ale přerušovanou čarou.

2.3.4.3

Diagramy objektů

Diagramy objektů zachycují vazby mezi instancemi tříd. Jedná se tedy o speciální případ diagramu tříd. Téměř každá třída má více instancí, tedy objektů. Diagram objektů se kreslí jen pro tzv. prototypové objekty, které plně charakterizují všechny ostatní objekty. Reprezentuje stav systému v určitém časovém okamžiku. Pro zachycení časového vývoje systému se používá se používá sekvenční diagram (viz. níže). Diagramy objektů se kreslí zejména tehdy, když jsou mezi objekty možná komplikovaná propojení.

2.3.4.4

Sekvenční diagramy

Sekvenční diagramy modelují dynamické chování systému. Zachycují interakci mezi objekty v čase. Objekty spolu komunikují pomocí zasílání zpráv, což je v aplikaci 18

realizováno např. voláním funkcí. Sekvenční diagram popisuje jeden průchod zpráv systémem (případem užití). Jelikož nemá přímé výrazové prostředky pro větvení, smyčky a podmínky, vybíráme pouze takový scénář, který nám přináší největší funkční hodnotu.

2.3.4.5

Diagramy spolupráce

Diagramy spolupráce zachycují dynamické chování systému s ohledem na spolupráci. Zachycují interakci mezi objekty s ohledem na časovou posloupnost. Slouží pro pozdější určení vztahů mezi objekty. Datové vztahy určují distribuci informací a komunikační vztahy určují spolupráci mezi objekty. Diagram spolupráce, v porovnání se sekvenčním diagramem, zvyšuje přehlednost propojení mezi objekty. Diagram spolupráce používáme vesměs pro stejné případy jako sekvenční diagram. Nepoužíváme ho však pro zjištění časových interakcí, nýbrž pro zjištění spolupráce mezi objekty a zjištění jejich vazeb.

2.3.4.6

Stavové diagramy

Stavové diagramy zachycují dynamické chování objektu, orientované na zprávy a přechody. Stav objektu je dán hodnotami jeho atributů a může ovlivňovat chování objektu. Stavový diagram může obsahovat počáteční stavy, koncové stavy a mezistavy. Stavy jsou propojeny přechody, které jsou spouštěny událostmi. V rámci jednoho stavu lze definovat akce, které nastávají při příchodu do stavu, v průběhu stavu a při opuštění stavu. Je možné definovat podmínky pro přechody mezi jednotlivými stavy, což je nutné zejména tehdy, když jedna událost může vést k různým stavům. Je definován tzv. superstav, což je množina stavů, ze kterých vedou přechody do stejného stavu. Z globálního hlediska nás pak nezajímají vnitřní stavy, ale pouze stav superstavu. Superstav je aktivní, je-li aktivní nějaký jeho vnitřní stav, a neaktivní, neníli aktivní žádný jeho vnitřní stav. Stavový diagram popisuje chování jednoho objektu. Je vhodné jej sestrojit tehdy, když se chování objektu liší v závislosti na jeho stavu. Dále pak v případech, kdy nevíme, jakých stavů objekt může nabývat, nebo potřebujeme-li znát všechny přechody vedoucí z/do požadovaného stavu objektu. Není vhodné ho použít v takových případech, kdy objekt spolupracuje s jinými objekty nebo když je objekt z hlediska stavů nezajímavý.

19

2.3.4.7

Diagramy aktivit

Diagramy aktivit zachycují dynamické chování systému s orientací na aktivity. Zachycují chování mající několik paralelních procesů a popisují sekvenci aktivit s podporou podmíněných větví a paralelního chování. Diagram aktivit je typem stavového diagramu, kde je většina stavů definována jako aktivita. Struktura diagramu aktivit se může skládat z následujících UML prvků: počáteční stav, aktivita, uzel podmíněného větvení, uzel sloučení, vidlice, spoj, konečný stav. Diagram aktivit ukazuje, že jednotlivé aktivity se mohou vyskytovat paralelně nebo sekvenčně. Vhodný je zejména pro paralelní programování, protože umožňuje zachytit vlákna procesů a jejich synchronizace. Pod pojmem aktivita rozumíme stav, ve kterém lze zaznamenat určitou činnost. Činností rozumíme jakýkoliv proces vytvářený v reálném světě nebo volání nějaké programové rutiny. Uzel větvení má jeden vstupní přechod a několik podmíněných výstupních. Uzel sloučení představuje sloučení jednotlivých větví vzniklých v uzlu větvení, má tedy více vstupů a jeden výstup. Vidlice umožňuje rozdělení jednoho přechodu do potřebného počtu paralelních větví, které tak vytvářejí paralelní vlákna, procesy. Je-li spuštěn vstupní přechod vidlice, stanou se aktivní všechny přechody výstupní. Každé vidlici musí být přiřazen spoj, který spojuje vlákna vidlicí vytvořená. Spoj se stává aktivním v případě, kdy jsou všechny vstupní přechody aktivní. Takto je realizována tzv. synchronizace vláken. Diagram aktivit se používá většinou ve spojení s ostatními diagramy. Nejvíce se hodí na zobrazení paralelního chování, zobrazení složitého sekvenčního algoritmu a při programování aplikací s více vlákny.

2.3.4.8

Diagramy komponent

Diagramy komponent zachycují fyzickou strukturu implementace. Cílem softwarového procesu je vytvořit software a např. třída je příliš „drobný“ prvek pro globální popis celého systému. Komponenta je v globálním pohledu na produkt cokoliv, co

programátor

použije

(systém,

aplikace,

knihovna,

prvek

GUI

apod.).

V komponentově orientovaném vývoji jsou třídy mapovány do komponent. Diagram komponent zachycuje vztahy mezi komponentami, např. jejich závislost. Komponenta je na rozdíl např. od třídy nezávislá na programovacím jazyku, lze dobře pochopit její význam a po inicializaci funguje. Komponenty vznikají při použití

20

modulární architektury a poté jsou integrovány do systému. Jejich výhodou je možnost opětovného použití při řešení stejného problému v jiných systémech. Vývoj systému lze urychlit právě sestavováním systému z nakoupených komponent.

2.3.4.9

Diagramy rozmístění

Diagramy rozmístění zachycují hardwarovou topologii systému. Ukazují fyzickou strukturu softwarových a hardwarových komponent a jejich vazby. Nejefektivnější využití diagramu rozmístění získáme v případě, spojíme-li ho s diagramem komponent. Zachycují se ty komponenty, které mají globální význam a mají pod sebou ucelenou část softwarového produktu (databáze, konfigurace, interface apod.). V diagramu rozmístění se zachycují uzly, zařízení a komunikační kanály.

2.3.5 SSADM SSADM (Structured Systems Analysis and Design Method) je metoda návrhu systému přístupem shora dolů. Obrázek 2.5 ukazuje rozsah působnosti této metody v životním cyklu softwarového produktu.

strategie rozsah SSADM studie proveditelnosti

opravy chyb a údržba

specifikace požadavků

nasazení produktu

funkční specifikace

přejímací testování integrace a testování

návrh sytému implementace

Obrázek 2.5: Rozsah SSADM v životním cyklu softwarového produktu.

21

2.3.5.1

Hlavní složky SSADM

Strukturální model Strukturální model je soubor modulů, z nichž každý zahrnuje jednu až dvě etapy. Každá etapa je určena posloupností kroků spolu se vstupy, výstupy a dalšími závislostmi. Jednotlivé kroky jsou popsány z hlediska cílů, zúčastněných složek, prováděných aktivit, vstupních podmínek (prerekvizit), výstupů a použitých technik. Požadavky na nový systém jsou analyzovány spolu s poznatky o současném systému a jsou vytipována omezení, za kterých bude nový systém provozován. Tyto znalosti se spolu s požadavky uživatelů použijí k návrhu základních rysů systému. Na základě tohoto popisu se provede detailní analýza všech požadavků, zahrnující modelování systému z různých hledisek. Tyto modely jsou vzájemně kontrolovány na konzistenci, přičemž některé funkce mohou být pro názornost prototypovány. Následuje volba platformy pro implementaci systému a provede se detailní logický návrh sytému a návrh uživatelského rozhraní. Na závěr se kompletní logická specifikace systému implementuje ve zvoleném programovacím prostředí. Techniky a postupy Techniky a postupy předepisují, jak mají být jednotlivé aspekty systému modelovány a jak mají být potřebné informace shromažďovány a dávány do souvislostí. Techniky používají následující diagramy: •

Logický datový model

•

Model toku dat

•

Model entita/událost (tzv. E/E model)

•

I/O struktury

•

Model uživatelského rozhraní

•

Modely přístupu k datům

•

Logický návrh databáze

Dále mohou být využity některé další techniky a postupy: •

Analýza relačních dat

•

Definice požadavku

•

Definice funkcí systému

•

Formulace variant

•

Prototyp specifikace 22

Slovník SSADM Slovník SSADM definuje veškeré výstupy této metody, popisuje jejich kvalitativní úroveň, informační obsah a vzájemné vztahy. Projektové postupy Projektové postupy jsou další prováděné relevantní aktivity, které však nejsou přímo součástí SSADM. Zahrnují správu projektu, kvalitativní kriteria, kapacitní plánování aj.

2.3.5.2

Struktura SSADM

Struktura SSADM je založena na konceptu modulů. Studie proveditelnosti Studie proveditelnosti si klade za cíl rozhodnout o tom, zda je reálné, aby systém splnil očekávané cíle a zda vyváží přínos systému očekávané náklady. Měla by zhruba definovat rámec a cíle projektu. Výstupem je studie proveditelnosti. Analýza požadavků Účelem analýzy požadavků je přehledově definovat požadavky na nový systém na základě systému stávajícího a dokumentovat další požadavky uživatele na nový systém. Prvním krokem analýzy požadavků je analýza funkce, dat a kategorií uživatelů současného systému. Následuje zjištění požadavků na nový systém a formulace jeho základních rysů. Výstupem je analýza požadavků. Specifikace požadavků V tomto modulu se detailně definují požadavky na nový systém. Konkretizují a kvantifikují se požadavky na systém, vzešlé z předchozí analýzy požadavků. Data a funkce jsou popsány použitím několika technik z různých hledisek. V některých případech se používá prototypování, zejména uživatelského rozhraní. Koncové výstupy specifikace požadavků jsou katalog dat, katalog požadavků a specifikace zpracování. Mezi-výstupy specifikace požadavků jsou diagramy datových toků DFD (viz. níže) požadovaného systému, E/E matice (viz. níže), relační model, uživatelské role v systému a prototypy.

23

Logický návrh systému Logický návrh systému poskytuje detailní specifikaci průběhu zpracování informací v systému a požadavků na interakci s uživateli. Popisuje prostředí nového systému z technického hlediska. Logický návrh systému může probíhat ve dvou paralelních větvích. Jednak výběr, zhodnocení a zdokumentování technického okolí systému a jednak detailní a strukturovaný popis procedur a uživatelských dialogů. Výstupem je zvolené technické řešení, popis technického okolí systému a logický návrh. Fyzický návrh systému Fyzický model systému slouží jako spojovací článek mezi logickým návrhem systému a vlastní implementací. Obecné zásady pro vývoj a systémovou dokumentaci jsou obvykle ovlivněny organizací uživatele systému. Konkrétní metody implementace závisí na zvoleném hardwarovém a softwarovém vybavení.

2.3.5.3

Techniky a postupy

Techniky a postupy využívají následující diagramy: Modely datových toků (DFM) Model datových toků, tzv. DFM (Data Flow Model), je nejčastěji prezentován formou diagramů datových toků. Diagramy datových toků, tzv. DFD (Data Flow Diagrams), popisují toky dat v systému a jejich integraci s okolím. Specifikují zdroje a cíle dat, jejich transformace (hrubě) a identifikují místa (databáze), kde se data uchovávají. Slouží též k identifikaci hranice systému, přičemž zdroje i cíle dat mohou být vně systému. Diagram datových toků tvoří: •

Procesy, které reprezentují transformaci nebo manipulaci s daty.

•

Datové toky, které tvoří kanály mezi ostatními elementy, jimiž mohou proudit předdefinované množiny dat.

•

Datové sklady, obsahující uložená data. Mohou být tzv. hlavní, které jsou persistentní, nebo přechodné, v nichž se data ukládají dočasně.

24

Různé modely datových toků se mohou od sebe mírně lišit ve formálním zápisu v závislosti na využití pro konkrétní účel. Model datových toků se používá v několika etapách SSADM, jako: •

Současný fyzický DFM

•

Logický DFM

•

DFM požadovaného systému

DFM obsahuje: •

DFD vrstvené do úrovní

•

Popis elementárních procesů

•

Popis vnějších entit

•

Popis vstupů / výstupů

Současný fyzický DFM Současný fyzický DFM reprezentuje datové toky a s nimi související procesy v současném systému. Obvykle je složen z následujících prvků: •

Kontextový diagram, který uvažuje celý systém jako jeden blok

•

Diagram toku dokumentů, který popisuje, jak v současném systému putují dokumenty a formuláře a jaký je jejich smysl

•

Diagram toků zdrojů, který specifikuje toky „hmoty“ (ne informací)

Toky zdrojů a toky informací musí být konzistentní. DFM požadovaného systému Model datových toků požadovaného systému je založen na specifikaci funkce nového systému. Je vyjádřen diagramem, který používá následující notaci: •

Externí entity jsou znázorněny ovály, jsou označeny malým písmenem

•

Procesy jsou znázorněny obdélníky a identifikátorem procesu je číslo

•

Datové sklady jsou zprava otevřené obdélníky, označované „D“ plus číslo

•

Datové toky jsou znázorněny čarami se šipkou na konci a popisem obsahu dat

V rámci jednoho diagramu se duplikovaným datovým skladům nebo externím entitám přidává pruh. Hvězdička v pravém dolním rohu obdélníka procesu značí, že proces není dále dekomponován a existuje pro něj popis. Tečkovaný datový tok mezi externími entitami značí důležitý datový tok za hranicí systému. 25

Dekomponovatelné procesy jsou dále dekomponovány v dalších úrovních. Identifikátory procesů jsou vytvářeny z čísla dekomponovaného procesu a nového pořadového čísla, oddělených tečkou. Prostředky pro dočasné uložení dat jsou značeny „T“ plus číslo dekomponovaného procesu a nového požadovaného čísla, oddělených znakem „/“. Obrázek 2.6 znázorňuje příklad diagramu datových toků.

1

Registrace nového uživatele

1.1

a návštěvník informace o uživateli

příjem formuláře informací o uživateli

T1 uživatelé čekající na registraci *

D1 registrovaní uživatelé 1.2 b administrátor systému

registrace schválena

proces schválení registrace uživatele

D2 zamítnutí uživatelé *

e-mail s informací o schválení či neschválení

registrace zamítnuta

a návštěvník

Obrázek 2.6: Příklad diagramu datových toků.

2.3.5.4

Specifikace požadavků

Specifikace požadavků metody SSADM nepoužívá diagramy. Pokrývá potřeby analýzy funkčních a nefunkčních požadavků. Specifikace požadavků se používá od počátku projektu ke sběru a dokumentaci uživatelských požadavků zadavatele projektu. Požadavky na sytém jsou zapsány v tzv. katalogu požadavků. Příklad listu z katalogu požadavků lze nalézt např. v [2]. Funkční požadavky Funkční požadavky v sobě zahrnují aktualizace, dotazy, reporty, data, rozhraní vůči jiným systémům apod. V průběhu softwarového procesu jsou upřesňovány, neboť např. modelování ukáže nutnost jejich korekce. Některé požadavky se mohou dostat vzájemně do konfliktu, což opět vyvolá jejich aktualizaci. Při doplňování dalších

26

nefunkčních požadavků (viz. níže) může vyvstat potřeba změny některých funkčních požadavků. Nefunkční požadavky Nefunkční požadavky popisují jak, v jaké kvalitě a na jaké úrovni mají být určité požadavky splněny. Dále potom mohou sloužit k popisu množiny přípustných hodnot. SSADM definuje některé kategorie nefunkčních požadavků: •

Požadavky na úroveň služeb definují vlastnosti sytému z hlediska dostupnosti

služeb

v čase,

doby

odezvy,

spolehlivost

systému,

propustnosti systému (počet transakcí za časovou jednotku) •

Omezení přístupu specifikuje oprávnění jednotlivých uživatelů v rámci systému

•

Zabezpečení systému proti nečekaným selháním, mechanismy a perioda zálohování systému, zotavení z chyb

•

Monitorování a logování může být požadováno pro účely dokumentace užívání a běhu systému

•

Omezení při návrhu systému, daná např. rozhraním vůči jiným systémům, ergonomická rozhraní vůči uživatelskému rozhraní, požadavky na konverzi dat (může být i funkční požadavek)

Funkční specifikace Funkční specifikace je jádrem analýzy a návrhu celého systému. V rámci funkční specifikace budeme funkcemi rozumět jednotky, které jsou z hlediska uživatele rozeznatelné jako mechanismy fungování systému. Jednotlivé funkce se identifikují na základě katalogu funkcí, diagramu datových toků a E/E modelu. Dokumentace ke každé funkci se nazývá definice funkce. Veškeré funkce by měly odpovídat obecnému funkčnímu modelu, který se skládá ze standardizovaných komponent. Poskytuje charakteristiku funkce pomocí procesů a datových toků. Procesy rozumíme proces vstupu, proces aktualizace či dotazu, proces výstupu a proces zpracování chyb. Datovými toky jsou vstup, chyby syntaxe či řízení, události či dotazy, vstupy a výstupy databáze, výstup aktualizace či dotazu, chyby integrity, platný a chybový výstup. Funkce mohou být odvozovány z několika zdrojů. Aktualizační funkce jsou odvozovány z modelů datových toků požadovaného systému, dotazovací funkce

27

z katalogu požadavků. Veškeré definované funkce je nezbytné konzultovat se zadavatelem projektu. Paralelně s identifikací aktualizačních funkcí se definují události, které slouží jako spouštěče aktualizací. Následné modelování entita/událost může nalézt nové události, které si vyžádají ošetření dalšími funkcemi. I/O struktury popisují vstupy a výstupy funkcí a jsou součástí podpůrné dokumentace funkcí. Datové položky jsou strukturované do diagramů, které se využívají jako základ pro návrh dialogů v modulu logického návrhu systému. Pro každou funkci se identifikuje jedna I/O struktura, obvykle z popisu vstupů a výstupů funkce. Každá funkce je dokumentována ve formuláři dokumentace funkce, který musí obsahovat některé povinné a některé volitelné údaje. Mezi povinné údaje patří název funkce, unikátní identifikátor funkce, uživatelské role, stručný popis funkce, DFD procesy, události a jejich frekvence vzniku, popis vstupů a výstupů, objemy (frekvence používání funkce), frekvence dotazů, jména dialogů a požadavky úrovně služeb, které představují nefunkcionální požadavky. Mezi volitelné položky dokumentace funkce patří popis zpracování chyb, odkaz na související funkce a společné zpracování, které je referencí na základní popis součástí sdílených více funkcemi. Příklad formuláře dokumentace funkce lze nalézt v [2].

2.3.5.5

Popis života entit

Popis života entit určuje, které události ovlivňují které entity či jejich datové reprezentace. Sledujeme významné časové okamžiky nebo události přicházející zvenčí systému. Zpravidla se uvádějí i požadavky na priority zpracování při souběhu více událostí. Analýza životního cyklu entit, označovaná ELH (Entity Life History), se uskutečňuje technikou zvanou E/E modelování. Smyslem je nalézt příčiny změn v datech systému, definovat jejich omezení a modelovat jejich přesný vliv na jednotlivé datové elementy. ELH analýza je technika založená na stromových diagramech a zachycuje životní cyklus entity od jejího vzniku až po zánik, reflektuje veškeré události, které mohou entitu pozměnit, a zachycuje jejich časový sled. Výchozím bodem pro ELH analýzu je E/E matice (Event/Entity Matrix), která poskytuje křížový pohled na entity z logického datového modelu požadovaného systému a události, zdokumentované ve funkční specifikaci. 28

2.3.5.6

Identifikace uživatelských rolí

Uživatelské role vycházejí z katalogu uživatelů a zahrnují veškeré kategorie uživatelů systému. Katalog uživatelů popisuje uživatele systému a jejich úlohu v systému. Každá uživatelská role vymezuje působnost a odpovědnost v rámci systému a disponuje určitými právy v systému. Představuje vždy jednoho či více uživatelů. Každému uživateli systému je přiřazena jedna nebo více uživatelských rolí. Smyslem identifikace je sdružit uživatele systému do přesně definovaných skupin. Pozornost je nutné věnovat nejen identifikaci funkcí užívaných jednotlivými skupinami uživatelů, ale i frekvenci a charakteru užití těchto funkcí.

2.3.5.7

Identifikace a návrh dialogů

Identifikace dialogů sleduje interakci procesů s uživatelem a návrh dialogů definuje uživatelské rozhranní funkcí nového systému. Identifikace je založena na tzv. uživatelských rolích v systému, kdy každá uživatelská role má určitá oprávnění a vyžaduje určitý přístup funkcím právě prostřednictvím dialogů. Návrh dialogů vychází ze vstupů a výstupů funkcí, popsaných v I/O strukturách funkční specifikace, kde každá funkce s uživatelskou interakcí vyžaduje dialog. Pro každou takovou funkci obvykle postačí jeden dialog. Křížové odkazy mezi uživatelskými rolemi a funkcemi sytému zachycuje matice role/funkce. Struktura dialogů popisuje jednotlivé elementy dialogu. Každý element se váže k datovým položkám a musí být dokumentován. Dialogové elementy mohou být sdružovány do logických celků - kolekcí, pomocí nichž se popisují odlišné varianty cesty dialogem. Struktury menu popisují hierarchii dialogů a příkazové struktury definují posloupnosti v předávání řízení při ukončení dialogu. Nejdůležitější dialogy se nazývají kritické dialogy. Určujícími faktory jsou velká frekvence použití, složitost přístupu k datům a manipulace s nimi, důležitost pro systém, novinky. Jednotlivými kroky návrhu dialogů jsou tvorba dialogových struktur, identifikace sdružování do logických skupin dialogových elementů, identifikace navigace v dialozích, návrh struktur menu a příkazových struktur a také definice nápovědy k dialogu.

29

2.4 Řízení projektu vývoje software Kvalita řízení projektu vývoje software je dána stupněm zralosti organizace, který vývoj softwarového produktu provádí. Podle [1] lze zralost organizace zařadit do jedné z následujících pěti skupin: •

Počáteční – Softwarový proces je prováděn ad hoc, příležitostně až chaoticky. Několik procesů je definováno, případné úspěchy závisí na osobním úsilí.

•

Opakovatelná - Jsou zavedeny základní procesy řízení projektu. Snaha opakovat procesy úspěšných projektů podobných aplikací.

•

Definovaná - Softwarový proces je z hlediska řízení dokumentován, standardizován a integrován do ostatních procesů organizace.

•

Řízená - Jsou prováděna podrobná měření kvality softwarového procesu a produktu.

•

Optimalizovaná - Soustavné zdokonalování procesů využívá kvantitativní zpětnou vazbu z procesů a testů nových myšlenek a technologií.

2.4.1 Metriky softwarového projektu Metriky softwarového produktu, procesu, projektu jsou kvalitativní charakteristiky programů, procesu jejich tvorby a projektu. Důvody pro měření metrik jsou zejména plánování projektu (odhad nákladů, pracnosti, času), kontrola kvality produktu, odhad produktivity za účelem zdokonalení práce a růstu výkonnosti vývojového týmu. Metriky vychází především z předchozích projektů, zejména z produktivity jejich vývoje a kvality softwarového produktu. Jsou sbírány dlouhodobě v průběhu řešení různých projektů a mají indikovat zlepšení softwarového procesu. Projektové metriky slouží k taktickým účelům, tj. odhadování času, nákladů k monitorování projektu a jeho vyhodnocování. Měříme vstupy, výstupy a výsledky. Vstupy chápeme jako zdroje, tedy lidé a zařízení potřebné pro práci. Výstupy jsou předané produkty vytvořené během softwarového procesu. Výsledky určují efektivitu výstupů. Rozeznáváme přímá a nepřímá měření softwarového produktu. Přímá měření mohou být počet řádek kódu, rychlost výpočtu, velikost paměti, počet chyb za určitou dobu apod. Nepřímá měření potom popisují funkčnost, kvalitu, složitost, pracnost, spolehlivost, možnost údržby apod. 30

Metriky orientované na velikost jsou odvozené z velikosti produktu a normalizované faktorem kvality či produktivity. Ze statistik předchozích projektů můžeme odvodit počet chyb na KLOC (tisíc řádek kódu), počet defektů na KLOC, cenu LOC, počet stran dokumentace na LOC, počet chyb za člověkoměsíc, počet LOC za člověkoměsíc, apod. Funkčně orientované metriky definují tzv. funkční bod, který v sobě zohledňuje počet logicky různých vstupů systému, počet výstupů, počet dotazů, počet vnitřních logických souborů a počet logických souborů na rozhraních systému. Produktivitu softwarového procesu určují zejména lidský faktor (velikost a zkušenost týmu), faktor problému (složitost, počet změn v návrhu), faktor procesu (techniky analýzy a návrhu, jazyk a nástroje), faktor produktu (chování a spolehlivost systému) a faktor zdrojů (hardware i software). Metrikami kvality softwaru jsou zejména správnost, daná většinou počtem defektů na KLOC a udržovatelnost, daná snadností opravy chyb a snadností úprav produktu z důvodu změn požadavků ze strany zadavatele.

2.4.2 Odhadování a plánování rozsahu projektu Plánování rozsahu projektu a pracnosti, plánování času, zdrojů a nákladů vychází zejména z metrik předchozích projektů. Sledujeme rozsah z pohledu funkce, chování, rozhraní, omezujících podmínek a spolehlivosti. Přesnost odhadu projektu spočívá v přesnosti odhadu velikosti produktu, schopnosti převést odhad velikosti na odhad pracnosti, času, finančních nákladů, odhadu schopností vývojového týmu a stability požadavků na produkt. Plánování zdrojů spočívá v plánování lidských zdrojů, využití již hotových softwarových komponent a využití hardwarových i softwarových zdrojů. Rozeznáváme dvě kategorie odhadů. První možností je dekompozice, kdy provádíme odhad rozsahu projektu pomocí odhadu rozsahu jeho dílčích částí, neboť odhad na nižší úrovni bývá přesnější. Druhá možnost odhadu je založena na empirických modelech, využívajících odvozené formule pro pracnost a čas. Časové plánování projektu spočívá v odhadu pracnosti, dekompozici funkce produktu a výběru vhodného modelu softwarového procesu (viz kapitola 2.3.1).

31

2.4.3 Řízení rizik a zabezpečení kvality softwarového produktu Rizika zahrnují nejistoty a v případě, že nastanou, znamenají ztráty. Rizika lze rozdělit na známá, předvídatelná a nepředvídatelná. Při pečlivé analýze a návrhu lze známá rizika odhalit. Předvídatelná rizika jsou extrapolována ze zkušeností z předchozích projektů. Rozeznáváme riziko velikosti produktu, založené na špatném odhadu velikosti produktu. Riziko obchodního dopadu zahrnuje např. cenu za pozdní dodání produktu, cenu za defektní produkt, počet produktů, s nimiž musí produkt spolupracovat apod. Rizika týkající se zákazníka jsou založena na nejistotě, zda zadavatel dostatečné dobře ví, co chce, zda chce mít dostatečné komunikační spojení s realizátorem, zda rozumí softwarovému procesu, zda je dostatečně technicky vzdělaný v oblasti produktu apod. Dále definujeme procesní rizika, jejichž míra je dána zejména stupněm zralosti organizace (viz. výše). Technologická rizika spočívají v kontaktu s novou technologií, v nutnosti vytvoření nových algoritmů, speciálního uživatelského rozhraní apod. Dále se mohou vyskytnout rizika spojená s vývojovým prostředím, s velikostí týmu a jeho zkušenostmi apod. Řízení kvality softwarového produktu zahrnuje sérii inspekcí, revizí a testů, prováděných během vývojového cyklu. Jejich cílem je zajistit vytvoření produktu, který bude odpovídat požadavkům. Cena kvality je cena všech aktivit souvisejících se zabezpečením kvality produktu. Zabezpečování kvality spočívá v provádění auditů a zpráv pro management. Cílem je poskytnout managementu potřebná data, aby byl informován o kvalitě produktu, zda odpovídá požadavkům, případně jsou-li nějaké problémy, které je třeba řešit.

2.4.4 Řízení změn softwarového produktu Změny při vývoji softwaru jsou přirozené a je třeba s nimi počítat. Změny je třeba analyzovat předtím, než nastanou, evidovat dříve, než se implementují, a dát ve známost těm, kterých se týkají. Příčiny změn mohou být nové obchodní nebo tržní podmínky, které vyvolávají změny v požadavcích na produkt nebo v obchodních pravidlech, nové potřeby zákazníka, vyžadující modifikace produkovaných dat z informačního sytému, funkčnosti produktu nebo služeb poskytovaných počítačovým systémem. Dále potom reorganizace a obchodní změny, které mohou vyvolat změny v prioritách projektu nebo

32

v realizačním týmu a omezení rozpočtu nebo harmonogramu, které způsobují změnu definice systému nebo produktu. Správa verzí softwarového produktu Řízení verzí lze zachytit evolučním grafem, zobrazujícím hierarchii změn. Každý uzel představuje agregovaný objekt – kompletní verzi produktu, tedy zdrojový kód, dokumentaci a data. Značení verzí se provádí číselnými identifikátory, oddělenými tečkou. Např. drobné úpravy mění produkt z verze 1.1 na 1.1.1, větší změny z 1.1 na 1.2 a rozsáhlé změny mění verzi 1.1 na 2.0. Každá verze produktu může být složena z několika různých variant. Varianty se mohou lišit výběrem komponent např. podle zvolené cílové platformy. Každá komponenta je složena z odlišného souboru objektů stejné úrovně revize a tudíž koexistuje paralelně s jinými variantami. Proces změny Proces změny sestává z následujících kroků: •

zjištěna potřeba změny, požadavek na změnu od uživatele

•

vyhodnocení vývojářem, generování změnové zprávy

•

odpovědná osoba nebo skupina rozhodne o změně (v případě neakceptace je informován uživatel a proces změny končí)

•

požadavek je zařazen do pořadí k vyřízení, stanoví se kritéria pro revizi či audit

•

určí se pracovníci a provedou se změny

•

provede se revize (audit)

•

provedou se aktivity k zajištění kvality a testování

•

změny se zahrnou do dalšího uveřejnění souborů

•

přepracuje se příslušná verze softwaru a lze distribuovat novou verzi.

2.4.5 Testování softwaru Testování je proces spuštění produktu, mající za cíl odhalit chyby. Dobrá testovací data jsou taková data, která s velkou pravděpodobností objeví dosud neobjevené chyby. Úspěšný test je takový test, který objevil doposud neobjevené chyby. Cílem je tedy navrhnout takový test, který systematicky odkryje různé třídy chyb s minimálním úsilím a časem. 33

Testování ovšem nemůže dokázat absenci chyb, může jen dokázat jejich přítomnost. Ve valné většině případů platí, že úplné otestování produktu není možné. Testy by se měli vztahovat k požadavkům zákazníka, měly by být plánovány v předstihu a testování by mělo být prováděno třetí stranou. Při tvorbě testů lze použít např. metody založené na grafu, kdy se testem snažíme pokrýt co nevyšší počet cest programem, metody analýzy okrajových hodnot a srovnávací testování, založené na redundanci. Dále potom metoda „bílé skříňky“, vycházející ze znalosti programové řídící struktury a metoda „černé skřínky“, založená na požadovaném funkčním chování bez ohledu na implementaci. Dále je vhodné zajistit testování uživatelské dokumentace a nápověd.

2.4.6 Projektový management Klasický management slouží k udržování a rozvíjení zavedených systémů, které jsou prostředkem pro nepřetržitou, kontinuální a opakující se tvorbu požadovaných výstupů. Projektový management slouží k zabezpečení realizace jedinečných, neopakovatelných, časově a zdrojově limitovaných procesů, které vedou k dosažení předem stanovených cílů. Plánování je popis toho, co požadujeme, aby se stalo. Řízení realizace je proces, kterým chceme dosáhnout toho, aby plánované události se skutečně staly a k neplánovaným aby nedocházelo. Koncept řízení projektu je založen zejména na pochopení problému, na práci s lidmi, přípravě, plánování, kontrolování a řízení softwarového procesu. Problém musí být definován při komunikaci realizátora se zákazníkem a dekomponován na části, které jsou následně přiděleny vývojovým týmům. Nejdůležitějším předpokladem pro úspěšný softwarový projekt je výběr vysoce kvalifikovaných spolupracovníků. Pracovníci musí být organizováni do efektivních týmů, motivováni k vysoce kvalitní práci a koordinování tak, aby dosáhli efektivní komunikace. Softwarový proces je ovlivňován osobami vrcholného managementu, manažery projektu, pracovníky a v neposlední řadě také zákazníky a koncovými uživateli vyvíjeného produktu. Manažer projektu musí být schopen plánovat projekt, komunikovat se zákazníkem, řídit rozpočet projektu, vybírat řešitele jednotlivých problémů, kontrolovat stav projektu a také prezentovat dosažené výsledky.

34

V závislosti na rozsahu vyvíjeného produktu lze rozlišit tři přístupy k organizační stránce projektu: •

n osob je přiřazeno k m různým úkolům, vyskytuje se jen relativně malá společná část, kterou je třeba koordinovat.

•

n osob je přiřazeno k m různým úkolům, m < n. Vznikají neformální týmy a ad hoc vedoucí týmu. Koordinaci řídí softwarový manažer.

•

n osob organizovaných do t týmů, každý má jeden či více úkolů, pracují na jednom projektu. Koordinaci provádí projektový manažer.

Volba struktury týmu závisí na stylu řízení, počtu pracovníků, jejich dovednostech a na složitosti problému. Komunikace zainteresovaných osob je dána zralostí organizace, možnostmi a lokalizací pracovníků, použitím podpůrných prostředků komunikace apod. Koordinace a komunikace může být zajištěna následujícími způsoby: •

Formální, neosobní přístup - Dokumentace, zdrojový kód, zprávy, zápisy.

•

Formální, interpersonální procedury - Týkají se zajištění kvality softwarového produktu. Kontrolní schůze, inspekce návrhu a kódu.

•

Neformální, interpersonální procedury - Schůze a neformální porady, které slouží k předávání informací v týmu a řešení problémů.

•

Elektronická komunikace.

•

Interpersonální síť - Neformální diskuse se zkušenými experty mimo tým, kteří mohou asistovat členům týmu.

35

3 IS pro řízení projektu vývoje software Informační systém pro řízení projektu vývoje software (Information system for software development project control), dále jen ISSDPC, je podpůrným nástrojem pro vývoj rozsáhlých softwarových produktů na bázi aplikace s uživatelským rozhraním využívajícím HTTP protokol sítě internet. Pro přístup k aplikaci tedy postačí počítač s připojením na internet a internetovým prohlížečem. Nabízí komplexní přístup k řešení vývoje softwarových produktů, které svým rozsahem vyžadují spolupráci týmu či týmů vývojářů. Základní objektem aplikace je projekt. Projekty mohou být přehledně uspořádávány do stromu, přičemž každý projekt může vlastnit řadu objektů, určených k zajištění efektivity vývoje projektu. Samozřejmostí je možnost nastavení přístupových práv samostatně jak ke každému projektu, tak i objektům projektem vlastněným. Přístup do systému mají uživatelé, kteří byli v systému registrováni. Ti mohou být seskupovány do skupin uživatelů. Skupiny uživatelů slouží k seskupování uživatelů do logických skupin (např. skupina administrátorů určitého projektu nebo skupina vývojářů určitého projektu). Díky existenci skupin uživatelů mohou být práva přidělována nejen jednotlivcům, ale právě i celým registrovaným skupinám uživatelů, což výrazně zjednodušuje a zrychluje manipulaci s přístupovými právy k jednotlivým objektům. Pro formální i neformální komunikaci mezi uživateli systému, kteří mají oprávnění zasahovat určitým způsobem do životního cyklu projektu, slouží diskusní fórum projektu. Diskusní příspěvky lze uspořádat do přehledné stromové struktury s možností vytvoření logických skupin diskusních příspěvků. Za účelem efektivního řízení vývoje projektu lze využít seznam úkolů projektu. Každý úkol

je charakterizován svým popisem, přiřazenou prioritou, stavem, který

určuje, v jaké fázi vývoje se úkol nachází, a požadovaným datem a časem dokončení. Může být a zpravidla bývá stanoven uživatel, který je zodpovědný za vyřešení úkolu. Každý softwarový produkt obsahuje chyby. Rozsáhlý softwarový produkt proto vyžaduje vhodný přístup k evidenci a odstraňování chyb. K tomu slouží seznam chyb projektu. Záznamy o chybě mohou být opět logicky seskupovány do stromu. Každý záznam o chybě má některé formální parametry, sloužící ke snadné orientaci mezi ostatními záznamy. Podobně jako úkol, tak i záznam o chybě se může nacházet v jednom z definovaných stavů. Každý záznam o chybě v projektu by měl mít za 36

následek vznik příslušného úkolu, který má vést k odstranění této chyby. Záznam o chybě proto může odkazovat a zpravidla odkazuje na příslušný úkol. Výsledkem softwarového procesu jsou vždy nějaké soubory, které mohou obsahovat produkt, část produktu, dokumentaci produktu, či jiné softwarové objekty s projektem související. Tyto výstupy jsou pozměňovány jak během vývoje produktu, tak i po jeho uvedení do provozu. Je žádoucí je aktualizovat, např. z důvodu opravy chyb v předchozích uvedených výstupech, změnách funkčností apod. K tomuto účelu může každý projekt vlastnit zveřejněné soubory. Každé uvedení souborů obsahuje zejména informace o verzi daného softwarového výstupu, datum uveřejnění a odkaz na příslušné soubory ke stažení. V následujících kapitolách je popsán návrh systému ISSDPC, jeho implementace a popis systému z pohledu uživatele, sloužící ke snadné orientaci uživatele v aplikaci.

3.1 Návrh a implementace ISSDPC Realizace každého softwarového produktu, tedy i aplikace ISSDPC, by měla probíhat metodicky řízeným přístupem k řešení problému. V tomto případě byla zvolena metoda objektově orientovaného návrhu a implementace, které předcházela specifikace požadavků na požadovaný systém.

3.1.1 Specifikace požadavků na ISSDPC Návrhu systému předchází specifikace požadavků. Zde bude uvedena neformální specifikace požadavků. V následujícím seznamu jsou uvedeny nejprve nefunkční a poté funkční požadavky na Informační systém pro řízení projektu vývoje software. Nefunkční požadavky 1. Jednoduchý nástroj pro správu vývoje softwarových produktů se zaměřením na požadavky na změnu. 2. Implementace platformově a databázově nezávislá, založená na Open Source [7] technologiích. 3. Přístup uživatelů k aplikaci přes rozhraní HTTP protokolu sítě internet. 4. Administrátor systému má oprávnění smazat kterýkoliv uživateli vytvořený objekt. 5. Možnost budoucího snadného rozšíření aplikace o nové funkčnosti. 37

Funkční požadavky 6. Logování uživatelů pod uživatelským jménem a heslem, evidence osobních informací o uživatelích, formulář pro žádost o registraci uživatele do systému. 7. Automatické odhlášení uživatele po zvolené době od poslední interakce uživatele se systémem, možnost „ručního“ odhlášení uživatelem. 8. Existence skupin uživatelů s cílem sdružovat uživatele do logických skupin. 9. Možnost nastavení přístupových práv jednotlivě ke každému objektu systému jak pro jednotlivé skupiny uživatelů, tak i pro jednotlivé registrované uživatele. 10. Definice systémové skupiny uživatelů – administrátorů sytému s nejvyšší možnou úrovní oprávnění v systému. Administrátor systému má mít přístup ke všem objektům, vytvořeným kterýmkoliv uživatelem systému, bez ohledu na aktuální nastavení přístupových práv k těmto objektům. Dále má přístup k některým systémovým objektům, sloužícím k administraci systému. 11. Schválení či odmítnutí uživatelů žádajících o registraci do systému mají oprávnění provádět pouze administrátoři systému. 12. Možnost poznámky administrátora systému u každého uživatele, ke které mají přístup pouze administrátoři systému. 13. Kódování přístupových hesel jednosměrnou hashovací funkcí kvůli zamezení možnosti zpětného určení hesla z údaje uloženého v databázi. Při zapomenutí hesla přiděluje uživateli heslo administrátor systému. Ten má oprávnění uživatelská hesla měnit bez znalosti hesla původního. 14. Existence prostředků podporujících efektivní vývoj softwarových produktů, tedy diskusní fórum, seznam úkolů, seznam chyb, možnost zveřejňování souborů, přístup ke zdrojovým kódům. 15. Možnost přiřazení úkolu jednotlivým uživatelům, zodpovědným za jejich vyřešení. 16. Možnost křížových odkazů u chyb na úkoly, které danou chybu řeší. 17. Objekty nesmí být fyzicky mazány, pouze je jim nastaven atribut smazáno. Smazané objekty mají oprávnění vidět pouze administrátoři systému. Mohou s nimi manipulovat shodně, jako kdyby byly objekty platnými. 38

18. Při mazání objektu jsou automaticky mazány i objekty vlastněné mazaným objektem. 19. Obnovu smazaných objektů je umožněna pouze administrátorovi systému. Obnovit lze pouze takový objekt, jehož rodičovský objekt není smazán. Při obnově objektu jsou automaticky obnoveny i všechny takové objekty, jejichž je tento objekt vlastníkem a které byly smazány při stejné operaci mazání jako objekt obnovovaný. Dříve smazaným objektům bude ponechán atribut smazané.

3.1.2 Vývojový nástroj systému Z požadavků na plnou přístupnost systému přes rozhraní sítě internet a platformovou nezávislost systému byl zvolen skriptovací jazyk PHP4 [8], který je celosvětově ve značném rozsahu využíván pro aplikace tohoto typu a nabízí vhodnou konektivitu k databázím, jejichž využití je v podobných systémech standardem. Další výhodou je podpora objektově orientovaného programování, které bylo využito při návrhu a implementaci tohoto informačního systému.

3.1.3 Server ISSDPC Jelikož je kód jazyka PHP4 platformově nazávislý, lze informační systém provozovat na kterémkoli HTTP serveru disponujícím podporou skriptů psaných v jazyce PHP4, případně podporujícím přístup ke zvolené databázi. Pro platformy založené na operačním systému typu UNIX je to např. Apache HTTP server [9], který je často součástí operačního systému. Musí však být rozšířen o modul podpory jazyka PHP4. Pro platformy typu Win32 lze využít např. IIS (Internet Information Server) [10], který je součástí např. operačního systému MS Windows 2000 [10]. Softwarovou podporu skriptů jazyka PHP4 pro tyto i jiné HTTP servery lze nalézt na [8].

3.1.4 Databáze ISSDPC Na základě specifikace požadavků byla snaha navrhnout takový systém, který bude nejen platformově nezávislý, ale také databázově nezávislý. Konektivitu aplikace ke zvolené databázi zajišťuje třída Databáze (třída Database) (viz. kapitola 3.1.5). Tato třída jako jediná obsahuje syntaxe závislé na zvoleném databázovém rozhraní. Nebylo 39

možné využít žádné z objektově orientovaných databází, neboť podpora objektově orientovaného programování v jazyce PHP4 není na dostatečné úrovni. Z tohoto důvodu bylo nutné sáhnout po databázových systémech s klasickým relačním přístupem. V době vzniku této práce byla zajištěna konektivita aplikace na databázi MySQL 4.0 [11] (navrženou pro systémy typu UNIX). Dále byla třída Databáze implementována také pro konektivitu na databáze, které lze zpřístupnit pomocí rozhraní ODBC [10] (původně navržené pro systémy typu Win32). Konektivitu aplikace na alternativní databázová rozhraní lze jednoduše zajistit modifikací třídy Databáze. Omezení jsou dána pouze možnostmi jazyka PHP4.

3.1.5 Struktura aplikace Aplikace byla navržena metodou OOAD (Objektově orientovaná analýza a design), popsané v kapitole 2.3.4. Z analýzy požadovaného systému vyplynuly požadavky na vznik následujících tříd. •

Uživatel (třída User)

•

Skupina uživatelů (třída User_group)

•

Projekt (třída Project)

•

Úkol (třída Task)

•

Diskusní příspěvek (třída Mail)

•

Záznam o chybě (třída Bug)

•

Uvedení souborů (třída Release)

Generalizací těchto tříd vznikl požadavek na existenci třídy Objekt (třída Object) a třídy Databáze (třída Database). Výchozí třídou je třída Databáze, neboť všechny objekty aplikace mají svá data uložena v tabulkách databáze. Od třídy Databáze dědí třída Objekt, která obsahuje data a metody společné pro všechny výše zmíněné třídy. Spojovací třídou mezi třídou Objekt a třídami Uživatel a Skupina uživatelů je třída Přístupových práv (třída Access_rights). Každý uživatel nebo skupina uživatelů může mít k ostatním typům objektů nastaveno přístupové právo. Typ přístupového práva je atributem třídy Přístupových práv a určuje stupeň oprávnění uživatele či skupiny uživatelů k manipulaci s daným objektem.

40

3.1.6 Implementace Implementace informačního systému pro řízení projektu vývoje software byla z důvodů uvedených v kapitole 3.1.2 realizována pomocí PHP skriptů. Každé třídě přísluší jedna tabulka v databázi. V tabulkách jsou obsažena data specifická pro objekty dané třídy. Vazba mezi uživateli (instancemi třídy Uživatel) a skupinami uživatelů (instancemi třídy Skupina uživatelů) je zajištěna tabulkou Users_in_groups. Metody a data specifická pro konkrétní typy objektů jsou umístěna ve zdrojových kódech jejich tříd. Vazby mezi všemi zmíněnými třídami jsou znázorněny v příloze označené písmenem A. Diagram tříd podrobně zachycující atributy jednotlivých tříd je uveden v příloze označené písmenem B a diagram tříd zachycující důležité metody jednotlivých tříd je uveden v příloze označené písmenem C. Kromě souborů implementací tříd je aplikace tvořena soubory se skripty, které generují příslušné HTML stránky aplikace. Jejich struktura pro uživatelskou roli návštěvník je znázorněna v příloze označené písmenem D. Pro ostatní uživatelské role je struktura znázorněna v příloze označené písmenem E. Při tvorbě výše zmíněných diagramů, umístěných v přílohách A až E, byly využity standardy jazyka UML (viz. kapitola 2.3.4). Jazykem prostředí aplikace ISSPDC je angličtina, která je v odborné praxi jazykem celosvětově nejpoužívanějším a v oboru vývoje software je standardem. Na počítači, na kterém se bude k aplikaci přistupovat (klient), musí být nainstalován prohlížeč internetových stránek a tento prohlížeč musí umožňovat používání tzv. cookies. Ty jsou aplikací využívány k uchování identifikátoru tzv. session proměnných jazyka PHP4, které slouží k uchovávání dočasných informací. Identifikátor také slouží k odlišení uživatelů, kteří jsou v danou chvíli připojeni k systému.

3.1.7 Inicializace systému Pro uvedení systému do provozu, je nutné, aby byla vytvořena databáze, tabulky a zaregistrovány výchozí objekty zapsáním jejich atributů do vytvořených tabulek databáze. K tomu je určen skript s SQL příkazy pro databázi MySQL, který je přiložen ke zdrojovým kódům aplikace. Po jeho spuštění dojde k vytvoření databáze ISSDPC, příslušných tabulek jednotlivých tříd a proběhne inicializace systému naplněním tabulek daty výchozích objektů systému. Výchozí objekty systému jsou:

41

•

Jedna instance třídy Projekt s názvem ISSDPC Projects, definující kořenový projekt všech projektů v systému, které budou uživateli později vytvořeny.

•

Pět instancí třídy Skupina uživatelů, kterými budou systémové skupiny uživatelů sloužící ke správě uživatelů systému. Jedná se o následující skupiny uživatelů: o Běžní uživatelé (Regular users) o Smazaní uživatelé (Deleted users) o Uživatelé čekající na registraci (Users waiting for registration) o Zamítnutí uživatelé (Rejected users) o Administrátoři systému (System administrators)

•

Dvě instance třídy Uživatel, kterými budou definováni: o Nepřihlášený uživatel (Non logged user) o Výchozí systémový administrátor (Administrator) s výchozím heslem „administrator“. Ten je současně vložen do systémové skupiny Běžní uživatelé a do systémové skupiny Systémový administrátoři.

Dále dojde ke vložení uživatele Administrator do systémové skupiny uživatelů Běžní uživatelé a do systémové skupiny uživatelů Administrátoři systému a jsou přiřazena přístupová práva následujícím objektům: •

Přístupové právo typu čtení (read) skupině uživatelů Běžní uživatelé ke skupině uživatelů Běžní uživatelé.

•

Přístupové právo typu čtení (read) skupině uživatelů Běžní uživatelé k uživateli Administrator.

•

Přístupové právo typu modifikace (edit) uživateli Administrator k uživateli Administrator.

Při prvním přihlášení do systému je velmi žádoucí změnit přístupové heslo uživatele Administrator, vytvořit konkrétního uživatele a umístit ho do skupiny administrátorů systému. Poté již získává právě registrovaný uživatel plnou kontrolu nad systémem a uživatele Administrator je možno smazat (označit za smazaného).

42

Před prvním použitím aplikace je nutné provést některá nastavení i v jejím kódu. Třída App_settings uložená v souboru „class.app_settings.php“ obsahuje několik atributů, které je pro správnou funkci aplikace nutné modifikovat. Mezi tyto atributy patří jméno databázového serveru, jméno databáze, jméno uživatele a heslo, které jsou nutné při přístupu do databáze, cesta na pevném disku serveru ke složce se zdrojovými kódy aplikace a relativní cesta ze složky aplikace pro určení požadované složky pro ukládání zveřejnovaných souborů jednotlivých projektů. Zveřejněné soubory jsou poté ukládány do podřízených složek se zachováním stromové hierarchie projektů. Složky ve stromu jsou pojmenovány podle názvů odpovídajících projektů. Dále je možné nastavit elektronickou adresu administrátora systému, na kterou budou odesílány dotazy a požadavky uživatelů systému.

3.2 Popis ISSDPC z pohledu uživatele Okno aplikace je rozděleno na dvě oblasti. Levý panel obsahuje důležité odkazy, které lze využít pro přechod do některých výchozích stavů systému. Zbylá větší část okna aplikace slouží zejména k zobrazování aktuálně požadovaných objektů a zobrazování nabídek určených pro jejich modifikaci. Výchozí okno aplikace je zobrazeno na následujícím obrázku.

Obrázek 3.1: Výchozí okno aplikace ISSDPC.

43

3.2.1 Uživatelské role Po zobrazení výchozí stránky systému je přístup uživatele automaticky nastaven na přístup v roli návštěvník. Každý uživatel, který vyplnil a odeslal registrační formulář dostupný z výchozí stránky systému, se stává předmětem schválení jeho registračních údajů. Úspěšné odeslání registračního formuláře ještě nezajišťuje možnost vstupu do systému, neboť každý žadatel o povolení vstupu do systému musí být nejprve schválen administrátorem systému. Pokud je uživatel schválen, stává se registrovaným uživatelem systému a je mu umožněno přihlásit se do systému. Poté bude přistupovat do systému v roli registrovaný uživatel. Každý přihlášený uživatel může žádat (nejlépe pomocí elektronické pošty) o registraci

svého

projektu.

Projekty

jsou

rovněž

schvalovány

systémovým

administrátorem. V případě schválení projektu se žadatel o registraci projektu stane projektovým administrátorem svého projektu. K projektu a objektům projektu podřízeným přistupuje v roli administrátora projektu. Další rolí přístupu k projektu a jeho podřízeným objektům je role vývojář projektu. V tomto případě jsou práva uživatelé omezena oproti uživateli přistupujícímu k objektům projektu v roli administrátor projektu. Poslední definovanou uživatelskou rolí je administrátor systému, který má práva všech podřízených uživatelských rolí ke všem objektům v systému a práva k dalším nastavením systému. Obrázek 3.2 zobrazuje hierarchii uživatelských rolí v aplikaci.

návštěvník registrovaný uživatel vývojář projektu administrátor projektu administrátor systému

Obrázek 3.2: Hierarchie uživatelských rolí.

44

3.2.2 Skupiny uživatelů Skupiny uživatelů slouží k seskupování registrovaných uživatelů do logických skupin. Nejdůležitější účel skupin uživatelů je možnost snadného nastavení přístupových práv k jednotlivým objektům systému (projekty, diskusní fóra apod.). V praxi je nutné umožnit přístup k danému objektu určité skupině lidí (uživatelů). Možnost přístupu k objektu je většinou omezena na několik málo typů přístupových práv a jejich nastavování pro každého uživatele zvlášť by bylo pro administrátora daného objektu nepohodlné a zdlouhavé. Za účelem zjednodušení manipulace s přístupovými právy a pro zvýšení přehlednosti přidělených práv lze uživatele seskupovat do skupin uživatelů podle požadavku na jejich práva přístupu k objektu. Práva lze potom snadno přidávat či ubírat celé skupině uživatelů. Všechny skupiny uživatelů, které jsou přístupné právě přihlášenému uživateli, je možné zobrazit pomocí odkazu Skupiny uživatelů (User groups) z levého panelu aplikace (viz. Obrázek 3.3). Jednotlivé skupiny uživatelů se také zobrazují u příslušných projektů, ke kterým náleží.

Obrázek 3.3: Seznam skupin uživatelů z pohledu administrátora systému.

45

Systémové skupiny uživatelů V systému je definováno pět systémových uživatelských skupin: •

Běžní uživatelé (Regular users)

•

Smazaní uživatelé (Deleted users)

•

Uživatelé čekající na registraci (Users waiting for registration)

•

Zamítnutí uživatelé (Rejected users)

•

Administrátoři systému (System administrators)

Ve skupině uživatelů běžní uživatelé jsou obsaženi všichni registrovaní uživatelé. Těm je umožněno přihlásit se do systému a to pod svým uživatelským jménem a heslem. Po přihlášení získávají práva k těm objektům, u nichž byla administrátorem těchto objektů nastavena určitá úroveň přístupových práv pro členy skupiny běžní uživatelé. Skupina uživatelů smazaní uživatelé je složena z uživatelů, kteří byli v minulosti ve skupině běžní uživatelé, ale z jistého důvodu (např. na jejich žádost, nekázeň apod.) jim byl přístup do systému znemožněn. Nemohou se přihlásit do systému a jejich přístupová práva k objektům systému odpovídají uživatelské roli návštěvník. Uživatelé skupiny smazaní uživatelé se mohou stát opět členy skupiny běžní uživatelé, pokud pominou důvody znemožnění přístupu do systému. Jejich opětovný vstup do systému mohou umožnit pouze členové systémové skupiny administrátoři systému. Ve skupině uživatelé čekající na registraci jsou uživatelé, kteří vyplnili registrační formulář pro nové uživatele, dostupný z výchozí stránky systému. Žadatelé jsou schvalováni členy systémové uživatelské skupiny administrátoři systému. Po schválení žádosti je schválený uživatel automaticky přesunut do skupiny běžní uživatelé a je mu umožněn vstup do systému pod jím zvoleným uživatelským jménem a heslem. Pokud je schválení uživatele zamítnuto, je zamítnutý uživatel přesunut ze systémové skupiny uživatelů uživatelé čekající na registraci do skupiny zamítnutí uživatelé. Takovému uživateli není přístup do systému umožněn. Uživatele lze dodatečně schválit a umožnit mu tak vstup do systému, pokud pominou důvody odmítnutí jeho žádosti o registraci. Každý registrovaný uživatel je v

právě jedné ze čtyř výše zmíněných

systémových skupin.

46

Poslední systémovou skupinou je skupina administrátoři systému. Členové této skupiny mají všechna přístupová práva k systému i ke všem objektům v systému definovaným, ovšem pouze v případě, že jsou současně členy systémové skupiny běžní uživatelé. Mohou manipulovat se všemi objekty, uživateli i skupinami uživatelů v maximální míře, jaká je systémem povolena. K systémovým skupinám uživatelů mají přístup pouze členové systémové skupiny administrátoři systému. Výjimku tvoří skupina běžní uživatelé. Její členy může vidět každý přihlášený uživatel. Projektové skupiny uživatelů Kromě systémových skupin uživatelů, mohou existovat i skupiny uživatelů příslušející k daným projektům. Tyto skupiny uživatelů mají oprávnění vytvářet administrátoři jednotlivých projektů pomocí odkazu vytvořit nový objekt (create new object) na stránce příslušného projektu a dále volbou skupina uživatelů (user group). Jméno skupiny uživatelů musí být jedinečné v celém systému z důvodu zachování přehlednosti při kopírování uživatelů mezi skupinami uživatelů, jež jsou administrátoru projektu dostupné. Přidávání či ubírání členů skupiny uživatelů se provádí ze stránky skupiny uživatelů pomocí odkazu přidat/odebrat uživatele (add/remove members). Dojde k přechodu na stránku umožňující přidávat a odebírat uživatele. Lze vybrat zdrojovou skupinu uživatelů. Vždy lze vybírat uživatele alespoň ze systémové skupiny uživatelů běžní uživatelé. Přidávání uživatelů ze zvolené skupiny do skupiny aktuální se provádí zaškrtnutím požadovaných uživatelů a stiskem tlačítka přidat (add). Na této stránce lze uživatele ze skupiny uživatelů i odstraňovat. Stačí zaškrtnout vybrané uživatele a stisknout tlačítko odstranit (remove).

3.2.3 Registrace uživatele Každý uživatel, který se chce podílet na projektech vyvíjených pod tímto informačním systémem, musí nejprve projít registrační procedurou. Registrační formulář je dostupný z výchozí stránky aplikace. Uživatel vyplní formulář s dotazy na osobní informace. Po vyplnění všech povinných údajů je nutné formulář odeslat kliknutím na tlačítko odeslat (Submit). Povinné údaje formuláře jsou přihlašovací jméno, křestní jméno, pohlaví, elektronická adresa a heslo (login name, first name, last name, gender, e-mail a password). Zvolené uživatelské jméno musí být v systému 47

jedinečné (systém provádí kontrolu automaticky). Při zadávání hesla je třeba rozlišovat malá a velká písmena, v případě uživatelského jména nikoliv. Minimální počet znaků hesla je pět. Heslo se nesmí shodovat s uživatelským jménem. Další omezení při volbě hesla nejsou stanovena. Některé položky již později uživatel měnit nesmí (login name, first name, last name, title). Tuto pravomoc má pouze administrátor systému. Samozřejmostí je možnost změny přístupového hesla. Přístupové heslo uživatele je do databáze ukládáno v zakódované podobě. Kódování je realizováno pomocí algoritmu MD5 [12]. Protože se jedná o jednosměrnou hashovací funkci, nelze heslo zpětně určit. Pokud uživatel zapomene své osobní přístupové heslo, je nucen požádat administrátora systému o přidělení hesla nového. Při zadávání hesla je nutné rozlišovat malá a velká písmena.

3.2.4 Přihlášení uživatele do systému a odhlášení Pokud je uživatel registrován (jeho registrace byla schválena), může se přihlásit do systému a získat tak přístupová práva příslušející skupině uživatelů běžní uživatelé. Přihlášení do systému lze provést ze stránky, která je dostupná z výchozí stránky systému pomocí odkazu login. Po uživateli se požaduje zadat jeho přihlašovací jméno (login name) a heslo (password). V heslu je nutné rozlišovat malá a velká písmena, v přihlašovacím jméně nikoliv. Po odeslání těchto údajů dojde k jejich ověření. Pokud jsou zadané údaje platné, uživatel je přihlášen do systému, v opačném případě je mu vstup do systému odepřen a v systému je nadále v uživatelské roli návštěvníka. V případě, že uživatel ukončí práci v systému, může se odhlásit pomocí odkazu logout umístěném v levém panelu pod jeho uživatelským jménem. Pokud tak neučiní a nedojde z jeho strany k interakci se systémem po dobu definovanou v aplikaci systému (30 minut), je uživatel od systému automaticky odhlášen. Důvodem k automatickému odhlášení uživatele je zejména ochrana informací a dat, neboť není žádoucí, aby cizí osoba neoprávněně manipulovala s objekty, k nimž má uživatel umožněn přístup.

3.2.5 Osobní stránka uživatele Po přihlášení uživatele do systému přechází aplikace na osobní stránku uživatele. Tato stránka slouží jednak k zobrazení osobních informací o uživateli a dále poskytuje uživateli odkazy na projekty, na jejichž vývoji se podílí.

48

U každého uživatele jsou registrovány následující údaje: •

uživatelské jméno (user name, povinné)

•

přístupové heslo (password, povinné)

•

křestní jméno (first name, povinné)

•

příjmení (last name, povinné)

•

titul, (title)

•

pohlaví, (gender, povinné)

•

elektronická adresa, (e-mail, povinné)

•

odkaz na osobní webovou stránku uživatele (user web)

•

telefon (phone)

•

poštovní adresa (mailing address)

•

osobní poznámka uživatele (user note)

•

poznámka systémového administrátora (sysamdin note)

Tyto údaje (kromě poznámky systémového administrátora) zadává uživatel při registraci do systému a později je může upravovat ze své osobní stránky po kliknutí na odkaz edit. Některé údaje jsou povinné, některé uživatel sám oprávnění měnit nemá. Poznámku systémového administrátora mohou vidět a měnit pouze členové systémové skupiny uživatelů administrátoři systému. V levém panelu aplikace se pro všechny přihlášené uživatele objeví odkaz Users, kterým lze zobrazit členy systémové skupiny uživatelů běžní uživatelé. Každý uživatel této skupiny je zobrazen formou odkazu na jeho osobní stránku. Přihlášený uživatel může na svou osobní stránku dostoupit také z levého panelu aplikace, a to pomocí odkazu User Homepage. Pokud se uživatel nachází na své osobní stránce, může pod svými osobními informacemi nalézt odkazy na projekty, na jejichž vývoji se podílí. Projekty jsou zobrazeny jako odkazy na stránky těchto projektů. U každého odkazu na projekt je zároveň zobrazena informace o počtu úkolů přiřazených uživateli v daném projektu. Číslo odpovídá počtu nedokončených úkolů.

3.2.6 Administrace systému Pokud je přihlášený uživatel v systémové skupině Administrátoři systému, získává veškerá přípustná práva k manipulaci se systémem a uloženými objekty.

49

Obrázek 3.4: Stránka s nastaveními pro administraci systému.

Chování systému po přihlášení administrátora systému je totožné s chováním systému k ostatním uživatelům, pouze se v levém panelu aplikace objeví odkaz příslušející administraci systému. Po zobrazení stránky příslušející odkazu options (viz. Obrázek 3.4) je možné změnit některá nastavení systému. Pokud uživatel potřebuje přistupovat k objektům v roli systémového administrátora, musí na této stránce zaškrtnout volbu Global view as System Administrator. Poté může procházet strom projektů a objektů jím podřízeným bez ohledu na práva, které k těmto objektům má v roli běžného přihlášeného uživatele systému. Je mu umožněno měnit veškeré informace o objektech a jejich přístupová práva pro jednotlivé uživatele či uživatelské skupiny. Dále může manipulovat s uživateli v jednotlivých skupinách uživatelů a může libovolně měnit veškeré informace o uživatelích včetně jejich přístupového hesla. Má přístup k systémovým skupinám uživatelů. Může schválit či zamítnout přístup uživatelům čekajícím na schválení registrace (členové systémové skupiny uživatelů uživatelé čekající na registraci). Pokud uživatel ze skupiny administrátoři systému zvolí možnost přístupu k systému v roli

administrátora systému, je mu umožněna další volba přístupu

50

k objektům systému. Pomocí volby View option for disabled object může zvolit zobrazení objektů ve dvou režimech: •

Zobrazit pouze nesmazané objekty (show valid objects only)

•

Zobrazit nesmazané i smazané objekty (show both valid and not valid objects)

Pokud zvolí druhou možnost, může procházet stromovou strukturou všech objektů, přičemž se budou zobrazovat i objekty smazané. Za účelem snadného rozpoznání smazaných a nesmazaných objektů je u každého smazaného objektu poznámka deleted (smazáno) a údaj s datem a časem jejich smazání. Mazání objektů je systémovému administrátorovi umožněno pouze při volbě zobrazit nesmazané i smazané objekty. Smazání objektu je poté možné provést pomocí odkazu delete v pravém horním rohu aplikace na stránce zobrazení objektu. V okamžiku smazání objektu jsou smazány i objekty jemu podřízené. Při provádění operace mazání objektu či objektů nedochází k faktickému odstranění záznamů v databázi. U mazaných objektů pouze dojde k nastavení příslušného příznaku smazání v databázi. Obnovení smazaných objektů je možné pomocí odkazu undelete. Tato operace bude provedena pouze v případě, že rodičovský objekt smazaného objektu sám smazán není. V případě úspěšného obnovení objektu jsou obnoveny i všechny objekty jemu podřízené, smazané při stejné operaci mazání, při které byl smazán obnovovaný objekt. Na osobní stránce administrátora systému se také nachází odkaz na systémovou skupinu uživatelů uživatelé čekající na registraci, včetně informace o počtu uživatelů v ní umístěných. Při zobrazení této skupiny je uživatel automaticky přepnut do role administrátora systému, pokud tak sám neučinil z nabídky options, dostupnou pro členy systémové skupiny uživatelů administrátoři systému z levého panelu aplikace. Po zobrazení skupiny uživatelé čekající na registraci se zobrazí seznam uživatelů čekajících na schválení jejich registrace do systému. Každý uživatel je zobrazen jako odkaz na jeho osobní stránku. Na této stránce jsou pro členy systémové skupiny uživatelů administrátoři systému dostupné příkazy pro povolení (approve) nebo pro zamítnutí (reject) registrace. Je-li uživateli schválen vstup do systému je automaticky přesunut do systémové skupiny uživatelů Běžní uživatelé. V případě zamítnutí jeho registrace je uživatel přesunut do systémové skupiny uživatelů zamítnutí uživatelé a vstup do systému mu umožněn není.

51

3.2.7 Projekt (Project) Hlavním úkolem Informačního systému pro řízení projektu vývoje software je správa projektů. V systému je zaveden stromový přístup k projektům. Kořenem stromu je projekt s názvem ISSDPC Projects. Všechny další projekty jsou v něm obsaženy jako jeho

podprojekty.

Podprojekty

kořenového

projektu

musí

být

schváleny

administrátorem systému. Jméno projektu musí být jedinečné v celém systému. Každý nově vytvořený projekt má svého administrátora projektu (většinou uživatel žádající o registraci projektu). Projekt může případně vlastnit skupinu uživatelů s právem administrace projektu. Tito uživatelé již mohou registrovat nové podprojekty tohoto projektu bez nutnosti schválení registrace projektu administrátorem systému.

Obrázek 3.5: Příklad výchozí stránky projektu v pohledu administrátora systému.

Administrátor projektu je tedy uživatel, který má přístupové právo k projektu typu modifikace (edit). Má právo vytvářet objekty, které budou příslušet k projektu (skupiny uživatelů, seznamy úkolů, seznamy chyb, zveřejňovat soubory projektu). Ostatní

52

registrovaní uživatelé mohou mít přístupové právo typu čtení (read). Nemají-li přiřazeno žádné přístupové právo, potom o existenci projektu vůbec nevědí. Pokud podprojekt vytváří administrátor projektu, vytvoří se k projektu automaticky i skupina administrátorů nového projektu, v níž je jediný uživatel. Tím je právě administrátor projektu, který nový podprojekt vytvořil. Obrázek 3.5 zachycuje příklad výchozí stránky projektu.

3.2.8 Seznam úkolů (Task list) Každý projekt může vlastnit seznam úkolů (task list). Jedná se o stromovou strukturu objektů typu úkol (task). Je to jeden z nejdůležitějších prvků systému z ohledem na vývoj projektu. Pomocí úkolů jsou přidělovány pracovní úkoly jednotlivým vývojářům projektu. Každý úkol má několik atributů. •

Identifikátor úkolu (Task Id)

•

Jméno úkolu (task name)

•

Popis úkolu (task description)

•

Priorita úkolu (task priority)

•

Vývojář, jemuž byl úkol přidělen (developer)

•

Stav úkolu (task status)

•

Procento dokončení úkolu (task progress)

•

Datum a čas poslední změny stavu úkolu (date of last status change)

•

Datum a čas požadovaného dokončení úkolu (due date)

Identifikátor úkolu jednoznačně identifikuje úkol v systému a je využíván pro nastavení parametru související úkol u objektu záznam o chybě, který je popsán v kapitole 3.2.9. Jméno úkolu je zobrazeno v titulku úkolu a mělo by stručně a jasně vystihovat problém, který daný úkol vyřeší. Jméno úkolu musí být zadáno. Popis úkolu by měl obsahovat upřesnění požadavků stanovených ve jméně úkolu. Nemusí být zadán. Každý úkol musí mít stanovenou prioritu úkolu, ohodnocenou celým číslem v rozsahu 1 až 5, kde nevyšší prioritu má úkol s ohodnocením jedna. Uživatel, který definuje nový úkol, může úkol přidělit některému z vývojářů, podílejících se na projektu. Vývojář úkolu však nemusí být stanoven (jedná-li se 53

například o skupinu úkolů – viz. dále). Vývojář úkolu je vybírán pouze ze skupin uživatelů příslušejících danému projektu.

Obrázek 3.6: Příklad zobrazení objektu typu úkol.

Z hlediska splnění úkolu se každý úkol může nacházet v jednom ze čtyř následujících stavů: •

Úkol před započetím prací (waiting)

•

Na úkolu se pracuje (in process)

•

Úkol hotov (done)

•

Úkol zrušen (Canceled)

Po vytvoření nového úkolu se úkol nachází ve stavu waiting až do započetí prací směřujících k jeho splnění. Vývojář pověřený splněním úkolu může měnit procento dokončení úkolu, čímž dává spolupracovníkům najevo, nakolik je jemu přidělený úkol hotov. Jakmile tento uživatel nastaví nenulové procento dokončení úkolu, přechází úkol do stavu in process, což vyjadřuje, že se na úkolu pracuje. V případě, že se vývojář úkolu domnívá, že je úkol splněn, nataví procento dokončení úkolu na hodnotu 100%. Dokončení úkolu musí být posouzeno administrátorem projektu, který v případě splnění 54

úkolu nastaví atribut stavu úkolu na hodnotu done, čímž je určeno, že požadavky dané specifikací úkolu jsou splněny. Pokud shledá úkol nesplněným, nastaví procento dokončení úkolu na zvolenou hodnotu nižší než 100% a v případě nutnosti doplní požadavky do názvu nebo do popisu úkolu. V určité fázi vývoje projektu může nastat, že původně zadaný úkol již neodpovídá např. změněným požadavkům na projekt a je nutné zastavit práci na tomto úkolu. Tehdy administrátor projektu nastavuje stav úkolu na hodnotu canceled. Datum a čas poslední změny stavu úkolu poukazuje na poslední změnu stavu vývoje úkolu. Pokud je úkol dokončen (done), určuje tento údaj datum a čas jeho dokončení. Datum a čas požadovaného dokončení úkolu umožňuje rychlou orientaci v požadavku na dokončení úkolu z časového hlediska. Nemusí být zadán. Zejména v rozsáhlejších projektech je vhodné členit úkoly do skupin. K tomu lze využít možnost uspořádání úkolů do stromové struktury. Každý úkol tak může zahrnovat další podřízené úkoly, či opět skupiny úkolů. Při zobrazení odkazu na úkol je za ním zobrazena informace o počtu podřízených úkolů, které jsou přiřazeny přihlášenému uživateli a ještě nebyly splněny. Tato funkce je užitečná pro rychlou orientaci v úkolech, neboť uživatel má ihned přehled o úkolech, které má ještě splnit. Informace o nesplněných úkolech uživatele je také dostupná z osobní stránky uživatele, kde je uvedena za každým odkazem na projekt, na kterém se uživatel podílí. Každý úkol může mít, stejně jako každý jiný objekt v systému, stanovena přístupová práva, která určují rozsah přístupu k úkolu pro vybrané uživatele či skupiny uživatelů. V případě objektů typu úkol jsou definovány čtyři typy přístupových práv. •

Čtení (read)

•

Modifikace (edit)

•

Změna procenta dokončení úkolu (change progress)

•

Vytvoření podúkolu (create sub)

Uživatelé s právem čtení mohou pouze vidět všechny informace o úkolu. Uživatel pověřený splněním úkolu má přístupová práva na možnost změny procenta dokončení úkolu. Administrátor projektu má právo modifikace úkolu a má tedy možnost změny kteréhokoliv atributu daného úkolu. V životním cyklu daného úkolu zejména rozhoduje

55

o tom, zda je úkol splněn. V některých případech je vhodné, aby uživatel měl právo vytvořit podúkol úkolu bez možnosti modifikace úkolu. K tomuto účelu slouží přístupové právo typu vytvoření podúkolu.

3.2.9 Seznam chyb (Bug list) Každý projekt může vlastnit seznam chyb (bug list), který slouží k registraci záznamů o chybách ve vyvíjeném projektu. Každá chyba v projektu by měla vyvolat vytvoření příslušného úkolu, či skupiny úkolů, po jejichž splnění se očekává odstranění ohlášené chyby. Každá chyba má několik atributů: •

Jméno chyby (bug name)

•

Popis chyby (bug description)

•

Stav chyby (bug status)

•

Datum a čas poslední změny stavu chyby (date of last status change)

•

Související úkol (related task)

Jméno záznamu o chybě by mělo krátce a jednoznačně a výstižně popsat odhalenou chybu v projektu a musí být zadáno. Popis záznamu o chybě by měl upřesnit informaci obsaženou ve jméně záznamu o chybě, ale nemusí být zadán. Každá položka typu záznam o chybě (bug) se může nacházet v pěti různých stavech: •

Uvedení chyby (released)

•

Definován příslušný úkol nebo skupina úkolů (waiting)

•

Na odstranění chyby se pracuje (in process)

•

Chyba vyřešena (done)

•

Chyba stornována (canceled)

Do stavu released se záznam o chybě dostává po jeho vytvoření. Jakmile je definován úkol či skupina úkolů, záznam o chybě přechází do stavu waiting. Dále by měl stav záznamu o chybě odpovídat stavu souvisejícího úkolu. Datum a čas poslední změny stavu chyby poukazuje na poslední změnu stavu vývoje vedoucího k odstranění chyby. Pokud je chyba vyřešena (done), určuje tento údaj datum a čas jejího vyřešení. 56

Související úkol udává úkol, který byl definován za účelem vyřešení této chyby. Nemusí být zadán. Záznamy o chybách lze podobně jako úkoly sdružovat do skupin. To je výhodné zejména z důvodu přehlednosti a zejména pokud je uživatel, který chybu definuje, schopen přesně definovat dílčí chyby, které chybu vyvolaly. Poté lze u každé dílčí chyby přesně definovat související úkol. Přidávání a změna záznamů o chybách v seznamu chyb je opět dána přístupovými právy ke každému z těchto objektů. Práva určuje administrátor projektu. Jsou definovány tři typy přístupových práv k záznamu o chybě. •

Čtení (read)

•

Modifikace (edit)

•

Možnost vytvoření podřízeného záznamu o chybě (create sub)

Uživatelé s přístupovým právem čtení mohou daný záznam o chybě pouze vidět. Měnit všechny jeho atributy mohou uživatelé s přístupovým právem modifikace. Vidět informace o záznamu o chybě a možnost vytvořit podřízený záznam mají uživatelé s právem možnosti vytvoření podřízeného záznamu o chybě.

3.2.10

Diskusní fórum (Mail forum)

Ke každému projektu může být vytvořeno diskusní fórum (mail forum). Slouží především pro komunikaci mezi vývojáři daného projektu. Je tvořeno stromovou strukturou objektů typu mail. Práce s těmito objekty se velmi podobá práci ve standardních aplikacích pro správu elektronické pošty používané v síti internet. Oprávnění k vytvoření diskusního fóra k příslušnému projektu má pouze administrátor projektu (uživatel s přístupovými právy k projektu typu modifikace). Provádí se z domovské stránky projektu pomocí odkazu nový objekt (new object). Poté vybereme z nabídky volbu mail forum. Po vytvoření získá tento objekt počáteční přístupová práva shodná s přístupovými právy rodičovského projektu. Každý diskusní příspěvek má následující atributy: •

odesílatel (sender)

•

datum odeslání příspěvku

•

předmět (subject)

•

tělo příspěvku (body)

57

Při vytváření či modifikaci diskusního příspěvku je požadováno, aby byl zadán předmět příspěvku. Každý diskusní příspěvek (mail) může mít nastaveny tři druhy přístupových práv. Uživatelé s právy typu modifikace (edit) mohou editovat obsah diskusního příspěvku. Dále mohou odpovídat na příspěvek pomocí odkazu odpovědět (reply), čímž dojde k vytvoření nového diskusního příspěvku. Mají také pravomoc měnit přístupová práva k diskusnímu příspěvku. Uživatelé s přístupovými právy k diskusnímu příspěvku typu odpovědět (create sub) mají právo vidět diskusní příspěvek bez možnosti měnit jeho obsah. Mohou reagovat na příspěvek svou odpovědí pomocí odkazu odpovědět (reply). Posledním typem přístupových práv k diskusnímu příspěvku jsou práva typu čtení (read). Uživatelé s tímto oprávněním mohou diskusní příspěvek zobrazit, ale nemohou měnit jeho obsah, ani na něj reagovat odpovědí. Přístupová práva k typu odpovědět (create sub) je vhodné nastavit například u takových příspěvků, které slouží k vytvoření logických skupin příspěvků s cílem zachování přehlednosti a snadné orientace v diskusním fóru.

3.2.11

Zveřejněné soubory (Releases)

Zveřejněné soubory (releases) umožňují přístup k nejnovějším souborům softwarového produktu, které jsou výsledkem vývojového procesu projektu. Vytvořit nový objekt typu zveřejněný soubor může administrátor projektu ze stránky projektu pomocí odkazu nový objekt (new object) s následující volbou zveřejněný sobor (release). Každý objekt typu zveřejněný soubor má následující atributy: •

název zveřejněného souboru (release name)

•

verze souboru (version)

•

datum jeho uvedení

•

poznámka (release description)

•

odkaz na soubor (file).

Název zveřejněného souboru slouží jako stručný popis souboru a musí být vyplněn. Verze by měla odpovídat konvencím pro označování verzí softwarových produktů (viz. kapitola 2.4.4) a musí být vyplněna. Poznámka může obsahovat

58

doplňující informace k zveřejněnému souboru. Odkaz na soubor umožní stažení uloženého souboru. Ukládání zveřejňovaného souboru na server se provádí při vytváření či modifikaci objektu typu zveřejněný soubor. Výběr souboru z pevného disku počítače přihlášeného uživatele lze provést pomocí tlačítka browse na stránce editace objektu. K objektu typu zveřejněný soubor jsou definovány dva typy přístupových práv. Uživatelé s přístupovým právem typu čtení (read) mohou vidět informace o zveřejněném souboru, mohou si soubor uložit na svůj pevný disk, ovšem nemohou měnit žádné informace o zveřejněném souboru ani uložit na server aplikace soubor jiný. Uživatelé s přístupovým právem typu modifikace (edit), kterými jsou ve většině případů administrátoři projektu, mohou měnit veškeré informace o zveřejněném souboru včetně možnosti uložení jiného souboru na server, než který byl uložen při vytvoření tohoto objektu zveřejněný soubor.

3.2.12

Zdrojové kódy (Source codes)

Pro správu zdrojových kódů byl zvolen již existující systém CVS [13], při současném použití jeho nadstavby WebCVS [14], umožňující přistup ke zdrojovým kódům přes rozhraní sítě internet. Nabízí komplexní řešení pro zprávu zdrojových kódů. Jeho popis je nad rámec této diplomové práce.

3.2.13

Přístupová práva k objektům

Každý objekt aplikace má nejméně dva typy přístupových práv – čtení (read) a modifikace (edit). Některé objekty mají ještě další typy přístupovým práv (viz. popisy jednotlivých objektů). Nastavení přístupových práv k objektu lze provést ze stránky objektu pomocí odkazu přístupová práva (access rights). Tuto možnost mají pouze ti uživatelé, kteří mají k danému objektu přístupové právo typu modifikace (edit). Obrázek 3.7 zachycuje příklad stránky pro nastavení práv k objektu typu projekt. Při vytváření objektu jsou všechna práva automaticky děděna. V závislosti na typu vytvářeného objektu jsou navíc automaticky přidána ještě některá práva uživateli, který objekt vytváří, aby tomuto uživateli byla nadále umožněna editace atributů a přístupových práv jím vytvářeného objektu. Kompatibilita dědění přístupových práv je zajištěna, neboť nadřazený objekt má množinu přípustných typů práv shodnou nebo

59

omezenější než objekt podřízený. Potomci podřízených objektů, které nejsou typu projekt, mohou vlastnit pouze objekty stejného typu. Přístupová práva k objektu mají oprávnění měnit pouze uživatelé s přístupovým právem k objektu typu modifikace (edit) a to v libovolném rozsahu. Jediné omezení spočívá v tom, že nesmí odebrat přístupová práva typu modifikace sami sobě, neboť by tím okamžitě ztratili možnost zasahovat do přístupových práv k objektu. Změna přístupových práv je možná ze stránky přístupových práv objektu, která je dostupná pomocí odkazu access rights v pravém horním rohu aplikace.

Obrázek 3.7: Okno pro nastavování přístupových práv k objektu typu projekt.

Přístupová práva lze nastavit buď pro jednotlivé uživatele, nebo pro celé skupiny uživatelů. Přidání práva uživateli se provádí pomocí odkazu přidat uživatele (add user). Zobrazí se seznam uživatelů skupiny běžní uživatelé, takových, kteří ještě nemají nastavena žádná práva k danému objektu. Vybereme požadované uživatele ze seznamu a po stisknutí tlačítka add dojde k vložení přístupových práv pro vybrané uživatele s výchozím nastavením přístupového práva typu čtení. Přidání přístupového práva 60

skupině uživatelů se provádí podobně, jako přidávání přístupového práva uživateli, s tím rozdílem, že vybíráme ze seznamu uživateli přístupných skupin uživatelů. Uživateli přístupné skupiny jsou takové skupiny, ke kterým má uživatel přístupové právo nejméně typu čtení. Změnu typu přístupového práva pro konkrétní uživatele či skupiny uživatelů lze provést na stránce přístupových práv k objektu a to zaškrtnutím vybraných uživatelů či skupin uživatelů a změnou typu přístupového práva v roletové nabídce. Než použijeme tlačítka submit pro uložení změn, můžeme volit mezi několika způsoby aplikace změn přístupových práv: •

Provést změny u vybraných práv pouze u tohoto objektu (Apply selected right changes (this object only))

•

Provést změny u vybraných práv u tohoto a všech podřízených objektů (Apply selected right changes (this object and all children objects))

Dále je potom možné aplikovat na vybraná práva volby: •

Odstranit vybraná práva pouze u tohoto objektu (remove selected right changes (this object only))

•

Odstranit vybraná práva u tohoto a všech podřízených objektů (remove selected right changes (this object and all children objects))

Poslední možnou volbou je: •

Nastavit identická práva u všech podřízených objektů (Set the same rights for all children object)

Při této volbě nemusí být žádná přístupová práva vybrána. U všech podřízených objektů budou všechna aktuální přístupová práva odstraněna a nahrazena přístupovými právy aktuálního objektu. V některých případech použití této funkce může dojít k nevhodnému nastavení přístupových práv u podřízených objektů, zejména pokud nejsou podřízené objekty stejného typu jako objekt, z kterého práva dědíme. Poté je nutné u všech podřízených projektů modifikovat přístupová práva tak, aby odpovídala požadovaným. Z těchto důvodů je nutné použití této funkce dobře zvážit. Přístupová práva k libovolnému objektu mohou být kdykoliv modifikována členy uživatelské skupiny administrátoři systému.

61

4 Závěr Byl navržen a implementován informační systém pro řízení projektu vývoje software. Vzniknul tak jednoduchý nástroj pro řízení softwarového projektu s vlastnostmi požadovanými v zadání. Pomocí nástrojů jako jsou diskusní fórum, seznam úkolů projektu a seznam chyb projektu lze snadným způsobem řídit práci vývojového týmu na softwarovém projektu. Aplikace byla navržena pro používání v síti internet. Připojení k informačnímu systému lze tedy provést odkudkoli, kde má uživatel přístup k počítači s internetovým připojením a internetovým prohlížečem. Registrovaní uživatelé mají možnost se přihlašovat do systému pod svým uživatelským jménem a mohou být administrátory projektů seskupováni do skupin uživatelů, za účelem nastavování přístupových práv k součástem projektu. Aplikace je přehledná, neboť na co přihlášený uživatel nemá oprávnění, to „nevidí“. Přístupová práva k součástem projektů mohou být nastavována jak jednotlivcům, tak skupinám uživatelů. Důvodem vzniku této aplikace byla neexistence snadno dostupného, podobně jednoduchého nástroje pro řízení projektu vývoje software. Existující systémy jsou ve většině případů příliš složité (např. [15]), nebo finančně nákladné (např. [16]). Aplikace byla implementována pomocí skriptovacího jazyka PHP4 [8], je tedy platformově nezávislá. Jisté problémy při přenosu systému na jiné platformy mohou být způsobeny odlišnou interpretací kódu aplikace. Mohou se vyskytnout nepředpokládané chyby v interpretaci PHP kódu, což ovšem není chyba implementace, ale interpretace kódu zvoleným interpreterem. Aplikace byla otestována pod operačním systém Windows 9x v kombinaci s HTTP serverem Apache [9] a pod operačním systémem Windows 2000 s jeho službou IIS (Internet Information Server) [10]. Byly vyzkoušeny dva databázové systémy s odlišnou konektivitou (databáze MySQL a přes rozhraní ODBC databáze MS Access 2000). Konektivitu na jiné databázové systémy lze provést snadným rozšířením kódu aplikace o třídu zprostředkovávající spojení ke zvolené databázi. Z časových důvodů nebylo možné Informační systém pro řízení projektu vývoje software otestovat v praxi. Při jeho provozu se pravděpodobně vyskytnou požadavky na změnu některých funkcí, či vyvstane požadavek na vznik funkcí nových. Díky jednoduché struktuře kódu aplikace však může vývoj tohoto produktu pokračovat dále. 62

5 Literatura [1]

Vosátka, K.: studijní podklady pro předmět Řízení softwarových projektů. Dostupné z URL: http://cs.felk.cvut.cz/~richta/www-si2/.

[2]

Vlček, T.: studijní podklady pro předmět Počítačem podporovaná výroba. Dostupné z URL: http://labe.felk.cvut.cz/pub/vyuka/33PPV/pdf/. Praha.

[3]

Richta, K., Sochor, J.: Softwarové inženýrství I. Skripta. Vydavatelství ČVUT, Praha 1998. ISBN 80-01-01428-2.

[4]

IEEE. Software Engineering Standards. IEEE Press, 1987.

[5]

Jalote, P.: An Integrated Approach to Software Engineering. Springer, second edition, 1997.

[6]

Unified Modeling Language. Školící podklady společnosti Unicorn. Praha 2000.

[7]

Definice Open Source. Dostupná z URL: .

[8]

Technologie PHP včetně dokumentace. Dostupná z URL: .

[9]

Apache HTTP server. Dostupný z URL: .

[10] Informace o platformě Win32 a produktech společnosti Microsoft dostupné z URL: . [11] Databázový systém MySQL. Dostupný z: . [12] Informace o algoritmu MD5 společnosti RSA security, Inc. dostupné z URL: . [13] CVS (Concurrent Version System) pro správu verzí zdrojových kódů. Dostupný z URL: . [14] Software WebCVS pro správu verzí zdrojového kódu. Dostupný z URL: . [15] SourceForge - systém pro vývoj software. Dostupný z URL: . [16] Software ClearCase pro správu verzí. Dostupný z URL: . 63

6 Obsah přiloženého CD K diplomové práci je přiloženo CD s následujícím obsahem: •

Zdrojové kódy aplikace Informační systém pro řízení projektu vývoje software v jazyce PHP4.

•

Textový soubor readme.txt obsahující návod na instalaci a konfiguraci aplikace.

•

Textový soubor issdpc_sql.txt obsahující SQL příkazy pro vytvoření a inicializaci databáze ISSDPC pro MySQL server.

•

Vytvořenou a inicializovanou databázi pro databázový server MySQL.

•

Vytvořenou a inicializovanou databázi pro databázový server MySQL s vytvořenými příklady projektů a jim podřízených objektů.

•

Dokument diplomové práce ve formátech MS Word 2000 a PDF.

7 Přílohy Seznam příloh A – Diagram tříd ISSDPC B – Diagram tříd, atributy uložené v databázi C – Diagram tříd, důležité metody D – Struktura stránek aplikace, uživatelská role návštěvník E – Struktura stránek aplikace, ostatní uživatelské role

64

65

66

67

68

69