PALM - Die Integration von ALM und PLM
Von Stefano Rizzo
In den letzten zwanzig Jahren haben sich das Management des Produ...
2www.polarion.com
Software steuert den Produktentwicklungsprozess
Es lässt sich die These aufstellen, dass nun die Zeit fü...
3www.polarion.com
Integration von PLM und ALM
Wir haben bereits festgestellt, dass ALM- und PLM-Systeme sehr unterschiedli...
4www.polarion.com
Integrierte Zusammenarbeit
Sowohl bei der Software- als auch der Produktentwicklung arbeiten Entwickler ...
5www.polarion.com
Entwicklungsumgebungen wird sich das Software-Element (das ggf. wieder eine Komponente eines Bauteils is...
6www.polarion.com
Der in diesem Whitepaper vorgestellte PALM-Ansatz erfordert lediglich gute, moderne, robuste ALM- und PL...
7www.polarion.com
Die PALM-Roadmap
Da das PALM-Ziel ein sehr anspruchsvolles ist, teilt sich die PALM-Roadmap in 4 Schritt...
8www.polarion.com
Europe, Middle-East, Africa: Polarion Software GmbH
Kesselstraße 19 — 70327 Stuttgart, GERMANY
Tel +49 7...
Nächste SlideShare
Wird geladen in …5
×

PALM - Die Integration von ALM und PLM

392 Aufrufe

Veröffentlicht am

In den letzten zwanzig Jahren haben sich das Management des Produktentwicklungsprozesses, das dem Product Lifecycle Management (PLM) zugeordnet ist, und das Management des Software-Entwicklungsprozesses, das zum Bereich Application Lifecycle Management (ALM) Lösungen zählt, getrennt voneinander entwickelt. Das Ergebnis ist, dass PLM- und ALM-Lösungen heute in erster Linie in parallelen Umgebungen in der Produktentwicklung vorhanden und nicht gut integriert sind.

Lesen Sie in diesem Whitepaper, warum das Zusammenwachsen von PLM und ALM - von uns als „Product and Application Lifecycle Management” (PALM) bezeichnet – eine zukünftige Generation der Management-Kontrolle für Systementwicklung darstellt und wie Sie Ihre PALM-Roadmap auf den Weg bringen.

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
392
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
2
Aktionen
Geteilt
0
Downloads
6
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

PALM - Die Integration von ALM und PLM

  1. 1. PALM - Die Integration von ALM und PLM Von Stefano Rizzo In den letzten zwanzig Jahren haben sich das Management des Produktentwicklungsprozesses, das dem Product Lifecycle Man- agement (PLM) zugeordnet ist, und das Management des Software-Entwicklungsprozesses, das zum Bereich Application Lifecycle Management (ALM) Lösungen zählt, getrennt voneinander entwickelt. Das Ergebnis ist, dass PLM- und ALM-Lösungen heute in erster Linie in parallelen Umgebungen in der Produktentwicklung vorhanden und nicht gut integriert sind. In einem vorherigen Whitepaper „ALM und PLM – Ein erfolgreiches Team” haben wir die Gründe ermittelt, warum ALM-Disziplinen und -Lösungen in PLM-Plattformen integriert werden müssen. In diesem Whitepaper schauen wir uns die Bereiche PLM und ALM genauer an, entwickeln ein Geschäftsszenario für stärkere Integration zwischen den beiden Systemen und beschreiben Vision, Strat- egie und Plan zur Lösungsfindung eines einheitlichen Managements der Entwicklung von Produkten und Software. Wir sind der Meinung, dass das Zusammenwachsen von PLM und ALM - von uns als „Product and Application Lifecycle Management” (PALM) bezeichnet – eine zukünftige Generation der Management-Kontrolle für Systementwicklung darstellt. Polarion Software® Whitepaper Copyright © 2015 Polarion Software - Die Vervielfältigung und Weitergabe dieses Dokuments in unveränderter Form ist gestattet.
  2. 2. 2www.polarion.com Software steuert den Produktentwicklungsprozess Es lässt sich die These aufstellen, dass nun die Zeit für eine Integration zwischen PLM und ALM gekommen ist. Einer der Hauptgründe ist, dass Software schnell zu einem vorherrschenden Bestandteil technologisch anspruchsvoller Produkte wird und von einem System, das speziell für die Steuerung von Software entwickelt wurde, gesteuert werden muss. Als Unterstützung des Arguments für die Integration zwischen PLM und ALM können wir die Tatsache heranziehen, dass der Produktentwicklungsprozess zunehmend computergestützt ist. Als PLM zuerst als Disziplin entwickelt wurde, war der Prozess der Konzipierung, Entwicklung, Umsetzung und Instandhaltung eines Produkts ein rein physischer, der mit einem Zeichenbrett begann und physische Modelle, Prototypen usw. umfasste. Mit dem Aufkom- men der Digitalen Produktentwicklung (DPD) jedoch haben Hersteller nun diese physischen Methoden ersetzt durch computergestüt- zte Systeme wie Computer Aided Manufacturing (CAM) und Computer Numerical Control (CNC) Maschinen, die den Bedarf an der Herstellung physischer Prototypen verringern. Diese computergestützten Tools ermöglichen auch den Produktingenieuren, einen Produktentwurf iterativer zu entwickeln und häu- figer Änderungen vorzunehmen. Das Endergebnis dieser Computerisierung (neben den Vorteilen einer kürzeren Markteinführungszeit und besserer Produkte) ist die Tatsache, dass Produktentwicklungsteams nun wie ihre Softwareentwicklungsteams handeln und zusammenarbeiten sowie die Merkmale und Fähigkeiten, die in ALM-Systemen zu finden sind, neu schätzen lernen. PLM mag ein reiferer Markt sein, doch es kann viel von seinem jüngeren ALM-Pendant lernen und übernehmen. Virtuelle Entwicklungsumgebungen werden den Bedarf an physischen Prototypen verringern und die Entwicklungszeit für neue Produkte beschleunigen, während sie realistische Überprüfungen der Kundenanforderungen ermöglichen. Diese Umgebungen werden einen nahtlosen Produktinformationsfluss über alle Phasen des Systemlebenszyklus hinweg unterstützen , einschließlich Entwurf, Herstellung, Implementierung, Überprüfung und Auswertung sowie operative Unterstützung.ToolsdesWorkflow-Managementswerdendieglobalverteilten,zusammenarbeitenden Teams unterstützen, die diese virtuellen Entwicklungsumgebungen verwenden werden. INCOSE Systems Engineering Vision 2020 INCOSE-TP-2004-004-02 September, 2007
  3. 3. 3www.polarion.com Integration von PLM und ALM Wir haben bereits festgestellt, dass ALM- und PLM-Systeme sehr unterschiedlich sind und zur Steuerung unterschiedlicher Sachen entwickelt wurden. PLM Systeme sind darauf ausgerichtet, ein Produkt schneller auf den Markt zu bringen.ALM-Systeme sind darauf ausgerichtet, hochwertige Software zu entwickeln. Wir haben auch festgestellt, dass wenn ein Hersteller ein Produkt herstellt, das einen bedeutenden Anteil an Software beinhaltet, dieser Hersteller zusätzlich zu einem PLM-System ein ALM-System benötigt, um die Bereitstellung des ganzen Produkts effektiv zu steuern. Letztlich wissen wir, dass diese Systeme miteinander zusammen arbeiten müssen, um Software-intensive Produkte effektiv auf den Markt zu bringen und die Qualität dieser Produkte sicherzustellen. Nun möchten wir diese Integrationspunkte näher betrachten und die Möglichkeiten ausleuchten, diese zwei sehr unterschiedlichen Systeme zusammenzubringen. Eine gemeinsame Prozessschicht läutet den Wandel ein Die reiferen Anbieter von ALM haben in den letzten Jahren ihre Produktangebote weiterentwickelt, um zu einer integrierten, Prozess- zentrierten Lösung zu werden,die die Nachverfolgbrakeit und die Steuerung von Bausteinen über unterschiedliche Entwicklungsphasen hinweg ermöglicht. In solchen entwickelten Plattformen bestehen die ALM-Bausteine ohne Replika, sind versioniert, miteinander verbunden und gewährleisten Konsistenz über die Zeit und Veränderungen hinweg. Solche Merkmale erlauben eine bessere Trennung von Aufgaben zwischen Entwicklern und steigern erheblich ihre Verantwortung. Nicht zuletzt vereinfachen moderne ALM-Plattformen mittels der genannten Fähigkeiten stark die Überprüfung der Einhaltung bei diversen Zertifizierungsmaßnahmen, die durch die wachsende Anzahl an Industriestandards anstehen. Diese Prozessschicht bildet ein ideales „Rückgrat” oder eine gemeinsame Integrationsschicht zwischen PLM und ALM. Folglich ist davon auszugehen, dass ALM und PLM eine gemeinsame Prozessschicht teilen müssen, die Folgendes bietet: • Einzigartigkeit der Bestandteile • Workflowmanagement • Versionierung • Nachverfolgbarkeit • Change Management für jede Produkt- und Software-bezogene Information. Prozess Zusammenarbeit Anforderungen Qualitätssicherung PLM PALM ALM
  4. 4. 4www.polarion.com Integrierte Zusammenarbeit Sowohl bei der Software- als auch der Produktentwicklung arbeiten Entwickler miteinander und mit internen und externen Stakeholdern anhand von Spezifikationen, Diagrammen und Kommentaren zusammen. Sie arbeiten zusammen an unstrukturiertem Inhalt. Dieser Inhalt muss geteilt, abgerufen, geschützt, editiert und später wiederverwendet werden. Zusammenarbeit zwischen Entwicklern erfolgt heute durch gemeinsame Arbeitsplatz-„Tools” wie E-Mails, Chats,Telefonate, Meetings und letztliche durch das Teilen von Microsoft® Word Dokumenten, in denen Inhalt oft gelesen und schnell wieder vergessen wird. Das Problem mit dieser Art von Zusammenarbeit liegt in der Tatsache, dass diese Arbeitsplatz-„Tools” für gewöhnlich völlig von sowohl ALM- als auch PLM-Systemen und -Prozessen abgekoppelt sind. Des Weiteren findet viel Zusammenarbeit heute online und über mobile Endgeräte statt, sodass es folglich für moderne ALM/PLM- Systeme notwendig ist, sowohl Browser-basierten als auch Mobil-basierten Zugang zu Projektinhalt zu bieten. Die meisten älteren ALM-Plattformen und PLM-Systeme sind weit davon entfernt, diese Art von Fähigkeit zu erlangen. Ebenen der Zusammenarbeit, die eine moderne, voll integrierte ALM-Plattform bietet, lösen das Kommunikationsdilemma durch Bereitstellung von Web-basiertem und Mobil-basiertem Zugang zu Projektinhalt neben Funktionen für die Zusammenarbeit in Echtzeit zwischen Anwendern. Solche Schichten sollten spezifisch und geeignet für ALM- und PLM-Anwender sein, um dem Risiko des Verlustes oder duplizierter Daten infolge von Zusammenarbeit außerhalb dieser Systeme vorzubeugen. Integration in der Anforderungsphase In der Anforderungsphase existieren Anforderungs-getriebene ALM-Deliverables, Code oder PLM-Deliverables/Bauteile) parallel innerhalb eines einzigen, gemeinsamen Speicherorts. Diese Anforderungen bleiben ggf. über ihre Lebensdauer hinweg getrennt oder sie kommen ggf. zusammen (zum Beispiel wenn ein ALM-Deliverable Bauteil für PLM wird, wenn es auf einer PLM-Komponente installiert wird). Es ist auch möglich, dass eine Anforderung für einen ALM-Code ggf. mehrere Male wirksam eingesetzt wird, indem der gleiche Code zu unterschiedlichen “Bauteilen” auf unterschiedlicher Hardware oder Hardware mit einzigartigen Parametern wird. Integration in der Testphase Ähnlich können in der Testphase Testfälle geschrieben werden, um Hardware und Software Komponenten zu überprüfen. In agileren Natürlich besteht der Bedarf an einer gemeinsamen technischen Prozessschicht aus der Übersetzung in Werkzeugsätze des tatsächlichen Bedarfs, die als „tiefe Prozessintegration” bezeichnet werden kann. Wie wir im vorherigen Whitepaper der Reihe „ALM und PLM – Ein erfolgreiches Team” erörtert haben, gibt es eine klare Verbindung zwischen Schlanker Produktion für die Produktentwicklung und Agilen Methoden für die Software- Entwicklung. Schlank und Agil werden natürlich nur zusammenkommen, wenn wir eine Prozessintegrationsschicht entwickeln können, die ein einziges Prozessmanagement, einschließlich Arbeitsabläufe, Version und Change Management, erlaubt. Es gibt eine weitreichende Erörterung im Bereich Systemherstellung über den Bedarf an reifen und kohärenten Prozessen. Durch die Präzisierung von immer mehr formalen Proz- essvorlagen besteht aber auch eine bedeutende Konsequenz darin, dass die Entwickler im- mer mehr den Eindruck haben, dass ihr Talent für die Instandhaltung von Prozessen und die Sicherstellung von Einhaltungen statt für die Entwicklung von Innovationen eingesetzt wird. Einen perfekten Kompromiss bildet die Fähigkeit, die die meisten ALM-Systeme bieten, Prozesswissen im Werkzeugsatz einzubetten. Diese Fähigkeit erlaubt Entwicklern, sich auf ihre Arbeit zu konzentrieren, während das Tool sie durch den Prozess leitet. Hierfür wird eine gemeinsame Prozessschicht, die Prozesswissen einbettet, die perfekte Lösung sein. Der Bedarf für eine gemeinsamen Proz- essschicht, die einen einzigen Workflow sowie ein einheitliches Versions- und Konfigurationsmanagement bietet, wird nicht nur im Zusammenhang mit dem Zusammenwachsen von ALM und PLM diskutiert: Ein großer Hype mit dem Namen DevOps beschäftigt sich ebenfalls damit. Bei DevOps geht es darum, dass Soft- ware-Entwickler und IT-Spezialisten im Bereich Operations ihren Fokus auf Kommunikation, Zusammenarbeit und Integration legen.
  5. 5. 5www.polarion.com Entwicklungsumgebungen wird sich das Software-Element (das ggf. wieder eine Komponente eines Bauteils ist) häufiger wiederholen und ggf. QS und Testing an jedem Kontrollpunkt einbinden. Die mögliche Folge der Wiederverwendung der Softwareprüfungsmethoden in PLM wird sein, dass die zwei Zweige des weit verbreiteten V-Modells zu einem zusammenfallen werden, was einen höheren Grad an Agilität für die Systemherstellung bedeutet. Eine umfassendere Definition von Nachverfolgbarkeit Letztendlich schlagen wir vor, dass die PLM-Definition von Nachverfolgbarkeit über die heutige Aufspaltung der Produkte in Bauteile und Komponenten ausgedehnt werden sollte, um die Nachvollziehbarkeit nach ALM-Art, die Verbindungen zwischen Dateien/ Bausteinen und Hardware Komponenten aufzeigt, sowie den Einfluss von Veränderung auf jeder an zugehörigen „Bauteilen” oder dem System als Ganzem einzubinden. Einige PLM-Anbieter werden argumentieren,dass sie Nachverfolgbarkeit in ihren aktuellen Systemen durch Integration mit quelloffener Versionierung oder Softwarekonfiguartionsmanagement-Tools wie Subversion oder Perforce bieten. Diese Integrationsform bietet Verbindungen zu Embedded-Softwarecode von Modellen innerhalb des PLM-Systems. Auch wenn diese Einstiegsebene der Integration ein Schritt in die richtige Richtung ist, erreicht sie nicht den in PALM geplanten Reifegrad, der über die einfache Fähigkeit, ein UML-Modell (oder andere) mit einem Code zu verknüpfen, um Zusammenarbeit in Echtzeit ortsungebunden mit jedem Gerät zu ermöglichen und Einflussanalysen über die unterschiedlichen Bausteine hinweg, die zu unterschiedlichen Prozessabschnitten (von Anforderungen bis zu Aufgaben, von Testfällen bis zu Fehlern, von Änderungsanforderungen bis zu Testplänen, von Maßnahmen bis zu Codes) gehören, durchzuführen. Ein zentralisierter und einheitlicher Speicherort ALM-Anbieter arbeiten momentan an Standardisierungsinitiativen wie Open Services for Lifecycle Collaboration (OSLC)1, um ihre getrennten ALM-Komponenten zu integrieren und eine Spezifikation zu definieren, die einen Ansatz für gemeinsame Integration und Datenaustausch, der auch bereit ist für eine PLM-Integration, festzulegen. Jedoch befasst sich diese bemerkenswerte und vielversprechende Initiative, abgesehen von der Tatsache, dass sie noch sehr neu und noch nicht weithin anerkannt ist, nicht mit dem Problem der Datenreplikation. Wir haben dies erörtert - um eine gute Integration zwischen ALM und PLM zu erreichen, benötigen wir eine gemeinsame Prozessschicht, die Zusammenarbeit, gemeinsames Workflow, Version, Change, Nachverfolgbarkeit- und Testmanagement bietet. OSLC wurde ins Leben gerufen, um eine gute Integration zwischen unterschiedlichen Tools, die dem Markt durch fusionierte ALM-Anbieter zur Verfügung gestellt werden, zu liefern. Solche Anbieter haben sich mit dem Bedarf an einer gemeinsamen Integrationsschicht zwischen ihren eigenständigen Tools, die einzelne Funktionen für jede eigene Disziplin bieten, befasst. Kürzlich wurden die Bemühungen von OSLC ausgedehnt, um die ALM/PLM-Integration abzudecken durch einen Standardweg zur Verknüpfung von ALM und PLM Komponenten zur Unterstützung von Anwendungsfälle wie „A Systems Engineer responds to a change in requirements for an existing product release”. Moderne ALM-Systeme beruhen nicht auf Datenreplikation oder proprietären Speicherverfahren. Dies bedeutet, dass jeder Baustein, wie ein Dokument, ein Bericht oder ein Stück Softwarecode, innerhalb eines einzigen Ortes (gemeinsamer Speicherort) ggf. abgerufen, verknüpft, verändert, analysiert, behandelt, wiederverwendet, instand gehalten, eliminiert, zusammengestellt und von Fehlern befreit werden kann und für Benutzer entweder eines ALM- oder eines PLM-Systems zugänglich ist. Der Ansatz eines zentralisierten und einheitlichen Speicherorts liefert das wahre „Geheimnis” der PLM/ALM-Integration. Von überall auf der Welt und zu jeder Zeit können Produkt- und Softwareentwickler auf Produkt-bezogene Informationen zugreifen, sie teilen und gemeinsam daran arbeiten. Diese prinzipiell mögliche Integrationsebene scheint kurzfristig schwierig zu erreichen. Somit besteht unser Ansatz in dem Vorschlag, mit den Mindestfunktionen zu beginnen, die in ein Integrationsrückgrat eingebunden werden müssen. 1) Open Services for Lifecycle Collaboration (OSLC) http://open-services.net/about/ is a community of software developers, operations experts, and organizations that are working to standardize the way that software lifecycle tools (such as ALM, PLM) can share data with one another.
  6. 6. 6www.polarion.com Der in diesem Whitepaper vorgestellte PALM-Ansatz erfordert lediglich gute, moderne, robuste ALM- und PLM-Systeme und eine minimale gemeinsame Schicht der gemeinsamen Daten (PALM-Rückgrat, das der Zusammenarbeit, dem Versions- und Change Management, der Workflow-Unterstützung, dem Nachverfolgbarkeits- und Anforderungsmanagement, der Überprüfung und der Qualitätssicherung gewidmet ist), um eine innovative und einzigartige Umgebung für die Zusammenarbeit zu erschaffen, die der umfassenden Verbesserung der System- und Produktqualität dient. Ist OSCL einmal weithin anerkannt, könnte OSCL von der PALM- Schicht als Standardintegrationsweg mit allen ALM- und PLM-Tools verwendet werden. Das PALM-Rezept 1. Entwicklung einer gemeinsamen Integrationsschicht (PALM-Rückgrat) zwischen PLM/ALM-Systemen 2. Verknüpfung der Management-Disziplinen Prozessunterstützung, Zusammenarbeit, Anforderungen und Überprüfung, um Software und Hardware unter ein Dach zu bringen. 3. Einführung einer umfassenderen Definition von Nachverfolgbarkeit für PLM, um die breite Wirkung von Veränderungen innerhalb des Systems als Ganzem aufzuzeigen. 4. Errichtung einer neuen, einheitlichen PALM-Plattform zur Steuerung und Verwaltung Software-intensiver Produkte. Vorteile der PALM-Plattform für den Endanwender • Verbesserte Teamarbeit hinsichtlich Produktspezifikationen,Anforderungsdefinition,Testfallerstellung und Projektfortschritt durch einen universellen Web-Zugang und Zugang über mobile Endgeräte. • Größere Fähigkeit, Veränderungen an Software und Hardware sowie die diese Veränderungen herbeiführenden Gründe durch verknüpftes Versions- und Change Management zu verfolgen. • Größere Fähigkeit zurAnalyse derAuswirkungen derVeränderung an Software- und Hardware-Komponenten und zur Feststellung von Spezifikationen, die durch einheitliche Nachverfolgbarkeit für Software und Hardware nicht erfüllt werden. • Der Software/Hardware-Produktlebenszyklus wird als eigenständige Disziplin durch einen einheitlichen Speicherort und Werkzeugsatz behandelt. Dies bedeutet, dass wir auf der PALM-Plattform gemeinsame Ansätze und Methoden zur Lenkung der Software- und Produktentwicklung definieren können. Solche Methoden können von der Verbindung eher herkömmlicher Wasserfallmodelle in ALM mit V-Modellen in PLM oder von der Verbindung modernen Agiler ALM-Ansätze mit Schlanker Produktion stammen. Im besten Fall wird jedes Unternehmen seine eigenen Methoden definieren oder vorhandene bewährte Verfahren an seine Bedürfnisse an einem einzigen Ort anpassen können und gleichzeitig die gesamte Produktentwicklung (mit Software und Hardware) steuern. Vorteile der PALM Plattform für den Produkthersteller • VerbesserteQualitätdurchverknüpftesManagementallerKomponenten(SoftwareundHardware)desProduktentwicklungsprozesses. • Weniger Produktrückrufaktionen durch oben genannte verbesserte Qualität. • Schnellere Lösungszeit durch bessere und lückenlosere Nachvollziehbarkeit. “Dies ist eine ausgezeichnete Gelegenheit für Polarion, um eine Brücke zwischen den Welten von ALM und PLM zu schlagen: Embedded-Software ist heutzutage entscheidend für den Produktbetrieb und PLM benötigt die Reife, die ALM bei der Steuerung von Software-Elementen bieten kann.” Michael Azoff, Chefanalyst, Ovum
  7. 7. 7www.polarion.com Die PALM-Roadmap Da das PALM-Ziel ein sehr anspruchsvolles ist, teilt sich die PALM-Roadmap in 4 Schritte.Am Ende jeden Schrittes wird der Anwender von integrierten Merkmalen, wie unten dargestellt, profitieren: Um zu einer integrierten PALM-Lösung zu gelangen,sollten ALM- und PLM-Anbieter zusammenarbeiten für die: • Festlegung einer Roadmap, die mittelfristig zur Entwicklung eines logisch einzigartigen Speicherorts führt, wo PLM- und ALM-Informationen aufgenommen werden können • Erzeugung neuer gemeinsamer Prozesse zur Steuerung der Produkt- und Software-Entwicklung, indem gemeinsame Merkmale und Funktionen zwischen den Disziplinen (ALM-Arbeitsbausteine, PLM-Bauteile/Komponenten, Berichte) wirksam eingesetzt werden. PLM-Anbieter sollten: • Schlüsselmethoden wie Nachverfolgbarkeit und Change Management, die innerhalb der ALM-Disziplin entwickelt und erprobt wurden, einbinden • durch offene Programmierschnittstellen Integrationspunkte erzeugen, um eine Brücke zwischen PLM- und ALM- Funktionalität zu schlagen, indem ein gemeinsamer Speicherort erzeugt wird und PLM-Bauteile und -Komponenten mit ALM-Prozessen und -Arbeitsbausteinen verbunden werden • durch offene Programmierschnittstellen Integrationspunkte erzeugen, um eine Brücke zwischen PLM- und ALM- Funktionalität zu schlagen, indem ein gemeinsamer Speicherort erzeugt wird und PLM-Bauteile und -Komponenten mit ALM-Prozessen und -Arbeitsbausteinen verbunden werden ALM-Anbieter sollten: • alle Integrationen, Lücken und Fehlausrichtungen unter den Komponenten ihrer ALM-Werkzeugsätze eliminieren • durch offene Programmierschnittstellen Integrationspunkte erzeugen, um eine Brücke zwischen PLM- und ALM- Funktionalität zu schlagen, indem ein gemeinsamer Speicherort erzeugt wird und PLM-Bauteile und -Komponenten mit ALM-Prozessen und -Arbeitsbausteinen verbunden werden • eine Migration der ALM-Daten in einen gemeinsamen PALM-Speicherort in Erwägung ziehen Gemeinsamer PALM-Speicherort, in dem sich alle Bestandteile befinden Zusammenarbeit Workflow-Unterstützung Nachverfolgbarkeit Qualitätssicherung ProzesseTesting Anforderungen + + + + + + Versionierung Changes
  8. 8. 8www.polarion.com Europe, Middle-East, Africa: Polarion Software GmbH Kesselstraße 19 — 70327 Stuttgart, GERMANY Tel +49 711 489 9969 - 0 Fax +49 711 489 9969 - 20 www.polarion.com - info@polarion.com Americas & Asia-Pacific: Polarion Software, Inc. 1001 Marina Village Parkway, Suite 403, Alameda, CA 94501, USA Tel +1 877 572 4005 Fax +1 510 814 9983 www.polarion.com - info@polarion.com Zusammenfassung Software übernimmt in zunehmendem Maße die Vorherrschaft der Hardware bei der Produktentwicklung. Dies trifft insbesondere auf technologisch hoch entwickelte Produkte zu (wie Kraftfahrzeuge, Flugzeuge, medizinische Geräte und Smartphones). Produktingenieure müssen aktiv auf die Suche nach Tools gehen, die jenseits ihrer üblichen PLM-Systeme liegen und Disziplin- übergreifende Zusammenarbeit erlauben – insbesondere mit Pendants der Software-Entwicklung – zur Sicherstellung des End- to-End-Managements von Softwarekomponenten sowie Hardwarekomponenten. PLM-Anbieter sollten versuchen, ALM-Systeme zur Steuerung des Softwareentwicklungsprozesses zu integrieren, um eine ganzheitliche Lösung zu bieten. Zuverlässige Nachverfolgbarkeit über unterschiedliche Produkt- (Hardware und Software) Versionen, Konfigurationen und Varianten instand zu halten ist eine schwieriger werdende Aufgabe und wird die heutigen PLM-Systeme und -Anbieter vor eine Herausforderung stellen. Da der Produktentwicklungsprozess zunehmend virtualisiert wird, wird auch der gesamte Prozess zunehmend iterativ und inkrementell und verlangt darüber hinaus eine Integration zwischen PLM- und ALM-Disziplinen und -Systemen. PLM kann von ALM- Konzepten profitieren, wie zum Beispiel von der erweiterten Definition der Nachverfolgbarkeit dieser Disziplin. Die Lösung wird nicht in einem einzigen übermäßig komplexen System, das PLM- und ALM-Funktionen einbindet, zu finden sein. Es ist äußerst unwahrscheinlich, dass die heutigen ALM-Systeme sich dahingehend entwickeln werden, dass sie PLM-Merkmale einbinden. Sollten PLM-Anbieter versuchen, sich weiter zu entwickeln, um sich mit den speziellen durch ALM-Systeme gelöste Problemen auseinander zu setzen, sind sie schlecht ausgerüstet für die Aufgabe und werden wahrscheinlich bei diesem Versuch scheitern. Das wahrscheinlicherer Szenario ist, dass ALM, da Software nur eine „Komponente” eines Produkts ist, ein „Teilsystem” innerhalb der PLM-Disziplin werden wird. Diese Verbindung wird durch eine Integration zwischen PLM und ALM erreicht und wird rechtzeitig ein neues einheitliches Product and Application Lifecycle Management System (PALM) hervorbringen, das gezielt ins Leben gerufen wird, um die Entwicklung von Software-intensiven, technisch anspruchsvollen Produkten zu steuern. Über Polarion Software Polarion Software ist ein führender Anbieter einer durchgängigen und zu 100% Browser-basierten Plattform für Anforderungs-,Test- und Application-Lifecycle-Management (ALM). Polarion wird von globalen Unternehmen in einer Vielzahl von Branchen eingesetzt, wie zum Beispiel im Automobilbau, in der Medizintechnik und in der Luft- und Raumfahrt. Kunden erzielen mit Polarion die für die Herstellung Ihrer Produkte nötige Agilität, Traceability und Compliance. Käufer der mit Polarion entwickelten Produkte erwarten eine herausragende Qualität und Sicherheit. Mehr als 2,5 Millionen Anwender weltweit vertrauen deswegen auf Polarion, um die Zusammenarbeit in ihren Unternehmen voranzutreiben, ALM und Product Lifecycle Management (PLM) zu verküpfen und um ihre hochwertigen Produkte auf den Markt zu bringen. Weitere Informationen unter: www.polarion.com

×