Sviluppo del sistema informativo contabile: Enterprise, database e moduli di interfaccia

Sviluppo del sistema informativo di contabilità: Enterprise, database e moduli di interfaccia!

Sono disponibili numerosi pacchetti di software di contabilità che offrono una varietà di funzionalità. Essi costano molto meno di quanto costerebbe il software di contabilità personalizzato. Tuttavia, questi pacchetti software offrono solo la struttura per i sistemi di informazione contabile. Al massimo, riducono lo sforzo di programmazione per i sistemi informativi contabili.

Cortesia dell'immagine: bestsmallbizhelp.com/wp-content/uploads/2011/07/1018910261.jpg

Lo sviluppo di sistemi di informazione contabile è molto più che il software per la pubblicazione di registri contabili e la creazione di report. Prevede anche l'istituzione di procedure per l'acquisizione di dati e la distribuzione, nonché l'analisi delle informazioni contabili.

Lo sviluppo di un sistema di informazione contabile è spiegato con particolare riferimento ai requisiti di un'impresa commerciale di dimensioni medio-grandi. Tuttavia, questi passaggi sarebbero comuni alla maggior parte degli altri sistemi di informazione in un'azienda commerciale.

1. Modulo Enterprise:

Il modulo aziendale di sviluppo del sistema informativo comporta l'identificazione delle entità di base e delle loro interrelazioni, l'identificazione delle attività di base e il raggruppamento di queste attività in sottosistemi. Quindi, le priorità vengono decise sulla base dell'analisi costi-benefici per l'impresa.

Identificazione delle entità:

Un numero elevato di entità esiste in un'azienda commerciale e l'elenco è tanto vario quanto lo sono le attività commerciali. Tuttavia, in questa fase, la preoccupazione principale è identificare le entità ampie, ciascuna contenente un gruppo di entità elementari. Kerner 5 indica sei entità di base in un'azienda commerciale.

Sono clienti, prodotti, venditori, personale, strutture e denaro. In un sistema di informazione contabile, ci sono tre entità di base, vale a dire transazioni, conto e periodo di elaborazione. Le interrelazioni tra queste entità possono essere espresse usando i diagrammi ER come mostrato in Fig. 8.2.

Le transazioni devono essere di diverso tipo, come ricevute, pagamenti, vendite, acquisti, acquisizione di attività o rimborso di passività, ecc. E ciascuna di esse può essere definita un'entità di livello inferiore. Allo stesso modo, i conti possono essere di diversi tipi, come attività, passività, entrate e spese.

Ognuno di questi capi può avere entità di livello inferiore come le immobilizzazioni e le attività correnti. Queste entità possono essere ulteriormente suddivise in entità ancora di livello inferiore come terreni e fabbricati, impianti e macchinari, ecc. Tuttavia, in questa fase, è necessario identificare le entità generali. I dettagli vengono elaborati al momento della progettazione dei database.

Le entità sono identificate alla luce e al fine di definire la portata e l'attenzione del sistema informativo. Ad esempio, se il sistema informativo è visto come un sistema informativo strategico, le entità generali devono essere identificate alla luce delle spinte strategiche che l'impresa intende dare alle proprie attività con l'aiuto del sistema informativo.

Queste spinte potrebbero essere la minimizzazione dei costi, il servizio clienti, la differenziazione dei prodotti e le alleanze strategiche. Le entità di base in questo caso sarebbero clienti, canali, imprese concorrenti, prodotti, ecc.

Analisi delle attività:

Un altro aspetto importante del modulo aziendale è l'identificazione delle attività associate alle entità. Queste attività sono ampiamente identificate sotto forma di relazioni nei diagrammi ER. Tuttavia, i dettagli sono ottenuti con l'aiuto di analisi delle attività. La struttura organizzativa esistente è un'importante fonte di informazioni per quanto riguarda le vaste attività intraprese dall'impresa.

Tuttavia, al fine di sviluppare sistemi di informazione indipendenti dall'attuale struttura organizzativa, è essenziale basare l'analisi dell'attività sulle entità di base già identificate sopra. Il prossimo livello di analisi delle attività comporta l'identificazione delle attività del ciclo di vita. Nel caso di "operazioni" che costituiscono una delle entità di base in un sistema di informazione contabile, esistono quattro ampie attività del ciclo di vita, ossia:

1. Acquisto del ciclo di vita

2. Ciclo di vita della produzione

3. Ciclo di vita dei ricavi

4. Ciclo di vita degli investimenti

Allo stesso modo, il periodo di elaborazione ha due attività fondamentali del ciclo di vita, vale a dire:

un. Pianificazione e controllo del ciclo di vita

b. Ciclo di vita dei rapporti interni ed esterni

Queste attività del ciclo di vita sono attività in corso e vengono eseguite continuamente. Ciascuna di queste attività può essere correlata sequenzialmente ad altre attività. Il terzo livello di analisi delle attività comporta la suddivisione delle attività del ciclo di vita in funzioni.

Ad esempio, ogni tipo di transazione deve essere avviato e riconosciuto; quindi i dati relativi alla transazione devono essere acquisiti, codificati per la futura classificazione, classificati, riepilogati e segnalati. Queste funzioni devono essere eseguite in modo diverso per diversi tipi di transazioni. Il processo di definizione delle funzioni si concentra solo su quelle attività che creano, aggiornano o utilizzano le informazioni nel database dell'azienda.

A questo livello di analisi delle attività, le attività sono autonome, hanno chiaramente definito gli eventi o nodi di inizio e fine e una persona identificabile o un gruppo di persone responsabili dell'esecuzione della funzione.

Queste funzioni possono quindi essere suddivise in sottofunzioni fino a quando le funzioni sono abbastanza specifiche da definire il modulo per i programmi per computer. La suddivisione delle attività del ciclo di vita in funzioni e sotto-funzioni aiuta nell'individuazione di funzioni che si ripetono in più di un'attività del ciclo di vita.

Ad esempio, la funzione di classificazione dei dati acquisiti può essere eseguita nei cicli di vita degli acquisti e della commercializzazione. Tale analisi delle attività aiuta a identificare le opportunità per migliorare il design esistente:

1. eliminazione delle funzioni ridondanti

2. combinando le funzioni duplicate

3. semplificare e migliorare i metodi di elaborazione

La ridondanza può essere identificata mediante un'attenta analisi delle attività. Le attività che possono offrire opportunità per migliorare l'elaborazione includono attività:

un. Anche questo viene eseguito altrove

b. Questo può essere combinato con altre attività

c. Questo può essere gestito anche da un'altra persona

d. Ciò può essere eseguito in qualche altra fase del ciclo di vita che non aggiunge alcun valore al prodotto o al servizio del sistema informativo.

Una parola di cautela qui è che non tutti i licenziamenti sono cattivi. In effetti, alcune ridondanze o duplicazioni possono essere intenzionalmente autorizzate a insinuarsi nel sistema. Questo può essere fatto al fine di migliorare le prestazioni e l'affidabilità del sistema.

Ad esempio, alcune delle duplicazioni potrebbero essere necessarie per garantire la semplicità delle procedure e migliorare la velocità di elaborazione. L'eliminazione della ridondanza può comportare il 'mettere tutte le uova in un unico paniere' e quindi influire sull'affidabilità. Il rischio di implicazioni impreviste e bassi ritorni dal nuovo metodo o procedura proposti sono altri fattori che meritano attenzione prima che vengano proposte modifiche nel sistema informativo.

Raggruppamento di attività in sottosistemi:

Dopo che le attività sono state definite utilizzando l'approccio top-down adottato sopra, vengono raggruppate per formare sottosistemi. Una decisione importante da prendere in questa fase riguarda la base del raggruppamento. Non può esistere un unico criterio oggettivo per decidere a quale sottosistema appartiene un'attività.

L'attuale struttura organizzativa può fornire una delle basi per il raggruppamento di attività. Tuttavia, l'attuale struttura organizzativa potrebbe subire modifiche e l'utilità del sistema informativo potrebbe andare persa.

Per raggruppare le attività nel sottosistema, prendiamo l'aiuto dalla teoria dell'organizzazione. Una delle caratteristiche essenziali di ogni buona struttura organizzativa è che mira a facilitare il coordinamento delle attività.

Un sistema efficace di comunicazione è requisito essenziale per un migliore coordinamento. È quindi essenziale raggruppare le attività in modo tale da facilitare la comunicazione all'interno del gruppo e ridurre al minimo la necessità di una comunicazione tra gruppi.

Allo scopo di rappresentare e documentare il raggruppamento di attività in sottosistemi, vengono utilizzati diagrammi di struttura o diagrammi a blocchi gerarchici. La figura 8.3 fornisce un diagramma di struttura che mostra i componenti del ciclo delle entrate.

Grafici di struttura simili possono essere preparati per altri cluster di attività e, infine, questi sottosistemi sono integrati tra loro fornendo i mattoni per un sistema di informazioni contabili.

I sottosistemi così identificati dal raggruppamento di attività sono seri contendenti per essere entità nella struttura organizzativa. Il vantaggio con il metodo di raggruppamento per raggruppare le attività è che il raggruppamento si basa su funzioni e risorse e non su aree geografiche.

