• Proces vývoje SW.
• Metodika Unified Process.
• Agilní vývoj SW.
• Fáze testování a typy testů.
• Softwarové metriky, refaktoring kódu. Kvalita softwaru.
• Odhadování nákladů a času vývoje SW.
• Údržba a znovupoužitelnost.

Základní aktivity při vývoji SW:

• Specifikace
  • Je třeba definovat funkcionalitu SW a operační omezení.
• Vývoj
  • Je třeba vytvořit SW, který splňuje požadavky kladené ve specifikaci.
    1. Návrh
    2. Implementace
• Validace
  • SW musí být validován („kolaudován“), aby bylo potvrzeno, že řeší právě to, co požaduje uživatel.
• Evoluce
  • SW musí být dále rozvíjen, aby vyhověl měnícím se požadavkům zákazníka.
    1. Nasazeni
    2. Vlastni evoluce
    3. Servisovani
    4. Phase-out (dožívání)

Modely životního cyklu

• Vodopád
• Prototypování
• Výzkumník
• Spirálový model

• Vodopád
  • celý projekt rozdělen do fází (trvající řádově měsíce):
    1. analýza
    2. návrh
    3. implementace
    4. integrace
    5. verifikace
    6. nasazení
    7. údržba
  • chyba vede k návratu k předešlým fázím
    • ➖ odhalení chyby je čím dále dražší
  • ➖ těžké odhadnout ukončení fáze
  • testování neprobíhá současně s vývojem
    • ➖ chyby jsou odhalovány pozdě kvůli
• Iterativní
  • celý projekt vyvíjen v několika iteracích
    • každá iterace obsahuje fáze jako u vodopádu (ale může se lišit intenzita)
    • ➕ rychlejší zpětná vazba od zákazníka
    • ➕ částečné řešení dříve
• Inkrementální
  • jednotlivé části projektu vyvíjeny nezávisle a následně integrovány.
  • samotné část mohou být vyvíjeny další metodikou (vodopád, iterativně, XP,…)
  • ➕ vždy je výsledkem iterace použitelný produkt

• Metodika zaměřená na lidi.
• Umožňují rychlý vývoj a zároveň dokáží reagovat na změnu požadavků v průběhu vývojového cyklu.
• velmi krátké iterace
• UML pouze jako komplement
• malé fungující týmy
• zákazník zapojen do vývoje

Agilní metodiky

• Extreme programming (XP)
• Feature-Driven Development (FDD)
• SCRUM Process Development
• Test-Driven Development (TDD)

Rozdíl oproti Model-Driven Engineering (MDE):

• MDE:
  • pevná funkcionalita
  • variabilní čas a zdroje
• Agile:
  • pevný čas a zdroje
  • variabilní funkcionalita

• Nemůže ukázat nepřítomnost defektů, může pouze ukázat, že v softwaru jsou chyby.
• Testování také ukazuje funkce a výkon.
• Ukazatelem kvality software.
• Testování je destruktivní činnost, není vhodné, aby vývojář a tester byla ta samá osoba.

• Verifikace - test proti vnitřní činnosti (unit testy)
  • “Dělat věci správně”
• Validace - test proti specifikaci
  • “Dělat správné věci”

• úplné testy
  • prochází všechny logické cesty
  • není realizovatelné
• selektivní testování
  • testujeme důležité logické cesty a cykly
  • validuje rozhraní a vytváří důvěru ve vnitřní činnost
• dynamické testování
  • vzorkování – provedení programu s předem určenými vstupy a porovnání s očekávanými výsledky
• BlackBox vs. WhiteBox
  • vidím/nevidím do struktury programu

• Unit testy
  • hledají defekty uvnitř softwarových komponent a verifikují fungování softwarových komponent (např. modulů, programů, objektů, tříd, atd.), které jsou testovatelné samostatně.
• Integrační testy
  • testuje rozhraní mezi komponentami, interakce s různými částmi systému jako jsou operační systém, souborový systém, hardware anebo rozhraní mezi systémy.
• Systémové testy
  • Systémové testování se zabývá chováním celého systému/produktu, jak byl definován rozsahem vyvíjeného projektu nebo programu.
  • Měly by pokrýt jak funkční tak nefunkční požadavky.
• Akceptační testy
  • Hlavní částí testování z pohledu dodávky aplikace zákazníkovi.

Další testy:

• Funkční testy
  • slouží k nalezení rozdílů mezi aktuální aplikací proti funkční specifikaci (funkční požadavky)
• Nefunkční testy
  • Zahrnují testování výkonu, zátěžové testování, stres testování, testování použitelnosti, testování udržovatelnosti, testování spolehlivosti a testování přenositelnosti.
  • Je testováním toho, “jak“ systém pracuje (jako celek).
• Statické testy
  • Provádí manuální prozkoumání (revidování) a automatizovanou analýzu (statickou analýzu) kódu nebo jiné projektové dokumentace (uživ.příručky, apod.)
• Dynamické testy
  • Znamenají provádění testování na již běžící systému, aplikaci
