Agilität. Aber richtig!

Größe: px
Ab Seite anzeigen:

Download "Agilität. Aber richtig!"

Transkript

1 Heft 17 4,90 Agilität. Aber richtig! Agile Anti-Patterns Architektur systematisch verbessern Agilität im Ganzen istockphoto.com/akindo

2 Evolution mit aim42 Evolution, Änderung und Wartung aber richtig! Software systematisch verbessern Die Informatikausbildung fokussiert auf die Neuentwicklung von Software den Alltag vieler Softwerker prägen jedoch meist Pflege, Änderung oder Erweiterung von Systemen. In diesem Artikel stelle ich Ihnen aim42 vor, ein systematisches Vorgehen zur Verbesserung von Software. aim42 ist frei verfügbar und systematisiert Praktiken und Patterns rund um Evolution, Änderung und Wartung von IT-Systemen. Autor: Dr. Gernot Starke In Entwicklung und Betrieb von Software wünschen wir uns über die gesamte Lebensdauer unserer Systeme möglichst niedrige Änderungs- und Betriebskosten, bei gleichzeitig hoher Änderbarkeit und Verständlichkeit (Abb. 1). Bei mittleren bis großen Systemen tritt diese ideale Situation in der Realität nur selten ein. Zeitdruck, Konstruktions- und Managementfehler sowie kurzfristig orientierte Entwurfsentscheidungen sorgen dafür, dass ziemlich genau das Gegenteil geschieht: Obwohl anfänglich alles sauber entwickelt und entworfen war, degenerieren Systeme über die Zeit das Phänomen der verfaulenden Software schlägt zu. Änderungen werden schwieriger, riskanter und dauern immer länger. In Entwicklung und Betrieb treten vermehrt Probleme auf, deren Behebung mehr und mehr Zeit und Ressourcen in Anspruch nimmt. Damit einher steigen Änderungs- und Betriebskosten. Ganz unterschiedliche Gründe verursachen diese missliche Situation einige verbreitete Beispiele: 1. Mangelnde konzeptionelle Integrität: identische Probleme werden innerhalb eines Systems unterschiedlich gelöst, es gibt mehrere unterschiedliche, teils widersprüchliche Lösungsansätze. 2. Übermäßige strukturelle Komplexität, umständliche Konzepte oder Abläufe innerhalb des Systems. 3. Zum fachlichen Problem unpassende Wahl von Technologien, Frameworks oder sonstiger Infrastruktur ( mit Kanonen auf Spatzen schießen ). 4. Schlechter Quellcode, der beispielsweise Grundlagen des Clean Code [1] verletzt, unter zu hoher Kopplung oder niedriger Kohäsion leidet, gegen Coding- Konventionen verstößt, Redundanzen enthält oder schlicht unverständlich ist. Diese Liste könnte ich nahezu beliebig weiterführen und jeder neue Eintrag würde mich dabei an eine reale Situation meines bisherigen Berufslebens erinnern. Wege in den Abgrund Zu Beginn vieler Entwicklungsprojekte sieht Software doch recht ordentlich aus: Motivierte Teams erarbeiten stimmige Konzepte und setzen diese dann handwerklich sauber um. Konzepte und Technologien passen zum Problem, ebenso die Algorithmen und Datenstrukturen. Im Laufe der Zeit jedoch beginnt das Drama: Die ursprüngliche Ordnung weicht einem ständig steigenden Chaos. Ausnahmen werden zur Regel, Code wird immer schwerer verständlich, das Entwicklungsteam beginnt von hysterisch gewachsen zu sprechen weil kaum jemand nachvollziehen kann, wie es zu dieser kontinuierlichen Verschlechterung kommen konnte. Warum kommt es dazu? Verlernen Teams über die Zeit 54 bt

3 das vernünftige und saubere Arbeiten? Nein vielmehr zwingen oftmals äußere Einflüsse zu Kompromissen, die dann langfristig zu den oben genannten Problemen führen [2]. Neudeutsch nennen Manager dieses Phänomen technische Schulden Softwareentwickler bezeichnen diese als Quick and Dirty, Hotfix oder Workaround und wissen, dass sich dahinter meistens ein weiterer Schritt in Richtung degenerierter Systeme (rottensoftware) verbirgt. Innere Werte werden vernachlässigt Ursächlich resultieren diese Probleme aus einem mangelnden Bewusstsein für den Wert der inneren Qualität von Software. Auftraggeber interessieren sich primär für neue Features, Erweiterungen oder schnellstmögliche Fehlerbehebung, weniger für den Erhalt konzeptioneller Integrität, verständlichen Quellcode oder stimmige Anwendung von Konzepten oder Technologien. Aber gerade diese innere Qualität von Systemen stellt sicher, Ziele wie niedrige Änderungskosten, schnelle Fehlerbehebung, hohe Anpassbarkeit zu erreichen. Leider ignorieren immer noch zu viele IT-Manager diesen kausalen Zusammenhang. Systematisch verbessern Der Weg zu besserer Software führt in der kommerziellen Realität immer über mehrere, meist kleine Schritte zum Ziel. Praktisch niemals können wir den Lauf der Welt für einige Monate anhalten, um in dieser Zeit die Qualität unserer Software zu verbessern. Vielmehr müssen wir Verbesserungen in die regulären Wartungsarbeiten (etwa: Erweiterungen, Fehlerkorrekturen) integrieren. Ich möchte Ihnen aim42 vorstellen eine frei verfügbare Methode zur systematischen Verbesserung der Software. Basierend auf der langjährigen praktischen Erfahrung einiger Initiatoren wird sie mittlerweile als Open-Source-Projekt durch ein engagiertes Team kollaborativ weiterentwickelt [3]. aim42 adressiert Business und Technik gleichermaßen. Die zentralen Konzepte von aim42 kommen Ihnen garantiert bekannt vor: Probleme, (Lösungs-)Maßnahmen, Kosten und Risiken. aim42 packt diese Aspekte in einen methodischen Rahmen und stellt sicher, dass wirklich relevante Probleme auch durch Maßnahmen abgedeckt werden und nicht vorschnell an Themen optimiert wird, die nur geringen geschäftlichen Nutzen erbringen. Abb. 1: Wunschsituation kommerzieller Software Abb. 2: Istsituation kommerzieller Software Probleme verursachen Kosten Um Verbesserungen effektiv an realen Bedürfnissen auszurichten, sollten Sie für alle erkannten Probleme innerhalb von Softwaresystemen oder beteiligten Prozessen explizit deren Kosten ermitteln: Welche Kosten entstehen beispielsweise durch direkt zurechenbaren Mehraufwand bei Entwicklung oder Betrieb, wie viel Geld kostet zusätzlich benötigte Hardware, welcher Umsatzausfall oder welche Opportunitätskosten fallen durch enttäuschte Kunden oder entgangene Verkäufe an? Zu den Kosten ermitteln Sie, in welcher Frequenz sie anfallen etwa bei jeder Änderung, bei jedem Release des Systems oder bei jedem Aufruf einer bestimmten Systemfunktion. aim42 nennt das problem list, eine Liste oder Tabelle sämtlicher bisher erkannten Probleme samt ihrer geschätzten Kosten. Erst wenn Sie die Kosten von Problemen kennen, können Sie mit anderen Stakeholdern zielgerichtet über Prioritäten und mögliche Abhilfen diskutieren. aim42 unterstützt Sie durch pragmatische und einfache Ansätze in dieser Bewertung. Kontinuität und Iteration Aus der Vogelperspektive teilt aim42 die systematische Verbesserung in drei Phasen ein (Abb. 4): 55

