SOFTWARE RELIABILITY

SOFTWARE RELIABILITY

1. Inleiding

Het software-bedrijf MathWorks ontwikkelt wiskundige software voor bedrijven en overc heidsinstellingen. Op dit moment is de software voor het statistische pakket StatWorks in de test-fase; de code voor de software is af, maar de software wordt nog getest op fouten. De betrokken bedrijven willen natuurlijk graag weten wanneer zij StatWorks zullen ontvangen. De manager van MathWorks moet een release-datum aan de klanten kunnen doorgeven, en met grote waarschijnlijkheid moet de software op dat moment ook inderdaad release-klaar zijn. Maar hoe weet je nu of de software inderdaad voldoende betrouwbaar is? Dit is een probleem van software reliability. In deze opdracht bent u verantwoordelijk voor de statistische kant van dit probleem en zult u de manager moeten voorzien van een schatting van de release-datum.

2. Een eenvoudig model voor de betrouwbaarheid van software

Als er na het vrijgeven van de software nog fouten in de software zitten, zullen die bij de gebruiker op den duur tot storingen leiden. We spreken van een storing als de software bij een bepaalde input niet de gewenste output levert. Afhankelijk van de aard en het doel van de software zou men ook van een storing kunnen spreken als de uitvoering van een opdracht te veel tijd in beslag neemt. Het is uiteraard de bedoeling dat het programmapakket voor een behoorlijke tijd zonder storingen zal draaien. Om na te gaan hoe betrouwbaar de software is, is een testteam aan de slag gegaan met het testen van de software voor StatWorks. Het testteam genereert willekeurige inputs voor het programma op een manier die zo goed mogelijk de situatie bij de toekomstige gebruiker nabootst, en controleert vervolgens of het programma de gewenste output levert en voldoet aan de normen die het software-bedrijf zich stelt. Het testteam registreert de tijdstippen waarop een storing optreedt. Laten we eens proberen een model op te zetten voor een dergelijke situatie. We nemen daarbij voorlopig voor het gemak even aan dat er twee fouten in de software zitten. Op een bepaald moment, dat we tijdstip t = 0 zullen noemen, wordt er begonnen met testen. Na 1

een bepaalde periode van testen, op tijdstip t1 , zal er voor het eerst een storing optreden. Deze storing wordt veroorzaakt door de fouten in de software. Om de zaak niet te moeilijk te maken, nemen we aan dat de storing veroorzaakt werd door precies ´e´en fout. Een storing in ons model wordt dus niet veroorzaakt door een combinatie van software-fouten. Dit is natuurlijk een beperking, maar anders wordt het rekenkundig wel erg ingewikkeld. De tijd wordt hier gemeten in CPU-seconden (CPU = Central Processing Unit), d.w.z. de hoeveelheid tijd die de computer netto besteedt aan het betreffende programma. Dit ligt voor de hand, omdat alleen als het programma runt, situaties kunnen ontstaan die tot een storing leiden. Nadat het testteam op tijdstip t1 een storing geconstateerd heeft, leggen ze op gedetailleerde wijze in een rapport vast wat er fout is gegaan en geven hun bevindingen door aan het reparatieteam of debugging team, dat zal gaan proberen de fout op te sporen en te repareren. De CPU-tijd wordt hierbij stilgezet; het opsporen en debuggen kost weliswaar ook tijd, maar die heeft niets te maken met de CPU-klok die bij het testteam loopt. Na verloop van tijd heeft het reparatieteam de betreffende fout opgespoord en verbeterd. We nemen hierbij aan dat het repareren foutloos gebeurt en dat er tijdens het repareren ook geen nieuwe fouten ge¨ıntroduceerd worden. Het testteam kan nu weer aan de slag met de nieuwe software, die als gevolg van onze aannames, op het moment dat het testen hervat wordt, nog maar ´e´en fout bevat. De CPU-klok loopt nu weer verder totdat deze fout uiteindelijk ook tot een storing leidt. Laten we het tijdstip waarop dat gebeurt aanduiden met t2 . Op tijdstip t2 wordt de klok weer stop gezet en wordt de fout die tot de tweede storing heeft geleid ook opgespoord en verwijderd. De input van het programma wordt steeds willekeurig gekozen. Als gevolg daarvan zullen de tijdstippen t1 en t2 waarop de storingen optreden van het toeval afhangen. Ze zijn realisaties van stochastische grootheden T1 en T2 . Kunnen we iets zeggen over de verdeling van T1 en T2 ? We hebben al geconstateerd dat elk van de twee fouten op een bepaald moment een storing veroorzaakt. Fout nr. 1 veroorzaakt na een tijd T10 een storing en fout nr. 2 na een tijd T20 . De eerste van deze twee storingen treedt op op het tijdstip, gegeven door het minimum van T10 en T20 , de tweede op het tijdstip, gegeven door het maximum van T10 en T20 ; m.a.w. T1 = min(T10 , T20 ) en T2 = max(T10 , T20 ). Laten we veronderstellen dat T10 en T20 onafhankelijk zijn en beide dezelfde continue verdeling hebben, gegeven door de verdelingsfunctie F en/of dichtheid f . Met deze betrekkelijk eenvoudige aannames kunnen we allerlei interessante vragen beantwoorden. De volgende opdracht dient als vingeroefening. Opdracht 2.1 – Druk de marginale verdelingsfuncties en dichtheden van T1 en T2 uit in F en f . – Hoe groot is de kans dat er op tijdstip t = 10 nog geen storing is opgetreden? – Hoe groot is de kans dat er op tijdstip t = 10 reeds twee storingen zijn opgetreden? – Hoe groot is de kans op precies 1 storing voor of op tijdstip t = 10. Definieer M als het aantal storingen dat is opgetreden voor of op tijdstip t = 10. – Bepaal de kansverdeling van M en ook de verwachting en variantie.

