Obsah

Zadání

Proces vývoje SW

Proces vývoje SW

Proces při němž:
  • uživatelovi potřeby
    • ⬇ transformovány na
  • požadavky na software
    • ⬇ transformovány na
  • návrh
    • ⬇ implementován jako
  • kód
    • ⬇ testován, dokumentován a certifikován pro
  • operační použití

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

Modely životního cyklu

OO modely

Metodika Unified Process

  • Generická procesně orientovaná metodika postavená nad UML.
    • Definuje KDO dělá KDY, CO a JAK toho má dosáhnout.
    • iterativní a inkrementální
      • Každou iteraci lze chápat jako mini-projekt (fáze: Plánování, Analýza a návrh, Implementace, Integrace a testování)
    • use-case driven
      • Hlavní pohled udává Use Case diagram, snažíme se vždy dokončit jeden případ užití a pak pokračujeme dále.
    • architecture-centric
      • Jasně udává, že volba a vybudování dobré architektury systému je hlavním cílem projektového týmu.
    • Řízení rizik
      • Vyžaduje, aby se projektový tým zaměřil na řešení nejvážnějších rizik v rané fázi životního cyklu projektu (největší rizika jsou vždy řešena jako první).
  • Fáze v UP:
    • Inception
      • Definuje oblast projektu a business využití.
    • Elaboration
      • plán projektu, specifická funkcionalita, základní architektura
    • Construction
      • tvorba produktu
    • Transition
      • předání produktu zákazníkovi
  • Každá fáze má několik iterací s jasným plánem a výstupem.
    • Obsahují „workflows“, různě zastoupené během celého vývoje.
      • requirements
        • Use Case model: use-case, sequence diagram
      • analysis
        • Analysis model: class/object diagram
      • design
        • Design model: class/object diagram, sequence, state, activity diagram
        • Deployment model: deployment, sequence diagram
      • implementation
        • Implementation model: component, sequence diagram
      • test
        • Test model: odkaz na všechny odpovídající modely a diagramy
      • Use-case spojuje workflows dohromady.

Metodika Rational Unified Process (RUP)

  • komerční implementace metodiky UP od IBM
  • RUP i UP stojí na stejném základu
  • RUP mírně detailnější než UP
  • drobné odlišnosti v syntaxi

Agilní vývoj SW

Agilní metodiky

Manifesto of Agile Software Development

http://agileManifesto.org
  • Individuality and interactions over processes and tools.
  • Working software over comprehensive documentation.
  • Customer collaboration over contract negotiation.
  • Responding to change over following a plan.

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

Fáze testování a typy testů

Proces spuštění (části) programu s cílem nalézt chyby.

Myers,1979

Test je úspěšný, pokud zjistí přítomnost jedné či více chyb v programu.

Typy testů

Další testy:

Softwarové metriky

Softwarová metrika

Údaj (měření, atribut softwaru), který lze nakonec převést na číselné hodnocení.

Dělíme na:

Velikostně orientované metriky

  • Lines Of Code (LOC), 1000 Lines Of Code (KLOC)
  • počet chyb/KLOC
  • počet defektů/KLOC
  • cena/LOC
  • velikost dokumentace/KLOC

Funkčně orientované metriky

  • počet uživatelských vstupů
  • počet už. výstupů
  • počet dotazů
  • počet souborů
  • počet spojení s jinými systémy

Metriky složitosti

Halsteadova metrika

Program je věta, která vznikla na určité slovní zásobě. Na základě poměru délky věty (programu) a velikosti slovní zásoby (počet operátorů a operandů) získáme složitost.

McCabe odhad složitosti

Vnímá program jako graf. Dochází k výpočtu cyklomatické složitosti:
  • Kolik je možných průchodů grafem nebo kolik je tam nezávislých větví.

Funguje také jako indikátor spolehlivosti.

  • Pokud V(G) je větší než 10 má velký chybový potenciál a zle se testuje.
  • V(G) je v podstatě počet uzavřených oblastí v rovinném grafu.

McClure odhad složitost

Také založen na cyklomatické složitosti. Odvozeno od počtu větvení (C) a počtu řídících proměnných (V), především zohledňuje složitost podmínek tj. samotných uzlů!
  • C + V

Odhadování nákladů a času vývoje SW

Při odhadování se reflektuje:

Funkční bod

Metrika, říkající kolik toho funkční jednotka umí. Měří aplikační oblast, nezkoumá technickou oblast.

