Utveckling av redovisningsinformationssystem: Företags-, databas- och gränssnittsmoduler

Utveckling av redovisningssystem: Företags-, databas- och gränssnittsmoduler!

Ett antal mjukvarupaket för redovisning finns tillgängliga som erbjuder en mängd olika funktioner. De kostar mycket mindre än vad kundanpassad bokföringsprogram skulle kosta. Dessa mjukvarupaket erbjuder dock bara strukturen för redovisningssystem. De minskar mest programmeringsansträngningen för redovisningssystem.

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

Utvecklingen av redovisningssystem är mycket mer än mjukvaran för bokföring av poster och rapportering av bildandet. Det handlar också om att upprätta förfaranden för att fånga data och distribution, samt analys av bokföringsinformation.

Utvecklingen av ett bokföringsinformationssystem förklaras med särskild hänvisning till kraven för ett medelstort till stort företag. Dessa steg skulle emellertid vara vanliga för de flesta andra informationssystem i ett företag.

1. Enterprise Module:

Företagsmodulen för informationssystemutveckling innefattar identifiering av grundläggande enheter och deras relationer, identifiering av grundläggande aktiviteter och omgruppering av dessa aktiviteter till delsystem. Därefter bestäms prioriteringarna på grundval av kostnads-nyttoanalys för företaget.

Identifierande enheter:

Ett stort antal enheter finns i ett företag och listan är lika varierad som affärsverksamheten är. Men i detta skede är det främsta problemet att identifiera de breda enheterna, var och en av dem innehåller en grupp elementära enheter. Kerner 5 pekar ut sex grundläggande enheter i ett företag.

De är kunder, produkter, säljare, personal, faciliteter och pengar. I ett bokföringsinformationssystem finns tre grundläggande enheter, nämligen transaktioner, konto och bearbetningsperiod. Interrelationerna mellan dessa enheter kan uttryckas med hjälp av ER-diagrammen som visat fig. 8.2.

Transaktionerna ska vara av olika slag, såsom kvitton, betalningar, försäljning, inköp, förvärv av tillgångar eller återbetalning av skulder etc. och var och en av dem kan kallas en lägre enhet. På samma sätt kan konton vara av olika slag, till exempel tillgångar, skulder, intäkter och kostnader.

Var och en av dessa huvuden kan ha enheter på lägre nivå, såsom anläggningstillgångar och omsättningstillgångar. Dessa enheter kan delas upp i ännu lägre nivåer, såsom mark och bygg, anläggningar och maskiner etc. I det här skedet behöver de breda enheterna identifieras. Detaljerna utarbetas vid utformningen av databaserna.

Enheterna identifieras i ljuset av och i syfte att definiera omfattningen och fokuseringen av informationssystemet. Om informationssystemet exempelvis betraktas som ett strategiskt informationssystem, ska de breda enheterna identifieras mot bakgrund av de strategiska drag som företaget planerar att ge sina aktiviteter med hjälp av informationssystemet.

Dessa drivkrafter kan vara kostnadsminimering, kundservice, produktdifferentiering och strategiska allianser. De grundläggande enheterna i ett sådant fall skulle vara kunder, kanaler, konkurrerande företag, produkter etc.

Aktivitetsanalys:

En annan viktig aspekt av företagsmodulen är identifiering av aktiviteter som är associerade med enheterna. Dessa aktiviteter identifieras i stor utsträckning i form av relationer i ER-diagrammen. Emellertid erhålls detaljer med hjälp av aktivitetsanalys. Den befintliga organisationsstrukturen är en viktig källa till information om de breda aktiviteter som bedrivs av företaget.

Men för att utveckla informationssystem som är oberoende av den nuvarande organisationsstrukturen är det väsentligt att basera aktivitetsanalysen på de grundläggande enheter som redan identifierats ovan. Nästa nivå av aktivitetsanalys innebär identifiering av livscykelaktiviteter. När "transaktioner" är en av de grundläggande enheterna i ett redovisningssystem finns det fyra breda livscykelaktiviteter, nämligen:

1. Inköp av livscykel

2. Livscykel för produktion

3. Livscykel för intäkter

4. Investeringar livscykel

På samma sätt har behandlingsperioden två grundläggande livscykelaktiviteter, nämligen:

