SIN Flashcards

Question

Stakeholder

Answer 1

Zainteresovana osoba, ktera je ovlivnena systemem, pozaduje projekt nebo ho sponzoruje - nebo kdokoliv kdo se na projektu podili Users * Administrators * Non-Users * Customer * Sponsor * Domain experts * Implementation experts * Project Management * Test experts * Supplier * Hackers * Stakeholders of competing systems * Institutions/Regulator … (statní i nestátní instituce)

Answer 2

1. Modelovani business procesu a entit - jak funguje organizace? 2. Analyticke modelovani - co system dela? 3. Navrhove modelovani - jak to system dela? 4. Kodovani - implementace

Answer 3

Prvni uroven modelovani systemu - popisuje Business Domain Model - entity systemu a vazby - business procesy v ramci organizace Business process - obchodni/firemni postup - mnozina aktivit, ktera realizuje podnikatelsky cil firmy - treba "Zahradkareni", Odecet mericu, Pripojeni mericu, Vyuctovani... AS IS - jake jsou postup ted? AS BOSS THINKS IT IS - jak si to predstavuje vedeni TO BE - jake budou procesy po zavedeni systemu? Typy procesu: 1. Hlavni - financni jadro firmy 2. Podpurne - technicke provedeni hlavnich procesu 3. Ridici procesy - vedlejsi, doplnkove

Answer 4

Vizualizuje nejaky proces systemu - prehlednejsi diagram nez textovy popis - uzly jsou akce - hrany jsou chronologicky navazujici prechody ma start -> 1.akce -> 2. akce -> ... -> konec Muze mit vetvici rozhodovaci body s podminkou (GUARD) Start -> Podat zadost o dovolenou -> posoudit zadost -> ROZHODNUTI [ANO]/[NE] -> (ano) zanest schvaleni do archivu -> oznamit vysledek -> konec Tento diagram muzu rozdelit vizualne na zony zodpovednosti - treba jaka aktivita se musi provest v Praze, jaka v Brne, jaka jinde - nebo podle roli - aktivita Admin, pak User atd... - muze mit paralelni rozvetveni - vodorovna cara vymezuje paralelni blok, kde aktivity probihaji najednou (fork-join) - koncu muze byt vice - plne vyplneny je ze konci cely diagram (muze jich byt vic) - nevyplneny s krizkem ukoncuje pouze prislusnou vetev (muze jich byt vic) Muzeme vnorovat aktivity (pro prepouzitelnost) jako o-o symbol, kde tato aktivita zabaluje jeste jine aktivity v sobe pro prehlednost Existuji dve znacky - SEND, RECEIVE zpravy mezi aktivitami, ktere graficky znazornuji odeslani a prijeti nejake zpravy na kterou aktivita muze reagovat jako trigger - treba zamitnta operace je znazornena jako ERROR a posle se zprava chybova

Answer 5

Cil - globalni smerovani cilu organizace - chci zvysit trzby v cr o 20% do peti let Pozadavek - nastroje, kroky k naplneni cile - popisu duvodu, dosahnuti cile, reaguji na potreby - jako XY potrebuji XY pro XY... Systemovy pozadavek - popis IT reseni - defincie IT omezeni, reseni, reakce na business pozadavek - implementace business pozadavku B. pozadavek - jako manaze chci zpracovavat data o trzbach pro vypocet S. pozadavek na to - system umozni export tabulek do CSV Hierarchie: Business cil -> je postaven z business pozadavku -> ktere jsou realizovany systemovymi pozadavky Sablona: Jako potřebuji , protože BR 235 - Jako obchodník potřebuji být informován o končících smlouvách svých klientů, abych mohl začít jednání o nové smlouvě včas. V kazde fazi projektu se provede sber pozadavku, jejich analyza, dokumentce a overeni, neustale upresneni cilu a pozadavku Granularita - detailnost pozadavku se zacina od nejmene konkretnich (ve fazi prvotni analyzy) a postupne se pozadavky upresnuji na konkretni detaily - pozadavky kde ma budova stat? - potom - jaky je tvar budovy? - nejpozdeji - jake zidle budou v budoe? - tedy nema smysl resit pozadavky na tvar zidli, kdyz ani nemame plan kde bude samotna budova

Answer 6

Nutne vlastnosti - dissatisfiers – Vlastnosti/požadavky, které nebyly stakeholderem ani zmiňovány, protože je považoval za zcela zřejmé. – Př.: Systém bude umožňovat kopírovat veškeré zobrazené tabulky pomocí „CTRL + C a CTRL + V“ do MS Excel . - pokud nebudou implementovany => rozladeny klient  Požadované vlastnosti (Satisfiers) – Explicitně zmíněné vlastnosti/požadavky. – Př.: Systém umožní montérovi vkládat žádosti o odstranění překážek bránících přístupu k elektrickým přípojkám.  Zbytné vlastnosti (Delighters – „Nadchávače“) – Vlastnosti systému, které stakeholder neočekával, ale po jejich objevení/používání je považuje za příjemné vylepšení. – Př.: Systém bude propojen s rozhraním banky a bude automaticky párovat došlé platby s předpisy plateb. Jak jde čas, tak se ze zbytných vlastností se stanou požadované a z požadovaných nutné.

