MODEL RAYLEIGHA W ZWINNYCH METODYKACH WYTWARZANIA OPROGRAMOWANIA

Transkrypt

1 ROZDZIAŁ 99 MODEL RAYLEIGHA W ZWINNYCH METODYKACH WYTWARZANIA OPROGRAMOWANIA Model Rayleigha to narzędzie służące do estymacji liczby wykrywanych w systemie informatycznym defektów, w trakcie realizacji tego systemu, oraz do predykcji liczby defektów ukrytych, które wyjdą na jaw dopiero po wdrożeniu systemu u klienta. Model ten ma ugruntowaną pozycję wśród klasycznych metodyk wytwarzania oprogramowania. Brak natomiast prac badających jego użyteczność w metodykach zwinnych. W rozdziale został opisany przeprowadzony w warunkach akademickich eksperyment, w którym, przy pomocy monitorowania pojawiania się defektów w projekcie informatycznym, weryfikowano poprawność działania modelu Rayleigha dla zwinnego procesu wytwarzania oprogramowania. Badano projekty studenckiego realizowane w procesie zbliżonym do programowania ekstremalnego. 1. WPROWADZENIE Bardzo istotnym elementem każdego procesu wytwarzania oprogramowania powinno być zarządzanie jakością. Istnieje kilka różnych definicji jakości w procesie wytwarzania oprogramowania. Według autorów [9] najważniejszy jest punkt widzenia klienta, który z kolei swoją wizję jakości zazwyczaj opiera na kilku zmiennych, takich jak: cena, niezawodność, wydajność, satysfakcja z użytkowania produktu i inne. Nie wszystkie te zmienne są mierzalne w związku z tym w [9] sugeruje się przybliżanie jakości przy pomocy liczby awarii systemu występujących w jednostce czasu i liczby defektów przypadających na milion linii kodu. Autorzy [4] podają, że zespół działań, których celem jest sporządzenie raportów informujących o jakości produktu i reagowanie gdy raporty te wskazują na niespełnienie założonych standardów, nazywany jest zapewnianiem jakości (quality assurance). Zgodnie z tą definicją zapewnianie jakości można oprzeć o wielkości zasugerowane w [9] są to wielkości mierzalne i łatwo można na ich podstawie określić wymagane standardy. Z wielkościami tymi jednak wiąże się dosyć poważny problem. Trudno wyliczyć ich wartości przed zakończeniem realizacji projektu. Jednym z narzędzi umożliwiających Marian Jureczko: Politechnika Wrocławska, Instytut Informatyki, Automatyki i Robotyki; Wybrzeże Wyspiańskiego 27, Wrocław; marian.jureczko@pwr.wroc.pl

2 M. Jureczko szacowanie liczby defektów jeszcze przed ukończeniem projektu jest model Rayleigha. Istnieje bogata literatura dotycząca zastosowania modelu Rayleigha w zarządzaniu jakością w projekcie informatycznym. Obszerne wyjaśnienie sposobu jego używania i zasady działania można znaleźć w [8], [10] i [11]. W [13] wykazano, że model Rayleigha, po odpowiednim dopasowaniu parametrów w rozkładzie Weibulla, jest jednym z najlepszych predykatorów liczby defektów. Porównywano tam dwie wersje modelu Rayleigha, z kilkoma różnymi modelami przyrostu niezawodności, opartymi o rozkład wykładniczy. Walidację modelu Rayleigha dla trzech różnych projektów programistycznych można znaleźć w [5]. Ponadto zaproponowano tam, w oparciu o te trzy projekty, sposób łączenia danych historycznych z różnych projektów w celu lepszego wykalibrowania modelu. Prowadzone są również badania mające na celu zwiększenie dokładności oszacowań dostarczanych przez model. Przykład takich badań opisano w [12], gdzie wprowadzono koncepcję punktów zmiany. Koncepcja ta polega na podzieleniu czasu na odcinki, na których stosuje się rozkłady z różnymi parametrami. Wszystkie wymienione powyżej prace, opisujące i rozwijające model Rayleigha, dotyczą zastosowania go w kaskadowym procesie wytwarzania oprogramowania. Eksperyment opisywany w tym rozdziale jest próbą udzielenia odpowiedzi na pytanie o możliwość zastosowania modelu Rayleigha do przewidywania liczby defektów w systemie wytworzonym w procesie zwinnym. Jedyną pracą łączącą model Rayleigha z metodykami zwinnymi, do jakiej udało się dotrzeć, jest [14]. Niestety praca ta, koncentruje się na zwinnym wytwarzaniu dokumentacji i nie próbuje nawet odpowiadać na sformułowane powyżej pytanie. Struktura tego rozdziału jest następująca. W podrozdziale 2 przedstawiono rozkład Weibulla i opierający się na nim model Rayleigha. Podrozdział 3 zawiera definicję i szczegółowy opis przeprowadzonego eksperymentu. W podrozdziale 4 przedstawiono uzyskane wyniki, a w podrozdziale 5 płynące z nich wnioski i potencjalne kierunki prowadzenia dalszych badań. 2. MODEL RAYLEIGHA I ROZKLAD WEIBULLA Model Rayleigha to narzędzie pozwalające estymować liczbę defektów w programie na podstawie danych historycznych. Jest on oparty o rozkład Weibulla i w związku z tym przed omówieniem samego modelu przedstawiony zostanie rozkład Weibulla ROZKŁAD WEIBULLA Rozkład Weibulla jest od dawna powszechnie używany do przeprowadzania analizy niezawodności. Jego cechą charakterystyczną jest to, że koniec wykresu 2

3 Model Rayleigha w zwinnych metodykach wytwarzania oprogramowania asymptotycznie dąży do zera, ale go nigdy nie osiąga. Dystrybuantę F(t) oraz funkcję gęstości prawdopodobieństwa f(t) tego rozkładu definiuje się następująco: F( t) = 1- e m f( t) = t t c m e ( t/ c ) m - ( t/ c ) m (1) (2) gdzie m to współczynnik kształtu, c współczynnik skali, natomiast t oznacza czas. Stosując rozkład Weibulla do zarządzania jakością w projekcie programistycznym wykorzystuje się jego funkcję gęstości prawdopodobieństwa. Służy ona do estymacji liczby, lub częstotliwości występowania defektów w funkcji czasu. W będącym tematem rozdziału eksperymencie badano liczbę wykrywanych defektów w funkcji czasu. Kształt funkcji gęstości rozkładu w istotny sposób zależy od wartości współczynnika kształtu m, co pokazano na rysunku 1. Dobór wartości współczynnika kształtu powinien być oparty o dane doświadczalne MODEL RAYLEIGHA Rys. 1 Gęstość prawdopodobieństwa rozkładu Weibulla (dla c=1) Model Rayleigha to narzędzie umożliwiające przewidywanie liczby defektów operacyjnych (defektów ukrytych w gotowym, przekazanym klientowi systemie) na podstawie historii występowania defektów w trakcie procesu wytwarzania oprogramowania. Prace [5], [8], [10], [11] i wiele innych pokazują zastosowanie Rys. 2 Model Rayleigha modelu Rayleigha w kaskadowych procesach wytwarzania oprogramowania. W procesach tych wyróżnia się fazy, np.: projekt wysokiego poziomu, projekt niskiego poziomu, implementacja, testy jednostkowe, testy integracyjne, testy systemu. Fazy te występują po sobie. Rozpoczęcie następnej ma miejsce dopiero po zakończeniu poprzedniej. W celu zastosowania modelu Rayleigha w takim procesie konstruuje się histogram, co pokazano na rysunku 2. Każdy słupek histogramu odpowiada liczbie defektów wykrytych w danej fazie procesu. Do tak skonstruowanego histogramu dopasowuje się rozkład Weibulla. 3

4 M. Jureczko Dopasowanie rozkładu polega na odpowiednim dobraniu jego parametrów (m, c). Następnie należy jeszcze go przemnożyć przez stałą równą liczbie defektów. Dzięki temu uzyskuje się funkcję f R, z której całka jest całkowitej równa liczbie defektów. Adekwatność uzyskanego rozkładu należy zweryfikować stosując test dopasowania, według autorów [3] najlepiej do tego celu stosować test Kołmogorowa Smirnowa lub ewentualnie test chi kwadrat. Jeżeli dopasowany rozkład będzie adekwatny do zebranych danych (historii występowania defektów w trakcie procesu wytwarzania oprogramowania) to licząc z uzyskanej z niego funkcji f R całkę, od miejsca w którym się zakończyła ostatnia faza procesu (w omawianym tu przykładzie faza testów systemu) do nieskończoności, dostajemy oszacowanie liczby defektów ukrytych w systemie. Model Rayleigha jest oparty o rozkład Weibulla ze współczynnikiem kształtu m=2, lub bliskim tej wartości. W [10] podano, że przyjęcie m=2 może prowadzić do konstrukcji modelu, który zaniża liczbę defektów operacyjnych i w praktyce często lepszy jest model z parametrem m=1,8. Najlepsze efekty uzyskuje się, gdy dobiera się wartość współczynnika na podstawie danych historycznych. W taki właśnie sposób postąpiono w opisywanym tu eksperymencie. 3. OPIS EKSPERYMENTU Podrozdział ten zawiera definicję eksperymentu, jego plan oraz opis sposobu przeprowadzenia DEFINICJA EKSPERYMENTU Obiekty badania: iteracyjny, zwinny proces wytwarzania oprogramowania, zbliżony do metodyki programowania ekstremalnego (XP); model Rayleigha jako narzędzie pozwalające na predykcję liczby defektów operacyjnych w systemie informatycznym. Cel eksperymentu: zweryfikowanie możliwości zastosowania modelu Rayleigha do opisywania liczby wykrywanych defektów w funkcji czasu, przy założeniu, że system informatyczny, w którym są wykrywane defekty, jest wytwarzany w zwinnym procesie; zbadanie skuteczności modelu Rayleigha w estymacji liczby defektów operacyjnych systemu informatycznego wytwarzanego w zwinnym procesie. Środowisko: badano projekty realizowane przez studentów piątego roku informatyki, studiów magisterskich. Tematyka projektów była różnorodna ŚRODOWISKO EKSPERYMENTU Eksperyment został przeprowadzony w środowisku akademickim. Badano projekty 4

5 Model Rayleigha w zwinnych metodykach wytwarzania oprogramowania realizowane w ramach zajęć projektowych przez studentów piątego roku informatyki. Studenci mieli przynajmniej kilkuletnie doświadczenie w posługiwaniu się obiektowymi językami programowania wynikające z odbytych przez nich zajęć dydaktycznych. Nowością dla nich natomiast były metodyki zwinne oraz wynikające z nich metody pracy, takie jak testy jednostkowe. Każdy projekt był realizowany przez czteroosobowy zespół, w którym jedna osoba pełniła funkcję kierownika projektu. Implementacja projektów trwała jeden semestr, z którego wyłączono ostatni miesiąc. Miesiąc ten został przeznaczony na testowanie. Testy były przeprowadzane przez innych studentów, niż ci, którzy projekt realizowali. Były to testy na zasadzie czarnej skrzynki. Miały one za zadanie zasymulować użytkowanie aplikacji przez użytkownika docelowego (klienta). Model Rayleigha ma za zadanie przewidywać liczbę defektów po zakończeniu fazy testów, w zastosowanym tu podejściu waliduje się go jako estymator liczby defektów wykrytych po ostatniej iteracji projektu, czyli w fazie testów. Podejście takie znajduje swoje uzasadnienie w wykładniczych modelach przyrostu niezawodności ([6], [7], [8], [10], [13], [15]). Z modeli tych wynika bowiem, że liczba błędów wykrytych podczas fazy testów jest dużo większa niż liczba defektów operacyjnych. Szacowanie przy pomocy modelu sumy defektów operacyjnych i defektów wykrytych podczas fazy testów i przyrównywanie ich do liczby defektów wykrytych podczas testów nie prowadzi więc do dużej niedokładności. Stosowany proces wytwarzania oprogramowania był wzorowany na programowanie ekstremalnym w oparciu o [1] i [2]. Niestety z uwagi na formułę przedmiotu, w ramach którego projekty były realizowane, nie wszystkie zalecane w XP praktyki można było wyegzekwować. Stosowano iteracyjne podejście sterowane historiami użytkownika (historie składały się ze scenariusza głównego i ewentualnie alternatywnych). W każdej iteracji implementowano, uprzednio wybrane w ramach gry planistycznej (rolę klienta grał prowadzący) z zachowaniem praktyki opcjonalności, historie. Iteracje trwały jeden lub dwa tygodnie. Programowanie rozpoczynano od testów, zarówno na poziomie testów akceptacyjnych jak i jednostkowych. Nie udało się natomiast wdrożyć takich praktyk jak programowanie w parach (z uwagi na fakt, że studenci nad projektem pracowali w domu, a nie na zajęciach) czy też cykle kwartalne (to z uwagi na zbyt krótki czas realizacji projektu). W eksperymencie badano dziesięć projektów. Niestety, z powodu braków w danych, aż cztery projekty trzeba było odrzucić i analizie poddano jedynie sześć. W analizowanych projektach liczba defektów wykrytych przed przekazaniem systemu do testów wahała się od 21 do 57, średnio dla projektu wykrywano 43 defekty ZMIENNE W eksperymencie weryfikuje się dwie hipotezy, każda z nich opiera się na innych 5

