Modul Organisationsinformationssystem. Diplomarbeit: Entwicklung eines Informationssystems Großhandelsbasis. Automatisierte Arbeitsplätze

Basierend auf dem Zweck des zu entwickelnden Informationssystems werden wir den modularen Aufbau der Anwendung weiterentwickeln. Um die modulare Struktur zu bestimmen, verwenden wir die UML 2.0-Notation Komponentendiagramm (Abb. 3.4).

Reis. 3.4

Das Informationssystem besteht aus drei Komponenten:

• 1. Schnittstelle. Implementierung der Benutzerinteraktion mit dem Informationssystem. Enthält folgende Module:
  • · Eingabe/Ausgabe – Organisation der Eingabe und Ausgabe von Informationen bei der Arbeit mit geistigem Eigentum;
  • · Berichterstattung - Organisation der Berichterstattung gemäß den festgelegten Dokumentationsformen für verschiedene Tätigkeitsbereiche der Personalagentur;
  • Suche - Organisation der Suche nach Kandidaten und Stellenangeboten gemäß den angegebenen Parametern;
• 2. Datenverarbeitung. Implementierung von Informationsverarbeitungsfunktionen: Suche nach Daten in der Datenbank, mathematisches Modell für die Aufgabe der Primäranalyse von Dokumenten usw.;
• 3. DB. Implementierung eines Data Warehouse, das Informationen über Kunden enthält.

Entwicklung der Datenbankstruktur

Wie bereits erwähnt, werden im Informationssystem alle Informationen in einer einzigen Datenbank gespeichert. Die IDEF1x-Methodik wurde angewendet, um die logische Struktur der Datenbank zu modellieren. Gemäß dieser Methodik besteht der Prozess zum Erstellen eines Informationsmodells aus den folgenden Schritten:

• Definition von Entitäten; Ermittlung von Abhängigkeiten zwischen Entitäten;
• Festlegen von Primär- und Alternativschlüsseln;
• Definition von Entitätsattributen;
• Bringen des Modells auf das erforderliche Niveau der Normalform;
• · Übergang zur physikalischen Beschreibung des Modells: Zuordnung von Korrespondenzen Entitätsname - Tabellenname, Entitätsattribut - Tabellenattribut;
• Festlegen von Auslösern, Verfahren und Einschränkungen;
• Datenbankgenerierung.

Das Entitätsbeziehungsdiagramm, das die Datenbank in Bezug auf IDEF1.x beschreibt, besteht aus drei Hauptblöcken – Entitäten, Attribute und Beziehungen. Wenn wir das Diagramm als grafische Darstellung der Regeln des Fachgebiets betrachten, dann sind Entitäten und Attribute Substantive und Beziehungen Verben.

Da der zukünftige IS nach dieser Datenbank suchen wird, wurden folgende Hauptattribute für das Dokument gewählt:

• - Name des Dokuments;
• - das Datum des Eingangs des Dokuments im Archiv (Anwaltskanzleien, die Archivdienste anbieten, überwachen die Aufbewahrung von Dokumenten. Jedes Dokument hat seine eigene Aufbewahrungsfrist. Viele Wertpapiere verlieren mit der Zeit ihre Relevanz und ihr Wert wird auf Null reduziert. Solche Dokumente Die rechtzeitige Aussortierung solcher Unterlagen und die Vernichtung von Unterlagen gehört zum Leistungspaket der Archivierung von Anwaltskanzleien innerhalb dieser Frist wird das Dokument zur Vernichtung übergeben);
• - Eigentum (Typ) des Dokuments (da alle Dokumente in 7 Typen unterteilt wurden, für die eine Rangfolge nach Wichtigkeit vorgenommen wurde);
• -Spaltennummer;
• - Regalnummer;
• - Schlittennummer (diese 3 Parameter sind notwendig, um den Standort des Dokuments im Archiv zu bestimmen);
• - das Vorhandensein des Dokuments in seiner Zelle (Sie müssen wissen, ob sich das Dokument im Archiv befindet oder dem Antragsteller ausgestellt wurde).

Das Ergebnis einer Abfrage zur Auswahl aller Dokumente eines Mandanten sollte wie folgt aussehen, siehe Abbildung 3.5. Im vorgestellten Beispiel wurde die Anzahl der Dokumente bewusst auf 20 begrenzt.

Betrachten wir nun das in Abbildung 3.6 dargestellte logische Datenmodell des zu entwickelnden Informationssystems genauer.

Reis. 3.5

Reis. 3.6

Aus dem dargestellten Datenmodell ist ersichtlich, dass es drei Entitäten enthält, jede mit ihrem eigenen Satz von Attributen, von denen zwei abhängig sind und eine nicht.

Die Entität „Mitarbeiter“, die eine unabhängige Entität ist, hat die folgenden Attribute:

• · Mitarbeiteridentifikationsnummer – ist der Primärschlüssel dieser Entität;
• Name des Mitarbeiters;
• Fachgebiet;
• · Bewertung;
• · Weitere Informationen.

Die Entität „Kunde“ ist eine abhängige Entität der Entität „Mitarbeiter“, was bedeutet, dass jeder Mitarbeiter viele Kunden bedienen kann. Die Cliententität hat die folgenden Attribute:

• · Serien- und Passnummer – ist der Primärschlüssel dieser Entität;
• · Mitarbeiteridentifikationsnummer – ist ein sekundärer Schlüssel dieser Entität;
• Name des Mitarbeiters;
• Fachgebiet;
• · Bewertung;
• · Weitere Informationen.

Die Entität „Dokument“ ist eine abhängige Entität von der Entität „Kunde“, was bedeutet, dass jeder Kunde viele verschiedene Dokumente im Archiv speichern kann. Die Dokumententität hat die folgenden Attribute:

• · Dokument-ID – ist der Primärschlüssel dieser Entität;
• · Serien- und Passnummer – ist ein sekundärer Schlüssel dieser Entität;
• · Name des Dokuments;
• · Eingangsdatum;
• · Zugehörigkeit zu einer Gruppe;
• Spaltennummer;
• · Regalnummer;
• · Slider-Nummer;
• Das Vorhandensein eines Dokuments in einer Zelle.

Die Beziehung der Informationssubsysteme des Unternehmens

Wie hängen sie zusammen Informationssysteme innerhalb des Unternehmens? Der übliche Weg für ein mittelständisches russisches Unternehmen ist, die Einführung der Informationstechnologie mit der Automatisierung der Buchhaltung, der Personalabteilung und des Workflows zu beginnen. Die Daten dieser Systeme sind am stärksten formalisiert, die Prozesse lassen sich leicht automatisieren. Die weit verbreiteten Pakete „1C: Accounting“, „Boss: HR“, „LanDocs“, „LanStaff“, „Salary“ etc. erlauben Ihnen, beliebige Anwendungen selbst aufzubauen und somit in das allgemeine Informationssystem zu integrieren des Unternehmens. Reis. 7.1 zeigt, wie die Module des Informationssystems eines Unternehmens zueinander in Beziehung stehen. Das TPS-Modul dient den Hauptproduktions- und Unterstützungsprozessen und ist normalerweise die Hauptquelle für andere Informationsmodule. ESS ist der Hauptempfänger von Daten und internen Systemen aus der externen Umgebung.

Reis. 7.1.

Auch andere Systeme tauschen Daten aus. Und hier kommt eine der schwierigsten Fragen für eine Führungskraft - Suche nach dem optimalen Integrationsgrad. Es ist verlockend, ein vollständig integriertes System zu haben, aber eine solche Integration ist extrem zeitaufwändig und teuer. Und was der Unterhalt eines solchen Systems kostet, verrät man besser gar nicht. Daher muss die Notwendigkeit integrierter Systeme gegen die Schwierigkeit und die Kosten eines groß angelegten IC abgewogen werden. Es gibt keine standardmäßige Integrations- oder Zentralisierungsebene - jeder Führer muss(oder mit Hilfe eines Beratungsunternehmens), um dieses schwierige Problem zu lösen.

Beziehungen zwischen DSS- und TPS-Sammlung, KWS,

Automatisierte Arbeitsplätze

Leistungsanforderungen

Liste der generierten Berichte

4.4.2. Anforderungen an das System der Planung und Produktionssteuerung

Das Informationssystem sollte eine Warenwirtschaftsplanung und Auftragsproduktionsverwaltung bereitstellen.

Anforderungen an die IS-Funktionalität:

1. Konfigurationsmanagement fertiger Produkte (FP):

Pflege von Regulierungs- und Referenzinformationen über die Zusammensetzung des GP mit der Möglichkeit, den Relevanzzeitraum der Spezifikation anzugeben und mit der Möglichkeit, GP mit mehreren verschiedenen Spezifikationen zu produzieren;

Pflege von Regulierungs- und Referenzinformationen zur Herstellungstechnologie von Produkten, die Teil des GP sind, mit der Möglichkeit, den Zeitraum der Technologierelevanz anzugeben und mit der Möglichkeit, GP mit mehreren verschiedenen Technologien herzustellen;

2. Vertriebsmanagement:

Anzeigen der Historie von Kundenbeziehungen;

Registrierung/Anpassung des Antrags des Kunden mit Angabe der GP-Liste, der Mengen, des Versanddatums, des Verkaufspreises und etwaiger zusätzlicher Bedingungen;

Anzeigen der aktuellen Wirtschaftskennzahlen (Berechnung) des bestellten GP;

3. Produktionsplanung:

Erstellung eines Geräteverfügbarkeitsplans, der die Anzahl der verfügbaren Standardstunden für jeden Tag des Planungszeitraums angibt;

Erstellung eines Produktionsplans, der das hergestellte Produkt, seine Menge, die verwendete Ausrüstung und die Aufteilung für jeden Tag des Planungszeitraums angibt;

Erstellung eines Plans für den Bedarf der Produktion an Materialien und Komponenten;

Kontrolle und Verwaltung der Ausrüstungsladung gemäß dem erstellten Produktionsplan;

Anpassungen des Produktionsplans während seiner Ausführung;

Plan-Fakten-Analyse des Produktionsplans;

4. Produktionsleitung:

Bildung von Schichtaufgaben (Arbeitsaufträgen) für die Herstellung von Produkten;

Zuweisung/Neuzuordnung von Auftragnehmern zu Outfits und Festlegung der Ausführung von Outfits mit Angabe der Anzahl der hergestellten Produkte, der Anzahl fehlerhafter Produkte und der Gründe für die Eheschließung;

Verwaltung der Lagerung und Bewegung von Bestandsartikeln (Bestand und Materialien) in der Produktion;

5. Beschaffungsmanagement:

Auf der Grundlage des Bedarfsplans für Materialien und Komponenten Erstellung eines Kaufantrags mit Angabe des Lieferanten, des Waren- und Materialangebots, der Menge und der Lieferzeit;

Bildung von Bestellungen auf der Grundlage von Einzelbestellungen für Waren und Materialien von Abteilungen;

Überwachung und Verfolgung des Prozesses zur Erfüllung von Bestellungen;

Betriebskontrolle von Rückständen;

Plan-Fakten-Analyse von Lieferungen;

6. Kostenmanagement:

Bildung der geplanten (normativen) Kosten des Hausarztes;

Festsetzung der tatsächlichen Produktionskosten;

Berechnung der tatsächlichen Kosten von GP;

Plan-Fakten-Analyse der Kosten.

Voraussetzungen für die Berechnung der Standardkosten einer Bestellung

Die Standardkosten des Produkts und der gesamten Bestellung werden nach der folgenden Methode berechnet:

1. Die direkte Materialkomponente der Standardkosten eines Produkts wird auf der Grundlage von Informationen über die Standardzusammensetzung dieses Produkts (Spezifikation) und den festgelegten Buchhaltungspreisen für die in dieser Spezifikation enthaltenen Waren und Materialien gebildet. Für die Spezifikation dürfen mehrere Sachkostenpositionen verwendet werden.

2. Die Höhe der direkten Löhne wird auf der Grundlage der üblichen betrieblichen Zusammensetzung des Produkts berechnet. Festgelegt werden: die Regeldauer jedes Arbeitsgangs, der Beruf des für diesen Arbeitsgang erforderlichen Arbeiters sowie die Kategorie des Arbeiters. Außerdem werden in das System die Geldsätze der Standardstunden entsprechend den Berufen der Arbeitnehmer und ihrer Kategorien eingegeben.

3. Der normative Wert der indirekten Kosten wird als Prozentsatz der angegebenen Basis (der Wert der direkten Kosten für das angegebene Element) berechnet.

Um diese Berechnung durchführen zu können, müssen folgende Daten im Informationssystem verfügbar sein:

1. Spezifikation für die Herstellung des Produkts (sowie Spezifikationen für die Herstellung aller in diesem Produkt enthaltenen Halbzeuge aus eigener Herstellung);

2. Herstellungstechnologie des Produkts und der darin enthaltenen Halbzeuge: Welche Vorgänge sollten in welcher Zeit durchgeführt werden. Darüber hinaus werden für jeden Vorgang der Beruf und der Rang des Arbeiters angegeben, der für seine Durchführung (für die Freigabe dieses bestimmten Produkts) erforderlich ist;

3. Protokoll der Abrechnungspreise für gebrauchte Waren und Materialien;

4. Monetäre Sätze von Standardstunden für Berufe und Kategorien.

Voraussetzungen für die Berechnung der tatsächlichen Kosten einer Bestellung

Die tatsächlichen Kosten des Produkts und der gesamten Bestellung werden nach folgender Methode berechnet:

1. Die direkten Materialkosten für die Freigabe des Produkts werden auf der Grundlage tatsächlicher Materialverbrauchsdaten des Shops für Produktionsstufen berechnet. In diesem Fall werden zunächst die Kosten aller in diesem Produkt enthaltenen Halbzeuge berechnet. Die Summenbewertung erfolgt gemäß der in den Rechnungslegungsgrundsätzen des Unternehmens festgelegten Methodik.

2. Die Löhne der direkten Produktionsarbeiter werden auf der Grundlage der Daten zum Abschluss von Ladenaufträgen berechnet. Für den Fall, dass Auftragsaufzeichnungen im IS nicht geführt werden, beziehen sich die Löhne auf die verteilungspflichtigen direkten Kosten, d.h. wird nach einer bestimmten Basis auf die hergestellten Produkte verteilt.

3. Die Abschreibung der direkten Produktionsausrüstung ist in den direkten Kosten enthalten, wenn für jede Phase die in dieser Phase verwendete Ausrüstung (Maschine) angegeben ist.

4. Zu verteilende direkte Kosten:

Grundstoffe, die seltener verbraucht werden als für jede Verarbeitungsstufe (z. B. Chemikalien, deren Rate pro Produktionseinheit so gering ist, dass es keinen Sinn macht, ihren Querschnittsverbrauch selbst bei dieser Rate zu berücksichtigen);

Die Löhne der Arbeitnehmer in Ermangelung von Informationen über ihre Verteilung nach Abteilungen;

Abschreibung direkter Betriebsmittel für den Fall, dass nur deren monatlicher Gesamtbetrag ohne Aufschlüsselung nach Verarbeitungseinheiten zur Verfügung steht.

Diese Kosten werden den hergestellten Produkten gemäß der gewählten Vertriebsbasis zugeordnet (z. B. im Verhältnis zu den direkten Materialkosten).

1. Allgemeine Produktionskosten (Konto BU 25): werden im Verhältnis der gewählten Verteilungsbasis auf hergestellte Produkte verteilt. Der Anteil dieser Ausgaben kann in Übereinstimmung mit den vom Unternehmen angenommenen Rechnungslegungsgrundsätzen als Teil der laufenden Arbeiten verbleiben oder nicht.

2. Allgemeine Geschäftskosten und Vertriebskosten (Konten 26 und 44) ​​werden als Ausgaben der laufenden Periode erfasst und stehen im Zusammenhang mit Vertriebskosten. Die Verteilung dieser Kosten auf die Kosten der fertigen Produkte kann anhand eines speziellen Berichts eingesehen werden.

Leistungsanforderungen an Informationssysteme

<Раздел должен содержать требования к производительности Информационной системы. Вводится в шаблон>.

Zuverlässigkeitsanforderungen

<Раздел должен содержать требования к надежности Информационной системы. Например:>

Anforderungen zur Sicherstellung eines zuverlässigen (nachhaltigen) Funktionierens des Informationssystems

Das zuverlässige (nachhaltige) Funktionieren des Informationssystems muss durch die Umsetzung einer Reihe von organisatorischen und technischen Maßnahmen durch den Kunden gewährleistet werden, deren Liste nachstehend aufgeführt ist:

1. Organisation der unterbrechungsfreien Stromversorgung technischer Anlagen;

2. Nutzung lizenzierter Software;

3. Regelmäßige Umsetzung der Empfehlungen des Ministeriums für Arbeit und soziale Entwicklung der Russischen Föderation, die im Erlass vom 23. Juli 1998 „Über die Genehmigung branchenübergreifender Standardzeitstandards für die Wartung von PCs und Bürogeräten sowie die Wartung von Software“ festgelegt sind ";

4. Regelmäßige Erfüllung der Anforderungen von GOST 51188-98. "Datenschutz. Testen von Software auf das Vorhandensein von Computerviren“;

5. Regelmäßige Sicherung von Datenbanken des Informationssystems durch das Informationssystem selbst oder durch das eingesetzte Datenbankmanagementsystem.

Einführung

Die betreffende Diplomarbeit wurde auf der Grundlage der Donetsk OJSC Donetsk Manufactory für das Cleonelly-Geschäft geschrieben.

Eine der führenden Aktivitäten der JSC Donetsk Manufactory stellt eine breite Palette von Kleidungsstücken her, hauptsächlich Bademäntel, Laken und Handtücher. Darüber hinaus produziert das Unternehmen gefärbtes Baumwollgarn zum Weben und Stricken.

Die Entwicklung automatisierter Informationstechnologien geht Hand in Hand mit der Entstehung neuartiger technischer Mittel zur Verarbeitung und Übertragung von Informationen, der Verbesserung der Organisationsformen der Computernutzung und der Sättigung der Infrastruktur mit neuen Kommunikationsmitteln. Die Entwicklung der Marktbeziehungen hat zur Entstehung neuer Arten unternehmerischer Tätigkeit und vor allem zur Gründung von Firmen geführt, die sich mit der Informationswirtschaft, der Entwicklung von Informationstechnologien, ihrer Verbesserung, dem Vertrieb von automatisierten Inbeschäftigen insbesondere Softwareprodukte zur Automatisierung von Informations- und Rechenprozessen. Dazu gehören auch Computer, Kommunikation, Büroausstattung und bestimmte Arten von Dienstleistungen - Informationen, technische und Beratungsdienste, Schulungen usw. Dies trug zur schnellen Verbreitung und effektiven Nutzung von Informationstechnologien in Management- und Produktionsprozessen, zu ihrer nahezu universellen Anwendung und großen Vielfalt bei.

Unternehmen, die sich mit dem Design und der Entwicklung von Geräten für verschiedene Zwecke befassen, verwenden derzeit in großem Umfang verschiedene Tools sowohl für das computergestützte Design - CAD (CAD) als auch für die Überwachung von Produktionsprozessen - Prozessleitsysteme (SCADA / DCS). Für Geräte mit eigenem Design ist es jedoch erforderlich, eigene Mittel zur Überwachung ihrer Leistung und zur Analyse der Produktqualität zu entwickeln.

Der technologische Prozess der Abrechnung der im Cleanelly-Geschäft auf Lager befindlichen Produkte umfasst die Phase der Abrechnung der verkauften Produkte.

Der Zweck dieses Abschlussprojekts ist die Implementierung eines automatisierten Arbeitsplatzes (AWP), der es Ihnen ermöglicht, Produkte im Lager des Geschäfts zu verbuchen.

Um das obige Ziel zu erreichen, müssen die folgenden Aufgaben gelöst werden:

¾ Analyse der Geschäftsprozesse des Geschäfts;

¾ Untersuchung der Informationsflüsse, die in der Phase der Lieferung des entwickelten Produkts entstehen;

¾ konzeptionelle und logische Datenmodelle entwickeln;

¾ Entwicklung von Software für einen automatisierten Arbeitsplatz der Produktbuchhaltung

¾ die Wirtschaftlichkeit des Informationssystems bewerten.

1 Entwicklung von Softwareanforderungen

1.1 Analyse bestehender Lösungen

Derzeit gibt es eine Vielzahl von Unternehmen, die sowohl die direkte Entwicklung von Produkten als auch die Entwicklung von Steuerungssystemen für diese Produkte kombinieren. Ähnliche Systeme werden von namhaften Unternehmen wie 1:C Enterprise und Zvezda entwickelt. In solchen Systemen werden die Kontrolle und Abrechnung von Materialien und die Verarbeitung der erhaltenen Informationen durchgeführt.

1C:Enterprise ist ein System angewandter Lösungen, die nach denselben Prinzipien und auf einer einzigen technologischen Plattform aufgebaut sind. Der Manager kann eine Lösung wählen, die den aktuellen Bedürfnissen des Unternehmens entspricht und mit dem Wachstum des Unternehmens oder der Erweiterung der Automatisierungsaufgaben weiterentwickelt wird.

Das Softwaresystem 1C:Enterprise wurde entwickelt, um eine breite Palette von Aufgaben der Buchhaltungs- und Verwaltungsautomatisierung zu lösen, mit denen sich dynamisch entwickelnde moderne Unternehmen konfrontiert sind. Lösung dringender Probleme des Rechnungswesens und des Managements Die Zusammensetzung der Programme des 1C:Enterprise-Systems ist auf die tatsächlichen Bedürfnisse von Unternehmen ausgerichtet. Die Firma "1C" produziert Umlaufsoftwarelösungen, die zur Automatisierung typischer Aufgaben der Buchhaltung und Verwaltung in Unternehmen entwickelt wurden. Eine Besonderheit der Umlauflösungen von 1C ist eine gründliche Untersuchung der Zusammensetzung der in Standardlösungen enthaltenen Funktionalität. 1C Company analysiert die Erfahrungen von Benutzern mit 1C:Enterprise-Programmen und überwacht Änderungen ihrer Bedürfnisse.

Zu den Hauptvorteilen meines Wholesale Base-Systems gehören die relativ geringen Kosten für die Implementierung dieses Systems sowie eine Reihe anderer Vorteile:

¾ Zuverlässigkeit der erstellten Anwendungen. Das Softwarepaket (PC) muss nicht nur gegen Benutzerfehler resistent sein, sondern auch gegen Ausfälle im Kommunikationssystem.

¾ Benutzerfreundlichkeit der Schnittstelle;

¾ Ein hohes Maß an Systemsicherheit, was nicht nur die Überwachung der Verfügbarkeit bestimmter Systemressourcen und den Schutz von Informationen in allen Phasen des Betriebs beinhaltet, sondern auch die Verfolgung der durchgeführten Aktionen mit einem hohen Maß an Zuverlässigkeit.

1.2 Domänenanalyse

Die Besonderheit der Analyse des Themenbereichs besteht darin, dass Sie den gesamten Betriebsablauf der Organisation sehen können.

CASE dient der Analyse und Reorganisation von Geschäftsprozessen – All Fusion Process Modeler (BPwin) Top-Level-Tool, das die Methoden IDEF0 (Funktionsmodell), DFD (Datenflussdiagramm) und IDEF3 (Arbeitsablaufdiagramm) unterstützt. BPwin ist eine leistungsstarke Modellierungssoftware, mit der Sie Änderungen an komplexen Geschäftsprozessen analysieren, dokumentieren und planen können. BPwin bietet ein Tool zum Sammeln aller notwendigen Informationen über den Betrieb des Unternehmens und eine grafische Darstellung dieser Informationen in Form eines ganzheitlichen und konsistenten Modells.

In Bezug auf die Systemfunktionalität. Innerhalb der IDEF0-Methodik (Integration Definition for Function Modeling) wird ein Geschäftsprozess als eine Reihe von Arbeitselementen dargestellt, die miteinander interagieren, und zeigt auch die Informationen, Personal- und Produktionsressourcen, die von jeder Arbeit verbraucht werden. Das Funktionsmodell soll die bestehenden Geschäftsprozesse im Unternehmen (das sogenannte AS-IS-Modell) und den Idealzustand beschreiben – was anzustreben ist (TO-BE-Modell). Die IDEF0-Methodik schreibt den Aufbau eines hierarchischen Systems von Diagrammen vor, d.h. einzelne Beschreibungen von Systemfragmenten. Zunächst wird eine Beschreibung des Gesamtsystems und seiner Interaktion mit der Außenwelt (Kontextdiagramm) durchgeführt, danach erfolgt eine funktionale Dekomposition. – Das System wird in Subsysteme unterteilt und jedes System wird separat beschrieben (Zerlegungsdiagramme). Dann wird jedes Subsystem in kleinere zerlegt usw., um den gewünschten Detaillierungsgrad zu erreichen.

Wenn es während des Modellierungsprozesses notwendig ist, die spezifischen Aspekte der Unternehmenstechnologie hervorzuheben, ermöglicht BPwin Ihnen, zu jedem Zweig des Modells in die DFD- oder IDEF3-Notation zu wechseln. DFD-Diagramme (Data Flow Diagramming) können ergänzen, was sich bereits im IDEF3-Modell widerspiegelt, da sie Datenflüsse beschreiben, sodass Sie sehen können, wie Informationen zwischen Geschäftsfunktionen innerhalb des Systems ausgetauscht werden. Gleichzeitig lassen DFD-Diagramme die Interaktion zwischen Geschäftsfunktionen aus.

Aus Sicht der Reihenfolge der durchgeführten Arbeiten. Und ein noch genaueres Bild erhält man, wenn man das Modell um IDEF3-Diagramme ergänzt. Diese Methode lenkt die Aufmerksamkeit auf die Reihenfolge, in der Ereignisse ausgeführt werden. IDEF3 enthält Logikelemente, mit denen Sie alternative Szenarien für die Entwicklung eines Geschäftsprozesses modellieren und analysieren können.

Um Geschäftsprozesse zu berücksichtigen, die im Lager eines Geschäfts ablaufen, müssen nur zwei Methoden IDEF0 und DFD verwendet werden. Der Prozess der Modellierung eines beliebigen Systems in IDEF0 beginnt mit der Definition des Kontexts, d. h. die abstrakteste Ebene zur Beschreibung eines Systems oder von Geschäftsprozessen als Ganzes.

Modell IDEF0. Um die Geschäftsprozesse „Bildung der Lieferantenbestellung“, „Wareneingang“, „Warenausgang“ zu untersuchen, betrachten Sie die Diagramme, die in Form eines IDEF0-Diagramms dargestellt werden. Ein IDEF0-System wird als ein Satz interagierender Aktivitäten oder Funktionen dargestellt.

Die IDEF0-Methodik basiert auf vier Hauptkonzepten.

Das erste davon ist das Konzept Funktionsblock (Aktivitätsbox). Der Funktionsblock wird grafisch als Rechteck dargestellt und repräsentiert eine spezifische Funktion innerhalb des betrachteten Systems.

Jede der vier Seiten des Funktionsblocks hat ihre eigene spezifische Bedeutung (Rolle), während:

Die obere Seite ist auf „Control“ eingestellt;

Die linke Seite ist "Eingabe";

Die rechte Seite ist auf „Output“ eingestellt;

Die Unterseite hat die Bedeutung „Mechanism“ (Mechanismus).

Der zweite „Wal“ der IDEF0-Methodik ist das Konzept eines Schnittstellenbogens (Pfeil). Die grafische Anzeige des Schnittstellenbogens ist ein Einwegpfeil. Jeder Schnittstellenbogen muss einen eigenen Namen haben (Pfeilbeschriftung). Mit Hilfe von Schnittstellenbögen werden verschiedene Objekte angezeigt, die mehr oder weniger die im System ablaufenden Prozesse bestimmen. In diesem Fall werden die Pfeile je nachdem, auf welcher Seite des Arbeitsrechtecks ​​sie eintreten oder von welcher Seite sie austreten, unterteilt in:

Eingangspfeile (betreten Sie die linke Seite des Funktionsblocks) - stellen Daten oder Objekte dar, die sich während der Ausführung der Arbeit ändern;

Steuerpfeile (auf der Oberseite des Funktionsblocks enthalten) - stellen die Regeln und Einschränkungen dar, aufgrund derer die Arbeit ausgeführt wird;

Ausgangspfeile (aus der rechten Seite des Funktionsblocks herausgehen) - stellen Daten oder Objekte dar, die als Ergebnis der Ausführung von Arbeiten erscheinen;

Mechanismuspfeile (auf der Unterseite des Funktionsblocks enthalten) – repräsentieren Ressourcen (z. B. Ausrüstung, Personal).

Das dritte Kernkonzept des IDEF0-Standards ist die Dekomposition. Das Zerlegungsprinzip wird angewendet, wenn ein komplexer Vorgang in seine Teilfunktionen zerlegt wird.

Durch die Dekomposition können Sie das Systemmodell schrittweise und strukturiert in Form einer hierarchischen Struktur einzelner Diagramme darstellen, was es weniger überladen und leicht verdaulich macht.

Das letzte der IDEF0-Konzepte ist das Glossar. Für jedes der IDEF0-Elemente: Diagramme, Funktionsblöcke, Schnittstellenbögen impliziert der bestehende Standard die Erstellung und Pflege eines Satzes entsprechender Definitionen, Schlüsselwörter, narrativer Aussagen usw., die das von diesem Element angezeigte Objekt charakterisieren. Dieses Set wird Glossar genannt und ist eine Beschreibung der Essenz dieses Elements.

Betrachten Sie die Diagramme der Geschäftsprozesse, die im Lager des Geschäfts von OAO DMM, "Cleonelly", stattfinden:

Für die allgemeine Sichtbarkeit des Systems ist es notwendig, den Kontext „Enterprise Warehouse Activity“ aufzubauen (siehe Abbildung 1.1).

Abbildung 1.1 – Diagramm „Lageraktivität des Unternehmens“

Nachdem der Kontext hergestellt ist, wird eine Dekomposition durchgeführt, d. h. Erstellen Sie die folgenden Diagramme in der Hierarchie.

Jedes nachfolgende Diagramm ist eine detailliertere Beschreibung einer der Aktivitäten im obigen Diagramm. Ein Beispiel für die Zerlegung von Kontextarbeit ist in Abbildung 1.2 dargestellt. Damit das Gesamtsystem bis zum erforderlichen Detaillierungsgrad in Teilsysteme unterteilt wird, wird dieses System in drei Ebenen unterteilt.

Abbildung 1.2 - Zerlegungsdiagramme der ersten Ebene

Abbildung 1.3 - Diagramm „Produktfreigabe“

Abbildung 1.4 - Diagramm „Warenausgang“

Abbildung 1.5 - Diagramm „Wareneingang“

DFD. Die Grundlage dieser Methodik ist die Konstruktion eines Modells des analysierten IS - entworfen oder tatsächlich vorhanden. Gemäß der Methodik ist das Systemmodell als eine Hierarchie von Datenflussdiagrammen (DFDs) definiert, die den asynchronen Prozess der Informationstransformation von ihrer Eingabe in das System bis zu ihrer Ausgabe an den Benutzer beschreiben. DFD-Diagramme werden normalerweise erstellt, um den aktuellen Betrieb des Dokumentenverwaltungssystems einer Organisation zu visualisieren. Am häufigsten werden DFD-Diagramme als Ergänzung zu dem in IDEF0 implementierten Geschäftsprozessmodell verwendet.

Die Hauptkomponenten eines Datenflussdiagramms sind:

Externe Entitäten (grafisch als Quadrat dargestellt) - bezeichnen ein materielles Objekt oder eine Person, die eine Quelle oder ein Empfänger von Informationen ist. Zum Beispiel: Kunden, Mitarbeiter, Lieferanten, Kunden, Lager;

Systeme / Subsysteme (sieht grafisch wie ein Rechteck mit abgerundeten Ecken aus) - Werke, die Funktionen oder Prozesse bezeichnen, die Informationen verarbeiten und ändern;

Datenlaufwerke sind ein abstraktes Gerät zum Speichern von Informationen, die jederzeit auf dem Laufwerk abgelegt und nach einiger Zeit abgerufen werden können, und die Methoden zum Platzieren und Abrufen können beliebig sein. Das Datenlaufwerk ist im Allgemeinen ein Prototyp der zukünftigen Datenbank und die Beschreibung der darin gespeicherten Daten sollte mit dem Informationsmodell verknüpft werden;

Datenströme - definiert die Informationen, die über eine Verbindung von einer Quelle zu einem Empfänger übertragen werden. Der Datenfluss im Diagramm wird durch eine Linie dargestellt, die mit einem Pfeil endet, der die Flussrichtung anzeigt.

Betrachten Sie das Datenflussdiagramm (DFD) „Warenausgang“ Abbildung 1.6. Dieses Diagramm zeigt die Bewegung von Dokumenten, wenn eine "Warenanforderung" bei der Organisation eingeht.

Abbildung 1.6 - Diagramm DFD „Warenausgang“

Betrachten Sie das folgende Datenflussdiagramm „Produktfreigabe“ (siehe Abbildung 1.7). Es zeigt den Arbeitsablauf und die Dokumentenbewegung bei der „Warenfreigabe“.

Abbildung 1.7 - DFD-Diagramm „Produktfreigabe“

In Datenflussdiagrammen addieren sich alle verwendeten Symbole zu einem großen Bild, das eine klare Vorstellung davon gibt, welche Daten verwendet werden und welche Funktionen vom Workflow-System ausgeführt werden. Gleichzeitig stellt sich oft heraus, dass die bestehenden und für die Unternehmenstätigkeit wichtigen Informationsflüsse unzuverlässig umgesetzt werden und neu organisiert werden müssen.*****

Die Organisationsstruktur eines Unternehmens, das Frottierprodukte verkauft, wird am Beispiel der Firma JSC "Donetsk Manufactory M" des Cleonelly-Geschäfts betrachtet:

In Richtung der Entwicklung von Systemen zur Überwachung und Abrechnung von Materialien können folgende Probleme erfolgreich gelöst werden:

1. Dies ist die Kontrolle über die gelieferten und im Lager gelagerten Waren.

2. Informationen über Lieferanten und Verbraucher

3. Enthält auch Informationen Informationen und Operationen auf dem Produkt

4. Das Protokoll der Meldung der freigegebenen Ware ist enthalten

5. Enthält ein Warenverzeichnis

6. Automatisierung von Lagerfunktionen (Ankunft, Verbrauch, Abschreibung, Warenreservierung)

7. Erfassung und Aufbewahrung von Rechnungen für gekaufte und verkaufte Waren und Dienstleistungen sowie Ausstellung von Rechnungen gegen Vorkasse, mit Zahlungsaufschub und mit Warenlieferung

8. Erstellung von Rechnungen und Abrechnung der ausgegebenen Waren

9. Durchführung einer Bestandsaufnahme von Lagern mit Erstellung eines Kollationsblatts, ein Akt des Mangels und des Überschusses

10. Erstellen Sie Produktpakete

Wie bereits erwähnt, ist das Haupttätigkeitsfeld dieses Unternehmens der Verkauf von Baumwollprodukten. Der Designprozess umfasst viele Phasen, die von den Managementstrukturen von Designunternehmen während der gesamten Lebensdauer dieses Unternehmens sorgfältig ausgearbeitet werden. Dieser Prozess kann nicht sofort geändert werden, da er viele Abteilungen des Unternehmens selbst, externe Subunternehmer und Kunden des Projektunternehmens umfasst. Daher sind Unternehmen bei der Implementierung von Informationssystemen im Zusammenhang mit Design- und Entwicklungsmanagementprozessen vorsichtig. Russische Unternehmen nutzen in der Regel eigene Entwicklungen in diesem Bereich.

1.3 Sammlung von Anforderungen

Bei der Konzeption des Informationssystems (IS) des „Arbeitsplatzes des Großhandelsmarktes“ galt es Anforderungen zu sammeln, die dabei helfen, eine Schnittstelle so zu gestalten, dass der Endnutzer (Mitarbeiter des Ladens) bequem damit arbeiten kann entwickelten IS.

Requirements Engineering ist ein Prozess, der die Aktivitäten umfasst, die zum Erstellen und Genehmigen eines Systemanferforderlich sind.

Um den Prozess der Automatisierung der Buchhaltung und Materialkontrolle zu implementieren, ist es notwendig, dass das Informationssystem die folgenden funktionalen Anforderungen erfüllen kann:

¾ Ergebnisdokumentation.

¾ Das Informationssystem muss als Programm implementiert werden, das auf der integrierten Umgebung von Visual Fox Pro basiert.

Das Programm arbeitet unter dem Betriebssystem Windows 2000/NT/XP.

Es gibt vier Hauptphasen im Anforderungsentwicklungsprozess (Abbildung 1.8):

Analyse der technischen Machbarkeit der Erstellung eines Systems;

Anforderungsbildung und -analyse;

Spezifikation der Anforderungen und Erstellung der relevanten Dokumentation;

Anforderungsvalidierung.

Die Anforderungserfassung ist eine wichtige Phase des Softwaredesigns, da hier alle Kundenanforderungen richtig und korrekt formuliert werden müssen.

1.4 Anforderungsspezifikation

Die Bestimmung der richtigen Anforderungen ist wahrscheinlich der wichtigste Schritt in einem Softwareprojekt. Es ist sehr wichtig, dass das Projektformat zu den vom Entwicklungsteam erhobenen Anforderungen an die Software passt, da diese Anforderungen sonst nicht im Softwareprodukt unterstützt und abgebildet werden können. Die Software Requirements Specification (SRS) ist von zentraler Bedeutung für den gesamten Lebenszyklus der Softwareentwicklung. Dies ist nicht nur ein abgeleitetes Dokument, das die Spezifikationen eines Softwareprojekts definiert, sondern auch das Hauptdokument, das für Qualifizierungs- und Abnahmetests verwendet wird. Die Zertifizierung ist eine Bewertung der Qualität der Arbeit von Projektmanagern. Es bestimmt den Übereinstimmungsgrad des Softwareprodukts mit den festgelegten Anforderungen. Die SRS-Spezifikation fungiert als Mechanismus zur Festlegung von Systemanforderungen, die als Kriterien für die Zertifizierung verwendet werden.

Auf der Grundlage des SRS wird eine Vereinbarung zwischen Kunden und Herstellern von Softwareprodukten getroffen. Die SRS-Spezifikation beschreibt vollständig die Funktionen, die das entwickelte Softwareprodukt erfüllen muss. Auf diese Weise können potenzielle Benutzer feststellen, inwieweit das Produkt ihre Anforderungen erfüllt, sowie Möglichkeiten, das Produkt so zu modifizieren, dass es für die Lösung ihrer Probleme am nützlichsten ist.

Reduzierte Entwicklungszeit. An der Erstellung der SRS-Spezifikation sind verschiedene Gruppen innerhalb der Organisation des Kunden beteiligt. Sie prüfen alle Anforderungen sorgfältig, noch bevor die direkte Entwicklung des Projekts beginnt. Dies verringert die Wahrscheinlichkeit einer späteren Neuentwicklung des Projekts, der Codierung und des Testens.

Durch sorgfältige Untersuchung der in der SRS-Spezifikation dargestellten Anforderungen können Versehen, Missverständnisse und Inkonsistenzen früh im Entwicklungszyklus gefunden werden, wenn Probleme viel einfacher zu beheben sind als später im Entwicklungszyklus.

Die SRS-Spezifikation wird zur Grundlage für Kalkulation und Terminplanung. Die Produktbeschreibung ist die eigentliche Grundlage für die Kostenschätzung des Projekts. In einer Umgebung, in der der Begriff eines formellen Angebots existiert, wird der SRS verwendet, um eine Schätzung eines Angebots oder Preises zu validieren.

Mit den richtigen Spezifikationen kann die SRS auf Organisationsebene viel produktivere Bewertungs- und Überprüfungspläne entwickeln. Im Rahmen eines Entwicklungsvertrags stellt der SRS einen Benchmark zur Bewertung der Einhaltung von Spezifikationen bereit.

Dank der SRS-Spezifikation ist es einfacher, das Softwareprodukt an neue Benutzer zu übertragen und es auf anderen Computern zu installieren. Somit wird es für Kunden einfacher, das Softwareprodukt an andere Abteilungen der Organisation zu übertragen, und für Entwickler, es an andere Kunden zu übertragen.

Als Grundlage für das Upgrade dient die SRS-Spezifikation. Dieses Dokument befasst sich mit dem Produkt selbst, nicht mit dem Projektentwicklungsprozess, sodass es als Erweiterung des fertigen Produkts verwendet werden kann.

Nachdem der Prozess der Definition und Spezifikation von Anforderungen abgeschlossen ist, ist es notwendig, eine Anforderungsvalidierung durchzuführen.

Die Anforderungsspezifikation für das Softwareprojekt sollte in Anhang A dargestellt werden.

1.5 Anforderungsvalidierung

Die Qualifizierung muss zeigen, dass die Anforderungen wirklich das System definieren, das der Kunde haben möchte. Die Anforderungsvalidierung ist wichtig, da ein Fehler in der Anforderungsspezifikation zu Systemüberarbeitungen und hohen Kosten führen kann, wenn er während des Systementwicklungsprozesses oder nach der Inbetriebnahme des Systems entdeckt wird.

Während des Asollten verschiedene Arten von Überprüfungen der Anforderungsdokumentation durchgeführt werden:

1. Überprüfung der Korrektheit der Anforderungen.

2. Konsistenz prüfen.

3. Auf Vollständigkeit prüfen.

4. Machbarkeitsprüfung.

Es gibt eine Reihe von Methoden zur Anforderungsvalidierung, die zusammen oder einzeln verwendet werden können:

1. Übersicht der Anforderungen.

2. Prototyping.

3. Generierung von Testszenarien.

4. Automatisierte Konsistenzanalyse.

Das offensichtlichste für den Kunden des Systems ist das Prototyping.

Bevor Sie mit dem Prototyping beginnen, können Sie ein UI-Flussdiagramm erstellen. Ein solches Diagramm wird verwendet, um die Beziehungen zwischen den Hauptelementen der Benutzeroberfläche zu untersuchen.

Der nächste Schritt bei der Anforderungsvalidierung ist das Prototyping.

Ein Software-Prototyp ist eine teilweise oder potenzielle Implementierung eines vorgeschlagenen neuen Produkts. Mit Prototypen können Sie drei Hauptaufgaben lösen: den Prozess der Anforderungsformulierung klären und vervollständigen, alternative Lösungen untersuchen und das Endprodukt erstellen.

Der Prototyp des Hauptmenüs dieses Moduls ist in Abbildung 1.9 dargestellt.

1.6 Auswahl einer Methodik für das Design von Informationssystemen

Die Essenz des strukturellen Ansatzes zur Entwicklung von IS liegt in seiner Zerlegung (Partitionierung) in automatisierte Funktionen: Das System wird in funktionale Subsysteme unterteilt, die wiederum in Teilfunktionen unterteilt, in Aufgaben unterteilt werden und so weiter. Der Partitionierungsprozess wird bis zu bestimmten Prozeduren fortgesetzt. Gleichzeitig behält das automatisierte System eine ganzheitliche Sicht, in der alle Komponenten miteinander verbunden sind.

Alle gebräuchlichen strukturellen Ansatzmethoden basieren auf einer Reihe allgemeiner Prinzipien. Die folgenden Prinzipien werden als zwei Grundprinzipien verwendet:

Teile und herrsche – das Prinzip, komplexe Probleme zu lösen, indem sie in viele kleinere unabhängige Probleme zerlegt werden, die leicht zu verstehen und zu lösen sind;

Das Prinzip der hierarchischen Ordnung ist das Prinzip, die Bestandteile eines Problems in hierarchischen Baumstrukturen zu organisieren, wobei auf jeder Ebene neue Details hinzugefügt werden.

In der Strukturanalyse werden hauptsächlich zwei Gruppen von Werkzeugen verwendet, die die vom System ausgeführten Funktionen und die Beziehungen zwischen Daten veranschaulichen. Jede Gruppe von Werkzeugen entspricht bestimmten Arten von Modellen (Diagrammen), von denen die häufigsten die folgenden sind:

SADT-Modelle (Structured Analysis and Design Technique) und zugehörige Funktionsdiagramme;

DFD (Data Flow Diagrams) Datenflussdiagramme;

ERD (Entity-Relationship-Diagramme)

In der Entwurfsphase von IS werden die Modelle erweitert, verfeinert und mit Diagrammen ergänzt, die die Struktur der Software widerspiegeln: Softwarearchitektur, Blockdiagramme von Programmen und Diagramme von Bildschirmmasken.

Die aufgeführten Modelle ergeben zusammen eine vollständige Beschreibung des IS, unabhängig davon, ob es sich um ein bestehendes oder neu entwickeltes handelt. Der Aufbau der Diagramme richtet sich im Einzelfall nach der geforderten Vollständigkeit der Systembeschreibung.

2 GESTALTUNG VON INFORMATIONSSYSTEMEN

2.1 Architekturdesign

Bei der Erstellung eines komplexen Informationssystems ist seine Architektur ein kritischer Aspekt, bei der es sich um eine konzeptionelle Vision der Struktur zukünftiger funktionaler Prozesse und Technologien auf Systemebene und in Verbindung handelt. Gewöhnlich werden komplexe Informationssysteme von Organisationen als eine Zusammensetzung von Komponenten konzipiert, die auf einer hohen Ebene interagieren und selbst Systeme sein können. Die Architektur des Informationssystems einer Organisation erleichtert das Verständnis des Systems, indem es seine Funktionalität und Struktur so definiert, dass Designentscheidungen offengelegt werden und es dem Beobachter ermöglicht, Fragen zur Erfüllung von Designanforderungen, zur Verteilung von Funktionen und zur Implementierung von Komponenten zu stellen.

Die Architektur des Informationssystems einer Organisation ist ein Modell dafür, wie die Informationstechnologie die Hauptziele und die Entwicklungsstrategie eines automatisierten Objekts unterstützt. Es ermöglicht kritisches Denken und eine klare Vorstellung davon, wie integrierte Sätze von Informationssystemen strukturiert sein sollten, um diese Ziele zu erreichen. Eine Informationssystemarchitektur beschreibt, wie Informationssysteme, Anwendungen und Personen innerhalb einer Organisation einheitlich und einheitlich arbeiten.

Somit enthält die Architektur eines Informationssystems einen allgemein akzeptierten Satz von Komponenten, die die "Bausteine" eines Informationssystems bereitstellen. Diese „Bausteine“ und ihre Eigenschaften werden auf der angemessenen Detailebene definiert, um den durch die Planungsentscheidungen generierten Anforderungen zu entsprechen.

Beim Entwerfen moderner Informationssysteme von Organisationen sollte ihre Architektur unter Berücksichtigung vieler Interessengruppen entwickelt werden, sie sollte für Benutzer verständlich sein, Entwicklern ermöglichen, das System zu planen und zu terminieren, es ermöglichen, Schlüsselschnittstellen, Funktionen und Technologien zu definieren und auch zu schätzen Projektzeitplan und Budget. Gleichzeitig müssen die Architekten moderner Informationssysteme dafür verantwortlich sein, in der frühesten Phase ihrer Entwicklung ein zufriedenstellendes und durchführbares Systemkonzept zu erstellen, die Integrität dieses Konzepts während der gesamten Entwicklung aufrechtzuerhalten und die Eignung des resultierenden Systems für zu bestimmen Nutzung durch den Auftraggeber. Andererseits ist die Entwicklung von Informationssystemarchitekturen der Prozess, Informationssystemarchitekturen ausreichend detailliert zu beschreiben, um sie für die Entwicklung von Informationssystemen nützlicher zu machen.

Die Untersuchung ausländischer Erfahrungen zeigt, dass in entwickelten Ländern bei der Entwicklung der Architektur eines Informationssystems die folgenden Bedingungen erforderlich sind:

¾ sich auf die Mission der Organisation konzentrieren;

¾ Fokus auf Anforderungen;

¾ Fokus auf Entwicklung;

¾ Anpassungsfähigkeit;

¾ das Bedürfnis nach Flexibilität.

Die Einhaltung all dieser Bedingungen ermöglicht es Ihnen, die Architektur des Informationssystems der Organisation perfekter und effizienter zu entwickeln.

Die wichtigsten derzeit implementierten Softwarearchitekturen sind:

¾ Dateiserver;

¾ Client-Server;

¾ mehrstufig.

Dateiserver. Diese Architektur zentralisierter Datenbanken mit Netzwerkzugriff geht davon aus, dass einer der Computer im Netzwerk als dedizierter Server bestimmt wird, der die Dateien der zentralisierten Datenbank speichert. Entsprechend den Benutzeranforderungen werden Dateien vom Dateiserver zu den Benutzerarbeitsstationen übertragen, wo der Hauptteil der Datenverarbeitung durchgeführt wird. Der zentrale Server übernimmt im Grunde nur die Rolle eines Dateispeichers und ist selbst nicht an der Verarbeitung der Daten beteiligt. Nach Abschluss der Arbeiten kopieren die Benutzer die Dateien mit den verarbeiteten Daten zurück auf den Server, von wo sie von anderen Benutzern übernommen und verarbeitet werden können. Eine solche Organisation der Datenpflege hat eine Reihe von Nachteilen, beispielsweise wenn viele Benutzer gleichzeitig auf dieselben Daten zugreifen, sinkt die Performance stark, da gewartet werden muss, bis der Benutzer, der mit den Daten arbeitet, seine Arbeit beendet hat. Andernfalls können Änderungen einiger Benutzer durch Änderungen anderer Benutzer überschrieben werden.

Kundenserver. Dieses Konzept basiert auf der Idee, dass der zentrale Server neben der Speicherung der Datenbankdateien den Großteil der Datenverarbeitung übernehmen sollte. Benutzer greifen auf den zentralen Server über eine spezielle strukturierte Abfragesprache (SQL, Structured Query Language) zu, die eine Liste von Aufgaben beschreibt, die vom Server ausgeführt werden. Benutzeranfragen werden vom Server entgegengenommen und erzeugen darin Datenverarbeitungsprozesse. Als Antwort erhält der Nutzer einen bereits verarbeiteten Datensatz. Zwischen Client und Server wird nicht wie bei der Fileserver-Technologie der gesamte Datensatz übertragen, sondern nur die Daten, die der Client benötigt. Eine Benutzerabfrage von nur wenigen Zeilen kann eine Datenverarbeitung generieren, die viele Tabellen und Millionen von Zeilen umfasst. Als Antwort kann der Client nur wenige Nummern empfangen. Die Client-Server-Technologie vermeidet die Übertragung großer Informationsmengen über das Netzwerk, indem die gesamte Datenverarbeitung auf einen zentralen Server verlagert wird. Darüber hinaus ermöglicht der betrachtete Ansatz die Vermeidung von Konflikten bei Änderungen an denselben Daten durch mehrere Benutzer, die für die Fileserver-Technologie typisch sind. Die Client-Server-Technologie implementiert eine konsistente Datenänderung durch mehrere Clients und gewährleistet so die automatische Datenintegrität. Diese und einige andere Vorteile haben die Client-Server-Technologie sehr beliebt gemacht. Zu den Nachteilen dieser Technologie gehören hohe Leistungsanforderungen an den zentralen Server. Je mehr Clients auf den Server zugreifen und je mehr Daten verarbeitet werden, desto leistungsfähiger muss der zentrale Server sein.

Basierend auf diesen Überlegungen wurde beim Entwurf der AWS-Architektur die Client-Server-Technologie als Grundlage übernommen. Layoutdiagramme spiegeln die physikalischen Beziehungen zwischen Software- und Hardwarekomponenten eines Systems wider.

2.2 Gestaltung der Schnittstelle des Informationssystems

Unter der Benutzeroberfläche wird oft nur das Erscheinungsbild des Programms verstanden. In Wirklichkeit nimmt der Benutzer jedoch das gesamte System darüber wahr, was bedeutet, dass ein solches Verständnis davon zu eng ist. In Wirklichkeit umfasst die Benutzerschnittstelle alle Designaspekte, die die Interaktion zwischen dem Benutzer und dem System beeinflussen. Es ist nicht nur der Bildschirm, den der Benutzer sieht. Die Benutzeroberfläche besteht aus vielen Komponenten, wie z.

eine Reihe von Benutzeraufgaben, die er mit Hilfe des Systems löst;

Systemsteuerungen;

Navigation zwischen Systemblöcken;

visuelle Gestaltung der Programmbildschirme.

Hier sind einige der wichtigsten Vorteile einer guten Benutzeroberfläche aus geschäftlicher Sicht:

Verringerung der Anzahl von Benutzerfehlern;

Reduzierung der Kosten für die Systemunterstützung;

Verringerung des Produktivitätsverlusts von Arbeitnehmern während der Implementierung des Systems und schnellere Wiederherstellung der verlorenen Produktivität;

Verbesserung der Mitarbeitermoral;

Reduzierung der Kosten für die Änderung der Benutzerschnittstelle auf Wunsch der Benutzer;

Verfügbarkeit der Systemfunktionalität für die maximale Anzahl von Benutzern.

AWP Wholesale Base wird als Anwendung mit Client-Server-Technologie entwickelt.

2.2.1 Benutzeroberfläche des Steuerprogramms

Das Hauptmodul der „Workstation Wholesale Base“ ist das Luck.exe-Modul, das die Implementierung der Hauptfunktionalität des Anwendungsfalldiagramms bereitstellt, das in Abbildung 1.9 von Abschnitt 1.4 dargestellt ist.

Bei der Entwicklung eines Informationssystems besteht eine der Hauptaufgaben darin, die einfachste und unbelasteteste Schnittstelle zu schaffen. Es ist die Schnittstelle des Softwareprodukts, die Benutzern hilft, mit dem Informationssystem zu „kommunizieren“, indem sie als Dialog zwischen dem Benutzer und dem System fungiert.

Programmoberfläche, Administratorteil:

1. die Startform des Programms. Dieses Formular wird beim Start des Softwareprodukts gestartet und bildet somit den Beginn des Dialogs des Benutzers mit dem System (Abbildung 2.3);

2. Admin-Formular. In dieser Form erfolgt die komplette Verwaltung des Informationssystems, d.h. Hinzufügen, Löschen, Ändern von Daten in der Datenbank sowie ggf. Anzeigen und Drucken von Berichten (Abbildung 2.4);

3. Formular „Kunden“, dank dieses Formulars können Sie vollständige Informationen über die Kunden des Unternehmens einsehen (Abbildung 2.7);

4. Formular „Lieferanten“, dank dieses Formulars können Sie vollständige Informationen über die Kunden des Unternehmens einsehen (Abbildung 2.8).

Benutzerteil Programmschnittstelle:

Im Wareneingangsfenster wird die Ware bearbeitet. Bei der Auswahl dieser Formularregisterkarte muss der Benutzer zuerst

Im Verbrauchsmenü gibt es Vorgänge, die von einem Lagermitarbeiter für die Freigabe und den Verkauf von Waren ausgeführt werden.

Im Restemenü werden die Waren, die im Lager gelagerten Namen, gezählt.

Im Kassenmenü werden hier Informationen zu eingehenden Bestellungen und ausgehenden Bargeldbestellungen gespeichert (Screenshots)

2.2.2 Benutzerschnittstellen von Steuerungskomponenten

Abb. 2.0 Hauptmenü des Programms

Das Hauptfenster des Programms ist in Abb. 1.9. Wie aus der Abbildung ersichtlich, wird es neben dem oben bereits beschriebenen Hauptmenü auch ein Bedienfeld enthalten (Schaltflächen „Einnahmen“, „Ausgaben“, „Zugriff“, „Salden“, „Kasse“, „Aufwertung“ , „Analytics“, „Verzeichnisse“, „Dienstprogramme“ und „Programm beenden“).

Abbildung 2.1 Fenster des Eingangs- oder Wareneingangsmenüs im Lager.

Abbildung 2.2 Flow-Menüfenster

Abbildung 2.2 Menüfenster, das die Zugriffsrechte auf das Programm regelt.

Abbildung 2.3 Das Menüfenster der restlichen Ware.

Abbildung 2.4 Checkout-Menüfenster.

Abbildung 2.4 Menüfenster Neubewertung.

2.3 Datenbankdesign

Für das Design der Datenbank wurde ERwin 4.0 von Computer Associates Int.

ERwin ist ein leistungsstarkes und benutzerfreundliches Datenbankdesign-Tool, das breite Akzeptanz und Popularität erlangt hat. Es bietet höchste Produktivität bei der Entwicklung und Wartung von Anwendungen, die Datenbanken verwenden. Während des gesamten Prozesses, von der logischen Modellierung der Informationsanforderungen und Geschäftsregeln, die die Datenbank definieren, bis zur Optimierung des physischen Modells gemäß den angegebenen Merkmalen, ermöglicht Ihnen ERwin, die Struktur und die Hauptelemente der Datenbank zu visualisieren.

ERwin ist nicht nur das beste Tool für das Datenbankdesign, sondern auch ein Tool zum schnellen Erstellen von Datenbanken. ERwin optimiert das Modell entsprechend den physikalischen Eigenschaften der Zieldatenbank. Im Gegensatz zu anderen Tools behält ERwin automatisch die logische und physische Schemakonsistenz bei und übersetzt logische Konstrukte wie viele-zu-viele-Beziehungen in ihre physische Implementierung. Erleichtert das Datenbankdesign. Dazu genügt es, ein grafisches E-R-Modell (Object-Relationship) zu erstellen, das alle Datenanforderungen erfüllt, und Geschäftsregeln einzugeben, um ein logisches Modell zu erstellen, das alle Elemente, Attribute, Beziehungen und Gruppierungen anzeigt. Erwin hat zwei Ebenen der Modellrepräsentation - logisch und physikalisch. Die logische Ebene ist eine abstrakte Ansicht von Daten, in der Daten so dargestellt werden, wie sie in der realen Welt aussehen, und wie sie in der realen Welt genannt werden können, beispielsweise „Stammkunde“, „Abteilung“ oder „Mitarbeiter“. Familienname, Nachname". Modellobjekte, die auf der logischen Ebene dargestellt werden, werden Entitäten und Attribute genannt. Die logische Ebene des Datenmodells ist universell und in keiner Weise an eine bestimmte DBMS-Implementierung gebunden. Es gibt drei Unterebenen der logischen Ebene des Datenmodells, die sich in der Informationstiefe der Daten unterscheiden:

Entitätsbeziehungsdiagramm (ERD)

Datenmodell basierend auf Schlüsseln (Key Based Model (KB));

Vollständiges Attributmodell (vollständig attributiertes Modell (FA)).

Das Entitätsbeziehungsdiagramm enthält Entitäten und Beziehungen, die die grundlegenden Geschäftsregeln des Themenbereichs widerspiegeln. Ein solches Diagramm ist nicht zu detailliert, es enthält die Hauptentitäten und die Beziehungen zwischen ihnen, die die Grundanforderungen erfüllen. Ein Entity-Relationship-Diagramm kann viele-zu-viele-Beziehungen enthalten und keine Beschreibung der Schlüssel enthalten. Typischerweise wird ERD für Präsentationen und Diskussionen der Datenstruktur mit Fachexperten verwendet. Ein schlüsselbasiertes Datenmodell ist eine detailliertere Darstellung von Daten. Es enthält eine Beschreibung aller Entitäten und Primärschlüssel und soll die Datenstruktur und Schlüssel darstellen, die dem Themengebiet entsprechen.

Das logische Modell ist die detaillierteste Darstellung der Datenstruktur: Es stellt die Daten in der dritten Normalform dar und umfasst alle Entitäten, Attribute und Beziehungen (siehe Anhang B).

Physikalisches Datenmodell im Gegenteil, es hängt von dem spezifischen DBMS ab, das tatsächlich eine Anzeige des Systemkatalogs ist. Die physikalische Schicht des Modells enthält Informationen zu allen Datenbankobjekten. Da es keine Standards für Datenbankobjekte gibt (z. B. keinen Standard für Datentypen), hängt die physikalische Schicht des Modells von der spezifischen Implementierung des DBMS ab. Daher kann dieselbe logische Ebene eines Modells mehreren unterschiedlichen physikalischen Ebenen unterschiedlicher Modelle entsprechen. Wenn es auf der logischen Ebene des Modells keine Rolle mehr spielt, welchen konkreten Datentyp das Attribut hat (obwohl abstrakte Datentypen unterstützt werden), dann ist es auf der physikalischen Ebene des Modells wichtig, alle Informationen über bestimmte physische Objekte zu beschreiben - Tabellen, Spalten, Indizes, Prozeduren usw. . Die Aufteilung des Datenmodells in logische und physikalische Schichten ermöglicht es uns, mehrere wichtige Probleme zu lösen.

Das physische Datenmodell ist in Anhang B dargestellt.

2.4 Begründung für die Wahl einer Plattform zur Erstellung eines Informationssystems

Visual FoxPro ist eine Entwicklungsumgebung für ein visuelles relationales Datenbankverwaltungssystem, die derzeit von Microsoft veröffentlicht wird. Die neuste Version ist 9.0. Verwendet die Programmiersprache FoxPro. Die Systemversion 7.0 kann auf Windows 9x- und NT-Kernel-Betriebssystemen, Versionen 8.0 und 9.0 ausgeführt werden - nur auf Windows XP, 2000, 2003.

FoxPro (Fox-Pro?) ist einer der Dialekte der Programmiersprache xBase. Sie wird hauptsächlich für die Entwicklung von relationalen DBMS verwendet, obwohl sie auch für die Entwicklung anderer Klassen von Programmen verwendet werden kann.Wie oben erwähnt, ist die VFP-Sprache eine stark ergänzte und erweiterte xBase-Sprache. In Visual FoxPro ist die Programmiersprache, dh das grundlegende Sprachkonstrukt, das Konzept einer Klasse. Die Originalversion von xBase ist die reinste Struktursprache mit dem Grundkonzept von Prozeduren und Funktionen. So ermöglicht die moderne Programmiersprache Visual FoxPro sowohl die Programmierung „auf die altmodische Art“ mit der Beschreibung der Masse an Prozeduren zu kombinieren, als auch im OOP-Stil eine komplexe Klassenhierarchie zu erstellen.

Ich habe mich für diese Programmiersprache entschieden, weil sie eine Reihe der folgenden Vorteile bietet:

¾ Ein bekanntes Datenbanktabellenformat, das den Austausch von Informationen mit anderen Microsoft Windows-Anwendungen erleichtert.

Eine moderne Organisation relationaler Datenbanken, mit der Sie Informationen über Datenbanktabellen, ihre Eigenschaften, Indizes und Beziehungen speichern, Bedingungen für die referenzielle Integrität festlegen, lokale und entfernte Ansichten (Views), Verbindungen mit Servern und gespeicherte Prozeduren erstellen können, die ausgeführt werden, wenn mehr als 50 Es treten verschiedene Arten von Ereignissen auf (VFP 7.0-9.0).

Schnelles Arbeiten mit großen Datenbanken.

Hohe Transparenz bei der Arbeit mit Datenbanken: Das multifunktionale Datensitzungsfenster ermöglicht es Ihnen, eine Liste der geöffneten Datenbanktabellen, ihrer Beziehungen, Filter, Indexreihenfolge, Puffermodi zu sehen, in Strukturänderungsmodi zu wechseln, mit Tabelleninformationen zu arbeiten usw.

Hochgeschwindigkeits-Anwendungsentwicklung mit Wizards (Wizard), Designers (Designer), Builders (Builder), IntelliSense-Eingabeaufforderungsmodus beim Schreiben von Programmtext, Debugging und Programmtestsystemen.

Fähigkeit, Client-Server-Anwendungen mit Daten zu entwickeln, die auf Oracle- und Microsoft SQL Server-Datenbankservern und anderen Microsoft Windows-Anwendungen mit ODBC und OLE gehostet werden

Das VFP-System ist für die Verwendung durch professionelle Programmierer gedacht, daher macht es keinen Sinn, sein Menü und seine Sprache zu russifizieren - für jeden Programmierer ist die englische Syntax der algorithmischen Sprache vertrauter als die russische.

2.5 Moduldesign

Gehen wir näher auf den Aufbau eines der Programmmodule ein und betrachten an dessen Beispiel die notwendigen Schritte zur Erstellung eines Projekts.

Als Beispiel betrachte ich das Design eines Moduls, das den Anwendungsfall „Zulassung beantragen“ umsetzt.

Lassen Sie uns zunächst die Ereignisabläufe beschreiben, die in diesem Anwendungsfall auftreten.

Voraussetzung für einen Use Case ist der Eingang einer Anfrage des Auftraggebers.

5. Der Anwendungsfall beginnt, wenn der Kunde ein Ticket einreicht.

6. Der Manager öffnet das Eingangsformular.

7. Der Manager setzt das Datum der Bewerbung.

8. Der Manager gibt den Namen des Produkts an.

9. Der Manager gibt die Menge der eingehenden Waren ein.

10. Der Manager gibt den Betrag des Antrags ein.

11. Der Manager schließt das Formular.

12. Der Anwendungsfall endet.

Eine Nachbedingung für den Anwendungsfall ist die Registrierung einer Bewerbung im System und das Erscheinen eines neuen Kunden im Protokoll des Hauptformulars.

Betrachten Sie das Sequenzdiagramm dieses Anwendungsfalls. Wie aus diesem Diagramm ersichtlich ist, veranlasst der Manager beim Öffnen des Eingangsformulars, dass mehrere Aktionen ausgeführt werden - automatisch (aus der Sicht des Managers) wird das Datum der Bewerbung eingetragen. Die Liste der Kunden bei der Antragstellung wird von der Basis aus mit Primärinformationen gefüllt. Danach gibt der Manager alle erforderlichen Daten ein und klickt auf die Schaltfläche "Akzeptieren". Dies führt die folgenden Schritte aus. Alle Daten werden an die gespeicherte Prozedur übergeben.

3 Implementierung und Validierung des Informationssystems

3.1 Anwendungsimplementierung

Die Implementierung der Anwendung ist im Wesentlichen eine der mühsamen Phasen für den Entwickler des Informationssystems, da die vom Kunden gestellten Anforderungen klar und korrekt in das System integriert werden müssen. Bisher gibt es keine solchen Softwareprodukte, die sich an die Anforderungen des sogenannten Kunden "anpassen" und einen bestimmten Satz von Funktionen für die Implementierung des Systems bereitstellen könnten, der diese Anforderungen erfüllt. Daher muss jeder Entwickler die optimale Umgebung für die Entwicklung des Systems auswählen, aber es sollte beachtet werden, dass man bei der Implementierung einer Anwendung nicht darauf verzichten kann, Programmcode zu schreiben. Beim Schreiben des Programmcodes werden bestimmte Funktionen implementiert, die das System ausführen muss. Je nach gewählter Systemimplementierungsumgebung sieht der Programmcode anders aus, in einer Umgebung wie Microsoft Visual FoxPro gibt es einen Programmcode, in Visual Basic einen anderen und so weiter.

In diesem Fall wurde die Anwendung in Microsoft Visual FoxPro implementiert.

Die Hauptfunktionen des Systems werden im Folgenden beschrieben:

1. Ausgangsform des Systems. Dieses Formular ist ein Schaltflächenformular und dementsprechend erfüllt jede Schaltfläche ihre Funktion. Die Administratorregistrierungsschaltfläche ist in Abbildung 3.1 dargestellt.Diese Schaltfläche führt eine Funktion aus, die das Administratorpanel öffnet, wenn der Benutzer über solche Rechte für dieses System verfügt

2. Menütaste Ankunft. Mit dieser Schaltfläche können Sie den Wareneingang im Lager des Geschäfts verfolgen (Abb. 3.2).

3. In der Schaltfläche des Verbrauchsmenüs wird das Konto der aus dem Lager freigegebenen Waren geführt Abbildung 3.3.

4. In der Schaltfläche Zugriffsmenü werden die Rechte zur Nutzung dieses Programms geregelt Abbildung 3.4.

5. In der Menüschaltfläche Reste werden Informationen über die im Lager des Geschäfts gelagerten Materialien gespeichert Abbildung 3.5.

6. Die Schaltfläche des Kassenmenüs speichert Informationen über eingehende und ausgehende Geldbestellungen Abb. 3.6.

7. In der Menüschaltfläche übergibt die Neubewertung die Preisänderungen an den neuen Preis der Ware Abb.3.7.

Abbildung 3.1 - Ausgangsform des Systems

Abbildung 3.2 - Abrechnungsform für Materialeingänge im Lager.

Abbildung 3.3 - Abrechnungsform für die freigegebenen Waren.

Abbildung 3.4 - Formular zur Regulierung der Zugangsrechte zum Programm.

Abbildung 3.5 - Die Form der verbleibenden Ware im Lager.

Abbildung 3.5-Formular zu eingehenden und ausgehenden Bargeldbestellungen.

Abbildung 3.6-Form der Transaktionen für die Waren.

Anwendungstests

Testen ist der Vorgang, bei dem ein Programm ausgeführt wird, um Fehler zu erkennen. Testen bietet:

Fehlererkennung;

Nachweis der Zweckmäßigkeit der Programmfunktionen;

Demonstration der Umsetzung der Leistungsanforderungen des Programms;

Zeigen Sie die Zuverlässigkeit als Indikator für die Programmqualität an.

Abbildung 3.2 zeigt die Informationsflüsse des Testprozesses.

Am Eingang des Testprozesses gibt es drei Abläufe:

Programmtext;

Anfangsdaten zum Starten des Programms;

Erwartete Ergebnisse.

Tests werden durchgeführt, alle Ergebnisse werden ausgewertet. Das bedeutet, dass die tatsächlichen Testergebnisse mit den erwarteten Ergebnissen verglichen werden. Wenn eine Nichtübereinstimmung gefunden wird, wird ein Fehler behoben und das Debuggen beginnt.

Nach dem Sammeln und Auswerten der Testergebnisse beginnt die Darstellung der Qualität und Zuverlässigkeit der Software. Wenn regelmäßig schwerwiegende Fehler auftreten, die Designänderungen erfordern, die Qualität und Zuverlässigkeit der Software zweifelhaft sind, wird die Notwendigkeit verstärkter Tests festgestellt.

Die beim Testen gesammelten Ergebnisse können auch formaler ausgewertet werden. Dazu werden Software-Zuverlässigkeitsmodelle verwendet, die eine Zuverlässigkeitsvorhersage auf Basis realer Daten zur Fehlerrate durchführen.

Es gibt 2 Prinzipien des Programmtestens:

Funktionstests (Black-Box-Tests);

Strukturtests (White-Box-Tests).

Beim White-Box-Testing ist die interne Struktur des Programms bekannt. Testgegenstand ist hier nicht das externe, sondern das interne Verhalten des Programms. Die Korrektheit des Aufbaus aller Elemente des Programms und die Korrektheit ihres Zusammenwirkens werden überprüft.

Black-Box-Tests (Funktionstests) ermöglichen es Ihnen, Kombinationen von Eingabedaten zu erhalten, die eine vollständige Überprüfung aller funktionalen Anforderungen für das Programm bieten //. Das Softwareprodukt wird hier als "Black Box" behandelt, deren Verhalten nur durch Untersuchung seiner Eingaben und entsprechenden Ausgaben bestimmt werden kann.

Das „Black Box“-Prinzip ist keine Alternative zum „White Box“-Prinzip. Vielmehr handelt es sich um einen komplementären Ansatz, der eine andere Klasse von Fehlern erkennt.

Beim Black-Box-Testen wird nach den folgenden Fehlerkategorien gesucht:

Falsche oder fehlende Funktionen;

Schnittstellenfehler;

Fehler in externen Datenstrukturen oder beim Zugriff auf eine externe Datenbank;

Leistungsfehler (erforderliche Speicherkapazität etc.);

Initialisierungs- und Beendigungsfehler.

Anders als White-Box-Tests, die früh im Testprozess durchgeführt werden, werden Black-Box-Tests spät im Testprozess angewendet. Beim Black-Box-Testen wird die Kontrollstruktur des Programms vernachlässigt. Hier konzentriert sich die Aufmerksamkeit auf den Informationsbereich der Softwaresystemdefinition. Das Testen in dieser Phase konzentriert sich auf die Eignung der Lösung für den Einsatz in einer Live-Produktionsumgebung. Der Schwerpunkt liegt auf der Behebung von Fehlern und der Bestimmung ihres Schweregrads sowie der Bereitstellung des Produkts für die Veröffentlichung.