Answer 7

0.krok - priprava sberu - urcit, jak pozadavky budu sbirat 1. Samotny sber 2. Dokumentace pozadavku - prvotni navrh 3. Anayla a souhlas vystupu = prvotni fazi jde pouze o prani, nikoliv jeste pozadavky, protoze sbiram jenom prvni utrzky zainteresovanych osob a mohou byt v rozporu s cily nebo navzajem Poazdavky ziskavam od zainteresovanych osob a firmy - zakaznik, uzivatel - pak s dokumentace stavajiciho systemu - z procesu firmy - z konkurencniho trhu - resim pouze s relevantnim okolim (tedy spise se bude ptat uzivatele systemu nebo administratora nez uklizecky firmy) Ne vzdy mam presne pozadavky - muzou byt pouze predpoklady a otevreene body - nutne posouvat do dalsich fazi na analyzu a prehodnocovat pozdeji Vzdy se zamerit pouze na sber pozadavku, nikoliv reseni konfliktu v pozadavcich - identifikovat problemy - analyzovat - resit problemy - dokumentace

Answer 8

Cokoliv je lepsi nez nic: - poznamky z meetingu - grafy, screenshoty - videa - tabule - emaily... Dale se to rozpracovava v analyze

Answer 9

- vlastni napady, zkusenosti z praxe - skupinovy meeting, setkani s nejvyse postavenymi zakazniky - individualni osloveni zamestancu co se systemem realne delaji - analyza aktualni dokumentace - pozorovani, rutina zamestnancu samozrejma, nazornejsi nez popis - prototypovani - simulace procesu, prototyp GUI, wireframes, screen - brainstorming - dotaznik - pomoci window-flow - screen s pozadavkem/popisem

Answer 10

 Datové konflikty – Hranice pro hlášení nízkého stavu zboží má být 7 nebo 10?  Zájmové konflikty – Vysoká kvalita nebo rychlé dodání?  Hodnotové konflikty – „Já nehodlám podporovat vývoj SW pro klonování.“  Vztahové konflikty – „Ten už mne jednou pomluvil u šéfky, takže s ním já nic řešit nehodlám“  Strukturální/hierarchické konflikty – Ostych projevit názor před vyšším managementem.

Answer 11

Hlavni ukoly po prvnim sberu: 1. Dokumentace 2. Kategorizace 3. Definice predpokladu a omezeni 4. Prioritizace Kategorie: 1. Funkcni pozadavek - definuji, co system bude umoznovat uzivatelum 2. Kvalitativni pozadavek - user friendly, safety, vykon, udrzba... obence 3. Pozadavky na zavedeni reseni (malo) - docasne pozadavky, po uspesnem zavedeni reseni ztraci smsyl, treba migrace prvotnich dat, zaskoelni atd... Atributy pozadavku: - ID - nazev - popis - kdo vznesl pozadavek - priorita Zpusoby popisu pozadavku 1. Volny text 2. Strukturovany text - hlavne pouzivanej 3. Tabulka 4. Diagram - vzdy nutno dodrzovat jednotny styl firmy

Answer 12

1. Používejte strukturovaný text! 2. Vždy popisujte pouze jediný požadavek! 3. Vyhněte se souvětím! 4. Používejte terminologii srozumitelnou všem, kteří s požadavkem budou jakkoliv pracovat! 5. Nepoužívejte trpný rod! 6. Nepoužívejte obvyklá podstatná jména bez uvedení kontextu! 7. Ověřujte platnost formulací s univerzálními kvantifikátory (nikdo, všichni, vždy, nikdy, veškeré,…)! 8. Řešte CO a nikoliv JAK! 9. Používejte šablony! Vzdy popis jednoho pozadavku, jakmile dve akce - rozdelit Sablona pro business pozadavek: Jako , potřebuji , protože BR 235 Jako uživatel, potřebuji abych byl při vypínání aplikace upozorněn na případné neuložené záznamy, protože se tím předejde opakovanému a časově náročnému zadávání záznamů. Na to navazujici sablona funkcniho pozadavku: Systém bude umožňovat () () () . FR 2 Upozorneni na neulozene zaznamy – Systém upozorni uzivatele na neulozene zaznamy pokud vypne apliakci... CHYBY Superlativům – Systém umožní nejjednodušší správu faktur.  Subjektivním popisům – Proces řízení nákupu bude efektivní.  Nekonkrétním zájmenům – V příštím roce to ušetří 20% nákladů.  Nejednoznačným přídavným jménům a příslovcím – Proces reklamací bude většinou řešen přes on-line rozhraní  Otevřeným, neověřitelným termínům – Systém poskytne podporu mzdovému oddělení, ale nejen jemu.  (Vágním) porovnáním – Nový systém bude kvalitnější než stávající.  “Zadním dvířkám” – Pokud to bude možné, tak proces reklamací bude o 30% rychlejší.  Nekompletním odkazům a definicím

Answer 13

