Dostosowanie praktyk programowania ekstremalnego do wymogów standardu iso 9000



Pobieranie 56.78 Kb.
Data08.05.2016
Rozmiar56.78 Kb.

J.R. Nawrocki, B. Walter (red.), Wybrane problemy inżynierii oprogramowania, KKIO 2002

Dostosowanie praktyk programowania ekstremalnego do wymogów standardu ISO 9000

Michał Jasiński, Jerzy R. Nawrocki, Bartosz Walter, Adam Wojciechowski



e-mail: {Michal.Jasinski, Jerzy.Nawrocki, Bartosz.Walter, Adam.Wojciechowski} @cs.put.poznan.pl

Instytut Informatyki, Politechnika Poznańska

Streszczenie

Pomimo istnienia narzędzi poprawy procesów programowych (ang. SPI – Software Process Improvement) takich jak standard ISO 9000, czy model CMM, wciąż istnieje potrzeba szukania nowych, bardziej efektywnych rozwiązań. W erze ciągłych zmian (tak technologii, jak i wymagań) podejście reprezentowane przez CMM, czy ISO 9000 okazało się zbyt mało elastyczne. Na tym gruncie pojawiły się nowe, tak zwane „lekkie” metodyki rozwoju oprogramowania. Jedną z nich jest Programowanie Ekstremalne (ang. XP – Extreme Programming). Jednak, pomimo, że XP charakteryzuje się dużą lekkością procesów i proponuje wiele interesujących praktyk, posiada ono również pewne ograniczenia dotyczące m in. konserwacji oprogramowania. Ponadto, dość trudno byłoby wprowadzić XP do organizacji, która posiada certyfikat ISO 9001. Celem pracy jest zaproponowanie zmodyfikowanej wersji XP, która byłaby akceptowalna z punktu widzenia ISO 9000, a która zarazem zachowywałaby „lekkość” procesów rozwoju oprogramowania.

1. Wprowadzenie

Nie jest przesadą stwierdzenie, iż głównym czynnikiem rozwoju sektora ICT (ang. Information and Communications Technology) jest oprogramowanie. European Information Technology Observatory (EITO) szacuje, iż całkowita wartość rynku ICT w Europie Zachodniej osiągnie 678 miliardów Euro w roku 2002, z czego 11% (ponad 70 bilionów Euro) przypadnie właśnie na oprogramowanie [7]. Jednakże rynek ten staje się coraz bardziej wymagający. Zatem, aby osiągnąć sukces, organizacje wytwarzające oprogramowanie są zmuszone szukać nowych dróg w celu przyciągnięcia nowych klientów i utrzymania dotychczasowych. Jedną z możliwości jest uzyskanie certyfikatu ISO 9001:2000.

ISO 9000 to rodzina międzynarodowych standardów dotyczących ustalania i utrzymywania Systemu Zarządzania Jakością (ang. QMS – Quality Management System). Standardy te na dość wysokim poziomie abstrakcji opisują podstawy i słownictwo [3], wymagania [4] oraz wytyczne dotyczące poprawy funkcjonowania [5] takich systemów. Należy przy tym zauważyć, iż jedynym standardem z rodziny ISO 9000, do którego organizacja może się certyfikować jest ISO 9001. Standardy te mogą być wykorzystywane zarówno w prywatnej fabryce, jak i w instytucji państwowej, w stoczni, czy wreszcie w małej firmie programistycznej. ISO 9000 wywodzi się z Anglii i zyskuje coraz większą popularność. W 1997 roku na całym świecie wydano około 102 tys. certyfikatów, podczas gdy trzy lata później było ich już ponad 250 tyś. [15].

