Metody estymacyjne w zarządzaniu zmianami oprogramowana

1. PJWSTK, styczeń 2002 Metody estymacyjne w zarządzaniu zmianami oprogramowana Piotr Habela

2. 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. Zarządzanie zmianą • 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. 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. 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. 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. Zawartość normy Cykl życiowy Dostrajanie Procesy podstawowe Procesy pomocnicze Procesy organizacyjne • 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 Struktura: cykl życiowy <>- proces <>- czynność <>- zadanie

7. Unifikacja norm dot. cyklu życiowego Rysunek zapożyczony z: ISO 12207 and Related Software Life-Cycle Standards Jim Moore, The MITRE Corporation

8. 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. 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. Ź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. 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

12. Gromadzenie i diagnoza zgłoszeń problemów • Sprawdzenie SPR; • Odtworzenie problemu; • Badanie kodu i / lub dokumentacji; • Identyfikacja błędu; • Określenie przyczyny błędu;

13. Rozpatrzenie zgłoszenia

14. Cykl życiowy zgłoszenia problemu

15. Decyzje Rady

16. 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. 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. 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. 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. 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. 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. 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. 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. 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. COSMIC-FFP – krótka charakterystyka • 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” • Pełna niezależność od czynników niefunkcjonalnych

26. 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. COSMIC-FFP – model kontekstowy oprogramowania

28. Sposób naliczania • 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. 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: Wynik: 8+6+3+5= 22 Cfpu

29. 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. 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. 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??