Vyjadruje kdo bude jakym zpusobem pouzivat IT system - uzivatele (role) a jejich prava (moznosti) - cilem je stanovit vsechny hranice a moznosti IT systemu z pohledu vsech rol - tedy co se muze vsechno provest v systemu - vizualizuje Funkcni pozadavky, tedy - sber pozadavku, stanoveni business cilu, business pozadavku, na to vytvoreni funkcnich pozadavku, podle nich tvorba UC diagramu - prispiva k prehlednosti - podklad pro dokumentaci a testovani - abstrahuje konkretni procesy v ramci jednoho pripadu - dekomponuje problem Bubliny jsou vzdy aktivity umozene systeme nejakemu akterovi, tedy ptam se vzdy "Co SYSTÉM umožňuje uživateli" - prihlasit se, zadat objednavku, zaplatit... - vzdy slovesna vazba - kazdy priprad uziti popisuje nejakou CRUD operaci Akterem/roli muze byt i cas, kdy mame nejakou casovanou udalosti - odeslani notifikace... Akteri muzou klasicky dedit pomoci sipky, abych neopakvoal hrany Kazdy priapd uziti muzeme vnitrne popsat, s varianty pruchody, preconditions, posloupnosti aktivit a postconditions: UC 112 – Přihlášení uživatele do systému 1. Systém zobrazí přihlašovací formulář (FRM. 26_Login frame) včetně CAPTCHA. 2. Uživatel vyplní požadované údaje a potvrdí je. 3. IF Systém ověří správnost vyplněných údajů THEN zobrazí všechny role (FRM.27_Role offer), které má uživatel v systému na výběr ELSE … 4. Uživatel vybere jednu z nabízených rolí. 5. Systém ... Vzdy sablone: system zobrazi, uzivatel udela, system ... Scenar se muze menit, mame hlavni scenar, alternatini, vyjimecny, vetvime pomoci basic if statmentu muzeme udealat for loop <> obsahuje v sobe schovany use-case, je to vyjmuti stale opakujicich se korku aby se predeslo duplicite textu - tedy mame aktivitu A, ktera <> aktivitu B, tzn aktivita B se provede vzdy kdyz se provede aktivita A, je to mnozina operaci ktera se vzdy vykona po nejakem use casu - treba kontrola prihlaseni uzivatele <> - je doplnujici moznost, ktrea ma smysl pouze pri provedeni hlavni akce ale ne samostatne - treba editace stranky <> zobrazenim nahledu - tzn ze sobrazit nahled upravovane stranky muzu pouze behem editace, jinak to nedava smysl, je to rozsirujici moznost Chyby - vagni pojmenovani, popis navigace v systemu (scenar zacina uz po navigaci, tedy jsem na miste kde je potreba)

Answer 14

Je propracovanejsi business domain model - tedy je doplnen o implementacni specifikace jako typy, parametry, funkce, atributy... Business domenovy model - prvotni napad diagram entity bez detailu Analityicky - detailnejsi, implementacne specificky Z nej muzu generovat uz tabulky v databazich atd... Musi se definovat atributym typy, nasobnosti vazeb

Answer 15

Je obycejne dedeni Generalizace je od potomku k predku Specializace je do predka k potomkum Abstraktni trida a abstraktni emtody stejne jako v Jave Interface stejne jako v Jave - lizatkove rozhrani - co poskytuju a co prijimam

Answer 16

Slouzi k modelovani zivotniho cyklu entit - ma zacatek - konec (nemusi byt vzdy) - stavy - prechody mezi stav Hrana prechodu je definovana jako: Trigger [Guard] / Effect, - tedy popis udalosti, podminky a akce Treba: Svobodny -> svtba [>16let]/vymena dokladu -> zenaty -> rozvod -> rozvedeny... Tedy prechody muzou ale nemusi mit popisy

Answer 17

Příklad: Cena (produktu, služby,..) není pouze statická hodnota, která zůstává stejná po celou dobu života objektu. Může se měnit v průběhu času z různých důvodů, jako jsou například tržní trendy, nabídka/poptávka, konkurence…. Proto je nezbytné ukládat informace o cenách společně s časovou platností Smyslem je nedavat tento promenlivy atribut jako atribut classy, ale misto toho zalozit uplne novou entitu _Price, na kterou navazu puvodni product: SPATNE: class: Product attribute: price DOBRE class Product vazba has -> ProductPriceHistory 0..N class ProductPriceHistory - price - valid from - valid to 1..1 product

Answer 18

