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

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

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

Funktionale Sicherheit in Automotive und Luftfahrt (ISO26262 und DO 178BC) Otto Alber, Peter Wittmann 09.10.2013

Funktionale Sicherheit in Automotive und Luftfahrt (ISO26262 und DO 178BC) Otto Alber, Peter Wittmann 09.10.2013 Funktionale Sicherheit in Automotive und Luftfahrt (ISO26262 und DO 178BC) Otto Alber, Peter Wittmann 09.10.2013 Einleitung Modell-basierte Entwicklung bei Silver Atena Erfahrung mit Modell-basierter Entwicklung

Mehr

Implementierung sicher und schnell

Implementierung sicher und schnell im Überblick SAP Services SAP Business One SAP Accelerated Implementation Program Herausforderungen Implementierung sicher und schnell Mit Methode sicher zum Ziel Mit Methode sicher zum Ziel Ihr Unternehmen

Mehr

BESTVOR. Kurzvorstellung. Stand: 28.11.2008

BESTVOR. Kurzvorstellung. Stand: 28.11.2008 BESTVOR Kurzvorstellung Stand: 28.11.2008 Einführung, Motivation und Zielsetzung Projekt BESTVOR Self-Assessment Einführungsanleitungen Seite 2 Motivation Praxis Schwierigkeiten Die Integration unterschiedlicher

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

Der Prozess für erfolgreiche

Der Prozess für erfolgreiche ivu.xpress Der Prozess für erfolgreiche it-projekte IVU.xpress Für IT-Projekte Erprobt. Effizient. Schnell. Komplexe IT-Systeme sind aus dem Alltag von Verkehrsbetrieben nicht mehr wegzudenken. Oft ist

Mehr

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

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

Unsere These: Meilensteindefinitionen sind wichtig für die Projektplanung und die Bewertung des Projektstatus.

Unsere These: Meilensteindefinitionen sind wichtig für die Projektplanung und die Bewertung des Projektstatus. Fachgruppe Projektmanagement im Mittelstand August 2015 Themen, die vor dem Projekt durchzuführen sind KNOW-HOW Unsere These: Meilensteindefinitionen sind wichtig für die Projektplanung und die Bewertung

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

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Wiederholung Weitere Begriffe Programmierung im Großem (Programmierung von Software als Ganzes) Prozess-Modelle 2 Wiederholung: Prozesse Prozesse sind hierarchische Gruppierungen von

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

Werkzeugunterstützte Verknüpfung von Anforderungen und Tests Voraussetzung für eine systematische Qualitätssicherung

Werkzeugunterstützte Verknüpfung von Anforderungen und Tests Voraussetzung für eine systematische Qualitätssicherung Werkzeugunterstützte Verknüpfung von Anforderungen und Tests Voraussetzung für eine systematische Qualitätssicherung Dr. Sadegh Sadeghipour sadegh.sadeghipour@itpower.de Meike Lim meike.lim@itpower.de

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

Kollaboratives Requirements Engineering bei Mercedes-Benz Cars. Dr. Andreas Queckenberg

Kollaboratives Requirements Engineering bei Mercedes-Benz Cars. Dr. Andreas Queckenberg Kollaboratives Requirements Engineering bei Mercedes-Benz Cars Dr. Andreas Queckenberg Berliner Requirements Engineering Symposium 2013 1 Agenda Rückblick REM@MBC Kollaboratives Requirements Engineering

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

Reviews von Entwicklungsartefakten durchführen

Reviews von Entwicklungsartefakten durchführen Testen Reviews von Entwicklungsartefakten durchführen Bereich Evaluation Ziele Fehler und Probleme frühzeitig finden Wissenstransfer ermöglichen Teamzusammenhalt fördern Lösungen erarbeiten Aktivität Reviews

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

2.2 IT Configuration Coordinator (IT-Konfigurationskoordinator/in)

2.2 IT Configuration Coordinator (IT-Konfigurationskoordinator/in) 2.2 IT Configuration Coordinator (IT-Konfigurationskoordinator/in) 2.2.1 Kurzbeschreibung IT Configuration Coordinators organisieren das Konfigurations- und Changemanagement, indem sie Software-Entwicklungsprozesse

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

