e-Informatica Software Engineering Journal SPEM/UML w specyfikacji procesów zarządzania projektem

SPEM/UML w specyfikacji procesów zarządzania projektem

Iwona Dubielewicz,  Jerzy Sas
Wydziałowy Zakład Informatyki,  Politechnika Wrocławska
{dubielewicz, sas}@ci.pwr.wroc.pl
Streszczenie

Celem rozdziału jest weryfikacja możliwości stosowania profilu SPEM/UML do specyfikacji procesów zarządczych. W pierwszej części przedstawiono najważniejsze pojęcia i notację wprowadzoną przez profil SPEM (profil dedykowany do opisu procesów inżynierii oprogramowania). W następnej części dokonano interpretacji pojęć określonych w [PMBO1996] w kategoriach metamodelu SPEM oraz opisano w notacji SPEM procedurę wydania produktu dla rzeczywistego procesu wytwórczego. Podane rezultaty należy traktować jako weryfikację przydatności SPEM do ujednolicenia opisu wszystkich procesów występujących podczas wytwarzania oprogramowania.

Wprowadzenie#

Projekty, podejmowane jako nietypowe działania, niosą ze sobą zwykle pewien stopień niepewności co do ich pomyślnej realizacji. W przypadku projektów informatycznych, w których sukcesem kończy się niewielki ich procent, od kilkunastu lat dużo uwagi poświęca się metodykom wytwarzania oprogramowania a także, odpowiedniemu dla każdej z nich, zarządzaniu. Z tych samych względów, dla których modeluje się oprogramowanie, stwierdzono potrzebę modelowania samego procesu wytwarzania oprogramowania. Jednolity i przejrzysty sposób opisu różnorodnych działań i aspektów procesu wytwarzania oprogramowania powinien pozwolić na zapanowanie nad złożonością procesu, ułatwić komunikacje pomiędzy członkami zespołu, wprowadzić ujednolicenie pojęć dla różnorodnych metodyk wytwarzania oprogramowania. Pojawił się więc postulat zdefiniowania uniwersalnego języka, który sprostałby tym wymaganiom. Odpowiedzią na takie zapotrzebowanie jest Software Process Engineering Metamodel ([SPEM2002]), zaproponowany przez OMG (ang. Object Management Group), który został pomyślany jako spójny zestaw pojęć do opisu procesu inżynierii oprogramowania.SPEM pozwala na definiowanie procesów i ich komponentów, wykorzystując do tego notacje i mechanizmy wprowadzone w UML [UML2001]. SPEM jest również profilem UML, bowiem tylko jako taki pozwala wykorzystywać notację i pojęcia do specyfikacji zachowań (diagramy aktywności i maszyny stanów).

Celem niniejszego rozdziału jest weryfikacja przydatności pojęć zaproponowanych w metamodelu SPEM do:

  • opisu elementów zarządzania projektem prezentowanych w publikacji A Guide to the Project Management Body of Knowledge ([PMBO2000]), która jest ‘biblią’ z zakresu zarządzania projektami informatycznymi,
  • opisu rzeczywistych prac spotykanych w procesie wytwarzania oprogramowania (weryfikację przeprowadzono na przykładzie konkretnego procesu występującego w trakcie wydania kolejnej wersji oprogramowania).

Rozdział składa się z trzech podstawowych części. W punkcie 2. przedstawiono podstawowe pojęcia zdefiniowane w profilu SPEM, a w kolejnym, trzecim, przeanalizowano możliwość zastosowania ich do opisu ‘procesowego podejścia’ do zarządzania podanego w [PMBO2000]. W podrozdziale czwartym przedstawiono jedną z procedur stosowanych w firmach produkujących oprogramowanie i opisano ją w pojęciach i notacji SPEM. Opis ten należy traktować jako weryfikację przydatności metamodelu SPEM.

Podsumowanie zawiera ocenę realizacji określonych wcześniej celów oraz uwagi na temat przydatności pojęć proponowanych w profilu SPEM.

Charakterystyka metamodelu SPEM#

SPEM jest metamodelem przeznaczonym do definiowania procesów i ich komponentów. W metamodelu zaproponowano minimalny zbiór elementów do modelowania procesu i nie wprowadzono żadnych ograniczeń ani dodatkowych modeli do opisu specyficznych zagadnień jak np. analiza, testowanie. Pojęcia wprowadzone w metamodelu można podzielić na :

  • opisujące strukturę procesu, do których należą: ProduktPracy, OpisPracy, Aktywność, RolaProcesu, WykonawcaProcesu;
  • opisujące cykl życia procesu, w tym Iterację, Fazę;
  • umożliwiające zarządzanie złożonością: KomponentProcesu, Proces, Dyscyplina.

