Softwareentwicklungsverträge
| dc.contributor.author | Kath, Peter | |
| dc.date.accessioned | 2023-02-09T15:32:20Z | |
| dc.date.available | 2006-10-23T11:59:11Z | |
| dc.date.available | 2023-02-09T15:32:20Z | |
| dc.date.issued | 2006 | |
| dc.identifier.uri | http://nbn-resolving.de/urn:nbn:de:hebis:26-opus-36766 | |
| dc.identifier.uri | https://jlupub.ub.uni-giessen.de//handle/jlupub/10163 | |
| dc.identifier.uri | http://dx.doi.org/10.22029/jlupub-9547 | |
| dc.description.abstract | Das Problem: Softwareentwicklungsverträge (SEV) steuern komplexe Langzeitverträge. Die vier zentralen Aspekte der Vertragsbeziehungen sind: (1) Stufenweise Konkretisierung der Leistungs-bestimmung, (2) Häufige Änderungen, (3) Notwendigkeit der Kooperation und (4) die Schwierigkeit einen geeigneten Qualitätsmaßstab zu finden. (1) Softwareentwicklungsprojekte (SEP) sind einer Reise ohne präzises Ziel vergleichbar. Existiert überhaupt eine Leistungsbeschreibung, so ist sie häufig fehlerhaft oder unvollständig. Die Verantwortlichkeit für ihre Erstellung ist, wenn es zu Auseinandersetzungen kommt, häufig streitig. (2) Mit Änderungen muss stets gerechnet werden. Diese Erfordernis spiegelt sich regelmäßig nicht in den SEV wider oder ist unausgewogen gestaltet. (3) Die Entwicklung von Software erfordert grundsätzlich eine enge Zusammenarbeit der Parteien. Im Gegensatz dazu erlauben SEV häufig nicht beiden Parteien, die Mitwirkung einzufordern. (4) Der Qualitätsmaßstab in SEV in Deutschland lässt die Unmöglichkeit der Erstellung mangelfreier Software meist unbeachtet. Die Bezugnahme auf technische Standards wird einseitig im Interesse einer Partei verwandt. Die Rechtssysteme in Deutschland und den USA bieten wenig Hilfe, um die entsprechenden Fragestellungen zu lösen, beginnend mit der rechtlichen Qualifikation von Software. Dies führt bei Rechtsstreitigkeiten zu unvorhersehbaren Ergebnissen und zu einem erheblichen Risiko für SEP. Die Analyse der Verträge zeigt, das die vier genannten Aspekte entweder nicht angemessen berücksichtigt, oder interessenorientierte Verträge formuliert werden. Alle Versuche, Software innerhalb der vorhandenen rechtlichen Konzepte zu klassifizieren, hat zu zweifelhaften Konstruktionen geführt. Die Mehrzahl der Probleme wurzelt, sowohl in Deutschland wie in den USA, darin, dass SEP mit dem geltenden Recht nicht abgebildet werden können. Die Lösung: Software ist keine Sache. Sie benötigt ihre eigenen Regeln. Dies tritt insbesondere bei SEP klar zu Tage. Konzepte aus dem vorletzten Jahrhundert, wie sie heute in Deutschland angewandt werden, passen nicht für SEP. Sie geben den Parteien, die sich Hilfe von der Rechtsordnung erhoffen, keine Unterstützung. Diese Hilfe müsste die zwei Gesichtpunkte Entwicklung und Verflechtung berücksichtigen. Der Entwicklungsgedanke bezieht sich dabei auf Leistungsbestimmung und Änderungen, der Verflechtungsgedanke auf das Kooperationserfordernis und die Notwendigkeit, einen geeigneten Leistungsmaßstab zu vereinbaren. Es sollte eine gesetzliche Grundlage in Form eines neuen, im besonderen Schuldrecht zu verankernden Vertragstypus, nach Maßgabe der folgenden Bestimmungen geschaffen werden: § 1 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. § 2 Ä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. § 3 Mitwirkungspflichten Der Unternehmer kann vom Besteller die zum Leistungserfolg erforderlichen Mitwirkungshandlun-gen 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. § 4 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. | de_DE |
| dc.description.abstract | The problem: Software development contracts (SDC) control a complex long term relationship. The four basic aspects of this relationship are: (1) step by step development, (2) constant modifications, (3) need of cooperation and (4) the difficulty of defining an appropriate quality standard. (1) Software development projects (SDP) are usually a journey starting without a precise target. If a specification exists at all it is often deficient or incomplete. The responsibility for shaping the specification is often in dispute particularly in case of conflicts. (2) Modification is an essential aspect that is frequently not sufficiently reflected in agreements or puts the burden on one side only. (3) The development of software generally requires close cooperation of the parties. By contrast SDC frequently do not allow both parties to call for contribution. (4) Quality standards in SDC in Germany seldom reflect the impossibility of developing error-free software. Reference to technical standards is used in the interest of one party. The law systems in Germany and the USA offer little help for the solution of related questions starting with qualification of software. This leads to unpredictable results in case of litigation and imposes a high risk on SDP. The analysis of contracts shows, that the four named aspects are either not considered properly or the interests of one party dominate the agreement. All attempts to classify software within existing law concepts have lead to questionable constructions. Most of the problems are rooted in the inability of the law in Germany and the USA to get along with SDP. The solution: Software is not a good. It needs its own rules. This can be specifically demonstrated in SDP. Concepts from the century before last, as applied in Germany, do not fit to SDP and fail to give support to parties and courts in need of help from the law. That help shall embrace the two elements of development and linkage of the party s duties. The development aspect points at the specification of the project target and modifications, the linkage aspect aims at cooperation and the necessity to reach mutual agreement on a standard of quality. Thus a legal foundation may read as follows: § 1 Specification of performance (1) Customer has the right to require developer to perform according to the specification of performance unless and as far parties do not agree otherwise. (2) As far as performance is not definable, customer can only require the specified performance. Developer can require payment only for the specified performance. § 2 Modification of performance Customer has the right to require a modification of performance, developer to require a modification of payment as far as adherence to the agreed performance is unconscionable. § 3 Cooperation Developer has the right to require customer to cooperate. Developer can not refer to that right as far as cooperation of customer is not possible without advice or other activity of developer. § 4 Standard of quality Developer has the right to require payment, if he has substantially performed. This applies to partial performance as far as payment for partial performance is agreed upon. | en |
| dc.language.iso | de_DE | de_DE |
| dc.rights | In Copyright | * |
| dc.rights.uri | http://rightsstatements.org/page/InC/1.0/ | * |
| dc.subject | Softwareentwicklung | de_DE |
| dc.subject | Softwareerstellung | de_DE |
| dc.subject | Projektvertrag | de_DE |
| dc.subject | Leistungsbestimmung | de_DE |
| dc.subject | Mitwirkungspflicht | de_DE |
| dc.subject | Software specification | en |
| dc.subject | Change management | en |
| dc.subject | Cooperation | en |
| dc.subject | Quality standard | en |
| dc.subject | Modification | en |
| dc.subject.ddc | ddc:340 | de_DE |
| dc.title | Softwareentwicklungsverträge | de_DE |
| dc.title.alternative | Software development contracts | en |
| dc.type | doctoralThesis | de_DE |
| dcterms.dateAccepted | 2006-10-12 | |
| local.affiliation | FB 07 - Mathematik und Informatik, Physik, Geographie | de_DE |
| thesis.level | thesis.doctoral | de_DE |
| local.opus.id | 3676 | |
| local.opus.institute | Professur für Bürgerliches Recht, Internationales Privatrecht und Rechtsvergleichung | de_DE |
| local.opus.fachgebiet | Informatik | de_DE |
Dateien zu dieser Ressource
Das Dokument erscheint in:
Urheberrechtlich geschützt