Normkonforme Medizinproduktentwicklung

Größe: px
Ab Seite anzeigen:

Download "Normkonforme Medizinproduktentwicklung"

Transkript

1 Agile Methoden in der Medizintechnik mit agilen Prozessen und Artefakten Marc Bless Version Mai 2012, Baden-Baden

2 Inhaltsverzeichnis Vorwort 4 Von der Norm zum Prozess: des Meta-Prozesses 7 Überblick der Prozesse und Artefakte 10 Prozesse, Meetings, Reviews 12 Acceptance Testing 13 Clean Code / SOLID Principles 14 Continuous Integration 16 Early Integration / Early Testing 17 Exploratory and Manual Testing 18 Integration Testing 19 Problem Communication 20 Product Backlog Grooming 21 Quality Management Prozess 23 Release Planning Meeting 24 Risk Analysis and Management 25 Scrum 27 Software Maintenance Process 28 Sprint Planning 29 Sprint Retrospective 31 Sprint Review 32 Team Kick-Off Meeting 34 Test Automation 35 Version 0.1 /

3 Test-Driven Design (TDD) 37 Unit Testing 39 Usability Process 40 Zero Bug Tolerance 41 Dokumente, Artefakte, Pläne 43 Architecture Documentation 44 Definition of Done 45 Definition of Ready 47 Iteration Notes 49 Linkable IDs 50 Product Backlog 51 Release Notes 53 Software Development Plan 54 Software Maintenance Plan 56 Sprint Development Plan = Sprint Backlog 57 Team Charter / Working Agreements 59 Test Documentation 61 User Story 62 Versioning System 64 Historie und Ausblick 66 Version 0.1 /

4 Vorwort Medizintechnik und die Entwicklung entsprechender Medizinprodukte befinden sich in einem regulierten Umfeld. Gesetze, Normen und Richtlinien geben mehr oder weniger harte Rahmenbedingungen vor, in deren Grenzen ein Medizinprodukt umgesetzt werden darf. Lange Entwicklungszeiten für Produktlebenszyklen sind wirtschaftlich heutzutage nicht mehr sinnvoll. Eine kurze Time-to-Market wird immer wichtiger, um den Marktbegleitern einen Schritt voraus zu sein und innovative Produktideen schnell als erster am Markt platzieren zu können. Der Kunde eines Medizinproduktes wird immer mündiger und entscheidet selbst über den Erfolg einzelner Produkte und Dienstleistungen. Dies erfordert bereits bei der Entstehung neuer Produktideen eine gewisse Nähe zum Anwender oder sogar die entwicklungsbegleitende Einbindung echter Anwender. In traditionellen Vorgehensweisen kann der Anwendungserfolg oft erst ganz am Ende des Prozesses ermittelt werden. Ein entsprechendes Reagieren auf Kunden und Anwender sowie deren wertvolles Feedback kann dann erst in einem nächsten Produkt, Projekt oder Release stattfinden und sich auswirken. Der Kunde bewertet ein Produkt nicht nur nach seinen Funktionen und der einfachen Handhabung, sondern auch nach seiner Qualität und Fehlerfreiheit. Dabei spielen oft schon Kleinigkeiten eine große Rolle, die zu einer negativen Bewertung eines Produktes führen können. In sozialen Netzwerken und Produktbewertungsportalen multiplizieren sich diese Effekte mittlerweile soweit, dass wir feststellen müssen: über Sieg oder Niederlage eines Produktes kann heute die breite Masse der Anwender entscheiden, unabhängig von Marketing- und Werbemaßnahmen. Der Einsatz agiler Management- und Entwicklungsmethoden liegt auf der Hand. Schnelle Entwicklungszyklen, Einbindung und Feedback echter Anwender, sowie höchste Qualitätsansprüche können durch agile Methoden nachhaltig realisiert werden. Des weiteren haben agile Methoden in den letzten Jahren ein breites Publikum erreicht und sind in aller Munde. Viele Versprechen, aber auch Missverständnisse kursieren bezüglich agiler Methoden: Scrum ist chaotisch. Jeder macht, was er will. Es wird nichts mehr dokumentiert. Scrum funktioniert nur bei kleinen Web-Projekten. Version 0.1 /

5 Agilität funktioniert nicht bei komplexen Medizintechnik-Projekten. Agile Methoden funktionieren in unserer Organisation nicht. Scrum ist die Lösung all unserer Probleme. Durch Agilität werden wir effizienter. Die IEC beschreibt einen konkreten Software-Life-Cycle-Prozess und muss eins-zueins umgesetzt werden. Wir müssen ein V-Modell einsetzen, um normkonform zu arbeiten. Die Kombination der agilen Welt und des regulierten Umfeldes der Medizinproduktentwicklung bereitet vielen Leuten Kopfzerbrechen und führt zu großer Unsicherheit. In dieser Unsicherheit lauert die Gefahr, agile Methoden in bestehende, normkonforme Prozesse zu pressen, ohne dass sich der Vorteil echter Agilität entfalten kann. Eine vereinfachte, beschränkte oder missverstandene Anwendung agiler Methoden kann dazu führen, dass das Scheitern eines Produktes oder Projektes eben diesen agilen Methoden zugerechnet wird: Agil haben wir schon probiert, das hat ja auch nicht funktioniert. Agil hat bei uns alles nur schlimmer gemacht. Scrum hat uns mit Problemen konfrontiert, die wir vorher gar nicht hatten. Können beide Welten effektiv nebeneinander existieren? Wie viel Agilität passt in die normativen Anforderungen? Welche agilen Praktiken eignen sich für einen regulierten Entwicklungsprozess? Die grundsätzliche Frage lautet: wie kann die Normkonformität agiler Prozesse und Methoden nachgewiesen werden? Dieses Dokument beschreibt den Prozess, mit dessen Hilfe die Anforderungen aus der IEC an den Software-Life-Cycle-Prozess zu konkreten agilen und traditionellen Praktiken transferiert wurden. Diese anwendbaren Praktiken werden im Detail beschrieben und können gesamtheitlich als reines Scrum betrachtet werden mit entsprechenden Erweiterungen, um die normativen Anforderungen an den Software-Life-Cycle abzubilden. Zukünftige Ausgaben dieses Dokumentes werden die Normen 14971, und e- benso einbinden und abgeleitete Praktiken beschreiben. Des weiteren ist die Einbindung von Praktiken geplant, welche einen agilen, FDA-konformen Entwicklungsprozess ermöglichen. Version 0.1 /

6 Das vorliegende Dokument beschreibt eine vollständige, IEC konforme Implementierung von Scrum als Projektmanagementmethode sowie agilen Entwicklungspraktiken aus dem Extreme Programming. Ich freue mich auf Fragen, Feedback und konstruktive Kritik der Leserschaft und bedanke mich vorab für das Interesse an der Thematik. Marc Bless Baden-Baden, Juni 2012 Version 0.1 /

7 Marc Bless Von der Norm zum Prozess: des Meta-Prozesses Um zu einem normkonformen Prozess zu gelangen, bin ich vorgegangen, wie im Folgenden beschrieben. Anforderungen an den Software-Life-Cycle-Prozess Zunächst habe ich die Struktur der IEC vollständig aufgebrochen. Aus den einzelnen Kapiteln, Sektionen und jedem darin enthaltenen Paragraphen habe ich die eigentlichen Anforderungen an einen Software-Life-Cycle-Prozess extrahiert. Abgeleitete Anforderungen: Der Prozess - Teil 1/2 IEC Kapitel & Sektionen Paragraphen Anforderungen Marc Bless Scrum und die IEC Wie soll das gehen? --- ScrumMed 2012, agile coach.de Die Struktur der Norm suggeriert einen sequentiellen Entwicklungsablauf, der einem agilen Ansatz im Wesen widerspricht. Gleichzeitig stecken in dieser Struktur viele redundante Anforderungen, die zu einem sequentiellen Ablauf eher orthogonalen Charakter haben, wie zum Beispiel das gesamte Thema Risikomanagement. agile coach.de Version 0.1 /