4 1. Analyze: Aufdecken und sammeln von Problemen. Gleichzeitig sollten Sie in der Analyse auch Ver ständnis für die Organisation, Struktur und Lösungskonzepte des Systems Abb. 4: Drei Phasen der gewinnen, weil das für die Verbesserung Erkennung von Problemen und Risiken fundamental ist. 2. Evaluate: Schätzen oder ermitteln des (Geld-)Werts von Problemen und Maßnahmen. Das ermöglicht zielgerichtete Priorisierung und Planung. Diese Bewertung reichert Probleme und Maßnahmen um relevante Steuerinformationen und KPIs für das IT- und technische Management an. 3. Improve: Durchführen von Verbesserungsmaßnahmen. Hier fasst aim42 bewährte Patterns und Praktiken von Evolution, Refactoring, Migration oder stufenweisem Umbau zusammen. Kontinuität und Iteration Verbesserung ist ein kontinuierlicher Prozess (Abb. 5). aim42 funktioniert für beliebige Entwicklungs- oder Wartungsprozesse und teilt relevante Aktivitäten (Praktiken, Vorgehensmuster) in Phasen ein. Diese Aktivitäten können Sie in Ihrem normalen Entwicklungsvorgehen nahtlos integrieren. Eine gedankliche Schleife wiederholt sich in aim42 immer wieder: (1) Sie finden ein Problem oder dessen Ursachen, (2) bewerten dieses Problem hinsichtlich seiner Kosten und (3) identifizieren Lösungsmaßnahmen dafür. Grundkonzepte aim42 1. Sammeln Sie in der Analyse möglichst viele Probleme, die Sie rund um das System und dessen Organisation finden können (Abb. 3). 2. Jedes Problem bewerten Sie hinsichtlich seiner einmaligen und/oder wiederholten Kosten. Hierbei werden Sie oft auf Schätzungen sowie Annahmen angewiesen sein halten Sie diese Bewertungen fest. Auf Basis der Kosten können Sie hervorragend Prioritäten festlegen. 3. Manche Probleme sind nur Symptome von tieferliegenden Ursachen die Root Cause Analysis hilft, ihnen systematisch auf die Spur zu kommen. 4. Suchen Sie mit technisch kundigen Beteiligten nach Maßnahmen, die die - se konkreten Probleme oder deren Ursachen lösen oder beheben. Zwi schen Maßnahmen und Problemen respektive Ursachen besteht eine m:n-beziehung eine einzige Maßnahme kann mehrere Probleme adressieren, ein Problem kann zur Lösung mehrere Maßnahmen benötigen. 5. Auch Maßnahmen haben Kosten, die Sie systematisch ermitteln oder schätzen müssen. 6. Maßnahmen können Nebenwir kungen besitzen oder negative Seiteneffekte. Legen Sie diese offen. 7. Die Gegenüberstellung von Kostenvon-Maßnahmen sowie den Kostendes-Problems ergibt eine wertvolle Entscheidungshilfe für Budget- oder fachlich Verantwortliche. Damit müssen Softwarearchitekten end lich nicht mehr über die schwer vermittelbaren inneren Qualitäten, Kopp lung, Kohäsion oder Implementierungsdetails argu mentieren, sondern können in Businesssprache argumentieren. 8. aim42 arbeitet hochgradig iterativ: Bewertungen von Problemen und Maßnahmen können sich über die Zeit ändern, wie sich in modernen Entwicklungsprozessen auch die Prioritäten von beispielsweise Anforde rungen oder Zielen über die Zeit ändern können. Regelmäßige (iterative) Überprüfung der problem list und des improvement backlog stellen deren Aktualität sicher. Abb. 3: Basiskonzepte systematischer Verbesserung (nach aim42) 56 bt

5 (4) Sie wenden die Lösungsmaßnahme an und (5) analysieren ob das ursprüngliche Problem damit behoben ist. Diese Schleife läuft in ähnlicher Form in jeglicher Art von Konstruktions- oder Optimierungsprozessen ab. Nach meiner Erfahrung kranken viele Systeme in der Praxis daran, dass die technisch Verantwortlichen vor der Bewertung der Kosten von Problem und Maßnahmen zurückschrecken. Stattdessen argumentieren sie über Prinzipien der Softwaretechnik oder technische Konzepte und scheitern damit bei Management oder Auftraggebern. Praktiken und (Vorgehens-)Muster aim42 katalogisiert zurzeit fast achtzig erprobte Praktiken und (Vorgehens-)Muster. Einige Beispiele finden Sie im Textkasten Auszug Praktiken und Patterns. Allerdings garantiert der Einsatz dieser Praktiken und Muster keinen Erfolg: Wie andere mächtige Werkzeuge auch gehört zur Anwendung dieser Praktiken Fingerspitzengefühl und etwas Erfahrung. Zwar finden Sie in der Methodenreferenz zu aim42 [4] eine Menge Hinweise über wenn, wann und wie, aber eine leistungsfähige Methode ist eben kein Algorithmus. Analyse: Verständnis gewinnen und Probleme identifizieren Gewinnen Sie einen Überblick über Zweck, Aufgaben und insbesondere Qualitätsanforderungen an das System. Klären Sie interne Strukturen, Konzepte und wesentliche Architekturansätze. Dabei suchen Sie nach Problemen, Symptomen, Risiken oder technischen Schulden innerhalb des Systems, seiner Betriebs- oder Ablaufumgebung und allen zugehörigen Prozessen. Notieren Sie Lösungsideen (Maßnahmenvorschläge, remedies ). Evaluate: Abbildung auf betriebswirtschaftliche GröSSen Stellen Sie die Vergleichbarkeit von Problemen und Lösungsmaßnahmen sicher, indem Sie deren betriebswirtschaftliche Werte (etwa in Euro oder Aufwandsgrößen) schätzen oder ermitteln. Damit können Sie Probleme und mögliche Maßnahmen priorisieren. Improve: Mehr als nur Refactoring Planen und koordinieren Sie die auf konkrete Probleme bezogenen Verbesserungsmaßnahmen. Ändern Sie, je nach Situation, Quellcode, Konzepte oder beteiligte Entwicklungs- oder Betriebsprozesse. Reduzieren Sie technische Schulden. Optimieren Sie Qualitätseigenschaften, beispielsweise Wartbarkeit, Verständlichkeit, Sicherheit oder Performance. Sämtliche Verbesserungen beziehen sich dabei auf Probleme oder deren Ursachen, die Sie in der Analysephase erkannt und anschließend Abb. 5: Kontinuierliche Verbesserung iterativer Prozess bewertet haben so stellen Sie sicher, keine Veränderung um ihrer selbst willen durchzuführen. Improvement Backlog Eine wesentliche Frage innerhalb der kontinuierlichen Verbesserung habe ich bisher offen gelassen: Woher kommen die konkreten Verbesserungsvorschläge und -maßnahmen? In der Bewertungsphase wollen wir diese Maßnahmen bezüglich ihrer Aufwände und Risiken bewerten, und in der Verbesserungsphase wollen wir sie umsetzen aber wann definieren wir sie überhaupt? Die Antwort lautet kontinuierlich : Ideen, Maßnahmen, Taktiken oder Strategien zur Verbesserung finden Sie in jeder der aim42-phasen. Ich empfehle Ihnen, im Rahmen der systematischen Verbesserung von Software dazu einen Improvement Backlog zu führen, d. h. sämtliche Ideen für Verbesserungen im Rahmen einer Aufgabenliste zu dokumentieren. Auch hierfür gilt wieder das Prinzip der systematischen Sparsamkeit: Halten Sie diese Dokumentation kurz und knapp. Aktualität ist wichtiger als Vollständigkeit, Transparenz wichtiger als Ausführlichkeit (Abb. 6). Community: Mitmachen erwünscht aim42 ist ein junges Open-Source-Projekt, das noch tatkräftige Unterstützung benötigt. Die bisherigen Committer bringen ihre langjährige und reichhaltige Erfahrung ein und die gesamte Community freut sich über weitere Anregungen und Input. Für Interessierte: Das Handbuch zur Methodik (der so genannte Method-Guide) wird im AsciiDoc-Format [5] geschrieben und automatisch im aim-guide publiziert. Der gesamte Text liegt unter einer liberalen Creative-Commons-Lizenz auf einem öffentlichen GitHub Repository [6]. Werfen Sie einen Blick Abb. 6: Maßnahmen in allen auf unsere offenen Punk- Phasen sammeln 57

6 te [7], ergänzen Sie Kommentare oder machen Sie Verbesserungsvorschläge. Fazit aim42 fasst bekannte und bewährte Praktiken und Vorgehensmuster für die Evolution und systematische Verbesserung von Software in einem methodischen Rahmen zusammen. In vielen Real-Life-Situationen haben diese Praktiken ihre Praxistauglichkeit unter Beweis gestellt aim42 integriert sie in einem gemeinsamen Kontext. Danksagung: Danke an die fleißigen Reviewer dieses Artikels, Per Starke, Oliver Tigges, Burkhard Neppert, Tammo van Lessen, Stefan Tilkov, Gerrit Beine, Roland Schimmack, Michael Mahlberg und das aim42-team. Links & Literatur [1] Martin, Robert: Clean Code Handbook of Agile Software Craftmanship, Prentice Hall, 2008 [2] [3] Website mit weiteren Details zur Methode: [4] aim42-method-guide, das Handbuch zur Methode, enthält einen umfangreichen Katalog von Patterns und Practices sowie ein Literaturverzeichnis: [5] [6] Der Code: https://github.com/aim42 [7] offene Punkte und Verbesserungsvorschläge zu aim42: https://github.com/aim42/aim42/issues Dr. Gernot Starke (innoq-fellow) ist Diplom-Informatiker, Berater und Trainer für methodische Softwareentwicklung und Softwarearchitektur. Er hat mehr als zwanzig Jahre Erfahrung in Entwurf und Entwicklung mittlerer bis großer Softwaresysteme und ist (Mit-) Gründer von arc42 sowie Gründungsmitglied des isaqb e.v. Auszug Praktiken und Patterns An einigen Beispielen möchte ich Granularität und Scope von aim42 aufzeigen. Für eine ganzheitliche Übersicht über alle aktuellen aim42-praktiken und Patterns verweise ich Sie auf das Onlinemethodenhandbuch [4]. Anticorruption Layer: Isoliere Clients von internen Änderungen an Subsystemen. ATAM: Architecture-Tradeoff-Analysis, findet Risiken in Architektur. Assertions: Über Zusicherungen im Code fehlerhafte Annahmen aufdecken. Branch for Improvement: Über unterschiedliche Branch es in der Versionsverwaltung verschiedene Stände der Veränderung abbilden. Capture Quality Requirements: Qualitätsziele verschiedener Beteiligter offenlegen. Context Analysis: Systemkontext und externe Schnittstellen klären und dokumentieren. Data Analysis: In Daten und Datenstrukturen nach Problemen oder Komplexität suchen. Estimate Problem Cost: Kosten von Problemen ermitteln. Extract Reusable Component: Aus bestehendem System wiederverwendbare Teile extrahieren. Frontend Switch: In der Benutzeroberfläche Anfragen entweder an alte oder veränderte Teile des Systems routen. Hierarchical Quality Model: Qualitätsziele konkretisieren durch Qualitätsbaum mit Szenarien. Improvement Backlog: Pflege eine Übersicht möglicher Verbesserungsmaßnahmen, inklusive ihrer Kosten und Risiken. Introduce Boy Scout Rule: Hinterlasse Code nach Änderungen immer sauberer als vorher. Issue Tracker Analysis: Bug oder Issue Tracker bezüglich Cluster und Häufungen untersuchen. Keep Data, Toss Code: Systeme durch massive Änderungen im Code, aber unter Beibehaltung der relevanten Daten verbessern. Pre-Interview Questionnaire: Interviews durch Stakeholder- und situationsspezifische Fragebögen vorbereiten. Profiling: Vermesse Speicher- und anderen Ressourcenverbrauch zur Laufzeit. Qualitative Analysis: Risikobewertung der systemrelevanten Qualitätsanforderungen auf Basis der getroffenen Architekturentscheidungen. Refactoring Plan: Teamweite Koordination und Abstimmung von Refactoring-Maßnahmen zur groß angelegten Codeverbesserung. Root Cause Analysis: Finde die Ursache von Problemen differenziere Ursache und Symptom. Software Archeology: Verstehe Software durch Analyse von Quellcode und seiner Versionshistorie. Stakeholder Interview: Finde Probleme durch Befragung relevanter Beteiligter. Static Code Analysis: Analysiere Quellcode, um zusammengehörige Bausteine, Abhängigkeiten, Kohäsion und andere strukturelle Eigenschaften zu finden. 58 bt

