Utvikling av regnskapsinformasjonssystem: Enterprise, Database og Interface Modules

Utvikling av regnskapsinformasjonssystem: Enterprise, Database og Interface Modules!

En rekke regnskapsprogramvarepakker er tilgjengelige, og tilbyr en rekke funksjoner. De koster mye mindre enn hva tilpasset regnskapsmessig programvare ville koste. Disse programvarepakker tilbyr imidlertid kun strukturen for regnskapsinformasjonssystemer. I det minste reduserer de programmeringsinnsatsen for regnskapsinformasjonssystemer.

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

Utviklingen av regnskapsinformasjonssystemer er mye mer enn programvaren for ledgerpostering og rapportering av formasjon. Det innebærer også etablering av prosedyrer for innhenting av data og distribusjon, samt analyse av regnskapsinformasjon.

Utviklingen av et regnskapsinformasjonssystem er forklart med spesiell henvisning til kravene til et mellomstort til stort næringsliv. Disse trinnene vil imidlertid være felles for de fleste andre informasjonssystemer i et bedriftsforetak.

1. Bedriftsmodul:

Bedriftsmodulen for informasjonssystemutvikling innebærer identifisering av grunnleggende enheter og deres sammenhenger, identifisering av grunnleggende aktiviteter og omgruppering av disse aktivitetene i delsystemer. Deretter blir prioritetene bestemt på grunnlag av kostnads ​​/ nytteanalyse for bedriften.

Identifiserende enheter:

Et stort antall enheter eksisterer i et næringsliv og listen er like variert som forretningsaktivitetene er. Men på dette stadiet er det primære problemet å identifisere de brede enhetene, hver av dem som inneholder en gruppe av elementære enheter. Kerner 5 peker ut seks grunnleggende enheter i et næringsliv.

De er kunder, produkter, leverandører, personell, fasiliteter og penger. I et regnskapsinformasjonssystem er det tre grunnleggende enheter, nemlig transaksjoner, konto og prosessperiode. Forholdet mellom disse enhetene kan uttrykkes ved hjelp av ER-diagrammer som vist Fig. 8.2.

Transaksjonene skal være av ulike slag, for eksempel kvitteringer, betalinger, salg, kjøp, kjøp av eiendeler eller tilbakebetaling av gjeld mv. Og hver av dem kan kalles en lavere enhet. Tilsvarende kan kontoer være av forskjellige slag, for eksempel eiendeler, gjeld, inntekter og kostnader.

Hvert av disse hovedene kan ha lavere nivåer, for eksempel anleggsmidler og omløpsmidler. Disse enhetene kan deles videre i enheter på lavere nivå, som for eksempel land og bygg, anlegg og maskiner mv. På dette stadiet må de brede enhetene imidlertid identifiseres. Detaljerne er utarbeidet når databasene ble utformet.

Enhetene er identifisert i lys av og med sikte på å definere omfanget og fokuseringen av informasjonssystemet. For eksempel, hvis informasjonssystemet betraktes som et strategisk informasjonssystem, skal de brede enhetene identifiseres i lys av de strategiske pressene som bedriften planlegger å gi til sine aktiviteter ved hjelp av informasjonssystemet.

Disse drivkraften kan være kostnadsminimering, kundeservice, produktdifferensiering og strategiske allianser. De grunnleggende enhetene i et slikt tilfelle vil være kunder, kanaler, konkurrerende foretak, produkter, etc.

Aktivitetsanalyse:

Et annet viktig aspekt av virksomhetsmodulen er identifisering av aktiviteter knyttet til enhetene. Disse aktivitetene er bredt identifisert i form av relasjoner i ER-diagrammer. Imidlertid oppnås detaljer ved hjelp av aktivitetsanalyse. Den eksisterende organisasjonsstrukturen er en viktig kilde til informasjon om de brede aktivitetene som foretas av bedriften.

Men for å utvikle informasjonssystemer som er uavhengige av dagens organisasjonsstruktur, er det viktig å basere aktivitetsanalysen på de grunnleggende enhetene som allerede er identifisert ovenfor. Det neste nivået av aktivitetsanalyse innebærer identifisering av livssyklusaktivitetene. I tilfelle "transaksjoner" er en av de grunnleggende enhetene i et regnskapsinformasjonssystem, er det fire brede livssyklusaktiviteter, nemlig:

1. Innkjøp livssyklus

2. Produksjons livssyklus

3. Inntekter livssyklus

4. Investeringer livssyklus