Item Pattern je návrhový vzor používaný pro modelování situací, kdy každý kus produktu může být sledován jednotlivě – například má unikátní sériové číslo. Tento vzor se často používá ve skladech, kde potřebujeme přesně vědět, kolik kusů máme, kde přesně jsou, a jaké mají vlastnosti. 🧠 Pochopení na konkrétním příkladu Představ si, že máš e-shop s elektronikou a provozuješ více skladů (např. v Praze a Brně). Prodáváš různé produkty – např.: USB kabely (levné, nezajímá tě, který kus přesně prodáš) Notebooky (drahé, každý má unikátní sériové číslo) 💡 Potřebujeme řešit: Kolik kabelů a notebooků máme ve skladu v Praze? Má konkrétní notebook se sériovým číslem XYZ ještě někde skladem? Při prodeji kabelu neřešíme konkrétní kus, ale u notebooku ano. [Eshop] | | 1..* [Warehouse] (název, adresa) | | M:N (skladuje produkty) [StockItem] -------------------- [Product] (count, optional items) (název, cena, ...) | | 1..* (jen u drahých) [Item] (serialNumber) Takze kdyz rozkliknu nejaky zbozi v eshopu a vidim "skladem 12ks" - tak to je presne ten "abstraktni" StockItem, ktery realne neexistuje, ale sklada se z konkretniho Productu a v pripade ze chci k tomu pridat treba seriove cislo, tak se sklada i z Itemu Smyslem je oddelit "drahe" atributy od primo classy Product (treba seriove cislo, ktere je potreba pouze v pripade treba prodeje drahych Notebooku), to oddeleni provedu zavedenim nove ineityt ProductItem - ktery mi ukazuje KONKRETNI JEDEN kus tohoto produktu, do ktereho uz jako atribut vlozim seriove cislo. Toto mi predejde situaci, ze bych musel davat seriove cislo do vsech produktu, treba i kabelu a kazdeho hrebiku. Potom "SkladnenyProdukt" neni nejaka konkretni instance, ale pouze abstraktni zasoba tohoto zbozi na skladech, ktere ale odkazuje na konkretni Product a treba i na KONKRETNI instanci draheho produktu ProductItem

Answer 19

Popisuje logickou architekturu systemu z vyssiho domenoveho pohledu na jednotlive subsystemy - tedy kouka seshora na cely system a zabaluje jednotlive domeny do jedne komponenty a neresi jeji vnitrni reprezentaci - logicke oddeleni chovani kompopnent/subsystemu naseho systemu - komponenty komunikuji rozhranmi - lizatka, ktere poskytuju, nebo prijimam - je to black-box ktery mi pskytuje nejake chovani a komponenta je nahraditelna pokud poskytuje pozadovane chovani komponena v sobe zabalje klidne i dalsi komponenty - je to abstraktni pohled zaobaleny Svuj system tedy muzu zakreslit jako jednu velkou krabici, ve ktere mam vnitrni komponenty - jako servisy treba, nebo logicke oblasti, nebo kontroly. Nas system poskytuje navenek nejake rozhrani na Portu a na jinem portu naopak pozaduje rozhrani. Tak nas sytem muzeme jako puzzle dosazovat do jinych systemu. V ramci systemu se deleguji zpravy - na portu prijde nejaka udalost, ta se dleguje do komponenty A, ktera ale treba potrebuje provest mezivypocet/kontrolu/platbu v komponente B, vysledek se pak vraci do A a deleguje se do komponenty C, ktera provede posledni fazi a deleguje zpravu a vys;edek ven pres rozhrani a pres Port mimo nas system Artefakt - fyzicky projev jedne ci vice komponent - treba RestSysServer.jar - treba basic jarko ktere mi zabaluje nekolik funkcionalit v ramci jedne komponenty

Answer 20

 kladou důraz na časové hledisko  ukazují  kdo (instance tříd) se podílí na realizaci  jaké zprávy a s jakými parametry si objekty vyměňují  v jakém pořadí Graficky znazornuje akci uzivatele, jak se provolavaji, na jake hladiny a hloubky, kdo koho vola a s jakymi parametry, co se vraci jako navratova hodnota Treba editace zaznamu -> fetch, update, save... pres vsech 7 vrstev Posilaji se zpravy: - synchronni (cekam na odpoved) -> tucne sipka - asynchronni (necekam) -> jednoducha sipka - navrat <--- - konstrukce a destrukce cile Na svislych osach jsou "obdelinky" ktere ukazuji dobu zitovnosti entity, respektive dobu cekani na zpracovani, tedy komunikace a cekani probiha v ramci zivotnsoti obdelniku, jakmile je odeslana return tak obdelnik zmizi a tim se dana entita vzda prace Je mozne i posilani zprav sam sobe -> vyvola to vnitrni akci (vnitrni obdelnik), pak je i navrfatova hodnota sama sobe, treba delete na nejnizsi vrstve ze sebe treba ze zaznamu odstrani polozku Muze dochazet k podminkam/vetvenim/smyckam - opt - obycejny if, then pripad, tedy si vyrhadim oblast, ktera se provede pouze pokud je splnena podminka, tedy jeden boxik - alt - switch case - vice pripadu za sebou, vice boxiku - loop - min, max, podminka, tedy opakuje to akci max-krat pokud je splnena podminka - break - dalsi casti jsou preskoceny - ref - odkaz na jinou proceduru

Answer 21

* popisuje:  HW architekturu systému  nasazení SW na HW * základním elementem je UZEL (NODE) * základní vazbou je ASOCIACE (ASSOCIATION) Tedy jako uml class diagram zakresluje realne fyzicke entity - tablety, tiskarrnu, router, usb, mobily... - plus jako hrany jsou popisy pripojeni - LAN, Wifi, usb, bluetooth... - je to citelnejsi pro cloveka - nebo se modeluje poradne pres UML diagram, kde uvedu nasobnosti, misto opakovani obrazku konkretnich Konkretni nasazeni - instance uzlu -> k jmenum pridam :server, :router... Muzu delat i diagram nasazeni apliakce do mobilu - spustitelny .exe - je v ramci executional env na androidu - je v ramci android mobile phone <> neboli .app --> runs on execEnv Android --> deployed on Androidn Mobile Phone Tato to muzu skladat jako puzzle - treba tento <> mobil se muze pres Wifi pripojovat k <> Restaurant Server, tento server ma v sobe uz zabalene nejake ipady, tiskarny atd...

