Kaskadenmodell AIS. Lebenszyklus automatisierter Informationssysteme (LC AIS). AIS-Lebenszyklusmodelle. Phasen des Lebenszyklus von Informationssystemen

3.1 Definieren eines AIS-Lebenszyklusmodells

unter dem Modell Lebenszyklus Unter Softwareproduktentwicklung wird eine Struktur verstanden, die die Reihenfolge der Ausführung und die Beziehung von Prozessen, Aktionen und Aufgaben bestimmt, die während des gesamten Lebenszyklus der Softwareproduktentwicklung ausgeführt werden. Die folgenden Lebenszyklusmodelle für die Softwareproduktentwicklung werden am häufigsten verwendet (Tabelle 1). Kurze Charakteristika AIS-Lebenszyklusmodelle): Wasserfallmodell oder Wasserfall (Wasserfallmodell); V-förmiges Modell (V-förmiges Modell); Prototyping-Modell (Prototyp-Modell); Rapid Application Development Model oder RAD-Modell (RAD-Rapid Application Development Model); Multi-Pass-Modell (inkrementelles Modell); Spiralmodell.

Tabelle 1. Kurze Eigenschaften jedes der aufgeführten Modelle

Name	Eigenschaften
Kaskadenmodell	Unkompliziert und einfach zu bedienen. Eine ständige strenge Kontrolle des Arbeitsfortschritts ist erforderlich. Die entwickelte Software kann nicht geändert werden
V-förmiges Modell	Einfach zu verwenden. Der Schwerpunkt liegt auf dem Testen und Vergleichen der Ergebnisse der Test- und Entwurfsphasen
Prototyping-Modell	Vor der Erstellung der finalen Anforderungen wird eine „schnelle“ Teilimplementierung des Systems erstellt. Bereitgestellt Rückkopplung zwischen Benutzern und Entwicklern im Verlauf eines Projekts. Die verwendeten Anforderungen sind nicht vollständig
Modell für schnelle Anwendungsentwicklung	Projektteams klein (3 ... 7 Personen) und bestehen aus hochqualifizierten Fachkräften. Reduzierte Entwicklungszykluszeit (bis zu 3 Monate) und verbesserte Leistung. Wiederverwendung von Code und Automatisierung des Entwicklungsprozesses
Multi-Pass-Modell	Ein funktionierendes System ist schnell erstellt. Reduziert die Möglichkeit, während des Entwicklungsprozesses Änderungen vorzunehmen. Eine Migration von der aktuellen Implementierung auf eine neue Version ist nicht möglich, während die aktuelle Teilimplementierung erstellt wird
Spiralmodell	Deckt das Wasserfallmodell ab. Unterteilt die Phasen in kleinere Teile. Ermöglicht flexibles Design. Analysiert und verwaltet Risiken. Durch Prototypen lernen Anwender das Softwareprodukt früher kennen

3.2 Kaskadenmodell

In homogener Form Informationssysteme In den 1970er und 1980er Jahren bildeten Anwendungssoftwareprodukte eine Einheit. Um diese Art von Softwareprodukt zu entwickeln, wurde ein Kaskadenmodell oder „Wasserfall“ verwendet.

Das Kaskadenmodell eines Softwareprodukts ähnelt dem Modell eines automatisierten Steuerungssystems (siehe Kapitel 1, Abb. 1).

Dieser Prozess ist in der Regel iterativer Natur: Die Ergebnisse der nächsten Stufe führen häufig zu Änderungen der in früheren Stufen getroffenen Designentscheidungen. Daher besteht ständig die Notwendigkeit, zu früheren Phasen zurückzukehren und früher zu klären oder zu überarbeiten Entscheidungen getroffen. Dadurch nimmt der eigentliche Entwicklungsprozess eine andere Form an (siehe Kapitel 1, Abbildung 2)

3,3 V-Modell

Dieses Modell (Abb. 5) wurde als Variation des Wasserfallmodells entwickelt, in dem Besondere Aufmerksamkeit ist der Verifizierung und Zertifizierung des Softwareprodukts gewidmet. Das Modell zeigt, dass Produkttests schon früh im Entwicklungslebenszyklus besprochen, entworfen und geplant werden.

Vom Wasserfallmodell hat das V-förmige Modell eine sequentielle Struktur geerbt, nach der jede nachfolgende Phase erst nach erfolgreichem Abschluss der vorherigen Phase beginnt.

Dieses Modell basiert auf einer systematischen Herangehensweise an das Problem, für die vier grundlegende Schritte definiert sind: Analyse, Design, Entwicklung und Überprüfung. Die Analyse umfasst Projektplanung und Anforderungen. Das Design ist in High-Level und Detailliert (Low-Level) unterteilt. Die Entwicklung umfasst Codierung, Überprüfung - Verschiedene Arten testen.

Das Modell zeigt deutlich die Beziehung zwischen den Analysephasen und den Entwurfsphasen, die dem Codieren und Testen vorausgehen. Gestrichelte Pfeile zeigen, dass diese Phasen parallel betrachtet werden sollten.

Das Modell umfasst die folgenden Phasen:

Ausarbeitung der Projektanforderungen und Planung – Systemanforderungen werden ermittelt und Arbeitsplanung durchgeführt;

Vorbereitung der Anforderungen an das Produkt und deren Analyse – es wird eine vollständige Spezifikation der Anforderungen an das Softwareprodukt erstellt;

High-Level-Design – die Struktur ist definiert Software, die Beziehung zwischen seinen Hauptkomponenten und den von ihnen implementierten Funktionen;

Detailliertes Design – der Betriebsalgorithmus jeder Komponente wird festgelegt;

Codierung – die Umwandlung von Algorithmen in fertige Software wird durchgeführt;

Unit-Tests – jede Komponente oder jedes Modul des Softwareprodukts wird getestet;

Integrationstests – die Integration des Softwareprodukts und seine Tests werden durchgeführt;

Systemtests – die Funktionsfähigkeit des Softwareprodukts wird überprüft, nachdem es gemäß der Anforderungsspezifikation in die Hardwareumgebung platziert wurde;

Betrieb und Wartung – Einführung eines Softwareprodukts in die Produktion. Während dieser Phase kann das Softwareprodukt geändert und aktualisiert werden.

Abb.5 V-förmiges Modell

Vorteile des V-förmigen Modells:

1) Der Verifizierung und Zertifizierung des Softwareprodukts kommt eine große Rolle zu. Bereits in den frühen Phasen seiner Entwicklung werden alle Maßnahmen geplant.

2) Bescheinigung und Verifizierung nicht nur des Softwareprodukts selbst, sondern auch aller empfangenen internen und externen Daten werden vorausgesetzt;

3) Der Fortschritt der Arbeiten kann leicht verfolgt werden, da der Abschluss jeder Phase ein Meilenstein ist.

Neben diesen Vorteilen weist das Modell auch eine Reihe von Nachteilen auf:

Iterationen zwischen Phasen werden nicht berücksichtigt; es ist unmöglich, in verschiedenen Phasen des Lebenszyklus Änderungen vorzunehmen; Anforderungstests erfolgen zu spät, daher wirken sich Änderungen auf den Zeitplan aus.

Es ist sinnvoll, dieses Modell bei der Entwicklung von Softwareprodukten zu verwenden, deren Hauptanforderung eine hohe Zuverlässigkeit ist.

Das Produkt und die Erstellung praktischer Karten zum Ausfüllen der Datenbankattribute: die Einfachheit der Erstellung von Links und deren Modernisierung. Kapitel II. Entwicklung eines Programms zur Automatisierung der Aktivitäten der Taxiflotte 2.1 Analyse der Kundenanforderungen Programm automatisiert Arbeitsplatz Der Taxi-Dispatcher wird nach dem Spiralmodell des Lebenszyklus automatisierter Informationssysteme entwickelt. In jeder Phase der Schöpfung...

Systeme. Hauptsächlich normative Dokumente, die den Prozess der Erstellung jedes IS- und IT-Projekts regeln, sind GOSTs und ihre Komplexe für die Erstellung und dokumentieren Informationstechnologie, automatisierte Systeme, Software, Organisation und Datenverarbeitung sowie die maßgeblichen Dokumente der Staatlichen Technischen Kommission Russlands über die Entwicklung, Herstellung und den Betrieb von Software und ...

Beim Aufbau von IS hat sich der Kaskadenansatz bewährt, bei dem es bereits zu Beginn der Entwicklung möglich ist, alle Anforderungen recht genau und vollständig zu formulieren, um Entwicklern den Freiraum zu geben, diese bestmöglich technisch umzusetzen. Diese Kategorie umfasst komplexe Systeme mit einer Vielzahl von Aufgaben rechnerischer Natur eines Echtzeitsystems usw.

AIS-Lebenszyklusmodell- ist eine Struktur, die die Prozesse, Aktivitäten und Aufgaben beschreibt, die während der Entwicklung, des Betriebs und der Wartung über den gesamten Lebenszyklus des Systems ausgeführt werden.

Die Wahl eines Lebenszyklusmodells hängt von den Besonderheiten, dem Umfang, der Komplexität des Projekts und den Bedingungen ab, unter denen das AIS erstellt und betrieben wird.

Das AIS-Lebenszyklusmodell umfasst:

Die Ergebnisse der Arbeit in jeder Phase;

Schlüsselereignisse oder Abschluss- und Entscheidungspunkte.

In Anlehnung an die bekannten Software-Lebenszyklusmodelle werden AIS-Lebenszyklusmodelle ermittelt - Kaskade, iterativ, Spirale.

I. Kaskadenmodell beschreibt den klassischen Ansatz zur Entwicklung von Systemen in beliebigen Fachgebieten; war in den 1970er und 80er Jahren weit verbreitet.

Das Kaskadenmodell sieht eine sequentielle Arbeitsorganisation vor, und das Hauptmerkmal des Modells ist die Aufteilung aller Arbeiten in Phasen. Der Übergang von der vorherigen Stufe zur nächsten erfolgt erst nach vollständigem Abschluss aller Arbeiten der vorherigen Stufe.

Zuordnen fünf stabile Entwicklungsstadien, praktisch unabhängig vom Fachgebiet

An Erste In dieser Phase wird der Problembereich untersucht und die Anforderungen des Kunden formuliert. Das Ergebnis dieser Phase ist die mit allen interessierten Parteien vereinbarte Leistungsbeschreibung (Entwicklungsaufgabe).

Während zweite Stufe, entsprechend den Anforderungen Leistungsbeschreibung werden bestimmte Designlösungen entwickelt. Das Ergebnis ist eine Projektdokumentation.

Dritte Bühne - Projektumsetzung; im Wesentlichen Softwareentwicklung (Codierung) gemäß den Designentscheidungen der vorherigen Phase. Implementierungsmethoden sind nicht von grundlegender Bedeutung. Das Ergebnis der Stufe ist ein fertiges Softwareprodukt.

An vierte In dieser Phase wird die erhaltene Software auf Übereinstimmung mit den in der Leistungsbeschreibung genannten Anforderungen überprüft. Der Probebetrieb ermöglicht es, verschiedene Arten versteckter Mängel aufzudecken, die sich unter realen Bedingungen des AIS-Betriebs manifestieren.

Der letzte Schritt ist die Hingabe fertiges Projekt Dabei geht es vor allem darum, den Kunden davon zu überzeugen, dass alle seine Anforderungen vollumfänglich erfüllt werden.

Abb. 1.1 AIS LC-Kaskadenmodell

Arbeitsphasen innerhalb des Wasserfallmodells werden oft als Teile des AIS-Projektzyklus bezeichnet, da die Phasen aus vielen iterativen Verfahren zur Verfeinerung von Systemanforderungen und Entwurfsoptionen bestehen. Der Lebenszyklus von AIS ist viel komplizierter und länger: Er kann eine beliebige Anzahl von Zyklen der Verfeinerung, Änderung und Ergänzung bereits angenommener und umgesetzter Entwurfsentscheidungen umfassen. In diesen Zyklen findet die Weiterentwicklung des AIS und die Modernisierung seiner einzelnen Komponenten statt.

Vorteile des Wasserfallmodells:

1) In jeder Phase wird eine vollständige Entwurfsdokumentation erstellt, die den Kriterien für Vollständigkeit und Konsistenz entspricht. In der Endphase wird eine Benutzerdokumentation entwickelt, die alle in den Standards vorgesehenen Arten der AIS-Unterstützung abdeckt (organisatorisch, informativ, softwaretechnisch, technisch usw.);

2) Durch die sequentielle Ausführung der Arbeitsschritte können Sie den Zeitpunkt der Fertigstellung und die entsprechenden Kosten planen.

Das Kaskadenmodell wurde ursprünglich zur Lösung verschiedenster technischer Probleme entwickelt und hat bis heute nicht an Bedeutung für den Anwendungsbereich verloren. Darüber hinaus ist der Wasserfall-Ansatz ideal für die Entwicklung von AIS, da bereits zu Beginn der Entwicklung alle Anforderungen recht genau formuliert werden können, um Entwicklern die Freiheit der technischen Umsetzung zu geben. Zu diesen AIS zählen insbesondere komplexe Abwicklungssysteme und Echtzeitsysteme.

Nachteile des Wasserfallmodells:

Erhebliche Verzögerung beim Erhalt der Ergebnisse;

Fehler und Mängel in einer der Phasen treten in der Regel in späteren Arbeitsphasen auf, was eine Rückgabe erforderlich macht;

Die Komplexität der parallelen Arbeit am Projekt;

Übermäßige Informationsüberflutung jeder Stufe;

Die Komplexität des Projektmanagements;

Hohes Risiko und Unzuverlässigkeit der Investitionen.

