Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

--- courses:a4m33sep [2013/01/02 11:26]
matllubos
+++ courses:a4m33sep [2025/01/03 18:23] (aktuální)
@@ Řádek 33: / Řádek 33: @@
 ===== Časté otázky =====
-  * Přikládám odkaz na mé [[courses/a4m33sep/notes|poznámky]] z přednášek. Společně se slidy to stačí na naučení na A. Za případné chybky neručím (prosím případně někdo doplňte, opravte
+  * Přikládám odkaz na mé [[courses/a4m33sep/notes|poznámky]] z přednášek. Společně se slidy to stačí na naučení na A. Za případné chybky neručím (prosím případně někdo doplňte, opravte  §
-  * Co je to bod LCO, LCA, IOC + dopad na plán projektu?
-**LCO - Life Cycle of Objectives : Víme, co zákazník chce
-LCA - Life Cycle of Architecture : Víme, co jak budeme dělat
-IOC - Initial Operation Capacity: Je hotovo a nasazeno**
-  * Programování zabírá 20% – 40% nákladů (v člověkodních) na projekt. Jaké činnosti spotřebovávají zbytek? Které z nich jsou primární a které podpůrné? V jakém poměru jsou tyto dvě kategorie?
-**10-20% testy ; 10% dokumentace ; 20% analýza ; 10% Project Management. Primární jsou: vývoj, testy a analýza. Podpůrné jsou dokumentace a ProjectManagement. Poměr 70:30 cca**
-  * Podle čeho se dá strukturovat SRS? (Myšleno takové to XXX-centric)
-** SRS =  software requirements specification; Dá se strukturovat podle Data-Centric, Function-Centric, Feature-Centric, Use case-Centric, Aspect-Centric, Architecture-Centric**
-  * Co je model GUI, k čemu slouží a v čem se dá udělat?
-** Model, který předvedema zákazníkovi, jak bude aplikace udělat. Není naimplementovaná logika, jde pouze o rozvržení GUI. Naimplementovat se dá např v: HTML, klikací pdf, power point. Je dobré, aby se dal znovu použít, nebo alespoň nějak převést potom na aplikaci.**
-  * Co je to architektura a jaký má vztah se SRS?
-** Architektura popisuje nefunkční požadavky aplikace. Jsou v tom programovací paradigmata, architektonické styly, principy, standardy. Měla by být přesná a pochopitelná. Měla by být popsaná v SRS. Architecture-style SRS je často používaná. **
-  * Popište čtyři základní pohledy na architekturu. (Takový ten obrázek se scénáři uprostřed.)
-** Software Architecture ; Business process architecture - obchodní strategie, řízení, organizace, obchodní procesy ; Information technology (system) architecture - HW a SW infrastruktura nutná pro chod
-organizace ; Information architecture - organizace dat **
-** Dle mého není správně. Správně je (uvedu analogii s UML diagramy): **
-  - ** Logical view - Class, Sequence diagram **
+** Co je to bod LCO, LCA, IOC + dopad na plán projektu? **
-  - ** Development view - Component, Package diagram **
-  - ** Process view - Activity diagram **
+ Jsou to milníky vyskytující se během fází vývoje SW
-  - ** Phisical view - Activity diagram **
-  - ** Scenarios - Use-case**
+ * LCO (Live cycle objectives)
-  * Napište atributy testů a co znamenají. (Chtěl tak čtyři.)
+   * Víme co zákazník chce (víme co máme dělat)
+   * máme stanoven cíl (shoda na vizi se zákazníkem, rozpočtu, nákladech, identifikace rizik)
+ * LCA (Live cycle architecture/activities)
+   * Víme jak to máme udělat
+   * stanovena architektura, stabilní vize, definovány plány a odhady
+ * IOC (Initial operation capability)
+   * Máme nasazenou beta verzi produktu u zákazníka
+   * první build, následuje údržba
+** Programování zabírá 20% – 40% nákladů (v člověkodních) na projekt. Jaké činnosti spotřebovávají zbytek? Které z nich jsou primární a které podpůrné? V jakém poměru jsou tyto dvě kategorie? **
+ * Hlavní:
+   * Analýza 10-30%
+   * Návrh   15%
+   * Implementace 30-40%
+   * Testování 10-20%
+ * Podpůrné
+   * Dokumentace 10 %
+   * Projektové řízení 5 %
+   * CM 5 %
+ * Hlavní x Podpůrné - 70:30%
+** Podle čeho se dá strukturovat SRS? (Myšleno takové to XXX-centric) **
+ * Časté:
+   * Feature centric - do LCA
+   * Architecture centric - během vývoje
+   * Change request centric - během údržby (po IOC)
+ * Méně časté
+   * Data centric
+   * Aspect centric
+   * Function centric
+   * Use-case centric
+** Co je model GUI, k čemu slouží a v čem se dá udělat? **
+je to vlastně prototyp UI
+slouží k:
+  * komunikace se zákazníkem
+  * částečnou validaci požadavků (a jejich zpřesnění)
+  * pomáhá pochopení systému
+  * vhodný jako součást specifikace
+  * lze použít jako grafický návrh pro skutečný produkt
+v čem udělat:
+  * HTML
+  * Excel, Power point
+  * Klikací pdf
+  * speciální nástroje
+** Co je to architektura a jaký má vztah se SRS? **
+možné definice, architektura je:
+  * Komponenty a vazby
+  * Celková struktura systému a její dokumentace
+  * Diagram struktury systému
+Definice struktury systému, strukturu tvoří komponenty, ze kterých se systém skládá. Z vnějšku viditelné vlastnosti těchto komponent a vztahy mezi nimi
-   - ** Power : vysoká pravděpodobnost nalezení problému, pokud existuje **
+vztah se SRS:
-  - ** Valid : odhalí skutečné chyby **
+  * realizuje nefunkční požadavky ze SRS
-  - ** Value : odhalí chyby důležité pr  - uživatele **
+  * je nutné architekturu plánovat co nejdřív, protože jinak můžeme zjistit, že je nemožné požadavky SRS splnit (nebo špatně odhadneme cenu)
-  - ** Credible : odpovídá očekávanému chování uživatele **
-  - ** Representative : odpovídá tomu, čeh  - si uživatel nejpravděpodobněji všimne **
-  - ** Non-redundant : reprezentuje skupinu testů, které se zaměřují na stejné riziko **
-  - ** Motivating : „klient“ bude chtít chyby nalezené testem opravit **
-  - ** Performable : proveditelný v souladu s návrhem **
-  - ** Maintainable : udržovatelný při změnách systému **
-  - ** Repeatable : snadný  - a levně znovupoužitelný **
-  - ** Pop (Karl Popper) : odhalí věci týkající se základních či kritických předpokladů **
-  - ** Coverage : vyzkouší systém způsobem, kterým t  - nečiní jiné testy **
-  - ** Easy t  - evaluate : snadné a jasné vyhodnocení **
-  - ** Appropriately complex : dostatečná komplexnost **
-  - ** Accountable : obhajitelnost, prokazatelnost testu **
-  - ** Supports troubleshooting : poskytuje užitečné informace k ladění nalezených problémů **
-  - ** Cost : přímé náklady, čas a pracnost **
-  - ** Opportunity cost : náklady, které se ušetří provedením testu **
-  * Na jaké základní části se dělí dokumentace, jaké obsahují podkategorie? Napište příklady v kategoriích. (2 hlavní a u každé 2 podkategorie + příklad)
+** Popište čtyři základní pohledy na architekturu. (Takový ten obrázek se scénáři uprostřed.) **
-  - ** Dokumentace požadavků – Prohlášení, která identifikují atributy, schopnosti, vlastnosti nebo vlastnosti systému. Tvoří základ pro to, co bylo nebo bude realizováno. **
-  - ** Dokumentace architektury/designu – Přehled softwaru. Zahrnuje vztahy k prostředí a stavebním základům, které budou použity v návrhu softwarových komponent. **
-  - ** Technická dokumentace – Dokumentace kódu, algoritmy, popis rozhraní a API. **
-  - ** Uživatelská dokumentace – Manuály pro koncového uživatele, systémové administrátory a osazenstvo podpory. **
-  - ** Marketingová dokumentace – Jak prodávat produkt a analýza tržní poptávky **
-** Podle otázky by to mělo být takto (příklady si doplní každý sám :) )**
+  * Logical view - Class, Sequence diagram
-  - ** Dokumentace Procesu **
+  * Development view - Component, Package diagram
-    - ** Plány a odhady **
+  * Process view - Activity diagram
-    - ** Zprávy **
+  * Physical view - Diagram nasazení
-    - ** Pracovní dokumenty **
+  * Scenarios - Use-case
-  - ** Dokumentace Produktu **
-    - ** Uživatelská **
-    - ** Vývojářská **
-    - ** Administrační a instalační příručka **
-  * Vysvětlete pojmy „správa verzí“ a „řízení změn“ a řekněte jak souvisí s SVN. Vysvětlete pojmy tag, branch, main trunk. (Bylo tam „řízení změn“ a ne „změnové řízení“, tak nevím.)
+** Napište atributy testů a co znamenají. (Chtěl tak čtyři.) **
-** Správa verzí: zaznamenáva změny v kódu. Kdo, kdy a co udělal. Řízení změn: Jak co a kdy se bude měnit. Je nutné udělat ToDo list, vazbu na specifikaci ... . SVN podporuje správu verzí. Tag : stav nějakého kódu v branchi. Branch: Kopie verze jiné  branche, která se mění nezávisle na původní branch, dokud se nespojí. Main trunk: Hlavní vývojová branch **
-  * Napište osnovu plánu projektu ve které není záměrně nic důležitého vynecháno. (plány jsou obvykle projektu, konfiguračního řízení, testování)
+  - Power : vysoká pravděpodobnost nalezení problému, pokud existuje
-  - ** Initiation and Scope Definition **
+  - Valid : odhalí skutečné chyby
-  - ** Software Project Planning **
+  - Value : odhalí chyby důležité pro uživatele
-  - ** Software Project Enactment **
+  - Credible : odpovídá očekávanému chování uživatele
-  - ** Review and Evaluation **
+  - Representative : odpovídá tomu, čeho si uživatel nejpravděpodobněji všimne
-  - ** Closure **
+  - Non-redundant : reprezentuje skupinu testů, které se zaměřují na stejné riziko
-  - ** Software Engineering Measurement **
+  - Motivating : „klient“ bude chtít chyby nalezené testem opravit
-  * Co je to historie, co obsahuje a proč se dělá?
+  - Performable : proveditelný v souladu s návrhem
-** Záznam změn v projektu. Kde se udělali. Je dobré ji mít v nějakém trakovacím systému provázaného s SVN. Obsahuje: celková pracnost, kalendářní čas, počty lidí, pracnost dle typů činností, kalendářní čas dle typů činností, počty (obrazovky, tabulky, tisky, programy, …), charakteristika systému a agendy, problémy, rizika,vše, co je vhodné uchovat pro budoucnost. Dělá se pro odhady projektů do budoucna, poučení se z chyb z minulosti ... **
+  - Maintainable : udržovatelný při změnách systému
-  * Jaké jsou základní druhy metrik, k čemu jsou?
+  - Repeatable : snadný  - a levně znovupoužitelný
-  - ** time (kalendářní čas):z evidence práce **
+  - Pop (Karl Popper) : odhalí věci týkající se základních či kritických předpokladů
-  - ** size (rozsah):počet řádek kódu, CVSstat **
+  - Coverage : vyzkouší systém způsobem, kterým to nečiní jiné testy
-  - ** effort (pracnost):z evidence práce **
+  - Easy t  - evaluate : snadné a jasné vyhodnocení
-  - ** quality (jakost):Bugzilla, Jira **
+  - Appropriately complex : dostatečná komplexnost
-  * Co je to V-model, k čemu slouží a co znamená?
+  - Accountable : obhajitelnost, prokazatelnost testu
-**V-Model je zjednodušený model, který slouží k pochopení vývoje software, tj. zejména posloupností kroků, které po sobě následují.[[http://upload.wikimedia.org/wikipedia/commons/thumb/e/e8/Systems_Engineering_Process_II.svg/420px-Systems_Engineering_Process_II.svg.png|V-Model]]**
+  - Supports troubleshooting : poskytuje užitečné informace k ladění nalezených problémů
-  * Co je to testovací technika, k čemu slouží?
+  - Cost : přímé náklady, čas a pracnost
-** Testovací technika je recept pro provádění těchto činností s cílem objevit něco, co stojí za reporting. Slouží k nahlášení chyb v SW. **
+  - Opportunity cost : náklady, které se ušetří provedením testu
-  * Popiste zakladni cinnosti Softwaroveho inzenyrstvi. Jakeho jsou typu (primarni, podpurne)? A strucne kazdou charakterizujte.
-** Základní: **
-  - ** Byznys modelování popisující strukturu a dynamiku podniku či organizace.  **
+** Na jaké základní části se dělí dokumentace, jaké obsahují podkategorie? Napište příklady v kategoriích. (2 hlavní a u každé 2 podkategorie + příklad) **
-  - ** Specifikace požadavků definující prostřednictvím specifikace tzv. případů použití softwarového systému jeho funkcionalitu. **
-  - ** Analýza a návrh zaměřené na specifikaci architektury softwarového produktu.  **
+ * Dokumentace Procesu
-  - ** Implementace reprezentující vlastní tvorbu softwaru, testování komponent a jejich integraci. **
+    * Plány a odhady
-  - ** Testování zaměřené na činnosti spjaté s ověřením správnosti řešení softwaru v celé jeho složitosti. **
+      * Plán projektu, QA Plan, CM Plan
-  - ** Rozmístění zabývající se problematikou konfigurace výsledného produktu na cílové počítačové infrastruktuře. **
+    * Zprávy
+      * Výsledky testů, stav práce, atd.
+    * Pracovní dokumenty
+      * Komunikace se zákazníkem i s vlastními členy týmu
+ * Dokumentace Produktu
+    * Uživatelská
+      * Kontextová nápověda
+    * Vývojářská
+      * Kód + komentáře
+      * Kuchařky pro vývojáře
+    * Administrační
+      * administrační manuál
+      * instalační příručka
+      * troubleshooting
+** Vysvětlete pojmy „správa verzí“ a „řízení změn“ a řekněte jak souvisí s SVN. Vysvětlete pojmy tag, branch, main trunk. (Bylo tam „řízení změn“ a ne „změnové řízení“, tak nevím.) **
+  * Správa verzí
+    * identifikace a evidence SW produktu a jeho položek, řízení SW položek a dokumentace
+    * zaznamenáva změny v kódu. Kdo, kdy a co udělal
+  * Řízení změn
+    * identifikace změn, vazba na specifikaci
+    * řízení změn nad sjednaný rozsah
+    * model vývoje v době údržby
+  * Tag - ukazatel na určitou revizi SW (je to vlastně pojmenovaná verze v repozitáři)
+  * Branch - větev verzovacího stromu
+  * Main trunk - hlavní větev (převážně v SVN v gitu je to většinou main i když nemusí)
+** Napište osnovu plánu projektu ve které není záměrně nic důležitého vynecháno. (plány jsou obvykle projektu, konfiguračního řízení, testování) **
+  * Plán projektu
+    * Úvod - účel, rozsa, rozcestník
+    * Východiska a stávající stav
+    * Rozsah - rizika, zahrnuté nezahrnuté aktivity, omezující podmínky
+    * Organizace - odpovědnost, role
+    * Plány - plány, rozklad práce, milníky, harmonogram
+    * Vedení a řízení - QA management, schůzky CM,
+    * Ukončení projektu a akceptační kritéria
+  * Plán CM
+    * Introduction - účel, rozsah
+    * Management
+    * Activities - řízení verzí, řízení změn
+    * Schedules
+    * Resources
+    * Maintenance
+  * Plán testování
+    * Úvod
+    * Co testovat, co netestovat
+    * Přístup a cíle
+    * Artefakty - výstupy testů, logy, reporty, ..
+    * Elementy testu - odpovědnost, plány, zdroje, řízení
+** Co je to historie, co obsahuje a proč se dělá? **
+Data z minulých projektů
+  * rizika, problémy
+  * kdo co dělal
+  * počty lidí, obrazovky
+  * Termíny, pracnost
+  * Kalendářní čas podle typu činnosti, Pracnost podle typu činnosti
+  * charakteristika systému a agend
+Proč (poučení z minulosti, záznam o změnách):
+  * Nabídky (odhady, okrajové problémy, rizika, problémy)
+  * Údržba
+** Jaké jsou základní druhy metrik, k čemu jsou? **
+  - time (kalendářní čas):z evidence práce
+  - size (rozsah, LOC):počet řádek kódu, CVSstat
+  - effort (pracnost, MD, issues):z evidence práce
+  - quality (jakost, počet chyb):Bugzilla, Jira
+** Co je to V-model, k čemu slouží a co znamená? **
+V-Model je zjednodušený model, který slouží k pochopení vývoje software, tj. zejména posloupností kroků, které po sobě následují.[[http://upload.wikimedia.org/wikipedia/commons/thumb/e/e8/Systems_Engineering_Process_II.svg/420px-Systems_Engineering_Process_II.svg.png|V-Model]]
+když píšu požadavky, tak vlastně zároveň definuji akceptační testování, když navrhuji design, tak vlastně definuji integrační a systémové testy, které pak budou testovat požadované vlastnosti atd.
+** Co je to testovací technika, k čemu slouží? **
+Testovací technika je recept pro provádění těchto činností s cílem objevit něco, co stojí za reporting.
+Určuje tedy co by nás mělo zajímat při testování.
+Její výběr záleží na
+  * Požadavcích kladených na testy
+  * Atributů testů
+  * Kontextu vývoje (rizika, kritéria kvality, omezení)
+Př.:
+  * Stress, Users, Functional, Scenario, Domain, Regresní testy
+** Popiste zakladni cinnosti Softwaroveho inzenyrstvi. Jakeho jsou typu (primarni, podpurne)? A strucne kazdou charakterizujte. **
+  * Základní:
+    * Byznys modelování popisující strukturu a dynamiku podniku či organizace.
+    * Specifikace požadavků definující prostřednictvím specifikace tzv. případů použití softwarového systému jeho funkcionalitu.
+    * Analýza a návrh zaměřené na specifikaci architektury softwarového produktu.
+    * Implementace reprezentující vlastní tvorbu softwaru, testování komponent a jejich integraci.
+    * Testování zaměřené na činnosti spjaté s ověřením správnosti řešení softwaru v celé jeho složitosti.
+    * Rozmístění zabývající se problematikou konfigurace výsledného produktu na cílové počítačové infrastruktuře.
-** Podpůrné: **
+  * Podpůrné:
-  - ** Řízení změn a konfigurací zabývající se problematikou správy jednotlivých verzí vytvářených artefaktů odrážejících vývoj změn požadavků kladených na softwarový systém.  **
+    * Řízení změn a konfigurací zabývající se problematikou správy jednotlivých verzí vytvářených artefaktů odrážejících vývoj změn požadavků kladených na softwarový systém.
-  - ** Projektové řízení zahrnující problematiku koordinace pracovníků, zajištění a dodržení rozpočtu, aktivity plánování a kontroly dosažených výsledků.  Nedílnou součástí je tzv. řízení rizik, tedy identifikace problematických situací a jejich řešení.  **
+    * Projektové řízení zahrnující problematiku koordinace pracovníků, zajištění a dodržení rozpočtu, aktivity plánování a kontroly dosažených výsledků.  Nedílnou součástí je tzv. řízení rizik, tedy identifikace problematických situací a jejich řešení.
-  - ** Prostředí a jeho správa je tok činností poskytující vývojové organizaci metodiku, nástroje a infrastrukturu podporující vývojový tým. **
+   * Prostředí a jeho správa je tok činností poskytující vývojové organizaci metodiku, nástroje a infrastrukturu podporující vývojový tým. *
+** Model zivotniho cyklu software/SDLC. K cemu slouzi? Příklady. Souvislost SDLC a primarnich + podpurnych cinnosti SW inzenyrstvi z min.otazky. + Příklady 2 SDLC **
+Určuje kdy se provedou jednotlivé fáze vývoje, na co bude kladen důraz (dokumenty, kód management, diagramy)
+Určují kompromis mezi: Time, cost, scope, quality (agilní mají proměnou cenu a rozsah, běžné pouze čas)
+Typy:
+  * Běžné
+    * Vodopád - hodí se spíše pro údržbu
+  * Agilní (užší vztah se zákazníkem, iterační vývoj)
+    * SCRUM - důraz na management
+    * Extrémní programování - důraz na kód
+** Naroky na specifikaci pozadavku na software / system. Diskutujte naroky na formu, obsah, zpusob pouziti. **
+Forma:
+  * Case nástroje - složité, moc se nepoužívá
+  * Strukturovaný text doplněný diagramy
+  * Izolovaný katalog požadavků - bez hlubší struktury (ne moc optimální)
+  * Viktoriánská novela - špatná specifikace, text bez jakékoli struktury
+obsah má být komplexní má obsahovat pozitivní i negativní vymezení
+požadavky:
+  * funkční
+  * nefunkční
+  * požadavky na rozhraní
+  * jiné
+použití:
+  * vyjednávání o rozsahu
+  * podklad pro testování (kvalifikační, akceptační)
+  * rozhodování co je úprava nad rámec sjednaného rozsahu
+** rozdíl mezi verzí konfigurační jednotky a verzí softwarového díla **
+mám pár názorů, ale počkám zda někdo nenapíše něco rozumného, abych tu nepsal blbosti
+konfigurační jednotka: programy, dbs schema, data, konfigurace
+** Co je architektonicky styl (ve smyslu sw. inzenyrstvi) + priklady. **
+Definice:
+  * Popis typů komponent, vzorů pro kontrolu jejich běhů a datových přenosů
+  * Množina omezení
+  * Definují rodinu architektur, které omezení splňují
+  * Abstrakce pro množinu souvisejících architektur
+př.:
+  * Pipes and filters
+  * Event driven architecture
+  * Layered architecture – interní dekompozice (např. TCP/IP)
+  * Multi-tier architecture – fyzická dekompozice (např. webový server – aplikační server – databáze)
+  * Model-View-Controller (MVC)
+  * Repositories
+  * „Table driven” interpreters
+  * Big ball of mud
+** Kvalifikacni a akceptacni testovani * charakterizovat, popsat rozdily. **
+Kvalifikační - testování dodavatelem, je to výstupní kontrola před dodáním. Kompletní ověření všech systémových funkcí
+Akceptační - testování zákazníkem, před dodáním do produkce. Rozhodnutí zda dodávku přijme
+Rozdíly - podle toho kdo testuje, kvalifikační je také velmi často automatizované (regresní testy)
+** Popiste jake KONKRETNI kroky provedete, pokud chcete rozjet Continuous integration (Smoke testing, night buildy) (+obrázek)?**
+Jenkins, popsat, jak by se co nastavilo, kam s kódem … Prakticky popis toho, co se dělalo na cvikách.
+Nakreslil bych ten obrázek co byl v přednášce, pak jak se nasadí verzovací systém, integrační platforma (Jenkins). Jak se pouští noční build a že je o výsledcích testů někdo informován.
+** Tag a branch, vysvetlete jaky je mezi nimi rozdil. **
+To už tu jednou bylo...
+** Jako projektovy manazer budete zakaznikovi hlasit rizika. Jak pravidelne to budete delat? Co bude obsahem sdeleni? Jakou formou to delat, aby to vubec melo smysl. **
+Tohle jsem nikde nenašel, ale podle toho, jak se to dělá u nás: Rizika se probírají na schůzích, které jsou jednou za 14 dní(u větších projektů), případně se řeší podle závažnosti hned. Posílají se minimálně e-mailem, abych měl záznam o tom, že jsem to zíkazníkovi poslal. Lépe je issue tracker. Obsah sdělení je důvod rizika, cena a doba opravy a proč je nutné to dělat.
+Dle mého hlavně v nabídce a během řešení change requestu. Pak mimořádná rizika, která se objeví na schůzkách.
+**Vzajemna souvislost, popis a naroky kladene na prostredi * vyvojove, integracni, testovaci, akceptacni, produkcni.**
+Vývojové - kde se vyvíjí, Integrační: Slouží ke spojení více aplikací, většinou pro integrační testy, Testovací: Slouží pro Unit testy, Akcepační: Slouží pro akceptační testy, Produkční: Tam to běží.
+Prostředí by si měly být co nejvíc podobné
+** Koncepty integrace a principy na kterých jsou založeny **
+  * Filetransfer
+  * Shared Database
+  * Remote Procedure Call
+  * Messaging
+** jak zavést evidenci změnových řízení **
+Podle mě nejlélpe Issue trackerem minimálně a propojovat změny k sobě. JIRA umí jak spojit změny, tak evidovat jejich pracnost.
+** Napište materiál ze kterého jste se učili a co vás na něm zaujalo. **
+Joooo Google !!
+==== Otázky z 14.1.2013, které nejsou výše ====
+** Co je to IOC Anchor point, k čemu se to váže atd. **
+  *Viz výše
+** Vyjmenujte způsoby dekompozice požadavků, porovnejte je a v jakých fázích použijete jaké dekompozice a proč? **
+  *Feature centric - do LCA
+  *Architecture centric - při vývoji
+  *Change request centric - po IOC resp. při údržbě
+** Vysvětlete SDLC (asi chtěl ten graf?) a řekněte v jaké fázi vývoje můžete začít programovat a kdy může prograování skončit a proč? **
+** Vyjmenujte atributy požadavků a krátce je popište (chtěl jich snad 8)? **
+  * Correct
+  * Unambiguous
+  * Complete
+  * Consistent
+  * Ranked
+  * Verifiable
+  * Modifiable
+  * Traceable
+** Cíle CM plánu (stručně vysvětlete) **
+  * Zajistit řád a pořádek v konfiguraci SW produktu.
+  * evidence všech částí SW
+  * identifikace všech částí SW i celku
+  * zajištění, že provádění změn SW produktu produkt nepoškodí
+  * Zajisti možnost zíkat přehled o stavu a konfiguraci SW produktu
+** Co kdo požaduje od architektury (ve slajdech je taková tabulka) **
+  * Zákazník - zda to jde, kdy to bude, kolik to bude stát atp.
+  * Uživatel - bude to dělat to co chce
+  * Systemový inženýr - jak realizovat nefunkční požadavky
+  * Vývojář - dostatčný detail pro design, komunikace s ostatními IS atp.
+  * Udržbář - jak udržovat, co to bude za práci atp.
+** Co má být v plánu CM + návrh osnovy **
+  * Úvod - učel, rozsah a podmínky použití
+  * řízení verzí (version control)
+  * řízení změn (change control)
+  * release management
+** 5 typů testů + k čemu jsou **
+** kroky při odhadování požadavků **
+** Rozdíl mezi frameworkem a knihovnou, hot spot vs frozen spot **
+  * Framework určuje částečně architekturu a design
+  * Knihovna nic nevynucuje
+  * IoC - inversion of control, při použití knihovny my voláme nějakou její funkci, při použití frameworku framework volá náš kód
+  * Frozen spot to co je dáno frameworkem a je neměné
+  * Hot spot - prostor kam dodat vlastní kód do frameworku
-  * Model zivotniho cyklu software/SDLC. K cemu slouzi? Příklady. Souvislost SDLC a primarnich + podpurnych cinnosti SW inzenyrstvi z min.otazky. + Příklady 2 SDLC
+** Kužel nejistoty + něco, co si přesně nepamatuju **
-** Analýza --> Implementace --> Testování --> Vyhodnocení --> Analýza ... **
+  * Je to že odhad se na začátku může až 4x (tak, je to ve slidech na tom obrázku) přestřelit nebo podstřelit vůči reálnému odhadu a postupně se nám odhad zužuje ve tvaru kuželu.
-  * Naroky na specifikaci pozadavku na software / system. Diskutujte naroky na formu, obsah, zpusob pouziti.
-** Záleží na tom, pro koho bude (uživatel, správce, vnitřek firmy). Forma může být textová, grafická ... . Použití jako podpora pro další projekty, kde se využije předchozích částí, jako specifikace akceptace projektu, popis projektu, pro změnové řízení ... **
-  * rozdíl mezi verzí konfigurační jednotky a verzí softwarového díla
-** Nevím **
-  * Co je architektonicky styl (ve smyslu sw. inzenyrstvi) + priklady.
-** Návrhový vzor. Popis, jak by se co mělo čistě řešit. **
-  - ** Pipes and filters **
-  - ** Event driven architecture **
-  - ** Layered architecture – interní dekompozice (např. TCP/IP) **
-  - ** Multi-tier architecture – fyzická dekompozice (např. webový server – aplikační server – databáze) **
-  - ** Model-View-Controller (MVC) **
-  - ** Repositories **
-  - ** „Table driven” interpreters **
-  - ** Big ball of mud **
-  * Kvalifikacni a akceptacni testovani * charakterizovat, popsat rozdily.
+** K tomu sdlc, chtěl graf, kde je na jedný ose pracnost a na druhý jednotlivý fáze SDLC **
-** Akceptační testování: Testování podle kritérií na akceptaci. Provádí se u zákazníka. Kvalifikační: Stejné jako akceptační, akorát se dělá u dodavatele před odevzdáním zákazníkovi. **
-  * Popiste jake KONKRETNI kroky provedete, pokud chcete rozjet Continuous integration (Smoke testing, night buildy) (+obrázek)?
-** Jenkins, popsat, jak by se co nastavilo, kam s kódem ... Prakticky popis toho, co se dělalo na cvikách. **
-  * Tag a branch, vysvetlete jaky je mezi nimi rozdil.
-**  Tag : stav nějakého kódu v branchi. Branch: Kopie verze jiné  branche, která se mění nezávisle na původní branch, dokud se nespojí. **
-  * Jako projektovy manazer budete zakaznikovi hlasit rizika. Jak pravidelne to budete delat? Co bude obsahem sdeleni? Jakou formou to delat, aby to vubec melo smysl.
-** Tohle jsem nikde nenašel, ale podle toho, jak se to dělá u nás: Rizika se probírají na schůzích, které jsou jednou za 14 dní(u větších projektů), případně se řeší podle závažnosti hned. Posílají se minimálně e-mailem, abych měl záznam o tom, že jsem to zíkazníkovi poslal. Lépe je issue tracker. Obsah sdělení je důvod rizika, cena a doba opravy a proč je nutné to dělat. **
-  * Vzajemna souvislost, popis a naroky kladene na prostredi * vyvojove, integracni, testovaci, akceptacni, produkcni.
-** Vývojové - kde se vyvíjí, Integrační: Slouží ke spojení více aplikací, většinou pro integrační testy, Testovací: Slouží pro Unit testy, Akcepační: Slouží pro akceptační testy, Produkční: Tak to běží. **
-  * jak zavést evidenci změnových řízení
-** Podle mě nejlélpe Issue trackerem minimálně a propojovat změny k sobě. JIRA umí jak spojit změny, tak evidovat jejich pracnost. **
-  * Napište materiál ze kterého jste se učili a co vás na něm zaujalo.
-** Joooo Google !! **
 ===== Ústní =====

courses/a4m33sep.1357122403.txt.gz · Poslední úprava: 2025/01/03 18:15 (upraveno mimo DokuWiki)

Nahoru