Varianten Handling in AUTOSAR

Varianten Handling in AUTOSAR Vielfalt beherrschen und Kosten kontrollieren V0.01 2015-09-22 Was sind eigentlich Varianten Beispiele für verschiedene (verwandte) Abwandlung eines Steuergerätes Airbag Steuergerät für und OEM B Anwendung:

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

PLM Business Consulting gedas Engineering Benchmark

PLM Business Consulting gedas Engineering Benchmark PLM Business Consulting gedas Engineering Benchmark Ziel gedas Engineering Benchmark wurde von gedas auf Basis des umfangreichen Engineering-Knowhows aus dem Automotive-Umfeld entwickelt, zielt auf die

Mehr

JOB MANAGEMENT MIT DEM SAP SOLUTION MANAGER. Whitepaper

JOB MANAGEMENT MIT DEM SAP SOLUTION MANAGER. Whitepaper JOB MANAGEMENT MIT DEM SAP SOLUTION MANAGER. Whitepaper Wussten Sie, dass lediglich der kleinere Teil der Datenverarbeitung in Ihrem System von End-Anwendern generiert wird? Der größere Teil der Informationen

Mehr

Automotive Consulting Solution. Warranty Management - Integration von Antragsabwicklung und Qualitätsmanagement

Automotive Consulting Solution. Warranty Management - Integration von Antragsabwicklung und Qualitätsmanagement Automotive Consulting Solution Warranty Management - Integration von Antragsabwicklung und Qualitätsmanagement Agenda 1. Kundennutzen 2. Funktionsbeschreibung 3. Abbildung im System 4. Technischer Steckbrief

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

Softfolio xrm - Your Solution for Sage Evolution Projektmanagement

Softfolio xrm - Your Solution for Sage Evolution Projektmanagement Softfolio xrm - Your Solution for Sage Evolution Projektmanagement PROJEKTMANAGEMENT Projektaufgaben und Ressourcen effizient verwalten Führen Sie Ihre Projekte zum Erfolg. Die Koordination und Durchführung

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

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12 Vertretung von Prof. Dr. Blume WS 2011/12 Inhalt Test, Abnahme und Einführung Wartung- und Pflegephase gp Vorlesung Zusammenfassung Produkte und Recht (Folien von Prof. Blume) 2 , Abnahme und Einführung

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

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

Dienstleistungsportfolio

Dienstleistungsportfolio Dienstleistungsportfolio Die klassischen Grenzen zwischen einzelnen Ingenieur- und Informatikbereichen werden immer mehr aufgehoben. Im Vordergrund steht ein durchgängiger effizienter Entwicklungsprozess.

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

Metrik-basierte Steuerung der automobilen Systementwicklung.

Metrik-basierte Steuerung der automobilen Systementwicklung. Seite 1 Metrik-basierte Steuerung der automobilen Systementwicklung. Kaiserslautern, Dr. Jürgen Knoblach Seite 2 Metrik-basierte Steuerung der automobilen Systementwicklung. Gliederung. 1. Herausforderungen

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

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

Qualitätspartnerschaft in der Entwicklung von Schienenfahrzeugen. Deutsche Bahn AG Gorden Falk Leiter Sicherheit und Qualität Berlin, 25.09.

Qualitätspartnerschaft in der Entwicklung von Schienenfahrzeugen. Deutsche Bahn AG Gorden Falk Leiter Sicherheit und Qualität Berlin, 25.09. Qualitätspartnerschaft in der Entwicklung von Schienenfahrzeugen Deutsche Bahn AG Gorden Falk Leiter Sicherheit und Qualität Berlin, 25.09.2014 Es gibt vielfältige Probleme in aktuellen Beschaffungsprojekten,

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

COMPARC embedded 2010

COMPARC embedded 2010 Fraunhofer-Institut für Software- und Systemtechnik ISST COMPARC embedded 2010 AUTOSAR zwischen Weiterentwicklung und Umsetzung MONTAG, 22. November 2010 Fraunhofer Forum, Berlin Herzlich Willkommen bei

Mehr

Richtlinie für Verfahren für interne Datenschutz-Audits