Tale clustering sulla base di funzioni garantisce l'omogeneità tra i membri del gruppo di persone associate a ciascuno dei sottosistemi. L'impatto dell'organizzazione del sistema informativo sulla struttura organizzativa non è raro.

Spesso, l'introduzione di sistemi di informazione è stata accompagnata da cambiamenti nelle strutture organizzative a causa del fatto che i nuovi sistemi di informazione cambiano il modo in cui le persone lavorano in un'organizzazione.

Pertanto, è ancora più importante che i progettisti dei sistemi informatici lavorino in associazione attiva con le persone che si occupano dello sviluppo dell'organizzazione mentre il raggruppamento di attività in cluster e sottosistemi è in corso. Ciò garantisce non solo che la nuova struttura sia più pragmatica, ma anche più accettabile per le persone. In questi casi, la transizione dal vecchio sistema a quello nuovo è meno dolorosa e meno costosa.

Impostazione delle priorità:

Una volta che i sottosistemi sono stati identificati e integrati nel loro insieme, le priorità devono essere determinate tra i vari sottosistemi e le caratteristiche di ciascun sistema. Il sistema informativo richiederebbe l'impegno di risorse finanziarie.

Inoltre, potrebbero esserci costi impliciti del nuovo sistema in termini di cambiamenti necessari nel processo operativo. È quindi fondamentale valutare i pro e i contro di ciascun sottosistema e sottosistema prima che siano progettati e implementati.

Ogni sottosistema viene valutato sulla base di criteri di valutazione ben definiti definiti in termini di fattori critici di successo (CSF). Questi fattori sono già stati identificati nella Sezione 8.2.

L'altro metodo è il brainstorming, in cui le persone rilevanti nell'organizzazione si riuniscono per identificare i fattori che meritano considerazione nel determinare le priorità. Il libero flusso di idee è incoraggiato nella prima fase.

Il principio sottostante, qui, è che nessuna idea è sciocca o irrilevante in questa fase. Durante la seconda fase, inizia il processo di eliminazione e dopo le discussioni, i suggerimenti sono finalizzati.

Una volta finalizzato l'elenco dei fattori, vengono assegnati i pesi relativi e viene definita la funzione di un criterio per valutare ciascun componente del sistema di informazione contabile proposto.

2. Modulo database:

Il sistema di informazioni contabili elabora un grande volume di dati. Gestire i dati è, quindi, una delle principali considerazioni nel processo di sviluppo. Esistono due approcci di base alla progettazione dei dati, vale a dire:

un. L'approccio tradizionale, orientato all'applicazione, e

b. L'approccio al database.

Approccio tradizionale:

L'approccio tradizionale alla progettazione dei dati è orientato all'applicazione, nel senso che per ciascuna applicazione viene generato un set separato di file di dati in base alle proprie esigenze. In altre parole, i file di dati sono dedicati a una determinata applicazione e sono in qualche modo "di proprietà" dell'applicazione.

Ad esempio, un'applicazione di contabilità clienti deve contenere il file dei dati anagrafici del cliente, un file delle transazioni di vendita e una ricevuta dal file delle transazioni dei clienti. Questi file di dati vengono utilizzati solo per l'applicazione di contabilità clienti.

Questo approccio è adatto a sistemi informativi contabili di dimensioni ridotte per la sua semplicità. Tuttavia, a mano a mano che il sistema di informazione cresce in termini di volume di dati e complessità di analisi, dà origine a determinati problemi.

Il problema fondamentale con l'approccio tradizionale è che i programmi applicativi dipendono dai file di dati che usano e manipolano. Di conseguenza, qualsiasi modifica nel file di dati (in termini di aggiunta o eliminazione di dati) richiede modifiche in tutti i programmi che utilizzano il file di dati.

Questa dipendenza dei dati scoraggia le modifiche nei file di dati che portano alla mancanza di flessibilità. In assenza di qualsiasi strumento per l'esecuzione di attività di gestione dei dati di tipo tipo sui dati, tali servizi devono essere inclusi nei programmi utilizzando il file di dati. Questo complica il programma. Un altro problema riguarda il soddisfacimento della query ad hoc.

Per il tipo inatteso di query, è necessario scrivere programmi speciali. Questi programmi speciali richiedono tempo per svilupparsi e hanno un solo uso e quindi sono costosi. Vi sono molte duplicazioni nella registrazione di elementi di dati.

