%%% @(#) se-errors-2.tex  1.5  10/10/95
%%&\documentstyle[german,a4,supertab]{article}
\documentstyle[art10,twocolumn,german]{article}
\input{/home/pi/kelter/p/tex/a4.tex}
\input{/home/pi/kelter/p/tex/endversion.tex}
\columnsep8mm

% \renewcommand{\newpage}{}

\newcommand{\KM}{Kon\-fi\-gu\-ra\-tions\-manage\-ment}


\pagestyle{empty}


\begin{document}

\title{Klassische Fehler in der Software-Entwicklung}

\author{CEFE - CAD/CAM-Entwicklungsgesellschaft
\\
   Arbeitsgruppe 19 Software Engineering\thanks
      {Specher der Arbeitsgruppe:  Dierk Wendt, GDV-E,
      Hella KG, 59552 Lippstadt, 02941/387614,
      wendt@hella.de
}}

\date{}%Version vom 06.10.1995}

\maketitle

\section{Einleitung}
In diesem Artikel werden einige typische Fehler behandelt, die im Rahmen 
der Software-Entwicklung h"aufig auftreten.
Anhand von allgemein gehaltenen Beispielen zu den Ursachen, den m"oglichen 
Folgen und entsprechenden Ma"snahmen soll das Problembewu"stsein der Entwickler
und ihrer Vorgesetzten zu den einzelnen Punkten gest"arkt werden. 
Obwohl viele dieser Fehler zwar seit langem bekannt sind, ist die
Vermeidung dieser Fehler trotzdem weitaus schwieriger, als es auf den ersten Blick
scheint. Bei immer k"urzer werdenden Entwicklungszyklen und st"andig steigender
Komplexit"at der "au"seren Rahmenbedingungen mu"s mit dem zur Verf"ugung 
stehenden Budget in m"oglichst kurzer Zeit qualitativ hochwertige Software 
entwickelt werden, die au"serdem noch entsprechenden Konkurrenzprodukten 
"uberlegen ist. Die Kosten f"ur die Beseitigung von Produktm"angeln stellen
in der Regel direkt entgangenen Gewinn dar. Der Entwicklungsproze"s ist deshalb
unter vertretbarem Aufwand so zu gestalten, da"s M"angel gar nicht erst auftreten.


\section{"Ubersicht}
Die einzelnen Fehler werden zun"achst in Kategorien eingeteilt, die zum Teil
mit den Phasen des Software-Ent"-wicklungssprozesses identisch sind. Anschlie"send
werden im n"achsten Kapitel zu jedem der Fehler verschiedene Ursachen, Folgen
und Ma"snahmen zur Vermeidung dieser Fehler im Detail ausgef"uhrt.


\BD

\item [Vorgehensmodell:] ~ \par
\BI
\item Es wird direkt mit der Codierung angefangen.
\item Das Vorgehensmodell fehlt bzw.\ wird nicht befolgt.
\item Die Terminvorgaben sind unrealistisch.
\item Die Weiterbildung der Mitarbeiter ist nicht zielgerichtet.
\item Auswahl und Einsatz der Werkzeuge bzw.\ Methoden ist unzureichend vorbereitet.
\item Ein Risikomanagement wird nicht betrieben.
\EI
 
\item [Verifizierung und Validierung:] ~ \par
\BI
\item Eine Abnahme der Phasenergebnisse erfolgt nicht.
\item Es wird nicht systematisch bzw.\ unzureichend getestet.
\EI
 
\item [Problem- und Systemanalyse:] ~ \par
\BI
\item Die Anforderungen und Qualit"atsmerkmale werden nicht festgelegt.
\item Es fehlen eindeutige Begriffsdefinitionen.
\EI
 
\item [Systementwurf:] ~ \par

\BI
\item Die Systemarchitektur ist gar nicht oder nur mit gro"sem Aufwand erweiterbar.
\item Das System ist nicht modular aufgebaut, die Daten sind nicht gekapselt.
\EI
 
\item [Codierung:] ~ \par
\BI
\item Programmier-Standards bzw. -Richtlinien werden nicht beachtet.
\item Die Namensvergabe ist ung"unstig.
\EI
 
\item [Betrieb und Wartung:] ~ \par
\BI
\item Die Dokumentation fehlt ganz, ist veraltet oder nicht ad"aquat.
\item Die Schulung der Anwender wird vernachl"assigt.
\item Das \KM\ ist unzureichend.
\EI

\ED



\noindent
\begin{figure}[ht]
\vspace*{8cm}
\special{psfile=15_4_grafik.ps}
\caption{Einflu"sfaktoren auf die Fehlerkosten betrachtet "uber den Lebenszyklus}
\end{figure}



%\newpage 
\section{Erl"auterungen}
\subsection{Vorgehensmodell}
Das Vorgehensmodell zerlegt den Software-Ent"-wicklungsproze"s in "uberschaubare
Phasen und definiert Aktionen und Ergebnisse. Erst dadurch kann der Schritt von
''chaotischer Software-Bastelei'' zur industriellen Software-Produktion vollzogen 
werden. Ist ein unstrukturiertes Vorgehen bei Quick \& Dirty Wegwerf-Software noch
zu tolerieren, so hat das bei allen Systemen, die einer Wartung unterliegen, 
vernichtende Konsequenzen. Das Fehlen oder auch Nichtbefolgen eines Vorgehensmodells
bedeutet, da"s der Software-Entwicklungsproze"s nicht beherrscht wird.

Ein Vergleich: Ein Schreiner, der eine T"ur bauen soll, nimmt das Ma"s auf, l"a"st
sich die Details der T"ur vom Bauherren (schriftlich) best"atigen, fertigt eine Skizze
an, stellt T"ur und Zarge in der Werkstatt her, geht zur Baustelle und setzt sie
ein. K"ame der Mann aus der Software-Entwicklung, unterl"age er der Versuchung,
sein Werkzeug und einen gro"sen Stapel Holz aus dem Lager an die Baustelle zu
transportieren und dort solange zu s"agen, bohren, schrauben und h"ammern, bis das
Loch in der Wand geschlossen ist, mit mehr oder minder zuf"alligem Ergebnis.

Und dort liegt die Krux in der Software-Entwicklung. Die Umgebung gestattet es
in der Regel, bis zum letzten Moment an dem Produkt zu "andern, ohne da"s man es
diesem sofort ansieht, w"ahrend der Schreiner aus dem Beispiel ohne sein strukturiertes 
Vorgehen den Auftrag nicht mit wirtschaftlichem Erfolg und f"ur den Kunden
zufriedenstellend abschlie"sen k"onnte. Das geht auch in der Software-Entwicklung
nicht, nur merkt man es nicht so schnell!

Software-Projekte laufen immer Gefahr, Termin und Budget zu "uberschreiten.
Durch die Zerlegung in "uberschaubare Phasen gewinnt man
mit einem Vorgehensmodell Planungssicherheit und erh"alt durch die eingebauten
Meilensteine und Verifizierungen ein Lenkungsinstrument, mit dem fr"uhzeitig 
Abweichungen erkannt und Korrekturma"snahmen ergriffen werden k"onnen. Eine 
Koordination mehrerer in das Projekt eingebundener Personen oder Stellen ist ohne
Vorgehensmodell praktisch nicht m"oglich. So wird oft bei gro"sen und kritischen
Projekten das anzuwendende Modell vom Auftraggeber (z.B. ESA) vorgeschrieben.

\subsubsection{Es wird direkt mit der Codierung angefangen}
\BIB

\item Ursachen:

\BI
\item
Dies ist wohl der h"aufigste Fehler in der Softwareentwicklung. 
Dieses Vorgehen bringt dem Entwickler vordergr"undig einen Zeitgewinn. 
Er kann sehr schnell etwas vorweisen und eine L"osung pr"asentieren.
\EI

\item Folgen:

\BI
\item 
Das Umsetzen der ersten Ideen direkt in Source Code ist immer unzul"anglich,
da der wichtigste Schritt -- das Systemdesign -- umgangen wird. 
Selbst f"ur eine prototypische Umsetzung ist das Vorgehen nicht geeignet, 
da ohne Betrachtung der Systemumgebung und m"oglicher Realisierungsalternativen
auch die Aussagekraft des Prototyps sehr zweifelhaft ist. 
Ohne Dokumentation des gedanklichen Weges, der zu dem Software-Produkt 
gef"uhrt hat, ist dieses f"ur Au"senstehende und nach einiger Zeit 
oft auch f"ur den Autor nicht mehr nachvollziehbar. 
Selbst mit entsprechender Dokumentation ist dies oft schwierig genug. 
Sogenannte Prototypen bergen zudem immer das Risiko, pl"otzlich aus Zeitdruck 
zu einem Produkt bef"ordert zu werden.

\EI

\item Ma"snahmen:

\BI
\item 
Die direkte Codierung mu"s rigoros auf Wegwerf-Software begrenzt werden 
(z.B. kurz ben"otigte Testumgebung, ''workarounds''). 

\item 
Seitens der F"uhrung mu"s sichergestellt werden, da"s strukturiert vorgegangen
wird. Dazu mu"s ein Vorgehensmodell oder -plan existieren, der die 
Entwurfsphasen ber"ucksichtigt. 

\item 
Der Entwickler mu"s angehalten werden, Entwurfsdokumente zu erstellen. 
Diese m"ussen zeitlich geplant, verabschiedet und aktuell gehalten werden.
\EI

\EIB
 
\subsubsection{Das Vorgehensmodell fehlt bzw.\ wird nicht befolgt}
\BIB

\item Ursachen:

\BI
\item 
Die Notwendigkeit wird nicht erkannt: ''Hier wei"s jeder, was zu tun ist''. 
Das kann f"ur eine geschlossene Gruppe mit einer starken F"uhrung, die 
die F"aden in der Hand h"alt, zutreffend sein. In diesem Fall wird implizit nach 
einem ungeschriebenen Vorgehensmodell entwickelt.

\item 
Die Leitung nutzt ihrerseits nicht die Steuerinstrumente, die das 
Vorgehensmodell bietet. Es ist ein Papiertiger und wird deshalb nicht befolgt.

\item 
Das Arbeiten nach einem Vorgehensmodell macht die Arbeit transparent.
Das m"ogen viele Entwickler aus unterschiedlichen Gr"unden nicht.

\EI
 
\item Folgen:

\BI
\item 
Die Planung ist unsicher.

\item 
Die Leitung verzichtet auf ein wirksames Instrumentarium, um Projekte 
erfolgreich zu lenken. Probleme werden deshalb zu sp"at erkannt.


\item 
Die Gefahr von Qualit"atsproblemen steigt.

\item 
Teamwork und die Kommunikation zwischen den Teams wird erschwert.


\item 
Die Einarbeitung in ein fremdes Projekt dauert l"anger, 
auch f"ur neue Mitarbeiter.
\EI

\item Ma"snahmen:

\BI
\item
Falls noch nicht existent, mu"s ein Vorgehensmodell definiert und eingef"uhrt werden.
Dabei spielt es keine Rolle, welches Vorgehensmodell 
(Wasserfall, V-Modell, Spiralmodell, ...) als Basis ausgew"ahlt wird. 
Wichtig ist dabei, da"s alle Entwickler ihre T"atigkeit darin 
wiederfinden m"ussen und das Modell auf alle Projekte je nach 
Gr"o"se und Risiko konfektionierbar ist, zum Beispiel durch die
Unterscheidung zwischen obligatorischen und fakultativen Meilensteinen.

\item 
Der positive Effekt des Vorgehensmodells auf die Qualit"at ist allen
Beteiligten deutlich zu machen.
\EI

\EIB


\subsubsection{Die Terminvorgaben sind unrealistisch}
\BIB

\item Ursachen:

\BI
\item
Es wird nach dem Motto verfahren, das Unm"ogliche fordern, um das M"ogliche 
zu erreichen.

\item 
Die Einbeziehung der DV-Aspekte in die Projektplanung ist mangelhaft.

\item 
Die Qualifikation in Planungs-, Organisations- und F"uhrungstechniken ist zu gering. 

\item 
Der meist gro"se Zeitbedarf f"ur Verifizierung und Validierung wird weit
untersch"atzt.
 
\EI

\item Folgen:

\BI
\item 
Es herrscht Frust und Pessimismus bei den beteiligten Mitarbeitern. 

\item 
Es gibt Akzeptanzprobleme bez"uglich der Zielvorgaben, Ma"snahmen und 
Leitungsstrukturen.

\item 
Die Mitarbeiter f"uhlen sich "ubergangen. 
\EI

\item Ma"snahmen:

\BI
\item
Es sind realistische Ziele zu vereinbaren.
 
\item 
Alle betroffenen Stellen im eigenen Hause sowie ggfs. weitere 
beteiligte Unternehmen sind fr"uhzeitig in die Terminplanung einzubeziehen. 

\item 
Qualifizierung der entsprechenden Mitarbeiter in formellen Planungs-, 
Organisations-, Controlling- und F"uhrungstechniken.

\item 
Gewissenhafte und umfassende Information aller Mitarbeiter, soweit vertretbar. 
Fehlende offizielle Information f"ordert die Entstehung und Fehl\-interpretation 
inoffizieller Informationen.
 
\EI

\EIB


\subsubsection{Die Weiterbildung der Mitarbeiter ist nicht zielgerichtet}
\BIB

\item Ursachen:

\BI
\item 
Weiterbildung betrifft oft zuk"unftige Aufgaben, die h"aufig aufgrund 
kurzfristiger "Uberlegungen dem aktuellen Tagesgesch"aft untergeordnet 
wird.

\item 
Die Mitarbeiter werden nicht als strategische Ressource angesehen.

\item 
Kosten und Termingr"unde.

\item 
Weiterbildungsma"snahmen, insbesondere extern durchgef"uhrte, werden zum
Teil als Prestigesymbol angesehen. Firmenspezifische Belange sind dabei
nebens"achlich. 

\EI

\item Folgen:

\BI
\item 
Es gibt keine systematische Fortbildung, insbesondere fehlt Training-on-the-job. 
Ohne geplante Weiterbildungsma"snahmen entspricht die Qualifikation der 
Mitarbeiter langfristig nicht mehr den Anforderungen.

\item
Die Mitarbeiter greifen zum Selbststudium. Dies ist in der Regel mit
gro"sem Zeitverlust verbunden. Au"serdem fehlt oft der thematische 
Gesamt"uberblick aufgrund von l"uckenhaftem Wissen.

\EI

\item Ma"snahmen:

\BI
\item 
Eine gr"undliche Ausbildung in den verwendeten Methoden, Verfahren und 
Werkzeugen ist eine wichtige Voraussetzung f"ur positive Arbeitsergebnisse. 
Deshalb ist es angebracht, die Entwicklung des Produktionsfaktors ''Arbeit''
ebenso systematisch zu managen, wie die anderer Produktionsfaktoren.

\item 
Externe Schulungen k"onnen firmenspezifischen Weiterbildungsbedarf nicht 
immer befriedigend decken. Es kann daher sinnvoll sein, durch befristete, 
projektbezogene Einbeziehung externen Expertenwissens (z.B. Hochschulen, 
Unternehmensberatungen usw.) ein Training-on-the-job zu realisieren. 
Wichtig hierbei ist, da"s ein Know-how-Transfer sichergestellt wird.

\item 
Ein Erfahrungsaustausch ist oft im Rahmen von firmen"ubergreifenden 
Workshops oder Arbeitskreisen m"oglich. Diese werden von Berufsorganisationen,
Universit"aten usw. angeboten.  
\EI

\EIB
 

\subsubsection{Auswahl und Einsatz der Werkzeuge bzw.\ Methoden ist unzureichend vorbereitet}
\BIB

\item Ursachen:

\BI
\item
Bei Projektbeginn sind die Anforderungen an die Werkzeuge bzw. Methoden noch unklar.

\item
Moderne Software-Ent"-wicklungswerkzeuge sind z.T. sehr komplex; 
ihre Beurteilung und Auswahl\- ist daher zeitaufwendig.

\item
Der Weiterbildungsbedarf der Mitarbeiter be\-z"uglich neuer Technologien wird 
untersch"atzt.
 
\EI

\item Folgen:

\BI
\item 
Ungeeignete Methoden und Werkzeuge f"uhren zu Produktivit"ats- und 
Qualit"atseinbu"sen.

\item
Die Mitarbeiter versuchen, inad"aquate Werkzeuge zu umgehen.

\item
Die Fehlinvestionen f"ur falsche Werkzeuge m"ussen oft teuer bezahlt werden 
(Wartungskosten alter Daten, Anschaffungs- und Schulungskosten f"ur das 
neue Werkzeug).
\EI

\item Ma"snahmen:

\BI
\item 
Neue Unternehmensstrategien k"onnen eine Anpassung 
von Methoden und Werkzeugen notwendig machen. Dies ist bei der
Planung und Auswahl zu ber"ucksichtigen.

\item
Die Einbeziehung von externem Expertenwissen ist oft sinnvoll. 
Das entscheidende Kriterium ist dabei die nachgewiesene Praxiserfahrung des
Beraters und nicht ein wohlklingender akademischer Titel.

\item
Kriterienkataloge f"ur die Auswahl von Werkzeugen bzw. Evaulationsberichte
von Unternehmensberatungen k"onnen wichtige Hinweise 
liefern. Weitergehende Informationen bieten Workshops oder Anwenderkonferenzen.

\item
In einem Pilotprojekt sind ein oder zwei der in Frage kommenden Werkzeuge
bzgl. ihrer Leistungen im ''Alltagsgesch"aft'' gr"undlich zu testen. 
\EI

\EIB


\subsubsection{Ein Risikomanagement wird nicht betrieben}
\BIB

\item Ursachen:

\BI
\item
Der Kosten- und Termindruck ist zu gro"s.

\item
Problempotentiale, insbesondere fachfremde Aspekte wie die Produkthaftung,
werden falsch eingesch"atzt.

\item
Risiken werden ''aktiv verdr"angt''.

\item
Es fehlt eine Datenbasis mit brauchbaren Erfahrungswerten.
  
\EI

\item Folgen:

\BI
\item 
Planungen sind unzuverl"assig, da sie Risikopotentiale nicht ber"ucksichtigen. 
Durch unvorhergesehene Probleme werden Terminverz"ogerungen und 
Kosten"uberschreitungen verursacht.

\item 
Es fehlen Regelkreise im Vorgehensmodell, um die Phasenergebnisse zu validieren.
Die konstruierten Systeme gehen u.U. an den Realwelt-Gege\-ben\-heiten 
(Datenumfang, Schnittstellen, Kundenw"unsche usw.) vorbei.
 
\EI

\item Ma"snahmen:

\BI
\item 
Risikomanagement ist erlernbar. Projekte scheitern nicht an den Dingen,
die beherrscht werden oder schon "ahnlich konstruiert wurden. Problematisch
sind in der Regel nur neue Technologien. Deshalb ist die Integration des 
Risikomanagementes in ein Vorgehensmodell (z.B. das Spiralmodell nach Boehm) 
wichtig.

\item 
Benchmarking und Prototyping sind wichtige Methoden zum identifizieren 
und absch"atzen von Risiken.

\item 
Fremdleistungen (z.B. Software-Module) sollten st"andig "uberwacht werden. 
Hier darf die Qualit"atssicherung nicht vernachl"assigt werden.

\item 
Wenn kein ausreichendes eigenes Know-how vorhanden ist, kann m"oglicherweise 
externe Erfahrung genutzt werden.

\EI

\EIB
  

\subsection{Verifizierung und Validierung}
Qualit"atspr"ufungen m"ussen in jeder Phase des Entwicklungsprozesses
durchgef"uhrt werden. Idealerweise sollte jedes Zwischenprodukt "uberpr"uft werden:
Definition, Spezifikation, Entwurf, Code, Benutzer-Dokumentation,
mit einem Wort: alles.

Um diese Pr"ufungen und Tests durchf"uhren zu k"onnen, mu"s selbstverst"andlich
vorher definiert werden, welche (Qualit"ats-)Eigenschaften die
jeweiligen Zwischenprodukte haben sollen. Das hei"st, da"s aus den
Anforderungen an das Endprodukt die Anforderungen an das jeweilige Zwischenprodukt 
abgeleitet werden m"ussen.

Qualit"atssicherung wird in der Software-Entwick\-lung durch Verfikations-
und Validierungs-Aktivit"aten geleistet. Bei der Verifizierung wird die Frage
''Haben wir das System richtig entwickelt?'' beantwortet, d.h. es wird gepr"uft,
ob es die Anforderungen der Spezifikation der jeweiligen Entwicklungsphase
erf"ullt. Die Validierung hingegen soll die Frage ''Haben wir das richtige
System entwickelt?'' beantworten; es wird "uberpr"uft, ob die Anforderungen
des Kunden erf"ullt werden.

Wir k"onnen und sollten pr"ufen
\BIB
\item jede Spezifikation bez"uglich ihrer internen Folgerichtigkeit und
      Widerspruchsfreiheit,
\item jede Spezifikation (au"ser der ersten) in Hinblick auf die Vorg"anger-
      Spezifikation (Vollst"andigkeit, genaue funktionale Entsprechung),
\item jedes Programm-Modul bez"uglich der zugeh"origen Spezifikation auf
      Vollst"andigkeit und funktionale Gleichwertigkeit,
\item jedes Programm-Modul hinsichtlich der internen Folgerichtigkeit und
      Widerspruchsfreiheit
\EIB


\subsubsection{Eine Abnahme der Phasenergebnisse erfolgt nicht}
\BIB

\item Ursachen:

\BI
\item 
Die Anforderungen und Qualit"atsmerkmale wurden nicht festgelegt.

\item 
Ein geeignetes Vorgehensmodell fehlt.

\item 
Durch h"aufige Iterationen im Entwicklungsablauf ist ein
Phasenabschlu"s nicht immer eindeutig erkennbar.

\EI

\item Folgen:

\BI
\item
Fehler werden erst in sp"ateren Phasen oder sogar erst beim
Kunden entdeckt.

\item
Die Kosten steigen infolge verz"ogerter Fehlerentdeckung 
exponentiell an.

\item
Der Projekt-Fortschritt kann nicht beurteilt werden, da "uber
die Qualit"at der vorliegenden Produkte keine durch Pr"ufungen
best"atigte Aussagen vorliegen.

\EI

\item Ma"snahmen:

\BI
\item
Die Zeitpunkte und die Voraussetzungen f"ur die Abnahme der
Phasenergebnisse m"ussen im Vorgehensmodell bzw. dem Projekt-Plan 
eindeutig festgelegt werden. 

\item
Sehr gut geeignet f"ur die "Uberpr"ufung der Phasenergebnisse
sind Review-Verfahren. Die Vorteile des Review-Verfahrens
zeigt die nachstehende Tabelle \cite{krueger}:


\vspace{0.5cm}
\noindent 
\begin{tabular}{|p{41mm}|p{17mm}|}
\hline Entwicklungsphase 
   & Gefundene Fehler \\ 
\hline
Review der funktionalen Spezifikation &       2 ...  5 \% \\
Review der Grobentwurfes              &      10 ... 16 \% \\
Review des Feinentwurfes              &      17 ... 22 \% \\
Review des Codes                      &      20 ... 32 \% \\
Modultest                             &      12 ... 17 \% \\
Funktionstest                         &      10 ... 14 \% \\
Komponententest                       &       8 ... 14 \% \\
Systemtest                            &     0,5 ...  7 \% \\
\hline
\end{tabular}

\EI

\EIB


\subsubsection{Es wird nicht systematisch bzw.\ unzureichend getestet}
\BIB

\item Ursachen:

\BI
\item 
Es ist angeblich keine Zeit f"ur systematische Tests
vorhanden (Termindruck).

\item 
Die Notwendigkeit f"ur systematische Tests wird nicht erkannt.

\item 
Die Erstellung von Testspezifikationen f"ur systematische
Tests wird nicht entwicklungsbegleitend - beginnend in den
ersten Entwicklungsphasen - durchgef"uhrt, sondern erst
unmittelbar vor dem erforderlichen Test, so da"s der
Arbeitsaufwand zum Testzeitpunkt sehr gro"s ist.

\EI

\item Folgen:

\BI
\item 
Tests, die nicht systematisch durchgef"uhrt werden, k"onnen
nicht reproduziert werden, d.h. Regressionstests sind nicht
m"oglich.

\item 
Verbesserungen der Tests sind nicht m"oglich, da sp"ater
auftretende Fehler nicht auf bestimmte (unzureichende)
Testschritte zur"uckgef"uhrt werden k"onnen.

\item 
Nicht entdeckte Fehler 
\BI
\item
k"onnen je nach Art der Software hohe Sch"aden bis hin zu
Personensch"aden mit allen damit verbundenen Konsequenzen verursachen;

\item
verursachen Fehlerbeseitigungskosten, die h"oher sind als
die Kosten, die bei einem systematischen Test sofort nach der
Erstellung der Software auftreten.
\EI

\EI

\item Ma"snahmen:

\BI
\item 
Die m"oglichen Konsequenzen unzureichender Tests m"ussen
verdeutlicht werden.

\item 
In einem Pr"ufplan m"ussen die im Entwicklungsablauf durchzuf"uhrenden
Pr"ufungen und Tests verbindlich festgelegt werden.

\item 
Die f"ur Pr"ufungen und Tests ben"otigte Zeit mu"s eingeplant werden.
\EI

\EIB

  
\subsection{Problem- und Systemanalyse}
Viele Entwicklungsprojekte scheitern letztendlich daran, da"s der Problemanalyse
im Vorfeld nicht gen"ugend Beachtung geschenkt worden ist. Fehler, die in dieser
Phase gemacht werden, lassen sich sp"ater, wenn "uberhaupt, nur mit sehr hohem
Aufwand korrigieren. In dieser Phase wird grob beschrieben, was das zuk"unftige
System leisten soll. Hierzu werden die Methoden zur Funktions- und
Datenmodellierung eingesetzt, um Modelle in einer groben Detaillierung zu
erstellen. Der Detaillierungsgrad mu"s eine Aussage "uber die
Wirtschaftlichkeit des geplanten Vorhabens erm"oglichen. In dieser Phase gibt
es eine enge Zusammenarbeit zwischen Anwendern und Systemanalytikern.


\subsubsection{Die Anforderungen und Qualit"atsmerkmale werden nicht festgelegt}
\BIB

\item Ursachen:

\BI
\item
Das Pflichtenheft fehlt komplett oder wurde nur m"undlich besprochen.
Nicht selten wird das Pflichtenheft auch vom Entwickler selbst erstellt.
 
\item
Die Anwender wollen sich noch nicht festlegen 
oder geben ihre Anforderungen nur unvollst"andig oder ungenau an.

\item
Mangelndes Vorstellungsverm"ogen der Anwender "uber die M"oglichkeiten 
der Software-Entwicklung.

\item
Die Anforderungen an das System, bzw. seine Leistungsgrenzen werden durch 
eine ''vorl"aufige'' Version der Software ermittelt.

\item
W"ahrend der Benutzung einer ersten Programmversion "andert sich der 
Arbeitsstil der Anwender, dadurch ergeben sich f"ur ihn neue Perspektiven 
und in der Folge auch neue Anforderungen.

\item
Wichtige Qualit"atskriterien (z.B. das Laufzeitverhalten des Programmes, 
das Aussehen der Oberfl"ache, die maximale Anzahl an Einzelaktionen f"ur 
einen Vorgang) werden nicht spezifiziert.

\EI

\item Folgen:

\BI
\item 
Die Software mu"s mit einem erheblichen Mehraufwand ge"andert oder erweitert
werden. 

\item 
Es entsteht Software, die nicht den (nicht schriftlich niedergelegten) 
Vorstellungen des Kunden entspricht. Bei gravierenden M"angeln aus 
Anwendersicht kann es passieren, da"s die Software gar nicht benutzt wird.

\EI

\item Ma"snahmen:

\BI
\item 
Die Anforderungen der Anwender an die Software und alle wichtigen 
Qualit"atsmerkmale sind schriftlich zu fixieren.

\item 
Auch vorl"aufige Entwicklungsziele sind genau festzulegen.

\item 
Zwischenzeitliche "Anderungen am Pflichtenheft m"ussen m"oglich sein,
jedoch nach einem geregelten Verfahren.

\item 
Wichtige Qualit"atskriterien (siehe oben) m"ussen schriftlich spezifiziert werden.

\EI

\EIB

\subsubsection{Es fehlen eindeutige Begriffsdefinitionen}
\BIB

\item Ursachen:

\BI
\item
Dem Entwickler erscheinen ''seine'' Begriffsdefinitionen eindeutig und auch 
f"ur andere Mitarbeiter und den Anwender unmittelbar einleuchtend. 
Er "ubersieht dabei die in der Regel unterschiedlichen
Sichtweisen und Denkmuster der Anwender und Entwickler. 
\EI

\item Folgen:

\BI
\item 
Erstellen nutzloser Software. Falsch verstandene Sachverhalte f"uhren zu 
Mi"sverst"andnissen und Fehlentwicklungen, was oftmals erst bei der 
Programmabnahme deutlich wird.

\item 
Destruktive Diskussionen. Unterschiedliche Vorstellungen der Diskussionspartner
"uber den Diskussionsgegenstand k"onnen zu ergebnislosen Diskussionen, 
oder was noch schlimmer ist, zu weiteren Fehlentscheidungen f"uhren.

\EI

\item Ma"snahmen:

\BI
\item 
Erstellen eines Begriffs-Lexikons, in dem alle verwendeten Fachbegriffe 
definiert werden. Die Entwickler m"ussen ihre Arbeit mehr unter dem 
Gesichtspunkt einer Dienstleistung sehen. Sie sollten sich daher bem"uhen die 
''Sprache'' der Anwender zu sprechen und Begriffe solange zu hinterfragen,
bis alle m"oglichen Mi"sverst"andnisse ausger"aumt sind. 

\item 
Benutzen strukturierter oder objektorientierter Methoden. Dies bietet den 
enormen Vorteil, da"s Begriffe, Strukturen und Abl"aufe, die im Rahmen der 
Problemanalyse erarbeitet werden, nahezu ohne Informationsverlust f"ur 
den Systementwurf und sogar die Codierung weiterverwendet werden k"onnen.

\item 
Vorstellen und Diskutieren von Zwischenergebnissen, sowie gemeinsames
Erstellen von Spezifikationen.

\EI

\EIB
 
\subsection{Systementwurf}
Der Schritt von der Analyse zur Codierung - die Entwurfsphase - besch"aftigt 
sich haupts"achlich mit folgenden Teilproblemen:

\BIB
\item 
Sofern noch keine Festlegungen bez"uglich der einzusetzenden Hard- und Software 
getroffen wurden, sind diese auszuw"ahlen. 

\item 
Der Funktionsumfang ist zu gliedern und Datenstrukturen sind zu definieren. 

\item 
Die Schnittstellen (Datenschnittstellen, Benutzeroberfl"ache) m"ussen beschrieben werden. 

\item 
Die Managementfunktionalit"aten (z.B. Zugriff auf Ressourcen/Daten, 
Priorit"aten im Ablauf, Proze"ssteuerung) sind zu planen. 
\EIB

Weiter zu beachtende Aspekte sind die Wartungsfreundlichkeit, 
eine eventuelle Wiederverwendbarkeit 
sowie die Datensicherheit der zu entwickelnden Software. Nach Sch"atzungen
betr"agt der Anteil der Wartungskosten etwa 70\% der gesamten Entwicklungskosten.

\subsubsection{Die Systemarchitektur ist gar nicht oder nur mit gro"sem Aufwand erweiterbar}

\BIB

\item Ursachen:

\BI
\item  
Die Gegebenheiten f"ur den Einsatz (Nutzungs-/Lebensdauer, Wiederverwendbarkeit, 
Ausweitung des Einsatzes der Applikation) werden nicht richtig eingesch"atzt. 

\item  
Die Offenheit bei der Verwendung unterschiedlicher Plattformen (Hardware, 
Standardsoftware) wird nicht ber"ucksichtigt.

\item  
H"aufig fehlt eine kritische Bewertung des Systementwurfs.

\item  
Es werden keine Entwurfsvarianten vorgeschlagen und diskutiert.

\EI

\item Folgen:
\BI
\item  
Die Systemarchitektur ist un"ubersichtlich, was bei "Anderungen ein 
Hauptproblem werden kann.

\item  
F"ur Tests entsteht ein erh"ohter Aufwand. 

\item  
Die Fehlersuche wird erheblich erschwert.

\item  
Monolithische Architekturen/Systeme bilden ung"unstige Voraussetzungen 
bez"uglich der Pflege und Erweiterbarkeit.

\EI

\item Ma"snahmen:
\BI
\item 
Der Einsatz objektorientierter Methoden und Techniken kann eine 
"ubersichtlichere Architektur liefern. 

\item 
Kleinere Programmbausteine lassen neben einer schnelleren Entwicklung auch 
eine einfachere Fehlerlokalisierung zu.

\item 
Das Verfeinern des Entwurfs (''vom Groben zum Feinen'') wird durch einen 
objektorientierten Ansatz einfacher, da Detaillierungen und Erg"anzungen -- 
basierend auf bereits existierenden Klassen -- m"oglich sind.

\item 
Ein aktueller Ansatz zur Unterst"utzung der Designphase ist die Nutzung von 
Software-Entwurfsmustern: Neben der Problembeschreibung und
dem verallgemeinerten Implementierungsproblem wird auch eine Anleitung zum Implementieren gegeben. 
Durch die Verwendung bew"ahrter L"osungen lassen sich Fehler vermeiden. 
Verschiedene Unternehmen berichten von einem Anteil der Wiederverwendbarkeit 
von bis zu ca. 80\%, wenn objektorientierte Methoden und Techniken in Design und 
Implementierung eingesetzt werden \cite{martin}.

\EI

\EIB


\subsubsection{Das System ist nicht modular aufgebaut, die Daten sind nicht gekapselt}
 
\BIB

\item Ursachen:

\BI
\item 
Oft sind die endg"ultigen Anforderungen zu Beginn einer Entwicklung noch 
nicht vollst"andig definiert oder sie werden im Laufe einer Entwicklung 
modifiziert. 

\item 
Fehlende Kenntnisse oder unzureichende F"ahigkeiten der Entwickler im Umgang 
mit entsprechenden Techniken und Werkzeugen aufgrund fehlender Schulung 
sind weitere Fehlerpotentiale.
 
\EI

\item Folgen:
\BI
\item 
Ein schnelles Entwickeln (Rapid Prototyping) ist nicht m"oglich.

\item 
Die Wartung von Systemen wird durch teilweise schwer durchschaubare 
Abh"angigkeiten beeintr"achtigt.

\item 
Daten(strukturen) sind nicht ausreichend gesch"utzt, z.B. vor Mi"sbrauch, 
ungewolltem Gebrauch, Verf"alschung.
\EI

\item Ma"snahmen:

\BI
\item 
Die Kenntnis und Anwendung entsprechender Methoden und Techniken 
(u.a. Objektorientierung) unterst"utzen sowohl eine Modularisierung 
als auch eine Kapselung. Die jeweiligen Entwickler m"ussen nat"urlich
die daf"ur notwendigen Qualifikationen besitzen.

\item 
Die Entwicklung eines ad"aquaten Modul- und Datenkonzepts schafft auch f"ur 
die Implementierung g"unstige Voraussetzungen.

\item 
Zum Abschlu"s der Entwurfsphase ist eine Verifizierung des Modells durch 
die an der Entwicklung Beteiligten hinsichtlich Vollst"andigkeit und 
Eindeutigkeit (Klarheit) durchzuf"uhren.
\EI

\EIB


\subsection{Codierung}
Die Codierung ist die Umsetzung des Systementwurfs in durch den Rechner
interpretierbare ''Objekte'', z.B. Programme, Module, Makros usw., also in auf dem
Computer lauff"ahigen Code. Man erwartet, da"s alle wesentlichen technischen
Entscheidungen bereits im Systementwurf festgelegt worden sind, so da"s
die Implementierung weitgehend mechanisch aus dem Systementwurf herleitbar
ist. Die einzelnen Programmodule sollen am Schlu"s dieser Phase in codierter, 
dokumentierter und getesteter Form vorliegen. Die Fehler, die in dieser Phase 
entstehen, f"uhren zu un"ubersichtlichen Programmen, die keiner warten m"ochte.

\subsubsection{Programmier-Standards bzw. -Richt\-linien werden nicht beachtet}
\BIB

\item Ursachen

\BI
\item Der Sinn von Standards und die damit verbundenen Vorteile sind den 
      Entwicklern nicht klar.
\item Die existierenden Standards sind nicht praxisgerecht und werden deshalb 
      nicht akzeptiert.
\item Es gibt zuviele Standards und Richtlinien. Damit werden sinnvolle 
      Standards durch "uberfl"ussige Regelungen ''verdeckt''.
\item Es existieren gar keine Standards.
\EI

\item Folgen

\BI
\item Die Programme sind schwer zu lesen.
\item Die Wiederverwendung der Software wird erschwert.
\item Bestimmte Mechanismen und Ma"snahmen zur Fehlervermeidung, die durch 
      die Standards und  Richtlinien implementiert werden, kommen nicht zur 
      Wirkung.
\item Die Portierung auf andere Hardware-Plattfor\-men f"uhrt zu kostspieligen 
      Wartungsarbeiten.
\item Eine uneinheitliche und nicht konsistente Benutzerschnittstelle f"uhrt zu
      einer Belastung der Anwender; die Akzeptanz des Programmes schwindet.
\item Die Weiterbearbeitung der Programme durch andere Entwickler wird erschwert.
\EI

\item Ma"snahmen

\BI
\item Die Entwickler m"ussen "uber die Ziele, die mit der Einf"uhrung von Standards
      und Richtlinien verfolgt werden, ausreichend informiert werden. Eine Einbeziehung
      der Mitarbeiter bei der Erstellung solcher Richtlinien erh"oht die Akzeptanz.

\item Bei jeder Erweiterung von Richtlinien oder Standards sollten die bisherigen
      erneut auf ihre Notwendigkeit "uberpr"uft werden. Auch hierbei ist die
      Einbeziehung der Mitarbeiter sinnvoll.

\item Die Einhaltung von Standards mu"s durch ein geeignetes Gremium kontrolliert
      werden. Dieses sollte nur Mitarbeiter umfassen, die nicht bei der Erstellung
      der Programme involviert waren.
\EI
\EIB

\subsubsection{Die Namensvergabe ist ung"unstig}
\BIB

\item Ursachen

\BI
\item Es existieren keine sinnvollen und verbindlichen Regeln.
\item Die verwendete Programmiersprache erlaubt nur eine eingeschr"ankte 
      Namensl"ange.
\item Nur der Entwickler wei"s, was seine Abk"urzungen bedeuten
      (z.B. SNEB = Suchen nach erstem Blank).
\EI

%>>>>>
%\newpage
\item Folgen

\BI
\item Namen sind oft nur f"ur den ''Erfinder'' aussagekr"aftig und informativ, 
      f"ur andere Mitarbeiter enth"alt der Name keine sofort erkennbare 
      Information.
\item Die Einarbeitung neuer Mitarbeiter wird erschwert.
\item Der Wartungsaufwand wird erh"oht.
\EI

\item Ma"snahmen

\BI
\item Zur problemad"aquaten Charakterisierung von Typen, Konstanten, 
      Variablen, Prozeduren usw. sollten Namen gew"ahlt werden, die die 
      Funktion dieser Gr"o"se bzw. ihre Aufgabe zum Ausdruck bringen. 
      Es sollten Namen vermieden werden, die problemfrei sind oder 
      technische Aspekte, z.B. der Repr"asentation bezeichnen.
\item Die Langform des Namens mu"s als Kommentar angeben werden, wenn mit 
      Programmiersprachen gearbeitet wird, die nur eine eingeschr"ankte 
      Namensl"ange erlauben.
\item Es m"ussen eigene Richtlinien f"ur die Namensvergabe definiert werden,
      damit alle gezwungen sind, lesbar zu programmieren. Einheitlichkeit erh"oht
      die Lesbarkeit, das mu"s jedem klar sein!
\EI
\EIB

\subsection{Betrieb und Wartung}
Auch f"ur die Zeit nach der Auslieferung von Software an Kunden m"ussen geeignete
Ma"snahmen getroffen werden, um die Anforderungen immer komplexerer
Software-Produkte zu beherrschen.

Dem Anwender m"ussen Zugang zum Produkt und dessen M"oglichkeiten und Vorteile
transparent gemacht werden. Dies erreicht man i.d.R. durch entsprechende
Dokumentation und Schulungen.

Die Entwickler m"ussen darauf vorbereitet sein, u.U. Software-Versionen mit
unterschiedlichen Leistungsmerkmalen bereitzustellen, bzw. "altere Software-Versionen
weiterzupflegen. Zudem mu"s zu jeder Software-Version die richtige Dokumentation zur
Verf"ugung stehen. Hierzu bedarf es eines geeigneten \KM-Sy\-stems.
 
\subsubsection{Die Dokumentation fehlt ganz, ist veraltet oder nicht ad"aquat}
\BIB

\item Ursachen:

\BI
\item
Fehlendes Problembewu"stsein bei Mitarbeitern und Verantwortlichen:
Dokumentation ist ohne Stellenwert, sie wird als Luxus angesehen.

\item
Dokumentation hat keinen Einflu"s auf den Gehalt eines Programms.
Dies gilt insbesondere f"ur programminterne Kommentare.

\item
''Geniale'' Programmierer halten sich nicht mit dem Schreiben von
Dokumentation auf.

\item
Das Schreiben von Dokumentation ist l"astig, insbesondere bei Termindruck. 
Deshalb wird Dokumentation h"aufig auf das Notwendigste reduziert und es
entstehen Alibi-Dokumente, die niemandem n"utzen, jedoch den Formalismus
befriedigen.

\item
Die Software wird ge"andert, aber die entsprechende Dokumentation, vor allem
programminterne Kommentare, wird nicht aktualisiert.
\EI

\item Folgen:

\BI
\item 
Entwicklungsentscheidungen k"onnen nur nachvollzogen werden, wenn das
Entscheidungsumfeld dokumentiert ist.

\item 
Schon einmal getroffene Entwicklungsentscheidungen m"ussen    
wieder neu erarbeitet werden, falls sie nicht mit den Gr"unden, die zu   
der Entscheidung f"uhrten, dokumentiert werden.

\item 
Das "Andern oder Weiterentwickeln von Software ger"at langwierig     
und fehlertr"achtig, wenn Programme und Schnittstellen nur   
unzureichend beschrieben sind.                               
Dies gilt insbesondere, wenn die urspr"ungliche Entwicklungsmannschaft
nicht mehr vollst"andig zur Verf"ugung steht.

\item 
Der Leistungsumfang von Software ist f"ur den Anwender   
nicht voll "uberschaubar, wenn die Leistungsmerkmale nicht komplett      
oder eindeutig beschrieben sind. Dies kann zu unn"otigen Zeitverlusten       
beim Einarbeiten, Frustration bei den Anwendern und Vertrauensverlust 
in die Software-Entwickler f"uhren. 

\item 
Au"serdem m"ussen vorhandene, aber unerkannte Leistungsmerkmale m"oglicherweise 
durch Zukaufen oder zus"atzliches Entwickeln von Software abgedeckt werden.
\EI

\item Ma"snahmen:

\BI
\item 
Die Projektverantwortlichen m"ussen den Mitarbeitern die Folgen fehlender oder
mangelhafter Dokumentation vor Augen halten und so das Problembewu"stsein f"ordern.

\item 
F"ur jede Software mu"s ein zugeh"origer Satz von Dokumenten definiert werden.

\item 
Jedes Dokument mu"s Minimalanforderungen erf"ullen, z.B. eine spezifische,
vordefinierte Kapitelstruktur enthalten.

\item 
Ein Dokumentations-Verantwortlicher mu"s f"ur alle Unterlagen sein Einverst"andnis    
geben.
\EI

\EIB




\subsubsection{Die Schulung der Anwender wird vernachl"assigt}

\BIB

\item Ursachen:

\BI
\item 
Training-on-the-job gilt als ausreichend f"ur ''gute'' Leute. Deshalb werden
Schulungen von Anwenderseite nicht energisch genug gefordert.

\item 
Der Lernumfang f"ur den Anwender wird vom Entwickler als zu klein
eingesch"atzt, um daf"ur eine Schulungsma"snahme vorzusehen.

\item 
Zeit oder Kosten f"ur eine Schulung sollen eingespart werden.

\EI

\item Folgen:

\BI
\item 
Methoden werden nicht richtig eingesetzt und bringen das erwartete Ergebnis
deshalb gar nicht oder erst nach Ablauf der geplanten Zeit.

\item 
Das Einarbeiten in neue Software-Werkzeuge, bzw. Anwendungsprogramme
ist langwierig und manche Leistungsmerkmale bleiben unentdeckt.       
Die daraus resultierende Frustration der Anwender kann zum    
Imageverlust der Software-Entwicklungsabteilung f"uhren.

\item 
Frustrierte Anwender z"ogern mit dem Erteilen weiterer Auftr"age; 
es wird lieber Software gekauft, bzw. woanders in Auftrag gegeben.

\item
Die durch das Unterlassen der Schulung eingesparte Zeit      
wird sp"ater durch Fehlbedienungen oder Ineffizienz mehrfach an anderer         
Stelle verbraucht. 

\item
Die Anwender-Schulung erfolgt zum falschen Zeitpunkt,
zu fr"uh: Informationsverlust beim Anwender, weil er Lerninhalte wieder 
vergi"st; zu sp"at: verlorene Zeit bei vorherigem Selbststudium.

\item
Die Ber"uhrungs"angste mit neuen Dingen mancher Anwender werden be\-st"atigt                                             
und f"uhren so zu l"angerem Verharren in alten Positionen.
\EI

\item Ma"snahmen:

\BI
\item 
Projektverantwortliche m"ussen Schulungsma"snahmen mit Zeitpunkt und                         
Umfang (wenn m"oglich: im Gespr"ach mit Anwendern) einplanen.

\item 
Wirtschaftliche Folgen unterlassener Schulungen unter        
ganzheitlichem Blickwinkel darlegen. Letztendlich leiden auch die           
Software-Entwicklungs\-abteilungen, wenn deren Budget bei Schulungen 
geschont wird, das gesparte Geld aber an anderer Stelle mehrfach ausgegeben 
werden mu"s.

\item 
Die Vorteile der Neuerungen m"ussen transparent gemacht werden, um die                                               
Motivation der Anwender zur Innovation zu erh"ohen.
\EI

\EIB


\subsubsection{Das \KM\ ist unzureichend}

\BIB

\item Ursachen:

\BI
\item 
Termindruck: in der Eile gibt man sich damit zufrieden, alles im Kopf zu                             
haben.

\item 
Das Untersch"atzen des Nutzerkreises, der Lebensdauer oder      
des Umfanges der zu entwickelnden Software. Vermeintlich wenige Nutzer,
Interimsl"osungen oder kleine Programme lassen ein Programm gef"uhlsm"a"sig 
leichter beherrschbar erscheinen. Deshalb wird das etwas aufwendigere 
Konfigurieren mit gutem Gewissen unterlassen.

\item 
Das Untersch"atzen der Personalfluktuation: man ist der Ansicht, die jeweiligen                                      
Experten immer verf"ugbar zu haben.
\EI

\item Folgen:

\BI
\item 
Das Altern der Software wird wegen des fehlenden "Uberblickes beschleunigt.
Mit der Zeit erf"ahrt fast jedes Programm "Anderungen, die zu Beginn nicht                                              
vorhersehbar waren und somit meist ''irgendwie'' in die bestehende 
Programmstruktur eingebracht werden.

\item 
Ohne ein klares Konfigurationsmanagement                                     
verliert man schnell die Kontrolle, welcher Kunde welche     
Module in welcher Version ausgeliefert bekam.

\item 
Die ausgelieferte Software neigt zu Fehlern, weil alte Module    
verwendet wurden. Entweder wurden die richtigen Module nicht
ber"ucksichtigt oder sogar durch alte Module "uberschrieben.

\item 
Das Pflegen der Software f"uhrt zu ''Verschlimmbesserungen''. Es      
kann passieren, da"s mit Fehlerkorrekturen oder Weiterentwicklungen betraute   
Mitarbeiter veraltete oder als Testversion gedachte Module als die       
aktuell g"ultige  Programmversion ansehen und so Ver"anderungen schaffen, 
die m"oglicherweise mit den tats"achlich g"ultigen Modulen nicht mehr        
korrespondieren. Oder es werden nicht mehr aktuelle Module korrigiert, die    
schon von einer weiteren Person in anderer Weise ver"andert wurden.
Das schlu"sendliche Chaos kann im Extremfall nur durch die    
komplette Neuentwicklung der Software bereinigt werden.
\EI

\item Ma"snahmen:

\BI
\item 
Projektverantwortliche m"ussen das Problembewu"stsein bei allen Beteiligten                      
herbeif"uhren.

\item 
Es m"ussen geeignete Soft"-ware-\KM-Tools       
bereitgestellt werden.

\item 
Es sollten projektbezogen \KM-Ver"-antwortliche                    
ernannt werden, ohne deren Einverst"andnis keine Software ausgeliefert werden   
darf.
\EI

\EIB



\section{Zusammenfassung}

Wie anfangs bereits erw"ahnt, m"ussen viele der beschriebenen Fehler und Probleme
immer in Zusammenhang mit den jeweiligen Unternehmensstrukturen gesehen
werden. Ein allgemeing"ultiges L"osungskonzept gibt es nicht. Vielmehr gilt es, in einer 
Gratwanderung zwischen Reglementierungen und Vorschriften einerseits sowie 
Freir"aumen f"ur die individuelle Kreativit"at andererseits in der Praxis
den besten Mittelweg zu finden. Es bleibt jedoch ein schwieriges Unterfangen,
alle Personen zufriedenzustellen, die an der Software-Entwicklung direkt
und indirekt beteiligt sind: Entwickler, Anwender und Management.


\begin{thebibliography}{[.]}
\bibitem{beims}
Beims, H.D.: Praktisches Software Engineering, Hanser Verlag, 1995

\bibitem{davis}
Davis, A.D.: 201 Principles of Software Development, McGraw-Hill, 1995

\bibitem{demarco}
DeMarco, T.: Software-Projektmanagement, Wolfram's Fachverlag, 1989

\bibitem{denert}
Denert, E.: Software-Engineering, Springer-Verlag, 1992

\bibitem{frick}
Frick, A.: Der Software-Entwicklungsproze"s - Ganzheitliche Sicht, Hanser Verlag, 1995

\bibitem{fruehauf}
Fr"uhauf, K.; Ludewig J.; Sandmayr H.: Software-Projektmanagement und -Qualit"atssicherung,
vdf Verlag der Fachvereine Z"urich, 1988

\bibitem{krueger}
Kr"uger, M.: Pr"ufen von Software -- aber richtig, Elektronik Nr. 24, 1993

\bibitem{martin}
Martin, J.; Odell, J. : Object Oriented Analysis and Design, Prentice Hall 1992

\bibitem{myers}
Myers, Glenford J.: Methodisches Testen von Programmen, 4.Auflage, Oldenbourg, 1991

\bibitem{schaefer}
Sch"afer, S.: Objektorientierte Entwurfsmethoden, Addison-Wesley, 1994

\bibitem{wallmueller}
Wallm"uller, E.: Software-Qualit"atssicherung in der Praxis, Hanser, 1990

\end{thebibliography}

\end{document}

