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ądz 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óznienia
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ądz zródła danych lub
argumentów funkcji.
ą reprezentują zró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 zró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ądz 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 wskaznikach
" 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ą
grozne
" 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!
Wyszukiwarka
Podobne podstrony:
amd102 io pl09java io InvalidClassExceptionElektroenergetyka opracowanie1str 04 07 maruszewskiprzetworniki II opracowaneMechanika Techniczna I Opracowanie 06Marketing Opracowane Pytania Egzaminacyjne 2009 Furtak (46)grice opracowaniE Cooperative Principle, Maxims of Conversationlipidy opracowanie z ŚUM (1)Finanse Finanse zakładów ubezpieczeń Analiza sytuacji ekonom finansowa (50 str )więcej podobnych podstron