8 Aus diesem Grund ordnete ich die Anforderungen neuen Clustern zu, welche einzelne Entwicklungsthematiken inhaltlich abgeschlossen handhabbar machten. Eine für uns grundlegende Aussage der Norm lautet: agile Vorgehensweisen sind (erlaubt und) möglich. ( Jeder beliebige wasserfallartige, iterative oder evolutionäre Prozess kann verwendet werden. ) Dokumente und Prozesse Den Anforderungen in den Clustern wurden konkrete agile und klassische Praktiken und Artefakte zugeordnet. Die Zuordnungen einzelner Praktiken und Artefakte zu einzelnen Anforderungen habe ich so vollständig vorgenommen, dass die Gesamtmenge aller normativen Anforderungen vollständig erfüllt wird. Jede einzelne Zuordnung ist schriftlich begründet, um einen Nachweis der Anforderungserfüllung führen zu können. Das Ergebnis aller Praktiken und Artefakte mitsamt ihrer Begründungen findet sich im Hauptteil dieses Dokuments. Das wichtigste Prinzip für die Zuordnung von Praktiken und Artefakten ist Simplicity (Einfachheit) und bedeutet, die minimale, aber vollständige Befriedigung der normativen Anforderungen zu finden. Praktiken sind dabei im Wesentlichen Prozesse, Reviews, Meetings, Besprechungen und Workshops. Unter Artefakten verstehen wir sämtliche Dokumente, Ergebnisse, funktionierende Software, Pläne und en, welche im Entwicklungsverlauf entstehen und eine Rolle spielen. Nachweis der Normkonformität Der Nachweis der Normkonformität wird aus kopierrechtlichen Gründen nicht in diesem Dokument geführt. Da die Originalquellen und Anforderungen der Normen nicht bei den Zuordnungen der Praktiken und Artefakte beschrieben sind, mag es an manchen Stellen nicht offensichtlich sein, für welche Anforderung und aus welchem Grund eine bestimmte Praktik oder ein Artefakt Normkonformität herstellt. Der interessierte Leser darf sich gerne an den Autoren wenden, um mehr über das Thema Nachweis der Normkonformität zu erfahren. Grundsätzlich können zwei Anwendungsfälle unterschieden werden. Der Abgleich der normativen Anforderungen mit einem bestehenden (agilen oder klassischen) Life-Cycle-Prozess ist ein sehr aufwändiges, aber notwendiges Verfahren, um die Normkonformität des beste- Version 0.1 /

9 henden Prozesses nachzuweisen. Im Gegensatz dazu führt die Ableitung eines neuen, normkonformen Prozesses zu einer vollständigen Scrum-Umsetzung mit minimalem Tailoring. (Scrum steht hierbei nur für eine mögliche agile Referenzimplementierung, es können beliebige andere Vorgehensmodelle oder Prozessframeworks modelliert werden. Der in diesem Dokument vorgestellte Ansatz beschreibt eine vollständige Scrum-Implementierung.) Der Aufwand für diese Ableitung ist ebenfalls nicht unerheblich, wird jedoch durch die Gewissheit über die Normkonformität relativiert. Abgeleitete Anforderungen: Der Prozess - Teil 2/2 Anforderungen Dokumente Artefakte Prozesse Reviews Meetings Simplicity = Einfachheit: Minimale, aber vollständige Befriedigung der normativen Anforderungen Abgleich mit (bestehendem) Life-Cycle-Prozess Nachweis der Normkonformität Marc Bless Scrum und die IEC Wie soll das gehen? --- ScrumMed 2012, Abschließend lässt sich sagen: Scrum und die Norm IEC harmonieren perfekt miteinander, benötigen minimales Tailoring, widersprechen sich nicht und verfolgen ähnliche Zielsetzungen. Version 0.1 /

10 Überblick der Prozesse und Artefakte Das nachfolgende Diagramm zeigt den gesamten Überblick aller Prozesse und Artefakte, welche aus normativen und gewünschten agilen Gründen benötigt werden. Im folgenden Hauptteil dieses Dokumentes werden die einzelnen Praktiken und Artefakte im Detail beschrieben in jeweils eigenen Kapiteln. Die Struktur dieser einzelnen Kapitel ist folgendermaßen aufgebaut: - kurze Erklärung der Praktik oder des Artefaktes für das bessere Verständnis, welche Absicht dahintersteckt und welche Ergebnisse erwartet werden. - Liste der üblicherweise beteiligten Rollen für eine bessere Einschätzung, welche Rollen in einem bestehenden Unternehmenskontext für den Einsatz der Praktik oder des Artefaktes in Frage kommen. Die in diesem Dokument aufgeführten Rollen müssen nicht genau so übernommen werden, sie dienen eher dem Aufzeigen potentieller, sinnvoller Möglichkeiten. Version 0.1 /

11 - Liste von Büchern, Artikeln und Webseiten, welche sich mit der Praktik oder dem Artefakt detailliert auseinandersetzen. - Liste der direkt aus dem Normtext abgeleiteten Anforderungen an den Software-Life-Cycle-Prozess. Hinweis: aus Copyright-Gründen sind diese Listen mit Norminhalten nicht in diesem Dokument enthalten. - Durchzuführende Maßnahmen und Aktivitäten sowie Begründungen, weswegen die beschriebene Praktik oder das Artefakt zur Herstellung der Normkonformität benötigt wird. Version 0.1 /

12 Prozesse, Meetings, Reviews Version 0.1 /

13 Acceptance Testing Process Akzeptanz-Tests sind ein grundlegender Bestandteil von (agilen) Anforderungen. Durch ihre Einhaltung wird sichergestellt, dass (a) die gewünschten Anwenderbedürfnisse befriedigt werden, (b) die umgesetzte Funktionalität durch geprüfte Schnittstellen integriert werden kann und (c) die Anforderung als "fertig" (done) betrachtet werden kann. Product Owner Entwicklungs-Team Lisa Crispin - Agile Testing Mit Hilfe von definierten Akzeptanz-Tests wird sichergestellt, dass das erstellte Software- Produkt die Bedürfnisse der Anwender befriedigt und die Anforderungen korrekt umgesetzt wurden. Mit Hilfe von Akzeptanz-Tests wird sichergestellt, dass eine in Software umgesetzte Anforderung abgekapselt funktioniert und damit für eine Integration in andere Strukturen bereit ist. Durch Akzeptanztests wird sichergestellt, dass die entwickelte Software entsprechende Akzeptanzkriterien befriedigt. Akzeptanztests entsprechen Black-Box-Tests. Version 0.1 /

14 Clean Code / SOLID Principles Process Clean Code ist ein Wertesystem zur Professionalisierung der Software-Entwicklung. In ihm sind viele Good Practices und grundlegende Prinzipien enthalten, welche durch die Erfahrungen in den letzten Jahrzehnten als gültig und korrekt betrachtet werden können. Bekannter sind in erster Linie die fünf SOLID-Prinzipien: Single Responsibility Principle SRP Eine Klasse darf nur aus einem Grund geändert werden. Open Closed Principle OCP Eine Klasse muss offen sein für Erweiterungen, aber geschlossen gegen Modifikationen. Liskov Substitution Principle LSP Eine abgeleitete Klasse verhält sich immer so wie ihre Basisklasse. Interface Segregation Principle ISP Clients werden nicht mit Details versehen, die sie nicht benötigen. Dependency Inversion Principle DIP Klassen hoher Ebenen sollen nicht von Klassen niedriger Ebenen abhängig sein, sondern beide sollen von Interfaces/Abstraktionen abhängen. Interfaces sollen nicht von Details abhängen, sondern Details von Interfaces. Entwicklungs-Team Version 0.1 /

