Regnskab & økonomistyring - Lektion 17 HD 5. semester forår 2010 v/ Jens Godik Højen, April 2010

Systemdesign implementering og drift Lektionen omhandler udarbejdelse af de problemstillinger der er forbundet i forbindelse med Systemdesign implementering og drift. Lektionen ligger op til overvejelser vedrørende et designs betydning for en endelig beslutning om et konceptuelt løsningsforslag. Systemernes processer og deres indbyrdes afhængighed mellem systemets forskellige niveauer, datalageret og frontend sammenholdes med tidligere støtteværktøj (Data Flow, Context diagram og REA diagrammer). Her skal det samlede emne ses som en helhed mellem aktørerne, handlingsmønstre og logiske hændelser.

Konsekvensen af systemskift Vigtigheden af en struktureret udviklingsproces bunde i omfanget af involverede parametre.

Konceptuelt systemdesign Der findes talrige bud på metoder der kan løse evalueringsarbejdet i designfasen. Udvikling af et projekts struktur (framework)

System forberedelse I forberedelsen af systemets specifikationer samles de samlede elementer og processen evalueres. Det kan være en fordel at evalueringsmodeller som vist neden for: Trappemodel Vandfaldsmodel Spiralmodel (Iterative) Socioteknisk fasemodel FAKIR modellen

Trappemodel

Spiralmodellen 1. Analyse - etablere en effektiv kommunikation mellem bygherren og kunde. 2. Idé - definere ressourcer, tid linjer og andre projekt relaterede oplysninger. 3. Plan opgave - vurdere både tekniske og ledelsesmæssige risici. 4. Struktur – præsenterer skitser af en eller flere løsningsforslag. 5. Prototyping - Bygge, afprøve, installere og give brugersupport (her under dokumentation og uddannelse). 6. Test/evaluering - få kundefeedback baseret på evaluering af løsninger skabt i løbet af de tekniske fase og gennemføres under installation fase.

Socioteknisk fasemodel

FAKIR Forundersøgelse Her identificeres og afgrænses problemet. På baggrund af analysen, udarbejdes en problemformulering. Analyse Behovsanalysen gennemføres med det formål at der skal udarbejdes en kravspecifikation. Indholdet af denne vil relaterer krav til hardware, brugervenlighed, ergonomi, økonomi, miljø osv. Konstruktion. kravspecifikationen danner grundlaget når der skal indhentes tilbud fra forskellige leverandører, hvor deres tilbud vurderes individuelt. Der indgås kontrakter med uddybning af opgavens indhold, udstyret leveres. Implementering Det samlede system bestående af hardware og software implementeres i organisationen, og der gennemføres systemtest. Revision Efter en kortere periode gennemgås systemet og dets resultater.

Fysisk systemdesign

Input/Output Input I forbindelse med datainput skal de forskellige typer identificeres og den videre behandling fastlægges ud fra opsamlingsopgavens karakteristika. Output: Planlagte rapporter, kendetegnes ved at det er iterative intervaller de produceres ud fra. Til specielle formål analyserapporter, kendetegnes ved at de produceres efter pludseligt opstået krav til virksomhedens drift. Udløste undtagelse rapporter, rapporter der produceres i sjældne tilfælde og som kræves ud fra pludselige opstået situationer. Efterspørgslen rapporter, udarbejdes ikke kontinuerligt, de har primært til opgave at give svar i forbindelse med ledelsesbeslutningsopgaver.

Design af formularer Det er af afgørende betydning om formularer skal opfører sig som en papirformular eller om det er et rent digitalt design. Yderligere skal datatransporten mellem formularen og datakilden optimeres så transporten foregår hurtigt og sikkert.

Skærm indhold Organiser så der kan anvendes genvejstaster og data kan inddateres hurtigt og nemt. Tilstræb at papirformularer og skærm ligner hinanden mest muligt. Det skal være nemt at indhente tillægsoplysninger Begræns mængden af data på skærmen  

Skærmorden Organisering af felter Dataindtastningsrækkefølge Gruppere relateret data og anvend pladsen fornuftigt Undgå at formularen går ud over skærmen og gør overgangen mellem de enkelte skærmbilleder så smidig som muligt Det skal være muligt at rette fejl – Alle fejl! Minimer størrelsen af samtidige data ved at lave mikro SQL relateret direkte til de enkelte tekstfelter.

Design af rapporter Rapportdesign kan bestå af tekst, tak og grafik. Alt efter opgaven og modtageren anvendes et præsentationslayout.

Design af programmer Program design antages at være den proces der tager længst tid. Der kan spares tid hvis følgende tommelfinger regler overholdes. Se liste side 774 Vær sikker på at du har forstået slutbrugeren Hold dig til planen, hvis ikke muligt så sikre at det er nødvendigt med en ændring Forklar i koden hvad du gør! Test programmet – helst på en kompetent slutbruger Dokumenter hvad du gør Oplys konstant slutbrugeren om hvad du gør Dokumenter installationsproceduren

Procedurer afledt af programdesign Hvem, hvad, hvornår, hvor, hvorfor og hvordan 

Implementering

omstilling Direkte konvertering Parallel konvertering Løbende konvertering Pilot konvertering

Dokumentationsmetoder Udvikler dokumentation, beskrivelse af systemet (input, output, filtyper database layout og kode) Operativ dokumentation, sikkerhed, fil placering udstyr osv. Bruger dokumentation, brugervejledning og undervisningsmateriale.

Procestjek og sikkerhed Walk-throughs. Er en metode der trin for trin tester systemet for fejl. Giver ikke retvisende billede i forbindelse med belastning af applikationen. ”Processing” test af transaktioner, belastning af datakilden og fejlplacering Godkendelsestest. Skal gennemføres før der siges god for systemet.

Refleksionscirklen

Dataflow diagram repetition Dette værktøj anvendes primært i forbindelse med et analysearbejde der skal klarlægge et flow af data inden for en organisation   Der skelnes mellem fire typer: (side 84) Data flowchart, grafisk illustration af kilde til datadestinationen. (s. 86) Dokument flowchart, grafisk illustration af dokumenthåndtering og informations deling mellem virksomhedens aktører (s. 94) System flowchart, grafisk illustration af relationerne mellem input og output fra informationssystemerne. (s. 95) Program flowchart, en grafisk illustration af de logiske operationers sekvenser ved program eksekvering. (s. 99)

Afsluttende bemærkning Context diagram Betegner typisk det ”højeste niveau” i systembeskrivelsen. Symbolikken er typisk genanvendt, men her beskrives et system i mere overordnede termer, REA diagrammer Ressource, handling, agent. Værktøjet blev oprindelig udviklet til det formål at udvikle og designe AIS E/R diagrammer Står for Entitets/relations diagram. Værktøjet anvendes typisk i forbindelse med opbygning af en datakilde. Ved at skitserer databasens enkelte elementer, vil denne skitse danne rammen for en senere dataservermodel.