Answer 22

Waterfall - analysis - desing - implementation - testing - deploy - maintanance Silné stránky? - Už od začátku je jasný plán => víme co bude - snadné řízení zdrojů (paralelismus projektů) - Zvládne to i začátečník/průměrný zaměstnanec (rozdíl oproti agilním) - Není třeba aby tým byl na jednom místě – analýza u nás, implementace v Malajsii; dá se snadno předat externímu dodavateli Slabé stránky? - Špatně reaguje na změnu - Stojí hodně peněz – veškeré chyby se projeví až při předání (akceptačním testu) a pak je drahé chyby opravit - Dlouho trvá než zákazník vidí nějaký výstup - Vyžaduje detailní plán a specifikaci – každé přeplánování je drahé - Sleduje procesy, které není možné změnit - Není zaměřen na přínos klientovi – je zaměřen na dodání v nějaký čas – dodání podle specifikace není často totožné s tím co zákazníkovi pomůže – potřeby vs.přání

Answer 23

1. Clovek a komunikace je nad procesy a nastroje 2. Fungujici SW je nad vycerpavajici dokumentaci 3. Spoluprace se zakaznikem je nad presnou smlouvou 4. Rekace na zmenu je nad presne dodrzeni planu Tedy se klade duraz na komunikaci nez na procesy a pouzite nastroje - dodani fungujiciho SW je dulezitejsi nez dukladna dokumentace - plan se muze v prubehu menit pri komunikaci se zakaznikem nebo zmenou prichozi

Answer 24

- projekt ma iterace - planovani je zamreno na caste releasy - tym ma vlastni pracovni prostor v ramci projektu - ranni stand up meeting - report sleduje rychlost projektu - popis funkce pomoci user stories Brainstorming s tabuli - refactoring by nemel ovlivnovat chovani programu, duklad na cistotu a srozumitelnost kodu - dokuemtnace se vytvari az zpetne reverse engineeringem - male a caste releasy parove programovani ve vice lidech * Návrh je jednoduchý * Použití metafor k popisu funkcí * Vydávání malých verzí * Zaměření na okamžitou přidanou hodnotu * Refactoring * Udržitelné tempo * Zákazník je vždy k dispozici * Coding standards * Test driven development * Pair programming * Continuous integration * Sdílený kód * Pro každý kód existuje unit test * Před každým release musí projít všechny testy * Pokud je objeven bug => je napsán unit a akceptační test * Akceptační testy probíhají často a jejich úspěšnost je zveřejňována

Answer 25

* Vize * Týmový práce & spolupráce * Jednoduchá pravidla * Sdílení informací * Lehké řízení * Učení se * Zkušení programátoři * Očekává se hodně změn * Malý tým * Zkušené programátory * Někoho s předchozí zkušeností s Agile * Komunikační schopnosti Nedoporucuje se: * Velké programátorské týmy * Dislokované týmy * Nutnost fixace projektového trojúhelníku Problemy * Aplikace jen některých doporučení * Nepřítomnost zákazníka * Spoléhá na ústní podání * Přečtení knížky ≠ zavedení do praxe * Malý důraz na architekturu v počátečních fázích

Answer 26

Agilni rozsireny pristup vyvoje SW, ktery se zameruje na tzv sprinty 1-4 tydenni, v ramci kterych se ma vyrobit inkrement do fungujici aplikace. - je to agilni metodia tymu, ktery se vzdy jednorazove sejde, prodiskutuje cile a vsichni se vrhnou na realizaci„Tým je samoorganizovaný – po Sprint planningu si sám zvolí, jakým způsobem dosáhne cíle sprintu, bez přímého řízení zvnějšku.“ - je v tom zapojeny zakaznik - iteracne-inkrementacni metoda - odolna a pripravena na zmeny - je potreba jista urovne a zkusenosti programatoru a tymu Role: - product owner - predstavitel vsech stakehoalderu, zavadi napady a funkcionality co se ma pridat - scrum master - zajišťuje, že tým správně používá Scrum, odstraňuje překážky a chrání tým před vnějšími rušivými vlivy. Není to manažer, ale spíš pomocník a strážce metodiky - samotny tym Burndown graf - „Burndown graf zobrazuje zbývající práci (např. ve story pointech nebo hodinách) během sprintu – ideálně by měla klesat k nule ke konci sprintu.“ Ceremonie: - Sprint planning - denni scrum - retro scrum Zakladni SCRUM flow: 1. Product backlog 2. Sprint Planning 3. Sprint Backlog 4. Sprint 5. Inkrement 6. Retrospective 1. Na zacatku je Product Backlog: - sem Product owner zapisuje pozadavky na system - pozadavky se tematicky rozdeli na domeny jako "prihlasovani", "sprava uctu", "platby"... - pozadavky se strukturuji do sablony "Jako _ chci _ abych _" - je to neco jako TODO list celkovy, ktery se postupne updatuje a upravuje, doladuje, analyzuje... 2. Potom v ramci zacatku Sprintu se provede Planning - stanovi se priorita Product Backlogu pozadavku - z nej se vybere nekolik pozadavku a prida se do planu - tento Plan se nazyva Sprint Backlog - jako TODO list ale ne globalni, nybrz je to TODO list daneho Sprintu jednoho, v nem se uchovavaji i veci, ktere se nestihly pred tim a dodelavaji se 3. Jakmile se stanovi plan, tak zacne samotny Sprint - vsichni zacnou pracovat na pozadavcich ze Sprint Backlogu - denni meeting - reseni problemu - pristupy, omezeni, konflikty, dotazovani, plan na dnes, co bylo udelano, co chybi... - je v tom vbudovany mikro-watefrall - analyza pozadavku, navrh, implementace, testovani, nasazeni... 4. Jakmile je Sprint u konce, tak se definuje hotovy inkrement: - definice muze byt ruzna, musi se dohodnout s Product Ownerem, zda tento realease neco vyda, respektive jestli vubec bud - vystupem je inkrement - release male hotove casti do fungujici apliakce - nebo nic 5. Pote se provede retrospektivni zhodnoceni pohledu zpet na cely sprint - zhodnoti se, co se povedlo, co by chtelo vylepsit, jake nastaly konflikty - co potrebuje specifiakaci, stiznosti, uprava Spring Backlogu na dalsi Sprint - update Burndown Grafu 6. Zacina novy Sprint Planning znovu...

