Die Entwicklung technischer Spezifikationen gemäß GOST 34 ist einfach und unkompliziert

Oft hört man die Meinung, dass die Erstellung der Leistungsbeschreibung nach GOST 34 (TK) nicht nur mühsam, sondern auch äußerst ärgerlich ist, weil man viel Unsinn aller Art Wasser schreiben muss. Aber denken Sie darüber nach: Ganze Forschungsinstitute waren an der Entwicklung dieses GOST beteiligt, es war ein Projekt auf Landesebene, die Erfahrung von Hunderten von Automatisierungsprojekten, komplexe Projekte wurden zusammengefasst. Könnten sie wirklich Unsinn schreiben?

Mit einem kompetenten Ansatz hilft GOST nicht nur bei der Entwicklung technischer Spezifikationen, sondern auch bei der Umsetzung des gesamten Automatisierungsprojekts (und nicht nur bei staatlichen Verträgen, sondern auch bei der kommerziellen Entwicklung) erheblich. Literaten haben es geschrieben. Aber um die Früchte ihrer Arbeit nutzen zu können, muss man das Konzept nicht nur von TK, sondern auch von GOST 34 als Ganzes ein wenig verstehen.

In diesem Artikel werden wir Punkt für Punkt alle Anforderungen von GOST analysieren und versuchen, die Entwicklung von TK gemäß GOST 34 nicht zu einer Belastung, sondern zu einer großen Hilfe im Projekt zu machen.

1. Worum geht es in dem Artikel?

Oft hört man die Meinung, dass die Erstellung der Leistungsbeschreibung nach GOST 34 (TK) nicht nur mühsam, sondern auch äußerst ärgerlich ist, weil man viel Unsinn aller Art Wasser schreiben muss. Aber denken Sie darüber nach: Ganze Forschungsinstitute waren an der Entwicklung dieses GOST beteiligt, es war ein Projekt auf Landesebene, die Erfahrung von Hunderten von Automatisierungsprojekten, komplexe Projekte wurden verallgemeinert. Könnten sie wirklich Unsinn schreiben?

Mit einem kompetenten Ansatz hilft GOST nicht nur bei der Entwicklung technischer Spezifikationen, sondern auch bei der Umsetzung des gesamten Automatisierungsprojekts (und nicht nur bei staatlichen Verträgen, sondern auch bei der kommerziellen Entwicklung) erheblich. Literaten haben es geschrieben. Aber um die Früchte ihrer Arbeit nutzen zu können, muss man das Konzept nicht nur von TK, sondern auch von GOST 34 als Ganzes ein wenig verstehen.

TK ist übrigens nicht das erste Dokument, das während des Automatisierungsprojekts entwickelt wird. Dies wird ausdrücklich in Absatz 1.5 angegeben. GOST 34.602-89: „Die TK im KKW wird auf der Grundlage der ursprünglichen Daten entwickelt, einschließlich der Daten, die in der endgültigen Dokumentation der Phase„ Erforschung und Rechtfertigung der Schaffung des KKW “enthalten sind.“ Weitere Informationen finden Sie in meinem Artikel Pre-Design-Umfrage während der Entwicklung eines Informationssystems .

ACHTUNG: DER ZWECK DIESES ARTIKELS IST NICHT, GOST ZU ERSETZEN UND EINIGE SEINEN BESTIMMUNGEN ZU ERKLÄREN.

2. Charakteristische Merkmale der technischen Spezifikationen gemäß GOST 34

2.1. Nach welchem ​​Standard wird der ToR kompiliert?

Der vollständige Name des Standards für TK gemäß GOST 34 lautet wie folgt: GOST 34.602-89 „Informationstechnologie (IT). Eine Reihe von Standards für automatisierte Systeme. Die Leistungsbeschreibung für die Erstellung eines automatisierten Systems. "

Der Standard selbst ist auf nur 15 Seiten gedruckt (ja, ziemlich viel). Die Sprache ist Russisch, wirklich Russisch und nicht fremd auf dem kyrillischen Alphabet. Das heißt, wenn Sie nicht im Voraus in Ihren Kopf fahren, dass weder die Texte von GOSTs noch Bundesgesetze oder Dissertationen für einen bloßen Sterblichen verständlich sind, ist es durchaus möglich, zu lesen und einzudringen, obwohl dies oft nicht das erste Mal ist.

In der Tat verwendet der Standard viele dunkle Begriffe. Was versteht man zum Beispiel unter sprachlicher Unterstützung? Um die verwendeten Konzepte zu verdeutlichen, sollte man sich an GOST 34.003-90 „Informationstechnologie (IT)“ wenden. Eine Reihe von Standards für automatisierte Systeme. Automatisierte Systeme. Begriffe und Definitionen. "

2.2. Warum benötigen Sie GOST für die Leistungsbeschreibung?

Wenn Sie ein neues Dokument für Sie erstellen müssen, suchen Sie wahrscheinlich im Internet nach einer Vorlage für ein solches Dokument oder fragen Sie bei Kollegen nach. JEDER Standard für Dokumente oder Prozesse ist also eine Vorlage. Darüber hinaus vereinfacht die Vorlage die Entwicklung des Dokuments erheblich: Struktur und Inhalt wurden bereits für Sie ausgearbeitet. Darüber hinaus berücksichtigt eine solche Vorlage solche Momente, an die Sie sich nicht erinnert hätten.

2.3. Welche Rolle spielt die Leistungsbeschreibung im Projekt?

Gemäß Absatz 1.7 der Norm RD 50-682-89 ist "die Leistungsbeschreibung das Hauptdokument, gemäß dem die Erstellung der AU und die Annahme durch den Kunden durchgeführt werden". Und das ist wirklich das Hauptdokument. Es sollte alles beschreiben, was für die Entwicklung und Implementierung des Systems erforderlich ist.

TOR legt das Gesamterscheinungsbild des Systems, den Arbeitsaufwand (Entwicklungsrahmen) sowie das Entwicklungs- und Akzeptanzverfahren fest. Alles beginnt mit TK und alles endet damit. Dieses Dokument ist ideal, damit Ihr Kunde die Bedeutung und Komplexität der Aufgabe versteht und weiß, warum er Geld zahlt.

Darüber hinaus werden die technischen Spezifikationen sowohl für den Auftragnehmer als auch für den Kunden zusammengestellt, da das Automatisierungsprojekt von Teams beider Seiten durchgeführt wird. In jedem IT-Projekt gibt es eine Vielzahl von organisatorischen Aktivitäten, deren Umsetzung ohne die aktive Beteiligung des Kunden nicht möglich ist. Erklären Sie dies den Kunden bei jeder Gelegenheit, sonst haben sie den Eindruck, dass sie nur Geld bezahlen und aufrecht sitzen müssen: Die Angestellten werden alles tun. Und dann schlägt das Projekt fehl und der Showdown beginnt. Ohne ein echtes Team lohnt es sich im Allgemeinen nicht, ein Projekt zu starten.

Formulieren Sie TK nicht formal. Wenn Sie nicht wissen, was Sie schreiben sollen, bedeutet dies, dass es zu früh ist, TK zu entwickeln. Sie haben kein Verständnis für das System, der automatisierte Prozess selbst, das Automatisierungsobjekt, sind noch nicht verstanden. Sie sollten ein Systemkonzept erstellen, darüber haben wir ganz am Anfang des Artikels gesprochen.

2.4. Wie alt sind GOST 34.602-89 und gibt es neuere Standards?

Nicht so veraltet. Ich konnte fast keine nicht zum Kern gehörenden Dinge finden. Und keiner von denen, die behaupten, GOST 34 sei veraltet, kann kein einziges Beispiel nennen (hatte wahrscheinlich nicht die Qualifikation, es zu lesen?). Tatsache ist, dass GOST einen allgemeinen Ansatz für das Automatisierungsprojekt beschreibt, es geht nicht um Programmierung, Bei GOST 34 geht es nicht darum.

Wenn wir über den Vergleich mit anderen Standards sprechen, gibt es nichts Besonderes, mit dem wir vergleichen können. GOST 34 bietet einen so umfassenden Überblick über das Automatisierungsprojekt, dass andere Standards (meiner Meinung nach) nicht für die Außensohle geeignet sind. Ja, sie sind einfacher (daher beliebter), aber die Tiefe ist nicht dieselbe. Hier ist eine Liste von Standards, mit denen Sie sich vertraut machen sollten, wenn Sie Ihre eigenen Standards für ein Automatisierungsprojekt entwickeln:

• IEEE 830-1998. Methode zur Erstellung von Spezifikationen für Softwareanforderungen.
• GOST R ISO / IEC 12207-2010. Informationstechnologie. System- und Softwareentwicklung. Software-Lebenszyklusprozesse.
• ISO / IEC / IEEE 29148-2011. System- und Software-Engineering - Lebenszyklusprozesse - Requirements Engineering.
• GOST R 54869-2011. Projektmanagement. Projektmanagementanforderungen.
• Well und State Standard Spezifikationen 34 Serie.

3. Allgemeine Grundsätze für die Erstellung technischer Spezifikationen gemäß GOST 34

3.1. Welcher Spezialist sollte die Leistungsbeschreibung gemäß GOST 34 erstellen?

Entwickler schwören oft, wenn sie TK gemäß GOST 34 entwerfen. Warum? Ja, weil es nicht die Sache der Programmierer ist. Leistungsbeschreibungen gemäß GOST 34 können Programmierern im Allgemeinen nicht angezeigt werden. Hierfür gibt es technische Projektunterlagen. Leistungsbeschreibung - Ein Dokument, das mit dem Kunden vereinbart wurde und beim Projektmanager ständig auf dem Tisch liegt. TK beantwortet zwei Fragen: WAS soll das System tun und wie soll es erstellt werden. Das technische Projekt beantwortet die Frage: WIE sollen die Anforderungen des ToR erfüllt werden? In TK schreiben Sie beispielsweise vor, dass eine Autorisierung durch Anmeldung und Kennwort erfolgen soll, und in TP geben Sie Layouts der Schnittstelle, der Skripte und der Datenbankstruktur an. Warum es eine Unterteilung in verschiedene Phasen gibt und warum Sie die Aufgabe für Programmierer nicht sofort erledigen sollten, finden Sie in meinen Artikeln die Geheimnisse des erfolgreichen Entwurfs von IP (Informationssystem) am Beispiel des Aufbaus eines Krankenhauses und der Vorentwurfsumfrage bei der Entwicklung eines Informationssystems .

Die Leistungsbeschreibung sollte von einem Geschäftsanalysten erstellt werden, da er ein "Übersetzer" zwischen dem Kunden und dem Entwicklungsteam ist. Die Aufgabe eines Business Analysten ist es, zu verstehen, was der Kunde braucht, und es auf eine Weise auszudrücken, die für das Team klar ist. Und drücken Sie es in Form von technischen Spezifikationen aus. Darüber hinaus muss ein Business Analyst nicht nur dem Kunden und seinen Mitarbeitern zuhören, sondern auch herausfinden, was sie nicht gesagt haben (und dies sind normalerweise mehr als 50%). Daher muss der Analyst über gute Kenntnisse der zu automatisierenden Prozesse verfügen und aufgrund seines Wissens die Lücken füllen, die bei den Ergebnissen der Umfrage bestehen geblieben sind.

3.2. Welche Seite sollte die Leistungsbeschreibung sein?

Grundsätzlich wird die Leistungsbeschreibung vom Auftragnehmer zusammengestellt Warum?

Nicht nur, weil dies in Anhang 1 zu GOST 34-602-89 empfohlen wird. Tatsächlich verfügt der Kunde in der Regel nicht über die entsprechenden Spezialisten. TK wird jedoch unbedingt vom Kunden entwickelt und vereinbart. Und hier muss sichergestellt werden, dass die Vereinbarung nicht formell ist. Ich versuche immer darauf zu bestehen, dass wir zusammen mit dem Kunden jeden Artikel im Detail analysieren. Ihr Ziel ist es, den Kunden in das Projekt einzubeziehen. Andernfalls wird er seine Erwartungen an das System nicht erfüllen, was bedeutet, dass er zum einen mit den Ergebnissen unzufrieden ist und zum anderen nicht in der Lage ist, die erforderlichen organisatorischen Maßnahmen durchzuführen.

3.3. Wie weit können Sie von GOST 34 gehen?

Jede Vorlage hat auch einen erheblichen Nachteil - dies ist eine Vorlage. Das heißt, ein Schritt nach rechts und links ist das höchste Maß an sozialem Schutz (wie die Todesstrafe zuvor genannt wurde).

In der Tat ist dies nicht so. Jeder Prozessstandard (dh ein Standard nicht für Wurst, sondern für einige Aktivitäten) gibt nur allgemeine Hinweise und Umrisse. Es wurde geschaffen, um etwas Wichtiges nicht zu vergessen, die Erfahrung von Generationen an Sie weiterzugeben und Sie nicht hinter die Fahnen zu treiben.

Glaubst du nicht? Lesen Sie dann Abschnitt 2.2 von GOST 34.602-89 (die Zahlen nach dem Bindestrich sind übrigens das Jahr der Veröffentlichung des Standards oder seiner Ausgabe): „Je nach Art, Zweck, spezifischen Merkmalen des Automatisierungsobjekts und den Funktionsbedingungen des Systems können Abschnitte von TK in Form von Anwendungen erstellt werden. Unterabschnitte von TK ausschließen oder zusammenführen. “ Auch in Absatz 1.2. In RD 34.698-90 heißt es: „Der Inhalt der Dokumente ist allen AS-Typen gemeinsam und kann bei Bedarf vom Entwickler der Dokumente in Abhängigkeit von den Merkmalen des erstellten AS ergänzt werden. Es ist zulässig, zusätzliche Abschnitte und Informationen in Dokumente aufzunehmen, um Abschnitte zu kombinieren und auszuschließen. “

Wenn Sie nur allgemeine Sätze zitieren können, schreiben Sie im Allgemeinen nichts für alles Gute, gegen alles Schlechte. Andernfalls nimmt der Fachmann, der das Dokument liest, nachdem er solche Passagen erfüllt hat, das Dokument nicht mehr ernst und wichtige Punkte werden übersehen. Machen Sie das Lesen eines Dokuments nicht zu einer Qual!

3.4. Warum beschreibt TK nach GOST 34 so viele Anforderungen, die nicht direkt mit den Funktionen des Systems zusammenhängen?

In einem TOR von 30 Seiten können nur 7 bis 10 Seiten Funktionen zugewiesen werden. Dies hat eine Erklärung. Tatsache ist, dass die Entwickler von GOST 34 das Automatisierungsprojekt ganz anders betrachteten als wir. Und sie sahen korrekter und umfassender aus.

Erstens werden in der ersten Hälfte von TK nicht nur allgemeine Informationen über das System und die allgemeinen Anforderungen präsentiert. Wir müssen verstehen, warum das System erstellt wird, welche Prozesse es automatisiert, was getan werden muss, damit das System funktioniert, welche Art von System das System hat. Es scheint alltäglich zu sein, aber ohne sie werden die Teammitglieder das Ziel der Arbeit und die Mittel zur Erreichung des Ziels anders verstehen. Für uns ist es sehr wichtig sicherzustellen, dass alle Teilnehmer auf die gleiche Welle eingestellt sind und nicht wie ein Schwan, Krebs und Hecht.

Zweitens sahen die Compiler von GOST 34 das System hauptsächlich als Menschen und dann als Hardware-Software-Komplex. So definiert GOST 34.003-90 ein automatisiertes System: „Ein System, das aus Personal und einer Reihe von Automatisierungstools für seine Aktivitäten besteht und Informationstechnologie zur Ausführung etablierter Funktionen implementiert.“ Ein Informationssystem ist also ein geschulter Personal-, Software- und Hardwarekomplex. Computer von Buchhaltern wegnehmen, sie sind zwar schwierig, können aber ihre Arbeit erledigen, wenn auch mit Papierregistern. Aber 1C wird ohne einen Buchhalter nicht unabhängig arbeiten. Daher die vielen Abschnitte der TK zu organisatorischen Maßnahmen. Wie sie sagen, besteht ein IT-System zu 20% aus IT, der Rest sind organisatorische Maßnahmen. Das heißt, TK ist ein Dokument, das alles beschreibt, was für die Implementierung des Systems erforderlich ist, von A bis Z.

Achten Sie drittens auf den Namen GOST 34.602-89: "Leistungsbeschreibung für die Erstellung eines automatisierten Systems". TK nicht auf dem System, sondern auf der Erstellung des Systems. Was ist der Unterschied? Der Unterschied besteht darin, dass der ToR nicht nur die Anforderungen für das System selbst festlegt, sondern auch den Prozess seiner Erstellung regelt, dh das Dokument enthält Anforderungen für alle organisatorischen Maßnahmen, deren Umsetzung erforderlich ist, um das Ergebnis zu erzielen. Während der Implementierung eines Automatisierungsprojekts ist es häufig erforderlich, eine Reihe von Prozessen neu zu strukturieren, Personal zu schulen und die Hardware vorzubereiten.

Viertens ist der ToR ein Dokument, mit dem Sie abhaken können: Haben wir diese Anforderung berücksichtigt oder nicht? Vielleicht setzen Sie 10 Ticks automatisch sauber, da dies Standardlösungen sind. Das Häkchen Nummer 11 zeigt jedoch ein sehr großes Problem an. Wenn Sie dieses Problem jetzt überspringen, wird es irgendwo im Implementierungsprozess angezeigt, wenn alle Fristen und Budgets bereits festgelegt wurden.

Fünftens können , wie oben erwähnt, unnötige Unterabschnitte ausgeschlossen werden, dies ist zulässig. Wenn Sie beispielsweise sicher sind, dass in Ihren Designs nichts patentiert werden kann, warum sollten Sie dann Anforderungen an die Patentreinheit stellen? Dies ist nicht der Fall, wenn es kein Wasser und kein Syud ohne Wasser gibt.

3.5. Warum sagen die verschiedenen Abschnitte dasselbe?

In der Tat gibt es in TK Unterabschnitte, die den Inhalt anderer Unterabschnitte weitgehend wiederholen. Beispielsweise gibt es Anforderungen an die organisatorische Unterstützung sowie an die Anzahl und Qualifikation des Personals. In beiden Absätzen sprechen wir über Mitarbeiter.Im ersten Fall geben wir jedoch Auskunft über die Organisationsstruktur: Welche Abteilungen sollten sein, wie sollte die Interaktion mit anderen Abteilungen hergestellt werden. Stimmen Sie zu, dies ist keineswegs gleichbedeutend mit den Anforderungen an die Anzahl und Qualifikation des Personals.

Für kleine Systeme sind jedoch nur ein oder zwei Administratoren und einige Moderatoren erforderlich. In diesem Fall haben wir einfach nichts in zwei ganzen Abschnitten zu beschreiben. Lassen Sie dann einige Abschnitte weg und geben Sie in den anderen eine vollständige Anforderungserklärung ab.

3.6. Muss ich TK qualitativ ausstellen?

Obwohl die Anforderungen für das Design von TK in Absatz 3 von GOST 34.602-89 angegeben sind, lassen Sie uns einige Worte zu diesem Aspekt sagen.

Natürlich der Hauptinhalt. Aber erstens werden sie von Kleidern begrüßt, und zweitens ist es schwierig, Analphabeten mit einer überspringenden Schrift zu lesen. Die Leser werden durch minderwertiges Design abgelenkt, und es wird für sie schwieriger, sich mit den Inhalten zu befassen. Daher werden strenge technische Inhalte und begrenzte Terminologie in technischen Dokumenten ohne farbenfrohe Ausdrücke akzeptiert: Der Leser sollte sich auf das Wesentliche konzentrieren und nicht auf die künstlerischen Wendungen.

Hier einige Vorschläge für die Ausführung großer Dokumente wie TK.

ErstensEs ist unbedingt erforderlich, Stile in einem großen Dokument zu verwenden. Außer zum Unterstreichen oder Hervorheben innerhalb eines Absatzes dürfen Sie die Einstellungen für Schriftart und Absatz nicht nur für ein Fragment ändern. Wenn Sie ändern, dann den Stil.

