Underhåll och vidareutveckling

Med underhåll menar man rättning av fel och införande av småändringar i ett befintligt programsystem. Denna verksamheten bedrivs normalt inom ramen för garantiåtaganden eller underhållsavtal. Med vidareutveckling menar man en förändring av ett befintligt programsystem för att täcka mer omfattande tillägg och ändringar av kraven. Vidareutveckling drivs i form av projekt. Inom de flesta programutvecklande organisationer handlar en stor del av verksamheten om ändringar och vidareutveckling av existerande programvaruprodukter. Modeller för hantering av underhåll och vidareutveckling är mindre generellt användbara än modeller för nyutveckling. Speciellt underhåll varierar mycket beroende på typ av produkt, typ av kund och typ av relation kund leverantör.

När man väl infört en utvecklingsmodell, ligger en komplikation i att underhåll och vidareutveckling i början mest avser gammal programvara som inte utvecklats enligt modellen. Låt oss hantera underhåll och vidareutveckling i två fall:

• underhåll och vidareutveckling av programvara som är pålitligt dokumenterad
• underhåll och vidareutveckling av programvara som inte har en pålitlig dokumentation

Förutsättningen är att underhållet regleras av ett underhållsavtal, inom vilket kunden begär felrättning och ändringar efter hand. Vidareutveckling antas upphandlas separat. En annan förutsättning är att det finns ett original bibliotek på förtaget, där produktdokument arkiveras efter utvecklingsprojektets slut, och där man håller ordning på utgåvorna av varje dokument och på produktutgåvor. Någon person blir utsedd till bibliotekarie.

Programvara som är pålitligt dokumenterad

Underhåll

Man behöver först och främst en rutin för att ta emot felrapporter och ändringsbegäran från kunder och andra. När väl felrapporten eller ändringsbegäran kommit in till företaget, kan den hanteras ungefär som sådana ärenden hanteras inom ett utvecklingsprojekt. Dock behöver vi en speciell rutin för detta, eftersom det inte finns någon projektledare. För varje programprodukt finns en underhållsansvarig utsedd. Detta är en person som har befogenhet att ta emot felanmälan och ändringsbegäran från kunden, besluta om pris (inom vissa ramar), införa och prova ändringen. Den underhållsansvarige behöver därmed också vara tekniskt kompetent att själv utföra de flesta ändringarna.

De faktiska ändringarna görs i de existerande dokumenten. Man uppdaterar alltså vid behov kravspecifikationen, konstruktionsdokument, källprogram och testspecifikation. Hur ändringar ska göras beslutas från fall till fall, liksom vilka delar av testspecifikationen som ska genomföras i testningen av den nya utgåvan av programsystemet.

Felanmälan / ändringsbegäran

Underhållsansvarig tar emot felanmälan eller ändringsbegäran från kunden, noterar detta och tar därefter ut en ändringsblankett. Blanketten löpnumreras per underhållen produkt. Underhållsansvarige fyller i blankettens översta del "Felrapport" med vem som anmälde och en beskrivning av felet. Om underhållsansvarige beslutar att ändringen inte ska åtgärdas, noterar han det på blanketten. Beslutet kan bero på att felet ska åtgärdas senare. Kunden kan även ha dragit tillbaka en ändringsanmälan på grund av att kostnaden blir allt för hög. Om felet ska åtgärdas, formulerar underhållsansvarig ett ändringsförslag, där det även ingår ett förslag på hur ändringen ska genomföras.

Införande av ändringen

Underhållsansvarige börjar med att ge bibliotekarien en kopia av ändringsblanketten. Denne kontrollerar att inte någon annan håller på att ändra källprogramet. Om inte, ger han en kopia av källprogrammet i projektsbiblioteket till ändraren. Efter ändringen genomförs en informell provning så att det ändrade programmet fungerar, och noterar detta på blanketten.

När programmet har ändrats, ska det fastställas av linjechefen. Om ändringen var omfattandet, kan linjechefen besluta att dokumenten ska granskas före fastställande. Oavsett om den nya versionen granskats, ska ändringen godkännas på ändringsblanketten. Detta godkännande innebär fastställande av den nya versionen. Underhållsansvarige går därefter till bibliotekarien med den fastställda versionen. Bibliotekarien sparar undan den gamla versionen och lägger in den nya i orginalbiblioteket.

En ny utgåva av produkten skapas och provas på det sätt som beskrivs på blanketten, och som linjechefen godkänt. Eventuella fel noters i en ändringsblankett, som går en ny runda. Testaren dokumenterar provnings resultaten på ändringsblanketten. Därefter levereras programmet till kunden.

Vidareutveckling

Vidareutveckling genomförs som speciella utvecklingsprojekt. Projektledningen sker som vid nyutveckling. Programutvecklingsplan, en speciell kravspecifikation och ett speciellt konstruktionsdokument tas fram för den nyutveckling som ska göras. Testspecifikation och källprogramdokument ändras. Den speciella kravspecifikationen innehåller kompatibilitetskrav, där anges de krav som gäller kompatibilitet med den gamla versionen, t.ex. filformat. Parallellt med att programsystemet provas, ska den ursprungliga kravspecifikationen och det ursprungliga konstruktionsdokumentet uppdateras med de ändringar som beskrivs i den speciella kravspecifikationen och det speciella konstruktionsdokumentet. De uppdaterade dokumenten ska granskas och godkännas på vanligt sätt. Den speciella kravspecifikationen och det speciella konstruktionsdokumentet för vidareutvecklingen arkiveras som projektdokument, men ingår inte i projektdokumentationen. När vi dareutvecklingen är slut har kravspecifikationen och konstrucktionsdokumentet uppdaterats, granskats, godkänts och lagts i orginalbiblioteket.

Programvara som inte har en pålitlig dokumentation

Den här sortens programvara kan antingen vara helt odokumenterad, eller så kan den ha varit dokumenterad någon gång, men dokumentationen har inte upprätthållits, så att idag är det bara källprogrammen som är tillförlitliga. När man underhåller och vidareutvecklar sådan programvara, har vi två huvud mål.

• Modifiering och vidareutvecklingar ska vara dokumenterade.
• Man vill få så stor del av programmet som möjligt tillförlitligt dokumenterad.

Vid den andra punkten så skulle man kunna i efterhand dokumentera upp det existerande programsystemet med kravspecifikation, testspecifikation, konstruktionsdokument och källprogramdokumenten. Men tyvärr är det sällan som man gör detta på grund av att man inte har råd eller tid med en sådan insats som blir ganska omfattande med mycket granskningar.

Underhåll

Vid felrättningar och mindre ändringar får man nöja sig med att dokumentera den nya funktionaliteten i källprogrammet, och att skriva en ofullständig testspecifikation som bara täcker den testning som behöver göras efter ändringen.

Vidareutveckling

Vidareutveckling genomförs som projekt på samma sätt som i föregående text. Vid det första vidareutvecklingsprojektet skriver man en kravspecifikation som täcker den funktionalitet som ska ändras, och konstruktionsdokumentet beskriver hur ändringen ska göras. Testspecifikationen anger hur den nya produkten ska testas. De här dokumenten är produktdokument och kommer efter hand att utökas vid varje ny vidareutveckling. Vid efter följande vidareutvecklingsprojekt skriver man nya tilläggsdokument varefter man bygger vidare på de första dokumenten genom att modifiera dem innan projektet avslutas.