Entwicklung eines Accounting Information Systems: Unternehmens-, Datenbank- und Schnittstellenmodule
Entwicklung eines Accounting Information Systems: Unternehmens-, Datenbank- und Schnittstellenmodule!
Es gibt eine Reihe von Buchhaltungssoftwarepaketen, die eine Vielzahl von Funktionen bieten. Sie kosten viel weniger als die Kosten für eine kundenspezifische Buchhaltungssoftware. Diese Softwarepakete bieten jedoch nur die Struktur für Abrechnungsinformationssysteme. Sie reduzieren allenfalls den Programmieraufwand für rechnungslegende Informationssysteme.
Bild mit freundlicher Genehmigung: bestsmallbizhelp.com/wp-content/uploads/2011/07/1018910261.jpg
Die Entwicklung von rechnungslegungsbezogenen Informationssystemen ist weit mehr als die Software für die Buchung und die Berichterstellung. Dazu gehört auch die Festlegung von Verfahren zur Erfassung und Verteilung von Daten sowie die Analyse von Buchhaltungsinformationen.
Die Entwicklung eines rechnungslegungsbezogenen Informationssystems wird unter besonderer Berücksichtigung der Anforderungen eines mittelständischen bis großen Wirtschaftsunternehmens erläutert. Diese Schritte sind jedoch für die meisten anderen Informationssysteme in einem Unternehmen gleich.
1. Enterprise Modul:
Das Enterprise-Modul für die Entwicklung von Informationssystemen umfasst die Identifizierung grundlegender Entitäten und ihrer Wechselbeziehungen, die Identifizierung grundlegender Aktivitäten und die Umgruppierung dieser Aktivitäten in Untersysteme. Anschließend werden die Prioritäten auf Basis einer Kosten-Nutzen-Analyse für das Unternehmen festgelegt.
Identifizierende Entitäten:
In einem Unternehmen gibt es eine große Anzahl von Entitäten, und die Liste ist so vielfältig wie die Geschäftsaktivitäten. In dieser Phase besteht jedoch das Hauptanliegen darin, die breiten Entitäten zu identifizieren, wobei jede von ihnen eine Gruppe von Elementarentitäten enthält. Kerner 5 weist auf sechs grundlegende Einheiten eines Unternehmens hin.
Sie sind Kunden, Produkte, Verkäufer, Personal, Einrichtungen und Geld. In einem Rechnungslegungsinformationssystem gibt es drei grundlegende Einheiten, nämlich Transaktionen, Konto und Bearbeitungszeitraum. Die Wechselbeziehungen zwischen diesen Entitäten können mit Hilfe der ER-Diagramme ausgedrückt werden (siehe Abb. 8.2).
Die Transaktionen müssen unterschiedlicher Art sein, z. B. Einnahmen, Zahlungen, Verkäufe, Erwerb, Erwerb von Vermögenswerten oder Rückzahlung von Verbindlichkeiten usw., und jede davon kann als untergeordnetes Unternehmen bezeichnet werden. In ähnlicher Weise können Konten unterschiedlicher Art sein, z. B. Vermögenswerte, Verbindlichkeiten, Einnahmen und Ausgaben.
Jeder dieser Leiter kann untergeordnete Einheiten wie Anlagevermögen und Umlaufvermögen haben. Diese Entitäten können weiter in noch untergeordnete Entitäten wie Grundstücke und Gebäude, Anlagen und Maschinen usw. unterteilt werden. Zu diesem Zeitpunkt müssen jedoch die umfassenden Entitäten identifiziert werden. Die Details werden zum Zeitpunkt des Entwurfs der Datenbanken ausgearbeitet.
Die Entitäten werden im Hinblick auf und im Hinblick auf die Definition des Umfangs und des Fokus des Informationssystems identifiziert. Wenn das Informationssystem beispielsweise als strategisches Informationssystem betrachtet wird, werden die allgemeinen Einheiten anhand der strategischen Stoßrichtungen identifiziert, die das Unternehmen seinen Aktivitäten mit Hilfe des Informationssystems geben möchte.
Diese Bereiche könnten Kostenminimierung, Kundenservice, Produktdifferenzierung und strategische Allianzen sein. Die grundlegenden Einheiten in einem solchen Fall wären Kunden, Vertriebskanäle, konkurrierende Unternehmen, Produkte usw.
Aktivitätsanalyse:
Ein weiterer wichtiger Aspekt des Unternehmensmoduls ist die Identifizierung der mit den Entitäten verbundenen Aktivitäten. Diese Aktivitäten werden in den ER-Diagrammen grob in Form von Beziehungen identifiziert. Details werden jedoch mit Hilfe der Aktivitätsanalyse erhalten. Die bestehende Organisationsstruktur ist eine wichtige Informationsquelle über die umfassenden Aktivitäten des Unternehmens.
Um jedoch Informationssysteme zu entwickeln, die unabhängig von der aktuellen Organisationsstruktur sind, ist es unerlässlich, die Aktivitätsanalyse auf den bereits oben genannten Basiseinheiten zu gründen. Die nächste Stufe der Aktivitätsanalyse umfasst die Identifizierung der Lebenszyklusaktivitäten. Wenn "Transaktionen" eine der grundlegenden Einheiten in einem Rechnungslegungsinformationssystem sind, gibt es vier umfassende Lebenszyklusaktivitäten, nämlich:
1. Lebenszyklus des Einkaufs
2. Lebenszyklus der Produktion
3. Lebenszyklus der Einnahmen
4. Lebenszyklus der Investitionen
In ähnlicher Weise hat der Bearbeitungszeitraum zwei grundlegende Lebenszyklusaktivitäten, nämlich:
ein. Lebenszyklus planen und steuern
b. Lebenszyklus der internen und externen Berichterstattung
Diese Lebenszyklusaktivitäten sind laufende Aktivitäten und werden kontinuierlich durchgeführt. Jede dieser Aktivitäten kann sequentiell mit einigen anderen Aktivitäten verbunden sein. Die dritte Ebene der Aktivitätsanalyse umfasst die Aufteilung der Lebenszyklusaktivitäten in Funktionen.
Zum Beispiel muss jede Art von Transaktion initiiert und erkannt werden. Dann müssen die Daten bezüglich der Transaktion erfasst, für die zukünftige Klassifizierung codiert, klassifiziert, zusammengefasst und gemeldet werden. Diese Funktionen sind für verschiedene Arten von Transaktionen unterschiedlich auszuführen. Die Definition der Funktionen konzentriert sich nur auf die Aktivitäten, die Informationen in der Datenbank des Unternehmens erstellen, aktualisieren oder verwenden.
Auf dieser Ebene der Aktivitätsanalyse sind die Aktivitäten in sich abgeschlossen, haben klar definierte Start- und Endereignisse oder -knoten und eine identifizierbare Person oder eine Gruppe von Personen, die für die Ausführung der Funktion verantwortlich sind.
Diese Funktionen können dann in Unterfunktionen unterteilt werden, bis die Funktionen spezifisch genug sind, um das Modul für Computerprogramme zu definieren. Die Aufteilung der Lebenszyklusaktivitäten in Funktionen und Unterfunktionen hilft dabei, Funktionen zu identifizieren, die sich in mehr als einer Lebenszyklusaktivität wiederholen.
Zum Beispiel kann die Funktion der Klassifizierung erfasster Daten in Einkaufs- und Marketinglebenszyklen durchgeführt werden. Diese Aktivitätsanalyse hilft bei der Ermittlung von Möglichkeiten zur Verbesserung des vorhandenen Designs durch:
1. Beseitigung der redundanten Funktionen
2. Kombinieren der duplizierten Funktionen
3. Vereinfachung und Verbesserung der Verarbeitungsmethoden
Die Redundanz kann durch sorgfältige Analyse der Aktivitäten identifiziert werden. Zu den Aktivitäten, die wahrscheinlich Möglichkeiten zur Verbesserung der Verarbeitung bieten, gehören Aktivitäten:
ein. Das wird auch anderswo durchgeführt
b. Das kann mit anderen Aktivitäten kombiniert werden
c. Das kann auch von einer anderen Person gehandhabt werden
d. Dies kann in einer anderen Phase des Lebenszyklus durchgeführt werden, die dem Produkt oder der Dienstleistung des Informationssystems keinen Wert hinzufügt.
Vorsicht ist hier geboten, dass nicht alle Entlassungen schlecht sind. Tatsächlich kann sich eine gewisse Redundanz oder Duplikation absichtlich in das System einschleichen. Dies kann gemacht werden, um die Leistung und Zuverlässigkeit des Systems zu verbessern.
Beispielsweise kann ein Teil der Duplizierung erforderlich sein, um die Vereinfachung der Verfahren sicherzustellen und die Verarbeitungsgeschwindigkeit zu verbessern. Die Beseitigung der Redundanz kann dazu führen, dass alle Eier in einen Korb gelegt werden, was die Zuverlässigkeit beeinträchtigen kann. Das Risiko unerwarteter Auswirkungen und geringe Erträge aus der vorgeschlagenen neuen Methode oder dem neuen Verfahren sind weitere Faktoren, die Aufmerksamkeit erfordern, bevor Änderungen im Informationssystem vorgeschlagen werden.
Gruppieren von Aktivitäten in Subsystemen:
Nachdem die Aktivitäten mit dem oben angewendeten Top-Down-Ansatz definiert wurden, werden sie zu Subsystemen zusammengefasst. Eine wichtige Entscheidung, die in dieser Phase zu treffen ist, bezieht sich auf die Grundlage der Gruppierung. Es gibt möglicherweise kein einziges objektives Kriterium für die Entscheidung, zu welchem Teilsystem eine Aktivität gehört.
Die vorliegende Organisationsstruktur kann eine der Grundlagen für die Gruppierung von Aktivitäten bieten. Die vorliegende Organisationsstruktur kann jedoch Änderungen unterliegen und die Nützlichkeit des Informationssystems kann verloren gehen.
Um die Aktivitäten in einem Subsystem zu gruppieren, erhalten wir Hilfe aus der Organisationstheorie. Eine der wesentlichen Eigenschaften einer guten Organisationsstruktur besteht darin, dass sie die Koordinierung der Aktivitäten erleichtern soll.
Ein wirksames Kommunikationssystem ist eine wesentliche Voraussetzung für eine bessere Koordinierung. Es ist daher wichtig, Aktivitäten so zu gruppieren, dass die Kommunikation innerhalb der Gruppe erleichtert wird und die Notwendigkeit einer Kommunikation zwischen Gruppen minimiert wird.
Zum Darstellen und Dokumentieren der Gruppierung von Aktivitäten in Subsystemen werden Strukturdiagramme oder hierarchische Blockdiagramme verwendet. Abbildung 8.3 zeigt ein Strukturdiagramm mit den Komponenten des Umsatzzyklus.
Ähnliche Strukturdiagramme können für andere Aktivitätscluster erstellt werden, und schließlich sind diese Untersysteme miteinander integriert und liefern die Bausteine für ein Abrechnungsinformationssystem.
Die durch Clusterung von Aktivitäten identifizierten Untersysteme sind ernsthafte Konkurrenten, weil sie Entitäten in der Organisationsstruktur sind. Der Vorteil der Clustering-Methode zur Gruppierung von Aktivitäten besteht darin, dass die Gruppierung auf Funktionen und Ressourcen basiert und nicht auf geografischen Regionen.
Ein solches Clustering auf der Basis von Funktionen gewährleistet die Homogenität unter den Mitgliedern der Personengruppe, die jedem der Subsysteme zugeordnet ist. Die Auswirkungen der Organisation des Informationssystems auf die Organisationsstruktur sind nicht ungewöhnlich.
Die Einführung von Informationssystemen wurde häufig von Änderungen in den Organisationsstrukturen begleitet, da neue Informationssysteme die Art und Weise ändern, in der die Mitarbeiter in einer Organisation arbeiten.
Umso wichtiger ist es, dass Informationssystem-Designer in aktiver Verbindung mit den Organisationsentwicklern arbeiten, während Aktivitäten in Clustern und Subsystemen gruppiert werden. Dies stellt nicht nur sicher, dass die neue Struktur pragmatischer ist, sondern auch für die Menschen akzeptabler ist. In solchen Fällen ist der Übergang vom alten zum neuen System weniger schmerzhaft und weniger kostspielig.
Prioritäten setzen:
Nachdem die Teilsysteme identifiziert und als Ganzes integriert wurden, müssen die Prioritäten unter den verschiedenen Teilsystemen und Merkmalen in jedem System festgelegt werden. Das Informationssystem würde die Bereitstellung finanzieller Ressourcen erfordern.
Darüber hinaus können implizite Kosten des neuen Systems im Hinblick auf notwendige Änderungen im Arbeitsablauf entstehen. Daher ist es wichtig, die Vor- und Nachteile jedes Teilsystems und jedes Teilsystems zu wägen, bevor sie konzipiert und implementiert werden.
Jedes Teilsystem wird auf der Grundlage gut definierter Bewertungskriterien bewertet, die in Bezug auf die kritischen Erfolgsfaktoren (CSF) definiert werden. Diese Faktoren wurden bereits in Abschnitt 8.2 identifiziert.
Die andere Methode ist das Brainstorming, bei dem die relevanten Personen in der Organisation zusammenkommen, um die Faktoren zu ermitteln, die bei der Festlegung von Prioritäten berücksichtigt werden müssen. Der freie Ideenfluss wird in der ersten Phase gefördert.
Das zugrunde liegende Prinzip ist hier, dass zu diesem Zeitpunkt keine Idee dumm oder irrelevant ist. In der zweiten Phase beginnt der Ausscheidungsprozess, und nach Erörterung sind die Vorschläge abgeschlossen.
Sobald die Liste der Faktoren abgeschlossen ist, werden relative Gewichtungen zugewiesen und die Funktion eines Kriteriums wird definiert, um jede Komponente des vorgeschlagenen Abrechnungsinformationssystems auszuwerten.
2. Datenbankmodul:
Das Rechnungsinformationssystem verarbeitet große Datenmengen. Die Verwaltung der Daten ist daher eine der wichtigsten Überlegungen im Entwicklungsprozess. Es gibt zwei grundlegende Ansätze für das Datendesign, nämlich:
ein. Der traditionelle, anwendungsorientierte Ansatz und
b. Der Datenbankansatz
Traditioneller Ansatz:
Der traditionelle Ansatz des Datendesigns ist anwendungsorientiert in dem Sinne, dass für jede Anwendung ein separater Satz von Datendateien gemäß den Anforderungen generiert wird. Mit anderen Worten, die Datendateien sind für eine bestimmte Anwendung bestimmt und befinden sich in gewisser Weise im Besitz der Anwendung.
Beispielsweise muss eine Debitorenbuchhaltung die Kundenstammdatendatei, eine Verkaufstransaktionsdatei und einen Beleg aus der Transaktionsdatei der Kunden enthalten. Diese Dateien werden nur für die Debitorenanwendung verwendet.
Dieser Ansatz ist aufgrund seiner Einfachheit für kleinere Abrechnungsinformationssysteme geeignet. Da das Informationssystem jedoch in Bezug auf das Datenvolumen und die Komplexität der Analyse wächst, entstehen auch einige Probleme.
Das grundlegende Problem des traditionellen Ansatzes besteht darin, dass die Anwendungsprogramme von den von ihnen verwendeten und manipulierten Datendateien abhängen. Folglich erfordert jede Änderung in der Datendatei (hinsichtlich des Hinzufügens oder Löschens eines Datenelements) Änderungen in allen Programmen, die die Datendatei verwenden.
Durch diese Datenabhängigkeit werden Änderungen in Datendateien verhindert, die zu Inflexibilität führen. In Ermangelung eines Werkzeugs zum Durchführen von Datenverwaltungsaktivitäten vom Typ Routine in den Daten sind solche Einrichtungen in die Programme aufzunehmen, die die Datendatei verwenden. Dies macht das Programm komplizierter. Ein anderes Problem bezieht sich auf die Erfüllung der Ad-hoc-Abfrage.
Für unerwartete Abfragen müssen spezielle Programme geschrieben werden. Solche Spezialprogramme brauchen Zeit, um sich zu entwickeln und nur einmal zu verwenden, und sind daher teuer. Bei der Aufzeichnung von Datenelementen gibt es viele Duplikate.
Zum Beispiel können die Datenelemente, wie Kundenname, Rechnungsnummer, Preis usw., in Transaktionsdateien für eine Anwendung zur Verarbeitung von Kundenaufträgen sowie in der Debitorenanwendung enthalten sein. Dies führt zu Redundanz in Daten.
Die Datenredundanz führt zu einer ineffizienten Verwendung von Speichermedien. Dies wirkt sich auch auf die Qualität der Daten aus, da die Aktualisierung eines bestimmten Datenelements möglicherweise nicht in allen Dateien erfolgt, in denen das Datenelement gespeichert ist.
Datenbankansatz:
Der moderne Ansatz des Datendesigns ist der Datenbankansatz. Dieser Ansatz basiert auf der Annahme, dass mehrere Anwendungen Datensätze benötigen, die viele Gemeinsamkeiten aufweisen. Es ist daher besser, über ein gemeinsames Datenlager zu verfügen, das die Datenanforderungen jeder Anwendung im Informationssystem erfüllt.
Das gemeinsame Repository wird Datenbank genannt und wird von einem Verwaltungssystem verwaltet, das als Database Management System (DBMS) bezeichnet wird. Das DBMS ist eine Software, die speziell für die Verwaltung der Daten in Datenbanken gemäß den Anforderungen von Anwendungsprogrammen sowie von Daten, die direkt von Benutzern stammen, entwickelt wurde. Der konzeptionelle Aufbau der Datenbankumgebung wird mit Hilfe von Abb. 8.5 dargestellt.
Der Datenbankansatz kümmert sich um die Probleme des Anwendungsansatzes. Sie gewährleistet die Unabhängigkeit der Daten, da das DBMS für den Datenfluss von der Datenbank zu Anwendungsprogrammen sorgt. Die Benutzeranwendung muss sich nicht um den Ort der Daten in der Datenbank kümmern. Ein Datenwörterbuch wird gepflegt, und Daten können mit den im Datenwörterbuch angegebenen Wörtern aufgerufen werden.
Der Datenbankansatz verringert auch die Größe und Komplexität der Anwendungsprogramme, da die routinemäßige Art von Datenverarbeitungsvorgängen, beispielsweise das Sortieren, durch das DBMS erfolgt. Das DBMS wird auch zur Erfüllung der Anforderungen einer Ad-hoc-Abfrage verwendet. Das DBMS verwendet Structured Query Language (SQL) als Sprache für die Kommunikation zwischen dem Benutzer und der Datenbank.
Die Sprache ist sehr einfach und ziemlich nahe an Englisch. Dadurch wird sichergestellt, dass der Benutzer bei Bedarf Informationen aus der Datenbank abrufen kann. Die Anzahl der Schulungen, die Manager für Ad-hoc-Abfragen benötigen, ist gering, und wenige Schulungsstunden können die elementaren Fähigkeiten für die Verwendung der Sprache vermitteln. Der wichtigste Vorteil des Datenbankansatzes ist möglicherweise die Verringerung der Redundanz in Datenbanken.
Es gibt viele Modelle, die häufig beim Entwurf von Datenbanken verwendet werden. Der moderne Ansatz ist jedoch, dem ER-Modell des Datenbankdesigns zu folgen. Bei diesem Ansatz handelt es sich um einen Top-Down-Ansatz. Die zuvor im Enterprise-Modul dargestellten ER-Diagramme werden zum Ausgangspunkt.
Für jede Entität und Beziehung werden Attribute identifiziert und in den erweiterten ER-Diagrammen (EER-Diagrammen) dokumentiert. In einem Buchhaltungsinformationssystem kann die EER für jede Entität (Transaktion und Konten) gezeichnet werden, und die Beziehung (Wirkung) für die Transaktionskonten wird im ER-Diagramm dargestellt. Zum Beispiel können für eine Verkaufstransaktion Attribute angegeben und dokumentiert werden, wie in Abb. 8.6 gezeigt.
Diese Attribute werden zu den Datenelementen (Feldern) in einem Datensatz in der Datendatei für jede Entität (in diesem Fall Verkaufsdatei). In ähnlicher Weise werden für andere Entitäten und Beziehungen solche Extended ER (EER) -Diagramme gezeichnet.
Sobald diese Attribute identifiziert wurden, ist es wahrscheinlich, dass einige der Attribute in verschiedenen EER-Diagrammen verwendet werden. Um zu vermeiden, dass solche gemeinsamen Attribute doppelt vorhanden sind, wird eine Normalisierung der Daten vorgenommen.
3. Schnittstellenmodul:
Ein Schnittstellenmodul definiert die Quellen von Datenelementen sowie die Formate der Eingabe- / Ausgabe- und Dialogbildschirme, die im System verwendet werden sollen. Es definiert auch die Berichtsformate und die Bildschirme für die Navigation von einem Teil des Informationssystems zum anderen.
Das Modul befasst sich mit anderen Worten mit der Definition der Schnittstelle zwischen Benutzer und Maschine. Die Bedeutung des Schnittstellenmoduls hat aufgrund der zunehmenden Kommunikation zwischen Benutzer- und Informationssystemen zugenommen.
Sowohl die Dateneingabe als auch die Datenabfrage sind interaktiv geworden. In vielen Fällen werden Eingabeformulare aus dem Prozess entfernt und die Dateneingabe erfolgt direkt. Die sich ändernden Anforderungen der Datenabfrage machen viele Berichtsformulare zu starr. Interaktive Berichtsbildschirme bieten größere Flexibilität bei der Datenabfrage und ermöglichen benutzerdefinierte Berichtsformate zum Anzeigen und Drucken.
Eingabemasken:
Die Eingabemasken werden im Hinblick auf den natürlichen Ablauf der Geschäftstätigkeit definiert. Daher hängen sie in erster Linie von den Formularen ab, mit denen die Daten manuell erfasst werden, wenn sie vom Unternehmen zum ersten Mal empfangen werden. Diese Formulare können in einem Buchhaltungsinformationssystem Rechnungen, Bestellungen, Verkaufsaufträge, Spesenbelege usw. enthalten.
Daher werden im Schnittstellenmodul auch Formulare überprüft. Umgestaltete und Eingabebildschirme werden anhand der vom Unternehmen verwendeten Formulare definiert. In einem Buchhaltungsinformationssystem muss man beim Bildschirmdesign sorgfältiger vorgehen.
Eine geringfügige Verbesserung des Eingabebildschirms, die die Dateneingabe spart, kann zu erheblichen Einsparungen führen, da der Dateneingabebildschirm sehr oft verwendet wird. Folgende Faktoren können bei der Gestaltung des Eingabebildschirms berücksichtigt werden:
(a) Übereinstimmung mit Formularen:
Das Eingabeformat muss mit den Eingabeformularen übereinstimmen. In manchen Fällen lohnt es sich, dasselbe Format zu verwenden, das vom Eingabeformular verwendet wird. Soweit möglich, kann sogar die Farbe des Hintergrunds des Bildschirms mit der Farbe des Eingabeformulars übereinstimmen.
(b) interaktiv:
Der Eingabebildschirm sollte interaktiv sein. Es sollte auf Fehler bei der Dateneingabe zum Zeitpunkt der Eingabe hinweisen und Korrekturen zulassen. Jedes Datenelement muss über einige Datenvalidierungsbedingungen verfügen. Jeder Verstoß gegen diese Datenvalidierungsbedingungen sollte zum Zeitpunkt der Dateneingabe automatisch hervorgehoben werden.
Beispielsweise muss ein Dateneingabebildschirm für die Erfassung einer Rechnung auf einen Fehler bei der Datumseingabe hinweisen, wenn das Datum ungültig ist. Das Datum kann ungültig sein, weil es außerhalb des Abrechnungszeitraums liegt oder der eingegebene Monat größer als zwölf ist.
(c) Konsistenz:
Die Eingabebildschirme sollten konsistent sein, um Begriffe und Positionen für bestimmte allgemeine Arten von Datenelementen zu definieren. Es hilft, die Trainingszeit zu reduzieren, da es die Bekanntheit verbessert. Beispielsweise kann das Transaktionsdatum immer in der rechten Ecke jedes Transaktionsdokuments platziert werden.
(d) Einfachheit:
Ein grundlegendes Merkmal eines guten Eingabebildschirms ist die Einfachheit. Zu viele hervorgehobene Abschnitte, das Blinken von Werten oder Attributen oder das Platzieren zu vieler Kästchen und das Unterstreichen erhöhen nur die Komplexität und Verwirrung. Manchmal werden Pieptöne verwendet, um auf Fehler bei der Dateneingabe hinzuweisen. Solche Pieptöne sollten vernünftig verwendet werden und sollten generell vermieden werden.
(e) Flexibilität:
Der Eingabebildschirm sollte für Änderungen zugänglich sein. Es sollte Benutzern erlauben, Änderungen hinsichtlich des Hinzufügens oder Löschens und Verschiebens von Datenelementen vorzunehmen. Das Verfahren zur Änderung sollte einfach sein. Heutzutage bieten die von verschiedenen Softwareherstellern erhältlichen Bildschirmgeneratoren die Funktionen, z. B. das Ziehen und Fixieren / Ablegen von Datenelementen vom Bildschirm mithilfe eines gewöhnlichen Zeigegeräts wie der Maus.
(f) Maßarbeit:
Die Bildschirme müssen für jede Benutzerkategorie maßgeschneidert sein. Dies würde unnötig lange Start- und Einreiseverfahren reduzieren.
Berichtsbildschirme:
Die Berichte können zur weiteren Analyse durch ein anderes Computerprogramm oder durch den Benutzer selbst erstellt werden. Die zur Verarbeitung durch Computerprogramme bestimmten Daten, wie Tabellenkalkulationen, statistische Pakete, Textverarbeitungsprogramme, werden in Dateien gespeichert.
Es ist besser, sie in einem Standarddatenformat zu speichern, damit sie leicht zugänglich sind. Die für Benutzer bestimmten Berichte werden normalerweise in Form von Text, Tabellen und Diagrammen aufbewahrt. Es sollte angestrebt werden, dass die Berichte zeitnah, genau, klar und kostengünstig erstellt und übermittelt werden.
Dialogfenster:
In den Dialogbildschirmen werden die Aufgaben im Informationssystem identifiziert und ausgeführt. Sie legen fest, was mit Hilfe des Informationssystems getan werden kann, wie von einer Aufgabe / Prozedur zu einer anderen navigiert wird und wie verschiedene Aufgaben ausgeführt werden, die das Informationssystem zulässt.
Diese Bildschirme sollten einfach und eindeutig sein. Die Einfachheit kann durch die Bereitstellung einer grafischen Benutzeroberfläche (GUI) und einer begrenzten Anzahl von Menüelementen auf einem Bildschirm eingeführt werden. Das Verfahren zur Navigation von einem Menü zum anderen sollte einfach, in der richtigen Reihenfolge und leicht nachvollziehbar sein. Es sollte auch Fehler bei der Ausübung von Optionen aufzeigen und zur Korrektur des Verfahrens aufgefordert werden.
CASE-Tools für die Bildschirmgestaltung:
Für das Entwerfen von Formularen, Bildschirmen und Berichten stehen verschiedene CASE-Werkzeuge zur Verfügung. Diese Werkzeuge haben den Vorteil, dass sie eine Entwurfsumgebung bieten, die selbst für einen neuen Benutzer flexibel und leicht verständlich ist.
Da diese Tools über Screen Prototyping-Funktionen verfügen, ist eine stärkere Einbindung der Benutzer in den Prozess des Screen-Designs möglich. Natürlich ermöglichen solche Tools schnelle Änderungen und verbessern die Produktivität von Programmierern, indem Codes für die endgültige Implementierung generiert werden. Dies führt zu einer Verkürzung der Entwicklungszeit.
Sobald die Formulare, Ein- / Ausgabebildschirme und Dialogbildschirme fertig sind, sollten sie getestet und entsprechend modifiziert werden. Die mit den CASE-Tools erstellten Formulare und Bildschirme können leicht geändert werden. Daher müssen Anstrengungen unternommen werden, um die Akzeptanz des Systems zu verbessern, indem Formulare und Bildschirme ordnungsgemäß getestet und geändert werden.
4. Anwendungsmodul:
Dieses Modul erweitert die bereits im Enterprise-Modul angegebenen Subsysteme. Für jedes im Strukturdiagramm angegebene Subsystem werden in diesem Modul detaillierte Verarbeitungsabläufe definiert.
Mit anderen Worten, das Anwendungsmodul befasst sich in erster Linie mit den Prozessen, die zur Umwandlung der Eingabedaten in Werte erforderlich sind, die Bestandteil der Berichte sein sollen, wie sie im Schnittstellenmodul definiert sind. Es sei darauf hingewiesen, dass nur die Prozesse definiert werden sollen, die das sind
(a) Ändern Sie die Werte in den Datenbanken oder
(b) Dies sind keine Bestandteile der Datenbank, werden aber in den im Schnittstellenmodul definierten Berichten benötigt.
Auf die bereits in der Datenbank vorhandenen Werte kann mit der DBMS-Abfragesprache je nach Anforderung der Benutzer zugegriffen werden, ohne dass hierfür Programme entwickelt werden. Somit wird die Aufgabe des Anwendungsmoduls um die bereits im Datenbank- und Bildschirmdesign bereits geleistete Arbeit reduziert.
Datenflussdiagramm:
Die Rolle des Managers in diesem Modul besteht im Wesentlichen darin, das grundlegende Verarbeitungsverfahren zu bestimmen. Die detaillierten Algorithmen werden im Allgemeinen von einem professionellen Informationssystem definiert und dokumentiert, natürlich mit aktiver Hilfe des Managers.
Das Werkzeug zum Ausdrücken der Prozesse, die zur Umwandlung der Eingabedaten in eine Ausgabe ausgeführt werden sollen, ist das Datenflussdiagramm (DFD). Es beschreibt den Datenfluss. Es definiert, was zu tun ist, und ignoriert, wie es gemacht werden soll oder wie es früher gemacht wurde. Dieser Ansatz erlaubt Änderungen im System und Schwachstellen des bestehenden Systems können nach diesem Ansatz behoben werden.
DFD-Symbole:
In DFDs werden vier grundlegende Symbole verwendet. Sie sind:
(i) Terminator:
Terminator ist eine externe Quelle für Datenfluss oder externe Senke von Daten. Hierbei handelt es sich um eine externe Einheit oder ein Objekt wie Kunde, Verkäufer, Anteilseigner usw. Da die Terminatoren externe Einheiten sind, ist die Kommunikation zwischen den Terminatoren vom System ausgeschlossen. Der Abschluss wird durch ein Rechteck symbolisiert (im Allgemeinen schattiert), und die Beschriftung wird im Rechteck platziert.
(ii) Datenfluss:
Der Datenfluss enthält eine Reihe von Datenelementen bezüglich des vom Terminator initiierten Ereignisses. Sie wird in DFD durch einen Pfeil symbolisiert und die Flussrichtung wird durch die Pfeilrichtung angezeigt. Die Pfeile sind im Allgemeinen gekennzeichnet, es sei denn, sie werden zu oder von Datendateien geleitet. Wie bereits erwähnt, sind Datenflüsse zwischen zwei Terminatoren nicht in DFD enthalten, sodass Daten nicht direkt zwischen zwei Terminatoren fließen können.
(iii) Prozess:
Der Prozess wandelt die eingehenden Daten für die Umleitung in den Datenspeicher oder Terminator um. Sie wird durch ein Rechteck mit abgerundeten Ecken oder einen Kreis symbolisiert. Es ist natürlich mit einem Verb beschriftet.
(iv) Datenspeicher:
Dateien sind die Datenspeicher in Informationssystemen und werden in DFDs in Form von offenen Rechtecken dargestellt. Im Allgemeinen entsprechen sie Tabellen in Datenbanken. Eine Teilansicht des Datenflussdiagramms für die Kundenauftragsabwicklung ist in Abb. 8.7 dargestellt.
Es sei darauf hingewiesen, dass einige zusätzliche Symbole und geringfügige Variationen in Symbolen, die verschiedene Komponenten von DFD repräsentieren, ebenfalls verwendet werden. Die oben genannten Symbole sind die am häufigsten verwendeten und entsprechen der von Gane und Sarson vorgeschlagenen grafischen Konvention.
Ein Manager findet das Zeichnen von DFD oft sehr schwierig und frustrierend. Jedes Mal, wenn man eine DFD zeichnet, hat man den einen oder anderen Aspekt des Datenflusses ignoriert. Glücklicherweise verfügen die verfügbaren CASE-Tools über Möglichkeiten zum Erstellen und Ändern von DFDs. Anfängern wird jedoch empfohlen, die folgenden Schritte zu ergreifen, um dieses Problem zu beheben:
(a) Identifizieren Sie alle Eingangsdatenflüsse und Ausgangsdatenflüsse separat mit Abschlusszeichen, wodurch die Eingangsdatenflüsse auf der linken Seite und der Ausgangsdatenfluss auf der rechten Seite angezeigt werden.
(b) Beschriften Sie die Terminatoren mit Datenfluss-Nomen oder Adjektivnamen.
(c) Identifizieren Sie Prozesse vorwärts von Eingangsdatenflüssen und rückwärts von Ausgangsdatenflüssen, bis sie sich in der Mitte treffen.
(d) Beschriften Sie die Prozesse mit Verbnamen.
Ein Manager muss darauf vorbereitet sein, das DFD neu zu zeichnen, da die Datenflüsse dem Manager oft erst nach dem Zeichnen des DFD klar werden. Die Einbindung der Benutzer in dieser Phase ist sehr nützlich, nicht nur um den Aufwand des Managers zu reduzieren, sondern auch, um den DFD zu verbessern.
Test von DFD:
Es wird empfohlen, den DFD vor dem Abschluss gründlich zu testen. Im Folgenden sind einige der häufigsten Fehler im DFD-Design aufgeführt:
ein. Das Terminator-Label kann anstelle der Klasse der Name einer Person oder eines Unternehmens sein. Beispielsweise kann ein Terminator als M / s gekennzeichnet sein. BR Ltd. anstelle des Alleinverkäufers. Ein weiterer Fehler könnte darin bestehen, dass der Carrier als Terminator anstelle der dem Datenfluss direkt zugeordneten externen Entität gesetzt wird.
b. Daten können direkt von einem Terminator zu einem anderen Terminator fließen.
c. Es kann kein Datenfluss zu oder von einem Prozess angezeigt werden.
d. Der Datenfluss wird vom Terminator zu einem Datenspeicher (Datei) oder von einer Datei zum Terminator oder zwischen zwei Dateien ohne Verarbeitung angezeigt.
e. Die Prozesse werden als Objekte gekennzeichnet, z. B. Rechnung oder ein Nomen, z. B. Buchhalter.
Nachdem die DFDs für jedes Untersystem gezeichnet wurden, können zukünftige Verarbeitungsdetails herausgearbeitet und in strukturiertem Englisch (Psedo-Codes) beschrieben werden. Diese Psedo-Codes werden später zur Codierung der Anwendungen verwendet. Die Rolle des Managers in diesem Prozess ist nur darauf beschränkt, dem Informationssystem-Fachmann zu helfen, die an der Verarbeitung beteiligten Algorithmen zu erkennen und zu verstehen.
5. Implementierungsmodul:
Dieses Modul befasst sich hauptsächlich mit dem Testen des Systems, der Schulung der Benutzer und der Installation des Systems.
Testen des Systems:
Das Testen verschiedener Module erfolgt in verschiedenen Phasen des Entwicklungsprozesses. Die goldene Regel, die beim Testen zu beachten ist, besteht darin, dass der Test durchgeführt werden sollte, um festzustellen, auf welche Weise das System wahrscheinlich versagt. Es sollte nicht das Ziel sein, zu beweisen, dass das System gemäß der Entwurfsspezifikation funktioniert. Das Testen von Systemen ist das Suchen nach Antworten auf zwei grundlegende Fragen:
1. Ob das Informationssystem den Informationsbedürfnissen des Unternehmens dient? Der Prozess, der eine Antwort auf diese Frage sucht, wird von Fachleuten des Informationssystems als Systemvalidierungsprozess bezeichnet.
2. Funktioniert das Informationssystem korrekt? Der Überprüfungsprozess sucht nach einer Antwort auf diese Frage.
Da sich die Art und der Grad der Schwere der Fehler in verschiedenen Phasen der Systementwicklung unterscheiden, werden verschiedene Tests in verschiedenen Modulen und im gesamten System durchgeführt.
Gerätetest:
Die auf Modulebene verwendeten Tests können als Unit-Tests bezeichnet werden. Diese Tests werden durchgeführt, um Fehler in Schnittstellen, Datenbanken, Rechenoperationen und Steuerlogik zu erkennen. Sie werden ausgeführt, indem ein Modul des Informationssystems mit Testdaten betrieben wird, die speziell dafür ausgelegt sind, zu prüfen, ob das System:
ein. Akzeptiert einen falschen Datentyp (z. B. akzeptiert einen numerischen Wert für den Namen);
b. Akzeptiert Daten außerhalb des gültigen Bereichs (z. B. Datum mit einem Monat größer als 12);
c. Verursacht falsches Springen von einer Prozedur zu einer anderen Prozedur.
Systemtest:
Da die Komponententests isoliert durchgeführt werden, ist es wichtig, dass die Integrationstests durchgeführt werden, um zu prüfen, ob diese Einheiten als Gruppe ordnungsgemäß funktionieren. Aufgrund der unterschiedlichen Fehlerarten sind verschiedene Teststrategien zur Überprüfung der Gültigkeit und zur Überprüfung des Systems zu befolgen. Fertucks schlägt drei Strategien vor, um das Informationssystem zu testen:
(a) Clear Box-Test:
In dieser Strategie wird anhand von Tests ermittelt, ob die für die Verarbeitung angewandten Verfahren den Anforderungen der Anwendung entsprechen. Dies kann durch die Überprüfung durch Kollegen von anderen Informationssystemen erreicht werden, die in der Entwicklungsphase nicht direkt beteiligt waren.
Alternativ kann ein strukturiertes Durchlaufverfahren verwendet werden. Bei dieser Methode überprüft eine Gruppe von Personen die Verfahren, wobei zunächst fehleranfällige Teile untersucht und Korrekturen ermittelt werden, die vorgenommen werden müssen. Dann bewerten die Gruppenmitglieder die Ausgabe, die das System für eine bestimmte Art von Eingabe anbieten wird, und testen, ob die Ausgabe des Systems korrekt ist oder nicht.
(b) Black-Box-Test:
Bei dieser Strategie wird das System auf ungültige Daten oder Daten getestet, die Fehler in der Funktionsweise des Systems verursachen können. Die Ausgabe wird geprüft, um festzustellen, ob ein Fehler aufgetreten ist. Beispielsweise können Daten einen negativen Wert für die bestellte Menge oder einen Bruchwert für eine Variable enthalten, die nur den gesamten Wert annehmen kann.
(c) Ticking Box-Test:
Diese Strategie setzt voraus, dass niemals ein vollständig fehlerfreies Informationssystem bereitgestellt werden kann. Nach allen Tests und Änderungen muss daher die Anzahl der noch im System verbleibenden Fehler geschätzt werden. Um diese Anzahl zu schätzen, können absichtlich einige Fehler in das System eingeführt werden. Dann werden die Tests erneut durchgeführt, um Fehler zu erkennen.
Der Anteil der festgestellten eingeführten Fehler wird als Schätzung des Anteils der bei den früheren Tests festgestellten tatsächlichen Fehler angenommen. Wenn also 90% der eingeführten Fehler während des Ticking-Box-Tests erkannt wurden, während ursprünglich beim Clear-Box-Test und beim Black-Box-Test insgesamt 450 Fehler entdeckt wurden, bedeutet dies, dass 50 echte Fehler weiterhin im System unentdeckt bleiben.
Installation:
Bei der Installation wird das alte System durch ein neues System ersetzt. Grundsätzlich gibt es vier Ansätze zur Installation. Die "kalte" Installation wird durchgeführt, wenn das alte System sofort eingestellt wird und durch ein neues System ersetzt wird.
Eine solche Installation hat den Vorteil einer schnelleren psychologischen Anpassung, da das neue System verwendet werden soll. Ein solcher Ansatz ist jedoch möglicherweise nicht geeignet, wenn alte Daten aus dem früheren System wertvoll sind oder das neue System einige Probleme aufweist. Für die Installation von Abrechnungsinformationssystemen wurde dieser Ansatz nicht als akzeptabel befunden. Die alternativen Ansätze umfassen:
(a) Pilotinstallation:
Ein System darf nur zur Verwendung durch eine ausgewählte repräsentative Benutzergruppe installiert werden, die das System unter Verwendung des Systems testet. Andere Benutzer verwenden weiterhin das alte System. Wenn die Probleme im System behoben sind, verwenden auch andere Benutzer das System. Dieser Ansatz ist auch für Buchungssystem-Informationssysteme nicht sehr beliebt, da die gesamte Buchhaltungsdatenbank aktualisiert werden muss, bevor sie von Benutzern verwendet werden kann.
Die Informationsanforderungen des Benutzers überschreiten die Grenzen von Abteilungen und Abteilungen im Organigramm. Dieser Ansatz kann jedoch für vollständige Buchhaltungseinheiten wie Zweigstelle, Regionalbüro usw. verwendet werden. Somit kann ein Rechnungslegungsinformationssystem von ausgewählten Zweigstellen verwendet werden. Sobald sie fehlerfrei sind, können sie auch von anderen Zweigen verwendet werden.
(b) Phase-in-Installation:
Bei diesem Ansatz erfolgt die Installation in Schritten. Diese Stufen sind unabhängige Komponenten des Informationssystems. So kann der Umsatzlebenszyklus eines Buchhaltungsinformationssystems zuerst installiert werden und andere Lebenszyklen können aufeinander folgen. Dieser Ansatz hilft, sich auf einen ausgewählten Teil des Systems zu konzentrieren. Dies trägt dazu bei, die Akzeptanz des Systems unter den Benutzern zu verbessern, da es dem Benutzer ermöglicht, mit Änderungen problemlos umzugehen.
(c) Parallele Installation:
Die parallele Installation bedeutet, dass das alte und das neue System für einen bestimmten Zeitraum gleichzeitig ausgeführt werden, bis der Nutzen des neuen Systems nachgewiesen ist. Diese Methode wird am häufigsten für Buchhaltungsinformationssysteme verwendet, da dies die sicherste aller anderen Methoden ist. Die einzige Schwierigkeit besteht hier in den Kosten des Parallellaufs und der Tendenz, die Dauer des Parallellaufs durch diejenigen zu verlängern, die sich der Veränderung widersetzen.
Review nach der Implementierung:
Jedes System muss nach Abschluss der Implementierung überprüft werden. Eine solche Überprüfung hilft nicht nur beim Erkennen der Schwachstellen des Systems, sondern bereitet auch eine Agenda für zukünftige Änderungen vor. Es ist tatsächlich ein Lernprozess. Ein Systemaudit kann auch durchgeführt werden, um zu prüfen, wie erfolgreich das System in Bezug auf Kosten, Liefertermin, Vollständigkeit und Qualität ist.
