Model Rayleigha w zwinnych metodykach wytwarzania

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, 50-370 Wrocław; [email protected]
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.
2.1.
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
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-( t/c )
m
(1)
m
m
m t 
f(t ) =   e − ( t/c )
t c
(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.
2.2.
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
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ę fR, 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 fR 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.
3.1.
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.
3.2.
ŚRODOWISKO EKSPERYMENTU
Eksperyment został przeprowadzony w środowisku akademickim. Badano projekty
4
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.
3.3.
ZMIENNE
W eksperymencie weryfikuje się dwie hipotezy, każda z nich opiera się na innych
5
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.
3.4.
HIPOTEZY
Dla każdego z badanych projektów z osobna weryfikowano hipotezę zerową:
– H0 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).
– H1 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ą:
– H1 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.
– H1 P – Hipoteza alternatywna. Istnieje istotna różnica pomiędzy empiryczną
liczbą defektów, a predykcją modelu.
3.5.
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
Model Rayleigha w zwinnych metodykach wytwarzania oprogramowania
4. WYNIKI EKSPERYMENTU
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
m=1,8
Projekt 2
m=2,5
Projekt 3
m=1,9
Projekt 4
m=1,7
Projekt 5
m=2,59
Projekt 6
m=1,75
Rys. 3 Defekty wykrywane w badanych projektach z dopasowanymi do nich rozkładami Weibulla
7
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.
1
2
3
4
5
6
Projekt
α
H0 ks
H0 chi
0,
1
P
P
0,0
5
P
P
0,0
1
P
P
0,
1
P
P
0,0
5
P
P
0,0
1
P
P
0,
1
P
O
0,0
5
P
O
0,0
1
P
P
0,
1
O
O
0,0
5
P
O
0,0
1
P
O
0,
1
O
O
0,0
5
P
O
0,0
1
P
P
0,
1
O
O
0,0
5
P
O
0,01
P
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.
4.2.
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
1
28
2
21
3
19
4
21
5
10
6
20
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 H0 P. W świetle uzyskanych wyników, wydaje się jednak bardzo
mało prawdopodobne, aby hipoteza ta była prawdziwa.
8
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
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 2002.
[2] Beck K., Andres C.: Wydajne programowanie: Extreme programming. Mikom, Warszawa 2005.
[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
2006.
[5] Galinac T., Golubić S.: Project overlaping and its influence on the product quality. Proc of the 8th
International Conference on Telecommunications, pp. 655-662, 2005.
[6] Goel A.L.: Software Reliability Models: Assumptions, Limitations, and Applicability. IEEE
Transactions on Software Engineering vol. SE-11, no. 12, pp. 1411-1423, 1985.
[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. 139-155, 2005.
[8] Kan S. H.: Modeling and software development quality. IBM Systems Journal, vol. 30, no. 3, pp.
351-362, 1991.
[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, 1994.
[10] Kan S. H.: Metryki i modele w inżynierii jakości oprogramowania. Wydawnictow naukowe
PWN, Warszawa 2006.
[11] Li P.L.: A Catalog of Techniques that Predict Information about the Count or Rate of Field
Defects. CMU tech report CMU-ISR1-06-122, School of Computer Science, Pittsburgh, 2006.
[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 12th Asia-Pacific
Software Engineering Conference, 2005.
[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. 1312-1323, 2006.
[14] Luqi, Zhang L.: Documentation Driven Agile Development for Systems of Embedded Systems.
Proc. Of the 4th Workshop on Software Engineering for Embedded Systems, 2003.
[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, 2006.
10