Ontwikkeling van boekhoudingsinformatiesysteem: Enterprise-, database- en interfacemodules

Ontwikkeling van Accounting Information System: Enterprise, Database en Interface Modules!

Er zijn een aantal boekhoudsoftwarepakketten beschikbaar die verschillende functies bieden. Ze kosten veel minder dan wat op maat gemaakte boekhoudsoftware zou kosten. Deze softwarepakketten bieden echter alleen de structuur voor boekhoudinformatiesystemen. Hoogstens verminderen ze de programmeerinspanning voor boekhoudinformatiesystemen.

Afbeelding met dank aan: bestsmallbizhelp.com/wp-content/uploads/2011/07/1018910261.jpg

De ontwikkeling van boekhoudkundige informatiesystemen is veel meer dan de software voor het plaatsen van grootboek en rapportage. Het omvat ook het vaststellen van procedures voor het vastleggen van gegevens en distributie, evenals het analyseren van boekhoudkundige informatie.

De ontwikkeling van een boekhoudkundig informatiesysteem wordt toegelicht met speciale aandacht voor de vereisten van een middelgrote tot grote onderneming. Deze stappen zijn echter hetzelfde voor de meeste andere informatiesystemen in een zakelijke onderneming.

1. Enterprise-module:

De enterprise-module voor de ontwikkeling van informatiesystemen omvat de identificatie van basisentiteiten en hun onderlinge relaties, identificatie van basisactiviteiten en hergroepering van deze activiteiten in subsystemen. Vervolgens worden de prioriteiten bepaald op basis van de kosten-batenanalyse voor de onderneming.

Identiteiten identificeren:

Een groot aantal entiteiten bestaat in een zakelijke onderneming en de lijst is net zo gevarieerd als de bedrijfsactiviteiten. In dit stadium gaat het er echter vooral om de brede entiteiten te identificeren, die elk een groep elementaire entiteiten bevatten. Kerner ⁵ wijst op zes basisentiteiten in een zakelijke onderneming.

Het zijn klanten, producten, verkopers, personeel, faciliteiten en geld. In een boekhoudinformatiesysteem zijn er drie basisentiteiten, namelijk transacties, rekening en verwerkingsperiode. De onderlinge relaties tussen deze entiteiten kunnen worden uitgedrukt met behulp van de ER-diagrammen zoals weergegeven in Afb. 8.2.

De transacties zullen van verschillende aard zijn, zoals ontvangsten, betalingen, verkopen, aankopen, verwerving van activa of terugbetaling van verplichtingen, enz. En elk van hen kan een lagere entiteit worden genoemd. Evenzo kunnen accounts van verschillende aard zijn, zoals activa, verplichtingen, inkomsten en uitgaven.

Elk van deze hoofden kan entiteiten op een lager niveau hebben, zoals vaste activa en vlottende activa. Deze entiteiten kunnen verder worden gesplitst in nog lagere entiteiten zoals grond en gebouwen, installaties en machines, enz. In dit stadium moeten echter de brede entiteiten worden geïdentificeerd. De details zijn uitgewerkt op het moment van het ontwerpen van de databases.

De entiteiten worden geïdentificeerd in het licht van en met het oog op het definiëren van de reikwijdte en focus van het informatiesysteem. Als het informatiesysteem bijvoorbeeld als een strategisch informatiesysteem wordt beschouwd, moeten de brede entiteiten worden geïdentificeerd in het licht van de strategische impulsen die de onderneming met behulp van het informatiesysteem aan haar activiteiten wil geven.

Deze impulsen kunnen kostenminimalisatie, klantenservice, productdifferentiatie en strategische allianties zijn. De basisentiteiten in een dergelijk geval zijn klanten, kanalen, concurrerende ondernemingen, producten, enz.

Activiteitsanalyse:

Een ander belangrijk aspect van de enterprise-module is de identificatie van activiteiten die aan de entiteiten zijn gekoppeld. Deze activiteiten worden globaal geïdentificeerd in de vorm van relaties in de ER-diagrammen. Details worden echter verkregen met behulp van activiteitsanalyse. De bestaande organisatiestructuur is een belangrijke bron van informatie over de brede activiteiten van de onderneming.

Maar om informatiesystemen te ontwikkelen die onafhankelijk zijn van de huidige organisatiestructuur, is het essentieel om de activiteitsanalyse te baseren op de basisentiteiten die hierboven al zijn geïdentificeerd. Het volgende niveau van activiteitenanalyse omvat de identificatie van de levenscyclusactiviteiten. In het geval dat 'transacties' een van de basisentiteiten in een boekhoudinformatiesysteem is, zijn er vier brede levenscyclusactiviteiten, namelijk:

1. Levenscyclus kopen

2. Productie levenscyclus

3. Levenscyclus van de inkomsten

4. Levenscyclus van een investering

Evenzo heeft de verwerkingsperiode twee basisactiviteiten in de levenscyclus, namelijk:

een. Planning en besturing van de levenscyclus

b. Interne en externe rapportage levenscyclus