Umsichtig planen, robust bauen

Umsichtig planen, robust bauen Umsichtig planen, robust bauen iks Thementag Mehr Softwarequalität Best practices für alle Entwicklungsphasen 19.06.2012 Autor: Christoph Schmidt-Casdorff Agenda Softwarearchitektur Architekturkonformität

Mehr

Bewertung von Software- Architekturen. Dipl.-Ing. Mahbouba Gharbi @email: m.gharbi@itech-progress.com

Bewertung von Software- Architekturen. Dipl.-Ing. Mahbouba Gharbi @email: m.gharbi@itech-progress.com Bewertung von Software- Architekturen Dipl.-Ing. Mahbouba Gharbi @email: m.gharbi@itech-progress.com ITech Progress GmbH 2012 Agenda Motivation Bewertung von Software-Architekturen Qualitative Bewertung

Mehr

Gernot Starke. Effektive Softwarearchitekturen. Ein praktischer Leitfaden ISBN: 978-3-446-42728-0. Weitere Informationen oder Bestellungen unter

Gernot Starke. Effektive Softwarearchitekturen. Ein praktischer Leitfaden ISBN: 978-3-446-42728-0. Weitere Informationen oder Bestellungen unter Gernot Starke Effektive Softwarearchitekturen Ein praktischer Leitfaden ISBN: 978-3-446-42728-0 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42728-0 sowie im Buchhandel.

Mehr

Risikogetriebene Softwarearchitektur. STEFAN TOTH Agile Bodensee 26.09.2013

Risikogetriebene Softwarearchitektur. STEFAN TOTH Agile Bodensee 26.09.2013 Risikogetriebene Softwarearchitektur STEFAN TOTH Agile Bodensee 26.09.2013 0 Die Hacke für den Klotz am Bein STEFAN TOTH Agile Bodensee 26.09.2013 0 Stefan Toth Stefan.Toth@oose.de st_toth seit 06/2008

Mehr

Inhaltsverzeichnis. Gernot Starke. Effektive Softwarearchitekturen. Ein praktischer Leitfaden ISBN: 978-3-446-42728-0

Inhaltsverzeichnis. Gernot Starke. Effektive Softwarearchitekturen. Ein praktischer Leitfaden ISBN: 978-3-446-42728-0 sverzeichnis Gernot Starke Effektive Softwarearchitekturen Ein praktischer Leitfaden ISBN: 978-3-446-42728-0 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42728-0 sowie im

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

Fachhochschule für Technik und Wirtschaft Berlin FB4: Wirtschaftsinformatik

Fachhochschule für Technik und Wirtschaft Berlin FB4: Wirtschaftsinformatik Fachhochschule für Technik und Wirtschaft Berlin FB4: Wirtschaftsinformatik Entwicklung und Evaluation eines Vorgehensmodells zur Optimierung des IT-Service im Rahmen eines IT-Assessment Framework Oliver

Mehr

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

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

Mehr

WSR 2004. Softwarewartung und Prozessmodelle in Theorie und Praxis. Urs Kuhlmann Andreas Winter

WSR 2004. Softwarewartung und Prozessmodelle in Theorie und Praxis. Urs Kuhlmann Andreas Winter WSR 2004 Softwarewartung und Prozessmodelle in Theorie und Praxis Urs Kuhlmann Andreas Winter Universität Koblenz-Landau 1 Gliederung Wartungsbegriff Prozessmodelle Fallstudien Problembereiche Fazit 2

Mehr

Experience. nr.52. ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen. märz 2012

Experience. nr.52. ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen. märz 2012 ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen Experience nr.52 märz 2012 RequIREMENTs EngINEERINg Ins Schwarze treffen Ins SchwARze treffen Requirements Engineering: die Grundlagen

Mehr

Stefan Toth. Befehl von unten: Softwarearchitektur für dynamische Projekte

Stefan Toth. Befehl von unten: Softwarearchitektur für dynamische Projekte Stefan Toth Befehl von unten: Softwarearchitektur für dynamische Projekte [ ] Ob man diese Entwickler schließlich Architekten nennt oder nicht, bleibt dem Projekt überlassen und sollte für die tatsächliche

Mehr

ITSM-Health Check: die Versicherung Ihres IT Service Management. Christian Köhler, Service Manager, Stuttgart, 03.07.2014