Verzögerung beim Erhalten von Ergebnissen Dies zeigt sich darin, dass bei einem konsequenten Entwicklungsansatz die Ergebnisse erst nach Abschluss der nächsten Arbeitsstufe mit den Stakeholdern abgestimmt werden. Dadurch kann sich herausstellen, dass das entwickelte AIS nicht den Anforderungen entspricht und solche Inkonsistenzen in jedem Entwicklungsstadium auftreten können; Darüber hinaus können Fehler sowohl von Analysten als auch von Programmierern unbeabsichtigt eingeführt werden, da sie nicht über umfassende Kenntnisse in den Themenbereichen verfügen müssen, für die AIS entwickelt wird.

Kehren Sie zu früheren Phasen zurück. Dieser Mangel ist eine Manifestation des vorherigen: Die schrittweise Arbeit am Projekt kann dazu führen, dass Fehler, die in früheren Phasen gemacht wurden, erst in späteren Phasen erkannt werden. Dadurch kehrt das Projekt in die vorherige Phase zurück, wird bearbeitet und erst dann in die Folgearbeit überführt. Dies kann zu einer Unterbrechung des Zeitplans führen und die Zusammenarbeit zwischen Entwicklungsteams, die einzelne Phasen durchführen, erschweren.

Die schlechteste Option ist, wenn die Mängel der vorherigen Stufe nicht in der nächsten Stufe, sondern später entdeckt werden. Beispielsweise können in der Phase des Probebetriebs Fehler in der Beschreibung des Themenbereichs auftreten. Dies bedeutet, dass ein Teil des Projekts in die Anfangsphase der Arbeit zurückgeführt werden muss.

Die Komplexität paralleler Arbeit verbunden mit der Notwendigkeit, die verschiedenen Teile des Projekts zu koordinieren. Je stärker die Beziehung zwischen einzelnen Teilen des Projekts, je häufiger und sorgfältiger die Synchronisierung durchgeführt werden muss, desto abhängiger sind die Entwicklungsteams voneinander. Dadurch gehen die Vorteile des parallelen Arbeitens einfach verloren; Die fehlende Parallelität wirkt sich auch negativ auf die Arbeitsorganisation des gesamten Teams aus.

Problem Informationsüberlastung entsteht durch die starke Abhängigkeit zwischen verschiedenen Entwicklergruppen. Tatsache ist, dass bei Änderungen an einem Teil des Projekts die Entwickler benachrichtigt werden müssen, die es in ihrer Arbeit verwendet haben (verwenden könnten). Bei einer großen Anzahl miteinander verbundener Subsysteme wird die Synchronisierung der internen Dokumentation zu einer separaten Hauptaufgabe: Entwickler müssen sich ständig mit Änderungen vertraut machen und bewerten, wie sich diese Änderungen auf die erzielten Ergebnisse auswirken.

Komplexität des Projektmanagements Dies ist hauptsächlich auf die strenge Abfolge der Entwicklungsphasen und das Vorhandensein komplexer Beziehungen zwischen verschiedenen Teilen des Projekts zurückzuführen. Der geregelte Arbeitsablauf führt dazu, dass einige Entwicklungsgruppen auf die Arbeitsergebnisse anderer Teams warten müssen, sodass ein administrativer Eingriff erforderlich ist, um den Zeitpunkt und die Zusammensetzung der übertragenen Dokumentation zu vereinbaren.

Bei Feststellung von Fehlern in der Arbeit ist eine Rückkehr zu den vorherigen Phasen erforderlich; die laufende Arbeit derjenigen, die einen Fehler begangen haben, wird unterbrochen. Die Folge davon ist in der Regel eine Verzögerung bei der Umsetzung sowohl der korrigierten als auch der neuen Projekte.

Es ist möglich, die Interaktion zwischen Entwicklern zu vereinfachen und die Informationsüberflutung der Dokumentation zu reduzieren, indem die Anzahl der Verknüpfungen zwischen einzelnen Teilen des Projekts verringert wird. Allerdings kann nicht jedes AIS in lose gekoppelte Subsysteme unterteilt werden.

Hohes Risiko. Je komplexer das Projekt ist, desto länger dauert die jeweilige Entwicklungsstufe und desto komplexer sind die Beziehungen zwischen den einzelnen Projektteilen, deren Anzahl auch zunimmt. Darüber hinaus können die Ergebnisse der Entwicklung tatsächlich erst in der Testphase gesehen und bewertet werden, d. h. nach Abschluss der Analyse-, Design- und Entwicklungsphasen, deren Umsetzung viel Zeit und Geld erfordert.

Eine verspätete Bewertung führt zu ernsthaften Problemen bei der Identifizierung von Analyse- und Entwurfsfehlern – eine Rückkehr zu früheren Phasen und eine Wiederholung des Entwicklungsprozesses sind erforderlich. Eine Rückkehr zu früheren Stadien kann jedoch nicht nur mit Fehlern verbunden sein, sondern auch mit Änderungen, die im Themenbereich oder in den Kundenanforderungen während der Entwicklung aufgetreten sind. Gleichzeitig kann niemand garantieren, dass sich der Themenbereich bis zur Fertigstellung der nächsten Version des Projekts nicht erneut ändert. Tatsächlich bedeutet dies, dass die Möglichkeit eines „Zyklus“ des Entwicklungsprozesses besteht: Die Kosten des Projekts werden ständig steigen und die Fristen für die Lieferung des fertigen Produkts werden sich ständig verzögern.

II. Iteratives Modell (Stufenmodell mit Zwischensteuerung) ist eine Reihe kurzer Zyklen (Schritte) der Planung, Umsetzung, Untersuchung und Aktion.

Die Erstellung komplexer AIS beinhaltet die Koordination von Designlösungen, die bei der Umsetzung einzelner Aufgaben erzielt werden. Der „Bottom-up“-Designansatz erfordert solche Renditeiterationen, bei denen Designlösungen für einzelne Aufgaben zu gemeinsamen Systemlösungen zusammengefasst werden. In diesem Fall besteht die Notwendigkeit, die zuvor formulierten Anforderungen zu überarbeiten.

Vorteil Der Vorteil des iterativen Modells besteht darin, dass stufenübergreifende Anpassungen im Vergleich zum Kaskadenmodell zu einer geringeren Arbeitsintensität der Entwicklung führen.

Mängel Iteratives Modell:

· Die Lebensdauer jeder Stufe erstreckt sich über die gesamte Arbeitsdauer.

· Aufgrund der großen Anzahl an Iterationen kommt es zu Diskrepanzen bei der Umsetzung von Entwurfsentscheidungen und der Dokumentation;

Feinheiten der Architektur

· Schwierigkeiten bei der Verwendung der Projektdokumentation in den Phasen der Implementierung und des Betriebs erfordern eine Neugestaltung des gesamten Systems.

III. Spiralmodell Im Gegensatz zur Kaskade, aber ähnlich der vorherigen, handelt es sich um einen iterativen Prozess der AIS-Entwicklung. Gleichzeitig steigt die Bedeutung der ersten Phasen wie Analyse und Design, die durch die Erstellung von Prototypen die Machbarkeit technischer Lösungen prüfen und begründen.

Jede Iteration ist ein vollständiger Entwicklungszyklus, der zur Veröffentlichung einer internen oder externen Version eines Produkts (oder einer Teilmenge des Endprodukts) führt, das von Iteration zu Iteration verbessert wird, um ein vollständiges System zu werden (Abbildung 1.2).

Reis. 1.2. Spiralmodell des AIS-Lebenszyklus

Somit entspricht jede Windung der Spirale der Erstellung eines Fragments oder einer Version eines Softwareprodukts, legt die Ziele und Merkmale des Projekts fest, bestimmt seine Qualität und plant die Arbeit an der nächsten Windung der Spirale. Jede Iteration dient dazu, die Details des Projekts zu vertiefen und konsistent zu spezifizieren, wodurch eine sinnvolle Option für die endgültige Umsetzung ausgewählt wird.

Durch die Verwendung des Spiralmodells können Sie zur nächsten Phase des Projekts übergehen, ohne auf den Abschluss der aktuellen Phase warten zu müssen – die unvollendete Arbeit kann in der nächsten Iteration erledigt werden. Die Hauptaufgabe jeder Iteration besteht darin, so schnell wie möglich ein funktionsfähiges Produkt zu erstellen, das den Benutzern vorgeführt werden kann. Dadurch wird der Prozess der Einführung von Klarstellungen und Ergänzungen in das Projekt erheblich vereinfacht.

Der spiralförmige Ansatz zur Softwareentwicklung überwindet die meisten Mängel des Wasserfallmodells und bietet darüber hinaus eine Reihe von Vorteilen Zusatzfunktionen den Entwicklungsprozess flexibler gestalten.

Vorteile iterativer Ansatz:

Die iterative Entwicklung vereinfacht die Einführung von Änderungen am Projekt erheblich, wenn sich die Kundenanforderungen ändern.

Beim Spiralmodell werden einzelne Elemente des AIS nach und nach zu einem Ganzen integriert. Da die Integration mit weniger Elementen beginnt, gibt es bei der Implementierung weitaus weniger Probleme;

Reduzierung des Risikoniveaus (eine Folge des vorherigen Vorteils, da Risiken bei der Integration erkannt werden). Das Risikoniveau ist zu Beginn der Projektentwicklung maximal, mit fortschreitender Entwicklung nimmt es ab;

Die iterative Entwicklung bietet eine größere Flexibilität im Projektmanagement, indem sie taktische Änderungen am in der Entwicklung befindlichen Produkt ermöglicht. So ist es möglich, die Entwicklungszeit zu verkürzen, indem man die Funktionalität des Systems reduziert oder Drittprodukte als Komponenten anstelle eigener Entwicklungen verwendet (relevant wenn). Marktwirtschaft wenn es notwendig ist, der Werbung für ein Konkurrenzprodukt zu widerstehen);

Der iterative Ansatz erleichtert die Wiederverwendung von Komponenten, da es viel einfacher ist, die gemeinsamen Teile des Projekts zu identifizieren (zu identifizieren), wenn sie bereits teilweise entwickelt sind, als zu versuchen, sie gleich zu Beginn des Projekts zu isolieren. Die Analyse des Entwurfs nach mehreren ersten Iterationen zeigt gemeinsame wiederverwendbare Komponenten, die in nachfolgenden Iterationen verbessert werden;

Das Spiralmodell ermöglicht Ihnen ein zuverlässigeres und stabileres System. Dies liegt daran, dass im Zuge der Weiterentwicklung des Systems bei jeder Iteration Fehler und Schwachstellen gefunden und behoben werden. Gleichzeitig werden kritische Leistungsparameter angepasst, die im Falle eines Wasserfallmodells nur vor der Implementierung des Systems verfügbar sind;

Ein iterativer Ansatz ermöglicht eine Prozessverbesserung
Entwicklung – als Ergebnis der Analyse am Ende jeder Iteration wird eine Bewertung der Veränderungen in der Entwicklungsorganisation durchgeführt; es verbessert sich bei der nächsten Iteration.

Das Hauptproblem des Spiralkreislaufs- die Schwierigkeit, den Zeitpunkt des Übergangs zur nächsten Stufe zu bestimmen. Um dieses Problem zu lösen, müssen für jede Phase des Lebenszyklus Fristen eingeführt werden. Andernfalls kann der Entwicklungsprozess zu einer endlosen Verbesserung des bereits Erreichten werden.

Durch die Einbeziehung der Benutzer in den Prozess des Entwerfens und Kopierens der Anwendung können Sie Kommentare und Ergänzungen zu den Anforderungen direkt im Prozess des Entwerfens der Anwendung erhalten und so die Entwicklungszeit verkürzen. Vertreter des Kunden erhalten die Möglichkeit, den Entstehungsprozess des Systems zu steuern und dessen Funktionsinhalt zu beeinflussen. Das Ergebnis ist die Inbetriebnahme eines Systems, das die meisten Bedürfnisse der Kunden berücksichtigt.

Lebenszyklusmodell und Designtechnologie

Zuvor haben wir gesagt, dass die Designtechnologie die Reihenfolge der Aktionen festlegt, die für den Erhalt eines IP-Projekts erforderlich sind. Offensichtlich bedeutet die Ausführung jeder dieser Aktionen den Übergang des Informationssystems von einem Zustand in einen anderen. Somit beschreibt jede Designtechnologie eindeutig ein Lebenszyklusmodell. Andererseits durch den Aufbau eines Lebenszyklusmodells für Informationssysteme, d. h. durch die Definition von:

Aufgaben, Zusammensetzung und Reihenfolge der ausgeführten Arbeiten;

· die Ergebnisse jeder durchgeführten Aktion;

Für die Arbeitsausführung erforderliche Methoden und Mittel;

die Rollen und Verantwortlichkeiten der Teilnehmer;

sonstige Informationen, die für die Planung, Organisation und Verwaltung der gemeinsamen Entwicklung von geistigem Eigentum erforderlich sind,

Wir erhalten eine eindeutige Beschreibung der von uns gewählten Designtechnologie. Daher ist das Lebenszyklusmodell ein integraler und wesentlicher Bestandteil der Designtechnologie für Informationssysteme.

Phasen und Phasen des Designs

Die Begriffe „Bühne“ und „Bühne“ des Designs werden oft verwechselt. Manchmal reden sie darüber Stufen oder Phasen Lebenszyklus, Schritte Design. Es stellt sich die Frage: Was ist der richtige Weg?

Es sollte daran erinnert werden, dass es anders ist internationale Standards Die verwendete Terminologie kann variieren. Wir werden uns, wenn möglich, auf die Terminologie inländischer GOSTs konzentrieren. Designphase Wir nennen den Teil des Prozesses der Erstellung eines IS, der auf einen bestimmten Zeitraum begrenzt ist und mit der Veröffentlichung eines bestimmten Produkts (Modell, Dokumentation, Programmtext usw.) endet. Je nach Gemeinsamkeit der Ziele können Entwurfsstufen zu zusammengefasst werden Stufen. Zum Beispiel die Phase „Technisches Design“, die Phase „Implementierung“ usw.

Den veröffentlichten Daten zufolge erfordert jede Phase der AIS-Entwicklung eine gewisse Zeit. Die meiste Zeit (45–50 %) wird für Codierung, komplexe und eigenständige Tests aufgewendet. Im Durchschnitt nimmt die Entwicklung von AIS ein Drittel des gesamten Lebenszyklus des Systems ein.

Reis. Zeitverteilung in der Entwicklung von AIS

AIS-Erstellungsphasen (ISO/IEC 15288)

Der ISO/IEC 12207-Standard definiert ein Lebenszyklus-Framework, das die Prozesse, Aktivitäten und Aufgaben enthält, die während der Erstellung eines Informationssystems ausgeführt werden müssen.

AIS bestehen in der Regel über einen langen Zeitraum und durchlaufen in ihrer Entwicklung nacheinander mehrere Phasen der gemeinsamen Entwicklung. Lebenszyklus(LC)-Systeme:

1) Vorprojektbefragung (oder -analyse) der Organisation,

2) AIS-Design,

3) Implementierung von AIS,

4) Einführung von AIS,

5) Funktionsweise (Bedienung, Nutzung)

6) AIS-Eskorte,

7) Modernisierung des AIS-Projekts.

Lebenszyklus – der Zeitraum der Erstellung und Nutzung eines Informationssystems, der seine verschiedenen Zustände abdeckt, beginnend mit der Entstehung des Bedarfs an diesem Informationssystem und endend mit dem Zeitpunkt seiner vollständigen Außerbetriebnahme.

Es ist zu beachten, dass AIS ein Produkt der Informationsproduktion ist, ebenso wie ein Auto ein Produkt der Maschinenbauproduktion, eine Wurst ein Produkt der Lebensmittelproduktion usw. ist, also die Phasen des AIS-Lebenszyklus mit 1 bis 5 ähneln den Phasen des Lebenszyklus eines Produkts.

AIS-Lebenszyklus, wie ein Auto, kann durch körperliche Abnutzung enden, Wenn im Lebenszyklus Supportphase nicht geklappt, also Reparatur und Wartung beispielsweise von Computern und Programmen, die Teil des AIS sind (ohne Support funktioniert das System auch sechs Monate lang nicht). Mit qualifizierter Begleitung kann AIS lange bestehen bleiben, es besteht jedoch eine Bedrohung Beendigung des AIS-Lebenszyklus aufgrund von Obsoleszenz, AIS-Obsoleszenz, wenn es keine Upgrade-Stufe gibt AIS (ohne Modernisierung wird das System länger als 2 Jahre nicht funktionieren).

Der physische Wertverlust von AIS ist die Unfähigkeit, die Anforderungen der Organisation an AIS aufgrund von Ausfällen, Ausfällen oder Ausfällen von Systemkomponenten zu erfüllen.

Obsoleszenz von AIS – Nichterfüllung der Anforderungen der Organisation und ihrer Mitarbeiter an AIS aufgrund der Verwendung veralteter automatisierter Systeme Informationstechnologien und mangelnde Unterstützung für neue Benutzeranforderungen.

Wenn Ihre Organisation verantwortungsvoll und umfassend an die Automatisierung herangegangen ist und alle Phasen und Etappen entsprechend organisiert hat, dann Der AIS-Lebenszyklus begrenzt nur die Lebensdauer Ihrer Organisation, was bedeutet, dass die für das AIS ausgegebenen Mittel nicht zusammen mit dem physisch oder moralisch veralteten AIS in den Müll geworfen werden.

Alle Phasen des AIS-Lebenszyklus wurden oben aufgeführt, einige davon laufen jedoch parallel, sodass sie nur hervorgehoben werden 5 Phasen im AIS-Lebenszyklus(Abb.35):

In der ersten Phase“ Umfrage vor dem Projekt» (Abb. 33) Es ist üblich, zwei Hauptunterstufen und eine zusätzliche Unterstufe zu unterscheiden:

1.1. dirigieren Umfrage vor dem Projekt und Sammlung von Umfragematerialien;

1.2. Analyse von Umfragematerialien und Entwicklung basierend auf der Analyse einer Machbarkeitsstudie (FS) und Leistungsbeschreibung (TOR);

1.3. Auswahl und Entwicklung einer Variante des Systemkonzepts.

Die Ziele der Vorprojekterhebungsphase sind wie folgt:

· die Bedürfnisse für ein neues AIS zu formulieren, d.h. alle Mängel des bestehenden IS identifizieren;

· Wählen Sie die Richtung und bestimmen Sie die wirtschaftliche Machbarkeit des AIS-Designs.

Die Umfragearbeit beginnt mit der Analyse der primären Anforderungen und der Arbeitsplanung, die zwischen 2 Tagen und 4 Wochen dauert. Als nächstes wird die Befragung des Unternehmens selbst durchgeführt (die Dauer der Befragung beträgt 1-2 Wochen).

Zunächst wird eine Beschreibung erstellt und die Funktionsweise des jeweiligen Unternehmens bzw. der Organisation anhand der für sie geltenden Anforderungen (Ziele) analysiert. Die organisatorischen und topologischen Strukturen des Unternehmens werden festgelegt. Es werden die funktionalen Aktivitäten der einzelnen Unternehmensbereiche und die funktionalen Interaktionen zwischen ihnen, Informationsflüsse innerhalb der Abteilungen und zwischen ihnen, Objekte außerhalb des Unternehmens und externe Informationsinteraktionen identifiziert. Es wird eine Liste der Zielaufgaben (Funktionen) des Unternehmens ermittelt und eine Analyse der Funktionsverteilung nach Abteilungen und Mitarbeitern durchgeführt.

Die Liste der im Unternehmen eingesetzten Automatisierungsmittel wird festgelegt.

Als nächstes werden die Ergebnisse der Umfrage verarbeitet und die folgenden zwei Arten von Unternehmensaktivitätsmodellen erstellt (beachten Sie, dass die Erstellung jedes der erforderlichen Modelle intensive Arbeit von 6–7 qualifizierten Systemanalytikern innerhalb von 2–4 Monaten erfordert).

1. Im Bau „wie es ist“-Modell Dies ist eine „Momentaufnahme“ der Situation im Unternehmen (Organisationsstruktur, Interaktionen zwischen Abteilungen, eingeführte Technologien, automatisierte und nicht automatisierte Geschäftsprozesse usw.) zum Zeitpunkt der Umfrage und ermöglicht es Ihnen zu verstehen, was dieses Unternehmen ist Was und wie es aus Sicht der Systemanalyse funktioniert und wie es funktioniert, sowie auf der Grundlage der automatischen Überprüfung eine Reihe von Fehlern und Engpässen identifizieren und eine Reihe von Vorschlägen zur Verbesserung der Situation formulieren.

2. Gebildet Das „wie es soll“-Modell Integration vielversprechender Vorschläge des Managements und der Mitarbeiter des Unternehmens, von Experten und Systemanalytikern und Ermöglichung der Bildung einer Vision neuer rationaler Technologien für den Betrieb des Unternehmens. Sie vertritt Konzept des zukünftigen AIS.

Die Erstellung des Konzepts des zukünftigen Systems umfasst folgende Arbeiten:

Detaillierte Untersuchung des Automatisierungsobjekts;

Erforderliche Forschungsarbeiten (F&E) im Zusammenhang mit der Suche nach Wegen und der Bewertung der Möglichkeit zur Umsetzung von Nutzeranforderungen;

Entwicklung alternativer Optionen für das Konzept des erstellten AIS und Pläne für deren Umsetzung;

Grad notwendigen Ressourcen für deren Umsetzung und Betrieb;

Bewertung der Vor- und Nachteile jeder Option;

Vergleich der Benutzeranforderungen und Eigenschaften des vorgeschlagenen Systems und Auswahl Die beste Option;

Festlegung des Verfahrens zur Beurteilung der Qualität und der Bedingungen für die Abnahme des Systems;

Bewertung der vom System erhaltenen Wirkungen;

Erstellung eines Berichts mit einer Beschreibung der durchgeführten Arbeiten;

Beschreibung und Begründung der vorgeschlagenen Version des Systemkonzepts.

Basierend auf dem erstellten Systemkonzept und den Ergebnissen der Befragung des Unternehmens zur Ermittlung der Anforderungen an das zukünftige System wird ein Systemprojekt erstellt (Anforderungsmodell), das die erste Phase der Entwicklung des Automatisierungssystems selbst darstellt (nämlich die Phase der Analyse der Anforderungen an das System), in der die Anforderungen des Kunden spezifiziert, formalisiert und dokumentiert werden

Tatsächlich wird in dieser Phase eine Antwort auf die Frage gegeben: „Was soll das zukünftige System tun?“. Hier liegt der Schlüssel zum Erfolg des gesamten Automatisierungsprojekts. In der Praxis der Erstellung großer Softwaresysteme gibt es viele Beispiele für eine erfolglose Implementierung, gerade aufgrund der Unvollständigkeit und Unschärfedefinition der Systemanforderungen.

In dieser Phase wird Folgendes festgelegt:

§ Architektur des Systems, seine Funktionen, äußere Bedingungen seines Funktionierens, Verteilung der Funktionen zwischen den Hardware- und Softwareteilen;

§ Schnittstellen und Funktionsverteilung zwischen Mensch und System;

§ Anforderungen an Software- und Informationskomponenten des Systems, notwendige Hardwareressourcen, Datenbankanforderungen, physikalische Eigenschaften der Systemkomponenten, deren Schnittstellen;

§ die Zusammensetzung der mit dem System verbundenen Personen und Arbeitsplätze;

§ Einschränkungen im Entwicklungsprozess (Richtlinienfristen für den Abschluss einzelner Phasen, verfügbare Ressourcen);

§ organisatorische Verfahren, die den Schutz von Informationen gewährleisten.

Im Rahmen des Systemdesigns wird Folgendes durchgeführt:

Festlegung der Zusammensetzung, Struktur und Ausprägung funktionaler Aufgaben im Rahmen der Tätigkeit von Strukturabteilungen;

Bestimmung der Zusammensetzung und Struktur von Automatisierungssoftware für die Problemlösungstechnik unter Berücksichtigung vorhandener Werkzeuge in strukturelle Unterteilungen;

Bestimmung der Struktur und Eigenschaften informationsunterstützender Technologie zur Lösung von Problemen;

Entwicklung technischer Lösungen zum Aufbau von Informationsunterstützung (logische Datenbankstrukturen, Klassifikatorstrukturen);

§ Entwicklung der Zusammensetzung automatisierter Workflow-Verfahren.

Systemprojekt sollte beinhalten:

ein vollständiges Funktionsmodell der Anforderungen für das zukünftige System;

Kommentare zum Funktionsmodell (untergeordnete Prozessspezifikationen in Textform);

ein Paket von Berichten und Dokumenten zu einem Funktionsmodell, einschließlich einer Beschreibung des Modellierungsobjekts, einer Liste von Subsystemen, Anforderungen an Methoden und Kommunikationsmittel für den Informationsaustausch zwischen Komponenten, Anforderungen an die Eigenschaften der Verbindungen des Systems mit angrenzenden Systemen, Anforderungen für Systemfunktionen;

· konzeptionelles Modell der integrierten Datenbank (Diagrammpaket);

Systemarchitektur in Bezug auf das konzeptionelle Modell;

· Vorschläge für die Organisationsstruktur zur Unterstützung des Systems.

Somit enthält das Systemprojekt Funktions-, Informations- und möglicherweise Ereignismodelle von Anforderungen an das zukünftige System. Art und Ablauf der Arbeiten bei der Erstellung dieser Anforderungsmodelle ähneln den entsprechenden Arbeiten bei der Erstellung von Aktivitätsmodellen. Darüber hinaus enthält das Systemprojekt eine Leistungsbeschreibung für die Erstellung eines automatisierten Systems.

Es ist notwendig, den folgenden Vorteil des Systemprojekts zu beachten. Die traditionelle Entwicklung zeichnet sich durch die Umsetzung der Anfangsphasen auf handwerkliche, nicht formalisierte Weise aus. Dadurch können Kunden und Anwender das System erstmals sehen, nachdem es bereits weitgehend implementiert ist. Natürlich unterscheidet sich dieses System von dem, was sie erwartet hatten. Daher folgen mehrere weitere Iterationen seiner Entwicklung oder Modifikation, was zusätzliche (und erhebliche) Kosten an Geld und Zeit erfordert. Der Schlüssel zur Lösung dieses Problems ist das Systemprojekt, das Folgendes ermöglicht:

Beschreiben, „sehen“ und korrigieren Sie das zukünftige System, bevor es physisch implementiert wird;

Reduzieren Sie die Kosten für die Entwicklung und Implementierung des Systems;

Bewerten Sie die Entwicklung im Hinblick auf Zeit und Ergebnisse.

Erreichen Sie gegenseitiges Verständnis zwischen allen an der Arbeit Beteiligten (Kunden, Benutzer, Entwickler, Programmierer usw.);

Verbesserung der Qualität des entwickelten Systems, nämlich: Schaffung einer optimalen Struktur einer integrierten Datenbank, Durchführung einer funktionalen Zerlegung typischer Module.

Ein Systemprojekt ist völlig unabhängig und von bestimmten Entwicklern trennbar, erfordert keine Wartung durch seine Ersteller und kann problemlos auf andere Personen übertragen werden. Wenn das Unternehmen aus irgendeinem Grund nicht bereit ist, das projektbasierte System zu implementieren, kann es außerdem „auf Eis gelegt“ werden, bis der Bedarf entsteht. Darüber hinaus kann es zur eigenständigen Entwicklung oder Korrektur bereits auf seiner Basis implementierter Softwaretools durch die Programmierer der Untereingesetzt werden.

