Modele cyklu życia systemu

Elementarny model cyklu życia systemu:

–

inicjacja (specyfikacja)

–

projektowanie

–

kodowanie

–

walidacja

–

instalacja

Model kaskadowy:
Polega na wykonywaniu podstawowych czynności jako odrębnych faz projektowych, w ustalonym
porządku. Każda czynność to kolejny schodek (kaskada):

–

określenie wymagań (planowanie i analiza)

–

projektowanie

–

implementacja (wytworzenie kodu)

–

testowanie (poszczególnych elementów oraz elementów połączonych w całość)

–

konserwacja (po wdrożeniu, np. reagowanie na awarie, dostosowanie do nowych wymagań
klienta)

Jeżeli jakaś faza nie daje dobrych wyników, powtarzamy ją. Stosowany w projekcie o dobrze
zdefiniowanych wymaganiach dla dobrze rozumianych zastosowań. Rzadko stosowany w praktyce
ale stanowi bazę dla innych modeli powstałych jako jego udoskonalenia. Sprawdza się w przypadku
niewielkich projektów.

Zalety:

–

łatwość zarządzania przedsięwzięciem

–

ułatwia planowanie, harmonogramowanie oraz monitorowanie przedsięwzięcia

Wady:

–

brak weryfikacji

–

brak elastyczności

–

wysoki koszt błędów popełnianych we wstępnych fazach (prawdopodobnie przez
konieczność powtarzania fazy)

–

nie sprzyja wprowadzaniu modyfikacji

–

zbytni formalizm i narzucenie ścisłej kolejności wykonywania prac

Model typu V

specyfikacja testy akceptacji
projekt systemu integracja i walidacja systemu
projekt podsystemu integracja i walidacja podsystemu
projekt modułu formalne testy modułu

kodowanie modułu i wstępne testy

Modyfikacja modelu kaskadowego podkreślająca wagę weryfikacji i walidacji systemu (każdy
poziom posiada swoja fazę testowania i nie można przejść do niższego bez odpowiednich testów
potwierdzających jego poprawność).

Model spiralny
Projekt jako kolejne kroki projektowe z uwzględnieniem zagrożeń realizacji projektu, stosowany
raczej do realizacji dużych systemów.

Reprezentacja graficzna ma postać spirali, której każda pętla podzielona jest na cztery sektory:

–

określenie celów, alternatyw, ograniczeń, ustalenie planów realizacji

–

analiza alternatywnych rozwiązań, identyfikacja i ograniczenie ryzyka

–

implementacja rozwiązania o najbardziej odpowiedni model wybrany na podstawie oceny
zagrożeń

–

recenzja postępu prac i planowanie kolejnej fazy (bądź zakończenie projektu)

Każdy następny cykl (pętla) wymaga formalnej decyzji o kontynuacji projektu.

Zalety:

–

jawne zarządzanie ryzykiem

–

faza oceny w każdym cyklu pozwala uniknąć błędów lub wcześnie je wykryć

–

pozwala na wykorzystanie różnych, najbardziej odpowiednich modeli dla poszczególnych
faz projektu

–

cały czas istnieje możliwość rozwijania projektu (rozpoczęcia nowego cyklu)

Wady:

–

niezbyt dobre dopracowanie – każdy projekt jest inny i powstaje w innych warunkach, więc
ciężko określić te, które będziemy brać pod uwagę

–

tworzenie w oparciu o ten model wymaga doświadczenia w prowadzeniu tego typu
projektów i często wiedzy ekonomicznej w zarządzaniu (znajomość problematyki
szacowania i zarządzania ryzykiem)

Prototypowanie

Kolejne fazy modelu:

–

określenie ogólnych wymagań

–

budowa prototypu

–

weryfikacja prototypu przez klienta

–

pełne określenie wymagań

–

realizacja pełnego systemu zgodnie z modelem kaskadowym

Model zalecany przy realizacji nowatorskich rozwiązań, które dotychczas nie były w firmie
zamawiającej produkt stosowane, gdyż w takich warunkach klientowi jest trudno ściśle zdefiniować
swoje wymagania.