Struktura procesu#

Podstawowym pojęciem w SPEM jest proces (ang. process). Jest on rozumiany jako element grupujący (pakiet) wszystkie składowe, za pomocą których proces jest definiowany.Modelem konceptualnym procesu jest współdziałanie abstrakcyjnych, aktywnych bytów zwanych RolamiProcesu (ang. ProcessRole), które wykonują operacje zwane Aktywnościami (ang. Activities) na konkretnych, rozróżnialnych bytach zwanych ProduktamiPracy (ang. WorkProduct).

fig1.png

Rys. 1. Model konceptualny procesu w SPEM

Źródło: [SPEM2002] Celem procesu jest uzyskanie zestawu produktów pracy w pożądanym, dobrze określonym stanie Występujące na rysunku 1. elementy są określone w następujący sposób:ProduktPracy jest czymkolwiek, co jest produkowane, konsumowane lub modyfikowane w procesie; ProduktPracy jest pewnego rodzaju np. dokument tekstowy, wykonywalny itp. Stany, w których może znaleźć się ProduktPracy, mogą być opisane za pomocą powiązanej z nim maszyny stanów. ProduktPracy może być wykorzystywany, modyfikowany lub wytwarzany w ramach OpisuPracy, która jest z nim związana.

Aktywność opisuje fragment pracy wykonywanej przez jedną RolęProcesu. Aktywność może składać się z atomowych elementów zwanych krokami (ang. step). Z drugiej strony aktywność jest specjalizacją ogólniejszego pojęcia, nazwanego OpisuPracy, będącego rodzajem operacji UML (ang. operation). OpisPracy reprezentuje złożone prace, dekompozycja których może być zamodelowana za pomocą diagramu aktywności (ang. activity diagram).

RolaProcesu opisuje rolę, odpowiedzialność i kompetencje pewnego bytu działającego w ramach procesu; jest specjalizacją ogólniejszego pojęcia, nazwanegoWykonawcąProcesu (ang. ProcessPerformer). WykonawcaProcesu określa właściciela zbioru OpisówPrac w procesie, w sytuacjach, gdy nie można wskazać właściciela procesu w terminach RoliProcesu.

W SPEM z każdym elementem modelu może być związany zbiór Przewodników (ang. Guidance), dostarczający szczegółowych informacji o elemencie modelu; przewodniki mogą być różnych rodzajów (ang. GuidanceKind), a do najważniejszych z nich należą: lista kontrolna (ang. check list), techniki (ang. techniques), wytyczne (ang. guideline), szablon (ang. template).

Wszystkie wymienione elementy metamodelu są reprezentowane specjalnymi ikonami:

fig2.png

Produkty Pracy
fig3.png

Aktywność
fig4.png

Opis Pracy
fig5.png

Rola Procesu
fig6.png

Wykonawca Procesu
fig7.png

Przewodnik

Cykl życia procesu#

Cykl życia (ang. lifecycle) to OpisPracy, której elementami składowymi są fazy (ang. phase). Cykl życia definiuje zachowanie kompletnego procesu, stosowanego w danym projekcie lub programie.Faza (ang. phase) to taki OpisPracy, w którym warunek wstępny określa kryteria wejścia do OpisuPracy, natomiast cel fazy, zwany kamieniem milowym, określa kryteria jej zakończenia; fazy są definiowane z dodatkowymi ograniczeniami dotyczącymi kolejności ich występowania.

Iteracja (ang. iteration) jest złożonym OpisemPracy z tzw. mniejszym kamieniem milowym. Iteracja reprezentuje zbiór aktywności (występujących na pewnym etapie wytwarzania oprogramowania), którego wynikiem jest wewnętrzne lub zewnętrzne wydanie (ang. release) produktu software’owego. SPEM nie narzuca dekompozycji faz na iteracje.

Zarządzanie złożonością#

Do zarządzania złożonością prezentacji procesu, SPEM wprowadza pojęcie KomponentuProcesu (ang. ProcessComponent) oraz jego specjalizacje: Proces (zdefiniowany w 2.1) oraz Dyscyplinę (ang. discipline).KomponentProcesu jest pakietem reprezentującym zbiór elementów, pozwalających opisać fragment procesu; KomponentProcesu jest wewnętrznie spójny i może być wykorzystany wraz z innymi komponentami do opisu kompletnego Procesu.

