Home

Softwareentwicklungsverträge - Gießener Elektronische Bibliothek

Contents

1. Neben der ungenauen Zieldefinition wird der best ndige Wandel der Anforderungen als kritischer Faktor hervorgehoben Dies gilt insbesondere weil einmalige Abweichungen selten sind Sie ziehen vielmehr regelm ig weitere nderungen nach sich Die Kosten f r nderungen einschlie lich Erweiterungen k nnen dabei in derselben Gr enordnung wie die einer Neuentwicklung liegen Es wird daraus unmittelbar verst ndlich warum die Erfolgsaussichten eines Projektes teilweise davon abh ngig gemacht werden wie wirkungsvoll das Softwarehaus sich gegen nderungsw nsche des Softwarebestellers wehren kann Love illustriert dies anschaulich indem er als wichtigen Grund f r ein Scheitern von Softwareprojekten in Bezug auf Erweiterungs und nderungsw nsche ausf hrt Wir haben nicht gelernt wie wir oft oder wirkungsvoll genug nein sagen sollen c Zusammenfassung und Ergebnis Die Erstellung von Software ist ein komplexer Prozess Der Weg vom Beginn des Projektes bis zu seinem Abschluss ist in vielf ltiger Weise begehbar Die Vorstellung f r diesen Weg einen allgemein verbindlichen Plan zu zeichnen der die Wirklichkeit auch nur ann hernd genau wiedergibt hat sich in der Praxis als Illusion erwiesen Andererseits wird genau dieser verbindliche und m glichst konkrete Plan als Grundvoraussetzung f r ein Gelingen betrachtet Softwarehaus und Softwarebesteller m ssen also mit einem Paradoxon zu Rech
2. Nach Love sind gr ere Software Projekte so komplex in ihrem Bau und so teuer wie die Konstruktion eines gro en Fabrikgeb udes oder neuen Flughafens a a O S 190 7 Siehe dazu unten Kritische Faktoren P S o S 16 74 Maymon Cave a a O S 16 diesen subjektiven Faktor betonend auch Love a a O S 206 75 Abzuraten ist daher nach Etzel Heilmann Richter von Vorgaben wie weniger Benutzerfehler als bisher Stattdessen sollte konkret angegeben werden z B wie viele Fehler auf wie viele Gesch ftsvorf lle und wie viele Sekunden durchschnittlicher Antwortzeiten a a O S 22ff 76 Hierunter wird v a die nderbarkeit verstanden siehe bei Franz a a O S 19f 7 Darunter ist v a die Unabh ngigkeit der Software von Rahmenbedingungen wie anderer Software v a des Betriebssystems und der Hardware zu verstehen Franz a a O S 21ff Geht man davon aus dass Individualsoftware erheblich l nger lebt als ihre technische Umgebung so Franz a a O S 85 Zehnder a a O S 153f so erlangt dieses Merkmal langfristig erhebliche Bedeutung 78 Etzel Heilmann Richter a a O S 22 ausf hrlich Franz a a O S Off 79 Nach Rupp sollten die Abnahmekriterien als Bestandteil des Vertrages innerhalb der Anforderungsanalyse erstellt werden a a O S 328 und die Anforderungen pr zise abbilden S 328 25 Kapitel 2 Softwareentwicklung in der Praxis Auf diese Weise soll erreicht werden dass Soft
3. Sie ist Bestandteil des materiellen Rechts und findet ohne gesonderte Vereinbarung jedenfalls dann Anwendung wenn die Niederlassungen places of business Art 10 CISG beider Vertragsparteien in verschiedenen Staaten liegen die gleicherma en die Konvention ratifiziert haben Die Art 1 bis 4 CISG regeln die Anwendbarkeit der Konvention Nach Art 1 der CISG ist das bereinkommen auf Kaufvertr ge ber Waren zwischen Parteien anzuwenden die ihre Niederlassung in verschiedenen Staaten haben Es werden nicht nur Kaufvertr ge ber schon existierende Waren goods erfasst sondern auch contracts for the supply of goods to be manufactured or produced Art 3 Abs 1 CISG also Kaufvertr ge ber noch herzustellende Waren Eine Anwendung wird dann ausgeschlossen wenn der berwiegende Teil der Vertragspflicht des Lieferanten in der Ausf hrung von Arbeiten oder anderen Dienstleistungen supply of labor or other services liegt Art 3 Abs 2 CISG Es ist zun chst zu fragen ob Software als Ware good i S der CISG angesehen wird In der US Rechtsprechung findet sich hierzu keine verwertbare Stellungnahme Die in der Literatur hierzu gef hrte Diskussion hat sich mit denselben Argumenten wie bei der Frage nach der Anwendbarkeit des U C C 188 Der CISG wird in der amerikanischen Literatur auch einfach unter der Bezeichnung United Nations Convention und im deutschen Sprachraum al
4. 1 6 Leistungs nderungen Alle nach Vertragsschluss erfolgenden nderungen des Leistungsumfanges werden nur dann Vertragsinhalt wenn sie vereinbart und im Software Leistungsschein aufgenommen werden Der Anbieter beh lt sich vor die unter 7 vereinbarte Verg tung bei vereinbarten nderungen des Leistungsumfanges angemessen zu erh hen Der Auftragnehmer kann f r eine erforderliche umfangreiche Pr fung ob und zu welchen Bedingungen die gew nschte nderung durchf hrbar ist eine angemessene Verg tung verlangen sofern er den Auftraggeber auf die Notwendigkeit der Pr fung hinweist und der Auftraggeber einen entsprechenden Pr fauftrag gibt verg tungspflichtige nderungspr fung Wie bei MA gibt es keinen Anspruch des Softwarebestellers auf Durchf hrung von nderungen erneut vor dem Hintergrund einer vollst ndigen Erfassung des Vertragszieles bei Vertragsabschluss KO h lt nderungen allerdings nach dieser Formulierung insofern f r regelungsbed rftig als dem nderungsbereiten Softwarehaus durch die Pr fung eines nderungsverlangens erheblicher Aufwand entstehen kann und damit eine Verg tung angemessen ist Das Muster betont dabei die Notwendigkeit einer Vereinbarung d h einer kosten bewussten ausdr cklichen Entscheidung des Auftraggebers In den Mustern BA GL SN B SN A und den BVB sind deutlich umfangreichere mehrstufige Verfahren f r nderungen vorgesehen Die nderungsregelung geh rt bei GL
5. 2537 21 22 Kapitel 3 Rechtliche Rahmenbedingungen in den USA Softwarehauses angesehen Wurde urspr nglich noch davon ausgegangen dass selbst gr ere Unternehmen wegen eines Wissensgef lles zu Gunsten des Softwarehauses sch tzenswert sein k nnen so wurden mit zunehmender Verbreitung der EDV und damit der Softwareentwicklung auch an den Besteller h here Anforderungen gestellt Auch ohne ausdr ckliche dahingehende Vereinbarung kann sich ein Besteller nicht auf unzureichende Resultate des Softwarehauses berufen wenn er seine Mitwirkungspflichten verletzt Die Herleitung dieses Ergebnisses nach dem Recht von Illinois beruhte auf einem Sechs Stufen Test f r breach of contract Auf der vierten Stufe wird vom Kl ger verlangt dass er beweist alle eigenen vertraglichen Verpflichtungen eingehalten zu haben Auch Nachforderungen d h das Bestehen auf Leistungen die vom urspr nglichen Auftrag nicht gedeckt sind k nnen im Konfliktfall als Vertragsverletzung ausgelegt werden Beeintr chtigen die nderungsw nsche des Bestellers den Projektfortschritt so kann er sich nicht unter Bezugnahme auf den Vertragsbruch des Softwarehauses von 222 when you are talking to non computer people they talk in generalities and great vagueness because they just don t understand the details that are involved in automating anything The job ofthe systems analyst is to listen to them in their terms and then
6. issued insbesondere angesichts der Tatsache dass es sich bei dem Besteller um ein sehr gro es Unternehmen mit einer eigenen IT Abteilung handelt Auch die Terminologie der Authorization Letters l sst es nahe liegend erscheinen dass das Softwarehaus zur Ausf hrung vom Softwarebesteller vorgegebener Arbeiten autorisiert wird wenngleich dieser Schluss nicht zwingend ist 266 Unter 1 1 1 1 84 Kapitel 4 Empirischer Befund in den USA Es wird deutlicher hinsichtlich der neu zu entwickelnden Software Hier findet sich zun chst eine der soeben aufgef hrten hnliche Formulierung MAS shall be developed tested and implemented in modules and subsystems which shall be jointly prioritized by FDRI and PRODIGY and implemented in accordance with each MAS Joint Detailed Project Plan that results from Exhibit 1 Section 2 and with the MAS Implementation Plans that result from Exhibit 5 Section 6 Diese wird im Anschluss daran weiter prazisiert The Project Managers shall be responsible for the day to day management and successful completion ofthe MAS and SMS projects as set forth in Exhibit 1 and of the Joint Detailed Project Plans required under Exhibit 1 Section 2 The Project Managers shall also establish a MAS Design Baseline that shall be mutually agreed to by FDRI and PRODIGY having been reviewed and approved by appropriate management The MAS Design Baseline shall consist of the Functional and Data Specificatio
7. 640 Rn 2 die vertraglichen Beziehungen schlagen bei Akzeptanz des Werkes als im wesentlichen vertragsgem e Leistung insoweit um als dass nunmehr die M ngelbeseitigung und nicht mehr die Erstellung eines mangelfreien Werkes geschuldet ist Bamberger Roth Voit 640 Rn 1 421 Vgl AnwK Raab 644 Rd 9 41 o gt 41 N 41 41 42 114 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland zeitliche Trennung der Risikosph ren statt Die Verj hrung ist zudem in 634a BGB anders geregelt als in 438 BGB f r das Kaufrecht Nach 438 Abs 1 Nr 3 BGB gilt f r die hier in Frage stehenden Anspr che eine Verj hrungsfrist von zwei Jahren Bei 634 Abs 1 Nr 1 BGB verj hren Anspr che ebenfalls in zwei Jahren allerdings setzt dies nach dem Tatbestand voraus dass der Erfolg in der Herstellung Wartung oder Ver nderung einer Sache oder in der Erbringung von Planungs oder Uberwachungsleistungen hierf r besteht Geht man mit einem Teil der Literatur davon aus Software sei keine Sache so f hrt dies nach 634a Abs 1 Nr 3 195 BGB zu einer Verj hrung von drei Jahren die gem 199 Abs 1 Nr 2 BGB mit Kenntniserlangung beginnt und daher ggf gem 199 Abs 4 BGB bis zu zehn Jahren dauern kann Wird modifiziertes Kaufrecht angewandt so sind M ngel ausgeschlossen wenn der Softwarebesteller sie kennt 442 Abs 1 BGB Dies gilt auch bei Werkvertragsrecht gem 640 Abs 2
8. Rn 109 der letztlich auch eine Verk rperung erfordere Rn 110 Malzer a a O S 366 das Werk bei einem Softwareentwicklungsvertrag sei nicht die geistige Leistung sondern das Produkt dieser Leistung deren Ergebnis S 269 es stehe hinter jedem Werk wenn auch untergeordnete geistige Arbeit S 268 Thewalt a a O S 46f Programm und Tr ger verhielten sich wie die Pr gung zur M nze Das Programm ist der durch durch den Pr gestempel hervorgerufenen Pr gung gleichzusetzen Die M nze entspricht dem Datentr ger Diese Trennung wird freilich auch von einem Anh nger der Sacheigenschaft vertreten siehe Krau a a O Fn 80 Redeker f hrt entsprechend aus die Programme existierten unabh ngig von der konkreten Verk rperung IT Recht Rn 280 vgl auch Diedrich CR 2002 S 473 wonach alleine das Speichermedium wahrnehmbar sei M ller Hengstenberg CR 2004 S 161 was sich insbesondere bei im Netzwerk verbundenen Systemen oder dem Outsourcing z B in Form externer Rechenzentren zeige nach dem Sachbegriff des BGB m ssten im Raum abgrenzbare physische K rper vorliegen ebenso Thewalt a a O S 47 Redeker CR 2003 S 88 384 Zweck des Vertrages ist die L sung von Anwenderproblemen im Bereich der Technik Wissenschaft und Wirtschaft Slongo a a O S 7 M ller Hengstenberg spricht davon das Hauptinteresse der Vertragsparteien l ge in der Funktionsf higkeit der L sung CR 2004 S 16
9. 110 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland 3 Ergebnis So eindeutig die Einordnung von Softwareentwicklungsvertragen in der Rspr ausfallt so uneinheitlich stellt sie sich in der Literatur dar Nach der Schuldrechtsreform hat sich dieser Sachverhalt nicht geandert Von der wohl berwiegenden Meinung wird modifiziertes Kaufvertragsrecht nach 651 S 3 BGB angewandt wenn auch einige Stimmen reines Werkvertragsrecht nach 631ff BGB anwenden wollen Einzelstimmen sprechen sich fur eine lizenzvertragliche L sung oder einen dynamischen Vertrag aus Einzelne Autoren schlie lich betonen die Unma geblichkeit der schuldrechtlichen Modelle f r die Vereinbarungen der Parteien ll Der Mangelbegriff bei der Softwareentwicklung F r die Leistungsbestimmung ist es von besonderer Bedeutung welcher Ma stab bei der Softwareentwicklung angelegt werden muss ob sie also wie jedes andere Produkt anzusehen oder eine besondere Betrachtungsweise gerechtfertigt ist Ein modifizierter Fehlerbegriff wird von manchen Stimmen in der Literatur abgelehnt Auch bei anderen hochtechnisierten Industrieprodukten stelle sich das Problem angeblicher Unvermeidbarkeit von Fehlern und f r die Softwareindustrie sei vom Gesetzgeber keine Privilegierung vorgesehen Einige Stimmen der Literatur vertreten allerdings die Gegenauffassung So f hrt bereits Slongo aus Individualsoftware sei mit nur zufriedenstellender Gebrauchstauglichkeit aon
10. Kapitel 2 Softwareentwicklung in der Praxis Dieser scheinbar so einfach vorgezeichnete Weg ist nicht zuletzt infolge der Komplexit t des zu beschreibenden Ergebnisses der Software nicht so einfach zu verfolgen wie angenommen werden k nnte e Anforderungen und Abnahme Als Ziel der Entwicklung des V Modells wurde die Verbesserung der Softwarequalit t angegeben Was ist nun unter Softwarequalitat zu verstehen Sp testens bei der Abnahme wird der Softwarebesteller zum Ausdruck bringen ob das Gelieferte seinen Vorstellungen vom Vertragsgegenstand entspricht Seine Einsch tzung wird jedenfalls auch von subjektiven Vorstellungen bestimmt sein Formuliert man mit Maymon dass der entscheidende Ma stab f r einen Projekterfolg die Anwenderzufriedenheit ist so wird dieses subjektive Element deutlich Aus diesem Grund wird die klare Definition davon nahegelegt was unter Qualit t zu verstehen ist Zu den Qualit tskriterien werden neben der Funktionserf llung und Benutzerfreundlichkeit die Kriterien Zuverl ssigkeit Wartungsfreundlichkeit und Portabilit t genannt Insbesondere bei den letztgenannten Kriterien handelt es sich um Merkmale die nicht innerhalb kurzer Zeit berpr fbar und daher auch einer Abnahme nur schwer zug nglich sind Dieser Problematik wird im Rahmen des Requirements Engineering dadurch Rechnung zu tragen versucht dass Anforderungen und Abnahmekriterien miteinander verkn pft werden
11. S ist f r die Umsetzung innerhalb der gemeinsam gebildeten Entwicklungsteams verantwortlich falls der Lenkungsausschuss nicht eine abweichende Regelung definiert Die Erstellungsleistung umfasst neben der softwaretechnischen Realisierung des Auftragmoduls eine Stellungnahme ber die sinnvolle Durchf hrung des n chsten Spiralzyklus mit seinen Alternativen 6 Planungsphase Die Planung des Entwicklungsprozesses f r die n chsten Phasen erfolgt nach den gleichen Grunds tzen wie die der Produktentwicklung Der Bestimmung der Entwicklungsziele und der Bewertung ihrer Alternativen folgt die Entscheidung ber das Vorgehen im n chsten Spiraldurchlauf Diese Leistungen werden unter der Leitung von S in enger Zusammenarbeit mit E erbracht Die softwaretechnische Kompetenz des Softwarehauses bringt es nach HE also in eine leitende Rolle die es aber nur bei entsprechender Mitarbeit des Softwarebestellers ausf llen kann Die Art der Formulierung entspricht weit mehr der Festlegung einer Methode als dem gewohnten juristischen Diktus Den Vertragsparteien wird hier eine spezifizierte Leitlinie an die Hand gegeben mit deren Hilfe die Vertragspartner ihr gemeinsames Projekt 150 Kapitel 6 Empirischer Befund in Deutschland abwickeln Dieser Grundidee folgend werden eher Aufgabenbereiche zugewiesen als Pflichten verteilt Bei GL findet sich als gesonderte Pflicht des Softwarehauses unter 10 optional das so genannte Herstellen de
12. der Softwarebesteller ausgerichteten Mustern bzw Praxisbeispielen dar Auch hier zeigt sich ein quer durch die Rechtsordnungen verlaufender Bruch zwischen informationstechnisch f r sinnvoll erachteten und vertraglich vorgesehenen Anforderungen an die Mitarbeit des Softwarebestellers Der Softwarebesteller wird vielfach als Auftraggeber in der Rolle eines bergeordneten Geldgebers gesehen und seine Mitarbeit auf Lippenbekenntnisse bei fehlender konkreter Projekteinbindung reduziert 57 Kapitel 4 A IV 205 Kapitel 7 Vergleichende Darstellung Hier zeigt sich ein weiteres nicht unerhebliches Gefahrdungspotential fur den Projekterfolg Dieses Potential fallt aus deutscher Sicht generell und aus amerikanischer Sicht dann gr er aus wenn an den Interessen der Softwarebesteller orientierte Muster betrachtet werden D Qualitatskriterien Im amerikanischen Recht unterscheiden sich die rechtlichen Vorgaben fur die Einstandspflicht des Softwarebestellers danach ob der U C C angewandt wird oder nicht Allgemein findet sich im Falle seiner Anwendung zun chst eine Regel wonach die Waren goods dann zur Vertragserf llung geeignet sind wenn sie mit den vertraglichen Verpflichtungen obligations under the contract bereinstimmen also die vereinbarte Beschaffenheit aufweisen Dies wird pr zisiert indem Zusagen und Best tigung von Fakten eine Beschreibung Beispiele oder Modelle der Waren eine Einstandspflicht express warran
13. ders BVB EVB IT Computersoftware 6 Aufl Berlin 2003 N Nichols Cyclopedia of Legal Forms Annotated Westlaw Database 2 3191 2002 Savage Diane W Nicklisch Fritz Weick G nter Verdingungsordnung f r Bauleistungen 3 Aufl M nchen 2001 Nicklisch Fritz Kooperation bei Projektvertr gen am Beispiel von Softwareentwicklungsvertr gen FS Traub 1994 S 305 Nolting Roger David Nolte Bernd Application Service Providing WiSt 2004 S 431 Norvis Mark Survival in the Software Jungle Boston 1995 P Palandt Otto Begr B rgerliches Gesetzbuch 64 Aufl M nchen 2005 zitiert Palandt Bearbeiter Plath Kai Uwe Abnahme bei Individualsoftwarevertr gen ITRB 2002 S 98 Primak Scott L Computer Software Should the U N Convention on contracts for the international sale of goods apply Computer Law Journal 1991 S 197 240 Literaturverzeichnis R Raysman Richard Brown Peter Computer Law Drafting and Negotiating Forms and Agreements Lsbl New York 2003 Redeker Helmut IT Recht in der Praxis 3 Aufl M nchen 2003 ders Softwareerstellung im neuen Schuldrecht ITRB 2002 S 202 ders Softwareerstellung und 651 BGB CR 2003 S 88 ders Von Dauerbrennern und neuen Entwicklungen im Recht der Leistungsst rungen Wie sich technische und gesetzgeberische Innovationen auf juristische Diskussionen ausgewirkt haben CR 2005 S 700 Rehmann Wolfgang Herstellung von Individualsoftware
14. geringe Ergebnisvarianz liegt der Schwerpunkt auf der Kontrolle zeitgerechter Leistungserbringung Auch die Regelung des Change Managements orientiert sich in den Praxisbeispielen an der Ergebnisvarianz Wo sie gering ist findet sich keine entsprechende Regelung Ist sie dagegen hoch schl gt sich dies in entsprechenden vertraglichen Bestimmungen nieder Die Muster enthalten mit der benannten Ausnahme der an Softwarehausinteressen orientierten Beispiele alle eine mehr oder weniger ausgefeilte mehrstufige Regelung zum Change Management wobei es Aufgabe des Softwarehauses ist die Auswirkung von nderungen auf Kosten und Zeitplan zu ermitteln Die Einstandpflicht ist bei den Praxisbeispielen von der Ergebnisvarianz abh ngig Bei hoher Ergebnisvarianz wird ein flexibles Kriterium gew hlt w hrend bei geringer Ergebnisvarianz hohe Anforderungen an das Softwarehaus gestellt werden Ist der Softwarebesteller in einer sowohl wirtschaftlich als auch informationstechnisch starken Position so hat er die Ergebnisvarianz in der Hand und kann das Softwarehaus fast wie einen Subunternehmer der eigenen Softwareabteilung einsetzen 97 Kapitel 4 Empirischer Befund in den USA In den Mustern findet sich zur Einstandspflicht ein breites Spektrum von Varianten die von acceptable implementation und perform substantially uber comply with requirements und conform in all material aspects bis hin zu Strict compl
15. 131 58 Madden a a O Fn 562 58 a 58 Ss 58 228 Kapitel 8 Schlussfolgerungen Vergangenheit und Zukunft zu fassen Durch eine gesetzliche Neu Regelung k nnte also Abhilfe geschaffen werden Andererseits hat das BGB Herausforderungen unterschiedlichster Natur bestanden und die Besinnung auf eine generalisierende Betrachtungsweise wird mit guten Gr nden immer noch als geeignete Antwort auf die Vielgestaltigkeit der Dienstleistungsvertr ge verstanden In der angloamerikanischen Diskussion zur Frage ob eine richterrechtliche L sung precedent der gesetzlichen statute vorzuziehen sei wird als Vorteil der ersteren deren Flexibilit t und F higkeit zu Wachstum und Anpassung hervorgehoben Das Recht ndere sich dann im Wege der Evolution und nicht durch Revolution Diese schrittweise Entwicklung erm gliche es zudem auf den richtigen Moment f r eine neue weichenstellende Entscheidung zu warten Die beste L sung werde durch fallbezogene Antworten der Richter gefunden Aus deutscher Sicht d rfen an dieser Stelle zwei Aspekte nicht unbeachtet bleiben Zum einen hat die Rechtsprechung vor allem der Obergerichte zwar eine faktisch bedeutsame Wirkung sie bleibt jedoch v a methodisch deutlich hinter der amerikanischer Entscheidungen zur ck Das OLG M nchen entwickelt seine Begr ndung nicht auf Grundlage eines Urteils des OLG K ln oder auch eines eigenen Urteils sondern z
16. 14 For each calendar day after any due date that Vendor has failed to achieve a task or deliverable Customer at its option shall be entitled to the following payments or credits Delay Credit i for the first fifteen 15 calendar days after each such due date the Delay Credit shall be Five Hundred Dollars 500 00 per calendar day ii for the next fifteen 15 calendar days after the unmet due date the Delay Credit shall be One Thousand Dollars 1 000 00 per calendar day and iii thereafter the Delay Credit shall be Two Thousand Dollars 2 000 00 per calendar day Bei OD findet sich zudem eine Begunstigungsregel wonach das Softwarehaus dem Softwarebesteller die gunstigsten Konditionen anbieten muss The remedial rates charged to Customer shall be the lowest such rates charged any Customer of Vendor for comparable service The rates may be increased annually but to no more than the lesser of a the lowest rates then being charged any Customer of Vendor for comparable service or b five percent 5 of the previous year s rates No additional charges shall be applied for service unless the service and charges are approved in writing by a duly authorized representative of Customer Such charges must be identified in the contract or in a duly executed written change order Vendor must warrant that all prices and charges are the lowest it offers any Customer for comparable products and services AE verpflichtet das Soft
17. 2003 Slater Amy 236 Carter J W Corbin Arthur Linton CORI Corvaglia Stefano Cox Trevor D Literaturverzeichnis Article 2B International Perspectives Journal of Contract Law 1999 S 54 Corbin on Contracts Revised Edition St Paul 1993 Datenbank des Contracting and Organizations Research Institute der University of Missouri Columbia cori missouri edu search Das einheitliche UN Kaufrecht Bern 1998 Chaos versus uniformity the divergent views of software in the International Community Business Law International 2000 359 Dauner Lieb Barbara Heidel Thomas Ring Gerhard Hrsg De Marco Tom Diedrich Kay Dubischar Roland Dumke Rainer E Eckert J rn EDGAR Endler Maximilian Daub Jan Erman Eschbach Andreas Anwaltskommentar BGB Band 2 Schuldrecht Teilband 1 241 bis 610 Monchengladbach 2005 zitiert AnwK Bearbeiter Anwaltskommentar BGB Band 2 Schuldrecht Teilband 2 611 bis 853 Monchengladbach 2005 zitiert AnwK Bearbeiter The Deadline New York 1997 Typisierung von Softwarevertragen nach der Schuldrechtsreform CR 2002 S 473 Grundbegriffe des Rechts Stuttgart Berlin K ln Mainz 1968 Software Engineering 3 Aufl Braunschweig Wiesbaden 2001 AcP 2003 863ff Datenbank der US Securities and Exchange Commission http www sec gov edgar shtml Internationale Software berlassung und UN Kaufrecht CR 1993 S 601 B rgerlich
18. Die Lieferung der Dokumentation ist gem 11 Dokumentation vorgesehen 11 1 Die Dokumentation ist einfach zu erstellen oder per EDV aufzurufen sie darf zum internen Gebrauch beliebig vervielf ltigt werden und umfasst 11 1 1 Die Softwaredokumentation Programmbeschreibungen Handb cher einschlie lich der angepassten und erweiterten Programme die Dokumentation ist so detailliert zu erarbeiten dass anhand der Handb cher eine Programmbedienung durch den geschulten Mitarbeiter m glich ist 11 1 2 Die detaillierte Dokumentation der Gesamtkonfiguration Zur Gesamtkonfiguration geh rt das gesamte Ablageschema der Daten inkl aller Codierungen und Bedeutungen Soweit die Dokumentation nicht durch den entsprechenden Ausdruck der Konfigurationsdateien sichergestellt werden kann bergibt der AN dem AG das gesamte Ablageschema zus tzlich in Papierform ber nderungen des Ablageschemas der Daten informiert der AN den AG unverz glich 11 2 Die Dokumentation ist sp testens 3 Monate nach der Endabnahme vorzulegen und wesentlicher Bestandteil der vertragliche Hauptleistung 59 Diese Gefahr ist u a deswegen gegeben weil die Dokumentation der Codierung sich in Entwicklerkreisen keiner gro en Beliebtheit erfreut 176 Kapitel 6 Empirischer Befund in Deutschland Hier wird erneut deutlich dass der Softwarebesteller vor allem eine Programmbedienung und nicht eine eigene Programmpflege im Sinn hat Der nicht klar er
19. Die bisher dargestellten Methoden und Erfahrungen d rfen nicht zu der Annahme verleiten dass nur die strenge Beachtung ausgefeilter Vorgaben und Entwicklungssysteme zum Ziel f hren kann Es gibt nicht wenige bekannte Beispiele f r erfolgreiche Software CP M MS BASIC MS DOS UNIX Oracle PASCAL Lotus 1 2 3 die nicht unter Verwendung von Software Engineering Methoden und in sehr kleinen Teams entwickelt wurde Dies mag auch an den erheblichen Produktivitatsunterschieden bei in der Entwicklung t tigen Personen liegen Hinsichtlich der Frage wie umfangreiche Software rechtzeitig hergestellt werden kann findet die urspr nglich von Brooks stammende Aussage hinsichtlich des Zusammenhanges der Anzahl von Mitarbeitern und der Projektdauer allgemeine Unterst tzung Danach wird wegen des berproportional ansteigenden Kommunikationsbedarfes durch den Einsatz 88 Etzel Heilmann Richter der daneben auch das Einbeziehen des Betriebsrats empfiehlt a a O S 64 Etzel Heilmann Richter a a O S 76 10 Etzel Heilmann Richter a a O S 78 Franz bemerkt dazu dass eine Demokratie bei der Softwareentwicklung unm glich sei es m sse vielmehr eine Hierarchie geben a a O S 31 Nach Etzel Heilmann Richter das Kongruenzgesetz der Organisation a a O S 26 d h werden projektbezogene Entscheidungen von Personen au erhalb des Projektes beispielsweise einem Lenkungsausschuss getroffen so m ssen diese auch f r die
20. Er mu dar ber hinaus die als Proze zu begreifende Entstehung einer Zieldefinition und die aus der Fl chtigkeit des bearbeiteten Mediums Als Beispiele sind hier zu nennen Planung Beratung berlassung und Pflege im Hinblick auf Software oder EDV Software und Hardware sowie die aus der Praxis entstandenen bzgl ihrer Einordnung noch nicht klar konturierten Outsourcing Hosting Application Service Providing Open Source und Datenbankvertr ge die jeweils ein B ndel von Leistungen enthalten k nnen 6 21n der Einleitung S 2 233 Kapitel 8 Schlussfolgerungen resultierende nderungsanf lligkeit ber cksichtigen Entwicklungsgedanke Auf dieser Grundlage k nnte ein neuer Titel im besonderen Schuldrecht entstehen der auch als Modell f r hnlich gelagerte Konstellationen z B f r Projektvertr ge in Frage kommt Ein bedeutender Teil der vorliegenden Arbeit hat sich mit nderungen mit ihrer vorhersehbaren Unvorhersehbarkeit mit ihren weitreichenden Auswirkungen und mit der einem Paradoxon angen herten Spannung zwischen Wunsch und Wirklichkeit befasst Diese Spannung war Ausgangspunkt und h ufig Triebfeder f r den Versuch die Thematik zu erforschen Sie mag sich auch als Triebfeder f r das Wagnis eines gr eren Entwurfes erweisen zu dem der Autor hofft beigetragen zu haben Als Grundlage f r einen solchen Entwurf k nnen die folgenden Bestimmungen dienen Einzelne Schuldverh ltnisse Titel 8a Software
21. Es ist unglaublich schwierig selbst einfache Konzepte einem anderen Menschen genau mitzuteilen Es soll niemand die seltsamen zwischenmenschlichen Missverst ndnisse untersch tzen a a O S 120 vgl auch Maymon Cave a a O S 85 32 a a O S 66 3 Einige statistische Angaben zu den Erfahrungen in der Praxis siehe unten Kritische Faktoren in der Softwareentwicklung wale Kapitel 2 Softwareentwicklung in der Praxis b Aufwand Unabh ngig von der Gr e des Projektes erfordert die Planungsphase mit dem Teil Ergebnis des Entwurfes eines Pflichtenheftes erheblichen Personaleinsatz Der Aufwand f r die Planung liegt deutlich ber dem der Implementation also der Programmiertatigkeit Bemerkenswert ist dabei die unter dem Stichwort Pareto Prinzip auch in der Softwareentwicklung bekannte Verteilung des Aufwands Nach diesem auch als 80 20 Regel bezeichneten Prinzip lassen sich bei der Automatisierung vieler hnlicher F lle mit 20 des Automatisierungsaufwandes 80 aller F lle n mlich die einfacheren behandeln w hrend f r die komplizierteren 20 der F lle 80 des Automatisierungsaufwandes anfallen Automatisierte F lle Aufwand Wenn der Softwarebesteller also einen Automatisierungsgrad von mehr als 80 anstrebt d h mit der vorgestellten Softwarel sung mehr als 80 der Vor Beginn der Programmentwicklung sind nach Maymon Cave bereits 50 des Gesamtaufwands verbraucht a a O S 73
22. S 75 4 Etzel Heilmann Richter sprechen von einem zwangsl ufigen Nebeneinander von Informations und Kommunikationssystemen unterschiedlichen Alters und Stils a a O S 14 20 Kapitel 2 Softwareentwicklung in der Praxis Die m gliche Route kann also wahrscheinlich nicht v llig frei gew hlt werden Bestehende Handicaps oder Vorgaben schr nken die Wahl des Weges ein Im n chsten und f r diese Untersuchung besonders interessanten Schritt ist die Vorstellung des Softwarebestellers vom Projektziel zu ermitteln zu berpr fen und in ein Anforderungsprofil zu kleiden Das sog Requirements Engineering beschreibt den systematischen Weg von der Projektidee ber die Ziele zu einem vollst ndigen Satz von Anforderungen Am Ende dieser Phase kann somit eine Definition der zu erbringenden Leistung stehen Diese dient als Fahrplan oder Pflichtenheft enth lt idealtypisch die Gesamtheit der f r eine bestimmte Probleml sung ma gebenden Zielvorstellungen Randbedingungen und Bewertungskriterien und stellt das Grundgesetz f r das weitere Vorgehen dar Die aus der Wortwahl ersichtliche Aufmerksamkeit in dieser Entwicklungsphase scheint aus Sicht der Praxis nicht deutlich genug hervorgehoben werden zu k nnen Franz stellt zur Beschreibung des Inhaltes eines Pflichtenheftes pointiert fest Zum Schluss sollte unter allen beteiligten Entscheidungstr gern v llige Einigkeit dar ber bestehen dass
23. Softwareentwicklungsvertrag bezeichneten Dokument SuS unter 1 Gegenstand des Vertrages Hervorhebungen im Original Gegenstand des Vertrages ist die Durchf hrung des folgenden Entwicklungsvorhabens durch den Auftragnehmer f r den Partner Planung Evaluierung und Realisierung der Software X im Folgenden Softwareerstellungsvertrag 173 Kapitel 6 Empirischer Befund in Deutschland Der Gegenstand des Softwareerstellungsvertrages und der genaue Umfang der vom Auftragnehmer durchzuf hrenden Arbeiten sowie gegebenenfalls die Mitwirkungspflicht des Partners ergibt sich aus a dem Pflichtenheft X mit dem Stand vom 23 03 2001 b dem Angebot des Auftragnehmers vom 28 05 2001 c der Auftragsbest tigung des Partners vom 25 07 2001 d der Erg nzungen zum Pflichtenheft mit Stand vom 05 07 2001 Ma geblich ist das Pflichtenheft Auch hier wurden vor Vertragsschluss Schriftst cke ausgetauscht wobei sich aus den Datumsangaben interessante Schlussfolgerungen ergeben Danach hat zun chst das Pflichtenheft als Grundlage f r das Einholen von Angeboten und damit durch den Softwarebesteller erarbeitet vorgelegen Auf dessen Basis hat das Softwarehaus ein Angebot abgegeben woraufhin nderungen am Pflichtenheft vorgenommen und durch den Softwarebesteller eine Auftragsbest tigung bersandt wurde SUS sieht eine ausschlie liche 7 1 MiO Nr 22 und MiN Nr 1 des Source Code Nutzun
24. Ver nderung vorausgesehen h tten so kann Anpassung des Vertrags verlangt werden soweit einem Teil unter Ber cksichtigung aller Umst nde des Einzelfalls insbesondere der vertraglichen oder gesetzlichen Risikoverteilung das Festhalten am unver nderten Vertrag nicht zugemutet werden kann 2 Einer Ver nderung der Umst nde steht es gleich wenn wesentliche Vorstellungen die zur Grundlage des Vertrags geworden sind sich als falsch herausstellen Auch hier ist von einer unvorhergesehen nderung der Umst nde die Rede die zudem schwerwiegend sein muss 54 Dass nicht jede von den Parteien gewollte Vertrags nderung verbindlich ist ergibt sich aus dem Erfordernis der sog consideration ein dem deutschen Recht unbekanntes Prinzip Vereinbarungen sind danach nur dann bindend wenn ihnen grob gesprochen ein Austausch d h ein Geben und Nehmen zugrunde liegt Fehlt es daran wie im Fall von Geschenken so liegt keine einklagbare Schuld vor vgl Hay Peter U S Amerikanisches Recht 2 Aufl M nchen 2002 Rn 298ff Calamari Perillo a a O 4 1 S 168ff und 5 14 S 237ff 535 Dasselbe gilt f r die Parallelnorm im Handelsrecht 2 209 U C C 198 Kapitel 7 Vergleichende Darstellung Anderungen der Anforderungen in Softwareentwicklungsvertragen sind nach den Erfahrungen der Praxis wie sie sich auch in zahllosen Entscheidungen der Gerichte widerspiegeln vorhersehbar Die Vertragsparteien wissen in aller Regel von die
25. Vordergrund Dies gilt sowohl fur die Anpassungsleistungen 1 1 7 SMS Enhancements and Maintenance Team As of the date of this Agreement FDRI employs certain individuals referred to in Exhibit 6 as the SMS Enhancements and Maintenance Team who are and or shall be assigned exclusively to work on enhancements and maintenance for the SMS Product in the following capacities Personnel Rates Per Day Per Person One Team Leader Development Manager ry Two Systems Analysts 5 Six Programmers One Technical Support Person 5 One Product Integrity Testing Quality Assurance Person als auch f r die Neuprogrammierung 1 1 8 1 MAS System Development In consideration of the financial and technical resources committed hereunder by PRODIGY for the development enhancement of SMS FDRI agrees to provide for the development of MAS a level of support equivalent to that identified in Section 1 1 7 above Therefore except where otherwise required or permitted under this Section 1 1 8 1 FDRI shall employ in the requisite positions and at the requisite skill levels eleven 11 individuals who will be 282 Rider Nr 9 263 Schedule A Vendor Specification 264 Siehe soeben im Statement of Work bei AE S 81f 83 Kapitel 4 Empirischer Befund in den USA dedicated by FDRI to the development of the MAS System the MAS Development Team Ill Spezifikationen Alle Vertrage beziehen sich auf technische Anlagen in denen das
26. a a O S 333 5 Suhl Blumstengel in Fischer Herold Danglmayer Nastansky Suhl a a O S 333 Franz a a O S 65 Maymon Cave a a O S 85 die allerdings zumindest einen Teil der Istanalyse erst im Anschluss an die Anforderungsdefinition vorsehen S 50f nicht eindeutig insoweit Love a a O S 125 6 Siehe dazu sogleich unter II nderungen 61 Heinrich a a O S 43 Spee Kapitel 2 Softwareentwicklung in der Praxis Softwarebestellers als zuk nftiger Benutzer wird als wichtiger oder sogar unverzichtbarer Aspekt der Entwicklung eingeschatzt d Voraussetzung f r die Erstellung Zur Erstellung eines verwertbaren Pflichtenheftes m ssen zahlreiche Parameter einschlie lich ihrer Gewichtung gegenseitigen Abh ngigkeit Kosten usw ber cksichtigt werden Als Hindernisse auf dem Weg werden eine Vielzahl von Faktoren genannt Neben unklaren Zielvorstellungen und Sprachbarrieren geh ren dazu st ndig ver nderte Ziele bzw Anforderungen sowie das sog Gold plating Unklare Vorstellungen k nnen leicht aus nicht funktionalen Anforderungen erwachsen Dabei handelt es sich um Anforderungen die nicht die Funktionalit t betreffen wie z B einfache Bedienbarkeit bersichtliche Gestaltung Sie m ssen als Ziele des Softwarebestellers ber cksichtigt werden sollten dann aber m glichst quantifizierbar und damit einer Testbarkeit und Abnahme zug nglich sein Insgesamt wird bei der Formulierung von
27. dass die Software die Anforderungen an Zeitverhalten Ergonomie Fehlertoleranz Wartbarkeit auch durch Dritte und Interoperabilit t erf llt und durch m glichst einfache Schnittstellen mit der angrenzenden Standardsoftware verbunden ist Sicherung der Kompatibilit t zu k nftigen St nden der Standardsoftware Deutsche Praxisbeispiele Software kann nicht mit Sicherheit frei von Fehlern sein aber bei EDV gest tzten Vorg ngen an allen in Beilage 2 definierten Anlagen treten bei typischer Lastsituation zur Tageszeit der gr ten Last in 95 aller F lle Antwortzeiten unter drei Sekunden auf Das System ist so gestaltet dass es leicht erlernt und bedient werden kann die Software wird gem den Programmierrichtlinien des Softwarehauses Beilage 5 erstellt und gewartet es folgen zahlreiche Detailanforderungen funktioneller Art Die gesamte Software ist Jahr 2000 und EURO f hig Die vom System erzeugten Daten sind korrekt soweit das Softwarehaus AN die Stammdaten ordnungsgem angelegt hat und keine Eingriffe in die vom AN gelieferten Systemkomponenten vorgenommen wurden Der Nachweis f r fehlerhafte Berechnungen muss vom Softwarebesteller AG gef hrt werden F r vom AG vorgenommene Eingriffe bernimmt der AN keine Haftung US Muster die Parteibezeichnungen wurden angepasst Development Services and the Software will strictly comply with the descriptions including performance capabilities completeness
28. den Vertragsverhandlungen Angebotsunterlagen und 313 Palandt Heinrichs Rn 1 zu 133 Jauernig Jauernig 133 Rn 7 Wendtland in Bamberger Roth Rn 19 zu 133 Rn 2 zu 157 AnwK Looschelders 133 Rn 2 Erman Armbr ster 157 Rn 2 Soergel Hefermehl 133 Rn 2 M Ko Mayer Maly Busche 133 Rn 19f 314 AnwK Looschelders 133 Rn 3 315 Erman Armbr ster 157 Rn 3 wobei eine Trennung von dem rechtlichen Sollen nach 242 praktisch schwer durchf hrbar ist und die Grenzen daher verschwimmen Soergel Hefermehl 133 Rn 3 36 Erman Palm 134 Rn 42 Soergel Hefermehl 133 Rn 35 317 Erman Palm 133 Rn 41 Soergel Hefermehl verweist daf r auf die Fragw rdigkeit des Indizwertes der Selbstinterpretation der Partei 133 Rn 18 und 35 318 Erman Palm 133 Rn 32 Soergel Hefermehl 133 Rn 25 hnlich steht bei der Auslegung des Gesetzes die ratio legis im Vordergrund Palandt Heinrichs Rn 34 38 Einl vor 1 Soergel Hefermehl Anh 133 Rn 7 in anderen kontinentaleurop ischen Rechtsordnungen sind die Auslegungskriterien fur Gesetze anders als im deutschen Recht ausdr cklich geregelt vgl etwa 6 7 ABGB und Art 12 Codice Civile 319 Palandt Heinrichs Rn 14 Erman Palm 133 Rn 23 Erman Armbr ster 157 Rn 5 Soergel Hefermehl 133 Rn 24 320 Stellvertretend f r diese sog Lehre vom Empfangerhorizont M Ko Mayer Maly Busche 8 133 Rn 10 die dabei
29. hier st nde die Beschaffenheit der Sache im Vordergrund w hrend die F higkeiten des Verk ufers unerheblich blieben Beim Werkvertrag w rde der Unternehmer dagegen gerade wegen 113 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland Unterschiede ergeben sich nach der Schuldrechtsreform nicht mehr hinsichtlich der Voraussetzungen und dem Umfang von Schadensersatz sowie im Grundsatz bei den Voraussetzungen fur das Vorliegen eines Mangels und dessen Rechtsfolgen Eine bedeutsame Ausnahme stellt dabei allerdings das Wahlrecht zwischen Nachbesserung und Neuerstellung dar Im modifizierten Kaufvertragsrecht liegt es gem 439 Abs 1 BGB beim K ufer im Werkvertragsrecht beim Unternehmer Dar ber hinaus kann der Besteller beim Werkvertrag anders als bei modifiziertem Kaufrecht den Mangel selbst beseitigen und den Ersatz der erforderlichen Aufwendungen verlangen 634 Nr 2 BGB Dies bezeichnet Schneider als die wahrscheinlich gef hrlichste Waffe des Bestellers von Software Der bedeutsamste Unterschied ist die Notwendigkeit gem 640 beim Werkvertrag bzw Entbehrlichkeit modifizierter Kaufvertrag der Abnahme An sie sind ein B ndel zentraler Rechtspflichten gekn pft n mlich die F lligkeit der Verg tung 641 BGB der Gefahr bergang 8 644 Abs 1 BGB der Beginn der Verj hrung 8 634a Abs 2 BGB sowie der Gew hrleistungsausschluss bei Mangelkenntnis 640 Abs 3 BGB Mit der Abnahme endet v
30. insoweit nur beschr nkte Regelungen enth lt nicht vorgesehen Dies gilt auch f r die Praxisbeispiele wobei die Tendenz Mitwirkungspflichten zu Gunsten des Softwarebestellers einzuschr nken besonders bei dem Vertrag zur Erstellung von Standardsoftware auff llt 190 Kapitel 6 Empirischer Befund in Deutschland Die Notwendigkeit fur die Regelung von Veranderungen wird teilweise gering eingesch tzt und der Vertragsinhalt f llt dementsprechend kurz aus In einigen Mustern wird in der nderungsregelung im Gegensatz dazu ein Schwerpunkt des Vertrages gesehen Die Initiative f r Ver nderungen soll dabei ganz berwiegend beim Softwarebesteller liegen Es finden sich mehrstufige Verfahren mit zum Teil ausf hrlichen Detailregelungen Dabei zeigt sich ein ausgepr gtes Bed rfnis auch nderungen formal zu erfassen In zwei Praxisbeispielen werden nderungen als selbstverst ndlich vorausgesetzt sollen jedoch nicht in einem umfangreichen Verfahren abgehandelt sondern v a im Rahmen der Wartung durchgef hrt werden Insgesamt zeichnet sich der Wunsch des Softwarebestellers nach einer dauerhaften ber die Softwareentwicklung hinausgehenden Betreuung ab in den Mustern sind Pflege und Wartung entweder nicht vorgesehen oder Gegenstand eines getrennt behandelten Entwurfes Besonderer Wert wird also auf die dauerhafte Sicherung des Auftragszieles gelegt Aus dem Gew hrleistungsma stab l sst sich wenig f r die Leistungsbestimmung entn
31. nnen die Vertragsdurchf hrung und gestaltung sowie die Handelsbr uche spielen Dies gilt vor allem f r die Auslegung sowie das Einbeziehen oder den Ausschluss von Einstandspflichten Die CISG und der UCITA leisten keinen merklichen und verwertbaren Beitrag f r die hier relevanten Fragestellungen Auch die Restatements r cken die Parteivereinbarung und Hilfsmittel daf r wie diese ggf ermittelt werden kann in den Vordergrund Dabei besteht ein weitgehendes Ermessen des Gerichtes f r die Beurteilung von Vertr gen Es erw chst aus einer Erg nzungskompetenz f r Vertragsl cken und dem Ausf llen der unbestimmten Rechtsbegriffe von good faith and fair dealing sowie der unconscionability Die Aus bung des Ermessens muss sich 236 Sie haben m a W das Recht to call forth legal reinforcement of exchange relations Macneil Gudel a a O S 403 siehe auch Calamari Perillo a a O S 4ff 237 Vgl Macneil Gudel a a O S 402ff 57 Kapitel 3 Rechtliche Rahmenbedingungen in den USA allerdings an der Vertragsdurchfuhrung und den Handelsbrauchen orientieren Die H he der Messlatte f r ordnungsgem e Erf llung der Leistungsanforderungen wird in aller Regel durch substantial performance bestimmt In der Rechtsprechung zeichnet sich die Tendenz ab dem Besteller mehr Verantwortung f r das Erreichen des Vertragsziels zu bertragen Je deutlicher es wird dass Softwareentwicklungsvertr ge keine einfachen Austausc
32. nor shall Supplier be entitled to any compensation for work done pursuant to or in contemplation of a Change unless made pursuant to a written Change Order issued by Company and executed by both parties Supplier shall be paid for any work performed in preparing a Change at Company s request OD enth lt keine gesonderte nderungsregelung Vil Zusammenhang zwischen Leistungsbestimmung und Einstandspflicht Wie bei den Vertragsmustern zeigen sich hinsichtlich der Einstandspflicht als Ma f r die geforderte Leistung auch bei den ausgehandelten Vertr gen berraschende Formulierungen Die flexibelste Regelung findet sich bei FP Danach wird eine substantielle bereinstimmung mit den vereinbarten Spezifikationen gefordert 285 Unter Changes in Section Il 28 Auf m gliche nderungen abgezielt ist allenfalls die bereits genannte Regelung unter 5 d wonach Unzul nglichkeiten bei der Spezifikation grunds tzlich nicht zu Lasten des Softwarebestellers gehen 287 Unter 6 2 Performance als Unterpunkt zu 6 Warranties and Representation 93 Kapitel 4 Empirischer Befund in den USA Performance FDRI represents and warrants that as developed and accepted under this Agreement the SMS System Enhancements and Maintenance changes and the MAS System shall substantially perform in accordance with all applicable Exhibits and shall be free of any defects which substantially affect the performance of the SMS System as d
33. r den Auftragnehmer erkennbar dass die Leistungsbeschreibung nach 1 2 oder Anweisungen des Auftraggebers fehlerhaft unvollst ndig nicht eindeutig oder objektiv nicht ausf hrbar sind muss er dem Auftraggeber diesen Umstand sowie die ihm erkennbaren Folgen hieraus unverz glich schriftlich mitteilen und unter 1 14 515 S 0 S 132 145 Kapitel 6 Empirischer Befund in Deutschland Unterrichtung Der Auftragnehmer wird den Auftraggeber ber den Fortgang der Erstellung entsprechend dem Zeitplan unterrichten und dem Auftraggeber auf Verlangen Einsicht in entsprechende Unterlagen und Ausz ge hiervon gew hren sowie insbesondere ihm ein nach 1 1 erste Variante erstelltes Feinkonzept vorlegen GL formuliert hnlich 4 5 Leistungszeit AD 2 3 Der Anbieter unterrichtet den Kunden uber den Fortgang der Arbeiten Sobald er Kenntnis von Hindernissen oder Verz gerungen erh lt welche die fristgem e Leistungserbringung gef hrden teilt er dies dem Kunden unverz glich mit Nach den BVB m ssen u a Informationen zu Projekthindernissen weitere Ausf hrungen enthalten 3 Leistungen des Auftragnehmers Wie 2 a Der Auftragnehmer hat den Auftraggeber nach einem im Erstellungsschein festgelegten Zeitplan Uber den Stand der Arbeiten und die Einhaltung der Anforderungen an die Programme zu unterrichten und Zwischenergebnisse mitzuteilen Dar ber hinaus kann der Auftraggeber Einsicht in die
34. sinnvolle Wahl des Softwarehauses dar Die zentrale Bedeutung der Mitwirkung zeigt sich besonders in der ersten Phase des Projektes wo die zunehmend pr zisere Bestimmung der Leistung aus dem intensiven Zusammenwirken der Vertragsparteien hervorgeht Eine Mitwirkung des Bestellers ist in 643 BGB nur als Nebenpflicht vorgesehen tats chlich bildet sie in Softwareentwicklungsvertr gen jedoch die Grundlage f r die Definition und Ausf hrung der zu erbringenden Leistung Der Projekterfolg im rechtlichen Sinne also die vertragsgem e Erf llung wird am Ende durch den Vergleich von Leistungsbestimmung und Leistungsergebnis gemessen Der Komplexit t der Leistungsbestimmung entsprechend f llt in der Softwareentwicklung auch die Leistungskontrolle aus Die Abnahme findet regelm ig in verschiedenen Stufen statt und ist nicht selten Ausgangspunkt f r weitere w nschenswerte oder notwendige Arbeiten des Softwarehauses F r ein solches Szenario ist die Abnahmeregelung des 640 BGB nicht ausgelegt Das Werkvertragsrecht versagt demnach wenn es von den Parteien bez glich der zu Beginn bei allf lligen nderungen oder bei Abschluss des Leistungen anfallenden 232 Kapitel 8 Schlussfolgerungen Fragen untersucht wird Die erste der oben genannten Moglichkeiten scheidet daher aus Es verbleiben die Optionen einen neuen Vertragstyp oder ein vollstandig neues Softwarevertrags Gesetz ins Leben zu rufen Ein Gesetz das Softwar
35. sowie den f r das jeweilige 178 Auch in der Literatur wird das Thema anl sslich einer geplanten Revision des U C C kontrovers diskutiert Flechtner a a O S 225 226ff 7 Der endg ltigen Entscheidung f r oder gegen die Anwendbarkeit des U C C wird in manchen Konstellationen hier downloadable products auch mit dem Argument ausgewichen es g be hinsichtlich der Rechtsfolgen keinen essentiellen Unterschied zwischen U C C Article 2 und dem Common Law of Contracts SPECHT et al v Netscape Communications Corp amp AOL Inc 306 F 3d 17 US Crt App 2 Circt 1 10 02 Definiert in 1 303 a U C C A course of performance is a sequence of conduct between the parties to a particular transaction that exists if 1 the agreement of the parties with respect to the transaction involves repeated occasions for performance by a party and 2 the other party with knowledge of the nature of the performance and opportunity for objection to it accepts the performance or acquiesces in it without objection Definiert in 1 303 b U C C A course of dealing is a sequence of conduct concerning previous transactions between the parties to a particular transaction that is fairly to be regarded as establishing a common basis of understanding for interpreting their expressions and other conduct 18 oO 18 45 Kapitel 3 Rechtliche Rahmenbedingungen in den USA Gesch ft anerkannten Handelsbr uchen usage of trade D
36. 1530 481 Esser Schmidt a a O 6 VI S 111ff 82 Thewalt a a O S 229 Schneider Handbuch a a O S 1530 Redeker IT Recht a a O S 434 122 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland softwarevertragstypisch echte Schuldnerpflichten dar Wird die Mitwirkung als Schuldnerpflicht verstanden so kann das Softwarehaus aus einem etwaigen Schuldnerverzug Schadensersatzpflichten herleiten Kommt man ber 651 S 3 BGB zur Anwendung des 642 BGB so kann das Softwarehaus demgegen ber nur eine angemessene Entsch digung was den entgangenen Gewinn nicht einschlie t verlangen Um diesbez gliche Unklarheit zu vermeiden wird eine deutliche Benennung der Mitwirkungspflicht empfohlen Das Angewiesensein des Softwarehauses auf die Mitwirkung des Bestellers hat auch in der Rechtsprechung seinen Niederschlag gefunden So erkl rte der BGH die Gestellung kompetenter Mitarbeiter seitens des Bestellers f r den erfolgreichen Abschluss des streitigen Projektes f r erforderlich und sah in ihrem Fehlen eine schuldhafte Mitverursachung der eingetretenen Sch den Es stelle auch eine Verletzung der Mitwirkungspflicht dar wenn der Besteller das Pflichtenheft als notwendige Voraussetzung f r die zu erbringende Leistung dem Softwarehaus auf Anforderung nicht vollst ndig Uberlasse Das LG Frankfurt erblickte eine solche in dem Nichtwahrnehmen der vom Softwarehaus angeforderten Besprechung V
37. 1992 237 238 OLG K ln U v 18 06 93 OLGR K ln 1993 S 237 OLG K ln U v 25 06 93 OLGR K ln 1993 S 270 OLG K ln U v 03 12 93 OLGR K ln 1994 S 13 LG Heilbronn U v 16 12 93 CR 1994 S 281 OLG Saarbr cken U v 22 09 94 BB Beilage 95 Nr 16 S 12 OLG K ln U v 22 09 95 NJW 1996 S 1067 OLG D sseldorf U v 18 07 97 CR 1997 S 732 OLG K ln U v 12 02 99 NJW RR 1999 S 1733 OLG Karlsruhe U v 16 08 02 CR 2003 S 95 118 44 a 44 gt 44 a 44 a 44 44 ao N Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland Wenn dem Pflichtenheft also einerseits eine gro e Bedeutung zuerkannt wird es aber andererseits h ufig nicht oder mangelhaft erstellt wird stellt sich die Frage nach der Verantwortlichkeit f r sein Nicht Vorhandensein 2 Verantwortungszuweisung Zun chst ist klarzustellen ob vertraglich zwischen der Planung und der Ausf hrung unterschieden wurde Wird eine Unterscheidung vorgenommen so beschr nkt sich der erste Teil des Vertrages auf die Erstellung eines Konzeptes f r das weitere Vorgehen Hier liegt es nach einer Auffassung nahe eine Parallele zum Baurecht zu ziehen In der Planungsphase liege die Projektverantwortung beim Besteller in der Erstellungsphase beim Softwarehaus Aus diesem Grundsatz wird auch bei fehlender Phasentrennung der Ansatzpunkt f r die Zuordnung der Verantwortlichkeit gefunden Es sei Aufgabe des Auftraggebers
38. 329 unter ausdr cklicher Bezugnahme auf das Bau und Werkm ngelrecht 454 Ihde CR 1999 S 409 der diese Zuordnung auch mit dem Argument unterstreicht die Informationen k men schlie lich aus dem Verantwortungsbereich des Auftraggebers dabei verweist er auf die Vergleichbarkeit mit dem Bau und Industrieanlagenvertrag Schneider Handbuch a a O S 1479 55 Weick in Nicklisch Weick Verdingungsordnung f r Bauleistungen 3 Aufl M nchen 2001 3 Rn 1 auch im Werkvertragsrecht gelte der Grundsatz dass der Bauherr brauchbare und zuverl ssige Plane und Unterlagen zur Verf gung stellen muss Rn 5 119 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland dazu herleiten Malzer leitet die Verantwortlichkeit des Auftraggebers allgemein aus der Privatautonomie her wonach jede Partei prim r selbst f r die Einbringung ihrer Interessen Sorge zu tragen habe Die Rechtsprechung verortet die Verantwortlichkeit f r das Pflichtenheft ganz berwiegend ebenfalls beim Auftraggeber Es findet sich jedoch auch die Auffassung beide Vertragspartner m ssten an der Erstellung mitwirken wobei der Auftragnehmer die Folgerungen aus der Ist Analyse zu ziehen habe Wurde kein Pflichtenheft erstellt so m sse der Auftragnehmer mit nderungen und Erg nzungen rechnen und auf diese schnell reagieren und es sei ein mittlerer Ausf hrungsstandard geschuldet Dieses Ergebnis f r die Verantwortungszuweisung ist unvoll
39. 4 und 5 Corbin Arthur 2372 13 N 13 gt 13 a 13 a Kapitel 3 Rechtliche Rahmenbedingungen in den USA Bedeutung Daneben tritt fur zwischenstaatliche Vertr ge das UN Kaufrecht das als Federal Law das sonstige State Law einschlie lich des U C C verdr ngt und fur alle Gerichte im Rahmen seines Anwendungsbereiches verbindlich ist Als speziellste Regelung ist schlie lich der ebenfalls als default rule auf den Weg gebrachte Uniform Computer Information Transactions Act UCITA zu nennen B Performance Nach einer dem Anspruchsaufbau des BGB entsprechenden Norm wie 8 631 BGB die eine konkrete dem Vertragstypus zugeordnete Pflicht benennt sucht man im amerikanischen Recht vergeblich Als prim rer Rechtsschutz im Fall von Vertragsverletzung wird Schadensersatz damages angesehen In der Regel wird daher Schadensersatz zugesprochen und nur in Ausnahmef llen auf eine Verpflichtung zur Erf llung des Vertrages specific performance erkannt Specific performance wird demnach nur in einer begrenzten Auswahl von Situationen zugestanden Herstellungsvertr ge construction contracts Linton Corbin on Contracts Revised Edition St Paul 1993 S 76ff Macneil lan R Gudel Paul J Contracts 3 Auflage New York 2001 S 94ff Auch an dem Entwurf und der Weiterentwicklung des U C C v a im Wege der offiziellen Kommentierung ist das American Law Institute ma geblich beteiligt
40. 6 Scheitern des nderungsverlangens Wird ein nderungsverlangen nicht verbindlich so sind die Arbeiten auf der Grundlage der bisherigen Bestimmungen weiterzuf hren VB 22 2 bleibt unber hrt Anm Dort wird dem Softwarebesteller ein K ndigungsrecht gem 649 BGB einger umt Auch bei GL f hrt ein nderungsverlangen des Softwarebestellers zun chst zu einer Pr fungspflicht die in einen weitergehenden und verg tungs pflichtigen Pr fungsauftrag m nden kann Das Softwarehaus hat innerhalb von 30 Arbeitstagen zu pr fen ob das nderungsverlangen mangelhaft ist ob es Anpassungen von Zeitplan oder Verg tung erfordert und welche Auswirkungen es auf derzeitige und anstehende Arbeiten hat Die Vertragspartner haben nachdem die Folgen des nderungsverlangens vom Softwarehaus als vertrags ndernd eingestuft wurden 10 Arbeitstage Zeit um v a Fristen und Termine neu festzulegen Gelingt dies nicht gilt der bestehende Vertrag Auch hier kann der Softwarebesteller eine nderung nur eingeschr nkt erzwingen wobei das Softwarehaus zu fristgerechter Reaktion angehalten werden soll Eine straffere Fristenregelung in einem hnlich formalisierten Verfahren findet sich bei SN B der dabei zwischen kleineren nderungen die das Softwarehaus bestm glich zu ber cksichtigen hat und gr eren nderungen die ein f rmliches nderungsverlangen des Softwarebestellers erfordern unterscheidet 2 4 nderungen Der AN hat i
41. 97 CR 1997 S 732 und OLG Frankfurt U v 03 05 01 OLGR Frankfurt 2001 S 307 Slongo a a O S 31 spricht von einer intensiven gesellschafts hnlichen Zusammenarbeit nach Rehmann Herstellung von Individualsoftware Folgen der Verletzung von Mitwirkungspflichten CR 1989 S 961 ist die Werkleistung mit den Mitwirkungspflichten des Bestellers verflochten vgl auch Malzer a a O S 288 Thewalt a a O S 198 Sobola Dobmeier Gl ckler a a O S 227 Bormuth Ulrich Schmitz Karl Beteiligung der Anwender an der Softwareentwicklung AiB 1993 S 31 Nicklisch Fritz Kooperation bei Projektvertr gen am Beispiel von Softwareentwicklungsvertr gen FS Traub 1994 S 305 Ihde CR 1999 S 409 Schubert Haase ZKM 2003 S 251 So bereits OLG Stuttgart U v 18 10 88 CR 1989 S 589 und zuletzt dem Inhalt nach auch BGH U v 20 02 01 NJW 2001 S 1718 120 45 45 N 45 46 46 O O 46 N 46 ow Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland beispielsweise von komplexen Zusammenhangen und symbiosehaften Abh ngigkeiten und Nicklisch von dem Erfordernis intensiver Kooperation Technik Arbeitsorganisation und Qualifizierung der Mitarbeiter stellten zusammengeh rende und nicht trennbare Teile eines integrierten Planungsprozesses dar Das Softwarehaus und der Besteller m ssten eng und kooperativ miteinander arbeiten Daraus werden f r die Pflichten der Beteili
42. A S 7 28 41 Kapitel 3 Rechtliche Rahmenbedingungen in den USA Ist der Vertragsgegenstand Software so erhebt sich die viel diskutierte Frage nach deren Sacheigenschaft movable thing Bei den Entscheidungen die eine Einordnung von Software als good und damit die Anwendbarkeit des U C C bejahen k nnen zwei Gruppen von Argumenten unterschieden werden Praktikabilit tsgesichtspunkte einerseits und funktionelle berlegungen andererseits Zu den letzteren z hlt zun chst die berlegung dass es sich auch bei einem Vertrag ber Software um einen contract to give handele und die dominierende oder grunds tzliche Verpflichtung darin bestehe etwas zu geben oder zu liefern Dar ber hinaus wird auf das Ergebnis welches vom Programm geliefert wird und nicht auf das Programm selbst abgestellt Das Ergebnis sei gegenst ndlich und nur darauf komme es an Die Sacheigenschaft von Software erg be sich zwangsl ufig aus der Notwendigkeit sie in ein Medium zu Ubertragen Durch das Tr germedium erhalte sie ein tangible home und erst durch die Verk rperung gewinne sie einen Wert Die Verbindung von Medium und Information sei daher unentwirrbar Auf die in das Produkt investierte Arbeit schlie lich komme es nicht an da Arbeit als Dienstleistung in jedem Produkt enthalten sei und daher auch jeder Verkauf von G tern einen hybriden Vertrag darstelle Zu den praktischen Gesichtspunkten geh rt die berleg
43. AiB Arbeitsrecht im Betrieb ALI American Law Institute AN Auftragnehmer Anm Anmerkung AnwK Anwaltskommentar Art Artikel Aufl Auflage Az Aktenzeichen B BauR Baurecht Zeitschrift BB Betriebsberater Zeitschrift Bd Band BGB B rgerliches Gesetzbuch BGH Bundesgerichtshof BGHZ Entscheidungen des Bundesgerichtshofs in Zivilsachen amtliche Sammlung BMI Bundesministerium des Inneren BVB Besondere Vertragsbedingungen BVerfG Bundesverfassungsgericht BvR Aktenzeichen des Bundesverfassungsgerichts f r Verfassungsbeschwerden bzgl bez glich bzw beziehungsweise Cc CAD Computer Added Design CISG Convention on the International Sale of Goods Corp Corporation CORI Contracting and Organizations Research Institute CR Computer und Recht Zeitschrift Crt Court D ders derselbe DFU Datenfern bertragung d h das hei t DIN Norm des Deutschen Instituts f r Normung e V Diss Dissertation Dist District Distr District DV Datenverarbeitung E ECR Entscheidungssammlung zum Computerrecht VIII Dissertation Softwareentwicklungsvertrage Abk rzungen ed edition EDGAR US Securities and Exchange Commission EDV elektronische Datenverarbeitung e g exempli gratia lat for example Einl Einleitung ES Erstellungsschein F ff und folgende Fn Fu note FS Festschrift G gem gem GG Grundgesetz ggf gegebenenfalls GW Gesetz gegen Wettbewerbsbeschr nkungen H HGB Handelsgese
44. Auftraggebers 7 Die Verteilung und Pflege der vom Auftragnehmer gelieferten Versionen der H ndlersoftware geschieht durch den Auftraggeber Cee Der Softwarebesteller hat hier offenbar eigene Kompetenz oder soll sie jedenfalls erwerben und dann in seinem Betrieb fur Aufgabenbereiche wie Schulung und Verteilung der Software zustandig sein Eine Verquickung der Arbeitsbereiche ergibt sich aus Abs 4 wonach das Softwarehaus nach den Anweisungen und Vorlagen des Softwarebestellers t tig werden soll Die bereits bei SUS angetroffene Pflicht zur Informationslieferung wird auch hier als Holschuld begr ndet und dar ber hinaus davon abh ngig gemacht dass es der laufende Betrieb erlaubt Der anschlie ende Satz ist als Feststellung formuliert und allenfalls als Auslegungshilfe f r den Fall hilfreich in dem der Softwarebesteller die Lieferung der Information unterl sst Konsequent w re es insoweit an das Vers umnis einer Mitteilungspflicht konkrete Folgen zu kn pfen wie beispielsweise eine Beweislastzuweisung zum Softwarebesteller f r die Frage des Verschuldens von Leistungsverz gerungen 183 Kapitel 6 Empirischer Befund in Deutschland Bemerkenswert ist hier auch der in Abs 5 anzutreffende Hinweis wonach die Vertragspartner davon ausgehen es wurden gleichsam im Alltagsgeschaft fehlerbereinigte Versionen vom Softwarehaus geliefert Bei MiN werden Pflichten des Softwarebestellers in 7 Mitwirkungspfli
45. BGB W hrend 640 Abs 2 BGB aber auf die Abnahme abstellt kommt es nach 442 Abs 1 BGB auf den Zeitpunkt des Vertragsschlusses ant Im Handelsverkehr also der Regelsituation f r die hier untersuchten Vertr ge m sste bei der Annahme von modifiziertem Kaufrecht zudem die R gepflicht des 377 HGB ber cksichtigt werden Die Anwendbarkeit der Vorschriften des Handelskaufes ist jedoch keineswegs zwangsl ufig wenn der Vertrag dem Regime des 651 S 3 BGB unterstellt wird danach dem Gesetzeswortlaut die Vorschriften ber den Kauf f r anwendbar erkl rt werden es typologisch jedoch bei einem Werkvertrag bleibt Die Typologie des BGB geht in ihrer Systematik konsequent davon aus bei modifizierten Kaufvertr gen w rde die Entscheidungsgrundlage f r den 22 Weick G nter Vereinbarte Standardbedingungen im deutschen und englischen Bauvertragsrecht M nchen 1977 S 188 23 Diese Verj hrung wird von Koch als Drei Plus Verj hrung mit erheblichem Risikopotential f r den Softwareersteller bezeichnet ITRB 2002 S 297 Schmidl will diese Konsequenz vermeiden indem er f r die Sacheigenschaft nach 8 634a BGB einen anderen Ma stab als bei 651 BGB anlegt MMR 2004 S 590 Thewalt h lt die l ngere verschuldensunabh ngige Verj hrung im Falle der unk rperlichen Software als komplexes Gesamtwerk demgegen ber f r angemessen a a O S 256ff Dies f hrt f r noch herzustellende Sachen zu der misslichen Situat
46. Befund in Deutschland Bei GL findet sich dar ber hinaus unter 8 1 Programmierarbeiten die Anforderung eines Standards Soweit nichts anderes vereinbart ist wird das Programm nach dem aktuellen Stand des Software Engineering und den Grunds tzen ordnungsgem er Berufsaus bung erbracht Dies ist insofern interessant als nach den informationstechnischen Methoden der Softwareentwicklung bereits seit geraumer Zeit eine vollst ndige Definition des Leistungsgegenstandes wie sie bei GL im Erstellungsschein vorgesehen ist nicht vorgenommen wird SO verwendet einen hnlichen Ma stab wenn er in 11 Abs 1 ausf hrt 1 Gew hrleistungsumfang Der Lizenzgeber steht daf r ein dass das Lizenzprodukt die Hauptfunktionen im wesentlichen erf llt und den anerkannten Regeln der Technik entspricht sowie nicht mit Fehlern behaftet ist die den Wert oder die Tauglichkeit zu dem gew hnlichen oder nach dem Vertrag vorausgesetzten Gebrauch aufheben oder mindern Dies entspricht dem Wortlaut des berholten 459 Abs 1 S 1 BGB und l sst daher auch eine Hierarchie bzgl der vertraglich vorausgesetzten und der gew hnlichen Verwendung wie sie sich jetzt in 434 Abs 1 S 2 BGB findet vermissen Die ausf hrlichsten Anforderungen finden sich bei BA unter 6 Abstrakte Leistungsvorgaben 1 Die Leistungen auch die Beistellungen des AG nach 5 haben folgenden abstrakten Leistungsvorgaben zu gen gen Stand der T
47. Developer will develop the Technical Design for the Software in accordance with the Scope of Work Developer shall deliver the completed Technical Design on or before date Das Softwarehaus soll demnach auf Basis der Scope of work das technische Design der Software bernehmen Scope of work ist unter 1 definiert als 1 6 Scope of Work means the document attached as Exhibit A to this Agreement that describes the Development Services features functions and specifications of the Software contents of the Documentation and other information necessary to define the work to be performed pursuant to this Agreement Es bleibt offen wer den Inhalt des Scope of work erstellt DS unterscheidet unter 1 ausdr cklich zwei Phasen n mlich die Erstellung der schriftlichen Produktspezifikation und die Entwicklung des Produktes 65 Kapitel 4 Empirischer Befund in den USA Software Development Services a Developer agrees to design and develop the software product s described in the attached Exhibit A the Product s in two phases consisting of the creation of written Product specifications the Specifications and the development of the Product pursuant to the schedule set forth in the attached Exhibit B Die genannte Anlage A ist dann ohne weiteren Inhalt mit Functional Requirements betitelt Wer diese funktionellen Anforderungen formuliert ist im Muster nicht festgelegt Auch bei FL wird das Sof
48. Empirischer Befund in Deutschland notwendigen Umfang Zugang zu Raumen Hard und Software und Telekommunikation 2 Der AG schl gt rechtzeitig Testfalle und Testverfahren vor und bergibt Testdaten Der AN fordert alle Mitwirkungsleistungen des AG rechtzeitig und spezifiziert an Der Eingangssatz enth lt hier einen m glicherweise f r die Auslegung im Streitfall bedeutsamen Grundsatz die nachfolgende Pflichtenbenennung bleibt in ihrem Umfang dabei allerdings begrenzt Vor allem die Angemessenheit der Freistellung von Mitarbeitern d rfte einen regelm igen Anlass f r kontrovers gef hrte Diskussionen bilden Eine weitere Einschr nkung erf hrt die Position des Softwarehauses durch die Gestaltung der Mitwirkungsleistungen als Holschuld nach Abs 2 S 2 Bei MA ist die Mitwirkungspflicht nicht in vergleichbarer Weise relativiert 6 Mitwirkungspflichten 1 Der Anwender ist im Rahmen des Zumutbaren zur angemessen Mitwirkung bei der Programmherstellung verpflichtet Die Mitwirkungspflicht umfasst insbesondere die Bereitstellung der f r die Programmherstellung erforderlichen Informationen DV technischer und projektorganisatorischer Art Hardware und Betriebssysteme eingesetzte Standardsoftware Organisationspl ne sowie gegebenenfalls der Hardware auf der das Programm sp ter eingesetzt werden soll 2 Sofern der Hersteller dem Anwender Entw rfe Programmtestversionen oder hnliches vorlegt werden diese vom Anw
49. Kapitels sollte die Zieldefinition auf der Grundlage kontinuierlicher Abstimmung der Vertragspartner sorgf ltig und mit m glichst geringem nderungspotential erarbeitet und im Verlauf des Projektes festgelegt werden Mit keiner der interessenorientierten Varianten ist diese Vorgehensweise vereinbar In der ersten findet die Zieldefinition zu einem ung nstigen zu fr hen Zeitpunkt statt in der zweiten werden die nderungen gar nicht oder nicht effektiv eingegrenzt In beiden wird dem Kooperationserfordernis keine Rechnung getragen Diese Form der Vertragsgestaltung ist daher nicht nur unausgewogen sondern auch ineffektiv d h ungeeignet den Projekterfolg zu f rdern Unausgewogene Vertr ge bedeuten ein hohes Projektrisiko Sie spiegeln ungleiche Machtpositionen oder ein vermeintliches Verhandlungsgeschick einer Vertragspartei wider nicht jedoch die aus informationstechnischer Sicht erforderlichen Rahmenbedingungen Die zus tzliche Ineffektivit t solcher Vertr ge erh ht dieses Projektrisiko weiter Ein vermeintlicher Verhandlungserfolg bzw die Durchsetzung der eigenen Position kann also leicht in ein Scheitern des Projektes f hren welches zwar m glicherweise durch Haftungsregelungen abgesichert ist aber gleichwohl ein unbefriedigendes Ergebnis langer beidseitiger Bem hungen darstellt Aus Sicht der Projektleitung ist ein guter Vertrag ein solcher der den Projekterfolg beg nstigt und ihm nicht vermeidbare Hindern
50. Lieferstra e 1 11111 Handelshausen zugeschnittene auf der derzeitigen Hardware des Kunden laufende EDV L sung zur Lagerverwaltung zu erarbeiten und einzuf hren BVB 8 3 Leistungen des Auftragnehmers 1 Der Auftragnehmer ist verpflichtet nach Ma gabe des Erstellungsscheines unter Ausnutzung des Standes der Wissenschaft und Technik bei Vertragsabschluss das DV technische Feinkonzept funktionsf hige Programme einschlie lich Dokumentation zu erstellen sowie vereinbarte sonstige Leistungen zu erbringen Wenn der Auftragnehmer erkennt dass die Leistungsbeschreibung Ziffer 1 bis 3 des Erstellungsscheines oder eine Forderung des Auftraggebers zur Vertragsausf hrung fehlerhaft unvollst ndig nicht eindeutig oder objektiv nicht ausf hrbar ist hat er dies und die ihm erkennbaren Folgen dem Auftraggeber unverz glich schriftlich mitzuteilen Der Auftraggeber wird seinerseits unverz glich ber eine nderung der Leistungsbeschreibung 134 Kapitel 6 Empirischer Befund in Deutschland 5 oder seiner Forderungen zur Vertragsausftihrung Nummer 3 entscheiden Hier findet sich der Versuch einen objektivierbaren Leistungsma stab einzufuhren Stand der Wissenschaft und Technik bei Vertragsabschluss Zudem werden die Sorgfaltspflichten des Softwarehauses im Hinblick auf die Prufung der Leistungsbeschreibung des Softwarebesteller konkretisiert SN S 1 Vertragsgegenstand 1 1 Der Auftragnehmer erstellt f
51. Marktteilnehmer mit der Freiheit zur Gestaltung seiner rechtlichen 302 Zuletzt im Nichtannahmebeschluss des BVerfG vom 4 August 2004 Az 1 BvR 1557 01 Orientierungss tze 1b und 1c m w Nachw Wenn Coing die Worte Equal Justice under Law als gleichbedeutende Regel f r deutsche und amerikanische Richter kennzeichnet Staudinger Coing a a O Rn 213 so sollte freilich deutlicher werden was in den Vereinigten Staaten gemeinhin unter Law verstanden wird n mlich das Recht einschlie lich des Case Law als seiner bedeutendsten Quelle 303 Staudinger Coing a a O Rn 229ff 34 Nicht ber cksichtigt werden hier die im Zusammenhang mit dem zentralen Thema der Urheberrechte stehenden Regeln aus dem UrhG sowie Einzelfragen aus dem Bereich des GWB 305 Art 74 Abs 1 Nr 1 72 GG 306 Flume Vom Beruf unserer Zeit f r Gesetzgebung in ZIP 2000 S 1427 1429 100 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland Beziehungen ausgestattet werden Die Privatautonomie erlaubt es das Ob Abschlussfreiheit und Wie Inhaltsfreiheit der Vertr ge zu bestimmen Soweit der Inhalt an Grenzen st t etwa durch die 305ff BGB sind Kaufleute und um solche wird es sich bei den Vertragspartnern von Softwareentwicklungsvertr gen ausnahmslos handeln weniger schutzw rdig als Verbraucher Das zwingende Recht tritt gegen ber der autonomen Einsch tzung von Chancen und Risiken durch den Unternehme
52. OD das angestrebte Ergebnis als klar voraussehbar beurteilt wird geht FP von einer Pr zisierung im Projektverlauf aus Bei AE kommt die starke wirtschaftliche Stellung des Softwarebestellers insofern zum Tragen als dem Softwarehaus die Rolle eines Zuarbeiters zugewiesen wird der vom Besteller definierte Funktionen erf llt Diese tendenzielle Ausrichtung spiegelt sich auch in den Mustern wieder Die an den Interessen des Softwarehauses orientierten Muster unterscheiden sich in den entscheidenden Punkten grundlegend von denen die sich an den Interessen des Softwarebestellers ausrichten So verlangen die letztgenannten Muster eine weitgehende bernahme von Beratungspflichten die von der Bedarfsanalyse bis hin zur Bedarfsermittlung durch das Softwarehaus reicht Auch die Einflussnahme auf Personalentscheidungen ist hier sehr weitgehend ausgestaltet Umgekehrt verzichten die am Interesse des Softwarehauses orientierten Muster etwa vollst ndig auf ein Change Management und verlangen vom Softwarebesteller Pr fungen der erbrachten Leistungen die ein erhebliches Know How voraussetzen 291 Purchase Agreement Nr 3 292 Unter 2 2 1 223 Section II Audit 2 Diese etwa aus der Differenz von Einkaufs und Verkaufs AGB bekannte Differenzierung ist aus Sicht des parteiischen Rechtsberaters eines der Beteiligten selbst verst ndlich kann jedoch zu erheblichen Friktionen bei der Vertragsverhandlung f hren da sie nicht v
53. Peter U S Amerikanisches Recht 2 Aufl M nchen 2002 Heinrich Lutz J Systemplanung 6 Aufl M nchen Wien 1994 Heppner Henning Softwareerstellungsvertr ge Diss K ln 1997 Herr Robert Anm zu LG Karlsruhe U v 13 05 1991 10 O 458 89 CR 1992 S 342 Hilty Reto Der Softwarevertrag Ein Blick in die Zukunft MMR 2003 S 3 Hoeren Thomas Software berlassung als Sachkauf Diss M nster 1989 l Ihde Thomas Das Pflichtenheft beim Softwareerstellungsvertrag CR 1999 S 409 238 J Jauernig Othmar Hrsg K Karger Michael Kargl Herbert Koch Frank ders Kottof Jost Kohler Helmut Krau Wolfgang L Levine Howard A Love Tom M Literaturverzeichnis BGB Kommentar 11 Aufl M nchen 2004 zitiert Jauernig Bearbeiter Kooperation bei komplexer Softwareentwicklung Konsequenzen unzureichender vertraglicher Regelung der Zusammenarbeit ITRB 2004 S 208 Management und Controlling von IT Projekten Munchen Wien 2000 Kaufrechtliche Vorgaben fur Vertrage zur Softwareerstellung ITRB 2002 S 297 Computer Vertragsrecht 6 Aufl Freiburg 2002 Softwareerstellungsvertrage nach der Schuldrechtsreform K amp R 2002 S 105 Rechtsfragen zum Softwarevertrag CR 1987 S 827 Die Auswirkungen der Schuldrechtsreform auf Softwarevertrage Diss Munster 2004 Hugh R Jones Lecture at Albany Law School 67 Albany Law Rev Alb L Rev S 1 T cke des Projekts Object L
54. Projektleiter kaum in hnlich berzeugender Weise von seinem Vorhaben abgebracht werden Selbst nderungen grundlegender Art werden vor diesem Hintergrund nicht selten akzeptiert Die nicht auf ein Dauerschuldverh ltnis mit allf lligen nderungen ausgerichteten in Betracht gezogenen Vertragstypen im deutschen Gesetz bieten kaum Hilfestellung Um so gr ere Bedeutung f llt daher der vertraglichen Gestaltung zu und um so erstaunlicher ist die unbefriedigende Ernte die nach dieser Untersuchung hier konstatiert werden muss Das zuvor beschriebene Element der gemeinschaftlichen Projektabwicklung legt es nahe notwendige und vor allem einseitig w nschenswerte nderungen als gemeinsames Anliegen zu betrachten Wirtschaftlich unabdingbar wird eine dementsprechende Interessenabstimmung dann wenn es wie in nahezu allen deutschen Vertragsmustern eine Festpreisvereinbarung gibt In diesem Fall ist das Softwarehaus darauf angewiesen den Auftragsumfang sorgf ltig mit der Verg tung abzustimmen wenn es wirtschaftlich berleben will Es ist daher in seinem ureigensten Interesse nderungen etwa im Hinblick auf eine Reduzierung des Leistungsspektrums selbst ansto en und unkalkulierbare bzw kalkulierbar nicht realisierbare nderungen verhindern zu k nnen Eine entsprechende vertragliche Regelung ist nicht nur im Sinne des Softwarehauses sondern auch im Sinne des Softwarebestellers Hier sollte die Aussage aus dem zweiten Kapitel bedacht werde
55. Softwareingenieurs steht die Fixierung der Kundenanforderungen in einem Pflichtendokument insbesondere f r zuk nftige Konflikte im Mittelpunkt des Interesses Die Einsch tzung der Bedeutsamkeit und Konsequenzen in der Projektpraxis fallen deutlich auseinander Anschaulich wird dieser Befund bei Betrachtung der bis in j ngste Zeit reichenden Judikatur die F lle zu beurteilen hatte in denen ein Pflichtenheft schlicht nicht erstellt wurde W hrend also die Juristen vor allem aus einer ex post Betrachtung nicht m de werden die Bedeutung sorgf ltiger Anforderungsdefinitionen zu betonen scheinen die am Projektgesch ft Beteiligten h ufig auf eine entsprechende Fixierung zu verzichten 2 Koch Frank A Computervertragsrecht 6 Aufl Freiburg 2002 Rn 12 der auch von der vertraglichen Beschreibung des Lieferumfanges spricht vgl auch http de wikipedia org wiki Pflichtenheft und Software_Requirements_Specification So beispielsweise in der DIN 69901 die Begriffe des Projektmanagement definiert oder in der Norm des Institute of Electrical and Electronic Engineers IEEE zur Software Requirement Specification SRS in der Version Std 830 1998 Eine Ausnahme ist beispielsweise aus j ngster Zeit der Beitrag von S bbing Die Bedeutung der ITIL f r die Vertragsgestaltung ITRB 2005 S 97 zu der IT Infrastructure Library kurz ITIL wo der Autor ausdr cklich darauf hinweist dass der Verweis auf technisch ausgele
56. Territorien mit Ausnahme von Lousiana bernommen worden was jedoch wegen selbst ndiger Interpretation und Umsetzungsvarianten nicht notwendig zu einer einheitlichen Rechtslage f hrt vgl Blumenwitz Einf hrung in das anglo amerikanische Recht 7 Aufl M nchen 2003 S 48 Fn 13 F r einen Common Law Juristen kann bereits die Zweckm igkeit der Unterscheidung von ffentlichem und privatem Recht fraglich oder zumindest nicht zwingend sein Merryman John Henry Western European and Latin American Legal Systems a a O S 800ff die praktische Bedeutung dieser Betrachtungsweise zeigt sich z B im amerikanischen unified judicial system das die dem Civil Law System gel ufige Unterscheidung von Verwaltungs und Ordentlicher Gerichtsbarkeit nicht kennt Merryman The Civil Law Tradition Sec ed Stanford California 1985 Im Uniform Commercial Code sind u a Kauf U C C ARTICLE 2 SALES Miete U C C ARTICLE 2A LEASES und Darlehen U C C ARTICLE 3 NEGOTIABLE INSTRUMENTS geregelt nicht jedoch z B Dienst und Werkvertrag Der Uniform Commercial Code wurde der ffentlichkeit durch die National Conference of Commissioners on Uniform State Laws erstmals 1952 vorgestellt jedoch zun chst nur in Pennsylvania in geltendes Recht transformiert Nach ausgiebigen nderungen in den folgenden Jahren wurde der U C C zwischen 1957 und 1967 in allen Staaten eingef hrt Nur Louisiana beschr nkte sich auf die Einf hrung der Art 1 3
57. Unterbreitet der AN ein Angebot innerhalb einer angemessenen Frist so kann der AG entscheiden ob er dieses Angebot annehmen will oder nicht Er hat dies binnen einer Frist von zehn Kalendertagen wahrzunehmen Erfolgt innerhalb dieser Frist keine Antwort des AG gilt das Angebot als abgelehnt 2 4 3 Nimmt der AG das Angebot an wird die nderung Bestandteil dieser Vereinbarung und der Terminplan entsprechend erg nzt Die nderung wird auch bei allen brigen Unterlagen ber cksichtigt 2 4 4 F r die Pr fung des nderungswunsches kann der AN wenn er dies bei seiner Antwort binnen einer Woche entsprechend angek ndigt hat und f r die Ausarbeitung entsprechender Unterlagen insbesondere Erg nzungs Pflichtenhefte eine Verg tung verlangen Diese Verg tung erfolgt grunds tzlich nach Zeitaufwand wenn nichts anderes zwischen den Parteien vereinbart wird Die Berechnung erfolgt auf der Basis eines Stundensatzes gem dem in der Anlage 3 beigef gten Preisblatt Der AN wird entsprechende Zeitnachweise f hren und sich diese als Regiearbeiten vom AG zeitnah abzeichnen lassen Die gleichzeitige Vorlage abgezeichneter Regiezettel Zeitnachweise ist Voraussetzung f r einen Zahlungsanspruch und nicht nur f r die F lligkeit 2 4 5 Zeigt sich w hrend der Bearbeitung des nderungswunsches gleich in welchem Stadium dass es sich tats chlich nicht um einen nderungswunsch sondern um einen Fehler des Pflichtenheftes oder der sonstigen Ausa
58. Verf gung stellen Dass bei BA der Softwarebesteller AG und nicht das Softwarehaus AN origin r die Fehlbeseitigung vornimmt der AN unterst tzt bei der Fehlbeseitigung nach Abs 2 lediglich ist hier nicht ohne weiteres nachvollziehbar Die Abgrenzung von nicht verg tungspflichtiger Gew hrleistung und verg tungspflichtiger Softwarepflege weist keine deutlichen Konturen und im Zusammenhang mit der Gew hrleistungs regelung in 30 Abs 5 eine erhebliche Komplexit t auf Keines der Muster sieht eine Regelung f r die Fehlerbehandlung im laufenden Projekt d h insbesondere vor der Abnahme vor Dies ist aus juristischer Sicht verst ndlich da ein Fehler i S eines Mangels eine erbrachte Leistung voraussetzt In der Softwaretechnik hingegen ist die 517 BA unterscheidet in 21 drei Klassen Betriebsverhindernde Fehler Klasse 1 betriebsbehindernde Fehler Klasse 2 und Sonstige Fehler Klasse 3 518 M glicherweise handelt es sich auch lediglich um einen Druckfehler 519 In 30 Abs 5 S 2 BA hei t es zu der Gew hrleistungsfrist Die Frist wird f r Anspr che aus Sachm ngeln auch durch eine Fehlermeldung gehemmt bis die Fehlerbeseitigung abgenommen ist 25 Abs 3 Bei einem Fehler der Klasse 1 betrifft die Hemmung das ganze Teilprojekt Im brigen gilt 203 BGB F r jeweils 4 Fehler der Klasse 1 verl ngert sich die Frist um drei Monate 149 Kapitel 6 Empirischer Befund in D
59. Zeitpunkt schriftlich die nderung der im Erstellungsschein festgelegten Anforderungen an die Programme verlangen Der Auftragnehmer hat die ge nderten Leistungen auszuf hren soweit sie ihm im Rahmen seiner betrieblichen Leistungsf higkeit nicht unzumutbar sind Sofern der Auftragnehmer nicht innerhalb von 21 Kalendertagen ab Zugang des nderungsverlangens die nderung als unzumutbar ablehnt oder ein Pr fung nach Absatz 2 geltend macht hat der Auftragnehmer die nderung durchzuf hren Erfordert das nderungsverlangen vom Auftragnehmer eine umfangreiche Pr fung ob und zu welchen Bedingungen die nderung durchf hrbar ist so kann er hierf r eine Verg tung insoweit verlangen als er den Auftraggeber schriftlich darauf hingewiesen und der Auftraggeber daraufhin den Pr fungsauftrag schriftlich erteilt hat die Frist bis zu deren Ablauf dem Auftraggeber das Ergebnis der Pr fung schriftlich mitgeteilt sein muss ist einvernehmlich festzulegen 2 Beeinflusst die nderung einer Leistung oder eine Forderung zur Vertragsausf hrung vertragliche Regelungen z B Preis Ausf hrungsfristen Abnahme wird unverz glich die durch die nderung bedingte Anpassung im Erstellungsschein unter Ber cksichtigung entstehender Mehr oder Minderaufwendungen vereinbart Sofern der Auftragnehmer die Anpassung des Erstellungsscheines nicht innerhalb von 21 Kalendertagen nach Zugang des nderungsverlangens oder bis zum Ablauf der Frist gem Nummer 1
60. Ziele der AG mit seiner neuen Software verfolgt und welche strategischen Ziele hierdurch wieder realisiert werden sollen z B produktionssynchrone Belieferung Die Arbeiten des AN haben zu einem Pflichtenheft in Verbindung mit einem Terminplan mit relativen Terminen als Ergebnis gef hrt Der AN hat in der Zwischenzeit ein Auswahlverfahren f r die geeignete Hardware und Betriebssysteme sowie Datenbankumgebung durchgef hrt und eine entsprechende Auswahl bereits getroffen Diese Ma nahmen sind Grundlage dieses Vertrages Werden diese Ausf hrungen v a im Lichte der Kenntnis der rechtlichen Rahmenbedingungen aus Kapitel 5 n her betrachtet so wird deutlich warum die Pr ambel in SN S nicht enthalten ist Das Softwarehaus erkennt hier an vollst ndig ber die Gegebenheiten und Ziele des AG informiert zu sein Das hohe Risiko eine technische oder betriebliche Rahmenbedingung bersehen oder unzutreffend bewertet zu haben liegt 511 Die Allgemeinheit der Formulierung lie e es zu diese Pr ambel mit geringf gigen nderungen in einer Vielzahl von F llen aufzunehmen 132 Kapitel 6 Empirischer Befund in Deutschland damit alleine beim Softwarehaus Es wird mit dem Vortrag etwas nicht gewusst zu haben im von Dritten beurteilten Streitfall kaum Geh r finden Die Pr ambel bei GL hat einen neutraleren Inhalt 1 1 Anbieter Der Anbieter ist eine Softwarefirma die sich spezialisiert hat auf die Entwickl
61. a O S 58 Rupp a a O S 20f nach Maymon Cave ist es danach erforderlich gut kontrollierte nderungen bei den Benutzeranforderungen einzukalkulieren a a O S 32 88 Er beschreibt dies als Gegensatz zu Hardware wie Computern oder Autos Mythos S 102 Nach Brooks zeigt alle Erfahrung mit gro en Projekten dass man das erste Ergebnis nicht gebrauchen kann und es von Anfang an f r den Abfalleimer bestimmen sollte Mythos S 102 Love spricht sogar davon dass regelm ig zweimal damit zu rechnen ist Entwicklungen wieder wegzuwerfen wobei Wiederholungen den kompletten Entwicklungszyklus von Anforderungsanalyse bis Kundenabnahme umfassen a a O S 239 An existing system does more to clarify needs than any number of abstract definitions Fisher a a O S 40 ebenso Etzel Heilmann Richter a a O S 68 vgl auch Suhl Blumstengel die im Oberfl chenentwurf eine sehr gute Unterst tzung f r die Entwicklung sieht aus der jedoch auch h ufig nderungen im Sollkonzept resultieren in Fischer Herold Danglmayer Nastansky Suhl a a O S 377 Eschbach geht davon aus dass Prototypen i d R weggeworfen werden und daher auch niemals als Grundlage f r das eigentliche Programm dienen sollten a a O S 128ff 5572 89 91 Kapitel 2 Softwareentwicklung in der Praxis Dies ist im hier interessierenden Zusammenhang der Leistungsbestimmung auch deswegen besonders wichtig weil konzeptionelle Fehler d h solche d
62. aktive Ermittlung von Informationen durch das Softwarehaus als selbstverst ndlich betrachtet Es zeichnet sich allerdings in j ngerer Zeit die Tendenz ab das Bestehen dieses Gef lles nicht mehr grunds tzlich anzunehmen sondern vielmehr softwarespezifische Erfahrungen auch beim Softwarebesteller vorauszusetzen 54 642 BGB Mitwirkung des Bestellers 1 Ist bei der Herstellung des Werkes eine Handlung des Bestellers erforderlich so kann der Unternehmer wenn der Besteller durch das Unterlassen der Handlung in Verzug der Annahme kommt eine angemessene Entsch digung verlangen 2 Die H he der Entsch digung bestimmt sich einerseits nach der Dauer des Verzugs und der H he der vereinbarten Verg tung andererseits nach demjenigen was der Unternehmer infolge des Verzugs an Aufwendungen erspart oder durch anderweitige Verwendung seiner Arbeitskrafterwerben kann 8 643 BGB K ndigung bei unterlassener Mitwirkung 1 Der Unternehmer ist im Falle des 642 berechtigt dem Besteller zur Nachholung der Handlung eine angemessene Frist mit der Erkl rung zu bestimmen dass er den Vertrag k ndige wenn die Handlung nicht bis zum Ablauf der Frist vorgenommen werde 2 Der Vertrag gilt als aufgehoben wenn nicht die Nachholung bis zum Ablauf der Frist erfolgt 545 Siehe auch oben Kapitel 5 V 546 S o Kapitel 3 D Il Kapitel 5 II 5 b 204 Kapitel 7 Vergleichende Darstellung Gleichwohl legen die Gerichte in Deutschland ausgepragter
63. alle Muster die Verpflichtung des Softwarehauses eine funktionsf hige Software bereitzustellen In vier der sieben Muster sind nach dem Vorstehenden neben der Software selbst ausf hrliche Dokumentationsunterlagen an den Softwarebesteller auszuh ndigen In einem Muster wird der diesbez gliche S o S 61 64 Kapitel 4 Empirischer Befund in den USA Lieferumfang der genaueren Bestimmung durch die Vertragspartner berlassen In den Softwarehaus orientierten Mustern muss neben der Software selbst nur in geringem Umfang DaS V bzw kein weiteres Material RB V zur Verf gung gestellt werden Ill Spezifikationen Bis auf RB V das die Entwicklung auf der Basis von bereits existierender Software auf Seiten des Softwarehauses vorsieht gehen alle Muster von einem mehrstufigen Verfahren zur Bestimmung des Vertragsinhaltes aus Dies besteht theoretisch aus drei Schritten Zun chst werden die Anforderungen an die Software formuliert Diese Beschreibung wird in ein m glichst pr zises Anforderungsprofil transformiert und schlie lich im letzten Schritt programmtechnisch umgesetzt Wer im Rahmen dieser Vorgehensweise welche Pflichten bernimmt ist unterschiedlich geregelt Bis auf RB V gehen alle Muster davon aus dass das Softwarehaus f r den zweiten Schritt die Transformation des W nschenswerten in Machbares verantwortlich ist Die Details werden im folgenden dargestellt Bei AS hei t es unter 2 2 Technical Design Phase
64. als in den USA gro e Zur ckhaltung an den Tag wenn es darum geht die Notwendigkeit eines aktiven Parts des Softwarebestellers anzuerkennen Dies spiegelt sich auch in den Mustern wieder Die an den Interessen des Softwarebestellers orientierten amerikanischen und deutschen Muster verlagern das Risiko einer seitens des Softwarebestellers unerw nschten Leistungsbestimmung weitestgehend auf das Softwarehaus Mitwirkungspflichten finden sich nur in den an den Interessen des Softwarehauses orientierten amerikanischen Mustern und in einem Praxisbeispiel In den deutschen Mustern und Praxisbeispielen ersch pft sich die Pflicht des Softwarebestellers ganz berwiegend im Bereitstellen von technischen Ressourcen W hrend die deutschen Muster und Praxisbeispiele Personalfragen also z B welche Mitarbeiterqualifikationen verlangt und v a wie sie aufrecht erhalten werden ganz berwiegend keine Bedeutung beimessen werden sie bei den softwarebestellerfreundlichen amerikanischen Mustern eingehend geregelt Mitwirkungspflichten sind also in beiden Rechtsordnungen vorgesehen und in verschiedenen Gerichtsentscheidungen konkretisiert Vom Softwarebesteller wird allerdings nur dann eine aktive Rolle verlangt wenn dies ausdr cklich vertraglich vereinbart wurde und er ber ausreichendes Know How verf gt Diese Tendenz ist im deutschen Recht ausgepr gter als im amerikanischen Besonders auff llig stellt sie sich in an den Interessen
65. bzw bez glich des Untersuchungsgegenstandes ihr die M glichkeit er ffnen neue Wege zu gehen und dies im gesamten Bundesgebiet und f r alle Gerichte Bisher ist eine Trendwende soweit ersichtlich nicht erkennbar Die Entwicklung ist jedoch offen d h wie in den USA kann eine zuverl ssige Prognose ber die Rechtsgrundlagen die einer gerichtliche Entscheidung als Basis dienen werden nicht getroffen werden W hrend der Grund hier in einer Gesetzes nderung die neue Subsumtionsm glichkeiten er ffnet zu suchen ist liegt er dort in der bisher uneinheitlichen Entscheidungspraxis Die Grundvoraussetzungen f r die Softwareentwicklung aus informationstechnologischer Sicht wurden im Kapitel 2 ausf hrlich dargelegt F r dieses Kapitel sind zun chst die dort gewonnenen Erkenntnisse fruchtbar zu machen Dies geschieht im Folgenden anhand der Ausgangsfrage ob und ggf wie die Vertr ge und Muster die Vorgaben des Software Engineering ber cksichtigen Im Einzelnen 1 Wird ein pr zises Ziel vorgegeben und wie geschieht dies ggf 2 Ist ein Reaktionsmechanismus f r einen Wandel der Anforderungen vorgesehen und ggf in welcher Form 3 Wird die Mitarbeit des Softwarebestellers sichergestellt und ggf auf welche Weise 4 Werden angemessene Qualit tskriterien f r die Beurteilung der Leistung gew hlt und wird dabei insbesondere die mangelnde Eignung der Fehlerfreiheit ber cksichtigt 530 Vor diesem Hintergrund werden
66. den Preis eingerechnet werden m ssen 140 Kapitel 6 Empirischer Befund in Deutschland Punkte soweit erforderlich detailliert festschreiben Ab Fertigstellung des ausgearbeiteten Pflichtenhefts wird dieses als Anlage zum vorliegenden Vertrag gef hrt Bei GL findet sich wie bei KO eine Option wonach das Softwarehaus die Erstellung des Pflichtenhefts bernehmen kann Vorausgesetzt wird dabei allerdings das Vorliegen einer Aufgabenstellung des Softwarebestellers Wie bei KO ist eine Abnahme und eine R gepflicht vorgesehen Nr 7 Erstellung des Pflichtenheftes 7 1 Erstellung 1 Falls dies im Erstellungsschein ES 1 2 vorgesehen ist erarbeitet der Anbieter ein Pflichtenheft Grundlage ist die Aufgabenstellung des Kunden 2 Das Pflichtenheft beschreibt den Ist Zustand der derzeitigen EDV L sung und den Soll Zustand der zu entwickelnden EDV L sung einschlie lich des Soll Zustandes nach etwa vereinbarten Zusatzleistungen N heres regelt der Erstellungsschein ES 4 1 Der Anbieter gew hrleistet Richtigkeit und Vollst ndigkeit des Pflichtenheftes 3 Der Kunde ist zur zumutbaren Mitarbeit verpflichtet 4 Falls und soweit bei der Ausarbeitung des Pflichtenheftes das Bed rfnis zu einer Anpassung der vertraglichen Regelungen insbesondere des Zeitplans nach Erstellungsschein Verg tung nach Erstellungsschein oder Funktionspr fung nach Erstellungsschein erkennbar wird entscheiden die Vertragspartner einvernehmli
67. denen es ausgeschlossen ist wobei eines davon die Option der Ablehnung beinhaltet 536 Dies schlie t nicht aus dass sich im Einzelfall die Umst nde dergestalt ndern dass eine Anpassung nach den genannten Vorschriften verlangt werden kann Es handelt sich dann jedoch nicht um eine Frage der Leistungsbestimmung sondern einen allgemeinen Grundsatz der nicht Gegenstand dieser Untersuchung ist 199 Kapitel 7 Vergleichende Darstellung Das Verfahren f r nderungen folgt ganz berwiegend diesem zeitlichen Schema Verlangen T des Softwarebestellers von nderungen und ggf Teil Arbeitsstop l Pr fung des nderungsverlangen durch das Softwarehaus und ggf Teil Arbeitsstopp Ggf Mitteilung von Kostenpflichtigkeit der Pr fung des Anderungsverlangens durch das Softwarehaus Ggf Entscheidung des Softwarebestellers ber Durchf hrung der Pr fung Mitteilung durch das Softwarehaus ber Auswirkungen der nderung auf Kosten und Fristen Entscheidung des Softwarebestellers ber Durchf hrung der Anderung und ggf entsprechende Vertragsanpassung 200 Kapitel 7 Vergleichende Darstellung Eine vergleichende Ubersicht zu den Anderungsmechanismen ist der folgenden Tabelle zu entnehmen Merkmal des Deutsch US Anderungsverfahrens Muster Beispiele Muster Beispiele Vorhanden 7 3 4 2 Unterscheidung zwischen gro en und klei
68. der Informationstechnologie darstellt geschehen Zunachst ist also aus softwaretechnischer Sicht die Frage zu beantworten unter welchen Grundvoraussetzungen ein Softwareprojekt durchgefuhrt wird und welche Fragestellungen und Rahmenbedingungen sich daraus fur die rechtliche Perspektive ergeben Kapitel 2 Softwareentwicklung in der Praxis Kapitel 2 Softwareentwicklung in der Praxis A Theorie des Softwareengineering I Einf hrung Die Bestimmung der Leistungspflicht die f r den Vertragsjuristen einen zentralen Ausgangspunkt f r den Vertragsentwurf darstellt ist aus Sicht der Wissenschaft die sich mit der Softwareentwicklung befasst und aus Sicht der Systementwickler ein hochkomplexer Prozess Softwareentwicklung vollzieht sich danach in bestimmten definierten Schritten Die Planungsphase in der die Leistungsbestimmung ihren Ausgangspunkt hat vollzieht sich ihrerseits in verschiedenen Abschnitten die das Ziel der Softwareentwicklung und den Weg dorthin in eine zunehmend genauere Form f gen Heinrich unterteilt die Systemplanung wie aus der folgenden Grafik ersichtlich 8 Etzel Heilmann Richter definieren IT Projekte als einmalige Vorhaben mit hoher Komplexit t die innovatives Vorgehen erfordern deren Start und Ende terminiert deren Ressourcen begrenzt und die mit Risiken verbunden sind IT Projektmanagement Heidelberg 2000 S 3 die Unbeherrschbarkeit der Komplexit t der Softwareentwicklu
69. die Referenz in Zweifelsfallen und den allein verbindlichen Rahmen fur die gerichtliche Beurteilung darstellt Auch die obergerichtliche Rechtsprechung entfaltet keine Bindungswirkung wobei in der Praxis gleichwohl die faktische Orientierung vor allem an den h chstgerichtlichen Entscheidungen eine ma gebliche Wirkung aus bt Eine Grundlage f r das deutsche Vertragsrecht bildet die Privatautonomie also das Recht der Vertragspartner autonom und damit prinzipiell unber hrt von staatlicher Einflussnahme ber ihre privaten Verh ltnisse zu bestimmen Die Ausnahmen von diesem Prinzip spielen f r den Untersuchungsgegenstand keine gro e Rolle Dem entspricht die Konzeption des Schuldrechts als ein weitgehend offenes System Der gro en Bedeutung der Parteivereinbarung tr gt das Gesetz durch Auslegungsvorgaben Rechnung Ma geblich ist der wirkliche Wille 133 BGB und der hypothetische Parteiwille wie er sich aus dem Erkl rten und aus den Begleitumst nden 157 BGB entnehmen l sst Das Gericht legt die Erkl rungen der Parteien bei Vertragsschluss und die Umst nde unter denen diese abgegeben wurden sowie die Vorgeschichte im Prozess ohne Bindung an den vor allem im Prozess ge u erten Parteiwillen aus Dabei ist der Wortlaut ein Anhaltspunkt der im Lichte des Empf ngerhorizontes und der konkreten Umst nde im Einzelfall zu pr fen ist Der ge u erte Wille 51 Staudinger Magnus Art 1 Rn 44 die wesentliche Vertragsleistung bestehe
70. die Wahrscheinlichkeit einer Abhilfe durch den Verletzer sowie das Ausma des Verlusts den der Verletzer erleidet Konkretere Kriterien sind beispielsweise der Projektfortschritt je fr her der Vertragsbruch um so eher ist er material und der Verschuldensgrad Calamari Perillo 11 18 S 414f Calamari Perillo 11 18 S 415f Der Mechanismus durch die Formulierung time is of the essence alleine diesen Effekt zu erreichen funktioniert nach im Wachsen begriffener Ansicht nicht Calamari Perillo a a O S 416 Rs 2d 242 21 208 Unconscionable Contract or Term If a contract or term thereof is unconscionable at the time the contract is made a court may refuse to enforce the contract or may enforce the remainder of the contract without the unconscionable term or may so limit the application of any unconscionable term as to avoid any unconscionable result Legt man die berkommen Formulierung vom Anstandsgef hl aller billig und gerecht Denkenden Mot Il 727 zugrunde so entsprache der Begriff der Unconscionability der Sittenwidrigkeit etwa in 138 BGB Ein Vertrag erf llt diese Voraussetzung wenn such as no man in his senses and not under delusion would make on the one hand and as no honest and fair man would accept on the other Rs 2d 8 208 b 52 21 21 e wo 21 a 21 N Kapitel 3 Rechtliche Rahmenbedingungen in den USA die Moglichkeit auf Grundlage der Unconscionability das E
71. die zahlreichen Stellungnahmen aus der rechtlichen Literatur verst ndlich da hier eine Gelegenheit gesehen wird auf die weitere Entwicklung Einfluss zu nehmen Bei unklarer Rechtslage bedienen sich die Gerichte gerne der Stellungnahmen aus der Literatur wenn es an ober gerichtlichen Entscheidungen fehlt 51 Dieser letzte Hinweis w re in einer auf das deutsche Recht beschr nkten Darstellung trivial f r einen amerikanischen Kollegen dagegen kann er aus den in Kapitel 3 dargelegten Gr nden durchaus berraschend sein 193 Kapitel 7 Vergleichende Darstellung Dabei sind die gesetzlichen Rahmenbedingungen daraufhin zu untersuchen ob sie diesbezugliche Vorgaben und Einschrankungen enthalten A Zielprazision Aus inhaltlicher Sicht erweist sich das Statute Law als wenig ergiebig Selbst bei Anwendung des U C C lassen sich diesem allenfalls Anhaltspunkte generellen Inhalts entnehmen Es obliegt den Parteien den Inhalt der gegenseitigen Pflichten durch einen Vertrag zu bestimmen Ein Ruckgriff auf vorvertragliche Vereinbarungen zur Definition oder Auslegung dieser Pflichten wird als extrinsic evidence grundsatzlich ausgeschlossen Tatsachliche Vertragsdurchf hrung zwischen den Parteien bliche Vertragsgestaltungen und Handelsbr uche k nnen jedoch f r die Erkl rung und Erg nzung der Vereinbarungen verwendet werden Im Ergebnis verbleibt es bei einem sehr weit gesteckten Rahmen Eine Besonderheit genereller Art kann aus den R
72. durch den AG als solche gekennzeichnet Die Erf llung der in dem Abweichungsbericht zugesagten Anforderungen beziehen sich auf die Formulierungen des Pflichtenheftes Der AN sichert dem AG zu dass die im Pflichtenheft Abweichungsbericht dargestellten Leistungen durch die Standardsoftware und Anpassungen zu den terminlich vereinbarten Meilensteinen erbracht werden So eindeutig wie es die Vertragsbezeichnung bei MiO und MiN aussagt f llt die Vertragseinordnung nicht aus da sowohl MiO S 2 Nr 11 als auch MiN Nr 1 1 Schulungsleistungen erfassen die allgemein als Dienstleistungen betrachtet werden Beide Vertr ge machen deutlich dass es dem Softwarebesteller auf eine Betreuung ber den gesamten Lebenszyklus der Software und nicht nur auf die Erstellung eines Programms ankommt Betont wird dies bei MiO durch S 3 wonach alle Pflichten bis auf die Wartung eine unteilbare Leistung darstellen sollen Ein weiterer Hinweis darauf ist auch der Pr ambel bei MiO zu entnehmen Der Auftraggeber beabsichtigt die EDV Unterst tzung der Vertriebs und Produktionst tigkeiten seines und der verbundenen Unternehmen z B X sowie die Vertriebsaktivit ten seiner H ndler bis sp testens M rz 1996 auf eine neues System umzustellen und wurde diesbez glich vom Auftragnehmer beraten 172 Kapitel 6 Empirischer Befund in Deutschland Auf diese Pr ambel wird in Nr 3 S 1 als Zweck der Leistungen des Softwarehauses Bezug genom
73. entsprechenden Unterlagen und Ausz ge hiervon verlangen Einzelheiten und eine evtl Verg tung f r Zwischenberichte werden im Erstellungsschein vereinbart Erkennt der Auftragnehmer dass er die Ausf hrungsfristen nicht einhalten kann hat er dem Auftraggeber unverz glich die Gr nde f r die Verz gerung und ihre voraussichtliche Dauer mitzuteilen Ein Anspruch auf Verl ngerung der Ausf hrungsfristen besteht unbeschadet 15 nicht Interessanterweise kommt nur in den BVB zum Ausdruck dass die Auferlegung von Informationspflichten nicht unerhebliche Ressourcen verbrauchen kann die u U eine Verg tung als angemessen erscheinen lassen BA konkretisiert die Berichtspflicht durch inhaltliche Vorgaben in 14 Information 1 Der AN erstellt f r jeden Kalendermonat bis sp testens zum 7 Werktag des Folgemonats einen schriftlichen Bericht mit zumindest folgendem Inhalt Herstellungsgrad der Teilprojekte mit Angaben zur Einhaltung des Terminplanes und Verbrauch an Ressourcen 146 Kapitel 6 Empirischer Befund in Deutschland Im Folgemonat geplante Arbeiten des AN und Beistellungen des AG anstehende Entscheidungen Wesentliche Ergebnisse berblick ber das Projekt Qa Daruber hinaus sieht BA mindestens in 14tagigem Abstand stattfindende Projektbesprechungen vor die vom Softwarehaus zu protokollieren sind 13 Besprechungen und Protokolle la 2 Der AN erstellt ber jede Projektbesprechung ein P
74. gesetzlichen Regelungen der Leistungsbestimmung sind in hohem Ma e von der Einordnung unter den Vertragstypus abh ngig Hinsichtlich der Unterscheidung von Werk und modifiziertem Kaufvertragsrecht zeigt sich dies insbesondere anhand der Differenzen von Abnahme beim Werkvertrag und bergabe beim Kaufvertrag Auch hier spielt die Frage nach der Sacheigenschaft von Software im Rahmen des 651 BGB wieder eine wichtige Rolle Wird ein Lizenzvertrag angenommen greifen allgemeine kaum n her konturierte Regeln Die Annahme einer Zuordnung von Elementen aus dem Gesellschafts oder Dienstvertragsrecht wird an das seltene Vorliegen besonderer Konstellationen gekn pft Eine gemischte L sung f hrt in der Konsequenz zu ebenso gemischten rechtlichen Rahmenbedingungen Die genaue Definition der zu erbringenden Leistung in einem sog Pflichtenheft wird v a in der Literatur nachdr cklich gefordert in der Praxis aber h ufig nicht vorgenommen Verantwortlich f r die Erstellung des Pflichtenhefts ist nach ganz Uberwiegender Auffassung der Besteller der Software Dabei m ssen allerdings die sehr intensiven Leistungsbeziehungen zwischen den Vertragsparteien bei einem Softwareentwicklungsvertrag ber cksichtigt werden die zu erheblichen gegenseitigen Abh ngigkeiten bei der Leistungserbringung f hren Das Softwarehaus trifft diesbez glich vor allem eine vom Informationsgef lle abh ngige Pflicht zu umf nglicher Beratung und Dokumentation
75. im Gegensatz zu den informationstechnischen Anforderungen zu bestimmen sind F hrungskr fte aus dem Personal des Softwarebestellers unverzichtbar Eschbach bemerkt demgem treffend 8 S o S 21 81 Schwickert betont f r den Bereich des Web Site Engineering also der Softwareentwicklung mit dem Ziel der Neu Gestaltung einer Internetprasenz dass der Softwarebesteller nicht nur die strategischen Entscheidungen selbst vorbereiten und treffen sollte sondern auch die Analyse und Modellierung der betriebswirtschaftlich fachlichen Anforderungen von ihm wahrgenommen werden sollte a a O S 315f 82 Eschbach a a O S 125 83 So ausdr cklich Maymon Cave a a O S 84 Eschbach a a O S 125 5 Etzel Heilmann Richter a a O S 66 f r eine optimale Teamzusammensetzung empfehlen die Autoren einen internen d h aus dem Personal des Softwarebestellers stammenden Abteilungsleiter und 9 weitere interne Mitarbeiter 7 aus der Informatik und zwei aus dem Fachbereich gegen ber einem Projektleiter und 10 Softwareentwicklern 26 Kapitel 2 Softwareentwicklung in der Praxis es sei ein gefahrlicher Denkfehler wenn man als Softwarebesteller meint die eigene Beteiligung darauf beschr nken zu k nnen Forderungen aufzustellen und auf die Einhaltung von Terminen zu drangen 3 nderungen Ob es im Projektverlauf zu nderungen der Anforderungen kommt oder nicht stellt sich nicht als Frage dar sondern wird als selbst
76. is transmitted directly to its ultimate destination e g computer terminal or workstation without any intermediate stops or manual intervention b The FDRI on line system shall not experience more than downtime occurrences during a calendar month This downtime does not include FDRI nightly downtime to update the data base or any scheduled off hours maintenance Critical Diese Regelung enth lt zun chst die allgemeine Forderung hinsichtlich ausreichender personeller Ausstattung und im Anschluss daran konkrete Leistungsdaten hinsichtlich der Systemverf gbarkeit ausgedr ckt in Ausfalltoleranz bzgl Dauer 3 1 1 a und H ufigkeit 3 1 1 b Der in Klammern gesetzt Hinweis Critical ist f r die Konsequenz im Hinblick auf Nichterf llung von Bedeutung Werden drei kritische Anforderungen nicht 271 Nr 3 1 vergleichbare Regelungen werden in der IT Branche h ufig als sog Service Level Vereinbarungen bezeichnet 87 Kapitel 4 Empirischer Befund in den USA erfullt berechtigt dies den Softwarebesteller zu fristloser Vertragsk ndigung ber die Einhaltung der Performance Standards hat das Softwarehaus monatlich zu berichten Ergeben sich dabei Abweichungen so hat dies unmittelbare finanzielle Folgen in Form von Abz gen auf ausstehende Zahlungen SMS and MAS Performance Reporting and Remedies a During each calendar month FDRI agrees to provide PRODIGY with a monthly report lis
77. limited to any failure by customer to provide reasonable assistance and cooperation to Vendor such a delay shall be excused during the continuance of and to the extent of that cause and the period of performance shall be executed to the extent necessary to allow performance after the cause of the delay has been removed Bei RB V findet sich nach einer generellen beide Vertragsparteien betreffende Verpflichtung zur Kooperation in Nr 8 eine detaillierte Auflistung von Handlungserfordernissen auf Seiten des Softwarebestellers in Nr 9 Diese bestehen im wesentlichen daraus alle fur erforderlich gehaltenen Informationen zu liefern die technischen Voraussetzungen f r die Softwareentwicklung und Tests zu schaffen sowie ausreichendes Personal bereit zu halten 8 Cooperation Both Licensor and Licensee acknowledge and agree that successful development ofthe Management System so as to become operational in the Licensee s environment shall require their full and mutual good faith cooperation including without limitation the fulfillment by Licensee of the obligations set forth in paragraph 9 below 9 Licensee Obligations In addition to providing Licensor with full good faith cooperation and such information as may be required by Licensor in order to develop and implement the Management System Licensee shall a provide Licensor with specific and detailed information concerning Licensee s work flow procedures and transaction
78. ln U v 26 6 92 OLGR K ln 1993 S 237 und U v 25 6 93 OLGR K ln 1993 S 270 OLG M nchen U v 31 1 95 OLGR M nchen 1995 S 217 OLG D sseldorf U v 18 7 97 CR 1997 S 732 OLG Frankfurt U v 3 5 01 OLGR Frankfurt 2001 S 307 OLG Karlsruhe U v 16 8 02 CR 2003 S 95 107 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland Ablieferung ankniipfe Wenn eine L sung geschuldet sei und der Schwerpunkt der vertraglichen Vereinbarung in Erstellung von Individualsoftware liege so k nne von einem Werkvertrag mit dienstvertraglichen Elementen ausgegangen werden Software verbleibe nicht im Immateriellen vielmehr f hre der Inhalt der geistigen Leistung ber den Gebrauch zu gegenstandlichen und fassbaren Ergebnissen Diese materialisierte geistige Leistung bedinge eine Anwendbarkeit des Werkvertragsrechts b Was ist Software Nach 8 651 BGB finden auf Vertr ge die die Lieferung herzustellender Sachen zum Gegenstand haben die Vorschriften ber den Kauf Anwendung Handelt es sich um eine nicht vertretbare Sache so wird das Kaufrecht durch f nf Normen des Werkvertragsrechtes modifiziert Vertretbare Sachen sind nach 91 BGB Sachen die im Verkehr nach Zahl Ma oder Gewicht bestimmt zu werden pflegen worunter Ware aus Serienfertigung zu verstehen ist Nicht vertretbare Sachen sind solche die infolge von Bestellerw nschen individuelle Merkmale aufweisen und daher schwer oder gar nicht an
79. nicht in der bertragung sondern der Entwicklung dem Schreiben des Programms Schlechtriem Ferrari Art 1 Rn 38 wohl auch Soergel L deritz Fenge Art 1 Rn 21 Endler Daub die zwar den zur Produktion selbst erforderlichen Aufwand nicht zu den Dienstleistungen nach Art 3 Abs 2 CISG rechnen wohl aber die neben die Erstellungspflicht tretenden Installations Anpassungs Support Programmpflege und Einarbeitungsarbeiten a a O S 605 126 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland hat gegenuber der gerichtlichen Auslegung infolge der Privatautonomie allerdings Vorrang Unabhangig vom Parteiwillen sind die Grundsatze von Treu und Glauben Verkehrssitte sowie Handelsbrauche zu beachten wobei deren Konturen eher mit einer Burste als mit einem Pinsel gezogen werden Die Folgen von Unklarheiten k nnen durch die Gerichte im Konfliktfall anhand unbestimmter Rechtsbegriffe und weiten Ermessens der Richter bei der Ber cksichtigung vertragsbegleitender Umst nde in gro em Umfang gerichtsautonom bestimmt werden Bei der Frage nach dem konkret auf Softwareentwicklungsvertr ge anzuwendenden Recht ist in der Fachliteratur nahezu alles umstritten Dies gilt zun chst f r die Frage ob ein Vertragstyp aus dem besonderen Schuldrecht zugeordnet werden muss Es setzt sich bei der Frage danach fort ob berhaupt ein existenter Gesetzestypus passt und m ndet anschlie end in die Frage um welchen Typus es sich ha
80. performance vorliegt so ist in einem zweiten Schritt zu fragen ob diese sich als material darstellt Daf r finden sich Kriterien in Rs 2d 2417 Ob Verzug diese Voraussetzungen erf llt ist eine der dabei am h ufigsten diskutierten Fragen Im Ergebnis erf llt ma voller reasonable Verzug diese Voraussetzung nur dann wenn sich die Intention der Parteien zu dieser Rechtsfolge aus dem Vertragstext und den Begleitumst nden ergibt Wird material failure of performance bejaht so h ngen die daraus abzuleitenden Rechtsfolgen davon ab ob von der verletzten Partei noch erwartet werden kann eine versp tete Leistung anzunehmen oder ob sie von ihren eigenen Pflichten befreit wird Auch eine schwerwiegende Vertragsverletzung berechtigt demnach nur dann zur K ndigung wenn eine Heilung nicht zumutbar ist Eine besondere Bedeutung im Rahmen dieser Untersuchung kann sich aus Rs 2d 208 ergeben Danach hat das Gericht bei Klauseln die es f r den Zeitpunkt des Vertragsschlusses f r unvertretbar unconscionable halt die Wahl ob es den Vertrag oder Teile davon f r wirksam erkl rt oder die Anwendung des unvertretbaren Teiles so beschr nkt dass ein unvertretbares Ergebnis vermieden wird Praktisch bedeutsam ist vor allem 212 Es werden u a genannt Das Ausma in dem die verletzte Partei des Vorteils verlustig geht den sie vern nftigerweise erwarten konnte eine angemessene Kompensationsm glichkeit
81. r den Auftragnehmer Individual Software Vertragssoftware deren fachliche Spezifikation vom Auftraggeber schon in der Ausarbeitung vom Autor Version niedergelegt ist Diese fachliche Feinspezifikation beschreibt richtig vollst ndig und abschlie end den Leistungsumfang der vom Auftraggeber zu erstellenden Software Sie ist Vertragsbestandteil und als Anlage 1 beigef gt Durch diese Formulierung liegt die Verantwortung f r die Spezifikation beim Softwarebesteller und es wird der Versuch unternommen vor Beginn der Arbeiten des Softwarehauses einen verl sslichen richtig vollst ndig und abschlie end status quo zu schaffen Eine noch weiter konkretisierende Variante findet sich bei SN B unter 1 Vertragsgegenstand 1 1 Software Erstellung Der AN entwickelt und erstellt f r den AG die Software XYZ gem dem Pflichtenheft s a Pr ambel sowie gem Terminplan die beide Bestandteil dieses Vertrages sind Anlage 1 und 2 1 2 Projektverantwortung 1 2 1 Der AN bernimmt die Projektverantwortung auch f r dieses Software Produkt hat sie jedoch schon im Rahmen des Gesamtprojektes inne und bernimmt die Koordination und Integration dieses Projektes in das Gesamtsystem 1 2 2 Mitwirkung des AG 1 2 3 Die vom AN erstellte Projektsch tzung ist als Anlage 4 Vertragsbestandteil und Referenz f r Minderungen und Mehrungen sowie nderungen und deren Aufwand s a Ziffer 2 4 6 Anm Siehe dazu
82. she en tree eriet rerit ents 206 ErMETGUUNG 2 Er Eee 211 Kapitel 8 Schlussfolgerungen uuunnsnunnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 212 A Strukturelle Unterschiede Spielr ume und ihre Verwendung 212 Software ist keine Sache nn 212 Il L sungen im Begriffssystem und Erfahrungssystem 215 Ill Grenzen der Begriffssysteme 444444444HHnnnnnnnenen nennen 218 IV Erfolgsorientierte Fehlerbestimmung 44444444 444 220 Kapitel 9 Zusammenfassende W rdigung uunsssssesnnnnnnnnnnnnnnnnnnnnnnnnnnnn 223 AGesamibel nd 2er nennen 223 l Technik und Recht Social Engineering und Software Engineering ta dee ae ee ar NEE En a ne aia 223 Il Die L sung des Konfliktes zwischen Planung und Wirklichkeit 225 Ill Interessenorientierte oder projektorientierte Vertragsgestaltung wide do eM Said Mop otc AA ep Ea a a a aN 227 Be EIG DiIS sn oie ae cena coro behets ED ee 229 Literaturverzeichnis 2 42 42 2 22 lite eee BER 237 Dissertation Softwareentwicklungsvertrage Inhaltsverzeichnis VII Dissertation Softwareentwicklungsvertrage Abk rzungen Abk rzungen A aA anderer Ansicht a a O am angegebenen Ort ABGB Das Allgemeine b rgerliche Gesetzbuch sterreich Abs Absatz AcP Archiv f r die civilistische Praxis Zeitschrift a E am Ende AG Aktiengesellschaft Auftraggeber AGB Allgemeine Gesch ftsbedingung en
83. sind als zentraler und selbstverstandlicher Bestandteil des Aufgabenbereiches Konfigurationsmanagements Submodell KM im Abschnitt Anderungsmanagement erfasst 18 Kapitel 2 Softwareentwicklung in der Praxis Se ae Anderungsantrag Problem meldung p nderung bewerten abgelehnt 5 beabsichtigt Anderungsvorschlag 5 5 y gt Anderungsvorgehen entscheiden und Protokoll Anderung x u nderung gem nderungsauftrag V Modell Regelungen abgelehnt beauftragt Berichtsdok Projektabschlussbericht nderung 4 abschlie en erledigt nderungsmitteilung 2 vollst ndiges nderungsprojekt oder definierte Aktivit tenfolge nderungen k nnen dazu f hren dass der Produktzyklus teilweise oder vollst ndig hinsichtlich einzelner Teile oder in seiner Gesamtheit neu durchlaufen werden muss Das V Modell versucht in m glichst vollst ndiger Weise alle Aspekte der Entwicklung theoretisch zu erfassen und in ein formalisiertes Verfahren zu integrieren Theorie und Praxis des Softwareengineering bringen naturgem immer neue Modelle und Vorgehensweisen hervor Soweit ersichtlich sind derzeit aber keine durchgreifend neuen Ans tze f r die vorliegende Untersuchung von Bedeutung 3 F r die Softwareentwicklung sind im Laufe der letzten 50 Jahre mehr als 300 Normen von 50 verschiedenen Organisationen geschaffen worden siehe bei Th
84. stets der Ausgangspunkt der Betrachtung Der Wille der Parteien ist f r den Qualit tsma stab ausschlaggebend Bei der Bestimmung der geschuldeten Qualit t ist in beiden Rechtsordnungen eine Tendenz festzustellen keinen allzu strengen Ma stab anzulegen Die in den Mustern und Praxisbeispielen formulierten Ma st be sind zun chst in einer bersicht dargestellt 552 S o Kapitel 3 D II S 53 53 Kodifiziert im BGB in 242 Leistung nach Treu und Glauben Der Schuldner ist verpflichtet die Leistung so zu bewirken wie Treu und Glauben mit R cksicht auf die Verkehrssitte es erfordern 554 8 434 Abs 1 S 1 BGB 633 Abs 2 S 1 BGB 555 8 434 Abs 1 S 2 Nr 1 BGB 8 633 Abs 2 S 2 Nr 1 BGB 556 S o Kapitel 5 B Il 2 S 111f 207 Kapitel 7 Vergleichende Darstellung MaBstab der Leistungserbringung Deutsche Muster Vereinbarte bzw vertraglich vorausgesetzte Beschaffenheit so oder ahnlich in 6 Mustern Aktueller Stand des Software Engineering und der Grunds tze ordnungsgem er Berufsaus bung Lizenzprodukt erf llt die Hauptfunktionen im Wesentlichen und entspricht den anerkannten Regeln der Technik Stand der Technik bei Vertragsabschluss Verfahrensnormen nach DIN ISO 9000ff oder andere in Hinblick auf die Qualit tssicherung gleichwertige Verfahrensregeln Grunds tze ordnungsm iger Datenverarbeitung Vorgaben der Bundesanstalt f r Finanzdienstleistungsaufsicht Erstellung so
85. the following to Client 1 A description of the Software including an overview of how the Software works a flow diagram indicating the input flow processing and output of information and specifications for the Software including minimum hardware and operating system requirements 2 Complete user documentation including a description of how to access and use the Software screen prints of menus and input output screens data input descriptions sample output report forms error code descriptions and solutions where appropriate and explanations of all necessary disks and data used by the Software 3 Complete program technical documentation including program source code listings with comments technical information about files and their locations file names file database structures record structures and layout and data elements 4 A Master Copy ofthe Software on magnetic media including all programs on line documentation and any documentation developed on a computer Gefordert ist also eine Sammlung technischer und erkl render Unterlagen die den Entwicklungsvorgang von der Definition der Anforderungen bis hin zu der Kommentierung des Source Code erfasst Bei DS findet sich hierzu unter 2 Delivery and Acceptance Testing a Developer shall deliver the Specifications Product and Documentation to XXXXX in accordance with the schedule set forth in Exhibit B The term Documentation means all technical documentation for the
86. tigt der Anbieter vom Kunden dar ber hinausgehende Ressourcen so sind diese angemessen zu verg ten N heres regelt der Erstellungsschein ES 6 1 14 3 Bereitstellung von Informationen 156 Kapitel 6 Empirischer Befund in Deutschland Der Kunde stellt dem Anbieter alle bendtigten Informationen und Unterlagen zur Verf gung insbesondere solche ber Hardware Software Schnittstellen und Datenbest nde mit denen das Lizenzprodukt zusammenarbeiten soll andernfalls benennt der Kunde taugliche Informationsquellen N heres regelt der Erstellungsschein ES 6 2 14 4 Bereitstellung von Testdaten Der Kunde stellt dem Anbieter die im Erstellungsschein ES 6 3 definierten Testdaten zur Verf gung 14 5 Abruf von Mitwirkungshandlungen 1 Der Anbieter ruft rechtzeitig und schriftlich konkrete Mitwirkungshandlungen ab 2 Der Anbieter bietet dem Kunden soweit zumutbar Unterst tzung an Er erh lt f r vom Kunden geforderte Unterst tzungsleistungen eine Zusatzverg tung ES 5 5 14 6 Verletzung von Mitwirkungspflichten 1 Erf llt der Kunde in diesem Vertrag vorgesehene Mitwirkungspflichten nicht nicht richtig oder nicht rechtzeitig so r gt der Anbieter dies unverz glich schriftlich 2 Der Kunde ist dem Anbieter zum Ersatz des aus der Verletzung der Mitwirkungspflicht entstehenden Schadens verpflichtet Ein Zeitplan wird erforderlichenfalls angepasst 3 Der Anbieter kann dem Kunden eine angemessene Frist zur Erf l
87. to be a contract is not made invalid by the fact that it leaves particulars of performance to be specified by one of the parties Any such specification must be made in good faith and within limits set by commercial reasonableness 3 2 Unless otherwise agreed specifications relating to assortment of the goods are at the buyer s option and except as otherwise provided in subsections 1 c and 3 of Section 2 319 specifications or arrangements relating to shipment are at the seller s option 4 3 Where such specification would materially affect the other party s performance but is not seasonably made or where one party s cooperation is necessary to the agreed performance of the other but is not seasonably forthcoming the other party in addition to all other remedies 5 a is excused for any resulting delay in his own performance and 6 b may also either proceed to perform in any reasonable manner or after the time for a material part of his own performance treat the failure to specify or to cooperate as a breach by failure to deliver or accept the goods Dabei sollte nicht Ubersehen werden dass es bei der Regelung des U C C in erster Linie darum geht die Verantwortlichkeit fur die Konkretisierung eines Rechtsgeschaftes zuzuordnen Demgem wird der angesprochene Fragenkreis auch unter dem Gesichtspunkt der Indefinitness diskutiert vgl Calamari Perillo a a O 2 9 S SOff Kapitel 3D Il Das Schuldverh ltnis kann nach seinem
88. und 77 Love gibt den Aufwand fur die Codierung mit h chstens 20 an a a O S 199 nach Eschbach entfallen auf Analyse und Planung Kodierung und Test sowie Implementierung jeweils 10 w hrend 70 f r die Wartung Pflege und Erweiterung aufgewendet werden m ssen a a O S 81 Vilfredo Pareto lebte im 19 Jahrhundert und war Professor f r politische Okonomie an der Universit t von Lausanne Er erkannte dass in vielen M rkten berall auf der Welt ein Gro teil der Aktivit ten auf einen Bruchteil der Akteure entf llt Dies wurde als das 80 20 Pareto Prinzip bekannt 80 Prozent des Geschehens entfallen auf 20 Prozent der Beteiligten Zehnder a a O S 39 ebenso auch bei Fisher Myths and methods a guide to software productivity New York 1991 S 35ff 55 BE Kapitel 2 Softwareentwicklung in der Praxis anfallenden und per EDV abzuwickelnden Vorgange erledigen will so steigen die Kosten nach dieser Annahme deutlich berproportional an Einfacher ausgedr ckt Die Behandlung von Sonderf llen wird teuer c Zeitpunkt und Zust ndigkeit Die Frage zu welchem Zeitpunkt ein Pflichtenheft vorliegen soll l sst sich aus Sicht des Software Engineering nicht eindeutig beantworten Dies liegt zum Teil an der dargestellten unterschiedlichen Terminologie oder der Uneinheitlichkeit in der Aufeinanderfolge der Arbeitsschritte im jeweiligen Modell Teilweise scheint die Frage sich auch nicht zu stellen oder einer klaren Zu
89. und Vorbereitung realisierung Systemtest Schulung Verfahrenstest ee Verfahrens Einf hrung einf hrung 144 Kapitel 6 Empirischer Befund in Deutschland Nach den BVB liegt also bei Vertragsbeginn bez glich der Softwarebestellung bereits ein idealerweise im Rahmen eines EDV technischen Vorgehensmodelles entwickeltes fachliches Feinkonzept d h eine klare Definition der Leistungsanforderung in fachlicher Hinsicht vor In der letzten Gruppe SN B und BA bauen die Parteien auf einem bestehenden Pflichtenheft auf Bei BA wurde dieses Pflichtenheft gemeinsam erstellt und vom Softwarehaus gepr ft d h die Verantwortung f r die Geeignetheit des Pflichtenheftes f r die nachgelagerten Projektschritte liegt alleine beim Softwarehaus 4 Leistungsbeschreibung 1 Das Projekt ist heute durch folgende Unterlagen beschrieben a b Gemeinsam erstelltes Pflichtenheft Anlage Pflichtenheft C ax d wx Der AN hat diese Unterlagen auf Vollstandigkeit Eindeutigkeit Konsistenz und Realisierbarkeit gepr ft Bei SN B wird bereits in der Pr ambel deutlich dass die verbindliche Definition der zu erbringenden Leistung ausschlie lich Sache des Softwarehauses ist IV Besondere Pflichten des Softwarehauses KO BA GL HE SN B und die BVB sehen besondere Pflichten des Softwarehauses vor Mehrfach sind dabei Informations und Berichtspflichten anzutreffen So hei t es bei KO unter Nr 1 12 Hinweispflicht Ist f
90. unten VI Ver nderungen 1 3 Geschuldetes Ergebnis 1 3 1 Das vom AN geschuldete Ergebnis ist die rechtzeitige Implementierung und Herstellung der Ablauff higkeit der zu erstellenden Software mit einwandfreier Funktionsweise in abnahmef higem Zustand 135 Kapitel 6 Empirischer Befund in Deutschland innerhalb des Gesamtsystems mit Echtdaten bis sp testens zum Die Teilschritte ergeben sich aus dem Terminplan 1 3 2 Dokumentationen 1 4 Ber cksichtigung Gesamtprojekt Der AN wird bei der Ausf hrung des Vertrages die Entwicklung des Gesamtprojektes sowie die technische Entwicklung ber cksichtigen und den AG rechtzeitig auf etwa erforderlich werdende nderungen hinweisen und dazu erforderlich werdende Entscheidungen herbeif hren Soweit der AN dies unterl sst schuldet er dennoch zum Gesamtpreis s Ziffer 8 eine entsprechend angepasste und oder aktualisierte Leistung nicht nur mittleren Ausf hrungsstandard Das Softwarehaus wird hier ber die aus dem Pflichtenheft herzuleitende Leistungsbestimmung hinaus f r die Entwicklung von Gesamtprojekt und au ervertraglicher Technik in die Verantwortung genommen Es wird dar ber hinaus eng an seine Prognosen insbesondere hinsichtlich Zeit und Kosten gebunden und dies unbeschadet der vorgesehenen Festpreisvereinbarung Eine k rzere aber im Ergebnis weitergehende Definition schl gt schlie lich KO in 1 Vertragsgegenstand vor Entwicklung Der Anbiet
91. user manuals operations manuals programmer documentation including narratives on programming conventions and structure and screen layouts 66 Kapitel 4 Empirischer Befund in den USA Bei RB U findet sich dieser Gedanke in abgeschwachter Form wieder Das Softwarehaus bleibt fur die Ermittlung der notwendigen Daten verantwortlich aber der Softwarebesteller wird zur Mitarbeit insbesondere in Form der Bereitstellung von Personalressourcen berufen 4 7 Detailed Design Specifications A For each Application Licensor shall with Licensee s full cooperation gather the necessary data and develop Detailed Design Specifications Licensee shall make available personal knowledgeable in Licensee operations with respect to each Application for the number of days set forth on Schedule H attached hereto Als Ausgangsdokument setzt RB U dabei den sog Request for Proposal voraus der vom Softwarebesteller als Grundlage fur dessen Ausschreibung formuliert wurde Liegen die vom Softwarehaus erstellten Spezifikationen vor folgt in einem Teil der Muster ein zweiter Schritt in dem diese Spezifikationen vom Softwarebesteller daraufhin gepr ft werden ob sie seinen in den functional requirements niedergelegten Vorstellungen entsprechen Dies wird mit Fristen und weiteren Verfahrensregeln verkn pft Bei DS hei t es unter 1 b b XXXXX will have the period set forth in Exhibit B to review the Specifications XXXXX wi
92. v Dharma Systems Inc 148 F 3d ih Cir 1998 649 654 Colonial Life Ins Co of America v Electronic Data Services Inc 817 F Supp 235 D N H 1993 andererseits Andersen Consulting LLP v Gavin 26 Conn L Rptr 496 Conn Super 2432 16 a 16 S 16 16 17 17 Oo Kapitel 3 Rechtliche Rahmenbedingungen in den USA Stellungnahmen aus der Literatur stuft Softwareentwicklungsvertr ge gleichwohl als Vertr ge ber goods ein und wendet den U C C an Programme seien als Code der den Computer zur Ausf hrung bestimmter Funktionen anweist das Ergebnis eines intellektuellen Prozesses Das Ergebnis dieses Prozesses werde dann zur Software wenn es auf ein Medium bertragen wurde Dieser Vorgang sei vergleichbar mit der Aufzeichnung von Musik auf einer CD oder dem Halten einer Vorlesung die in Buchform bertragen wird Sobald das Programm in Form einer Diskette oder einem anderen Medium vorliegt ist es tangible moveable and available in the marketplace Rechtspolitisch wird die Anwendbarkeit des U C C zudem als w nschenswert angesehen da damit ein einheitliches Recht bezogen auf einen weiten Umfang von Fragen die blicherweise in Computersoftware Auseinandersetzungen auftauchen zur Verf gung steht Dies sei ein starkes Argument strong policy argument fur den R ckgriff auf das Uniform Law In den von der Rechtsprechung entschiedenen F llen werden neben der Liefer
93. vom Fallrecht geschulten Vorgehensweise der amerikanischen Richter zu suchen Ebenso voreilig w re es das Prinzip der Abstraktion vorrangig dem deutschen Recht zuzusprechen Die oben bereits mehrfach angef hrten Restatements of Law sind ein Paradebeispiel f r Abstraktion und stehen diesbez glich den allgemeinen Teilen des deutschen BGB in nichts nach Auf den Punkt gebracht k nnten die deutschen Gerichte also einen Softwareentwicklungsvertrag als Vertrag sui generis handhaben und eigene Rechtsregeln hierzu entwickeln Ein solcher Schritt erfordert allerdings den Mut dazu einer beengenden Dogmatik den R cken zu kehren und der eigenen berzeugung zu folgen Letztendlich k nnen auf diese Weise dann allerdings auch Signale an den Gesetzgeber gesendet werden Diese gesetzgeberische Initiative kann nat rlich auch ohne gerichtlichen Ansto ergriffen werden In den USA ist dies bereits geschehen und m ndete in den oben beschriebenen Entwurf des Uniform Computer Information Transaction Act UCITA Er erlangte u a aus Kompetenzgr nden keine Geltung Gabe es einen amerikanischen 54 Ein Weg der z B von Hilty auf Basis einer Lizenzvertragsl sung vorgeschlagen wird in MMR 2003 S 3 15 und Fn 114 565 Wovon jedoch die Mehrzahl der Fachbeitr ge auszugehen scheinen Der ganz berwiegende Teil der Diskussion verl uft entlang der Zuordnungsfrage Werkvertrag oder Kaufvertrag s o Kapitel 5 B I 2 S 106 566 S o Kapitel
94. wegen auftretender Fehler und nderungen in der vorgelagerten Phase erneut durchlaufen werden Diesem Sachverhalt tragen weiterentwickelte Modelle konzeptionell Rechnung Im Folgenden sollen drei dieser Modelle n her betrachtet werden Im sog Wasserfallmodell ist als Ende jeder Phase eine Pr fung und im Fall des Auftretens von Fehlern ein wiederholtes Durchlaufen der Phase vorgesehen Im Unterschied zu den vorangegangenen Modellen findet hier also im Anschluss an jede Phase eine Validierung statt und die m gliche R ckkehr zu einem vorgelagerten Entwicklungsstadium ist bereits Bestandteil der Betrachtungsweise 2 Hansen Neumann a a O S 207 2 Das Wasserfallmodell repr sentiert eine auch heute noch verwandte Methode die bereits Anfang der 70er Jahre eingef hrt wurde McManus Wood Harper Information Systems S 77 die einzelnen Schritte werden mit unterschiedlichen Schwerpunkten und Bezeichnungen dargestellt vgl Mall Software Engineering S 19 die grunds tzliche Struktur ist in der folgenden Grafik dargestellt See Kapitel 2 Softwareentwicklung in der Praxis Durchf hrbarkeit Pr fung Analyse Softwareanforderun Pr fung pi Design Grob und Feinentwurf Pr fung Programmierung Pr fung Pr fung Test Installation Prufung p t Inbetriebnahme Pr fung Das Wasserfallmodell geht von einem konseq
95. will provide the development Services and complete the work described in the scope of work Bei FL hei t es 60 Kapitel 4 Empirischer Befund in den USA 1 01 Development Undertaking Developer shall within days of final execution of this Agreement commence work on and diligently proceed with the development of the Subject Programs according to and in conformity with the specifications and performance standards set forth in Exhibit A Specifications and Performance Standards Vom Softwarehaus ist hier nicht ein feststehendes Ergebnis sondern die Arbeit im Hinblick auf dieses Ergebnis geschuldet Wahrend sich also deutlich die Service Orientierung als Vertragsinhalt bereits aus dem Vertragswortlaut ablesen lasst ist die Vertragseinordnung in den brigen Mustern zumindest hinsichtlich des Wortlautes nicht eindeutig Im Gegensatz zu RB V wo unter Nr 2 davon die Rede ist Licensor hereby agrees to develop the Management System for Licensee formuliert RB U 1 The Software System 1 1 Definition ofthe System Licensor agrees to supply to Licensee a data processing software system the System which meets Licensee s requirements contained in Licensee s Request for Proposal as all such requirements may be modified or superseded by the Detailed Design Specifications as defined herein Die Betonung liegt auf der Lieferung eines Systems welches den Anforderungen des Softwarebestellers entspricht Ahnlich u
96. wird Eine weitergehende Variante findet sich auch bei MiN etwas versteckt im Source Code Nutzungsvertrag unter 6 Kontrollrechte Die Parteien haben das Recht jederzeit ohne Vorank ndigung bei dem jeweiligen Vertragspartner die korrekte Anwendung des Vertrages zu berpr fen Zur Sicherung der termingerechter Fertigstellung verankert MiN v a Informationspflichten unter 4 Lieferung 4 2 Der AN ist verpflichtet eine voraussichtlich wesentliche l nger als f nf Werktage anhaltende Verz gerung dem AG unverz glich schriftlich anzuzeigen nachdem f r den AN die Verz gerung erkennbar wird Sofern der AG seine Zustimmung nicht innerhalb von sieben Werktagen verweigert verl ngern sich die Folgetermine um die Dauer der angezeigten Verz gerung Verweigert der AG seine Zustimmung so verst ndigen sich die Vertragspartner ber die weitere Vorgehensweise Kann keine Einigung erzielt werden so ist nach Ma gabe der Nr 22 Anm Nr 22 enth lt eine Schiedsklausel zu verfahren 4 3 Entsteht eine wesentliche Verz gerung durch h here Gewalt oder ist sie durch den AG zu vertreten so zeigt der AN dies ebenfalls unverz glich unter Hinweis auf die voraussichtliche Dauer der Verz gerung an In diesem Fall verl ngern sich die Termine jeweils um die Dauer der angezeigten Verz gerung Der h heren Gewalt stehen Streik Aussperrung oder hnliche Umst nde von denen der AN mittelbar oder unmittelbar betro
97. zu k nnen und die im brigen folgende Anforderungen zu erf llen hat Die Dokumentation wird dem Kunden in facher Ausfertigung als Printversion und auf geeignetem Datentr ger im format zur Verf gung gestellt Ill Spezifikationen Die Muster gehen bei der Spezifikation der Leistung von unterschiedlichen Projektst nden aus Dabei wird nicht immer deutlich in welcher Phase sich das Projekt tats chlich befindet W hrend nach KO und augenscheinlich auch nach MA bei Null begonnen wird setzen GL und HE voraus dass bereits erste Grundsteine f r eine konkretere Leistungsbeschreibung gelegt wurden Bei SN S und den BVB liegt eine fachliche Feinspezifikation bzw ein fachliches Feinkonzept vor Bei SO findet sich als Anlage 2 eine Funktionsbeschreibung die ohne Hinweis auf weitere Planungsleistungen oder erfordernisse offenbar als ausreichende Grundlage f r die vertragliche Vereinbarung angesehen wird Bei BA und SN B schlie lich liegt zum Zeitplanpunkt des Vertragsschlusses ein Pflichtenheft vor Auf die Regelung auch im Hinblick auf die Verantwortung f r die Spezifikation wird in der vorgenannten Reihenfolge also nach dem Umfang erbrachter Vorarbeiten im Einzelnen eingegangen KO bietet die Optionen der Pflichtenhefterstellung durch den Kunden oder den Anbieter an und formuliert dementsprechend 1 Nr 1 3 Pflichtenheft 139 Kapitel 6 Empirischer Befund in Deutschland Variant
98. 03 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland Willen der Vertragsparteien in Frage stellt Ein ge u erter Wille ist also stets zu respektieren und bei erganzender Vertragsauslegung konsequent weiterzudenken B Anwendbares Recht l Einordnung des Vertragstypus 1 Notwendigkeit Die Diskussion Uber das auf Softwareentwicklungsvertrage anzuwendende Recht hat durch die Schuldrechtsreform neuen Auftrieb erhalten der zu zahlreichen Stellungnahmen und auch umfangreicheren wissenschaftlichen Stellungnahmen Anlass gab In vielen Beitragen ist dabei die Notwendigkeit einer Einordnung des Vertragstypus gar nicht Bestandteil der berlegungen Hoeren betont in seiner Dissertation noch die Verbindlichkeit von Begriffskategorien die durch den Gesetzgeber vorgegeben seien Die wahre Rechtsnatur einer Vereinbarung so wie die der Software berlassung als Kauf stehe nicht zur Disposition der Vertragsparteien Von diesem Gedanken ist wohl auch Redeker ausgegangen wenn er ausf hrt Vertrag und Gesetz lie en nur wenig Regelungsl cken In einigen neueren und neuesten Stellungnahmen findet sich diese Auffassung nicht wieder So betont Thewalt die Typenfreiheit des Schuldrechts und verweist auf die f r Softwareentwicklungsvertr ge unbedeutenden zwingenden Vorschriften denkbarer Vertragstypen Die 322 Bamberger Roth Wendtland 157 Rn 26 AnwK Looschelders 157 Rn 10 333 Erman Palm 13
99. 05 S 700 die anl sslich des zwanzigj hrigen Jubil ums der Zeitschrift CR auf zahlreiche immer noch bzw wieder ungel ste Probleme hinweisen 600 Stellvertretend k nnen hier Application Service Providing dazu Nolting Roger David Nolte Bernd in WiSt 2004 431 435 und Open Source Software dazu Spindler Gerald Hrsg Rechtsfragen bei Open Source K ln 2004 genannt werden 231 Kapitel 8 Schlussfolgerungen Softwareentwicklungsvertr gen zu einem bestimmten vorhandenen Vertragstypus 2 die Schaffung eines neuen Vertragstypus oder 3 die Einf hrung eines Computer und Informationsgesetzes Die erste M glichkeit w rde nach den Ergebnissen dieser Untersuchung sehr wahrscheinlich zur Anwendung des Werkvertragsrechts f hren Die 88 631 ff BGB sind jedoch als effektive Rechtsgrundlage f r Softwareentwicklungsvertr ge ungeeignet Effektiv ist eine Rechtsgrundlage dann wenn sie bez glich der zentralen Fragen die mit einem Sachverhalt verkn pft sind Antworten f r die Parteien bereith lt Dies ist jedoch nicht der Fall Zun chst existiert kein klares Leistungsprofil Die Umschreibung als Herstellung eines versprochenen Werkes er ffnet mehr Fragen als sie beantwortet Die Mitwirkung des Bestellers die in Softwareentwicklungsvertr gen eine unabdingbare Voraussetzung f r den Projekterfolg darstellt ist in 642 BGB nur rudiment r geregelt Die Konsequenz der 88 643 645 Abs 1 S 2 BGB stellt zudem selten eine
100. 1 32 Thewalt a a O S 114ff 106 35 35 N 35 35 35 a e o 35 oO 35 35 N 35 36 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland Stellungnahmen knupfen fur die Vertragseinordnung an die durch die Software zu ver ndernde Hardware an Der BGH geht in st ndiger Rechtsprechung von der Einordnung der Softwareentwicklung als Werkvertrag aus ohne dies ausf hrlich zu begr nden Die Einordnung habe den Besonderheiten der Vertragsgestaltung zu folgen wobei darauf abzustellen sei ob die Software berlassung im Rahmen eines Dauerschuldverh ltnisses oder im Wege eines einmaligen Erwerbsaktes gegen einmaliges Entgelt erfolgt Dieses Ergebnis wurde zementiert nachdem der BGH die Sacheigenschaft von Software wenn auch unter nur eingeschr nkt verwertbarer Bezugnahme auf fr here Entscheidungen eindeutig bejaht hatte Zur Einordnung zweifelhafter Vertr ge u erte sich der BGH in j ngster Zeit am ausf hrlichsten au erhalb des Softwarebereiches Stehe die bertragung von Besitz und Eigentum im Vordergrund und bilde eine Montage nicht den Schwerpunkt des Vertrages liege kein Werkvertrag vor Auch die Prognostizierbarkeit des Risikos und die Verantwortbarkeit des Erfolges wurden als Einordnungskriterium herangezogen In der letztgenannten Entscheidung h lt das Gericht zudem f r erw hnenswert dass es den Interessen beider Parteien entspr che wenn die Nac
101. 1 hnlich komme es den Parteien nach Malzer a a O S 266 auf die 109 38 38 jare 38 N 38 ow Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland Ver nderung einer Sache ab Das Vertragsziel l ge in der Funktionsf higkeit einer bestimmten Hardware Aus dieser Erfolgsbezogenheit wird von der Rspr eine bedeutsame Konsequenz abgeleitet Eine wirksame Abnahme setze eine gewisse Zeit fehlerfreier Arbeit der Software voraus Es sei zu Gunsten des Bestellers eine Testphase erforderlich Die Brauchbarkeit von Software sei wie bei einem Lizenzvertrag ber ein Fertigungsverfahren oder eine Erfindung erst nach langen Ausf hrungsversuchen erkennbar d Urheberrechtliche Einfl sse Die Bedeutung des urheberrechtlichen Elementes der Software berlassung wird sehr unterschiedlich beurteilt W hrend sie nach einer Auffassung ohne Bedeutung f r die Typeneinordnung ist stellt sie nach anderer Auffassung das zentrale Kriterium dar Nach vermittelnder Ansicht ndert sie zwar an der Hauptpflicht des werkvertraglichen Erfolges nichts doch f hre die Pflicht zur Rechteverschaffung zu einem Typenkombinationsvertrag mit lizenzvertraglichen Element hinsichtlich der urheberrechtlichen Aspekte Fertigstellung der funktionstauglichen Software und somit auf einen messbaren Erfolg an Schweinoch Roas nennen als Endziel die berlassung funktionsfahiger Software CR
102. 2 U C C 550 2 313 1 a b und c U C C 51 2 315 U C C Implied Warranty Fitness for Particular Purpose eine Einstandspflicht die allerdings abbedungen werden kann wie in Vertragen teilweise vorgesehen vgl oben Kapitel 3 C 1 4 S 46 206 Kapitel 7 Vergleichende Darstellung der jungeren Rechtsprechung zu gunstigeren Entscheidungen fur die Softwareh user gef hrt hat Woran die geschuldete Qualit t zu messen ist richtet sich im deutschen Recht in erster Linie nach dem schuldrechtlichen Vertragstyp erg nzt durch den allgemeinen Grundsatz von Treu und Glauben Sowohl im Kauf wie im Werkvertrag ist Ma stab die vereinbarte Beschaffenheit Ist die Beschaffenheit nicht vereinbart so ist nach der nach dem Vertrag vorausgesetzten Eignung zur Verwendung zu fragen und als letzte Alternative danach ob das Werk bzw die Sache sich f r die gew hnliche Verwendung eignet und eine Beschaffenheit aufweist die bei Werken Sachen der gleichen Art blich ist und die der Besteller nach der Art des Werkes der Sache erwarten kann Verschiedene Gerichte sowie einige Stimmen in der Literatur gehen davon aus Fehlerfreiheit sei keine bei Individualsoftware zu erwartende Beschaffenheit In beiden Rechtsordnungen ist die Bestimmung der Einstandspflicht von der Antwort auf eine Vorfrage n mlich der Einordnung von Software in das Rechtssystem abh ngig Ebenso ist die vertragliche Vereinbarung
103. 2004 S 326 Softwarebasierte Probleml sung nach Schmidl Michael Softwareerstellung und 651 BGB ein Vers hnungsversuch MMR 2004 S 590 385 Nach Koch ITRB 2002 S 297 ist Vertragszweck die Ver nderung des Rechners Der Computer werde in seinen wesentlichen Eigenschaften ver ndert n mlich in seinen Probleml sungsmerkmalen Braun BB 1992 S 154 Hilty der die Sacheigenschaft von Software aus der Perspektive eines Urheber und Patentrechtlers vehement zur ckweist will dynamischen gegenstandslosen und statischen Gebrauch unterscheiden Dynamischer Gebrauch sei die Nutzung von Funktionalit t wie sie nur Erfindungen haben MMR 2003 S 3 OLG K ln in OLGR K ln 1992 S 237 OLG M nchen in OLGR M nchen 1995 S 217 BGH U v 04 11 87 BGHZ 102 S 135 vor der M glichkeit zur Erprobung sei keine Abnahme m glich U v 02 11 95 CR 1996 S 667 und es kann eine Umkehr der Beweislast stattfinden wenn M ngel typischerweise erst sp t erkennbar sind U v 02 07 96 BGHZ 133 S 155 allerdings f r die Sondersituation sich als fehlerhaft erweisender Backups Schweinoch Roas CR 2004 S 326 Nutzungsrechte sind nach dem Gesetzeswortlaut des 651 BGB irrelevant auch w rde bei zugestandenem Einfluss die Typisierung wandelbar da von h ufig vorkommender Vertragsgestaltung abh ngig 391 Hilty MMR 2003 S 3 32 Thewalt a a O S 167 38 oO 38 38 38 oO on 39
104. 3 A S 38 Fn 141 und C Ill S 49 216 Kapitel 8 Schlussfolgerungen Gesetzgeber der zivilrechtliche Normen fur die gesamte USA schaffen und verbindlich in Kraft setzen k nnte so ware der UCITA h chstwahrscheinlich seit mehreren Jahren geltendes Recht An dieser Stelle k nnen nunmehr die Vorteile des deutschen Civil Law Systems fruchtbar gemacht werden Der deutsche Bundestag w re ohne weiteres in der Lage ein Computer und Informationsgesetz zu beschlie en einen neuen Vertragstypus zu schaffen oder als bescheidenste L sung nderungen am bestehenden Gesetz beispielsweise in Form einer expliziten Zuweisung der Softwarevertr ge zum Werkvertragsrecht vorzunehmen An eine derart ge nderte Rechtslage w ren alle deutschen Gerichte gebunden und es best nde auch f r die Kautelarjurisprudenz eine klare Vorgabe die es zu beachten gilt und die als Wegweiser dienen kann Eine L sung im Begriffssystem des deutschen Rechts ist einerseits schwieriger weil sie sich im best ndigen Ringen von notwendiger Abstraktion und gew nschter bisweilen ersehnter Konkretisierung ihre Berechtigung f r einen dauerhaften Platz erk mpfen muss Sie ist andererseits einfacher weil sie nur in begrenztem Ma e einer Vielzahl von u U divergierender Staatsinteressen ausgesetzt ist die zudem in einem Staatsorgan dem Bundesrat geb ndelt zu Tage treten Der Rechtsvergleich offenbart also Chancen die von einem deutschen Gesetzge
105. 3 Rn 20 334 Hoeren Thomas Software berlassung als Sachkauf Diss M nster 1989 S 25f 335 Hoeren a a O S 30ff 57 336 Hoeren a a O S 26 377 Redeker IT Recht in der Praxis 3 Aufl M nchen 2003 S 491 388 Malzer Hans Michael Der Softwarevertrag Diss K ln 1991 S 3 Slongo Doris Der Softwareerstellungsvertrag Diss Z rich 1991 S 21 Schmid Joachim Probleme der Rechtsnaturbestimmung moderner Vertragstypen am Beispiel des Back Up Vertrages CR 1994 S 513 Volle Peter Rechtliche Einordnung der EDV Systemvertr ge CR 1996 S 139 Schubert Michael von Haase Marina Konfliktmanagement in IT Projekten ZKM 2003 S 251 Thewalt Stephan Der Softwareerstellungsvertrag nach der Schuldrechtsreform Diss M nchen 2004 S 11 M ller Hengstenberg CR 2005 S 385 Seffer Horter ITRB 2005 S 169 349 Thewalt a a O 2004 S 11 A O 33 104 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland unzureichenden gesetzlichen Vorgaben k nnten nur eine pauschale Orientierungsfunktion wahrnehmen zumal das Projektleben nicht dem Gesetz folge Wenn Hoeren noch betont das Recht solle sich nicht an der Technik orientieren sondern auf die Starke seiner eigenen Denkweise vertrauen und EDV Fragen mittels des dem Zivilrecht eigenen klassischen Instrumentariums l sen so formulieren Malzer und Slongo bereits wenig sp ter dass Software eigene Regeln brauche Dies
106. 7 4 Vertragsfortfuhrung nach Pflichtenheft Dem Kunden steht es frei die Umsetzung des Projektes auf der Grundlage des gelieferten Pflichtenheftes mit einem dritten Unternehmer fortzuftihren 7 5 Anpassung nach Beginn der Realisierung Ergeben sich nach Realisierungsbeginn Anderungen hinsichtlich der Leistungsbeschreibung so ist das Pflichtenheft durch den Anbieter entsprechend fortzuschreiben 7 6 Vergutung Der Anbieter erh lt f r die Erarbeitung eine Verg tung nach Erstellungsschein ES 5 2 und f r die Fortschreibung eine Zusatzverg tung nach Erstellungsschein ES 5 5 Betrachtet man die Ausarbeitung der Aufgabenstellung als eigenen Schritt so findet sich hier ein dreistufiges Verfahren Zun chst definiert der Softwarebesteller seine Anforderungen diese setzt das Softwarehaus zun chst in ein abzunehmendes Pflichtenheft und dann in ein ebenfalls abzunehmendes Programm um Interessant ist die Ausstiegsoption des Softwarebestellers Sie enth lt einen deutlichen Hinweis auf die Fragilit t des Planungsprozesses die sich aus den Unwagbarkeiten bei Projektbeginn ergibt Die Einschr nkung der Mitarbeitspflicht des Softwarebestellers auf das Zumutbare erm glicht es eine berm ige Belastung von dessen Ressourcen insbesondere seinen Mitarbeitern zu vermeiden und einem ggf erheblichen Kompetenzgef lle hinsichtlich der Softwareentwicklung Rechnung zu tragen Auch HE geht von einer vorvertraglichen T tigkeit der Vertr
107. A Der Uniform Computer Information Transaction Act urspr nglich als Art 2B U C C konzipiert ist trotz der jahrelangen Entwurfsbemuhungen in der Praxis des amerikanischen Rechts von untergeordneter Bedeutung Das Modellgesetz wurde bisher lediglich von 2 Staaten Virginia und Maryland in Kraft gesetzt Uber diese verschwindend geringe Akzeptanz hinaus zeichnet sich eine Gesetzgebung ab die den UCITA Bestimmungen zielgerichtet entgegenwirkt Vermont lowa North Carolina und West Virginia haben so genannte UCITA bomb shelter Gesetze verabschiedet die Vereinbarungen von Gerichtsstand und Rechtswahl sofern diese zur Anwendbarkeit des UCITA f hren w rden f r nicht durchsetzbar unenforceable erkl ren Schlie lich wurde das Standby Komitee der NCCUSL im Sommer 2003 aufgel st womit die Bem hungen darum eine Einf hrung des Modellgesetzes durch weitere Bundesstaaten zu erreichen praktisch aufgegeben sind D Common Law I Restatements Gem Rs 2d 8 234 2 gilt die Grundregel dass soweit nicht anders vereinbart in Vertr gen die Erf llungsleistungen von ausgedehnter Zeitdauer zum Gegenstand haben zun chst diese zu erf llen sind bevor die andere sofort erbringbare Leistung Bezahlung verlangt werden kann Diese Regel erlangt vor allem in Dienstleistungsvertr gen service contracts such as employment contracts Bedeutung Sie findet allerdings nur Anwendung wenn und soweit sich aus der Parteivereinbarung od
108. Abs 2 S 2 schriftlich geltend macht ist die ge nderte Leistung im Rahmen der bestehenden Vereinbarungen auszuf hren Der Auftragnehmer kann verlangen dass die von der Leistungs nderung betroffenen Arbeiten bis zur Anpassung des Erstellungsscheines entsprechend der ge nderten Leistung und Gegenleistung unterbrochen werden Wird die Ausf hrung nicht vom Auftraggeber unterbrochen und 166 Kapitel 6 Empirischer Befund in Deutschland erkennt der Auftragnehmer dass die zwischen Zugang des Anderungsverlangens und Anpassung des Erstellungsscheines auszuf hrenden Arbeiten im Falle der Durchf hrung der nderung nicht verwendbar sind hat er dies dem Auftraggeber unverz glich mitzuteilen 3 Kommt eine Anpassung des Erstellungsscheines nicht innerhalb von 21 Kalendertagen nach Zugang des Verlangens des Auftragnehmers zur Anpassung der vertraglichen Regelungen zustande so werden die Arbeiten auf der Grundlage der bestehenden Vereinbarungen weitergef hrt soweit der Auftraggeber den Vertrag nicht gem 649 BGB k ndigt Die Ausf hrungsfristen verl ngern sich um die Zahl der Kalendertage an denen in Folge des nderungsverlangens bzw der Pr fung des nderungsverlangens gem Nummer 1 Abs 2 die Ausf hrung unterbrochen wurde Der Auftragnehmer kann f r die Dauer der Unterbrechung die vereinbarte Verg tung sowie die entsprechende Erh hung einer vereinbarten Obergrenze bzw die entsprechende Erh hung eines vereinbarten Festpr
109. Anforderungen der sprachlichen Pr zision eine besondere Bedeutung beigemessen Im Ergebnis muss der Softwarebesteller a wissen was er will und dies anschlie end b gemeinsam mit dem Softwarehaus zutreffend und pr zise formulieren 62 Etzel Heilmann Richter sprechen von konsequenter und kompromissloser Benutzerorientierung a a O S 85 vgl auch Fisher a a O S 16 Zehnder a a O S 190f Etzel Heilmann Richter a a O S 66 6 Dumke a a O S 23ff 64 Rupp a a O S 19 65 Rupp a a O S 20 6 Darunter sind unn tige Funktionen zu verstehen vergleichbar etwa einer Vergoldung des Schraubenziehers mit entsprechenden Folgen f r Aufwand und Kosten Rupp a a O S 22 ebenso Fisher a a O S 16 8 Auch hier ist die Parallele zu unbestimmten Rechtsbegriffen in der juristischen Terminologie augenf llig 88 Rupp a a O S 264ff 270 8 Die durch das Einhalten bestimmter Regeln zur Vermeidung sprachlicher Defekte erreicht werden kann so Rupp a a O mit instruktiver bersicht auf S 191ff Dabei kann auch auf Schablonen S 230ff und computergest tzte Formulierungshilfen S 255 zur ckgegriffen werden 70 Rupp a a O S 191 Kratzsch bei Rupp a a O S 421ff empfiehlt die Anforderungen systematisch in einer Datenbank und nicht einem einfachen Textdokument zu erfassen da sich so Fragen Versionspflege und Abnahmekriterien leichter mit der jeweiligen Anforderung verkn pfen lassen 24
110. Bedeutung dieser Frage erstaunt dass sie nur bei GL auftaucht Eine Versicherungspflicht f r Haftungsrisiken findet sich bei GL Nr 20 6 und in den BVB unter 14 Nr 4 in beiden F llen obligatorisch vorgesehen und nicht zur Option gestellt Im softwarebestellerfreundlichen Muster SN B schlie lich werden die Pflichten des Softwarehauses nicht unerheblich erweitert So hei t es unter 2 4 151 Kapitel 6 Empirischer Befund in Deutschland Der AN hat im Rahmen seines Pflichtenhefts und des Terminplans die bei einem Projekt dieser Gr enordnung und dieser Art blichen nderungen und Schwierigkeiten bereits ber cksichtigt Weiterhin wird das Softwarehaus zur Anforderung verschiedener Leistungen beim Softwarebesteller verpflichtet Dies gilt gem 3 3 f r Mitwirkungsleistungen 3 3 Abruf der Mitwirkung Der rechtzeitige Abruf der Mitwirkungsleistungen des AG ist Sache des AN Soweit bereits feste Termine f r Mitwirkungsleistungen festgelegt sind z B in Anlage 2 wird der AN auf solche Termine rechtzeitig hinweisen Es gilt dar ber hinaus auch f r Testdaten 9 10 1 Der AG wird rechtzeitig vom AN dahingehend informiert welche Daten bzw welche Unterlagen der AN wann ben tigt F r die Beschaffung der Testdaten ist der AG nur dann verantwortlich wenn ihm die Daten hinreichend genau beschrieben worden sind Die Bestimmung unter 3 3 soll laut Anmerkung des Autors dazu dienen ein
111. Development Agreement bzw Custom Software Development Agreement DaS V von Software Development and License Agreement DS von Software Development and Acquisition Agreement und FL von einem Agreement for Development of Software to Specifications In allen Mustern ist die Einr umung einer Lizenz vorgesehen wobei AS DaS V RB U und RB V keine Exklusivit t vorsehen w hrend DS DaS U und FL exklusive d h eine auch das Softwarehaus von der weiteren Nutzung ausschlie ende Rechte bertragung beinhalten In den zwei letztgenannten Vertr gen ist diese Exklusivit t allerdings zeitlich auf ein Jahr FL bzw 25 Jahre DaS U begrenzt Im Muster von DS findet sich in der Pr ambel die Formulierung 2 XXXXX desires to engage Developer to perform certain software development services and Developer is willing to perform software development services for XXXXX upon the terms and conditions set forth herein Vertragsinhalt ist demnach das Erbringen von Software development Services Sehr hnlich formuliert AS in der Pr ambel indem er die performance von services in den Vordergrund r ckt C Client wishes to have Developer design and develop certain computer software according to the terms specifications and conditions set forth in this Agreement and Developer desires to perform these services Unter der berschrift Development Obligations trifft man dementsprechend auf die Formulierung 2 1 Generally Developer
112. Dissertation Softwareentwicklungsvertrage Softwareentwicklungsvertrage Inaugural Dissertation zur Erlangung des Doktorgrades am Fachbereich Rechtswissenschaft der Justus Liebig Universit t Gie en vorgelegt von Peter Kath Gie en 2006 Guruji Dr Shri Balaji Tambe und meiner Familie Dissertation Softwareentwicklungsvertrage Inhalts bersicht Inhalts bersicht Kapitel 1 Gang der Untersuchung Bedeutung der IT Branche und Einf hrung in die Begriffe Software und Leistungsbestimmung 3 Kapitel 2 Softwareentwicklung in der Praxis uuuunuesnsnnnnnnnnnnnnnnnnnnnnnn 10 Kapitel 3 Rechtliche Rahmenbedingungen f r Softwareentwicklungsvertr ge unnnnnnsnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 36 Kapitel 4 Empirischer Befund in den USA uuz24444400040000R RR Rn Rn nn n nun 59 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland 99 Kapitel 6 Empirischer Befund u 4444444444H0nnnnnn nun nun nnnnnnnnnnnnnnnnnnn 130 Kapitel 7 Vergleichende Darstellung Methoden der Leistungsbestimmung uuussssssnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn nn 192 Kapitel 8 Schlussfolgerungen unnnnnnnennnnnnnnnnnnnnnnnn nn 212 Kapitel 9 Zusammenfassende W rdigung uusssssssnnnnnnnnnnnnnnnnnnnnnnnnnnnn 223 Eiteraturverzeichnis aaa 237 Dissertation Softwareentwicklungsvertrage Inhaltsverzeichnis Inhaltsverzeichnis Kapitel 1
113. Es ist eine wichtige Aufgabe des Bestellers durch geeignete Mitwirkung zum Projekterfolg beizutragen H ufig notwendige und oder gew nschte nderungen der Leistungsbestimmung k nnen nach einer Auffassung in der Literatur vom Besteller regelm ig nicht verlangt werden Die Auswirkungen daraus resultierender Projektst rungen richten sich danach aus wessen Verantwortungsbereich sie stammen Es wird daher eine vertragliche Regelung des Vorgehens bei nderungen empfohlen 128 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland Dem UN Kaufrecht kommt bei Softwareentwicklungsvertragen im deutschen Recht bisher keine relevante Rolle zu da seine Anwendbarkeit an der uberwiegenden Arbeits bzw Dienstleistung im Rahmen der Softwareentwicklung scheitert 129 Kapitel 6 Empirischer Befund in Deutschland Kapitel 6 Empirischer Befund In diesem Kapitel werden entsprechend Kapitel 4 neun Musterentwurfe und drei Beispiele aus der Praxis ausgewertet A Musterentwurfe Untersucht wurden die Musterentw rfe von Koch KO Marly MA Bartsch BA Gl ckler GL Schneider SN Schr der S Heppner HE sowie die BVB Erstellung BVB Nur Schneider unterscheidet zwischen einer am Besteller und am Softwarehaus orientierten Variante Sie werden hier als SN B und SN S unterschieden Mit Ausnahme von HE und MA gliedern sich alle Muster in einen Hauptvertrag und zum Teil zahlreiche Anlagen Details bez
114. Filialen Ein kleines Projekt stellt beispielsweise die Entwicklung der Website f r den Fachbereich einer Universitat dar D Die Bedeutung der Leistungsbestimmung Im Rahmen der Softwareentwicklung wird blicherweise von einem Projekt gesprochen An diesem Projekt k nnen eine Vielzahl von Personen partizipieren Strukturell und h ufig vertraglich sind zwei Seiten beteiligt Das Softwarehaus und der Softwarebesteller Auf der einen Seite wird durch das Softwarehaus Wissen der Informationstechnologie repr sentiert Auf der anderen Seite hat sich der vermutete oder tats chliche Bedarf f r die L sung oder Unterst tzung der L sung einer Aufgabenstellung mit Mitteln der Informationstechnologie gezeigt Daraus entwickelt sich ein Projekt f r das die Beteiligten fr her oder sp ter nach juristischer Begleitung suchen Was sind nun die Interessen der Beteiligten Eine allgemein zutreffende Antwort darauf gibt es nicht zu unterschiedlich sind die Ausgangssituationen und die W nsche und Motive der Menschen Abstrakt lie e sich immerhin formulieren Die Beteiligten erwarten von der T tigkeit der Juristen eine F rderung des Projektes m glicherweise w nschen sie infolge einschl giger Erfahrungen auch lediglich den sch dlichen Einfluss der rechtlichen Profession m glichst gering und unter Kontrolle zu halten Wird eine dauerhafte in aller Regel auch heute noch schriftliche vertragliche Fixierung f r n tig befunden so b
115. Folgen der Verletzung von Mitwirkungspflichten CR 1989 S 961 Rupp Chris Requirements Engineering und Management 2 Aufl M nchen Wien 2002 S Salmond John Salmond on Jurisprudence Twelfth Ed London 1966 Schaub Beate Das Pflichtenheft im Spiegel der Rechtsprechung CR 1993 S 329 Schlechtriem Peter Hrsg Kommentar zum Einheitlichen UN Kaufrecht 3 Aufl M nchen 2000 zitiert Schlechtriem Bearbeiter Schlosser Hans Grundz ge der Neueren Privatrechtsgeschichte 9 Aufl Heidelberg 2001 Schmid Joachim Probleme der Rechtsnaturbestimmung moderner Vertragstypen am Beispiel des Back Up Vertrages CR 1994 S 513 Schmidl Michael Softwareerstellung und 651 BGB ein Vers hnungsversuch MMR 2004 S 590 Schneider Jochen Handbuch des EDV Rechts 3 Aufl K ln 2003 ders Softwareerstellung und Softwareanpassung Wo bleibt der Dienstvertrag CR 2003 S 317 ders IT Vertragsrecht CR 2005 S 695 Schneider Jochen Bischof Elke Das neue Recht fur Softwareerstellung anpassung ITRB 2002 S 273 Schr der Georg F Softwarevertrage Munchen 2002 Schubert Michael von Haase Marina Konfliktmanagement in IT Projekten ZKM 2003 S 251 Schutze Rolf A Hrsg M nchener Vertragshandbuch 5 Aufl Munchen 2004 Zitiert M nchener Vertragshandbuch Bearbeiter mane Literaturverzeichnis Schweinoch Martin Roas Rudolf Paradigmenwechsel fur Projekte Vertragstypologie der Neuerstellung von I
116. Gang der Untersuchung Bedeutung der IT Branche und Einf hrung in die Begriffe Software und Leistungsbestimmung 3 A Gang der Untersuchung cceeeeeeeeeeeeeeeeeeeeeeeeeeeeeaeaaeeeeeeeeeeeeeeeeees 3 B Bedeutung der Informationstechnologie 4nnen nen 3 C Erscheinungsformen von Software uussssessesssssnnnnnnnnnnnnnnnn nennen 5 D Die Bedeutung der Leistungsbestimmung 4444mmnne een 8 Kapitel 2 Softwareentwicklung in der PraxiS uuuuuunnnnnnnnnnnnnnnnnnnnnnnnnnn 10 A Theorie des Softwareengineering esserr nennen 10 K EIRTURr NGY ars een 10 Il Modelle f r die Erstellung von Software esseenn 12 Ill F r den Untersuchungsgegenstand besonders bedeutsame Aspekte der Softwareentwicklung uurssss44rss nennen 20 1 Der lange Weg zum Pflichtenheft Requirements Engineering ee ee ee ee 20 a EINTURRUNG AH es este een line 20 BIAUWANG ee 22 c Zeitpunkt und Zust ndigkeit mrrrn nn 23 d Voraussetzung f r die Erstellung 24244444444H 24 e Anforderungen und Abnahme uussrsssssseseeeennnnnnnnn nenn 25 2 Mitarbeit des Softwarebestellers uu 4444444 4 26 3 Anderungenan uuse seien ae 27 a Psychologie des Entwicklungsprozesses 28 b Kritische Faktoren in der Softwareentwicklung 30 c Zusammenfassu
117. I nderungen der Leistungsbestimmung Welche Bedeutung nderungen im Rahmen der Softwareentwicklung zukommt bemerkt bereits Slongo auch aus rechtlicher Sicht pr gnant Projekt nderungen geh rten zum Wesen jedes nicht ganz einfachen Informatikprojektes Ein nderungsverfahren m sse daher vertraglich vorgesehen werden 3 Rehmann CR 1989 S 961 auch nach dem BGH k nnen Pflichten denen nach dem Parteiwillen wesentliche Bedeutung zukommt zu Hauptpflichten werden U v 22 07 98 NJW 1998 S 3197 84 Vgl zu den weiteren Rechtsfolgen ausf hrlich Thewalt a a O S 199ff 5 Sick a a O S 31 Sobola Dobmeier a a O S 34 6 BGH U v 20 02 2001 NJW 2001 S 1718 der Besteller bef nde sich dann in Annahmeverzug 7 BGH U v 28 06 94 NJW RR 1994 S 1469 1469 488 LG Frankfurt U v 15 12 88 ECR LG S 79 weitere Beispiele aus der Rechtsprechung bei Koch Computervertragsrecht a a O Rn 230 8 Die Bedeutung aus technischer Sicht wurde bereits in Kapitel zwei ausf hrlich dargestellt 490 Slongo a a O S 38 491 Redeker IT Recht a a O Rn 437 im Zuge notweniger nderungen k nne auch ein Festpreis unzumutbar werden wobei wie im Baurecht die Schmerzgrenze bei Budget berschreitungen von 20 25 berschritten w rde S 439 123 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland Die Konsequenzen des Auftretens von Anderungen gewinnen in der Literatur aller
118. Inhalt jeden Teil zur R cksicht auf die Rechte Rechtsg ter und Interessen des anderen Teils verpflichten 203 54 a 54 54 w N Kapitel 7 Vergleichende Darstellung wenn diese Pflicht verletzt wird und ein Festhalten am Vertrag unzumutbar ist Fur den Werkvertrag und den nach 651 S 3 BGB modifizierten Kaufvertrag ist eine Mitwirkungspflicht ausdr cklich bestimmt Auch hier hatten die Gerichte das Ausbleiben von Mitwirkungshandlungen in Einzelf llen zu beurteilen Das Fehlen qualifizierten Personals f r das Projekt auf der Seite des Softwarebestellers welches vor allem durch die Lieferung von Informationen zur Leistungsbestimmung beitragen kann wurde von Gerichten in Deutschland und den USA als eine Verletzung der Mitwirkungspflicht angesehen Seitens Gerichten beider Rechtsordnungen wird davon ausgegangen das Softwarehaus habe die erforderlichen Mitwirkungshandlungen einzufordern sei es durch das Verlangen nach Vorlage von Material oder der Teilnahme an Besprechungen Wenn Spezifikationen laut Vertrag durch den Softwarebesteller zu erbringen sind so verletzt er nach deutscher und US amerikanischer Rechtsprechung seine Mitwirkungspflicht wenn er es unterl sst sie vorzunehmen Eine bedeutende Einschr nkung kann sich nach amerikanischer und deutscher Rechtsprechung aus Beratungspflichten des Softwarehauses ergeben In einem von starkem Wissensgef lle gepr gten Vertragsverh ltnis wird Aufkl rung und
119. Kunst als eine Wissenschaft so scheint nach dem Vorstehenden eine sorgf ltige vertrauensvolle und geduldige Erfassung und Fortschreibung des Projektzieles in Zusammenarbeit mit dem Softwarebesteller Voraussetzung f r den Projekterfolg zu sein b Kritische Faktoren in der Softwareentwicklung Ein Grund f r die vielgestaltigen Versuche den Softwareentwicklungsprozess zu verstehen zu systematisieren und f r die Praxis tragf hige Konzepte zu entwerfen h ngt mit den h ufigen Schwierigkeiten bis hin zum Scheitern von Projekten zusammen Nach Franz werden 40 60 aller Softwareprojekte nicht beendet Nach Norvis halten lediglich 1 mit hohem Softwareanteil das Budget und die Fristen und 25 lieferten nie ein funktionierendes Produkt ab 107 Dass auch Druck auf die Mitarbeiter einen rascheren Erfolg nicht unbedingt beg nstigt wird pr gnant von Etzel Heilmann Richter zusammengefasst Menschen denken unter Druck weder schneller noch besser a a O S 24 hnlich Brooks mit zahlreichen Beispielen Mythos S 26 108 von Brooks anschaulich als WHISKEY Prinzip bezeichnet Why in Heaven Isn t Someone Koding Everything Yet 109 Eschbach formuliert Je eher Du anf ngst zu programmieren desto l nger wirst Du brauchen a a O S 87 vgl auch S 114 Verschiedene Gr nde daf r im Einzelnen auch bei Dumke a a O S 63 110 So ausdr cklich Maymon Cave a a O S 173 wer die zahllosen Skizzen von Leo
120. Muster sehen eine Ubertragung der Rechte an der Software vor wobei MA 7 Abs 2 und SN B Nr 4 1 4 4 eine exklusive Einraumung der Nutzungsrechte an den Softwarebesteller enthalten w hrend BA 88 27 28 SN S Nr 4 1 und KO 8 3 sich auf eine einfache Rechte bertragung beschr nken Als Standard mit abweichender Option ist dies auch bei HE 10 der Fall GL S und die BVB treffen keine Vorentscheidung sondern berlassen die Wahl dem Musterverwender SN B GL und S verwenden eine Pr ambel wobei sich bei SN B und GL bedeutsame Informationen finden Unter SN B wird formuliert Die Vertragspartner arbeiten seit l ngerer Zeit zusammen Der Auftragnehmer AN hat f r den Auftraggeber AG bereits Untersuchungen im Haus des AG durchgef hrt und inzwischen abgeschlossen Diese Ist Analyse vom bildet den Ausgangspunkt f r die folgenden Regelungen Der AN kennt aus der bisherigen Arbeit nicht nur die Verh ltnisse bei dem AG und zwar auch dessen EDV und Organisationsverh ltnisse aus eigener Erfahrung sondern verf gt auch ber die entsprechenden Unterlagen Die Vertragspartner haben in der Folgezeit nach dieser Analyse eine Reihe von Projektsitzungen abgehalten die in den Protokollen 1 02 5 02 und 7 02 festgehalten sind Darin sind auch die Empfehlungen des AN f r das weitere Vorgehen und die Auswahl der Ziel Hardware bzw des Ziel Betriebssystems enthalten Auf der Basis dieser Gespr che steht auch fest welche
121. Product 62 Kapitel 4 Empirischer Befund in den USA including flowcharts source code object code program procedures and descriptions including descriptions of the source code and build procedures for the object code procedures for maintenance and modification testing data and similar written material relating to the design structure and implementation of the Product The term Documentation does not include end user documentation or manuals The Documentation shall be sufficient to enable a reasonably skilled and experienced programmer to understand the design structure and implementation of the Product Der letzte Satz trifft hier den Kern der vorstehenden Liste von Lieferpflichten Der Softwarebesteller soll durch sie in die Lage versetzt werden die Software von diesem Zeitpunkt an falls gew nscht oder notwendig selbst ndig zu pflegen oder ndern Er soll m a W aus der Abh ngigkeit von der Expertise des Softwarehauses in die Freiheit zur selbstbestimmten Nutzung und Entwicklung der Software gelangen DaS U verwendet einen inhaltsgleichen Satz in seiner Beschreibung der zu liefernden Documentation unter 6 Vendor shall deliver to User all necessary and reasonable documentation for the System including user systems operating and program manuals Such documentation shall include but not be limited to Anm Es folgt eine l ngere Aufz hlung der technischen Dokumente The documentation togethe
122. Projekt naher beschrieben wird Am kurzesten fallt diese Bezugnahme bei AE unter Statement of Work aus The Software and such other Deliverables shall perform and comply with the specifications set forth in the Authorization Letter the Specifications Die Authorization Letters sollen dabei ausweislich der Praambel sukzessive erstellt und gemeinsam umgesetzt werden WHEREAS Company desires to retain Supplier to furnish the programming training consulting or other services the Services specified in Work Authorization Letters each an Authorization Letter to be issued from time to time and executed by both parties Wer die Spezifikationen also vornimmt ist zumindest im Vertrag nicht ausdr cklich geregelt Dass die Spezifikationen sich erst im Verlaufe des Projektes herauskristallisieren wird bei FP noch deutlicher Dies gilt in abgeschwachter Form zunachst fur die weiter zu entwickelnde Software bei der eine gemeinsame Priorit tenbildung erfolgen soll Each SMS System Enhancement and or Maintenance Change shall be jointly prioritized by FDRI and PRODIGY and implemented in accordance with each SMS Joint Detailed Project Plan that results from Exhibit 1 Section 2 and with the SMS Implementation Plans that result from Exhibit 5 Section 5 265 Aus dem Gesamtzusammenhang des Vertrages kann die Vermutung abgeleitet werden der Softwarebesteller sei f r die Vorgaben verantwortlich Daf r spricht der Wortlaut
123. SN B und SN A sowie den BVB mit Abstand zu den umfangreichsten Regelungen des ganzen Vertrages Bei BA SN B GL und in den BVB kann der Softwarebesteller das Durchf hren von nderungen verlangen wobei GL auch die M glichkeit eines Ausschlusses des nderungsrechts ausdr cklich vorsieht Liegt das nderungsverlangen vor hat das Softwarehaus innerhalb einer vorgegebenen Zeit einen Vorschlag bzgl des weiteren Vorgehens zu 160 Kapitel 6 Empirischer Befund in Deutschland unterbreiten Alle Muster sind vom Bem hen gekennzeichnet eine Kalkulierbarkeit der nderungsfolgen zu erreichen und vor allem eine Verz gerung des Projektes durch nderungen zu verhindern BA enth lt die vergleichsweise k rzeste Vorschrift 22 Leistungs nderungen 1 Der AG kann jederzeit Leistungs nderungen und erg nzungen verlangen die im Rahmen des Projektes liegen es sei denn sie w ren f r den AN unzumutbar F r kleine nderungen vorausgesch tzter Aufwand bis f nf Arbeitstage gen gt die Festlegung durch das Teilprojektteam nach 13 Abs 2 wenn sich dadurch der Terminplan nicht ndert Im brigen gilt 12 Abs 3 2 Der AN sch tzt sofort ab ob der Mehraufwand mehr als neun Arbeitstage betr gt In diesem Fall verlangt er vom AG eine schriftliche Darstellung der Vorgaben und erstellt auf dieser Grundlage ein schriftliches Angebot Hierbei ist er an die Kalkulation Anlage Kalkulation gebunden Wenn der AG nichts anderes ent
124. Tendenzen etwas indem er klarstellte die Dokumentation m sse erst zum Abschluss der Arbeiten vorliegen und Teildokumentationen k nnten nur bei entsprechender Absprache verlangt werden 2 Mitwirkungspflichten des Auftraggebers Zun chst wird in der Literatur von einer Zuordnung der Mitwirkungspflichten zu den Obliegenheiten ausgegangen d h ihre Verletzung habe zwar eine Rechtsverk rzung zur Folge begr nde jedoch keinen klagbaren Anspruch Dies k nne sich jedoch insbesondere durch eine Vereinbarung der Vertragsparteien andern Teilweise wird auch davon ausgegangen auch ohne ausdr ckliche Erw hnung im Vertrag stellten die Mitwirkungspflichten 474 Redeker IT Recht a a O Rn 420 75 Schneider Handbuch a a O S 1538 Der Auftragnehmer habe keine genuine Pr fungspflicht der Besteller m sse selbst f r seine Angaben im Pflichtenheft einstehen daher gingen Vagheit und Unvollst ndigkeit zu Lasten des Bestellers wobei das Softwarehaus eine Hinweispflicht treffen kann wenn es die Mangelhaftigkeit h tte erkennen k nnen S 1539 76 Redeker IT Recht a a O Rn 420ff 7 OLG Celle U v 03 03 92 NJW RR 1993 S 432 478 OLG K ln U v 03 12 93 OLGR K ln 1994 S 13 ebenso OLG Karlsruhe U v 16 08 02 CR 2003 S 95 479 U v 20 02 01 NJW 2001 S 1718 0 Malzer a a O S 290 Redeker IT Recht a a O Rn 432 ausf hrlich Thewalt a a O S 208ff Schneider Handbuch a a O S
125. Vertrages dem freien Spiel der Kr fte berlassen soll m a W die Optimierung des Gesamtergebnisses also in der Optimierung der Eigeninteressen der Parteien gesucht werden Wird dies mit einem Ja beantwortet so treffen wir auf die bekannte marktwirtschaftliche Variante die in eine interessenorientierte Vertragsgestaltung m ndet Die Vertragsgestaltung kann jedoch auch projektorientiert erfolgen In diesem Fall wird der Entwurf an dem Projektziel und daran orientiert wie es am effektivsten zu erreichen ist Soweit die vergleichsweise geringe Stichprobe den Befund erlaubt ist die Tendenz zu unausgewogenen Vertr gen in den USA etwas ausgepr gter als in Deutschland Der mit dem Vertragsentwurf befasste Jurist hat je nach den Interessen und der Machtposition seines Auftraggebers die Wahl zwischen einer softwarehaus oder softwarebestellerfreundlichen Variante W hlt er die erste so schr nkt er die Einstandspflichten des Softwarehauses 226 Kapitel 8 Schlussfolgerungen weitgehend ein begrenzt den Auftragsumfang der alleine und verbindlich vom Softwarebesteller zu definieren ist und macht jede Zusatzleistung von einer Zustimmung und Vergutungspflicht abh ngig W hlt er die zweite so werden die Einstandspflichten m glichst weitgehend gefasst und der Auftragsumfang einschlie lich wahrscheinlicher nderungen wird bei einem Festpreis im Projektverlauf durch den Softwarebesteller bestimmt Nach den Erkenntnissen des zweiten
126. Was ist Software an 108 c Zweck der Softwareentwicklung 44444en nn gt 109 d Urheberrechtliche Einfl sse mmsmrur ns 110 Se ErgeDNIS reset nee nein ne Jaa 111 Il Der Mangelbegriff bei der Softwareentwicklung 111 Il Leistungsbestimmungz az ee 112 1 Bedeutung insbesondere bei der Softwarestellung _ 112 2 Zeitpunkt und Anforderungen 4444444Hnennnnnnnn nennen 112 3 Gesetzliche Regeln nach modifiziertem Kaufvertragsrecht 8 651 Abs 1 S 3 BGB und Werkvertragsrecht 88 631ff BGB Vertrag dynamischer Vertrag eee 116 IV Leistungsbestimmung durch das Pflichtenheft 117 1 Begriff und Bedeutung 117 2 VerantwortungszuweiSung anderer 119 V Beratungs und Mitwirkungspflichten gt 120 1 Beratungs und Dokumentationspflichten des Auftragnehmers BR NEE sect Yank pnd seeevonsaunetuese 3 E cane gas sender p oer amt nese 121 2 Mitwirkungspflichten des Auftraggebers 2 4444444000 122 VI nderungen der Leistungsbestimmung eeeeeee 123 VII UN Kaufrecht 6 SO neben 124 C Zusammenfassung und Ergebnis 444444444444Hnnnnnnnnnennnnnn nn 126 Kapitel 6 Empirischer Befund 44s4440nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 130 A Musterenw rfe aan een 130 l Vertragsart ten ann
127. agsparteien aus Sein Vertragsmodell strebt die ausgepr gteste Form der Zusammenarbeit der Vertragsparteien an Es orientiert sich sehr weitgehend an dem oben AT vorgestellten Spiralmodell der Softwareentwicklung also einem informationstechnischen Verfahren der Softwareentwicklung Sowohl die f r den Juristen schwer fassbare Terminologie als auch die Verfahrensweise selbst tragen zur Einzigartigkeit des Ansatzes von HE bei 514 Ob die Vertragsparteien freilich nicht besser daran t ten konkrete Pflichten zu benennen sei dahingestellt 2142 Kapitel 6 Empirischer Befund in Deutschland 2 Ablaufbeschreibung des zugrunde gelegten Entwicklungsmodells Das Entwicklungsziel soll durch eine zyklische Abfolge von vier Teilprozessen Quadranten erreicht werden Durch die Erh hung des Entwicklungsstandes mit jedem Zyklus ergibt sich das modellhafte Bild einer Spirale Spiralmodell Der erste Quadrant dient zur Identifizierung der Anforderungen Alternativen Risiken und Einschr nkungen Die Bewertung dieser Faktoren im zweiten Quadranten ergibt die Entscheidung zur Gestaltung des weiteren Vorgehens Die Realisierung der sich aus der Bewertung ergebenden Teilziele erfolgt im dritten Quadranten Jeder Zyklus schlie t mit einem Planungsquadranten ab in dem sich die Parteien auf den Zeit und Ressourcenbedarf f r den n chsten Zyklusdurchlauf einigen nderungen des bergeordneten Zusammenarbeitsger sts sind dabei zu pr fen D
128. ahmebereit und mit Fehlern etwa wegen des Nichterfassens einer im Betrieb m glichen Aufgabenstellung m sse immer gerechnet werden Im Softwarebereich g be es keine mangelfreie Leistung sondern maximal eine ann hernd fehlerfreie Diese Einsch tzung wird von einigen Gerichten geteilt So f hrt das LG Mannheim aus bei komplizierter Technik wie Individualsoftware sei mit Problemen zu rechnen das OLG Oldenburg best tigt es sei 33 Krau a a O S 60f ebenso bereits Bartl Rechtliche Problematik der Softwarevertr ge BB 1988 S 2122 Es sei Aufgabe des Anbieters der Software Leistungseinschr nkungen zu offenbaren 3 a a 0 S 44 3 a a 0 S 51 38 Sobola Dobmeier a a O S 33 ebenso deutlich Sick Ulrich Vertr ge im Projekt und Systemgesch ft 2 Aufl Heidelberg 2004 S 48 Software kann nicht fehlerfrei sein 3 7 Urteil v 20 06 86 in ECR LG S 1 2 111 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland bekannterma en schwierig Individualsoftware auf Anhieb fehlerfrei zu erstellen und das LG M nchen stellt fest nach tats chlichen Gegebenheiten und blichen Vertragsbedingungen garantiere kein Hersteller Fehlerfreiheit Ill Leistungsbestimmung 1 Bedeutung insbesondere bei der Softwarestellung Die Bedeutung der Leistungsbestimmung wird in der Literatur mit gro er Deutlichkeit unterstrichen Es sei insbesondere vor dem Hintergrund eines im Rahmen der Schuld
129. al FDRI shall credit PRODIGY with a reduction on its bill for processing services during the such month Continuous failure in any and all consecutive succeeding months shall result in a reduction on the applicable bill s for processing services until the failure is rectified d FDRI s failure to meet a performance standard due to any cause beyond its reasonable control and not unique to FDRI such as but not limited to the malfunction or failure of any entity from which FDRI must 272 Die allerdings verschiedene weitere Voraussetzungen hat 2 2 2 2 PRODIGY may terminate this Agreement immediately upon written notice to FDRI in the event that i in accordance with Section 3 1 1 c FDRI s failure perform in accordance with any 3 of the performance standards identified as Critical in Section 3 1 1 results in a 50 reduction in PRODIGY S processing services bills and ii such 50 reduction remains in effect for nine or more consecutive calendar months If this Agreement is terminated pursuant to this Section 2 2 2 2 PRODIGY s sole and total financial liability to FDRI shall be as set forth in Section 2 2 3 below 273 Unter 3 1 2 88 Kapitel 4 Empirischer Befund in den USA obtain information or have electronic contact in order to perform the services set forth in this Agreement shall not be considered to be a failure for which FDRI shall be responsible under this Agreement e PRODIGY agrees that due to the diffic
130. aller Software und Systementwicklung Hannover 2002 S 29 Modelle wie Rapid Application Development RAD oder Dynamic Systems Development Method DSDM vgl McManus Wood Harper S 87ff k nnen hier au er Betracht bleiben da sie gegen ber den betrachteten Modellen keine f r den Untersuchungsgegenstand ma geblichen Neuerungen enthalten 19 40 Kapitel 2 Softwareentwicklung in der Praxis Ill F r den Untersuchungsgegenstand besonders bedeutsame Aspekte der Softwareentwicklung 1 Der lange Weg zum Pflichtenheft Requirements Engineering a Einf hrung Der Begriff des Pflichtenhefts hat sich als Bezeichnung f r die detaillierte Beschreibung der Anforderungen an ein Produkt Hardware und Software im Bereich der Praxis der Softwareentwicklung durchgesetzt Auch in der juristischen Fachliteratur wird der Begriff allgemein als Definition von Vorgaben und Anforderungsspezifika f r Software verstanden Die Einf hrung neuer oder nderung bestehender Software setzt im Rahmen der Planung modellunabh ngig zun chst eine Erfassung der Einsatzbedingungen eine so genannte Ist Analyse voraus Das Softwarehaus muss also den Ausgangspunkt f r die Entwicklungsarbeit den Punkt von dem aus die Reise beginnen soll kennen Je komplexer die vorgefundene Situation um so umfangreicher f llt demgem eine Ist Analyse aus Heute sind kaum mehr Situationen denkbar in denen ein Softwarehaus auf EDV freie Rahmenbedi
131. allerdings dem inneren Willen des Erkl renden eine Bedeutung f r die Auslegung zukommen lassen 32 Bamberger Roth Wendtland 133 Rn 25 Palandt Heinrichs 133 Rn 14ff 322 Soergel Hefermehl 133 Rn 25 102 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland Leistungsverzeichnisse heranzuziehen Bei formbed rftigen Erkl rungen sind dabei nach teilweise und v a in der Rspr vertretener Auffassung nur diejenigen au erhalb der Urkunde liegenden Umst nde verwertbar die in der Urkunde zumindest angedeutet sind Vertr ge m ssen bei ihrer Auslegung nach 157 dar ber hinaus die Grunds tze von Treu und Glauben ber cksichtigen also im Hinblick auf ein Ergebnis gedeutet werden welches die berechtigten Belange beider Parteien angemessen ber cksichtigt und mit den Anforderungen des redlichen Gesch ftsverkehrs im Einklang steht Beachtung verlangt nach 157 weiter die zum Zeitpunkt des Vertragsschlusses geltende Verkehrssitte die infolge ihres Charakters als Norm unabh ngig von ihrer Kenntnis G ltigkeit beansprucht Unter Kaufleuten ist der Handelsbrauch in 8 346 HGB ausdr cklich als Richtlinie f r die Bedeutung und Wirkung von Handlungen aufgenommen Eine weitere Auslegungsregel findet sich in 305c Abs II BGB wonach Zweifel bei der Auslegung zu Lasten des Verwenders von Allgemeinen Gesch ftsbedingungen gehen Der hier zugrunde liegende Schutzgedanke wird ber All
132. alt von Lebenssachverhalten wobei der Schwerpunkt seiner Anwendung auf dem Bausektor liegt Vertragsgegenstand ist jedenfalls eine entgeltliche Wertsch pfung Diese kann nach 631 Abs 2 BGB neben der Herstellung oder Ver nderung einer Sache auch in einem anderen Erfolg bestehen Im Vordergrund steht im Unterschied zum Kaufvertrag nicht die bertragung von Eigentum und Besitz sondern das Ergebnis einer T tigkeit des Unternehmers 406 Redeker IT Recht a a O Rn 436 7 Schaub CR 1993 S 329 vgl auch M ller Hengstenberg CR 2005 S 385 08 Schubert Haase ZKM 2003 S 251 2 U v 16 7 2003 BGHZ 151 S 330 bez glich eines Forschungs und Entwicklungsvertrages 410 U v 23 1 1996 NJW 1996 S 1745 41 Weyers Typendifferenzierung im Werkvertragsrecht AcP 182 1982 S 60 12 M Ko Soergel 631 Rn 2 43 MUKo Soergel 631 Rn 5 diesen g ngigen Begriff halt Voit f r wenig hilfreich und verweist allerdings mit wenig Konkretisierungsgewinn auf eine typologische Abgrenzung nach Fallgruppen und die Angemessenheit der Rechtsfolgen Bamberger Roth Voit 631 Rn 4 414 Dies zielt haupts chlich auf unk rperliche Werke in denen das Werk lediglich als Abbildung in der Gedankenwelt existiert und es an jeder gegenst ndlichen Beziehung fehlt wie bei Theaterauff hrungen und Konzerten AnwK Raab Bd 2 Tb 2 8 631 Rn 11 15 Raab nennt Kaufvertr ge reine Sachverschaffungsvertr ge
133. atistisches Jahrbuch 2005 fur die Bundesrepublik Deutschland SJB D 2005 Wiesbaden 2005 Staudinger Julius von Begr Einl zum BGB 1 12 Verschollenheitsgesetz 12 Aufl Berlin 1995 ders BGB Wiener UN Kaufrecht 12 Aufl Berlin 2005 zitiert Staudinger Bearbeiter 242 T Thaller Georg Erwin Thewalt Stephan U C C V Volle Peter W Weick G nter Weyers Hans Leo Hrsg Weyers Hans Leo Z Zehnder Carl August Zilahi Szab Miklos G Zweigert Konrad K tz Hein Literaturverzeichnis Software und Systementwicklung Hannover 2002 Der Softwareerstellungsvertrag nach der Schuldrechtsreform Diss M nchen 2004 2003 Edition Philadelphia Chicago 2003 Rechtliche Einordnung der EDV Systemvertr ge CR 1996 S 139 Vereinbarte Standardbedingungen im deutschen und englischen Bauvertragsrecht M nchen 1977 Europ isches Vertragsrecht Baden Baden 1997 Typendifferenzierung im Werkvertragsrecht in AcP 182 1982 S 60 Informatik Projektabwicklung 2 Aufl Stuttgart 1991 Wirtschaftsinformatik M nchen Wien 1993 Einf hrung in die Rechtsvergleichung auf dem Gebiete des Privatrechts 3 Aufl T bingen 1996 243
134. aulichen prinzipieller Zusammenh nge schwerlich quantifizierbarer Merkmale In der Praxis werden die Gegebenheiten von Projekt zu Projekt verschieden einen anderen Winkel f r die Darstellung der Bedarfsgerechtigkeit erfordern z B abh ngig vom Verh ltnis funktionaler und nicht funktionaler Anforderungen 2353 Kapitel 3 Rechtliche Rahmenbedingungen in den USA 2 AMERIKANISCHER TEIL Kapitel 3 Rechtliche Rahmenbedingungen fur Softwareentwicklungsvertrage A Einordnung und Bedeutung der Rechtsquellen Das amerikanische Recht unterscheidet sich bereits in systematischer Hinsicht grundlegend vom deutschen Zwei Besonderheiten sind dabei f r den Untersuchungsgegenstand in erster Linie zu ber cksichtigen Das Verh ltnis von Gesetz und Rechtsprechung und das Primat der einzelstaatlichen Regelung Im Verh ltnis von Gesetz und Rechtsprechung dominiert im angloamerikanischen Rechtskreis die Entscheidung des Gerichts Nicht das abstrakte Gesetz sondern die im gerichtlichen Verfahren gewonnene Erkenntnis wird zur wegweisenden Regel Die Gesetzgebung kann damit nur eingeschr nkt als Ausgangspunkt oder Eckpfeiler f r die rechtliche Beurteilung von Vertr gen herangezogen werden Codes sind in der Common Law Rechtskultur als eine Hilfe nicht jedoch als Grundlage der Rechtsfindung zu verstehen Die Bedeutung des Wortlauts der vertraglichen Vereinbarung sticht als individuelles Element demgegen ber deutlich hervor und dr ng
135. ber ergriffen werden k nnen Ill Grenzen der Begriffssysteme The legal order is seen as something static Law is viewed not as a process for the perception and resolution of problems but as a set of established rules and institutions Dieses Urteil eines Common Law Juristen ber das Civil Law ist nach den Erkenntnissen aus den untersuchten Muster Vertr gen in dieser Pauschalit t sicher unzutreffend In der 567 Er d rfte bei dem geringen politischen Potential der Regelung auch nicht mit gr erem Widerstand des Bundesrates zu rechnen haben der sich dann auch blicherweise auf Anpassungen im Detail beschr nkt 568 Diesen Kampf haben beispielsweise der Teilzeit Wohnrechtsvertrag 481ff BGB der Reisevertrag 651a ff der Darlehensvermittlungsvertrag 88 655a ff und die Gesch ftsbesorgungsvertr ge aus der Finanzwirtschaft 676a ff gewonnen Ihren Sieg verdanken alle genannten Beispiele bis auf den Darlehensvermittlungsvertrag allerdings dem europ ischen und nicht dem deutschen Gesetzgeber 59 Merryman The Civil Law tradition a a O S 69 217 Kapitel 8 Schlussfolgerungen Vertragsgestaltung kommt zum Ausdruck wie das Recht in der rechtlichen Praxis verstanden und angewandt wird Und hier zeigen sich nicht die Unterschiede die nach dem vorstehenden Zitat zu erwarten waren Deutsche und amerikanische Vertragsjuristen versuchen gleicherma en L sungen f r die komplexe Au
136. bh ngt 9 Calamari Perillo a a O 16 18 S 631 39 Kapitel 3 Rechtliche Rahmenbedingungen in den USA C Statute Law I U C C 1 Anwendbarkeit Der U C C ersetzt im Rahmen seines Anwendungsbereiches das Common Law Die Bedeutung des U C C ersch pft sich dabei nicht in der Regelung der von ihm ausdr cklich erfassten Materie Das Statute Law muss infolge des oben angesprochenen Verh ltnisses von Gesetz und Rechtsprechung als weiches Recht verstanden werden Die Gerichte sind einerseits an einer Rechtsfortbildung des angewendeten Rechts nicht gehindert andererseits zu einer Anwendung der in unanwendbarem Recht verk rperten Prinzipien in der Lage So hei t es im offiziellen Kommentar zu U C C 1 103 U C C 2003 Edition Philadelphia Chicago 2003 S 23 Courts have recognized the policies embodied in an act as applicable in reason to subject matter which was not expressly included in the language of the act They have done the same where reason and policy so required even where the subject matter has been intentionally excluded from the act in general Nothing in this act stands in the way of continuance of such action by the courts Der U C C wird von den Gerichten demgem h ufig als Quelle fur das Common Law herangezogen und zwar dem Zitat gem auch in F llen in denen eine direkte Anwendung ausgeschlossen ist 150 U C C 2 102 151 Die Bedeutung des off
137. bindung zwischen dem Lizenzgeber und dem Lizenznehmer wird hierdurch nicht begr ndet Hier klingt das Element gemeinsamer Verantwortung ebenfalls an 133 Kapitel 6 Empirischer Befund in Deutschland BA und MA belassen es bei der Bestimmung des Vertragsgegenstands bei einer im Hinblick auf den Erfolg allgemeineren Formulierung Nach BA 8 1 Projektvertrag Der AG beauftragt hiermit den AN das in diesem Vertrag umschriebene Softwareprojekt durchzuf hren Die Leistungen sind insbesondere a Lieferung von Standardsoftware b umfassende Parametrisierung nderung und Erweiterung dieser Software c Tests Installation und Schulung Leistungsziel ist dass die Software getestet und betriebsfertig auf der Hardware des AG installiert ist In 1 Vertragsgegenstand hei t es bei MA Gegenstand des Vertrages ist das vom Hersteller zu entwickelnde und dem Anwender zu berlassende Computerprogramm XY Software einschlie lich Benutzungsanleitung Quellcode Herstellerdokumentation sowie weiterer schriftlicher Materialien zur Produktbeschreibung nachfolgend zusammenfassend als Software bezeichnet GL BVB und SN S nehmen bereits im Hinblick auf die Beschreibung des Vertragsgegenstands ausdr cklich Bezug auf die konkreten Anforderungen des Softwarebestellers GL 1 3 Vertragsziel Ziel des Austauschvertrages ist es gegen Geldleistung eine speziell auf die betrieblichen Anforderungen des Kunden im Werk
138. bis zu 300 Entwickler in bis zu 50 Teilprojekten ber viele Monate zusammen wobei r umliche Entfernungen keine Rolle spielen Zur Veranschaulichung Eine Arbeitsgruppe des deutschen Softwarehauses in Indien bereitet ein Modul vor welches in den USA mit anderen Modulen zusammengefasst und in Deutschland durch ein drittes Team beim Softwarebesteller implementiert werden soll wobei der Softwarebesteller in zwei dieser Arbeitsgruppen mit mehreren Mitarbeitern vertreten ist und durch ein drittes Team welches in der Planungsphase ma geblich beteiligt war die Test und Installationsphase vorbereitet und berwacht Aus Sicht des BGB wird hier ein unbekannter Vertragsgegenstand Software in nicht vorgesehener Form der Zusammenarbeit aus Mitarbeitern von Auftraggeber und nehmer zusammengesetzte Projektteams m glicherweise in Kombination mit Subunternehmerbeteiligung in unbekannter Vorgehensweise zyklische Abwicklung ber einen langen Zeitraum mindestens mehrere Monate h ufig mehrere Jahre abgewickelt Weyers hat als Ergebnis seiner eingehenden Untersuchung des Werkvertragsrechts herausgestellt dass die gleichen Fragen in verschiedenen Kombinationen und mit geringen Abwandlungen bei den unterschiedlichsten Einzelvertr gen immer wieder auftauchen und auf 579 S o Kapitel 2 580 Weyers AcP 182 1982 S 60 73 223 Kapitel 8 Schlussfolgerungen einen berschaubaren Satz von Regelungsproblemen begrenzt sind Deshalb
139. bt es keine einheitliche Kodifikation des Vertragsrechts Nach der Kompetenzverteilung der US amerikanischen Verfassung ist die Regelung des Vertragsrechts den Einzelstaaten vorbehalten Damit dies nicht zu 50 g nzlich verschiedenen Systemen in einem sprachlich kulturell und wirtschaftlich verbundenem Wirtschaftsraum f hrt existieren sog Uniform Laws Diese haben allerdings nur Vorbildfunktion default rule d h sie k nnen m ssen aber nicht von den Einzelstaaten umgesetzt werden Im amerikanischen Recht gibt es kein besonderes Schuldrecht i S des BGB das versucht alle Vertragsarten zu erfassen Insbesondere spezielle gesetzliche Regelungen f r die Herstellung eines Werkes Werkvertragsrecht sind nicht vorhanden Im Rahmen des Untersuchungsgegenstandes muss daher auf allgemeinere Regelungen zur ckgegriffen werden F r das amerikanische Recht sind dabei vor allem der U C C und die Restatements of the Law of Contracts von besonderer 131 Das Amendment X aus 1791 zur amerikanischen Verfassung besagt The powers not delegated to the United States by the Constitution nor prohibited by it to the states are reserved to the states respectively or to the people Dies verk rpert ein den Art 30 70 GG innewohnendes Prinzip Das b rgerliche Recht wird jedoch nicht wie in Art 74 Abs 1 Nr 1 GG dem Bund zugeordnet Wie der Uniform Commercial Code siehe unten S 40 133 Der U C C ist von allen Staaten und
140. ch ber die Anpassungen des Erstellungsscheins 5 Kommt keine Einigung zustande hat der Kunde das Recht die Erstellung des Pflichtenheftes schriftlich f r gescheitert zu erkl ren Das Projekt wird in diesem Fall nicht durchgef hrt der Anbieter erh lt f r bereits geleistete Arbeit eine Zusatzverg tung nach Erstellungsschein ES 5 5 soweit nicht eine aufwandsabh ngige Verg tung geschuldet ist 7 2 Abnahme Geltung 1 Das Pflichtenheft ist nach Fertigstellung vom Kunden innerhalb von 30 Arbeitstagen abzunehmen Der Kunde pr ft das Pflichtenheft auf Richtigkeit und Vollst ndigkeit 2 Das abgenommene Pflichtenheft wird Teil des Erstellungsscheines ES 1 1 1 Falls und soweit Widerspr che zur Aufgabenstellung des Kunden bestehen hat das Pflichtenheft Vorrang 3 Mit der Abnahme des Pflichtenheftes beginnt der Anbieter mit der Realisierung 7 3 M ngel des Pflichtenheftes 1 Fehler die der Kunde aus dem Pflichtenheft erkennen kann sind bei Abnahme zu r gen sp testens bevor der Anbieter mit Aufwendungen f r die Umsetzung des Pflichtenheftes beginnt Werden erkennbare Fehler sp ter ger gt so tr gt der Kunde die Mehrkosten die aus der nachtr glichen Ber cksichtigung der R ge entstehen SEHE Kapitel 6 Empirischer Befund in Deutschland 2 Fehler die der Kunde nicht aus dem Pflichtenheft erkennen kann k nnen geltend gemacht werden wie vom Anbieter zu vertretende Fehler bei der Umsetzung des Pflichtenheftes
141. chland beide f r die Vertragsauslegung anzuwenden wobei 133 BGB auf ein subjektives Element den wirklichen Willen 157 BGB dagegen auf ein objektives Element Treu und Glauben sowie die Verkehrssitte zielt Die Auslegung des vorhandenen d h erkl rten Parteiwillens folgt vorrangig den subjektiven Kriterien des 133 w hrend die erg nzende Vertragsauslegung nach 157 sich anhand objektiver Kriterien auf einen hypothetischen Parteiwillen bezieht Beide Vorschriften zusammen dienen dazu den Inhalt der Leistungspflicht das rechtliche Wollen zu ermitteln F r die Ermittlung der auslegungsrelevanten Umst nde gelten in einem Prozess die Regeln ber Behauptungs und Beweislast Die anschlie ende Ermittlung des Parteiwillens nach Auslegungsgrunds tzen stellt demgegen ber eine richterliche W rdigung dar bei der keine Bindung an das Parteivorbringen besteht Entscheidend ist bei der Auslegung das von den Vertragsparteien verfolgte Ziel der Vereinbarung Es kommt auf die Interessenlage und den wirtschaftlichen Zweck des Gesch ftes an Auszugehen ist vom Wortlaut der Erkl rung Ma geblich ist die Verst ndnism glichkeit dessen f r den die Erkl rung bestimmt ist Als f r die Auslegung relevante Begleitumstande sind sodann das Gesamtverhalten der Parteien und v a die Entstehungsgeschichte wie Vorverhandlungen Abwicklung fr herer Gesch fte m ndliche u erungen der Beteiligten bei
142. chlie lich des Einbeziehens sachverst ndiger und gerichtlicher Hilfe erfolgreich abgeschlossen Das Softwarehaus wird als Auftragnehmer der Softwarebesteller als Auftraggeber bezeichnet Der Auftraggeber stammt aus der Baubranche und verf gt ber mehrere Standorte Er wollte seine vorhandene EDV auf ein neues System umstellen 169 52 w 52 A 52 a Kapitel 6 Empirischer Befund in Deutschland ein Produktionsbetrieb in Nordrhein Westfalen nachfolgend MiN beteiligt Das dritte betrifft ein Softwarehaus in S dhessen und einen Softwarebesteller der ffentlichen Hand im Siegerland nachfolgend S S l Vertragsart MiO gliedert sich in den hier untersuchten Hauptvertrag und sechs Beilagen die z B Detailinformationen zu den Anforderungen des Auftraggebers Beilage 1 technischen Voraussetzungen wie Endger te Schnittstellen Systemkomponenten Beilage 2 Installation Beilage 3 Programmierrichtlinien des Auftragnehmers Beilage 5 Beispiele f r Source Code Kommentare Beilage 6 enthalten Der Vertrag ist bezeichnet als Werkvertrag ber die Lieferung Installation und Wartung einer Gesamtl sung f r Vertrieb und Produktion von x Die Grundregelung f r den Vertragsgegenstand ist in 3 Vertragsgegenstand enthalten Die Satznummerierung und die Nummerierung der Unterpunkte wurde zur besseren Zitierbarkeit erg nzt Sie sind im Original nicht vorhanden Gegenstand dieses Vertra
143. cht zwangsl ufig ja nicht einmal logisch Gedanken Programme und Gehirn K rper bedingen einander da der Mensch ohne Gehirn nicht denken kann Sind Gedanken k rperliche Gegenst nde weil das Gehirn ein k rperlicher Gegenstand ist Strom und Computer sind in gleicher Weise untrennbar miteinander verkn pft Der Computer ist ohne Energie ein St ck Metall der Strom ohne Computer nicht wahrnehmbar Kann Strom deswegen als k rperlicher Gegenstand bezeichnet werden 59 An dieses Kriterium wird f r die Definition von Software angekn pft Vgl Brockhaus Computer und Informationstechnologie unter Software jede immaterielle eben weiche Komponente eines Computersystems im Unterschied zur greifbaren Hardware Grieser Irloeck unter Software alles was im Gegensatz zur Hardware nicht physikalisch vorhanden also nicht anfassbar ist Feretti unter Software berbegriff f r alle immateriellen Bestandteile eines Computers 560 S o Kapitel 3 C I 2 S 42 und Kapitel 5 B I 2 b S 109 und Fn 379 212 Kapitel 8 Schlussfolgerungen Der Sourcecode eines Programms in seiner einfachsten Form sieht z B so aus PROGRAM Hallo Welt BEGIN Write Line Hallo World END Die Ausf hrung dieses Programms wird zur Bildschirmausgabe Hallo World f hren Worin ist hier eine Sacheigenschaft zu sehen Der Gegenmeinung ist zuzugestehen dass sie einen gewichtigen F rsprecher auf
144. chten des AG formuliert 1 1 Der AG verpflichtet sich die T tigkeiten des AN zu unterst tzen Insbesondere schafft der AG unentgeltlich alle Voraussetzungen im Bereich seiner Betriebssph re die zur ordnungsgem en Durchf hrung des Auftrages erforderlich sind Zu diesen Voraussetzungen z hlen u a dass der AG Arbeitsr ume f r die Mitarbeiter des AN einschlie lich aller erforderlichen Arbeitsmittel nach Bedarf ausreichend zur Verf gung stellt eine Kontaktperson benennt die den Mitarbeitern des AN w hrend der vereinbarten Arbeitszeit zur Verf gung steht die Kontaktperson ist erm chtigt Erkl rungen abzugeben die im Rahmen der Fortf hrung des Auftrages als Zwischenentscheidung notwendig sind Es handelt sich bei dieser Person um X der im brigen auch neben der Gesch ftsf hrung die Projektleitung wahrnimmt den Mitarbeitern des AN jederzeit Zugang zu den f r ihre T tigkeit notwendigen Informationen verschafft und sie rechtzeitig mit allen erforderlichen Unterlagen versorgt im Falle von Programmierarbeiten Rechnerzeiten inkl Operating Testdaten und Datenerfassungskapazit ten rechtzeitig ohne gesonderte Kostenberechnung und in ausreichendem Umfang zur Verf gung stellt Der AG steht daf r ein dass die im Rahmen des Auftrages vom AN gefertigten Berichte Organisationspl ne Entw rfe Zeichnungen Aufstellungen und Berechnungen nur f r seine Zwecke verwendet werden Soweit an den Arbeitsergebnissen d
145. chuldrecht Teilband 1 241 bis 610 M nchengladbach 2005 zitiert AnwK Bearbeiter Band 2 Schuldrecht Teilband 2 611 bis 853 M nchengladbach 2005 zitiert AnwK Bearbeiter B Balzert Helmut Lehrbuch Grundlagen der Informatik 2 Aufl M nchen 2005 Bamberger Heinz Georg Roth Herbert Hrsg Kommentar zum B rgerlichen Gesetzbuch M nchen 2003 zitiert Bamberger Roth Bearbeiter Bartl Harald Rechtliche Problematik der Softwarevertr ge BB 1988 2122 Bauer Indes M Witzel Michaela Individualsoftwareerstellung 8 651 und die Neugestaltung des Abnahmeverfahrens ITRB 2003 S 62 Baumbach Adolf Hopt Klaus J Handelsgesetzbuch 31 Aufl M nchen 2003 Blumenwitz Dieter Einf hrung in das anglo amerikanische Recht 7 Aufl M nchen 2003 Bormuth Ulrich Schmitz Karl Beteiligung der Anwender an der Softwareentwicklung AiB 1993 S 31 Braun Bernd berlassung von Computerprogrammen an den Anwender als Werkvertrag BB 1992 S 154 Brockhaus Computer und Informationstechnologie Mannheim Leibzig 2003 Brooks Frederick P EDV Projekte in den Griff bekommen K ln 1987 ders Management von Informatik Projekten M nchen Wien 1997 ders Vom Mythos des Mann Monats Bonn 1987 Br hl Adolf Peter Dr schel Das V Modell 2 Aufl M nchen 1995 Cc Calamari John D Perillo Joseph M The law of contracts 4 ed St Paul Minnesota 1998 California Transaction Forms Westlaw Database 9 59
146. computer systems and project management experience satisfactory to Licensor to act as coordinator of all Licensee activities in connection with the development of the Management System and to supervise all projects undertaken by Licensee in connection with the modification preparation installation and use of the Management System g convert or enter into a suitable agreement for Licensor to convert data files as required to interface with the Management System h in general to provide all information and access to the personnel needed to develop and implement the Management System VI Veranderungen Change Management Das Change Management wird in 4 Mustern behandelt In den Softwarehaus orientierten Mustern DaS V und RB V sowie FL ist es nicht geregelt Eine einfache ziemlich neutrale Form mit dem Schwerpunkt auf gemeinsamer Entscheidung ber nderungen findet sich bei DS Das nderungsverfahren kann hier von beiden Vertragspartnern in Form eines nderungsvorschlages eingeleitet werden Softwarebesteller und Softwarehaus diskutieren die Auswirkungen auf das Projekt und nehmen ggf einvernehmlich eine Vertragserg nzung vor Zum Schutz des Softwarebestellers ist eine Zustimmungspflicht des Softwarehauses vorgesehen wenn der Ver nderungswunsch reasonable und der Softwarebesteller die Kosten zu tragen bereit ist I Software Development Services c Either party may from time to time during the performance of the
147. ct Law richtungsweisende Juristen sind hier zu nennen Professor Williston Professor Arthur L Corbin and Professor E Alan Farnsworth Calamari Perillo a a O 1 6 S 15f 23 ow 23 23 a e 56 Kapitel 3 Rechtliche Rahmenbedingungen in den USA wegen der Schwierigkeit bei der Einordnung von Software in das Rechtssystem sehr umstritten Nicht selten fuhren rechtspolitische Erw gungen zu seiner Anwendung Dies erm glicht es sich auf die vertrauten Rechtsinstitute der implied und express warranties zu beziehen wobei der U C C insgesamt in hohem Ma e die Parteihoheit bei der Leistungsbestimmung anerkennt wie sich z B bei der M glichkeit der Haftungsfreizeichnung Disclaimer zeigt Die Definition der Leistung ist nichts anderes als die Beschreibung dessen was ich will Das Recht der USA geht von dem Grundsatz der Vertragsfreiheit aus Die Vertragspartner k nnen im Rahmen des Gesetzes nach eigenem Gutd nken vertragliche Bindungen eingehen Beschr nkungen ergeben sich aus der staatlichen Sozialkontrolle vor allem zu Gunsten eines potentiell schw cheren Vertragspartners Minderj hrigen Angestellten Mieters Verbrauchers etc Softwareentwicklungsvertr ge werden in der ganz berwiegenden Zahl zwischen Parteien geschlossen die keiner der typischerweise gesch tzten Gruppen angeh ren Die Grenzen sind daher weit gesteckt Eine wichtige Rolle bei der Ermittlung der geschuldeten Leistungen k
148. d Remedies the software will perform substantially in accordance with the specifications for the software RB V unter 13 Warranty the Management System will substantially conform to the specifications contained in Schedule A as modified by the Modifications listed in Schedule B RB U verlangt demgegenuber ohne Beschrankung dass die Software mit den vereinbarten Anforderungen Ubereinstimmt 5 5 System Requirements such applicaton shall comply with Licensee s requirements as disclosed in the Detailed Design Specifications und dass auch die Antwortzeiten des Systems sich innerhalb des vereinbarten Rahmens bewegen Noch weitergehend verlangt DaS U dass die Software die Bed rfnisse des Softwarebestellers wie sie in den Anforderungsbestimmungen formuliert sind erf llt 17 Warranties a Warranty Vendor as an expert in the field warrants that the system shall meet User s needs as defined in the approved Design Document and 244 Einzelheiten bei RB U unter 5 6 Terminal Response Time 78 Kapitel 4 Empirischer Befund in den USA in Exhibit A and shall be substantially free from programming errors and defects in workmanship and materials Hinsichtlich der Preisgestaltung findet sich in allen Mustern eine Fixpreisvereinbarung Bei den tendenziell ausgerichteten Mustern sind Zusatzleistungen entweder gesondert zu verg ten oder im Gesamtpreis i
149. das Vorgelegte wirklich das ist was erreicht werden soll 5 Dies kann soweit gehen dass der Aufwand f r die Bereitstellung von Altdaten den brigen Projektaufwand bersteigt siehe Zehnder a a O S 107 4 Auch f r die Bezeichnung dieses Abschnittes der Entwicklung gibt es keine einheitliche Terminologie es ist von Systemspezifikation vgl auch Maymon Cave Leitfaden des Software Projektmanagements Wiesbaden 1988 mit anschaulicher Grafik zur Verdeutlichung der Zusammenh nge auf S 46 Sollkonzept Suhl Blumstengel in Fischer Herold Dangelmaier Nastansky Suhl a a O S 333 und S 363ff oder auch Anforderungsspezifizierung vgl die Darstellung in Form eines Leitfadens bei Kargl a a O S 198ff die Rede teilweise ist eine Anforderungsdefinition im Modell gar nicht explizit vorgesehen vgl etwa bei Schwickert Axel Web Site Engineering Stuttgart Leipzig Wiesbaden 2001 S 159 Rupp Requirements Engineering und Management 2 Aufl M nchen Wien 2002 S 13 48 nach der Definition von Zehnder a a O S 40 48 Franz Techniken der modernen Software Entwicklung M nchen 1991 S 141 5 Kritisch insoweit Eschbach der das Pflichtenheft als Projektplan f r ungeeignet h lt a a O S 151 51 So formuliert Love Beginnen Sie niederzuschreiben was Sie als Anforderungen verstanden haben Lassen Sie diese Anforderungen vom Auftraggeber best tigen bevor Sie auch nur einen weiteren Arbeitsschritt unternehmen
150. den Funktion die von dem BVerfG deutlich best tigt werden Hier kommt auch zum Ausdruck dass es eine Bindung an Pr judizien d h an Entscheidungen anderer Gerichte nicht gibt Jedes Gericht kann und muss aufgrund der Sachlage im konkret zu entscheidenden Fall und auf Grundlage der geltenden Gesetze sein Urteil f llen Die Rechtsprechung auch der oberen und obersten Gerichte geh rt nicht zu den verbindlichen Rechtsquellen Dies schlie t eine Bindung etwa an st ndige Rechtsprechung oder eigene Pr judizien unter dem Gesichtspunkt des Vertrauensschutzes gleichwohl nicht aus In der Praxis zeigt sich dann auch die verst ndliche Tendenz Entscheidungen an dem prognostizierten Verhalten der oberen Gerichte auszurichten Im Alltagsgesch ft des Richtens wird das Rad nicht jedes Mal neu er sondern gefunden Il Das Prinzip Privatautonomie Im deutschen Recht lassen sich die Kernbestandteile der Regelungen f r Softwareentwicklungsvertr ge dem BGB entnehmen Anders als in den USA ist das Zivilrecht durch vom Bund ausgiebig genutzte Gesetzgebungskompetenz bundeseinheitlich geregelt Das BGB welches auch vor kurzem noch als Respekt gebietendes Kulturdenkmal bezeichnet wurde ist vom Grundsatz der Privatautonomie gepr gt Vor dem Hintergrund unbehinderten Marktzuganges der prinzipiell freien Verf gbarkeit von Waren und Dienstleistungen und der gleichberechtigten Marktstellung und Verhandlungsposition soll der
151. den neben Computer programming die Kategorien Prepackaged Software und Information Retrieval erfasst In diesen letzten beiden Kategorien wuchs die Anzahl der Beschaftigen von 1995 bis 2000 ebenfalls von 180 800 bzw 56 900 auf 299 900 bzw 243 000 hatte also ebenfalls einen erheblichen Anstieg zu verzeichnen der im Bereich des Information retrieval besonders auff llig ausf llt 11 Z B nach der Art der Softwareerstellung dem Grad der Spezialisierung und des Leistungsumfanges oder nach dem Anwendungsbereich Zilahi Szab M G Wirtschaftsinformatik M nchen Wien 1993 S 485ff 12 Zur Systemsoftware werden Betriebssysteme und Netzwerksysteme gerechnet Beispiele f r Systemsoftware sind Betriebssysteme wie Unix Linux Windows oder Netzwerksoftware wie Novell vgl Zilahi Szab a a O S 485ff 13 Beispiele f r Anwendungssoftware sind Textverarbeitung Word Word Perfect Open Office betriebswirtschaftliche Software z B SAP R3 oder sonstige aufgabenbezogene 5 Kapitel 1 Allgemeiner Teil Steuerung der internen Vorgange im Computersystem bzw im Computernetzwerk dient lost die Anwendungssoftware Aufgaben die der Benutzer ihr au erhalb der reinen Interaktion mit dem Rechner oder Netzwerk stellt Auf einer anderen Begriffsebene werden Individual und Standardsoftware unterschieden Individualsoftware wird speziell f r die Belange eines Auftraggebers hergestellt Eine individuelle L sung versucht den spezifischen situat
152. der geschuldeten Leistung sowie ggf der einzigartigen Expertise eines Vertragspartners selbst schaffen Doch auch wenn eine Leistungsbestimmung erfolgt so haben im Konfliktfall die Gerichte die grunds tzliche Frage zu kl ren um welchen Vertragstypus es sich handelt insbesondere ob goods oder services geschuldet sind Im Ergebnis wird eine Durchf hrung des Vertrages ber die Rechtsfigur der specific performance nur in Ausnahmef llen zu erzwingen sein 144 Als Begr ndung hierf r wird die Schwierigkeit der berwachung einer Vertragsdurchsetzung und die Unangemessenheit des Erzwingens einer Fortsetzung unerw nschter pers nlicher Beziehungen forcing the continuance of a distasteful personal relationship Calamari Perillo a a O S 617f und 623 angegeben Die Schwierigkeit der berwachung wird jedoch in zunehmendem Ma e nicht als berzeugendes Argument angesehen ndeed the willingness of courts of equity in recent decades to take on supervision of complex school desegregation and legislative reapportionment plans would indicate that supervision of contract performance is a burden that courts can deal with Calamari Perillo a a O S 623 145 Calamari Perillo a a O S 619 146 Calamari Perillo a a O S 622 147 Calamari Perillo a a O S 611 und S 366 148 So hie es im Restatement 1st 364 dass Billigung oder Zur ckweisung der specific performance von the moral standards of enlightened judges a
153. der civil law Rechtswissenschaftler verenge den Blick auf die rechts dogmatische Frage nach dem was ist und vermeide die Frage danach was sein soll 219 Kapitel 8 Schlussfolgerungen ordentliche Qualitat schleichen wenn einmal ein Einfallstor fur eine Begrenzung der Einstandspflicht ge ffnet w rde Dem lie e sich aus Sicht des Softwarehauses in diesem Fall aus Angst vor b swilligen Softwarebestellern motiviert entgegenhalten der Anspruch auf ein fehlerloses Produkt lie e jedes Softwareprojekt zu einem Va banque Spiel werden Das Softwarehaus sei den Launen des Bestellers ausgeliefert da dieser sich aus dem Pool der unvermeidbaren Fehler nach eigenem Gutd nken und zum eigenen Vorteil bedienen k nne Auf Misstrauen gr ndende Vertragsformulierungen bilden keine solide Basis f r ein Langzeitprojekt wie z B einen Softwareentwicklungsvertrag Setzt sich eine Vertragspartei ber das Unwohlsein der anderen Vertragspartei in diesem Punkt hinweg so ist der erste Schritt f r einen sp teren Konflikt bereits gegangen In einem Streitfall wird es sehr wahrscheinlich nie darauf ankommen ob eine theoretisch verlangte oder nicht erforderliche Fehlerfreiheit zu praktischen Konsequenzen f hrt Wie oben dargestellt ist es nach der Judikatur bereits keineswegs selbstverst ndlich dass berhaupt ein pr zises Leistungsergebnis mit hinreichender Sicherheit ermittelt werden kann Haben die Parteien eine klare Vereinbarung getro
154. derungen der Informationstechnologie verglichen Kapitel 7 Softwareentwicklungs vertrage A Software Engineering B Bedeutung der Informationstechnologie Der Weg in die Informationsgesellschaft kann anhand ausgewahlter statistischer Daten nachvollzogen werden Im Vordergrund stehen dabei die anhand offizieller Statistiken nachvollziehbaren Bestandsdaten an Hardware und der Computernutzung in Unternehmen sowie ausgew hlter Kennzahlen 233 Kapitel 1 Allgemeiner Teil aus dem seit kurzem statistisch separat erfassten Wirtschaftsbereich der Datenverarbeitung und Datenbanken Die Ausstattung privater Haushalte stellt sich danach wie folgt dar Gegenstand 1999 2004 PC station r 43 1 58 7 PC mobil Notebook Laptop 4 9 13 3 Internetanschluss zugang 10 7 47 1 In den USA stieg der Anteil der PC Nutzung zwischen 1998 und 2002 von 458 6 auf 653 pro 1 000 Einwohner die Ausstattung war im Vergleich zu Deutschland noch deutlich besser Die Zahl der Internet Hostrechner wuchs in Deutschland von 1 449 915 in 1998 USA 30 489 463 auf 2 603 007 in 2003 USA 162 208 993 Deutlich mehr als die Halfte aller Haushalte verfugte in Deutschland in 2004 ber einen PC und davon konnte ein gro er Anteil das Internet nutzen Die erhebliche Wachstumsrate im Bereich der Internetzug nge und der Hostrechner zwischen 1999 1998 und 2004 2003 kann als Indikator daf r dienen dass das Internet ein
155. derweitig absetzbar sind Wird Software als Sache eingeordnet findet nach der aktuellen Fassung des 651 BGB Kaufvertragsrecht Anwendung Die hier untersuchte Individualsoftware wird soweit die Sacheigenschaft angenommen wurde ausnahmslos als nicht vertretbar angesehen Ob Software eine Sache im Sinne des Gesetzes darstellt wird in der Literatur bis in die j ngste Zeit kontrovers diskutiert Bejaht wird es vor allem mit dem Hinweis auf die Notwendigkeit der Verk rperung Zur Verk rperung des Programms sei die Funktionsf higkeit des Computers zwingend und ohne Speicherung k nne kein Programm 372 OLG Hamm a a O CR 1992 S 206 373 OLG Karlsruhe Juris KORE541772003 Rn 42ff 374 OLG Hamm U v 8 3 89 NJW 1990 1609 1610 in Form von Ausdrucken und Bildschirmausz gen 375 LG Karlsruhe U v 13 5 93 CR 1991 544 547 376 Palandt Heinrichs 91 Rn 2 377 Palandt Sprau 651 Rn 8 378 Vgl die Dissertationen von Krau einerseits a a O Software ist eine Sache S 18 und Thewalt andererseits a a O Software ist keine Sache S 45ff 48 108 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland seine vorgegebenen Funktionen ausf hren Dem Begriff Software sei eine Materialisierung immanent Was im Falle von Software ver u ert werde sei weder ein immaterielles gegenstandsloses geistiges Gut noch ein Nutzungsrecht sondern eine Ware n mlich das verk rperte und dokumentier
156. deutlich einfacher und hilfreicher den Fokus von der Frage Was ist Software auf die Frage Wie k nnen die im Zusammenhang mit Software auftretenden rechtlichen Probleme gel st werden zu lenken F r diese Untersuchung kann die Frage weiter pr zisiert werden Welche rechtlichen Regeln unterst tzen Softwareentwicklungsvertr ge Diese Formulierung ist bewusst gew hlt Sie beruht auf dem Standpunkt dass das Recht dem Menschen dienen muss und nicht der Mensch dem Recht Die Besch ftigung mit der rechtlichen Auffang L sung oder besser Begleitung eines tats chlichen Ph nomens sollte eine Frage nach der optimalen Gestaltungsform f r eine m glichst gro e Anzahl von Menschen sein Eine Rechtsordnung in der wir gewohnt sind neue F lle in ein System geschriebener Gesetze einzuordnen tut sich scheinbar mit Antworten schwerer als ein System das eine Antwort von Fall zu Fall geben kann Doch auch dieser Schein tr gt Ein am Gesetz ausgerichtetes Rechtssystem wie das deutsche lehrt eine m glichst pr zise Subsumtion des Sachverhalts unter den vom Gesetzgeber vorgegebenen Tatbestand Dabei trifft der Gesetzgeber auf die f r alle Rechtsordnungen geltende Realit t der wunderbaren Vielf ltigkeit dieser Welt Wie kann diese in das spr de Gewand von Rechtsnormen gekleidet werden F r die L sung dieser eigentlich unl sbaren Aufgabe bedient das Recht sich des Tricks der Abstraktion Auf diese Weise werden K
157. development of a particular Product provide written notice to the other party proposing changes to the applicable Specification or the schedule Change Proposal Following a Change Proposal the parties shall promptly meet to determine the financial and schedule impact if any and whether and with what modifications the proposed change is mutually agreeable No Change Proposal will have any contractually binding effect until formally agreed to in writing by both parties provided however that if XXXXX initiates a Change Proposal and agrees to pay Developer s additional fees to make such change Developer may not refuse to accept any reasonably requested Change Proposal 74 Kapitel 4 Empirischer Befund in den USA DaS U bestimmt bestellerfreundlicher dass nderungen an und Erg nzungen zu den Spezifikationen infolge ver nderter Rahmenbedingungen auftreten k nnen und erlegt dem Softwarehaus f r diesen Fall die Pflicht auf den Softwarebesteller ber daraus resultierende Mehrarbeit unter Angabe von Preis und Terminplan nderungen zu informieren Die Zusatzarbeiten m ssen vom Softwarebesteller autorisiert und dann vom Softwarehaus zu Standardpreisen um 20 reduziert durchgef hrt werden 2 Project Phases a Phase I System Definition v The design Document is subject to further supplementation or modification after approval of it necessitated by changing or newly recognized business needs and requirements If such supp
158. diese 182 Kapitel 6 Empirischer Befund in Deutschland fristgerecht anfordert und es der laufende Betrieb erlaubt Eine Verz gerung der Bereitstellung von Informationen verhindert die kurzfristige Fehlerbeseitigung bzw Lokalisierung 2 Der Auftraggeber wird dem Auftragnehmer zur Anpassung des Vertragsgegenstandes an das Datenbanksystem ORACLE eine Lizenz dieses Datenbanksystems leihweise auf Dauer dieses Vertrages zur Verf gung stellen soweit ORACLE diesem Vorgang zustimmt 3 Sollte ORACLE berechtigterweise nicht zustimmen erwirbt der Auftraggeber f r den Einsatz beim Auftragnehmer die kleinstm gliche ORACLE Lizenz z B f r Novell die dem Auftragnehmer eine Programmentwicklung gestattet und stellt sie gem obigem Punkt zur Verf gung Der Auftragnehmer wird anstreben ORACLE Business Partner zu werden 4 Die Erstellung der Druckroutinen f r Auftragspapiere wird nach den Anweisungen und Vorlagen des Auftragnehmers durch den Auftraggeber erfolgen 5 Der Auftraggeber wird f r alle vertragsgegenst ndlichen Installationen der Software eine zentrale Verwaltungsstelle einrichten die bei Problemen als First Level Support fungieren wird und neue Versionen Upgrades und fehlerbereinigte Versionen der Software an alle Systeme verteilen wird Anfragen an den Auftragnehmer werden nur von diesem First Level Support oder von X get tigt 6 Die Schulung des Anwenderpersonals des Auftraggebers geschieht durch das Personal des
159. dings weniger deutliche Konturen Redeker stellt zunachst fest es best nde kein Anspruch des Bestellers auf nderungen Schneider sieht einen praktisch bedeutsamen Fall von Anderungen darin dass Spezifikationen erst im Verlauf des Projektes vorgenommen wurden Konkretisiere der Besteller seine zunachst allgemeinen Vorgaben abschnittsweise so verschwimme die Projektverantwortung Schneider bezeichnet es als nichtad quate Risikoverlagerung wenn der Besteller der seine Vorgaben nicht sorgfaltig erarbeitet durch kompensierende Pflichten des Auftragnehmers entlastet werde Allgemeiner will Nicklisch danach unterscheiden aus wessen Verantwortungsbereich die Projektst rungen kommen K men sie aus dem des Softwarehauses so k me weder eine zus tzliche Verg tung noch eine Fristverl ngerung in Betracht Stamme sie aus der Sph re des Bestellers so sei dagegen sowohl Fristverl ngerung als auch Mehrverg tung geschuldet Bei neutraler Projektst rung m sste jeder seine Nachteile selbst tragen die Fristen w rden also verl ngert ohne dass allerdings eine zus tzliche Verg tung anfalle Wie die Verantwortungsbereiche abgegrenzt werden k nnen bleibt dabei allerdings offen Vil UN Kaufrecht CISG Neben dem BGB bietet sich f r Vertr ge mit internationaler Beteiligung das UN Kaufrecht CISG als Rechtsquelle an Es ist von der Bundesrepublik Deutschland am 21 12 1989 ratifiziert worden und mit Wirkung
160. dison zu bedanken der mich bei der Suche nach Material sehr hilfreich unterst tzt hat Die Vertr ge stammen aus der sehr umfangreichen Datenbank EDGAR der US Securities and Exchange Commission http www sec gov edgar shtml sowie der Datenbank CORI des Contracting and Organizations Research Institute der University of Missouri Columbia cori missouri edu search Vertrag zwischen First Data Resources Inc und Prodigy Services Company unterzeichnet im Dezember 1992 und die Weiter Entwicklung eines Buchungs Rechnungs und Mitgliederverwaltungssystems betreffend EDGAR Central Index Key No 0000824740 File No 0000950 109 98 004594 Die Parteien hatten im Mai 1986 einen Vertrag ber die Entwicklung eines Subscription Management Systems SMS abgeschlossen Dieses System sollte unter dem hier untersuchten Vertrag weiterentwickelt und um ein Member Administrative System MAS erg nzt werden Das Softwarehaus wird im Vertragstext FDRI der Softwarebesteller Prodigy genannt Rahmenvertrag zwischen der American Telephone and Telegraph Company und der Evolving Systems Inc aus dem Jahr 1998 EDGAR Central Index Key 0001052054 File No 333 43973 Das Softwarehaus wird im Vertragstext als Supplier der Softwarebesteller als Company bezeichnet 79 24 24 on 24 25 25 25 N Kapitel 4 Empirischer Befund in den USA OMT Technologies und einem Unternehmen in Los Ang
161. dung anhand der Frage ob Kosten und Termine eingehalten wurden und Vorprodukte vorliegen sowie dokumentiert die Pr fungen und wertet sie aus Br hl Dr schel a a O S 25 26 A7 Kapitel 2 Softwareentwicklung in der Praxis System SWE 1 SWE 9 System System Anforderungs System Ebene analyse und Entwurf Integration Systemanforderungen Systemarchitektur Handbuch System Integrationsplan Informationen gt DV Segment SWE 2 SWE 8 Segment DV Anforderungs DV Integration Ebene analyse und Entwurf DV Anforderungen DV Architektur DV Integrationsplan gt ie SWE 3 SWKE Integration Implementierungsdok SWKE SW Anforderungs g Konfigurations analyse r SW Anforderungen einheits SWE 7 SWKE Ebene a SW Integration SWE 4 Grobentwurf Komponenten K SW Architektur Integration omponenten Ebene Schnittstellenentwurf SWKE Integrationsplan Komponente Implementierungsdokumente Modul SWE 5 Feinentwurf Modul Datenbank Datenkatalog Ebene SW Entwurf Implementierungsdokumente Datenbank Modul Legende ER Datenbank Pr f aktivit ten Implementierung Die Grafik macht auch hier deutlich dass einerseits eine klare zeitliche Reihenfolge gegeben ist andererseits die Ergebnisse immer wieder an den Vorgaben und den vorangegangenen Stufen zu messen sind st ndiger Pr fprozess nderungen
162. e Pflichtenhefterstellung durch Kunden Der Kunde erarbeitet zur Vorbereitung der Programmerstellung mit dem Anbieter ein Pflichtenheft Hierbei wird er vom Anbieter durch Beratung unterstutzt Variante Pflichtenhefterstellung durch Anbieter 1 Der Anbieter erarbeitet in einem Pflichtenheft die Aufgabenstellung die vom Anbieter durch Software Erstellung anschlie end zu l sen ist Der Anbieter hat hierbei den Ist und Soll Zustand f r die vorgesehene Anwendung zu beschreiben Der Anbieter steht f r die Richtigkeit und fachgerechte Durchf hrung der Erstellung dieser Vorgaben ein Die Erstellung erfolgt in laufender Abstimmung mit dem Kunden 2 Dem Kunden steht es frei aufgrund des vom Anbieter erstellten Pflichtenheftes den Erstellungsauftrag an einen Dritten zu vergeben In diesem Fall ist eine Verg tung f r die Pflichtenhefterstellung geschuldet deren H he im Leistungsschein n her zu bezeichnen ist 3 Der Kunde nimmt das Pflichtenheft ab Unrichtigkeiten oder Unvollst ndigkeiten des Pflichtenheftes sind vom Kunden bei oder nach Abgabe zu r gen sp testens aber vor dem Zeitpunkt zu dem der Anbieter mit der Programmerstellung auf der Grundlage des Pflichtenheftes beginnt R gt der Kunde zu einem sp teren Zeitpunkt M ngel die f r ihn vor diesem Zeitpunkt des Beginns der Programmerstellung erkennbar waren tr gt der Kunde die Mehrkosten die aus der nachtr glichen Ber cksichtigung dieser R ge entstehen F r nicht aus de
163. e Vertragsverletzung nach 280 BGB als Ergebnis versp teter Mitwirkung bzw den Annahmeverzug zu vermeiden Nicht zuletzt diese Intention setzt neben der auch in den anderen genannten Vorschriften zum Ausdruck kommenden einseitigen Risikoverlagerung das Muster erheblichen Zweifeln hinsichtlich der Eignung zum Einsatz in der Vertragspraxis aus will der Verwender nicht sehenden Auges eine ggf gerichtliche Korrektur in Kauf nehmen V Besondere Pflichten des Softwarebestellers In allen Mustern mit Ausnahme von HE wird vom Softwarebesteller die Bereitstellung von Ressourcen verlangt S widmet den Mitwirkungspflichten eine eigene Anlage die allerdings nur drei Paragraphen enth lt 8 1 Installation 152 Kapitel 6 Empirischer Befund in Deutschland Die Installation des Lizenzproduktes erfolgt durch den Lizenzgeber Der Lizenznehmer verpflichtet sich die nachfolgenden Mitwirkungspflichten zu erf llen 2 Zugang Dem Lizenzgeber bzw dessen Beauftragten ist zum Zweck der Installation nach Vorank ndigung der Zugang zu den Rechenanlagen des Lizenznehmers zu gestatten 3 Leistungen des Lizenznehmers 1 Der Lizenzgeber erh lt vom Lizenznehmer einen eigenen Raum zur Verf gung gestellt soweit der Lizenzgeber sich f r die Erbringung der Leistungen aus dem Lizenzvertrag beim Lizenznehmer aufh lt Der Lizenzgeber ist dabei berechtigt das Telefon sowie sonstige Kommunikationseinrichtungen auf Kosten des Lizenznehmers in An
164. e dass hier Uber viele Jahre hinweg eine Vielzahl von f hrenden amerikanischen Juristen ma geblich mitgewirkt hat unterstreichen die Bedeutung der Restatements als Referenz von kaum bersch tzbarer Tragweite Der U C C dient in erster Linie als Auffangregelung Ob er auf Softwareentwicklungsvertr ge angewendet werden kann ist in erster Linie 282 Risetime s sole and exclusive remedy for any noncompliance with the warranty will be limited to repair correction or replacement of the nonconforming aspect of the licensed software by CCI Risetime Inc v Colorado Customware Inc 2003 US Dist LEXIS 19470 2003 Das Gericht berantwortete die Entscheidung einer Jury da es sich um eine tats chliche Frage der Vertragsauslegung handele Die Klage des Bestellers auf R ckzahlung der an das Softwarehaus entrichteten Verg tung wurde abgewiesen da die Mangelhaftigkeit der Software nicht nachgewiesen sei bzw die Fehler nicht nachweislich auf Mangelhaftigkeit der Software beruhten Some of the problems resulted from Sutter s failure to acquire the proper type of printer some resulted from what turned out to be the unanticipated inadequacy of the specifications that Sutter had prepared and accepted and some were attributable quite simply to the ordinary process of adjustment to a new system Sutter Insurance Co v Applied systems Inc 2004 US Dist LEXIS 3802 2004 Corbin a a O S 86 Als drei fur das US Contra
165. e a e aE 131 Il Bestandteile der Lieferung zz 4424442444444 136 Ill Spezifikationen 000404400RRRnnnnnnnnnnnnnnnnnnnnnnnnnenennnnn 139 IV Besondere Pflichten des Softwarehauses 145 V Besondere Pflichten des Softwarebestellers 152 VI Ver nderungen Change Management 44 gt 159 V Dissertation Softwareentwicklungsvertrage Inhaltsverzeichnis VII Zusammenhang zwischen Leistungsbestimmung und Einstandspflicht sera ea neeneenen 167 B Beispiele aus der Praxis 000004400000000000RRnnn nn nennen nennen 169 Vertragsart eh 170 ll Bestandteile der Lieferung 4 zz z44 2444244444 174 III Spezifikationen und Leistungsma stab e 178 IV Besondere Pflichten des Softwarehauses 4 180 V Besondere Pflichten des Softwarebestellers 182 VI Ver nderungen Change Management gt 185 WANS SOUS QOS are een EE EEEE 187 C Zusammenfassung und Ergebnis 2 42222424444442444 en 188 Kapitel 7 Vergleichende Darstellung Methoden der Leistungsbestimmung ae 192 PR ZielprazsoNna Re sala stan ETE 194 B Reaktionsmechanismen bei nderungen 198 C Einbindung des Softwarebestellers Mitwirkungspflichten 202 BD Oualit lskriterien s ansaee
166. e of Licensor consulting and professional personnel assigned to the project It is agreed that named manager shall be primarily responsible as the project manager The project manager shall devot his full time efforts to installation of the System The project manager shall make himself available if reasonably required and agreed to to be on site at the appropriate Licensee site during testing implementation and other necessary times Licensor shall provide sufficient staffing to enable the System to be installed in accordance with the implementation schedule Licensee shall have the right to require Licensor to replace any personell other than the project manager working on the project at Licensees premises whom Licensee deems in its reasonable sole discretion to be unfit or otherwise unsatisfactory In the event that named manager is no longer associated to Licensor the responsibilities shall be assumed by an individual with equivalent qualifications experience and knowledge of the appropriate System DaS U erweitert diese Moglichkeit zur Einflussnahme um Genehmigungspflichten und Anforderungen an die Art des Beschaftigungsverhaltnisses Zudem ist die Pflicht zum Austausch von Seiten des Softwarebestellers unerwunschtem Personal deutlich weiter gefasst 11 Project Leader Vendor agrees to provide the services of to personally supervise all of Vendor s work on the System and to prepare the Design Document All other personnel ass
167. echnik bei Vertragsabschluss Verfahrensnormen nach DIN ISO 9000ff oder andere in Hinblick auf die Qualit tssicherung gleichwertige Verfahrensregeln Grunds tze ordnungsm iger Datenverarbeitung Vorgaben der Bundesanstalt f r Finanzdienstleistungsaufsicht 2 Individualsoftware ist so zu erstellen und zu dokumentieren dass sie die Anforderungen an Zeitverhalten Ergonomie Fehlertoleranz Wartbarkeit auch durch Dritte und Interoperabilit t erf llt und durch m glichst einfache Schnittstellen mit der angrenzenden Standardsoftware verbunden ist Sicherung der Kompatibilit t zu k nftigen Standen der Standardsoftware 168 Kapitel 6 Empirischer Befund in Deutschland Dieser Anforderungsliste ist allerdings eher der Wunsch zu entnehmen geltende Standards m glichst weitgehend zu erfassen als dass sie eine praktisch verwertbare Richtlinie f r die Vertragsparteien darstellt zumal hier eine Hierarchie fehlt und auch Widerspr che zwischen den Anforderungen nicht ausgeschlossen sind Bemerkenswert ist schlie lich dass die Projektleitung nur in 4 Mustern ausdr cklich geregelt ist Bei HE 2 SN S Nr 6 1 und 6 5 wird sie gemeinsam ausge bt wobei der Vorsitz bei HE vom Softwarebesteller eingenommen wird Bei BA 11 Abs 1 und SN B Nr 1 2 wird sie dem Softwarehaus zugeordnet KO 8 7 Abs 1 MA 8 4 BA 8 7 Abs 1 und 2 27 SN S Nr 7 1 SN B Nr 8 1 und SO 8 8 Abs 1 enthalten eine Fixpre
168. echtliche Rahmenbedingungen in den USA nicht abgeschlossen Je nach den Besonderheiten des Einzelfalles kann die Entscheidung zu Gunsten oder gegen seine Anwendbarkeit ausfallen 4 Regeln zur Leistungsbestimmung Ein contract for sale umfasst sowohl einen gegenw rtigen Verkauf als auch Vertr ge ber zuk nftige Verk ufe both a present sale of goods and a contract to sell goods at a future time 2 106 1 U C C Dabei besteht der Verkauf aus dem bergang des Eigentums gegen Entrichtung des Kauf Preises A sale consists in the passing of title from the seller to the buyer for a price 2 106 1 U C C Die weitere Bestimmung der Leistung wird ausdr cklich den Vertragspartnern berlassen Goods or conduct including any part of a performance are conforming or conform to the contract when they are in accordance with the obligations under the contract 2 106 2 U C C Aus deutscher Sicht interessant ist die Regelung hinsichtlich vorvertraglicher Vereinbarungen evidence of any prior agreement or of a contemporaneous oral agreement Diese k nnen grunds tzlich nicht f r eine von dem Vertrag abweichende Bestimmung der Leistungspflicht herangezogen werden sog Parol or Extrinsic Evidence Rule Anderes gilt f r die Art und Weise der Vertragsdurchf hrung course of performance der bisher blichen Gestaltung der Vertragsbeziehungen durch die Vertragsparteien course of dealing
169. ecific performance where the contract as a whole was unconscionable when made Rs 2d 208 g Rs 2d 213 Als materielles Recht stellt es nicht etwa eine Auslegungsregel dar sondern definiert den Gegenstand der Auslegung Anmerkung a Die Restatements of contracts geben dabei Detailregelungen an die Hand was das Verhaltnis der vertraglichen und au ervertraglichen Umst nde anbelangt 214 218 Rs 2d 222 und 223 vorbildlich ist diesbez glich die Klarheit in der 203 die Priorit ten bei der Auslegung verdeutlicht 203 Standards of Preference in Interpretation In the interpretation of a promise or agreement or a term thereof the following standards of preference are generally applicable a an interpretation which gives a reasonable lawful and effective meaning to all the terms is preferred to an interpretation which leaves a part unreasonable unlawful or of no effect b express terms are given greater weight than course of performance course of dealing and usage of trade course of performance is given greater weight than course of dealing or usage oftrade and course of dealing is given greater weight than usage of trade c specific terms and exact terms are given greater weight than general language d separately negotiated or added terms are given greater weight than standardized terms or other terms not separately negotiated 221 Stahl Management Corp v Conceptions Unlimited 554 F Supp 890 1983
170. eferung der Software unter 9 Abnahme vorgesehen 9 1 Der Auftragnehmer liefert die Rohversion die vorl ufige Endversion und die Endversion der Software auf einem festen Datentr ger CD ROM Disketten oder vergleichbares mit vorhandenen Mitteln des Partners lesbares Speichermedium Zwischenversionen k nnen per DF Anm Datenfern bertragung bertragen werden Dokumentation und Quellcode sind in 12 Dokumentation und Quellcode geregelt 12 1 Der Auftragnehmer bergibt mit jeder Version insbesondere Rohversion vorl ufige Endversion und Endversion den Quellcode des Programmes an den Partner 12 2 Der Auftragnehmer liefert neben dem ablauff higen Programm und dem Quellcode eine Programmdokumentation Diese erl utert den Programmcode nach Ma gabe des allgemeinen technischen Standards Sie ist in ihrem Umfang so zu bemessen dass ein der Programmiersprache 177 Kapitel 6 Empirischer Befund in Deutschland kundiger Mitarbeiter prinzipiell den Aufbau und die Arbeitsweise der Software nachvollziehen und bearbeiten kann Die Programmdokumentation kann auch zum Bestandteil des Quellcodes gemacht werden Hier zeigt sich die Ausrichtung des Vertrages wie bereits durch die Einr umung des ausschlie lichen Nutzungsrechtes dokumentiert deutlich Der Softwarebesteller m chte in die Lage versetzt werden das eigens f r ihn erstellte Programm ohne fremde Hilfe v a der des Softwarehauses ver ndern und
171. ehmen Die teilweise vorhandenen Verweise auf technische Standards sind von zweifelhaftem praktischen Nutzen Die Fehlerbeseitigung folgt von einer Ausnahme abgesehen stets der Abnahme und wird als Gew hrleistungsfrage behandelt In den Praxisbeispielen wird sie als Bestandteil der Wartung betrachtet Die Frage nach der Projektleitung ist nicht in allen Mustern und dort wo sie vorhanden ist unterschiedlich geregelt Sie wird dem Softwarehaus aber auch dem Softwarebesteller oder einem parit tisch besetzten Gremium bertragen Sowohl die Muster als auch die Praxisbeispiele enthalten ohne Ausnahme Festpreisvereinbarungen 191 Kapitel 7 Vergleichende Darstellung 4 RECHTSVERGLEICHUNG Kapitel 7 Vergleichende Darstellung Methoden der Leistungsbestimmung Weder im deutschen noch im amerikanischen Recht ist die Softwareentwicklung durch Gesetze bzw statutes geregelt Im amerikanischen Recht ist der Versuch ein auch die Softwareentwicklung regelndes Uniform Law auf den Weg zu bringen nach anf nglichen Erfolgen gescheitert Im deutschen Recht gibt es zwar Grundmodelle wie den Werkvertrag die als Regelungsbasis in Betracht kommen Welches Modell sich jedoch in welchem Ausma eignet ist heftig umstritten und infolge der Schuldrechtsreform auch aus Sicht der Rechtsprechung fraglich Die Notwendigkeit Software in das hergebrachte Rechtssystem einzuordnen trifft in beiden Rechtsordnungen auf erhebliche Schwierigkeite
172. ehr hinnehmbaren Gesamtbild komplettiert Il Die L sung des Konfliktes zwischen Planung und Wirklichkeit Planung und Wirklichkeit fallen regelm ig auseinander Dass die Vorstellung von einem Ergebnis nicht mit dem tats chlichen Resultat bereinstimmt ist keine Besonderheit von Softwareentwicklungsvertr gen Es offenbart sich bei ihnen jedoch in besonders pr gnanter Form Ein einmal 581 Weyers AcP 182 1982 S 61 582 Weyers AcP 182 1982 S 77 83 Schneider IT Vertragsrecht in CR 2005 S 695 S 697f 584 Weyers weist hier etwa auf die Unangemessenheit des jederzeitigen K ndigungsrechtes und der fehlenden Regelung f r eine tempor re Leistungsst rung hin AcP 182 1982 S 67ff 224 Kapitel 8 Schlussfolgerungen errichtetes Bau Fundament z B stellt eine unmittelbar und bei gr eren Projekten eindrucksvoll wahrnehmbare Realit t dar Ebenso fundamentale Mengenger ste oder Datendefinitionen weisen diese sinnlich erfahrbare Eigenschaft nicht auf Ein Bauherr der sich mit einem nderungsvorschlag tr gt wird sich h ufig durch einmal geschaffene Fakten leiten lassen Er wird kaum auf den Gedanken verfallen ein etwa durch nderungen der Bauplanung erm glichtes drittes Geschoss aufzusetzen wenn der Architekt ihm erkl rt die Statik sei daf r nicht ausgelegt Ein Softwarebesteller der statt urspr nglich zwei nunmehr drei Produktgruppen in seinem Warenwirtschaftssystem verwalten will kann vom
173. ein musse IV Leistungsbestimmung durch das Pflichtenheft 1 Begriff und Bedeutung Unabh ngig von der Einordnung des Vertragstyps spielt bei der Leistungsbestimmung h ufig das sog Pflichtenheft eine Rolle Es stellt die Definition der zu erbringenden Leistung dar wobei es nicht das Wie 43 43 43 43 gt Redeker IT Recht a a O S 490 Redeker IT Recht a a O S 489 Redeker IT Recht a a O S 489 Es handle sich um einen Typenverschmelzungsvertrag der das Risiko weder ausschlie lich dem Besteller wie beim Dienstvertrag noch ausschlie lich dem Unternehmer wie beim Werkvertrag zuordne Thewalt a a O S 120ff bei klar definierten Anforderungen fehle es aber an dem erheblichen Risikoelement der Auftragnehmer g be mit der Akzeptanz eines Projektes mit klarer Definition der Aufgabenstellung konkludent zu erkennen er wolle das Erfolgsrisiko bernehmen S 121f Vgl dazu oben Kapitel 1 S 14ff 39 Heppner Softwareerstellungsvertr ge S 192ff 0 Heppner a a O S 382 441 5 0 Kapitel 2 S 20ff NO 43 117 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland sondern das Was enthalt also das Ziel des Projektes beschreibt nicht jedoch den Weg dorthin Aus technisch organisatorischer Sicht existieren umfangreiche Definitionen die allerdings aus rechtlicher Perspektive bisher wenig Beachtung finden Auch aus dem Blickfeld des
174. eises verlangen wenn und soweit die von der Unterbrechung betroffenen Arbeitnehmer nicht anderweitig eingesetzt werden konnten und dem Auftraggeber dies schriftlich mitgeteilt wurde Das formalisierte Schema nderungsverlangen Pr fung oder ausf hrliche verg tungspflichtige Pr fung durch das Softwarehaus und ggf Unterbrechung der Arbeiten Entscheidung des Softwarebestellers ist auch hier vorgesehen Die gegenseitigen Handlungsanforderungen und die Verg tungspflicht sind weitgehend ausgeglichen geregelt und erkennbar von den Gedanken getragen berraschungen f r beide Vertragspartner zu vermeiden und die Behinderung des Projektfortganges zu minimieren Dass dieser gew nschte Projektfortgang aber ohne Einvernehmen nicht zustande kommen kann wird durch Abs 2 S 1 anschaulich wenn hier von unverz glicher Vereinbarung der Anpassung die Rede ist Der Fortgang des Projektes kann bei nderungen nicht einseitig erzwungen werden er muss von beiden Vertragsparteien gewollt sein Vil Zusammenhang zwischen Leistungsbestimmung und Einstandspflicht Hinsichtlich des Ma stabes f r Leistungserbringung findet sich bei KO 8 4 Abs 1 GL Nr 4 4 und Nr 17 Abs 2 SN S Nr 8 1 1 SO 8 11 Abs 1 und HE 8 13 eine Anlehnung an die gesetzliche Regelung des 434 BGB 51 Die gesetzliche Regelung wird im Verh ltnis zur Leistungsbeschreibung im Erstellungsschein ausdr cklich f r subsidi r erkl rt 167 Kapitel 6 Empirischer
175. eistellungen und Abgrenzung die Verantwortlichkeiten so aufzeigt 1 Der AG stellt folgende Leistungen bei a die Hardware Anlage Hardware b das Netzwerk Anlage Netzwerk c die System und Datenbanksoftware Anlage System und Datenbanksoftware Der AG sorgt f r Betriebsbereitschaft Pflege und Wartung dieser Gegenst nde 2 Au erdem stellt der AG sein besonderes versicherungstechnisches und versicherungsrechtliches Fachwissen zur Verf gung und wirkt nach 17 mit 3 Die brigen Leistungen die notwendig sind damit die Hardware Abs 1a mit der neuen Software vertragsgem arbeitet werden vom AN erbracht Auch hier ist ausschlie lich der Softwarebesteller f r seine EDV verantwortlich mit der Einschr nkung dass die ordnungsgem e Interaktion der neuen Software mit der vorhandenen EDV Sache des Softwarehauses wird Abs 3 Die von BA vorgeschlagene weitere Grundregel in dessen Organisationsteil 8 17 Mitwirkung des AG erg nzt diese Anfangsbedingungen 1 Der AG wei dass das Projekt nur realisiert werden kann wenn er umfassend fachkundig und rechtzeitig mitwirkt Er wird den AN in dem Projekt unterst tzen womit nicht eine bernahme von Verpflichtungen des AN gemeint ist Er stellt zugunsten des Projektes seine Mitarbeiter in angemessenem Umfang von anderen T tigkeiten frei Er erbringt die Beistellungen 5 rechtzeitig gibt Informationen und gew hrt dem AN im 154 Kapitel 6
176. eit produziert angepasst erweitert und mit Hilfe des Internet auch vertrieben gewartet und durch andere Dienstleistungen wie z B Sicherung Backup begleitet F r die Bew ltigung der damit verbundenen Rechtsfragen w re daher eine Basis die grundlegende Fragen einer Antwort zumindest n her bringt von allgemeinem Interesse Die Vielzahl der Projekte die teilweise ohne pr zise Leistungsbeschreibung oder ohne geeignete vertragliche Grundlage zu Recht und letztendlich vor Gericht kommen m ssen erfordert die T tigkeit des Gesetzgebers Die Rechtsprechung hat sich in jahrzehntelanger Praxis auf eine Zuordnung der Softwareentwicklungsvertr ge zum Werkvertragsrecht versteift Von ihr kann eine nachhaltige L sung kaum erwartet werden Auf Ebene der Softwareverb nde unter federf hrender Beteiligung der ffentlichen Auftraggeber sind zwar allgemeine Bedingungen auch f r den Bereich der Planung und Erstellung von Software geschaffen worden die BVB bzw EVB IT doch ist der bereits Anfang der 19 70er Jahre begonnene Entwicklungsproze noch nicht zum Abschluss gekommen und es ist diesen allgemeinen Regeln bisher nicht gelungen einen der VOB auch nur ann hernd vergleichbaren Stellenwert zu erlangen Oben Kapitel 8 A II wurden drei M glichkeiten f r eine Reform durch den Gesetzgeber angedeutet 1 Die ausdr ckliche Zuweisung von 5 Zusammenfassende Darstellungen finden sich bei Redeker CR 2005 S 695 und Schneider CR 20
177. eiten 558 Wie etwa Software diene der Konditionierung der Hardware Braun in BB 1992 S 154 157 211 Kapitel 8 Schlussfolgerungen Die Genesis des Begriffes Software beruht auf dem Gegensatzpaar Hardware und Software Hardware ist dabei das was man anfassen kann Software das was sich der sinnlichen Wahrnehmung entzieht also eben keine Sache Zweifellos erf llen die Tr ger der Software die Sacheigenschaft Dies gilt allerdings auch f r Tr ger von Film Musik und Duft weshalb Film Musik und Duft selbst keineswegs als Sachen anzusehen sind Software entfernt sich bei diesem Vergleich noch weiter vom Sachbegriff da Film Musik und Duft direkt zur sinnlichen Wahrnehmung durch Auge Ohr und Nase bestimmt und geeignet ist Software selbst ist mit den Sinnen dagegen nicht wahrnehmbar und auch nicht daf r gedacht Was sinnlich wahrnehmbar sein kann sind allenfalls die Ergebnisse der Software Im deutschen wie im amerikanischen Recht ist die Argumentation anzutreffen Medium und Programm seien unentwirrbar verbunden und weil dies so sei m sse die Sacheigenschaft bejaht werden Wie die Gegner der Sacheigenschaft dargelegt haben ist diese Behauptung angesichts neuer Technologien und darauf basierender Konzepte wie Netzwerke lokale und globale wie das Internet und z B Application Service Providing unzutreffend Doch selbst wenn eine Untrennbarkeit angenommen wird so ist die daraus gezogene Schlussfolgerung ni
178. eiten aus die bei Umsetzung des nderungsverlangens nicht mehr verwendbar w ren kann der Kunde verlangen dass der Anbieter diese bis zur Anpassung der Leistungsbeschreibung bzw des Pflichtenheftes unterbricht gleiches gilt f r neu anstehende Arbeiten Sobald der Anbieter erkennt das derzeitige oder anstehende Arbeiten bei der Umsetzung des nderungsverlangens nicht mehr verwendbar w ren hat er den Kunden auf diese M glichkeit unverz glich hinzuweisen 12 5 Verbindlichkeit 162 Kapitel 6 Empirischer Befund in Deutschland 1 Die Anderung ist verbindlich sofern der Anbieter nicht innerhalb von 30 Arbeitstagen ab Zugang das Anderungsverlangen als unzumutbar ablehnt eine Pr fung nach VB 12 2 oder Anpassungen des Erstellungsscheines nach VB 12 3 fordert 2 Falls ein Anpassungsverlangen nach VB 12 3 vorliegt ist die verlangte nderung nur dann verbindlich wenn ber das Anpassungsverlangen fristgerecht eine Einigung erzielt wurde VB 12 3 3 3 Wird eine nderung verbindlich so ist sie in die Leistungsbeschreibung einzuarbeiten die weiteren Anpassungen gem VB 12 3 sind in den Vertrag umzusetzen Ein Zeitplan ES 3 wird des weiteren um den Zeitverlust angepasst der durch die Durchf hrung des nderungsverfahrens verursacht wurde Soweit die Ressourcen des Anbieters nicht anderweitig eingesetzt werden konnten ist dieser zur Geltendmachung einer Zusatzverg tung nach dem Erstellungsschein berechtig ES 5 5 12
179. eitgehend Rechnung getragen Die deutschen Muster basieren auf unterschiedlichen Stadien der Softwareentwicklung wobei auch hier ein mehrstufiges Verfahren zur Leistungsbestimmung in der Mehrzahl der Muster vorgesehen ist Es wird teilweise davon ausgegangen es l ge ein gepr ftes Pflichtenheft vor welches nach Ma gabe des Vertrages umzusetzen ist Auch zwei der Praxisbeispiele gehen von einer mehrstufigen Detaillierung der Anforderungen aus die sich in einem Beispiel w hrend des Projektverlaufes fortsetzt In zwei Beispielen werden die Anforderungen bei Vertragsabschluss als vollst ndig betrachtet Die Verantwortlichkeit f r das Erstellen eines Pflichtenhefts als zentrales Spezifikationsdokument ist unterschiedlich geregelt und teilweise als Option vorgesehen Technische Details werden weitgehend in die Anlagen verwiesen Auch die deutschen Muster und Praxisbeispiele bem hen sich darum eine m glichst detaillierte Leistungsbestimmung durch ein mehrstufiges Verfahren f r deren Erarbeitung sicherzustellen Wie bei ihren amerikanischen Pendants ist die Verantwortung dabei unterschiedlich geregelt Die Vorgabe der Zielpr zision wird damit weitgehend ausreichend ber cksichtigt Dies geschieht auf vergleichbare Weise Die amerikanischen Muster und ihre deutschen Kollegen bem hen sich mit einer Ausnahme darum den juristischen Haupt Vertrag von der in Anlagen zu regelnden Technik zu trennen Die Praxisbeispiele au
180. eles California DMX Incorporation OD geschlossen l Vertragsart OD besteht aus zwei Teilen einem Purchase Agreement und einem Software License Agreement die durch verschiedenen Anh nge erg nzt werden wobei hier ein sog Rider von Bedeutung ist Die Bezeichnung als Purchase kann dabei insofern als irref hrend angesehen werden als bereits unter Nr 2 davon die Rede ist das Softwarehaus habe Software Services und Support zu liefern Auch enth lt der Lizenzvertrag keine Uber die in den anderen Vertr gen ebenfalls enthaltenen diesbez glichen Regelungen wesentlich hinausgehenden Bestimmungen FP ist als Software Development and Processing Services Agreement bezeichnet und mit zahlreichen Anh ngen versehen w hrend AE den Titel Software Development Agreement tr gt und sich aus drei Teilen der unbenannten Section der mit General Provisions of a Software Development Contract bezeichneten Section 115 sowie sog Authorization Letters zusammensetzt Sowohl bei OD als auch bei FP findet sich zudem die Bestimmung dass berschriften keine Bedeutung beizumessen sei Headings The title or headings of various paragraphs Sections and Articles hereof are intended solely for convenience of reference and shall not be construed for any purpose whatsoever to modify or explain or place any construction upon any of the provisions of this Agreement Sowohl Aufbau als auch Bezeichnung der Vertrage eignen sich nicht als Grundlage f
181. eliver and install the Subject Programs at the data processing operations center of Customer and shall deliver to Customer at that address all documentation and other materials required to be provided in accordance with the milestone RB V und RB U unterscheiden sich dahingehend dass RB V im wesentlichen eine Ubertragung der Lizenz zum Gegenstand hat 2 Development and License Subject to all of the terms and conditions hereof Licensor hereby agrees to develop the Management System for Licensee and does hereby agree to grant to Licensee a perpetual non exclusive and non transferable license the License to use the Management System terminable as specified herein which license the Licensee hereby accepts wahrend RB U neben der Lizenzeinraumung die Lieferung eines Systems verlangt welches den Anforderungen des Softwarebestellers entspricht Es versteht sich fast von selbst dass hierzu auch eine ausf hrliche Dokumentation geh rt 4 10 Documentation The documentation to be provided on or before Preliminary Acceptance of each Application of the Software System shall include the Detailed Design Specifications system flow charts program flow charts file layouts report layouts screen layouts program source code user instruction manuals and all other documentation as specified in the RFP Anm RFP steht f r Request for Proposal and the Licensor Proposal Unter dem Gesichtspunkt der Lieferung enthalten
182. emerkenswert ist seine Feststellung zu diesem Schema wonach das Produkt der Systemplanung also das Ergebnis der Entwicklung zu Beginn 11 Kapitel 2 Softwareentwicklung in der Praxis des Planungsprozesses weitgehend unbekannt ist Die Beteiligten haben bei dieser Sichtweise also allenfalls ein abstraktes Ziel eine bestimmte Funktionalit t und eine grobe Route die theoretische Abfolge der Softwareentwicklung vor Augen Diese Problematik von Planbarkeit in der Softwareentwicklung wird auch von zahlreichen anderen Autoren betont Anders als etwa bei der Erstellung eines Bauwerkes gibt es kein physisches also sinnlich erfahrbares Modell an dem sich Auftraggeber und Softwarehaus orientieren k nnen Etwas anders und provokativer ausgedr ckt Die Beteiligten begeben sich auf eine Reise bei der sie weder Ziel noch Route kennen In dem Bem hen diese Aufgabe trotzdem zu bew ltigen haben sich zur Beschreibung des Ablaufes der Softwareentwicklung in der Literatur zahlreiche Modelle herausgebildet Sinn dieser Softwareentwicklungsmodelle ist die Reduzierung von Komplexit t Eine un berschaubare Aufgabenstellung wird in einzelne Abschnitte und oder Teilprojekte gegliedert in denen u a die Grundlagen f r die Entscheidungen grunds tzlicher Bedeutung wie beispielsweise die Erstellung eines Pflichtenheftes geschaffen werden Il Modelle f r die Erstellung von Software Eine Vielzahl von Modellen hat den Versuch untern
183. empfiehlt sie unterschiedlich zu definieren S 289f und S 302 221 Kapitel 9 Zusammenfassende W rdigung Kapitel 9 Zusammenfassende W rdigung A Gesamtbefund Die vorangegangene Untersuchung kann zu drei zentralen Themenkreisen verdichtet werden Der erste betrifft das Verhaltnis von Technik und Recht dazu l der zweite die Beziehung zwischen Planung und Wirklichkeit dazu Il der dritte die Eignung von interessenorientierter anstelle von projektorientierter Vertragsgestaltung zur Optimierung des Projektverlaufs dazu III I Technik und Recht Social Engineering und Software Engineering Die im Rahmen von Softwareentwicklungsvertr gen auftauchenden Fragestellungen werden von dem Vertragsgegenstand und nicht von der Rechtsordnung innerhalb derer sie beantwortet werden gepr gt Die diagnostizierten Br che verlaufen also nicht zwischen dem deutschen und dem amerikanischen Recht sondern zwischen Technik und Recht Die praesumtio similitudinis also die Vermutung der hnlichkeit der L sungsans tze bestimmter Sachverhalte bei der Rechtsvergleichung findet sich an dieser Stelle best tigt Dies gilt sowohl f r die Bereiche in denen eine rechtliche Erfassung der Realit t im gro en und ganzen gelingt als auch dort wo sie weitgehend versagt Das social engineering gelingt grunds tzlich bei der Konzeption von Verfahren zur Bestimmung eines pr zisen Zieles Die systematische Vorgehensweise der Juristen l
184. en bedeutsamen Wachstumsfaktor in der Branche der Infomationstechnologie und vor allem auch der Softwareindustrie darstellt Ganze Branchenzweige wie z B das Design von Internetpr senzen Webdesign der Einkauf ber das Internet Online Shopping oder das Bereithalten von Infrastruktur f r Internetpr senzen Webhosting verdanken ihre Existenz der zunehmenden Marktdurchdringung mit dieser in weitem Umfang auf Software angewiesenen Telekommunikationstechnologie In Unternehmen ergab sich in Deutschland eine Nutzung von Computern in 2003 zu 80 und in 2004 zu 84 Der Anteil der Besch ftigten an Computern stieg von 46 in 2003 auf 55 in 2004 3 Statistisches Jahrbuch 2005 f r die Bundesrepublik Deutschland SJB D 2005 Wiesbaden 2005 S 114 Die Angaben stellen Prozentzahlen v H dar Laut Statistisches Jahrbuch 2005 f r das Ausland SJB A 2005 Wiesbaden 2005 Computer die direkt mit dem World Wide Web verbunden sind die diesbez glichen Zahlen sollten als N herungswert betrachtet werden S 301 Fn 1 5 SJB A 2005 S 330 SJB A 2005 S 300f 7 SJB D 2005 S 119 Kapitel 1 Allgemeiner Teil Auch aus der Anzahl der in der Branche Beschaftigten und der Hohe der erzielten Umsatze kann auf die Bedeutung des Wirtschaftszweiges geschlossen werden In 2002 wurden im Wirtschaftsbereich der Datenverarbeitung und Datenbanken in Deutschland 42 025 Unternehmen erfasst die mit 377 908 Beschaftigten einen U
185. enden besonderen Regeln zu suchen Soweit in der Literatur eine gesellschaftsrechtliche Konstruktion in Betracht gezogen wird wird dies mit einem gemeinsamen Erfolgsrisiko begr ndet Die Basis f r eine solche Annahme bildet der gemeinsame Zweck Soweit eine gesellschaftsrechtliche L sung berhaupt in Betracht gezogen wird u ern sich hier bereits Zweifel In ausf hrlicheren Untersuchungen wird die Anwendbarkeit der 88 705ff deutlich abgelehnt Die Parteien verfolgten nicht gemeinsame sondern gegens tzliche Interessen zudem mache es wertungsm ig keinen Sinn Vorschriften der 705ff BGB auf Softwareentwicklungsvertr ge anzuwenden Ein gemeinsames 6 Hilty MMR 2003 S 3 7 Hilty MMR 2003 S 3 beispielhaft f r allgemeine Regeln werden die 275ff 311f 313ff und 320 bis 326 genannt 428 S o Fn 352 429 Karger ITRB 2004 S 208 liegt es bei beiden Parteien spr che einiges f r die Anwendung der 705ff BGB 0 Sobola Dobmeier Gl ckler a a O S 230 1 Karger etwa meint die Anwendung von Gesellschaftsrecht werde aus diesem Grund Erfordernis von gemeinsamem Zweck und hierauf gerichteten F rsorgepflichten ein Ausnahmefall sein ITRB 2004 S 208 482 Slongo a a O S 142 433 723 Abs 1 BGB beschr nke die sonst gem 649 BGB jederzeitige K ndigungsm glichkeit des Bestellers durch das Erfordernis eines wichtigen Grundes Thewalt a a O S 225f das Individualri
186. ender gewissenhaft gepr ft Reklamationen oder nderungsw nsche sind zu diesem Zeitpunkt anzumelden soweit sie bereits erkennbar sind 3 Im Gegensatz zu BA formuliert MA eine Regel und nennt lediglich nsbesondere Beispiele hierzu Bemerkenswert ist auch die ausdr ckliche Erw hnung der Pr fungspflicht des Softwarebestellers in Bezug auf Entwurfe Programmtestversionen oder ahnlichem Es wird dadurch deutlich dass er sich selbst gewissenhaft mit den Arbeitsergebnissen des Softwarehauses besch ftigen muss und bei entsprechendem Vers umnis mit Nachteilen die allerdings nicht n her benannt sind zu rechnen hat Selbst das bestellerfreundliche Muster SN B w hlt f r die Pflichtenbenennung eine offene Formulierung die jedoch mit einer Abrufverpflichtung kombiniert wird 155 Kapitel 6 Empirischer Befund in Deutschland 3 2 Mitwirkung Der AG ist zur Mitwirkung im Rahmen des erforderlichen Umfangs insbesondere zu den nachgenannten Mitwirkungsleistungen verpflichtet 3 2 1 Bereitstellung von Unterlagen Testf llen Testdaten Anm Diese und die folgenden P nktchen finden sich im Original der Text von 3 2 und 3 3 ist also vollst ndig wiedergegeben 3 2 2 Bereitstellung von R umen Maschinen Testsysteme 3 2 3 Bereitstellung von Personal 3 3 Abruf der Mitwirkung Der rechtzeitige Abruf der Mitwirkungsleistungen des AG ist Sache des AN Soweit bereits feste Termine f r Mitwirkungsleistungen
187. enth lt keinerlei Lieferverpflichtung und SN B statuiert hierzu kontr r das umfassende Recht des Softwarebestellers die Herausgabe s mtlicher Arbeitsergebnisse und Unterlagen zu verlangen Nr 4 3 6 Hinsichtlich der zu liefernden Dokumente finden sich sowohl terminologisch als auch inhaltlich betr chtliche Unterschiede S verlangt kurz die Aush ndigung der Dokumentation in zweifacher Ausf hrung 8 7 5 KO sieht in 2 Nr 2 3 die Lieferung einer Benutzerdokumentation sowie optional einer Entwicklerdokumentation MA in 1 die von Benutzungsanleitung Herstellerdokumentation sowie weiterer schriftlicher Materialien zur Produktbeschreibung vor Nach BA 8 6 3 ist das Maschinenprogramm mit Handbuch sowie das Quellprogramm mit Dokumentation zu bergeben GL sieht unter 4 3 als Pflicht das Erstellen einer Benutzerdokumentation vor Das zus tzliche Erstellen einer systemtechnischem Dokumentation ist optional also ggf gesondert zu vereinbaren In den BVB findet sich unter 16 Nr 1 die Pflicht eine ausf hrliche Dokumentation Programmentwicklungsdokumentation Programm dokumentation sowie sonstige programmbezogene schriftliche Unterlagen in deutscher Sprache zur Verf gung zu stellen wobei auf eine Vereinbarung im Erstellungsschein verwiesen wird 512 Bei BA wird von der umfassenden Anpassung und Erg nzung einer Standardsoftware ausgegangen weshalb diese
188. entwicklungsvertrag 88 630a 630d 630a Leistungsbestimmung 1 Der Besteller kann die Leistung vom Unternehmer nach Ma gabe einer Leistungsbeschreibung verlangen soweit nicht etwas Abweichendes vereinbart ist 2 Soweit die Leistungspflicht unbestimmbar ist kann der Besteller vom Unternehmer nur die bestimmbare Leistung verlangen Der Unternehmer kann vom Besteller nur die Verg tung f r die bestimmbare Leistung verlangen 8 630b nderung der Leistungsbestimmung Der Unternehmer kann die Erbringung seiner Leistung der Besteller die Zahlung der Verg tung von einer nderung der Leistungsbestimmung abh ngig machen soweit ein Festhalten an der vereinbarten Leistung unter Ber cksichtigung aller Umst nde des Einzelfalles nicht zumutbar ist 234 Kapitel 8 Schlussfolgerungen 630c Mitwirkungspflichten Der Unternehmer kann vom Besteller die zum Leistungserfolg erforderlichen Mitwirkungshandlungen verlangen Der Unternehmer kann sich auf die Mitwirkungspflicht des Bestellers nicht berufen soweit der Besteller sie nicht ohne Beratung oder sonstige Handlung des Unternehmers erbringen kann 630d Leistungsma stab Der Unternehmer kann die Verg tung verlangen wenn er seine Leistung gem Leistungsbeschreibung im wesentlichen erbracht hat F r Teilleistungen gilt dies soweit eine Verg tung f r Teilleistungen vereinbart ist 235 Literaturverzeichnis Literaturverzeichnis A Anwaltskommentar BGB Band 2 S
189. er den Umst nden nichts anderes ergibt Ausreichend ist dabei d h f r die F lligkeit der Gegenleistung eine Erf llung im wesentlichen substantial performance 194 National Conference of Commissioners on Uniform State Laws 195 Flechtner a a O S 225 S 227 1 Calamari Perillo a a O 11 17 und Fn 3 S 412 49 Kapitel 3 Rechtliche Rahmenbedingungen in den USA Der Ma stab f r die Erf llung ergibt sich zun chst aus Rs 2d 235 1 wonach nur die volle Erf llung zu einem Erl schen der Leistungspflicht f hrt Ist die Erf llung f llig so stellt jedes Abweichen einen Vertragsbruch dar aus dem ein Recht auf Schadensersatz erw chst Dies gilt selbst dann wenn sich ein Schaden nicht beweisen l sst oder berhaupt kein Schaden entstanden ist wobei dann allerdings allenfalls eine nominale Summe zugesprochen werden kann Auf den Grad des Verschuldens kommt es nicht an wenngleich die Gerichte unerhebliche Abweichungen trifling departures ignorieren k nnen Geringf gige M ngel trivial defects sind daher in der Regel unbeachtlich Dies erweckt zun chst den Eindruck einer strengen Einstandspflicht f r die in einem Vertrag vereinbarten Konditionen Wenn beispielsweise bei der Errichtung eines Hauses f r 50 000 die K cheneinrichtung versehentlich abweichend vom Vertrag ausgef hrt wird was sich f r 100 ndern lie e ansonsten aber eine vertragsgem e Ausf hrung vorl
190. er entwickelt f r das vom Kunden vorgegebene Problem eine zweckm ige und wirtschaftliche EDV L sung in der Form geeigneter Software ber die Stufen Problemanalyse Systemplanung Programmierung Dokumentation und Einweisung Das Softwarehaus soll hier dazu verpflichtet werden ein Problem des Softwarebestellers zu l sen und zwar in einer zweckm igen und wirtschaftlichen Weise mit geeigneten Mitteln Umfassender und allgemeiner k nnte ein Pflichtenprogramm kaum definiert werden ll Bestandteile der Lieferung Die Muster KO MA BA GL SN S und S sehen die Lieferung der Software vor wobei die Bezeichnung divergiert KO unter 2 1 Programm in kodierter und eingabebereiter Form MA unter 1 Computerprogramm 136 Kapitel 6 Empirischer Befund in Deutschland BA unter 1 1 Standardsoftware GL unter 4 1 2 Lizenzprodukt in der vereinbarten Code Form gem VB 9 Anm VB Vertragsbedingungen hier im Unterschied zu ES Erstellungs schein verwendet sowie unter 9 1 das Lizenzprodukt auf installationsfertigen Datentr gern SN S unter 1 2 Software auf einem blichen Datentr ger SO unter 7 5 Lieferkopie des Lizenzproduktes auf Datentr gern Die BVB sprechen unter 9 Nr 1 allgemeiner von der Pflicht des Auftraggebers die vertraglichen Leistungen in der vereinbarten Form zu dem im Erstellungsschein festgelegten Zeitpunkt zu bergeben HE
191. er vornehmen so ist damit h ufig nur eine konkrete Darstellung der programmtechnisch zu l senden Aufgabe gemeint Dies ist aus dem Blickwinkel der Informationstechnologie zwar mehr als nur eine Idee aber weitaus weniger als eine pr zise Grundlage f r die Implementation Ist eine solche Grundlage von Seiten des Softwarebestellers geschaffen so wechselt nach der Rechtsprechung die Verantwortung f r den weiteren Projektverlauf grunds tzlich zum Softwarehaus 195 Kapitel 7 Vergleichende Darstellung Weder im amerikanischen noch im deutschen Recht liefert das in den Gesetzen enthaltene Recht nach dem Vorstehenden Aufschlusse ber die Zielpr zision Ausgehend von allgemeinen Rechtsgrunds tzen wird die Verantwortlichkeit f r die Zielpr zision in der Rechtsprechung keinem Vertragspartner eindeutig zugewiesen wobei sich ber einen Zeitraum von etwa 20 Jahren gesehen eine Tendenz dazu zeigt den Softwarebesteller mehr in die Pflicht zu nehmen Die gesetzlichen Rahmenbedingungen enthalten f r eine detaillierte Leistungsbestimmung kaum Vorgaben oder Einschr nkungen Die Vertragsgestaltung ist daher weitgehend frei m glich Dies kommt in den Vertragsmustern und beispielen auch zum Ausdruck Der berwiegende Teil der amerikanischen Muster und zwei der Praxisbeispiele gehen von einem Vertragsabschluss in einem fr hen Projektstadium aus d h von einem Zeitpunkt zu dem der Detaillierungsgrad der Anforderungen noch vergleichswe
192. ern und Lenkungsausschuss bestehend aus den Gesamtprojektleitern nebst Stellvertretern von AG und AN sowie einem weiteren Mitglied jedes Vertragspartners das direkt der Gesch ftsleitung unterstellt ist 147 Kapitel 6 Empirischer Befund in Deutschland Der Auftraggeber kann mit schriftlicher Begr ndung den unverz glichen Austausch eines Arbeitnehmers verlangen wenn dieser wiederholt gegen vertragliche Pflichten verstoBen hat Die durch den Wechsel entstehenden Kosten tr gt der Auftragnehmer Wahrend in GL bereits aus der Verlagerung der Bestimmungen in den Erstellungsschein und dem geringen Umfang ein Hinweis auf die Einschatzung der Bedeutung zu entnehmen ist ergibt sich dies in den BVB aus dem zur Wahl Stellen der entsprechenden Regelung Anders n mlich bedeutend h her sch tzt offenbar BA die Bedeutung der Personalfrage ein wenn er unter 15 Mitarbeiter formuliert 1 Vorbehaltlich 16 Anm 16 regelt Leistungserbringung durch Subunternehmer erbringt der AN die Leistungen mit eigenen angestellten Mitarbeitern Sie m ssen die notwendigen Kenntnisse und Erfahrungen besitzen der AG kann insofern Ausk nfte verlangen Die fachlichen Qualifikationen der Mitarbeiter des AN sind im Mitarbeiterplan Anlage Mitarbeiterplan festgelegt 2 Die Projektleiter des AN 11 Abs 2 m ssen zumindest seit einem Jahr beim AN in einer vergleichbaren Position arbeiten 3 Die Vertragspartner werden einen Austausch von P
193. ert ist Dies kann schematisch in Form einer Grafik dargestellt werden wobei das Ma in dem ein Softwareprojekt bedarfsgerechte L sungen hervorbringt davon abh ngt ob es gelingt Zielpr zision und Wandelbarkeit in eine optimale Balance zu bringen 128 Dies schlie t nicht aus dass in manchen Situationen eine Fehlertoleranz nicht akzeptabel ist Wer w rde sich sonst wohl der Softwaresteuerung eines Aufzuges oder einer Notversorgung z B Sauerstoff und Medikamentenzufuhr anvertrauen 2343 Kapitel 2 Softwareentwicklung in der Praxis Flexibilitat Bedarfsgerechtigkeit Zielprazision Wird die Zielprazision bei geringer Flexibilitat maximiert Linie subopt 2 so fuhrt dies zu einem vergleichsweise geringen Ausschlag auf der Achse der Bedarfsgerechtigkeit Ebenso verh lt es sich wenn die Flexibilit t gesteigert wird die Zieldefinition aber auf einem geringen Niveau verbleibt Linie subopt 1 Erst wenn Flexibilit t und Zielpr zision in gleichem Umfang d h ausbalanciert gesteigert werden wird die Aussicht auf eine bedarfsgerechte L sung optimal unterstitzt Schlie lich kann als weiteres Ergebnis der Untersuchung festgestellt werden dass der Projekterfolg von einer angemessenen Einbindung des Softwarebestellers in die Projektarbeit ma geblich beeinflusst wird Dies gilt vor allem hinsichtlich der Formulierung und Pr zisierung der Anforderungen 122 Hier geht es lediglich um das Veransch
194. erung einer effektiven Nutzbarkeit verstanden werden Die im Abs 3 genannten Punkte stellen im Anschluss daran Detailkriterien f r eine dementsprechende Umsetzung auf Wie sich aus der Regeln des Abs 3 Nr 7 ergibt werden viele nderungen erwartet weshalb ein einfacher Zugriff auf zu ndernde Softwareteile gew hrleistet werden soll MiO orientiert sich an dem 179 Kapitel 6 Empirischer Befund in Deutschland Grundgedanken die Schwierigkeit bei der Bestimmbarkeit des Was durch ein Regeln des Wie zu kompensieren MiN regelt den Leistungsma stab in Nr 6 Zusicherungen 6 1 Der AN erkl rt sich bereit im Falle von auftretenden Problemstellungen die das Gesamtsystem Hard und Software betreffen auf Anfrage durch den AG ber das normale Ma hinaus im Rahmen der vorhandenen Kapazit ten gegen Verg tung bei der L sung der Problemstellung zu helfen und zu unterst tzen 6 2 Der AN sichert zu dass die gesamte Software 2000 und EURO f hig ist 6 3 Der AN sichert zu dass die vom System erzeugten Daten korrekt sind soweit der AG die Stammdaten ordnungsgem angelegt hat und keine Eingriffe in die vom AN gelieferten Systemkomponenten vorgenommen wurden Der Nachweis f r fehlerhafte Berechnungen muss vom AG gef hrt werden F r vom AG vorgenommene Eingriffe bernimmt der AN keine Haftung 6 6 Die Softwarepflege erfolgt in der Form dass Updates auf dem zentralen Applikationsserver installiert werde
195. erungen Change Managemernt 4 4 nn gt 74 VII Zusammenhang zwischen Leistungsbestimmung und Einstandspllicht esse 77 B Beispiele aus der Praxis nase won 79 k Mertragsaft an ae 80 ll Bestandteile der Lieferung nn 83 Spezifikationen sense ee 84 IV Besondere Pflichten des Softwarehauses 444400 87 V Besondere Pflichten des Softwarebestellers 91 VI Ver nderungen Change Managemernt 44 en gt 92 VII Zusammenhang zwischen Leistungsbestimmung und Einstandspilich ne ar ER 93 C Zusammenfassung und Ergebnis 244444444444Hnnnnnnnnnnnnnnnn nenn 96 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland 99 A Einordnung und Bedeutung der Rechtsquellen 99 I Rechtsprechung und Gesetz 24444444nnnnnnnnennnnnnnnnnn nenn 99 Il Das Prinzip Privatautonomie 444444444444004H RR nennen een 100 III Auslegungsgrunds tze 2444444snnnnnnnnnnnnnnnnnn nennen 101 B Anwendbares ReCHIAt ccccccceeceeeccceeceeeeeneeeeaeeeseeeseeeeeseeeeeeenees 104 Dissertation Softwareentwicklungsvertrage Inhaltsverzeichnis Einordnung des Vertragstypus usneeeeeesssssnsnnnnnnnnnnnnnnnn nennen 104 12 N olwendigkeil 2 2 22 104 2 Typenauswahl und Einordnungskriterien 105 b
196. es AN Urheberrechte entstanden sind verbleiben dieselben bei dem AN 7 2 Der AG stellt sicher dass die Anwendungsumgebung den bei Vertragsabschluss vereinbarten und im Pflichtenheft oder Abweichungs bericht definierten Vorgaben entspricht und gem den bereinstimmend fortgeschriebenen Anforderungen ausgelegt ist b 7 3 siehe sogleich unten Die Verpflichtung zur Mitwirkung ist hier erheblich deutlicher akzentuiert als bei MiO Der Generalklausel des Nr 7 1 S 1 folgen nicht abschlie end eine Mehrzahl von einzelnen Pflichten Hier wird das Bereitstellen von Ressourcen 7 1 erster und dritter Spiegelstrich und 7 2 sowie die rechtzeitige und uneingeschr nkte Informationslieferung 7 1 dritter Spiegelstrich verlangt Interessant ist die Zuweisung der Verantwortlichkeit f r die Koordination und berwachung des Change Managements zu dem Projektleiter des Softwarebestellers dazu sogleich 184 Kapitel 6 Empirischer Befund in Deutschland VI Ver nderungen Change Management Die aus einem Teil der Muster ersichtliche Regelungsdichte bezuglich des Change Managements findet sich in den Praxisbeispielen nur ansatzweise wieder Die Formulierungen bei MiN und SUS sind sich sehr hnlich Bei SUS hei t es unter 7 3 10 Zusatzleistungen und Modifikationen Verlangt der Partner eine nicht im Pflichtenheft enthaltene Leistung so wird der Auftragnehmer die Anfrage kurzfristig beantworten Macht ein nderungsver
197. es Gesetzbuch Handkommentar 11 Aufl K ln 2004 zitiert Erman Bearbeiter Software nach Ma Haar 1992 Esser Josef Weyers Hans Leo Esser Josef Schmidt Eike Schuldrecht Band Il Besonderer Teil 8 Aufl Heidelberg 1993 Schuldrecht Band Allgemeiner Teil Teilband 1 8 Aufl Heidelberg 1995 237 Literaturverzeichnis Etzel Hans Joachim Heilmann Heidi Richter Reinhard Hrsg IT Projektmanagement Heidelberg 2000 F Feretti Vittorio W rterbuch der Datentechnik Berlin Heidelberg New York 1996 Fischer Joachim Herold Werner Dangelmaier Wilhelm Nastansky Ludwig Suhl Leena Bausteine der Wirtschaftsinformatik 3 Aufl Berlin 2002 Fisher David T Myths and Methods a guide to software productivity New York 1991 Flechtner Harry M Substantial Revisions to U S Domestic Sales Law IHR 2004 Florida Jur Forms Legal and Business Database 20B 1 2003 Flume Werner Vom Beruf unserer Zeit fur Gesetzgebung in ZIP 2000 S 1427 Franz Wolfgang Techniken der modernen Software Entwicklung Munchen 1991 Fruhauf Karol Ludewig Joachen Sandmayr Helmut Software Prufung Stuttgart 1991 G Grupp Bruno EDV Pflichtenheft zur Hardware und Softwareauswahl 2 Aufl K ln 1991 Grieser Franz Irloeck Thomas Computer Lexikon 2 Aufl M nchen 1995 H Hansen Hans Robert Neumann Gustaf Wirtschaftsinformatik I Grundlagen betrieblicher Informationsverarbeitung 8 Aufl Stuttgart 2001 Hay
198. es ist bezuglich des Fehlerbegriffes insbesondere deswegen verwunderlich weil selbst die deutsche Rechtsprechung sich diesbezuglichen Zugestandnissen nicht versperrt Auf den Stand der Technik wird moglicherweise verwiesen um zu verhindern dass ggf die Gerichte einen Ausf hrungsstandard mittlerer Art und Giite zugrunde legen N hmen die Gerichte allerdings den Verweis insbesondere auf das Software Engineering als die die Softwareentwicklung beschreibende informationstechnische Disziplin ernst k men mit hoher Wahrscheinlichkeit Ergebnisse zustande die sich die Unterzeichner der Vertr ge nicht tr umen lie en Bez glich der Ausgangsfrage ist daher festzustellen dass in deutschen Mustern teilweise keine angemessenen Qualit tskriterien f r die Beurteilung der Leistung gew hlt und die mangelnde Eignung der Fehlerfreiheit ganz berwiegend nicht ber cksichtigt wird Die amerikanischen Muster bilden dazu in der Mehrzahl einen erfreulichen Kontrast E Verg tung Der Befund aus Mustern und Praxisbeispielen offenbart vergleichbare Konzepte In den amerikanischen finden sich mit Ausnahme eines Praxisbeispiels ausschlie lich zeitunabh ngige Verg tungsregeln Fixpreise Auch in den deutschen sind soweit nicht offen gelassen ausschlie lich Festpreisvereinbarungen anzutreffen 557 Wie in 243 Abs 1 BGB f r Gattungsschulden vorgesehen 210 Kapitel 8 Schlussfolgerungen Kapitel 8 Schlussfolgerungen A Struktu
199. essons Hannover 1994 Macneil lan R Gudel Paul J Madden Start Mall Rajib Malzer Hans Michael Marly Jochen Contracts 3 Aufl New York 2001 The vital Common Law Its role in a statutory age 18 U Ark Little Rock L J 555 Fundamentals of Software Engineering New Delhi 2003 Der Softwarevertrag Diss K ln 1991 Software berlassungsvertr ge 4 Aufl M nchen 2004 Maymon Gilbert W Cave William C Leitfaden des Software Projektmanagements Wiesbaden 1983 McManus John Wood Harper Trevor Merryman John Henry Information Systems Project Managament Delhi 2004 The Civil Law Tradition 2 Aufl Stanford California 1985 239 Literaturverzeichnis ders Western European and Latin American Legal Systems Charlottesville Virginia 1978 Movsesian Mark L Two Cheers for freedom of contract The Fall and Rise of Freedom of Contract In 23 Cardozo L Rev S 1529 M nchener Kommentar zum B rgerlichen Gesetzbuch Bd 1 Allgemeiner Teil M nchen 4 Aufl 2001 Bd 4 Schuldrecht Besonderer Teil 4 Aufl 2005 zitiert M Ko Bearbeiter M nchener Kommentar zum Handelsgesetzbuch Bd 6 373 406 CISG M nchen 2004 zitiert M Ko HGB Bearbeiter M ller Hengstenberg Claus Dieter Der Vertrags als Mittel des Risikomanagements Ein Pl doyer f r die dynamische Projektbegleitung im Vertrag CR 2005 S 385 ders Vertragstypologie der Computersoftwarevertr ge CR 2004 S 161
200. estatements f r F lle abgeleitet werden in denen ein Gericht die Parteivereinbarung f r unvollst ndig oder f r unconscionable h lt Es steht ihm dann frei eine den Umst nden angemessene Regel hinzuzuf gen bzw den Vertrag insgesamt oder bez glich bestimmter Teile f r unwirksam zu erkl ren Dies g be theoretisch Raum daf r auch hinsichtlich der Zielpr zision Erg nzungen bzw Subtraktionen vorzunehmen eine M glichkeit von der in dem hier untersuchten Bereich allerdings kein Gebrauch gemacht wurde Das Case Law hat sich in der in rechtlichen Dimensionen insbesondere im Common Law verh ltnism ig kurzen Zeitspanne von zwanzig Jahren als dynamisch erwiesen Wurde es noch 1984 f r selbstverst ndlich gehalten dass das Softwarehaus f r den Spezifikationsvorgang weitgehende Verantwortung bernimmt so zeigt sich in neueren Entscheidungen dass der Softwarebesteller zunehmend mehr am Projektrisiko beteiligt wird Bei zusammenfassender Betrachtung lassen sich im amerikanischen Recht keine Vorgaben f r die Pr zision des Vertragszieles erkennen Tendenziell 582 Zum Begriff siehe oben Kapitel 3 S 52 194 Kapitel 7 Vergleichende Darstellung ist eine einseitige Belastung eines Vertragsbeteiligten mit der Verantwortung fur detailgenaue Spezifikationen nicht unproblematisch Bei ausdrucklicher schriftlicher Vereinbarung und nicht v llig ungleicher Verhandlungsposition sind den vertraglichen Regelungen diesbez gl
201. esteller ist bereit daf r eine regelm ige Verg tung zu leisten VII Sonstiges Aus den Gew hrleistungsregeln ergeben sich keine besonderen Leistungsma st be MiO und MiN halten sich sehr kurz Treten gew hrleistungspflichtige M ngel auf wird der Auftragnehmer diese beheben MiO Nr 20 Abs 4 Die Gew hrleistung des AN richtet sich grunds tzlich nach 631ff BGB MIN Nr 8 1 187 Kapitel 6 Empirischer Befund in Deutschland Etwas ausf hrlicher ist die Regelung in SuS unter 11 Gew hrleistung 11 2 Als M ngel gelten Abweichungen der Vertragssoftware von der im Pflichtenheft beschriebenen Funktionsweise soweit diese Abweichungen die Tauglichkeit zum blichen im Pflichtenheft beschriebenen Funktionsweise beeintr chtigen Die Gew hrleistung besteht nicht wenn der Mangel nur unerheblich ist sich also insbesondere nicht erheblich auf die Gebrauchstauglichkeit auswirkt W hrend MiN auf den gesetzlichen Ma stab verweist nimmt SUS ausdr cklich auf das Pflichtenheft Bezug Im Ergebnis d rfte dies allerdings zu keinem Unterschied f hren da das Pflichtenheft zusammen mit dem Abweichungsbericht die zwischen den Parteien vereinbarte Gebrauchseignung bestimmt Alle Vertr ge enthalten Fixpreisregelungen wobei in MiN und MiO quartalsweise bzw monatliche Zahlungen f r die Wartung vorgesehen sind C Zusammenfassung und Ergebnis Die Autoren der Muster sind berwiegend ersichtlic
202. eutschland Fehlerbeseitigung ein fortlaufender Prozess der sich regelm ig Uber die gesamte Lebensdauer des Projektes erstreckt Diesem Umstand wird nur bei HE infolge seiner am softwaretechnischen Spiralmodell orientierten Ausrichtung Rechnung getragen Die Pflichten des Softwarehauses sind hier f r die jeweiligen Projektphasen benannt 3 Identifikationsphase Ziel der von S Anm dem Softwarehaus zu erbringenden Planungs und Beratungsleistungen im ersten Quadranten Anm der erste Quadrant umfasst nach 8 2 die Identifizierung der Anforderungen Alternativen Risiken und Einschr nkungen ist es also in enger Zusammenarbeit mit E Anm dem Softwarebesteller die Leistungsf higkeit Funktionalit t und nderungsf higkeit des Systems oder eines Teils davon zu bestimmen 4 Bewertungsphase Die identifizierten Alternativen werden im Bewertungsquadranten bewertet Die Entwicklungsteams werden von S gef hrt falls der Lenkungsausschuss nicht eine abweichende Regelung festlegt Die Ergebnisse der Entwicklungsteams sollen aus folgenden Komponenten bestehen Erstens aus einem inhaltlichen Modell das die Anforderungen entsprechend ihrem Konkretisierungsgrad simuliert zweitens aus einem Plan f r das weitere Vorgehen der den Bereich und den Grad der Umsetzung bestimmt drittens aus dem konkreten Ma nahmenplan zur Implementierung im n chsten Quadranten 5 Realisierungsphase
203. eveloped under the Prior Agreement FDRI represents and warrants that those MAS System enhancements developed by FDRI in furtherance of this Agreement shall be free of any defects which substantially affect the performance of the SMS System as updated by the SMS System Enhancements Bei AE bezieht sich die Einstandspflicht darauf dass keine Kopiermechanismen vorgesehen sind und keine Virus oder ahnliche Gefahr von der Software ausgeht Dar ber hinaus wird f r die ohne weiteres als notwendig vorausgesetzte Behebung von Defekten auf warranties gem den Authorization letters verwiesen Supplier shall provide such warranties for the repair of errors or defects in the Work as may be provided in the Authorization Letter applicable to such Work Supplier warrants that there are no copy protection or similar mechanisms within the Software which either now or in the future will interfere with the grants made in this Agreement Supplier also warrants that Supplier shall not install either now or in the future any malicious code program or other internal component e g software virus software worm software time bomb or similar component which is designed to damage destroy or alter software firmware or hardware or which is designed in any manner reveal damage destroy or alter any data or other information accessed through or processed by the Software in any manner or which is designed to adversely affect the operation of a c
204. evertrage in den Mittelpunkt stellt K nnte sich nicht auf die Softwareentwicklung beschr nken Zahlreiche andere Konstellationen aus der Praxis m ten mit bedacht werden Es fehlt jedoch an den ma geblichen Kriterien um eine sinnvolle Abgrenzung der rechtlich zu regelnden Thematik vornehmen zu k nnen was nicht zuletzt auf den Einflu des Internet zur ckzuf hren ist Hier entstehen best ndig neue Gesch ftsmodelle mit entsprechendem Regelungsbedarf die meist unmittelbar mit dem Einsatz und der Entwicklung von Software verkn pft sind Die Zeit f r einen solchen gro en Wurf der die Vielf ltigkeit des Umganges mit Software zufriedenstellend erfa t ist m E noch nicht gekommen Demgegen ber stellt die Softwareentwicklung eine vergleichsweise etablierte Projektform dar deren problematische Gesichtspunkte an zahllosen praktischen Beispielen auch in der Rechtsprechung nachvollzogen werden k nnen Diese Untersuchung hat dabei gezeigt dass sich ein Kernbereich dieser Gesichtspunkte durchaus umrei en l t Es ist der bereits eingangs erw hnte von Austausch und kontinuierlicher Pr fung gepr gte Prozess stufenweise konkretisierenden Vorgehens Im Ergebnis steht f r den Gesetzgeber daher die Aufgabe an einen Vertragstyp Softwareentwicklung zu schaffen Dieser sollte sich an der Form orientieren in der das Zusammenwirken der Vertragsparteien bei der Softwareentwicklung blicherweise erfolgt Verflechtungsgedanke
205. ezieht sie sich auf zwei Regelungskreise Der erste betrifft gewisserma en r ckw rts gerichtet das In Worte Fassen des aktuellen Projektstands also die Darstellung des status quo Der zweite 1 Die Beispiele k nnen nat rlich nicht repr sentativ sein Je nach Anforderungen kann auch die Aufgabenl sung f r das mittelst ndische Unternehmen zu einem Gro projekt die Website zu einem mittelgro en Projekt werden 17 Wie z B im in die Schlagzeilen geratenen Toll Collect Projekt einem gro en Industriekonsortium mit aktueller Beteiligung der DaimlerChrysler Financial Services AG 45 der Deutschen Telekom AG 45 und der franz sischen Cofiroute S A 10 http www toll collect de faq tcrdifro04 1_unternehmen jsp zuletzt abgerufen am 05 12 05 18 Als Juristen sollten wir ehrlich genug sein dieser bisweilen durchaus anzutreffenden Haltung mit offenen und selbstkritischen Augen entgegenzusehen 8 Kapitel 1 Allgemeiner Teil betrifft vorwartsgerichtet die antizipierte Zukunft des Projekts Die Aufgabe der rechtlichen Berater ist es mithin eine Form zu gestalten in der die Beteiligten das bisher Erreichte und das angestrebte Ziel wiederfinden Die Leistungsbestimmung wie sie hier verstanden wird betrifft beide Regelungs kreise Ihre Aufgabe ist es 1 das Ziel festzulegen 2 den Weg dorthin aufzuzeigen was 3 eine Standortbestimmung voraussetzt Dies soll auf Basis der Softwareentwicklung wie sie sich aus der Sicht
206. festgelegt sind z B in Anlage 2 wird der AN auf solche Termine rechtzeitig hinweisen Das Kontrastmuster SN S geht dar ber im Konkreten nicht wesentlich hinaus 6 Organisation des Projekts Mitwirkung des Auftraggebers 6 1 Zusammenarbeit Mitwirkung 6 1 1 Das Projekt erfordert eine enge Zusammenarbeit der Parteien Die Zeitplanung geht von einem erfolgreichen Ineinandergreifen der von den Parteien im Rahmen des Projektes zu erbringenden Leistungen und Vorleistungen aus Die Parteien haben die bislang bekannten Pflichten beider Seiten im Aktivit ten und Zeitplan Ziffer 2 1 festgelegt 6 1 2 Der Auftraggeber ist zur Mitwirkung auch im brigen verpflichtet insbesondere zur Beistellung von Testf llen Testdaten Testsystem und geeigneten Mitarbeitern s a Ziffer 6 6 6 1 3 GL regelt die Mitwirkung am ausf hrlichsten 14 Mitwirkung durch den Kunden 14 1 Allgemeine Mitwirkung Der Kunde unterst tzt die Arbeiten des Anbieters in angemessener Weise Weitergehende Regelungen bleiben unber hrt 14 2 Bereitstellung von Ressourcen 1 Der Kunde stellt die in seiner Betriebssph re liegenden Voraussetzungen sicher die f r die vertragsgem e Erbringung der Leistungen des Anbieters erforderlich sind Insbesondere stellt der Kunde dem Anbieter die im Erstellungsschein ES 6 1 aufgef hrten R ume Mitarbeiter Hardware und Software zu den dort vorgesehenen Konditionen und Zeiten zur Verf gung 2 Ben
207. ffen so bildet diese den Ma stab f r eine ggf sp ter notwendig werdende Kontrolle Der Fehler ist dann wie auch vom Gesetzgeber vorgesehen durch die vertragliche Vereinbarung definiert Dies kann eine Einstandpflicht ber die anerkannten Regeln der Technik hinaus zu Folge haben Liegt eine pr zise Leistungsbestimmung vor ist diese das Ma aller Dinge Sie fixiert die four corners of the instrument zwischen denen die geschuldete Leistung Gestalt annimmt Auf unausgesprochene Erwartungen vorausgesetzte Bedingungen oder Einschr nkungen kommt es nicht an Unjuristisch bedeutet dies nichts anderes als die triviale Feststellung Halte Dein Versprechen Der Gewinn aus der rechtsvergleichenden Betrachtung sollte f r das deutsche Recht aus der prinzipiell gro z gigeren Sichtweise des 573 So zutreffend auch Redeker der betont dieses Problem habe sich in der Praxis nie gestellt CR 2005 a a O S 700 703 574 BGH U v 15 10 02 in NJW 2003 S 200 201 Der Auftraggeber hat die Entstehung eines mangelfreien zweckgerechten Werkes zu gew hrleisten Entspricht die Leistung nicht diesen Anforderungen so ist sie fehlerhaft und zwar unabh ngig davon ob die anerkannten Regeln der Technik eingehalten worden sind Ausschlaggebend ist allein dass der Leistungsmangel zwangsl ufig den angestrebten Erfolg beeintr chtigt Zuletzt auch OLG Bremen U v 07 07 04 4 U 64 03 in BauR 2005 S 1679f Das OLG N rnber
208. ffen ist gleich 4 6 Kommt der AN mit dem Testbetriebsende Abnahmereife schuldhaft nach Ma gabe der Bestimmungen dieses Vertrages in Verzug so verpflichtet er sich f r jede Woche der Termin berschreitung eine Vertragsstrafe von 2 des Pauschalfestpreises insgesamt aber h chstens 10 des Pauschalfestpreises an den AG zu zahlen Weitergehende Schadensersatzanspr che des AG sind ausgeschlossen es sei denn die Haftung ergibt sich aus Nr 9 Anm Nr 9 enth lt eine allgemeine Haftungsregel dieses Vertrages Nr 4 2 betrifft wie sich im Gegenschluss aus 4 3 ergibt vom Softwarehaus zu vertretende voraussichtliche Projektverz gerungen Es wird der etwas hilflos wirkende Versuch unternommen den Terminplan durch ein der Verz gerungsmitteilung anschlie endes Verfahren zu retten Eine Verweigerung der Zustimmung ndert an den Umst nden d h den Gr nden und Auswirkungen der Verz gerung nichts M glicherweise ist die Vertragsstrafe bei Verz gerung in Nr 4 6 wirkungsvoller 181 Kapitel 6 Empirischer Befund in Deutschland Bei MiO finden sich unter 28 Informationspflichten folgende Regelungen Der Auftragnehmer wird dem Auftraggeber sp testens am 10 jeden Monats Bericht ber den Projektfortschritt im vergangenen Monat geben Der Auftragnehmer wird sofort nach Vertragsschluss dem Auftraggeber eine Liste seiner bei der Vertragsdurchf hrung beteiligten Mitarbeiter zusenden und dem Auftraggeber jede pe
209. fgabe der Steuerung von Softwareentwicklungsprojekten zu finden Dabei mag der Versuch einer scharfen Trennung von Technik und Recht in manchen deutschen Mustern der rechtssystematischen Idee entspringen zwei unabh ngig voneinander bestehende Begriffswelten sozusagen einen allgemeinen und einen speziellen Teil zu schaffen Der juristische Teil kann dann wie in zumindest einem Beispiel anzutreffen zur Abwicklung eines umfangreicheren Projektes schlicht ungeeignet sein Doch gibt dies allenfalls einen Hinweis auf eine bisweilen vorzufindende Neigung die im amerikanischen Rechtsraum seltener anzutreffen ist nicht jedoch einen allgemeinen Befund berwiegend werden die Grenzen von Begriffssystemen erkannt Bedenklicher stimmt angesichts der Untersuchungsergebnisse die Einsch tzung dem Civil Lawyer sei das Prinzip der Rechtssicherheit so wichtig dass er bereit sei die Einzelfallgerechtigkeit daf r zu opfern In dem Wunsch nach dieser Rechtssicherheit k nnte eine Triebfeder fur die oben beschriebene extensive rechtliche Ausformung von nderungsszenarien in den deutschen Mustern erblickt werden Hier gilt es allerdings Rechtssicherheit in Vertr gen und in Gesetzen zu unterscheiden Die letztere hat nicht nur die Aufgabe dem Normadressaten ein regelgerechtes Verhalten zu erm glichen sondern muss auch unter dem Gesichtspunkt der Gleichbehandlung bestehen Gesetze gelten f r alle Vertr ge begr nden dagegen nur Pflichten zw
210. freedom and public control This conflict is unavoidable in a liberal democracy like ours and grand theories can do little to resolve it The best the law can do is fashion reasonable compromises on a case by case basis Mark L Movsesian Two Cheers for freedom of contract The Fall and Rise of Freedom of Contract In 23 Cardozo L Rev S 1529 1547f 229 59 S 59 59 e O 59 a Kapitel 8 Schlussfolgerungen Zum anderen ist die Kontinuitat der Rechtsprechung Einordnung von Softwareentwicklungsvertragen als Werkvertrag durch die Schuldrechtsreform eine Revolution im soeben genannten Sinne in Frage gestellt Unabh ngig davon bed rfen weitere Aspekte der Ber cksichtigung Die Vielfalt der oben unter Technik und Recht aufgef hrten Abweichungen typischer Elemente eines Softwareentwicklungsvertrages vom klassischen Bild der im BGB vorgefundener Regelungsmodelle setzt dessen Begriffswelt erheblichen Spannungen aus Diese Spannung kann wie sich am Beispiel der Einordnung von Software zeigen l sst bisweilen nur mit durchaus fragw rdigen Konstruktionen gel st werden Unter der Pr misse dass nur ganz wenige wichtige Lebensgebiete wie etwa die Vertragsbeziehungen im Bau und Transportwesen erfassbar und getrennt regelbar sind fragt sich ob Software mittlerweile dieser Gruppe zugerechnet werden muss Die Antwort ist m E eindeutig Nicht ohne Grund wird heute von einem Informationszeital
211. fur besonders riskant angesehenen Bereiches in das Pflichtenprogramm des Softwarebesteller ein 31 Haftung 1 2 Der AG ist im Rahmen der Schadensminderungspflicht zur Datensicherung und zur Virenabwehr nach dem Stand der Technik verpflichtet Eine hnliche Bestimmung findet sich auch bei SN S 9 Haftungsbeschr nkung 9 9 Datensicherung Der Auftraggeber ist f r eine regelm ige Sicherung seiner Daten verantwortlich Bei einem vom Auftragnehmer verschuldeten Datenverlust haftet der Auftragnehmer deshalb ausschlie lich f r die Kosten der Vervielf ltigung der Daten der zu erstellenden Sicherheitskopien und f r Kosten der Wiederherstellung der Daten die auch bei einer ordnungsgem erfolgten Sicherung der Daten verloren gegangen w ren Dort werden dem Softwarebesteller zus tzlich weitergehende Nacherf llungsm glichkeiten einger umt 8 9 Minderung oder R cktritt Die Nacherf llung gilt nicht schon mit dem zweiten Nacherf llungsversuch als endg ltig fehlgeschlagen Vielmehr steht dem Auftragnehmer w hrend der Nachfristen die Anzahl der Nacherf llungsversuche in Abh ngigkeit von der Art des Mangels den besonderen Umst nden Personal u sowie der Art der betroffenen Software Beteiligung Dritter u frei In den BVB schlie lich finden sich bedeutsame Einzelregelungen hinsichtlich des Treffens von Entscheidungen im Rahmen von nderungen und Erg nzungen sowie der Besch
212. g U v 23 06 05 13 U 1943 02 in BauR 2005 S 1680 formuliert dies so Ergibt die Auslegung ein bestimmtes Vertragssoll so ist das Werk mangelhaft wenn die Sollbeschaffenheit nicht erreicht ist 220 Kapitel 8 Schlussfolgerungen amerikanischen Rechts gezogen werden Substantial performance in diesem Sinne hei t die zentralen Funktionen die die Software erf llen soll nicht ber Detailfragen aus den Augen zu verlieren Nach der Paretoregel verursachen die letzten 20 also die Spezialf lle etwa 80 des Aufwandes Vielleicht wird deswegen davon ausgegangen das Projekt sei etwa zur H lfte fertig wenn die Entwickler davon sprechen es w re bei einem Erf llungsgrad von 90 angelangt Wenn dem Softwarehaus ein perfektionistischer und vermeintlich pr ziser Fehlerbegriff im Nacken sitzt ist dem Projekt nicht gedient und die Abnahmeprozedur wird leicht zum Spie rutenlaufen f r beide Vertragsparteien Gro z gigkeit ist nicht mit Nachgiebigkeit zu verwechseln sondern stellt eine Konzentration auf das Wesentliche dar Durch Kombination dieser wesentlichen Leistungsmerkmale mit einer pr zisen Leistungsbestimmung kann eine tragf hige Basis gerade f r hochkomplexe Projekte geschaffen werden 575 5 0 Kapitel 3 A Ill 1 b S 22 578 Vgl hierzu oben Kapitel 2 A Ill 3 b S 31 Fn 115 und die instruktive Darstellung bei De Marco The Deadline der zwischen Zeitplan und Ziel unterscheidet und
213. g des Zweckes der bergabe fehlt Einen ersten Ansatz zur Kl rung enth lt SN B wenn er die Geeignetheit f r eine allerdings nicht n her bezeichnete Adressatengruppe verlangt Es ist hier wohl davon auszugehen dass Bedienungsanleitung Benutzungsanleitung Bedienerdokumentation f r den Endanwender d h den die Software lediglich benutzenden Personenkreis konzipiert werden sollen Die Entwicklungsdokumentation Entwicklerdokumentation oder systemtechnische Dokumentation ist demgegen ber f r die Entwicklung d h f r den in der jeweiligen Programmierung sachverst ndigen Personenkreis vorgesehen Angesichts der Bedeutung die einer Dokumentation insbesondere f r die nderung beizumessen ist erstaunt diese Ungenauigkeit Nur bei GL der insoweit im Erstellungsschein unter 1 3 auch n here Angaben zur Qualit t der 138 Kapitel 6 Empirischer Befund in Deutschland geforderten Dokumentation macht klingt der eigentlich Zweck der berlassung einer systemtechnischen Dokumentation an Der Kunde erh lt eine Benutzerdokumentation nach DIN 66285 die im brigen folgende Anforderungen zu erf llen hat Die Benutzerdokumentation wird dem Kunden in facher Ausfertigung als Printversion und auf geeignetem Datentr ger im format zur Verf gung gestellt Der Kunde erh lt eine systemtechnische Dokumentation die es einem durchschnittlich erfahrenen Programmierer erm glicht den Programmplan und das Know How nachvollziehen
214. gemeine Gesch ftsbedingungen hinaus auf Gesch fte angewandt bei dem der Vertragstext vom wirtschaftlich und intellektuell berlegenen entworfen wurde Die Auslegung muss stets den Grundsatz der Privatautonomie beachten darf also nicht zu einem Ergebnis f hren das den bereinstimmenden 323 MUKo Mayer Maly Busche 133 Rn 44 324 Unter dem Stichwort der Andeutungstheorie BGH 20 Dezember 1974 V ZR 132 72 BGHZ 63 359 23 Marz 1979 V ZR 24 77 BGHZ 74 116 25 M rz 1983 V ZR 268 81 BGHZ 81 150 zuletzt 17 Februar 2000 IX ZR 32 99 NJW 2000 1569 Palandt Heinrichs 133 Rn 19 a A Bamberger Roth Wendtland 133 Rn 26 Erman Palm 125 Rn 16 M Ko Mayer Maly Busche 133 Rn 29 53 hnlich Bamberger Roth Wendtland 157 Rn 12 Palandt Heinrichs 133 Rn 20 Bamberger Roth Wendtland 157 Rn 20 Erman Armbruster 157 Rn 30 MiKo Mayer Maly Busche 133 Rn 5 M Ko Mayer Maly Busche 157 Rn 16 Palandt Heinrichs 133 Rn 23 ebenso Bamberger Roth Wendtland 157 Rn 13 a A Jauernig Jauernig 133 Rn 11 vgl auch Bamberger Roth Schmidt 305c Rn 23 der auf den historischen Ursprung der Unklarheitenregel im r mischen Recht hinweist ambiguitas contra stipulatorem est M Ko Mayer Maly Busche 157 Rn 7 bei Ausnutzung wirtschaftlicher bermacht Siehe oben S 100 A 32 a 32 32 32 on O 32 33 O oO 33 a 1
215. ges ist die Lieferung Inbetriebnahme Einf hrung und Wartung der Anwendungssoftware f r den in der Pr ambel genannten Zweck wobei einige Teilleistungen nicht Vertragsgegenstand sind wie sich aus den folgenden Detaildefinitionen ergibt Insbesondere geh rt zu den Pflichten des Auftragnehmers 1 die Definition einer lauff higen Konfiguration aus Hardware Software und Netzwerkverbindungen die die beim Auftraggeber und seinen H ndlern anfallenden Datenmengen und Anwendungen unter Verwendung der in Beilage 2 definierten Anzahl an Endger ten und unter Betrieb der in Beilage 2 definierten Schnittstellen zu anderen Systemen bew ltigen kann 2 die Definition der Schnittstellen zu anderen Systemen gemeinsam mit dem Auftraggeber 526 Der Vertrag wurde 1999 unterzeichnet Der Softwarebesteller wurde durch ein Consultingunternehmen bei dem Vertragsentwurf und der Vertragsverhandlung unterst tzt Ob das Projekt erfolgreich durchgef hrt wurde ist nicht bekannt Das Softwarehaus wird als Auftragnehmer der Softwarebesteller als Auftraggeber bezeichnet Die Softwarel sung sollte auf Basis der vom Auftragnehmer entwickelten Standardmodule an die individuellen Verh ltnisse beim Auftraggeber angepasst werden 27 Dieser Vertrag wurde im August 2001 unterzeichnet und das Projekt nach etwa zwei Jahren erfolgreich abgeschlossen Das Softwarehaus wird als Auftragnehmer der Softwarebesteller als Partner bezeichnet Es handelte sich um die vol
216. get unter dem Vorbehalt der Zustimmung der Projektleitung um h chstens 20 erh hen Die Projektleitung kann den Spielraum nach 7 Abs 2 bei der Verg tung und 19 beim Terminplan aussch pfen Weitere nderungen bed rfen der Zustimmung des Lenkungsausschusses 161 Kapitel 6 Empirischer Befund in Deutschland und die Vertragspartner auf m glichst konkrete Anderungsinhalte und folgen zu verpflichten Weiter ausgeformt ist das ansonsten dreistufige Verfahren bei GL 12 Change Management 12 1 nderungsrecht 1 Soweit dies nicht im Erstellungsschein ES 1 5 ausgeschlossen ist kann der Kunde ab dem Beginn der Realisierung bis zur Abnahme schriftlich verlangen dass die gem VB 4 1 im Erstellungsschein festgelegte Leistungsbeschreibung ge ndert wird nderungsverlangen 2 Der Anbieter kann nderungen aufgrund seiner anderweitigen betrieblichen Auslastung seiner mangelnden Leistungsf higkeit oder aufgrund sonstiger Gr nde als unzumutbar schriftlich ablehnen 3 Der Anbieter pr ft unverz glich das nderungsverlangen Er gibt dem Kunden einen schriftlichen Hinweis wenn das nderungsverlangen erkennbar fehlerhaft unvollst ndig unklar oder unm glich ist er weist auf m glicherweise drohende M ngel hin Der Kunde entscheidet unverz glich ber ein nderung des nderungsverlangens VB 17 3 1 bleibt unber hrt Anm diese Regelung schlie t eine Gew hrleistungs pflicht f r den Fall aus dass de
217. glich der zu erbringenden Leistung werden dabei in eine sehr unterschiedlich als Leistungsschein KO Funktionsbeschreibung SO Pflichtenheft MA und SN B Erstellungsschein GL und die BVB oder fachliche Feinspezifikation SE AN bezeichnete Anlage verwiesen 502 Koch Computervertragsrecht Formular Nr 7 im Anhang Vertrag ber die Erstellung von Software 5 3 Marly Software berlassungsvertr ge Formular VII in Teil F berlassung von Individualsoftware im Unternehmensverkehr mit Quellcode berlassung S 708ff M nchener Vertragshandbuch Bartsch Bd 3 Formular Ill H 4 Vertrag ber ein Softwareprojekt S 57 3ff Sobola Dobmeier Gl cker Vertragsmuster D III Softwareerstellungsvertrag S 233ff Schneider Handbuch Vertragsbeispiele IV und V im Anhang Vereinbarung zur Softwareerstellung und Vereinbarung zur Erstellung und Installation von Software S 2380ff 2396ff Schr der Softwarevertr ge Textabdruck Softwarelizenzvertrag S 15ff Heppner Softwareerstellungsvertr ge Muster A1 im Anhang Muster f r einen evolution ren Softwarevertrag zwischen Endanwender E und Softwareunternehmen S S 387ff 59 Entnommen aus M ller Hengstenberg BVB EVB IT Computersoftware BVB Erstellung S 180ff Bei den Besonderen Vertragsbedingungen f r die Beschaffung von DV Leistungen BVB und den erg nzenden Vertragsbedingungen f r d
218. gsvertrages sehen eine einfache nicht bertragbare Lizenz vor wobei MiN f r kundenspezifische Auftragsprogrammierung ein ausschlie liches Verwertungsrecht beim Softwarebesteller begr ndet 10 1 ll Bestandteile der Lieferung MiO verlangt unter Nr 3 S 1 s o die Lieferung der Anwendungssoftware und unter S 2 Nr 10 die Lieferung der Dokumentation sowie des Sourcecodes der Anwendungssoftware S 2 Nr 7 und Nr 9 Teil des Vertragsgegenstandes ist die Lieferung des Sourcecodes aller Programme mit Ausnahme der Zeichenroutinen und CAD Module sowie dessen Updates Der Auftraggeber hat das Recht den Sourcecode ausschlie lich im Rahmen des im Punkt Immaterialg terrechte beschriebenen Nutzungsbereiches zu nutzen Der Lieferung des Sourcecodes als bertragung des eigentlichen Know How wird besondere Bedeutung beigemessen wie sich aus Nr 10 Terminplan ergibt Dort hei t es in Absatz 3 Die Lieferung des Sourcecodes erfolgt jeweils Zug um Zug gegen Zahlung des bei Abnahme der Softwarelieferung f lligen Betrages im yas Kapitel 6 Empirischer Befund in Deutschland Falle der Abnahme bei X auch gegen Ruckstellung der Bankgarantie fur die Vorauszahlung Diese Lieferpflicht des Sourcecode darf hier insofern als ungew hnlich angesehen werden als das Softwarehaus auch f r die Wartung verantwortlich sein soll und der Softwarebesteller kein ausschlie liches Nutzungsrecht erh lt Sie wird verst ndlich we
219. gte Referenzen das Risiko einer nderung der Leistungsbeschreibung mit sich bringt weshalb die Priorisierung der unterschiedlichen Dokumente zur Bestimmung der Leistungspflicht bedeutsam ist Mall Rajib Fundamentals of Software Engineering New Delhi 2003 S 23 The SRS document Anm Software requirement specification normally serves as a contract between the development team and the customer Any future dispute between the customer and the developer can be settled by examining the SRS document letztere Aussage d rfte nach den Erfahrungen der Rechtspraxis allerdings eher Wunschdenken sein Schaub betont die Bedeutung des Detaillierungsgrades f r die Klarheit des Projektganges S 329 Ihde unterstreicht die Bedeutung des Pflichtenhefts als Ma stab f r die zu erbringende Leistung Ihde Thomas Das Pflichtenheft beim Softwareerstellungsvertrag CR 1999 S 409 Schneider weist auf das Risiko eines Rundum Sorglos Pakets f r das Softwarehaus vor dem Hintergrund unzureichender Leistungsbeschreibung hin CR 2003 S 317 auch in der Rechtsprechung wird die zentrale Bedeutung eines Pflichtenhefts f r die Definition der Leistungspflicht unterstrichen OLG D sseldorf U v 10 06 92 CR 1993 S 361 OLG K ln U v 03 12 93 OLGR K ln 1994 S 13 OLG K ln U v 12 02 99 NJW RR 1999 S 1733 Siehe dazu bereits oben unter Kapitel 5 A Ill 2 OLG D sseldorf U v 10 06 92 CR 1993 S 361 OLG K ln U v 26 06 92 OLGR K ln
220. gten teilweise sehr weitgehende Konsequenzen gezogen 1 Beratungs und Dokumentationspflichten des Auftragnehmers Bereits in fr heren Entscheidungen pointiert die Rspr die Pflichten des Softwarehauses bei der Individualsoftwareentwicklung Die Entwicklung m sse in einem intensiven Dialog stattfinden den der Auftragnehmer anzubieten und zu leiten habe Auch wenn die Pflichtenhefterstellung von Auftraggeberseite zu erfolgen habe so treffe das Softwarehaus doch eine Pflicht zu umfangreicher und sorgf ltiger Pr fung Die Aufgabenanalyse und Beratung sei unabh ngig von der Einordnung als Kauf oder Werkvertrag selbstverstandlich und erforderlich Diese Einsch tzung wird von der lteren Literatur geteilt Es stelle eine notwendige Hauptleistung des Softwarehauses dar zur Betriebsorganisation zu beraten die der Projektierung einer geeigneten Informatikl sung voran bzw mit ihr einhergeht Der Umfang der Nebenpflichten des Softwarehauses h nge allerdings von dem Ma des Vertrauens auf seine Fachkunde ab Dieses wiederum richte sich nach der eigenen Fachkunde des Auftraggebers und der Komplexit t der Software sowie der von beiden 464 a a 0 S 174 dies f hre vertrags und gesellschaftsrechtliche Konstruktionen an ihre Grenzen 65 a a 0 S 305 466 Bormuth Schmitz AiB 1993 S 31 87 M ller Hengstenberg CR 2005 S 385 386 der dabei besonders die Phase des Designs der Projektziele hervorheb
221. h darum bem ht einen eigenen Ansatz zu verfolgen Dies zeigt sich am deutlichsten bei der unterschiedlichen Terminologie etwa hinsichtlich des Vertrages selbst dem Liefergegenstand oder der Dokumentation aber auch beim Vertragsaufbau den Fragen von Sourcecode bergabe und dem Umfang der bertragung von Nutzungsrechten Dabei neigen die Muster auch zu einer abstrakten Formulierungsweise Es wird ganz berwiegend versucht einen Hauptvertrag mit abschlie ender juristischer Regelung erg nzt um Anlagen zur Kl rung der technischen Fragen zu konzipieren Eine Vergleichbarkeit der Vertr ge ist nach dem Vorstehenden nur eingeschr nkt m glich In den Praxisbeispielen wird bereits durch die Benennung des Vertrages in zwei F llen eine klare Einordnung als Werkvertrag versucht Dabei werden eine Vielzahl auch technischer Details bereits im Hauptvertrag geregelt 188 Kapitel 6 Empirischer Befund in Deutschland Muster und Praxisbeispiele sind von verschiedenen Ausnahmen abgesehen um Ausgewogenheit bemuht und burden keinem der Vertragspartner berm ige Pflichten auf Tendenziell beg nstigen die Muster und Praxisbeispiele eher von einer Ausnahme abgesehen in nachvollziehbarem Ma e den Softwarebesteller In fast allen Mustern fehlt es an einer hypothetischen Einf hrung in die tats chlichen Gegebenheiten Eine unterschiedliche Ausgangssituation wird nicht erkl rt sondern vorausgesetzt F r den Leser und Verwender wi
222. hbesserung durch den mit den Verh ltnissen am besten vertrauten Auftragnehmer gesch he womit Werkvertragsrecht sach und interessengerecht w re Auch die brige Rechtsprechung wendet ganz berwiegend wenn auch meist ohne Begr ndung Werkvertragsrecht an Das Werkvertragsrecht passe besser weil die Verj hrung an die Abnahme und nicht an die 383 Koch ITRB 2002 S 297 Braun BB 1992 S 154 der von der Konditionierung der Hardware spricht 364 WM 1971 S 615 NJW 1987 S 1259 NJW 1990 S 3011 NJW 1996 S 1745 NJW RR 1998 S 1128 NJW RR S 347 NJW 2001 S 1718 CR 2002 S 93 385 U v 04 November 1987 VIII ZR 314 86 Juris KORE305838701 Rn 16 386 U v 14 Juli 1993 VIII ZR 147 92 Juris KORE372139300 Rn 23 367 U v 22 Juli 1998 VIII ZR 220 97 Juris KORE306249800 Rn 16 F rderanlage ebenso U v 15 April 2004 VII ZR 291 03 Juris KORE311192004 Rn 11 Mobilheim 68 U v 16 Juli 2002 X ZR 27 01 CR 2003 S 244 245 F amp E Vertrag wo ein Werkvertrag allerdings auch bei hohem Erfolgsrisiko infolge der Vertragshoheit der Parteien nicht ausgeschlossen wird 36 U v 7 M rz 2002 III ZR 12 01 NJW 2002 S 1571 1573 Buchhaltung 370 BGH a a O NJW 2002 S 1572 371 OLG Oldenburg U v 14 8 87 CR 1988 S 214 LG Frankfurt B v 15 12 88 ECR LG S 79 LG Karlsruhe B v 13 5 91 CR 1991 S 544 OLG Koblenz U v 4 10 91 NJW RR 1992 S 688 OLG K
223. he Change 75 Kapitel 4 Empirischer Befund in den USA Order A sample Change Order is set forth in Exhibit B attached to and made part of this Agreement 5 1 2 Change Order Evaluation Developer will evaluate each Change Order without charge within ten 10 days of its receipt and will provide Client with a the change in cost as a result of the Change Order b the impact if any of the Change Order on the completion date and milestone deadlines and c the availability of Developer s resources to carry out the Change Order Developer may in its sole discretion refuse to carry out any proposed Change Order 5 1 3 Change Order Acceptance If Developer agrees to carry out the proposed Change Order Client will promptly give Developer written authorization to carry out the Change Order by executing the Change Order in the manner provided on Exhibit B 5 2 Performance of Change Order Developer will begin performance in accordance with a Change Order immediately upon its execution by Client Developer has no obligation to perform any additional services before receiving the executed Change Order and Client has no obligation to pay Developer for any services performed pursuant to a Change Order before that Change Order is executed by Client 5 3 Change Order as Binding Agreement Once fully completed and executed each Change Order is deemed to be incorporated into and to be part of this Agreement and will constitute a forma
224. he Rechte an den vom Softwarehaus entwickelten Systemen ausschlie lich bei diesem verbleiben Hat der Softwarebesteller eigene processes entwickelt kann er das Softwarehaus dar ber informieren dass er diesbez glich eine Ausnahme als gegeben ansieht und eigene Rechte beansprucht Aus den Vertragstexten ergibt sich dass Service entweder als die zentrale Leistung FP und AE oder jedenfalls als wesentlicher Vertragsbestandteil anzusehen ist So hei t es in FP in der Pr ambel WHEREAS PRODIGY desires to engage FDRI to continue to provide full life cycle systems development data processing services and other services for PRODIGY in connection with PRODIGY S member billing operations and to create a software development team at FDRI dedicated to the development of a Member Administrative System the MAS System for PRODIGY In AE trifft man ebenfalls in der Praambel auf folgenden Wortlaut WHEREAS Company desires to retain Supplier to furnish the programming training consulting or other services the Services 258 Unter Software Titel and Rights 25 Purchase Agreement Nr 4 260 Nr 1 1 8 2 a dem Softwarehaus wird dabei allerdings untersagt w hrend der Vertragslaufzeit Rechte an Wettbewerber zu bertragen Die Lizenzrechte sind an den bestehenden Vertag gekn pft Nr 4 1 1 und 4 1 2 wobei der Softwarebesteller die M glichkeit hat bei Vertragsende das Recht auf zeitlich unbesch
225. her insgesamt nicht zu berzeugen Der Verweis auf den Stand der Technik soll die magische Wirkung einer Qualit tssicherung entfalten Dies kann ihm nicht gelingen Er ist Ausdruck des Wunsches zumindest einen Bezugspunkt zu der vertrauten juristischen Welt zu setzen die den Anschein einer Subsumtionsm glichkeit er ffnet Das Projekt Softwareentwicklung wird auf diese Weise nicht gef rdert Vielmehr kann sich best tigt sehen wer ein Spezifikum des Civil Law darin sieht dass generelle Aussagen auf Kosten der Besonderheit des Einzelfalles berbetont werden IV Erfolgsorientierte Fehlerbestimmung Die Untersuchung hat gezeigt dass Fehlerfreiheit als Erf llungsma stab bei komplexer Software aus Sicht des Softwareengineering ungeeignet ist Dies wird von Teilen der deutschen Rechtsprechung ebenso beurteilt und findet sich in der ganz berwiegenden Anzahl der amerikanischen Muster und Praxisbeispiele in Anlehnung an den in Literatur und Rechtsprechung weitgehend anerkannten Grundsatz dass substantial performance f r eine vertragsgem e Erf llung ausreicht wieder Dessen ungeachtet halten die deutschen Muster mit gro er Mehrheit an dem Kriterium der Fehlerfreiheit fest Der Grund hierf r ist vermutlich in der Bef rchtung zu finden das Softwarehaus k nne sich auf einfache Weise aus der Verantwortung f r 572 Merryman The Civil Law Tradition a a O S 72 der anmerkt die traditionelle Sichtweise
226. hvertr ge von Ware und Geld darstellen um so differenzierter f llt die Beurteilung der Verursachungsbeitr ge im Falle eines Scheiterns aus Die Leistungsbestimmung wird den Risikosph ren beider Parteien zugeordnet und die Gerichte pr fen im Zweifelsfall anhand der konkreten Vereinbarungen und der Projektgeschichte genau nach wie die Verantwortungsbereiche abgegrenzt wurden und welche Beitr ge die Parteien erbracht bzw nicht erbracht haben 58 Kapitel 4 Empirischer Befund in den USA Kapitel 4 Empirischer Befund in den USA Die ersten Kapitel haben gezeigt dass es aus technischer und rechtlicher Sicht kein einfaches Unterfangen darstellt die Leistung in einem Softwareentwicklungsvertrag zu bestimmen Da die Informationstechnologie und mithin die Produktion von Software ein bedeutender Industriezweig ist werden vielfach entsprechende Vertrage geschlossen In diesem Kapitel werden sieben Musterentw rfe und drei Beispiele aus der Praxis untersucht A Musterentwurfe Die Untersuchung basiert auf sieben Musterentw rfen von Raysman Brown RB David F Simon DaS Amy Slater AS und Diane W Savage DS sowie einem in der Datenbank nicht genannten Autor FL f r Florida RB und DaS unterscheiden zwischen Vertr gen die an den Interessen des Softwarehauses Vendor Oriented und denen des Softwarebestellers User Oriented orientiert sind Es wurden jeweils beide Varianten in die Untersuchung aufgenommen im F
227. i der Spezifikation In dem bestellerfreundlichen Vertrag AD sind keine besonderen Pflichten des Bestellers vorgesehen 280 Im Purchase Agreement unter 9 281 Im Purchase Agreement unter 19 b Unter 13 wird software als system definiert Diese etwas un bersichtliche Vorgehensweise macht es verst ndlich warum in einigen Vertr gen wie z B AE oder auch aus Gesetzen wie dem U C C bekannt zu Beginn des Vertrages ein eigener Abschnitt den Definitionen gewidmet wird 91 Kapitel 4 Empirischer Befund in den USA Das Element der Zusammenarbeit in FP wird durch eine Regelung bezuglich der Notwendigkeit von Berichten und gemeinsamer Besprechungen dokumentiert die mindestens einmal im Vierteljahr stattfinden sollen Progress Reports and Meetings for SMS and MAS FDRI and PRODIGY agree to meet regularly as described in Exhibit 1 Section 3 to review progress ofthe MAS and SMS Systems Development and Maintenance Such meetings shall be held as needed but in any event not less frequently than quarterly and shall be documented in writing and signed by the Project Managers and reflect all questions discussed and decisions made VI Ver nderungen Change Management Das Change Management wird bei FP in zwei Regelungen behandelt Selbst allt gliche nderungen bed rfen der Zustimmung durch die Projektleitung und substantielle nderungen sollen nur in der Form schriftlicher Vertragserg nzungen erfolgen Change orders Day t
228. iance und schlie lich system shall meet needs reichen Ein Zusammenhang mit der Ergebnisvarianz ist nicht erkennbar wobei davon auszugehen ist dass diese angesichts der berwiegend detaillierten Bestimmungen zum Spezifikationsverfahren und Change Management hoch eingestuft werden kann Bei hoher Ergebnisvarianz wird in den Praxisbeispielen zeitabh ngige Verg tung gew hlt w hrend bei geringer Ergebnisvarianz ein Fixpreis vorgesehen ist In den Mustern spielt diese Differenzierung keine Rolle Hier trifft man ausschlie lich auf zeitunabh ngige Verg tungsregeln Fixpreise Was die Zuordnung zu Vertragsarten anbelangt so ist sie in den untersuchten Beispielen ohne Bedeutung Es wird keine klare Einordnung erkennbar Die Leistungsbeschreibung ist am Ergebnis ausgerichtet wobei der Schwerpunkt der vom Softwarehaus geforderten Leistung unterschiedlich auf Service und Lieferungselemente verteilt wird Alle Muster gehen davon aus dass die Bereitstellung funktionsf higer Software geschuldet ist und dies hier mit Ausnahme der am Softwarebesteller orientierten Muster durch die Erbringung von Serviceleistungen erreicht wird 98 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland 3 DEUTSCHER TEIL Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland A Einordnung und Bedeutung der Rechtsquellen I Rechtsprechung und Gesetz Das Gewaltenteilungsprinzip geht historisch davon aus dass ein luckenloses Gesetz v
229. ice st tzt sucht der deutsche Gesetzgeber dieses Prinzip durch Kodifikation zu verwirklichen Dass dies nicht immer gelingt versteht sich von selbst Die M glichkeit der Kodifikation bietet jedoch den auch von Vertretern des Common Law anerkannten Vorteil ex ante rules zu schaffen d h Reformen mit abschlie ender Wirkung f r die 585 Redeker weist dementsprechend im Zusammenhang mit der Schuldrechtsreform darauf hin dass der Gesetzgeber Probleme auch schaffen kann wenn er die Spezifikation besonderer bei Software aber mittlerweile weit verbreiteter technischer Produkte nicht hinreichend ber cksichtigt In CR 2005 S 700 705 Hier sei beispielhaft nur auf den provokativen Titel des Aufsatzes von Schneider verwiesen Softwareerstellung und Softwareanpassung Wo bleibt der Dienstvertrag In CR 2003 S 317 Maryland s Chief Judge Chase zitiert nach Madden Start The vital Common Law Its role in a statutory age 18 U Ark Little Rock L J 555 Anschaulich bei Salmond im Anschluss an eine deutliche Stellungnahme zu Gunsten von Kodifikationsl sungen im englischen Recht formuliert In the most carefully prepared of codes subtle ambiguities will come to light real or apparent inconsistencies will become manifest and omissions will reveal themselves No legislative skill can effectually anticipate the complexity and variety of the facts In Salmond on Jurisprudence 12th ed London 1966 S
230. ich allerdings keine Grenzen gesetzt Dem BGB als der ma geblichen deutschen Rechtsquelle l sst sich kein klares Bild f r die Frage nach Vorgaben bzw Einschr nkungen bei der Leistungspr zision entnehmen Zun chst ist unklar welches Modell vor allem Kauf Werk oder modifiziertes Werkvertragsrecht zu Grunde zu legen ist Doch selbst wenn ein Vertragstypus gew hlt ist so finden sich keine n heren Regeln zum Umfang der Leistungsbestimmung Sowohl der Vertragszweck Herstellung des versprochenen Werkes als auch bergabe und Eigentumsverschaffung berlassen es den Vertragsparteien eine genauere Bestimmung der Pflichten vorzunehmen In deutscher Literatur und Rechtsprechung wird das Thema der Leistungspr zisierung meist unter dem Stichwort Pflichtenheft abgehandelt Einigkeit besteht dabei ber ihre Notwendigkeit Gegenstand von Gerichtsentscheidungen werden jedoch vor allem F lle in denen ein Pflichtenheft nicht erstellt wurde Manche Softwareh user setzen sich danach ber die in ihrer Branche entwickelten Standards hinweg und entwickeln Software ohne Zielpr zision Die Rechtsprechung sieht die Verantwortung f r das Erstellen des Pflichtenhefts ganz berwiegend beim Softwarebesteller Dabei darf allerdings nicht unbeachtet bleiben dass unter einem Pflichtenheft nicht in jedem Fall eine detaillierte Leistungsvorgabe verstanden wird Wenn Literatur und Rechtsprechung die vorgenannte Aufgabenzuweisung zum Softwarebestell
231. ich und ausfuhrlich dokumentiertes Modell Die Softwareentwicklung stellt darin einen Teil in dem Gesamtsystem des Entwicklungsstandards f r IT Systeme dar Auch hier wird die Komplexit t durch Zerlegung in einzelne Anschnitte und verschiedene Aufgabenbereiche reduziert Der Aufgabenbereich Softwareentwicklung auch als Submodell SWE bezeichnet ist in neun Schritte gegliedert 36 37 38 Die offizielle Beschreibung erstreckt sich ber mehrere hundert Seiten siehe den Anhang in Br hl Dr schel a a O Fn 9 Im V Modell 97 der 1997 fertiggestellten und mittlerweile in aktualisierter Form vorliegenden offiziellen Anleitung zur Durchf hrung von IT Projekten werden Projektmanagement Qualit tssicherung Konfigurationsmanagement und Softwareentwicklung als T tigkeitsbereiche unterschieden Vier Aufgabenbereiche werden unterschieden Das Produktmanagement PM das Konfigurationsmanagement KM die Qualit tssicherung QS und die eigentliche Softwareentwicklung SWE Das PM plant und steuert den Entwicklungsprozess das KM verwaltet die fertigen Zwischen Produkte Konfigurationen und Rechte bernimmt das Change Management die Datensicherung und ein Berichtswesen Br hl Dr schel a a O S 27 28 die QS legt den organisatorischen und abwicklungstechnischen Rahmen fest pr ft ob vorgegebene Methoden eingehalten werden bereitet die Produktpr fung vor und f hrt sie durch trifft die Durchf hrungsentschei
232. icher Verschaffung letztlich dasselbe Gut in den Mittelpunkt der Betrachtung stellen differenzierend wie aus dem zum BGB bekannten Streit Schlechtriem Ferrari Art 1 Rn 38 der Programme die ber einen Tr ger nutzbar sind als Waren ansieht Best nde der Auftrag des Softwarehauses in der nderung vorhandener Software so f nde die CISG nach Art 3 Abs 1 dann keine Anwendung wenn diese Software einen substantial part ausmacht Dies wird nach der berwiegenden Auffassung durch das Wertverh ltnis des von den Parteien beizutragenden Materials bestimmt Staudinger Magnus Art 3 CISG Rn 14 ebenso Soergel L deritz Fenge Art 3 Rn 3 a A Schlechtriem Ferrari der auch ein qualitatives Element ber cksichtigen will Art 3 Rn 8 125 49 49 50 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland Fur Individualsoftware hangt das Ergebnis allerdings weiter davon ab ob die Pflicht der liefernden Partei hier das Softwarehaus zum Uberwiegenden Teil preponderant part aus Arbeits oder sonstiger Dienstleistung supply of labour or other services besteht Dies wird fur Softwareentwicklungsvertrage berwiegend bejaht Damit spielt das UN Kaufrecht fur Softwareentwicklungsvertrage keine Rolle C Zusammenfassung und Ergebnis Fur die rechtlichen Rahmenbedingungen im deutschen Recht ist als erster Grundsatz festzuhalten dass geschriebenes Recht in Form der Gesetze den Ausgangspunkt rechtlicher Bewertung
233. ie Beschaffung von IT Leistungen EVB IT handelt es sich um im Bundesanzeiger ver ffentlichte Richtlinien die von den Herstellerverb nden der Softwareindustrie unter Federf hrung des Bundesministers des Inneren seit 1972 erarbeitet wurden Ihr Inhalt ist nicht unumstritten und sie werden daher vom BGH im Gegensatz etwa zu der VOB B nicht als Standard anerkannt und der AGB Kontrolle im Einzelfall unterzogen vgl BGH in CR 1991 S 273 274f 50 5 50 50 ao a 50 50 on 130 Kapitel 6 Empirischer Befund in Deutschland l Vertragsart Auch die Wahl der Vertragsbezeichnung offenbart ein breitgef chertes Spektrum der Nomenklatur wobei sich daraus teilweise Anhaltspunkte f r den systematischen Ansatz des Autors ableiten lassen KO Vertrag ber Erstellung von Software GL Softwareentwicklungsvertrag und SN S Vereinbarung zur Softwareentwicklung verwenden sehr hnliche Bezeichnungen In SN B wird dies in Andeutung einer Pflichtenerweiterung abge ndert auf Vereinbarung zur Erstellung und Installation von Software MA betitelt sein Vertragsmuster als berlassung von Individualsoftware im Unternehmerverkehr mit Quellcode berlassung Die f r ma geblich gehaltenen Einteilungskriterien sind hier also einmal Individualsoftware in Abgrenzung zur Standardsoftware im Unternehmerverkehr in Abgrenzung zu Vertr gen mit Verbrauchern sowie die berlassung des Quellcode in Abgren
234. ie Lieferung von neuen Versionen vorgesehen 6 Vertragsgegenstand Wartung Cc Updatewartung i S dieses Vertrages bedeutet die Lieferung von neuen Systemversionen Updates Releases inklusive Sourcecode wie sie standardm ig allen anderen Kunden des Auftragnehmers angeboten bzw geliefert werden f r die eingesetzten Programmmodule Updatewartung garantiert die laufende Anpassung der Anwendungssoftware an notwendige nderungen der Umgebungsbedingungen wie Hardware Systemsoftware inklusive Datenbanksysteme Steuerrecht in sterreich Deutschland Schweiz und der EU Interessant ist die ebenfalls unter 6 definierte Basiswartung Basiswartung im Sinne dieses Vertrages bedeutet a Die Unterst tzung bei der Lokalisierung von M ngeln und die Beseitigung von St rungen und M ngeln Die Beseitigung von St rungen und M ngeln erfolgt durch Zurverf gungstellung einer mangelfreien Programmversion per Datentr ger oder Daten bertragung Es wird hier erneut deutlich das die Betreuung ber den gesamten Lebenszyklus gefordert ist Die Basiswartung ist gem der Verg tungsvereinbarung in Nr 12 Abs 4 bis zum Ende der Gew hrleistungsfrist 9 Monate ab Gesamtabnahme im Fixpreis inkludiert Danach wird sie f r die folgenden 15 Monaten gegen monatliche Verg tung erbracht Die Parteien gehen also offenbar davon aus dass auch nach der End Abnahme St rungen und M ngel zu beseitigen sind und der Softwareb
235. ie Reaktion der Softwareh user wider den Besteller ausdr cklich mit in die Pflicht f r den Projekterfolg zu nehmen und die Verantwortlichkeit f r Misserfolge im Projekt auch auf den Besteller zu bertragen So finden sich beispielsweise in den Erstellungsvertr gen Bestimmungen wonach der Besteller auf Anforderung des Softwarehauses zeitgerecht Material vorzulegen hat Dies ist zum einen als Bedingung f r die Leistungspflicht des Softwarehauses gestaltet und f hrt zum anderen bei Versto zu einer Ausdehnung des dem Softwarehaus einger umten Zeitrahmens Weiterhin wird der Versuch unternommen den Rechtsbehelf bei nichtvertragsgem er Beschaffenheit auf Reparatur 228 Einem Softwarehaus wurden ca 42 Mio Schadensersatz zugesprochen weil der Staat California nderungen im Umfang von ca 1 500 000 lines of Software code in Auftrag gab den Vertrag dann k ndigte und f r die nderungsarbeiten nicht zahlen wollte State of California v Lockheed Martin IMS 2002 WL 99554 2002 Der Besteller wollte auf Basis einer m ndlichen Absprache die Bezahlung von Zusatzleistungen erzwingen Das Gericht wies dies zur ck Objectwave must show that there has been an offer an acceptance consideration and sufficient specification of terms so that the obligations involved can be ascertained Savoca Masonry Co Inc v Homes and Son Constr 112 Ariz 392 394 542 P 2d 817 819 1975 While contract terms need not be set forth in
236. ie Teilergebnisse der Quadranten gelten nur dann als erf llt wenn eine Entscheidung nach den Kriterien des jeweiligen Einzelquadranten vorliegt Die Parteien bilden einen Lenkungsausschuss dem E Anm Softwarebesteller vorsteht Teil 2 Bestimmungen f r die Entwicklungsphasen 3 Identifikationsphase Zu Beginn der Zusammenarbeit legen die Parteien ihre bisherigen T tigkeiten im Themenbereich des Vertragsgegenstandes schriftlich nieder und quittieren die gegenseitige bergabe In jedem Zyklus der Spirale werden zun chst Anforderungen Alternativen und Einschr nkungen identifiziert Ziel der von S Anm das Softwarehaus zu erbringenden Planungs und Beratungsleistungen im ersten Quadranten ist es also in enger Zusammenarbeit mit E Anm Softwarebesteller die Leistungsf higkeit Funktionalit t und nderungsf higkeit des Systems oder eines Teils davon zu bestimmen Dabei sollen Alternativen wie die Entscheidung zwischen den L sungen A oder B Wiederverwendung einer bereits vorher bestehenden eigenen Implementation oder der Kauf eines fremden Standardproduktes sowie die Barrieren f r die Wahl der Alternativen aufgestellt werden Das Ergebnis des Identifikationsquadranten bildet die Aufgabenstellung f r die weiteren Entwicklungsphasen Diese wird durch den Lenkungsausschuss gemeinschaftlich getroffen und zyklisch konkretisiert Der Schwerpunkt der Verantwortung liegt hier bei dem Softwarehaus wobei die regelm ige ge
237. ie auf fehlerhafter Analyse der Anforderungen beruhen mit Tests erst sp t entdeckt werden und daher exponentiell ansteigende Fehlerbehebungskosten zur Folge haben Ein Fehler in der Formulierung der Anforderungen ist daher deutlich teurer als ein Fehler der bei der falschen Implementation der richtigen Anforderung auftritt Aus dem bisherigen Befund wird die Schlussfolgerung gezogen dass 1 nderungen im System vorzusehen sind 2 bei grundlegenden nderungen mit einem Neubeginn des Projektes zu rechnen ist 3 notwendige nderungen m glichst fr hzeitig erkannt und ber cksichtigt werden sollten 4 nderungsverlangen des Softwarebestellers die dem Entwicklungsprozess zuwiderlaufen Widerstand entgegenzusetzen ist a Psychologie des Entwicklungsprozesses Die Rolle des Softwarebestellers bei der Erarbeitung des Pflichtenheftes sowie die relative H ufigkeit von nderungen lassen vermuten was sich in der Praxis als essentiell f r den Entwicklungsprozess erwiesen hat Kommunikation So sieht Eschbach in der Kommunikation zwischen Softwarehaus und Softwarebesteller den Schl ssel zum Projekterfolg Dies gilt nicht nur hinsichtlich der beteiligten Projektmitarbeiter aus der EDV 92 Nach einer Annahme von Barry Boehm verhalten sich die Kosten der Fehlerbehebung im Vergleich von Analyse Design Implementierung in der Gr enordnung 1 10 100 zitiert nach Biedermann Sven in Rupp a a O S 339f von Biedermann
238. iegende Untersuchung befasst sich im Schwerpunkt mit den rechtlichen Rahmenbedingungen der Entstehung von Software und geht dabei von der Praxis der Vertragsgestaltung aus Ein aus Gr nden der Begrifflichkeit hier vorwegzunehmendes Ergebnis der Untersuchung ist das Verwenden der Bezeichnung Softwareentwicklungsvertr ge Der Produktionsprozess von Software ist 1 Der urspr ngliche Arbeitstitel enthielt noch den Begriff Softwareerstellungsvertr ge ae Einleitung aus verschiedenen unten naher ausgefuhrten Grunden nicht mit dem anderer Industrieg ter zu vergleichen Ein Gesichtspunkt ist dabei die Ungewissheit der endg ltigen Form des Ergebnisses Ein bis ins Detail beschriebenes Produkt mit einer unumst lichen Vorgabe hinsichtlich Form Material Farbe etc ist in einer an vorzugebenden Trends und zu weckenden Bed rfnissen orientierten Produktionsstruktur selten Im Bereich der Produktion von Software tritt die h ufig im Laufe des Projektes sukzessive erfolgende Pr zisierung des Ergebnisses hinzu Es liegt also nicht in der Hand des produzierenden Softwarehauses Form und Gestalt zu w hlen Das Endprodukt entsteht in einem von Austausch mit dem Softwarebesteller und kontinuierlicher Pr fung gepr gten Prozess stufenweise konkretisierenden Vorgehens Der Begriff der Entwicklung ist daher treffender als der der Erstellung Ausgangsbasis bei dieser Entwicklung ist mit fortschreitender informationstechnischer D
239. iegt so stellt dies gleichwohl einen Vertragsbruch dar Selbst bei Kaufvertr gen in denen nach der perfect tender rule eine uneingeschr nkte bereinstimmung der Ware mit den vertraglichen Vereinbarungen gefordert wird wendet die Rechtsprechung allerdings regelm ig die Doktrin der sog substantial performance an 197 Full performance of a duty under a contract discharges the duty 198 Rs 2d 8 235 2 When performance of a duty under a contract is due any non performance is a breach 19 Rs 2d 8 346 1 The injured party has a right to damages for any breach by a party against whom the contract is enforceable unless the claim for damages has been suspended or discharged Rs 2d 8 346 2 If the breach caused no loss or if the amount of the loss is not proved under the rules stated in this Chapter a small sum fixed without regard to the amount of loss will be awarded as nominal damages 201 Rs 2d 235 Comment a 202 Calamari Perillo fassen dies unter dem Grundsatz de minimis non curat lex a a O S 418 So die Illustration 2 im Kommentar zu 235 Rs 2d Calamari Perillo a a O S 421 vgl auch Art 25 CISG als Teil des amerikanischen law of statutes A breach of contract committed by one of the parties is fundamental if it results in such detriment to the other party as substantially to deprive him of what he is entitled to expect under the contract unless the pa
240. ieht allenfalls die dort verwendeten Argumente zur St tzung der eigenen Argumentation heran 5 Salmond f hrt dazu aus the first virtue of legislation lies in its abrogative power It is not merely a source of new law but is equally effective in abolishing that which already exists in a strict system of binding precedent its operation is irreversible What it does it does once for all A a O S 125 Weyers AcP 182 1982 S 77 592 case law with all its imperfection has at least this merit that it remains in living contact with the reason and justice of the matter and draws from this source a flexibility and a power of growth and adaption which are to much wanting in a the litera scripta of enacted law Salmond a a O S 129 Levine Howard Hugh R Jones Lecture at Albany Law School 67 Alb L Rev S 1 21 The process of judging have described of course is not perfect Mistakes will be made The social realities may be wrongly perceived Unforeseen embarrassing consequences may occur But the commitment to incremental development of the law to waiting for just the right moment when a broader rule may be articulated and justified as underlying prior rulings also believe best enables correcting or at least limiting the damage of mistakes Jones a a O S 25 Law always reflects a community s values and American contract law reflects the continuing conflict in our society between individual
241. iengsch fte Real property und in der neueren Rechtsprechung Dienstvertr ge Service contracts S 614 mit Sportlern und K nstlern S 618 13 S 13 14 14 oO N Ezgi Kapitel 3 Rechtliche Rahmenbedingungen in den USA geh ren typischerweise nicht dazu Erst wenn die geschuldete Leistung wegen ihrer Einzigartigkeit nicht durch Erf llung von anderer Seite erbracht werden kann besteht Aussicht auf Erzwingung im Wege gerichtlicher Entscheidung Bei der Durchsetzung von Schiedsspr chen welche specific performance zum Gegenstand haben kommt es auf die Eigenart des Vertrages jedoch nicht an Die Bestimmtheit der vertraglichen Vereinbarung zumindest in Form einer reasonable certainty ist Voraussetzung f r specific performance Als im Rahmen der Courts of Equity entwickeltes Rechtsinstitut baut specific performance auf dem Grundstein der unconscionability auf Da die Anwendung und Auswirkung der unconscionability in hohem Ma e von den besonderen Umst nden des Einzelfalles abh ngt ergeben sich weite Ermessensspielr ume f r die zur Entscheidung berufenen Gerichte Bemerkenswert ist schlie lich die Feststellung specific performance sei generell inkonsistent mit dem Zusprechen von Schadensersatz Im Ergebnis wird ein Erf llungsanspruch im amerikanischen Recht nur unter engen Voraussetzungen gew hrt Einen Teil dieser Voraussetzungen k nnen die Vertragspartner im Wege pr ziser Beschreibung
242. iese k nnen f r eine Erkl rung und Erg nzung der Parteivereinbarung herangezogen werden Sind f r die Erf llung Spezifikationen der Leistung durch eine Partei erforderlich so sind diese in good faith and within limits set by commercial reasonableness zu erbringen Werden Mitwirkungshandlungen der einen Partei nicht oder nicht rechtzeitig erbracht so wird die andere Partei hinsichtlich der daraus folgenden Verz gerungen der eigenen Leistung von nachteiligen Rechtsfolgen befreit und kann entweder mit der eigenen Erf llung fortfahren oder die unterbliebene Mitwirkung als Vertragsbruch behandeln Dar ber hinaus dienen insbesondere die Regelungen hinsichtlich der Einstandspflichten des Verk ufers sowohl infolge ausdr cklichen express warranties 2 313 als auch infolge konkludenten Verhaltens implied warranties 88 2 314 bis 2 315 der Kl rung der Gesichtspunkte unter denen Leistungspflichten konkretisiert werden k nnen 2 316 U C C r umt dabei ein weitgehendes Recht zur Abbedingung von konkludenten Einstandspflichten ein die sich zudem auch aus der Vertragsdurchf hrung der Gestaltung der Vertragsbeziehungen sowie den Handelsbr uchen ergeben kann 2 316 c Wenn und soweit warranties nicht ausgeschlossen sind zeigt sich hier ein bedeutender Unterschied zur Rechtslage bei Nichtanwendbarkeit des U C C In diesem Fall ist der Ma stab f r die Erf llung due care was jedenfalls nicht gleichbede
243. igned by Vendor to work on the System Shall be pre approved by User and shall have necessary technical and application skills and experience and education and shall be full time employees of Vendor Vendor shall replace any personnel User finds to be unfit or unsatisfactory for any reason In den Softwarebesteller orientierten Mustern DaS U und RB U trifft man schlie lich auf sog Most Favored Customer Klauseln Sie verpflichten das Softwarehaus f r das Projekt vorgesehenes Personal bis zum Projektende nicht anderweitig einzusetzen Dies wird bei RB U so formuliert 71 Kapitel 4 Empirischer Befund in den USA 6 2 Most Favored Customer For the complete period covered by this Agreement Licensor agrees to treat Licensee as its most favored customer In accepting such treatment Licensor agrees not to reassign any staff assigned to Licensee s projects to other projects until such time the Licensee projects are satisfactorily completed Daruber hinaus muss das Softwarehaus dem Softwarebesteller seine Leistungen zu den g nstigsten Konditionen anbieten Licensor resents that all of the prices terms warranties and benefits granted by Licensor hereunder are comparable to or better than the equivalent terms being offered by it to any present customer of Licensor If during the term of this Agreement Licensor shall enter into arrangements with any other customer providing such customer more favorable terms this Agreement shall thereu
244. ihrer Seite hat Dies k nnte in der rechtlichen Diskussion einen Ansporn zur Kontroverse bilden doch handelt es sich bei dem F rsprecher um das h chste deutsche Gericht Der von diesem eingeschlagene Weg auch wenn er nicht auf sorgf ltiger begr ndeter Entscheidung beruht wird vielfach von der Zivilgerichtsbarkeit nachvollzogen Allein dies verleiht ihm einiges an faktischem Gewicht Es ndert jedoch nichts an der Fehleinsch tzung Der gerichtlichen Praxis kann zugute gehalten werden dass sie eine Entscheidung treffen muss und dabei verst ndlicherweise auf vertraute Konzepte zur ckgreifen m chte Dieser pragmatische Ansatz kommt auch sehr gut in einem amerikanischen Urteil zum Ausdruck Vertragsschlie ende k nnten danach berechtigterweise davon ausgehen zumindest ein Gesetz sei anwendbar Es war dabei allerdings mit einer Entscheidung anderer Tragweite als die deutschen Gerichte sie zu gew hren h tten konfrontiert Die Anwendbarkeit des U C C insgesamt hing von der Einordnung der Software als good ab Bei einer Entscheidung gegen die Sacheigenschaft h tte das Gericht also ohne Gesetz dagestanden Einem deutschen Gericht w re dann immer noch die M glichkeit gegeben auf Vertragstypen auszuweichen die eine 51 Der m gliche Einwand es handle sich um ein Programm und nicht um Software soweit man dieser Unterscheidung berhaupt folgt greift nicht Wenn das Programm in eine computerlesbare Sprache bersetzt und an
245. ilien Die Sacheigenschaft von Software i S des Art 1 CISG ist nicht so umstritten wie bez glich des BGB und die h M wendet das UN Kaufrecht auf Standard Software an Bei den hier untersuchten Softwareentwicklungsvertr gen ist weiter davon auszugehen dass der Besteller zwar intensiv mitarbeitet bzw dazu verpflichtet w re er jedoch kein Vorprodukt wie etwa eine vorhandene Software zur Verf gung stellt Nach Art 3 Abs 1 CISG w re danach eine Anwendbarkeit gegeben 7 Zu den offiziellen Gesetzessprachen geh ren gleichrangig Arabisch Chinesisch Englisch Franz sisch Russisch und Spanisch nicht jedoch die deutsche bersetzung die daher lediglich eine unverbindliche Anwendungshilfe darstellt Ferrari in Schlechtriem Peter Hrsg Kommentar zum einheitlichen UN Kaufrecht 3 Aufl M nchen 2000 Vor Artt 1 6 Rn 26f Staudinger Magnus Art 1 Rn 42 Schlechtriem Ferrari Art 1 Rn 34 Soergel L deritz Fenge Art 1 Rn 21 Staudinger Magnus Art 1 Rn 44 m w Nachw Soergel L deritz Fenge Art 1 Rn 21 der sich auf die textliche Erweiterung des Art 1 CISG gegen ber dem EKG Das Einheitliche Gesetz ber den internationalen Kauf beweglicher Sachen als Vorl ufer der CISG sprach von objets mobilier corporels bezieht Endler Maximilian Daub Jan Internationale Software berlassung und UN Kaufrecht CR 1993 S 601 603f die eine weite Auslegung des Warenbegriffes fordern und auch bei unk rperl
246. in einer Definition des Produktes da viele Misserfolge ihre Ursache in den Punkten haben die nie richtig spezifiziert worden waren Das Ma an Umsicht und Sorgfalt beim Erfassen der Anforderungen des Softwarebestellers erweist sich somit als zentrale Grundlage f r den Projekterfolg F r das Ergebnis einzelner Projektabschnitte ist die Folge nachl ssig formulierter Ziele anschaulich bei Brooks formuliert Der schwammig formulierte Meilenstein ist eine B rde an der man schwer zu tragen hat Er ist im wahrsten Sinne des Wortes ein Muhlstein der langsam die Moral des Teams zermalmt weil er es uber eventuelle Verz gerungen im Unklaren l sst bis nichts mehr zu retten ist 4 Nach Zehnder ist aus Gr nden der Komplexit t normalerweise ein mathematischer Beweis fur die Richtigkeit des Gesamtsystems nicht m glich a a 0 S 119 Ebenso Eschbach der den vollst ndigen Test komplexer Software f r unm glich h lt a a O S 208 115 Nach Maymon Cave stellt sich h ufig im Verlauf der Abschlusstests heraus dass die Software nicht in dem Ma e wie angenommen fertig war a a O S 21 Software stirbt nicht Sie w chst st ndig S 7 ebenso Etzel Heilmann Richter a a O S 75 83 Eschbach f hrt dazu aus Wenn die Programmierer das Gef hl haben das Programm sei zu 90 fertig dann ist Halbzeit a a O S 152 Bei Barry Boehm zitiert nach Thaller a a O S 26 sind unvollst ndige Anf
247. inder Greise Frauen M nner gleich welcher Hautfarbe Herkunft und sonstiger Daseinsumst nde zu nat rlichen Personen Blumen B ume H user Autos und Computer werden zu Sachen Sprache Geste mitunter auch Schweigen wird zur Willenserkl rung Geben und Nehmen zum Rechtsgesch ft Die Arbeit eines Schreiners Automechanikers einer Floristin oder Malerin eines Computertechnikers oder einer Programmiererin wird zum Werkvertrag 215 Kapitel 8 Schlussfolgerungen Die Abstraktion findet dabei bekannterma en im deutschen Recht dergestalt in Stufen statt dass einem spezielleren Teil ein allgemeiner vorangestellt wird Daraus ergibt sich f r die Frage nach den geeigneten Rechtsregeln die M glichkeit eine L sung auf der allgemeineren Ebene dem allgemeinen Schuldrecht oder der Ebene des besonderen Schuldrechts zu suchen Es ist weder erforderlich noch sinnvoll als einzige M glichkeit eine Zuordnung zu einem vorhandenen Typ des besonderen Schuldrechts zu sehen Ein vergleichender Blick zum amerikanischen Recht erweist sich auch hier als hilfreich Es gelingt den US Gerichten durchaus auch bei Nichtanwendbarkeit des U C C zu einer L sung zu gelangen Selbst dort wo er angewandt wird finden die Gerichte keine dem Werkvertrag vergleichbare Regelung vor was sie wiederum nicht darin hindert sachgerechte Entscheidungen zu treffen Es w re dabei sicher voreilig den Grund hierf r in der
248. ion dass die K ufer ihre Rechte de facto nicht verlieren k nnen da es an einer Abnahme fehlt sie w ren also ungerechtfertigt besser gestellt als Besteller nach Werkvertragsrecht Thewalt a a O S 82 Was etwa dazu f hren k nnte dass die Ablieferung ohne geschuldetes Handbuch oder Bedienungsanleitung die R gepflicht des Softwarebestellers in Gang setzt und er sie u U nach vers umter Anzeige nicht nachfordern kann vgl M Ko HGB Grunewald 377 Rn 24 42 A 42 a 115 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland Vertragsschluss bereits vor diesem geschaffen Der Kaufer trifft seine Wahl aufgrund existenter oder hinreichend konkret bekannter Eigenschaften des Werkes Beim Werkvertrag betrifft die Entscheidung dagegen lediglich eine Planung im Hinblick auf ein m glicherweise vage beschriebenes Werk Im Ergebnis bestehen erhebliche Unterschiede f r die Vertragspartner je nachdem ob eine Einordnung nach den 651 433ff oder 631ff BGB erfolgt 4 In sonstigen Konstellationen Lizenzvertrag 88 705ff F amp E Vertrag dynamischer Vertrag Geht man von einem Lizenzvertrag aus so soll die Summe aller jener Regeln Anwendung finden die sich aus den allgemeinen Bestimmungen des Schuldrechts auch mit Bezug auf den Lizenzvertrag ergeben oder aber durch die Rechtsprechung ermittelt werden Soweit nicht allgemeine Regeln greifen sei nach passenden das Wesen des Lizenzvertrages reflektier
249. ionsbedingten Vorgaben m glichst weitgehend Rechnung zu tragen Der Anwender definiert durch seine Vorgaben die Entwicklung einer speziell auf seine Bed rfnisse ausgerichteten Software Standardsoftware ist demgegen ber die programmtechnische L sung einer abstrakten Aufgabe z B die Funktion einer Schreibmaschine durch Textverarbeitung zu ersetzen deren Programmlogik und Verarbeitungsvorg nge fest vorgegeben sind Sie wird nicht f r einen einzelnen Auftraggeber sondern f r einen vermuteten oder tats chlichen Marktbedarf geschaffen Zentrale Aufgaben wie z B im Bereich der B roanwendungen das Verfassen und Bearbeiten von Texten Textverarbeitung das Durchf hren von Berechnungen Tabellenkalkulation das Speichern Abrufen Manipulieren vordefinierter Datens tze Datenbanken beruhen auf einem einheitlichen Schema welches in der Praxis ohne weiteres f r viele Anwendungsfalle eingesetzt werden kann Standardsoftware findet sich berall dort wo eine Vielzahl von Anwendungsbereichen und damit potentieller Kunden die aufwendige Entwicklung von Software rechtfertigt Die richtige Einsch tzung eines entsprechenden Bedarfs hat zum Entstehen weltweit agierender Konzerne und ganzer Industriezweige gef hrt Ob eine Aufgabenstellung im konkreten Fall durch Standard oder Individualsoftware gel st wird h ngt weitgehend von der Wahl und den Ressourcen v a dem Budget des zuk nftigen Anwenders ab Programme von der Verei
250. ire 31 03 93 42 Kapitel 3 Rechtliche Rahmenbedingungen in den USA Anwendungsbereich des U C C sei gro z gig auszulegen um die ihm zugrunde liegenden Ideen zu fordern Daf r spr che zudem dass eine Vereinfachung und Einheitlichkeit der Rechtsanwendung nur auf diese Weise erreicht werde F r die Einordnung von Software als service wird im Gegensatz zu dem Vorstehenden vorgebracht beim Erwerb von Software stehe das Wissen und die F higkeiten des Programmierers im Vordergrund Diese und nicht die Gegenst nde mit deren Hilfe Wissen und F higkeiten in den Computer bertragen werden seien die Essenz eines Softwareerwerbs Es handele sich also um einen contract to do bzw einen contract for work labour and materials and not a sale Der Charakter von Software als eine klassische Form geistigen Eigentums werde nicht dadurch beeintr chtigt dass sie aus einer physischen Komponente und einer immateriellen nicht ber hrbaren Komponente bestehe 3 Anwendbarkeit auf Softwareentwicklung Bei Softwareentwicklungsvertr gen liegt bei Vertragsabschluss wie bei Liefervertr gen ber vorher nicht existierende Sachen noch keine fertige 171 Software vor Die Mehrzahl der amerikanischen Gerichte und der 165 Communications Groups Inc Also Known as CGI Plaintiff v Warner Communications Inc 527 N Y S 2d 341 Systems Design and Management Information Inc SDMI v Kansas Cit
251. ischen den Parteien Dabei ist es die jeweilige besondere Situation der Parteien die im Vertrag zu ber cksichtigen ist Einzelfallgerechtigkeit wird durch Anpassung des Vertrages an die besonderen Umst nde gew hrleistet Soweit also insbesondere nach den Erkenntnissen aus dem zweiten Kapitel nderungen ein bedeutender Bestandteil von Softwareentwicklungsvertr gen sind sollten f r den Fall ihres Auftretens 570 Merryman The Civil Law Tradition a a O S 71 the legal order frequently sacrifies the justice of the individual case to the demands of certainty in the law 571 Weshalb der deutsche Gesetzgeber in diesem Fall beispielsweise grunds tzlich keine Kontrolle nach den 88 305c ff BGB vorsieht Vorrang der Individualabrede 305cBGB 218 Kapitel 8 Schlussfolgerungen auch umfassende Regelungen vorgesehen werden Dies ist kein Tribut an das Verdikt der Rechtssicherheit sondern eine Reaktion der Vertragspraxis auf die faktischen Gegebenheiten mithin eine erfahrungs und keine begriffsorientierte Vorgehensweise Es bleibt das Bem hen um einen allgemeinen Ma stab f r Anforderungen an die Technik als Ausweis einer im deutschen Rechtssystem verhafteten Denkweise Diese nur in den deutschen Mustern zu findende Eigenheit mag einem Denken in Begriffssystemen geschuldet sein Die Absicht informationstechnischen Gegebenheiten Rechnung zu tragen ist erkennbar bleibt jedoch im Detail zu ungenau und vermag da
252. ise gering ist ein Gro teil der Spezifikationsarbeit also noch vor den Parteien liegt Es finden sich durchgehend mehrstufige Verfahren zur Bestimmung des Vertragsinhaltes Sie werden durch eine Anforderungsformulierung eingeleitet der sich die Erstellung eines pr zisen Anforderungsprofils anschlie t und die schlie lich in die Implementation d h programmtechnische Umsetzung m ndet Dabei sind auch technische Details bereits im Hauptvertrag vorhanden Die Erstellung der Spezifikation auf diesem Wege wird teilweise f r die Zukunft vorgesehen In zwei Praxisbeispielen wird die Spezifikation ebenfalls sukzessive im Projektverlauf vorgenommen im dritten ist sie fest vorgegeben Die Erstellung technischer Spezifikationen wird in den Mustern ganz berwiegend als Sache des Softwarehauses angesehen in zwei Praxisbeispielen wird sie als gemeinsame Aufgabe der Vertragsparteien betrachtet in einem wurde sie vom Softwarehaus erstellt und vom Softwarebesteller gepr ft Im Ergebnis wird die Erarbeitung detaillierter Anforderungen als Ziel vorgegeben was durch die Vorgehensweise in einem abgestuften Verfahren 196 Kapitel 7 Vergleichende Darstellung erreicht werden soll Die Verantwortlichkeit ist dabei in einigen Mustern nicht eindeutig zugewiesen eine Tendenz die auch in zwei Praxisbeispielen bestatigt wird und das Element der gemeinsamen Entwicklung betont Aus informationstechnischer Sicht wird dem Erfordernis nach Zielprazision w
253. iss K ln 1997 S 192ff Braun Bernd berlassung von Computerprogrammen an den Anwender als Werkvertrag BB 1992 S 154 Marly a a O der seine Monographie danach gliedert Auch Marly erkennt diese Variante als in der Praxis wenig verbreiteten Fall a a O Rn 44 S 21 Fn 105 Hoeren a a O S 28 m w Nachw Schneider Handbuch des EDV Rechts S 1474 Malzer a a O S 289 der daneben darauf abstellt dass bei der Softwareentwicklung eine Wertsch pfung f r den Auftraggeber stattf nde Schneider Handbuch des EDV Rechts S 1467 der weiter danach differenziert wer bei der Projektsteuerung die Verantwortung S 1470ff bzw insgesamt die Projektverantwortung tr gt Schneider CR 2003 S 317 Karger Michael Kooperation bei komplexer Softwareentwicklung ITRB 2004 S 208 Diedrich spricht davon dass mangels pr fbaren Leistungsgegenstandes Regelungen ber die Risikoverteilung auf dem Weg zur Leistungserbringung erforderlich werden die den Werkvertrag in den Vordergrund r cken CR 2002 S 473 hnlich formuliert Kottof dass Softwareentwicklungsvertr ge f r eine angemessene Allokation der Projektrisiken zu sorgen h tten was eindeutig zu einem Werklieferungsvertrag f hre K amp R 2002 S 105 K hler Rechtsfragen zum Softwarevertrag CR 1987 S 827 Diedrich CR 2002 S 473 M ller Hengstenberg CR 2004 S 161 Schweinoch Roas CR 2004 S 326 381 Sobola Dobmeier Gl ckler a a O S 23
254. isse entgegenstellt Eine projektorientierte Vertragsgestaltung ist aus diesem Blickwinkel unzweifelhaft vorzugsw rdig 227 Kapitel 8 Schlussfolgerungen B Ergebnis Die Einordnung eines deutschen und eines amerikanischen Softwareentwicklungsvertrages in das System der Rechtsordnungen ist nicht gefestigt Im Gegenteil Die deutsche Schuldrechtsreform hat in Fachkreisen zu einer erheblichen Verunsicherung beigetragen Im amerikanischen und deutschen Recht ist nicht vorhersehbar ob bzw welche Normen vor Gericht angewendet bzw bei der Vertragsgestaltung als Referenz betrachtet werden m ssen Die Leistungsbestimmung kann dabei auf deutscher Seite ma geblich von der Einordnung gepr gt sein insbesondere wenn die au erhalb der Hauptstr mungen diskutierten Modelle Lizenzvertrag Gesellschaftsvertrag Dienstvertrag wiederbelebt werden Auch in den USA bt die Nicht Anwendbarkeit des U C C z B hinsichtlich der Einstandspflicht erheblichen Einfluss auf die Entscheidungsfindung aus Im Ergebnis kann in beiden Rechtsordnungen bzgl der Beurteilung von Softwareentwicklungsvertr gen von Rechtssicherheit keine Rede sein Rechtssicherheit im Sinne von Vorhersehbarkeit der rechtlichen Folgen des Handelns repr sentiert ein tragendes Prinzip des deutschen und des amerikanischen Rechts W hrend sich das Common Law dabei im Vertragsrecht in erster Linie auf ein system of jurisprudence founded on the immutable principles of just
255. isvereinbarung Die BVB 7 lassen die Verg tungsfrage ebenso wie GL Nr 13 der allerdings verschiedene ausf hrliche Optionen f r eine Festpreisvereinbarung oder eine aufwandsabh ngige Verg tung anbietet offen B Beispiele aus der Praxis Im Folgenden werden drei Vertr ge untersucht die anl sslich tats chlich durchgef hrter Softwareentwicklungsprojekte geschlossen wurden An den ersten beiden waren jeweils ein Softwarehaus aus Mittelhessen und einmal ein Produktionsbetrieb in sterreich nachfolgende MiO und zum anderen 522 Hier findet sich eine ausgefeilte Regelung die durch eine Bonus Malus System 19 erg nzt wird und zu einer Verg tungsspanne zwischen 88 und 144 des urspr nglichen Preises f hrt Wobei dem Prinzip des Lizenzvertrages folgend je nach Lizenzmodell f r die Verg tungsregelung mehrere Varianten mit teilweise fortlaufend zahlbarer Lizenzgeb hr vorgeschlagen werden Dem Verfasser liegen alle Vertr ge die ihm im Rahmen seiner T tigkeit als Rechtsanwalt zug nglich wurden im vollst ndigen Wortlaut vor Aus Verschwiegenheitsgr nden sind die Parteien und Produkte hier anonymisiert Anders als in den USA ist es in Deutschland ungleich schwerer empirisches Material zu erhalten Die Vertr ge wurden soweit erforderlich der neuen Rechtschreibung angepasst Dieser Vertrag wurde 1995 abgeschlossen Das Projekt wurde nach etwa 5 Jahren und nach berwindung erheblicher Projektst rungen eins
256. itigung des Fehlers Soweit nicht ein Fehler der Leistung des AN vorliegt sondern beispielsweise ein Bedienungsproblem oder ein Problem der Softwareumgebung erh lt der AN hierf r eine Verg tung nach der Kalkulation 3 F r die Fehlerbeseitigung gilt a Bei einem Fehler der Klasse 1 21 beginnt der AN sofort und mit allem Nachdruck mit den Ma nahmen um zumindest das Problem in eine niedrigere Fehlerklasse zu verschieben und setzt die T tigkeit auch ber die normale Arbeitszeit werktags 8 00 bis 17 00 Uhr mit aller zumutbaren Anstrengung fort Sp testens nach drei vollen Werktagen darf kein Fehler der Klasse 1 mehr vorliegen b Bei Fehlern der Klasse 2 beginnt der AN bei Fehlerkenntnis werktags bis 12 00 Uhr noch am selben Tag bei sp terer Fehlerkenntnis am n chsten Werktag vormittags mit der Fehlerbeseitigung und setzt sie solange fort bis kein Fehler der Klasse 2 mehr vorliegt Der AG kann eine Intensit t wie bei Fehlern der Klasse 1 verlangen gegen Zahlung von Verg tungszuschl gen f r die Leistung au erhalb der blichen Arbeitszeit c Fehler der Klasse 3 werden nach Zweckm igkeit und im Rahmen eines korrekten Konfigurationsmanagements alsbald oder sp ter beseitigt Es gilt die Fehlereinstufung nach 21 Die Fehlerbeseitigung ist abzunehmen z B durch ein Protokoll nach 13 Abs 2 Anm oben S 147 wiedergegeben 4 Bei fremder Hard oder Software kann der AN nur die Dienste des jeweiligen Lieferanten zur
257. iziellen Kommentars f r die Auslegung des U C C kann mit den Worten von Macneil Gudel a a O S 95 vor Augen gef hrt werden Thus while not a part of the statute the Official Comments are extremely authoritative in interpreting the U C C 152 Corbin a a O S 79ff 40 Kapitel 3 Rechtliche Rahmenbedingungen in den USA Einschr nkend ist allerdings darauf hinzuweisen dass der U C C in seiner ursprunglichen d h vom Permanent Editional Board herausgegebenen Form praktisch nicht existiert Viele Einzelstaaten haben den Einheitstext an verschiedenen Punkten geandert Zudem sieht der Einheitstext verschiedene optionale Regelungen vor von denen zahlreiche Staaten ebenfalls Gebrauch gemacht haben Dieser theoretische Befund darf jedoch nicht dar ber hinwegt uschen dass neben anderen integrierenden Faktoren nicht zuletzt durch national d h f r den Bereich der gesamten Vereinigten Staaten von Amerika ausgepr gte Ausbildung Forschung und Pr fung in weiten Gebieten durchaus ein bundeseinheitliches Vertragsrecht gelehrt gelernt gepr ft und damit praktiziert wird Der U C C besteht in seiner aktuellen Fassung aus 9 Teilen Articles von denen vor allem der zweite Sales hier von Interesse ist Art 2 U C C ist nur auf Kaufvertr ge Sales Art 2 anwendbar Es fragt sich daher zun chst ob Software unter den Anwendungsbereich des U C C f llt 2 Anwendbarkeit des U C C auf Software Artikel 2 des U C C is
258. klarzustellen wie das von ihm gew nschte Werk auszusehen hat also dessen Eigenschaften Beschaffenheiten und Einsatzzwecke festzulegen und bekannt zu geben Als Konkretisierung der Aufgabenstellung und des Erwartungshorizonts sei die Erstellung des Anforderungsprofils origin re Pflicht des Auftraggebers Diese Aufgabenverteilung wird auch umgekehrt von Autoren aus dem Bereich des Baurechts f r das Werkvertragsrecht betont Die Planung falle grunds tzlich in den Aufgabenbereich des Auftraggebers Auch Thewalt sieht die Verantwortung zur Erstellung des Pflichtenhefts beim Auftraggeber und will bei Vorliegen eines Handelsgeschaftes aus 375 HGB sogar eine Pflicht 49 Bereits Malzer h lt bei der vorgelagerten Erarbeitung eines Anforderungsprofiles eine gesonderte rechtliche Beurteilung d h nicht nach 631ff BGB f r m glich a a O S 266f dies gelte insbesondere dann wenn eine gesonderte Verg tung verlangt ist oder der Entwicklungsauftrag erkennbar noch nicht erteilt werden soll S 277 50 Von Slongo als erfolgsgerichtete T tigkeit im Interesse des Bestellers bezeichnet bei der das Softwarehaus f r kein bestimmtes Arbeitsresultat einzustehen habe a a O S 115 451 Redeker empfiehlt das Erarbeiten eines Pflichtenhefts und die Erstellung selbst wie in den Leistungsphasen der HOAI sorgf ltig zu trennen IT Recht a a O S 306 452 Schneider Handbuch a a O S 1489 453 Schaub CR 1993 S
259. ktionsf hige Erstellung eines auf die konkreten Bed rfnisse des AG zugeschnittenen EDV Systems als Produktions und H ndler L sung Der Auftrag umfasst Software Installation Einweisung Schulung und Wartung Geschuldet wird ein in sich geschlossenes System bei dem Software Anpassungs programmierung Einrichtungsarbeiten sowie Dienstleistungskomponenten aufeinander abgestimmt sind und den vertraglichen Anforderungen des AG die dem AN im Pflichtenheft dargestellt sind Rechnung tragen Das System wird gem beigef gtem Angebot realisiert Ma geblich f r den Vertragsinhalt sind in jedem Fall die Anforderungen gem Pflichtenheft Das Pflichtenheft formuliert die Gesch ftsprozesse und funktionalen Anforderungen des AG die es mit der Software abzubilden gilt Der Vertrag wird in mehreren Phasen nach den im Terminplan genannten Meilensteinen realisiert Zahlungen f r termingerecht erbrachte und abgenommene Leistungen k nnen auch bei vorzeitigem Vertragsende nicht zur ckverlangt werden 1 2 Die Anforderungen des AG wurden im Vorfeld durch ein Pflichtenheft formuliert Zu diesem Pflichtenheft wurde seitens des AN ein Abweichungsbericht erstellt Im Abweichungsbericht nicht erw hnte Punkte des Pflichtenheftes werden als erf llbar betrachtet Aufbauend auf diesem Abweichungsbericht ist vom AG zu den einzelnen Punkten die terminliche Priorisierung eingetragen Anforderungen die nicht Bestandteil dieses Vertrages sind sind dort explizit
260. l amendment to this Agreement adjusting fees and completion dates to the extent set forth in the Change Order RB U unterscheidet zwischen kleineren minor Modifikationen und nderungen nach Annahme der Spezifikationen und vor der ersten Teil Abnahme Kleine nderungen m ssen dokumentiert werden bed rfen der Zustimmung des Softwarebestellers und d rfen keine Auswirkungen auf den Preis haben RB U geht ebenfalls davon aus dass ein nderungsverlangen durch den Softwarebesteller initiiert wird Das Softwarehaus hat innerhalb von 20 Tagen zu Kosten und Terminfolgen Stellung zu nehmen Das nderungsverlangen erlangt Wirksamkeit wenn der Softwarebesteller es innerhalb von weiteren 20 Tagen best tigt 4 13 Changes After Detailed Design A Licensor in developing the Software System may make minor modifications to the Software System and Detailed Design Specifications if such minor modifications do not limit diminish or affect the functional operation or use of the System or the output or result in the System failing to comply with the volume and response time criteria contained in this agreement All such changes shall be documented in writing a copy of which shall be submitted to Licensee for prior approval There shall be no 763 Kapitel 4 Empirischer Befund in den USA change in the prices set forth in this Agreement as a result of such minor specifications B After acceptance of the detailed Design Specificatio
261. langen eine umfangreichere Pr fung erforderlich wird der Auftragnehmer dies und die mit der Pr fung ggf verbundenen Kosten ebenfalls kurzfristig mitteilen Bei der Antwort wird der Auftragnehmer die Auswirkungen des nderungswunsches auf Termine und die vollst ndigen Kosten f r das Durchf hren der nderung mitteilen Bei MiN lautet die entsprechende Formulierung 7 3 Der Projektleiter des AG ist f r die Koordination und berwachung aller nderungs und Erweiterungs oder K rzungsw nsche bzgl der im Pflichtenheft und oder dem Abweichungsbericht niedergelegten Vereinbarungen Change Management verantwortlich Der AN wird Anfragen aus dem Change Management des AG kurzfristig beantworten Macht ein nderungsverlangen eine umfangreichere Pr fung erforderlich wird der AN dies und die mit der Pr fung ggf verbundenen Kosten ebenfalls kurzfristig mitteilen Bei der Antwort wird der AN die Auswirkungen des nderungswunsches auf Kosten und ggf auf Termine ber cksichtigen Dies wird bei MiN unter den Bestimmungen zur Wartung 13 Wartung erg nzt 13 4 Updates und Upgrades Gegenstand des Wartungsvertrages ist ferner die kostenlose Lieferung neuer verbesserter und erweiterter Programmversionen Updates und Upgrades der Software Dabei stellt der AN sicher dass die vorhandenen Daten bernommen werden und auch die individuell angepassten Programme mit den neuen Versionen zusammenarbeiten Ggf sind im Rahmen des Wartung
262. ldrechtsreform bemerkbar Er wird f r Softwareentwicklungsvertr ge auch sehr deutlich bei der Frage nach der Einordnung in das besondere Schuldrecht sp rbar Die rechtliche Entscheidung scheint hier sehr in einem System von Begriffen wie denen der Sache oder des Werkvertrages gefangen Zwar stellt sich auch im amerikanischen Recht z B die Frage nach der Sacheigenschaft von Software doch wird sie weitaus weniger problematisiert und spielt in der Rechtsprechung eine untergeordnete Rolle Pointiert formuliert k nnte man insbesondere aus der anhaltenden Diskussion in der Fachliteratur den Eindruck gewinnen der deutsche Jurist verbringe betr chtliche Zeit damit die richtige Schublade zu suchen er sei mit der Etikettierung der B ume so besch ftigt dass er den Blick f r das Ganze den Wald verliere Dieser Schein tr gt Es mag im Einzelfall zutreffen dass der Aufwand f r die Suche nach dem richtigen Gewand unverh ltnism ig hoch ausf llt Er ist jedoch berwiegend von dem Wunsch nach einem angemessenen Ergebnis gepr gt Der Blick ber den Zaun im Fall der vorliegenden Untersuchung 214 Kapitel 8 Schlussfolgerungen ber den Atlantik f hrt jedoch vor Augen wie begrenzt eine in der Dogmatik verhaftete Betrachtungsweise bleibt Sie dreht sich im Kreise der selbstgeschaffenen Begriffe und Systeme und es f llt ihr daher besonders schwer Ver nderungen zur Kenntnis und in ihre Denkweise aufzunehmen Es ist
263. lementation or modification requires additional work beyond that originally stated in the approved Design Document Vendor shall so inform User and promptly provide User with a price for the additional work on a time and materials basis The time rates shall be the then current published standard rates charged by Vendor to similarly situated customers less twenty percent 20 The additional work shall not be performed unless the specific work and the price of it are first authorized in writing by a duly authorized officer of User Woraus sich nderungen genau ergeben k nnen ist im Muster nicht geregelt Ein Ablehnungsrecht des Softwarehauses hinsichtlich der Durchf hrung auch umfangreicher nderungen ist nicht vorgesehen AS setzt voraus dass der nderungswunsch vom Softwarebesteller ausgeht Die Anfrage ist vom Softwarehaus innerhalb einer Frist von 10 Tagen auf Kosten Auswirkungen auf den Terminplan und Ressourcenverf gbarkeit zur Ausf hrung zu pr fen Die Durchf hrung der nderung kann auch abgelehnt werden Nimmt das Softwarehaus an wird der Vertrag auf Grundlage einer nderungsvereinbarung fortgeschrieben Sowohl f r die nderungsanfrage als auch f r die nderungsvereinbarung sind bei AS Muster als Anlagen vorgesehen 5 1 1 Change Order Request Client will submit to Developer by means of a written order all requests for additional services that alter amend enhance add to or delete from the Development Services t
264. len Muster machen deutlich welcher Wert darauf gelegt wird Missverst ndnisse hinsichtlich der Leistungsbestimmung zu vermeiden IV Besondere Pflichten des Softwarehauses In vier Mustern werden dem Softwarehaus zus tzliche ausdr ckliche Pflichten bei der Durchf hrung des Vertrages auferlegt FL fordert vom Softwarehaus die Bereitstellung ausreichender Ressourcen 1 2 Development Budget and Timetable Developer shall commit and utilize sufficient resources to meet the milestones and to complete development ofthe Subject Programs within the development timetable set forth in Exhibit B omitted and within the development budget set forth in Exhibit C omitted Developer shall notify Customer of any circumstances when and as they arise that may reasonably be anticipated to lead to a material deviation from the development timetable and development milestones set forth in Exhibit B Developer shall devote sufficient time and effort and shall allocate sufficient personnel resources to the Subject Programs as may be required for development and testing Neben dieser allgemeinen Beschreibung wird hinsichtlich der Projektleitung Konkretes gefordert 1 5 Designation of Supervisor Developer shall designate an employee who shall be assigned by Developer to supervise the development of the Subject Programs The employee shall devote substantially all of his or her business time to that endeavor Bei AS wird das Softwarehaus zu monatlicher Be
265. lich Zuleitungen M bel etc F r die zeitgerechte Ausstattung die allerdings nicht die Hardware umfasst ist der Softwarebesteller verantwortlich CUSTOMER RESPONSIBILITIES Customer shall be responsible for timely site preparation including but not limited to the provision of adequate electrical power and sufficient number and type of electrical outlets dust and smoke control provisions adequate furniture and sufficient work space for Vendor s personnel to perform installation Customer shall be responsible for equipment cabling except as specifically set forth herein to be provided by Vendor Daruber hinaus treffen den Softwarebesteller Sorgfaltspflichten beim Umgang mit der Software Customer hereby agrees that at all times prior to making payment in full to Vendor Customer shall i Keep the System free from all liens and encumbrances ii Not use or permit the System or any item element or component thereof to be used in any careless reckless or negligent manner which is likely to be injurious to said products iii Not make or permit any alterations to said products without Vendor s prior written consent and iv Upon reasonable notice during regular business hours permit inspection of the System by Vendor or Vendor s designated agent Bei FP ergeben sich die besonderen Pflichten des Softwarebestellers aus der soeben dargestellten gemeinsamen Verantwortung bei der Projektleitung und der Mitwirkung be
266. ll report any deficiencies in the Specifications to Developer and Developer will correct the deficiencies within the period set forth in Exhibit B XXXXX s acceptance or non acceptance of the Specifications will be based on XXXXX s determination of whether the Specifications represent an acceptable implementation of the functional requirements set forth in Exhibit A the Functional Requirements If XXXXX accepts the Specifications Developer will develop the Product in accordance with the Specifications and Functional Requirements Ahnlich findet sich bei AS unter 2 3 2 3 Acceptance of Technical Design Client has ten 10 days from the date on which Developer delivers the Technical Design in which to accept or reject it in writing If Client rejects the Technical Design Client must specify in writing Client s grounds for rejection and Developer will 1 S o S 61 567 Kapitel 4 Empirischer Befund in den USA use its best efforts to revise the Technical Design to make it acceptable to Client within the following ten 10 days If Client rejects the Technical Design a second time Client will have the option of repeating the procedure described in this section or terminating this Agreement on written notice to Developer Bei DaS V ist diese Pr fungspflicht unter Nr 1 S 2 bereits mit der Einf hrung der Anforderungen als Anlage in den Vertrag verkn pft Die vorgenannten Pr fungs und oder R gepflichten auch in zwei der neutra
267. lst ndig Neuentwicklung einer zum Vertrieb vorgesehenen Standardsoftware 528 Unter 6 findet sich eine weitere Vereinbarung mit dem Titel Vertragsgegenstand Wartung der diesbez gliche Details regelt 170 Kapitel 6 Empirischer Befund in Deutschland 3 die Prtifung der Vorgaben des Auftraggebers Pflichtenheft auf Sinnhaftigkeit und Machbarkeit 4 die Anpassung bzw Erweiterung der Standardsoftware an die Anforderungen des Auftraggebers wie in Beilage 1 spezifiziert und im Probebetrieb der Vorversionen noch genauer zu definieren 5 die Installation der Anwendungssoftware gem Beilage 3 inklusive der Anpassungen 6 die Optimierung der zentralen Datenbanksysteme in Bezug auf Laufzeitverhalten und Inanspruchnahme von Ressourcen 7 die Lieferung des Sourcecodes der Anwendungssoftware ohne die Sourcen f r Zeichen der CAD Routinen 8 die Unterst tzung des Auftraggebers bei der Inbetriebnahme und Erfassung der Stammdaten 9 die Mitwirkung an den Abnahmetests 10 die Lieferung der Dokumentation 11 die Schulung des Personals des Auftraggebers 12 die Wartung der Anwendungssoftware gem den Regelungen dieses Vertrages 13 die Lieferung und Anpassung der Anwendungssoftware in der Produzentenversion und H ndlerversion f r die Firma X zu diesem Vertrag vergleichbaren Bedingungen und auf besonderen Auftrag Die Lieferung des Sourcecodes ist in diesem Fall gesondert zu diskutieren Die genannten Pflichten sind Haup
268. lung der Mitwirkungspflichten setzen Nach fruchtlosem Ablauf der Frist kann der Anbieter vom Vertrag zur cktreten und neben Schadensersatz eine Verg tung verlangen die den bisher erbrachten Leistungen entspricht Der Kunde kann den Anbieter nach fruchtlosem Ablauf der Frist zu der Erkl rung auffordern ob er zur cktreten werde GL benennt neben den Ressourcen hier Informationen die vom Softwarebesteller zur Verf gung zu stellen sind Diese Vereinbarung tr gt dem Umstand Rechnung dass das Softwarehaus in der Regel hinsichtlich der betrieblichen d h v a fachlichen Gegebenheiten wie branchen bliche Daten Verfahren Gebr uche o auch bei eigener und sorgf ltiger Ist Analyse ein Informationsdefizit gegen ber dem Softwarebesteller hat GL w hlt hier die Regelbeispielmethode insbesondere Die Abrufpflicht f r Mitwirkungshandlungen ist weiter formalisiert schriftlich konkrete und die Folgen der Pflichtverletzung sind benannt wobei hier eine unverz gliche schriftliche R ge verlangt wird Dem Softwarehaus wird also eine aktive Rolle zugewiesen in der es die Mitwirkungshandlungen zun chst rechtzeitig und schriftlich abzurufen und bei Ausbleiben unverz glich und ebenfalls schriftlich zu r gen hat Besondere Informationspflichten die zum Teil mit R gepflichten kombiniert werden finden sich bei SN S GL und KO 157 Kapitel 6 Empirischer Befund in Deutschland BA bezieht die Vorsorge bzgl eines
269. m Pflichtenheft selbst erkennbare M ngel bleibt der Kunde berechtigt eine R ge ohne Mehrkosten f r ihn bei Abnahme der erstellten Software zu erkl ren KO geht von einem zweistufigen Verfahren aus bei dem Programmerstellung und Pflichtenhefterstellung streng voneinander getrennt sind und die Erstellung auch von einem Dritten durchgef hrt werden kann Die erste Phase muss vom Softwarebesteller abgenommen werden d h dieser muss best tigen das vom Softwarehaus erarbeitete Pflichtenheft entspreche seinen Vorstellungen und ihn trifft eine R gepflicht f r M ngel Bei MA bernimmt der Softwarebesteller die Pflichtenhefterstellung wobei bestimmte Vorgaben zu beachten sind 2 Softwarespezifikation und Pflichtenheft Die Software wird vom Hersteller entsprechend den im Pflichtenheft ausgearbeiteten Anforderungen hergestellt Das Pflichtenheft wird vom Anwender unter angemessener Beratung durch den Hersteller erstellt Es soll die in DIN 66231 Programmentwicklungsdokumentation aufgef hrten 513 Nach den Ergebnissen im Allgemeinen Teil lie e sich freilich mit guten Gr nden vertreten dass die Spezifikationserarbeitung einen integralen Teil der Softwareentwicklung darstellt Auch ist nicht einsichtig warum die Pflichtenhefterstellung nur dann verg tet werden soll wenn die Programmerstellung durch einen Dritten erfolgt Diese wichtige und umfangreiche Arbeitsleistung wird von jedem Anbieter zumindest kalkulatorisch in
270. m Rahmen seines Pflichtenhefts und des Terminplans die bei einem Projekt dieser Gr enordnung und dieser Art blichen nderungen 163 Kapitel 6 Empirischer Befund in Deutschland und Schwierigkeiten bereits ber cksichtigt Infolgedessen ist der AG berechtigt die sich im Rahmen einer Konkretisierung entstehenden Erg nzungs und nderungsw nsche anzubringen die der Auftragnehmer bestm glich ber cksichtigen wird 2 4 1 Der AG ist aber berechtigt gr ere nderungen zu verlangen wenn sich solche aus der Entwicklung seines Betriebs und seiner betrieblichen Strategie ergeben In diesem Falle wird der AG ein f rmliches nderungsverlangen an den AN stellen wonach das Pflichtenheft entsprechend anzupassen und zu erg nzen ist Der AN wird dieses nderungsverlangen kurzfristig sp testens innerhalb einer Woche beantworten und dabei auch mitteilen ob er dieses nderungsverlangen n her pr fen muss Er wird dabei insbesondere angeben welche nderungen sich aus seiner Sicht gegen ber der Projektsch tzung siehe 1 2 ergeben welche Auswirkungen auf die Termine dies wom glich hat und welchen Zeitaufwand er ben tigt um ein detailliertes Angebot in preislicher und terminlicher Hinsicht zur Ausf hrung des nderungswunsches anzubieten Erkennt der AN bereits in diesem Stadium dass die Ausf hrung des nderungswunsches f r ihn unzumutbar ist bzw seine Kr fte bersteigt so wird er auch dies bereits jetzt mitteilen 2 4 2
271. me frame implementation impact on the respective Joint Detailed Project Plans for SMS and or MAS and provided further that wherever costs of development or time frames are at issue the parties shall negotiate in good faith to reconcile the differences between them to reach as soon as practicable a mutually agreeable project plan to accommodate the implementation of any change Change Control shall be administered for SMS and the MAS Design Baseline according to the methodologies and standards resulting from Exhibit 3 Section 10 Bei AE ist im Falle von Anderungen ein einfaches einstufiges Verfahren vorgesehen Sie setzen ebenfalls eine schriftliche Anderungsvereinbarung voraus Die Bestimmung geht dabei davon aus dass der Softwarebesteller jederzeit eine nderung verlangen und eine entsprechende Order geben kann diese das Softwarehaus jedoch nur bei Einhaltung des Schriftformerfordernisses zu Verg tungsanspr chen berechtigt M gliche Kosten oder Zeitplanauswirkungen werden nicht erw hnt Company may at any time during the progress of the Work require additions to or alterations of or deductions or deviations all hereinafter referred to as a Change from the Work called for under an Authorization Letter subject to the terms of the applicable Authorization Letter Except as provided for in the Authorization Letter no Change shall be considered as additions to or deductions from the Work called for under the Authorization Letter
272. meinsame Entscheidungsnotwendigkeit den Softwarebesteller in sehr weitgehender Form einbezieht Nach der oben S 135 bereits dargestellten Nr 1 1 SN S wird der Softwarebesteller mit der Verantwortlichkeit f r die fachliche Feinspezifikation belastet Die Erstellung eines Pflichtenheftes ist nicht vorgesehen 143 Kapitel 6 Empirischer Befund in Deutschland In den BVB wird bei der Spezifikationsfrage die Orientierung an einem EDV technischen Phasenkonzept besonders deutlich Zu den Erstellungsleistungen gehort nach 1 Nr 1 a ausdrucklich das Erstellen des DV technischen Feinkonzeptes Unter 1 Nr 2 wird dabei eine klare Abgrenzung zu Planungsleistungen versucht Die Bedingungen gelten nicht f r die Planung von DV gest tzten Verfahren Im Phasenmodell geh ren die Verfahrensidee Ist Analyse Forderungen das Grobkonzept und das fachliche Feinkonzept zur Verfahrensplanung w hrend u a das technische Feinkonzept die Programmierung sowie das Testen der Verfahrensrealisierung und damit den BVB Erstellung zugeordnet werden bersicht ber das Phasenkonzept Verfahrensidee Ist Analyse Forderungen Verfahrens planung Grobkonzept Fachliches Feinkonzept DV technisches Feinkonzept System Programmierung Technische und realisierung organisatorische Vorbereitung Einf hrungs Verfahrens Integration
273. men Der Wortlaut bei MiN l sst erkennen was im Vorfeld der Vertrags unterzeichnung geschehen ist Nachdem das Softwarehaus ein Angebot erstellt hatte wurde auf dessen Basis durch den Softwarebesteller ein Pflichtenheft erarbeitet Zu diesem hat das Softwarehaus einen Abweichungsbericht vorgelegt der unter Einschr nkung der Anforderungen des Pflichtenhefts die zugesagten Leistungsmerkmale festlegt Das insofern irref hrend als Pflichtenheft bezeichnete Dokument stellt eher eine Wunschliste des Softwarebestellers dar die das Softwarehaus auf Realisierbarkeit pr fte Im Abweichungs bericht nicht erw hnte Punkte des Pflichtenhefts werden als erf llbar betrachtet Angebot Pflichtenheft und Abweichungsbericht bilden hier zusammen die Grundlage f r die Beschreibung der Leistungspflicht wobei der Geltungsvorrang zumindest dem zeitlichen Zusammenhang nach beim Abweichungsbericht liegt Auch der zus tzliche Hinweis unter 10 Schutzpflichten 10 3 Der AN hat das vom AG erstellte Pflichtenheft berpr ft und keine Bedenken im Hinblick auf Funktions und Einsatzf higkeit gem Nr 1 des Vertrages festgestellt ndert an der insoweit fehlenden endg ltigen Klarheit nichts denn als Ergebnis der Pr fung wurde ein Abweichungsbericht erstellt der eine Zusammenstellung von gerade nicht erf llbaren Anforderungen darstellt Die hier fehlende klare Priorisierung findet sich bei dem als
274. mence a cure ofthe default within thirty days of receiving written notice AdOutlet shall be obligated to pay iXL for all services rendered pursuant to any outstanding Statements of Work through the effective date of such termination 22 23 23 a 55 Kapitel 3 Rechtliche Rahmenbedingungen in den USA Korrektur oder Austausch zu beschr nken Schlie lich kann die Pflicht zur Spezifikation der Leistung dem Besteller auferlegt werden Dann f hrt eine mangelhafte Spezifikation zur Entlastung des Softwarehauses E Zusammenfassung und Ergebnis Die Leistungspflicht ist im amerikanischen Recht nur teilweise vertragsspezifisch d h f r einen bestimmten Vertragstyp angepasst geregelt An einer dem deutschen besonderen Schuldrecht vergleichbaren gesetzlichen Regelung f r die Erstellung eines Werkes fehlt es Als Rechtsquellen kommen f r den Untersuchungsgegenstand Gesetzesrecht law of statutes und Fallrecht Common Law in Betracht Im Bereich des law of statutes sind der U C C die CISG und der UCITA zu nennen Im Bereich des case law sind neben den eigentlichen Entscheidungen die Restatements of Law als vielbeachtete Autorit t heranzuziehen Die h ufig anzutreffenden Parallelen von Restatement on the Law of Contracts und dem U C C beg nstigen ein einheitliche Rechtsprechung Die Anwendung der Restatements wird h ufig die indirekte Anwendung des U C C zur Folge haben Dieser Effekt und die Tatsach
275. minute detail necessary terms frequently include time of performance place of performance price or compensation and penalty provisions Pyeatte v Pyeatte 135 Ariz 346 350 661 P 2d 196 200 Ariz Ct App 1982 Objectwave Corp v Authentix Network Inc 2002 WL 1477625 Northrop Grumman Corp v The United States 42 Cont Cas Fed CCH P77 381 1998 IXL inc v AdOutlet com Inc 2001 US Dist LEXIS 3784 2001 AdOultet war hier der Besteller iXL das Softwarehaus AdOutlet shall perform the tasks set forth in this Statement as a condition to iXL s obligations to perform hereunder and that at iXL s request AdOutlet shall provide client materials required by iXL to perform the tasks set forth in the Statement Id P 2 2 AdOutlet shall comply in a timely manner with all reasonable requests of iXL for assistance in enabling iXL to fulfill any of iXL s obligations under this Statement A failure by AdOutlet to meet its deadlines will result in an extension of the time allowed for iXL to perform Der Vertrag gab dem Softwarehaus das Recht bei Versto des Bestellers gegen seine Mitwirkungs Pflichten zu k ndigen und dies bei fortbestehender Zahlungspflicht f r alle bis zur Wirksamkeit der K ndigung ausstehenden Arbeiten The Agreement further provided for termination upon other material defaults of duties and obligations under the Agreement other than payment obligations ifthere was a failure to substantially cure or com
276. mit dem Hinweis versehen diese Aussage sei so wichtig f r die Systementwicklung wie die Newton schen Gesetze in der Physik die Fehler der fr hen Planungs Phase sind also die bei weitem teuersten Fr hauf Ludewig Sandmayr a a O S 19 Franz a a O S 128 3 Wie beispielsweise im V Modell im Rahmen des Konfigurationsmanagements 9 Was nach Brooks bei mit dem Grundkonzept inkompatiblen Ideen angezeigt ist Mythos S 39 5 Brooks spricht davon dass Ideen und Vorstellungen die nicht in das Gesamtkonzept passen nur aus diesem Grund sofort verworfen werden sollten Mythos S 39 dementsprechend bezeichnet er die Geschlossenheit des Konzeptes als den_ Hervorhebung im Original grundlegenden Gedanken der Systementwicklung S 36 Brooks der dies am Beispiel des Turmbaus zu Babel illustriert Mythos S 64ff Love a a O S 120 Etzel Heilmann Richter a a O S 64 68 A a O S 105ff 28 Kapitel 2 Softwareentwicklung in der Praxis Abteilung des Softwarebestellers sondern auch und gerade fur dessen Fachabteilung und F hrungskr fte Auch die Notwendigkeit klarer Verantwortungen und Zust ndigkeiten ist bei der Vielzahl beteiligter Personen unmittelbar einsichtig Dies erstreckt sich auch auf die im Licht der Diskussion aktueller Entwicklungsmethoden vielleicht berraschende Forderung nach hierarchischen Strukturen wobei allerdings Verantwortung und Entscheidungsbefugnis zusammenfallen m ssen
277. msatz von 56 360 Mrd erzielten Darauf entfallen 26 562 Softwarehauser mit 228 750 Mitarbeitern und einem Umsatz von 31 229 Mrd In dem Sektor Informations und Kommunikationstechnologien arbeiteten 2002 insgesamt 1 078 443 Menschen in 57 716 Unternehmen und erzielten einen Umsatz von 270 754 Mrd In den USA verdoppelte sich die Anzahl der Besch ftigen im speziellen Bereich des Computer programming zwischen 1995 und 2000 von 245 300 auf 518 700 Im Online Information Service wuchs die Zahl der Mitarbeiter zwischen 1999 und 2000 von 98 900 auf 177 300 Diese Zahlen belegen die gro e Bedeutung der Informationstechnologie als Wirtschaftsfaktor sowie die deutlichen Wachstumsraten in der Branche C Erscheinungsformen von Software Software kann nach vielen Kriterien eingeteilt werden Eine g ngige Unterscheidung differenziert zwischen Systemsoftware und Anwendungssoftware W hrend die Systemsoftware zur Verwaltung und 8 SJB D 2005 S 118 Vergleichszahlen aus dem deutschen Baugewerbe zeigen folgendes Bild In 2003 erwirtschafteten 14 203 20 639 in 1999 erfasste Unternehmen mit 744 000 1 127 000 in 1999 Mitarbeitern einen Umsatz von 85 207 221 460 in 1999 Mrd SUB D 2005 S 367 Sowohl Umsatz als auch Besch ftigung sind also deutlich r ckl ufig 10 Statistical Abstract of the US 2002 122 Edition Issued by the Department of Commerce Dec 2002 S 696f In der IT industry wur
278. munikation der Vertragspartner und kontinuierliche Mitarbeit des Softwarebestellers kann jedenfalls kein optimales Ergebnis erzielt werden Ein Grund f r nderungen der Anforderungen sind Fehlvorstellungen ber die Einfachheit und die Auswirkungen von nderungen Software ist ein hochgradig wandlungsf higes und wandlungsanf lliges Produkt H ufige nderungen tragen jedoch nicht zum Projekterfolg bei da nderungen an einer Stelle regelm ig die Notwendigkeit von nderungen an anderer Stelle und damit einen nicht kalkulierbaren Ressourcenverbrauch Zeit und Kosten nach sich ziehen Je sp ter nderungen konzeptioneller Art durchgef hrt werden um so aufwendiger sind sie Schlie lich hat sich Fehlerfreiheit nicht als geeignetes Qualit tskriterium f r komplexe Software erwiesen Die Grundvoraussetzungen unter denen ein Softwareprojekt durchgef hrt wird sind demnach im Anschluss an die Ausgangsfrage aus dem ersten Kapitel wie folgt zu benennen Eine effektive Projektabwicklung d h die optimale Zielerreichung h ngt von stabilen und pr zisen Vorgaben bei flexibler Handhabung ab Pr zise und unver nderte Zielvorgaben erh hen die Kalkulierbarkeit wobei sie jedoch bei mangelnder Flexibilit t im Hinblick auf allf llige nderungen zu einer unbrauchbaren L sung f hren k nnen Ein bedarfsgerechtes Ergebnis wird also nur erreicht wenn die Genauigkeit der Spezifikation mit der Offenheit f r nderungen ausbalanci
279. n Einordnungsgesichtspunkten z hlt die Dauer der Software berlassung Soll sie nur auf Zeit erfolgen sei von Miete auszugehen F r Softwareentwicklungsvertr ge ist eine berlassung auf Zeit allerdings kaum denkbar Als ungeeignete Kriterien werden die Bezeichnung sowie die Verg tungsregelung Einmalzahlung oder Zahlung nach Zeitabschnitten aussortiert Einige Stimmen wollen eine Abgrenzung danach vornehmen wer das Herstellungsrisiko tr gt Mehrfach vertreten ist das Einordnungskriterium der Angemessenheit der Normen Daneben werden die Bestimmtheit und die Beeinflussbarkeit des Erfolges genannt Zwei Vertr ge zur Softwareerstellung ITRB 2002 S 297 differenzierend danach ob ein Anwender oder ein Softwarehaus als Besteller auftritt und wer die Verwertungsrechte erh lt wobei nur dann 651 BGB greifen soll wenn eine Anwender der ein einfaches Nutzungsrecht erh lt Besteller ist Redeker Helmut Softwareerstellung und 8 651 BGB CR 2003 S 88 Schneider Handbuch des EDV Rechts 3 Aufl K ln 2003 S 1065 und 1137 Zuletzt Hilty Reto Der Softwarevertrag ein Blick in die Zukunft MMR 2003 S 3 m w Nachw Gl ckler in Sobola Sabine Dobmeier Gerhard Hrsg Software und Arbeitsvertr ge f r die IT Branche Berlin 2003 S 230 Karger Kooperation bei komplexer Softwareentwicklung ITRB 2003 S 208 M ller Hengstenberg CR 2005 S 385 Heppner Softwareerstellungsvertr ge D
280. n Im amerikanischen Recht f hrt dies dazu dass z B die Frage ob ein Gericht den U C C anwenden wird oder nicht keineswegs sicher beantwortet werden kann Dieser Befund ist auch das Ergebnis der unterschiedlichen Gerichtsbarkeiten und Rechtsgrundlagen in den 50 amerikanischen Bundesstaaten In der deutschen Rechtssph re zeigt sich die Problematik auf andere Weise W hrend die Gerichte berwiegend einer klaren Linie folgen findet sich in der Fachliteratur eine kaum berschaubare Vielfalt von Meinungen In den USA w rde eine wie in Deutschland gefestigte Rechtsprechung die Rechtslage mit hoher Wahrscheinlichkeit ber viele Jahre hinweg zementieren In Deutschland wo es eine Bindung der Gerichte an Vorentscheidungen nicht gibt kann sich die Rechtslage durch eine Ma nahme des Gesetzgebers schnell ndern Durch die Schuldrechtsreform aus dem Jahre 2002 und vor allem die damit verbundene nderung des nach der Rechtsprechung ma geblichen Werkvertragsrechts ist genau eine solche Situation eingetreten Die deutschen Gerichte k nnten diese Gesetzes nderung zum Anlass nehmen ihre Entscheidungspraxis zu 192 Kapitel 7 Vergleichende Darstellung andern Sie sind dazu aber nicht gezwungen weil das Gesetz nur das bisher als Grundlage der Spruchpraxis dienende Werkvertragsrecht anderte nicht aber die Softwareentwicklung oder sonstige Softwarevertrage regelte Eine Ma nahme der Legislative kann die Rechtsprechung also zwingen
281. n wonach ein h ufiger Grund f r das Scheitern von Softwareprojekten darin zu sehen ist das das Softwarehaus nicht gelernt hat oft oder wirkungsvoll genug Nein zu sagen Dies bedeutet nichts anderes als die Neigung der Softwareh user auch schwer oder im 225 Kapitel 8 Schlussfolgerungen Ergebnis letztlich gar nicht erzielbare Ergebnisse als Vorgabe zu akzeptieren Wenn diese Neigung auf eine Vertragsregelung trifft die dem Softwarebesteller weitgehende und dem Softwarehaus allenfalls rudiment re Rechte im nderungsverfahren einr umt so ger t das Projekt vom Regen in die Traufe Ein ohnehin nur z gerlich die Anforderungen und Erwartungen premsendes Softwarehaus wird damit konfrontiert Projekterweiterungen akzeptieren zu m ssen Die nat rliche Diskrepanz zwischen Planung und Wirklichkeit kann nicht durch einseitige Bestimmung gel st werden An ihre Stelle muss vielmehr eine gemeinsame Planung sich ver ndernder Wirklichkeit treten Ill Interessenorientierte oder projektorientierte Vertragsgestaltung Sowohl die deutsche wie die amerikanische Rechtsordnung sehen die Vertragsfreiheit als ein zentrales Element der Zivilrechtsverfassung an Die Frage was den Parteien im Rahmen der Gestaltung von Software entwicklungsvertr gen erlaubt ist stellt sich daher wenn berhaupt nur in extremen F llen Davon unabh ngig ist allerdings die Frage was aus Sicht der Beteiligten sinnvoll ist Soll die Aushandlung des
282. n Change Management vorgesehen ist so berrascht hinsichtlich der Muster dass es bei f nf von ihnen also nahezu einem Drittel an einer Regelung fehlt Dort wo sie vorhanden ist kann ein nderungsverlangen von jeweils einer Ausnahme abgesehen nur von dem Softwarebesteller ausgehen Die M glichkeit der Ablehnung durch das Softwarehaus ist nur in jeweils 2 Mustern und einem Praxisbeispiel vorgesehen 201 Kapitel 7 Vergleichende Darstellung Zusammengefasst ergibt sich folgendes Bild Die Regelung des Change Managements wird von einer bedeutenden Anzahl von Mustern vernachlassigt Dass Anderungsverfahren fast durchweg nicht vom Softwarehaus eingeleitet und zudem nur ausnahmsweise von diesem zur ckgewiesen werden k nnen ist nur als Entgegenkommen seitens des Softwarehauses verst ndlich und m glicherweise Ausdruck der derzeitigen Machtverh ltnisse zwischen Softwarebestellern und Softwareh usern Aus Sicht des Software Engineering ist es nicht nachvollziehbar und stellt eine signifikante Gefahr f r den Projekterfolg d h die termin und budgetgerechte Erf llung dar Dieses Problem wird mit wenigen Ausnahmen weder von deutschen noch von amerikanischen Autoren thematisiert Der Vergleich zeigt also eine Fehleinsch tzung im Verh ltnis der Disziplinen und nicht der Rechtsordnungen zueinander Soweit Unterschiede ersichtlich sind bestehen sie zum einen in der ausgepr gteren Tendenz deutscher Muster Technik und Recht
283. n Mustern mit Ausnahme von SO behandelt Bei HE ist es Bestandteil des Entwicklungsprozesses und bedarf keiner gesonderten Regelung Die Initiative soll dabei vom Softwarebesteller ausgehen lediglich bei SN S ist auch ein Ansto f r nderungen vom Softwarehaus vorgesehen Eine bestimmte Form der nderungsmeldung wird nicht verlangt Eine pr gnante Formulierung findet sich bei MA 5 Nachtr gliche nderungsw nsche 1 nderungsw nsche des Anwenders im Hinblick auf den Funktionsumfang die Programmstruktur die Bildschirmgestaltung oder sonstige Merkmale muss der Hersteller nicht ber cksichtigen soweit sie eine Abweichung vom urspr nglichen Vertragsinhalt darstellen insbesondere nicht mit dem der Programmerstellung zugrunde gelegten Pflichtenheft oder sonstigen Leistungsbeschreibungen bereinstimmen 2 Dem Hersteller steht es frei die gew nschten nderungen gegen ein angemessenes zus tzliches Entgelt zu ber cksichtigen 159 Kapitel 6 Empirischer Befund in Deutschland Nach MA stellt das Abweichen vom Pflichtenheft eine vergutungspflichtige Ausnahmesituation dar Basis fur einen solchen Gedanken ist die Annahme den Regelfall bilde ein im Pflichtenheft vollstandig erfassbares Vertragsziel Diese Annahme steht im Widerspruch zu den aus der Praxis der Softwareentwicklung gewonnenen Erkenntnissen wie sie sich konsequent nur bei HE wieder finden Eine vergleichbar rudimentare Regelung findet sich auch bei KO
284. n keinen anderen Sinn beylegen als welcher aus den Worten und dem Zusammenhange derselben in Beziehung auf den streitigen Gegenstand oder aus dem n chsten unzweifelhaften Grunde des Gesetzes deutlich erhellet Es ist jedoch davon auszugehen dass der Gesetzgeber des BGB niemals an die L ckenlosigkeit der Kodifikation geglaubt hat Coing in Staudinger Einl zum BGB Rn 204 Auch sprechen einige Gr nde daf r anzunehmen die den Richtern des Kaiserreichs zugeschriebene Anh ngerschaft zur Begriffsjurisprudenz sei durchaus weniger ausgepr gt gewesen als angenommen Eckert J rn AcP 2003 S 863ff 88 Dubischar Roland Grundbegriffe des Rechts Stuttgart Berlin K ln Mainz 1968 S 21 29 Dubischar a a O S 10 a E 11 300 Nach Stimmen in der Literatur Staudinger Coing a a O Rn 206 Schlosser a a O S 191 besonders instruktiv ausgedr ckt in Art 1 des schweizerischen ZGB 301Schlosser a a O S 194 zur sog Freirechtsschule vgl auch Staudinger Coing Rn 205ff Soergel Hefermehl Anh 133 Rn 16 u ert die Bef rchtung eine zu starke Betonung der richterlichen Wertungsfreiheit k nne dazu f hren dass die Rechtsprechung zu einer zusammenhanglosen Falljustiz abgleitet und zur Rechtsunsicherheit f hrt 99 29 S Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland Recht gebunden Die Bindung an Gesetz und Recht impliziert Gestaltungsspielr ume bei Aus bung der rechtsprechen
285. n und die jeweiligen Arbeitspl tze selbst ndig die neuen Versionen laden 6 7 Die Programm und Datenstrukturen sind so ausgelegt dass der AG Erweiterung an den Datentabellen vornehmen kann z B Statistikfelder ohne dass die Programmfunktionalit t darunter leidet und die Update F higkeit eingeschr nkt ist Stammen Software und Hardware wie im Regelfall nicht aus einer Hand so ist dem Softwarebesteller daran gelegen gleichwohl eine Betreuung des Gesamtsystems sicherzustellen Dies spiegelt sich in 6 1 wieder wobei die Pflichten des Softwarehauses hier durch die Begrenzung auf vorhandene Kapazit ten und gegen Verg tung nicht unerheblich relativiert werden Weiter soll durch konkrete Benennung bestimmten Risiken f r den Softwarebesteller vorgebeugt werden Nr 6 2 Erneut findet sich in Nr 6 7 eine im Hinblick auf nderungen von Teilen der Software konzipierte Klausel IV Besondere Pflichten des Softwarehauses SUS legt besonderen Wert darauf dem Softwarebesteller eine Kontrolle der T tigkeit des Softwarehauses zu erm glichen 2 3 Der Auftragnehmer wird dem Partner auf Wunsch jederzeit Einblick in die jeweils vorliegenden Arbeitsergebnisse geben alle sonstigen gew nschten Ausk nfte erteilen sowie Beauftragten des Partners w hrend 180 Kapitel 6 Empirischer Befund in Deutschland der bei dem Auftragnehmer blichen Arbeitszeit Zutritt zu den R umen gew hren in denen die Softwareentwicklung durchgef hrt
286. nardo da Vinci D rer oder vieler anderer vor Augen hat wird zwischen Wissenschaft und Kunst freilich keinen Widerspruch finden m ssen 111 Love a a O mit Beispielen S 32 112 A a O S 30 nach Sneed Risiken der Softwareentwicklung zitiert nach Etzel Heilmann Richter a a O S 14 liegt die Wahrscheinlichkeit f r den erfolgreichen Abschluss gro er IT Projekte mit mehr als 20 Mitarbeitern bei 42 bei Projekten mit weniger als 5 Mitarbeitern bei 74 113 Mark Norvis Survival in the Software Jungle Boston 1995 zitiert nach Thaller a a O S 25 auch wenn sich die statistischen Aussagen zahlenm ig unterscheiden so ist der Befund doch eindeutig Wenn dasselbe f r Bauvorhaben gelten w rde so st nde an jeder Stra enecke eine Bauruine 30 Kapitel 2 Softwareentwicklung in der Praxis Die Frage ob und wann ein Projekt erfolgreich beendet wird ist dabei auch deswegen schwer zu beantworten weil auf Seiten der Informatik soweit ersichtlich die einheitliche Auffassung besteht dass fehlerfreie Software nicht nachweisbar ist In der Praxis ist es weniger von Bedeutung ob Fehler gefunden werden sondern wann dies geschieht und wie Softwarebesteller und Softwarehaus darauf reagieren Als eine wesentliche wenn nicht sogar die bedeutendste Ursache f r den Misserfolg von Projekten werden Schwierigkeiten bei den Anforderungsdefinitionen genannt Vyssotzky sieht die grunds tzliche Aufgabe der Systemarchitekten
287. nbegriffen B Beispiele aus der Praxis Als Beispiele aus der Praxis wurden drei Vertr ge ausgew hlt die Softwareentwicklungsprojekte in den USA betreffen Der erste wurde zwischen einem Softwarehaus aus Nebraska First Data Resources und einem Softwarebesteller aus New York Prodigy Services im folgenden FP der zweite zwischen einem Softwarehaus in Colorado Evolving Systems und der American Telephone and Telegraph Company in New Jersey AE der dritte zwischen einem Softwarehaus in Manitoba Canada 245 Auch hier sind weitere Einzelheiten wie eine Response Time warranty vorgesehen Bei DL unter 3 a bei FL unter 3 01 Bei AS unter 3 1 wobei eine Basiszahlung Base development Fee und Zusatzzahlungen Additional Development Fees f r nderungen vorgesehen sind So bei RB V nach Nr 11 a E general consulting services So bei DaS U unter 5 das nur reasonable travel expenses incurred in travelling to User facilities von dem Fixpreis ausnimmt Die Auswahl spiegelt unterschiedliche Ausgangssituationen wider sowohl was die Gesamttendenz des Vertrages mehr an den Interessen des Softwarebestellers so in AE siehe sogleich bzw des Softwarehauses so in FP orientiert als auch was die faktische Grundlage Neuentwicklung in OD Weiterentwicklung in FP anbelangt An dieser Stelle m chte ich nicht vers umen mich bei dem Kollegen Prof Anuj Desai von der University of Wisconsin Ma
288. ndelt Im Ergebnis wird von zwei breiten Str mungen mit unterschiedlichen Begr ndungen die Anwendbarkeit des reinen Werkvertragsrechts sowie des nach 651 BGB modifizierten Kaufvertragsrechts vertreten Daneben finden sich auch Ansichten die keinen Typus des besonderen Schuldrechts oder eine Mischform als gegeben sehen Die Rechtsprechung verfolgt demgegen ber zur Rechtslage vor der Schuldrechtsreform eine klare Linie wonach Softwareentwicklungsvertr ge nach Werkvertragsrecht zu beurteilen sind Einen zentralen Gesichtspunkt stellt in Literatur und Rechtsprechung die Frage nach der Sacheigenschaft von Software dar In der Literatur wird dies ohne absehbare Kl rung kontrovers diskutiert Dabei findet h ufig zun chst eine begriffliche Unterscheidung zwischen dem Programm und der Programmverk rperung statt und anhand der Auffassung zur Trennbarkeit wird ber die Einordnung als Sache entschieden Die Rechtsprechung ordnet Software unbeirrt von der Diskussion in der Literatur unter den Sachbegriff ein Ein besonderer Status wird der Software gleichwohl von einigen Stimmen in Rechtsprechung und Literatur hinsichtlich des auf sie anwendbaren Fehlerbegriffes zugestanden 127 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland Entgegen der weitlaufig betonten Bedeutung konkreter Leistungsbestimmung wird diese in der Praxis haufig gar nicht verspatet und oder mit erheblichen Abweichungen zur anfanglichen Konzeption vorgenommen Die
289. nderungsfeinspezifikation Die Parteien werden die gew nschten nderungen in einer nderungsfeinspezifikation schriftlich festlegen und gemeinsam verabschieden 3 5 Mangel der Einigung ber nderung Wird ber ein nderungsverlangen keine Einigung erzielt werden die Parteien soweit sie keine andere Vereinbarung treffen das Projekt entsprechend der verabschiedeten Feinspezifikation 1 1 realisieren 165 Kapitel 6 Empirischer Befund in Deutschland Zeitvorgaben werden hier nicht gemacht und das Vergutungsinteresse des Softwarehauses wird besonders betont Es fehlt an einem mehrstufigen Verfahren wie in den vorstehenden Mustern Hervorgehoben wird zudem die beidseitige Verantwortlichkeit bei der Initiative zur Anderung 3 1 und bei der Ausarbeitung der Anderungsspezifikation 3 4 Die Pr fung von nderungen darauf ob sie Auswirkungen auf den Projektstatus haben nur f r den Fall vorzusehen dass dies m glich und notwendig ist stellt eine durchaus zweifelhafte Option f r das Softwarehaus dar Sieht es von einer solchen Pr fung ab und stellen sich im Nachhinein Schwierigkeiten bei der Projektabwicklung heraus d rfte ein Berufen auf diese Klausel einer schieds gerichtlichen Kontrolle kaum standhalten In den BVB findet sich ein in weiten Teilen den vorstehenden Mustern entsprechendes Verfahren 5 nderung der Leistung 1 Der Auftraggeber kann bis zur Abnahme oder dem im Erstellungsschein vereinbarten
290. ndividualsoftware CR 2004 S 326 Schweizerische Vereinigung fur Datenverarbeitung Hrsg EDV Pflichtenhefte 2 Aufl Bern und Stuttgart 1984 Schwickert Axel Web Site Engineering Stuttgart Leibzig Wiesbaden 2001 Scott Michael D Scott on Computer Law 2 Aufl New York 2003 Seffer Adi Horter Carsten Nebenleistungspflichten des Erstellers von Individualsoftware ITRB 2005 S 169 Sick Ulrich Vertrage im Projekt und Systemgeschaft 2 Aufl Heidelberg 2004 Simon David F Computer Law Handbook Philadelphia 1990 Slongo Doris Der Softwareerstellungsvertrag Diss Z rich 1991 Sobola Sabine Dobmeier Gerhard Hrsg Software und Arbeitsvertr ge f r die IT Branche Berlin 2003 zitiert Sobola Dobmeier Bearbeiter S bbing Thomas Die Bedeutung der ITIL f r die Vertragsgestaltung ITRB 2005 S 97 Soergel Hs Th Begr B rgerliches Gesetzbuch Bd 2 Allgemeiner Teil 88 104 240 13 Aufl Stuttgart 1999 Zitiert Soergel Bearbeiter ders Bd 13 CISG 13 Aufl Stuttgart 2000 Spindler Gerald Hrsg Rechtsfragen bei Open Source K ln 2004 Spitta Thorsten Softwareentwicklung Berlin 2003 ders Scriptum Informationsmanagement S 5 abrufbar zuletzt 12 12 05 unter http www wiwi uni bielefeld de spitta download IM3 pdf Statistical Abstract of the US 2002 122 Edition Issued by the Department of Commerce Dec 2002 Statistisches Jahrbuch 2005 f r das Ausland SJB A 2005 Wiesbaden 2005 St
291. nebst umfassender Parametrisierung Anderung und Erweiterung dieser Software 8 1 1 b zu liefern ist 137 Kapitel 6 Empirischer Befund in Deutschland SN S spricht von der Ubergabepflicht von Bedienungsanleitung Bedienungshandb cher und Installationsanweisung Nr 1 2 w hrend sich bei SN B 1 3 2 die weitestgehende Formulierung findet An Dokumentationen sind deshalb dem AG in verst ndlicher und f r die jeweilige Adressatengruppe geeigneter Form zu erstellen und auszuh ndigen eine ausf hrliche Programmbeschreibung mit Kommentaren und Hinweisen auf die entsprechenden Passagen des Quellcodes Programmier Anweisungen Entwicklungsdokumentation Datenmodell Installationsdokumentation Bedienungsanleitung Die Frage der Quellcode bergabe behandeln die Muster ebenfalls nicht einheitlich MA 8 1 BA 8 6 3 SN B 5 2 verlangen die bergabe des Quellcode bei KO 8 2 2 1 GL 9 1 2 ist sie nur bei gesonderter Vereinbarung geschuldet bei SN S HE und in den BVB ist sie nicht vorgesehen ber die Lieferung von Software und Dokumenten hinausgehende Pflichten finden sich als Option bei GL 6 3 7 1 das Erstellen eines Pflichtenheftes und in den BVB 8 1 Nr 1 a grunds tzlich das Erstellen des DV technischen Feinkonzeptes Die Vielfalt der verwendeten Begriffe hinsichtlich der Dokumentenlieferung tr gt hier zur Verwirrung bei zumal es an einer Definition oder der Erkl run
292. nen Anderungen 1 1 Einleitung nur durch Softwarebesteller 6 2 Einleitung auch durch Softwarehaus 1 1 1 Anderung kann vom Softwarebesteller verlangt werden 4 1 2 1 Anderungswunsch des Softwarebestellers kann abgelehnt werden 2 1 2 Das Verfahren ist an Fristen gebunden 3 2 Es handelt sich berwiegend nicht um klare Ja Nein Kriterien weshalb die Tabelle nur als Ubersicht zur Verdeutlichung einer Tendenz gedacht ist Auch muss nat rlich die geringe Gr e der Stichprobe hinsichtlich der Praxisbeispiele ber cksichtigt werden Zur Erinnerung Es wurden 9 deutsche und 7 amerikanische Muster und jeweils 3 Praxisbeispiele untersucht Dass dies in den Beispielen nicht ausdr cklich vorgesehen ist liegt teilweise an der Vertragspr misse Anderungen w rden durch die von beiden Vertragsparteien besetzte Projektleitung kontinuierlich abgehandelt Diesem Verlangen muss in drei F llen bei Unzumutbarkeit nicht entsprochen werden Auch wenn eine nderung verlangt werden kann setzt sie bei gr erem Ausma in jedem Fall eine Vereinbarung ber die Verg tung voraus Die Bewertung dieser Informationen gestaltet sich infolge der unterschiedlichen Ausgangspunkte der Muster und Beispiele nicht einfach Es lassen sich jedoch im Hinblick auf die Ausgangsfrage ob und ggf wie einem Wandel der Anforderungen Rechnung getragen wird einige klare Aussagen treffen Auch wenn in elf Mustern und f nf Beispielen ei
293. ng wird besonders hervorgehoben von Eschbach Software nach Ma Haar 1992 S 140 Love Tom T cke des Projekts Hannover 1994 S 33 Zehnder Informatik Projektabwicklung 2 Aufl Stuttgart 1991 S 119 20 In diesem Zusammenhang wird h ufig auch von einem Software Lebenszyklus Dumke Software Engineering 3 Aufl Braunschweig Wiesbaden 2001 S 17ff oder auch Software Lebenslauf Fr hauf Ludewig Sandmayr Software Pr fung Stuttgart 1991 S 14ff gesprochen 21 Heinrich Lutz J Systemplanung 6 Aufl M nchen Wien 1994 S 43 10 Kapitel 2 Softwareentwicklung in der Praxis Strategische Informationssystem Planung Ergebnis Planungsziele v Der Prozess der Vorstudie v Ergebnis Grundkonzeption v Der Prozess der Feinstudie lt lt v Ergebnis angepasste Grundkonzeption v Der Prozess der Grobprojektierung P Vv Ergebnis Logisches Modell Sollzustand v Der Prozess der Feinprojektierung a v Ergebnis Physisches Modell Sollzustand v Der Prozess der Installation v Ergebnis Produktives Informationssystem D gt pe oO c 2 io i 9 70 T gt e OO Cc gt Cc oO i 2 c oO gt x O QO oO ep oO H 2 Cc oO Q 2 lt oO Tw oO oO D oO Q D Cc oO ie L A B
294. ng und Ergebnis 44444444 44444 32 Kapitel 3 Rechtliche Rahmenbedingungen f r Softwareentwicklungsvertr ge unnsnnsnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 36 A Einordnung und Bedeutung der Rechtsquellen 36 B Performance ae ee re evecddvendsnsteenterdvendemeeise 38 C Statute EaW ee ee ee ends EK EEEE TEE 40 LU ease ARE ARE ELTERN EE TEE VAINERAHRERNA AR AE 40 1 Anwendbarkeit ehe 40 2 Anwendbarkeit des U C C auf Software ueeeeeennn 41 3 Anwendbarkeit auf Softwareentwicklung 44444440 0 43 Dissertation Softwareentwicklungsvertrage Inhaltsverzeichnis 4 Regeln zur LeistungsbestiMMUung ccccceeeeeeeeeeeeeeeeenenaaes 45 Il Convention on Contracts for the International Sale of Goods CISGY oa pen 47 III Uniform Computer Information Transaction Act UCITA 49 DE Eommon award 49 Restalemen a ehe 49 Gase LaWi near nase ke 53 E Zusammenfassung und Ergebnis 4444444444444nnnnnnnnnnnnnnnnnnn nenn 56 Kapitel 4 Empirischer Befund in den USA uuzz44444400004000R RR Rn n nun 59 A M sterentWUTe snesena ee 59 l Vertragsart 822 60 ll Bestandteile der Lieferung 62 Ill Spezifikationen asus ern enn 65 IV Besondere Pflichten des Softwarehauses 44440 68 V Besondere Pflichten des Softwarebestellers 72 VI Ver nd
295. nge the Design Document as requested by User following its review of it The Design Document shall then approved by User in writing prior to the start of any other work under this agreement Such approval shall not operate as an acceptance by user of any latent defects deficiencies problems or omissions in the Design Documents or the System iii In the event that Vendor does not provide to User a Design Document which is satisfactory to User as determined in the sole discretion of User User may elect to terminate this agreement without further liability or obligation ton Vendor and may retain the Design Document and use it in whatever manner if any User sees fit Eine zusatzliche Kundigungsmoglichkeit wird dem Softwarebesteller nach Abschluss der Spezifikationsphase eingeraumt 25 Termination a b User may at its sole option elect to terminate this agreement for convenience by written notice following the completion of Phase I Anm Gemeint ist die Systemdefinition in Abgrenzung zur eigentlichen Systementwicklungsphase In the event of such termination User shall pay the amount due for Phase I shall retain and own all rights in and to the Design Document and shall have no further obligations to Vendor and the parties shall continue to be bound by the noncompetition and confidentiality sections of this Agreement In RB U wird besonderer Wert auf die Integration des Softwarebestellers in den Entwicklungsproze
296. ngen behandelt Geringf gige nderungen einer Vorgabe Zielvorgabe Vorstudie Pflichtenheft einzelne Funktionen werden durch Absprache zwischen dem Projektleiter des Auftraggebers und dem Projektleiter des Auftragnehmers vorl ufig festgelegt an jedem Monatsende vom Projektleiter des Auftragnehmers schriftlich festgehalten und werden durch kaufm nnischen Briefwechsel zwischen den Parteien vereinbart Auftraggeber und Auftragnehmer bevollm chtigen hiermit in diesem Sinne ihre Projektleiter Gr ere nderungen bed rfen von vorne herein der Schriftform Als gr ere nderungen sind nderungen zu verstehen deren Implementation entweder den Arbeitsumfang von drei Manntagen berschreitet oder die Funktionalit t der Software einschr nkt Kleinere nderungen bis zum Gesamtaufwand von sechs Arbeitstagen je Quartal des Projektzeitraumes sind im Pauschalpreis inbegriffen Rechtzeitig vor der Inangriffnahme der Ausf hrung weiterer nderungen muss der Auftragnehmer die schriftliche Zustimmung des Auftraggebers einholen Es wird terminologisch nicht ganz klar zwischen kleinen geringf gigen und gr eren nderungen unterschieden Dem in Absatz 1 festgelegten monatlichen Rhythmus ist die blichkeit der nderungen zu entnehmen Es wird kein besonderes Verfahren vereinbart sondern von einer gemeinsamen Entscheidung ausgegangen 186 Kapitel 6 Empirischer Befund in Deutschland Auch bei MiO ist im Rahmen der Wartung d
297. ngungen trifft Die vorhandenen Ressourcen m ssen daher auf weitere Verwertbarkeit und falls dies zutrifft auf die Notwendigkeit von Schnittstellen mit der zu erstellenden Software gepr ft werden Vgl Brockhaus Computer und Informationstechnologie Mannheim Leipzig 2003 unter Pflichtenheft Balzert Lehrbuch Grundlagen der Informatik 2 Aufl M nchen 2005 definiert das Pflichtenheft als Festlegung der Anforderungen an ein Software System in verbaler d h umgangssprachlicher Form Feretti W rterbuch der Datentechnik Berlin Heidelberg New York 1996 setzt das Pflichtenheft mit Spezifikationen gleich und definiert sie schlicht als vorgegebene technische Bedingungen Grieser Irlbeck Computer Lexikon 2 Aufl M nchen 1995 definieren das Pflichtenheft als Schriftst ck das vom Softwarehaus in Zusammenarbeit mit dem Kunden verfasst wird und die detaillierte Beschreibung der gew nschten F higkeiten enth lt 2 Vgl Schaub CR 1993 S 329 die darauf hinweist dass der ebenfalls verwandte Begriff der Leistungsbeschreibung keine sachlichen Unterschiede aufweist 43 Grupp Bruno EDV Pflichtenheft zur Hardware und Softwareauswahl 2 Aufl K ln 1991 S 29ff vgl auch Dumke der von einer Anforderungsanalyse spricht sie aber als eine der Pflichtenhefterstellung nachgelagerte Phase ansieht a a O S 32ff die Terminologie ist vielf ltig Situationsstudie Vorstudie u vgl Kargl a a O
298. nn der Softwarebesteller ber eine eigene Entwicklungsabteilung verf gt die sich an Wartung und Pflege der Software beteiligt ohne alleine daf r verantwortlich sein zu k nnen oder zu wollen Durch die ausf hrliche Pflichtendefinition zur Dokumentationslieferung wird dieser Gedanke best tigt 23 Dokumentation enth lt dazu folgende Regelung Teil des Vertragsgegenstandes bei Lieferung und Wartung ist die Lieferung und laufende Aktualisierung Benutzer und technischer Dokumentation f r alle gelieferten EDV Komponenten sowie die Lieferung eines Testdatenbestandes Die Benutzerdokumentation besteht mindestens aus einem Benutzerhandbuch und der kontextintensiven Online Hilfe Benutzerhandbuch und Handbuch f r Installation und Administration haben alle f r die laufende Arbeit notwendigen Abl ufe so zu beschreiben dass sie f r eine eingeschulte Person verst ndlich sind Daneben hat die Dokumentation alle typischen und vorhersehbaren Fehler und M ngelsituationen darzustellen und deren Behebung zu beschreiben Das Handbuch f r Systembediener muss neben den wichtigsten Teilen des Systemhandbuchs insbesondere einen Arbeitsplan gegliedert nach t glichen w chentlichen monatlichen und j hrlichen Vorg ngen enthalten sowie alle Aktionen im Fehlerfall Sicherung Restore von Dateien und Datenbanken beschreiben Die technische Dokumentation besteht aus dem Data Dictionary Beschreibung der Datens tze und Datenfelde
299. nntes Konzept Seine Bedeutung und der jeweils angemessene Rechtsbehelf wird von den Umst nden abh ngig gemacht Hinsichtlich der Leistungsanforderungen werden zwei Typen von bad faith ausdr cklich genannt Abuse of a power to specify terms und interference with or failure to cooperate in the other party s performance 205 Rs 2d 237 b 206 Rs 2d 237 b 207 Rs 2d 204 When the parties to a bargain sufficiently defined to be a contract have not agreed with respect to a term which is essential to a determination of their rights and duties a term which is reasonable in the circumstances is supplied by the court Rs 2d 204 d in diesem Fall ist ein reasonable price at the time for delivery festzusetzen wie es auch w rtlich in 2 305 1 U C C hei t 209 Vgl Calamari Perillo a a O 11 38 S 457ff und 1 304 U C C Every contract or duty within the Uniform Commercial Code imposes an obligation of good faith in its performance and enforcement Definiert wird good faith in 1 201 20 U C C so honesty in fact and the observance of reasonable commercial standards of fair dealing Etwas literarischer wird sie auch als die Regel of the pure heart and the empty head bezeichnet Rs 2d 205 c Rs 2d 205 d N O 20 21 21 O 51 Kapitel 3 Rechtliche Rahmenbedingungen in den USA Ergibt sich anhand der vorstehend genannten Kriterien dass eine failure of
300. ns and before Preliminary Acceptance of any Application Licensee shall have the right to request from Licensor in writing a change to the Software System or Detailed Design Specifications If a change is requested Licensor shall within a reasonable time not to exceed twenty days inform Licensee in writing if such change would result in an extension of the Implementation Schedule or additional cost to Licensee giving the details thereof Licensor shall use the best efforts to respond as expeditiously as possible A change requested by Licensee requiring no extension or additional cost shall be considered effective if within twenty days Licensee consents in writing thereto A change for which an extension or increase has been specified by Licensor shall be considered effective if within twenty days thereafter Licensee consents in writing to such extension or increase Vil Zusammenhang zwischen Leistungsbestimmung und Einstandspflicht Bemisst man die Anforderungen an die zu erbringende Leistung an den Gew hrleistungsregeln so ergeben sich bemerkenswerte Unterschiede Bei AS wird die strikte bereinstimmung mit dem Scope of work verlangt 8 1 1 Compliance with Specifications Developer warrants that the Development Services and the Software will strictly comply with the descriptions including performance capabilities completeness specifications configurations and function that appear in the Scope of Work or in any Change Orde
301. ns from the respective Business Area Analysis Units designated by the parties during the Logical Phase of the MAS system development life cycle The Logical Phase work product deliverables that will define the MAS Design Baseline will be Process and Data Definitions Process Decomposition Diagrams Logical Process Model Data Flow Diagrams Entity Relationship Diagrams Logical Entity Model and Association Matrices Die Gemeinschaftlichkeit der Entwicklungsarbeit ergibt sich hier aus mehreren Gesichtspunkten Zum einen wird hier als selbstverst ndlich vorausgesetzt dass die Spezifikation von Daten und Funktionen von beiden Vertragsparteien stammt designated by the parties Weiterhin soll eine Entwurfsrichtlinie gemeinsam entwickelt und vom Management gepr ft und best tigt werden Schlie lich ist die gemeinsame Projektleitung also eine Verkn pfung auch auf personeller Ebene vorgesehen OD beschreitet einen anderen Weg Hier sind die Spezifikationen in einem detailliert angegebenen Verfahren bereits bei Vertragsabschluss festgelegt Der Softwarebesteller hat seine W nsche und Bed rfnisse ge u ert das Softwarehaus hat diese Vorgaben evaluiert und in eine detaillierte 267 Unter 1 1 1 2 268 Unter 1 1 2 29 1 1 2 Satz 1 lautet FDRI and PRODIGY agree to assign and make available one Project Manager each and other key personnel for the duration and completion ofthe MAS systems development MAS maintenance SMS opera
302. nsverwaltung ber die Maschinensteuerung egal ob mobiles Telefon Aufzug Gep ckabfertigungs oder Glasfertigungsanlage bis hin zur Flug oder Raumfahrtsteuerung und berwachung 14 Was individuelle Gestaltungsm glichkeiten jedoch nicht ausschlie en muss wie z B die Option der Makroprogrammierung zeigt 263 Kapitel 1 Allgemeiner Teil Die in dieser Form gezogene Grenzlinie zwischen Standardsoftware und Individualsoftware wird allerdings aus unterschiedlichen Gr nden verwischt So kann und muss auch Standardsoftware im konkreten Fall an die Bed rfnisse der Anwender angepasst werden Dies geschieht ber die Einstellung von Optionen sog Customizing wie in einem einfachen Fall der Auswahl der Sprache oder Darstellung Bei umfangreicheren Anwendungen kann die Anzahl der einzurichtenden Parameter durchaus im vierstelligen Bereich liegen Die Verkn pfung von Anwendungen erfordert dar ber hinaus eine Bearbeitung u U eine Neuerstellung von Schnittstellen um z B eine bernahme von Daten zu erm glichen etwa die Nutzung der Adressdaten aus einer Datenbank f r ein Rundschreiben Unter anderem zu diesem Zweck beinhaltet Standardsoftware nicht selten eine eigene Programmiersprache die individuelle Anpassungen erm glicht Individualsoftware bedient sich auf der anderen Seite in zunehmendem Ma e bereits vorhandener Programmelemente Objekte So machen sich Programmiersprachen die konzeptionell in der Verkn pfung immer wieder a
303. nterschiedlich ist der Wortlaut bei DaS DaS V gibt dem Softwarehaus vor in den Spezifikationen beschriebene nicht diesen Spezifikationen entsprechende Programme zu entwickeln 1 Software Development Pursuant to the terms of this agreement Vendor shall develop for Customer certain computer programs described in the Specifications set forth in Attachement A and related user level documentation the Software install the Software on Customer s computer equipment and make it ready for use Customer acknowledges that it has carefully reviewed Attachment A which fully sets forth all of customers requirements and that Vendor s compliance with it shall constitute satisfactory performance under this agreement 61 Kapitel 4 Empirischer Befund in den USA DaS U macht bereits in der Praambel deutlich dass es um die Lieferung von an den Bed rfnissen und Anforderungen des Bestellers orientierter Software gehen soll Vendor desires to provide application software to User that meets User s needs and requirements Muster die sich am Interesse des Softwarehauses orientieren bevorzugen also eine Service L sung wohingegen die am Softwarebesteller ausgerichteten Muster die Lieferung supply provide eines Systems pr ferieren Il Bestandteile der Lieferung Was Bestandteil der Lieferung sein soll ist bei AS explizit in dem Anhang SCOPE OF WORK dargestellt II DELIVERABLES Developer will deliver
304. o day operational changes in the processing services specified in Exhibit 15 and otherwise provided for under this Agreement e g print suppression operational schedule changes may only be made with approval of the Project Managers Substantial changes in the processing services provided under this Agreement e g eliminating the microfiche provided for in Exhibit 17 processing changes requiring coding may only be made by written amendment hereto F r die Durchf hrung von nderungen ist kein besonderes Verfahren vorgesehen Es wird vielmehr einleitend die Verteilung der Priorit ten im Falle von nderungen dem Softwarebesteller zugeordnet und die Notwendigkeit begr ndet nderungen nur nach vorheriger Sch tzung der Auswirkung auf Kosten und Zeitplan durch das Softwarehaus einzuleiten Der Tendenz zur gemeinschaftlichen Projektabwicklung folgend wird ber nderungen gemeinsam entschieden und diese werden auf Basis eines gemeinsam zu entwerfenden Projektplans durchgef hrt Change Control All proposed changes to SMS and MAS shall be prioritized by PRODIGY provided however that all changes to SMS and or to the MAS Design Baseline shall be mutually agreed upon and no changes shall be built into either SMS or MAS without prior estimation by FDRI of any cost 282 Unter 1 1 6 283 Unter 2 1 6 Change orders als Unterpunkt von 2 1 Processing Services 284 Unter 1 1 3 92 Kapitel 4 Empirischer Befund in den USA and or ti
305. of its obligations and after notice to Vendor of such breach and a reasonable opportunity to cure such breach Customer may at its option to be exercised in its sole discretion and in additional to any other rights or remedies to which Customer may be entitled hereunder or at law or in equity a Require that Vendor return all amounts previously paid by Customer to Vendor hereunder within five 5 days after notice to Vendor from Customer demanding such payment and upon such payment title and risk of loss to the System shall pass to Vendor or b Upon notice to Vendor terminate further performance by Vendor of all or any portion of Vendors obligations hereunder and at Vendor s expense seek assistance from other persons or entities in completing performance of such obligations 274 Diese Klausel ist nicht als Force Majeure Regelung zu verstehen Force Majeure ist im Vertrag gesondert unter 5 3 geregelt 275 Im Vertrag finden sich an anderer Stelle Regelungen zu Gew hrleistung und Haftung 5 und 6 Diese sind allerdings mit den blichen weitgehenden Ausschlussbestimmungen Disclaimer versehen 5 1 a E 6 4 und enthalten auch eine Haftungsregelung des Softwarebestellers bei eigener Fahrl ssigkeit 5 2 276 Im Rider unter 12 und 14 bei Nr 13 zeigt sich einmal mehr dass es im amerikanischen Recht am einer den 631ff vergleichbaren gesetzlichen Auffang Regelung fehlt 89 Kapitel 4 Empirischer Befund in den USA
306. olgenden als RB V und RB U bzw DaS V und DaS U bezeichnet Die Entw rfe von AS DS und FL werden im Folgenden demgem auch zusammengefasst als neutrale Entw rfe bezeichnet Das Softwarehaus wird unterschiedlich bezeichnet Als Licensor RB V und RB U der Softwarebesteller ist der Licensee als Vendor DaS V und DaS U wobei der Softwarebesteller bei DaS V Customer und bei DaS U User hei t oder als Developer bei DS AS und FL wobei der Softwarebesteller bei DS mit XXXXX bei AS als client und bei FL als customer bezeichnet wird 38 Raysman Richard Brown Peter Computer Law Drafting and Negotiating Forms and Agreements Lsbl New York 2003 Simon David F Computer Law Handbook Philadelphia 1990 Slater Amy in California Transaction Forms Westlaw Database 9 59 2003 Savage Diane W in Nichols Cyclopedia of Legal Forms Annotated Westlaw Database 2 3191 2002 Unbekannter Autor in Florida Jur Forms Legal and Business Database 20B 1 2003 289 Bei Raysman Brown ist das User orientierte Muster auf eine grunds tzliche Neuerstellung das Vendor orientierte Muster dagegen auf die Anpassung einer bereits vom Softwarehaus entwickelten Software ausgerichtet 59 Kapitel 4 Empirischer Befund in den USA l Vertragsart Aus der Vertragsbezeichnung lassen sich nur begrenzte Schl sse f r die Leistungsbestimmung ziehen RB sprechen von Software Development and License Agreement AS und DaS U von Software
307. ollowing the report Any uncorrected delays or problems during the report period and their causes shall also be set forth Progress meetings shall be held in person or by conference call on Monday of each week unless rescheduled by agreement and minutes thereof prepared by User and circulated to Vendor RB U sieht zwei Konferenzen mit dazugehoriger Berichtspflicht pro Monat vor 4 4 Progress Meetings Twice each month there shall be a meeting to discuss the progress of the projects At such meetings the Licensor Project Manager shall present a written report to Licensee with respect to project status and progress Such report shall include a summary of the accomplishments and difficulties during the prior reporting period and the anticipated results during the next reporting period DaS U bietet f r den Projektfortgang nach Erstellung der Spezifikationen bei DaS U Design Document genannt ein unverkennbar zu Lasten des Softwarehauses ausfallendes Verfahren an W hrend das Softwarehaus zahlreiche Pflichten treffen werden dem Softwarebesteller im Rahmen der Projektphasenbeschreibung zus tzliche L sungsm glichkeiten vom Vertrag einger umt 243 S o S 66 Nr 2 a DaS U 69 Kapitel 4 Empirischer Befund in den USA 3 Project Phases a Phase System Definition i ii The Design Document shall be presented by Vendor to user for review and comment Vendor shall modify supplement or cha
308. ommen die Phasen der Entwicklung in eine logische Abfolge zu bringen Im Ergebnis besteht weitgehend bereinstimmung hinsichtlich der erforderlichen Arbeitsschritte wie sich anhand zweier Phasenmodelle zeigen l sst 22 Heinrich a a O S 43 22 Zehnder a a O S 59f Eschbach a a O S 140 Love schreibt dazu instruktiv Trotz genauester Planung geschieht immer wieder das Unerwartete a a O S 189 24 Was eine Folge der Unsichtbarkeit und F gsamkeit so Brooks Vom Mythos des Mann Monats Bonn 1987 S 102 von Software ist 25 Eine anschauliche bersicht ber 12 sequentielle Vorgehensmodelle findet sich bei Kargl Herbert Management und Controlling von IT Projekten M nchen Wien 2000 S 75 2 Hansen Hans Robert Neumann Gustav Wirtschaftsinformatik I Grundlagen betrieblicher Informationsverarbeitung 8 Aufl Stuttgart 2001 S 204f 7 Ausschnitt aus einer umfangreichen bersicht nach Kargl a a O S 75 12 Kapitel 2 Softwareentwicklung in der Praxis Planung Projektdefinition Definition Ist Analyse Entwurf Sollkonzept Implementierung Realisierungsplanung Abnahme Einf hrung Software Entwicklung Wartung und Pflege Systemeinf hrung Balzert 1982 Walter 1992 In der Praxis zeigte sich dass die einzelnen Abschnitte nicht strikt voneinander zu trennen sind Sie Uberlappen sich vielmehr und m ssen
309. omputer or its memory Supplier shall immediately advise Company in writing upon reasonable suspicion or actual knowledge that the Software provided under this Agreement may result in the harm described above Supplier shall indemnify and hold Company and its customers harmless from any damage resulting from Supplier s failure to comply with this paragraph Die weitestgehende Bestimmung findet sich bei OD Im Hauptvertrag wird im wesentlichen eine Abgrenzung von Drittprodukten und der nach dem Vertrag herzustellenden Software vorgenommen und die diesbez gliche Einstandspflicht ausgeschlossen 288 Unter Warranty in Section Il im Anschluss an das Zitat findet sich der bliche Ausschluss aller sonstigen Einstandspflichten EXCEPT AS EXPRESSLY SET FORTH IN THIS SUBSECTION TITLED WARRANTY SUPPLIER DISCLAIMS ALL WARRANTIES EXPRESS AND IMPLIED INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTY OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 28 Im Purchase Agreement unter 14 Warranties 94 Kapitel 4 Empirischer Befund in den USA a In addition to any express warranties set forth herein Customer may be entitled to the benefit from certain limited warranties provided directly by the manufacturers owners publishers or distributors of these products Vendor assumes no liability for nor responsibility under these third party warranties unless such liability or responsibility shall be specifically set forth herein b C
310. on sachlichen Kriterien sondern ausschlie lich von der Machtposition der Parteien herr hrt Ob zudem durch Verhandlungsmacht durchgesetzte Vertragsbedingungen bei der ohnehin nicht unerheblichen Gefahr des Scheiterns eines Softwareprojektes geeignet sind eine tragf hige Grundlage f r eine Zusammenarbeit der Parteien zu bilden darf mit guten Gr nden bezweifelt werden 295 berspitzt formuliert Das Softwarehaus muss herausfinden was der Softwarebesteller braucht 96 Kapitel 4 Empirischer Befund in den USA Die Muster gehen durchgehend von einem mehrstufigen Verfahren zur Erarbeitung der Spezifikationen aus Der erste Schritt besteht in einer Ermittlung der Anforderungen Die Durchf hrung des zweiten Schrittes der von diesen Anforderungen zur technischen Spezifikation f hrt wird in fast allen Mustern dem Softwarehaus zugeordnet Die der Implementation vorgelagerte Pr fung der Spezifikation wird in vier von sieben Mustern als Aufgabe des Softwarebestellers betrachtet Eine einheitliche Ausrichtung danach welche Partei sinnvollerweise die eine oder andere Aufgabe bernehmen sollte ist nicht erkennbar Der Offenheit des Ergebnisses hohe Ergebnisvarianz stehen an anderer Stelle der Praxisbeispiele hier hinsichtlich des Projektteams der Systemverf gbarkeit und der Berichtspflichten genaue Vorgaben gegen ber und es werden die Elemente der gemeinschaftlichen Leistungserbringung betont Wo das Ergebnis klar bestimmbar scheint
311. orbehaltlich etwaiger Nacherf llungsanspr che das Erf llungsstadium und der Anspruch auf den Werklohn ist nunmehr unabh ngig vom weiteren Schicksal des Werkes Es findet eine scharfe seiner Sachkunde ausgesucht AnwK Raab Rn 15 Eine Ausnahme ergibt sich aus 434 Abs 1 S 2 und Abs 2 BGB Danach sind ffentliche u erungen des Verk ufers Herstellers oder seiner Gehilfen aus der Werbung oder bei der Kennzeichnung f r die Soll Beschaffenheit grunds tzlich zu ber cksichtigen Auch kann eine unsachgem e Montage oder mangelhafte Montageanleitung zu einem Mangel f hren Eine Entscheidung die darin begr ndet liegt dass der Unternehmer bei der Werkerstellung auf Leistungshindernisse mit der Folge gr erer Unsicherheit auf seiner Seite sto en kann und zudem ber die berlegene Sachkunde bei der sinnvollen Art der Nacherf llung verf gt Bamberger Roth Voit 8 631 Rn 2 Schneider Handbuch a a O S 1114 gemildert werde das Risiko allerdings durch das Verweigerungsrecht des Unternehmers gem 635 Abs 3 und 275 Abs 2 BGB bei grobem Missverh ltnis des Aufwandes zum Leistungsinteresse bzw unverh ltnism igen Kosten S 1117 Wobei dies nur f r die F lle gilt in denen der geschuldete Erfolg in der Herstellung Wartung oder nderung einer Sache oder in der Erbringung von Planungsleistungen hierf r einem Bauwerk oder entsprechender Planungs oder Uberwachungsleistungen besteht Vgl AnwK Raab
312. orderungen mit 13 1 der am h ufigsten genannte Grund f r den Abbruch von Software Projekten nach Rupp beruhen 65 der schwerwiegenden Fehler in Programmen auf Unzul nglichkeiten in der Anforderungs Analyse a a O S 12 nach Zehnder ist der otandardfehler in der Konzeptphase eine zu breite oder zu schmale Planung d h es werden zu viele Details erfasst oder es wird nur ein Weg als der richtige angenommen a a O S 59f Etzel Heilmann Richter erl utern anhand eines instruktiven Beispiels wie Missverst ndnisse bei der Bestimmung der Leistung zu einer hohen Gef hrdung des Projekterfolges f hren k nnen a a O S 29ff vgl auch Eschbach a a O S 154 V A Vyssotzky Commonsense in designing testable software nach Brooks Mythos S 124 118 Unsuccessful software projects fail in most cases because the software does not fit adequately to the needs of the people using it so Fisher a a O in seinem Vorwort S IX Ebenso deutlich auch Brooks Eine sorgf ltige Definition der Funktion und eine ebenso sorgf ltige Spezifikation sind die Grundlage des Erfolgs Mythos S 124 vgl auch Rupp a a O S 25 119 Mythos S 137 11 oO 11 N Esq Kapitel 2 Softwareentwicklung in der Praxis Die Option eines Projektabbruchs also die Frage ob das Projekt fortgesetzt werden soll ist in diesem Zusammenhang immer wieder zu stellen weil derAbbruch sich als die bessere Alternative erweisen kann
313. ordnung zu entziehen Dort wo sie Ber cksichtigung findet fallen die Antworten insoweit einheitlich aus als der Zeitpunkt jedenfalls nicht in einer fr hen Phase des Projektes liegt Ihm vorgelagert ist die Ist Analyse und die grobe Festlegung des Sollzustandes Konzeptionell und logisch nachgelagert ist jedenfalls die Phase der Implementierung Das Pflichtenheft wird also regelm ig im Stadium zwischen Sollkonzept und Implementation erstellt Der genaue Zeitpunkt scheint ma geblich davon abzuh ngen wieviel Unw gbarkeit die Vertragspartner zum Zeitpunkt der Festlegung in Kauf zu nehmen und wie flexibel sie mit allf lligen nderungen umzugehen bereit sind Hinsichtlich der Zust ndigkeit f r die Erstellung des Pflichtenheftes stellt sich die in der Rechtswissenschaft gef hrte Diskussion ber die Abgrenzung von Verantwortlichkeiten des Softwarehauses und des Softwarebestellers nicht mit vergleichbarer Sch rfe Da der Softwarebesteller seine Bed rfnisse am besten kennt und andererseits das Softwarehaus bei der informationstechnischen Umsetzung einen Wissensvorsprung besitzt ist der Planungsprozess durch Kooperation bestimmt Die Einbeziehung des 57 So z B im ansonsten denkbar ausf hrlichen V Modell 88 Franz a a O S 65 72 der ausdr cklich mehrere m gliche Zeitpunkte benennt S 141 Maymon Cave a a O S 50 85 Love a a O S 120 Suhl Blumstengel in Fischer Herold Danglmayer Nastansky Suhl
314. orliegt und der Richter als Subsumtionsautomat tatig wird Auch wenn sich dies als Illusion herausstellt weil die notwendige Schematisierung zwangsl ufig einen Verlust an Begriffssch rfe zur Folge hat so bleibt der Grundgedanke des deutschen Rechtes doch dass der Jurist das Sozialgeschehen von Normen her aufzugliedern und zu verstehen sucht Die Rechtsfindung erfolgt durch Subsumtion nach Wortlaut Auslegung oder Gewohnheitsrechtss tzen und erst wenn sich hieraus nichts ergibt nach richterlicher Rechtssch pfung Bereits in der Anfang des 20 Jahrhunderts in der Wissenschaft gef hrten Diskussion wurden auf der Grundlage rechtsvergleichender Betrachtung mit anglo amerikanischem Recht allerdings Stimmen laut die eine freiere Judikatur forderten Gem Art 20 Abs 3 GG ist die Gesetzgebung an die verfassungsm ige Ordnung die vollziehende Gewalt und die Rechtsprechung an Gesetz und 86 Schlosser Grundz ge der Neueren Privatrechtsgeschichte 9 Aufl Heidelberg 2001 S 191 Coing in Staudinger Einl zum BGB 12 Aufl Berlin 1995 Rn 202ff Sehr anschaulich wird dies durch die Modellkodifikation des Civil Law dem Code Civil Hier ist es dem Richter gem Art 5 ausdr cklich untersagt anl sslich einer Entscheidung allgemeine und regelnde Ausf hrungen vorzunehmen Das preu ische ALR von 1794 bestimmt in seiner Einleitung in 46 Bey Entscheidungen streitiger Rechtsf lle darf der Richter den Gesetze
315. pon be deemed amended to provide the same terms to Licensee DaS U geht insofern dar ber hinaus als diese Beg nstigungspflicht sich auch auf die Softwarepflege und die Unterst tzung sowie neu entwickelte Software bezieht 24 Most favored User Vendor shall not charge a price for System maintenance and support which is in excess of that charged to any other customer for comparable services and Vendor shall inform User of and make available to User for license at a reasonable fee not to exceed that charged to any other person any newly developed software which User may find useful to its business operations V Besondere Pflichten des Softwarebestellers Besondere Pflichten werden dem Softwarebesteller in den Mustern DaS V und RB V auferlegt Bei DaS V erfolgt dies im Zusammenhang mit Kundigungspflichten bei der Regelung von verspateten Leistungen Wirkt der Softwarebesteller nicht in angemessener Form mit kann sich das Softwarehaus vom Vertrag l sen bzw ist bei verspateter Leistungserbringung entschuldigt T2 Kapitel 4 Empirischer Befund in den USA 8 Default Vendor may terminate the License in the event of a default by customer Events of default include but are not limited to c Customer s failure to provide reasonable assistance and cooperation to Vendor 3 Fee If Vendor is delayed or prevented from performing this Agreement by any cause beyond its reasonable control including but not
316. posal Randnummer Restatement Rechtsprechung Seite Satz siehe auch Subscription Management Systems siehe oben sogenannte r siehe unten Softwareentwicklung Software Requirement Specification Softwareentwicklung Tabelle unter anderem und hnlich Uniform Commercial Code United Nations United States of America unter Umst nden Urteil vom Uniform Computer Information Transactions Act United Nations Commission on International Trade Law Urhebergesetz und so weiter versus vor allem Vertragsbedingung vergleiche Format zur digitalen Speicherung von Audiodaten WestLaw Juristische Datenbank Wertpapier Mitteilungen Zeitschrift X Dissertation Softwareentwicklungsvertrage Abk rzungen Z z B ZKM ZIP zum Beispiel Zeitschrift fur Konflikt Management Zeitschrift fur das Wirtschaftsrecht und Insolvenzpraxis Zeitschrift Kurzel fur Muster und Vertrage AE AS BVB DaS DaS U DaS V FDRI FL FP GL KO Ma MiN MiO OD RB RB U RB V SN B SN S SO SuS Softwareentwicklungsprojekt zwischen einem Telekommunikationsunternehmen in New Jersey American Telephone and Telegraph Company und einem Softwarehaus in Colorado Evolving Systems Inc Musterentwurf von Amy Slater Musterentwurf von Bartsch Besondere Vertragsbedingungen BVB Erstellung Musterentwurf von David F Simon Musterentwurf von David F Simon User Oriented Musterentwurf von David F Simon Vendor Orien
317. r nkte Nutzung zu erwerben 4 1 3 Macht der Besteller von dieser M glichkeit Gebrauch dann tritt ein f nfj hriges Verbot des Verkaufes an Wettbewerber in Kraft 4 1 3 b iii und das Softwarehaus muss bei der l ckenlosen bertragung was einer vollst ndigen bertragung des Know Hows ohne Unterbrechung des produktiven Einsatzes der Software entspricht mitwirken 4 1 3 d 1 1 8 2 b Wenn das Softwarehaus dieser Einordnung widerspricht wird ein spezielles Einigungsverfahren in Gang gesetzt das wenn sich die Parteien nicht einigen k nnen in ein schiedsgerichtliches Verfahren m ndet 81 26 a Kapitel 4 Empirischer Befund in den USA der unter Statement of Work wie folgt wiederholt und erganzt wird STATEMENT OF WORK Supplier shall provide the Services described in the Authorization Letter and deliver the Pre existing Software and the Developed Software collectively referred to as Software and all other Deliverables described in the Authorization Letter to Company at Company s location in accordance with the Work schedule set forth in the Authorization Letter Bei OD werden drei Leistungsbestandteile unterschieden TRANSACTION AND SCOPE Vendor agrees to provide to Customer and Customer agrees to acquire from Vendor the following a SOFTWARE The software listed in Schedule C b SERVICES Services as listed in Schedule D c SUPPORT Support as listed in Schedule E In dem an den Interessen de
318. r zur ck Gleichwohl stellt der Gesetzgeber mit dem Schuldrecht eine Regelungssystematik zur Verf gung die sich bem ht eine Grundlage und ein Auffangbecken f r Vertr ge jeder Art zu bieten Es steht den Gestaltern eines Vertrages danach zwar die M glichkeit offen dessen Inhalt nicht jedoch die Einordnung in die Systematik verbindlich festzulegen Die rechtlichen Rahmenbedingungen f r Softwareentwicklungsvertr ge h ngen im deutschen Recht ausschlaggebend davon ab in welche Vertragskategorie sie einzuordnen sind Ill Auslegungsgrunds tze Die Grunds tze f r die Auslegung von Vertr gen finden sich im deutschen Recht im BGB in den 133 und 157 BGB Diese erg nzen sich und sind 307 Ausf hrlich hierzu Schmidt in Esser Josef Schmidt Eike Schuldrecht Band Allgemeiner Teil Teilband 1 8 Aufl Heidelberg 1995 11S 2ff S 3 308 Einschr nkungen kommen hier v a unter dem Gesichtspunkt des 20 GWB kartellrechtliches Diskriminierungsverbot f r marktbeherrschende Unternehmen in Einzelf llen gest tzt oder ersetzt durch 826 BGB Kontrahierungszwang bei rechtlicher oder tats chlicher Monopolstellung in Betracht vgl Hopt in Baumbach Hopt Handelsgesetzbuch 31 Aufl M nchen 2003 Rn 6 f und 11 Einl Vor 343 Die sich aus den 134 138 BGB ergebenden Grenzen gelten demgegen ber unabh ngig von der Unternehmereigenschaft Hopt in Baumbach Hopt a a O Rn 4 zu Einl vor 1 die
319. r Betriebsfertigkeit 10 1 Herstellen der Betriebsfertigkeit durch den Anbieter 1 Falls dies im Erstellungsschein ES 1 1 2 vorgesehen ist stellt der Anbieter die Betriebsfertigkeit des Systems sicher Er erbringt hierbei insbesondere folgende Leistungen soweit sie im Erstellungsschein vorgesehen sind Installation des Lizenzproduktes Integration des Lizenzproduktes Migration von Datenbest nden Im Erstellungsschein k nnen weitere Leistungen aufgef hrt werden 2 Der Kunde wirkt hierbei in zumutbarer Weise mit Die Vertragspartner kl ren fr hzeitig welche Beeintr chtigungen eines bereits genutzten Systems im Rahmen der Herstellung der Betriebsfertigkeit zu erwarten sind 3 Die Herstellung der Betriebsfertigkeit gilt als Teil der Hauptleistung und wird mit dieser gemeinsam gem VB 16 abgenommen Inwieweit es sich hierbei v a was die Integration angeht um eine Option handeln kann ist angesichts des bei GL eingangs formulierten Vertragsziels von der Erarbeitung und Einf hrung einer auf den Kunden zugeschnittenen EDV L sung h chst fraglich Die Lauff higkeit zu erstellender Software in der technischen Umgebung des Bestellers ist ein wichtiger Planungsfaktor und dahingehende berlegungen d rften in den allermeisten F llen d h bei vorhandener EDV einen integralen Bestandteil der ersten Projektschritte bilden F r die Problematik der bernahme von Altdaten gilt prinzipiell dasselbe wobei angesichts der
320. r Softwarebesteller auf die nderung trotz ge u erter Bedenken des Softwarehauses besteht 12 2 Ausf hrliche Pr fung Falls eine umfangreiche Pr fung notwendig ist ob und zu welchen Bedingungen eine nderung durchgef hrt werden kann gibt der Anbieter dem Kunden einen entsprechenden Hinweis Wenn der Kunde dem Anbieter einen Pr fauftrag erteilt hat der Anbieter das Recht f r diesen zus tzlichen Aufwand eine Zusatzverg tung nach dem Erstellungsschein abzurechnen ES 5 5 Die Vertragspartner legen einvernehmlich die Frist fest innerhalb derer die Ergebnisse der Pr fung schriftlich vorgelegt werden 12 3 Anpassung von Verg tung Zeitplan u a 1 Falls und soweit die Umsetzung eines nderungsverlangens eine Anpassung der vertraglichen Regelungen insbesondere des Zeitplanes der Verg tung oder der Funktionspr fung n tig werden l sst hat der Anbieter ein entsprechendes Anpassungsverlangen mitzuteilen 2 Falls das Anpassungsverlangen nicht innerhalb von 30 Arbeitstagen nach Zugang des endg ltigen nderungsverlangens ggf innerhalb der nach VB 12 2 Satz 3 festgelegten Frist erfolgt ist eine sp tere Anpassung wegen des nderungsverlangens ausgeschlossen 3 Die Parteien einigen sich innerhalb von 10 Arbeitstagen nach Zugang eines Anpassungsverlangens ber die nderung der Leistungsbeschreibung und die sonstige Anpassung des Erstellungsscheines 12 4 Arbeitsstopp F hrt der Anbieter bei Zugang des nderungsverlangens Arb
321. r mit Format und Kommentar Kommentaren im Sourcecode wie sie in den beiliegenden Beispielen Beilage 6 exemplarisch dargestellt sind und aus der Schnittstellenbeschreibung zu den nicht im Sourcecode gelieferten Modulen ae Erkennbarer Schwerpunkt der Dokumentationslieferung ist es die Verwertbarkeit der Unterlagen in der Praxis sicherzustellen Fur die 175 Kapitel 6 Empirischer Befund in Deutschland technische Dokumentation akzentuiert der letzte Absatz dies indem er die konkrete Gestaltung der Kommentare nicht dem Softwarehaus uberlasst sondern eine eigene Vorgabe in Form von Beispielen liefert Der Entwickler soll auf diese Weise daran gehindert werden die Erlauterung seiner Arbeit in f r Dritte unverst ndlicher Form vorzunehmen Bei MiN ist die Lieferpflicht der Software nicht ausdr cklich benannt Unter der etwas irref hrenden berschrift 12 Dienstleistungen hei t es Der AN stellt dem AG nach Vertragsschluss ein lauff higes Standardsystem mit Datenbank und 10 PC Arbeitspl tzen zum Probebetrieb zur Verf gung damit das System kennen gelernt voreingestellt und mit Stammdaten best ckt werden kann Eine Lieferpflicht ergibt sich dann aber aus 13 Fehlerbeseitigung und hier unter 13 4 Updates und Upgrades Gegenstand des Wartungsvertrages ist ferner die kostenlose Lieferung neuer verbesserter und erweiterter Programmversionen Updates und Upgrades der Software
322. r with the source code shall provide a competent programmer with sufficient information to maintain and enhance the system In der am Softwarehaus orientierten Variante DaS V findet sich die Tendenz den Lieferumfang zu begrenzen bzw zumindest klar zu definieren indem eine vollstandige Beschreibung zusatzlicher Software oder Dokumentation in Anhangen gefordert wird 1 Software Development Any different or additional software or documentation developed by Vendor for Customer or services to be provided by Vendor to Customer shall be fully described in additional Attachments which shall also be subject to the terms and conditions of this Agreement and such other terms and conditions as Vendor and Customer shall agree upon in each respective Attachment Der Umfang der Dokumentationslieferungspflicht ist durch die Begrenzung auf user level auf einem eher zur ckhaltenden Niveau angesiedelt 4 Training and Documentation 63 Kapitel 4 Empirischer Befund in den USA Vendor shall provide to Customer user level documentation for the Software Additional training and support services and documentation shall be provided to Customer upon Customer s written request at Vendor s then current hourly rates plus expenses Bei FL ist die Lieferpflicht grunds tzlich an den Terminplan gekn pft 2 01 Delivery and Installation Immediately on the completion of each development milestone set forth at Exhibit B Developer shall d
323. ralmodell gibt jedoch bereits durch seine graphische Gestaltung einen Hinweis auf die zyklische Entwicklung innerhalb des Projektes Es ist durch eine Vorgehensweise gepr gt die als Iteration bezeichnet wird ein Verfahren zur Verbesserung von N herungsl sungen durch st ndiges Wiederholen des gleichen Ablaufes Nicht jeder weitere Schritt f hrt dabei zwangsl ufig n her zum Ziel Fertigstellung der Software Es k nnen vielmehr unvorhergesehen Risiken 15 Kapitel 2 Softwareentwicklung in der Praxis wie Kostensteigerungen auftauchen oder Umstellungen in der weiteren Planung wie eine Verlangerung der Projektdauer erforderlich werden Es kann sich also herausstellen dass der aktuell zu veranschlagende Aufwand und angestrebte Fertigstellungszeitpunkt deutlich von der urspr nglichen Prognose abweichen und das Ziel damit in weite Ferne r ckt Besondere Aufmerksamkeit verdient das im Spiralmodell explicit vorgesehene sog Prototyping Bei dieser Vorgehensweise wird bereits zu einem fr hen Zeitpunkt ein Prototyp entwickelt und in Abstimmung mit den Anwendern stufenweise verfeinert Dies f hrt naturgem dazu dass die Phasen Entwurf und Implementation eng miteinander verzahnt werden und teilweise parallel ablaufen Das letzte hier darzustellende Modell ist das V Modell Es ist vom Ende der 80er bis zum Anfang der 90er Jahre initiiert vom Deutschen Bundesministerium f r Verteidigung zur Optimierung der Softwareentwickl
324. rammcodes gelesen werden so dass bei vielen zu erwartenden nicht die Programmlogik betreffenden nderungen in den Anforderungen an die Anwendung nur Tabellen aber keine Zahlenwerte in Programmen ge ndert werden m ssen 8 die gem den Programmierrichtlinien des Auftragnehmers Beilage 5 erstellt und gewartet wird 9 die bei der Produktionssoftware vom Konzept einer relationalen Datenbank ausgeht auf die mit der Sprache SQL zugegriffen wird 10 die nicht nur vom Programmierer getestet wird 11 bei der nderungen und anwendungsspezifische Anpassungen so durchgef hrt werden dass solche nderungen klar erkennbar sind und die Versionsf higkeit nicht verloren geht 12 die Transaktionen auf zentralen Datenbanken ORACLE mit Beginn und Endbefehl f r das Datenbanksystem transparent macht 13 die die logische Zusammengeh rigkeit von Tabelleneintr gen durch explizite Aufnahme der foreign keys transparent macht 14 die in der Produktionssoftware keine Mechanismen enth lt die die Benutzung durch den Anwender zeitlich begrenzen oder den Wechsel zwischen verschiedenen Arbeitspl tzen erschweren Kopierschutz 15 die die bernahme von Daten in die vorhandenen PC Systeme des Auftraggebers zwecks Auswertung mittels Tabellenkalkulation erm glicht Interessant ist hier zun chst die Aussage zur unvermeidbaren Fehlerhaftigkeit von Software in Abs 1 Die unter Abs 2 Nr 1 und 2 aufgef hrten Punkte k nnen als Generalklauseln zur Sich
325. rater verstanden 202 Kapitel 7 Vergleichende Darstellung in beiden Rechtsordnungen und entsprechenden Vertragen eingebunden wird In den restatements wird eine Andeutung im Hinblick auf Mitwirkungspflichten im Kommentar dahingehend formuliert dass eine failure to cooperate in the other party s performance als bad faith i S des 205 ausgelegt werden kann Geht man von einer Anwendbarkeit des U C C aus so findet sich eine Norm die ebenfalls von cooperation spricht in 2 311 4 Es wird der Grundstein f r eine Entschuldigung m glicher Versp tung bzw aus Vertragsbruch herzuleitendem Schadensersatz gelegt Die Rechtsprechung sanktioniert demgem das Ausbleiben von Mitwirkungshandlungen im Einzelfall wie oben dargestellt wobei dies auch vor dem Hintergrund des Grundsatzes geschieht dass Rechtsfolgen aus einem Vertragsbruch nur geltend machen kann wer selbst vertragstreu ist Das BGB fordert nunmehr in 241 Abs 2 ausdr cklich eine gegenseitige R cksichtnahme und gibt in 324 ein korrespondierendes R cktrittsrecht 539 Rs 2d 205 Duty of Good Faith and Fair Dealing 2 Every contract imposes upon each party a duty of good faith and fair dealing in its performance and its enforcement S o Kapitel 3 S 45f und 51ff 5 2 311 U C C Options and Cooperation Respecting Performance 2 1 An agreement for sale which is otherwise sufficiently definite subsection 3 of Section 2 204
326. rbeitung seitens des AN handelt werden die Vereinbarungen hinsichtlich der Verg tungspflichtigkeit und der Verschiebung von Terminen hinf llig Die Vertragspartner nehmen je nach Erkennbarkeit dieses Fehlers eine angemessene Anpassung des Gesamtvertrages und dabei der Verg tung in Analogie zur Verzugsregelung vor 2 4 6 Hinsichtlich etwaiger Minderungen und hinsichtlich des Mehraufwands im Zusammenhang mit Angeboten wird der AN jeweils einen Abgleich mit der Projektsch tzung siehe 1 2 vornehmen und diese dann wenn 164 Kapitel 6 Empirischer Befund in Deutschland die Anderung Vertragsbestandteil wird fortschreiben Kommt keine Einigung ber die nderung zustande obwohl der AN rechtzeitig ein Angebot unterbreitet hat ist der AN nicht berechtigt au erordentlich zu k ndigen Er hat lediglich das Recht nach wie vor nach 649 BGB vorzugehen also eine ordentliche K ndigung auszusprechen Beruht eine nderung auf einem Fehler aus der Sph re des Softwarehauses insbesondere im Pflichtenheft so ndert dies nach diesem Muster nichts an Verg tung und Terminen Dies ist rechtlich durchaus nachvollziehbar ndert allerdings nichts an dem faktisch m glicherweise erheblichen Mehraufwand Dies Projekt kann dadurch in eine Krise geraten f r die hier keine L sung vorgesehen ist Im softwarehausfreundlichen Parallelentwurf SN S f llt die Regelung etwas k rzer aus 3 nderungen der Leistungen 3 1 nde
327. rd h ufig erst bei genauem Studium aus dem Zusammenhang ersichtlich in welcher Phase sich das Projekt bei Vertragsschluss tats chlich befindet Das Spektrum des Projektstandes reicht in den Mustern von Null d h die Parteien treffen sich auf Basis einer mehr oder weniger konkretisierten Idee seitens des Softwarebestellers bis hin zu dem Vorliegen einer ausgefeilten Formulierung fachlichen Feinspezifikation oder einem bereits gepr ften Pflichtenheft Keine n here Leistungsbeschreibung Vorliegen einer Aufgabenstellung Vorliegen eines Pflichtenheftes Konkretisierungsgrad Vorliegen Fachliches Feinkonzept y Da die Begriffe nicht einheitlich verwendet werden kann das Pflichtenheft hnlich konkrete oder sogar detailliertere Angaben als das Feinkonzept bzw die Feinspezifikation enthalten Wird von der Vertragsabwicklung auf Basis eines Pflichtenheftes ausgegangen so ist dieses teilweise vom Softwarebesteller teilweise vom 189 Kapitel 6 Empirischer Befund in Deutschland Softwarehaus und teilweise gemeinsam zu erstellen in allen Praxisbeispielen wurde es vom Softwarebesteller vorgelegt Hat der Softwarebesteller die Aufgabe der Erstellung des Pflichtenhefts bernommen ist in den Mustern eine korrespondierende Pflicht von der Beratung bis hin zur Pr fung vorgesehen bernimmt sie das Softwarehaus so ist teilweise eine Abnahme durch den Softwarebesteller geforde
328. rechtsreform erweiterten Fehlerbegriffes u erst wichtig den Leistungsumfang genau zu vereinbaren Das Schwergewicht des Vertrages sollte bei der eigentlichen Leistung und deren Spezifikation liegen Die Notwendigkeit genauer Zieldefinition im Hinblick auf die zu erbringenden Funktionen den Aufwand und die Zeit sei auch in der IT Branche vorhanden Teilweise wird das Vorliegen einer werkvertraglichen Einigung ausdr cklich an das Vorhandensein genauer Leistungsbestimmung gebunden 2 Zeitpunkt und Anforderungen Als Zeitpunkt f r die Erstellung der Leistungsbestimmung wird in der Literatur eine h ufige Versp tung d h eine Formulierung nach Vertragsschluss diagnostiziert Es sei blich Spezifikationen erst im Projektverlauf vorzunehmen Die Realisierung weiche zudem h ufig von der anf nglich 388 Urteil v 14 08 87 CR 1988 S 214 399 Urteil v 18 11 88 NJW 1989 S 2625 Nach dem OLG N rnberg ist das Ergebnis h ufig fehlerbelastet U v 08 11 95 ECR OLG 213 S 799 400 Vgl Thewalt a a O S 128 m w Nachw Allgemein ist es bei einer individuellen Wertsch pfung erforderlich eine brauchbare und ersch pfende Leistungsbeschreibung zur Verf gung zu stellen M Ko Soergel 631 Rn 132 Sick a a O S 14 Dies sei eine der wichtigsten Aufgaben bei der Vertragsformulierung und verhandlung S 15 Schneider Handbuch a a O Vorwort S VI M ller Hengstenberg BVB EVB IT Computer
329. reibung von M ngeln Nach 3 Nr 1 Abs 2 S 2 hat der Softwarebesteller im Fall einer durch das Softwarehaus bem ngelten Leistungsbeschreibung unverz glich ber eine nderung der Leistungsbeschreibung 5 oder seiner Forderungen zur Vertragsausf hrung Nummer 3 zu entscheiden 158 Kapitel 6 Empirischer Befund in Deutschland Im Rahmen der Regelungen zur Gewahrleistung in 12 trifft den Softwarebesteller nach den BVB folgende Pflicht 4 Macht der Auftraggeber M ngel geltend teilt er dem Auftragnehmer mit wie sich die M ngel bemerkbar machen dabei m ssen die im Erstellungs schein festgelegten Unterlagen f r die M ngelbeseitigung zur Einsichtnahme oder Anforderung zur Verf gung stehen Ben tigt der Auftragnehmer weitere Unterlagen hat der Auftraggeber die Unterlagen unverz glich zur Verf gung zu stellen Dar ber hinaus hat der Auftraggeber den Auftragnehmer bei der M ngelbeseitigung in dem im Erstellungsschein festgelegten Umfang zu unterst tzen Die beiden wichtigen hier enthaltenen Elemente der Mitwirkungspflicht beziehen sich auf den Umgang mit Problemen im Projektverlauf Der Softwarebesteller ist dabei gefordert diese nach Verm gen zu konkretisieren und nach eigenen Kr ften bei der Abhilfe mitzuwirken sowie beispielhaft f r mangelhafte Leistungsbeschreibung unverz glich erforderliche Entscheidungen zu treffen VI Ver nderungen Change Management Das Change Management wird in alle
330. relle Unterschiede Spielr ume und ihre Verwendung Die Leistungsbestimmung in Softwareentwicklungsvertr gen vollzieht sich in einem von beiden Rechtsordnungen weitgehend unbeschr nkten Rahmen Diese Freiheit erstreckt sich allerdings vor allem im deutschen Recht nicht auf das Unterlassen der Leistungsbestimmung Wenn die Vertragsparteien einen Gesichtspunkt nicht geregelt haben z B ob eine Dokumentation zu erstellen ist oder ein Pflichtenheft zu liefern so wird eine entsprechende Pflicht konstruiert Die Erweiterung der Leistungsbestimmung wird dann durch die Gerichte vorgenommen Haben die Parteien dagegen eine Vereinbarung getroffen z B das Pflichtenheft werde vom Softwarebesteller vorgelegt so schlie t dies eine Intervention der Gerichte regelm ig aus Die Spielr ume k nnen sehr unterschiedlich genutzt werden wie im folgenden zu zeigen ist Dabei ist zun chst hinsichtlich der f r das deutsche Recht grundlegenden Weichenstellung bzgl der Einordnung von Software Stellung zu beziehen I Software ist keine Sache Software ist keine Sache Dieser so einfache Satz ist von Teilen der deutschen Literatur so schwer nachzuvollziehen Dabei ist schon die Art und Weise wie Begr ndungen f r die Sacheigenschaft gesucht werden ein deutlicher Hinweis auf die Fragw rdigkeit dieser Ansicht Warum m ssen abenteuerliche Konstruktionen gew hlt werden wo es viel einfacher ist die Grenzen des Sachbegriffes zu berschr
331. rform in accordance with all applicable Exhibits and shall be free of any defects which substantially affect the performance of the SMS System as developed under the Prior Agreement Softwarehaus represents and warrants that those MAS System enhancements developed by Softwarehaus in furtherance of this Agreement shall be free of any defects which substantially affect the performance of the SMS System as updated by the SMS System Enhancements Softwarehaus shall provide such warranties for the repair of errors or defects in the Work as may be provided in the Authorization Letter applicable to such Work Softwarehaus represents and warrants to Softwarebesteller that a the System will be capable of fulfilling all of Softwarebesteller s current and reasonably anticipated needs in an efficient and commercially desirable and competitive manner b there are no problems or defects including viruses known to Softwarehaus in the System c the System does not contain any limitations which would render the System unsuitable for use by Softwarebesteller in processing its own applications and those of its current divisions subsidiaries or affiliates or presently contemplated future divisions subsidiaries or affiliates d the System will operate and conform in all respects during the term hereof in accordance with the Performance Standards e the System will meet all applicable local state and federal codes laws regulations and tariff
332. richterstattung ber den Projektstatus verpflichtet 242 5 0 61 68 Kapitel 4 Empirischer Befund in den USA 2 7 Progress Reports Developer agrees to provide Client with monthly progress reports and a statement of Developer s fees and expenses incurred to date These progress reports are due on the fifteenth 15th day of each month for the prior month Each report will contain a description of the current status of the Software the time spent on Development Services during the month the tasks on which the time was spent the estimated progress to be made in the next month any problems encountered and their proposed solutions and Developer s estimated ability to meet milestones and other deadlines Noch weitergehende Formulierungen findet man bei den Softwarebesteller orientierten Mustern DaS U und RB U So werden bei DaS U u a konkrete Darlegungen zu den im Projekt tatigen Mitarbeitern verlangt 9 Progress Reports and Meetings Vendor shall submit monthly written progress reports to User on the first of each month Each report shall describe the work performed since the preceding report including but not limited to the development testing and installation status of each function of the system the names of each employee then working on the project and a description of the work performed by each listed employee during the report period The report shall also describe the work expected to be performed during the month f
333. rn Der Anderungsbedarf kann sich auch aus Kenntnissen ergeben die berhaupt erst im Projektverlauf gewonnen werden konnten Ein denkbarer Verlauf f r die Zielgenauigkeit ist in der folgenden Grafik abgebildet Zielgenauigkeit Zeitablauf Die Zielgenauigkeit wird hier mit Zeitablauf infolge des Informationszugewinns zun chst gr er das Ma des Zuwachses verlangsamt sich jedoch mit zunehmender Informationsdichte Der beste Zeitpunkt f r eine verbindliche Zieldefinition liegt demnach eindeutig nicht bei Projektbeginn 26 Neben den hier behandelten problematischen F llen gibt es auch Situationen in denen das Ziel dem Softwarehaus von Beginn an sehr pr zise vorgegeben werden kann Dies ist etwa bei der Programmierung technisch definierter Abl ufe der Fall Der Softwarebesteller legt dem Softwarehaus die definierten Eingangs und die definierten durch das Softwarehaus programmtechnisch zu erarbeitenden Ausgangsdaten vor 127 Es tritt ein berf tterungseffekt ein Die Vielzahl der hinzutretenden Informationen kann bei konstanten Verarbeitungsressourcen nicht bew ltigt verdaut werden Dies kann u U auch zu einem r ckl ufigen Verlauf der Kurve f hren d h die Zielgenauigkeit nimmt nicht zu sondern ab ESA Kapitel 2 Softwareentwicklung in der Praxis Die Verantwortlichkeit fur die Zieldefinition kann eindeutig weder dem Softwarehaus noch dem Softwarebesteller zugeordnet werden Ohne Kom
334. rojektmitarbeitern auf ein Mindestma beschr nken und einander vorher konsultieren Ein Projektleiter oder Mitarbeiter soll ausgetauscht werden wenn der Vertragspartner hierf r nachvollziehbare Gr nde vortragt GL und BA sehen besondere Regeln f r die Fehlerbeseitigung vor W hrend GL dies unter 17 Haftung f r Sachm ngel als eine Frage der Gew hrleistung ansieht verortet BA die entsprechende Regelung unter 25 Fehlerbeseitigung in den Abschnitt der Projektorganisation BA behandelt sie als der Abnahme in 26 nachgelagerte Bestimmung im Ergebnis inhaltlich ebenfalls als dem Bereich der Gew hrleistung zugeh rig GL 17 5 M ngelbeseitigung Rechtsfolgen 1 Der Anbieter beseitigt M ngel die im Abnahmeprotokoll festgehalten sind oder die vom Kunden innerhalb der Verj hrungsfrist gemeldet werden Anm Es folgen ausf hrliche Regeln zum einer M ngelmeldung folgenden Verfahren BA 1 Der AG meldet St rungen und Fehler unverz glich Die Meldung kann zun chst m ndlich erfolgen ist jedoch sp testens am bern chsten 148 Kapitel 6 Empirischer Befund in Deutschland Werktag schriftlich zu wiederholen Sie kann nur durch einen Projektleiter 11 Abs 2 abgegeben werden oder durch eine andere Person die die notwendigen Kenntnisse der Software und Qualifikation hat und dem AN als meldeberechtigt benannt wurde 2 Der AN unterst tzt den AG nach den Regeln dieses Vertrages bis zur Aufkl rung und Bese
335. rotokoll das die wesentlichen Er rterungspunkte und alle getroffenen Entscheidungen festh lt und das er dem AG unverz glich berl sst Das Protokoll wird im Rahmen der Zust ndigkeiten des jeweiligen Gremiums verbindlich wenn der AG nicht binnen f nf Werktagen schriftlich mit eigenem Formulierungsvorschlag widerspricht ber den Widerspruch wird in der n chsten Projektbesprechung verhandelt Zur Sicherstellung der Mitarbeiterqualifikation finden sich bei BA GL und in den BVB gesonderte Bestimmungen Bei GL werden entsprechende Erfordernisse kurz unter 5 Verg tung im Erstellungsschein angedeutet 9 4 2 Der Anbieter setzt Mitarbeiter mit folgender Qualifikation ein Weitergehend ist in den BVB neben der Qualit tsanforderung eine wenn auch nur ausnahmsweise zum Zuge kommende Einflussnahmem glichkeit auf Personalentscheidungen des Softwarebestellers vorgesehen 3 Leistungen des Auftragnehmers 4 Im Erstellungsschein kann die fachliche Qualifikation z B Projektleiter Systemprogrammierer der bei dem Erstellen der Programme einzusetzenden Arbeitnehmer festgelegt werden Wenn ein zur Vertragserf llung eingesetzter Arbeitnehmer der Auftragnehmers durch einen anderen ersetzt werden muss so geht dessen Einarbeitung zu Lasten des Auftragnehmers 516 BA sieht in 12 drei Gremien vor Teilprojektteams bestehend aus Teilprojektleitern von AN und AG Projektleitung bestehend aus allen Teil Projektleit
336. rs FL und DS verwenden demgegen ber abgeschwachte Formulierungen W hrend bei DS eine akzeptable Implementation der Spezifikationen und ein einj hriges Funktionieren gem der Spezifikationen verlangt wird 4 Warranty a Developer warrants that the Specifications will represent an acceptable implementation of the Functional Requirements Developer warrants that for a period of twelve 12 months after XXXXX s first commercial shipment of the Product excluding shipments for beta testing the Warranty Period the Product will perform in accordance with the Specifications sieht FL vor die Software m sse ebenfalls f r ein Jahr bez glich aller wesentlicher Aspekte mit den Spezifikationen und den 77 Kapitel 4 Empirischer Befund in den USA Ausf hrungsstandards bereinstimmen wobei nachtr gliche nderungen durch den Softwarebesteller ausgenommen sind 6 01 Limited Warranty Developer warrants for the benefit only of Customer that the Subject Programs shall conform in all material respects to the Specifications and Performance Standards except for subsequent modifications made at Customer s request Die ubrigen Muster fallen deutlich unterschiedlich aus je nachdem ob sie aus Sicht des Softwarehauses DaS V und RB V oder des Softwarebestellers DaS U und RB U formuliert sind Die erstgenannten verwenden bereinstimmend den Ma stab der substantiellen Ubereinstimmung DaS V unter 6 Warranty an
337. rsonelle Ver nderung bei den beteiligten Mitarbeitern mitteilen Die bliche Berichterstattung wird hier um eine gesonderte Informationspflicht bez glich der Mitarbeiter beim Softwarehaus erweitert Ein Einwirkungsrecht auf Personalentscheidungen ist damit nicht verbunden Der Softwarebesteller hat durch die bersicht ber den Personalbestand beim Vertragspartner aber ein Fr hwarnsystem an der Hand das ihm helfen kann m gliche Projektst rungen vorherzusehen V Besondere Pflichten des Softwarebestellers Besondere Pflichten des Softwarebestellers beschr nken sich in SuS auf eine kurze Regelung unter 2 Durchf hrung der Arbeiten 2 1 Der Partner wird auf Anfrage alle f r die Durchf hrung der X Software erforderlichen Ausk nfte rechtzeitig erteilen Dies wird vor allem daran liegen dass im Ergebnis die Entwicklung einer Standardsoftware Vertragsgegenstand und eine Integration in eine vorhandene Anwendungsumgebung nicht erforderlich ist Damit entf llt auch die Notwendigkeit Ressourcen in anderer Form als der Lieferung von Informationen zur Verf gung zu stellen Bei MiO und MiN verh lt sich dies anders weshalb hier ausf hrlichere Regelungen anzutreffen sind Bei MiO hei t es unter 8 Pflichten des Auftraggebers die Absatznummerierung wurde wieder erg nzt 1 Der Auftraggeber wird dem Auftragnehmer alle notwendigen Informationen zur Verf gung stellen soweit der Auftragnehmer
338. rt Die Terminologie ist in den Praxisbeispielen nicht eindeutig Eine im Projektverlauf zunehmende Konkretisierung ist in einem Muster und eingeschr nkt aus den Praxisbeispielen ablesbar wobei sie sich in einem Praxisbeispiel bereits vor dem Vertragsschluss vollzogen hat Das Pflichtenheft wurde jedenfalls stets vom Softwarehaus gepr ft und dient in zwei F llen zusammen mit anderen vorvertraglichen Unterlagen als Grundlage der Leistungsbestimmung In dem Praxisbeispiel wo die Anforderungen im Vorfeld pr ziser festgelegt werden konnten und eine Integration in eine bestimmte betriebliche Soft und Hardware Umgebung nicht erforderlich ist findet sich eine deutlich geringere Regelungsdichte Die besonderen Pflichten der Vertragspartner dienen ganz berwiegend zur Projektkontrolle So ist das Softwarehaus gehalten in inhaltlich unterschiedlich ausgestaltetem Ma e regelm ig ber den Projektstand zu informieren Personalfragen wird keine hohe Bedeutung beigemessen teilweise werden Mitarbeiterqualifikationen gefordert in einem Beispiel beh lt sich der Softwarebesteller in Ausnahmesituationen einen Einfluss auf Personalentscheidungen vor Die Pflichten des Softwarebestellers beschr nken sich nahezu durchgehend auf das Bereitstellen von Ressourcen zum Teil in rudiment rer Form und auch dies wird durch weitere Einschr nkungen nicht unerheblich relativiert Eine aktive Rolle des Softwarehauses ist mit zwei Ausnahmen wobei eine
339. rty in breach did not foresee and a reasonable person of the same kind in the same circumstances would not have foreseen such a result 20 N 20 20 e Ww 50 Kapitel 3 Rechtliche Rahmenbedingungen in den USA Bei Vertragen die sich nicht im Austausch von Ware und Bezahlung ersch pfen wie beispielsweise Bauvertragen wird generell ein milderer Ma stab angelegt Hier ist substantial performance grunds tzlich ausreichend Dieses Prinzip spiegelt sich etwa in Rs 2d 237 wider Danach ist f r das Schicksal der Gegenleistungspflicht zun chst zu fragen ob berhaupt ein failure of performance vorliegt Beantwortet wird dies auf der Grundlage der Parteivereinbarung daneben aber auch auf der erg nzender Regeln wie beispielsweise derjenigen hinsichtlich ausgelassener Bestimmungen omitted essential terms und dem Grundsatz von good faith and fair dealing Insbesondere die erste Regel ist aus deutscher Sicht interessant Haben sich die Parteien im Hinblick auf eine grundlegende essential Bestimmung nicht geeinigt sei es weil sie eine Frage nicht bedacht oder sie auch bewusst als unerheblich oder unerfreulich angesehen haben so kann das Gericht eine den Umst nden angemessene Regel hinzuf gen Dies gilt laut Kommentar z B selbst dann wenn der Vertrag keine Regelung ber den Preis enth lt Good faith and fair dealing ist ein im US amerikanischen Recht mittlerweile anerka
340. rungsverlangen Beide Vertragspartner sind berechtigt unter Angabe wichtiger Gr nde den anderen Vertragspartner aufzufordern ber nderungen diese Vertrages oder der einzelnen fachlichen Feinspezifikationen zu beraten und zu verhandeln 3 2 Pr fung des nderungsverlangens Soweit der Auftraggeber nderungen in bereits verabschiedeten Spezifikationen w nscht wird der Auftragnehmer gegen Verg tung auf Zeit und Materialbasis entsprechend der allgemeinen Preisliste des Auftragnehmers den dabei entstehenden Aufwand pr fen sowie ob die gew nschte nderung durchf hrbar ist und den Auftraggeber dann m glichst kurzfristig dar ber informieren welche nderungen sich insbesondere hinsichtlich der Kosten und des Zeitplans voraussichtlich ergeben Soweit m glich und notwendig wird der Auftragnehmer auch pr fen inwieweit eine solche nderung Auswirkungen auf bisher realisierte Leistungen und deren Nutzbarkeit hat 3 3 Unterbrechung zur Pr fung von nderungen Gegen Verg tung der Ausfallzeiten kann der Auftraggeber bis zur Einigung ber ein nderungsverlangen teilweise oder vollst ndige Unterbrechung der Realisierung fordern Eventuell vereinbarte Leistungsfristen und Zeitpl ne verl ngern sich dementsprechend um die Ausfallzeit sowie um die Zeit die der Auftragnehmer ben tigt um nach seiner Unterbrechung die Wiederaufnahme der Arbeiten zu organisieren und die notwendigen Ressourcen wieder zur Verf gung zu stellen 3 4
341. rzwingen der Vertragsdurchf hrung specific performance zu verweigern Schlie lich findet sich in den Restatements die Parol evidence rule wonach eine verbindliche Vereinbarung grunds tzlich alle vorhergehenden Vereinbarungen f r unwirksam erklart Wie im U C C werden auch hier Usage of trade und Course of dealing als M glichkeit f r die Erg nzung oder Qualifizierung der Parteivereinbarung genannt ll Case Law Naturgem finden sich im Fallrecht nur Reaktionen auf fehlgeschlagene Softwareprojekte Welche Rolle die detaillierte Regelung der Leistungspflicht spielt zeigt sich vor allem dann wenn entsprechende Vereinbarungen nicht getroffen werden So wurde es bereits 1984 in einem Prozess der wegen mangelhafter Software von einem erfolgreich Schadensersatz begehrenden Kl ger gef hrt wurde als usual industry practice bezeichnet dass vor Beginn der Programmierung detaillierte Spezifikationen in Verbindung mit vertieften Besprechungen mit dem Kunden vorbereitet werden Die Kommunikation mit dem Besteller in die richtigen Bahnen zu leiten wurde jedenfalls in dieser fr hen Phase der Softwareentwicklung als sich die entsprechende Industrie und der Aufbau von unternehmensinternen EDV Abteilungen noch in der Entwicklung befand als eine zentrale und in der Softwareentwicklung allt gliche Aufgabe des 218 Perhaps the simplest application of the policy against unconscionable agreements is the denial of sp
342. s and Softwarehaus has no knowledge of any pending or proposed change in such codes laws regulations or tariffs which the System as installed would not meet Zunachst fallt hinsichtlich der deutschen Muster auf dass sie sich zum gro en Teil mit der Verwendung des Wortlauts des Gesetzes begn gen Soweit sie dar ber hinausgehen suchen sie technische Ma st be zu referenzieren Von einer Ausnahme abgesehen ist ein Zugest ndnis an einen eingeschr nkten Fehlerbegriff f r Individualsoftware nicht vorhanden In zwei Praxisbeispielen findet sich ein technischer Ansatz wobei in einem Fall die Fehlerhaftigkeit von Individualsoftware ausdr cklich erw hnt wird Der Befund bez glich der amerikanischen Muster ergibt deutliche Unterschiede Die Bezugnahme auf eine gesetzliche Formulierung findet nicht statt Ebenso wenig wird auf allgemeine technische Ma st be verwiesen Als Anker dienen vielmehr mit einer Ausnahme stets die Spezifikationen Einem eingeschr nkten Fehlerbegriff wird in f nf Mustern 209 Kapitel 7 Vergleichende Darstellung und einem Praxisbeispiel Rechnung getragen In einem Muster findet sich andererseits die Pflicht des Softwarehauses nicht nur fehlerfreie Software zu liefern sondern damit auch die Bedurfnisse des Softwarebestellers zu erfullen Im Ergebnis zeichnen sich die amerikanischen Muster und Beispiele weitgehend durch einen Pragmatismus aus der den deutschen Mustern fremd zu sein scheint Di
343. s Inc v Inacomp Financial Services 1993 WL 410066 1993 Baeco Plastics Inc v Inacomp a a O a plaintiff must prove the following elements 1 an offer and acceptance 2 consideration 3 the terms of the contract 4 plaintiff s performance of all contractual conditions required of him 5 defendant s breach of the terms of the contract and 6 damages occurring as a result of the defendant s breach Der Besteller hatte gekUndigt und wurde wegen unstreitiger Nachforderungen und nicht erbrachter Mitwirkungsleitungen zun chst per Juryspruch zu Schadensersatz in H he von 2 6 Mio verurteilt die das Gericht auf 469 000 herabsetzte Computrol Inc v Newtrend L P And CA Newtrend 203 F 3D 1064 2000 54 22 w 22 A 22 a 22 oO 22 S Kapitel 3 Rechtliche Rahmenbedingungen in den USA seinen Verpflichtungen l sen Erbringt das Softwarehaus andererseits ohne konkreten Auftrag Uber die urspr ngliche Vereinbarung hinaus Leistungen so ist es f r die Vereinbarung einer dementsprechenden Verg tung selbst dann beweispflichtig wenn der Besteller nicht im erforderlichen Ma e mitarbeitet Die Tatsache alleine dass eine Festpreisvereinbarung vorliegt schlie t die Verg tungspflicht f r Zusatzleistungen jedenfalls dann nicht aus wenn die von dem Softwarehaus vorgenommenen Arbeiten nicht in den Aufgabenbereich des Vertrages fallen In der j ngeren Rechtsprechung spiegelt sich d
344. s Softwarebestellers ausgerichteten Muster AE wird neben dem Service die Lieferung der Software zur ausdrucklichen Pflicht gemacht Wahrend man eine dementsprechende Regelung bei FP vergeblich sucht erganzt OD im Anhang rider unter Nr 1 folgende Formulierung 1 To fulfill the requirements of SCHEDULE A attached to the Agreement Vendor recommends the software manufactured developed or supplied by Vendor and other components to be supplied by Vendor Das Softwarehaus empfiehlt fur eine Erf llung der Leistungsanforderungen den Einsatz nicht n her definierter anderer vom Softwarehaus zu liefernder Komponenten Dies erschwert dem Softwarebesteller den Einsatz von Konkurrenzprodukten da er sich damit ggf dem Einwand des Softwarehauses aussetzt ein den Anforderungen entsprechendes Ergebnis sei nur mit dessen Produkten zu erzielen 82 Kapitel 4 Empirischer Befund in den USA Il Bestandteile der Lieferung Hierzu findet sich bei OD die Pflicht des Softwarehauses operating manuals und complete source code listings zu liefern In der Anlage A wird als Scope of Project to provide software consulting and professional services for 120 automated music formats using MPEG Layer 2 WAV audio compression genannt Bei AE wird der Lieferungsumfang uber die Pre existing Software und die Developed Software hinaus auf Deliverables erstreckt FP stellt die Bereitstellung weitgehend definierter Teams in den
345. s UN Kaufrecht gef hrt vgl zur Terminologie Corvaglia Stefano Das einheitliche UN Kaufrecht Bern 1998 18 Art 1 CISG 187 Die etwa gelegentlich in Bezug genommene Entscheidung Evolution Online Sys Inc v Koninklijke Nederland N V 2d Cir 1998 41 F Supp 2d 44 gibt keine Aufschl sse Uber die hier interessierende Fragestellung der Anwendbarkeit der UN Konvention auf Softwareentwicklungsvertrage 47 Kapitel 3 Rechtliche Rahmenbedingungen in den USA auseinander zu setzen Solange Software in einem k rperlichen Medium vorliegt kann sie als Transformation von unk rperlichen Ideen und Wissen in eine physische Form verstanden werden Der Benutzer erhalte etwas und dieses Etwas solle von der Konvention erfasst werden Dem Hauptziel der Konvention der economic expansion and facilitation of international commerce sei damit zudem am besten gedient Diese Auffassung wird unter dem Gesichtspunkt geteilt dass sich der Erwerb von Software f r viele vielleicht die meisten Menschen soweit sie sich berhaupt mit solch esoterischen Angelegenheiten befassen als ein Kauf sale of goods darstellt Es k nne nicht erwartet werden dass von der betroffenen Person verstanden wird die Essenz des Vertrages liege im Recht zur Nutzung der Software Dies Ergebnis ndere sich auch dann nicht wenn die Software auf elektronischem Wege geliefert werde In diesem Fall fehle es zwar an der Einbettung in einem k rperlichen Medi
346. s beiden Gruppen nehmen auch technische Details in den Hauptvertrag auf 533 Dies versteht sich einerseits da es sich um f r eine Vielzahl von F llen vorgesehene Muster handelt von selbst Andererseits w re es durchaus gerade im Bereich der Beschreibung der Vorgehensweise bei der Leistungsbestimmung durchaus m glich diese im Hauptvertrag zu verankern So ist es beispielsweise bei HE vorgesehen der allerdings einen sehr technisch abstrakten Ansatz verfolgt und die konkreten Fragen im Projektleben nicht regelt 197 Kapitel 7 Vergleichende Darstellung B Reaktionsmechanismen bei Anderungen Das amerikanische und das deutsche Recht enthalten Regeln fur den Fall von Anderungen der Rahmenbedingungen So hei t es in den Restatements 2d 89 a dass auch einseitige nderungen der in einem Vertrag begr ndeten Pflichten verbindlich sind wenn sie sich als fair and equitable in view of circumstances not anticipated when the contract was made darstellen Regelungsgegenstand dieser Norm ist die Rechtslage bei unvorhergesehenen Ereignissen Im deutschen Recht wird nderungen nach Vertragsabschluss nunmehr in 313 BGB unter dem Titel St rung der Gesch ftsgrundlage Rechnung getragen Dort hei t es 1 Haben sich Umst nde die zur Grundlage des Vertrags geworden sind nach Vertragsschluss schwerwiegend ver ndert und h tten die Parteien den Vertrag nicht oder mit anderem Inhalt geschlossen wenn sie diese
347. s to provide the necessary skills and services to design develop test document and install the Custom Portions and other necessary design and implementation services so that the entire System meets the Performance Standards IV Besondere Pflichten des Softwarehauses Bei FP findet sich zunachst die bereits benannte prazise Anforderung an das vom Softwarehaus bereitzustellende Projektteam Die Bedeutung dieser Regelung wird durch eine erganzende Bestimmung zu den Performance Standards unterstrichen die hier auszugsweise wiedergegeben wird PERFORMANCE STANDARDS SMS and MAS 3 1 1 FDRI Responsibilities FDRI shall maintain the computer capacity and staff necessary to provide services in accordance with the performance standards set forth in this Article 3 NOTE Unless otherwise stated all attainment measurements to be calculated based on calendar days in a calendar month a As measured by the FDRI host computer on line system downtime shall not exceed during the period from 6 00 a m to 3 00 a m Central Time for any calendar month For purposes of this item a downtime does not include telecommunications lines or individual terminals controllers or modems on PRODIGY property Critical NOTE for the purposes of the provisions of this Section 3 1 1 on line system shall mean a system in which the input data enters the computer directly from the point of origin e g computer terminal or workstation and the output
348. scheidet setzt der AN zun chst die T tigkeiten nach den bisherigen Vorgaben fort 3 Falls sich die Vertragspartner nicht ber die Verg tung und eine nderung des Terminplans einigen entschiedet in Bezug auf den Terminplan die Schlichtung 23 in Bezug auf die Verg tung bleibt der Streit offen 4 Alle Vorg nge in diesem Zusammenhang sind aufs u erste zu beschleunigen um eine Projektverz gerung zu vermeiden Das Softwarehaus muss einem nderungsverlangen in zwei F llen nicht entsprechen Einmal wenn es nicht im Rahmen des Projektes liegt und zum anderen wenn es unzumutbar ist Es werden kleine nderungen bis 5 Arbeitstage Aufwand nderungen mit 5 bis 9 Arbeitstagen Aufwand und nderungen mit mehr als 9 Tagen Aufwand unterschieden Je nach Umfang werden unterschiedliche Verfahren f r das weitere Vorgehen bestimmt wobei f r mittleren Aufwand eine Regelungsl cke besteht Konkrete Fristen sind nicht vorgesehen BA beschr nkt sich insoweit auf die Generalklausel des Abs 4 Bei den umfangreichsten nderungen findet ein formalisierter Einigungsversuch auf der bereits verhandelten Verg tungsbasis und anhand einer nderungsspezifikation des Softwarebestellers und darauf beruhender Kalkulation des Softwarehauses statt BA versucht also nderungen in m glichst enger Anlehnung an bereits bestehende Regelungen abzufedern 520 In 12 Abs 3 findet sich folgende Regelung Ein Teilprojektteam kann sein Bud
349. schlie end zum Herunterladen auf einem Webserver bereitgestellt wird handelt es sich dann nicht um Software Der Erwerb einer Vielzahl von Programmen einschlie lich umfangreicher Betriebssysteme findet genau auf diese Weise statt Wenn hier Programme ver u ert werden und nicht Software worin besteht dann der Unterschied 562 Nachweise s o in Kapitel 5 B 2 S 107 53 S o Kapitel 3 C 2 S 42 213 Kapitel 8 Schlussfolgerungen Sacheigenschaft nicht voraussetzen wie z B den Werk oder Dienstvertrag oder vorhandene Regeln analog anzuwenden Il L sungen im Begriffssystem und Erfahrungssystem Die Frage Wenn Software keine Sache ist was ist sie dann kann sehr einfach beantwortet werden Software ist Software Es ist nicht notwendig auch wenn der civil lawyer dies als schwer ertr glich empfindet Software der vorgegebenen Begriffswelt der Gesetze zuzuordnen Der Rechtsvergleich kann an dieser Stelle helfen sich von den Begriffsvorgaben zu l sen Das deutsche Recht sch pft strukturell aus dem Gesetz als prim re Rechtsquelle Wie sich beispielsweise bei der untergerichtlichen Rechtsprechung zur vertraglichen Einordnung der Softwareentwicklung zeigt reicht allerdings eine Stellungnahme des BGH h ufig dazu aus dem dort vorgegebenen Weg ohne weitere Begr ndung zu folgen Gleichwohl macht sich der Strukturunterschied zum amerikanischen Recht beispielsweise bei Gesetzes nderungen wie der Schu
350. sei das Modell des BGB in seiner jetzigen Form geeignet zu vorhersehbaren und konsensf higen Entscheidungen im Einzelfall zu f hren Er r umt jedoch ein dass die Verallgemeinerungsf higkeit nicht f r im Leistungsprogramm enthaltene Schutz Treu und sonstige Nebenpflichten gilt Wie f llt diese zutreffende Beurteilung nun aus wenn die urspr nglich als Nebenpflicht konzipierte Mitwirkung zu einem zentralen Bestandteil des Leistungsprogrammes wird wenn die erfolgreiche Abwicklung des Vertrages mit der sorgsamen Erf llung dieser Nebenpflicht steht und f llt Wie zuletzt bei Schneider in seinem berblick ber das IT Vertragsrecht der letzten 20 Jahre anschaulich dargestellt vollzieht sich die Softwareentwicklung in einem Pflichtengef ge welches von der Verflechtung zweier Anpassungsleistungen gepr gt ist Es zeigt sich das bereits dargestellte Element der Abh ngigkeit der Vertragspartner voneinander Zu den ohnehin bestehenden konzeptionellen Defiziten des Werkvertrages im Hinblick auf Langzeitvertrage tritt hier also das Novum der engen Verbundenheit der Vertragspartner die an eine gesellschaftsrechtliche Konstruktion denken l sst ohne jedoch auf diesem Weg zufrieden stellende L sungen anbieten zu k nnen Das Fehlen einer zuverl ssigen Verankerung im Gesetz wird durch die unzureichende Einarbeitung von Kooperationskonzepten in der untersuchten vertragsrechtlichen Praxis zu einem von der Rechtsordnung m E nicht m
351. ser Notwendigkeit und berucksichtigen sie ebenso regelm ig in den Vertr gen F r die rechtlichen Rahmenbedingungen f r nderungsmechanismen gilt hier also das bereits zur Zielpr zision Ausgef hrte d h es obliegt den Vertragsparteien ohne n here Vorgaben oder Einschr nkungen des Rechts wie sie nderungen der Anforderungen im Projektverlauf regeln m chten In vier der amerikanischen und sieben der deutschen Muster sowie in zwei amerikanischen und allen deutschen Praxisbeispielen bei letzteren in zwei davon im Rahmen von Pflegevereinbarungen ist ein Change Management vorgesehen In den an den Interessen des Softwarehauses orientierten amerikanischen Mustern ist es nicht geregelt wohl dagegen im entsprechenden deutschen Muster Der Inhalt der jeweiligen Regelung f llt sehr unterschiedlich aus Teilweise wird zwischen kleinen und gr eren nderungen unterschieden Ausgangspunkt ist ein nderungsverlangen das in jeweils einem deutschen und amerikanischen Muster sowie einem amerikanischen Praxisbeispiel auch vom Softwarehaus ausgehen kann Ansonsten liegt die Initiative stets beim Softwarebesteller Die Durchf hrung kann in einem amerikanischen Praxisbeispiel und in zwei Mustern vom Softwarebesteller verlangt und in zwei Mustern vom Softwarehaus auch abgelehnt werden Unter den teilweise sehr ausf hrlichen deutschen Mustern finden sich zwei in denen ein Recht zur Ablehnung von nderungen vorgesehen und vier in
352. sich daraus ergebenden Konsequenzen Rede und Antwort stehen Wie es z B Vorgehensweisen wie das V Modell nahe legen k nnten andererseits schr nken Vorgaben die Kreativit t nicht zwangsl ufig ein sie k nnen f r einen kreativen Prozess vielmehr beg nstigend wirken ebenso Eschbach a a O S 93 Love a a O S 28 und best tigend Etzel Heilmann Richter a a O S 86 das bekannteste aktuelle Beispiel d rfte LINUX sein dessen Kern bekanntlich aus der Feder einer Person stammt Es handelt sich allerdings durchweg um Standardsoftware Love gibt an die Produktivit tsabweichung von Softwareingenieuren k nne 25 1 oder sogar 50 1 bei gleicher Ausbildung und Erfahrung betragen a a O S 244 auch arbeiten gute Teams laut Love bis zu 10 mal schneller als schlecht funktionierende S 248 Mythos S 22 der Einsatz zus tzlicher Arbeitskr fte bei bereits verz gerten Softwareprojekten verz gert sie nur noch mehr Franz a a O S 31 Zehnder a a O S 180 Etzel Heilmann Richter a a O S 24 Eschbach a a O S 150 29 10 S 10 N 10 o 104 10 a 10 oO Kapitel 2 Softwareentwicklung in der Praxis zus tzlicher Arbeitskr fte keine Zeitersparnis erreicht Auch der Gedanke m glichst fr hzeitig mit der eigentlichen Programmierung zu beginnen hat sich als Fehleinsch tzung erwiesen Sieht man in der Erstellung von Software nicht ohnehin eher eine
353. sichtliche Inhalt der Dokumentation zur Gesamtkonfiguration d rfte auch vor allem dazu dienen ein Verst ndnis des Softwarebestellers daf r zu erm glichen wie der Umgang mit den Daten vom Programm gehandhabt wird Dies kann dazu beitragen die Abh ngigkeit vom Wissensmonopol des Softwarehauses zu verringern Diese Absicht wird im Source Code Nutzungsvertrag unterstrichen Das Softwarehaus wird in der Bestimmung 4 Source Code zur Einraumung eines nicht ausschlie lichen nicht Ubertragbaren Nutzungsrechts verpflichtet 4 3 Der AG erh lt das zeitlich und r umlich unbeschr nkte Recht den Quellcode auf s mtliche Arten zu nutzen ihn insbesondere zu bersetzen zu bearbeiten das Arrangement und andere Umarbeitungen des Quellcodes zu verwerten sowie die erzielten Ergebnisse zu vervielf ltigen Zu diesem Zweck bergibt der AN neben dem gesamten eigenen Source Code inkl Projektdateien Einstellungen dem AG alle Angaben zu notwendigen Hilfsmitteln Libraries Compiler usw zur Erzeugung der Binaries Anm Source Code und Quellcode sind Synonyme Er repr sentiert das Programm in einer h heren Programmsprache das vom Computer jedoch erst verstanden wird wenn es compiliert d h in f r Computer lesbare Bin rprogramme Binaries bersetzt wurde Dies gilt ebenfalls f r alle Folgeupdates und nderungsdokumentationen Zur Bewertung werden einige typische Source Code Dateien vorab bergeben Bei SUS ist die Li
354. siko der Beteiligten werde nicht notwendig reduziert sondern durch eine Risikovergemeinschaftung ersetzt Heppner a a O S 308 116 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland Interesse k nne sich allenfalls ergeben wenn Besteller und Softwarehaus das erstellte Produkt gemeinsam vermarkten wollten Eine hnliche Sonderrolle spielten Vertr ge bei denen es sich um die Entwicklung relativ neuer v llig ungew hnlicher Software in einer komplexen Umgebung handelt In diesem Fall sei von einem Entwicklungsauftrag auszugehen f r den das Werkvertragsrecht eine unangemessen einseitige Risikozuweisung zu Lasten des Softwarehauses enthalte Wenn der Arbeitserfolg ma geblich von nicht unerheblicher Unsicherheit ber das Erreichen des Zieles gekennzeichnet ist m sse eine L sung jenseits von Dienst und Werkvertrag gefunden werden bei dem im Falle des Fehlschlagens des Projektes ein K ndigungsrecht ex nunc und eine h lftige Kostentragung durch beide Vertragspartner die Folge sei Heppner schlie lich stellt die Komplexit t der Softwareentwicklung in den Vordergrund bei der sich die Grenzen austausch vertrags bzw gesellschaftsrechtlicher Konstruktionen zeige Als L sung biete sich ein dem Spiralmodell der Softwareentwicklung angen herter sog evolution rer Vertrag an4 der durch ein wohlgeordnetes Ineinandergreifen von gesellschafts und austauschvertraglichen Elementen gekennzeichnet s
355. software 5 Aufl Berlin 2001 S 178 der weiter ausf hrt diese Notwendigkeit werde jedoch nicht immer angemessen beachtet was zu beklagenswerten Missst nden f hre 404 In Form eines Pflichtenhefts Malzer a a O S 276f zum Pflichtenheft siehe auch sogleich 05 Schneider Handbuch a a O S 1485 40 gt 40 40 oO N 112 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland konzipierten L sung aus vielen Gr nden ab Selbst wenn ein Pflichtenheft erstellt werde erweise es sich nicht selten als unzureichend Es sei an der Tagesordnung dass die tats chlichen Bed rfnisse nicht den definierten Anforderungen entsprechen Der BGH weist darauf hin dass die Bedeutung der Leistungsbeschreibung im Einzelfall ermittelt werden muss Zudem k nne auch eine Leistung geschuldet sein die nicht ausdr cklich vereinbart wurde 3 Gesetzliche Regeln nach modifiziertem Kaufvertragsrecht 651 Abs 1 S 3 BGB und Werkvertragsrecht 88 631ff BGB Wird ber 8 651 Abs 1 S 3 modifiziertes Kaufvertragsrecht angewandt so besteht die Hauptpflicht des Softwareerstellers nach 433 Abs 1 BGB in der bergabe und Eigentumsverschaffung frei von Sach und Rechtsm ngeln Das Werkvertragsrecht verpflichtet demgegen ber zur Herstellung des versprochenen Werkes 8 631 Abs 1 BGB die nach 633 Abs 1 BGB ebenfalls mangelfrei zu erfolgen hat 631 BGB erfasst ein Vertragsmodell mit der gr ten Vielf
356. specifications configurations and function that appear in the Scope of Work or in any Change Orders Specifications will represent an acceptable implementation of the Functional Requirements Softwarehaus warrants that for a period of twelve 12 months after XXXXX s first commercial shipment of the Product excluding shipments for beta testing the Warranty Period the Product will perform in accordance with the Specifications The Subject Programs shall conform in all material respects to the Specifications and Performance Standards except for subsequent modifications made at Softwarebesteller s request The software will perform substantially in accordance with the specifications for the software The Management System will substantially conform to the specifications contained in Schedule A as modified by the Modifications listed in Schedule B Application shall comply with Softwarebesteller s requirements as disclosed in the Detailed Design Specifications 208 Kapitel 7 Vergleichende Darstellung MaBstab der Leistungserbringung Softwarehaus as an expert in the field warrants that the system shall meet Softwarebesteller s needs as defined in the approved Design Document and in Exhibit A and shall be substantially free from programming errors and defects in workmanship and materials US Praxisbeispiele The System shall substantially pe
357. spruch zu nehmen soweit dies f r die Durchf hrung des Lizenzvertrages notwendig ist 2 Die Rechenanlagen des Lizenznehmers auf denen das Lizenzprodukt installiert werden sollen m ssen in einem ordnungsgem en Zustand insbesondere mit einem funktionierenden Betriebssystem ausgestattet sein Der Lizenzgeber ist nicht verpflichtet St rungen der Rechenanlagen erst zu beseitigen um den Installationsvorgang vornehmen zu k nnen 3 Der Lizenzgeber erh lt vom Lizenznehmer die technischen Dokumentationen zu den bereits auf den Rechenanlagen des Lizenznehmers installierten Softwareprogrammen soweit dies zur Installation des Lizenzproduktes notwendig ist Verwertbar ist hier der Grundgedanke dass das Softwarehaus auf eine funktionsf hige EDV Basis beim Softwarebesteller angewiesen ist Bedarf allerdings bereits die Existenz eines funktionsf higen Betriebssystems besonderer Vereinbarung so d rften insgesamt erhebliche Zweifel an den Erfolgsaussichten eines umfangreicheren Softwareprojekts bestehen Bei KO ist dies unter 2 Lieferung und Installation geregelt 2 2 Mitwirkung des Kunden Der Kunde stellt dem Anbieter zum Zweck der Programmentwicklung Testdurchf hrung und Installation ausreichend M glichkeiten der Anlagennutzung und Rechenzeiten zur Verf gung Die ben tigten Rechenzeiten sind im Software Leistungsschein anzuf hren und im Voraus terminlich festzuhalten Zus tzliche Rechenzeit stellt der Kunde gegen angeme
358. ss gelegt Dies wird hier durch konkrete Vorgaben hinsichtlich der personellen Projektbeteiligung zu erreichen versucht Der Softwarebesteller hat die Pflicht aber auch das Recht sich an der Projektdurchf hrung aktiv zu beteiligen Geregelt wird also die Form der Zusammenarbeit 4 1 Licensee Participation During the entire course of the project licensee shall provide a project director the Project Director whose duties shall be to act as liaison between Licensor and Licensee It is understood that for the System to succeed the Licensee data processing staff should acquire a knowledge of the Systems As a consequence Licensee shall have the right to have one programmer analyst in Licensor s premises Licensor shall provide desk space for such Licensee employee 5702 Kapitel 4 Empirischer Befund in den USA Im Anschluss daran finden sich bei RB U weitere personalbezogene Vorgaben fur das Softwarehaus Diese erfassen zunachst die geforderte Qualifikation und den Widmungsumfang der vom Softwarehaus eingesetzten Mitarbeiter Dar ber hinaus erm glichen sie auch die Einflussnahme auf Personalentscheidungen des Softwarehauses 4 2 Staffing and Staff Qualification The consulting and professional personnel provided by Licensor hereunder shall have appropriate technical and application skills to enable them to perform their duties hereunder Licensor shall disclose in the progress reports provided for hereunder the names and experienc
359. ssene Verg tung zur Verf gung Durch die Verg tungspflicht f r die au erplanm ige Inanspruchnahme von Rechenzeit also der Nutzung der EDV Anlage des Softwarebestellers wird betont welch knappes Gut Rechenzeit darstellen kann Zus tzlichen Bedarf der zur Projektabwicklung ganz im Sinne des Softwarebestellers dient mit einer Zahlungspflicht zu sanktionieren mag auch dazu gedacht sein die 153 Kapitel 6 Empirischer Befund in Deutschland Planungssorgfalt zu erh hen Es handelt sich gleichwohl um eine ungew hnliche Regelung die zudem gewissen Friktionen mit der allgemeinen Mitwirkungsregel in 9 Pflichten des Kunden ausgesetzt ist 9 2 Unterst tzungspflicht des Kunden Der Kunde verpflichtet sich die zur Herstellung des Werkes erforderlichen T tigkeiten des Anbieters zu unterst tzen Insbesondere schafft der Kunde unentgeltlich alle Voraussetzungen im Bereich seiner Betriebssph re die zur Erstellung des Werkes erforderlich sind Arbeitsr ume m ssen in den Gesch ftszeiten zug nglich sein und erforderliche Arbeitsmittel zur Verf gung stehen Testdaten und sonstige Informationen sind rechtzeitig beizustellen und mit dem Operating beauftragte Mitarbeiter rechtzeitig abzustellen Durch die Sph renabgrenzung wird deutlich gemacht worauf es nach KO ankommt Im Bereich des Softwarebestellers ist dieser selbst und alleine verantwortlich Noch deutlicher akzentuiert findet sich dies bei BA der unter 5 B
360. sst sich hier offenbar gut mit der Vorgehensweise der Informatiker in bereinstimmung bringen Dabei sind allerdings zwei Einschr nkungen zu beachten Die erste betrifft ein juristisches Defizit Die Geschwindigkeit mit der sich die Technik und die damit verbundenen Verfahren ndern kann durch die Rechtsordnung nicht nachvollzogen werden Das v a in Form von Vertragsgestaltung zu Tage tretende Recht ist bei dem Versuch der Abbildung der ersten Phasenmodelle 577 Zweigert K tz Einf hrung in die Rechtsvergleichung auf dem Gebiete des Privatrechts 3 Aufl T bingen 1996 S 39 578 Zweigert K tz a a O S 45 222 Kapitel 9 Zusammenfassende W rdigung stecken geblieben Zyklische Modelle wie z B das Spiralmodell scheinen das Recht zu uberfordern Die zweite Einschrankung betrifft ein Defizit der Informations Technik in der Praxis Wie diese Praxis lehrt wird allzu haufig gegen die erkannte und von Juristenseite unerm dlich angemahnte Regel dass der Softwareentwicklungsvertrag auf eine prazise Leistungsbestimmung gegr ndet sein muss versto en Das social engineering versagt in vielen F llen bei nderungen des Leistungsprogrammes dazu sogleich unter Il und bei der Gestaltung von Mitwirkungspflichten Die Gr nde hierf r entspringen m E dem soeben angedeuteten Auseinanderfallen von technischer und rechtlicher Entwicklung Bereits in einem Softwareprojekt mittlerer GroRe arbeiten m glicherweise
361. st ndig soweit die damit zusammenh ngenden Beratungspflichten des Softwarehauses au er acht gelassen werden Auf diese ist daher n her einzugehen V Beratungs und Mitwirkungspflichten 463 Sowohl in der Literatur als auch in der Rechtsprechung werden die intensiven Leistungsbeziehungen der Vertragspartner bei einem Softwareentwicklungsprojekt hervorgehoben Heppner spricht hier 46 A a O S 141ff dass nach 375 HGB die n here Bestimmung der kaufvertraglichen Verh ltnisse dem K ufer vorbehalten sein muss will Thewalt durch stillschweigende Vereinbarung eines Bestimmungsrechtes als gegeben ansehen S 149 Die sich aus 642 BGB ergebende Obliegenheit zur Leistungsbestimmung enthalte als minus den Vorbehalt dazu S 150 hnlich Schneider Handbuch a a O S 1479 der die Erstellung des Pflichtenhefts als eine Mitwirkungsleistung des Auftraggebers verstanden wissen will Malzer a a O S 277 OLG Celle U v 20 02 91 CR 1991 S 610 OLG K ln U v 18 06 93 OLGR K ln 1993 S 237 und U v 25 06 93 OLGR K ln 1993 S 270 LG Heilbronn U v 16 12 93 CR 94 S 281 OLG Saarbr cken U v 22 09 94 BB Beilage 95 Nr 16 S 12 der BGH weist auf die Notwendigkeit hin im Einzelfall zu ermitteln ob die Erstellung eines Pflichtenhefts geschuldet sei U v 13 11 97 NJW RR 1998 S 1128 OLG D sseldorf U v 10 06 92 CR 1993 S 361 KG Berlin U v 01 06 90 CR 1990 S 768 OLG D sseldorf U v 18 07
362. ste Zugang zur Erkenntnis dessen was Treu und Glauben entspricht seien Malzer a a O S 266 Thewalt a a O S 66ff Redeker IT Recht in der Praxis S 297 Herr Robert Anm zu LG Karlsruhe U v 13 05 1991 10 O 458 89 CR 1992 S 342 M ller Hengstenberg Claus Dieter Vertragstypologie der Computersoftwarevertr ge CR 2004 S 161 Diedrich Kay Typisierung von Softwarevertr gen nach der Schuldrechtsreform CR 2002 S 473 Krau Wolfgang Die Auswirkungen der Schuldrechtsreform auf Softwarevertr ge Diss M nster 2004 S 42 der den Grundcharakter des Werkvertrages betont Marly Jochen Software berlassungsvertr ge 4 Aufl M nchen 2004 S 58 Schweinoch Martin Roas Rudolf Paradigmenwechsel f r Projekte Vertragstypologie der Neuerstellung von Individualsoftware CR 2004 S 326 Kottof Jost Softwareerstellungsvertr ge nach der Schuldrechtsreform K amp R 2002 S 105 Plath Kai Uwe Abnahme bei Individualsoftwarevertr gen ITRB 2002 S 98 Koch Frank Kaufrechtliche Vorgaben f r 105 oO N 34 35 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland besonderen Schuldrecht gel ste Lizenzvertragsl sung sowie Hinweise auf das Gesellschaftsrecht und einen sog dynamischen bzw evolution ren Vertrag Die Kriterien nach denen eine Zuordnung erfolgen soll sind au erordentlich vielseitig Zu den wenigen soweit ersichtlich einheitlich vertretene
363. sult from the objectives set out by the Customer and shall be brought to the Customers attention by the Vendor for consideration Bemerkenswert ist der letzte Satz wonach Fehler Auslassungen oder Ungenauigkeiten nicht der unzureichenden Vorgabe des Softwarebestellers angelastet werden d rfen sondern diesbez glich eine Aufklarungspflicht von Seiten des Softwarehauses konstituiert wird Der Softwarebesteller ist also einerseits gehalten m glichst genau zu definieren was er will und den Entwurf des Softwarehauses auch auf die Wiedergabe seiner Intentionen zu pr fen Das Softwarehaus wird auf der anderen Seite jedoch nicht aus der Pflicht entlassen auf unzureichende oder fehlerhafte Vorgaben des Bestellers aufmerksam zu machen Erg nzt wird diese Regelung durch eine Generalklausel im Anhang wonach alle seitens des Softwarebestellers bekannt gemachten Spezifikationen durch die Software abgedeckt werden miussen 2 For all purposes of the Agreement all references to the System shall be deemed to include all components equipment program products systems services training and documentation referenced in the Agreement or necessary to enable the System to operate in accordance with all Vendors published specifications with respect thereto SCHEDULE A and all of the terms and conditions of the Agreement 270 Rider Nr 2 86 Kapitel 4 Empirischer Befund in den USA collectively the Performance Standards Vendor agree
364. svertrages entsprechende Anpassungs leistungen zu erbringen Der AN verpflichtet sich gesetzlichen nderungen mit f r den AN erkennbaren Auswirkungen auf die Funktionalit t der Software beim AG rechtzeitig vor Wirksamwerden der nderung im Rahmen des Wartungsvertrages zu liefern und sichert die Jahr 2000 F higkeit der Software ausdr cklich zu 185 Kapitel 6 Empirischer Befund in Deutschland Der AN liefert die Updates in regelm igen Abst nden und gew hrleistet einen einwandfreien Anderungsdienst mit eindeutiger Versionsverwaltung Es findet sich das bereits bekannte dreistufige Schema wieder wonach einer Anfrage des Softwarebestellers eine Pr fung des Softwarehauses folgt Das Ergebnis der Pr fung muss Angaben zu Kosten und Terminen enthalten Abgeschlossen wird das Verfahren mit der hier nicht gesondert aufgef hrten Entscheidung des Softwarebestellers Es kommt hier eine Zustimmung oder eine Ablehnung in Betracht eine Regelung kontroverser Auffassungen zu den nderungskonditionen besteht nicht Aus der Wartungsregelung bei MiN wird deutlich dass die Vertragspartner von einer best ndigen nderung in regelm igen Abst nden gelieferte Updates was laut Vertragsdefinition in 13 4 S 1 verbesserten Programmversionen entspricht ausgehen Dies erkl rt warum bei MiN den nderungsregelungen keine gro e Beachtung geschenkt wird Bei MiO werden die nderungen unter 4 nderungen der Vorgaben f r Anpassu
365. t 68 OLG Stuttgart U v 01 10 88 CR 1989 S 598 49 OLG Celle U v 20 02 91 CR 1991 S 610 OLG K ln U v 18 06 93 OLGR K ln 1993 S 237 und U v 25 06 93 OLGR K ln 1993 S 270 470 BGH U v 14 07 93 NJW 1993 2436 2438 41 Dazu geh rten auch Rahmenorganisation die Einf hrung der neuen L sung im Betrieb des Anwenders sowie die notwendige Schulung des Personals Slongo a a O S 23 ebenso Malzer a a O S 287 472 Malzer a a O S 289 3 Schaub CR 1993 S 329 121 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland Seiten gestellten Fragen Teilweise wird in der neueren Literatur eine Pr fungspflicht des Softwarehauses bez glich des Pflichtenhefts verneint Es wird dabei auch betont das Softwarehaus habe zwar die Bed rfnisse des Bestellers sorgf ltig zu analysieren und ggf entsprechende Nachfragen zu stellen jedoch d rfe dabei nicht unber cksichtigt bleiben dass auf Seiten des Softwarehauses m glicherweise keine Branchenkenntnis d h detailliertes Wissen ber die Gegebenheiten in der Branche des Kunden vorliege Eine nicht selten streitentscheidende softwaretypische Pflichtenerweiterung nehmen die Gerichte bez glich der Dokumentation vor Der Besteller habe Anspruch auf eine umfassende schriftliche Fixierung der Funktions und Bedienungsregeln Die Lieferung geh re auch ohne ausdr ckliche Vereinbarung zur Hauptleistungspflicht Der BGH begrenzte diese extensiven
366. t kommen Es ist f r einen Projekterfolg ebenso 120 Zehnder a a O S 144 ebenso Franz a a O S 66 121 Etzel Heilmann Richter a a O S 24 Brooks gibt an dass jede Instandsetzung eines Programmes sehr wahrscheinlich 20 50 neue Fehler nach sich zieht Mythos S 107 122 was nach Zehnder sogar oft der Fall ist a a O S 174 1233 Zehnder sieht die konsequente Bek mpfung von Projekt nderungen als zentrale Forderung an eine gute Projektleitung a a O S 294f Brooks bemerkt dass richtiges Projektmanagement danach verlangt r ckhaltlos plausibel und manchmal unter dem Damoklesschwert des Auftragsverlustes Planungen zu vereiteln die jeglicher Grundlage entbehren Mythos S 19 124 A a O S 33 125 Kargl formuliert dies mit der trockenen Definition Bei komplexen Projekten besteht eine niedrige Planbarkeit ein im Voraus nicht bestimmbarer Informationsbedarf ein hoher Bedarf an Kommunikation und vielf ltige M glichkeiten der Bearbeitungsfolge a a O S 110 2395 Kapitel 2 Softwareentwicklung in der Praxis zwingend notwendig wie unm glich pr zise ein Ziel vorzugeben Zwingend notwendig ist es weil nur auf diese Weise die Vorstellungen und Wunsche des Softwarebestellers die das Projekt ins Leben gerufen haben realisiert werden k nnen Unm glich ist es weil die Vorstellungen und W nsche sich im Laufe des Projektes aufgrund sich andernder Rahmenbedingungen oder unabh ngig davon ebenfalls nde
367. t teleologische und historische Auslegung insbesondere auch das Ber cksichtigen vertragsbegleitender Umst nde in den Hintergrund Dieses Prinzip steht im Gegensatz zu der deutschen Regelung des 133 BGB wonach der wirkliche Wille und nicht der buchst bliche Sinn des Ausdrucks f r eine Auslegung ma geblich ist Ohne Kenntnis dieses Prinzips ist die in 130 Where such codes wie der U C C exist they make no pretense of completeness The judge is not compelled to find a basis for deciding a given case within the case Usually moreover such codes are not rejections of the past they do not purport to abolish all prior law in their field but rather to perfect it and except where it conflicts with their specific present purposes to supplement it Where some provision of a code or other statute appears to be in possible conflict with a deeply rooted rule of Common Law the tendency will be to interpret the code provision in such a way as to evade the conflict Merryman John Henry Western European and Latin American Legal Systems Charlottesville Virginia 1978 S 829 36 Kapitel 3 Rechtliche Rahmenbedingungen in den USA amerikanischen Vertragen zu beobachtende Tendenz zu umfassender Regelung und die damit einhergehende L nge der Vertragstextes kaum nachvollziehbar Das Primat der einzelstaatlichen Regelung fu t auf der f deralen Struktur der Vereinigten Staaten Anders als im kontinentaleurop ischen Rechtsraum gi
368. t ausdr cklich nur auf transactions in goods anwendbar Goods sind dabei definiert als all things including specially manufactured goods which are movable at the time of identification to the contract for sale Computer hardware wird unzweifelhaft als goods eingeordnet w hrend Vertr ge die vorwiegend Dienstleistungen personal services beinhalten wie Wartungs Trainings oder Supportvertr ge h ufig als nicht vom U C C erfasst angesehen werden 153 Calamari Perillo a a O S 17 154 Dazu ausf hrlich Eisenberg Melvin A 50 States but one law in Weyers Hrsg Europ isches Vertragsrecht Baden Baden 1997 S 30ff 15 Die aktuelle Fassung des Modellentwurfes findet sich unter http www law cornell edu ucc ucc table html die in den Einzelstaaten umgesetzten Fassungen finden sich unter http www law cornell edu uniform ucc html die aktuellen Anderungsvorschlage f r Art 2 U C C sind dokumentiert bei Flechtner Harry M Substantial Revisions to US Domestic Sales Law IHR 2004 S 225ff 86 U C C 2 102 157 U C C 2 105 1 158 Jedoch nicht ausschlie lich In einigen F llen wurde der U C C auch dann f r einschlagig befunden wenn in einem Dienstleistungsvertrag die Lieferung von goods eingeschlossen war wobei die Anwendbarkeit des U C C mit dem Umfang der gelieferten goods wahrscheinlicher ist Scott Scott on Computer Law 2 Aufl New York 2003 7 09
369. tations which would render the System unsuitable for use by Customer in processing its own applications and those of its current divisions subsidiaries or affiliates or presently contemplated future divisions subsidiaries or affiliates d the System will operate and conform in all respects during the term hereof in accordance with the Performance Standards e the System will meet all applicable local state and federal codes laws regulations and tariffs and that Vendor has no knowledge of any pending or proposed change in such codes laws regulations or tariffs which the System as installed would not meet 290 Rider Nr 4 ob dies ein uneingeschr nktes Vertrauen des Softwarehauses in seine Produkte oder eine erhebliche Risikobereitschaft widerspiegelt oder das Ergebnis einer komplexen Verhandlung darstellt ist nur f r die unmittelbar am Vertragsschluss Beteiligten nachzuvollziehen 95 Kapitel 4 Empirischer Befund in den USA Was die Preisgestaltung anbelangt so findet sich bei OD eine Fixpreisvereinbarung w hrend bei FP monatliche Zahlung vorgesehen ist Bei AE wird ebenfalls eine am Zeitaufwand orientierte Verg tung vereinbart 7 C Zusammenfassung und Ergebnis Die Vertr ge sind von sehr unterschiedlichen Ausgangssituationen gepr gt Dies gilt zum einen hinsichtlich der Bestimmbarkeit der zu erbringenden Leistung Ergebnisvarianz zum anderen bez glich der konomischen Machtverh ltnisse W hrend bei
370. tats chliche Wirkung dieser Unterscheidung sollte freilich nicht bersch tzt werden selbst dort wo Unternehmer ausdr cklich von der Anwendbarkeit bestimmter Regeln ausgenommen sind wie z B nach 310 Abs 1 S 1 BGB f r die 305 Abs 2 308 309 BGB findet die Inhaltskontrolle von Vereinbarungen im unternehmerischen Verkehr prinzipiell in gleicher Weise statt wie im Rechtsverkehr mit Verbrauchern vgl Erman Roloff B rgerliches Gesetzbuch Handkommentar 11 Aufl K ln M nster 2004 307 Rn 35 Ob dies heute noch gelingen kann ist nicht einfach zu beantworten so bemerkt etwa Weyers treffend Nun bietet bei aller Vielfalt und Farbigkeit fr herer Gesellschaftsordnungen in anderen Bereichen der wirtschaftliche und technologische Rahmen in dem diese Regeln f r Kaufvertr ge entstanden rezipiert und entwickelt worden waren im Vergleich zu heute ein Bild eher idyllischer Einfachheit und berschaubarkeit und das gilt auch von dem objektiven Wirtschaftsmodell des BGB also der Wirtschaftsstruktur f r die seine Regeln in vollem Umfang angebracht sein mochten Weyers in Esser Weyers Schuldrecht Band II Besonderer Teil 8 Aufl Heidelberg 1998 8 2 II 1 b S 6 312 So wird ein Vertrag etwa nicht dadurch zum Werkvertrag dass ich ihn als solchen bezeichne vergleichbar einem Esel der mit der Aufschrift Kuh versehen wird 101 30 31 m 31 Kapitel 5 Rechtliche Rahmenbedingungen in Deuts
371. te Wirtschaftsgut Software Die Gegenmeinung geht davon aus dass das Programm und seine Verk rperung voneinander getrennt werden missten Die Nutzung von Software geschehe anders als etwa bei einem Buch an unterschiedlichen physischen Stellen und h nge nicht an einer festen unver nderten physischen Plattform sondern wandert Es werde kein materialisierter Gegenstand bertragen sondern das geistige Produkt erworben welches primar Informationsgehalt habe c Zweck der Softwareentwicklung Der Zweck der Softwareentwicklung wird je nach Einsch tzung von Software unterschiedlich bewertet W hrend eine Meinung in erster Linie an den Gedanken der Probleml sung anknupft stellt eine andere auf die 379 Krau a a O S 16f Software k nne auch nicht geistig funktionieren ihre Funktionsweise sei ein rein physikalisch beschreibbarer auf eine Maschine einwirkender Vorgang dabei m ssten Werkverk rperung und urheberrechtliches Werk allerdings strikt getrennt werden S 20 anders dazu Hoeren Eine Trennung von Programm und Datentr ger sei nicht m glich a a O S 32 auch interessiere den Erwerber nicht alleine die Funktionalit t des Programmes S 33 Marly a a O Rn 101 Software m sse unabdingbar in einer verk rperten Form existieren sie bed rfe anders als etwa Know How einer Form die unk rperliche berlassung z B ber das Internet sei lediglich ein spezieller Vertriebstyp
372. ted Musterentwurf von Diane W Savage First Data Resources Incorporation Musterentwurf eines in der Datenbank nicht genannten Autors FL f r Florida Softwareentwicklungsprojekt zwischen einem Softwarehaus aus Nebraska First Data Ressources und einem Softwarebesteller aus New York Prodigy Services Company Musterentwurf von Glockler in Sobola Dobmeier Musterentwurf von Heppner Musterentwurf von Koch Musterentwurf von Marly Softwareentwicklungsprojekt zwischen einem Softwarehaus aus Mittelhessen und einem Produktionsbetrieb in Nordrhein Westfalen Softwareentwicklungsprojekt zwischen einem Softwarehaus aus Mittelhessen und einem Produktionsbetrieb in Osterreich Softwareentwicklungsprojekt zwischen einem Softwarehaus in Manitoba Canada OMT Technologies Inc und einem Unternehmen in Los Angeles California DMX Inc Musterentwurf von Raysman Brown Musterentwurf von Raysman Brown User Oriented Musterentwurf von Raysman Brown Vendor Oriented Musterentwurf von Schneider Musterentwurf von Schneider am Besteller orientierte Variante Musterentwurf von Schneider am Softwarehaus orientierte Variante Musterentwurf von Schr der Softwareentwicklungsprojekt zwischen einem Softwarehaus in S dhessen und einem Softwarebesteller der ffentlichen Hand im Siegerland IE Einleitung Einleitung Das Produkt Software existierte vor funfzig Jahren nicht Heute ist es aus dem Alltag nicht mehr wegzudenken an seiner En
373. ter gesprochen An der wirtschaftlichen Bedeutung der Softwareindustrie besteht ohnehin kein ernsthafter Zweifel Der amerikanische Gesetzgeber war bereits Ende der neunziger Jahre der Auffassung Information und Software verdiene ein eigenes Gesetz H lt man sich weiter vor Augen dass eine sehr spezielle wenn auch zweifellos sehr bedeutsame Regelungsmaterie die Reise ihren Platz im Kanon der Modelle des besonderen Schuldrechts gefunden hat so fragt sich mit welchen Gr nden der Software ein Anspruch auf eine gesetzliche Grundlage verweigert werden kann Die Diskussion um Softwarevertr ge ist auch keineswegs eine Eintagsfliege Sie wird mit unterschiedlichen Vorzeichen bereits seit ber zwanzig Jahren 58 Weyers AcP 182 1982 S 61 57 S o Kapitel 1 B S 15ff 58 S o Kapitel 3 A S 38 und C III S 49 230 Kapitel 8 Schlussfolgerungen gef hrt und ist durch die Schuldrechtsreform neu belebt worden Ein Ende ist nicht in Sicht zumal die Vielfalt der im Zusammenhang mit Software auftauchenden Sachverhalte regelm ig durch neue Varianten bereichert wird Dar ber hinaus zeigt der Befund aus den untersuchten Mustern und Vertr gen hinsichtlich bedeutsamer Einzelfragen dass es teilweise nur schwer oder gar nicht gelingt Freir ume und Defizite im rechtlichen Rahmen auszugleichen Schlie lich besteht ein unabweisbares internationales Interesse an einer L sung Software wird weltw
374. ting the performance standards set forth in this Article 3 and FDRI s performance during the just concluded calendar month relative to those performance standards Within fifteen 15 business days after the end of said calendar month FDRI shall then review this report with PRODIGY Included in each such report shall be an analysis of the data used to derive FDRI s performance experience b If FDRI fails to perform in accordance with any 3 of the performance standards set forth in Section 3 1 1 and not identified as critical FDRI shall credit PRODIGY with a reduction on its bill for processing services during the such month If such failure continues with respect to such standards for a such month FDRI shall credit PRODIGY with a reduction on its bill for processing services during such month If such failure continues with respect to such standards for a such month FDRI shall credit PRODIGY with a reduction on its bill for processing services during such month If such failure continues with respect to such standards for a such month FDRI shall credit PRODIGY with a reduction on its bill for processing services during such month and on the processing services bills for any and all consecutive succeeding months in which such failure continues c If FDRI fails to perform in accordance with any 3 of the performance standards set forth in Section 3 1 1 and identified as Critic
375. tions SMS maintenance and MAS operations under the direction of the Project Managers to ensure the completion of the SMS and MAS projects as specified in the Joint Detailed Project Plan 85 Kapitel 4 Empirischer Befund in den USA Spezifikation umgesetzt die der Softwarebesteller im Anschluss daran seinerseits auf eine akkurate Abbildung der Vorgaben hin pr ft 5 NEEDS AND REQUIREMENTS The parties hereto agree that a Customer has communicated its needs and requirements to Vendor and has indicated what if any unusual conditions or uses needed to be taken into account by Vendor in preparing its proposal b Vendor has evaluated the information supplied by Customer and has provided Customer with a detailed Vendor Specification Schedule A setting forth Vendor s understanding of Customer s needs and requirements as well as the items including detailed specifications which will satisfy the needs and requirements contained therein c The specifications set forth in the Vendor Specification shall be deemed to constitute the maximum specifications to be met by the items listed therein d Customer has carefully reviewed the Vendor Specification Schedule A and is satisfied that its needs and requirements are accurately and completely described and that the items contained in Schedule A will satisfy these needs and requirements so long as the listed specifications are met Any errors omissions of ambiguities are not to deemed to re
376. tleistungspflichten und bilden mit Ausnahme der Wartung eine unteilbare Leistung Im Fall der Zerst rung der Software wird der Auftragnehmer bei aufrechtem Wartungsvertrag innerhalb von einem Werktag eine Kopie der jeweiligen Software kostenlos nachliefern DF bzw Versand Kurier oder innerhalb von zwei Werktagen die notwendigen Arbeiten zur Installation der Software beginnen Aus S 2 Nr 3 ergibt sich dass das Pflichtenheft vom Softwarebesteller vorgelegt wurde Die hier festgeschriebene Pr fpflicht auf Sinnhaftigkeit macht dabei wenig Sinn solange es an einem Bezugsrahmen fehlt Selbst soweit hier sehr allgemein von den Interessen des Softwarebestellers ausgegangen wird so ergibt sich daraus infolge der Subjektivit t kein geeigneter Kontrollma stab Dabei stellt das gepr fte Pflichtenheft nach der unmittelbar folgenden Nr 4 keine vollst ndige Leistungsbeschreibung dar Es bedarf vielmehr noch einer genauen Definition durch einen Probebetrieb der Vorversionen MiN besteht aus einem als Werkvertrag bezeichneten Hauptvertrag und vier Anlagen n mlich einem Source Code Nutzungsvertrag einem Pflichtenheft einem Abweichungsbericht mit Priorisierung Stand X und den Bedingungen des Angebotes vom X 171 Kapitel 6 Empirischer Befund in Deutschland Der Vertragsgegenstand ist unter 1 Vertragsgegenstand geregelt 1 1 Gegenstand dieses Vertrages ist die vollst ndige und fun
377. to make an effort to convert that into the degree of precision that is required to write specifications that are adequate to write a computer program which is precise Georgetown School of Arts and Sciences v Microsystems Engineering Corp 984 WL 564182 1984 Das Verfahren wurde allerdings zu Gunsten des Softwarehauses entschieden weil der Besteller keine wesentlichen Fehler nachweisen konnte Dreier Company Inc v Unitronix Corp And Andrew Yasenchak 527 A 2D 876 1986 mit Verweis auf Hundred East Credit Corp v Eric Schuster 212 N J Super 357 Hier wurde das klagende Unternehmen in den Anwendungsbereich des Konsumentenschutzes einbezogen da Even the most world wise business entity can be inexperienced and uninformed in a given consumer transaction Unlawful practices thus can victimize business entities as well as individual consumers So wurde das Vorbringen des Kl gers er sei nicht erfahren genug gewesen in einem Verfahren bzgl der Anwendbarkeit einer vertraglichen Haftungsausschlussregelung des Softwarelieferanten als unglaubhaft zur ckgewiesen Buyer was hardly the sheep keeping company with wolves that it would have us believe Colonial Life Ins Co of America v Electronic Data 817 F Supp 235 1993 So wurde die Klage eines Bestellers vollst ndig abgewiesen weil er kein ausreichendes Personal im Projekt besch ftigte einen key Mitarbeiter entlie und die Dateneingabe vernachl ssigte Baeco Plastic
378. trennen zu wollen Zum anderen u ern sie sich in deren Wunsch nderungen im Griff zu haben d h sich durch detaillierte Verfahren vor Unvorhergesehenem zu sch tzen Das Bed rfnis nderungen formal zu erfassen f hrt daher in den deutschen Mustern teilweise zu fraglichen Detailregelungen die bisweilen wie hilflose Versuche wirken die Ver nderungen innewohnende Unsicherheit zu vermeiden Angemessene Reaktionsmechanismen f r den Wandel der Anforderungen sind also weitgehend nicht vorgesehen C Einbindung des Softwarebestellers Mitwirkungspflichten Die Leistungsbestimmung in Softwareentwicklungsvertr gen ist ohne Mitwirkung des Softwarebestellers nicht m glich Dies hat sich im ersten Kapitel aus informationstechnischer Sicht gezeigt und wurde im f nften Kapitel von zahlreichen Autoren aus juristischer Sicht best tigt Hier soll daher die Frage beantwortet werden ob und ggf wie der Softwarebesteller 537 In einem vom Verfasser im Rahmen der Untersuchung gef hrten Interview unterstrich ein Interviewpartner dass die Softwareh user in den 19 80er Jahren infolge der Situation von Angebot und Nachfrage eine deutlich bessere Verhandlungsposition gehabt h tten 538 Ausgegangen wurde dabei von der manchmal illusorischen Vorstellung der Vertrag werde als eine gelebte Vereinbarung die das R ckgrat des Projektes darstellt und nicht als das mehr oder weniger berfl ssige Produkt der Rechtsabteilungen bzw juristischen Be
379. tstehung sind Millionen von Menschen beteiligt und der ganz Uberwiegende Teil der Menschheit ist auf seine Existenz angewiesen sei es zur Energieversorgung zur Kommunikation oder zum Transport Moderne Kraftwerke Telekommunikationseinrichtungen und Fahrzeuge kommen ohne Software nicht aus Noch deutlicher macht sich der Einfluss von Software dort bemerkbar wo sie als Gebrauchsgegenstand zur Unterstutzung oder als zentrales Medium fur die eigene Arbeit dient Neben der Hardware und den eigentlichen Daten nimmt die Software eine herausgehobene Position ein Sie dient als Schnittstelle zwischen Mensch und Maschine und erfullt im wesentlichen zwei Aufgaben Zum einen steuert sie die technische Ausstattung wie Gro rechner Arbeitsstationen und deren Peripherie aber auch Aufz ge Fahrzeuge oder ganze Produktionsanlagen Zum anderen erm glicht und definiert sie die Einflussm glichkeiten des Anwenders auf diese Steuerung Programmtechnische Vorgaben ben einen dauerhaften und pr genden Einfluss auf die Arbeitsumgebung und Arbeitsabl ufe in einer Vielzahl von Bereichen aus Neben der Informationstechnologie ist daher auch in zunehmendem Ma e die Rechtswissenschaft weltweit mit Fragestellungen bez glich Software befasst Dies beginnt mit der Frage was Software eigentlich ist wie sie entsteht und erstreckt sich ber die Konfliktl sung in Projekten aller Art vor allem auf die Entwicklung eines geeigneten rechtlichen Rahmens Die vorl
380. twarehaus verpflichtet die Software in conformity with the specifications and performance standards set forth in Exhibit A zu entwickeln ohne die Festlegung wer die Spezifikationen erstellt Bei DaS zeigt sich eine deutliche Differenzierung hinsichtlich Softwarebesteller und Softwarehaus orientierter Variante DaS V spricht zwar nicht aus wer die Anforderungen formuliert auferlegt dem Softwarebesteller aber unter Nr 1 S 2 die Pflicht eine entsprechende Anlage auf Vollst ndigkeit und Richtigkeit zu berpr fen Customer acknowledges that it has carefully reviewed Attachment A which fully sets forth all of Customer s requirements and that Vendor s compliance with it shall constitute satisfactory performance under this agreement Anders stellt sich dies bei DaS U dar Hier wird das Softwarehaus im Rahmen der ersten Projektphase verpflichtet die Bed rfnisse der Softwarebestellers zu eruieren 2 Project Phases a Phase I System Definition i The first task to be undertaken by Vendor is the investigation of all of User s computer needs and the preparation of a detailed written report summarizing those needs and the specifications for the system meeting those needs Such specifications to be identified by phase hereinafter referred to as the Design Document shall include but not be limited to descriptions of functionality response time for critical functions input formats record layouts output reports
381. ty d h einen Erf llungsma stab begr nden Im Hinblick auf Softwareentwicklungsvertr ge hat zudem die Regel Bedeutung erlangt wonach ein K ufer der sich auf die F higkeiten und das Urteil des Verk ufers bei der Auswahl der Waren verl sst soweit der Verk ufer von einem bestimmten Zweck f r den die Waren ben tigt werden wissen musste erwarten kann dass sie f r diesen Zweck auch geeignet sind Die Gerichte ber cksichtigen in jedem Einzelfall unabh ngig von der Anwendbarkeit des U C C die durch den Vertrag dessen Durchf hrung und ggf entsprechende Handelsbr uche begr ndeten Pflichten im Detail was in 58 Dies gilt zun chst hinsichtlich der Frage ob berhaupt erf llt wurde oder nicht Nach der perfect tender rule kann der K ufer die Ware zur ckweisen wenn sie auch nur geringf gig von der vertraglichen Vereinbarung abweicht 8 2 601 U C C Diese Regel ist jedoch einiger Kritik ausgesetzt und es sind zahlreiche Ausnahmen im Code selbst und durch Gerichtsentscheidungen vorgenommen worden u a f r den Fall dass Waren wie bei Softwareentwicklungsvertr gen die Software speziell f r den K ufer gefertigt wurden vgl Calamari Perillo 11 20 S 421 Demgem hat sich in dem untersuchten Case Law keine Partei jemals auf die perfect tender rule berufen vgl auch oben Kapitel 3 D I S 50 Bei Nichtanwendbarkeit des U C C ist der Ma stab due care s o Kapitel 3 C 1 4 S 46 549 2 106
382. tzbuch Hrsg Herausgeber h M herrschende Meinung l i d R in der Regel IEEE Institute of Electrical and Electronic Engineers IHR Internationales Handelsrecht Zeitschrift Inc Incorporated Incl einschlie lich i S im Sinne ISO International Standard Organisation IT Informationstechnologie ITIL IT Infrastructure Library ITRB IT Rechtsberater Zeitschrift K K amp R Kommunikation und Recht Zeitschrift KG Kammergericht KM Konfigurationsmanagement L L Law LG Landesgericht Itd limited M MAS Member Administrative System m a W mit anderen Worten m E meines Erachtens MMR Multimedia und Recht Zeitschrift Mot Motive MPEG Moving Picture Experts Group Standard zur Komprimierung von Dateien M Ko M nchener Kommentar m w Nachw mit weiteren Nachweisen N NCCUSL National Conference of Commissioners on Uniform State Laws NJW Neue Juristische Wochenschrift Zeitschrift IX Dissertation Softwareentwicklungsvertrage NJW RR Nr oO o OLG OLGR ORACLE P PC PM Q QS R Rev RFP Rn Rs Rspr S S s a SMS S 0 sog UNCITRAL UrhG usw V vV v a VB vgl W WAV WL WM Abk rzungen Neue Juristische Wochenschrift Rechtsprechungsreport Zeitschrift Nummer oder hnlich Oberlandesgericht Oberlandesgericht Report Entscheidungssammlung ein Datenbanksystem Personal Computer Produktmanagement Qualit tssicherung Review Request for Pro
383. uenten Abarbeiten der einzelnen Abschnitte aus wobei jede Stufe so lange durchlaufen wird bis ein vollst ndiges und fehlerfreies Ergebnis vorliegt Der R cksprung erfolgt dabei nur auf die jeweils vorgelagerte Stufe Im Spiralmodell werden in jeder Phase von der ersten Formulierung der Anforderungen bis zum produktiven Einsatz definierte Zyklen durchlaufen 2 Dieses Modell wurde 1988 von Barry Boehn mit dem Ziel vorgestellt die Risiken der Softwareentwicklung zu reduzieren McManus Wood Harper a a O S 83 14 Kapitel 2 Softwareentwicklung in der Praxis Festlegung von Zielen Alternativen und Randbedingungen Risikoanalyse und ggf Entwurf von Prototypen Entwurf Design und Pr fung Implementation und Planung der nachsten Phase u or Ziele Alternativen u Randbedingungen Risiko Analyse erkennen Prototyping Requirements Design N chste Phase planen Implementation Validierung Verifikation Test Das Spiralmodell ist eine Weiterentwicklung des Wasserfallmodells wobei durch die Risikoanalyse und das Prototyping bei jedem Schritt die Entwicklung von Kosten und Zeitplan besser im Auge behalten werden kann Die unterschiedliche Terminologie sollte freilich nicht dar ber hinwegt uschen dass die zeitliche Abfolge der einzelnen Schritte von der Projektdefinition hier Vorstudie bis zur Systemeinf hrung hier Installation unver ndert geblieben ist Das Spi
384. uftretender Programmelemente bestehen ein Baukastenprinzip zunutze Die sog objektorientierten Programmiersprachen z B versuchen auf diesem Weg der Kombination bereits entwickelter L sungen zum Ziel zu gelangen Es tritt die M glichkeit einer Verbindung von Standardsoftware mit Individualsoftware hinzu wie sich am derzeit h ufig anzutreffenden Beispiel des Verkn pfens einer individuell programmierten Website mit Hintergrundanwendungen wie etwa einer Datenbank zeigen l sst Hinsichtlich ihrer Gr e und der Gliederung in Teile k nnen Softwareprojekte wie folgt eingeteilt werden Organisationsgr e Klein Mittel Gro Sehr gro Entwickler lt 10 gt 10 gt 300 gt 1000 Anzahl lt 4 gt 4 gt 50 gt 130 Teil Projekte Entwickler Projekt 4 5 6 8 8So bei Spitta Thorsten Scriptum Informationsmanagement S 5 abrufbar zuletzt 12 12 05 unter http www wiwi uni bielefeld de spitta download IM3 pdf die Zahlenangaben sollen und k nnen lediglich einen Eindruck von der unterschiedlichen Aufgabenstellung abh ngig von der Anzahl der beteiligten Personen geben TE Kapitel 1 Allgemeiner Teil Beispiele f r Gro projekte sind die Entwicklung eines Navigationssystems f r Kfz oder die Entwicklung eines Warenwirtschaftssystems f r eine Handelskette Mittlere Projekte sind die Entwicklung einer betriebswirtschaftlichen Software f r ein mittelst ndisches Unternehmen mit mehreren
385. ulty of determining and calculating its damages upon FDRI s failure to perform in accordance with the performance standards included in this Article 3 the remedies set forth in this Article 3 and Section 2 2 2 2 of this Agreement shall be PRODIGY s sole and exclusive remedies and PRODIGY hereby elects to waive any and all other remedies to which PRODIGY may be entitled under this Agreement for any claim based on FDRI s failure to perform in accordance with such performance standards Die Einstandspflicht des Softwarehauses wird unter d im Hinblick auf Ereignisse begrenzt die au erhalb seiner Einflusssphare liegen Interessant ist die den Haftungsumfang erkl rende und begrenzende Regelung unter e Dies verleiht den im Vertrag fixierten Anforderungen an die Leistungserbringung zus tzliches Gewicht Ein Schwerpunkt bei OD liegt auf termingerechter Vertragserf llung Wird diese nicht erbracht fallen betr chtliche Abz ge hinsichtlich ausstehender oder erbrachter Zahlungen bzw Vertragsstrafen an Diese treten anders als bei FP auch neben weitere m gliche Anspr che 12 In addition to any other remedies available to Customer hereunder the amounts payable by Customer to Vendor pursuant to the Agreement shall be reduced by three thousand dollars 3 000 00 for each day that Final Acceptance is delayed beyond its final date for completion in the implementation schedule SCHEDULE G 13 Upon a material breach by Vendor
386. um die Art der bertragung sei jedoch auch hier f r den K ufer unerheblich und dem Ziel einer einheitlichen Rechtsanwendung komme auch nur eine breite Anwendung der UN Konvention unter Einschluss der electronic software entgegen Allerdings k nne dieser Standpunkt nicht auf Individualsoftware ausgedehnt werden Software die nach Vorgaben eines Bestellers speziell angefertigt werde sei Gegenstand eines Dienstleistungsvertrages Eine endg ltige Bewertung erfordere allerdings eine fallbezogene Analyse Im Ergebnis spielt die CISG f r die rechtlichen Rahmenbedingungen von Softwareentwicklungsvertr gen in den USA bisher allenfalls eine untergeordnete Rolle 188 Primak Scott L Computer Software Should the U N Convention on contracts for the international sale of goods apply Computer Law Journal 1991 197 S 215 189 To the extent that the end user is getting something that thing should be governed by the Convention Hervorhebungen im Original Primak a a O S 231 1 Carter J W Article 2B International Perspectives Journal of Contract Law 1999 54 S 66 91 Cox Trevor Chaos versus uniformity the divergent views of software in the International Community Business Law International 2000 S 359 192 Cox a a O S 359 Scott a a O S 8 36 1 Scott a a O S 8 41 48 Kapitel 3 Rechtliche Rahmenbedingungen in den USA Ill Uniform Computer Information Transaction Act UCIT
387. ung dass Softwareverk ufe Alltagsgesch fte darstellen und die Parteien berechtigterweise erwarten k nnen zumindest ein Gesetz regele den Verkauf und der U C C erf lle diese Erwartung eher als das Common Law Immer wieder findet sich zudem die Auffassung der 15 Austin s of Monroe Inc v Bill Brown 474 So 2D 1383 Supreme Judicial Court of Massachusetts 4 02 80 16 Communications Groups Inc Also Known as CGI Plaintiff v Warner Communications Inc 527 N Y S 2d 341 Systems Design and Management Information Inc SDMI v Kansas City Post Office Employees Credit Union 788 P 2d 878 N Distr Court Texas 28 04 03 1861 Advent Systems Ltd v Unisys Corp 925 F 2d 670 62 Comshare Inc v United States of America 27 F 3d 1142 US Distr Crt S D N Y 03 09 86 in einem steuerrechtlichen Fall Auf die bertragung einer Idee in eine tangible expression stellt auch ab Management Computer Servs Inc v Hawkins Ash Baptie amp Co 557 N W 2d 67 US Crt Appeals 6 Circuit 27 06 94 63 Micro Data Base Systems Inc v Dharma Systems Inc 148 F 3d 649 Appeal from the United States District Court for the Eastern District of Virginia at Alexandria 13 09 95 Populsion Technologies Inc d b a PowerTech Marine Propellers v Attwood Corporation 369 F 3d 896 US District C Northern Ohio East 27 09 01 64 Lan Systems Inc v Netscout Service Level Corp 183 F Supp 2d 328 District Crt New Hampsh
388. ung als Ergebnis eines Forschungs und Technologieprojektes entstanden Die Entwicklung wurde in Zusammenarbeit mit dem Bundesministerium des Inneren BMI und den Verb nden der deutschen Industrie mit dem Ziel betrieben die Softwarekosten einzud mmen die Qualit t der Software zu verbessern und die Abh ngigkeit des Softwarebestellers vom Softwarehersteller zu vermindern Im Jahr 1992 bernahm das BMI das Verfahren f r den zivilen Verwaltungsbereich und machte es damit zu einem Standard f r den ffentlichen Bereich Es hat auch dar ber hinaus in der Privatwirtschaft Anerkennung gefunden wo es als Entwicklungsstandard in vielen Unternehmen Verwendung findet 31 Dieser Grundgedanke findet sich bereits bei Brooks Mythos S 102 Prototyping wird insbesondere bei Projekten die der Benutzerschnittstelle und oder der Interaktion mit dem Anwender gro e Bedeutung beimessen als sinnvoll angesehen vgl McManus Wood Harper S 84 32 Suhl in Fischer Herold Dangelmaier Nastansky Suhl Bausteine der Wirtschaftsinformatik 3 Aufl Berlin 2002 S 375 33 Br hl Dr schel Das V Modell 2 Aufl M nchen 1995 S 150 34 Br hl Dr schel a a O S 16 gt Hansen Neumann a a O S 211 eine Liste offizieller Verwender des V Modells aus Deutschland Osterreich und der Schweiz findet sich unter www v modell iabg de VM Anwender html 16 Kapitel 2 Softwareentwicklung in der Praxis Das V Modell ist ein sehr umfangre
389. ung von Software meist weitere Leistungen erbracht Dann entscheidet der sog predominant factor Test ber die Einordnung The question becomes whether the dominant factor or essence of the transaction is the sale of the materials or the service Im Ergebnis ist nicht sicher vorhersehbar ob amerikanische Gerichte den U C C anwenden oder nicht Der Prozess der Meinungsbildung ist noch 2000 2000 WL 225940 weitere Nachweise bei Scott a a O 7 09 A S 7 30 172 Nachweise unter Advent Systems Ltd v Unisys Corp 925 F 2d 670 3rd Cir 1991 S 675f 3 Advent Systems Ltd v Unisys Corp a a O S 674f 174 Advent Systems Ltd v Unisys Corp a a O S 676 ebenso Systems Design and Management v Kansas Credit Union 788 P 2d 878 Kan App 1990 175 Siehe auch oben S 36 Fn 130 6 Richard A Rosenblatt amp Company Inc Appellant v Davidge Data Systems Corporation et al 743 N Y S 2d 471 2002 N Y App Div LEXIS 6154 Propulsion Technologies Inc d b a PowerTech Marine Propellers Plaintiff Appellee Cross Appellant v Attwood Corp 369 F 3d 896 2004 US App LEXIS 10429 ePresence Inc Plaintiff v Evolve Software Inc 190 F Supp 2d 159 2002 US Dist LEXIS 3742 David B Page v R William Hotchkiss 2003 Conn Super LEXIS 3341 52 U C C Rep Serv 2d Callaghan 365 77 Incomm Inc v Thermo Spa Inc 41 Conn Sup 566 570 595 A 2d 954 3 Conn L Rptr 346 1991 44 Kapitel 3 R
390. ung von Software zur Lagerverwaltung Sie verf gt ber Erfahrungen mit Konzeption und Realisierung von EDV L sungen 1 2 Kunde Der Kunde ist ein mittelst ndisches Unternehmen das mit Kfz Zubeh rteilen handelt Der Kunde verf gt ber Erfahrung im Umgang mit Software zur Lagerverwaltung und genaue Kenntnis dar ber welche betrieblichen Prozesse durch die Lagerverwaltung erledigt werden sollen Der Kunde best tigt dass er kein EDV Laie ist und genau wei was er will Das Softwarehaus best tigt demgegen ber nur dass es ber EDV Fachkenntnisse verf gt jedoch weder dass es die betrieblichen Umst nde beim Kunden noch dessen Intentionen genauer kennt Es h tte daher deutlich geringere Schwierigkeiten damit bei einer Auseinandersetzung darauf zu verweisen ein Umstand sei ihm nicht bekannt gewesen und habe auch nicht bekannt sein m ssen Was im Ergebnis geschuldet wird beschreiben die Muster sehr unterschiedlich HE betont in 1 Entwicklungsziel die Gemeinsamkeit des Entwicklungsprozesses Das Ziel der Zusammenarbeit ist der gemeinsame Aufbau eines Management Informationssystems MIS das sich an den technischen und wirtschaftlichen Anforderungen von E Anm dem Softwarebesteller sowie an den Qualit tsstandards des Weltmarktes orientiert SO formuliert in 2 berschrieben mit Austauschvertrag Mit dem vorliegenden Vertrag werden Leistungen ausgetauscht Eine gesellschaftsrechtliche Ver
391. unterstreicht Seffer wenn er anmerkt kein gesetzliches Leitbild passe Im allgemeinen Vertragsrecht wird teilweise ausdr cklich von einem Ausschluss des dispositiven Rechts und der Notwendigkeit erg nzender Vertragsauslegung ausgegangen wenn der gew hlte Vertragstyp gesetzlich nicht geregelt ist oder der Interessenlage der Parteien nicht entspricht 2 Typenauswahl und Einordnungskriterien Folgt man der in weiten Teilen der Fachliteratur betriebenen Suche nach einem gesetzlichen Typus so l sst sich keine einheitliche Tendenz feststellen In Betracht gezogen werden der reine Werkvertrag nach 631ff BGB sowie die nach 651 S 3 modifizierten ber 651 S 1 BGB anzuwendenden Kaufvertragsregeln Vereinzelt finden sich auch eine vom 341 M ller Hengstenberg CR 2005 S 385 342 Sefferi Horter ITRB 2005 S 169 343 Hoeren a a O S 57 344 Hoeren a a O S 171 345 a a 0 8 3 346 a a O S 21 34 Seffer Horter ITRB 2005 S 169 348 Bamberger Roth Wendtland 157 Rn 39 Erman Armbr ster 157 Rn 19 AnwK Looschelders 157 Rn 10ff der in diesem Zusammenhang auch auf die Unbeachtlichkeit des dispositiven Rechts in den Fallen hinweist in denen das in Frage stehende Gesetzesrecht veraltet ist weil es den geanderten wirtschaftlichen Verh ltnissen nicht mehr gerecht wird M Ko Mayer Maly Busche 157 Rn 36 in Rn 11 bemerken sie allerdings dass Rechtsnormen berhaupt der be
392. ur Schlussfolgerungen hinsichtlich der Leistungsbestimmung 253 Vertrag zwischen OMT Technologies Inc aus Winnipeg Manitoba in Kanada und der DMX Inc aus Los Angeles Kalifornien ber Software Service und Supportleistungen unterzeichnet im M rz 1993 EDGAR Central Index Key 0001040449 File No 00022815 v CORI File No 1040449 98 001350b html Dass es sich bei dem Softwarehaus um ein kanadisches Unternehmen handelt kann hier vernachl ssigt werden da der Vertrag dem kalifornischen Recht unterstellt wurde siehe Nr 28 des Vertrages zumal das kanadische Rechtssystem mit Ausnahme des Bundesstaates Quebec wie das der USA auf dem englischen Common Law basiert Das Softwarehaus wird im Vertragstext als Vendor der Softwarebesteller als Customer bezeichnet Siehe sogleich S 82 255 Bemerkenswert ist dabei dass die Gliederung nach alphabetisch angeordneten Themen von A wie Acceptance bis W wie Work done by others angeordnet ist 25 Unter Nr 22 257 Hier wird die extensive Formulierung aus FP Nr 9 6 wiedergegeben 80 25 gt Kapitel 4 Empirischer Befund in den USA Wahrend bei AE eine exklusive Lizenz des Softwarebestellers vorgesehen ist findet sich bei OD nur das Einr umen einer einfachen nicht Ubertragbaren Lizenz deren Ubergang zudem von der Abnahme und der vertragsgem en Zahlung abh ngig sein soll In FP wird ausdr cklich darauf hingewiesen dass s mtlic
393. urchdringung der Gesellschaft zunehmend ein vorhandener Bestand an Hard und Software Viele Projekte m ssen neue Bestandteile mit alten verkn pfen oder auf Grundlage der alten neue entwickeln Entwicklung in dem hier verstandenen Sinn umfasst daher auch komplexe Anpassungen Keine Unterscheidung findet ferner zwischen der Entwicklung von Standard und Individualsoftware statt Deren Dynamik wird bei unterschiedlicher Akzentuierung im Einzelfall als vergleichbar vorausgesetzt Auf notwendige Differenzierungen z B bzgl der Frage ob die Lieferung des Quellcode Bestandteil der Leistungspflicht ist vgl dazu zuletzt Redeker CR 2005 S 700 704 wird im Rahmen der vorliegenden Untersuchung nicht eingegangen En Kapitel 1 Allgemeiner Teil 1 ALLGEMEINER TEIL Kapitel 1 Gang der Untersuchung Bedeutung der IT Branche und Einf hrung in die Begriffe Software und Leistungsbestimmung A Gang der Untersuchung Diese Arbeit untersucht Softwareentwicklungsvertrage im Hinblick auf die zentrale Frage der Leistungsbestimmung Sie wird aus drei Perspektiven beleuchtet Aus der Sicht der Informationstechnologie Software Engineering Kapitel 2 aus der Sicht der US amerikanischen Rechtsordnung Kapitel 3 und 4 und aus Sicht der deutschen Rechtsordnung Kapitel 5 und 6 In den Blickpunkt werden dabei fur die Praxis vorgesehene Muster und in der Praxis verwendete Vertrage gestellt und anschlieRend miteinander und mit den Anfor
394. ustomer hereby acknowledges and agrees that any warranties included herein do not extend or apply to Customer s use of any attachment feature or software on or in conjunction with the System or any item element or component thereof which has not been furnished pursuant to this Agreement or which has not been approved in writing by Vendor c Customer understands and agrees that Vendor Vendor s supplier or suppliers and the manufacturers developers or distributors of the items elements and components of the System are not engaged in a joint venture and subject to Article 15 that Vendor has no intention obligation or duty to warrant and or represent the quality performance and condition of such deliverables on their behalf Im Anhang findet sich dann ein Anforderungsma stab der kaum extensiver formuliert zu werden vermag Die Software soll danach u a nicht nur in bereinstimmung mit den vereinbarten Anforderungen funktionieren sowie keine bekannten Fehler oder einen Virus enthalten sondern alle gegenw rtigen und vern nftigerweise zu erwartenden W nsche der Softwarebestellers erf llen Vendor represents and warrants to Customer that a the System will be capable of fulfilling all of Customers current and reasonably anticipated needs in an efficient and commercially desirable and competitive manner b there are no problems or defects including viruses known to Vendor in the System c the System does not contain any limi
395. utend ist mit einer Verantwortlichkeit f r das Ergebnis dieses due care w hrend bei Anwendbarkeit des U C C die Einstandspflicht aus den implied oder express warranties abgeleitet werden kann 182 Definiert in 1 303 c U C C A usage of trade is any practice or method of dealing having such regularity of observance in a place vocation or trade as to justify an expectation that it will be observed with respect to the transaction in question The existence and scope of such a usage must be proved as facts If it is established that such a usage is embodied in a trade code or similar record the interpretation of the record is a question of law 183 2 311 1 U C C Options and Cooperation Respecting Performance Good faith ist in 1 201 20 definiert als honesty in fact and the observance of reasonable commercial standards of fair dealing 184 2 311 3 U C C die Hauptfolge der Behandlung einer dem gem en Unterlassung als Vertragsbruch ist die Option Schadensersatz neben der Leistung Zu verlangen 46 Kapitel 3 Rechtliche Rahmenbedingungen in den USA ll Convention on Contracts for the International Sale of Goods CISG Die United Nation Convention on Contracts for the International Sale of Goods CISG wurde anlasslich der 97 Diplomatischen UN Konferenz der Vereinten Nationen in Wien am 11 April 1980 verabschiedet und ist fur die Vereinigten Staaten seit dem 1 Januar 1988 in Kraft
396. verst ndliche Erfahrung aus der Praxis wiedergegeben Den Grund f r das regelm ige nderungsverlangen des Softwarebestellers sieht Brooks in der Unsichtbarkeit und Fugsamkeit des Produktes Das Ber cksichtigen dieser nderungen kann auf verschiedene Weise geschehen Zum einen sollte von Anfang an damit gerechnet werden dass bereits erfolgte Entwicklungen wieder verworfen werden Zum anderen kann dem Softwarebesteller schon zu einem fr hen Zeitpunkt ein stark vereinfachter Entwurf vorgelegt werden Diese Prototyping genannte Methode wird deswegen verwendet weil sie es dem Anwender am ehesten erlaubt seine eigenen Vorstellungen anhand des Vorgefundenen zu artikulieren Gleichwohl kann auch in diesem Fall nicht mit ihrem dauerhaften Bestand gerechnet werden aber die Methode der Leistungsbestimmung vermittelt zumindest Erfahrung und hilft fr hzeitig dabei Entwicklungen in die falsche Richtung zu korrigieren des Softwarehauses Zehnder empfiehlt die Zusammensetzung der Projektleitung aus zwei Personen wobei einer vom Softwarebesteller stammt a a O S 188f ferner soll ein qualifizierter Anwender zwingend in Vollzeit ber einen gewissen Zeitraum im Projektteam mitarbeiten um die Gestaltung der k nftigen Funktionen und Arbeitspl tze zu erm glichen S 190f 8 A a O S 75 87 Suhl Blumstengel in Fischer Herold Danglmayer Nastansky Suhl a a O S 372 Etzel Heilmann Richter a a O S 174 Heinrich a
397. vgl Macneil Gudel S 95 Das angesehene American Law Institute ALI ver ffentlichte sein Restatement 1932 zum ersten Mal Die Konzeption ist der eines Gesetzes vergleichbar 385 88 in drei Banden 16 Kapiteln die in sog Topics unterteilt sind z B in dem Kapitel 3 Formation of Contracts Mutual Assent das Topic In General gefolgt von Manifestation of Assent in General und Making of Offers usw Die zweite Auflage der Restatement of the Law of Contracts wurde 1962 begonnen 1979 abgeschlossen und 1981 ver ffentlicht Ihre Bedeutung wird von Calamari Perillo mit den Worten it is a highly persuasive authority gekennzeichnet The Law of Contracts 4th Edition St Paul 1998 S 15 Convention on the International Sale of Goods CISG prepared by the United Nations Commission on International Trade Law UNCITRAL and adopted by a diplomatic conference on 11 April 1980 adopted by the United States on December 11th 1986 effective on January 1 1988 139 Zu der Frage ob Software in den Anwendungsbereich der CISG f llt s u S 47 14 Macneil Gudel a a O S 96 141 Urspr nglich vorgesehen als Article 2B des Uniform Commercial Code U C C 2B Der Originaltext ist erhaltlich Uber die University of Pennsylvania Law School unter http www law upenn edu bll ulc ulc htm ucita siehe unten unter III Calamari Perillo a a O S 611 Calamari Perillo a a O S 611ff dazu z hlen traditionsgem Immobil
398. volumes as they relate to applications of the Management System provided however that the supplying of such information shall not be deemed to alter or supplement in any manner the description of the existing System contained in Schedule A hereto or the description of the changes and modifications necessary to the Existing System in order to develop the Management System which changes and modifications are specified in Schedule B hereto b install and maintain at the location referred to in paragraph 3 hereof the hardware and system software specified in Schedule D hereto the System Configuration c make available to each Licensor employee located in Licensee s premises test time on the System Configuration in the amount of at least 30 hours of which shall be between 9 00 a m and 5 00 p m on business days which availability shall include sufficient disc storage space to permit Licensor to develop and test the Management System and access to the 3738 Kapitel 4 Empirischer Befund in den USA System Configuration through at least one dedicated terminal for each Licensor employee at the Licensee s premises d set up format and make available to Licensor the frames and tables specified in Schedule E hereto e make available to Licensor personnel of Licensee testing the Management System and training users of the Management System f provide one employee of Licensee who shall have substantial
399. warebesteller und Softwarehaus bereits zum Zeitpunkt der Pflichtenhefterstellung festlegen woran der Projekterfolg gemessen werden wird Allein die Tatsache dass der Notwendigkeit dieses Zusammenhanges besondere Bedeutung beigemessen wird wirft ein bezeichnendes Licht auf den Entwicklungsprozess von Software Das Modell f r die Softwareentwicklung hier i S einer Skizze des fertigen Produktes ist keine sinnlich wahrnehmbare Konstruktion wie das Modell eines B rogeb udes oder einer Br cke sondern ein auf Beschreibung in Worten und Zahlen angewiesenes Dokument 2 Mitarbeit des Softwarebestellers Wie oben bereits angedeutet ist die Rolle des Softwarebestellers auch und gerade im Rahmen der Erstellung des Pflichtenheftes von zentraler Bedeutung Die Gestaltung der Benutzeroberfl che wird sinnvollerweise vom Softwarebesteller bestimmt Seine Mitarbeiter sind es die in den folgenden Jahren mit den entsprechenden Masken arbeiten werden Geht man davon aus dass ein Softwaresystem in erster Linie durch die Ausgaben die es seinem Benutzer zur Verf gung stellt definiert ist so wird dieser Aspekt nochmals unterstrichen Hinsichtlich der richtigen Abbildung der Realit t durch die Software d h der vollst ndigen Auswahl der richtigen und wichtigen Daten ist der Softwarebesteller zudem jedenfalls kompetenter als das Softwarehaus F r das Einbinden der Software in die betrieblichen Abl ufe und wenn es darum geht die fachlichen
400. warehaus neben konkreten vertraglichen Obligationen zur Einhaltung allgemeiner Standards Supplier represents to Company and its customers that the Work will be performed in a worker like manner in accordance with professional standards in the field and subject to the acceptance criteria established in this Agreement or the Authorization Letter Die starke Position des Softwarebestellers in AE zeigt sich u a in dessen Berechtigung einen Austausch von Mitarbeitern verlangen zu k nnen Company has the right at any time for reasonable cause prior to and after assignment to Company s Work to reject or have Supplier remove Suppliers employee s from the Work under this Agreement upon notice to Supplier Upon such notice Supplier shall at company s request replace the Supplier employee s In the event of any staffing change the Company shall not be charged for the time required to train the replacement The amount of noncompensatory training time if any shall be mutually determined by Supplier and Company s Representative 277 Im Rider unter 5 278 Unter Representation in Section Il 279 Unter Supplier Employees in Section Il 90 Kapitel 4 Empirischer Befund in den USA V Besondere Pflichten des Softwarebestellers Besondere Pflichten des Softwarebestellers finden sich bei AD zunachst hinsichtlich der Arbeitsumgebung angemessene Ausstattung der Arbeitsplatze des Softwarehauses beim Softwarebesteller hinsicht
401. weiterentwickeln zu k nnen Eine Betreuung ber den gesamten Lebenszyklus insbesondere also die Wartung nach der Erstellung ist nicht vorgesehen Ill Spezifikationen und Leistungsma stab Die Spezifikation der Leistung ergibt sich bei MiO aus dem Pflichtenheft und dem noch durchzuf hrenden Probebetrieb der Vorversionen siehe oben MiN bezieht sich daf r auf das Pflichtenheft den Abweichungsbericht und das Angebot des Softwarehauses s o Bei SUS erstreckt sich die Bezugnahme auf Pflichtenheft Angebot Auftragsbest tigung und sog Erg nzungen s o I In den letzten beiden F llen wird dem Pflichtenheft die vorzugsweise Geltung einger umt Dadurch wird sehr anschaulich wie das Bem hen um eine Fixierung der n heren Leistungsbestimmung durch den dynamischen Prozess in dem sie zustande kommt erschwert wird Ein Versuch dieser Unsicherheit zu begegnen findet sich bei MiO im Wege eines extensiv formulierten Leistungsma stabes Absatz und Unternummerierungen wurden erg nzt 13 Qualit tsanforderungen 1 Auftraggeber und Auftragnehmer stimmen berein dass an die Entwicklung von Software hohe Qualit tsanforderungen gestellt werden es aber dennoch nicht m glich ist Software zu entwickeln die mit Sicherheit frei von Fehlern ist 2 Der Auftraggeber erf llt die Qualit tsanforderungen 1 dass bei EDV gest tzten Vorg ngen an allen in Beilage 2 definierten Anlagen bei typischer Lastsituation zur Tages
402. y Post Office Employees Credit Union 788 P 2d 878 N Distr Court Texas 28 04 03 Comshare Inc v United States of America 27 F 3d 1142 US Distr Crt S D N Y 03 09 86 Propulsion Technologies Inc d b a PowerTech Marine Propellers v Attwood Corporation 369 F 3d 896 US District C Northern Ohio East 27 09 01 Systems Design and Management Information Inc SDMI v Kansas City Post Office Employees Credit Union 788 P 2d 878 N Distr Court Texas 28 04 03 Advent Systems Ltd v Unisys Corp 925 F 2d 670 LeSueur Creamery Inc v Haskon Inc 660 F 2d 342 US Court of Appeals 8 Circ 17 9 81 Data Processing Services Inc v L H Smith Oil Corp 492 N E 2d 314 Crt App Indiana 4 Distr 28 4 86 Austin s of Monroe Inc v Bill Brown 474 So 2D 1383 Crt Appeal Lousiana 2d Circuit 21 8 85 Micro Managers Inc v Stanley Oren Terry Coleman 147 Wisc 2D 500 Crt Appeals Wisc 10 11 88 David B Page v R William Hotchkiss 400 N E 2d 1255 Superior Court of Connecticut Windham 2 12 03 Andersen Consulting LLP v Gavin 26 Conn L Rptr 496 Conn Super C 3 2 00 Schroders Incorporated et al Plaintiffs v Hogan Systems Inc 522 N Y S 2d 404 Arlington Electrical Construction Appellant v Schindler Elevator Corporation 1992 Ohio App Lexis 953 Stenograph Corp v Microcat Corp 1990 WL 146754 N D III 1990 Advent Systems Ltd v Unisys Corp 925 F 2d 3rd Cir 1991 670 673 Micro Data Base Systems
403. zeit der gr ten Last in 95 aller F lle Antwortzeiten unter drei Sekunden auftreten Es ist also durchaus m glich dass manche Benutzeraktionen Antwortzeiten von ber drei Sekunden zur Folge haben 2 dass das System so gestaltet ist dass es leicht erlernt und bedient werden kann 178 Kapitel 6 Empirischer Befund in Deutschland 3 dass auch die vorhandenen HP UX Systeme des Auftraggebers verwendet werden k nnen 3 Der Auftraggeber wird Software liefern die ma geblich die folgenden Anforderungen erf llt in 95 aller F lle 1 die nicht nur auf Funktionalit t sondern auch auf Verhalten in Grenzf llen Fehleingaben Anzahl gleicher Transaktionen Datenmengen getestet wurde und 2 f r jedes Formular eine kontextintensive Hilfe anbietet 3 f r jede Eingabe von Werten aus einem vordefinierten Wertebereich eine Liste von zul ssigen Werten anzeigt 4 gegen Fehlbedienung durch Verwendung von Wertebereichspr fungen und Integrit tsregeln abgesichert ist bzw die Benutzer bei kritischen Eingaben auf die m glichen Folgen hinweist 5 deren Sourcecode ausschlie lich den dokumentierten Standardsprachumfang der Programmiersprache von Paradox Object PAL bzw Visual C bzw definierte zus tzliche Werkzeuge verwendet 6 zu deren Installation keine nderungen am Maschinencode des Betriebssystems notwendig sind 7 in der Regel Zahlenwerte wie Prozentwerte Wertgrenzen u aus einer leicht wartbaren Tabelle au erhalb des Prog
404. zum 1 1 1991 in Kraft getreten Da es sich um einheitliches Kaufrecht handelt stellt sich zun chst die Frage ob es auf Softwareentwicklungsvertr ge anwendbar ist 2 IT Recht a a O S 443 ebenso Nicklisch FS Traub 1994 S 305 3 und mit ihr wanke die Einordnung als Werkvertrag Schneider Handbuch a a O S 1485ff 1487 die Pflicht des Softwarehauses zur Konkretisierung nicht ge u erter Vorgaben sei eine berforderung gegen ber dem Auftragnehmer S 1488 494 Schneider Handbuch a a O S 1485 5 Nicklisch FS Traub 1994 S 305 6 Siehe hierzu bereits Kapitel 3 C Il 124 Kapitel 5 Rechtliche Rahmenbedingungen in Deutschland Auch im deutschen Recht wird die Diskussion Uber die Anwendbarkeit der CISG auf Softwareentwicklungsvertrage im Rahmen des Art 3 CISG gefuhrt Der Text der englischen Fassung lautet Article 3 1 Contracts for the supply of goods to be manufactured or produced are to be considered sales unless the party who orders the goods undertakes to supply a substantial part of the materials necessary for such manufacture or production 2 This Convention does not apply to contracts in which the preponderant part of the obligations of the party who furnishes the goods consists in the supply of labour or other services Goods die in der deutschen Fassung als Waren bersetzt werden sind in der CISG nicht definiert Erfasst werden bewegliche Sachen im Gegensatz zu Rechten und Immob
405. zung zur berlassung nur im Objektcode d h ohne die Weitergabe des in der Software verk rperten Know How als Voraussetzung f r eine nderung des Programms durch den Besteller oder von ihm beauftragte Dritte Die Wortwahl berlassung statt z B Erstellung schlie lich weist MA als Vertreter der Ansicht aus die Softwareentwicklungsvertr ge dem modifizierten Kaufrecht zuordnet BA w hlt die offene Bezeichnung Vertrag ber ein Softwareprojekt SO gibt durch den Titel Softwarelizenzvertrag zu erkennen dass er den Schwerpunkt der vertraglichen Regelung in lizenzrechtlichen Fragen sieht HE schlie lich bezeichnet seinen Entwurf als Muster f r einen Evolution ren Software Vertrag zwischen Endanwenderund Softwareunternehmen Die Besonderheit seines Ansatzes ergibt sich hier aus der Betonung des evolution ren Elements der Vereinbarung Die berschreibung der BVB als Besondere Vertragsbedingungen Erstellung schlie lich l t erkennen dass es sich um klassische allgemeine Vertragsbedingungen i S des BGB handelt die f r einen bestimmten Anwendungsbereich n mlich die Erstellung in Abgrenzung zu Planung und Pflege f r die unterschiedliche BVB existieren vorgesehen sind 510 Die von HE vorgestellte Variante Muster zwischen zwei Softwareunternehmen enth lt keine f r den Untersuchungsgegenstand durchgreifenden Unterschiede 131 Kapitel 6 Empirischer Befund in Deutschland Alle

Download Pdf Manuals

Related Search

Related Contents

Philips Jam Jacket CordSaver DLA66006D  OWNERS_MANUAL_-_RT50-R_Scooter_Owner  SIDEXIS Ó Intraoral  SPLENDOR LED MANUEL D`UTILISATION    3000 Series User Manual  Precauzioni per la sicurezza  - Oracle Documentation  PORTUGUÊS  

Copyright © All rights reserved. Failed to retrieve file