ALM - Application Lifecycle Management - Verwaltung des Lebenszyklus von Anwendungen. Das Konzept der Application Lifecycle Management Methodik - ALM (Application Lifecycle Management)

Usw..

„Lebenszyklusmanagement“ läuft auf die Notwendigkeit hinaus, die aus dem System-Engineering bekannten Praktiken zu beherrschen:

• Informationsmanagement(„Die richtigen Informationen müssen den richtigen Stakeholdern rechtzeitig und in einer für ihre Nutzung zugänglichen Form zur Verfügung stehen“),
• Konfigurationsmanagement(„Die Designinformationen müssen mit den Anforderungen übereinstimmen, die „as built“-Informationen müssen mit dem Design übereinstimmen, einschließlich Designbegründungen, das physische System muss mit den „as built“-Informationen übereinstimmen, und verschiedene Teile des Designs müssen miteinander übereinstimmen“, manchmal Teil dieser Praxis wird "Change Management" genannt).

LCMS vs. PLM

Das neu formulierte LCMS verwendet PLM nicht als erforderliche Softwareklasse, um die herum ein solches System aufgebaut ist. In großen Engineering-Projekten werden mehrere (meist deutlich „unterentwickelte“) PLMs von verschiedenen Anbietern gleichzeitig verwendet, und wenn wir ein LCMS erstellen, sprechen wir normalerweise von ihrer interorganisationalen Integration. Gleichzeitig werden natürlich auch die Fragen gelöst, wie Informationen von Systemen, die noch nicht mit einem der PLM-Systeme des erweiterten Unternehmens verbunden sind, in das LCMS integriert werden können. Der Begriff "erweitertes Unternehmen" (erweitertes Unternehmen) bezieht sich normalerweise auf eine Organisation, die durch ein System von Verträgen aus den Ressourcen (Personen, Werkzeuge, Materialien) verschiedener juristischer Personen geschaffen wurde, die an einem bestimmten Ingenieurprojekt teilnehmen. In erweiterten Unternehmen wird die Antwort auf die Frage, in welches PLM die Daten welcher bestimmten CAD-/CAM-/ERP-/EAM-/CRM-Systeme usw. integriert sind, nicht trivial: Sie können den Eigentümern verschiedener Unternehmen die Nutzung der Software nicht vorschreiben eines Lieferanten.

Und da das PLM-System immer noch eine Software ist und das „Managementsystem“ aus dem LCMS eindeutig auch als „Managementsystem“ verstanden wird, impliziert der Begriff LCMS eindeutig den organisatorischen und nicht nur den informationstechnischen Aspekt. Daher ist der Ausdruck „PLM zur Unterstützung eines Lebenszyklusmanagementsystems verwenden“ ziemlich aussagekräftig, obwohl er verwirrend sein kann, wenn er darin wörtlich „PLM“ ins Russische übersetzt.

Das Verständnis eines „Lifecycle-Management-Systems“, wenn es von den IT-Leuten gehandhabt wird, schrumpft jedoch sofort auf „nur Software“, die verdächtig nach PLM-Software aussieht. Und nach dieser übermäßigen Vereinfachung beginnen die Schwierigkeiten: Ein „verpacktes“ PLM-System eines Anbieters von Konstwird normalerweise sofort konstruktiv als eine Reihe von Softwaremodulen aus dem Katalog dieses Anbieters ohne Berücksichtigung der unterstützten Konstruktions- und Verwaltungsfunktionen präsentiert und wird als Trio der folgenden Komponenten betrachtet:

• datenzentrisches Lebenszyklus-Datenrepository,
• "Workflow-Engine" zur Unterstützung des "Managements",
• „Portal“, um den Inhalt des Repositorys und den Status des Workflows anzuzeigen.

Zweck des LCMS

Hauptzweck: LCMS erkennen und verhindern Kollisionen, die bei der kollaborativen Entwicklung unvermeidlich sind. Alle anderen LCMS-Funktionen sind Derivate, die diese Hauptfunktion unterstützen.

Die Grundidee eines jeden modernen LCMS- Dies ist die Verwendung einer genauen und konsistenten Darstellung des Systems und der Welt um es herum in den unvermeidlich heterogenen und anfänglich inkompatiblen Computersystemen einer erweiterten Organisation. Die Verwendung von virtuellen Layouts, Informationsmodellen und datenzentrischen Repositories von Konstruktionsinformationen gewährleistet die Erkennung von Kollisionen während der „Konstruktion im Computer“, der „virtuellen Montage“ und nicht beim Zeichnen von Zeichnungen und anderen Projektmodellen in die materielle Realität während der tatsächlichen Konstruktion „in Metall und Beton“ und in Betrieb nehmen.

Die Idee von LCMS bezieht sich also nicht auf diverse „Design Automation“, sondern in erster Linie auf „Generative Design“ (Generative Design) und „Generative Production“ (Generative Manufacturing). Das LCMS befasst sich nicht mehr mit Synthese, sondern mit Analyse: Es erkennt und/oder verhindert Kollisionen in den Konstruktionsergebnissen einzelner Subsysteme, wenn sie mit verschiedenen Technologien zusammengesetzt werden:

• Zusammenführen von Projektdaten in einem Repository,
• Ausführen des Integritätsprüfungsalgorithmus für Engineering-Daten, die in mehreren Repositories verteilt sind,
• durch Durchführen einer tatsächlichen "virtuellen Montage" und Simulation für eine speziell ausgewählte Teilmenge von Konstruktionsdaten.

Modellbasierter Ansatz

Der Einsatz von LCMS impliziert Verzicht nicht nur auf Papier im Design, sondern auch auf „elektronisches Papier“(.tiff oder andere Rasterformate) und der Übergang zur datenzentrischen Darstellung von Informationen. Der Vergleich zweier Modelle, die in einigen Notationen auf Papier existieren, und das Auffinden von Inkonsistenzen in ihnen ist viel schwieriger und länger als das Verhindern von Kollisionen in strukturierten elektronischen Dokumenten, die Konstruktionsdatenmodelle anstelle von Rastergrafiken verwenden.

Das Datenmodell kann nach einer Sprache gestaltet werden, zum Beispiel:

• im Sinne des Standards ISO 24744 zur Beschreibung von Entwicklungsmethoden),
• Metamodell (im Sinne des OMG-Standardisierungskonsortiums),
• Datenmodell/Referenzdaten (im Sinne des Integrationsstandards für Lebenszyklusdaten ISO 15926).

Dieser Übergang zu strukturell repräsentierten Modellen existiert bereits in frühen Entwurfsphasen und wird als „Model-based Systems Engineering“ (MBSE, Model-based Systems Engineering) bezeichnet. Bereits in den frühesten Stadien des Lebenszyklus, noch vor dem Erscheinen vollwertiger 3D-Modelle der Struktur, wird es möglich, Kollisionen durch Computerdatenverarbeitung zu beseitigen.

Das LCMS sollte:

• Bereitstellung eines Mechanismus zum Übertragen von Daten aus einer einzigen Anwendung CAD/CAM/ERP/PM/EAM/usw. zum anderen- und in elektronisch strukturierter Form und nicht in Form eines "Pakets elektronischen Papiers". Die Übertragung von Daten aus einem technischen Informationssystem (mit einem klaren Verständnis dafür, wo, wo, wann, was, warum, wie) ist Teil der vom LCMS bereitgestellten Funktionalität. Daher muss das LCMS den Workflow (den Arbeitsfluss, der teilweise von Menschen und teilweise von Computersystemen ausgeführt wird) unterstützen.
• Versionskontrolle, das heißt, eine Kbereitzustellen – sowohl Modelle als auch physische Teile des Systems. Das LCMS unterhält eine Taxonomie abgestufter Anforderungen und stellt ein Mittel bereit, um zu prüfen, ob abgestufte Entwurfsentscheidungen und deren Begründungen mit diesen Anforderungen kollidieren. Im Laufe der technischen Entwicklung wird jede Beschreibung des Systems, jedes seiner Modelle viele Male geändert und ergänzt und existiert daher in vielen alternativen Versionen mit unterschiedlichem Grad an Korrektheit und mit unterschiedlichem Grad an Übereinstimmung miteinander. Das LCMS muss sicherstellen, dass für die aktuelle Arbeit nur die richtige Kombination dieser Versionen verwendet wird.

LCMS-Architektur

Es kann viele architektonische Lösungen für LCMS geben, dieselbe Funktion kann durch verschiedene Strukturen und Arbeitsmechanismen unterstützt werden. Es gibt drei Arten von Architektur:

1. Herkömmliche Versuche, ein LCMS zu erstellen ist es, kritische Datenübertragungen auf einer Punkt-zu-Punkt-Basis zwischen verschiedenen Anwendungen bereitzustellen. In diesem Fall kann ein spezialisiertes Workflow-Unterstützungssystem (BPM-Engine, "Business Process Management Engine") oder ein Ereignisverarbeitungssystem (Complex Event Processing Engine) verwendet werden. Leider erweist sich der Aufwand für die Bereitstellung von Punkt-zu-Punkt-Austauschen als enorm: Jedes Mal werden Spezialisten benötigt, die sowohl die Verknüpfungssysteme als auch die Methode der Informationsübertragung verstehen.
2. Verwendung des Integrationsstandards für Lebenszyklusdaten ISO 15926 nach der „ISO 15926 Outside“-Methode, wenn für jede Engineering-Anwendung ein Adapter zu einer neutralen, normkonformen Darstellung entwickelt wird. So bekommen alle Daten die Möglichkeit, in irgendeiner Anwendung zusammenzutreffen und eine Kollision zwischen ihnen kann erkannt werden - aber die Anwendung braucht nur einen Datenübertragungsadapter zu entwickeln, und nicht mehrere solcher Adapter (entsprechend der Anzahl anderer Anwendungen, mit denen sie verbunden ist notwendig, um zu kommunizieren).
3. PLM(Teamcenter, ENOVIA, SPF, NET-Plattform usw.) – es wird eine standardisierte Architektur verwendet, mit der einzigen Ausnahme, dass das Datenmodell, das in jedem dieser PLMs verwendet wird, weniger universell ist, um alle Fachgebiete des Engineerings widerzuspiegeln, und ist auch nicht neutral und in allen Formaten verfügbar. Die Verwendung von ISO 15926 als Grundlage für die Übertragung von Daten an das LCMS kann daher als Weiterentwicklung der tatsächlich in modernem PLM umgesetzten Ideen angesehen werden.

Gemäß der Konkann LCMS in drei Typen unterteilt werden:

• "Repository"(Aktuelle Speicherung aller Projektdaten in einem LCMS-Repository, wo Daten von dort kopiert werden, wo sie entwickelt wurden),
• "registrieren"(LCMS verwaltet eine Liste von Lebenszyklusdatenadressen in zahlreichen Repositories anderer CAD-Systeme, technischer Simulationssysteme, PLM, ERP usw.),
• "Hybride Architektur"-- wenn ein Teil der Daten in das zentrale LCMS-Repository kopiert wird und ein Teil der Daten von anderen Stellen über Links verfügbar ist.

Der LCMS-Architekt sollte außerdem Folgendes beschreiben:

• "Portal"(einschließlich „Webportal“), seine Funktionen und Art der Implementierung. Die bloße Präsenz des Portals ermöglicht es Ihnen, Top-Manager zu beruhigen, indem Sie die Abwesenheit von Konflikten demonstrieren. An architektonische Lösungen für das LCMS-Portal werden besondere Anforderungen gestellt.
• Datenintegritäts-/Konsistenzprüfungsalgorithmen Lebenszyklus sowie eine Beschreibung der Funktionsweise dieser Algorithmen:
  • ein Standardmodul in einer separaten Anwendung, das mit Daten im Repository dieser Anwendung arbeitet – sei es CAD oder PLM;
  • Speziell für LCMS entwickelte Kollisionsprüfungssoftware, die Zugriff auf Daten aus verschiedenen Anwendungen hat, die sich im zentralen LCMS-Repository befinden;
  • ein speziell entwickeltes Softwaretool, das über das Internet über einen sicheren Kanal auf verschiedene Datenablagen zugreift, die sich in verschiedenen Organisationen befinden;
  • speziell programmierte Prüfungen mit Kollisionskontrolle beim Laden unterschiedlicher Engineering-Datensätze in das zentrale Repository des LCMS;
  • eine Kombination aller aufgeführten Methoden - unterschiedlich für verschiedene Arten von Kollisionen; usw.
• die Art und Weise, wie LCMS-Benutzer interagieren(Konstrukteure, Einkäufer, Installateure, Facility-Projektmanager usw.) und wie die LCMS-Software diese Interaktion kollisionsfrei unterstützt. Systems-Engineering-Standards (insbesondere der System-Engineering-Praxisstandard ISO 15288) erfordern eine Auswahl des Lebenszyklustyps für komplexes Objekt-Engineering und einen Hinweis darauf, welche Systems-Engineering-Praxisoptionen verwendet werden. Das Lebenszyklusmodell ist eines der wichtigsten Artefakte, die als organisatorische Vorkehrungen für die Koordinierung der Arbeit der erweiterten Engineering-Projektorganisation dienen. Koordiniertes Arbeiten im Rahmen von Collaborative Engineering ist der Schlüssel zu wenigen Konstruktionskollisionen. Wie genau wird das LCMS-Lebenszyklusmodell dies unterstützen? Daher finden PLM-Systeme in der Regel keinen Platz für Lebenszyklusmodelle und erst recht nicht für Organisationsmodelle. Daher ist es für LCMS notwendig, nach anderen Lösungen für die Softwareunterstützung dieser Modelle zu suchen.
• Organisatorischer Aspekt der Umstellung auf den Einsatz von LCMS. Die Umstellung auf den Einsatz von LCMS kann eine erhebliche Veränderung der Struktur und sogar des Personals eines Ingenieurbüros bewirken: Nicht alle Bagger werden zu Baggern, nicht alle Taxifahrer zu Taxifahrern.

Entscheidend für das LCMS ist, wie die vorgeschlagene Lösung dazu beiträgt, Kollisionen frühzeitig zu erkennen und sogar zu verhindern. Wenn es um etwas anderes geht (sinnvolle Wahl des Lebenszyklustyps gemäß dem Risikoprofil des Projekts, Alterungsmanagement, Kostenmanagement und Budgetreform, axiomatisches Design beherrschen, Bauen mit Just-in-Time-Lieferungen, Design und Konstruktion generieren, und vieles, vieles mehr, auch äußerst nützlich-modern-interessant), dann geht es um andere Systeme, andere Projekte, andere Methoden, andere Herangehensweisen. Das LCMS sollte seine Arbeit gut machen und eine riesige Menge willkürlich ausgewählter Fremdaufgaben nicht schlecht lösen.

Der LCMS-Architekt hat also zwei Hauptaufgaben:

• bringen eine Reihe von Top-Kandidatenarchitekturen und deren Hybriden hervor
• Treffen Sie eine Auswahl nach mehreren Kriterien unter diesen Architekturen.
  • sinnvolle Betrachtung (Sinnhaftigkeit der Auswahlkriterien)
  • Präsentation des Ergebnisses (Begründung).

Kriterien für die Auswahl einer architektonischen Lösung für das LCMS

1. Die Qualität des LCMS erfüllt seinen Hauptzweck: Kollisionserkennung und -vermeidung Das Hauptkriterium lautet: Wie stark kann der Engineering-Fortschritt beschleunigt werden, indem die Kollisionserkennung oder -vermeidung mit der vorgeschlagenen LCMS-Architektur beschleunigt wird? Und wenn die Arbeitszeit nicht reduziert werden kann, um wie viel kann dann die Arbeitsmenge in der gleichen Zeit mit den gleichen Ressourcen erhöht werden? Die folgenden Methoden werden empfohlen:
   • Goldratts Theory of Constraints(TOC, Theory of Constraints) – Die Architektur sollte angeben, welche Systemeinschränkungen sie auf dem kritischen Ressourcenpfad eines Engineering-Projekts entfernt (nicht zu verwechseln mit dem kritischen Pfad).
   • ROI(Return on Investment) für Investitionen in das LCMS in der Phase der Formalisierung des Ergebnisses einer inhaltlichen Überprüfung der Kandidatenarchitekturen.
   Wichtig ist die Wahl der Betrachtungsgrenzen: Die Gesamtgeschwindigkeit eines Engineering-Projekts kann nur an der Grenze des betrachteten Organisationssystems gemessen werden. Die Grenzen einer einzelnen juristischen Person stimmen möglicherweise nicht mit den Grenzen eines erweiterten Unternehmens überein, das ein großes technisches Projekt durchführt, und ein Unternehmen, das nur an einer Phase des Lebenszyklus beteiligt ist, kann seine Nützlichkeit und Kritikalität für den gesamten Lebenszyklus falsch einschätzen des Systems und wählt den falschen Weg, sich in das LCMS zu integrieren. Dann kann sich herausstellen, dass die Erstellung des LCMS den Gesamtzeitplan und die Budgets des Projekts nicht beeinflusst, da die unangenehmsten Kollisionen weiterhin vom neuen LCMS nicht angegangen werden.
2. Möglichkeit zur Übernahme eines inkrementellen LCMS-Entwicklungslebenszyklus Inkrementell ist in der ISO 15288 ein solcher Lebenszyklus, bei dem die Funktionalität nicht auf einmal, sondern stufenweise an den Nutzer übergeben wird – aber auch Investitionen in die Entwicklung erfolgen nicht auf einmal, sondern stufenweise. Natürlich muss in diesem Fall das Gesetz des abnehmenden Nutzens berücksichtigt werden: Jede Erhöhung des LCMS (jede neue Art von Kollisionen im Voraus erkannt) ist teurer, und der Nutzen daraus wird bis zur Entwicklung immer geringer des seit vielen Jahren andauernden LCMS verblasst von selbst. Stellt sich heraus, dass für einige der vorgeschlagenen Architekturen auf einmal viel Geld in die Erstellung des LCMS investiert werden muss, der Nutzen aber sofort in Höhe von 100% und erst nach fünf Jahren schlüsselfertig erzielt werden kann Grundlage, dann ist dies eine schlechte Architektur. Wenn sich herausstellt, dass es möglich ist, einen kompakten LCMS-Kern zu entwickeln und in Betrieb zu nehmen, und dann viele, viele Module des gleichen Typs für verschiedene Arten von Kollisionen mit einem klaren Mechanismus für ihre Entwicklung (z. B. basierend auf der Verwendung von ISO 15926), dann ist das sehr gut. Es geht nicht so sehr darum, „agile Entwicklung“ (agile Methoden) anzuwenden, sondern eine modulare Architektur des LCMS bereitzustellen und einen Plan für die Implementierung einer priorisierten Liste von Modulen vorzuschlagen – zuerst die dringendsten, dann die weniger dringenden und so weiter an. Nicht zu verwechseln mit ICM (Incremental Commitment Model), obwohl die Bedeutung hier dieselbe ist: Die Architektur ist besser, bei der Sie eine Art Ratenzahlung für das System erhalten und die erforderliche Funktionalität so früh wie möglich erhalten - in um die Leistung (mindestens eine kleine) vorzeitig zu erhalten und die verspätete Leistung später zu zahlen.
3. Grundlegende finanzielle und intellektuelle Fähigkeit, Technologie zu beherrschen und zu warten Wenn wir die Kosten nicht nur für das LCMS selbst berechnen, sondern auch für das gesamte Personal und die sonstige Infrastruktur, die für die Umsetzung des Projekts erforderlich sind, müssen wir verstehen, wie viel von diesen Investitionen in Bildung, Computer und organisatorischen Aufwand für die übrig bleibt Zahler und Eigentümer des LCMS, und wie viel außerhalb abgerechnet wird - mit zahlreichen Auftragnehmern, die natürlich dankbar sein werden, zuerst ein "Stipendium" für die Entwicklung neuer Technologien zu erhalten und dann das von ihnen erstellte System zu unterstützen. Das Neue ist normalerweise extrem teuer, und zwar nicht, weil es an sich teuer ist, sondern weil es eine Lawine von Veränderungen verursacht, die es verursacht. An diesem Punkt berücksichtige ich die Total Cost of Ownership des LCMS, und derselbe Punkt beinhaltet die Betrachtung des gesamten Lebenszyklus, nicht mehr eines Engineering-Systems mit seinen vermeidbaren Kollisionen, sondern des LCMS selbst.
4. Skalierbarkeit der LCMS-Architektur Dieses Kriterium ist für große Ingenieurprojekte relevant. Da Sie möchten, dass das System von all den Tausenden von Menschen in der erweiterten Organisation verwendet wird, muss es schnell in diesem Umfang wachsen. Inwieweit kann der „Pilot“ oder „Polygon“ des LCMS ohne grundlegende Architekturänderungen schnell wachsen? Höchstwahrscheinlich werden sie nicht wachsen können. Daher brauchen wir architektonisch keinen "Piloten" oder "Polygon", sondern sofort eine "erste Stufe". Die Anforderung des Skalierungskriteriums überschneidet sich eng mit der Anforderung des Inkrementalitätskriteriums, betrifft jedoch einen etwas anderen Aspekt – nicht so sehr das zeitliche Dehnen der LCMS-Erstellung, sondern die Möglichkeit, das abgedeckte Volumen zu dehnen. Die Erfahrung zeigt, dass alle Systeme mit Testmengen an Konstruktionsdaten zurechtkommen, nicht aber mit industriellen. Wie werden die Kosten für Hard- und Software nicht-linear mit dem Volumen-/Geschwindigkeitswachstum steigen? Wie lange wird noch an Regelungen gearbeitet, wenn sich herausstellt, dass mehr Daten einen Arbeitsplatz durchlaufen, als von einer Person sinnvoll eingesehen werden können? Schlechte Skalierbarkeit kann nicht nur auf der technischen Seite der Architektur der Software- und Hardwarelösung lauern, sondern auch auf der Seite ihrer Finanzarchitektur. So kann ein geringer Lizenzpreis pro LCMS-Arbeitsplatz oder sogar ein geringer Preis pro neuer Verbindung auf dem Repository-Server eine mehr oder weniger attraktive Lösung für zehn Arbeitsplätze in eine finanziell absolut untragbare Lösung für die angepeilten tausend Arbeitsplätze verwandeln.
5. Fähigkeit, unvermeidliche organisatorische Herausforderungen anzugehen einschließlich Einstellungen gegenüber geliebten Legacy-Systemen in der erweiterten Organisation. Wie viel würde die vorgeschlagene zentralisierte oder verteilte Architektur erfordern, um „Funktionen an andere Abteilungen abzugeben“, „unsere Daten abzugeben“ und allgemein etwas „abzugeben“ im Vergleich zur aktuellen Situation ohne LCMS? Mainframes verloren massiv die Konkurrenz zu Mini-Computern und diese zu persönlichen. Es gibt fast keinen Weg zurück (zu zentralisierten Systemen, die das LCMS zwangsläufig darstellt), da sich alle Daten in separaten Anwendungen befinden und das Einziehen dieser Daten in neue Systeme eine sehr schwierige organisatorische Aufgabe ist. Wie ist die LCMS-Architektur aufgebaut: Ersetzt sie aktuelle Legacy-Engineering-Anwendungen, baut sie auf der aktuellen IT-Infrastruktur auf, wird sie „kostenlos“ von verschiedenen Diensten installiert? Wie viel Organisations-/Management-/Beratungsaufwand ist erforderlich, um neue Technologien durchzusetzen? Wie viele Leute müssen entlassen, wie viele neue Spezialisten gefunden und eingestellt werden? Dieses Kriterium der organisatorischen Akzeptanz steht nicht nur in engem Zusammenhang mit der Zentralisierung/Dezentralisierung, sondern auch mit der Berücksichtigung des Motivationssystems im erweiterten Unternehmen, d.h. Die Bewertung der LCMS-Architektur anhand dieses Kriteriums geht weit über eine enge Betrachtung des LCMS allein hinaus, sondern erfordert eine gründliche Analyse der Prinzipien des Aufbaus der erweiterten Organisation, bis hin zu und einschließlich der Überprüfung der Prinzipien, die den Verträgen zugrunde liegen, unter denen sie erstellt wurde. Aber das ist die Essenz des Systemansatzes: Jedes Zielsystem (in diesem Fall LCMS) wird zunächst nicht "in der Tiefe, aus welchen Teilen", sondern "nach außen, Teil von was" betrachtet - nicht sein Design und Wirkmechanismen sind primär interessant, werden aber unterstützt Das LCMS der Kollisionsvermeidungsfunktion im externen Supersystem - und der Preis, den das externe Supersystem bereit ist, für diese neue Funktion zu zahlen. Daher werden mögliche LCMS-Architekturen primär nicht im Hinblick auf „anständige verwendete Technologien, beispielsweise von Softwarehersteller XYZ“ betrachtet (dies ist die Voreinstellung: alle vorgeschlagenen Architekturen sind in der Regel technologisch anständig, sonst sind sie keine Optionen!), sondern im Hinblick auf die oben genannten fünf Kriterien.

LCMS-Funktionen

1. Kollisionsvermeidung
   1. Konfigurationsmanagement
      1. Identifikation (Klassifikationen, Kodierungen)
      2. Konfigurationsabrechnung (alle möglichen Baselines – ConOp, Architecture, Design, as built), einschließlich Datenübertragung zum LCMS-Repository, einschließlich Unterstützung für Workflow-Änderungen, einschließlich Unterstützung für paralleles Engineering (Arbeiten unter Bedingungen unvollständiger Baselines)
      3. Versionierung (einschließlich Forks)
   2. Fehlender manueller Datentransfer (Übernahme von Ein- und Ausgabedaten zwischen bereits bestehenden Automatisierungsinseln, einschließlich der Übernahme von Daten aus den Inseln des „Rise to Digital“ alter Designentwicklungen)
   3. NSI-Konfiguration
   4. Kollaboratives Engineering-Unterstützungssystem (Videokonferenzen, Remote-Projektsitzungen usw. - möglicherweise nicht das System, das zum Erstellen des LCMS-Systems selbst verwendet wird)
2. Kollisionserkennung
   1. Unterstützung für ein Register geprüfter Kollisionstypen und dem Register entsprechende Prüftechnologien
   2. Datenübertragung zur Überprüfung von Kollisionen zwischen Automatisierungsinseln (ohne Assemblierung im LCMS-Repository, aber mittels der LCMS-Integrationstechnologie)
   3. Ausführen eines Workflows zum Prüfen verschiedener Arten von Kollisionen
      1. im LCMS-Repository
      2. nicht in einem Repository, sondern mittels der LCMS-Integrationstechnologie
   4. Starten eines Laufs des Workflows zum Beheben der gefundenen Kollision (Versenden von Benachrichtigungen über Kollisionen, da der Lauf des zu lösenden Workflows nicht Sache des CLMS ist)
   5. Führen einer aktuellen Liste ungelöster Kollisionen