Cel:

–

wykrycie nieporozumień pomiędzy klientem a twórcami systemu

–

wykrycie brakujących funkcji

–

wykrycie trudnych usług

–

wykrycie braków w specyfikacji wymagań

Zalety:

–

minimalizacja ryzyka związanego z niewłaściwym określeniem wymagań

–

możliwość szybkiej demonstracji pracującej wersji systemu (prototypu)

–

możliwość szkoleń zanim zbudowany zostanie pełen system (dla pracowników firmy

zamawiającej?)

Wady:

–

dodatkowy koszt budowy prototypu

–

możliwe zdziwienie klienta, który zobaczy pełny system na pierwszy rzut oka bardzo
podobny do prototypu

Programowanie odkrywcze

–

określenie ogólnych wymagań

–

budowa systemu

–

testowanie systemu

–

weryfikacja systemu przez klienta

–

jeżeli system jest ok, przechodzimy do ostatecznego testowania, jeżeli nie, przechodzimy do
fazy budowania

Zalety:

–

możliwość stosowania nawet w przypadku trudności z określeniem wymagań klienta

Wady:

–

brak struktury projektu ze względu na ciągłe zmiany

–

niemożliwość osiągnięcia dużej niezawodności przy realizacji większych systemów

–

testowanie może odbywać się tylko w obecności klienta, gdyż twórcy nie mają pełnych
wymagań wobec systemu

Realizacja przyrostowa

–

określenie wymagań

–

ogólny projekt

–

wybór podzbioru funkcji

–

szczegółowy projekt, implementacja, testy

–

dostarczenie zrealizowanej części systemu

–

wybór kolejnego podzbioru funkcji etc.

Zalety:

–

skrócenie przerw w kontaktach z klientem

–

możliwość wczesnego wykorzystania przez klienta dostarczonych fragmentów

–

możliwość elastycznego reagowania na powstałe opóźnienia

Wady:

–

dodatkowy koszt związany z niezależną realizacją fragmentów systemu

Modelowanie konceptualne

Faza określania wymagań: co i przy jakich ograniczeniach system ma zrobić. Wynik: zewnętrzny
opis systemu.
Faza analizy: jak system ma działać. Wynik: logiczny model systemu.
Faza projektowania: jak system ma zostać zaimplementowany. Wynik: projekt.

Strukturalne metody analizy:

–

model danych – diagram encji i związków (Entity-Relationship Diagram)

–

model dynamiki – diagram stanów

–

model funkcjonalny – diagram przepływu danych (Data Flow Diagram)

Diagram związków i encji

Konstruktory:

–

encja
●

reprezentuje obiekty materialne i koncepcyjne

●

musi być jednoznacznie identyfikowalna (nazwa)

●

wszystkie encje wzajemnie się wykluczają

●

encje silne zawierają atrybuty kluczowe

●

encja słaba nie ma takich atrybutów, jest powiązana z co najmniej jedną silną encją

–

atrybut
●

modeluje własność encji

●

zadania: identyfikacja, opis, klasyfikacja, określanie ilości lub wyrażenie stanu encji
•

przykładowo: numer zamówienia – identyfikacja, typ towaru – klasyfikacja, status
płatności – wyrażenie stanu etc.

●

mogą być jedno lub wielowartościowe

●

mogą być kluczowe (jednoznacznie determinować encję) lub niekluczowe (ew.
kluczowe w innych encjach)

●

mogą być obowiązkowe i opcjonalne

●

związek
–

relacja R pomiędzy n zbiorami encji E1, …, En

–

posiada stopień – liczbę wiązanych encji (unarny, binarny, ternarny)

●

typ asocjacji
–

liczba wiązanych instancji encji
–

1:1 (np. dziekan - wydział)

–

1:n (np. wydział - student)

–

m:n (np. książka – autor)

