Best-Practice-Leitfaden Software-Release
|
|
- Nelly Kranz
- vor 8 Jahren
- Abrufe
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: zvei-be@zvei.org 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
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
MehrUnsere 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
MehrProzessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements. von Stephanie Wilke am 14.08.08
Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements von Stephanie Wilke am 14.08.08 Überblick Einleitung Was ist ITIL? Gegenüberstellung der Prozesse Neuer
MehrAnforderungen an die HIS
Anforderungen an die HIS Zusammengefasst aus den auf IBM Software basierenden Identity Management Projekten in NRW Michael Uebel uebel@de.ibm.com Anforderung 1 IBM Software Group / Tivoli Ein Feld zum
MehrAlbert HAYR Linux, IT and Open Source Expert and Solution Architect. Open Source professionell einsetzen
Open Source professionell einsetzen 1 Mein Background Ich bin überzeugt von Open Source. Ich verwende fast nur Open Source privat und beruflich. Ich arbeite seit mehr als 10 Jahren mit Linux und Open Source.
MehrSPI-Seminar : Interview mit einem Softwaremanager
Erstellung eines Fragenkatalogs der die Beurteilung der Level 2 Key Process Areas in einem ca. einstündigen Interview mit einem Software Manager ermöglicht Vortrag von Matthias Weng 1 Aufbau Geschichte
MehrWir beraten Sie. Wir unterstützen Sie. Wir schaffen Lösungen. Wir bringen Qualität. Wir beraten Sie. Wir unterstützen Sie. Wir schaffen Lösungen
Was bedeutet es, ein Redaktionssystem einzuführen? Vorgehensmodell für die Einführung eines Redaktionssystems Die Bedeutung Fast alle Arbeitsabläufe in der Abteilung werden sich verändern Die inhaltliche
MehrMit 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
MehrLeseauszug DGQ-Band 14-26
Leseauszug DGQ-Band 14-26 Einleitung Dieser Band liefert einen Ansatz zur Einführung von Prozessmanagement in kleinen und mittleren Organisationen (KMO) 1. Die Erfolgskriterien für eine Einführung werden
MehrProjektmanagement. Einleitung. Beginn. Was ist Projektmanagement? In dieser Dokumentation erfahren Sie Folgendes:
Projektmanagement Link http://promana.edulearning.at/projektleitung.html Einleitung Was ist Projektmanagement? In dieser Dokumentation erfahren Sie Folgendes: Definition des Begriffs Projekt" Kriterien
MehrDelta Audit - Fragenkatalog ISO 9001:2014 DIS
QUMedia GbR Eisenbahnstraße 41 79098 Freiburg Tel. 07 61 / 29286-50 Fax 07 61 / 29286-77 E-mail info@qumedia.de www.qumedia.de Delta Audit - Fragenkatalog ISO 9001:2014 DIS Zur Handhabung des Audit - Fragenkatalogs
MehrCheckliste zur qualitativen Nutzenbewertung
Checkliste zur qualitativen Nutzenbewertung Herausgeber Pentadoc Consulting AG Messeturm Friedrich-Ebert-Anlage 49 60308 Frankfurt am Main Tel +49 (0)69 509 56-54 07 Fax +49 (0)69 509 56-55 73 E-Mail info@pentadoc.com
MehrMachbar? 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!
MehrFormularsammlung. 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
MehrBeispielfragen L4(3) Systemauditor nach AS/EN9100 (1st,2nd party)
Allgemeine Hinweise: Es wird von den Teilnehmern erwartet, dass ausreichende Kenntnisse vorhanden sind, um die Fragen 1.1 bis 1.10 unter Verwendung der EN 9100 und ISO 19011 innerhalb von 20 Minuten zu
Mehr«PERFEKTION IST NICHT DANN ERREICHT, WENN ES NICHTS MEHR HINZUZUFÜGEN GIBT, SONDERN DANN, WENN MAN NICHTS MEHR WEGLASSEN KANN.»
«PERFEKTION IST NICHT DANN ERREICHT, WENN ES NICHTS MEHR HINZUZUFÜGEN GIBT, SONDERN DANN, WENN MAN NICHTS MEHR WEGLASSEN KANN.» www.pse-solutions.ch ANTOINE DE SAINT-EXUPÉRY 1 PROJECT SYSTEM ENGINEERING
MehrBeschreibung des MAP-Tools
1. Funktionen des MAP-Tool 2. Aufbau des MAP-Tools 3. Arbeiten mit dem MAP-Tool Beschreibung MAP-Tool.doc Erstellt von Thomas Paral 1 Funktionen des MAP-Tool Die Hauptfunktion des MAP-Tools besteht darin,
MehrTeil 2 Management virtueller Kooperation
Anwendungsbedingungen und Gestaltungsfelder 45 Teil 2 Management virtueller Kooperation Der strategischen Entscheidung über die Einführung telekooperativer Zusammenarbeit und die rüfung der Anwendungsbedingungen
MehrSDD System Design Document
SDD Software Konstruktion WS01/02 Gruppe 4 1. Einleitung Das vorliegende Dokument richtet sich vor allem an die Entwickler, aber auch an den Kunden, der das enstehende System verwenden wird. Es soll einen
MehrSoftware-Validierung im Testsystem
Software-Validierung im Testsystem Version 1.3 Einleitung Produktionsabläufe sind in einem Fertigungsbetrieb ohne IT unvorstellbar geworden. Um eine hundertprozentige Verfügbarkeit des Systems zu gewährleisten
MehrWarum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität
Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität Marcus Winteroll oose GmbH Agenda I. Ziele und Zusammenarbeit II. Was wir vom agilen Vorgehen lernen
MehrChristian 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
MehrProzessoptimierung. und. Prozessmanagement
Prozessoptimierung und Prozessmanagement Prozessmanagement & Prozessoptimierung Die Prozesslandschaft eines Unternehmens orientiert sich genau wie die Aufbauorganisation an den vorhandenen Aufgaben. Mit
MehrDok.-Nr.: Seite 1 von 6
Logo Apotheke Planung, Durchführung und Dokumentation von QM-Audits Standardarbeitsanweisung (SOP) Standort des Originals: Dok.-Nr.: Seite 1 von 6 Nummer der vorliegenden Verfaßt durch Freigabe durch Apothekenleitung
MehrFACHARTIKEL 2013 Software Programmierung, Testing und Implementierung zum Stichtag mithilfe von PERM-Domänen
FACHARTIKEL 2013 Software Programmierung, Testing und Implementierung zum Stichtag mithilfe von PERM-Domänen von Herbert Mittelbach Stichtage Von Herbert Mittelbach Stichtage haben stets eine besondere
MehrDie vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante
ISO 9001:2015 Die vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante Prozesse. Die ISO 9001 wurde grundlegend überarbeitet und modernisiert. Die neue Fassung ist seit dem
MehrSoftfolio 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
MehrGRS SIGNUM Product-Lifecycle-Management
GRS SIGNUM Product-Lifecycle-Management Das optionale Modul Product-Lifecycle-Management stellt eine mächtige Ergänzung zum Modul Forschung & Entwicklung dar. Folgende Punkte werden dabei abgedeckt: Definition
MehrSSI WHITE PAPER Design einer mobilen App in wenigen Stunden
Moderne Apps für Smartphones und Tablets lassen sich ohne großen Aufwand innerhalb von wenigen Stunden designen Kunde Branche Zur Firma Produkte Übersicht LFoundry S.r.l Herrngasse 379-381 84028 Landshut
MehrDas Pflichtenheft. Dipl.- Ing. Dipl.-Informatiker Dieter Klapproth Ains A-Systemhaus GmbH Berlin
Fragestellungen: Warum reicht das Lastenheft nicht aus? Was kann ich mit dem Lastenheft machen? Was unterscheidet das Pflichtenheft vom Lastenheft? Was gehört zum Auftragsumfang einer Individualsoftware?
MehrArbeitsmappe: Projektplanung Individualsoftware
Arbeitsmappe: Projektplanung Individualsoftware Whitepaper und technische Dokumentation Informationen zu diesem Dokument Autor: Tobias Eichner, tobias@starenterprise.com Datum der Erstveröffentlichung:
Mehr1 Mathematische Grundlagen
Mathematische Grundlagen - 1-1 Mathematische Grundlagen Der Begriff der Menge ist einer der grundlegenden Begriffe in der Mathematik. Mengen dienen dazu, Dinge oder Objekte zu einer Einheit zusammenzufassen.
MehrDatenübernahme von HKO 5.9 zur. Advolux Kanzleisoftware
Datenübernahme von HKO 5.9 zur Advolux Kanzleisoftware Die Datenübernahme (DÜ) von HKO 5.9 zu Advolux Kanzleisoftware ist aufgrund der von Update zu Update veränderten Datenbank (DB)-Strukturen in HKO
MehrFehler und Probleme bei Auswahl und Installation eines Dokumentenmanagement Systems
Fehler und Probleme bei Auswahl und Installation eines Dokumentenmanagement Systems Name: Bruno Handler Funktion: Marketing/Vertrieb Organisation: AXAVIA Software GmbH Liebe Leserinnen und liebe Leser,
MehrOptimierung Liefertreue
Optimierung Liefertreue Vorwort Sehr geehrter Lieferant! Nur gemeinsam mit Ihnen lässt sich die gesamte Wertschöpfungskette optimieren. Eine vertrauensvolle Zusammenarbeit, frühzeitige Einbindung und eine
MehrProfessionelle Seminare im Bereich MS-Office
Der Name BEREICH.VERSCHIEBEN() ist etwas unglücklich gewählt. Man kann mit der Funktion Bereiche zwar verschieben, man kann Bereiche aber auch verkleinern oder vergrößern. Besser wäre es, die Funktion
MehrZIELE erreichen WERTSTROM. IDEEN entwickeln. KULTUR leben. optimieren. KVP und Lean Management:
KVP und Lean Management: Damit machen wir Ihre Prozesse robuster, schneller und kostengünstiger. ZIELE erreichen WERTSTROM optimieren IDEEN entwickeln KULTUR leben 1 Lean Management Teil 1: Das Geheimnis
MehrMaintenance & 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
MehrSwissSupplyChain Musterprüfung
Prüfungsfach: Prüfungsdauer: 1 Stunde Maximale Punktzahl 60 Anzahl Aufgabenblätter 6 Anzahl Lösungsblätter... Bitte bei den Lösungsblättern nicht auf die Rückseite schreiben! Bitte beachten Sie: Sollten
MehrWAS finde ich WO im Beipackzettel
WAS finde ich WO im Beipackzettel Sie haben eine Frage zu Ihrem? Meist finden Sie die Antwort im Beipackzettel (offiziell "Gebrauchsinformation" genannt). Der Aufbau der Beipackzettel ist von den Behörden
MehrTechnische Dokumentation: wenn Englisch zur Herausforderung wird
Praxis Technische Dokumentation: wenn Englisch zur Herausforderung wird Anforderungsspezifikation, Requirements-Engineering, Requirements-Management, Terminologieverwaltung www.sophist.de Über Englischkenntnisse
MehrITIL und Entwicklungsmodelle: Die zwei Kulturen
Kombination von IT Service Management (ITIL) und Anwendungsentwicklung Kai Witte und Matthias Kaulke, München, den 30.03.2006 Rahmeninformationen Wo sind wir? Unternehmensdarstellung (1) Unabhängiges Beratungsunternehmen
MehrKünstliches binäres Neuron
Künstliches binäres Neuron G.Döben-Henisch Fachbereich Informatik und Ingenieurwissenschaften FH Frankfurt am Main University of Applied Sciences D-60318 Frankfurt am Main Germany Email: doeben at fb2.fh-frankfurt.de
MehrVermeiden Sie es sich bei einer deutlich erfahreneren Person "dranzuhängen", Sie sind persönlich verantwortlich für Ihren Lernerfolg.
1 2 3 4 Vermeiden Sie es sich bei einer deutlich erfahreneren Person "dranzuhängen", Sie sind persönlich verantwortlich für Ihren Lernerfolg. Gerade beim Einstig in der Programmierung muss kontinuierlich
MehrTaking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum
Taking RM Agile CLICK TO EDIT MASTER OPTION 1 Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Click to edit Master subtitle style Christian Christophoridis Requirements Management
MehrHäufig wiederkehrende Fragen zur mündlichen Ergänzungsprüfung im Einzelnen:
Mündliche Ergänzungsprüfung bei gewerblich-technischen und kaufmännischen Ausbildungsordnungen bis zum 31.12.2006 und für alle Ausbildungsordnungen ab 01.01.2007 Am 13. Dezember 2006 verabschiedete der
MehrAvira Server Security Produktupdates. Best Practice
Avira Server Security Produktupdates Best Practice Inhaltsverzeichnis 1. Was ist Avira Server Security?... 3 2. Wo kann Avira Server Security sonst gefunden werden?... 3 3. Was ist der Unterschied zwischen
MehrJava Enterprise Architekturen Willkommen in der Realität
Java Enterprise Architekturen Willkommen in der Realität Ralf Degner (Ralf.Degner@tk-online.de), Dr. Frank Griffel (Dr.Frank.Griffel@tk-online.de) Techniker Krankenkasse Häufig werden Mehrschichtarchitekturen
MehrStuPro-Seminar Dokumentation in der Software-Wartung. StuPro-Seminar Probleme und Schwierigkeiten in der Software-Wartung.
StuPro-Seminar Dokumentation in der Software-Wartung StuPro-Seminar Probleme und Schwierigkeiten in der Software-Wartung Folie 1/xx Software-Wartung: theoretisch Ausgangslage eigentlich simpel: fertige
MehrModul 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
MehrMünchen, 17.08.2011. Themenvorschläge für Abschlussarbeiten Zur Abstimmung mit Prof. Brecht
München, 17.08.2011 Themenvorschläge für Abschlussarbeiten Zur Abstimmung mit Prof. Brecht Am 04.08.2011 in Ulm wurde das Themengebiet als der zentrale Anknüpfungspunkt für Abschlussarbeiten definiert
MehrBacher Integrated Management
Ihre IT-Verantwortung wir tragen sie mit. Bacher Integrated Management Das zentrale IT-Infrastruktur Management-Portal BIM gibt den EINBLICK. Das zentrale IT-Infrastruktur Management-Portal von Bacher
MehrModul 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
MehrBarrierefreie Webseiten erstellen mit TYPO3
Barrierefreie Webseiten erstellen mit TYPO3 Alternativtexte Für jedes Nicht-Text-Element ist ein äquivalenter Text bereitzustellen. Dies gilt insbesondere für Bilder. In der Liste der HTML 4-Attribute
MehrLeichte-Sprache-Bilder
Leichte-Sprache-Bilder Reinhild Kassing Information - So geht es 1. Bilder gucken 2. anmelden für Probe-Bilder 3. Bilder bestellen 4. Rechnung bezahlen 5. Bilder runterladen 6. neue Bilder vorschlagen
MehrRegelwerk der "Electronical Infrastructure for Political Work"
Regelwerk der "Electronical Infrastructure for Political Work" Stand 01.06.11 Inhaltsverzeichnis 1.Inhalt...2 2.Codex...2 3.Arbeiten mit dem EIPW...2 3.1.Dokumente...2 3.2.Gestaltung der Arbeit...2 3.2.1.Einfachheit
MehrI n f o r m a t i o n s s i c h e r h e i t i n G e m e i n d e n B e v ö l k e r u n g s z a h l < 6 000
Leitfaden I n f o r m a t i o n s s i c h e r h e i t i n G e m e i n d e n B e v ö l k e r u n g s z a h l < 6 000 Inhalt 1 Einleitung... 2 2 Übersicht Dokumente... 2 3 Umsetzung der Anforderungen an
MehrIn diesem Tutorial lernen Sie, wie Sie einen Termin erfassen und verschiedene Einstellungen zu einem Termin vornehmen können.
Tutorial: Wie erfasse ich einen Termin? In diesem Tutorial lernen Sie, wie Sie einen Termin erfassen und verschiedene Einstellungen zu einem Termin vornehmen können. Neben den allgemeinen Angaben zu einem
MehrManaged 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
MehrOUTSOURCING ADVISOR. Analyse von SW-Anwendungen und IT-Dienstleistungen auf ihre Global Sourcing Eignung. Bewertung von Dienstleistern und Standorten
Outsourcing Advisor Bewerten Sie Ihre Unternehmensanwendungen auf Global Sourcing Eignung, Wirtschaftlichkeit und wählen Sie den idealen Dienstleister aus. OUTSOURCING ADVISOR Der Outsourcing Advisor ist
MehrInformationssicherheit als Outsourcing Kandidat
Informationssicherheit als Outsourcing Kandidat aus Kundenprojekten Frankfurt 16.06.2015 Thomas Freund Senior Security Consultant / ISO 27001 Lead Auditor Agenda Informationssicherheit Outsourcing Kandidat
MehrVersion smarter mobile(zu finden unter Einstellungen, Siehe Bild) : Gerät/Typ(z.B. Panasonic Toughbook, Ipad Air, Handy Samsung S1):
Supportanfrage ESN Bitte füllen Sie zu jeder Supportanfrage diese Vorlage aus. Sie helfen uns damit, Ihre Anfrage kompetent und schnell beantworten zu können. Verwenden Sie für jedes einzelne Thema jeweils
MehrDatensicherung. Beschreibung der Datensicherung
Datensicherung Mit dem Datensicherungsprogramm können Sie Ihre persönlichen Daten problemlos Sichern. Es ist möglich eine komplette Datensicherung durchzuführen, aber auch nur die neuen und geänderten
MehrBüroWARE Exchange Synchronisation Grundlagen und Voraussetzungen
BüroWARE Exchange Synchronisation Grundlagen und Voraussetzungen Stand: 13.12.2010 Die BüroWARE SoftENGINE ist ab Version 5.42.000-060 in der Lage mit einem Microsoft Exchange Server ab Version 2007 SP1
MehrEinführung und Motivation
Einführung und Motivation iks-thementag: Requirements Engineering 16.11.2010 Autor Carsten Schädel Motto Definiere oder Du wirst definiert. Seite 3 / 51 These Im Privatleben definiert jeder (seine) Anforderungen.
MehrLineargleichungssysteme: Additions-/ Subtraktionsverfahren
Lineargleichungssysteme: Additions-/ Subtraktionsverfahren W. Kippels 22. Februar 2014 Inhaltsverzeichnis 1 Einleitung 2 2 Lineargleichungssysteme zweiten Grades 2 3 Lineargleichungssysteme höheren als
MehrHilfe, mein SCRUM-Team ist nicht agil!
Hilfe, mein SCRUM-Team ist nicht agil! Einleitung: Laut unserer Erfahrung gibt es doch diverse unagile SCRUM-Teams in freier Wildbahn. Denn SCRUM ist zwar eine tolle Sache, macht aber nicht zwangsläufig
MehrCheckliste fu r Lieferanten
1 Checkliste fu r Lieferanten Um die Daten in den E- Control Tarifkalkulatoren (TK Neu Haushalte, TK Gewerbe und TK Admintool Neu) vor ihren Livegang zu vervollständigen und zu aktualisieren, sollen die
MehrMobile Intranet in Unternehmen
Mobile Intranet in Unternehmen Ergebnisse einer Umfrage unter Intranet Verantwortlichen aexea GmbH - communication. content. consulting Augustenstraße 15 70178 Stuttgart Tel: 0711 87035490 Mobile Intranet
MehrDiplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008
Konzeption und Implementierung einer automatisierten Testumgebung, 10. Dezember 2008 1 Gliederung Einleitung Softwaretests Beispiel Konzeption Zusammenfassung 2 Einleitung Komplexität von Softwaresystemen
MehrSoftwaretests in Visual Studio 2010 Ultimate Vergleich mit Java-Testwerkzeugen. Alexander Schunk Marcel Teuber Henry Trobisch
Softwaretests in Visual Studio 2010 Ultimate Vergleich mit Java-Testwerkzeugen Alexander Schunk Henry Trobisch Inhalt 1. Vergleich der Unit-Tests... 2 2. Vergleich der Codeabdeckungs-Tests... 2 3. Vergleich
MehrAgile 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
MehrPlanung, Auswahl und Ingest
Planung des Forschungsdaten-Managements: Planung, Auswahl und Ingest Gabriel Stöckle ZAH Heidelberg gst@ari.uni-heidelberg.de Überblick Planung Ziele des Projekts Beziehung zu vorhandene Daten Bewertung
Mehrrobotron*e count robotron*e sales robotron*e collect Anmeldung Webkomponente Anwenderdokumentation Version: 2.0 Stand: 28.05.2014
robotron*e count robotron*e sales robotron*e collect Anwenderdokumentation Version: 2.0 Stand: 28.05.2014 Seite 2 von 5 Alle Rechte dieser Dokumentation unterliegen dem deutschen Urheberrecht. Die Vervielfältigung,
MehrFragebogen zur Anforderungsanalyse
Fragebogen zur Anforderungsanalyse Geschäftsprozess Datum Mitarbeiter www.seikumu.de Fragebogen zur Anforderungsanalyse Seite 6 Hinweise zur Durchführung der Anforderungsanalyse Bevor Sie beginnen, hier
MehrIntegrierte IT Portfolioplanung
Integrierte Portfolioplanung -en und _e als zwei Seiten einer Medaille Guido Bacharach 1.04.010 Ausgangssituation: Komplexe Umgebungen sportfolio Ausgangssituation: Komplexe Umgebungen portfolio Definition:
Mehrconuno - WIR GESTALTEN FÜR SIE Development Services
conuno - WIR GESTALTEN FÜR SIE Development Services Beratung für Finanzdienstleister Innovative Produktlösungen IT Services & Sourcing c o n s u l t i n g g e s t a l t e n s o f t w a r e g e s t a l
MehrProjektanleitung zum
Web Business Manager Projektanleitung zum Diploma-Abschlussprojekt.......................................................... Offizielles Curriculum des Europäischen Webmasterverbandes Web Business Manager
Mehr[Customer Service by KCS.net] KEEPING CUSTOMERS SUCCESSFUL
[Customer Service by KCS.net] KEEPING CUSTOMERS SUCCESSFUL Was bedeutet Customer Service by KCS.net? Mit der Einführung von Microsoft Dynamics AX ist der erste wichtige Schritt für viele Unternehmen abgeschlossen.
MehrCode of Conduct (CoC)
Code of Conduct (CoC) Aeiforia CoC-Check: Erkennen Sie Auswirkungen des CoC auf Ihr Unternehmen! Aeiforia hat ein auf Checklisten gestütztes Vorgehen entwickelt, mit dem Sie Klarheit erlangen, in welchen
MehrWann ist eine Software in Medizinprodukte- Aufbereitungsabteilungen ein Medizinprodukt?
DGSV-Kongress 2009 Wann ist eine Software in Medizinprodukte- Aufbereitungsabteilungen ein Medizinprodukt? Sybille Andrée Betriebswirtin für und Sozialmanagement (FH-SRH) Prokuristin HSD Händschke Software
MehrInformationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse:
Informationssystemanalyse Problemstellung 2 1 Problemstellung Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse: große Software-Systeme werden im Schnitt ein Jahr zu spät
MehrD i e n s t e D r i t t e r a u f We b s i t e s
M erkblatt D i e n s t e D r i t t e r a u f We b s i t e s 1 Einleitung Öffentliche Organe integrieren oftmals im Internet angebotene Dienste und Anwendungen in ihre eigenen Websites. Beispiele: Eine
MehrBeratung, Projektmanagement und Coaching
new solutions GmbH IT Consulting 2 IT Consulting Software Development IT Training Software Products Beratung, Projektmanagement und Coaching new solutions business software 3 --- Die Experten der new solutions
MehrVorbereitung. Zwischenevaluierung Research Studios Austria
Vorbereitung Zwischenevaluierung Research Studios Austria Herbst 2009 Inhaltsverzeichnis 1. Wer evaluiert?... 2 2. Was wird inhaltlich geprüft?... 2 3. Was wird wirtschaftlich geprüft?... 2 4. Wie sieht
MehrQualifikationsbereich: Application Engineering Zeit:
Höhere Fachprüfung ICT-Manager Musterprüfung 2015 Höhere Fachprüfung ICT-Manager Muster KAF Zeit: Die Lösungen sind auf diese Arbeitsblätter zu schreiben. Es werden nur die Lösungen auf den Arbeitsblättern
MehrLeitfaden. zur Einführung neuer Studiengänge
Leitfaden zur Einführung neuer Studiengänge Entstehung des Leitfadens Einführung neuer Studiengänge Die Grundlagen des Leitfadens wurden auf der Basis des bisherigen Verfahrens in einer Workshopreihe des
MehrDaten-Synchronisation zwischen Mozilla Thunderbird (Lightning) / Mozilla Sunbird und dem ZDV Webmailer
Daten-Synchronisation zwischen Mozilla Thunderbird (Lightning) / Mozilla Sunbird und dem ZDV Webmailer Zentrum für Datenverarbeitung der Universität Tübingen Inhaltsverzeichnis 1.Synchronisation...aber
MehrDER SELBST-CHECK FÜR IHR PROJEKT
DER SELBST-CHECK FÜR IHR PROJEKT In 30 Fragen und 5 Tipps zum erfolgreichen Projekt! Beantworten Sie die wichtigsten Fragen rund um Ihr Projekt für Ihren Erfolg und für Ihre Unterstützer. IHR LEITFADEN
MehrOutsourcing und Offshoring. Comelio und Offshoring/Outsourcing
Outsourcing und Offshoring Comelio und Offshoring/Outsourcing INHALT Outsourcing und Offshoring... 3 Comelio und Offshoring/Outsourcing... 4 Beauftragungsmodelle... 4 Projektleitung vor Ort und Software-Entwicklung
MehrAnmeldeverfahren. Inhalt. 1. Einleitung und Hinweise
Anmeldeverfahren Inhalt In dieser Anleitung finden Sie eine detaillierte Beschreibung der verschiedenen Anmeldeverfahren bzw. Zugangsberechtigungen anhand der verschiedenen Szenarien, die für Sie in der
MehrTestplan. 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
MehrSEO Erfolg mit themenrelevanten Links
Hinweis für Leser Dieser Leitfaden soll Ihnen einen Überblick über wichtige Faktoren beim Ranking und Linkaufbau liefern. Die Informationen richten sich insbesondere an Website-Betreiber, die noch keine
Mehryour 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
MehrFAQ 04/2015. Auswirkung der ISO 14119 auf 3SE53/3SF13 Positionsschalter. https://support.industry.siemens.com/cs/ww/de/view/109475921
FAQ 04/2015 Auswirkung der ISO 14119 auf 3SE53/3SF13 Positionsschalter mit https://support.industry.siemens.com/cs/ww/de/view/109475921 Dieser Beitrag stammt aus dem Siemens Industry Online Support. Es
MehrInhalt. 1 Einleitung AUTOMATISCHE DATENSICHERUNG AUF EINEN CLOUDSPEICHER
AUTOMATISCHE DATENSICHERUNG AUF EINEN CLOUDSPEICHER Inhalt 1 Einleitung... 1 2 Einrichtung der Aufgabe für die automatische Sicherung... 2 2.1 Die Aufgabenplanung... 2 2.2 Der erste Testlauf... 9 3 Problembehebung...
MehrFallbeispiel. Auswahl und Evaluierung eines Software- Lokalisierungstools. Tekom Herbsttagung 2004 Angelika Zerfaß
Fallbeispiel Auswahl und Evaluierung eines Software- Lokalisierungstools Tekom Herbsttagung 2004 Angelika Zerfaß Beratung und Training für Translation Tools Projekt: Software-Lokalisierungstool Die Firma
MehrSoftware Engineering. Sommersemester 2012, Dr. Andreas Metzger
Software Engineering (Übungsblatt 2) Sommersemester 2012, Dr. Andreas Metzger Übungsblatt-Themen: Prinzip, Technik, Methode und Werkzeug; Arten von Wartung; Modularität (Kohäsion/ Kopplung); Inkrementelle
MehrWholesale und FTTH. Handbuch Abrechnung 1/5. Ausgabedatum 01.05.2015 Ersetzt Version 2-0. Swisscom (Schweiz) AG CH-3050 Bern
Ausgabedatum 005.2015 Ersetzt Version 2-0 Gültig ab 005.2015 Gültig ab 005.2015 1/5 Inhaltsverzeichnis 1 Einleitung... 3 2 Rechnungsstellung... 3 3 Rechnungen... 3 4 Zahlungen... 4 5 Widerspruch gegen
Mehr