en. Planera och kontrollera livscykel

b. Intern och extern rapporterings livscykel

Dessa livscykelaktiviteter är pågående aktiviteter och utförs kontinuerligt. Var och en av dessa aktiviteter kan vara sekventiellt relaterad till vissa andra aktiviteter. Den tredje aktivitetsanalysens nivå innebär att livscykelaktiviteter delas upp i funktioner.

Till exempel måste varje typ av transaktion initieras och erkännas; Då måste uppgifterna om transaktionen fångas, kodas för framtida klassificering, klassificeras, summeras och rapporteras. Dessa funktioner ska utföras olika för olika typer av transaktioner. Processen att definiera funktionerna fokuserar endast på de aktiviteter som skapar, uppdaterar eller använder information i företagets databas.

På denna nivå av aktivitetsanalys är aktiviteterna självständiga, tydligt definierade händelser eller knutpunkter i början och slut och en identifierbar person eller en grupp personer som är ansvariga för att utföra funktionen.

Dessa funktioner kan sedan delas in i delfunktioner tills funktionerna är specifika nog för att definiera modulen för datorprogram. Uppdelningen av livscykelaktiviteter i funktioner och delfunktioner hjälper till att identifiera funktioner som upprepas i mer än en livscykelaktivitet.

Till exempel kan funktionen för klassificering av infångade data utföras vid inköp och marknadsföring av livscykler. En sådan aktivitetsanalys hjälper till att identifiera möjligheter att förbättra den befintliga designen genom att:

1. eliminera de överflödiga funktionerna

2. kombinera de dubbla funktionerna

3. Förenkling och förbättring av bearbetningsmetoderna

Redundansen kan identifieras genom noggrann analys av verksamheten. De aktiviteter som sannolikt erbjuder möjligheter att förbättra behandlingen innefattar aktiviteter:

en. Det görs också på andra håll

b. Det kan kombineras med andra aktiviteter

c. Det kan också hanteras av någon annan person

d. Det kan utföras på något annat stadium av livscykeln som inte lägger till något värde för produkten eller tjänsten i informationssystemet.

Ett försiktighetssvar här är att inte alla uppsägningar är dåliga. Faktum är att viss redundans eller dubbelarbete får avsiktligt att krypa in i systemet. Detta kan göras för att förbättra systemets prestanda och tillförlitlighet.

Exempelvis kan en del av dupliceringen vara nödvändig för att säkerställa enkelhet av förfaranden och förbättra bearbetningshastigheten. Eliminering av redundans kan leda till att "lägga alla ägg i en korg" och kan därmed påverka tillförlitligheten. Risken för oväntade konsekvenser och låg avkastning från föreslagen ny metod eller procedur är andra faktorer som förtjänar uppmärksamhet innan förändringar föreslås i informationssystemet.

Gruppering av aktiviteter i delsystem:

Efter att aktiviteterna definierats med hjälp av ovan-nedåtgående tillvägagångssättet ovan, omgrupperas de för att bilda delsystem. Ett viktigt beslut som fattas vid detta skede gäller grunden för gruppering. Det kan inte existera ett enda objektivt kriterium för att bestämma vilket delsystem en verksamhet tillhör.

Den nuvarande organisationsstrukturen kan ge en av baserna för gruppering av aktiviteter. Men den nuvarande organisationsstrukturen kan genomgå förändringar och användbarheten av informationssystemet kan gå vilse.

För att gruppera verksamheten i delsystem tar vi hjälp från organisationsteori. En av de grundläggande egenskaperna hos en bra organisationsstruktur är att den syftar till att underlätta samordningen av verksamheten.

Ett effektivt kommunikationssystem är nödvändigt för en bättre samordning. Det är därför viktigt att gruppera aktiviteter på ett sådant sätt att kommunikationen underlättas inom gruppen och behovet av kommunikation mellan grupper minimeras.

I syfte att representera och dokumentera gruppering av aktiviteter i delsystem används strukturdiagram eller hierarkiska blockdiagram. Figur 8.3 visar strukturdiagram som visar inkomsterna i intäktscykeln.

Liknande strukturdiagram kan förberedas för andra grupper av aktiviteter och slutligen är dessa delsystem integrerade med varandra, vilket ger byggstenarna ett redovisningssystem.

