Best-Practice-Leitfaden Software-Release

Größe: px
Ab Seite anzeigen:

Download "Best-Practice-Leitfaden Software-Release"

Transkript

1 Best-Practice-Leitfaden Software-Release Themenplattform Automotive Electronics, Infrastructure & Software

2 Impressum Best-Practice-Leitfaden Software-Release Herausgeber: ZVEI - Zentralverband Elektrotechnik- und Elektronikindustrie e.v. Themenplattform Automotive Electronics, Infrastructure & Software Lyoner Straße Frankfurt am Main Telefon: Fax: Verantwortlich: Dr. Stefan Gutschling Mai 2014 Trotz größtmöglicher Sorgfalt übernimmt der ZVEI keine Haftung für den Inhalt. Alle Rechte, insbesondere die zur Speicherung, Vervielfältigung und Verbreitung sowie der Übersetzung, sind vorbehalten. 2

3 Inhaltsverzeichnis 1. Ziele dieses Leitfadens 4 2. Release-Prozess Software-Release Prozess aus Sicht des Zulieferers Prozess aus Sicht des OEM 7 3. Dokumentation und Artefakte Übersichtsdokument Detaillierte Releasedokumentation Lieferumfang Systembeschreibung Lebenslauf/Änderungshistorie Funktionsliste Verifikationssergebnisse Metriken Freigaben Leitlinien für die Anwendung in der Praxis Definitionen und Begriffe Endredaktion und beteiligte Firmen 21 3

4 1. Ziele dieses Leitfadens Mit der steigenden Bedeutung von Software im Fahrzeug, der zunehmenden Vernetzung von Steuergeräten und der damit rapide wachsenden Komplexität tritt die Notwendigkeit eines robusten und effizienten Softwareentwicklungsprozesses immer mehr in den Fokus der Automobilindustrie. Immer mehr Anforderungen sind in immer kürzeren Zeitspannen umzusetzen. Die wachsende Komplexität kann nur beherrscht werden, wenn der Entwicklungsprozess im Netzwerk von Fahrzeugherstellern, Zulieferern und Dienstleistern nahtlos ineinandergreift und die Aufgabenteilung klar definiert und allen Beteiligten transparent ist. Während in den letzten Jahren der Fokus auf der Verbesserung der firmeninternen Prozesse (z. B. in der Umsetzung von Automotive SPICE oder CMMI) lag, wurden die Schnittstellen zwischen Fahrzeugherstellern und den Zulieferern noch wenig betrachtet. Gerade an der Nahtstelle Software-Release führen fehlende einheitliche Definitionen zu erheblichem Abstimmungsaufwand, wenn nicht sogar zu Mißverständnissen und dadurch verursachten signifikanten Störungen im Projektablauf. Die Optimierung gerade des Software-Release- Prozesses ist ein gemeinsames Interesse aller Beteiligten sie kann einen wichtigen Beitrag zur Erhöhung des Reifegrades leisten. Deshalb soll dieser Leitfaden zu einigen wesentlichen Aspekten Erfahrungen und Best-Practices zusammenfassen. Damit soll das Bewusstsein geschaffen werden, wo eine frühzeitige bilaterale Festlegung hilfreich ist, auch wenn nicht überall eindeutige unternehmensübergreifende Empfehlungen möglich sind. Dieser Leitfaden betrachtet beide Seiten des V-Modelles von der Übergabe der Anforderungen des OEM bis zur Übergabe von Steuergeräten an den OEM. Eine gemeinsame Begrifflichkeit ist dabei sehr wichtig nicht nur, aber ganz besonders bei neuen Geschäftsbeziehungen. Ziel ist es, Vorschläge für eine Optimierung der Schnittstelle (Kommunikation und Dokumentation) zwischen Fahrzeughersteller und Zulieferer zu präsentieren. Dies ist eine wesentliche Voraussetzung, um neuen Herausforderungen im Bereich Software-Entwicklung (Fahrerassistenzsysteme, Serviceorientierte Kommunikation, Car2x, etc.) besser begegnen zu können. Im Zentrum steht dabei die Definition der zu einem Software-Release gehörenden Artefakte, wobei es in erster Linie um ein gleiches Verständnis der Inhalte und weniger um einheitliche Datenformate geht. 4

5 2. Release-Prozess 2.1. Software-Release Im reinen Wortsinn bedeutet Software- Release Freigabe der Software. In der klassischen Informationstechnologie steht die Freigabe der Software am Ende ihres Entwicklungsprozesses. Mit der Freigabe sichert der Lieferant der Software bestimmte Eigenschaften zu und gibt sie für den Abnehmer im Rahmen der definierten Eigenschaften zur Benutzung frei. Das Resultat der Freigabe erfüllt daher typischerweise Vertragselemente der Geschäftsbeziehung zwischen Abnehmer und Lieferant. Die Softwareentwicklung für eingebettete Steuergeräte im Automobil ist in einem weiteren Kontext zu betrachten. Softwarekomponenten, die von verschiedenen Lieferanten stammen können, sind zunächst auf einzelnen Steuergeräten zu integrieren. Ihre Funktion ist auch im Verbund vernetzter Steuergeräte sicherzustellen. Aus Sicht des Fahrzeugherstellers gilt dies bis hin zu verteilten Funktionen, die das Gesamtfahrzeug betreffen. Damit fügt sich die automotive Softwareentwicklung in ein System ein, das viele Beteilgte aufweist und Disziplinen wie Elektrik, Elektronik, Mechanik und Vernetzung als Randbedingungen beachten muss. Dafür hat sich in der Automobilindustrie eine Prozesssystematik mit vielen Synchronisationspunkten etabliert, zu denen jeweils ein Software-Release erforderlich ist. Im sprachlichen Umgang und auch im Folgenden in diesem Leitfaden geht der Begriff Software-Release inzwischen über die wörtliche Bedeutung hinaus und bezieht sich vor allem auf das Ergebnis der Freigabe, also das freizugebende Artefakt, aber auch auf die dazu gehörigen Dokumente und Metriken. Der zur Freigabe und dem freizugebenden Artefakt führende Vorgang ist der Release- Prozess. Dieser Leitfaden beleuchtet in den folgenden Abschnitten den Release-Prozess aus verschiedenen Blickwinkeln: aus der Sicht des Zulieferers und aus der des Fahrzeugherstellers. Das freizugebende Artefakt ist hierin generisch als Komponente aufzufassen. Es kann sich dabei aus Sicht des Zulieferers um eine Software-Komponente handeln. Es kann sich aber auch um eine Gruppe von Software-Komponenten handeln, die gemeinsam freizugeben sind, z. B. die Software für ein ganzes Steuergerät. Aus der Sicht des OEM schließt der Begriff Komponente oft Hardware mit ein und bezieht sich dann z. B. auf ein freizugebendes Steuergerät Prozess aus Sicht des Zulieferers Der Prozess aus Sicht des Zulieferers gliedert sich in verschiedene Entwicklungszyklen über die verschiedenen Subsysteme (Mechanik, Hardware, Software). Die Entwicklungszyklen der Subsysteme sind in sich abgeschlossen, können unterschiedlich schnell sein und müssen zu den Meilensteinen des Gesamtsystems synchronisiert werden (siehe Bild 1). Die Entwicklungsmethoden der einzelnen Subsysteme können voneinander unabhängig sein (z. B. V-Modell für die Hardware und Agile Methoden für die Softwareentwicklung). Der Software-Release-Prozess des Zulieferer enthält folgende Schritte: Funktionserweiterungen, Änderungen und Fehlerbehebungen fließen zu einem definierten Zeitpunkt in die Komponenten ein. Was wann einfließt, muss im Rahmen der Release-Planung definiert werden. Die getesteten und freigegebenen Komponenten werden zur Gesamtsoftware integriert. Auf Basis der Gesamtsoftware wird ein änderungsbezogener Softwaretest durchgeführt, der zur Zeitoptimierung auch parallelisiert werden kann. Bei hohem Automatisierungsgrad kann die Software auch mit der gesamten Testfallsammlung geprüft werden. Die Gesamtsoftware wird evtl. zusammen mit einem Datensatz freigegeben. Die Gesamtsoftware wird falls erforderlich zusammen mit anderen Systemen wie z. B. Hardware ausgeliefert. Der Umfang des Software-Releases muss vor der Auslieferung definiert und abgesichert werden. Gesamtsoftware und Grundbedatung stellen zusammen mit der Begleitdokumentation das Software-Release aus Sicht des Zulieferers dar. 5

6 Product: I-Level Project Preparation Production Ramp up and Series Gate Gate Gate Gate Gate Production I1 Diese Concept Auslieferung stellt Product wiederum and Process eine Komponente für den OEM dar. Damit startet der Readiness and Phase Development Validation Release-Prozess beim OEM. I2.x I2.x I3.x I3.x I4.x I1.5 I2 I2.5 I3 I3.5 I4 I5 Mechanics: Long Cycles Hardware: Medium Cycles Software: Short Cycles Bild 1: Prozess: Synchronisation der Subsystem Entwicklung (Bildquelle: ESG Elektroniksystem- und Logistik) Bild 2: Ablauf Change-Request/Bugfix (Bildquelle: ZF Friedrichshafen ) 6

7 2.3. Prozess aus Sicht des OEM Der OEM erwartet vom Zulieferer eine für den geforderten Reifegrad komplett getestete Software. Aus Sicht des OEM ist die Software Teil des Steuergerätes und damit Teil einer Komponente. Diese Komponente testet der OEM inhouse in verschiedenen Schritten. Es werden Komponenten-, Teilsystem-, und Systemtests durchgeführt. In den verschiedenen Absicherungsschritten werden die Komponenten (Steuergeräte) immer näher an das Gesamtfahrzeug herangeführt und getestet (siehe Bild 3). In den Komponententests wird die Komponente an sich getestet, z. B. auf Funktionsfähigkeit und Flashbarkeit. Der Teilsystemtest sichert das Zusammenspiel zwischen der Komponente und den direkten Kommunikationspartnern ab. Im Gesamtsystem wird die Querwirkungsfreiheit sowie die Funktionalität im Fahrzeug getestet. Treten bei einem Test Fehler auf, werden diese an den Komponentenentwickler (Zulieferer) zur Fehlerbehebung in Folge-Releases zurückgespiegelt. Bild 3: Release-Prozess aus Sicht des OEM (Bildquelle: ESG Elektroniksystem- und Logistik) Bild 4: Prinzip der unterschiedlichen Integrationsebene (Bildquelle: ESG Elektroniksystem- und Logistik) 7

8 Release-Prozess aus Sicht des OEM Zeitlicher Ablauf Die Integration einer Software in das Gesamtsystem besteht dementsprechend aus drei unterschiedlichen Integrationsstufen. Diese Tests werden aufeinanderfolgend gestartet, laufen aber parallel ab. Wenn die Quickchecks einer Integrationsstufe erfolgreich durchlaufen wurden, beginnt der nächste Testschritt. Nachlieferungen von Software werden nur bei Show-Stoppern zugelassen. An einem vorher definierten Zeitpunkt findet der System-Freeze statt. Ab diesem Zeitpunkt sind keine Nachlieferungen mehr zulässig und die abschließenden Tests werden durchgeführt. Release-Prozess aus Sicht des OEM Theorie Bei den OEM werden Integrationsstufen mit definierten Funktionshüben eingeplant. Zu Beginn der Entwicklung sind die Abstände größer, zwischen zwei und vier Monaten. Kurz vor SOP sind die Funktionshübe nicht mehr so komplex und kommen in Abständen von zwei bis sechs Wochen. Release-Prozess aus Sicht des OEM Realität Durch ungeplante Bugfix-Maßnahmen werden Fehlerbehebungsschleifen zwischen die geplanten Integrationsstufen geschoben. Dies ist darauf zurückzuführen, dass Fehlerbehebungen ungeachtet des Soll-Prozesses nachgeliefert werden. Bugfix-Maßnahmen und Funktionshübe werden in der Praxis oftmals nicht getrennt. Wegen ungeplanter Fehlerbehebungsschleifen müssen Kapazitäten für die Weiterentwicklung und Absicherung überplant werden. Kapazitäten stehen oft nicht ausreichend zur Verfügung. Ungeplante Schleifen können somit eine zeitliche Verschiebung bis zum finalen Produkt bedeuten. Gleichzeitig besteht die Gefahr, dass die Nachvollziehbarkeit und Transparenz der durchgeführten Aktionen wegen den zwischengeschobenen Schleifen leidet. Release-Prozess aus Sicht des OEM Best Practice Bei jeder Integrationsstufe ist mit Fehlern zu rechnen. Daher sollten Fehlerbehebungsschleifen von Anfang an mit eingeplant werden. Dies sichert eine höhere Qualität und Transparenz im SW-Entwicklungsprozess. Im Endeffekt ergibt sich dabei ein gleicher Zeitaufwand wie bei zwischengeschobenen Schleifen. Gesamtsystem Teilsystem Release SWL Komponente Komponententest KF SF1 SF2 Nachlieferung bei Legend: Show-Stopper SWL Softwarelieferung KF KomponentenFreeze SF1 System Freeze 1 Release SF2 System Freeze 2 SR System Release QC Quick Check Bild 5: Releaseprozess: zeitlicher Ablauf (Bildquelle: ESG Elektroniksystem- und Logistik) QC QC Funktionstests Nachlieferung bei Show-Stopper Release SR Systemfunktionstest mit Blick auf Gesamtsystem, Querwirkungen und Besonderheiten System Release t 8

9 Funktionshub Funktionshub Funktionshub Bild 6: Release-Prozess aus Sicht OEM: Theorie (Bildquelle: ESG Elektroniksystem- und Logistik) Funktionshub Bugfix Funktionshub Funktionshub Bugfix Bild 7: Release-Prozess aus Sicht des OEM: Realität (Bildquelle: ESG Elektroniksystem- und Logistik) Funktionshub Funktionshub Bugfix Funktionshub Bugfix Bild 8: Release-Prozess aus Sicht des OEM: Best Practice (Bildquelle: ESG Elektroniksystem- und Logistik) 9

10 3. Dokumentation und Artefakte In diesem Kapitel wird beschrieben, welche Dokumente bei der Auslieferung einer Komponente (ECU) bzw. eines Software-Standes zu einem Release bereitgestellt werden sollten Übersichtsdokument Die Praxis hat gezeigt, dass der beste Einstieg in eine Release-Dokumentation für den Kunden mit einem Übersichtsdokument zu erreichen ist. Folgende Aspekte sollten in diesem zusammenfassenden Dokument Erwähnung finden: Kurzbeschreibung des Releases, Einsatzzweck (Bauphase, Erprobungsfahrt, Zwischenrelease, ). Eine eindeutig strukturierte Nomenklatur in der Release-Bezeichnung ist anzustreben. Damit kann dann sicher zwischen Haupt-Releases oder z. B. Bugfix-Releases unterschieden werden. Zudem ist es sinnvoll, in der Nomenklatur zu benennen, ob die Software schnittstellenkompatibel zum Vorgänger ist oder auch nicht. Übersicht der gelieferten Unterlagen, Fahrplan durch die Dokumentation Projektterminplan mit Bezug auf die aktuelle Phase im Projekt (A-, B-, C-Muster) Kurze Beschreibung des vereinbarten Regelablaufs bzw. des Vorgehensmodells für ein Release Netzwerk-Beschreibung n Release n-1 Netzwerk-Beschreibung n+1 Release n Wochen vor Auslieferung an OEM Vorab-Freeze alle Anforderungen bekannt Freeze Fahrfähiger Stand an OEM alle Anforderungen besprochen Basisauslieferung an OEM Integration Gemeinsame Freigabe Lieferung der Komponenten OEM/Zulieferer Programmierung / Integration / Prüfung Bedatung SW- Test HIL SW- Test Fzg Prüfung OEM Bild 9: Beispiel Regelablauf Software-Release (Bildquelle: ZF Friedrichshafen) 3.2. Detaillierte Releasedokumentation Lieferumfang Hier ist eine detaillierte Übersicht der gelieferten SW-Komponenten bzw. des Steuergerätes einschließlich einer Variantenübersicht z. B. in Form einer Matrix zu erstellen, die alle zur Integration der Komponente notwendigen Informationen enthält. So sollten z. B. die ein Software-Release kennzeichnenden Informationen zu Software-Version, Konfigurationsdateien, Flashbootloader, HW usw. hier detailliert und klar benannt werden. Bei Bedarf sollten darüber hinaus Parametersätze und Diagnosebedatungen ebenfalls beschrieben werden. Als vorteilhaft hat sich ebenfalls erwiesen, eine Liste der integrierten Software-Fremdkomponenten (z. B. OEM-Standardsoftware) inklusive der Versionsnummern beizufügen. In diesem Zusammenhang kann es auch sinnvoll sein, zusätzlich die exakten Daten der verwendeten Buildumgebung wie z. B. Compilerversionen zu beschreiben. In Tabelle 1 wird beispielhaft die Matrix-Beschreibung des B1-Musterstandes eines Steuergerätes beschrieben. Ähnliche Darstellungen können auch bei reinen SW Lieferungen verwendet werden. 10