Der Zweck der Entwicklung der „Machbarkeitsstudie“ des AIS-Projekts besteht darin, die wichtigsten Parameter zu bewerten, die das Projekt einschränken, die Auswahl zu rechtfertigen und die wichtigsten Entwurfsentscheidungen für einzelne Komponenten des Projekts zu bewerten. Gleichzeitig gibt es organisatorische Parameter, die die Art und Weise der Organisation der Infim System charakterisieren, Informations- und Wirtschaftsparameter, die die Kosten für die Erstellung und den Betrieb des Systems sowie die Einsparungen aus seinem Betrieb charakterisieren. Die Hauptobjekte der Parametrisierung im System sind Aufgaben, Aufgabenkomplexe, Ökonomische Indikatoren, Informationsverarbeitungsprozesse. Nachdem eine Entscheidung über die weitere Arbeit getroffen wurde, wird eine Reihe von organisatorische Maßnahmen Beispielsweise müssen entsprechende Arbeitsaufträge erteilt werden; Es sollten Verantwortliche für Bereiche ernannt werden usw.

Ohne eine solche Unterstützung durch die Unternehmensleitung ist es sinnlos, überhaupt ein Projekt zu starten.

Abbildung 33. Der Arbeitsablauf in der Vorentwurfsphase des AIS-Lebenszyklus.

Als nächstes wird eine Leistungsbeschreibung (TOR) für das Projekt erstellt, die Folgendes widerspiegelt technische Bedingungen und Anforderungen für das zukünftige AIS sowie Einschränkungen der Designressourcen. Wenn das Projekt eine wissenschaftliche Untersuchung der Komponenten erfordert, wird auf Basis des TOR das Konzept des zukünftigen AIS entwickelt.

Im Rahmen der Bildung des TOR werden auf Basis der identifizierten und vereinbarten Anforderungen Vorschläge zur Automatisierung erarbeitet, darunter:

Erstellen einer Liste der automatisierten Arbeitsplätze des Unternehmens und der Interaktionsmöglichkeiten zwischen ihnen;

Analyse der Anwendbarkeit bestehender Unternehmensmanagementsysteme (hauptsächlich MRP- und ERP-Klassen) zur Lösung der erforderlichen Aufgaben und Bildung von Empfehlungen zur Auswahl eines solchen Systems;

Gemeinsame Entscheidungsfindung mit dem Kunden Wählen Sie ein bestimmtes Unternehmensmanagementsystem oder entwickeln Sie Ihr eigenes Systeme.

Entwicklung von Vorschlägen für technische Mittel;

Entwicklung von Softwarevorschlägen;

Entwicklung der Topologie, Zusammensetzung und Struktur des lokalen Netzwerks;

Erarbeitung von Vorschlägen für die Stufen und Bedingungen der Automatisierung.

Wenn Sie sich für ein bestimmtes Steuerungssystem entschieden haben, werden einige Schritte übersprungen.

Zweite Phase " Design» (Abb. 34) führt folgende Teilschritte aus:

1) Vorentwurf: Klärung der Anforderungen der TOR, Ausführung und Genehmigung des Vorentwurfs;

2) technisches Design: Auswahl von Designlösungen für alle Aspekte der AIS-Entwicklung, Beschreibung aller AIS-Komponenten, Ausführung und Genehmigung eines technischen Projekts;

3) Detailentwurf: Auswahl und Entwicklung mathematischer Methoden und Programmalgorithmen, Anpassung der Struktur von Datenbanken (DB), Erstellung von Dokumentationen für die Lieferung und Entwicklung von Softwareprodukten, Auswahl eines Satzes AIS-Hardware, Erstellung von Dokumentationen für die Lieferung und Installation von Hardware, Entwicklung eines Arbeitsentwurfs von AIS.

Die Ziele dieser Phase sind:

· eine funktionale Architektur des AIS entwickeln, die die Struktur und Zusammensetzung funktionaler Subsysteme widerspiegelt, zur automatisierten Unterstützung bestimmter Managementfunktionen der Organisation;

· die Systemarchitektur der gewählten AIS-Variante zu entwickeln, also die Zusammensetzung der unterstützenden Subsysteme.

Für komplexe große AIS, Automatisierung großes Unternehmen, Halten, Körper Staatsmacht usw., im Unterschritt 1“ Vorläufiger Entwurf» Als Ergebnis werden vorläufige Lösungen für das zukünftige AIS als Ganzes und seine Komponenten formuliert vorläufiger Entwurf(EP). Die Entwicklung vorläufiger Designlösungen für das System und seine Teile umfasst:

Definition der AIS-Funktion;

Definition der Funktion von Teilsystemen, ihrer Ziele und Wirkungen;

Bestimmung der Zusammensetzung von Aufgabenkomplexen und Einzelaufgaben;

Definition des Konzepts der Informationsbasis, ihrer erweiterten Struktur;

Definition von Datenbankverwaltungssystemfunktionen;

Bestimmung der Zusammensetzung des Computersystems;

Definition der Funktion und Parameter der wichtigsten Softwaretools.

Entwicklung der Dokumentation für diesen Teil des Projekts.

Wenn das zu entwickelnde Projekt nicht sehr komplex ist, beispielsweise ein kleines Unternehmen automatisiert wird, wird der Arbeitsschritt übersprungen.

Bei Unterschritt 2. Ingenieur-Design » Arbeit an der logischen Entwicklung und Auswahl von die besten Optionen Entwurfsentscheidungen, aus denen ein technisches Projekt (TP) entsteht. Im Rahmen der Erstellung eines technischen Projekts wird Folgendes durchgeführt:

- Umwandlung eines Systemprojekts in ein technisches Projekt(Implementierungsmodell), das die folgenden Aktionen umfasst: Verfeinerung des logischen Modells (Entwicklung einer detaillierten Logik für jeden Prozess mithilfe von Datenflussdiagrammen und Prozessspezifikationen), Entwurf einer physischen Datenbank, Aufbau einer Hierarchie der zu programmierenden Modulfunktionen, Schätzung der Implementierungskosten.

Die aufgeführten Arbeiten sollten von beratenden Analysten gemeinsam mit Systemdesignern durchgeführt werden – hier liegt die Grenze zwischen Beratung und Entwicklung. Dennoch ist es wünschenswert, dass der Berater in der Phase der Systemeinführung auch im Interesse des Kunden handelt, nämlich: Software System systemisch und technische Projekte, und beteiligte sich auch an den Arbeiten zu seiner Erweiterung und Modifikation, tk. Erweiterungen sollten auf Basis des Anforderungsmodells geplant werden.

- technische Designarbeiten:

Entwicklung allgemeiner Lösungen für das System und seine Teile,

Entwicklung allgemeiner Lösungen für funktional-algorithmische Systemstruktur,

Entwicklung gemeinsamer Entscheidungen zu Personalfunktionen und Organisationsstruktur,

Entwicklung gemeinsamer Lösungen für den Aufbau technischer Mittel,

Entwicklung allgemeiner Lösungen für Problemlösungsalgorithmen und eingesetzte Sprachen,

Entwicklung gemeinsamer Lösungen zur Organisation und Pflege einer Informationsbasis,

Entwicklung gemeinsamer Lösungen für das System der Klassifizierung und Kodierung von Informationen,

Entwicklung gängiger Softwarelösungen;

Führen Sie die Entwicklung und Ausführung der Dokumentation für alle Teile des Projekts durch, einschließlich des Dokuments "Formulierung des Problems",

Entwicklung und Ausführung von Dokumentationen zur Lieferung von Produkten für den Erwerb von AIS und/oder Technische Anforderungen(technische Spezifikationen) für ihre Entwicklung;

Entwicklung von Entwurfsaufgaben in angrenzenden Teilen des Projekts des Automatisierungsobjekts.

Unterstufe 3.“ Arbeitsdesign » verbunden mit der physischen Umsetzung der gewählten Projektoption und dem Erhalt der detaillierten Designdokumentation (DP).

Dieser Unterschritt wird durchgeführt:

Entwicklung und Ausführung der Arbeitsdokumentation, die alle notwendigen und ausreichenden Informationen enthält, um die Durchführung der Arbeiten zur Inbetriebnahme des AIS und seines Betriebs sicherzustellen sowie das Niveau der Betriebseigenschaften (Qualität) des Systems gemäß den angenommenen Standards aufrechtzuerhalten Entwurfsentscheidungen sowie die Koordination und Genehmigung dieser Dokumentation;

Entwicklung von Programmen und Softwaretools des Systems, sowie die Auswahl, Anpassung und/oder Anbindung eingekaufter Softwaretools,

Entwicklung von Softwaredokumentationen.

Organisation von Ausschreibungen für die Lieferung von AIS-Komponenten (Software und Hardware, Software- und Hardwaresysteme, Informationsprodukte).

Abbildung 34. Der Arbeitsablauf in der Entwurfsphase des AIS-Lebenszyklus.

Bei Vorliegen von Designerfahrung und geringer Komplexität des Projekts werden alle drei Teilphasen zu einer zusammengefasst, wodurch ein einziges Techno-Working-Projekt (TDP) entsteht. In diesem Fall wird das Projekt nach Abschluss der Teilschritte konsequent vom Entwurf zum detaillierten Entwurf umgewandelt.

Die dritte Stufe Implementierung» (Abb. 35) ist der physikalische Aufbau des Systems in der folgenden Reihenfolge:

1) Erhalt und Installation technischer Mittel;

2) Codierung, Test und Entwicklung von Programmen;

3) Beschaffung und Installation von Software;

4) Erstellung von Informationsunterstützung, einschließlich der Befüllung von Datenbanken;

5) Entwicklung von Anleitungen für den Betrieb von Soft- und Hardware sowie Berufsbeschreibungen für Angestellte.

Diese Arbeiten können praktisch parallel durchgeführt werden.

In der vierten Phase des AIS-Lebenszyklus“ Implementierung» Es gibt folgende Teilschritte:

1) Pilotimplementierung:

Inbetriebnahme technischer Anlagen,

Inbetriebnahme von Softwaretools, Durchführung des Probebetriebs aller Komponenten und Systeme als Ganzes,

· Schulung und Zertifizierung des Personals.

Pilotumsetzung besteht darin, die Funktionsfähigkeit von Elementen und Modulen des Projekts zu überprüfen und Fehler auf der Ebene der Elemente und Verbindungen zwischen ihnen zu beseitigen.

In dieser Phase wird daran gearbeitet Organisationstraining Automatisierungsobjekt zur Inbetriebnahme von AIS, einschließlich:

Umsetzung von Designentscheidungen zur Organisationsstruktur des AIS;

Bereitstellung von Lehr- und Methodenmaterialien für die Einheiten des Kontrollobjekts;

Einführung von Informationsklassifikatoren;

Ausbildung,

Überprüfung seiner Fähigkeit, die Funktionsfähigkeit des AIS sicherzustellen.

Gleichzeitig wird das AIS mit den gelieferten Produkten (Software usw.) vervollständigt technische Mittel, Software- und Hardwarekomplexe, Informationsprodukte) sowie Konstruktion und Installation, Inbetriebnahme, Vorversuche:

Führen Sie Tests des AIS auf Leistung und Einhaltung der Leistungsbeschreibung gemäß dem im Voraus erstellten Programm und der Methodik der Vortests durch;

Fehlerbehebung und Verbesserung (falls erforderlich) der Software, Vornahme von Änderungen an der AIS-Dokumentation, einschließlich der Betriebsdokumentation gemäß Testprotokoll.

Die Pilotumsetzungsarbeiten enden am Ausarbeitung eines Gesetzes über den Abschluss des Probebetriebs.

2) Industrielle Umsetzung (Inbetriebnahme):

Inbetriebnahme,

Unterzeichnung von Abnahme- und Lieferakten.

Inbetriebnahme besteht darin, eine Projektüberprüfung auf Funktionsebene zu organisieren und die Einhaltung der in der Vorprojekterhebungsphase formulierten Anforderungen zu überwachen, d. h.:

Führen Sie einen Test zur Einhaltung der Leistungsbeschreibung gemäß dem im Voraus erstellten Programm und der Methodik der Abnahmetests durch;

Analyse der AIS-Testergebnisse und Beseitigung der während der Tests festgestellten Mängel.

Abschlussarbeiten an Ausarbeitung eines Gesetzes über die Zulassung von AIS zum dauerhaften Betrieb.

In der letzten fünften Phase des AIS-Lebenszyklus Betrieb, Wartung und Modernisierung Software, Hardware und das gesamte Projekt.

AIS-Eskorte besteht in Durchführung von Arbeiten gemäß den Gewährleistungspflichten, Durchführung von Arbeiten zur Beseitigung der beim Betrieb des AIS festgestellten Mängel innerhalb der festgelegten Gewährleistungsfrist und bei der Durchführung der Arbeiten zur Vornahme der erforderlichen Änderungen an der Dokumentation für das AIS.

Der Service nach der Garantiezeit umfasst:

Bei der Durchführung von Arbeiten zur Analyse der Funktionsweise des Systems;

Bei der Identifizierung von Abweichungen der tatsächlichen Betriebseigenschaften des AIS von den Entwurfswerten;

Bei der Ermittlung der Ursachen dieser Abweichungen;

Bei der Beseitigung der festgestellten Mängel und der Gewährleistung der Stabilität der Betriebseigenschaften des AIS;

Bei der Durchführung der notwendigen Änderungen an der Dokumentation für AIS.

Abhängig von den Besonderheiten des erstellten AIS und den Bedingungen für deren Erstellung ist die Durchführung einzelner Arbeitsschritte vor Abschluss der vorherigen Arbeitsschritte, die zeitlich parallele Ausführung von Arbeitsschritten und die Einbeziehung neuer Arbeitsschritte zulässig.

