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

Upřesnení zdrojů:

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
  1. vytvoření modelu okolí systému
  2. vytvoření prvotního modelu chování systému
  3. dokončení esenciálního modelu
  4. 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
  1. Studie stávajícího fyzického systému
  2. Odvození logického ekvivalentu stávajícího systému
  3. Odvození nového logického systému
  4. Odvození nového fyzického systému
  5. Kvantifikace cen a termínů
  6. Výběr jedné z možností
  7. Začlenění nového fyzického modelu do specifikace

Logické modelování

  • Gane, Sarson (1979) – DFD + ERD

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
  1. identifikace pozorovacích bodů
  2. sdružení pohledů do skupin (funkční, nefunkční, hraniční, definiční pohledy)
  3. 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
  1. stávající systém je analyzován s cílem porozumět problémové oblasti nového systému.
  2. pohled na stávající systém je použit pro vytvoření specifikace požadavků systému.
  3. specifikace požadavků je zpracována detailně, takže je možné formulovat podrobné technické možnosti a alternativy.
  4. 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.
  5. je vytvořen návrh logických procesů (viz. předchozí etapa).
  6. logický návrh je převeden na fyzický návrh při aplikaci jednoduchých pravidel.

Objektová analýza a návrh, UML

Upřesnení zdrojů:

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í

  1. Aktor (aktivní objekt) –- může operovat s jinými objekty, ale sám není nikdy takto operován
  2. Server –- nikdy neoperuje s jinými objekty, a sám je operován jinými
  3. 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

  1. identifikace tříd a objektů (dědičnost)
  2. identifikace struktur („part-of” vztahů)
  3. definice subjektů
  4. definice atributů
  5. 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

  1. 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í)
  2. 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
  3. 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, …
  • 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)
  • 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

Upřesnení zdrojů:

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.

Příklad datového slovníku (DD) popisující datový tok objednávka zboží:

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 - Ž množství zboží = {0 - 9}

Notace DD:

  • = 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

Upřesnení zdrojů:

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

Upřesnení zdrojů:

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í: IRiDium CObalt

Odhady COCOMO a funkční body

Upřesnení zdrojů:

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
  1. určí se úroveň modelu a mód projektu
  2. určí se hodnocení vlivu faktorů reprezentovaných jednotlivými atributy (velmi nízký, nízký, normální, velký, velmi velký, extrémně velký)
  3. určí se číselné hodnocení atributů z tabulek
  4. určí se korekční faktor F_c jako součin takto získaných hodnot (střední a pokročilý model)
  5. 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

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

  1. 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
  2. S použitím matice složitosti spočtěte váhy EI, EO, EQ, ILF, EIF (nízká, průměrná, vysoká).
  3. Spočtěte Počet neupravených funkčních bodů.
  4. Určete hodnoty 14 charakteristik systému.
  5. Sečtěte hodnoty charakteristik – určíte tak Faktor technické složitosti (FTS) systému.
  6. Určete Počet upravených FP systému.

FP=(0.65 + (0.01*FTS))*(UFP)

Předměty

Použitá literatura

  1. Král, Jaroslav. 1998. Informacní systémy : specifikace, realizace, provoz. Veletiny: Science. ISBN: 80-86083-00-4.
  2. Král, Jaroslav. 2008. PA102 Technologie informačních systémů I (přednášky). FI MU, Brno.
  3. Král, Jaroslav. 2009. PA105 Technologie informačních systémů II (přednášky). FI MU, Brno.
  4. 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).
  5. 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).
  6. 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).
  7. Software Development Life Cycle (SDLC). Dostupné z PowerPoint – Powered by Google Docs (Jan. 2012).
  8. Horačková, Lenka. Vypracované otázky k IS. Dostupné z http://fi.muny.cz/vypracovane-otazky-statnice-is.zip-594/ (Jan. 2012).
  9. SZZ_Informacni_systemy_varianta_I.zip. FIMUNY. Dostupne z http://fi.muny.cz/szz-informacni-systemy-varianta-i.zip-1180/ (Jan. 2012).

Přílohy

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.

Diskuze

, 2012/02/03 17:27

Doplnil som ešte časť Diagramy v UML

, 2012/02/05 18:13

kdyz uz jsme u toho UML, tak bych mozna dodal k jednotlivejm diagramum i priklad (obrazek), jak vypadaji. Ale to jen pokud by se nekomu vylozene chtelo :)

You could leave a comment if you were logged in.
mgr-szz/in-ins/1.2-ins.txt · Poslední úprava: 2020/04/12 16:56 (upraveno mimo DokuWiki)
Nahoru
CC Attribution-Noncommercial-Share Alike 4.0 International
chimeric.de = chi`s home Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0