Entwicklung webbasierter Software in kleinen Unternehmen
Klassische Verfahren und angewendete Methoden
©2004
Diplomarbeit
174 Seiten
Zusammenfassung
Inhaltsangabe:Einleitung:
Kleine Betriebe unterscheiden sich essentiell von Konzernen bei der Höhe des Kapitals, der inneren Struktur und bezüglich der Einheit von Eigentum und unternehmerischer Verantwortung. Es ist zu beobachten, dass eine nicht ausgereifte Organisation in großen Betrieben schneller Probleme aufwirft als in kleinen Betrieben. So wird in vielen kleinen Betrieben Software entwickelt, deren Entstehungsprozess als Ad-hoc-Methode oder Whisky-Syndrom bezeichnet wird. Die Software entsteht mittels einer intuitiven und nicht standardisierten Methode. Besondere Organisationsstrukturen oder -abläufe sind nicht vorhanden oder werden vernachlässigt. Hieraus entstehen Fehler, deren Beseitigung einen erhöhten Aufwand von Ressourcen erfordert. Knappe Ressourcen führen dazu, dass Projekte scheitern.
Kleinere Softwarebetriebe gehen bei der Erstellung von webbasierter Software nicht nach den klassischen Methoden des SE vor. Sie erhoffen sich eine Zeitersparnis. Die Produkte werden aus dem Bauch heraus und ohne Systematiken, die auf wissenschaftlichen Erkenntnissen beruhen, erstellt. Diese Hypothese stellt den Auslöser und die Motivation für diese Arbeit dar. Eine empirische Analyse wird diese Aussage überprüfen.
Die Arbeit besteht aus einer empirischen Untersuchung und der damit verbundenen Auswertung der Ergebnisse. Grundlage der Studie bilden Kleinbetriebe, deren Kernkompetenz das Entwickeln webbasierter Anwendungen mittels der serverseitigen Entwicklungssprache PHP ist. Die Befragung wurde im Oktober 2003 durchgeführt. Grundgesamtheit waren alle Entwickler, die in den PHP-News-Groups in Hamburg, Berlin, Hannover und Köln eingeschrieben sind. Zielsetzung dieser Studie ist aufzuzeigen, inwieweit die Methoden der Softwareentwicklung der Zielgruppe sich von klassischen Methoden und mit welchen Kriterien unterscheiden. Die unterschiedlichen Ausprägungen zum Stand der Softwareentwicklung können Grundlage für praxisorientierte Softwareerstellung sein. Hinweise auf Abweichungen von den angewandten Methoden sind durchaus im statistischen Material enthalten und können Entscheidungshilfe für Unternehmen sein, die Softwareentwicklung beauftragen und einen geeigneten Softwareentwickler auswählen wollen.
Inhaltsverzeichnis:Inhaltsverzeichnis:
InhaltsverzeichnisI
AbbildungsverzeichnisIII
Chart-VerzeichnisIV
TabellenverzeichnisV
AbkürzungsverzeichnisVII
1.Einführung1
1.1Problemstellung1
1.2Zielsetzung2
2.Grundlagen der […]
Kleine Betriebe unterscheiden sich essentiell von Konzernen bei der Höhe des Kapitals, der inneren Struktur und bezüglich der Einheit von Eigentum und unternehmerischer Verantwortung. Es ist zu beobachten, dass eine nicht ausgereifte Organisation in großen Betrieben schneller Probleme aufwirft als in kleinen Betrieben. So wird in vielen kleinen Betrieben Software entwickelt, deren Entstehungsprozess als Ad-hoc-Methode oder Whisky-Syndrom bezeichnet wird. Die Software entsteht mittels einer intuitiven und nicht standardisierten Methode. Besondere Organisationsstrukturen oder -abläufe sind nicht vorhanden oder werden vernachlässigt. Hieraus entstehen Fehler, deren Beseitigung einen erhöhten Aufwand von Ressourcen erfordert. Knappe Ressourcen führen dazu, dass Projekte scheitern.
Kleinere Softwarebetriebe gehen bei der Erstellung von webbasierter Software nicht nach den klassischen Methoden des SE vor. Sie erhoffen sich eine Zeitersparnis. Die Produkte werden aus dem Bauch heraus und ohne Systematiken, die auf wissenschaftlichen Erkenntnissen beruhen, erstellt. Diese Hypothese stellt den Auslöser und die Motivation für diese Arbeit dar. Eine empirische Analyse wird diese Aussage überprüfen.
Die Arbeit besteht aus einer empirischen Untersuchung und der damit verbundenen Auswertung der Ergebnisse. Grundlage der Studie bilden Kleinbetriebe, deren Kernkompetenz das Entwickeln webbasierter Anwendungen mittels der serverseitigen Entwicklungssprache PHP ist. Die Befragung wurde im Oktober 2003 durchgeführt. Grundgesamtheit waren alle Entwickler, die in den PHP-News-Groups in Hamburg, Berlin, Hannover und Köln eingeschrieben sind. Zielsetzung dieser Studie ist aufzuzeigen, inwieweit die Methoden der Softwareentwicklung der Zielgruppe sich von klassischen Methoden und mit welchen Kriterien unterscheiden. Die unterschiedlichen Ausprägungen zum Stand der Softwareentwicklung können Grundlage für praxisorientierte Softwareerstellung sein. Hinweise auf Abweichungen von den angewandten Methoden sind durchaus im statistischen Material enthalten und können Entscheidungshilfe für Unternehmen sein, die Softwareentwicklung beauftragen und einen geeigneten Softwareentwickler auswählen wollen.
Inhaltsverzeichnis:Inhaltsverzeichnis:
InhaltsverzeichnisI
AbbildungsverzeichnisIII
Chart-VerzeichnisIV
TabellenverzeichnisV
AbkürzungsverzeichnisVII
1.Einführung1
1.1Problemstellung1
1.2Zielsetzung2
2.Grundlagen der […]
Leseprobe
Inhaltsverzeichnis
ID 7907
Behnk, Friedrich: Entwicklung webbasierter Software in kleinen Unternehmen -
Klassische Verfahren und angewendete Methoden
Hamburg: Diplomica GmbH, 2004
Zugl.: Fachhochschule Flensburg, Fachhochschule, Diplomarbeit, 2004
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2004
Printed in Germany
I
Inhaltsverzeichnis
Inhaltsverzeichnis ...I
Abbildungsverzeichnis...III
Chart-Verzeichnis...IV
Tabellenverzeichnis...V
Abkürzungsverzeichnis...VII
1.
Einführung... 1
1.1.
Problemstellung ... 1
1.2.
Zielsetzung ... 2
2.
Grundlagen der Software-Entwicklung ... 3
2.1.
Software-Engineering ... 4
2.2.
Alternative Vorgehensweisen ... 4
2.2.1.
Extreme-Programming ... 5
2.2.2.
Intuitive Vorgehensweise ... 6
2.3.
Anforderungen der Web-Programmierung ... 7
2.4.
Kleine Unternehmen... 8
2.4.1.
Grundlagen und Arten... 9
2.4.2.
Wirtschaftliche Bedeutung kleiner Unternehmen...10
2.4.3.
Unternehmensspezifische Probleme ...10
3.
Empirische Studie und Interviews ...12
3.1.
Vorgehen...12
3.2.
Gegenstand der Untersuchung und Auswahl der Objekte ...13
3.3.
Fragebogen- und Interviewdesign...13
3.4.
Methodik und Repräsentanz der Stichprobe ...15
3.4.1.
Häufigkeitsverteilung ...15
3.4.2.
Kreuztabellen...15
3.4.3.
Clustering ...16
II
4.
Die Softwareentwicklung...18
4.1.
Gliederung des Softwareprojekts ...20
4.2.
Das Software-Engineering ...21
4.2.1.
Projektdefinition ...24
4.2.2.
Projektplanung ...29
4.2.3.
Projektkontrolle ...37
4.2.4.
Projektabschluss ...44
4.2.5.
Betrieb und Wartung ...46
4.2.6.
Qualitätskriterien...47
4.2.7.
Projektmanagement ...51
5.
Ergebnisse zur Befragung ...54
5.1.
Gliederung der Unternehmensgrößen in Klassen ...54
5.2.
Metafragen zur Unternehmung ...57
5.3.
Projektdefinition...62
5.4.
Projektplanung ...70
5.5.
Projektkontrolle ...77
5.6.
Projekt-Termination...91
5.7.
Betrieb und Wartung ...95
5.8.
Qualität ...100
5.9.
Management ...105
5.10.
Stimmungsbild ...109
5.11.
Clusteranalyse...116
6.
Résumé der Studie ...122
6.1.
Zusammenfassung der Ergebnisse der Untersuchung ...123
6.2.
Schlusswort...125
Literaturverzeichnis...VIII
Bücher...VIII
Skripte ... XII
Internet-Adressen... XIV
Anhang...XVI
Interview... XVI
Fragebogen...XXIV
Charts ... XXV
III
Abbildungsverzeichnis
Abbildung 1
Das System ...19
Abbildung 2
Verlauf des Projektes ...21
Abbildung 3
Unsicherheit der Schätzung ...31
Abbildung 4
Ein allgemeines Modell des Entwurfsprozesses...34
Abbildung 5
Das Wasserfallmodell...39
Abbildung 6
Evolutionäre Entwicklung ...40
Abbildung 7
Inkrementelle Entwicklung ...42
Abbildung 8
Das Boehm'sche Spiralmodell des Softwareprozesses ...43
Abbildung 9
Der Unterhaltsaufwand für eine Software ...47
Abbildung 10
Die Softwarequalitätsmerkmale ...48
Abbildung 11
Kosten der Fehlerbehebung ...50
Abbildung 12
Entdecken der Fehler ...51
Abbildung 13
Einordnung der Diplomarbeit ...126
IV
Chart-Verzeichnis
Chart 1
Mitarbeiter ...55
Chart 2
Mitarbeiterklassen...57
Chart 3
Freie Mitarbeiter ...58
Chart 4
Freelancer ...60
Chart 5
Anteil Analyse ...63
Chart 6
Berater ...64
Chart 7
Lastenheft...65
Chart 8
Pflichtenheft ...66
Chart 9
Projektdefinition nach Lehrbuch ...69
Chart 10
Schriftlicher Entwurf ...71
Chart 11
Anteil Entwurf...73
Chart 12
Prototyp ...74
Chart 13
Projektplanung nach Lehrbuch...76
Chart 14
Vorgehensmodelle Vertraut...77
Chart 15
Vorgehensmodelle Angewandt...79
Chart 16
Anteil Testen ...85
Chart 17
Anteil Dokumentation ...87
Chart 18
Projektkontrolle nach Lehrbuch...90
Chart 19
Erfahrungsdatenbank ...91
Chart 20
Weiterentwicklung ...95
Chart 21
Ziele Qualität und Zeit ...101
Chart 22
Formeller Zeitplan...105
Chart 23
Behinderung durch undurchdachte Software ...109
Chart 24
Gruppenaufteilung ...117
Chart 25
Projekt nach Lehrbuch ...122
V
Tabellenverzeichnis
Tabelle 1
Beschäftigungszahlen insolventer Unternehmen 2002 ...11
Tabelle 2
Irrtumswahrscheinlichkeit und Bedeutung ...16
Tabelle 3
Entwicklungsabschnitte und Phasen ...29
Tabelle 4
Mitarbeiter ...55
Tabelle 5
Klassenzusammensetzung ...56
Tabelle 6
Mitarbeiterklassen...56
Tabelle 7
Freie Mitarbeiter ...58
Tabelle 8
Freier Mitarbeiter x Mitarbeiterklassen...59
Tabelle 9
Freelancer x Mitarbeiterklassen...61
Tabelle 10
Anteil Analyse ...63
Tabelle 11
Begründung kein Pflichtenheft...66
Tabelle 12
Pflichtenheft x Mitarbeiterklassen...67
Tabelle 13
Pflichtenheft x Berater ...67
Tabelle 14
Schätzverfahren...70
Tabelle 15
Entwurfsmethoden ...72
Tabelle 16
Anteil Entwurf...73
Tabelle 17
Entwurf x Pflichtenheft...74
Tabelle 18
Schätzverfahren...78
Tabelle 19
Vorgehensmod. Angewandt x Vorgehensmod. Vertraut ...80
Tabelle 20
Vorgehensmodelle Angewandt...80
Tabelle 21
Wasserfall Angewandt x Wasserfall Vertraut ...81
Tabelle 22
Inkrementell Angewandt x Wasserfall Vertraut ...81
Tabelle 23
Spiral Angewandt x Wasserfall Vertraut ...82
Tabelle 24
Inkrementell Angewandt x Inkrementell Vertraut ...82
Tabelle 25
Wasserfall Angewandt x Inkrementell Vertraut ...82
Tabelle 26
Spiral Angewandt x Spiral Vertraut ...82
Tabelle 27
Vorgehensmodell Vertraut x Berater...83
Tabelle 28
Vorgehensmodell Angewandt x Berater...83
Tabelle 29
Wasserfall Angewandt x Berater ...84
Tabelle 30
Wasserfall Angewandt x Pflichtenheft ...84
Tabelle 31
Anteil Testen ...86
VI
Tabelle 32
Anteil Dokumentation ...87
Tabelle 33
Anteil Dokumentation x Berater...88
Tabelle 34
Erfahrungsdatenbank x Pflichtenheft ...92
Tabelle 35
Erfahrungsdatenbank x Entwurf ...92
Tabelle 36
Erfahrungsdatenbank x Vorgehensmodell Vertraut ...92
Tabelle 37
Erfahrungsdatenbank x Vorgehensmodell Angewandt...93
Tabelle 38
Weiterentwicklung x Anteil Analyse ...96
Tabelle 39
Weiterentwicklung x Berater...96
Tabelle 40
Weiterentwicklung x Entwurf ...97
Tabelle 41
Weiterentwicklung x Vorgehensmodell Vertraut ...97
Tabelle 42
Weiterentwicklung x Vorgehensmodell Angewandt ...98
Tabelle 43
Weiterentwicklung x Anteil Dokumentation...98
Tabelle 44
Ziele Qualität und Zeit ...101
Tabelle 45
Ziele Qualitaet und Zeit x Vorgehensmodell Angewandt ...102
Tabelle 46
Ziele Qualität und Zeit x Inkrementell Angewandt ...102
Tabelle 47
Ziele Qualität und Zeit x Erfahrungsdatenbank ...103
Tabelle 48
Ziele Qualität und Zeit x Weiterentwicklung ...103
Tabelle 49
Formeller Zeitplan x Berater ...106
Tabelle 50
Formeller Zeitplan x Pflichtenheft ...106
Tabelle 51
Formeller Zeitplan x Vorgehensmodell Vertraut ...107
Tabelle 52
Formeller Zeitplan x Vorgehensmodell Angewandt...107
Tabelle 53
Unmut SW-Architektur x Aufford. zur Weiterentwicklung ...110
Tabelle 54
Unmut Softwarearchitektur x Berater...111
Tabelle 55
Unmut Softwarearchitektur x Vorgehensmodell Vertraut ...111
Tabelle 56
Unmut Softwarearchitektur x Anteil Dokumentation...112
Tabelle 57
Herausforderung der Softwareentwicklung ...113
Tabelle 58
Vorteile kleinerer Betriebe ...114
Tabelle 59
Nachteile kleinerer Betriebe ...115
Tabelle 60
Gruppenmerkmale ...118
Tabelle 61
Gruppenstärke ...118
Tabelle 62
Vorgehensmodelle Vertraut x Gruppe ...119
Tabelle 63
Vorgehensmodelle Angewandt x Gruppe ...120
Tabelle 64
Inkrementell Angewandt x Gruppe ...120
VII
Abkürzungsverzeichnis
ARPA
Advanced Research Projects Agency
CE
Conformité Européenne
COCOMO
Constructive Cost Modelling
EDB
Elektronische Erfahrungsdatenbank
EDV
Elektronische Datenverarbeitung
HTML
Hypertext Markup Language
HTTP
Hypertext Transfer Protocol
IT
Informationstechnologie
IuK
Informations- und Kommunikationstechnologie
k. A.
keine Angaben
KMU
kleine und mittlere Unternehmen
loc
lines of code
MA
Mitarbeiter
MS
Mile Stones
NATO
North Atlantic Treaty Organization
OSS
Open Source Software
PHP
Hypertext Preprocessor
QM
Qualitätsmanagement
SE
Software-Engineering
SICOMO
Siemens Cost Modelling
UML
Unified Modelling Language
URL
Uniform Resource Identifier
VM
Vorgehensmodelle
XML
eXtensible Markup Language
XP
eXtreme Programming
Friedrich R. Behnk
Einführung
Seite 1
1. Einführung
Kleine Betriebe unterscheiden sich essentiell von Konzernen bei der Höhe
des Kapitals, der inneren Struktur und bezüglich der Einheit von Eigentum
und unternehmerischer Verantwortung.
Es ist zu beobachten, dass eine nicht ausgereifte Organisation in großen
Betrieben schneller Probleme aufwirft als in kleinen Betrieben. So wird in
vielen kleinen Betrieben Software entwickelt, deren Entstehungsprozess als
,,Ad-hoc-Methode"
1
oder ,,Whisky-Syndrom"
2
bezeichnet wird. Die Software
entsteht mittels einer intuitiven und nicht standardisierten Methode.
Besondere Organisationsstrukturen oder -abläufe sind nicht vorhanden oder
werden vernachlässigt. Hieraus entstehen Fehler, deren Beseitigung einen
erhöhten Aufwand von Ressourcen
3
erfordert. Knappe Ressourcen führen
dazu, dass Projekte scheitern.
1.1.
Problemstellung
,,Kleinere Softwarebetriebe gehen bei der Erstellung von webbasierter
Software nicht nach den klassischen Methoden des SE vor. Sie erhoffen sich
eine Zeitersparnis. Die Produkte werden aus dem ,,Bauch heraus" und ohne
Systematiken, die auf wissenschaftlichen Erkenntnissen beruhen, erstellt."
Diese Hypothese stellt den Auslöser und die Motivation für diese Arbeit dar.
Eine empirische Analyse wird diese Aussage überprüfen.
1
Vgl. Zenner (2002), S. 1-3.
2
Die Abkürzung Whisky steht für ,,,,Why isn't Sam coding yet!". Es dominiert die
Denkweise, dass schnelles Codieren mit einem raschen und erfolgreichen
Projektabschluss gleichzusetzen ist. Vgl. Schelle (2001), S. 77.
3
Der Begriff Ressourcen steht in diesem Fall für Zeit, Personal und Geld.
Friedrich R. Behnk
Einführung
Seite 2
1.2.
Zielsetzung
Die Arbeit besteht aus einer empirischen Untersuchung und der damit
verbundenen Auswertung der Ergebnisse. Grundlage der Studie bilden
Kleinbetriebe
4
, deren Kernkompetenz das Entwickeln webbasierter
Anwendungen mittels der serverseitigen Entwicklungssprache PHP ist. Die
Befragung wurde im Oktober 2003 durchgeführt. Grundgesamtheit waren alle
Entwickler, die in den ,,PHP-News-Groups" in Hamburg, Berlin, Hannover
und Köln eingeschrieben sind.
Zielsetzung dieser Studie ist aufzuzeigen, inwieweit die Methoden der
Softwareentwicklung der Zielgruppe sich von klassischen Methoden und mit
welchen Kriterien unterscheiden. Die unterschiedlichen Ausprägungen zum
Stand der Softwareentwicklung können Grundlage für praxisorientierte
Softwareerstellung sein. Hinweise auf Abweichungen von den angewandten
Methoden sind durchaus im statistischen Material enthalten und können
Entscheidungshilfe für Unternehmen sein, die Softwareentwicklung
beauftragen und einen geeigneten Softwareentwickler auswählen wollen.
4
Als Kleinbetriebe werden in dieser Arbeit Unternehmen bezeichnet, deren
Mitarbeiterstärke nicht mehr als 25 Personen beträgt.
Friedrich R. Behnk
Grundlagen der Software-Entwicklung
Seite 3
2. Grundlagen der Software-Entwicklung
Der Bedarf Software zu erstellen entstand mit der Entwicklung der ersten
Rechenanlagen. Ursprünglich waren Computer nur für wissenschaftliche,
militärische und technische Disziplinen entwickelt worden. Software-Pioniere
waren gedanklich noch weit entfernt von den heutigen Entwicklern.
Algorithmen und Programme waren weniger komplex als die heutigen.
Programmierer waren zugleich Benutzer der Programme.
5
Die Situation
erforderte noch keine komplexen Software-Entstehungs-Prozesse. Das
Hauptaugenmerk galt der Korrektheit der Ergebnisse, die die Anwendungen
liefern mussten. Mit Zunahme der Leistungsfähigkeit von Hardware wuchsen
die Ansprüche an Software. Die Aufgabenstellungen wurden deutlich
komplexer in ihren wissenschaftlichen, militärischen, technischen und
zunehmend kommerzielleren Anforderungen. Durch die zwangsläufig
mangelnde Erfahrung in der systematischen Software-Entwicklung kam es
zu erheblichen Schwierigkeiten. Trotz steigender Komplexität mussten
Zuverlässigkeit und Sicherheit gewährleistet bleiben - die Programme
zusätzlich flexibel werden. Daneben sollte die Dokumentation und
Wartbarkeit der Software sichergestellt werden.
6
Mit der bis dato intuitiven
Vorgehensweise ließen sich die neuen Probleme nicht bewältigen. Diese
Situation verschärfte sich 1965 so dramatisch, dass sich zu dieser Zeit der
Begriff der ,,Softwarekrise"
7
etablierte.
Im Jahr 1968 wurde zum ersten Mal der Begriff ,,Software-Engineering"
8
auf
der von der NATO veranstalteten ,,Software-Engineering-Konferenz"
9
in
Garmisch ins Leben gerufen. Die Forderung nach einer Weiterentwicklung,
5
Vgl. Pomberger, Blaschek (1992), S. 1.
6
Vgl. Ebenda.
7
Ebenda.
8
Sommerville (2001), S. 19.
9
Pomberger, Blaschek (1992), S. 1.
Friedrich R. Behnk
Grundlagen der Software-Entwicklung
Seite 4
ausgehend von der ,,Kunst der Softwareherstellung" hin zum industriellen
Prozess, verbunden mit einer systematischen Vorgehensweise, wurde laut.
Die Geburtsstunde des Software-Engineering war gekommen.
Heute ist eines der primären Ziele, die Dauer der Produktentwicklung bis zur
Marktreife bzw. Auslieferung möglichst klein zu halten
10
. Diese Anforderung
setzt besonders aus finanziellen Gründen kleinere Betriebe im Vergleich zu
großen Unternehmen unter starken Druck. Es wird kontinuierlich nach neuen
und effizienteren Methoden gesucht, zumal der ,,Königsweg"
11
noch nicht
gefunden wurde.
2.1.
Software-Engineering
,,SE ist die Anwendung wissenschaftlicher Erkenntnisse mit dem Ziel,
Computer mittels Programm, Verfahren und zugehörigen Dokumenten dem
Menschen nutzbar zu machen."
12
,,Das SE ist eine technische Disziplin, die
sich mit allen Aspekten der Softwareerstellung beschäftigt, von den frühen
Phasen der Systemspezifikation bis hin zur Wartung des Systems, nachdem
sein Betrieb aufgenommen wurde."
13
SE steht somit für ein ingenieurmäßiges
Vorgehen, welches auf wissenschaftlichen Erkenntnissen beruht. Das Projekt
wird in seine einzelne Phasen zerlegt. Die Software wird einem definierten
Vorgehen folgend erstellt.
2.2.
Alternative Vorgehensweisen
Die bekanntesten Alternativen zum SE sind das ,,Extreme-Programming" und
ein ,,intuitives Vorgehen", auf die im Folgenden eingegangen wird.
10
Vgl. Sommerville (2001), S. 204.
11
Sommerville (2001), S. 19.
12
Denert (1991), S. 13.
13
Sommerville (2001), S. 22.
Friedrich R. Behnk
Grundlagen der Software-Entwicklung
Seite 5
2.2.1. Extreme-Programming
,,Extreme-Programming"
14
,XP, wird zur Zeit leidenschaftlich zwischen
Software-Ingenieuren und Entwicklern diskutiert, die auf der Suche nach
,,unkonventionelleren" Methoden sind. Kent Beck hat das Vorgehen des XP
Ende der 90er Jahre publiziert. Das XP geht, wie auch das SE, davon aus,
dass das Erstellen einer Software ein kreativer Prozess ist.
15
,,Keine der
eingesetzten Praktiken ist wirklich neu; neu ist die Kombination und der
,,extreme" Grad, in dem diese Praktiken eingesetzt werden."
16
Grundlegend
ist davon auszugehen, dass sich in dem dynamischen Prozess der Software-
Entwicklung die Anforderungen stetig ändern. Dieser Zustand, die
dynamische Komplexität, wird als störend empfunden. Mittels Formalisierung
und einer Intensivierung der weiteren Planung werden dieser Komplexität
,,Fesseln" angelegt, um sie zu bewältigen.
17
XP empfindet diesen Zustand
nicht als störend. Diese Eigenschaft wird bewusst genutzt, um agiler auf die
Problematik einzugehen. Beck vergleicht die Softwareentwicklung mit dem
Autofahren: Veränderungen werden wahrgenommen und durch rasche kleine
Lenkbewegungen wird das Auto auf der Straße gehalten. Als Beispiel dient
die Metapher des Regenschauers, um eine möglichst klare Sicht zu
behalten, werden intuitiv die Scheibenwischer eingeschaltet.
18
Diese Aktion
kann nicht im Vorfeld geplant werden, da der genaue Zeitpunkt des
einsetzenden Regens unbekannt ist. Analog hierzu kann das Auftreten von
unvorhergesehenen Problematiken im Softwareprojekt betrachtet werden.
14
Lippert, Roock, Wolf (2002), S. 1 bis 21.
15
Vgl. Coldewey, Poppendieck (2002), S. 1 bis 5, siehe hierzu auch Schmidt-Setzwein,
Harbeck (2002), S. 1 bis 5.
16
Siehe hierzu
http://www.gi-ev.de/informatik/lexikon
(10.2003).
17
Vgl. Schmidt-Setzwein, Harbeck (2002), S. 1 bis 5.
18
Vgl. Ebenda.
Friedrich R. Behnk
Grundlagen der Software-Entwicklung
Seite 6
Das XP besitzt folgende elementare Unterschiede zum SE:
19
1. Sehr kurze Releases, max. 1 bis 3 Monate.
2. Planungsspiel: Der Kunde wird intensiver in das Projekt involviert.
3. Tests: Der Kunde entwickelt Testfälle, die von einem Entwickler noch
vor der Implementierung des Programms umgesetzt werden. Die
Testfälle laufen automatisch.
4. Einfacher Entwurf: Aufgrund der sich dynamisch ändernden
Umgebung wird der Entwurf möglichst einfach gehalten und Zug um
Zug angepasst.
5. Programmieren in Paaren: Zwei Personen teilen sich einen Computer
und entwickeln gemeinsam.
6. Kontinuierliche Code-Integration: Nach der Fertigstellung eines
Programmstückes wird dieses dem gesamten Programm hinzugefügt.
Automatische Testläufe bestätigen die Funktion. Auf diese Weise
existiert zu jeder Zeit ein lauffähiges Programm.
2.2.2. Intuitive Vorgehensweise
Die Ad-hoc-Methode sollte bei Software-Projekten nicht zur Diskussion
stehen, da jegliche systematische Vorplanung fehlt.
20
Das Problem ist
gegeben und der ,,Programmierer" versucht, sich der Lösung zu nähern,
indem er unverzüglich seine Gedanken in ein Programm umsetzt. Bei sehr
kleinen Projekten kann diese Methodik durchaus effektiv sein. Erreicht das
Produkt einen bestimmten Umfang oder muss es weiter entwickelt werden,
zeigen sich die Nachteile einer fehlenden Strukturierung und mangelnder
Dokumentation. Im Extremfall ist die Weiterentwicklung des Programms nicht
mehr effizient, so dass die Software neu programmiert werden muss.
19
Siehe hierzu
http://www.gi-ev.de/informatik/lexikon
(10.2003).
20
Bei kleineren Projekten kann es durchaus ökonomischer sein, eine ausführliche
Analyse und Planungsphase stark zu raffen.
Friedrich R. Behnk
Grundlagen der Software-Entwicklung
Seite 7
2.3.
Anforderungen der Web-Programmierung
Der Gründungsgedanke des Internets geht in die 60er Jahre zurück und ist,
wie so oft bei Neuerungen, militärischen Ursprungs. Ende der 60er Jahre
waren vier Rechner miteinander über eine Datenleitung verbunden. Dieses
Netzwerk wurde ARPA-Net
21
genannt. Innerhalb weniger Jahre stieg die Zahl
der angeschlossenen Rechner stark an. Durch die zusätzliche wissen-
schaftliche Nutzung und dem damit verbundenen Informationsaustausch,
auch im zivilen Bereich, entwickelte sich das ARPA-Net zu dem uns heute
bekannten Internet. Das Militär gründete anfangs der 80er Jahre ein eigenes
Netzwerk, das Milnet.
Zu dem Ursprungsgedanken des reinen Informationsaustausches kam mit
dem zivilen Gebrauch auch die kommerzielle Nutzung des Internets hinzu.
Bei der geschäftlichen Nutzung dieses Mediums kann auf ein zielgerichtetes
Marketing in Verbindung mit einem entsprechendem Design nicht verzichtet
werden. Der emanzipierte Benutzer fordert eine performante
22
Internetpräsenz mit einem ansprechenden und klaren Design
23
und einer
intuitiv verständlichen Navigation. Wird dem User dieses nicht geboten,
verlässt er die Seite mit einer negativen Assoziation.
Die größte Differenz zwischen einem ,,herkömmlichen" Entwicklerteam und
einem Team, welches sich auf das Erstellen von Internetpräsenzen
spezialisiert hat, ist die künstlerische Anforderung. Das Design ist
unumstritten einer der wichtigsten Aspekte. Leider haben viele Firmen die
Wichtigkeit eines kompetenten Designers ,,noch" nicht erkannt. So ist der
folgende Satz: ,,Wir brauchen eine Website, wer kann HTML program-
21
Die Abkürzung "ARPA" steht für "Advanced Research Projects Agency". Vgl. Münz,
http://selfaktuell.teamone.de
(10.2003).
22
Der Begriff ist ein Ausdruck für Geschwindigkeit. In diesem Sinn steht er für einen
schnellen Aufbau der Website.
23
Vgl. Lynch, Horton, Rosdale (1999), S. 27.
Friedrich R. Behnk
Grundlagen der Software-Entwicklung
Seite 8
mieren?"
24
, in der Praxis keine Seltenheit. Das Ergebnis bzw. die Qualität der
Produkte sind entsprechend.
Demnach werden Programmierer für die technische Komponente und
Designer für die künstlerische Komponente benötigt. Erschwerend kommt
hinzu, dass die Ausstattung der Computer heterogen ist. Die Darstellung der
Inhalte erfolgt auf verschiedenen Browsern, eine einheitliche Präsentation ist
somit unmöglich.
25
Leider ist die Existenz von Webseiten, auf denen die
einfachsten journalistischen Regeln
26
nicht befolgt werden, keine Seltenheit.
Zu oft überwiegt die Vorstellung, dass eine hohe Anzahl kontrastreicher
Farben die Attraktivität der Web-Präsenz erhöht.
2.4.
Kleine Unternehmen
Der Begriff ,,Kleines Unternehmen" ist zu definieren. Die Anzahl der
Mitarbeiter und der Umsatz sind zwei Unterscheidungsmerkmale für die
Größe einer Unternehmung. In dieser Ausarbeitung wird der Fokus auf die
Anzahl der Mitarbeiter gelegt, nach der auch die spätere klassenspezifische
Einordnung erfolgt.
Recherchen haben ergeben, dass unterschiedliche Definitionen der
Begrifflichkeit ,,Kleinbetriebe" existieren. So wurde in dem Artikel
,,Insolvenzen in Europa" zwischen dem Begriff Kleinbetriebe und
Mikrobetriebe unterschieden. Kleinbetriebe weisen eine Personalstärke von
10 bis 49 Personen auf, Mikrobetriebe nicht mehr als 9 Mitarbeiter.
27
24
Lankau (2000), S. 5.
25
Vgl. Kübler (1999), S. 2.
26
Die einfachste journalistische Regel fragt nach dem ,,wer, was, wann und wo". Vgl.
Lynch, Horton, Rosdale (1999), S. 22.
27
Vgl. Bertz (2003), S. 15.
Friedrich R. Behnk
Grundlagen der Software-Entwicklung
Seite 9
2.4.1. Grundlagen und Arten
Die Beschreibung von Kleinbetrieben und Mikrobetrieben ist eng mit der
Erklärungen für den Schritt in die Selbstständigkeit verknüpft. Die Gründe
reichen von der ,,Inspiration durch Arbeitslosigkeit" bis zu ,,ideologischen
Motivationen". Eine detaillierte Erörterung dieser Motivationen ist eher in der
Soziologie als in der Wirtschaftslehre zu finden. Sie werden im weiteren
Verlauf dieser Ausarbeitung nicht näher erörtert.
Grundlegend existieren drei Arten von Existenzgründungen, aus denen
Kleinbetriebe hervorgehen.
28
1. Der ,,Craftsman"
2. Der ,,Manager-Opportunist"
3. Der ,,Freelancer" (Im Sektor Dienstleistung)
Der Craftsman besitzt in der Regel keine akademische Ausbildung und
Führungserfahrung. Die Gründung einer Firma erfolgt spontan oder aus einer
Notlage heraus. Das benötigte Kapital besteht zum Teil aus Ersparnissen
und finanzieller Unterstützung von Seiten des Verwandten- oder
Bekanntenkreises. Markant für diese Art von Unternehmung ist ein geringes
Wachstum.
29
Der ,,Manager-Opportunist" besitzt in der Regel eine akademische
Ausbildung und fokussiert seit längerer Zeit den Schritt in die
Selbstständigkeit. Finanzielle Mittel werden zu einem großen Teil
fremdfinanziert. Typisch ist die wesentlich höhere Risikobereitschaft im
Vergleich zu dem Craftsman. Scheitert die Firma nicht an den Folgen
eingegangener Risiken, kommt es zu einem schnellen Wachstum.
30
28
Vgl. Berger, Domeyer, Funder (1990), S. 71. ff.
29
Vgl. Ebenda.
30
Vgl. Ebenda.
Friedrich R. Behnk
Grundlagen der Software-Entwicklung
Seite 10
Freiberufler
31
sind eigenständige Unternehmer, die ihre Kenntnisse temporär
in den Dienst einer Unternehmung stellen - üblicherweise für die Dauer eines
Projektes. Sie sind in der Regel 1-Mann-Betriebe. Ihre Ausbildung kann,
muss aber nicht zwangsläufig akademischen Ursprungs sein.
2.4.2. Wirtschaftliche Bedeutung kleiner Unternehmen
Auf Westeuropa bezogen, zählen nur 0,3% aller Betriebe mehr als 250
Mitarbeiter.
32
In dem Vortrag ,,Rahmenbedingungen für einen erfolgreichen
IT-Mittelstand" von Thomas Mosch zum Softwaretag 2003 in Berlin wird
aufgezeigt, dass 99,7% der Unternehmen in Deutschland zu den kleinen und
mittleren Unternehmungen, KMU, gehören. Demnach sind annährend 80%
der Erwerbstätigen in Deutschland dem Mittelstand zuzuordnen, die einen
Anteil von 48% an der Bruttowertschöpfung erwirtschaften.
33
Annährend
54.000 Unternehmen haben sich im IT-Bereich angesiedelt. Klein-
unternehmen vertreten mit 42.000 Firmen einen Anteil von 77,7% aller IT-
Unternehmen in Deutschland.
34
2.4.3. Unternehmensspezifische Probleme
Umfragen haben ergeben, dass das vorrangige Ziel eines KMU-Betriebes
der ,,Kampf um den Fortbestand der Unternehmung" ist. Es liegt prozentual
weit vor den Zielen ,,Steigerung der Gewinne"
35
und ,,Innovation". Diese
Tatsache spiegelt den aktuellen Stand der Unternehmensstabilität wider.
Gerade KMU-Betriebe sehen sich mit der Problematik konfrontiert, immer
komplexer werdende gesellschaftliche und wirtschaftliche Auflagen erfüllen
31
Die Begriffe Freiberufler und Freelancer werden in dieser Ausarbeitung synonym
verwendet.
32
Vgl. Bertz (2003), S. 15.
33
Vgl. Mosch (2003), S. 3.
34
Vgl. Mosch (2003), S. 4.
35
Vgl. Berger (1990), S. 80.
Friedrich R. Behnk
Grundlagen der Software-Entwicklung
Seite 11
zu müssen.
36
Um diesen Anforderungen gerecht zu werden, muss der KMU-
Unternehmer ein ,,Generalist höchster Qualität" sein. Neben ausgezeichneter
Kenntnis seines Fachgebietes bedarf es zusätzlicher Fähigkeiten in allen die
Unternehmung betreffenden Bereichen. Er benötigt in diesen Feldern die
Hilfe externer Spezialisten.
37
,,Achillesferse" der beschriebenen Unternehmen ist die Problematik der
Finanzierung und eine schwache Eigenkapitalquote, die zur Zeit in
deutschen Kleinbetrieben bei durchschnittlich 18% liegt.
38
Die schwierige
Situation kleiner Unternehmen veranschaulicht die folgende Übersicht
,,Beschäftigungszahlen insolventer Unternehmen 2002".
Tabelle 1
Beschäftigungszahlen insolventer Unternehmen 2002
Personalstärke
Deutschland
1 5
63,9 %
6 10
14,2 %
11 20
10,5 %
21 50
7,4 %
51 100
2,5 %
> 100
1,6 %
39
36
Vgl. Berger (1990), S. 80.
37
Als Beispiele sein angeführt, die CE-Prüfung, die ISO 9001 Zertifizierung und Qm-
Zertifizierung. Vgl. Burghardt (2002), S. 212 ff.
38
Vgl. Bertz (2003), S. 36.
39
Die Zahl der Insolvenzen der Unternehmen im Jahr 2002 beträgt 150.275. Von
diesem Ergebnis sind bereits die Privatinsolvenzen abgezogen, insgesamt sind 2002
241.000 Insolvenzen zu verzeichnen. Vgl. Bertz (2003), S. 16.
Friedrich R. Behnk
Empirische Studie und Interviews
Seite 12
3. Empirische Studie und Interviews
Sinn einer Untersuchung ist es, eine These wissenschaftlich zu untermauern
oder zu widerlegen. Um ein genaues Abbild der Wirklichkeit zu erhalten,
müsste eine Totalerhebung durchgeführt werden. Im Rahmen dieser Arbeit
kann das allgemeine statistisch richtige Vorgehen nur skizziert werden. Es
werden Untersuchungsverfahren vollständig angewendet, die zuvor
durchgeführte Datenerhebung genügt jedoch nicht einer repräsentativen
Stichprobe aus einer definierten Grundgesamtheit, um eine
verallgemeinerbare Abbildung der Realität zu erhalten.
40
Erreicht wird
trotzdem ein möglichst genaues Abbild mit einer zufälligen Stichprobe, wobei
zu gewährleisten war, dass jede statistische Einheit dieselbe Chance hatte,
in die Stichprobe zu gelangen.
41
3.1.
Vorgehen
Im Vorfeld dieser Untersuchung wurde ein Fragebogen
42
entworfen, der die
Grundlage für zwei unterschiedliche Interviews
43
bildet. Die Software-
beratungshäuser aus Norddeutschland, in denen die Interviews durchgeführt
wurden, haben sich auf die Erstellung von webbasierten Firmenlösungen
spezialisiert und sind seit geraumer Zeit in dieser Branche am Markt etabliert.
In den Interviews wurde das Konzept des Fragebogens bestätigt, so dass die
Befragung mit dem entworfenen Fragebogen durchgeführt werden konnte.
40
Vgl. Kirchhoff, Kuhnt, Lipp, Schlawin, (2000), S. 15.
41
Vgl. Fahrmeir (1997), S. 14.
42
Siehe hierzu Anhang, ,,Fragebogen".
43
Die Interviews wurden in mündlicher Form durchgeführt und protokolliert. Im Anhang
dieser Arbeit befindet sich die Zusammenfassung der zwei Interviews.
Friedrich R. Behnk
Empirische Studie und Interviews
Seite 13
3.2.
Gegenstand der Untersuchung und Auswahl der Objekte
Primäres Ziel dieser angestrebten Untersuchung ist es, die allgemein
angenommene Behauptung, ,,kleine Beriebe entwickeln Software nicht nach
systematischen, methodischen und wissenschaftlichen Vorgehensweisen",
im Detail zu analysieren.
Die Grundgesamtheit, aus der die Stichprobe gezogen wurde, bilden
selbstständige und angestellte Programmierer kleiner Betriebe, die Mitglieder
der PHP-Usergroups in Hamburg, Berlin, Hannover und Köln sind. Sie haben
eine E-Mail mit einer URL erhalten, die auf eine Webseite verlinkt ist und
zum Fragebogen führt. Nach dem Ausfüllen des Fragebogens und mit der
Bestätigung des ,,Send-Buttons" wurden die Inhalte der Variablen des
Fragebogens direkt an einen Formmailer
44
gesendet, der diese in Form einer
E-Mail weiterleitet. Mit dieser Methode wird die Anonymität des Befragten
gewährleistet und die größtmögliche Funktionalität sowie Einfachheit
geboten.
3.3.
Fragebogen- und Interviewdesign
Ein aussagekräftiger Fragebogen zeichnet sich nicht nur durch optische
Aspekte und logisches Vorgehen aus,
45
sondern durch verständliche
Fragestellungen und Vermeidung von suggestiven und stereotypischen
Formulierungen.
46
Der Fragebogen enthält sowohl offene als auch
geschlossene Fragestellungen. Bei verwendeten Skalen wurde darauf
geachtet, dass es keine ,,goldene Mitte"
47
gibt. Aus den Antworten lässt sich
infolgedessen eine eindeutige Tendenz ableiten. Die Erläuterung der
44
Ein Formmailer dient zur Versendung von Emails, die aus HTML-Formularen erzeugt
werden. Vgl.
http://www.formmailer.com
.
45
Logisches Vorgehen wird mit rotem Faden umschrieben. Vgl. Kirchhoff, Kuhnt, Lipp,
Schlawin, (2000), S. 21.
46
Vgl. Kirchhoff, Kuhnt, Lipp, Schlawin, (2000), S. 107.
47
Kirchhoff, Kuhnt, Lipp, Schlawin, (2000), S. 56.
Friedrich R. Behnk
Empirische Studie und Interviews
Seite 14
Stichprobe und des Anlasses zum Thema der Befragung sind wichtige
Punkte, die in dem zugehörigen Anschreiben erörtert wurden. Auch die
Gewährleistung der Anonymität der Befragten wurde zugesichert.
48
Die Untersuchung ist in drei Abschnitte untergliedert. In dem ersten Abschnitt
wird deskriptiv auf das zu befragende Unternehmen eingegangen. Durch die
Angaben des Befragten lässt sich feststellen, ob der Fragebogen in die
Untersuchung mit eingeschlossen wird. Ein Fragebogen wird dann nicht in
der Untersuchung berücksichtigt, wenn die Unternehmung mehr als 25
Mitarbeiter zählt; es sollten nur kleine Unternehmen in der Studie untersucht
werden.
Der zweite Teil der Befragung wird in die einzelnen Schritte des
Projektmanagement
49
, in dem das Vorgehen des SE eingebettet ist,
aufgesplittet:
Die Fragen zur Projektdefinitionsphase sollen aufzeigen, inwieweit die
befragten Personen das Problem analysieren und sich mit der Analyse
auseinandersetzen.
Bei der Projektplanung und dem Entwurf liegt das primäre Interesse auf dem
Kenntnisstand hinsichtlich der in den jeweiligen Unternehmungen geübten
Vorgehensweisen. Dabei wird überprüft, ob die Befragten die in der Literatur
beschriebenen Methoden kennen bzw. in den Unternehmen auch anwenden.
Zum Vorgang der Projektkontrolle gestellte Fragen geben Aufschluss über
die praktische Umsetzung und Steuerung.
48
Vgl. Friedrichs (1985), S. 238.
49
Das Projektmanagement wird aufgeteilt in die Projektdefinition, die Projektplanung, die
Projektkontrolle und die Projekttermination.
Friedrich R. Behnk
Empirische Studie und Interviews
Seite 15
Mit der Projekttermination und der dazugehörigen Frage lässt sich
herausfinden, ob ein System zur Erfahrungssicherung und Verwaltung
existiert.
Der letzte Teil der empirischen Untersuchung bringt Transparenz in die
Erfahrungen der Befragten. Er gibt Aufschluss über die spezifischen
Schwerpunkte, Erfordernisse und Probleme in der Branche.
3.4.
Methodik und Repräsentanz der Stichprobe
Mittels der Befragung wird ein Abbild der aktuellen Gegebenheiten in
Softwarebetrieben aufgezeigt. Für ein repräsentatives Ergebnis ist die
Rücklaufquote mit n = 36 zu gering. Die Ergebnisse dieser Befragung sind
als Tendenz zu werten und geben einen Ausschnitt der Realität wieder.
3.4.1. Häufigkeitsverteilung
Die einfachste Analyse stellt die Häufigkeitsverteilung dar. Es wird
aufgezeigt, wie häufig eine Antwort angegeben wurde. Zur besseren
Übersicht wird diese in Prozent ausgedrückt.
3.4.2. Kreuztabellen
Mit der bivariaten Analyse wird der Zusammenhang von zwei bis mehreren
Variablen überprüft.
50
Für zwei Variablen nichtmetrischer Ausprägung
51
eignet sich die Darstellung in Form von Kreuztabellen am besten.
52
Der Chi-Quadrat-Test (
?
²-Test) ist eine Methode zur Überprüfung der
Abhängigkeit zweier Merkmale. Dessen Ergebnis lässt Rückschlüsse auf die
50
Vgl. Bühl, Zöfel (2000), S. 225.
51
Der Begriff der bivariaten Analyse bezeichnet Variablen nichtmetrischer Ausprägung.
Sie besitzen eine nominale oder ordinalskalierte Ausprägung.
52
Vgl. Bühl, Zöfel (2000), S. 225.
Friedrich R. Behnk
Empirische Studie und Interviews
Seite 16
Irrtumswahrscheinlichkeit zu. Ein Kreuztabelle dessen Chi-Quadrat-Test
nach Pearson eine Signifikanz unter p = 0,05 aufweist, gilt als signifikant. In
diesem konkreten Beispiel wird von einer Irrtumswahrscheinlichkeit mit 5%
gesprochen. Sehr signifikant sind Ergebnisse deren Wert p = 0.01 aufweist.
Im Zusammenhang mit p = 0,001 ist die Bezeichnung höchst signifikant zu
gebrauchen.
53
Tabelle 2
Irrtumswahrscheinlichkeit und Bedeutung
p 0.05
nicht signifikant
p = 0.05
signifikant
p = 0.01
sehr signifikant
p = 0.001
höchst signifikant
54
3.4.3. Clustering
Zielsetzung der Clusteranalyse ist das Zusammenfassen von Probanden in
Gruppen. Die Mitglieder einer Gruppe sollen nach der Analyse weitgehend
übereinstimmende Eigenschaften aufweisen. Als ein guter Fusions-
algorithmus, welcher erstklassige Ergebnisse liefert und die Elemente den
,,richtigen" Gruppen zuordnet, hat sich das Ward-Verfahren etabliert.
55
53
Vgl. Bühl, Zöfel (2000), S. 109.
54
Quelle Bühl, Zöfel (2000), S. 109.
55
Vgl. Backhaus (2003), S. 516.
Friedrich R. Behnk
Empirische Studie und Interviews
Seite 17
Um das Verfahren sinnvoll anwenden zu können, müssen die folgenden
Voraussetzungen erfüllt sein:
56
-
Eine metrische Ausprägung der Variablen.
-
Es dürfen keine Ausreißer vorhanden sein.
-
Die zu prüfenden Variablen dürfen keine Korrelation
57
aufweisen.
-
Erwartungsgemäß sollten die Elementzahlen in jeder Gruppe ungefähr
gleich groß sein.
56
Vgl. Backhaus (2003), S. 517.
57
Vgl. Friedrichs (1985), S 388, ff.
Friedrich R. Behnk
Die Softwareentwicklung
Seite 18
4. Die Softwareentwicklung
Um die Softwareentwicklung genauer einordnen zu können, müssen die
Begriffe System und Systementwicklung erläutert werden.
,,Ein System ist ein sinnvoller Satz von miteinander verbundenen
Komponenten, die zusammenarbeiten, um ein bestimmtes Ziel zu
erreichen".
58
Unter System wird ein Verbund von Komponenten verstanden, die in
Beziehungen zueinander stehen und damit etwas bewirken. Beziehungen
sind informationelle, materielle oder energetische Vorgänge. Die kleinste
Ebene, auf die sich ein System herunterbrechen lässt, ist das Element.
59
Systemtypisch ist durch das Zusammenwirken vieler Elemente die
Eigenschaft der Komplexität. Sehr komplexe Systeme bestehen aus
Subsystemen, die einzeln für sich wiederum ein System darstellen.
Die allgemeine Definition eines Systems kann sowohl Software als
Beziehung zwischen den Elementen des Systems erklären, als auch
Software selbst als System oder Subsystem veranschaulichen.
58
Sommerville (2001), S. 35.
59
Vgl. Züst (1997), S. 30.
Friedrich R. Behnk
Die Softwareentwicklung
Seite 19
Abbildung 1 Das System
60
Nach der obigen Definition muss ein System nicht zwingend eine Software
enthalten. Das System einer analogen Uhr ist komplex und beinhaltet keine
Software. Eine Digitaluhr ist ein System, welches zusätzlich eine Software
enthält, ohne die sie nutzlos wäre. Das Abbilden eines betriebs-
wirtschaftlichen Vorganges zielt hingegen in wenigen Fällen auf das
Entwerfen und das Entwickeln einer Hardware ab. Es ist somit selten
notwendig, eine Hardwareentwicklung in eine Projektbetrachtung mit
einzubeziehen.
Die Definition von Ernst Denert bezieht sich auf Systeme, die eine Software
beinhalten. ,,Ein System
61
ist die Gesamtheit aller Module, die sich in einem
ganzheitlichen Zusammenhang befinden. Es antwortet auf die Eingabe von
60
Quelle Böhm, Fuchs, Pacher (1996), S. 30.
61
Gemeint ist Softwaresystem.
Friedrich R. Behnk
Die Softwareentwicklung
Seite 20
Informationen mit einer wohldefinierten Reaktion, indem es Informationen
speichert, transformiert und ausgibt".
62
Zum Entwickeln und Abbilden eines Systems ist die Systementwicklung
unumgänglich. Nach Ian Sommerville werden Systementwickler in die
Spezifikation des Systems, die Definition der Gesamtarchitektur und in die
Integration der verschiedenen Einzelteile involviert. Die Schwerpunkte der
Systementwicklung liegen weniger in der Entwicklung der Systemkompo-
nenten. Sie beinhaltet alle Aspekte der Entwicklung und umfasst die
Hardware-, Software- und Verfahrensentwicklung. Der Prozess der
Softwareentwicklung ist nur ein Teil der Systementwicklung. Er umfasst alle
Schritte, die zur Erstellung eines Softwaresystems notwendig sind.
63
4.1.
Gliederung des Softwareprojekts
Durch die Art der Problemstellung bei der Softwareentwicklung, lässt sich
das Erstellen eines Softwaresystems am effizientesten als Projektarbeit
bewältigen. Manfred Burghardt beschreibt ein Projekt als ein zielorientiertes
Vorhaben zur Herstellung eines Produktes, das in seinem zeitlichen Ablauf
klar umgrenzt und im Wesentlichen durch die Einmaligkeit der Bedingungen
in seiner Gesamtheit gekennzeichnet ist.
64
Ein Projekt besitzt folgenden Merkmale:
-
Einmaligkeit der Bedingungen und der Aufgabenstellung
-
Klar umgrenzter zeitlicher Rahmen, einem definierten Anfangs-
zeitpunkt und Endtermin
-
Herstellung eines Produktes
-
Projektspezifische Organisation
62
Denert (1991), S. 36.
63
Vgl. Sommerville (2001), S. 21 ff.
64
Vgl. Burghardt (2002), S. 19.
Friedrich R. Behnk
Die Softwareentwicklung
Seite 21
Um ein Projekt durchzuführen, wird es in vier Phasen unterteilt, die
sequentiell abgearbeitet werden:
65
-
Projektdefinition
-
Projektplanung
-
Projektkontrolle
-
Projekttermination
Phasenübergreifender Prozess ist das Management, welches die einzelnen
Phasen plant, steuert und kontrolliert.
Abbildung 2 Verlauf des Projektes
66
Unumgänglich ist die Eingliederung der Phasen der Softwareerstellung in
des Projektmanagement.
4.2.
Das Software-Engineering
Der Autor Sommerville definiert das SE als eine Disziplin, die sich mit allen
Aspekten der Softwareherstellung beschäftigt. Der Herstellungsprozess wird
in Phasen zerlegt und gegliedert, angefangen von der frühen Phase, der
Systemspezifikation bis hin zur Wartung des Systems, nachdem der Betrieb
aufgenommen wurde.
67
Der Schlüsselbegriff ,,alle Aspekte" betrifft nicht nur
die einzelnen Phasen, sondern auch die Qualitätskriterien, die eine Software
65
Vgl. Burghardt (2002), S. 13 ff.
66
Eigene Erweiterung der Darstellung von Burghardt (2002), S. 12.
67
Vgl. Sommerville (2001), S. 23.
Friedrich R. Behnk
Die Softwareentwicklung
Seite 22
erfüllen muss, und die Softwareprojektverwaltung, ohne die ein kontrolliertes
und zielgerichtetes Lenken des Projektes nicht möglich ist. Das SE umfasst
mehrere Phasen. Zur Erstellung einer Software existieren verschiedene
Vorgehensmodelle. Jedes Softwareprojekt,
unabhängig von dem
angewandten Vorgehensmodell, enthält folgende Phasen:
-
Definition der Systemanforderungen
-
Systementwurf, Planung
-
Systementwicklung und Tests
-
Integration und Tests
-
Betrieb und Wartung
Beim Wasserfallmodell, auch Softwarelebenszyklus genannt, werden die
Phasen sequentiell abgearbeitet. Das Aufdecken eines Fehlers veranlasst
einen Rücksprung in die Phase, in der der Fehler entstanden ist. Durch die
Veränderung und die daraus resultierenden Wirkungen müssen die
nachfolgenden Phasen wiederholt und überarbeitet werden.
68
Evolutionäre Entwicklung als Modell des SE basiert auf einer Anfangs-
implementation, die über viele Versionen weiterentwickelt wird.
69
Auch in
diesem Modell werden die einzelnen Phasen abgearbeitet. Der primäre
Unterschied zum Wasserfallmodell ist in der Intensität und der Art der
Durchführung zu finden. Die Systemdefinition hat einen geringen Umfang.
Der Systementwurf und die Systementwicklung gehen fließend ineinander
über. Durch die vielen Versionen erfolgt eine ständige Wiederholung der
ersten drei Schritte. Auf den Erfahrungen der vorherigen Versionen werden
die späteren Versionen entwickelt.
68
Vgl. Sommerville (2001), S. 58, Vgl. Denert (1991), S. 32, Vgl. Pomberger, Blaschek
(1992), S. 23.
69
Vgl. Sommerville (2001), S. 59, Vgl. Pomberger, Blaschek (1992), S. 24.
Friedrich R. Behnk
Die Softwareentwicklung
Seite 23
Darüber hinaus werden Hybriden und Weiterentwicklungen der genannten
Verfahren angewendet.
In der Definition der Systemanforderungen wird das System analysiert.
70
Ziel
der Analyse ist das Erkennen der Anforderungen und das Verstehen der
Interaktion der Subsysteme im Verbund.
71
Durch die erkannten
Anforderungen wird die Systemgrenze gesetzt. Sie stellt die
Systemschnittstelle zu anderen, z. B. Wirtschaftssystemen oder sozialen
Systemen dar.
Wichtige Grundlage für den ,,Systementwurf"
72
und die Planung ist der
,,Strukturplan"
73
, in dem die einzelnen ,,Meilensteine"
74
definiert werden. Bevor
nun das System entworfen wird, erfolgt das Abschätzen der für die
Entwicklung benötigten Ressourcen.
Nachdem die Grundlagen für das Projekt erstellt wurden, kann die
,,eigentliche" Entwicklungsarbeit in der Phase der Software-System-
entwicklung beginnen. Die Software-Systementwicklung beinhaltet die
Implementation, in der der Entwurf der Software programmiert wird. Um die
Korrektheit der Module zu gewährleisten, werden diese auf Richtigkeit mittels
Inspektionen geprüft.
75
Das anschließende Testen zeigt Fehler auf, die bis zu
diesem Zeitpunkt noch nicht gefunden wurden.
70
Vgl. Böhm, Fuchs, Pacher (1996), S. 334, Vgl. Pomberger, Blaschek (1992), S. 19.
71
Vgl. Sommerville (2001), S. 67, Vgl. Böhm, Fuchs, Pacher (1996), S. 147, Pomberger,
Blaschek (1992), S. 33.
72
Sommerville (2001), S. 108, Zender (1991), S. 87 Vgl. Böhm, Fuchs, Pacher (1996),
S. 16.
73
Burghardt (2002), S. 74, Schelle (2001), S. 109.
74
Burghardt (2002), S. 68, Zender (1991), S. 21, Denert (1991), S. 49.
75
Vgl. Burghardt (2002), S. 207, Denert (1991), S. 410.
Friedrich R. Behnk
Die Softwareentwicklung
Seite 24
Nach der Freigabe der Software erfolgt die Integration. Der letzte Test vor
der Integration ist der Akzeptanztest, in dem der Auftraggeber die Software
begutachtet und prüft, ob sie den Anforderungen entspricht.
76
Im Abschluss erfolgt der Betrieb und die Wartung. Unter Volllast und im
täglichen Gebrauch kristallisieren sich bisher unentdeckte Fehler heraus, die
es zu beheben gilt. Diese Phase beginnt nach Abschluss des Projektes und
umfasst alle im nachhinein anfallenden Arbeiten. Veränderungen der
Umgebung und steigende Anforderungen der Benutzer erfordern eine
Weiterentwicklung des Systems. Sie kann kontinuierlich oder in einem neuen
Projekt erfolgen.
Zum Erreichen einer definierten Qualität werden Standards festgelegt.
Einfluss auf die Qualität einer Software hat das vom Kunden veranschlagte
Budget und die zur Verfügung stehende Zeit.
Die Planung, Organisation und Steuerung erfolgt durch das Management,
welches dafür Sorge trägt, die definierten Ziele mit den festgelegten Mitteln
und Methoden zu erreichen.
4.2.1. Projektdefinition
Am Anfang eines jeden Projektes steht eine umfassende Analyse. In dem
analytischen Teil wird das System systematisch auf seine Elemente und
deren Beziehungen untereinander untersucht. Die Phase der Analyse wird in
die Problemanalyse und die Durchführbarkeitsanalyse gegliedert.
Es ist keine Seltenheit, dass seitens der Auftraggeber nur vage Angaben
über das gewünschte System bzw. die Problemstellung gemacht werden.
77
76
Vgl. Pomberger, Blaschek (1992), S. 44.
77
Vgl. Ergebnis des Interviews zur Frage 3: ,,Erhalten Sie in der Regel vom Auftraggeber
ein Lastenheft?".
Friedrich R. Behnk
Die Softwareentwicklung
Seite 25
Um die Wünsche und Bedürfnisse kundengerechter umzusetzen und die
Probleme in einer Software abbilden zu können, muss zuerst das System
erhoben, der Leistungsumfang geklärt und das System abgegrenzt werden.
Diesen Arbeitsschritt bezeichnet man als die Problemanalyse.
78
Die Systemerhebung hilft, das System zu verstehen, um es im nächsten
Schritt zu modellieren. Das Modell ist das Fundament, auf dem alle
nachfolgenden Arbeitsschritte aufbauen. Zur Erhebung finden verschiedene
Methoden Anwendung. Gängige Techniken sind die Befragung der
Mitarbeiter mittels Fragebogen und Interviews, bis hin zur Mitarbeit des
Analytikers.
79
Die Abgrenzung, die erst durch das Durchdringen des Systems ermöglicht
wird, legt die Ziele fest, die für ein erfolgreiches Abschließen des Projektes
unumgänglich sind. Zielkriterien sind Erreichbarkeit, Vollständigkeit,
Verständlichkeit und die Messbarkeit.
80
Das Resultat dieses Vorganges ist
die Systembeschreibung.
In größeren Projekten, in denen der Kunde eine Individualsoftware durch ein
Systemhaus programmieren lässt, ist es üblich, dass die bisherigen Schritte
von Analysten durchgeführt werden, die die Systembeschreibung in einem
,,Lastenheft"
81
oder auch dem so genannten ,,Anforderungskatalog"
82
nieder-
geschrieben wird.
78
Vgl. Pomberger, Blaschek (1992), S. 33.
79
Vgl. Pomberger, Blaschek (1992), S. 33.
80
Vgl. Hilgenberg,
www.pflichtenheft.de
(10.2003).
81
Vgl. Schelle (2001), S. 88, Sommerville (2001), S. 108.
82
Vgl. Burghardt (2002), S. 35.
Friedrich R. Behnk
Die Softwareentwicklung
Seite 26
Formal definiert sich das Lastenheft als die ,,Gesamtheit der Anforderungen
des Auftraggebers an die Lieferungen und Leistungen eines Auftrag-
nehmers"
83
. Es formuliert also ,,Was" zu erarbeiten ist und ,,Wofür".
84
Bevor ein Entwicklungsvorhaben angenommen wird, ist notwendig zu klären,
ob die Durchführung dieses Projektes für den Auftragnehmer sinnvoll
85
ist.
Methoden zur Durchführbarkeitsanalyse sind Expertenbefragungen und
Studien, die in Auftrag gegeben werden.
86
Kleinere Problemstellungen
werden in firmeninternen Diskussionen gelöst.
Wirtschaftliche Interessen sind von größter Bedeutung. Es geht jedoch nicht
immer in erster Linie um den rein monetär messbaren Gewinn; vielmehr
werden auch Vorhaben realisiert, die auf den ersten Blick mehr Kosten als
Umsatzerlöse produzieren. Der Zweck in diesem Vorgehen liegt im
Imagegewinn oder der Akquisition neuer Kunden.
87
Somit lässt sich darauf
schließen, dass die Realisierung eines Auftrages nicht nur kurzfristige Ziele,
sondern auch längerfristige Ziele verfolgt, die die Überlebensfähigkeit des
Software-Unternehmens sichern sollen.
Eine Gefahr dabei ist das Überschätzen der eigenen Fähigkeiten und
Ressourcen. Es werden Aufträge angenommen, die aufgrund fehlenden
Wissens und/oder fehlender Ressourcen in keinster Weise einen positiven
Beitrag leisten können, sondern von Beginn an zum Scheitern verurteilt sind
und am Ende ein negatives Licht auf den Auftragnehmer werfen.
83
DIN 69 905.
84
Vgl. Schelle (2001), S. 88.
85
Sinnvoll meint in diesem Zusammenhang ein Vorhaben mit vorgegebenen Zielen, die
mit vorhandenen Ressourcen realisierbar sind.
86
Vgl. Pomberger, Blaschek (1992), S. 47.
87
Siehe hierzu Ergebnis des Interviews zur Frage 11: ,,Berücksichtigen Sie in der Regel
bei der Erstellung der Software auch den Aspekt der Weiterentwicklung?",
Burghardt (2002), S. 43.
Friedrich R. Behnk
Die Softwareentwicklung
Seite 27
Wurde die Durchführbarkeitsanalyse positiv abgeschlossen, entsteht auf der
Grundlage der bis zu diesem Zeitpunkt gewonnenen Erkenntnisse das
Pflichtenheft.
88
Begrifflichkeiten, die in der Literatur synonym angewendet
werden, sind die Systemspezifikation und die Anforderungsbestimmung.
89
Die formale Beschreibung des Pflichtenheftes legt fest, ,,Womit" und ,,Wie"
die Forderungen verwirklicht werden.
90
Das Pflichtenheft erfüllt mehrere
Funktionen. Die wichtigste ist das Aufzeigen der benötigten Anforderungen.
91
Um die zu diesem Zeitpunkt größtmögliche Vollständigkeit und Konsistenz
des Konzeptes, also Widerspruchsfreiheit der Angaben, zu gewährleisten, ist
eine Validierung
92
unumgänglich. Die Durchführung erfolgt mit dem Kunden,
der die abzubildende Problematik am besten kennt - nicht zuletzt aufgrund
der Tatsache, dass die meisten Problemstellungen komplexe und
unüberschaubare Probleme sind.
93
Für sie kann es keine endgültige
Spezifikation geben.
Der Inhalt eines Pflichtenheftes kann sich im Detail sehr unterschiedlich
gliedern. Die Essenz der Aussagen der unterschiedlichsten Quellen ist
jedoch gleich. Das Pflichtenheft beschreibt das Gesamtsystem, die
Teilsysteme, die Datendefinition mit Schnittstellen und die allgemeinen
Systemangaben. Der Inhalt dieses Dokuments grenzt den Leistungsumfang
des Systems ab.
Aus dem Pflichtenheft muss für den Kunden klar hervorgehen
94
, was
umgesetzt werden soll und welche Forderungen unrealistisch sind. Auch gilt
es als juristisches Dokument und bildet im Streitfall vor Gericht die
essentielle Beweisgrundlage für vereinbarte Leistungen.
88
Vgl. Sommerville (2001), S. 108, Burghardt (2002), S. 36, Schelle (2001), S. 88.
89
Vgl. Pomberger, Blaschek (1992), S. 40.
90
Vgl. DIN 69 905.
91
Vgl. Burghardt (2002), S. 36.
92
Vgl. Sommerville (2001), S. 64.
93
Vgl. Sommerville (2001), S. 46.
94
Vgl. weiteres bei Grupp (1987), S. 75 ff; zum Thema Nurpraktiker, Nurtheoretiker und
Möchte-Gern-EDV-Profis.
Friedrich R. Behnk
Die Softwareentwicklung
Seite 28
Eine weitere Herausforderung, die es zu bewältigen gilt, ist der
kontinuierliche Wandel des Pflichtenheftes.
95
Aus praktischer Sicht ist es
unmöglich ein Pflichtenheft 1:1 auf das Projekt zu übertragen.
96
Die
Auftragnehmer und -geber entwickeln dieses Dokument über mehrere
Iterationszyklen während des Projektes weiter.
Das Ende dieses Projektabschnitts wird von der Prozessorganisation
geprägt.
97
In der Organisation werden Entwicklungsphasen festgelegt und
Richtlinien/Standards bestimmt.
98
Die Tabelle 3 ,,Entwicklungsabschnitte und
Phase" zeigt ein Beispiel für typische Entwicklungsbereiche und deren
Phasen. Zu erkennen ist, dass Phasen oft nicht exakt abgegrenzt werden
können, weil sie fließende Übergänge besitzen.
95
Vgl. Arnold (2003), 1 bis 9.
96
Ebenda.
97
Vgl. Burghardt (2002), S. 65.
98
Siehe hierzu Kap. 4.2.6. ,,Die Softwareentwicklung, Qualitätskriterien".
Details
- Seiten
- Erscheinungsform
- Originalausgabe
- Jahr
- 2004
- ISBN (eBook)
- 9783832479077
- ISBN (Paperback)
- 9783838679075
- DOI
- 10.3239/9783832479077
- Dateigröße
- 1.6 MB
- Sprache
- Deutsch
- Institution / Hochschule
- Fachhochschule Flensburg – Wirtschaftswissenschaften
- Erscheinungsdatum
- 2004 (April)
- Note
- 1,0
- Schlagworte
- sortware-engineering vorgehensmodell webprogrammierung