Dyscyplina jest pakietem, który grupuje te aktywności w procesu, które są związane z tym samym tematem (ang. theme [SPEM2002] str. 8-3). Wnioskując z przykładów podanych w [SPEM2002], [KRUC1998] aktywności zgrupowane w dyscyplinę dotyczą pewnego zasobu, artefaktu przetwarzanego w procesie (np. specyfikacja wymagań, model, konfiguracja). Przypisanie Aktywności do Dyscyplin jest dokonywane poprzez zależność kategoryzacji, z dodatkowym ograniczeniem, że każda Aktywność może być powiązana tylko z jedną Dyscypliną (każda Aktywność należy dokładnie do jednego pakietu). Taki podział Aktywności powoduje, że Przewodniki i ProduktyPracy wykorzystywane w tych Aktywnościach są analogicznie kategoryzowane.

W SPEM zdefiniowano również sześć relacji, jakie mogą występować między elementami metamodelu. Należą do nich m.in. wspomniana relacja kategoryzacji (ang. categorize), czy relacja poprzedzania (ang. precedes), która łączy dwa ProduktyPracy lub dwie Aktywności. Relacje są reprezentowane przerywanymi strzałkami, przy czym grot strzałki dotyka elementu zależnego. Pakiety, KomponentyProcesu oraz Dyscypliny są reprezentowane ikonami:

fig8.png

dla pakietu (dyscypliny) SPEM
fig9.png

dla procesu SPEM

Kompletny opis metamodelu SPEM można znaleźć w [SPEM2002] i [FTFR2002], a systematyczny opis w języku polskim w [DUBI2002].

Wybrane elementy procesu zarządzania projektem w metamodelu SPEM#

Nasuwa się pytanie, czy przy tak uniwersalnej notacji i semantyce zaproponowanych pojęć nie można wykorzystać ich do opisu procesu zarządzania projektem lub przynajmniej niektórych jego części.W ([PMBO2000], str.4) podstawowe pojęcie ‘projekt’ jest definiowane następująco:

Projekt (przedsięwzięcie) jest ‘chwilowym wysiłkiem’ (ang. endeuvour) podjętym w celu wytworzenia unikatowego produktu lub usługi. Chwilowość oznacza tu fakt, że każdy projekt ma swój początek i koniec. Unikatowość oznacza natomiast, że oczekiwany produkt lub usługa są odmienne (w zauważalny sposób) od innych, istniejących produktów lub usług. Projekt składa się z procesów, przy czym ‘proces jest serią akcji prowadzących do pewnego rezultatu’.

Porównując te dwie definicje z pojęciami określonymi w SPEM, należy uznać, że

  • projekt jest tożsamy z pojęciem procesu SPEM (‘wysiłek’ = OpisPracy, ‘produkt’= ProduktPracy, ‘ma początek i koniec’ = jest całością; ‘podjętym’ = bezosobowo określony WykonawcaProcesu)
  • proces (składający się z akcji) jest OpisemPracy w SPEM (składającej się z aktywności);

W [PMBO2000] wyróżniono dwie klasy procesów występujących podczas realizacji projektu:

  • procesy zarządzania projektem: opis i organizacja prac wykonywanych w projekcie; procesy te są spotykane w większości projektów;
  • procesy wytwórcze (zorientowane na produkt): specyfikowanie i budowa produktucelu projektu; są one zwykle definiowane przez cykl życia projektu i zmieniają się w zależności od dziedziny zastosowań produktu.

Profil SPEM jest przewidziany do specyfikacji procesu wytwarzania oprogramowania wobec czego procesy wymienione w drugiej kategorii można dobrze opisać wykorzystując pojęcia i notacje zaproponowane w tym profilu. Interesujące wydaje się natomiast zbadanie, jak procesy zarządcze mogą być zamodelowane w notacji SPEM.

Zarządzanie projektem jest w ([PMBO2000], str.6) rozumiane jako zastosowanie wiedzy, praktyki, narzędzi i technik do działań (wykonywanych w ramach projektu) tak, by spełnić oczekiwania inwestorów (ang. stackholders) dotyczące zakresu projektu, czasu jego trwania, kosztu i jakości uzyskanego produktu.

