1 / 31

Metody estymacyjne w zarządzaniu zmianami oprogramowana

Piotr Habela

PJWSTK, styczeń 2002

2 / 31

Plan prezentacji:

• Przedstawienie problematyki zarządzania zmianami

• Zapewnienie jakości oprogramowania w kontekście zarządzania zmianą; normy jakości

• Szablon procesu wprowadzania zmiany wg IEEE

• Omówienie miar funkcyjnych

• Podsumowanie

3 / 31

• Związane w szczególności z fazą pielęgnacji oprogramowania

• Zakłada zdefiniowanie zdyscyplinowanego procesu postulowania i nanoszenia zmiany:– Zabezpieczenie jakości modyfikowanego produktu;

– Określenie wszelkich aspektów współpracy z wykonawcą zewnętrznym.

• Wymaga dojrzałych rozwiązań w zakresie:– Dokumentacji oprogramowania;

– Zarządzania konfiguracją.

• Istnieją ważne przyczyny dla mierzenia „wielkości” rozpatrywanej zmiany.

Zarządzanie zmianą

Wprowadzenie zmian w oprogramowaniu może stanowić najbardziej surowy (i kosztowny) sprawdzian jakości

zarówno samego produktu jak i procesu jego wytwarzania i utrzymania.

4 / 31

Jak zapewnić jakość oprogramowania?

• Brak uniwersalnych kryteriów oceny samego produktu => przedmiotem norm jakości stają się

właściwości procesu wytwarzania

• ISO: „Jakość = stopień wypełnienia przez produkt wymagań klienta” => rola dokumentu

wymagań na oprogramowanie

• Zgodność procesów z normami:– Pomaga budować zaufanie odbiorców do wykonawcy;– Może być oficjalnym wymogiem (przepisy, kontrakt)

5 / 31

Norma ISO/IEC-12207• Centralne miejsce zarówno w międzynarodowym

jak i amerykańskim systemie norm• Uwzględnia podział na czynności wykonawcy

i odbiorcy• Definiuje działania obowiązkowe, rekomendowane

i dozwolone• Określa wymaganą strukturę procesów

obejmujących cały cykl życiowy oprogramowania• Dokument wysokiego poziomu:

– Nie przesądza metodologii oraz rodzajów dokumentacji– Pożądane może być zastosowanie innych norm

i metodologii celem sprecyzowania modelu cyklu

6 / 31

Zawartość normy

Procesy podstawowe Procesy pomocnicze Procesy organizacyjne

Dostrajanie

• Nabycie produktu• Dostarczenie• Budowa• Użytkowanie• Pielęgnacja

• Dokumentacja• Zarządzanie konfiguracją• Zapewnienie jakości• Weryfikacja• Walidacja• Przeglądy• Audyty• Rozwiązywanie problemów

• Zarządzanie• Infrastruktura• Doskonalenie• Szkolenia

Cykl życiowy

Struktura:

cykl życiowy <>- proces <>- czynność <>- zadanie

7 / 31

Unifikacja norm dot. cyklu życiowego

Rysunek zapożyczony z:ISO 12207 and Related Software Life-Cycle Standards Jim Moore, The MITRE Corporation

8 / 31

Inne istotne normy (1)• Główne obszary:

– Projektowanie;– Standardy dokumentacji;– Miary funkcjonalne;– Ergonomia;– Utrzymanie oprogramowania;– Zarządzanie projektem;– Jakość;– Definicja wymagań;– Bezpieczeństwo i ochrona;– Testowanie; weryfikacja i walidacja.

9 / 31

Inne istotne normy (2)

• Główne źródła:– IEEE;– ISO;– BSI;– Inne, zwł. amerykańskie (Mil, NASA, DoD)

• Dostępne nam źródła: materiały pochodne IEEE

• Preferowane: ISO

10 / 31

Źródło zmiany = „problem z oprogramowaniem”

• Nie każdy problem z oprogramowaniem implikuje konieczność naniesienia zmiany

• Rodzaje zmian:– Naprawcze (corrective): usuwanie wykrytych usterek

(najwyższy priorytet)

– Ulepszające (perfective): optymalizacja, zabezpieczenie przed skutkami błędów. Nie zmienia pierwotnej funkcjonalności!

– Dostosowujące (adaptive): dostosowanie do zmieniającego się środowiska systemu: wymagania, platforma, interfejsy…

