©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 1 Ulepszanie procesu l Jak ulepszyć proces tworzenia oprogramowanie, aby w jego trakcie powstało doskonalsze oprogramowanie ?

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 2 l Poznać podstawowe zasady ulepszania procesu tworzenia oprogramowania. l Dowiedzieć, w jaki sposób czynniki procesu tworzenia oprogramowania wpływają na jakość oprogramowania i produktywność twórców oprogramowania. l Zrozumieć model CMM (Process Capability Maturity Model- model dojrzewania zdolności procesu), który można wykorzystać do oceny jakości procesu tworzenia oprogramowania w wielkich firmach. l Dowiedzieć, dlaczego ulepszanie, którego podstawą jest CMM, nie dotyczy wszystkich procesów tworzenia oprogramowania. Cele

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 3 l Jakość procesu i produktu l Analiza i modelowanie procesu l Miernictwo procesu l CMM l Klasyfikacja procesów Zawartość

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 4 l W ostatnich kilku latach w społeczności inżynierów oprogramowania pojawiło się ogromne zainteresowanie ulepszaniem procesu. l Ulepszanie procesu polega na rozpoznaniu istniejących procesów i zmodyfikowanie ich tak, aby poprawić jakość produktu lub zmniejszyć koszt i czas tworzenia. l W większości publikacji na temat ulepszania procesu skoncentrowano się na zwiększeniu jakości produktu, a w szczególności na zmniejszeniu liczby defektów w dostarczonym oprogramowaniu. l Dalszym zasadniczym celem ulepszeń, stanie się redukcja kosztu i czasu. Zainteresowanie ulepszaniem procesu

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 5 Właściwości procesu WłaściwośćOpis Procesu ZrozumiałośćDo jakiego stopnia proces jest jawnie zdefiniowany i jak łatwo jest zrozumieć jego definicję? JawnośćCzy czynności procesu kończą się jasnymi rezultatami, tak że postęp procesu jest jawny na zewnątrz? Podatność naDo jakiego stopnia czynności procesu można wspomagać narzędziami CASE? wspomaganie AkceptowalnośćCzy inżynierowie odpowiedzialni za tworzenie produktu programowego akceptują proces i czy są w stanie go używać? NiezawodnośćCzy proces zaprojektowano w taki sposób, aby unikać błędów w procesie albo zauważać je, zanim spowodują błędy w produkcie? SolidnośćCzy proces może być kontynuowany mimo niespodziewanych komplikacji? Zdatność doCzy proces rozwija się tak, aby odzwierciedlić zmieniające się wymagania pielęgnacjifirmowe lub zidentyfikowane ulepszenia procesu? BłyskawicznośćJak szybko można ukończyć proces dostarczenia systemu na podstawie zadanej specyfikacji?

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 6 Proces ulepszania procesu Model procesu Model procesu Dostosuj Zmiany procesu Dostosuj Zmiany procesu Wyszkól inżynierów Wyszkól inżynierów Zidentyfikuj ulepszenia Zidentyfikuj ulepszenia Zanalizuj proces Zanalizuj proces Wprowadź zmiany procesu Wprowadź zmiany procesu Plan zmian procesu Plan zmian procesu Plan szkoleń Plan szkoleń Informacje zwrotne o ulepszeniach Informacje zwrotne o ulepszeniach Poprawiony model procesu Poprawiony model procesu

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 7 l Analiza procesu l Identyfikacja ulepszeń l Wprowadzenie zmiany procesu l Szkolenia w związku ze zmianami procesu l Dostosowanie zmian Podstawowe etapy procesu ulepszania

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 8 Jakość procesu i produktu l Podstawą ulepszania procesu jest złożenie, że krytycznym czynnikiem wpływającym na jakość produktu jest jakość procesu tworzenia produktu. l Pomysł ulepszenia procesu pojawił się w pracach amerykańskiego inżyniera W. E. Deminga, który po drugiej wojnie światowej pracował w japońskim przemyśle nad poprawą jakości. Japoński przemysł na wiele lat zaangażował się w proces ustawicznego ulepszania (w języku japońskim nosi ono nazwę kaizen). Przyczyniło się to znacznie do ogólnie wysokiej jakości towarów produkowanych w Japonii.

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 9 Główne czynniki wpływające na jakość produktów programowych Jakość produktu Jakość produktu Technologia tworzenia Koszt, czas i harmonogram Jakość procesu Jakość personelu

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 10 Małe przedsięwzięcia l W wypadku małych przedsięwzięć, w których zespół składa się tylko z kilku członków, jakość zespołu wytwarzającego jest znacznie ważniejsza niż zastosowany proces tworzenia. l Jeśli poziom umiejętności i doświadczenia członków zespołu jest bardzo wysoki, to jakość produktu prawdopodobnie też będzie wysoka. l Jeśli członkowie zespołu są nieumiejętni i niedoświadczeni, to dobry proces może ograniczyć szkody, ale sam nie doprowadzi do zbudowania oprogramowania wysokiej jakości.

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 11 Analiza i modelowanie procesu l Analizowanie i modelowanie procesu polega na badaniu istniejących procesów i opracowywaniu ich abstrakcyjnych modeli, w których rejestruje się ich główne właściwości. l Analiza procesu polega na badaniu istniejących procesów w celu zrozumienia związków między różnymi jego częściami. l Początkowy etap analizy procesu jest nieuchronnie jakościowy- analityk po prostu stara się odkryć główne elementy modelu. Późniejsze fazy są bardziej ilościowe. l Proces podlega bardziej szczegółowej analizie za pomocą różnych miar, które gromadzi się automatycznie lub manualnie. Po zakończeniu analizy można ten proces zapisać w postaci modelu procesu.

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 12 l Kwestionariusze i wywiady. Inżynierowie pracujący w przedsięwzięciu są pytani o to, co się obecnie dzieje. Odpowiedzi na formalne kwestionariusze są dopracowywane w trakcie indywidualnych rozmów z osobami biorącymi udział w procesie. l Studia etnograficzne. Mogą posłużyć do zrozumienia natury budowania oprogramowania jako działalności człowieka. Taka analiza umożliwia odkrycie subtelności i złożoności, których nie ujawniono by za pomocą innych metod. Metody analizy procesów