Opinie na temat ISO 9000 są mocno zróżnicowane. Przykładowo, dyrektor generalny British Standard Institute twierdził, iż ISO 9000 „wprowadzi oszczędności”, „zapewni satysfakcję klientom” oraz „zmniejszy niepotrzebne nakłady czasowe na opracowywanie i modyfikację projektów i procedur” [15]. Z drugiej strony barykady stoją tacy krytycy standardu ISO 9000, jak John Seddon. W jego opinii „po otrzymaniu etykietki standardu jakości, ISO 9000 spowodowało, że wkroczyła ona (jakość) na złą drogę. Będąc dalekim od pierwszego kroku w kierunku jakości ISO 9000 okazało się zarazem krokiem w złym kierunku. Nadzieja jedynie w tym, że kierownictwo organizacji nie straciło zainteresowania tym tematem” [15]. Pogląd ten zdaje się potwierdzać fakt, iż prawie 10% przedsiębiorstw w Australii zrezygnowało z odnowienia certyfikatu ISO 9001 [15]. Gdzie tkwią wady podejścia ISO 9000? Głównym zarzutem stawianym temu standardowi, są nadmiarowe wymagania dotyczące dokumentacji i związana z tym biurokratyzacja procesów. Ponadto, część osób postrzega ISO 9000 jako zbyt ogólne. Zaowocowało to nowymi propozycjami modeli oceny dojrzałości, w tym także dla oprogramowania [6, 14, 16]. Jednak pomimo tych trudności, niektóre przedsiębiorstwa zajmujące się produkcją oprogramowania zdecydowały się przejść przez proces certyfikacji do ISO 9001. Niebezpieczeństwo polega na tym, że w wyniku uzyskania certyfikatu zgodności ze standardem ISO 9001 powstanie dobrze udokumentowany, lecz niestety słabo wydajny system. Początkowy entuzjazm pracowników dotyczący poprawy procesów programowych szybko zniknie, kiedy zdadzą sobie oni sprawę, że certyfikat jakości ISO 9001 jest jedynie zabiegiem marketingowym, i że ich organizacja nie ma rzeczywiście zamiaru polepszać swoich procesów.

Z drugiej strony, kilka lat temu pojawiły się tak zwane lekkie (ang. lighweight lub agile) metodyki rozwoju oprogramowania. Jedną z najbardziej popularnych jest Programowanie Ekstremalne (ang. Extreme Programming, w skrócie XP). XP podkreśla znaczenie klienta obecnego podczas procesu tworzenia oprogramowania, komunikacji słownej, jakości produktu, krótkiego sprzężenia zwrotnego pomiędzy twórcami oprogramowania, a klientem i użytkownikami końcowymi, prostoty proponowanych rozwiązań, minimalizacji ilości tworzonych dokumentów i unikania nadgodzin. W kontekście współczesnego rynku ICT, XP jest o tyle interesujące, iż jest zorientowane na częste zmiany, a także kładzie nacisk na dostarczenie maksymalnej ilości funkcji w jak najkrótszym czasie. Typowa reakcja programisty na Programowanie Ekstremalne to: „Wreszcie metodyka dla ludzi, a nie ludzie dla metodyki.” Uważamy, że można i warto wykorzystać ten entuzjazm, jako punkt wyjścia do rzeczywistej poprawy procesów, którą można połączyć z wymaganiami ISO 9000. Niestety taki mariaż nie jest oczywisty. W artykule przedstawiamy propozycję zmodyfikowanej metodyki opartej na praktykach XP i zgodnej z ISO 9001:2000.

W kolejnym rozdziale przedstawiamy najistotniejsze cechy Programowania Ekstremalnego. W rozdziale trzecim omawiamy System Zarządzania Jakością organizacji z certyfikatem ISO 9001. Pokazujemy, w jaki sposób połączyć ogólny QMS proponowany przez standard ISO 9000 z bazą wiedzy organizacji zawierającą dokumenty, artefakty oraz inne dane związane z rozwojem oprogramowania. Skupiamy się przede wszystkim na dwóch częściach standardu ISO 9001:2000: realizacji wyrobu oraz na monitorowaniu i pomiarach. Realizacja wyrobu, oparta na praktykach XP i zgodna z ISO 9001:2000, jest opisana w rozdziale 4. Wykorzystujemy tu elastyczny, czteroetapowy schemat poprawy procesów przypominającym model CMM [14]. W rozdziale piątym opisujemy pomiary niezbędne z punktu widzenia ISO 9000, a które zarazem są użyteczne w kontekście praktyk XP. Ostatni rozdział przedstawia rezultaty pierwszych doświadczeń związanych z podejściem zaproponowanym w niniejszej pracy.



2. Programowanie Ekstremalne

Programowanie Ekstremalne [1, 2, 8] reprezentuje „nową falę” wśród metodyk rozwoju oprogramowania określaną mianem tzw. lekkiego podejścia. Tom de Marco, ojciec analizy strukturalnej, nazywa Programowanie Ekstremalne jednym z najbardziej istotnych zagadnień w inżynierii oprogramowania (patrz słowo wstępne do [2]). Cechy charakterystyczne XP, które świadczą o jego przewadze w kontekście współczesnych uwarunkowań rozwoju oprogramowania, to:



  • Minimalizacja ryzyka. Technologie i rynki informatyczno-telekomunikacyjne rozwijają się bardzo szybko. Aby nadążyć za zmianami, należy inwestować w nowe technologie i wypróbowywać nowe narzędzia. Z drugiej strony, są one często niedojrzałe i nie można na nich polegać. Najlepsze podejście to poczynienie pewnych (najlepiej niewielkich) inwestycji, które będą z czasem zwiększane w zależności od tego jak dana technologia będzie się dalej rozwijać (podobnie, jak w przypadku kupowania akcji na giełdzie). XP opiera się na przyrostowym modelu rozwoju oprogramowania i doskonale dopasowuje się do tej strategii.

  • Orientacja na klienta. W XP wszystkie decyzje biznesowe podejmowane są przez klienta, który ma tym samym pełną kontrolę nad rozwojem oprogramowania.

  • Brak niepotrzebnej dokumentacji. Programiści w XP koncentrują się na tworzeniu oprogramowania, a nie na pisaniu dokumentów. Jedynymi artefaktami, które muszą powstać w procesie rozwoju systemu są przypadki testowe i kod programu.

  • Zapewnianie jakości poprzez intensywne testowanie. Programowanie Ekstremalne wymaga, aby przypadki testowe były tworzone zanim powstanie kod. Zautomatyzowane testy oraz integracja modułów programowych wykonywana wielokrotnie w ciągu dnia są kluczowymi elementami procesu tworzenia oprogramowania.

  • Brak nadgodzin. Krótkie wydania (ang. release) i przyrosty (ang. increment) pozwalają szybko zdobywać nową wiedzę i doświadczenie. Powoduje to, że planowanie staje się łatwiejsze i jest bardziej przewidywalne. W konsekwencji, programiści nie muszą (zawsze) pracować w nadgodzinach.

Niestety, XP ma także słabe strony. Najistotniejszym problemem są kłopoty z konserwacją oprogramowania (ang. maintenance). Ponieważ jedynymi artefaktami są przypadki testowe i kod, zarządzanie nimi w dłuższym horyzoncie czasowym może okazać bardzo trudne. Ten aspekt, jest również kłopotliwy z punktu widzenia ISO 9000. W dalszej części artykułu przedstawimy naszą propozycję rozwiązania tego problemu.

3. Rozwój oprogramowania w organizacji z certyfikatem ISO 9001

Standard ISO 9001:2000 definiuje wymagania dla Systemu Zarządzania Jakością w podejściu procesowym. Oznacza to, iż oczekiwane rezultaty są osiągane w bardziej wydajny sposób, jeśli związane z nimi zasoby i czynności, włączając w to zwiększenie zadowolenia klienta, są zarządzane tak jak proces. QMS jest wyspecyfikowany w dokumencie posiadającym trójwarstwową strukturę, obejmującą Procesy Jakości (ang. Quality Processes) (wraz z tzw. Politykami Jakości (ang. Quality Policy)), Procedury Jakości (ang. Quality Procedures) oraz Instrukcje (ang. Work Instructions). Strukturę tą przedstawia rys. 1.

EMBED Visio.Drawing.5

Rys. 1: Trójwarstwowa struktura Księgi Jakości.

Problematyczny jest fakt, iż Instrukcje są czasami zbytnio zbiurokratyzowane. Dobrym przykładem takiego podejścia jest książka Trickera na temat ISO 9000 [18]. Zgodnie z jej wskazówkami pojedyncza Instrukcja powinna mieć co najmniej 16 stron. Połowa z nich zawiera informacje czysto administracyjne, takie jak metryczka dokumentu, lista adresatów dokumentu, wprowadzone poprawki, lista dodatków itp. Wszystko to sprawia, że dokumentacja Systemu Zarządzania Jakością staje się nadmiernie rozbudowana. Inną wadą podejścia proponowanego przez Trickera jest orientacja na formularze: Instrukcje skupiają się na opisywaniu, w jaki sposób należy wypełniać formularze wykorzystywane w Procedurach Jakości. Naszym zdaniem, Instrukcje powinny być znacznie skrócone (część elementów może być pominięta, inne, np. skróty i terminy, mogą zostać zebrane razem, a następnie umieszczone w osobnym dokumencie). Ponadto uważamy, iż Instrukcje powinny opisywać praktyki specyficzne dla danej metodyki rozwoju oprogramowania.

Naszym zdaniem organizacja, która stawia na jakość potrzebuje dwóch elementów:



  • ogólnego Systemu Zarządzania Jakością, operującego na dość wysokim poziomie abstrakcji,

  • Tezaurusa (rozumianego jako baza wiedzy), który powinien umożliwiać gromadzenie i wykorzystywanie wiedzy organizacji.

W Tezaurusie należałoby zamieścić szablony dokumentów, np. Planów Jakości, dane historyczne dotyczące poprzednich projektów etc. Informacje te są niezwykle istotne podczas planowania i poprawy procesu rozwoju oprogramowania. Ponadto, nieoceniona jest możliwość ponownego wykorzystania doświadczeń, którą dana organizacja zdobyła podczas realizacji poprzednich przedsięwzięć.

W ramach klauzul ISO 9000:2000 można wyróżnić dwie grupy. Pierwsza z nich opisuje ogólny System Zarządzania Jakością (rozdziału 4, 5 i 6), podczas gdy druga zawiera specyfikację wymagań dla metodyki, która może zostać wykorzystana przez organizację wdrażającą ISO 9000 (rozdziały 7 i 8 standardu ISO 9001:2000). W dalszej części artykułu skupimy się na wymaganiach narzuconych właśnie przez rozdziały 7 i 8 normy ISO 9001:2000.



4. Realizacja wyrobu: zmodyfikowane praktyki XP

Aby dostosować praktyki XP do wymagań dotyczących realizacji wyrobu, które narzuca ISO 9000, sugerujemy wykorzystanie Modelu Dojrzałości dla XP (ang. XP Maturity Model, w skrócie XPMM) [14]. Kluczowe Obszary Procesu (ang. Key Process Area) związane z odpowiednimi poziomami dojrzałości są następujące:



  • Zarządzanie Relacjami z Klientem (ang. Customer Relationship Management) (Poziom 2),

  • Zapewnianie Jakości Wyrobu (ang. Product Quality Assurance) (Poziom 2),

  • Programowanie Parami (ang. Pair Programming) (Poziom 3),

  • Wydajność Projektu (ang. Project Performance) (Poziom 4).

Poziomy dojrzałości XPMM są o tyle użyteczne, że pozwalają na wprowadzanie XP do danej organizacji w sposób stopniowy (z poziomu na poziom). Zapewnia to procesowi poprawy procesów programowych dość dużą elastyczność.

W kolejnym rozdziałach opisujemy Kluczowe Obszary Procesu modelu XPMM, wraz z modyfikacjami, które są niezbędne, aby zapewnić zgodność procesu rozwoju oprogramowania z wymaganiami ISO 9000:2000.



4.1 Zarządzanie Relacjami z Klientem

Zadowolenie klienta ma największe znaczenie zarówno w przypadku XP jak i ISO 9000. Jednakże w przypadku Programowania Ekstremalnego już na początku przedsięwzięcia wiemy o wiele więcej na temat sposobu, w jaki zadowolenie to można uzyskać. Poniżej zamieszczamy główne praktyki XP wpływające bezpośrednio na satysfakcję klienta:



  • CRM1: Historyjki użytkownika są wykorzystywane do opisywania wymagań. Są one sporządzane na małych kartkach papieru w języku naturalnym. Zwykle są bardzo krótkie i właściwie stanowią jedynie wprowadzenie do dyskusji pomiędzy klientem, a zespołem rozwijającym oprogramowanie, więc nie muszą w pełni wyczerpywać danego zagadnienia. Historyjki użytkownika nie są dokumentowane ani utrzymywane.

  • CRM2: Proces rozwoju oprogramowania jest podzielony na krótkie wydania (około 6-9 tygodni), zaś każde wydanie składa się z przyrostów (około 2-3 tygodni). W ramach każdego przyrostu realizowanych jest wybrany zbiór historyjek użytkownika. W momencie zakończenia danego wydania, produkt jest dostarczany użytkownikom końcowym. Zapewnia to szybkie sprzężenie zwrotne między klientem i użytkownikami końcowymi, a zespołem rozwijającym oprogramowanie.

  • CRM3: Plan wydania jest tworzony podczas gry planistycznej. Historyjki użytkownika dostarczone przez klienta są oceniane przez programistów. Szacują oni pracochłonność wymaganą do implementacji każdej z nich oraz oceniają ryzyko z tym związane. Posiadając wypracowaną w ten sposób wiedzę, klient wybiera te historyjki użytkownika, które będą realizowane w ramach bieżącego wydania.

  • CRM4: Komunikacja z klientem jest wspomagana za pomocą wybranej metafory systemu. System jest opisywany w sposób zrozumiały dla klienta i przyszłych użytkowników.

  • CRM5: Kod odzwierciedla wymaganą funkcjonalność. Funkcje systemu, które mają zostać zaimplementowane muszą być wybrane przez klienta, a nie przez programistów.

Głównym problemem w kontekście ISO 9000 jest brak udokumentowanych wymagań (metodyka Programowania Ekstremalnego wykorzystuje historyjki użytkownika zamiast udokumentowanych wymagań). Standard ISO 9001:2000 nie specyfikuje wprost potrzeby istnienia udokumentowanych wymagań, jednakże potrzeba taka wynika z poniższych klauzul:

  • (...) organizacja powinna określić (...) zapisy potrzebne do dostarczenia dowodów, że procesy realizacji i wyrób będący ich wynikiem spełniają wymagania.(...)” ([4], klauzula 7.1),

  • Organizacja powinna przeprowadzić przegląd wymagań dotyczących wyrobu. (...) Jeżeli klient przekazał wymagania w formie nieudokumentowanej, to organizacja powinna potwierdzić wymagania przed ich akceptacją. (...)” ([4], klauzula 7.2.2.),

  • Należy określić dane wejściowe związane z wymaganiami dotyczącymi wyrobu oraz utrzymywać zapisy. Powinny one obejmować: wymagania funkcjonalne i dotyczące parametrów (...). Wymagania powinny być kompletne, jednoznaczne i wzajemnie niesprzeczne. (...)” ([4], klauzula 7.3.2).

Potrzeba udokumentowanych wymagań jest także podkreślana w podejściu proponowanym w modelu CMM ([14], Kluczowy Obszar Procesu dotyczący Zarządzania Wymaganiami, Kompetencja 2). Powstaje zatem pytanie, w jaki sposób wprowadzić udokumentowane wymagania do lekkiej metodyki, jaką jest XP. Rozwiązanie tego problemu wymaga dostrzeżenia, że Programowanie Ekstremalne zostało stworzone jako lekka metodyka dla programistów, przez co kładzie dodatkowe obowiązki na barki innych osób m. in. reprezentanta klienta. Idąc dalej w tym kierunku, sugerujemy, aby odpowiedzialność za dokumentowanie i zarządzanie dokumentami przekazać na ręce testera. Jest to jedna z ról w zespole XP, której przypisano obowiązek implementacji przypadków testowych zaproponowanych przez klienta.

Zgodnie z tym co mówi Beck, tester jest „odpowiedzialny za pomoc klientowi podczas wyboru i tworzenia testów funkcjonalnych”[1]. Ponieważ wymagania i testy akceptacyjne operują na tym samym poziomie abstrakcji, zatem tester wydaje się osobą, która nadaje się najlepiej na analityka odpowiedzialnego za zarządzanie wymaganiami.



4.2 Zapewnianie Jakości Wyrobu

Zapewnianie jakości wyrobu jest adresowane w ISO 9000 przez klauzulę 7.3.5 Weryfikacja projektowania i rozwoju. Mówi ona m. in. „Weryfikację należy przeprowadzać zgodnie z zaplanowanymi ustaleniami w celu zapewnienia, że dane wyjściowe z projektowania i rozwoju spełniły wymagania określone w danych wejściowych do projektowania i rozwoju.”

Programowanie Ekstremalne pokrywa ten aspekt poprzez następujące praktyki:


  • PQA1: Testy powstają przed kodem programu. Oznacza to, że programista powinien najpierw stworzyć testy, a dopiero później może zacząć pisać kod. Praktyka to pomaga przede wszystkim lepiej zrozumieć, czego można oczekiwać od danego fragmentu programu. Ponadto, zapobiega to również sytuacjom, w których testy są definiowane w taki sposób, by zapewnić zgodność z napisanym już kodem, zamiast na odwrót.

  • PQA2: Testy jednostkowe muszą być zdefiniowane dla każdego fragmentu programu. Umożliwia to testy regresyjne.

  • PQA3: W przypadku znalezienia błędu, tworzone są dodatkowe testy. Praktyka ta również wspomaga realizację testów regresyjnych.

Ponadto, XP uzupełnia powyższy praktyki dwoma dodatkowymi:

  • PQA4: Częsta integracja. Pozwala to na uzyskanie szybkiego sprzężenia zwrotnego na temat bieżącego stanu tworzonego systemu.

  • PQA5: Optymalizacja jest odłożona na koniec. Działania optymalizacyjne wymagają dużych nakładów, a ponadto są potencjalnym źródłem błędów, które trudno zlokalizować i usunąć. Z tego powodu, dla zachowania wysokiej jakości oprogramowania, lepiej jest nie wprowadzać optymalizacji, o ile nie jest to naprawdę konieczne.

4.3 Programowanie Parami

Programowanie parami jest specyficzne dla Programowania Ekstremalnego, w związku z czym nie jest bezpośrednio związane z żadną z klauzul ISO 9000. Jednakże, aby możliwe było efektywne wykorzystanie par programistów, niezbędna jest otwarta przestrzeń pracy. Wiąże się to z klauzulą 6.3 Infrastruktura oraz 6.4. Środowisko pracy. Ponadto, warto w tym momencie podkreślić, że standard ISO 9000 wymaga zgodności z wymaganiami nie zaś zgodności ze zdefiniowanym procesem.