Delsystemen som identifieras genom gruppering av aktiviteter är allvarliga konkurrenter för att vara enheter i organisationsstrukturen. Fördelen med grupperingsmetoden för gruppering av aktiviteter är att grupperingen bygger på funktioner och resurser och inte på geografiska områden.

En sådan gruppering på grundval av funktioner säkerställer homogenitet bland medlemmarna i gruppen människor associerade med var och en av delsystemen. Inverkan av informationssystem organisation på organisationsstruktur är inte ovanligt.

Ofta har införandet av informationssystem åtföljts av förändringar i organisationsstrukturerna på grund av att nya informationssystem förändrar hur människor arbetar i en organisation.

Det är därför allt viktigare att informationssystemdesigners arbetar i aktiv förening med organisationsutvecklingsfolket medan gruppering av aktiviteter i kluster och delsystem görs. Detta garanterar inte bara att den nya strukturen är mer pragmatisk men också mer acceptabel för människor. I sådana fall är övergången från gammalt system till nytt en mindre smärtsamt och billigare.

Ställa in prioriteringar:

När delsystemen har identifierats och integrerats som helhet måste prioriteringarna bestämmas bland de olika delsystemen och funktionerna i varje system. Informationssystemet skulle kräva åtagande av ekonomiska resurser.

Dessutom kan det vara implicita kostnader för det nya systemet när det gäller nödvändiga förändringar i verksamhetsprocessen. Det är därför viktigt att väga för och nackdelar med varje delsystem och delsystem innan de utformas och implementeras.

Varje delsystem utvärderas på grundval av väldefinierade utvärderingskriterier definierade med avseende på de kritiska framgångsfaktorerna (CSF). Dessa faktorer har redan identifierats i avsnitt 8.2.

Den andra metoden är brainstorming där de relevanta personerna i organisationen samlas för att identifiera de faktorer som förtjänar övervägande vid bestämning av prioriteringar. Fritt flöde av idéer uppmuntras i första etappen.

Den underliggande principen är att ingen aning är dum eller irrelevant i detta skede. Under det andra steget börjar processen för eliminering och efter diskussionerna slutföras.

När listan över faktorer har slutförts tilldelas relativa vikter och ett kriteries funktion definieras för att utvärdera varje komponent i det föreslagna bokföringsinformationssystemet.

2. Databasmodul:

Redovisningsinformationssystem bearbetar stor mängd data. Hantering av data är således en av de viktigaste övervägandena i dess utvecklingsprocess. Det finns två grundläggande metoder för datadesign, nämligen:

en. Det traditionella, applikationsorienterade tillvägagångssättet, och

b. Databasmetoden.

Traditionell inställning:

Det traditionella tillvägagångssättet för datadesign är applikationsorienterat i den meningen att för varje applikation genereras en separat uppsättning datafiler enligt sina krav. Med andra ord är datafilerna dedikerade till en given applikation och är på ett sätt som "ägs" av ansökan.

Till exempel måste en kundfordringsansökan ha kundmasterdatafilen, en transaktionsfil och ett kvitto från kundens transaktionsfil. Dessa datafiler används endast för kundfordran.

Detta tillvägagångssätt är lämpligt för mindre redovisningssystem på grund av dess enkelhet. Men eftersom informationssystemet växer med avseende på datamängden och analysens komplexitet, ger det också upphov till vissa problem.

Det grundläggande problemet med det traditionella tillvägagångssättet är att applikationsprogrammen är beroende av datafilerna som de använder och manipulerar. Som en följd av detta måste ändringar i datafilen (i form av tillägg eller radering av dataobjekt) nödvändiga ändringar i alla program som använder datafilen.

Detta databeroende motverkar ändringar i datafiler som leder till inflexibilitet. I avsaknad av något verktyg för att utföra rutinmässiga datahanteringsaktiviteter på data, ska sådana anläggningar ingå i programmen som använder datafilen. Detta komplicerar programmet. Ett annat problem gäller att möta ad hoc-frågan.

För oväntad typ av fråga måste specialprogram skrivas. Sådana speciella program tar tid att utvecklas och har bara en gång användning och är därmed dyra. Det finns mycket dubbelarbete vid inspelning av dataposter.