We hebben zojuist in Opdracht 2.1 de verdeling afgeleid van het aantal storingen dat is opgetreden voor of op tijdstip t = 10. We kunnen voor elk tijdstip t het aantal storingen 2

dat is opgetreden voor of op tijdstip t noteren met M (t). Op het moment dat er met testen wordt begonnen, op tijdstip t = 0, zijn er nog 0 storingen opgetreden, dus M (0) = 0 en als we maar lang genoeg doorgaan met testen zullen allebei de fouten tot storingen leiden, dus M (∞) = 2. M (t) is een stijgende functie in t; zij maakt een sprong ter hoogte 1 elke keer als er een storing optreedt. Er is een belangrijke relatie tussen M (t) enerzijds en T1 en T2 anderzijds, gegeven door de volgende equivalentie: (2.1)

{M (t) ≥ i}

⇐⇒

{Ti ≤ t} .

Een korte uitleg is wellicht op zijn plaats. Als M (t) ≥ i, hebben er op tijdstip t minstens i storingen plaatsgevonden. Dat betekent dat de tijdstippen van in ieder geval de eerste i storingen kleiner zijn dan of gelijk aan t. Omdat Ti de grootste is van de eerste i storingstijdstippen is die bewering equivalent met Ti ≤ t. In onderstaande figuur zijn bij wijze van voorbeeld twee willekeurige tijdstippen t1 en t2 getekend. In het voorgaande stonden t1 en t2 voor de realisaties van de stochastische tijdstippen T1 en T2 van de eerste en tweede storing. Nu zullen we met t1 en t2 twee vaste willekeurige tijdstippen bedoelen, waar t1 < t2 . Twee mogelijke tijdstippen van de storingen worden in de figuur door pijlen aangegeven. De eerste storing valt voor tijdstip t1 , de tweede ergens na tijdstip t2 . Hieruit volgt dat voor de situatie hieronder beschreven, M (t1 ) = M (t2 ) = 1.

Figuur 2.1 De gekozen tijdstippen t1 en t2 verdelen de positieve re¨ele rechte (0, ∞) in drie disjuncte stukken, te weten (0, t1 ], (t1 , t2 ] en (t2 , ∞). Het aantal storingen dat optreedt in deze drie stukken kunnen we noteren als respectievelijk M (t1 ), M (t2 ) − M (t1 ) en M (∞) − M (t2 ). Omdat we hebben aangenomen dat het totaal aantal fouten, aanwezig in de software, gelijk is aan twee, kunnen we voor het aantal opgetreden storingen in [t2 , ∞) ook schrijven 2 − M (t2 ). Opdracht 2.2 – Beredeneer dat de stochastische vector (M (t1 ), M (t2 ) − M (t1 ), 2 − M (t2 )) een multinomiale verdeling heeft met parameters 2 (het aantal fouten in de software) en kansvector (F (t1 ), F (t2 ) − F (t1 ), 1 − F (t2 )). – Welke verdeling hebben de afzonderlijke componenten van de vector (M (t1 ), M (t2 ) − M (t1 ), 2 − M (t2 ))? – Bepaal aan de hand hiervan P (M (t1 ) = m1 ), P (M (t2 ) = m2 ) en P (M (t2 ) = m2 | M (t1 ) = m1 ). 3

– Bepaal met behulp van (2.1) ook P (T1 ≤ t) en P (T2 ≤ t). (Vergelijk met Opdracht 2.1.) – Hoe groot is de kans dat er precies ´e´en storing optreedt tussen t1 en t2 ?

3. Een meer realistisch model