Richtlinie für Verfahren für interne Datenschutz-Audits Richtlinie für Verfahren für interne Datenschutz-Audits Freigabedatum: Freigebender: Version: Referenz: Klassifikation: [Freigabedatum] Leitung 1.0 DSMS 01-01-R-05 Inhaltsverzeichnis 1 Ziel... 2 2 Anwendungsbereich...

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

Medizintechnologie.de. Entwicklungsplan. Entwicklungsplan. Einteilung in Entwicklungsphasen

Medizintechnologie.de. Entwicklungsplan. Entwicklungsplan. Einteilung in Entwicklungsphasen Medizintechnologie.de Entwicklungsplan Entwicklungsplan Medizinprodukte werden immer komplexer. Um alle gesetzlichen und normativen Vorgaben einhalten und die Entwicklung eines Medizinproduktes kontrollieren

Mehr

PMI Munich Chapter 21.04.2008

PMI Munich Chapter 21.04.2008 Projektmanagement im Rahmen einer IT-Infrastruktur- Standardisierung mit internationalen Teams Christoph Felix PMP, Principal Project Manager, Microsoft Deutschland PMI Munich Chapter 21.04.2008 Agenda

Mehr

Qualitätsmanagement. Grundlagen

Qualitätsmanagement. Grundlagen Grundlagen Historie: Mit industriellen Massenproduktion erforderlich geworden (Automobilindustrie, Anfang des letzten Jahrhunderts); Qualitätsmanagement zunächst nur in der Fertigung Mitte des letzten

Mehr

Software EMEA Performance Tour 2013. Berlin, Germany 17-19 June

Software EMEA Performance Tour 2013. Berlin, Germany 17-19 June Software EMEA Performance Tour 2013 Berlin, Germany 17-19 June Change & Config Management in der Praxis Daniel Barbi, Solution Architect 18.06.2013 Einführung Einführung Wer bin ich? Daniel Barbi Seit

Mehr

lung eingebetteter Softwaresysteme im

lung eingebetteter Softwaresysteme im Technische Universität München Fakultät für Informatik Lehrstuhl für Software & Systems Engineering Kosten und Nutzen modellbasierter Entwick lung eingebetteter Softwaresysteme im Automobil Sascha Kirstan

Mehr

Maintenance & Re-Zertifizierung

Maintenance & Re-Zertifizierung Zertifizierung nach Technischen Richtlinien Maintenance & Re-Zertifizierung Version 1.2 vom 15.06.2009 Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 22899 9582-0

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

Die Softwareentwicklungsphasen!

Die Softwareentwicklungsphasen! Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.

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

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

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

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg Herzlich willkommen Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg Heike Bickert Software-/Systemingenieurin, Bereich Quality Management Braunschweig // 17.11.2015 1 Agenda ICS AG Fragestellungen

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

Test Management Cockpit. SAP Deutschland AG & Co. KG

Test Management Cockpit. SAP Deutschland AG & Co. KG Test Management Cockpit SAP Deutschland AG & Co. KG Einleitung Kennzahlen und Testmanagement Der zusätzliche Aufbau eines Kennzahlensystems bietet die große Chance, tatsächlich die Kenntnis darüber zu

Mehr

02/07. PLM-Lösungen für Mechatronik. Autor: Jens Krüger, Softlab. Version: 1.0

02/07. PLM-Lösungen für Mechatronik. Autor: Jens Krüger, Softlab. Version: 1.0 02/07 PLM-Lösungen für Mechatronik Autor: Jens Krüger, Softlab Version: 1.0 Datum: Februar 2007 1 / 4 Elektrik und Elektronik sind in der Automobilindustrie mittlerweile der wichtigste Innovationstreiber,

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

Modellbasierter Entwurf sicherheitskritischer Anwendungen. Von Moritz Borgmann Für VL Eingebettete Systeme Sommer Semester 2009

Modellbasierter Entwurf sicherheitskritischer Anwendungen. Von Moritz Borgmann Für VL Eingebettete Systeme Sommer Semester 2009 Modellbasierter Entwurf sicherheitskritischer Anwendungen Von Moritz Borgmann Für VL Eingebettete Systeme Sommer Semester 2009 Einführung Einführung Modellbasierter Entwurf und der IEC 61508 Ausblick Zusammenfassung,

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