15 Robert C. Martin - Clean Code Durch die korrekte Anwendung objekt-orientierter Prinzipien wie "Separation of Concerns" und "Single Responsibility Principle" entstehen lose gekoppelte Architekturen. Durch die Anwendung objekt-orientierter Prinzipien wird die Aufteilung von Software-Einheiten in weitere Einheiten getrieben. Modernes Software-Engineering wird umgesetzt mit der Anwendung von Clean Code und SOLID-Prinzipien, TDD, Unit Tests, Design Patterns und vielen anderen Methoden, die hier nicht vollständig aufgeführt werden können. Version 0.1 /

16 Continuous Integration Process Kontinuierliche Integration beschreibt den Prozess des regelmäßigen, vollständigen Neubildens und Testens einer Anwendung. Jeder Entwickler checkt seine Änderungen früh und regelmäßig (mindestens täglich) in eine Versionsverwaltung ein. Von dort aus wird das gesamte System neu gebaut und automatisch getestet, damit die Entwickler schnellstmöglich auf vorhandene Fehler im System aufmerksam gemacht werden können. Entwicklungs-Team Konsequent angewandte Continuous Integration ist die Aktivität, durch welche eine frühzeitige Integration aller beteiligten Komponenten inklusive der dazugehörigen Integrationstests sichergestellt wird. Die einzelnen Software-Einheiten werden kontinuierlich integriert. Kontinuierliche Integration bedient sich eines Versionierungssystems, um jederzeit kleine Änderungen am System integrieren zu können. Kontinuierliche Integration benötigt eine funktionierende Test-Automatisierung, um ihren Nutzen entfalten zu können. Version 0.1 /

17 Early Integration / Early Testing Process Frühzeitige Integration und frühzeitiges Testen sind zum Einen Konzepte der kontinuierlichen Integration mit Test-Automation, zum Anderen können sie auch entwicklungsbegleitend manuell durchgeführt werden. Im Extremfall können Anforderungen vor ihrer eigentlichen Umsetzung bereits getestet werden (Test-First Development). Das darunterliegende Prinzip heißt "Schnelles Scheitern" (Fail Fast). Wir möchten so schnell wie möglich wissen, dass unser Vorhaben nicht erfolgreich sein kann. Entwicklungs-Team James Shore - The Art of Agile Development (Kapitel 13.2) Anforderungen können bereits vor ihrer endgültigen Umsetzung getestet und integriert werden. Frühe Integration bedient sich eines Versionierungssystems, um Änderungen am System sofort integrieren zu können. Version 0.1 /

18 Exploratory and Manual Testing Process Neben einer funktionierenden Test-Automation beschäftigen sich agile, entwicklungsbegleitende Tester mit explorativem und manuellem Testen des Systems. Entwicklungs-Team Lisa Crispin - Agile Testing Exploratives Testen entspricht Black-Box-Tests. Die benötigte Test Dokumentation wird mit den Ergebnissen der explorativen und manuellen Tests angereichert. Version 0.1 /

19 Integration Testing Process Integrations-Tests stellen sicher, dass sich die einzelnen Teile eines entwickelten System miteinander verbinden lassen und ein funktionierendes Ganzes entsteht. Entwicklungs-Team Lisa Crispin - Agile Testing Integrations-Tests entsprechen Black-Box-Tests bezüglich der Schnittstellen einzelner Systemkomponenten und White-Box-Tests bezüglich der System-Architektur. Die Software-Integration wird durch Integrationstests verifiziert. Die integrierten Software-Einheiten werden durch Integrationstests verifiziert. Durch Test- Automation kann eine Dokumentation der Testergebnisse erzeugt werden. Integrations- sowie System-Tests können mit Simulationen, Prototypen und Mocks durchgeführt werden. Version 0.1 /

20 Problem Communication Process Ein Problem-Kommunikationsprozeß wird dafür eingesetzt, Stakeholder, Anwender, Kunden und allgemein alle am Produkt interessierten Personen darüber zu informieren, welche Fehler und Probleme sich in dem Produkt befinden und behoben bzw. nicht länger benutzt werden sollten. Product Owner keine Probleme und deren Konsequenzen werden über einen "Problem Communication"-Prozeß an Anwender kommuniziert. Einzubindende Stakeholder werden durch einen "Problem Communication"-Prozeß über die Existenz eines Problems informiert. Version 0.1 /

21 Product Backlog Grooming Process Im Product Backlog Grooming Meeting wird von Product Owner und Team bewertet, welche Änderungen sich am Produkt durch Anforderungen (z.b. Änderungsanträge und User Stories) ergeben. Die Entscheidung darüber, welche Anforderungen umgesetzt werden sollen, liegt einzig und alleine beim Product Owner. Product Owner Entwicklungs-Team Scrum Master Im Product Backlog Grooming Meeting werden bestehende Anforderungen und User Stories im Product Backlog neu bewertet und aktualisiert. Der Product Owner läßt im Product Backlog Grooming Meeting neue und geänderte Anforderungen vom Team bewerten und erteilt deren Freigabe durch Aufnahme und Einsortierung in sein Product Backlog. Im Product Backlog Grooming Meeting werden neue und geänderte Anforderungen auf ihren Einfluß auf bestehende Produkte und Systeme untersucht. Version 0.1 /

22 Im Product Backlog Grooming Meeting durchlaufen neue und geänderte Anforderungen den Risikomanagement-Prozess, um neue Risiko-Maßnahmen abzuleiten. Im Product Backlog Grooming Meeting durchlaufen neue und geänderte Anforderungen den Risikomanagement-Prozess, um sie mit bestehenden Risiko-Maßnahmen abzugleichen. Im Product Backlog Grooming Meeting werden Fehler- und Problem-Berichte bewertet und ihr Einfluß auf die Sicherheit bestehender Produkte und Systeme festgestellt, um notwendige Anforderungsänderungen im Product Backlog abzuleiten. Im Product Backlog Grooming werden notwendige Änderungen am System diskutiert und für die Entwicklung freigegeben. Im Product Backlog Grooming werden Probleme und Fehler von bereits releaster Software besprochen. Im Product Backlog Grooming werden die Funktionalitäten und Performance-Anforderungen an einzusetzende SOUP-Komponenten definiert. Im Product Backlog Grooming werden Änderungen an der Software analysiert, bewertet und ins Product Backlog einsortiert. Damit durchlaufen Änderungen den gleichen Entwicklungsprozeß wie Anforderungen und User Stories. Im Backlog Grooming werden die Anforderungen an Hardware und Software identifiziert, welche durch den Einsatz von SOUP notwendig werden. Im Product Backlog Grooming wird das Product Backlog kontinuierlich überarbeitet und angepasst. Im Product Backlog Grooming werden User Stories erstellt, verfeinert, abgeschätzt, verworfen und in einzelne User Stories aufgesplittet. Version 0.1 /

23 Quality Management Prozess Process Ein zertifiziertes Qualitätsmanagementsystem (z.b. nach ISO 13485) für medizinische Produkte wird dafür genutzt, die Normkonformität für Medizinproduktentwicklungen nachzuweisen und damit deren Marktfreigabe zu erwirken. Qualitätsmanager Scrum Master ISO Ein Qualitäts-Management-Prozess ist definiert und wird eingesetzt. Version 0.1 /

24 Release Planning Meeting Process Im Release Planning wird regelmäßig darüber entschieden, welcher Inhalt/Scope in die Produktentwicklung einfließen soll und welche Zeiträume und Meilensteine sich daraus ergeben. Product Owner Entwicklungs-Team Im Release Planning findet die Vorbewertung und Priorisierung statt für Probleme und Fehler von bereits releaster Software. Das Release Planning unterscheidet nicht, ob ein Release aus neuen Anforderungen besteht oder aus Änderungen an einem bestehenden System. Im Release Planning wird festgelegt, ob ein Release als vollständiges System-Release erstellt wird oder als Patch zu einem bestehenden System-Release. Im Release Planning wird entschieden, welche Maßnahmen und Aktivitäten durchzuführen sind, um eine verläßliche Auslieferung der Software zu gewährleisten. Im Release Planning wird das Product Backlog initial erstellt bzw. in späteren Release Planning Meetings kontinuierlich überarbeitet und angepasst. Version 0.1 /

25 Risk Analysis and Management Process In einem Risiko-Management-Prozeß werden Gefährdungen für Menschen und Umwelt durch Gebrauch eines Medizinproduktes analysiert, bewertet, durch Maßnahmen reduziert und entsprechend kontrolliert. Der Risiko-Management-Prozeß findet während aller Entwicklungsaktivitäten und -phasen statt. Qualitätsmanager Product Owner Entwicklungs-Team Scrum Master ISO Im Sprint Planning Meeting wird sichergestellt, dass alle Maßnahmen aus der Risiko-Analyse einer in diesem Sprint geplanten Anforderung in das Product Backlog als Anforderung einfließen. Im Sprint Planning Meeting wird sichergestellt, dass alle Maßnahmen aus der Risiko-Analyse einer in diesem Sprint geplanten Anforderung in das Product Backlog als Anforderung einfließen. Version 0.1 /

26 Im Sprint Planning Meeting durchlaufen alle Anforderungen eine Risiko-Analyse, um notwendige Maßnahmen abzuleiten. In der Risiko-Analyse während des Sprint Planning Meetings werden alle Anforderungen auf möglichen Mißbrauch untersucht und entsprechende Maßnahmen abgeleitet. Notwendige Änderungen an der Software, die durch System-Tests erkannt werden, durchlaufen während des Sprint Plannings die notwendige Risikoanalyse. Im Sprint Planning Meeting werden Probleme und Fehler auf sicherheitsrelevante Aspekte mit Hilfe der Risikoanalyse untersucht. Die Sicherheitsklassifizierung wird im Sprint Planning für alle umzusetzenden Software-Einheiten überdacht und gegebenenfalls neu vergeben. Im Sprint Planning werden die Architektur und die Software-Einheiten der umzusetzenden Anforderungen definiert. Die identifizierten Software-Einheiten durchlaufen die Risiko-Analyse. Im Sprint Planning wird die Risiko-Analyse der umzusetzenden Architektur und ihrer Software-Einheiten durchgeführt. Im Sprint Planning werden für fehlerhaftes Verhalten der Software mögliche Ursachen in Hardware- und Software-Fehlern analysiert Im Sprint Planning werden User Stories daraufhin untersucht, ob sie zu einer Gefahrensituation beitragen können, die in der Risiko-Analyse enthalten ist. Im Sprint Planning werden die umzusetzenden Anforderungen und deren abgeleitete Software-Einheiten durch die Risiko-Analyse auf mögliche Gefährdungen hin untersucht. Im Sprint Planning werden Workflows und sequentielle Abfolgen von Events in der Software durch die Risiko-Analyse auf Gefahrensituationen untersucht. Im Sprint Planning werden die umzusetzenden Software-Einheiten durch die Risiko-Analyse auf Gefahrensituationen untersucht. Im Sprint Planning wird der zu erstellenden Software-Einheit eine Sicherheitsklassifizierung zugewiesen (A, B, C), welche weitere Details im Entwicklungsprozess bestimmt. Im Sprint Planning werden zu jeder Software-Einheit mit möglichen Gefahrensituationen entsprechende Maßnahmen identifiziert und festgehalten. Im Sprint Planning werden mögliche Ursachen für Fehlverhalten von SOUP durch die Risiko- Analyse identifiziert. Im Sprint Planning werden SOUPs und ihre bekannten Fehler/Abweichungen durch die Risiko-Analyse betrachtet. Risiko-Management wird in erster Linie im Sprint Planning durchgeführt. Risiko-Management wird im Sprint Planning Meeting durchgeführt. Im Sprint Planning wird jeder Anforderung und User Story (auf jeder Ebene) eine Sicherheitsklassifizierung zugeordnet durch die Anwendung der Risiko-Analyse. Version 0.1 /

27 Scrum Process Scrum ist ein Management-Framework für die empirische Prozeßkontrolle. Product Owner Entwicklungs-Team Scrum Master Ken Schwaber - Agiles Projektmanagement mit Scrum Roman Pichler - Scrum Scrum ist ein gültiges Prozeß-Framework für den Software-Life-Cycle. Version 0.1 /

28 Software Maintenance Process Process Der Software Maintenance-Prozess (Software Wartungsprozeß) beschreibt alle Aktivitäten, die für die Änderung von sich im Markt befindlichen Medizinprodukten notwendig sind. Dazu gehört das Einholen und Bewerten von Anwender-Feedback sowie ein installierter Fehlerbehebungsprozeß. Product Owner Entwicklungs-Team https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e e f-8982fc416138/entry/march_10_2012_11_27_am8?lang=en Über den Software Maintenance Prozeß erfolgt das Einholen des Feedbacks zu releaster Software innerhalb der eigenen Organisation. Über den Software Maintenance Prozeß erfolgt das Einholen des Feedbacks zu releaster Software von tatsächlichen Anwendern. Version 0.1 /

29 Sprint Planning Process Im Sprint Planning Meeting einigen sich der Product Owner und das Team auf ein Sprint-Ziel und das dafür umzusetzende Sprint Backlog. Im zweiten Teil des Sprint Plannings werden vom Team konkrete Architektur- und Umsetzungsaufgaben identifiziert und geplant. Product Owner Entwicklungs-Team Scrum Master Im Sprint Planning Meeting wird vom Team festgestellt, ob sich Anforderungen im Product Backlog widersprechen. Im Sprint Planning Meeting wird sichergestellt, dass über die Anforderungen ein einheitliches Verständnis bei allen Beteiligten herrscht. Im Sprint Planning Meeting wird sichergestellt, dass zu jeder Anforderung Akzeptanz-Kriterien für die Integration in andere Strukturen erstellt werden. Im Sprint Planning Meeting werden bestehende Anforderungen und User Stories im Product Backlog neu bewertet und aktualisiert. Version 0.1 /

30 Spätestens im Sprint Planning Meeting werden Anforderungen auf ihre korrekte und vollständige Definition geprüft. Im Sprint Planning Meeting werden vom Team alle Tasks identifiziert, welche für die Umsetzung einer Änderung (erneut) durchgeführt werden müssen. Im Sprint Planning erfolgt die Planung der Integrations-Tests sowie der System-Tests. Im Sprint Planning finden die notwendigen Risiko-Analysen sowie die Umsetzungsplanung statt für Probleme und Fehler von bereits releaster Software. Im Sprint Planning werden die Fehler- und Problemberichte analysiert. Im Sprint Planning werden für benötigte SOUP-Komponenten die Funktionalitäten und Performance-Anforderungen festgelegt. Im Sprint Planning werden die umzusetzenden Anforderungen in eine Architektur überführt und diese wiederum in Software-Einheiten runtergebrochen. Im Sprint Planning werden die Architektur und die Schnittstellen der umzusetzenden Software-Einheiten sowie der einzubindenden externen Software-Einheiten festgelegt. Die grundlegenden Software-Strukturen und Architektur-Entscheidungen können im Sprint Planning getroffen werden. Im Sprint Planning werden Software-Einheiten, die eine Risiko-Maßnahme umsetzen, genauso behandelt wie alle anderen Anforderungen und befolgen den definierten Entwicklungsprozeß. Im Sprint Planning Meeting wird das Sprint Backlog bzw. der Sprint Development Plan festgelegt. Im Sprint Planning werden die Iteration Notes (Sprint Notizen) angefangen. Im Sprint Planning Meeting wird in der zweiten Phase (Sprint Planning 2) die Architektur der umzusetzenden Anforderungen besprochen, skizziert und festgehalten. Version 0.1 /

31 Sprint Retrospective Process In der Sprint Retrospektive hat das Team die Möglichkeit, Verbesserungsmaßnahmen für die eigenen Prozesse und Strukturen zu identifizieren und zu beschließen. Product Owner Entwicklungs-Team Scrum Master Norman Kerth - Project Retrospectives Esther Derby, Diana Larsen - Agile Retrospectives Der Team Charter und die Working Agreements können vom Team im Sprint Retrospective Meeting an veränderte Situationen und gegebene Notwendigkeiten angepasst werden. Die Definition-of-Ready kann vom Team im Sprint Retrospective Meeting an veränderte Situationen und gegebene Notwendigkeiten angepasst werden. Die Definition-of-Done kann vom Team im Sprint Retrospective Meeting an veränderte Situationen und gegebene Notwendigkeiten angepasst werden. Der Software Development Plan kann vom Team im Sprint Retrospective Meeting an veränderte Situationen und gegebene Notwendigkeiten angepasst werden. Version 0.1 /

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind.

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. Wir erledigen alles sofort Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. agilecoach.de Marc Bless Agiler Coach agilecoach.de Frage Wer hat

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

Marc Bless. Scrum. und die IEC 62304. Medizinische Software mit agilen Methoden normkonform entwickeln. Gekürzte Ausgabe

Marc Bless. Scrum. und die IEC 62304. Medizinische Software mit agilen Methoden normkonform entwickeln. Gekürzte Ausgabe Marc Bless Scrum und die IEC 62304 Medizinische Software mit agilen Methoden normkonform entwickeln Gekürzte Ausgabe Version 1.3 November 2013 agilecoach.de Marc Bless Scrum und die IEC 62304 Medizinische

Mehr

Agile Produktentwicklung in der Medizintechnik

Agile Produktentwicklung in der Medizintechnik Whitepaper für Top-Entscheider Agile Produktentwicklung in der Medizintechnik Agilität in der Produktentwicklung ist in aller Munde und in allen Branchen existieren eine Vielzahl von Firmen, die sich mit

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

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Wasserfall vs. Agile: Eine Erfolgsstory 2 Umsetzung agiler Prinzipien Entwicklungsprozess 2009 30.6% 13.4% 20.6% 35.4% Agil Iterativ

Mehr

Agile Methoden bei der Entwicklung medizinischer Software

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

Mehr

Scrum und die IEC 62304

Scrum und die IEC 62304 agilecoach.de Marc Bless Scrum und die IEC 62304 Medizinische Software mit agilen Methoden normkonform entwickeln Leseprobe der Vollständigen Ausgabe Version 1.2 Juli 2013, Baden-Baden Vorwort zur Leseprobe

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

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

Mehr

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

SCRUM. Software Development Process

SCRUM. Software Development Process SCRUM Software Development Process WPW 07.08.2012 SCRUM Poster www.scrum-poster.de Was ist Scrum? Extrem Schlanker Prozess 3 Rollen 4 Artefakte Wenige Regeln Die Rollen Product Owner Der Product Owner

Mehr

30 Multiple Choice-Fragen - pro Frage gibt es immer 1-4 richtige Antworten

30 Multiple Choice-Fragen - pro Frage gibt es immer 1-4 richtige Antworten SCRUM Foundation MUSTERPRÜFUNG Closed Book, d.h. keine Hilfsmittel zulässig Dauer: 60 Minuten 30 Multiple Choice-Fragen - pro Frage gibt es immer 1-4 richtige Antworten Beispiel für die Bewertung Annahme

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

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

IT-Basics 2. DI Gerhard Fließ. Vorgehensmodelle

IT-Basics 2. DI Gerhard Fließ. Vorgehensmodelle IT-Basics 2 DI Gerhard Fließ Vorgehensmodelle Sichtbarkeit Die Sichtbarkeit von Membervariablen und Methoden können durch die folgenden Schlüsselworte geregelt werden: private nur in der eigenen Klasse

Mehr

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen Bernhard Fischer Fischer Consulting GmbH MedConf 2009 Folie 1 Wie soll Software entwickelt werden? MedConf 2009 Folie

Mehr

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de SCRUM Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter Dirk.Prueter@gmx.de Überblick Was ist SCRUM Wie funktioniert SCRUM Warum lohnt es sich, SCRUM anzuwenden

Mehr

Praxisbericht: Agil skalierte Produktentwicklung im regulierten Umfeld. Andreas Becker, Uwe Valentini Agile-by-HOOD 19.02.2014

Praxisbericht: Agil skalierte Produktentwicklung im regulierten Umfeld. Andreas Becker, Uwe Valentini Agile-by-HOOD 19.02.2014 Praxisbericht: Agil skalierte Produktentwicklung im regulierten Umfeld Andreas Becker, Uwe Valentini Agile-by-HOOD 19.02.2014 Reguliertes agil-skaliertes Umfeld Product Daily Definiton of Done Planning

Mehr

Einführung in das Scrum Framework & welche 10 Praktiken helfen, Scrum wirklich gut zu machen

Einführung in das Scrum Framework & welche 10 Praktiken helfen, Scrum wirklich gut zu machen Einführung in das Scrum Framework & welche 10 Praktiken helfen, Scrum wirklich gut zu machen Wer bin ich Kurse und Vorträge mit Jeff Sutherland und Ken Schwaber Verschiedene Kurse der Scrum.org Professional

Mehr

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten Projektmanagement Agile Methoden: Extreme Programming / Scrum Dokument V 1.2 Probleme bei Projekten Viel Arbeit, die an den Zielen vorbeigeht Viel Dokumentation für f r unbenutzte Bestandteile Fehlende

Mehr

AGILER TESTMANAGER EIN OXYMORON?

AGILER TESTMANAGER EIN OXYMORON? AGILR ANAGR IN OXYMORON? Kay.Grebenstein@saxsys.de AGILR ANAGR IN OXYMORON? Benötigen wir mit Scrum noch die Rolle estmanager? 1 AGILR ANAGR IN OXYMORON? Aufgaben SCRUM AUFGABN Strategische bene (Qualitätsmanager)

Mehr

Agiles Testen - Ein Erfahrungsbericht Thomas Schissler / artiso AG Michael Lierheimer/ infoteam software AG

Agiles Testen - Ein Erfahrungsbericht Thomas Schissler / artiso AG Michael Lierheimer/ infoteam software AG Agiles Testen - Ein Erfahrungsbericht Thomas Schissler / artiso AG Michael Lierheimer/ infoteam software AG Herausforderungen bei agilem Testen Klassische Projektstruktur Projektleiter Entwickler QS-Abteilung

Mehr

Agiles Anforderungsmanagement mit SCRUM im regulierten Umfeld

Agiles Anforderungsmanagement mit SCRUM im regulierten Umfeld Agiles Anforderungsmanagement mit SCRUM im regulierten Umfeld Bernhard Fischer Fischer Consulting GmbH MedConf 2011 Luzern Folie 1 Wozu brauchen wir Requirements? MedConf 2011 Luzern Folie 2 Der Anforderungszoo

Mehr

Grob- und Detailplanung bei der Implementierung nutzen

Grob- und Detailplanung bei der Implementierung nutzen Softwarearchitektur Grob- und Detailplanung bei der Implementierung nutzen Bereich Realisierung Aktivität Softwareinkrement realisieren Ziele Vermitteln einer Orientierungshilfe für alle Entwickler Etablierung

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

Wie funktioniert agile Software-