6 M. Jureczko zmiennych. Przy weryfikowaniu, czy model Rayleigha poprawnie opisuje pojawianie się w funkcji czasu defektów, zmienną jest czas (numer iteracji) wykrycia defektu. Przy weryfikowaniu, czy model Rayleigha poprawnie przewiduje liczbę defektów operacyjnych, zmienną zależną jest liczba defektów wykryta podczas testów czarnej skrzynki, a zmienną niezależną oszacowana liczba defektów uzyskana z modelu HIPOTEZY Dla każdego z badanych projektów z osobna weryfikowano hipotezę zerową: H 0 x Rozkład empiryczny występowania defektów w funkcji czasu nie różni się w sposób istotny od rozkładu teoretycznego wynikającego z modelu Rayleigha. Hipotezę weryfikowano przy pomocy testu dopasowania x, gdzie x może się równać chi (test chi kwadrat) lub ks (test Kołmogorowa Smirnowa). H 1 x Hipoteza alternatywna. Rozkład empiryczny w istotny sposób różni się od rozkładu teoretycznego. Dla wszystkich badanych projektów łącznie weryfikowano hipotezę zerową: H 1 P Nie ma istotnej różnicy pomiędzy liczbą defektów znalezionych w projekcie podczas testów czarnej skrzynki, a predykcją tej liczby uzyskaną z modelu Rayleigha. H 1 P Hipoteza alternatywna. Istnieje istotna różnica pomiędzy empiryczną liczbą defektów, a predykcją modelu POMIARY W procesie wytwarzania oprogramowania zastosowano system śledzenia defektów Mantis. W systemie tym zgłaszano głównie defekty wynikające z niezaliczonych testów akceptacyjnych. Pojawiały się również postulaty dotyczące niedopasowania implementacji do oczekiwań klienta, oraz wykrycia złych praktyk programistycznych. Każde zgłoszenie odpowiadało jednemu defektowi. Data wprowadzenia zgłoszenia stanowiła podstawę do powiązania defektu z iteracją. Na podstawie liczby defektów skonstruowano histogram (wysokość słupka odpowiadała liczbie defektów zgłoszonych w iteracji), który był badany pod kątem zgodności z modelem Rayleigha. Na etapie testów czarnej skrzynki dwuosobowa grupa studentów testowała system wcielając się w rolę przyszłego klienta. Zgłaszano błędy dotyczące niezgodności ze specyfikacją, niestabilnego działania i niewłaściwych rozwiązań w interfejsie aplikacji. 6

7 4. WYNIKI EKSPERYMENTU Model Rayleigha w zwinnych metodykach wytwarzania oprogramowania Dla każdego z projektów skonstruowano histogram opisujący wykrywanie defektów w funkcji czasu. Do histogramu dopasowano rozkład Weibulla. Dla każdego projektu sprawdzono przy pomocy dwóch testów dopasowania, czy rozkład dobrze opisuje pojawianie się defektów. Rezultat tych kroków opisano w 4.1. Dla każdego, z uzyskanych w 4.1, modeli wyliczono analitycznie oszacowanie liczby defektów operacyjnych i porównano je z liczbą defektów wykrytych podczas testów czarnej skrzynki. Rezultat tego porównania przedstawiony jest w 4.2. Projekt 1 Projekt 2 m=1,8 m=2,5 Projekt 3 Projekt 4 m=1,9 m=1,7 Projekt 5 Projekt 6 m=2,59 m=1,75 Rys. 3 Defekty wykrywane w badanych projektach z dopasowanymi do nich rozkładami Weibulla 7

8 M. Jureczko 4.1. MODEL RAYLEIGHA JAKO ESTYMATOR LICZBY WYKRYWANYCH W TRAKCIE WYTWARZANIA OPROGRAMOWANIA DEFEKTÓW Na rysunku 3 pokazano histogramy wykrywania defektów w procesie wytwarzania oprogramowania dla poszczególnych, badanych projektów oraz dopasowane do nich rozkłady. Dla każdego z rozkładów podano uzyskany współczynnik kształtu m. Tabela 1. Wyniki zastosowania testów Kołmogorowa Smirnowa i chi kwadrat do uzyskanych rozkładów. P oznacza przyjęcia, a O odrzucenie hipotezy zerowej. Przy pomocy α oznaczono poziom istotności testu. Projekt α 0, 0,0 0,0 0, 0,0 0,0 0, 0,0 0,0 0, 0,0 0,0 0, 0,0 0,0 0, 0, ,01 H 0 ks P P P P P P P P P O P P O P P O P P H 0 chi P P P P P P O O P O O O O O P O O P W tabeli 1 pokazano dla których projektów udało się dopasować rozkład Weibulla tak dobrze, że test dopasowania pozwolił zaakceptować hipotezę zerową mówiącą o tym, że nie ma istotnej różnicy pomiędzy rozkładem teoretycznym, a danymi empirycznymi. Test Kołmogorowa Smirnowa pozwolił zaakceptować wszystkie rozkłady na najczęściej stosowanym poziomie istotności α=0,05. Natomiast, działający w stosunku do rozkładu Weibulla bardzo restrykcyjnie [3], test chi kwadrat, pozwolił przyjąć jako poprawne tylko niektóre spośród uzyskanych rozkładów MODEL RAYLEIGHA JAKO ESTYMATOR LICZBY DEFEKTÓW OPERACYJNYCH Tabela 2. Liczba defektów operacyjnych Projekt Liczba defektów znaleziona podczas testów czarnej skrzynki Predykcja liczby defektów operacyjnych uzyskana z modelu 6,55 1,04 1,83 3,54 2,26 1,18 W tabeli 2 przedstawiono rezultat zastosowania modelu Rayleiga do predykcji liczby defektów operacyjnych. Uzyskane wyniki pokazują, że model bardzo mocno zaniża liczbę defektów. Wartości uzyskane podczas testów czarnej skrzynki są zdecydowanie większe niż ich predykcje. Predykcje uzyskiwano wyliczając całkę z dopasowanego rozkładu na przedziale od końca ostatniej iteracji do nieskończoności. Rozmiar próbki jest zbyt mały, żeby można zweryfikować poprawność hipotezy H 0 P. W świetle uzyskanych wyników, wydaje się jednak bardzo mało prawdopodobne, aby hipoteza ta była prawdziwa. 8

9 Model Rayleigha w zwinnych metodykach wytwarzania oprogramowania 5. WNIOSKI I MOŻLIWOŚCI DALSZEGO ROZWOJU Przeanalizowane projekty programistyczne pozwalają stwierdzić, że schemat wykrywania defektów w czasie, w projekcie wykonywanym według zwinnej metodyki, jest podobny do tego, z jakim mamy do czynienia w projektach realizowanych według metodyk tradycyjnych. Zarówno w jednym, jak i w drugim przypadku schemat ten może zostać opisany przy pomocy modelu Rayleigha. Przebadano zaledwie sześć projektów. Stawianie ogólnych wniosków może więc być bardzo ryzykowne. Przebadane projekty mają bowiem ze sobą wiele wspólnego (wszystkie były realizowane przez niezbyt doświadczonych programistów studentów, w niezbyt długim okresie czasu jeden semestr). Uzyskane tu wnioski mogą więc nie mieć zastosowania do projektów informatycznych innych kategorii. Uzasadnione jest powtórzenie opisanego w tym rozdziale eksperymentu dla kolejnych projektów, w celu uzyskania statystycznie istotniejszych rezultatów. Druga z badanych hipotez, dotycząca możliwości predykcji liczby defektów operacyjnych projektu zrealizowanego według metodyki zwinnej przy pomocy modelu Rayleigha, nie została zweryfikowana. Rozmiar próbki nie pozwalał na uzyskanie statystycznie istotnych wyników, zdrowy rozsądek podpowiada jednak, że model nie przewiduje poprawnie liczby defektów operacyjnych. Powody, dla których model nie zadziałał prawidłowo, czyli tak jak działa w przypadku procesu kaskadowego, mogą być różne. Być może studenci zaniżali liczbę defektów w swoich aplikacjach, mając nadzieję, na zaprezentowanie tym sposobem swojej pracy w lepszym świetle. Możliwe jest również, że brak doświadczenia w przeprowadzaniu testów, powodował, iż produkt po ostatniej iteracji zawierał więcej defektów, niż by to miało miejsce w sytuacji, w której rozwijany by on był przez programistów mających doświadczenie w stosowaniu metodyk zwinnych. Otrzymanie ostatecznych wniosków co do możliwości zastosowania modelu do predykcji liczby defektów operacyjnych wymaga dalszych badań i przeanalizowania kolejnych projektów. Z punktu widzenia możliwości stosowania modelu Rayleigha, najciekawszym, potencjalnym wynikiem dalszych badań, jest znalezienie zależności funkcyjnej pozwalającej, na podstawie wyjścia modelu, wyliczyć liczbę defektów operacyjnych (w najprostszym przypadku byłoby to przemnożenie wyjścia modelu przez stałą). Wyznaczenie zależności funkcyjnej wymaga jednak zdecydowanie większej próbki niż ta, którą udało się uzyskać na potrzeby opisanego w tym rozdziale eksperymentu. Eksperyment pokazuje, że model Rayleigha nie sprawdza się w metodykach zwinnych tak dobrze, jak ma to miejsce w przypadku procesu kaskadowego. Sytuacja taka nie może zbytnio dziwić. W procesie kaskadowym początkowo stale rośnie rozmiar wytworzonego systemu, co może pociągać za sobą zwiększanie się liczby defektów. Natomiast końcowe fazy są poświęcone tylko testowaniu, więc liczba defektów powinna się zmniejszać. W metodykach zwinnych system rośnie, aż do samego końca. Na rzecz zmniejszania się liczby defektów przemawia jedynie widmo 9

