Diplomarbeit. F E R N U N I V E R S I T Ä T Gesamthochschule in Hagen Fachbereich Wirtschaftswissenschaft

Save this PDF as:
 WORD  PNG  TXT  JPG

Größe: px
Ab Seite anzeigen:

Download "Diplomarbeit. F E R N U N I V E R S I T Ä T Gesamthochschule in Hagen Fachbereich Wirtschaftswissenschaft"

Transkript

1 F E R N U N I V E R S I T Ä T Gesamthochschule in Hagen Fachbereich Wirtschaftswissenschaft Diplomarbeit im wirtschaftswissenschaftlichen Zusatzstudiengang für Ingenieure und Naturwissenschaftler Bearbeitungszeit 9 Wochen (Teilzeitstudent) im Fach : Wirtschaftsinformatik über das Thema : Analyse des V-Modells als Entwicklungsstandard für IT-Systeme des Bundes - ein Konzept zur inkrementellen Softwareentwicklung Betreut durch : Prof. Dr. R. Gabriel, Ruhr-Universität Bochum Verfasser : Dipl.-Ing. Christoph Wolfram Kettenbach Matrikel-Nr. : Anschrift : Mittelstraße Bremerhaven Telefon : 0471 / Fax : 0471 / Abgabedatum : 14. August 1998

2 Frau Petronella Steigert gewidmet.

3 Abstract Die vorliegende Diplomarbeit im Fach Wirtschaftsinformatik befaßt sich mit der Anwendung des Entwicklungsstandards für IT-Systeme des Bundes (V-Modell) für die Inkrementelle Entwicklung im Rahmen des Software Engineering. Nach einer kurzen Einführung in das V-Modell, die als Basis für die nachfolgenden Untersuchungen dient, wird untersucht, was unter Inkrementeller Entwicklung zu verstehen ist. Inkrementelle Entwicklung bedeutet: Entwicklung eines IT-Systems in Ausbaustufen innerhalb eines vorher festgelegten Gesamtrahmens der Anforderungen an das System. Die Inkrementelle Entwicklung soll einem grundsätzlichen Problem bei der IT-System-Entwicklung Abhilfe schaffen. Es ist das Problem, ein IT-System von vornherein so genau und treffend zu spezifizieren, daß die Entwicklung in nachfolgenden sequentiellen Phasen ablaufen kann. Die Erfahrungen mit den ausgelieferten Inkrementen ermöglichen es, die Anforderungen im Laufe einer Entwicklung stetig zu präzisieren. Inkrementelle Entwicklung hat fast immer auch evolutionären Charakter. Während der Entwicklung erfolgt ein permanenter Lernprozeß. Aufgrund des Lernprozesses verändern sich die Anforderungen, die ursprünglich einmal hinsichtlich des Systems formuliert wurden. Der Entwicklungsstandard für IT-Systeme des Bundes Vorgehensmodell (V-Modell) liegt in der neuen Ausgabe von Juni 1997 vor. Das V-Modell ist ein Standard, der als Arbeitsanleitung, Kommunikationsbasis und Vertragsgrundlage dienen kann. Innerhalb des Standards V- Modell gilt die Anwendung der Strategie der Inkrementellen Entwicklung von IT-Systemen als Regelfall. Es stellt sich die Frage, ob der Standard V-Modell den Anforderungen der Inkrementellen Entwicklung gerecht wird. Die Untersuchung zeigt: Die Anwendung des Entwicklungsstandards V-Modell für Inkrementelle Entwicklung ist sehr gut möglich. Das V-Modell ist kein Phasenmodell, welches ein streng sequentielles Abarbeiten von Phasen erforderlich macht. Die Regelungen des Standards sind auch nicht darauf fixiert, innerhalb von Phasenmodellen angewendet zu werden. Sie sind flexibel genug, um auch den Anforderungen der Inkrementellen und auch Evolutionären Entwicklung gerecht zu werden. Dies wird anhand des von Hesse vorgestellten Verfahrens zur Evolutionären Objektorientierten Softwareentwicklung (EOS) nachgewiesen. Der Standard V- Modell bietet wirkungsvolle Maßnahmen zur Unterstützung der Inkrementellen und Evolutionären Entwicklung. Er ermöglicht ein sachdienliches Management von Projekten mit Inkrementeller Entwicklungsstrategie.

4 INHALTSVERZEICHNIS 1 Einleitung Erläuterung der Aufgabenstellung Erläuterung der Vorgehensweise Organisatorische Rahmenbedingungen der Arbeit Danksagung V-Modell (Entwicklungsstandard für IT-Systeme des Bundes) Vorbemerkungen Entstehung des V-Modells Aufbau des Standards Definition des Begriffes Standard Standardisierungskonzept Tailoring Submodelle Projektmanagement Systemerstellung Qualitätssicherung Konfigurationsmanagement Dreistufige Standardisierung Gliederung eines IT-Systems nach V-Modell Einsatz des V-Modells in verschiedenen Organisationen Weiterentwicklung und Pflege des Standards Zweck des Standards...17 I

5 2.8.1 Vertragsgrundlage Arbeitsanleitung Kommunikationsbasis Verbreitung und wirtschaftliche Bedeutung des V-Modells Erörterung der Kritik am V-Modell Entwicklungsstrategien beim Software Engineering Software-Engineering Historisches (Softwarekrise) Begriffsdefinition Software Engineering Software Engineering als Ingenieurdisziplin System Engineering Definition des Begriffes Entwicklungsstrategie Wasserfallmodell (Phasenmodell) als ursprüngliche Strategie Nachteile der Strategie Problem der genauen Spezifikation von IT-Systemen Einteilung von Software nach ihrer Spezifizierbarkeit Ansätze zur Behebung des Spezifikationsproblems Das Problem der Wartung von IT-Systemen Beispiel für ein Wasserfallmodell (NASA) Wasserfallmodelle sind nicht sequentiell Vorstellung von Inkrementeller und Evolutionärer Entwicklungsstrategie Vorteile der Inkrementellen Entwicklungsstrategie Stetige Präzisierung der Spezifikation des IT-Systems Vermeidung der Entwicklung unnötiger Details Integration von Wartung und Weiterentwicklung Gründe für die Abgrenzung von inkrementell und evolutionär Inkrementelle Entwicklung und Cleanroom Software Engineering Entwicklungsstrategie Prototyping...47 II

6 3.6 Alternative Abgrenzung der Entwicklungsstrategien Entwicklungsstrategie Objektorientierte Entwicklung Analyse der Unterstützung der Strategie der Inkrementellen Entwicklung durch das V-Modell Relevanz der Fragestellung Analyse: Abgrenzung der Begriffe Phase und Aktivität im V-Modell Unterschied Entwicklungsstandard V-Modell und Phasenmodell Unzureichende Dynamik starrer Phasenmodelle Projektmanagement für Inkrementelle Softwareentwicklung Untersuchung der Unterstützung von Evolutionärer Objektorientierter Softwareentwicklung (EOS) durch das V-Modell Anforderungen an das Projektmanagement Analyse: Erfüllung der Anforderungen durch das V-Modell Evolutionäre Objektorientierte Softwareentwicklung (EOS) Analyse: Eignung des V-Modells als Standard für EOS Ergebnis Zusammenfassung der förderlichen Elemente des Standards Zusammenfassung der hinderlichen Elemente des Standards Zusammenfassung Literaturverzeichnis...75 Anhang...82 III

7 ABBILDUNGS- und TABELLENVERZEICHNIS Bild 1 Einteilung der Projekte (Vorhaben) in Typen beim Standardisierten Vortailoring...8 Bild 2 Vergleich der beiden Tailoringverfahren...9 Bild 3 Zusammenspiel der Submodelle...10 Bild 4 Ablauf der Systemerstellung (Submodell SE)...12 Bild 5 Mögliche Zustände eines Produktes nach V-Modell...14 Bild 6 Dreistufige Standardisierung im V-Modell...14 Bild 7 Gliederung eines IT-Systems nach V-Modell...16 Bild 8 Wasserfallmodell nach B. Boehm Bild 9 Phasenmodell der NASA...38 Bild 10 Verteilung des Personalaufwandes während der Phasen...39 Tabelle 1 Charakteristika der NASA -Softwareprojekte...40 Bild 11 Abgrenzung der Entwicklungsstrategien nach V-Modell...49 Bild 12 Abgrenzung der Entwicklungsstrategien nach Hesse...50 Bild 12 Mögliche zeitliche Anordnung der Aktivitäten...54 Bild 13 Ablauf der Inkrementellen Entwicklung nach V-Modell...55 Bild 14 Tätigkeiten in einem Entwicklungszyklus...63 Bild 15 Zeitlich verzahnte Entwicklungszyklen...64 Bild 16 Evolutionäre und Inkrementelle Entwicklung mit V-Modell...66 Bild 17 EOS mit V-Modell...68 IV

8 ABKÜRZUNGSVERZEICHNIS AU BMI BMVg BWB CASE DIN DoD EOS IPAS IT KM PM QS SE SEL V-Modell Allgemeiner Umdruck Bundesministerium des Innern Bundesministerium der Verteidigung Bundesamt für Wehrtechnik und Beschaffung Computer Aided Software Engineering Deutsches Institut für Normung Department of Defense (USA) Evolutionäre Objektorientierte Systementwicklung Interdisziplinäres Projekt zur Arbeitssituation in der Software-Entwicklung Informationstechnik Konfigurationsmanagement Projektmanagement Qualitätssicherung Systemerstellung Software Engineering Laboratory der NASA Entwicklungsstandard für IT-Systeme des Bundes (Vorgehensmodell) V

9 1 Einleitung 1.1 Erläuterung der Aufgabenstellung Das V-Modell ist der verbindliche Entwicklungsstandard für Informationstechnik-Systeme (IT-Systeme) im Bereich der Bundeswehr und im Bereich der öffentlichen Verwaltung. Es regelt die Vorgehensweise bei der Entwicklung von IT-Systemen. Die Bezeichnung V- Modell wird allgemein als Abkürzung des Begriffes Vorgehensmodell gebraucht. Ein Vorgehensmodell ist eine modellhafte Darstellung des idealtypischen Entstehungsprozesses von IT-Systemen. Weiterhin findet etwas spezieller die Bezeichnung V-Modell für Vorgehensmodelle Verwendung, bei denen die bildliche Darstellung der Abfolge von Entwicklungsaktivitäten dem Buchstaben V entspricht. Der linke Arm des Buchstabens besteht aus den Aktivitäten des Entwurfsprozesses von IT-Systemen, der rechte Arm aus den Aktivitäten der Integration und Überprüfung. Wurde in der ersten Version (1992) das V-Modell noch mit dem Titel Planung und Durchführung von IT-Vorhaben: Vorgehensmodell bezeichnet, so lautet der offizielle Titel der jetzt aktuellen Version (1997) Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell (V-Modell). Dieser Titel macht deutlich, daß das V-Modell als Standard aufgefaßt werden soll, der die Entwicklung von Systemen und Software regelt. Wird von dem V-Modell gesprochen, so ist häufig der Entwicklungsstandard für IT-Systeme des Bundes gemeint. In der vorliegenden Arbeit wird der Einfachheit halber statt der Bezeichnung Entwicklungsstandard für IT-Systeme des Bundes der Begriff V-Modell verwendet. Bei der Verwendung des V-Modells als Standard können verschiedene Entwicklungsstrategien zur Anwendung kommen. Solche Entwicklungsstrategien sind z. B. das Wasserfallmodell, Prototyping, Inkrementelle Entwicklung, Evolutionäre Entwicklung, Objektorientierte Entwicklung etc. Das Ziel dieser Arbeit ist, festzustellen, auf welche Weise und in welchem Umfang die Entwicklungsstrategie Inkrementelle Entwicklung durch den Standard V-Modell unterstützt wird. Das folgende Kapitel erläutert den Gang der Untersuchung zum Erreichen dieses Zieles. 1

