Juraj Michalek (xmichal5@fi.muni.cz) Analyza a navrh systemov (Sochorove materialy) *** Softver vseobecne *** Softverove produkty -- genericke - vseobecne - moze kupit ktokolvek -- zakazkove - softver sa vyvija pre jedneho zakaznika Dobre rieseny softver -- udrzatelnost - softver je modifikovatelny podla potrieb zakaznika -- spolahlivost - ochrana a bezpecnost, vypadky nesmu sposobit skody -- efektivita - nie je plytvane prostriedkami (pamat) -- pouzitelnost - uzivatelske rozhranie a dokumentacia Kriticke faktory pri rieseni -- zlozitost - da sa charakterizovat atributmi programu -- velkost -- komunikacia - problem komunikovat pri velkych timoch -- casovy plan - prilis nasadeny casovy plan a ludia nestihaju -- softver nie je vidiet :) Vyrobny proces softveru -- zrozumitelnost - proces je pomenovany a da sa mu rozumiet -- viditelnost - procesne aktivity davaju viditelny vystup -- spolahlivost - proces je navrhnuty tak, ze chybe sa da vyhnut skor, ako zavini chybu vo vyrobku -- prijatelnost - proces je prijatelny pre vyrobu -- robustnost - proces dokaze precovat aj v pripade neocakavanych chyb -- udrzovatelnost - proces odraza meniace sa poziadavky -- rychlost - ako rychlo je mozne proces realizovat -- podporovatelnost - podpora nastrojov CASE *** Modely systemu *** Vyskumnik 1. vytvor system 2. implmentuj 3. pouzivaj 4. if(!system vyhovuje) goto 2 5. odovzdaj system Vodopad -- vzdy sa vracia iba o jednu uroven -- navrat o viac urovni je veeelmi drahy 1. definicia poziadavkov 2. navrh systemu a softveru 3. implemntacia a testovanie jednotiek 4. testovanie systemu 5. prevadzka a udrzba -- realne projekty vsak nedodrzuju kroky v presnom poradi -- uzivatel nedokaze na zaciatku vsetko sformulovat -- zakaznik musi byt trpezlivy 1. analyza poziadavkov - obrysove poziadavky 2. definicia poziadavkov - dokument poziadavkov 3. specifikacia systemu - funkcna specifikacia 4. navrh architektury - specifikacia architektury a plan testovania 5. navrh rozhrania - specifikacia rozhrania 6. podrobny navrh - specifikacia navrhu 7. kodovanie - kod programu 8. testovanie jednotiek - protokol o testovani 9. testovanie modulov - protokol o testovani modulov 10. integracne testovanie - protokol o integracii 11. testovanie systemu - protokol o teste 12. predanie systemu - konecna dokumentacia Obrysova specifikacia 1. vytvor obrysovu specifikaciu 2. implementuj system 3. pouzivaj ak nevyhovuje gogo 2 4. dodaj system -- vstah medzi skutocnostou a dokumentami je vsetcia vieme aky :)) -- proces nie je viditelny -- system je zle strukturovany -- vyzadovany su talentovani pracovnici Prototypovanie 1. vytvor obrysovu specifikaciu 2. vytvorenie <-> vyhodnotenie prototypu 3. specifikacia systemu 4. navrh a implementacia <-> vyhodnotenie systemu 5. predanie hotoveho systemu -- problem - po specifikacii sa zahadzuje prototyp Spiralovy model I. quadrant: x.1. rizikova analyza x.2. prototyp II. quadrant: x.0. testy a simulacie 1.1. koncept prace systemu 2.1. softverove poziadavky (implementacia) 2.2. validacia poziadavkov (testovanie) III. quadrant: x.1 plan (zivotneho cyklu, vyvoja, testovania( IV. quadrany: x. co bude riesene, alternativy, obmedzenia Lehmanovy zakony 1. system sa v realnom prostredi neustale meni, pokial nie je lacnejsie system restrukturalizovat alebo nahradit novou verziou 2. pri vyvoji je program coraz menej strukturovany a narasta jeho vnutorna zlozitost. Odstranenie narastajucej zlozitosti vyzaduje zvysene usilie 3. rychlost zmien globalnych atributov vyzera nahodne, ale pri dlhsom pozorovani je mozne vidiet samoregulaciu 4. rychlost vyvoja je priblizne konstantna a nekoreluje s vynalozenymi nakladmi 5. system urcuje pripuste vylepsenia v novych verziach. Ak je narast prilis velky dochadza k zavaznym problemom Timove programovanie LOC - lines of code E - effort (pracovne usilie - v mesiacoch) PP - produktivita programatora GPP - skupinova produktivita programatorov PP = LOC / E GPP = LOC/(E + faktor N^2) - zapocitava narocnost komunikacie GPP/PP = E/(E + faktor N^2) *** Specifikacia poziadavkov na SW *** 1. system rozumie vsetkym relevantnym podnetom 2. novy system musi mat funkcie stareho a nove vylepsenia Specifikacny dokument -- zavazny podklad pre navrh a realizaciu systemu 1. Uvod 1.1. Odkaz na system 1.2. Celkovy popis 1.3. Kladne obmedzenie produktu 2. Popis informacii 2.1. Popis informacnych tokov 2.1.1. Datove toky 2.1.2. Toky riadenia 2.2. Popis informacneho obsahu 2.3. Popis rozhrani systemu 3. Popis funkcii 3.1. Funkcne delenie 3.2. Popis funkcii 3.2.1. Strucny popis pore spracovanie 3.2.2. Zakazy a obmedzenia 3.2.3. Poziadavky na vykon 3.2.4. Navrhovane obmedzenia 3.2.5. Obrazky :)))) 3.3. Popis riadenia 3.3.1. Specifikacia riadenia 3.3.2. Navrhove obmedzenia 4. Popis chovania 4.1. Stavy systemu 4.2. Udalosti a akcie 5. Validacne kriteria 5.1. Hranice vykonnosti 5.2. Triedy testov 5.3. Ocakavana odozva SW 5.4. Specialne poziadavky 6. Literatura 7. Prilohy -- nie je mozne specifikovat vsetky detaily -- nie je mozne predpokladat dopad na existujuceho systemu -- problematicke su netestovatelne zelania (uzivatel je mrcha ;)) Modely specifikacie Zoznam funkcnych a nefunkcnych poziadavkov -- zoznam poziadavkov rozmiestnenych do skupin -- to je asi to najjednoduhsie Zoznam udalosti a reakcii -- vnutorne chovanie systemu -- zoznam (udalost x reakcia) Pozadovane vystupy -- uzivatelova predstava, co sa ma ako vypisovat -- lajstro sem, lajstro tam Procesny model -- sled transformacie udajov v systeme -- ako a kam sa hodi ktory bajt a co sa s nim zomelie Datovy model -- kazdy bitik treba popisat, aby sa nam nestratil Dokumenty pre cielove skupiny 1. Zoznam poziadavkov - normalna rec - pre uzivatelov 2. Specifikacia poziadavkov a funkcii - vyvojari a riadiaci prac. 3. Specifikacia SW - formalny popis pre navrh a implementaciu Zasady pre tvorbu dokumentu 1. Oddelit funkcionalitu od implementacie 2. Procesne orientovany popis. Matematicka specif. nestaci 3. System popisovat aj s kontextom 4. Musi zahrnut aj okolie, v ktorom bude system pracovat 5. Pojmy a pravidla musia byt zrejme 6. je to operacny dokument - da sa s nim validovat system 7. tolerantna voci rozsireniam a neuplnosti 8. kazda zmena musi ovplyvnit len cast dokumentu *** Funkcna dekompozicia a minispecifikacia *** Data Flow Diagram (DFD) -- modelovaci nastroj umoznujuci zobrazit system ako siet procesov, ktore plnia svoje funkcie a posielaju si medzi sebou data -- je to funkcne orientovany pohlad na system Zlozky DFD 1. proces 2. pamat 3. datovy tok 4. terminator (koncovy uzol) Proces -- cast systemu transformujuca vstupy na vystupy -- pomenovanie: fraza, veta - vyjadruje cinnost procesu Toky -- cesta pohybu dat -- pohyb dat / materialu -- divergujuci datovy tok - paket je zaslany naraz viacerim -- pomenovanie: vyjadruje podstatu transformacie, ktora sa s tokom udiala Pamat -- data v klude - nic sa nehybe :))) -- pomenovanie: meno v mnoznom cisle, oznacuju pakety v tokoch -- esencialna pamata - data medzi procesmi pracujucimi v roznom case -- pasivna cast systemu -- nedestruktivne citanie Implementacna pamat -- procesy mozu byt rieseny na roznych systemoch -- pripadne ich riesia rozny ludia a teda pamat je interface -- data su ulozene len z implementacnych dovodov Terminator -- externe entity (externisti :) -- rozhranie medzi systemom a svetom -- nie je mozne menit obsah terminatora -- medzi terminatormy by nemali byt priame komunikacne toky :-( Konzistencia DFD Overit: -- cierne diery - proces so vstupmi, ale bez vystupov -- biely trpaslici - procesy, ktore maju len vystupy -- neoznacene toky -- pamati len na citanie Pofiderne vztahy -- terminator -> terminator -- terminator -> pamat -- pamat -> terminator -- pamat -> pamat Viacurovnyovy DFD -- jedna uroven - 5-7 procesov -- pamat sa kresli az na urovni, kde je 1. krat pouzita Minispecifikacia -- popisuje logiku procesov -- konzultuje sa so zakaznikom DFD a minispecifikacia: -- pre kazy proces na najnizsej urovni jednu minispecifikaciu (to aby sme sa potom prilis necudovali, ze co to mame v systeme:) -- minis. popisuje pravidla transformacie dat procesom -- popisuje pravidla, ale nie implemntaciu -- do minispecifikacie sa NESMIE zaniest redundancia -- pravidla je vhodne zapisat do rozhodovacej tabulky -- alebo do stromu :)) (pripadne aj do palmy:) -- uvodne podmienky - ktore vstupy su k dispozicii -- zeverecne podmienky - vystupy a vstahy medzi hodnotami *** Modelovanie dat *** Datovy model -- nemenne atributy -- stabilny zaklad pre procesny model -- zachytava vztahy, ktore nie su v procesnych modeloch -- vztahy mesmu byt porusene pri transformacii Komponenty 1. entita -> entitna mnozina 2. vztah -> vztahova mnozina 3. atribut -> domena atributu Asociovana entita -- je vysledkom vztahu dvoch entit -- napr. kupna zmluva je asco. e. (zo zakaznika x zbozia) Nadtypova entita -- zdruzuje entity pribuzneho typu Tvorba ERD 1. pokec s uzivatelom a pochopenie, co to vlastne pouziva 2. priadnie entitnych mnozin 3. overenie entit (pouzije sa zoznam datovych elementov) 4. odstranenie redundantnych entit (napr. volne zavesena asocka.) Normalizacia dat - Codd 1. nevyskytuju sa opakujuce zaznamy poloziek 2. odstranenie funkcnej zavislosti -- problem: su problematicke akekolvek zlozitejsie upravy -- kazda neklucova polozka je plne funkcen zavisla na kazdom kazdom kandidatskom kluci 3. kazdy atribut je plne funkcne zavisla na kluci -- polozka je netranzitivne zavisla na kandidatskom kluci -- zmenu jedneho atributu je nutne spravit na vla miestach 4. podmienene zavislosti Vytvorenie ERD 1. odhadnuty ERD - z textu sa vyvodia entity a relacie 2. doplnenie atributov 3. normalizacia 3.1. zavislosti na kluci 3.2. opakovanie netit -> ako nova entita 4. vyhladanie funkcnych zavislosti 5. odstranenie opakujucich sa atributov *** Strukturovana analyza a navrh **** Ciele pouzitai strukturovanej analyzy -- projekt je rozcleneny na male casti -- male casti sa dobre definuju -- diagramy a modelovanie - rozumeju vsetcia :))) -- efektivne vyuzitie skusenych aj neskusenych Dekompozicia systemu -- funkcny pristup - system su funkcie prepojene datovymi tokmi -- datovy - hladaju sa struktury aplikacie - konceptualny model pre DB -- objektovy -- system su objekty, data su zapuzdrene Cielovo orientovany pristup 1. fyzicke poziadavky 2. odvodenie logickych vystupov 3. transformacie 4. odvodenie fyzickych vystupov 5. potrebne fyzicke vystupy Funkcna dekompozicia zhora dole -- funkcie su rozobrate podla urovni az na najmensie Logicke modelovanie 1. vytvorenie DFD 2. nacrt datoveho modelu 3. analyza entit a ich vztahov -> logicky datovy model 4. relacny datovy model, normalizacia 5. prekreslenie DFD -> logicky procesny model 6. dekompozicia na proceduralne jednotky 7. specifikacia detailov kazdej procesnej jednotky Pohladova analyza 1. identifikacia pozorovacich bodov -- pohlady sa nesmu prekryvat -- funkcia je vyrisena vramci jedneho pohladu -- kazdy pohlad popisuje spracovanie informacie 2. zdruzenie pohladov do skupin, podla problemov -- hranicny pohlad - pohlad z okolia systemu -- definicny pohlad - lokalizovane spracovanie informacie 3. urcenie struktury pohladov -- usporiadanie pohladov podla ich atributov Data structure system development fyzicke vstupy fyzicke vystupy transformacia vstupne logicky transformacia logickych vystupov proces editovania log. vstupov transf. na log. vystupy proces zmeny dat ->baza->proces log. vyberu Nevyhody pristupu -- pri tvorbe fyzickeho modelu povodneho systemu ma uzivatel pocit, ze analytik sa uci jeho system za jeho peniaze -- ak analytik nevytvoril dobre fyzicky model, nevytvori dobre ani logicky model -- pri analyza sa programatori flakaju *** Strukturovana analyza - Yourdon *** -- vyuziva esencialny model - je dlhodobo stabilny 1. analyzauj system - na ake udalosti reaguje 2. vytvor esencialny model 3. vzhladom na novetechnologie navrhni novu implementaciu Hranice medzi okolim a systemom 1. rozhranie - system s okolim 2. vnutorna cast - model chovania -- hranica je nahodna (musi ju urcit analytik) Definicia okolia 1. ucel systemu - strucny text s popisom o co pojde (pre manazarov) 2. kontextovy diagram - obsahuje jediny proces reprezentujuci cely system Kontextovy diagram (DFD): -- terminatory - ludia a systemy z okolia, s ktorymi komunikuje -- prijimane data -- produkovane data -- datove pamati - zdielane medzi systemom a terminatorom -- hranice - medzi systemom a svetom 3. zoznam udalosti - textovy zoznam na ktore system musi odpovedat Zoznam udalosti -- kazda udalost ma priznak: -- F Flow - tokova udalost -- T Temporal - casova udalost -- C Control - riadiaca udalost, signal Model okolia -- nie je presne jasny rozsah systemu (a to je problem;) -- uzivatelia maju prevazne lokalne znalosti -- niektore interakcie su pri analyza zabudnute Dialogove toky -- nezanasaju sa implementacne detaily -- povely su vseobecne a nejedna sa o dialog Chybove situacie -- su zanesene do zoznamu udalosti -- len zoznam chyb na strane terminatorov Mozne postupy 1. kontextovy diagram -> zoznam udalosti 2. ERD -> zoznam udalosti -> kontextovy diag. Dokoncenie modelu -- overenie: -- vstupnych tokov - kontext -- vystupnych tokov a odozvy na udalost -- kazda necasova udalost by mala mat vstup -- kazda udalost produkuje okamzity vystup, alebo je ulozena Model chovania systemu -- pre kazdu udalost zakreslime jeden proces -- proces je pomenovany podla ocakavanej odozvy -- vlozime datove pamati nutne pre asynchronne spracovanie dat -- doplnime prislusne IO toky -- taketo DFD overime voci kontextovemu diag. -- prvotny model sa nekonzultuje s uzivatelom! -- nie je usporiadany, tak aby ho userik pochopil Vyvazenie - smerom nahor -- spajame vzajomne suvisiace procesy 1. zoskupenie zahrna blizke procesy 2. pamati sa zakryvaju, pokial ich pouziva skupina na nizsej urovni Vyvazenie - smerom nadol -- funkcna dekompoziacia -- pri procesoch s komplikovanou funkciou su zrejme dalsie podfunkcie -- vyjadria sa ako procesy na nizsej urovni -- pri inych procesoch nie su jasne dalsie podfunkcie -- pokusime sa ich odvodit zo vstupov Dokoncenie modelu chovania -- dokoncenie ERD a datoveho modelu: -- prvotny ERD -- priradenie atributov entitam -- identifikacia novych/prebytocnych entit -- krizova kontrola proti DFD -- dokoncenie stavoveho modelu: -- definicia moznych stavov -- dosiahnutelnost stavov -- cesta z nekoncovych stavov -- reakcie na vsetky mozne podmienky v kazdom stave Model chovania 1. kontextovy diagram 2. zoznam udalosti 3. uplna sada vyvazenych diagramov datovych tokov 4. uplna sada dokoncenych ERD diagramov 5. uplna sada dokoncenych stavovych diagramov 6. uplny datovy slovnik 7. uplna sada procesnych specifikacii -- dokonoala technologia -> ziadne implementacne obmedzenia zo strany uzivatela Automatizovanie -- volba casti systemu, fungujucich automaticky -- volab casti pozadujucich manualny vstup Dokoncenie uzivatelskeho implementacneho modelu -- urcenie uzivatelskeho rozhrania -- odporucania pre navrh rozhrania -- navrh formularov -- identifikacia manualnych podpornych aktivit -- opatrenia pre chybove technologie -- specifikacia operacnych obmedzeni Odporucania pre navrh rozhrani -- I a O su riesene konzistentne -- informacie su pozadovane v logickom poradi -- z hlasenia o chybe musi byt jasne o aku chybu ide :-)))))) (tento bodik by si mal dat M$ ako moto:))))) -- rozlisit medzi editaciou pola a formulara -- opravy a kontrola chyb by mali zavisiet na uzivateloch -- uzivatel moze rusit cast transakcie, alebo celu -- pohodlny mechanizmus pomoci -- volbu medzi menu/comand line riadenim nechat na uzivatelovi!!! (toto by si tiez M$ mohol zobrat ako moto, ale to uz by ich male vela) :))) -- pri dlhodobych cinnostiach zobrazovat priebezne spravy -- poskytnut implicitne hodnoty na standartnych vstupoch -- farby a zvuk s mierou! Operacne obmedzenia -- objem dat -- pozadovane doby odozvy -- politicke obmedzenia - implemntacne volby -- obmedzenia dana okolim a vnutornym porostredim -- obmedzenia na spolahlivost -- bezpecnostne obmedzenia *** Objektove modely *** Strategie -- postup: 1. ucel a rysy 2. objekty 3. zodpovednosti 4. scenare -- rysy: 1. zaviest dolezite informacie 2. previest obchod 3. analyzovat vysledky 4. spolupracovat s inymi systemami -- objekty: 1. vyber objektov (ludia a organizacie) 2. role (nie su druhy ludi) 3. vyber miesta (kam veci prichadzaju a kde su) 4. vyber transakcii 5. vyber specifickych poloziek -- zodpovednost: 1. atributy vybrane z realneho sveta 2. obvykle atributy (cas, meno...) 3. prepojenie objektov, ktore sa poznaju 4. niekolko krat sa spytat preco je objekt potrebny 5. objekt prevadza sam bezne operacie -- scenar: 1. scenar zolozeny na rysoch 2. interakcie v problemovej domene 3. spustenie scenara (test, ako by sa system choval) -- umoznuje najst dalsie objekty -- zpresni priradenie objektov -- ujasni dynamiku systemu -- testuje model Klucove scenare 1. zacni v problemovej domene - interakcia s ludmi 2. kazdy objekt plni len a len svoju pracu 3. dvojpreichodove overenie: 3.1. scenar zalozeny len na objektoch 3.2. pre kazdu sluzbu zviaz dalsie sluzby 4. popis scenara pomocou pohadu 5. objekt vie co je zac a nemusi to zistovat 6. bez dokoladneho zvazenia neposielaj viac nez hodnotu 7. vyhladaj a spolupracuj 8. ak objekt nieco rozpozna, spusti cinnosti (znizuje zapuzdrenie) 9. preberaj hodnoty len ak ich potrebujes 10. nadbytocnu pracu vyber zo slucky 11. konzistentne scenare (kazdy objekt musi poznat komu ma spravu poslat) 12. obmedz interakcie kde je velke mnozstvo sprav 13. redukuj kaskadove spravy 14. vykonaj zdvojene a nasobne spravy 15. vytvaranie a rusenie objektov 16. usporiadanie riadiacich objektov a objektov ziskavajucich data *** Objektovo orientovana analyza *** Abstrakcia -- ignorovanie aspektov, ktore nie su vyznamne pre model -- proceduralna - kazda operacie je jednoducha entita -- datova abstrakcie - hodnoty v objektoch su pozorovane a modifikovane operaciami Objekt -- stav -- spravanie -- identitu Role -- aktor - operuje s dalsimi objektami -- server - neoperuje s cudzimi objektami -- agent - vykonava operacie a dava prikazy na operacie dalsim Sluzby -- konstruktor -- prepojenie k inemu objektu -- ziskanie atribotov -- destruktor -- spracovanie atributov -- sledovanie systemov Definicia atributov -- identifikacia atributov -- umiestnenie atributov -- identifikacia vazieb medzi instanciami -- overenie zvlastnych pripadov -- specifikacia atributov Preverenie z pohladu objektu -- ako som popisany vseobecne -- ako som popisany v tejto problemovej oblasti -- ako som popisany v kontextu zodpovednosti systemu -- co potrebujem vediet -- aku stavovu informaciu si mam pamatat -- v akych stavoch sa mozem nachadzat Overenie zvlastnych pripadov -- aplikovatelnost atributu -- preverenie vazieb M:N -- vztahy medzi objektami jednej triedy -- preskumanie paralelnych vztahov -- najdenie chybajucich vztahov -- hladanie specialnych objektov - ma specialny vyznam *** UML *** -- Unified Modeling Language -- zobrazenie hranice systemu -> use case -- ilustrovanie use case pomocou diagramov -- reprezentacia systemu -- model spravania - stavovo-prechodove diagramy -- odhaluje implmentacnu architekturu -- rozsiruje funkcionalitu pomocou stereotypov Pripady pouzitia -- vzor pre spravanie systemu -- prieskum ucastnikov -> ziskame ich potreby Dokumenty -- pre kazdy pripad pouzitia sa vytvara vlastny dokument -- je formulovany z pohladu ucastnika -- zachytava detaily, ktore musi system poskytnut uzivatelovi -- Obsah: 1. ako pripad zacina a konci 2. normalny tok udalosti 3. alternativny tok udalosti 4. vynimocny tok udalosti Realizacia pripadov pouzitia -- predpoklada sa pohlad zvnutra -- interakcne diagramy popisuju, ako su pripady pouzitia realizovane -- diagram postupnosti (sequence) -- ukazuje postupnost interakcii -- diagram spoluprace (collaboration) -- ukazuje interakcie medzi objektami a prepojeniami Diagram tried -- existencia tried a ich vztahy Triedy -- chovanie tried je reprezentovane operaciami -- operacie su najdene po preskumani diagramu interakcii Atributy -- reprezentuju strukturu triedy -- ziskavaju sa preskumanim definicie triedy Vztahy -- poskytuju komunikaciu medzi objektami -- kto s kym potrebuje hovorit -- asociacia -- obojsmerne prepojenie medzi triedami -- agregacia -- vztah medzi celkom a jeho castami -- zavislost -- klient x poskytovatel -- klient nema semanticku znalost o poskytovatelovi -- najdene pri skumani diagramov interakcii Nasobnost a navigacia -- kolko objektov sa ucastni vztahu Dedicnost -- vztah medzi nadtriedov a jej podtriedami -- zovseobecnenie -- specializacia -- spolocne vztahy na najvyssej aplikovatelnej urovni Stav objektu -- zivotna historia danej triedy -- zabezpecuje dynamicke chovanie Fyzicky svet -- diagram komponent -- komponenta je kuscok, ktory sa zapoji do celku :) Nasadenie systemu -- diagram s konfiguraciou procesnych provkov Stereotyp -- definuju casto pouzivane vztahy -- hranica, entita, utilita *** Odhady a COCOMO *** Idea -- cena zavisi na veslkosti SW -- presnost odhadu zavisi na etape vyvoja -- constructive cost model (cocomo) -- SLOC - pocet riadkov kodu -- effort = E(KSLOC) -- time = T(KSLOC) - doba vyvoja -- data sa cerpaju z predchadzajucich projektov -- parametry su vsak specificke pre kazdu firmu Povodne COCOMO 1. zakldany model - odhad E a T z KSLOC 2. stredny model - vplyv dalsich faktorov 3. pokrocily model - zahranju sa aj etapy vyvoja projektu 1. organicky mod -- male projekty -- uplne porozumenie poziadavkom -- male obmedzenia a volnost pri navrhu -- velke skusenosti pri spracovani podobnych projektov -- mala zavislost na HW -- minimalna potreba novych architektur a algor. -- minimum poziadavkov na skratenie terminu 2. bezprostredny mod -- projekty strednej velkosti -- dobre pochopenie poziadavkov -- zretelne obmedzenia na rozhranie -- skusenosti pri inych projektoch -- stredna zavislost na hardveri -- stredna potreba novych alg. a arch. -- nutney signal na ukoncenie prac 3. viazany mod -- vsetky velkosti -- len hruba predstava o projekte -- skusenosti -- vysoka zavislost na HW -- extremne poziadavky na algoritmy -- vysoke podnety na dokoncovanie Vypocet: E = a * (KSLOC) ^ b T = c * E ^ d -- parametre je nutne volit podla projektu -- dalej sa zanasa korekcny faktor (15 atributov) Rozsirene modely -- Aplication Composition Model - projekty s pouzitim GUI -- Early Design Model - hrube odhady v zaciatkoch -- Post Architecture Model - odhady po specifikacii arch. Cenove faktory 1. Spolahlivost 2. Velkost databaz 3. KOmplexnost produktu 4. Obmedzenia na dobu vykonania 5. Obmedzenia hlavneho datoveho ulozista 6. Moznosti analytika 9. Skusenosti s aplikaciou 10. moznosti programtora 11. Skusenosti s virtualnym strojom 12. Skusenosti s programovacim jazykom 13. Pouzitie modernych programovych technologii 14. Pouzitie softverovych nastrojov 15. Planovanie *** Halsteadova teoria *** -- hodnotenie programov podla vyskytu symbolov 1. pocet opratorov v module 2. pocet operandov v module 3. pocet roznych operatorov 4. pocet (e)roznych operandov -- vyhodnotenim programu sa ziska tabulka Doplnujuce metriky -- objem proghramu - celkovy pocet rozhodnuti, ktory terba pri pisani progrmau spravit Putnamov zakon -- skrateny cas mozeme kompenzovat zvysenym pracovnym usilim -- cas je vsak podstatne vyznamnejsi nez pracovne usilie *** Zrnka mudrosti :) *** -- zlozitost aplikacie ma vacsi vliv na produktivitu nez volba programovacieho jazyka -- Brooks: pridanie riesitelskej kapacity u oneskoreneho projektu zvetsi jeho oneskorenie -- system obsahuje tolko podsystemov, kolko je analytikov