Element modeluOpis procesu Czynność (przedstawianaCzynność ma jasno zdefiniowany cel oraz warunki wejściowy i wyjściowy. w postaci zaokrąglonegoPrzykładami czynności są przygotowanie zbioru danych testowych do testowania prostokąta nie rzucającego modułu, korekta dokumentu itd.. Zwykle czynność jest niepodzielna, tzn. jest zadaniem cienia)jednej osoby lub grupy. Nie dzieli się jej na czynności podrzędne. Proces (przedstawianyProces to zbiór czynności mający pewna spójność. Cel procesu jest ogólnie w postaci zaokrąglonegouzgodniony w ramach firmy. Przykładami procesów są analiza wymagań, prostokątaprojektowanie architektoniczne, planowanie testowania itd. rzucającego cień) Wynik (przedstawiony w Wynik jest namacalnym rezultatem czynności przewidzianym w planie postaci prostokątaprzedsięwzięcia. rzucającego cień) Warunek (przedstawiany wWarunek jest albo warunkiem początkowym. Który musi być spełniony przed postaci równoległoboku)rozpoczęciem procesu lub czynności, albo warunkiem końcowym, który jest spełniony po ukończeniu procesu lub czynności. Rola (przedstawiana w Rola jest ustalonym zakresem odpowiedzialności. Przykładami ról są menedżer okręgu rzucającego cień)konfiguracji, inżynier testów, projektant oprogramowania itp. Jedna osoba może odgrywać kilka ról, a jedną rolę można nadać kilku osobom. Wyjątek (nie występuje wWyjątek to opis sposobu modyfikacji procesu, gdy wystąpi jakieś przewidziane lub pokazanych przykładach, alenieprzewidziane zdarzenie. Wyjątki są zwykle niezdefiniowane. Często sposób można go przedstawić w postaciobsługi wyjątku zależy jedynie od talentu menedżerów przedsięwzięcia i inżynierów. prostokąta z podwójną krawędzią) Komunikacja (przedstawianaWymiana informacji między osobami lub między osobą i wspomagającym systemem w postaci strzałki)komputerowym. Komunikacja może być formalna lub nieformalna. K.formalna to np. akceptacja wyniku przez menedżera. K. nieformalna to m.in. Wymiana poczty elektronicznej w celu wyjaśnienia niejednoznaczności w dokumencie. Elementy modelu procesu

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 14 Proces testowania modelu Inżynier testów Inżynier testów Specyfikacja modułu Specyfikacja modułu Przetestuj moduł Przetestuj moduł Rola Podpisany rejestr testów Podpisany rejestr testów Dane testowe modułu Dane testowe modułu Model kompiluje się bez błędów składniowych Modułowi zadano wszystkie zdefiniowane testy Warunek początkowy Warunek końcowy Dane wyjściowe Odpowiada za Dane wejściowe Proces