Abbildung 35. AIS-Lebenszyklusphasen.

Der Lebenszyklus ist normalerweise iterativ: abgeschlossene Etappen Lebenszyklen, beginnend mit den frühesten, werden entsprechend neuen Anforderungen und Änderungen der äußeren Bedingungen zyklisch wiederholt. In jeder Phase des Lebenszyklus entsteht eine Reihe von Dokumenten und technischen Lösungen, die den Ausgangspunkt für nachfolgende Entscheidungen bilden.

Am weitesten verbreitet drei Lebenszyklusmodelle:

Kaskadenmodell (bis in die 70er Jahre) – ein sequentieller Übergang zur nächsten Stufe nach Abschluss der vorherigen;

· iteratives Modell (70er – 80er) – mit iterativen Rückkehr zu den vorherigen Stufen nach Abschluss der nächsten Stufe;

· Spiralmodell (80-90er Jahre) – ein Prototypenmodell, das eine schrittweise Erweiterung des AIS-Prototyps voraussetzt.

Für Kaskadenlebenszyklusmodell Typisch ist die Automatisierung einzelner, unabhängiger Aufgaben, die keine Informationsintegration und -kompatibilität, Software sowie technische und organisatorische Schnittstelle erfordern. Im Rahmen der Lösung individueller Probleme rechtfertigte sich das Kaskadenmodell hinsichtlich Entwicklungszeit und Zuverlässigkeit. Die Anwendung dieses Lebenszyklusmodells auf große und komplexe Projekte führt aufgrund der langen Dauer des Entwurfsprozesses und der Variabilität der Anforderungen während dieser Zeit zu deren praktischer Unrealisierbarkeit.

Iteratives Lebenszyklusmodell. Bei der Erstellung komplexer AIS geht es um die Verknüpfung von Designlösungen, die bei der Umsetzung einzelner Aufgabenstellungen gewonnen werden. Der „Bottom-up“-Entwurfsansatz erfordert solche iterativen Rückführungen, wenn Entwurfslösungen für einzelne Aufgaben zu allgemeinen Systemlösungen vervollständigt werden und gleichzeitig die Notwendigkeit besteht, zuvor formulierte Anforderungen zu überarbeiten. Aufgrund einer Vielzahl von Iterationen kommt es in der Regel zu Unstimmigkeiten in den abgeschlossenen Entwurfsentscheidungen und der Dokumentation. Die Verwirrung von funktionalem und Systemarchitektur Aufgrund der Schwierigkeit bei der Verwendung der Entwurfsdokumentation, die von AIS erstellt wurde, ist eine Neugestaltung des gesamten Systems in den Phasen der Implementierung und des Betriebs erforderlich. Der lange Lebenszyklus der Entwicklung eines Informationssystems endet mit der Implementierungsphase, gefolgt vom Lebenszyklus der Erstellung eines neuen AIS.

Spirallebenszyklusmodell. Bei der Organisation des AIS-Designs wird ein Top-Down-Ansatz verwendet, bei dem zunächst die Zusammensetzung funktionaler Subsysteme und dann die Festlegung einzelner Aufgaben festgelegt wird. Dementsprechend werden zunächst systemweite Fragen wie die Organisation einer integrierten Datenbank, die Technologie zum Sammeln, Übertragen und Sammeln von Informationen und dann die Technologie zur Lösung spezifischer Probleme entwickelt. Im Rahmen von Aufgabenkomplexen erfolgt die Programmierung in Richtung von den Hauptprogrammmodulen hin zu den Modulen, die einzelne Funktionen ausführen. Gleichzeitig rücken die Fragen der Interaktion der Schnittstellen der Programmmodule untereinander und mit der Datenbank in den Vordergrund und die Implementierung von Algorithmen tritt in den Hintergrund.

Jede Windung der Spirale entspricht einem Schritt-für-Schritt-Modell zur Erstellung eines AIS-Fragments. Es klärt die Ziele und Merkmale des Projekts, bestimmt seine Qualität und plant die Arbeit der nächsten Spirale. Es erfolgt eine konsequente Vertiefung und Konkretisierung der Projektdetails, es entsteht eine fundierte Version, die zur Umsetzung gebracht wird.

Das Spiralmodell des Lebenszyklus basiert auf dem Einsatz von Prototypentechnologie oder RAD-Technologie (Rapid Application Development).

Nach dieser Technologie wird AIS durch die Erweiterung von Software-Prototypen entwickelt und folgt dabei dem Weg von der Anforderungsspezifikation zur Spezifikation des Programmcodes.

Natürlich wird mit der Prototypentechnologie die Anzahl der Iterationen reduziert und es gibt weniger Fehler und Inkonsistenzen, die bei nachfolgenden Iterationen korrigiert werden müssen, und der Entwurf selbst wird schneller durchgeführt und die Erstellung der Projektdokumentation wird vereinfacht. Um eine bessere Übereinstimmung mit der von AIS entwickelten Designdokumentation zu erzielen, wird immer mehr Wert auf die Aufrechterhaltung eines systemweiten Repositorys und die Designautomatisierung gelegt, insbesondere auf den Einsatz von CASE-Technologien (Computers Aids System Engineering).

Bei Verwendung des Spiralmodells:

· Es kommt zu einer Anhäufung und Wiederverwendung von Designlösungen, Designtools, Modellen und Prototypen von AIS und Informationstechnologien.

· Es erfolgt eine Orientierung an der Entwicklung und Modifikation des Systems und der Technologien im Prozess ihrer Gestaltung;

· Im Systemdesignprozess wird eine Risiko- und Kostenanalyse durchgeführt.

Eine Schnittstelle ist eine Paarung von Teilen von Software und Hardware, Daten, einer Technologie zur Kommunikation zwischen Mensch und Computer, bei der alle Informationen, logischen, physikalischen und elektrischen Parameter festgelegten Standards entsprechen.

Prototyp – die Mindestversion des Systems, die zur Generierung oder Entwicklung der Vollversion verwendet wird

Das Repository enthält Informationen über die Objekte des entworfenen AIS und die Beziehungen zwischen ihnen, alle Subsysteme tauschen Daten mit ihm aus.

AIS-Lebenszyklusmodelle - Eine Struktur, die die sequentielle Umsetzung von Prozessen, Aktionen und Aufgaben, die während des gesamten Lebenszyklus ausgeführt werden, und die Beziehung zwischen diesen Prozessen definiert.

Kaskadenmodell. Der Übergang zur nächsten Stufe bedeutet den vollständigen Abschluss der Arbeiten der vorherigen Stufe. Die bei der Anforderungsbildung definierten Anforderungen werden in Form von Leistungsbeschreibungen streng dokumentiert und für die gesamte Dauer der Projektentwicklung fixiert. Jede Phase gipfelt in der Veröffentlichung einer vollständigen Dokumentation, die ausreicht, um die Entwicklung durch ein anderes Entwicklungsteam fortzusetzen.

Projektschritte nach dem Wasserfallmodell:

1. Anforderungsbildung;

2. Design;

3. Entwicklung;

4. Testen;

5. Einführung;

6. Betrieb und Wartung.

Vorteile:

-Vollständige und vereinbarte Dokumentation in jeder Phase;

-Festgelegte Arbeitsreihenfolge;

- Ermöglicht eine klare Termin- und Kostenplanung.

Mängel:

-Erhebliche Verzögerung beim Erhalt vorgefertigter Ergebnisse;

-Fehler in einer der Phasen werden in späteren Phasen entdeckt, was dazu führt, dass die Projektdokumentation zurückgegeben und erneut registriert werden muss;

- Schwierigkeiten beim Projektmanagement.

Spiralmodell. Jede Iteration entspricht der Erstellung eines Fragments oder einer Version der Software, bei der die Ziele und Merkmale des Projekts festgelegt, die Qualität der erzielten Ergebnisse bewertet und die Arbeit der nächsten Iteration geplant wird.

Jede Iteration – abgeschlossene Entwicklungszyklen in Form der 1. Version des AIS.

Iterationsschritte:

1.Anforderungsbildung

3.Design

4.Entwicklung

5.Integration

Bei jeder Iteration wird Folgendes ausgewertet:

Das Risiko, die Bedingungen und Kosten des Projekts zu überschreiten;

Die Notwendigkeit, eine weitere Iteration durchzuführen;

Der Grad der Vollständigkeit und Genauigkeit des Verständnisses der Anforderungen an das System;

Die Zweckmäßigkeit der Beendigung des Projekts.

Vorteile:

-Vereinfacht den Prozess der Durchführung von Änderungen am Projekt;

- Bietet mehr Flexibilität im Projektmanagement;

- Die Möglichkeit, ein zuverlässiges und stabiles System zu erhalten, weil Bei jeder Iteration werden Fehler und Inkonsistenzen gefunden.

- Einfluss des Kunden auf die Arbeit im Prozess der Überprüfung jeder Iteration.

Mängel:

-Komplexität der Planung;

-Intensive Arbeitsweise für Entwickler;

-Die Arbeitsplanung basiert auf Erfahrung und es gibt nicht genügend Kennzahlen, um die Qualität jeder Version zu messen.

Anforderungen an die Technologie für Design, Entwicklung und Wartung von AIS

Designtechnologie- definiert eine Kombination aus drei Komponenten:

- Schritt-für-Schritt-Anleitung, wodurch die Reihenfolge definiert wird technologische Operationen Design;

- Regeln zur Bewertung der Ergebnisse technologischer Operationen;

- Einreichung der Designentwicklung zur Prüfung und Genehmigung.

Technologische Anweisungen, die den Hauptinhalt der Technologie ausmachen, sollten aus einer Beschreibung des Ablaufs der technologischen Vorgänge, der Bedingungen, unter denen dieser oder jener Vorgang ausgeführt wird, und Beschreibungen der Vorgänge selbst bestehen.

Die Technologie zum Entwerfen, Entwickeln und Warten von IS muss Folgendes erfüllen Allgemeine Anforderungen:

Die Technologie muss den gesamten Software-Lebenszyklus unterstützen;

Die Technologie soll die garantierte Erreichung der Ziele der IS-Entwicklung mit einer bestimmten Qualität und zu einem bestimmten Zeitpunkt gewährleisten;

Die Technologie soll die Möglichkeit bieten, in kleinen Gruppen (3-7 Personen) an der Gestaltung einzelner Subsysteme zu arbeiten. Dies ist auf die Grundsätze der Teamverwaltbarkeit und Produktivitätssteigerung durch Minimierung der Anzahl externer Links zurückzuführen;

Die Technologie sollte die Möglichkeit bieten, die Projektkonfiguration zu verwalten, Versionen des Projekts und seiner Komponenten zu verwalten, die Möglichkeit der automatischen Ausgabe von Projektdokumentationen und die Synchronisierung seiner Versionen mit Projektversionen;

Der Einsatz jeglicher Technologie für die Gestaltung, Entwicklung und Wartung von IS in einer bestimmten Organisation und einem bestimmten Projekt ist ohne die Entwicklung einer Reihe von Standards (Regeln, Vereinbarungen) nicht möglich, die von allen Projektbeteiligten eingehalten werden müssen. Solchen Standards das Folgende einschließen:

- Designstandard;

- Standard für die Gestaltung der Projektdokumentation;

- Benutzeroberflächenstandard.

Entwicklungsbedarf

- Durchführung von Arbeiten zur Erstellung von Software;

Vorbereitung auf die Einführung von AIS;

Kontrolle, Prüfung der Hauptindikatoren des Projekts.

Begleitende Anforderungen

Der Abschluss der Umsetzung des CIS sollte mit der Veröffentlichung eines Systems von Verwaltungsvorschriften und Stellenbeschreibungen einhergehen, die die Funktionsweise der Organisation bestimmen. Ab Inbetriebnahme des Informationssystems erfolgt der Betrieb auf Grundlage der „Ordnung für die Funktionsweise des Informationssystems“ und einer Reihe von Verordnungen. Die Wartung des Systems und sein unterbrechungsfreier Betrieb erfolgt durch eine durch die entsprechende Verordnung autorisierte Unterabteilung der Organisation. Die Fertigstellung des Informationssystems nach der Inbetriebnahme erfolgt nach individuellen Projekten und Leistungsbeschreibungen.

Bei der Aufrechterhaltung des CIS besteht die Aufgabe darin, seine Lebensfähigkeit aufrechtzuerhalten. Die Lebensfähigkeit des CIS wird maßgeblich davon bestimmt, wie es den tatsächlichen Aufgaben und Bedürfnissen der Universität entspricht, die sich im Laufe des Lebenszyklus des CIS ändern.

Einführung

1. Architektur automatisierter Informationssysteme und Probleme ihrer Verbesserung 13

1.1. Architekturmodelle und Hauptkomponenten von AIS 13

1.2. AIS-Entwicklungsprobleme 47

1.3. Plattformen für die Implementierung der neuen Architektur von AIS UP 53

1.4. Kapitel 1 Schlussfolgerungen 57

2. AIS UE-Architekturmodell 58

2.1. Grundvoraussetzungen für AIS UP 59

2.2. Architektur AIS UP 66

2.3. AIS UP 89 Komponenten

2.4. Kapitel 2 Schlussfolgerungen 102

3. Methoden zur praktischen Umsetzung von AIS UE 104

3.1. Werkzeuge Entwicklung von AIS UP 104

3.2. Erfahrung in der praktischen Umsetzung des AIS UP 111-Modells

3.3. Kapitel 3 Schlussfolgerungen 123

4. Fazit 125

5. Terminologie und Abkürzungen 128

6. Literatur

Einführung in die Arbeit