På samme måte har behandlingsperioden to grunnleggende livssyklusaktiviteter, nemlig:

en. Planlegging og kontroll livssyklus

b. Intern og ekstern rapportering livssyklus

Disse livssyklusaktivitetene er pågående aktiviteter og utføres kontinuerlig. Hver av disse aktivitetene kan være sekvensielt knyttet til noen andre aktiviteter. Det tredje nivået av aktivitetsanalyse innebærer oppdeling av livscyklusaktivitetene i funksjoner.

For eksempel må hver type transaksjon påbegynnes og anerkjennes; da må dataene om transaksjonen bli fanget, kodet for fremtidig klassifisering, klassifisert, oppsummert og rapportert. Disse funksjonene skal utføres forskjellig for ulike typer transaksjoner. Prosessen med å definere funksjonene fokuserer bare på de aktivitetene som lager, oppdaterer eller bruker informasjon i databasen til bedriften.

På dette aktivitetsnivået er aktivitetene selvforsynte, har klart definerte start- og sluttbegivenheter eller noder og en identifiserbar person eller en gruppe personer som er ansvarlige for å utføre funksjonen.

Disse funksjonene kan da deles inn i delfunksjoner til funksjonene er spesifikke nok til å definere modulen for dataprogrammer. Oppdelingen av livscyklusaktiviteter i funksjoner og delfunksjoner bidrar til å identifisere funksjoner som gjentas i mer enn én livssyklusaktivitet.

For eksempel kan funksjonen for klassifisering av innfangne ​​data utføres i innkjøp og markedsførings livssykluser. En slik aktivitetsanalyse hjelper til med å identifisere muligheter for å forbedre eksisterende design ved å:

1. eliminere de overflødige funksjonene

2. kombinere dupliserte funksjoner

3. Forenkle og forbedre behandlingsmetodene

Redundansen kan identifiseres ved nøye analyse av aktivitetene. Aktivitetene som sannsynligvis vil gi muligheter til å forbedre behandlingen, inkluderer aktiviteter:

en. Det utføres også andre steder

b. Det kan kombineres med andre aktiviteter

c. Det kan også håndteres av en annen person

d. Det kan utføres på et annet stadium av livssyklusen som ikke legger til noen verdi for produktet eller tjenesten til informasjonssystemet.

Et ord med forsiktighet her er at ikke alle avskedigelser er dårlige. Faktisk kan enkelte redundanser eller duplisering bli tilsiktet å krype inn i systemet. Dette kan gjøres for å forbedre ytelsen og påliteligheten til systemet.

For eksempel kan noe av dupliseringen være nødvendig for å sikre enkelhet av prosedyrer og forbedre behandlingshastigheten. Eliminering av redundans kan resultere i "å sette alle egg i en kurv" og kan dermed påvirke påliteligheten. Risikoen for uventede implikasjoner og lav avkastning fra foreslått ny metode eller prosedyre er andre faktorer som fortjener oppmerksomhet før endringer foreslås i informasjonssystemet.

Gruppering av aktiviteter i subsystemer:

Etter at aktivitetene er definert ved hjelp av topp-ned-tilnærmingen som er vedtatt ovenfor, blir de omgruppert for å danne delsystemer. En viktig beslutning om å bli tatt på dette stadiet, er knyttet til gruppering. Det kan ikke eksistere et enkelt objektivt kriterium for å bestemme hvilket delsystem en aktivitet tilhører.

Den nåværende organisasjonsstrukturen kan gi et grunnlag for gruppering av aktiviteter. Men den nåværende organisasjonsstrukturen kan gjennomgå endringer og bruken av informasjonssystemet kan gå tapt.

For å gruppere aktivitetene i subsystem, tar vi hjelp fra organisasjonsteori. En av de viktigste funksjonene i en god organisasjonsstruktur er at den tar sikte på å legge til rette for koordinering av aktiviteter.

Et effektivt kommunikasjonssystem er avgjørende for bedre koordinering. Det er derfor viktig å gruppere aktiviteter på en slik måte at kommunikasjon lettes i gruppen, og behovet for kommunikasjon mellom grupper minimeres.

For å representere og dokumentere gruppering av aktiviteter i delsystemer, benyttes strukturdiagrammer eller hierarkiske blokkdiagrammer. Figur 8.3 viser strukturskjema som viser komponentene i inntektssyklusen.