3. Entwicklung(hier wird das LCMS als autopoietisches System betrachtet, da „inkrementelle Implementierung“ eine der wichtigsten Eigenschaften des LCMS selbst ist – also eine Funktion des LCMS selbst und nicht eine Funktion des unterstützenden Systems für das LCMS)
   1. Gewährleistung der Kommunikation über die Entwicklung des LCMS
      1. Arbeitsplanung für die Entwicklung des LCMS (Roadmap, Entwicklung eines Aktionsplans)
      2. Arbeitsweise des LCMS-Projektbüros,
      3. Führen eines Verzeichnisses der Arten von Kollisionsprüfungen (das „Wunschlisten“-Register selbst und die Roadmap für die Durchführung von Prüfungen)
      4. Organisatorische und technische Modellierung (Enterprise Architecture) für LCMS
      5. Kommunikationsinfrastruktur für LCMS-Entwickler (Internetkonferenzen, Videokonferenzen, Wissensmanagement usw. – möglicherweise nicht diejenige, die beim Collaborative Engineering mit LCMS verwendet wird)
   2. Einheitlichkeit der Datenintegrationstechnologie (z. B. ISO 15926-Technologie)
      1. Verwendung eines neutralen Datenmodells
         1. Unterstützung von Referenzdatenbibliotheken
         2. Entwicklung von Referenzdaten
      2. Technologie zur Unterstützung von Adaptern zu einem neutralen Datenmodell
   3. Einheitliche Workflow-/BPM-Integrationstechnologie (unternehmensweit)
4. Datensicherheit(auf der Skala von Informationssystemen, die innerhalb des LCMS betrieben werden)
   1. Gewährleistung der Einheitlichkeit des Zugangs (ein Login und Passwort zu allen am Workflow beteiligten Informationssystemen)
   2. Zugriffsrechte auf Datenelemente verwalten
   3. Sicherung

Carolyn Pampino (IBM)
Anwendungsbasiert: Rational Team Concert Beta 3, Rational Quality Manager Beta 3, Beta 3

Rezension

Der harte Wettbewerb zwingt viele Unternehmen, Produkte in kürzerer Zeit zu entwickeln und sie gleichzeitig noch innovativer zu machen. Die Softwareentwicklung an sich ist eine komplexe Aufgabe, daher sind die Systeme, die von Organisationen erstellt werden, die Informationssysteme und -geräte entwickeln, ebenfalls äußerst komplex. Teams, die unter engen Fristen stehen, müssen dies tun, ohne die Qualität zu opfern oder das Budget zu erhöhen. Dazu sollte ihre Strategie darin bestehen, die Effizienz der Softwareentwicklung zu verbessern. Die Lösung für dieses Dilemma ist die Verbesserung der Lebenszyklusinteraktionen durch Application Lifecycle Management (LCM).

Zur Unterstützung von Softwareentwicklungsprojekten konzipiert, koordinieren Lösungen für das Application Lifecycle Management Personen, Prozesse und Tools in einem iterativen Softwareentwicklungszyklus, der die zugehörigen Aktivitäten der Planung, des Änderungsmanagements, der Anforderungsdefinition und -verwaltung, des Architekturmanagements, des Softwarekonfigurationsmanagements, des Aufbaus und der Bereitstellung umfasst Automatisierung, Qualitätsmanagement. Zusätzlich zu den Hauptfunktionen der LCA-Lösungen umfassen sie die Rückverfolgung zwischen Lebenszyklusartefakten, Prozessdefinition und -sicherung sowie Berichterstellung.

Der wichtigste Vorteil einer SPS-Lösung ist die Fähigkeit, die an einem Projekt beteiligten Personen, Prozesse, Informationen und Tools zu koordinieren, um innovative Produkte für die Projektbeteiligten zu erstellen. Da es keine Einheitslösung gibt, raten wir unseren Kunden, sich bei der Implementierung des Lebenszyklusmanagements, das am besten zur Kultur und Umgebung ihrer Organisation passt, auf die folgenden Prinzipien zu konzentrieren:

• Verwenden Sie Echtzeitplanung;
• Lebenszyklusverfolgung für verwandte Artefakte bereitstellen;
• Möglichkeiten zur Interaktion im Kontext bieten;
• Wenden Sie Geschäftsanalysen für die Entwicklung an;
• Kontinuierliche Verbesserung im Entwicklungsprozess implementieren.

Echtzeitplanung

Wir planen, weil wir ein bestimmtes Ziel erreichen wollen und wissen wollen, wann es erreicht sein wird. Es gibt nur einen Weg, um zu wissen, wann die Arbeit erledigt ist. Dazu muss sichergestellt werden, dass die Pläne vollständig in die Ausführung des Projekts integriert und immer auf dem neuesten Stand sind. In der folgenden Tabelle sind einige typische Planungsaktivitäten aufgeführt, die Sie durchführen oder unterlassen sollten.

Das folgende Bild zeigt, wie schnell das direkte Aktualisieren der aufgewendeten Zeit aus einem Arbeitselement es einfacher macht, Pläne genau zu halten.

Reis. 1. Die Aktualisierung der aufgewendeten Zeit von der Arbeitsaufgabe hält die Pläne genau

Die nächsten drei Bilder zeigen verschiedene Ansichten desselben Iterationsplans. Die Verwendung von Ansichten hilft dem Team, die Arbeit auszugleichen, effektiv zu planen und schneller auf Änderungen zu reagieren.

Reis. 2. Die geplante Zeitansicht zeigt, wann einige Teammitglieder mehr Arbeit haben als andere

Reis. 3. Die elektronische Taskboard-Ansicht kann von geografisch verteilten flexiblen Teams verwendet werden

Reis. 4. Entwicklungsplanansicht zeigt die Verteilung der Aufgaben nach Tag und Woche auf traditionellere Weise

Die folgende Abbildung zeigt einen Release-Plan in Rational Team Concert mit Links zum zugehörigen Product Backlog, Anforderungssammlungen in Rational Requirements Composer und einem Testplan in Rational Quality Manager .

Reis. 5. Zur Planung gehören Sammlungen von Anforderungen und Testplänen.

Die IBM Rational Collaborative Lifecycle Management-Lösung umfasst eine vollständig integrierte Echtzeitplanung.

Lebenszyklus-Trace

Tracing ist kein weiteres nettes „nice to have“-Feature im Lebenszyklus der Softwareentwicklung. Die Ablaufverfolgung hilft Ihnen zu verstehen, was alle anderen im Team tun. Beispielsweise weiß ein Anforderungsanalyst genau, welche Anforderungen er geschrieben hat, aber er muss auch wissen, ob eine bestimmte Anforderung bei einer bestimmten Entwicklungsiteration berücksichtigt wird, und wenn ja, bei welcher. Oder er will wissen, ob die Umsetzung dieser Anforderung getestet wurde und wie das Ergebnis ist.

Eine SPS-Lösung, die die Rückverfolgung zwischen Lebenszyklusartefakten ermöglicht, hilft Teams bei der Beantwortung schwieriger Fragen zum Status ihres Projekts. Das Erstellen von Verknüpfungen zwischen Artefakten erleichtert Teams die Beantwortung von Fragen wie: „Welche Anforderungen sind von Fehlern betroffen?“ und "Welche Workitems stehen zum Testen bereit?"

Reis. 6. Wichtige Fragen, die die LCA-Lösung beantwortet

Die Ablaufverfolgung hilft jedem Teammitglied zu verstehen, was der Rest des Teams tut und wie sich dies auf den Umfang der Arbeit als Ganzes auswirkt. Wenn Sie in einer extern gedrosselten Umgebung arbeiten, hilft Ihnen die Ablaufverfolgung bei der Beantwortung von Fragen von Prüfern wie „Welche Änderungen sind in diesem Build enthalten, welche Tests wurden ausgeführt und mit welchem ​​Ergebnis?“.