Putnam

T - usílí (člověkodny)
D - doba řešení
c - hodnota podle předchozích projektů
N - Délka programu
N = c * T^{1/3} * D*^{4/3}

Cocomo (COnstructive COst MOdel)

  • Odhadování pracnosti shora-dolů.
  • Vychází z Putnama a odhadu délky programů KSLOC.
  • Zdroj empirických dat je větší počet předchozích projektů a pozorování.
  • Model (přesnost výpočtu)
    • základní (hrubý odhad)
    • střední
    • pokročilý (bere v potaz etapu vývoje)
  • Mód (jak je projekt obtížný)
    • organický (jednodušší, dobře řešitelné projekty menšího rozsahu)
    • bezprostřední (středně obtížné projekty)
    • vázaný (rozsáhlé projekty s vysokými nároky na řízení)

E = a * F * (KLOC)^b
T = c* E^d

  • a,b,c,d - parametry volené podle úrovně modelu a módu
  • T - doba řešení
  • E = úsilí
  • F = korekční faktor, ekvivalence s „c“ v Putnamovi tedy produktivita

Cocomo II

Nemá smysl dělat přesné výpočty na začátku projektu → korekční faktor vždy 1 a základní model.

Důvod změny:

  • nové SW procesy
  • nové jevy měření
  • nové možnosti jako znovupoužití SW

3 různé modely:

  • ACM (Aplication Composition Model)
    • pro projekty s použitím moderních nástrojů a GUI
  • EDM (Early Design Model)
    • pro hrubé odhady v úvodních etapách, kdy se architektura vyvíjí
  • PAM (Post Architecture Model)
    • pro odhady poté, co byla specifikována architektura

Kvalita softwaru

Obecný model kvality (Quality model)

Kvalita dle IEEE

Stupeň, do jaké míry systém, komponenta nebo proces splňuje specifikované požadavky. (spíše u SW na zakázku)
Stupeň, do jaké míry systém, komponenta nebo proces splňuje zákazníkovy nebo uživatelovy potřeby nebo jeho očekávání. (spíše u krabicového SW)

Techniky zajištění kvality software

Údržba a znovupoužitelnost + Refaktoring

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.

Systémový re-engineering

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

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“

Znovupoužitelnost

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

Úrovně znovupoužitelnosti (reuse levels)

Reuse-Oriented software engineering

Model vývoje SW, založen na systematickém znovuužití, kde jsou systémy integrovány z existujících komponent (commercial-off-the-shelf = COTS)
  • Zbylou funkcionalitu (kterou ještě nemáme) doprogramujme, především proxy, adaptéry a GUI.
  • Jedná se o standardní budování business systémů.

Lehmanovy zákony

Zákony se zabývají fází evoluce, popisují rovnováhu mezi novými požadavky a údržbou na straně jedné a zvyšující se složitostí, snižující se “business value” na straně druhé.

  • Zákon trvalé proměny
    • Systém používaný v reálném prostředí se neustále mění, dokud není levnější systém restrukturalizovat nebo nahradit zcela novou verzí.
  • Zákon rostoucí složitosti
    • Při evolučních změnách je program stále méně strukturovaný a vzrůstá jeho vnitřní složitost.
    • Odstranění složitosti vyžaduje dodatečné úsilí.
  • Zákon vývoje programu
    • Rychlost globálních změn atributů systému se může jevit v omezeném časovém intervalu jako náhodná.
    • V dlouhodobém pohledu se však jedná o seberegulující proces, který lze statisticky sledovat a předvídat.
  • Zákon invariantní spotřeby práce
    • Celkový pokrok při vývoji projektů je statisticky invariantní.
    • Jinak řečeno, rychlost vývoje programu je přibližně konstantní a nekoreluje s vynaloženými prostředky
  • Zákon omezené velikosti přírůstku
    • Systém určuje přípustnou velikost přírůstku v nových verzích.
    • Pokud je limita překročena, objeví se závažné problémy týkající se kvality a použitelnosti systému.

Brooksův zákon

Týká se začlenění nového člena týmu do zpožděného projektu (ten, který s ním neměl zatím žádný styk :D). Zákon říká, že “Přidání řešitelské kapacity u opožděného projektu může zvětšit jeho zpoždění (náklady na začlenění nového pracovníka do týmu jsou zpravidla větší, než jeho přínos)”.

Zdroje