Die Tätigkeit moderner Unternehmen ist mit der Bewegung voneinander abhängiger und volumetrischer Ströme von Material-, Finanz-, Arbeits- und Informationsressourcen verbunden. Die Steuerung der Prozesse des Produktions- und Handelszyklus in einem sich dynamisch verändernden politischen und wirtschaftlichen Umfeld erfordert eine schnelle Entscheidungsfindung in kurzer Zeit. Die Lösung für dieses Problem in moderne Verhältnisse ist ohne den Einsatz automatisierter Verarbeitungsvorgänge nicht möglich Wirtschaftsinformationen.

In den letzten 40 Jahren wurden automatisierte Informationstechnologien (IT) aktiv zur Lösung der Probleme der Buchhaltung, Planung und Analyse eingesetzt Wirtschaftstätigkeit Unternehmen unterschiedlicher Eigentumsform, Branchenzugehörigkeit, organisatorische Struktur und Umfang der Aktivität. In dieser Zeit wurden viele praktische Erfahrungen bei der Erstellung automatisierter Informationssysteme für die Unternehmensführung (AIS UE) gesammelt, Managementmethoden entwickelt und allgemein anerkannt, deren Anwendung außerhalb der Computerumgebung unmöglich ist. Man kann mit voller Verantwortung sagen, dass AIS UE zu einem integralen Bestandteil der Unternehmensinfrastruktur geworden ist. Theoretische und praktische Probleme der Automatisierung wirtschaftlicher Prozesse werden in den Werken von Glushkov V.M., Volkov S.I., Isakov V.I., Ostrovsky O.M., Podolsky V.I., Ratmirov Yu.A., Romanov A.N., Hotyashova E.N., Brady R., Zachman J. eingehend untersucht. , Cook M., Finkelstein K., Hammer M. und andere Autoren. Die von ihnen vorgeschlagenen Ansätze wurden zur Grundlage für den Einsatz von Computertechnologie in Unternehmen zur Lösung von Problemen der Buchhaltung, Planung und Analyse finanzieller und wirtschaftlicher Aktivitäten. Jedoch

Die von ihnen vorgeschlagenen Modelle berücksichtigten nicht die Realitäten der Wirtschaft der Informationsgesellschaft und den aktuellen Stand der IT-Entwicklung.

Die Entwicklung von Kommunikationsinstrumenten trägt zu einer immer engeren Interaktion zwischen Produzenten und Verbrauchern, Lieferanten und Käufern bei, erhöht den Wettbewerb auf dem Markt, erweitert die Grenzen lokaler Märkte zu nationalen und transnationalen Märkten und beschleunigt die Zeit für Wirtschafts- und Finanztransaktionen. Umsetzung globaler Computernetzwerke V Wirtschaftsprozesse führte zur Entstehung neuer Konzepte: der Ökonomie der Informationsgesellschaft, E-Business(E-Business), E-Commerce(E-Commerce), elektronisch Marktplatz(E-Marktplatz) usw. Trends in der Globalisierung der Wirtschaft spiegeln sich in der neuen Uwider, bei der die Frage der Erhöhung der Flexibilität beim Aufbau von Geschäftsprozessen und der Effektivität der Beziehungen zu Kunden und Lieferanten im Vordergrund steht.

Die bestehenden Konzepte der AIS UE-Organisation basieren auf einem funktionalen Ansatz zur Aufgabenverteilung zwischen ihren Subsystemen. Allerdings erfüllt AIS, das als Komplex von Subsystemen mit Fokus auf einzelne Managementfunktionen aufgebaut ist, die Anforderungen an die Kontinuität der End-to-End-Geschäftsprozesse eines Unternehmens nicht optimal. Daher in letzten Jahren Immer beliebter wird ein Ansatz, bei dem Geschäftsprozesse im Vordergrund stehen und nicht einzelne Funktionen der sie ausführenden Managementsystemdienste. Es braucht Entwicklung neues Konzept AIS UE-Architektur. Gleichzeitig ist klar, dass der Übergang zu einer neuen AIS UE-Architektur nicht sofort erfolgen kann, da Unternehmen und Organisationen seit vielen Jahren eine Vielzahl von Softwaretools in Betrieb nehmen, die die Lösung implementieren wichtige Aufgaben Kontrollen, die nicht sofort aufgegeben werden können. Leider konzentrieren sich die meisten von ihnen auf autonomes Funktionieren, was die komplexe Integration von Informationsflüssen erheblich erschwert. Viele bestehende Softwareprodukte, die Unterstützung bei der Lösung neuer Probleme der Unternehmensführung bieten, die im Kontext der Globalisierung der Wirtschaft entstanden sind, werden auch ohne ausreichende Ausarbeitung von Schnittstellen für die Interaktion mit Softwaresystemen entwickelt, die die Lösung verwandter Probleme umsetzen. Unter diesen Bedingungen kommt der Synthese integrierter Unternehmensmanagementsysteme durch die Integration von Standardkomponenten von Drittanbietern, kundenspezifischen Lösungen und Eigenentwicklungen eine besondere Bedeutung zu.

In den Veröffentlichungen von Wissenschaftlern und Praktikern wird seit langem die Idee diskutiert, Standards für die Systemintegration von Softwaretools verschiedener Hersteller zu implementieren. Der Fortschritt der Systemtools hat zur Entstehung objektorientierter und komponentenorientierter Softwareentwicklungstechnologien geführt, mit denen Sie große Systeme aus vorgefertigten Blöcken erstellen können. Führende Anbieter von Hardware und Systemsoftware (Intel, Microsoft, Sun, Oracle, IBM usw.), Kommunikationstools (Cisco, Nortel, Ericsson, Motorola), angewandten Lösungen (SAP, PeopleSoft, Siebel usw.), maßgeblicher Staat, internationale, kommerzielle und gemeinnützige Organisationen und Verbände (ISO, IEEE, ASCII, APICS, RosStandard usw.) haben inzwischen Technologien zur Integration von Hardware und Software entwickelt und setzen diese aktiv in die Praxis um, die die Schaffung offener Systeme basierend auf Standards und Protokollen für den Datenaustausch und die Interaktion von Komponenten ermöglichen einer heterogenen Umgebung im Echtzeitmodus.

Diese Vorschläge stellen jedoch lediglich eine systemweite Plattform dar, die in Bezug auf einen bestimmten Themenbereich eine erhebliche Verfeinerung erfordert. Im Kontext der praktischen Umsetzung von AIS UE sind die Mechanismen zum Entwurf und zur Entwicklung von Informationssystemen (IS) unter Verwendung von Komponenten-Multi-Link-Architekturen basierend auf Standards und Protokollen offener Systeme nicht ausreichend entwickelt.

In diesem Zusammenhang wird das Problem der Entwicklung einer theoretischen Plattform und der Entwicklung praktischer Empfehlungen zum Aufbau von AIS UE, das eine umfassende Automatisierung aller Informationsverfahren für die Verwaltung von Unternehmen und Organisationen ermöglicht, zu einem dringenden Problem.

Die Notwendigkeit, einen ganzheitlichen Ansatz zur Lösung der Probleme der Systemintegration von AIS PM und der End-to-End-Automatisierung mikroökonomischer Prozesse auf Basis moderner IT zu entwickeln, bestimmte die Wahl des Themas und der Ausrichtung dieser Studie.

Ziel der Studie ist es, ein Modell der AIS UE-Architektur zu entwickeln, das eine umfassende Automatisierung und Informationsunterstützung für End-to-End-Geschäftsprozesse bietet, und die Auswahl der Tools für deren Systemintegration aus Sicht moderner Informationstechnologien zu begründen.

Ausgehend vom angestrebten Ziel wurden folgende wissenschaftliche und praktische Aufgaben gestellt und gelöst:

Analyse und Verallgemeinerung bestehender Ansätze für den Entwurf, die Entwicklung und die Implementierung von AIS UP-Software;

Klassifizieren Sie die Arten von Software, die in der Praxis des Unternehmensmanagements verwendet werden.

Erkunden Sie vorhandene Technologien und Standards, die die Integration heterogener Softwaretools ermöglichen.

Identifizieren von Problemen, die bei der Integration der in AIS UE verwendeten Softwaretools auftreten;

Systematisierung der von Unternehmen gestellten Anforderungen an AIS UE-Software zur Gewährleistung Informationsunterstützung durch wirtschaftliche Prozesse;

Entwickeln Sie ein Modell der AIS UE-Architektur und heben Sie deren Hauptkomponenten hervor.

Entwickeln Sie die Prinzipien der Interaktion und des Datenaustauschs von AIS UE-Komponenten;

Gegenstand der Forschung sind Methoden und Werkzeuge zur Entwicklung wirtschaftlicher Informationssysteme.

Gegenstand der Studie ist Unternehmensführung IS.

Die Forschungsmethodik basiert auf spezifischen Anwendungen der Methodik wissenschaftlicher Erkenntnisse in den Anwendungsbereichen Informatik und Mathematik.

Die Ziele und Zielsetzungen der Studie wurden entsprechend der Hauptarbeitsrichtung zur Weiterentwicklung und Verbesserung mathematischer Methoden und Computertechnologien in wirtschaftswissenschaftlichen Fachgebieten formuliert.

Neben einem allgemeinen wissenschaftlichen Ansatz auf der Grundlage der Systemtheorie fasst die Dissertation die Erfahrungen bei der Entwicklung, Implementierung und dem Betrieb von Softwaretools in- und ausländischer Hersteller und Methoden zusammen

Implementierung internationaler offener Standards für Gebäudeinformationssysteme. Auf dieser Grundlage wird eine Reihe methodischer und praktischer Empfehlungen vorgeschlagen, die bei russischen und ausländischen Unternehmen erprobt wurden.

Die Arbeit nutzt die theoretischen Grundlagen der Werke in- und ausländischer Autoren auf dem Gebiet:

Automatisierte Verarbeitung wirtschaftlicher Informationen und Modellierung wirtschaftlicher Prozesse;

Methoden zur Planung und Betriebsführung von Produktion und Lagerbeständen;

Reengineering und Computerdesign von Geschäftsprozessen;

Moderne Standards in der Informationstechnologie.

Im Rahmen der Studie wurden die Entwicklungen von Forschungsteams und einzelnen Wissenschaftlern an der Finanzakademie der Regierung der Russischen Föderation, dem Allrussischen Korrespondenzinstitut für Finanzen und Wirtschaft und Moskau untersucht staatliche Universität Wirtschaftswissenschaften, Statistik und Informatik, Universität für Wirtschaft und Finanzen St. Petersburg. Voznesensky, Research Financial Institute und andere Organisationen.

Die Informationsbasis der Studie bildeten Softwareprodukte russischer und ausländischer Hersteller, Veröffentlichungen in Wirtschafts- und Computerpublikationen, Forschungen der internationalen Forschungsgruppen Gartner Group, Aberdeen, IDC, MetaGroup, DataQuest usw. Lehrmaterial führende nationale und internationale Beratungs- und Wirtschaftsprüfungsunternehmen, Forschungsergebnisse des Verbandes der Softwareentwickler im Bereich Wirtschaftswissenschaften,

Erforschung des Softwaremarktes in Russland und den GUS-Staaten TSIES „Business-Programme-Service“ .

Die wissenschaftliche Neuheit der Dissertation liegt in der Entwicklung eines Architekturmodells von AIS UE, das sich auf die integrierte Automatisierung von End-to-End-Geschäftsprozessen konzentriert, und Vorschlägen für deren Umsetzung durch Systemintegration heterogener Software in einer verteilten heterogenen Netzwerkumgebung zu Objekt- und Komponententechnologien.

Die wissenschaftliche Neuheit enthält die folgenden in der Dissertation erzielten Ergebnisse:

Definition und Klassifizierung von Anforderungen an Funktionalität Software zur organisatorischen und wirtschaftlichen Führung von Unternehmen;

Das AIS UE-Architekturmodell konzentriert sich auf die integrierte Automatisierung von End-to-End-Geschäftsprozessen.

Prinzipien der Integration von Softwaretools zur Lösung von Problemen der funktionalen Dienste eines Unternehmens mit Basissoftware zur Verwaltung von Geschäftsprozessen, Datenaustausch und Dokumentenmanagement;

Vorschläge zur Organisation eines einzigen Informationsraums des Unternehmens, der Mitarbeitern und Partnern des Unternehmens über das Unternehmens-Webportal zur Verfügung steht;

Vorschläge zur Implementierung eines einheitlichen Systems zur Erstellung und Klassifizierung der Berichterstattung mithilfe von Analysetools;

Prinzipien zur Umsetzung der Interaktion von AIS UE-Subsystemen basierend auf objektorientierten und Komponententechnologien und der Interaktion von Softwarekomponenten in einem verteilten Netzwerk

Umgebung gemäß Industriestandards und Internetprotokollen;

Ein Mechanismus zur Implementierung der adaptiven Eigenschaften des Architekturmodells der AIS UE-Software gemäß den Anforderungen eines bestimmten Unternehmens, basierend auf der Fähigkeit, die grundlegenden Subsysteme an bestehende und geplante Arbeitsprozesse anzupassen.

Die praktische Bedeutung der Dissertationsarbeit besteht darin, dass Sie durch die Umsetzung der vorgeschlagenen Vorschläge AIS UE erstellen können, das Informationsverfahren zur Steuerung der Aktivitäten eines Unternehmens im Kontext der wirtschaftlichen Globalisierung und der Bildung einer Informationsgesellschaft wirksam unterstützt.

Das vorgeschlagene AIS UE-Architekturmodell und die Empfehlungen für seine Anwendung verfügen über ausreichende Flexibilität und Vielseitigkeit, was ihre Anwendbarkeit im Gebäudemanagement-IS für Unternehmen unterschiedlicher Eigentumsformen, Branchenspezifika und Tätigkeitsumfang gewährleistet.

Unabhängiger praktischer Wert haben:

Vorschläge zur Auswahl und Anwendung von Standards, Protokollen und anderen Mechanismen, die bei der Systemintegration von AIS UE verwendet werden;

