SOFTWARE RELIABILITY

SOFTWARE RELIABILITY 1. Inleiding Het software-bedrijf MathWorks ontwikkelt wiskundige software voor bedrijven en overheidsinstellingen. Op dit moment is de software voor het statistische pakket StatWorks c 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.. 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 t 1, 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 één 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 t 1 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 één 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 t. Op tijdstip t 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 t 1 en t waarop de storingen optreden van het toeval afhangen. Ze zijn realisaties van stochastische grootheden T 1 en T. Kunnen we iets zeggen over de verdeling van T 1 en T? We hebben al geconstateerd dat elk van de twee fouten op een bepaald moment een storing veroorzaakt. Fout nr. 1 veroorzaakt na een tijd T 1 een storing en fout nr. na een tijd T. De eerste van deze twee storingen treedt op op het tijdstip, gegeven door het minimum van T 1 en T, de tweede op het tijdstip, gegeven door het maximum van T 1 en T ; m.a.w. T 1 = min(t 1, T ) en T = max(t 1, T ). Laten we veronderstellen dat T 1 en T 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.1 Druk de marginale verdelingsfuncties en dichtheden van T 1 en T 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.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

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( ) =. 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 T 1 en T anderzijds, gegeven door de volgende equivalentie: (.1) {M(t) i} {T i 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 T i de grootste is van de eerste i storingstijdstippen is die bewering equivalent met T i t. In onderstaande figuur zijn bij wijze van voorbeeld twee willekeurige tijdstippen t 1 en t getekend. In het voorgaande stonden t 1 en t voor de realisaties van de stochastische tijdstippen T 1 en T van de eerste en tweede storing. Nu zullen we met t 1 en t twee vaste willekeurige tijdstippen bedoelen, waar t 1 < t. Twee mogelijke tijdstippen van de storingen worden in de figuur door pijlen aangegeven. De eerste storing valt voor tijdstip t 1, de tweede ergens na tijdstip t. Hieruit volgt dat voor de situatie hieronder beschreven, M(t 1 ) = M(t ) = 1. Figuur.1 De gekozen tijdstippen t 1 en t verdelen de positieve reële rechte (0, ) in drie disjuncte stukken, te weten (0, t 1 ], (t 1, t ] en (t, ). Het aantal storingen dat optreedt in deze drie stukken kunnen we noteren als respectievelijk M(t 1 ), M(t ) M(t 1 ) en M( ) M(t ). 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 [t, ) ook schrijven M(t ). Opdracht. Beredeneer dat de stochastische vector (M(t 1 ), M(t ) M(t 1 ), M(t )) een multinomiale verdeling heeft met parameters (het aantal fouten in de software) en kansvector (F (t 1 ), F (t ) F (t 1 ), 1 F (t )). Welke verdeling hebben de afzonderlijke componenten van de vector (M(t 1 ), M(t ) M(t 1 ), M(t ))? Bepaal aan de hand hiervan P (M(t 1 ) = m 1 ), P (M(t ) = m ) en P (M(t ) = m M(t 1 ) = m 1 ). 3

Bepaal met behulp van (.1) ook P (T 1 t) en P (T t). (Vergelijk met Opdracht.1.) Hoe groot is de kans dat er precies één storing optreedt tussen t 1 en t? 3. Een meer realistisch model Het in paragraaf 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 u 0. Dit aantal u 0 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 M 0 fouten in de code, waarvan men aanneemt dat ze even moeilijk te detecteren zijn als de u 0 reeds aanwezige fouten. Men test nu het programma en vindt zo een totaal van N 1 fouten, waarvan M 1 geïntroduceerde fouten zijn en u 1 oorspronkelijke. Het ligt voor de hand dat de verhouding van gevonden oorspronkelijke en geïntroduceerde fouten gebruikt kan worden om u 0 te schatten. Opdracht 3.1 Construeer met behulp van de zojuist gegeven argumentatie een schatting voor u 0. Deze methode wordt in de praktijk weinig gebruikt, vanwege het feit dat het erg lastig blijkt te zijn om fouten te creëren 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 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, u 0 fouten in de software zitten. We nummeren de fouten van 1 t/m u 0. Elk van de u 0 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 T i. We nemen aan dat elke fout even ernstig is. In ons model komt dit tot uitdrukking in de aanname dat T 1,..., T u 0 alle dezelfde verdeling hebben. Bovendien nemen we aan dat de fouten onafhankelijk van elkaar tot storingen leiden, m.a.w. dat T 1,..., T u 0 onafhankelijk zijn. De gemeenschappelijke verdelingsfunctie van T 1,..., T u 0 noemen we F, de dichtheid f. De gelijkenis met het model van paragraaf 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 u 0. Laten we eens gaan kijken naar de tijdstippen waarop zich storingen voordoen. Het tijdstip van de eerste storing noemen we T 1. De eerste storing kan veroorzaakt worden door elk van de u 0 aanwezige fouten in de software, door die fout die het eerst tot een storing leidt, 4

m.a.w. door die fout i waarvoor T i het kleinste is. Hieruit volgt dat T 1 = min(t 1,..., T u 0 ). Evenzo geldt dat T gelijk is aan de op een na kleinste van T 1,..., T u 0, enz. en dat tenslotte T u0 = max(t 1,..., T u 0 ). Evenals in paragraaf definiëren 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 T 1 van de eerste storing, de tweede op tijdstip T, enzovoorts. Ook hier geldt weer de relatie (.1): {M(t) i} {T i t}. In Figuur 3.1 wordt voor een realisatie van T 1,..., T u0 de functie M(t) geschetst. Hier was T 1 = 0.16, T = 1.6, T 3 = 1.9, enzovoorts. Kijk goed naar het verloop van M(t) en overtuig jezelf ervan dat equivalentie (.1) inderdaad waar is. Figuur 3.1. Een mogelijk verloop van M(t) Neem willekeurige tijdstippen 0 < t 1 < t <... < t m. Deze tijdstippen verdelen de 5

positieve reële rechte (0, ) in m + 1 disjuncte stukken, te weten (0, t 1 ], (t 1, t ], en zo voort tot het laatste stuk (t m, ). Het aantal storingen dat optreedt in (0, t 1 ] hebben we M(t 1 ) genoemd. Het aantal storingen in (t 1, t ] kunnen we schrijven als M(t ) M(t 1 ). Tot slot is het aantal storingen in (t m, ) gelijk aan u 0 M(t m ). Opdracht 3. Bepaal de kansverdeling van de stochastische vector (M(t 1 ), M(t ) M(t 1 ),..., M(t m ) M(t m 1 ), u 0 M(t m )). 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 u 0 fouten in de software, genummerd van 1 t/m u 0. De tijd die verstrijkt voordat fout nr. i tot een storing leidt, duiden we aan met T i en we nemen aan dat T 1,..., T u 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 waar f de dichtheid is van T 1,..., T u 0. λ(t) = u 0 f(t), t > 0, Op een bepaald moment t e 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 t e en daarna. We verplaatsen ons denkbeeldig in de situatie dat de software vrijgegeven is. Als op tijdstip t = t e bekend is dat er m e fouten zijn gedecteerd en gerepareerd, dan kunnen we de voorwaardelijke kans (4.) P ( storing in (t, t + t) M(t e ) = m e ), t > t e bepalen. Volgens ons model wordt elke fout opgespoord en gerepareerd, dus als er op tijdstip t e precies m e storingen zijn opgetreden, dan zijn er op tijdstip t e nog u 0 m e fouten aanwezig in de software. Opdracht 4. Laat zien dat f(t) (4.3) P ( storing in (t, t + t] M(t e ) = m e ) (u 0 m e ) 1 F (t e ) t, t > t e. Gebruik eventueel Opdracht 3.. Dit geeft aanleiding voor het begrip voorwaardelijke storingsintensiteit. De voorwaardelijke storingsintensiteit is dus de storingsintensiteit die behoort bij de voorwaardelijke kans (4.). De uitdrukking daarvoor in (4.3) leidt tot de volgende formule voor de voorwaardelijke storingsintensiteit. (4.4) λ(t M(t e ) = m e ) = (u 0 m e ) f(t) 1 F (t e ). 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 (t 1, t ] bij benadering een Poisson verdeling heeft met parameter t t 1 λ(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 kort) interval (t 1, t ] een Poisson verdeling heeft met parameter t t 1 λ(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 t e getest en vraagt zich af of de software betrouwbaar genoeg is om te worden vrijgegeven. Stel dat er in het begin u 0 fouten in de software zaten en dat er gedurende de testperiode m e storingen zijn opgetreden en dat alle betreffende fouten in de software verbeterd zijn. Dus er zitten nog u 0 m e 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 u 0 = 100, m e = 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 u 0, m e 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 t e + 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 t e voordat de software vrijgegeven kan worden. Als u 0 en β bekend zijn is dit zo uit te rekenen, blijkt uit Opdracht 4.5. Maar meestal zijn u 0 en β niet bekend. In dat geval zullen we u 0 en β moeten schatten en de schattingen invullen in de plaats van u 0 en m e. Het schatten van u 0 en β is het onderwerp van de volgende paragraaf. 5. Meest aannemelijke schatters Ons model was gebaseerd op de aanname dat ieder van de u 0 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 u 0 fouten. Als we dit als uitgangspunt nemen, is 8

ons model dus volledig bekend, afgezien van twee onbekende grootheden, te weten u 0, 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ële verdeling met parameter β. We houden dan een model over met twee onbekende, reëelwaardige, grootheden, te weten u 0 en β. In deze paragraaf gaan we proberen schatters te vinden voor u 0 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 u 0 en β zijn die waarden û 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, t e ]. In die periode hebben we m e storingen waargenomen; de tijdstippen van die storingen zijn geregistreerd en worden gegeven door t 1,..., t me. Van tevoren wisten we niet hoeveel storingen er binnen (0, t e ] zouden vallen. Het aantal storingen m e binnen (0, t e ] moeten we dus ook zien als door het toeval bepaald, als een realisatie dus! Het is het grootste gehele getal zo dat t me t e en t me +1 > t e. De kans op het waarnemen van de feitelijke realisaties (hier komen we op het tweede punt) zou dus worden gegeven door de kans P (T 1 = t 1, T = t,..., T me = t me, T me +1 > t e ). Echter omdat de verdeling F van T i continu is, is bovenstaande kans gelijk aan 0. Daar valt dus niets te maximaliseren. Daarom zullen we gaan kijken naar de volgende kans (5.1) ( P T 1 (t 1 t, t 1 + t ], T (t t, t + t ],..., ) T me (t me t, t me + t ], T me +1 > t e, 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 T 1 < T < < T u0 de geordende detectietijden zijn van de aanwezige fouten. We herinneren ons het verband tussen M(t) en T i : (5.) {M(t) i} {T i t}. Het volgende plaatje geeft schematisch het verband aan tussen M(t) op verschillende tijdstippen en de realisaties t 1,..., t me. Elk tijdstip t i wordt omgeven door haken. De linkerhaak stelt t i t voor, de rechterhaak t i + t. Bij het uitrekenen van de kans in (5.1) valt er tussen elk paar haken, ofwel in elk interval (t i t, t i + t ] een storing. Dat staat aangegeven boven de figuur. Bij elke storing wordt M één 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 T 1 (t 1 t, t 1 + t ],T (t t, t + t ],..., T me (t me t, t me + t ], T me +1 > t e ) m e [ ] (u 0 i + 1)f(t i ) t (1 F (t e )) u 0 m e, i=1 voor t voldoende klein. Gebruik hierbij Figuur 5.1 en het feit dat voor elke 0 < s 1 <... < s m < de vector (M(s 1 ), M(s ) M(s 1 ),..., M(s m ) M(s m 1 ), u 0 M(s m )) de in Opdracht 3. 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 u 0. De aannemelijkheidsfunctie krijgen we door alle t s eruit te delen, met als resultaat m e (5.4) L(β, u 0 ) = [(u 0 i + 1)f β (t i )] (1 F β (t e )) u 0 m e i=1 Opdracht 5. 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 û 0 van β en u 0 gegeven worden door: (5.5) ˆβ = m e me i=1 t i + t e (û 0 m e ), 10

met û 0 de oplossing van (5.6) m e i=1 1 û 0 i + 1 = m e t e me i=1 t i + t e (û 0 m e ). 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 9108 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 676 7843 16185 35338 53443 33 3098 79 169 36799 54433 146 378 8738 16358 3764 55381 7 388 10089 17168 37654 56463 34 4434 1037 17458 37915 56485 351 5034 1058 17758 39715 56560 353 5049 10491 1887 40580 5704 444 5085 1065 18568 4015 6551 556 5089 1098 1878 4045 6651 571 5090 11175 19556 4188 6661 709 5097 11411 0567 496 6373 759 534 1144 101 4306 64103 836 5389 11811 1308 45406 64893 860 5565 1549 3063 46653 71043 968 563 1559 417 47596 74364 1056 6080 1791 5910 4896 75409 176 6380 1311 6770 49171 76057 1846 6477 13486 7753 49416 8154 187 6740 14708 8460 50145 870 1986 719 1551 8493 504 84566 311 7447 1561 9361 5489 8868 366 7644 1577 30085 5875 608 7837 15806 3408 5331 Tabel 6.1. Storingstijdstippen in CPU secondes 11

Opdracht 6.1 Bepaal de meest aannemelijke schattingen van β en u 0 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. 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.5 uur kalendertijd, omdat de.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 (t 1, t ) is gelijk aan t t 1 λ()ds. Zij τ een variabele die de tijd aangeeft gemeten vanaf t e. Het verwachte aantal storingen dat optreedt in het tijdsinterval τ (0, t], gegeven M(t e ) = m e, zullen we aanduiden met µ(τ). Uiteindelijk zullen we voor τ de waarde van t invullen die we uit Opdracht 6. kregen. 1

Opdracht 7.1 µ(τ) kan geschreven worden als τ λ(t)dt. 0 Geef een uitdrukking voor λ(t). Opdracht 7. In Opdracht 6.1 hebben we een schattingen van β en u 0 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.. 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.. 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 verwachte toename kalendertijd vs. CPU-tijd is ν t(τ+h) ν t (τ) h. Evenzo is de verhouding van de verwachte hoeveelheid kalendertijd die het reparatieteam nodig zal hebben gedurende het tijdsinterval (τ, τ + h] gelijk aan ν r(τ+h) ν r (τ) h en de verwachte hoeveelheid kalendertijd voor de computer apparatuur is dan ν c(τ+h) ν c (τ) h. Is deze uitdrukking het grootste 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 ν door lim t (τ+h) ν t (τ) ν h 0 h te vergelijken met lim r (τ+h) ν r (τ) ν h 0 h en lim c (τ+h) ν c (τ) h 0 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., 7.3 en 7.4 (bedenk dat µ (τ) = λ(τ)). Vul in de resulterende uitdrukkingen de schattingen uit Opdracht 6.1 in. Teken de resulterende ν t(τ), ν r(τ) en ν c(τ) 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 ν (τ) = max{ν t(τ), ν r(τ), ν c(τ)}, 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