Supertyp – encja, która zawiera jedną lub więcej kategorii (subtypów) podwiązanych za pomocą
relacji; subtypu muszą się wzajemnie wykluczać.

Przykład: Pracownik może być pracownikiem etatowym lub pracownikiem na umowę zlecenie.

Diagram przepływu danych

–

przedstawia graficzny model procesów w systemie – bez odniesienia kiedy i jak zostały
wykonane

–

odzwierciedlają ruch danych w systemie rzeczywistym

–

pozwalają patrzeć na system na różnych poziomach szczegółowości

DFD jest głównym modelem dla programów nieinteraktywnych (np. kompilatorów), których
głównym zadaniem jest obliczanie wartości funkcji. Dla systemów służących do składowania
danych (np. bazy danych) DFD jest często trywialny, gdyż celem jest składowanie danych, a nie ich
transformacja.

Na proces składają się następujące elementy:

•

Terminatory — obiekty zewnętrzne stanowiące odbiorców bądź źródła danych lub
argumentów funkcji.



reprezentują źródła lub miejsca przeznaczenia informacji, które są zewnętrzne w
stosunku do systemu (np. osoba lub inny system komputerowy)



obiekt generujący lub przejmujący strumienie danych

•

Składnice (magazyny) danych — trwałe lub tymczasowe składnice danych, które są
argumentami dla funkcji.



reprezentują miejsca, gdzie dane są przechowywane między operującymi na nich
procesami



są dostępne tylko dla procesów co oznacza, że magazyn nie może się łączyć
bezpośrednio z terminatorem



przepływ do składu interpretowany jako zapis, modyfikacja lub usunięcie danych

•

Procesy — (funkcje) realizują określone cele; jeśli funkcji nie można rozbić na pod-funkcje,
wówczas nosi ona nazwę elementarnej.



odpowiadają tym składnikom systemu, które operują na danych



otrzymują i przesyłają dane za pośrednictwem przepływów danych



dokonują transformacji przepływów wejściowych i wyjściowe

•

Przepływy — elementy pokazujące kierunek przesyłu danych (np. bajtów, znaków,
pakietów).



opisują strumienie danych o określonej zawartości przepływające pomiędzy:



terminatorami a procesami



procesami a procesami



procesami a składnicami danych

Oznaczenia:

–

proces – kółko

–

magazyn – prostokąt

–

terminator – kwadrat

–

przepływ – strzałka

Pamiętajmy:

–

terminatory leżą poza modelowanym systemem

–

przepływy łączące terminatory do różnych składowych reprezentują interfejsy pomiędzy
systemem a światem zewnętrznym

–

analityk/projektant nie może zmieniać zawartości terminatora

–

dowolna relacja istniejąca pomiędzy terminatorami nie może być pokazana na diagramie
DFD

Diagramy DFD są rozbudowane, więc zazwyczaj tworzymy diagramy hierarchiczne, które:

–

składają się z zestawu powiązanych diagramów

–

posiadają następujące poziomy:


diagram kontekstowy
•

przedstawiony jako jeden proces oznaczający cały system wraz z przepływami do i
od terminatorów



diagram ogólny
•

przedstawia główne funkcje systemu

•

najbardziej ogólne spojrzenie na system (posiada kilka procesów, terminatorów i
magazyny)



diagram 1-go poziomu



diagram 2-go poziomu



…

Liczba poziomów nie powinna przekroczyć 7 +- 2.

Diagram przejść przez stany STD (State-Transition-Diagram)
Pokazuje zachowanie się systemu w czasie (szczególnie istotne dla systemów czasu rzeczywistego).
Ze względu na swoją elastyczność może też służyć do prezentowania sposobu realizacji funkcji
systemu.

Konstruktory:

–

zdarzenie


informuje o tym, co wydarzyło się w pewnej chwili



ma zerowy czas trwania



reprezentuje pewną klasę zjawisk o podobnej reakcji systemu, np.:
•

pociąg odjeżdża ze stacji

•

wybranie polecenia z menu

•

przekroczenie określonej temperatury



