Mangelfuldt dokumenterede it-systemer Hvordan løses udfordringen?
Indholdsfortegnelse 1. Resume... 3 2. Introduktion... 3 3. Fordelene ved at løse udfordringen... 3 4. Løsningen... 4 4.1 Hvordan?... 4 4.2 Moduldesigns:... 4 4.3 Tekniske usecases:... 6 5. Næste skridt?... 6 6. Konklusion... 7 Page 2 of 7
1. Resume I forbindelse med KeyCore s Back on Track - services støder vi ofte på virksomheder, der står med et it- system, der er mangelfuldt dokumenteret. Årsagerne er mange, men resultatet er altid, at systemet er svært og dyrt at teste, idriftsætte og/eller vedligeholde. Dette whitepaper præsenterer en løsning på denne udfordring. 2. Introduktion Der kan være mange årsager til at it- systemers funktionalitet ikke dokumenteres tilstrækkeligt, herunder: Manglende krav til dokumentation i forhold til underleverandør af udvikling. Misforståelser omkring dokumentationskrav eksempelvis i forbindelse med forståelsen af agile udviklingsmetoder Intern udvikling af it- systemer ved knopskydning. Presset projektøkonomi. Fejlslagent dokumentationsforsøg (for eksempel autogenerering). Konsekvenserne af den mangelfulde dokumentation kan vise sig i alle efterfølgende faser af systemets livscyklus: Test: Testen risikerer at blive lige så mangelfuld som dokumentationen. Testholdet bliver tvunget til at gætte sig frem til, hvordan systemet burde virke. Idriftsættelse: Idriftsættelse af mangelfuldt dokumenterede it- systemer vil typisk fejle grundet manglende fokus på interfaces til øvrige systemer og tredjeparter (eks. fejlkonfiguration af firewalls, manglende udveksling af certifikater, etc.). Vedligehold: Her opstår flere alvorlige udfordringer dels forårsager den mangelfulde test, at der findes uforholdsmæssigt mange fejl, dels vil der blive brugt mange kræfter på afklaring om, hvorvidt en given virkemåde skyldes en kodefejl eller et uhensigtsmæssigt design. Ligeledes betyder den manglende dokumentation, at vedligeholdelsen forsinkes af unødvendige og forsinkende afklaringer af, hvordan det allerede idriftsatte system egentligt fungerer. Videreudvikling: Videreudviklingen af systemet kompliceres naturligt af, at information om hvorledes systemet fungerer, ikke er umiddelbart tilgængelig, hvilket bl.a. besværliggør estimering af ændringer. I disse situationer opleves ofte kritiske personafhængigheder, ligesom det vil være reglen mere end undtagelsen, at processen omkring videreudviklingen forsinkes og fordyres p.g.a. den manglende fælles referenceramme. Sunset: Uden en fyldestgørende dokumentation af it- systemets funktionalitet, herunder interfaces, risikerer man at nedlægge systemet før tid. 3. Fordelene Fordelene ved at udarbejde en systematisk dokumentation af it- systemer på en form, der er let tilgængelig for såvel forretning som it, er: At mange diskussioner kan undgås, hvilket frigør tid til at skabe fremdrift At man får et effektivt værktøj til kommunikation og diskussion af ændringsønsker At man får et solidt grundlag for udvikling, test, drift, it- revision, review og videreudvikling mm. At man øger sandsynligheden for genbrug af funktionalitet på tværs af systemerne. Page 3 of 7
At man letter udviklingen af relaterede systemer, der skal interface til det eksisterende system 4. Løsningen KeyCore benytter en udviklingsmetode, der fokuserer på fremdrift, baserer sig på PRINCE2, agile metoder, praktiske erfaringer og almindelig sund fornuft. Metoden anvender en struktureret måde at dokumentere design af it- systemer. Dokumentationsformen er kendetegnet ved at designdokumentationen: Udarbejdes i fællesskab mellem designteamet og forretningen Skrives i et naturligt sprog, men formuleres kort og koncist Kan forstås og godkendes af forretningen Udgør oplægget til kodning for udviklingsteamet Leverer et solidt fundament for udarbejdelse af testcases Overdrages til vedligeholdelsesteamet efter endt udvikling og holdes opdateret dér i hele systemets levetid KeyCore har hjulpet flere kunder med at få deres forretningskritiske, afsporede projekter tilbage på ret kurs, og alle erfaringerne viser, at dokumentationsformen i allerhøjeste grad også er fordelagtig til dokumentation af systemer, selv når udviklingen er afsluttet. 4.1 Hvordan? Lad os som eksempel se på den del af dokumentationen, der beskriver det funktionelle design af it- løsningen, altså beskrivelsen af, hvad it- systemet gør. Kernen i måden, hvorpå KeyCore dokumenterer dette, er 2 dokumenttyper, som vi kalder moduldesigns og tekniske usecases. Forskellen ligger i, hvorvidt den beskrevne funktionalitet indeholder en brugergrænseflade eller ej. Moduldesigns beskriver de moduler der har skærmbilleder og tekniske usecases der beskriver interfaces og algoritmer i systemet. 4.2 Moduldesigns: Moduldesigns beskriver en række skærmbilleder, der tilsammen udgør et sammenhængende funktionalitetsområde, et såkaldt modul. Eksempler på moduler kunne være: Vedligehold kunder : Vil typisk indeholde skærmbilleder til at fremsøge, oprette, rette og slette informationer i et kundekartotek. Dan salgsrapport : Vil typisk indeholde skærmbilleder til definition af udtrækskriterier, definition af outputformat, selve genereringen af rapporten og efterfølgende muligheder for print, udsendelse, arkivering et cetera. Overvåg systemtilstand : Vil typisk indeholde skærmbilleder til at give en oversigt over den overordnede tilstand af det system, der overvåges, drill- down - skærme til uddybning af events og eventuelle skærmbilleder til støtte af udbedring af fejlsituationer. Her er et typisk eksempel på en indholdsfortegnelse fra moduldesignet Vedligehold kunder : Page 4 of 7
Ethvert moduldesign indeholder et overblik over de skærmbilleder, der indgår i modulet og derefter et afsnit for hvert skærmbillede. Alle disse afsnit følger samme skabelon med følgende 4 underafsnit: 1) Layout: Beskriver, hvordan skærmbilledet ser ud, såsom: Bemærk: Der er bevist tale om en stregtegning (og ikke for eksempel et skærm- mockup), blandt andet for at holde fokus på funktionalitet (og ikke på grafisk udtryk) og for at understøtte vedligeholdelses- processen. 2) Felter: Beskriver på en kompakt form alle felter på skærmbilledet, herunder de anvendte datatyper, hvorvidt og hvornår felter vises, om de er obligatorisk og så videre. 3) Handlinger: Beskriver alle de handlinger, en bruger kan foretage på skærmen, samt, hvad systemets reaktion er herpå. For skærmbilledet ovenfor kunne eksempler på relevante handlinger være: Page 5 of 7
4) Valideringsregler: Lister alle de fejlsituationer, der kan opstå på skærmbilledet 4.3 Tekniske usecases: Disse dokumenter beskriver al den funktionalitet i it- systemet, der ikke involverer en brugerinteraktion, såsom webservices, batchkørsler, oprydningsjobs, tunge beregningsalgoritmer, fælles delfunktioner og så videre. En typisk indholdsfortegnelse fra en teknisk usecase ser således ud: Ud over de to nævnte typer dokumenter beskriver dokumentationsformen, at der skal udarbejdes et par støttedokumenter til beskrivelse af tværgående funktionalitet (domænespecifikke datatyper, fælles skærmbilledekomponenter, logisk datamodel, sitemap med videre). Tilsammen udgør dokumentationsformen et effektivt værktøj til at dokumentere et it- system på en form, der: Kan forstås umiddelbart af forretningen, og som derfor er perfekt til at danne grundlag for diskussion af fx ændringsønsker. Er dækkende nok til, at det kan anvendes af testere til at skabe et sæt dækkende testcases. Er præcist nok til at udviklere kan vedligeholde systemet. 5. Næste skridt? KeyCore s udviklings- og dokumentationsform kan bidrage afgørende til hurtigt at etablere en effektiv dokumentationsproces for mangelfuldt dokumenterede it- systemer. Vi foreslår, at dette gøres ved, at KeyCore deltager med coaching i starten af dokumentationsforløbet og bidrager med metoder, skabeloner, best practice- eksempler, review og deltagelse i den indledende produktion af den nødvendige dokumentation. Formålet med deltagelsen er, at dokumentationsholdet bliver selvkørende efter et kort introduktionsforløb. Page 6 of 7
Efterfølgende står KeyCore om nødvendigt til rådighed med rådgivning om dokumentationsformen, det videre forløb, samt et opfølgende review. Der er ingen tvivl om, at udarbejdelse af systematisk dokumentation efter endt udvikling kræver en vis ekstra investering i tid og ressourcer i forhold til, hvis denne dokumentation var udarbejdet som en integreret del af analyse- og udviklingsprocessen, og det er derfor vigtigt på forhånd at vælge en udviklingsmodel, der understøtter dette. Men selv efter endt udvikling giver investeringen i udfærdigelsen af systematisk dokumentation et højt afkast i form af store produktivitetsforbedringer og højere kvalitet i forhold til at arbejde videre med et mangelfuldt dokumenteret it- system. 6. Konklusion Mangelfuld dokumentation udgør en risiko i alle faser af et it- systems livscyklus, idet disse vil blive dyrere og vil tage længere tid end nødvendigt. Når man som virksomhed står i den situation, at man har fået leveret eller har produceret et it- system, der enten er dårligt dokumenteret eller slet ikke dokumenteret, så kan man med fordel benytte den dokumentationsmodel, som KeyCore har anvendt hos flere kunder med meget positivt resultat. Modellen består i indledende coaching af et dokumentationsteam samt bidrag i form af bl.a. skabeloner og best practice- eksempler. Systematisk dokumentation af et it- system har den effekt, at der arbejdes langt mere effektivt i alle faser af it- systemets livscyklus, og at arbejdet derved gøres væsentligt simplere og billigere. Står din virksomhed aktuelt med mangelfuldt dokumenteret it- system, kontakt da KeyCore s salgsansvarlige for at høre mere om mulighederne for hurtigt at få rettet effektivt op på denne situation. Kontakt: John D Arcy Consulting Sales Director and Senior Programme Manager T: +45 40898839 W: www.keycore.dk jd@keycore.dk *** Page 7 of 7