Softwarové inženýrství pro praxi

• Stránky předmětu: a4m33sep
• Přednášející:
• Cvičící:

Cvičení první týden nejsou.

• Test je shodný s tím, co je na fóru matfyzu.

• 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

• Přikládám odkaz na mé 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):

1. Logical view - Class, Sequence diagram
2. Development view - Component, Package diagram
3. Process view - Activity diagram
4. Physical view - Diagram nasazení
5. Scenarios - Use-case

• Napište atributy testů a co znamenají. (Chtěl tak čtyři.)

1. Power : vysoká pravděpodobnost nalezení problému, pokud existuje
2. Valid : odhalí skutečné chyby
3. Value : odhalí chyby důležité pr - uživatele
4. Credible : odpovídá očekávanému chování uživatele
5. Representative : odpovídá tomu, čeh - si uživatel nejpravděpodobněji všimne
6. Non-redundant : reprezentuje skupinu testů, které se zaměřují na stejné riziko
7. Motivating : „klient“ bude chtít chyby nalezené testem opravit
8. Performable : proveditelný v souladu s návrhem
9. Maintainable : udržovatelný při změnách systému
10. Repeatable : snadný - a levně znovupoužitelný
11. Pop (Karl Popper) : odhalí věci týkající se základních či kritických předpokladů
12. Coverage : vyzkouší systém způsobem, kterým t - nečiní jiné testy
13. Easy t - evaluate : snadné a jasné vyhodnocení
14. Appropriately complex : dostatečná komplexnost
15. Accountable : obhajitelnost, prokazatelnost testu
16. Supports troubleshooting : poskytuje užitečné informace k ladění nalezených problémů
17. Cost : přímé náklady, čas a pracnost
18. 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)

1. 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.
2. 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.
3. Technická dokumentace – Dokumentace kódu, algoritmy, popis rozhraní a API.
4. Uživatelská dokumentace – Manuály pro koncového uživatele, systémové administrátory a osazenstvo podpory.
5. 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 :) )

1. Dokumentace Procesu
   1. Plány a odhady
   2. Zprávy
   3. Pracovní dokumenty
2. Dokumentace Produktu
   1. Uživatelská
   2. Vývojářská
   3. 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.)

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í)

1. Initiation and Scope Definition
2. Software Project Planning
3. Software Project Enactment
4. Review and Evaluation
5. Closure
6. Software Engineering Measurement

• Co je to historie, co obsahuje a proč se dělá?

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 …

• Jaké jsou základní druhy metrik, k čemu jsou?

1. time (kalendářní čas):z evidence práce
2. size (rozsah):počet řádek kódu, CVSstat
3. effort (pracnost):z evidence práce
4. quality (jakost):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í.V-Model

• 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. Slouží k nahlášení chyb v SW.

• Popiste zakladni cinnosti Softwaroveho inzenyrstvi. Jakeho jsou typu (primarni, podpurne)? A strucne kazdou charakterizujte.

Základní:

1. Byznys modelování popisující strukturu a dynamiku podniku či organizace.
2. Specifikace požadavků definující prostřednictvím specifikace tzv. případů použití softwarového systému jeho funkcionalitu.
3. Analýza a návrh zaměřené na specifikaci architektury softwarového produktu.
4. Implementace reprezentující vlastní tvorbu softwaru, testování komponent a jejich integraci.
5. Testování zaměřené na činnosti spjaté s ověřením správnosti řešení softwaru v celé jeho složitosti.
6. Rozmístění zabývající se problematikou konfigurace výsledného produktu na cílové počítačové infrastruktuře.

Podpůrné:

1. Ří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.
2. 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í.
3. 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

Analýza –> Implementace –> Testování –> Vyhodnocení –> Analýza …

• 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.

1. Pipes and filters
2. Event driven architecture
3. Layered architecture – interní dekompozice (např. TCP/IP)
4. Multi-tier architecture – fyzická dekompozice (např. webový server – aplikační server – databáze)
5. Model-View-Controller (MVC)
6. Repositories
7. „Table driven” interpreters
8. Big ball of mud

• Kvalifikacni a akceptacni testovani * charakterizovat, popsat rozdily.

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 !!

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.