Virksomhedens informationsbehandling APEX 4 2009 Ved. Jens Godik Højen

Business Process Reenginering (BPR) Organisere omkring resultater, ikke opgaver Dem der efterspørger en løsning også gennemfører til resultatet. Dem der producerer oplysninger også sender oplysningen videre. samle og sprede data – for at undgå dualitet i samme svar. Integrere parallelle aktiviteter. Styrk arbejdstagere, bruge indbyggede kontrolfunktioner, og skær ned på unødvendige led i organisationsdiagrammet. Indfange data én gang, ved kilden. Centralt Data Warehouse.

Udfordringer i forbindelse med BPR Traditioner Modstand Begrænsning i nødvendigt økonomisk grundlag Ledelsesmæssigt svigt – dårlig opbakning Skepsis Omskoling Kontrol

prototyping Fordele: Ulemper: Krav til systemet kommer fra kilden Højre grad af brugerinvolvering og tilfredshed Hurtigere udvikling (måske) Større lyst til ændringer Mindre udgiftstung Ulemper: Betydelig brug af medarbejdernes tid Mindre effektiv udnyttelse af systemressourcer ufuldstændigt system udvikling utilstrækkeligt afprøvet og dokumenteret systemer negative adfærdsmæssige reaktioner Udvikling der aldrig får en ende!

Nære udviklingsmetoder End-user computing (EUC) End-user development (EUD)

End-user computing (EUC) Udtrækning af data til simple rapporter og hurtige svar. Hvad nu hvis analyser og statistiske analyser. Udvikle små applikationer vha. regneark og små databaser Lave skemaer, åbne debitor poster, lån gældsydelser osv.

End-user development (EUD) Fordele: Bruger oprettelse, kontrol, og gennemførelsen System, som opfylder brugernes behov Aktualitet Frigøre systemer ressourcer Ulemper: Logik og udvikling fejl Utilstrækkeligt testet ansøgninger Ineffektive systemer dårligt kontrolleret og dokumenteret systemer system uforligeligheder gentagelse af systemer og data og ressourcespild Øgede omkostninger

Motivation v. anvendelse af EUC Opret hurtighjælp Sikrer support Undervisning i udvikling af EUC Evaluer udvikling løbende Assister hurtigt i forbindelse med EUC Oprette standarder for udvikling Opret kontrolgruppe for: adgang, uautoriseret brug, mod duplikerede værdier osv.

Program Konceptuelt systemdesign Konsekvenser af It-projekter Design Procedurer Implementering Omstilling

Konsekvensen af systemskift Systemskiftets indgriben i virksomhedens paradigme

Konceptuelt systemdesign Udvikling af et projekts struktur (framework)

System forberedelse Trappemodel Vandfaldsmodel Spiralmodel (Iterative) Socioteknisk fasemodel FAKIR modellen

Trappemodel

Spiralmodellen Analyse Idé Plan Struktur Prototyping Test/evaluering

Socioteknisk fasemodel

FAKIR modellen

Fysisk systemdesign Det konceptuelle design skal implementeres og sikres i den fremadrettede drift.

Input/output I forbindelse med datainput skal de forskellige typer identificeres og den videre behandling fastlægges ud fra opsamlingsopgavens karakteristika. Planlagte rapporter Til specielle formål analyserapporter Udløste undtagelse rapporter Efterspørgslen rapporter

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, tal og grafik. Alt efter opgaven og modtageren anvendes et præsentationslayout.

Design af programmer 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 anvendelse Parallel anvendelse Løbende anvendelse Pilot anvendelse

Dokumentation 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.

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.

Analyse metoder Bevægeligt gennemsnit Eksponentiel udglatning Ekstrapolation Lineær Trend kurven Vækst kurven Regression/Pivot