Fara ASA är en ledande skandinavisk leverantör av IT-system för kollektivtrafik. FARA behövde utveckla en produkt baserat på krav från fem olika kunder. Gislen Software tillhandahöll 20 indiska utvecklare under mer än två år och utvecklade stora delar av ett webbaserat centralsystem, datasynkroniseringslösning via mobilnätet och en plattform för att bygga en bussdator som gjorde det möjligt att använda samma källkod för både en linuxbaserad fast bussdator och en microsoftbaserad mobil enhet som tex. användes av kontrollanter. Projektet var på ungefär 55 tusen timmar, vilket gjorde det till ett av de då största projekten som någonsin lagts ut från Norge till Indien.

Bakgrund

Team at Fara in Trondheim

Q-Free ASA, en världsledare för holistiska intelligenta transportsystem och vägtullsystem fick fem stora AFC-projekt (Automatic Fare Collection) under 2004. Dessa projekt skulle hantera smarta kort och biljetter och till skillnad från tidigare biljettsystem Q-Free utvecklat bestämde man sig för att utveckla en generell anpassningsbar produkt. Som en del i detta skapade Q-Free ett separat företag FARA ASA som blev ett eget bolag på Oslo Börs. Idag är FARA ASA en ledande producent av IT lösningar för kollektivtrafik inom Skandinavien. Projektet inkluderade både hårdvaru och mjukvaruutveckling. Miljökraven för bussdatorer var bland de tuffaste man kan tänka. Bortsett från vibrationer måste bussdatorn som var monterad i bussarna klara temperaturer mellan -45° och +90° Celcius. Även om dessa hårdvarukrav var en utmaning, så var det inte de enda. GPS positionering och ett mobilt alarm system i ett av Europas minst befolkade områden, batterilivslängd när utomhustemperaturen gick en bra bit under fryspunkten såväl som nya olika nationella standarder för smarta kort som dessutom förändrades under projektets gång. Dessutom var detta sannolikt då det största projektet som outsourcats från Norge till Indien.

Krav & Design

Ett team med tre indier och en svensk skickades till Trondheim för att jobba tillsammans med Q-Frees personal. Produkten som skulle utvecklas baserades på krav från fem olika kunder. Onsiteteamet gick igenom kraven och analyserade de olika delar som Fara ville lägga ut till Indien. Teamet i Norge hanterade kommunikationen med Indien. Senare byttes detta team ut och en del kommunikation skedde då direkt. En av våra verksamhetskonsulter dokumenterade bakgrunden, tog en massa foton och skrev ett långt kompendium som beskrev sammanhang och bakgrund för att ge en djupare förståelse av miljön för att indiska programmerare som inte varit i Norge skulle förstå bättre. Nedan följer en lista på olika saker som utvecklades:

En nästan fullskaleprototyp av bussdatorns GUI

Den slutliga bussdatorn skulle utvecklas i ANSI C med hjälp av ett GUI-bibliotek som skulle användas både på de fasta linuxbaserade bussdatorn i bussarna och de portabla Windows CE enheterna som skulle användas för biljettförsäljning t.ex. för flygplatsbussar och för inspektörer. Denna fanns ännu inte, men skulle utvecklas och utvecklingen i ANSI C är en krävande process. Därför utvecklade vi först en nästan fullskalig prototyp av bussdatorn i Delphi för Windows där busschauförer kunde testa sin konfiguration och få en känsla för hur systemet skulle fungera. Tack vare denna prototyp kunde många problem undvikas.

Andra delar vi utvecklade

  • Utskriftsbibilotek i ANSI C
  • Bibliotek för att kunna spara och uppdatera data i smarta kort i Ansi C
  • En webbrowser i Ansi C för att kunna visa html filer med hyperlänkar i bussarna (för hjälp och instruktioner)
  • J2EE/Web moduler för administration av användare, bussdatorer, administratörer, leding och översyn samt kommunikation
  • J2EE/Web moduler för att hantera händelser och alarm genom att skicka SMS / email till rätt person, baserat på olika regler som kunde konfigureras.
  • J2EE/Web moduler för hantering av chaufförsavräkning, betalning och korrigeringar
  • J2EE-baserad kommunikationslösning för att synkronisera tusentals bussdatorer, portabla bussdatorer och försäljningssystem per timma
  • Lösning för att kunna definiera, underhålla produkter, avgifter, rutter, mm.
  • Rapporter

Gislen Software levererade mer än 55 tusen timmars arbete. Enligt NASSCOMs officiella statistik innebar det att vi stod för 5% av Indiens totala IT export till Norge under 2005.

Utvecklingsprocess

Kraven var givna, redan då Q-Free kontaktade Gislen Software. Men Gislen Software var involverad i alla delar av designprocessen. En förenklad Unified Process användes med Use Case analys där så kallade ’Fully Dressed Use Cases’ användes för att exakt beskriva flödet för olika lösingar. En windowsbaserad prototyp utvecklades i Delphi för att visa hur GUI-t såg ut i olika kunderscenarier. Tack vare denna prototyp kunde man minimera risken för senare ändringar och få tidigare feedback från kunderna. Eftersom utveckling i Ansi C tar mycket tid var detta också ett sätt att minska senare risker. Eftersom denna prototyp behövdes snabbt tog vi fram denna prototyp genom att använda indiska utvecklare både i Norge och Sverige och skicka koden fram och tillbaka och vi jobbade 24×7 under några dagar.

Sammanfattning

Gislen Software kunde ge tillräckligt många resurser med kort varsel för att utveckla olika delar av projektet. Tillsammans med Faras egna anställda och norska konsulter kunde vi färdigställa produkten i tid för alla de fem kunderna. En kombination med onsite och offsite utveckling, erfarna verksamhetskonsulter och seniorer i Norge gjorde att vi framgångsrikt lyckades leverera det sannolikt största IT-projektet som då outsourcats från Noge till Indien i tid.

Fara ASA börsintroducerades på Oslo Börs den 1/1-2006 och det första systemet levererades till Rogalands Fylke under Januari 2006.

Vi lärde oss mycket från detta projekt. Stora outsourcingprojekt skall hanteras med en kombination av onsite & offsite arbete och det är viktigt att alla parter är med tidigt i projektet. Kulturella och andra utmaningar skall hanteras med bra dokumentation och det är kritiskt att alla nyckelpersoner i outsourcingteamet förstår sammanhangen rätt. Prototyping, use case analys och dokumentation kan alla användas för att reducera risker.