• Klasyfikacja istotności zmiany: => różne tryby postępowania

– Ważność: krytyczna lub rutynowa;

– Pilność: nagła lub nie-nagła.

11 / 31

Szkic procesu zarządzania zmianą(na podstawie norm IEEE)

• Gromadzenie i analiza raportów problemów z oprogramowaniem (SPR)

• Klasyfikacja zgłoszeń i ew. wynikłych z nich wniosków zmiany w oprogramowaniu (SCR)

• Decyzje w sprawie wniosków zmian• Realizacja zmiany• Weryfikacja i walidacja• Zatwierdzenie zmiany przez użytkownika

Zmiana

Diagnoza ew. wniosek zmiany

Rozpatrzenie decyzja, dyspozycje

Modyfikacja raport z dokonania zmiany

Weryfikacja

Wydanie

Instalacja

Walidacja

zgłoszenie problemu

12 / 31

Gromadzenie i diagnoza zgłoszeń problemów

Użytkownik Specjalista z Maintenance Team

SPR

[tymczasowy]

SCR

Zgłoszenie problemu Diagnoza problemu

SCR

[prop. tymczasowego obejścia]

•Sprawdzenie SPR;•Odtworzenie problemu;•Badanie kodu i / lub dokumentacji;•Identyfikacja błędu;•Określenie przyczyny błędu;

13 / 31

Rozpatrzenie zgłoszeniaKierownik Projektu

Analiza wniosku

SPR

SCR

Określenie priorytetu i warunków realizacji

Decyzja w sprawie wniosku

Odrzucenie

Do realizcji

Do zbadania

Decyzja do zatwierdzenia

Decyzja

Do zatwierdzenia

[niekrytyczny LUB nagły]

[krytyczny I nie-nagły][decyzja o odrzuceniu]

[decyzja o uruchomieniu][niewystarczająca diagnoza]

14 / 31

Cykl życiowy zgłoszenia problemu

Przygotowanie

Diagnoza

Rozpatrzenie

Zamknięcie OdrzucenieRealizacja Uzupełnienie

15 / 31

Decyzje RadyRada

Przegląd zrealizowanych zmian

SPR

SCR

SMR

Zamknięcie problemu

Przegląd klasyfikacji aktualnych problemów

Przegląd krytycznych problemów

Zmiana klasyfikacji problemu

SPR

SCR

SPR

Decyzja w sprawie problemu

Przegląd krytycznych wniosków

SCR

Poprawki do wniosku zmiany

Odrzucony

Do realizacji

Do zbadania

[zatwierdzono]

[zgłoszono zastrzeżenia]

[problem do rozpatrzenia]

[potwierdzono realizację zmiany]

[brak dalszych zakończonych zmian]

[brak zastrzeżeń co do klasyfikacji]

[zmiana uznana za niepotrzebną]

[rozpatrzono krytyczne problemy]

[uzgodniono modyfikację]

[niewystarczająca diagnoza]

[brak dalszych wniosków]

16 / 31

Weryfikacja i walidacja

• Weryfikacja:– Kontrola kodu i dokumentacji– Testy zmienionego oprogramowania: modułu,

integracyjne oraz systemowe– Testy regresyjne

(ponieważ może to okazać się kosztowne, weryfikacji można poddawać jednocześnie całe pakiety zmian)

• Walidacja:– Testy akceptacyjne

17 / 31

Najważniejsze używane tu dokumenty• Dokumenty merytoryczne:

– SPR– SCR– SMR– Wszelkie modyfikowane dokumenty projektowe

• Proces ten odwołuje się do czterech kluczowych dokumentów projektu:

• Plan zarządzania projektem;

• Plan zapewnienia jakości oprogramowania;

• Plan zarządzania konfiguracją oprogramowania;

• Plan weryfikacji i walidacji oprogramowania.

18 / 31

Repozytorium konfiguracji po stronie odbiorcy oprogramowania

• Zapewnia dostęp (np. na potrzeby diagnozy problemuz oprogramowaniem) do całości udostępnionego modelu oprogramowania

• Inna charakterystyka użytkowania niż w środowisku produkcyjnym

• Zorientowane na dokumentowanie zależnościi wspieranie pomiarów funkcyjnych