zdarzenia zachodzące poza systemem to zdarzenia zewnętrzne, np.:
•

wprowadzanie danych
przerwanie operacji przez użytkownika



zdarzenia wewnętrzne mają swoje źródło w ramach systemu, np.:
•

zakończenie wykonywania metody

•

błąd arytmetyczny

–

stan


czas między zdarzeniami



system w różnych stanach reaguje w sposób jakościowo rożny na zachodzące zdarzenia

–

przejście


zmiana stanu wywołana przez zdarzenie



przejście może być uwarunkowane spełnieniem dodatkowego warunku

–

akcja


czynność wykonywana w momencie zajścia zdarzenia
•

wykonywanie obliczeń

•

odłożenie słuchawki

–

operacja



związana z konkretnym stanem



oznacza czynność ciągłą, wykonywaną podczas trwania stanu



operację może przerwać zdarzenie powodujące przejście do nowego stanu



zakończenie operacji może spowodować wygenerowanie zdarzenia i przejście do innego
stanu
•

monitorowanie czujnika

•

wyświetlanie aktualnego czasu

Weryfikacja jakościowa STD:

–

czy zdefiniowano wszystkie stany

–

czy wszystkie stany są osiągalne

–

czy istnieją wyjścia ze wszystkich stanów (poza końcowymi)

–

czy w każdym stanie system odpowiada poprawnie na wszystkie możliwe warunki

Jakość

Model McCalla:

–

przyjazność – efektywność użytkowania programu i przyjazność jego interfejsu

–

bezpieczeństwo – bezpieczeństwo używania programu pod kątem kontroli do korzystania z
niego oraz odporności na skutki nieprawidłowej obsługi

–

wydajność – ocena wydajności systemu i sposobów zarządzania zasobami

–

poprawność – stopień realizacji wymagać, kompletność i logiczność wdrożenia, zgodność
działania programu ze specyfikacją

–

pielęgnowalność – stopień przystosowania programu do poprawy, modyfikacji,
rozszerzenia, adaptowania

–

elastyczność – możliwości rozbudowania programu o nowe funkcje oraz uniwersalność
wdrożonych rozwiązań

–

testowalność – przystosowanie do procesu testowania oraz instrumentacja tego procesu

–

przenośność – zdolność do łatwego uruchomienia na innych maszynach lub systemach
oprogramowania

–

uniwersalność – możliwość wykorzystania istniejącego oprogramowania lub jego
fragmentów do konstrukcji innych programów

–

otwartość – przystosowanie programu do współpracy lub wymiany informacji z innymi
systemami komputerowymi

Zapewnienie jakości
Fazy:

–

planowanie

–

nadzorowanie

–

doskonalenie

Weryfikacja i walidacja

Walidacja – proces oceny oprogramowania na zakończenie procesu (fazy) produkcyjnej w celu
sprawdzenia, czy jest wolne od błędów i niezgodności

Weryfikacja – proces określenia, czy produkt danej fazy produkcyjnej spełnia wymagania
postawione w fazie poprzedniej

Metody:

–

przeglądy techniczne oprogramowania (przegląd techniczny wykonywalnej specyfikacji
programu)

–

dowodzenie poprawności

–

symulacje i prototypowanie

–

śledzenie wymagań

Warto zapamiętać!

–

wydajność testowania to 2-4 błędów/h, a przeglądów 10-12 błędów/h

–

pracochłonność poprawy błędów wykrytych w testowania to 10-40 h/błąd, a w wyniku
przeglądu 1 h/błąd

Testowanie

Testowanie – proces sprawdzania/oceny, czy produkt lub jego część jest „dobra”.

Atestowanie (walidacja) – testowanie zgodności systemu z rzeczywistymi potrzebami
użytkownika

Klasyfikacja testów

Testy statystyczne – wykrywanie przyczyn najczęstszych błędnych wykonań oraz ocena
niezawodności systemu.

Schemat wykonania:

–

losowa konstrukcja danych wejściowych zgodnych z rozkładem prawdopodobieństwa tych
danych