ITSM-Health Check: die Versicherung Ihres IT Service Management. Christian Köhler, Service Manager, Stuttgart, 03.07.2014 : die Versicherung Ihres IT Service Management Christian Köhler, Service Manager, Stuttgart, 03.07.2014 Referent Christian Köhler AMS-EIM Service Manager Geschäftsstelle München Seit 2001 bei CENIT AG

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

Experten-Review für Ihre Microsoft SharePoint-Architektur. Maximaler Nutzen, hohe Stabilität und Sicherheit für Ihre SharePoint-Farm

Experten-Review für Ihre Microsoft SharePoint-Architektur. Maximaler Nutzen, hohe Stabilität und Sicherheit für Ihre SharePoint-Farm Experten-Review für Ihre Microsoft SharePoint-Architektur Maximaler Nutzen, hohe Stabilität und Sicherheit für Ihre SharePoint-Farm Heben Sie mit Materna die Potenziale Ihrer SharePoint-Umgebung. Microsoft

Mehr

your IT in line with your Business Geschäftsprozessmanagement (GPM)

your IT in line with your Business Geschäftsprozessmanagement (GPM) your IT in line with your Business Geschäftsprozessmanagement (GPM) Transparenz schaffen und Unternehmensziele effizient erreichen Transparente Prozesse für mehr Entscheidungssicherheit Konsequente Ausrichtung

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

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

Umfrage zum Informationsbedarf im Requirements Engineering

Umfrage zum Informationsbedarf im Requirements Engineering Umfrage zum Informationsbedarf im Requirements Engineering Vielen Dank für Ihre Teilnahme an dieser Studie! Im Rahmen eines Forschungsprojektes an der Universität Hamburg und der TU Graz führen wir eine

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

Architektur und Qualität. Tjard Köbberling

Architektur und Qualität. Tjard Köbberling Architektur und Qualität Tjard Köbberling Gliederung Überblick Architektur und Qualität? Architekturentwurf Anforderungsanalyse Strukturierung Architekturbeschreibungen - Sichten Fallbeispiel 2 Architektur

Mehr

Architekturdokumentation leicht gemacht

Architekturdokumentation leicht gemacht Architekturdokumentation leicht gemacht Andreas Richter ar@anrichter.net @anrichter www.anrichter.net Architekturdokumentation Warum überhaupt Dokumentieren? Das arc42 Template Wie mach ich das nu? Ausblick

Mehr

Software Engineering

Software Engineering Software Engineering Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik Prof. A. Müller, FH KL Software Engineering 2015 1 Inhalte Begrüßung Vorstellung, Übersicht Formales

Mehr

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

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

Mehr

Warum 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 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

Mehr

Dr. Carola Lilienthal www.dpunkt.de/plus

Dr. Carola Lilienthal www.dpunkt.de/plus Dr. Carola Lilienthal ist Senior-Softwarearchitektin und Mitglied der Geschäftsleitung der WPS Workplace Solutions GmbH in Hamburg. Dort verantwortet sie den Bereich Softwarearchitektur und gibt ihr Wissen

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

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

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16 Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle

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

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

Agiles Testen. Gedankensammlung. 17. November 2013 - Patrick Koglin

Agiles Testen. Gedankensammlung. 17. November 2013 - Patrick Koglin Agiles Testen Gedankensammlung 17. November 2013 - Patrick Koglin Inhalt Reflektion: Agilität notwendig? Wo? Eigenschaften agiler Entwicklung Quality is everyone s responsibility Qualität möglich machen

Mehr

16 Architekturentwurf Einführung und Überblick

16 Architekturentwurf Einführung und Überblick Teil III: Software-Architekturentwurf 16 Architekturentwurf Einführung und Überblick 16.1 Software entwerfen Warum? Beim Arbeiten im Kleinen nicht oder nur ansatzweise (Detailentwurf) Größere Software

Mehr

Andrea Grass & Dr. Marcus Winteroll oose Innovative Informatik GmbH. Geschäftsprozessmanagement und Agilität geht das zusammen?

Andrea Grass & Dr. Marcus Winteroll oose Innovative Informatik GmbH. Geschäftsprozessmanagement und Agilität geht das zusammen? Andrea Grass & Dr. Marcus Winteroll oose GmbH Geschäftsprozessmanagement und Agilität geht das zusammen? Agenda I. Wozu eigentlich BPM? II. Vorgehen und Rollen im abpm III. Methoden und Techniken IV. Resümee

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

So bin ich, so arbeite ich: Analytisch. Ergebnisorientiert. Umsetzungsstark. Motivierend.

So bin ich, so arbeite ich: Analytisch. Ergebnisorientiert. Umsetzungsstark. Motivierend. OFFICE EXCELLENCE Schlanke Prozesse für Ihre Verwaltung Die Idee einer Verbesserung von administrativen Prozessen ist unter verschiedenen Bezeichnungen wiederzufinden: Kaizen im Office, KVP im Büro, Lean

Mehr

Verbesserung der Architektur und Dokumentation der DPP-Software Saros. Slawa Belousow Institut für Informatik FU Berlin 13.01.2011

Verbesserung der Architektur und Dokumentation der DPP-Software Saros. Slawa Belousow Institut für Informatik FU Berlin 13.01.2011 Verbesserung der Architektur und Dokumentation der DPP-Software Saros Slawa Belousow Institut für Informatik FU Berlin 13.01.2011 Vorstellung der Arbeit Problem Entwicklung wird immer schwieriger Ziel

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

Übung 6: Feinentwurf. Prof. Dr. Dr. h.c. Manfred Broy Dr. Herbert Ehler, Martin Feilkas 6. Juli 2006 Bernd Spanfelner, Sebastian Winter

Übung 6: Feinentwurf. Prof. Dr. Dr. h.c. Manfred Broy Dr. Herbert Ehler, Martin Feilkas 6. Juli 2006 Bernd Spanfelner, Sebastian Winter Prof. Dr. Dr. h.c. Manfred Broy Sommersemester Dr. Herbert Ehler, Martin Feilkas 6. Juli 2006 Bernd Spanfelner, Sebastian Winter Einführung in die Softwaretechnik Übung 6: Feinentwurf Aufgabe 17: Entwurfsmuster

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

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

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

