Hochschule Fakultät Technologie und Management Informationsverarbeitung Ravensburg-Weingarten PT & TM Softwareentwicklung Inhaltsverzeichnis

Transkript

1 Inhaltsverzeichnis 8 SOFTWAREENTWICKLUNG IMMATERIELLE PRODUKTE SOFTWARE Definition von Software Kategorien von Software SOFTWARE ENGINEERING Entstehung und Definition des Software Engineering Vorgehensmodelle Systemerstellung im V-Modell XT PHASEN DER SOFTWAREENTWICKLUNG Anforderungsanalyse Spezifikation Systemspezifikation Spezifikationssprache Spezifikationstechnik Entwurf Sinnbilder und Ihre Anwendung Anwendungsbereich und Zweck Allgemeines Begriffe Bezeichnung Darstellungsarten Sinnbilder nach DIN Sinnbilder nach DIN Codierung / Implementierung Modultest Integration Systemtest Betrieb und Wartung SOFTWARE KOSTEN Entwicklungsaufwand und Kosten Fehlerkosten Software Lebenszyklus Kosten Planungskosten Entwicklungskosten Wartungskosten DV1_Kapitel_8.doc Seite 8-1 von 32 Rüdiger Siol

2 8 Softwareentwicklung DV I Kosten Entwicklung Wartung Flußdiagramme Pseudo-Code Sortieralgorithmus Algorithmen Softwareentwicklung Spezifikation Requirements-Engineering Zustandsdiagramme UML Entstehungsprozeß Entwicklungswerkzeuge Anwendungsbeispiel Lottozahlengenerator Aufgabenbeschreibung Lösungsvorschlag Implementierung Test Übersicht Prof. Dr. Wöllhaf Seite 3 10:55:46 DV1_Kapitel_8.doc Seite 8-2 von 32 Rüdiger Siol

3 8.1 Immaterielle Produkte 1 Das Ziel jeglicher Software Entwicklung ist immer ein Programm oder ein Softwaresystem; also ein Produkt, das entweder intern genutzt wird und von vorübergehender Bedeutung sein mag oder aber, das auf dem Markt verkauft werden soll. Hierzu einige Begriffe: o Angebotsprodukt: Produkt, das durch die Organisation dem Kunden (dem Markt) zum Kauf angeboten oder ihm als Besitz oder zur Benutzung zur Verfügung gestellt wird. o Dienstleistung: Immaterielles Produkt, das dem Zweck dient, unmittelbar den Zustand des Kunden zu verbessern. o Software: Immaterielles Produkt, bestehend aus geschriebenen oder anderweitig aufgezeichneten Informationen, wie etwa Rechnersoftware, Konstruktionsentwürfe, Sitzungsberichte, Verfahren. Angebotsprodukte Materielle Angebotsprodukte Immaterielle Angebotsprodukte A: Hardware Stückgüter B: Verfahrenstechnische Produkte (Massen und Endlosgüter) C: Software D: Dienstleistungen Beliebige Kombinationen aus A, B, C und D Kategorien von Angebotsprodukten (mit Kombinationen) 1 Masing; Handbuch Qualitätsmanagement; Carl Hanser Verlag München Wien (1994); 3-te Auflage; ISBN DV1_Kapitel_8.doc Seite 8-3 von 32 Rüdiger Siol

4 8.2 Software Definition von Software Bis vor kurzem war noch umstritten, ob Software überhaupt als ein Produkt betrachtet werden soll oder ob sie eher eine Dienstleistung darstellt. Heute wird Software generell als ein immaterielles Produkt angesehen. Vielfach versteht man unter Software Programme, die auf einer Hardware lauffähig sind und das so entstandene Computersystem zur Lösung verschiedener Aufgaben nutzbar machen. Diese Definition reicht jedoch im allgemeinen noch nicht aus: Die Entwicklung eines Programms erfordert, von der anfänglichen Definition der Anforderungen bis hin zum Laden des endgültigen Codes in den Computer, die Erstellung einer Reihe von Unterlagen wie Anforderungsdokumentation, Spezifikation, Entwurfsdokumentation, Programmtext (Quellcode) und Testdokumentation. Unter Software versteht man auch die Gesamtheit dieser Dokumente. Software besteht somit aus: - Maschinell gespeicherten Instruktionen (Programmen), - Vereinbarungen über Eigenschaften der zu verarbeitenden Daten, - Dokumenten, die zur Nutzung und Wartung erforderlich sind. Demgemäß werden Software und Softwareprodukt in DIN ISO 9000 Teil 3 folgendermaßen definiert: o Software: Geistiges Produkt, das aus Programmen, Verfahren und allen dazugehörigen Beschreibungen besteht, die zur Arbeit mit einem Datenverarbeitungssystem gehören. Software ist unabhängig von dem Medium, auf dem sie gespeichert ist. o Softwareprodukt: Vollständiger Satz von Computerprogrammen, Verfahren und dazugehörigen Beschreibungen und Daten, der zur Lieferung an den Anwender bestimmt ist. 2 Handbuch Qualitätsmanagement; Dr. Walter Masing; Carl Hanser Verlag München Wien 3.te Auflage Auszüge aus Kapitel 44 DV1_Kapitel_8.doc Seite 8-4 von 32 Rüdiger Siol

5 8.2.2 Kategorien von Software Es gibt verschiedene Möglichkeiten der Klassifikation von Software. In diesem Kapitel sollen folgende Kategorien betrachtet werden: - Anwendungssoftware 3 ist Software für den Anwender zur Lösung einer Arbeitsaufgabe. Man unterscheidet horizontale, d. h. branchenübergreifende und vertikale, d. h. branchenspezifische Anwendungssoftware. - Systemsoftware ist der Sammelbegriff für all diejenigen Programme, die den Betrieb einer EDV-Anlage und ein reibungsloses Zusammenspiel vorhandener Hardwarekomponenten ermöglichen sowie einen koordinierten Ablauf der Anwendungsprogramme sicherstellen. Kern der Systemsoftware 4 bildet das Betriebssystem. Zur Systemsoftware zählen darüber hinaus alle Programme und Werkzeuge (Tools) für die Entwicklung von Programmen wie Compiler, Interpreter, Linker, Testwerkzeuge, Debugger sowie Kommunikationssoftware. - Standardsoftware oder Standardanwendungssoftware sind Programme für Aufgabenstellungen, die in vielen Betrieben gleichartig auftreten und bei ihrer Entwicklung so allgemein gehalten sind, dass sie für einen breiten Anwenderkreis geeignet sind. Standardsoftware wird im allgemeinen in großen Stückzahlen vertrieben und kann vielfältige Vorteile bieten wie vergleichsweise geringe Anschaffungskosten, sofortige Verfügbarkeit, Ausgereiftheit, Praxisnähe, Einsatz fortschrittlicher Programmiermethoden. - Individualsoftware 5 ist das Gegenstück zur Standardsoftware und umfasst spezielle Anwendungen, d. h. Einzelentwicklungen, die auf einen individuellen Anwender bzw. ein bestimmtes Unternehmen zugeschnitten sind. - Steuerungssoftware 6 umfasst Programme zur Steuerung von Geräten, Anlagen und Prozessen, die oftmals in die zu steuernde Hardware eingebaut sind. Steuerungssoftware übernimmt vielfach sicherheitsrelevante Funktionen. 3 Siehe auch Kapitel 6 - Anwendersoftware 4 Siehe auch Kapitel 5 - Betriebssysteme 5 Z.B.: Selbst entwickelte Programme 6 Z.B.: Regelungstechnik, Mechatronik DV1_Kapitel_8.doc Seite 8-5 von 32 Rüdiger Siol

6 8.3 Software Engineering DV I Idee, Anforderung Lastenheft Pflichtenheft Design.. Implementierung Test Abnahme Entwicklungsphasen Entstehungsprozeß Entwicklungsmodelle Wasserfallmodell Iterative Entwicklung Rapid Prototyping Evolutionär code-and-fix Softwareentwicklung Software-Entstehungsprozeß Prof. Dr. Wöllhaf Seite 4 11:25:08 DV I Kosten Entwicklung Wartung Flußdiagramme Pseudo-Code Sortieralgorithmus Algorithmen Softwareentwicklung Spezifikation Requirements-Engineering Zustandsdiagramme UML Entstehungsprozeß Entwicklungswerkzeuge Anwendungsbeispiel Lottozahlengenerator Aufgabenbeschreibung Lösungsvorschlag Implementierung Test Übersicht Prof. Dr. Wöllhaf Seite 10 11:25:41 DV1_Kapitel_8.doc Seite 8-6 von 32 Rüdiger Siol

7 DV I Programm Problemlösung Aufgabe Übersetzer ( Compiler ) Algorithmus Entwerfen in grafischer Form Hardwareorientierte Maschinensprache problemorientierte Programmiersprache textuelle Beschreibung nach formalen Regeln Ablaufpläne Struktogramme Natürliche Sprache - nicht formal Vom Problem zum Programm Prof. Dr. Wöllhaf Seite 11 11:26:12 DV I Computer können nur solche Aufgaben lösen, deren Lösung sich als Algorithmus angeben läßt Algorithmen werden mit Hilfe von Programmiersprachen in eine computergerechte Form gebracht Wie sage ich es meinem Computer? Definition eines Algorithmus Prof. Dr. Wöllhaf Seite 12 11:26:24 DV1_Kapitel_8.doc Seite 8-7 von 32 Rüdiger Siol

8 8.3.1 Entstehung und Definition des Software Engineering Die Erkenntnisse aus der Softwarekrise und die Bemühungen zur Entwicklung einer verbesserten Programmiertechnologie fanden in der Forschung ihren ersten Niederschlag in zwei von der NATO veranstalteten Software Engineering-Konferenzen in Garmisch 1968 und Rom Auf diesen Konferenzen wurde darauf hingewiesen, dass Programme Industrieprodukte sind, und es wurde die Forderung erhoben, Softwareentwicklung als ingenieurmäßige Disziplin und weniger als kreative Kunstfertigkeit zu verstehen. Der Begriff Software Engineering wurde geprägt. Unter Software Engineering - im Deutschen manchmal auch Softwaretechnik genannt versteht man jenes Teilgebiet der Informatik, das die rationelle, wirtschaftliche und jederzeit kontrollierbare Herstellung großer Programmsysteme zum Inhalt hat, die dazu erforderlichen wissenschaftlichen Methoden erforscht und geeignete Werkzeuge entwickelt und zur Verfügung stellt. Die strikte Anwendung von Methoden des Software Engineering ist eine wesentliche Voraussetzung für ein effizientes Qualitätsmanagement von Software. Ein zentrales Ergebnis des Software Engineering ist die Entwicklung und Anwendung unterschiedlicher Vorgehensmodelle Vorgehensmodelle Mit der Einführung und Verwendung von Vorgehensmodellen bei der Softwareentwicklung wird neben einer klaren und systematischen Vorgehensweise die zeitliche und inhaltliche Strukturierung des Entwicklungsprozesses angestrebt. Durch Vorgehensmodelle wird der Prozess der Softwareentwicklung in aufeinander abgestimmte Phasen zerlegt, und für jede Phase werden Tätigkeiten und Ergebnisse festgelegt. Synonyme Begriffe für Vorgehensmodell sind Software- Lebenszyklus, Phasenmodell, Projektmodell und Prozeßmodell. Es gibt zahlreiche, sehr unterschiedliche Vorgehensmodelle: - Wasserfallmodell - V-Modell - Spiralmodell - Prototyping-Modell - Objektorientiertes Lebenszyklusmodell. Das klassische Wasserfallmodell ist nach wie vor das häufigst eingesetzte Modell und dient vielfach als Grundlage bei Ausschreibungen. Es bietet einen klaren Rahmen, definiert die wichtigsten Tätigkeiten des Softwareentwicklungsprozesses, grenzt diese ab und erleichtert somit die Projektplanung und Abschätzung der Entwicklungskosten. Die Phasen werden als abgeschlossene Einheiten aus Aktivitäten und Ergebnissen definiert und sequentiell durchlaufen. Das Ende einer Phase wird durch einen Meilenstein markiert, an dem geprüfte und bewertete Arbeitsergebnisse vorliegen. In Prozess-Normen werden häufig Reviews gefordert, bei denen Arbeitsergebnisse formell freigegeben werden. DV1_Kapitel_8.doc Seite 8-8 von 32 Rüdiger Siol

9 DV I Wasserfallmodell der Softwareentwicklung Prof. Dr. Wöllhaf Seite 5 09:40:50 Am Wasserfallmodell wird manchmal kritisiert, dass die strenge Trennung der einzelnen Phasen eine unzulässige Idealisierung darstelle, da sich die Tätigkeiten überlappen und die Wechselwirkungen zwischen den Phasen komplexer seien als durch das sequentielle Modell angezeigt. Das sequentielle Vorgehen hat auch den Nachteil, dass erst sehr spät greifbare Ergebnisse vorliegen. Änderungswünsche der Anwender können damit erst dann geäußert werden, wenn der zur Umsetzung erforderliche Aufwand bereits sehr hoch ist. DV I Iterierte Phasenmodell Prof. Dr. Wöllhaf Seite 6 11:27:31 DV1_Kapitel_8.doc Seite 8-9 von 32 Rüdiger Siol

10 DV I Modell der evolutionären Softwareentwicklung Prof. Dr. Wöllhaf Seite 7 11:27:49 DV1_Kapitel_8.doc Seite 8-10 von 32 Rüdiger Siol

11 Prototyping Modell An dieser Stelle bieten das Prototyping-Modell und auch das Spiralmodell wesentliche Vorteile. Zielsetzung bei diesen Vorgehensmodellen ist, dem Anwender bereits kurze Zeit nach Beginn des Entwicklungsprozesses einen Prototyp, d. h. eine Demonstrationsversion des zukünftigen Programms, vorführen zu können. Dadurch können Missverständnisse ausgeräumt und Änderungswünsche frühzeitig berücksichtigt werden. Durch Einsatz von Werkzeugen läßt sich die Entwicklung von Prototypen wesentlich beschleunigen (Rapid Prototyping). DV I Das V-Modell Prof. Dr. Wöllhaf Seite 9 11:28:16 DV1_Kapitel_8.doc Seite 8-11 von 32 Rüdiger Siol

12 V-Modell 7 Besondere Bedeutung für das Qualitätsmanagement hat das V-Modelle erlangt. Beim V- Modell stehen die eher konstruktiven Aktivitäten (linker Zweig des V) den prüfenden, d. h. verzifizierenden und validierenden Aktivitäten (rechter Zweig des V) gegenüber. Das Modell macht deutlich, dass Fehler auf derjenigen Abstraktionsstufe gefunden werden, auf der sie begangen werden. Da bei der Systementwicklung zunächst vom Ganzen (AufgabensteIlung) zum Detail (Code) vorgegangen (top down: linker Zweig) und danach vom Detail (Code) über Integration- und Testschritte zum Ganzen (Problemlösung) zurückgekehrt wird (bottom up: rechter Zweig), können in den Phasen des rechten Zweiges des V nur jene Fehler gefunden werden, die in der symmetrischen Phase des linken Zweiges des V entstanden sind. Daraus folgt, dass die frühen Fehler am längsten im System bleiben und somit weitaus am teuersten sind. Darum ist in den frühen Phasen fast jeder Aufwand gerechtfertigt, der dazu beiträgt, Fehler zu vermeiden oder zu beseitigen (siehe auch nächster Abschnitt). Mit Testen können sie aber erst spät entdeckt werden; das Mittel für die Früherkennung der Fehler sind die Reviews Systemerstellung im V-Modell XT Das V-Modell nach Boehm Testfälle Systemkonzeptvalidierung Betrieb Anforderungs definition Systemdurchführbarkeitskonzept Systemspezifikation Produktentwurf Komponenten entwurf Modulentwurf Codierung Testfälle Testfälle Testfälle Testfälle Anforderungsvalidierung Entwurfsvalidierung Testvalidierung Einzeltest Systemtest Akzeptanztest Integrationstest Pilotbetrieb Einführung Validierung Verifizierung Zeit (r.siol) FH_RV-Weingarten DV SS_ Entwicklungsstandard für IT-Systeme des Bundes (EStdIT) DV1_Kapitel_8.doc Seite 8-12 von 32 Rüdiger Siol

13 Erzeugnisstruktur und Systemstruktur IT-Projekte erfolgreich mit dem neuen V-Modell XT 31 DV1_Kapitel_8.doc Seite 8-13 von 32 Rüdiger Siol

14 Systementwicklung und Entscheidungspunkte Zerlegung in der Systementwicklung Anforderungen (Lastenheft) Gesamtsystemspezifikation (Pflichtenheft) Gefährdungs- und Systemsicherheitsanalyse Systemarchitektur Unterstützungssystemarchitektur Systemspezifikation Spezifikation log. Unterstützung Prüfspezifikation Systemelement Implementierungs-, Integrations- und Prüfkonzept System/Unterstützungssystem Prüfspezifikation Systemelement HW-Architektur und SW-Architektur HW-Spezifikation und SW-Spezifikation Logistisches Unterstützungskonzept Externe-Einheit-Spezifikation Projekt beauftragt Gesamtsystem System spezifiziert System, Segmente System entworfen Einheiten Feinentwurf abgeschlossen IT-Projekte erfolgreich mit dem neuen V-Modell XT 32 Entscheidungspunkte Entscheidungspunkte - Produkte Systementwicklung System integriert Abnahme erfolgt Gesamtsystem Lieferung durchgeführt System, Segmente Einheiten Systemelemente realisiert Prüfprotokoll Lieferung Abnahmeerklärung Prüfprotokoll Systemelement Lieferung Prüfprotokoll Systemelement System mit allen Segmenten Logistische Unterstützungsdokumentation Prüfprotokoll Systemelement HW-Einheiten SW-Einheiten Externe Einheiten IT-Projekte erfolgreich mit dem neuen V-Modell XT 33 DV1_Kapitel_8.doc Seite 8-14 von 32 Rüdiger Siol

15 8.4 Phasen der Softwareentwicklung Phasen der Softwareentwicklung und Nutzung Phase Anforderungsanalyse Spezifikation Entwurf Codierung / Implementierung Modultest Integration Systemtest Betrieb und Wartung Tätigkeit Klärung der Anforderungen (globale Ziele). Planung des Softwareprojekts: Auftraggeber, Bearbeiter, Aufwand, Termine. Dokumentation der Solleigenschaften des Softwareprodukts: Pflichtenheft. Dokumentation der Problemlösung. Modularisierung: Logische Gliederung der Funktionen und Daten. Festlegung der Schnittstellen der Module (unabhängig von einer Programmiersprache). Erstellen der Quelltexte in einer Programmiersprache. Fehlerbeseitigung durch den Vergleich von Sollund Ist- Eigenschaften der Programm-Module. Zusammenfügen der Module zum Gesamtsystem. Fehlerbeseitigung durch Vergleich von Soll- und Ist- Eigenschaften des Gesamtsystems. Nutzung des Softwareprodukts durch den Anwender: Fehlerbeseitigung und Pflege durch das Wartungsteam. DV I Struktur der systematischen Softwareentwicklung Prof. Dr. Wöllhaf Seite 8 11:31:31 DV1_Kapitel_8.doc Seite 8-15 von 32 Rüdiger Siol

16 8.4.1 Anforderungsanalyse Anforderungsanalysen bzw. Anwendungsanalysen werden in der Praxis üblicherweise von Benutzern und Informatikern gemeinsam durchgeführt. Die Benutzer sind die internen oder externen potentiellen Kunden die möglicherweise an einer Systemlösung interessiert sind und auch bereit sein werden, dafür Mittel bereitzustellen. Sofern eine Zielsetzung besteht, für die es derzeit noch keine handelsüblichen Systeme gibt ist diese Vorgehensweise erforderlich, dazu gehört: o Zusammenfassung aller Anforderungen. o Gliederung in Funktionsbereiche, das sind in diesem Falle Anforderungen an die Informationsverarbeitung. o Durchführbarkeitsstudien zur technischen, wirtschaftlichen und terminlichen Machbarkeit. o Prüfung, ob die erforderlichen Ressourcen verfügbar sind oder verfügbar gemacht werden können. o Zusammenfassung der Anforderungen, die als realisierbar und derer, die als nicht realisierbar eingestuft wurden. Das Ergebnis der Anforderungsanalyse wird in einem Dokument als Studie zur Machbarkeit (Realisierbarkeit) zusammengefasst. Auf dieser Basis ist gemeinsam mit dem Interessenten (Kunden, späteren Benutzer intern oder extern) zu prüfen, ob an einer Realisierung überhaupt noch Interesse besteht. Sofern das der Fall ist, werden die umzusetzenden Anforderungen in einem Dokument zusammengefasst und es wird auch dargestellt, wie die Erfüllung dieser Anforderungen überprüft wird. Die Art und Weise, wie diese Tests erfolgen sollen, ist bereits auf dieser Ebene verbindlich zu vereinbaren; d.h. man definiert die Validierung 8 des Systems. Hier ist es entscheidend die Sicht bzw. Vorstellung des Kunden vollständig erfasst zu haben; ihn aber gegebenenfalls darauf hinzuweisen, dass aus Systemtechnischen Gründen eventuell Tests zu erfolgen haben, deren Notwendigkeit er nicht erkannt hat. Diese Phase hat als Ergebnisse: o Studie zur Machbarkeit (Realisierbarkeitsstudie) o Zusammenfassung der Anforderungen o Eventuell weitere Dokumente wie Studien oder Forschungsberichte usw. Auf dieser Basis wird der Lieferant ein detailliertes Angebot ausarbeiten. 8 Validierung heißt, es wurden die Anforderungen erfüllt; es wurde also das gemacht, was der Kunde (Auftraggeber) wollte. Dies kann in einem Projekt ein sehr Zeit- und kostenintensiver Vorgang sein so z.b. wenn Langzeittests die Zuverlässigkeit und Robustheit des Systems nachweisen sollen. DV1_Kapitel_8.doc Seite 8-16 von 32 Rüdiger Siol

17 8.4.2 Spezifikation DV I Benutzerschnittstellen Requirement-Engineering Prof. Dr. Wöllhaf Seite 32 11:34:02 Besser formuliert ist das eine Anforderungsspezifikation (Requirement Specification). Der Lieferant erarbeitet eine sehr detaillierte Spezifikation auf deren Grundlage dann auch die zugehörige Systemspezifikation und Managementpläne erstellt werden können. Der Lieferant muss auf dieser Basis die Möglichkeit haben, ein vollständiges Angebot zu erstellen. Intern sollte bekannt sein, welche Toleranzen verfügbar sind; für alle Beteiligten, die für den Erfolg des Projektes verantwortlich sind und sein werden. Der Kunde (Benutzer, interner oder externer Auftraggeber) muss auf dieser Basis die Möglichkeit haben, einen eindeutig definierten Auftrag zu erteilen. Ergebnis dieser Phase: Die Anforderungsspezifikation (Requirement Specification). DV1_Kapitel_8.doc Seite 8-17 von 32 Rüdiger Siol

18 Systemspezifikation Die Systemspezifikation gehört zum Teilgebiet der Programmiermethodik; Programmierungstechnik; Systemanalyse bzw. specification. Man bezeichnet das auch als Systementwurfsbeschreibung. Spezifikation ist eine detaillierte Beschreibung der Teile des Ganzen und ihrer Eigenschaften bezüglich Größe, Qualität, Performance usw. sowie ihrer Beziehungen untereinander. Obwohl die Definition in dieser Allgemeinheit für alle Systeme gilt, wird die Spezifikation von Softwaresystemen noch enger gefasst. Im Wesentlichen geht es darum festzulegen o was ein System tun sollte, d.h. seine Funktionen; o worauf das System wirken sollte, d.h. seine Daten; o unter welchen Bedingungen das System arbeiten sollte, d.h. seine physische Umgebung und o welchen Einschränkungen das System unterliegen sollte, d.h. seine Grenzen. Bei der Entwicklung von Programmen geht man in der Regel aus von einem Pflichtenheft, in dem die zu erbringenden Leistungen in mehr oder weniger formalisierter Weise niedergelegt sind. Die Umsetzung des Pflichtenhefts in eine Form, von der man für die anschließende Programmierung ausgehen kann, ist die Aufstellung der Spezifikation. Die Spezifikation ist somit das Ergebnis der Entwurfsphase. Sie enthält die zu erbringenden Leistungen in einer DV-gerechten Form und ermöglicht eine anschließende Implementierung. Für die Spezifikation im strengen Sinne existieren wenige Werkzeuge. Fasst man den Begriff der Spezifikation weniger rigoros, so vermitteln weitere Methoden die Möglichkeiten des Spezifizierens. Daher werden in der Literatur auch vielfach Problembeschreibungssprachen (UML, PSL/PSA) und Datenbanksysteme mit hoher Sprachschnittstelle als Werkzeuge zur Spezifikation bezeichnet. Die Spezifikation bildet die Grundlage für Korrektheitsbeweise. DV I Softwaremodellierung mit UML Prof. Dr. Wöllhaf Seite 35 11:34:42 DV1_Kapitel_8.doc Seite 8-18 von 32 Rüdiger Siol