10 1.2 Erläuterung der Vorgehensweise Die Untersuchung verläuft in drei Schritten. Der erste Schritt beinhaltet die überblicksartige Vorstellung des Entwicklungsstandards V-Modell. Nach einer Definition des Begriffes Standard erfolgt die Darstellung und Erläuterung von Inhalt und Zweck des V-Modells. Eine Erörterung der Kritik am V-Modell rundet das Bild ab. Der zweite Schritt beinhaltet die Untersuchung der Entwicklungsstrategie der Inkrementellen Entwicklung von IT-Systemen. Nach einer kurzen Erläuterung des Software Engineering richtet sich das Augenmerk der Untersuchung auf die unterschiedlichen Entwicklungsstrategien. Die Definition des Begriffes Entwicklungsstrategie bildet den Ausgangspunkt. Ein Vergleich mit anderen Entwicklungsstrategien verdeutlicht die Strategie der Inkrementellen Entwicklung und grenzt sie ab. Hierbei erfolgt insbesondere die Abgrenzung der Begriffe inkrementell und evolutionär durch die Darstellung verschiedener Sichtweisen dieser Begriffe. Der dritte Schritt analysiert, wie die Inkrementelle Entwicklung von IT-Systemen durch die Regelungen und Vorgaben des V-Modells unterstützt wird. Das geschieht u. a. anhand der Untersuchung, ob das V-Modell als Entwicklungsstandard für das von Hesse vorgestellte Verfahren der Evolutionären Objektorientierten Softwareentwicklung (EOS) 1 geeignet ist. Ein weiteres Ergebnis ist das Herausstellen der für die Inkrementelle Entwicklung förderlichen und hinderlichen Elemente des V-Modells. Die Zusammenfassung der Ergebnisse bildet den Abschluß der Arbeit. 1.3 Organisatorische Rahmenbedingungen der Arbeit Nach dem Abschluß meines Maschinenbaustudiums an der Universität der Bundeswehr Hamburg 1993, schrieb ich mich als Teilzeitstudent im Wirtschaftswissenschaftlichen Zusatzstudiengang für Ingenieure und Naturwissenschaftler an der FernUniversität Hagen ein. Als Bearbeitungsdauer für die vorliegende Diplomarbeit sind neun Wochen vorgesehen. Sie wurde direkt von Herrn Professor Dr. Gabriel, Ruhr-Universität Bochum betreut. Die Arbeit entstand neben meiner beruflichen Tätigkeit als Programmieroffizier der Marine. 1 vgl. Hesse, W. (1995), Evolutionäre objektorientierte Systementwicklung und Projektmanagement, in: Huber- Wäschle, F. et al. (Hrsg.), GISI 95 - Herausforderungen eines globalen Informationsverbundes für die Informatik, Informatik aktuell, Berlin Heidelberg New York 1995, S. 35 bis 42 2

11 1.4 Danksagung Bei Herrn Professor Dr. Gabriel bedanke ich mich für die Übernahme der Betreuung der Arbeit. Weiterhin bedanke ich mich bei Herrn Professor Dr. Gehring für die Zuteilung einer Diplomarbeit. Herrn Professor Dr. Hesse gilt mein Dank für die Bereitschaft, mir als ihm unbekannten Studenten aufgrund eines -kontaktes bereitwillig Kopien seiner Veröffentlichungen über EOS (Evolutionäre Objektorientierte Softwareentwicklung) zukommen zu lassen. Weiterhin möchte ich mich bei den zahlreichen Korrekturlesern dieser Arbeit für das Aufspüren von Rechtschreib- und Kommafehlern und für die fruchtbare Kritik bedanken. 3

12 2 V-Modell (Entwicklungsstandard für IT-Systeme des Bundes) 2.1 Vorbemerkungen Das V-Modell ist ein umfangreiches, mehrere hundert Seiten umfassendes Werk. Es besteht aus mehreren Teilen und es gibt eine Vielzahl von Zusätzen zu den eigentlichen Regelungen des Standards. Das V-Modell ist in gedruckter Form und als CD erhältlich. Auf der CD zum V-Modell ist eine Kurzbeschreibung enthalten. Sie ist der vorliegenden Arbeit als Anhang beigefügt. Die Kurzbeschreibung kann zusätzlich zu den in diesem Kapitel gemachten Ausführungen hilfreich sein, eine Übersicht über das V-Modell zu gewinnen. Die folgenden Ausführungen zum V-Modell sollen eine Überblick über den Standard schaffen. Zur detaillierteren Darstellung sei auf das V-Modell selbst verwiesen. Besonders betont werden die Aspekte des V-Modells, die für die nachfolgenden Untersuchungen zur Unterstützung der Strategie der Inkrementellen Entwicklung durch das V-Modell von Bedeutung sind. 2.2 Entstehung des V-Modells Das V-Modell wurde vom Bundesamt für Wehrtechnik und Beschaffung (BWB) in Zusammenarbeit mit der Beraterfirma IABG mbh erstellt. Das BWB ist für die materielle Ausrüstung der Streitkräfte zuständig. Es ist somit auch für die Entwicklung von Systemen und Software für die Bundeswehr und die Bundeswehrverwaltung verantwortlich. Bei der Vielzahl der zu betreuenden Entwicklungs- und Beschaffungsprojekte, die mit unterschiedlichsten Vertragspartnern abgewickelt werden, lag es nahe, eine verbindlichen Standard für IT-Projekte herauszugeben. Einen solchen hauseigenen Standard für die Beschaffung von IT-Systemen durchzusetzen, war aufgrund der nicht unerheblichen Nachfragemacht des BWB nicht schwer. Zumal andere NATO-Partner, allen voran das DoD (Department of Defense, USA) mit seinem MIL-STD- 4

13 498 2, Ähnliches taten. Bei der Erstellung des V-Modells orientierte man sich an den neusten Erkenntnissen zum Software Engineering und an den Standards der NATO-Partner. Es wurde eine verbindliche Richtlinie geschaffen, die vom Bundesministerium des Innern (BMI) für dessen Geschäftsbereich übernommen wurde. 2.3 Aufbau des Standards Das V-Modell besteht aus drei Teilen Teil 1 Regelungsteil Teil 2 Behördenspezifische Erweiterungen Bereich Bundesministerium der Verteidigung (BMVg) und Bereich Bundesministerium des Innern (BMI) Teil 3 Handbuchsammlung. Der Standard ist im Bereich des Bundesministeriums der Verteidigung als sog. Allgemeiner Umdruck (AU) veröffentlicht. AU 250 (Teil 1-3) ist des V-Modell. Weiterhin gehören zum Standard die Methodenzuordnung und die Funktionalen Werkzeuganforderungen, sie sind aber separat veröffentlicht. AU 251 ist die Methodenzuordnung, AU 252 die Funktionale Werkzeuganforderungen. Kern des Standards (AU 250) ist der Regelungsteil (Teil 1). Die beiden anderen Teile können als Erläuterung zum Regelungsteil aufgefaßt werden. Der Teil 2 enthält für den Bereich BMI und den Bereich BMVg unterschiedliche Ergänzungen und Erläuterungen. In Teil 3 wird u. a. die Anwendung des V-Modells für verschiedene Anwendungsfälle näher beschrieben. Auf diese Weise soll das Verständnis für die korrekte Anwendung des V-Modells gefördert werden. Auf der CD zum V-Modell sind zusätzlich Beispiele für seine konkrete Anwendung in Entwicklungsprojekten und Produktmuster (Muster für die Ergebnisse von Entwicklungsaktivitäten) enthalten, die nicht zum eigentlichen Umfang des Standards gehören. 2 o. V. (1994), MIL-STD-498: Military Standard: Software Development and Documentation, Department of Defense USA 5 December Dieser Standard wurde am 27. Mai 1998 zurückgezogen und ist jetzt im Standard IEEE/EIA 12207, "Information technology - Software life cycle process" enthalten. 5

14 2.4 Definition des Begriffes Standard Das DIN faßt den Begriff Standard als englische Übersetzung des Begriffes Norm auf. 3 Die Definition des Begriffes Norm nach DIN lautet: Dokument, das mit Konsens erstellt und von einer anerkannten Institution angenommen wurde und das für die allgemeine und wiederkehrende Anwendung Regeln, Leitlinien oder Merkmale für Tätigkeiten oder deren Ergebnisse festlegt, wobei ein optimaler Ordnungsgrad in einem gegebenen Zusammenhang angestrebt wird. 4 Allgemein wird ein Standard als eine Vereinheitlichung betrachtet, die nicht von einer Normungsinstitution herausgegeben wird, sondern sich auf andere Weise am Markt durchgesetzt hat. Die Definition des Begriffes Standard durch den Duden unterstützt diese Sichtweise:... etw., was als mustergültig, modellhaft angesehen wird u. nach dem sich anderes richtet; Richtschnur, Maßstab, Norm... 5 Besonders hervorzuheben ist, daß ein Standard gemäß der Definition des DIN Regeln, Leitlinien oder Merkmale für Tätigkeiten oder deren Ergebnisse festlegt. Genau dies leistet das V- Modell. Es legt, wie im Folgenden noch gezeigt wird, Regeln für die durchzuführenden Tätigkeiten während der Entwicklung von IT-Systemen fest. Diese Tätigkeiten werden im Rahmen des V-Modells als Aktivitäten bezeichnet. Weiterhin legt das V-Modell die Merkmale der Ergebnisse dieser Aktivitäten fest. Das V-Modell entspricht somit der Definition eines Standards. Im folgenden wird die Konzeption des Standards erläutert. 2.5 Standardisierungskonzept Tailoring Das Ziel des V-Modells ist es, für alle Entwicklungen von IT-Systemen eingesetzt werden zu können. Das V-Modell erhebt den Anspruch, allgemeingültig zu sein. Gleich ob eine kleine Büroanwendung mit eigenen Mitteln oder die Steuerung eines Kraftwerkes durch die Vergabe an Dritte entwickelt wird, das V-Modell soll bei beiden wirksam und sinnvoll verwendet werden können. Der Aufwand an Dokumentation und Verwaltung soll genau den jeweiligen Er- 3 o. V. (1994), DIN EN 4502 Allgemeine Fachausdrücke und deren Definition betreffend Normung und damit zusammenhängende Tätigkeiten, Berlin April 1994, S. 12 bis 13 4 ebenda, S o. V. (1989), Duden Deutsches Universalwörterbuch A-Z, 2. Auflage, Wien Zürich 1989, S