Exempelvis kan dataposter som kundnamn, fakturanummer, pris etc. inkluderas i transaktionsfiler för ansökan om beställning av orderorder samt ansökan om kundfordringar. Detta orsakar redundans i data.

Data redundans resulterar i ineffektiv användning av lagringsmedia. Det påverkar också kvaliteten på data eftersom uppdatering av ett visst dataobjekt kanske inte äger rum i alla filer där den dataobjekten är lagrad.

Databasstrategi:

Det moderna tillvägagångssättet för datadesign är databasinriktning. Detta tillvägagångssätt bygger på antagandena att flera applikationer kräver datasatser som har mycket gemensamt. Det är därför bättre att ha ett gemensamt förvar av data som uppfyller datakraven för varje applikation i informationssystemet.

Det gemensamma förvaret heter databasen och hanteras av ett hanteringssystem som heter Database Management System (DBMS). DBMS är programvara som är speciellt utformad för att hantera data i databaser enligt önskemål från applikationsprogram, samt från dem som kommer direkt från användarna. Den konceptuella utformningen av databasmiljön visas med hjälp av figur 8.5.

Databasmetoden tar hand om problemen med applikationsmetoden. Det garanterar datainformitet eftersom DBMS tar hand om flödet av data från databasen till applikationsprogram. Användarprogrammet behöver inte störa om platsen för data i databasen. En datalogik bibehålls och data kan ringas med de ord som anges i datalogin.

Databasstrategin minskar också programmets programmets storlek och komplexitet, eftersom rutinmässig typ av databehandling som sortering görs av DBMS. DBMS används också för att betjäna behoven hos ad hoc-fråga. DBMS använder Structured Query Language (SQL) som språk för kommunikation mellan användaren och databasen.

Språket är väldigt enkelt och ganska nära engelska. Detta säkerställer att användaren kan få information från databasen vid behov. Mängden utbildning som krävs av chefer för att göra ad hoc-frågor är minimal och få timmars utbildning kan ge grundläggande färdigheter för att använda språket. Kanske är den viktigaste fördelen med databasstrategin minskningen av redundansen i databaser.

Det finns många modeller som brukar användas vid databasdesign. Det moderna tillvägagångssättet är dock att följa ER-modellen för databasdesign. Detta tillvägagångssätt är top-down-tillvägagångssätt och ER-diagrammen som drogs tidigare i Enterprise Module blir utgångspunkten.

För varje enhet och relation identifieras och dokumenteras attribut i Extended ER-diagrammen (EER-diagram). I ett bokföringsinformationssystem kan EER dras för varje enhet (transaktion och konton) och förhållandet (effekt) för transaktionskontona visas i ER-diagrammet. Till exempel kan attribut för en försäljningstransaktion specificeras och dokumenteras som visas i figur 8.6.

Dessa attribut blir dataobjekten (fält) i en post i datafilen för varje enhet (i detta fall försäljnings transaktionsfil). På liknande sätt, för andra enheter och relationer, utförs sådana utvidgade ER (EER) diagram.

När dessa attribut har identifierats är det troligt att vissa av attributen ska vara vanliga i olika EER-diagram. För att undvika dubbelarbete av sådana gemensamma attribut, genomförs normalisering av data.

3. Gränssnittsmodul:

En gränssnittsmodul definierar källorna till dataposter och formatet på inmatnings- / utmatnings- och dialogskärmar som ska användas i systemet. Det definierar också rapportformat och skärmarna för navigering från en del av informationssystemen till den andra.

Med andra ord handlar modulen om att definiera gränssnittet mellan användaren och maskinen. Betydelsen av gränssnittsmodulen har ökat på grund av ökad kommunikation mellan användar- och informationssystem.

Både datainmatningen och datasökningen har blivit interaktiva. I många fall elimineras inmatningsformulär från processen och datainmatningen sker direkt. Förändringskraven för dataförfrågan gör många rapportformulär för styva. Interaktiva rapportskärmar ger större flexibilitet i datasök och tillåter användardefinierade rapportformat för visning och utskrift.

Inmatningsskärmar:

Inmatningsskärmarna definieras i ljuset av den naturliga processen i affärsverksamheten. Därför beror de främst på de former som används för att registrera data manuellt när de först mottas av företaget. Dessa formulär, i ett bokföringsinformationssystem, kan innefatta faktura, inköpsorder, försäljningsorder, utgiftsbevis etc.

I gränssnittsmodulen ses således även formulär; omkonstruerade och inmatningsskärmar definieras i form av formulär som används av företaget. I ett redovisningssystem måste man vara mer försiktig när det gäller skärmdesign.

En mindre förbättring av inmatningsskärmen som sparar datainmatning kan leda till betydande besparingar eftersom antalet gånger datainmatningsskärmen används är mycket stor. Följande faktorer kan komma ihåg när du utformar inmatningsskärmen:

(a) Matchande med formulär:

Inmatningsskärmsformatet måste matcha inmatningsformulär. Ibland betalar det sig att anta samma format som används av inmatningsformuläret. I så stor utsträckning kan även färgen på bakgrunden på skärmen matchas med inmatningsformulärets färg.

(b) Interaktiv:

Inmatningsskärmen ska vara interaktiv. Det bör påpeka fel vid datainmatning vid inmatningstillfället och tillåta korrigeringar. Varje dataobjekt måste ha något datavalideringsförhållande och eventuell kränkning av sådant datavalideringsförhållande bör automatiskt markeras vid datainmatningstillfället.

Till exempel måste en datainmatningsskärm för fakturans inmatning påpeka ett fel vid inmatning av datum om datumet är ogiltigt. Datumet kan vara ogiltigt eftersom det ligger utanför redovisningsperioden eller månaden som anges är större än tolv.

(c) Konsistens:

Inmatningsskärmarna bör vara konsekventa när det gäller att definiera termer och plats för vissa vanliga typer av dataposter. Det hjälper till att minska träningstiden, eftersom det förbättrar kännedom; till exempel kan datum för transaktionen alltid placeras i det högra hörnet av varje transaktionsdokument.

(d) Enkelhet:

En av de grundläggande egenskaperna hos en bra inmatningsskärm är enkelheten. För många markerade sektioner, blinkande av värden eller attribut eller att lägga för många lådor och understrykning, lägger bara till komplexitet och förvirring. Ibland används pip för att peka på datainmatningsfel. Det borde finnas en god användning av sådana pip och i allmänhet bör dessa undvikas.

(e) Flexibilitet:

Inmatningsskärmen bör vara möjlig för ändringar. Det ska tillåta användare att göra ändringar när det gäller tillägg eller radering och flyttning av dataobjekt. Förfarandet för modifiering bör vara enkelt. Dessa dagar erbjuder skärmgeneratorer från olika mjukvaruproducenter funktioner som dra och fixa / släppa någon dataobjekt från skärmen med hjälp av vanlig pekdon som mus.

(f) Skräddarsydda:

Skärmarna måste vara skräddarsydda för varje kategori av användare. Detta skulle minska orimligt långa start- och ingångsförfaranden.

Rapportera skärmar:

Rapporterna kan beredas för vidare analys av något annat datorprogram eller av användaren själv. Data som riktas för bearbetning av dataprogram, såsom kalkylblad, statistiska paket, textbehandlare, förvaras i datafiler.

Det är bättre att sätta dem i standarddatformat så att de enkelt kan nås. Rapporterna som är avsedda för användare hålls normalt i form av text, tabeller och diagram. Arbetet bör göras för att se till att rapporterna utarbetas och meddelas i rätt tid, exakt, tydligt och till låg kostnad.

Dialogskärmar:

Dialogrutorna är de som används för att identifiera och utföra uppgifterna i informationssystemet. De definierar vad som kan göras med hjälp av informationssystemet, hur man navigerar från en uppgift / procedur till en annan och hur man utför olika uppgifter som informationssystemet tillåter.

Dessa skärmar ska vara enkla och entydiga. Enkelheten kan introduceras genom att tillhandahålla grafiskt användargränssnitt (GUI) och har begränsat antal menyalternativ på en skärm. Förfarandet för navigering från en meny till den andra ska vara enkelt, i rätt ordning och lätt att följa. Det bör också påpeka misstag vid utövandet av alternativ och vara snabb för att korrigera förfarandet.