• Ew. wsparcie dla indywidualnego procesu zarządzania zmianą

19 / 31

Konieczność mierzenia wielkości zmiany

• W przedstawionym procesie należy dodatkowo uwzględnić współpracę zlecającego i wykonawcy jak dwóch niezależnych podmiotów

• Zmiany są nieuniknione i kontrakt musi regulować sposoby ich wprowadzania i rozliczania: wymaga to oparcia się na jakiejś mierze „wielkości” oprogramowania

• Pożądane cechy takiej miary:– Jest powiązana z „wartością dla klienta”, tj. ilością dostarczonej

funkcjonalności;

– Odzwierciedla pracochłonność wytworzenia oprogramowania.

• Cecha o znaczeniu pierwszorzędnym:obiektywizm pomiaru

20 / 31

Miary funkcjonalne• Danymi wejściowymi nie są własności środowiska

czy metody implementacji, ale raczej model pojęciowy, mniej lub bardziej konsekwentnie zawężony do czystych wymagań funkcjonalnych

• Powstałe w latach 70-tych (A. Albrecht, IBM); wówczas przełom w myśleniu o rozmiarze oprogramowania

• Wyrosłe z obszaru systemów informacyjnych• Rozkwit w połowie lat 80-tych,

później straciły sporo na popularności; obecnie zdają się wracać do łask

• Wciąż relatywnie niedojrzałe (zob. standardy)

21 / 31

Metoda IFPUG(International Function Points User Group)

• Bezpośrednie rozwinięcie metody Albrechta• Prawdopodobnie najpopularniejsza obecnie miara

funkcjonalna• Brak statusu standardu prawnego• Podstawa naliczeń = 5 składników funkcjonalnych

(WE i WY użytkownika, zbiory danych wewn.i zewn., zapytania zewnętrzne),

ważonych jako proste, średnie lub złożone• Przewiduje 14 czynników korygujących• Krytyka: a) problemy z obiektywną oceną złożoności

b) wpływy rozwiązań techn. Lat 70/80-tych

22 / 31

Mk. II FPA(Function Point Analysis)

• Zarządzana przez komitet powołany w tym celu przez UKSMA (United Kingdom Software Measures Association)

• Istotnie uproszczona w stosunku do IFPUG:– Zlicza dla poszczególnych funkcji typy danych

wchodzących, wychodzących i liczbę różnych encji, do których następują odwołania;

– Elementy te nie są ważone;– Aktualna wersja odradza stosowania czynników

korygujących jako potencjalnie nieobiektywnychi (jak dowiodły doświadczenia), niezbyt skutecznych

23 / 31

Pomiar czy estymacja?

• Funkcjonalność dostarczona w programie przyjęta jako podstawowy „wymiar” oprogramowania

• Abstrahuje od wszelkich czynników niefunkcjonalnych• Podstawa dla znormalizowanych i porównywalnych miar:

– Produktywności [rozmiar/nakład pracy]

– Szybkości realizacji [rozmiar/czas realizacji]

– Niezawodności [liczba defektów/rozmiar]

• Może stanowić element metod estymacjiczasu realizacji lub pracochłonności,podczas produkcji lub pielęgnacji oprogramowania.

24 / 31

COSMIC-FFP (COmmon Software Measurement International Consortium

– Full Function Points) • Najnowsza inicjatywa wywodząca się z wcześniej

wspomnianych metod• Główne motywy:

– Efektywne wsparcie dla innych (poza MIS) rodzajów oprogramowania (real-time, komunikacyjne)

– Metoda naliczeń tak prosta, aby była faktycznie obiektywna

– Uwzględnienie aktualnych rozwiązań w dziedzinie oprogramowania (architektury wielowarstwowe, metody obiektowe)

– Przystosowanie do powstającej normy ISO-14143

25 / 31

COSMIC-FFP – krótka charakterystyka

• Pełna niezależność od czynników niefunkcjonalnych

WymaganiaFunkcjonalne

ProcesFunkcyjny

Podproces

Pp_PrzemieszczaniaDanych

Pp_ManipulacjiDanych

• Model kontekstowy:precyzyjne określenie granic mierzonego systemu

• Model oprogramowania COSMIC-FFP:– Procesy funkcyjne;– 4 rodzaje podprocesów przemieszczania– Podprocesy manipulacji– Pojęcie „grupy danych”