Zweitens dürfen wir solche obligatorischen Elemente wie ein automatisch vervollständigtes Inhaltsverzeichnis, eine Liste von Begriffen und Abkürzungen nicht vergessen (nun, es macht keine Freude zu erraten, was mit dieser oder jener Abkürzung gemeint ist), die Titelseite. Es ist auch ratsam, eine Liste der Versionen des Dokuments und eine Liste der Änderungen bereitzustellen: Es ist sehr einfach, später zu verfolgen, wann eine bestimmte Version gesendet wurde.

ViertensJede einzelne Anforderung muss in einem separaten nummerierten Absatz aufgeführt werden. Wenn ein Fragment 2-3 Anforderungen enthält, wird nur die erste gelesen, und unser Gehirn überspringt den Rest. TK ist ein Dokument, in dem Sie vor jedem Absatz überprüfen können, ob die Anforderung erfüllt ist oder nicht.

Fünftens , sparen Sie nicht an der Platzierung von Links. Manchmal lesen Sie einen Absatz, in dem eine Funktion oder Anforderung erwähnt wird, und Sie verstehen nicht, dass dieser aus demselben oder einem anderen Dokument stammt. Wenn von diesem, dann in welchem ​​Abschnitt. Versuchen Sie daher, auf andere Abschnitte zu verweisen, wenn diese im aktuellen Text erwähnt werden. Natürlich sollten Links automatisch sein.

Beachten Sie, dass die Arbeitserklärung nach strengen Regeln ohne Rahmen erstellt wird (dies ist in Absatz 3 angegeben), die übrigen Dokumente jedoch mit einem Rahmen. Dies ist in GOST 24.301-80 „System der technischen Dokumentation für ACS festgelegt. Allgemeine Anforderungen für die Umsetzung von Textdokumenten (in der geänderten Fassung Nr. 1, 2). “ Diese Norm legt die Regeln für die Ausführung aller Dokumente außer TK und Dokumenten fest, die in der Vorentwurfsphase erstellt wurden. Obwohl ich persönlich den Rahmen in keinem Dokument mag.

4. Abschnitt 1. „Allgemeine Informationen“ / S. 2.3 GOST 34.602-89 /

Die meisten Informationen in diesem Abschnitt müssen nicht kommentiert werden, daher konzentrieren wir uns nur auf einige Unterabschnitte.

Mit der „Liste der Dokumente, auf deren Grundlage das System erstellt wird“ meinen wir also Gesetze, Anordnungen oder eine Vereinbarung. Ein solches Dokument kann auch eine andere TK sein, wenn wir TK für das Subsystem entwickeln. Im Allgemeinen gibt es mehrere Abschnitte im ToR, die eine Liste von Dokumenten enthalten, und man muss die Unterschiede zwischen dem Zweck dieser Teile der technischen Aufgabe sehr klar verstehen.

Im Unterabschnitt "Verfahren zur Verarbeitung und Präsentation der Ergebnisse der Arbeiten zur Erstellung des Systems (seiner Teile), zur Herstellung und Inbetriebnahme einzelner Werkzeuge (Hardware, Software, Informationen) und der Software und Hardware (Software und methodisch) der Systemkomplexe" werden dem Kunden allgemeine Informationen zur Annahme von Arbeiten gegeben. Zum Beispiel die Tatsache, dass wir Dokumentation übertragen und eine Reihe von Systemtests durchführen. Hier erwähnen wir nur das Verfahren zum Übertragen der Arbeitsergebnisse, und im Folgenden wird in anderen Abschnitten dieses Thema ausführlich beschrieben.

5. Abschnitt 2. „Zweck und Ziele der Schaffung (Entwicklung) des Systems“ / p. 2.4 GOST 34.602-89 /

Hier müssen wir den Unterschied zwischen dem Zweck und dem Zweck der Schaffung eines Systems verstehen. Sehr oft werden diese Konzepte verwechselt. Zum Beispiel schreiben sie, dass der Zweck des Systems die Automatisierung Ihres persönlichen Kontos ist und das Ziel darin besteht, ein persönliches Konto zu erstellen. Öl ist Öl. In einigen Fällen stimmen diese Konzepte wirklich überein, dann schreiben Sie nur den Termin.

Mit dem Ziel ist alles klar: Wir geben genau die Art (en) der automatisierten Aktivität an. Wenn wir beispielsweise ein System für die Produktionsabrechnung erstellen, sollten automatisierte Abrechnungsarten, automatisierte Vorgänge sowie Objekte genannt werden, deren Automatisierung angenommen wird.

Mit dem Ziel ist alles anders. Das Ziel ist, wofür wir ein Projekt planen. Sie können es Geschäftsziele nennen. Ich hebe die folgenden möglichen Ziele für Automatisierungsprojekte hervor:

1. ( , ..)
2. (, -, , ).
3. ( , , ).
4. : , .
5. , . , , «», .

Das GOST sagt auch, dass es notwendig ist, Kriterien für die Bewertung der Erreichung des Ziels bereitzustellen, dh spezifische Indikatoren. Zum Beispiel haben wir 3 Personen, die insgesamt 20 Bestellungen pro Tag abholen. Und nach der Implementierung des Systems möchten wir, dass jeder 20 Bestellungen sammelt, also dreimal mehr. Wenn solche Indikatoren dort bekannt sind, stellen wir sie in diesem Absatz vor.

6. Abschnitt 3. "Eigenschaften des Automatisierungsobjekts" / p. 2,5 GOST 34.602-89 /

Ein sehr wichtiger und oft oft formal beschriebener Abschnitt. Obwohl dies meiner Meinung nach der wichtigste Abschnitt von TK ist, verstehen wir ohne ihn einfach nicht, worüber das System erstellt wird.

Definieren wir zunächst, was ein „Automatisierungsobjekt“ ist. Wenn wir ein Lager oder eine Anlage, eine Buchhaltungsabteilung, automatisieren, ist alles klar. Und wenn wir zum Beispiel ein neues soziales Netzwerk erstellen, existiert das Objekt sozusagen nicht. Tatsächlich bedeutet ein Objekt jedoch eher automatisierte Prozesse. Und selbst im Fall eines Lagers automatisieren wir nicht das Lager selbst (wie kann die Lagerung von Kartons automatisiert werden?), Sondern Lagerprozesse.

Wenn Sie diesen Abschnitt formell ausführen, ist er der Beschreibung des Zwecks des Systems sehr ähnlich, und im TOR wird ein weiterer Wassersee angezeigt, es ist jedoch nicht klar, was das System tun soll.

Dieser Abschnitt sollte Folgendes enthalten:

1. Beschreibung des Kunden: Aktivitäten des Kunden, Anzahl der Filialen, Mitarbeiter. Natürlich müssen Sie den Kunden in dem Teil charakterisieren, der sich direkt auf das zu erstellende System bezieht.
2. Informationen zu Systembenutzern: Benutzertypen, welche Rolle das System für verschiedene Benutzer spielt.
3. Beschreibung automatisierter Objekte. Wenn wir beispielsweise ein Lager automatisieren, müssen wir beschreiben, wie viel es ist, wie viele Gehwege, welche Breite von Gehwegen, welche Gestelle, ob es einen separaten Montagebereich gibt, wie viele Personen arbeiten und welche Verantwortlichkeiten sie haben. Dann werden wir verstehen, dass wir speziell automatisieren, wie der Lagerprozess aussehen soll und welche Geräte verwendet werden.
4. Beschreibung automatisierter Prozesse. Natürlich ist es nicht notwendig, Prozesse in TK detailliert zu beschreiben. Es sind jedoch gängige Szenarien erforderlich. Erst dann wird uns klar, welche Funktionen zur Verfügung stehen sollen.
5. Eine Liste von Dokumenten, die eine detaillierte Beschreibung des Automatisierungsobjekts enthalten.

Ich hatte Fälle, in denen die Beschreibung dieses Abschnitts mehr als die Hälfte der Entwicklung von TK in Anspruch nahm, weil es lange und akribisch dauert, verschiedene Informationen zu sammeln, zu analysieren und sorgfältig zu beschreiben.

7. Abschnitt 4 „Systemanforderungen“

In TK gibt es laut GOST 34 einen gigantischen Abschnitt: Abschnitt 4 „Systemanforderungen“. Es hat drei Unterabschnitte:

• Anforderungen an das gesamte System.
• Anforderungen an die vom System ausgeführten Funktionen (Aufgaben).
• Anforderungen an Arten von Sicherheiten.

Wir werden diese Unterabschnitte separat betrachten.

7.1. Unterabschnitt 4.1. "Anforderungen an das Gesamtsystem" / p. 2.6.1 GOST 34.602-89 /

In Unterabschnitt 4.1 „Anforderungen an das Gesamtsystem“ werden die sogenannten nicht funktionalen allgemeinen Anforderungen beschrieben, die das System beschreiben, das aus verschiedenen Blickwinkeln erstellt wird.

Übrigens können, wie bereits erwähnt, Unterabschnitte hinzugefügt und weggelassen werden. Daher ist die hier angegebene Nummerierung ungefähr und dient zur Orientierung innerhalb des Artikels.

7.1.1. Abschnitt 4.1.1. "Anforderungen an die Struktur und Funktionsweise des Systems" / p. 2.6.1.1 GOST 34.602-89 /

Dieser Artikel ist ziemlich umfangreich und sollte einen allgemeinen Überblick über die Architektur des Systems geben. Wir werden diese Anforderungen genauer analysieren.

1. Die Liste der Teilsysteme, deren Zweck und Hauptmerkmale, Anforderungen an die Anzahl der Hierarchieebenen und den Grad der Zentralisierung des Systems.

In diesem Absatz zitiere ich normalerweise:

• ( , , , -, , , ) , ( , SMTP, SMS-, -, -, , , ..);
• .

Wenn Sie eine Microservice-Architektur planen, ist es sinnvoll, die Funktionalität von Services aufzulisten und zu beschreiben.

Aus Gründen der Klarheit ist es wünschenswert, ein Strukturdiagramm des Systems mit der Bezeichnung seiner Teile und verwandten Systeme beizufügen, wie in den folgenden Beispielen gezeigt.



... oder so:



2. Anforderungen an Kommunikationsmethoden und -mittel für den Informationsaustausch zwischen Systemkomponenten.

3. Anforderungen an die Merkmale der Beziehung des erstellten Systems zu verwandten Systemen, Anforderungen an seine Kompatibilität, einschließlich Anweisungen zum Austausch von Informationen (automatisch, Senden von Dokumenten, Telefon usw.)

Unter modernen Bedingungen werden die meisten Interaktionen unter Verwendung des HTTP (S) -Protokolls durchgeführt. Abgesehen davon gibt es anscheinend nichts zu schreiben. Diese Elemente können jedoch so groß sein, dass sie an die Anwendung gesendet werden. Sie sollten folgende Informationen enthalten:

• eine Liste der übertragenen Informationen, zumindest eine allgemeine Beschreibung, um allgemein zu verstehen, warum wir in ein bestimmtes System integrieren;
• Protokollbeschreibung (oder Beschreibungslinks), insbesondere im Fall von Geräteanhängen;
• lokale Netzwerkstruktur;
• erforderliche Datenrate;
• Nutzung von mobilem Internet oder WiFi;
• Beschreibung nicht automatisierter Datenübertragungsmethoden.

4. Anforderungen an die Betriebsarten des Systems.
Betriebsarten können verschiedene Klassifikationen haben:

• : , , (, , , API, );
• : , , , ;
• : 24/7 ( );
• : ;
• : , , ( );
• : -, , (, , );
• : ( ), , (, , , );
• : , « »;
• App-Sichtbarkeit: Dialog oder Hintergrund
• über die möglichen Auswirkungen auf das System: reguläre, Schulungs- und Testmodi.

5. Voraussetzungen für die Diagnose des Systems.

Anforderungen an die kontinuierliche oder regelmäßige Diagnose sollten für Systeme gestellt werden, die auf einer Mikroservice-Architektur (beabstandet) basieren, Systeme, die Geräte enthalten: Sensoren, Steuerungssysteme, Terminals usw. Wenn nur Software entwickelt wird, die auf einem einzelnen Server ausgeführt wird, sind diese Anforderungen natürlich überflüssig: Sie werden herausfinden, ob etwas nicht mehr funktioniert.

6. Perspektiven für die Entwicklung, Modernisierung des Systems.

Wie sehen die Aussichten für die Entwicklung des Systems zum Unterabschnitt „Anforderungen an die Struktur und Funktionsweise des Systems“ aus? Aber stellen Sie sich vor, Sie erstellen jetzt eine Alpha-Version für 100 Personen und möchten in einem Jahr mehr als eine Million gleichzeitig arbeitende Benutzer in verschiedenen Teilen der Welt erreichen. In der Erstellungsphase müssen Sie dann sofort eine Clusterarchitektur bereitstellen.

Oder Sie arbeiten jetzt in einer Organisation, und in sechs Monaten wird es mehrere geben, was bedeutet, dass die Möglichkeit einer Erweiterung im Voraus vorausgesehen werden muss.

Mit anderen Worten, in diesem Abschnitt können Sie alle Modernisierungsaussichten aufschreiben, insbesondere aber diejenigen, die sich definitiv auf die Architektur auswirken.

7.1.2. Abschnitt 4.1.2. "Anforderungen an die Anzahl und Qualifikation des Personals" / p. 2.6.1.2 GOST 34.602-89 /

Wie bereits erwähnt, besteht jedes automatisierte System aus „Personal und einer Reihe von Automatisierungstools für seine Aktivitäten“. Daher sind die Anforderungen an das Personal und seine Qualifikationen im TOR angegeben.

Wenn Sie eine bestimmte Produktionslinie automatisieren, kennen Sie die Anzahl der Mitarbeiter. In vielen Fällen hängt dies jedoch vom Arbeitsaufwand ab. Geben Sie daher die Positionen, den Arbeitsplan, die Beschreibung der Aktivitäten (zum Zuweisen von Zugriffsrechten) und die ungefähren Qualifikationen an. Zumindest benötigen Sie einen Systemadministrator und -betreiber, häufig einen Moderator. Möglicherweise müssen Sie mehrere Arten von Operatoren mit unterschiedlichen Zugriffsebenen bereitstellen.

Es ist klar, dass die Anforderungen an das Personal oft vom Kunden festgelegt werden. Warum bringen Sie sie dann mit? Aber erstens haben wir bereits gesagt, dass die technischen Spezifikationen für beide Seiten erstellt werden, und zweitens wird der Auftragnehmer geschützt: Die Personalauswahlbedingung ist nicht erfüllt. Was wünscht sich der Kunde dann, wenn das System nicht implementiert ist?

7.1.3. Abschnitt 4.1.3. "Anforderungen an die Leistungsindikatoren" / p. 2.6.1.3 GOST 34.602-89 /

In diesem Unterabschnitt wird oft geschrieben, was Ihnen gefällt, da die Liste der möglichen Indikatoren im GOST-Text fehlt und es fast unmöglich ist, sie in Open Source zu finden. Bitte beachten Sie, dass der in GOST angegebene „Grad der Anpassungsfähigkeit“, die „Grenzen der Modernisierung“ und die „Wahrscheinlichkeitszeitmerkmale“ zum einen für ACS (automatisiertes Steuerungssystem) angegeben sind und zum anderen nur schwer zu messen sind. Daher sind diese Eigenschaften nicht immer geeignet.

Im Text selbst werden „Ernennungsindikatoren“ jedoch als „Parameter definiert, die den Grad der Übereinstimmung des Systems mit seinem Zweck charakterisieren“. In modernen Computersystemen beziehen sich die quantitativen Werte, die dieses System charakterisieren, hauptsächlich auf die Leistung und das Datenspeichervolumen.

Zielindikatoren umfassen:

• die Anzahl der Benutzer, die gleichzeitig im System arbeiten;
• die Anzahl der gleichzeitig ausgeführten Anforderungen an den Server;
• die Anzahl der Transaktionen (aufgezeichnet) pro Zeiteinheit der Transaktionen;
• Antwortzeit für eine andere Anzahl von einmaligen Anfragen und arbeitenden Benutzern für eine andere Menge verarbeiteter Daten (insbesondere beim Suchen und Zusammenfassen von Berichten);
• Menge der gespeicherten Daten (insbesondere Bilder und Videos);
• Verbindungszeit für zusätzliche Rechenleistung bei Erreichen der maximalen Last;
• Verbindungszeit zusätzlicher Kapazitäten mit einer signifikanten Erhöhung des Volumens gespeicherter Daten.

Alle diese Merkmale wirken sich auf die Auswahl der Serverhardware, der Anwendungsserver- und DBMS-Architektur, des relationalen oder nicht relationalen DBMS, der Microservices usw. aus.

7.1.4. Abschnitt 4.1.4. "Anforderungen an die Zuverlässigkeit" / p. 2.6.1.4 GOST 34.602-89 /

Der Text von GOST beschreibt ausreichend detailliert, was in den Anforderungen an die Zuverlässigkeit angegeben werden muss. Um jedoch den Ansatz zur Gewährleistung der Zuverlässigkeit zu verstehen, der diesem Standard innewohnt, sollten Sie die GOSTs der Serie 27 studieren. Zunächst sollten Sie sich mit der Terminologie vertraut machen: Dies reicht aus, um das Konzept der Zuverlässigkeit zu verstehen, wie es gemessen wird und wie es bereitgestellt wird. Siehe daher GOST 27.002-89. „Zuverlässigkeit in der Technologie. Grundbegriffe. Begriffe und Definitionen. "

Das Grundkonzept, das auf automatisierte Systeme angewendet werden kann, ist der Verfügbarkeitsfaktor: 99%, 99,9%, 99,99%. Jede Anzahl von "Neunen" wird durch bestimmte Maßnahmen bereitgestellt.

Welche technischen Lösungen können diese Anforderungen beeinflussen? Dies ist die Anzahl der Reservekapazitäten (sie variieren) und die Verfügbarkeit von technischem Personal vor Ort sowie die Verwendung nicht nur unterbrechungsfreier Stromversorgungen, sondern auch Dieselgeneratoren sowie der Anschluss aus zwei unabhängigen Quellen (Anschluss an Stromnetze gemäß Zuverlässigkeitskategorie I oder II).

7.1.5. Abschnitt 4.1.5. "Sicherheitsanforderungen" / p. 2.6.1.5 GOST 34.602-89 /

Dieser Unterabschnitt beschreibt die Sicherheitsanforderungen für Handhabungsgeräte (Installation, Inbetriebnahme und Betrieb). Diese Anforderungen werden nun als Arbeitsschutz bezeichnet und sind in GOSTs der 12. Serie (SSBT - das System der Arbeitsschutzstandards) enthalten. In TK reicht es aus, erneut eine Liste dieser Abschnitte zu erstellen, wenn sich jemand ernsthaft mit Sicherheit befasst.

7.1.6. Abschnitt 4.1.6. "Anforderungen an Ergonomie und technische Ästhetik" / p. 2.6.1.6 GOST 34.602-89 /

Wir geben die Anforderungen von GOST an: "Die Anforderungen an Ergonomie und technische Ästhetik umfassen Wechselstromindikatoren, die die notwendige Qualität der menschlichen Interaktion mit der Maschine und den Komfort der Arbeitsbedingungen des Personals angeben."

Normalerweise wird in diesem Absatz geschrieben, dass das System eine bequeme und schöne Oberfläche haben sollte. Aber wie misst man Bequemlichkeit und Schönheit? Daher lassen wir diese Anforderung entweder weg oder sagen, dass die Benutzeroberfläche einem später entwickelten Designprojekt entspricht, oder wir stellen Standards bereit, beispielsweise die sogenannten „Richtlinien“ für die Entwicklung mobiler Anwendungen: Material Design für Android und Human Interface Guidelines für iOS.

Sie können auch die maximale Anzahl von Übergängen (Klicks) angeben, wenn Sie bestimmte Funktionen implementieren, die für uns besonders wichtig sind, die durchschnittliche Geschwindigkeit der Datensuche usw.

7.1.7. Abschnitt 4.1.7. "Transportierbarkeitsanforderungen für mobile Lautsprecher" / p. 2.6.1.7 GOST 34.602-89 /

