Bild: UnsplashHallo allerseits! Wir sind Automatisierungstechniker von
Positive Technologies und unterstützen die Entwicklung von Unternehmensprodukten: Wir unterstützen die gesamte Fertigungslinie von Entwicklern, die eine Codezeile festlegen, bis hin zur Veröffentlichung fertiger Produkte und Lizenzen auf Update-Servern. Informell werden wir DevOps-Ingenieure genannt. In diesem Artikel möchten wir über die technologischen Phasen des Softwareproduktionsprozesses sprechen, darüber, wie wir sie sehen und wie wir sie klassifizieren.
Anhand des Materials erfahren Sie, wie komplex die Koordination der Entwicklung mehrerer Produkte ist, was ein Workflow ist und wie er dazu beiträgt, Lösungen zu organisieren und zu replizieren, welche Hauptphasen und -schritte im Entwicklungsprozess bestehen und wie die Verantwortlichkeiten zwischen DevOps und Teams in unserem Unternehmen aufgeteilt sind.
Über Chaos und DevOps
Beachten Sie kurz, dass das Konzept von DevOps Entwicklungstools und -dienste sowie Methoden und Best Practices für deren Verwendung umfasst. Das globale
Ziel der Einführung von DevOps-Ideen in unserem Unternehmen ist die konsequente Reduzierung der Produktions- und Wartungskosten von Produkten in quantitativen Größen (Arbeitsstunden oder Maschinenstunden, CPU, RAM, Festplatte usw.). Die einfachste und naheliegendste Möglichkeit, die Gesamtentwicklungskosten auf Unternehmensebene zu senken, besteht darin
, die Kosten für die Ausführung typischer Serienaufgaben in allen Produktionsphasen zu
minimieren . Was sind diese Phasen, wie unterscheiden sie sich vom allgemeinen Prozess, aus welchen Schritten bestehen sie?
Wenn ein Unternehmen ein einzelnes Produkt entwickelt, ist alles mehr oder weniger klar: In der Regel gibt es eine gemeinsame Roadmap und ein gemeinsames Entwicklungsschema. Aber was tun, wenn die Produktpalette erweitert wird und es mehr Produkte gibt? Auf den ersten Blick haben sie ähnliche Prozesse und Fließbänder und das Spiel "Finde X Unterschiede" in den Protokollen und Skripten beginnt. Und wenn sich bereits mehr als 5 Projekte in der aktiven Entwicklung befinden und Sie Unterstützung für mehrere Versionen benötigen, die über mehrere Jahre hinweg entwickelt wurden? Wollen wir die maximal mögliche Anzahl von Lösungen in Produktförderern wiederverwenden oder sind wir bereit, für jede einzelne Entwicklung Geld auszugeben?
Wie lässt sich ein Gleichgewicht zwischen Eindeutigkeit und Serialität von Lösungen finden?
Diese Probleme tauchten seit 2015 immer häufiger vor uns auf. Die Anzahl der Produkte wuchs und wir versuchten, den Ausbau unserer Automationsabteilung (DevOps), die die Montagelinien dieser Produkte unterstützte, auf ein Mindestmaß zu beschränken. Gleichzeitig wollte ich so viele Lösungen wie möglich, um zwischen den Produkten zu replizieren. Warum sollte man in zehn Produkten dasselbe auf unterschiedliche Weise tun?
Entwicklungsleiter : "Leute, können wir irgendwie bewerten, was DevOps für Produkte tut?"
Wir : "Wir wissen nicht, wir haben uns keine solche Frage gestellt, aber welche Indikatoren sollten berücksichtigt werden?"
Entwicklungsleiter : „Und wer weiß! Denken Sie ... "
Wie im berühmten Film: "In mein Hotel! .." - "Äh ... Wirst du den Weg zeigen?" Denken, wir kamen zu dem Schluss, dass Sie zuerst über den Endzustand der Produkte entscheiden müssen; Dies war unser erstes Ziel.
Wie können Sie ein Dutzend Produkte mit ausreichend großen Teams von 10 bis 200 Mitarbeitern analysieren und messbare Messgrößen für die Replikation von Lösungen ermitteln?
1: 0 zugunsten von Chaos oder DevOps an den Schulterblättern
Wir begannen mit dem Versuch, IDEF0-Diagramme und verschiedene Geschäftsprozessdiagramme aus der BPwin-Reihe anzuwenden. Die Verwirrung begann nach dem fünften Kasten der nächsten Phase des nächsten Projekts, und diese Quadrate für jedes Projekt können in mehr als 50 Schritten in den Schwanz einer langen Python gezeichnet werden. Ich war traurig und wollte zum Mond heulen - es passte überhaupt nicht.
Typische Produktionsaufgaben
Die Modellierung von Produktionsprozessen ist eine sehr komplexe und sorgfältige Arbeit: Sie müssen viele Daten zu verschiedenen Abteilungen und Produktionsketten sammeln, verarbeiten und analysieren. Mehr dazu erfahren Sie im Artikel "
Modellierung von Produktionsprozessen in IT-Unternehmen ".
Als wir mit der Modellierung unseres Produktionsprozesses begannen, verfolgten wir ein bestimmtes Ziel - jedem Mitarbeiter, der an der Entwicklung der Produkte unseres Unternehmens beteiligt ist, und den Projektmanagern Folgendes mitzuteilen:
- wie Produkte und ihre Komponenten ausgehend von einem Code-Commit den Kunden in Form von Installern und Updates erreichen,
- Welche Ressourcen werden für jede Produktionsstufe der Produkte bereitgestellt?
- welche Dienstleistungen in jeder Phase involviert sind,
- Wie unterscheiden sich die Verantwortungsbereiche für die einzelnen Phasen?
- Welche Verträge existieren am Eingang und Ausgang jeder Stufe?
Mit einem Klick auf das Bild wird es in voller Größe geöffnetUnsere Arbeit im Unternehmen gliedert sich in mehrere Funktionsbereiche. Die Richtung der Infrastruktur ist die Optimierung des Betriebs aller "Eisen" -Ressourcen der Abteilung sowie die Automatisierung der Bereitstellung virtueller Maschinen und der Umgebung auf diesen. Die Überwachungsrichtung bietet eine Überwachung des Zustands des Dienstes rund um die Uhr. Wir bieten auch Monitoring als Service für Entwickler an. Die Workflow-Richtlinien bieten Teams Tools zum Verwalten von Entwicklungs- und Testprozessen, zum Analysieren des Codestatus und zum Erhalten von Projektanalysen. Und schließlich bietet webdev Veröffentlichungen auf den GUS- und FLUS-Update-Servern sowie die Lizenzierung von Produkten mithilfe des LicenseLab-Dienstes an. Um die Produktionspipeline zu unterstützen, haben wir viele verschiedene Support-Services für Entwickler eingerichtet und gepflegt (Sie können sich Geschichten über einige von ihnen auf den alten Mitaps anhören:
Op! DevOps! 2016 und
Op! DevOps! 2017 ). Wir entwickeln auch interne Automatisierungstools, einschließlich
Open Source-Lösungen .
In den letzten fünf Jahren haben sich in unserer Arbeit viele gleichartige und routinemäßige Vorgänge angesammelt, und von unseren Entwicklern aus anderen Abteilungen kommen hauptsächlich die sogenannten
Standardaufgaben , deren Lösung ganz oder teilweise automatisiert ist, keine Schwierigkeiten für die Ausführenden verursacht und keinen nennenswerten Arbeitsaufwand erfordert. Gemeinsam mit den führenden Bereichen haben wir solche Aufgaben analysiert und bestimmte Kategorien von Arbeiten oder
Produktionsstufen unterschieden , die Stufen in unteilbare Stufen unterteilt und die
produktionstechnologische Kette besteht aus mehreren Stufen.
Das einfachste Beispiel für eine technologische Kette sind die Phasen der Montage, Bereitstellung und Prüfung jedes unserer Produkte innerhalb des Unternehmens. Im Gegenzug besteht die Erstellungsphase beispielsweise aus vielen einzelnen typischen Schritten: Herunterladen des Quellcodes aus GitLab, Vorbereiten von Abhängigkeiten und Bibliotheken von Drittanbietern, Testen von Einheiten und Analyse des statischen Codes, Ausführen eines Erstellungsskripts in GitLab CI und Veröffentlichen von Artefakten im Store in Artifactory und Generieren von Versionshinweisen über unser internes Tool ChangelogBuilder.
Informationen zu typischen DevOps-Aufgaben finden Sie in unseren anderen Artikeln zu Habré: „
Persönliche Erfahrung: Wie unser Continuous Integration-System aussieht “ und „
Automatisierung von Entwicklungsprozessen: Wie wir DevOps-Ideen in Positive Technologies implementiert haben “.
Viele typische Produktionsketten bilden den
Produktionsprozess . Ein Standardansatz zur Beschreibung von Prozessen ist die Verwendung funktionaler IDEF0-Modelle.
Ein Beispiel für die Modellierung eines Produktions-CI-Prozesses
Besonderes Augenmerk haben wir auf die Entwicklung von Modellprojekten für ein kontinuierliches Integrationssystem gelegt. Dies ermöglichte es uns, Projekte zu vereinheitlichen und das sogenannte
Release-Assembly-Schema mit Fortschritten hervorzuheben.
So funktioniert es Alle Projekte sehen typisch aus: Sie umfassen die Konfiguration von Assemblys, die in das Snapshot-Repository von Artifactory fallen. Anschließend werden sie auf Testständen bereitgestellt und getestet und dann in das Release-Repository hochgestuft. Der Artifactory-Dienst ist der zentrale Verteilungspunkt für alle Build-Artefakte zwischen Teams und anderen Diensten.
Wenn wir unser Freigabeschema stark vereinfachen und verallgemeinern, umfasst es die folgenden Schritte:
- plattformübergreifende Produktmontage,
- Bereitstellung auf Prüfständen,
- Ausführen von Funktions- und anderen Tests
- Förderung von getesteten Builds, um Repositories auf Artifactory freizugeben,
- Release-Builds veröffentlichen, um Server zu aktualisieren,
- Lieferung von Baugruppen und Updates für die Produktion,
- Starten Sie die Installation und Produktaktualisierungen.
Betrachten Sie beispielsweise das technologische Modell dieses typischen Release-Schemas (im Folgenden einfach als Modell bezeichnet) in Form eines funktionalen IDEF0-Modells. Es spiegelt die Hauptphasen unseres CI-Prozesses wider. IDEF0-Modelle verwenden die sogenannte
ICOM-Notation (Input-Control-Output-Mechanism), um zu beschreiben, welche Ressourcen in jeder Phase verwendet werden, basierend auf welchen Regeln und Anforderungen, was getan wird, was ausgegeben wird und welche Mechanismen, Dienste oder Personen Implementieren Sie eine bestimmte Phase.
Mit einem Klick auf das Bild wird es in voller Größe geöffnetIn funktionalen Modellen ist es in der Regel einfacher, die Beschreibung von Prozessen zu zerlegen und detaillierter darzustellen. Mit zunehmender Anzahl der Elemente wird es jedoch immer schwieriger, sie zu verstehen. In der realen Entwicklung gibt es aber auch Hilfsschritte: Überwachung, Zertifizierung von Produkten, Automatisierung von Arbeitsabläufen und andere. Aufgrund des Skalierungsproblems haben wir eine solche Beschreibung aufgegeben.
Die Geburt der Hoffnung
In einem Buch bin ich auf alte sowjetische Karten gestoßen, die technologische Prozesse beschreiben (die übrigens heute in vielen staatlichen Unternehmen und Universitäten verwendet werden). Warten Sie, warten Sie, denn wir haben auch einen technologischen Prozess! Es gibt Phasen, Ergebnisse, Metriken, Anforderungen, Indikatoren usw. Warum versuchen Sie nicht, technologische Karten auf unsere Produktförderer anzuwenden? Es gab ein Gefühl: „Hier ist es! Wir haben den richtigen Faden gefunden, es ist Zeit, ihn gut zu ziehen! “
In einer einfachen Tabelle haben wir beschlossen, die Produkte in Spalten und in den Zeilen technologische Stufen und Stufen des Produktförderers zu fixieren. Stufen - das ist etwas Großes, zum Beispiel die Stufe der Montage des Produkts. Und die Schritte sind kleiner und detaillierter, zum Beispiel der Schritt des Herunterladens des Quellcodes auf den Build-Server oder der Schritt des Kompilierens des Codes.
An den Schnittpunkten von Zeilen und Spalten der Karte werden die Status für eine bestimmte Phase und ein bestimmtes Produkt notiert. Für Status wurden viele Zustände definiert:
- Keine Daten - oder unpraktisch. Es ist notwendig, eine Analyse der Relevanz der Stufe im Produkt durchzuführen. Entweder wurde die Analyse bereits durchgeführt, aber die Stufe wird derzeit nicht benötigt oder ist wirtschaftlich nicht gerechtfertigt.
- Verschoben - oder momentan irrelevant. Eine Stufe im Förderband ist erforderlich, aber in diesem Jahr gibt es keine Umsetzungskräfte.
- Geplant . Die Umsetzung der Etappe ist für dieses Jahr geplant.
- Es ist implementiert . Die Stufe im Förderer wird im erforderlichen Volumen ausgeführt.
Das Füllen des Tisches begann projektweise. Zunächst wurden Phasen und Schritte eines Projekts klassifiziert und deren Status erfasst. Dann nahmen sie das nächste Projekt, zeichneten den Status auf und fügten die Schritte und Schritte hinzu, die in früheren Projekten fehlten. Als Ergebnis erhielten wir die Stufen und Schritte unseres gesamten Produktionsförderers und deren Status in einem bestimmten Projekt. Es hat sich etwas ähnliches herausgestellt wie die Kompetenzmatrix des Produktförderers. Wir haben eine solche Matrix eine technologische Karte genannt.
Mit Hilfe der technologischen Karte stimmen wir uns messtechnisch angemessen mit den jährlichen Arbeitsplänen und Zielen des Teams ab, die wir gemeinsam erreichen möchten: Welche Phasen fügen wir in diesem Jahr dem Projekt hinzu und welche lassen wir für später. Während des Arbeitsprozesses erhalten wir möglicherweise Verbesserungen in den Phasen, die wir nur für ein Produkt durchgeführt haben. Dann erweitern wir unsere Karte und führen diese Verbesserung als Stufe oder als neuen Schritt ein. Anschließend analysieren wir jedes Produkt und finden heraus, ob es sinnvoll ist, die Verbesserung zu replizieren.
Sie mögen uns widersprechen: „Das ist natürlich alles gut, nur mit der Zeit wird die Anzahl der Schritte und Stufen unerschwinglich groß. Wie soll ich sein? "
Wir haben für jede Stufe und jeden Schritt eine standardmäßige und ausreichend vollständige Beschreibung der Anforderungen eingeführt, damit sie von allen im Unternehmen gleichermaßen verstanden werden. Wenn Verbesserungen eingeführt werden, kann eine Stufe mit der Zeit in einer anderen Stufe oder einem anderen Schritt absorbiert werden - dann werden sie "zusammenbrechen". In diesem Fall passen alle Anforderungen und technologischen Nuancen zu den Anforderungen einer Verallgemeinerungsstufe oder eines Verallgemeinerungsschritts.
Wie bewerte ich die Auswirkung von Replikationsentscheidungen? Wir verwenden einen äußerst einfachen Ansatz: Wir schreiben die anfänglichen Kapitalkosten für die Implementierung der neuen Stufe den jährlichen Gesamtkosten für Lebensmittel zu und teilen sie dann bei der Replikation in alle auf.
Teile der Entwicklung spiegeln sich bereits als Schritte und Schritte auf der Karte wider. Wir können die Reduzierung der Produktkosten durch die Einführung von Automatisierung für typische Stufen beeinflussen. Danach betrachten wir die Änderungen der qualitativen Merkmale, der quantitativen Kennzahlen und des Gewinns, den die Teams erzielen (in Arbeitsstunden oder Maschinenstunden Einsparungen).
Ablaufdiagramm
Wenn wir alle unsere Schritte unternehmen, mit Tags codieren und in einer Kette erweitern, wird es sehr lang und unverständlich (nur der eigentliche „Python-Schwanz“, über den wir am Anfang des Artikels gesprochen haben):
[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]
Dies sind die Schritte zum Zusammenstellen von Produkten [Erstellen], zum Bereitstellen auf Testservern [Bereitstellen], zum Testen von [Testen], zum Heraufstufen von Assemblys zum Freigeben von Repositorys basierend auf dem Testen von [Heraufstufen], zum Generieren und Veröffentlichen von Lizenzen [Lizenz] und zum Veröffentlichen von [Veröffentlichen] auf dem GUS-Aktualisierungsserver und Bereitstellung auf FLUS-Update-Servern, Installation und Aktualisierung von Produktkomponenten in der Kundeninfrastruktur mithilfe des Produktkonfigurationsmanagements [Installieren] sowie Erfassung der Telemetrie [Telemetrie] von installierten Produkten.
Darüber hinaus gibt es separate Phasen: Überwachen des Status der Infrastruktur [InfMonitoring], Versionskontrolle des Quellcodes [SourceCodeControl], Vorbereiten der Assembly-Umgebung [Vorbereiten], Projektmanagement [Workflow], Bereitstellen von Kommunikationstools für Teams [Kommunikation], Produktzertifizierung [Zertifizierung] und Bereitstellen Autarkie von CI-Prozessen [CISelfSufficiency] (zB Unabhängigkeit von Baugruppen vom Internet). Wir werden nicht einmal Dutzende von Schritten in unseren Prozessen berücksichtigen, da diese sehr spezifisch sind.
Es wird viel einfacher sein, den gesamten Produktionsprozess zu verstehen und zu betrachten, wenn er in Form einer
technologischen Landkarte dargestellt wird . Dies ist eine Tabelle, in der die einzelnen Produktionsschritte und zerlegten Schritte des Modells in Zeilen geschrieben sind und die Spalten beschreiben, was bei jedem Schritt oder Schritt getan wird. Der Schwerpunkt liegt auf den Ressourcen, die die einzelnen Phasen bereitstellen, und auf der Abgrenzung der Verantwortungsbereiche.
Die Karte ist für uns eine Art Klassifikator. Es spiegelt die großen technologischen Teile der Lebensmittelproduktion wider. Dadurch wurde es für unser Automatisierungsteam einfacher, mit Entwicklern zu interagieren und die Implementierung von Automatisierungsstufen gemeinsam zu planen sowie zu verstehen, welche Arbeitskräfte und Ressourcen (Mensch und "Eisen") erforderlich sind.
In unserem Unternehmen wird eine Map automatisch aus einer Jinja-Vorlage in Form einer regulären HTML-Datei generiert und dann auf den GitLab Pages-Server hochgeladen. Ein Screenshot mit einem Beispiel einer vollständig generierten Karte kann hier angesehen
werden .
Mit einem Klick auf das Bild wird es in voller Größe geöffnetKurz gesagt, das Flussdiagramm ist ein verallgemeinertes Bild des Produktionsprozesses, in dem sich klar klassifizierte Blöcke mit typischer Funktionalität widerspiegeln.
Die Struktur unseres Routings
Die Karte besteht aus mehreren Teilen:
- Überschriftenbereich - hier wird eine allgemeine Beschreibung der Karte gegeben, grundlegende Konzepte werden vorgestellt, grundlegende Ressourcen und Ergebnisse des Produktionsprozesses werden ermittelt.
- Informationspanel - Hier können Sie die Anzeige der Daten für einzelne Produkte steuern und eine Zusammenfassung der Schritte und Schritte für alle Produkte im Allgemeinen anzeigen.
- Technologische Karte - eine tabellarische Beschreibung des technologischen Prozesses. Auf der Karte:
- alle Stufen, Schritte und deren Codes sind angegeben;
- Eine kurze und vollständige Beschreibung der Stufen wird gegeben;
- Die auf jeder Stufe verwendeten Eingaberessourcen und Dienste werden angezeigt.
- die Ergebnisse jeder Stufe und jedes einzelnen Schritts sind angegeben;
- Der Verantwortungsbereich für jeden Schritt und jede Stufe ist angegeben;
- identifizierte technische Ressourcen, wie z. B. HDD (SSD), RAM, vCPU und Arbeitsstunden, die erforderlich sind, um die Arbeit in dieser Phase zu unterstützen, sowohl zum gegenwärtigen Zeitpunkt als auch in der Zukunft, als Plan;
- für jedes produkt wird angegeben, welche technologischen schritte oder schritte dafür implementiert wurden, für die implementierung geplant sind, irrelevant sind oder nicht implementiert wurden.
Entscheidungsfindung auf Basis der technologischen Landkarte
Nach der Überprüfung der Karte können - abhängig von der Rolle des Mitarbeiters im Unternehmen (Entwicklungsleiter, Produktmanager, Entwickler oder Tester) - einige Maßnahmen ergriffen werden:
- zu verstehen, welche Schritte in einem realen Produkt oder Projekt fehlen, und die Notwendigkeit ihrer Implementierung zu bewerten;
- Zuständigkeitsbereiche zwischen mehreren Abteilungen zu unterscheiden, wenn diese auf verschiedenen Stufen arbeiten;
- Verträge an den Ein- und Ausgängen der Etappen vereinbaren;
- Integrieren Sie Ihren Arbeitsstand in den gesamten Entwicklungsprozess.
- den Bedarf an Ressourcen, die die einzelnen Phasen bereitstellen, genauer einschätzen.
Alles zusammenfassen
Das Routing ist universell, erweiterbar und wartungsfreundlich. Es ist viel einfacher, eine Beschreibung von Prozessen in dieser Form zu entwickeln und beizubehalten als in einem strengen akademischen IDEF0-Modell. Darüber hinaus ist die tabellarische Beschreibung einfacher, vertrauter und besser strukturiert als das Funktionsmodell.
Für die technische Umsetzung der Schritte sind wir verantwortlich für das spezielle interne CrossBuilder-Tool - ein Interlayer-Tool zwischen CI-Systemen, Services und Infrastruktur. Der Entwickler muss sein Fahrrad nicht sehen: In unserem CI-System genügt es, eines der Skripte (die sogenannte Task) des CrossBuilder-Tools auszuführen, das es unter Berücksichtigung der Besonderheiten unserer Infrastruktur korrekt ausführt.
Zusammenfassung
Der Artikel erwies sich als recht lang, was jedoch bei der Beschreibung der Modellierung komplexer Prozesse unumgänglich ist. Zum Schluss möchte ich kurz unsere Hauptideen festhalten:
- Ziel der Einführung von DevOps-Ideen in unserem Unternehmen ist eine konsequente Reduzierung der Produktions- und Wartungskosten für Unternehmensprodukte in quantitativen Größen (Arbeitsstunden oder Maschinenstunden, vCPU, RAM, Festplatte).
- Eine Möglichkeit, die Gesamtkosten für die Entwicklung zu senken, besteht darin, die Kosten für die Ausführung typischer serieller Aufgaben zu minimieren: Phasen und Schritte des technologischen Prozesses.
- Eine typische Aufgabe ist eine Aufgabe, deren Lösung ganz oder teilweise automatisiert ist, die den Ausführenden keine Schwierigkeiten bereitet und keine erheblichen Arbeitskosten verursacht.
- Der Produktionsprozess besteht aus Stufen, die Stufen sind in unteilbare Stufen unterteilt, die typische Aufgaben von unterschiedlichem Umfang und Volumen sind.
- Aus unterschiedlichen typischen Aufgaben sind wir zu komplexen technologischen Ketten und mehrstufigen Modellen des Produktionsprozesses gekommen, die durch ein funktionsfähiges IDEF0-Modell oder ein einfacheres Flussdiagramm beschrieben werden können.
- Ein Arbeitsplan ist eine tabellarische Darstellung der Schritte und Schritte eines Herstellungsprozesses. Am wichtigsten: Auf der Karte können Sie den gesamten Prozess in großen Teilen mit der Möglichkeit der Detaillierung anzeigen.
- Anhand der technologischen Landkarte ist es möglich, die Notwendigkeit der Implementierung von Phasen in einem bestimmten Produkt zu bewerten, die Verantwortungsbereiche zu differenzieren, Verträge für die Inputs und Outputs der Phasen zu vereinbaren und den Ressourcenbedarf genauer zu bewerten.
In den folgenden Artikeln werden wir detaillierter darauf eingehen, mit welchen technischen Tools bestimmte technologische Phasen auf unserer Karte implementiert werden.
Autoren des Artikels: