Introduction to Software Engineering (IUS) PDF

Summary

This document provides an introduction to software engineering, discussing software development methodologies, different types of software, quality aspects, and the software crisis. It covers topics like software products, their quality factors, and the need to address the inefficiencies observed throughout the 1960s (the software crisis).

Full Transcript

Machine Translated by Google Introduction to Software Engineering (IUS) 1. Co je softwarové inženýrství? Systematický přístup k vývoji, nasazení a údržbě SW Inženýrská disciplína zabývající se praktickými problémy vývoje rozsáhlých SW...

Machine Translated by Google Introduction to Software Engineering (IUS) 1. Co je softwarové inženýrství? Systematický přístup k vývoji, nasazení a údržbě SW Inženýrská disciplína zabývající se praktickými problémy vývoje rozsáhlých SW systémů 1.1 Proč vytváříme software? Zlepšení služeb (informační systémy..) Snižování nákladů (řízení výroby..) Nemožnost řešení bez použití počítačů (předpověď počasí..) je nutné zlepšovat vlastnosti SW, zejména spolehlivost, bezpečnost a použitelnost, potřeba zvyšovat produktivitu vývoje SW 2. Popis softwarovou krizi z 60. let. Projevovala se a stále se projevuje neúnosným prodlužováním a prodražováním projektů, nízkou kvalitou výsledných produktů, problematickou údržbou a nízkou produktivitou práce programátorů Hledání řešení těchto problémů vedlo k zavedení (První krok k metodickému přístupu programování -) strukturovaného programování 3. Co je softwarový produkt? Sbírka počítačových programů, procedur, pravidel as nimi spojená dokumentace Členové jedné komunity (programátoři) vytvářejí SW(výrobek) pro jinou skupinu lidí (zákazníci). SW produkt není jen samotný program ale také požadavky, specifikace, popisy návrhu, zdrojové texty, testovací data, příručky, manuály Aktéři ve vývoji SW produktu – zákazník (sponzor, specifikuje požadavky na SW), dodavatel (vyvíjí systém, komunikuje s uživatelem), uživatel (testuje, používá systém) Machine Translated by Google 4. Generický a zákaznický SW. Genericky (krabicový) SW: prodává se libovolnému zájemci, musí se dobře otestovat před prodejem, dodatečné opravy jsou náročné Zákaznický SW: šitý na míru konkrétnímu zákazníkovi, cena je vyšší, typické pro systémy řízení výroby, tvorba SW ve SW firmě 5. Kvalita softwarového produktu. Je to souhrn vlastnosti a charakteristik výrobku, procesu nebo služby, který ukazuje jeho schopnost plnit určené nebo odvozené potřeby Není definována jako absolutní míra ale jako stupeň splnění požadavků a potřeb (míra stupně dokonalosti) 6. Správnost SW Do jaké míry SW vyhovuje specifikaci 7. Spolehlivost SW Pravděpodobnost, že SW bude v daném číše vykonávat zamýšlenou funkci 8. Efektivnost SW Splnění kritérií pro využití zdrojů počítačového systému, na čas potřebný k realizaci a dalších kritérií (náklady) 9. Použitelnost SW Úsilí vynaložené na to, aby se dal SW používat 10. Bezpečnost SW Míra odolnosti vůči neoprávněným zásahům do systému 11. Přenositelnost SW Jak velké úsilí je potřebné pro přenos na jinou platformu 12. Znovupoužitelnost SW Do jaké míry lze znovu použít jednotlivé části SW 13. Interoperabilita SW Úsilí potřebné k zajištění spolupráce s jinými systémy Machine Translated by Google 14. Udržovatelnost SW Schopnost SW reagovat na měnící se potřeby zákazníka nebo změny legislativy 15. Testovatelnost SW Úsilí nutně k testování vlastnosti SW 16. Dokumentovanost SW Míra, do jaké jsou všechna rozhodnutí při vývoji SW zdokumentována a kontinuita dokumentace 17. Popis problémy při vývoji SW Složitost - nelze pochopit všechny možné stavy systému a důsledky úprav, žádné dvě části nejsou stejné, složitost je zdrojem dalších problémů (komunikace v týmu..) Přizpůsobivost – při změně by se měl změnit SW ne naopak Nestálost – přibývající požadavky, změna SW v závislosti na okolí Neviditelnost – nejsme schopni určit, co chybí v reprezentaci SW výrobku Méně časté problémy: o práce v týmu o nízká znovupoužitelnost při tvorbě SW o problém míry o tvorba dokumentace – problematická udržovatelná aktuálnost o náchylnost SW k chybám – hodně se projeví při chodu, ne při vývoji SW o způsob stárnutí SW Syndrom 90% hotovo - při posuzování hotové části se vychází z odpracovaného podle plánu a ne podle skutečně hotového Specifikace Náchylnost SW k chybám - některé se projeví až během provozu a ne během vývoje Práče v týmu - komunikační problémy Dokumentace - u velkých projektů náročné na udržení aktuálnosti Stárnutí SW - postupně přidávání nových funkcí a časté opravy vedou k degradaci systému Syndrom 2. systému - autor mě úspěšný 1. produkt, snaží se vytvořit druhy dokonalý - ten je často příliš složitý a nepochopitelný a neefektivní Machine Translated by Google 18. Křivka stárnutí SW 19. Co je softwarový proces? Definuje kdo mě kdy co dělat, aby byly splněny požadavky 20. Popis proces vývoje SW Analýza a specifikace požadavků (8%): zákazníkovy požadavky jsou zapsány do strukturované podoby, pozornost je věnována samotným požadavkům, nikoli jejich realizaci, do této etapy patří i studie vhodnosti a analýza rizik, CÍL: stanovení služeb, které zákazník požaduje od systému a určení podmínek jeho vývoje a provozu Architektonický návrh (7%): ujasnění koncepce systému, dekompozice, plánuje se akceptační testování a nasazení do provozu , školení uživatelů Podrobný návrh: podrobná specifikace součásti systému, vyber algoritmů, stanovení struktury dat, ošetřování chyb, specifikují se požadavky na lidské zdroje, odhaduje se doba trvání a náklady na projekt Plánuje na návrh testu součásti včetně testovacích dat Implementace a testování součásti (12%): programová realizace, vypracování dokumentace, otestování součástí Integrace a testování systému (6%) : spojení součástí do jednoho celku, otestování celého systému, oprava chyb, které se dříve neobjevily Akceptační testování a instalace: otestování zákazníkem/uživatelem, školení uživatelů po akceptaci Provoz a údržba (67%) : zabezpečení provozu SW, průběžné řešení dalších problémů, které se dříve neprojevily, opravy, rozšiřování a přizpůsobování SW Machine Translated by Google 21. Popis vodopádový/ lineární model základní model, etapy lineární za sebou (od první etapy po poslední) možnost návratu k předešlé etapě, neodpovídá vývoji reálných projektů výhody: jednoduchý na řízení, pokud jsou požadavky neměnné tak je ideální nevýhody: zákazník není nikdy schopen předem stanovit přesné požadavky, při změnách se dlouho realizují, zákazník vidí spustitelnou verzi až v pozdějších etapách vývoje – příliš pozdě na odhalení nedostatků 22. Popis V-model Je to varianta vodopadového modelu s větším důrazem na testování V symbolizuje grafické uspořádání etap, V jako verifikace a validace, levá část – vývojové aktivity, plánování testů, pravá část – testování podle plánu Machine Translated by Google 23. Popis W-model Vychází z V modelu Aktivity spojené s testováním jsou na stejné úrovni jako návrhové aktivity (druhé souběžné V), levá strana – ověřování, plánování a návrh testů, pravá strana – testování, změny kódu, regresivní testování 24. Popis iterativní model proces vývoje je rozdělen do iteraci, jednotlivé iterace jsou vlastně vodopády, po každé iteraci má uživatel k dispozici neúplnou verzi pro otestování výhody - zákazník má možnost validovat výsledek nevýhody - náročnější na řízení, potenciálně horší výsledná struktura Machine Translated by Google 25. Popis prototypování není to ucelený model, je součástí jiných systémů prototyp: částečná implementace produktu, prezentuje vnější rozhraní (validace), dále se nepoužívá 26. Popis inkrementální model Kombinace lineárního a iterativního modelu, na základě celkové specifikace se stanoví ucelené části systému Může to být buď série vodopádů pro každou součást systému, nebo například specifikace a návrh vodopádem a následuje iterativní přístup kombinovaný s prototypováním... Výhody - Jednoduché zavedení změn během vývoje Nevýhody – vývoj po částech může vést ke ztrátě vnímání logiky celku Machine Translated by Google 27. Popis spirálový model Kombinace prototypování a analýzy rizik Jednotlivé etapy se neustále opakují, vždy na vyšším stupni Mezníky (Milestones) – převzato metodikou RUP o Life Cycle Objectives – vyhodnocení cíle projektu, stanovené požadavky, cena, plán, priority, identifikovaná rizika o Life Cycle Architecture – vyhodnocení architektury, řešení rizik, požadavky a architektura jsou stabilní o Initial Operation Capability – systém připravený k distribuci, stabilní verze pro zákazníka Výhody - vhodný pro složité projekty, nezávislý na metodologii, chyby a nevyhovující postupy jsou hned odhaleny Nevýhody - analýza rizik musí být na vysoké úrovni, problematické plánování termínů a cen, vyžaduje neustálou spolupráci se zákazníkem, SW je k dispozici až po posledním cyklu Analýza rizik: cílem je odhalit možná ohrožení projektu (odchod lidí, snížení rozpočtu, selhání HW, nezájem o produkt) a připravit na ně reakce Machine Translated by Google 28. Popis Metodika RAD - Rapid Application Development James Martin, ŘADA 1991 rychlý iterativní vývoj prototypů funkční verze jsou k dispozici mnohem dříve než u ostatních modelů intenzivní zapojení zákazníka do vývoje - rychlé reakce na změny Fáze: Plánování, Návrh, Provedení, Uzavření a nasazení Výhody – flexibilita, možná rychlá změna na požadavek zákazníka, úspora číši a zdrojů - může to vést k nižší kvalitě) Nevýhody – nutnost spolupráce se zákazníkem, nižší kvalita návrhu, problém s udržovatelností 29. Popis RUP - Rational Unified Process objektově orientovaná metodika věnuje se všem etapám vývoje SW (kdo, co, kdy, jak...) základní praktiky: - využívání stávajících komponentů - iterativní vývoj - model je vizualizován - UML - průběžná kontrola kvality - zprava požadavků zákazníka - řízení změn systému výhody: vhodný pro velkou škálu projektů, včasné odhalení rizik, správa změn, přepracování do detailů, UML nevýhody: u menších projektů neefektivní vývoj, komerční (mnoho podpůrných produktů) 4 fáze: - inception/zahájení - rozsah, náklady, rizika, první UC,1-2 iterace - elaboration/projektování - plánování, specifikace požadavků, architektura, analýza rizik, 2-4 iterace - construction/realizace - analýza, návrh, implementace, 2-4 iterace - transition/ dodání – dodání, školení, podpora při zavedení, 2 iterace (beta, plná verze) Machine Translated by Google 30. Co je to abstrakce? Zjednodušený pohled na systém bez ztráty jeho významu 31. Co je to zapouzdření? Související data, operace a atributy seskupené do jedné jednotky za účelem zakrytí implementačních detailů 32. Co je to dědičnost? Definuje objekty a třídy na základě již existujících objektů, vzniká hierarchie 33. Co je polymorfismus? Znalost třídy/objektu jak provést určitou operaci, která ale může být společná pro více tříd 34. Popis problémy při specifikaci požadavků Přirozená neúplnost a nepřesnost požadavků zákazníků, nepřesná formulace Nedostatek znalostí analytika (neznalost analyzované oblasti, terminologie), zákazníka (neznalost vývoje SW, terminologie) Nekonzistentní požadavky – různí uživatelé – různé požadavky (i mezi zákazníkům a uživatelům) Další problémy – problémy s testováním a validací požadavků Vyřazení - v době specifikace je nějaká entita implicitní, ale s odstupem číši se může vytratit Deformace - získaná informace může zavádět Zobecnění - věta je příliš obecná, proto je nepravdivá 35. Popis diagram tříd (CLASS DIAGRAM) Zobrazuje třídy a statické vztahy mezi nimi Kromě tříd obsahuje rozhraní, seskupení a vztahy (obecnění, asociace, závislost, realizace) Je často používán pro modelování a návrh systému Machine Translated by Google 36. Popis diagram objektů (OBJECT DIAGRAM) Zobrazuje objekty jako instance tříd a jejich vztahy Jsou úzce spojeny s diagramy tříd Popisuje statickou strukturu systému ve specifickém čase Využívají se k testování přesnosti diagramu tříd Mezi objekty existuje spojení 37. Popis diagram seskupení (PACKAGE DIAGRAM) Ukazuje seskupení příbuzných elementů systému a závislosti mezi nimi Je užitečný pro uspořádání rozsáhlých systémů 38. Popis diagram případů použití (USE CASE DIAGRAM) Vytváří se s pomocí uživatelů ke zjištění funkčních požadavků na systém, hranice a rozsah systému Představuje soubor případů použití (funkce vykonávaná aktérem), aktérů (pracuje se systémem), vzájemných vztahů, interakcí Každý případ použití popisuje posloupnost událostí, má vstupní podmínky, tok událostí a následné podmínky Machine Translated by Google 39. Popis stavový diagram (STATE DIAGRAM) Modelování dynamického chování a změn( stavy objektů, přechody mezi stavy, počáteční a koncový bod stavových změn) Zachycuje stav jediného objektu Využívá se k ujasnění životního cyklu objektu Je nutností pro vývoj systému 40. Popis diagram aktivit (ACTIVITY DIAGRAM) Zvláštní případ stavového diagramu, stavy představují aktivity a přechody jsou vyvolané dokončením aktivit Reprezentují objektově orientované vývojové diagramy Vhodný pro pochopení toku činnosti (scénář případu použití, detail operace, algoritmu, obchodní proces) Je navržen jako zjednodušený pohled na dění v průběhu procesu Podpora paralelního chování - vícevláknové programování Není vhodný pro reprezentování složitého větvení a popis chování objektu v průběhu jeho života Machine Translated by Google 41. Popis sekvenční diagram (SEQUENCE DIAGRAM) Identifikuje základní vnitřní dynamiku Popisuje spolupráci skupiny objektů Ukazuje jak objekty mezi sebou komunikují v časové rovině Nejsou vhodně pro zobrazení detailu algoritmu Skládá se z objektů a sprav 42. Popis diagram komunikace (COMMUNICATION DIAGRAM) Ukazuje účastníky interakce a datová spojení mezi nimi Vhodnější pro zobrazení spojení než sekvenční Sekvenční je vhodnější při zobrazení sekvence volání Machine Translated by Google 43. Popis implementaci shora-dolů a zdola-nahoru Shora-dolů: nejprve se vytvoří moduly na nejvyšší úrovni a postupně moduly nižších vrstev, systém lze spíše testovat jako celek a vážné chyby jsou včas odstraněny, nevýhoda je že je třeba simulovat podsystémy, které ještě nejsou vytvořeny, testování logiky systému je náročnější než testování jednotlivých modulů Zdola-nahoru: nejprve nejnižší moduly, odladí se a využívají se na tvorbu na vyšší úrovni, nevýhoda je že chyby se projeví později – v etapě integračního testování, testování modulů jednotlivě je jednodušší než celé logiky systému 44. Jaký je rozdíl mezi validací a verifikací? Validace - ověření, že SW splňuje potřeby uživatele Verifikace - ověření, že SW vyhovuje specifikaci 45. Popis cíle a průběh testování Cílem testování je odhalit chyby během vývoje SW Test, který neodhalí nesprávné chování SW je neúspěšný Jsou navrženy testovací vstupy (dvojice vstupní a očekávaná výstupní data) Vstupní data jsou zadaná a zaznamenaná výstupní data Výstupní data se porovnají s očekávanými Testovací vstupy vybíráme takové, u kterých lze očekávat, že způsobí chybu. 46. Popis metodu testování černé a bílé skříňky. Bílá skříňka - zaměřuje se na vnitřní logiku a strukturu systému, předpokládá se důkladná znalost implementace systému Černá skříňka - test vychází ze specifikace bez znalosti o vnitřní struktuře 47. Popis process-oriented přístup k modelování Lidé jsou jen zdroje, procesy musí fungovat i když se změní tým, musí fungovat za všech okolností Podstatná je role (analytik, programátor, tester..), ne individualita Standard pro komunikaci je dokumentace 48. Popis people-oriented přístup Lidé nefungují vždy stejně, důraz na individualitu Důležitá je kvalita členů týmu, ne jejich počet Důležitá osobní komunikace, podpora práce vývojového týmu Machine Translated by Google 49. Popis Agilní metodiky a Heavyweight metodiky Agilní Minimum byrokracie Doraz na komunikaci v týmu Co nejrychleji vyvinout SW, čekat na zpětnou vazbu od zákazníka Doraz na testování Adaptivní přístup, malé projekty a malé týmy, decentralizované řízení, malý objem dokumentace, people-oriented, kritérium: čas a zdroje, proměnné kritérium: funkcionalita Různé metody: extrémní programování, Crystal, Scrum... Heavyweight Prediktivní přístup, velké projekty a velké týmy, centralizované řízení, velký objem dokumentace, process-oriented, kritérium: funkcionalita, proměnné kritérium: čas a zdroje 50. Popis extrémní programování Komunikace, testování, párové programování Doraz na zpětnou vazbu – zákazník je člen týmu – vyhodnocuje dosaženou funkcionalitu Jednoduché věci je třeba tvořit jednoduše Uvolňovat jen malé změny postupně - ale často Testování je základ Proces vývoje – Zkoumání, Plánování, Iterace, Produkce, Údržba, Uzavření 51. Metriky - výpočty LOC- počet řádků kódu kLOC - kilo LOC spolehlivost – střední doba mezi výpadky systému MTBF = MTTF+MTTR dostupnost – pravděpodobnost, že program v daném čase funguje (MTTF/MTBF)*100 MTBF - měnová doba mezi failures (MTTR + MTTF) MTTR - časová odezva na recovery (počet jednotek offline/počet úseků offline) MTTF - měná lhůta pro failure (počet jednotek online/ počet úseků online ) Machine Translated by Google 52. Co je to vlastnictví? Neomezené právo na věc, vlastnictví hmotných zdrojů je přirozené pro lidi, vlastnictví nehmotných zdrojů je sporné – chybí jim vzácnost 53. Co je patent? Monopol na výrobek, službu, platí 20 let, lze jej prodat, souhlas k využití se dává licencí Aby byl patent uznán jako vynález musí být nový, výsledek vynález. činnosti, průmyslově využitelný Např.: telefon, TV 54. Co je to autorské pravo? Výsledek tvůrčí činnosti autora vyjádřené v jakékoli vnímatelné podobě, autor je fyzická osoba, která dílo vytvořila Vzniká vytvořením díla, jsou chráněny 70 let po smrti autora 55. Co je ochranná známka? Slovní nebo obrazové označení výrobku slovy, písmeny, čísly, barvou, kresbou Odlišuje výrobce a propaguje, brání třetím osobám používat stejné označení (v ČR platí 10 let) Např.: Microsoft Windows, Coca-Cola 56. Popis licence Slouží k udělení práv na využívání intelektuálního vlastnictví Public - veřejně bez omezení Open-source - volně dostupné kódy -GPL - general public -LGPL - lesser GPL - knihovny -GFDL - free documentation - dokumentace -BSD - zcela volně šíření Softwarové licence Proprietární – privátně vlastněné a kontrolované, výrobce dodává spustitelnou aplikaci, uživatel nemá právo studovat či editovat zdrojový kód, o Např.: SW s licencí na jednom počítači, licenční programy pro školy, serverové licence, licence vázaná na daného uživatele Svobodný (Free SW, Open Source SW) – umožňuje spouštět program za jakýmkoli účelem, studovat a přizpůsobovat program, vylepšovat jej o Tři směry licencí: copyleft – uděluje práva k modifikaci za určitých podmínek, BSD-style – požaduje pouze formální atributy modifikovaného SW, jinak s ním můžeme nakládat volně, public domain – autor se zříká autorských práv Machine Translated by Google 57. Popis metodiky vývoje SW Metodiky vývoje SW se věnují aspektům, které ovlivňují vývoj SW produktu (proces tvorby SW..) Metoda – postup pro dosažení určitého cíle Metodika – souhrn doporučených praktik a postupů Metodologie – nauka o metodách, jejich tvorbě a použití o Metodika vývoje SW = Software Development Methodology 58. Popis životní cyklus softwaru Rozděluje proces vývoje SW na období (etapy) s daným cílem Analýza a specifikace požadavků (8%) Architektonický návrh a podrobný návrh (7%) Implementace a testování součásti (12%) Integrace a testování systému (6%) Provoz a údržba (67%) 59. Popis Proces vývoje softwaru Proces, ve kterém: o se potřeby uživatele transformují na požadavky na SW o požadavky na SW se trans. na návrh o návrh se implementuje o implementace se testuje o produkt se dodá uživateli 60. Popis dekompozice problémů Rozdělení (dekompozice) složitého problému na jednodušší Přináší: snáze zvládnutelné systémy, pozornost na jeden podsystém, vývoj podsystémů nezávisle na sobě, velké systémy bez dekompozice nelze zvládnout 61. Popis hlavní cíle SW inženýrství Management projektu – řízení životního cyklu projektu, efektivita práce – čas Techniky – analýzy, návrhu, programování, testování. Vlastnosti SW inženýra – základní znalosti, schopnost aplikovat znalosti, schopnost získávat nové znalosti Machine Translated by Google 62. Popis analýzu a specifikaci požadavků Stakeholder – zúčastněná strana v projektu = zákazník, uživatel, analytik, návrhář, tester, manažer. Je důležité zapojit nejen zákazníka, ale identifikovat všechny stakeholders a zapojit je do projektu 63. Popiš Typy požadavků Obchodní – proč zákazník potřebuje systém, obchodní cíle – úspora nákladů, úspora času Uživatelské – co se dá se systémem dělat, úkoly, které vykonává uživatel Funkční – co musí být provedeno, aby mohly být vykonány úkoly (user req.) a tím splněny obchodní požadavky (business req.), chování systému v různých podmínkách (NAPR: co vše je třeba zjistit pro zjištění dostupnosti léku, chemikálie, co vše je třeba zjistit pro rezervaci knihy o uživateli apod.) Nefunkční – vlastnosti a charakteristiky, které musí systém splňovat a respektovat omezení o požadavky na provoz systému (statické – např. počet uživatelů, dynamické – např. doba odezvy..) o požadavky na výsledný systém (poč. vybavení – např. HW náročnost, program. vybavení – např. op. systém, vyvíjený software – např. efektivita, spolehlivost) o požadavky na vývojový proces – dodržování pravidel, předání systému o požadavky na rozhraní - SW - User, SW - HW o externí požadavky – legislativa (ochrana informací..) Získávání informací – cíl projektu, interview, uživatelské požadavky Analýza – vhodnost, modelování, prototypování Specifikace – transformace informací z analýzy do dokumentu Validace – vyhodnocování požadavků, simulování, prototypování Machine Translated by Google 64. Popiš Dobrou specifikaci požadavků Seřazena podle důležitosti – požadavky podle data Sledovatelná – smysl požadavku je jasný Modifikovatelná – jednoduché úpravy a doplňování požadavků Jednoznačná Úplná – obsahuje všechny důležité požadavky Konzistentní – požadavek není v rozporu s jiným požadavkem Verifikovatelná – měřitelnost splnění požadavků 65. Popiš Datové modelování Mít v systému všechna potřebná data Nemít v systému žádná nepotřebná data Vyjádřit vztahy mezi daty Popsat transformování dat v systému Entita – objekt, rozlišitelný od jiných objektů Entitní množina – množina entit stejného typu (sdílejí atributy) Atribut – vlastnost entity, která nás zajímá o Prázdné (NULL), Jednohodnotové, Vícehodnotové (telefon), Odvozené (datumNarození->věk) Vztah – asociace mezi entitami Vztahová množina – množina vztahů, které sdílejí vlastnosti 66. Popiš kardinalitu Maximální počet vztahů daného typu (vztah. množina) ve kterých se může podílet jedna entita (1..*, 0..*,..) 67. Popiš Data Flow Diagram (DFD) Diagram datových toků Technika při strukturované analýze Je hierarchický model – ukazuje funkce systému, toky mezi daty, je doplněn minispecifikacemi Machine Translated by Google 68. Popiš Přístupy k analýze a návrhu Strukturovaný – systém chápaný jako komplex procesů, které operují nad daty o Konceptuální model – podstata systému, DFD o Logický model – implementace konceptuální struktury o Fyzický model – fyzické uspořádání dat (soubory..) Objektově orientovaný – systém chápaný jako komplex vzájemně komunikujících objektů o objektově orientované prostředky (objekty, třídy, UML) a metodik (RUP) o vyšší stabilita navrhovaných prvků o Objekt má roli, identitu, má metody, uchovává data, zpracuje a odesílá zprávy 69. Popiš Vztahy tříd Dědičnost – vztah generalizace mezi třídami, odvozená třída sdílí atributy, chování, vztahy, může přidat atributy, chování Asociace – zachycuje vztahy mezi třídami, asoc. má své násobnosti, název, vyjadřuje proměnlivý vztah mezi objekty o Agregace – seskupení více částí, seskupený objekt může existovat bez tvořícího objektu, konstituční objekt může být součástí více seskupení Závislost – vyjadřuje vztahy mezi objekty, třídami Realizace – vztah mezi třídou a rozhraním 70. Popiš principy orient. návrhu Single Responsibility Principle (SRP) – třídy by měly mít jedinou zodpovědnost, důvod ke změně Open Closed Principle (OCP) – třída by měla být otevřena pro rozšíření, uzavřena pro modifikace Dependency Inversion Principle (DIP) – závislost na abstraktním, nikoli na konkrétním, směr závislostí na konkr. Acyclic Dependencies Principle (ADP) – závislosti nesmí tvořit cykly Liskov Substitution Principle (LSP) – odvozené třídy by měly být zaměnitelné za bázové třídy (např. kružnice – elipsa) Do not Repeat Yourself (DRY) – neopakujte stejný kód na různých místech – vytváří obecnější třídu Machine Translated by Google 71. Popiš jazyk UML Unified Modelling Language Základní modelovací jazyk metodiky RUP Stavební bloky UML: o Předměty – prvky (třída, případ použití, stav) o Vztahy – určují vzájemnou souvislost předmětů (závislost, asoc, agre., komp., realiz.) o Diagramy – modely UML (use case diagram, diagram tříd, diagram seskupení, diagram objektů) o Ornamenty – obohacuje prvky (atribut, operace) 72. Popiš Diagramy jazyka UML 2.0 Diagramy struktury o D Tříd, D objektů, D seskupení Diagramy chování o D případu použití, Stavový D, D aktivit Diagramy interakce o Sekvenční D, D komunikace 73. Popiš jazyk OCL Object Constraint Language (OCL) Definuje omezení, podmínky a připomínky nad UML modely Formální jazyk navržený pro návrháře Využití: o specifikace podmínek pro provedení metod o spec. omezení, hodnot atributů, tříd 74. Popiš Návrh architektury Zaměřuje se na organizaci systému – identifikují se komponenty, vztahy a jejich komunikace Vytvořen na začátku vývoje SW v první iteraci Návrh je spojen se specifikací požadavků 75. Popiš Architektonické vzory Abstraktní popis dobrých odzkoušených praktik Jsou ověřeny na různých systémech Obsahují informace o vhodnosti použití, slabé a silné stránky Např.: Model-View-Controller, Vrstvená architektura, Klient-Server Machine Translated by Google 76. Popiš Model-View-Controller Odděluje prezentaci a interakci od systémových dat (odděluje model a pohled na model) Používá se pro různé zobrazení a interakce pro jeden model Výhody: data mohou být měněna nezávisle na reprezentaci a naopak Nevýhody: těžší zpracování pro jednoduché modely Model - spravuje data a stav aplikace, informuje View o změnách stavu View – zobrazuje model, vyžaduje změny modelu, posílá uživatelské činnosti Controlleru Controller – zajišťuje změny modelu na základě akcí uživatele a změny View na základě změny modelu Např.: webová aplikace, M – databáze, V – dynamické stránky, formulář, C – http protokol, validace dat 77. Popiš Vrstvenou architekturu Rozdělení systému do vrstev – každá vrstva má svou funkcionalitu, nadřazená vrstva používá služby nižší vrstvy (nejnižší vrstva = jádro systému), elementy každé vrstvy můžeme modifikovat nezávisle Výhody: náhrada vrstvy za novou vrstvu, redundantní služby (autentifikace..) Nevýhody: náročné oddělení vrstev, potřeba přímé komunikace vyšší a nižší vrstvy, požadavky na výkon aplikace Podpora inkrementálního vývoje – snazší úprava architektury Např.: knihovní systém řídící přístup k chráněným elektr.zdrojem Machine Translated by Google 78. Popiš Architekturu Klient-Server Funkcionalita je rozdělena do služeb – každá služba je poskytována nezávislým serverem Klient je uživatel služeb, přistupuje na servery Použití: přístupnost pro velký počet klientů, replikace serverů při zatížení systému Výhody: distribuce serverů v síti, služby jsou dostupné pro všechny klienty Nevýhody: náchylnější k útokům (typ denial of service), výkon aplikace neumíme předpokládat, problémy se správou serverů (vlastník 1 organizace) 79. Popiš Konceptuální modely Doménový model – entity a pojmy problémové domény (reprezentuje reálný systém (system-as-is) , vycházejí z ní obch., uživ., funk., a nefunk. požadavky) Model architektury – dekompozice systému, např.: diagram tříd Modely chování – uživ., funk. požadavky (málo i nefunk.), např.: use case diagram, stavový diagram Modely interakce – interakce elementů (objekty, aktéři) v use case diagramu, např.: diagram komunikace Datový model – perzistentní data (stálá data), např.: ERD 80. Popiš Generace programovacích jazyků První generace – programování přímo v binárním kódu Druhá generace – assemblery, symbolické vyjádření binárních instrukcí (1 k 1) Třetí generace – procedurální jazyky, jeden příkaz transformován do 5-10 instrukcí v bin.kódě Čtvrtá generace – neprocedurální jazyky (což je třeba provést, ne jako), jeden příkaz přeložen do 30-50 instrukcí v bin. kódu, tzv. uživatelské programování Microsoft Excel Machine Translated by Google 81. Popiš Typování a jazyky Význam – určit sémantický význam elementů (známe příslušné operace) Staticky typované jazyky – typová kontrola během kompilace např.: C++, Java Dynamicky typované jazyky – typová kontrola během běhu programu např.: Smalltalk, Self, Python, Lisp Silně typované – silná omezení na kombinaci typů, zabránění kompilaci kvůli nekompatibilním typem, tzv. typově bezpečné (type safe) Slabě typované – slabá omezení na kombinaci typů (např.: implicitní přetypování) 82. Popiš Přístupy statického ověřování Formální (Inspection) Neformální (Walkthrough) Sledování přes rameno (Over-The-Shoulder) Párové programování (Pair Programming) Koupací kachna (Rubber Duck Debugging) 83. Popiš Code Review. 200-400 LOC na prohlídku, odhalení až 15 chyb za hodinu Nejefektivnější způsob odhalování chyb v kódu, zvyšuje čitelnost, údržbu kódu, zlepšuje schopnosti méně zkušených programátorů 84. Popiš Techniky testování. Náhodné testování – náhodné testovací vstupy Funkcionální testování – vstupy a výstupy na základě specifikace, metoda černé skříňky (black box, functional, closed box) o zjištění zda vstupní a výstupní data vyhovují specifikaci o nebereme v úvahu vnitřní strukturu, logiku modulu o úplné funkcionální testování je v praxi nemožné Strukturální testování – na základě vnitřní struktury programu, metoda bílé skříňky (white box, open box) o vychází z vnitřní struktury, testuje se implementace programu o pokrývá řízení a údaje (data) – založené na tocích řízení a tocích dat o mutační testování – úmyslně zavedené chyby do programu Testování rozhraní – na základě rozhraními mezi moduly a specifikací programu Machine Translated by Google 85. Popiš Strategie testování Testování zdola-nahoru – testování komponent na nižší úrovni, poté na vyšší úrovni Testování shora-dolů – testování modulů nejvyšší úrovně, poté submoduly Sendvičové testování – kombinace shora-dolů, zdola-nahoru Jednofázové testování – testování modulů samostatně, poté se najednou integrují Testování pozorováním – prototyp, technika programování N-verzí 86. Popiš Statickou a Dynamickou analýzu Statická analýza – analýza programu bez spuštění, soustředí se na časté programátorské chyby – syntaktické, neinicializace proměnných, dělení nulou, neoprávněný přístup do paměti Dynamická analýza – analýza za běhu testovaného programu, soustředí se na nesprávnou práci s pamětí (Valgrind), uvíznutí (deadlock), časově závislé chyby (race condition), hlásí méně falešných chyb než Statická an. 87. Popiš Akceptační testování. Testování uživatelem na reálných datech, uživatel rozhodne, zda produkt splňuje zadání, vztahuje se na zákaznický software 88. Popiš Alfa a Beta testování. Alfa testování – tam kde se vyvíjí software, testování uživatelem (vývojáři sledují a evidují chyby), známé prostředí Beta testování – testování uživatelem u sebe, neznámé prostředí, výsledkem je správa uživatele Machine Translated by Google 89. Popiš IT Support. Distribution. IT podpora používá multivendor strategy (strategii více prodejců) o skládá se z vnitřní podpory o 3 hlavní dodavatelé – IBM, ATOS, HP o centrální management spolehlivosti, bezpečnosti, podpory aplikací IT support se skládá z IT Operations (operace v daném prostředí s danou kvalitou a poplatky, vyřizování denních dotazů a otázek služeb, menší upgrady) a IT Transitions (přechody na naplnění požadavků pro funkcionalitu, velké upgrady, vylepšení, projekty) Úkoly pro IT Operations Dostupnost služeb, ochrana údajů, zálohování, legální procesy (archivace), podpora uživatelům, finanční cíle Úkoly pro IT Transitions Vylepšit na novější verze, změnit poskytovatele SW, nové standardy Změnit strategii společnosti, reorganizace společnosti, řídit se legálními požadavky (práva, daně, zprávy) Virtualization Adv – flexibilita, lepší využívání zdrojů, přidělení zdrojů je online, méně manuálních činností v případě HW modifikace Disadv – přináší jiný level komplexnosti, limit připojení – sítě, vyšší požadavky na stabilitu, licenční limity pro aplikace Cloud – speciální typ outsourcingu Public cloud – + flexibilita v přidělení zdrojů, + méně vlastní snahy, - bezpečnost, - poloha, - limitovaná záruka v případě ztráty dat, -poplatky Machine Translated by Google Private cloud – +bezpečnost není problém, - vyšší poplatky, -menší flexibilita SLA (Service Level Agreement) Sjednaná dohoda mezi zákazníkem a poskytovatelem služeb o dostupnosti služeb a kvalitě kvantifikovaným způsobem. Většinou se odkazuje na řešení mimořádných událostí, avšak může zahrnovat kontinuitu podnikání, obnovu, řízení výkonnosti, záruku, dostupnost a ostatní parametry služeb. OLA (Operational Level Agreement) Dohoda mezi interními podpůrnými skupinami, odvozených od SLA. Typicky je přísnější než SLA a odráží jiný druh procesu (dostupnost služby vs. rozlišení času) 90. Popiš Scrum. Důležitost týmové práce Pre-Game: Plánování – počáteční požadavky dle priorit, analýza rizik, odhad času, zdrojů, formování týmu (5-10 členů), vedoucí Scrum Master Architek.návrh – tvorba doménových modelů, definice architektury systému Development: probíhá v iteracích, iterace se nazývá Sprint, typická délka iterace je 30 dní Sprint Planning – setkání na začátku Sprintu – vývojový tým, zákazníci, uživatelé Post-Game - integrace výsledků Sprintů, testování systému, příprava dokumentace, školení uživatelů 91. Popiš Management. Management je proces koordinace činností skupiny lidí, který se realizuje za účelem dosažení stanoveného cíle 92. Popiš Projekt. Projekt je časově ohraničené (úsilí) – každý projekt má svůj začátek a konec, konec projektu – když jsou dosaženy stanovené cíle Je jedinečný (výsledek) – výsledek projektu se liší od jiných projektů Machine Translated by Google 93. Popiš Demingův manažerský cyklus (PDCA) Plánování (plan) – plánování zlepšení Zavádění (do) – realizace plánu Ověření (check) – zhodnocení výsledků Jednání (act) – rozhodnutí o dalších změnách 94. Popiš Procesy managementu projektu Inicializace – rozpoznání, že projekt může začít, získání všech relevantních informací (časový cenový horizont, potenciální rizika), zdroj inicializace – požadavky zákazníka, poptávka na trhu, výhody technologie Plánování – vytvoření a udržování plánu pro bezpečný chod projektu, definice požadavků na zdroje, práci, kvantitu práce a kvalitu, je podrobné Řízení – kontrola a řízení v závislosti na výkonu, shromažďování a rozšiřování informací o projektu, sledování stavu projektu Převádění – nejvíce času a peněz, realizace plánu projektu, přidělování úkolů manažerům, koordinace úkolů a priorit, vytváří se výsledek (výrobek, služba) Ukončení – zaznamenání poznatků, zkušeností, poučení pro budoucí projekty, ukončení kontraktu s dodavateli 95. Popiš CMM. Capability Maturity Model – nástroje popisující, jak dobře jsou nastaveny praktiky, procesy a chování organizace, zaměření na procesy Struktura modelu: o úrovně zralosti – 5 úrovní, nejvyšší stupeň ideální stav o klíčové oblasti – související aktivity pro dosažení cílů o cíle – cíle definují rozsah, omezení, záměry klíč. oblastí o vlastnosti – praktiky začlenění klí. oblastí do organizace o klíčové praktiky – efektivní praktiky do začlenění oblastí 96. Efektivnost komunikace.

Use Quizgecko on...
Browser
Browser