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.

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.

• 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

Skládá se ze dvou částí:

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

• 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ů)

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

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

• Structured Analysis and System Specification
• DeMarco (1978) – připisováno prvenství při použití DFD
• shora-dolů
• Analýza pomocí 4 modelů

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

• Gane, Sarson (1979) – DFD + ERD

• View Point Analysis - VPA
• Mullery (1979)
• zdola-nahoru

• hierarchie entit není dosud vytvořena,
• hierarchie entit není na první pohled zřejmá,
• systém není přirozeně hierarchicky uspořádán

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ů

• 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

• 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

• Logické datové struktury - LDS
• Diagramy datových toků - DFD
• Životní cykly entit - ELH (Entity Life History)

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.

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

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

• 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í.

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

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

• zahrnuje všechny (obvykle statické) vlastnosti objektu plus současné (obvykle dynamické) hodnoty těchto vlastností

• vyjadřuje, jak objekt koná a reaguje, v pojmech změn stavu a předávání zpráv

• je množina objektů, které sdílejí společnou strukturu a shodné chování
• objekt je instancí třídy
• atributy –- reprezentují strukturu třídy

• 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

• 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

• 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

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)

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)

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

• 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

• 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

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

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

• 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

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í

• 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

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

• vztah mezi nadtřídou a podtřídami

• z pohledu stavového diagramu je to výskyt jevu, který může spustit přechod mezi stavy

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

• 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í)

• STD
• graf stavů a přechodů

• statické diagramy

• dynamické diagramy
• stavový diagram

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

• 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.).

• 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

• 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, …

• 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, …

• 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

• 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, …)

• 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

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

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í

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

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

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ů

• 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 – COnstructive COst MOdel

• existuje víc druhů COCOMO – COCOMO 81, COCOMO II

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

• 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í.

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

RELY – požadovaná spolehlivost
DATA – velikost databáze
CPLX – složitost produkt

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

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

MODP – použití moderních prg. technik
TOOL – použití SW nástrojů

: 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 závisí na (), ostatní parametry jsou konstantní.
  • korekční faktor je součinem hodnot 15 atributů specifických pro vývojový proces

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 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 vypočtou hodnoty odhadu podle vzorců

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

• 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

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

• Externí vstupy (EI - External Inputs)
• Externí výstupy (EO - External Outputs)
• Externí dotazy (EQ - External Enquiry)

• Vnitřní logické soubory (ILF - Internal Logical Files)
• Soubory vnějšího rozhraní (EIF - External Interface Files)

Před výpočtem musíme EI, EO, EQ, ILF, EIF roztřídit do skupin podle vah. Potom spočítame UFP

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ý

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.

• PA102 Technologie informačních systémů I
• PA105 Technologie informačních systémů II
• PB007 Analýza a návrh systémů
• PA103 Objektové metody návrhu informačních systémů
• PA104 Vedení týmového projektu

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).

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.

Ľ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.