IUS Past Paper - Introduction to Software Engineering PDF

Introduction to Software Engineering (IUS) 1. Čo je softvérové inžinierstvo? Systematický prístup k vývoju, nasadeniu a údržbe SW Inžinierska disciplína zaoberajúca sa praktickými problémami vývoja rozsiahlych SW systémov 1.1 Prečo vytvárame softvér? Zlepšenie služieb...

Introduction to Software Engineering (IUS) 1. Čo je softvérové inžinierstvo? Systematický prístup k vývoju, nasadeniu a údržbe SW Inžinierska disciplína zaoberajúca sa praktickými problémami vývoja rozsiahlych SW systémov 1.1 Prečo vytvárame softvér? Zlepšenie služieb (informačné systémy..) Znižovanie nákladov (riadenie výroby..) Nemožnosť riešenia bez použitia počítačov (predpoveď počasia..) je nutné zlepšovať vlastnosti SW, hlavne spoľahlivosť, bezpečnosť a použiteľnosť, potreba zvyšovať produktivitu vývoja SW 2. Popis softvérovú krízu z 60. rokov. Prejavovala sa a stále sa prejavuje neúnosným predlžovaním a predražovaním projektov, nízkou kvalitou výsledných produktov, problematickou údržbou a nízkou produktivitou prace programátorov Hľadanie riešenia týchto problémov viedlo k zavedeniu (Prvý krok k metodickému přístupu programování -) štruktúrovaného programovania 3. Čo je softvérový produkt? Zbierka počítačových programov, procedúr, pravidiel a s nimi spojená dokumentácia Členovia jednej komunity (programátori) vytvárajú SW(výrobok) pre inú skupinu ľudí (zákazníci). SW produkt nie je len samotný program ale aj požiadavky, špecifikácie, popisy návrhu, zdrojové texty, testovacie dáta, príručky, manuály Aktéri vo vývoji SW produktu – zákazník (sponzor, špecifikuje požiadavky na SW), dodávateľ (vyvíja systém, komunikuje s užívateľom), užívateľ (testuje, používa systém) 4. Generický a zákaznícky SW. Genericky(krabicový) SW: predáva sa ľubovoľnému záujemcovi, musí sa dobre otestovať pred predajom, dodatočné opravy sú náročné Zákaznícky SW: šitý na mieru konkrétnemu zákazníkovi, cena je vyššia, typické pre systémy riadenia výroby, tvorba SW v SW firme 5. Kvalita softvérového produktu. Je to súhrn vlastnosti a charakteristík výrobku, procesu alebo služby, ktorý ukazuje jeho schopnosť plniť určené alebo odvodene potreby Nie je definovaná ako absolútna miera ale ako stupeň splnenia požiadaviek a potrieb (miera stupňa dokonalosti) 6. Správnosť SW Do akej miery SW vyhovuje špecifikácii 7. Spoľahlivosť SW Pravdepodobnosť, že SW bude v danom čaše vykonávať zamýšľanú funkciu 8. Efektívnosť SW Splnenie kritérií na využitie zdrojov počítačového systému, na čas potrebný na realizáciu a ďalších kritérií (náklady) 9. Použiteľnosť SW Úsilie vynaložené na to , aby sa dal SW používať 10. Bezpečnosť SW Miera odolnosti voči neoprávneným zásahom do systému 11. Prenositeľnosť SW Aké veľké úsilie je potrebné pre prenos na inú platformu 12. Znovupoužitelnosť SW Do akej miery je možné znovu použiť jednotlivé časti SW 13. Interoperabilita SW Úsilie potrebné na zaistenie spolupráce s inými systémami 14. Udržovateľnosť SW Schopnosť SW reagovať na meniace sa potreby zákazníka alebo zmeny legislatívy 15. Testovateľnosť SW Úsilie nutne na testovanie vlastnosti SW 16. Dokumentovanosť SW Miera, do akej sú všetky rozhodnutia pri vývoji SW zdokumentované a kontinuita dokumentácie 17. Popis problémy pri vývoji SW Zložitosť - nie je možné pochopiť všetky možné stavy systému a dôsledky úprav, žiadne dve časti nie sú rovnaké, zložitosť je zdrojom ďalších problémov (komunikácia v tíme..) Prispôsobivosť – pri zmene by sa mal zmeniť SW nie naopak Nestálosť – pribúdajúce požiadavky, zmena SW v závislosti od okolia Neviditeľnosť – nie sme schopní určiť, čo chýba v reprezentácii SW výrobku Menej časté problémy: o práca v tíme o nízka znovupoužiteľnosť pri tvorbe SW o problém miery o tvorba dokumentácie – problematická udržovateľná aktuálnosť o náchylnosť SW k chybám – veľa sa prejaví pri chode, nie pri vývoji SW o spôsob starnutia SW Syndróm 90% hotovo - pri posudzovaní hotovej časti sa vychádza z odpracovaného podľa plánu a nie podľa skutočne hotového Špecifikácia Náchylnosť SW k chybám - niektoré sa prejavia až počas prevádzky a nie počas vývoja Práča v tíme - komunikačné problémy Dokumentácia - u veľkých projektov náročné na udržanie aktuálnosti Starnutie SW - postupne pridávanie nových funkcii a časte opravy vedú k degradácii systému Syndróm 2. systému - autor ma úspešný 1. produkt , snaží sa vytvoriť druhy dokonalý - ten je často príliš zložitý a nepochopiteľný a neefektívny 18. Krivka starnutia SW 19. Čo je softvérový proces? Definuje kto ma kedy čo robiť, aby boli splnene požiadavky 20. Popis proces vývoja SW Analýza a špecifikácia požiadaviek (8%) : zákazníkove požiadavky sú zapísané do štruktúrovanej podoby, pozornosť je venovaná samotným požiadavkám, nie ich realizácii, do tejto etapy patri aj štúdia vhodnosti a analýza rizík, CIEĽ: stanovenie služieb, ktoré zákazník požaduje od systému a určenie podmienok jeho vývoja a prevádzky Architektonicky návrh (7%): ujasnenie koncepcie systému, dekompozícia, plánuje sa akceptačné testovanie a nasadenie do prevádzky , školenia užívateľov Podrobný návrh: podrobná špecifikácia súčasti systému, vyber algoritmov, stanovenie štruktúry dát, ošetrovanie chýb, špecifikujú sa požiadavky na ľudské zdroje, odhaduje sa doba trvania a náklady na projekt. Plánuje na návrh testu súčasti vrátané testovacích dát Implementácia a testovanie súčasti (12%): programová realizácia, vypracovanie dokumentácie, otestovanie súčastí Integrácia a testovanie systému (6%) : spojenie súčastí do jedného celku, otestovanie celého systému, oprava chyb, ktoré sa predtým neobjavili Akceptačné testovanie a inštalácia: otestovanie zákazníkom/užívateľom, skolenie užívateľov po akceptácii Prevádzka a údržba (67%) : zabezpečenie prevádzky SW, priebežné riešenie ďalších problémov, ktoré sa predtým neprejavili, opravy, rozširovanie a prispôsobovanie SW 21. Popis vodopádový/ lineárny model základný model, etapy lineárne za sebou (od prvej etapy po poslednú) možnosť návratu k predošlej etape, neodpovedá vývoju reálnych projektov výhody: jednoduchý na riadenie, ak sú požiadavky nemenné tak je ideálny nevýhody: zákazník nie je nikdy schopný vopred stanoviť presné požiadavky, pri zmenách sa dlho realizujú, zákazník vidí spustiteľnú verziu až v neskorších etapách vývoja - príliš neskoro na odhalenie nedostatkov 22. Popis V-model Je to varianta vodopadového modelu s väčším dôrazom na testovanie V symbolizuje grafické usporiadanie etáp, V ako verifikácia a validácia, ľavá časť – vývojové aktivity, plánovanie testov, pravá časť – testovanie podľa plánu 23. Popis W-model Vychádza z V modelu Aktivity spojené s testovaním sú na rovnakej úrovni ako návrhové aktivity (druhé súbežné V), ľavá strana – overovanie, plánovanie a návrh testov, pravá strana – testovanie, zmeny kódu, regresívne testovanie 24. Popis iteratívny model proces vývoja je rozdelení do iterácii, jednotlivé iterácie sú vlastne vodopády, po každej iterácii má užívateľ k dispozícii neúplnú verziu na otestovanie výhody - zákazník ma možnosť validovať výsledok nevýhody - náročnejší na riadenie, potenciálne horšia výsledná štruktúra 25. Popis prototypovanie nie je to ucelený model, je súčasťou iných systémov prototyp: čiastočná implementácia produktu, prezentuje vonkajšie rozhranie(validácia), ďalej sa nepoužíva 26. Popis inkrementálny model Kombinácia lineárneho a iteratívneho modelu, na základe celkovej špecifikácie sa stanovia ucelené časti systému Môže to byt buď séria vodopádov pre každú súčasť systému , alebo napríklad špecifikácia a návrh vodopádom a nasleduje iteratívny prístup kombinovaný s prototypovaním... Výhody - Jednoduché zavedenie zmien počas vývoja Nevýhody - vývoj po častiach môže viest k strate vnímania logiky celku 27. Popis špirálový model Kombinácia prototypovania a analýzy rizík Jednotlivé etapy sa neustále opakujú, vždy na vyššom stupni Medzníky (Milestones) – prevzaté metodikou RUP o Life Cycle Objectives – vyhodnotenie cieľa projektu, stanovené požiadavky, cena, plán, priority, identifikované riziká o Life Cycle Architecture – vyhodnotenie architektúry, riešenie rizík, požiadavky a architektúra sú stabilné o Initial Operation Capability – systém pripravený na distribúciu, stabilná verzia pre zákazníka Výhody - vhodný pre zložité projekty, nezávislý na metodológii, chyby a nevyhovujúce postupy sú hneď odhalené Nevýhody - analýza rizík musí byť na vysokej úrovni, problematické plánovanie termínov a cien, vyžaduje neustálu spoluprácu so zákazníkom, SW je k dispozícii až po poslednom cykle Analýza rizík: cieľom je odhaliť možné ohrozenia projektu(odchod ľudí, zníženie rozpočtu, zlyhanie HW, nezáujem o produkt) a pripraviť na ne reakcie 28. Popis Metodika RAD - Rapid Application Development James Martin, RAD 1991 rýchly iteratívny vývoj prototypov funkčné verzie sú k dispozícii oveľa skôr ako u ostatných modelov intenzívne zapojenie zákazníka do vývoja - rýchle reakcie na zmeny Fázy: Plánovanie, Návrh, Prevedenie, Uzavretie a nasadenie Výhody – flexibilita, možná rýchla zmena na požiadavku zákazníka, úspora čašu a zdrojov - môže to viest k nižšej kvalite) Nevýhody – nutnosť spolupráce so zákazníkom, nižšia kvalita návrhu, problém s udržovateľnosťou 29. Popis RUP - Rational Unified Process objektovo orientovaná metodika venuje sa všetkým etapám vývoja SW (kto , čo , kedy, ako...) základne praktiky: - využívanie existujúcich komponentov - iteratívny vývoj - model je vizualizovaný - UML - priebežná kontrola kvality - sprava požiadaviek zákazníka - riadenie zmien systému výhody: vhodný pre veľkú škálu projektov, včasné odhalenie rizík, správa zmien, prepracovanie do detailov, UML nevýhody: u menších projektov neefektívny vývoj, komerčný(veľa podporných produktov) 4 fázy: - inception/zahájenie - rozsah, náklady, riziká, prvý UC,1-2 iterácie - elaboration/projektovanie - plánovanie, špecifikácia požiadaviek, architektúra, analýza rizík, 2-4 iterácie - construction/realizácia - analýza, návrh, implementácia, 2-4 iterácie - transition/ dodanie – dodanie, školenie, podpora pri zavedení, 2 iterácie(beta, plná verzia) 30. Čo je to abstrakcia? Zjednodušený pohľad na systém bez straty jeho významu 31. Čo je to zapuzdrenie? Súvisiace dáta, operácie a atribúty zoskupené do jednej jednotky za účelom zakrytia implementačných detailov 32. Čo je to dedičnosť? Definuje objekty a triedy na základe už existujúcich objektov, vzniká hierarchia 33. Čo je polymorfizmus? Znalosť triedy/objektu ako vykonať určitú operáciu, ktorá ale môže byť spoločná pre viac tried 34. Popis problémy pri špecifikácii požiadaviek Prirodzená neúplnosť a nepresnosť požiadaviek zákazníkom, nepresná formulácia Nedostatok znalostí analytika (neznalosť analyzovanej oblasti, terminológie), zákazníka (neznalosť vývoja SW, terminológie) Nekonzistentné požiadavky – rôzni užívatelia – rôzne požiadavky (aj medzi zákazníkom a užívateľom) Ďalšie problémy – problémy s testovaním a validáciou požiadaviek Vyradenie - v dobe špecifikácie je nejaká entita implicitná, ale s odstupom čašu sa môže vytratiť Deformácia - získaná informácia môže zavádzať Zobecnenie - veta je príliš všeobecná , preto je nepravdivá 35. Popis diagram tried (CLASS DIAGRAM) Zobrazuje triedy a statické vzťahy medzi nimi Okrem tried obsahuje rozhrania, zoskupenia a vzťahy (zobecnenie, asociácia, závislosť, realizácia) Je často používaný na modelovanie a návrh systému 36. Popis diagram objektov (OBJECT DIAGRAM) Zobrazuje objekty ako inštancie tried a ich vzťahy Sú úzko spojené s diagramami tried Popisuje statickú štruktúru systému v špecifickom čase Využívajú sa na testovanie presnosti diagramu tried Medzi objektmi existuje spojenie 37. Popis diagram zoskupení (PACKAGE DIAGRAM) Ukazuje zoskupenia príbuzných elementov systému a závislosti medzi nimi Je užitočný na usporiadanie rozsiahlych systémov 38. Popis diagram prípadov použitia (USE CASE DIAGRAM) Vytvára sa s pomocou užívateľov na zistenie funkčných požiadaviek na systém, hranice a rozsah systému Predstavuje súbor prípadov použitia (funkcia vykonávaná aktérom), aktérov (pracuje so systémom), vzájomných vzťahov, interakcií Každý prípad použitia popisuje postupnosť udalostí, má vstupné podmienky, tok udalostí a následné podmienky 39. Popis stavový diagram (STATE DIAGRAM) Modelovanie dynamického chovania a zmien( stavy objektov, prechody medzi stavmi, počiatočný a koncový bod stavových zmien) Zachycuje stav jediného objektu Využíva sa na ujasnenie životného cyklu objektu Je nutnosťou pre vývoj systému 40. Popis diagram aktivít (ACTIVITY DIAGRAM) Zvláštny prípad stavového diagramu, stavy predstavujú aktivity a prechody sú vyvolané dokončením aktivít Reprezentujú objektovo orientované vývojové diagramy Vhodný pre pochopenie toku činnosti (scenár prípadu použitia, detail operácie, algoritmu, obchodný proces) Je navrhnutý ako zjednodušený pohľad na dianie v priebehu procesu Podpora paralelného chovania - viacvláknové programovanie Nie je vhodný pre reprezentovanie zložitého vetvenia a popis chovania objektu v priebehu jeho života 41. Popis sekvenčný diagram (SEQUENCE DIAGRAM) Identifikuje základnú vnútornú dynamiku Popisuje spoluprácu skupiny objektov Ukazuje ako objekty medzi sebou komunikujú v časovej rovine Nie sú vhodne na zobrazenie detailu algoritmu Skladá sa z objektov a sprav 42. Popis diagram komunikácie (COMMUNICATION DIAGRAM) Ukazuje účastníkov interakcie a dátové spojenia medzi nimi Vhodnejší pre zobrazenie spojení ako sekvenčný Sekvenčný je vhodnejší pri zobrazení sekvencie volaní 43. Popis implementáciu zhora-nadol a zdola-nahor Zhora-nadol: najprv sa vytvoria moduly na najvyššej úrovni a postupne moduly nižších vrstiev, systém je možné skôr testovať ako celok a vážne chyby sú včas odstránené, nevýhoda je že je potrebné simulovať podsystémy, ktoré ešte nie sú vytvorené, testovanie logiky systému je náročnejšie ako testovanie jednotlivých modulov Zdola-nahor: najprv najnižšie moduly, odladia sa a využívajú sa na tvorbu na vyššej úrovni, nevýhoda je že chyby sa prejavia neskôr – v etape integračného testovania, testovanie modulov jednotlivo je jednoduchšie ako celej logiky systému 44. Aký je rozdiel medzi validáciou a verifikáciou? Validácia - overenie, že SW splňuje potreby užívateľa Verifikácia - overenie, že SW vyhovuje špecifikácii 45. Popis ciele a priebeh testovania Cieľom testovania je odhaliť chyby behom vývoja SW Test, ktorý neodhalí nesprávne chovanie SW je neúspešný Sú navrhnuté testovacie vstupy(dvojica vstupné a očakávané výstupné dáta) Vstupné dáta sú zadane a zaznamenane výstupné dáta Výstupné dáta sa porovnajú s očakávanými Testovacie vstupy vyberáme také, u ktorých sa dá očakávať, že spôsobia chybu. 46. Popis metódu testovania čiernej a bielej skrinky. Biela skrinka - zameriava sa na vnútornú logiku a štruktúru systému, predpokladá sa dôkladná znalosť implementácie systému Čierna skrinka - test vychádza zo špecifikácie bez vedomosti o vnútornej štruktúre 47. Popis process-oriented prístup k modelovaniu Ľudia sú len zdroje, procesy musia fungovať aj keď sa zmení tím, musia fungovať za všetkých okolností Podstatná je rola (analytik, programátor, tester..), nie individualita Štandard pre komunikáciu je dokumentácia 48. Popis people-oriented prístup Ľudia nefungujú vždy rovnako, dôraz na individualitu Dôležitá je kvalita členov tímu, nie ich počet Dôležitá osobná komunikácia, podpora práce vývojového tímu 49. Popis Agilnej metodiky a Heavyweight metodiky Agilná Minimum byrokracie Doraz na komunikáciu v tíme Čo najrýchlejšie vyvinúť SW, čakať na spätnú väzbu od zákazníka Doraz na testovanie Adaptívny prístup, malé projekty a malé tímy, decentralizované riadenie, malý objem dokumentácie, people-oriented, kritérium: čas a zdroje, premenné kritérium: funkcionalita Rôzne metódy: extrémne programovanie, Crystal, Scrum... Heavyweight Prediktívny prístup, veľké projekty a veľké tímy, centralizované riadenie, veľký objem dokumentácie, process-oriented, kritérium: funkcionalita, premenné kritérium: čas a zdroje 50. Popis extrémne programovanie Komunikácia, testovanie, párové programovanie Doraz na spätnú väzbu - zákazník je člen tímu – vyhodnocuje dosiahnutú funkcionalitu Jednoduché veci je potrebné tvoriť jednoducho Uvoľňovať len malé zmeny postupne - ale často Testovanie je základ Proces vývoja – Skúmanie, Plánovanie, Iterácia, Produkcia, Údržba, Uzavretie 51. Metriky - výpočty LOC- počet riadkov kódu kLOC - kilo LOC spoľahlivosť – stredná doba medzi výpadkami systému MTBF = MTTF+MTTR dostupnosť - pravdepodobnosť, že program v danom čase funguje (MTTF/MTBF)*100 MTBF - mean time between failures(MTTR + MTTF) MTTR - mean time to recovery(počet jednotiek offline/počet úsekov offline) MTTF - mean time to failure(počet jednotiek online/počet úsekov online) 52. Čo je to vlastníctvo? Neobmedzené pravo na vec, vlastníctvo hmotných zdrojov je prirodzené pre ľudí, vlastníctvo nehmotných zdrojov je sporné – chýba im vzácnosť 53. Čo je to patent? Monopol na výrobok, službu, platí 20 rokov, je ho možné predať , súhlas na využitie sa dáva licenciou Aby bol patent uznaný ako vynález musí byť nový, výsledok vynález. činnosti, priemyslovo využiteľný Napr.: telefón, TV 54. Čo je to autorské pravo? Výsledok tvorivej činnosti autora vyjadrené v akejkoľvek vnímateľnej podobe, autor je fyzická osoba, ktorá dielo vytvorila Vzniká vytvorením diela, sú chránené 70 rokov po smrti autora 55. Čo je to ochranná známka? Slovné alebo obrazové označenie výrobku slovami, písmenami, číslami, farbou, kresbou Odlišuje výrobcu a propaguje, bráni tretím osobám používať rovnaké označenie (v ČR platí 10 rokov) Napr.: Microsoft Windows, Coca-Cola 56. Popis licencie Slúži k udeleniu práv na využívanie intelektuálneho vlastníctva Public - verejne bez obmedzenia Open-source - voľne dostupné kódy -GPL - general public -LGPL - lesser GPL - knižnice -GFDL - free documentation - dokumentácie -BSD - úplne voľne šírenie Softvérové licencie Proprietárne – privátne vlastnené a kontrolované, výrobca dodáva spustiteľnú aplikáciu, užívateľ nemá právo študovať či editovať zdrojový kód, o Napr.: SW s licenciou na jednom počítači, licenčné programy pre školy, serverové licencie, licencia viazaná na daného užívateľa Slobodný (Free SW, Open Source SW) – umožňuje spúšťať program za akýmkoľvek účelom, študovať a prispôsobovať program, vylepšovať ho o Tri smery licencií: copyleft – udeľuje práva k modifikácii za určitých podmienok, BSD-style – požaduje iba formálne atribúty modifikovaného SW, inak s ním môžeme nakladať volne, public domain – autor sa zrieka autorských práv 57. Popis metodiky vývoja SW Metodiky vývoja SW sa venujú aspektom, ktoré ovplyvňujú vývoj SW produktu (proces tvorby SW..) Metoda – postup pre dosiahnutie určitého cieľa Metodika – súhrn doporučených praktík a postupov Metodológia – náuka o metódach, ich tvorbe a použitia o Metodika vývoja SW = Software Development Methodology 58. Popis životný cyklus softvéru Rozdeľuje proces vývoja SW na obdobia (etapy) s daným cieľom Analýza a špecifikácia požiadaviek (8%) Architektonicky návrh a podrobný návrh (7%) Implementácia a testovanie súčasti (12%) Integrácia a testovanie systému (6%) Prevádzka a údržba (67%) 59. Popis Proces vývoja softvéru Proces, v ktorom: o sa potreby užívateľa transformujú na požiadavky na SW o požiadavky na SW sa trans. na návrh o návrh sa implementuje o implementácia sa testuje o produkt sa dodá užívateľovi 60. Popis dekompozícia problémov Rozdelenie (dekompozícia) zložitého problému na jednoduchšie Prináša: ľahšie zvládnuteľné systémy, pozornosť na jeden podsystém, vývoj podsystémov nezávisle od seba, veľké systémy sa bez dekompozície nedajú zvládnuť 61. Popis hlavné ciele SW inžinierstva Manažment projektu – riadenie životného cyklu projektu, efektivita práca – čas Techniky – analýzy, návrhu, programovania, testovania.. Vlastnosti SW inžiniera – základné znalosti, schopnosť aplikovať znalosti, schopnosť získavať nové znalosti 62. Popis analýzu a špecifikáciu požiadaviek Stakeholder – zainteresovaná strana v projekte = zákazník, užívateľ, analytik, návrhár, tester, manažér.. Je dôležité zapojiť nielen zákazníka, ale identifikovať všetkých stakeholders a zapojiť ich do projektu 63. Popíš Typy požiadaviek Obchodné – prečo zákazník potrebuje systém, obchodné ciele – úspora nákladov, úspora času Užívateľské – čo sa dá so systémom robiť, úlohy, ktoré vykonáva užívateľ Funkčné – čo musí byť vykonané, aby mohli byť vykonané úlohy (user req.) a tým splnené obchodné požiadavky (business req.), chovanie systému v rôznych podmienkach (NAPR: čo všetko treba zistiť pre zistenie dostupnosti lieku, chemikálie, čo všetko je treba zistiť pre rezerváciu knihy o užívateľovi apod.) Nefunkčné – vlastnosti a charakteristiky, ktoré musí systém splňovať a rešpektovať obmedzenia o požiadavky na prevádzku systému (statické – napr. počet užívateľov, dynamické – napr. čas odozvy..) o požiadavky na výsledný systém (poč. vybavenie – napr. HW náročnosť, program. vybavenie – napr. op. systém, vyvíjaný softvér – napr. efektívnosť, spoľahlivosť) o požiadavky na vývojový proces – dodržiavanie pravidiel, odovzdanie systému o požiadavky na rozhranie – SW - User, SW - HW o externé požiadavky – legislatíva (ochrana informácií..) Získavanie informácií – cieľ projektu, interview, užívateľské požiadavky Analýza – vhodnosť, modelovanie, prototypovanie Špecifikácia – transformácia informácií z analýzy do dokumentu Validácia – vyhodnocovanie požiadaviek, simulovanie, prototypovanie 64. Popíš Dobrú špecifikáciu požiadaviek Zoradená podľa dôležitosti – požiadavky podľa dátumu Sledovateľná – zmysel požiadavky je jasný Modifikovateľná – jednoduché úpravy a dopĺňanie požiadaviek Jednoznačná Úplná – obsahuje všetky dôležité požiadavky Konzistentná – požiadavka nie je v rozpore s inou požiadavkou Verifikovateľná – merateľnosť splnenia požiadaviek 65.Popíš Dátové modelovanie Mať v systéme všetky potrebné dáta Nemať v systéme žiadne nepotrebné dáta Vyjadriť vzťahy medzi dátami Popísať transformovanie dát v systéme Entita – objekt, rozlíšiteľný od iných objektov Entitná množina – množina entít rovnakého typu (zdieľajú atribúty) Atribút – vlastnosť entity, ktorá nás zaujíma o Prázdne (NULL), Jednohodnotové, Viachodnotové (telefón), Odvodené (datumNarodenia->vek) Vzťah – asociácia medzi entitami Vzťahová množina – množina vzťahov, ktoré zdieľajú vlastnosti 66. Popíš kardinalitu Maximálny počet vzťahov daného typu (vzťah. množina) v ktorých sa môže podieľať jedna entita (1..*, 0..*,..) 67. Popíš Data Flow Diagram (DFD) Diagram dátových tokov Technika pri štruktúrovanej analýze Je hierarchický model – ukazuje funkcie systému, toky medzi dátami, je doplnený minišpecifikáciami 68. Popíš Prístupy k analýze a návrhu Štruktúrovaný – systém chápaný ako komplex procesov, ktoré operujú nad dátami o Konceptuálny model – podstata systému, DFD o Logický model – implementácia konceptuálnej štruktúry o Fyzický model – fyzické usporiadanie dát (súbory..) Objektovo orientovaný – systém chápaný ako komplex vzájomne komunikujúcich objektov o objektovo orientované prostriedky (objekty, triedy, UML) a metodík (RUP) o vyššia stabilita navrhovaných prvkov o Objekt má rolu, identitu, má metódy, uchováva dáta, spracuje a odosiela správy 69. Popíš Vzťahy tried Dedičnosť – vzťah generalizácia medzi triedami, odvodená trieda zdieľa atribúty, chovanie, vzťahy, môže pridať atribúty, chovanie Asociácia – zachycuje vzťahy medzi triedami, asoc. má svoje násobnosti, názov, vyjadruje premenlivý vzťah medzi objektami o Agregácia – zoskupenie viacerých častí, zoskupený objekt môže existovať bez tvoriaceho objektu, konstitučný objekt môže byť súčasťou viacerých zoskupení Závislosť – vyjadruje vzťahy medzi objektmi, triedami Realizácia – vzťah medzi triedou a rozhraním 70. Popíš princípy orient. návrhu Single Responsibility Principle (SRP) – triedy by mali mať jedinú zodpovednosť, dôvod k zmene Open Closed Principle (OCP) – trieda by mala byt otvorená pre rozšírenie, uzavretá pre modifikácie Dependency Inversion Principle (DIP) – závislosť na abstraktnom, nie na konkrétnom, smer závislostí od konkr. k abstr. Acyclic Dependencies Principle (ADP) – závislosti nesmú tvoriť cykly Liskov Substitution Principle (LSP) – odvodené triedy by mali byt zameniteľné za bázové triedy (napr. kružnica – elipsa) Do not Repeat Yourself (DRY) – neopakujte rovnaký kód na rôznych miestach – vytvára všeobecnejšiu triedu 71. Popíš jazyk UML Unified Modelling Language Základný modelovací jazyk metodiky RUP Stavebné bloky UML: o Predmety – prvky (trieda, prípad použitia, stav) o Vzťahy – určujú vzájomnú súvislosť predmetov (závislosť, asoc, agre., komp., realiz.) o Diagramy – modely UML (use case diagram, diagram tried, diagram zoskupení, diagram objektov) o Ornamenty – obohacuje prvky (atribút, operácia) 72. Popíš Diagramy jazyka UML 2.0 Diagramy štruktúry o D Tried, D objektov, D zoskupení Diagramy chovania o D prípadu použitia, Stavový D, D aktivít Diagramy interakcie o Sekvenčný D, D komunikácie 73. Popíš jazyk OCL Object Constraint Language (OCL) Definuje obmedzenia, podmienky a pripomienky nad UML modelmi Formálny jazyk navrhnutý pre návrhárov Využitie: o špecifikácia podmienok pre vykonanie metód o špec. obmedzení, hodnôt atribútov, tried 74. Popíš Návrh architektúry Zameriava sa na organizáciu systému – identifikujú sa komponenty, vzťahy a ich komunikácia Vytvorený na začiatku vývoja SW v prvej iterácii Návrh je spojený so špecifikáciou požiadaviek 75. Popíš Architektonické vzory Abstraktný popis dobrých odskúšaných praktík Sú overené na rôznych systémoch Obsahujú informácie o vhodnosti použitia, slabé a silné stránky Napr.: Model-View-Controller, Vrstvená architektúra, Klient-Server 76. Popíš Model-View-Controller Oddeľuje prezentáciu a interakciu od systémových dát (oddeľuje model a pohľad na model) Používa sa na rôzne zobrazenie a interakcie pre jeden model Výhody: dáta môžu byť menené nezávisle od reprezentácie a naopak Nevýhody: ťažšie spracovanie pre jednoduché modely Model - spravuje dáta a stav aplikácie, informuje View o zmenách stavu View – zobrazuje model, vyžaduje zmeny modelu, posiela užívateľské činnosti Controlleru Controller – zaisťuje zmeny modelu na základe akcií užívateľa a zmeny View na základe zmeny modelu Napr.: webová aplikácia, M – databáza, V – dynamické stránky, formulár, C – http protokol, validácia dát 77. Popíš Vrstvenú architektúru Rozdelenie systému do vrstiev – každá vrstva má svoju funkcionalitu, nadradená vrstva používa služby nižšej vrstvy (najnižšia vrstva = jadro systému), elementy každej vrstvy môžeme modifikovať nezávisle Výhody: náhrada vrstvy za novú vrstvu, redundantné služby (autentifikácia..) Nevýhody: náročné oddelenie vrstiev, potreba priamej komunikácie vyššej a nižšej vrstvy, požiadavky na výkon aplikácie Podpora inkrementálneho vývoja – ľahšia úprava architektúry Napr.: knižničný systém riadiaci prístup k chráneným elektr.zdrojom 78. Popíš Architektúru Klient-Server Funkcionalita je rozdelená do služieb – každá služba je poskytovaná nezávislým serverom Klient je užívateľ služieb, pristupuje na servery Použitie: prístupnosť pre veľký počet klientov, replikácia serverov pri zaťažení systému Výhody: distribúcia serverov v sieti, služby sú dostupné pre všetkých klientov Nevýhody: náchylnejšia na útoky (typ denial of service), výkon aplikácie nevieme predpokladať, problémy so správou serverov (vlastník 1 organizácia) 79. Popíš Konceptuálne modely Doménový model – entity a pojmy problémovej domény (reprezentuje reálny systém (system-as-is) , vychádzajú z nej obch., uživ., funk., a nefunk. požiadavky) Model architektúry – dekompozícia systému, napr.: diagram tried Modely chovania – uživ., funk. požiadavky (málo aj nefunk.), napr.: use case diagram, stavový diagram Modely interakcie – interakcie elementov (objekty, aktéri) v use case diagrame, napr.: diagram komunikácie Dátový model – perzistentné dáta (stále dáta), napr.: ERD 80. Popíš Generácie programovacích jazykov Prvá generácia – programovanie priamo v binárnom kóde Druhá generácia – assemblery, symbolické vyjadrenie binárnych inštrukcií (1 k 1) Tretia generácia – procedurálne jazyky, jeden príkaz transformovaný do 5-10 inštrukcií v bin.kóde Štvrtá generácia – neprocedurálne jazyky (čo treba vykonať, nie ako), jeden príkaz preložený do 30-50 inštrukcií v bin. kóde, tzv. užívateľské programovanie napr. Microsoft Excel 81. Popíš Typovanie a jazyky Význam – určiť sémantický význam elementov (poznáme príslušné operácie) Staticky typované jazyky – typová kontrola počas kompilácie napr.: C++, Java Dynamicky typované jazyky – typová kontrola počas behu programu napr.: Smalltalk, Self, Python, Lisp Silno typované – silné obmedzenia na kombináciu typov, zabránenie kompilácii kvôli nekompatibilným typom, tzv. typovo bezpečné (type safe) Slabo typované – slabé obmedzenia na kombináciu typov (napr.: implicitné pretypovanie) 82. Popíš Prístupy statického overovania Formálne (Inspection) Neformálne (Walkthrough) Pozeranie cez rameno (Over-The-Shoulder) Párové programovanie (Pair Programming) Kúpacia kačka (Rubber Duck Debugging) 83. Popíš Code Review. 200-400 LOC na prehliadku, odhalenie až 15 chýb za hodinu Najefektívnejší spôsob odhaľovania chýb v kóde, zvyšuje čitateľnosť, údržbu kódu, zlepšuje schopnosti menej skúsených programátorov 84. Popíš Techniky testovania. Náhodné testovanie – náhodné testovacie vstupy Funkcionálne testovanie – vstupy a výstupy na základe špecifikácie, metóda čiernej skrinky (black box, functional, closed box) o zistenie či vstupné a výstupné dáta vyhovujú špecifikácii o neberieme do úvahy vnútornú štruktúru, logiku modulu o úplné funkcionálne testovanie je v praxi nemožné Štrukturálne testovanie – na základe vnút.štruktúry programu, metóda bielej skrinky (white box, open box) o vychádza z vnútornej štruktúry, testuje sa implementácia programu o pokrýva riadenie a údaje (dáta) – založené na tokoch riadenia a tokoch dát o mutačné testovanie – úmyselne zavedené chyby do programu Testovanie rozhraní – na základe rozhraniami medzi modulmi a špecifikáciou programu 85. Popíš Stratégie testovania Testovanie zdola-nahor – testovanie komponentov na nižšej úrovni, potom na vyššej úrovni Testovanie zhora-nadol – testovanie modulov najvyššej úrovne, potom submoduly Sendvičové testovanie – kombinácia zhora-nadol, zdola-nahor Jednofázové testovanie – testovanie modulov samostatne, potom sa naraz integrujú Testovanie pozorovaním – prototyp, technika programovania N-verzií 86. Popíš Statickú a Dynamickú analýzu Statická analýza – analýza programu bez spustenia, sústredí sa na časté programátorské chyby – syntaktické, neinicializácia premenných, delenie nulou, neoprávnený prístup do pamäti Dynamická analýza – analýza za behu testovaného programu, sústredí sa na nesprávnu prácu s pamäťou(Valgrind), uviaznutie (deadlock), časovo závislé chyby (race condition), hlási menej falošných chýb ako Statická an. 87. Popíš Akceptačné testovanie. Testovanie užívateľom na reálnych dátach, užívateľ rozhodne, či produkt splňuje zadanie, vzťahuje sa na zákaznícky softvér 88. Popíš Alfa a Beta testovanie. Alfa testovanie – tam kde sa vyvíja softvér, testovanie užívateľom (vývojári sledujú a evidujú chyby), známe prostredie Beta testovanie – testovanie užívateľom u seba, neznáme prostredie, výsledkom je správa užívateľa 89. Popíš IT Support. Distribution. IT podpora používa multivendor strategy (stratégiu viacerých predajcov) o skladá sa z vnútornej podpory o 3 hlavní dodávatelia – IBM, ATOS, HP o centrálny manažment spoľahlivosti, bezpečnosti, podpory aplikácií IT support sa skladá z IT Operations (operácie v danom prostredí s danou kvalitou a poplatkami, vybavovanie denných dotazov a otázok služieb, menšie upgrady) a IT Transitions (prechody na naplnenie požiadaviek pre funkcionalitu, veľké upgrady, vylepšenia, projekty) Úlohy pre IT Operations Dostupnosť služieb, ochrana údajov, zálohovanie, legálne procesy (archivácia), podpora užívateľom, finančné ciele Úlohy pre IT Transitions Vylepšiť na novšie verzie, zmeniť poskytovateľa SW, nové štandardy Zmeniť stratégiu spoločnosti, reorganizácia spoločnosti, riadiť sa legálnymi požiadavkami (práva, dane, správy) Virtualization Adv – flexibilita, lepšie využívanie zdrojov, pridelenie zdrojov je online, menej manuálnych činností v prípade HW modifikácie Disadv – prináša iný level komplexnosti, limit pripojenia – siete, vyššie požiadavky na stabilitu, licenčné limity pre aplikácie Cloud – špeciálny typ outsourcingu Public cloud – + flexibilita v pridelení zdrojov, + menej vlastnej snahy, - bezpečnosť, - poloha, - limitovaná záruka v prípade straty dát, -poplatky  Private cloud – +bezpečnosť nie je problém, - vyššie poplatky, -menšia flexibilita SLA (Service Level Agreement) Dojednaná dohoda medzi zákazníkom a poskytovateľom služieb o dostupnosti služieb a kvalite kvantifikovaným spôsobom. Väčšinou sa odkazuje na riešenie mimoriadnych udalostí, avšak môže zahŕňať kontinuitu podnikania, obnovu, riadenie výkonnosti, záruku, dostupnosť a ostatné parametre služieb. OLA (Operational Level Agreement) Dohoda medzi internými podpornými skupinami, odvodených od SLA. Typicky je prísnejší než SLA a odráža iný druh procesu (dostupnosť služby vs. rozlíšenie času) 90. Popíš Scrum. Dôležitosť tímovej práce Pre-Game: Plánovanie – počiatočné požiadavky podľa priorít, analýza rizík, odhad času, zdrojov, formovanie tímu (5-10 členov), vedúci Scrum Master Architek. návrh – tvorba doménových modelov, definícia architektúry systému Development: prebieha v iteráciách, iterácia sa nazýva Sprint, typická dĺžka iterácie je 30 dní Sprint Planning – stretnutie na začiatku Sprintu – vývojový tím, zákazníci, užívatelia Post-Game - integrácia výsledkov Sprintov, testovanie systému, príprava dokumentácie, školenie užívateľov 91. Popíš Manažment. Manažment je proces koordinácie činností skupiny ľudí, ktorý sa realizuje za účelom dosiahnutia stanoveného cieľa 92. Popíš Projekt. Projekt je časovo ohraničené (úsilie) – každý projekt ma svoj začiatok a koniec, koniec projektu – keď sú dosiahnuté stanovené ciele Je jedinečný (výsledok) – výsledok projektu sa líši od iných projektov 93. Popíš Demingov manažérsky cyklus (PDCA) Plánovanie (plan) – plánovanie zlepšenia Zavádzanie (do) – realizácia plánu Overenie (check) – zhodnotenie výsledkov Jednanie (act) – rozhodnutie o ďalších zmenách 94. Popíš Procesy manažmentu projektu Inicializácia – rozpoznanie, že projekt môže začať, získanie všetkých relevantných informácií (časový cenový horizont, potenciálne riziká), zdroj inicializácie – požiadavky zákazníka, dopyt na trhu, výhody technológie Plánovanie – vytvorenie a udržovanie plánu pre bezpečný chod projektu, definícia požiadaviek na zdroje, prácu, kvantitu práce a kvalitu, je podrobné Riadenie – kontrola a riadenie v závislosti od výkonu, zhromažďovanie a rozširovanie informácií o projekte, sledovanie stavu projektu Prevádzanie – najviac času a peňazí, realizácia plánu projektu, prideľovanie úloh manažérom, koordinácia úloh a priorít, vytvára sa výsledok (výrobok, služba) Ukončenie – zaznamenanie poznatkov, skúseností, poučení pre budúce projekty, ukončenie kontraktu s dodávateľmi 95. Popíš CMM. Capability Maturity Model – nástroje popisujúce, ako dobre sú nastavené praktiky, procesy a chovanie organizácie, zameranie na procesy Štruktúra modelu: o úrovne zrelosti – 5 úrovní, najvyšší stupeň ideálny stav o kľúčové oblasti – súvisiace aktivity pre dosiahnutie cieľov o ciele – ciele definujú rozsah, obmedzenia, zámery kľúč. oblastí o vlastnosti – praktiky začlenenia kľ. oblastí do organizácie o kľúčové praktiky – efektívne praktiky do začlenenia oblastí 96. Efektívnosť komunikácie.