Praktyki związane z programowaniem parami są następujące:


  • PP1: Kod programu jest pisany według uzgodnionych standardów. W ten sposób o wiele łatwiej jest zrozumieć i modyfikować kod napisany przez kogoś innego.

  • PP2: Kod jest tworzony w parach. To podstawowa praktyka w projektach realizowanych zgodnie z metodyką XP.

  • PP3: Tylko jedna para może w danym momencie integrować kod. Jest to konieczne, aby zapewnić spójność kodu tworzonego systemu współdzielonego w ramach zespołu programistów.

  • PP4: Kod jest wspólną własnością wszystkich pracujących nad nim osób. Każdy może zmodyfikować dowolny fragment tworzonego oprogramowania, jeśli jest to konieczne.

  • PP5: Wykorzystanie systemu kontroli wersji. Praktyka ta wspomaga współwłasność kodu (PP4) oraz częstą integrację (PQA4).

5. Monitorowanie i pomiary

Standard ISO 9001:2000 opisuje monitorowanie i pomiary w bardzo ogólny sposób. Rozwijając oprogramowanie zgodnie z metodyką Programowania Ekstremalnego należy zwrócić uwagę na następujące klauzule:



  • 8.2.3 Monitorowanie i pomiary procesów. Celem wykorzystanych tu metod jest „(...) wykazać zdolność procesów do osiągania zaplanowanych wyników (...).” W kontekście XP powinno się zbierać dane dotyczące następujących metryk dotyczących procesu tworzenia oprogramowania:

  • Nadgodziny (na każdy dzień). XP zakłada brak godzin nadliczbowych. Metryka to pozwoli ocenić, jak bardzo dana organizacja zbliżyła się do idealnego procesu.

  • Czas dostępności reprezentanta klienta dla zespołu tworzącego oprogramowanie. Czas ten powinien być wykorzystany na odpowiedzi na pytania, rozwiązywanie konfliktów i tworzenie testów akceptacyjnych.

  • Tempo projektu, rozumiane jako ilość czasu, w ciągu tygodnia, jaki każdy członek zespołu może spędzić na realizacji przydzielonych mu zadań. Dane te są wykorzystywane podczas planowania.

  • Zapisy z integracji pozwalające stwierdzić, jak często nowe fragmenty kodu są integrowane z aktualną wersją tworzonego systemu (XP zaleca przeprowadzanie kilku integracji w ciągu dnia).

  • Tryb produkcji każdego fragmentu kodu (w parach bądź indywidualnie).

  • Szybkość programowania mierzona w liniach kodu na godzinę, ilości stworzonych przypadków testowych na godzinę, czy ilości przeprowadzonych testów akceptacyjnych na godzinę.

  • 8.2.4 Monitorowanie i pomiary wyrobu. W kontekście rozwoju oprogramowania najistotniejszym kryterium oceny jest raport z testów, prezentujący odsetek pozytywnie zakończonych testów jednostkowych i testów akceptacyjnych (zarówno jedne jak i drugie mogą obejmować testy funkcjonalne i wydajnościowe).

  • 8.3 Nadzór nad wyrobem niezgodnym. Standard ISO 9001:2000 wymaga, aby „(...) jeżeli wyrób niezgodny zostanie poprawiony, to należy poddać go ponownej weryfikacji w celu wykazania zgodności z wymaganiami. W podejściu reprezentowanym przez Programowanie Ekstremalne, nowa wersja systemu może zostać umieszczona w bibliotece jednostek elementarnych (ang. baseline library) dopiero wtedy, kiedy poprawnie przejdzie wszystkie testy modułów.

  • 8.5.2 Działania korygujące. Zgodnie z ISO 9001:2000 „(...) organizacja powinna podjąć działania eliminujące przyczyny niezgodności w celu zapobiegania ich powtórnemu wystąpieniu (...).” W celu przeciwdziałania ponownemu pojawianiu się defektów w oprogramowaniu, XP wymaga, aby dla każdego odnalezionego błędu tworzone były dodatkowe przypadki testowe. W konsekwencji, jeśli dany błąd wystąpi ponownie, taki test pozwoli go wykryć.

Pozostałe klauzule dotyczące monitorowania i pomiarów (8.2.1 Zadowolenie klienta, 8.2.2 Audit wewnętrzny, 8.4 Analiza danych, 8.5.1 Ciągłe doskonalenie oraz 8.5.3 Działania zapobiegawcze) są „przezroczyste” z perspektywy XP.

6. Wstępne wyniki

Podejście opisane w niniejszym artykule zostało zastosowane na tegorocznym Studium Rozwoju Oprogramowania (ang. Software Development Studio, SDS). Studium, utworzone na Politechnice Poznańskiej, jest organizacją tworzącą oprogramowanie, która pozwala studentom zdobywać doświadczenie praktyczne w zakresie rozwoju oprogramowania i poprawy procesów programowych [9]. Co roku realizowanych jest 11 projektów we współpracy z klientami wywodzącymi się z ośrodków naukowych oraz przedsiębiorstw. W każdym projekcie uczestniczy ośmioro studentów kierunku Informatyka: 4 osoby z trzeciego, 2 z czwartego i 2 z piątego roku studiów. Studenci ci pełnią różne role w kolejnych latach, zyskując doświadczenie w obszarze projektowania i programowania (trzeci rok), zarządzania przedsięwzięciem (czwarty rok) oraz zapewniania jakości (piąty rok).

Wszystkie projekty są realizowane w ciągu jednego roku akademickiego (9 miesięcy). Przykładowe przedsięwzięcia to, m. in.: Internetowe Środowisko dla Zarządzania Wymaganiami, Sieciowa Baza Danych dla Testów Wielokrotnego Wyboru, Internetowy System Analizy Wiedzy, System Badania Natężenia Ruchu Miejskiego i wiele innych.

W poprzednim roku akademickim przedsięwzięcia zostały podzielone na dwie grupy. Pierwsza z nich obejmowała przedsięwzięcia rozwijane zgodnie z modelem CMM, Poziom 2, podczas gdy druga zawierała projekty zarządzane zgodnie z „czystym” XP. Nasze obserwacje wykazały, iż przedsięwzięcia realizowane zgodnie z paradygmatem Programowania Ekstremalnego cierpiały, między innymi, z powodu:



  • braku precyzyjnie zdefiniowanego procesu,

  • niedostatecznej komunikacji pomiędzy klientem a zespołem tworzącym oprogramowanie (przedstawiciele klienta nie byli dostępni w stopniu jaki zakłada XP),

  • opóźnień w realizacji przedsięwzięcia i, co najważniejsze,

  • problemów z konserwacją tworzonego oprogramowania.

Jednym z objawów wymienionych wyżej problemów były kłopoty studentów trzeciego roku z napisaniem prac inżynierskich. Więcej szczegółów na temat tego eksperymentu można znaleźć w pracy [13].

Aby ocenić dojrzałość procesów inżynierii wymagań w przedsięwzięciach realizowanych na zajęciach SDS w tym roku akademickim, a następnie porównać je z danymi z lat ubiegłych wykorzystaliśmy model Sommerville’a-Sawyera [17]. Ten prosty trójpoziomowy model oparty jest na tak zwanych „dobrych praktykach” (ang. good practices). Somerville i Sawyer wyróżnili sześćdziesiąt sześć praktyk, które podzielili na trzy grupy:



  • podstawowe (ang. basic),

  • pośrednie (ang. intermediate),

  • zaawansowane (ang. advanced),

Każdej praktyce może zostać przypisane od zera do trzech punktów, w zależności od tego, w jaki sposób i w jakim zakresie jest stosowana. I tak odpowiednio przydzielane są:

  • 3 punkty, jeżeli dana praktyka jest standardem w danej organizacji,

  • 2 punkty, jeżeli jest często przestrzegana

  • 1 punkt, jeżeli jej wykorzystanie zależy od decyzji pracowników i jest dowolne,

  • 0 punktów, jeżeli dana praktyka nie jest w ogóle, albo jest bardzo rzadko przestrzegana.

Najwyższy poziom dojrzałości w modelu Sommerville’a-Sawyera nazwano Zdefiniowanym. Organizacje na tym poziomie muszą uzyskać powyżej 85 punktów za praktyki podstawowe oraz ponad czterdzieści punktów za praktyki pośrednie i zaawansowane. Poziom pośredni nosi nazwę Powtarzalnego, a organizacje na tym poziomie muszą zebrać, co najmniej 55 punktów za praktyki podstawowe. Najniższy poziom, Początkowy, przeznaczony jest dla organizacji, które zgromadziły mniej niż 55 punktów za praktyki podstawowe.

Na podstawie naszych wstępnych obserwacji, możemy stwierdzić, że połączenie ISO 9000 z metodyką Programowania Ekstremalnego zaowocowało znaczną poprawą w ocenie praktyk Somerville’a – Sawyera. Ponieważ samo XP adresuje zaledwie 6 praktyk podstawowych, 4 pośrednie i jedną zaawansowaną, przedsięwzięcia realizowane w tym podejściu w zeszłym roku zostały ocenione jako Początkowe [10]. Dla kontrastu, tegoroczne przedsięwzięcia w większym lub mniejszym stopniu wspierały większość z 66 praktyk modelu. Można to uznać za istotny wskaźnik poprawy.

