Servicepack 1 till TRS2006

[Fredrik]

I Aurans senaste nyhetsbrev, som kom igår (18/1-06), kan man läsa att service pack 1 till TRS2006 är på gång. SP1 är tänkt att lösa de problem som finns i TRS2006.


Vidare så har P I Engineering uppdaterat Raildriver med nya drivdrutiner så att alla ägare till Raldriver och TRS2006 nu ska kunna bli lyckliga lokförare


Hela nyhetsbrevet (på engelska) hittar du här

[Daniel]

NÄR Kommer SP1?

[Deskgrunt]

Ursprungligen postat av Daniel

NÄR Kommer SP1?

Besökte nyss Aurans forum som jag lyckats hålla mig borta ifrån ett tag...

Alan Yeomas skriver så här i en post 25:e januari:

Its still too early to give a timeframe on SP1, but as with all previous versions of Trainz, we are realistically looking at a few months yet. Some of the important fixes, sound springs to mind, will take time to code and test. Whilst we can't comment in every thread that raises issues, we do read them and take notice, and I feel certain SP1 will deliver on many of these.

Så förbered dig på att vänta några månader till... Man kan ju undra vad Auran gjort sen september...

[Mazz]

Lite anmärkningsvärt att man nu börjar "arbeta" med en SP1. Det borde man börjat med direkt efter release.

Det är ju inte fel att släppa en programvara som innehåller buggar, det hör till det normala. Och, Auran har ju etablerade rutiner för service-pack. Men, har dom någon test-funktion att tala om, så borde stor del av buggarna varit kända redan vid release-tillfället.

Att man släpper kod med kända buggar i hör till det normala, då ett släpp måste vara en kod som är orörd genom hela testfasen, annars har man inte kontroll på vad som släpps. En sen fix i koden ska normalt innebära att man börjar om hela test-sessionen, eftersom en fix i sin tur kan generera andra buggar.

Så, SP1 borde varit påbörjad i september, om Auran har en vettig test-funktion. Tycker jag.

[Daniel]

Helt sjukt!
5 månader!

[Rc1166]

Jag vill inte försvara allt Auran gör man jag har haft kontakter med Auran under några år och lärt mig lite om deras språkbruk. Work (arbete) brukar vara själva kodningen medan allt jobbet innan brukar kallas preliminaries. För att göra en SP är det nödvändigt att kunna rekonstruera ett eventuellt fel och det vet jag av annan erfarenhet inte är det lättaste.
Det är ju alltid ett mål att göra idiotsäkra system men idioter är uppfinningsrika sa en vis man och det har jag sett flera exempel på.
Jag har ändrat lite så det inte ska vara lätt att identifiera dom "skyldiga".

En grupp hade onormalt mycket hårdvarufel med framförallt brända komponenter. Av en slump hade jag ett ärende dit och såg hur dom lagt filtar och täcken över datorerna för att inte störas av fläktljudet.

En användare som bland annat jobbade med fordonssystem hade själv kommit på att byta littera till "specialfordon" för att på det viset komma förbi alla kontroller programmerarna lagt in för vanliga fordon och som han tyckte var jobbiga. När han var färdig bytte han tillbaka till rätt littera.

Ibland hände ju saker utanför systemen som tog ett tag att reda ut. Vid ett par tillfällen så rapporterades samma vagn samtidigt från olika stationer. det visade sig att en serie vagnar hade numrerats om (skyltarna var färdiga och skulle bara skruvas fast när vagnarna var målade). Vagnarna stog snyggt i en rad utanför vekstaden och X började med alla skyltar i skottkärran. Monterade nummer 1 på den första och sedan vidare med nästa vagn tills han var klar med ena sidan på alla vagnar. Sedan fortsatte han med andra sidan och började med 1 !!

Tillbaka till TRS2006 så kan jag inte gå in på detaljer men väl ge några tips.
Om du laddar ner från DownLoadStation, låt CMP jobba färdigt innan du avbryter. Det kan se ut som datorn hängt sig när den sorterar in dina tillägg. Glöm inte att göra commit efter nerladdningar. Spara ofta när du jobbar i surveyor. Om inget annat hjälper, läs manualen.

[Mazz]

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.