• Regresní testy
  • Testy na ověření stávající funkcionality (provádí se po opravení chyb či novem release)
• Progresní testy
  • Testy na ověření nové funkcionality
• Smoke test
  • Je krátký test, který slouží jako ověření, že vyvíjená aplikace je „způsobilá“ pro další fázi testování.
• Assembly testy
  • Mají za úkol ověřit, že jednotlivé části kódu, testované v rámci unit testů, spolu fungují.

• kvantitativní (číselně vyjádřená) míra, tj. ukazatel do jaké míry se nějaký atribut vyskytuje v systému, komponentě nebo procesu
• kvalitativní charakter, tj. nečíselné vyjádření

Dělíme na:

• Produktové
  • zdrojový kód, dokumentace, cyklomatická složitost (počet cest programem), počty funkčních bodů
• Procesní
  • činnosti spojené s vývojem, doba strávená na jednotlivých úlohách, původní odhad a skutečná reálná doba
• Metriky zdrojů
  • HW, lidé, čas, nemocnost, výkonnost

• Implicitní (in proces)
  • zjistitelné pouze během vývoje
• Explicitní (after proces)
  • zjistí se kdykoliv i po skončení vývoje (z artefaktů produktů systému)

Při odhadování se reflektuje:

• Minulý podobný projekt (velmi dobrý výchozí bod)
• Použití dekompoziční techniky
• Použití empirických modelů
• Odhad se zpožděním (nutný určitý buffer, pokud by se něco pokazilo)

Putnam

T - usílí (člověkodny)
D - doba řešení
c - hodnota podle předchozích projektů
N - Délka programu

• Kvalitativní atributy souvisí převážně s non-funkčními požadavky.
  • Performance (výkon)
  • Reliability (spolehlivost)
  • Security (bezpečnost)
  • Scalability (škálovatelnost)
  • Maintainability (udržovatelnost)

• Techniky hodnocení kvality
  • monitoring a testování
    • verifikace kvality existujícího systému
  • predikce na základě modelu
    • odhad kvality systému ve vývoji
  • formální verifikace
    • verifikace formulovaných tvrzení o systému

Obecný model kvality (Quality model)

• Operation:
  • Dělá to, to co má? Týká se splnění specifikace, standardů a uživatelského očekávání.
  • pohled uživatele
• Revision:
  • Je dobře navržený? (dobře testovatelný, rozšiřitelný apod.)
  • Týká se vývoje.
  • Pohled vývojářů
• Transition:
  • Je dobře nasaditelný? (přenositelnost, nezávislost na HW, pohodlná instalace)
  • Celkový pohled obou stran

• Obecně lze mluvit o testování, validaci a verifikaci produktu.
• Validací se rozumí otázka, zda jsme vytvořili správný produkt tj. jestli produkt odpovídá potřebám uživatele.
• Verifikací se rozumí, zda jsme produkt vytvořili správně tj. zda produkt odpovídá specifikaci.
• Testováním se pak pokoušíme zmíněné předchozí dokázat pro omezenou sadu příkladů.
• Inspekce, recenze
• Testování
• Měření
• Standardy a procedury

Velmi nákladná v čase, finance odpovídají tomu jak dlouho ho chceme udržet. Náklady jsou 2x -100x větší než na vývoj. Na údržbu se mělo myslet již při vývoji.

• Oprava softwarových chyb
• Adaptace softwaru na jiné operační prostředí
• Přidat nebo měnit systémovou funkcionalitu → každá implementace degraduje kvalitu systému

Znovu napsání celé části systému bez účelu změnit její funkcionalitu, když subsystémy vyššího systému vyžadují častou údržbu. Cílem je vytvoření nového systému, který by se lépe udržoval (i snížení ceny za údržbu).

Refactoring je kontinuální proces vylepšení skrze vývojový a evoluční proces. Jeho záměrem je vyhnout se degradaci struktury a kódu, která zvyšuje cenu za údržbu.

„Code smells“

• Duplikovaný kód - kód se opakuje na různých místech programu
• Dlouhé metody
• Long Parameter List - dlouhý seznam parametrů
• Shotgun Surgery - abychom udělali jednoduchou změnu v kódu, je nutné sahat na mnoho míst, indikátor toho, že máme špatný model, že třídy mají špatnou zodpovědnost
• Middle Man - zprostředkované volání objektu zbytečně přes prostředníka
• Lazy Class - prázdná skořápka, třída, která nic nedělá
• Spekulativní obecnost - kód, který je v programu obsažen, aby sloužil někdy do budoucna

Hlavní výhodou je několikanásobné finanční ohodnocení jednou vyvinuté komponenty.

Úrovně znovupoužitelnosti (reuse levels)

• Abstrakce (The abstraction level): analytické prvky
• Objekty (The object level): třídy
• Komponenty (The component level): kolekce tříd
• Systém (The system level): celý systém a různé platformy

• slidy pa103
• slidy pa017
• https://docs.google.com/document/d/1JVC34-jBqK-hnyxty9YNelID_LChUsvREdgS9NaEjvI