Ad esempio, gli elementi di dati come il nome del cliente, il numero della fattura, il prezzo, ecc. Possono essere inclusi nei file di transazione per l'applicazione di elaborazione degli ordini di vendita, nonché per l'applicazione dei conti clienti. Ciò causa ridondanza nei dati.

La ridondanza dei dati si traduce in un uso inefficiente dei supporti di memorizzazione. Influisce anche sulla qualità dei dati in quanto l'aggiornamento di un dato elemento dati potrebbe non avvenire in tutti i file in cui è memorizzato quell'elemento di dati.

Approccio al database:

L'approccio moderno alla progettazione dei dati è l'approccio al database. Questo approccio si basa sull'ipotesi che diverse applicazioni richiedano insiemi di dati che hanno molto in comune. Pertanto, è meglio disporre di un repository comune di dati che soddisfi i requisiti dei dati di ciascuna applicazione nel sistema informativo.

Il repository comune è chiamato database ed è gestito da un sistema di gestione chiamato Database Management System (DBMS). Il DBMS è un software appositamente progettato per gestire i dati nei database in base alle richieste dei programmi applicativi, nonché da quelli provenienti direttamente dagli utenti. La progettazione concettuale dell'ambiente di database è mostrata con l'aiuto di Fig. 8.5.

L'approccio al database si occupa dei problemi dell'approccio delle applicazioni. Assicura l'indipendenza dei dati poiché il DBMS si occupa del flusso di dati dal database ai programmi applicativi. L'applicazione utente non deve preoccuparsi della posizione dei dati nel database. Viene mantenuto un dizionario dei dati e i dati possono essere richiamati utilizzando le parole specificate nel dizionario dei dati.

L'approccio al database riduce anche le dimensioni e la complessità dei programmi applicativi in ​​quanto il tipo di routine delle operazioni di elaborazione dei dati, come l'ordinamento, viene eseguito dal DBMS. Il DBMS viene anche utilizzato per soddisfare le esigenze della query ad hoc. Il DBMS utilizza Structured Query Language (SQL) come linguaggio per la comunicazione tra l'utente e il database.

La lingua è molto semplice e abbastanza vicina all'inglese. Ciò garantisce che l'utente possa ottenere informazioni dal database come e quando richiesto. La quantità di formazione richiesta dai manager per effettuare query ad hoc è minima e poche ore di formazione possono fornire le competenze elementari per l'utilizzo della lingua. Forse, il vantaggio più importante dell'approccio al database è la riduzione della ridondanza nei database.

Esistono molti modelli comunemente usati nella progettazione di database. Tuttavia, l'approccio moderno è quello di seguire il modello ER di progettazione di base dati. Questo approccio è l'approccio top-down e i grafici ER disegnati in precedenza nel Modulo Enterprise diventano il punto di partenza.

Per ciascuna entità e relazione, gli attributi sono identificati e documentati nei diagrammi ER estesi (diagrammi EER). In un sistema di informazioni contabili, l'EER può essere estratto per ciascuna entità (transazione e contabilità) e la relazione (effetto) per i conti delle transazioni è indicata nel diagramma ER. Ad esempio, per una transazione di vendita, gli attributi possono essere specificati e documentati come mostrato in Fig. 8.6.

Questi attributi diventano gli elementi di dati (campi) in un record nel file di dati per ciascuna entità (in questo caso il file delle transazioni di vendita). Allo stesso modo, per le altre entità e relazioni vengono disegnati i diagrammi ER (ER esteso).

Una volta identificati questi attributi, è probabile che alcuni degli attributi siano comuni in diversi grafici EER. Per evitare la duplicazione di tali attributi comuni, viene eseguita la normalizzazione dei dati.

3. Modulo di interfaccia:

Un modulo di interfaccia definisce le origini degli elementi di dati e i formati di input / output e le schermate di dialogo che devono essere utilizzate nel sistema. Definisce inoltre i formati del report e le schermate per la navigazione da una parte dei sistemi di informazione all'altro.

In altre parole, il modulo si occupa della definizione dell'interfaccia tra utente e macchina. L'importanza del modulo di interfaccia è aumentata a causa dell'aumentata comunicazione tra utente e sistemi informativi.

Sia l'inserimento dei dati che l'interrogazione dei dati sono diventati interattivi. In molti casi, i moduli di input vengono eliminati dal processo e l'immissione dei dati avviene direttamente. I mutevoli requisiti della query di dati rendono troppo rigidi molti moduli di report. Le schermate di report interattive offrono una maggiore flessibilità nella query dei dati e consentono formati di report definiti dall'utente per la visualizzazione e la stampa.

Schermate di input:

Le schermate di input sono definite alla luce del processo naturale dell'attività aziendale. Pertanto, dipendono principalmente dai moduli utilizzati per registrare manualmente i dati quando vengono ricevuti per la prima volta dall'azienda. Queste forme, in un sistema di informazioni contabili, possono includere fattura, ordine di acquisto, ordine di vendita, buono spesa, ecc.

Pertanto, nel modulo di interfaccia, anche i moduli vengono rivisti; ridisegnati e schermate di input sono definiti alla luce dei moduli utilizzati dall'azienda. In un sistema di informazione contabile, bisogna essere più attenti alla progettazione dello schermo.

Un piccolo miglioramento nella schermata di immissione che consente di salvare l'immissione dei dati può comportare notevoli risparmi poiché il numero di volte in cui viene utilizzata la schermata di immissione dei dati è molto grande. I seguenti fattori possono essere tenuti a mente durante la progettazione dello schermo di input:

(a) Abbinamenti con le forme:

Il formato dello schermo di input deve corrispondere ai moduli di input. A volte, si paga per adottare lo stesso formato utilizzato dal modulo di input. Nella misura del possibile, anche il colore dello sfondo dello schermo può essere abbinato al colore del modulo di input.

(b) Interattivo:

Lo schermo di input dovrebbe essere interattivo. Dovrebbe segnalare errori nell'immissione dei dati proprio al momento dell'iscrizione e consentire correzioni. Ogni elemento di dati deve avere alcune condizioni di convalida dei dati e qualsiasi violazione di tali condizioni di convalida dei dati dovrebbe essere automaticamente evidenziata al momento dell'inserimento dei dati.

Ad esempio, una schermata di inserimento dati per l'inserimento della fattura deve indicare errori nell'inserimento della data se la data non è valida. La data potrebbe non essere valida perché è al di fuori del periodo contabile o il mese inserito è maggiore di dodici.

(c) Consistenza:

Le schermate di input devono essere coerenti nella definizione di termini e posizione per determinati tipi comuni di elementi di dati. Aiuta a ridurre il tempo di allenamento in quanto migliora la familiarità; ad esempio, la data della transazione può sempre essere collocata nell'angolo destro di ciascun documento di transazione.

(d) Semplicità:

Una delle caratteristiche di base di un buon schermo di input è la semplicità. Troppe sezioni evidenziate, il lampeggiamento di valori o attributi o la presenza di troppi riquadri e sottolineature aggiungono solo complessità e confusione. A volte vengono utilizzati segnali acustici per segnalare errori di immissione dei dati. Ci dovrebbe essere un uso giudizioso di tali beep e, in generale, questi dovrebbero essere evitati.

(e) Flessibilità:

Lo schermo di immissione dovrebbe essere suscettibile di modifiche. Dovrebbe consentire agli utenti di apportare modifiche in termini di aggiunta o cancellazione e trasferimento dell'elemento di dati. La procedura per la modifica dovrebbe essere semplice. In questi giorni, i Generatori di schermate disponibili da vari produttori di software offrono le funzionalità come trascinare e correggere / rilasciare qualsiasi elemento di dati dallo schermo utilizzando un normale dispositivo di puntamento come il mouse.

(f) su misura:

Gli schermi devono essere personalizzati per ogni categoria di utenti. Ciò ridurrebbe le procedure di ingresso e di entrata indebitamente lunghe.

Schermate del report:

Le relazioni possono essere preparate per ulteriori analisi da parte di altri programmi per computer o dall'utente stesso. I dati diretti per l'elaborazione da programmi per computer, come fogli di calcolo, pacchetti statistici, elaboratori di testi, sono conservati in file di dati.

È meglio metterli in un formato dati standard in modo che possano essere facilmente accessibili. I report destinati agli utenti sono normalmente mantenuti sotto forma di testo, tabelle e grafici. Dovrebbero essere fatti degli sforzi per garantire che i rapporti siano redatti e comunicati in modo tempestivo, accurato, chiaro e a basso costo.

Schermi di dialogo:

Le schermate di dialogo sono quelle utilizzate per identificare ed eseguire le attività nel sistema informativo. Definiscono cosa può essere fatto con l'aiuto del sistema informativo, come spostarsi da una attività / procedura a un'altra e come eseguire varie attività consentite dal sistema informativo.

Questi schermi dovrebbero essere semplici e non ambigui. La semplicità può essere introdotta fornendo l'interfaccia utente grafica (GUI) e il numero limitato di voci di menu in un'unica schermata. La procedura per la navigazione da un menu all'altro dovrebbe essere semplice, in giusta sequenza e facile da seguire. Dovrebbe anche segnalare l'errore nell'esercitare le opzioni ed essere pronto a correggere la procedura.