Angebote für integrierte Automatisierung durchgängige Geschäftsprozesse und Arbeitsabläufe;

Vorschläge zur Schaffung eines einzigen Informationsraums des Unternehmens unter Verwendung des Mechanismus von Webportalen;

Vorschläge zur Anpassung des spiraliterativen Ansatzes bei der Entwicklung und Implementierung der AIS UP-Software.

Die praktische Bedeutung der Arbeit wurde in konkreten Projekten zur Umsetzung des vorgeschlagenen problemorientierten Modells eines Untevaluiert:

Integriertes Unternehmensmanagementsystem „Flagman“ der Firma „Infosoft“,

eRelationship-Kder Pivotal Software Corporation (Kanada),

Monarch ES-Unternehmensberichtssysteme der Firma DataWatch (USA),

Das Projekt der Integration von Informationssystemen der Unternehmen Sovintel und Tele Ross.

Das Vest-MetaTechnology-Schulungszentrum verwendet Materialien, die vom Autor auf der Grundlage des im Verlauf dieser Studie vorgeschlagenen Ansatzes erstellt wurden, bei der Durchführung von Kursen zur Entwicklung von Informationssystemen für das Unternehmensmanagement (siehe http://www.vest.msk.ru).

Diwerden in der Forschung und verwendet praktische Tätigkeiten Führungsgremien der Association of Software Developers in Economics (AREP) und ihrer Mitglieder.

Über die wichtigsten Bestimmungen der Arbeit wurde berichtet und diskutiert unter:

Konferenz „IBM-Lösungen im Bereich der Geschäftsintegration für Telekommunikationsunternehmen“, Repräsentanz von IBM in Osteuropa (Moskau, 18. Juni 2002);

Symposium „Call Center CRM Solutions 2002/Call Centers and Customer Relationship Management“ (Moskau, März 2002);

Konferenzen von Entwicklern von Informationssystemen basierend auf den Tools des Unternehmens Centura Software Corp. (Berlin, Deutschland, 17.-19. November 1999);

Konferenz „InfoCity: Praxis und Probleme der Informatisierung von Städten“ (Moskau, Oktober 1999);

Wissenschaftliche und praktische Konferenzen der Firma „Infosoft“ (Moskau, 1995-1999);

Konferenz von Spezialisten im Bereich ACS und CIS“ Enterprise-Systeme"(Moskau, April 1998 und 28.-30. April 1997, Organisatoren: SoftService-Unternehmen und Repräsentanzen von Oracle, Informix, Sybase, Borland und Centura);

3. Jahreskonferenz „Unternehmensdatenbanken 98“ (Moskau, 31. März – 3. April 1998 und 26. – 29. März 1996, organisiert vom Zentrum für Informationstechnologien unter Beteiligung des Open Systems Publishing House);

Konferenz „Tekhnikom-97“ (Moskau, 24.-26. November 1997, Organisatoren: SoftService, Russischer Verband der Oracle-Benutzer, Repräsentanzen von Microsoft, Borland, Computer Associates, Lucent Software).

Probleme bei der AIS-Entwicklung

Die Einführung von Informationstechnologien in die Wirtschaft, das Eindringen von Computer- und Kommunikationstools in die Unternehmensführung auf allen Ebenen, das wachsende Interesse an der Interaktion von Unternehmen über das Internet erfordern konzeptionelle Änderungen in den Ansätzen zum Aufbau von AIS PM. Dies gilt nicht nur für reine technologische Probleme Aufbau und Betrieb von IS, aber auch Ansätze zur Unternehmensführung unter den Bedingungen der Informationsgesellschaftsökonomie.

AIS UP sollte den Anforderungen an Automatisierung und Informatisierung im gesamten Unternehmen gerecht werden, was den Softwareentwicklern die Aufgabe stellt: eine Plattform zu entwickeln, die die Arbeit einer großen Anzahl von Benutzern unterstützen kann; Unterstützung für Kommunikationstools und Industriestandards für Datenaustausch- und Komponenteninteraktionsprotokolle; Integration bestehender Entwicklungen in ein einziges System.

Die Integration heterogener Anwendungen in ein einziges AIS sollte Folgendes unterstützen: End-to-End-Geschäftsprozesse; einzelne Benutzeroberfläche (Portal); gemeinsamer Informationsraum.

Unserer Meinung nach liegt der Kern der gestellten Probleme nicht so sehr in den technischen Aspekten der Implementierung, sondern in der Notwendigkeit, ein grundlegend neues Modell der AIS UE-Architektur zu verwenden.

Lassen Sie uns die Vor- und Nachteile verschiedener IS-Architekturoptionen im Hinblick auf die Möglichkeiten zum Aufbau einer integrierten Lösung zusammenfassen.

Die Zentralisierung der Datenverarbeitung macht hohe Anforderungen zu den Servern. Mit zunehmender Anzahl gleichzeitiger Benutzer (was bei der Automatisierung von Prozessen im gesamten Unternehmen unvermeidlich ist) werden die Belastungen für die Hardwareplattform und die verwendete Software zu groß. Durch den Einsatz verschiedener Hardwarelösungen (Clustering, Multiprocessing und andere Formen der Kombination von Rechenressourcen) sowie der verteilten Verarbeitung mithilfe von Transaktionsmonitoren, Anwendungsservern und leistungsstarken industriellen DBMS können Sie wirklich skalierbare Lösungen erstellen und zentrale Knoten entlasten, indem Sie nicht nur die Leistung erhöhen Hardware, sondern auch durch den passenden Aufbau der Softwarekomponenten des Systems.

Selbst wenn der zentrale Datenbankserver jedoch in der Lage ist, die erforderliche Leistung bereitzustellen, treten bei einem solchen IS-Aufbau zwangsläufig Probleme bei der Aufrechterhaltung einer einheitlichen Struktur einer gemeinsamen Datenbank auf, wenn einzelne IS-Softwarekomponenten entwickelt werden verschiedene Unternehmen oder sogar Entwicklungsteams innerhalb derselben Organisation. Die Installation einer gemeinsamen Datenbank mit Zugriff von Programmen zur Lösung verschiedener Anwendungsprobleme ermöglicht die Bereitstellung eines gemeinsamen Informationsraums. Die oben aufgeführten Technologien ermöglichen einer großen Anzahl von Benutzern den Zugriff auf die Datenbank, dies garantiert jedoch nicht die korrekte Arbeit mit gemeinsam genutzten Daten. Es bleibt das Problem der logischen Datenintegrität. Bei der Verwendung von Programmen unterschiedlicher Hersteller ist es unumgänglich, Daten in Subsysteme aufzuteilen, ggf. durch Denormalisierung und Schaffung redundanter Strukturen. Schematische Architektur mit gemeinsame Basis in der folgenden Abbildung dargestellt (Abbildung 1-14). Wie aus dem obigen Diagramm hervorgeht, interagieren die Module nicht, das heißt, es findet kein Echtzeitaufruf von einem Modul zum anderen statt, es gibt keine betriebliche Unterstützung für einen End-to-End-Prozess. Die Daten werden in der Datenbank gespeichert, von wo aus sie anderen Modulen zur Verfügung stehen, die die Funktionen zur Verfolgung von Änderungen darin enthalten müssen, und die Relevanz der Daten hängt von der Häufigkeit der Überprüfung auf Aktualisierungen ab. Ein Beispiel für einen End-to-End-Prozess wäre eine Rechnungsstellung durch einen Mitarbeiter der Vertriebsabteilung. Wenn er hierfür ein CRM-System nutzt, muss die generierte Rechnung parallel zur Abrechnung im Logistikmodul des ERP-Systems verarbeitet werden, um die Ware zu reservieren, und unmittelbar danach – im Finanzmodul, um die Schulden des Käufers zu erhöhen. Hierzu müssen die entsprechenden Module prüfen, ob ein neues Konto vorhanden ist. Erfolgt dies nicht fristgerecht, kann eine Rechnung über den tatsächlich reservierten Artikel ausgestellt werden.

Damit verschiedene Module mit einer gemeinsamen Datenbankstruktur arbeiten können, müssen sie zunächst im Hinblick auf eine bestimmte Datenstruktur entwickelt werden oder einen vereinbarten Metadatenmechanismus (Repository) verwenden.

Bei Verwendung einer anderen Architektur, wenn heterogene Datenbanken auf verschiedenen Computern (und möglicherweise in verschiedenen Netzwerken) verwaltet und von autonomen Modulen verwendet werden (Abbildung 1-15), ist die Aufrechterhaltung der logischen Integrität der Daten eine noch zeitaufwändigere Aufgabe. In diesem Fall ist es notwendig, die Datenreplikation (Synchronisation), die Vereinheitlichung von Verzeichnissen, Kodierungs- und Klassifizierungsregeln zu regulieren und umzusetzen sowie den Replikationsmechanismus selbst zu entwickeln oder zu implementieren. All dies erfordert organisatorische Maßnahmen zur Synchronisierung der Datenbank. Es bleibt das Problem der automatischen Fortführung des Prozesses (ein Beispiel mit einer Rechnung).

Plattformen für die Implementierung der neuen AIS UE-Architektur

Zu Beginn des 21. Jahrhunderts wurden auf industrieller Ebene in der IT-Branche folgende Lösungen entwickelt und beherrscht, die eine flächendeckende Einführung der IT in wirtschaftliche Prozesse sicherstellten:

ein Werkzeug für Personal Computing, das darin besteht, dass bei vielen Arten von Arbeiten die Notwendigkeit von Vermittlern zwischen der Formulierung der Aufgabe und ihrem Ausführenden verschwunden ist, d ihre Kompetenz im Umgang mit Computern ohne Einbeziehung oder mit minimaler Unterstützung von technischem Begleitpersonal;

Mittel zur automatisierten Unterstützung für koordinierte gemeinsame Arbeit Gruppen („Teams“) von Arbeitern an einem Projekt, Dokument, einer Aufgabe usw.;

Mechanismus der elektronischen Kommunikation, der es in vielen Fällen ermöglichte, die Notwendigkeit der Übermittlung von Papierdokumenten zu beseitigen und die Notwendigkeit von Besprechungen zu minimieren, was besonders wichtig ist, wenn die Teilnehmer des einen oder anderen Geschäftsprozess.

Dank dieser Lösungen wurde es möglich, die meisten Arbeitsprozesse zu automatisieren, die sowohl innerhalb des Unternehmens in seinen Finanz-, Wirtschafts-, Produktions- und Handelsaktivitäten als auch im Zusammenhang mit externen Funktionen ablaufen. Die Kombination von Software- und Hardwaretools, die verschiedene Funktionen und Aufgaben automatisieren, ermöglicht die Verknüpfung von Technologie- (basierend auf Geräten und technischen Geräten) und Arbeitsabläufen (unter Beteiligung von Mitarbeitern aus allen Unternehmensbereichen) zu durchgängigen Geschäftsprozessen . Damit besteht grundsätzlich die Möglichkeit, das Problem der Isolierung der Entstehungsorte der Daten von den Zentren ihrer Speicherung und Verarbeitung, der Trennung der Arbeitsplätze voneinander zu lösen.

Auch die Lösung des Problems der Integration von AIS-Modulen und die Wahl eines zentralen oder dezentralen Ansatzes zur Organisation ihrer Interaktion ist dank der neuesten Entwicklungen führender Hersteller von Systemsoftware möglich: Betriebssysteme, Webserver, Anwendungsserver, DBMS und Middleware-Plattformen. Die Anwendungsintegration wird durch den Einsatz objektorientierter Entwicklungstechnologie und komponentenbasierter mehrschichtiger Architektur ermöglicht. Schlüsselprinzip Hier ist das Konzept der Programmierschnittstellen und die Regulierung ihrer Änderung und Erweiterung (IDL-Sprache).

Um in einer verteilten heterogenen Umgebung wie dem Internet zu arbeiten, werden aktiv Webdienstspezifikationen entwickelt, die jeweils eine oder mehrere Geschäftsabläufe oder -funktionen (Geschäftsabläufe, Funktionen) implementieren können. OASIS, BPMI sowie IBM, Microsoft und BEA haben die Workflow-Regulierungsspezifikationen BPEL4WS (Business Process Execution Language for Web Services), XLANG und WSFL (Web Services Flow Language) sowie die WfML-Koalition - XPDL (XML Process Definition Language) veröffentlicht. .

Der Trend geht dahin, Komponenten mit offenen Webservice-Schnittstellen zu Subsystemen zusammenzufassen, die logisch vollständige Geschäftsprozesszyklen ausführen. Dabei können sich die Komponenten auf verschiedenen über das Netzwerk verteilten Anwendungsservern befinden und mit einer oder mehreren Datenbanken arbeiten. Durch Variation der Anzahl und Beziehungen der Komponenten, der Anzahl und des Standorts der Netzwerkserver sowie der Möglichkeit, Komponenten auszutauschen oder im Netzwerk ohne Kompatibilitätsverlust zu verschieben, ist es möglich, ein AIS aufzubauen, das ein Gleichgewicht zwischen Zentralisierung und Dezentralisierung im Unternehmen aufrechterhält Management.

Der Umsetzung einer solchen Architektur stehen keine technischen Hindernisse entgegen. Moderne industrielle Anwendungsserver (z. B. MTS / COM + / .Net, ONE oder J2EE / EJB) ermöglichen den Aufbau mehrschichtiger Systeme, stellen eine gemeinsame Plattform für den Zugriff auf verschiedene Webdienste bereit, sorgen für transaktionale Betriebsintegrität und Lastausgleich mit Wettbewerbsfähiger Zugriff von Zehntausenden Benutzern in Echtzeit sowie Gewährleistung von Fehlertoleranz und Wiederherstellung nach Ausfällen.

Eine wichtige Errungenschaft der IT-Branche sind die weit verbreiteten und von führenden Softwareherstellern anerkannten Standards: K(COM/DCOM, CORBA, Java RMI) und Datenaustauschformate (EDI, XML).

Der EDI-Standard und seine branchenspezifischen Varianten (EDIFACT, XI2, HIPAA etc.) werden seit Mitte der 1970er Jahre im Finanz- und Industriesektor Nordamerikas und Europas eingesetzt und dominieren heute weltweit. Mit der wachsenden Popularität von XML im Internet wurde EDI in XML übersetzt.

Auf Basis von XML (DTD und XDR) wurden in verschiedenen Wirtschaftsbereichen Daten in Form sogenannter Fachwörterbücher oder Dokumenttypen entwickelt, strukturiert und formatiert, beispielsweise WIDL, OFX, FpML, IFX, XBRL, CRML und zahlreiche andere im Westen sowie CommerceML.ru und XML Partnership/ARB in Russland. Die American Society for Production and Inventory Management APICS, die ERP-/MRP-Klassensysteme zertifiziert, veröffentlicht Spezifikationen Wirtschaftssubjekte im XML-Format, beispielsweise die Struktur und das Format von Kunden- oder Rechnungsdaten. Selbstdokumentierendes XML sorgt für ein eindeutiges Verständnis von Daten sowohl für Menschen als auch für Programme.

AIS UE-Architektur

Um ein Modell der AIS UE-Architektur zu erstellen, betrachten wir ein Unternehmen als eine Reihe von Arbeits-, Finanz-, Material- und Informationsressourcen, die an Geschäftsprozessen beteiligt sind, um die Geschäftsziele eines Unternehmens zu erreichen. Unter Geschäftszielen versteht man hier die von den Eigentümern und Top-Managern vorgegebenen strategischen Langfristziele sowie die von Top- und Mittelmanagern vorgegebenen aktuellen Ziele. Ein Geschäftsprozess oder Geschäftsprozess ist eine Abfolge von Aktionen von Mitarbeitern, Vorgängen an Arbeitsplätzen sowie von Software und Hardware im automatischen Modus ausgeführten Funktionen. Nennen wir jede Aktion oder ihre Abfolge eine Phase des Prozesses. Synonyme für Aktionen können auch Operationen, Prozeduren sein. Wenn eine Phase die Handlungen eines Mitarbeiters (einer Rollengruppe, eines Vertreters oder Leiters einer Abteilung sowie einer Person, die eine offizielle Position innehat) erfordert, wird sie auch als Aufgabe bezeichnet und der Mitarbeiter wird als Ausführender bezeichnet. Die Abfolge von Aktionen in einem Geschäftsprozess kann mehrdeutig sein, das heißt, eine Beschreibung des Prozesses in Form eines gerichteten Graphen kann Verzweigungen mit Bedingungen für den Übergang von einer Phase zur anderen umfassen. Typische Stufenketten lassen sich in Teilprozesse gliedern. Die Bewegung von Aufgaben durch bestimmte Phasen des Prozesses wird als Route bezeichnet. Wenn der Prozess aufgrund willkürlicher Übergänge zwischen Phasen, deren Entscheidung der Ausführende während der Ausführung der Aufgabe in der aktuellen Phase trifft, nicht beschrieben werden kann, spricht man von freiem Routing.

AIS PM soll es ermöglichen, Geschäftsprozesse formal in grafischer Form in Form eines gerichteten Graphen (Digraphen) zu beschreiben, dessen Scheitelpunkte die Stufen und dessen Kanten die Übergänge zwischen den Stufen sind. In einem bestimmten Fall sieht das Geschäftsprozessdiagramm so aus netzwerkdiagramm, wobei Scheitelpunkte Jobs mit Angabe ihrer Dauer bezeichnen und ausgerichtete Kanten (Pfeile) die Reihenfolge der Jobs anzeigen. Gemäß der Beschreibung des Prozesses, der sogenannten Prozesslandkarte, muss AIS UE Ressourcen verwalten (oder genauer gesagt, den Managern des Unternehmens bei deren Verwaltung helfen), Aufgaben und deren Ausführende zuweisen sowie Software und Hardware aufrufen (aktivieren). um automatisierte Verfahren durchzuführen.

Die Parameter der Unternehmensgröße wirken sich auf die Organisation des Managements in einem bestimmten Unternehmen aus, was sich in den Anforderungen an AIS UE widerspiegelt. Andererseits beeinflusst AIS UE beispielsweise die Größe des Unternehmens und trägt zum Geschäftswachstum bei. Die Änderung eines der Parameter erfordert eine Aktualisierung des AIS, ebenso wie die Einführung des AIS die Organisation des Managements verändern kann.

Der Zweck der Fokussierung auf Geschäftsprozesse beim Aufbau von AIS UE besteht darin, eine gemeinsame Plattform zu finden, auf deren Grundlage eine angemessene Änderung des AIS möglich ist, ohne dass eine vollständige Neuorganisation des Systems erforderlich ist. Bei dieser Plattform handelt es sich um die Modellierung von Geschäftsprozessen durch Prozessmanagementsoftware.

Als Kernstück von AIS PM ist es notwendig, ein System zu entwickeln, das mehrere Funktionen vereint, die in der Überprüfung von Prozessmanagementsystemen diskutiert wurden (Absätze „1.1.7 Dokumentenmanagementsysteme“ auf Seite 31 und „1.1.8 Prozessmanagementsysteme“ auf Seite). 34). Darunter: Workflow – ein Subsystem zur Verwaltung von Arbeitern und technologische Prozesse, das eine vordefinierte und freie Aufgabenverteilung zwischen den Ausführenden ermöglicht; Docflow – ein Subsystem zur Verwaltung des Dokumentenflusses und zur Weiterleitung von Dokumenten mit Verfolgung ihres Status; Groupware – ein Subsystem zur Unterstützung der Funktionen der operativen Aufgabenzuweisung und der freien Weiterleitung (Ad-hoc) von Aufgaben zwischen Mitgliedern einer Gruppe von Darstellern; Datenfluss – Weiterleitung von Daten, Datenpaketen und Nachrichten zwischen Anwendungen.

Im Gegensatz zur akzeptierten Praxis der autonomen Nutzung solcher Systeme gehen wir hier vom Vorhandensein einer gemeinsamen Prozesslandkarte, eines gemeinsamen Moduls zur Verarbeitung von Prozessschritten, eines gemeinsamen Mechanismus zur Zuweisung von Ausführenden und zur Weiterleitung von Aufgaben und Daten aus.

Somit werden die technologischen Daten generiert technische Geräte, Sachdaten, die von Benutzern an Arbeitsplätzen in das IS eingegeben werden (einschließlich Primärdokumente), sowie von ihnen generierte Daten Softwareanwendungen, werden in das AIS UE eingegeben und stehen den Verbrauchern von Informationen in Echtzeit zur Verfügung.

Schematisch wird der Lebenszyklus der Datenverarbeitung in AIS UE in der folgenden Abbildung dargestellt (Abbildung 2-2). Manuell eingegebene oder von Softwarekomponenten empfangene Daten werden als Dokument formalisiert, das vom Workflow-Modul gemäß der Prozesslandkarte weiterverarbeitet wird. Entlang der Verarbeitungsroute (sofern die Systemkonfiguration dies erfordert) ruft das Dokumentenverwaltungssubsystem die Module funktionaler Subsysteme zur Verarbeitung von Finanz-, Geschäfts- und anderen Arten von Transaktionen auf. Dadurch werden Anmeldeinformationen in strukturierten Datenbanken gespeichert. Die Dokumente selbst wiederum werden in einem Speicher oder einer unstrukturierten Datenbank gespeichert. Alle diese Datenbanken müssen den Analysemodulen des Berichtssubsystems zur Verfügung stehen, um die erforderlichen Berichte zu erstellen.

Erfahrung in der praktischen Umsetzung des AIS UE-Modells

Von 1995 bis 1999 wurde unter der Leitung des Autors der Dissertation das System der integrierten Automatisierung der Unternehmensführung „Flagman“ der Firma „Infosoft“ entwickelt, das derzeit in mehr als hundert großen und mittelständischen Industriebetrieben eingesetzt wird , Bau-, Handels-, Agrarunternehmen und Haushaltsorganisationen Russland und GUS-Staaten. Das System entwickelt sich weiterhin auf der Grundlage des vom Autor entwickelten Kernels weiter, und bis 2002 umfasst das „Flaggschiff“ mehr als zehn Hauptsubsysteme, wie in der folgenden Abbildung dargestellt (Abbildung 3-2):

Grundlage des Systems „Flagship“ ist das Basismodul „Dokumentenmanagement“, das für die Eingabe, Bearbeitung, Weiterleitung und den Druck aller Primärdokumente zuständig ist. Weitere Basismodule sind „Administration“ und „Tools“, die allen Funktionsmodulen gemeinsam sind. Sie ermöglichen die Konfiguration von Rollengruppen und Zugriffsrechten, Arbeitsplätzen bis hin zu Menüpunkten, Dokumentenlayouts und Berichtsvorlagen.

Die Vorteile des implementierten Modells waren eine einzige Erfassung von Primärdokumenten, die Erstellung von Konten in funktionalen Subsystemen auf Basis dieser Dokumente und die Vereinheitlichung der Arbeit mit Primärdokumenten.

Die rasante Entwicklung der Subsysteme und die mangelnde Standardisierung ihrer Interaktion haben dazu geführt, dass die Integration um eine zentrale Datenbank und gemeinsame Tabellen herum durchgeführt wurde. Wenn wir die zweistufige Architektur nicht berücksichtigen, deren Wahl durch den Entwicklungsstand der Entwicklungstools im Jahr 1995 bestimmt wurde, wurde die gegenseitige Abhängigkeit der Module zum Hauptproblem bei der Entwicklung des Systems. Seine ersten Implementierungen offenbarten die Unzulänglichkeit der Workflow-Automatisierungsfunktionen allein durch Dokumentenweiterleitung und warfen die Frage nach der Notwendigkeit der Implementierung eines Prozessmanagementmoduls (Workflow) auf.

Wenn wir die Implementierung genauer betrachten, dann ist das Dokumentenverwaltungsmodul eine Bibliothek von Objekten, die in allen Subsystemen enthalten ist und auch als eigenständiges Modul kompiliert wird. Die Bibliothek umfasst Werkzeuge zum Einrichten von Dokumenttypen und -varianten, zur Zusammensetzung von Feldern, Eingabe- und Bearbeitungsformularen, eine Liste von Zuständen, mögliche Kombinationen von Übergängen von Zustand zu Zustand, eine Liste von Operationen mit Bezug auf Funktionsmodule, Vorlagen und Druck Formulare sowie Regeln für die Bildung von Registern und Dokumentenjournalen.

Operationen mit Dokumenten ändern ihren Zustand und rufen auch die Funktionen von Anwendungssubsystemen auf. Die Liste der Funktionen ist in jedes Subsystem eingebettet und für dieses spezifisch. Für begleitende Programmierer beim Aufbau des Systems stehen Funktionsparameter und die Möglichkeit zur Anbindung von Dokumentfeldern über Formeln zur Verfügung. Dadurch können Sie die meisten Finanztransaktionen sowie Logistikfunktionen automatisieren. persönliche Rekorde und Gehaltsabrechnung, aber die vollständige Implementierung erfordert immer noch eine Skriptsprache.

Das System verfügt über einen integrierten Berichtsgenerator, der allen Subsystemen gemeinsam ist. Da das System auf dem Prinzip der Integration rund um eine zentrale Datenbank basiert, hat der Generator Zugriff auf alle Daten, unabhängig davon, ob sie zu Modulen gehören. Berichte werden in eine hierarchische Struktur eingeteilt, jedes der Berichtslayouts enthält eine Vorlage dafür Vorschau und Drucken sowie SQL-Abfragen zum Generieren des resultierenden Datensatzes. Die generierten Berichte können als Dokumente weiterverarbeitet werden.

Es sollte auch beachtet werden, dass das Flagship-System ein einheitliches System implementiert Aussehen Subsysteme. Das allgemeine Verwaltungsmodul für Benutzeroberflächenelemente, AWP-Funktionen, einschließlich Menüs und Symbolleisten, ermöglicht es Ihnen, das Erscheinungsbild einheitlich anzupassen.

An dieser Moment Die IT-Entwicklung erfordert eine Aktualisierung der Plattform des Flagman-Systems. Zunächst gilt es, diese auf eine dreistufige Architektur zu übertragen und das Dokumentenmanagementmodul zu einem voll funktionsfähigen Prozessmanagementsystem weiterzuentwickeln. Außerdem müssen Mechanismen zur Integration externer Anwendungen entwickelt werden, da das System lediglich über die Möglichkeit verfügt, Daten zu importieren und zu exportieren.

Dennoch zeugen zahlreiche Beispiele für die erfolgreiche Implementierung und den kommerziellen Betrieb des Flagman-Systems, das Wachstum der Verkaufszahlen in den Jahren 2001-2002, davon Wirtschaftlichkeit Lösungen für die Automatisierung von Unternehmen verschiedener Tätigkeitsbereiche, Branchen und Größenordnungen.

Im Februar 1999 wurde das unter der Leitung des Autors entwickelte „Flagman“-System der Firma „Infosoft“ von der Centura Software Corp. als beste russische Entwicklung im Centura Team Developer Toolkit ausgezeichnet. (USA) und die Firma „Interface“ (Russland). 1999, 2000 und 2001 CIS „Flagman“ wurde von den Experten der Jury des „Business-Soft“-Wettbewerbs der Association of Software Developers in the Field of Economics (AREP), TSIES „Business Programs-Service“, als unternehmensweites Informationssystem zertifiziert “, die Zeitschrift „Accounting“ und „Finanzzeitung“.