W tabeli 1. podano zidentyfikowane działania zarządzania (nazwane w niej procesami), które na tym poziomie opisu można utożsamiać z pojęciem Aktywności w SPEM (czyli specjalizacjami OpisuPracy). Dla tych Aktywności są ustalone i obszernie opisane w [PMBO2000] wejściowe i wyjściowe ProduktyPracy oraz stosowane techniki i narzędzia (odpowiedniki Przewodników w SPEM).

W kontekście SPEM zarządzanie projektem jest Dyscypliną, bowiem obejmuje ono działania, których wspólnym tematem jest ogólnie rozumiane ‘zarządzanie’ (czymś – por. tabela 1).

Z drugiej strony rozważając zarządzanie projektem jako pewną całość można je traktować również jako proces, na który składają się Dyscypliny określone w tabeli 1. – kolumna 1, mianem zakresów dziedzinowych (ang. domain area). Można bowiem zauważyć, że te tzw. zakresy dziedzinowe ‘kategoryzują’ procesy do pewnego ‘tematu’ (np. koszt, czas), rozumianego właśnie jako dyscyplina w SPEM. Zgodnie z definicją, w takim przypadku aktywność może być zakwalifikowana do wyłącznie jednej dyscypliny (i jest to spełnione). W [PMBO2000] wprowadza się tzw. grupy procesów zarządczych:

  1. inicjowania – (zwykle jeden proces) mają na celu przeprowadzenie oceny stanu projektu (lub jego fazy); często wchodzi w skład zarządzania zakresem projektu
  2. planowania – (zwykle wiele procesów) mają na celu zbudowanie planu wytwarzania oprogramowania; są przedmiotem częstych iteracji, ponieważ planowanie trwa przez cały cykl życia projektu
  3. wykonawcze – odpowiadają za wytworzenie oprogramowania poprzez wykonanie planu projektu; są silnie zależne od ustalonej struktury prac
  4. nadzorcze – realizują monitorowanie wykonania planu w celu wykrycia odchyleń od planu; efektem istnienia tych procesów może być powtórzenie procesów planistycznych
  5. zamykania – odpowiadają za skompletowanie kontraktu i ocenę końcową projektu

Zestawienie procesów zakwalifikowanych do poszczególnych grup podano w tabeli 1.

Podane w tabeli 1. grupy procesów można potraktować jako KomponentyProcesu zarządzania projektem, przy czym grupa procesów Nadzorcze jest takim KomponentemProcesu, który wykonuje się współbieżnie z pozostałymi komponentami realizowanymi sekwencyjnie.

Odwzorowanie procesów zarządzania projektem do grup procesów i obszarów dziedzinowych
Zakresy dziedzinowe, Grupy procesów Inicjowania Planowania Wykonawcze Nadzorcze Zamykania
Zarządzanie integracją projektu Opracowanie planu projektu Wykonanie planu projektu Zintegrowane nadzorowanie zmian
Zarządzanie zakresem projektu Inicjowanie projektu Planowanie zakresu Definicja zakresu Weryfikacja zakresu Nadzorowanie zmian zakresu
Zarządzanie czasem projektu Definicja aktywności Kolejkowanie aktywności Szacowanie trwania aktywności Opracowanie harmonogramu Nadzorowanie harmonogramu
Zarządzanie kosztem projektu Planowanie zasobów Szacowanie kosztów Budżetowanie Nadzorowanie kosztów
Zarządzanie jakością projektu Planowanie jakości Zapewnienie jakości Nadzorowanie jakości
Zarządzanie zasobami ludzkimi projektu Planowanie organizacyjne Rekrutacja personelu Budowa zespołu
Zarządzanie komunikacją w projekcie Planowanie komunikacji Dystrybucja informacji Raportowanie zachowania Zamknięcie administracyjne
Zarządzanie ryzykiem projektu Planowanie zarządzania ryzykiem Identyfikacja ryzyka Analiza jakościowa ryzyka Analiza ilościowa ryzyka Planowanie reakcji na ryzyko Monitorowanie i nadzorowanie ryzyka
Zarządzanie zakupami w projekcie Planowanie zakupów Planowanie przetargów Wybór dostawcy Administracja kontraktem Zakończenie kontraktu

Źródło: [PMBO2002], tłumaczenie własne

Przykład zastosowania SPEM do modelowania procedur wytwarzania oprogramowania#

W celu sprawdzenia praktycznej użyteczności metamodelu SPEM podjęto próbę zdefiniowania w kategoriach tego modelu wybranych elementów prostej metodyki zarządzania działem wytwarzania oprogramowania. Metodyka ta została opracowana dla potrzeb konkretnego producenta oprogramowania średniej wielkości. Zarys metodyki oraz założeń przyjętych przy jej opracowaniu można znaleźć w [SAS2002] a szczegółowy opis wszystkich elementów metodyki wraz ze wzorcami tworzonych dokumentów znajduje się w [RADL2002]. Ponieważ metodyka bazuje na powszechnie obecnie stosowanym podejściu procesowym (m.in. wymaganym przy wdrażaniu norm ISO 9001:2000) w dalszej części będziemy nazywać tę metodykę Metodyką Prostych Procesów (MPP).Pierwotnie MPP została opisana bez używania jakiegokolwiek formalizmu, w języku zrozumiałym dla grona pracowników podlegających jej wymaganiom. W opisie elementów metodyki użyto pojęć stosowanych wewnętrznie w środowisku wdrożenia w znaczeniach zgodnych z powszechnie używanymi.

W MPP wyróżniono siedemnaście typowych działań wykonywanych w dziale wytwarzania oprogramowania i nazwano je procesami a szczegółowe instrukcje przebiegu procesów nazwano procedurami. Terminologia stosowana w MPP została tak dobrana aby była zrozumiała dla programistów oraz odpowiadała przyjętym w firmie zwyczajom. Stąd odbiega ona od terminologii stosowanej w SPEM oraz od tej omówionej w punkcie 3.

Dla celów przykładu wybrano z MPP procedurę zamknięcia i wydania wersji oprogramowania (PZWW). Przedstawiony zostanie opis procedury w jego pierwotnej postaci oraz odwzorowanie pojęć stosowanych w opisie oryginalnym na pojęcia SPEM. Przebieg procedury zamodelowany zostanie za pomocą diagramu aktywności UML. W opisie pozostawiono oryginalne oznaczenia i symbole procedur, dokumentów i uczestników procesów występujących w MPP. Ze względu na ograniczoną objętość artykułu przytoczona tutaj pierwotna specyfikacja procedury została nieco skrócona – stąd brak objaśnienia niektórych użytych symboli. Pełny ich opis znajduje się w [RADL2002].

Specyfikacja procedury wydania wersji według MPP #

Cel: Przygotowanie do dystrybucji kolejnej wersji oprogramowania oraz osiągnięcie wysokiego poziomu jego jakości. Wymagania wstępne:

  • ustalony termin faktycznego zakończenia procedur realizacji zadań planowych (DP.05) w odniesieniu do wszystkich zadań umieszczonych w harmonogramie prac nad wersją;
  • uzupełnienie dokumentacji zadań wchodzących w skład wydania, w tym również przygotowanie uaktualnień instrukcji użytkownika przez dokumentalistę.

Wykonawcy procedury:

  • DP.PK – kierownik Działu Programistów (nadzór),
  • DP.IW – integrator wersji (odpowiedzialny za przebieg procedury),
  • DP.KZ – kierownicy integrowanych zadań,
  • DP.PT – testerzy,
  • DH.HK, DW.WK – kierownicy innych działów (informowani o zakończeniu wydania wersji),
  • DP.BA – administrator,
  • DW.WD – dokumentalista.

Odpowiedzialny za przebieg procedury PZWW: DP.IW – pracownik działu programistów na stanowisku kierownika projektu zwany dalej integratorem wersji (DP.IW). Sposób realizacji procedury PZWW:

PRZYGOTOWANIE:

  1. DP.PK ustala datę zamrożenia kodu oraz informuje o tym wszystkich kierowników zadań, wysyłając odpowiednią informację pocztą elektroniczną.
  2. DP.PK na podstawie listy zadań i poprawek zrealizowanych w wydawanej wersji systemu przygotowuje plan testów (dokument DP.09.D.01).
  3. DP.PK informuje wszystkich programistów przewidzianych do testowania (DP.PT) wysyłając im odpowiednią informację pocztą elektroniczną.
  4. Kierownicy zadań realizowanych w ramach wydania kończą realizację zadań i udostępniają ich rezultaty.
  5. Jeśli zadanie nie może być kompletnie zakończone przed ustaloną datą zamrożenia kodu – zadanie to wypada z planu realizacji. Kierownik takiego zadania informuje o tym DP.PK nie później niż na 4 dni robocze przed planowanym terminem zamrożenia kodu.
  6. W zaplanowanym dniu DP.PK sprawdza (przeglądając dokumenty DP.05.D.01) czy wszystkie planowane zadania zostały zakończone. Jeśli nie, to albo podejmu-je decyzję u usunięciu zadania z planu wydania, albo podejmuje decyzję o prze-sunięciu terminu wydania. W tym ostatnim przypadku:
    1. DP.PK modyfikuje opublikowany dokument DP.09.D.01,
    2. DP.PK powiadamia wszystkich DP.PT o przesunięciu terminu wydania,
    3. w wyznaczonym terminie powtarzany jest pkt. 6.
      INICJALIZACJA:
  7. DP.PK zleca DP.IW rozpoczęcie procedury wydania powiadamiając go o tym pocztą elektroniczną.
  8. DP.IW zamraża kod poprzez zamknięcie dostępu do repozytorium wszelkim osobom poza sobą.
  9. DP.IW pobiera z repozytorium komplet wszystkich źródeł (łącznie z innymi zasobami).
  10. DP.IW dokonuje pełnej kompilacji wszystkich modułów systemu.
  11. Po pomyślnym skompilowaniu wszystkich modułów DP.IW sprawdza działanie modułu uaktualniania struktury bazy danych. W przypadku błędów sam dokonuje odpowiedniej korekty.
  12. DP.IW udostępnia na wszystkich obsługiwanych platformach DBMS wybrane wypełnione i doprowadzone do wymaganej wersji bazy, które będą wykorzystywane w trybie wielodostępu przez testerów.
  13. DP.IW udostępnia testerom komplet skompilowanych modułów wykonywalnych oraz bazy danych przygotowane do testów.
    CYKL TESTOWANIA:
  14. DP.IW inicjuje kolejny cykl testowania pełnej wersji systemu, informując o tym osoby biorące udział w testowaniu.
  15. DP.BA analizując bazę danych o błędach sprawdza, czy wszystkie przewidziane i zlecone do poprawy błędy zostały faktycznie poprawione. Odnotowuje pozostałe błędy w bazie danych o błędach.
  16. DP.PT wykonują testy przydzielonych im modułów. Wszystkie zauważone błędy odnotowują w bazie danych o błędach oznaczając je znacznikiem w polu ,,Do poprawy.
  17. W trakcie trwania procedury testowania DP.IW czy instrukcje użytkownika do modułów zostały odpowiednio uaktualnione. Jeśli nie – żąda od kierownika odpowiedniego zadania natychmiastowego dostarczenia wytycznych do dokumentalisty i uaktualnienia instrukcji.
  18. DP.IW na podstawie listy zadań realizowanych w ramach wydania sprawdza, czy zostały uaktualnione opisy zmian w katalogu ,,Czytaj w odniesieniu do wszystkich zmodyfikowanych modułów. W razie braków żąda ich uzupełnienia od kierowników odpowiednich zadań.
  19. Po zakończeniu cyklu testowania DP.PK analizuje wykryte w trakcie testowania usterki zapisane w bazie danych o błędach. Przydziela je do poprawy wybranym programistom przesyłając im dokumenty DP.02.D.01.
  20. Jeśli w wyniku realizacji poprzedniego punktu DP.PK stwierdził, że nie ma już błędów wymagających poprawy, informuje o tym pocztą elektroniczną DP.IW. Przechodzimy do punktu ZAKOŃCZENIE TESTOWANIA.
  21. Programiści, wyznaczeni do poprawy wykrytych błędów, przystępują do realizacji przydzielonych im pakietów serwisowych.
  22. Po zakończeniu realizacji wszystkich pakietów serwisowych DP.IW ponownie kompiluje i konsoliduje wszystkie moduły i udostępnia je w ustalonej poprzednio lokalizacji w Intranecie.
  23. Jeśli w zakresie niektórych zadań podlegających testowaniu DP.PK nie stwierdził już błędów, to wpisuje odpowiednią adnotację dla tych zadań w dokumencie DP.09.D.01.
  24. Przechodzimy do punktu CYKL TESTOWANIA
    ZAKOŃCZENIE TESTOWANIA:
  25. Po zakończeniu testowania DP.IW uznaje aktualną zawartość repozytorium w ścieżce rozwojowej za zamkniętą i tworzy ze wszystkich projektów w repozytorium ich niezależne kopie.
  26. DP.IW uzupełnia bazę danych o błędach o wszystkie nie poprawione błędy (ze statusem: do poprawy), znajdujące się w bazie danych o błędach używanej w trakcie wydania wersji.
  27. DP.IW przekazuje DW.WD informacje o wszystkich zmianach dokonanych w trakcie testowania i poprawiania wykrytych błędów wpływających na wygląd i funkcjonalność oprogramowania.
  28. DP.IW odmraża kod.
  29. DP.IW informuje DP.PK o zakończeniu przygotowania wersji i przekazuje mu informacje o lokalizacji kompletu oprogramowania (wraz ze wszelkimi zasobami) gotowego do udostępnienia do dystrybucji.
  30. DP.PK sprawdza kompletność dostarczonego zestawu i kopiuje go do repozytorium wersji wydanej, gdzie będzie on dostępny dla DH i DW.
  31. DP.PK informuje o udostępnieniu kolejnej wersji systemu DH.HK i DW.WK wysyłając im wiadomość pocztą elektroniczną.
  32. DP.IW archiwizuje wszystkie źródła na płycie CD, którą przekazuje DP.PK.

Tworzone lub wykorzystywane dokumenty:

  • DP.09.D.01 – dokumentacja wykonania prac objętych wydaniem wersji,
  • DP.02.D.01 – specyfikacja pakietu błędów do poprawy,
  • DP.05.D.01 – strony główne zadań podlegających integracji.

Inne modyfikowane struktury informacyjne:

  • baza danych o zgłoszonych błędach,
  • baza danych o błędach wykrytych w trakcie integracji,
  • repozytorium wersji rozwojowej,
  • repozytorium wersji wydanej,
  • zarchiwizowane na nośnikach zasoby związane z wydaną wersją.

Inne przekazywane informacje: Przyjmuje się, że przekazywane informacje nie mające postaci dokumentów o określonym formacie są przekazywane pocztą elektroniczną:

  • powiadomienie o ustaleniu daty rozpoczęcia wydania (DP.PK – > DP.KZ)
  • powiadomienie o przydzieleniu zadań w zakresie testowania (DP.PK – > DP.PT)
  • powiadomienie o konieczności usunięcia zadania z planu wydania ze względu na opóźnienia (DP.KZ- >DP.PK).
  • przekazanie decyzji o usunięciu zadania z zakresu wydania (DP.PK – > DP.KZ).
  • poinformowanie o rozpoczęciu integracji (DP.PK – > DP.IW, DP.PT)
  • przekazanie informacji o zakończeniu fazy testowania (DP.PK – > DP.IW)
  • przekazanie informacji o zmianach w specyfikacji zewnętrznej wprowadzonych na etapie wydania wersji (DP.IW – > DW.WD)
  • przekazanie informacji o udostępnieniu wydanej wersji (DP.PK – > DW.WK, DH.HK)

Interpretacja elementów specyfikacji wg SPEM#