11 Tabelle1: Beispiel für Kenndaten eines Steuergeräte-Releases: Musterstand Variante Tier 1 Artikel-Nr. 1. Flexray Single XY 2. Flexray 4fach XY 3. Flexray 8fach XY Kennzeichnung OEM LU Nr. (Lieferumfang) OEM ZB Nr. (Zusammenbau) SW HW SW Nummer HW Nummer B1 MECH DBC-File OEM... Mechanik Index ECU-Filename... Standard SW Package... OEM Flashbootloader Stand... SW-Sachnummer Erweiterte SW Sachnummer Systembeschreibung Neben der grundlegenden Kennzeichnung des Produktes sollte zu einem Release immer ein klarer Bezug zur System- bzw. Steuergeräteebene beigefügt werden. Dies ist für den Kunden insbesondere dann hilfreich, wenn er Funktionalitäten an einem Release überprüfen will und hierzu die entsprechenden Rahmenbedingungen schnell verfügbar haben will. Zu der Systembeschreibung gehören z. B. folgende Informationen: Schaltplan des Steuergerätes Schnittstellenbeschreibung des Steuergerätes bzw. Systems Blockschaltbild Steckerbeschreibung Lebenslauf/Änderungshistorie Die Aufgabe des Lebenslaufes ist es, dem Kunden einen knappen aber vollständigen Überblick über den Änderungsumfang des Release zu geben. Als zentrales Element enthält es eine Auflistung der Software Änderungen bezogen auf das Vorgänger-Release. Idealerweise werden die Änderungen aus dem Workflow- Managementsystem exportiert, um Konsistenzprobleme von Software und Dokumentation zu vermeiden. Um die Kompatibilität von Hardware, Software und Werkzeugen eindeutig zu dokumentieren, ist es sinnvoll, das Dokument Lieferumfang zu referenzieren. Dieser wichtige Block einer Releasedokumentation kann häufig von Release zu Release übernommen werde, bei Änderungen in System bzw. Steuergeräte-HW sind Hinweise zur Kompatibilität des Software-Release zu verschiedenen Hardware Ständen ebenfalls zu dokumentieren. 11

12 Es ist sinnvoll, eine Unterscheidung zwischen umgesetzten Anforderungen und Fehlerbehebungen vorzunehmen. In der Praxis haben sich Tabellen mit folgenden Spalten als Kategorien bewährt: Fortlaufende Nummer Eindeutige Lieferanten-ID (Referenz auf Change-Management-System des Lieferanten) Headline der Änderung Kennzeichnung Anforderung/Fehlerbehebung Eindeutige Kunden-ID (Referenz auf Requirements- oder Problem-Management-System des Kunden) Funktionsliste Im Zuge der Releaseplanung eines Projektes werden die zu einem Release umzusetzenden Funktionen festgelegt. Diese sollten hier nochmals aufgeführt werden und es sollte eine Referenzierung auf die gültigen Anforderungsdokumente vorgenommen werden. Es soll dargestellt werden, ob die geplante Funktion realisiert wurde. Wurde sie nur teilweise realisiert, sollte eine kurze Darstellung der Einschränkungen ergänzt werden. Eine Herausforderung ist der Trend zu einem immer fein granularerem Reporting, welches unter Umständen bis auf die Ebene von Einzelanforderungen reichen kann. Hier ist mit dem Kunden zur Aufwandsminimierung unbedingt eine sinnvolle Tiefe bzw. eine mittlere Granularität zu vereinbaren. So kann ein Bezug auf übergeordnete Funktionen oder Funktionsgruppen sinnvoll sein. An vielen Stellen wird hierfür der Begriff Feature verwendet. Durch eine hohe Lastenheftqualität und -stabilität wird das Erstellen einer aussagekräftigen Funktionsliste unterstützt. Die Wichtigkeit einer solchen Liste wird allerdings bei schlechterer bzw. volatiler Lastenheftqualität umso bedeutender. Behobene Fehler sind bereits in der Änderungshistorie dargestellt. Hier in der Funktionsliste sollten daneben Fehler aufgeführt werden, die bekannt, aber noch nicht behoben sind ( known issues ). Dies erhöht die Transparenz und stärkt das Vertrauen. Es ist weiterhin sinnvoll Metriken zu dem erreichten Funktionshub zwischen den Releases zu erstellen. Wie entwickelt sich die Anzahl der Anforderungen über die Projektlaufzeit, werden die vereinbarten Funktionshübe erreicht, wie groß sind die Abweichungen? Bild 10 zeigt angenommen über einen fiktiven Projektverlauf den Umsetzungs- und Erfüllungsgrad. Dabei wird unterschieden zwischen Anforderungen die zum Release geplant und umgesetzt wurden, sowie zwischen Anforderungen die zwar geplant waren aber nicht umgesetzt werden konnten Verifikationssergebnisse Die Aufgabe dieses Dokumentes ist es, Verifikationsergebnisse des Lieferanten dem Kunden in einer geeigneten Weise zur Verfügung zu stellen. Im Rahmen einer Prozessabstimmung vereinbaren Kunde und Lieferant zu Projektbeginn, welche Testmethoden und welche Test-Endekriterien im Projekt zum Einsatz kommen. Um den Aufwand für Kunden und Lieferanten zu minimieren und aus Gründen des Knowhow Schutzes, ist es notwendig eine geeignete Abstraktionsebene für die Verifikationsergebnisse zu vereinbaren. Im Normalfall ist es ausreichend, die Testabdeckung bezogen auf die Kunden- Requirements zu berichten (siehe auch Abschnitt 3.2.6). Die detaillierten Testergebnisse werden nur dann zur Verfügung gestellt, wenn dies vertraglich vereinbart ist. Ein guter Kompromiss ist oft, dass detaillierte Ergebnisse eingesehen werden können, jedoch nicht übergeben werden. Anmerkungen: Vom definierten Dokumentumfang kann je nach Projektphase abgewichen werden. In frühen Phasen ist der Dokumentenumfang evtl. unvollständig oder angepasst. Bei mehreren Lieferungen und Rekursionsschleifen zu einem Release kann es sinnvoll sein, eine Delta-Betrachtung durchzuführen. 12

13 Anforderungen umgesetzt nicht umgesetzt Zum Release geplant B0 B1 B2 C0 C1 C2 D0 Release Bild 10: Umsetzungsstatus Lastenhefte (Bildquelle: Leopold Kostal) Metriken Metriken dienen zur gesamtheitlichen Bewertung eines SW-Release und sind damit ein wesentliches Element des Risiko-Managements. In vielen Fällen ist es sinnvoll, die jeweils gleichen Metriken über den Projektverlauf zu dokumentieren, um daraus Trend- Aussagen ableiten zu können. Daher ist die sorgfältige Definition der Metriken beim Projektstart besonders wichtig. Jede spätere Änderung erfordert ggf. Korrekturrechnungen und erschwert in jedem Fall Aussagen zum langfristigen Trend. In vielen Projekten haben sich die folgenden Metriken bewährt: Anzahl der umgesetzten Funktionsänderungen ( Funktionshub ) Anzahl der behobenen Fehler Anzahl der noch nicht behobenen Fehler bzw. der offenen Punkte ( known issues ) Testabdeckung bezogen auf die Anforderungen Testabdeckung bezogen auf den erstellten Code (z. B. Function Coverage oder Code Coverage ) Metriken zur Bewertung der Produkt-Qualität (z. B. MISRA oder HIS) Maturity Index Der Maturity Index ist ein sehr nützliches Werkzeug zur Bestimmung der Produktqualität oder Produktreife im Laufe der Produktentwicklung. Er berücksichtigt Probleme und Änderungswünsche je nach deren Schweregrad und Bearbeitungsstatus. Details hierzu finden sich im Glossar. Ressourcenbedarf (bezüglich RAM, ROM und Laufzeit, siehe Bild 11) 13

14 BELEGUNG ROM (DATENBEREICH) KBYTE Summe Nutzbar 85 % Bild 11: Beispiel Ressourcenverlauf Ist/Soll (Bildquelle: ZF Friedrichshafen/ZVEI) Freigaben Mit diesem Dokument werden die Freigabeunterlagen der beteiligten Entwicklungsabteilungen in einem mehrstufigen Prozess verdichtet (siehe Bild 12). Die Freigabe zu einer definierten Verwendung eines Software-Release wird vom Projektleiter des Lieferanten ausgesprochen und dokumentiert. Diese basiert auf den Freigabeempfehlungen der beteiligten Funktionen (z. B. SW-Entwicklung, Test, Qualitätssicherung, Safety-Management). Abhängig von den Projektphasen können unterschiedliche Freigabe-Level geprüft und erteilt werden. Dies sind zum Beispiel: Eine Freigabe für die Erprobung im Fahrzeug auf einem abgesperrten Prüfgelände für speziell zugelassene Fahrer in der Prototypenerprobung Eine Freigabe für die Erprobung im Fahrzeug auf öffentliche Straßen für einen eingeschränkten Personenkreis, der das Fahrzeug bewegen darf, Eine Freigabe für die uneingeschränkte Verwendung des Fahrzeugs auf öffentlichen Straßen. 14

