O'Reilly logo

IT-Projektverträge: Rechtliche Grundlagen by Christoph Zahrnt

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

9 Erstellung von Programmen
270
Abb. 9–2
Abrechnung nach § 649 BGB
9.3 Sonstige Leistungsfragen
9.3.1 Leistungsumfang
Ein Festpreis gilt alle Leistungen ab, die notwendig sind, auch wenn diese im
Angebot nicht enthalten sind.
(1) Geschuldete Formen des Programms und Erstellungshilfsmittel
Die Frage nach der geschuldeten Sprachform des Programms stellt sich unabhän-
gig von der Frage, in welchem Umfang urheberrechtliche Nutzungsrechte einge-
räumt werden:
Was hat der Auftragnehmer zu liefern?
Inwieweit darf der Kunde das nutzen?
Umfang: Das Programm ist vollständig als Quellprogramm zu liefern, sodass der
Kunde es selbst pflegen kann. Das gilt auch für Standardbausteine, die der Auf-
tragnehmer – ohne einschränkende Vereinbarung – einfügt.
Hinsichtlich der Entwicklungsumgebung heißt das, dass solche Programme
(Werkzeuge) nicht geliefert werden müssen, die üblicherweise von demjenigen auf
dem Markt beschafft werden, der ein Programm erstellen und ändern will (insbe-
sondere Compiler)
.
Hauptpflicht: Wenn schon di e Lieferung der Benutzerdokumentation als Haupt-
pflicht angesehen wird [Kapitel 6.2.1 (1)], muss die des Quellprogramms erst
recht als solche angesehen werden.
Wenn das Quellprogramm an einen Laien-Anwender nicht ausgeliefert wird,
weil der Auftragnehmer die Pflege übernimmt, merkt Laien-Anwender gar nicht,
(6+).393-3').? 
(+
(2*+% )*
.+.#%
+)%
2(%
 *( *(
'#%*)%)+*().-2(%
 %.#%% *( *(,&%))%1* " *
A+;/33'38+/1@ %(- * 
 %%$%
+( %%
%(%+*(
) %.+. %
A+;/33'38+/1@
# )**
( *
" %( *  *( *(
%*#))%
()'(*
+)%) %
.+. %
271
9.3 Sonstige Leistungsfragen
dass ihm etwas fehlt. Es ist auch durchaus sinnvoll, dass er nur das Objektpro-
gramm hat und nicht nach jeder kleinen Änderung (nach jeder Mängelbeseiti-
gung) eine neue Version des Quellprogramms erhält. Außerdem hat er aus Kos-
tengründen meist nicht die erforderliche Entwicklungsumgebung erworben,
sodass er selbst mit dem Quellprogramm gar nichts anfangen könnte. Deswegen
kann grundsätzlich nicht Verwirkung [Kapitel 3.10 (4)] angenommen werden,
wenn der Kunde das Quellprogramm nicht anfordert, solange der Auftragneh-
mer das Programm für ihn pflegt.
Zeitpunkt: Der Kunde hat Anspruch auf Lieferung spätestens zum Beginn einer
vereinbarten Abnahmeprüfung (denn die IT-technische Qualität des Quellpro-
gramms und erst recht d
ie der systemtechnischen Dokumentation sind Gegen-
stand der Abnahmeprüfung), sonst vor Zahlung.
(2) Dokumentation
Zur rechtlichen Einordnung des Fehlens der Dokumentation siehe Kapitel 6.2.1 (2).
Benutzerdokumentation: Diese ist im Ansatz wie bei Softwareprodukten [Kapitel
6.2.1 (2)] erforderlich. Hier kommt aber bei Projektverträgen mit großen Kunden
in Betracht, dass der Auftragnehmer nur Material für die Benutzerdokumenta-
tion zu liefern hat und der Kunde diese selbst fertigstellt. Es kommt auch in
Betracht, dass solche Kunden die Dokumentation selbst – als Teil einer Gesamt-
dokumentation – erstellen.
Bei Vergütung nach Aufwand wird häufig keine Benutzerdokumentation
erstellt. Hier dü rfte sie bei kleineren Programmen eher nur geschuldet sein, wenn
der Kunde sie ausdrücklich beauftragt
.
Systemtechnische Dokumentation: Diese wird stets geschuldet. Umfang und
Inhalt werden in erster Linie durch die vereinbarten Richtlinien zur Entwicklung
und vor allem zur Dokumentation bestimmt [Kapitel 9.1.5], kaum durch die zur
Qualitätssicherung.
Deswegen macht die Formulierung, dass die Dokumentation DIN EN ISO
9001:2000 zu entsprechen habe, wenig Sinn. Diese Norm behandelt u.a. die
Dokumentation des Entwicklungsganges, aber nicht die des Entwicklungsergeb-
nisses; im Übrigen ist sie zu allgemein.
Testdokumentation: Si
e ist zu erstellen und zu übergeben. Das folgt zum einen
aus dem Grundsatz »kein Test ohne Protokoll« und zum anderen daraus, dass die
Testfälle bei der Weiterentwicklung des Programms benötigt werden. Es darf
nicht sein, dass bei einer späteren Änderung des Programms unverhältnismäßig
viele Testfälle erstellt werden müssen, um durch die Änderung möglicherweise
verursachte Fernwirkungen auszuschließen. Ei nzelheiten können sich aus den
vereinbarten Entwicklungs- und Dokumentationsrichtlinien ergeben.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required