Fachausschuss Vertragsrecht der DGRI Sitzung am in München. Moderne Vertragsgestaltung vs. BGB (und BGH?) Beitrag J.

Größe: px
Ab Seite anzeigen:

Download "Fachausschuss Vertragsrecht der DGRI Sitzung am 16.4.2010 in München. Moderne Vertragsgestaltung vs. BGB (und BGH?) Beitrag J."

Transkript

1 Fachausschuss Vertragsrecht der DGRI Sitzung am in München Moderne Vertragsgestaltung vs. BGB (und BGH?) Beitrag J. Schneider Was bleibt bei modernen Projektmethoden von den in der Rspr. entwickelten Positionen? Lösungsmöglichkeiten in der Vertragsgestaltung Berücksichtigung von - BGH v VII ZR 151/08 bei Projektverträgen, zusammen mit - BGH v X ZR 82/07 Tiefladesattelauflieger, und - BGH v III ZR 79/09 Web-Design-Vertrag. 1

2 Gliederung VORWEG Thesen...3 I. Moderne Projektmethoden Manifesto for Agile Software Development Principles behind the Agile Manifesto SCRUM Prototyping V-Modell...7 II. Typische Merkmale moderner Projektmethodik, v.a. bei Extreme Programming.8 1. Versuch Schema zu Extreme Programming Projektverträge in der Rspr., BGB a.f. - Werkvertrag Abgleich Projektvorgehensmodelle und Rspr. Positionen...10 III. BGH intervenierende Variable über 651 BGB? BGH v Silowände BGH v Tiefladesattelaufleger BGH v. 4. März III ZR 79/09 Web-Design-Vertrag...16 IV. OLG München v gegen BGH, Lit OLG München v U 3515/09, CR 2010, Lit. Stellen zu Projektvertrag und V. Argumentationen gegen 651-Anwendung aus den BGH-Urteilen Argumentations-Ansatz aus : Argumentations-Ansatz aus Argumentations-Ansatz aus VI. Was ändert sich für die Diskussion um 651 Anwendung im Hinblick auf neue Methoden? Diskussion Software und Sachqualität Thesen:...20 VII. Lösung: Planungsanteil, Gemischter Vertrag Zwischenüberlegung Gemischte Verträge, Auswirkungen der Theorien dazu? Vorschläge, Alternativen Freigabe als Kompromiss für Spirale, Iteration, Teilabnahme...22 Literaturhinweise

3 VORWEG Thesen Als erkenntnisleitende Frage wird unterstellt: Bei welcher Argumentation bzw. Lösung vermeidet man am ehesten Widersprüche bzw. erzeugt die wenigsten Widersprüche oder zweifelhafte bis unbrauchbare Ergebnisse? Der folgende Reißverschluß-artig gedachte Vortrag kombiniert die Agile- und die 651-er Problematik. These 1: Die drei BGH-Entscheidungen zwingen nicht, über 651 BGB Kaufrecht auf die Erstellung und Anpassung von Software anzuwenden. Die Entscheidung des OLG München würde allerdings dazu führen, 651 BGB strikt nicht anzuwenden mit einer Begründung, die zu unbrauchbaren Verjährungsregelungen führt, zumindest, was AGB des Auftragnehmers betrifft: Bei Ablehnung der Sachqualität und Anwendung Wv-Recht kommt 634a Abs. 1 Nr. 1 nicht mehr als Verjährungsregelung in Betracht (im Verbund mit 634a Abs. 2 Verjährung von zwei Jahren beginnend mit der Abnahme). D.h., dass zwar eine Abnahme durchaus erforderlich ist, diese jedoch nicht für die Verjährung maßgeblich ist. Vielmehr gilt die regelmäßige Verjährungsfrist und diese beginnt nicht mit Abnahme, sondern nach den allgemeinen Regeln. Dieses Ergebnis erscheint dann nicht umgehbar, v.a. nicht i.v.m. OLG München. Für Pflegeverträge, die bei Systemverträgen die Standardsoftware gegen Pauschale und die angepassten Teile gegen Aufwand (oder auch gegen Pauschale) zum Gegenstand haben, wird noch fragwürdiger, ab wann eine Vergütung bzw. die volle Vergütung verlangt werden kann. These 2: Die "modernen" Vorgehensmodelle unterlaufen/konterkarieren die Argumentationsbemühungen für eine Rechtfertigung der Anwendung von 631 ff. unter Hinweis auf den (hohen) und damit auch separierbaren bzw. darleg- und beweisbaren Planungsanteil. Die Frage ist, was überhaupt von diesem Planungsanteil bleibt. These 3: Die Verneinung der Sachqualität ist nicht europarechtskonform und schafft zusätzliche Probleme bei Lizenz, weil Mietrecht nicht anwendbar ist. 3

4 I. Moderne Projektmethoden 1 1. Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value 2 : 1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more. 2. Principles behind the Agile Manifesto We follow these principles 3 : 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 1 Aus Skript des Autors für Tagung Kölner Tage 2010; übrige Abschnitte z.t. Erweiterung Vortrag Kölner Tage Typo und Absatz-Anordnung geändert, Nr. und Hervorhebungen hinzugefügt. 3 Typo und Absatz-Anordnung geändert, Nr. und Hervorhebungen hinzugefügt 4

5 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Xtreme Programming Ruby on rails u.ä. 3. SCRUM Scrum (engl. für Gedränge) ist ein Vorgehensmodell mit - Meetings, - Artefakten, - Rollen, - Werten und - Grundüberzeugungen, das beim Entwickeln von Produkten im Rahmen agiler Softwareentwicklung hilfreich ist. Teammitglieder organisieren ihre Arbeit weitgehend selbst und wählen auch die eingesetzten Software-Entwicklungswerkzeuge und -Methoden Oder: 5 Scrum is an iterative, incremental framework for developing any product or managing any work. It allows teams to deliver a potentially shippable set of functionality every iteration, providing the agility needed to respond to rapidly changing requirements. The Scrum framework constantly challenges its users to focus on improvement, and its sprints provide the stability to address the ever-changing needs that occur in any project. These characteristics have led to Scrum becoming the most popular method in the world of agile software development. Rollen: - Product Owner - Team - Scrum Master - Zusammenspiel - Zertifizierung Artefakte: 4 ; s.a. 5 s.a. Auer-Reinsdorff, ITRB 2010, i.e., 5

6 - Product Backlog - Sprint Backlog - Burndown Chart, (täglich) aktualisiert der je Sprint noch zu erbringende Aufwand - Impediment Backlog Zyklusmodell - Sprint Umsetzung eines Iterationsschritts - Review - Retrospektive Der Prozess: - Product Backlog (Produktanforderung des Kunden > - Sprint backlog > - Sprint > - Working Increment. 4. Prototyping Die typischen moderneren Projektmethoden, charakterisiert etwa als Agile Programming oder Extreme Programming haben als eine Art Vorläufer das Prototyping. 6 Das Interessante dabei ist und damit auch das Vergleichbare mit den moderneren Methoden, dass dem Kunden in einem relativ frühen Stadium ein in bestimmten Kernfunktionalitäten bereits vorhandenes Programm gezeigt werden kann, auch wenn das Programm vielleicht noch nicht alle Funktionen aufweist, die es später, möglicherweise auch auf den Kunden zugeschnitten, benötigt und aufweisen soll. Allerdings gibt es wohl auch Prototypen, die die Funktionalität noch nicht echt aufweisen, die also auch noch nicht mit z.b. Vorführdaten arbeiten können, hier handelt es sich dann um einen sogenannten Demonstrationsprototypen. 7 Arten von Softwareprototypen: - Demonstrationsprototyp - Prototyp im engeren Sinne - Prototyp als Entwurfsmuster - Horizontaler Prototyp - Vertikaler Prototyp Arten des Prototyping: - Exploratives Prototyping - Evolutionäres Prototyping - Experimentelles Prototyping - Rapid Controll Prototyping - Vertikales Prototyping - Horizontales Prototyping 6 S. z.b: Söbbing, ITRB 2008, 145; Müller-Hengstenberg/Kirn, CR 2010, 8. 7 S. zu den Arten von Prototypen bei Software und überhaupt zu Arten des Prototyping: Müller- Hengstenberg/Kirn, CR 2010, 8 und 9. 6

7 Das Prototyping ist insofern für die hier zu behandelnden Fragen von Interesse, als die Folgend der neuen Projektmethoden bezüglich Dokumentation, spiralförmigen Vorgehens u.ä. vergleichbar sind, während die Voraussetzungen durchaus verschieden sind, indem nämlich beim Prototyp etwas im Kern funktionsfähiges vorliegt, zumindest vorliegen sollte. 5. V-Modell Das V-Modell XT ist seit dem 1. Februar 2009 in der Version 1.3 erhältlich. Das V- Modell XT hat seit dem letzten Release nur wenige inhaltliche Änderungen erfahren, darunter die maßgebliche Überarbeitung des Vorgehensbausteins zur Systemsicherheit. Das V-Modell XT orientiert sich nun stärker an den Empfehlungen des Bundesamtes für Sicherheit in der Informationstechnik (BSI). Darüber hinaus ist jedoch viel 'unter der Haube' geschehen. Die Werkzeugunterstützung durch den Projektassistenten wurde in vielerlei Hinsicht überarbeitet, um eine bessere Tailorbarkeit und Planbarkeit zu erreichen. Die beliebten Export-Funktionen wurden um weitere Dateiformate erweitert: DOC und ODT für Produktvorlagen, MS Project XML für Pläne. Für den Anwender unsichtbar wurde ein Variantenkonzept realisiert, mit dem Anpassungen des Vorgehensmodells an organisationsspezifische Besonderheiten werkzeuggestützt durchgeführt werden können. Zum V-Modell und dessen Struktur: 7

8 II. Typische Merkmale moderner Projektmethodik, v.a. bei Extreme Programming 1. Versuch Schema zu Extreme Programming Zu den Zielen von Agile Programming: Manifesto for Agile Software Development und Principles behind the Agile Manifesto 8, s. oben Zitat Es folgt der Versuch einer Zusammenfassung der Charakteristika moderner Projektmethoden und ihrer Wirkung im Verbund mit Stichworten zur vertragsrechtlichen Beurteilung, orientiert an Extreme Programming: Sarre/Schmidt 9 Charakteristika 1. Die Funktionalität des Systems wird in Users Stories 10 zusammengefasst (GUI, Funktionalitäten, Testfälle und - szenarien), = lfd. Grobspezifikation Wünschdirwas + Redaktion 2. SW-Qualität Qualitätssicherung, 2.a Jeweils zwei Entwickler programmieren gemeinsam ( programming in pairs ) 2.b Gemeinsamer Code- Besitz (collective code ownership) 2.c Ständige Refaktorisierung Bisherige Institution Pflichtenheft entfällt als corpus mit einheitlichem Versionsstand der Feinspezifikation, das Vorgehen ähnelt aber Zurufprojekt und Fall mit fehlendem Pflichtenheft Sache des Auftragnehmers Dienstvertrag aufgrund gemeinsamer Entwicklung der Vorgaben und der Ergebnisse? 15 Quellcode für AG? Urteile BGH zum mittleren Ausführungsstandard 11 und zur Ausführungsart 12, Mittlerer Ausführungsstandard 14 Absicherung, v.a. wenn 2. Entwickler Mitarbeiter des AG ist. BGH v zu Umständen einer Herausgabepflicht Anm./Fragen Worauf beruht Kalkulation? 13 Initial GUI als Oberflächenbeschreibung, Funktionalitäten, Testszenarien, laufender Verfeinerung erst später In klassischen Verträgen im Vertrag nicht geregelt, wird erst bei Abnahme (frühestens) geprüft Nutzungsrechte stehen beiden Vertragspartner (gemeinsam) zu. 16 Wenn nicht beide Vertragspartner ein Exemplar des Code haben, sollte er zu Gunsten beider, also 2- fach, hinterlegt werden Qualitätssicherung, Konfigurationsfähig 8 vom Verfasser auch auf Kölner Tagen 2010 angesprochen, ebenso das folgende Schema 9 Linke Spalte stammt ohne Verweise - aus Vortrag Sarre/Schmidt, Folie 8: Wesentliche Merkmale, Habel IT- Gesprächskreis, München , erweitert für Tagung Kölner Tage S. z.b. Mike Cohn, User Stories Applied: For Agile Software Development, BGH v X ZR 129/01, CR 2004, S. oben BGH v X ZR 167/04, 13 Wichtig für Risikoverteilung bei Änderung der Ausführungsart, s. BGH v , NJW 1998, BGH X ZR 129/01, CR 2004, S. eher abl. Schneider Handbuch des EDV-Rechts, 4. Aufl. 2009, H. Rz. 7 f. 16 S. a. zum Problem OLG Frankfurt v , CR 2003, 50. 8

9 2.d (continuous refactoring) 17 Schnelle Code- Reviews (rapid code reviews) 3. Vor der Entwicklung werden (automatisierbare) Tests erstellt, > Nr. 1 = Teil der Vorgaben, es wird festgelegt, wie getestet wird, ermöglicht, dass sich die Entw. der Testfälle bedienen können Bisher Tests nachträglich proof of...? mit Ausstiegsszenari en und Anschärfen der Folgen je nach absolvierter Phase Vor Abnahme ist Auftragnehmer für Mangelfreiheit verantwortlich und Beweis-belastet, evtl. >>>Machbarkeit und >>Zwischenabnahme, Freigabe für weiteres Vorgehen? -keit wird verbessert Aktuelle Berücksichtigung von Korrektur- Bedarf 4. Auf unnötige Features wird verzichtet (YAGNI - you aren t gonna need it) 5. Kunde ist bei der gesamten Entwicklung dabei ( on-site customer ), 6. Extrem kurze Zyklen für ( Schraube ) Anforderungsanalys e, Design, Implementierung und Test. Das Ergebnis pro Zyklus ist immer ein lauffähiges Programm ( small releases ). 7. Insgesamt entsteht keine oder nur sehr wenig Dokumentation seitens AN CR - Management Realisierung ist Sache des AN, AG ist nicht verpflichtet, die Ausführungsart des AN zu prüfen (BGH v X ZR 167/04, s.a. BGH zu Funktionsmangel Keine Pflicht des AN zu prüfung der Ausführungsart und zu Teilabnahmen Bedienungs- Handbücher (+Installationsanl eitung) OLG Düsseldorf v , Gitteroste (Deltapflichtenheft reicht nicht); OLG Köln v , CR 1998, 459 proaktiver AN Mitwirkung als Hauptleistung?, Kooperationsvertrag Freigaben, Teilabnahmen, Gesamtabnahme BGH v OLG Karlsruhe v , CR 2002, 802; BGH v X ZR 9/99 8. Resumee /Frage BGH , BGH und BGH ,./. OLG München BGH , Mittlerer Ausführungsstanda rd revidieren, mehr auf Vertragszweck abstellen Wem gehören die Ergebnisse? Obwohl Planung verschwindet, passt 651 nicht (?). 17 S. z.b. Martin Fowler u.a., Refactoring: Improving the Design of Existing Code,

10 2. Projektverträge in der Rspr., BGB a.f. - Werkvertrag (Übersicht, Auflistung, BGB a.f., weggelassen) 3. Abgleich Projektvorgehensmodelle und Rspr. Positionen a) Planungsphase Der Schwerpunkt zumindest des Projektvertrages wird, auch wenn andere Leistungen hinzutreten, durch die Erstellung der Software geprägt. Der Vertrag enthält unter Umständen noch die Erstellung der fachlichen Vorgaben (Gewinnung des Pflichtenhefts ) und zerteilt sich insofern grob in die Phasen - Planung und - Realisierung. Das Argument für die Nichtanwendung ist gerade die beinhaltete, aber vor die Realisierung ( Herstellung ) geschaltete Planung. Im Hinblick auf 651 BGB wäre andererseits wichtig, den Hardwareanteil zu berücksichtigen bzw. ins Verhältnis zu setzen. Systemverträge müssten demnach eher nach Kaufrecht beurteilt werden. 18 Entsprechendes gilt für die Services, also Installation, Einrichten, Einführungsunterstützung usw., wenn sie nicht eigenständigen Charakter haben. b) Erfolgsverantwortung beim AN Die typische vertragstyplogische Einordnung des klassischen Projekts ist Werkvertrag und zwar wohl in der Regel ungeachtet der Anteile der Hardware. Als Erfolg wird die Erstellung des betriebsfertigen Systems ( schlüsselfertig ) gesehen. Die Projektverantwortung folgt selbstverständlich aus der Erfolgsverantwortung seitens des Auftragnehmers und somit verbleibt nur Mitwirkungsleistung des Auftraggebers. Ist der Erfolg nicht in einem Pflichtenheft definiert, gilt ein mittlerer Ausführungsstandard nach Stand der Technik und orientiert am Vertragszweck 19. c) Pflichtenheft Die Beibringung des Pflichtenhefts als fachliche Anforderungen ist Sache des Auftraggebers. Dies gehört zu seinen genuinen Mitwirkungspflichten. 20 Kann der Softwarehersteller die Verpflichtung zur Programmierung nur sinnvoll unter Mitwirkung des Kunden erfüllen, so besteht aus in der Natur der Sache liegenden 18 BGH v a.a.o., anders gerade die EVB-IT System. 19 BGH v X ZR 129/01, CR 2004, BGH v , CR 1989, 102 Registierkassen und BGH v , CR 1996, 467 Service-RZ II. 10

11 Gründen, auch ohne ausdrückliche Regelung, eine entsprechende Mitwirkungspflicht. 21 Unmittelbar auch heute noch passend für diese Entscheidung, v.a , hinsichtlich der Parametrierung, da es um das Ausfüllen von Programmblättern bzw. die Spezifikation von Warengruppe, Preis und einer Kurzbeschreibung der Ware ging. Man könnte dies auf heutige Verhältnisse also als Kurzbeschreibung des Produkts bzw. des Geschäftsprozesses ansehen. Gemäß diesen Entscheidungen bedarf es nicht einmal einer expliziten Regelung der Mitwirkungspflichten im Vertrag, obwohl dies sicher empfehlenswert ist (auch im Rahmen des Aktivitäten- und Fristenplans). d) Dokumentation(en) Möglicher Umfang, Katalog der Dokumenationen- Anwenderdokumentation (nur dazu hat der BGH entschieden). - Installationsbeschreibung (ergibt sich aus den BGH-E.) - Administratoranweisungen - Quellcode mit Programmbeschreibung + Kommentierung - Beschreibung der Entwicklungsumgebung, evtl. die Entwicklungsumgebung selbst, - Entwicklungsdokumentation, stand aller Einstellungen / Parameter bei Übergabe/Ablieferung/Abnahme - Die bei Generierung/Kompilierung entstandenen Ergebnisse sowohl in Text als auch in elektronischer Form - Geschäftsmodell, Datenreferenzen, Datenmodell, - Wartungs- oder Pflege-Dokumentation. Zur systematisch geführten Softwareentwicklungsdokumentation gehören 22 : - Fachkonzept, - DV-Feinspezifikation, - Quellprogramme mit zugehöriger Dokumentation, - Datenbank-Modelle - Beschreibung der Testverfahren, - Testdokumentation, - Beschreibung der Abnahmeverfahren, - Abnahmeprotokolle, - Softwaredokumentation (System- und Anwenderhandbuch), - Darstellung des Vorgehensmodells bei der Entwicklung, - Dokumentation der Entwicklungsumgebung. 23 Die modernen Projektmethoden sind auch dadurch gekennzeichnet, dass es zumindest nach Auffassung der Anbieter - entweder keine Dokumentation gibt, oder - die "Dokumentation" vom Anwender selbst (mit-) erstellt wird (s.a. II.1). Sehr wohl kann sich aber aus dem Vertrag anderes ergeben. 21 BGH v , CR 1989, 102, 104 (LS 2) Registrierkassen und Bestätigung durch BGH v , CR 1998, 393, 395 Warentermingeschäft. 22 Hoppen/Hoppen, Bewertung und Bilanzierung selbst erstellter Software, CR 2009, 761, 766 mit Auflistung was zur Softwareentwicklungsdokumentation gehört. 23 Zusätzlich nennen Hoppen/Hoppen, CR 2009, 761, noch, aber wichtig wohl nur für die Bewertung: Aufstellung der beteiligten Mitarbeiter mit Aufgaben und angefallenem Entwicklungsaufwand. 11

12 Anm./These: Stories, Cases sind zwar Anforderungen/Forderungen, jedoch kein Pflichtenheft, auch keine Bestandteile, wenn sie nicht über die zuständigen Instanzen aufgegriffen und in den Design-/Entwicklungsprozess integriert werden; sie taugen auch später nicht als Basis für die Dokumentation, wenn sie nicht systematisch aufbereitet und bearbeitet werden. Sie können aber zur näher zu konkretisierenden Leistungsbeschreibung, auch für Tests dienen. Die Relevanz ergibt sich aus vertraglichen Regelungen. Die Möglichkeit der Erstellung durch den Anwender erscheint hinsichtlich der Entwicklungsdokumentation äußerst fraglich. Des weiteren wird angenommen, jedenfalls von vielen Auftragnehmern, dass die Bedienungsanleitung Bestandteil der Software selbst wäre und zwar über die Onlinehilfe. Dies ist zwar insofern richtig, als es Tendenzen gibt, große Teile dessen, was früher in der Bedienungsanleitung stand, in die Onlinehilfen zu verlagern. Dies enthebt jedoch nicht insgesamt der Notwendigkeit einer Benutzerdokumentation zumindest in einer grundsätzlichen Darstellungsform. Dabei ist wenig relevant, ob es sich um eine ausdruckbare oder ausgedruckte Fassung handelt. Vielmehr ist zu beachten, dass mindestens die Installationsanleitung und ein gewisser Kern von Anweisungen in schriftlicher Form so vorliegt, dass der Kunde damit auch dann umgehen kann, wenn er evtl. erneut die Software zu installieren bzw. zum Anlaufen zu bringen hat bzw. wenn er sich selbst ansonsten helfen soll. Im klassischen Projekt ist eine in der Praxis häufig diskutierte Frage, die aber selten (offensichtlich) zu Gericht kommt, wie genau die Dokumentation auszusehen hat und wann sie im einzelnen zu erstellen ist. Hypothese: Ist die Frequenz der Änderungsverlangen nicht hoch und sind die Änderungsverlangen nicht gravierend, dürfte ökonomisch gesehen eine projektsynchrone bzw. leicht zeitversetzte Erstellung der Entwicklungsdokumentation einschließlich auch der Anwendungsdokumentation einfacher und damit kostengünstiger sein. Bei höherer Änderungsrate und bei tiefergreifenden Änderungen dürfte eine Erstellung der Dokumentation im nachhinein die kostengünstigere sei. Der BGH hat diese Überlegungen nicht so angestellt, aber vielleicht indirekt berücksichtigt. Jedenfalls gehört zum typischen Projekt zum einen eine gewisse Änderungsrate und zum anderen ist die Dokumentation erst fällig, wenn nach einer angemessenen Frist (die bei einer evtl. Fristsetzung nach altem Recht im Rahmen von 326 zu berücksichtigen war) nach Ende der Fertigstellung incl. der Abarbeitung der Änderungsverlangen der Auftragnehmer noch genügend Zeit hat, die Dokumentation zu erstellen. Daraus ließe sich auch ein Modell rekonstruieren, wie ein Zeitplan für einen Projektvertrag aussehen könnte, in dem es einen Zeitpunkt gibt, der als relativer Termin das Ende der Änderungswünsche und deren Realisierung markiert, ab dem dann die vereinbarte Frist für die Erstellung der Dokumentation läuft. Diese Frist müsste evtl. noch angepasst werden, wenn durch die Änderungswünsche ein erheblicher Mehraufwand auch bei der Dokumentation (wegen Erweiterung der Funktionalitäten usw.) entstehen würde. Der Katalog der Dokumentationen ist offen. Im juristischen Bereich hat allerdings bislang v.a. die Anwendungsdokumentation und allenfalls die Installationsanleitung 12

13 eine Rolle gespielt. Die weiteren Dokumentationen wären und sind wohl im wesentlichen Vereinbarungssache: e) Änderungen, Üblichkeit und Häufigkeit In mehreren Entscheidungen hat der BGH sinngemäß die Üblichkeit von Änderungsverlangen und deren Ausführung festgestellt. 24 Der Projektunternehmer hat für eine der vertragsgemäßen Software angepasste Auslegung der Hardware einzustehen (also veraltet), muss dabei auch in gewissem Umfang möglichen nachträglichen Änderungen und Ausweitungen der Programme Rechnung tragen. Die Grenze des gewissen Umfangs bemisst sich nach den zu erwartenden Mehrkosten, den Umfang, den Zeitpunkt und der Wahrscheinlichkeit einer Programmerweiterung sowie den Möglichkeiten und Schwierigkeiten einer späteren Erweiterung. 25 LS 3 Indirekt bestätigt auch die Entscheidung vom die Üblichkeit von Änderungsverlangen und deren Ausführung (im Hinblick auf die Fälligkeit der Software-Dokumentation besonders relevant). 26 f) Zur Abnahme Typisch für Projekte ist, dass der Abnahmeerklärung eine ausführliche Erprobung zwecks Feststellung der Abnahmefähigkeit vorausgeht. Ausführliche Verträge regeln in einer Reihe von Phasen den schrittweisen Übergang bis hin zum Probebetrieb als Abnahmetest einschließlich einer gewissen fehlerfreien Zeit. Soweit schon vorher Abnahmen vorgesehen sind, wird in der Regel eine Gesamtabnahme vereinbart, die möglicherweise einen eingeschränkten Gegenstand hat, etwa noch Performance, während die Funktionalität der einzelnen Module bereits vorher getestet wäre, nun aber noch die Gesamtfunktionalität ansteht, also die Interoperabilität innerhalb des Systems u.ä.. Als typisch für die Verbindung mit Outsourcing bzw. überhaupt für Outsourcingverträge ist die Regelung auch der Phase nach der Abnahme, etwa im Sinne einer Anlauf-/Einarbeitungsphase incl. Einschwingen hinsichtlich der Skills auf Seiten des Auftragnehmers. Dies gilt insbesondere, wenn nicht das selbe Personal, das das Projekt betrieben hat, für den Betrieb verantwortlich wird. g) Rechtzeitiger Abruf als Voraussetzung für Mitwirkungsverzug Wie erwähnt, ist der Auftraggeber generell zur Mitwirkung verpflichtet, auch wenn keine besonderen Regelungen hierfür im Vertrag zu finden sind. Allerdings empfiehlt es sich natürlich, diese Mitwirkung im einzelnen zu regeln. Dies betrifft z.b. auch den Bereich der Abnahme, also, wer der Testsystem stellt, wann die Testcases/Szenarien zu liefern sind, welche Verbindlichkeit diese bzw. die Ergebnisse haben u.ä. Evtl. enthält der Vertrag noch Regelungen, dass die Mitwirkung rechtzeitig abzurufen ist. Damit ist die Schwäche der gesetzlichen 24 S. als Beispiel zu kurzer Fristsetzung i.v.m. den Änderungs- und Ergänzungsarbeiten BGH v X ZR 92/90, CR 1993, 424. Noch deutlicher: BGH v X ZR 16/85, CR 1986, 977 Reservekapazität im Hardware-Mengengerüst (soweit auf Hardware bezogen wohl veraltet). 25 BGH v X ZR 16/85, CR 1986, 977, LS 3 26 BGH v X ZR 9/99, CR 2001,

14 Regelung der Mitwirkung nicht kompensiert, dass es sich insoweit nicht um Hauptpflichten handelt. Dies dürfte sich auch nach Schuldrechtsmodernisierung nicht anders darstellen. Umso wichtiger wäre die exakte Regelung möglichst vieler Mitwirkungspflichten im Rahmen des Aktivitäten- und Fristenplans. III. BGH intervenierende Variable über 651 BGB? 1. BGH v Silowände BGH, Urteil vom 23. Juli VII ZR 151/08 - OLG Nürnberg LG Weiden i.d. OPf. a) Kaufrecht ist auf sämtliche Verträge mit einer Verpflichtung zur Lieferung herzustellender oder zu erzeugender beweglicher Sachen anzuwenden, also auch auf Verträge zwischen Unternehmern. b) Verträge, die allein die Lieferung von herzustellenden beweglichen Bau- oder Anlagenteilen zum Gegenstand haben, sind nach Maßgabe des 651 BGB nach Kaufrecht zu beurteilen. Die Zweckbestimmung der Teile, in Bauwerke eingebaut zu werden, rechtfertigt keine andere Beurteilung. c) Eine andere Beurteilung ist auch dann nicht gerechtfertigt, wenn Gegenstand des Vertrages auch Planungsleistungen sind, die der Herstellung der Bau- und Anlagenteile vorauszugehen haben und nicht den Schwerpunkt des Vertrages bilden. Rz. 16 c) Allerdings hat die Anknüpfung an den Begriff der beweglichen Sache in der Literatur erhebliche Kritik erfahren, soweit sie sich auf Verträge im Zusammenhang mit der Errichtung von Bauwerken auswirkt... Diese Kritik vermag nichts daran zu ändern, dass der Wille des Gesetzgebers eindeutig dahin geht, diejenigen Werklieferungsverträge, die nach altem Recht noch dem Werkvertragsrecht unterstellt waren, nunmehr als Kaufverträge einzuordnen, was auch mit einer Angleichung an das UN-Kaufrecht begründet worden ist (BT- Drucks. 14/6040, S. 268). Dieser Wille ist durch die unmissverständliche Formulierung des Gesetzes ausreichend zum Ausdruck gekommen. Das Gesetz kann nicht unter Hinweis darauf umgangen werden, dass die alte Rechtslage vermeintlich zu angemessenen Ergebnissen geführt hat (so auch Messerschmidt/Voit- Messerschmidt/Leidig, aao, Rdn. 28). Rz. 17 Zu Recht wird darauf hingewiesen, dass die von der Literatur angeführten Wertungswidersprüche systematisch in der Regelung des 651 Satz 1 BGB angelegt sind (Rudolph, aao). Es mag als Wertungswiderspruch empfunden werden, dass ein Vertrag mit demjenigen, der die Errichtung des Bauwerks schuldet und dazu die Bauteile herstellt und anliefert, nach Werkvertragsrecht zu beurteilen ist, während ein Vertrag mit demjenigen, der die Bauteile herstellt und lediglich anliefert, grundsätzlich nach Kaufrecht zu beurteilen ist. Dieser vermeintliche Wertungswiderspruch ist jedoch allgemein in 651 BGB angelegt, weil die Anwendung von Kaufrecht auf im Kern erfolgsbezogene Verträge angeordnet und vom Gesetzgeber in der Meinung akzeptiert worden ist, Kauf- und Werkvertragsrecht unterschieden sich nicht wesentlich. Das... Rz Dem Gesetz kann keine Beschränkung derart entnommen werden, dass lediglich Verträge über die Lieferung von typischen Massengütern oder zum Verbrauch bestimmten Gütern erfasst sein sollten (so aber Erman/Schwenker, BGB, 12. Aufl., 651 Rdn. 5). Der Wortlaut des 651 BGB und die dargestell-ten Motive geben dafür nichts her. Die Beschränkung lässt sich auch nicht aus einer autonomen Auslegung der Verbrauchsgüterkaufrichtlinie entnehmen, die für die Auslegung des Gesetzes bei einer Lieferung an einen Verbraucher zu berücksichtigen wäre. Die Verbrauchsgüterkaufrichtlinie findet allerdings nur auf Verträge Anwendung, die die Lieferung herzustellender oder zu erzeugender Verbrauchsgüter an Verbraucher zum Gegenstand haben. Daraus ergibt sich jedoch ausweislich der Richtlinie keine Einschränkung der dargestellten Art. Denn Verbrauchsgüter sind gemäß Art. 1 Abs. 2 lit. b) der Richtlinie bewegliche körperliche Gegenstände mit Ausnahme der dort benannten 14

15 Gegenstände. Eine weitere Einschränkung enthält die Legaldefinition der Richtlinie nicht. Sie ergibt sich auch nicht aus dem Verfahren zur Richtlinie (vgl. Rudolph, aao, S. 67). Insbesondere liegt kein Anhaltspunkt dafür vor, dass die schwierige Abgren-zung von typischen Massengeschäften oder zum Verbrauch bestimmten Gütern von anderen Gütern in irgendeiner Weise durch die Richtlinie eröffnet sein soll- 21 Von dem Anwendungsbereich des Werkvertragsrechts erfasst bleiben damit ausweislich der Begründung zum Entwurf des Gesetzes zur Modernisierung des Schuldrechts im Wesentlichen die Herstellung von Bauwerken, reine Reparaturarbeiten und die Herstellung nicht-körperlicher Werke, wie zum Beispiel die Planung von Architekten oder die Erstellung von Gutachten (BT-Drucks. 14/6040, S. 268). b) Das alles stellt das Berufungsgericht nicht in Frage. Es meint vielmehr auf der Grundlage einer in der Literatur vertretenen Meinung zur Einordnung von Verträgen zwischen Unternehmern über die Lieferung eines herzustellen-den typischen Investitionsgutes Werkvertragsrecht anwenden zu müssen. In der Literatur wird geltend gemacht, 651 BGB sei nicht anzuwenden, wenn der Vertrag zwischen Unternehmern über die Lieferung eines herzustellenden typi-schen Investitionsgutes andere zusätzliche wesentliche Leistungen enthalte, zu denen etwa Planungs-, Konstruktions-, Integrationsund Anpassungsleistungen gezählt werden. Dabei sind vor allem Leistungen im Zusammenhang mit der Lieferung von in den Produktionsprozess einzupassenden Maschinen oder Industrieanlagen oder Projektverträge im Mittelpunkt der Diskussion (vgl. Leistner, JA 2007, 81, 88; Metzger, AcP 204 (2004), 231, 232 f.; Schumann, ZGS 2005, 250; Bamberger/Roth/Voit, BGB, 2. Aufl., 651 Rdn. 12; Lapp in jurispk-bgb, 3. Aufl., 651 Rdn. 1). Seien diese Leistungen für den Gesamterfolg des Vertrages von wesentlicher Bedeutung, bildeten sie den Schwerpunkt des Vertrages (MünchKomm- Busche, BGB, 5. Aufl., 651 Rdn. 31) oder gäben ihm das Gepräge (Palandt/Sprau, BGB, 68. Aufl., 651 Rdn. 4), so sei Werk-vertragsrecht anwendbar. Werkvertragsrecht sei auch dann anwendbar, wenn ein Prototyp einer Maschine entwickelt werde, weil die dafür erforderliche geistige Leistung den Schwerpunkt des Vertrages bilde, während die Maschine selbst nur das Substrat dieser Leistung sei (Staudinger/Peters/Jacoby (2008), 651 Rdn. 8, 16; Palandt/Sprau, aao). 23 b) Der Senat muss nicht entscheiden, ob in den dargestellten Fällen 651 BGB nicht anwendbar ist. Denn ein solcher Fall liegt entgegen der Auffassung des Berufungsgerichts nicht vor. 24 Allerdings geht auch der Senat davon aus, dass die Beklagte im vom Berufungsgericht festgestellten Umfang Planungsleistungen übernommen hat. Die dagegen gerichteten Verfahrensrügen der Klägerin hat er geprüft, jedoch nicht für durchgreifend erachtet, 564 Satz 1 ZPO. 25 Jedoch sind die Leistungen der Beklagten nicht von solchem Gewicht, dass die Anwendung des Werkvertragsrechts gerechtfertigt wäre. Das Berufungsgericht verkennt die Bedeutung der Planungsleistung im Anwendungsbereich des 651 BGB. Danach können solche Planungsleistungen, die als Vor stufe zu der im Mittelpunkt des Vertrages stehenden Lieferung herzustellender Anlagenteile anzusehen sind, der Beurteilung des Vertrages nach den Vorschriften über den Kauf regelmäßig nicht entgegenstehen. Wäre es anders, würde die Vorschrift des 651 BGB weitgehend leer laufen, denn jeder Herstellung geht eine gewisse Planungsleistung voraus (Messerschmidt/Voit-Messerschmidt/Leidig, aao, 651 Rdn. 49; Motzke, in Bauträger-, Bau- und Maklervertrag in der Praxis der Wohnungsunternehmen und Immobilienverwaltungen, S. 22). Eine Ausnahme kann deshalb allenfalls dann gelten, wenn die Planungsleistung so dominiert, dass sie den Schwerpunkt des Vertrages bildet und deshalb die Anwendung des Werkvertragsrechts erfordert. Das kann z.b. dann der Fall sein, wenn es bei der Beauftragung im Wesentlichen um die allgemein planerische Lösung eines konstruktiven Problems geht. Für IT-Rechts-Zwecke relevant sind die Aussagen zu a) Generelle Anwendung 651 BGB, auch B:B. b) Keine teleologische Begrenzung bzw. Auslegung. c) Beachtlichkeit des Planungsanteils 27. Allerdings genügt nicht, dass der Unternehmer als Vorstufe planerisch tätig wird: Danach können solche Planungsleistungen, die als Vorstufe zu der im Mittelpunkt des Vertrages stehenden Lieferung herzustellender Anlagenteile anzusehen sind, der Beurteilung 27 Wobei noch zusätzlich zu berücksichtigen wäre: BGH v III ZR 93/09 Video-Partnerportal (dort Hauptleistung Betrieb) zur Beurteilung gemischter Verträge. S. aber eher noch restriktiver zur Relevanz des Planungsanteils: BGH , sogleich. 15

16 des Vertrages nach den Vorschriften über den Kauf regelmäßig nicht entgegenstehen. Wäre es anders, würde die Vorschrift des 651 BGB weitgehend leer laufen, denn jeder Herstellung geht eine gewisse Planungsleistung voraus... (mwn)., Rz BGH v Tiefladesattelaufleger BGH v X ZR 82/07 - Tiefladesattelauflieger Leitsatze Stephan Lorenz: a) Kaufrecht ist auf sämtliche Verträge mit einer Verpflichtung zur Lieferung herzustellender oder zu erzeugender beweglicher Sachen anzuwenden, auch wenn mit der Herstellung eine Planungsleistung verbunden ist (Bestätigung von BGH NJW 2009, 2877) b) 377 HGB ist auch auf Werklieferungsverträge anwendbar c) Die Beweislast für das Vorliegen einer Beschaffenheitsvereinbarung im Rahmen des subjektiven Fehlerbegriffs trägt der Käufer ( 434 I S. 1 BGB) Kommentar SL:... Kernaussage: Ein Vertrag über herzustellende Sachen ist nach 651 BGB auch dann dem Kaufrecht zugewiesen, wenn mit der Herstellung eine gewisse Planungs- und Konzeptionsarbeit verbunden ist. Argument: Der Herstellung von zu liefernden Sachen gehen typischerweise gewisse Planungsleistungen voraus und die Vorschrift des 651 BGB würde weitgehend leer laufen, wenn dieser Umstand dazu führte, statt Kaufrecht Werkvertragsrecht anzuwenden. Offen bleibt weiter, ob dann Werkvertrag anzunehmen ist, wenn die Planungsleistung überwiegt. BGH : Rz. 7 II. Das hält der rechtlichen Nachprüfung nicht stand. Rz a) Die Einordnung des geschlossenen Vertrages als Werkvertrag ist rechtsfehlerhaft. Nach 651 Satz 1 BGB finden auf einen Vertrag, der, wie hier, die Lieferung herzustellender oder zu erzeugender beweglicher Sachen zum Gegenstand hat, die Vorschriften über den Kauf Anwendung. Werkvertrags-rechtliche Bestimmungen treten nur ergänzend, und nicht verdrängend neben das Kaufrecht, wenn der Vertrag die Lieferung einer nicht vertretbaren Sache zum Gegenstand hat ( 651 Satz 3 BGB). Kaufrecht ist mithin auf sämtliche Verträge mit einer Verpflichtung zur Lieferung herzustellender oder zu erzeugender beweglicher Sachen anzuwenden (BGH, Urt. v VII ZR 151/08, zur Veröffentlichung in BGHZ vorgesehen, Tz. 19 unter Hinweis auf BT-Drucks. 14/6040, S. 268). Unerheblich für die vertragsrechtliche Einordnung ist entgegen der Auffassung des Berufungsgerichts deshalb, dass der Auflieger nach den konkreten Vorstellungen und Vorgaben der Klägerin habe hergestellt werden sollen. Das mag die Annahme rechtfertigen, der Vertrag habe die Lieferung einer nicht vertretbaren Sache zum Gegenstand gehabt. Dies ändert ausweislich der gesetzlichen Regelung in 651 Satz 3 BGB aber nichts an der grundsätzlichen Anwendbarkeit von Kaufrecht (vgl. insoweit auch BGH, aao Tz. 18 ff.). Rz. 9 b) Ob ausnahmsweise Werkvertragsrecht anwendbar sein könnte, wenn ein zwischen Unternehmen geschlossener Vertrag die Lieferung typischer Investitionsgüter, namentlich in den Produktionsprozess einzupassender Maschinen oder Investitionsanlagen, und im Zusammenhang damit die Erbringung zusätzlicher wesentlicher Planungs-, Konstruktions-, Integrations- und Anpassungsarbeiten zum Gegenstand hat, bedarf im Streitfall keiner Entscheidung (vgl. insoweit auch BGH, aao Tz. 22). Zwar kann davon ausgegangen werden, dass die Beklagte, um ihre Lieferungspflicht zu erfüllen, auch gewisse Planungs- oder Konstruktionsleistungen erbringen musste, worauf schon hindeutet, dass ihr vor Vertragsschluss die Dokumentation der Fräse W 1000 F übergeben wurde. Soweit in den Gründen des angefochtenen Urteils insoweit davon die Rede ist, der Beklagten sei die technische Dokumentation des herzustellenden Sattelaufliegers übergeben worden, handelt es sich ausweislich des Zusammenhangs der Entscheidungsgründe um ein Versehen. Bei den gegebenenfalls erbrachten Planungs- bzw. Konstruktionsleistungen kann es sich nach Lage des Streitfalls nur um solche gehandelt haben, die als Vorstufe zu der im Mittelpunkt des Vertrags stehenden Lieferung anzusehen sind. Der Herstellung von zu liefernden Sachen gehen typischerweise gewisse Planungsleistungen voraus und die Vorschrift des 651 BGB würde weitgehend leer laufen, wenn dieser Umstand dazu führte, statt Kaufrecht Werkvertragsrecht anzuwenden. 3. BGH v. 4. März III ZR 79/09 Web-Design-Vertrag 16

17 Rz. 16 Die Qualifizierung des "Internet-System-Vertrags" als Werkvertrag im Sinne der 631 ff BGB steht im Einklang mit der Rechtsprechung des Bundesgerichtshofs zur Zuordnung von Internet-Verträgen zu den Vertragstypen des Bürgerlichen Gesetzbuchs. Sie findet ihre maßgebliche Grundlage in dem von den Parteien vereinbarten Vertragszweck, wie er in der vertraglichen Leistungsbeschreibung und dem hieran anknüpfenden Parteiwillen, insbesondere auch in der verobjektivierten Kundenerwartung, zum Ausdruck kommt, und rechtfertigt sich letztlich auch aus einem Vergleich mit Verträgen, die ähnliche Gegenstände betreffen und als Werkverträge anerkannt sind. Rz. 21 (d) Im "Webdesign-Vertrag" verpflichtet sich der Anbieter, für den Kunden eine individuelle Website zu erstellen. Ein solcher Vertrag dürfte - ebenso wie ein Vertrag über die Erstellung oder Bearbeitung einer speziellen, auf die Bedürfnisse des Auftraggebers abgestimmten Software (s. BGHZ 102, 135, 140 f; BGH, Urteile vom 15. Mai X ZR 128/88 - NJW 1990, 3008, vom 3. November X ZR 83/90 - NJW 1993, 1063, vom 9. Oktober X ZR 58/00 - CR 2002, 93, 95 und vom 16. Dezember X ZR 129/01 - NJW-RR 2004, 782, 783) - regelmäßig als Werkvertrag im Sinne der 631 ff BGB, unter Umständen auch als Werklieferungsvertrag im Sinne von 651 BGB, anzusehen sein (s. dazu etwa Busche aao m.w.n.; Klett/Pohle aao S. 201; Redeker aao Rn. 980; Schneider, in: Handbuch des EDV-Rechts, 4. Aufl., Teil O Rz. 342 f = S. 2066; Schmidt, in: Spindler, Vertragsrecht der Internet-Provider, 2. Aufl., Teil VIII Rz. 4 = S. 659 ff; Cichon, Internet-Verträge, 2. Aufl., S. 117 ff; Härting, Internetrecht, 3. Aufl., Rn. 334 ff = S. 83 ff). Noch besonders zu erwähnen: RZ

18 IV. OLG München v gegen BGH; Literaturhinweise 1. OLG München v U 3515/09, CR 2010, 156 Ein Softwareentwicklungsvertrag ist Werkvertrag. Dies gilt auch dann, wenn ein Standardprogramm den individuellen Bedürfnissen des Anwenders angepasst wird (... MüKo BGB 5. Aufl. 631, Rdnr. 254 m.w.n.... Dem steht auch 651 BGB nicht entgegen. Selbst wenn man davon ausgeht, dass es sich bei dem Softwareprogramm um eine bewegliche Sache (Datenträger) handelt, besteht die eigentliche Leistung in der geistigen Schöpfung des Programms, und nicht in der Lieferung der herzustellenden beweglichen Sache. Darüber hinaus wurde die Individualsoftware per Datenfernübertragung übertragen, so dass auch von einer beweglichen Sache nicht ausgegangen werden kann.... Wie bereits ausgeführt, handelt es sich hier nicht um einen Kaufvertrag, sodass die Entscheidung des BGH vom (NJW 2009, 2877, Silowände) nicht einschlägig und vergleichbar ist. 2. Lit. Stellen zu Projektvertrag und Palandt/Sprau, 69. Aufl., 651 BGB Rz. 4 negiert trotz Zitat der E. deren Aussagen weitgehend: Ein Werkvertrag fällt nicht unter 651, wenn die Schöpfung eines Gesamterfolges den Schwerpunkt... bildet. Palandt/Sprau, 69. Aufl., Rz. 22 vor 631 BGB: Programmierleistungen sind in der Regel Werkleistungen ist in diesen Fällen mangels Sacheigenschaft der Leistung nicht anwendbar. - Anmerkung Schweinoch zu BGH v , CR 2009, 637, 640; - Schweinoch, Geänderte Vertragstypen in Softwareprojekten, CR 2010, 1. - Anmerkung Hoffmann zu BGH vom in MMR 2009, - Witte, Agiles Programmieren und 651 BGB, ITRB 2010, 44; - Maume/Wilser, Viel Lärm um nichts? Zur Anwendung des 651 BGB auf IT- Verträge, CR 2010, Mankowski, CR 2010, 137 zu OLG München, Internationale Zuständigkeit, S. 138: - Ob ein Softwareentwicklungsvertrag unter deutschem Recht ein Werkvertrag wäre, spielt für die europäische Einordnung keinerlei Rolle. Und Fn. 9: Dies übersieht OLG München. - BGH v III ZR 79/09 Rz. 21 (d) Im "Webdesign-Vertrag"..., s. oben 18

19 V. Argumentationen gegen 651-Anwendung aus den BGH-Urteilen 1. Argumentations-Ansatz aus : Rz Verträge, die allein die Lieferung von herzustellenden Bau- oder Anlagenteilen zum Gegenstand haben, sind gemäß 651 BGB nach Kaufrecht zu beurteilen (Dauner-Lieb/Langen- Raab, Schuldrecht Teilband 2, 651 Rdn. 14; Messerschmidt/Voit-Messerschmidt/Leidig, Privates Baurecht, 651 Rdn. 28; Leupertz, BauR 2006, 1648 f.; Voit, BauR 2009, 369, 370). Inwieweit etwas anderes gilt, wenn der Lieferant eine Verpflichtung zum Einbau der Teile in ein Bauwerk eingegangen ist oder die Teile selbst nach den von der Rechtsprechung aufgestellten Kriterien als Bauwerk zu beurteilen sind, ist hier nicht zu klären. Rz. 17 (oben) Es mag als Wertungswiderspruch empfunden werden, dass ein Vertrag mit demjenigen, der die Errichtung des Bauwerks schuldet und dazu die Bauteile herstellt und anliefert, nach Werkvertragsrecht zu beurteilen ist, während ein Vertrag mit demjenigen, der die Bauteile herstellt und lediglich anliefert, grundsätzlich nach Kaufrecht zu beurteilen ist. Wie ist der Unterschied richtig auf Software und Systeme zu übertragen? 2. Argumentations-Ansatz aus Werkvertrag, wenn Planungsleistung überwiegt. Die Ausnahme wäre Werkvertrag, die Regel Kaufrecht. Für die Ausnahme offen gelassen -, s. Rz. 9 oben, käme es darauf an ob zusätzlich wesentliche Planungs-, Konstruktions-, Integrations- und Anpassungsarbeiten zum Gegenstand gehören. Individual- Software zu schaffen oder Standardsoftware anzupassen und zu implementieren, könnte dem Umstand entsprechen, namentlich in den Produktionsprozess einzupassender Maschinen oder Investitionsanlagen, und im Zusammenhang damit die Erbringung zusätzlicher wesentlicher Planungs-, Konstruktions-, Integrations- und Anpassungsarbeiten. 3. Argumentations-Ansatz aus ! Rz 21: Unter Umständen >>> 651 und Kauf, regelmäßig... Werkvertrag. Es ist zwar unklar, wie das regelmäßig, also die Regel und somit die Umstände als Ausnahme hergeleitet und begründet werden können. Immerhin wird ein Regel- /Ausnahmeverhältnis angenommen. Hoeren sieht dies als Zurückrudern des III. Senats gegenüber dem VII (Silowände) (Beck-blog.de v ). Die E. v ist vom regel- /Ausnahmeverhältnis diametral (?) entgegengesetzt. VI. Was ändert sich für die Diskussion um 651 Anwendung im Hinblick auf neue Methoden? 1. Diskussion Software und Sachqualität Sachdiskussion bei Software unter evtl. Aufschlüsselung - Softwareerstellung Standardsoftware - Softwareerstellung Individualsoftware - Anpassung beim Kunden vorhandener Software - Anpassung beim Kunden vorhandener Software - Systemvertrag, Exkurs zu EVB-IT System und Systemlieferung 19

20 Ungelöst: Verjährung, wenn (zwecks Vermeidung der anwendung des 651) Sachqualität abgelehnt wird. 2. Thesen: - Iteration und Spirale, erst recht Scrum mit einzelner Mini-Planung lassen eigenes erhebliches Gewicht der Planung (allein) durch AN vermissen. - Das Ganze (Projekt) als Planung erscheint auch im Hinblick auf Ziele (Manifesto) und Vorgaben abwegig. - Teleologische Reduktion/Auslegung geht nicht (mehr). VII. Lösung: Planungsanteil, Gemischter Vertrag 1. Zwischenüberlegung - Somit also erfolgt Anwendung von Kaufrecht auf IT-Realisierungs-Projekte? - aber nicht auf gesondert beauftragte - Planung/Erstellung Pflichtenheft, Projektleitung 28. Was aber bewirkt ein Planungsanteil beim Erstellungs- und Anpassungsvertrag? 29 - Bei Spiralförmigem vorgehen, Iterations-Mini-schritten, Scrum, Koop. u.ä. Momenten verliert sich die Möglichkeit der Trennung. - Mankowski 30, Europa-Rechts-konforme Auslegung lässt Sachdiskussion praktisch leerlaufen. 2. Gemischte Verträge, Auswirkungen der Theorien dazu? Aufbau der Leistungsbereiche, Schleichender Wandel im Vertragstyp, OLG München v , CR 1990, 646 OLG Düsseldorf v , NJW 1989, 2627, Installation ändert Vertragstyp OLG Köln v , CR 2003, 246; OLG Karlsruhe v , CR 2003, 95 BGH v III ZR 93/09 Videoportal Dienstvertrag bei Lieferung Standardsoftware und zusätzlich Anpassung, v.a. wenn Anpassungsaufwand relativ gering? a) Zur Anwendbarkeit von 627 Abs. 1, 628 Abs. 1 Satz 1, 3 BGB auf einen Vertrag mit dem Betreiber eines sogenannten Video-Partnerportals. Stephan-lorenz.de : Der BGH sieht hier zu recht in der werkvertraglichen Komponente (Erstellung eines Videos) eine nur untergeordnete Leistung. Es liegt also ein gemischter Vertrag vor, der seinen Schwerpunkt aber im Dienstvertragsrecht hat und daher zumindest für die Kündigungsmöglichkeit allein Dienstvertragsrecht unterliegt. 3. Vorschläge, Alternativen Vorschlag 1: Analogie zu, Vergleich mit Maschinenlieferungs- und Aufstellungsvertrag. Statt Abnahme: Test der Vertragsgemäßheit, proof of... vor Auslieferung und SLA zur Performance S.a. J. Schneider, in Schneider/von Westphalen (Hrsg.), Softwareerstellungsverträge, 2006, B. 1 ff., Nach Maume/Wilser, CR 2010, 209, bei Softwareerstellung sei stets Planung vorausgehend. 30 Zitat wie oben: CR 2010, 137 zu OLG München, Internationale Zuständigkeit, S. 138: Ob ein Softwareentwicklungsvertrag unter deutschem Recht ein Werkvertrag wäre, spielt für die europäische Einordnung keinerlei Rolle. Und Fn. 9: Dies übersieht OLG München. 31 BGH v VIII ZR 220/97 zu Kauf mit Montageverpflichtung und Rückabwicklung 20

Agile Software-Entwicklung: Überblick

Agile Software-Entwicklung: Überblick Agile Software-Entwicklung: Überblick Stefan Diener / Apr 18, 2007 / Page 1 Inhalt Historie Agiles Manifest Agile Prinzipien Agile Methoden Agile SW-Entwicklungsprozesse Stefan Diener / Apr 18, 2007 /

Mehr

12.07.2009. agiles Projektmanagement. agiles Projektmanagement. Universität Würzburg 6. Juli 2009. Universität Würzburg 6.

12.07.2009. agiles Projektmanagement. agiles Projektmanagement. Universität Würzburg 6. Juli 2009. Universität Würzburg 6. ? agiles Projektmanagement Benedict Gross mail@b-gross.com Augustenstr. 53 +49 172 75 75 75 4 80333 München +49 89 90 77 25 44 agiles Projektmanagement Einige Fragen zur Einführung: Was wissen Sie über

Mehr

Agile Entwicklung Technical Literacy 1

Agile Entwicklung Technical Literacy 1 Agile Entwicklung Technical Literacy 1 Prof. Dr.-Ing. Carsten Bormann cabo@tzi.org 1 xkcd 844! Thanks, Randall Munroe, for all the wonderful teaching materials !Building the thing right vs.!building the

Mehr

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering 4. Methodologien Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering: 4. Methodologien 2 Wie den Entwicklungsprozess organisieren? Dokumentieren Verwalten Instandhalten

Mehr

Agile SW- Entwicklungsmethoden. Ein agiler Vortrag über Ideen, die uns das Leben erleichtern sollen. von Paul Palaszewski

Agile SW- Entwicklungsmethoden. Ein agiler Vortrag über Ideen, die uns das Leben erleichtern sollen. von Paul Palaszewski Agile SW- Entwicklungsmethoden Ein agiler Vortrag über Ideen, die uns das Leben erleichtern sollen. von Paul Palaszewski Agenda 1) Arten des Lernens: Shu-Ha-Ri 2) Das Agile Software Development Manifest.

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

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden vs. Agile Methoden Christoph.Kluck@Student.Reutlingen University.de Medien und Kommunikationsinformatik Agenda Einführung Vorgehensmodelle Herkömmlich agil Resümee Klassische Probleme Nachgereichte Anforderungen

Mehr

Vertragsgestaltung im Rahmen agiler Softwareentwicklung. Nils Purwin, LL.M., B.Sc.

Vertragsgestaltung im Rahmen agiler Softwareentwicklung. Nils Purwin, LL.M., B.Sc. Vertragsgestaltung im Rahmen agiler Softwareentwicklung Nils Purwin, LL.M., B.Sc. Inhaltsverzeichnis A. Einführung in die Thematik B. Agilität in der Vertragsgestaltung I. Entwicklungsleistung II. Einräumung

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

Herausforderungen bei agiler Entwicklung und agilem Testen

Herausforderungen bei agiler Entwicklung und agilem Testen Herausforderungen bei agiler Entwicklung und agilem Testen Dr. Andreas Birk, Gerald Heller Vivit Deutschland Jahrestreffen, Bad Honnef 14. September 2010 Inhalt Was ist agile Entwicklung? Wie unterstützt

Mehr

Festpreisvertrag und agil nützt nicht viel? Stefan Roock, stefan.roock@akquinet.de Henning Wolf, henning.wolf@akquinet.de http://www.it-agile.

Festpreisvertrag und agil nützt nicht viel? Stefan Roock, stefan.roock@akquinet.de Henning Wolf, henning.wolf@akquinet.de http://www.it-agile. Festpreisvertrag und agil nützt nicht viel? Stefan Roock, stefan.roock@akquinet.de Henning Wolf, henning.wolf@akquinet.de http://www.it-agile.de Unser Hintergrund Agile Softwareentwicklung/Schulung/Beratung

Mehr

Agile Methoden vs. Testen

Agile Methoden vs. Testen Agile Methoden vs. Testen cc gmbh Bernhard Moritz CC GmbH TAV 27, AK Testmanagement, 6.6.2008 Bernhard Moritz Flachstraße 13 65197 Wiesbaden Telefon 0611 94204-0 Telefax 0611 94204-44 Bernhard.Moritz@cc-gmbh.de

Mehr

Der neue EVB-IT Systemlieferungsvertrag - wesentliche Punkte und die Grenze zum Werkvertragsrecht Marco Junk BITKOM

Der neue EVB-IT Systemlieferungsvertrag - wesentliche Punkte und die Grenze zum Werkvertragsrecht Marco Junk BITKOM Der neue EVB-IT Systemlieferungsvertrag - wesentliche Punkte und die Grenze zum Werkvertragsrecht Marco Junk BITKOM LawCamp 2010 20. März 2010, Frankfurt a.m. Inhalt I. Historie II. Der neue EVB-IT Systemlieferungsvertrag

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

Was funktioniert und was nicht? Agile Softwareentwicklung in der Praxis Martin Lippert, martin.lippert@akquinet.de

Was funktioniert und was nicht? Agile Softwareentwicklung in der Praxis Martin Lippert, martin.lippert@akquinet.de Was funktioniert und was nicht? Agile Softwareentwicklung in der Praxis Martin Lippert, martin.lippert@akquinet.de Über mich Martin Lippert Senior IT-Berater bei akquinet it-agile GmbH martin.lippert@akquinet.de

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

Softwareprojektverträge Rechtliche Aspekte

Softwareprojektverträge Rechtliche Aspekte Softwareprojektverträge Rechtliche Aspekte Rechtsanwalt Marcus Beckmann BECKMANN UND NORDA RECHTSANWÄLTE Welle 9-33602 Bielefeld http://www.beckmannundnorda.de info@beckmannundnorda.de fon 0521/98628-0

Mehr

Fragestellungen im IT Projektgeschäft

Fragestellungen im IT Projektgeschäft Fragestellungen im IT Projektgeschäft 10. November 2011 Beutler Künzi Stutz, Bern 1 Inhalt 1. Agile Softwareentwicklung 2. Cloud Computing 3. Fragen 10. November 2011 Beutler Künzi Stutz, Bern 2 Manifest

Mehr

Selbstorganisiert ein Ziel erreichen Analyse, Architektur und Design in agilen Software-Projekten

Selbstorganisiert ein Ziel erreichen Analyse, Architektur und Design in agilen Software-Projekten Selbstorganisiert ein Ziel erreichen Analyse, Architektur und Design in agilen Software-Projekten 1 Qualifikation Über den Vortragenden Freiberuflicher SW-Entwickler und Berater seit 2006 Certified Scrum

Mehr

Das Who s Who der agilen Methoden Golo Roden

Das Who s Who der agilen Methoden Golo Roden Das Who s Who der agilen Methoden Golo Roden www.goloroden.de www.des-eisbaeren-blog.de Über mich > Wissensvermittler und Technologieberater >.NET, Codequalität und agile Methoden > MVP für C#, zweifacher

Mehr

Vertragsrecht in agilen Softwareprojekten. Prof. Ursula Sury, RA

Vertragsrecht in agilen Softwareprojekten. Prof. Ursula Sury, RA Vertragsrecht in agilen Softwareprojekten Prof. Ursula Sury, RA 1 Agenda Die zentrale Frage/ Grundelemente des Softwarevertrags Ablauf der Softwareentwicklung Ziele der agilen Software Besonderheiten der

Mehr

Trends in der Agilität Dr. Martin Geier

Trends in der Agilität Dr. Martin Geier Projektmanagement Agil Trends in der Agilität Dr. Martin Geier Zahlen und Fakten Fakten Gründung 2001 Standorte: Deutschland: Erlangen, München USA: Detroit, Miami Auszeichnungen 2004 2008 2011 2006, 2007,

Mehr

Zum Überblick: Lorenz/Riehm, JuS Lern CD Zivilrecht I Rn. 382 ff (Gewährleistung im Werkvertrag)

Zum Überblick: Lorenz/Riehm, JuS Lern CD Zivilrecht I Rn. 382 ff (Gewährleistung im Werkvertrag) Prof. Dr. Stephan Lorenz Vorlesung ADas neue Schuldrecht in Anspruchsgrundlagen@ Übungsfall 14: "Backup" (Abgrenzung Kaufvertrag/Werkvertrag/Werklieferungsvertrag, Mangelfolgeschäden beim Werkvertrag,

Mehr

IT-Projekte mit System: Vertragsmanagement als Erfolgsfaktor

IT-Projekte mit System: Vertragsmanagement als Erfolgsfaktor IT-Projekte mit System: Vertragsmanagement als Erfolgsfaktor Dr. Jörg Schneider-Brodtmann Tübingen, 21.06.2007 1 Ausgangslage max. 20 % 30 % aller IT-Projekte werden erfolgreich abgeschlossen etwa 20 %

Mehr

Vorlesung Das neue Schuldrecht in Anspruchsgrundlagen

Vorlesung Das neue Schuldrecht in Anspruchsgrundlagen Prof. Dr. Stephan Lorenz Vorlesung Das neue Schuldrecht in Anspruchsgrundlagen Übungsfall 14: "Backup" (Abgrenzung Kaufvertrag/Werkvertrag/Werklieferungsvertrag, Mangelfolgeschäden beim Werkvertrag, Verjährung)

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

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

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

Ganzheitliches IT-Projektmanagement

Ganzheitliches IT-Projektmanagement Ganzheitliches IT-Projektmanagement Kapitel 2 nach dem Buch: Ruf, Walter; Fittkau, Thomas: "Ganzheitliches IT-Projektmanagement" Wissen - Praxis - Anwendungen R. Oldenbourg Verlag München - Wien 2008;

Mehr

BUNDESGERICHTSHOF BESCHLUSS

BUNDESGERICHTSHOF BESCHLUSS BUNDESGERICHTSHOF XI ZR 327/01 BESCHLUSS vom 5. Februar 2002 in dem Rechtsstreit - 2 - Der XI. Zivilsenat des Bundesgerichtshofes hat am 5. Februar 2002 durch den Vorsitzenden Richter Nobbe und die Richter

Mehr

V-Methode, RUP, Waterfall oder was?

V-Methode, RUP, Waterfall oder was? 5. Bayerischer IT-Rechtstag am 26. Oktober 2006 auf der SYSTEMS 2006 in München Übersicht über die verschiedenen Vorgehensmodelle Dr. Sarre & Schmidt EDV-Sachverständige, München Öffentlich bestellter

Mehr

vogel & partner rechtsanwälte

vogel & partner rechtsanwälte Agile Projektsteuerung und Urheberrecht sowie Know-how-Schutz Karlsruher Entwicklertag, agile day, 22.05.2014 IHK Karlsruhe Prof. Dr. Rupert Vogel Rechtsanwalt Fachanwalt für IT-Recht Karlsruhe/Stuttgart

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

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

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

Scrum. Golo Roden. www.goloroden.de www.des-eisbaeren-blog.de

Scrum. Golo Roden. www.goloroden.de www.des-eisbaeren-blog.de Scrum Golo Roden www.goloroden.de www.des-eisbaeren-blog.de Über mich > Wissensvermittler und Technologieberater >.NET, Codequalität und agile Methoden > MVP für C#, zweifacher MCP und CCD > Autor, Sprecher

Mehr

Di 7.2. Sprinten mit dem V-Modell XT. Olaf Lewitz. January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich

Di 7.2. Sprinten mit dem V-Modell XT. Olaf Lewitz. January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Di 7.2 January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Sprinten mit dem V-Modell XT Olaf Lewitz Sprinten mit dem V-Modell XT Olaf Lewitz microtool GmbH, Berlin Konkurrenz

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

ZuuL - Entwicklung eines Adventures

ZuuL - Entwicklung eines Adventures ZuuL - Entwicklung eines Adventures im Rahmen der Uni-Tage 2009 Team 120 Universität Hamburg 16./17. November 2009 Team 120 (Universität Hamburg) ZuuL - Entwicklung eines Adventures 16.11.09 1 / 21 Übersicht

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

Kurzübersicht Unified Process und Agile Prozesse

Kurzübersicht Unified Process und Agile Prozesse Kurzübersicht Unified Process und Agile Prozes Rainer Schmidberger schmidrr@informatik.uni-stuttgart.de Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt.

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

Software Engineering. 2. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2010

Software Engineering. 2. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2010 Software Engineering 2. Methodologien Franz-Josef Elmer, Universität Basel, HS 2010 Software Engineering: 2. Methodologien 2 Wie den Entwicklungsprozess organisieren? Dokumentieren Verwalten Instandhalten

Mehr

XP, Scrum, Crystal, FDD:

XP, Scrum, Crystal, FDD: XP, Scrum, Crystal, FDD: Welche agile Methode passt zu uns? Henning Wolf Christoph Kemp Was ist Agilität? Teil 1: Das agile Manifest We are uncovering better ways of developing software by doing it and

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

BUNDESGERICHTSHOF IM NAMEN DES VOLKES URTEIL. in dem Rechtsstreit

BUNDESGERICHTSHOF IM NAMEN DES VOLKES URTEIL. in dem Rechtsstreit BUNDESGERICHTSHOF IM NAMEN DES VOLKES VII ZR 103/02 Nachschlagewerk: ja URTEIL in dem Rechtsstreit Verkündet am: 9. Januar 2003 Seelinger-Schardt, Justizangestellte als Urkundsbeamter der Geschäftsstelle

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

Inhaltsübersicht. Vorwort... Inhaltsverzeichnis... Abkürzungsverzeichnis... Literaturverzeichnis... Erstes Kapitel: Der Rechtsschutz für EDV-Produkte

Inhaltsübersicht. Vorwort... Inhaltsverzeichnis... Abkürzungsverzeichnis... Literaturverzeichnis... Erstes Kapitel: Der Rechtsschutz für EDV-Produkte Vorwort... Inhaltsverzeichnis... Abkürzungsverzeichnis... Literaturverzeichnis.... V XV XXVII XXXI Erstes Kapitel: Der Rechtsschutz für EDV-Produkte Einführung I. Vorüberlegung: Der Ideenschutz... 1 II.

Mehr

Agile Softwareentwicklung - Ein praktisches Beispiel -

Agile Softwareentwicklung - Ein praktisches Beispiel - Agile Softwareentwicklung - Ein praktisches Beispiel - Dr. Dagmar Monett Díaz Berlin, 03.11.2009 D. Monett: Agile Softwareentwicklung Ein praktisches Beispiel Der Softwareentwicklungsprozess Sichtweisen,

Mehr

Hot & Spicy Erfahrungen mit agilerem Requirements Engineering im Automotive Umfeld Omar Naas, Senior Consultant, EVOCEAN GmbH

Hot & Spicy Erfahrungen mit agilerem Requirements Engineering im Automotive Umfeld Omar Naas, Senior Consultant, EVOCEAN GmbH ReConf 2010 München 17. März 2010 Hot & Spicy Erfahrungen mit agilerem Requirements Engineering im Automotive Umfeld Omar Naas, Senior Consultant, EVOCEAN GmbH Agenda 1. Automotive SPICE Ein kurzer Einblick

Mehr

BUNDESGERICHTSHOF IM NAMEN DES VOLKES URTEIL. 1. Dezember 2010 Ermel, Justizangestellte als Urkundsbeamtin der Geschäftsstelle. in dem Rechtsstreit

BUNDESGERICHTSHOF IM NAMEN DES VOLKES URTEIL. 1. Dezember 2010 Ermel, Justizangestellte als Urkundsbeamtin der Geschäftsstelle. in dem Rechtsstreit BUNDESGERICHTSHOF IM NAMEN DES VOLKES VIII ZR 82/10 Nachschlagewerk: ja BGHZ: nein BGHR: ja URTEIL in dem Rechtsstreit Verkündet am: 1. Dezember 2010 Ermel, Justizangestellte als Urkundsbeamtin der Geschäftsstelle

Mehr

ANECON. Business Process meets Agile Software Development. DI Ernst Lieber Leiter Geschäftsfeld Softwareentwicklung

ANECON. Business Process meets Agile Software Development. DI Ernst Lieber Leiter Geschäftsfeld Softwareentwicklung ANECON Business Process meets Agile Software Development DI Ernst Lieber Leiter Geschäftsfeld Softwareentwicklung ANECON Software Design und Beratung G.m.b.H. Alser Str. 4/Hof 1 A-1090 Wien Tel.: +43 1

Mehr

Rechtliche Aspekte des Cloud Computing

Rechtliche Aspekte des Cloud Computing Rechtliche Aspekte des Cloud Computing Fabian Laucken Rechtsanwalt und Fachanwalt für gewerblichen Rechtsschutz und Fachanwalt für Informationstechnologierecht Vertragsrecht I Einordnung von Clouddiensten

Mehr

1 Einleitung. A. Einführung und Problemaufriss

1 Einleitung. A. Einführung und Problemaufriss 1 Einleitung A. Einführung und Problemaufriss Dem tradierten Konzept des Vertragsschlusses, wie es auch die Verfasser des BGB vor Augen hatten, liegt die Vorstellung zugrunde, ein Vertrag werde entweder

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

Systemen - Testen im Softwarelebenszyklus

Systemen - Testen im Softwarelebenszyklus P r a k t I s c h e Entwicklung und Test Testen von Software-Systemen Systemen - Testen im Softwarelebenszyklus Entwickler erstellen ihr System bzw. ihre Software und testen es/sie zur Entwicklungszeit

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

Vorinstanzen LG Düsseldorf, 19.02.2009, Az: 21 S 53/08, AG Düsseldorf, 19.12.2007, Az: 31 C 8544/07. Vertragsrecht; AGB-Recht; Werkvertragsrecht

Vorinstanzen LG Düsseldorf, 19.02.2009, Az: 21 S 53/08, AG Düsseldorf, 19.12.2007, Az: 31 C 8544/07. Vertragsrecht; AGB-Recht; Werkvertragsrecht Gericht BGH Aktenzeichen III ZR 79/09 Datum 04.03.2010 Vorinstanzen LG Düsseldorf, 19.02.2009, Az: 21 S 53/08, AG Düsseldorf, 19.12.2007, Az: 31 C 8544/07 Rechtsgebiet Schlagworte Leitsätze Vertragsrecht;

Mehr

Social Media als Hilfsmittel für agile Projekt-Teams

Social Media als Hilfsmittel für agile Projekt-Teams Social Media als Hilfsmittel für agile Projekt-Teams 14. Sept. 2010, Zürich Dr. Hans-Peter Korn www.korn.ch "Agiles" Management: Wozu? Resultat > Konzept / Plan Planen - Reisen - Ankommen voraussehbar,

Mehr

der Vertragsgestaltung info@infora.de www.infora.de

der Vertragsgestaltung info@infora.de www.infora.de Fachtagung IT-Beschaffung 2013 Fachforum 5 Agile Softwareentwicklung Aspekte INFORA GmbH Wilhelm Kruth W Sa Salzufer 8 10587 Berlin Tel.: 030 893658-0 Fax: 030 89093326 der Vertragsgestaltung info@infora.de

Mehr

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Die Bearbeitungszeit der Klausur beträgt 90 Minuten. Es sind alle

Mehr

Beschluss des Bundesgerichtshofs vom 12.12.2002 I ZB 29/02 - Der Bundesgerichtshof hat mit Beschluss vom 12.12.2002 I ZB 29/02 wie folgt entschieden:

Beschluss des Bundesgerichtshofs vom 12.12.2002 I ZB 29/02 - Der Bundesgerichtshof hat mit Beschluss vom 12.12.2002 I ZB 29/02 wie folgt entschieden: HVBG-INFO 006/2004-458- Bei dem Mehraufwand für die Vertretung einer am eigenen Gerichtsstand klagenden oder verklagten Partei durch einen auswärtigen Rechtsanwalt handelt es sich nicht um Kosten, die

Mehr

Empirische Evidenz von agilen Methoden. Seminar in Software Engineering Wintersemester 03/04

Empirische Evidenz von agilen Methoden. Seminar in Software Engineering Wintersemester 03/04 Empirische Evidenz von agilen Methoden Seminar in Software Engineering Wintersemester 03/04 Agenda Einleitung Bedeutung von agil Kurzübesicht agiler Methoden Überprüfung des (agilen) Erfolges Ausgewählte

Mehr

BUNDESGERICHTSHOF BESCHLUSS. vom. 31. Oktober 2006. in dem Rechtsstreit

BUNDESGERICHTSHOF BESCHLUSS. vom. 31. Oktober 2006. in dem Rechtsstreit BUNDESGERICHTSHOF VI ZB 20/06 BESCHLUSS vom 31. Oktober 2006 in dem Rechtsstreit Nachschlagewerk: BGHZ: BGHR: ja nein ja ZPO 233 Fe, 85 Abs. 2 Der beim OLG nicht zugelassene Rechtsanwalt, der als Vertreter

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

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

BUNDESGERICHTSHOF BESCHLUSS. vom. 22. Februar 2010. in dem Rechtsstreit

BUNDESGERICHTSHOF BESCHLUSS. vom. 22. Februar 2010. in dem Rechtsstreit BUNDESGERICHTSHOF II ZB 8/09 BESCHLUSS vom 22. Februar 2010 in dem Rechtsstreit Nachschlagewerk: BGHZ: BGHR: ja nein ja BRAO 155 Abs. 4, 5 Satz 1 Wegen des eindeutigen, einer Auslegung nicht zugänglichen

Mehr

Scrum Einführung. SWP: Spieleprogrammierung Fachbereich Mathematik und Informatik

Scrum Einführung. SWP: Spieleprogrammierung Fachbereich Mathematik und Informatik SWP: Spieleprogrammierung Fachbereich Mathematik und Informatik Scrum Einführung Do, Hoang Viet(do@mi.fu-berlin.de) Freie Universität Berlin, SoSe 2013 Rollen Product Owner Definiert die Ziele Product

Mehr

BUNDESGERICHTSHOF IM NAMEN DES VOLKES URTEIL. in dem Rechtsstreit

BUNDESGERICHTSHOF IM NAMEN DES VOLKES URTEIL. in dem Rechtsstreit BUNDESGERICHTSHOF IM NAMEN DES VOLKES I ZR 2/03 URTEIL in dem Rechtsstreit Verkündet am: 6. Mai 2004 Führinger Justizangestellte als Urkundsbeamtin der Geschäftsstelle Nachschlagewerk: ja BGHZ : nein BGHR

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

Zum Honoraranspruch des Arztes bei rechtswidrigem Eingriff

Zum Honoraranspruch des Arztes bei rechtswidrigem Eingriff Zum Honoraranspruch des Arztes bei rechtswidrigem Eingriff anläßlich des Urteils des Bundesverfassungsgerichts v 17.4.2012 1 BvR 3071/10 Beitrag zur 12. Herbsttagung der Arbeitsgemeinschaft Medizinrecht

Mehr

BUNDESGERICHTSHOF IM NAMEN DES VOLKES VERSÄUMNISURTEIL. in dem Rechtsstreit

BUNDESGERICHTSHOF IM NAMEN DES VOLKES VERSÄUMNISURTEIL. in dem Rechtsstreit BUNDESGERICHTSHOF IM NAMEN DES VOLKES VII ZR 135/00 Nachschlagewerk: ja VERSÄUMNISURTEIL in dem Rechtsstreit Verkündet am: 5. April 2001 Seelinger-Schardt, Justizangestellte als Urkundsbeamtin der Geschäftsstelle

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

Was fehlt Scrum? 31. März 2014 Erich Oswald CTO Ergon Informatik AG

Was fehlt Scrum? 31. März 2014 Erich Oswald CTO Ergon Informatik AG Was fehlt Scrum? 31. März 2014 Erich Oswald CTO Ergon Informatik AG Scrum ist eine Erfolgsstory Aus der Praxis entstanden Nachweislich erfolgreich Gut geeignet für komplexe Probleme Produktentwicklung

Mehr

Are you Agile. SAQ Zug um Zug, 27. November 2008. Agilität: Was bringen Sie mit? Was wissen Sie schon? Was wollen Sie heute Abend mitnehmen?

Are you Agile. SAQ Zug um Zug, 27. November 2008. Agilität: Was bringen Sie mit? Was wissen Sie schon? Was wollen Sie heute Abend mitnehmen? ? SAQ Zug um Zug, Agilität: Was bringen Sie mit? Was wissen Sie schon? Was wollen Sie heute Abend mitnehmen? Folie 1 hat sich als Projektleiter während acht Jahren dafür eingesetzt, Ende Iteration lauffähige

Mehr

HAFTUNG AUS FEHLERHAFTEN GUTACHTEN

HAFTUNG AUS FEHLERHAFTEN GUTACHTEN HAFTUNG AUS FEHLERHAFTEN GUTACHTEN Fortbildungsveranstaltung des Bundesverbandes unabhängiger Pflegesachverständiger, 22.02.2014, Lübeck Dr. Roland Uphoff, M.mel. Fachanwalt für Medizinrecht 839a BGB Haftung

Mehr

extreme Programming Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis dpunkt.verlag Henning Wolf Stefan Roock Martin Lippert

extreme Programming Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis dpunkt.verlag Henning Wolf Stefan Roock Martin Lippert Henning Wolf Stefan Roock Martin Lippert extreme Programming Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis 2., überarbeitete und erweiterte Auflage dpunkt.verlag 1 Einleitung 1 1.1 Die

Mehr

Starke vs. Schwache Prozesse. Seminarvortrag

Starke vs. Schwache Prozesse. Seminarvortrag Starke vs. Schwache Prozesse Seminarvortrag 1 / 16 Gliederung des Vortrags Starke vs. Schwache Prozesse 1. Hintergrund 2. Begrifflichkeiten 3. Vergleich agiler und plangesteuerter Prozesse (Orientierung

Mehr

AdoptG Art. 12 1 Abs. 1, 7 Abs. 2 Erbrechtliche Stellung eines vor dem 1.1.1977 adoptierten Minderjährigen

AdoptG Art. 12 1 Abs. 1, 7 Abs. 2 Erbrechtliche Stellung eines vor dem 1.1.1977 adoptierten Minderjährigen DNotI Deutsches Notarinstitut letzte Aktualisierung: 25.11.2014 OLG Köln, 13.8.2014-2 Wx 220/14 AdoptG Art. 12 1 Abs. 1, 7 Abs. 2 Erbrechtliche Stellung eines vor dem 1.1.1977 adoptierten Minderjährigen

Mehr

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle Diverse Grundlagen Dr. Karsten Tolle Vorgehensmodelle im Software Engineering Wasserfallmodell Rapid Prototyping Spiralmodell V-Modell Rational Unified Process extrem Programming Test Driven Development

Mehr

Wahlpflichtmodul Projekt I Softwareprojekt I

Wahlpflichtmodul Projekt I Softwareprojekt I Wahlpflichtmodul Projekt I Softwareprojekt I Dipl. Inf. Andrea Meyer SCRUM in Detail Dipl. Inf. Andrea Meyer WIEDERHOLUNG 4 Prinzipien von SCRUM Zerlegung Transparenz Anpassung Überprüfung WIEDERHOLUNG

Mehr

Arbeitshilfen zu 15 HOAI 2013 - Abnahme als Fälligkeitsvoraussetzung

Arbeitshilfen zu 15 HOAI 2013 - Abnahme als Fälligkeitsvoraussetzung Arbeitshilfen zu 15 HOAI 2013 - Abnahme als Fälligkeitsvoraussetzung Bisher bedurfte es zur Fälligkeit eines Honoraranspruchs lediglich der vertragsgemäßen Erbringung der Leistung und der Übersendung einer

Mehr

System der Musterverträge

System der Musterverträge Wichtiger Hinweis: Die nachfolgenden Ausführungen zu den vom dmmv empfohlenen Musterverträgen geben allein die Auffassung des Autors wieder und sind nicht Bestandteil der Empfehlung des dmmv. Sie können

Mehr

Web-Design-Vertrag. 1 Gegenstand des Vertrages

Web-Design-Vertrag. 1 Gegenstand des Vertrages Web-Design-Vertrag Zwischen im Folgenden Anbieter genannt und im Folgenden Kunde genannt wird folgender Vertrag geschlossen: 1 Gegenstand des Vertrages (1) Gegenstand des Vertrages ist die Entwicklung

Mehr

DNotI. 9zr14499 BGH IX ZR 144/99 13.04.2000 GesO 10 Abs. 1 Nr. 4

DNotI. <Dokumentnummer> 9zr14499 <Gericht> BGH <Aktenzeichen> IX ZR 144/99 <Datum> 13.04.2000 <Normen> GesO 10 Abs. 1 Nr. 4 DNotI Deutsches Notarinstitut Dokumentnummer: 9zr14499 letzte Aktualisierung: 24.Mai 2000 9zr14499 BGH IX ZR 144/99 13.04.2000 GesO 10 Abs. 1

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

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

Sittenwidrigkeitsprüfung von Kettenkrediten

Sittenwidrigkeitsprüfung von Kettenkrediten Sittenwidrigkeitsprüfung von Kettenkrediten Nach der Rechtsprechung kann ein Kreditvertrag auch dann sittenwidrig sein, wenn er auf einem unangemessenen Umschuldungsverlangen der Bank beruht, weil die

Mehr

Projektmanagement. Projektmanagement

Projektmanagement. Projektmanagement Projektmanagement Dipl.-Ing. Oliver Lietz Was ist ein Projekt? Projektmanagement Eindeutiges Ziel Individuell (einmalig) Begrenzt (Anfang und Ende) Komplex (keine Routineaufgabe) Warum Projektmanagement

Mehr

BUNDESGERICHTSHOF IM NAMEN DES VOLKES URTEIL. 5. Mai 2008 Röder Justizhauptsekretärin als Urkundsbeamtin der Geschäftsstelle. in dem Rechtsstreit

BUNDESGERICHTSHOF IM NAMEN DES VOLKES URTEIL. 5. Mai 2008 Röder Justizhauptsekretärin als Urkundsbeamtin der Geschäftsstelle. in dem Rechtsstreit BUNDESGERICHTSHOF IM NAMEN DES VOLKES II ZR 108/07 Nachschlagewerk: ja URTEIL in dem Rechtsstreit Verkündet am: 5. Mai 2008 Röder Justizhauptsekretärin als Urkundsbeamtin der Geschäftsstelle BGHZ: nein

Mehr

BUNDESGERICHTSHOF IM NAMEN DES VOLKES URTEIL. 15. November 2006 Breskic, Justizangestellte als Urkundsbeamtin der Geschäftsstelle. in dem Rechtsstreit

BUNDESGERICHTSHOF IM NAMEN DES VOLKES URTEIL. 15. November 2006 Breskic, Justizangestellte als Urkundsbeamtin der Geschäftsstelle. in dem Rechtsstreit BUNDESGERICHTSHOF IM NAMEN DES VOLKES XII ZR 120/04 Nachschlagewerk: ja URTEIL in dem Rechtsstreit Verkündet am: 15. November 2006 Breskic, Justizangestellte als Urkundsbeamtin der Geschäftsstelle BGHZ:

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

Az: 3/11 O 3/91 Vorhergehendes Az: LG Frankfurt am Main Datum: 16.09.1991 Fundstelle: http://www.globalsaleslaw.com/content/ api/cisg/urteile/26.

Az: 3/11 O 3/91 Vorhergehendes Az: LG Frankfurt am Main Datum: 16.09.1991 Fundstelle: http://www.globalsaleslaw.com/content/ api/cisg/urteile/26. Az: 3/11 O 3/91 Vorhergehendes Az: Gericht: LG Frankfurt am Main Datum: 16.09.1991 Fundstelle: Siehe auch: http://www.globalsaleslaw.com/content/ api/cisg/urteile/26.htm E n t s c h e i d u n g s g r ü

Mehr

Einführung in die Softwaretechnik 9. Softwareprozesse

Einführung in die Softwaretechnik 9. Softwareprozesse 9. Softwareprozesse Klaus Ostermann (Mit Folien von Christian Kästner, Gabriele Taentzer und Wolfgang Hesse) 1 Agenda Wie kommt man vom Kundenwunsch zur fertigen Software? Wie strukturiert man ein Softwareprojekt?

Mehr

Wie agil kann Business Analyse sein?

Wie agil kann Business Analyse sein? Wie agil kann Business Analyse sein? Chapter Meeting Michael Leber 2012-01-24 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

13 W 890/10. Leitsatz

13 W 890/10. Leitsatz 13 W 890/10 Leitsatz Die Unterscheidungskraft einer an eine Internetdomain angelehnten Firma gem. 18 Abs. 1 HGB kann sich aus dem Zusammenhang einer für sich gesehenen nicht unterscheidungskräftigen Second-Level-Domain

Mehr

Klassische vs. agile Methoden der Softwareentwicklung

Klassische vs. agile Methoden der Softwareentwicklung Klassische vs. agile Methoden der Softwareentwicklung Vorgetragen am 03. November 2004 durch Jonathan Weiss Emel Tan Erstellt für SWT Methoden und Werkzeuge zur Softwareproduktion Agenda I. Einleitung

Mehr

Allgemein anerkannten Regeln der Technik

Allgemein anerkannten Regeln der Technik Rechtsanwalt Martin Liebert Eisenacher Straße 2, 10777 Berlin Dozent der Fachhochschule für Verwaltung und Recht Berlin, BBA Berlin, MCI Innsbruck, IAPH Berlin Die Allgemein anerkannten Regeln der Technik

Mehr

DNotI. Dokumentnummer: 2zr108_07 letzte Aktualisierung: 5.5.2008 BGH, 5.5.2008 - II ZR 108/07. GmbHG 32 a Abs. 3; AktG 76 Abs. 1

DNotI. Dokumentnummer: 2zr108_07 letzte Aktualisierung: 5.5.2008 BGH, 5.5.2008 - II ZR 108/07. GmbHG 32 a Abs. 3; AktG 76 Abs. 1 DNotI Deutsches Notarinstitut Dokumentnummer: 2zr108_07 letzte Aktualisierung: 5.5.2008 BGH, 5.5.2008 - II ZR 108/07 GmbHG 32 a Abs. 3; AktG 76 Abs. 1 Eigenkapitalersatzregeln gelten nicht für Finanzierungshilfe

Mehr