Im Folgenden finden Sie typische Gebote und Verbote im Zusammenhang mit der Ablaufverfolgung:

Das folgende Bild zeigt die Ablaufverfolgungsansicht für einen Versionsplan, der Anforderungen und Testfallzuordnungen enthält. Der Plan hat auch eine Spalte zum Anzeigen von Fehlern, die Elemente des Plans betreffen. Dies ist ein Beispiel für einen integrierten Plan mit Trace-Informationen. Im Gegensatz zu veralteten, regelmäßig generierten Trace-Berichten wird bei Verwendung eines integrierten Plans mit integrierter Trace-Ansicht das Fehlen von Artefakten offensichtlich und im Projekt leicht eliminiert.

Reis. 7. Release-Plan für Entwicklung, Anforderungen und Tests

Wenn Trace-Links hergestellt werden, erstellt IBM Rational Collaborative Lifecycle Management automatisch Trace-Links basierend auf Fehlern, die während des Tests identifiziert wurden. Das folgende Bild zeigt den Fehler mit dafür erstellten Routing-Links. Wenn Sie während des Testens einen Fehler hinzufügen, werden automatisch Trace-Links des Fehlers zu den Testergebnissen, dem Testfall, dem Testplan, dem Planelement und der Anforderung erstellt.

Reis. 8. Lifecycle-Links, die automatisch für einen Fehler generiert werden, zeigen Testfälle, Planelemente und davon betroffene Anforderungen an

Interaktion im Kontext

Die Interaktion beschränkt sich nicht auf die Aufrechterhaltung freundschaftlicher und funktionierender Beziehungen. Interaktion verbessert die Qualität und schafft einen Mehrwert für Stakeholder, was bedeutet, dass Interaktion für Innovationen wichtig ist. Möglichkeiten zur Zusammenarbeit in einer LCA-Lösung können die Fähigkeit von Teammitgliedern verbessern, miteinander zu kommunizieren, auf Änderungen zu reagieren und zur Vorhersagbarkeit von Projekten beitragen.

Außerdem helfen Collaboration-Tools Teams dabei, sich auf das Wesentliche zu konzentrieren. Teams sollten nach Möglichkeiten suchen, manuelle und nicht kreative Aufgaben zu automatisieren. Eine gute SPS-Lösung umfasst Automatisierung für Builds und Testausführung, sollte aber auch Automatisierung für Statusberichte und Informationszugriff umfassen. Projekt-Dashboards und persönliche Dashboards spielen eine wichtige Rolle, indem sie dem Team automatisch die benötigten Informationen zur Verfügung stellen, dem Team Sichtbarkeit und Zugriff auf aktuelle Daten durch Teamberichte und -abfragen bieten. Eine gut gestaltete Benutzeroberfläche automatisiert den Zugriff auf Informationen, indem sie Informationen direkt an die Benutzer liefert, ohne sie zu zwingen, den „Kontext zu ändern“, indem sie zu einer anderen Anwendung wechseln. In dieser Form trägt Automatisierung direkt zu einer besseren Interaktion bei.

Die folgende Abbildung zeigt eine Reihe von Dashboards mit Widgets, die Informationen aus Rational Team Concert, Rational Requirements Composer und Rational Quality Manager enthalten. Die Daten auf den Dashboards zeigen den aktuellen Status des Projekts.

Reis. 9. Dashboards mit Daten aus verschiedenen Quellen sorgen für Transparenz der Arbeit aller Funktionsteams

Das folgende Bild zeigt ein Mini-Dashboard, das immer an der Seite der Benutzeroberfläche verfügbar ist und links oder rechts angedockt werden kann. Es fungiert als personalisiertes Mini-Dashboard, das den Benutzer durch die LCA-Lösung begleitet und jederzeit ein- oder ausgeblendet werden kann.

Reis. 10. Mini-Panel, auf das von überall in der Benutzeroberfläche zugegriffen werden kann

Das folgende Bild zeigt die persönliche Minibar in Rational Team Concert. Diese Anzeige verfügt über ein Widget, das Änderungen an Anforderungen in Rational Requirements Composer anzeigt. Dies ist ein Beispiel für ein Mini-Panel mit Informationen aus verschiedenen Quellen. Wenn Sie den Mauszeiger über eine Anforderung bewegen, wird eine Vorschau mit Informationen zum Status der Anforderung im Requirements Composer angezeigt. Benutzer, die einen schnellen Zugriff auf Informationen benötigen, werden sich schnell an Mini-Panels gewöhnen.

Business Intelligence für die Entwicklung

Woher wissen Sie, ob etwas besser wird, wenn Sie keine Erfolgsmetriken definieren? Können Sie zu jedem Zeitpunkt in einem Projekt feststellen, ob sich das Team auf ein erfolgreiches Ergebnis zubewegt? Das Identifizieren von Bereichen, die verbessert werden müssen, das Setzen von Zielen und das Verfolgen des Fortschritts in Richtung dieser Ziele ist das, was bei der Entwicklung von Business Intelligence für die Entwicklung hilft.

Laut Capers Jones 1 sind Projekte, die Messpraktiken umfassend nutzen, viel erfolgreicher als solche, die dies nicht tun.

Reis. 12. Projekte, die Messverfahren verwenden, haben eine höhere Erfolgswahrscheinlichkeit

Beispielsweise werden die folgenden drei Metriken von weniger als 50 % der Forschungsorganisationen von Capers Jones verwendet:

• Qualitätskennzahlen 45 %
• Produktivitätsmetriken 30 %
• Bereitschaftsmetriken 15 %

Das Bild unten zeigt die Berichte für das Entwicklungsteam im Projekt-Dashboard. Wenn ein Arbeitselement aktualisiert wird, spiegeln die Berichte die Aktivität und Richtung des Teams wider. Verwenden Sie Fortschrittsdiagramme, um den Fortschritt Ihres Teams bis zum Abschluss geplanter Arbeiten zu verfolgen. Oder verwenden Sie alternativ Diagramme, die die Änderung der Anzahl der Arbeitsaufgaben in den Zuständen „Offen“, „In Bearbeitung“ und „Geschlossen“ zeigen (idealerweise die Anzahl der Aufgaben in den Zuständen „Offen“ und „In Bearbeitung“) abnehmen soll, während die im „Geschlossen“-Wachstum wachsen).

Reis. 13. Dashboard mit Berichten und Metriken zur Messung von Verbesserungen

Dashboards und Berichte sind eine Schlüsselkomponente der LCA-Lösung, die dafür verantwortlich ist, den aktuellen Fortschritt des Teams zu messen und darauf zu reagieren.

Kontinuierliche Verbesserung des Entwicklungsprozesses

Ein Prozess ist mehr als eine dokumentierte Reihe von Aktivitäten. Wir entwickeln Prozesse basierend auf Best Practices aus der Branchenerfahrung, um die Teamkommunikation zu verbessern und die Erfolgschancen des Teams zu erhöhen. Das Verhalten wird weitgehend durch Gewohnheit bestimmt. Wenn Sie einen Prozess definieren oder ändern, fordern Sie effektiv das gesamte Team auf, seine Gewohnheiten zu ändern und Verhaltensweisen anzunehmen, die ihm auf den ersten Blick möglicherweise nicht klar sind. Es ist ziemlich schwierig, die Gewohnheiten einer Person zu ändern. Die Änderung eines Prozesses erfordert oft eine Änderung der Denk- und Verhaltensweise der Menschen. Eine gut konzipierte LCM-Lösung ermöglicht es Ihnen, den Prozess schrittweise zu ändern, die Teamdynamik zu verbessern und sich weiter in Richtung größerer Effizienz zu bewegen.

Wenn man die Entwicklung des Marktes für Entwicklungstools in den letzten 10-15 Jahren analysiert, kann man einen allgemeinen Trend zur Verlagerung des Schwerpunkts weg von Technologien zum eigentlichen Schreiben von Programmen feststellen (die seit den frühen 1990er Jahren durch das Aufkommen von RAD-Tools - "schnelle Anwendungsentwicklung") auf die Notwendigkeit einer integrierten Verwaltung des gesamten Lebenszyklus von Anwendungen - ALM (Application Lifecycle Management) .

Mit zunehmender Komplexität von Softwareprojekten steigen die Anforderungen an die Effizienz ihrer Umsetzung stark an. Dies ist heute umso wichtiger, da Softwareentwickler in nahezu allen Aspekten der Arbeit von Unternehmen involviert sind und die Zahl solcher Spezialisten wächst. Gleichzeitig deuten Forschungsdaten in diesem Bereich darauf hin, dass die Ergebnisse von mindestens der Hälfte der „hausinternen“ Softwareentwicklungsprojekte die in sie gesetzten Hoffnungen nicht rechtfertigen. Unter diesen Bedingungen wird die Aufgabe, den gesamten Prozess der Erstellung von Softwarewerkzeugen unter Einbeziehung aller seiner Beteiligten – Designer, Entwickler, Tester, Supportdienste und Manager – zu optimieren, besonders dringlich. Application Lifecycle Management (ALM) betrachtet den Software-Release-Prozess als einen sich ständig wiederholenden Zyklus miteinander verbundener Phasen:

Definition von Anforderungen (Requirements);

Design und Analyse (Design & Analyse);

Entwicklung (Entwicklung);

Test, Test);

Bereitstellung und Wartung (Bereitstellung und Betrieb).

Jeder dieser Schritte muss sorgfältig überwacht und kontrolliert werden. Ein richtig organisiertes ALM-System ermöglicht Ihnen Folgendes:

Reduzieren Sie die Zeit, die benötigt wird, um Produkte auf den Markt zu bringen (Entwickler müssen sich nur um die Übereinstimmung ihrer Programme mit den formulierten Anforderungen kümmern);

die Qualität zu verbessern und gleichzeitig sicherzustellen, dass die Anwendung die Bedürfnisse und Erwartungen der Benutzer erfüllt;

Steigerung der Produktivität (Entwickler erhalten die Möglichkeit, Best Practices in Entwicklung und Implementierung auszutauschen);

Beschleunigen Sie die Entwicklung durch die Integration von Tools;

· Reduzierung der Wartungskosten durch ständige Aufrechterhaltung der Konsistenz zwischen der Anwendung und ihrer Konstruktionsdokumentation;

Holen Sie das Beste aus Ihrer Investition in Fähigkeiten, Prozesse und Technologie heraus.

Streng genommen ist das Konzept von ALM natürlich nichts grundlegend Neues - ein solches Verständnis der Probleme der Softwareentwicklung entstand vor etwa vierzig Jahren, zu Beginn der Herausbildung industrieller Entwicklungsmethoden. Bis vor relativ kurzer Zeit zielten die Hauptanstrengungen bei der Automatisierung von Softwareentwicklungsaufgaben jedoch darauf ab, Tools direkt für die Programmierung als die zeitaufwändigste Phase zu erstellen. Und erst in den 80er Jahren begann sich die Situation aufgrund der Komplikation von Softwareprojekten erheblich zu ändern. Gleichzeitig hat die Relevanz der Erweiterung der Funktionalität von Entwicklungswerkzeugen (im weiteren Sinne des Begriffs) in zwei Hauptbereichen stark zugenommen: 1) Automatisierung aller anderen Phasen des Softwarelebenszyklus und 2) Integration von Werkzeugen mit gegenseitig.

Viele Unternehmen haben sich mit diesen Aufgaben beschäftigt, aber der unangefochtene Marktführer war hier Rational, das sich seit mehr als zwanzig Jahren seit seiner Gründung auf die Automatisierung von Softwareentwicklungsprozessen spezialisiert hat. Einst war sie es, die zu einer der Pionierinnen in der weit verbreiteten Verwendung visueller Methoden zum Entwerfen von Programmen wurde (und praktisch zur Autorin der UML-Sprache, die de facto als Standard in diesem Bereich akzeptiert wird), eine gemeinsame ALM-Methodik schuf und ein entsprechendes Instrumentarium. Man kann sagen, dass Rational zu Beginn dieses Jahrhunderts das einzige Unternehmen war, das eine vollständige Palette von Produkten zur Unterstützung von ALM (vom Geschäftsdesign bis zur Wartung) in seinem Arsenal hatte, jedoch mit Ausnahme einer Klasse von Tools - gewöhnliche Programmierwerkzeuge. Im Februar 2003 hörte es jedoch auf, als unabhängige Organisation zu existieren, und wurde ein Geschäftsbereich der IBM Corporation mit dem Namen IBM Rational.

Bis vor kurzem war Rational praktisch der einzige Hersteller von integrierten Entwicklungswerkzeugen der ALM-Klasse, obwohl es für bestimmte Stufen der Softwareentwicklung konkurrierende Werkzeuge anderer Anbieter gab und gibt. Vor ein paar Jahren hat die Borland Corporation jedoch öffentlich ihre Absicht angekündigt, mit ihr zu konkurrieren, die schon immer eine starke Position im Bereich der traditionellen Anwendungsentwicklungstools (Delphi, JBuilder usw.) hatte, die eigentlich die Grundlage der ALM-Komplex der Corporation, der durch den Erwerb anderer Unternehmen, die ähnliche Produkte herstellen, erweitert wurde. Dies ist der grundlegende Unterschied in den Geschäftsmodellen der beiden Unternehmen, der potenzielle Chancen für echten Wettbewerb eröffnet. Nachdem Rational Teil von IBM wurde, positioniert sich Borland heute als einziger unabhängiger Anbieter einer umfassenden ALM-Plattform (d. h. es vermarktet keine eigenen Betriebssysteme, Sprachen usw.). Wettbewerber wiederum bemerken, dass Borland noch keine klare ALM-Methodik formuliert hat, die eine Grundlage für die Kombination der vorhandenen Tools bietet.

Ein weiterer wichtiger Akteur im Bereich der Entwicklungstools ist die Microsoft Corporation. Sie droht zwar nicht, ihre eigene ALM-Plattform zu schaffen; Die Förderung in dieser Richtung erfolgt nur im Rahmen der Zusammenarbeit mit anderen Lieferanten, den gleichen Rational und Borland (beide wurden die ersten Teilnehmer des Visual Studio Industry Partner-Programms). Gleichzeitig wird die Funktionalität des Flaggschiff-Entwicklungstools Visual Studio .NET von Microsoft durch den Einsatz von High-Level-Modellierungs- und Projektmanagement-Tools, einschließlich der Integration mit Microsoft Visio und Microsoft Project, ständig erweitert.

Es sei darauf hingewiesen, dass heute fast alle führenden Unternehmen, die Technologien und Softwareprodukte entwickeln (mit Ausnahme der oben aufgeführten, man kann Oracle, Computer Associates usw. nennen), über fortschrittliche Softwareentwicklungstechnologien verfügen, die sowohl selbst als auch durch den Kauf von entwickelt wurden Produkte und Technologien, die von kleinen spezialisierten Unternehmen entwickelt wurden. Und obwohl sie wie Microsoft noch nicht planen, eine eigene ALM-Plattform zu erstellen, werden die von diesen Unternehmen veröffentlichten CASE-Tools in bestimmten Phasen des Softwarelebenszyklus häufig verwendet.

ALM-Systeme ermöglichen es Ihnen, Transparenz und ein klares Verständnis des Anwendungsentwicklungsprozesses zu schaffen und ihn als einen der Geschäftsprozesse darzustellen. Allerdings sollte ALM nicht nur als Mittel zur Überwachung und Kontrolle der Compliance betrachtet werden, warnen Analysten. Diese Systeme dienen weniger der Steuerung als vielmehr der Automatisierung des Entwicklungsprozesses und der Integration verschiedener Tools.

Das größte Problem bei der Implementierung von ALM-Tools sind Menschen, die den Entwicklungsprozess nicht verstehen. Oft geht das Management davon aus, dass ALM in der Lage sein wird, Dinge in einem klar definierten Muster zu erledigen. Es ist jedoch unmöglich, alles im Voraus zu planen. Bei der Anwendungsentwicklung ist es oft notwendig, bei jedem Schritt mehrere Iterationen zu durchlaufen, Zwischenversionen freizugeben und die Funktionalität der Anwendung schrittweise zu erweitern. Das ALM-System sollte die Aktionen der Entwickler nicht einschränken, sondern den Prozess erleichtern.

Die IT-Branche spricht gerne über die Barrieren zwischen der IT und dem Unternehmen, aber innerhalb der IT-Organisation selbst gibt es viele weniger sichtbare Barrieren, die einem nachlässigen Systemintegrator im Wege stehen können.

Betrachten Sie zum Beispiel eines der kontroversesten und am heißesten diskutierten Themen in der heutigen IT – die DevOps-Methodik und alles, was damit zusammenhängt. Als kurze Beschreibung aller Handlungen, die mit der Übergabe der entwickelten Anwendung an den IT-Service für den Echtbetrieb verbunden sind, klingen diese Worte harmlos genug. Aber im Großen und Ganzen gibt es eine Wand aus Missverständnissen zwischen Entwicklern von Unternehmensanwendungen und Spezialisten, die die IT-Infrastruktur des Unternehmens verwalten. Programmierer beschuldigen die IT häufig für mangelnde Flexibilität und Personen, die den täglichen IT-Betrieb verwalten, dafür, dass sie die Einschränkungen und Anforderungen der Produktionsinfrastruktur ignorieren, auf der die von ihnen erstellten Anwendungen ausgeführt werden müssen.

Diese Spannung führt zu einem wachsenden Interesse an der Application Lifecycle Management-Technologie. ALM), bei der es sich um eine Reihe von Steuerelementen handelt, die Programmierern und IT-Mitarbeitern ein klareres Verständnis der Art der zu entwickelnden Anwendung und der Infrastruktur, auf der die Anwendung ausgeführt werden muss, vermitteln sollen. Die Hauptidee ist, dass die Erleichterung der Zusammenarbeit zwischen Entwicklern und IT-Experten zu einem effizienteren Funktionieren der gesamten Unternehmensinformationsumgebung führt. Das Problem ist, dass die Implementierung von ALM wenig Chancen hat, wenn die beiden Parteien, deren Zusammenarbeit für den Erfolg des Projekts notwendig ist, beginnen, die Verantwortung für die auftretenden Schwierigkeiten aufeinander abzuwälzen.

Um die ALM-Methodik erfolgreich zu implementieren, muss sich der Systemintegrator über die Ebene der Vorwürfe in der IT-Abteilung erheben. Laut Gina Poole, Vizepräsidentin für Marketing der Division IBM Rational-Software, bedeutet dies, einen IT-Leiter oder Finanzleiter zu finden und einzustellen, der nachvollziehen kann, wie viel Geld der Kunde aufgrund des Mangels an koordinierter Arbeit aller Dienste der IT-Abteilung verliert. Das späte Beheben von Fehlern in einer Anwendung in einem Entwicklungsprojekt bedeutet extrem hohe Kosten. Wenn die Notwendigkeit einer solchen Korrektur durch vorherige Annahmen des Entwicklers über das Umfeld, in dem die Anwendung betrieben werden soll, verursacht wird und sich diese Annahmen am Ende als falsch herausstellen, steigen die Kosten des gesamten Projekts erheblich oder der Kunde wird es tun gezwungen sein, seine Infrastruktur entsprechend aufzurüsten.

Natürlich kann die Lösung solcher Widersprüche in der IT-Infrastruktur eines Unternehmens eine beträchtliche Summe Geld kosten. Das einzige Endziel dieser Arbeit sollte jedoch darin bestehen, eine Reihe von Verwaltungstechnologien zu erstellen und zu implementieren, die es Programmierern und IT-Betriebsspezialisten ermöglichen, sich gegenseitig nicht mehr in die Arbeit einzugreifen. Je mehr Zeit Programmierer damit verbringen, die Zusammenarbeit mit der IT zu besprechen, desto weniger Zeit haben sie für die eigentliche Entwicklung. Je mehr Anwendungen erstellt werden, desto fortschrittlichere Infrastruktur wird benötigt, und das sind natürlich gute Nachrichten für Reseller.

Im Allgemeinen ist die DevOps-Debatte für Wiederverkäufer und Integratoren definitiv von Vorteil. Das Problem ist, sich nicht in die internen Konflikte zu verstricken, zu viele IT-Projekte parallel betreiben zu wollen. Wenn der Kunde das Konzept von ALM nicht akzeptiert, ist dies tatsächlich ein sehr guter Indikator für seine mangelnde Reife und schwache Kompetenz im IT-Management. Dies allein legt nahe, dass es für den Wiederverkäufer besser ist, sich von einem solchen Kunden fernzuhalten, da ein solcher Kunde höchstwahrscheinlich mehr Probleme als Gewinne bringen wird.