15 Kunde Freigabe Projekt Freigabe- Empfehlung Freigabe- Empfehlung Freigabe- Empfehlung Software- Projekt Safety (HW + SW) Elektronik- Hardware Freigabe- Empfehlung Freigabe- Empfehlung Freigabe- Empfehlung Projekt Q-Bericht Software- Entwicklung Software- Lieferant Software- Testmanager Qualitäts- Beauftragter Bild 12: Beispiel für einen mehrstufigen Freigabeprozess (Bildquelle: ZF Friedrichshafen) 15

16 4. Leitlinien für die Anwendung in der Praxis Für eine optimale Umsetzung des Software- Release-Prozesses in enger Kooperation zwischen den OEM s und ihren Partnern auf Zulieferer- und Dienstleisterseite müssen zwei zentrale Herausforderungen adressiert werden: eine hohe Transparenz über den Status der Software ist die Basis für nahtlose Zusammenarbeit und Vertrauen zwischen allen Partnern, und Stabilität im Prozess ist gerade in kritischen Projektphasen essentiell, um Reibungsverluste zu vermeiden. Für die anzustrebende Transparenz sind Konsistenz und Kontinuität der Informationen von entscheidender Bedeutung. Sie bilden die Grundlage für eine effiziente Kommunikation. Heute sind die Austauschformate für die Dokumentation von Software-Releases zwischen Kunde und Lieferant für jeden Kunden unterschiedlich. Eine Vereinheitlichung der Schnittstellen insbesondere zu Change- und Problem- Management ist dringend anzustreben. Durch hohe Transparenz muss sichergestellt werden, dass Kunde und Lieferant ein einheitliches Verständnis über Anforderungen und Erwartungen für jedes Software-Release haben. Dies kann durch Projekt- und Release- Kick-offs, in denen Erwartungen und Umfang gemeinsam geklärt werden, und durch eine transparente Darstellung aller relevanten Informationen in Release-Planung und Dokumentation sichergestellt werden. Dabei ist es wichtig, dass eine geeigneten Abstraktionsebene gemeinsam definiert wird, die nicht zu feingranular ist ein zu viel an Detailinformationen führt nicht zu höherer Transparenz. So soll natürlich in der Release-Dokumentation der Grad der Anforderungserfüllung berichtet werden aber nicht durch ein paralleles Reporting zur Anforderungsmanagementdatenbank (z. B. in DOORS), sondern in einer mittleren und pragmatischen Granularität: entscheidend ist eine gute Übersicht, was dieser Softwarestand kann und was nicht. Zum Aufbau einer Vertrauensbasis zwischen Kunde und Lieferant können initiale Prozess-Qualitätsbewertungen (z. B. SPICE- Assessment), die bei Bedarf im Projektverlauf aktualisiert werden können, einen wichtigen Beitrag leisten. Dies kann hilfreicher sein als ein zu feingranulares Reporting im Projekt. Eine rechtzeitige Planung und Abstimmung der Release-Inhalte ist Grundlage für eine qualitativ hochwertige und termingerechte Lieferung. Ungeplante Änderungen führen leicht zu einem Terminverzug im Projekt. Die Zahl der zu liefernden Software-Releases muss in der Projektplanung definiert und so weit wie irgend möglich eingehalten werden übertriebener Aktionismus durch tägliche Releases schadet nur der Stabilität des Prozesses. Tägliche Softwarelieferungen im Rahmen agiler Entwicklung, z. B. durch Nightly Builds mittels Continuous Integration können insbesondere auf Komponenten-Ebene durchaus sinnvoll sein. Sie sind nicht als Software- Release im Sinne dieses Leitfadens zu sehen, da dabei deutlich weniger formale Anforderungen zu erfüllen sind. Späte Änderungen aufgrund von Kundenentscheidungen müssen gemeinsam bewertet werden. Die Balance zwischen Termintreue, Qualität und Änderungsbedarfen des Kunden kann nur in enger und offener Kommunikation erfolgreich optimiert werden. Dazu sind vereinbarte Metriken und eine gemeinsame Bewertung eine wichtige Basis. Bei der Planung der Releases ist darauf zu achten, dass Testergebnisse und damit Korrekturen in Folge-Releases einfließen können. In der Release-Planung ist genauso die Definition unterschiedlicher Freigabe-Levels und damit Testumfänge pro Release je nach Projekt-Phase zu dokumentieren. Die Unterscheidung zwischen Bugfix auf Seitenzweig und Weiterentwicklung auf Hauptzweig ist notwendig. Dabei ist der Umfang von Bugfixes, die nicht im Hauptzweig integriert werden können, auf das Notwendigste zu beschränken. 16

17 Die Übergabe eines Software-Release an den Kunden sollte durch ein Release-Review begleitet werden. Hier wird der erreichte Entwicklungsstand an den Anforderungen und Erwartungen des Kunden gespiegelt und es wird ein gemeinsames Verständnis hergestellt, für welche Zwecke das Release verwendet werden kann. Eine Bewertung der Entwicklungsphase seit dem zugehörigen Release-Kick-off ( Lessons learned ) ist sinnvollerweise ein zusätzlicher Bestandteil eines Release-Reviews. 17

18 5. Definitionen und Begriffe Applikationsstand Grundbedatung der Integrationssoftware (Gesamtsoftware) mit neutralen Daten/Konfigurationswerten, um eine Grundfunktionalität sicherzustellen. Bugfix Behebung eines festgestellten Fehlers bzw. einer Fehlfunktion. Der Bugfix wird erst zur nächsten offiziell geplanten Softwarelieferung wirksam. Ein Bugfix beschreibt immer die Behebebung eines Fehlers und keine neue Funktionalität (vgl. Funktionshub. Feature). Feature Übergeordnete Funktionalität oder Funktionsgruppe. Siehe auch Funktionshub. Freigabe Eine Freigabe bestätigt, dass eine (Software-) Komponente oder ein (Software-) Release für bestimmte Zwecke eingesetzt werden kann. Funktionshub Geplante oder implementierte neue Funktionalität aus Sicht der bestehenden Funktionalität einer Teilkomponente. Ein Funktionshub beschreibt keinen Bugfix (siehe dort). Integrationsstufe Gesamtheit aller geplanten und durchgeführten Funktionshübe, Bugfixes sowie die positiv abgeschlossener Absicherungsmaßnahmen für diesen Meilenstein. Kalibrationsstand Kalibrierte Software mit erweiterten Daten bzw. erprobten Datensätzen auf Basis des Applikationsstands Known Issue Ein bekanntes und unter gewissen Bedingungen bzw. Konstellationen auftretendes Problem in einer Softwarekomponente, welches zum aktuellen Zeitpunkt noch nicht behoben wurde. Maturity Index (Produkt-/Release-Reife) Der Maturity Index hat das Ziel, die Produktreife in einer Kennzahl zusammenzufassen. Dabei werden die Issues entsprechend ihrer Schwere und ihrem Bearbeitungszustand gewichtet (siehe Tabelle 2). Alle Release-relevanten Fehler, Änderungswünsche und Feature-Implementierungen werden gleichwertig als Issue behandelt. Der Maturity Index ergibt sich letztlich als die Summe der gewichteten Issues und wird sinnvolerweise als Grafik über die Zeit aufgetragen. Tabelle 2: Wichtungsfaktoren zur Ermittlung des Maturity-Index Severity Showstopper Major Minor Status New or Analyzing Open or Implementing Testing Closed or Rejected

19 Alle Implementierungs- Tasks für Release sind definiert Test und Bugfixing läuft Maturity Index Gewünschte Testabdeckung erreicht Fehlerbehebung und Verifizierung läuft lmplementierung ist fortgeschritten Testing startet Maturity Index Release Zeitpunkt Bugfixing und Verifizierung läuft Blocking Issues sind gelöst, der letzte Testlauf kann starten Bild 13: Typischer Verlauf des Maturity-Index (Bildquelle: TTTech Computertechnik) Regelablauf Terminübersicht der geplanten und abgestimmten Projektphasen und Meilensteine mit dem OEM, sowie der erwarteten Ergebnisse in zeitlicher Relation zur Auslieferung für diese Integrationsstufe. Release Die bestimmte fertige und veröffentlichte Version/Stand einer Software, das für einen spezifischen Zweck bereitgestellt wurde (Bsp. Test oder Produktion). Mit einem Release geht eine Veränderung der Versionsbezeichnung, meist ein Hochzählen der Versionsnummer einher. Release-Kick-off Ein Release-Kick-off sollte in Form eines Präsenz-Meetings zwischen Kunden und Lieferanten stattfinden. Teilnehmer sind Entscheidungsträger, Projektleiter und technische Experten. Im Meeting präsentiert der Kunde: Release-Ziele Akzeptanzkriterien und der Lieferant: geplante Absicherungsmaßnahmen und ggf. eine detaillierte Terminplanung. Ziel des Release-Kick-offs ist der Abgleich der Erwartungen beider Seiten und die Definition von Regeln bezüglich Kommunikation, Prozessen, Eskalation, etc. Release-Review Teilnehmer und Format entsprechen dem Release-Kick-off. Im Meeting präsentiert der Kunde die ggf. überarbeiteten: Release-Ziele und Akzeptanzkriterien Der Lieferant präsentiert: den erreichten Stand der Entwicklung Reifegrad des Produkts Absicherungsmaßnahmen Testabdeckung Die Release-Notes werden gemeinsam gesichtet und akzeptiert und die weiteren Schritte bis zur Freigabe des Release werden abgestimmt. Ein weiteres Element des Release-Reviews ist die Bewertung der Entwicklungsphase seit dem Release-Kick-off bezüglich der Punkte, die sich bewährt haben und der Punkte, die einer Verbesserung bedürfen (im Sinne von Lessons learned ). 19

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

Machbar? Machbar! 07.10.2010

Machbar? Machbar! 07.10.2010 TANNER AG 2010 TANNER AG Kemptener Straße 99 D-88131 Lindau (B) Telefon +49 8382 272-0 Fax +49 8382 272-900 www.tanner.de info@tanner.de Agile Softwareentwicklung im regulativen Umfeld. Machbar? Machbar!

Mehr

Agile Programmierung - Theorie II SCRUM

Agile Programmierung - Theorie II SCRUM Agile Programmierung - Theorie II SCRUM Arne Brenneisen Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Christian

Mehr

Firmenportrait open4business GmbH. open4business. Softwareentwicklung für Unternehmen

Firmenportrait open4business GmbH. open4business. Softwareentwicklung für Unternehmen Firmenportrait open4business GmbH open4business Softwareentwicklung für Unternehmen Wer sind Wer wir sind Kurzprofil Die open4business GmbH ist ein mittelständisches IT-Dienstleistungsunternehmen mit Firmensitz

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Requirements-Management Glücksspiel oder systematischer Prozess? 5 / 02. Sonderdruck der Vector Consulting GmbH

Requirements-Management Glücksspiel oder systematischer Prozess? 5 / 02. Sonderdruck der Vector Consulting GmbH 5 / 02 Februar Oktober 2002 ISSN 1435-6074 D 46769 Das Magazin für Automobilentwicklung Sonderdruck der Vector Consulting GmbH Requirements-Management Glücksspiel oder systematischer Prozess? P R O Z E

Mehr

IV::SOLUTIONFRAMEWORK

IV::SOLUTIONFRAMEWORK IV::SOLUTIONFRAMEWORK EINFÜHRUNG Das IV::SolutionFramework ist die Antwort der INTERVISTA AG auf die Anforderungen an moderne IT Entwicklungsprojekte. Effiziente Vorgehensmodelle und die Einführung von

Mehr

Präventives Software Qualitätsmanagement in der Kfz-Elektronik

Präventives Software Qualitätsmanagement in der Kfz-Elektronik Präventives Software Qualitätsmanagement in der Kfz-Elektronik Gesellschaft für Informatik, Regionalgruppe Köln, 23.02.2011 Thomas Thurner SQS Software Quality Systems AG Content 1. Motivation 2. Methoden

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr

PM-Forum Augsburg. Thomas Müller-Zurlinden, PMP 18.05.2012. Kontakt: Info@QinS.de

PM-Forum Augsburg. Thomas Müller-Zurlinden, PMP 18.05.2012. Kontakt: Info@QinS.de PM-Forum Augsburg Thomas Müller-Zurlinden, PMP 18.05.2012 Kontakt: Info@QinS.de Einführung in die Konzepte der Software Product Line Organisation einer globalen SPL Entwicklung SPL und die Herausforderungen

Mehr

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Modellgetriebene Softwareentwicklung auf Basis von TOPCASED am Beispiel

Mehr

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management Anforderungsmanagement im Projekt BIS-BY von B. KREUZER Schlüsselwörter: Änderungswünsche, Anforderungsmanagement, DOORS Kurzfassung Softwaresysteme unterliegen während ihrer Entwicklung und während ihres

Mehr

CONTINUOUS DELIVERY. Entmystifiziert. codecentric AG

CONTINUOUS DELIVERY. Entmystifiziert. codecentric AG CONTINUOUS DELIVERY Entmystifiziert WIE SOFTWARE LIEFERN? 01.07.2014 2 WAS IST CONTINUOUS DELIVERY? Robust Wiederholbar Effektiv 01.07.2014 3 LANDSCHAFTEN Continuous Integration Public / Private Hybrid

Mehr

Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen

Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen Dipl.-Math. Hermann Will QADVICE Software+System Qualität Jamnitzerstr. 2, 81543 München hermann.will@qadvice.de Zusammenfassung.

Mehr

Testmanagement in IT-Projekten

Testmanagement in IT-Projekten Teil 1: Projektmagazin 05/20009 Teil 2: Projektmagazin 06/2009 1 Test: Prozess, bei dem ein Programm oder ein Software-System ausgeführt wird, um Fehler zu finden Teil 1: Projektmagazin 05/20009 Teil 2:

Mehr

RELEASE AUF KNOPFDRUCK: MIT CONTINUOUS DELIVERY KOMMEN SIE SCHNELLER ANS ZIEL.

RELEASE AUF KNOPFDRUCK: MIT CONTINUOUS DELIVERY KOMMEN SIE SCHNELLER ANS ZIEL. RELEASE AUF KNOPFDRUCK: MIT CONTINUOUS DELIVERY KOMMEN SIE SCHNELLER ANS ZIEL. Die Erwartungen Ihrer Businesskunden an ihre IT steigen. Mehr denn je kommt es darauf an, die Software optimal am Kunden auszurichten

Mehr

Grundlagen des Projektmanagements Im Rahmen der Haupstudiumsprojekte am Fachbereich Informatik und Gesellschaft an der TU Berlin

Grundlagen des Projektmanagements Im Rahmen der Haupstudiumsprojekte am Fachbereich Informatik und Gesellschaft an der TU Berlin Grundlagen des Projektmanagements Im Rahmen der Haupstudiumsprojekte am Fachbereich Informatik und Gesellschaft an der TU Berlin Raphael Leiteritz, raphael@leiteritz.com, 22. April 2002 1 Inhalt 1 Was

Mehr

Mit agilen Methoden kommen Sie weiter

Mit agilen Methoden kommen Sie weiter Mit agilen Methoden kommen Sie weiter Wir machen Sie und Ihr Unternehmen fit für Scrum. Rido - Fotolia.com Was ist Scrum? Scrum stellt heute eines der bekanntesten agilen Produktentwicklungs-Frameworks

Mehr

Absicherung von Automotive Software Funktionen

Absicherung von Automotive Software Funktionen GI Themenabend "Automotive" Absicherung von Automotive Software Funktionen 27.02.2013 Jürgen Schüling Überblick Berner & Mattner Gründung: 1979 Mitarbeiter: 400 Umsatz 2011: Standorte: Angebot: Branchen:

Mehr

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Über mich Berufliche Erfahrung 3 Jahre Projektabwicklung 2 Jahre

Mehr

Leitfaden und Empfehlungen für Post-View-Vergütung im Affiliate Marketing. erarbeitet vom Arbeitskreis Affiliate Marketing im BVDW e.v.

Leitfaden und Empfehlungen für Post-View-Vergütung im Affiliate Marketing. erarbeitet vom Arbeitskreis Affiliate Marketing im BVDW e.v. Leitfaden und Empfehlungen für Post-View-Vergütung im Affiliate Marketing erarbeitet vom Arbeitskreis Affiliate Marketing im BVDW e.v. Die Vergütung von Transaktionen nach dem Post-View-Verfahren sowie

Mehr

Use Cases REQEDIT CLIENT. Mai 2014. DER INNOVATIVE TOOLHERSTELLER www.reqteam.com

Use Cases REQEDIT CLIENT. Mai 2014. DER INNOVATIVE TOOLHERSTELLER www.reqteam.com Use Cases REQEDIT CLIENT Mai 2014 Übersicht 1. Einführung Anforderungsmanagement 2. Einführung Anforderungsmanagementtools und Austauschformate 3. Warum ReqEdit? 4. Use Cases - kleinere und mittlere Unternehmen

Mehr

Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- Architekturentwicklung von Fahrzeugen

Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- Architekturentwicklung von Fahrzeugen Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- entwicklung von Fahrzeugen Martin Jaensch, Dr. Bernd Hedenetz, Markus Conrath Daimler AG Prof. Dr. Klaus D. Müller-Glaser

Mehr

USABILITY-CHECKLISTE FÜR SOFTW ARE- ANWENDENDE UNTERNEHMEN

USABILITY-CHECKLISTE FÜR SOFTW ARE- ANWENDENDE UNTERNEHMEN USABILITY-CHECKLISTE FÜR SOFTW ARE- ANWENDENDE UNTERNEHMEN 1 EINLEITUNG Auch Unternehmen, die Software-Produkte einkaufen, stehen vor der Herausforderung, eine geeignete Auswahl treffen zu müssen. Neben

Mehr

Transparenz optimieren durch Managed Services. Dr. Armin Metzger, sepp.med gmbh MID Insight, Nürnberg 2012-11-20

Transparenz optimieren durch Managed Services. Dr. Armin Metzger, sepp.med gmbh MID Insight, Nürnberg 2012-11-20 Transparenz optimieren durch Managed Services Dr. Armin Metzger, sepp.med gmbh MID Insight, Nürnberg 2012-11-20 Inhalt Managed Services was ist das? Motivation und Benefits von Managed Services Parameter

Mehr

Requirements Management für SAP Solution Manager Projektrisiken minimieren durch professionelles Anforderungsmanagement

Requirements Management für SAP Solution Manager Projektrisiken minimieren durch professionelles Anforderungsmanagement Requirements Management für SAP Solution Manager Projektrisiken minimieren durch professionelles Anforderungsmanagement SAP Consulting Use this title slide only with an image Agenda Risikofaktoren beim

Mehr

Projektmanagement für Systeme im regulatorischen Umfeld

Projektmanagement für Systeme im regulatorischen Umfeld Projektmanagement für Systeme im regulatorischen Umfeld Agilität beherrscht Komplexität Dr. Oliver Schütz Thomas Reuner Mitglieder der Arbeitsgruppe APS der GfSE PM für Systeme im regulatorischen Umfeld

Mehr

Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht. München, 11.03.2014

Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht. München, 11.03.2014 Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht München, 11.03.2014 Vorstellung Ihr Referent Ralf Nagel Senior Consultant für modellbasierte Anforderungsanalyse MID GmbH Kressengartenstraße

Mehr

ITIL meets CMMI: Optimierung der IT-Prozesse durch das Zusammenspiel von ITIL und CMMI SQM 2006

ITIL meets CMMI: Optimierung der IT-Prozesse durch das Zusammenspiel von ITIL und CMMI SQM 2006 ITIL meets CMMI: Optimierung der IT-Prozesse durch das Zusammenspiel von ITIL und CMMI SQM 2006 Dr. Ralf Kneuper Dr. Ralf Kneuper Beratung Jan Stender ITIL Berater Überblick Motivation Überblick CMMI Überblick

Mehr

Application Life Cycle Management

Application Life Cycle Management Application Life Cycle Management Konzepte von ALM Hermann Lacheiner +43 7236 3343 849 Hermann.Lacheiner@scch.at www.scch.at Das SCCH ist eine Initiative der Das SCCH befindet sich im Anwendungsorientierte

Mehr

Kapitel 2: Der Software-Entwicklungsprozess

Kapitel 2: Der Software-Entwicklungsprozess Wie konstruiert man Software? Kapitel 2: Der Software-Entwicklungsprozess SoPra 2008 Kap. 2: Der Software-Entwicklungsprozess (1/10) Der Software-Entwicklungs-Prozess Historisches 1960JJ adhoc Techniken

Mehr

Tine 2.0 Wartungs- und Supportleistungen

Tine 2.0 Wartungs- und Supportleistungen Tine 2.0 Wartungs- und Supportleistungen 1 Überblick Wartungs- und Supportleistungen Metaways Tine 2.0 Wartungs- und Support Editionen: LEISTUNGEN BASIC BUSINESS PROFESSIONAL SW Wartung ja ja ja Ticketsystem

Mehr

Aktuelle Themen der Informatik

Aktuelle Themen der Informatik Aktuelle Themen der Informatik Change Management Michael Epple AI 8 Inhalt: 1. Einführung 2. Begriffsbestimmungen 3. Ablauf des Change Management Prozesses 4. Zusammenhang zwischen Change Management, Configuration

Mehr

Modul 3: Service Transition Teil 4

Modul 3: Service Transition Teil 4 Modul 3: Service Transition Teil 4 1. Ziel, Wert und Aufgaben von Service Transition? 2. Prozess: Projektmanagement (Transition Planning and Support) 3. Prozess: Change Management 4. Prozess: Change-Evaluierung

Mehr

Grundlagen des Software Engineering

Grundlagen des Software Engineering Grundlagen des Software Engineering Teil 1: SW-Management Fachrichtung Wirtschaftsinformatik FB Berufsakademie der FHW Berlin Prof. Dr. Gert Faustmann Einleitung Historie des Konfigurationsmanagements:

Mehr

Agile Methoden bei der Entwicklung medizinischer Software

Agile Methoden bei der Entwicklung medizinischer Software Agile Methoden bei der Entwicklung medizinischer Software Bernhard Fischer Fischer Consulting GmbH Fischer Consulting GmbH Technologie-Forum 2008 Folie 1 Wie soll Software entwickelt werden? Fischer Consulting

Mehr

Massive Automatisierung von Software-Tests. In einem agilen Automotive Projekt

Massive Automatisierung von Software-Tests. In einem agilen Automotive Projekt Massive Automatisierung von Software-Tests In einem agilen Automotive Projekt Inhalt Die Projektziele Die Projektstruktur und die Rahmenbedingungen Automotive SPICE und Scrum Die Automatisierung der SW-Testfälle

Mehr

your engineering partner boost your development

your engineering partner boost your development boost development Individuelle Lösungen von Ihrem Engineering Partner Luft- und Raumfahrt Wir realisieren Ihre Visionen und setzen unser ganzes Know-How ein, damit Ihre Ziele praxisgerecht, zeitnah und

Mehr

Referenzprozessmodell zur erfolgreichen Durchführung von CRM - Projekten

Referenzprozessmodell zur erfolgreichen Durchführung von CRM - Projekten Referenzprozessmodell zur erfolgreichen Durchführung von CRM - Projekten Eine große Anzahl von CRM- Projekten scheitert oder erreicht die gesetzten Ziele nicht. Die Ursachen hierfür liegen oftmals in der

Mehr

IT-Development & Consulting

IT-Development & Consulting IT-Development & Consulting it-people it-solutions Wir sind seit 1988 führender IT-Dienstleister im Großraum München und unterstützen Sie in den Bereichen IT-Resourcing, IT-Consulting, IT-Development und

Mehr

Schneller zu Ergebnissen unser erstes Agile Project

Schneller zu Ergebnissen unser erstes Agile Project Schneller zu Ergebnissen unser erstes Agile Project Thomas Schmidt Juni 2014 Agenda Das Project Projektstruktur und der Projektplan Theorie vs Realität Releases und Sprints Executable Code Angst vor dem

Mehr

Lieferung 4.3 Entwicklungsprozess für mobile Anwendungen

Lieferung 4.3 Entwicklungsprozess für mobile Anwendungen Lieferung 4.3 Entwicklungsprozess für mobile Anwendungen für das BMBF-Projekt Modellgetriebene agile Entwicklung für mobile Anwendungen (ModAgile Mobile) Arbeitspaket Arbeitspaketleitung Förderkennzeichen

Mehr

Medical SPICE Von der Regulierung zur Praxis

Medical SPICE Von der Regulierung zur Praxis Medical SPICE Von der Regulierung zur Praxis Thomas Wunderlich, Manager, Vector Consulting Services GmbH Markus Manleitner, SW Quality Assurance Officer, Dräger medical GmbH MedConf 2013, 17.10.2013 2013.

Mehr

Gemeinsam erfolgreich in IT Projekten

Gemeinsam erfolgreich in IT Projekten management consulting partners Gemeinsam erfolgreich in IT Projekten MCP Die IT-Spezialisten mit Prozesswissen in der Industrie MCP GmbH www.mc-partners.at Christian Stiefsohn Juli 2014 Das Unternehmen

Mehr

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Ottostr. 15 96047 Bamberg Tel. +49/951/98046200 Fax +49/951/98046150 email: info@softcondev.de www: softcondev.de INHALT Vorwort Diese

Mehr

CMMI und SPICE im Automotive Umfeld

CMMI und SPICE im Automotive Umfeld Vorträge 2006 CMMI und SPICE im Automotive Umfeld Inhalt Motivation Übersicht zu CMMI Anwendung in Entwicklungsprojekten Prozess Management als Lösungsansatz SPICE Motivation Jährliche Kosten für Prozessverbesserung

Mehr

DURCHGÄNGIGE SAP CHANGE- UND RELEASE-PROZESSE EINFACH UMSETZEN