Answer 27

Agilní metodiky vývoje softwaru byly zavedeny jako reakce na problémy tradičních (vodopádových) přístupů, které se ukázaly jako neefektivní v dynamickém a rychle se měnícím prostředí softwarového vývoje. 🔧 Proč byly agilní metodiky zavedeny? 1. ❌ Nespokojenost s tradičním (vodopádovým) modelem Vývoj podle vodopádu (Waterfall) probíhá ve striktních fázích: analýza → návrh → implementace → testování → nasazení. Změny v požadavcích byly těžko proveditelné nebo velmi drahé. Zákazník často produkt viděl až na konci, což vedlo k tomu, že výsledný software neodpovídal očekávání. Projekty byly často předražené, opožděné nebo zcela selhaly. 2. 📈 Zvýšené nároky trhu Zákazníci chtěli výsledky rychleji a možnost reagovat na změny během vývoje. Trh softwaru je velmi dynamický – firmy potřebují schopnost rychlé inovace a přizpůsobení se konkurenci. 3. 🤝 Potřeba lepší spolupráce a komunikace Tradiční přístup odděluje zákazníka od týmu → vede ke komunikačním šumům. Agilní přístup zdůrazňuje těsnou spolupráci se zákazníkem a mezi členy týmu. 4. 🔄 Potřeba iterativního a inkrementálního vývoje Místo toho, aby se čekalo měsíce na finální produkt, agilní týmy dodávají software po menších částech (inkrementech). To umožňuje rychlou zpětnou vazbu, zlepšování a přizpůsobení aktuálním požadavkům. ✅ Přínosy agilního přístupu Tradiční přístup Agilní přístup Dlouhé fáze bez výsledku Krátké cykly s viditelným pokrokem Slabá zpětná vazba Pravidelná zpětná vazba Těžko reaguje na změny Změny jsou vítány Zákazník vidí výsledek pozdě Zákazník je zapojen průběžně 💬 Shrnutí Agilní metodiky vznikly, aby řešily praktické problémy: neschopnost reagovat na změny, pomalý vývoj, nízká kvalita výsledků, slabá komunikace se zákazníkem. Díky iterativnímu, přizpůsobivému a týmovému přístupu dnes patří mezi nejpoužívanější přístupy ve vývoji softwaru

Answer 28

Pristup, kdy vyvojarsky tym dela celou praci - tedy neni tym specializovanej na test, na integraci, na deploy, na udrzu atd... - o vsechno se stara autor systemu - plan, code, build, test, release, deploy, operate, monitor, feedback smycka Developments and Operations GitOps - pristup, kdy OneTruthPlace je Git a cely vyvoj je odvijenej od Gitu

Answer 29

