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?

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

1. Power : vysoká pravděpodobnost nalezení problému, pokud existuje
2. Valid : odhalí skutečné chyby
3. Value : odhalí chyby důležité pro uživatele
4. Credible : odpovídá očekávanému chování uživatele
5. Representative : odpovídá tomu, čeho 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 to 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)

* 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?

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

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

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.