Informatik Spektrum 22: 24–36 (1999)

© Springer-Verlag 1999

Hauptbeitrag

Die Praxis der Softwareentwicklung: Eine Erhebung*

Bernhard Deifel, Ursula Hinkel, Barbara Paech, Peter Scholz, Veronika Thurner

Zusammenfassung Im Rahmen des Forschungsverbundes Software-Engineering wurden durch Interviews die derzeit bei den Industriepartnern des Forschungsverbundes praktizierten Softwareentwicklungsprozesse erfaßt. Diese Studie wertet die Ergebnisse der geführten Interviews aus und stellt übergreifende Trends und Anforderungen bezüglich Pro-

Anwendungsmodellierung unter Einbeziehung der späteren Nutzerinnen und Nutzer. Ebenfalls im Vordergrund stehen Fragen der Qualitätssicherung,Verteilung und Modularität in der Systemarchitektur sowie die Wiederverwendung von Modellen und Systemteilen. An diesen fachgebietsübergreifenden Fragestellungen arbeiten erfahrene Partner aus Universitäten und Industrie ze§deÞnition, Beschreibungstechniken, WerkzeugunterstŸtzung, Dokumentation, Projektmanagement und Organisation der Fachgebiete Informatik, Betriebswirtschaft und der Anwendungsbereiche Informationstechnik und Maschinenwesen eng vor. zusammen. Im Rahmen von interdisziplinär angelegten TeilSchlüsselwörter Softwareentwicklungsprozeß, Pro- projekten kooperieren Teams der Technischen Universität und der Ludwig-Maximilians Universität München, der Universität zeßbewertung, Prozeßverbesserung, Beschreibungstechniken, Erlangen-Nürnberg, des FAST e.V. und einschlägiger IndustrieWerkzeugunterstützung unternehmen.Angestrebt wird die Integration der bisher weitSummary Within the research consortium on soft- gehend getrennten pragmatischen Arbeiten zur punktuellen Verbesserung der herrschenden Praxis der Softwareentwickware engineering FORSOFT, the software development processes currently practised by the consortiumÕs industrial part- lung einerseits sowie der grundlagenorientierten, vornehmlich akademischen Arbeiten zur Formalisierung und mathematiners were investigated into by interviews. This study evaluates the interview results and presents overall trends as well as schen Fundierung der Softwaretechnik andererseits [BEPT97].

requirements regarding process deÞnition, description techniques, tool support, documentation, project management, and organization.

2.Ziele der Befragung und Vorstellung des Fragebogens

Key words Software development process, Process evaluation, Process improvement, Description techniques, Tool support

1.Der Forschungsverbund SoftwareEngineering Die vorgestellte Studie wurde im Rahmen des Bayerischen Forschungsverbundes Software-Engineering (FORSOFT) durchgeführt. Ziel von FORSOFT ist die Beherrschung und Weiterentwicklung der technischen und organisatorischen Aspekte des Entwicklungsprozesses im Software-Engineering. Einer der Forschungsschwerpunkte liegt dabei auf der systematischen

*Diese Arbeit wurde gefördert von der Bayerischen Forschungsstiftung. Bernhard Deifel, Ursula Hinkel, Barbara Paech Peter Scholz,Veronika Thurner Institut für Informatik, Technische Universität München, Arcisstraße 21, D-80290 München, http://www.forsoft.de/, e-mail: {deifel, hinkel, paech, scholzp, thurner}@in.tum.de 24

Um als Forschungsgegenstand zielgerichtet Fragestellungen im Bereich der Softwareentwicklung herauszugreifen, die sowohl von der wissenschaftlichen Seite als auch von ihrer Relevanz für die Praxis her von großer Bedeutung sind, wurden zu Beginn des Forschungsverbundes die Softwareentwicklungspraktiken unserer Industriepartner untersucht. Ziel dieser Analysen war die Erfassung des Ist-Zustandes hinsichtlich gängiger Praktiken in der Softwareentwicklung sowie häufiger Schwachpunkte. Darauf basierend wurden Verbesserungspotentiale identifiziert. Die Analyse konzentrierte sich auf die Aspekte l Prozeßdefinition,Vorgehensmodell und Prozeßverbesserung, l Beschreibungstechniken und Darstellungsmittel, l Werkzeugunterstützung, l Management und Controlling sowie l Teamstruktur,Aufgabenverteilung und Einbettung in das Unternehmen. Für diese Analyse wurden bei den Industriepartnern durch Mitglieder des Instituts für Informatik, des Instituts für Informati-

B. Deifel et al.: Die Praxis der Softwareentwicklung: Eine Erhebung

onstechnik und des Instituts für Werkzeugmaschinen und Betriebswissenschaften (iwb) der Technischen Universität München und des Instituts für Mathematische Maschinen und Datenverarbeitung (IMMD) der Friedrich-Alexander Universität Erlangen-Nürnberg Interviews durchgeführt. Diese Interviews orientierten sich an einem Leitfaden, der die Problematik der Softwareentwicklung aus verschiedenen Blickwinkeln beleuchtet.Abbildung 1 gibt einen Überblick über die Struktur dieses Interviewleitfadens. Die Interviews konzentrierten sich auf eine qualitative Erfassung des Stands der Praxis. Quantitative Erhebungen wurden dabei nicht durchgeführt. Der Interviewleitfaden ist dreigeteilt.Abschnitt I untersucht strukturelle Aspekte des betrachteten Unternehmens sowie in detaillierterer Form des Teilbereiches der Befragten und ordnet diesen in das gesamte Unternehmen ein. Fragenteil II dient der fachlichen Einordnung der Befragten. Hier werden zunächst anhand eines Aufgaben- und Rollenschemas die Aufgaben und Tätigkeiten der einzelnen Befragten ermittelt. Jede der angegebenen Tätigkeiten wird anschließend mit Hilfe des Fragebogens genauer untersucht. Betrachtet werden dabei Aspekte technischer Tätigkeiten, Projektmanagement und die organisatorische Einbettung einer Tätigkeit sowie projektübergreifende Aspekte.Aus dem umfassenden Interviewleitfaden wurden also individuell für jeden Befragten die für sein Tätigkeitsfeld relevanten Fragen ausgewählt. Abschnitt III des Fragenkataloges erfaßt einerseits die Anforderungen der Industriepartner an Softwareprodukte sowie andererseits die sich daraus ableitenden Anforderungen an den Prozeß der Softwareentwicklung. Der Interviewleitfaden baut auf den Fragebögen des CMM [PCCW93] sowie des Software Best Practice Questionnaire ESSI [EC96] auf und umfaßt die dort behandelten Prozeßkriterien. Im Gegensatz zu den Befragungen nach CMM oder

ESSI untersucht unsere Studie nicht nur die Existenz und Umsetzung von Regelungen beispielsweise zur Prozeßdefinition oder zur Festlegung von Beschreibungstechnik.Vielmehr stehen auch die konkreten Inhalte der einzelnen Vorgaben im Vordergrund. Der von uns eingesetzte Interviewleitfaden wurde also um die entsprechenden Abfragen erweitert. Um einen fundierten Einblick in die Entwicklungspraktiken im Teilbereich der jeweils Befragten zu erhalten, ist es erforderlich, manche Bereiche relativ detailliert zu untersuchen. Dabei wird auf konkrete Projektbeispiele und die damit verknüpften positiven und negativen Erfahrungen der beteiligten Personen Bezug genommen. Der Schwerpunkt der Befragung lag, bedingt durch die Tätigkeitsfelder der Industriepartner von FORSOFT, auf dem technischen Vorgehensmodell der Softwareentwicklung. Fokussiert wurden dabei der Entwicklungsprozeß sowie die verwendeten Beschreibungstechniken. Ebenfalls betrachtet wurden die technische Werkzeugunterstützung, Dokumentation sowie Aspekte des Projektmanagements und der Organisation.Abbildung 2 gibt einen Überblick über die bei der Analyse untersuchten technischen und organisatorischen Aspekte der Softwareentwicklung. Der Stand der Praxis in der Industrie im Bereich des Projektmanagements von Softwareentwicklungsprojekten wird weiterführend im Detail vom Projektbereich B des Forschungsverbundes untersucht. Nach einer Vorstellung der Interviewpartner in Abschnitt 3 stellen wir in Abschnitt 4 kurz unsere Erwartungen an die Praxis vor, auf die wir in der Analyse der Interviewergebnisse (Abschnitt 5) Bezug nehmen. Dort zeigen wir auch an einzelnen Punkten Verbeserungspotential auf. In Abschnitt 6 stellen wir als Ergebnis der Analyse Kernfragen der Softwareentwicklung auf und fassen die Verbesserungsvorschläge noch einmal zusammen. Ferner stellen wir kurz die Erwartungen der Indu-

Strukturierung des Interviews I Strukturelle Einordnung I.1 Unternehmen als Ganzes

II Fachliche Einordnung: Aufgaben und Tätigkeit des Befragten II.1.1 Anforderungsanalyse und -definition

II.1.2 Entwurf, Design

II.1.3 Implementierung

II.1.4 Integration und Produkttest

II.1.5 Inbetriebnahme und Abnahme

II.1.6 Einsatz und Wartung

III Anforderungen II.1.7 Wiederverwendung, Weiterentwicklung

Management

III.1 Anforderungen an Softwareprodukte

Entwicklung

III.1.1 Anforderungen des Kunden

I.1.1 Struktur I.1.2 Produkte

III.1.2 Anforderungen aus dem Softwareentwicklungsunternehmen

Auftraggeber, Benutzer

I.2 Teilbereich des Befragten I.2.1 Struktur I.2.2 Produkte I.2.3 Rolle bzgl. Software

II.1 - II.3 Aspekte technischer Tätigkeiten

II.4 Projektmanagement, organisatorische Einbettung einer Tätigkeit

II.1.0 - II.1.8 Vorgehensmodell

II.4.1 Projektplanung

II.4.6 Konfigurationsmanagement

II.2 Beschreibungstechniken

II.4.2 Projektverfolgung

II.3 Werkzeugunterstützung der technischen Tätigkeiten

II.4.3 Ressourcenmanagement

II.4.8 Qualitätsmanagement

II.4.4 Risikomanagement

II.4.9 Dokumentation

II.4.7 Versionsverwaltung

II.4.5 Lieferantenmanagement

III.1.3 Gemeinsame Anforderungen von Kunden und Entwicklern III.1.4 Technische Anforderungen aus der Funktionalität

III.2 Anforderungen an den Entwicklungsprozeß

II.4.10 Einplanung der Wiederverwendung II.3 Werkzeugunterstützung des Managements

II.5 projektübergreifende Aspekte II.5.1 Struktur

25

II.5.2 Soziale Aspekte

B. Deifel et al.: Die Praxis der Softwareentwicklung: Eine Erhebung

II.5.3 Prozeß

Abb.1 Struktur des Interviewleitfadens

striepartner an die Zusammenarbeit mit FORSOFT vor und gehen auf die daraus resultierenden Konsequenzen für die Arbeit von FORSOFT ein.

3.Vorstellung der Interviewpartner Durchführung des Interviews. Die Interviews wurden von den Mitarbeitern der Universität aus den Bereichen Informatik und aus den Ingenieurwissenschaften Elektrotechnik und Maschinenwesen jeweils bei ihren direkten Industriepartnern innerhalb des Forschungsverbundes durchgeführt.An den Interviews nahmen Mitarbeiter aus insgesamt 20 unterschiedlichen Abteilungen von 13 verschiedenen Firmen teil, wobei je Abteilung genau ein Interview durchgeführt wurde. Die Firmen selbst beschäftigen ca. 5 bis 70000 Mitarbeiter, aufgeteilt wie folgt:

Tabelle Firmengröße klein

(bis zu 100 Mitarbeiter)

5

mittel

(bis zu 5000 Mitarbeiter)

5

groß

(über 5000 Mitarbeiter)

3

Teamgröße von 3 bis 50 Leuten Projektgöße von 36 bis 1500 Personenmonaten

Die Mitarbeiter in den unterschiedlichen Teams haben meist eine Hochschulausbildung und sind in den reinen Softwarebereichen vorwiegend Informatiker, während im Ingenieurbereich vor allem Ingenieure die Software entwickeln. Dies liegt hauptsächlich daran, daß dort häufig keine reinen Softwarepro-

Dokumentation

l

Existenz

l

Inhalt

l

Grad der Umsetzung

l

Verfolgbarkeit von Anforderungen

Vorgehen bei Verbesserung

l

Dokumentation von Änderungen

l

Beschreibungstechniken

l

Erstellung von projektbegleitender Dokumentation

Projektmanagement

Formalität

l

Projektplanung

l

Darstellungsweise (graphisch oder textuell)

l

Projektverfolgung

l

Einsatz und Akzeptanz abstrakter Beschreibungstechniken

l

Korrektur und Fortschreibung von Projektplänen

l

Wiederverwendung von erstellten Beschreibungen

l

Werkzeugunterstützung der Managementaufgaben

l

Technische Werkzeugunterstützung l

26

Befragte Abteilungen. Die befragten Abteilungen haben eine Mitarbeiteranzahl von ca. 5 bis zu 100 Personen. Etwa ein Viertel davon sind Dienstanbieter, die sowohl firmeninterne Abteilungen als auch externe Firmen, die im Auftrag von firmeninternen Abteilungen Teile von Projekten bearbeiten, in der Softwareentwicklung unterstützt. Die Dienste sind dabei die Entwicklung und Definition unternehmensweiter Standards und Entwicklungsmethoden, diesbezügliche Beratungen und Spezialthemen, wie die Definition von Softwarearchitekturen oder die Prozeßverbesserung. Die restlichen drei Viertel der Abteilungen entwickeln in erster Linie Software in abgeschlossenen Projekten von der Problemanalyse bis hin zur Fertigstellung oder sind an Teilen größerer Entwicklungsprojekte beteiligt. Die Interviewpartner wurden nicht direkt bezüglich einzelner spezifischer Projekte befragt, sondern bezüglich ihrer Erfahrung aus mehreren Projekten innerhalb ihrer Abteilung.

Tabelle Projektgröße

Rollen der Software. Software spielt in allen befragten Firmen zweierlei Rollen. Einerseits wird sie als Entwicklungswerkzeug und als Anwendungssoftware für unterschiedliche Zwecke, wie Projektmanagement, Büroanwendungen und so weiter, eingesetzt.Andererseits wird sie als eigenständiges Produkt oder als eingebetteter Teil eines Produktes verkauft. Die betrachteten Softwaretypen reichen hier von eingebetteten Realzeitsystemen

Prozeßdefinition

über Betriebssysteme, Middleware [Tre96] bis hin zu Anwendungssoftware.

Einsatz und Akzeptanz von technischen Werkzeugen

l

Durchgängigkeit der Werkzeugunterstützung

l

Codegenerierung

l

Schulung für den Werkzeugeinsatz

Organisation l

Struktur

l

Aufgabenteilung und Kooperation

B. Deifel et al.: Die Praxis der Softwareentwicklung: Eine Erhebung

Abb.2 Übersicht über die untersuchten Aspekte der Softwareentwicklung

jekte durchgeführt werden, sondern Software als Teil eines tech- Soziale Faktoren. An der Softwareentwicklung ist meist ein vielfältiger Personenkreis mit sehr unterschiedlichen Interessen nischen Produktes entwickelt wird. und unterschiedlicher Vorbildung beteiligt. Die erfolgreiche Kommunikation zwischen diesen unterschiedlichen Gruppen hat entscheidenden Einfluß auf den Verlauf der Entwicklung und die Qualität des Endprodukts (siehe z.B. IPAS-Projekt 4.Erwartungen an die Praxis [WO92]). Diese Kommunikation wird durch Maßnahmen wie gemeinsame Workshops und Schulungen zur Angleichung des Wissensstands der Beteiligten unterstützt. Ein weiterer Faktor In diesem Abschnitt beschreiben wir unsere Erwartungen an dieser Kommunikation ist der Stellenwert der Softwareentwickdie industrielle Praxis vor der Durchführung der Interviews. Diese Erwartungen basieren zum einen auf in der Literatur eta- lung im Unternehmen. Die strategische Bedeutung von Softblierten Methoden, zum anderen auf eigenen oder in der Litera- ware ist allen Beteiligten bewußt (z.B. [SBF+95]). tur beschriebenen Erfahrungen mit Industriepartnern. Die industrielle Praxis ist deutlich geprägt von der Einführung einer prozeßorientierten Qualitätssicherung, wie sie in den Normen ISO-9000 und CMM [KS95,Hoh95] und ent5.Stand der Praxis sprechenden Richtlinien (z.B. ESI [ESI94]) festgelegt wird. Dabei steht der Wunsch nach einem übergreifenden, einheitlichen Prozeß im Widerstreit mit einem individuell angepaßten ProIn diesem Abschnitt stellen wir die Ergebnisse der Interviews jektvorgehen und dem raschen technologischen Wandel.Wir vor und zeigen an einzelnen Punkten Verbesserungspotential beschreiben nachfolgend die wichtigsten Elemente einer proauf.Wir gliedern die Analyse nach den technischen und den orzeßorientierten Qualitätssicherung und unsere diesbezüglichen ganisatorischen Aspekten der Softwareentwicklung. Erwartungen. Wichtige Kernaussagen sind in Tabellen zusammengestellt und mit einer quantitativen Auswertung über alle geProzeßdefinition. Entsprechend dem ISO-Standard ist der Pro- führten Interviews versehen. Dabei gibt die Zahl nach dem zeß auf einer Ebene standardisiert, die keine genauen FestleSchrägstrich jeweils an, von wievielen Interviewpartnern zu eigungen bezüglich der Inhalte der Zwischenprodukte trifft.Wie ner bestimmten Kernaussage Informationen vorliegen. Die inzwischen allgemein gefordert (z.B. [Som96]) wird aber ein Zahl vor dem Schrägstrich besagt, für wie viele der zu einem iteratives, prototyping-orientiertes Vorgehen unterstützt. Aspekt befragten Interviewpartner die Kernaussage erfüllt ist. Außerdem werden Vorgaben zur Wiederverwendung von Code und Zwischenprodukten gemacht [OS96]. Entsprechend der 5.1.Technisches Vorgehensmodell hohen Aktualität der Thematik Requirements Engineering im industriellen wie akademischen Umfeld (vgl. die Studie des Eu- Im Rahmen des technischen Vorgehensmodells untersuchen ropean Software Institute [ESI95] und die Vielzahl neuer Bücher wir die definierten und eingesetzten Prozesse und Methoden. wie [Wie95,Jac95,Mac96,SS97]) werden die Anforderungsspezi- Ferner betrachten wir Beschreibungstechniken sowie deren fikation und die Verfolgbarkeit von Anforderungen im VorgeWerkzeugunterstützung. hensmodell besonders berücksichtigt.Wie im ISO-Standard gefordert, wird der Prozeß permanent fortgeschrieben.

5.1.1.Existenz einer Prozeßdefinition

Beschreibungstechniken. Modellierungstechniken für Daten (z.B. Entity-Relationship-Diagramme [Che76]) und Verhalten (Automaten wie Statecharts [Har87] oder SDL [BH93], oder Prozeßbeschreibungen wie Use Cases [Jac92]) bzw. Sammlungen von Modellierungstechniken wie UML [BRJ97] sind bekannt und werden eingesetzt. Diese Techniken werden durch systematischen Einsatz von CASE-Werkzeugen zur Erstellung und Verwaltung der Modelle unterstützt. Insbesondere werden Änderungen an den Modellen und anderen Dokumenten systematisch gehandhabt. Die Konsistenz der Modelle wird durch organisatorische Maßnahmen, wie z.B. Reviews, sichergestellt. Für sicherheitskritische Anteile werden auch formale Methoden zur Validierung der Modelle eingesetzt [Bro97]. Projektmanagement. Das Projektmanagement umfaßt die Erstellung eines Projektplans und eines Aufwands- und Kostenplans. Der Projektplan wird projektbegleitend werkzeuggestützt fortgeschrieben. Die Aufwands- und Kostenpläne werden mit den tatsächlichen Aufwänden und Kosten verglichen. Dieser Abgleich dient als Entscheidungsgrundlage im Projektverlauf und zur Ableitung von Vorgaben für nachfolgende Projekte.

Existenz. In den meisten der befragten Unternehmen existiert eine Definition des Softwareentwicklungsprozesses. Sie strukturiert den Entwicklungsprozeß durch Zwischenprodukte und Meilensteine, die Kontrollpunkte für die Qualitätssicherung festlegen. Der Detaillierungsgrad der Prozeßdefinition orientiert sich häufig an den Anforderungen einer Zertifizierung nach der ISO-9000 Normengruppe. Mehr als die Hälfte der befragten Softwareentwicklungsgruppen sind ISO-9000 zertifiziert. Tabelle Prozeßdefinition Prozeßdefinition existiert

16 / 20

SWE-Prozeß untergeordnet zu HW-Systementwicklung

9 / 20

Organisation ist ISO-9000 zertifiziert

12 / 15

Abhängigkeit von der Unternehmensgröße. Einige der befragten Unternehmen verfügen über keine Prozeßdefinition für die Softwareentwicklung. Dabei kommen kleine, flexible Unterneh-

B. Deifel et al.: Die Praxis der Softwareentwicklung: Eine Erhebung

27

men, deren Entwicklerteams ausschließlich in überschaubaren Projekten eingesetzt werden, in der Regel gut ohne eine explizite Prozeßdefinition aus. Einfache Strukturen, kurze Kommunikationswege und die schnelle Anpassung an die Anforderungen neuer Projekte prägen hier die Arbeit im Entwicklungsteam. Die Vorgehensweise wird projektspezifisch und bei Bedarf abgesprochen und die resultierende Flexibilität von den Beteiligten als Vorteil angesehen. Die aus diesem Vorgehen bedingte Personenabhängigkeit des Projektverlaufes wird bei kleinen, überschaubaren Projekten von den Beteiligten selten als Nachteil empfunden. Im Gegensatz dazu wird bei größeren Unternehmen mit komplexeren, längerfristig angesetzten Softwareentwicklungsprojekten der Mangel einer adäquaten Prozeßdefinition als Schwachstelle erkannt. Eine Verbesserung dieser Situation durch Einführung eines definierten Prozesses ist dort in Arbeit.

l

Konsistenzüberprüfungen möglich, und Entwurfsentscheidungen können nicht rückverfolgt werden. Reviews dienen als einzige Qualitätssicherungsmaßnahme. Für die Überprüfung der Konsistenz durch diese Reviews scheint es aber keine klaren Vorgaben zu geben. In einem überwiegenden Teil der untersuchten Prozesse wird bestehende Software (Eigenentwicklung oder Fremdsoftware) weiterentwickelt. Es wurde aus den Interviews aller dings nicht deutlich, wie genau der Rückgriff auf das Bestehende erfolgt. Ebensowenig wurden uns inhaltliche Vorgaben zur Erstellung wiederverwendbarer Software genannt.

Gründe für diese Charakteristika. Bei näherer Betrachtung ergeben sich für diese Charakteristika Gründe, die spezifisch für den jeweiligen Prozeßkontext sind. Dabei lassen sich die Prozeßkontexte nach den folgenden Merkmalen detaillieren: l Es handelt sich um Software für Individualkunden oder um Trends im Inhalt der Prozeßdefinitionen. Die ProzeßdefinitioProduktsoftware. Zu letzterem zählt auch Middleware. nen der befragten Unternehmen weisen bezüglich ihrer Inhalte l Die Software wird neu entwickelt oder es existiert ein Kern, und ihrem Detaillierungsgrad einige übereinstimmende Trends der die wesentliche Funktionalität umfaßt und in den Proauf. In mehreren Fällen ist die Prozeßdefinition auf ein iteratijekten nur noch angepaßt werden muß. Im letzteren Fall ist ves, zyklisches Vorgehen ausgerichtet.Vermehrt werden auch noch zu unterscheiden, ob der Kern eine Eigenentwicklung Aspekte der bausteinorientierten Softwareentwicklung berückist oder ob in den Projekten jeweils andere Standardsoftware sichtigt. In den Bereichen Maschinenwesen und Automatisieangepaßt wird.Wir verwenden im folgenden für die Komporungstechnik wird die Softwareentwicklung als ein Teil der genenten des Kerns den Begriff Bausteine. Damit sind aber samten Maschinen- oder Geräteerstellung betrachtet. Hier keine speziellen Eigenschaften wie z.B. explizite Schnittstelsteht die Entwicklung der Maschine im Vordergrund, während len impliziert. die Softwareerstellung eine untergeordnete Rolle spielt und sich in vielen Fällen auf die Anpassung bestehender Software an Än- Prozeßtypen. Diese Merkmale haben großen Einfluß auf die derungen an der Maschine beschränkt. Bei der Entwicklung Ausprägung der Entwicklungsschritte Analyse, Entwurf und von Anwendungen mit hohem Datenbankanteil wird ein großer Implementierung und die dort definierten Zwischenprodukte. Teil des Entwicklungsaufwandes in die Gestaltung der BedienWir gehen nachfolgend auf die vier möglichen Prozeßtypen oberfläche investiert, während der Entwurf der internen Softnäher ein. Dabei nehmen wir Bezug auf 17 der 20 Interviews, in warestruktur und -realisierung in den Hintergrund gerückt ist. denen von konkreten Produkten berichtet wird. Die anderen drei Interviewpartner arbeiteten nicht in konkreten Projekten, sondern an der Erstellung von Referenzprozessen für die jewei5.1.2.Inhalt der Prozeßdefinition ligen Unternehmen. In diesem Abschnitt gehen wir näher auf die in den Interviews beschriebenen Prozesse ein, unabhängig davon, ob sie so durch Tabelle Prozeßtypen eine Definition vorgegeben waren oder in den jeweiligen Projekten entstanden. Produktneuentwicklung 2 / 17 Charakteristika der Prozeßdefinitionen. Übergreifend lassen sich die in den Interviews beschriebenen Prozesse wie folgt charakterisieren: l Die Prozesse sind iterativ, oft auch prototyping-orientiert. l Analyse und Entwurf bzw. Implementierung sind selten klar getrennt. Es werden meist nur zwei dieser drei Entwicklungsschritte vollständig ausgeführt. Dies gilt auch für die Implementierung,wenn sie nur in der Anpassung einer bestehenden Software besteht. l Es gibt keinen systematischen Übergang zwischen den einzelnen Entwicklungsschritten und den entsprechenden Zwischenprodukten. l Es gibt kaum methodische Anleitung zur Erstellung der Zwischenprodukte (Modelle). Ihr Inhalt ist nicht genau festgelegt. l Inhaltliche Abhängigkeiten der Zwischenprodukte (Modelle) sind selten definiert bzw. dokumentiert. Damit sind keine 28

Bausteine als Produkt

1 / 17

Individuelle Anpassung einer Eigenentwicklung

9 / 17

Individuelle Anpassung von Standardsoftware

4 / 17

Individuelle Neuentwicklung

1 / 17

Individuelle Neuentwicklung. Dieser Fall wird bei den in der Literatur beschriebenen Softwareentwicklungsmethoden meist vorausgesetzt, aber nur in einem Interview berichtet. In diesem Fall wird versucht, für Analyse (incl. Oberflächenprototyp), Entwurf und Implementierung eigenständige Zwischenprodukte zu erstellen. Die genauen Inhalte der Zwischenprodukte werden aber erst während des Projektablaufs definiert. Das Projekt besteht aus mehreren parallel laufenden Teilprojekten, und es wird versucht, zwischen diesen Teilprojekten Teilergebnisse (das heißt Klassendefinitionen) auszutauschen. Sowohl dieses Ziel wie auch die Tatsache, daß der Oberflächenprototyp den Anwendern nicht ausreicht, ist Ursache dafür, daß sich Entwurf

B. Deifel et al.: Die Praxis der Softwareentwicklung: Eine Erhebung

und Implementierung bald verselbständigen und nur noch wenig Bezug zu den Analysemodellen haben. Neuentwicklung eines Produkts. Dieser Fall wird in zwei Interviews berichtet. In beiden Fällen liegt der Schwerpunkt auf dem Entwurf und der Implementierung. Die Prozesse sind aber sehr unterschiedlich. In einem Fall werden mächtige Modellierungs-, Simulations- und Codeerzeugungswerkzeuge verwendet. Damit sind die Inhalte und Beziehungen der Zwischenprodukte klar und Konsistenzüberprüfung möglich.Allerdings wird hier noch die mangelnde Kompatibilität der verschiedenen Werkzeuge beklagt. Die wenig ausgeprägte Anforderungsanalyse wird als problematisch angesehen. Im anderen Fall werden außer Text und Code keine Modellierungstechniken eingesetzt und kaum Zwischenprodukte definiert. Der Prozeß wird von der Implementierung dominiert. Der Bruch zur Anforderungsdefinition wird nicht als problematisch angesehen. Individuelle Anpassung des bestehenden Kerns. In dreizehn Fällen steht in den Projekten die Anpassung eines bestehenden Kerns im Vordergrund, nur in einem Fall ohne kundenspezifische Anpassung. In neun Fällen ist der Kern eine Eigenentwicklung, in den anderen Fällen wird auf andere Standardsoftware zurückgegriffen.Aufgrund des starken Kundenbezugs liegt der Schwerpunkt des Prozesses auf der Anforderungsdefinition, die aber so spezifisch für die Kernsoftware gestaltet wird, daß sie praktisch direkt implementiert werden kann.Weiterhin werden Oberflächenprototypen erstellt. Bausteine als Produkt. Nur in einem Fall sind die Bausteine selbst das Produkt, d.h. also für andere wiederverwendbar. Es liegt dafür keine Prozeßdefinition vor. Die Bausteine werden größtenteils aus bestehender Individualsoftware entnommen und verallgemeinert. Deshalb wird keine eigentliche Anforderungsanalyse durchgeführt, und ein Großteil der Implementierung entfällt. Der Schwerpunkt liegt auf dem Entwurf, nämlich der Strukturierung der Bausteine zur leichten Wiederverwendbarkeit.

Handhabung von Vorschlägen zur Prozeßverbesserung. Nach den Informationen der Interviews ist die Handhabung von Vorschlägen zur Prozeßverbesserung abhängig von der Größe der Unternehmen bzw. Entwicklungsteams. Tendentiell verfügen größere Teams über einen definierten Verbesserungsvorgang, während kleinere Teams mit Verbesserungsmöglichkeiten eher spontan und ohne vorherige Planung umgehen. Unabhängig von der Teamgröße werden längerfristig angelegte Analysen von Erfolgszahlen üblicherweise nicht durchgeführt.

Grad der Umsetzung. Neben der Existenz und den Inhalten von Prozeßdefinitionen wurde auch der Grad ihrer Umsetzung untersucht. Es stellte sich heraus, daß in knapp der Hälfte der Fälle eine existierende Prozeßdefinition nur bedingt oder gar nicht umgesetzt wird. Einer der wesentlichen Gründe hierfür ist, daß die vorgegebene Prozeßdefinition oft zu allgemein und grobgranular für die unmittelbare Umsetzung im Projekt ist, so daß Anpassungen und projektabhängige Veränderungen fast immer erforderlich sind. In anderen Fällen paßt die vorgegebene Prozeßdefinition nicht zur Aufgabenstellung. Diese Problematik tritt üblicherweise dann auf, wenn eine allgemeine Prozeßdefinition zentral entwickelt und vorgegeben wurde, die jedoch nicht die speziellen Anforderungen bestimmter Produkttypen oder Spezialaufgaben berücksichtigt.

Prozeßdefinition wird im wesentlichen umgesetzt

9 / 16

Verbesserungspotential. Ein Vergleich der Interviewergebnisse mit dem Stand der Technik deckt eine Reihe von Verbesserungsmöglichkeiten im Rahmen von Existenz, Inhalt und Umsetzung einer Prozeßdefinition auf. Das in der Prozeßdefinition festgeschriebene Vorgehensmodell ist oft zu allgemein und nicht adäquat für die konkrete Aufgabenstellung. Ein Rückgriff auf bestehende Software reduziert die Notwendigkeit von Entwurfsmodellen. Ferner fehlt eine Systematik für bausteinorientierte Softwareentwicklung, die die Neuentwicklung von Bausteinen ebenso unterstützt wie die spätere Auswahl aus einer existierenden Bibliothek von Bausteinen zur Wiederverwendung.Weiterhin fehlt der bei vielen Zwischenprodukten notwendige Prozeß zur Verwaltung von Änderungen und Beziehungen zwischen den Produkten sowie eine geeignete Werkzeugunterstützung.

5.1.4.Vorgehen bei der Prozeßverbesserung

5.1.3.Umsetzung der Prozeßdefinition

Tabelle Umsetzung der Prozeßdefinition

Akzeptanz von Vorgaben anderer Fachgruppen.Wenig gegenseitige Akzeptanz finden auch Prozeßdefinitionen, die zwischen Personen mit unterschiedlichem fachlichen Hintergrund ausgetauscht werden. Beispielsweise werden von Informatikern erstellte Prozeßdefinitionen in Ingenieurteams oft nur bedingt angenommen und umgekehrt. Häufigster Ablehnungsgrund ist hier der Vorwurf des mangelnden Einblicks in die Fachprobleme der jeweils anderen Gruppe, wobei Möglichkeiten für Kommunikation und Wissensaustausch jedoch nur bedingt genutzt werden. Hier entstand deshalb der Eindruck, daß diese Ablehnung sich mehr auf kulturellen Widerständen als auf sachlichen Argumenten begründet.

Tabelle Prozeßverbesserung Prozeßverbesserung ist definierte Aufgabe Prozeßverbesserung verläuft nach geregeltem Prozeß

10 / 11 4 / 10

Prozeßverbesserung bei großen Teams. Die größeren Entwicklungsteams erachten einen geregelten Umgang mit Verbesserungsvorschlägen als sinnvoll, um einen Wildwuchs von Verbesserungsideen und damit von einer Vielfalt von umgesetzten Praktiken zu verhindern. So wird eine einheitliche Prozeßdefinition aufrecht erhalten, die für alle Projektbeteiligten bindend ist. Größere Teams weisen üblicherweise ein gewisses Bewußtsein für die Nützlichkeit eines systematischen Verbesserungsprozesses auf. Gelegentlich werden hier auch externe Berater zur Prozeßverbesserung hinzugezogen, wobei jedoch bezüglich der Vorschläge von außen in einigen Fällen Akzeptanzprobleme auftreten.

B. Deifel et al.: Die Praxis der Softwareentwicklung: Eine Erhebung

29

Prozeßverbesserung bei mittleren Teams. Im Gegensatz dazu kommen bei mittleren und kleineren Unternehmen Verbesserungsvorschläge fast ausschließlich von innen, also unmittelbar von Mitgliedern des Entwicklungsteams. Diese werden beispielsweise von speziellen Arbeitskreisen zur Prozeßverbesserung kontinuierlich geprüft und gegebenenfalls in die Prozeßdefinition integriert. Prozeßverbesserung bei sehr kleinen Teams. Auch bei sehr kleinen Unternehmen und Entwicklungsteams kommen die Verbesserungsvorschläge üblicherweise von den Entwicklern selbst. Teilweise ohne systematische Vorauswahl werden hier neue Konzepte schnell ausprobiert und möglicherweise wieder verworfen.Ausschlaggebend für die Entscheidung über die weitere Verwendung der getesteten Konzepte ist hier das direkte Feedback über die Kundenzufriedenheit.

5.1.5.Beschreibungstechniken

gunterstützt auf Petrinetze abgebildet werden. Im Bereich der Kontrollsysteme werden für die Spezifikation datenfluß- und automatenbasierte Beschreibungstechniken wie etwa Statecharts und Activitycharts [ILO90] eingesetzt. Akzeptanz von Beschreibungstechniken. Je größer ein Entwicklungsteam, desto höher scheint die Bereitschaft zu sein, Beschreibungstechniken in den System- und Softwareentwicklungsprozeß einzubinden. Hier unterstützen abstrakte Beschreibungen mit präziser Bedeutung die Kommunikation zwischen den Entwicklern und erweisen sich gegenüber den rein informellen, textuellen Beschreibungen als Vorteil.Wenn in Projekten auf den Einsatz von Beschreibungstechniken völlig verzichtet wird, so werden als Gründe für die Ablehnung der hohe Aufwand für die Einarbeitung sowie ein höherer Aufwand bei der Verwendung von Beschreibungstechniken genannt. Es wird bezweifelt, daß sich ein Prozeß mit Beschreibungstechniken flexibel gestalten läßt; das Ändern von bestehenden Beschreibungen wird als zu aufwendig eingeschätzt.

Die Befragung unserer Interviewpartner bezüglich des Einsatzes von Beschreibungstechniken hat ergeben, daß, sofern Beschreibungstechniken eingesetzt werden, diese semiformalen Charakter [Bro96] haben.

Wiederverwendung von Spezifikationen. Ein häufig angesprochenes Problem im Zusammenhang mit Beschreibungstechniken war die Frage nach der Wiederverwendung von Beschreibungen. Die Wiederverwendung wird als Möglichkeit erkannt, den Aufwand bei der System- und Softwareerstellung zu verrinCharakteristika semiformaler Beschreibungstechniken. Es gern – damit erscheint der Einsatz von (semi-)formalen Behandelt sich somit um Beschreibungsformen, die über keine schreibungstechniken als lohnend. Inwieweit die Verwendung wohldefinierte, formale, auf mathematisch-logischen Konzepten basierende Semantik verfügen, jedoch eine eindeutig festge- von Beschreibungstechniken für die Wiederverwendung eine Rolle spielt, wird von den Industriepartner noch nicht klar erlegte syntaktische Darstellung bieten.Als Konsequenz stehen kannt. Des weiteren fehlt generell eine Methode, die den Aspekt formale Verifikationsmethoden, wie zum Beispiel Model der Wiederverwendung in den bestehenden EntwicklungsproChecking [BCM+90], für den Nachweis der Systemkorrektheit oder für Konsistenzüberprüfungen nicht zur Verfügung. Bei ei- zeß einbaut und somit zum Beispiel das Identifizieren von Bausteinen unterstützt. nigen Industriepartnern erfolgt die System- und Softwareentwicklung gänzlich ohne semiformale Beschreibungsmittel; hier werden rein textuelle Beschreibungen erstellt und daraus direkt Anforderungen an eine ideale Beschreibungstechnik. Eine ideale Beschreibungstechnik nach den Vorstellungen der von der Quellcode abgeleitet. uns befragten Interviewpartner würde folgende Kriterien erfüllen: es würde sich um eine graphische Beschreibungsform hanTabelle Beschreibungstechniken deln, die leicht erlernbar und einsetzbar ist. Sie wäre werkzeugunterstützt und Ausgangspunkt für eine automatische, effiziEinsatz formaler Methoden 1 / 19 ente Codegenerierung.Allerdings würde die Existenz einer solEinsatz semiformaler Methoden 14 / 20 chen idealen Beschreibungstechnik noch lange nicht ihre Akzeptanz und ihren Einsatz in der Industrie gewährleisten. Um Beispiele für eingesetzte Beschreibungstechniken. Hinsichtlich die Vorteile von formalen Beschreibungstechniken noch klarer vermitteln zu können, ist in erster Linie die Entwicklung von der semiformalen Beschreibungstechniken zeichnet sich kein Werkzeugen erforderlich, die die Handhabung der Beschreieinheitlicher Trend ab. Die Liste der zum Einsatz kommenden bungstechniken erleichtern. Beschreibungstechniken reicht von objektorientierten Techniken wie Use Cases [Jac92] und OMT [Rum91] über Entity Relationship Diagramme [Che76], Data Dictionaries,Workflowdia- Verbesserungspotential. Bis es diese ideale Beschreibungstechnik geben wird, so die Auffassung der Autoren, sollten aber zugramme [JBS97] und SA/RT [HP87] bis hin zu Statecharts mindestens für sicherheitskritische Teile einer Systementwick[Har87,HN96] und SDL [IT92]. Es handelt sich dabei überwielung formale Beschreibungstechniken verwendet werden. Hier gend um graphische Beschreibungstechniken. Im Bereich des Maschinenwesens (Anlagentechnik) kommen neben rein textu- sollte vordergründig darauf geachtet werden, daß die verwenellen Beschreibungen proprietäre Darstellungsformen aus dem deten Techniken automatische Codegenerierung und Simulation anbieten, idealerweise auch die werkzeugunterstütze VerifiIngenieurbereich zum Einsatz. Hierzu zählen Funktions-, Sigkation ermöglichen. nalfluß- und Schaltpläne ([IEC,VDI, DIN]). Darüber hinaus werden ablauforientierte Beschreibungsformen wie Petrinetze [Rei85] verwendet. Dabei wird der Anwender jedoch nicht direkt mit den Formalismen der Petrinetze konfrontiert; er arbeitet auf der Ebene von Workflows oder Use Cases, die werkzeu30

B. Deifel et al.: Die Praxis der Softwareentwicklung: Eine Erhebung

Aus diesem Grund können sich solche industriellen Anwender eher vorstellen, mehr Geld in die Finanzierung von Wie im Abschnitt 5.1.5 bereits erläutert wurde, werden Beschrei- Werkzeugen zu investieren, die besseren Code generieren, weil dieser in vielen Kontrolleinheiten implementiert wird. Bei Firbungstechniken nur dann von der Industrie akzeptiert, wenn men, die Individualösungen herstellen, fällt dieser Kostenfaktor benutzerfreundliche Werkzeuge mit effizienter Codegenerieweniger ins Gewicht. Sie sind daher seltener bereit, viel Geld für rung zur Verfügung stehen.Aus diesem Grund wurden die Inoptimierende Entwurfswerkzeuge für Software zu bezahlen, terviewpartner zu dem Punkt technische Werkzeugunterstütweil hier der Einsatz von leistungsstärkeren Prozessoren im zung ebenfalls befragt. Vergleich zu den Gesamtkosten nur einen geringen Teil ausWerkzeugunterstützung hauptsächlich für graphische Sprachen. macht. Im Bereich der Kontrollsysteme werden Tools wie Statemate, Oftmals mangelnde Schulung. Kommen dann schließlich MatrixX und Ascet SD zur Erstellung von kontrollorientierten Spezifikationen verwendet. In der Telekommunikation dagegen Werkzeuge in einem Unternehmen zum Einsatz, so besteht oftmals nur ein mangelhaftes Schulungsangebot für die betroffesind eher die Sprache SDL unterstützende Werkzeuge im Einnen Mitarbeiter. Meist gibt es keinen systematischen Ausbilsatz.Werkzeuge werden also, wenn überhaupt, dann nur für sedungsplan, und Schulungen erfolgen nur auf Grund persönlimiformale und graphisch orientierte Beschreibungsmittel in chen Engagements der jeweiligen Mitarbeiter. den Entwurfsprozeß eingebunden. Kontrollsystementwickler reagieren auf den Einsatz von nicht-graphischen Sprachen wie Tabelle Werkzeugunterstützung Esterel [BG92] oder Lustre [HCRP91] trotz teilweise guter maschineller Unterstützung noch skeptischer als bei graphischen Sprachen.Als Begründung geben die Befragten meist an, daß Verwendung von CASE-Tools in Analyse- und Designphase 9 / 19 sich bisher selbst graphisch orientierte Sprachen wie etwa StaVerwendung von CASE-Tools für die Codegenerierung 7 / 19 techarts außerhalb von Forschungs- und VorentwicklungsabteiSystematische Schulungen für CASE-Tools und lungen bei den Anwendern nur zögerlich durchgesetzt hätten Beschreibungstechniken 9 / 15 und man nun nicht schon wieder neue Konzepte einführen könne. In allen Bereichen werden dagegen zunehmend GUI-Builder für das Prototyping von Oberflächen genutzt. Verbesserungspotential. Wir sind der Auffassung, daß gezielte Schulungen die Akzeptanz und den Einsatz von Werkzeugen erDurchgängige Werkzeugunterstützung fehlt. Wie sich bestätigt höhen würden. Darüber hinaus sollte in Zukunft die Implemenhat, gibt es noch keinen Werkzeugverbund, welcher alle Enttierung von technischen Werkzeugen zur Softwareentwicklung wicklungsschritte der Softwareentwicklung abdeckt, geschweige vorangetrieben werden. Dies kann nicht allein Aufgabe der Unidenn durchgängig ist. Bisher werden für die Softwareentwickversitäten und Forschungseinrichtungen sein, sondern erforlung mehrere Tools eingesetzt, die oftmals sogar von unterdert die intensive Zusammenarbeit von Industrie und Wissenschiedlichen Herstellern stammen. Folglich ist der Einsatz von schaft. So könnten zum Beispiel prototypische Ansätze aus dem formalen Beschreibungstechniken unattraktiv, weil ein durchBereich der Universitäten von der Industrie zu kommerziellen gängiger Entwurfsprozeß mit größtmöglicher WiederverwenWerkzeugen ausgebaut werden. dung von Arbeiten aus vorhergehenden Phasen nicht unterstützt wird. Es fehlen also herstellerübergreifende Quasistandards.Al5.1.7.Dokumentation von Entwicklungsentlerdings wird diese Toolvielfalt oftmals gerade von der Industrie scheidungen und vom Entwicklungsprozeß gewünscht, um die Unabhängigkeit von einem einzigen Toolhersteller zu gewährleisten. Bezüglich der Dokumentation von Entwicklungsentscheidungen und des Entwicklungsprozesses hat sich in den vergangeAutomatisch generierte Codes sind oft ineffizient. Weiterhin läßt nen Jahren nicht viel verändert. In allen befragten Bereichen haben wir dabei unabhängig von der Art der entwickelten Softsich feststellen, daß der automatisch generierte Targetcode der eingesetzten Werkzeuge für die Systembeschreibung oft ineffizi- ware gemeinsame Trends erkannt. In den meisten Projekten wird die Dokumentation generell aufgrund des hohen Zeitent ist. Erzeugter Code kann zwar für Prototypen mit entspredrucks vernachlässigt. Teilweise wird keine oder eine wenig dechend leistungsfähiger und daher auch teurer Hardware eingetaillierte Dokumentation erstellt. setzt werden, ist aber für die Erstellung von Serienprodukten, derzeit meist aus Performanz- und Speicherplatzgründen, ungeProbleme im Projektablauf. Dadurch ergeben sich verschiedeeignet. ne Probleme im Projektablauf.Am meisten wird beklagt, daß die erstellte Dokumentation keine ausreichende Verfolgbarkeit Benutzerakzeptanz ist abhängig vom Anwendungsgebiet. Ein von Anforderungen bietet. So ist meist nicht nachvollziehbar, wesentlicher Unterschied besteht hier auch zwischen Maschinenbauunternehmen und Kontrollsystementwicklern: während welche Anforderungen im einzelnen im fertigen Produkt umgeim Maschinenwesen Unikate oder nur wenige aber gleichzeitig setzt worden sind und warum manche Anforderungen nicht eingeflossen sind. Genausowenig wird dokumentiert, in welauch teuere Maschinen mit gleicher Bauart hergestellt werden, werden bei Firmen für Kontrollsystementwicklung hauptsäch- chen Systemteilen sich einzelne Anforderungen widerspiegeln. Damit ist beispielsweise bei einer späteren Änderung einer einlich hohe Stückzahlen produziert. Kostenunterschiede von wenigen D-Mark oder sogar Pfennigen bei Prozessoren beeinflus- zelnen Anforderung nicht sofort feststellbar, an welchen Stellen diese Auswirkungen auf die Umsetzung ins System hat. sen hier schon den Gewinn des Unternehmens.

5.1.6.Technische Werkzeugunterstützung

B. Deifel et al.: Die Praxis der Softwareentwicklung: Eine Erhebung

31

Probleme durch Änderungen. Ein weiteres häufig erwähntes Problem besteht darin, daß oft erst nach der Fertigstellung von Dokumenten Änderungen an deren Inhalt erforderlich werden. So wird beispielsweise erst im Laufe der Implementierung einzelner Systemteile festgestellt, daß das Design an manchen Stellen nicht umgesetzt werden kann und somit abgeändert werden muß. Solche Änderungen werden vielfach gar nicht oder nicht systematisch in der Dokumentation nachgezogen. Ein Interviewpartner erstellt statt einer direkten Anpassung der Dokumentation selbst Änderungsprotokolle, in denen alle Änderungen bezüglich der bestehenden Dokumente in zeitlicher Abfolge eingetragen werden. Problematisch hierbei ist allerdings das Herauslesen des letzten aktuellen Standes des Dokumentes. Falls jede Änderung direkt in die Dokumentation einfließt, haben manche Interviewpartner umgekehrt die Schwierigkeit, laufend sehr umfangreiche Dokumentationen immer wieder nach diesen Abänderungen gegenüber der Vorversion zu durchsuchen. Automatische Dokumentationserstellung. Ein Interviewpartner erprobt einen anderen Weg der Dokumentationserstellung, indem aus einer ablauffähigen semiformalen Spezifikation alle Dokumentationsinformationen automatisch generiert werden. Jedoch hat man auch hier die gleichen Probleme, Änderungen gegenüber vorher nachzuvollziehen. Verbesserungspotential. Unserer Ansicht nach muß, um die momentane Situation der Dokumentationsaktivit zu verbessern, zunächst allgemein das Bewußtsein für die Wichtigkeit einer Entwicklungsdokumentation sowohl in den Führungsebenen als auch bei den einzelnen Entwicklern gestärkt werden. So sollte der Aufwand für die Dokumentation bereits bei der Planung berücksichtigt werden. Um diesen möglichst gering zu halten, sollten Vorlagen und Checklisten über den Inhalt den Vorgang der Erstellung der Dokumentation unterstützten. Eine Verbesserung der Verfolgbarkeit kann man durch matrixartige Tabellen erreichen, die beispielsweise Anforderungen mit deren Umsetzungen in Bezug zueinander setzen. Gleichzeitig sollten zumindest für Umsetzungen, die zu vielen Diskussionen Anlaß geben könnten, die spezifischen Entscheidungsüberlegungen dokumentiert werden.

als Projekte geplant. Die folgenden Zahlen beziehen sich auf die befragten Abteilungen, die selbst eigene Projekte durchführen.

Tabelle Projektmanagement Erstellung von Projektplänen

7/8

Existenz von Projektmanagementwerkzeugen

7/8

Verfolgung der Projektpläne

6/8

Projektplanung. Falls Projektpläne erstellt werden, enthalten diese zumindest Zeitpläne. Diese werden häufig durch verschiedene Meilensteine unterteilt, zu denen die geforderten Zwischenergebnisse vorliegen müssen. Häufig erfolgen keine Risikoabschätzung, keine Ressourcenplanung und keine Kostenplanung. Projektverfolgung. Das Erreichen von Teilzielen oder die Feststellung von Abweichungen vom Projektplan wird zwar meistens grundsätzlich verfolgt, häufig wird hierbei jedoch nicht systematisch vorgegangen.Vereinzelt werden jedoch zur Fälligkeit des Meilensteins mit Hilfe von Reviews die Ergebnisse überprüft. Hinsichtlich ihrer Formalität fallen die Reviews zwischen den unterschiedlichen befragten Abteilungen sehr verschieden aus.Während einige Abteilungen einen formalen Review aufgrund des zu großen Aufwandes ablehnen, werden in anderen Abteilungen Reviews nach internen Richtlinien vorgenommen. Die Reviews laufen meistens prinzipiell gleich ab, indem in Sitzungen die Ersteller und die Reviewer die Ergebnisse gemeinsam besprechen. Je stärker auf die Formalität des Reviews geachtet wird, desto definierter ist dabei der konkrete Ablauf. Projektsteuerung. Falls im Review Abweichungen vom Projektplan festgestellt werden, wird fallabhängig nachkorrigiert. Dies kann zur Umplanung des Projektablaufes führen. Teilweise werden Kapazitäten erweitert. Im Extremfall wird auch ein Abbruch des Projektes veranlaßt.Auch bei der Korrektur von Projektplänen findet man ein Spektrum vom unsystematischen Vorgehen bis zum Einsatz eines voll durchdefinierten Konfigurationsmanagements, um Änderungen an den Projektplänen nachvollziehbar zu machen.Auch hier nimmt meist die Systematik mit der Projektgröße zu. So wird besonders in kleineren Projekten mit bis zu vier beteiligten Personen eine mündliche Absprache als ausreichend empfunden.

5.2.Organisatorisches Vorgehensmodell

Werkzeugunterstützung für Projektmanagement. Zur Unterstützung des Projektmanagements ist nahezu bei allen Befrag5.2.1.Projektmanagement ten ein Werkzeug vorhanden. Dieses wird jedoch selten wirklich eingesetzt, da es als aufwendig und oft nicht flexibel genug für Die Aktivitäten im Projektmanagement sind wegen der verschiedenen Aufgabenbereiche der befragten Abteilungen sehr Umplanungen angesehen wird.Wünschenswert wäre vor allem auch ein Werkzeug, das eine Beschreibung von Workflows ununterschiedlich. Meist werden nur für klar definierte und in terstützt und ferner einen detaillierten Überblick über den Prosich abgeschlossene Aufgabenstellungen Projektpläne erjektstand ermöglicht. Das Konfigurationsmanagement wird stellt. Die Planungsaktivitäten und Kontrollaktivitäten nehmen tendenziell mit dem Umfang des Projektes zu. Da vor al- meistens durch dafür spezialisierte zugekaufte und eventuell lem in reinen Dienstleistungsabteilungen häufig nur kurzfri- auf entsprechende Abteilungsbedürfnisse angepaßte Werkzeuge unterstützt. stige Beratungstätigkeiten von geringem Umfang durchgeNeben diesen spezialisierten Werkzeugen werden führt werden, werden hier selten einzelne Projekte definiert. Dagegen haben die zu lösenden Aufgaben in Entwicklungsab- für Planungsaktivitäten und die Kommunikation meist verteilungen meist einen größeren Umfang und werden deshalb schiedene Office-Pakete bzw. Groupware und e-mail eingesetzt. 32

B. Deifel et al.: Die Praxis der Softwareentwicklung: Eine Erhebung

Verbesserungspotential. Um das Projektmanagement kurzfristig zu verbessern, müssen Projektpläne entsprechend verfolgt und jeweils zum Kontrollzeitpunkt entsprechend flexibel angepaßt werden. Dazu ist es notwendig, bereits während der Projektplanung die erwarteten Zwischenergebnisse festzuschreiben und gleichzeitig die Art und den Zeitpunkt der Ergebniskontrolle zu planen.

5.2.2.Organisation

Hauptziele sein.Während der Vertrieb aufgrund des Ziels hoher Absatzzahlen möglichst viele Anforderungen realisiert haben will, achtet die Entwicklung darauf, den Entwicklungsaufwand gering zu halten, und versucht daher, die Anzahl der Anforderungen zu reduzieren. Eine personelle Trennung der Definition von Kundenanforderungen und der Definition tatsächlich zu realisierender Anforderungen ist hier sinnvoll, weil gerade die Abwägung konkurrierender Ziele explizit notwendig wird und in Verhandlungen zwischen den Abteilungen ein für die Firma optimales Ergebnis gefunden werden muß.

Grundsätzlich hat jede Firma ihre eigene individuelle Organisationsstruktur. Es lassen sich jedoch manche Gemeinsamkeiten Tabelle Organisation und Trends erkennen. Stabsabteilung für die Softwareentwicklung

Stabsabteilungen für die Softwareentwicklung. In den größeren Firmen bestehen zentrale Stabsabteilungen, die sich ausschließlich mit softwareentwicklungsspezifischen Aufgaben beschäftigen. Zum einen entwickeln diese unternehmensweite Standards und Methoden. Zum anderen werden teilweise Beratungs- und Coachingaufgaben in den Entwicklungsbereichen übernommen.Außerdem übernehmen sie Servicefunktionen, wie zum Beispiel Werkzeugauswahl, -empfehlung und manchmal auch -anpassung für die Anwendungsbereiche. Neben den rein technischen Aufgaben befinden sich meist auch fachliche Vorfeldabteilungen im zentralen Bereich, die sich um zukünftige Entwicklungen im Anwendungsbereich kümmern. Beziehung zwischen Stabs- und Entwicklungsabteilungen. Im Verständnis der eigentlichen Entwicklungsabteilungen werden die Stabsabteilungen als Zulieferer aufgefaßt. Manchmal funktionieren in den Firmen jedoch der Informationsfluß und die Aufgabenteilung zwischen Stab und Entwicklung nicht optimal. So werden teilweise zentral und manchmal losgelöst von Entwicklungsabteilungen Standards definiert, die dann in den einzelnen Entwicklungsabteilungen nicht eingesetzt werden.Andererseits kommt es vor, daß sich Entwicklungsabteilungen eigene Werkzeuge zusammenstellen, die bereits in ähnlicher Version in anderen Abteilungen vorhanden sind und nur auf die jeweils speziellen Bedürfnisse der Abteilungen angepaßt werden müßten. Entwicklung innerhalb einer Abteilung. Zur Entwicklung der Software selbst gibt es prinzipiell zwei unterschiedliche organisatorische Strukturierungen. Einerseits existieren Organisationen, in denen Entwicklungsprojekte durchgängig von der Problemanalyse bis zum Intergrationstest innerhalb einer Abteilung durchgeführt werden. Dies bietet den Vorteil, daß sich sämtliche Informationen bezüglich eines Projektes immer innerhalb dieser Abteilung befinden.

Entwicklung innerhalb einer Abteilung Entwicklung über mehrere Abteilungen hinweg

5 / 20 10 / 20 5 / 20

Outsourcing. In der gleichen Kunden-/Lieferantenbeziehung befindet sich eine interne Abteilung, die gewisse Tätigkeiten an externe Firmen vergeben hat. Kriterien zur Aufteilung in interne und externe Tätigkeiten können die gleichen sein wie bei der Aufteilung auf Abteilungen. Beispielsweise wurde bei einem Interviewpartner die komplette Implementierungstätigkeit ausgelagert. Teilweise ist das Outsourcing lediglich rein organisatorischer Natur, da Mitarbeiter der ausführenden Firma direkt vor Ort bei ihrem Kunden arbeiten. Erfahrungen mit Aufgabentrennung. Meistens wurden mit der Aufgabentrennung in unterschiedliche Abteilungen positive Erfahrungen gesammelt, da sich jede Abteilung auf einen gewissen Bereich spezialisieren kann. Problematisch ist jedoch der erhöhte Kommunikationsaufwand zwischen den Abteilungen. Beim Outsourcing kommt neben der Spezialisierung auf bestimmte Aufgabenbereiche auf Seiten des Auftragnehmers noch die größere Kostenflexibilität auf Seiten des Auftraggebers hinzu, da hier Ressourcen und Personal projektabhängig von extern hinzugekauft werden können. Jedoch wird diese höhere Flexibilität durch die gleichzeitige Auslagerung von Spezialwissen an den Auftragnehmer erkauft. Verbesserungspotential. Insgesamt wurde bestätigt, daß ein wesentlicher Punkt bei der Zusammenarbeit in einer abteilungsübergreifenden Organisation der richtige Informationsfluß ist. Unserer Meinung nach müssen deshalb zentrale Abteilungen die einzelnen Abteilungen über ihr Informations-und Serviceangebot entsprechend aufklären. Dies kann beispielsweise durch die intensive Nutzung von Intranetdiensten geschehen. Den Verlust von Spezialwissen beim Outsourcing kann man zumindest teilweise durch die verstärkte Forderung von Entwicklungsdokumentationen kompensieren.

Entwicklung über mehrere Abteilungen hinweg. Andererseits beobachten wir den Trend, daß die Entwicklungstätigkeit nach bestimmten Kriterien auf unterschiedliche Abteilungen aufgesplittet wird. Die Zusammenarbeit zwischen den Abteilungen geschieht dann meistens in einer Kunden-/Lieferantenbezie6.Fazit und Ausblick hung. Die Aufteilungskriterien sind unter anderem die verschiedenen Entwicklungsschritte oder technische Kriterien, wie zum Beispiel die Aufteilung in eine Hardware- und eine SoftIn diesem Bericht haben wir den Stand der Praxis der Softwareentwicklung. Ein Grund für eine Aufteilung nach Entwick- wareentwicklung bei den Industriepartnern von FORSOFT vorlungsschritten kann beispielsweise das Vertreten verschiedener gestellt.Ausgangspunkt war eine Befragung der Unternehmen. B. Deifel et al.: Die Praxis der Softwareentwicklung: Eine Erhebung

33

Ziel dieser Erhebung war es vor allem,Verbesserungspotential aufzudecken, das als Ausgangsbasis für die weiteren Forschungsaktivitäten in FORSOFT dienen wird. Im Rahmen unserer Interviewgespräche hatten die Industriepartner die Möglichkeit, ihre Verbesserungswünsche für die Softwareentwicklung zu äußern.Weiterhin wurden aufgrund der Interviewergebnisse Verbesserungsvorschläge erarbeitet, die aufzeigen, wie der aktuelle Stand der Technik besser in den Unternehmen umgesetzt werden kann. Schließlich hat sich auch gezeigt, daß zudem einige Gebiete der Softwareentwicklung noch nicht ausreichend theoretisch aufbereitet sind. Im folgenden werden wir neben diesen Kernfragen der Softwareentwicklung die Erwartung der FORSOFT Industriepartner an den Forschungsverbund sowie unsere Verbesserungsvorschläge zum besseren Einsatz der bereits vorhandenen Techniken erläutern. Erwartungen und Wünsche der Industriepartner.Wie wir festgestellt haben, gibt es bereits zahlreiche Insellösungen für die verschiedenartigen Fragestellungen der Softwareentwicklung, wenngleich tragfeste Brücken zwischen diesen Inseln noch fehlen. Zwar existieren bereits für manche Problemstellungen unterschiedliche Werkzeuge und Methoden, deren Korrelation und Anwendbarkeit für ein konkretes Projekt sind für die Unternehmen aber oft nur schlecht durchschaubar.Viele Industriepartner wünschen sich deshalb eine methodische Unterstützung für den Vergleich verschiedener Ansätze zur Softwareentwicklung. Nur so kann für ein bestimmtes Projekt schnell und kostengünstig die passende Entwicklungsstrategie gefunden werden. Doch nicht nur die passende Methode zu finden ist ein Problem in der Industrie; vielmehr würden sich unsere Partner gezielte Verbesserungen in den Vorgehensmodellen wünschen. Dies betrifft vor allem die Übergänge zwischen den einzelnen Entwicklungsphasen und die Erstellung und den Einsatz von Bausteinen.Außerdem würde man es begrüßen, wenn vermehrt Techniken und Werkzeuge zur Projektkoordination eingesetzt werden könnten. Werkzeugunterstützung ist aber nicht nur für Projektmanager ein Thema. Die meisten der in FORSOFT assoziierten Unternehmen wünschen sich den Einsatz von Tools, die den gesamten Projektverlauf in allen Phasen begleiten. So sollte beispielsweise die Verfolgung einzelner Anforderungen vom Requirements Engineering bis hin zum fertigen Produkt anhand einer systematischen Dokumentation möglich sein. Zu diesem Zweck müßten natürlich auch sämtliche Designentscheidungen und -änderungen systematisch erfaßt werden können. Den Industriepartnern ist auch bewußt, daß der Informationsfluß zwischen den Beteiligten oft nicht gut genug ist und insbesondere von Nicht-Informatikern die Komplexität der Softwareentwicklung nicht richtig eingeschätzt wird.

Unternehmen finden.Allerdings mußten wir auch feststellen, daß selbst in Bereichen, wo solche Werkzeuge existieren, diese nicht immer verwendet werden. So sind im Bereich Verifikation theoretische Arbeiten in Tools umgesetzt worden, dennoch ist beispielsweise automatisches Model Checking nur selten, interaktives Theorembeweisen so gut wie nie ein Thema bei Firmen. Der Transfer dieser Technologien in die Entwicklungsabteilungen wäre sicherlich mit gezielten Schulungen möglich. Firmeninterne Ausbildungen könnten auch helfen, Mitarbeitern formale Beschreibungstechniken zugänglicher zu machen, die sie dann konsequent und systematisch im Entwicklungsprozeß einsetzen könnten. Formale Beschreibungstechniken ermöglichen nicht nur eine Verifikation der inneren Konsistenz des Designs, die sicherheitskritische Situationen entschärfen oder kostspielige Rückrufaktionen vermeiden kann, sondern dienen auch der Dokumentation des Entwicklungsprozesses. Für einen systematischen Entwicklungsprozeß ist es unabdingbar, selbst unter dem Druck von Meilensteinen und Zeitplänen, den Entwicklungsstand fortlaufend zu dokumentieren. Wie schon in den Abschnitten über Prozeßdefinition betont, sind firmenweite Prozeßdefinitionen nicht ausreichend. Sie müssen in den Entwicklungsabteilungen an die jeweiligen Aufgaben angepaßt sein. Dabei reicht es nicht, einzelne Zwischenergebnisse zu definieren. Die Prozeßvorgaben müssen auch methodische Anleitung für die Durchführung der einzelnen Entwicklungsschritte geben. Kernfragen der Softwareentwicklung. Die Ergebnisse der Umfrage zeigen folgende Kernfragen der Softwareentwicklung auf, die im Rahmen des Forschungsverbundes von wissenschaftlichem Interesse sind und deshalb in Zukunft aufgegriffen werden: l Es mangelt an der Durchgängigkeit des Entwicklungsprozesses, d.h. der methodischen und technischen Unterstützung konsistenter Übergänge zwischen den einzelnen Entwicklungsschritten. Dies muß durch aufeinander angepaßte Beschreibungstechniken und abgestimmte Werkzeuge behoben werden. l Die Erstellung und Wiederverwendung von Bausteinen ist ein wichtiges, bisher wissenschaftlich noch nicht konsolidiertes Forschungsthema. Es gilt zu klären, inwieweit der Einsatz von (abstrakten) Beschreibungsformalismen die Wiederverwendung von Modellen, Dokumenten und Code unterstützt. l Bisher fehlen adäquate und umfassende, methodische und werkzeugunterstützte Mittel zur Projektdokumentation und verwaltung, die allen Projektbeteiligten fortlaufend einen Einblick in den aktuellen Entwurfsfortschritt verschaffen.

Neben diesen technischen Kernfragen, die sowohl von seiten der Industrie als auch seitens der Hochschule gestellt wurden, Verbesserungsvorschläge zum Stand der Technik. Unsere Inter- ergeben sich auch weitere, eher sozial orientierte Problemstelviews haben ergeben, daß viele Technologien, die eigentlich lungen, die nicht in die Thematik des Forschungsverbundes Stand der Technik sind, noch nicht in der Industrie eingesetzt fallen, aber dennoch wichtig sind. So hat sich gezeigt, daß der werden. Dies begründet sich beispielsweise darin, daß manche Informationsfluß zwischen den an der Softwareentwicklung beMethoden und Beschreibungstechniken zwar wissenschaftlich teiligten Personen verbessert werden muß. Der mangelnde Wisfundiert sind, aber nur selten in industrietaugliche CASE Werk- sensaustausch rührt in erster Linie daher, daß die Arbeiten und zeuge umgesetzt werden und deshalb nur wenig Akzeptanz in Leistungen der beteiligten Gruppen untereinander teilweise 34

B. Deifel et al.: Die Praxis der Softwareentwicklung: Eine Erhebung

keine Wertschätzung finden. Dies gilt insbesondere für den Austausch zwischen untereinander fachfremden Personenkreisen wie etwa Ingenieuren und Informatikern. Dies hat natürlich auch auf die Akzeptanz von technischen Lösungen Auswirkungen.Ansätze aus der Informatik werden von Ingenieuren nicht anerkannt und umgekehrt; Softwareentwickler hinterfragen selten wirtschaftliche Aspekte der Softwareerstellung, und Manager wiederum haben oft nicht die nötige Ausbildung, um komplexe technische Zusammenhänge erkennen zu können. Gerade komplexe Fragestellungen können aber in Zukunft nur mit Hilfe einer fächerübergreifenden Denkweise in interdisziplinären Teams bearbeitet werden.Allgemein ist auffällig, daß gerade informatikspezifische Fragestellungen bei den Anwendern, oft Ingenieure aus dem Bereich der Elektrotechnik, nur auf wenig Verständnis stoßen. Ein Beitrag zur Lösung dieser Problematik wäre möglicherweise, Informatiker nicht nur in Fachabteilungen, sondern auch vermehrt für Stabs- und Managementtätigkeiten einzusetzen um so die Kommunikation zwischen Informatikern und informatikfremden Fachbereichen zu verbessern. Dies könnte bereits an den Hochschulen durch eine verstärkt interdisziplinär geprägte Ausbildung gefördert werden. Der Forschungsverbund Softwaretechnik hat es sich zur Aufgabe gemacht, die oben dargestellten Kernfragen der Softwareentwicklung aufzugreifen und deren Beantwortung voranzutreiben.Viele der gestellten Kernfragen werden freilich erst auf lange Sicht gelöst werden können. Trotzdem bietet FORSOFT bereits zum aktuellen Zeitpunkt für die beteiligten Industriepartner eine ideale Ausgangsbasis zur Verbesserung ihrer Softwareentwicklung.

Danksagung. Wir danken unseren Industriepartnern für die offen geführten Diskussionen und den Einblick, den sie uns in ihre tägliche Arbeit gewährt haben. Ferner bedanken wir uns bei den Kollegen, die an der Gestaltung des Fragebogens und der Durchführung der Interviews mitgewirkt haben: Dirk Ansorge, Andreas Gallasch, Michael Mauderer und Alexander Sabbah vom Institut für Werkzeugmaschinen und Betriebswissenschaften (iwb), Wolfgang Kellerer und Peter Sties vom Lehrstuhl für Kommunikationsnetze des Instituts für Informationstechnik, Thomas Kolloch vom Lehrstuhl für Prozeßrechner des Instituts für Informationstechnik und Sascha Molterer vom Institut für Informatik der Technischen Universität München sowie Gunnar Billing vom Institut für Mathematische Maschinen und Datenverarbeitung (IMMD) der Friedrich-Alexander Universität Erlangen-Nürnberg.

Bernhard Deifel ist seit 1996 Wissenschaftlicher Mitarbeiter am Institut für Informatik der TU München. Er studierte bis 1995 Informatik an der Universität Passau und arbeitete anschließend in einer Systems Engineering Gruppe bei BMW. Der Schwerpunkt seiner Arbeit liegt auf den Gebieten Requirements Engineering und Softwarearchitekturen.

Dr. Ursula Hinkel studierte Informatik an der TU München und war von 1994 bis 1998 wissenschaftliche Mitarbeiterin in der Forschungsgruppe von Professor Dr. Manfred Broy. Im Forschungsverbund FORSOFT lag ihr Arbeitsschwerpunkt im Bereich Software-Engineering für Telekommunikationssysteme. Gegenstand ihrer Promotion war die Spezifikationssprache SDL. Heute arbeitet sie als Software-Ingenieurin bei Rohde & Schwarz GmbH & Co.KG.

Barbara Paech studierte Informatik und promovierte 1990 an der LMU München. Nach Mutterschafts- und Erziehungsurlaub leitete sie von 1994–1997 ein Projekt an der TU München über die formale Fundierung von Softwareentwicklungsmethoden.Von 1997–1998 leitete sie ein Teilprojekt zum Thema Reengineering im Rahmen des Forschungsverbund FORSOFT an der TU München. Seit Oktober 1998 ist sie Leiterin der Requirements Engineering Gruppe an der Fraunhofer Einrichtung für experimentelles Software Engineering in Kaiserslautern. Veronika Thurner studierte Informatik an der Technischen Universität München und ist seit 1994 wissenschaftliche Mitarbeiterin am dortigen Institut für Informatik. Ihre Arbeitsschwerpunkte liegen in den Bereichen der Geschäftsprozeßmodellierung und -optimierung sowie der systematischen Softwareentwicklungsmethoden. Im Rahmen des Forschungsverbundes SoftwareEngineering FORSOFT leitet sie seit 1998 das Zentralprojekt zu Kernfragen der Softwareentwicklung. Peter Scholz studierte von November 1990 bis Mai 1995 Informatik und Wirtschaftswissenschaften an der Universität Passau. Er schloß sein Studium mit dem Diplom in Informatik ab. Danach war er bis September 1998 als wissenschaftlicher Mitarbeiter am Lehrstuhl von Prof. Dr. Manfred Broy an der TU München tätig. Seine Dissertation hat er über den Entwurf und die verteilte Implementierung reaktiver Systeme verfaßt. Seit Oktober 1998 ist er für die BMW Technik GmbH im Innovationscenter Produkt und Technologie im Bereich der Elektronikentwicklung tätig.

B. Deifel et al.: Die Praxis der Softwareentwicklung: Eine Erhebung

35

[HP87]

D. J. Hatley und I.A. Pirbhai. Strategies for Real-Time System Specification. Dorset House Publishing, 1987. Literatur [IEC] SPS-Programmierrichtlinie IEC 1131/3. [ILO90] i-Logix Inc., 22 Third Avenue, Burlington, Mass. 01803, U.S.A. Languages of Statemate, 1990. [BCM90] J.R. Burch, E.M. Clarke, K.L. McMillan, D.L. Dill und L.J. [ESI94] European Software Institute. Quality Systems Guideline Hwang. Symbolic Model Checking: 1020 States and Guide to ISO9001:94 for the Software Industry, 1994. Beyond. In Proceedings of the Conference on Logic in Com[IT92] ITU-T. Recommendation Z.100, Specification and Descripputer Science, Seiten 428–439, Philadelphia, Juni 1990. tion Language (SDL). ITU-T, Geneva, 1992. IEEE Computer Society Press. [Jac92] I. Jacobson. Object-Oriented Software Engineering – A [BEPT97] M. Broy, H. Ehler, B. Paech und V. Thurner. Innovation Use Case Driven Approach. Addison-Wesley, 1992. durch Kooperation im Software-Engineering. In Informa[Jac95] M. Jackson. Software Requirements and Specification. tik’97: Jahrestagung der Gesellschaft für Informatik, Reihe Addison-Wesley, 1995. Informatik aktuell, 1997. [BG92] G. Berry und G. Gonthier. The ESTEREL Synchronous Pro- [JBS97] S. Jablonski, M. Böhm und W. Schulze. Workflow-Management: Entwicklung von Anwendungen und Systemen – gramming Language: Design, Semantics, Implementation. Facetten einer neuen Technologie. dpunkt-Verlag, 1997. Science of Computer Programming , 19:87–152, 1992. [KS95] R. Kneuper und F. Sollmann. Normen zum Qualitätsmana[BH93] R. Braek und O. Haugen. Engineering Real Time Systems. gement bei der Softwareentwicklung.Informatik-Spektrum, Prentice Hall, 1993. 18:314–323, 1995. [BRJ97] G. Booch, J. Rumbaugh und I. Jacobson. The Unified Mode[Mac96] L.A. Macaulay. Requirements Engineering. Springer,Applied ling Language for Object-Oriented Development,Version Computing, 1996. 1.1, 1997. [OS96] Schwerpunkt: Wiederverwendung. Objektspektrum – [Bro96] M. Broy. Formal Description Techniques – How Formal Zeitschrift für objektorientierte Technologien, (1), 1996. and Descriptive are they. In R. Gotzhein und J. Bredereke, [PCCW93] M.C. Paulk, B. Curtis, M.B. Chrissis und C.V. Weber. CapabiHrsg., FORTE IX, 95–112 . Chapman and Hall, 1996. lity Maturity Model for Software,Version 1.1. Software En[Bro97] M. Broy, Hrsg. Schwerpunkt: Formale Methoden in der Pragineering Institute, Carnegie Mellon University, Pittsburgh, xis. IT&TI: Informationstechnik und technische Informatik, Pennsylvania, Februar 1993. 39(3), 1997. [Rei85] W. Reisig. Petri Nets – An Introduction. Number~4 in [Che76] P. Chen. The Entity-Relationship Model – Towards a UniEATCS Monograph. Springer, 1985. fied View of Data. ACM Transactions on Database Systems , [Rum91] J. Rumbaugh. Object-Oriented Modelling and Design. Pren1(1):9–36, 1976. [DIN] Funktionspläne nach DIN 40719, tice Hall, 1991. Teil 6. [SBF+95] H. G. Schwärtzel, M. Broy, G. Färber, R. Haggenmüller, G. [EC96] Directorate General III – Industry, European Commission. Held und G. Merbeth. Softwaretechnik – Beitrag zum BeSoftware Best Practice (ESSI), März 1996. richt Innovation und Forschung für Bayerns Zukunft, 1995. [ESI95] European Software Institute. ESPITI - European User [Som96] I. Sommerville. Software Engineering. Addison-Wesley, Survey Analysis, Dezember 1995. 1996. [Har87] D. Harel. Statecharts: A Visual Formalism for Complex Sys[SS97] I. Sommerville und P. Sawyer. Requirements Engineering: tems. Science of Computer Programming, 8:231–274,1987. A Good Practice Guide. John Wiley & Sons, 1997. [HCRP91]N. Halbwachs, P. Caspi, P. Raymond und D. Pilaud. The Synchronous Dataflow Programming Language Lustre. Procee- [Tre96] M. Tresch. MIDDLEWARE: Schlüsseltechnologie zur Entwicklung verteilter Informationssysteme. Informatikdings of the IEEE, 79(9):1305–1320, September 1991. Spektrum, (19):249–256, 1996. [HN96] D. Harel und A. Naamad. The Statemate Semantics of Sta[VDI] Funktionsdiagramme nach VDI 3260. techarts. ACM Transactions On Software Engineering and [Wie95] R.J. Wieringa. Requirements Engineering – Frameworks Methodology, 5(4):293–333, 1996. for Understanding. John Wiley & Sons, 1995. [Hoh95] B. Hohler. Software-Qualitätsmodelle: Capability Maturity [WO92] F. Weltz und R.G. Ortmann. Das Softwareprojekt – ProModel (SEI), Bootstrap-Methode, ISO 9000 ff. Informatikjektmanagement in der Praxis Campus, 1992. Spektrum , 18:324–334, 1995.

36

B. Deifel et al.: Die Praxis der Softwareentwicklung: Eine Erhebung