15 fordernissen angemessen sein. Eine überflüssige Papierflut soll genauso vermieden werden, wie das Fehlen wichtiger Dokumente. In allen Fällen soll eine lückenlose Dokumentation des Entwicklungsprozesses vorliegen. Diese sich widersprechenden Ansprüche wurden wie folgt gelöst: 1. Das V-Modell enthält einen Maximalansatz an allgemeingültigen Regelungen, die zusammen eine sinnvolle Beschreibung des Entwicklungsprozesses bilden und eine durchgängige Dokumentationskette sicherstellen. 2. Aus diesem Maximalansatz werden die für das jeweilige Projekt sinnvollen Regelungen herausgesucht. Dies geschieht nach Regeln, die im V-Modell selbst enthalten sind. Auf diese Weise wird für jede Art von Projekt eine sinnvolle Vorgehensbeschreibung und durchgängige Dokumentation gewährleistet. Wegen der Eigenschaft, allgemeingültig zu sein und durch ein festgelegtes Verfahren auf jede Projektsituation angepaßt werden zu müssen, wird das V-Modell auch als generisches Modell bezeichnet. Das V-Modell ist ein Standard für alle Fälle, zwingt aber dazu, es stets auf die konkrete Projektsituationen anzupassen. Das Anpassen geschieht weitestgehend bevor der eigentliche Entwicklungsprozeß des Systems beginnt, bei der Planung des Projektes. Das Ergebnis dieses Anpaßvorganges wird, neben der ausgewählten Entwicklungsstrategie, in einem für das jeweilige Projekt spezifischen Projekthandbuch beschrieben. Das Maßschneidern des V-Modells auf ein Projekt wird Tailoring genannt. Es gibt zwei verschiedene Arten, die für ein Projekt sinnvollen Regelungen zu bestimmen. Standardisiertes Vortailoring Beim sog. Standardisierten Vortailoring wird anhand von spezifischen Projektmerkmalen (z. B. Aufwand in Personenjahren u. a.) eine Einteilung von Projekten in Projekttypen vorgenommen (Bild 1). Projekte werden im Sprachgebrauch des V-Modells auch als Vorhaben bezeichnet. Für jeden Typus von Projekt existiert eine musterhafte Ausprägung des V-Modells. Es werden die notwendigen Arbeitsabläufe (Aktivitäten) und Dokumente (Produkte der Aktivitäten) für einen Projekttypus vorgeschlagen. Auf Basis dieses Vorschlages können dann Veränderungen, die für das konkrete Projekt sinnvoll sind, vorgenommen werden. Auf diese Weise wird das projektspezifische Vorgehensmodell erstellt. 7

16 Vorhabenklassen administrative IT-Vorhaben technisch-wissenschaftliche IT-Vorhaben Auswahl, Beschaffung und Anpassung von Fertigprodukten klein mittel groß klein/mittel groß Bild 1 Einteilung der Projekte (Vorhaben) in Typen beim Standardisierten Vortailoring Quelle: o. V. (1997), AU 250/3 Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell: Teil 3 Handbuchsammlung, Juni 1997, S. T-6 Tailoring nach Streichbedingungen Beim Tailoring nach Streichbedingungen durchsucht man das gesamte generische V-Modell nach für das konkrete Projekt sinnvollen Regelungen. Nicht sinnvolle Regelungen werden gestrichen. Dies geschieht nach Streichbedingungen, deren Festlegung im V-Modell beschrieben ist und die hier nicht weiter erläutert werden. Beim Streichen wird unterschieden zwischen solchen Streichungen, die schon zum Zeitpunkt der Projektplanung sicher bestimmt werden können, und potentiellen Streichungen, die sich erst im Projektverlauf ergeben. Dies geschieht durch ein Markieren von Aktivitäten und Produkten dieser Aktivitäten, deren Streichung sich im Projektverlauf ergeben könnte. Bild 2 verdeutlicht die beiden Tailoringverfahren. Es macht deutlich, wie von zwei unterschiedlichen Seiten ein Erzeugen des für das jeweilige Projekt spezifischen Vorgehensmodells aus dem generischen V-Modell bewerkstelligt werden kann. 8

17 Gesamtmenge der Regelungen des V-Modells Tailoring mit Streichbedingungen Streichen von Aktivitäten und Produkten anhand vorgegebener Streichbedingungen Standardisiertes Vortailoring Identifikation der relevanten Aktivitäten und Produkte durch Ermittlung des Vorhabentyps und der charakteristischen Ergänzungen Zusatzanforderungen Basisanforderungen verbliebene Regelungsmenge des Projekthandbuchs Bild 2 Vergleich der beiden Tailoringverfahren Quelle: o. V., AU 250/3 Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell: Teil 3 Handbuchsammlung, Juni 1997, S. T Submodelle Das V-Modell ist aufgeteilt in mehrere Untermodelle, Submodelle genannt (Bild 3). Das V- Modell beschränkt sich somit nicht nur auf die Beschreibung der Software- bzw. Systemerstellung (Submodell SE), sondern betrachtet auch die Bereiche, die neben der Systemerstellung in einem Projekt beachtet werden müssen. Diese Bereiche sind das Projektmanagement (Submodell PM), die Qualitätssicherung (Submodell QS) und das Konfigurationsmanagement (Submodell KM). Auf diese Weise wird eine ganzheitliche, integrierte Betrachtungsweise gewährleistet. Die Systemerstellung wird nicht isoliert betrachtet, sondern mit weiteren organisatorische Festlegungen zur Durchführung des Entwicklungsprojektes verknüpft. Die einzelnen Submodelle werden nachfolgend erläutert. 9

18 Projekt planen und kontrollieren PM Voraussetzungen schaffen und Softwareentwicklungsumgebung (SEU) bereitstellen Plandaten Istdaten SEU Istdaten SEU SEU Plandaten Plandaten Plandaten Istdaten Istdaten SEU QS- Anforderungen vorgeben SE Produkt entwickeln Produktstruktur planen Konfigurationsstruktur QS- Ergebnis Produkte prüfen QS QS-Anforderung Produkt Rechte Produkt Produkte/ Rechte verwalten KM Bild 3 Zusammenspiel der Submodelle Quelle: o. V. (1997), AU 250/1 Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell: Teil 1 Regelungsteil, Juni 1997, S Projektmanagement Das Submodell Projektmanagement beschreibt die Aktivitäten zur Planung, Durchführung und Kontrolle von Entwicklungsprojekten. Dies geschieht durch das Erzeugen eines projektspezifischen Vorgehensmodells (Tailoring). Weiterhin erfolgt auch die Festlegung der Entwicklungsstrategie, z. B. Inkrementelle Entwicklung oder Einsatz/Anpassung von Fertigprodukten. Dies umfaßt eine erste Planung der zeitlichen Abfolge der Aktivitäten für die verschiedenen Teile eines Systems. Die Gliederung eines IT-Systems nach V-Modell in verschiedene Teile, die sog. Segmente, wird später erörtert. Die Zeitliche Einteilung der Aktivitäten steht nicht von vornherein fest, da durch den Standard nur die logische Verknüpfungen der Aktivitäten erläutert werden. So ist es durchaus möglich, zu einem Zeitpunkt im Projekt für verschiedene Segmente des zu entwickelnden IT- Systems unterschiedliche Aktivitäten durchzuführen. Weiterhin regelt das Submodell PM die Festlegung von Werkzeugen (z. B. CASE-Tools) und Methoden der Entwicklung (z. B. Entitiy-Relationship-Modellierung für den Entwurf von relationalen Datenbanken). 10

19 Das Projektmanagement ist ausschließlich technisch orientiert. Das V-Modell enthält keinerlei aufbauorganisatorische Festlegungen zur Durchführung eines Projektes. Auf diese Weise ist das V-Modell unabhängig von der Unternehmensorganisation, in der es eingesetzt wird Systemerstellung Das Submodell Systemerstellung ist der Kern des V-Modells. Hier wird der Verlauf eines Entwicklungsprojektes bei der Erstellung des Systems bzw. der Software beschrieben. Bild 4 zeigt den Ablauf der Systemerstellung. Deutlich ist das V zu erkennen, welches symbolhaft für das V-Modell ist. Die Systemerstellung läuft in mehreren sog. Aktivitäten ab. Die Anzahl dieser Aktivitäten ist von der projektspezifischen Ausprägung des V-Modells abhängig. Die Aktivitäten werden in Bild 4 rechteckig dargestellt. Die Ergebnisse der Aktivitäten, die Produkte, werden in Ellipsen dargestellt. Die logischen Verbindungen der Aktivitäten sind durch die geraden Pfeile dargestellt. Bild 4 zeigt beispielsweise, daß die Produkte der Aktivität SE3 SW-/HW- Anforderungsanalyse, die Technischen Anforderungen und Betriebsinformationen, die Eingangsprodukte für die nächste Aktivität SE 4-SW SW-Grobentwurf sind. Auf diese Weise wird die logische Verknüpfung zwischen den Aktivitäten hergestellt. Die Aktivität der SE 7-SW SW-Integration wiederum prüft (gebogene Pfeile) die Durchführung und Ergebnisse der beiden o. g. Aktivitäten. Die bildliche Darstellung sämtlicher logischer Verknüpfungen führt zu der nicht gerade übersichtlichen Darstellung in Bild 4. Auf diese Weise wird gezeigt, daß die Zusammenhänge der Systemerstellung sehr komplex sind. Bild 4 stellt den Maximalansatz von Aktivitäten, Produkten und logischen Verknüpfungen dar, der sich durch das Tailoring verringert. Der Ablauf der Entwicklung besteht (im Maximalfall) aus den Aktivitäten System-Anforderungsanalyse System-Entwurf SW-/HW - Anforderungsanalyse SW - Grobentwurf SW - Feinentwurf SW - Implementierung 11

20 Externe Vorgaben (AG) Rahmenbedingungen (für SE 1.7) Protokoll System (installiert und in Betrieb) SE 1 System-Anforderungsanalyse SE 1.1 bis SE 1.8 SWPÄ-Konzept SE 9 Überleitung in die Nutzung SE 9.1 bis 9.3 Produktinformationen Kosten-/Nutzenanalyse Angebotsbewertung Anwenderforderungen Betriebsinformationen System (installierbar) SE 2 System-Entwurf SE 2.1 bis SE 2.6 Integrationsplan SE 8 System-Integration SE 8.1 bis SE 8.3 System- Ebene Schnittstellenübersicht Systemarchitektur Schnittstellenbeschreibung Betriebsinformationen Technische Anforderungen SW-Einheit Implementierungsdokumente (SW-Einheit) HW-Einheit Nicht-IT-Anteile SE 3 SW-/HW-Anforderungsanalyse SE 3.1 bis SE 3.5 Betriebsinformationen Technische Anforderungen SE 4-SW SW-Grobentwurf SE 4.1-SW bis SE 4.3-SW SE 7-SW SW-Integration SE 7.1-SW bis SE 7.4-SW Implementierungsdokumente (SW-Komponente) SW-Komponente SW-Einheits-/ HW-Einheits- Ebene SW-Kompo- nenten- Ebene Schnittstellenübersicht Schnittstellenbeschreibung Betriebsinformationen SW-Architektur Datenbank SW-Modul Implementierungsdokumente (SW-Modul, Datenbank) SE 5-SW SW-Feinentwurf SE 5.1-SW und SE 5.2-SW Datenkatalog SW-Entwurf Betriebsinformationen Modul-/Datenbank- Ebene Legende: SE 6-SW SW-Implementierung SE 6.1-SW bis SE 6.3-SW Prüfaktivitäten (siehe QS) Bild 4 Ablauf der Systemerstellung (Submodell SE) Quelle: o. V. (1997), AU 250/1 Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell: Teil 1 Regelungsteil, Juni 1997, S SW - Integration System - Integration Überleitung in die Nutzung 12