Jsou to modely poskytování služeb v cloudu (Cloud Service Models). Liší se v tom, kolik věcí spravuje poskytovatel (např. Microsoft, Google, Amazon) a kolik věcí si spravuješ ty sám. Představ si to jako pronájem různých úrovní výpočetního prostředí: Model Co si spravuješ sám? Co za tebe spravuje poskytovatel? IaaS OS, runtime, aplikace Hardware, virtualizace, síť, úložiště PaaS Jen aplikaci OS, runtime, databáze, škálování, prostředí… SaaS Nic – jen používáš Celou aplikaci i infrastrukturu 1️⃣ IaaS – Infrastructure as a Service = pronájem "holé" infrastruktury (virtuálních serverů) Poskytovatel ti dá virtuální počítače (VM), disky, sítě, firewally, ale o zbytek se staráš ty. Musíš si nainstalovat operační systém, runtime (např. Javu, Node.js) a vlastní aplikace. Máš plnou kontrolu, ale také plnou odpovědnost. 🛠 Příklady: Microsoft Azure – Virtual Machines Amazon AWS – EC2 (Elastic Compute Cloud) Google Cloud – Compute Engine 🎯 Reálný scénář: Firma potřebuje spustit vlastní ERP systém, který je náročný na konfiguraci. Spustí si vlastní virtuální servery, instaluje si databázi, nastavuje síťové porty atd. 2️⃣ PaaS – Platform as a Service = pronájem vývojové platformy bez starostí o OS a hardware Poskytovatel ti připraví platformu, kde můžeš jen nahrát aplikaci a on se postará o běhové prostředí. Ty se soustředíš jen na kód a data, nestaráš se o servery, škálování, aktualizace OS apod. 🛠 Příklady: Google App Engine Heroku Azure App Services AWS Elastic Beanstalk 🎯 Reálný scénář: Vývojář vytvoří webovou aplikaci v Node.js a nasadí ji na Heroku – ten se postará o servery, aktualizace, škálování podle návštěvnosti 3️⃣ SaaS – Software as a Service = hotová aplikace dostupná přes internet Nepotřebuješ nic instalovat, vše běží v cloudu. Používáš hotovou službu – přihlásíš se a funguješ. Nevlastníš žádnou infrastrukturu ani platformu, jen konzumuješ službu. 🛠 Příklady: Google Workspace (Gmail, Docs, Drive) Microsoft 365 (Word, Excel, Teams) Dropbox Salesforce Zoom 🎯 Reálný scénář: Přihlásíš se do Gmailu a posíláš e-maily. Nepotřebuješ řešit servery, spam filtry, ani aktualizace – o vše se stará Google. 🧱 Vztah mezi nimi – vrstvy služeb: Představ si to jako stavění domu: Model Příklad ze stavby Co máš ty IaaS Holý pozemek s infrastrukturou (voda, elektřina) Postavíš dům sám PaaS Hrubá stavba s elektřinou a odpady Jen zařídíš interiér SaaS Hotový dům na klíč Jen se nastěhuješ a bydlíš 📊 Shrnutí tabulkou Model Spravuješ sám Používáš Typický uživatel IaaS OS, software Servery Systémový administrátor PaaS Aplikaci Platformu Vývojář SaaS Nic Aplikaci Koncový uživatel 💬 Shrnutí větou: IaaS: „Potřebuji infrastrukturu – chci si vše řídit sám.“ PaaS: „Chci jen psát kód, o zbytek ať se stará někdo jiný.“ SaaS: „Chci hotovou aplikaci, hlavně ať to funguje.“

Answer 30

🟩 Flash karta 1: Co je JavaBean? Jak vypadá a k čemu se používá? Definice: JavaBean je speciální typ třídy v Javě určený pro znovupoužitelné softwarové komponenty. Vlastnosti JavaBeanu: Má bezparametrový konstruktor. Implementuje Serializable pro podporu perzistence (uložení a načtení stavu). Používá veřejné getter a setter metody pro přístup k vlastnostem (podle konvencí getX() / setX()). Nepotřebuje implementovat žádné speciální rozhraní. Využití: Práce s formuláři, databází, UI komponentami. Používá se v frameworkách jako JSP, JSF nebo Spring. Snadná introspekce (IDE a nástroje automaticky zjistí vlastnosti objektu). 🟨 Flash karta 2: Co je Bound Property (vázaná vlastnost)? Definice: Vázaná vlastnost (bound property) je vlastnost JavaBeanu, která informuje registrované posluchače, když se její hodnota změní. Mechanismus: Bean obsahuje metody: addPropertyChangeListener(...) removePropertyChangeListener(...) Při změně vlastnosti se zavolá: firePropertyChange(...) → odešle PropertyChangeEvent posluchačům. Použití: Umožňuje například automatickou aktualizaci UI, pokud se změní hodnota vlastnosti. 🟥 Flash karta 3: Co je Constrained Property (omezená vlastnost)? Definice: Omezená vlastnost (constrained property) je vázaná vlastnost, která před provedením změny umožňuje posluchačům změnu vetovat (zamítnout). Mechanismus: Bean obsahuje metody: addVetoableChangeListener(...) removeVetoableChangeListener(...) Před změnou se zavolá: fireVetoableChange(...) Pokud některý posluchač vyhodí PropertyVetoException, změna se neprovede. Použití: Validace změn – např. zabránění nastavení neplatné hodnoty (např. záporný zůstatek na účtu).

Answer 31

GRASP (General Responsibility Assignment Software Patterns) jsou principy a vzory pro návrh objektově orientovaného softwaru, které pomáhají určit, která třída by měla mít jakou zodpovědnost. GRASP není framework ani knihovna, ale sada návrhových pravidel, která vedou k čistému, udržitelnému a znovupoužitelnému kódu. Pomoci návrhářům rozhodnout, kde a jak rozmístit zodpovědnosti mezi objekty ve třídách, aby byl systém dobře strukturovaný. Princip GRASPU: 1. Information expert - prirad zodpovednsot tomu objektu, ktery ma vsechny potrebne informace pro vypocet 2. Creator - objekt A vytvori objekt B iff ho bude realne potrebovat 3. Controller 4. Low couplig - nezavisle komponenty 5. Hight Cohesion - souvisejici odpovednosti vedle 6. Polymorfismus 7. Pure Fabrication - artifical klass jako DAO, podpora single responsibility 8. Indirection - vloz zprostredkujici objekt mezi dvema komunikujicimi objekty - nizsi zavislost 9. Protected Varaitions - abstrakce a rozhrani jako bezpecnost proti zmenam