Arbeitsmappe: Projektplanung Individualsoftware

Arbeitsmappe: Projektplanung Individualsoftware Arbeitsmappe: Projektplanung Individualsoftware Whitepaper und technische Dokumentation Informationen zu diesem Dokument Autor: Tobias Eichner, tobias@starenterprise.com Datum der Erstveröffentlichung:

Mehr

Microsoft Solutions Framework. Daniel Dengler CN7. Unterschied MSF - MOF Microsoft Solutions Framework

Microsoft Solutions Framework. Daniel Dengler CN7. Unterschied MSF - MOF Microsoft Solutions Framework Einführung MSF MOF Microsoft Solutions Framework Microsoft Operations Framework Daniel Dengler CN7 Agenda Unterschied MSF - MOF Microsoft Solutions Framework Elementare Komponenten grundlegende Richtlinien

Mehr

T.A. Cook. Management eines Turnaround-Projektes mittels SAP, Impress Project iapp und Primavera Enterprise

T.A. Cook. Management eines Turnaround-Projektes mittels SAP, Impress Project iapp und Primavera Enterprise T.A. Cook Management eines Turnaround-Projektes mittels SAP, Impress Project iapp und Primavera Enterprise Die Aufgabe Großstillstandsreparatur von 43 Prozeßanlagen TÜV / Reinigung / Katalysator-Service

Mehr

Professionelles Projektmanagement in der Praxis. Veranstaltung 5 Teil 3 (02.06.2003):