Sagen Sie eine veraltete Anforderung. Jetzt tragen Server auf Lastwagen, wie große Computer zuvor, nicht mehr. Stellen Sie sich dennoch vor, Sie hätten eine Art Superschutz, einen internen Schaltkreis hinter der DMZ und ... die Notwendigkeit, über einen Laptop fernzuarbeiten. Ja, ein VPN ist jederzeit konfiguriert, aber es ist besser, wenn es im Administrationshandbuch wiedergegeben wird und die Möglichkeit selbst in der Netzwerkkonfiguration vorgesehen ist.

7.1.8. Abschnitt 4.1.8. "Anforderungen an Betrieb, Wartung, Reparatur und Lagerung" / p. 2.6.1.8 GOST 34.602-89 /

Diese Anforderungen beziehen sich auf die Wartung eines Komplexes technischer Mittel (Server, Firewalls, Switches, Workstations usw.). Wenn das Gerät eine spezielle Wartung erfordert, muss dies in diesem Abschnitt beschrieben werden. Sie haben beispielsweise ein spezielles Gerät, das einmal im Monat kalibriert werden muss.

7.1.9. Abschnitt 4.1.9. "Anforderungen zum Schutz von Informationen vor unbefugtem Zugriff" / p. 2.6.1.9 GOST 34.602-89 /

Das Thema des Schutzes von Informationen vor unbefugtem Zugriff ist ebenso umfangreich wie Maßnahmen, um dies sicherzustellen. Wenn wir über den Zugriff auf das persönliche Konto der Website und auf das Administrationsfenster dieser Website sprechen, gibt es natürlich genügend Anforderungen für die Autorisierung, die Komplexität des Kennworts und das Rollenzugriffsmodell. Wenn jedoch ein Finanzsystem oder ein System für staatliche Bedürfnisse geschaffen wird, treten besondere Anforderungen auf.

Es ist wichtig zu beachten, dass in diesem Unterabschnitt nicht nur die Maßnahmen aufgeführt sind, die während der Entwicklung des Systems angewendet werden müssen, sondern auch dessen Betrieb.

Für Finanzsysteme sollten Sie daher den "PCI DSS (Payment Card Industry Data Security Standard") verwenden. Für Systeme, in denen personenbezogene Daten gespeichert sind, - Dekret der Regierung der Russischen Föderation vom 01.11.2012 Nr. 1119 „Über die Genehmigung von Anforderungen zum Schutz personenbezogener Daten während ihrer Verarbeitung in Informationssystemen für personenbezogene Daten“. Möglicherweise gibt es in Ihrem Fachgebiet andere Standards.

Im Allgemeinen kann die Schutzausrüstung in die folgenden Typen unterteilt werden:

1. Mittel, die vom erstellten Softwareprodukt bereitgestellt werden.
2. Vom Systemadministrator bereitgestellte Maßnahmen.
3. Physikalische Schutzmaßnahmen.
4. Allgemeine organisatorische Maßnahmen.
5. Maßnahmen während des Softwareentwicklungsprozesses.

1. Sicherheitsmaßnahmen des erstellten Softwareprodukts:

• Kennwortanforderung für Benutzer, insbesondere für Benutzer mit Administratorrolle.
• Implementierung eines rollenbasierten Zugriffsmodells.
• Die Anforderung, elektronische Signaturschlüssel zur Durchführung kritischer Vorgänge zu verwenden.
• Entfernen von Softwarekomponenten, die für die Interaktion mit externen Systemen verantwortlich sind, in die DMZ.
• Bereitstellung der Registrierung von Ereignissen und Benutzeraktionen.

2. Vom Systemadministrator bereitgestellte Maßnahmen:

• Die Verwendung von Firewalls (Firewalls).
• Dokumentation und Überwachung der verwendeten Dienste und Protokolle.
• DMZ-Konfiguration (Demilitarized Zone).
• Überwachung der Implementierung der Regeln für die Verwendung von Laptops: Herstellen einer Verbindung zu einem internen Netzwerk mithilfe von Firewalls.
• Deaktivieren von Standardkonten vor dem Verbinden von Geräten und Systemen mit dem Netzwerk.
• Konfigurieren von drahtlosen Zugriffsgeräten: Legen Sie Kennwörter fest und ändern Sie die Standardzugriffseinstellungen.
• Installieren Sie Updates, die identifizierte Hardware- und Software-Schwachstellen beheben.
• Bereitstellung von Sicherheit für den Remotezugriff auf das System (z. B. über ein VPN).
• Installation, Aktualisierung und Überwachung von Antivirensoftware.
• Führen Sie regelmäßige Netzwerk-Scans und Scans durch, nachdem Sie wichtige Änderungen vorgenommen haben.
• Zuweisung eines eindeutigen Kontos zu jedem Mitarbeiter, regelmäßige Überprüfung auf das Vorhandensein gelöschter Konten entlassener Mitarbeiter, Änderung von Passwörtern. Ausgabe und Abrechnung von Token für elektronische Signaturen.
• Konfigurieren Sie Datenbankzugriffsbeschränkungen.
• Zeitsynchronisationssteuerung auf allen Servern und Arbeitsstationen (um die Richtigkeit der in Ereignisprotokollen aufgezeichneten Zeit sicherzustellen).
• Konfigurieren Sie Ereignisprotokolle.
• Regelmäßige Bestandsaufnahme von drahtlosen Zugangspunkten und anderer installierter Software.

3. Physikalische Schutzmaßnahmen:

• Eingeschränkter Zugang zu kritischen Räumen.
• Trennen Sie die Netzwerkanschlüsse an öffentlichen Orten.
• Installation von CCTV-Kameras für kritische Räumlichkeiten.

4. Allgemeine organisatorische Maßnahmen:

• Verabschiedung einer Sicherheitsrichtlinie und regelmäßige Schulung des Personals in Informationssicherheitsregeln.
• Implementieren Sie Verfahren zur Reaktion auf Sicherheitsvorfälle.
• Bildschirmüberprüfung oder vertrauliche Datenberichte.
• Ausstellen von Abzeichen an alle Besucher, Begleiten von Besuchern in kritischen Bereichen.
• Umfassende Überprüfung der eingestellten Mitarbeiter.
• Gewährleistung der Sicherheit von Organisationen und Anbietern von Diensten im Zusammenhang mit Software und Hardware.

5. Während des Softwareentwicklungsprozesses ergriffene Maßnahmen:

• Verantwortliche Personen kontrollieren, ob sie Änderungen am Programmcode vornehmen, den Code auf Einhaltung der Informationssicherheitsregeln überprüfen (Pufferüberlaufkontrolle, korrekte Fehlerbehandlung, Überprüfung auf Crossite-Scripting, Zugriffsmechanismusfehler usw.).
• Die Verwendung starker Kryptographie.
• Anwendung von Sicherheitsregeln für öffentliche Webanwendungen.
• Entwickeln Sie für jede Änderung ein Stornierungsverfahren.
• Dokumentation von Änderungen.

7.1.10. Abschnitt 4.1.10. "Anforderungen an die Informationssicherheit bei Unfällen" / p. 2.6.1.10 GOST 34.602-89 /

Dieser Abschnitt enthält eine Liste möglicher Unfälle und Ausfälle, bei denen die Sicherheit von Informationen gewährleistet werden sollte. Solche Ereignisse können umfassen:

• Verlust der Ernährung;
• Serverausfall;
• Ausfall des Speichergeräts (Festplatte).

7.1.11. Abschnitt 4.1.11. "Anforderungen an den Schutz gegen den Einfluss äußerer Einflüsse" / p. 2.6.1.11 GOST 34.602-89 /

Dieser Abschnitt ist nützlich bei Servern, Arbeitsstationen und anderen Geräten in einem Kühlhaus oder umgekehrt in Industrieräumen mit erhöhten Temperaturen, an staubigen Orten oder an Orten mit hoher Luftfeuchtigkeit. Manchmal lohnt es sich auch, Vibrationen, Strahlung oder andere Einflüsse zu berücksichtigen.

7.1.12. Unterabschnitt 4.1.12. "Anforderungen an die Patentreinheit" / p. 2.6.1.12 GOST 34.602-89 /

Wenn Sie den Verdacht haben, dass Sie eine in anderen Ländern (oder in unserem Land) patentierte Technologie verwenden und der Patentinhaber möglicherweise eine Klage gegen den Eigentümer des Systems einreicht, enthält dieser Absatz die Liste der Länder, in denen Sie prüfen möchten für Patentreinheit.

7.1.13. Abschnitt 4.1.13. "Anforderungen an die Standardisierung und Vereinheitlichung" / p. 2.6.1.13 GOST 34.602-89 /

Dieser Artikel ist auch selten in den Nutzungsbedingungen in Bezug auf Software enthalten. Es zeigt sowohl die Anforderungen für den Einsatz spezifischer Technologien als auch standardisierte Formen von Dokumenten und Klassifikatoren an.

Diese Beschreibung ist besonders wichtig, wenn Sie spezielle Anforderungen an die verwendeten Frameworks, Plugins, Protokolle, Geräte, mathematischen Algorithmen, Software von Drittanbietern usw. haben. Vergessen Sie nicht anzugeben, in welchem ​​Teil und zu welchem ​​Zweck diese Tools verwendet werden sollen.

Manchmal ist es in Systemen einiger Klassen auch üblich, bestimmte Datenaustauschprotokolle zu verwenden. Beispielsweise werden OCG-Standards verwendet, um Daten zwischen geografischen Informationssystemen auszutauschen, und OCPP wird verwendet, um Ladestationen für Elektrofahrzeuge zu steuern.

7.1.14. Abschnitt 4.1.14. "Zusätzliche Anforderungen" / p. 2.6.1.14 GOST 34.602-89 /

Dieser Absatz sollte im Text von GOST enthalten sein. Er braucht keine Kommentare.

7.2. Unterabschnitt 4.2. "Anforderungen an die vom System ausgeführten Funktionen (Aufgaben)" / p. 2.6.2 GOST 34.602-89 /

Dieser Abschnitt ist von zentraler Bedeutung für moderne Computersysteme. Tatsächlich ist das System für die Ausführung bestimmter Funktionen erstellt. Häufig enthält TK, das auf der Grundlage ausländischer Standards und im Allgemeinen ohne Standards erstellt wurde, nur diesen Abschnitt.

7.2.1. Funktionsbeschreibung Struktur

Zunächst betrachten wir die Struktur der funktionalen Anforderungen an das System: Subsystem - Funktionssatz - Funktion - Aufgabe. Eine Aufgabe ist Teil einer Funktion, und die Aufgabe kann als separate Funktion beschrieben werden. Für die Anmeldefunktion führen wir beispielsweise ein Kennwort als eine der Aufgaben ein. Und wir können das Verfahren zur Passworteingabe als separate Funktion beschreiben: Überprüfung der Richtigkeit, Wiederherstellung des Passworts, Anzeige von Eingabeaufforderungen usw. Ein Komplex vereint Funktionen. Zum Beispiel "Grundlegende Informationen berücksichtigen", "Auktion abhalten" usw. Der Komplex hat zwei oder mehr Funktionen.

Wenn Ihr System aus mehreren Subsystemen besteht, sollte TK grundsätzlich eine Liste von Funktionen für Subsysteme bereitstellen und die funktionalen Anforderungen für Subsysteme in einzelnen TK für Subsysteme bereits detailliert beschreiben (sie werden jetzt häufig als CTZ bezeichnet - eine private technische Aufgabe).

7.2.2. Arten von Funktionen in Bezug auf ihre Implementierung

Tatsächlich können alle Funktionen (oder ihre Aufgaben; mehrere Aufgaben können gleichzeitig in einer Funktion vorhanden sein) in die folgenden Typen unterteilt werden:

• Informationen eingeben. Manchmal auch als "Buchhaltungsinformationen" bezeichnet.
• Informationsausgabe.
• Automatische Verarbeitung von Informationen.

7.2.3. Arten von Funktionen in Bezug auf ihre Rolle

Funktionen können allgemein und speziell sein. Zu den allgemeinen Funktionen gehören beispielsweise das Arbeiten mit Objektlisten, das Arbeiten mit einer Objektkarte und das Arbeiten mit einer interaktiven Karte. Diese Funktionen können für alle Sonderfunktionen oder Teile von Sonderfunktionen gelten.

7.2.4. Voraussetzung, kein Skript

Vergessen Sie nicht, dass der ToR Anforderungen an das System und den Prozess seiner Erstellung enthält. Keine Skripte. TK beantwortet die Frage, WAS das System tun soll. Auf die Frage, wie das technische Design antwortet. Wenn Sie anfangen, die technische Implementierung detailliert zu beschreiben, tauchen Sie in die Details ein und geben Sie keine vollständige Liste der Anforderungen an: Unser Gehirn kann nicht gleichzeitig in Modi mit umfassender Abdeckung und Berücksichtigung von Details arbeiten.

Die Struktur der Funktionen des TOR und des technischen Projekts kann sehr unterschiedlich sein: In einem Szenario können mehrere Funktionen implementiert werden und umgekehrt.

7.2.5. Funktionale Anforderungen

Hier einige Empfehlungen zum Erstellen einer Funktionsbeschreibung:

1. Anforderungen an Funktionen und Aufgaben sollten normalerweise an die Anwendung gestellt werden. Somit ist das Dokument organisch in nicht funktionale und funktionale Teile unterteilt. Darüber hinaus kann die Anwendung immer separat gedruckt und angezeigt werden.
2. Vermeiden Sie große Absätze. Es ist am besten, wenn die Anforderungen in Absätze und Unterabsätze unterteilt sind: Es ist einfacher, sie wahrzunehmen und ihre Implementierung zu steuern (aktivieren Sie die Kontrollkästchen). Wenn eine Liste mit Anforderungen oder Informationen bereitgestellt wird, lassen Sie diese durch eine nummerierte Liste oder eine Liste mit Aufzählungszeichen angeben.
3. Für Funktionen, deren Zweck aus ihrem Namen nicht ersichtlich ist, müssen der Zweck und das zu lösende Problem angegeben werden. Andernfalls riskiert sogar der TK-Compiler zu vergessen, warum er diese oder jene Funktionalität beschrieben hat.

7.2.6. Funktionsbeschreibung Beispiel

5.6. Registrierung eines Fahrzeugs im System

Folgende Anforderungen werden vorgestellt:

1) Das System sollte die folgenden allgemeinen Informationen berücksichtigen:

• staatliches Kennzeichen (GRNZ);
• Name des Eigentümers;
• Eigentümeradresse;
• Daten vom Fahrzeugdatenerfassungsdienst (siehe Abschnitt 3.3, Anhang B);
• Hinweis.

2) Das System sollte die Berücksichtigung der folgenden Informationen im Zusammenhang mit der Tarifzahlung ermöglichen (die angegebenen Informationen sind informativer Natur, die Möglichkeit, sie direkt in der Fahrzeugkarte zu ändern, ist nicht erforderlich):

• aktuelle Fahrzeugklasse (siehe Abschnitt 3.3, Anhang A);
• aktueller Tarif (siehe Abschnitt 5.1, Anhang A);
• aktueller Vertrag (siehe Abschnitt 5.5, Anhang A);
• Fahrzeugklasse nach Angaben des Innenministeriums der Republik Kasachstan;
• Informationen über das persönliche Konto und seinen Zustand (siehe Abschnitt 3.6, Anhang A);
• Informationen zur Eintragung in das Fahrzeugregister mit ermäßigtem Fahrpreis (siehe Abschnitt 3.5, Anhang A).

3) Das System sollte es ermöglichen, Informationen über das Fahrzeug auf folgende Weise zu registrieren und zu ändern:

• manuell vom Bediener;
• nach Erhalt von Informationen aus dem Registrierungssystem für RFID-Tags (siehe Abschnitt 1.1, Anhang B);
• bei der Identifizierung des Fahrzeugs mit der Kamera GRNZ.

4) Bei der Registrierung eines neuen Fahrzeugs im System muss das System vom Dienst Daten über das Fahrzeug anfordern, um Daten über das Fahrzeug zu erhalten (siehe Abschnitt 3.3, Anhang B). Es sollte möglich sein, die angegebenen Informationen eines einzelnen Fahrzeugs zu aktualisieren.

7.3. Unterabschnitt 4.3. "Anforderungen an Sicherheitsarten" / p. 2.6.3 GOST 34.602-89 /

Der Abschnitt der Anforderungen für Unterstützungsarten wird im Allgemeinen häufig als Beispiel für das überschüssige Volumen von TK gemäß GOST angeführt. Wenn es darum geht, ob alle Abschnitte und Unterabschnitte angegeben werden sollen, erinnern sie sich an die Software, für die es in den meisten Fällen einfach nichts zu schreiben gibt.

In der Tat ist dies ein sehr wichtiger Unterabschnitt, obwohl nicht jeder seinen Zweck versteht. Es beschreibt die Bedingungen, ohne die eine Entwicklung oder Inbetriebnahme nicht möglich ist. Diese Bedingungen werden als „Sicherheiten“ bezeichnet.

Wenn man diesen Unterabschnitt liest, fragt man sich, was die Verfasser des Standards unter "Software", "Sprachsoftware", "Informationssoftware" usw. verstehen. Antworten sollten in GOST 34.003-90 gesucht werden, wo alle diese Begriffe entschlüsselt werden.

7.3.1. Abschnitt 4.3.1 "Software" / S. 2.6.3.1 GOST 34.602-89 /

Stellen Sie sich die Situation vor, in der Sie ein System erstellen müssen, in dem Sie die automatische Berechnung der optimalen Route implementieren möchten. Die Schaltfläche „Route berechnen“ mag einfach aussehen, aber dahinter können sehr komplexe mathematische Algorithmen und Berechnungen stehen. Es ist klar, dass es sich nicht lohnt, solche Algorithmen zu entwickeln, da sich professionelle Mathematiker damit beschäftigen. Wenn solche Algorithmen verfügbar sind, werden auch die Anforderungen für ihre Entwicklung oder die Verwendung von vorgefertigten Algorithmen geschrieben.

7.3.2. Abschnitt 4.3.2 „Informationsunterstützung“ / S. 2.6.3.2 GOST 34.602-89 /

Beim Lesen der Beschreibung dieser Anforderung im GOST-Text scheint dies eine Wiederholung dessen zu sein, was in anderen Abschnitten gesagt wurde. Warum zum Beispiel noch einmal die Anforderungen an „Zusammensetzung, Struktur und Methoden zur Organisation von Daten im System“ und „Informationsaustausch zwischen Systemkomponenten“ beschreiben? Wir vergessen jedoch erneut, dass die Compiler von GOST unter dem System nicht nur über Software verfügten, sondern auch über alle organisatorischen Maßnahmen.

Wenn Sie sich vorstellen, stoßen Sie auf eine solche Situation, dass der Kunde seinerseits keinen Bediener angegeben hat, der Daten in das System eingibt, und gleichzeitig angibt, dass das System nicht funktioniert. Eine vertraute Situation? Wenn jedoch die Anforderung, diese Eingabe bereitzustellen, in der Leistungsbeschreibung dargelegt würde, wäre es möglich, den Kunden an dieser Stelle direkt anzutreiben. Oder Sie benötigen Zugriff auf einen bestimmten Adressklassifizierer für die Arbeit, der Kunde gibt ihn Ihnen jedoch nicht.

Daher ist es in diesem Absatz sinnvoll, die Anforderungen für eingehende Informationen und Informationen, die von Komponente zu Komponente des Systems übertragen werden, nicht automatisiert anzugeben. Die automatisierte Informationsverarbeitung, die Verwendung von DBMS und der Informationsaustausch innerhalb des Systems werden in anderen Abschnitten ausführlich beschrieben.

7.3.3. Abschnitt 4.3.3 „Sprachliche Unterstützung“ / S. 2.6.3.3 GOST 34.602-89 /

Dieser Absatz enthält:

• Anforderungen für die Verwendung von Programmiersprachen (sofern bestimmte Präferenzen bestehen);
• Schnittstellensprache (welche Sprachen, mehrsprachige Schnittstelle);
• Sprache für die Kommunikation zwischen Projektteams, Übersetzungsanforderungen;
• andere Merkmale der Dateneingabe und -ausgabe, falls verfügbar: Verschlüsselung, nicht standardmäßige Methoden der Benutzerinteraktion mit dem System.

7.3.4. Abschnitt 4.3.4 "Software" / S. 2.6.3.4 GOST 34.602-89 /

Dieser Absatz enthält eine Liste der gekauften Software, sofern diese in der Entwicklungsphase des ToR identifiziert wurden.

7.3.5. Abschnitt 4.3.5 "Technischer Support" / S. 2.6.3.5 GOST 34.602-89 /

Jedes Informationssystem kann ohne Hardware, Server, Netzwerke usw. nicht funktionieren. Die Bestimmung der spezifischen Eigenschaften von Geräten ist normalerweise ratsam, um sie in ein technisches Design einzubeziehen. In der Leistungsbeschreibung kann jedoch eine ungefähre Zusammensetzung angegeben werden, damit der Kunde eine Vorstellung von den zukünftigen Kosten hat.

7.3.6. Abschnitt 4.3.6 "Metrologische Unterstützung" / p. 2.6.3.6 GOST 34.602-89 /

Wenn Daten von Sensoren im System empfangen werden sollen, muss bekannt sein, welche Messinstrumente verwendet werden, welche Genauigkeitsmessgeräte bereitgestellt werden sollten und ob diese Werkzeuge zertifiziert und zertifiziert werden sollten.

7.3.7. Abschnitt 4.3.7 "Organisatorische Unterstützung" / p. 2.6.3.7 GOST 34.602-89 /

Stellen Sie sich vor, Sie erstellen ein System von Grund auf neu. Dies ist beispielsweise ein Lagerverwaltungssystem für einen neuen Logistikkomplex. Mit anderen Worten, es gibt nur Wände. Oder Sie aktualisieren das System und um die Änderungen zu implementieren, müssen Sie die Organisationsstruktur ändern. In solchen Fällen sollten Sie die Bedingungen für die Organisation der Prozesse angeben, unter denen das von Ihnen bereitgestellte System tatsächlich funktioniert.

7.3.8. Abschnitt 4.3.8 "Methodische Unterstützung" / p. 2.6.3.8 GOST 34.602-89 /

Manchmal ist zur Verwaltung des Systems Personal mit besonderen Kompetenzen erforderlich. In diesem Fall sollte im TOR eine Liste von Methoden, Normen und Standards angegeben werden, mit denen die mit dem System interagierenden Mitarbeiter vertraut gemacht werden sollten.

7.3.9. Andere Arten von Sicherheiten

Bei der Entwicklung jedes neuen TK sollten Sie berücksichtigen, was Sie für eine erfolgreiche Inbetriebnahme benötigen. Zum Beispiel schreibe ich häufig Anforderungen für die rechtliche Unterstützung auf, wenn der verwendete Rechtsrahmen nicht vollständig definiert ist und seine Entwicklung die Implementierung beeinflussen kann. Obwohl solche Probleme am besten vor der Ausarbeitung der Leistungsbeschreibung gelöst werden können .

8. Abschnitt 5 „Zusammensetzung und Inhalt der Arbeiten zur Schaffung (Entwicklung) des Systems“ / p. 2,7 GOST 34,602-89 /

Dieser Abschnitt ist organisatorisch und wird häufig in den Vertrag aufgenommen. Diese Informationen im ToR können jedoch angegeben werden.

Im Wesentlichen ist dies ein kurzer Plan für die Entwicklung und Implementierung. Beim Kompilieren gebe ich normalerweise eine Tabelle an, in der alle oder einige der folgenden Spalten aufgelistet sind:

• Der Name der Stufe (Teilstufe).
• Arbeitsinhalt (Kurzbeschreibung, Aufgabenliste).
• Das Ergebnis der Arbeit (genehmigte Dokumente, entwickelte und eingereichte Lösungen).
• Design-, Arbeits- oder Berichtsdokumentation.
• Verantwortlich (wer führt diese Arbeit aus: Kunde, Auftragnehmer oder andere Person). Wenn beide Parteien ein gemeinsames Ergebnis liefern müssen, werden die Rollen angegeben.
• Dauer (Daten, Daten, Beginn des Timings).

Ein Beispiel für den Inhalt dieses Abschnitts finden Sie in der folgenden Tabelle.

9. Abschnitt 6 „Verfahren zur Überwachung und Abnahme des Systems“ / S. 2,8 GOST 34,602-89 /

In diesem Abschnitt wird der Prozess der Akzeptanz des Systems durch den Kunden ausführlich beschrieben: Welche Tests sollten durchgeführt werden, was wird in diesen Tests enthalten sein, welche Dokumente werden getestet, wie werden Kommentare erstellt und beseitigt.

9.1. Unterabschnitt 6.1. "Typen, Zusammensetzung, Volumen und Testmethoden des Systems und seiner Komponenten" / p. 2.8.1 GOST 34.602-89 /

Normalerweise gebe ich hier die Liste der Tests an und erwähne, dass die Testmethoden im Dokument "Testprogramm und Methodik" angegeben werden, das eine Beschreibung der wichtigsten Testfälle und Testskripte ist.

Lassen Sie uns auf die Arten von Tests eingehen. Arten von Tests, ihre Zusammensetzung und Anforderungen an Dokumente werden in GOST 34.603-92 „Informationstechnologie. Arten von Tests automatisierter Systeme. " Verweisen Sie daher bei der Entwicklung dieses Abschnitts und des technischen Projekts unbedingt auf diesen Standard. Hier werden nur die wichtigsten Punkte erläutert.

Versuchen wir zu verstehen, welche Art von Tests sind:

1. Die Tests sind in die folgenden Typen unterteilt:

• Vorläufig.
• Probebetrieb.
• Akzeptanz.

2. Vorläufige (und teilweise akzeptierte) Tests sind wiederum unterteilt in:

• ( ).
• ( ).

Warum sind Tests in verschiedene Phasen unterteilt? Erstens kann ein Teil der Tests ohne Kunden durchgeführt werden, da GOST 34.603-92 nicht zwischen interner und externer Akzeptanz unterscheidet. Zweitens wird ein sequentieller Testprozess Teil für Teil beschrieben, und dann wird alles integriert.

Versuchen wir, den Testprozess in einfachen Worten zu beschreiben:

1. Vorläufige autonome Tests von Teilen des Systems. Teile des Systems werden einzeln getestet, wenn die Zusammensetzung mehrere Subsysteme oder große Module enthält. Typischerweise werden solche Tests autonom durchgeführt, dh ohne Integration in benachbarte Systeme. Wenn das System einfach ist, kann dieser Schritt sicher übersprungen werden.

2. Vorläufige autonome Tests des gesamten Systems.Das gesamte System wird in einem Komplex in einem autonomen Modus getestet, dh ohne Integration in benachbarte Systeme. Mit benachbarten Systemen verknüpfte Funktionen werden nicht getestet. Im Extremfall werden „Stubs“ gesetzt (Emulation der Integration) oder die Datenbank wird mit Daten gefüllt, die aus externen Quellen stammen müssen.

3. Vorläufige umfassende Tests. Das System wird auf integrierte Weise getestet, dh in Interaktion mit benachbarten Systemen. In dieser Form wird das System zum Testbetrieb an den Kunden übertragen.

4. Pilotbetrieb.MA kann in verschiedenen Modi stattfinden. Das Beste ist die Nutzung realer Daten, mit echten Benutzern und mit echten Aufgaben. Nur diese Art von Test stellt sicher, dass das System wirklich betriebsbereit ist. Während des Probebetriebs werden die Nachteile beseitigt.

5. Abnahmetests. Dies ist die letzte Art der Überprüfung. Sagen Sie mir, warum wird der Testbetrieb nach Beseitigung aller Mängel nicht reibungslos in die Industrie gehen? So passiert es normalerweise. Aber hohe Onkel müssen sehen, dass das System wirklich funktioniert, um es zu "fühlen". Abnahmetests sind für sie bestimmt, für eine hohe Provision. Abnahmetests unterscheiden sich daher von Vorversuchen vor allem im Status der Kommission.

Auch in diesem Absatz werden Dokumente angegeben, in denen Testmethoden angegeben werden:

• « () ». . — 34.603-92 (. 2.2.2 4.1) — 50-34.698-90 « . . . . ».
• « », . 3.1 34.003-90. « » (. . 3.2 34.603-92), .

9.2. Unterabschnitt 6.2. "Allgemeine Anforderungen für die schrittweise Abnahme von Arbeiten" / p. 2.8.2 GOST 34.602-89 /

In diesem Abschnitt gebe ich normalerweise Folgendes an:

1. Auf wessen Gebiet und auf wessen Ausrüstung werden die Tests durchgeführt: der Kunde oder der Auftragnehmer.
2. Eine allgemeine Beschreibung der Durchführung der Tests (z. B. Überprüfung der Dokumente, Vorhandensein von Elementen der Benutzeroberfläche, Ausarbeitung von Skripten).
3. Teilnehmerliste.
4. Die Liste der Dokumente, aus denen das Testergebnis besteht:
   
   
   • Für Vor- und Abnahmetests ist dies ein Testbericht, der eine Liste der Prüfungen und ihrer Ergebnisse enthält.
   • Für den Testbetrieb - ein Testbetriebsjournal.

10. Abschnitt 7 „Anforderungen an die Zusammensetzung und den Inhalt der Arbeiten zur Vorbereitung des Automatisierungsobjekts für die Inbetriebnahme des Systems“ / S. 2,9 GOST 34,602-89 /

Der in diesem Abschnitt beschriebene Prozess wird häufig als Implementierung bezeichnet. Bitte beachten Sie, dass diese Arbeiten auch in Abschnitt 5 „Zusammensetzung und Inhalt der Arbeiten zur Erstellung (Entwicklung) des Systems“ aufgeführt sind . In Abschnitt 5 werden sie jedoch nur kurz erwähnt, und hier wird eine detaillierte Beschreibung gegeben.

Bei der Vorbereitung eines Objekts sind in der Regel folgende Arbeiten durchzuführen:

1. Reorganisation, ggf. Einstellung neuer Mitarbeiter.
2. Mitarbeiterschulung.
3. Für Webanwendungen: Entwicklung gemeinsamer Abschnitte der Website und Nutzungsvereinbarung (Zustimmung zur Verarbeitung personenbezogener Daten).
4. Füllen von Verzeichnissen und anderen Hintergrundinformationen.
5. Übertragen Sie Daten vom alten System.
6. Stellen Sie das System auf Industrieservern bereit.
7. Konfigurieren Sie die Integration mit benachbarten Systemen.
8. Einrichten eines Zugriffssystems und Erstellen von Konten.

Einige dieser Punkte sollten ausführlich beschrieben werden, insbesondere im Hinblick auf die Datenübertragung und das Ausfüllen von Verzeichnissen.

11. Abschnitt 8 „Dokumentationsanforderungen“ / S. 2.10 GOST 34.602-89 /

Nicht wert, bezieht sich auf die Dokumente formal. Dokumente - das ist Projektmanagement, Projektworkflow. Sie werden nicht alles im Kopf behalten, und der Erfolg des Projekts hängt von der Verfügbarkeit und Qualität der Dokumente ab. Natürlich gibt es Dokumente "nach Gewicht", und sie sollten entsprechend behandelt werden, aber ohne ein Dokument in einem ruhigen und geordneten Modus kann das Projekt nicht umgesetzt werden.

Die Dokumentation des Automatisierungsprojekts gemäß GOST 34 wird durch folgende Normen geregelt:

• GOST 34.201-89 Arten, Vollständigkeit und Bezeichnung von Dokumenten bei der Erstellung automatisierter Systeme.
• RD 50-34.698-90 Richtlinien. Informationstechnologie. Eine Reihe von Standards und Richtlinien für automatisierte Systeme. Automatisierte Systeme. Anforderungen an den Inhalt von Dokumenten.
• Für die Leistungsbeschreibung - GOST 34.602-89, die wir jetzt diskutieren.

Der erste Standard (GOST 34.201-89) enthält eine Liste und Struktur der Dokumentation. In der zweiten - RD 50-34.698-90 - wird der Inhalt der folgenden Dokumente angegeben:

• Dokumente von Vorentwürfen und technischen Projekten.
• Dokumente, die in der Vorentwurfsphase entwickelt wurden.
• Organisations- und Verwaltungsdokumente (Gesetze, Protokolle usw.)

11.1 Merkmale der Dokumentationsstruktur

Beim Zusammenstellen einer Liste der erforderlichen Dokumente sehen sie sich normalerweise RD 50-34.698-90 an und wählen die erforderlichen aus. Gleichzeitig werden viele Fehler gemacht, da die Dokumentation eine ziemlich komplizierte Struktur aufweist, die in GOST 34.201-89 beschrieben ist.

Versuchen wir, einige Regeln zu identifizieren, die beim Zusammenstellen einer Liste von Dokumenten hilfreich sind.

1. Jede Phase verfügt über eine eigene Dokumentation.

Jede Phase verfügt über eine eigene Dokumentation. Das ist sehr wichtig zu verstehen. Es ist nicht erforderlich, die Entwicklung von Betriebsdokumenten in der Entwurfsphase vorzuschreiben und umgekehrt. Es stellt sich als rein formelles Papier heraus, für das Sie viel Zeit aufwenden werden. Und wenn das „Benutzerhandbuch“ bis zum Ende der Systementwicklung normalerweise niemand erfindet (obwohl ich solche Zahlen getroffen habe), wird die „Beschreibung der automatisierten Funktionen“, in der normalerweise Skripte für Programmierer angegeben sind, nach Abschluss der Entwicklung ständig erstellt. Beim Lesen von RD 50-34.698-90 kann der Eindruck entstehen, dass einige Dokumente überlappende Inhalte haben. Dies liegt auch daran, dass die Dokumente für verschiedene Phasen vorgesehen sind.

Da einige Dokumente entweder in der einen oder in einer anderen Phase entwickelt werden können, bietet GOST 34.201-89, um Wiederholungen zu vermeiden, beispielsweise eine Liste von Dokumenten, die sowohl in der Phase eines technischen Entwurfs und einer Arbeitsdokumentation ausgestellt werden können, als auch separat eine Liste von Dokumenten für jede dieser Stufen separat. Wenn Sie eine Liste von Dokumenten für eine der Phasen erstellen, müssen Sie daher die Dokumentenlisten in mehreren Abschnitten des Standards durchsehen.

Um nicht verwirrt zu werden, habe ich eine Excel-Tabelle zusammengestellt, in der Sie mithilfe von Filtern sofort eine vollständige Liste der Dokumente für eine bestimmte Phase anzeigen können.

2. Dokumente sind in Themen unterteilt (Teile des Projekts).

34 , , , , , , ( ). 50-34.698-90 (). , .

3. .

GOST 34.201-89 gibt direkt an, in welchen Fällen ein Dokument in einem anderen enthalten ist. Dies geschieht so, dass keine entarteten Dokumente mit ein oder zwei Seiten mehr vorhanden sind. Wenn etwas beschrieben werden muss, das Volumen jedoch sehr klein ist, ist es am besten, den Text in ein anderes Dokument aufzunehmen. In den meisten Fällen gibt es ein Dokument wie „Erläuterung zum technischen Entwurf“, in dem Sie Abschnitte hinzufügen können.

4. Betriebs- und Entwurfsschätzungen werden getrennt hervorgehoben.

Die Compiler von GOST 34.201-89 in separaten Spalten der Tabelle mit einer Liste der angegebenen Dokumente, die zu den Betriebs- und Entwurfsschätzungen gehören.

Die Entwurfsschätzungen umfassen Dokumente für Bau- und Elektroarbeiten: Schätzungen, Beschaffungspläne, Zeichnungen und elektrische Diagramme.

Die Betriebsdokumente enthalten die Dokumente, die die Verwendung und Wartung des Systems leiten: Handbücher und Anweisungen, Listen mit Materialien und Daten, Dokumente, die Informationen zu Verstößen während des Betriebs enthalten.

11.2 Merkmale der Gestaltung der Dokumentenliste

Wie Sie bereits erwähnt haben, wird bei der Beschreibung der Arbeitsschritte in Abschnitt 5, „Zusammensetzung und Inhalt der Arbeit zur Erstellung (Entwicklung) eines Systems“ , auch eine Liste mit Dokumentationen bereitgestellt. Eine doppelte Liste von Dokumenten wird aus einem einfachen Grund bereitgestellt: Es reicht nicht aus, den Namen des Dokuments anzugeben, es ist dennoch erforderlich, seinen Zweck zu erläutern und eine kurze Zusammenfassung bereitzustellen (für das „Benutzerhandbuch“ ist es natürlich nicht sinnvoll, den Inhalt anzugeben). Andernfalls kann nicht festgestellt werden, welche Bedeutung ein bestimmtes Dokument für das Projektmanagement hat. GOST ist ein Gast, und bei jedem Projekt können Inhalt und Rolle der Dokumente unterschiedlich sein. Darüber hinaus kann die Liste Dokumente enthalten, die nicht durch GOST 34 geregelt sind und die unbedingt geklärt werden müssen.

In Dokumentationsregeln gebe ich normalerweise eine Tabelle mit den folgenden Spalten an:

• Bühne.
• Der Name des Dokuments.
• Hinweis: Gibt den Entwicklungsstandard, den Zweck, die Zusammenfassung und die Hauptmerkmale des Dokuments an.

11.3 Beispielliste der Dokumentation

Damit ein großes Projekt ein komplexes System implementieren kann, ist möglicherweise eine ziemlich große Liste von Dokumentationen erforderlich. Ein Beispiel für eine solche Liste finden Sie in der folgenden Tabelle.

12. Abschnitt 9 "Quellen der Entwicklung" / p. 2.11 GOST 34.602-89 /

Es scheint ein formeller Abschnitt zu sein, aber sehr nützlich. Stellen Sie sich eine Situation vor, in der Sie sich daran erinnern, dass Sie während der Entwicklung von TK einen Artikel gelesen haben und ihn aus irgendeinem Grund finden müssen, um beispielsweise etwas zu klären oder Ihre Entscheidungen zu rechtfertigen. Aber Sie erinnern sich weder an den Namen noch an den Ort, an dem er enthalten war. Wenn ich nützliche Materialien verwende, stellen Sie diese daher unbedingt auf die Liste. Und in den Text habe ich eine Fußnote eingefügt, in der die Quelle angegeben ist.

Wenn es viele Quellen gibt, sollten sie in Unterabschnitte unterteilt werden, zum Beispiel:

• Materialien, die Analoga (Prototypen) des entwickelten Systems beschreiben.
• Materialien, die die allgemeine Idee des Systems beschreiben. Häufig werden diese Dokumente in der Vorentwurfsphase erstellt, und auf diese wird normalerweise im Abschnitt „Merkmale des Automatisierungsobjekts“ verwiesen.
• Projektentwicklungsmaterialien: Liste der verwendeten GOSTs der Serie 34, verwendete Standards für das Projektmanagement.
• Materialien zur Implementierung des Hauptprozesses: Eine Liste von Gesetzen, Standards, internen Vorschriften und Anordnungen, die die Regeln für die Implementierung automatisierter Prozesse festlegen.
• Materialien und Standards, die Anforderungen an die allgemeine Sicherheit und Informationssicherheit enthalten.

Fazit

Natürlich kann die Erstellung der Leistungsbeschreibung gemäß GOST 34 nicht als einfach bezeichnet werden. Und nicht, weil GOST schlecht ist, sondern weil GOST Sie nur dazu bringt, das ganze Projekt durchzudenken und all die kleinen Dinge zu malen. Ein gut geschriebener TOR ist jedoch der halbe Erfolg des Projekts.

Schreiben Sie in die Kommentare, wenn Sie es für notwendig halten, etwas zu klären oder zu ergänzen. Stellen Sie sicher, dass Sie Änderungen am Artikel vornehmen.

Lesen Sie weitere Artikel des Autors:

• Pre-Design-Umfrage bei der Entwicklung eines Informationssystems.
• Geheimnisse des erfolgreichen Entwurfs von IP (Informationssystem) am Beispiel des Baus eines Krankenhauses.
• Einige Hinweise zum Aufbau von Informationssystemen.