Mehr

Systemkontext und -umfang festlegen

Systemkontext und -umfang festlegen Systemkontext und -umfang festlegen Requirements Engineering Bereich Anforderungen Aktivität (Kunden-)Anforderungen erheben Ziele Identifikation der fachlichen Einsatzumgebung eines Softwaresystems Identifikation

Mehr

Technische Aspekte des erfolgreichen Testens von Software in Unternehmen

Technische Aspekte des erfolgreichen Testens von Software in Unternehmen Technische Aspekte des erfolgreichen Testens von Software in Unternehmen Tim A. Majchrzak Agenda 1 Einführung 2 Hintergrund 3 Vorgehen und Methodik 4 Handlungsempfehlungen 5 Fazit 2 Agenda 1 Einführung

Mehr

ERP-Systemeinsatz bewerten und optimieren

ERP-Systemeinsatz bewerten und optimieren ERP-Systemeinsatz bewerten und optimieren Handlungsfelder zur Optimierung des ERP-Systemeinsatzes ERP-Lösungen werden meist über viele Jahre lang eingesetzt, um die Geschäftsprozesse softwaretechnisch

Mehr

- Agile Programmierung -

- Agile Programmierung - Fachhochschule Dortmund Fachbereich Informatik SS 2004 Seminar: Komponentenbasierte Softwareentwicklung und Hypermedia Thema: - - Vortrag von Michael Pols Betreut durch: Prof. Dr. Frank Thiesing Übersicht

Mehr

Wie viel Geschäftsprozess verträgt agile Softwareentwicklung?

Wie viel Geschäftsprozess verträgt agile Softwareentwicklung? @LeanAgileScrum #LASZH LAS Conference 2012 Sponsoren Wie viel Geschäftsprozess verträgt agile Softwareentwicklung? Marcus Winteroll 16:15 Auditorium Organisationsteam Patrick Baumgartner (Swiftmind GmbH)

Mehr

SERVICE SUCHE ZUR UNTERSTÜTZUNG

SERVICE SUCHE ZUR UNTERSTÜTZUNG SERVICE SUCHE ZUR UNTERSTÜTZUNG VON ANFORDERUNGSERMITTLUNG IM ERP BEREICH MARKUS NÖBAUER NORBERT SEYFF ERP SYSTEME Begriffsbestimmung: Enterprise Resource Planning / Business Management Solution Integrierte

Mehr

itestra Software Tuning Mehr Leistung. Weniger Kosten. Software Productivity

itestra Software Tuning Mehr Leistung. Weniger Kosten. Software Productivity itestra Software Productivity Software Tuning Mehr Leistung. Weniger Kosten. Fit für die Zukunft Performance-Defizite in Software-Systemen verursachen jedes Jahr Mehrausgaben für Betrieb und Nutzung in

Mehr

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum

Taking 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

Mehr

Integration mit Service Repositories zur SOA Governance

Integration mit Service Repositories zur SOA Governance Integration mit Service Repositories zur SOA Governance Nürnberg, 10.11.2009 I N H A L T 1. SOA Governance 2. Service Repository 3. Modelle und Service Repository 4. Modell-Driven SOA I N H A L T 1. SOA

Mehr

DAS INBOUND MARKETING SPIEL. Eine Spielanleitung www.need-for-lead.com

DAS INBOUND MARKETING SPIEL. Eine Spielanleitung www.need-for-lead.com DAS INBOUND MARKETING SPIEL Eine Spielanleitung www.need-for-lead.com Vorwort Leads das ist die Währung, die wirklich zählt. Denn aus Leads werden im besten Fall Kunden. Und die wertvollsten Leads sind

Mehr

Bringen Sie Klarheit in Ihre Ausrichtung mit dem KMU*STAR. Strategie-Entwicklung für KMU

Bringen Sie Klarheit in Ihre Ausrichtung mit dem KMU*STAR. Strategie-Entwicklung für KMU Bringen Sie Klarheit in Ihre Ausrichtung mit dem KMU*STAR Strategie-Entwicklung für KMU Sicher und klug entscheiden Hat auch Ihr KMU mit erschwerten Rahmenbedingungen zu kämpfen, wie mit Veränderungen

Mehr

JOB MANAGEMENT MIT DEM SAP SOLUTION MANAGER. Whitepaper

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

Mehr

CA Clarity PPM. Übersicht. Nutzen. agility made possible

CA Clarity PPM. Übersicht. Nutzen. agility made possible PRODUKTBLATT CA Clarity PPM agility made possible CA Clarity Project & Portfolio Management (CA Clarity PPM) unterstützt Sie dabei, Innovationen flexibel zu realisieren, Ihr gesamtes Portfolio bedenkenlos

Mehr

Wie wirksam wird Ihr Controlling kommuniziert?

Wie wirksam wird Ihr Controlling kommuniziert? Unternehmenssteuerung auf dem Prüfstand Wie wirksam wird Ihr Controlling kommuniziert? Performance durch strategiekonforme und wirksame Controllingkommunikation steigern INHALT Editorial Seite 3 Wurden

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

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

Mehr

Den Unterschied machen Ein Leitfaden für IT- Entscheider in Versicherungsunternehmen

Den Unterschied machen Ein Leitfaden für IT- Entscheider in Versicherungsunternehmen Den Unterschied machen Ein Leitfaden für IT- Entscheider in Versicherungsunternehmen Den Unterschied machen Ein Leitfaden für IT- Entscheider in Versicherungsunternehmen Das Asskura- Modell ist ein Werkzeug,

Mehr

Requirements Engineering (Anforderungstechnik)

Requirements Engineering (Anforderungstechnik) 5 Requirements Engineering Einführung 5.1 Was ist Requirements Engineering? Erste Näherung: Requirements Engineering (Anforderungstechnik) ist das systematische, disziplinierte und quantitativ erfassbare

Mehr

Die PROJEN-GmbH bietet ihren Kunden einheitliche

Die PROJEN-GmbH bietet ihren Kunden einheitliche Die PROJEN-GmbH Hintergründe und Entstehung Der Ursprung der PROJEN-GmbH liegt in der Projektmanagement-Beratung. Die Firmengründer haben 2011 gemeinschaftlich ein ganzheitliches Konzept für professionelles

Mehr

iteratec Business Breakfast Optimierung von Applikationslandschaften

iteratec Business Breakfast Optimierung von Applikationslandschaften iteratec Business Breakfast Optimierung von Applikationslandschaften Best Practice Erfahrungen Lothar Weber Zürich, 11.06.2014 Agenda Optimierung von Applikationslandschaften 8:00 8:05 Begrüssung 8:05

Mehr

Requirements Management Wissensmanagement für und mit Anforderungen

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

Mehr

Das Handwerkszeug. Teil I

Das Handwerkszeug. Teil I Teil I Das Handwerkszeug Beratung in der IT 3 Beratung ist ein häufig gebrauchter und manchmal auch missbrauchter Begriff in der IT. Wir versuchen in diesem Einstieg etwas Licht und Klarheit in diese Begriffswelt

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

1 Einleitung... 1. 2 Vorstellung der Fallstudie KnowBeer... 5

1 Einleitung... 1. 2 Vorstellung der Fallstudie KnowBeer... 5 1 Einleitung... 1 2 Vorstellung der Fallstudie KnowBeer... 5 Teil I: Überblick Der Business Rules Ansatz 3 Ausgangslage... 11 3.1 Was ist das Problem?... 11 3.2 Motivation: Sinnvolle Unternehmen... 12

Mehr

ITIL in 60 Minuten. Jörn Clausen. joernc@gmail.com. Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules.

ITIL in 60 Minuten. Jörn Clausen. joernc@gmail.com. Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules. ITIL in 60 Minuten Jörn Clausen joernc@gmail.com Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules. Elizabeth Swann: Hang the code, and hang the rules. They re

Mehr

vii Inhaltsverzeichnis 1 Einleitung 1

vii Inhaltsverzeichnis 1 Einleitung 1 vii 1 Einleitung 1 1.1 Softwarearchitektur als Disziplin im Software Engineering........ 2 1.2 isaqb International Software Architecture Qualification Board.......... 4 1.3 Certified Professional for Software

Mehr

Kanban Agile 2.0? Thomas Schissler artiso AG

Kanban Agile 2.0? Thomas Schissler artiso AG Kanban Agile 2.0? Thomas Schissler artiso AG Vorstellung Thomas Schissler Coach und Consultant artiso AG Schwerpunkte sind Team Foundation Server Agile Entwicklungsprozesse Software-Qualität Software-Architektur

Mehr

Kundeninformation DIN EN ISO 9001:2015 - die nächste große Normenrevision

Kundeninformation DIN EN ISO 9001:2015 - die nächste große Normenrevision Kundeninformation DIN EN ISO 9001:2015 - die nächste große Normenrevision Einführung Die DIN EN ISO 9001 erfährt in regelmäßigen Abständen -etwa alle 7 Jahreeine Überarbeitung und Anpassung der Forderungen

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

Das Agile Team. Skills, Arbeitsweise, Umgebung

Das Agile Team. Skills, Arbeitsweise, Umgebung Das Agile Team Skills, Arbeitsweise, Umgebung Das Team handelt Das Team Verwandelt Anforderungen in potentially shippable product increment Der handelnde Agent Selbstorganisiert - was heisst das Gemeinsam

Mehr

Lösungen zum Test objektorientierter Software

Lösungen zum Test objektorientierter Software Lösungen zum Test objektorientierter Software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14. März 2013 HOM/FHTeL Lösungen zum Test objektorientierter Software

Mehr

Extreme Programming ACM/GI Regionalgruppe Bremen, 12.6.2001

Extreme Programming ACM/GI Regionalgruppe Bremen, 12.6.2001 Extreme Programming ACM/GI Regionalgruppe Bremen, 12.6.2001 Tammo Freese OFFIS, Oldenburg freese@acm.org http://www.tammofreese.de Frank Westphal unabhängiger Berater westphal@acm.org http://www.frankwestphal.de

Mehr

oose. Was (noch) klassische Projekte von Scrum & Co lernen können eine empirische Studie

oose. Was (noch) klassische Projekte von Scrum & Co lernen können eine empirische Studie Was (noch) klassische Projekte von Scrum & Co lernen können eine empirische Studie München, 06.05.2009 Markus Wittwer, oose GmbH 2009 by de GmbH Markus Wittwer Berater und Trainer Coach für agile Projekte

Mehr

Windows Server 2003 End of Service

Windows Server 2003 End of Service Windows Server 2003 End of Service Herausforderungen & Migration Michael Korp Microsoft Deutschland GmbH Ende des Support für 2003, 2008, 2008 R2 Ende des Support für Windows 2003 Ende des Mainstream Support

Mehr

Requirements Lifecycle Management (RLM)

Requirements Lifecycle Management (RLM) Whitepaper Requirments Lifecycle Management Requirements Lifecycle Management (RLM) Die Weiterentwicklung der klassischen Anforderungsanalyse 1 Einleitung War noch vor einiger Zeit die klassische Anforderungsanalyse

Mehr

Agile BI Kickstart. Beschreibung des Workshops. Workshopbeschreibung

Agile BI Kickstart. Beschreibung des Workshops. Workshopbeschreibung Bereich: Workshop: Dauer: In-House Workshop Agile BI Kickstart 2 Tage Beschreibung des Workshops Agile Vorgehensweisen werden bei der Entwicklung von BI- und Data Warehouse-Lösungen heutzutage mehr und

Mehr

Anwenderforum E-Government QuickCheck:ITIL 18.02.2010/Berlin

Anwenderforum E-Government QuickCheck:ITIL 18.02.2010/Berlin Anwenderforum E-Government QuickCheck:ITIL 18.02.2010/Berlin INFORA GmbH Martin Krause Cicerostraße 21 10709 Berlin Tel.: 030 893658-0 Fax: 030 89093326 Mail: info@infora.de www.infora.de Agenda Die Ausgangssituation

Mehr

Langlebige Softwarearchitekturen

Langlebige Softwarearchitekturen Langlebige Softwarearchitekturen Dr. Carola Lilienthal Carola.Lilienthal@wps.de www.wps.de //// Hans-Henny-Jahnn-Weg 29 //// 22085 HAMBURG Die zwei Architekturziele für diesen Vortrag Architekturziel 1:

Mehr

Prozessbewertung 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 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

Mehr

Software Produktlinien: Einführung und Überblick

Software Produktlinien: Einführung und Überblick C A R L V O N O S S I E T Z K Y Software Produktlinien: Einführung und Überblick Johannes Diemke Vortrag im Rahmen des Seminars Software System Engineering im Wintersemester 2007/2008 Übersicht 1 Motivation

Mehr

Bewertungsansätze für IT Application Evolution

Bewertungsansätze für IT Application Evolution Bewertungsansätze für IT Application Evolution ACADEMY GOV, 26. August 2015 Dr. Beat Fluri, Senior Solution Architect Über mich Beat Fluri Zürich Senior Solution Architect MSc ETH, Dr. Inform. UZH Bei

Mehr

Software-Dokumentation im agilen Entwicklungsprozess

Software-Dokumentation im agilen Entwicklungsprozess Software-Dokumentation im agilen Entwicklungsprozess Ulrike Müller, Knowledge Manager, SAP AG Monika Pfanner, Knowledge Architect, SAP AG tekom-herbsttagung Wiesbaden, 24. Oktober 2012 SAP und Knowledge

Mehr

Hilfe, mein SCRUM-Team ist nicht agil!

Hilfe, 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

Mehr

Abschlussvortrag Masterarbeit: Operationalizing Architecture in an agile Software Projec

Abschlussvortrag Masterarbeit: Operationalizing Architecture in an agile Software Projec Abschlussvortrag Masterarbeit: Operationalizing in an agile Software Projec Freie Universität Berlin, Institut für Informatik February 2, 2015 Übersicht 2 Was ist Softwarearchitektur? Softwarearchitektur

Mehr

Corporate Websites MEHRSPRACHIGE MULTICHANNEL-PROJEKTE MIT WORKFLOWS. 18. und 19. September DMEXCO 2013. Michael Steinfort, comspace. www.sitecore.

Corporate Websites MEHRSPRACHIGE MULTICHANNEL-PROJEKTE MIT WORKFLOWS. 18. und 19. September DMEXCO 2013. Michael Steinfort, comspace. www.sitecore. Corporate Websites MEHRSPRACHIGE MULTICHANNEL-PROJEKTE MIT WORKFLOWS Michael Steinfort, comspace 18. und 19. September DMEXCO 2013 Deutschland und die Sprachen Corporate Websites haben bei internationalen

Mehr

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

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

Mehr

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

Qualität in Bildung und Beratung. Empfehlungen für die Arbeit mit dem Qualitätsentwicklungssystem QES plus

Qualität in Bildung und Beratung. Empfehlungen für die Arbeit mit dem Qualitätsentwicklungssystem QES plus Empfehlungen für die Arbeit mit dem Qualitätsentwicklungssystem QES plus Bearbeitet von: K. Gerber/ D. Hotze Stand vom 14.08.2007 Empfehlungen für die Arbeit mit dem Qualitätsentwicklungssystem QES plus

Mehr

Agiles Vorgehen Do s und Don ts im Umfeld und beim Management

Agiles Vorgehen Do s und Don ts im Umfeld und beim Management Agiles Vorgehen Do s und Don ts im Umfeld und beim Management Vortrag bei der Fachgruppe IT-Projektmanagement 22. Mai 2015, Steinbeis-Transferzentrum IT-Projektmanagement, Stuttgart hoffmann@stz-itpm.de

Mehr

Agiler Healthcheck. Dieter Bertsch & Sabine Canditt Agile Center Allianz Deutschland München / Januar 2013

Agiler Healthcheck. Dieter Bertsch & Sabine Canditt Agile Center Allianz Deutschland München / Januar 2013 Agiler Healthcheck Dieter Bertsch & Sabine Canditt Agile Center Allianz Deutschland München / Januar 2013 Inhalt 1 2 3 Motivation Existierende Healthchecks Agiler Healthcheck der Allianz "Der Glaube an

Mehr

Agile Softwareentwicklung

Agile Softwareentwicklung Agile Softwareentwicklung Werte, Konzepte und Methoden von Wolf-Gideon Bleek, Henning Wolf 2., aktualisierte und erweiterte Auflage Agile Softwareentwicklung Bleek / Wolf schnell und portofrei erhältlich

Mehr

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

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

Mehr

Effektive Software- Architekturen

Effektive Software- Architekturen Gemot Starke Effektive Software- Architekturen Ein praktischer Leitfaden 4., aktualisierte und erweiterte Auflage HANSER Inhalt Vorwort Vorwort zur vierten Auflage XIII XIV 1 Einleitung 1 1.1 Software-Architekten

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

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

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

Mehr

CONTINUOUS DELIVERY. Entmystifiziert. codecentric AG

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

Mehr

ITILin60Minuten. Jörn Clausen joernc@gmail.com. Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules.

ITILin60Minuten. Jörn Clausen joernc@gmail.com. Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules. ITILin60Minuten Jörn Clausen joernc@gmail.com Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules. Elizabeth Swann: Hang the code, and hang the rules. They re more

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

REZA NAZARIAN. Berater für digitale Projekte PROFIL. Schwerpunkt. Zusammenfassung. Kernkompetenzen

REZA NAZARIAN. Berater für digitale Projekte PROFIL. Schwerpunkt. Zusammenfassung. Kernkompetenzen PROFIL REZA NAZARIAN Telefon: 0163 54 90 761 Email: consulting@reza-nazarian.de Schwerpunkt Zusammenfassung Kernkompetenzen Strukturierte agile Produktentwicklung für sinnvolle technische Lösungen. Als

Mehr

Taxonomy of Evolution and Dependability. Integration Engineering SS 2009 Andreas Landerer

Taxonomy of Evolution and Dependability. Integration Engineering SS 2009 Andreas Landerer Taxonomy of Evolution and Dependability Integration Engineering SS 2009 Andreas Landerer Agenda Informationen über Massimo Felici Definition zentraler Begriffe Inhalt des Artikels Kernaussagen des Artikels

Mehr