Czynności wchodzące w skład testowania modułu ©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31. Slide ## Zadaj modułowi zaakceptowane testy Zadaj modułowi zaakceptowane testy Zgłoś raport do akceptacji Zgłoś raport do akceptacji Umieść wyniki testowania w systemie zarządzania konfiguracjami Umieść wyniki testowania w systemie zarządzania konfiguracjami Napisz raport o testowaniu modułu ze szczegółami wykrytych problemów Napisz raport o testowaniu modułu ze szczegółami wykrytych problemów Zarejestruj wyniki testów do testowania regresywnego Zarejestruj wyniki testów do testowania regresywnego Zintegruj moduł z uprzężą testową Zintegruj moduł z uprzężą testową Skompiluj uprząż testową Skompiluj uprząż testową Opracuj uprząż testową dla modułu Opracuj uprząż testową dla modułu Przeczytaj i zrozum interfejs modułu Przeczytaj i zrozum interfejs modułu Przeczytaj specyfikację modułu Przeczytaj specyfikację modułu Pobierz moduł z systemu zarządzania konfiguracjami Pobierz moduł z systemu zarządzania konfiguracjami Opracuj dane testowe zgodne ze specyfikacja Opracuj dane testowe zgodne ze specyfikacja Zgłoś dane testowe do przeglądu Zgłoś dane testowe do przeglądu Wykonaj przegląd danych testowych Wykonaj przegląd danych testowych PRZYGOTOWANIE DANYCH TESTOWYCH PRZYGOTOWANIE UPRZĘŻY TESTOWEJ DLA MODUŁU WYKONANIE TESTÓW PRZEKAZANIE RAPORTU Z TESTOWANIA

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 16 Wyjątki w procesie l Procesy budowania oprogramowania to procesy złożone. l Chociaż firma może mieć zdefiniowany model procesu, zawsze jednak jest on reprezentacją idealnej sytuacji, w której zespół wytwórczy nie napotyka żadnych niespodziewanych komplikacji. l W rzeczywistości nieoczekiwane kłopoty są chlebem powszednim menedżerów przedsięwzięć. l „Idealny” model procesu musi być dynamicznie aktualizowany w miarę znajdowania rozwiązań tych trudności.

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 17 l Kilka ważnych osób zapada na chorobę w tym samym czasie tuż przed krytycznym przeglądem przedsięwzięcia. l Następuje awaria procesora komunikacyjnego, co oznacza, że poczta elektroniczna nie działa przez kilka dni. l Następuje reorganizacja przedsiębiorstwa, co oznacza, że menedżerowie musza spędzić dużo czasu przy pracy nad kwestiami organizacyjnymi zamiast nad zarządzaniem przedsięwzięciem l Zgłoszono niespodziewaną propozycję nowego przedsięwzięcia. Siła robocza musi być przekazana z obecnego przedsięwzięcia do zadań związanych z nowa propozycją. Przykładowe rodzaje wyjątków

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 18 l Pomiar procesu daje ilościowe dane o procesie tworzenia oprogramowania. l Można na przykład monitorować czas i pracę niezbędna do testowania. l Skuteczne ulepszenie procesu testowania powinno umożliwić redukcje pracy, czasu lub obu tych wartości. l Miary procesowe nie mogą jednak posłużyć do oceny, czy poprawiono jakość produktu. Miernictwo procesu

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 19 l Czas spędzony nad ukończeniem konkretnego procesu l Zasoby niezbędne w konkretnym procesie l Liczba wystąpień konkretnego zdarzenia Klasy miar procesowych

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 20 l Cele. Co firma próbuje osiągnąć? l Pytania. Powstają z uszczegółowienia celów przez identyfikację konkretnych obszarów niejednoznaczności związanej z celami. Cel jest zwykle związany z pytaniami, na które trzeba znaleźć odpowiedź. Paradygmat GQM (Goal Question Metric - cel pytanie miara)

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 21 SEI CMM l Software Engineering Institute (SEI) w Carnegie-Mellon Uniwersity jest instytutem utworzony przez Departament Obrony Stanów Zjednoczonych. Jego misją jest przekazywanie technologii oprogramowania. l Wynikiem prac w ramach tej misji nad oceną zdolności jest CMM (Capability Maturity Model- model dojrzewania zdolności). Ma on ogromny wkład w przekonanie społeczności inżynierów oprogramowania do poważnego traktowania ulepszania procesu.

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 22 Model dojrzewania zdolności SEI Poziom 1 Początkowy Poziom 1 Początkowy Poziom 2 Powtarzalny Poziom 2 Powtarzalny Poziom 3 Zdefiniowany Poziom 3 Zdefiniowany Poziom 4 Zarządzany Poziom 4 Zarządzany Poziom 5 Optymalizowany Poziom 5 Optymalizowany

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 23 l Poziom początkowy. Firma na tym poziomie nie ma skutecznych procedur zarządzania ani planów przedsięwzięcia. Jeśli nawet istnieją jakieś formalne procedury do sterowania przedsiębiorstwem, to nie są one wykorzystywane. l Poziom powtarzalny. Firma na tym poziomie wdrożyła już formalne zarządzanie, zapewnianie jakości i procedury zarządzania konfiguracjami. Poziom nosi nazwę powtarzalnego, ponieważ firma może z powodzeniem powtarzać przedsięwzięcia tego samego rodzaju. l Poziom zdefiniowany. Firma na tym poziomie zdefiniowała już swój proces, ma więc podstawy do ilościowego ulepszania procesu. l Poziom zarządzany. Firma na tym poziomie zdefiniowała już swój proces i formalny program zbierania danych ilościowych. l Poziom optymalizowany. Firma na tym poziomie jest zaangażowana w ustawiczne ulepszanie procesu. Pięć poziomów modelu