Während der Testphase werden zwei Hauptaufgaben gelöst:

Testen der Lösung - Testpläne, die während der Planungsphase erstellt und während der Entwicklungsphase erweitert und getestet wurden, werden ausgeführt;

Pilotbetrieb – Einsatz der Lösung in einer Testumgebung und Erprobung unter Einbeziehung zukünftiger Nutzer und Umsetzung realer Szenarien zur Nutzung des Systems. Diese Aufgabe wird vor Beginn der Bereitstellungsphase durchgeführt.

Der Zweck der Testphase besteht darin, das Risiko zu reduzieren, das auftritt, wenn die Lösung in den kommerziellen Betrieb geht.

Für den Erfolg der Testphase ist es notwendig, dass sich die Einstellung zum Projekt ändert und der Entwickler von der Entwicklung neuer Funktionen auf die Sicherstellung der richtigen Qualität der Lösung umstellt.

In dieser Phase der Entwicklung des Informationssystems müssen die folgenden Arten von Tests durchgeführt werden:

Grundlegende Tests - technische Tests auf niedriger Ebene. Sie wird vom Entwickler selbst beim Schreiben des Programmcodes durchgeführt. Es wird die White-Box-Methode verwendet, das Fehlerrisiko ist hoch.

Usability-Tests sind Tests auf hoher Ebene, die vom Tester und zukünftigen Benutzern des Produkts durchgeführt werden. Es wird die Black-Box-Methode verwendet.

Alpha- und Beta-Tests – in MSF-Begriffen ist Alpha-Code im Grunde der gesamte Quellcode, der während der Entwicklungsphase des MSF-Prozessmodells erstellt wurde, und Beta-Code ist der Code, der während der Testphase getestet wurde. Daher wird während der Entwicklungsphase des MSF-Prozessmodells der Alpha-Code und während der Testphase der Beta-Code getestet.

Interoperabilitätstests – Die zu entwickelnde Lösung muss in der Lage sein, sich mit bestehenden Systemen und Softwarelösungen zu integrieren und mit diesen zu interagieren. Der Fokus dieser Testform liegt auf der Überprüfung der Integrierbarkeit und Interaktionsfähigkeit der entwickelten Lösung mit bestehenden Systemen. In diesem speziellen Fall wird der korrekte Betrieb der Anwendung auf dem Gerät des Benutzers und der vom Benutzer verwendeten Software überprüft.

Leistungstests - konzentriert sich auf die Überprüfung, ob die Anwendung die Anforderungen an Leistung und Geschwindigkeitskomfort erfüllt.

Dokumentation und Hilfesystem testen - Alle entwickelten Begleitdokumente und Hilfesysteme werden getestet.

Pilotieren ist das Testen einer Lösung in einer Produktionsumgebung. Der Hauptzweck des Pilotbetriebs besteht darin, zu zeigen, dass die Lösung für einen stabilen Betrieb in industriellen Umgebungen geeignet ist und die Anforderungen des Unternehmens erfüllt. Im Pilotbetrieb wird die Lösung unter realen Bedingungen getestet. Der Pilotbetrieb ermöglicht es Benutzern, ihre Meinung zum Betrieb des Produkts zu äußern. Basierend auf dieser Meinung beseitigt der Entwickler alle möglichen Probleme oder erstellt einen Aktionsplan für den Fall unvorhergesehener Umstände. Letztendlich ermöglicht Ihnen der Pilotbetrieb die Entscheidung, ob Sie mit einer umfassenden Bereitstellung beginnen oder die Bereitstellung verschieben möchten, bis Probleme behoben sind, die die Bereitstellung beeinträchtigen könnten.

Der Pilotbetriebsprozessplan für das entwickelte Informationssystem ist in Tabelle 3.2 angegeben.

Tabelle 3.2 – Pilotbetriebsplan

Aktion		Beschreibung
1. Wahl der Erfolgskriterien		Entwickler und Teilnehmer des Pilottests legen die Erfolgskriterien fest und einigen sich darauf
2. Benutzer und Installationsort auswählen		Ein Team von Teilnehmern an experimentellen Tests durch Benutzer und Entwickler wird gebildet. Der Einsatzort des Pilotverfahrens wird bestimmt.
3. Vorbereiten von Benutzern und Installationsstandorten		Schulung der Benutzer - Teilnehmer des Tests wird durchgeführt. Der Aufstellungsort wird vorbereitet.
4. Stellen Sie die Beta-Version bereit		Die Testversion wird installiert und in Betrieb genommen.
5. Support und Überwachung der Testversion		Überwachung der Arbeit der Benutzer und des Systems, Unterstützung beim Betrieb, Sammeln von Informationen über den Betrieb des Systems
6. Feedback von Benutzern und Bewertung der Ergebnisse		Benutzer äußern ihre Meinung über den Betrieb des Systems, weisen auf Mängel und Fehler hin.
7. Änderungen und Ergänzungen vornehmen	Gefundene Fehler werden korrigiert, Änderungen am Design oder Prozess vorgenommen. Die korrigierten Ergebnisse werden den Benutzern zur Bearbeitung und Auswertung zur Verfügung gestellt.
8. Einsatzentscheidungen	Wenn die Ergebnisse der Pilotversuchsarbeit die Benutzer zufriedenstellen, wird entschieden, das System einzusetzen.

3.2 Anwendungsbereitstellungstechnik

In dieser Phase setzt der Entwickler (oder das Team) die für die Lösung erforderlichen Technologien und Komponenten ein, das Projekt geht in die Wartungs- und Supportphase über und der Kunde genehmigt es schließlich. Nach der Bereitstellung bewertet das Team das Projekt und befragt die Benutzer, um ihre Zufriedenheit zu ermitteln.

Ziele der Bereitstellungsphase:

¾  die Lösung in die industrielle Umgebung überführen;

¾ - Anerkennung des Abschlusses des Projekts durch den Kunden.

Die Bereitstellung standortspezifischer Komponenten besteht aus mehreren Phasen: Vorbereitung, Installation, Schulung und formelle Genehmigung.

Die Ergebnisse der Systembereitstellungsphase sind Wartungs- und Supportsysteme, ein Dokumentenspeicher, in dem sich alle Versionen von Dokumenten und Code befinden, die während des Projekts entwickelt wurden.

Um das in Entwicklung befindliche System einzusetzen, wurde ein Aktionsplan erstellt, der in Tabelle 3.1 dargestellt ist.

Tabelle 3.1 – Anwendungsbereitstellungsplan

Aktion	Aktionsbeschreibung
1. Sicherung	Benutzerdaten werden mit seiner Teilnahme und Zustimmung gesichert, indem Informationen auf Wechselmedien (CD, DVD) übertragen werden
2. Installieren der Basiskomponenten der Lösung	Anwenden von Technologien, die die Lösung funktionieren lassen. Installieren Sie in diesem Fall die Visual FoxPro-Komponente
3. Installieren der Client-Anwendung	Übertragung auf den Computer des Benutzers und Installation der endgültigen Version des entwickelten IS und der Datenbank
4. Ausbildung	Die Benutzer werden für die Arbeit mit dem System geschult, der Entwickler ist von der Korrektheit und dem Verständnis der Bedienung des IS durch die Kunden überzeugt
5. Übertragung der Wissensbasis des Projekts an den Auftraggeber	Die gesamte Projektdokumentation wird dem Kunden übergeben
6. Schließen des Projekts	Erstellen eines Projektabschlussberichts. Der Kunde unterschreibt das Abnahmeprotokoll.

Für das normale Funktionieren der Workstation ist das Betriebssystem Microsoft WindowsXP erforderlich.

4 Informationsprojektmanagement

4.1 Wahl des Entwicklungslebenszyklus

Eines der Grundkonzepte der IS-Designmethodik ist das Konzept des Lebenszyklus seiner Software (LC-Software). Der Lebenszyklus von Software ist ein kontinuierlicher Prozess, der mit der Entscheidung über die Notwendigkeit ihrer Erstellung beginnt und mit der vollständigen Außerbetriebnahme endet.

Das wichtigste Regulierungsdokument, das den Softwarelebenszyklus regelt, ist die internationale Norm ISO / IEC 12207 (ISO - International Organization of Standardization - International Organization for Standardization, IEC - International Electrotechnical Commission - International Electrotechnical Commission). Es definiert eine Lebenszyklusstruktur, die die Prozesse, Aktivitäten und Aufgaben enthält, die während der Softwareentwicklung abgeschlossen werden müssen.

Der ISO/IEC 12207-Standard bietet kein spezifisches Lebenszyklusmodell und keine Softwareentwicklungsmethoden. Das Lebenszyklusmodell kann als eine Struktur verstanden werden, die die Reihenfolge der Ausführung und das Verhältnis von Prozessen, Aktionen und Aufgaben, die während des gesamten Lebenszyklus durchgeführt werden, bestimmt. Das Lebenszyklusmodell hängt von den Besonderheiten des IS und den Besonderheiten der Bedingungen ab, unter denen es erstellt und betrieben wird.

Heutzutage gibt es viele Software-Lebenszyklusmodelle, aber die beiden beliebtesten und am weitesten verbreiteten sind:

Spiralmodell (siehe Abbildung 4.1);

Iteratives Modell.

Abbildung 4.1 – Spiralmodell des Software-Lebenszyklus

Um ein Informationssystem zu erstellen, d.h. „Automatisierter Arbeitsplatz eines Lagermitarbeiters Großhandelsdepot“ wurde ein iterativer gewählt. Das Unterscheidungsmerkmal des iterativen Modells besteht darin, dass es sich um eine formale Methode handelt, die aus unabhängigen Phasen besteht, die nacheinander durchgeführt werden, und häufig überprüft wird (Abbildung 4.2). Das iterative Vorgehen hat sich beim Aufbau von ISs bewährt, bei denen bereits zu Beginn der Entwicklung alle Anforderungen recht genau und vollständig formuliert werden können, um den Entwicklern die Freiheit zu geben, diese technisch bestmöglich umzusetzen.

Vorteile des iterativen Modells:

Das Modell ist Nicht-Entwicklern und Endbenutzern bekannt.

Bequemlichkeit und Benutzerfreundlichkeit, weil alle Arbeiten werden in Etappen durchgeführt (entsprechend den Phasen des Modells);

Anforderungsstabilität;

Das Modell ist verständlich;

Der Aufbau des Modells kann auch von technisch wenig geschultem Personal (einem unerfahrenen Benutzer) geführt werden;

Das Modell behandelt Komplexität auf geordnete Weise und funktioniert gut für Projekte, die einigermaßen verständlich sind;

Das Modell fördert eine strenge Kontrolle des Projektmanagements;

Erleichtert die Arbeit des Projektleiters, um das Entwicklungsteam zu planen und zu vervollständigen.

Abbildung 4.2 – Iteratives Modell des Software-Lebenszyklus

Modellphasen:

In der Phase der Analyse werden die vom System auszuführenden Funktionen bestimmt, diejenigen mit der höchsten Priorität identifiziert, die an erster Stelle ausgearbeitet werden müssen, und der Informationsbedarf wird beschrieben;

In der Entwurfsphase werden die Prozesse des Systems genauer betrachtet. Das Funktionsmuster wird analysiert und ggf. korrigiert. Prototypen des Systems werden gebaut;

In der Implementierungsphase wird das System entwickelt;

In der Implementierungsphase wird das fertige Produkt in das bereits bestehende System der Organisation eingeführt. Benutzerschulung wird bereitgestellt;

In der Wartungsphase wird das Softwareprodukt gewartet (jede Ergänzung oder Änderung, um das Produkt funktionaler zu machen).

Die Wahl eines Lebenszyklusmodells für die Softwareentwicklung ist ein wichtiger Schritt. Daher kann für ein Projekt die Wahl eines Lebenszyklusmodells für die Softwareentwicklung anhand der folgenden Prozesse getroffen werden.

Analyse der unterscheidenden Kategorien des Projekts, platziert in den Tabellen.

Beantworten Sie die Fragen zu jeder Kategorie, indem Sie die Wörter „ja“ und „nein“ unterstreichen.

Priorisieren Sie die Kategorien oder Probleme im Zusammenhang mit jeder Kategorie in Bezug auf das Projekt, für das ein akzeptables Modell ausgewählt wird.

Entwicklungsteam. Auf Basis der Fähigkeiten erfolgt die Personalauswahl für das Entwicklungsteam bereits vor der Wahl des Softwareentwicklungslebenszyklusmodells. Die Eigenschaften eines solchen Teams (siehe Anhang G, Tabelle G.1) spielen eine wichtige Rolle im Prozess der Auswahl eines Lebenszyklusmodells, was bedeutet, dass das Team eine wesentliche Hilfestellung bei der Auswahl eines Softwareprodukt-Lebenszyklusmodells leisten kann, da es ist verantwortlich für die erfolgreiche Umsetzung des entwickelten Lebenszyklusmodells.

Benutzerteam. In den frühen Stadien eines Projekts kann ein vollständiges Bild der Benutzergemeinschaft (siehe Anhang UND Tabelle H.1), die mit der entwickelten Software arbeiten wird, und ihrer zukünftigen Beziehung zum Entwicklungsteam während des gesamten Projekts erhalten werden. Diese Darstellung hilft bei der Auswahl des geeigneten Modells, da einige Modelle eine erhöhte Benutzerbeteiligung am Entwicklungsprozess und Studium des Projekts erfordern, da die Anforderungen vom Benutzer während des Entwicklungsprozesses geringfügig geändert werden können und der Entwickler diese Änderungen kennen muss und wie um diese Änderungen in der Software darzustellen.

4.2 Definition von Zweck und Umfang des Softwareprojekts

Das Softwareprodukt, das für die Buchhaltung von Waren in einem Lager entwickelt wird, wird den Prozess des Empfangens, Strukturierens und Speicherns von Daten über Waren in einem Lager automatisieren und den Prozess der Erstellung von Berichten vereinfachen.

Die Ziele des Softwareprojekts werden sein - die Erstellung und der Einsatz eines Systems zur Warenbuchhaltung. Dieses System ist für den internen Gebrauch durch Cleonelly-Mitarbeiter bestimmt, hauptsächlich Mitarbeiter des Lagers des Unternehmens.

Um den Umfang des Softwareprodukts zu definieren, wird nachstehend beschrieben, was das Softwareprojekt sein sollte oder nicht sein sollte.

Das Softwareprojekt muss:

Für den internen Gebrauch innerhalb der Organisation;

Ein Projekt zur Implementierung des Multi-User-Zugangs;

Ein Projekt, das Informationen über das Produkt des Unternehmens eingeben, ändern und speichern kann;

Ein Projekt, das Informationen über Benutzer des Systems eingeben, ändern und speichern kann;

Ein Projekt, das Informationen über Kunden und Lieferanten der Organisation, die Gegenstand von Transaktionen sind, eingeben, ändern und speichern kann;

Ein Projekt, das externe Berichterstattung generiert.

4.3 Erstellung der Struktur des operativen Werkverzeichnisses

Um ein einzigartiges Produkt oder eine einzigartige Dienstleistung (das Ergebnis des Projekts) zu erstellen, müssen Sie eine bestimmte Arbeitsfolge ausführen. Die Aufgabe der Projektplanung besteht darin, den Zeitplan und die Kosten dieser Arbeiten genau abzuschätzen. Je genauer die Schätzung, desto höher die Qualität des Projektplans. Um eine genaue Schätzung abgeben zu können, müssen Sie den Umfang des Projekts gut verstehen, dh genau wissen, welche Arbeiten durchgeführt werden müssen, um das gewünschte Ergebnis zu erzielen. Erst nachdem die Liste der Projektarbeiten erstellt wurde, wird die Dauer jeder von ihnen geschätzt und die für ihre Umsetzung erforderlichen Ressourcen zugewiesen. Und nur dann können Sie die Kosten und den Zeitplan jeder Aufgabe und als Ergebnis der Addition die Gesamtkosten und die Dauer des Projekts abschätzen. Deshalb ist die Definition des Arbeitsumfangs der erste Schritt in der Projektplanung. Die Bestimmung des Umfangs der Entwurfsarbeit beginnt mit der Definition der Phasen (oder Phasen) des Projekts. Beispielsweise können im Projekt zur Erstellung des Systems "Buchhaltung von Waren im Lager" die folgenden Phasen unterschieden werden:

Entwicklung von Softwareanforderungen;

Entwurf von Informationssystemen;

Implementierung und Zertifizierung des Informationssystems;

Systemimplementierung.

Nachdem die Zusammensetzung der Phasen und deren Ergebnisse festgelegt sind, gilt es, die Abfolge dieser Phasen zueinander und die Fristen für deren Umsetzung festzulegen. Dann müssen Sie bestimmen, aus welchen Werken die Phasen bestehen, in welcher Reihenfolge diese Werke aufgeführt werden und welche Fristen bei ihrer Ausführung eingehalten werden müssen.

Die Arbeitsliste der Arbeiten (Abbildung 4.3) wurde mit einem Softwareprodukt wie MS Project 2003 erstellt.

Abbildung 4.3 - Betriebsliste der Arbeiten

4.4 Schätzung der Dauer und Kosten der Softwareentwicklung

Dauerschätzung. Es wird nach der Erstellung der Betriebsliste der Arbeiten festgelegt (Abbildung 4.3, Absatz 4.3). Diese Dauerschätzung kann anhand des Gantt-Diagramms (Anhang K) eingesehen werden.

Diagramme sind ein grafisches Mittel zum Anzeigen der in einer Projektdatei enthaltenen Informationen. Anhand von Diagrammen können Sie sich eine visuelle Vorstellung von der Abfolge der Aufgaben, ihrer relativen Dauer und der Dauer des gesamten Projekts machen.

Das Gantt-Diagramm ist eine der beliebtesten grafischen Darstellungen eines Projektplans und wird in vielen Projektmanagementprogrammen verwendet.

In MS Project ist das Gantt-Diagramm das wichtigste Mittel zur Visualisierung des Projektplans. Dieses Diagramm ist ein Diagramm mit einer horizontalen Zeitachse und einer vertikalen Aufgabenliste. In diesem Fall ist die Länge der Segmente, die Aufgaben bezeichnen, proportional zur Dauer der Aufgaben.

Im Gantt-Diagramm können neben den Balken zusätzliche Informationen angezeigt werden (neben den Aufgaben werden die Namen der daran beteiligten Ressourcen und deren Belastung bei Erledigung der Aufgabe angezeigt).

Geschätzte Kosten

Das Projekt besteht aus Aufgaben , das heißt, Aktivitäten, die darauf abzielen, ein bestimmtes Ergebnis zu erzielen. Damit eine Aufgabe erledigt werden kann, Ressourcen .

Eine wichtige Eigenschaft von Ressourcen sind die Kosten (Kosten (Kosten)) ihrer Verwendung im Projekt. Es gibt zwei Arten von Ressourcenkosten in MS Project: Zeitaufwand und Kosten pro Nutzung.

Der Zeitsatz (Rate) wird in den Kosten für die Nutzung der Ressource pro Zeiteinheit ausgedrückt, z. B. 100 Rubel pro Stunde oder 1000 Rubel pro Tag. In diesem Fall sind die Kosten für die Teilnahme der Ressource am Projekt die Zeit, während der sie im Projekt arbeitet, multipliziert mit dem Stundensatz.

In diesem Fall wurde der Zeitsatz verwendet (Abbildung 4.4) Die Gesamtkosten der Ressourcennutzung sind in Abbildung 4.5 ersichtlich.

Abbildung 4.4 – Zeitrate bei der Ressourcennutzung

In dieser Abbildung sehen Sie, dass der Systementwickler während des Projekts 50 Rubel pro Stunde erhält; Ein Business Analyst erhält 45 Rubel pro Stunde, ein Tester 38 Rubel pro Stunde. Überstunden werden nicht berücksichtigt.

Abbildung 4.5 – Gesamtkosten der Nutzung von Projektressourcen

4.5 Zuweisung von Projektressourcen

Ein Fragment der Ressourcenverteilung für das System „Warenbuchhaltung im Lager“ ist in Abbildung 4.6 zu sehen

Abbildung 4.6 – Ein Fragment der Verteilung von Projektressourcen

Für jede im Projekt durchgeführte Arbeit wird eine Ressource zugeordnet, die diese Arbeit ausführt. Die Abbildung zeigt den Gesamtarbeitsaufwand für jede der Ressourcen und die spezifische Anzahl der an einem bestimmten Tag aufgewendeten Stunden.

4.6 Bewertung der Wirtschaftlichkeit des Vorhabens

Die Berechnung der Wirtschaftlichkeit des Projektes ist ein wichtiger Schritt. Hier wird die Wirtschaftlichkeit des Projekts berechnet. Diese Berechnung zeigt, wie profitabel das Projekt ist oder das Projekt völlig unrentabel ist. Bei der Berechnung der Wirtschaftlichkeit des Projekts muss die Amortisationszeit des Projekts berechnet werden. Die Amortisationszeit gibt den Zeitraum an, für den sich das Projekt auszahlt.

Eingabedaten.

Zusätzlicher Gewinn aus der Umsetzung des Projekts (DP) = 38.000 Rubel. Von den Experten des Unternehmens wurde ein zusätzlicher Gewinn prognostiziert.

Startinvestition (IC) = 39396,47 Rubel. Startinvestitionen entsprechen den Gesamtkosten der Nutzung von Projektressourcen (Abbildung 4.5 in Abschnitt 4.6)

Abzinsungssatz (i) = 12 %.

Laufzeit des Projekts (n) = 2 Jahre.

Zusätzlicher Gewinn aus der Umsetzung des Projekts (DP) = 38.000 Rubel.

Jährliche Kosten für die Durchführung des Projekts (Z 1) = 15.000 Rubel.

Jährliche Kosten für die Durchführung des Projekts (Z 2) = 10.000 Rubel.

Jährliche Bareinnahmen (R 1) = 23.000 Rubel.

Jährliche Bareinnahmen (R 2) = 28.000 Rubel.

Bei der Bewertung von Investitionsprojekten wird die Net-Present-Income-Berechnungsmethode verwendet, die eine Cashflow-Diskontierung vorsieht: Alle Einnahmen und Ausgaben werden zu einem Zeitpunkt angegeben.

Die zentrale Kennzahl in der betrachteten Methode ist die NPV-Kennzahl (Net Present Value) – der aktuelle Wert der Cashflows. Dies ist ein verallgemeinertes Endergebnis der Investitionstätigkeit in absoluten Zahlen.

Ein wichtiger Punkt ist die Wahl des Abzinsungssatzes, der die erwartete durchschnittliche Höhe der Kreditzinsen am Finanzmarkt widerspiegeln sollte.

Der Kapitalwert (NPV) wird mit Formel 4.2 berechnet

(4.2)

R k - jährliche Bareinnahmen für n Jahre.

k - die Anzahl der Jahre, für die das Projekt konzipiert ist.

IC - Anfangsinvestition.

i - Diskontsatz.

Nach dieser Formel Barwert= RUB 3460,67

Der NPV-Indikator ist eine absolute Steigerung, da er schätzt, wie viel die reduzierten Einnahmen die reduzierten Kosten decken. Da NPV > 0 ist, sollte das Projekt angenommen werden.

Das Return on Investment (ROI)-Verhältnis wird mit Formel 4.3 berechnet

(4.3)

Berechnet (ROI) = 108,78 %

Tabelle 4.1 - Hilfstabelle zur Berechnung der Amortisationszeit des Projekts

= 1,84

Amortisationszeit n ok = 1,84 Jahre (1 Jahr und 11 Monate)

Da ROI => 100 % (nämlich = 108,78 %) gilt das Projekt als profitabel.

(4.4)

Somit ist der Rentabilitätsindex (PI) = 1,2

Die Elemente, die den Betrieb eines IS für beliebige Zwecke sicherstellen, sind in der Definition aufgeführt. Einige von ihnen - Mittel, Methoden und Personal - stellen den Betrieb des IS sicher, während andere - Speicherung, Verarbeitung und Ausgabe von Informationen - Funktionsmerkmale, d.h. bestimmen, welche Informationsprozesse das Funktionieren des IS ausmachen. Daher wird die IS-Struktur in zwei verschiedenen Plänen betrachtet: die funktionale Struktur und die IS-Struktur als eine Reihe von unterstützenden Subsystemen.

Die funktionalen Elemente des IS sind definitionsgemäß folgende Gruppen (Blöcke) von Prozessen:

Eingabe von Informationen aus externen oder internen Quellen;

Eingabeinformationen verarbeiten und in einer geeigneten Form darstellen;

Ausgabe von Informationen zur Präsentation für Verbraucher oder zur Übertragung an ein anderes IS;

Feedback sind Informationen, die von den Mitarbeitern dieser Organisation verarbeitet werden, um die eingegebenen Informationen zu korrigieren.

funktionelle Struktur Das Informationssystem wird in Form eines Blockdiagramms (Abb. 1) dargestellt, in dem jedes Element des Systems als Block (in Abb. - ein Rechteck) dargestellt wird und die Verbindungen und ihre Richtungen durch Pfeile angezeigt werden.

Separate Teile (Blöcke des Systems) werden Subsysteme genannt.

In jedem konkreten Fall hängen die Menge und die Wechselbeziehungen funktionaler Teilsysteme vom Fachgebiet und den Besonderheiten der Tätigkeit des Unternehmens ab, dessen Tätigkeit durch das Informationssystem bereitgestellt wird.

Die IS-Struktur kann auch als Komplex von unterstützenden Subsystemen dargestellt werden (Abb. 2).

Abb.1. Verallgemeinertes Funktionsblockdiagramm des IC.

Für AIS, die sich in der Natur und den Arten der Informationsverarbeitung unterscheiden, unterscheidet sich das Funktionsdiagramm jedoch in einem Satz von Verarbeitungssubsystemen. Beispielsweise produzieren AIPS (Bibliothek, Museum, Nachschlagewerk usw.) Eingabe, Systematisierung, Speicherung, Suche und Ausgabe von Informationen auf Anfrage des Benutzers ohne komplexe Datentransformationen. Informationslösende Systeme: ASOD, ACS, DSS - führen die Verarbeitung von Datenbankinformationen nach einem bestimmten Algorithmus durch, unterscheiden sich jedoch auch in der Zusammensetzung von Informationsverarbeitungs-Subsystemen. Ein auf Konstruktionsautomatisierung spezialisiertes CAD hat spezielle Subsysteme in seiner Struktur: technische Dokumentation, Aufgabengenerierung, Simulationsmodellierung, Berechnung und in einigen Fällen kann es ein Expertensystem geben (siehe Blockdiagramm in Abb. 2).

Abb.2. CAD-Blockdiagramm

Betrachten wir eine andere Art von IS-Struktur: als Komplex von unterstützenden Subsystemen (Abb. 3).

Die Struktur eines Informationssystems kann unabhängig vom Umfang als eine Reihe von Subsystemen betrachtet werden. Ein Subsystem ist ein Teil eines Systems, das sich durch ein bestimmtes Merkmal auszeichnet. Man spricht in diesem Fall von einem Strukturmerkmal der Klassifikation, und die Teilsysteme werden als Bereitstellen bezeichnet.

Somit kann die Struktur eines beliebigen Informationssystems durch einen Satz unterstützender Subsysteme dargestellt werden.

Abb. 3. IS-Struktur nach Art der unterstützenden Subsysteme.

Unter den unterstützenden Subsystemen werden üblicherweise informationelle, technische, mathematische, softwaretechnische, organisatorische und rechtliche Unterstützung unterschieden.

Informationsunterstützung- eine Reihe von Informationsdaten-Arrays, ein einheitliches System zur Klassifizierung und Kodierung von Informationen, einheitliche Dokumentationssysteme, Schemata für den Informationsfluss, der in einer Organisation zirkuliert, sowie eine Methodik zum Aufbau von Datenbanken. Der Zweck des Informationsunterstützungs-Subsystems besteht darin, verlässliche Informationen zum Treffen von Managemententscheidungen rechtzeitig zu generieren und auszugeben.

Einheitliche Dokumentationssysteme werden auf staatlicher, republikanischer, Branchen- und regionaler Ebene geschaffen. Das Hauptziel ist die Gewährleistung der Vergleichbarkeit von Indikatoren verschiedener Bereiche der gesellschaftlichen Produktion. Es wurden Standards entwickelt, in denen die Anforderungen festgelegt sind:

zu einheitlichen Dokumentationssystemen;

zu einheitlichen Formen von Dokumenten verschiedener Managementebenen;

zur Zusammensetzung und Struktur von Angaben und Kennzahlen;

zum Verfahren zur Einführung, Aufrechterhaltung und Registrierung einheitlicher Urkundenformen.

Trotz der Existenz eines einheitlichen Dokumentationssystems offenbart eine Umfrage bei den meisten Organisationen eine ganze Reihe typischer Mängel:

extrem großes Dokumentenvolumen zur manuellen Bearbeitung;

dieselben Indikatoren werden häufig in verschiedenen Dokumenten dupliziert;

die Arbeit mit einer großen Anzahl von Dokumenten lenkt Spezialisten von der Lösung unmittelbarer Probleme ab;

Es gibt Indikatoren, die erstellt, aber nicht verwendet werden usw.

Die Beseitigung dieser Mängel ist eine der Aufgaben bei der Schaffung von Informationsträgern.

Informationsflussdiagramme spiegeln die Bewegungswege von Informationen, ihr Volumen, die Herkunftsorte der Primärinformationen und die Verwendung der resultierenden Informationen wider. Durch die Analyse der Struktur solcher Systeme können Maßnahmen zur Verbesserung des gesamten Managementsystems entwickelt werden.

Die Konstruktion und detaillierte Analyse von Schemata des Informationsflusses, die es ermöglichen, Informationswege und -mengen zu identifizieren, Indikatoren und Prozesse für ihre Verarbeitung zu duplizieren, bietet:

Ausschluss doppelter und ungenutzter Informationen;

Klassifizierung und rationale Darstellung von Informationen.

Methodik des Datenbankaufbaus basiert auf den theoretischen Grundlagen ihrer Gestaltung.

Grundbegriffe der Methodik:

ein klares Verständnis der Ziele, Ziele und Funktionen des gesamten Managementsystems der Organisation;

Identifizierung der Informationsbewegung vom Zeitpunkt des Auftretens bis zu ihrer Verwendung auf verschiedenen Managementebenen, die zur Analyse in Form von Informationsflussschemata präsentiert werden;

Verbesserung des Dokumentenmanagementsystems;

Verfügbarkeit und Nutzung eines Klassifikations- und Codierungssystems;

Besitz der Methodik zur Erstellung konzeptioneller informationslogischer Modelle, die die Beziehung von Informationen widerspiegeln;

Erstellung von Informationsarrays auf Maschinenmedien, was moderne technische Unterstützung erfordert.

Dieses Konzept wird in zwei Stufen praktisch umgesetzt.

Stufe 1 - eine Erhebung aller Funktionsbereiche des Unternehmens, um:

die Besonderheiten und die Struktur seiner Aktivitäten verstehen;

ein Diagramm der Informationsflüsse erstellen;

Analysieren Sie das bestehende Dokumentenmanagementsystem;

Informationsobjekte und die entsprechende Zusammensetzung von Details (Parameter, Merkmale) bestimmen, die ihre Eigenschaften und ihren Zweck beschreiben.

2. Stufe - Aufbau eines konzeptionellen informationslogischen Datenmodells basierend auf den Ergebnissen der Erhebung der 1. Stufe. In diesem Modell müssen alle Verbindungen zwischen Objekten und deren Details hergestellt und optimiert werden. Das informationslogische Modell ist die Grundlage, auf der die Datenbank erstellt wird.

Technischer Support- eine Reihe von technischen Mitteln, die für den Betrieb des Informationssystems ausgelegt sind, sowie die entsprechende Dokumentation für diese Werkzeuge und technologischen Prozesse

Der Komplex der technischen Mittel besteht aus:

Computer aller Modelle;

Geräte zum Sammeln, Sammeln, Verarbeiten, Übertragen und Ausgeben von Informationen;

Datenübertragungsgeräte und Kommunikationsleitungen;

Bürogeräte und -geräte für den automatischen Datenabruf;

Betriebsstoffe usw.

Die Dokumentation umfasst die Vorauswahl der technischen Mittel, die Organisation ihres Betriebs, den technologischen Prozess der Datenverarbeitung, die technologische Ausrüstung. Dokumentation lässt sich grob in drei Gruppen einteilen:

systemweit, einschließlich staatlicher und industrieller Standards für technischen Support;

spezialisiert, mit einer Reihe von Methoden für alle Phasen der Entwicklung des technischen Supports;

normative Referenz, die bei der Durchführung von Berechnungen für den technischen Support verwendet wird.

Bis heute haben sich zwei Hauptformen der Organisation technischer Unterstützung (Formen des Einsatzes technischer Mittel) entwickelt: zentralisiert und teilweise oder vollständig dezentralisiert.

Die zentrale technische Unterstützung basiert auf der Nutzung von Großrechnern und Rechenzentren im Informationssystem. Diese Organisationsform erleichtert die Verwaltung und Umsetzung der Normung, reduziert jedoch die Verantwortung und Initiative der Mitarbeiter.

Die Dezentralisierung technischer Mittel beinhaltet die Implementierung funktionaler Subsysteme auf Personal Computern direkt an den Arbeitsplätzen. Hier wird von den Mitarbeitern mehr Eigenverantwortung gefordert, für das Management wird es schwieriger, Standardisierungen durchzusetzen.

Derzeit ist ein teilweise dezentralisierter Ansatz üblicher – die Organisation des technischen Supports auf der Grundlage verteilter Netzwerke, die aus Personalcomputern und einem Mainframe-Computer zum Speichern von Datenbanken bestehen, die allen funktionalen Subsystemen gemeinsam sind.

Mathematik und Software- eine Reihe mathematischer Methoden, Modelle, Algorithmen und Programme zur Umsetzung der Ziele des Informationssystems sowie des normalen Funktionierens des Komplexes technischer Mittel.

Zu den Mitteln Software sich beziehen:

Werkzeuge zur Modellierung von Managementprozessen;

typische Steuerungsaufgaben;

Methoden der mathematischen Programmierung, mathematischen Statistik, Warteschlangentheorie etc.

Teil Software umfasst allgemeine System- und spezielle Softwareprodukte sowie technische Dokumentationen.

ZU Allgemeine Systemsoftware enthalten Sätze von benutzerorientierten Programmen, die zur Lösung typischer Probleme der Informationsverarbeitung entwickelt wurden. Sie dienen dazu, die Funktionalität von Computern zu erweitern, den Datenverarbeitungsprozess zu steuern und zu verwalten.

Spezielle Software ist eine Reihe von Programmen, die während der Erstellung eines bestimmten Informationssystems entwickelt wurden. Es umfasst Anwendungssoftwarepakete (APP), die die entwickelten Modelle unterschiedlicher Angemessenheit implementieren und die Funktionsweise eines realen Objekts widerspiegeln.

Technische Dokumentation für die Entwicklung von Software sollte eine Beschreibung der Aufgaben, eine Aufgabe zur Algorithmisierung, ein wirtschaftliches und mathematisches Modell der Aufgabe und Testfälle enthalten.

Organisatorische Unterstützung- Dies ist eine Reihe von Methoden und Werkzeugen, die die Interaktion von Mitarbeitern mit technischen Mitteln und untereinander bei der Entwicklung und dem Betrieb von IS regeln.

Die Organisationsunterstützung setzt folgende Funktionen um:

Analyse des bestehenden Managementsystems der Organisation, in der IS eingesetzt werden soll, und Identifizierung der zu automatisierenden Aufgaben;

Vorbereitung von Aufgaben zur Lösung am Computer, einschließlich der Aufgabenstellung für die Gestaltung von IS und einer Machbarkeitsstudie zu ihrer Wirksamkeit;

Entwicklung von Managemententscheidungen über die Zusammensetzung und Struktur der Organisation, Methodik zur Lösung von Problemen zur Verbesserung der Effizienz des Managementsystems.

Organisatorische Unterstützung wird basierend auf den Ergebnissen einer Vorprojektumfrage in der 1. Phase des Aufbaus einer Datenbank erstellt.

Rechtsbeistand- eine Reihe von Rechtsnormen, die die Erstellung, den rechtlichen Status und die Funktionsweise von Informationssystemen bestimmen, die das Verfahren zur Beschaffung, Umwandlung und Nutzung von Informationen regeln.

Der Hauptzweck der Rechtshilfe ist die Stärkung der Rechtsstaatlichkeit. Die Zusammensetzung der rechtlichen Unterstützung umfasst Gesetze, Dekrete, Beschlüsse staatlicher Behörden, Anordnungen, Anweisungen und andere behördliche Dokumente von Ministerien, Abteilungen, Organisationen und lokalen Behörden. Bei der rechtlichen Unterstützung kann man einen allgemeinen Teil herausgreifen, der das Funktionieren eines beliebigen Informationssystems regelt, und einen lokalen Teil, der das Funktionieren eines bestimmten Systems regelt.

Die rechtliche Unterstützung für die Phasen der Entwicklung des Informationssystems umfasst die Regelungen zu den vertraglichen Beziehungen zwischen dem Entwickler und dem Kunden und die rechtliche Regelung der Abweichungen vom Vertrag.

Die rechtliche Unterstützung der Phasen des Funktionierens des Informationssystems umfasst:

Status des Informationssystems;

Rechte, Pflichten und Verantwortlichkeiten des Personals;

das Verfahren zum Erstellen und Verwenden von Informationen usw.

Diese Gruppe von Subsystemen ist für fast alle AIS-Typen üblich. Die Struktur und Komplexität der unterstützenden Subsysteme hängt jedoch von der Art des AIS, dem Umfang und anderen Faktoren ab. Das Software-Subsystem findet also im AIS der ursprünglichen Softwareentwicklung statt – im AIS mit Standardsoftware fehlt es. Für innerbetriebliche Zwecke kann im AIS das Teilsystem der Rechtshilfe fehlen – in diesem Fall können Sie sich auf das Teilsystem der Organisationshilfe beschränken, in dem unter anderem Fragen der Rechtshilfe gelöst werden; Selbstzweck-AIS, zum Beispiel Informationsdienstsysteme, können ein Untersystem zur rechtlichen Unterstützung haben. AIS, die über eine Faktendatenbank verfügen, verfügen nur über ein Informationsunterstützungs-Subsystem, in dem es erforderlich sein kann, bestimmte sprachliche Probleme zu lösen. Dokumentarische AIPS verfügen über ein entwickeltes Sprachunterstützungs-Subsystem, da diese Systeme komplexe Probleme lösen, um die semantische Relevanz von Benutzeranforderungen für den Inhalt ausgegebener Dokumente sicherzustellen. Und das sind in der Regel nicht nur Softwaremodule für die morphologische Analyse, sondern auch eine Reihe von Wörterbüchern und Regeln für deren Pflege.

Zwecke der Erstellung und Implementierung von IS.

Was kann von der Implementierung von Informationssystemen erwartet werden?

Die Einführung von Informationssystemen kann dazu beitragen:

1. Entlastung der Arbeitnehmer von Routinearbeiten und deren Beschleunigung durch Automatisierung;

2. Ersatz von Papierdatenträgern durch Magnetplatten oder -bänder, was zu einer Verringerung des Dokumentenvolumens auf Papier und damit zur Möglichkeit einer rationelleren Organisation der Informationsverarbeitung auf einem Computer führt;

3. Verbesserung der Struktur der Informationsflüsse und des Dokumentenmanagementsystems im Unternehmen durch die systemische Wirkung: Einmalige Datenerfassung – ihre mehrfache und vielseitige Nutzung“;

4. Gewinnung rationaler Optionen zur Lösung von Managementproblemen (durch die Einführung mathematischer Methoden und intelligenter Systeme usw.):

neue Marktnischen finden;

Optimierung der Kosten für die Herstellung von Produkten und/oder Dienstleistungen;

Optimierung der Beziehungen zu Käufern und Lieferanten.

Entwicklungsstadien von Informationssystemen

Die Entwicklungsgeschichte von IS ist in Etappen gegliedert (Tabelle 2), entsprechend der annähernd akzeptierten Zielnummerierung – die Herangehensweise an den Einsatz von IS verändert sich.

Tabelle 2. Stadien der IS-Entwicklung.

Zeitspanne	Das Konzept der Verwendung von Informationen	Art von Informationssystemen	Anwendungszweck
1950 - 1960	Papierfluss von Abrechnungsdokumenten	Informationssysteme zur Verarbeitung von Abrechnungsbelegen auf elektromechanischen Buchungsmaschinen	Beschleunigung der Dokumentenverarbeitung Vereinfachen Sie die Rechnungsverarbeitung und Gehaltsabrechnung
1960 - 1970	Grundlegende Unterstützung bei der Erstellung von Berichten	Management-Informationssysteme für Produktionsinformationen	Beschleunigung des Meldeprozesses
1970 - 1980	Managementkontrolle der Umsetzung (Vertrieb)	Entscheidungsunterstützungssysteme Top-Management-Systeme	Auswahl der rationellsten Lösung
1980 - 2000	Informationen sind eine strategische Ressource, die einen Wettbewerbsvorteil verschafft	Strategische Informationssysteme Automatisierte Büros	Festes Überleben und Wohlstand

Die ersten Informationssysteme erschienen Mitte des letzten Jahrhunderts. In den 1950er Jahren wurden sie für die Verarbeitung von Rechnungen und Gehaltsabrechnungen entwickelt und auf elektromechanischen Buchhaltungsmaschinen implementiert. Dies führte zu einer gewissen Reduzierung der Kosten und des Zeitaufwands für die Erstellung von Papierdokumenten.

60er sind gekennzeichnet durch eine veränderte Einstellung gegenüber Informationssystemen. Die von ihnen erhaltenen Informationen wurden für die regelmäßige Berichterstattung über viele Parameter verwendet. Heutzutage benötigen Unternehmen Allzweck-Computergeräte, die viele Funktionen ausführen können, und nicht nur Rechnungen verarbeiten und Gehaltsabrechnungen berechnen, wie es in der Vergangenheit der Fall war.

In den 70er - frühen 80er Jahren. Informationssysteme werden zunehmend als Mittel zur Managementkontrolle, zur Unterstützung und Beschleunigung des Entscheidungsprozesses eingesetzt.

Bis Ende der 80er. das konzept der nutzung von informationssystemen ändert sich erneut. Sie werden zu einer strategischen Informationsquelle und werden auf allen Ebenen einer Organisation mit beliebigem Profil verwendet. Informationssysteme dieser Zeit, die die erforderlichen Informationen rechtzeitig bereitstellen, helfen der Organisation, bei ihren Aktivitäten erfolgreich zu sein, neue Produkte und Dienstleistungen zu entwickeln, neue Absatzmärkte zu finden, würdige Partner zu gewinnen, die Freigabe von Produkten zu einem niedrigen Preis zu organisieren und vieles mehr mehr.

Das moderne Verständnis des Informationssystems beinhaltet die Verwendung eines Personal Computers als wichtigstes technisches Mittel zur Verarbeitung von Informationen. In großen Organisationen kann die technische Basis des Informationssystems neben einem Personal Computer einen Mainframe oder Supercomputer umfassen. Darüber hinaus ist die technische Umsetzung des Informationssystems an sich bedeutungslos, wenn die Rolle der Person, für die die erstellten Informationen bestimmt sind und ohne die es unmöglich ist, sie zu erhalten und zu präsentieren, nicht berücksichtigt wird.