ALM und PLM - Ein erfolgreiches Team

599 Aufrufe

Veröffentlicht am

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).

System- und 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.

Erfahren Sie in diesem Whitepaper, worin sich die Disziplinen Software-Entwicklung und Produktentwicklung unterscheiden und warum ihr Zusammenwachsen einen entscheidenden Wettbewerbsvorteil für produzierende Unternehmen darstellt.

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
599
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
14
Aktionen
Geteilt
0
Downloads
8
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

ALM und PLM - Ein erfolgreiches Team

  1. 1. ALM und PLM – Ein erfolgreiches Team Von Stefano Rizzo Software übernimmt zunehmend die vorherrschende Position der Hardware im Produktentwicklungsprozess,insbesondere im Rahmen technologisch anspruchsvoller Produkte und Branchen wie der Automobil-, Luftfahrt-/Verteidigungsindustrie und der Fertigung medizinischer Geräte. Technologiehersteller sind üblicherweise zu Product Lifecycle Management (PLM) Lösungen übergegangen, um Markteinführungszeiten zu beschleunigen, Prozesse effizienter zu gestalten, Zusammenarbeit zu verbessern und die Erfüllung gesetzlicher Anforderungen zu gewährleisten. Herkömmliche PLM-Systeme haben jedoch mit dem Software-Management und dem eigenen aufwendigen Entwicklungsprozess im Rahmen des Produktentwicklungsprozesses zu kämpfen. Software ist schon auf einer viel tieferen Ebene vorhanden - sie bildet eine Komponente innerhalb eines PLM-„Bauteils”. Software hat in diesem Zusammenhang ihren eigenen Lebenszyklus - mit unterschiedlichen zu verwaltenden Informationen, unterschiedlicher Zusammenarbeit, unterschiedlichen Spezifikationen und Bausteinen - und diesem Lebenszyklus werden PLM-Lösungen nicht ausreichend gerecht. In diesem Whitepaper aus der ALM/PLM-Reihe - werden wir: • die Unterschiede zwischen ALM und PLM analysieren • darlegen, warum ALM nicht für PLM verwendet werden kann • darlegen, warum PLM nicht für ALM verwendet werden kann • die Gründe aufzeigen, warum eine Zusammenarbeit zwischen ALM und PLM notwendig ist 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 PLM und ALM - Definition der Systeme Was ist PLM? PLM umfasst den Steuerungsprozess des gesamten Lebenszyklus eines Produkts von seinem Entwurf über die Konstruktion und Fertigung bis hin zu Service und Abkündigung. PLM verbindet Menschen, Daten, Prozesse und Geschäftssysteme und bildet einen Pfeiler der Produktinformation für Unternehmen und ihre ausgebauten Unternehmensbereiche. PLM-Systeme unterstützen Abteilungen bei der Bewältigung steigender Komplexität und Engineering-Herausforderungen im Rahmen der Entwicklung neuer Produkte für die globalen wettbewerbsorientierten Märkte durchVerkürzung undVereinfachung jeder Phase des Produktentwicklungsprozesses, bringen Produkte schneller auf den Markt, erfüllen zunehmend strenge Compliance-Anforderungen und Industriestandards und führen zu besserer Zusammenarbeit und Kommunikation über den Produktentwicklungsprozess hinweg. Die Marktkategorie für PLM kam zum ersten Mal 1985 auf, inspiriert durch die American Motor Corporation (AMC), als Möglichkeit zur Beschleunigung des Produktentwicklungsprozesses und besseren Wettbewerbsfähigkeit auf dem Automobilmarkt. PLM wird heute weiterhin hochwirksam in der Automobilindustrie eingesetzt, hat aber auch Einzug gehalten in Branchen wie Luftfahrt/ Verteidigung, Gesundheit, Medizingeräte, Prozessfertigung (Nahrungsmittel, Chemie) und Energie. Was ist ALM? “Application Lifecycle Management (ALM) ist kein Produkt, sondern ein Prozess”, stellt das Marktforschungsunternehmen Ovum in seinem Software Lifecycle Management Bericht 2011 fest. Des Weiteren definiert Ovum ALM als Prozess, durch den IT und Softwa- reentwicklungsunternehmen Software über ihren gesamten Lebenszyklus hinweg entwickeln, einsetzen und betreiben.1 1) Ovum, Software Lifecycle Management 2011
  3. 3. 3www.polarion.com Vergleich von ALM-und PLM-Lebenszyklusphasen Projekt- und Portfoliomanagement von Anwendungen 1 4 2 5 3 6 Entwurf und Anwendungsfallanalyse Vor Beginn eines Softwareprojekts wird eine Investitionsanalyse durch- geführt und ein Geschäftsszenario entwickelt. Die zugrunde liegende Architektur des Softwarecodes wird aufgestellt und unterschiedliche Anwend- ungsfälle werden entwickelt, um die möglichen Interaktionen des Nutzers mit dem endgültigen Sys- tem zu veranschaulichen. Marktdaten werden gesammelt, po- tenzielle Anwender/Software-Kun- den werden befragt und Daten zur Ausgestaltung von dokumentierten Anforderungen werden gesammelt. Der Anwendungscode wird ge- schrieben oder im Falle einer Ver- besserung erweitert oder überprüft. Da Anforderungen entstehen oder sich verändern, muss auch das Anforderungsdokument weiterent- wickelt werden, um die Auswirkun- gen auf Entwicklungszeitpläne, Lieferfristen, Ressourcen usw. zu analysieren. Die Software wird systematisch von Fehlern befreit, Leistungs-, Last- und Stresstests werden durchge- führt und notwendige Überarbeitun- gen vorgenommen. Projektbeginn und Anforderungserfassung Code-Erstellung Anforderungsmanagement Testmanagement/QS ALM-Phasen 7 8 Fertigungsfreigabe, Einsatz Die Endfreigabe wird erarbeitet, die Freigabe wird abgeschlossen und die Anwendung wird in der Produktion eingesetzt. Die fortlaufende Instandhaltung der Anwendung - einschließlich der Verbesserung der Fehlerbehebung über den Anwendungslebenszyklus hinweg bis zum Ende der Lebens- dauer. Anwendungsleistung Schlüsselbotschaft Auch wenn Software-Entwicklung einem kaskadenförmigen Wasserfallmodell folgen kann, bedeutet die weit verbreitete Anerkennung der agilen Entwicklungsmethodik, dass Software iterativer entwickelt wird - in kurzen, schnellen „Sprints” mit sich häufig wandelnden Anforderungen und vielen permanenten Überarbeitungen. Schlüsselbotschaft Der PLM-Prozess ist für gewöhnlich oder in erster Linie wasserfallartig im Gegensatz zu iterativen Modellen und nimmt nicht einfach inkrementelle Veränderungen innerhalb des Prozesses auf. Konzeption Dienstleistungen 1 4 2 3 Informationen vom Markt werden gesammelt, Kundenanforderungen festgelegt und die Idee für das Produkt entwickelt sowie auf diesen Informationen basierende technische Spezifikationen angelegt. In dieser finalen Phase des Produktlebenszyklus gehen wir in die Dienstleistungsphase über, die Reparatur und Instandhaltung, Abfallmanagement und Lebensende (Abkündigung, Vernichtung) des Produkts umfasst. Der Erstentwurf des Produkts wird entwickelt, verfeinert, überprüft und bestätigt unter Verwendung von Tools wie CAD. Dieser Schritt umfasst eine Reihe von Engineer- ing-Disziplinen, einschließlich mechanische, elektrische und elek- tronische und (Embedded) Software, sowie anwendungsspezifisches Know-how, wie Automobiltechnik. In diesem Stadium ist der Produktentwurf abgeschlossen und die Herstellungsmethode festgelegt, mit auf diese Phase ausgerichteter Tool-Gestaltung,Analyse,Simulation und Ergonomieanalyse. Entwurf Umsetzung PLM-Phasen
  4. 4. 4www.polarion.com Ein genauerer Blick auf die Ähnlichkeiten und Unterschiede zwischen PLM und ALM Zur Erstellung eines effektiven Geschäftsszenario für Integration ist ein Verständnis der Ähnlichkeiten und Unterschiede zwischen PLM und ALM entscheidend. Dies ermöglicht uns, die grundlegende Ausrichtung jedes Systems, wo die Systeme voneinander profitieren können, zu verstehen und die richtigen Aspekte für Integration auszumachen. Bauteile vs. Dateien Der erste Unterschied besteht in der Tatsache, dass ein PLM-System sich an den „Bauteilen” orientiert, die hergestellt werden, um ein physisches Produkt herzustellen, wohingegen sich ein ALM-System am Management von Softwaredateien/-bausteinen (ein Anforderungsdokument oder ein Stück Softwarecode oder ein Testfall) und entsprechend an der Veränderung dieser Dateien orientiert. Browser-basierte Web-Collaboration Die ALM-Disziplin befand sich herkömmlicherweise innerhalb der Abteilung für Software-Entwicklung. In den letzten Jahren sind ALM- Daten jedoch für eine zunehmend große Anzahl an Stakeholdern wertvoll geworden. Die Reichweite von ALM dehnt sich auf neue Disziplinen über die Software-Entwicklung hinaus aus und mit einer größeren Anzahl an Stakeholdern entsteht ein erhöhter Bedarf an einfachem Echtzeit-Zugang zu Daten, typischerweise über eine Browser-Schnittstelle. Doch Web-basierte Zusammenarbeit unter Teammitgliedern ist eine der meist entscheidenden Hürden, denen übliche PLM-Anbieter gegenüberstehen, denen es im Gegensatz zu AML-Anbietern nur gelungen ist, einen Teil ihrer Lösung an das Web anzubinden. Es ist heute zum Beispiel nicht möglich, für einen Nutzer ein detailliertes 3D-Rendering und eine detaillierte Stückliste (BoM) mit Traceability-Links eines Fahrzeuggetriebes, das in China von einem sich in Stuttgart befindenden Server dargestellt wird, zu erstellen. Diese Art von Leistungsfähigkeit ist ohne die Integration mit ALM einfach Jahre entfernt. Schlanke Produktion und Agile Software-Entwicklung In den Neunzigern führte das Toyota-Produktionssystem das Konzept der Schlanken Produktion als Managementphilosophie zur Verbesserung des Mehrwerts für den Kunden ein. Toyota konnte durch diese Philosophie von einem kleinen Unternehmen zum größten Hersteller der Welt heranwachsen. Kurz gesagt, Schlank ist jedes Produktionsverfahren, das Mehrwert für den Kunden schafft, d. h. etwas für das der Kunde bereit ist zu zahlen. Alles andere landet im Müll. Wir können hier behaupten, dass Agile Entwicklung von der Schlanken Produktion abgeleitet wurde, zumindest aus einem philosophischen Blickwinkel heraus betrachtet: In Agilen Methoden befinden sich die Nutzer im Zentrum des Entwicklungsuniversums und sie legen fest, welche Elemente es wert sind, eingebunden zu werden. So liegt die Schlussfolgerung nahe, dass die Integration von ALM- und PLM-Systemen aus Gründen der Integration von Produkt- und Software-Entwicklungsmethoden miteinander einhergehen muss. Es wird eine natürliche Entwicklung sein, dass die Schlanke Produktion und die Agile Entwicklung gemeinsam als einzigartiger Ansatz für die Anwendungs- und Produktentwicklung zurückkehren. PLM-Nachverfolgbarkeit vs. ALM-Nachverfolgbarkeit Ein zweiter Unterschied zwischen PLM und ALM besteht in der Art und Weise, wie die Systeme Nachverfolgbarkeit definieren. In einem PLM-System wird die Nachverfolgbarkeit als „Bauteil von” der Aufspaltung eines gesamten Systems definiert. Ein Auto besteht aus einem Rahmen, einer Achse, vier Reifen usw. In einem ALM-System wird die Nachverfolgbarkeit als Verbindungen zwischen Dateien/Bausteinen definiert, die zu unterschiedlichen Abschnitten gehören. Die Veränderung einer Anforderung wirkt sich ggf. auf eine Codezeile aus oder erfordert einen neuen Testfall, der zur Bestätigung der neuen Anforderung entwickelt werden muss. Ein PLM-System verknüpft und verbindet Informationen mit PLM-Bausteinen wie Formeln und Toleranzen. Ein ALM-System andererseits verknüpft und verbindet Informationen,die mit Softwarecodes inVerbindung stehen,wieAnforderungen,Änderungsanfragen,Testfälle, und übermittelt Kommentare. Das Vorhandensein von Software als „Bauteil” eines kompletten Systems ist ein bedeutender Einflussfaktor für die Verknüpfung
  5. 5. 5www.polarion.com ALMPLM von PLM und ALM. Software ist im Bereich PLM als Einzelbauteil vorhanden, doch da endet die Reichweite des Managements. Das PLM-System geht nicht weiter in die Tiefe, um die Tatsache zu steuern, dass das Software-„Bauteil” seinen eigenen komplexen Lebenszyklus mit einer Reihe von Dateien/Bausteinen sowie Veränderungen an diesen Dateien/Bausteinen aufweist. Der Mangel an Management-Kontrolle über den Software-„Bauteil” sorgt zunehmend für Probleme für Produkthersteller. Qualitätsprobleme der Software sind Grundlage vieler kostenintensiver Produktfehler und führen ggf. zu einem Produktrückruf. Und doch verfügen die Produktingenieure mit ihren PLM-Tools nicht über die Möglichkeit, den Software-bezogenen Problemen auf den Grund zu gehen. Denken wir nur an eine Situation in der Automobilindustrie, wo in der Freigabe 3.4.5 einer Softwarekomponente ein falsches Signal erzeugt wird, wenn der Parameter X bei „3.5” angesetzt wird. Diese Softwarekomponente wird wirksam in zahlreichen Fahrzeugen eingesetzt. Wie findet ein Hersteller heraus, welche Fahrzeuge dieses zu behebende Problem haben? In einem Blog-Beitrag weist Tom Grant, Analytiker für Anwendungsentwicklung und Bereitstellung bei Forester Research, auf die momentan bestehende Kluft zwischen PLM und ALM Systemen hin und liefert Argumente für PLM- und ALM-Anbieter zur Schließung dieser Lücke: “Geschäftsprozesse, wie die Festlegung von Anforderungen, die sowohl Hardware- als auch Softwarekomponenten umfassen, sind ein Grund, warum ALM und PLM verbunden werden müssen.Während Produktteams bereits wissen, wie dies durchzuführen ist (zum Beispiel, durch Erarbeitung der Anforderungen im Sinne von „Systeme der Systeme”), teilen die von ihnen verwendeten Tools nicht immer das gleiche Verständnisebene. PLM-Tools, die in der Theorie sowohl der Hardware als auch Software Rechnung tragen sollten, bleiben zurück, wenn es um die Auseinandersetzung mit dem digitalen Teil des Produkts geht. Einige Elemente von ALM wie Source Code Management bestehen noch nicht einmal im PLM-Bereich.” - Tom Grant, Senior-Analyst, Anwendungsentwicklung und Bereitstellung, Forrester Research2 Version Control vs. Change Management PLM-Systeme haben ein Konzept der Versionskontrolle - und verstehen, dass ein Teil ggf. mit der Zeit verändert wird - aber sie leisten kein gutes Change Management und können selten den Grund für die Veränderung erfassen oder wiederfinden. Da diese Systeme auch nicht über das ALM-Konzept der Nachverfolgbarkeit verfügen, können sie auch nicht ausmachen, wie sich die Veränderung an einem Teil (insbesondere einem Softwareteil) auf andere verbundene Bausteine innerhalb des Systems auswirkt. vs. Aufgaben- management Konfigurations- management Release- Management Anforderungs- management Testmanagement Change Management Build- Management Audits, Metriken Nachlauf & Abkündigung Markteinführung & Anlauf Produktion Dienstleistungen & Support Konzept Entwurf & Entwicklung Prototyp & Pilotprojekt PLM- Plattform Produktlebenszyklus CRM PDM ERPSCM 2) Forrester Research, Inc., Blog post, August 2012 – “ALM and PLM: Make it Work People”, Tom Grant.
  6. 6. 6www.polarion.com Auf der grundlegenden Ebene sind PLM- und ALM-Systeme sehr unterschiedlich. Sie wurden zu unterschiedlichen Zeiten entworfen, um unterschiedliche Arten der Information zu steuern. Sie wurden entwickelt, um unterschiedlichen Prozessen und unterschiedlichen Benutzern zur Verfügung zu stehen. Aber nun ist es an der Zeit, dass PLM und ALM zusammenfinden. Software spielt eine zu große Rolle bei den heutigen technologisch fortgeschrittenen Produkten und das Risiko der Nicht-Steuerung dieser Software ist zu groß für diese Systeme, als dass sie weiterhin in getrennten Umgebungen bestehen könnten. Schlüsselbotschaften Software spielt eine entscheidende Rolle in Produkten und ist oft die Ursache eines Produktfehlers. 1999 veranlasste ein Softwarefehler im Nasa Mars Climate Orbiter das 125 Millionen-Dollar-Raumfahrzeug – Schlüssel zum Mars-Erkundungsprogramm – dazu, zu niedrig und zu schnell in die Marsatmosphäre einzudringen. Von dem Raumfahrzeug hörte man nie wieder etwas. Letzten Endes sind PLM- und ALM-Systeme entwickelt worden, um sehr unterschiedliche Dinge zu steuern und ganz unterschiedliche Funktionen für ihre Benutzer einzubeziehen. Stellt eine Hersteller ein Produkt mit einer sehr maßgeblichen Softwareausstattung her, werden sowohl PLM als auch ALM benötigt und diese Systeme sollten zusammenarbeiten. PLM und ALM definieren Nachverfolgbarkeit unterschiedlich. In PLM beschreibt die Nachverfolgbarkeit die Aufspaltung eines Produkts in mehrere Bauteile und Komponenten. In ALM beschreibt die Nachverfolgbarkeit die Verbindung zwischen Bausteinen über mehrere Ebenen des Software-Entwicklungsprozesses hinweg. Beide Systeme sind um Prozesse und Kerndisziplinen herum aufge- baut Beide Systeme integrieren Arbeit- sabläufe, Variantenmanagement, Testmanagement, Anforderungen und Spezifikationsmanagement Beide Systeme bieten die Möglich- keit, Komponenten miteinander zu verbinden Beide Systeme bieten die Möglich- keit, Informationen und Komponent- en miteinander zu verbinden In beiden Umgebungen gibt es einen umfassenden Einsatz von Modellen ALM stellt die Software-„Dateien” in den Mittelpunkt und setzt einen Prozess zur Entwicklung von Software-Anwendungen fest. Diese Anwendungen bestehen aus unterschiedlichen Arten von Bausteinen und komplexen Beziehungen zwischen diesen Bausteinarten, die wiederum Wirkungsgeflechte bilden. PLM orientiert sich an „Bauteilen”, die eine Baumstruktur mit „Bauteil von”-Beziehungen bilden. ALM handelt imAbstrakten.PLM handelt im Konkreten.InALM werden abstrakte Funktionen von Software-Entwicklern vergegenwärtigt, eruiert, definiert, implementiert, überprüft und instand gehalten. Im Anwendungsbereich von PLM steht die Bereitstellung einer Materialstückliste für die Produktionskette. Die Funktion der Komponenten in PLM ist die Komponente selbst. In PLM gibt es eine „Bauteil von” Verknüpfungsart, die Hierarchien der Aufspaltung festlegt. In ALM gibt es viele unterschiedliche Verknüpfungsarten, die Hierarchien der Abhängigkeit festlegen. In PLM ist diese Information reine Mathematik: Formeln, Toleranzen, Diagramme etc. In ALM ist die mit den Bausteinen verbundene Information beschreibend: Texte, Modelle, User Stories, Testszenarien etc. In PLM folgen Modelle der „Bauteil von”-Aufspaltung und definieren Produktformen. PLM- Modelle sind normalerweise in unterschiedliche Ebenen aufgeteilt,die unterschiedliche Produkt- Teilsysteme darstellen: elektrischer Aufbau, Bremsen-Teilsystem, Getriebe, Innenraum etc. In ALM folgt ein Modell der funktionalen Aufspaltung anhand von Diagrammen wie Entity- Relationship- oder objektorientierten Diagrammen. ALM & PLM Ähnlichkeiten und Unterschiede Ähnlichkeiten Unterschiede
  7. 7. 7www.polarion.com Software im Produktentwicklungsprozess Heutzutage werden Duzende Mikroprozessoren benötigt, die 100 Millionen Codezeilen ausführen, um ein Premiumfah- rzeug aus der Einfahrt herauszufahren. Und diese Software wird komplexer.3 Softwareherstellung wird zunehmend zur vorherrschenden Größe in der Herstellung von Konsum- und Industrieprodukten. Siemens stellt inzwischen mehr Software-Entwickler im Hochtechnologiebereich ein als Microsoft, Oracle oder SAP. Die wachsende und ausschlaggebende Bedeutung der Software innerhalb der Produkte führt zu neuer Kom- plexität im Produktentwicklungsprozess. Hersteller sind nicht mehr länger einfach nur für die Hardware verantwortlich, sie müssen nun zusätzliche Prozesse und Verfahren für die Entwicklung komplexer Em- bedded-Software-Systeme entwickeln. Da Qualität und Leistung die- ser Software unter manchen Umständen (wie in einem medizinischen Gerät oder bei der Steuerung eines Flugzeuges oder Fahrzeuges) eine Frage des Lebens oder des Todes für den Benutzer sein kann, un- terliegt der Softwareprozess einer strengen Kontrolle und Regulierung, deren Einhaltung von staatlichen Organen überwacht wird. Die Nichter- füllung dieser Standards kann zu schweren Strafen oder dem Stilllegen von Herstellungsbetrieben führen.4 PLM und ALM müssen ein Team werden Weiter oben haben wir über die wachsende Anzahl an Software innerhalb von Industrieprodukten - und insbesondere innerhalb tech- nologisch aufwändiger Produkte wie Automobile, medizinische Geräte und Flugzeuge - gesprochen. Dieses zunehmende - und zunehmend vorherrschende - Zugegensein von Software führt zu einer neuen Dimension an Komplexität innerhalb des Produktentstehungs- und -herstellungsprozesses. Die Komplexität muss gesteuert werden. Oberflächlich betrachtet, scheinen die Methoden zur Steuerung eines Produktlebenszyklus (PLM) und des Lebenszyklus einer Softwareanwendung (ALM) völlig ähnlich zu sein. Sowohl PLM- als auch ALM-Systeme sind um einen integrierten Prozess und eine Reihe von Kerndisziplinen herum entwickelt. Aber hier enden die Ähnlichkeiten. Schlüsselbotschaften Der F-35 Joint Strike Fighter der US-Luftwaffe beinhaltet ungefähr 5,7 Millionen Codezeilen. Das durchschnittliche medizinische Gerät weist momentan eine Million Codezeilen auf und diese Zahl verdoppelt sich alle paar Jahre. Software ist ein zunehmend bedeutender Einflussfaktor in der industriellen Produktinnovation. “Das Entscheidende bei der System-orientierten Produktentwicklung und Systemherstellung ist ein stetiges Wachstum, da Hersteller immer mehr Software zur Bereitstellung von Produktfunktionen einbeziehen. Der Wechsel von lose instrumentierter mechanischer Gestaltung, elektronischer Gestal- tung und Software-Entwicklung zu einem strenger ausgeführten System-orientierten Ansatz erfordert zeitaufwändige Veränderungen für neue Produk- tentwicklungsvorgänge, -prozesse, -organisationen und -ausgestaltungen. Hersteller, die den Wechsel nicht rechtzeitig vollziehen, werden mit den Wettbe- werbern zu kämpfen haben.” Gartner - Marc Halpern, Janet Suleski: Predicts 2013: Product Design and Life Cycle Management. 30 November 2012 3) This Car Runs on Code – IEEE Spectrum, February 2009 4) Getting Better Software into Manufactured Products – McKinsey Quarterly, March 2006
  8. 8. 8www.polarion.com CIOs und IT-Manager mit einer beträchtlichen Investition in PLM- Systeme haben versucht, ein PLM-System zur Steuerung von Software wirksam einzusetzen. Ein PLM-System kann Produkt- bezogene Arbeitsabläufe, Spezifikationen, Entwürfe und Versionen steuern - warum also nicht auch Software? Fordert man von einem PLM-System die Steuerung der Komplexität eines Software-Entwicklungsprozesses - einschließlich iterative Entwicklungszyklen, Veränderungen von Anforderungen, Nachverfolgbarkeit von Bausteinen und Beziehungen zwischen Bausteinen usw. – liegt dies jenseits seiner Grenzen. Die Steuerung des Software-Entwicklungsprozesses legt man besser in die Hände des ALM, einer Software-zentrierten Disziplin, die sich speziell um die oben beschriebene Aufgabe herum orientiert. Nach Ermittlung der vielen unterschiedlichen ALM- und PLM-Ansätze und Werkzeugsätze, kann festgehalten werden: 1. Die Erfordernis einer Steuerung von Software- und Produktlebenszyklus mit einem integrierten Ansatz ist heute dringlicher denn je 2. PLM-Werkzeugsätze können nicht die Softwareentwicklung steuern 3. ALM-Werkzeugsätze können nicht die Produktentwicklung steuern Bleibt also die Frage, wie ein Hersteller am besten die wachsende Anzahl an Software, die nun als Komponente innerhalb eines Bau- teils innerhalb eines Produkts vorhanden ist, steuert? Idealerweise wird dieses Problem durch die Integration zwischen PLM-System und ALM-System gelöst. 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). System- und 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. Da sich die Disziplinen Software-Entwicklung und Produktentwicklung deutlich unterscheiden, gibt es keine Möglichkeit, nur PLM oder nur ALM bei der Systemherstellung zu verwenden. Wir müssen beide verwenden und zusammenführen. PLM-Anbieter sollten versuchen, ALM-Systeme zur Steuerung des Software-Entwicklungsprozesses zu integrieren, um eine Lösung zu bieten. Eine mögliche Lösung findet sich im nächsten Whitepaper der Reihe: “PALM - Die Integration von ALM und PLM” Testing & QA Release Management Project Management Portfolio Management Change Management Service Management Just-in-time (JIT) Demand Management Continuous Integration Deployment Build & Configuration Management Quelle: The Forrester Wave™ : Application Life-Cycle Management, Forrester Research, Inc.
  9. 9. 9www.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 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 Über Polarion Software

×