19 Spezifikationssprache Teilgebiet: Programmierungsmethodik specification language Die Hilfsmittel, mit denen ein System spezifiziert wird, nennt man Spezifikationssprache. Obwohl es keine Festlegungen gibt, in welcher Sprache, d.h. auch graphischer Darstellung, und auf welchem Niveau, d.h. DetailIierungsgrad, ein System beschrieben werden soll, gehen moderne Ansätze davon aus, dass ein System auf einem dem Benutzerdenken sehr nahen Niveau beschrieben werden sollte. So werden z.b. Dialogprogramme zur Wartung von Stammdateien durch bildhaftes Spezifizieren am Terminal erzeugt. Die Spezifikation der Bildschirmmaske dient dann einerseits zur Beschreibung und Dokumentation des Systems, andererseits als Ausgangspunkt für die automatische Generierung von Programmen. Ähnlich wird auch für Verarbeitungsprogramme und Reportprogramme verfahren. Allgemein gilt die Tendenz, dass nur noch angegeben wird, was getan werden soll und nicht mehr, wie das getan werden soll Spezifikationstechnik Teilgebiet: Programmierungsmethodik specification technique Notation zur Spezifikation von Systemen; formale Spezifikationstechniken beruhen meist auf der mathematischen Logik oder der Algebra und bieten neben einer Notation zur Spezifikation auch (Ansätze zu) Verfahren für die formale Auswertung (Vollständigkeit, Konsistenz) von Spezifikationen. DV1_Kapitel_8.doc Seite 8-19 von 32 Rüdiger Siol

20 8.4.3 Entwurf Der Entwurf oder das technische Konzept besteht aus allen formellen und informellen Dokumenten zur Beschreibung der Realisierung auf der Basis der verfügbaren technischen und wirtschaftlichen Möglichkeiten. Dazu gehören die Datenorganisation, die Programmstrukturen, die Schnittstellendokumente und das Design. In der Entwurfsphase wird pro Vorgang oder Objekt eine Grobentwurfsdokumentation und eine Feinentwurfsdokumentation erstellt. Der grobe und feine Datenentwurf beinhaltet: o Das Datenbankstrukturdiagramm o Die Dateibeschreibungen o Beschreibungen von Listen und Masken o Datenbeschreibungstabellen o Schlüsselverzeichnisse o Testdatenbeschreibungen Der grobe und feine Programmentwurf beinhaltet: o Prozessablaufdiagramm o Datenflussdiagramm o Programmbeschreibungen o Programmablaufplan je Modul o Modulschnittstellendiagramme o Modultestrahmen Sinnbilder und Ihre Anwendung Dies wird durch DIN (Deutsches Institut für Normung e.v.) unterstützt. Der Normenausschuß Informationssysteme (NI) hat u.a. die DIN bereitgestellt Anwendungsbereich und Zweck Zweck dieser Norm ist die einheitliche und anschauliche Darstellung von Aufgabenlösungen in der Informationsverarbeitung. Dazu legt diese Norm Sinnbilder und deren Anwendung zur Darstellung von Daten 1) und ihre Verarbeitung sowie von Datenträger- und Verarbeitungseinheiten und die Verknüpfung dieser Elemente fest. Nicht Gegenstand der Norm sind die Texte. die bei der Anwendung zur näheren Bezeichnung in die Sinnbilder eingetragen werden müssen. Die Sinnbilder sind nicht für Schaltpläne bestimmt. Nicht Gegenstand der Norm ist die Darstellung der Speicherungsform von Daten, wie sie z. 8. in Programmiersprachen vereinbart wird Allgemeines Diese Norm lässt unterschiedliche Darstellungsarten für Lösungen von Aufgaben der Informationsverarbeitung zu. Die Wahl der Darstellungsart hängt vom jeweiligen Zweck der Darstellung ab. In allen Darstellungsarten erfolgen die Aussagen mit Hilfe von Sinnbildern und erläuternden Texten. Dabei können mit Hilfe der Sinnbilder u. a. Reihenfolgen, Zugriffsmöglichkeiten und hierarchische Zuordnungen aufgezeigt werden. Die Verwendung der Sinnbilder lässt DV1_Kapitel_8.doc Seite 8-20 von 32 Rüdiger Siol

21 unterschiedliche Detaillierungsgrade der Darstellungen zu. Es ist möglich, dass ein Sinnbild einer groben Darstellung eine detaillierte Darstellung zusammenfasst. Der Detaillierungsgrad richtet sich nach dem Zweck der Darstellung. Die Grösse und Lage der Sinnbilder darf dem jeweiligen Anwendungsfall entsprechend gewählt werden, jedoch müssen die Sinnbilder in ihrem Charakter erkennbar bleiben. Es wird empfohlen, für das Zeichnen der Sinnbilder eine Schablone nach Beiblatt 1 zu DIN zu benutzen Begriffe Siehe DIN 44300, DIN 44302, DIN und DIN Bezeichnung Eine Darstellung, die den Bedingungen dieser Norm entspricht. wird z.b. wie folgt bezeichnet: Benennung Norm-Nummer Kennbuchstaben Programmablaufplan DIN PA DV1_Kapitel_8.doc Seite 8-21 von 32 Rüdiger Siol

22 Darstellungsarten 1 Datenflussplan (DF) Ein Datenflussplan 9 stellt Verarbeitungen und Daten sowie die Verbindungen zwischen beiden dar. Die Verbindungen stellen dabei die Zugriffsmöglichkeiten von Verarbeitungen auf Daten dar. 2 Programmablaufplan (PA) Ein Programmablaufplan,) stellt die Verarbeitungsfolgen in einem Programm I) dar. Die Verbindungen zeigen dabei die Reihenfolgen der Verarbeitungen auf. Daten werden nicht dargestellt. 3 Programmnetz (PN) Ein Programmnetz ist die Vereinigung von einem oder mehreren Programmablaufplänen mit einem oder mehreren Datenflussplänen. 4 Datennetz (DN) Ein Datennetz zeigt Daten mit ihren Verbindungen als mögliche Zugriffswege auf. Verarbeitungen werden nicht dargestellt. 5 Programmhierarchie (PH) Eine Programmhierarchie stellt die Über-/Unterordnungen von Verarbeitungen dar. Die Verbindungen sagen aus, ob eine Verarbeitung eine andere verwendet (in Richtung der Verbindung) bzw. in ihr verwendet wird (entgegen der Verbindungsrichtung). Daten und Verarbeitungsreihenfolgen werden nicht dargestellt. 6 Datenhierarchie (DH) Eine Datenhierarchie stellt die Zusammenfassung bzw. Unterteilung von Daten dar. Die Verbindungen sagen aus, welche Daten andere enthalten (in Richtung der Verbindung) bzw. in anderen Daten enthalten sind (entgegen der Verbindungsrichtung). Die Unterteilung muß nicht vollständig sein und drückt keine Reihenfolge der Anordnung aus. Verarbeitungen und Zugriffswege werden nicht dargestellt. 7 Konfigurationsplan (KP) Ein Konfigurationsplan stellt Verarbeitungseinheiten und Datenträgereinheiten mit ihren Verbindungen dar. Die Verbindungen zeigen die Datenübertragungswege. Jedes Sinnbild einer Verarbeitungseinheit oder Datenträgereinheit kann als Zusammenfassung zusammengehöriger Einheiten benutzt werden. Verarbeitungen und Daten werden nicht dargestellt. 9 Begriff siehe DIN DV1_Kapitel_8.doc Seite 8-22 von 32 Rüdiger Siol

23 Sinnbilder nach DIN DIN Sinnbilder Verarbeitung / Verarbeitungseinheiten Verarbeitungseinheit, allgemein (processing unit) Manuelle Verarbeitung (manual operation) Verzweigung (decision) DIN Sinnbilder Daten (Begriffe nach DIN ) Daten, allgemein (data) Maschinell zu verarbeitende Daten (data to be processed by machine) Manuell zu verarbeitende Daten (data to be processed by manual operation) (r.siol) FH_RV-Weingarten DV SS_ (r.siol) FH_RV-Weingarten DV SS_ Sinnbilder Verbindungen DIN Verbindung (line) Verarbeitungsfolge Zugriffsmöglichkeit Zugriffsweg Über-/Unterordnung Zusammenfassung / Unterteilung Datenübertragungsweg (communication link) (r.siol) FH_RV-Weingarten DV SS_ Sinnbilder Darstellungshilfen DIN Grenzstelle - zur Umwelt (terminator) (z.b. Beginn oder Ende einer Folge, Herkunft oder Verbleib von Daten) Verbindungsstelle (connector) Eine Verbindung kann durch eine Verbindungsstelle unterbrochen und an anderer Stelle derselben Darstellung mit einer Verbindungsstelle mit gleicher Innenbeschriftung fortgesetzt werden. (r.siol) FH_RV-Weingarten DV SS_ Sinnbilder Darstellungshilfen DIN Bemerkung (annotation) Mit diesem Sinnbild kann erläuternder Text jedem anderen Sinnbild dieser Norm zugeordnet werden. Die durchbrochene Linie zum erläuternden Sinnbild darf durch eine Volllinie ersetzt werden. (r.siol) FH_RV-Weingarten DV SS_ DV1_Kapitel_8.doc Seite 8-23 von 32 Rüdiger Siol

24 Sinnbilder nach DIN Sinnbilder für Struktogramme nach Nassi-Shneiderman DIN Struktogramme nach Nassi-Shneiderman G = Gemeinsamer Bedingungsteil B = Bedingung V = Verarbeitung N = Bezeichner des zu verlassenden umfassenden Sinnbildes n = natürliche Zahl größer oder gleich DIN Sinnbilder Verarbeitung allgemein process V Verarbeitung imperative V Block block (r.siol) FH_RV-Weingarten DV SS_ (r.siol) FH_RV-Weingarten DV SS_ DIN Sinnbilder Folge serial V1 Folge serial V B B DIN Sinnbilder V V Wiederholung Wiederholung mit vorausgegangener Bedingungsprüfung Wiederholung mit nachfolgender Bedingungsprüfung iterative pre-tested iteration post-tested iteration V Wiederholung ohne Bedingungsprüfung continuous iteration (r.siol) FH_RV-Weingarten DV SS_ (r.siol) FH_RV-Weingarten DV SS_ B V DIN Sinnbilder G Alternative bedingte Verarbeitung selective choice monadic selective B1 V1 G B2 V2 einfache Alternative dyadic selective B 1 G B i V 1 V i V n-1 V n B n mehrfache Alternative multiple exclusive selective (r.siol) FH_RV-Weingarten DV SS_ DV1_Kapitel_8.doc Seite 8-24 von 32 Rüdiger Siol

25 8.4.4 Codierung / Implementierung Unter Codierung wird an dieser Stelle die Niederschrift eines Programmes nach den Regeln einer formalen Programmiersprache, also z.b.: C, C++, Ada, Algol, Pascal u.a. verstanden. Codierung (Verschlüsselung) ist hier die Umwandlung einer natürlichen Sprache zur Beschreibung von Algorithmen in eine formale Sprache; da in der Regel höhere Sprachen (wie hier genannt) verwendet werden, ist dies für den Menschen (Anwender) noch lesbar und verständlich so gesehen also noch nicht wirklich verschlüsselt. Der Compiler erzeugt daraus Maschinencode, also Bitmuster die nur noch aus 0 oder 1 bestehen, zusammengefasst je Rechnerwort hexadezimal oder oktal dargestellt werden können, und nur noch dem Systemexperten des jeweiligen Rechnersystems verständlich sind. Man benutzt also eine Programmiersprache (programming language) um ein Programmprotokoll, also ein Quellprogramm, zu erzeugen. Für jeden der spezifizierten Module werden Quellprogramme erzeugt; das können auch einfach Datenlisten usw. sein. Vereinfachend spricht man auch von Programm wobei klar zu stellen ist, dass unter dem Begriff Programm auch ein komplettes Softwaresystem verstanden werden kann. Format von C - Programmen Programm in C #include <stdio.h> int main ( ) { printf ( Hello, World!\n ); } #include <stdio.h> int main ( ) { printf ( y = a * x * sin ( x )\n ); } (r.siol) FH_RV-Weingarten DV SS_ DV1_Kapitel_8.doc Seite 8-25 von 32 Rüdiger Siol

26 8.4.5 Modultest Ein Modul ist ein getrennt übersetzbares Programmstück, ein Unterprogramm, eine Funktion oder eine Prozedur jeweils zusammen mit den von ihm benutzten Daten. Ein Modul sollte separat getestet werden um sicher zu stellen, dass er alle Anforderungen erfüllt. Dazu sind Testhilfen bereitzustellen oder zu schaffen. Testverfahren, Testergebnisse und Testprotokolle sind besonders sorgfältig und so zu dokumentieren, dass sie jederzeit wiederholt ausführbar sind. Sie sind Bestandteil der Entwicklungsdokumentation Integration Ein System gliedert sich in Teilsysteme (Hardware, Software und Schnittstellen) die ihrerseits modular aufgebaut sind. Diese Module und Teilsysteme sind nun in einer systematischen Vorgehensweise aneinanderzufügen; es ist also eine Folge von Integrationsschritten erforderlich. Mit jedem Integrationsschritt wird ein höheres Komplexitätsniveau (Eine höhere Integrationsebene) erreicht. Je Integrationsniveau sind wiederum zugehörige Testverfahren bereitzustellen und anzuwenden. Dies ist ein iterativer Prozess der auch die Überarbeitung und Wiederholung von Modultests erforderlich machen kann. Diese Tests dienen dazu, nachzuweisen dass das Produkt entsprechend dem Stand der Technik richtig gemacht wurde; man bezeichnet das als Verifikation Systemtest Ein Systemtest soll nachweisen, dass das Produkt die gestellten (also vertraglich vereinbarten) Anforderungen erfüllt. Er beantwortet also die Frage, ob wir das richtige Produkt gemacht haben; man bezeichnet das als Validierung Betrieb und Wartung Unter Betrieb versteht man die produktiven Nutzungsphasen des entwickelten Systems. Sofern das System die vereinbarten Anforderungen Störungs- und Fehlerfrei erfüllt ist für die Software keine Wartung erforderlich, da sie keinem Verschleiß unterliegt; natürlich können Ausfälle in der Hardware auftreten. In der Praxis werden sich aus der Nutzung Änderungs- und Ergänzungswünsche ergeben deren Erfüllung als Wartung oder als Weiterentwicklung verstanden werden kann. Der Betrieb kann die Anpassung an geänderte Daten oder Schnittstellen erfordern. DV1_Kapitel_8.doc Seite 8-26 von 32 Rüdiger Siol

27 8.5 Software Kosten Entwicklungsaufwand und Kosten 11 Auch wenn das Schätzen extrem schwierig, eventuell sogar unmöglich ist; es hilft nichts, irgendwie braucht man Zahlen. Nachfolgend einige Betrachtungen, wie solche Zahlen entstehen. Hoffentlich wissen alle, worüber sie reden. Wer hat eigentlich die Frage Nennen Sie eine Zahl! gestellt? Handelt es sich um eine rein interne Entwicklung für den Betrieb oder hat man den Auftrag eines Kunden schon angenommen? Reden wir über fertig entwickelte und ausgereifte Produkte, die nur noch verkauft werden müssen oder über noch zu erbringende Entwicklungsleistungen? 10 Auszüge aus: Harry M. Sneed; Software Management; Verlagsgesellschaft Rudolf Müller GmbH Köln, 1987; ISBN sowie auch: Siegfried Vollmann; Aufwands Achätzung im Software Engineering; IWT Verlag 1. Auflage 1990; ISBN Siegfried Vollmann; Aufwandsschätzung im Software Engineering; IWT Verlag GmbH Vaterstetten bei München (1990); ISBN DV1_Kapitel_8.doc Seite 8-27 von 32 Rüdiger Siol

28 Schätzung in der EDV Während im technischen Bereich fast überall mit hohen Sicherheitsaufschlägen gearbeitet wird und etwa eine Betondecke auf eine Tragkraft ausgelegt wird, die einem Vielfachen von dem entspricht, was sie normalerweise tragen muss, wird bei EDV-Projekten, insbesondere wenn sie aufgrund des Preises gegen Konkurrenzangebote akquiriert wurden, oft unter sehr optimistischen Annahmen sehr knapp kalkuliert. Das hat zur Folge, dass zwar nur sehr selten Häuser einstürzen, aber sehr häufig EDV- Projekte die Kosten und Termine überziehen. So findet eine Untersuchung der Universität Köln heraus, dass nur 11 % der Projekte mit einem Aufwand von mehr als 10 Mannjahren eine Kostenüberschreitung von weniger als 25 % aufweisen. Auch Selig kommt in einer Befragung von Unternehmen zu ähnlichen Ergebnissen. Eine solche Aussage ist denn auch typisch für die Situation in der EDV insgesamt, die Liste der Großprojekte mit riesigen Kostenüberschreitungen ist lang. Die Gründe dafür sind relativ gut bekannt. So schreibt Brooks in seinem Buch vom Mythos des Mann-Monats: "Aus Zeitnot sind mehr Softwareprojekte schief gegangen als aus allen anderen Gründen zusammengenommen. Warum ist gerade dieser Umstand so häufig für ein Scheitern verantwortlich? o Erstens sind unsere Schätzmethoden nur kärglich ausgebildet. Schlimmer noch, sie spiegeln eine unausgesprochene Annahme wider, nämlich die, dass schon alles gut gehen werde. o Zweitens erliegen wir mit unseren Schätzmethoden dem Trugschluss, das Ausmaß der Anstrengungen mit dem Fortschritt zu verwechseln, indem wir die Annahme zugrunde legen, Arbeitszeit und Arbeitskräfte seien austauschbare Faktoren. o Drittens fehlt es Softwaremanagern oft an der höflichen Halsstarrigkeit..., weil wir unserer Schätzungen selber nicht sicher sind. o Viertens wird der Fortgang der Arbeiten schlecht überwacht. o Fünftens, wird eine Abweichung vom Zeitplan festgestellt, ist die normale (und traditionelle) Antwort darauf der Einsatz zusätzlicher Arbeitskräfte. Als versuche man ein Feuer mit Benzin zu löschen, wird dadurch alles nur noch schlimmer, viel schlimmer." Auch wenn diese Aussagen schon ca. 40 Jahre alt sind, gelten sie auch heute noch. Die ersten drei beziehen sich dabei auf die Schätzung, die letzten zwei auf die Projektabwicklung. Es kommen noch einige weitere Gründe hinzu. Der Wichtigste ist, dass jemand das Projekt machen will, einen Auftrag haben will, denn damit ist heute Erfolg verbunden. Ein Misserfolg des Projektes kommt dagegen erst später, auszubaden haben ihn häufig andere. Zumindest zum Zeitpunkt der Schätzung verstärkt das eine meist ohnehin schon optimistische Grundhaltung. Statt einer soliden Schätzung gibt es dann starke Sprüche. DV1_Kapitel_8.doc Seite 8-28 von 32 Rüdiger Siol

29 8.5.2 Fehlerkosten Entwicklungskosten umfassen alle Aufwendungen für die Herstellung von Software. Einen wesentlichen Anteil haben dabei die Fehlerkosten; sie sind die größten Kostentreiber. Die Kosten der Entdeckung und Behebung eines Fehlers steigen mit dem Abstand zwischen dem Zeitpunkt der Entstehung und dem Zeitpunkt der Entdeckung und Behebung extrem an. Beispiel: Fehlerkosten in Abhängigkeit von der Phase der Entdeckung Phase der Fehlerauffindung Fehlerkosten (z.b.: in ) Entwurfs-Review Implementierung / Entwicklungstest Systemtest Feldeinsatz Das nächste Beispiel zeigt, wo und zu welchem Anteil Fehler entstehen und wann sie erkannt werden. Die Prozentangaben sind natürlich grobe Schätzungen. Frühzeitige Fehlererkennung bewirkt enorme Einsparungen. Entstehung und Behebung von Softwarefehlern Anforder ungen Entwurf Implementierung 10% 40% 50% Fehlerstrom 3% 5% 7% 25% 50% 10% Anforderungs review Entwurfsreview Codereview Entwicklungstest Systemtest Feldeinsatz (r.siol) FH_RV-Weingarten DV SS_ Bei der Beurteilung des Entwicklungsaufwandes bis zur Auslieferung (ohne Wartung) wird die Phase der Codierung meist überschätzt: ihr Anteil an den Entwicklungskosten beläuft sich nämlich nur auf bis zu 20%. Der Aufwand für das Testen hingegen, der bis zu 50% betragen kann, wird oftmals unterschätzt. Die Integration mit einem Anteil von 30% wird oft vergessen. Betrachtet man jedoch den Gesamtaufwand der Softwareentwicklung über sämtliche Phasen des Softwarelebenszyklus, einschließlich der Nutzungsphase, so nimmt die Wartung mit ca. 60% den weitaus größten Teil in Anspruch, wobei dieser Anteil derzeit sogar noch wächst. DV1_Kapitel_8.doc Seite 8-29 von 32 Rüdiger Siol

30 8.5.3 Software Lebenszyklus Kosten entstehen durch o Planung o Entwicklung o Wartung von Softwaresystemen. Insgesamt spricht man vom Software Lebenszyklus (Software Life Cycle) und versucht die Kosten in diesem Rahmen darzustellen. Dabei ergibt sich folgendes Bild zur Software Kostenverteilung: Software Kostenverteilung 10% 30% 60% Planung Entwicklung Wartung Planungskosten Planungskosten sind die Kosten vor der eigentlichen Entwicklung. Denn schon allein die Voruntersuchung eines geplanten Systems kann je nach Systemgröße recht teuer sein; sollte aber nicht mehr als 10% der Entwicklungskosten betragen. Allerdings, wenn der Anwender nicht weiß, was er will oder wenn es Zielkonflikte gibt, kann der Anteil der Planungskosten überproportional hoch liegen, sogar bis zu 30% der Entwicklungskosten. In solchen Fällen ist eine ordnungsgemäße Kostenrechnungsführung kaum möglich. Daher sollten Projekte mit einem hohen Planungsaufwand in mehrere Projekte aufgeteilt werden. DV1_Kapitel_8.doc Seite 8-30 von 32 Rüdiger Siol

31 Entwicklungskosten Entwicklungskosten sind die Kosten, die während der Entwicklung eines Systems anfallen, d. h. von der Spezifikation bis zur Freigabe. Eentwicklungskosten Integrationstest 22% Anforderungs- Spezifikation 18% Entwurf 15% Modultest 24% Programmierung 21% Sie werden durch die Quantität und Qualität der Software sowie durch die Dauer der Entwicklung und die Produktivität der Entwickler bestimmt. Je kürzer die Laufzeit eines Projektes, um so höher die Kosten. Dieser Sachverhalt ist unter der Bezeichnung»Brooks'sches Gesetz«bekannt geworden. Nach Professor Brooks nimmt der Kommunikationsaufwand mit der Anzahl der Mitarbeiter zu, so dass die Produktivität des einzelnen immer geringer wird. Die Produktivität hängt also von der Anzahl der aufeinander angewiesenen Mitarbeiter ab. Dennoch nicht nur davon. Die Produktivität schwankt erheblich von Betrieb zu Betrieb, in Abhängigkeit von der Qualifikation der Mitarbeiter und der Güte der Entwicklungsumgebung. Der Test macht demnach bis zu 46% der Entwicklungskosten aus. Inwiefern der Einsatz moderner Methoden und Werkzeuge diese Aufwandsverteilung ändert, bleibt noch zu beweisen. Es liegen zu wenig Erfahrungen vor. Fest steht, dass ein großer Teil der Entwicklungskosten den Wartungskosten zugerechnet wird. DV1_Kapitel_8.doc Seite 8-31 von 32 Rüdiger Siol

32 Wartungskosten Wartungskosten sind alle Kosten, die nach der ersten Freigabe des Systems anfallen. Wartungskosten Erweiterung 40% Anpassung 20% Korrektur 25% Optimierung 15% Wartungskosten sind alle Kosten, die nach der ersten Freigabe des Systems anfallen. Sie betragen bis zu 67% der Life cycle-kosten. Um bei dem Beispiel von Entwicklungskosten zu bleiben, wären noch erforderlich, um das System am Leben zu erhalten. 40% der Wartungskosten sind in der Tat Weiterentwicklungskosten. Wenn man diese 40% von den abzieht, bleiben nur für die eigentliche Wartungs-Fehlerbehebung, Optimierung und Anpassung. Dagegen stiegen die Entwicklungskosten auf Damit gäbe es ein Verhältnis von 3:2 statt 1:2 zwischen Entwicklungs- und Wartungskosten. Dieses Verhältnis entspricht eher den Tatsachen. Es ist auch eine Ermessensfrage, wann Software-Systeme fertig sind. Die Frage lässt sich nur schwer beantworten. Komplexe interaktive Systeme sind an sich nie fertig. Sie werden ständig weiterentwickelt. Um so wichtiger wird es, nach der ersten Freigabe eines Systems die echten Wartungskosten von den Weiterentwicklungskosten zu trennen. Änderungen, Optimierungen und Korrekturen zu der bestehenden Software Komponente sind echte Wartungsaktivitäten. Die Erstellung neuer Komponenten - das sind Moduln, Datenkapseln oder Dokumente - sollten hingegen als Entwicklung zu Buche schlagen. Diese Betrachtungsweise ist für eine ordentliche Software-Kostenrechnung äußerst wichtig, da sonst die wahren Entwicklungskosten verschleiert würden. Ein Großteil der Entwicklung findet in den ersten Jahren nach der Freigabe eines Systems statt. Sie als Wartungskosten einzustufen, ist eine Verzerrung der Kostenrechnung. Die Planungskosten sind ebenso von den Entwicklungskosten zu trennen, weil man für sie keinen messbaren Gegenwert hat. Der Gegenwert der Entwicklungskosten ist der Code, auch wenn er nicht ohne weiteres brauchbar ist. Den Planungskosten steht das Know-how in den Köpfen der Planer gegenüber. DV1_Kapitel_8.doc Seite 8-32 von 32 Rüdiger Siol