====== Softwarové inženýrství pro praxi ====== * Stránky předmětu: [[http://www.profinit.eu/cz/podpora-univerzit/univerzitni-vyuka/a4m33sep|a4m33sep]] * Přednášející: * Cvičící: ===== Cvičení ===== Cvičení první týden nejsou. ===== Zkouška ===== == 3.1.2011 == * Test je shodný s tím, co je na [[http://forum.matfyz.info/viewtopic.php?p=31485|fóru matfyzu]]. == 9.1.2012 == * Otázky se hodně opakují (viz seznam dole) * časově extrémně náročné - psát jen v bodech a nezastavovat se * opravuje to pedantsky. Ve chvíli, kdy otázka zní například "Co to je XXXX a YYYY a jaký je mezi tím rozdíl", tak chce: * zřetelnou odpověď na to, co je to XXX * zřetelnou odpověď na to, co je to YYY * zřetelnou odpověď na to, jaký je mezi tím rozdíl/vztah * když kterákoliv část otázky chybí tak, jdou body dolů a jdou hodně rychle. Obvyklé známky D-F * test opravuje cca týden (nebo 5 dní, o víkendu nepracuje, neodpovídá na mejly) * ústní je za dlouho. Někdy je ústní dobrovolná, když se špatně vyspí tak povinná. Obvykle F-D na ústní nemusí, C+ ano ===== Č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 § ** Co je to bod LCO, LCA, IOC + dopad na plán projektu? ** Jsou to milníky vyskytující se během fází vývoje SW * LCO (Live cycle objectives) * 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 vztah se SRS: * realizuje nefunkční požadavky ze SRS * 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) ** Popište čtyři základní pohledy na architekturu. (Takový ten obrázek se scénáři uprostřed.) ** * Logical view - Class, Sequence diagram * Development view - Component, Package diagram * Process view - Activity diagram * Physical view - Diagram nasazení * Scenarios - Use-case ** Napište atributy testů a co znamenají. (Chtěl tak čtyři.) ** - Power : vysoká pravděpodobnost nalezení problému, pokud existuje - Valid : odhalí skutečné chyby - Value : odhalí chyby důležité pro uživatele - Credible : odpovídá očekávanému chování uživatele - Representative : odpovídá tomu, čeho 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 to 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) ** * Dokumentace Procesu * Plány a odhady * Plán projektu, QA Plan, CM Plan * 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é: * Ří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í. * 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 ** Kužel nejistoty + něco, co si přesně nepamatuju ** * 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. ** K tomu sdlc, chtěl graf, kde je na jedný ose pracnost a na druhý jednotlivý fáze SDLC ** ===== Ústní ===== Z písemky jsem dostal 25 b (jestli si dobře vzpomínám) a byla mi navrhnuta známka C. Musel jsem jít na ústní (ano, v mém případě byla povinná, chtěl jsem si ji nechat zapsat, ale nešlo to...). O termínu ústní s nimi lze diskutovat. Mě byli navrhnuty 3 termíny hned další týden po písemce. Po výměně několika emalů jsem se snimi dohodl na termínu až za dalších 14 dní po písemce. Byl jsem u p. Zoubka. Posadili si mě do nějaké zasedačky a cca po 5 minutách tam přišel i Zoubek (byli jsme tam sami...). Ústní probíhala tak, že jsme spolu postupně procházeli všechny nedostatky v testu. Potom se mě zeptal, jestli mám nějakou praxi, když jsem řekl že ne, tak mi odpověděl, že se mě teda musí ještě na něco zeptat :-). Položil mi ještě asi 2 otázky. Otázky neobsahovaly žádně špeky a p. Zoubek byl velmi trpělivý, když jsem něco hned nevěděl, tak se mě snažil popostrčit. Nakonec jsem si odnesl B. Ústní trvala cca 20 min. ~~DISCUSSION~~