Deze levenscyclusactiviteiten zijn lopende activiteiten en worden continu uitgevoerd. Elk van deze activiteiten kan sequentieel gerelateerd zijn aan sommige andere activiteiten. Het derde niveau van activiteitsanalyse omvat het splitsen van de levenscyclusactiviteiten in functies.

Elk type transactie moet bijvoorbeeld worden geïnitieerd en herkend; dan moeten de gegevens met betrekking tot de transactie worden vastgelegd, gecodeerd voor toekomstige classificatie, geclassificeerd, samengevat en gerapporteerd. Deze functies moeten voor verschillende soorten transacties anders worden uitgevoerd. Het proces van het definiëren van de functies is alleen gericht op die activiteiten die informatie in de database van de onderneming maken, bijwerken of gebruiken.

Op dit niveau van activiteitsanalyse zijn de activiteiten op zichzelf staand, hebben duidelijk gedefinieerde begin- en eindgebeurtenissen of knooppunten en een identificeerbare persoon of een groep personen die verantwoordelijk zijn voor het uitvoeren van de functie.

Deze functies kunnen vervolgens worden onderverdeeld in subfuncties totdat de functies specifiek genoeg zijn om de module voor computerprogramma's te definiëren. Het splitsen van levenscyclusactiviteiten in functies en subfuncties helpt bij de identificatie van functies die in meer dan één levenscyclusactiviteit worden herhaald.

De functie van classificatie van vastgelegde gegevens kan bijvoorbeeld worden uitgevoerd in levenscycli van aankoop en marketing. Een dergelijke activiteitsanalyse helpt bij het identificeren van mogelijkheden om het bestaande ontwerp te verbeteren door:

1. het elimineren van de overtollige functies

2. combineren van de gedupliceerde functies

3. vereenvoudiging en verbetering van de verwerkingsmethoden

De overtolligheid kan worden geïdentificeerd door een zorgvuldige analyse van de activiteiten. De activiteiten die waarschijnlijk kansen bieden om de verwerking te verbeteren, omvatten activiteiten:

een. Dat gebeurt ook elders

b. Dat kan worden gecombineerd met andere activiteiten

c. Dat kan ook door een andere persoon worden afgehandeld

d. Dat kan in een andere fase van de levenscyclus worden uitgevoerd die geen waarde toevoegt aan het product of de dienst van het informatiesysteem.

Een waarschuwing is hier dat niet alle ontslagen slecht zijn. Het is zelfs mogelijk dat een deel van de overtolligheid of duplicatie opzettelijk in het systeem kan kruipen. Dit kan gedaan worden om de prestaties en betrouwbaarheid van het systeem te verbeteren.

Een deel van de duplicatie kan bijvoorbeeld nodig zijn om de eenvoud van procedures te waarborgen en de verwerkingssnelheid te verbeteren. Het elimineren van overtolligheid kan ertoe leiden dat 'alle eieren in één mand worden gestopt' en dus de betrouwbaarheid kan beïnvloeden. Het risico van onverwachte implicaties en lage opbrengsten van voorgestelde nieuwe methode of procedure zijn andere factoren die aandacht verdienen voordat wijzigingen in het informatiesysteem worden voorgesteld.

Activiteiten groeperen in subsystemen:

Nadat de activiteiten zijn gedefinieerd volgens de hierboven beschreven methode van bovenaf, worden ze gegroepeerd om subsystemen te vormen. Een belangrijke beslissing die in deze fase moet worden genomen, heeft betrekking op de basis van de groepering. Er bestaat misschien niet één objectief criterium om te beslissen tot welk subsysteem een ​​activiteit behoort.

De huidige organisatiestructuur kan een van de basis vormen voor het groeperen van activiteiten. Maar de huidige organisatiestructuur kan veranderingen ondergaan en het nut van het informatiesysteem kan verloren gaan.

Om de activiteiten in een subsysteem te groeperen, nemen we hulp van de organisatietheorie. Een van de essentiële kenmerken van elke goede organisatiestructuur is dat deze gericht is op het vergemakkelijken van de coördinatie van activiteiten.

Een effectief communicatiesysteem is essentieel voor een betere coördinatie. Het is daarom essentieel om activiteiten zodanig te groeperen dat de communicatie binnen de groep wordt gefaciliteerd en de behoefte aan communicatie tussen groepen wordt geminimaliseerd.

Voor het weergeven en documenteren van de groepering van activiteiten in subsystemen worden structuurdiagrammen of hiërarchische blokdiagrammen gebruikt. Figuur 8.3 geeft een structuurdiagram met de componenten van de inkomstencyclus.

Vergelijkbare structuurgrafieken kunnen worden voorbereid voor andere clusters van activiteiten en ten slotte zijn deze subsystemen met elkaar geïntegreerd en vormen de bouwstenen voor een boekhoudinformatiesysteem.

De subsystemen die zo worden geïdentificeerd door clustering van activiteiten zijn serieuze kanshebbers om entiteiten in de organisatiestructuur te zijn. Het voordeel van de clusteringmethode voor het groeperen van activiteiten is dat de groepering gebaseerd is op functies en bronnen en niet op geografische regio's.

Een dergelijke clustering op basis van functies zorgt voor homogeniteit tussen de leden van de groep mensen die bij elk van de subsystemen hoort. De impact van de organisatie van het informatiesysteem op de organisatiestructuur is niet ongewoon.