CASE-verktyg för skärmdesign:

En mängd olika CASE-verktyg är tillgängliga för utformning av blanketter, skärmar och rapporter. Dessa verktyg har fördelen att erbjuda designmiljö som är flexibel och enkel att förstå även för en ny användare.

Eftersom dessa verktyg har skärmprototypanläggningar, är det möjligt att ha större medverkan av användarna i processen med skärmdesign. Naturligtvis tillåter sådana verktyg snabba förändringar och förbättrar produktiviteten hos programmerare genom att generera koder för slutlig implementering. Detta resulterar i minskad utvecklingstid.

När blanketterna, inmatnings- / utmatningsskärmarna och dialogrutorna är klara, bör de testas och ändras i enlighet med detta. Blanketterna och skärmarna som är utformade med hjälp av CASE-verktygen kan enkelt ändras. Därför måste ansträngningarna göras för att förbättra acceptansen av systemet genom korrekt provning och modifiering av former och skärmar.

4. Applikationsmodul:

Den här modulen utökar delsystemen som redan identifierats i företagsmodulen. För varje delsystem som identifieras i strukturdiagrammet definieras detaljerade bearbetningsförfaranden i denna modul.

Med andra ord är applikationsmodulen huvudsakligen inriktad på de processer som är inblandade i att omvandla ingångsdata till värden som ska utgöra en del av rapporterna som definieras i gränssnittsmodulen. Det kan noteras att endast dessa processer ska definieras som

(a) Ändra värdena i databaserna, eller

(b) Det är inte delar av databasen men krävs i de rapporter som definieras i gränssnittsmodulen.

De värden som redan finns i databasen kan nås med hjälp av DBMS-frågespråk enligt kravet från användare utan att program utvecklas för detta ändamål. Sålunda reduceras uppgiften med applikationsmodulen av det arbete som redan utförts i databasdesign och skärmdesign.

Dataflödesdiagram:

Chefens roll i den här modulen identifierar i grunden grundprocessen. De detaljerade algoritmerna definieras generellt och dokumenteras av informationssystemets professionella, med aktiv hjälp från chefen.

Verktyget som används för att uttrycka de processer som ska utföras för att omvandla ingångsdata till utdata är Data Flow Diagram (DFD). Det beskriver flödet av data. Det definierar vad som måste göras och ignorerar hur det ska göras eller hur det görs tidigare. Detta tillvägagångssätt tillåter förändringar i systemet och svagheterna i det befintliga systemet kan tas bort enligt detta tillvägagångssätt.

DFD-symboler:

Det finns fyra grundläggande symboler som används i DFD. Dom är:

(i) Avslutare:

Terminator är en extern källa till dataflöde eller extern synkronisering av data. Det är en extern enhet eller ett objekt som kund, leverantör, aktieägare etc. Eftersom terminatorerna är externa enheter, är kommunikationen mellan terminatorerna exkluderad från systemet. Terminatorn symboliseras av en rektangel (vanligtvis skuggad) och etiketten placeras i rektangeln.

(ii) Dataflöde:

Dataflödet har en rad dataposter angående händelsen som initieras av terminatorn. Den symboliseras med en pil i DFD och flödesriktningen indikeras av pilens riktning. Pilarna är generellt märkta om de inte riktas till eller från datafiler. Som tidigare påpekats är dataflöden mellan två terminatorer inte inkluderade i DFD och således kan data inte flöda direkt mellan två terminatorer.

(iii) Process:

Processen omvandlar inkommande data för omdirigering till datalager eller terminator. Den symboliseras av en rektangel med rundade hörn eller en cirkel. Det är självklart märkt med ett verb.

(iv) datalager

Filer är datalager i informationssystem och är representerade i DFD i form av öppna rektanglar. Generellt motsvarar de tabeller i databaser. En partiell vy av dataflödesdiagrammet för försäljningsorderbearbetning presenteras i figur 8.7.

Det kan noteras att vissa tilläggssymboler och mindre variationer i symboler som representerar olika komponenter i DFD också används. Ovanstående symboler är de som oftast används och är enligt den grafiska konventionen som föreslås av Gane och Sarson.