Główne obszary procesu Programowe zarządzanie konfiguracjami Programowe zapewnianie jakości Programowe zarządzanie podwykonawcami Programowe śledzenie i przewidywanie przedsięwzięcia Zarządzanie wymaganiami Programowe zarządzanie konfiguracjami Programowe zapewnianie jakości Programowe zarządzanie podwykonawcami Programowe śledzenie i przewidywanie przedsięwzięcia Zarządzanie wymaganiami Powtarzalny Przeglądy partnerskie Koordynacja międzygrupowa Oprogramowana inżynieria produktów Zintegrowane zarządzanie oprogramowaniem Program szkoleń Definicja procesu przedsiębiorstwa Koncentracja firmy na procesie Przeglądy partnerskie Koordynacja międzygrupowa Oprogramowana inżynieria produktów Zintegrowane zarządzanie oprogramowaniem Program szkoleń Definicja procesu przedsiębiorstwa Koncentracja firmy na procesie Zdefiniowany Zarządzanie zmianami procesu Zarządzanie zmianami technologii Zapobieganie defektom Zarządzanie zmianami procesu Zarządzanie zmianami technologii Zapobieganie defektom Zarządzanie jakością oprogramowania Ilościowe zarządzanie procesem Zarządzany Optymalizowany Początkowy

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 25 l Przy omawianiu zdolności procesu w modelu CMM często zapomina się, że celem opracowania tego modelu było to, aby Departament Obrony Stanów Zjednoczonych mógł oceniać zdolność zleceniobiorców pragnących tworzyć dla niego oprogramowanie. l Uważa się, że firmy z wyższego poziomu mają przewagę w zdobywaniu kontraktów. l W przyszłości Departament Obrony będzie prawdopodobnie wymagać, aby firmy osiągnęły pewien poziom dojrzałości (przypuszczalnie poziom 3), zanim zaczną starać się o zlecenia na budowę oprogramowania. Ocena zdolności

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 26 Proces oceny zdolności Wybierz przedsięwzięcia do oceny Wybierz przedsięwzięcia do oceny Rozdaj kwestionariusze Rozdaj kwestionariusze Zanalizuj odpowiedzi Zanalizuj odpowiedzi Wyjaśnij odpowiedzi Wyjaśnij odpowiedzi Rozpoznaj kwestie do dyskusji Rozpoznaj kwestie do dyskusji Przeprowadź wywiady z menedżerami przedsięwzięć Przeprowadź wywiady z menedżerami przedsięwzięć Przeprowadź wywiady z menedżerami Przeprowadź wywiady z menedżerami Spotkaj się z menedżerami i inżynierami Spotkaj się z menedżerami i inżynierami Przedstaw ocenę Napisz raport Przeprowadź wywiady z inżynierami

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 27 l Klasyfikacja dojrzałości procesu zaproponowana w modelu SEI jest odpowiednia w wypadku wielkich i długotrwałych przedsięwzięć informatycznych realizowanych przez ogromne firmy. l Istnieje wiele innych rodzajów przedsięwzięć i przedsiębiorstw informatycznych, w których bezpośrednie zastosowanie tego punktu widzenia na dojrzałość procesu jest niemożliwe. Klasyfikacja procesów

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 28 Rodzaje procesów l Procesy nieformalne. Są to procesy, w których nie ma ściśle zdefiniowanego modelu procesu. Zespół wytwórczy sam wybiera proces. l Procesy zarządzane. Są to procesy, które obejmują zdefiniowany model procesu. Używa się go do kierowania procesem tworzenia. l Procesy metodyczne. Są to procesy, w których używa się pewnej metody lub metod tworzenia (takich jak np. systematyczne metody projektowania obiektowego). l Procesy ulepszane. Są to procesy, które w naturalny sposób obejmują ulepszanie jako cel.

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 29 Zastosowania procesów Proces zarządzany Proces zarządzany Proces metodyczny Proces metodyczny Dobrze rozpoznane dziedziny Zastosowań Systemy restrukturyzowane Dobrze rozpoznane dziedziny Zastosowań Systemy restrukturyzowane Wielkie systemy Produkty o długim czasie życia Wielkie systemy Produkty o długim czasie życia Prototypy Systemy o krótkim czasie życia Systemy gospodarcze Małe i średnie systemy Prototypy Systemy o krótkim czasie życia Systemy gospodarcze Małe i średnie systemy Proces nieformalny Proces nieformalny

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 30 Wspomaganie narzędziowe procesów Proces nieformalny Proces nieformalny Proces metodyczny Proces metodyczny Proces zarządzany Proces zarządzany Proces ulepszany Proces ulepszany Narzędzia Narzędzia Narzędzia Warsztaty Narzędzia uniwersalne do zarządzania do zarządzania analityczne specjalistyczne konfiguracjami przedsięwzięciami i projektowe

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 31 l Ulepszanie procesu obejmuje analizę, standaryzację, pomiary i zmianę procesu. Jeśli ulepszenie procesu ma być skuteczne, to nie można pominąć szkoleń. l Modele procesu to opisy czynności, podprocesów, ról, wyjątków, komunikacji, wyników i innych procesów. l Pomiarów należy używać do poszukiwania odpowiedzi na konkretne pytania na temat używanego procesu tworzenia oprogramowania. Podstawą tych pytań powinny być cele związane z ulepszaniem firmy. l Istnieją trzy typy miar procesów: miary czasowe, miary wykorzystania zasobów i miary zdarzeniowe. Główne tezy

©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 25 Slide 32 l W modelu CMM podzielono procesy tworzenia oprogramowania na początkowe, powtarzalne, zdefiniowane, zarządzane i optymalizowane. W modelu wskazano główne procesy, których należy przestrzegać na każdym z tych poziomów. l Model CMM nadaje się dla wielkich zespołów inżynierów budujących wielkie systemy. Nie należy go stosować bez adaptacji do lokalnych warunków. l Procesy można podzielić na nieformalne, zarządzane, metodyczne i ulepszane. Tej klasyfikacji można użyć do rozpoznania wspomagania narzędziowego dla procesu. Główne tezy