Wynik oceny pokazuje, iż przedsięwzięcia realizowane zgodnie z przedstawioną w tej pracy metodyką zostały ocenione na poziomie Powtarzalnym. Jednakże wciąż istnieje potrzeba dalszych badań, które pozwolą ocenić dojrzałość nie tylko procesów związanych z inżynierią wymagań, ale także inne aspekty rozwoju oprogramowania, zwłaszcza te charakterystyczne dla XP i ISO 9000.

7. Podsumowanie

Podejście zaprezentowane w niniejszej pracy jest skierowane głównie do organizacji, które zidentyfikowały rozwój oprogramowania, jako jeden z kluczowych procesów, i które są zainteresowane rzeczywistą, nie zaś tylko pozorną, poprawą procesów opartą na standardzie ISO 9001:2000. Wstępne rezultaty są bardzo obiecujące, pokazując, że zaproponowane modyfikacje w metodyce XP spowodowały wzrost dojrzałości procesów, chroniąc wciąż jednocześnie programistów przed nadmierną biurokracją i zachowując lekkość procesów rozwoju oprogramowania.



Bibliografia

[1] Beck K., Extreme Programming: Embrace Change, Addison-Wesley, Boston. 2000.

[2] Beck K., Fowler M, Planning Extreme Programming, Addison-Wesley, Boston 2001.

[3] Polski Komitet Normalizacyjny, Systemy Zarządzania Jakością – Podstawy i terminologia (ISO 9000:2000). Wersja polska, PKN, 2001.

[4] Polski Komitet Normalizacyjny, Systemy Zarządzania Jakością – Wymagania (ISO 9001:2000). Wersja polska, PKN, wrzesień 2001.

[5] Polski Komitet Normalizacyjny, Systemy Zarządzania Jakością – Wytyczne doskonalenia funkcjonowania (ISO 9004:2000). Wersja polska, PKN, listopad 2001.

[6] Polski Komitet Normalizacyjny, Ocena procesu programowego (ISO 15504:1998). Wersja polska, PKN, 1998.

[7] European Information Technology Observatory, EITO2002 – 10th Edition 2000, European Information Technology Observatory, Bruksela, 2002.

[8] Jeffries R., Anderson A., Hendrickson C., Extreme Programming Installed, Addison-Wesley, Boston, 2001.

[9] Nawrocki J., Towards Educating Leaders of Software Teams: A New Software Engineering Programme at PUT, Proceedings of SEES 98, Scentific Publishers OWN, Poznań, 149-157, 1998.

[10] Nawrocki J., Jasiński M, Walter B., Wojciechowski A., Extreme Programming Modified: Embrace Requirements Engineering Practices, Proceedings of the 10th IEEE Joint International Requirements Engineering Conference, Los Alamitos, IEEE Press, 303-310, 2002.

[11] Nawrocki J., Wojciechowski A., Experimental Evaluation of Pair Programming, w: Maxwell K., Oligny S., Kusters R., van Veenedaal E. (eds.), Project Control: Satisfying the Customer, proceedings of ESCOM 2001, Shaker Publishing, 269-276, 2001.

[12] Nawrocki J., Walter B., Wojciechowski A., Toward Maturity Model for eXtreme Programming, Proceedings of the 27th EUROMICRO Conference, Los Alamitos, IEEE Press, 233-239, 2001.

[13] Nawrocki J., Walter B., Wojciechowski A., A comparison of CMM Level 2 and eXtreme Programming, Proceedings of the 7th European Conference on Software Quality, Helsinki, Lecture Notes in Computer Science 2349, Springer Verlag, 288-297, 2002.

[14] Paulk M. C., The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley, Reading MA, 1994.

[15] Seddon J., The Case Against ISO 9000, Oak-Press, Dublin, 2000.

[16] CMU/SEI, Capability Maturity Model Integration. Version 1.1, Staged Representation, Carnegie Mellon University/Software Engineering Institute, 2002.

[17] Somerville I., Sawyer P., Requirements Engineering: A Good Practice Guide, John Wiley & Sons, Chichester, 1997.



[18] Tricker R., Sherring-Lucas B., ISO 9000 in Brief, Butterworth-Heinemann, Oxford, 2001.

 Praca naukowa finansowana ze środków Komitetu Badań Naukowych w latach 2002-2005 jako projekt badawczy 4 T11F 001 23.


©absta.pl 2016
wyślij wiadomość

    Strona główna