Wie funktioniert agile Software- Wie funktioniert agile Software- Entwicklung mit SCRUM Zürich, 8. Mai 008 Jean-Pierre König, namics ag Software Engineer Bern, Frankfurt, Hamburg, München, St. Gallen, Zug, Zürich www.namics.com Agenda»

Mehr

Sollten folgende drei Fragen durch das Team positiv beantwortet werden, sind wichtige SCRUM-Elemente in Ihrem Team erfolgreich installiert.

Sollten folgende drei Fragen durch das Team positiv beantwortet werden, sind wichtige SCRUM-Elemente in Ihrem Team erfolgreich installiert. SCRUM-CHECKLISTE Teilen Sie diese Liste an alle Teammitglieder aus. Jeder soll einen Haken an der Stelle setzen, die er für Ihr SCRUM Team als erfüllt ansieht. Anschließend diskutieren Sie über fehlende

Mehr

Scrum for Management Praxis versus Theorie oder Praxis dank Theorie. ALM Day 26.Oktober 2011 Urs Böhm

Scrum for Management Praxis versus Theorie oder Praxis dank Theorie. ALM Day 26.Oktober 2011 Urs Böhm Scrum for Management Praxis versus Theorie oder Praxis dank Theorie ALM Day 26.Oktober 2011 Urs Böhm Übersicht Kurze Situationsübersicht Diskussion Prozesse Challenges in der SW-Entwicklung Wie geht Scrum

Mehr

Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare

Praktische Erfahrungen beim Einsatz des Vorgehensmodells SCRUM bei AGFA HealthCare Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare SCRUM Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" eines Entwicklerteams von AGFA HealthCare 2 Praktische

Mehr

Software Engineering

Software Engineering Software Engineering Prof. Adrian A. Müller, PMP Fachbereich Informatik und Mikrosystemtechnik Fachhochschule Kaiserslautern, Standort Zweibrücken Prof. A. Müller, FH KL Software Engineering WS '11/'12

Mehr

Iterativ. Inkrementell

Iterativ. Inkrementell Iterativ Inkrementell Build Release Test Qualität Architektur & Documentation Distributed Version Control Continuous Integration TDD Design Agile Architektur Dependency Feature Branches Mocks

Mehr

AGILES QUALITÄTSMANAGEMENT

AGILES QUALITÄTSMANAGEMENT AGILES QUALITÄTSMANAGEMENT Manfred Rätzmann Head of Department Quality Assurance Deutsche Post E-Post Development GmbH Manfred.Raetzmann@epost-dev.de http://www.epost.de/ Klassische Ziele des Qualitätsmanagements:

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

Trotz Agilität nicht ins Abseits geraten Modellierung in einem agilen Umfeld. Susanne Mühlbauer, Philip Stolz, HOOD GmbH MID Insight 2012

Trotz Agilität nicht ins Abseits geraten Modellierung in einem agilen Umfeld. Susanne Mühlbauer, Philip Stolz, HOOD GmbH MID Insight 2012 Trotz Agilität nicht ins Abseits geraten Modellierung in einem agilen Umfeld Susanne Mühlbauer, Philip Stolz, HOOD GmbH MID Insight 2012 Agenda 1. Scope, Motivation und Begriffsklärung 2. Modellierung

Mehr

Projektmanagement. Agile Vorgehensweise / Scrum. Version: 1.0 Stand: 23.06.2016

Projektmanagement. Agile Vorgehensweise / Scrum. Version: 1.0 Stand: 23.06.2016 Projektmanagement Agile Vorgehensweise / Scrum Version: 1.0 Stand: Lernziel Sie können in eigenen Worten darstellen warum Agilität notwendig ist. Sie können mit eigene Worten das Framework Scrum beschreiben.

Mehr

Scrum in der Praxis (eine mögliche Umsetzung)

Scrum in der Praxis (eine mögliche Umsetzung) Scrum in der Praxis (eine mögliche Umsetzung) ALM Talk, 26. Oktober 2011 Stefan Stettler Ausgangslage Viele Projektbeteiligte Verkauf, Entwickler, PM, Designer, Ergonomen Unterschiedliche Sichten und Vorstellungen,

Mehr

Agilität selbst erfahren. Agile Softwareentwicklung in der Praxis: Jetzt bewerben für das erste Agile Code Camp 2013!

Agilität selbst erfahren. Agile Softwareentwicklung in der Praxis: Jetzt bewerben für das erste Agile Code Camp 2013! Agilität selbst erfahren. Agile Softwareentwicklung in der Praxis: Jetzt bewerben für das erste Agile Code Camp 2013! Sie wollen alles über agile Softwareentwicklung wissen? Wie können Sie agile Methoden

Mehr

Agile Softwareprozess-Modelle

Agile Softwareprozess-Modelle Agile Softwareprozess-Modelle Steffen Pingel Regionale Fachgruppe IT-Projektmanagement 2003-07-03 Beweglich, Lebhaft, Wendig Was bedeutet Agil? Andere Bezeichnung: Leichtgewichtiger Prozess Manifesto for

Mehr

Agile Softwareentwicklung mit Scrum

Agile Softwareentwicklung mit Scrum Agile Softwareentwicklung mit Scrum Einführung und Überblick zum agilen Softwareentwicklungsprozess Scrum März 2006 Robert Schmelzer, DI(FH) E-Mail: robert@schmelzer.cc Web: http://www.schmelzer.cc Einführung

Mehr

Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch -

Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch - Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch - Prof. Dr. Roland Petrasch, Beuth Hochschule für Technik prof.beuth-hochschule.de/petrasch Stefan Lützkendorf Projektron GmbH

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

Agiles Testen. Handwerkszeug zur Prävention von Fehlern und technischen Schulden. Entwicklertag 2014. Lars Alvincz, Daniel Knapp

Agiles Testen. Handwerkszeug zur Prävention von Fehlern und technischen Schulden. Entwicklertag 2014. Lars Alvincz, Daniel Knapp Agiles Testen Handwerkszeug zur Prävention von Fehlern und technischen Schulden Entwicklertag 2014 Lars Alvincz, Daniel Knapp 2 Agenda Ziel dieses Vortrags Grundzüge des agilen Testens Voraussetzungen

Mehr

Zum Beispiel ein Test

Zum Beispiel ein Test Zum Beispiel ein Test Torsten Mandry OPITZ CONSULTING Deutschland GmbH Gummersbach Schlüsselworte Beispiele, Specification by Example, Akzeptanztest, Lebende Spezifikation, Java Einleitung Beispiele helfen

Mehr

Testmanagement im agilen Entwicklungsprozess

Testmanagement im agilen Entwicklungsprozess Testmanagement im agilen Entwicklungsprozess Unser Beratungsangebot für die effiziente Abwicklung von Projekten: n Anforderungen erkennen n Software-Qualität steigern n Teams zum Erfolg führen Unser Erfolgskonzept:

Mehr

Leichtgewichtige Traceability im agilen Entwicklungsprozess am Beispiel von Scrum

Leichtgewichtige Traceability im agilen Entwicklungsprozess am Beispiel von Scrum Leichtgewichtige Traceability im agilen Entwicklungsprozess am Beispiel von Scrum Traceability Workshop SE 2013 Aachen 26. Feb. 2013 Elke Bouillon 1, Baris Güldali 2, Andrea Herrmann 3, Thorsten Keuler

Mehr

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft.

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft. Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle Folie 2 Agenda Projektmanagement: Ziele und Methoden Agile Methoden: Scrum Agile Methoden im BI Umfeld PM

Mehr

Marc Bless. Scrum. und die IEC 62304. Medizinische Software mit agilen Methoden normkonform entwickeln

Marc Bless. Scrum. und die IEC 62304. Medizinische Software mit agilen Methoden normkonform entwickeln Marc Bless Scrum und die IEC 62304 Medizinische Software mit agilen Methoden normkonform entwickeln Version 1.8 Januar 2014 agilecoach.de Marc Bless Scrum und die IEC 62304 Medizinische Software mit

Mehr

Inhalt. 3.1 Der inkrementelle Entwurf im Überblick... 13 3.2 Flache Aufwandskurve... 14 3.3 Qualitätskriterien für den inkrementellen Entwurf...

Inhalt. 3.1 Der inkrementelle Entwurf im Überblick... 13 3.2 Flache Aufwandskurve... 14 3.3 Qualitätskriterien für den inkrementellen Entwurf... ix 1 Einleitung 1 Roman Pichler Stefan Roock 1.1 Agile Softwarewicklung und Scrum............................ 1 1.2 Zielgruppe und Zielsetzung.................................. 2 1.3 Überblick über das

Mehr

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-42660-3. Weitere Informationen oder Bestellungen unter

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-42660-3. Weitere Informationen oder Bestellungen unter Ralf Wirdemann Scrum mit User Stories ISBN: 978-3-446-42660-3 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42660-3 sowie im Buchhandel. Carl Hanser Verlag, München 1 Einführung.....................................

Mehr

Software-Dokumentation im agilen Umfeld. Marion Bröer, parson communication

Software-Dokumentation im agilen Umfeld. Marion Bröer, parson communication Software-Dokumentation im agilen Umfeld Marion Bröer, parson communication parson communication Software- und Prozessdokumentation Wissensmanagement Wikis und XML-basierte Dokumentation Schulungen und

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

Projektorganisation und Vorgehen in agilen Projekten. Noser Technologieimpulse München 2013 - Matthias Neubacher

Projektorganisation und Vorgehen in agilen Projekten. Noser Technologieimpulse München 2013 - Matthias Neubacher Projektorganisation und Vorgehen in agilen Projekten Noser Technologieimpulse München 2013 - Matthias Neubacher Ein wenig Theorie Agile Methoden Warum? hohe Anpassbarkeit schnellere Ergebnisse günstigere

Mehr

IT-Projekt-Management

IT-Projekt-Management IT-Projekt-Management email: vuongtheanh@netscape.net http: www.dr-vuong.de 2005 by, Bielefeld Seite 1 Vorgehensmodell 2005 by, Bielefeld Seite 2 Was ist ein Vorgehensmodell? Strukturbeschreibung über

Mehr

End-to-End Agility Sind Sie schon agil genug? Mag. Christoph Leithner c.leithner@celix.at

End-to-End Agility Sind Sie schon agil genug? Mag. Christoph Leithner c.leithner@celix.at End-to-End Agility Sind Sie schon agil genug? Mag. Christoph Leithner c.leithner@celix.at www.celix.at September 2015 celix Solutions GmbH Spezialist für Team Collaboration und IT Prozess Management Agile

Mehr

Projektmanagement Vorlesung 12/ 13

Projektmanagement Vorlesung 12/ 13 Folie 1 Projektmanagement Vorlesung 12/ 13 Prof. Adrian Müller, PMP FH Kaiserslautern phone: +49 6332 914-329 http://www.fh-kl.de/~amueller Folie 2 Inhalte Agile Modelle Manifesto Übersicht XP Prinzipien

Mehr

vii Inhaltsverzeichnis 1 Einleitung 1 2 Rechtliche Grundlagen 5

vii Inhaltsverzeichnis 1 Einleitung 1 2 Rechtliche Grundlagen 5 vii 1 Einleitung 1 2 Rechtliche Grundlagen 5 2.1 Die Rechtslage in Europa.................................. 5 2.1.1 Definition eines Medizinproduktes.................... 5 2.1.2 Richtlinien, Gesetze und

Mehr

Scrum mit User Stories

Scrum mit User Stories Ralf Wirdemann Scrum mit User Stories HANSER Inhaltsverzeichnis 1 Einführung 1 1.1 Warum dieses Buch? 2 1.2 Struktur und Aufbau 3 1.3 Dankeschön 5 1.4 Feedback 5 2 Beispiel: Scrumcoaches.com 7 2.1 Das

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

Agile Management Einführung in agiles Management

Agile Management Einführung in agiles Management Agile Management Einführung in agiles Management Agile Management Agile Management-Methoden Einführung Agile Management PQRST e.u. - Ing. Erich Freitag Version 25.06.2013 Lernziele Den Unterschied zwischen

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

DevOps in der Praxis. Alexander Pacnik 24.11.2015

DevOps in der Praxis. Alexander Pacnik 24.11.2015 DevOps in der Praxis Alexander Pacnik 24.11.2015 Einführung... DevOps Versuch einer Definition Alexander Pacnik IT Engineering & Operations Project Management inovex GmbH 2 Einführung... DevOps Versuch

Mehr

READY-STEADY-DONE! Der Product Owner are you READY for agile?!

READY-STEADY-DONE! Der Product Owner are you READY for agile?! READY-STEADY-DONE! Der Product Owner are you READY for agile?! Susanne Mühlbauer HOOD GmbH Büro München Keltenring 7 82041 Oberhaching Germany Tel: 0049 89 4512 53 0 www.hood-group.com -1- Neue Ideen sind

Mehr

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-41656-7. Weitere Informationen oder Bestellungen unter

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-41656-7. Weitere Informationen oder Bestellungen unter Ralf Wirdemann Scrum mit User Stories ISBN: 978-3-446-41656-7 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41656-7 sowie im Buchhandel. Carl Hanser Verlag, München 1 Einführung.....................................

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

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

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Projektplan Software Engineering Projekt November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Der Projektplan Grundlage der gemeinsamen Arbeit innerhalb des Teams und mit

Mehr

Agiles Projektmanagement. erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011. Thomas Hemmer

Agiles Projektmanagement. erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011. Thomas Hemmer Agiles Projektmanagement erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011 Thomas Hemmer Chief Technology Officer thomas.hemmer@conplement.de conplement AG, Nürnberg 2 conplement

Mehr

Test-Driven Developement Eine Einführung

Test-Driven Developement Eine Einführung Test-Driven Developement Eine Einführung 2007 by Tobias Hagen Im Rahmen der Veranstaltung Aktuelle Themen der Informatik bei Prof. Dr. Friedbert Kaspar Hochschule Furtwangen University Übersicht Einführung...

Mehr

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

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

Mehr

Requirements Engineering für die agile Softwareentwicklung

Requirements Engineering für die agile Softwareentwicklung Johannes Bergsmann Requirements Engineering für die agile Softwareentwicklung Methoden, Techniken und Strategien Unter Mitwirkung von Markus Unterauer dpunkt.verlag Inhaltsverzeichnis 1 Einleitung 1 1.1

Mehr

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, 01. 02. Dezember 2009 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung

Mehr

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches Dieses Buch beschreibt das Wesen von Scrum die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen bereitzustellen. Was ist das Wesen

Mehr

Scrum ist ein agiles Framework zur Software-Entwicklung. SCRUM bei Festo. Was ist SCRUM? Frank M. Hoyer, House of Software

Scrum ist ein agiles Framework zur Software-Entwicklung. SCRUM bei Festo. Was ist SCRUM? Frank M. Hoyer, House of Software SCRUM bei Festo Frank M. Hoyer, House of Software SI-MS/Frank M. Hoyer Scrum bei Festo 15. März 2010 geändert: 16. September 2014, HOY Was ist SCRUM? Scrum ist ein agiles Framework zur Software-Entwicklung.

Mehr

Susanne Muehlbauer 29. November 2011

Susanne Muehlbauer 29. November 2011 Machen Sie noch Modellierung Anforderungsmanagement oder sind Sie schon READY for SCRUM? Susanne Muehlbauer 29. Wer ist HOOD unser Geschäftsfeld Der Einsatz von Requirements Engineering und kontinuierliche

Mehr

Service Virtualisierung