–

określenie wyników poprawnego działania systemu na tych danych

–

uruchomienie systemu oraz porównanie wyników działania z poprawnymi wynikami

Niektóre cechy:

–

testowanie systemu w typowych sytuacjach

–

możliwość automatyzacji (brute force, sprawdzanie wszystkich możliwości?)

Miary niezawodności oprogramowania

–

prawdopodobieństwo wystąpienia błędnego wykonania podczas realizacji transakcji
•

stosowane głównie w przypadku testowania systemów o charakterze transakcyjnym
(operacje mogą się zakończyć wyłącznie sukcesem bądź ich anulacją)

•

wyliczane na podstawie częstości transakcji zakończonych niepowodzeniem

–

częstotliwość występowania błędnych wykonań
•

dotyczy głównie systemów, które nie posiadają charakteru transakcyjnego

•

określa przewidywalną liczbę błędnych wykonań w jednostce czasu

–

średni czas między błędnymi wykonaniami

•

szacowany czas pomiędzy wystąpieniem błędnych wykonań

–

dostępność systemu
•

określa prawdopodobieństwo dostępności systemu dla użytkownika w danej chwili

•

tylko błędy prowadzące do czasowej niedostępności systemu mają wpływ na tę miarę

•

zależy też od szybkości powrotu do stanu normalnego

Miary niezawodności pozwalają oszacować koszty konserwacji!

Testy funkcjonalne

–

system traktowany jako czarna skrzynka, która w nieznany sposób realizuje wymagane
funkcje

–

dane wejściowe dzielone na klasy, których działanie powinno być podobne

–

sprawdzamy działania funkcji dla:
•

wszystkich dopuszczalnych warunków wejściowych i opcji

•

danych na granicach dziedzin wejściowych

•

danych na granicach dziedzin wynikowych

•

danych dla granic funkcjonalnych

•

danych niepoprawnych, niespodziewanych i destrukcyjnych

Zasady wyboru testowanych funkcji i danych wejściowych:

–

możliwość wykonania funkcji jest ważniejsza niż jakość wykonania (tj. klient akceptuje
niedopracowane rozwiązanie, jeżeli chce mieć je jak najszybciej)

–

funkcje systemu znajdujące się w poprzedniej wersji są istotniejsze niż nowo wprowadzone

–

typowe sytuacje są ważniejsze niż wyjątki (lepiej żeby się wysypywało czasem niż często)

Testy strukturalne

–

zakładają znajomość sposobu implementacji testowanych funkcji

Wybrane kryteria doboru danych wejściowych

–

kryterium pokrycia wszystkich instrukcji (każda instrukcja wykonana co najmniej raz)

–

kryterium pokrycia instrukcji warunkowych (każdy warunek instrukcji warunkowej został
co najmniej raz spełniony i raz niespełniony

Dobór danych wejściowych dla pętli:

–

tak, by nie wykonała się żadna iteracja (lub minimalna liczba)

–

tak, aby wykonała się maksymalna liczba iteracji

–

tak, aby wykonała się przeciętna liczba iteracji

Testy statyczne

–

analiza kodu bez uruchomienia programu (efektywniejsze od strukturalnych!)

Techniki:

–

dowody poprawności (trudne)

–

metody nieformalne (inspekcje Fagana)
●

śledzenie przebiegu programu

●

wyszukiwanie typowych błędów, np.:
•

niezainicjowane zmienne

•

porównania liczb zmiennoprzecinkowych

•

indeksy wykraczające poza tablice

•

błędne operacja na wskaźnikach

•

błędy w instrukcjach warunkowych

•

niekończące się pętle

•

błędy popełniane dla granicznych wartości

•

błędne użycie/pominięcie nawiasów w złożonych wyrażeniach

•

nieuwzględnienie błędnych danych

Ocena liczby błędów

–

liczba błędów nie musi mieć związku z niezawodnością oprogramowania

–

liczba błędów ma bezpośredni wpływ na konserwację oprogramowania

Technika posiewania błędów

–

wprowadzamy celowo błędy w miejsca, w których potencjalnie mogą znajdować się inne
błędy

–

wykrywanie błędów może dodatkowo ujawnić te, które nie zostały wprowadzone celowo

–

wymaga znajomości na temat tego, w których częściach programu mogą znajdować się
błędy

Testy systemu
Techniki:

–

testy pod obciążeniem

–

testy odporności
•

zanik zasilania

•

awaria sprzętowa

•

wprowadzenie niepoprawnych danych

•

sekwencja niepoprawnych poleceń

Bezpieczeństwo oprogramowania

–

systemy krytyczne z punktu widzenia bezpieczeństwa to takie, w których błędne wykonania
mogą prowadzić do zagrożenia życia i zdrowia ludzkiego oraz spowodować duże straty
materialne lub złamanie przepisów prawnych

–

bezpieczeństwo nie jest tożsame z niezawodnością
•

system zawodny może być bezpieczny, jeżeli skutki błędnych wykonań nigdy nie są
groźne

•

niezawodność nie opisuje sytuacji wyjątkowych

•

niebezpieczeństwo może wynikać z awarii sprzętowych

Analiza drzewa błędów jako podstawowa technika zwiększania bezpieczeństwa

–

korzeniem drzewa jest jedna z rozważanych niebezpiecznych sytuacji

–

wierzchołkami są pośrednie sytuacje

–

unikanie niebezpieczeństwa polega na unikaniu jego przyczyn, czyli:
•

unikanie błędów podczas implementacji „wierzchołków” drzewa

•

zlecenie realizacji „wierzchołków” doświadczonym programistom

•

stosowanie technik programowania N-wersyjnego (tworzymy kilka implementacji tego
samego algorytmu i sprawdzamy, czy wszystkie dają ten sam wynik)

•

szczególnie dokładne testowanie „wierzchołków”

W drzewach błędów można używać operatorów logicznych sumy, koniunkcji, wykluczenia.

Systemy jakości
Analogia między produkcją systemów informatycznych a produkcją towarów pzrzemysłowych na
początku XX wieku:

–

oprogramowanie jest zawodne

–

producent dyktuje warunki

–

niezadowalająca obsługa klienta

By poprawić sytuację stosuje się systemy jakości.

Zagadnienia systemów jakości:

–

powtarzalność
•

norma ISO9001 - „opisz to, co robisz, a potem postępuj tak jak napisano”

–

zapewnienie minimalnej liczby defektów
•

sprawność procesów biznesowych na poziomie „pięciu dziewiątek” (99,999%)

–

tworzenie coraz lepszych produktów
•

japońskie określenie „kaizen” - wprowadzanie stałych, drobnych informacji

•

„jeżeli możesz coś zrobić lepiej bez dodatkowego nakładu pracy, zrób to”

Jakość kosztuje:

–

opracowanie i wdrożenie standardów

–

stosowanie automatycznych narzędzi testujących

–

utrzymanie wewnętrznego działu jakości

–

znalezienie najlepszych ludzi

–

szkolenia

Klient musi mieć świadomość, że płaci dodatkowo za jakość.

CMM (Capability Maturity Model)

–

model dojrzałości procesu wytwarzania, opracowany przez Instytut Inżynierii
Oprogramowania (ang. się) w Carnegie Mellon University w Pittsburghu na początku lat
90tych dla Departamentu Obrony USA

–

celem było uzyskanie metody oceny przydatności potencjalnych wykonawców (ustalono
próg na poziomie trzecim)

–

obecnie wykorzystywany jest SPICE korzystający z cech modeli CMM, Bootstrap i
ISO9003

Struktura modelu CMM

–

poziom 1 (początkowy)


brak porządnej inżynierii wymagań



słaba współpraca w zespole



zaniedbana analiza i projekt



brak procedur zapewnienia jakości



brak jasno określonych ról w zespole



systematycznie przekraczany czas i budżet



poziom większości firm informatycznych, które jednak pomimo tego potrafią
wprowadzać dobre produkty (dzięki umiejętnościom informatyków, ich zaangażowaniu
oraz tolerancji klientów na błędy)



do wejścia na kolejny poziom wymagane:
•

uporządkowanie procesu

•

zarządzanie projektem

–

poziom 2 (powtarzalny)


skok od chaosu do porządku



firma jest w stanie wprowadzić produkt o podbnej jakości wielokrotnie (powtarzalność)



kluczowe obszary działań:
•

zarządzanie wymaganiami

•

planowanie projektu (produktów, dat zakończenia, kamieni milowych, budżetu)

•

zarządzanie wykonawstwem (świadome i zorganizowane znalezienie wykonawcy,
określenie mu standardów jakości, terminów)

•

zapewnienie jakości oprogramowania (grupa odpowiedzialna za jakość, plan testów,
automatycznych procedur testowych, zbioru zalecanych praktyk programistycznych,
dokumentowanie działań związanych z testowaniem)

•

zarządzanie konfiguracją (stosowanie narzędzi informatycznych do centralizacji,
kontrole wersji)



do wejścia na kolejny poziom wymagane:
•

definicja procesu

•

zarządzanie produkcją

–

poziom 3 (zdefiniowany)


integracja, definicja procesów, standaryzacja



potrzeby ujawniają się w firmach średniej wielkości



kluczowe obszary działań:
•

program szkoleń

•

zintegrowanie zarządzanie oprogramowaniem
–

intranetowa baza wiedzy

–

inżynieria produktu

–

koordynacja między zespołowa

–

przeglądy partnerskie



do wejścia na kolejny poziom wymagane:
•

sterowanie procesem

•

zarządzanie ilościowe

–

poziom 4 (zarządzany, zmierzony)

–

zdefiniowanie, udokumentowanie i zbieranie miar (metryk)

–

ilościowa kontrola procesu informatycznego

–

kluczowe obszary działań:


zarządzanie ilościowe procesem – zbieranie danych dotyczących budowy: liczby godzin

poświęconych na realizację, liczebność zespołów, inwestycje w narzędzia, godziny
szkoleń i wydatki



zarządzanie jakością oprogramowania – liczba błędów, godziny testów, zgodność z
planem i wymaganiami, koszt wytworzenia jednej cechy w oprogramowaniu



kontrola kosztów budowy oprogramowania



do wejścia na kolejny poziom wymagane:
•

ulepszanie procesu

•

zarządzanie zmianami

–

poziom 5 (optymalizujący)


poziom czwarty ze sprzężeniem zwrotnym (czyli wykorzystujemy zebrane miary do
analizy i usprawnienia całości procesu)



kluczowe obszary działań:
•

przeciwdziałanie błędom

•

zarządzanie zmianą technologii

•

zarządzanie zmianą procesu

Dla każdego obszaru działań określono:

–

cele (goals)

–

zobowiązania (commitment to perform)

–

praktyki (ability to perform)

–

działania (acitivities performed)

–

miary i analizy (measurements and analysis)

–

sposoby weryfikacji (veryfying implementation)

Przykładowo dla poziomu drugiego, obszar planowania projektu:

–

cel: prace i role w projekcie zaplanowane i udokumentowane

–

zobowiązanie: projekt musi posiadać swojego kierownika, którego odpowiedzialnością jest
wynegocjowanie ról oraz stworzenie planu projektu

–

praktyka: istnieje formalny plan projektu zawierający następstwo działań, wymagania
techniczne, koszty, standardy etc.

–

działania: uczestniczenie grupy wykonującej projekt w procesie planowania, estymacje,
opisanie ryzyka etc.

–

miary i analizy: kroki milowe projektu

–

sposób weryfikacji: przeglądy projektu

CMM jest metodą certyfikacji, zawierającą wiele praktycznych wskazówek dla szefów i ich
zespołów.

Wybrane parametry firmy na 5-tym poziomie:

–

koszt złej jakości (koszt poprawy wszystkich błędów) to 4% całkowitych nakładów na
produkcję oprogramowania – na poziomie 1-szym ponad 50%

–

nie przekraczają zaplanowanych kosztów i czasu – na poziomie pierwszym przekraczają
czas średnio o 150%, koszt prawie o 200%

–

koszt tworzenia funkcji to 30% kosztów firmy z poziomu pierwszego

–

średnio 7.5 roku jest potrzebne, by wejść z poziomu 1 na 5

Model propagacji defektów (wg IBM)

Propagacja błędów (wg Pressmana)

–

koszt błędów w zależności od projektowania

Generalnie polega to na tym, że w każdej fazie produkcji (modelowanie, projektowanie, kodowanie,
testowanie) powstaje pewna ilość błędów. Część z błędów, które przechodzą do fazy następnej jest
wzmacniana, dodatkowo pojawiają się też nowe błędy. Dlatego poszukiwania błędów nie
powinniśmy zaczynać dopiero w fazie kodowania tylko już przy modelowaniu, bo ilość błędów
przepuszczonych i wzmocnionych przy modelowaniu i projektowaniu będzie duża i nie wyłapiemy
ich nawet przy efektywnym testowaniu.

Wady CMM:

–

duży skok jakościowy pomiędzy pierwszym a drugim poziomem (teoretycznie nie jest to
wada, ale firma może mieć problem ze zorganizowaniem się)

–

duży koszt wdrażania (dokumentacja, uzgodnienia, przeglądy, etaty dla nie-programistów,
koszt certyfikatów)

ISO a CMM

–

oba standardy typu „mów co robisz i rób, co mówisz”

–

firmy z ISO 9000 kwalifikują się najczęściej do 3-4 poziomu CMM

–

ISO ma charakter binarny (certyfikowana firma lub nie), CMM ma 4 poziomy certyfikacji

–

CMM bardziej ukierunkowany na firmy informatyczne

–

standaryzacja CMM bardziej złożona od ISO

Konserwacja oprogramowania

–

z punktu widzenia klienta jest to faza eksploatacji

–

z punktu widzenia producenta faza konserwacji (pielęgnacji, utrzymania)

Konserwacja do wprowadzanie modyfikacji. Klasy modyfikacji:

–

modyfikacje poprawiające
•

usuwają błędy z oprogramowania

•

poprawa błędów popełnionych w każdej fazie tworzenia oprogramowania

–

modyfikacje ulepszające
•

poprawiają jakość oprogramowania

•

poprawa wydajności funkcji

•

poprawa ergonomii interfejsu użytkownika

•

poprawa przejrzystości raportów

–

modyfikacje dostosowujące
•

dostosowują oprogramowanie do zmian zachodzących w środowisku jego pracy

•

zmiany wymagań użytkownika

•

zmiany przepisów prawnych dotyczących dziedziny problemu

•

zmiany organizacyjne po stronie klienta

•

zmiany sprzętu i oprogramowania systemowego

Przyczyny modyfikacji:

–

żądania użytkowników

–

decyzja kierownictwa firmy programistycznej (np. zwiększenie konkurencyjności
oprogramowania)

Koszty konserwacji

Obiektywne:

–

stabilność środowiska, w którym pracuje system

–

stabilność platformy sprzętowej i oprogramwania systemowego

–

czas użytkowania systemu

Czynniki wpływające na redukcję kosztów konserwacji:

–

znajomość dziedziny problemu

–

wysoka jakość modelu i projektu (spójność, stopień powiązań składowych, przejrzystość)

–

wysoka jakość dokumentacji technicznej (w pełni odpowiada systemowi, wystarczająco
szczegółowa, zgodna z przyjętymi standardami)

–

stabilność personelu

–

środowisko implementacji

–

niezawodność oprogramowania

–

inżynieria odwrotna

–

zarządzanie wersjami

Wniosek – wiele działań zmierzających do redukcji kosztów systemu musi być podejmowana już w
trakcie budowy systemu!