Professionelles Projektmanagement in der Praxis. Veranstaltung 5 Teil 3 (02.06.2003): Professionelles Projekt-Management in der Praxis Veranstaltung 5 Teil 3 (02.06.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Dozent: Dr. Harald Wehnes,

Mehr

Verwertung und Wirtschaftlichkeit. Projektmanagement. Konzeptentwicklung. Technologische/Technische Klärung

Verwertung und Wirtschaftlichkeit. Projektmanagement. Konzeptentwicklung. Technologische/Technische Klärung Zielsetzung und Einsatz: Die Checkliste dient als Hilfsmittel für die Gestaltung und Umsetzung einer Voruntersuchung. Die hier vorliegende ist auf die Abwicklung vergleichsweise komplexer Voruntersuchungen

Mehr

Christian Kühnel, BMW Group AGILE ENTWICKLUNG VON FAHRERASSISTENZSOFTWARE. AGILE CARS 2014.

Christian Kühnel, BMW Group AGILE ENTWICKLUNG VON FAHRERASSISTENZSOFTWARE. AGILE CARS 2014. Christian Kühnel, BMW Group AGILE ENTWICKLUNG VON FAHRERASSISTENZSOFTWARE. AGILE CARS 2014. PROJEKT ÜBERBLICK Entwicklung von Fahrerassistenz-Software zur Vorverarbeitung und Fusion von Sensordaten aus

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

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

Muster Nachweisdokumentation und Sicherheitsbewertungsbericht

Muster Nachweisdokumentation und Sicherheitsbewertungsbericht Muster Nachweisdokumentation und Sicherheitsbewertungsbericht auf Basis der "Verordnung (EG) Nr. 352/2009 der Kommission vom 24. April 2009 über die Festlegung einer gemeinsamen Sicherheitsmethode für

Mehr

Anforderungs- und Projektmanagement

Anforderungs- und Projektmanagement Anforderungs- und Projektmanagement Zwei Regelkreise mit vielen Gemeinsamkeiten Stefan Gregorzik 2. Berliner Requirements Engineering Symposium Berlin, 27. September 2012 CONTACT Software 1990 gegründet

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

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

Einführung in das Projektmanagement

Einführung in das Projektmanagement Einführung in das Projektmanagement Warum Projektmanagement? Projekte bergen Risiken Förderung von Zusammenarbeit Verbesserung von Informationsfluss und austausch Planung unter Berücksichtigung von Ressourcen

Mehr

Automotive Consulting Solution. Pickup-Sheet Prozess in der Materialwirtschaft

Automotive Consulting Solution. Pickup-Sheet Prozess in der Materialwirtschaft Automotive Consulting Solution Pickup-Sheet Prozess in der Materialwirtschaft Agenda 1. Kundennutzen 2. Funktionsbeschreibung 3. Abbildung im System 4. Technischer Steckbrief 2 Kundennutzen Lösung Erprobte

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

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

Zur Herstellung seiner Erzeugnisse setzt Schunk Kohlenstofftechnik in wesentlichem Umfang zugekaufte

Zur Herstellung seiner Erzeugnisse setzt Schunk Kohlenstofftechnik in wesentlichem Umfang zugekaufte Qualitätsrichtlinien für Lieferanten 1. Einführung Zur Herstellung seiner Erzeugnisse setzt Schunk Kohlenstofftechnik in wesentlichem Umfang zugekaufte Produkte ein. Um zu gewährleisten, dass kein Fehler

Mehr

Internes Audit. Länderübergreifende Verfahrensanweisung. Inhalt. 1 Zweck, Ziel

Internes Audit. Länderübergreifende Verfahrensanweisung. Inhalt. 1 Zweck, Ziel Datum des LAV-Beschlusses: 05.11.2012 Seite 1 von 9 Inhalt 1 Zweck, Ziel... 1 2 Geltungsbereich... 2 3 Begriffe, Definitionen... 2 4 Verfahren... 2 4.1 Planung der Audits... 5 4.2 Vorbereitung des Audits...

Mehr

13 Anhang A: Erfüllung der Norm ISO 9000 durch HERMES

13 Anhang A: Erfüllung der Norm ISO 9000 durch HERMES 13 Anhang A: Erfüllung der Norm ISO 9000 durch Hinweis Einleitung Eine der wesentlichsten Grundlagen für die Qualitätssicherung in einem Unternehmen ist die Normenserie «ISO 9000», insbesondere ISO 9001:1994

Mehr

Projektmanagement. Leitfaden. (Kurzfassung) OEC GmbH Vogelbergstraße 20 D-86441 Zusmarshausen

Projektmanagement. Leitfaden. (Kurzfassung) OEC GmbH Vogelbergstraße 20 D-86441 Zusmarshausen Projektmanagement Leitfaden (Kurzfassung) Inhaltsangabe Projektmanagementleitfadens Seitenzahl 1. Zweck und Ziel des Leitfadens 1 2. Geltungsbereich 1 3. Aufbau der Leitfadens 1 4. Projektorganisation

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

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

Schleswig-Holsteinischer Landtag Umdruck 18/3151

Schleswig-Holsteinischer Landtag Umdruck 18/3151 Schleswig-Holsteinischer Landtag Umdruck 18/3151 Finanzministerium des Landes Schleswig-Holstein Finanzministerium Postfach 7127 24171 Kiel An den Vorsitzenden des Finanzausschusses des Schleswig-Holsteinischen

Mehr

XT Bundesrepublik Deutschland, 2004, Alle Rechte vorbehalten

XT Bundesrepublik Deutschland, 2004, Alle Rechte vorbehalten XT Bundesrepublik Deutschland, 2004, Alle Rechte vorbehalten -Planung und Steuerung: Projektfortschrittsentscheidung- Projektfortschrittsentscheidung für InfoMaPa Projekt genehmigt Version: 1.1 Projektbezeichnung

Mehr

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 Agiles Vorgehen 2 Agiles Vorgehen 3 WAS BEDEUTET AGIL Abstimmung über Ziel (nicht konkretes Entwicklungsergebnis)

Mehr

Entwurf. Anwendungsbeginn E DIN EN 62304 (VDE 0750-101):2013-10. Anwendungsbeginn dieser Norm ist...

Entwurf. Anwendungsbeginn E DIN EN 62304 (VDE 0750-101):2013-10. Anwendungsbeginn dieser Norm ist... Anwendungsbeginn Anwendungsbeginn dieser Norm ist.... Inhalt Einführung... 13 1 Anwendungsbereich... 16 1.1 *Zweck... 16 1.2 *Anwendungsbereich... 16 1.3 Beziehung zu anderen Normen... 16 1.4 Einhaltung...

Mehr

Formularsammlung. zum methodischen Leitfaden. für eine effiziente Projektarbeit in. virtuellen Teams mit teamspace

Formularsammlung. zum methodischen Leitfaden. für eine effiziente Projektarbeit in. virtuellen Teams mit teamspace Formularsammlung zum methodischen Leitfaden für eine effiziente Projektarbeit in virtuellen Teams mit teamspace 2004 Ein Produkt der 5 POINT AG, Darmstadt - Internet Business Solutions - Inhalt Die vorliegenden

Mehr

Mit dem Blick für Details Den Antrieb von morgen gestalten

Mit dem Blick für Details Den Antrieb von morgen gestalten Mit dem Blick für Details Den Antrieb von morgen gestalten Automotive Engineering FMEA, XiL, OBD oder FFT die Automobilentwicklung ist abwechslungsreich. Dabei stehen immer komplexe, mechatronische Systeme

Mehr

Wie die in-step BLUE SPICE Edition for Automotive Ihre Organisation unterstützt, SPICE Level 3 zu erreichen

Wie die in-step BLUE SPICE Edition for Automotive Ihre Organisation unterstützt, SPICE Level 3 zu erreichen Wie die in-step BLUE SPICE Edition for Automotive Ihre Organisation unterstützt, SPICE Level 3 zu erreichen microtool GmbH Inhalte Wie die in-step BLUE SPICE Edition for Automotive Ihre Organisation unterstützt,

Mehr

be partner auf der IAA / VDA QMC 2013 Die wichtigsten Infos für Sie auf einen Blick!

be partner auf der IAA / VDA QMC 2013 Die wichtigsten Infos für Sie auf einen Blick! be partner auf der IAA / VDA QMC 2013 Die wichtigsten Infos für Sie auf einen Blick! 30.10.2013 30.10.2013 be partner: be successful Seite 1 Seite 1 Vorträge & Infos Die wichtigsten Informationen aus nachfolgend

Mehr

Release Management. Aktuelle Themen der Informatik. Oliver Schmid

Release Management. Aktuelle Themen der Informatik. Oliver Schmid Release Management Aktuelle Themen der Informatik Oliver Schmid Agenda Einführung Begriffsbestimmungen Release Identifikation Release Typen Release Management Prozess Release Richtlinien Release Planung

Mehr

Qualitätsmanagement im Projekt

Qualitätsmanagement im Projekt Software-Engineering Qualitätsmanagement im Projekt Vorlesung im Wintersemester 2008/2009 Fakultät Wirtschaftsinformatik Klaus Mairon, M.Sc. Inhalte Messen und Bewerten: Metriken in der Qualitätssicherung

Mehr

Agile Entwicklung nach Scrum

Agile Entwicklung nach Scrum comsolit AG Hauptstrasse 78 CH-8280 Kreuzlingen Tel. +41 71 222 17 06 Fax +41 71 222 17 80 info@comsolit.com www.comsolit.com Agile Entwicklung nach Scrum Seite 1 / 6 Scrum V 1.0 1. Wieso Scrum Die Entwicklung

Mehr

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013 Software Komponenten FS13 Gruppe 03 Horw, 16.04.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Estermann Michael

Mehr

Kosten- oder Nutzenfaktor?

Kosten- oder Nutzenfaktor? Projektmanagement im Mittelstand Kosten- oder Nutzenfaktor? Dipl.-Ing. Willi Wurl Rosenstraße 39 D-71543 Wüstenrot Prozess- & Projektmanagement 11. April 2006 0 Einleitung Situation in mittelständischen

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

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

Agile Softwareverträge

Agile Softwareverträge Zeitschrift Informatik-Spektrum der deutschen Gesellschaft für Informatik Ursula Sury Agile Softwareverträge AGILE SOFTWAREENTWICKLUNG Komplexität, steter Wandel, Umgang mit vielen Unbekannten das sind

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

csi Projektmanagement Methode Prozessbeschreibung Reifegradsteuerung

csi Projektmanagement Methode Prozessbeschreibung Reifegradsteuerung Prozessbeschreibung Reifegradsteuerung Reifegradsteuerung Ist-Situation Terminschiene aufnehmen Kritischen Pfade Meilensteine und deren Abhängigkeiten kennzeichnen Transparenz über die Terminsituation

Mehr