Answer 32

Velky, komplexni software, ktery neslouzi jen pro maly zakladni business pozadavek ale velky korporatni business cile - informacni systemy skol, necmocnic - bankovnitvi - booking - eprodej poziva rozsahle databaze - web-servisy - hodne business pravidel - hodne uzivatelu

Answer 33

Tri vrstvy 1. Prezentacni - GUI, JSP, JSF, html, js... 2. Business - model, vnitrni kod, logika, business logika - servisy, DI, patterns... 3. Persistentni - databaze, JPA, DAO - Data Access Object

Answer 34

Mapovani databzovych entit na tridy s atributy a metodami pomoci frameworku a anotaci (Hibernate) - umoznuje specifikovat celou tabulku, columns, constraints jako Key - umoznuje uchovat odkazy na jine atributy pomoci cizich klicu - umoznuje asociace one-to-one, one-many, many-many - umoznuje inheritance - anotace ID

Answer 35

Pattern, ktery pridava mezivrstvu mezi userem a entitou v databazi - je to pomocny objekt, nebo rozhrani pro pristup k entitam persistentni vrstvy - vsechny upravy probihaji pomoci DAO, abych naprimo nekomunikoval s databazi Tedy v db mam tabulku Persons V appce mam tridu Person @Table - ORM Taky mam pomocny PersonDAO - ktery zabaluje pristupy k Person - CRUD operace interface - provolava skrz repository

Answer 36

vrstva mezi DAO a db - provadi vsechny CRUD operace definovane ned DAO objektem - uz ma v sobe hodne implementovanych nadefinovanych SQL dotazu v podobe basic metod v Jave

Answer 37

Uzivatel na webove strance klidne "zalozit noveho cloveka" 0. Odesle se HTTP pozadavek na stanovenou adresu (treba v html je a-ref ".../persons") a v tele pozadavku mam treba JSON informace jako name:..., age:..." 1. Tento pozadavek doputuje na muj REST Controller, ktery hlida tuto adresu. V nem mam specifikovanou metodu, ktera hlida @PostMapping prikaz a jmenuje se treba addPerson. Jako parametr automaticky bere telo HTTP pozadavku jako PersonDTO dto - kde DTO znamena to telo, neboli data transfer object - nosic dat pro entitu Person. 2. Rest PersonController chce pridat novy Person, tak v sobe ma PersonService, kterou zavola 3. Service je vrstva zodpovedna za kontrolu a validaci vstupnich dat, jeste nez zacne samotne business logika. Tedy z prichoziho personDTO se zkontroluje jeho name a age a pokud je vsechno v poradku, tak service vola BO - business object, aby vytvoril uz realnou entitu/tridu Person z prichozich DTO dat 4. PersonBO - realna implementace tridy Person jako business objektu v systemu, ma klasicky promenne, metody atributy atd... oznacuje se jako @Component, aby Spring mohl automaticky vkaldat zavislsti injekci. BO samo nic nedela, ale komunikuje s DAO - pro CRUD operace, tedy zavola PersonDAO.creat() a save. 5. PersonDAO ma v sobe repository, skrz kterou vola uz naimplementovane SQL dotazy, je to dalsi vrstva zabaleni 6. PersonRepository extenduje JpaRepository a ma v sobe vsechny uz default pouzivane metody jako findById, findByName, Group... 7. Repository komunikuje primo s db, do ktere to ulozi Probubla zpetna odezva. Pro pripad "get" pozadavku je obraceny postup az na detaily Controller - prijme DTO a ma Service Service - ma BO BO - ma DAO DAO - ma repository Repository - ma db TOTO cele je zalozeno na GRASPU - je to hierarchie zodpovednosti a predavani zprav a zodpovednych udalosti na jednotlivych vrstvach - hlavnim cilem je low coupling, high cohesion

Answer 38

It states that within a method, messages should only be sent to the following objects: The this object (or self) A parameter of the method An attribute of self An element of a collection which is an attribute of self An object created within the method

Answer 39

Datacentric - architektura postavena na zpracovani a analyze dat, dabataze, kompilatory, voice recognition Call-and-return - oop, procedrual, layers - nase systemy vetsinou - komunikace ruznych entit,z rpavy Virtualni machiny Mikroservisy Event-driven pipeline Client-server

Answer 40

Arch. styl a pattern, kdy mame server a komunikujiciho klienta Vyhody: - centralizace - jednoduche zabezpeceni - jednoduche skalovani - nevyhodou je prodleva serveru - zpomaleni nebo vzdalenost Dispatcher deleguje komunikaci a snazi se o load-balancing

Answer 41

Vertikalni - upgrade serveru Horizontalni - vice serveru Replikace databazi v pripade bottlenecku - data grid? - SOA - servisni pristup

Answer 42

Prostredi, kterym komunikuji servisy a kam si posilaji zpravy, delegace zprav a komunikace servis - je to jako jeden komunikacni kanal, na ktery jsou napojeny vsechny - neco jako PCI

SIN Flashcards

(66 cards)