26 / 31

COSMIC-FFP na gruncie systemów informacyjnych

• S.I. to tradycyjna a zarazem najwdzięczniejsza domena dla metod opartych na punktach funkcyjnych

• Grupa danych jest tu utożsamiana z pojęciem encji. Utożsamienie jej zatem z klasą nie powinno być błędem.

• Z kolei definicja procesu funkcyjnego pozwala go odnieść bezpośrednio do szczegółowej specyfikacji przypadku użycia (choć z większą tym razem dbałością o minimalność tego modelu).

Proces funkcyjny stanowi unikalny zbiór przemieszczeń danych (wejścia, wyjścia, odczyty, zapisy), realizujący spójny i logicznie niepodzielny zbiór funkcjonalnych wymagań użytkownika. Jest uruchamiany bezpośrednio lub pośrednio poprzez aktora lub zdarzenie wyzwalające i zostaje ukończony, gdy wykonał wszystkie kroki wymagane jako odpowiedź na zdarzenie wyzwalające.

27 / 31

COSMIC-FFP – model kontekstowy oprogramowania

Aktor

I/OMierzone

oprogramowanieTrwałynośnik

ODCZYTY

ZAPISY

WYJŚCIA

WEJŚCIA

Granica systemu

"Front end" "Back end"

28 / 31

Sposób naliczania

Grupa danych 1

Grupa danych 2

Grupa danych 3

Grupa danych 4

Proces funkcyjny A E, X E X

Proces funkcyjny B E,W X R X

Proces funkcyjny C E W

Proces funkcyjny D E,X,R,W

Proces funkcyjny E E R,W E,R,W E,X

Zidentyfikowane rodzaje pod-procesów przemieszczania danych (wejścia – Entry = E, wyjścia – Exit = X, zapisy – Write = W i oczyty – Read = R), są następnie sumowane: E X R W

8 6 3 5 Wynik: 8+6+3+5= 22 Cfpu

Każdy proces funkcyjny musi zawierać:• Co najmniej jeden podproces E – jako sygnał inicjujący• Co najmniej jeden podproces W lub X – jako obserwowalny efekt.

29 / 31

Naliczenie punktów funkcyjnych - przykład

• Wyświetlenie pracowników zarabiających poniżej 1000 zł:– Kwota płacy (jako opis pracownika): E

– Dane do wyświetlenia: R, X => Łącznie: 3 Cfpu

• Odnotowanie sprzedaży i wystawienie paragonu:– Towar (wprowadzenie identyfikatora): E

– Liczba sztuk towaru (jako opis elementu sprzedaży): E

– Towar (nazwa do wydrukowania): R, X

– Sprzedaż (zapis w systemie): W

– Element sprzedaży (zapis w systemie): W

– Komunikaty błędów + komunikaty potwierdzające: X

=> Łącznie: 7 Cfpu

• Czy jest to obiektywna/powtarzalna miara?

30 / 31

Podsumowanie (1)

• Efektywne nanoszenie zmian wymaga solidnej dokumentacji, właściwego zarządzania konfiguracją oraz zdyscyplinowanego procesu.

• Normy cyklu życiowego oprogramowania, zwykle sformułowane na wyższym poziomie ogólności niż konkretne metodyki, wymuszają najistotniejsze dobre praktyki w tym zakresie. Przepisy lub inne regulacje mogą wymagać od wykonawcy i zleceniodawcy respektowanie określonych norm.

• Zmiany w oprogramowaniu są nieuniknione. Kontrakt musi precyzyjnie określać sposób ich realizacji.

31 / 31

Podsumowanie (2)

• Umowy dotyczące pielęgnacji oprogramowania wymagają obiektywnego sposobu określania wielkości zmiany

• Adekwatne w tym zastosowaniu są miary funkcjonalne.• W nowych propozycjach z tego zakresu odchodzi się od

jakichkolwiek czynników niefunkcjonalnych, właśnie celem zapewnienia obiektywizmu i porównywalności pomiarów.

• Metoda COSMIC-FFP pomimo wczesnego etapu rozwoju wydaje się pod tym względem bardzo obiecująca.

• Jak duże jest zagrożenie rozbieżnościami wynikającymi z różnic w sposobach zamodelowania (przypadki użycia, klasy) funkcjonalnie tożsamych systemów??