21 Diese Hauptaktivitäten sind wiederum in Teilaktivitäten unterteilt. Sowohl von den Haupt- als auch von den Teilaktivitäten können aufgrund des Tailorings verschiedene entfallen. Die Beschreibung der Tätigkeiten in den einzelnen Aktivitäten kann dem V-Modell Teil 1 (Regelungsteil) oder der Kurzbeschreibung des V-Modells (siehe Anhang) entnommen werden Qualitätssicherung Das Submodell QS beschreibt die Qualitätssicherung im Projekt. Die QS geschieht im Rahmen einer (möglichst objektiven) Nachweisführung. Es wird die Erfüllung der in den Anforderungsdokumenten geforderten Eigenschaften des Systems überprüft. Die Anforderungsdokumente sind z. B. das Ergebnis der Systemanforderungsanalyse Konfigurationsmanagement Das Submodell Konfigurationsmanagement (KM) stellt sicher, daß die Produkte, die im Entwicklungsprozeß entstehen (Programmcode und Dokumentation) in ihrem Zustand und in ihrem Zusammenhang stets eindeutig identifizierbar sind. Dies umfaßt insbesondere eine Verwaltung der verschiedenen Versionen der Produkte. Es stellt sicher, daß Änderungen an den Produkten nur kontrolliert vorgenommen werden können (Änderungsmanagement). Um dies umzusetzen, können Produkte in einer Aktivität nur die in Bild 5 dargestellten Zustände geplant, in Bearbeitung, vorgelegt und akzeptiert einnehmen. 6 6 vgl. o. V. (1997), AU 250/1 Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell: Teil 1 Regelungsteil, Juni 1997, S

22 geplant in Bearb. vorgelegt akzeptiert * * Dieser Zustandsübergang wird durch Aktivität KM 3 Änderungsmanagement (Konfigurationssteuerung) verursacht. Dabei entsteht eine neue Produktversion. Bild 5 Mögliche Zustände eines Produktes nach V-Modell Quelle: o. V. (1997), AU 250/1 Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell: Teil 1 Regelungsteil, Juni 1997, S Dreistufige Standardisierung Auf der Basis der oben vorgestellten vier Submodelle wurde eine Standardisierung in drei Stufen vorgenommen.! " # $ % & ' " " ( ) * Bild 6 Dreistufige Standardisierung im V-Modell Quelle: o. V. (1997), V-Modell: Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell: Kurzbeschreibung, S. 4 Für jedes der vier Submodelle sind Vorgehensweisen, Methoden und Werkzeuganforderungen festgelegt. 14

23 Vorgehensweise ( Was ist zu tun? ) Es erfolgt eine Festlegung der Tätigkeiten im Verlauf der Projektabwicklung. Methoden ( Methodenzuordnung ) 7 ( Wie ist etwas zu tun? ) Hier werden Vorschläge für die Verwendung von Methoden für die festgelegten Aktivitäten gemacht. Das V-Modell enthält für alle Aktivitäten im Entwicklungsprozeß eine Darstellung sämtlicher bekannter Methoden zur Durchführung der verschiedenen Tätigkeiten. Hierbei wird die Methode lediglich beschrieben. Eine Ausbildung in der Anwendung der Methode enthält das V-Modell nicht. Das V-Modell legt keine Entwicklungsmethode verbindlich fest. Insbesondere wird keine Methode der Programmierung oder gar eine Programmiersprache festgelegt. Das V-Modell ist methodenneutral. Werkzeuganforderungen ( Funktionale Werkzeuganforderungen ) 8 ( Womit ist etwas zu tun? ) Es wird festgelegt, welche funktionalen Eigenschaften die Werkzeuge haben müssen, die bei der Projektabwicklung eingesetzt werden. Es werden jedoch keine konkreten Werkzeuge festgelegt. Das V-Modell ist auch in dieser Hinsicht neutral. Die Methodenzuordnung und die Funktionalen Werkzeuganforderungen sind für den Bereich BMI nicht verbindlich Gliederung eines IT-Systems nach V-Modell Ein IT-System gliedert sich aus der Sicht des V-Modells in Segmente, wobei solche mit IT- Anteilen und solche ohne IT-Anteile unterschieden werden. Segmente mit IT-Anteilen bestehen wiederum aus Software-Einheiten und Hardware-Einheiten. Diese Einheiten sind elementare Objekte der Systemarchitektur. 7 vgl. o. V. (1997), AU 251 Entwicklungsstandard für IT-Systeme des Bundes: Methodenzuordnung, Neudruck Juni vgl. o. V. (1997), AU 252 Entwicklungsstandard für IT-Systeme des Bundes: Funktionale Werkzeuganforderungen, Neudruck Juni vgl. Bundesministerium des Innern (1997), Entwicklungsstandard für IT-Systeme des Bundes Vorgehensmodell (V-Modell), Teil 2 Behördenspezifische Ergänzungen, Stand Juni 1997, S

24 Software-Einheiten bestehen aus Modulen und Datenbanken. Hardware-Einheiten bestehen aus Hardware-Komponenten und Hardware-Modulen. Die Aufgliederung eines Systems ist hierarchisch. Hierbei müssen nicht zwingend alle Ebenen der Hierarchie vorhanden sein. Bild 7 stellt diesen Sachverhalt dar. Außerdem wird dargestellt, welche Entwicklungstätigkeiten durch das V-Modell beschrieben werden. IT-System System-Ebene Segment mit IT-Anteil Segment ohne IT-Anteil.. kann entfallen Segment- Ebene Segment mit IT-Anteil Segment ohne IT-Anteil SW-Einheit HW-Einheit SW-Einheits-/ HW-Einheits- Ebene SW-Komponente. kann entfallen HW-Komponente. kann entfallen Komponenten- Ebene SW-Komponente HW-Komponente SW-Modul Datenbank HW-Modul Modul-/ Datenbank- Ebene Entwicklung vollständig durch das V-Modell geregelt Entwicklung in Teil 3 Handbuchsammlung beschrieben (Handbuch Hardwareerstellung ) Bild 7 Gliederung eines IT-Systems nach V-Modell Quelle: o. V. (1997), AU 250/1 Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell: Teil 1 Regelungsteil, Juni 1997, S Einsatz des V-Modells in verschiedenen Organisationen Wie bereits dargestellt, sind die Regelungen im V-Modell unabhängig von der Organisation, in der es eingesetzt wird. Um dennoch eine Zuordnung der Aktivitäten und Aufgaben zu den 16

25 ausführenden Personen herzustellen, wurde das Rollenkonzept entworfen. Die durchzuführenden Aufgaben werden bestimmten Rolleninhabern zugeordnet. Die Qualifikation und das Aufgabenspektrum eines Rolleninhabers sind in der Beschreibung der Rollen festgelegt Weiterentwicklung und Pflege des Standards Eine erste Ausgabe des Standards V-Modell wurde 1992 veröffentlicht. Es liegt jetzt in seiner überarbeiteten Version von Juni 1997 vor. Die Weiterentwicklung des V-Modells wird öffentlich kontrolliert. Sie erfolgt durch eine jährlich tagende Änderungskonferenz mit Behörden und Industrievertretern. Auf diese Weise wird gewährleistet, daß die Anwender des V- Modells bei dessen Weiterentwicklung beteiligt werden. 2.8 Zweck des Standards Im Folgenden werden drei wichtige Aspekte der Verwendung des Standards dargestellt, um die Funktion des Standards zu verdeutlichen Vertragsgrundlage Als einer der größten Abnehmer von Softwareentwicklungen im gesamten Bundeshaushalt ist für das BWB (Bundesamt für Wehrtechnik und Beschaffung) eine einheitliche technische Regelung des Entwicklungsganges bei der Auftragsvergabe wichtig. Dies fällt um so mehr ins Gewicht, da es sich häufig um Spezialsoftware handelt, die konkret auf einen bisweilen einzigartigen Anwendungsbereich zugeschnitten ist. Deshalb wurde vom BWB das V-Modell entwickelt, um eine Vertragsgrundlage zu bilden. Das V-Modell fixiert eindeutig den Entwicklungsprozeß und den Lieferumfang des auszuliefernden Produktes. Insbesondere sorgt es dafür, daß die Dokumentation vollständig ist. Auf diesen Aspekt wird besonders viel Wert gelegt, da auf diese Weise Wartungsmaßnahmen an der Software unterstützt werden. Die Software soll sich lange einsetzen und stets den neuen Erfordernissen anpassen lassen. 10 vgl. o. V. (1997), AU 250/1 Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell: Teil 1 Regelungsteil; Juni 1997, S

26 Außerdem trägt die Anwendung des V-Modells dazu bei, die sichere Funktion der erstellten IT-Systeme zu gewährleisten. Dies ist besonders für die IT-Systeme wichtig, von deren fehlerfreien Funktion Menschenleben abhängen (z. B. Avionik-System eines Flugzeuges) Arbeitsanleitung Das Regelwerk des V-Modells dient als Arbeitsanleitung. Dies ist ein Vorzug, der auch bei Eigenentwicklungen von Vorteil ist. Vor der Durchführung des Projektes wird bei der Planung des Projektes aus dem generischen V-Modell ein projektspezifisches erstellt. Dies bedeutet u. a., daß, wie oben beschrieben, aus den im Regelwerk genannten möglichen Arbeitsschritten, die konkret für das Projekt benötigten Arbeitsschritte ausgewählt werden. Das V-Modell enthält eine detaillierte Beschreibung der Arbeitsschritte (Aktivitäten) und ihrer Ergebnisse, den Produkten. Diese Beschreibung ist möglichst universell gehalten, so daß sie von den konkreten Gegebenheiten eines spezifischen Projektes unabhängig ist und möglichst für alle Arten von Projekten sinnvoll verwendet werden kann. Es ist jedoch möglich und durchaus im Sinne des V-Modells bei der Planung des Projektes auf Basis dieser universellen Beschreibung der Aktivitäten eine spezielle Beschreibung der Aktivitäten für das konkrete Projekt zu erstellen. Die universelle Beschreibung stellt jedoch unabhängig von der Erstellung einer speziellen Beschreibung das Vorhandensein einer Anleitung sicher. Das V-Modell kann wie eine Checkliste für die Systemerstellung verwendet werden, um sicherzustellen, keine Aktivität vergessen oder unvollständig ausgeführt zu haben Kommunikationsbasis Ein nicht zu unterschätzender Vorzug des V-Modells ist die Festlegung einer einheitlichen Terminologie. Auf diese Weise wird die Kommunikation im Rahmen eines Entwicklungsprojektes erheblich verbessert. Die einzelnen Begriffe sind in ihrer Bedeutung (z. B. Anwenderforderung, Systemarchitektur, Softwareeinheit, Hardwareeinheit) festgelegt. Alle Beteiligten haben, so sie Kenntnisse über das V-Modell besitzen, eine gleiche Vorstellung vom Inhalt und Sinn der Begriffe. Neben dieser Wirkung als Kommunikationsbasis durch die Terminologiefestlegung erleichtert das V-Modell auch die Suche nach Informationen über ein konkretes IT-System. Es gibt ver- 18

27 bindlich vor, welche Information über das IT-System wo zu finden ist. Dies geschieht in erster Linie über die sog. Produktmuster. Produkte sind die Ergebnisse von Aktivitäten. Es sind häufig Dokumente. Durch Produktmuster wird festgelegt, wie die einzelnen Dokumente der Entwicklungsdokumentation zu gliedern sind. Dieser Vorzug macht sich vor allen Dingen bei der Wartung des Systems nach Abschluß dessen Entwicklung positiv bemerkbar. Mit Kenntnis des V-Modells können an der Entwicklung Unbeteiligte die für die Wartung notwendigen Informationen leicht auffinden. 2.9 Verbreitung und wirtschaftliche Bedeutung des V-Modells Das V-Modell wurde, wie oben dargestellt, zwar für die Belange der Bundeswehr bzw. Bundesverwaltung erstellt, ist aber nicht auf diesen Anwendungsbereich fixiert. Es ist völlig unabhängig von der Organisationsstruktur, in der es eingesetzt wird (z. B. durch das Rollenkonzept). Das V-Modell kann überall eingesetzt werden, wo Software bzw. IT-Systeme entwickelt werden. Seine Herkunft als Entwicklungsstandard für Projekte zur Entwicklung von Spezialsoftware ist allerdings unverkennbar. Die Anwendung des V-Modells unterliegt keinerlei Nutzungsrechten. Der Standard ist ohne Lizenzgebühr erhältlich. Es ist offenbar im Sinne des BWB, wenn das V-Modell weite Verbreitung findet, da somit bei der Auswahl von Vertragspartnern auf ein weit verbreitetes Know How zurückgegriffen werden kann. Es stehen auf diese Weise mehr potentielle Vertragspartner zur Verfügung, als wenn nur wenige Spezialanbieter die notwendigen Erfahrungen mit dem V-Modell hätten. Die einfache Verfügbarkeit wird auch durch die Tatsache unterstützt, daß das V-Modell auf CD erhältlich ist. Alle Teile des Standards sind auf dieser CD im WINWORD-Format vorhanden. Dies erleichtert die Arbeit mit dem V-Modell im Rahmen eines IT-Projektes enorm. Die notwendigen Bestandteile lassen sich leicht kopieren. Mit Hilfe der enthaltenen Beispiele und Muster wird die Erstellung eigener Dokumente erleichtert. Zusätzlich enthält die CD eine Vielzahl von Informationen über das V-Modell, sein Umfeld und über dessen Einsatz. Sie enthält außerdem eine multimediale Anleitung in der Anwendung des V-Modells. Industrieunternehmen sind im Rahmen der Zertifizierung nach ISO 900x gezwungen, eine Ablaufbeschreibung ihrer Entwicklungsprozesse zu erstellen. Das V-Modell ist eine solche Ablaufbeschreibung. Somit trägt die Anwendung des V-Modells als Werkstandard zur Zertifizierung nach ISO 900x bei. 19

28 Auf Grund der genannten Vorteile wird das V-Modell inzwischen in vielen Bereichen der Industrie, bei Banken und Versicherungen verwendet, bzw. dient als Vorlage für die Erstellung eigener Werksstandards zur IT-Systementwicklung Erörterung der Kritik am V-Modell Seit seiner Herausgabe wurde das V-Modell in der Fachliteratur und von Anwendern kritisch begutachtet. Dieses Kapitel enthält die Erörterung häufig genannter Kritikpunkte am V-Modell. Das Hauptaugenmerk der Kritik richtet sich auf den Umfang der durch den Standard geforderten Dokumentation eines Systems. Auch die Durchführung eines kleinen Projekts erfordert eine Auseinandersetzung mit einer auf den ersten Blick sehr großen Anzahl von Dokumenten. Somit liegt der Vorwurf auf der Hand, das V-Modell führe zu einer unnötigen Produktvielfalt und zu einer Software-Bürokratie. 12 Außerdem wird die große Vielzahl der Regelungen bemängelt. Dem V-Modell wird deshalb seine Eignung nur für Großprojekte zugesprochen. Der Kritik kann nur teilweise zugestimmt werden. Es ist zutreffend, daß der gewaltige Umfang des Standards und die Komplexität der Regelungen zunächst einmal abschrecken. Der Umfang ergibt sich offensichtlich auch daraus, daß die Ersteller des V-Modells umfangreiche Erläuterungen gewählt haben, um auch in der IT-Systementwicklung Unerfahrenen eine Anwendung des Standards zu ermöglichen. Die Erläuterungen finden sich vor allem in der Handbuchsammlung (Teil 3). Sie sind für Fachleute nicht in jedem Fall unbedingt erforderlich. Als eigentliche Standardisierung ist der Teil 1 des Standards (Regelungsteil) ausreichend. Ein Einbeziehen von Teil 2 (Behördenspezifische Ergänzungen) und Teil 3 (Handbuchsammlung) fördert jedoch das Verständnis für die richtige Anwendung des V-Modells. Außerdem neigen Mitarbeiter von Behörden dazu, das V-Modell als Vorschrift derart aufzufassen, daß alles gemacht werden muß, was im V-Modell steht. Es wird kein sachdienliches 11 vgl. Kaindl, H. et al. (1998), Methodik der Softwareentwicklung, Vorgehensmodell und State-of-the-Art der professionellen Praxis, Braunschweig Wiesbaden Balzert, H. (1998), Lehrbuch der Software-Technik: Software-Management Software-Qualitätssicherung Unternehmensmodellierung, Heidelberg Berlin 1998, S

29 Tailoring durchgeführt. Dies stellt auch Dröschel vom Bundesamt für Wehrtechnik und Beschaffung (BWB) fest: Durch eine zu formale Anwendung des Standards wurden leidvolle und kostenträchtige Wege eingeschlagen, die einen Lernprozeß beim Anwender des Standards bewirkt haben. 13 Ein solcher Mißbrauch des V-Modells führt aufgrund der Überdosis von Regelungen genauso zum Mißerfolg wie planloses, unstrukturiertes Vorgehen. Bei der Durchführung der Projektplanung nach den Vorgaben des V-Modells entsteht zu Beginn der Eindruck, daß die Regelungen des V-Modells zu komplex sind und zu viele Dokumente in Verlauf der Entwicklung erstellt werden müssen. Der Eindruck wird dadurch erweckt, daß vor Beginn der eigentlichen Systemerstellung am grünen Tisch eine Auseinandersetzung mit den allgemeingültigen, komplexen Regelungen des V-Modells stattfindet. Außerdem muß der Umfang der Dokumentation festgelegt werden. Bei der Betrachtung im nachhinein stellt sich oft heraus, daß alle Dokumente (die sog. Produkte) wohl begründet waren. Die Möglichkeit, die Projektplanung während der Durchführung des Projektes zu ändern, wird durch den Standard nicht eingeschränkt. Insofern ist ein Verzicht auf die Durchführung einer Aktivität und die Erstellung eines Produktes während des Verlaufes der IT-Systemerstellung jederzeit möglich. Ein weiterer damit zusammenhängender Aspekt ist die Behauptung, wegen der Komplexität sei das V-Modell nur mit CASE-Unterstützung zu handhaben 14. Zu dieser Kritik ist festzustellen, daß es jedoch gerade die Leistung des V-Modells ist, gezwungen zu werden, gleich am Anfang eines Projektes sinnvolle Festlegungen zu treffen und umfangreiche Überlegungen über den Projektverlauf anstellen zu müssen. Nur dies sichert eine Chance auf einen Projekterfolg. Das Tailoring des generischen V-Modells auf das spezifische Vorgehensmodell des Projektes, welches die Komplexität der Regelungen reduziert, ist sicherlich nicht in jedem Fall einfach durchzuführen. Ob dafür in jedem Falle ein CASE-Tool erforderlich ist, sei dahingestellt. 13 Dröschel, W. (1998), Die Gestaltung von IT-Systemen mit V-Modell 97: Zielsetzung und Kernpunkt der Änderungen, in: Dröschel, W. et al. (Hrsg.), Inkrementelle und objektorientierte Vorgehensweise mit dem V- Modell 97, München Wien 1998, S vgl. Balzert, H. (1998), Lehrbuch der Software-Technik: Software-Management Software-Qualitätssicherung Unternehmensmodellierung, Heidelberg Berlin 1998, S

30 Als weiterer Nachteil wird empfunden, daß für jedes Projekt immer eine eigenes V-Modell aus dem generischen maßgeschneidert werden muß, diese Arbeit also immer wieder anfällt. 15 Hinsichtlich solcher Kritik kann auf das Standardisierte Vortailoring für verschiedene Projekttypen und die im V-Modell enthaltenen Musterprojektbeschreibungen und -handbücher verwiesen werden. Es ist jedoch auch möglich, diesen Sachverhalt positiv zu bewerten: Es wird vermieden, daß die spezifischen Eigenheiten einzelner Projekte nicht hinreichend berücksichtigt werden. Ein weiterer Kritikpunkt ist der nationale Charakter des V-Modells. Bei Systementwicklungsprojekten auf multinationaler Ebene sind deshalb Vorbehalte gegen den Einsatz des V- Modells möglich. Dies betrifft z. B. Projekte auf europäischer Ebene. Die Beziehungen zu anderen Standards und der Vergleich mit diesen ist im V-Modell selbst beschrieben. 16 Dennoch wäre es wünschenswert, wenn das V-Modell auch ein Standard zumindest auf europäischer Ebene wäre. Der erste Schritt der Diplomarbeit, die überblicksartige Vorstellung des V-Modells ist mit dieser Erörterung der Kritik abgeschlossen. Im nun folgenden zweiten Schritt werden die verschiedenen Entwicklungsstrategien im Rahmen des Software Engineering untersucht. 15 vgl. Kaindl, H. et al. (1998), Methodik der Softwareentwicklung, Vorgehensmodell und State-of-the-Art der professionellen Praxis, Braunschweig Wiesbaden 1998, S vgl. o. V. (1997), AU 250/2 Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell: Teil 2 Behördenspezifische Ergänzungen, Juni 1997, S. 6-1 bis

31 3 Entwicklungsstrategien beim Software Engineering 3.1 Software-Engineering Bevor eine Auseinandersetzung mit den Entwicklungsstrategien beim Software Engineering stattfinden kann, muß der Begriff Software Engineering erläutert werden Historisches (Softwarekrise) Als Softwarekrise wird die Situation bezeichnet, die sich Ende der sechziger bis Anfang der siebziger Jahre ergab. Die inzwischen gestiegenen Ansprüche an die Leistungsfähigkeit der Software konnten mit den bis dahin gebräuchlichen Programmiertechniken nicht mehr realisiert werden. Häufig wird das bis dahin praktizierte Vorgehen bei der Erstellung von Software als Code and Fix bezeichnet. 17 Ohne nähere Spezifikation des zu erwartenden Ergebnisses wird Programmcode geschrieben. Danach wird versucht, die Fehler zu beseitigen. Die Krise wurde dadurch ausgelöst, daß die Leistungsfähigkeit der Hardware in rasantem Maße zunahm. Diese Leistungsfähigkeit sollte durch die Programmierer natürlich ausgenutzt werden - es wurden Software-Lösungen für immer komplexer werdende Systeme verlangt. In der Programmierung herrschte jedoch bis dahin eine laufzeiteffiziente und speicherplatzsparende Vorgehensweise vor. Noch bis zum heutigen Tage fließen in die Beurteilung von Algorithmen und Software diese beiden Kriterien mit ein. Sie waren durch die Hauptbeschränkungen der damaligen Zeit, nämlich knappen CPU- und Speicherplatzkapazitäten, auch gerechtfertigt. Das führte zu der sog. maschinennahen Programmierung. Sie war darauf ausgerichtet war, die knappen Maschinenressourcen optimal auszunutzen. Die Folge war eine trickreiche Programmierung, die nur für den Ersteller des Programmes zu durchschauen war. Häufig waren die Anforderungen an die Leistungen der Software auch so gering, daß die Programmierung der Lösung von einigen wenigen Personen in relativ kurzer Zeit vorgenommen werden konnte. Die gestiegenen Hardware-Möglichkeiten eröffneten den Weg zur Unterstützung von komplexeren Problemen durch Software. An der softwaretechnischen Lösung dieser Probleme wa- 17 vgl. Boehm, B. (1988), A Sprial Modell of Software Development and Enhancement, IEEE Computer May 1988, S. 61 und 62 23

Inhaltsverzeichnis. Seite 1 von 9

Inhaltsverzeichnis. Seite 1 von 9 Inhaltsverzeichnis Inhaltsverzeichnis... 1 1. Einführung... 2 1.1. Verwendungsarten... 2 1.2. Struktur des V-Modells... 3 2. Submodelle... 4 2.1. Projektmanagement (PM)... 4 2.2. Systemerstellung (SE)...

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Wiederholung Weitere Begriffe Programmierung im Großem (Programmierung von Software als Ganzes) Prozess-Modelle 2 Wiederholung: Prozesse Prozesse sind hierarchische Gruppierungen von

Mehr

13 Anhang A: Erfüllung der Norm ISO 9000 durch HERMES

13 Anhang A: Erfüllung der Norm ISO 9000 durch HERMES 13 Anhang A: Erfüllung der Norm ISO 9000 durch Hinweis Einleitung Eine der wesentlichsten Grundlagen für die Qualitätssicherung in einem Unternehmen ist die Normenserie «ISO 9000», insbesondere ISO 9001:1994

Mehr

Übungen Softwaretechnik I

Übungen Softwaretechnik I Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich Übungen Softwaretechnik I Übung 2: Vorgehensmodelle IAS-Vorgehensmodell Motivation Probleme Die

Mehr

Das neue V-Modell 200x ein modulares Vorgehensmodell

Das neue V-Modell 200x ein modulares Vorgehensmodell Das neue V-Modell 200x ein modulares Vorgehensmodell 28. April 2004 Perlen der Weisheit Ulrike Hammerschall Ausgangssituation und Zielsetzung Ausgangssituation des V-Modells Verbreitete Richtschnur für

Mehr

Software- Entwicklungsaktivitäten und Vorgehensmodelle. Lebenszyklusmodell

Software- Entwicklungsaktivitäten und Vorgehensmodelle. Lebenszyklusmodell 1. Vorgehensmodelle Software- Entwicklungsaktivitäten und Vorgehensmodelle a) Lebenszyklusmodell (Life- Cycle- Modell) b) V- Modell c) Wasserfallmodell d) Modifiziertes Wasserfallmodell e) Iterative Modelle

Mehr

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

Eine Tour durch das V-Modell 200x

Eine Tour durch das V-Modell 200x Eine Tour durch das V-Modell 200x WEIT Weiterentwicklung des Entwicklungsstandards für IT- Systeme des Bundes auf Basis des V-Modell-97 Stand der Arbeiten Workshop Softwareprozesse in Luft- und Raumfahrtprojekten

Mehr

Was versteht man unter einem Softwareentwicklungsmodell?

Was versteht man unter einem Softwareentwicklungsmodell? Softwareentwicklung Was versteht man unter einem Softwareentwicklungsmodell? Ein Softwareentwicklungsmodell ist ein für die Softwareentwicklung angepasstes Vorgehensmodell bei der professionellen ( ingenieursmäßigen

Mehr

PRINCE2 TAG 2011. PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr. Peter Morwinski, Leiter Technologie Center

PRINCE2 TAG 2011. PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr. Peter Morwinski, Leiter Technologie Center Ihr starker IT-Partner. Heute und morgen PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr PRINCE2 TAG 2011 Peter Morwinski, Leiter Technologie Center INHALT PRINCE2 und V-Modell XT Einleitung

Mehr

Das Wasserfallmodell - Überblick

Das Wasserfallmodell - Überblick Das Wasserfallmodell - Überblick Das Wasserfallmodell - Beschreibung Merkmale des Wasserfallmodells: Erweiterung des Phasenmodells Rückkopplungen zwischen den (benachbarten) Phasen sind möglich Ziel: Verminderung

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

Software Engineering. 3. Analyse und Anforderungsmanagement

Software Engineering. 3. Analyse und Anforderungsmanagement Software Engineering 3. Analyse und Anforderungsmanagement Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz

Mehr

Informationssystemanalyse V-Modell 4 1

Informationssystemanalyse V-Modell 4 1 Informationssystemanalyse V-Modell 4 1 Das V-Modell Das V-Modell ist Bestandteil des Standardisierungskonzepts der Bundesbehörden. Dieses Konzept hat folgende Eigenschaften: Slide 1 verbindlich für IT-Vorhaben

Mehr

2 Einführung in das V-Modell XT

2 Einführung in das V-Modell XT Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr 2 Einführung in das V-Modell XT V-Modell XT Anwendung im Projekt

Mehr

1 Phase «Initialisierung»

1 Phase «Initialisierung» 1.1 Übersicht Projektanmeldung Projektportfolio Projektrandbedingungen Projekt vorbereiten Projektantrag Projekthandbuch Projektplan Zurückweisung Projektauftrag Projektportfolio Status Abbruch Phase Voranalyse

Mehr

Software Engineering

Software Engineering Software Engineering Grundlagen, Menschen, Prozesse, Techniken von Jochen Ludewig, Horst Lichter 1. Auflage Software Engineering Ludewig / Lichter schnell und portofrei erhältlich bei beck-shop.de DIE

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Wirtschaftsinformatik I Teil 2. Sommersemester 2008. 1. Übung

Wirtschaftsinformatik I Teil 2. Sommersemester 2008. 1. Übung Wirtschaftsinformatik I Teil 2 Sommersemester 2008 1. Übung Sarah Mund, Kirstin Simon, Markus Trierweiler, Christian Molitor, Jonathan Jäger, Björn Kirsten Aufgabenstellung Diskutieren Sie die Vor- und

Mehr

6 Vorgehensbausteine. <Datum> <Organisation> <Veranstaltungsort> <Vortragender> <Organisation>

6 Vorgehensbausteine. <Datum> <Organisation> <Veranstaltungsort> <Vortragender> <Organisation> Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr 6 Vorgehensbausteine 1.2.1 Copyright V-Modell XT Das

Mehr

Maintenance & Re-Zertifizierung

Maintenance & Re-Zertifizierung Zertifizierung nach Technischen Richtlinien Maintenance & Re-Zertifizierung Version 1.2 vom 15.06.2009 Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 22899 9582-0

Mehr

Wirtschaftsingenieurwesen (Informationstechnik) Modulname. Programmierung II / Software Engineering II Modulnummer

Wirtschaftsingenieurwesen (Informationstechnik) Modulname. Programmierung II / Software Engineering II Modulnummer Modulbeschreibung Programmierung II / Software Engineering II Modulname Programmierung II / Software Engineering II Modulnummer -1.2 Inhalt Programmierung II Software Engineering II Grundlagen der objektorientierten

Mehr

There s more to V than just SE! oder. Perlen der Weisheit Bernhard Schätz. Was Sie schon immer über den Allgemeinen Umdruck 250/01 wissen

There s more to V than just SE! oder. Perlen der Weisheit Bernhard Schätz. Was Sie schon immer über den Allgemeinen Umdruck 250/01 wissen There s more to V than just SE! oder Was Sie schon immer über den Allgemeinen Umdruck 250/01 wissen wollten, aber sich nicht zu fragen getraut haben... Perlen der Weisheit Bernhard Schätz Allgemeines Formales:

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

Übung Einführung in die Softwaretechnik

Übung Einführung in die Softwaretechnik Lehrstuhl für Informatik 3 RWTH Aachen Übung Einführung in die Softwaretechnik Lösungshinweise zum Übungsblatt 3 Aufgabe 6a) Welche Projekttypen gibt es, und wie ist deren Zusammenhang? Systementwicklung

Mehr

(Titel des Berichts)

(Titel des Berichts) (Titel des Berichts) Praxissemesterbericht von (Vorname Name) aus (Geburtsort) Matrikelnummer Anschrift Telefon HTW Aalen Hochschule für Technik und Wirtschaft Betreuender Professor Abgabetermin Angaben

Mehr

Einführung V-Modell XT. Das neue V-Modell XT Release 1.2 - Der Entwicklungsstandard für IT Systeme des Bundes

Einführung V-Modell XT. Das neue V-Modell XT Release 1.2 - Der Entwicklungsstandard für IT Systeme des Bundes Einführung V-Modell XT Das neue V-Modell XT Release 1.2 - Der Entwicklungsstandard für IT Systeme des Bundes 1 Inhalt RAN Motivation Herkunft und Ziele des V-Modell XT Struktur und Aufbau des V-Modell

Mehr

17 Architekturentwurf Vorgehen und Dokumentation

17 Architekturentwurf Vorgehen und Dokumentation 17 Architekturentwurf Vorgehen und Dokumentation 17.1 Einbettung Aber Erster Schritt der Lösung Wenn Anforderungsspezifikation vorliegt Vorgabe für Codierung Hierarchische Verzahnung von Anforderungen

Mehr

IT-Projekt-Management

IT-Projekt-Management IT-Projekt-Management email: vuongtheanh@netscape.net http: www.dr-vuong.de 2005 by, Bielefeld Seite 1 Vorgehensmodell 2005 by, Bielefeld Seite 2 Was ist ein Vorgehensmodell? Strukturbeschreibung über

Mehr

Professionelles Projektmanagement mit dem V - Modell XT

Professionelles Projektmanagement mit dem V - Modell XT Professionelles Projektmanagement mit dem V - Modell T Dr. Ingo Zank / IKMT (VT, 04/2007) V-Modell Release 1.2 Ein Seminar des IKMT - Institut für kreatives Management und Training Postfach 330145 14171

Mehr

Abschnitt 16: Objektorientiertes Design

Abschnitt 16: Objektorientiertes Design Abschnitt 16: Objektorientiertes Design 16. Objektorientiertes Design 16 Objektorientiertes Design Informatik 2 (SS 07) 610 Software-Entwicklung Zur Software-Entwicklung existiert eine Vielfalt von Vorgehensweisen

Mehr

Entwurf. Anwendungsbeginn E DIN EN 62304 (VDE 0750-101):2013-10. Anwendungsbeginn dieser Norm ist...

Entwurf. Anwendungsbeginn E DIN EN 62304 (VDE 0750-101):2013-10. Anwendungsbeginn dieser Norm ist... Anwendungsbeginn Anwendungsbeginn dieser Norm ist.... Inhalt Einführung... 13 1 Anwendungsbereich... 16 1.1 *Zweck... 16 1.2 *Anwendungsbereich... 16 1.3 Beziehung zu anderen Normen... 16 1.4 Einhaltung...

Mehr

V-Modell. Dipl. Wirtsch. Ing. Alexander Werth 11-1

V-Modell. Dipl. Wirtsch. Ing. Alexander Werth 11-1 V-Modell Dipl. Wirtsch. Ing. Alexander Werth Software Engineering 11-1 Was ist das V-Modell? Das V im V-Modell steht für Vorgehensmodell. Umfangreiches Dokument. Softwaretool zur Unterstützung. Vorgabe

Mehr

Software Engineering

Software Engineering Software Engineering Informatik II. 9. Software-Entwicklung Dokumentation Dipl.-Inform. Hartmut Petters Vorwort was ich noch zu sagen hätte... Basis dieser Vorlesung sind vor allem die folgenden Ausarbeitungen

Mehr

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger Software Engineering (Übungsblatt 2) Sommersemester 2012, Dr. Andreas Metzger Übungsblatt-Themen: Prinzip, Technik, Methode und Werkzeug; Arten von Wartung; Modularität (Kohäsion/ Kopplung); Inkrementelle

Mehr

PRÜFMODUL D UND CD. 1 Zweck. 2 Durchführung. 2.1 Allgemeines. 2.2 Antrag

PRÜFMODUL D UND CD. 1 Zweck. 2 Durchführung. 2.1 Allgemeines. 2.2 Antrag 1 Zweck PRÜFMODUL D UND CD Diese Anweisung dient als Basis für unsere Kunden zur Information des Ablaufes der folgenden EG-Prüfung nach folgenden Prüfmodulen: D CD Es beschreibt die Aufgabe der benannten

Mehr

Leseprobe. Joachim Drees, Conny Lang, Marita Schöps. Praxisleitfaden Projektmanagement. Tipps, Tools und Tricks aus der Praxis für die Praxis

Leseprobe. Joachim Drees, Conny Lang, Marita Schöps. Praxisleitfaden Projektmanagement. Tipps, Tools und Tricks aus der Praxis für die Praxis Leseprobe Joachim Drees, Conny Lang, Marita Schöps Praxisleitfaden Projektmanagement Tipps, Tools und Tricks aus der Praxis für die Praxis ISBN: 978-3-446-42183-7 Weitere Informationen oder Bestellungen

Mehr

SDD System Design Document

SDD System Design Document SDD Software Konstruktion WS01/02 Gruppe 4 1. Einleitung Das vorliegende Dokument richtet sich vor allem an die Entwickler, aber auch an den Kunden, der das enstehende System verwenden wird. Es soll einen

Mehr

16 Architekturentwurf Einführung und Überblick

16 Architekturentwurf Einführung und Überblick Teil III: Software-Architekturentwurf 16 Architekturentwurf Einführung und Überblick 16.1 Software entwerfen Warum? Beim Arbeiten im Kleinen nicht oder nur ansatzweise (Detailentwurf) Größere Software

Mehr

Software Engineering

Software Engineering Software Engineering Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik Prof. A. Müller, FH KL Software Engineering 2015 1 Inhalte Begrüßung Vorstellung, Übersicht Formales

Mehr

Projektmanagement V-Modell XT-konform gestalten

Projektmanagement V-Modell XT-konform gestalten Projektmanagement V-Modell XT-konform gestalten PMI Munich Chapter Meeting 20. März 2007 Dr. Marc Sihling 2007 4Soft GmbH Agenda Überblick V-Modell XT Projektinitialisierung Tailoring Rollenbelegung Projektplanung

Mehr

Interkulturelles Projektmanagement in internationalen Projekten am Beispiel von afghanischen Mitarbeitern. Bachelorarbeit

Interkulturelles Projektmanagement in internationalen Projekten am Beispiel von afghanischen Mitarbeitern. Bachelorarbeit Interkulturelles Projektmanagement in internationalen Projekten am Beispiel von afghanischen Mitarbeitern Bachelorarbeit zur Erlangung des akademischen Grades,,Bachelor of Science (B.Sc.) im Studiengang

Mehr

Functional Safety. Systems Engineering als Schlüsseldisziplin in Projekten mit funktionaler Sicherheit

Functional Safety. Systems Engineering als Schlüsseldisziplin in Projekten mit funktionaler Sicherheit Systems Engineering als Schlüsseldisziplin in Projekten mit funktionaler Sicherheit Mittelstraße 25/1 88471 Laupheim Fon: 07392-9393525 Fax: 07392-9393526 Mailto: tf@thomasfranzen.com Beispiele nicht sicherer

Mehr

Kapitel 2: Der Software-Entwicklungsprozess

Kapitel 2: Der Software-Entwicklungsprozess Wie konstruiert man Software? Kapitel 2: Der Software-Entwicklungsprozess SoPra 2008 Kap. 2: Der Software-Entwicklungsprozess (1/10) Der Software-Entwicklungs-Prozess Historisches 1960JJ adhoc Techniken

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

Die Softwareentwicklungsphasen!

Die Softwareentwicklungsphasen! Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.

Mehr

Auftragsprojekte von der Anfrage bis zur Abrechnung erfolgreich managen - Maßgeschneiderte Qualifizierung der Projekt- und Bauleiter -

Auftragsprojekte von der Anfrage bis zur Abrechnung erfolgreich managen - Maßgeschneiderte Qualifizierung der Projekt- und Bauleiter - Auftragsprojekte von der Anfrage bis zur Abrechnung erfolgreich managen - Maßgeschneiderte Qualifizierung der Projekt- und Bauleiter - FOCUS Team KG Besenbruchstraße 16 42285 Wuppertal Tel.: 0202 28394-0

Mehr

Die neue ISO 9001:2015 Neue Struktur

Die neue ISO 9001:2015 Neue Struktur Integrierte Managementsysteme Die neue ISO 9001:2015 Neue Struktur Inhalt Neue Struktur... 1 Die neue ISO 9001:2015... 1 Aktuelle Status der ISO 9001... 3 Änderungen zu erwarten... 3 Ziele der neuen ISO

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

Die vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante

Die vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante ISO 9001:2015 Die vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante Prozesse. Die ISO 9001 wurde grundlegend überarbeitet und modernisiert. Die neue Fassung ist seit dem

Mehr

Das V-Modell 97. Oldenbourg Verlag München Wien

Das V-Modell 97. Oldenbourg Verlag München Wien Das V-Modell 97 Der Standard für die Entwicklung von IT-Systemen mit Anleitung für den Praxiseinsatz herausgegeben von Wolfgang Dröschel und Manuela Wiemers Technische Universität Darmstadt Fachbereich

Mehr

15 Verwaltung von Anforderungen (Requirements Management)

15 Verwaltung von Anforderungen (Requirements Management) 15 Verwaltung von Anforderungen (Requirements Management) Was ist Requirements Management? Planung und Lenkung des RE-Prozesses Konfigurationsmanagement für Anforderungen Identifikation Änderungs- und

Mehr

Das Pflichtenheft. Dipl.- Ing. Dipl.-Informatiker Dieter Klapproth Ains A-Systemhaus GmbH Berlin

Das Pflichtenheft. Dipl.- Ing. Dipl.-Informatiker Dieter Klapproth Ains A-Systemhaus GmbH Berlin Fragestellungen: Warum reicht das Lastenheft nicht aus? Was kann ich mit dem Lastenheft machen? Was unterscheidet das Pflichtenheft vom Lastenheft? Was gehört zum Auftragsumfang einer Individualsoftware?

Mehr

Governance, Risk & Compliance für den Mittelstand

Governance, Risk & Compliance für den Mittelstand Governance, Risk & Compliance für den Mittelstand Die Bedeutung von Steuerungs- und Kontrollsystemen nimmt auch für Unternehmen aus dem Mittelstand ständig zu. Der Aufwand für eine effiziente und effektive

Mehr

5.3.2 Projektstrukturplan

5.3.2 Projektstrukturplan 5.3.2 Der ist eine der wichtigsten Planungs- und Controllingmethoden und das zentrale Kommunikationsinstrument im Projekt. Er bildet die Basis für sämtliche weitere Projektmanagement- Pläne sowie für die

Mehr

Prüfung nach Instandsetzung und Änderung und Wiederholungsprüfung Die neue DIN VDE 0701-0702 (VDE 0701-0702)

Prüfung nach Instandsetzung und Änderung und Wiederholungsprüfung Die neue DIN VDE 0701-0702 (VDE 0701-0702) Prüfung nach Instandsetzung und Änderung und Wiederholungsprüfung Die neue DIN VDE 0701-0702 (VDE 0701-0702) Dipl.-Ing./EUR Ing. Arno Bergmann DKE Deutsche Kommission Elektrotechnik, Elektronik Informationstechnik

Mehr

Lösungen zum Test objektorientierter Software

Lösungen zum Test objektorientierter Software Lösungen zum Test objektorientierter Software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14. März 2013 HOM/FHTeL Lösungen zum Test objektorientierter Software

Mehr

IGT-Richtlinie 01: Anforderungen an Smarthome-Systeme

IGT-Richtlinie 01: Anforderungen an Smarthome-Systeme Bewertungskriterien inklusive Vorlagen zur Unterscheidung der Funktionalität von Smarthome- Systemen aus Nutzersicht bzw. aus technischer Sicht. Version 03, August 2015 Prof. Dr. Michael Krödel IGT - Institut

Mehr

Datenschutzfreundliches Projektmanagement Sven Thomsen Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein

Datenschutzfreundliches Projektmanagement Sven Thomsen Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein Datenschutzfreundliches Projektmanagement Sven Thomsen Datenschutz Schleswig-Holstein Projekt? Definition Projekt: Vorhaben, das im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit

Mehr

Entwicklung und Dokumentation eines Klausurorganisationssystems mit Microsoft Access

Entwicklung und Dokumentation eines Klausurorganisationssystems mit Microsoft Access Informatik Werner Schehler Entwicklung und Dokumentation eines Klausurorganisationssystems mit Microsoft Access Diplomarbeit FACHHOCHSCHULE DORTMUND FACHBEREICH WIRTSCHAFT Studiengang Wirtschaft ENTWICKLUNG

Mehr

Software Engineering

Software Engineering Literatur Gliederung Software Engineering Herbert Kuchen Universität Münster Di+Fr 14:15-15:45, M2 Wintersemester 2009/2010 1 Literatur Gliederung Basis-Literatur H. Balzert: Lehrbuch der Software-Technik,

Mehr

IT-Projekte effektiv steuern durch Integration von Modellierung und ALM bzw. Änderungsmanagement

IT-Projekte effektiv steuern durch Integration von Modellierung und ALM bzw. Änderungsmanagement IT-Projekte effektiv steuern durch Integration von Modellierung und ALM bzw. Änderungsmanagement Basierend auf einem zentralen SOA-Projekt wird die Integration von Änderungsmanagement aus dem ApplicationLifeCycle

Mehr

Prozess-Modelle für die Softwareentwicklung

Prozess-Modelle für die Softwareentwicklung Prozess-Modelle für die Softwareentwicklung Prof. Dr. Andreas Spillner Institut für Informatik und Automation Hochschule Bremen Übersicht Softwareentwicklungs-Modelle Wasserfall-Modell Vorgehensmodell

Mehr

Software Engineering. 2. V-Modell XT

Software Engineering. 2. V-Modell XT Software Engineering 2. V-Modell XT Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz Implementierung Konfigurationsmanagement

Mehr

1. Grundbegriffe des Software-Engineering

1. Grundbegriffe des Software-Engineering 1. Grundbegriffe Software Engineering 1 1. Grundbegriffe des Software-Engineering Was ist Software-Engineering? (deutsch: Software-Technik) Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen

Mehr

Was ist Application Lifecycle Management?

Was ist Application Lifecycle Management? Was ist Application Lifecycle Management? Von David Chappell Gefördert durch die Microsoft Corporation 2010 Chappell & Associates David Chappell: Was ist Application Lifecycle Management? Seite 2 von 7

Mehr

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 3. Vorgehensmodelle Software Engineering Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 Agenda Agenda Übersicht V-Modell Rational Unified Process Extreme Programming Fazit, Literatur, Kontrollfragen

Mehr

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378 DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN Nr. 378 Umsetzung ausgewählter Supply-Chain-Operations-Reference-Metriken durch das

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Softwaretechnik (Allgemeine Informatik) Überblick

Softwaretechnik (Allgemeine Informatik) Überblick Softwaretechnik (Allgemeine Informatik) Überblick 1 Einführung und Überblick 2 Abstraktion 3 Objektorientiertes Vorgehensmodell 4 Methoden der Anforderungs- und Problembereichsanalyse 5 UML-Diagramme 6

Mehr

3.1 Zusammenstellung der Projektgruppe 35

3.1 Zusammenstellung der Projektgruppe 35 3.1 Zusammenstellung der Projektgruppe 35 die Planungen und vor allem Entscheidungsprozesse einzubeziehen Damit kommt unter Umständen eine beträchtliche Zahl von ProjektmitarbeiterInnen zusammen, die letztlich

Mehr

Qualitätsmanagement ISO 9001

Qualitätsmanagement ISO 9001 Qualitätsmanagement ISO 9001 Vorteile und Nutzen der Normenreihe in Ihrer Anwaltskanzlei Die Bedeutung der ISO 9001 Unternehmen befinden sich im Umbruch, traditionsreiche Produktionsstandorte werden aufgegeben,

Mehr

FACHARTIKEL 2013 Software Programmierung, Testing und Implementierung zum Stichtag mithilfe von PERM-Domänen

FACHARTIKEL 2013 Software Programmierung, Testing und Implementierung zum Stichtag mithilfe von PERM-Domänen FACHARTIKEL 2013 Software Programmierung, Testing und Implementierung zum Stichtag mithilfe von PERM-Domänen von Herbert Mittelbach Stichtage Von Herbert Mittelbach Stichtage haben stets eine besondere

Mehr

Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich. Softwaretechnik I

Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich. Softwaretechnik I Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich Softwaretechnik I Wintersemester 2015 / 2016 www.ias.uni-stuttgart.de/st1 st1@ias.uni-stuttgart.de

Mehr

Vorlesung Projekorganisation und Management Dr. Bernhard Schätz Leopold-Franzens Universität Innsbruck Sommersemester 2003 B.Schätz : Projektmanagement 1 Übersicht 1. Übersicht 2. Projektmanagement und

Mehr

Risikomanagement für IT-Projekte: Vergleich von Risiken und Methoden

Risikomanagement für IT-Projekte: Vergleich von Risiken und Methoden Sperrvermerk Risikomanagement für IT-Projekte: Vergleich von Risiken und Methoden Bachelorarbeit Zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle Diverse Grundlagen Dr. Karsten Tolle Vorgehensmodelle im Software Engineering Wasserfallmodell Rapid Prototyping Spiralmodell V-Modell Rational Unified Process extrem Programming Test Driven Development

Mehr

Datensicherung. Beschreibung der Datensicherung

Datensicherung. Beschreibung der Datensicherung Datensicherung Mit dem Datensicherungsprogramm können Sie Ihre persönlichen Daten problemlos Sichern. Es ist möglich eine komplette Datensicherung durchzuführen, aber auch nur die neuen und geänderten

Mehr

POCKET POWER. Projektmanagement. 3. Auflage

POCKET POWER. Projektmanagement. 3. Auflage POCKET POWER Projektmanagement 3. Auflage 3 Inhalt 1 Einleitung.................................... 5 2 Grundlagen des Projektmanagements................... 8 2.1 Projektdefinition..............................

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

Data Mining-Projekte

Data Mining-Projekte Data Mining-Projekte Data Mining-Projekte Data Mining stellt normalerweise kein ei nmaliges Projekt dar, welches Erkenntnisse liefert, die dann nur einmal verwendet werden, sondern es soll gewöhnlich ein

Mehr

Software Engineering. Dokumentation! Kapitel 21

Software Engineering. Dokumentation! Kapitel 21 Martin Glinz Thomas Fritz Software Engineering Kapitel 21 Dokumentation 2005-2013 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen Gebrauch gestattet;

Mehr

Ishikawa-Diagramm. 1 Fallbeispiel 2. 2 Was ist ein Ishikawa-Diagramm 2. 3 Vorgehen bei der Erstellung eines Ishikawa-Diagramms 2.

Ishikawa-Diagramm. 1 Fallbeispiel 2. 2 Was ist ein Ishikawa-Diagramm 2. 3 Vorgehen bei der Erstellung eines Ishikawa-Diagramms 2. Ishikawa-Diagramm 1 Fallbeispiel 2 2 Was ist ein Ishikawa-Diagramm 2 3 Vorgehen bei der Erstellung eines Ishikawa-Diagramms 2 4 Vorteile 5 5 Nachteile 5 6 Fazit 5 7 Literaturverzeichnis 6 1 Fallbeispiel

Mehr

Beuth Hochschule BEUTH HOCHSCHULE FÜR TECHNIK BERLIN University of Applied Sciences

Beuth Hochschule BEUTH HOCHSCHULE FÜR TECHNIK BERLIN University of Applied Sciences Beuth Hochschule BEUTH HOCHSCHULE FÜR TECHNIK BERLIN University of Applied Sciences WISSENSCHAFTLICHE WEITERBILDUNG Fernstudium Industrial Engineering Produktions- und Betriebstechnik Kurseinheit 98 und

Mehr

17 Überblick über die restlichen Vorgehensbausteine

17 Überblick über die restlichen Vorgehensbausteine Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr 17 Überblick über die restlichen Vorgehensbausteine V-Modell XT Anwendung im Projekt

Mehr

<thema> Projektdokumentation zum Softwareentwicklungsprojekt. (Entwicklerdokumentation) 28. Mai 2015

<thema> Projektdokumentation zum Softwareentwicklungsprojekt. (Entwicklerdokumentation) 28. Mai 2015 Projektdokumentation zum Softwareentwicklungsprojekt (Entwicklerdokumentation) Lehrveranstaltung Software Engineering I / II 28. Mai 2015 Entwickler: , , Auftraggeber:

Mehr

Projektmanagement im Rundfunk

Projektmanagement im Rundfunk Thesen für ein senderspezifisches Vorgehensmodell Medienberatung Klaus Petersen Nürnberg, Juli 2005 KLAUS PETERSEN Einleitung und Übersicht Erfolgreiche Projekte sind für die konvergente Entwicklung in

Mehr

Software Engineering. Prof. Dr. Stefan Enderle NTA Isny

Software Engineering. Prof. Dr. Stefan Enderle NTA Isny Software Engineering Prof. Dr. Stefan Enderle NTA Isny 3 Software Entwicklungsprozesse Softwareentwicklung Systematisches Vorgehen wichtig Zeitlicher Ablauf durch Vorgehensmodell Meist grundlegender Aufbau:

Mehr

Leseprobe. Mit Projekten Unternehmen erfolgreich führen. KNo W- HoW. Studie. Ergebnisbericht. Ronald Gleich. Reinhard Wagner.

Leseprobe. Mit Projekten Unternehmen erfolgreich führen. KNo W- HoW. Studie. Ergebnisbericht. Ronald Gleich. Reinhard Wagner. KNo W- HoW Studie Mit Projekten Unternehmen erfolgreich führen Ergebnisbericht Leseprobe Ronald Gleich Reinhard Wagner Andreas Wald Christoph Schneider Arnd Görner INHALTSVERZEICHNIS Vorwort 4 Einleitung

Mehr

The Software Quality Challenge

The Software Quality Challenge The Software Quality Challenge Stanislav Michel Otto-von-Guericke-Universität Magdeburg Gliederung 1. Einleitung 2. Fehlerbeseitigung Probleme 3. Erfolgreiche Qualitätsstrategien 4. Grundsätze der Softwarequalität

Mehr

Einführung und Motivation

Einführung und Motivation Einführung und Motivation iks-thementag: Requirements Engineering 16.11.2010 Autor Carsten Schädel Motto Definiere oder Du wirst definiert. Seite 3 / 51 These Im Privatleben definiert jeder (seine) Anforderungen.

Mehr

Aktuelle Produktinfo Nr. 18 Seite 1

Aktuelle Produktinfo Nr. 18 Seite 1 Seite 1 Rheine, 30.10.2014 Sehr geehrte Damen und Herren, liebe Kolleginnen und Kollegen, aktuell steht auf unserer Homepage www.kubass.de ein Update für die neueste KuBAss Version 1.3.31 zum Download

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

Standard Inhaltsverzeichnis für Testvorschrift

Standard Inhaltsverzeichnis für Testvorschrift Standard Inhaltsverzeichnis für Testvorschrift Inhaltsverzeichnis 1. Zweck, Veranlassung... 1 2. Allgemeines... 1 2.1 Zweck der Testvorschrift... 1 2.2 Freigabe und Änderungen... 1 2.3 Prinzipien... 2

Mehr

Ganzheitliches IT-Projektmanagement

Ganzheitliches IT-Projektmanagement Ganzheitliches IT-Projektmanagement Kapitel 2 nach dem Buch: Ruf, Walter; Fittkau, Thomas: "Ganzheitliches IT-Projektmanagement" Wissen - Praxis - Anwendungen R. Oldenbourg Verlag München - Wien 2008;

Mehr

Methoden-Tailoring zur Produkt- und

Methoden-Tailoring zur Produkt- und Methoden-Tailoring zur Produkt- und Dietmar Winkler, Stefan Biffl Vienna University of Technology Institute of Software Technology and Interactive Systems dietmar.winkler@qse.ifs.tuwien.ac.at http://qse.ifs.tuwien.ac.at

Mehr

GPP Projekte gemeinsam zum Erfolg führen

GPP Projekte gemeinsam zum Erfolg führen GPP Projekte gemeinsam zum Erfolg führen IT-Sicherheit Schaffen Sie dauerhaft wirksame IT-Sicherheit nach zivilen oder militärischen Standards wie der ISO 27001, dem BSI Grundschutz oder der ZDv 54/100.

Mehr

Dokumenten-Modelle im CMS CoreMedia

Dokumenten-Modelle im CMS CoreMedia Dokumenten-Modelle im CMS CoreMedia Einleitung Das Content Management System CoreMedia ist ein innovatives Produkt der Hamburger Firma CoreMedia, das hauptsächlich im Unternehmensbereich und für komplexe

Mehr

Realisierung der Anbindung an den Handelsplatz Koeln.de Leitfaden zur Projektplanung bei Lieferanten

Realisierung der Anbindung an den Handelsplatz Koeln.de Leitfaden zur Projektplanung bei Lieferanten Handelsplatz Köln.de Leitfaden zur Projektplanung bei en Realisierung der Anbindung an den Handelsplatz Koeln.de Leitfaden zur Projektplanung bei en Autor: Christoph Winkelhage Status: Version 1.0 Datum:

Mehr

Evaluation of Database Design and Reverse Engineering Tools for a Large Software System

Evaluation of Database Design and Reverse Engineering Tools for a Large Software System Evaluation of Database Design and Reverse Engineering Tools for a Large Software System Anne Thomas TU Dresden Dr. B. Demuth Pre Press GmbH (Dresden) T. Reuter Gliederung Einleitung Vorgehensweise Kontext

Mehr