Vaak is de introductie van informatiesystemen gepaard gegaan met veranderingen in de organisatiestructuren vanwege het feit dat nieuwe informatiesystemen de manier waarop mensen in een organisatie werken veranderen.

Het is daarom des te belangrijker dat ontwerpers van informatiesystemen actief samenwerken met de mensen die de organisatie ontwikkelen, terwijl het groeperen van activiteiten in clusters en subsystemen wordt uitgevoerd. Dit zorgt er niet alleen voor dat de nieuwe structuur pragmatischer is, maar ook meer acceptabel voor mensen. In dergelijke gevallen is de overgang van oud naar nieuw systeem minder pijnlijk en minder duur.

Prioriteiten stellen:

Zodra de subsystemen als geheel zijn geïdentificeerd en geïntegreerd, moeten de prioriteiten worden bepaald tussen de verschillende subsystemen en functies in elk systeem. Het informatiesysteem vereist toewijzing van financiële middelen.

Daarnaast kunnen er impliciete kosten van het nieuwe systeem zijn in termen van noodzakelijke wijzigingen in het operationele proces. Het is daarom van essentieel belang om de voor- en nadelen van elk subsysteem en subsubsysteem af te wegen voordat ze worden ontworpen en geïmplementeerd.

Elk subsysteem wordt geëvalueerd op basis van duidelijk gedefinieerde evaluatiecriteria die zijn gedefinieerd in termen van de kritieke succesfactoren (CSF). Deze factoren zijn al in paragraaf 8.2 geïdentificeerd.

De andere methode is, brainstormen, waarbij de relevante mensen in de organisatie bij elkaar komen om de factoren te identificeren die aandacht verdienen bij het bepalen van prioriteiten. Gratis stroom van ideeën wordt aangemoedigd in de eerste fase.

Het onderliggende principe, hier, is dat geen idee in dit stadium dom of niet relevant is. Tijdens de tweede fase begint het eliminatieproces en na discussies zijn de suggesties afgerond.

Nadat de lijst met factoren is voltooid, worden relatieve gewichten toegewezen en wordt de functie van een criterium gedefinieerd om elk onderdeel van het voorgestelde boekhoudinformatiesysteem te evalueren.

2. Databasemodule:

Boekhoudkundige informatiesysteem verwerkt grote hoeveelheid gegevens. Het beheren van de gegevens is dus een van de belangrijkste overwegingen in het ontwikkelingsproces. Er zijn twee basisbenaderingen voor gegevensontwerp, namelijk:

een. De traditionele, toepassingsgerichte aanpak, en

b. De database-aanpak.

Traditionele aanpak:

De traditionele benadering van gegevensontwerp is toepassingsgericht in die zin dat voor elke toepassing een afzonderlijke reeks gegevensbestanden wordt gegenereerd volgens de vereisten. Met andere woorden, de databestanden zijn bestemd voor een bepaalde applicatie en zijn op een bepaalde manier 'eigendom' van de applicatie.

Een aanvraag voor een rekeningvordering heeft bijvoorbeeld het klantstamgegevensbestand, een verkooptransactiebestand en een ontvangstbewijs van het transactiebestand van de klant. Deze databestanden worden alleen gebruikt voor de debiteurenapp.

Deze benadering is vanwege de eenvoud ervan geschikt voor kleinere boekhoudinformatiesystemen. Naarmate het informatiesysteem groeit in termen van gegevensvolume en complexiteit van de analyse, leidt dit echter ook tot bepaalde problemen.

Het fundamentele probleem met de traditionele aanpak is dat de applicatieprogramma's afhankelijk zijn van de databestanden die ze gebruiken en manipuleren. Dientengevolge vereist elke wijziging in het gegevensbestand (in termen van toevoeging of verwijdering van gegevensitems) wijzigingen in alle programma's die het gegevensbestand gebruiken.

Deze afhankelijkheid van gegevens ontmoedigt wijzigingen in gegevensbestanden die tot onbuigzaamheid leiden. Bij afwezigheid van een hulpmiddel voor het uitvoeren van routinematige gegevensbeheeractiviteiten op de gegevens, moeten dergelijke voorzieningen worden opgenomen in de programma's die het gegevensbestand gebruiken. Dit bemoeilijkt het programma. Een ander probleem heeft betrekking op het voldoen aan de ad hoc-vraag.

Voor onverwachte soorten zoekopdrachten moeten speciale programma's worden geschreven. Dergelijke speciale programma's hebben tijd nodig om zich te ontwikkelen en hebben slechts één keer gebruik en zijn dus duur. Er is veel duplicatie bij het opnemen van gegevensitems.

De gegevensitems zoals klantnaam, factuurnummer, prijs, enz. Kunnen bijvoorbeeld worden opgenomen in transactiebestanden voor de applicatie voor de verwerking van klantorders, evenals in de te ontvangen applicaties. Dit veroorzaakt redundantie in gegevens.

De gegevensredundantie resulteert in een inefficiënt gebruik van opslagmedia. Het heeft ook invloed op de kwaliteit van gegevens, omdat het bijwerken van een gegeven gegevensitem mogelijk niet plaatsvindt in alle bestanden waarin dat gegevensitem is opgeslagen.

