opracowanie io 15str


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 pl09
java io InvalidClassException
Elektroenergetyka opracowanie1
str 04 07 maruszewski
przetworniki II opracowane
Mechanika Techniczna I Opracowanie 06
Marketing Opracowane Pytania Egzaminacyjne 2009 Furtak (46)
grice opracowaniE Cooperative Principle, Maxims of Conversation
lipidy opracowanie z ŚUM (1)
Finanse Finanse zakładów ubezpieczeń Analiza sytuacji ekonom finansowa (50 str )

więcej podobnych podstron