10 M. Jureczko zbliżającego się wydania. Duża liczba defektów blisko terminu wydania zwiększa ryzyko niepomyślnego wdrożenia systemu u klienta. LITERATURA DO ROZDZIAŁU [1] Astels D., Miller G., Novak M.: Extreme programming: teoria i praktyka prowadzenia projektów programistycznych. Helion, Gliwice [2] Beck K., Andres C.: Wydajne programowanie: Extreme programming. Mikom, Warszawa [3] Cieślik G., Jóźwiak I., Jureczko M.: Applying Rayleigh model to predict software reliability. IEEE Transactions on Reliability, 2008, w recenzji. [4] Flasiński M.: Zarządzanie projektami informatycznymi. Wydawnictwo naukowe PWN, Warszawa [5] Galinac T., Golubić S.: Project overlaping and its influence on the product quality. Proc of the 8 th International Conference on Telecommunications, pp , [6] Goel A.L.: Software Reliability Models: Assumptions, Limitations, and Applicability. IEEE Transactions on Software Engineering vol. SE-11, no. 12, pp , [7] Huang C-Y.: Cost-reliability-optimal release policy for software reliability models incorporating improvements in testing efficiency. The Journal of System and Software no. 77, pp , [8] Kan S. H.: Modeling and software development quality. IBM Systems Journal, vol. 30, no. 3, pp , [9] Kan S. H., Basili V. R., Shapiro L. N.: Software quality: An overview from the perspective of total quality management. IBM System Journal, vol. 33, no. 1, pp. 4-19, [10] Kan S. H.: Metryki i modele w inżynierii jakości oprogramowania. Wydawnictow naukowe PWN, Warszawa [11] Li P.L.: A Catalog of Techniques that Predict Information about the Count or Rate of Field Defects. CMU tech report CMU-ISR , School of Computer Science, Pittsburgh, [12] Lin C-T., Huang C-Y., Chang J-R.: Integrating generalized Weibull-type testing-effort function and multiple change-point into software reliability growth models. Proc. of the 12 th Asia-Pacific Software Engineering Conference, [13] Lo J-H, Huang C-Y.: An integration of fault detection and correction processes in software reliability analysis. The Journal of System and Software no. 79, pp , [14] Luqi, Zhang L.: Documentation Driven Agile Development for Systems of Embedded Systems. Proc. Of the 4 th Workshop on Software Engineering for Embedded Systems, [15] Rinsaka K., Dohi T.: Optimal Testing/ Maintenance Design in a Software Development Project. Electronics and Communications in Japan (Part III: Fundamental Electronic Science), vol 89, no. 8, pp. 1-9,