Strumenti CASE per la progettazione dello schermo:

Sono disponibili numerosi strumenti CASE per la progettazione di moduli, schermate e report. Questi strumenti hanno il vantaggio di offrire un ambiente di progettazione flessibile e semplice da comprendere anche per un nuovo utente.

Poiché questi strumenti dispongono di funzionalità di prototipazione dello schermo, è possibile coinvolgere maggiormente gli utenti nel processo di progettazione dello schermo. Ovviamente, tali strumenti consentono rapidi cambiamenti e migliorano la produttività dei programmatori generando codici per l'implementazione finale. Ciò si traduce in tempi di sviluppo ridotti.

Una volta che i moduli, le schermate di input / output e le schermate di dialogo sono pronti, dovrebbero essere testati e modificati di conseguenza. Le forme e le schermate progettate utilizzando gli strumenti CASE possono essere facilmente modificate. Pertanto, è necessario compiere sforzi per migliorare l'accettabilità del sistema mediante prove e modifiche adeguate di moduli e schermi.

4. Modulo Applicazioni:

Questo modulo estende i sottosistemi già identificati nel modulo aziendale. Per ciascun sottosistema identificato nel diagramma della struttura, in questo modulo sono definite procedure di elaborazione dettagliate.

In altre parole, il modulo dell'applicazione riguarda principalmente i processi coinvolti nella conversione dei dati di input in valori che devono formare parte dei report definiti nel modulo di interfaccia. Si può notare che solo quei processi devono essere definiti così

(a) Modificare i valori nei database, o

(b) Non sono parti del database ma sono richieste nei report definiti nel modulo di interfaccia.

È possibile accedere ai valori già esistenti nel database utilizzando il linguaggio di query DBMS secondo le esigenze degli utenti senza sviluppo di programmi per questo scopo. Pertanto, il compito del modulo applicativo viene ridotto dal lavoro già eseguito nella progettazione del database e nella progettazione dello schermo.

Diagramma di flusso dei dati:

Il ruolo del manager in questo modulo è fondamentalmente l'identificazione della procedura di elaborazione di base. Gli algoritmi dettagliati sono generalmente definiti e documentati dal sistema informativo professionale, ovviamente, con l'aiuto attivo del manager.

Lo strumento utilizzato per esprimere i processi da eseguire per convertire i dati di input in output è il Data Flow Diagram (DFD). Descrive il flusso di dati. Definisce cosa deve essere fatto e ignora come deve essere fatto o come è stato fatto prima. Questo approccio consente di rimuovere i cambiamenti nel sistema e le debolezze del sistema esistente seguendo questo approccio.

Simboli DFD:

Ci sono quattro simboli base usati nei DFD. Loro sono:

(i) Terminator:

Terminator è una fonte esterna di flusso di dati o sink esterno di dati. È un'entità esterna o un oggetto come cliente, venditore, azionisti, ecc. Poiché i terminatori sono entità esterne, la comunicazione tra i terminatori è esclusa dal sistema. Il terminatore è simboleggiato da un rettangolo (generalmente ombreggiato) e l'etichetta è posizionata nel rettangolo.

(ii) Flusso di dati:

Il flusso di dati contiene una serie di dati relativi all'evento che viene avviato dal terminatore. È simboleggiato con una freccia in DFD e la direzione del flusso è indicata dalla direzione della freccia. Le frecce sono, generalmente, etichettate a meno che non siano dirette ao da file di dati. Come sottolineato in precedenza, i flussi di dati tra due terminatori non sono inclusi in DFD e, quindi, i dati non possono fluire direttamente tra due terminatori.

(iii) Processo:

Il processo trasforma i dati in entrata per il reindirizzamento verso l'archivio dati o il terminatore. È simboleggiato da un rettangolo con angoli arrotondati o un cerchio. È etichettato con un verbo, ovviamente.

(iv) Archivio dati:

I file sono gli archivi di dati nei sistemi di informazione e sono rappresentati nei DFD sotto forma di rettangoli aperti. Generalmente, corrispondono a tabelle in database. Una vista parziale del diagramma di flusso dei dati per l'elaborazione degli ordini di vendita è presentata in Fig. 8.7.

Si può notare che sono in uso anche alcuni simboli supplementari e piccole variazioni nei simboli che rappresentano i vari componenti del DFD. I simboli sopra riportati sono quelli più comunemente utilizzati e sono conformi alla convenzione grafica proposta da Gane e Sarson.

