Warum genau das Krankenhaus?

Warum nicht? Dies ist ein gutes Beispiel. Das Projekt ist überall ein Projekt: plus oder minus dieselben Phasen, dasselbe Verwaltungsschema, Dokumentenmanagement, Risikomanagement, Qualitätskontrolle und so weiter. Überall gibt es Anforderungen an Geräte, Räumlichkeiten und Software. Sie fragen, was können die Anforderungen für Räumlichkeiten im Informationssystem sein? Es ist ganz einfach: Der Standort der Arbeitsstationen des Bedieners und des Servers - beide erfordern eine Klimaanlage. Hier sind die Anforderungen für die Räumlichkeiten. Und kaum jemand zweifelt jetzt daran, ob das Krankenhaus Software benötigt. Wenn Sie auf dem Laufenden bleiben möchten, stehen Sie vor der Aufgabe, eine automatisierte medizinische Einrichtung mit elektronischen Patientenakten einzurichten, in der Ärzte eine Untersuchung mit Tabletten durchführen und beispielsweise Krankenschwestern die gewaschene Toilette nicht auf dem Laken, sondern am Telefon markieren. In diesem Fall gibt es viele Softwareanforderungen. Sobald Software benötigt wird, muss der Server installiert, der Administrator und die Bediener irgendwo platziert werden. Alles ist miteinander verbunden.

Wir haben uns für ein Bauprojekt entschieden, weil es am einfachsten ist, darauf zu demonstrieren, wie ein IP entworfen wird. Das Informationssystem ist irgendwo im Inneren versteckt, wir sehen es nicht und die Wände sind hier vor uns: gebogen und schräg, mit Sackgassen, weil das Projekt am Knie durchgeführt wurde und sogar der Kunde seine Anforderungen während des Spiels hundertmal geändert hat.

Programmcode im Inneren (aber niemand sieht das)

Was hat ein Krankenhaus damit zu tun, wenn wir Software entwickeln?

Und hier ist es, liebe Entwickler, Führungskräfte, Analysten, Tester.

Nicht die Software, die Sie entwickeln ... Nehmen Sie Android, das ist Software. Und wenn Sie zum Beispiel ein Buchhaltungssystem haben, dann haben Sie es bereits nicht nur mit Software zu tun, sondern auch mit einem INFORMATIONSSYSTEM.

Der Unterschied ist offensichtlich. Wenn Sie ein Telefon gekauft haben, ist alles einfach: Schalten Sie es ein, ein grüner Mann (Android) startet, verwenden Sie es. Wenn Sie eine Box mit Buchhaltungssoftware gekauft haben, ist klar, dass Sie jetzt Server benötigen, das Netzwerk konfigurieren, Workstations konfigurieren, Mitarbeiter schulen, das System in andere Unternehmens-IPs integrieren und das System im Testmodus betreiben müssen. Ja, und Buchhalter müssen irgendwie überredet werden, auf die neue Software umzusteigen. Nicht alle von ihnen sind bereit für Innovationen. Im Allgemeinen sind in jedem IT-Projekt 10 bis 20% IT, und alles andere sind organisatorische und administrative Maßnahmen. Nun, sehr dicht, Schmuck, Arbeit mit Mitarbeitern.

Informationssystem (ist es nur Software?)

Und schließlich erinnern wir uns an die Definition eines Systems aus den fernen 90er Jahren, die niemand aufgehoben hat:

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.

GOST 34.003-90. Informationstechnologie. Eine Reihe von Standards für automatisierte Systeme. Automatisierte Systeme. Begriffe und Definitionen.

Das heißt, IP besteht in erster Linie aus Menschen und Technologien, die zur Automatisierung ihrer Aktivitäten beitragen, und nicht umgekehrt.

Wie man ein Krankenhaus entwirft

Stellen Sie sich vor, Sie sind eine Bauorganisation, ein Kunde kommt zu Ihnen und bittet darum, an einem solchen Ort ein Krankenhaus zu bauen. Du rennst sofort um Ziegel zu legen oder ...? Wenn Sie sich ansehen, wie oft Informationssysteme erstellt werden, dann ist es so: Die Darsteller beginnen sofort, „in den Beton einzugreifen und Glaspakete zu kaufen“. So wird es nicht funktionieren - wir werden wieder aufbauen! Wir werden wieder aufbauen, bis wir das gewünschte Ergebnis erzielen.

Wenn Sie jedoch eine seriöse Organisation sind, bieten Sie dem Kunden zunächst ein DESIGN für den Bau an. Stimmen Sie zu Und warum ist es falsch mit dem Informationssystem? Vielleicht ist es nicht der Unterschied zwischen Konstruktion und Softwareentwicklung, aber dass sie im selben Krankenhaus viel nachdenken, planen und dann bauen und zuerst Software entwickeln und dann denken? Hören Sie deshalb nicht viel über krivoruky Programmierer, aber nichts über dieselben Wanderarbeiter auf einer Baustelle? Im Gegensatz zu Entwicklern arbeiten Bauherren an dem Projekt.

Ohne Projekt ist das immer so, auch wenn es nicht sichtbar ist

Wir betrachten nun den Entwurfsprozess genauer. Es hat mehrere Stufen. Warum müssen wir mehrere Phasen durchlaufen, warum nicht gleichzeitig? Der Klarheit halber werde ich ein Schulbeispiel geben ... Wie viele Jahre in der Schule haben wir die Multiplikationsoperation studiert? Sie sagen ein oder zwei Monate, und Sie werden sich grundlegend irren. Ja, wie man 5 mit 6 multipliziert, vergeht in einer Woche. Eine bestimmte Zeit wird die Multiplikationstabelle gelehrt. Und die Multiplikation von Brüchen, Zahlen mit einem Grad, Logarithmen, Ausdrücken in Klammern, komplexen Zahlen, die bis zu einem gewissen Grad ansteigen, wie viele Menschen studieren? Fast alle Schuljahre! Es stellt sich heraus, dass wir jedes Jahr dieselbe Multiplikation aus verschiedenen Blickwinkeln untersuchen.

Und warum wird das nicht in der ersten Klasse studiert?

Jeder Lern- und Designprozess ist also zyklisch. Zuerst bekamen wir allgemeine Konzepte über Zahlen, dann lernten wir, wie man einfache Aktionen mit ihnen ausführt, dann lernten wir über Brüche und wie man mit ihnen arbeitet und so weiter.

Zunächst wurde uns klar, welches Problem mit Hilfe des Informationssystems gelöst werden sollte. Dann bestimmten wir den Kreis der zu lösenden Aufgaben, verstanden, was das System tun sollte, welche Aktionen das Personal ausführen sollte. Dann überlegten sie, wie das System die zuvor definierten Aufgaben erfüllen sollte. Sie können diese Schritte überspringen, Sie müssen nur zurückgehen und alles wiederholen: Sieben Mal messen und einmal viel schneller abschneiden als umgekehrt, und es bleibt weniger Material übrig.

Wir geben ein anderes Beispiel. Sie befinden sich oben auf dem Berg und blicken mit einem starken Fernglas nach unten, um eine detaillierte Abstiegsroute zu erstellen. In den Okularen sieht man jeden Kieselstein auf dem Weg, jede Pfütze. Aber hier ist dieser Weg und ob er mit einem Fernglas nach oben führt, ist nicht sichtbar: Es gibt keinen allgemeinen Plan. Ein vernünftiger Kletterer wird zuerst die Abstiegswege mit bloßem Auge skizzieren und sie dann unter starker Vergrößerung untersuchen. Sobald Sie ins Detail gehen, verlieren Sie Ihre allgemeine Sicht auf das Projekt. Wenn Sie das Fernglas sofort nehmen, beschreiben Sie idealerweise 10 Funktionen, während Sie die anderen 40 vergessen, und erwähnen sie im Allgemeinen nicht.

Es kann gut gesehen werden, aber nur ein kleiner Teil

Die Komplexität des phasengesteuerten Designs besteht darin, dass Sie zu Beginn des Prozesses mit abstrakten Konzepten arbeiten müssen. Ich möchte also etwas Bereites "fühlen" und nicht über bestimmte Anforderungen, Funktionen, Aufgaben, Prozesse sprechen. Das sofortige Zeichnen einer Benutzeroberfläche ist einfacher, aber es ist auch einfacher, mindestens die Hälfte der Anforderungen zu übersehen. Wenn wir zunächst eine detaillierte Liste der Vorgänge erstellen, die der Benutzer ausführen muss, wenn er mit dem einen oder anderen Bildschirmformular arbeitet, muss der Designer nur zeichnen und nicht phantasieren, wie dies häufig der Fall ist.

Fahren Sie nun endlich mit den Entwurfsphasen fort.

1. Erstellung allgemeiner Anforderungen

Nehmen wir an, Sie sind Designer. Ein Kunde kommt zu Ihnen und wird von verantwortlichen Bauherren „geschickt“. Der Kunde bittet Sie natürlich, ein Krankenhausprojekt zu entwickeln. Sie rennen zum Kuhlmann und ... Nun, das ist die Antike - starten Sie ArchiCAD und zeichnen Sie.

Aber natürlich geht es nicht um dich. Sie sind ein Profi und stellen eine Reihe von „dummen“ Fragen. Und das wichtigste von ihnen - warum müssen Sie ein Krankenhaus bauen? Was ist der Zweck der Konstruktion? Wenn das Ziel nicht klar ist, können Sie die Frage nicht beantworten, ob es sich um ein großes oder ein kleines Krankenhaus mit welchem Profil handelt, als ausgestattet. Leider sagen Kunden oft viele interessante Dinge, außer der Hauptsache - was ist ihr Zweck. Hier ist es zunächst notwendig, aus ihnen herauszuziehen. Und du solltest eine Frage stellen. Der Kunde selbst ist kein Spezialist, er hat eine Idee und sieht darin seine Rolle erfüllt. Er versteht nicht, welchen Weg es braucht, um seine Idee zu verwirklichen. In der Regel erwartet der Kunde ein gutes altes Wunder - an die Küste zu kommen, ein Netz zu werfen (Geld zu bezahlen), einen Fisch zu fangen, und sie wird seinen Wunsch erfüllen ... Aber es passiert wie in einem Witz über einen reichen Mann, der, nachdem er einen Goldfisch gefangen hat, darum gebeten hat, einen Wunsch zu erfüllen: „ Ich möchte, dass alles bei mir ist! “ "Kein Problem", antwortete der Fisch, "du hattest alles ..."

Um das Ziel des Projekts zu verstehen, reicht es nicht aus, ein paar Sätze mit einem Standardsatz von Phrasen zu bilden. Das Ziel eines Projekts wird in der Regel auf der Grundlage von Widersprüchen festgelegt: Sie beschreiben das vorhandene Informationsmodell (z. B. sitzen Personen im Archiv und sortieren Papiere) und anschließend seine Mängel (aufgrund der mangelnden Automatisierung sind 10 Personen an dem Archiv beteiligt, das eindeutig überflüssig ist, andere Abteilungen können es wochenlang nicht erhalten aus dem Archiv die benötigten Informationen usw.) und bieten eine Lösung an (um Software einzuführen, mit der eine Reihe von Vorgängen in einem automatisierten Modus ausgeführt werden können, müssen die Vorgänge aufgelistet werden). Wenn eine völlig neue Art von Dienstleistung auf den Markt gebracht wird, ist es notwendig, den bestehenden Markt zu untersuchen und die dort verfügbaren Werkzeuge zu „kritisieren“ und dann eine Lösung vorzuschlagen.

Darüber hinaus muss in dieser Phase festgelegt werden, welche gesetzlichen Anforderungen berücksichtigt werden müssen, wie bestimmte Vorgänge legal ausgeführt werden müssen, wie der neue Dienst monetarisiert wird, wie der Markteintritt geplant ist und wie externe Teilnehmer des neuen Systems interessiert werden sollen.

Mit anderen Worten sollte ein Geschäftsmodell erstellt werden. Einerseits ist dies nicht die Aufgabe der Entwickler, andererseits ist ohne eine klare Definition des Ziels und dessen Implementierung nicht klar, welche Aufgaben das System lösen soll. Und wenn der Kunde selbst noch nicht klar formuliert hat, was er braucht, ist es unwahrscheinlich, dass er mit mindestens einem Ergebnis zufrieden ist.

2. Auswahl eines Systemkonzepts

In dieser Phase müssen allgemeine technische Lösungen ausgewählt werden, mit denen die in der vorherigen Phase gestellten Anforderungen erfüllt werden können. Ob es sich um eine Webanwendung oder einen nativen, dicken Client oder eine dünne, zentralisierte Datenbank oder verteiltes, relationales DBMS oder noSQL, Monolith oder Microservices, Java oder Python handelt. Oft wird vergessen, diese Probleme rechtzeitig zu besprechen, und dann stellt sich heraus, dass einer der Programmierer unabhängig ein bestimmtes Werkzeug ausgewählt hat, und am Ende erlaubt diese Lösung nicht, das Ziel zu erreichen.

3. Entwicklung der Leistungsbeschreibung

Ausgewählte allgemeine Anforderungen an das Krankenhaus, wählte das Konzept. "Nun", wird der Kunde sagen, "jetzt ist alles klar, Sie können zeichnen." Ist es möglich Die Anforderungen sind allgemein, sie müssen detailliert sein. Im ersten Schritt haben Sie beispielsweise festgelegt, dass ein Blutuntersuchungslabor vorhanden sein soll. Aber welche Art von Ausrüstung wird es geben, wie viel verbraucht sie Strom, Druckluft (was wäre wenn?), Benötigen Sie Quarzlampen zur Desinfektion, Labortische, Belüftung? Ohne dies wird es schwer zu entwerfen sein. Dies ist der erste. Und zweitens ist es notwendig, einen Plan für den Bau, die Vorbereitung und die Inbetriebnahme eines Krankenhauses vorzuschreiben.

Für das Informationssystem ist die Entwicklung von TOR ( Terms of Reference ) der zentrale Teil des Projekts. Die Leistungsbeschreibung beschreibt:

WAS das System tun sollte.
Wie sollte die Gesamtstruktur des Systems sein?
So erstellen Sie ein System.

Das heißt, das TOR enthält funktionale und nicht funktionale Anforderungen sowie Anforderungen für die Entwicklungsphasen, Lieferung, Abnahme, Dokumentation. Auch im ToR sollten kurz die Prozesse beschrieben werden, die wir tatsächlich automatisieren.

Bei der Beschreibung der Funktionen des Systems (und dies ist der zentrale Teil des TOR) sollte dies verstanden werden - wir geben Anforderungen an, WAS das System tun soll und nicht WIE. Für Sie sollte die Breite der Abdeckung wichtiger sein als die Tiefe. In der ersten Phase (Vorbereitung der allgemeinen Anforderungen) haben wir beispielsweise festgestellt, dass eine Funktion zum Blockieren der Benutzeranmeldung erforderlich ist. In der Arbeitserklärung wird angegeben, dass das Konto gesperrt ist, wenn es 90 Tage lang nicht verwendet wird oder nach 6 erfolglosen Anmeldeversuchen der Zugriff vom Administrator für einen bestimmten Zeitraum eingeschränkt werden kann. Wenn versucht wird, einen gesperrten Benutzer einzugeben, muss eine Meldung angezeigt werden usw. Und im technischen Projekt (lassen Sie uns weiterkommen) zeichnen wir ein Modell der Benutzerkarte mit dem Sperrflag und dem Entsperrdatum, schreiben ein Skript für die Anmeldung bei dem System, in dem die Sperre aktiviert ist, entsperren automatisch nach einer festgelegten Zeitspanne und sperren bei erfolglosen Anmeldeversuchen. Lassen Sie uns bestimmen, was auf der Clientseite und was auf der Serverseite getan wird.

Ich möchte einige Mythen im Zusammenhang mit der Entwicklung technischer Spezifikationen entlarven.

Mythos eins: TK enthält Anforderungen nur für den Auftragnehmer.

Nein, mit TK wird ein System erstellt, und es gibt Abschnitte in der Leistungsbeschreibung, in denen die Verteilung der Verantwortung beschrieben werden kann.

Mythos zwei: In der Leistungsbeschreibung gibt es oft viel „Wasser“.

In der Tat enthält TK häufig allgemeine Informationen über das System, diese werden jedoch benötigt. Zum Beispiel haben wir die Anforderungen an das System besprochen und diskutiert. Als Ergebnis erkannte ein Team, dass es notwendig war, eine Anwendung für Windows und das andere für einen Browser zu entwickeln. Der eine dachte, das System würde so heißen, der andere einen anderen Namen. Es scheint offensichtlich zu sein, aber sie sollten von allen Teammitgliedern und allen beteiligten Spezialisten gleichermaßen verstanden werden.

Mythos drei: Anforderungen an Mitarbeiter, Server, Kommunikationskanäle und Betriebsarten von Administratoren sind überflüssig, da sie im Bereich der Kundenverantwortung liegen.

Erstens, wie wir bereits in Betracht gezogen haben, wird TK für alle gleichzeitig geschrieben, und zweitens beschreibt TK, wie das System funktioniert, und nicht nur die Software wird geschrieben. Andernfalls liegt eine weitere Schachtel mit einer Scheibe und dicken Anweisungen auf einem Regal. Daher ist der organisatorische Teil von TK, nicht funktionale Anforderungen, nicht weniger wichtig als funktionale Anforderungen.

Wir betrachten die Vorbereitung von TK in einem separaten Artikel ausführlicher. Die Entwicklung der Leistungsbeschreibung gemäß GOST 34 ist einfach und unkompliziert .

4. Entwicklung eines technischen Projekts

Also mach weiter. Hier ist vor Ihnen (wir haben zugegeben, dass Sie ein Designer sind). Leistungsbeschreibung für den Bau eines Krankenhauses mit einer riesigen Liste von Anforderungen. Sie sitzen, schauen sich traurig 100 Seiten TK an und wissen nicht, wo Sie anfangen sollen. Dann beginnt sich das Bild allmählich zu klären. Sie denken: Ja, wir brauchen so viele Meter unter den Stationen, so viele unter der Küche, so viel auf dem Rastplatz, im Labor, in den Pflegeräumen und so weiter und so fort. Dann werden viele Skizzen, Skizzen, Optionen geboren, Sie machen neu, tauschen Räume, kurz gesagt, auf der Suche nach dem besten Verhältnis. Dann gehen Sie zu den Details - Zeichnungen, Zeichnungen, Blaupausen: Wände, Türen, Fenster, Kabelkanäle, Kabel, Rohre, Lüftung, Böden, Wandmaterialien, Oberflächen ... und so weiter und so fort und so fort. Umreißen Sie im Allgemeinen so detailliert wie möglich, wie das Krankenhaus nach Abschluss der Bauarbeiten aussehen und funktionieren soll.

Bei der Entwicklung eines technischen Projekts des Informationssystems sind Dokumente erforderlich, die Folgendes enthalten: detaillierte Szenarien, die den Betrieb und die Interaktion des entwickelten Systems, der Benutzer und verwandter Systeme beschreiben; detaillierte Layouts der Benutzeroberfläche mit einer Beschreibung des Datentyps und des Verhaltens jedes Schnittstellenelements (Standardwert, Bedingungen, unter denen Sie den Feldwert ändern können, Sichtbarkeit, vom System ausgeführte Aktionen, wenn sich das Element ändert usw.); Beschreibung der Protokolle zur Integration in verwandte Systeme und Geräte, Berichtsformulare und Beschreibung des Algorithmus für deren Bildung, Struktur von Servern und Datenbanken, falls mehrere vorhanden sind.

Normalerweise ist dies mehr als genug, um Entwicklern Dokumente zu geben und ein vernünftiges Ergebnis zu erzielen. Detaillierte Modelle und Skripte bieten ausreichend Informationen zum Verhalten des Systems und der Schnittstelle sowie zur Datenstruktur. Entwickler werden in einen engen Rahmen gestellt, in dem Sie phantasieren können, aber dann nicht rauskommen.

Ich hoffe, dass wir in den folgenden Artikeln genauer untersuchen werden, wie man technisches Design auf qualitativ hochwertige Weise durchführt, wie man Modelle und Szenarien entwickelt und welche Dokumente erstellt werden müssen.

5. Entwicklung der Arbeitsdokumentation

Die logische Frage ist, was ist die Arbeitsdokumentation für das Krankenhaus? Wirklich die Anleitung zum Reinigen des Korridors ?! Scherz als Scherz, müssen Sie ein Feuersystem warten? Es ist notwendig. Und die Aufzüge? Was ist mit Computernetzwerken? Und die Wasserversorgung? "Nun, das gilt nicht für das Krankenhausprojekt!" - Du sagst. Ja, das ist teilweise richtig. Das Krankenhaus wird jedoch an den gesamten Kunden geliefert, und alle Systeme müssen über eine entsprechende Betriebsdokumentation verfügen. Damit die Änderung schnell und erfolgreich durchgeführt werden kann, erstellen Sie eine Liste mit Anforderungen, gegenüber der Sie überprüfen können, ob alles in Ordnung ist.

Das Vorhandensein von Benutzer- und Administratorhandbüchern für IP ist ein Standard, damit ist alles klar. Der Kunde denkt jedoch oft im letzten Moment über den Prozess der Akzeptanz des Systems nach. Und vergebens. Dafür gibt es ein ausgezeichnetes Dokument, "Programm- und Testmethodik", das sich normalerweise auch auf Arbeitsdokumente bezieht. Es ist eine Art Checkliste, die eine Beschreibung der Überprüfungsverfahren enthält. Wenn dieses Dokument im Voraus erstellt wird (und das Skript als Grundlage aus dem technischen Projekt ausgeliehen werden kann), haben die Entwickler ein klares Kriterium für die Annahme ihrer Arbeit. Sie brauchen keine eigenen oder Outsourcing-Programmierer, um ihren Fall zu beweisen - es gibt ein Szenario, es muss ausgearbeitet werden. Und es wird keine Probleme mit dem Kunden geben - die Fantasie ist bereits durch das Dokument begrenzt.

Und wo ist der Ort für Agile?

Einige Leute mit zwei Händen hinter Agile (oder anderen "flexiblen" Entwicklungsmethoden), andere sind scharf dagegen. Der Autor des Artikels hat seine eigene Meinung: Agile ist sehr gut, aber auf den Punkt. Und sie verwenden es normalerweise für andere Zwecke.

Sagen Sie mir, Liebhaber von Agile, ist es möglich, diese Technologie zu verwenden, um das Ergebnis zu bestimmen, das Sie am Ende der Entwicklung, der Kosten und der Bedingungen erhalten? Nein?Nun, wie viele ~~Dummköpfe~~ werden Sie solche Kunden finden, die sich mit einem unklaren Ergebnis, Budget und Dauer an der Arbeit beteiligen? Würden Sie mit Agile ein Apartmentreparaturteam bestellen? Agile hat also einen Platz, aber für interne Projekte. Sie können Reparaturen so oft selbst durchführen, wie Sie möchten, und alles mehrmals überprüfen. Für externe Kunden ist dies ein Betrug, der von einem intelligenten Begriff bezeichnet wird (Sie werden dieser Formulierung natürlich nicht zustimmen, aber versuchen, den Kunden davon zu überzeugen).

Der Kunde denkt: und wie viele werden sie mir noch um die Nase fahren?

Zweitens ist Agile gut in Innovationen, bei denen nicht klar ist, welche Art von Ergebnis Sie erzielen möchten oder wie dies erreicht werden kann. Dies nennt man OCD, experimentelle Entwicklung. Oder sogar F & E - Forschung und Entwicklung. In jeder Anlage gibt es eine experimentelle Werkstatt, in der Prototypen mit einer Datei erhalten werden, die mehrmals umgebaut wird. Stellen Sie sich vor, Sie müssen den Touchscreen, alle Gesten und Verhaltensweisen neu entwickeln. Hier sollten Sie es wirklich versuchen, Sie können das Verhalten nicht im Voraus beschreiben. Aber stehen Sie oft vor solchen Aufgaben? Man sollte zwischen Technik und Forschung unterscheiden. Grundsätzlich sind wir Konstrukteure von Informationssystemen.

Drittens kann es in einem großen Projekt Phasen geben, in denen Zwangsstörungen erforderlich sind, und dann Agile, um zu helfen. Niemand stört die Verwendung von Sprints auf der Ebene der Betriebsplanung. Im Gegenteil, es ist eine sehr praktische Technologie: Planen Sie ein oder zwei Wochen ein und überwachen Sie das Ergebnis ständig. Auf strategischer Ebene kaskadierende Planung, auf taktischer Ebene iterativ. Und keine Widersprüche!

Leider versuchen Entwickler sehr oft, während sie Agile „predigen“, ihre Unfähigkeit zu maskieren, ein Systemprojekt zu entwickeln (oder sie wissen nicht einmal, dass dies möglich ist). Sie handeln für sie am bequemsten: Wir werden für das Geld des Kunden fertig und fertig. Während niemand die Kosten kontrolliert, kommt dies völlig durch. Aber dann kann ein externer Beobachter (Chefs) das Gefühl haben, dass der Prozess da ist, aber es gibt kein Ende und keine Kante und es ist kein Ergebnis sichtbar. Versuchen Sie nicht nur von Ihrem Glockenturm aus zu schauen.

Wo kann ich mehr über den Entwurf von Informationssystemen erfahren?

Es gibt viele Bücher zu diesem Thema. Dick und nicht so. Aber ein Buch ist immer eine ALIEN-Erfahrung. Und Sie haben einen anderen Charakter, eine großartige Situation und ein Projekt. Es gibt ein solches TRIZ-System - die Theorie der Lösung erfinderischer Probleme. Sein Autor Altshuller versucht zu erklären, welche Schritte Sie unternehmen müssen, um etwas zu erfinden. Es stellt sich heraus? Im Allgemeinen nicht.Die Prinzipien werden als interessant, nützlich bezeichnet, aber eine einzelne Vorlage gemäß der Erfindung kommt nicht heraus. Jeder Mensch denkt und erschafft auf seine Weise, und es ist unmöglich, dies zu lehren, man kann nur lernen. Es ist notwendig, die Erfahrung eines anderen zu nutzen, es ist dumm, sie nicht zu nutzen, aber sie muss von Ihnen erlebt (verarbeitet) und auf IHR Denken verlagert werden. Kopieren Sie das Wunder wird nicht erfolgreich sein.

Wenn Sie Design lernen möchten, schlage ich vor, die staatlichen Standardspezifikationen der 34. Serie als Grundlage zu nehmen. Dies ist ein echtes Meisterwerk, das Ergebnis der Arbeit ganzer Forschungsinstitute. Während der Entwicklung dieser Standards wurden Dutzende (wenn nicht Hunderte) der komplexesten Projekte zur Automatisierung verschiedener Systeme untersucht. Die kolossale Erfahrung wird angesammelt.

Diese Standards sind schwer zu beherrschen, und Sie werden nicht im Handumdrehen lernen, wie man sie verwendet. Daher werden wir versuchen, ihre Essenz in nachfolgenden Artikeln zu enthüllen.

Lesen Sie die Fortsetzung:Einige Hinweise zum Aufbau von Informationssystemen .

Lesen Sie weitere Artikel des Autors:

Geheimnisse des erfolgreichen Entwurfs von IP (Informationssystem) am Beispiel des Baus eines Krankenhauses