Database aanpak:

De moderne benadering van gegevensontwerp is een databasebenadering. Deze benadering is gebaseerd op de veronderstellingen dat verschillende applicaties datasets vereisen die veel gemeen hebben. Het is daarom beter om een ​​gemeenschappelijke gegevensopslagruimte te hebben die voldoet aan de gegevensvereisten van elke toepassing in het informatiesysteem.

De gemeenschappelijke repository wordt de database genoemd en wordt beheerd door een beheersysteem dat Database Management System (DBMS) wordt genoemd. De DBMS is software die speciaal is ontworpen om de gegevens in databases te beheren op basis van de aanvragen van applicatieprogramma's, en ook van programma's die rechtstreeks van gebruikers komen. Het conceptuele ontwerp van de databaseomgeving wordt getoond met behulp van Fig. 8.5.

De database-aanpak zorgt voor de problemen van de applicatie-aanpak. Het zorgt voor gegevensonafhankelijkheid terwijl het DBMS zorgt voor de gegevensstroom van de database naar toepassingsprogramma's. De gebruikerstoepassing hoeft zich niet bezig te houden met de locatie van de gegevens in de database. Een gegevenswoordenboek wordt bijgehouden en gegevens kunnen worden opgeroepen met behulp van de woorden die zijn opgegeven in het gegevenswoordenboek.

De databasebenadering vermindert ook de omvang en complexiteit van de applicatieprogramma's omdat de routinematige soort gegevensverwerkende bewerkingen, zoals sorteren, wordt uitgevoerd door de DBMS. Het DBMS wordt ook gebruikt voor het bedienen van de behoeften van een ad hoc-zoekopdracht. De DBMS gebruikt gestructureerde querytaal (SQL) als de taal voor communicatie tussen de gebruiker en de database.

De taal is heel eenvoudig en vrij dicht bij het Engels. Dit zorgt ervoor dat de gebruiker informatie uit de database kan ophalen wanneer en wanneer dat nodig is. De hoeveelheid training die managers nodig hebben voor het maken van ad hoc-vragen is minimaal en een paar uur training kan de basisvaardigheden voor het gebruik van de taal bieden. Misschien is het belangrijkste voordeel van databasebenadering de vermindering van de redundantie in databases.

Er zijn veel modellen die vaak worden gebruikt bij het ontwerpen van databases. De moderne benadering is echter om het ER-model van het databaseontwerp te volgen. Deze aanpak is van boven naar beneden en de eerder in de Enterprise-module getrokken ER-kaarten worden het startpunt.

Voor elke entiteit en relatie worden attributen geïdentificeerd en gedocumenteerd in de Extended ER-diagrammen (EER-diagrammen). In een boekhoudinformatiesysteem kan de EER worden getrokken voor elke entiteit (transactie en rekeningen) en wordt de relatie (effect) voor de transactierekeningen weergegeven in het ER-diagram. Voor een verkooptransactie kunnen bijvoorbeeld attributen worden gespecificeerd en gedocumenteerd zoals getoond in Fig. 8.6.

Deze kenmerken worden de gegevensitems (velden) in een record in het gegevensbestand voor elke entiteit (in dit geval verkooptransactiebestand). Evenzo worden voor andere entiteiten en relaties dergelijke Extended ER (EER) diagrammen getekend.

Zodra deze kenmerken zijn geïdentificeerd, is het waarschijnlijk dat sommige kenmerken in verschillende EER-grafieken gebruikelijk zijn. Om duplicatie van dergelijke gemeenschappelijke kenmerken te voorkomen, wordt normalisatie van gegevens uitgevoerd.

3. Interfacemodule:

Een interfacemodule definieert de bronnen van gegevensitems en de indelingen van invoer / uitvoer en dialoogschermen die in het systeem zullen worden gebruikt. Het definieert ook de rapportformaten en de schermen voor navigatie van het ene deel van de informatiesystemen naar het andere.

Met andere woorden, de module houdt zich bezig met het definiëren van de interface tussen de gebruiker en de machine. Het belang van de interfacemodule is toegenomen door de toegenomen communicatie tussen gebruikers- en informatiesystemen.

Zowel de gegevensinvoer als de gegevensquery zijn interactief geworden. In veel gevallen worden invoerformulieren uit het proces verwijderd en vindt de gegevensinvoer direct plaats. De veranderende eisen van data-query maken veel rapportvormen te star. Interactieve rapportschermen bieden meer flexibiliteit bij gegevensvragen en maken door de gebruiker gedefinieerde rapportindelingen mogelijk voor weergave en afdrukken.

Invoerschermen:

De invoerschermen worden gedefinieerd in het licht van het natuurlijke proces van de bedrijfsactiviteit. Daarom zijn ze in de eerste plaats afhankelijk van de formulieren die worden gebruikt om de gegevens handmatig te registreren wanneer ze voor het eerst door de onderneming worden ontvangen. Deze formulieren, in een boekhoudinformatiesysteem, kunnen bestaan ​​uit factuur, inkooporder, klantorder, kostenbon, enz.

