Udvikling af regnskabsinformationssystem: Enterprise, Database og Interface Modules

Udvikling af regnskabsinformationssystem: Enterprise, Database og Interface Modules!

Der findes en række regnskabsmæssige softwarepakker, der tilbyder en bred vifte af features.They koster meget mindre end hvad tilpasset regnskabssoftware ville koste. Disse softwarepakker tilbyder dog kun strukturen til regnskabsinformationssystemer. I det mindste reducerer de programmeringsindsatsen for regnskabsinformationssystemer.

Image Courtesy: bestsmallbizhelp.com/wp-content/uploads/2011/07/1018910261.jpg

Udviklingen af ​​regnskabsinformationssystemer er meget mere end softwaren til ledgerpostering og rapportering af dannelse. Det indebærer også etablering af procedurer til registrering af data og distribution samt analyse af regnskabsoplysninger.

Udviklingen af ​​et regnskabsinformationssystem er forklaret med speciel henvisning til kravene i mellemstore og store virksomheder. Disse trin vil imidlertid være fælles for de fleste andre informationssystemer i en virksomhed.

1. Enterprise Module:

Virksomhedsmodulet til informationssystemudvikling involverer identifikation af grundlæggende enheder og deres indbyrdes forhold, identifikation af grundlæggende aktiviteter og omgruppering af disse aktiviteter i subsystemer. Derefter fastlægges prioriteterne på grundlag af costbenefitanalyse for virksomheden.

Identificerende enheder:

Der findes et stort antal enheder i en virksomhed, og listen er så varieret som forretningsaktiviteterne er. På dette stadium er det primære problem at identificere de brede enheder, hver af dem indeholdende en gruppe af elementære enheder. Kerner ⁵ peger på seks grundlæggende enheder i en virksomhed.

De er kunder, produkter, leverandører, personale, faciliteter og penge. I et regnskabsinformationssystem er der tre grundlæggende enheder, nemlig transaktioner, konto og behandlingsperiode. Sammenhængen mellem disse enheder kan udtrykkes ved hjælp af ER-diagrammerne som vist i fig. 8.2.

Transaktionerne skal være af forskellig art, såsom kvitteringer, betalinger, salg, køb, erhvervelse af aktiver eller tilbagebetaling af passiver mv. Og hver af dem kan kaldes en enhed på lavere niveau. Tilsvarende kan konti være af forskellig art, såsom aktiver, passiver, indtægter og omkostninger.

Hvert af disse hoveder kan have enheder på lavere niveau, såsom anlægsaktiver og omsætningsaktiver. Disse enheder kan opdeles yderligere i enheder på lavere niveau som jord og byggeri, anlæg og maskiner mv. På nuværende tidspunkt skal de brede enheder imidlertid identificeres. Detaljerne udarbejdes på tidspunktet for udformningen af ​​databaserne.

Enhederne identificeres i lyset af og med henblik på at definere omfanget og fokuseringen af ​​informationssystemet. Hvis informationssystemet f.eks. Betragtes som et strategisk informationssystem, skal de brede enheder identificeres i lyset af de strategiske stødpunkter, som virksomheden planlægger at give sine aktiviteter ved hjælp af informationssystemet.

Disse fremskridt kan være omkostningsminimering, kundeservice, produktdifferentiering og strategiske alliancer. De grundlæggende enheder i et sådant tilfælde ville være kunder, kanaler, konkurrerende virksomheder, produkter mv.

Aktivitetsanalyse:

Et andet vigtigt aspekt af virksomhedsmodulet er identifikation af aktiviteter i forbindelse med enhederne. Disse aktiviteter er bredt identificeret i form af relationer i ER diagrammerne. Imidlertid opnås detaljer ved hjælp af aktivitetsanalyse. Den eksisterende organisationsstruktur er en vigtig kilde til information om virksomhedens brede aktiviteter.

Men for at udvikle informationssystemer, der er uafhængige af den nuværende organisationsstruktur, er det vigtigt at basere aktivitetsanalysen på de grundlæggende enheder, der allerede er identificeret ovenfor. Det næste niveau af aktivitetsanalyse indebærer identifikation af livscyklusaktiviteterne. I tilfælde af at »transaktioner« er en af ​​de grundlæggende enheder i et regnskabsinformationssystem, er der fire brede livscyklusaktiviteter, nemlig:

1. Køb livscyklus

2. Produktion livscyklus

3. Indtægter livscyklus

4. Investeringer livscyklus

På samme måde har behandlingsperioden to grundlæggende livscyklusaktiviteter, nemlig:

en. Planlægning og kontrol livscyklus

b. Intern og ekstern rapporteringslivscyklus

Disse livscyklusaktiviteter er løbende aktiviteter og udføres løbende. Hver af disse aktiviteter kan være sekventielt relateret til nogle andre aktiviteter. Det tredje niveau af aktivitetsanalyse indebærer opdeling af livscyklusaktiviteterne i funktioner.

For eksempel skal hver type transaktion initieres og anerkendes; Derefter skal dataene vedrørende transaktionen fanges, kodes for fremtidig klassificering, klassificeres, opsummeres og rapporteres. Disse funktioner skal udføres forskelligt for forskellige typer transaktioner. Processen med at definere funktionerne fokuserer kun på de aktiviteter, der opretter, opdaterer eller bruger oplysninger i virksomhedens database.

På dette niveau af aktivitetsanalyse er aktiviteterne selvstændige, har klart definerede start- og afslutningsbegivenheder eller noder og en identificerbar person eller en gruppe personer, der er ansvarlige for at udføre funktionen.

Disse funktioner kan derefter opdeles i underfunktioner, indtil funktionerne er specifikke til at definere modulet til computerprogrammer. Opdelingen af ​​livscyklusaktiviteter i funktioner og underfunktioner hjælper med at identificere funktioner, som gentages i mere end én livscyklusaktivitet.

F.eks. Kan funktionen af ​​klassificering af indfangede data udføres i købs - og markedsføringscykluser. En sådan aktivitetsanalyse hjælper med at identificere muligheder for at forbedre det eksisterende design ved at:

1. eliminering af de overflødige funktioner

2. kombinere de duplikerede funktioner

3. Forenkling og forbedring af behandlingsmetoderne

Redundansen kan identificeres ved en omhyggelig analyse af aktiviteterne. De aktiviteter, der sandsynligvis vil give mulighed for at forbedre behandlingen, omfatter aktiviteter:

en. Det udføres også andre steder

b. Det kan kombineres med andre aktiviteter

c. Det kan også håndteres af en anden person

d. Det kan udføres på et andet trin i livscyklusen, der ikke tilføjer værdi til produkt eller tjenesteydelse i informationssystemet.

Et ord af forsigtighed her er, at ikke alle afskedigelser er dårlige. Faktisk kan nogle redundans eller overlapning med vilje få lov til at krybe ind i systemet. Dette kan gøres for at forbedre systemets ydeevne og pålidelighed.

For eksempel kan en del af duplikationen være nødvendig for at sikre enkelhed af procedurer og forbedring af forarbejdningshastigheden. Eliminering af redundans kan resultere i 'sætte alle æg i en kurv' og kan således påvirke pålideligheden. Risikoen for uventede implikationer og lave afkast fra foreslået ny metode eller procedure er andre faktorer, som fortjener opmærksomhed, inden der foreslås ændringer i informationssystemet.

Gruppering af aktiviteter i subsystemer:

Når aktiviteterne er defineret ved hjælp af ovenstående nedadgående tilgang, er de omgrupperet til at danne delsystemer. En vigtig beslutning, der skal træffes på dette stadium, vedrører gruppering. Der må ikke eksistere et enkelt objektivt kriterium for at bestemme hvilket delsystem en aktivitet tilhører.

Den nuværende organisationsstruktur kan danne grundlag for gruppering af aktiviteter. Men den nuværende organisationsstruktur kan undergå ændringer, og informationssystemet kan være tabt.

For at gruppere aktiviteterne i subsystem tager vi hjælp fra organisationsteori. En af de væsentlige træk ved enhver god organisationsstruktur er, at den har til formål at lette koordineringen af ​​aktiviteterne.

Et effektivt kommunikationssystem er afgørende for en bedre koordinering. Det er derfor vigtigt at gruppere aktiviteter på en sådan måde, at kommunikationen lettes inden for gruppen, og behovet for kommunikation mellem grupper minimeres.

Med henblik på at repræsentere og dokumentere gruppering af aktiviteter i subsystemer anvendes strukturdiagrammer eller hierarkiske blokdiagrammer. Figur 8.3 giver et strukturdiagram, der viser indkomstkredsløbets komponenter.

Lignende strukturoversigter kan udarbejdes til andre klynger af aktiviteter, og endelig er disse delsystemer integreret med hinanden, hvilket giver byggestenene et regnskabsinformationssystem.

De subsystemer, der er identificeret ved gruppering af aktiviteter, er seriøse konkurrenter for at være enheder i organisationsstrukturen. Fordelen med klyngemetoden for gruppering af aktiviteter er, at grupperingen er baseret på funktioner og ressourcer og ikke på geografiske områder.

En sådan klyngning på grundlag af funktioner sikrer homogenitet blandt medlemmerne af gruppen af ​​mennesker, der er associeret med hver af subsystemerne. Virkningen af ​​informationssystemorganisation på organisationsstruktur er ikke ualmindeligt.

Ofte har introduktion af informationssystemer ledsaget af ændringer i organisationsstrukturerne på grund af det faktum, at nye informationssystemer ændrer den måde, hvorpå folk arbejder i en organisation.

Det er derfor desto vigtigere, at informationssystemdesignere arbejder i aktiv tilknytning til organisationsudviklingsfolkene, mens gruppering af aktiviteter i klynger og subsystem sker. Dette sikrer ikke kun, at den nye struktur er mere pragmatisk, men også mere acceptabel for mennesker. I sådanne tilfælde er overgangen fra gammelt system til nyt en mindre smertefuldt og billigere.

Indstilling af prioriteter:

Når delsystemerne er blevet identificeret og integreret som helhed, skal prioriteterne bestemmes blandt de forskellige delsystemer og funktioner i hvert system. Informationssystemet ville kræve engagement af økonomiske ressourcer.

Derudover kan der være implicitte omkostninger til det nye system med hensyn til nødvendige ændringer i driftsprocessen. Det er derfor vigtigt at afveje fordele og ulemper ved hvert delsystem og delsystem, inden de udformes og implementeres.

Hvert delsystem evalueres på grundlag af veldefinerede evalueringskriterier defineret med hensyn til de kritiske succesfaktorer (CSF). Disse faktorer er allerede blevet identificeret i afsnit 8.2.

Den anden metode er brainstorming, hvor de relevante personer i organisationen mødes for at identificere de faktorer, der fortjener overvejelser ved fastsættelsen af ​​prioriteter. Frie flow af ideer tilskyndes i første fase.

Det underliggende princip her er, at ingen ide er dum eller irrelevant på dette stadium. I anden fase begynder processen med eliminering og efter drøftelserne færdiggøres forslagene.

Når listen over faktorer er færdiggjort, tildeles relative vægte, og et kriteriums funktion er defineret til vurdering af hver komponent i det foreslåede regnskabsinformationssystem.

2. Databasemodul:

Regnskabsinformationssystem behandler store mængder data. Administrering af data er således et af de væsentligste overvejelser i processen med dets udvikling. Der er to grundlæggende tilgange til datadesign, nemlig:

en. Den traditionelle applikationsorienterede tilgang, og

b. Databaseprocessen.

Traditionel tilgang:

Den traditionelle tilgang til datastruktur er applikationsorienteret i den forstand, at der for hver applikation genereres et separat sæt datafiler efter dets krav. Med andre ord er datafilene dedikeret til en given ansøgning og er på en måde "ejet" af ansøgningen.

For eksempel skal en kundefordringsapplikation have kundemasterdatafilen, en salgstransaktionsfil og en kvittering fra kundernes transaktionsfil. Disse datafiler bruges kun til debitoransøgningen.

Denne tilgang er egnet til mindre regnskabsinformationssystemer på grund af dets enkelhed. Men som informationssystemet vokser med hensyn til datamængde og analysens kompleksitet, giver det også anledning til visse problemer.

Det grundlæggende problem med den traditionelle tilgang er, at applikationsprogrammerne er afhængige af de datafiler, de bruger og manipulerer. Som følge heraf kræver enhver ændring i datafilen (i form af tilføjelse eller sletning af datapost) ændringer i alle programmer ved hjælp af datafilen.

Denne dataafhængighed modvirker ændringer i datafiler, der fører til ufleksibilitet. I mangel af et værktøj til udførelse af rutinemessige datahåndteringsaktiviteter på dataene, skal sådanne faciliteter indgå i programmerne ved hjælp af datafilen. Dette komplicerer programmet. Et andet problem vedrører opfyldelsen af ​​ad hoc-spørgsmålet.

For uventet form for forespørgsel skal specialprogrammer skrives. Sådanne særlige programmer tager tid at udvikle sig og har kun én gang brug og er derfor dyre. Der er meget dobbeltarbejde i optagelse af dataposter.

F.eks. Kan dataelementer som kundenavn, fakturanummer, pris osv. Indgå i transaktionsfiler til ansøgning om salgsordrebehandling samt ansøgning om kundefordringer. Dette medfører redundans i data.

Data redundans resulterer i ineffektiv brug af lagermedier. Det påvirker også kvaliteten af ​​data, da opdatering af et givet dataelement måske ikke finder sted i alle de filer, hvor dataelementet er gemt.

Database tilgang:

Den moderne tilgang til data design er database tilgang. Denne tilgang er baseret på antagelserne om, at flere applikationer kræver datasæt, der har meget til fælles. Det er derfor bedre at have et fælles opbevaringssted, der opfylder datakravene for hver applikation i informationssystemet.

Det fælles depot kaldes databasen og styres af et styringssystem kaldet Database Management System (DBMS). DBMS er software specielt designet til at styre data i databaser i overensstemmelse med anmodninger fra applikationsprogrammer samt fra dem, der kommer direkte fra brugerne. Det konceptuelle design af databasemiljøet er vist ved hjælp af figur 8.5.

Databaseprocessen tager sig af problemerne med applikationsmetoden. Det sikrer data uafhængighed, da DBMS tager sig af strømmen af ​​data fra databasen til applikationsprogrammer. Brugerprogrammet behøver ikke at genere sig om placeringen af ​​dataene i databasen. En datalogi opretholdes, og data kan kaldes ved hjælp af de ord, der er angivet i datalogik.

Databaseprocessen reducerer også applikationsprogrammets størrelse og kompleksitet, da den rutinemæssige type databehandlingsoperationer som sortering udføres af DBMS. DBMS'en bruges også til at betjene behovet for ad hoc-forespørgsel. DBMS bruger Structured Query Language (SQL) som sprog for kommunikation mellem brugeren og databasen.

Sproget er meget simpelt og ret tæt på engelsk. Dette sikrer, at brugeren kan få oplysninger fra databasen efter behov. Den uddannelse, som ledere kræver for at lave ad hoc-forespørgsler, er minimal, og få timers træning kan give de grundlæggende færdigheder til at bruge sproget. Måske er den vigtigste fordel ved databaseprocessen reduktionen i redundans i databaser.

Der er mange modeller, der almindeligvis anvendes i design af databaser. Den moderne tilgang er imidlertid at følge ER-modellen af ​​databasedesign. Denne tilgang er top-down-tilgang, og ER-diagrammerne, der er trukket tidligere i Enterprise Module, bliver udgangspunktet.

For hver enhed og forhold identificeres attributter og dokumenteres i Extended ER-diagrammerne (EER-diagrammer). I et regnskabsinformationssystem kan EER trækkes for hver enhed (transaktion og konti), og forholdet (effekt) for transaktionskonti er vist i ER-diagrammet. For eksempel kan attributter for en salgstransaktion specificeres og dokumenteres som vist i figur 8.6.

Disse attributter bliver dataelementerne (felterne) i en post i datafilen for hver enhed (i dette tilfælde salgstransaktionsfil). Tilsvarende tegnes sådanne Extended E (EER) diagrammer for andre enheder og relationer.

Når disse attributter er identificeret, er det sandsynligt, at nogle af attributterne skal være fælles i forskellige EER-diagrammer. For at undgå overlapning af sådanne fælles attributter foretages normalisering af data.

3. Interface Module:

Et grænseflademodul definerer kilderne til dataposter og formaterne af input / output og dialogskærme, som skal bruges i systemet. Det definerer også rapportformater og skærme til navigation fra en del af informationssystemerne til den anden.

Med andre ord handler modulet om at definere grænsefladen mellem brugeren og maskinen. Interfacemodulets betydning er steget på grund af øget kommunikation mellem bruger- og informationssystemer.

Både dataindtastningen og datasøgningen er blevet interaktive. I mange tilfælde elimineres inputformularer fra processen, og dataindtastningen foregår direkte. De ændrede krav til datasøgning gør mange rapportblanketter for stive. Interaktive rapportskærme giver større fleksibilitet i datasøgning og tillader brugerdefinerede rapportformater til visning og udskrivning.

Input skærme:

Indgangsskærmen er defineret i lyset af den naturlige proces af forretningsaktiviteten. Derfor afhænger de primært af de former, der bruges til manuelt at registrere dataene, når de først modtages af virksomheden. Disse formularer kan i et regnskabsinformationssystem indeholde faktura, købsordre, salgsordre, udgiftsbevis osv.

I grænseflademodulet gennemgår formularerne også; Redesignede og input skærme er defineret i lyset af formularer, der anvendes af virksomheden. I et regnskabsinformationssystem skal man være mere forsigtig med hensyn til skærmdesign.

En mindre forbedring af inputskærmen, der sparer dataindtastning, kan resultere i betydelige besparelser, fordi antallet af gange dataregistreringsskærmen bruges er meget stor. Følgende faktorer kan tages i betragtning ved udformning af inputskærm:

(a) Matchende med formularer:

Indgangsskærmformatet skal stemme overens med inputformularer. Nogle gange betaler det sig at anvende det samme format, som bruges af inputformularen. I det omfang det er muligt, kan farven på baggrunden af ​​skærmen matches med farven på inputformularen.

(b) Interaktiv:

Indgangsskærmen skal være interaktiv. Det bør påpege fejl i dataregistreringen lige ved indgangen og tillade korrektioner. Hvert dataelement skal have en vis data valideringstilstand, og enhver overtrædelse af en sådan data validering betingelse skal automatisk fremhæves på tidspunktet for dataindtastning.

For eksempel skal en dataindtastningsskærm for indtastning af faktura påpege fejl ved indtastning af dato, hvis datoen er ugyldig. Datoen kan være ugyldig, fordi den er uden for regnskabsperioden, eller den indtastede måned er større end tolv.

(c) Konsistens:

Indgangsskærmbillederne skal være konsekvente i definere vilkår og placering for bestemte almindelige typer dataelementer. Det hjælper med at reducere træningstiden, da det forbedrer kendskabet; For eksempel kan datoen for transaktionen altid placeres i højre hjørne af hvert transaktionsdokument.

(d) Enkelhed:

En af de grundlæggende egenskaber ved en god input skærm er enkelheden. For mange fremhævede sektioner, blinkende værdier eller attributter, eller ved at sætte for mange kasser og understregning, tilføjer kun kompleksitet og forvirring. Nogle gange er bip bruges til at påpege dataindtastningsfejl. Der bør være en dømmekraftig brug af sådanne bip og generelt bør disse undgås.

(e) Fleksibilitet:

Indgangsskærmen skal kunne modificeres. Det skal give brugerne mulighed for at foretage ændringer i form af tilføjelse eller sletning og flytning af dataelement. Fremgangsmåden til ændring bør være enkel. Disse dage tilbyder skærmgeneratorer fra forskellige softwareproducenter funktionerne som træk og fix / slip ethvert dataobjekt fra skærmen ved at bruge almindelig pegeenhed som mus.

(f) Skræddersyet:

Skærmene skal være skræddersyet til hver kategori af bruger. Dette ville reducere uretmæssigt lange start- og indgangsprocedurer.

Rapport skærme:

Rapporterne kan udarbejdes til yderligere analyse af et andet computerprogram eller af brugeren selv. Dataene, der er rettet til behandling af computerprogrammer, såsom regneark, statistiske pakker, tekstbehandlingsprogrammer, opbevares i datafiler.

Det er bedre at sætte dem i standard dataformat, så de let kan nås. Rapporterne, der er beregnet til brugere, holdes normalt i form af tekst, tabeller og grafer. Der bør gøres en indsats for at sikre, at rapporterne udarbejdes og meddeles rettidigt, præcist, klart og til en lav pris.

Dialogskærme:

Dialogskærmen er dem, der bruges til at identificere og udføre opgaverne i informationssystemet. De definerer hvad der kan gøres ved hjælp af informationssystemet, hvordan man navigerer fra en opgave / procedure til en anden og hvordan man udfører forskellige opgaver, som informationssystemet tillader.

Disse skærmbilleder skal være enkle og entydige. Enkelheden kan introduceres ved at levere Graphic User Interface (GUI) og have begrænset antal menupunkter på en skærm. Fremgangsmåden til navigation fra en menu til den anden skal være enkel, i højre rækkefølge og let at følge. Det bør også påpege fejl i udøvelsen af ​​muligheder og være hurtig til at korrigere proceduren.

CASE-værktøjer til skærmdesign:

En række CASE-værktøjer er tilgængelige til udformning af formularer, skærme og rapporter. Disse værktøjer har den fordel at tilbyde design af miljø, der er fleksibelt og nemt at forstå selv for en ny bruger.

Da disse værktøjer har skærm prototyping faciliteter, er det muligt at have større inddragelse af brugerne i processen med skærm design. Selvfølgelig tillader sådanne værktøjer hurtige ændringer og forbedrer produktiviteten hos programmører ved at generere koder til endelig implementering. Dette resulterer i reduceret udviklingstid.

Når formularerne, input / output skærme og dialogskærme er klar, skal de testes og ændres i overensstemmelse hermed. Formularerne og skærme designet med CASE-værktøjerne kan let ændres. Derfor skal der gøres en indsats for at forbedre systemets acceptabilitet ved korrekt prøvning og modifikation af formularer og skærme.

4. Ansøgningsmodul:

Dette modul udvider delsystemerne, der allerede er identificeret i virksomhedsmodulet. For hvert delsystem, der er identificeret i strukturplanen, defineres detaljerede behandlingsprocedurer i dette modul.

Med andre ord er applikationsmodulet primært involveret i de processer, der er involveret i omdannelse af inputdata til værdier, som skal udgøre en del af rapporterne som defineret i grænseflademodulet. Det kan bemærkes, at kun disse processer skal defineres som

(a) Skift værdierne i databaserne, eller

(b) Det er ikke dele af databasen, men kræves i de rapporter, der er defineret i grænseflademodulet.

De værdier, der allerede findes i databasen, kan fås ved hjælp af DBMS forespørgselssprog i henhold til kravet til brugere uden udvikling af programmer til dette formål. Således er applikationsmodulets opgave reduceret med det arbejde, der allerede er udført i databasedesign og skærmdesign.

Data flow diagram:

Ledelsens rolle i dette modul er grundlæggende at identificere den grundlæggende procesprocedure. De detaljerede algoritmer er generelt defineret og dokumenteret af informationssystemets fagfolk, selvfølgelig med aktiv hjælp fra lederen.

Værktøjet, der bruges til at udtrykke de processer, der skal udføres for at konvertere inputdataene til output, er data flowdiagrammet (DFD). Det beskriver strømmen af ​​data. Det definerer hvad der skal gøres og ignorerer hvordan det skal gøres eller hvordan det blev gjort tidligere. Denne fremgangsmåde tillader ændringer i systemet, og svaghederne i det eksisterende system kan fjernes efter denne fremgangsmåde.

DFD symboler:

Der er fire grundlæggende symboler, der bruges i DFD'er. De er:

(i) Afsender:

Terminator er en ekstern kilde til datastrøm eller ekstern synkronisering af data. Det er en ekstern enhed eller objekt som kunde, sælger, aktionærer mv. Da terminatorerne er eksterne enheder, er kommunikationen mellem terminatorerne udelukket fra systemet. Terminatoren er symboliseret af et rektangel (generelt skygget) og etiketten er placeret i rektanglet.

(ii) Datastrøm:

Datastrømmen bærer en række dataelementer vedrørende den begivenhed, som terminatoren starter. Det er symboliseret med en pil i DFD, og ​​retningen af ​​strømmen er angivet ved pilens retning. Pilene er generelt mærket, medmindre de er rettet til eller fra datafiler. Som tidligere nævnt er datastrømme mellem to terminatorer ikke inkluderet i DFD, og ​​data kan således ikke strømme direkte mellem to terminatorer.

iii) proces:

Processen omdanner de indgående data til omdirigering til datalager eller terminator. Det er symboliseret af et rektangel med afrundede hjørner eller en cirkel. Det er selvfølgelig mærket med et verb.

(iv) Databutik:

Filer er datalagerene i informationssystemer og er repræsenteret i DFD'er i form af åbne rektangler. Generelt svarer de til tabeller i databaser. Et partielt billede af dataflydsdiagrammet for salgsordrebehandling er vist i figur 8.7.

Det kan bemærkes, at nogle supplerende symboler og mindre variationer i symboler, der repræsenterer forskellige komponenter af DFD, også anvendes. De ovennævnte symboler er de mest almindeligt anvendte og er ifølge den grafiske konvention foreslået af Gane og Sarson.

Mange gange finder en leder, at DFD er meget træk og frustrerende oplevelse. Hver gang man trækker en DFD, finder man at have ignoreret et eller andet aspekt af datastrømmen. Heldigvis har CASE-værktøjerne faciliteter til at oprette og ændre DFD'er. Begyndende anbefales imidlertid at følge nedenstående trin for at løse dette problem:

(a) Identificer alle input-datastrømme og outputdatastrømme separat sammen med terminatorer, idet inputdata strømmer på venstre side og output data flow til højre.

(b) Mærk terminatorerne ved hjælp af datastrøm navneord eller adjektivnavne.

(c) Identificer processer fremad fra input datastrømme og bagud fra output datastrømme indtil de mødes i midten.

(d) Mærk processerne ved hjælp af verbnavn.

En leder skal være parat til at genudlægge DFD, fordi datastrømmene ofte bliver klare til lederen, efter at DFD er tegnet. Brugerinddragelse på dette stadium er meget nyttigt ikke kun for at reducere indsatsen fra ledelsens side, men også for at forbedre DFD.

Test af DFD:

Det foreslås, at DFD skal testes grundigt, inden den er færdiggjort. Følgende er nogle af de almindelige fejl i DFD-design:

en. Termineringsetiketten kan være navnet på en person eller en virksomhed i stedet for en klasse. For eksempel kan en terminator mærkes som M / s. BR Ltd. i stedet for enesælger. En anden fejl kan være, at transportøren er sat som terminator i stedet for den eksterne enhed, der er direkte forbundet med datastrømmen.

b. Data kan strømme direkte fra en terminator til en anden terminator.

c. Ingen datastrøm kan angives til eller fra en proces.

d. Data flow er angivet fra terminator til en datalager (fil) eller fra en fil til terminator eller mellem to filer uden behandling.

e. Processerne er mærket som objekter, som f.eks. Faktura eller substantiv som bookingklerk.

Efter at DFD'erne er tegnet for hvert delsystem, kan fremtidige behandlingsdetaljer blive slået ud og beskrevet i strukturerede engelske (psedo-koder). Disse psedo-koder bruges senere til kodning af applikationerne. Lederens rolle i denne proces er begrænset kun til at hjælpe informationssystemerne professionelle med at identificere og forstå de algoritmer, der er involveret i behandlingen.

5. Implementeringsmodul:

Dette modul beskæftiger sig primært med test af systemet, træning af brugerne og installation af systemet.

Test af systemet:

Afprøvningen af ​​forskellige moduler udføres på forskellige stadier af udviklingsprocessen. Den gyldne regel, der skal tages i betragtning under testningen, er, at testen skal udføres med henblik på at identificere de måder, hvorpå systemet sandsynligvis vil mislykkes. Det skal ikke være med det formål at bevise, at systemet vil fungere efter designspecifikationen. Test af system er processen med at søge svar på to grundlæggende spørgsmål:

1. Om informationssystemet tjener virksomhedens informationsbehov? Processen, der søger svar på dette spørgsmål, betegnes af informationssystemets fagfolk som systemvalideringsprocessen.

2. Fungerer informationssystemet korrekt? Verifikationsprocessen søger svar på dette spørgsmål.

Da arten og graden af ​​alvorligheden af ​​fejl er forskellige på forskellige stadier af systemudvikling, administreres forskellige test på forskellige moduler og i systemet som helhed.

Enhedstest:

De tests, der anvendes på modulniveau, kan kaldes enhedsprøver. Disse tests udføres for at registrere fejl i grænseflader, databaser, aritmetiske operationer og kontrollogik. De udføres ved at køre et modul i informationssystemet på testdata specielt designet til at teste om systemet:

en. Accepterer forkert type data (f.eks. Accepterer numerisk værdi for navn);

b. Accepterer ud af gyldige intervaldata (f.eks. Accepterer dato med måned større end 12);

c. Forårsager ukorrekt springning fra en procedure til en anden procedure.

Systemtest:

Da enhedstesten udføres isoleret, er det vigtigt, at integrationsprøverne udføres for at kontrollere, om disse enheder fungerer korrekt som en gruppe. På grund af mangfoldighedernes forskellige forskelle skal forskellige teststrategier følges for at kontrollere gyldigheden og verificere systemet. Fertucks foreslår tre strategier til testning af informationssystemet:

(a) Ryd boks test:

I denne strategi er test designet til at fastslå, om de procedurer, der følges for behandling, svarer til kravene i ansøgningen. Dette kan opnås ved hjælp af en gennemgang af medarbeidsgivere, der ikke var direkte tilknyttet udviklingsfasen.

Alternativt kan en struktureret gennemgangsmetode anvendes. Ved denne metode gennemgår en gruppe personer procedurerne, først og fremmest at se på fejlbehæftede dele og identificere korrektioner, der skal foretages. Derefter vurderer gruppemedlemmer den produktion, som systemet vil tilbyde for en given type input, og test, om systemets output er korrekt eller ej.

(b) Test af sort boks:

I denne strategi testes systemet for ugyldige data eller data, der kan forårsage fejl i systemets funktion. Udgangen kontrolleres for at fastslå, om der er opstået en fejl. For eksempel kan data indeholde negativ værdi for bestilt mængde eller en brøkdel for en variabel, der kun kan tage hele værdien.

(c) Afkrydsningsfelt test:

Denne strategi forudsætter, at det aldrig er muligt at levere et helt fejlfrit informationssystem. Således er det efter alle test og modifikationer nødvendigt at estimere antallet af fejl, der stadig er tilbage i systemet. For at estimere dette tal kan nogle fejl indføres med vilje i systemet. Derefter udføres testene igen for at opdage fejl.

Andelen af ​​indførte fejl konstateres som et skøn over forholdet mellem de reelle fejl, der er konstateret under de tidligere tests. Således, hvis 90% af de indførte fejl blev registreret under afkrydsningsboksen test, mens i alt 450 fejl blev opdaget oprindeligt under testen af ​​klar boks og black box, betyder det, at 50 ægte fejl fortsat forbliver uopdagede i systemet.

Installation:

Installation er en proces til udskiftning af det gamle system med et nyt system. Der er stort set fire metoder til installation. Den 'kolde' installation sker, når det gamle system straks afbrydes og erstattes af et nyt system.

En sådan installation har fordelen af ​​hurtigere psykologisk tilpasning med det faktum, at det nye system skal bruges. En sådan tilgang kan dog ikke være egnet, hvis gamle data fra det tidligere system er værdifulde, eller det nye system har nogle problemer. Til installation af regnskabsinformationssystemer er denne tilgang ikke fundet acceptabel. De alternative tilgange omfatter:

a) Pilotinstallation:

Et system må kun installeres til brug af en valgt repræsentativ brugergruppe, der tester systemet ved at bruge det. Andre brugere fortsætter med at bruge gammelt system. Når problemerne i systemet bliver taget hånd om, begynder andre brugere også at bruge systemet. Denne tilgang er også ikke særlig populær for regnskabsinformationssystemer, fordi hele regnskabsdatabasen skal opdateres, før den kan bruges af brugerne.

Brugerens oplysningskrav overskrider afdelinger og afdelings grænser i organisationsdiagrammet. Denne tilgang kan dog anvendes til komplette regnskabsafdelinger som filial, regionalt kontor osv. Således kan et regnskabsinformationssystem anvendes af udvalgte filialer. Når de har vist sig at være fejlfri, kan de også bruges af andre filialer.

(b) Phase-in installation:

Under denne tilgang finder installationen sted i etaper. Disse trin er uafhængige komponenter i informationssystemet. Således kan indtægtslivscyklussen for et regnskabsinformationssystem først installeres, og andre livscyklusser kan følge efter hinanden. Denne tilgang hjælper med at fokusere på en udvalgt del af systemet. Det hjælper med at forbedre accepten af ​​systemet blandt brugerne, fordi det gør det muligt for brugeren at klare det nemt.

(c) Parallel installation:

Den parallelle installation betyder, at både det gamle og det nye system kører samtidigt i en vis periode, indtil nyheden af ​​det nye system er bevist. Denne metode er mest populær for regnskabsinformationssystemet, fordi dette er den sikreste af alle andre metoder. Det eneste problem her er omkostningerne ved parallel løb og tendensen til at forlænge parallelængden, der drives af dem, der modstår forandring.

Post Implementation Review:

Hvert system skal gennemgås, når implementeringen er gennemført. En sådan anmeldelse hjælper ikke kun med at identificere systemets svagheder, men forbereder også en dagsorden for modifikation for fremtiden. Det er faktisk en læringsproces. Systemrevision kan også udføres for at undersøge, hvor godt systemet er, hvad angår omkostninger, leveringsplan, fuldstændighed og kvalitet.