Molte volte, un manager trova il disegno della DFD un'esperienza molto difficile e frustrante. Ogni volta che si disegna un DFD, si scopre di aver ignorato uno o l'altro aspetto del flusso di dati. Fortunatamente, gli strumenti CASE disponibili dispongono di funzionalità per la creazione e la modifica di DFD. Tuttavia, i principianti sono invitati a seguire i seguenti passi per superare questo problema:

(a) Identificare tutti i flussi di dati di input e i flussi di dati di output separatamente insieme ai terminatori, mettendo i flussi di dati di input sul lato sinistro e il flusso di dati di output sulla destra.

(b) Etichettare i terminatori utilizzando nomi di flusso di dati o nomi di aggettivi.

(c) Identificare i processi in avanti dai flussi di dati di input e viceversa dai flussi di dati di output finché non si incontrano nel mezzo.

(d) Etichettare i processi usando i nomi dei verbi.

Un manager deve essere preparato a ridisegnare il DFD perché molte volte i flussi di dati diventano chiari al gestore solo dopo aver disegnato DFD. Il coinvolgimento dell'utente in questa fase è molto utile non solo per ridurre lo sforzo da parte del gestore ma anche per migliorare il DFD.

Test del DFD:

Si suggerisce che il DFD deve essere accuratamente testato prima che sia finalizzato. Di seguito sono riportati alcuni errori comuni nella progettazione di DFD:

un. L'etichetta del terminatore può essere il nome di una persona o un'impresa al posto della classe. Ad esempio, un terminatore può essere etichettato come M / s. BR Ltd. invece di unico fornitore. Un altro errore potrebbe essere che il vettore viene messo come terminatore anziché l'entità esterna direttamente associata al flusso di dati.

b. I dati possono fluire direttamente da un terminatore a un altro terminatore.

c. Nessun flusso di dati può essere indicato ao da un processo.

d. Il flusso di dati viene indicato dal terminatore a un archivio dati (file) o da un file al terminatore o tra due file senza elaborazione.

e. I processi sono etichettati come oggetti, come la fattura o un nome come l'addetto alla prenotazione.

Dopo che i DFD sono stati disegnati per ciascun sottosistema, i dettagli di elaborazione futuri possono essere tracciati e descritti in inglese strutturato (codici psedo). Questi codici psedo vengono in seguito utilizzati per la codifica delle applicazioni. Il ruolo del manager in questo processo è limitato solo ad aiutare i sistemi informatici a identificare e comprendere gli algoritmi coinvolti nell'elaborazione.

5. Modulo di attuazione:

Questo modulo si occupa principalmente di test del sistema, formazione degli utenti e installazione del sistema.

Test del sistema:

Il test di vari moduli viene eseguito in varie fasi del processo di sviluppo. La regola d'oro da tenere a mente durante i test è che il test dovrebbe essere fatto al fine di identificare i modi in cui il sistema rischia di fallire. Non dovrebbe essere con l'obiettivo di dimostrare che il sistema funzionerà secondo le specifiche di progettazione. Il test del sistema è il processo di ricerca di risposte a due domande fondamentali:

1. Se il sistema informativo serve alle esigenze di informazione dell'impresa? Il processo che cerca di rispondere a questa domanda è definito dai professionisti del sistema informativo come processo di validazione del sistema.

2. Il sistema di informazione funziona correttamente? Il processo di verifica cerca una risposta a questa domanda.

Poiché la natura e il livello di gravità degli errori sono diversi nelle diverse fasi dello sviluppo del sistema, i diversi test sono gestiti a diversi moduli e al sistema nel suo insieme.

Test unitario:

I test usati a livello di modulo possono essere chiamati unit test. Questi test vengono eseguiti per rilevare errori in interfacce, database, operazioni aritmetiche e logica di controllo. Esse vengono eseguite eseguendo un modulo del sistema di informazione su dati di prova appositamente progettati per verificare se il sistema:

un. Accetta dati di tipo errato (ad es. Accetta valori numerici per nome);

b. Accetta da dati di intervallo validi (ad esempio accetta data con mese superiore a 12);

c. Provoca il salto non corretto da una procedura a un'altra procedura.

Test di sistema:

Poiché i test unitari sono condotti in isolamento, è essenziale condurre test di integrazione per verificare se queste unità funzionano correttamente o meno come gruppo. A causa delle diversità di natura degli errori, è necessario seguire diverse strategie di test per verificare la validità e verificare il sistema. Fertucksuggests tre strategie per testare il sistema informativo:

(a) Verifica della scatola chiara:

In questa strategia, i test sono progettati per stabilire se le procedure seguite per l'elaborazione corrispondono ai requisiti dell'applicazione. Ciò può essere ottenuto con l'aiuto di revisioni da parte di altri professionisti del sistema informativo non direttamente associati alla fase di sviluppo.