Zo worden formulieren in de interfacemodule ook beoordeeld; opnieuw ontworpen en invoerschermen worden gedefinieerd in het licht van formulieren die door de onderneming worden gebruikt. In een boekhoudinformatiesysteem moet men zorgvuldiger zijn met betrekking tot schermontwerp.

Een kleine verbetering in het invoerscherm dat gegevensinvoer bespaart, kan aanzienlijke besparingen opleveren omdat het aantal keren dat het gegevensinvoerscherm wordt gebruikt erg groot is. De volgende factoren kunnen in gedachten worden gehouden bij het ontwerpen van het invoerscherm:

(a) Matching met formulieren:

Het formaat van het invoerscherm moet overeenkomen met invoerformulieren. Soms loont het om hetzelfde formaat te gebruiken dat wordt gebruikt door het invoerformulier. Voor zover mogelijk kan zelfs de kleur van de achtergrond van het scherm worden aangepast aan de kleur van het invoerformulier.

(b) Interactief:

Het invoerscherm moet interactief zijn. Het moet wijzen op fouten bij het invoeren van gegevens op het moment van invoer en correcties van vergunningen. Elk gegevensitem moet een bepaalde gegevensvalidatietoestand hebben en elke schending van deze gegevensvalidatietoestand moet automatisch worden gemarkeerd op het moment van gegevensinvoer.

Een gegevensinvoerscherm voor het invoeren van een factuur moet bijvoorbeeld wijzen op een fout bij het invoeren van de datum als de datum ongeldig is. De datum kan ongeldig zijn omdat deze buiten de boekhoudperiode valt of de ingevoerde maand groter is dan twaalf.

(c) Consistentie:

De invoerschermen moeten consistent zijn in het definiëren van termen en locaties voor bepaalde veelvoorkomende typen gegevensitems. Het helpt bij het verkorten van de trainingstijd omdat het de bekendheid verbetert; de transactiedatum kan bijvoorbeeld altijd in de rechterhoek van elk transactiedocument worden geplaatst.

(d) Eenvoud:

Een van de basiskenmerken van een goed invoerscherm is de eenvoud. Te veel gemarkeerde secties, knipperende waarden of attributen, of te veel vakken plaatsen en onderstrepen, voegen alleen maar toe aan complexiteit en verwarring. Soms worden piepjes gebruikt om fouten bij het invoeren van gegevens aan te wijzen. Er moet een verstandig gebruik van dergelijke piepjes zijn en deze moeten over het algemeen worden vermeden.

(e) Flexibiliteit:

Het invoerscherm moet geschikt zijn voor wijzigingen. Het moet gebruikers toelaten wijzigingen aan te brengen in termen van toevoeging of verwijdering en verplaatsing van gegevensitems. De procedure voor het wijzigen moet eenvoudig zijn. Tegenwoordig bieden de schermgeneratoren die verkrijgbaar zijn bij verschillende softwarefabrikanten de functies zoals slepen en fixeren / laten vallen van elk gegevensitem van het scherm met een gewoon aanwijsapparaat zoals een muis.

(f) Op maat gemaakt:

De schermen moeten op maat gemaakt zijn voor elke categorie gebruikers. Dit zou onnodig lange start- en toegangsprocedures verminderen.

Rapportschermen:

De rapporten kunnen worden voorbereid voor verdere analyse door een ander computerprogramma of door de gebruiker zelf. De gegevens die zijn bestemd voor verwerking door computerprogramma's, zoals spreadsheets, statistische pakketten, tekstverwerkers, worden bewaard in gegevensbestanden.

Het is beter om ze in het standaard gegevensformaat te plaatsen, zodat ze gemakkelijk toegankelijk zijn. De rapporten bedoeld voor gebruikers worden normaal bewaard in de vorm van tekst, tabellen en grafieken. Er moeten inspanningen worden geleverd om ervoor te zorgen dat de rapporten tijdig, nauwkeurig, duidelijk en tegen lage kosten worden opgesteld en gecommuniceerd.

Dialoogschermen:

De dialoogschermen zijn degene die worden gebruikt voor het identificeren en uitvoeren van de taken in het informatiesysteem. Ze bepalen wat kan worden gedaan met behulp van het informatiesysteem, hoe van de ene taak / procedure naar de andere te navigeren en hoe verschillende taken uit te voeren die door het informatiesysteem worden toegestaan.

Deze schermen moeten eenvoudig en ondubbelzinnig zijn. De eenvoud kan worden geïntroduceerd door Graphic User Interface (GUI) te bieden en een beperkt aantal menu-items op één scherm te hebben. De procedure voor navigatie van het ene menu naar het andere moet eenvoudig zijn, in de juiste volgorde en gemakkelijk te volgen. Het moet ook wijzen op een fout bij het gebruik van opties en moet snel worden gecorrigeerd.

CASE-hulpmiddelen voor schermontwerp:

Een verscheidenheid aan CASE-tools zijn beschikbaar voor het ontwerpen van formulieren, schermen en rapporten. Deze tools hebben het voordeel dat ze een ontwerpomgeving bieden die flexibel en eenvoudig te begrijpen is, zelfs voor een nieuwe gebruiker.

