MS SQL SERVER
Werbung
Softwareerstellung Softwareerstellung F. Steyer 1 Architektur 1.1 Architektur eines Anwendungssystems 1.2 Erweiterungen der Architektur 2 Vorgehensweise 2.1 Wasserfallmodell 2.2 V-Modell 2.3 Spiralmodell 2.4 Sägezahnmodell 2.5 Anwendungen mit Access 3 Pflichtenheft 3.1 Allgemeines 3.2 Fachliches Feinkonzept 3.3 DV-Grobkonzept 3.4 Beispielhafter Aufbau 4 Phasen 4.1 Phasenmodell 4.2 Vorschlag 4.3 Definition/Grobplanung 4.4 Entwurf/Feinplanung 4.5 Implementierung 4.6 Test/Abnahme 4.7 Einführung 4.8 Wartung/Pflege 5 Testen 5.1 Definitionen 5.2 Testspektrum 5.3 Teststrategien 5.4 Testaxiome 5.5 Drei Schritte bei der Implementierung 5.6 Versionskontrolle 5.7 Systemtestfälle 5.8 Prüfliste 5.9 Werkzeuge 6 Beurteilung 6.1 Prinzipien der Software-Entwicklung 6.2 Qualitätsmerkmale von Software TFH Berlin/Steyer Softwareerstellung 1 Architektur 1.1 Architektur eines Anwendungssystems Benutzeroberfläche Menüsystem Anwenderlogik Datenverwaltung TFH Berlin/Steyer 1-1 Softwareerstellung 1.2 Erweiterungen der Architektur Benutzeroberfläche Menüsystem Technik/ Aussenwelt Weiterverarbeitung/ Unternehmensmodell Anwenderlogik Datenverwaltung Es gibt vier Schnittstellen, die als Bibliotheken realisierbar sind: - message lib (Funktionen zum Lesen von der A/D-Karte) - database lib (Zugriffsfunktionen zur Datenbank) - screen_and_key lib (Darstellungs- und Eingabefunktionen) - export-/import lib (Übergabefunktionen vom/zum Unternehmensmodell) Im prozeduralen Steuerteil befindet sich eine Ereignisschleife. Im System selbst können mehrere Prozesse mit Prozesskommunikation laufen. TFH Berlin/Steyer 1-2 Softwareerstellung 2 Vorgehensweise 2.1 Wasserfallmodell Vorschlag Definition Entwurf Implementierung Test+Abnahme Einführung Wartung+Pflege Stichwort: Sequentielle Ausführung Ausgabe des Vorgängers = Eingabe des Nachfolgers 2.2 V-Modell Vorschlag Akzeptanz Definition Abnahmetest Entwurf Systemtest Implementierung Einzeltest Stichwort: Wichtigkeit des Testens TFH Berlin/Steyer 2-1 Softwareerstellung 2.2 Spiralmodell Test/Abnahme/Doku Vorschlag/Plan Implementierung Definition/Entwurf Stichwort: Stufenweise Erstellung 2.4 Sägezahnmodell Ergebnis Tätigkeit Prototyp Definition Einführung Prototyp Prototyp Prototyp Entwurf Implementierung Test+Abnahme Produkt Stichwort: Kundenfeedback TFH Berlin/Steyer 2-2 Softwareerstellung 2.3 Spiralmodell Vorschlag/Plan Test+Abnahme Definition Implementierung Entwurf Stichwort: Stufenweise Erstellung 2.4 Sägezahnmodell Ergebnis Tätigkeit Prototyp Definition Einführung Prototyp Prototyp Prototyp Entwurf Implementierung Test+Abnahme Produkt Stichwort: Kundenfeedback TFH Berlin/Steyer 2-2 Softwareerstellung 2.5 Anwendungen mit Access Was ist eine Microsoft ACCESS Anwendung ? - Eine Anwendung besteht aus Objekten (Tabellen, Abfragen, Formularen, Berichten, Makros und Modulen). - Objekte haben Eigenschaften, die man aufeinander einstellen kann. - Die Objekte einer Anwendung hängen zusammen. - Der Anschluss externer Bibliotheken ist möglich. Erstellen der Datenbasis: - Erstellen Sie die Tabellen und fügen Sie einige Beispieldatensätze zu jeder Tabelle hinzu. - Erstellen Sie eine Auswahlabfrage für Ihre Anwendung. Erstellen der informationellen Oberfläche: - Erstellen Sie Formulare auf der Basis der Auswahlabfragen. - Verbinden Sie die Elemente. Erstellen von Operationen (angebunden an der Oberfläche): - Fügen Sie alles hinzu, um die Formulare funktionsfähig zu machen. - Erstellen Sie ein zentrales Formular für jeden Funktionsbereich um hier die Hauptaufgaben durchführen. Unteraufgaben werden vom zentralen Formular aus durchgeführt. - Verbinden Sie alle Elemente. - Testen Sie die Formulare. Weitere Möglichkeiten: - Makro "Autoexec" zum Festlegen, wie die Anwendung gestartet wird - Makro "Tastenbelegung" zum Zuweisen von Befehlen zu Tastaturfolgen - Menü-Editor zum Erstellen benutzerdefinierter Menüleisten für Formulare - Trennen Sie evtl. die Tabellen der Anwendung von den anderen Anwendungsobjekten und plazieren Sie sie in eine eigene Datenbank, wenn z.B. die Anwendung an anderer Stelle auch installiert werden soll, wenn mehrere Benutzer parallel an denselben Daten arbeiten sollen, wenn die Daten auf einen Server plaziert werden sollen, wenn neue Anwendungsreleases installiert werden oder einfach, wenn das gesamte Anwendungssystem zu gross für eine Diskette wird. - Richten Sie Zugriffsrechte ein. TFH Berlin/Steyer 2-3 Softwareerstellung 3 Pflichtenheft 3.1 Allgemeines Zweck: - Klare Aufgabenvorgabe, schriftlich - Einwandfreie Dokumentation, als Unterlage Aufbau: - Keine langatmigen Beschreibungen - Klare Gliederung - Bedingungen und Anforderungen, Abnahmetestfälle - Einfacher Übergang von den Aufgaben zu den Verfahren und zu den Programmen - Austauschbare Blätter Eine Aufteilung in einen betriebswirtschaftlichen und einen DV-technischen Teil kann zweckmäsig sein, wenn Planung und Programmierung getrennt vorgenommen werden. Entstehung: - Die Programmierung darf erst beginnen, wenn ein bestimmter Reifegrad der Aufgabenstellung erreicht ist. - Änderungen sind für eine gewisse Zeit zu stoppen. - Änderungen müssen in Form von Austauschblättern des Pflichtenheftes kommen. Wesentliche Angaben (muss) Ergänzungen (soll) Hinweise (kann) 1. Zweck und Funktion des neuen Verfahrens 2. Beschreibung der Eingabedaten Datenstrukturen 3. Forderungen an das Verfahren/Programm - Genauigkeit - Wertebereiche - Sicherheit - Pflichtforderungen - Sonderfälle Lösungsweg Einsatztermin Einsatzumgebung ähnliche Verfahren Kompatibilität Mengengerüst Ausbaustufen Datenflusspläne 4. Beschreibung der Ausgabedaten Datenstrukturen TFH Berlin/Steyer interne Datenstrukturen 3-1 Softwareerstellung 3.2 Fachliches Feinkonzept 1 Gesamtproblematik 2 Beschreibung der Prozesse, der Prozessabläufe, der Prozessstruktur 3 Beschreibung der Daten, fachliches Speicherkonzept - Beschreibung der Datenströme (Name, Menge, Anfallzeit) - Datenlexikon (Name, Bedeutung, Herkunft+Verbleib, Format, Wertebereich, Risikoklasse für den Datenschutz) - Kriterien zur Wahl der Speichermedien (Volumen, Häufigkeit der Benutzung, Lebensdauer, Archivierung) 4 Schlüsselsysteme (Identifikations-, Informations-, Klassifikations-, Parallelschlüssel) 5 Anforderungen an die Belege (Erfassungsbelege) 6 Anforderungen an die Datenerfassung 7 Beschreibung der Auswertungen (Ausgaben) - Inhalt - Form (Listen-, Maskenlayout) - Träger (Papier, Bildschirm, Mikrofilm) - Häufigkeit 8 Organisatorische und technische Anforderungen (Dialogverfahren, Wiederanlauf, Benutzerberechtigung etc.) 9 Datensicherheits- und Datenschutzanforderungen - Kontrolle der Daten auf Plausibilität und Vollständigkeit - Zugriffsberechtigungskontrolle TFH Berlin/Steyer 3-2 Softwareerstellung 3.3 DV-Grobkonzept 1 Entwurf der DV-Lösung - Betriebsart (lokal, DFÜ, Stapel, Dialog etc.) - Betriebssystem (Responsezeit, Ein- oder Mehrplatzsystem etc.) - Verfahrensstruktur (hierarchischer Aufbau bis auf Modulebene) - Speicherkonzept (Speichermedien, Speicherform, Datenstrukturierung) - Beschreibung der Komponenten (Module) - Beschreibung der Funktionen - Daten- und Ablaufsicherheit (Schutzmechanismus, Wiederanlauf) - vorhandene Software (Schnittstellen, Anpassungsmodul) - Hardwarekonfiguration (Anzahl Band-/Plattengeräte, Typ/Grösse der CPU) 2 Ausbaustufen 3 Anforderungen an das Realisierungspersonal (Programmiererfahrung, BS-Kenntnisse, DB-Erfahrung) 4 Softwaretechnik (Entscheidungstabellen, normierte Programmierung, Generatortechnik, strukturierte Programmierung etc.) 5 Sonstige Anforderungen und Bedingungen - Simulationsprogramme, z.B. Eingabedaten - Restriktionen TFH Berlin/Steyer 3-3 Softwareerstellung 3.4 Beispielhafter Aufbau (1) Zielbestimmung (2) Grenzkriterien (muss) (3) Wunschkriterien (soll) (4) Abgrenzungskriterien (soll nicht) (5) Produkteinsatz (5.1) Anwendungsbereiche (5.2) Zielgruppen (6) Produktkonfiguration (6.1) Minimalkonfiguration (6.2) Empfohlene Konfiguration (7) Produktumgebung (7.1) Vorlagen (7.2) EBNF-Darstellung der Syntax der Vorlagedatei (7.3) Anschauliche Beschreibung des Aufbaus der Vorlage (7.4) Beispiel für eine Vorlagedatei (8) Produktfunktionen (8.1) Prüfungsvorlagen (8.1.1) Prüfungsvorlage aus Textvorlage erzeugen (8.1.2) Editor aufrufen (8.1.3) Drucken (8.1.4) Bearbeiten (8.2) Prüfungen (8.2.1) Prüfungen anlegen und bearbeiten (8.2.2) Ergebnisse erfassen (8.2.3) Ergebnisse bearbeiten (8.2.4) Löschen (8.3) Auswertung (8.3.1) Eine Prüfung (8.3.2) Alle Prüfungen (8.3.3) Auswahl (8.4) Personendaten (8.4.1) Prüflinge (8.4.2) Prüfer (9) Qualitätsanforderungen (9.1) Benutzerführung (9.2) Antwortzeitverhalten (9.2.1) Interaktive Prozesse (9.2.2) Statistische Auswertungen (9.3) Robustheit (9.4) Portabilität und Wartung (10) Benutzerschnittstelle (10.1) Benutzermodell (10.1.1) Prüfer (10.1.2) Verwaltung (10.1.3) Prüflinge TFH Berlin/Steyer 3-4 Softwareerstellung (11) Kommunikationsaufbau (11.1) Kommunikationsstrategie (11.2) Kommunikationsbeispiele (11.2.1) Programmaufruf (11.2.2) Menüstruktur (11.2.3) Dialoge des Systemmenüs (11.2.3.1) Konfigurieren (11.2.4) Dialoge des Menüs Vorlagen (11.2.4.1) Vorlage erzeugen (11.2.4.2) Vorlage bearbeiten (11.2.4.3) Vorlage drucken (11.2.5) Dialoge des Menüs Prüfungen (11.2.5.1) Prüfungen anlegen (11.2.5.2) Ergebnisse erfassen (11.2.5.3) Ergebnisse bearbeiten (11.2.5.4) Prüfungen löschen (11.2.6) Dialoge des Menüs Auswertungen (11.2.6.1) Einzelne Prüfung auswerten (11.2.6.2) Alle Prüfungen bearbeiten (11.2.6.3) Eine Auswahl von Prüfungen bearbeiten (11.2.7) Dialoge des optionalen Menüs Personendaten (11.2.7.1) Prüflinge bearbeiten (11.2.7.2) Prüferdaten (11.2.8) Reports (11.2.8.1) Statistische Auswertung einer Einzelprüfung (11.2.8.2) Statistische Auswertung mehrerer Prüfungen (ausgewählt und pauschal) (11.2.8.3) Prüfungsbogen (12) Globale Testfälle (12.1) Test-Vorlagedatei (13) Entwicklungskonfiguration TFH Berlin/Steyer 3-5 Softwareerstellung 4 Phasen 4.1 Phasenmodell Die Erstellung grosser Software bedarf eines planerischen und organisatorischen Rahmens. Diesen Rahmen bildet, vergleichbar mit anderen Ingenieurgrossprojekten, das Phasenmodell. Vorschlag Definition Entwurf Implementierung Test+Abnahme Einführung Wartung+Pflege Die strenge squentielle Anordnung aller Phasen ist kaum zu erreichen. Typischerweise verlaufen Phasen auch zeitlich überlappend oder zyklisch, wenn Fehler, Unstimmigkeiten oder neue Kundenwünsche auftreten. Vorschlag Definition ProjektLeitung/ Entwurf Kontrolle Implementierung Test+Abnahme Einführung Wartubg+Pflege TFH Berlin/Steyer 4-1 Softwareerstellung 4.2 Vorschlag Es werden zunächst Aufgabenstellung und Ziele angegeben. Dazu wird die prinzipielle Machbarkeit eines Produktes innerhalb eines vorgegebenen Zeit- und/oder Kostenrahmens geprüft. Neben der Prüfung der Machbarkeit wird das Produkt grob skizziert. Zum Abschluss der Vorschlagsphase steht eine begründete Aufgabe des Projektes und eine grobe Termin- und Kostenplanung. Das Ergebnis der Vorschlagsphase wird in einem Dokument (Projektvorschlag) schriftlich fixiert. Es wird entschieden, ob das Projekt durchgeführt wird. 4.3 Definition/Grobplanung In dieser Phase wird beschrieben, was das System aus Kundensicht idealerweise leisten soll. Die Systemanforderungen/-eigenschaften/-bedingungen werden hier genau, in einer dem Kunden verständlichen Form, präzisiert. Leistungsmerkmale des geplanten Systems, wie z.B. Kapazitäten, zeitliches Verhalten oder aber die Art des Herstellungsprozesses (z.B. zu verwendende Methoden, Programmiersprachen, Hardware) können hier in verifizierbarer Form festgelegt werden. Es wird festgelegt, welche Eigenschaften das erstellte System zur Abnahme haben muss, um erfolgreich die Systemabnahme passieren zu können. Es werden eine Ist-Aufnahme und eine Ist-Analyse durchgeführt um Schwachstellen im derzeitigen Zustand aufzudecken. Unterstützende Methoden wie Structured Analysis (SA), Structured Analysis and Design Technique (SADT), Petri-Netze, Objektorientierte Systementwicklung usw. werden hier eingesetzt und führen zu den gewünschten Darstellungen und Ergebnissen. Letztlich wird ein fachliches Grobkonzept erstellt. Es besteht aus einer Beschreibung des fachlichen Problems und einer Beschreibung der fachlichen Lösung sowie einer Wirtschaftlichkeitsberechnung. Hierbei soll auch der Einsatz evtl. schon vorhandener (Teil-)Lösungen berücksichtigt werden. 4.4 Entwurf/Feinplanung In der Entwurfsphase entsteht die Spezifizierung des Systems aus Entwicklersicht. Auch hier steht die Frage "Was leistet das System ?" im Vordergrund. Das Ergebnis der Entwurfsphase ist ein Dokument, das den Systementwurf in folgenden Details beschreibt: - Systemteile (Komponenten), in die das Gesamtsystem zerfällt (Modulstruktur, Modulhierarchie), - Spezifikation aller Systemteilanforderungen (Schnittstellenspezifikationen), - Nachweis, dass die in der Anforderungsdefinition formulierten Anforderungen im Entwurf berücksichtigt sind. Ergebnis der Planungsphasen ist das Pflichtenheft. Oft hat das Pflichtenheft Vertragscharakter und dient bei Streitigkeiten zwischen Entwickler und Kunde als rechtliche Grundlage. TFH Berlin/Steyer 4-2 Softwareerstellung 4.5 Implementierung Die Implementierungsphase führt zur Codierung aller Systemteile in einer konkreten Programmiersprache. Methoden und Werkzeuge der Strukturierten Programmierung im Grossen und Kleinen sind hier von Bedeutung. Wichtig ist die Zuordnung von Personen zu den Tätigkeiten der Systemerstellung, deren Schnittstellen und Verantwortlichkeiten. Ziel dieser Phase ist das programmierte und entsprechend dokumentierte System. Gefordert ist eine systematische und nachvollziehbare Realisierung des spezifizierten Entwurfs, der frei von genialen Tricks und persönlichem Stil (egoless) ist, schlichte und durchsichtige Lösungen bevorzugt und lediglich den Standard des Projektteams erkennen lässt. 4.6 Test/Abnahme In der Testphase soll bewiesen werden, dass die in der Definitionsphase definierten Anforderungen erfüllt wurden. Getestet wird üblicherweise zuerst komponentenweise (in Modulen), danach integrierend im Zusammenhang. Abschluss der Testphase bildet der Abnahmetest, der aus Kundensicht konstruierte Testfälle unter möglichst realen Bedingungen beim Kunden durchführt. Hier muss das Produkt den Nachweis erbringen, dass es die geforderten Eigenschaften besitzt. Alle Testergebnisse werden in einem Testprotokoll festgehalten. 4.7 Einführung Der Arbeitsablauf in den Anwenderabteilungen wird an das neue Verfahren angepasst. Hierfür müssen die betroffenen Mitarbeiter geschult und eingewiesen werden. Der Probebetrieb über einen längeren Zeitraum (parallel mit dem alten abzul”senden Verfahren mit Vergleich) schliesst das Projekt ab. 4.8 Wartung/Pflege Diese Phase ist die längste Phase im Software-Lebenszyklus. Sie beginnt nach der erfolgreichen Abnahme (Abnahmetest) des Produktes. Im Gegensatz zu anderen Phasen ist sie nur „usserst schwer planerisch zu beherrschen, da sie abhängig vom Auftreten unvorhersehbarer Ereignisse (Fehler, neue Anforderungen, ver„nderte Bedingungen usw.) ist. Die Wartungsphase stellt einen bedeutenden Kostenfaktor dar. Untersuchungen zeigen, dass die Wartungskosten in ungüstigen Fällen (schlechte Wartbarkeit) oder in güstigen Fälen (lange Lebensdauer) das Zehnfache der eigentlichen Entwicklungskosten ausmachen k”nnen. TFH Berlin/Steyer 4-3 Softwareerstellung 4.9 Projektmanagement Softwareprojekte zeichnen sich besonders dadurch aus, dass Kosten- und Terminplanungen extrem überschritten werden. Gründe hierfür liegen darin, dass - Software ein immaterielles und damit ein abstraktes Produkt ist, - Anforderungsdefinitionen zu unpräzise sind und zu offen für Kundenwünsche, die sich während der Entwicklung ändern, - die Arbeitsleistung von Programmierern extrem unterschiedlich sein kann (Untersuchen zeigen Faktoren bis zu 1:25), - Projektmanager im Softwarebereich meist geringere Erfahrungen haben als Manager aus vergleichbaren Ingenieurprojekten, - Organisations- und Planungsmethoden nur allmählich Eingang in Softwareprojekte finden. Die Notwendigkeit eines qualifizierten Projektmanagements liegt deshalb auf der Hand. Nicht jeder gute Programmierer oder Informatiker ist automatisch ein guter Projektmanager, muss es auch nicht sein. Hierzu bedarf es besonderer/anderer Fähigkeiten. Ein ebenso wichtiger Aspekt ist die Tatsache, dass ein Projektteam aus Menschen besteht. Diese Menschen sollen plan- und termingerecht eine kreative geistige Tätigkeit vollbringen, die sich nur beschränkt erzwingen lässt. Durch eine bewusste Projektleitung kann aber Einfluss genommen werden auf die Gesamtheit der Arbeitsbedingungen. Dazu gehören Faktoren, die zur Zufriedenheit der Mitarbeiter und der Identifikation mit dem erstellten Produkt (Wir-Gefühl) beitragen, wie z.B. - Sozialleistungen des Unternehmens - räumliche Arbeitsbedingungen - Arbeitsorganisation, Führungsstil - Aufstiegsmöglichkeiten, Verantwortung - Offenheit bei Information und Führung Im DV-Bereich erfolgen Arbeitsplatzwechsel oft und kurzfristig und können Projekte sehr hart treffen. Gut qualifizierte Mitarbeiter und langfristig erarbeitetes Wissen stellen ein immenses Kapital (und Garantie) für den wirtschaftlichen Erfolg des Unternehmens dar, mehr als mancher softwaretechnische Faktor. 4.10 Qualitätssicherung Die Qualitätssicherung (engl. quality assurance QA) ist meist organisatorisch unabhägig direkt der Projektleitung zugeordnet. Sie soll - sicherstellen, dass die Arbeitsweise und die verwendeten Methoden in allen Phasen den definierten Qualitätsansprüchen entsprechen, - feststellen, ob die planerischen Ziele sich mit den real erreichten Zielen decken (Dokumentation des Projektfortschritts), - alle Phasenergebnisse mit Tests und Vergleich der Anforderungsdefinition überprüfen. Hierzu werden Checklisten und Testdaten verwendet, die aus einer unabhängigen Sicht möglichst objektiv die Qualität und die Quantität der geleisteten Arbeit festhalten. Jeder gefundene Fehler ergibt für die Zukunft einen neuen Testfall. TFH Berlin/Steyer 4-4 Softwareerstellung 4.11 Spirale Benutzer Problem Vorschlag Wartung+Pflege Definition Test+Abnahme Entwurf Implementierung TFH Berlin/Steyer 4-5 Softwareerstellung 5 Testen 5.1 Definitionen Testen (engl. testing) ist die Ausführung eines Programms mit der Absicht, Fehler zu finden. Wenn es das Ziel ist, die Abwesenheit von Fehlern zu zeigen, wird man nicht viele finden. Wenn es das Ziel ist, die Anwesenheit von Fehlern zu zeigen, wird man einen grossen Prozentsatz finden. Die Anwesenheit von Fehlern kann man beweisen (dadurch, dass man einen findet), die Abwesenheit von Fehlern kann man überhaupt nicht beweisen. Andere verwandte Begriffe: Ein Beweis (proof) ist der Versuch, Fehler in einem Programm zu finden ohne Berücksichtigung der Programmumgebung. Fehlerkorrektur (debugging) ist die Analyse eines Fehlers mit seiner Korrektur. Modultest (module testing) ist der Test eines einzelnen Programmmoduls in einer isolierten Umgebung. Integrationstest (integration testing) ist der Test von Schnittstellen zwischen Systemteilen (Modulen, Komponenten, Subsystemen). Systemtest (system testing) ist der Test eines Gesamtsystems mit allen Systemteilen. Akzeptanztest (acceptance testing) ist der Test eines Systems oder Programms gegen die Benutzeranforderungen. 5.2 Testspektrum Das Finden von Testf„llen ist eine der schwierigsten Aufgaben beim Testen. Es gibt dazu zwei grunds„tzliche Vorgehensweisen, die sich an den Extremen des folgenden Spektrums befinden. Test der Spezifikationen (Kümmere dich nicht um den Programmcode.) Test des Programmcodes (Kümmere dich nicht um die Spezifikationen.) Die Person am linken Ende des Testspektrums entwirft die Testfälle entsprechend den vorher festgesetzten Spezifikationen. Sie betrachtet das Programm als black box. Solange der Code sich richtig verhält, ist sie zufrieden. Ihr letztes Ziel ist der Test jeder möglichen Kombination von Eingabewerten. Die Person am rechten Ende des Testspektrums entwirft die Testfälle entsprechend der Programmlogik. Ein Grundsatz dafür ist, so viele Testfälle zu entwerfen, dass jeder Befehl mindestens einmal ausgeführt wird. Etwas aufwendiger ist das Ziel, jeden Programmzweig mindestens einmal zu durchlaufen (z.B. bei IF). Das letzte Ziel ist der Test jedes möglichen Pfades durch das ganze Programm. Kein Extrem ist eine gute Strategie, aber die erste ist etwas besser. Für beide gilt im Extremfall, dass sie zu aufwendig sind. Daraus folgt: Testen ist weitgehend ein wirtschaftliches Problem. Die Kunst, Testfälle zu finden, ist die Kunst, Testfälle mit der gr”ssten Wirksamkeit zu finden, d.h. Fälle, die eine möglichst grosse Menge von Fehlermöglichkeiten abdecken. TFH Berlin/Steyer 5-1 Softwareerstellung 5.3 Teststrategien Die Bottom-Up-Teststrategie beginnt bei den Endmodulen, d.h. den Modulen, die keine anderen Module aufrufen. Wenn diese einmal getestet sind, sollten sie so zuverlässig wie eine Programmiersprachfunktion oder eine Zuweisung sein. Die nächste zu testende Modulmenge besteht aus den Modulen, die die erste Gruppe direkt aufrufen. Sie werden mit diesen zusammen getestet. Dies wiederholt sich bis die Spitze erreicht ist. Die Bottom-Up-Teststrategie verlangt einen Testtreiber, d.h. ein übergeordnetes Programm, das die (noch nicht vorhandene) Oberfläche simuliert, das die Testfälle bereitstellt und den Test steuert (s.u.). Die Top-Down-Teststrategie beginnt beim obersten Modul. Danach werden die vom obersten Modul direkt aufgerufenen Module mit diesem zusammen getestet. Das wiederholt sich, bis alle Module integriert und getestet sind. Die Top-Down-Strategie verlangt für die noch nicht implementierten Module auf tieferen Stufen Platz-haltermodule (stub routines). Ein weiteres Problem sind die Ein-/Aus-gabemodule, die am Anfang nicht vorliegen. Sie haben deshalb hohe Priorität, um Testfälle ein- und Testergebnisse ausgeben zu können. Die Big-Bang-Teststrategie ist die Üblichste und besteht darin, zuerst jeden Modul für sich zu testen und dann alle auf einmal zu integrieren. Die Nachteile sind, dass beides, Testtreiber und Platzhaltermodule, für alle Einzelmodule geschrieben werden müssen, dass ausserdem die Integration erst spät stattfindet und dass Fehler bei der Integration schwer zu lokalisieren sind. Die Sandwich-Teststrategie ist ein Kompromiss zwischen Bottom-Up- und Top-Down-Methode und versucht, die Vorteile von beiden zu vereinen: frühe Integration, frühe echte Oberfläche, frühe Ein/Ausgabemodule. Das Programm wird von oben und unten gleichzeitig vorangetrieben und trifft irgendwo in der Mitte zusammen. Dieser Treffpunkt sollte vorher festgelegt werden. Eine allgemeingültige Bewertung lässt sich nicht geben. Für kleinere Systeme wird eher die Bottom-UpStrategie, für grössere eher die Sandwich-Strategie von Vorteil sein. Die Ziele nochmals: - frühe Integration - frühes Gesamtsystem - Test vielfältiger Bedingungen Aus diesen Gründen haben die Top-Down-Methode und die Big-Bang-Methode mehr Nachteile als die anderen, die Top-Down-Methode etwas weniger und die Big-Bang-Methode etwas mehr. TFH Berlin/Steyer 5-2 Softwareerstellung 5.4 Testaxiome Ein guter Testfall ist ein Testfall, der mit hoher Wahrscheinlichkeit einen Fehler entdeckt, und nicht einer, der zeigt, dass das Programm fehlerfrei läuft. Eines der schwierigsten Probleme beim Testen ist es, zu wissen, wann man aufhören kann. Es ist unmöglich, sein eigenes Programm richtig zu testen. Ein notwendiger Teil jedes Testfalls ist eine Beschreibung der erwarteten Ergebnisse. Nichtreproduzierbare und spontane Tests sind sinnlos. Es muss Testfälle sowohl für falsche als auch für richtige Eingaben geben. Testergebnisse sollen genau analysiert werden. Wenn in einem Modul die Anzahl der entdeckten Fehler steigt, steigt auch die Anzahl der noch nicht entdeckten Fehler. Testen sollte vom kreativsten Programmierer gemacht werden. Testen soll, wie jede andere Tätigkeit auch, mit dem Setzen von Zielen beginnen. Qualität ist die Übereinstimmung von Dokument und Programm. TFH Berlin/Steyer 5-3 Softwareerstellung 5.5 Drei Schritte bei der Implementierung (1) Codierung Module mit Funktionsköpfen: Wenn die Architektur des Systems mit Modulhierarchie, Modulen und einzelnen Funktionen feststeht, können die Module in Dateien überführt und die darin enthaltenen Funktionen zunächst nur durch die Funktionsköpfe repräsentiert werden. Das zwingt zur genauen Formulierung der Datentypen. Die Rümpfe werden vorläufig noch durch leere Klammern dargestellt. Die Rubriken IN, OUT, EFFECT und EXCEPTION aus der Spezifikation werden als Kommentare zu jeder Funktion übernommen. Jeder Modul soll fehlerfrei compilierbar sein. Pseudocode: Wenn die Grobstruktur des Algorithmus einer Funktion feststeht, soll sie mit Kommandos der Programmiersprache formuliert werden. Die Ausdrücke bleiben noch sprachliche Umschreibung. Dieser Teil kommt als Kommentar nach dem Funktionenkopf. Der Modul bleibt immer noch compilierbar. Programmcode: Durch Verfeinerung des Pseudocode (Vertiefung der Verschachtelung und Formalisieren der Ausdrücke) entsteht der endgültige Programmcode. (2) Testfallgenerierung Jede Eingabevariante, jede Option, jeder Grenzwert von Eingabewertebereichen ergibt einen Testfall. Jede falsche Eingabeklasse ergibt einen Testfall. Jede Programmverzweigung (IF, CASE) ergibt so viele Testfälle wie Ausgänge möglich sind. Jede Programmschleife ergibt (mindestens) einen Testfall für null Durchläufe, für einen Durchlauf und für die maximal mögliche Anzahl von Durchläufen. Es muss soviele Testfälle geben, dass jeder Zweig eines Moduls mindestens einmal durchlaufen wird. Jeder gefunde und korrigierte Fehler ergibt einen Testfall. (3) Testausführung Testumgebung für das Testen eines Programmbausteins 'b2'. TESTTREIBER: Fall 1: Liefere Testfalldaten Rufe Testmodul TESTMODUL: drucke Parameter von oben evtl. rufe Platzhalter PLATZHALTER: drucke Parameter von oben führe Platzhalter aus drucke Ergebnis gib Ergebnis zurück führe Testmodul aus drucke Ergebnis gib Ergebnis zurück Vergleiche Ergebnis jetzt und früher TFH Berlin/Steyer 5-4 Softwareerstellung 5.6 Versionskontrolle Arbeiten mehrere Programmierer an einem System, muss organisa-torisch sichergestellt sein, dass sie einerseits so selbständig wie möglich ohne Behinderung durch andere arbeiten können, dass sie andererseits jedoch so oft wie möglich ihr Teilsystem zum Gesamtsystem hinzufügen können. Dazu ist folgendes Verfahren nützlich: GESAMTBEREICH fertiges System (t-3) wird nur selten geändert fertiges System (t-2) kann noch geändert werden PRIVATBEREICH privates Programm (t-1) steht zur Übergabe bereit privates Programm (t) ist in der Entwicklung Jeder Programmierer entwickelt zum Zeitpunkt t ein Programm, hat aber schon andere Programme entwickelt und getestet (zum Zeitpunkt t-1). Hat er eine zusammenhängende Menge von Programmen fertig-gestellt, transferiert er diese zum Gesamtbereich und verbindet sie testweise mit einer Gesamtversion, die zur Zeit t-2 entstanden war. Verhält sich diese immer noch korrekt, kann sie zu einem neuen gültigen Systemzustand eingefroren werden, der den alten aus der Zeit t-3 ablöst. TFH Berlin/Steyer 5-5 Softwareerstellung 5.7 Systemtestfälle - Stresstest: Ein verbreiteter Fehler grosser Systeme ist, dass sie unter leichten Bedingungen korrekt funktionieren, aber unter der Last zur Echtzeit schnell zum Stillstand kommen. - Massentest: Während der Stresstest Belastung in einer kurzen Zeitspanne testet, setzt der Massentest das System grossen Datenmengen über einen langen Zeitraum aus. - Konfigurationstest: Das System sollte mit jeder Hardware, mit jedem Systemprogramm, zu denen es passen soll, getestet werden. Ist die Software konfigurierbar, muss jede Konfiguration getestet werden. - Kompatibilitätstest: Gibt es von einem länger lebenden System mehrere Versionen, müssen die Benutzerschnittstellen früherer Versionen auch mit neuen Systemversionen laufen. - Sicherheitstest: Speichert das System Daten verschiedener Benutzer, müssen diese gegen beabsichtigte und unbeabsichtigte Beschädigung abgesichert sein. - Speichertest: Viele Systeme unterliegen Beschränkungen bezüglich Haupt- und Sekundärspeicherbedarf, die durch Testfälle vor allem über die Versionen hinweg abgesichert werden müssen. - Leistungstest: Antwortzeiten, CPU-Zeiten oder Durchsatzraten unter verschiedenen Bedingungen sind wichtige Kennziffern, die ständig kontrolliert werden müssen. - Installationsstest: Die Installation eines Systems soll so einfach wie möglich gestaltet sein. Eine der frustrierendsten Situationen eines Anwenders ist es, wenn er das System nicht einmal installieren kann. - Verfügbarkeitstest: Bestimmte Anforderungen an ein System, wie z. B. Mindestzeit, bis ein Fehler auftritt, ist x Tage oder Mindestzeit, bis ein aufgetretener Fehler behoben ist, ist y Tage, sind sehr schwer zu testen, können aber durchaus im Kaufvertrag stehen. Eine Möglichkeit besteht darin, künstlich Fehler einzuführen und die Entdeckung und Behebung zu beobachten. - Wiederanlauftest: In vielen Systemprogrammen ist es eine vitale Aufgabe, nach Verlust von Daten oder Ausfall von Verbindungen die Trümmer abzuräumen und in einen definierten Zustand zurückzukehren. - Dialogtest: Es sollten auch interaktive Dialogsitzungen nach ihren Eingaben aufgezeichnet und später nochmals mit diesen Strömen wiederholt werden. Die Ausgaben sind jeweils zu vergleichen. - Dokumentationstest: Ein sehr wichtiger Teil des Sytemtests ist die Genauigkeit der Benutzerdokumentation. Z.B. sollten alle Beispiele in den Handbüchern auf Korrektheit geprüft werden. - Ergonomietest: Die Arbeit mit dem System sollte im Normal-, aber auch im Fehlerbetrieb, an den Menschen als Bediener angepasst sein, z.B. mit verständlichen Fehlermeldungen. TFH Berlin/Steyer 5-6 Softwareerstellung 5.8 Prüfliste - Datenbezug: nichtinitialisierte Variable ? Vektorindex innerhalb der Grenzen ? Index kein Integer ? externe und interne Datenstruktur unpassend ? Strukturdefinitionen passen •ber mehrere Funktionen ? Stringgrenzen überschritten ? 1-Über-oder-Unterlauf bei Indexoperationen ? - Datendeklaration: nichtdeklarierte Variable ? Vorbesetzungen verstanden ? Felder und Strings richtig initialisiert ? richtige Längen, Typen und Speicherklassen ? Initialisierung passt zur Speicherklasse ? Variablen mit gleichen Namen ? - Berechnung: Rechnen mit nichtarithmetischen Variablen ? Konversionsfehler ? Rechnen mit Variablen verschiedener L„nge ? Ziellänge kleiner als zugewiesener Wert ? Zwischenwertüber- oder -unterlauf ? Division durch Null ? Variablenwert ausserhalb des sinnvollen Bereichs ? Operatorpräzedenz richtig verstanden ? Integerdivision korrekt ? - Vergleiche: Vergleiche zwischen inkonsistenten Variablen ? Vergleichsoperator richtig herum ? Boolesche Kombination korrekt ? Operatorpräzedenz richtig verstanden ? Ausführungsreihenfolge des Compilers verstanden ? Zuweisungen und Vergleiche richtig verstanden ? - Kontrollfluss: Terminiert jede Schleife ? Werden alle Mehrwegausgänge korrekt benutzt oder überrannt ? Terminiert das Programm ? Schleifenumgehungen wegen falscher Eingangsbedingungen ? Sind Schleifendurchfälle korrekt ? Fehler wegen Überschreiten um 1 ? Schleifenklammerung korrekt ? Schöpfen die Bedingungen alle Möglichkeiten aus ? - Schnittstellen: Gleiche Anzahl der formalen und aktuellen Parameter ? Gleiche Attribute der formalen und aktuellen Parameter ? Reihenfolge der formalen und aktuellen Parameter gleich ? Anzahl, Attribute und Reihenfolge der Parameter bei Systemfunktionen korrekt ? Werden lokale Variablen zurückgegeben ? Werden Eingabevariablen zurückgegeben ? Werden globale Variablendefinitionen einheitlich in den Modulen benutzt ? Werden Konstante korrekt als Argumente benutzt ? TFH Berlin/Steyer 5-7 Softwareerstellung - Ein-/Ausgabe: Dateiattribute korrekt ? OPEN-Anweisung korrekt ? Dateibeschreibung passt zu internen Datentypen ? Puffer ausreichend gross ? Wird die Datei vor der Benutzung geöffnet ? Werden I/O-Fehler abgefangen ? - Andere Prüfungen: Unbenutzte Variablen ? Warnungen oder sonstige Informationen ? Eingabeprüfung ausreichend ? Fehlende oder unbenutzte Funktionen ? 5.9 Werkzeuge - Debugger, z.B. sdb, adb: um ein Objektprogramm zu analysieren und lesbar auszugeben um ein Programm kontrolliert schrittweise ablaufen zu lassen um nach einem Absturz den aktuellen Verschachtelungskeller festzustellen um ein Objektprogramm zu editieren (patchen) - Programmformatierer, z.B. cb: um die Blockstruktur zu erkennen und die Lesbarkeit zu erh”hen - Genauere Programmprüfer, z.B. lint: um Quellprogramme nach versteckteren Fehlern zu durchsuchen um nicht portierbare Programmabschnitte zu finden um besser zu optimieren - Laufzeitanalysierer, z.B. prof, size: um die Aufrufanzahl von Prozeduren zu ermitteln um den CPU-Verbrauch von Prozeduren zu ermitteln um den Speicherverbrauch eines Programms zu ermitteln - Versionspfleger make: um stets den aktuellen Systemstand herzustellen - Traces (auch selbst erstellbar): um den dynamischen Ablauf zu verfolgen - Interaktive Testströme (z.B. mit tee selbst erstellbar): um interaktive Benutzersitzungen reproduzierbar zu wiederholen TFH Berlin/Steyer 5-8 Softwareerstellung 6 Beurteilung 6.1 Prinzipien der Software-Entwicklung 1. Prinzip der Abstraktion Eine Abstraktion ist eine Verallgemeinerung eines Sachververhaltes von einem bestimmten Standpunkt aus. Es wird dabei von besonderen oder einzelnen Eigenschaften abgesehen. Das Gegenteil der Abstraktion ist die Konkretisierung. Beispiel: Parametrisierung einer Funktion 2. Prinzip der Modularisierung Das Prinzip der Modularisierung führt zur Bildung abgeschlossener, unabhängiger, funktionaler Einheiten, den Modulen. Diese Unabhängigkeit ermöglicht die getrennte Entwicklung, Überprüfung und Wartung von Programmteilen und damit die arbeitsteilige Erstellung von Software schlechthin. Beispiel: elektronische Schaltkarte 3. Prinzip der Strukturierung Eine Struktur ist eine reduzierte, von unwichtigen Details losgelöste, charakteristische Darstellung des Ganzen. Für jedes System oder Teilsystem kann eine geeignete Struktur erkannt bzw. modellhaft definiert werden. Vordefinierte Strukturen erleichtern das Auffinden und Nachvollziehen strukturierter Beschreibungen. Beispiel: Landkarte 4. Prinzip der Hierarchisierung Dieses Prinzip bedeutet eine schrittweise Zerlegung eines Problems in Teilprobleme (wie bei der schrittweisen Verfeinerung), so dass eine Baumhierarchie entsteht. Breite und Tiefe des Baumes leiten sich ab aus der Problemart und Problemgrösse. Entsprechend den Ausdrucksmöglichkeiten der verwendeten Sprachen und Methoden können dies Abstraktionselemente beliebiger Art sein. Beispiel: Firmenorganisation TFH Berlin/Steyer 6-1 Softwareerstellung 5. Prinzip der Lokalität Dieses Prinzip fordert, dass alle relevanten Informationen zur Lösung eines Teilproblems (z.B. Modul, Prozedur, Funktion) lokal verfügbar sein sollen. Je nach Grösse des Problems kann dies in komprimierter Form erfolgen. Als ideal gilt dabei eine überschaubare Einheit wie z.B. eine Seite. Beispiel: Abteilungen in einer Firma 6. Prinzip der integrierten Dokumentation Aus diesem Prinzip leitet sich die Dokumentation als integraler Bestandteil der Software ab. Nachdokumentationen geleisteter Entwicklungen widersprechen diesem Prinzip. Die Beachtung des Prinzips führt zu Dokumentationen, die immer aktuell sind. Beispiel: Moduldokumentation 7. Prinzip der Mehrfachverwendung Problemlösungen müssen nicht immer neu erfunden werden. Umfassend dokumentierte und archivierte Software, die ausserdem hinreichend allgemein und flexibel entwickelt wurde (z.B. Dienstmodule für mathematische Verfahren, Dateienbearbeitung usw.), bietet sich zur Mehrfachverwendung an. Gerade bei der professioneller Erstellung grosser Software soll dieses Prinzip angestrebt werden. Beispiel: NAND-, NOR-Schaltungen 8. Prinzip der Standardisierung Eine Standardisierung der Softwareentwicklung führt zu einer Vereinheitlichung aller Texte und Dokumente. Nicht mehr das Schönheitsempfinden des Einzelnen ist dabei gefragt, sondern das vereinheitlichte Erscheinungsbild, der Firmenstandard. Eine Standardisierung erhöht die Verständlichkeit von Dokumenten und unterstützt die Austauschbarkeit von Produkten und Entwicklern. Beispiel: metrisches Masssystem TFH Berlin/Steyer 6-2 Softwareerstellung 6.2 Qualitätsmerkmale von Software Hauptkriterien: Brauchbarkeit: der tatsächliche Nutzen des Produktes (ohne Nachbesserungen) Wartbarkeit: wie einfach das Produkt vom Benutzer modifizierbar ist (Fehlerbehebung, Anpassung an neue Anforderungen) Unterkriterien: Änderbarkeit: notwendige Änderungen können mit minimalen Kosten durchgeführt werden (Kommt häufiger vor, als man denkt.) Allgemeingültigkeit: Abdeckungsbreite für eine Menge von Problemen und Funktionen Assimilationsfähigkeit: Grad der Änderbarkeit von Ein-/Ausgabedialogen Autarkie: Unabhängigkeit von anderen Software-Produkten bzw. ihren Funktionen Brauchbarkeit: Grad der Zuverlässigkeit, Effizienz, Benutzerfreundlichkeit u.a. Benutzerfreundlichkeit: geringe Beeinträchtigung von Zeit, Energie, Motivation des Benutzers Aspekte: - Aufgabenangemessenheit (Gestaltung der Masken, Dialogverzweigungsmöglichkeiten, Blätterfunktionen, An- und Abmeldeverfahren) - Selbsterklärungsfähigkeit (Menüsteuerung, verständliche Systemmeldungen, Help-Funktionen, Feldbezeichnungen) - Steuerbarkeit (Aufrufformen, z.B. Expertenmodus, keine Zwangsfolgen, Dialogkellerung) - Verlässlichkeit (Wiederanlauf, feste PF-TastenBelegung, kurze Antwortzeiten) - Fehlertoleranz und -transparenz (Eingabeprüfungen, Defaultwerte, Warnng vor Löschen) TFH Berlin/Steyer 6-3 Softwareerstellung Effizienz: Sparsamkeit im Verbrauch von Laufzeit und Speicherplatz Eine Gefahr ist es jedoch, diese Grössen mit übermässigen Entwicklungskosten auf raffinierte Weise zu optimieren, da später deshalb oft hohe Pflege- und Wartungskosten die Folge sind. Dazu kommt, dass durch sinkende Hardwarekosten die Bedeutung des Merkmals Effizienz laufend zurückgeht. Erweiterbarkeit: Ausdehnbarkeit auf zusätzliche Anforderungen Funktionsumfang: Ausmass, in dem die für den geplanten Verwendungszweck notwendigen Funktionen tatsächlich realisiert sind Die zweiten Systemversionen unterliegen oft der Gefahr, funktionell überladen zu werden, weil der Entwickler all das nachholen will, was bei der Erstentwicklung noch nicht realisiert war. Genauigkeit: Präzisionsgrad der Ausgaben und Berechnungen Geräte-Unabhängigkeit: von Hardware-Eigenschaften Kompaktheit: Grad, in dem ein Podukt nur notwendige, d.h. keine überflüssigen Teile enthält Konsistenz: Grad, in dem ein Produkt nach einheitlichen Entwurfs- und Implementierungstechniken sowie in einheitlicher Notation entwickelt wurde. Lesbarkeit: Grad der Programmlesbarkeit Portabilität: Einfachheit, um ein Produkt von einer Hardware/Softwareumgebung in eine andere zu überführen. Die Zielsetzung "hohe Portabilität" ist den Zielen "hohe Effizienz", "geringe Enrwicklungskosten" und "kurze Entwicklungszeit" entgegengerichtet. Robustheit: Grad, in dem ein System auf fehlerhafte und unerwartete Eingaben bzw. Einflüsse verständlich reagiert und seine vorgesehenen Funktionen weiter erfüllt. Selbsterklärung: Grad, in dem ein Produkt Informationen zur eigenen Erklärung bereithält. Strukturierung: Grad, in dem ein Produkt ein erkennbares Organisationsmuster seiner Teile besitzt. TFH Berlin/Steyer 6-4 Softwareerstellung Testbarkeit: Einfachheit, ein Produkt zu testen, um sicherzustellen, dass die geforderten Eigenschaften erfüllt sind. technische Mittel: Trace- und Dump-Erzeugung, Testversion, die dies kann, einfache Durchführung, so dass Ferndiagnose (per Telefon) möglich ist Verständlichkeit: Leichtigkeit, mit der ein Systembenutzer Zweck und Aufbau eines Systems versteht Vollständigkeit: Grad, in dem das Produkt alle geforderten Funktionen erfüllt. Wartbarkeit: Grad der Wahrscheinlichkeit, in dem ein im Einsatz befindliches Produkt nach Auftreten eines Fehlers innerhalb einer gegebenen Zeit wieder in funktionsfähigen Zustand gebracht werden kann. Zählbarkeit: Grad, in dem das Produkt die Messung von Gebrauchshäufigkeiten von Teilen/Funktionen und die Identifizierung von Fehlern unterstützt. Zugänglichkeit: Grad, in dem ein Produkt die selektive Nutzung von Systemteilen für andere Zwecke erlaubt Zuverlässigkeit: Grad der Wahrscheinlichkeit, mit der ein im Einsatz befindliches Produkt während einer bestimmten Zeit unter den vorgesehenen Bedingungen und mit gültigen Eingabedaten die Funktionen erfüllt und die Leistungen erbringt, die in der Anforderung spezifiziert sind. Die grösste Gefahr sind Fehler oder Datenschäden, die erst später entdeckt werden und nicht mehr reparabel sind. ZU: ZUVERLÄSSIGKEIT Anekdote von Dijkstra 1972: "Wenn die Wahrscheinlichkeit, dass die einzelne Komponente eines Programms korrekt ist, p ist, dann ist die Korrektheitswahrscheinlichkeit des gesamten Programmes, das aus N solchen Komponenten besteht, sowas wie P = pN. Wenn nun N sehr gross ist, so muss p schon sehr, sehr nah bei 1 liegen, wenn wir möchten, dass P überhaupt wesentlich von Null differiert." Beispiel: Für N=10 ist die Wahrscheinlichkeit pN der Korrektheit des Gesamtsystems für p=0.99 immer noch P=0.9. Für p=0.90 jedoch nur mehrP=0.35. Hat man gar N=100 Teile des Gesamtsystems, deren Korrektheitswahrscheinlichkeit p=0.99 ist, so ist P=0.37, für p=0.90 ist P sogar nur noch 0.000027. also: testen, testen, testen ZU: ZUVERLÄSSIGKEIT UND EFFIZIENZ Zuverlässigkeit ist wichtiger als Effizienz. Denn, wenn es nicht immer stimmen muss, kann man es auch ganz schnell machen. TFH Berlin/Steyer 6-5 Softwareerstellung SOFTWAREKOSTEN 59% aller Softwareprojekte überschreiten das Budget. Kostenverteilung Programmentwurf 35 % Entwicklungskosten 100 % Programmierung 20 % Test/Einführung 45 % Wartung/Pflege/ 35 % Erweiterung Entwicklungskosten 200 - 400 % - Je länger die Lebensdauer, desto höher die Wartungskosten. - Je mehr Benutzer, desto höher die Wartungskosten. TFH Berlin/Steyer 6-6 Softwareerstellung ZEIT - Möglichst einfache Produkte auf Kosten des prinzipiell möglichen oder auch wünschenwerten Funktionsumfangs entwickeln. - Möglichst frühzeitigen Entwicklungsstart in Verbindung mit einer stärkeren Betonung der Qualitätsmerkmale Änderbarkeit und Portabilität. - Evtl. Effizienzverluste zugunsten schnellerer Entwicklung in Kauf nehmen. - Erst zuletzt zum Mittel "Kapazitätserhöhung" greifen. Brooksches Gesetz: "Adding manpower to a late project makes it later." .. Weinbergs Daumenregel: "Drei Programmierer, organisiert zu einem Team, können nur die doppelte Arbeit eines einzelnen Programmierers schaffen." TFH Berlin/Steyer 6-7
