Juliane Vorndamme *Beeinflussung des Softwareentwicklungsprozesses durch ausgewählte rechtliche VerpflichtungenJurPC Web-Dok. 1/2000, Abs. 1 - 45 |
| Die Entwicklung von Software wird durch eine Vielzahl von Faktoren beeinflußt. Neben Faktoren aus verschiedenen Gebieten der Informatik spielen auch externe Einflüsse eine Rolle. Daher ist es von Interesse, die Auswirkungen rechtlicher Verpflichtungen auf die Entwicklung von Software zu untersuchen. In diesem Artikel wird auf die Entwicklung von Individualsoftware, die auf einer vertraglichen Grundlage basiert, eingegangen. | JurPC Web-Dok.
1/2000, Abs. 1 |
| Als besondere Schwierigkeit bei der Gestaltung von vertragsgemäßer Software erweist sich die Sicherstellung einer "aufgabenangemessenen" Software. Diese Eigenschaft bezieht sich auf den Arbeitsprozeß des späteren Benutzers der Software und wird im Hinblick auf eine dem "Stand der Technik" entsprechende Qualität des Softwareproduktes gefordert. In dieser Hinsicht gibt es Überschneidungen zu gesetzlichen Vorgaben zum Arbeitsschutz, die auf der "Verordnung über Sicherheit und Gesundheitsschutz bei der Arbeit an Bildschirmgeräten" basieren. | Abs. 2 |
| Neben der Forderung der Gestaltung einer vertragsgemäßen Software steht die Notwendigkeit die Möglichkeit einer Bewertung des entstandenen Produktes zu schaffen. Hier muß gegebenenfalls der Ersteller den Nachweis erbringen, daß er sämtlichen Verpflichtungen hinreichend nachgekommen ist. Dies ist gerade bei "weichen" Anforderungen aus dem Bereich der Software-Ergonomie problematisch. | Abs. 3 |
| Die Berücksichtigung der oben genannten Beeinflussung erfolgt über die Definition eines neuen Vorgehensmodelles - VIPSO - das zwei Zielsetzungen hinsichtlich der rechtlichen Verpflichtungen nachkommt: Der Unterstützung von vertrags- und verordnungskonformer Software. Der Hilfestellung der Nachweisführung über die Einhaltung der rechtlichen Verpflichtungen. | Abs. 4 |
"Vorgehenstreue" als Erfolgsgrundlage |
| Ein Vorgehensmodell ist ein Abbild des Entwicklungsprozesses von Software. Es hat deskriptiven Charakter und ist eine entscheidende Vorarbeit zur Erarbeitung einer Methode, die präskiptive Vorgaben über die Durchführung eines Entwicklungsprojektes macht. Die Vorteile der Nutzung eines Vorgehensmodelles, bzw. der sich daraus ableitenden Methode ergeben sich aus der Erkenntnis, daß die Prozeßgestaltung bei der Produktentwicklung entscheidenden Anteil an der späteren Produktqualität hat. Dies ist bereits mehrfach in der Literatur formuliert(1) und hat sich auch in Projektuntersuchungen bestätigt(2). | Abs. 5 |
| Es gibt eine ganze Reihe bekannter Vorgehensmodelle. Die ältesten von ihnen stammen bereits aus der Zeit, in der die sogenannte Softwarekrisekonstatiert wurde. Danach sind immer wieder neue Vorgehensmodelle entstanden, da Schwachpunkte bereits existierender Modelle entdeckt wurden, bzw. neue Gegebenheiten die bisherigen Überlegungen obsolet machten. Eine Vielzahl von Veränderungen an Vorgehensmodellen ist aus der Informatik selbst veranlaßt worden; so sind beispielsweise durch Einführung objektorientierter Analyse- und Designmethoden die bisherigen Vorgehensmodelle hinterfragt worden. Aus dieser Fragestellung folgten die evolutionären Vorgehensmodelle, nach denen eine Software in mehreren Evolutionsstufen entwickelt werden kann. Darin spiegelt sich die Idee, den Lernprozeß aller Beteiligten während der Entwicklung von Software zur Entwicklung "besserer" Software auszunutzen. | Abs. 6 |
| Durch die Vielzahl verschiedener Vorgehensmodelle muß bei Projektbeginn eine Entscheidung über das zugrundezulegende Vorgehen getroffen werden. Die oben erwähnte Untersuchung von Projekten ergab in diesem Zusammenhang folgende Erkenntnis(3): Es ist für den Erfolg eines Projektes wichtig nach einem Vorgehensmodell zu verfahren. Welches konkret angewandt wird, ist weniger wichtig als die Tatsache, daß überhaupt ein Modell umgesetzt wird. Allerdings sollte während des Projektes möglichst wenig von der gewählten Modellvorstellung abgewichen werden, was sich mit dem Begriff "Vorgehenstreue" umschreiben läßt. | Abs. 7 |
Vertragsrechtliche Grundlage |
| Bei der Erstellung von Individualsoftware liegt dem Entwicklungsprojekt eine vertragliche Bindung der Beteiligten zugrunde. Dadurch erhält ein Projekt zusätzlich zu den technischen und betriebswirtschaftlichen Problemstellungen auch einen juristischen Aspekt. Juristische Auseinandersetzungen entstehen insbesondere durch die Tatsache, daß jede Software ein hochkomplexes Gebilde ist, dessen Erstellung nicht völlig fehlerfrei gelingen kann(4). Außerdem besteht in jedem Entwicklungsprojekt eine Wechselwirkung mit der technischen und organisatorischen Umgebung des Projektes, die dazu führt, daß sich Veränderungen an den Anforderungen ergeben. Somit ergeben sich auch Veränderungen an der Einschätzung der Fehlerhaftigkeit einer Software. | Abs. 8 |
| Die gesetzliche Grundlagen der Erstellung von Individualsoftware ist nach einhelliger Meinung der Literatur(5) als auch der Rechtsprechung(6) das Werkvertragsrecht nach §§ 631 BGB. | Abs. 9 |
| Normalerweise entstehen Rechtsstreitigkeiten immer dann, wenn die Ansichten des Auftragnehmers und des Auftraggebers über den Erfolg des Projektes auseinandergehen. Der nach § 631 BGB geschuldete Erfolg eines Werkvertrages betrifft die vertragsgemäße, mangelfreie und rechtzeitige Herstellung des Werkes. Andererseits ist nach § 640 BGB der Besteller der Software verpflichtet, das entstandene Werk abzunehmen und erklärt damit, daß das abgenommene Werk den Anforderungen grundsätzlich genügt. Diese Abnahme entspricht jedoch nicht einer Bestätigung der Mängelfreiheit des Werkes durch den Auftraggeber. | Abs. 10 |
| Häufig kommt es zu Leistungsstörungen in der Form, daß der Auftraggeber eine mangelhafte Ausführung des Auftrages reklamiert. Nach dem werkvertraglichen Gewährleistungsrecht kann der Auftraggeber nur Ansprüche daraus geltend machen, wenn das Werk nach § 633 BGB einen Mangel aufweist. Dies liegt im Rechtssinne vor, wenn ein Fehler vorliegt oder eine zugesicherte Eigenschaft fehlt. Dabei ist zu unterscheiden zwischen den verschiedenen Fehlerbegriffen, die sich einerseits aus der juristischen Sicht und andererseits aus der Sicht der Informatik ergeben(7). In der Informatik bedeutet "Fehler" jegliche Abweichung des Ist-Zustandes eines Objektes vom Sollzustand(8). Im Rechtssinne verwendet man den Begriff "Mangel" dann, wenn eine solche Abweichung die vertraglichen Vereinbarungen oder die übliche Nutzbarkeit verletzt. | Abs. 11 |
Notwendigkeit der Veränderung des Pflichtenheftes |
| Geht man davon aus, daß hier nur juristische Mängel relevant sind, ist es wichtig festzustellen, wann ein solcher Mangel vorliegt. Dazu muß man zunächst den Inhalt der vertraglichen Vereinbarungen zwischen den Vertragsparteien kennen. Die vertraglichen Anforderungen an ein System sind in dem Pflichtenheft / der Leistungsbeschreibung zu finden(9). Falls ein solches Pflichtenheft fehlt, ist es auch möglich, den "Stand der Technik" als Beurteilungsgrundlage heranzuziehen(10). Um diesen zu identifizieren, müssen z.B. Normen und Richtlinien herangezogen werden(11). | Abs. 12 |
| Falls nun in einem Pflichtenheft alles Relevante in einem hinreichenden Detaillierungsgrad beschrieben worden ist, werden Rechtsstreite schnell zugunsten der einen oder anderen Partei zu entscheiden sein. Damit bietet ein möglichst präzise formuliertes Pflichtenheft die größte Rechtssicherheit(12). Zwar ist eine mündliche Vereinbarung grundsätzlich ebenso bindend wie eine schriftlich fixierte, jedoch werden im Falle des Fehlens einer schriftlichen Darlegung häufig Beweisprobleme auftreten(13). | Abs. 13 |
| Es zeigt sich bei vielen Rechtsstreiten allerdings schnell, daß das Problem darin besteht, daß die Anforderungen in dem Pflichtenheft nicht hinreichend präzise oder detailliert formuliert worden sind(14). | Abs. 14 |
| Es entsteht die Frage, was der Inhalt eines Pflichtenheftes sein soll, damit es seiner Aufgabe als Vertragsgrundlage möglichst weitgehend gerecht wird. Von SCHAUB stammt die folgende Definition des Inhaltes eines Pflichtenheftes nach DIN 69901: | Abs. 15 |
| "Ein Pflichtenheft ist eine ausführliche Beschreibung der Leistungen, die erforderlich sind, … damit die Ziele erreicht werden. Es enthält Aussagen zur Ausgestaltung der Bildschirminhalte und der Programmfunktionen und alle inhaltlichen Anforderungen …" [Schaub93, 330]. | Abs. 16 |
| Es ist zu klären, wem es angerechnet werden soll, wenn in einem Pflichtenheft etwas steht, womit zumindest eine der Vertragsparteien nicht einverstanden ist. Dazu ist es wichtig, das Zustandekommen der Anforderungen im Pflichtenheft näher zu untersuchen. | Abs. 17 |
| In diesem Zusammenhang kommt die These auf, daß der
Anwender als EDV-Laie besonderen Schutz genießen müsse(15) und deshalb fast alle Verantwortung auf den
Anbieter zu fallen habe. Dieser Ansicht muß aus zwei Gründen
widersprochen werden: - Zum einen ist mittlerweile einige Erfahrung bezüglich der EDV bei den Anwendern zu finden, - zum anderen hat die Verantwortung für das Pflichtenheft wenig mit EDV-Kenntnissen zu tun. Es handelt sich vielmehr um ein Problem aus dem Fachbereich des Anwenders, über das der Anwender naturgemäß am besten Bescheid weiß. In diesem Fachgebiet ist sozusagen der EDV-Experte Laie(16)und deshalb besonders schützenswert. Mittlerweile hat sich auch in der Literatur(17) und in der Rechtsprechung(18) die Beurteilung der Pflichten der Beteiligten in diese Richtung entwickelt. | Abs. 18 |
| Wenn den Anwender also eine Mitverantwortung in dieser Hinsicht trifft, wie soll er dieser gerecht werden? Hier kommt in erster Linie die "Mitwirkungspflicht" des Anwenders zum Tragen, die sich aus dem Werkvertragsrecht ableiten läßt. So geht das Gesetz (§ 642 BGB) davon aus, daß eine Mitwirkung des Bestellers bei einem Werkvertrag notwendig ist. Nach Literatur(19) und Rechsprechung(20) hat der Anwender in angemessener Form an der Erstellung des Pflichtenheftes mitzuwirken. | Abs. 19 |
| Die Erfahrung hat gezeigt, daß es selbst bei besten Absichten aller Beteiligten nicht möglich ist, ein Pflichtenheft in nur einem Anlauf und möglichst noch vor Vertragsabschluß zu erstellen. Normalerweise ist eine vollständige und hinreichend detaillierte Formulierung des Pflichtenheftes zu Beginn des Projektes nicht möglich. Während der Laufzeit eines Projektes wird jedoch ein Lernprozeß der Beteiligten stattfinden. Auch die Literatur stützt die These, daß häufig Anforderungen nicht ausreichend formuliert sind und spätere Abänderungen notwendig sein können. Einen Lernvorgang sehen auch SCHAUB, LESSHAFT, DEVILLE und GORNY in ihren Ausführungen(21). | Abs. 20 |
| Nach der rechtlichen Situation ist für den Projekterfolg ausschlaggebend, das Pflichtenheft heranzuziehen. Gleichzeitig wurde jedoch eben festgestellt, daß das ursprünglich vereinbarte Pflichtenheft noch der Veränderung bedarf. | Abs. 21 |
| Damit der Notwendigkeit zur Veränderung des Pflichtenheftes Rechnung getragen werden kann, ist es zunächst unumgänglich, daß die vereinbarten Veränderungen der Anforderungen schriftlich fixiert werden. Dabei ist eine schriftliche Fixierung sinnvoll, z.B., um auch die weiteren Auswirkungen der Veränderung zu erfassen (längere Lieferzeit u.ä.)(22). Außerdem sollen sich alle Beteiligten darüber im klaren sein, daß solchermaßen veränderte Anforderungen ebenfalls vertraglich geschuldet sind. Damit dieses Procedere allen Vertragspartnern vertraut ist, ist es notwendig, daß es in dem Vertrag bereits vorgesehen wird(23). | Abs. 22 |
| Bisher ist die Mitwirkungspflicht des Auftraggebers bei einem
Projekt zwar festgestellt, jedoch noch nicht erklärt worden, was unter
einer solchen angemessenen Mitwirkung des Auftraggebers zu verstehen ist. Dafür
entscheidend ist das fachliche Vermögen der beiden beteiligten Parteien –
Anwender und Entwickler: - In den Bereichen, in denen die größere Fachkompetenz beim Anwender liegt, soll dieser eher die Verantwortung für die Aussagen des Pflichtenheftes übernehmen. - Im anderen Fall wird die Verantwortung eher beim Entwickler liegen(24). Eine solche Aufteilung ist nicht nur im Sinne einer größeren Rechtssicherheit vorteilhaft, sondern dient auch im positiven Sinne der Qualität des Pflichtenheftes im allgemeinen. Durch die Wahrnehmung der Verantwortung aller Betroffenen sollen damit nach Möglichkeit überhaupt keine Rechtsstreitigkeiten mehr entstehen. | Abs. 23 |
| Damit ergeben sich für die Projektlaufzeit verschiedene Verantwortungsbereiche für Auftraggeber und Auftragnehmer. Ist ein Mißverständnis während der Entwicklungsphase aufgetreten und erkannt, ist zunächst zu überlegen, wie nach seinem Erkennen damit umgegangen wird. Bei fest vorgegebenen Verantwortungsbereichen wird man schnell die zuständigen Personen ansprechen können und zügig für eine Ausräumung des Mißverständnisses sorgen können. | Abs. 24 |
| Die wenigsten Überraschungen wird es auf jeden Fall für alle Beteiligten geben, wenn Rechte und Pflichten bezüglich der Zusammenarbeit explizit vertraglich vereinbart werden(25). | Abs. 25 |
Rolle der Abnahme der Projektergebnisse |
| Die Abnahme muß nach dem erfolgreichen Abschluß des Entwicklungsprojektes vorgenommen werden. Mit der Abnahme durch den Besteller wird dem Auftragnehmer mitgeteilt, daß er seine vertraglichen Verpflichtungen aus dem Softwareentwicklungsvertrag erfüllt hat. Von diesem Zeitpunkt an kann er die vertraglich vereinbarte Gegenleistung (Werklohn) fordern. Außerdem beginnt im Hinblick auf die Gewährleistungsrechte die Verjährungsfrist zu laufen(26). | Abs. 26 |
| Am eindeutigsten erfolgt eine Abnahme, wenn sie bereits im Vertrag vorgesehen ist und dann demgemäß durchgeführt wird. Die Abnahme muß nicht ausdrücklich und in einer bestimmten Form erklärt werden, sondern kann auch konkludent erfolgen. Konkludent könnte die Abnahme durch Ingebrauchnahme erfolgen. Weil aber die Funktionstüchtigkeit der Software erst nach dem praktischen Einsatz überprüft werden kann und Fehler häufig erst dann festgestellt werden, erweist es sich als schwierig, den Zeitpunkt der Ingebrauchnahme im juristischen Sinne als Abnahmeerklärung genau zu definieren. So stellt Brandi-Dohrn fest, daß es grundsätzlich eine Tendenz gibt, den Zeitpunkt der Abnahme eher nach hinten zu verschieben(27), wenn es an einer ausdrücklichen Abnahme des Werkes fehlt. Die Rechtssprechung teilt diese Rechtsansicht und geht davon aus, daß erst nach einer längeren Zeit der Erprobung eine Software als abgenommen gelten kann(28). | Abs. 27 |
| Dies hat zur Folge, daß sich für die Anbieter von Software eine größere Rechtssicherheit ergibt, wenn bereits zu Beginn des Projektes die Abnahmekriterien erarbeitet werden(29). Ansonsten kann der Anbieter in die Lage kommen, daß es ihm schwerfällt, die Gebrauchsfertigkeit der Software darzulegen und gegebenenfalls nachzuweisen(30). Als Grundlage für die Definition von Abnahmekriterien dient wiederum das Pflichtenheft(31). | Abs. 28 |
Arbeitsschutzrechtliche Situation |
| Die Anforderungen zum Arbeitsschutz ergeben sich aus internationalen (insbesondere europäischen) und nationalen Vorgaben zur Gestaltung von Bildschirmarbeitsplätzen. Für die Neuentwicklung von Individualsoftware ist die Einhaltung der "Verordnung über Sicherheit und Gesundheitsschutz bei der Arbeit an Bildschirmgeräten(32) " verpflichtend. Sie basiert auf der EG-Richtlinie 90/270/EWG des Rates vom 29.5.1990 über die Mindestvorschriften bezüglich Sicherheit und Gesundheitsschutz bei der Arbeit an Bildschirmgeräten(33). Die Richtlinie 90/270/EWG wurde bereits 1990 von dem Rat der EG verabschiedet. Die Bundesrepublik hat am 4.12.1996 eine Verordnung(34)erlassen, die die Umsetzung der Richtlinie regelt(35). Für ihre binnenstaatliche verpflichtende Umsetzung ist eine Terminstaffelung vorgesehen(36): - Neue Arbeitsplätze sollen dieser Richtlinie bereits seit dem 20.12.1996 entsprechen. - Für bereits existierende Arbeitsplätze gibt es die Möglichkeit, sie bis zum 31.12.1999 anzupassen. | Abs. 29 |
| Erschwerend kommt hinzu, daß nicht allgemeingültig vorgegeben werden kann, wie ein bestimmter Bildschirmarbeitsplatz exakt gestaltet werden soll. Allenfalls kann man eine Methode zur Erarbeitung einer konkreten Gestaltung und ein Verfahren, diese Methode umzusetzen, vorgeben(37). Hierbei ist es hilfreich in der Arbeitswissenschaft ausgebildete Personen in den Entwicklungsprozeß von Individualsoftware mit einzubeziehen. | Abs. 30 |
| Die Richtlinie (und damit die Verordnung) ist wenig konkret in ihren Vorgaben(38) und daher auch nicht unmittelbar umsetzbar bzw. überprüfbar. Allgemein geht man nämlich davon aus, daß die Übereinstimmung mit der Richtlinie immer in Zusammenhang mit dem Kontext erzielt und überprüft werden muß(39). Dies gilt insbesondere für die Überprüfung der Aufgabenangemessenheit, aber auch weiterer, sich aus der Richtlinie ergebenden Forderungen. | Abs. 31 |
| Die Definition von Softwareergonomie, wie sie ein Standard wie die ISO 9241 bietet, ist daher eine sinnvolle Ergänzung zu den Aussagen der Richtlinie(40). Diese Norm fand bei einer Befragung von Experten aus verschiedenen Ländern 1993 deren überwiegende Zustimmung(41), so daß man sie als eine allgemein anerkannte Norm für den Begriff der Ergonomie von Bildschirmarbeitsplätzen zugrunde legen kann. | Abs. 32 |
Notwendigkeit der Nachweiserbringung |
| Es muß dafür Sorge getragen werden, daß die Software, die entwickelt wird, richtlinienkonform ist. Dies setzt voraus, daß man eine Kontrolle über den Entwicklungsvorgang hat. In diesem Zusammenhang macht man die Beobachtung, daß nur schwer zu steuern ist, was man nicht beurteilen kann(42). Dadurch entsteht in bezug auf die Anforderung der Verordnungskonformität der Bedarf, daß diese überprüfbar sein muß. Es steht zu erwarten, daß dieser Problemkreis in Zukunft die Gerichte beschäftigen wird, wenn Berufsgenossenschaften oder Arbeitnehmer gegen den Arbeitgeber Klage auf Einhaltung der Richtlinie oder Verordnung einreichen(43). So ergibt sich aus der Aufgabenstellung der verordnungkonformen Gestaltung einer Benutzerschnittstelle zwangsläufig die Aufgabenstellung, die Einhaltung dieser Vorgabe nachzuweisen(44). | Abs. 33 |
| Allgemein spricht man von Software-"Evaluation", wenn man die Analyse und Bewertung von Softwaresystemen vornimmt(45). Der Ursprung der Evaluationsforschung liegt in den Sozialwissenschaften. Dort wird sie z.B. eingesetzt, um die Auswirkungen sozialer Programme besser abschätzen zu können. Für die Informatik wurde der Nachweis erbracht, daß diese sozialwissenschaftlichen Erkenntnisse zur Evaluation im wesentlichen auf die Softwareentwicklung übertragbar sind(46). | Abs. 34 |
| Problematisch ist in diesem Zusammenhang, daß man bei der
Durchführung von Evaluation bestimmte Risiken eingeht, z.B. daß die
Kosten dafür unverhältnismäßig hoch werden können(47) oder die Güte der verwandten Methoden
nicht befriedigend ist(48). Daher gilt es mögliche
Strategien zu entwickeln, um Evaluationsmethoden sinnvoll einzusetzen(49). Diese können z.B. sein: - Fixieren der Evaluationsanforderungen, mit denen sich alle Beteiligten bereits im Vorfeld des Projekts zufriedengeben, - Überprüfen mancher Anforderungen nur stichprobenartig. | Abs. 35 |
| Ähnlichkeiten(50)zwischen einzelvertraglichen und aus der Verordnungskonformität stammenden Anforderungen kann man für die Evaluation ausnutzen. Dabei kann man auch für einzelvertragliche Anforderungen auf die (zumindest teilweise) bewährten Methoden der Evaluation software-ergonomischer Eigenschaften zurückgreifen. In beiden Fällen müssen die Anforderungen zunächst "operationalisiert" werden, bevor eine Evaluation erfolgen kann. Dadurch wird eine Überprüfbarkeit mittels Evaluationsmethoden erst ermöglicht, da die gewünschten Eigenschaften auf verifizierbare Größen zurückgeführt werden. | Abs. 36 |
| Gerade wegen der Risiken und Grenzen bei der Evaluation von Software ist es sinnvoll, wenn sich die Projektbeteiligten bereits im Vorfeld auf zufriedenstellende Methoden zur Überprüfung von Anforderungen einigen und diese Vereinbarung schriftlich fixieren. | Abs. 37 |
Überführung der Anforderungen in ein Vorgehensmodell |
| Zwischen dem Bestreben, einerseits Software vertrags- und verordnungskonform zu gestalten und andererseits durch evolutionäres Vorgehen den Lernprozeß während einer Entwicklung auszunutzen, entsteht ein Spannungsfeld, das sich insbesondere auf das zu verwendende Vorgehensmodell auswirkt. Während in der Vergangenheit Vorgehensmodelle sehr stark auf die technische Perspektive der SW-Entwickler ausgerichtet gewesen(51), bietet VIPSO eine Alternative: | Abs. 38 |
| Verantwortungsverteilung im Iterativen Prozeß für Softwareentwicklung unter Verwendung der Objektorientierung | Abs. 39 |
| Es handelt sich dabei um die Darstellung des
Softwareentwicklungsprozesses unter Berücksichtigung von Prinzipien, die
aus Projektuntersuchungen, den Vorgaben aus den einzelvertraglichen
Vereinbarungen und den Vorgaben aus der Verordnung abgeleitet werden(52). Es ergeben sich folgende vier Prinzipien,
die in VIPSO Eingang finden: - Prinzip der Risikominimierung für die Softwareentwicklung, - Prinzip des definierten Organisationsmodells, - Prinzip der Sicherung der Qualität durch konstruktive Maßnahmen, - Prinzip der Evaluation der Projektergebnisse. | Abs. 40 |
| Bei VIPSO handelt es sich auch um ein Modell, das eine Unterscheidung in Sammel- und Entscheidungsphasen vorsieht und bei dem in den Entscheidungsphasen beschlossen werden kann, einen Rückschritt und damit eine Iteration bestimmter Aktivitäten vorzunehmen. Die Evaluation der Projektergebnisse wird dabei nicht nur statisch in den Entscheidungsphasen vorgesehen, sondern darüber hinaus dynamisch, bereits während der Sammelphasen des Projekts. | Abs. 41 |
| Die Sammel- und Entscheidungsphasen ordnen sich bei VIPSO in einen Makro-Prozeß (siehe Abbildung) ein, der die großen Iterationsvorgänge in einem Projekt beschreibt. Darüber hinaus werden die einzelnen Phasen selbst ebenfalls iterativ bearbeitet. Dies erfolgt in den zugeordneten Mikroprozessen. Die Aktivitäten der verschiedenen Phasen sind den oben genannten Prinzipien zugeordnet und in einen Ablaufzusammenhang gebracht. | Abs. 42 |
| Der besonderen Rolle der Verantwortlichkeiten und der Zuweisung von Verantwortungsbereichen, die im Projektverlauf verändert werden können, wird in VIPSO große Bedeutung beigemessen. Darüber hinaus ist die objektorientierte Spezifikations- und Entwurfsmethode von COAD/YOURDON in das Vorgehensmodell integriert. | Abs. 43 |
| Es gibt Überschneidungen von VIPSO mit Qualitätsmangementbestrebungen, wie man sie in TQM oder in der ISO 9000 findet. Allerdings orientiert sich VIPSO an den Erfordernissen des jeweiligen Entwicklungsprojektes und hat damit eine begrenztere Zielsetzung als ein Qualitätsmanagementsystem. Im Rahmen dieser eingeschränkten Zielsetzung erfüllt es jedoch eine weitergehende Aufgabe als ein Qualitätsmanagementsystem: In VIPSO wird neben der Einbettung von qualitätsfördernden und qualitätsprüfenden Maßnahmen die eigentliche Erarbeitung der Projektergebnisse unterstützt. Eine Projektdurchführung unter der Verwendung von VIPSO kann in ein übergeordnetes Qualitätsmanagementsystem eingebettet werden. Die Einbeziehung einer unabhängigen Qualitätssicherung in den Entwicklungsprozeß ist insbesondere in den Entscheidungsphasen möglich. | Abs. 44 |
| Schließlich muß man VIPSO in Relation setzen zu den zwei bekanntesten Strömungen von Vorgehensmodellen. Sicherlich geht allgemein die Tendenz weg von phasen-orientierter Entwicklung hin zu evolutionärer Entwicklung(53). Allerdings haben die evolutionären Modelle auch ihre Schwächen: Sie sind schwerer zu organisieren und bergen größere Risiken, wenn man die mögliche Entstehung von Konflikten, die aus rechtlichen Verpflichtungen herrühren, berücksichtigt, zum Beispiel wenn eine Evaluation des entstandenen Produktes anhand vorgegebener Kriterien nicht möglich ist, da die Anforderungen nicht abschließend bekannt sind. Genau in den Prinzipien Risikominimierung, Organisationsmodell und Evaluation haben die Phasenmodelle ihre Stärken. Jedoch ist ihre grundlegende Prämisse von der Unveränderbarkeit der Anforderungen heute nicht mehr haltbar. Damit wird es notwendig, mit VIPSO ein neues Vorgehensmodell, das die Vorteile beider Ansätze in sich vereint, zu schaffen. Dies ist insbesondere sinnvoll, da in Projektuntersuchungen festgestellt wurde, daß eine große "Vorgehenstreue", wie eingangs erwähnt, den Erfolg eines Projektes unterstützt. Vorgehenstreue kann man insbesondere dadurch begünstigen, daß man das Vorgehensmodell so praxisnah wie möglich wählt, so daß Abweichungen davon im Einsatz nicht notwendig werden. | JurPC Web-Dok.
1/2000, Abs. 45 |
Literatur: |
| [Balz81] Balzert, H.: Systematischer Vergleich von Methoden,
Sprachen und Werkzeugen zu Definition und Analyse von Anforderungen an
Software-Produkte. In: Floyd, C./Kopetz, H. (Hg.): Software-Engineering –
Entwurf und Spezifikation. Stuttgart, 1981: Teubner, S. 265-257.
[Bäum95] Bäumer, D. et. al: Large Scale Object-oriented Software-Development in a Banking Environment. An Experience Report. Internes Papier der Uni Hamburg. [Beck93a] Beck, A./Janssen, C.: Vorgehen und Methoden für aufgaben- und benutzerangemessene Gestaltung von graphischen Benutzungsschnittstellen. In: Coy, W./Gorny, P. et al. (Hg.): Menschengerechte Software als Wettbewerbsfaktor. Stuttgart, 1993: Teubner, S. 200-221. [Beim93] Beimel, J. et al.: Wie Experten der Software-Ergonomie den Teil 10 (Dialogue Principles) der ISO 9241 bewerten. In: Rödiger, K.-H. (Hg.): Software-Ergonomie 93. Stuttgart, 1993: Teubner, S. 133-145. [Boehm89a] Boehm, B.: Introduction and Overview. In: Boehm, B. (Hg.): Software Risk Management. IEEE Computer Society 1989, S. 1-17. [Boehm89b] Boehm, B.: A Spiral Model of Software Development and Enhancement. In: Boehm, B. (Hg.): Software Risk Management. IEEE Computer Society 1989, S. 26-37. [Boehm89c] Boehm, B./Ross, T.: Theory-W Software project management: principles and examples. In: Boehm, B. (Hg.): Software Risk Management. IEEE Computer Society 1989, S. 85-114. [Boehm89d] Boehm, B.: Verifying and Validating Software Requirements and Design Specifications. In: Boehm, B. (Hg.): Software Risk Management. IEEE Computer Society 1989, S. 205-216. [Böm89] Bömer, R.: Risikozuweisung für unvermeidbare Softwarefehler. In: CR 1989, S. 361-367. [Bons84] Bons, H.: Fehler und Fehlerauswertung. In: Gorny, P./Kilian, W. (Hg.): Computer-Software und Sachmängelhaftung. Stuttgart, 1984: Teubner, S. 35-45. [Brand90] Brandi-Dohrn, M.: Vertragsgestaltung zur Haftung bei Softwaremängeln. In: CR 1990, S. 312-317. [Bred97] Bredemeier, J.: Bildschirmarbeitsplatz: Umsetzung der EG-Richtlinie für Bildschirmarbeitsplätze in nationales Recht erfolgt! In: ZfPR 2/97, S. 60-64. [Dev97] Deville, R.: Quellcode und Dekompilierung als Vertragsinhalt. In: NJW-CoR 2/97, S. 108-112. [Dum94] Dumslaff, U. et al.: Ein Vorgehensmodell zur Software-Evaluation. HMD 175/1994. [Engl93] Englisch, J.: Ergonomie von Softwareprodukten – methodische Entwicklung von Evaluationsverfahren. Mannheim u.a., 1993: BI-Wissenschaftsverlag. [Fisch94] Fischer, U.: Bildschirmarbeit und Gesundheit. Bringt die EG-Richtlinie zur Bildschirmarbeit Fortschritte? In: Der Personalrat 8/94, S. 351-358. [Floyd89] Floyd, C. et al.: STEPS to Software Development with Users. In: ESEC 89, Lecture Notes in Computer Science Vol. 387. Berlin u.a., 1989: Springer, S. 48-64. [Floyd92a] Floyd, C.: Human Questions in Computer Science. In: Floyd, C. et al. (Hg.): Software Development and Reality Construction. Berlin u.a., 1992: Springer, S. 15-28. [Floyd92b] Floyd, C.: Software Development as Reality Construction. In: Floyd, C. et al. (Hg.): Software Development and Reality Construction. Berlin u.a., 1992: Springer, S. 86-100. [Floyd94] Floyd, C.: Software-Engineering – und dann? In: Informatik-Spektrum 17/1994, S. 29-37. [Görn93] Görner, C./Ilg, R.: Evaluation der Mensch-Rechner-Schnittstelle. In: Ziegler, J./Ilg, R. (Hg.): Benutzergerechte Softwaregestaltung – Standards, Methoden und Werkzeuge. München u.a., 1993: Oldenbourg, S. 189-206. [Gorn84a] Gorny, P.: Zur Vorgeschichte des Workshops. In: Gorny, P./Kilian, W. (Hg.):Computer-Software und Sachmängelhaftung. Stuttgart, 1984: Teubner, S. 7-18. [Gorn86] Gorny, P.: Kategorien von Softwarefehlern. In: CR 10/1986, S. 673-677. [Gorn93] Gorny, P. et al.: Unterstützung des Software-Design-Prozesses durch EXPOSE. In: Coy, W./ Gorny, P. et al. (Hg.): Menschengerechte Software als Wettbewerbsfaktor. Stuttgart, 1993: Teubner, S. 463-479. [Gorn95] Gorny, P.: EXPOSE, HCI-Counceling for user interface design. In: Norby, N. et al.(Eds.): Human-Computer-Interaction; Proc. Interact 95. Chapman & Hall 1995, 297-304 (5th Inter-national IFIP Conference on Human Computer Interaction, Lillhammer, Norway, June 1995; interne Ausgabe der Universität Oldenburg). [Hamp94] Hampe-Neteler, W.: Software-ergonomische Bewertung zwischen Arbeitsgestaltungund Softwareentwicklung. In: Schriften zur Wirtschaftsinformatik. Frankfurt u.a., 1994: Lang (zugl. Dissertation). [Hart97] Harten, G./Richenhagen, G.: Die neue Bildschirmarbeitsverordnung. In: WSI-Mitteilungen 12/1997, S. 884-890. [Haus89] Hausen, H.-L.: Rule-Base Handling of Software-Quality and Productivity Models. In: ESEC 89, 2nd European Software Engineering Conference. Berlin u.a., 1989: Springer. [Heuss88a] Heussen, B.: Technische und rechtliche Besonderheiten von Mängeln bei Computerleistungen (I). In: CR 1988, S. 894-890. [Kar88] Karat, J.: Software Evaluation Methodologies. In: Helander, M. (Hg.): Handbook of Human-Computer-Interaction. New York, 1988: Elsevier Science Publishers B.V.,S. 891-903. [Keil92] Keil-Slawik, R.: Artifacts in Software-Design. In: Floyd, C. et al. (Hg.): SoftwareDevelopment and Reality Construction. Berlin u.a., 1992: Springer, S. 168-188. [Kies95] Kiesche, E./Schierbaum, B.: Neue Anforderungen an Software-Ergonomie durch die EG-Richtlinie zur Bildschirmarbeit. In: Arbeit + Recht 2/1995, S. 41-48. [Kil84] Kilian, W.: Haftung für Softwaremängel. In: Gorny, P./Kilian, W. (Hg.): Computer-Software und Sachmängelhaftung. Stuttgart, 1984: Teubner, S. 19-35. [Koch91] Koch, F.A./Schupp, P.: Software-Recht I. Berlin u.a., 1991: Springer. [Less89a] Lesshaft, K.: Anforderung an Spezifikation und Dokumentation (I). In: CR 2/1989, S. 146-152. [Marly91] Marly, J.: Softwareüberlassungsverträge. München, 1991: Beck'sche Verlagsbuchhandlung. [Möll93] Möller, K.H./Paulish, D.J.: Software-Metriken in der Praxis. München u.a., 1993: Oldenbourg. [Müll95] Müller-Hengstenberg, C.-D.: Risikoteilung in DV-Projekten. In: CR 4/1995, S. 198-205. [Niel93] Nielsen, J.: Usability Engineering. In: AP Professional 1993. [Opp88] Oppermann, R. et al.: Evaluation von Dialogsystemen. Der software-ergonomischeLeitfaden EVADIS. Berlin u.a., 1988: De Gruyter. [Opp97] Oppermann, R.: Workshopunterlagen. Workshop 1997 Fachtagung Software-Ergonomie. Dresden. 1997. [Pom93] Pomberger, G./Blaschek, G.: Software Engineering, Prototying und objektorientierteSoftware-Entwicklung. München u.a., 1993: Hanser. [Raut95] Rauterberg, M.: Ein Konzept zur Quantifizierung software-ergonomischer Richtlinien.Institut für Arbeitspsychologie an der Eidgenössischen Hochschule Zürich 1995. [Red93] Redeker, H.: Der Rechtsbegriff des Mangels beim Erwerb von Software. In: CR 1993, S. 193-198. [SANUS] Projektbeschreibung Stand Juni 1996; http://sanus.uni_wuppertal.de. [Schaub93] Schaub, B.: Das Pflichtenheft im Spiegel der Rechtsprechung. In: CR 1993, S. 329-334. [Schier94] Schierbaum, B.: EG-Richtlinie zur Bildschirmarbeit. In: CR 1994, S. 410-417. [Schmidt92] Schmidt, H.: Beratungsleistungen und Mitwirkungspflichten. In: CR 1992, S. 709-714. [Schütze98] Schütze, R.A.; Weipert, L.: Münchner Vertragshandbuch. Band 3 Wirtschaftsrecht. 1. Halbband Wirtschaftsrecht. München, 1998: C.H.Beck'sche Verlagsbuchhandlung. [Schwald81] Schwald, A.: Schnittstellen in Phasenmodellen. In: Floyd, C./Kopetz, H. (Hg.): Software-Engineering – Entwurf und Spezifikation. Stuttgart, 1981: Teubner, S. 329-330. [Streitz95] Streitz, S.: Technische Abnahme. In: NJW-CoR 6/95, S. 410-413. [Stuur95] Stuurman, C.: Technische normen en het recht .Deventer, 1995: Kluwer. [Suhr93] Suhr, R./Suhr, R.: Software-Engineering; Technik und Methoden. München u.a., 1993: Oldenbourg. [Taeg95] Taeger, J.: Außervertragliche Haftung für fehlerhafte Computerprogramme. Tübingen, 1995: Mohr. (Habilitationsschrift) [Vier93] Viereck, A.: Design von Benutzungsoberflächen als ingenieursmäßiger Prozeß. In: Rödiger, K.-H. (Hg.): Software-Ergonomie 93. Stuttgart, 1993: Teubner, S. 311-320. [Vorn99] Vorndamme, J.: Die Auswirkungen rechtlicher Verpflichtungen auf die Softwareentwicklung. 1999: Oldenburger Hochschulreihe. [West93] Westphalen, F.: Software und Produzentenhaftung. In: NJW-CoR 6/93, S. 22-24. [Wott90] Wottawa, H./Thierau, H.: Lehrbuch Evaluation. Bern u.a., 1990: Huber. |
 Abb.: Makro-Prozeß VIPSO |
Fußnoten: |
| (1) Siehe [Kies95, 47],
[Suhr93]; [Balz81]; [Schwald81]; [Boehm89a-d];[Keil92]; [Floyd92a]; [Floyd92b];
[Pom93]; [Floyd89]; [Floyd94]. (2) Siehe die diesem Artikel zugrundeliegende Dissertation [Vorn99]. (3) Siehe [Vornd99; 28]. (4) Ebenfalls festgestellt von [Kil84, 27]; [Bons84, 36]; [Gorn86, 675]; [Heuss88a, 897]; [Böm89, 361]; [Red93, 195]. (5) Siehe [Kil84, 23]; [Gorn86, 676]; [Less89a, 146]; [Brand90, 312]; [West93, 23]; [Dev97, 111]; [Koch91, 98]; [Marly91, 202]. (6) Siehe [OLG Köln, CR 1/96, 20]; [OLG Celle, CR 3/95, 152]. (7) Diese Unterscheidung auch bei [Gorn84a, 7] und [Taeg95;11]. Marly schildert ebenso die Diskussion der verschiedenen Fehlerbegriffe in Informatik und Rechtswissenschaft. Er kommt zu dem Schluß, daß der Fehlerbegriff der Informatik keine Relevanz hat, weil bei Konflikten immer auf den juristischen Fachbegriff zurückgegriffen wird [Marly91, 222]. (8) Dies wird ebenso gesehen von [Kil84, 27]; [Bons84, 41]; [Heuss88a, 899]; [Böm89, 362]; [Red93, 193]; [Red93, 195]. (9) Ebenso gesehen in der Literatur: [Red93, 193]; [Kil84, 27]; [Gorn86, 674]; [Schaub93, 329] und in der Rechtsprechung: [OLG Karsruhe, CR7/95, 397]; [OLG Düsseldorf, CR 6/93, 361]; [LG Trier, CR 4/95, 221]. (10)Siehe auch [Red93, 193]; [Fisch94, 357]. |
| (11) Siehe auch [Bons84, 39];
[Stuur95, 520]. (12) Ebenso bei [Less89a, 151]; [Dev97, 111]; [Schaub93, 82]; [Marly91, 204]. (13)Siehe [Marly91, 220]. (14) Ebenso bei [Less89a, 146]; [Red93, 196]; [Red93, 198]; [Schaub93, 329]. (15) In der Rechtsprechung: [LG Bamberg, BB Beilage 11/89, Urteil Nr. 1]. (16) Vgl. [Bons84, 42]. (17) So sieht [Schaub93, 332] z.B. Parallelen zum Baurecht; ähnlich: [Less89a, 150]; [Schmidt92, 712]; [Müll95,202 u. 203];[Schütze98;625] im Münchener Vertragshandbuch zum Programmerstellungsvertrag. (18) Siehe [OLG Köln, CR 92, 497ff]. (19)Zustimmung durch die Literatur vgl. [Gorn86, 677]; [Schaub93, 332]; [Schaub93, 334]; [Less89a, 150]; [Bons84, 40]; [Böm89, 365f]; [Less89a, 148]; [Brand90, 315]; [Schmidt92, 711]; [Müll95, 199]; [Koch91, 86 u. 101]. (20) Zustimmung durch die Rechtsprechung vgl. [BGH, CR 8/96, 467]; [BGH, NJW CoR 5/95]; [OLG Köln, NJW CoR 3/96, 190] bzw. [OLG Köln, CR1/96, 20]; [BGH, CR 89, 102]. |
| (21) Siehe [Schaub93;82],
[Less89a, 151]; [Dev97, 111]; [Gorn86, 673]. (22)Ist dies nicht der Fall, kann der Anbieter keine Berücksichtigung von mehr Aufwand erwarten, sondern hat sozusagen konkludent die Veränderung akzeptiert [Brand90, 317]. (23) Wie es auch [Müll95, 199] vorstellt. (24) Ebenso bei [Schaub93, 334]. (25) So auch [Müll95, 201 u. 205]. (26) Z. B. über die Gewährleistung und die zu erfolgenden Zahlungen: vgl. [Bran90, 314]. (27) Ebenfalls [Brand90, 314]. (28) Siehe [BGH, CR11/96, 667]; [OLG Hamm, NJW CoR 5/92, 27]; [OLG Stuttgart, NJW CoR 4/96]. (29)Siehe auch [Streitz95, 410] und [Koch91, 218]. (30)Wie es das OLG Köln entschieden hat [OLG Köln, CR 9/92, 544ff]. |
| (31) Siehe [Koch91, 85]. (32) Vom 4.12.1996 im BGBl.IS.1841. (33) [ABl EG 1990 Nr. L 156/14] (34) Es handelt sich um die "Verordnung über Sicherheit und Gesundheitsschutz bei der Arbeit an Bild schirmgeräten " (BGBl. IS. 1841ff) , die als Artiel 3 der "Verordnung zur Umsetzung von EG-Einzelrichtlinien zur EG-Rahmenrichtlinie Arbeitsschutz erlassen wurde (BGBl. I vom 19.12.1996, S. 1841ff) [Hart97,884]. (35)Dies geschah mit erheblicher Verspätung, obwohl eine Verpflichtung zur nationalen Umsetzung bis zum 31.12.92 bestand [Fisch94, 357]; [Kies95,41]; [Bred97,60]. Aus dieser verspäteten Umsetzung sind durch aus auch negative Rechtsfolgen für die Bundesrepublik denkbar [Bred97, 60]. (36) Vgl. [Bred97,62]. (37) Wie es [Raut95, 98] in seiner Dissertation schließt. Nur einige Beispiele: Zur Eingliederung von Ergonomiewissen in die Anforderungserarbeitung mittels MUSE und EXPOSE [Gorn93]; [Gorn95]; [Vier93, 316f] zur Technik des Dialog-Designs; zu Usability-Methoden etwa [Niel93, 223]; außerdem das SANUS-Projekt [SANUS]. (38)[EN ISO 9241-11: Guidance on specificying and measuring usability, Stand May 7, 1993, 4]; siehe auch [Kies95, 43] und [Hart97, 886]. (39) [EN ISO 9241-11: Guidance on specificying and measuring usability, Stand May 7, 1993, 5]; [Dum94, 102] sieht als bestimmende Rahmenbedingungen z.B. die HW- und SW-Voraussetzungen. (40)Auch [Kies95, 44] sieht die Notwendigkeit, für die Konkretisierung von Anforderungen aus der RL auf Normen zurückzugreifen. |
| (41) [Beim93, 134] (42) In diesem Sinne äußert sich eine ganze Reihe von Autoren, z.B. [Haus89, 377]; [Möll93, 17]. (43) Diese Erwartung teilt auch [Schier94, 415]. (44) Wie ihn auch [Engl93, 58] und [Opp88, 8f] sehen. (45) Siehe [Dum94, 89]; [Wott90, 9]. (46) Vgl. [Hamp94, 14f]. (47) Siehe [Kar88, 892]. (48) Insbesondere die Zuverlässigkeit ist häufig schwer zu überprüfen, weil es nachgewiesenermaßen erhebliche Unterschiede bei verschiedenen Testnutzern gibt [SANUS, Kap. 6, S. 6]; [Görn93, 191]. (49) Teilweise auch bei [Hamp94, 229] oder [Opp88, 9]. (50) Wie sie nachgewiesen wurden bei [Vorn99; 66]. |
| (51) [Beck 93a, 202] (52) Siehe dazu [Vorn99; 82ff]. (53) Siehe [Bäum95;2]. |
| * Prof. Dr. Juliane Vorndamme hat in Saarbrücken und Hannover Mathematik studiert und ist seit 1989 Diplom - Mathematikerin. Von 1989 bis 1997 war sie in der Industrie als Entwicklerin und Projektleiterin tätig. Promotion zum Dr. rer. nat. im Fachbereich Informatik der Carl-von-Ossietzky-Universität Oldenburg. Seit 1997 Lehrstuhl "Echtzeitdatenverarbeitung und Betriebssysteme" des FB Elektrotechnik an der Fachhochschule Wilhelmshaven Forschungsschwerpunkte: Softwareengineering / Echtzeitdatenverarbeitung. |
| [online seit: 28.01.2000] |
| Zitiervorschlag: Autor, Titel, JurPC Web-Dok., Abs. |
| Zitiervorschlag: Vorndamme, Juliane, Beeinflussung des Softwareentwicklungsprozesses durch ausgewählte rechtliche Verpflichtungen - JurPC-Web-Dok. 0001/2000 |
