====== N-INS 1.2 První otázka (druhá část) ====== ====== Zadání ====== Strukturovaná analýza. Objektová analýza a návrh, UML. Nástroje a modely datové, funkční a časové dimenze systému. Softwarové metriky. CMM. Odhady COCOMO a funkční body. ====== Vypracování ====== ===== Strukturovaná analýza ===== **Lit. 4** ANANAS (6. až 10. přednáška), **Lit.8** Vypracované otázky k IS, **Lit.9** Analyza a navrh IS (Strukturovana analyza) === Charakteristika ==== Při strukturované analýze je systém zkoumán zejména ze dvou základních pohledů: * **funkčně orientovaný přístup** -- Systém jako množina interagujících funkcí. Funkční transformace jsou umístěny v procesech, které jsou propojeny datovými a řídícími toky. * **datově orientovaný přístup** -- Hledá fundamentální datové struktury aplikace. Funkční stránka (tj. různé transformace dat) je méně podstatná. Datový model definuje konceptuální model pro DB systému. * SA oba dva přístupy vzájemně kombinuje -- oddělené funkční a datové modely. * Postupné zpřesňování modelů. * Snaha o zachování konzistence: uvnitř modelu a vzájemně mezi jednotlivými modely. ==== YMSA ==== * E.Yourdon -- Moderní strukturovaná analýza (1989) * reakce na kritiku Analýzy pomocí 4 modelů (viz níže) * Při formulaci fyzického modelu ví uživatel o systému více, než analytik. Má pocit, že „analytik tomu nerozumí, za moje peníze se to učí“. * Uživatel odmítá spolupráci na vývoji logického modelu. „Pokud analytik neuměl stvořit sám ani fyzický model, tak nemůže navrhnout dobře ani nový systém.“ * Analytická fáze je „období nicnedělání“, skutečná práce začne, až když se začne programovat. Tvorba 4 modelů prodlužuje období „nicnedělání“. * Mnoho uživatelů navíc zpochybňuje smysl podrobné a pečlivé tvorby modelu systému, který bude stejně! zahozen a nahrazen novým systémem. * analýza s esenciálním modelem (dlouhodobě stabilní systém) * z esenciálního modelu se odvodí implementační model === Esenciální model === Skládá se ze dvou částí: == Model okolí == * popisuje rozhraní mezi systémem a okolním světem * kontextový diagram (DFD s jediným procesom + terminátory -- lidé a systémy z okolí, s nimiž systém komunikuje) * seznam událostí: toky (flow), časové události (temporal), řídící události (control) * prvotní dátový slovník (datová rozhraní mezi systémem a terminátory) == Model chování systému == * popisuje vnitřní části systému * dekompozici systému na jednotlivé procesy, toky a paměti uspořádané v sadě DFD a doplněné o příslušné minispecifikace a definici datových komponent * uplatňuje sa postup zdola-nahoru * prvotní model chování: prvotní systémový DFD + ERD a datový slovník * tvorba esenciálního modelu: vyvažování prvotního modelu chování (směrem nahoru -- seskupování, i směrem dolů -- dekompozice) * kontrola konzistentnosti DFD s ERD * definování procesů pomocí minispecifikací a řídících procesů pomocí STD (stavových diagramů) === Implementační model === * vybere se jenom automatizovaná část systému, manuální část se převede na terminátory * určení uživatelského rozhraní * doporučení pro návrh rozhraní * návrh formulářů * identifikace manuálních podpůrných aktivit * opatření pro chybové technologie * specifikace operačních omezení == Postup === - vytvoření modelu okolí systému - vytvoření prvotního modelu chování systému - dokončení esenciálního modelu - vytvoření implementačního modelu ==== Další metody ==== === SASS === * Structured Analysis and System Specification * DeMarco (1978) -- připisováno prvenství při použití DFD * shora-dolů * Analýza pomocí 4 modelů == Základní kroky metodiky == - **Studie stávajícího fyzického systému** - **Odvození logického ekvivalentu stávajícího systému** - **Odvození nového logického systému** - **Odvození nového fyzického systému** - Kvantifikace cen a termínů - Výběr jedné z možností - Začlenění nového fyzického modelu do specifikace === Logické modelování === * Gane, Sarson (1979) -- DFD + ERD {{:mgr-szz:in-ins:1_log_mod.jpg?500|}} === Pohledová analýza === * View Point Analysis - VPA * Mullery (1979) * zdola-nahoru == Použití == * hierarchie entit není dosud vytvořena, * hierarchie entit není na první pohled zřejmá, * systém není přirozeně hierarchicky uspořádán == Kroky == - identifikace pozorovacích bodů - sdružení pohledů do skupin (funkční, nefunkční, hraniční, definiční pohledy) - určení struktury pohledů === DSSD === * Data Structure Systems Development * datově orientovaný pŕístup * nejedná se o striktně stanovenou metodiku, spíše jde o souhrn zkušeností, které vedly ve většině případů k úspěchu === SSADM === * Structured System Analysis and Design Methodology * důraz kladen na detailní a strukturovaný přístup v každé etapě životního cyklu vývoje * používá se při vývoji systémů, ale nepokrývá celý životní cyklus systému == 3 základní pohledy na informační systém == * Logické datové struktury - LDS * Diagramy datových toků - DFD * Životní cykly entit - ELH (Entity Life History) == Etapy == - stávající systém je analyzován s cílem porozumět problémové oblasti nového systému. - pohled na stávající systém je použit pro vytvoření specifikace požadavků systému. - specifikace požadavků je zpracována detailně, takže je možné formulovat podrobné technické možnosti a alternativy. - současně s následujícím krokem (návrh log. procesů) je vypracován návrh logických dat. Vznikající modely jsou navzájem neustále vyvažovány. - je vytvořen návrh logických procesů (viz. předchozí etapa). - logický návrh je převeden na fyzický návrh při aplikaci jednoduchých pravidel. ===== Objektová analýza a návrh, UML ===== **Lit. 4** ANANAS (11. až 14. přednáška), **Lit. 6** OMNIS (1., 3.-11. přednáška) **Lit.8** Vypracované otázky k IS, **Lit.9** Analyza a navrh IS (Objektova analyza a navrh, UML) ==== Objektová analýza a návrh ==== * objekty kombinují data a funkce do uzavřené podoby, soudržné jednotky * objekty ukrývají data za vrstvou funkcí (operací) * modeluje požadavky na systém prostřednictvím objektů a jimi poskytovaných metod * objekty se oproti funkcím (příliš) nemění, tedy OO model tolik nezestárne a proto je lépe udržovatelný === Principy zvládnutí složitosti === * abstrakce procedurální a datová * zapouzdření * dědičnost * sdružování * komunikace pomocí zpráv * postup metody organizace * měřítko * kategorie chování === Abstrakce === * principem abstrakce je ignorovat ty aspekty subjektu, které nejsou významné pro současný účel, abychom se mohli víc soustředit na ty, které významné jsou. * vymezuje podstatné znaky objektu, které jej odlišují od ostatních druhů objektů, a tak poskytuje ostře definované koncept. hranice relativně podle perspektivy pozorovatele. * **Procedurální abstrakce:** každá operace, která docílí jasně definovaného výsledku, může být považována a používána jako jednoduchá entita, i když ve skutečnosti je realizována nějakou sekvencí operací nižší úrovně. * **Datová abstrakce:** princip definice datového typu pomocí operací, které jsou aplikovány na objekty příslušného typu s tím omezením, že hodnoty těchto objektů mohou být modifikovány a pozorovány pouze pomocí operací. === Zapouzdření === * ukrytí informace * princip použitý při vývoji celé programové struktury * spočívá v tom, že každá komponenta programu by měla zapouzdřit a ukrýt jediné návrhové rozhodnutí. * rozhraní každého modulu je definováno tak, aby odhalilo co nejméně o vnitřním dění v modulu. === Objekt === * má stav, chování a identitu * struktura a chování podobných objekt jsou definovány v jejich společné třídě * pojmy instance a objekt jsou vzájemně zaměnitelné === Stav objektu === * zahrnuje všechny (obvykle statické) vlastnosti objektu plus současné (obvykle dynamické) hodnoty těchto vlastností === Chování === * vyjadřuje, jak objekt koná a reaguje, v pojmech změn stavu a předávání zpráv === Třída === * je množina objektů, které sdílejí společnou strukturu a shodné chování * objekt je instancí třídy * atributy –- reprezentují strukturu třídy === Hierarchie === * znamená hodnostní zařazení nebo uspořádání abstrakcí * „is-a” hierarchie („je něčím”) = dědičnost * „part-of” hierarchie („součást něčeho”) = sestava vnitřní struktury objektu === Dědičnost === * mechanismus, který vyjadřuje podobnost mezi třídami * zjednodušuje definici třídy pomocí již dříve definované třídy * vyjadřuje generalizaci a specializaci tím, že v hierarchii tříd explicitně určuje společné atributy a služby === Propojení (vazba) === * fyzické nebo konceptuální spojení mezi objekty * označuje speciální asociaci, pomocí níž 1 objekt (klient) používá služby jiného objektu (poskytovatel, dodavatel) nebo pomocí níž může jeden objekt navigovat druhý objekt === Role účastníků propojení === - Aktor (aktivní objekt) –- může operovat s jinými objekty, ale sám není nikdy takto operován - Server –- nikdy neoperuje s jinými objekty, a sám je operován jinými - Agent –- operuje s jinými objekty a sám je operován jinými objekty (agenty i aktory) === Polymorfizmus === Umožňuje: * jednomu objektu volat jednu metodu s různými parametry (parametrický polymorfismus) * objektům odvozených z různých tříd volat tutéž metodu se stejným významem v kontextu jejich třídy, často pomocí rozhraní * přetěžování operátorů znamená provedení operace v závislosti na typu operandů (operátorový polymorfismus) === Coad – Yourdon: 5-vrstvý model === - identifikace tříd a objektů (dědičnost) - identifikace struktur („part-of” vztahů) - definice subjektů - definice atributů - definice služeb ==== UML ==== * Unified Modeling Language * standardní jazyk pro zobrazení, specifikaci, konstrukci a dokumentaci artefaktů systémů s převážně SW charakterem * může být použit při všech procesech životního cyklu vývoje a pro různé technologie a implementace === Modelovací techniky UML === * specifické vyjadřovací prostředky (jazyky) pro popis konceptů na vysoké úrovni abstrakce * grafické vyjádření – pro pochopení, dokumentaci a vysvětlení problému * zápis myšlenek strukturovaným způsobem napomáhá ke zvládnutí složitosti a multidimenzionality SW === Diagramy v UML === - modely ukazující **statickou strukturu** systému * diagramy tříd (grafický pohled na statickou strukturu) a objektové diagramy (instance diagramu tříd, ukazuje snímek systému v určitém bod) * implementační diagramy (diagram komponent, rozmístění) - modely ukazující **dynamické chování systému** * model případů užití –- externí pohled na systém (aktéři a případy užití) * diagram aktivit –- externě/interní pohled na systém * interakční diagram: diagram sekvencí a diagram spolupráce –- interní pohled na systém - modely ukazující **dynamické chování jedné třídy** * stavové diagramy, diagramy aktivit == Modelování požadavků na systém == * **use case diagram**: aktéři (role--uživatelé, externí systémy i čas) a případy užití (funkcionalita) * specifikace případů užití pomocí **minispecifikace** -- název, aktéři, omezení, toky událostí (scénáře). Forma: číslované kroky, pseudokód, **diagram aktivit** nebo pomocí **diagramů interakcí** s pseudokódem. == Analýza, modelování analytických tříd a objektů == * základní modely, bez implementačních detailů * většinou platformě nezávislé * **diagramy tříd** (grafický pohled na statickou strukturu): atributy, vztahy mezi třídami (asociace, závislosti, generalizace/specializace) * **objektové diagramy** (instance diagramu tříd, ukazuje snímek systému v určitém bod) * **diagram balíků**: balíky na analytické úrovni == Realizace případů užití (analýza/návrh) == **Diagramy interakcí:** * **sekvenční diagramy** (sequence d.) -- modelují výměnu zpráv s důrazem na časovou osu * **komunikační diagramy** (communication d.) -- modelují interakce organizované podle interagujících objektů * **diagramy přehledů interakcí** (interaction overview d.) -- ukazují realizaci složitého chování pomocí několika jednodušších interakcí (kombinuje sekvenční diagramy a digramy aktivit) * **časovací diagramy** (timing d.) -- zaměřují se na “real-timové” aspekty interakcí, časová omezení a závislosti, ... == Návrh == * detailní modely * zvolený cílový jazyk, technologie, ... * detailní **diagram tříd** na návrhové úrovni: návrhové třídy (otypované atributy a metody), vazby (upřesnění asociace: směr, agregace, kompozice, násobnost) * **diagram balíků**: balíky na návrhové úrovni * **diagramy komponent** * **diagramy rozmístění** === Vztahy === * cesta pro komunikaci mezi objekty. * **asociace** –- obousměrné propojení mezi třídami * **agregace** –- vztah mezi celkem a jeho částmi (silnější forma vztahu) * **kompozice** -- agregace se silnějším vlastnictvím a společným životem částí v celku. Části neexistují vně celku, každá část patří do jediného celku. * **závislost** –- slabší forma vztahu, mezi klientem a poskytovatelem, klient nemá žádnou znalost o poskytovateli === Násobnost === * definuje, kolik objektů se účastní vztahů (počet instancí jedné třídy vztažený k jedné instanci druhé třídy) === Navigace === * určuje směr propojení a směr návěstí === Dědičnost === * vztah mezi nadtřídou a podtřídami === Událost === * z pohledu stavového diagramu je to výskyt jevu, který může spustit přechod mezi stavy ===== Nástroje a modely datové, funkční a časové dimenze systému ===== **Našiel som toto:** **Lit. 9** Analyza a navrh IS (Nastroje a modely datove, funkcni a casove dimenze systemu). **Keď tak doplňte...** ==== Strukturovaná analýza ==== === Datové dimenze === * ERD * datový slovník (Data Dictionary) * jedná se o seznam definicí datových prvků systému. * popisuje obsah dat v datových tocích a pamětech na DFD, entity a atributy na ERD i další klíčová slova. objednávka zboží = @ id objednávky + kód zákazníka + {název zboží + množství zboží} id objednávky = {0 - 9} kód zákazníka = {0 - 9} název zboží = {{a - ž} | {A - Ž}} množství zboží = {0 - 9} * = je 'skládá se z' * + je 'a' * @ je klíč * {...} značí opakující se prvek * (...) nepovinný prvek === Funkční dimenze === * DFD * datové toky * procesy * paměti * terminátory * DFD bývají víceúrovňové * minispecifikace procesů * slovní popis algoritmického chování (každý proces má minispecifikaci nebo je dále dekomponovaný, jiná varianta není) === Časové dimenze === * STD * graf stavů a přechodů ==== Objektová analýza ==== === Datové dimenze === * statické diagramy === Funkční + časové dimenze === * dynamické diagramy * stavový diagram ===== Softwarové metriky ===== **Lit. 1** Kniha IS (str. 227-262), **Lit. 3** TIS II (11-kap11_15), **Lit. 5** VTP (10. prednáška), **Lit. 8** Vypracované otázky k IS, **Lit. 9** Analyza a navrh IS.mm (Softwarove metriky). ==== Měření SW ==== **Measure** -- quantitative indication of extent, amount, dimension, capacity, or size of some attribute of a product or process. – Number of errors **Metric** -- quantitative measure of degree to which a system, component or process possesses a given attribute. “A handle or guess about a given attribute.” – Number of errors found per person hours expended **KPI** -- KPIs are measurable industry, department or task relevant performance metrics that are evaluated over a specified time period, and compared against acceptable norms, past performance or targets. Linked to business plans/performance. * bez měření nelze kvalitně řídit ani hodnotit kvalitu SW, atributy kvality mohou ale být různé * je součástí business intelligence SW firmy a přepoklad uplatnění moderních způsobů řízení (CMM) * sledování kvantitativní charakteristiky (počet řádků, doba řešení, spotřeba práce, ...) * základ zajištění kvality SW * hodnoty metrik jsou cosi jako paměť firmy * metrika = „kvalifikovaný” atribut SW ==== Použití SW metrik ==== * **Výzkum:** podklad pro hledání metod realizace softwarových produktů, které by přinesly podstatné zvýšení jeho kvality a snížení nákladů a doby vývoje a hlavně rozsahu prací při údržbě softwaru (výzkum metod a zákonitostí vývoje softwaru). * **Normy:** základ pro stanovení technicko-ekonomických podkladů pro řízení prací při tvorbě softwaru (normy pracnosti, odhady takových metrik, jako je pracnost či doba řešení) a uzavírání smluv (cena, termíny), předpoklad CMM. * **Kontrola kvality:** prostředek sledování spolehlivosti softwaru při provozu a podklad pro řídící zásahy během údržby,procesy zajišťující kvalitu. * **Operativa:** prostředek sledování průběhu prací při vývoji (dodržování termínů, procento testovaných komponent, trendy počtů chyb, počty nově zanesených chyb, komponenty s největším počtem chyb, atd.). ==== Druhy metrík ==== * **Implicitní (in proces)** -- zjistitelné pouze během vývoje * **Explicitní (after proces)** -- zjistí se kdykoliv i po skončení vývoje (z artefaktů produktů systému) * **Interní** -- potřebuje řešitelský tým pro řízení a kontrolu prací: cost, effort, LOC, speed, memory, ... * **Externí** -- charakterizují uživatelské vlastnosti produktu: functionality, quality, complexity, efficiency, reliability, maintainability, ... * **produktové:** zdrojový kód, dokumentace, cyklomatická složitost (počet cest programem), počty funkčních bodů * **procesní:** činnosti spojené s vývojem, doba strávená na jednotlivých úlohách, původní odhad a skutečná reálná doba * **metriky zdrojů:** HW, lidé, čas, nemocnost, výkonnost === Implicitní (in proces) === * //Prac// -- pracnost * //Doba// -- doba řešení * //team(t)// a //Team// -- velikost týmu v čase a průměrná velikost * //MTBF(t)// -- střední doba mezi poruchami * další: spotřeba práce, produktivita, počet selhání systému v čase, defekty, spokojenost zákazníka, ... === Explicitní (after proces) === * //Del// -- délka programu v řádcích * //Fun(P)// -- počet podprogramů, počet metod * //Srnd// a //Nrnd// -- rozsah a výskyt operandů, * //Soper// a //Noper// -- rozsah a výskyt operací, * další: počet funkcí, tříd, počet datových tabulek, ... ==== Potíže s metrikami ==== * rozptyl hodnot * produktivita práce programátor, jejich kvalita * druh SW, obtížně splnitelné termíny realizace * moderní projekční techniky * kvalita zúčastněných * omezení SW a HW ==== Datové typy metrik ==== * příslušnost ke třídě -- id, číslo tramvaje; vztah: = * fuzzy metrika –- slabý, dobrý, velmi dobrý, vynikající; vztah: =, < * fuzzy číselná -- známky ve škole; vztah: =, < , (aritm. operace) * interval -- teplota, čas * číselná metrika -- plná data (délka, ...) ===== CMM ===== **Lit. 1** Kniha IS (str. 293-295), **Lit. 5** VTP (12. prednáška), **Lit. 8** Vypracované otázky k IS, **Lit. 9** Analyza a navrh IS.mm (CMM). ==== CMM = Capability Maturity Model ==== * definuje kvalitu procesu, ne jen výrobků * neříká jak, ale pouze co je nutné mít * cílem je zvýšení spokojenosti uživatelů SW systémů, zlepšení kvality SW a omezení rizik spojených s vývojem SW * nástroj na zlepšení efektivity práce firmy, obsahuje postupy na snižování nákladů, zkrácení termínů, eliminaci rizik spojených s migrací pracovníků * hodnotí vyspělost organizací podle stupně a kvality využívání SW procesů (SWP) * definuje 5 úrovní vyspělosti SWP ==== 1. Počáteční úroveň (initial level) ==== Chaotický proces, nepředvídatelná cena, plán a kvalita. * SWP v neformální formě a definuje se případ od případu od počátku * nejsou pevná pravidla plánování a řízení projektů * výsledky záleží spíš na kvalitě jednotlivce než organizaci práce, zkušenosti se nevyužívají, po odchodu pracovníka jsou ztraceny ==== 2. Úroveň zajišťující opakovatelnost (repeated level) ==== Intuitivní cena a kvalita jsou vysoce proměnlivé. Neformální metody a procedury. Zavedena pravidla pro řízení projektu, plánování a řízení založeno na zkušenostech. Jednotné zásady pro celou firmu, SWP nejsou standardizovány, plány realizace se sledují, náprava při odchylkách. Klíčové prvky : * řízené požadavky * plánování softwarového projektu * řízené subkontrakty na software * zajištění kvality software * řízení softwarových konfigurací ==== 3. Úroveň definovaných procesů (defined level) ==== Orientován na kvalitu. Spolehlivé ceny a plány, zlepšující se, ale dosud nepředvídatelný přínos (výkon) systému kvality. SWP standardizováno (jak procesy SW – inženýrské, tak manažerské), součástí norem jsou nástroje kontroly a zvýšení efektivity práce, zkušenosti a osvědčené metody a postupy. Součástí standardů jsou procedury přizpůsobení SWP na konkrétní projekt, zajištěna kontrola dodržování požadavků, nákladů a termínů. SWP založeno na odborném zázemí a znalostech pracovníků firmy, pravidelná školení. Klíčové prvky: * zlepšování organizačního procesu * definice organizačního procesu * standardizace prací všech etap vývoje * školicí program * řízení integrovaného software * aplikace inženýrských metod u softwarového produktu * podpora týmové práce, spolupráce mezi týmy * detailní prověrky a oponentury, audity ==== 4. Úroveň řízení procesů (controled level) ==== Kvantitativní; promyšlená statisticky řízená kvalita produktu. Definovány metriky kvality pro SWP i vývoj SW, systém sběru, sledování a vyhodnocování metrik jednotným způsobem v rámci celé organizace. Firma je schopná vyhodnocovat trendy a odhad hodnoty důležitých metrik, schopná odhadnout přesnost odhadů stanovením konfidenčních intervalů (intervaly spolehlivosti), tj. mezí, do nichž s velkou pravděpodobností padne odhadovaná hodnota. Klíčové prvky: * měření a kvantitativní řízení procesu výroby * řízení kvality ==== 5. Úroveň optimalizace procesů (optimized level) ==== Kvantitativní základ pro kontinuální investice směřující k automatizaci a zlepšení výrobního procesu. Zavedeny procedury neustálého vylepšování SWP, vytvořen tým hodnotící kvalitu procesů a navrhující vylepšení včetně zavádění nejnovějších metod, postupů a nástrojů. Tým analyzuje příčiny úspěchů i neúspěchů, pak modifikuje SWP. Klíčové prvky: * prevence chyb * inovace technologie * optimalizace SW procesů * řízené změny výrobních procesů Mnemotechnická pomůcka pro zapamatování anglických názvů CMM úrovní: **IR**i**D**ium **CO**balt ===== Odhady COCOMO a funkční body ===== **Lit. 1** Kniha IS (str. 264-275), **Lit. 3** TIS II (odhady), **Lit. 5** VTP (4., 5. a 6. přednáška), **Lit. 8** Vypracované otázky k IS, **Lit. 9** Analyza a navrh IS.mm (Cocomo a funkcni body). ==== Odhady ==== * dva principy odhadu -- odhady pracnosti (člověko-měsíce) -- E a doby řešení (měsíce) -- T * obě varianty odhadu (COCOMO, FP) jsou použitelné v různých etapách životního cyklu * COCOMO -- vychází z odhadu délky programů KSLOC = tisíce zdrojových řádků (COCOCMO II už může mít na vstupe UFP) * Funkční body -- odhad na základě struktury aplikace (nezkoumá kód ale funkci aplikace) ==== COCOMO ==== **COCOMO – COnstructive COst MOdel** * existuje víc druhů COCOMO -- COCOMO 81, COCOMO II === COCOMO 81 === * Cena vývoje aplikace přímo závisí na velikosti SW. * Přesnost odhadu velikosti SW závisí na etapě vývoje. * V pozdějších etapách je odhad přesnější. * Přesnost odhadu se může lišit až čtyřikrát (4:1) oběma směry. == 3 úrovně detailu == * **Základní model** -- hrubý odhad E(KSLOC) a T(KSLOC) založen na odhadu KSLOC. * **Střední model** -- vliv jiných faktorů na E(KSLOC) a T(KSLOC). * **Pokročilý model** -- bere v úvahu vlivy vývojové etapy, ve které se projekt nachází. == Vývojové módy projektů == * **Organický mód** -- velikost projektu = málo set tisíc řádků, malé problémy pro malé týmy, typické jsou mírné normy a malá omezení na specifikaci rozhraní a možnost ovlivnit požadavky. Algoritmy a postupy jsou dobře známy, podmínky realizace relativně stabilní, nejsou ostré podmínky ani termíny. Příklad: zpracování dat v dávkovém provozu, úpravy známého operačního systému nebo kompilátoru. * **Bezprostřední (přechodný) mód** -- typ mezi organickým a vázaným, velikost projektu < 400 tisíc řádků, pokud není kód generován automaticky. V týmu jsou zkušení i méně zkušení pracovníci, tým má nemoc velké zkušenosti z předchozích obdobných realizací, úloha poměrně složitá. Příklad: menší dedikované oper. systémy, běžné transakční systémy, systém řízení výroby, jednoduchý systém řízení vojsk a zbraní. * **Vázaný mód** -- SW pracuje za velmi ostrych omezení na výkonnost a dobu odezvy, velikost jsou miliony řádků, vyžaduje práci s komplikovanýmy SW a HW systémy za ostrých předpokladů na předepsané fce, spolehlivost, termíny, přenositelnost, modifikovatelnost. Požadavky je obtížné měnit, řeší se nové problémy, se kterými se pracovníci dosud nesetkali. Obvykle: specifikaci požadavků + návrh dělá malá skupina, vývoj částí – velký tým. Programování a testy – souběžné. Příklad: nové rozsáhlé oper. systémy, kosmické lodě, letadla, atomové elektrárny, RT aplikace. == Atributy produktu == RELY – požadovaná spolehlivost DATA – velikost databáze CPLX – složitost produkt == HW atributy == TIME – omezení času výpočtu STOR – využití paměti/disku VIRT - spolehlivost virtuálních stroj TURN – míra rychlosti oběhu úlohy počítačem == Atributy vývojového týmu == ACAP – analytické schopnosti PCAP – programovací schopnosti AEXP – zkušenosti s podobnými aplikacemi VEXP – zkušenosti se spec. virt. strojem LEXP – zkušenosti se spec. prog. Jazykem == Atributy projektu == MODP – použití moderních prg. technik TOOL – použití SW nástrojů == Vzorce == E=a*(KSLOC)^b T=c*E^d a,b,c,d: parametry podle úrovně modelu a vývojového módu * V základním modelu mají všechny parametry konstantní hodnoty. * Ve středním a pokročilém modelu ve všech vývojových módech a závisí na F_c (a*F_c), ostatní parametry jsou konstantní. * korekční faktor F_c je součinem hodnot 15 atributů specifických pro vývojový proces == Postup při stanovení odhadu pracnosti == - určí se úroveň modelu a mód projektu - určí se hodnocení vlivu faktorů reprezentovaných jednotlivými atributy (velmi nízký, nízký, normální, velký, velmi velký, extrémně velký) - určí se číselné hodnocení atributů z tabulek - určí se korekční faktor F_c jako součin takto získaných hodnot (střední a pokročilý model) - podle úroveň modelu a módu projektu se určí parametry a,b,c,d a vypočtou hodnoty odhadu podle vzorců === COCOMO II (1995)=== Potřeba změnit COCOMO 81 * nové softwarové procesy * nové jevy měření velikostí * nové jevy znovupoužití software * potřeba rozhodování na základě neúplné informace == 3 různé modely == * ACM (Aplication Composition Model) pro projekty s použitím moderních nástrojů a GUI * EDM (Early Design Model) pro hrubé odhady v úvodních etapách, kdy se architektura vyvíjí * PAM (Post Architecture Model) pro odhady poté, co byla specifikována architektura == Výpočet == PM_estimated=A*(Size)^{(SF)}*(prod{i}{}{EM_i}) SF=1.01+0.01*sum{}{}{(hodnocení driverů exponentu)} A v rozsahu 1.01 - 1.26 Size je určená několika přístupy: * KSLOC (tis.řádek zdroj. kódu) * UFP (neupravené fukční body) * EKSLOC (ekvivalentní velikost zdroj. kódu) SF - upravený součet 5 driverů s hodnocením 0 – 5 Drivery exponentu: * návaznost na předchozí výsledky * flexibilita vývoje * rozhodnutí architektury/rizika * koheze týmu *vyspělost procesu (podle SEI CMM) EM: multiplikátory úsilí (7 pro EDM, 17 PAM) -- nové atributy ==== Funkční body ==== **Funkční body = normalizovaná metrika softwarového projektu** * měří aplikační oblast, nezkoumá technickou oblast * měří aplikační funkce a data, neměří kód * měří vstupy, výstupy, dotazy, vnitřní paměti, vnější paměti odhad = velikost projektu x složitost x rizikové faktory === Funkční body vztažené k transakčním funkcím === * Externí vstupy (EI - External Inputs) * Externí výstupy (EO - External Outputs) * Externí dotazy (EQ - External Enquiry) === Funkční body vztažené k datovým funkcím === * Vnitřní logické soubory (ILF - Internal Logical Files) * Soubory vnějšího rozhraní (EIF - External Interface Files) === Neupravené funkční body (UFP) === Před výpočtem musíme EI, EO, EQ, ILF, EIF roztřídit do skupin podle vah. Potom spočítame UFP {{:mgr-szz:in-ins:1_matica_ftr_det.png?350|}}{{:mgr-szz:in-ins:1_matica_ret_det.png?350|}}{{:mgr-szz:in-ins:1_ufp.png?400|}} === Faktor technické složitosti (FTS) === 14 charakteristik: * Jsou vyžadovány datové komunikace? * Je výkonnost kritická? * Požaduje systém on-line vstup dat? * Je kód navrhován s cílem znovupoužití?... (viz kniha) Každá charakteristika je hodnocená ve stupnici 0 – 5 takto: * 0 = bez vlivu * 1 = náhodný * 2 = mírný * 3 = průměrný * 4 = významný * 5 = podstatný === Výpočet === - Identifikujte a spočtěte ILF, EIF, EI , EO, EQ. Pro každou ILF a EIF identifikujte počet RET a počet DET. Pro každou EI, EO a EQ, identifikujte počet FTR a DET - S použitím matice složitosti spočtěte váhy EI, EO, EQ, ILF, EIF (nízká, průměrná, vysoká). - Spočtěte Počet neupravených funkčních bodů. - Určete hodnoty 14 charakteristik systému. - Sečtěte hodnoty charakteristik -- určíte tak Faktor technické složitosti (FTS) systému. - Určete Počet upravených FP systému. FP=(0.65 + (0.01*FTS))*(UFP) ====== Předměty ====== * [[https://is.muni.cz/auth/predmet/fi/podzim2011/PA102|PA102 Technologie informačních systémů I]] * [[https://is.muni.cz/auth/predmet/fi/jaro2011/PA105|PA105 Technologie informačních systémů II]] * [[https://is.muni.cz/auth/predmet/fi/podzim2011/PB007|PB007 Analýza a návrh systémů]] * [[https://is.muni.cz/auth/predmet/fi/jaro2011/PA103|PA103 Objektové metody návrhu informačních systémů]] * [[https://is.muni.cz/auth/predmet/fi/jaro2011/PA104|PA104 Vedení týmového projektu]] ====== Použitá literatura ====== - Král, Jaroslav. 1998. Informacní systémy : specifikace, realizace, provoz. Veletiny: Science. ISBN: 80-86083-00-4. - Král, Jaroslav. 2008. PA102 Technologie informačních systémů I (přednášky). FI MU, Brno. - Král, Jaroslav. 2009. PA105 Technologie informačních systémů II (přednášky). FI MU, Brno. - Ráček, Jaroslav. 2011a. PB007 Analýza a návrh systémů (přednášky). FI MU, Brno. Dostupné z [[http://is.muni.cz/el/1433/podzim2011/PB007/um/27384117/]] (Jan. 2012). - Ráček, Jaroslav. 2011b. PA104 Vedení týmového projektu (přednášky). FI MU, Brno. Dostupné z [[http://is.muni.cz/el/1433/jaro2011/PA104/um/22859873/]] (Jan. 2012). - Ošlejšek, Radek. 2011. PA103 Objektové metody návrhu informačních systémů (přednášky). FI MU, Brno. Dostupné z [[https://is.muni.cz/auth/el/1433/jaro2011/PA103/um/prez/]] (Jan. 2012). - Software Development Life Cycle (SDLC). Dostupné z [[https://docs.google.com/viewer?a=v&q=cache:bfhOl8jp1S8J:condor.depaul.edu/~jpetlick/extra/394/Session2.ppt+&hl=en&pid=bl&srcid=ADGEEShCfW0_MLC4wRbczfUxrndHTkbwguF9fZuaUCe0RDyOCWyO2PTmaPhHnZ4jRhZZ75maVO_7gVAD2ex5-QIhrj1683hMefBNkak7FkQJCAwd-i0-_aQfEVEEKP177h4mmkvMMWJ7&sig=AHIEtbRhMlZ-TUyioKEhLQQxXk1WoSJXWA&pli=1|PowerPoint – Powered by Google Docs]] (Jan. 2012). - Horačková, Lenka. Vypracované otázky k IS. Dostupné z [[http://fi.muny.cz/vypracovane-otazky-statnice-is.zip-594/]] (Jan. 2012). - SZZ_Informacni_systemy_varianta_I.zip. FIMUNY. Dostupne z [[http://fi.muny.cz/szz-informacni-systemy-varianta-i.zip-1180/]] (Jan. 2012). ====== Přílohy ====== {{:mgr-szz:in-ins:1b.pdf|}} -- rozšíření některých témat a soukromé zpracování, vycházelo se z této wiki na přelomu roku 2013/2014. Nekonzultováno s kantory. ====== Vypracoval ====== Ľuboš Kohút, [[https://is.muni.cz/auth/osoba/172607]], 172607@mail.muni.cz Aktuální stav: hotovo Ospravedlňujem sa za moje prípadné preklepy a chyby v češtine. ~~DISCUSSION~~