Lignende strukturdiagrammer kan utarbeides for andre klynger av aktiviteter, og til slutt er disse delsystemene integrert med hverandre og gir byggeklossene for et regnskapsinformasjonssystem.

Delsystemene som er identifisert ved gruppering av aktiviteter, er seriøse konkurrenter for å være enheter i organisasjonsstrukturen. Fordelen med klyngemetoden for gruppering av aktiviteter er at grupperingen er basert på funksjoner og ressurser, og ikke på geografiske områder.

En slik clustering på grunnlag av funksjoner sikrer homogenitet blant medlemmene av gruppen mennesker som er tilknyttet hvert av delsystemene. Effekten av informasjonssystemorganisasjon på organisasjonsstruktur er ikke uvanlig.

Ofte har introduksjon av informasjonssystemer ledsaget av endringer i organisasjonsstrukturen på grunn av at nye informasjonssystemer forandrer måten folk jobber i en organisasjon.

Det er derfor enda viktigere at informasjonssystemdesignere jobber aktivt sammen med organisasjonsutviklingsfolk mens gruppering av aktiviteter i klynger og delsystem gjøres. Dette sikrer ikke bare at den nye strukturen er mer pragmatisk, men også mer akseptabel for mennesker. I slike tilfeller er overgangen fra gammelt system til nytt en mindre smertefullt og billigere.

Innstilling av prioriteringer:

Når delsystemene er identifisert og integrert som helhet, må prioriteringene bestemmes blant de ulike delsystemene og funksjonene i hvert system. Informasjonssystemet vil kreve forpliktelse til økonomiske ressurser.

I tillegg kan det være implisitte kostnader for det nye systemet når det gjelder nødvendige endringer i operasjonsprosessen. Det er derfor viktig å veie fordeler og ulemper ved hvert delsystem og delsystem før de utformes og implementeres.

Hvert delsystem evalueres på grunnlag av veldefinerte evalueringskriterier definert i forhold til de kritiske suksessfaktorene (CSF). Disse faktorene er allerede identifisert i avsnitt 8.2.

Den andre metoden er brainstorming, hvor de relevante personene i organisasjonen kommer sammen for å identifisere de faktorene som fortjener hensyn ved prioritering. Fri strøm av ideer oppfordres i første fase.

Det underliggende prinsippet, her, er at ingen ide er dum eller irrelevant på dette stadiet. I løpet av andre etappe begynner og eliminerer prosessen med eliminering, blir forslagene ferdigstilt.

Når listen over faktorer er avsluttet, blir relative vekter tilordnet, og et kriteriums funksjon er definert for å evaluere hver komponent i det foreslåtte regnskapsinformasjonssystemet.

2. Databasemodul:

Regnskapsinformasjonssystem behandler stort volum av data. Administrering av data er dermed en av de viktigste hensynene i utviklingsprosessen. Det er to grunnleggende tilnærminger til datadesign, nemlig:

en. Den tradisjonelle, applikasjonsorienterte tilnærmingen, og

b. Databasen tilnærming.

Tradisjonell tilnærming:

Den tradisjonelle tilnærmingen til datastruktur er applikasjonsorientert i den forstand at for hver applikasjon genereres et separat sett med datafiler i henhold til kravene. Med andre ord, datafilene er dedikert til en gitt applikasjon og er på en måte eid av søknaden.

For eksempel skal en kundefordringsapplikasjon ha kundemasterdatafilen, en salgstransaksjonsfil og en kvittering fra kundens transaksjonsfil. Disse datafilene brukes kun til kundefordringsprogrammet.

Denne tilnærmingen er egnet for mindre regnskapsinformasjonssystemer på grunn av sin enkelhet. Men etter hvert som informasjonssystemet vokser i forhold til datamengden og kompleksiteten av analysen, gir det også opphav til visse problemer.

Det grunnleggende problemet med den tradisjonelle tilnærmingen er at applikasjonsprogrammene er avhengige av datafilene de bruker og manipulerer. Som følge av dette krever endring i datafilen (når det gjelder tillegg eller sletting av dataelement) endringer i alle programmene ved hjelp av datafilen.

Denne dataavhengigheten motvirker endringer i datafiler som fører til ufleksibilitet. I fravær av verktøy for å utføre rutinemessige datahåndteringsaktiviteter på dataene, skal slike anlegg inkluderes i programmene som bruker datafilen. Dette kompliserer programmet. Et annet problem angår å møte ad hoc-spørringen.

For uventet type spørring må spesialprogrammer skrives. Slike spesialprogrammer tar tid å utvikle seg og har kun en gang bruk og er dermed dyre. Det er mye duplisering i opptak av dataposter.

For eksempel kan dataelementene som kundenavn, fakturanummer, pris etc. bli inkludert i transaksjonsfiler for søknadsbehandlingsprogram, samt søknad om kundefordringer. Dette fører til redundans i data.

Data redundans resulterer i ineffektiv bruk av lagringsmedier. Det påvirker også kvaliteten på dataene fordi oppdatering av et gitt datapunkt kanskje ikke finner sted i alle filene der dataelementet er lagret.

Database tilnærming:

Den moderne tilnærmingen til datadesign er databasemetode. Denne tilnærmingen er basert på forutsetningene at flere applikasjoner krever datasett som har mye til felles. Det er derfor bedre å ha et felles datalag som oppfyller datakravene til hver applikasjon i informasjonssystemet.

Fellesregisteret kalles databasen og styres av et styringssystem kalt Database Management System (DBMS). DBMS er programvare som er spesielt utviklet for å administrere dataene i databaser i henhold til forespørsler fra applikasjonsprogrammer, samt fra de som kommer direkte fra brukerne. Den konseptuelle utformingen av databasemiljøet er vist ved hjelp av figur 8.5.

Databaseprosessen tar seg av problemene i applikasjonsmetoden. Det sikrer data uavhengighet som DBMS tar vare på dataflyten fra databasen til applikasjonsprogrammer. Brukerprogrammet trenger ikke å bry seg om plasseringen av dataene i databasen. En datakatalog er opprettholdt, og data kan kalles ved hjelp av ordene som er angitt i dataloggen.

Databasen tilnærming reduserer også størrelsen og kompleksiteten til applikasjonsprogrammene som rutinemessig type databehandling som sortering utføres av DBMS. DBMS brukes også til å betjene behovene til ad hoc-spørringen. DBMS bruker Structured Query Language (SQL) som språk for kommunikasjon mellom brukeren og databasen.

Språket er veldig enkelt og ganske nær engelsk. Dette sikrer at brukeren kan få informasjon fra databasen etter behov. Mengden trening som kreves av ledere for å lage ad hoc-spørringer er minimal, og få timer med trening kan gi grunnleggende ferdigheter for å bruke språket. Kanskje er den viktigste fordelen med databasen tilnærming reduksjonen i redundansen i databaser.

Det er mange modeller som ofte brukes i design av databaser. Den moderne tilnærmingen er imidlertid å følge ER-modellen for databasedesign. Denne tilnærmingen er topp ned-tilnærming, og ER-diagrammer trukket tidligere i Enterprise Module blir utgangspunktet.

For hver enhet og forhold identifiseres attributter og dokumenteres i utvidede ER-diagrammer (EER-diagrammer). I et regnskapsinformasjonssystem kan EER trekkes for hver enhet (transaksjon og kontoer) og forholdet (effekt) for transaksjonskontoene er vist i ER-diagrammet. For eksempel, for en salgstransaksjon, kan attributter spesifiseres og dokumenteres som vist i figur 8.6.

Disse attributter blir dataelementene (feltene) i en post i datafilen for hver enhet (i dette tilfellet salgstransaksjonsfil). På samme måte trekkes andre utvidede ER (EER) diagrammer for andre enheter og relasjoner.

Når disse attributene er identifisert, er det sannsynlig at noen av attributter skal være felles i forskjellige EER-diagrammer. For å unngå duplisering av slike vanlige attributter, gjennomføres normalisering av data.

3. Grensesnittmodul:

En grensesnittmodul definerer kildene til dataposter og formatene til inngang / utgang og dialogskjermer som skal brukes i systemet. Det definerer også rapportformatene og skjermbildene for navigering fra en del av informasjonssystemene til den andre.

Modulen er med andre ord opptatt av å definere grensesnittet mellom brukeren og maskinen. Betydningen av grensesnittmodulen har økt på grunn av økt kommunikasjon mellom bruker- og informasjonssystemer.

Både datainngangen og datasøket er blitt interaktive. I mange tilfeller elimineres innskrivingsskjemaer fra prosessen, og datainngangen foregår direkte. De endrede kravene til datasøke gjør mange rapportblanketter for stive. Interaktive rapportskjermbilder gir større fleksibilitet i datasøk og tillater brukerdefinerte rapportformater for visning og utskrift.

Input skjermbilder:

Inngangsskjermer er definert i lys av den naturlige prosessen med forretningsaktiviteten. Derfor er de hovedsakelig avhengig av skjemaene som brukes til å registrere dataene manuelt når de først mottas av bedriften. Disse skjemaene, i et regnskapsinformasjonssystem, kan inkludere faktura, innkjøpsordre, salgsordre, kostnadsbevis, etc.

I grensesnittmodulen blir således skjemaer også gjennomgått; Redesigned og input skjermer er definert i lys av skjemaer som brukes av bedriften. I et regnskapsinformasjonssystem må man være mer forsiktig med hensyn til skjermdesign.

En mindre forbedring i inntaksskjermbildet som sparer datainngang kan føre til betydelige besparelser fordi antall ganger dataregistreringsskjermbildet brukes er svært stort. Følgende faktorer kan holdes i bakhodet mens du designer inngangsskjermbildet:

(a) Matchende med skjemaer:

Inndataskjermformatet må samsvare med inntastingsskjemaer. Noen ganger betaler det seg å adoptere det samme formatet som brukes av innskrivingsskjemaet. I den grad det er mulig, kan fargene på bakgrunnen på skjermen tilsvares med fargen på skjemaet.

(b) Interaktiv:

Inngangsskjermen skal være interaktiv. Det bør påpeke feil i dataregistrering rett ved inngangen og tillatelser. Hvert dataelement må ha noen data valideringstilstand, og eventuelle brudd på slike data validering tilstand skal automatisk utheves på tidspunktet for dataoppføring.

For eksempel må en dataregistreringsskjerm for fakturaoppføring peke på feil ved oppføring av dato dersom datoen er ugyldig. Datoen kan være ugyldig fordi den er utenfor regnskapsperioden eller måneden som er oppgitt, er større enn tolv.

(c) Konsistens:

Inndataskjermene bør være konsekvente når det gjelder definisjon av vilkår og plassering for visse vanlige typer dataelementer. Det bidrar til å redusere treningstiden som den forbedrer kjennskapen; For eksempel kan datoen for transaksjonen alltid plasseres i høyre hjørne av hvert transaksjonsdokument.

(d) Enkelhet:

En av de grunnleggende funksjonene til en god inngangsskjerm er enkelheten. For mange uthevede seksjoner, blinkende verdier eller attributter, eller å legge for mange bokser og understreker, legger bare til kompleksitet og forvirring. Noen ganger piper brukes til å påpeke datainngangsfeil. Det bør være en god bruk av slike pip og generelt bør disse unngås.

(e) Fleksibilitet:

Inndataskjermen skal kunne endres. Det skal tillate brukere å gjøre endringer i form av tillegg eller sletting og flytting av dataelement. Prosedyren for modifikasjon bør være enkel. I disse dager tilbyr skjermgeneratorene fra ulike programvareproduktene funksjoner som dra og fikse / slippe noe datapunkt fra skjermen ved å bruke vanlig pekeenhet som mus.

(f) Skreddersydde:

Skjermene må være skreddersydd for hver kategori av bruker. Dette vil redusere unødvendig lange start- og inngangsprosedyrer.

Rapporter skjermbilder:

Rapportene kan utarbeides for videre analyse av noe annet dataprogram eller av brukeren selv. Dataene som er beregnet for behandling av dataprogrammer, for eksempel regneark, statistiske pakker, tekstbehandlere, lagres i datafiler.

Det er bedre å sette dem i standard dataformat slik at de lett kan nås. Rapportene som er ment for brukere, holdes vanligvis i form av tekst, tabeller og grafer. Det bør arbeides for at rapportene skal utarbeides og kommuniseres rettidig, nøyaktig, tydelig og til en lav pris.

Dialogskjermbilder:

Dialogskjermene er de som brukes til å identifisere og utføre oppgavene i informasjonssystemet. De definerer hva som kan gjøres ved hjelp av informasjonssystemet, hvordan man navigerer fra en oppgave / prosedyre til en annen og hvordan man utfører ulike oppgaver som informasjonssystemet tillater.

Disse skjermene skal være enkle og entydige. Enkelheten kan bli introdusert ved å gi grafisk brukergrensesnitt (GUI) og ha begrenset antall menyelementer på en skjerm. Fremgangsmåten for navigering fra en meny til den andre skal være enkel, i riktig rekkefølge og lett å følge. Det bør også påpeke feil i å utøve alternativer og være rask for å korrigere prosedyre.

CASE-verktøy for skjermdesign:

En rekke CASE-verktøy er tilgjengelige for utforming av skjemaer, skjermbilder og rapporter. Disse verktøyene har fordelen av å tilby utforming av miljø som er fleksibelt og enkelt å forstå selv for en ny bruker.

Siden disse verktøyene har skjerm prototyping fasiliteter, er det mulig å ha større involvering av brukere i prosessen med skjermdesign. Selvfølgelig tillater slike verktøy raskere endringer og forbedrer produktiviteten til programmerere ved å generere koder for endelig implementering. Dette resulterer i redusert utviklingstid.

Når skjemaene, inn / ut skjermene og dialogskjermene er klare, bør de testes og modifiseres tilsvarende. Skjemaene og skjermene som er designet med CASE-verktøyene, kan enkelt endres. Derfor må det arbeides for å forbedre akseptabiliteten av systemet ved riktig testing og modifikasjon av skjemaer og skjermbilder.

4. Programmodul:

Denne modulen utvider delsystemene som allerede er identifisert i bedriftsmodulen. For hvert delsystem som er identifisert i strukturskjemaet, er detaljerte prosesseringsprosedyrer definert i denne modulen.

Programmodulen er med andre ord primært opptatt av prosessene som er involvert i å konvertere inngangsdata til verdier som skal utgjøre en del av rapportene som definert i grensesnittmodulen. Det kan bemerkes at bare disse prosessene skal defineres som

(a) Endre verdiene i databasene, eller

(b) Det er ikke deler av databasen, men kreves i rapportene som er definert i grensesnittmodulen.

Verdiene som allerede finnes i databasen, kan nås ved hjelp av DBMS-spørrespråk i henhold til kravet til brukere uten utvikling av programmer for dette formålet. Dermed er oppgaven med applikasjonsmodulen redusert av det arbeidet som allerede er utført i databasedesign og skjermdesign.

Dataflytdiagram:

Ledelsens rolle i denne modulen er i utgangspunktet å identifisere den grunnleggende prosesseringsprosedyren. De detaljerte algoritmer er generelt definert og dokumentert av informasjonssystemprofessoren, selvfølgelig, med aktiv hjelp fra lederen.

Verktøyet som brukes til å uttrykke prosessene som skal utføres for å konvertere inngangsdataene til utgang, er dataflytdiagrammet (DFD). Det beskriver datastrømmen. Det definerer hva som må gjøres og ignorerer hvordan det skal gjøres eller hvordan det ble gjort tidligere. Denne tilnærmingen tillater endringer i systemet og svakheter i det eksisterende systemet kan fjernes etter denne tilnærmingen.

DFD-symboler:

Det finnes fire grunnleggende symboler brukt i DFDs. De er:

(i) Terminator:

Terminator er en ekstern kilde til datastrøm eller ekstern synkronisering av data. Det er en ekstern enhet eller objekt som kunde, leverandør, aksjonærer, etc. Siden terminatorene er eksterne enheter, er kommunikasjonen mellom terminatorene ekskludert fra systemet. Terminatoren er symbolisert av et rektangel (generelt skygget) og etiketten er plassert i rektangelet.

(ii) Datafløm:

Datastrømmen bærer en rekke dataelementer angående hendelsen som startes av terminatoren. Det er symbolisert med en pil i DFD og retningen av strømmen er indikert av pilens retning. Pilene er generelt merket med mindre de er rettet til eller fra datafiler. Som påpekt tidligere, er datastrømmer mellom to terminatorer ikke inkludert i DFD og dermed kan data ikke strømme direkte mellom to terminatorer.

(iii) Prosess:

Prosess transformerer innkommende data for omdirigering til datalager eller terminator. Det er symbolisert av et rektangel med avrundede hjørner eller en sirkel. Det er selvfølgelig merket med et verb.

(iv) datalager:

Filer er datalagerene i informasjonssystemer og er representert i DFDs i form av åpne rektangler. Generelt svarer de til tabeller i databaser. En delvis oversikt over dataflytdiagrammet for salgsordrebehandling er vist i figur 8.7.

Det kan bemerkes at noen tilleggssymboler og mindre variasjoner i symboler som representerer ulike komponenter i DFD, også er i bruk. De ovennevnte symbolene er de mest brukte og er i henhold til den grafiske konvensjonen som foreslås av Gane og Sarson.

Mange tid, en leder finner tegning av DFD veldig vanskelig og frustrerende opplevelse. Hver gang man tegner en DFD, finner man å ha ignorert det ene eller det andre aspektet av dataflyten. Heldigvis har CASE-verktøyene muligheter for å opprette og modifisere DFD-er. Begynnerne anbefales imidlertid å følge disse trinnene for å løse dette problemet:

(a) Identifiser alle inngangsdata-strømmer og utdata-datastrømmer separat sammen med terminatorer, sette inndata-strømmer på venstre side og utdata-datastrømmen til høyre.

(b) Merk terminatorene ved hjelp av datastrømnavn eller adjektivnavn.

(c) Identifiser prosesser fremover fra inngangsdata strømmer og bakover fra utdatadatastrømmer til de møtes i midten.

(d) Merk prosessene ved hjelp av verbnavn.

En leder må være forberedt på å redraw DFD fordi mange ganger blir datastrømmen klar til leder bare etter å ha tegnet DFD. Brukerinnblanding på dette stadiet er svært nyttig ikke bare for å redusere innsatsen fra lederen, men også for å forbedre DFD.

Testing av DFD:

Det foreslås at DFD må testes grundig før den er ferdiggjort. Følgende er noen av de vanlige feilene i DFD-design:

en. Termineringsetiketten kan være navnet på en person eller et foretak i stedet for klassen. For eksempel kan en terminator være merket som M / s. BR Ltd. i stedet for eneste leverandør. En annen feil kan være at transportøren blir satt som terminator i stedet for den eksterne enheten som er direkte forbundet med datastrømmen.

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

c. Ingen datastrøm kan angis til eller fra en prosess.

d. Dataflyt er angitt fra terminator til en datalager (fil) eller fra en fil til terminator, eller mellom to filer uten behandling.

e. Prosessene er merket som objekter, som faktura eller et substantiv som bookingklerk.

Etter at DFD er tegnet for hvert delsystem, kan fremtidige behandlingsdetaljer bli kalket ut og beskrevet i strukturert engelsk (psedo-koder). Disse psedo-koder brukes senere til koding av applikasjonene. Lederens rolle i denne prosessen er begrenset bare til å hjelpe informasjonssystemene profesjonelle til å identifisere og forstå algoritmer involvert i behandlingen.

5. Implementeringsmodul:

Denne modulen er primært opptatt av testing av systemet, opplæring av brukere og installasjon av systemet.

Testing av systemet:

Testingen av ulike moduler gjøres på ulike stadier av utviklingsprosessen. Den gylne regelen som skal holdes i bakhodet mens du tester, er at testingen skal gjøres for å identifisere måter systemet vil trolig mislykkes på. Det skal ikke være med sikte på å bevise at systemet vil fungere som i designspesifikasjonen. Testing av systemet er prosessen med å søke svar på to grunnleggende spørsmål:

1. Hvorvidt informasjonssystemet betjener bedriftens informasjonsbehov? Prosessen som søker svar på dette spørsmålet, betegnes av fagfolk i informasjonssystemet som systemvalideringsprosess.

2. Fungerer informasjonssystemet riktig? Verifikasjonsprosessen søker svar på dette spørsmålet.

Ettersom naturen og graden av alvorlighetsgrad av feil er forskjellige på forskjellige stadier av systemutvikling, administreres forskjellige tester på forskjellige moduler og på systemet som helhet.

Enhetstest:

Tester som brukes på modulnivå kan kalles enhetstester. Disse testene utføres for å oppdage feil i grensesnitt, databaser, aritmetiske operasjoner og kontrolllogikk. De utføres ved å kjøre en modul i informasjonssystemet på testdata spesielt designet for å teste om systemet:

en. Godtar feil type data (for eksempel aksepterer numerisk verdi for navn);

b. Godtar uten gyldig rekkevidde data (for eksempel aksepterer dato med måned større enn 12);

c. Forårsaker feil hopping fra en prosedyre til en annen prosedyre.

Systemtest:

Da enhetstester utføres isolert, er det viktig at integreringstestene skal gjennomføres for å kontrollere om disse enhetene fungerer som en gruppe. På grunn av forskjellene i naturen av feil, skal ulike teststrategier følges for å kontrollere gyldigheten og verifisere systemet. Fertucks foreslår tre strategier for testing av informasjonssystemet:

(a) Clear boks testing:

I denne strategien er tester designet for å fastslå om prosedyrene som følges for behandling, samsvarer med kravene i søknaden. Dette kan oppnås ved hjelp av gjennomgang av medarbeiderne av informasjonssystemer som ikke var direkte tilknyttet utviklingsstadiet.

Alternativt kan strukturert gjennomgangsmetode anvendes. I denne metoden vurderer en gruppe personer prosedyrene, først ta en titt på feilproblemer og identifiserer korrigeringer som må gjøres. Deretter vurderer gruppemedlemmene produksjonen som systemet vil tilby for en gitt type inngang og teste om utgangen av systemet er riktig eller ikke.

(b) Svart boks testing:

I denne strategien testes systemet for ugyldige data eller data som kan forårsake feil i systemets funksjon. Utgangen kontrolleres for å fastslå om det har oppstått en feil. For eksempel kan data inneholde negativ verdi for bestilt kvantitet eller en brøkdel for en variabel som bare kan ta hel verdi.

(c) Ticking box testing:

Denne strategien forutsetter at det aldri er mulig å levere et helt feilfritt informasjonssystem. Således, etter alle test og modifikasjoner, er det nødvendig å estimere antall feil som fortsatt er igjen i systemet. For å estimere dette nummeret, kan noen feil innføres med vilje i systemet. Deretter utføres testene igjen for å oppdage feil.

Andelen innførte feil oppdaget er tatt som et estimat av andelen virkelige feil som oppdages under de tidligere testene. Således, hvis 90% av de introduserte feilene ble oppdaget under ticking-boksen, mens totalt 450 feil ble oppdaget opprinnelig under testboksen for klar boks og svart boks, betyr det at 50 virkelige feil fortsetter å forbli uoppdaget i systemet.

Installasjon:

Installasjon er en prosess for å erstatte det gamle systemet med et nytt system. Det er stort sett fire tilnærminger til installasjonen. Den "kalde" installasjonen er ferdig når det gamle systemet umiddelbart avsluttes og erstattes av et nytt system.

En slik installasjon har fordelen av raskere psykologisk tilpasning med det faktum at det nye systemet skal brukes. En slik tilnærming kan imidlertid ikke være egnet dersom gamle data fra det tidligere systemet er verdifulle eller det nye systemet har noen problemer. For å installere regnskapsinformasjonssystemer, har denne tilnærmingen ikke blitt funnet akseptabel. De alternative tilnærmingene inkluderer:

(a) Pilotinstallasjon:

Et system kan installeres for bruk bare av en valgt representativ brukergruppe som tester systemet ved å faktisk bruke det. Andre brukere fortsetter å bruke gammelt system. Når problemene i systemet blir tatt vare på, begynner andre brukere også å bruke systemet. Denne tilnærmingen er heller ikke særlig populær for regnskapsinformasjonssystemer fordi hele regnskapsdatabasen må oppdateres før den kan brukes av brukerne.

Brukerens informasjonskrav går over avdelingene og avdelingene i organisasjonskartet. Denne tilnærmingen kan imidlertid brukes til komplette regnskapsførende enheter som forgrening, regionkontor osv. Således kan et regnskapsinformasjonssystem brukes av utvalgte grener. Når de er funnet å være feilfrie, kan de også brukes av andre grener.

(b) Installasjon av fasene:

Under denne tilnærmingen finner installasjonen sted i trinn. Disse stadiene er uavhengige komponenter i informasjonssystemet. Så, inntektslevetidssyklusen til et regnskapsinformasjonssystem kan først installeres og andre livssykluser kan følge etter hverandre. Denne tilnærmingen bidrar til å fokusere på en valgt del av systemet. Det hjelper med å forbedre akseptabiliteten av systemet blant brukerne fordi det gjør det mulig for brukeren å takle endringen lett.

(c) Parallell installasjon:

Parallellinstallasjonen betyr at både det gamle og det nye systemet kjøres samtidig i en viss periode til nytten av det nye systemet er bevist. Denne metoden er mest populær for regnskapssystem fordi dette er den sikreste av alle andre metoder. Den eneste vanskeligheten, her er kostnaden for parallellkjøring og tendensen til å forlenge parallellperioden som drives av de som motstår forandring.

Etter gjennomføring gjennomgang:

Hvert system må vurderes etter at gjennomføringen er fullført. En slik gjennomgang hjelper ikke bare med å identifisere svakhetene i systemet, men forbereder også en agenda for endring for fremtiden. Det er faktisk en læringsprosess. Systemrevisjon kan også utføres for å undersøke hvor vellykket systemet er, når det gjelder kostnad, leveringsplan, fullstendighet og kvalitet.