In alternativa, può essere utilizzato il metodo strutturato strutturato. In questo metodo, un gruppo di persone rivede le procedure, esaminando prima le parti soggette a errori e identificando le correzioni che devono essere apportate. Quindi, i membri del gruppo valutano l'output che il sistema offrirà per un determinato tipo di input e verificherà se l'output del sistema è corretto o meno.

(b) Test della scatola nera:

In questa strategia, il sistema viene testato per dati o dati non validi che possono causare errori nel funzionamento del sistema. L'output viene controllato per stabilire se si sono verificati errori. Ad esempio, i dati possono contenere valori negativi per quantità ordinate o valori frazionari per una variabile che può assumere solo un valore intero.

(c) Test di caselle di ticchettio:

Questa strategia presuppone che non sia mai possibile fornire un sistema di informazione totalmente privo di errori. Pertanto, dopo tutti i test e le modifiche, è necessario stimare il numero di errori ancora presenti nel sistema. Per stimare questo numero, alcuni errori potrebbero essere introdotti deliberatamente nel sistema. Quindi i test vengono nuovamente condotti per rilevare errori.

La proporzione di errori introdotti rilevati viene presa come stima della proporzione di errori reali rilevati durante i test precedenti. Pertanto, se il 90% degli errori introdotti sono stati rilevati durante il test del ticking box, mentre in totale sono stati rilevati 450 errori durante i test clear box e black box, significa che 50 errori reali continuano a non essere rilevati nel sistema.

Installazione:

L'installazione è un processo di sostituzione del vecchio sistema con un nuovo sistema. In generale, ci sono quattro approcci all'installazione. L'installazione "a freddo" viene eseguita quando il vecchio sistema viene immediatamente interrotto e sostituito da un nuovo sistema.

Tale installazione ha il vantaggio di un aggiustamento psicologico più rapido con il fatto che il nuovo sistema deve essere utilizzato. Tuttavia, tale approccio potrebbe non essere adatto se i vecchi dati del sistema precedente sono preziosi o se il nuovo sistema ha qualche problema. Per l'installazione di sistemi di informazione contabile, questo approccio non è stato trovato accettabile. Gli approcci alternativi includono:

(a) Installazione pilota:

Un sistema può essere installato per essere utilizzato solo da un gruppo di utenti rappresentativi selezionati che testa il sistema utilizzando effettivamente. Altri utenti continuano a utilizzare il vecchio sistema. Quando i problemi del sistema vengono risolti, anche altri utenti iniziano a utilizzare il sistema. Questo approccio non è molto diffuso anche per i sistemi informativi contabili poiché l'intero database contabile deve essere aggiornato prima che possa essere utilizzato dagli utenti.

I requisiti di informazione dell'utente superano i confini del dipartimento e delle divisioni nell'organigramma. Tuttavia, questo approccio può essere utilizzato per entità contabili complete come filiali, uffici regionali, ecc. Pertanto, un sistema di informazioni contabili può essere utilizzato da filiali selezionate. Una volta che sono stati trovati privi di errori, possono essere utilizzati anche da altre filiali.

(b) Installazione in fase di installazione:

Con questo approccio, l'installazione avviene in fasi. Queste fasi sono componenti indipendenti del sistema informativo. Quindi, il ciclo di vita delle entrate di un sistema di informazione contabile può essere installato per la prima volta e altri cicli di vita possono susseguirsi uno dopo l'altro. Questo approccio aiuta a concentrarsi su una parte selezionata del sistema. Aiuta a migliorare l'accettabilità del sistema tra gli utenti perché consente all'utente di affrontare facilmente le modifiche.

(c) Installazione parallela:

L'installazione parallela significa eseguire contemporaneamente sia il vecchio che il nuovo sistema per un certo periodo finché non viene dimostrata l'utilità del nuovo sistema. Questo metodo è più popolare per il sistema di informazioni contabili perché questo è il più sicuro di tutti gli altri metodi. L'unica difficoltà, qui, è il costo della corsa parallela e la tendenza ad estendere il periodo di corsa parallela da coloro che resistono al cambiamento.

Revisione post implementazione:

Ogni sistema deve essere rivisto al termine dell'implementazione. Tale revisione non solo aiuta a identificare i punti deboli del sistema, ma prepara anche un programma di modifiche per il futuro. È, infatti, un processo di apprendimento. La verifica del sistema può anche essere condotta per esaminare il successo del sistema, in termini di costi, tempi di consegna, completezza e qualità.