Omdat deze tools beschikken over faciliteiten voor schermprototyping, is het mogelijk om gebruikers meer te betrekken bij het proces van schermontwerpen. Dergelijke tools laten uiteraard snel veranderingen toe en verbeteren de productiviteit van programmeurs door codes te genereren voor de uiteindelijke implementatie. Dit resulteert in kortere ontwikkeltijd.

Zodra de formulieren, invoer- / uitvoerschermen en dialoogschermen gereed zijn, moeten ze worden getest en dienovereenkomstig worden aangepast. De formulieren en schermen die zijn ontworpen met behulp van de CASE-tools kunnen eenvoudig worden gewijzigd. Daarom moeten inspanningen worden geleverd om de aanvaardbaarheid van het systeem te verbeteren door correct testen en wijzigen van formulieren en schermen.

4. Toepassingenmodule:

Deze module breidt de subsystemen uit die al zijn geïdentificeerd in de enterprise-module. Voor elk subsysteem dat wordt geïdentificeerd in het structuurdiagram, worden gedetailleerde verwerkingsprocedures gedefinieerd in deze module.

Met andere woorden, de applicatiemodule houdt zich primair bezig met de processen die betrokken zijn bij het converteren van de invoergegevens in waarden die deel zullen uitmaken van de rapporten zoals gedefinieerd in de interfacemodule. Het kan worden opgemerkt dat alleen die processen moeten worden gedefinieerd dat

(a) Verander de waarden in de databases, of

(b) Dat zijn geen onderdelen van de database, maar zijn vereist in de rapporten die zijn gedefinieerd in de interfacemodule.

De waarden die al in de database bestaan, kunnen worden benaderd met DBMS-querytaal volgens de vereiste van gebruikers zonder programma's voor dit doel te ontwikkelen. Aldus wordt de taak van de applicatiemodule verminderd door het werk dat al is uitgevoerd in het databaseontwerp en schermontwerp.

Gegevensstroomschema:

De rol van de manager in deze module is in feite de identificatie van de basisverwerkingsprocedure. De gedetailleerde algoritmen worden over het algemeen gedefinieerd en gedocumenteerd door professionals van het informatiesysteem, uiteraard met actieve hulp van de manager.

Het hulpprogramma dat wordt gebruikt voor het uitdrukken van de processen die moeten worden uitgevoerd voor het converteren van de invoergegevens naar uitvoer, is het gegevensstroomdiagram (DFD). Het beschrijft de stroom van gegevens. Het definieert wat moet worden gedaan en negeert hoe het moet worden gedaan of hoe het eerder werd gedaan. Deze benadering maakt veranderingen in het systeem mogelijk en zwakke punten van het bestaande systeem kunnen volgens deze benadering worden verwijderd.

DFD-symbolen:

Er zijn vier basissymbolen die worden gebruikt in DFD's. Zij zijn:

(i) Terminator:

Terminator is een externe bron van gegevensstromen of externe gegevensverzameling. Het is een externe entiteit of een object zoals klant, verkoper, aandeelhouders, etc. Omdat de terminators externe entiteiten zijn, wordt de communicatie tussen de terminators uitgesloten van het systeem. De terminator wordt gesymboliseerd door een rechthoek (meestal in de schaduw) en het label wordt in de rechthoek geplaatst.

(ii) Gegevensstroom:

Gegevensstroom draagt ​​een reeks gegevensitems met betrekking tot de gebeurtenis die door de terminator is geïnitieerd. Het wordt gesymboliseerd met een pijl in DFD en de richting van de stroom wordt aangegeven door de richting van de pijl. De pijlen zijn over het algemeen gelabeld tenzij ze naar of van gegevensbestanden worden geleid. Zoals eerder opgemerkt, zijn gegevensstromen tussen twee terminators niet opgenomen in DFD en kunnen gegevens dus niet rechtstreeks tussen twee terminators stromen.

(iii) Proces:

Proces transformeert de inkomende gegevens voor doorverwijzing naar gegevensopslag of terminator. Het wordt gesymboliseerd door een rechthoek met afgeronde hoeken of een cirkel. Het is natuurlijk gelabeld met een werkwoord.

(iv) Gegevensopslag:

Bestanden zijn de gegevensopslagplaatsen in informatiesystemen en worden weergegeven in DFD's in de vorm van open rechthoeken. Over het algemeen komen ze overeen met tabellen in databases. Een gedeeltelijk overzicht van het gegevensstroomdiagram voor de verwerking van verkooporders is weergegeven in Fig. 8.7.

Er kan worden opgemerkt dat sommige aanvullende symbolen en kleine variaties in symbolen die verschillende componenten van DFD vertegenwoordigen ook in gebruik zijn. De bovenstaande symbolen zijn de symbolen die het meest worden gebruikt en zijn volgens de grafische conventie voorgesteld door Gane en Sarson.

Vaak vindt een manager het tekenen van DFD erg moeilijk en frustrerend. Telkens wanneer iemand een DFD tekent, constateert men dat men het ene of het andere aspect van de gegevensstroom heeft genegeerd. Gelukkig hebben de beschikbare CASE-tools faciliteiten voor het maken en wijzigen van DFD's. Beginners worden echter geadviseerd om de volgende stappen te volgen om dit probleem op te lossen:

(a) Identificeer alle invoergegevensstromen en uitvoergegevensstromen afzonderlijk, samen met terminators, waarbij invoergegevensstromen aan de linkerzijde en uitvoergegevensstroom aan de rechterkant worden geplaatst.

(b) Label de terminators met behulp van datastroom-naamwoord of adjectievenamen.

(c) Identificatie van processen die voortkomen uit invoergegevensstromen en terugwaarts van uitvoergegevensstromen tot ze in het midden samenkomen.

(d) Label de processen met behulp van werkwoordnamen.

Een manager moet voorbereid zijn om de DFD opnieuw te tekenen omdat de gegevensstromen vaak pas na het tekenen van DFD duidelijk worden voor de manager. Gebruikersbetrokkenheid in deze fase is erg nuttig, niet alleen om de inspanning van de manager te verminderen, maar ook om de DFD te verbeteren.

Testen van DFD:

Er wordt gesuggereerd dat de DFD grondig moet worden getest voordat deze is voltooid. Hier volgen enkele veelvoorkomende fouten in het ontwerp van DFD:

een. Het terminatielabel kan de naam van een persoon of een onderneming zijn in plaats van klasse. Een terminator kan bijvoorbeeld worden gelabeld als M / s. BR Ltd. in plaats van enige verkoper. Een andere fout zou kunnen zijn dat de drager als terminator wordt geplaatst in plaats van de externe entiteit die direct is gekoppeld aan de gegevensstroom.

b. Gegevens kunnen direct van de ene terminator naar de andere terminator stromen.

c. Er kan geen gegevensstroom naar of van een proces worden aangegeven.

d. Gegevensstroom wordt aangegeven van terminator naar een gegevensopslag (bestand) of van een bestand naar een terminator, of tussen twee bestanden zonder verwerking.

e. De processen worden gelabeld als objecten, zoals een factuur of een zelfstandig naamwoord, zoals een reserveringsmedewerker.

Nadat de DFD's voor elk subsysteem zijn getekend, kunnen toekomstige verwerkingsdetails worden gekalkt en beschreven in gestructureerde Engels (psedo-codes). Deze psedo-codes worden later gebruikt voor het coderen van de applicaties. De rol van de manager in dit proces beperkt zich alleen tot het professioneel helpen van de informatiesystemen bij het identificeren en begrijpen van de algoritmen die bij de verwerking zijn betrokken.

5. Implementatiemodule:

Deze module houdt zich voornamelijk bezig met het testen van het systeem, het trainen van de gebruikers en de installatie van het systeem.

Het systeem testen:

Het testen van verschillende modules gebeurt in verschillende stadia van het ontwikkelingsproces. De gouden regel die in gedachten moet worden gehouden bij het testen, is dat het testen moet worden gedaan om vast te stellen op welke manier het systeem waarschijnlijk zal falen. Het zou niet moeten zijn om te bewijzen dat het systeem volgens de ontwerpspecificatie zal werken. Testen van het systeem is het zoeken naar antwoorden op twee basisvragen:

1. Of het informatiesysteem de informatiebehoeften van de onderneming dient? Het proces dat antwoord op deze vraag zoekt, wordt door systeembeheersprofessionals genoemd als systeemvalidatieproces.

2. Functioneert het informatiesysteem correct? Het verificatieproces zoekt een antwoord op deze vraag.

Omdat de aard en mate van ernst van fouten in verschillende stadia van de systeemontwikkeling verschillend zijn, worden verschillende tests op verschillende modules en op het systeem als geheel afgenomen.

Hoofdstuk toets:

De tests die op moduleniveau worden gebruikt, kunnen eenheidstests worden genoemd. Deze tests worden uitgevoerd om fouten in interfaces, databases, rekenkundige bewerkingen en besturingslogica te detecteren. Ze worden uitgevoerd door een module van het informatiesysteem uit te voeren op testgegevens die speciaal zijn ontworpen om te testen of het systeem:

een. Accepteert onjuist type gegevens (bijv. Aanvaardt numerieke waarde voor naam);

b. Accepteert buiten geldige bereikgegevens (bijv. Accepteert datum met maand groter dan 12);

c. Veroorzaakt verkeerd springen van een procedure naar een andere procedure.

Systeemtest:

Aangezien de unit-tests afzonderlijk worden uitgevoerd, is het essentieel dat de integratietests worden uitgevoerd om te controleren of deze units al dan niet correct functioneren als een groep. Vanwege de uiteenlopende aard van fouten moeten verschillende teststrategieën worden gevolgd om de geldigheid te controleren en het systeem te verifiëren. Fertuck geeft drie strategieën voor het testen van het informatiesysteem:

(a) Clear-box testen:

In deze strategie worden tests ontworpen om vast te stellen of de procedures die worden gevolgd voor verwerking overeenkomen met de vereisten van de toepassing. Dit kan worden bereikt met behulp van collega-informatiesysteemprofessionals die niet direct betrokken waren bij de ontwikkelingsfase.

Als alternatief kan een gestructureerde walkthrough-methode worden gebruikt. In deze methode beoordeelt een groep personen de procedures, waarbij ze eerst de voor fouten gevoelige delen bekijken en identificeert welke correcties moeten worden aangebracht. Vervolgens beoordelen de groepsleden de uitvoer die het systeem zal bieden voor een bepaald type invoer en testen of de uitvoer van het systeem correct is of niet.

(b) Black Box-tests:

In deze strategie wordt het systeem getest op ongeldige gegevens of gegevens die fouten in de werking van het systeem kunnen veroorzaken. De uitvoer wordt gecontroleerd om vast te stellen of er een fout is opgetreden. Gegevens kunnen bijvoorbeeld een negatieve waarde bevatten voor de bestelde hoeveelheid of een fractionele waarde voor een variabele die alleen de gehele waarde kan aannemen.

(c) Teckendoos testen:

Deze strategie gaat ervan uit dat het nooit mogelijk is om een ​​volledig foutloos informatiesysteem te leveren. Dus, na alle testen en aanpassingen, is het noodzakelijk om het aantal nog resterende fouten in het systeem te schatten. Om dit aantal te schatten, kunnen een paar fouten met opzet in het systeem worden geïntroduceerd. Vervolgens worden de tests opnieuw uitgevoerd om fouten te detecteren.

Het percentage geïntroduceerde fouten dat wordt gedetecteerd, wordt genomen als een schatting van het percentage echte fouten dat is gedetecteerd tijdens de eerdere tests. Dus, als 90% van de geïntroduceerde fouten werden gedetecteerd tijdens het testen van de tijkendoos terwijl in totaal 450 fouten werden gedetecteerd oorspronkelijk tijdens het testen van de clear box en de black box, betekent dit dat 50 echte fouten onopgemerkt blijven in het systeem.

Installatie:

Installatie is een proces waarbij het oude systeem wordt vervangen door een nieuw systeem. In grote lijnen zijn er vier benaderingen voor installatie. De 'koude' installatie wordt uitgevoerd wanneer het oude systeem onmiddellijk wordt stopgezet en wordt vervangen door een nieuw systeem.

Een dergelijke installatie heeft het voordeel van een snellere psychologische aanpassing met het feit dat het nieuwe systeem moet worden gebruikt. Een dergelijke benadering is misschien niet geschikt als oude gegevens uit het eerdere systeem waardevol zijn of als het nieuwe systeem enkele problemen heeft. Voor het installeren van boekhoudinformatiesystemen is deze aanpak niet aanvaardbaar gevonden. De alternatieve benaderingen omvatten:

(a) Pilootinstallatie:

Een systeem kan alleen worden geïnstalleerd voor gebruik door een selecte representatieve gebruikersgroep die het systeem test door het daadwerkelijk te gebruiken. Andere gebruikers blijven oud systeem gebruiken. Wanneer de problemen in het systeem worden aangepakt, beginnen andere gebruikers het systeem ook te gebruiken. Deze benadering is ook niet erg populair voor boekhoudinformatiesystemen omdat de volledige boekhoudgegevensbank moet worden bijgewerkt voordat deze door gebruikers kan worden gebruikt.

De informatiebehoeften van de gebruiker overschrijden de grenzen van afdelingen en divisies in het organigram. Deze benadering kan echter worden gebruikt voor volledige boekhoudkundige entiteiten zoals een filiaal, een regionaal kantoor, enz. Een boekhoudinformatiesysteem kan dus door geselecteerde filialen worden gebruikt. Als ze eenmaal foutloos zijn bevonden, kunnen ze ook door andere branches worden gebruikt.

(b) Phase-in installatie:

Bij deze aanpak vindt de installatie in fasen plaats. Deze fasen zijn onafhankelijke componenten van het informatiesysteem. De inkomstenlevenscyclus van een boekhoudinformatiesysteem kan dus het eerst worden geïnstalleerd en de een na de ander kunnen andere levenscycli volgen. Deze benadering helpt bij het focussen op een geselecteerd deel van het systeem. Het helpt bij het verbeteren van de aanvaardbaarheid van het systeem bij gebruikers, omdat het de gebruiker in staat stelt om gemakkelijk met veranderingen om te gaan.

(c) Parallelle installatie:

De parallelle installatie betekent dat het oude en het nieuwe systeem tegelijkertijd gedurende een bepaalde periode worden gebruikt totdat het nut van het nieuwe systeem is bewezen. Deze methode is het populairst voor boekhoudinformatiesystemen, omdat dit de veiligste van alle andere methoden is. De enige moeilijkheid hier is de kosten van parallelle run en de neiging om de parallelle looptijd te verlengen van diegenen die zich verzetten tegen verandering.

Beoordeling na implementatie:

Elk systeem moet worden beoordeeld nadat de implementatie is voltooid. Een dergelijke beoordeling helpt niet alleen bij het identificeren van de zwakke punten van het systeem, maar bereidt ook een agenda voor voor toekomstige wijzigingen voor. Het is in feite een leerproces. Systeemaudit kan ook worden uitgevoerd om te onderzoeken hoe succesvol het systeem is, in termen van kosten, leveringsschema, volledigheid en kwaliteit.