Następujące elementy definicji procesu mogą być odwzorowane na pojęcia metamodelu SPEM:

  • Cała procedura PZWW odpowiada pojęciu OpisPracy;
  • OpisPracy (procedura PZWW) jest elementem komponentem procesu-dyscypliny ,,Zapewnienie jakości;
  • Wykonawcy procedury (DP.PK, DP.IW, DP.KZ, DP.PT, DP.BA, DP.PP) odpowiadają RolomProcesu;
  • Ponieważ – zgodnie z definicją procesu – każda rola wprowadza odpowiadającą jej aktywność, to w procedurze PZWW występuje sześć aktywności. Wyłączono z tego zbioru marginalne role DH.HK, DW.WK i DW.WD ponieważ ich udział w procedurze jest bierny (tylko są informowani).
  • Wykonawca wymieniony w sekcji ,,Odpowiedzialny za przebieg procedury odpowiada WykonawcyProcesu.
  • Dokumenty wymienione w sekcji ,,Tworzone lub wykorzystywane dokumenty odpowiadają ProduktomPracy. Równocześnie każdy z tych dokumentów należy do osobnego rodzaju. Do ProduktówPracy zaliczyć należy też dane wymienione w sekcji ,,Inne wykorzystywane struktury informacyjne a w szczególności zawartości repozytoriów.
  • Procedura PZWW (jako OpisPracy) składa się z faz: PRZYGOTOWANIE, INICJALIZACJA, CYKL TESTOWANIA, ZAKOŃCZENIE TESTOWANIA. Dla tych faz można określić następujące kryteria wejścia i cele:
  • Kroki, na które dekomponuje się aktywność (będącą specjalizacją OpisuPracy) odpowiadają kolejnym punktom (1-32) wymienionym w sekcji ,,Sposób realizacji procedury
  • Występują następujące rodzaje Przewodników:
    • techniki – charakter takich przewodników mają szczegółowe objaśnienia realizacji kroków 11, 15, 21 (pełna postać opisu znajduje się w [DUBI2002],
    • szablony – szablony wytwarzanych dokumentów (DP.09.D.01, DP.02.D.01, DP.05.D.01) ([RADL2002])
    • lista kontrolna załączona do punktu 8. fazy ,,Zakończenie testowania ([DUBI2002]),

Diagram aktywności#

Dekompozycja procedura PZWW (będącej OpisemPracy) może być opisana diagramem aktywności. W poniższym diagramie aktywności stany akcji odpowiadają bądź pojedynczym krokom lub ich sekwencjom wykonywanym przez tę samą RolęProcesu. Stąd stany akcji zostały oznaczone indeksami kroków z opisu procedury. Tory odpowiadające RolomProcesu występującym w OpisiePracy oznaczono symbolami wykonawców procedury.

fig10.png

Rys. 1. Diagram aktywności dla procedury zamknięcia i wydania wersji

Podsumowanie#

W rozdziale przedstawiono charakterystykę metamodelu SPEM, który został pomyślany jako spójny zestaw pojęć do opisu procesu inżynierii oprogramowania. Pokazano jak wprowadzone w SPEM pojęcia oraz język UML można wykorzystać do opisu procesów zarządzania. Dokonano interpretacji podstawowych pojęć podanych w [PMBO2000] – ‘biblii’ z zakresu zarządzania projektami informatycznymi, na gruncie tego metamodelu. Kolejnym krokiem zastosowania SPEM do opisu realizacji projektu powinien być opis interakcji (przeplatania się) procesów wytwórczych i zarządczych (do tego należałoby wykorzystać elementy behawioralne UML, a w szczególności równoległe maszyny stanów).Z punktu widzenia praktyki wdrażania metodyki prowadzenia projektów informatycznych zastosowanie SPEM jest dyskusyjne. Wyrażenie przyjętego bądź zamierzonego sposobu działania w trakcie wytwarzania produktu programistycznego w kategoriach SPEM, a w szczególności użycia diagramów aktywności, sprzyja jego uporządkowaniu, wykryciu braków logicznych oraz zwiększa czytelność. Wymaga jednak znajomości języka UML przez wszystkich uczestników procesu, co w praktyce jest rzadkością – zwłaszcza jeśli wziąć pod uwagę, że uczestnikami procesu są nie tylko programiści.

Trudno spekulować o przyszłości SPEM’u. Aktualna wersja SPEM nie jest stabilna (kolejne dokumenty aktualizują jego zawartość [FTFR2002]), a dodatkowo, poważne zmiany zapowiadane w UML 2.0, mogą tę wersję metamodelu ponownie zmienić.

Bibliografia#

[DUBI2002] I. Dubielewicz i B. Hnatkowska, Zastosowanie profilu UML/SPEM do specyfikacji procesów zarządzania projektem informatycznym, 2002, Raporty Wydz. Zakł. Inform. PWr., Ser. SPR nr 5.
[FTFR2002] Final FTF Report of the Software Process Engineering Metamodel, May 2002, www.omg.org/issues, Finalization Task Force to the Platform Technical Committee of OMG.
[KRUC2000] P. Kruchten, Rational Unified Process, 2000, Addison-Wesley.
[PMBO2000] A Guide to the Project Management Body of Knowledge, 2000, www.pmi.org.
[PMBO2002] A Guide to the Project Management Body of Knowledge, 2002, www.pmi.org.
[RADL2002] P. Radliński i J. Sas, Przemysłowe wytwarzanie oprogramowania w oparciu o system procedur, 2002, Raporty Wydz. Zakł. Inform. PWr., Ser. PRE nr 11.
[SAS2002] J. Sas i P. Radliński, Organizacja pracy działu wytwarzania oprogramowania – podejście procesowe, pazdziernik 2002, IV Krajowa Konferencja Inżynierii Oprogramowania, Tarnowo P. k/Poznania.
[SPEM2002] OMG Software Process Engineering Metamodel, January 2002, www.omg.com.
[UML2001] OMG Unified Modeling Language Specification, September 2001, www.omg.com, Version 1.4.

©2015 e-Informatyka.pl, All rights reserved.

Built on WordPress Theme: Mediaphase Lite by ThemeFurnace.