Het in paragraaf 2 beschreven model is natuurlijk niet erg realistisch in die zin dat er in een groot software-pakket bij aanvang van de testfase wel meer dan twee fouten in de software kunnen zitten. Als dus na twee storingen het reparatieteam een verbeterde versie levert, hoeft deze bij lange na niet foutloos te zijn. Wat belangrijker is: het aantal fouten in de software is onbekend! We zullen het onbekende aantal fouten in de software aanduiden met u0 . Dit aantal u0 is in feite een parameter die we in ons model kunnen inbouwen en vervolgens kunnen gaan schatten. Een manier om dat te doen wordt fault seeding genoemd. Men introduceert kunstmatig een aantal, zeg M0 fouten in de code, waarvan men aanneemt dat ze even moeilijk te detecteren zijn als de u0 reeds aanwezige fouten. Men test nu het programma en vindt zo een totaal van N1 fouten, waarvan M1 ge¨ıntroduceerde fouten zijn en u1 oorspronkelijke. Het ligt voor de hand dat de verhouding van gevonden oorspronkelijke en ge¨ıntroduceerde fouten gebruikt kan worden om u0 te schatten. Opdracht 3.1 – Construeer met behulp van de zojuist gegeven argumentatie een schatting voor u0 . Deze methode wordt in de praktijk weinig gebruikt, vanwege het feit dat het erg lastig blijkt te zijn om fouten te cre¨eren die precies even moeilijk te detecteren zijn als de oorspronkelijk aanwezige fouten. Kunstmatige fouten worden vaak eerder ontdekt. Welk effect heeft dit op de schattingsmethode? We zullen nu het model van paragraaf 2 aanpassen aan het feit dat er een onbekend aantal fouten in de software zitten. Laten we aannemen dat er op tijdstip t = 0, bij de aanvang van het testen, u0 fouten in de software zitten. We nummeren de fouten van 1 t/m u0 . Elk van de u0 fouten zal op den duur tot een storing leiden. Laten we de CPUtijd die verstrijkt voordat fout nr. i tot een storing leidt aanduiden met Ti0 . We nemen aan dat elke fout even ernstig is. In ons model komt dit tot uitdrukking in de aanname dat T10 , . . . , Tu0 0 alle dezelfde verdeling hebben. Bovendien nemen we aan dat de fouten onafhankelijk van elkaar tot storingen leiden, m.a.w. dat T10 , . . . , Tu0 0 onafhankelijk zijn. De gemeenschappelijke verdelingsfunctie van T10 , . . . , Tu0 0 noemen we F , de dichtheid f . De gelijkenis met het model van paragraaf 2 is groot. Alleen hadden we daar voor het rekengemak aangenomen dat er twee fouten in de software aanwezig waren; hier doen we daar afstand van en noemen we het onbekende aantal fouten in de software u0 . Laten we eens gaan kijken naar de tijdstippen waarop zich storingen voordoen. Het tijdstip van de eerste storing noemen we T1 . De eerste storing kan veroorzaakt worden door elk van de u0 aanwezige fouten in de software, door die fout die het eerst tot een storing leidt, 4

m.a.w. door die fout i waarvoor Ti0 het kleinste is. Hieruit volgt dat T1 = min(T10 , . . . , Tu0 0 ). Evenzo geldt dat T2 gelijk is aan de op een na kleinste van T10 , . . . , Tu0 0 , enz. en dat tenslotte Tu0 = max(T10 , . . . , Tu0 0 ). Evenals in paragraaf 2 defini¨eren we voor elk tijdstip t het aantal storingen M (t) dat opgetreden is op of voor tijdstip t. Op tijdstip t = 0 wordt er begonnen met testen en zijn er nog geen storingen opgetreden, dus M (0) is altijd gelijk aan 0. De rest van het verloop van M (t) als functie van de tijd t hangt van het toeval af. In ieder geval zal M (t) een niet-dalende functie zijn van t. Bij elke storing zal de grafiek van M een sprong naar boven maken; de eerste op het tijdstip T1 van de eerste storing, de tweede op tijdstip T2 , enzovoorts. Ook hier geldt weer de relatie (2.1): {M (t) ≥ i}

⇐⇒

{Ti ≤ t} .

In Figuur 3.1 wordt voor een realisatie van T1 , . . . , Tu0 de functie M (t) geschetst. Hier was T1 = 0.16, T2 = 1.26, T3 = 1.29, enzovoorts. Kijk goed naar het verloop van M (t) en overtuig jezelf ervan dat equivalentie (2.1) inderdaad waar is.

Figuur 3.1. Een mogelijk verloop van M (t) Neem willekeurige tijdstippen 0 < t1 < t2 < . . . < tm . Deze tijdstippen verdelen de 5

positieve re¨ele rechte (0, ∞) in m + 1 disjuncte stukken, te weten (0, t1 ], (t1 , t2 ], en zo voort tot het laatste stuk (tm , ∞). Het aantal storingen dat optreedt in (0, t1 ] hebben we M (t1 ) genoemd. Het aantal storingen in (t1 , t2 ] kunnen we schrijven als M (t2 ) − M (t1 ). Tot slot is het aantal storingen in (tm , ∞) gelijk aan u0 − M (tm ). Opdracht 3.2 – Bepaal de kansverdeling van de stochastische vector (M (t1 ), M (t2 )−M (t1 ), . . . , M (tm )− M (tm−1 ), u0 − M (tm )).