DURCHGÄNGIGE SAP CHANGE- UND RELEASE-PROZESSE EINFACH UMSETZEN THEGUARD! SMARTCHANGE CHANGE PROCESS DURCHGÄNGIGE SAP CHANGE- UND RELEASE-PROZESSE EINFACH UMSETZEN DURCHGÄNGIGE SAP CHANGE- UND RELEASE-PROZESSE EINFACH UMSETZEN THEGUARD! SMARTCHANGE I CHANGE PROCESS

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

Wir schützen Ihre Investitionen. Qualitätssicherung nach Maß. IT Quality Services

Wir schützen Ihre Investitionen. Qualitätssicherung nach Maß. IT Quality Services Wir schützen Ihre Investitionen Qualitätssicherung nach Maß IT Quality Services Sicherheit, die senkt Mit den IT Quality Services schützen Sie Ihre Investitionen Ohne Qualitätssicherung Mit Qualitätssicherung

Mehr

SAPs PLM Interface für CATIA V5

SAPs PLM Interface für CATIA V5 V6 SAPs PLM Interface für CATIA V5 Durchgängige, sichere und trotzdem schlanke Geschäftsprozesse erhöhen die Wettbewerbsfähigkeit in einem immer härteren globalen Wettstreit um die Gunst der potenziellen

Mehr

Systems Engineering Center (SEC)

Systems Engineering Center (SEC) Systems Engineering Center (SEC) Überblick - 1 - OMNITRACKER Systems Engineering Center im Überblick Effizientes Werkzeug für den Einsatz in Software- und System- Entwicklungsorganisationen: Applikation

Mehr

Erfahrungen über den Einsatz einer agilen Entwicklungsmethode fürdie Produktentwicklung unterstützt durch Polarion ALM forsubversion

Erfahrungen über den Einsatz einer agilen Entwicklungsmethode fürdie Produktentwicklung unterstützt durch Polarion ALM forsubversion Erfahrungen über den Einsatz einer agilen Entwicklungsmethode fürdie Produktentwicklung unterstützt durch Polarion ALM forsubversion Nikolay Entin, Robert Neher Polarion Software GmbH, Lautlinger Weg 3,70567

Mehr

Medizinprodukte mit Risikoanalyse nach ISO 14971

Medizinprodukte mit Risikoanalyse nach ISO 14971 Whitepaper Medizinprodukte mit Risikoanalyse nach ISO 14971 www.infoteam.de Medizinprodukte mit Risikoanalyse nach ISO 14971 In unserer zunehmend vernetzten Welt steigt auch die durch Software realisierte

Mehr

Quality is our Passion!

Quality is our Passion! Quality is our Passion! Quality is our Passion! Quality is our Passion! 2 Knowledge Department ist ein Dienstleistungsunternehmen im Software-Entwicklungs-Bereich. Das Serviceangebot umfasst Trainings,

Mehr

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen Scrum technische Umsetzung und kaufmännische 9. Darmstädter Informationsrechtstag 2013 Darmstadt, 15. November 2013 Franziska Bierer 2 andrena ojects ag Gründung 1995 Standorte in Karlsruhe und Frankfurt

Mehr

Requirements Management Wissensmanagement für und mit Anforderungen

Requirements Management Wissensmanagement für und mit Anforderungen Requirements Management Wissensmanagement für und mit Anforderungen Barbara Paech Forum ITK-Industrie Industrie trifft Forschung in ViSEK, 28.10.02 IESE Fraunhofer Institut Experimentelles Software Engineering

Mehr

Automotive Software Engineering

Automotive Software Engineering Jorg Schauffele Thomas Zurawka Automotive Software Engineering Grundlagen, Prozesse, Methoden und Werkzeuge Mit 278 Abbildungen ATZ-MTZ-Fachbuch vieweg Inhaltsverzeichnis 1 Einfiihrung und Uberblick 1

Mehr

Sonntag, 4. Oktober 2009. Release a Day... Mythos oder Realität

Sonntag, 4. Oktober 2009. Release a Day... Mythos oder Realität Release a Day... Mythos oder Realität Markus Guske Michael Kloss Ein (nahezu) realistischer Fall... "Die fertige und veröffentlichte Version einer Software wird als Release bezeichnet. Damit geht ein Hochzählen

Mehr

Simulation 2.0: Simulationsbaukasten und Team-Modellierung

Simulation 2.0: Simulationsbaukasten und Team-Modellierung Simulation 2.0: Simulationsbaukasten und Team-Modellierung Vortrag an der FH Ostfalia, ASIM 2012 Daniel Frechen TESIS DYNAware GmbH 24. Februar 2012 TESIS DYNAware GmbH, www.tesis-dynaware.com 1 Einleitung

Mehr

VDA. Auslaufmanagement von Elektronikkomponenten im Automotive Aftermarket

VDA. Auslaufmanagement von Elektronikkomponenten im Automotive Aftermarket VDA Auslaufmanagement von Elektronikkomponenten im Automotive Aftermarket 605 Mit dieser Empfehlung wird ein Verfahren aufgezeigt, um (a) den OEM und Tier 1 durch eine Prognose möglicher, sich abzeichnender

Mehr

Modul 3: Service Transition

Modul 3: Service Transition Modul 3: Service Transition 1. Ziel, Wert und Aufgaben von Service Transition? 2. Prozess: Projektmanagement (Transition Planning and Support) 3. Prozess: Change Management 4. Prozess: Change-Evaluierung

Mehr

Antworten auf die globalen Herausforderungen bei der Integration von Entwicklungspartnern

Antworten auf die globalen Herausforderungen bei der Integration von Entwicklungspartnern ProSTEP ivip Symposium 2007 Antworten auf die globalen Herausforderungen bei der Integration von Entwicklungspartnern Peter Hakenberg Ford Werke GmbH Manager Virtual Analysis & Supplier Implementation

Mehr

Pressemitteilung Vector und IBM beschließen Partnerschaft Kompetenz zur Steuerung technischer Geschäftsprozesse in der Fahrzeugentwicklung gebündelt

Pressemitteilung Vector und IBM beschließen Partnerschaft Kompetenz zur Steuerung technischer Geschäftsprozesse in der Fahrzeugentwicklung gebündelt Vector und IBM beschließen Partnerschaft Kompetenz zur Steuerung technischer Geschäftsprozesse in der Fahrzeugentwicklung gebündelt Stuttgart, 18.09.2006 Vector Consulting GmbH, der Anbieter von Prozesstools

Mehr

Aktuelle Themen der Informatik IT Infrastructure Library Release Management

Aktuelle Themen der Informatik IT Infrastructure Library Release Management Aktuelle Themen der Informatik IT Infrastructure Library Release Management Oliver Schmid AI 8 Inhalt iii I Inhalt I Inhalt...iii II Abbildungsverzeichnis...iv 1 Einführung...1 2 Release Begriffe...2

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

CeBIT 17.03.2015. CARMAO GmbH 2014 1

CeBIT 17.03.2015. CARMAO GmbH 2014 1 CeBIT 17.03.2015 CARMAO GmbH 2014 1 HERZLICH WILLKOMMEN Applikationssicherheit beginnt lange bevor auch nur eine Zeile Code geschrieben wurde Ulrich Heun Geschäftsführender Gesellschafter der CARMAO GmbH

Mehr

Automotive Consulting Solution. Kundenspezifische Prozesse in der Automobilindustrie - EDI Lieferavis Ausgang

Automotive Consulting Solution. Kundenspezifische Prozesse in der Automobilindustrie - EDI Lieferavis Ausgang Automotive Consulting Solution Kundenspezifische Prozesse in der Automobilindustrie - EDI Lieferavis Ausgang Agenda 1. Kundennutzen 2. Funktionsbeschreibung 3. Abbildung im System 4. Technischer Steckbrief

Mehr

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System?

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System? Der Entwicklungsprozess Oder wie entwickle ich ein eingebettetes System? Einleitung Problemstellung erläutern, Eine Entwicklungsprozess ist ein Prozess, der beschreibt, wie man eine Entwicklung anzugehen

Mehr

Test & Diagnose. Thomas Romanek. thomas.romanek@udo.edu. PG AutoLab Seminarwochenende 21.-23. Oktober 2007. AutoLab

Test & Diagnose. Thomas Romanek. thomas.romanek@udo.edu. PG AutoLab Seminarwochenende 21.-23. Oktober 2007. AutoLab Test & Diagnose Thomas Romanek thomas.romanek@udo.edu PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Einführung Tests zur Qualitätssicherung V-Modell Spezielle Verfahren in Automotive Das Diagnosesystem

Mehr

Alles richtig machen Prozessorientierung hilft Ziele zu erreichen und schafft Vertrauen

