Vi ska väl inte fördjupa oss varken hur Auran jobbar eller kallar sina olika pass, men vill ändå passa på och inflika min syn dock på det hela.
Ofta kan man indela ett programutvecklingsprojekt i följande faser, om vi koncentrerar oss på ett versions-släpp av något slag, spelar ingen roll om det är full-release eller SP, det är samma.
Den första fasen är någon slags problemidentifiering eller förbättringsidentifiering. Oavsett vilket, klassas de ingående punkterna i "viktighetsgrad". De viktigaste är de som man först och främst jopbber med, även om massa andra parametrar spelar in oxå, såsom tillgängliga resurser, omfattning av åtgärden och andra beroenden. Så, ut från den fasen kommer ett antal "att-göra". Input till denna fas är tidigare testfaser, buggrapporter eller nya krav som en ny release ska ha. Det är här jag menar att Auran borde vetat det redan i september.
Nästa fas är eventuell justering av systemeringen och kodning utifrån de olika "att-göra"-sakerna. Arbetsinsatsen varierar naturligtvis på vad som ska göras, men inte ovanligt kan vara att kodnings-insatsen i sig inte är omfattande, likaväl som att den kan vara omfattande. Men, ju mer omfattande, desto större risker naturligtvis.
Fasen efter är en omfattande fas, för en stor programvara, som interagerar med många utomstående parametrar. Testprogrammet, som du säger Kenny är inte lätt. Men, det är oxå här ett företag måste förstå vikten av testspecifikationer för att kunna täcka in så många "filten över datorn"-fall som möjligt, men även de egenproducerade delmodulernas funktionalitet gentemot varandra är mycket omfattande och bara det är mer än nog i arbetsinsats.
Nyckeln för att kunna göra sedan en stabil release är att ha en kod som är stabil och INTE FÖRÄNDRAD genom testfasen. Buggar hittas naturligtvis även under denna period, men bara om det är en kritisk bugg, så backar man och kör hela programmet igen. Annars releasar man, med kända buggar. Och, det är här jag menar att det måste vara utom all tvivel at Auran har känt till åtminstånde ett antal buggar redan vid release-tillfället. Och, skulle mao kunnat köra första och andra fasen. Det är först när man går in i 3:e fasen som man har en build som är avsedd för release, som nya fix eller features stängs och det kan naturligtvis vara en finness att inte stänga för tidigt, ifall buggar från fältet upptäcks.
Alla ovanstående punkter ingår då i min värld i arbetet för ett nytt släpp och det är därför jag blir lite förvånad när man säger att nu har vi kommit på att vi behöver göra ett SP1...
Men, sen finns det naturligtvis massa dialekter på ovanstående från företag til företag, men på ett eller annat sätt bör ett företag som producerar ett stort program ha säkrat sin kvalitet i något som liknar ovanstående. Jämfört med tidigare releaser, så känns inte TRS2006 riktigt träffat lika bra kvalitetsmässigt, sett från en utomstående betraktare. Vilket iallafall jag är lite besviken på, känns som om TRS2006 släpptes lite för tidigt.
Sen kanske man så att säga jobbar på ett sätt internt och komunicerar utåt på ett annorlunda sätt, så man ska självklart ta mina funderingar med en nypa salt, naturligtvis. Jag är inte insatt i hur Auran jobbar.