4. Criteria voor de betrouwbaarheid

Een belangrijk begrip is het begrip storingsintensiteit. Het geeft de intensiteit weer waarmee storingen kunnen optreden. Een hoge storingsintensiteit wil zeggen dat er in de nabije toekomst waarschijnlijk veel storingen zullen optreden; een lage storingsintensiteit wil zeggen dat er weinig storingen zullen optreden. Het is niet moeilijk in te zien dat de storingsintensiteit afhangt van het aantal fouten in de software, immers, hoe meer fouten, hoe eerder een storing zal optreden. Tijdens de testfase worden voortdurend fouten gedetecteerd en verwijderd, dus daarmee zal de storingsintensiteit veranderen. Op wiskundige wijze wordt de storingsintensiteit dan ook beschreven als een functie λ van de tijd t, die aangeeft hoe groot de kans is dat er rond tijdstip t een storing optreedt. (4.1)

P ( storing in (t, t + ∆t] ) ≈ λ(t)∆t ,

waar ∆t heel klein is. Laten we de testfase nog eens doorlopen en ondertussen bekijken wat er met de storingsintensiteit gebeurt. Op tijdstip t = 0 zitten er u0 fouten in de software, genummerd van 1 t/m u0 . De tijd die verstrijkt voordat fout nr. i tot een storing leidt, duiden we aan met Ti0 en we nemen aan dat T10 , . . . , Tu0 0 onderling onafhankelijk zijn en alle dezelfde continue verdeling hebben met verdelingsfunctie F en dichtheid f . Elk van de fouten zal op den duur de oorzaak zijn van een storing. Opdracht 4.1 – Laat m.b.v. (4.1) zien dat de storingsintensiteit gegeven wordt door λ(t) = u0 f (t) ,

t>0,

waar f de dichtheid is van T10 , . . . , Tu0 0 . Op een bepaald moment te wordt er gestopt met testen. De bedoeling daarvan is om op dat moment een idee te krijgen van de betrouwbaarheid van de software. De vraag 6

is: is de storingsintensiteit op dat moment al laag genoeg om voldoende betrouwbaarheid te garanderen? Als de software op dat moment inderdaad al aan de gestelde betrouwbaarheidseisen voldoet, zal er definitief gestopt worden met testen. Is dat niet het geval, dan wordt het testen later gedurende een bepaalde tijd hervat, totdat duidelijk is dat de software wel aan alle eisen voldoet. Later zullen we in meer detail ingaan op de relatie storingsintensiteit-betrouwbaarheid. Eerst zullen we ons concentreren op wat we kunnen zeggen over de storingsintensiteit op tijdstip te en daarna. We verplaatsen ons denkbeeldig in de situatie dat de software vrijgegeven is. Als op tijdstip t = te bekend is dat er me fouten zijn gedecteerd en gerepareerd, dan kunnen we de voorwaardelijke kans P ( storing in (t, t + ∆t) | M (te ) = me ) ,

(4.2)

t > te

bepalen. Volgens ons model wordt elke fout opgespoord en gerepareerd, dus als er op tijdstip te precies me storingen zijn opgetreden, dan zijn er op tijdstip te nog u0 − me fouten aanwezig in de software. Opdracht 4.2 – Laat zien dat (4.3)

P ( storing in (t, t + ∆t] | M (te ) = me ) ≈ (u0 − me )

f (t) ∆t , 1 − F (te )

t > te .

Gebruik eventueel Opdracht 3.2. Dit geeft aanleiding voor het begrip voorwaardelijke storingsintensiteit. De voorwaardelijke storingsintensiteit is dus de storingsintensiteit die behoort bij de voorwaardelijke kans (4.2). De uitdrukking daarvoor in (4.3) leidt tot de volgende formule voor de voorwaardelijke storingsintensiteit. (4.4)

λ(t | M (te ) = me ) = (u0 − me ) ·

f (t) . 1 − F (te )

Als criterium voor het betrouwbaar zijn van de software is de (voorwaardelijke) storingsintensiteit een zeer bruikbaar instrument. Een lage storingsintensiteit wil zeggen dat de kans op het optreden van een storing in de directe toekomst klein is, dus dat de software betrouwbaar is; een hoge storingsintensiteit impliceert dat de software onbetrouwbaar is. Opdracht 4.3 – Maak aannemelijk dat het aantal storingen dat optreedt in een kort interval (t1 , t2 ] bij Rt benadering een Poisson verdeling heeft met parameter t12 λ(s)ds. – Geef een uitdrukking voor het verwachte aantal storingen µ(t) in (0, t]. In het vervolg nemen we aan dat het aantal storingen dat optreedt in een (niet noodzakelijk Rt kort) interval (t1 , t2 ] een Poisson verdeling heeft met parameter t12 λ(s)ds. Vanaf het 7

moment dat de software wordt vrijgegeven is het aantal fouten in de software (althans, in deze release) constant. Het management stelt dat de software zo betrouwbaar moet zijn dat de kans op foutloos draaien van de software voor de eerstvolgende 4 uur CPU-tijd minstens 95% is. Opdracht 4.4 Men heeft tot en met tijdstip te getest en vraagt zich af of de software betrouwbaar genoeg is om te worden vrijgegeven. Stel dat er in het begin u0 fouten in de software zaten en dat er gedurende de testperiode me storingen zijn opgetreden en dat alle betreffende fouten in de software verbeterd zijn. Dus er zitten nog u0 − me fouten in de software. Stel bovendien dat F (t) = 1 − exp(−βt). – Geef een uitdrukking voor de voorwaardelijke storingsintensiteit gegeven door (4.4). Neem hierbij u0 = 100, me = 90 en β = 10−6 (in CPU-seconden). – Voldoet de software aan de door het management gestelde betrouwbaarheidseisen?

Stel dat het aantal fouten in de software nog te groot was om aan de gestelde eis te voldoen dat de kans op foutloos draaien van de software voor de eerstvolgende 4 uur CPU-tijd minstens 95% is. Als we langer waren doorgegaan met testen, hadden we meer storingen geconstateerd, waren er meer fouten verwijderd en had de software later misschien wel aan de gestelde eis voldaan. Opdracht 4.5 Neem u0 , me en β als in Opdracht 4.4. Stel dat we nog een tijdje lang verder zouden gaan met testen, zeg t˜ CPU-seconden. – Bepaal de kans dat er geen storingen optreden in een periode van 4 CPU-uur, gerekend vanaf tijdstip te + t˜. – Bepaal t˜ zodanig dat deze kans 95% is. Als we t˜ zo nemen als in het laatste gedeelte van Opdracht 4.5, zou de software met een extra periode van t˜ seconden testen naar verwachting wel aan de gestelde eisen voldoen. Zo is t˜ het verwachte aantal CPU-seconden vanaf tijdstip te voordat de software vrijgegeven kan worden. Als u0 en β bekend zijn is dit zo uit te rekenen, blijkt uit Opdracht 4.5. Maar meestal zijn u0 en β niet bekend. In dat geval zullen we u0 en β moeten schatten en de schattingen invullen in de plaats van u0 en me . Het schatten van u0 en β is het onderwerp van de volgende paragraaf.

5. Meest aannemelijke schatters

Ons model was gebaseerd op de aanname dat ieder van de u0 aanwezige fouten in de software, onafhankelijk van alle andere, na een stochastische tijd, geregeerd door de verdelingsfunctie F , tot een storing leidt. Hierbij hebben we ook aangenomen dat deze verdelingsfunctie F dezelfde is voor ieder van de u0 fouten. Als we dit als uitgangspunt nemen, is 8

ons model dus volledig bekend, afgezien van twee onbekende grootheden, te weten u0 , het aantal fouten in de software, en F de onbekende onderliggende verdelingsfunctie. Vanaf dit moment nemen we, zoals in Opdracht 4.3, aan dat F de verdelingsfunctie is van een exponenti¨ele verdeling met parameter β. We houden dan een model over met twee onbekende, re¨eelwaardige, grootheden, te weten u0 en β. In deze paragraaf gaan we proberen schatters te vinden voor u0 en β. De methode die we hiervoor zullen gebruiken, is de methode van de meest aannemelijke schatters. Het onderliggende idee hierachter is welbekend. De meest aannemelijke schatters van u0 en β zijn die waarden u ˆ0 en βˆ die de kans op het waarnemen van de feitelijke realisaties zo groot mogelijk maken. Twee dingen verdienen hier wat extra aandacht. Ten eerste: wat zijn die feitelijke realisaties. Bedenk dat we over een vaste periode getest hebben, (0, te ]. In die periode hebben we me storingen waargenomen; de tijdstippen van die storingen zijn geregistreerd en worden gegeven door t1 , . . . , tme . Van tevoren wisten we niet hoeveel storingen er binnen (0, te ] zouden vallen. Het aantal storingen me binnen (0, te ] moeten we dus ook zien als door het toeval bepaald, als een realisatie dus! Het is het grootste gehele getal zo dat tme ≤ te en tme +1 > te . De kans op het waarnemen van de feitelijke realisaties (hier komen we op het tweede punt) zou dus worden gegeven door de kans P (T1 = t1 , T2 = t2 , . . . , Tme = tme , Tme +1 > te ) . Echter omdat de verdeling F van Ti0 continu is, is bovenstaande kans gelijk aan 0. Daar valt dus niets te maximaliseren. Daarom zullen we gaan kijken naar de volgende kans  P T1 ∈ (t1 −

∆t 2

, t1 +

∆t 2

], T2 ∈ (t2 −

∆t 2

, t2 +

∆t 2

], . . . ,

(5.1) Tme ∈ (tme −

∆t 2

, tme +

∆t 2



], Tme +1 > te ,

waarbij we ∆t weer heel klein zullen nemen. Vergelijk dit met de situatie bij continu verdeelde stochastische grootheden, waar de dichtheid gemaximaliseerd wordt. Laat weer voor t ≥ 0, M (t) het aantal gedetecteerde storingen zijn voor of op tijdstip t. Laat T1 < T2 < · · · < Tu0 de geordende detectietijden zijn van de aanwezige fouten. We herinneren ons het verband tussen M (t) en Ti : (5.2)

{M (t) ≥ i}

⇐⇒

{Ti ≤ t} .

Het volgende plaatje geeft schematisch het verband aan tussen M (t) op verschillende tijdstippen en de realisaties t1 , . . . , tme . Elk tijdstip ti wordt omgeven door haken. De linkerhaak stelt ti − ∆t voor, de rechterhaak ti + ∆t 2 2 . Bij het uitrekenen van de kans in ∆t (5.1) valt er tussen elk paar haken, ofwel in elk interval (ti − ∆t 2 , ti + 2 ] een storing. Dat staat aangegeven boven de figuur. Bij elke storing wordt M ´e´en groter. De waarde van M staat aangegeven onder de figuur. Zij wordt gevormd door de cumulatieve som van wat boven de figuur staat. 9

Figuur 5.1 Figuur 5.1 kan van nut zijn om de kans in (5.1), de aannemelijkheidsfunctie, te bepalen. Opdracht 5.1 – Laat zien dat  P T1 ∈ (t1 −

∆t 2

, t1 +

∆t 2

],T2 ∈ (t2 −

∆t 2

, t2 +

Tme ∈ (tme − ≈

me h Y

∆t 2

∆t 2

], . . . ,

, tme +

∆t 2

], Tme +1 > te



i u −m (u0 − i + 1)f (ti )∆t · (1 − F (te )) 0 e ,

i=1

voor ∆t voldoende klein. Gebruik hierbij Figuur 5.1 en het feit dat voor elke 0 < s1 < . . . < sm < ∞ de vector (M (s1 ), M (s2 ) − M (s1 ), . . . , M (sm ) − M (sm−1 ), u0 − M (sm )) de in Opdracht 3.2 bepaalde verdeling heeft.

We zullen nu ons model volledig parametrisch maken door inderdaad te veronderstellen dat de detectietijd per fout exponentieel verdeeld is met parameter β, ofwel (5.3)

F (t) = Fβ (t) = 1 − exp(−βt) ,

t>0.

In het resulterende model zitten nu dus twee parameters die we willen schatten, te weten β en u0 . De aannemelijkheidsfunctie krijgen we door alle ∆t’s eruit te delen, met als resultaat (5.4)

L(β, u0 ) =

me Y

u0 −me

[(u0 − i + 1)fβ (ti )] · (1 − Fβ (te ))

i=1

Opdracht 5.2 Beschouw de natuurlijke logaritme van (5.4) en vul de definitie van Fβ uit (5.3) in. – Laat zien dat de meest aannemelijke schatters βˆ en u ˆ0 van β en u0 gegeven worden door: (5.5)

me , u0 − me ) i=1 ti + te (ˆ

βˆ = Pme

10

met u ˆ0 de oplossing van me X

(5.6)

i=1

m e te 1 . = Pme u ˆ0 − i + 1 u0 − me ) i=1 ti + te (ˆ

In de praktijk moet de oplossing van (5.6) benaderd worden. Meestal wordt hiervoor een iteratieve methode gebruikt.

6. De testresultaten voor StatWorks

Het testteam heeft gedurende een tijd van 91208 CPU-seconden het pakket StatWorks getest en de tijdstippen geregistreerd waarop een storing optrad. Voor elke storing is de betreffende fout opgespoord en verwijderd. De storingstijdstippen zijn gegeven in de volgende tabel en zijn te vinden in de unix file /home/sda/Cursusdata/statworks. 3 33 146 227 342 351 353 444 556 571 709 759 836 860 968 1056 1726 1846 1872 1986 2311 2366 2608

2676 3098 3278 3288 4434 5034 5049 5085 5089 5090 5097 5324 5389 5565 5623 6080 6380 6477 6740 7192 7447 7644 7837

7843 7922 8738 10089 10237 10258 10491 10625 10982 11175 11411 11442 11811 12549 12559 12791 13121 13486 14708 15251 15261 15277 15806

16185 16229 16358 17168 17458 17758 18287 18568 18728 19556 20567 21012 21308 23063 24127 25910 26770 27753 28460 28493 29361 30085 32408

35338 36799 37642 37654 37915 39715 40580 42015 42045 42188 42296 42306 45406 46653 47596 48296 49171 49416 50145 52042 52489 52875 53321

53443 54433 55381 56463 56485 56560 57042 62551 62651 62661 63732 64103 64893 71043 74364 75409 76057 81542 82702 84566 88682

Tabel 6.1. Storingstijdstippen in CPU secondes 11

Opdracht 6.1 – Bepaal de meest aannemelijke schattingen van β en u0 voor de storingstijdstippen van Tabel 6.1.

Het management heeft bepaald dat de software voor StatWorks kan worden vrijgegeven als de storingsintensiteit van StatWorks onder een bepaalde drempel zit. Die drempel is bepaald naar het criterium van Opdracht 4.4, namelijk dat de kans dat de software 4 CPU-uur foutloos draait minstens 95% is. Opdracht 6.2 Geef de meest aannemelijke schatting voor de resterende tijd (in CPU-uren) voordat aan de vastgestelde drempel kan worden voldaan. Gebruik hiervoor de oplossingsmethode van Opdracht 4.5.

7. Van CPU-tijd naar kalendertijd

In de vorige opdracht heeft u een schatting gemaakt van de resterende tijd voordat het programma vrijgegeven kan worden, gemeten in CPU-uren. Hier heeft de manager natuurlijk helemaal niets aan. Hij wil een schatting hebben voor zijn klanten van de resterende tijd, gemeten in real-time tijdseenheden (in kalenderdagen bijv.). De vraag is nu: stel dat de software over τ CPU-uur vrijgegeven zou kunnen worden, hoeveel uren moet dan in werkelijkheid gewacht worden op de release? Laten we de relatie tussen CPU-tijd en werkelijke tijd (kalendertijd) eens nader bekijken. We beginnen hierbij met het testteam. Een uur CPU-tijd voor het runnen van tests zou bijvoorbeeld in werkelijkheid twee en een half uur kunnen kosten. Dit is het aantal mensuren dat het testteam besteedt aan bijvoorbeeld het invoeren van gegevens of aan het initialiseren van random input generators. Als het testteam dan uit twee personen bestaat, kost een uur CPU-tijd dus 1.25 uur kalendertijd, omdat de 2.5 uur over twee mensen kan worden verdeeld. Maar ook het optreden van een storing kost tijd. Immers, het testteam moet dan controleren of het daadwerkelijk een storing betreft en een verslag schrijven voor het reparatieteam met bijzonderheden over de aard van de storing en dergelijke. Laten we aannemen dat dit anderhalf uur in beslag neemt per fout, dus drie kwartier per fout persoon. De verwachte kalendertijd die besteed wordt aan rapportage van storingen bij een CPU-uur testen is dan drie kwartier maal het verwachte aantal storingen dat optreedt tijdens dat CPU-uur testen. Van paragraaf 4 weten we dat dat aantal uitgedrukt kan worden via de storingsintensiteit. Het verwachte aantal storingen dat optreedt in het tijdsinterval R t2 (t1 , t2 ) is gelijk aan t1 λ()ds. Zij τ een variabele die de tijd aangeeft gemeten vanaf te . Het verwachte aantal storingen dat optreedt in het tijdsinterval τ ∈ (0, t], gegeven M (te ) = me , zullen we aanduiden met µ ˜(τ ). Uiteindelijk zullen we voor τ de waarde van t˜ invullen die we uit Opdracht 6.2 kregen. 12

Opdracht 7.1 µ ˜(τ ) kan geschreven worden als ˜ – Geef een uitdrukking voor λ(t).

Rτ 0

˜ λ(t)dt.

Opdracht 7.2 In Opdracht 6.1 hebben we een schattingen van β en u0 gevonden, met als tijdseenheid CPU-seconden. Deze schattingen zullen we in deze opdracht gebruiken, maar dan omgezet in CPU-uren. Stel dat het testteam bestaat uit twee man die full-time inzetbaar zijn. De verwachte kalendertijd (ook in uren) die verstreken is na τ CPU-uren noemen we νt (τ ) (het subscript t staat voor testteam). – Schets de grafiek van νt (τ ). Laten we ons nu concentreren op het reparatieteam. Het reparatieteam treedt alleen in actie als er een storing geconstateerd is. De CPU-tijd die bij het testteam loopt kost voor het reparatieteam geen kalendertijd, tenminste niet op een rechtstreekse manier. De personeelstijd begint pas te lopen wanneer er een storing optreedt. Deze hangt dus van de CPU-tijd alleen af via het verwachte aantal opgetreden storingen. Een storing zal echter aan het reparatieteam gemiddeld meer tijd kosten dan aan het testteam. Het testteam hoeft bij het optreden van een storing “alleen maar” een rapportje te schrijven; het reparatieteam moet in de code van de software duiken en de fout opsporen. We nemen aan dat dit gemiddeld 6 mensuren per fout in beslag neemt. Opdracht 7.3 Neem dezelfde schattingen als in Opdracht 7.2. Stel dat het reparatieteam ook uit twee full-time inzetbare personen bestaat. We noteren de verwachte kalendertijd die verstrijkt na τ CPU-uren als νr (τ ). – Schets de grafiek van νr (τ ). Tenslotte gaan we naar de computerapparatuur. Een uur CPU-tijd kost de computer zelf natuurlijk ook tijd, laten we aannemen 6 uur. Elke storing kost de computer ook tijd, omdat bij een storing de software mogelijk nog een aantal keer gerund wordt door het testteam met dezelfde invoer om een beter idee te krijgen van wat er mis gaat. Een opgetreden storing kost gemiddeld een half uur CPU-tijd. Opdracht 7.4 Neem dezelfde schattingen als in Opdracht 7.2. Stel dat er vier computers full-time beschikbaar zijn. We noteren de verwachte kalendertijd die verstrijkt na τ CPUuren als νc (τ ). – Schets de grafiek van νc (τ ). Gedurende het testen wordt er op het testteam, het reparatieteam en de computer apparatuur simultaan een beroep gedaan. Dit is weliswaar in de praktijk niet helemaal exact waar, maar wel bij benadering. Hoeveel kalendertijd er in totaal verstrijkt tijdens een interval (0, τ ] in CPU-uur hangt af van in welke mate het testteam, het computerteam en de computer apparatuur belast zijn. Het volgende scenario komt vaak voor in de praktijk. Als het testen net is begonnen, detecteert men een groot aantal fouten in een kort tijdsbestek. Er moet vaak met testen 13

worden gestopt, opdat het reparatieteam het allemaal kan bijhouden. Naarmate het testen voortduurt, worden de tijdsduren tussen intervallen steeds langer. Nu heeft het reparatieteam minder te doen, maar wordt het testteam de beperkende factor. Zij hebben al hun tijd nodig voor het runnen van de tests en het analyseren van de resultaten. Tenslotte wordt de beschikbare computertijd de beperkende factor. Welke bron is nu op een gegeven tijdstip de beperkende factor? Is dat het testteam, het reparatieteam of de computer apparatuur? Dat is die bron die de grootste toename heeft in verstreken kalendertijd, vergeleken met de toename in CPU-tijd. Neem een tijdstip τ in gedachten in CPU-tijd. De verwachte hoeveelheid kalendertijd die het testteam nodig zal hebben gedurende het tijdsinterval (τ, τ + h] is gelijk aan νt (τ + h) − νt (τ ). De verhouding t (τ ) . Evenzo is de verhouding van verwachte toename kalendertijd vs. CPU-tijd is νt (τ +h)−ν h de verwachte hoeveelheid kalendertijd die het reparatieteam nodig zal hebben gedurende r (τ ) en de verwachte hoeveelheid kalenderhet tijdsinterval (τ, τ + h] gelijk aan νr (τ +h)−ν h νc (τ +h)−νc (τ ) tijd voor de computer apparatuur is dan . Is deze uitdrukking het grootste h voor het testteam, dan heeft het testteam gedurende (τ, τ + h] in verhouding de grootste verwachte kalendertijd verbruikt en is het testteam dus de beperkende factor. Als we nu het tijdsinterval kleiner en kleiner maken, ofwel h naar 0 laten gaan, dan kunnen we dus t (τ ) r (τ ) c (τ ) door limh→0 νt (τ +h)−ν te vergelijken met limh→0 νr (τ +h)−ν en limh→0 νc (τ +h)−ν , h h h bepalen wie op tijdstip τ de beperkende factor vormt. Maar dan zijn we feitelijk de afgeleiden aan het vergelijken van νt (τ ), νr (τ ) en νc (τ )! Opdracht 7.5 – Differentieer de uitdrukkingen voor νt (τ ), νr (τ ) en νc (τ ) uit Opdrachten 7.2, 7.3 en 7.4 ˜ )). (bedenk dat µ ˜0 (τ ) = λ(τ – Vul in de resulterende uitdrukkingen de schattingen uit Opdracht 6.1 in. – Teken de resulterende νt0 (τ ), νr0 (τ ) en νc0 (τ ) in een figuur en geef daarin ook aan welke de grootste is. – Bespreek in welke mate de situatie bij Mathworks voldoet aan het hierboven beschreven scenario.

Als we ν(τ ) zodanig definieren dat ν 0 (τ ) = max{νt0 (τ ), νr0 (τ ), νc0 (τ )} , dan is de uiteindelijke aantal verstreken kalenderuren na τ CPU-uren gelijk aan ν(τ ). Opdracht 7.6 Stel dat het 1 juli van dit jaar is, net voor het begin van de werkdag en stel dat het personeel volledig inzetbaar is (40 uur per week) tot de release van StatWorks. – Geef op basis van de gegevens van de paragrafen 6 en 7 een schatting van de release-datum van StatWorks.

14