Många en tid, en chef tycker att teckning av DFD är mycket svår och frustrerande upplevelse. Varje gång man drar en DFD, finner man att man har ignorerat en eller annan aspekt av dataflödet. Lyckligtvis har CASE-verktygen möjligheter att skapa och modifiera DFD-enheter. Nybörjare rekommenderas dock att följa följande steg för att lösa detta problem:

(a) Identifiera alla ingångsdata flöden och utgångsdata flöden separat tillsammans med terminatorer, sätta in dataflöden på vänster sida och utdataflöde till höger.

(b) Märk terminatorerna med dataflytnamn eller adjektivnamn.

(c) Identifiera processer framåt från ingångsdataflöden och bakåt från utdataflöden tills de möts i mitten.

(d) Märk processerna med hjälp av verbnamn.

En chef måste vara beredd att redraw DFD eftersom många gånger blir dataflödena tydliga för hanteraren först efter att ha ritat DFD. Användarengagemang i detta skede är väldigt användbar, inte bara för att minska förvaltarens insats utan också för att förbättra DFD.

Test av DFD:

Det föreslås att DFD måste testas noggrant innan den slutförs. Nedan följer några vanliga fel i DFD-designen:

en. Termineringsetiketten kan vara namnet på en person eller ett företag istället för klassen. Till exempel kan en terminator märkas som M / s. BR Ltd. istället för ensamleverantör. Ett annat misstag kan vara att bäraren sätts som terminator istället för den externa enheten som är direkt förknippad med dataflödet.

b. Data kan strömma direkt från en terminator till en annan terminator.

c. Inget dataflöde kan anges för eller från en process.

d. Dataflöde indikeras från terminatorn till en datalagring (fil) eller från en fil till terminatorn, eller mellan två filer utan behandling.

e. Processerna är märkta som föremål, till exempel faktura eller substantiv som bokningskonsulent.

Efter att DFD-ritningarna har ritats för varje delsystem, kan framtida behandlingsdetaljer utkalkas och beskrivas i strukturerad engelska (psedo-koder). Dessa psedo-koder används senare för att koda applikationerna. Chefens roll i denna process är endast begränsad till att hjälpa informationssystemets professionella att identifiera och förstå de algoritmer som är inblandade i behandlingen.

5. Implementeringsmodul:

Den här modulen handlar främst om testning av systemet, utbildning av användare och installation av systemet.

Testa systemet:

Testningen av olika moduler görs på olika stadier av utvecklingsprocessen. Den gyllene regeln som ska hållas i åtanke vid testningen är att testningen ska göras för att identifiera de sätt på vilka systemet sannolikt kommer att misslyckas. Det borde inte vara med målet att bevisa att systemet kommer att fungera enligt designspecifikationen. Systemtest är processen att söka svar på två grundläggande frågor:

1. Huruvida informationssystemet betjänar företagets informationsbehov? Processen som söker svar på denna fråga betecknas av informationssystemfackmän som systemvalideringsprocess.

2. Fungerar informationssystemet korrekt? Verifikationsprocessen söker svar på denna fråga.

Eftersom naturen och graden av felaktighet är olika vid olika systemutvecklingsstadier, administreras olika tester på olika moduler och i systemet som helhet.

Enhetstest:

Testen som används på modulnivå kan kallas enhetstester. Dessa tester utförs för att upptäcka fel i gränssnitt, databaser, aritmetiska operationer och kontrolllogik. De utförs genom att köra en modul i informationssystemet på testdata speciellt konstruerade för att testa om systemet:

en. Accepterar felaktig typ av data (t.ex. accepterar numeriskt värde för namn);

b. Accepterar ur giltigt intervalldata (t.ex. accepterar datum med månad större än 12);

c. Orsakar felaktig hoppning från ett förfarande till ett annat förfarande.

Systemtest:

Eftersom enhetstesterna är isolerade är det viktigt att integrationsprovningarna genomförs för att kontrollera om dessa enheter fungerar korrekt som en grupp eller ej. På grund av skillnader i naturen av fel ska olika teststrategier följas för att kontrollera validiteten och verifiera systemet. Fertucks suggests tre strategier för att testa informationssystemet:

(a) Rensa boxningstestning:

I denna strategi är tester utformade för att fastställa huruvida förfarandena som följs för bearbetning matchar kraven i ansökan. Detta kan uppnås med hjälp av granskning av medarbetare som inte har direkt koppling till utvecklingsfasen.

Alternativt kan strukturerad genomgångsmetod användas. I denna metod granskar en grupp personer rutinerna, först tittar på felaktiga delar och identifierar korrigeringar som måste göras. Därefter bedömer gruppmedlemmarna den produktion som systemet kommer att erbjuda för en given typ av ingång och testa om systemets utmatning är korrekt eller inte.

(b) Svart boxningstestning:

I denna strategi testas systemet för ogiltiga data eller data som kan orsaka fel i systemets funktion. Utmatningen kontrolleras för att fastställa om något fel har uppstått. Till exempel kan data innehålla negativt värde för beställt kvantitet eller ett fraktionsvärde för en variabel som bara kan ta helvärdet.

(c) Tickningstestning:

Denna strategi förutsätter att det aldrig går att leverera ett helt felfritt informationssystem. Således, efter alla test och modifikationer, är det nödvändigt att uppskatta antalet fel som kvarstår i systemet. För att uppskatta detta nummer kan några fel introduceras medvetet i systemet. Sedan utförs testen igen för att upptäcka fel.

Andelen infekterade fel som detekterats tas som en uppskattning av andelen verkliga fel som upptäckts under de tidigare testen. Om 90% av de införda felsökningarna upptäcktes under testning av kryssrutan medan totalt 450 fel upptäcktes ursprungligen under testrutan med clear box och black box, betyder det att 50 verkliga fel fortsätter att förbli oupptäckta i systemet.

Installation:

Installation är en process för att ersätta det gamla systemet med ett nytt system. Bredvid finns det fyra sätt att installera. Den kalla installationen görs när det gamla systemet avbryts och ersätts av ett nytt system.

En sådan installation har fördelen av snabbare psykologisk anpassning med det faktum att det nya systemet ska användas. Ett sådant tillvägagångssätt är dock inte lämpligt om gamla data från det tidigare systemet är värdefulla eller det nya systemet har några problem. För att installera redovisningsinformationssystem har denna inställning inte visat sig vara acceptabel. De alternativa tillvägagångssätten innefattar:

a) Pilotinstallation:

Ett system kan installeras för användning endast av en välj representativ användargrupp som tester systemet genom att använda den. Andra användare fortsätter att använda gammalt system. När problemen i systemet tas om hand, börjar andra användare också använda systemet. Detta tillvägagångssätt är inte särskilt populärt för redovisningssystem, eftersom hela bokföringsdatabasen måste uppdateras innan den kan användas av användarna.

Användarens informationskrav går över gränserna för avdelningen och divisionerna i organisationsschemat. Detta tillvägagångssätt kan emellertid användas för fullständiga redovisningsenheter, såsom filial, regionkontor osv. Således kan ett bokföringsinformationssystem användas av utvalda filialer. När de befunnits vara felfria kan de också användas av andra grenar.

(b) Inbyggnadsfas:

Under detta tillvägagångssätt sker installationen i steg. Dessa steg är oberoende komponenter i informationssystemet. Således kan intäktscykeln för ett redovisningssystem installeras först och andra livscykler kan följa efter varandra. Detta tillvägagångssätt hjälper till att fokusera på en vald del av systemet. Det hjälper till att förbättra acceptansen av systemet bland användare eftersom det gör att användaren enkelt kan klara av förändringar.

(c) Parallell installation:

Parallellinstallationen innebär att både det gamla och det nya systemet körs samtidigt under en viss period tills nytta av det nya systemet bevisas. Denna metod är mest populär för redovisningssystem eftersom detta är det säkraste av alla andra metoder. Den enda svårigheten, här är kostnaden för parallellkörning och tendensen att förlänga parallellperioden som drivs av dem som motstår förändringar.

Efter genomförande granskning:

Varje system måste ses över när genomförandet är klart. En sådan granskning hjälper inte bara till att identifiera systemets svagheter utan också förbereder en agenda för modifiering för framtiden. Det är faktiskt en inlärningsprocess. Systemrevision kan också utföras för att undersöka hur framgångsrikt systemet är, vad gäller kostnad, leveransschema, fullständighet och kvalitet.