Service Virtualisierung Service Virtualisierung So bekommen Sie Ihre Testumgebung in den Griff! Thomas Bucsics ANECON Software Design und Beratung G.m.b.H. Alser Str. 4/Hof 1 A-1090 Wien Tel.: +43 1 409 58 90 www.anecon.com office@anecon.com

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

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

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

Wasserfall, «Death March», Scrum und agile Methoden. 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm

Wasserfall, «Death March», Scrum und agile Methoden. 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm Wasserfall, «Death March», Scrum und agile Methoden 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm Übersicht Warum Projektmanagement? Gängige SW Entwicklungsprozesse Wasserfall V-Modell

Mehr

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit IBM Software Group IBM Rational mit RequisitePro Hubert Biskup hubert.biskup@de.ibm.com Agenda Rational in der IBM Software Group Der Rational Unified Process als Basis für die Projektarbeit mit Rational

Mehr

SCRUM. Scrum in der Software Entwicklung. von Ernst Fastl

SCRUM. Scrum in der Software Entwicklung. von Ernst Fastl SCRUM Scrum in der Software Entwicklung von Ernst Fastl Agenda 1. Die Entstehung von Scrum 2. Überblick über den Prozess 3. Rollen 4. Meetings 5. Artefakte 6. Fragen & Antworten Agenda 1. Die Entstehung

Mehr

Übungen zur Softwaretechnik

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

Mehr

Scrum, ISIS und ISO 9001 zertifiziertes Qualitätsmanagement. Joachim Meyer

Scrum, ISIS und ISO 9001 zertifiziertes Qualitätsmanagement. Joachim Meyer Scrum, ISIS und ISO 9001 zertifiziertes Qualitätsmanagement Joachim Meyer Inhalt ISIS ISO Zertifizierung S eite 2 Agile Softwareentwicklung Scrum TDD Extreme Programming Feature-Driven Development Lean

Mehr

Der Business Analyst in der Rolle des agilen Product Owners

Der Business Analyst in der Rolle des agilen Product Owners Der Business Analyst in der Rolle des agilen Owners HOOD GmbH Susanne Mühlbauer Büro München Keltenring 7 82041 Oberhaching Germany Tel: 0049 89 4512 53 0 www.hood-group.com -1- Inhalte Agile Software

Mehr

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

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

Mehr

Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski

Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski 1. Was heißt Agil 2. Scrum? Grundbegriffe 3. Wer benutzt Scrum 4. Vorteile & Nachteile von

Mehr

Produktphilosophie erstellen

Produktphilosophie erstellen User Experience Produktphilosophie erstellen Bereich Anforderungen Aktivität Ziele Erleichterte Kommunikation zwischen Stakeholdern Designentscheidungen erleichtern/rechtfertigen schnell durchführbar einfach

Mehr

Einführung in SCRUM. Helge Baier 21.01.2010

Einführung in SCRUM. Helge Baier 21.01.2010 Einführung in SCRUM Helge Baier 21.01.2010 Helge Baier Master of Computer Science (Software Engineering) über 10 Jahre Erfahrung in der Software Entwicklung Zertifizierung zum Scrum Master (2009) praktische

Mehr

extreme Programming (XP) Hermann Götz Sergij Paholchak Agenda Was ist XP? Grundprinzipien Der Entwicklungsprozess Die Projektplanung Praktiken Vorteile und Nachteile Wann macht XP Sinn für ein Projekt?

Mehr

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming /

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming / Software- Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.2-2010 Projektmodelle im Vergleich Klassisch Wasserfall -Modell Spezifikation/Pflichtenheft

Mehr

Einführung in Scrum. Agiles Projektmanagement. Martin Krüger 27.04.2011 Entwicklung von Workflowanwendungen

Einführung in Scrum. Agiles Projektmanagement. Martin Krüger 27.04.2011 Entwicklung von Workflowanwendungen Einführung in Scrum Agiles Projektmanagement Martin Krüger 27.04.2011 Entwicklung von Workflowanwendungen Warum Agiles Projektmanagement? Scrum Empfehlungen Das Seminar Planbarkeit Warum Agiles Projektmanagement?

Mehr

GI Fachgruppentreffen RE 2015

GI Fachgruppentreffen RE 2015 GI Fachgruppentreffen RE 2015 Miteinander reden statt gegeneinander schreiben Lagerfeuer Bundenbach Schmidtburg 2003 von Tiger St.Georg - selbst fotografiert von Tiger St.Georg. Susanne Mühlbauer 1 November

Mehr

SCRUM. Vertragsgestaltung & Vertragsorientierte Projektdurchführung. Katharina Vierheilig Vorlesung: Juristisches IT-Projektmanagement 08.01.

SCRUM. Vertragsgestaltung & Vertragsorientierte Projektdurchführung. Katharina Vierheilig Vorlesung: Juristisches IT-Projektmanagement 08.01. SCRUM Vertragsgestaltung & Vertragsorientierte Projektdurchführung Katharina Vierheilig Vorlesung: Juristisches IT- Agile Softwareentwicklung SCRUM 2 SCRUM Agiles Manifest Individuen und Interaktion Prozesse

Mehr

Agiles Testmanagement am Beispiel Scrum

Agiles Testmanagement am Beispiel Scrum Agiles Testmanagement am Beispiel Scrum SEQIS Software Testing Know-How Weitere Termine 16. September Testmanagement mit externen Partnern 21.Oktober Software unter Druck: Erfolgsfaktoren bei Last- und

Mehr

CONTINUOUS DELIVERY. codecentric AG

CONTINUOUS DELIVERY. codecentric AG CONTINUOUS DELIVERY AGENDA Einstieg Was ist Continuous Delivery Welche Ziele werden verfolgt? Voraussetzungen Technisch Organisatorisch Kulturell Umsetzung und Einführung 6 Disziplinen der Continuous Delivery

Mehr

Projekt: Requirements Engineering Sommersemester 2002. Anforderungsspezifikation im X-Treme Programming

Projekt: Requirements Engineering Sommersemester 2002. Anforderungsspezifikation im X-Treme Programming Projekt: Requirements Engineering Sommersemester 2002 Vortrag von Bernd Simmchen Anforderungsspezifikation im X-Treme Programming Gliederung 1 XP Eine kurze Einführung 2 Anforderungsspezifikation Klassisch

Mehr

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells...

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells... Inhaltsverzeichnis Inhaltsverzeichnis... I 1 Problemstellung... 1 2 V-Modell... 1 2.1 Allgemeines... 1 2.2 Anwendung des V-Modells... 3 3 SCRUM-Modell... 4 3.1 Allgemeines... 4 3.2 Anwendung des SCRUM-Modells...

Mehr

Projektmanagement. Vorlesung von Thomas Patzelt 8. Vorlesung

Projektmanagement. Vorlesung von Thomas Patzelt 8. Vorlesung Projektmanagement Vorlesung von Thomas Patzelt 8. Vorlesung 1 Möglicher Zeitplan, Variante 3 26.03. Vorlesung 1, Übung Gr.2 28.05. Keine Vorlesung, Pfingstmontag 02.04. Keine Vorlesung, Hochschultag 04.06.

Mehr

Agile Softwareentwicklung mit SCRUM

Agile Softwareentwicklung mit SCRUM Agile Softwareentwicklung mit SCRUM PMI MUC 01. März 2010 Referent: Gerhard Held mehr als 35 Berufsjahre in der Softwareentwicklung im Projektmanagement und verwandten Themen... Gründe für das Scheitern

Mehr

Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung. Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern

Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung. Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern phone: +49 631/3724-5329 http://www.hs-kl.de/~amueller

Mehr

myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt

myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt Überblick Agilität und Scrum Grundlagen der agilen Softwareentwicklung Rahmenbedingungen bei der Einführung eines agilen Projektvorgehens

Mehr