Alles richtig machen Prozessorientierung hilft Ziele zu erreichen und schafft Vertrauen Information zum Thema Prozess Der Erfolg eines Unternehmens die Durchsetzung seiner Produkte und Dienstleistungen auf dem Markt, effiziente interne Abläufe, eine gesunde wirtschaftliche Situation hängt

Mehr

23. Januar, Zürich-Oerlikon

23. Januar, Zürich-Oerlikon 23. Januar, Zürich-Oerlikon Effizientere agile Teams mit Git Christian Hassa, Managing Partner (@chrishassa) Daniel Sack, Development Expert (@danielthecoder) TechTalk Software AG Agenda Unser Weg zu Git

Mehr

Operative Exzellenz in der Konsumgüterindustrie Ganzheitliche und GuV wirksame Optimierung der Unternehmensprozesse

Operative Exzellenz in der Konsumgüterindustrie Ganzheitliche und GuV wirksame Optimierung der Unternehmensprozesse Operative Exzellenz in der Konsumgüterindustrie Ganzheitliche und GuV wirksame Optimierung der Unternehmensprozesse Jochen Jahraus, Partner KPS Consulting Competence Center Konsumgüter Seite Operative

Mehr

Ihr Vorteil durch effizientes Testen

Ihr Vorteil durch effizientes Testen EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM XAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM M EXAM EXAM EXAM EXAM EXAM EXAM EXAM

Mehr

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch Agiles Testmanagment Hugo Beerli bbv Software Services AG Luzern, September 2011 Product Backlog (Agenda) 1) Warum System Tests 2) Agile Arbeitsmethode Stand up Meeting 3) Vorteile der agilen Methode 4)

Mehr

Managed Services als strategische Lösung. Typische Aufgaben. Wir schaffen Ihnen Freiräume!

Managed Services als strategische Lösung. Typische Aufgaben. Wir schaffen Ihnen Freiräume! Managed Services als strategische Lösung Wir schaffen Ihnen Freiräume durch verantwortungsvolle Anwendungs- und Systembetreuung quer über alle Technologien. Pragmatisch, individuell skalierbar und jederzeit

Mehr

Modul 5: Service Transition Teil 1

Modul 5: Service Transition Teil 1 Modul 5: Service Transition Teil 1 1. Ziel, Wert und Aufgaben von Service Transition? 2. Prozess: Projektmanagement (Transition Planning and Support) 3. Prozess: Change Management 4. Prozess: Change-Evaluierung

Mehr

Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie

Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie Insert picture and click Align Title Graphic. Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie Dr. Dieter Lederer, Geschäftsführer Vector Consulting Services GmbH

Mehr

Projektplanungstool Rillsoft Project jetzt immer mit on-board

Projektplanungstool Rillsoft Project jetzt immer mit on-board Projektplanungstool Rillsoft Project jetzt immer mit on-board Von Ingo H. Fleckenstein, freier Journalist in Lehrte 9 Dezember 2013 Die Zulassung von OBD-Systemen für die jeweiligen Märkte nahm bei der

Mehr

Über dieses Buch. Kapitel 1. 1.1 Einleitung

Über dieses Buch. Kapitel 1. 1.1 Einleitung Kapitel 1 Über dieses Buch 1.1 Einleitung Dieses Buch behandelt das Vorgehensmodell Kanban und seinen Einsatz in Softwareentwicklungsprojekten. Kanban ist ein Vorgehensmodell der schlanken Softwareentwicklung

Mehr

IDC-Studie: Software Quality Assurance Unternehmen in Deutschland haben Nachholbedarf

IDC-Studie: Software Quality Assurance Unternehmen in Deutschland haben Nachholbedarf Pressemeldung Frankfurt am Main, 02. Februar 2012 IDC-Studie: Software Quality Assurance Unternehmen in Deutschland haben Nachholbedarf Software Quality Assurance wird nicht geliebt aber praktiziert. Die

Mehr

1 Einleitung. Software Engineering. Vorgehensweisen

1 Einleitung. Software Engineering. Vorgehensweisen 1 Noch ein Buch über Software Engineering? Warum nicht! Wir folgen einem Prinzip, das zur Lösungsfindung in den verschiedensten Domänen Einzug gehalten hat: die Betrachtung aus verschiedenen Blickwinkeln.

Mehr

Test Management Services Der Quick Start für SAP Projekte

Test Management Services Der Quick Start für SAP Projekte Test Management Services Der Quick Start für SAP Projekte Agenda Übersicht Herausforderungen beim Testen von SAP Projekten Der Test Management Service im Detail Testkonzept Trainings Test Workbench Test

Mehr

Projektmanagement Basistraining

Projektmanagement Basistraining Projektmanagement Basistraining adensio GmbH Kaiser-Joseph-Straße 244 79098 Freiburg info@adensio.com www.adensio.com +49 761 2024192-0 24.07.2015 PM Basistraining by adensio 1 Inhalte Standard 2-Tage

Mehr

Datenschutz: Datenvernichtung im HCM mittels Information Lifecycle Management. Dr. Michael Wulf, Sap SE 22.März 2015

Datenschutz: Datenvernichtung im HCM mittels Information Lifecycle Management. Dr. Michael Wulf, Sap SE 22.März 2015 Datenschutz: Datenvernichtung im HCM mittels Information Lifecycle Management Dr. Michael Wulf, Sap SE 22.März 2015 Motivation Datenschutz ist schon immer ein Thema im HR, wird aber noch wichtiger Was

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

Änderungsbasiertes Requirements Management mit agosense.requirements und Atlassian JIRA

Änderungsbasiertes Requirements Management mit agosense.requirements und Atlassian JIRA Änderungsbasiertes Requirements Management mit agosense.requirements und Atlassian JIRA REFERENT Webinar Nr. 1 26. März 2015 15 Uhr bis 16 Uhr Antonio Jesus de Loureiro antonio.loureiro@agosense.com +49.7154.99951.16

Mehr

i.s.h.med Entwicklung & Services Manfred Kösner / Manfred Schönthoner 27.09.2012 Siemens AG Österreich. Alle Rechte vorbehalten.

i.s.h.med Entwicklung & Services Manfred Kösner / Manfred Schönthoner 27.09.2012 Siemens AG Österreich. Alle Rechte vorbehalten. i.s.h.med Entwicklung & Services Manfred Kösner / Manfred Schönthoner 27.09.2012 i.s.h.med Entwicklung Die Ziele Verstärkung der Entwicklungsmannschaft bei stabilen Kosten Verbesserung der Effizienz in

Mehr

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

Abweichungsmanagement. Probleme hat doch jeder

Abweichungsmanagement. Probleme hat doch jeder 1 Abweichungsmanagement Probleme hat doch jeder SEQIS Software Testing Know-how Veranstaltungen 2011 24.03.2011 16.06.2011 22.09.2011 24.10.2011 Nicht zuviel und nicht zuwenig: Testdokumentation Theorie

Mehr

Requirements Management Center

Requirements Management Center Requirements Management Center Überblick - 1 - Inhalt OMNITRACKER Requirements Management Center im Überblick Workflow im Überblick Informationsmodell Dokumentation und Reports Leistungsmerkmale Anforderungsdefinitionsprozess

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

Dipl. Inf. Ali M. Akbarian

Dipl. Inf. Ali M. Akbarian Dipl. Inf. Ali M. Akbarian 2012 Einführung Globalisierung, Innovation und Kundenzufriedenheit sind auch in Zukunft die wichtigsten Herausforderungen der Unternehmen. Diese Herausforderungen verlangen:

Mehr

Softwareprozesse systematisch verbessern ISO15504(SPICE) und Automotive SPICE. Heinrich Dreier Elmshorn 17.04.2008

Softwareprozesse systematisch verbessern ISO15504(SPICE) und Automotive SPICE. Heinrich Dreier Elmshorn 17.04.2008 Softwareprozesse systematisch verbessern ISO15504(SPICE) und Automotive SPICE Heinrich Dreier Elmshorn 17.04.2008 Einleitung Softwareprozesse verbessern Einleitung Softwareprozesse verbessern SPI Software

Mehr

Automotive. Nichts läuft ohne.

Automotive. Nichts läuft ohne. Automotive SPICE Nichts läuft ohne. SPICE ist seit 2000 das Mittel der Wahl zur Beurteilung der Qualitätsfähigkeit eines Zulieferers für deutsche Automobilhersteller. Automotive SPICE (in 2005 veröffentlicht)

Mehr

Integrative Entwicklungsprozesse am Beispiel einer automotiven Anwendung

Integrative Entwicklungsprozesse am Beispiel einer automotiven Anwendung am Beispiel einer automotiven Anwendung Bernd van Vugt EXTESSY AG Stefan Gläser VOLKSWAGEN AG Motivation Kundenwunsch: Mobilität und Individualität Fahrzeug + Informationstechnologie + Dienst Herausforderung:

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr