Home

2001 by Martin Glinz. Alle Rechte vorbehalten. Reproduktion zum

1. Develop ment plan Requirements validation Integration and test plan test Design validation and verification Integ ration and test Implementation Acceptance jtest Plan next phases Develop verity nextlevel product Quelle Boehm 1988 BILD 3 6 Das Spiralmodell 3 3 Prototypen Prototypen sind ein zentrales Mittel zur fr hzeitigen Erkennung und L sung von Problemen in der Software Entwicklung DEFINITION 3 8 Prototyp Ein lauff higes St ck Software welches kritische Teile eines zu entwickelnden Systems vorab realisiert Der Prozess der Erstellung und Nutzung von Prototypen wird als Prototyping bezeichnet Es werden drei Arten von Prototyping unterschieden exploratives experimentelles und evolutio n res Prototyping Floyd 1984 Kieback Lichter Schneider Hufschmidt und Z llighoven 1992 Exploratives Prototyping dient zur Kl rung und Bestimmung von Anforderungen an Hand von lauff higen Programmen welche den zu kl renden Ausschnitt aus dem Gesamtproblem realisieren Exploratives Prototyping wird einerseits verwendet um mit sogenannten Demon strationsprototypen die prinzipielle N tzlichkeit und Machbarkeit von Systemideen zu demon strieren v a im Bereich der Akquisition und der Projekt Initiierung Andererseits dient es dazu ein konkretes von den zuk nftigen Benutzern erprobbares und kritisierbares Modell einer geplanten Inform
2. Anforderungs spezifikation Entwurf Realisierung und Komponententest Systemtest Zeit Ein f hrung Meilen steine EEE EHE weitere Meilensteine Projekt Anforderungs L sungs Integration beginn spezifikation konzept beendet und nach Review nach Re Integrations freigegeben view frei test bestan gegeben den interne Abnahme Kunden abnahme Projekt ende zum Beispiel je Modul nach freigegebenem Entwurf und nach bestandenem Modultest BILD 3 4 Beispiel eines ergebnisorientierten Phasenmodells 3 2 3 Wachstumsmodelle Wachstumsmodelle stellen den Gedanken der Software Evolution in den Mittelpunkt Ein System wird nicht konstruiert sondern es w chst in einer Reihe aufeinanderfolgender Schritte Es gibt verschiedene Varianten von Wachstumsmodellen unter verschiedenen Namen z B Versionen Modell evolution res Modell inkrementelles Modell Die Ideen zu dieser Art von Modellen gehen auf Basili und Turner 1975 zur ck Sie wurden von IBM f r die Entwicklung 26 Martin Glinz Software Engineering I sehr gro er technischer Software aufgenommen Mills et al 1980 und sp ter vor allem von Gilb 1988 verbreitet Der Grundgedanke ist immer der folgende Ausgehend von einer groben Zusammenstellung der Gesamtfunktionalit t des gew nschten Systems wird eine Folge von Lieferungen mit Lie ferumfang und Lieferter
3. 6 Konzipieren von L sungen 69 e Ist die Software auf mehrere Rechner verteilt versucht man die Prozesse als Ganzes zu vertei len Manchmal muss aber auch ein logischer Prozess auf mehrere physische Prozesse aufgeteilt werden e Weitere Prozesse k nnen notwendig sein wenn Aufgaben unterschiedlicher Dauer und Dring lichkeit zu erf llen sind wenn die Aufgaben die ein Prozess zu erf llen hat zu umfangreich werden oder wenn Fehlertoleranzanforderungen zu erf llen sind Die Kommunikationsbed rfnisse ergeben sich aus der Verteilung der Module auf die Pro zesse Das Vorgehen bei Wiederverwendung und Beschaffung wird in Abschnitt 6 5 5 beschrieben Bei der Ressourcenzuordnung werden die Module in der Regel als Ganzes auf Prozesse ver teilt Je enger die Kopplung zwischen einer Gruppe von Modulen ist desto eher sollten sie dem selben Prozess und dieser wiederum dem selben Rechner im System zugeordnet werden Die Aufspaltung eines Moduls auf mehrere Prozesse oder gar mehrere Rechner erh ht den Kopp lungsgrad des Systems und erschwert Fehlersuche und Modifikationen Zu erf llende Leistungs anforderungen v a geforderte Reaktionszeiten und zu transportierende Datenvolumina k nnen aber zu Abweichungen von diesem Prinzip zwingen Die gleichen berlegungen gelten f r die Zuordnung von Prozessen und Daten Bei der Ver teilung auf mehrere Rechner ist immer der durch die Verteilung entstehende Kommunikations bedarf insbesondere die M
4. Q Produkt Release Version reproduzierbar umgehbar Q Leistung Problem betrifft Q Programme Q Unterlagen Q Leistungen Q anderes Verwendete Hardware Antwort erwartet bis Betriebssystem Problembeschreibung U Problembeschreibung in Beilage zu treffende Ma nahmen Klassifizierung der Ma nahmen Fehlerbehebung I Anpassung Q Erweiterung oO Beratung Info o Schulung a Verantwortlicher Sachbearbeiter Zwischenbescheid an Kunde erforderlich wenn Meldung nicht bis zum vom Kunden erwarteten Termin erledigt werden kann Datum Visum Problem erledigt und Kunde informiert 12 Produktivit tsfaktoren 141 12 Produktivit tsfaktoren 12 1 Werkzeuge 12 1 1 Allgemeines Im Informatik Sprachgebrauch sind Werkzeuge rechnergest tzte Hilfsmittel f r die Entwick lung von Software Mit dem Einsatz von Werkzeugen werden prim r folgende Ziele verfolgt e Entlastung der Entwickler von Routinearbeiten e Bearbeitung der Sprachen graphisch oder textuell mittels derer die Entwickler ihre Probleme und L sungen formulieren Unterst tzung des Einsatzes von Entwicklungsmethoden Vereinfachung von nderungen Werkzeuge sind jedoch entgegen einem weit verbreiteten Glauben keine Wunderwaffen sie steigern die Produktivit t nicht um dezimale Gr enordnungen es sei denn man h tte vorher die Bits noch einzeln ins Silizium gemei elt sie ersetzen das eigene Denken und sorgf ltige
5. Deskriptive Darstellungen sind daher nur f r die Darstellung der Anforderungen kleiner berschaubarer Teilprobleme geeignet Dort vor allem bei der Modellierung echter Funktionen ist ihr Einsatz sinnvoll Konstruktive Darstellung Eine konstruktive Darstellung modelliert das zu spezifizierende System als eine Menge interagierender Komponenten Bild 7 7 Die Anforderungen werden dargestellt indem die Erzeugung der geforderten Resultate mit Hilfe der Komponenten und deren Zusammenarbeit in idealisierter Weise beschrieben wird Bild 7 7 Konstruktive Beschreibung von Anforderungen Beispiel Das Datenflussdiagramm ist eine typische Konstruktive Darstellung Bild 7 8 zeigt die Spezifikation f r die Aufbereitung und Anzeige eines Messwerts 7 Spezifikation von Anforderungen 91 Anzeige Rohwert Grenzwerte Me wert Dimension Indikator Instrument Bilder Bild 7 8 Datenflussdiagramm als typischer Vertreter einer konstruktiven Darstellung Eine Konstruktive Darstellung hat die folgenden Vorteile e Die Spezifikation ist ein anschauliches Modell der Problemstellung Sie ist daher leicht ver stehbar und nachvollziehbar e Die Darstellung erm glicht die Zerlegung der Gesamtaufgabe in kleinere besser berschau bare Teilaufgaben e Die Kombination von Teilen die unterschiedlich stark formalisiert sind
6. Will man erreichen dass Qualit tsmanagement etwas Aufbauendes ein positiver Teil der Unternehmenskultur ist und nicht etwas Negatives Destruktives so ist sehr darauf zu achten dass nicht nur Schlechtes kritisiert sondern vor allem auch Gutes gelobt wird 9 2 3 QM Verfahren Die Qualit tsmanagementverfahren kann man in drei Klassen gliedern Qualit tsplanung Qualit tslenkung und Qualit tspr fung Bild 9 3 Qualit tsplanung Definition der Qualit tsziele Das wollen wir erreichen Qualit tsienkung Konstruktive Ma nahmen So m ssen wir arbeiten Qualit tspr fung Analytische Ma nahmen Haben wir die Ziele erreicht Haben wir richtig gearbeitet Bild 9 3 Qualit tsmanagement Ma nahmen Zur Qualit tsplanung im Allgemeinen geh rt der Aufbau des Qualit tsmanagementsystems seine Dokumentation im Qualit tshandbuch und seine Auspr gung im Qualit tswesen Ferner 9 Qualit tsmanagement 115 geh rt dazu eine Festlegung von Qualit tsmerkmalen die bei jeder Produktentwicklung gemes sen werden sollen Qualit tsplanung im Speziellen ist die Festlegung der Ziele f r ein Projekt bzw Produkt vgl Kapitel 2 Qualit tslenkung im Allgemeinen findet statt durch Festlegung von Entwicklungsmethoden welche die Vorgehensweise definieren durch Sprachen welche die Ausdrucksweise normieren und durch Werkzeuge welche den Einsatz von Methoden und Sprachen unterst tzen Zu den Methoden geh ren auch Entwicklungsric
7. briert werden wenn damit brauchbare Prognosen erzielt werden sollen Das bedeutet dass abge schlossene Projekte nachkalkuliert werden m ssen Aus diesen Daten m ssen unternehmens und eventuell auch projektartspezifisch die Zusammenh nge zwischen Function Points und Aufwendungen hergeleitet werden Es gibt unterschiedliche Z hlregeln f r Function Points In diesem Text werden die Regeln der International Function Point Users Group IFPUG 1994 verwendet In IBM 1983 und Seibt 1987 werden andere Gewichtungskriterien und nur sieben Einflussfaktoren zur Berechnung des Wertkorrekturfaktors herangezogen Noth und Kretzschmar 1984 verwenden wie IFPUG vierzehn Einflussfaktoren gewichten aber den Faktor 9 technische Komplexit t mit 0 50 statt nur mit 0 5 Symons 1988 kritisiert das Albrechtsche Z hlverfahren und schl gt 54 Martin Glinz Software Engineering I ein Z hlverfahren vor das statt Kompletter Ein und Ausgben die einzelnen Datenfelder z hlt Mark II Function Points Personen 500 monate IBM nach Noth und Kretzschmar 1984 400 300 200 IBM 1983 100 1000 2000 3000 Function Points BILD 5 6 Bestimmung des Aufwand aus den Function Points Jones 1995 gibt Erfahrungswerte f r die Umrechnung von Function Points in Codezeilen an Tabelle 5 4 Die Codezeilen verstehen sich ohne Leerzeilen und ohne Kommentar TABELLE 5 4 Anzahl Codezeilen pro Function Point Sprache Mittlere Anzahl Cod
8. e ber die in die engere Wahl gekommenen Komponenten bzw Systeme beschafft man sich genaue Unterlagen und l sst sie sich ggf vorf hren e Aussagen zu kritischen Punkten die aus Werbematerial oder von Verk ufern stammen sollten nachgepr ft werden e Bei gr eren und teureren Komponenten bzw Systemen ist eine formale Evaluation sinnvoll Dabei werden alle Anforderungen gewichtet f r jede Anforderung und jedes Kandidatensystem die Erf llung gepr ft und die Ergebnisse zusammengez hlt Der Kan didat mit den meisten Punkten erf llt den Anforderungskatalog am besten e Neben der formalen Bewertung sollten auch folgende Aspekte zur Beurteilung herange zogen werden e Vertrauensw rdigkeit des Herstellers H ndlers e Verf gbarkeit von Service e Erfahrungen mit anderen Produkten des gleichen Herstellers e Eigene Beschaffungspolitik z B m glichst alles aus einer Hand beschaffen e F r jeden Kandidaten ist au erdem zu pr fen welcher finanzielle und zeitliche Auf wand f r notwendige Parametrierungen oder Anpassungsentwicklungen erforderlich ist e Sind Komponenten bzw Systeme in einer Preisklasse ber Fr 10 000 zu beschaffen empfiehlt sich die Miete einer Probeinstallation welche eine intensive Erprobung unter realen Bedingungen erm glicht Dabei werden manchmal auch noch Probleme entdeckt die bei der Formulierung der Anforderungen vergessen wurden 5 Entscheidung f llen und dokumentieren Aufgrund der Evaluation und ev
9. menfasst Eine solche Abstraktion wird Datenabstraktion genannt Abstrakte Datentypen sind das bekannteste Mittel zum Aufbau von Datenabstraktionen Der im Kapitel 7 5 4 spezifizierte Stack ist ein typisches Beispiel f r einen abstrakten Datentyp Bei der datenorientierten Architektur besteht ein System aus einer Menge von Datenabstrak tionen die in hnlicher Weise wie bei einer funktionsorientierten Architektur aufeinander auf bauen Es entsteht so eine Benutzungshierarchie Die Datenabstraktionen benutzen in ihren Implementierungen Operationen die von tieferliegenden Datenabstraktionen angeboten werden In der Regel versucht man die Datenabstraktionen in Schichten zu gliedern Anwendung der Virtuelle Maschinen Metapher vgl 6 8 2 Bild 6 3 zeigt als Beispiel die Architektur der Soft ware f r einen Bancomaten Man beachte dass ein Pfeil in diesem Bild nicht wie in Bild 6 2 den Aufruf einer einzelnen Funktion sondern die Benutzung von Leistungen bezeichnet Die Zusammenarbeit zwischen Leistungsanbietern und Leistungsverwendern kann durch Vertr ge spezifiziert werden Design by Contract Nach diesem Stil entworfene Systeme sind aufgrund der Eigenschaften des Geheimnisprin zips leicht nderbar und vor allem im Gro en gut verstehbar Ein datenorientierter Entwurf f hrt damit genau auf Modularisierungen wie sie gem Abschnitt 6 3 2 erw nscht sind Bancomat Steuerschicht Aswan Anwendungs schicht Dienstle
10. scher Entwicklung In einer Entwicklung ohne formulierte Ziele sind die Eigenschaften und Qualit ten der resul tierenden Software zuf llig Sie ergeben sich bestenfalls noch teilweise aus offensichtlichen Be d rfnissen der Problemstellung Zur Hauptsache h ngen sie jedoch dann ab vom Charakter und den Vorlieben der Entwicklerinnen und Entwickler von Gruppenstrukturen und von den Bezie hungen zwischen Entwicklern und Benutzern Software Engineering betreiben bedeutet daher zwingend dass f r jede Entwicklung von Software Ziele gesetzt werden und anschlie end systematisch auf diese Ziele hin gearbeitet wird Es gibt jedoch f r die Herstellung von Software kein nat rliches Ziel Viele m gliche Teil ziele stehen in Konkurrenz zueinander Beispielsweise kann eine Software nicht gleichzeitig ext rem zuverl ssig und besonders kosteng nstig in der Entwicklung sein Die Wahl der Ziele hat einen erheblichen Einfluss sowohl auf das entstehende Produkt als auch auf den Entwicklungsprozess Ein von Weinberg und Schulman 1974 durchgef hrtes Experiment zeigt dies in eindr cklicher Weise Bild 2 1 Weinberg und Schulman hatten f nf Entwicklungsgruppen die gleiche Software entwickeln lassen den f nf Gruppen aber unter schiedliche Projektziele gesetzt Das Ergebnis zeigt zweierlei e Die Qualit ten der erzeugten Programme sind stark korreliert sind mit den Zielen welche den Entwicklungsgruppen vorgegeben wurden e Die optimale Erreic
11. 12 2 Mehrfachverwendung von Software Die Bedeutung von Mehrfachverwendung f r die Produktivit t wurde in Kapitel 3 4 disku tiert 12 3 Die Rolle der Menschen Software wird von Menschen gemacht Die Software Leute sind daher neben der Software Mehrfachverwendung der entscheidende Produktivit tsfaktor in der Software Entwicklung Aspekte der Psychologie und der Menschenf hrung spielen somit eine wichtige Rolle in der Software Entwicklung Wesentliche Gedanken dazu enthalten die B cher von Brooks 1995 DeMarco und Lister 1991 und Weinberg 1971 In diesem Kapitel werden nur wenige Grund s tze und Regeln beschrieben 144 Martin Glinz Software Engineering I 12 3 1 Regeln ber Menschen in der Software Entwicklung Produktivit t Die Schwankungsbreite der individuellen Produktivit t von Software Entwicklern ist sehr gro Ein von Sackman 1968 durchgef hrtes Experiment ergab Schwankungsbreiten in der Produktivit t von ca 20 1 Diese Daten sind zwar schon recht alt aber es gibt keinen Grund zur Annahme dass sich seither etwas Grundlegendes ver ndert hat Boehm 1987 gibt eine Schwankungsbreite von rund 4 an wobei er allerdings nicht die besten und die schlechtesten Entwickler vergleicht sondern Gruppen die einerseits unter 15 und andererseits ber 90 auf einer relativen F higkeitsskala liegen Disponibilit t Personal ist kein beliebig disponierbarer Produktionsfaktor Drei Regeln sind zu beachten e Personalbes
12. 2 y Pl lt WP2 Gr e P1 lt Gr e P2 16 Martin Glinz Software Engineering I y Pl y P2 P3 gt Gr e P1 Gr e P2 Gr e P3 Beides ist mit der gegebenen Abbildungsvorschrift f r y der Fall 2 4 2 Skalentypen Abh ngig von den Relationen die es auf den Auspr gungen eines zu messenden Merkmals gibt sind auf den Skalenwerten bestimmte Operationen m glich oder eben auch nicht m glich Sind zum Beispiel die Merkmalswerte nicht additiv so sind Additionen von Skalenwerten unzu l ssig selbst wenn dies von der Art der Skala her m glich w re Abgestuft bez glich der erlaub ten Operationen werden f nf Skalentypen unterschieden Tabelle 2 1 TABELLE 2 1 Skalentypen Skalentyp Operationen Beschreibung Nominalskala Er Reine Kategorisierung von Werten Die Skalenwerte sind weder vergleichbar noch miteinander verkn pfbar Es ist nur nicht parame trische Statistik m glich Ordinalskala lt gt Die Skalenwerte sind geordnet und miteinander vergleichbar Die Bestimmung des Medianwerits ist m glich Im brigen kann nur nicht parametrische Statistik betrieben werden Mittelwerte oder Standardabweichungen k nnen nicht berechnet werden Intervallskala lt gt Werte sind geordnet die Distanz zwischen je zwei Skalenwerten Distanz kann bestimmt werden Der Nullpunkt der Skala ist willk rlich gew hlt Mittelwert und Standardabweichung sind bestimmbar Verh ltnisskala_ lt gt
13. Leitfaden DIN ISO 9000 Teil 3 1990 Qualit tsmanagement und Qualit tssicherungsnormen Leitfaden f r die Anwendung von ISO 9001 auf die Entwicklung Lieferung und Wartung von Software IEEE 1986 Standard for Software Verification and Validation ANSVIEEE Std 1012 1986 IEEE Computer Society Press IEEE 1989a IEEE Standard Dictionary of Measures to Produce Reliable Software IEEE Std 982 1 1988 IEEE Computer Society Press IEEE 1989b IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software IEEE Std 982 2 1988 IEEE Computer Society Press IEEE 1990 Standard Glossary of Software Engineering Terminology IEEE Std 610 12 1990 IEEE Computer Society Press ISO 8402 1994 Qualit tsmanagement und Qualit tssicherung Begriffe ISO 8402 1994 Quality Management and Quality Assurance Vocabulary ISO 9001 1994 Quality Systems Model for Quality Assurance in Design Development Production Installation and Servicing Second Edition Technisch revidierte Neuausgabe von ISO 9001 1987 Anh nge Anhang 1 Formbl tter f r Review Bericht e Deckblatt mit Review Zusammenfassung e Liste der Befunde Anhang 2 Unterlagen f r die Codeinspektion aus Aufgabe 9 3 126 Martin Glinz Software Engineering I Review Review Nr Seite von Bericht Datum Zeit von bis Zu pr fendes Produkt Nummer Version Titel Referenzunterlagen Nummer Version Titel Bewertung a akzep
14. Servers die Daten bereitstellen Datenbanksysteme Dateisysteme und einer Kommunikationsschiene welche alle Komponenten miteinander verbindet Erweitert man die Kommunikationsschiene zu einer Zwischenschicht welche Kommunikations Koordinations und bersetzungsdienste sowie ausgew hlte Teile der Anwendung realisiert so spricht man von einer Middleware Architektur Tresch 1996 Komponentenorientierte Architekturen werden manchmal auch als Architektur mit verteilten Objekten bezeichnet Kompo nente Objekt e Schnittstelle Bild 6 6 Beispiel einer komponentenorientierten Architektur 6 7 Wiederverwendung von Architekturen und Entwurfswissen 6 7 1 Entwurfsmuster Entwurfsmuster Gamma et al 1995 stellen bew hrte vorgefertigte L sungsschablonen f r wiederkehrende Entwurfsprobleme bereit und erm glichen damit die Wiederverwendung von Entwurfswissen Sie schaffen ferner eine begriffliche Basis und Terminologie f r die Kommuni kation ber solche Probleme DEFINITION 6 10 Entwurfsmuster design pattern Eine spezielle Komponente die eine allge meine parametrierbare L sung f r ein typisches Entwurfsproblem bereitstellt Grunds tzlich gibt es eine F lle von Mustern sowohl allgemeiner Art als auch f r spezifi sche Anwendungsbereiche Musterkataloge erschlie en das Wissen ber Muster und machen die Muster wiederverwendbar Entwerfen mit Mustern setzt voraus dass die Entwerfenden einen Grundschatz an Mustern
15. Werte sind geordnet und in der Regel additiv Vielfache und auch Rational Distanz Prozentwerte sind bestimmbar Die Skala hat einen absoluten skala genannt Vielfaches Nullpunkt dieser repr sentiert das totale Fehlen der gemessenen Eigenschaft bliche parametrische Statistik ist m glich Absolutskala lt gt Die Skalenwerte sind absolute Gr en das hei t sie lassen sich in Distanz keine andere Skala umrechnen Im brigen gleiche Eigenschaften Vielfaches wie Verh ltnisskala BEISPIEL 2 2 Skalentypen Nominalskala Testergebnisskala mit den Werten erf llt nicht erf llt nicht getestet Ordinalskala Eignungsskala mit den Werten 0 Intervallskala Datumskala f r Zeit Verh ltnisskala Anzahl Codezeilen Skala f r Programmgr e Absolutskala Z hlskala f r die Anzahl gefundener Fehler in Programmen 2 4 3 Direkte und indirekte Ma e Es gibt einige interessierende Merkmale von Software und von Software Entwicklungspro zessen die sich in einfacher Weise direkt messen lassen Solche Merkmale sind zum Beispiel Entwicklungskosten oder Durchlaufzeiten Solche Ma e nennen wir direkte Ma e Auch das in Beispiel 2 1 erw hnte Ma f r die Gr e von Programmen geh rt zu den direkten Ma en Auf der anderen Seite gibt es Merkmale f r die es keine direkten Ma e gibt oder wo das Messverfahren zu aufwendig w re In diesen F llen behilft man sich indem m
16. die Fehler und L cken erst zu beseitigen wenn man beim Entwerfen bzw Codieren an diese Stellen kommt c Sie gehen den Review Bericht durch markieren die Punkte die Ihnen schwerwiegend erscheinen und lassen nur diese beheben d Sie veranlassen die Behebung der festgestellten Fehler lassen aber gleichzeitig mit dem Detailentwurf eines Teilsystems beginnen in dessen Konzept nur zwei leichte M ngel gefunden wurden 9 3 Inspizieren Sie die im Anhang 2 gegebene Prozedur Bereiten Sie sich vor indem Sie die Prozedur durcharbeiten und Ihre Befunde notieren Tun Sie sich mit drei oder vier Kol leginnen und Kollegen zusammen und f hren Sie eine Review Sitzung durch Vergleichen Sie die Befundliste der Sitzung mit Ihren eigenen Befunden 9 4 Warum sind unvorbereitete und undokumentierte Tests sinnlos Zitierte und erg nzende Literatur Beizer B 1995 Black Box Testing Techniques for Functional Testing of Software and Systems New York etc John Wiley amp Sons Berner S S Joos M Glinz 1997 Entwicklungsrichtlinien f r die Programmiersprache Java Informatik Informatique 4 3 Jun 1997 8 11 Dunn R 1990 Software Quality Concepts and Plans Englewood Cliffs N J Prentice Hall in dt bersetzung Software Qualit t Konzepte und Pl ne M nchen Hanser 1993 Fagan M E 1986 Advances in Software Inspections IEEE Transactions on Software En gineering SE 12 7 July 1986 744 751 Freedman D P G M Wein
17. llung beispielsweise die Erf llung von Leistungsanforderungen sowie der Gr e der Zuverl ssigkeit der Benutzerfreundlichkeit oder der Pflegbarkeit Leider ist zu sagen dass die meisten dieser Merkmale nur indirekt gemessen werden k nnen und es bis heute keine allgemein anerkannten S tze von Indikatoren f r diese Merkmale gibt Auch bei scheinbar einfa chen Merkmalen wie der Produktgr e gehen die Meinungen auseinander ob beispielsweise die Zahl der Codezeilen ein ad quates Gr enma ist Im Bereich der Projektziele interessiert man sich insbesondere f r Ma e zur Messung von Aufwand Durchlaufzeit Dauer Arbeitsfortschritt Entwicklungskosten und Fehlerkosten Im Gegensatz zu den Produktmerkmalen lassen sich die meisten Projektmerkmale verh ltnism ig einfach messen wenn die notwendigen Basisdaten zum Beispiel eine geeignete Zeitaufschrei bung vorliegen Aufgaben 2 1 Warum sind Zielsetzung und Zielverfolgung im Software Engineering besonders wichtig 2 2 Geben Sie f r die Skalentypen Nominalskala Ordinalskala Intervallskala Verh ltnisskala und Absolutskala je ein Beispiel aus dem t glichen Leben an 2 3 In einem Unternehmen mit weltweiten Verkaufsniederlassungen sollen die Verk uferinnen und Verk ufer durch ein zentrales Produktinformations und Bestellsystem unterst tzt werden Dieses System soll den Verk uferinnen und Verk ufern aktuelle Produktinformationen liefern insbeson dere auch Angaben ber
18. ver ndern und geschrieben werden dabei wird der alte Inhalt zerst rt e Endknoten sind Aktivit ten in der Systemumgebung ze Kontext Diagramm Bild 7 19 Beispiel einer DFD Hierarchie in Strukturierter Analyse Datenflussdiagramme sind bersichtsmodelle Zur Pr zisierung m ssen die Namen aller Datenfl sse und Speicher definiert werden Hierzu dient ein globales Datenlexikon das alle ver wendeten Datennamen definiert Ferner muss die Funktionalit t jeder nicht hierarchisch zerleg ten Aktivit t beschrieben werden Hierzu dienen sogenannte Mini Spezifikationen in denen der 7 Spezifikation von Anforderungen 99 zu spezifizierende Zusammenhang zwischen Eingabe und Ausgabedaten in freier Form be schrieben ist Die Datenflussdiagramme eines Systems K nnen hierarchisch in Schichten angeordnet wer den Jede Ebene fasst die Datenflussdiagramme der darunterliegenden Ebenen zu je einer Aktivi t t zusammen In der Regel wird ein dazu passendes hierarchisches Nummerierungsschema f r Aktivit ten und DFD verwendet Bei geeigneter Wahl der Zerlegung kann so ein komplexes Modell schrittweise in einfachere Teilmodelle zerlegt werden Bild 7 19 7 5 4 4 Verhaltensspezifikation mit Automaten Verhaltensspezifikationen mit Automaten sind teilformale konstruktive Modelle Die Anfor derungen werden als eine Menge von Zust nden Zustands berg ngen ausl senden Ereignissen und ausgel sten Aktionen beschrieben Das Modell spez
19. 6 5 4 Variantenbehandlung Es ist wesentlich nicht stur einen einzigen L sungspfad zu verfolgen sondern stets den gan zen Raum m glicher L sungen zu betrachten berall wo sich mehrere L sungsm glichkeiten ergeben werden die m glichen L sungsvarianten soweit verfolgt bis ein sinnvoller Entscheid f r die beste Variante m glich ist Das L sungskonzept welches das Resultat der Konzipierung dokumentiert enth lt keine Varianten mehr Es dokumentiert lediglich wichtige verworfene Varianten kurz um die getroffenen Entscheidungen nachvollziehbar zu machen Bei den Kosten d rfen nicht nur die unmittelbaren Entwicklungskosten einer Variante be trachtet werden Vielmehr m ssen auch die Auswirkungen auf die Betriebs und Pflegekosten sowie m gliche Folgekosten durch Einfl sse auf andere Komponenten untersucht werden F r die Untersuchung von L sungsvarianten darf jedoch nicht beliebig viel Aufwand getrie ben werden Die Kosteneinsparungen durch die Wahl einer besseren bzw der besten Variante m ssen stets im richtigen Verh ltnis zu den Kosten f r die Untersuchung der Varianten stehen Als Faustregel gilt Je gr er bzw teuerer der Untersuchungsgegenstand ist desto aufwendiger darf die Untersuchung sein 6 5 5 Vorgehen bei Beschaffung und Wiederverwendung Die nachfolgend aufgef hrten f nf Schritte m gen als grober Leitfaden f r das Vorgehen bei Beschaffungen dienen Der Beschaffungsprozess l uft parallel zur Spezifikation d
20. 75 88 1 00 1 15 1 40 DATA Data base size 94 1 00 1 08 1 16 CPLX Product complexity 70 85 1 00 1 15 1 30 1 65 Computer Attributes TIME Execution time constraint 1 00 1 11 1 30 1 66 STOR Main storage constraint 1 00 1 06 1 21 1 56 VIRT Virtual machine volatility 87 1 00 1 15 1 30 TURN Computer turnaround time 87 1 00 1 07 1 15 Personnel Attributes ACAP Analyst capability 1 46 1 19 1 00 86 71 AEXP Applications experience 1 29 1 13 1 00 91 82 PCAP Programmer capability 142 117 1 00 86 70 VEXP Virtual machine experience 1 21 1 10 1 00 90 LEXP Programming language experience 1 14 1 07 1 00 95 Project Attributes MODP Use of modern programming practices 1 24 1 10 1 00 91 82 TOOL Use of software tools 1 24 1 10 1 00 91 83 SCED Required development schedule 1 23 1 08 1 00 1 04 1 10 Quelle Boehm 1981 BILD 5 5 COCOMO Kostenfaktoren Eine ausf hrliche Beschreibung von COCOMO inklusive der Definition was bei ihm ein Personenmonat und eine Zeile gelieferter Code ist findet sich in Boehm 1981 5 4 2 Das Function Point Verfahren Function Points sind ein relatives Ma zur Bewertung der Funktionalit t d h des Leistungs umfangs eines Systems Verf gt ein Unternehmen ber Erfahrungszahlen wieviel Aufwand pro Function Point im Mittel ben tigt wird um Software zu entwickeln bzw zu pflegen so k nnen Function Points zur Aufwandsch tzung herangezogen werden Wird in laufenden oder abge schlossenen Projek
21. Angewandte Informatik Band 8 Mannheim Wien Z rich BI Wissenschaftsverlag Noth T und M Kretzschmar 1984 Aufwandsch tzung von DV Projekten Berlin etc Springer Seibt D 1987 Die Function Point Methode Vorgehensweise Einsatzbedingungen und An wendungserfahrungen Angewandte Informatik 1 1987 3 11 Symons C R 1988 Function Point Analysis Difficulties and Improvements IEEE Transacti ons on Software Engineering 14 1 Jan 1988 2 11 Wellman F 1992 Software Costing Hemel Hempstead Prentice Hall International UK 6 Konzipieren von L sungen 59 6 Konzipieren von L sungen 6 1 Motivation F r die Entwicklung von Kleinsoftware typisch durch eine Person f r den Eigengebrauch ist kein systematischer Entwurf notwendig Allenfalls werden Skizzen gemacht im brigen wird direkt programmiert Gr ere Software dagegen braucht einen systematischen strukturierten Aufbau der nur durch ein sorgf ltig erstelltes L sungskonzept sichergestellt werden kann Ohne ein solches L sungskonzept ist es nicht oder nur mit gro em Aufwand m glich e die L sung zu verstehen e die Entwicklungsarbeit auf mehrere Personen zu verteilen Software Entwicklung ist Teamar beit e die L sung in vorhandene Software einzubetten dazu m ssen die Schnittstellen und Wechsel wirkungen verstanden werden e die L sung zu verteilen auf mehrere Rechner ggf auch geographisch Ferner legt ein gutes L sungskonzept den
22. Beobachter und schickt jedem Beobachter die Botschaft AKTUALI SIEREN Das benachrichtigende Subjekt wird als Parameter mitgegeben 3 Jeder benachrichtigte Beobachter reagiert indem er beim benachrichtigenden Subjekt mit den Bot schaften HOLEXXX HOLEYYY etc die ihn interessierenden Informationen abruft Varianten Der Botschaft AKTUALISIEREN k nnen weitere Informationen z B die Art des eingetretenen Ereignis ses als Parameter mitgegeben werden Der Botschaft AKTUALISIEREN k nnen die ver nderten Daten gleich mitgegeben werden wodurch der Abruf durch HOLEXXX entf llt Dieses Bringprinzip ist effizient koppelt aber Gegenstand und Beobach ter st rker als das mit HOLEXXX realisierte Holprinzip Bild 6 7 Das Beobachtermuster 6 7 2 Rahmen Rahmen frameworks stellen vorgefertigte L sungsger ste f r bestimmte Problemklassen bereit und gestatten damit die Wiederverwendung ganzer Architekturen DEFINITION 6 11 Rahmen framework Eine Menge kooperierender Module die das Grund ger st f r die L sung einer bestimmten Klasse von Problemen bilden Konkrete L sungen entstehen durch Erg nzung oder Spezialisierung des Rahmens durch problemspezifische Module Der Umfang eines Rahmens kann stark variieren e Enge Rahmen l sen ein spezifisches Teilproblem zum Beispiel die Realisierung einer Benut zerschnittstelle die Verwaltung von Dateien mit Vergabe und Pr fung von Zugriffsrechten oder die Grundfunktionalit t eines E
23. Entwicklern Grundsatz 4 Das Qualit tswesen ist verantwortlich f r die Ermittlung Messung der Qualit t Es erbringt Dienstleistungen in allen Belangen der Qualit t sowohl f r die Entwickler wie f r die F hrungsverantwortlichen Das Qualit tswesen erarbeitet die Kriterien zur Qualit tsmessung f hrt die Messungen durch oder ist dabei behilflich Es erarbeitet f r die F hrungsverantwortlichen Empfehlungen zu anste henden Entscheidungen z B Verkaufsfreigabe eines Produkts Es informiert die Entwickler ber die Qualit t ihrer Arbeit Grundsatz 5 Das Qualit tswesen muss einen unabh ngigen Berichterstattungspfad haben der bis zur Gesch ftsleitung geht Die F hrungsverantwortlichen k nnen Empfehlungen des Qualit tswesens ignorieren da sie gem Grundsatz 3 nicht nur die Termin Kosten und Sachverantwortung sondern auch die Qualit tsverantwortung haben Da qualitativ schlechte Produkte jedoch den Ruf eines ganzen Unternehmens ruinieren k nnen muss das Qualit tswesen die M glichkeit haben auf einem or dentlichen Berichtspfad die Gesch ftsleitung ber Pfuscharbeit zu orientieren Grundsatz 6 Die Entwickler m ssen ber die Qualit t ihrer Arbeit orientiert werden Jeder Vorgesetzte muss die Qualit t der Arbeit seiner Mitarbeiter in deren Beurteilung mit einbe ziehen Entwickler sind nur dann motiviert Qualit tsarbeit zu leisten wenn sie wissen und sp ren dass Qualit t belohnt und Pfusch bestraft wird
24. Erstellung von Wegwerfprototypen ist wirtschaftlich wenn es gelingt bei der eigentlichen Systementwick lung aufgrund der Erfahrung mit den Prototypen mehr Kosten zu sparen als die Prototypen selbst gekostet haben oder wenn mit Prototypen ein gef hrliches Risiko wesentlich gemindert werden kann vgl Kapitel 4 Risiken Im Gegensatz dazu ist beim evolution ren Prototyping der Prototyp ein Pilotsystem das den Kern des zu entwickelnden Systems bildet operational eingesetzt wird und durch schrittweise Erg nzungen und Erweiterungen zum geplanten System weiterentwickelt wird Dementspre chend muss ein evolution rer Prototyp sorgf ltig und nach allen Regeln der Kunst entwickelt werden Evolution res Prototyping entspricht im Vorgehen einem Wachstumsmodell Das Arbeiten mit Prototypen ist somit kein eigenst ndiges Modell f r die Entwicklung von Software e Demonstrationsprototypen unterst tzen die Akquisition von Auftr gen und das Aufsetzen von Projekten e Prototypen im engeren Sinn sowie Labormuster dienen zur Risiko Minderung und k nnen in jedem Prozessmodell zu jedem Zeitpunkt f r diesen Zweck eingesetzt werden e Das Arbeiten mit Pilotsystemen ist eine Form des Wachstumsmodells 3 4 Wiederverwendung und Beschaffung 3 4 1 Mehrfachverwendung und Produktivit t Die Produktivit t bei der Entwicklung neuer Software l sst sich nach heutigen Erkenntnissen nur in ziemlich eng begrenztem Rahmen steigern weil wesentliche Teile des En
25. Gr en der Eintretenswahrschein lichkeit und der Schadenh he Es ist daher sinnvoll Risiken nach ihrem Risikofaktor zu beurtei len Dieser ist das Produkt aus Eintretenswahrscheinlichkeit und Schadenh he Bild 4 6 blicherweise werden relative Skalen verwendet bei einfachen Absch tzungen nur mit den Werten gering mittel und hoch bei genauerem Arbeiten mit Werten von 0 bis 10 44 Martin Glinz Software Engineering I Das Arbeiten mit Risikofaktoren hat allerdings einen Sch nheitsfehler Risiken mit sehr ho hem Schaden bei gleichzeitig sehr geringer Eintretenswahrscheinlichkeit sogenannte Restrisi ken k nnen einen sehr kleinen Risikofaktor haben Hier kommen andere berlegungen zum Zug zum Beispiel ob die Firma einen solchen Schaden finanziell berlebt oder ob der Schaden sozial noch tolerierbar ist Bei Risikokombinationen k nnen die resultierenden Risikofaktoren anhand eines Entschei dungsbaums bestimmt werden Risikofaktor 1 10 50 100 10 Relative Eintretens wahrschein lichkeit Relative Schadenh he Aistein harmloses Risiko e Die Risiken B und C haben den gleichen Risikofaktor und sind somit etwa gleich gef hrlich e Dist ein sehr gef hrliches Risiko welches unbedingt unter Kontrolle gebracht werden muss Eist ein sogenanntes Restrisiko welches anders beurteilt werden muss siehe Text BILD 4 6 Beurteilung von Risiken In der Risikobewertung werden die Konsequenzen aus der Risikoanalyse gezog
26. Grundstein f r ein leicht pflegbares System Es erleichtert das Auffinden zu ndernder Teile erm glicht lokale nderungen unter Wahrung der urspr nglichen Strukturen und erlaubt die Auswirkungen von Erweiterungen und Erg nzungen abzusch tzen und zu begrenzen In der Konzipierung begangene Fehler sind h ufig gar nicht oder mit nur gro em Aufwand reparierbar Soll Software beschafft werden so muss in der Konzipierung daf r gesorgt werden dass Aufgabe und L sung hinreichend zusammenpassen Sorgf ltiges Konzipieren ist daher f r jede Art von professionell entwickelter Software wirtschaftlich 6 2 Definitionen und Begriffe Das Konzipieren einer L sung ist die Erstellung und Dokumentation des Architekturentwurfs oder Grobentwurfs eines Systems Dabei werden die wesentlichen Komponenten der L sung und die Interaktionen zwischen diesen Komponenten festgelegt Im Englischen spricht man von Architectural Design DEFINITION 6 1 Architektur architecture Die Organisationsstruktur eines Systems oder einer Komponente IEEE 610 12 DEFINITION 6 2 Entwurf design 1 Der Prozess des Definierens von Architektur Komponen ten Schnittstellen und anderen Charakteristika eines Systems oder einer Komponente 2 Das Ergebnis des Prozesses gem 1 IEEE 610 12 DEFINITION 6 3 L sungskonzept Das Dokument welches das Konzept der L sung d h die Architektur der zu erstellenden Software dokumentiert Synonyme Software Architektur Sys
27. Organisation ein Zertifikat f r ihr Qualit tsmanagementsystem braucht oder will Dies ist beispielsweise der Fall wenn ein gro er Kunde einen Auftrag davon abh ngig macht dass das Qualit tsmanagementsystem des Auftragnehmers gewissen Mindestanforderungen gen gt oder wenn sich die Organisation von der Zertifizierung einen Wettbewerbsvorteil erhofft In der Regel wird nach der Normenreihe ISO 9000 zertifiziert 9 3 Qualit tspr fung 9 3 1 Allgemeines Die Qualit tspr fung stellt fest ob ein Arbeitsergebnis den Vorgaben entspricht Letztlich ist zu pr fen ob ein fertiggestelltes Produkt die an das Produkt gestellten Anforderungen erf llt Mit der Pr fung darf jedoch nicht bis zum Abschluss der Entwicklung gewartet werden weil verfehlte Ziele dann m glicherweise nicht mehr oder nur mit sehr hohen Kosten doch noch er reichbar sind Oualit tspr fung ist daher eine permanente die Entwicklung begleitende Aufgabe Man un terscheidet zwei Arten der berpr fung die Validierung und die Verifikation Bild 9 4 Definition 9 4 Validierung Der Prozess der Beurteilung eines Systems oder einer Komponente w hrend oder am Ende des Entwicklungsprozesses mit dem Ziel festzustellen ob die spezifizierten Anforderungen erf llt sind IEEE 610 12 Validierung ist folglich die Pr fung ob ein Arbeitsergebnis geeignet ist die Erwartungen der Endbenutzer zu erf llen d h ob berhaupt das richtige Produkt entwickelt wird Definition
28. Software Management Volume 1 Systems Thinking New York Dorset House 5 Software Aufwandsch tzung 47 5 Software Aufwandsch tzung 5 1 Allgemeines Bild 5 1 zeigt wie man es nicht machen sollte Eine erste Aufwandsch tzung wird zun chst nach unten korrigiert um den Auftrag zu bekommen Anschlie end wird die Sch tzung jedesmal dann nach oben angepasst wenn sie von den tats chlichen Kosten eingeholt worden ist Die Sch tzung nach sieben Monaten ist offenbar die erste die wirklich seri s durchgef hrt wurde Sie zeigt dass schon die erste Sch tzung viel zu optimistisch war ganz zu schweigen von der politischen Sch tzung nach drei Monaten Tausend 4000 US Dollar 3200 2400 1600 L 800 Tats chliche Kosten O l y nach Boehm 1981 0 6 12 18 24 36 Monate BILD 5 1 Unr hmliches Beispiel f r die Kostenentwicklung eines Projekts Es gibt viele Gr nde f r die zum Teil krassen Fehleinsch tzungen von Software Kosten bzw Terminen u a e Software Erstellung ist weitgehend Kopfarbeit und daher stark von der Leistungsf higkeit die ser K pfe abh ngig Diese Leistungsf higkeit kann um mehr als eine Gr enordnung schwan ken e Nur ein kleiner Teil einer Software tr gt die eigentliche Funktionalit t Ein gro er Teil des Aufwands und das wird oft bersehen geht in Verwaltung Fehlerbehandlung Benutzer schnittstelle etc Bild 5 2 e Erfahrungen aus k
29. St rungen im Ablauf sowohl pr ventiv als auch reaktiv bek mpft Qualit t ist wichtig da das fertige Produkt anschlie Bend gepflegt und in der Regel weiterentwickelt werden muss Systematische Pflege Wartung ist ein kontinuierlicher Prozess welcher die Erhaltung der Gebrauchstauglichkeit eines Software Produkts zum Ziel hat Der Prozess regelt nicht nur die Reaktion auf aufgetretene Probleme sondern plant und lenkt auch die Weiterentwicklung der Software und ihre laufende Anpassung an ein sich wandelndes Umfeld 1996 2001 by Martin Glinz Alle Rechte vorbehalten Reproduktion zum nicht kommerziellen Gebrauch mit Quellenangabe gestattet Reproduktion auch auszugsweise zum kommerziellen Gebrauch nur mit schriftlicher Bewilligung des Verfassers gestattet 20 Martin Glinz Software Engineering I 3 1 2 Software Projekte Jede systematische Entwicklung von Software sowie alle gr eren abgrenzbaren Pflegevor haben ben tigen einen Abwicklungsrahmen Dies ist in der Regel ein Software Projekt DEFINITION 3 2 Projekt Eine zeitlich befristete Organisationsform zur Bearbeitung einer gege benen Aufgabe Dient zur Regelung der Verantwortlichkeiten und zur Zuteilung der f r die Arbeit notwendigen Ressourcen Software Projekte unterscheiden sich von klassischen technischen Entwicklungsprojekten Der wesentlichste Unterschied ist dass in den klassischen Disziplinen das entstehende materielle Produkt eine Reihe von nat rlichen Ansatzpun
30. System werden in Form von Szenarien aufgeschrieben und durchgespielt Szenarien eignen sich besonders gut zur interaktiven Gewinnung und Diskussion von Anforderungen mit den Kunden e Den Anwendungsbereich modellieren Feststellen welche Gegenst nde der Anwendung f r das zu spezifizierende System relevant sind Relevant sind diejenigen Gegenst nde ber die das System Information speichern muss damit es seine Aufgaben erf llen kann Herausfin den welche Eigenschaften der relevanten Gegenst nde und welche Beziehungen der Gegen st nde untereinander dem zu spezifizierenden System bekannt sein m ssen Begriffe kl ren Anwendungsszenarien Glossar bilden und durchspielen Problem stellung Soll Proze abl ufe Anwendungsbereich untersuchen modellieren Bild 7 5 Ans tze zur Anforderungsgewinnung Um die gew nschten Informationen von den Vertretern des Kunden zu erhalten k nnen ver schiedene Techniken eingesetzt werden e In Interviews werden die Vertreter des Kunden einzeln oder in Gruppen zu h chstens drei Leuten befragt e Mit Fragebogen k nnen Begriffswelt und Bed rfnisse einer gr eren Gruppe von Kundenver tretern erfasst werden e In gemeinsamen Arbeitstagungen manchmal auch Joint Application Development Sitzungen genannt kann eine Gruppe ausgew hlter Kundenvertreter und Informatiker gemeinsam die Anforderungen an ein geplantes System erarbeiten Die Ergebnisse der Analyse werden mittels geeigneter Meth
31. VAF in einem Bereich zwischen 0 65 und 1 35 liegt Die Function Points FP eines Systems berechnen sich dann zu 5 9 FP UFP x VAF Sollen Function Points zur Aufwandsch tzung verwendet werden so muss der zu erwartende Aufwand pro Function Point bekannt sein Entsprechende Kurven oder Tabellen sind im Umlauf Bild 5 6 sind aber mit Vorsicht zu genie en Der Aufwand pro Function Point ist stark von projektspezifischen und unternehmensspezifischen Faktoren abh ngig beispielsweise vom K n nen der Leute im betreffenden Unternehmen der verwendeten Entwicklungsumgebung und dem Stellenwert von Qualit t z B Umfang der verlangten Dokumente mittlerer Testaufwand Fer 1 In manchen Publikationen hei t dieser Faktor auch TCF Technical Complexity Factor 5 Software Aufwandsch tzung 53 ner muss gekl rt werden welche Aufgaben in der Aufwandsch tzung enthalten sind beispiels weise ob der Aufwand f r die Anforderungsspezifikation eingeschlossen ist oder nicht Wie Bild 5 6 zeigt k nnen schon innerhalb desselben Unternehmens signifikant unterschiedliche Umrechnungskurven resultieren TABELLE 5 3 Schema zur Bestimmung der Einflussfaktoren IFPUG 1994 Einzusetzen sind Werte zwischen 0 und 5 Z Faktor Datenkommunikation Verteilte Funktionen nicht vorhanden kein Einfluss Leistungsanforderungen unbedeutender Einfluss Belastung der Hardware m iger Einfluss Verlangte Transaktionsrate durchs
32. Vorl ufige Antwort Fehlerbehebung Abschlie ende Antwort 138 Martin Glinz Software Engineering I Abschluss und Ablage der Problemmeldung Auslieferung von neuem Release abgelehnt bewilligt i zu ndernde Software Einheiten in Arbeitsumgebung kopieren nderungen durchf hren ge nderte Einheiten mit neuer Versionsnummer in Referenz umgebung bringen Einheiten testen und freigeben Neue Konfiguration neues Release bilden Bild 11 5 Ablauf einer nderung Zitierte und erg nzende Literatur Babich W A 1986 Software Configuration Management Reading Mass Addison Wesley Bersoff E K V P Henderson S G Siegel 1980 Software Configuration Management Engle wood Cliffs N Y Prentice Hall Conradi R B Westfechtel 1998 Version Models for Software Configuration Management ACM Computing Surveys 30 2 June 1998 232 282 Fr hauf K J Ludewig H Sandmayr 1991 Software Projektmanagement und Oualit ts sicherung Z rich Verlag der Fachvereine und Stuttgart Teubner IEEE 1983 IEEE Standard for Software Configuration Management Plans ANSVIEEE Std 828 1983 IEEE Computer Societey Press IEEE 1987 IEEE Guide to Software Configuration Management ANSVIEEE Std 1042 1987 IEEE Computer Societey Press Anhang Problemmeldungsformular 11 Konfigurationsverwaltung 139 Problemmeldung Verfasser Telefon Fax E mail Adresse Betrifft Problem ist
33. allen anderen technischen Pro dukten Bei Software geht die Evolution jedoch besonders schnell Dies hat zwei wichtige Kon sequenzen FESTSTELLUNG 3 4 Es ist unm glich Software vom P oder E Typ so zu entwickeln dass sie w hrend einer mehrj hrigen Lebensdauer ohne jegliche nderungen ihre Aufgaben zur vollen Zufriedenheit der Benutzer erf llt Pflege Wartung ist bei dieser Art von Software kein Unfall der durch sorgf ltigere Ent wicklung h tte vermieden werden k nnen sondern ein unvermeidlicher Bestandteil der zu lei stenden Arbeit Bis zu einem Drittel des Gesamtaufwands f r ein Software Produkt entf llt auf die Weiterentwicklung des Produkts w hrend der Nutzung vgl Bild 1 3 Alle berlegungen zu Software seien sie technischer oder wirtschaftlicher Art d rfen daher nicht isoliert nur f r die Software Entwicklung gemacht werden sondern m ssen sich auf die gesamte Lebensdauer der Software beziehen FESTSTELLUNG 3 5 Dauert die Entwicklung von Software vom P oder E Typ l nger als ca ein halbes Jahr so ist es kaum m glich nach einem Satz einmal erhobener und dann festgeschriebe ner Anforderungen so zu entwickeln dass das fertige Produkt bei seiner Inbetriebnahme die Be d rfnisse der Leute die es benutzen sollen optimal befriedigt Sich ver ndernde Anforderungen sind bei P und E Software demnach ebenfalls kein Unfall sondern problembedingt Da solche Ver nderungen Instabilit ten und Mehrkosten in den Proje
34. der erste Schritt der L sung eines Systems Als Vorgabe muss eine Anforderungsspezifikation existieren Je nach gew hltem Prozessmodell f r den gesamten Entwicklungsprozess wird die Anforderungsspezifikation vollst ndig vor dem 6 Konzipieren von L sungen 67 L sungskonzept erstellt oder die Erstellung erfolgt verzahnt aber mit separater Dokumentation von Anforderungen einerseits und L sung andererseits Es sind sowohl hierarchische als auch zeitliche Verzahnung m glich Bei der hierarchischen Verzahnung werden aus Globalanforde rungen erste grunds tzliche L sungsentscheide abgeleitet Diese induzieren Anforderungen an die Komponenten dieser Globall sung Aus diesen Anforderungen werden wieder L sungskon zepte abgeleitet die wiederum zu Anforderungen an Teilsysteme dieser L sungen f hren k n nen usw Zeitliche Verzahnung entsteht bei Verwendung von Wachstumsmodellen Das L sungskonzept wiederum ist die Vorgabe f r die Realisierung der Software d h den Detailentwurf die Codierung und die Integration Auch hier gibt es vor allem bei Wachstums modellen eine zeitliche Verzahnung von Architekturentwurf und Realisierung Der Architekturentwurf grenzt sich vom Detailentwurf ab indem im Architekturentwurf nur die Komponenten ihre Schnittstellen und ihre Interaktionen festgelegt werden nicht aber die in terne Realisierung der Komponenten durch Algorithmen und verborgene Datenstrukturen Letzteres ist Aufgabe des Detailentwur
35. e generell ber die Einhaltung der Review Regeln zu wachen und diese freundlich aber be stimmt durchzusetzen 9 4 3 2 Schreiber Der Schreiber erstellt den Review Bericht Dieser entsteht f r alle sichtbar indem der Schreiber w hrend der Sitzung fortlaufend am Hellraumprojektor auf Folien schreibt Die bri gen Teilnehmer k nnen so das Geschriebene laufend verfolgen und Einspruch erheben wenn sie meinen es sei etwas nicht ad quat notiert worden Schreiber und Moderator sollten m glichst nicht die gleiche Person sein 9 4 3 3 Gutachter Die brigen Review Teilnehmer haben die Aufgabe das zu pr fende Material in der Vorbe reitung zu begutachten und in der Sitzung ber ihre Erkenntnisse zu berichten Die Autoren des zu pr fenden Materials k nnen nicht gleichzeitig Gutachter sein Die Gutachter sind in der Regel Entwickler aus anderen Projekten der gleichen Abteilung oder des gleichen Bereichs Gegebe nenfalls k nnen f r bestimmte Probleme Fachgutachter oder Qualit tsingenieure herangezogen werden Die Gutachter sollen e sich sorgf ltig vorbereiten e alle wichtigen Punkte in der Sitzung nennen e sich nicht pers nlich profilieren wollen und nicht alles besser wissen e den anderen gut zuh ren und nicht bereits genannte Dinge erneut aufbringen e w hrend der Sitzung zu einer positiven offenen und kooperativen Atmosph re beitragen Der Schreiber kann gleichzeitig auch Gutachter sein 9 4 3 4 Autor Der Autor bzw ein Vert
36. funktioniert oder ein elektrisches Ger t in Betrieb nehmen ohne wissen zu m ssen wie der Strom in die Steckdose kommt Eine Bank ist aus der Sicht der Kunden ebenfalls eine klassisches nach dem Geheimnisprin zip arbeitendes System Sie erbringt f r ihre Kunden ber eine Schnittstelle Schalter Banco mat Leistungen Geld entgegennehmen und sicher aufbewahren Guthaben wieder auszah len Dabei wissen die Kunden nur was die Bank leistet Wie die Leistungen erbracht werden zum Beispiel wie die Bank die Kontenf hrung organisiert oder wie sie die Kundeneinlagen so anlegt dass sie verlangte Auszahlungen jederzeit leisten kann bleibt nach au en verborgen Das Geheimnisprinzip ist f r beide Seiten wichtig Die Kunden wollen ihr Konto benutzen ohne wissen zu m ssen wie eine Bank funktioniert und ohne von bankinternen Organisations nde rungen betroffen zu sein Die Bank will ihr Gesch ft unabh ngig von den Kunden organisieren und sie will insbesondere nderungen in der Realisierung ihrer Leistungen vornehmen k nnen ohne dies mit allen Kunden abstimmen zu m ssen Im Software Entwurf sind die Komponenten Module die Leistungen Teill sungen Das WAS ist in der Modulschnittstelle beschrieben das WIE sind die Entwurfsentscheidungen und ihre Realisierung durch Programme Bei Software gibt es vier typische Arten von Entwurfsent scheidungen e wie eine Funktion realisiert ist zum Beispiel die Kalkulation einer Versicherungspr mie e
37. gef hrt werden kann WAS WER WANN Kundenwoche CO SOLL IST 17 18 19 20 21 22 23 24 25 26 aktueller Stand Meyer Schneider Erich Sn Proog Schneider 2 a DB Anpassung Fritschi l ___ Tanner i i i Wechselstube Meyer Tr Kursinfo Schneider eE Installation Fritschi Abnahme Schneider Vorprojekt MO Mi M21 M22 Wi M M5 M32 M6 BILD 4 2 Beispiel eines kombinierten Arbeits Personaleinsatz Terminplans f r ein kleines Projekt Es gibt heute eine Vielzahl von Projektf hrungs Werkzeugen f r Rechner zu kaufen mit denen man solche Diagramme erstellen und nachf hren sowie SOLL IST Vergleiche durchf h ren kann Es ist au erordentlich wichtig dass die geplanten und die tats chlichen Aufwendungen m g lichst genau erfasst und dokumentiert werden Denn nur auf der Grundlage verl sslicher Zahlen ber abgewickelte Projekte sind gute Aufwandsabsch tzungen f r neue Projekte m glich 4 2 Projektkontrolle und lenkung Planung ist nur sinnvoll wenn auch kontrolliert wird ob der Arbeitsfortschritt der Planung entspricht Fortschrittskontrollen m ssen messbare Ergebnisse haben wenn sie n tzlich sein sollen Andernfalls ger t man rasch in die Falle des 90 Syndroms Bild 4 3 Die wichtigsten Kontroll Ma nahmen sind Termin Sachziel Kosten und Risikoverfolgung Terminverfolgung geschieht mit Hilfe von Meilensteinen In der Planung hat jeder Meilen stein einen Soll Termin Jedesmal wenn ein Meilenstein
38. gew nschten Endzustand geplant Dabei k nnen ver schiedene Merkmale schrittweise ausgebaut werden zum Beispiel die Funktionalit t der Bedie nungskomfort die Leistung oder die Verwendbarkeit Mit letzterem ist beispielsweise der Aus bau von einer Einzweck zu einer Vielzweckanwendung oder von einem dedizierten zu einem portablen System gemeint In F llen wo ein Auftraggeber keine Teillieferungen will bzw man nicht mit Teilprodukten auf den Markt gehen will kann ein Wachstumsmodell trotzdem sinnvoll eingesetzt werden Die Lieferungen erfolgen dann intern Vorteile sind eine bessere Projektkontrolle und lieferf hige Teile wenn der Liefertermin f r das Gesamtsystem nicht eingehalten werden kann 3 Der Software Prozess 27 Wachstumsmodelle haben die folgenden Vorteile Sie modellieren das nat rliche Verhalten der meisten gro en Systeme Sie sind ein sehr geeignetes Instrument zur Projektf hrung Die Projektf hrung im Gro en erfolgt mit den Meilensteinen der Lieferungen Da jede Lieferung lauff hig sein muss ist eine wirksame Kontrolle der Meilensteine m glich Im Kleinen wird jede Lieferung ber die Mei lensteine eines ergebnisorientierten Phasenmodells kontrolliert Es entstehen sehr schnell lauff hige Teile des Systems Dies f rdert die Motivation der Pro jektbeteiligten und hilft dem Auftraggeber seine gr ten N te fr hzeitig zu lindern Das System kann sanft eingef hrt werden Es k nnen Erfahrungen in re
39. ist m glich e Das Modell ist eine idealisierte L sung In vielen F llen ist es daher m glich die L sung ana log zur Struktur der Aufgabenstellung zu strukturieren Dies spart Entwicklungsaufwand und vereinfacht das Verst ndnis der L sungsstruktur Die Tatsache dass das Modell eine idealisierte L sung ist stellt aber gleichzeitig auch einen Nachteil dar Es besteht die Gefahr dass e bei der Modellierung auf die Implementierung geschielt wird statt sich auf die Beschreibung der Anforderungen zu konzentrieren e suboptimale L sungen entstehen wenn die L sungsstruktur von der Anforderungsstruktur un ver ndert bernommen wird Konstruktive Darstellungen sind vor allem bei der Modellierung von Anforderungen im Gro en angezeigt 7 5 2 Formalit tsgrad der Darstellung Bei jeder Systementwicklung m ssen die vollst ndig informalen Ideen und Vorstellungen der Auftraggeber in eine vollst ndig formale Notation n mlich den Programmcode berf hrt wer den Verfahren zur Spezifikation von Anforderungen unterscheiden sich wesentlich in der Frage wie weit die Formalisierung schon w hrend des Spezifizierens erfolgen soll Bild 7 9 Eine informale Spezifikation erfolgt in der Regel deskriptiv mit nat rlicher Sprache Formale Spezifikationen verwenden formale Kalk le die sich mathematischer Mittel bedie nen Es sind sowohl konstruktive wie deskriptive Verfahren m glich Petrinetze zum Beispiel sind konstruktiv Spezifikation m
40. kleinem berschaubarem Rahmen entwickelt hergestellt und vertrieben so er brigen sich spezielle Ma nahmen zur Sicherstellung der Qualit t Pfuscharbeit hat sofortige R ckwirkungen auf deren Verursacher einerseits weil Hersteller und Abnehmer einander kennen andererseits weil es im Kleinbetrieb eine wirksame Kontrolle und h ufig ein traditionelles qualit tsbewusstes Berufsethos gibt Dies ist z B typisch der Fall in kleinen handwerklichen Meisterbetrieben Qualit tsmanagement im eigentlichen Sinn gab es historisch erst mit der industriellen Massenproduktion wo die Qualit t in der Produktion vor allem durch statistische Verfahren sichergestellt wurde Qualit tsmanagement in der Entwicklung von Produkten ist nochmals wesentlich j nger da Massenph nomene Probleme die sich auch in der Entwicklung nur noch durch Arbeitsteilung und Gruppenarbeit l sen lassen zunehmende Anonymisierung Entfremdung von Entwicklern und Produkten dort erst in den vergangenen 30 40 Jahren aufgetreten sind Software Qualit tsmanagement ist der j ngste Spross bei dem es speziell um die Qualit t von industriell entwickelter Software geht 9 1 1 Definitionen Im allgemeinen Sprachgebrauch wird Qualit t meistens mit einem hohen Wert auf einer absoluten G teskala assoziiert Im Gegensatz dazu bezeichnet der industrielle Qualit tsbegriff eine relative G te die sich an der Erf llung zuvor aufgestellter Ziele bemisst Definition 9 1 Qualit t Die Ges
41. l uft Die Korrektheit eines Programms kann durch Testen au er in trivialen F llen nicht bewiesen werden Der Grund daf r ist einfach F r einen Korrektheitsbeweis m ssten alle Kom binationen aller m glichen Werte der Eingabedaten getestet werden Schon f r ein triviales Programm das lediglich zwei mit 16 Bit repr sentierte ganze Zahlen addiert w ren 216 x 216 F lle zu testen Testen setzt voraus dass die erwarteten Ergebnisse bekannt sind Folglich muss entweder gegen eine Spezifikation oder gegen vorhandene Testergebnisse getestet werden Letzteres ist zum Beispiel der Fall wenn Tests nach Programmodifikationen wiederholt werden sogenannter Regressionstest Unvorbereitete und undokumentierte Tests sind sinnlos Nicht alle Eigenschaften eines Programms k nnen mit Testen gepr ft werden Qualit ts merkmale wie zum Beispiel Portabilit t oder Pflegbarkeit sind nicht testbar 9 Qualit tsmanagement 123 Mit Testen werden nur Fehlersymptome nicht aber die Fehlerursachen gefunden Auf jeden Test muss daher eine Phase folgen in der die Ursachen zu den festgestellten Symptomen gefun den und behoben werden 9 5 2 Testablauf In jedem Test gibt es drei Phasen Die Planung die Vorbereitung und die Durchf hrung des Tests In der Testplanung wird die Teststrategie festgelegt und werden im Rahmen der Projekt planung die notwendigen Arbeiten und die daf r erforderlichen Ressourcen geplant In der Testvorbereitung werden die
42. nnen beispielsweise folgende Lenkungsma nahmen in Betracht gezogen werden e die Bereitstellung zus tzlicher Ressourcen 42 Martin Glinz Software Engineering I e die Befreiung von Projektmitarbeitern von Verpflichtungen au erhalb des Projekts e die Anordnung von berstunden e die Vergabe von Teilauftr gen an Dritte e Abstriche bei den zu erreichenden Sachzielen e Etappierung der Sachziele nach der Art eines Wachstumsmodells Wenn erkannt wird dass der Projektplan trotz Gegenma nahmen nicht mehr einhaltbar ist so muss der Projektplan den neuen Gegebenheiten angepasst werden Nach unrealistischen Pl nen zu arbeiten ist demotivierend und wenig effektiv ProjektleiterIn tungen Ergebnisse Information Zufall St rungen BILD 4 4 Lenkung eines Software Entwicklungsprojekts 4 3 Der Projektabschluss Der Projektabschluss ist fast so wichtig wie der Projektstart Es geht darum das entstandene Produkt geordnet in die Phase der Pflege berzuleiten und das entstandene Projektwissen zu sichern Die w hrend des Projekts entstandenen Dokumente und Messungen werden abgeschlos sen Aus den Messwerten werden interessierende Gesamtgr en bestimmt zum Beispiel Gesamtaufwand und totale Durchlaufzeit des Projekts Eine kurze Projektgeschichte h lt SOLL und IST bez glich Sache Terminen Kosten und Personalaufwand fest und berichtet ber wichtige Erfahrungen die in zuk nftigen Projekten von Nutzen sein k nnten Alle f r d
43. on Software Engineering 22 1 68 85 Conte S D H E Dunsmore V Y Shen 1986 Software Engineering Metrics and Models Menlo Park CA etc Benjamin Cummings Fenton N E 1991 Software Metrics A Rigorous Approach London etc Chapman amp Hall Weinberg G E Schulman 1974 Goals and Performance in Computer Programming Human Factors 16 1 70 77 3 Der Software Prozess 19 3 Der Software Prozess Software Prozesse beschreiben den Ablauf der Entwicklung und der Pflege von Software In diesem Kapitel werden zun chst einige grundlegenden Ph nomene im Zusammenhang mit Soft ware Prozessen beschrieben Dann werden ausgew hlte Prozessmodelle f r die Entwicklung von Software vorgestellt Anschlie end wird die Rolle von Prototypen und von Wiederverwendung und Beschaffung im Entwicklungsprozess diskutiert Ausf hrungen zum Prozess der Software Pflege schlie en das Kapitel ab 3 1 Grundlagen 3 1 1 Software Prozesse Den Ablauf eines Vorhabens mit der Beschreibung der Schritte der beteiligten Personen der f r diesen Ablauf ben tigten Informationen und der dabei entstehenden Informationen nennen wir einen Prozess DEFINITION 3 1 Prozess Eine Folge von Schritten die zur Erreichung eines gegebenen Zwecks ausgef hrt wird IEEE 610 12 Wir unterscheiden dabei zwischen ad hoc Prozessen die spontan individuell und ungeregelt ablaufen und systematischen Prozessen deren Ablauf geplant und gelenkt wird Auch die He
44. sind funktionale Koh sion der Modul realisiert eine in sich geschlossene Funktion oder objektbezogene Koh sion der Modul enth lt ein Datenob jekt und alle zu seiner Bearbeitung erforderlichen Operationen Dazwischen gibt es verschie dene Koh sionsstufen logisch kommunikativ sequentiell prozedural die hier nicht n her dis kutiert werden sollen F r Details sei auf Stevens Myers und Constantine 1974 sowie auf Page Jones 1988 verwiesen DEFINITION 6 6 Kopplung coupling Ein Ma f r die Abh ngigkeit zwischen zwei Modulen Die Modularisierung ist umso besser je geringer die wechselseitige Kopplung zwischen den Modulen ist Inhaltskopplung ein Modul ver ndert direkt lokale Daten oder Code eines anderen Moduls ist unter allen Umst nden zu vermeiden Globale Kopplung Daten die von allen Modulen gele sen und ver ndert werden k nnen ist zu vermeiden oder allenfalls auf wenige Daten zu be schr nken Datenbereichskopplung Module kommunizieren ber Datenbereiche die sie ge meinsam haben oder sich gegenseitig zur Verf gung stellen ist akzeptabel Anzustreben ist Datenkopplung nur die tats chlich ben tigten Daten werden ber wohldefi nierte Schnittstellen bertragen Auch die konsequente Anwendung des Prinzips dass jedes Datum einem Modul geh rt und nur von diesem ver ndert werden darf reduziert die Kopplung Bei Bedarf stellt der Eigent mer eines Datums Operationen zur kontrollierten Manipulation des Dat
45. sofern sie richtig entwickelt worden ist Die nachfolgenden Ausf hrungen beziehen sich daher auf Software vom P und E Typ Die Pflegema nahmen werden in der Regel in drei Klassen unterteilt Fehlerbehebung Anpassung und Weiterentwicklung Erweiterungen Verbesserungen Bild 1 3 zeigt die typische Verteilung des Aufwands auf die drei Klassen DEFINITION 3 9 Pflege Wartung maintenance Modifikation bestehender Software und oder Erg nzung bestehender Software durch neue Software mit dem Ziel Fehler zu beheben die be stehende Software an ver nderte Bed rfnisse oder Umweltbedingungen anzupassen oder die be stehende Software um neue F higkeiten zu erweitern Bei gro er Software die zudem bei mehreren Kunden in Betrieb ist ist es unm glich jede nderung sofort in Betrieb zu nehmen Der Verwaltungs und Installationsaufwand w re viel zu hoch Stattdessen werden die nderungen geb ndelt und von Zeit zu Zeit en bloc als neuer Release freigegeben siehe auch Kapitel ber Konfigurationsmanagement DEFINITION 3 10 Release Eine konsistente Menge von Komponenten eines Systems die ge meinsam zur Benutzung freigegeben werden Bei Software bestehen die Komponenten aus einer Menge von Programm Daten und Steu erkomponenten die zusammen ein betriebsf higes System bilden sowie aus Komponenten wel che das System und seine Benutzung dokumentieren Meist wird zwischen kleinen und gro en Releases unterschieden und dies durch die Numm
46. solchen vorhanden sind sollten sie daher unbe dingt geschaffen bzw eingef hrt werden e H ufig werden beim Review nicht nur Befunde im Pr fling sondern auch Fehler in den Refe renzunterlagen gefunden Solche Befunde werden ebenfalls erhoben und auf einer separaten Befundliste notiert 9 4 5 Der Review Bericht F r den Review Bericht werden mit Vorteil vorbereitete Formbl tter verwendet Ein Beispiel wie solche Formbl tter aussehen k nnen findet sich im Anhang Das Deckblatt wird vom Moderator vorbereitet Am Ende der Sitzung wird dort der Gesamtbefund notiert und von allen Beteiligten mit ihrer Unterschrift best tigt Daran angeheftet wird die Liste der Befunde Dies sind Papierkopien von allen Folien die der Schreiber w hrend der Sitzung beschrieben hat 9 5 Testen Das Thema Testen wird hier nur kurz behandelt weil dieses Skript sich auch an Leute richtet die nicht Informatiker sind aber mit Software umgehen m ssen Im brigen wird auf die einschl gige Literatur verwiesen 9 5 1 Grunds tze Mit Tests werden zwei Ziele verfolgt e Im Test sollen m glichst viele der in einem Programm vorhandenen Fehler gefunden werden Myers 1979 Testen ist der Prozess ein Programm mit der Absicht auszuf hren Fehler zu finden e Aus der Tatsache dass das Programm mit einer Menge von Testdaten fehlerfrei l uft soll mit brauchbarer statistischer Sicherheit darauf geschlossen werden dass das Programm auch im Einsatz fehlerfrei
47. tbar Bild 1 5 e Gleiches gilt f r die Beurteilung des Entwicklungsstands Behauptet ein Bauunternehmen der Bau sei praktisch fertig obwohl erst der Rohbau steht so ist leicht feststellbar dass diese Behauptung nicht stimmt Die Beurteilung des Fertigstellungsgrads von Software ist ungleich schwieriger und aufwendiger e Software ist scheinbar sehr flexibel und leicht zu ndern Es gibt ja kein Material das dabei umgeformt oder gar neu produziert werden muss Kleinst Software ist tats chlich leicht nder bar Mit zunehmender Gr e der Software hat jede nderung jedoch so viele Effekte und Kon sequenzen die alle bedacht sein m ssen dass die tats chlichen Aufwendungen f r Software nderungen oft h her sind als diejenigen f r vergleichbare materielle Produkte Diese mechanische Konstruktion Wie erkennen wir aber Fehler in der hier ist offensichtlich falsch gespeicherten Software Konstruktion BILD 1 5 Software kann man nicht anfassen FESTSTELLUNG 1 3 Software verh lt sich im mathematischen Sinn unstetig Software ist Bestandteil eines digital arbeitenden Rechnersystems Solche Systeme haben die unangenehme Eigenschaft dass kleinste Ver nderungen in Programmen oder Daten Im Extrem fall gen gt schon die Setzung eines Punkts anstelle eines Kommas massive Ver nderungen im Verhalten des Systems bewirken k nnen Es ist daher ungleich schwieriger und aufwendiger das wunschgem e Funktionieren von Software mit ei
48. ternehmensinterne Profit Center g be die vom Handel mit wiederverwendbaren Software Kom ponenten leben Ans tze in dieser Richtung sind beispielsweise kommerziell vertriebene Klas senbibliotheken und Software Rahmen Frameworks Eine andere M glichkeit zur F rderung von Wiederverwendung innerhalb eines Unterneh mens ist die Schaffung einer Informationsstelle f r Wiederverwendung Diese tr gt Informatio nen ber wiederverwendbare Software zusammen und f hrt einen Katalog Interessierte Projekt leiter bzw Entwickler k nnen sich bei der Informationsstelle nach vorhandenen Komponenten f r ihr Problem erkundigen Wichtig ist dass beim Sammeln das Holprinzip herrscht die Informationsstelle sammelt selbst aktiv bei den Entwicklungsabteilungen diese werden nicht mit zus tzlichem Aufwand belastet sonst kooperieren sie nicht 3 4 3 Beschaffung Wo immer m glich werden Systeme bzw Software Komponenten nicht entwickelt sondern beschafft Dies hat rein konomische Gr nde aufgrund der verkauften St ckzahlen ist be schaffte Software fast immer kosteng nstiger als selbst entwickelte Allerdings fallen neben den reinen Beschaffungskosten fast immer auch Parametrierungs und Anpassungskosten an so dass die Wirtschaftlichkeit einer Beschaffung in jedem Einzelfall gepr ft werden muss Der Beschaffungsprozess ist typisch in den Software Entwicklungsprozess eingebettet weil Spezifikations Test und Installationsarbeiten auch bei Besch
49. 00 1000 Organic mode 100 200 300 400 500 600 Product size KDSI BILD 5 4 Aufwandssch tzung nach COCOMO Quelle Boehm 1981 Diese Gleichungen gelten f r einfache Anwendungsprogramme organic mode F r Pro grammsysteme semidetached mode bei denen ein erheblicher Anteil an Interaktion mit Betriebssystem Ger tetreibern etc hinzukommt und f r eingebettete Systeme embedded mode deren Erstellung nochmals erheblich schwieriger ist gelten andere Faktoren COCOMO Grundgleichungen f r Programmsysteme 5 3 MM 3 0 KDs 0 35 5 4 TDEV 2 5 MM COCOMO Grundgleichungen f r eingebettete Systeme 5 5 MM 3 6 KDSI 0 32 5 6 TDEV 25 MM Bild 5 4 zeigt eine graphische Veranschaulichung der Kosten ber der Produktgr e Die mit den Grundgleichungen ermittelten Nominalwerte k nnen nun noch erheblich genauer gemacht werden indem man sie mit einer Reihe von Kostenfaktoren multipliziert Bild 5 5 zeigt Boehm s Kostenfaktoren Tabelle Die aktuellen Werte aller Kostenfaktoren f r ein Projekt wer den unabh ngig voneinander gesch tzt und anschlie end alle miteinander multipliziert Der 5 Software Aufwandsch tzung 51 Nominalwert f r den Projektaufwand in Personenmonaten wird dann mit diesem Produktfaktor multipliziert 5 7 MMkorr Produkt der Kostenfaktoren x MMnominal Ratings Very Very Extra Cost Drivers Low Low Nominal High High High Product Attributes RELY Required software reliability
50. 6 Spezifikation mit Anwendungsf llen Die Klassenmodelle in Objektorientierten Spezifikationen modellieren weder den System kontext noch die Interaktionen zwischen einem System und seiner Umgebung Weil dies aber beides wichtige Elemente einer Anforderungsspezifikation sind werden objektorientierte Spezi fikationen heute meist durch ein Anwendungsfallmodell welches die Interaktionen zwischen den systemexternen Akteuren und dem System modelliert erg nzt Jacobson et al 1992 Definition 7 6 Anwendungsfall Eine durch genau einen Akteur angesto ene Folge von System ereignissen welche f r den Akteur ein Ergebnis produziert und an welchem weitere Akteure teilnehmen k nnen Jeder Anwendungsfall spezifiziert die notwendige Folge von Interaktionschritten bei der Ausf hrung einer essentiellen Systemfunktion Er wird informal durch Text oder teilformal beispielsweise durch Zustandsautomaten vgl Bild 7 12 modelliert Ein Anwendungsfall diagramm zeigt den Systemkontext und die Menge aller Anwendungsf lle Bild 7 23 Die zwei uses Beziehungen modellieren die gemeinsame Verwendung eines Sub Anwendungsfalls durch zwei andere Anwendungsf lle Postbearbeitung registrieren vorsortieren Sekretariat USES Chef USES weiterleiten archivieren Bild 7 23 Anwendungsfalldiagramm 7 Spezifikation von Anforderungen 103 7 6 Pr fung von Anforderungen 7 6 1 Worum es geht Beim Pr fen einer Anforderungsspezifikati
51. 9 5 Verifikation 1 Der Prozess der Beurteilung eines Systems oder einer Komponente mit dem Ziel festzustellen ob die Resultate einer gegebenen Entwicklungsphase den Vorgaben f r diese Phase entsprechen 2 der formale Beweis der Korrektheit eines Programms IEEE 610 12 Benutzer Erwartungen access zzocH Anforderungs spezifikation Architektur der L sung Detail Entwurf ehren Validierung Verifikation Bild 9 4 Validierung und Verifikation 9 Qualit tsmanagement 117 Verifikation ist demnach Pr fung ob ein Arbeitsergebnis den f r den betreffenden Arbeitsschritt gegebenen Vorgaben gen gt d h ob das Produkt richtig entwickelt wird Der Beweis der Korrektheit von Programmen ist ein Verifikationsverfahren auf der Grundlage formaler mathematischer Mittel Zur Validierung k nnen grunds tzlich keine mathematisch formalen Verfahren verwendet werden da die Benutzererwartungen nicht formalisierbar sind Bei der Verifikation der Zwischenprodukte einer Entwicklung dagegen ist es grunds tzlich m glich mathematisch formale Verfahren zu verwenden welche die Korrektheit der Entwick lung beweisen Der daf r erforderliche Aufwand ist jedoch so gro dass die formale Verifikation in der Praxis nur eine Nischenrolle spielt zum Beispiel zur Entwicklung der hochkritischen Komponenten in sicherheitskritischen Systemen Die Pr fverfahren die heute in der Praxis eingesetzt werden bzw einge
52. 91 behandelt alle Gebiete der Informatik mit Bezug zum Software Engineering einschlie lich der Grundlagen und Randgebiete in knappen bersichtsartikeln in der Art einer Enzyklop die aber nach Sachgebieten nicht nach Stichworten geordnet Der Begriff Software Engineering wurde von Bauer auf einer NATO Konferenz in Garmisch Partenkirchen gepr gt Der Tagungsband dieser Konferenz Naur Randell und Buxton 1976 gibt einen Eindruck der damaligen Situation Weinberg 1971 DeMarco und Lister 1991 und Glinz 1988 behandeln Probleme der Soft ware Psychologie der Menschenf hrung in der Software Entwicklung und den Gegens tzen zwischen rationalen und emotionalen Einstellungen im Software Engineering Zitierte Literatur Boehm B 1981 Software Engineering Economics Englewood Cliffs N J Prentice Hall Boehm B 1987 Improving Software Productivity IEEE Computer 20 9 Sept 1987 43 57 Brooks F P 1995 The Mythical Man Month Essays on Software Engineering Anniversary Edition Reading Mass etc Addison Wesley DeMarco T T Lister 1991 Wien wartet auf Dich Der Faktor Mensch im DV Management M nchen Wien Hanser Fairley R 1985 Software Engineering Concepts New York etc McGrawHill Glinz M 1988 Emotionales und Rationales im industriellen Software Engineering Techni sche Rundschau 20 88 78 81 IEEE 1990 Standard Glossary of Software Engineering Terminology IEEE Std 610 12 1990 IEEE
53. 985 Software Engineering Concepts New York etc McGraw Hill 82 Martin Glinz Software Engineering I Freeman P A I Wasserman eds 1983 Tutorial on Software Design Techniques IEEE Computer Society Press Order Number 514 Gamma E R Helm R Johnson J Vlissides 1995 Design Patterns Elements of Reusable Object Oriented Software Reading Mass etc Assison Wesley Garlan D M Shaw 1993 An Introduction to Software Architecture In V Ambriola and G Tortora eds Advances in Software Engineering and Knowledge Engineering World Scientific Publishing Company Singapore 1 39 Auch erschienen als technische Bericht von CMU bzw SEI CMU CS 94 166 CMU SEI 94 TR 21 Ghezzi C M Jazayeri D Mandrioli 1991 Fundamentals of Software Engineering Engle wood Cliffs Prentice Hall IEEE 1990 Standard Glossary of Software Engineering Terminology IEEE Std 610 12 1990 IEEE Computer Society Press Krasner G E S T Pope 1988 A Cookbook for Using the Model View Controller User Inter face Paradigm in Smalltalk 80 Journal of Object Oriented Programming 1 3 26 49 Kruchten P 1995 The 4 1 View Model of Architecture IEEE Software 12 6 Nov 1995 42 50 McDermid J 1991 Software Engineer s Reference Book Oxford Butterworth Heinemann ca 1200 p Meyer B 1988 Object Oriented Software Construction Englewood Cliffs N J Prentice Hall auf Deutsch Objektorientierte Softwareentwicklung M
54. 996 ZWECK Die Objekte der Klasse MeasurementList modellieren Messreihen VERANTWORTLICHKEITEN Speicherung Skalierung Filterung und Abfrage von Messreihen import java awt List public class MeasurementList extends List MeasurementList wird Unterklasse von List KLASSEN Variablen final private static double TOLERANZ 0 30 30 zugelassene TOLERANZ nach unten INSTANZ Variablen double wert Listeneintrag Messwert als reelle Zahl Measurementlist naechstes Zeiger auf n chstes Element der verketteten Liste Hinweis zur Dokumentation Ein Objekt auf das eine Methode Operation angewendet wird wird aktuelles Objekt genannt Hinweis zur Implementierung Jede auch die leere Liste wird durch ein Objekt abgeschlossen dessen Wert undefiniert ist und dessen Zeiger naechstes auf kein weiteres Objekt sondern auf null zeigt void add double element Erste Version von Martin Arnold 06 12 1996 Letzte Aenderung von Martin Glinz 18 12 1996 PRE 8 Realisierung 109 POST An die aktuelle Liste d h diejenige die mit dem aktuellen Objekt beginnt wird ein Element mit der Zahl element als Wert angeh ngt Das aktuelle Objekt bleibt erstes Element der Liste SA MeasurementList temp this Referenz auf aktuellen Listenbeginn erstes Element while temp naechstes null Suche nach letztem Element temp temp naechstes temp naechstes new Measu
55. Arbeiten nicht d h sie sind nicht intelligent weder k nstlich noch nat rlich sie f hren zwar in den meisten F llen zu verbesserter Qualit t der Produkte machen aber das Qualit tsmanagement Reviews Tests etc nicht berfl ssig Ein isolierter Einsatz von Werkzeugen bringt in der Regel wenig oder kann sogar kontrapro duktiv sein Werkzeuge m ssen als eine Komponente in einer Gesamtstrategie f r rechner gest tztes Software Engineering aufgefasst werden Bild 12 1 Glinz 1990 Die Sache Software Engineering und das Mittel computergest tzt d rfen in ihrer Wichtigkeit nicht miteinander verwechselt werden Seit etwa 1986 werden Werkzeuge vor allem solche f r Spezifikation und Entwurf von Software h ufig mit dem Schlagwort CASE computer aided software engineering bezeichnet Bild 12 1 Elemente einer Strategie f r computergest tztes Software Engineering 1994 1998 by Martin Glinz Alle Rechte vorbehalten Reproduktion zum nicht kommerziellen Gebrauch mit Quellenangabe gestattet Reproduktion auch auszugsweise zum kommerziellen Gebrauch nur mit schriftlicher Bewilligung des Verfassers gestattet 142 Martin Glinz Software Engineering I Produktivit tssteigerungen von 20 50 sind durch geeigneten Werkzeugeinsatz durchaus erreichbar Dieser Produktivit tsgewinn stellt sich jedoch nicht sofort ein Wird ein Werkzeug neu eingef hrt so m ssen die Mitarbeiter intensiv geschult werden und m ssen sich an den Um g
56. Benutzer erst kennenlernen und verstehen m ssen damit sinnvolle Gespr che ber das SOLL gef hrt wer den k nnen e die St rken und Schw chen des IST Systems nicht bekannt sind e Teile des IST Systems bernommen werden sollen und festgestellt werden muss welche Teile das sind e das IST System eins zu eins bernommen werden soll beispielsweise wenn ein System auf eine andere Rechnerplattform bertragen werden muss Hierzu ist es in der Regel nicht erforderlich je ein vollst ndiges Implementierungsmodell und essentielles Modell zu erstellen Jede ber das Notwendige hinausgehende Besch ftigung mit dem IST System verursacht Kosten denen kein Nutzen gegen bersteht Ferner besteht bei der Ableitung der Anforderungen aus dem IST System immer die Gefahr dass alter Wein in neue Schl uche abgef llt wird und m gliche neue innovative Wege nicht erkannt werden 7 5 Darstellung von Anforderungen Die m glichen Darstellungsformen unterscheiden sich konzeptionell vor allem in drei Aspek ten e Art der Darstellung konstruktiv oder deskriptiv e Formalit tsgrad der Darstellung e Verf gbare Gliederungs und Abstraktionsmittel Alle drei Aspekte werden im Folgenden skizziert 7 5 1 Art der Darstellung Deskriptive Darstellung Eine deskriptive Darstellung betrachtet das zu spezifizierende System als schwarzen Kasten Bild 7 6 Die Anforderungen werden durch Beschreibung der geforderten Zusammenh nge zwischen den geforderten Resul
57. Benutzer sehr hilfreich Ein solches Glossar sollte daher in jedem gr eren Entwicklungsprojekt projektbegleitend erstellt werden 10 3 Projektdokumente Die wichtigen Projektdokumente sind der Projektplan der Qualit tsplan und das Projekt protokoll Der Projektplan dokumentiert den geplanten Projektablauf wobei den Sollvorgaben w hrend der Projektabwicklung laufend die IST Werte gegen bergestellt werden Der Oualit tsplan enth lt die Vorgaben die das Projekt betreffend Qualit t zu beachten hat Ist ein standardisierter Rahmen Qualit tsplan vorhanden sind projektspezifische Qualit tspl ne h ufig nicht erforderlich Das Projektprotokoll enth lt alle Schriftst cke und Berichte z B nderungsantr ge Re view und Testprotokolle Fortschrittsberichte Sitzungsprotokolle die im Verlauf der Projekt abwicklung anfallen 10 4 Dokumentverwaltung Dokumente die man nicht findet wenn man sie braucht oder solche die nicht mehr aktuell sind sind von zweifelhaftem Wert Dokumente m ssen daher der Konfigurationsverwaltung vgl Kapitel 11 unterworfen werden Vor allem die folgenden drei Dinge sind wichtig 134 Martin Glinz Software Engineering I Klassifikation Leichtes Finden durch geordnetes Ablegen Jedes Dokument hat einen eindeutigen Namen Alle Dokumente haben einheitlich gestaltete Deckbl tter Jedes Blatt jedes Dokuments hat eine Kopfzeile mit folgenden Angaben Projekt Dokument name evtl Kurzname V
58. Cliffs N J Prentice Hall 298 p Knappe teilweise oberfl chliche Behandlung einer Sammlung von SE Themen Schwerpunkt auf Spezifikation und Entwurf Grundprobleme und Zusammenh nge werden nicht verdeutlicht Ludewig J Hrsg 1991 Software und Automatisierungsprojekte Beispiele aus der Praxis Stuttgart Teubner 227 p Kein Lehrbuch sondern eine Zusammenstellung von Erfahrungsberichten ber abgewickelte Software Projekte aus der Praxis Besonders f r Studierende ein guter Einblick in Anwendung bzw Nicht Anwendung von Software Engineering Prinzipien in der Praxis Marco A 1990 Software Engineering Englewood Cliffs N J Prentice Hall 544 p Darstellung etwas breit Themenauswahl im Detail z T etwas eigenwillig keine klare und systematische Dar stellung der Grundprinzipien Mayrhauser A von 1990 Software Engineering Methods and Management San Diego Academic Press 864 p In Inhalt und Aufbau von m iger Qualit t teilweise veraltet viel zu umfangreich nicht empfehlenswert McDermid J 1991 Software Engineer s Reference Book Oxford Butterworth Heinemann ca 1200 p Behandelt alle Gebiete der Informatik mit Bezug zum Software Engineering einschlie lich der Grundlagen und Randgebiete in knappen bersichtsartikeln in der Art einer Enzyklop die aber nach Sachgebieten nicht nach Stichworten geordnet Nachschlagewerk kein Lehrbuch Nagl M 1990 Softwaretechnik Methodisches Programmiere
59. Computer Society Press Lehman M M L A Belady Hrsg 1985 Program Evolution Processes of Software Change London etc Academic Press Naur P B Randell J N Buxton Hrsg 1976 Software engineering concepts and techni ques proceedings of the NATO conferences Neuausgabe der Proceedings der NATO Konfe renz von 1968 und der Nachfolgekonferenz von 1969 New York Petrocelli McDermid J 1991 Software Engineer s Reference Book Oxford Butterworth Heinemann ca 1200 p Oz E 1994 When Professional Standards are Lax The CONFIRM Failure and its Lessons Communications of the ACM 37 10 Oct 1994 29 36 Weinberg G M 1971 The Psychology of Computer Programming New York Van Nostrand Reinhold Lions J L 1996 ARIANE 5 Flight 501 Failure Report by the Inquiry Board Paris ESA http www esrin esa it htdocs tide Press Press96 arianeSrep html 2 Zielsetzung Messung 13 2 Zielsetzung Messung Ohne definierte Ziele ist keine systematische Software Entwicklung m glich Eine systemati sche Zielerreichung ist nur dann m glich wenn die Ziele kontinuierlich verfolgt und Abwei chungen festgestellt werden Hierzu sind Messungen erforderlich In diesem Kapitel werden die Problematik der Zielsetzung und Zielverfolgung sowie die Grundlagen der daf r erforderlichen Messtechnik behandelt 2 1 Das Zielsetzungsproblem Zielgerichtetes Arbeiten ist eine notwendige Voraussetzung f r jegliche Art von systemati
60. Element ausketten temp vorgaenger naechstes else aktuelles Element ist erstes Listenelement Listenanker listenanker temp naechstes Listenanker neu setzen temp listenanker else Element im TOLERANZDbereich vorgaenger temp temp temp naechstes 110 Martin Glinz Software Engineering I return listenanker R ckgabe Erstes Listenelement der bereinigten Liste Beispiel 8 2 Trick Programmierung mit Seiteneffekten in C Die nachfolgende Prozedur h ngt die Zeichenkette s an die Zeichenkette t an und speichert das Ergebnis in t Man beachte dass die R mpfe der beiden verwendeten Schleifen leer sind Alle Effekte sind als Seiteneffekte in den Schleifensteuerungen versteckt void strcat char s char t WHILE t FOR t t s t lt t concat s 8 3 Pr fung und Integration Software wird typischerweise komponentenweise realisiert Jede Komponente wird nach ihrer Fertigstellung zun chst f r sich allein gepr ft Die wichtigsten Pr fverfahren sind e Pr fung auf syntaktische Richtigkeit durch einen Compiler e Pr fung auf inhaltliche Richtigkeit durch Inspektion e Selbstinspektion durch die Autorin oder den Autor e Formale Inspektion vgl Kapitel ber Qualit tsmanagement durch Dritte e Komponententest vgl Kapitel ber Qualit tsmanagement Die fertiggestellten und gepr ften Komponenten m ssen anschlie end zu einem System in tegriert werden Di
61. Entwicklung falsche Funktionalit t quantifizierte Ziele sorgf ltige Spezifikation Prototypen Beteiligung des Auftraggebers falsche Benutzerschnittstelle Prototypen Einbezug der Endbenutzer oft nicht identisch mit den Auftraggebern Vergoldung berfl ssiger Luxus Kosten Nutzen Analyse Setzen von Priorit ten in den Zielen kostenorientierte Entwicklung sich st ndig ver ndernde Setzen von Wichtigkeits Schwellwerten unterhalb derer nicht ge n Anforderungen dert wird nderungsfreundlicher Entwurf z B durch Information Hiding Entwicklung mit Wachstumsmodell Probleme mit zugekauften sorgf ltige Auswahl z B mit Benchmarks Eingangs Qualit ts Komponenten kontrolle Probleme mit extern vergebenen berpr fung des Auftragnehmers vor Auftragsvergabe klar formu Auftr gen lierte Auftr ge Zwischeninspektionen w hrend der Abwicklung Abnahmeinspektion Auftr ge mit Erfolgshonorar Nichterreichen der verlangten Absch tzung in Review Simulationen Prototypen Messung und Leistungen z B Reaktionszeit Optimierung berforderung der Mitarbeiter Aufgaben Analyse Ausbildung Reduktion der Anforderungen in Bezug auf ihr software Entwicklung mit Wachstumsmodell technisches K nnen In der Risikoanalyse wird die Gef hrlichkeit der einzelnen Risiken bestimmt und werden Probleme untersucht die sich aus dem gleichzeitigen Eintreten mehrerer Risiken ergeben Die Gef hrlichkeit eines Risikos ist abh ngig von zwei
62. Entwicklung Beteiligten haben erhebliche Ein fl sse auf das was in einer Entwicklungsabteilung tats chlich geschieht Der Einfluss des Emo tionalen ist umso st rker je weniger er den Beteiligten bewusst ist Glinz 1988 12 3 3 Arbeitsumgebung Da Software von Menschen gemacht wird haben Ausbildung und Arbeitsumgebung dieser Menschen einen erheblichen Einfluss auf den Produktionsprozess Im Buch von DeMarco und Lister 1991 werden verschiedene Aspekte dieses Problems betrachtet Aufgaben 12 1 Eine Software Entwicklungsabteilung schreibt rote Zahlen Anstatt ein besonders spar sames Budget vorzulegen beantragt die Abteilungsleiterin zum Erstaunen der Gesch fts leitung eine Investition von 100 000 Franken zur Modernisierung der Arbeitspl tze der Entwicklerinnen und Entwickler sowie f r Umm blierungen und Gardinen Was k nnte sich die Frau dabei gedacht haben 12 2 Ein Unternehmen will die Produktivit t seiner Software Entwicklungsabteilung verbes sern Beschreiben Sie welche Rolle Werkzeuge dabei spielen k nnen Zitierte und weiterf hrende Literatur Boehm B 1987 Improving Software Productivity IEEE Computer 20 9 Sept 1987 43 57 Brooks F P 1995 The Mythical Man Month Essays on Software Engineering Anniversary Edition Reading Mass etc Addison Wesley Neuausgabe des Originals von 1975 DeMarco T T Lister 1991 Wien wartet auf Dich Der Faktor Mensch im DV Management M nchen Wien Han
63. Gute Darstellung der Entwicklungsphasen Objektorientierung wurde in der dritten Auflage hinzugef gt die zweite Auflage hie noch schlicht Software Engineering was der Darstellung teilweise noch anzumerken ist Manage ment Aspekte des Software Engineerings werden eher oberfl chlich behandelt Sehr gute Verweise auf weiter f hrende Literatur Schach S R 1999 Classical and Object Oriented Software Engineering with UML and Java Fourth edition Boston WCB McGraw Hill 616 p Teilweise reorganisierte leicht erweiterte und aktualisierte Fassung von Schach 1996 Beispiele neu mit UML und Java Keine Einf hrung in UML bzw Java Sommerville 1 1995 Software Engineering Fifth Edition Reading Mass Addison Wesley 742 p deutsche bersetzung der zweiten Auflage ebenfalls bei Addison Wesley 1987 Umfassende Darstellung des Themas In der F lle ist jedoch das Wesentliche nicht mehr gut zu erkennen Darstel lung trotz ihres Umfangs zum Teil oberfl chlich In vielen Bibliotheken ist auch die vierte Auflage von 1992 noch greifbar Deutsche Ausgabe in manchen Punkten nicht mehr aktuell Management Aspekt zuwenig gewichtet Suhr R R Suhr 1993 Software Engineering Technik und Methodik M nchen Wien Olden bourg 415 p Darstellung verschiedener schwergewichtig technischer Aspekte des Software Engineerings Ansprechend im Auf bau leider in der Ausf hrung vieler Themen unbefriedigend van Vliet H 1993 Softwar
64. Kosten verbunden sein Fragt man sich nach der Wirtschaftlichkeit dieser Aufwendungen so ist folgendes zu beachten Risikof hrungs kosten amortisieren sich bei jedem Projekt bei dem die Risikof hrung das Eintreten eines gr e ren Risikos verhindert oder dessen Schaden erheblich mindert Einen entsprechenden Nachweis zu f hren ist im Einzelfall allerdings oft schwierig In Projekten in denen es r ckblickend keine Probleme mit Risiken gab sind die Risikof hrungskosten hnlich zu betrachten wie Versiche rungspr mien Sie sind in vern nftigem Umfang eingesetzt im statistischen Mittel wirtschaft lich und sie vermindern drastisch die Wahrscheinlichkeit dass der Risikofall zur finanziellen Katastrophe wird Aufgaben 4 1 Gegeben sei das Problem aus Aufgabe 2 5 System zur statistischen Auswertung von Be triebsdaten Zum Umfeld sei folgendes zus tzlich bekannt Sie verf gen als ProjektleiterIn ber eine erfahrene Gruppe von Entwicklerinnen und Entwicklern Allerdings hat die Informatikerin welche bei der Entwicklung des Vorg ngersystems die Konzepte erstellt und die Hauptarbeit geleistet hatte vor einem Monat das Unternehmen verlassen Wegen Sparma nahmen in Ihrer Firma hat Ihre Chefin die Stelle bisher nicht wiederbesetzen d rfen Einen Ihrer Projektmitarbeiter m ssen Sie f r ein strategisches Projekt an eine andere Abteilung ausleihen Sie verf gen damit ber rund 30 weniger Arbeitskapazit t als Sie f r die Abwicklung Ihr
65. Martin Glinz Software Engineering Vorlesungsskript WS 2001 2002 Inhalt Einf hrung Software Entwicklung als Problem Zielsetzung Messung Der Software Prozess Software Projektf hrung Software Aufwandsch tzung Konzipieren von L sungen Spezifikation von Anforderungen Realisierung Qualit tsmanagement 10 Dokumentation ll _ Konfigurationsverwaltung 12 _ Produktivit tsfaktoren Literatur ON ABEND Vorbemerkung Dieses Skript ist als Grundlage f r eine zweist ndige Einf hrungsvorlesung in das Gebiet des Software Engineerings an der Universit t Z rich konzipiert Es wurde aus den Unterlagen zu verschiedenen Vorlesungen und Kursen des Verfassers zusam mengestellt Teile der Unterlagen insbesondere die Kapitel 1 bis 5 sind neu erstellt oder syste matisch berarbeitet worden andere wurden bernommen und nur in der u eren Form angepasst Die Darstellung ist daher nicht ganz homogen Es ist vorgesehen mit der Zeit alle Kapitel im gleichen Stil wie die Kapitel 1 bis 5 zu gestalten Z rich im Dezember 1996 Mit wenigen Fehlerkorrekturen und einer Modifikation in Kapitel 5 neu aufgelegt f r das WS 1997 98 Z rich im September 1997 Die 1996 geplante berarbeitung der Kapitel 6 12 konnte bisher nur teilweise realisiert werden Das Kapitel 6 wurde vollst ndig erneuert und erheblich erweitert In Kapitel 7 wurden die Defini tionen berarbeitet und ein neuer Abschnitt ber Anwendungsf lle hinzugef gt In e
66. Rechnern leicht realisierbar und zweitens sind sie leichter zu verstehen und zu entwerfen als Programme in denen mehrere Dinge gleich zeitig parallel ablaufen Viele Probleme erfordern jedoch die gleichzeitige koordinierte Bearbeitung mehrerer Auf gaben sei es lokal an einem Ort oder geographisch verteilt auf mehrere Orte Solche Probleme sind nicht oder nur sehr schlecht mit sequentiellen Programmen l sbar Stattdessen wird die L sung in diesem Fall auf mehrere nebenl ufige Prozesse aufgeteilt DEFINITION 6 8 Prozess process Eine durch ein Programm gegebene Folge von Aktionen die sich in Bearbeitung befindet Ein Prozess entsteht also zu dem Zeitpunkt wo seine erste Aktion begonnen wird und er ver schwindet nach Abschluss seiner letzten Aktion In dieser Zeit ist er entweder aktiv d h er ar beitet nach dem gegebenen Programm oder er wartet auf ben tigte Ressourcen oder er wartet auf einen anderen Prozess zum Beispiel um mit ihm zu kommunizieren DEFINITION 6 9 Nebenl ufigkeit concurrency Die parallele oder zeitlich verzahnte Bearbei tung mehrerer Aufgaben W hrend ihrer Arbeit m ssen Prozesse in der Regel miteinander kommunizieren d h sie m ssen Informationen austauschen oder ihren Arbeitsfortschritt synchronisieren H ufig wird auch beides miteinander kombiniert Die zur Synchronisation notwendigen Konzepte und Konstrukte werden vom Betriebssystem oder von einer Laufzeitumgebung f r die verwendete Programmiersp
67. Releases ist statistisch konstant Bild 3 8 b Offensichtlich sind die Tr gheitsdynamik gro er Systeme und Organisationen sowie die begrenzten F higkeiten sowohl der Systementwickler wie der Systembenutzer zum Be und Verarbeiten Verdauen von nderungen so stark dass sie die Eingriffe von au en marginalisieren den Pflegeprozess statistisch stabilisieren und ihn selbstregulierend machen Cumulative Modules Changed 3 Der Software Prozess 33 nm M O Qi 4 78 Modules Changed per Day a Se ERGEBEN 8 400 800 1200 1600 O 5 10 15 20 a Lehman Days RSN nd S ady 1985 BILD 3 8 A Kumulierte Anzahl ge B nderungsrate ber der Folge der Releases nderter Module RSN Release sequence number Aufgaben 3 1 3 2 3 3 3 4 3 5 Ein zu entwickelndes System besteht aus einer Basiskomponente mit Datenbank und Be nutzerschnittstelle sowie sechs voneinander weitgehend unabh ngigen Anwendungsfunk tionen F r die Basiskomponente wird ein Entwicklungsaufwand von 12 Personenwochen gesch tzt der Aufwand pro Anwendungsfunktion auf je drei Personenwochen Sie sind Projektleiterin Ihr Management verlangt einen Meilenstein mit dem Kriterium System zu 80 fertig a Wie reagieren Sie b Formulieren Sie ein messbares Kriterium f r einen solchen Meilenstein Gegeben sei das Problem aus Aufgabe 2 5 Statistischen Auswertung von Betriebsdaten a Welches Prozessmodell schlagen Sie f r die Entwicklung der
68. affungen notwendig sind Die Hauptarbeit ist im Rahmen der Konzipierung der Software zu leisten siehe Kapitel ber Konzi pierung 3 Der Software Prozess 31 3 4 4 Wiederverwendung und Beschaffung im Entwicklungsprojekt Alle Anstrengungen zur Mehrfachverwendung von Software Wiederverwendung Verwen dung beschaffter Software sind nutzlos wenn die Entwicklerinnen und Entwickler nicht mit machen Projektleitende und Entwickelnde d rfen ihren Berufsstolz nicht darin sehen m glichst alles selbst neu und perfekt zu machen Sie m ssen vielmehr lernen dass nicht das Perfekte und Teure die beste L sung ist sondern das Gebrauchstaugliche das so weit wie m glich aus vorhandenen Komponenten gefertigt ist Die Suche nach Beschaffbarem bzw Wiederverwendbarem muss zur fest verankerten T tig keit in jedem Projekt werden Damit zeitgerecht entschieden werden kann sind bereits w hrend der Anforderungsspezifikation entsprechende Vorabkl rungen zu treffen Die Mitarbeiterinnen und Mitarbeiter d rfen nicht danach beurteilt werden ob sie m glichst viel Neues produzieren Sie m ssen vielmehr danach beurteilt werden ob sie N tzliches und Be darfsgerechtes unter Verwendung von m glichst viel Vorhandenem produzieren 3 5 Pflege Wartung Pflege oft auch Wartung maintenance genannt ist der Prozess der systematischen Erhal tung der Gebrauchstauglichkeit von Programmen Software vom S Typ vgl Abschnitt 3 1 4 braucht keine Pflege
69. alen Pilotanwendungen gesammelt werden Umstellung Schulung der Mitarbeiter etc k nnen schrittweise erfolgen Dem stehen folgende Nachteile gegen ber Es besteht die Gefahr dass anstelle eines geschlossenen Systems viele nicht ganz zusammen passende Teilsysteme entstehen Die Konzepte und Strukturen der ersten Lieferungen k nnen durch Erg nzungen und nde rungen in sp teren Lieferungen bis zur Unkenntlichkeit entstellt werden so dass sich die Pflegbarkeit des Gesamtsystems drastisch verschlechtert Systematisches sorgf ltig geplantes Arbeiten ist daher beim Einsatz von Wachstums modellen besonders wichtig Die Verwendung eines Wachstumsmodells darf kein Vorwand f r ein Abgleiten in die ad hoc Entwicklung sein Wachstumsmodelle eignen sich vor allem wenn das System gro ist und eine lange Entwicklungszeit hat nicht die volle Funktionalit t sofort erforderlich ist man ein Software Vorhaben nicht vorab in allen Einzelheiten definieren Kann sondern zu n chst Erfahrungen sammeln will oder muss ein Basisprodukt schnell auf dem Markt bzw beim Kunden sein soll 3 2 4 Das Spiralmodell Das Spiralmodell Bild 3 6 ist eine von Boehm 1988 stammende Weiterentwicklung des Wasserfall Modells Es ist vor allem f r die Entwicklung gro er risikoreicher Systeme gedacht Anstelle der zyklischen Abfolge Entwickeln pr fen entwickeln pr fen tritt beim Spiral modell ein vierteiliger Zyklus der in der graphisch
70. alit tsleiter welcher unmittelbar an die Gesch ftsleitung berichtet Bild 9 2 Gesch fts leitung OB GL l Qualit ts leiter J r 7 1 l Bereich Bereich i I l Q Ing Qualit tsingenieur OB Qualit tsbeauftragter Bild 9 2 Das Qualit tswesen im Unternehmen Im Qualit tswesen ist das Fachwissen ber Qualit t insbesondere ber Qualit tsmanage mentverfahren konzentriert Die Qualit tsverantwortung liegt jedoch nicht allein beim Qualit tswesen sondern muss vom ganzen Unternehmen getragen werden 9 2 2 Grunds tze des Qualit tsmanagements Im Qualit tsmanagement gelten die folgenden sechs Grunds tze Grundsatz 1 Qualit t in der Entwicklung wie in der Produktion muss erzeugt werden sie kann nicht erpr ft werden Grundsatz 2 Qualit t bezieht sich immer sowohl auf die hergestellten Produkte wie auf die Prozesse zur Herstellung Entwicklung und Produktion dieser Produkte Schlampige Herstellungsprozesse sind eine denkbar schlechte Voraussetzung f r die Herstel lung guter Produkte Wer qualitativ hochwertige Produkte will das was letztlich z hlt muss daher auch f r qualitativ einwandfreie Herstellungsprozesse sorgen 114 Martin Glinz Software Engineering I Grundsatz 3 Die Qualit tsverantwortung liegt immer bei den gleichen Leuten welche auch die Sach Termin und Kostenverantwortung haben d h bei den F hrungskr ften in der Linie wie in Projektorganisationen und bei den
71. amm oder Klassenbibliotheken genutzt werden e K nnen Architektur und Entwurfsideen wiederverwendet werden zum Beispiel durch Ver wendung vorhandener Architekturmetaphern und muster oder von Entwurfsmustern design patterns Gamma et al 1995 e Kann soll das L sungskonzept so modifiziert werden dass vorhandene Software wiederver wendet bzw beschafft werden kann F r Beschaffungen und Wiederverwendung gelten die gleichen Abw gungen und Kosten berlegungen wie f r Entwurfsvarianten vgl Abschnitt 6 5 4 Bei den Kosten berlegungen sind zwei spezifische Punkte zu beachten e Wie und in welchem Zeit und Kostenrahmen k nnen Kandidaten gesucht und evaluiert wer den e Welche Parametrierungen Konfigurierungen Anpassungen und Erg nzungen sind notwendig und wieviel kosten diese 6 3 9 sthetik Wie in der Architektur von Geb uden gibt es auch in der Software Architektur eine sthetik Diese u ert sich vor allem in e der Wahl und konsequenten Verwendung eines Architekturstils vgl Abschnitt 6 6 e klar erkennbaren gestalteten Strukturen dies im Gegensatz zu irgendwie Gewordenem oder Gewursteltem e einer der Struktur des Problems angemessenen Struktur der Architektur e der Wahl der einfachsten und klarsten L sung aus der Menge der m glichen L sungen 6 3 10 Qualit t Ein guter Entwurf ist e effektiv das hei t er erf llt die Vorgaben und l st das Problem des Auftraggebers e wirtschaftlich das hei t gebrau
72. amtheit von Merkmalen einer Einheit bez glich ihrer Eignung festgelegte und vorausgesetzte Erfordernisse zu erf llen ISO 8402 Eine Einheit kann ein Produkt eine Dienstleistung eine T tigkeit ein Prozess ein System eine Person eine Organisation etc sein Qualit t im Sinn von ISO 8402 ist folglich Zielerf llung Dennoch schwingt die Vorstellung hoher G te immer mit da eben auch vorausgesetzte Erfordernisse das hei t solche die nicht explizit als Ziele formuliert sind zu erf llen sind Die Gesamtheit der qualit tsrelevanten T tigkeiten in einer Organisation wird als Qualit ts management bezeichnet Definition 9 2 Qualit tsmanagement Alle T tigkeiten der Gesamtf hrungsaufgabe welche die Qualit tspolitik Ziele und Verantwortlichkeiten festlegen sowie diese durch Mittel wie Qualit tsplanung Qualit tslenkung Qualit tssicherung und Qualit tsverbesserung im Rahmen des Qualit tsmanagementsystems verwirklichen ISO 8402 Hinweis Bis vor wenigen Jahren wurde das gesamte Qualit tsmanagement als Qualit ts sicherung bezeichnet Seit 1994 wird in allen Normen die hier verwendete Terminologie be nutzt Der Begriff Qualit tssicherung ist auf die Qualit tsmanagement Darlegung d h den Nachweis der Qualit tsma nahmen beschr nkt worden In der Praxis wird aber immer noch h ufig von Qualit tssicherung gesprochen wenn Qualit tsmanagement gemeint ist Qualit tsmanagement braucht einen organisator
73. an messbare Indi katoren f r das Merkmal bestimmt Die Indikatoren sollen m glichst stark mit dem eigentlichen l Die meisten in der Praxis vorkommenden Verh ltnisskalen sind additiv Additivit t ist aber keine zwingende Eigenschaft 2 Zielsetzung Messung 17 zu messenden Merkmal korreliert sein Die Indikatorma e bilden zusammen ein indirektes Ma f r das interessierende Merkmal BEISPIEL 2 3 Messung der Portabilit t d h des Aufwands ein System von einer bestehenden Hardware Systemumgebung auf eine andere Hardware Systemumgebung zu bertragen Eine genaue Messung der Portabilit t w rde die Bestimmung des Quotienten t port tent erfordern wobei tport der Aufwand f r die Portierung und tent der Aufwand f r die Neuentwicklung auf der neuen Hardware Systemumgebung ist Diese Messung kostet jedoch ein Vielfaches von dem was sie n tzt Als Ausweg kann man die Messung von Portabilit ts Indikatoren heranziehen Bild 2 3 Indikator Skala Messverfahren Planwert Schwellwert Anzahl BS Aufrufe Anzahl Prozeduraufrufe 0 100 Z hlen im Code 5 10 Anteil Hardware oder BS abh ngiger Module 0 100 Z hlen im Code 10 15 Anteil Nichtstandard Codezeilen 0 100 Z hlen Vgl mit 2 5 ISO Standard BILD 2 3 Messung von Portabilit t mit Indikatoren BS Betriebssystem 2 5 Wichtige Ma e f r Ziele in der Software Entwicklung Zur Messung von Produktzielen interessiert man sich vor allem f r Ma e zur Messung der Funktionserf
74. ang mit dem Werkzeug gew hnen Als Konsequenz sinkt die Produktivit t erst einmal anstatt zu steigen Noch schlimmer ist die Situation bei Werkzeugen f r Spezifikation und Entwurf von Software Da beide Bereiche bei manueller Arbeit traditionell vernachl ssigt werden hat der Werkzeugeinsatz zur Folge dass die Spezifikation und Konzipierung deutlich l nger dauern als vorher Der Gewinn macht sich erst in einer verk rzten Realisierung und noch sp ter in niedrige ren Pflegekosten bemerkbar Werkzeugeinsatz ist daher keine Ma nahme die sofort wirksam wird sondern eine Investi tion die sich erst mittelfristig dann aber umso deutlicher auszahlt Nicht zu vernachl ssigen ist neben dem Produktivit tsgewinn ein u U massiver Qualit ts gewinn bei der mit Werkzeughilfe entwickelten Software 12 1 2 Software Produktionsumgebungen Die vollst ndige Software Engineering Umgebung welche alle Aktivit ten von der Formu lierung der ersten Anforderungen bis zur Systemabnahme durchgehend und konsistent unter st tzt ist zwar schon vielfach postuliert und skizziert worden aber es gibt sie immer noch nicht zu kaufen Die heutige Situation ist gepr gt von einer Vielfalt von Systemen mit unterschiedlichen Schwerpunkten welche jeweils einen Teil der Software Engineering Aktivit ten gut einen Teil halbwegs und einen Teil berhaupt nicht unterst tzen 12 1 3 Klassifizierung von Werkzeugen Die heute verf gbaren Werkzeuge lassen sich grob i
75. are Engineering I 6 6 1 _ Funktionsorientierte Architektur Structured Design Structured Design Stevens Myers Constantine 1974 Page Jones 1988 ist der klassische Vertreter einer funktionsorientierten Architektur Die Grundidee ist dass jeder Modul des Sys tems eine Funktion berechnet Zur Realisierung einer Funktion k nnen andere einfachere Funk tionen aufgerufen werden Auf diese Art und Weise entsteht eine Hierarchie von Funktionen wobei unten die elementaren und weiter oben die komplexeren Funktionen stehen Die Funktion an der Spitze der Hierarchie ist das Hauptprogramm Der Datenaustausch zwischen den Modulen erfolgt entweder bei Aufruf und R ckkehr durch Parameter oder durch Zugriff auf explizit modellierte gemeinsame Speicherbereiche Bei den Parametern wird teilweise noch zwischen echten Daten und Steuerinformation unterschieden H ufig werden die Funktionen zus tzlich in Eingabe Verarbeitungs und Ausgabefunktionen gegliedert und die Hierarchie entsprechend strukturiert Bild 6 2 Eine funktionsorientierte Modularisierung kann den in Abschnitt 6 3 2 genannten Kriterien nur teilweise gen gen Alle Aufgaben bei denen eine Gruppe von Funktionen einen gemeinsa men Status verwaltet zum Beispiel Treiber Datenstrukturen oder intern kooperierende Anwen dungsfunktionen lassen sich nicht geeignet behandeln Solche Funktionsgruppen m ssten n m lich nach den Regeln von Abschnitt 6 3 2 zusammen mit den Statusdaten zu einem Modul
76. are vom S T yp ist solche die vollst ndig durch eine formale Spezifikation beschrieben werden kann Die Entwicklung ist erfolgreich wenn die resultierenden Programme nachweis lich die Spezifikation erf llen Typische Beispiele f r S Software sind Programme zum Sortie ren von Daten oder zur Berechnung mathematischer Funktionen e Software vom P Typ ist solche die ein spezifisches abgegrenztes Problem l st Die Entwick lung ist erfolgreich wenn das Problem zufriedenstellend gel st ist Typische Beispiele f r P Software sind Programme welche gegebene Modelle etwa Festigkeitsmodelle in der Statik oder Wettervorhersagemodelle in der Meteorologie berechnen e Software vom E Typ ist solche welche eine in der realen Welt eingebettete Anwendung reali siert Die Entwicklung ist erfolgreich wenn die Anwender mit der Software zufrieden sind FESTSTELLUNG 3 3 LEHMAN Nur Software vom S Typ ist stabil Software vom P und E Typ ist einer Evolution unterworfen Software vom E Typ tr gt selbst zur Evolution bei Evolution bedeutet in diesem Zusammenhang dass ein Produkt aufgrund des sich wandeln den Umfelds selbst einem permanenten Wandel unterliegt Software vom E Typ ist selbst Teil dieses Umfelds und tr gt mit zum Wandel bei Ein Produkt l st durch seine Benutzung Ver nde rungen in seiner Umwelt aus die ihrerseits Ver nderungen des betreffenden Produkts erforder lich machen Die gleichen Mechanismen der Evolution finden wir auch bei
77. atik L sung zu schaffen An Hand eines solchen Prototyps im engeren Sinn k nnen die Angemessenheit von Anforderungen und die Tauglichkeit von L sungen f r den ge planten Verwendungszweck untersucht werden Beispielsweise k nnen so Benutzerbed rfnisse gekl rt oder geplante Benutzerschnittstellen erprobt werden Bei Produktentwicklungen kann ex ploratives Prototyping au erdem zur Gewinnung von Wissen ber einen bisher nicht beherrsch ten Problembereich dienen 3 Der Software Prozess 29 Experimentelles Prototyping wird verwendet um die Realisierbarkeit kritischer Systemteile zu untersuchen und um Entwurfsalternativen zu bewerten Beispielsweise kann so gekl rt wer den ob bestimmte geforderte Leistungen Reaktionszeiten Datenraten erbracht werden k n nen Solche Prototypen werden auch als Labormuster bezeichnet Demonstrationsprototypen Prototypen im engeren Sinn und Labormuster sind Wegwerf Prototypen Das geplante System wird auf der Grundlage des mit den Prototypen erworbenen Wissens neu entwickelt Es ist zul ssig solche Wegwerf Prototypen nicht zu dokumentieren und schnelle softwaretechnisch unsaubere L sungen zu verwenden Es muss allerdings sichergestellt sein dass niemand der Versuchung erliegt aus Software die als Wegwerfprototyp geschrieben wurde dann doch durch Weiterentwicklung ein Produkt zu machen Ist ein solcher Ausbau be absichtigt so muss ein evolution res Prototyping gew hlt werden siehe unten Die
78. ation Kommen vier Verfahren in Betracht e Reviews e Pr f und Analysemittel in Werkzeugen e Simulation e Prototypen Ein Review ist eine formell organisierte Zusammenkunft von Personen zur inhaltlichen oder formellen berpr fung eines Produktteils Dokument Programmst ck etc nach vorgegebenen Pr fkriterien vgl Kapitel 9 4 Reviews sind das Mittel zur Pr fung von Dokumenten Pr f und Analysemittel in Werkzeugen werden immer dann eingesetzt wenn eine Spezifika tion mit Hilfe von Werkzeugen erstellt wurde Insbesondere L cken und Widerspr che in der Spezifikation lassen sich mit solchen Pr fverfahren finden Beispielsweise kann ein Werkzeug pr fen ob jeder verwendete Datenname auch irgendwo definiert ist Mit einer Simulation kann die Ad quatheit des Verhaltens des spezifizierten Systems in be stimmten Situationen untersucht werden Ein Prototyp ist ein lauff higes St ck Software welches Teile eines zu entwickelnden Systems vorab realisiert vgl Kapitel 3 2 5 Er dient als Modell f r die weitere Entwicklung oder f r das zu schaffende Produkt Ein Prototyp ist das m chtigste verf gbare Mittel f r die Beurteilung der Ad quatheit einer Spezifikation durch die zuk nftigen Benutzer Er erm glicht 104 Martin Glinz Software Engineering I in beschr nktem Rahmen eine Erprobung des gew nschten Systems in seiner geplanten Ein satzumgebung Aufgrund der im Vergleich zu anderen Pr fverfahren hohen Kosten f r einen Protot
79. att ber der Zeit aufgetragen werden Ersteres ist aufwendig und wird daher nur selten angewendet Einfacher ist es wieder die Meilensteine heranzuziehen und die Kosten ber den Meilensteinen aufzutragen Bei den Ist Kosten werden dabei die Kosten zum Zeitpunkt der Erreichung des Meilensteins genommen Risikoverfolgung ist in Kapitel 4 4 beschrieben Ein n tzliches Hilfsmittel in der Kontrolle vor allem gr erer Software Projekte ist ein orga nisiertes Berichtswesen z B standardisierte Wochen und Monats Fortschrittsberichte Diese haben im Wesentlichen eine Fr hwarnfunktion indem sie Probleme und St rungen melden be vor sich diese in der versp teten Erreichung von Meilensteinen manifestieren Bei gro en Projekten mit vielen beteiligten Personen haben sich sogenannte Arbeitspaker Ordner engl Unit Development Folder bew hrt In diesen werden alle Ergebnisse sowie alle sonstigen Papiere zu jeweils einem Arbeitspaket eingeheftet Jeder Ordner enth lt ein Leitblatt auf dem die Termine Verantwortlichkeiten und Arbeitsfortschritte f r das zugeh rige Arbeitspaket festgehalten sind Die Arbeitspaket Ordner k nnen physisch als Ordner oder lo gisch als Dateien auf einem Rechner gef hrt werden Werden bei der Projektkontrolle gr ere Abweichungen erkannt so m ssen die Ursachen daf r ergr ndet und entsprechende Lenkungsma nahmen ergriffen werden Bild 4 4 zeigt das Prinzip eines gelenkten Prozesses Bei Termin berschreitungen k
80. be gestattet Reproduktion auch auszugsweise zum kommerziellen Gebrauch nur mit schriftlicher Bewilligung des Verfassers gestattet 108 Martin Glinz Software Engineering I e bei Variablen und Konstanten Bedeutung der Variable bzw Konstante im Kontext des Pro gramms e defensives Programmieren e Vermeiden von Trickprogrammierung und Programmierung mit Seiteneffekten H ufig werden Vorschriften zur Programmiersystematik und zum Programmierstil in Entwicklungsrichtlinien festgehalten Beispiel 8 1 zeigt ein Beispiel f r ein nach den obenstehenden Kriterien erstelltes Programm Beispiel 8 2 demonstriert wie man es nicht machen sollte Das Java Programm in Beispiel 1 wurde nach einer Entwicklungsrichtlinie f r Java Berner et al 1996 dokumentiert Beispiel 8 1 Systematisches Programmieren in Java Dargestellt ist ein Auszug aus einer Klasse zur Verwaltung von Messreihen Da die Mess reihen unterschiedlich lang sein k nnen sind sie intern als verkettete Listen von Datenobjekten realisiert Nach au en ist jedoch f r jede Messreihe nur ein Objekt sichtbar das mit den von der Klasse bereitgestellten Operationen manipuliert wird RER EEEE EE EEEE AUTOR Martin Arnold PROJEKT Beispiel 8 1 Vorlesung Software Engineering JAVA Symantec Cafe Projectmanager 8 2b3 COPYRIGHT Forschungsgruppe Requirements Engineering Institut f r Informatik Universit t Z rich KLASSE Measurementlist VERSION 1 01 vonM Glinz am 18 12 1
81. berg 1982 Handbook of Walkthroughs Inspections and Technical Reviews 3rd edition Boston Toronto Little Brown and Co Fr hauf K J Ludewig H Sandmayr 1991 Software Projektmanagement und Qualit ts sicherung 2 Auflage Z rich vdf und Stuttgart Teubner Fr hauf K J Ludewig H Sandmayr 1991 Software Pr fung Eine Fibel Z rich vdf und Stuttgart Teubner Liggesmeyer P 1990 Modultest und Modulverifikation Reihe Angewandte Informatik Bd 4 Mannheim etc BI Wissenschaftsverlag Liggesmeyer P H M Sneed A Spillner Hrsg 1992 Testen Analysieren und Verifizieren von Software Berlin etc Springer Myers G J 1979 The Art of Software Testing New York John Wiley amp Sons in dt bersetzung Methodisches Testen von Programmen 4 Auflage M nchen Oldenbourg 1991 Russell G W 1991 Experience with Inspection in Ultralarge Scale Developments IEEE Soft ware 8 1 Jan 1991 25 31 Schnurer K E 1988 Programminspektionen Informatik Spektrum 11 6 Dez 1988 312 322 9 Qualit tsmanagement 125 Normen EN 29000 ISO 9000 1987 Qualit tsmanagement und Qualit tssicherungsnormen Leitfaden zur Auswahl und Anwendung EN 29001 ISO 9001 1987 Qualit tssicherungssysteme Modell zur Darlegung der Qualit ts sicherung in Design Entwicklung Produktion Montage und Kundendienst EN 29004 ISO 9004 1987 Qualit tsmanagement und Elemente eines Qualit tssicherungs systems
82. berg 1989 Exploring Requirements Quality before Design Dorset House New York auf Deutsch Software Requirements Anforderungen erkennen verstehen und erf llen Hanser M nchen 1993 IEEE 1990 Standard Glossary of Software Engineering Terminology IEEE Std 610 12 1990 IEEE Computer Society Press IEFE 1993 IEEE Recommended Practice for Software Requirements Specifications IEEE Standard 830 1993 IEEE Computer Society Press Jacobson I M Christerson P Jonsson G vergaard 1992 Object Oriented Software Engi neering A Use Case Driven Approach Amsterdam Reading Mass u a Addison Wesley Kotonya G I Sommerville 1998 Requirements Engineering Processes and Techniques Chichester etc John Wiley amp Sons Martin J 1990 Information Engineering Book 2 Planning and Analysis Prentice Hall Englewood Cliffs N J McDermid J 1991 Software Engineer s Reference Book Oxford Butterworth Heinemann ca 1200 p McMenamin S M J F Palmer 1984 Essential Systems Analysis Yourdon Press New York Oestereich B 1998 Objektorientierte Softwareentwicklung R Oldenbourg Verlag M nchen Pepper P et al 1982 Abstrakte Datentypen Die algebraische Spezifikation von Rechenstruk turen Informatik Spektrum 5 1982 107 119 Rumbaugh J M Blaha W Premerlani F Eddy W Lorensen 1991 Object Oriented Modeling and Design Englewood Cliffs N J Prentice Hall auf Deutsch Objektorienti
83. bwicklung bei Software Pro jekten wesentlich schneller ins Desaster als bei konventionellen Projekten Es ist daher notwen dig Software Projekte systematisch zu f hren Dazu geh ren eine sorgf ltige Planung fortlau fende Kontrolle und n tigenfalls Korrektur des Projektablauf Ferner muss den Projektrisiken besondere Beachtung geschenkt werden 4 1 Projektplanung Die Projektplanung schafft die notwendigen Voraussetzungen f r das Gelingen eines Pro jekts Neben der Definition der zu erreichenden Ziele geht es vor allem darum den Weg zum Ziel und die ben tigten Mittel festzulegen Dabei sind im Wesentlichen folgende Aufgaben zu erledigen die Festlegung des zu verwendenden Prozessmodells und der Organisationsstruktur des Projekts die Bestimmung der Anzahl der ben tigten Personen und die Planung ihres Einsatzes das Aufstellen eines Terminplan und eines Kostenplans die Festlegung der zu erstel lenden Dokumente und der anzuwendenden Verfahren f r Entwicklung Konfigurationsmanage ment und Qualit tsmanagement sowie die Absch tzung und Behandlung der Projektrisiken 4 1 1 Prozessmodell und Organisationsstruktur Zu den ersten Planungsschritten geh ren die Auswahl des Prozessmodells und der Organisa tionsstruktur f r das Projekt auf der Grundlage einer Analyse des Projektkontextes und inhalts Die prinzipielle Struktur der m glichen Prozessmodelle und ihre Eignung in verschiedenen Situationen wurden in Kapitel 3 diskutiert In der P
84. chenresultaten f r Meilensteine 3 2 Prozessmodelle f r die Entwicklung von Software Da man Software nicht sehen kann ist auch der Ablauf in welchem sie entsteht ohne beson dere Ma nahmen nicht erkennbar Es ist daher sehr wichtig eine Modellvorstellung ber den Ablauf der Entstehung von Software zu haben und sowohl die Planung als auch die Kontrolle der Entwicklung an diesem Modell zu orientieren Nur so ist ein Software Projekt f hrbar Ein Software Prozessmodell ist genau eine solche Modellvorstellung Die Wahl eines ge eigneten Prozessmodells ist daher eine der Grundlagen f r eine erfolgreiche Software Projekt f hrung In den folgenden Abschnitten werden ausgew hlte Prozessmodelle vorgestellt und cha rakterisiert 3 2 1 Das Wasserfall Modell Das sogenannte Wasserfall Modell wurde von Royce 1970 entwickelt und sp ter vor allem von Boehm 1981 propagiert Es ist das lteste systematische Prozessmodell f r die Entwick lung von Software Das Wasserfall Modell bertr gt den Software Lebenslauf d h die bei der Entwicklung von Einzelkomponenten beobachtete Reihenfolge von T tigkeiten auf die Entwicklung eines ganzen Systems Bild 3 2 Jede T tigkeit bildet eine Entwicklungsphase Am Ende jeder Phase steht ein Pr fschritt welcher sicherstellen soll dass eine Phase erst verlassen wird wenn alle ben tigten Phasenergebnisse in gepr fter und akzeptierter Form vorliegen Trotzdem geht das Wasserfall Modell davon aus da
85. chnittlicher Einfluss Online Dateneingabe erheblicher Einfluss Effiziente Benutzerschnittstelle starker Einfluss 4 2 3 4 5 6 7 8 Online Daten nderungen 9 Von der Konstruktion des Ma es her Komplexe Verarbeitungen m sste eigentlich VAF 1 gelten wenn alle Faktoren durchschnittlichen Wiederverwendbarkeit Einfluss haben Das w re der Fall 3 wenn durchschnittlicher Einfluss mit Einfache Installation 2 5 statt mit 3 bewertet w rde Aus Praktikabilit tsgr nden hat man sich aber f r den Wert 3 entschieden Installation an mehreren Orten was dazu f hrt dass VAF bei lauter E durchschnittlichen Einfl ssen den Ander und Erweiterbarkeit Wert 1 07 hat Summe der Faktoren TDI Einfache Benutzbarkeit Jones 1996 gibt Faustregeln zur Berechnung des Aufwands aus Function Points an REGEL 5 1 Faustregeln von Jones zur Aufwandberechnung A Durchlaufzeit in Monaten FP0 4 B Anzahl Mitarbeiter FP 150 C Aufwand Durchlaufzeit x Anzahl Mitarbeiter FP0 4 x FP 150 Sollen projektspezifische Faktoren zum Beispiel die F higkeit der beteiligten Personen ihre Vertrautheit mit Problemstellung und die Vertrautheit mit der L sungsplattform ber cksichtigt werden so m ssen bei der Umrechnung von Function Points in Personenmonate zus tzliche Korrekturfaktoren zur Anwendung kommen Das Function Point Verfahren muss folglich wie jedes andere algorithmische Verfahren kali
86. chstauglich kosteng nstig und mehrfachverwendbar bzw mehrfachverwendet e softwaretechnisch gut das hei t leicht verst ndlich robust zuverl ssig und nderungsfreund lich Die Sicherstellung dieser Qualit ten erfordert kontinuierliche Pr fma nahmen im Entwurfs prozess vgl Abschnitt 6 5 3 Pr fung 6 4 Produkte Das Ergebnis des Architekturentwurfs wird in einem Dokument niedergelegt das wir L sungskonzept oder auch Software Architektur nennen Das L sungskonzept dokumentiert die Gliederung der Software in Prozesse die Modularisierung die Interaktionen zwischen den Pro zessen und Modulen die Zuordnung von Ressourcen sowie aspektbezogene Teilkonzepte f r Querschnittsaufgaben wie Datenbankschema Konzept der Mensch Maschine Kommunikation 66 Martin Glinz Software Engineering I Fehlertoleranzkonzept etc Das L sungskonzept dokumentiert auch die Einbettung in vorhan dene Software sowie Beschaffungs und Wiederverwendungsentscheide MUSTER 6 1 M glicher Aufbau eines L sungskonzepts 1 Einleitung 1 1 berblick berblick ber die gew hlte L sung 1 2 Ziele und Vorgaben Beschreibung von Entwurfszielen und Vorgaben die nicht in der Anforderungsspezifikation stehen 1 3 Einbettung und Abgrenzung Wo und wie ist das konzipierte System eingebettet Wie und ber welche Schnittstellen wird mit der Umwelt kommuniziert 1 4 L sungsalternativen Betrachtete aber schlie lich verworfene L sungsalternativen Kurze S
87. d Ausgabefelder Schaltkn pfe l sen Verarbeitungen und Datenbankzugriffe aus Die Anwendung verwendet die Gegen standstypen KURS KUNDE und BUCHUNG aus der Datenbank Kursanmeldung Kurs Nr n Kurs Daten Kurs suchen Teilnehmer aktuell maximal Anzumeldende Person Neuer Kunde O bekannter Kunde KD Nr Name Titel Vorname Strasse Nr Postfach PLZ Ort Abbrechen Anmeldung eintragen Berechnen Sie die Function Points f r diese Anwendung Beachten Sie folgende Hinweise e Die Maske enth lt neben der eigentlichen Transaktion Anmeldung zwei weitere einge bettete Transaktionen Kurs suchen Person suchen Diese sind mitzuz hlen wenn sie nicht anderswo bereits als selbst ndige Transaktionen existieren Gehen Sie davon aus dass das hier der Fall ist d h dass beide eingebetteten Transaktionen gez hlt werden m ssen e Anfragen die nicht mehr als einen Datenbestand betreffen und nicht mehr als 15 Ein oder Ausgabedaten umfassen werden als einfach bewertet e Sie k nnen davon ausgehen dass die beteiligten Datenbest nde alle als einfach zu be werten sind e Bei den Einflussfaktoren k nnen Sie von folgenden Annahmen ausgehen Belastung der Hardware unbedeutend komplexe Verarbeitungen nicht vorhanden Wiederverwend barkeit sehr wichtig Alle brigen Faktoren haben durchschnittlichen Einfluss 58 Martin Glinz Software Engineering I Erg nzende und vertiefende Literatur Boehm 1981 ist die S
88. d oder ein Q Plan so kann das meiste durch Verweis auf diese Dokumente erledigt werden 4 1 4 Planung bei linearen und bei inkrementellen Prozessen Bei linearen Prozessmodellen zum Beispiel dem ergebnisorientierten Phasenmodell erfolgt die Planung im Vorprojekt Danach wird die Planung nur noch fortgeschrieben vgl 4 2 Bei Wachstumsmodellen gibt es mehrere Planungsabschnitte Hier muss zun chst in einem Vorprojekt eine Grobplanung erfolgen welche insbesondere die Erstellung des Lieferplans um fasst Jedes Inkrement wird in einem kleinen Vorprojekt dann geplant wenn es zur Ausf h rung ansteht Die Gesamtplanung wird revidiert wenn es aufgrund der realisierten Inkremente zu nderungen im Projekt kommt oder wenn unkorrigierbare Abweichungen von der Planung auftreten Die Muster 4 6 und 4 7 zeigen die beiden Planungsstile MUSTER 4 6 Lineare Planung MUSTER 4 7 Inkrementelle Planung Ansto Ansto Auftrag Auftrag Vorprojekt Vorprojekt Gesamtvorhaben Lieferung Teil l liefe rungen kleines Vorprojekt i te Iteration Projektdurch f hrung l Durchf hrung i tes Teilprojekt Projektabschluss Inbetriebnahme Erfahrungen ii gt Projekt W nsche abschluss 40 Martin Glinz Software Engineering I 4 1 5 Planungs Hilfsmittel Arbeits Termin Kosten und Personaleinsatzpl ne sollten graphisch in Diagrammen darge stellt werden Sie werden so angelegt dass im Projektablauf ein SOLL IST Vergleich
89. dell sehr viel berech tigte Kritik eingetragen Trotz seiner unbestreitbaren Vorteile Einfachheit Modellierung des nat rlichen Lebenslaufs und seiner immer noch beachtlichen Verbreitung sollte das Wasserfall Modell in der Interpretation einer Folge von Entwicklungst tigkeiten heute nicht mehr verwen det werden Gleiches gilt f r alle hnlichen Modelle welche die Phasen als T tigkeiten auffas sen 3 2 2 Ergebnisorientierte Phasenmodelle Ergebnisorientierte Phasenmodelle machen wie das Wasserfall Modell den Software Lebens lauf zur Grundlage des Prozesses Sie gehen also ebenfalls davon aus dass zun chst alle Anfor derungen spezifiziert werden dann das System vollst ndig entworfen wird dann codiert und ge 24 Martin Glinz Software Engineering I System feasibility Validation Software plans and requirements Validation Product design Verification Detailed design Verification Integration Product verification Implementation Operations and maintenance Revalidation BILD 3 3 Mehrfache Iterationen im Projektablauf mit dem Wasserfall Modell testet wird usw In einem ergebnisorientierten Phasenmodell ist eine Phase jedoch keine T tig keit wie beim Wasserfall Modell sondern ein Zeitintervall DEFINITION 3 6 Ergebnisorientiertes Phasenmodell Ein Modell f r den Software Entwick lungsprozess welches die Entwicklung in eine Sequenz aufeinanderfolgender Zeitabsch
90. der eine andere Wahl taste gedr ckt werden Die zuletzt get tigte Auswahl gilt Widerspruch Die oben geforderte M glichkeit der Annullierung wird ausgeschlossen Bild 7 10 Informale Spezifikation und deren Probleme 7 Spezifikation von Anforderungen 93 Sei mi die i te eingegebene M nze mj der Wert dieser M nze P der geforderte Preis und G die Funktion welche die Getr nkezubereitung ausl st Dann muss gelten vneN Vm 1isisn n n 1 mj gt 2P A Z mjl lt P gt G mi o m2 o omn A G mi o M2 o o Mn 1 i 1 i 1 Bild 7 11 Formale Spezifikation des Zusammenhangs zwischen der Eingabe von M nzen und der Ausl sung der Zubereitung in der Steuerung eines Getr nkeautomaten Start ee Annulliert Bereit Anzeige l schen Auswahl l schen Wahltaste gedr ckt Auswahl registrieren Preis anzeigen Wahltaste gedr ckt y alte Auswahl l schen neue Auswahl regi Gew hlt strieren neuen Preis anzeigen M nze eingegeben Summe M nzwert Preis Summe anzeigen M nze eingegeben Annulliert Summe alte Summe y Anzeige l schen M nzwert Geldannahme Eingeworfene M nzen zur ckgeben Preis Summe anzeigen A Auswahl l schen Summe gt Preis Anzeige l schen Getr nk zubereiten und ausgeben Wechselgeld Summe Preis Wechselgeld ausgeben Bedienung abbrechen Wenn l n
91. derungen 87 Fehler Normalfall und Fehlerf lle e Leistungsaspekt Datenmengen durchschnittlich im Extremfall Verarbeitungs Reaktionsgeschwindigkeit durchschnittlich im Extremfall Verarbeitungszeiten und intervalle wo immer m glich messbare Angaben e Qualit tsaspekt geforderte Qualit ten z B Benutzerfreundlichkeit Zuverl ssigkeit e Randbedingungsaspekt einzuhaltende zu verwendende Schnittstellen Normen und Gesetze Datenschutz Datensicherung Explizite Vorgaben des Auftraggebers Die Gliederung des Dokuments und die Art der Darstellung in den einzelnen Kapiteln h n gen stark von den verwendeten Methoden und Sprachen ab Teilweise sind sie auch durch Richt linien des Kunden oder des entwickelnden Unternehmens oder durch die Anwendung internatio naler Normen z B IEEE 830 1993 bestimmt Bei der Wahl der Gliederung ist dem Qualit tsmerkmal der Verst ndlichkeit besonderes Au genmerk zu widmen Schlechte oder gar nicht vorhandene Gliederungen behindern die Verst nd lichkeit unter Umst nden massiv 7 4 Gewinnung von Anforderungen 7 4 1 Probleme Bei der Gewinnung von Anforderungen treten typisch die folgenden Schwierigkeiten auf e Unterschiedliche Vertreter des Kunden haben unterschiedliche Vorstellungen ber das zu spe zifizierende System H ufig sind schon die Auffassungen und die Begriffsbildung im Anwen dungsbereich nicht einheitlich Requirements Engineering beinhaltet daher auch Kons
92. des Software Systems sicherzustellen und die M glichkeit der R ckverfolgung anzubieten Definition 11 2 Software Konfiguration Eine Menge zusammenpassender Software Einheiten Definition 11 3 Software Einheit software configuration item Der kleinste im Rahmen der Konfigurationsverwaltung als atomar behandelte Baustein einer Konfiguration Software Einheiten werden nur als Ganzes registriert freigegeben oder ge ndert Software Einheiten sind z B Programm Module und Dokumente 11 2 Kennzeichnung Software Einheiten haben eine eindeutige Kennzeichnung bestehend aus einem Namen und einer Versionsnummer f r das Anderungswesen Bild 11 1 Die dentit t einer Software Einheit ist feststellbar z B mit Pr fsummen Q LOG 0027 03 St ckliste Logistiksystem 0372538 1 Bild 11 1 Kennzeichnung von Software Einheiten 1993 1998 by Martin Glinz Alle Rechte vorbehalten Reproduktion zum nicht kommerziellen Gebrauch mit Quellenangabe gestattet Reproduktion auch auszugsweise zum kommerziellen Gebrauch nur mit schriftlicher Bewilligung des Verfassers gestattet 136 Martin Glinz Software Engineering I 11 3 Registrierung und Verwaltung Die Software Einheiten werden von einem Software Bibliothekar registriert und verwaltet Idealerweise erfolgt diese Verwaltung rechnergest tzt mit Hilfe von Werkzeugen welche Soft ware Einheiten Konfigurationen und Releases in einer Datenbank ablegen und verwalten Nummer Na
93. ditors 78 Martin Glinz Software Engineering I e Umfassende Rahmen bilden das L sungsger st f r ein vollst ndiges System zum Beispiel ein Rahmen f r das Schaltergesch ft in einer Bank Manchmal werden in einer Architektur mehrere Rahmen gleichzeitig verwendet Dabei muss der Vorteil der Wiederverwendung allerdings sorgf ltig abgewogen werden gegen die Nachteile m glicher Architekturkonflikte zwischen den verschiedenen Rahmen Die Einbettung unter schiedlicher Architekturprinzipien der verschiedenen Rahmen in eine gemeinsame koh rente Gesamtarchitektur kann sehr schwierig bis sogar unm glich sein 6 7 3 Architekturmuster Analog zu Entwurfsmustern sind Architekturmuster vorgefertigte Strukturen f r typische Architekturprobleme Definition 6 12 Architekturmuster Eine vorgefertigte parametrierbare Schablone f r die Ge staltung der Architektur eines Systems oder einer Komponente Es gibt eine F lle von Architekturmustern Man kann unterscheiden zwischen Strukturmus tern Steuermustern und Modularisierungs Entkopplungsmustern Nachfolgend werden einige ausgew hlte Architekturmuster beschrieben 6 7 3 1 Strukturmuster Das Matrixmuster Das Matrixmuster Bild 6 8 gliedert ein System in je eine Menge von Datenmodulen und von Funktionsmodulen wobei jede Funktion auf jedes Datum zugreifen kann Die Funktions module enthalten keine permanenten Daten Typische Anwendungen dieses Musters findet man in der klassischen Architekt
94. e rierung des Release nach dem Schema m n kenntlich gemacht m n bezeichnet den n ten kleinen Release innerhalb des m ten gro en Release Der Abstand zwischen zwei kleinen Releases betr gt in der Regel einige Monate der zwischen gro en Releases ein bis drei Jahre Pflegema nahmen auch wenn sie sorgf ltig durchgef hrt werden f hren typisch dazu dass die gepflegte Software gr er und in ihrem strukturellen Aufbau schlechter wird Lehman und Belady haben Zahlenmaterial ber die Pflege von Software erhoben und daraus sechs Gesetze 32 Martin Glinz Software Engineering I abgeleitet Belady und Lehman 1976 Lehman 1980 Lehman 1992 Alle Gesetze gelten nur f r gro e w hrend ihrer Lebenszeit st ndig benutzte Programme vom P und vor allem vom E Typ REGEL 3 1 Gesetz der kontinuierlichen Ver nderung Ein Programm unterliegt w hrend seiner gesamten Lebenszeit st ndiger Ver nderung oder es verliert nach und nach seinen Nutzen Die ser Prozess schreitet fort bis es kosteng nstiger wird das Programm durch ein neuerstelltes Nachfolgerprogramm zu ersetzen REGEL 3 2 Gesetz der zunehmenden Komplexit t Die Komplexit t eines Programms das st n dig ver ndert wird nimmt kontinuierlich zu weil seine Struktur durch die Anderungen immer schlechter wird es sei denn man ergreift explizite Gegenma nahmen REGEL 3 3 Grundgesetz der Programm Evolution Die Evolution eines Programms unterliegt einer sich selbst regelnden Dynamik mit
95. e Analyse DeMarco 1979 McMenamin und Palmer 1984 sowie Yourdon 1989 McDermid 1991 beschreibt verschiedene teilweise weniger bekannte klassische Spezifika tionsverfahren sowie Verfahren zur formalen Spezifikation Z VDM algebraische Spezifi kation Pepper et al 1982 geben eine Einf hrung in die algebraische Spezifikation Zitierte Literatur Ashworth C M Goodland 1990 SSADM a Practical Approach McGraw Hill London etc Boehm B 1981 Software Engineering Economics Prentice Hall Englewood Cliffs N J Booch G 1994 Object Oriented Analysis and Design with Applications Second Edition Redwood City Ca Benjamin Cummings Booch G Jacobson J Rumbaugh J 1997 The Unified Modeling Language for Object Oriented Development Documentation Set 1 1 Rational Software Corporation Coad P E Yourdon 1991a Object Oriented Analysis 2nd edition Englewood Cliffs N J Prentice Hall auf Deutsch Objektorientierte Analyse 1994 im gleichen Verlag 7 Spezifikation von Anforderungen 105 Coad P E Yourdon 1991b Object Oriented Design Englewood Cliffs N J Prentice Hall auf Deutsch Objektorientiertes Design 1994 im gleichen Verlag Davis A M 1993 Software Requirements Objects Functions and States Englewood Cliffs N J Prentice Hall DeMarco T 1979 Structured Analysis and System Specification Yourdon Press Prentice Hall Englewood Cliffs N J Gause D C G M Wein
96. e Engineering Principles and Practice Chichester John Wiley amp Sons 558 p bersicht ber alle Themengebiete des Software Engineerings vielfach jedoch sehr oberfl chlich Die dargestellten Techniken sind teilweise veraltet neuere fehlen Zehnder C A 1991 Informatik Projektentwicklung 2 Auflage Z rich Verlag der Fach vereine und Stuttgart Teubner 309 p Konzentriert sich auf den Aspekt der Software Entwicklung nach einem bestimmten Entwicklungsmodell Beschreibt vor allem was zu tun ist wenig Angaben zur Methodik
97. e Integration erfolgt schrittweise Jeder Integrationsschritt ist mit einem zuge h rigen Integrationstest verbunden der die Richtigkeit des Integrationsschritts sichert Nach Abschluss der Integration wird das fertiggestellte System einem gr ndlichen Systemtest unterworfen Im Systemtest sollen m glichst viele derjenigen Fehler gefunden werden die bei den Komponenten und Integrationstests bersehen wurden weil sie nur beim Zusammenspiel zwischen verschiedenen Komponenten auftreten Je nach Vertragsverh ltnis zwischen Software Ersteller und Auftraggeber erfolgt anschlie Bend noch eine formale Abnahme Dabei werden vorher vereinbarte Testf lle durchgespielt mit denen dargelegt wird dass die fertiggestellte Software die in der Anforderungsspezifikation gestellten Anforderungen erf llt Zitierte und weiterf hrende Literatur Berner S M Arnold S Joos M Glinz 1996 Java Entwicklungsrichtlinien Institut f r Informatik der Universit t Z rich Forschungsgruppe Requirements Engineering Berner S S Joos M Glinz 1997 Entwicklungsrichtlinien f r die Programmiersprache Java Informatik Informatique 4 3 Jun 1997 8 11 Fr hauf K J Ludewig H Sandmayr 1991 Software Pr fung Eine Fibel Z rich vdf und Stuttgart Teubner Wirth N 1993 Systematisches Programmieren eine Einf hrung 6 Auflage Stuttgart Teubner 9 Qualit tsmanagement 111 9 Qualit tsmanagement 9 1 Grundlagen Werden Produkte in
98. e Projektdokumentation dokumentiert die Entwicklung eines Software Produkts Die Produktdokumentation wird manchmal auch Systemdokumentation genannt 10 1 2 Aufgaben der Dokumentation Dokumentation hat die folgenden drei Hauptaufgaben Wissenssicherung Die Information aus den K pfen holen Das Wissen Know How ber ein System macht einen betr chtlichen Teil des Werts eines Systems aus Die Produktdokumentation hat die Aufgabe dieses Wissen schriftlich oder auf Datentr gern festzuhalten damit es nicht verloren geht Die Projektdokumentation sichert die Erfahrungen in der Abwicklung von Projekten Kommunikation Reden miteinander gen gt nicht Eine geordnete Systementwicklung und pflege ist ohne Kommunikation nicht m glich Dies gilt sogar f r Ein Personen Projekte wenn das Produkt l nger als ein paar Wochen leben soll M ndliche Kommunikation ist bei Arbeiten in einem kleinen Personenkreis sehr effizient Ausschlie lich m ndliche Kommunikation verursacht jedoch erh hte Kosten und wird letztlich ineffizient wenn der Personenkreis sich ndert oder die Systembetreuung auf einen anderen Personenkreis bergeht Letzteres ist typisch der Fall beim bergang von der Entwicklung zur Nutzung Daher m ssen auch in Kleinprojekten alle f r ein System wichtigen m ndlichen Informa tionen und Absprachen in Dokumenten festgehalten werden M ndliche Kommunikation gen gt nicht da Erzeugung und Benutzung von Informationen unter Umst
99. e anbietet werden Anwendungselemente eingesteckt Anwendungsrahmen vgl 6 7 2 sind oft nach dieser Metapher konstruiert Bild 6 10 Datenver waltung Anwendung 1 V O Zg N 2 se ZE ir Mo Kommunikation Bild 6 10 Die Steckersystem Metapher 6 Konzipieren von L sungen 8l Aufgaben 6 1 Welche Vorteile hat eine Modularisierung nach dem Geheimnisprinzip a f r die Verwen der eines Moduls b f r die Modulersteller f r das Pflegepersonal 6 2 Gegeben sei folgende Modularisierung der Steuerung einer Abf llanlage f r Fl ssigkeiten Modul Tank Steuerung des Einlassventils Behandlung der Sensoren f r vollen und leeren Tank Meldung des aktuellen Tankzustands an Leitstand Modul Abf llventil Steuerung des Auslassventils am Tank Modul Abf llung Steuerung des Flie bands mit den abzuf llenden Beh ltern Behand lung des Waage Sensors misst die abgef llte Menge Randbedingungen 1 Bei leerem Tank darf das Auslassventil nicht ge ffnet sein 2 W h rend der Nachf llung des Tanks Einlassventil offen muss das Auslassventil geschlossen sein Beurteilen Sie diese Modularisierung insbesondere im Hinblick auf Information Hiding und Zusammenarbeit Erg nzende und vertiefende Literatur Fairley 1985 sowie Ghezzi Jazayeri und Mandrioli 1991 beschreiben die Prinzipien guten Entwurfs McDermid 1991 enth lt eine bersicht ber klassische nicht objektorientierte Entwurfsver fahren Das T
100. e auf die vorhandenen Ressourcen Entw rfe und Programmcode beschreiben die L sungsdetails verwendete Algorithmen und Datenstrukturen Entw rfe werden entweder separat vom Programmcode dokumentiert oder sie sind in Form von ausf hrlichen Kommentaren im Programmcode integriert Die Testvorschriften legen fest welche Tests f r die einzelnen Komponenten nach ihrer Fertigstellung durchzuf hren sind und welche Tests nach welchem Integrationsschritt auszuf h ren sind Der in der Abnahmevorschrift beschriebene Abnahmetest bildet den formalen Abschluss einer Entwicklung Der Auftraggeber berpr ft mit diesem Test ob das System die in der Anforderungsspezifikation gestellten Anforderungen erf llt Der Integrationsplan beschreibt die Integration der einzeln fertiggestellten Komponenten zu einem in einer Testumgebung lauff higen Gesamtsystem Die nstallationsanleitung beschreibt wie ein auf der Zielhardware lauff higes System konfiguriert und auf der Zielhardware installiert wird Das Benutzerhandbuch enth lt die Bedienungsanleitung f r das System Es beschreibt aus Benutzersicht welche Funktionen das System bereitstellt und wie man es startet und bedient Zu einem eingebetteten System gibt es kein Benutzerhandbuch Seine Benutzung wird im Rahmen der Bedienungsanleitung des bergeordneten Systems dokumentiert Ein Glossar welches die verwendeten Begriffe und Abk rzungen erkl rt ist sowohl in der Entwicklung als auch nachher f r die
101. eString schreibt eine Zeichenkette auf ein Ausgabemedium e WriteReal zahl n konvertiert zahl in eine Zeichenkette und schreibt diese auf einer Breite von insgesamt n Zeichen auf ein Ausgabemedium e Die von mehreren Write Anweisungen erzeugten Ausgaben schlie en unmittelbar und ohne Zwischenraum aneinander an Durch den Aufruf von WriteLn wird eine neue Zeile auf dem Ausgabemedium begonnen e Es gibt keinen Operator f r Exponentiation Die Berechnung von x wird als x x program miert e exp x ist eine eingebaute Standardfunktion welche die Exponentialfunktion e berechnet 2 Auszug aus dem Entwurfsdokument Prozedur Kennlinie tabellieren Die Kennlinie welche durch die Funktion f x 2nx e gt gegeben ist wird im Bereich x1 x2 mit der Schrittweite Ax tabelliert F r den Fall x2 lt x1 soll die Tabellierung unterbleiben ber der Tabelle wird ein Titel x Ef x ausgedruckt 9 Qualit tsmanagement 129 3 Auszug aus den Codier Richtlinien Jede Anweisung beginnt auf einer neuen Zeile Die K rper aller Prozeduren und Bl cke sind jeweils 2 Zeichen einzur cken Namen sind so zu w hlen dass sie m glichst selbstdokumentierend sind Namen die aus drei und weniger Zeichen bestehen sollen m glichst nur f r lokale Aufgaben Schleifenindizes o verwendet werden Ihre Bedeutung ist bei der Definition zu dokumentieren Konstante Gr en sind am Beginn der Programme bzw Prozeduren al
102. einen wesentlichen Unterschied zwischen Software Qualit ts management und dem Qualit tsmanagement bei der Entwicklung anderer Produkte auch wenn Software Qualit tsmanagement verschiedentlich separat genormt worden ist z B ANSVIEEE Normen 9 1 3 Qualit tskosten Qualit t ist nicht umsonst Einrichtung und Unterhalt eines Qualit tsmanagementsystems kosten erhebliche Summen Die Durchf hrung von Qualit tsmanagement Ma nahmen in den Projekten belastet diese sowohl terminlich wie kostenm ig Welcher Nutzen steht diesen Kosten gegen ber Qualit tsmanagement bedeutet Verhinde rung bzw rechtzeitige Entdeckung von Fehlern Jeder nicht entdeckte oder zu sp t entdeckte Fehler ist mit teilweise erheblichen Fehlerbeseitigungskosten und m glichen Folgekosten z B Verlust von Marktanteilen verbunden Die Wirtschaftlichkeit des Qualit tsmanagements ergibt sich also aus der Gegen berstellung von Qualit tsmanagementkosten einerseits und Fehlerkosten andererseits Bild 9 1 Kosten Qualit tskosten Fehlerverh tungs und Pr fkosten Fehlerkosten Optimum Qualit tsaufwand nach Fr hauf Ludewig Sandmayr 1988 Bild 9 1 Qualit tskosten 9 Qualit tsmanagement 113 9 2 Das Qualit tsmanagementsystem 9 2 1 Das Qualit tswesen Das Qualit tswesen ist eine Sekund rorganisation innerhalb eines Unternehmens in der die Fachleute f r Qualit t zusammengefasst sind An der Spitze der Qualit tsorganisation steht der Qu
103. el Gr e oder Komplexit tsattribute zu messen und zu analysieren Programme f r die Ausf hrung und Auswertung von Tests zu instrumentieren Testf lle Testdaten und Testum gebungen zu generieren sowie Testergebnisse auszuwerten Konfigurationsverwaltungssysteme Konfigurationsverwaltungssysteme vereinfachen das Verwalten verschiedener Versionen von Programmen und Dokumenten und erm glichen das Generieren von Konfigurationen d h das automatische Zusammensetzen eines Systems aus einer Reihe von Programmen und Doku menten unter Umst nden mit entsprechender Vorverarbeitung wie Compilieren Binden Sortie ren etc 12 1 4 Planung des Werkzeugeinsatzes Wenn man Werkzeuge f r die Software Entwicklung erfolgreich einf hren will muss man sich zun chst ber folgende Fragen im Klaren sein Welche Aktivit ten sollen die Werkzeuge unterst tzen bzw automatisieren Wie wirtschaftlich ist der Werkzeugeinsatz Ein syntaxgesteuerter Editor beispielsweise welcher den Aufwand f r die Codierung um 25 vermindert bringt nur 5 Verminderung des Gesamt Projektaufwands wenn man 20 Aufwandsanteil f r die Codierung veranschlagt Welche Entwicklungskonzepte und damit verbunden welche Methoden und Sprachen sollen eingesetzt werden Ist die Schulung geregelt Freistellung der Mitarbeiter Finanzierung Verf gbarkeit von Kur sen Wie sieht die Einf hrungsstrategie aus Ist die Betreuung der Werkzeugverwender sichergestellt
104. ele Selbstverst ndlichkeiten des Alltagslebens sind ohne Rechner und deren Software nicht mehr m glich In krassem Gegensatz zu dieser Abh ngigkeit steht die Tatsache dass weltweit die Erstellung von Software nur ungen gend beherrscht wird Termin und Kosten berschreitungen bei Soft ware Projekten sind die Regel Software die Fehler enth lt oder sich nicht entsprechend den Vorstellungen und Bed rfnissen der Benutzenden verh lt geh rt zum Alltag Immer wieder kommt es auch vor dass ganze Projekte scheitern Stellvertretend seien zwei spektakul re Beispiele aus j ngerer Zeit genannt das Scheitern des CONFIRM Projekts und der missgl ckte Erstflug der Ariane 5 Rakete Im CONFIRM Projekt sollte im Auftrag gro er amerikanischer Hotel und Mietwagenunter nehmen ein neues umfassendes Reservierungssystem entwickelt werden Nach dreieinhalb Jah ren Entwicklungszeit und Investitionen von rund 125 Millionen Dollar wurde das Projekt im Juli 1992 eingestellt als erkannt wurde dass die gestellten Anforderungen mit dem gew hlten L sungsansatz nicht erreichbar waren Oz 1995 Bei der Ariane 5 f hrten eine nicht behandelte Ausnahmebedingung in der Software der Tr gheitsnavigationssysteme sowie die Fehlinterpretation der Meldung ber den Ausfall dieser Systeme als Messdaten durch die Software des Hauptrechners zu unsinnigen Befehlen an die Steuerd sen und damit zur Zerst rung der Rakete Lions 1996 Dabei erscheint Programmieren au
105. ellung sind vielf ltig e Geistige G ter werden in unserer Gesellschaft in der Regel als weniger wertvoll eingestuft als mit dem gleichen Aufwand erstellte materielle G ter Der Wert von Software wird unter sch tzt e Im Gegensatz zu materiellen Produkten gibt es f r Software keine nat rlichen Grenzen in Form von Materialeigenschaften oder Naturgesetzen Es gibt einzig die theoretische Grenze der Berechenbarkeit aber diese wirkt sich in der Praxis kaum aus W hrend ein Br ckenbauin genieur bei seinen Konstruktionen R cksicht nehmen muss auf die Eigenschaften der verwen deten Materialien und auf die Gesetze der Statik und Schwingungsdynamik ist ein Software Entwickler grunds tzlich in der Wahl seiner Konstruktionen frei Software findet ihre prakti schen Grenzen nur in der Begrenztheit des K nnens ihrer Entwickler Da diese Grenzen sehr 4 Martin Glinz Software Engineering I weit gesteckt sind und Menschen au erdem dazu neigen die Begrenztheit ihres K nnens zu verdr ngen werden bei Software h ufiger und leichtsinniger zu schwierige Vorhaben ange gangen als in anderen technischen Disziplinen e Bei der Entwicklung materieller Produkte sind viele Fehler leicht als solche erkennbar Wenn beim Bauen das Dach statt des Kellers in die Baugrube gesetzt wird so ist dies unschwer als Fehler zu erkennen Ein Fehler hnlicher Schwere in Software ist nur durch sorgf ltige und aufwendige Pr fma nahmen zuverl ssig erkennbar oder verh
106. en Es wird eine Rangliste der Risiken erstellt und es werden Ma nahmen zur Risikominderung geplant und eingeleitet 4 4 2 Risikosteuerung Um die erkannten Risiken in den Griff zu bekommen braucht es f r jedes gr ere Risiko einen Plan wie das Risiko beherrscht werden soll Grunds tzlich ist bei jedem Risiko zu berle gen 4 Software Projektf hrung 45 ob das Risiko vermeidbar ist welche Ma nahmen zur Risikominderung getroffen werden sollen wie das Risiko im Projekt verfolgt werden soll ob das Risiko auf Dritte abgew lzt werden kann Tabelle 4 1 zeigt eine Reihe von Ma nahmen zur Risikominderung Sie lassen sich mit fol genden Stichworten zusammenfassen Informationsbeschaffung Personalpolitik Prototypen Simulationen Vereinfachung Bei der Risikoverfolgung geht es darum die wichtigsten Risiken und ihre Entwicklung w h rend der gesamten Projektabwicklung im Auge zu behalten Boehm zum Beispiel empfiehlt in jedem Projekt eine Rangliste der 10 wichtigsten Risiken zu f hren In den in regelm igen Ab st nden stattfindenden Sitzungen der Projektverantwortlichen mit ihren Vorgesetzten wird diese Liste besprochen und aktualisiert Die dynamische Entwicklung der Rangliste bildet die Grund lage um Ma nahmen zur Risikominderung zu treffen oder getroffene Ma nahmen zu berpr fen und gegebenenfalls anzupassen 4 4 3 Wirtschaftlichkeit der Risikof hrung Eine sorgf ltige Risikof hrung kann mit erheblichen
107. en Auftrag wie folgt ca 50 h heres Datenvolumen zus tzliche Auswertungen in graphischer Form das Vorg ngersystem erzeugte nur Ta bellen andere Hardware anderes Betriebssystem Weitere Betreiber interessieren sich f r Ihr Auswertungssystem Sie rechnen f r die n chsten beiden Jahre mit mindestens f nf Auftr gen der gleichen Art Sie wissen ferner dass es in Ihrer Firma nur wenig Know How ber graphische statistische Auswertungen gibt Ihre Abteilungsleiterin hat Sie beauftragt einen Vorschlag f r die Projektziele vorzulegen und sich zu berlegen wie Sie die Zielverfolgung sicherstellen Welche Projektattribute und welche besonderen Qualit ten f r das Produkt schlagen Sie aufgrund der spezifischen Projektsituation vor Wie wollen Sie die Erreichung der vorge schlagenen Ziele kontrollieren Erg nzende und vertiefende Literatur Briand Morasca und Basili 1996 beschreiben grundlegende Eigenschaften wichtiger Produkt ma e In einem Vergleich mit anderen Ans tzen erschlie t dieses Papier ferner weitere Literatur zur Fundierung des Messens im Software Engineering Fenton 1991 sowie Conte Dunsmore und Shen 1986 sind Monographien ber Messen im Software Engineering Das Buch von Conte Dunsmore und Shen ist leider vergriffen und nur noch ber Bibliotheken zug nglich Zitierte Literatur Briand L C S Morasca and V R Basili 1996 Property Based Software Engineering Mea surement IEEE Transactions
108. en Modell Darstellung den vier Quadranten des Koordinatensystems entspricht 1 Planung des n chsten Spiralumlaufs 2 Zielsetzung bzw Zielkorrektur 3 Untersuchung von Varianten und ihren Risiken Variantenentscheid 4 Entwicklung und Pr fung dieser Schritt Korrespondiert mit dem Wasserfall Modell Der Zyklus wird viermal durchlaufen n mlich f r Systemdefinition Anforderungen an die Software Konzipierung Architektur Entwurf und Realisierung Detailentwurf Codierung Test Integration und Installation Wichtig ist vor allem der dritte Schritt im Zyklus wo die Risiken der Entwicklung erkannt und kontrolliert werden Boehm selbst bezeichnet das Spi ralmodell als risikogesteuert Das Hauptmittel hierf r sind Prototypen Gelegentlich findet man unter dem Namen Spiralmodell auch Modelle die eigentlich Wachstumsmodelle sind bei denen aber jeder Wachstumsschritt als ein Spiralumlauf dargestellt 1st 28 Martin Glinz Software Engineering I Cumulative cost Progress through steps Evaluate alternatives Determine identify resolve risks objectives alternatives constraints Risk analysis Risk analysis Risk analysis prototype Review partition ___ Simulations models benchmarks Te a g Requirements plan life cycle plan Concept of operation Detailed design 1 Software product design requirements
109. en mit der Auswahl passender Architekturmuster und oder der Orientierung an einer Architekturmetapher den Architekturstil vgl Abschnitt 6 6 Dieser gibt der Architektur ein Gesicht und erleichtert das Verst ndnis Der Stil wird so gew hlt dass die resultierende Architektur eine m glichst problemad quate Struktur aufweist Die Art und die Technik der Modularisierung richten sich nach dem gew hlten Architektur stil Anzustreben sind Module mit hoher Koh sion und geringer wechselseitiger Kopplung Aus heutiger Sicht ist das Geheimnisprinzip ein zentrales Modularisierungskriterium wenn der resultierende Entwurf leicht verst ndlich und gut nderbar bzw erweiterbar sein soll Bei der Konzipierung nebenl ufiger Systeme m ssen die Prozesse bestimmt und die Module den Prozessen zugeordnet werden Dies kann wie folgt geschehen e Man bestimmt alle systemexternen Akteure welche voneinander unabh ngig und spontan d h nicht aufgrund eines vorherigen Ansto es durch das System Informationen an das System senden und eine Systemreaktion erwarten e F r jeden dieser Akteure wird ein Prozess definiert Alle Module welche zur Erzeugung der geforderten Reaktion notwendig sind werden dem Prozess zugeordnet e Dabei stellt sich meistens heraus dass eine Reihe von Modulen in mehreren Prozessen ben tigt wird In dieser Situation werden zus tzliche Dienstleistungsprozesse definiert und die ge meinsam ben tigten Module diesen Prozessen zugewiesen
110. ende Material wird rechtzeitig vor der Sitzung verteilt Ein Review von Tisch vorlagen ist Zeitvergeudung Es muss daf r gesorgt sein dass die Teilnehmer rechtzeitig eingeladen werden und zu diesem Termin auch frei sind Sollen Reviews zum festen Bestandteil einer Entwicklungsmethode werden so empfiehlt es sich einen Zeitblock auf einen festen Wochentag zu legen z B immer Dienstags 10 12h in dem Reviews durchgef hrt werden und auf den nur in Notf llen andere Termine gelegt werden d rfen Alle kommen vorbereitet zur Sitzung Der Moderator bricht das Review ab wenn sich zeigt dass mehrere Teilnehmer nicht vorbereitet sind An einem Review nehmen mindestens drei und h chstens etwa sieben Personen teil Bei zu wenig Personen geht der zentrale Effekt des Gruppen Gutachtens verloren Ab etwa sieben teilnehmenden Personen tragen weitere Teilnehmer nur noch marginal zur Liste der Befunde bei folglich wird das Review mit zunehmender Teilnehmerzahl immer unwirtschaftlicher Eine Sitzung dauert maximal 2 Stunden Bei l ngeren Sitzungen l sst die Konzentration nach und die Effektivit t des Reviews sinkt rapide Dementsprechend muss der Umfang des zu pr fenden Materials gew hlt werden Richtwerte f r Code Reviews ca 150 200 Codezeilen ohne Kommentare f r Dokument Reviews ca 25 Seiten pro Sitzung Die Probleme werden in der Sitzung nur genannt nicht gel st Probleml sungsdiskussionen werden vom Moderator m glichst im Keim erst
111. enden Querschnittsaspekt fokussiert Ein Gestaltungskonzept f r die Benutzerschnittstelle zum Beispiel muss systemweit gelten Es w re schlecht in verschiedenen Modulen unterschiedliche Benutzerschnittstellen zu haben F r die folgenden Querschnittsaufgaben sollten aspektorientierte Teilkonzepte erstellt werden sofern dieser Aspekt f r das betreffende System relevant ist Die Datenhaltung insbe sondere das konzeptionelle Datenbankschema bei Verwendung einer Datenbank die Gestaltung der Benutzerschnittstelle die Behandlung von Fehlern sowie die Gew hrleistung von Sicherheit und Fehlertoleranz 6 3 3 Nutzung von Vorhandenem Wo immer m glich werden Systeme nicht vollst ndig neu entwickelt sondern es werden Teile oder gar das ganze System beschafft bzw wiederverwendet In der Konzipierung m ssen die wesentlichen Beschaffungs und Wiederverwendungsentscheidungen getroffen werden Es ist daher eine zentrale Aufgabe der Konzipierung zu untersuchen welche Teile der L sung mit welchen existierenden Komponenten realisiert werden k nnen Folgende Punkte sind immer zu untersuchen 6 Konzipieren von L sungen 65 e Kann eine L sung vollst ndig beschafft werden Standardsoftware konfigurierbare Baustei ne e K nnen abgeschlossene Teilsysteme zum Beispiel ein Datenbanksystem beschafft werden Ist das System durch Einbettung in einen existierenden Software Rahmen framework reali sierbar e K nnen einzelne Komponenten aus Progr
112. enge der zu bertragenden Daten zu ber cksichtigen Bei der Daten zuordnung muss dabei meistens zwischen redundanzfreier Speicherung mit erh htem Daten ber tragungsbedarf einerseits und redundanter Speicherung mit geringem bertragungsbedarf abge wogen werden Bei der Zuordnung der Prozesskommunikation muss vor allem darauf geachtet werden dass die Leistungsanforderungen unter Nutzung der vorhandenen Technologie erreicht werden Dort wo physische Randbedingungen oder Leistungsanforderungen dazu zwingen eine von der logischen Struktur der L sung abweichende physische Struktur zu w hlen muss neben der logischen auch die physische Struktur dokumentiert werden Gleiches gilt wenn die Software zu Liefer oder Verwaltungszwecken in Pakete gegliedert wird Das L sungskonzept enth lt dann verschiedene Sichten auf die L sung Kruchten 1995 Die Erstellung aspektbezogener Teilkonzepte richtet sich nach den Regeln f r den Entwurf des jeweiligen Aspekts zum Beispiel den Regeln des Datenbankentwurfs f r die Erstellung des Datenhaltungskonzepts Auf eine n here Ausf hrung wird hier verzichtet da sie den Rahmen dieses Skripts sprengen w rde Die Struktur des L sungskonzepts als Dokument ist in Abschnitt 6 4 beschrieben Wichtig ist dass das Dokument nicht erst am Schluss der Entwurfst tigkeiten entsteht sondern inkre mentell w hrend der gesamten Entwurfsarbeit 6 5 3 3 Pr fung Es ist zu verifizieren dass das Konzept die in d
113. ens bildung zwischen divergierenden Vorstellungen der beteiligten Personen e Die Kundenvertreter haben zwar eine Vorstellung was sie wollen aber sie k nnen ihre Vor stellung nicht formulieren Manchmal l sen sie dieses Problem indem sie anstelle ihrer ei gentlichen Anforderungen bestehende L sungen mit vergleichbaren Eigenschaften beschrei ben e Die Kundenvertreter wissen nicht oder nur sehr vage was sie eigentlich wollen 7 4 2 M gliche Techniken Die folgenden vier Vorgehensweisen k nnen erfolgreich zur Anforderungsgewinnung einge setzt werden Je nach Situation wird eine einzelne Technik oder eine Kombination von Techni ken gew hlt Bild 7 5 Begriffe kl ren und ein Glossar mit Definitionen der wichtigen Begriffe des Anwendungs bereichs erstellen Damit wird eine begriffliche Grundlage geschaffen die sicherstellt dass alle das Gleiche meinen wenn sie vom Gleichen reden Ein solches Glossar ist insbesondere dann wichtig wenn schon die Kundenvertreter untereinander keine klare und einheitliche Begriffs welt haben 88 Martin Glinz Software Engineering I e Soll Prozessabl ufe untersuchen Feststellen welche u eren Ereignisse auf das zu spezifizie rende System einwirken k nnen und erfragen wie das System auf welches dieser Ereignisse reagieren soll e Anwendungsszenarien bilden und durchspielen Alle Interaktionen der Umgebung seien dies Menschen oder Sensoren und Stellglieder mit dem zu spezifizierenden
114. er Anforde rungen und zur Konzipierung der L sung Der Aufwand den man f r die Beschaffung einer Komponente bzw eines Systems treibt h ngt stark davon ab e wie wichtig die Anwendung ist f r welche die Komponente beschafft wird e wie teuer die beschaffte Komponente ist e wie lange man die Komponente nutzen will Die Schritte 1 bis 3 sollten parallel zur Spezifikation der Anforderungen erfolgen Die Schritte 4 und 5 und evtl ein Teil von 3 sind Teilaufgaben der Konzipierung 1 Anforderungen analysieren Wer seri s beschaffen will muss als erstes die zu erf llen den Anforderungen kennen 2 Hauptkriterien definieren Aus der Menge aller Anforderungen werden diejenigen her ausgesch lt die kritisch und unverzichtbar sind Faustregel weniger als zehn zum Bei spiel drei bis f nf funktionale Anforderungen zwei Leistungsanforderungen der Maximal preis und bei reinen Software Beschaffungen die Hardware auf der das System laufen muss 3 Markt bersicht verschaffen Grobauswahl treffen Man muss herausfinden was es f r den gew nschten Problembereich berhaupt gibt Quellen sind zum Beispiel Anzeigen 6 Konzipieren von L sungen 71 Recherchen im WWW Berichte und Tests in Zeitschriften H ndler sowie Kontakte zu anderen Unternehmen der gleichen Branche Anhand der Kriterienliste wird eine Grobaus wahl getroffen bei der maximal noch drei bis f nf Kandidaten brigbleiben sollten 4 Kandidatensysteme evaluieren
115. er Anforderungsspezifikation erf llten Anfor derungen erf llt dass es wirtschaftlich ist und softwaretechnisch gut Kriterien f r die software technische G te sind zum Beispiel die G te der Modularisierung hohe Koh sion geringe Kopp lung die durchg ngige Einhaltung des gew hlten Entwurfsstils sowie Umfang und Verst nd lichkeit der Dokumentation Es ist sinnvoll das Konzept zus tzlich auch zu validieren d h unter Beteiligung der zuk nf tigen Benutzer festzustellen ob es ihren W nschen und Vorstellungen entspricht Da das Kon zept viel konkreter ist als die Anforderungsspezifikation werden so m glicherweise noch Anfor derungsfehler erkannt bevor mit der Realisierung des Systems begonnen wird 70 Martin Glinz Software Engineering I Das Mittel der Wahl zur Pr fung eines L sungskonzepts ist das Review vgl Kapitel 9 Zur Pr fung kritischer Leistungsanforderungen sind evtl Simulationen oder Labormuster eine Pro totypart vgl Kapitel 4 erforderlich Auch Prototypen im engeren Sinn k nnen zur Validierung herangezogen werden zum Beispiel um die Brauchbarkeit eines Benutzerschnittstellenkonzepts zu berpr fen Informelle Pr fungen finden kontinuierlich w hrend der gesamten Konzipierungsarbeit statt Vor Abschluss der Arbeit wird ein formelles Review durchgef hrt und das Konzept entspre chend den erhobenen Befunden revidiert Bei gr eren Aufgaben werden Teill sungen schon vorab formellen Reviews unterzogen
116. er Name Pflich tenheft gebr uchlich Mit diesem Namen werden jedoch h ufig verschiedene Begriffe verbun den Manche Leute verstehen Pflichtenheft als ein Synonym zu Anforderungsspezifikation andere verlangen eine grobe Beschreibung der gew hlten L sung als Bestandteil wiederum andere sehen auch Elemente der Projektabwicklung Kosten Termine als Bestandteil des Pflichtenhefts Bei der Verwendung des Namens Pflichtenheft ist daher Vorsicht geboten und das jeweils damit Gemeinte im Einzelfall zu kl ren 7 1 2 Wozu eine Anforderungsspezifikation erstellen Die Erstellung einer Anforderungsspezifikation kostet Geld ohne dass diesem Aufwand ein unmittelbar sichtbarer Ertrag in Form von Programmen gegen bersteht Das Spezifizieren von Anforderungen ist also nur dann wirtschaftlich wenn dem daf r zu treibenden Aufwand entspre chende Einsparungen gegen berstehen Requirements Engineering das systematische Spezifizieren von Anforderungen hat daher das klare Ziel Kosten zu senken Dass dieses Ziel realistisch ist zeigt folgende berlegung Fehlerkosten d h die Kosten f r die Lokalisierung und Behebung von Fehlern machen einen wesentlichen Teil der Gesamtkosten einer Systementwicklung aus Anforderungsfehler sind dabei die teuersten Fehler 1996 1999 by Martin Glinz Alle Rechte vorbehalten Reproduktion zum nicht kommerziellen Gebrauch mit Quellenangabe gestattet Reproduktion auch auszugsweise zum kommerziellen Gebrauch
117. erden n mlich all die Arbeiten tats chlich gemacht die bei ord nungsgem er Entwicklung eigentlich gemacht werden sollten z B sorgf ltige Dokumentation und Pr fung die aber sonst der Termin Guillotine zum Opfer fallen In Bild 5 8 beispielsweise beeinflusst die Sch tzung ab etwa dem 1 6 fachen des urspr nglichen Werts den tats chlichen Aufwand kaum noch Aufwand 20 100 Sicherheitszuschlag zur Sch tzung BILD 5 8 Der Parkinson Effekt Korrelation von gesch tztem und effektivem Aufwand 5 Software Aufwandsch tzung 57 Aufgaben 5 1 5 2 Sie sind Mitarbeiter in in der Informatikabteilung eines Unternehmens Im Rahmen des unternehmensweiten Qualit tsmanagementsystems nehmen Sie in Ihrer Abteilung die Rolle des Qualit tsbeauftragten ein Ihr Chef hat auf einer Konferenz von COCOMO geh rt Da es mit der Aufwandsch tzung in Ihrer Abteilung im Argen liegt hat er beschlossen das Geh rte in die Tat umzusetzen und ab sofort alle den Aufwand f r alle neuen Projekte mit COCOMO sch tzen zu lassen Bevor er seinen Entschluss verk ndet fragt er Sie als Qualit tsbeauftragte n noch um Ihre Meinung Was raten Sie ihm Im Rahmen der Entwicklung eines Informationssystems f r die Teilnehmeradministration eines Schulungsunternehmens ist eine Anwendung zur Anmeldung von Kursteilnehmern zu erstellen Die Anwendung wird ber untenstehende Eingabemaske angesprochen Un terstrichene Felder sind Eingabefelder graue Felder sin
118. erreicht ist kann durch Vergleich zwi schen Soll und Ist Termin eine gesicherte quantitative Aussage ber die Terminsituation ge macht werden Jedesmal wenn ein Solltermin f r einen Meilenstein verstreicht ohne dass der Meilenstein erreicht ist kann durch eine Sch tzung des verbleibenden Aufwands bis zur Erreichung des Meilensteins eine Sch tzung ber die Terminsituation abgegeben werden Sachzielverfolgung geschieht ebenfalls mit Hilfe von Meilensteinen indem jeder erreichte Meilenstein ein fertiggestelltes Zwischenergebnis dokumentiert 4 Software Projektf hrung 41 gesch tzter 100 Fertigstellungs grad in Prozent 80 60 40 20 nach Boehm 1981 0 2 4 6 8 10 12 geleisteter Aufwand in Personenwochen BILD 4 3 Das 90 Syndrom in der Projektkontrolle Die scheinbar einfachste Art der Kostenverfolgung ist das Aufzeichnen von budgetierten und tats chlichen Kosten ber der Zeit Bei n herem Hinschauen stellt man aber fest dass eine sol che Graphik f r die Projektkontrolle wertlos ist da der Projektfortschritt nicht ber cksichtigt wird Die gleiche Kurve kann bei einem termingerechten Projekt eine Kostenunterschreitung und bei einem in Verzug geratenen Projekt eine massive Kosten berschreitung bedeuten Stattdessen muss entweder der Projektfortschritt als Gewinn bewertet und mit in die Kurve der tats chlichen Kosten einbezogen werden oder die Kosten m ssen ber dem Projektfortschritt st
119. ersionsnummer nderungsindex evtl Datum Kapitelnummer Seitenzahl Bei Dokumenten auf Datentr gern oder in Informationssystemen wird so verfahren dass diese Informationen abrufbar sind bzw bei der Ausgabe auf Papier generiert werden Freigabewesen Nur Freigegebenes gilt Fertiggestellte Dokumente werden gepr ft gefundene M ngel werden behoben Dann erst wird das Dokument freigegeben und verteilt Von diesem Zeitpunkt an ist ein Dokument dem Zugriff seiner Ersteller entzogen Anderungen sind nur noch ber das Anderungswesen m glich nderungswesen Nur Aktuelles ist hilfreich Das nderungswesen hat zwei Ziele Dokumente immer aktuell zu halten wildes unkontrolliertes Andern von Dokumenten zu verhindern Hierzu wird ein Prozess definiert nach dem nderungen ablaufen In der Regel enth lt er die Schritte Antrag Entscheid Durchf hrung Freigabe 10 5 Dokumenterstellung Dokumente entstehen schritthaltend mit der Entwicklung Produktdokumente sind ein Bestandteil des zu entwickelnden Produkts Ohne Dokumente sind weder eine vern nftige Projektf hrung noch eine geordnete Pr fung und Qualit tssicherung m glich Das heute immer noch verbreitete Hinterher Dokumentieren welches dann oft dem Zeitmangel zum Opfer f llt sollte endg ltig der Vergangenheit angeh ren Hingegen kann es sinnvoll sein zum Schluss einer Entwicklung Dokumente nochmals zu berarbeiten Die Klarheit und die Konsistenz der Darstellu
120. erte Analyse Strukturierte Analyse DeMarco 1979 McMenamin und Palmer 1984 Yourdon 1989 ist eine teilformale konstruktive Spezifikationsmethode Die Anforderungen werden durch eine Hierarchie von Datenflussdiagrammen modelliert Ein Datenflussdiagramm Bild 7 8 besteht aus Aktivit ten Datenfl ssen und Speichern Zur Modellierung der Systemumgebung werden au erdem Endknoten verwendet Bilder 7 18 7 19 Datenflussdiagramme basieren auf dem Prinzip der datengesteuerten Verarbeitung jede Aktivit t arbeitet dann wenn die von ihr ben tigten Datenfl sse eintreffen Sie erzeugt bei ihrer Arbeit neue Datenfl sse Diese steuern entwe der andere Aktivit ten an oder verlassen das System als Ergebnis 98 Martin Glinz Software Engineering I Aktivit t Prozess activity process Datenfluss dataflow III Speicher store file Endknoten terminator terminal external Bild 7 18 Notationen f r Datenflussdiagramme Ein Datenflussdiagramm wird wie folgt interpretiert e Datenfl sse transportieren Datenpakete die von Aktivit ten oder Endknoten produziert bzw konsumiert werden e Aktivit ten arbeiten nur dann wenn alle von ihnen ben tigten Eingabe Datenfl sse vorliegen Die Aktivit t konsumiert die Daten bearbeitet sie und produziert Ausgabe Datenfl sse Sie kann dabei zus tzlich Speicherinhalte lesen oder schreiben e Speicher modellieren Datenbeh lter Ihr Inhalt kann gelesen werden ohne den Speicher zu
121. ertes Modellieren und Entwerfen M nchen Hanser 1993 Wirfs Brock R B Wilkerson L Wiener 1990 Designing Object Oriented Software Engle wood Cliffs N J Prentice Hall auf Deutsch Objektorientiertes Software Design M nchen Hanser 1993 Yourdon E 1989 Modern Structured Analysis Prentice Hall Englewood Cliffs N J 672 p 8 Realisierung 107 8 Realisierung Das Thema Realisierung wird hier nur summarisch behandelt da es in der Programmieraus bildung bereits vertieft worden ist Inspektions und Testverfahren werden im Kapitel 9 behan delt 8 1 M glichkeiten der Realisierung Ein L sungskonzept d h eine Systemarchitektur l sst sich auf verschiedene Arten realisie ren e durch Entwerfen und Codieren e durch Entwerfen und Generieren e durch Konfigurieren vorhandener Komponenten In allen F llen m ssen die realisierten Einzelkomponenten zu einem System integriert wer den und m ssen die Komponenten wie auch das System gepr ft werden um m gliche Fehler zu finden und sie anschlie end zu beheben Sowohl beim Entwerfen wie beim Codieren werden wo m glich vorhandene Komponenten und vorhandene Ideen zum Beispiel Entwurfsmuster genutzt Im klassischen Detailentwurf werden die zu codierenden Algorithmen und Datenstrukturen festgelegt Dort wo das L sungskonzept noch zuwenig detailliert ist werden die n tigen Details erarbeitet In der Codierung wird dieser Entwurf in einer Programmiersprache ausformul
122. erungen genannt Gesamte An forderungen Termine Kosten Sachziele Projekt Anforderungen Attribute an das Produkt m funktionale Attribute Anforderungen Leistungs besondere Randbe anforderungen Qualit ten dingungen Bild 7 4 Gliederungsbaum der Anforderungen Zus tzlich m ssen die Anforderungen oft nach ihrer Wichtigkeit klassifiziert werden z B in e Muss Anforderungen sind unverzichtbar und m ssen in jedem Fall erf llt werden e Soll Anforderungen sollten erf llt werden sind aber bei zu hohen Kosten verzichtbar e Wunsch Anforderungen werden nur erf llt wenn dies mit vertretbaren Kosten m glich ist Eine solche Klassifikation nach Wichtigkeit ist vor allem in zwei Situationen n tig e wenn die Entwicklungskosten eine harte Randbedingung darstellen Dies ist unter anderem dann der Fall wenn Software f r den Markt entwickelt wird e wenn die Anforderungsspezifikation als Grundlage f r die Beschaffung eines Systems dient weil dann die L sung nicht nach Ma auf die Bed rfnisse zugeschnitten werden kann 7 3 2 Inhalt und Aufbau einer Anforderungsspezifikation Eine Anforderungsspezifikation muss inhaltlich die folgenden Aspekte abdecken e Funktionaler Aspekt Daten Struktur Verwendung Erzeugung Speicherung bertragung Ver nderung Funktionen Ausgabe Verarbeitung Eingabe von Daten Verhalten Sichtbares dynamisches Systemverhalten Zusammenspiel der Funktionen 7 Spezifikation von Anfor
123. es Projekts eigentlich brauchen Eine Analyse ergibt folgende Aufwandsch tzung f r das Projekt e Portierung der vorhandenen Software mit gleichzeitiger Trennung in einen maschinen abh ngigen Infrastrukturteil und einen maschinenunabh ngigen Applikationsteil 12 Personenwochen e Parametrierung des verarbeitbaren Datenvolumens 3 Personenwochen e Erstellung der graphischen Auswertungen auf der Basis einer gekauften Graphik Bibliothek 12 Personenwochen e Abnahme und Projektabschluss 1 Personenwoche 46 4 2 4 3 Martin Glinz Software Engineering I Zur Problemanalyse Planung und Erstellung eines Rahmenkonzepts f r die L sung haben Sie bisher zwei Wochen aufgewendet eine weitere Woche werden Sie noch brauchen Der vereinbarte Liefertermin ist heute in neun Wochen Sie k nnen sich selbst eingerechnet maximal drei Leute mit voller Arbeitskapazit t f r das Projekt einsetzen Entwerfen Sie einen Aufgaben und Terminplan f r dieses Projekt im Stil von Bild 4 2 Begr nden Sie warum das Auftragen von budgetierten und tats chlichen Kosten ber der Zeit ein unbrauchbares Mittel f r die Kostenverfolgung in Projekten ist Gegeben sei das Problem aus Aufgabe 4 1 es ist aber 10 Tage fr her Sie haben soeben mit der Problemanalyse begonnen und wollen nun die Risiken des Projekts absch tzen a Welches sind Ihrer Ansicht nach die gr ten Risiken die den Erfolg Ihres Projektes gef hrden k nnen b Welche Ma nahmen k n
124. escheid L A analysieren Nachbesserung verlangt Projekt plan yeta Projekt planen schlie Linie Projektleiter Projekt durchf hren MUSTER 4 3 Start eines Produktentwicklungsprojekts f r Software Vorschla eingereicht Marketing N Entscheid ber Produkt abgelehnt vorschlag Beobachten untersuchen Markt Fragen stellen y Techno logie Antworten Feststellungen Produktstudie Kunden durchf hren Beauftragter Produkt studie nderungen notwendig enth lt Entscheid ber Durchf hrung Marketing Line Konzept abgelehnt Projekt skizze Projekt planen Projektleiter Projekt durchf hren 37 38 Martin Glinz Software Engineering I MUSTER 4 4 Start eines Software Konfigurationsprojekts Anfrage Kucktragen Nachbesse Kundenproblem rung verlangt Auskunft analysieren Wunsche Prototyp konfigurieren Auftrag akquirieren Prototyp Beauftragter Vertrieb Kunde Offerte zufrieden Offerte schreiben Beauftragter Bescheid erhalten Bescheid Bescheid analysieren o Ca a Projekt vertrag Projekt planen plan Projektieiter Projekt durchtuhren Kunde Vertrag 4 1 3 Der Projektplan Im Projektplan werden alle Ergebnisse der Planung sowie alle Planungsfortschreibungen do kumentiert Er muss Antworten auf die fo
125. ezeilen Assembler 320 C 128 FORTRAN 107 COBOL 197 Pascal 91 C 53 Ada 95 49 Smalltalk 21 SQL 12 Das Function Point Verfahren hat den gro en Vorteil dass die ben tigten Eingangsgr en sich in den fr hen Phasen eines Projekts leichter bestimmen lassen als beispielsweise die Gr e des erwarteten Resultats bei COCOMO Zudem sind mit Function Points Produktivit tsmessun gen m glich die weniger leicht verf lschbar sind als Messungen auf der Grundlage der erzeug ten Programmzeilen Allerdings ist das Verfahren auf Informationssysteme zugeschnitten und daher auf andere Arten von Software zum Beispiel Prozessautomatisierung nur beschr nkt anwendbar Ein wei 5 Software Aufwandsch tzung 55 terer Nachteil ist dass das Function Point Ma nicht additiv ist Die Summe der Function Points von n logisch zusammenh ngenden Teilsystemen ist gr er als die Anzahl der Function Points des Gesamtsystems Dies liegt daran dass die Schnittstellen zwischen je zwei Teilsystemen auf beiden Seiten als Schnittstellen zu externen Datenbest nden gez hlt werden w hrend diese Daten bei Betrachtung des Gesamtsystems als ein interner Datenbestand gez hlt werden Es ist daher nicht m glich bei einem gro en System die Function Points pro Teilsystem zu bestimmen und diese zu addieren 5 5 Sonstige Methoden Es gibt eine Reihe weiterer g ngiger Methoden zur Kostensch tzung z B so sch tzen dass man auf jeden Fall den Auftrag bekommt so
126. f den ersten Blick gar nicht so schwierig Was ist ein Pro gramm denn eigentlich mehr als das Zusammensetzen einfacher Befehle zu einer geeigneten Folge von Anweisungen an einen Rechner Was ist denn Software eigentlich und was hat sie f r besondere Eigenschaften die den Umgang mit ihr so schwierig machen 1 1 2 Software DEFINITION 1 1 Software Die Programme Verfahren zugeh rige Dokumentation und Daten die mit dem Betrieb eines Computersystems zu tun haben IEEE 610 12 Diese Definition erlaubt uns drei wichtige Feststellungen ber Software zu machen die wesentliche Hinweise darauf geben warum die Entwicklung von Software schwierig ist FESTSTELLUNG 1 1 Software umfasst erheblich mehr als nur Programme Bild 1 3 Der Aufwand f r das Schreiben der Programme betr gt in der Regel nur 10 20 Prozent des Gesamtaufwands f r die Entwicklung von Software Bezogen auf die gesamten Lebensdauer einer Software sind es unter 10 der Kosten Bild 1 4 Da die Programme jedoch der entschei dende Bestandteil von Software sind ohne Programme geht nichts wird bei der Sch tzung des 1 Wir formulieren in diesem Text alle Gesetzm igkeiten ber Software und Software Engineering als Feststellungen und Regeln Die Wahl dieser Terminologie hat folgenden Hindergrund In allen Lebensbereichen gilt dass wir Gesetzm igkeiten vermuten wenn wir gewisse Erfahrungen in gleicher Weise immer wieder machen In den Wissenschaften wird dann versuch
127. fs 6 5 2 Die Hauptaufgaben des Architekturentwurfs Tabelle 6 1 fasst die Hauptaufgaben zusammen Bild 6 1 zeigt ihre Zusammenh nge und Ab h ngigkeiten Nachfolgend werden die einzelnen Aufgaben etwas n her charakterisiert Das konkrete Vorgehen bei der Bearbeitung der Aufgaben ist stark von den verwendeten Entwurfs techniken und vom gew hlten Prozessmodell abh ngig TABELLE 6 1 Aufgaben des Architekturentwurfs Aufgabe analysieren e Anforderungen verstehen e Vorhandene bzw beschaffbare Technologien und Mittel analysieren Architektur modellieren und dokumentieren Grundlegende Systemarchitektur festlegen Wahl geeigneter Architekturmuster und metaphern Festlegung des Architekturstils Modularisieren Nebenl ufige L sungen in Prozesse gliedern Wiederverwendungs und Beschaffungsentscheide treffen Ressourcen zuordnen Aspektbezogene Teilkonzepte f r Querschnittsaufgaben erstellen L sungskonzept als Dokument erstellen L sungskonzept pr fen e Anforderungen erf llt Softwaretechnisch gut e Wirtschaftlich 6 5 3 Vorgehen beim Konzipieren 6 5 3 1 Aufgabenanalyse Das Vorgehen bei der Aufgabenanalyse h ngt sehr stark von der Art der vorhandenen Vor gaben ab Teilweise k nnen die gleichen Techniken wie bei der Gewinnung von Anforderungen vgl Kapitel 7 verwendet werden Es geht darum ein klares Verst ndnis zu erarbeiten was verlangt wird und welche grunds tzlichen L sungsm glichkeiten in Fra
128. ftware Entwicklungshandbuch oder in Software Entwicklungsrichtlinien Berner et al 1997 zusammengefasst 9 2 5 Qualit tssicherung Die Existenz eines Qualit tsmanagementsystems garantiert noch nicht dessen Wirksamkeit Die Darlegung des Qualit tsmanagements d h alle T tigkeiten zur Schaffung von Vertrauen dass die Qualit tsanforderungen erf llt werden wird Qualit tssicherung genannt Als zentrale Ma nahmen braucht es regelm ige berpr fungen ob das Qualit tsmanagementsystem wie geplant funktioniert und ob die vorgesehenen Qualit tsma nahmen wirklich durchgef hrt wer den Solche berpr fungen hei en Audits Interne Audits werden durch das Qualit tswesen geplant und durchgef hrt Jede Organisa tionseinheit sollte etwa einmal j hrlich auditiert werden Die Ergebnisse dieser Audits flie en in Ma nahmenpl ne zur Verbesserung der Qualit t und zur Eliminierung erkannter Schwachstellen ein 1 Bis vor wenigen Jahren wurde das gesamte Qualit tsmanagement als Qualit tssicherung bezeichnet Seit 1994 wird in allen Normen die hier verwendete Terminologie benutzt In der Praxis wird aber immer noch h ufig von Qualit tssicherung gesprochen wenn Qualit tsmanagement gemeint ist 116 Martin Glinz Software Engineering I Bei externen Audits wird die berpr fung durch eine externe auf Qualit tsmanagement spezialisierte Organisation durchgef hrt Ein externer Audit ist unter anderem dann erforderlich wenn eine
129. g I Erg nzende und vertiefende Literatur Basili und Turner 1975 Boehm 1981 1988 und Royce 1970 sind die Schl sselquellen f r die vorgestellten Prozessmodelle Barnes und Bollinger 1991 diskutieren wirtschaftliche Aspekte der Wiederverwendung und Ma nahmen zur F rderung von Wiederverwendung Floyd 1984 gibt eine Taxonomie der verschiedenen Arten des Prototypings Kieback et al 1992 geben eine kurze bersicht ber Prototyping als solches und beschreiben dann verschie dene industrielle Prototyping Projekte Lehman 1980 ist der Klassiker ber die Evolution von Software Das Problem der Definition und der Verbesserung der realen Software Prozesse in Unternehmen wird in diesem Kapitel nicht behandelt Interessierte Leserinnen und Leser seien auf Humphrey 1989 verwiesen Zitierte Literatur Barnes B H T B Bollinger 1991 Making Reuse Cost Effective IEEE Software 8 1 Jan 1991 13 24 Basili V R A J Turner 1975 Iterative Enhancement A Practical Technique for Software Development IEEE Transactions on Software Engineering SE 1 6 390 396 Boehm B 1981 Software Engineering Economics Englewood Cliffs N J Prentice Hall Boehm B W 1988 A Spiral Model of Software Development and Enhancement IEEE Com puter 21 5 May 1988 61 72 Brooks F P 1987 No Silver Bullet Essence and Accidents of Software Engineering IEEE Computer 20 4 10 19 Floyd C 1984 A Systematic Look at Prototypi
130. ganisationsaufwand scheint auf den ersten Blick betr chtlich Man fragt sich ob spontane informelle Zusammenk nfte zum Finden Besprechen oder L sen von Problemen nicht viel einfacher und n tzlicher w ren Die Erfahrung zeigt dass dies nicht zutrifft Da informelle Reviews nicht geplant werden sind sie keine systematische qualit tssichernde Ma nahme sondern es bleibt weitgehend dem Zufall berlassen ob ein Produktteil ein Review durchl uft oder nicht Man hat au erdem festgestellt dass die Fehlerauf deckungsrate in informellen Reviews deutlich niedriger ist als in formellen Reviews 120 Martin Glinz Software Engineering I 9 4 3 Rollen und Aufgaben der am Review Beteiligten 9 4 3 1 Moderator Der Moderator organisiert und leitet die Review Sitzung vgl 9 4 2 1 Punkt 3 Er sorgt fer ner f r die Fertigstellung und Weiterleitung des Review Berichts Im Idealfall ist der Moderator ein Mitarbeiter des Qualit tswesens und hat ein spezielles Training f r die Leitung von Reviews absolviert Die Effektivit t eines Reviews h ngt stark vom Geschick des Moderators ab Es geht unter anderem darum e eine offene Atmosph re zu schaffen in der jeder sich frei u ern kann ohne Angst sich zu bla mieren e Zur ckhaltende Teilnehmer zu Aussagen zu ermuntern e Dauerredner zu bremsen e Streit und pers nliche Angriffe zu vermeiden bzw beizulegen e Abgleiten in nutzlose Detaildiskussionen zu verhindern e immer wieder Konsens herzustellen
131. ge kommen 68 Martin Glinz Software Engineering I Anforderungen Technologie Vorhandene beschaffbare Eon Mittel Hard und Software Aufgaben Wahl von Architekturmetapher n grundlegenden analyse Architekturmustern und des Architekturstils Modularisierung a Wiederverwendungs Aspektbezogene Objekt Klassenmodell en Beschaffungsentscheide Teilkonzepte erstellen bzw bearbeiten treffen erstellen und erg nzen Nc Prozesse und Kommunikation festlegen Physische Struktur festlegen Ressourcen zuteilen Pr zise Definition von Objekten Klassen Zusammenarbeit Validieren und Inkrementeller Aufbau verifizieren des L sungskonzepts BILD 6 1 Zusammenh nge zwischen den Aufgaben des Architekturentwurfs am Beispiel eines objekt orientierten Entwurfs 6 5 3 2 Modellierung und Dokumentation Die Auswahl von Architekturmustern und Architekturmetaphern richtet sich nach dem gege benen Problem Architekturmuster sind vorgefertigte parametrierbare Schablonen f r die Ge staltung der Architektur eines Systems oder einer Komponente vgl Abschnitt 6 7 Architektur metaphern sind Leitbilder f r die Gestaltung von Architekturen Durch Analogien zwischen der Metapher und der Architektur erleichtern sie das Verst ndnis der letzteren vgl Abschnitt 6 8 Die Festlegung mit welcher Art von Modulen und welcher Art von Modul Kooperation ge arbeitet werden soll konstituiert zusamm
132. geforderten Software vor Begr nden Sie Ihre Entscheidung b Angenommen Ihre Abteilungsleiterin entscheidet unabh ngig von Ihrem Vorschlag dass dieses Projekt nach einem Wachstumsmodell abzuwickeln ist Skizzieren Sie einen Lieferplan indem Sie Anzahl und Reihenfolge der Lieferungen festlegen und f r jede Lie ferung entscheiden welche Komponenten der geforderten L sung in welchem Ausbauzu stand darin enthalten sein sollen a Wo und mit welchem Ziel kann Prototyping im Software Entwicklungsprozess einge setzt werden b Schildern Sie je eine typische Projektsituation in der die Verwendung eines Demonstra tionsprototyps eines Prototyps im engeren Sinn eines Labormusters und eines Pilot systems sinnvoll sind Ein Unternehmen betreibt ein selbst entwickeltes System zur Auftragsabwicklung Die Anwender beklagen sich seit l ngerer Zeit ber die m hsame und nicht mehr zeitgem e Bedienung des Systems Mit der Funktionalit t des Systems sind die Benutzer nach wie vor zufrieden Soeben hat die Gesch ftsleitung beschlossen die Benutzeroberfl che des Auftragsabwicklungssystem zu erneuern und hat Sie mit der Durchf hrung des entspre chenden Projekts beauftragt Zur Minimierung des Projektrisikos wollen Sie Prototyping einsetzen Welche Arten von Prototypen setzen Sie wozu ein Begr nden Sie das Gesetz des kontinuierlichen Wachstums von Lehman Regel 3 6 Zie hen Sie dabei auch Bild 3 7 heran 34 Martin Glinz Software Engineerin
133. ger als 45s keine Taste gedr ckt und keine M nze ein gegeben wird und Zustand Bereit dann Annulliert ausl sen Ausgabe Getr nk ausgegeben Auswahl l schen Bild 7 12 Teilformale Spezifikation der Steuerung eines Getr nkeautomaten mit einem Zustands automaten 94 Martin Glinz Software Engineering I 7 5 3 Gliederungs und Abstraktionsmittel Abstraktionen dienen dazu ein Modell so zu gliedern und zu strukturieren dass die Komple xit t des Modells besser beherrschbar und die Darstellung damit leichter verst ndlich wird Da bei werden drei Abstraktionsarten unterschieden Bild 7 13 Ganzes I hoch m chtig Komposition Benutzung speziell ae allgemein tief elementar Teil Bild 7 13 Abstraktionsarten und ihre Dimensionen Die Komposition fasst eine Menge von Einzelkomponenten unter Weglassung von Details zu einer bergeordneten Komponente zusammen Wichtig dabei ist dass nicht irgendwie zusam mengefasst wird sondern dass logisch zusammengeh rende Komponenten so zusammengefasst werden dass die dabei entstehende bergeordnete Komponente ein in sich m glichst geschlos senes Teilmodell darstellt Man spricht daher auch von kapselnder Komposition Betrachtet man eine kapselnde Komposition umgekehrt von oben nach unten stellt sie eine hierarchische kap selnde Zerlegung des Ganzen in Teile dar Die Kompositionsabstraktion ist ein zentrales Mittel zur Beherrschung der Komplexit t umfan
134. greicher Spezifikationen mit vielen Einzelkomponen ten Bild 7 14 Auftrags position Bild 7 14 a Kompositionsabstraktion Komplexe Gebilde mit vielen Komponenten 7 Spezifikation von Anforderungen 95 Auftragsabwicklung Auftrags position 1 Mitarbeiter Auftragsabwicklung Ferti u er gung Personal Bild 7 14 c abstrahieren und damit bersichtlicher machen Die Benutzung erlaubt die Bildung von Schichten deren Komponenten sich einerseits auf Leistungen tieferer Schichten abst tzen und andererseits Leistungen f r h here Schichten anbie ten Dabei muss den Benutzern der Leistungen einer Schicht nur bekannt sein was diese Lei stungen sind nicht aber wie das Modell im Inneren der leistungserbringenden Schicht und in allen darunterliegenden Schichten aussieht d h was dort alles im Detail gefordert wird damit die angebotenen Leistungen zustande kommen Bei Verwendung konstruktiver Modelle zur Spe zifikation ist die Benutzungsabstraktion ein geeignetes Mittel zur Gliederung der Anforderungen in aufeinander aufbauende Schichten Bild 7 15 Unternehmen b erweisungs Bank auftrag Bild 7 15 a Benutzungsabstraktion Komplexe Gebilde 96 Martin Glinz Software Engineering I ersonal Sal rwesen Kreditoren versicherung Erstattung Zahlung Funktionen Zahlungs verkehr Archiv B U berweisungs auftrag Dienste Bank Infrast
135. gt als Beispiel die Ge wichtungskriterien f r Dateneingaben Tabelle 5 2 zeigt ein Schema f r die Berechnung des Function Point Rohwerts unadjusted Function Points UFP Hat also beispielsweise ein System 37 logische Transaktionen mit Dateneingaben von denen 12 als einfach 16 als mittel und 9 als komplex bewertet werden so ergibt sich ein Wert von 12x3 16x4 9x6 154 als Wert f r die Dateneingaben TABELLE 5 1 Gewichtungskriterien f r Dateneingaben IFPUG 1994 Anzahl bearbeiteter Anzahl unterscheidbarer Datenelemente in der Eingabe Datenbest nde 1 4 5 15 gt 15 0 1 einfach einfach mittel 2 einfach mittel komplex gt 2 mittel komplex komplex TABELLE 5 2 Schema zur Berechnung des Function Point Rohwerts UFP IFPUG 1994 Element Schwierigkeitsgrad einfach mittel komplex Dateneingaben Datenausgaben Anfragen Ext Schnittstellen X93 xX4 0 X93 0 X5 x4 x6 x5 x x4 x6 x7 x10 Int Datenbest nde x7 x10 x15 Function Point Rohwert UFP Der Rohwert wird mit Gewichtungsfaktoren multipliziert welche die technische Komplexit t des Systems reflektieren Der sogenannte Wertkorrekturfaktor VAF value adjustment factor berechnet sich nach der Formel 5 8 VAF 0 65 0 01 x TDI TDI ist der total degree of influence der gem Tabelle 5 3 berechnet wird Die Formel ist so konstruiert dass
136. gten Zur berwindung dieser Software Krise erhob Friedrich Ludwig Bauer 1968 die Forderung nach Software Engineering d h einem systematischen Vor gehen bei der Entwicklung wie es in klassischen Ingenieurdisziplinen seit langem blich ist Dabei muss man wissen dass zur damaligen Zeit allgemein die Auffassung herrschte das Schreiben von Software sei eine Kunst und erfordere daher individuelle k nstlerische Freiheit f r die Programmierer Auf diesem Hintergrund gesehen war Bauers Forderung revolution r In der Zwischenzeit hat sich die Erkenntnis weitestgehend durchgesetzt dass bei nichttrivia len Aufgaben eine wirtschaftliche und termintreue Entwicklung qualitativ guter Software ohne Software Engineering nicht m glich ist Trotz aller seither erzielter Fortschritte ist uns die Software Krise treu geblieben Das hat verschiedene Gr nde Einerseits zeigt sich dass gegen gesicherte Erkenntnisse des Software Engineerings immer wieder versto en wird Die Ursachen daf r liegen neben Unkenntnis mei stens in emotional bedingten Fehleinsch tzungen Andererseits werden Fortschritte dazu benutzt immer gr ere und schwierigere Software Systeme zu entwickeln vgl Abschnitt 1 2 3 R ckblickend wird klar dass es sich um keine Krise gehandelt hat sondern um die erste Manifestation der grunds tzlichen Schwierigkeit der Entwicklung gro er Software Die von Fairley 1985 gegebene Definition gibt das heutige Verst ndnis von Software E
137. hen ge stellt die das Projekt auf einen guten Weg oder auf den Holzweg f hren Es empfiehlt sich jedem Projekt ein Vorprojekt vorzuschalten in dem das Projekt aufgesetzt wird und wichtige Definitions und Planungsarbeiten ablaufen Die Muster 4 1 bis 4 4 zeigen m gliche Modelle f r ein Vorprojekt f r vier typische Entwicklungssituationen An Hand dieser Muster wird gezeigt wo welche Planungsaufgaben anfallen MUSTER 4 1 Start eines unternehmensinternen Softwareprojekts Projektidee Initiierung Projektauftrag vorbereiten Beauftragter Linie nderungen notwendig fertig Entscheid ber Projekt auftrag inie abgelehnt ok T Vorprojekt durchf hren Projektleiter Projekt Anforde fertig plan rungs nderungen spezifi notwendig kation Entscheid ber Projekt durchf hrung Linie abgelehnt Legende J schwarze Linien Abl ufe Projekt durchf hren graue Linien Daten o a 4 Software Projektf hrung MUSTER 4 2 Start eines externen Auftragsprojekts f r Software Anfrage R ckfragen Studie durch f hren Machbar keit Aufwand Beauftragter nderungen notwendig Auskunit W nsche Kunde Absage Entscheid ob offeriert wird Linie Otterte enth lt robe nforderungs Offerte schreiben spezifikation Wirtschaftlich keitsrechnung Projektskizze Bescheid erhalten Bescheid B
138. htlinien Ferner sind alle Ma nahmen zur Ausbildung und zur Vereinheitlichung der Arbeitsweise der Entwickler Qualit tslenkungs Ma nahmen Qualit tslenkung im Speziellen sind alle Ma nahmen die in der F hrung eines Projekts er griffen werden um die Erreichung der gesetzten Ziele sicherzustellen Qualit tspr fung wird in Abschnitt 9 3 besprochen 9 2 4 Dokumentation des Qualit tsmanagementsystems Das Qualit tsmanagementsystem wird wie folgt dokumentiert e Das Oualit tshandbuch enth lt die Beschreibung des Qualit tsmanagementsystems eines Unternehmens oder Unternehmensbereichs Falls das Unternehmen Kunden hat die ber das Qualit tsmanagement orientiert werden wol len bevor sie Auftr ge erteilen wird das Qualit tshandbuch in zwei B nde unterteilt Der erste Band wird auf Anfrage an Kunden abgegeben Er enth lt die Qualit tsmanagement Organisa tion und einen berblick ber die Qualit tsmanagement Ma nahmen Der zweite Band ist das Handbuch der Qualit tsmanagement Verfahren Er beschreibt das un ternehmensspezifische Qualit tsmanagement Know How und ist vertraulich Der Software QOualit tsplan enth lt die Vorgaben betreffend Qualit t f r die Entwicklung von Produkten In der Regel gibt es einen allgemeinen Rahmenplan der bei Bedarf projektspezi fisch erg nzt wird Detaillierte Entwicklungsrichtlinien und Ausf hrungsbestimmungen die den Rahmen eines Qualit tsplans sprengen w rden werden h ufig in einem So
139. hung des gesetzten Ziels ging zum Teil erheblich auf Kosten anderer Quali t ten Das hei t dass manche Ziele sich gegenseitig konkurrenzieren Es kann daher keinen f r alle Software Vorhaben tauglichen Satz optimaler Ziele geben sondern die Ziele m ssen f r jedes Vorhaben entsprechend den jeweiligen konkreten Bed rfnis sen und Randbedingungen neu festgesetzt werden Bei der Planung muss ber cksichtigt werden dass manche Ziele abh ngig voneinander sind z B Termine und Sachziele und daher keine beliebigen Freiheitsgrade bei der Zielfestlegung bestehen Dort wo wesentliche Ziele sich konkurrenzieren ist es sinnvoll die Ziele mit Priorit ten zu versehen FESTSTELLUNG 2 1 Es gibt keine nat rlichen Ziele f r Software Die Ziele m ssen f r jedes Entwicklungsvorhaben neu festgelegt werden Dabei ist zu beachten dass sich Ziele konkurren zieren k nnen und dass Ziele voneinander abh ngig sein k nnen FESTSTELLUNG 2 2 Die Wahl der Ziele hat einen erheblichen Einfluss auf das Produkt und den Entwicklungsprozess 1996 2000 by Martin Glinz Alle Rechte vorbehalten Reproduktion zum nicht kommerziellen Gebrauch mit Quellenangabe gestattet Reproduktion auch auszugsweise zum kommerziellen Gebrauch nur mit schriftlicher Bewilligung des Verfassers gestattet 14 Martin Glinz Software Engineering I Ziel Qualit t der Ergebnisse Optimiere Erstellungs Anzahl Speicherbedarf Klarheit des Klarheit der aufwand Anweisungen P
140. hw chen in den Produkten anderer etwas f r die eigene Arbeit Auf die gleiche Weise wird eine einheitliche Anwendung von Standards und Konventionen innerhalb der Organisation gef rdert Die in Reviews festgestellten M ngel lassen sich statistisch auswerten Die Ergebnisse k n nen zur Qualit tslenkung verwendet werden Tritt beispielsweise eine bestimmte Art von Feh lern besonders h ufig auf so k nnen gezielt Ma nahmen ergriffen werden damit diese Fehler nicht mehr gemacht werden 9 4 2 Die Durchf hrung von Reviews Effektivit t und Erfolg von Reviews h ngen wesentlich von der richtigen Durchf hrung ab Dazu geh rt nicht nur die Abwicklung der eigentlichen Review Sitzung nach besonderen Re geln sondern ein insgesamt wohlorganisiertes Umfeld 9 Qualit tsmanagement 119 9 4 2 1 Der Ablauf eines formellen Review Zu einem formellen Review geh ren die nachfolgend beschriebenen f nf Schritte 1 Planung Reviews m ssen in der Entwicklung eingeplant werden Der notwendige Aufwand an Zeit und Arbeitskapazit t ist zu budgetieren Die Review Teilnehmer m ssen rechtzeitig eingeladen und mit dem zu pr fenden Material versorgt werden Je nach Qualit tsanforderungen k nnen die Aufwendungen f r Reviews bis zu 15 des gesamten Entwicklungsaufwandes ausmachen 2 Vorbereitung Die Teilnehmer an einem Review erhalten das zu pr fende Material sowie die Referenzunter lagen im Voraus und bereiten sich individuell auf die Sitzung
141. ickt Eine informelle Nachsitzung z B bei ei nem gemeinsamen anschlie enden Mittagessen kann solchen Probleml sungsgespr chen Raum bieten Jeder Gutachter nennt mindestens einen positiven und einen negativen Punkt im zu pr fenden Material Stilfragen werden nicht diskutiert Dort wo vorgeschriebene Standards auch Stilfragen regeln werden Abweichungen vom Standard als M ngel genannt in allen anderen F llen ist der Stil Ermessenssache der Autoren Das Produkt wird bewertet nicht deren Produzenten Reviews sind dazu da die Qualit t von Produkten zu beurteilen Sie sollen und d rfen nicht dazu verwendet werden die F higkeiten der Personen welche das Produkt erzeugt haben zu beurteilen Dies gilt sowohl f r die Review Teilnehmer wie f r die Manager Die Teilnehmer m ssen sich mit pers nlichen Beurteilungen zur ckhalten um die positive Atmosph re w hrend des Reviews nicht zu ge 122 Martin Glinz Software Engineering I f hrden und um den Autor welcher beim Review anwesend ist nicht ber das unvermeidliche Ma hinaus psychisch zu belasten Die Manager d rfen die Review Ergebnisse nicht zur Mitarbeiterbeurteilung heranziehen wenn sie nicht wollen dass die Reviews massiv an Effektivit t verlieren weil die Gutachter ihre Kollegen welche das gepr fte Produkt erzeugt haben schonen e Die Pr fung ist umso einfacher und effizienter je mehr Standards und Pr flisten bereitstehen nach denen bewertet werden kann Wo keine
142. ie Beziehung LEITET zur ABTEILUNG FERTIGUNG und die Operation BEF RDERN DEFINITION 7 5 Klasse class Eine eindeutig benannte Einheit welche eine Menge gleich artiger Objekte beschreibt Beispiel Die Klasse MITARBEITER mit den Attributen NAME VORNAME GESCHLECHT TITEL ZIVILSTAND ANZAHL KINDER und den Beziehungen ARBEITET IN und LEITET zur Klasse ABTEILUNG beschreibt Personen der Art wie Eva M ller eine ist Eine Klasse beschreibt den Aufbau die Bearbeitungsm glichkeiten und das m gliche Ver halten von Objekten dieser Klasse Eine Klassendefinition besteht aus e der Definition der Attribute der Klasse und der Wertebereiche dazu lokale Merkmale e der Definition der Beziehungen zu anderen Klassen referenzierte Merkmale e der Definition der Operationen die auf Objekten der Klasse oder auf der Klasse selbst m glich sind 100 Martin Glinz Software Engineering I Dabei gibt es immer zwei Sichten f r Klassen In der intensionalen Sicht ist eine Klasse ein Typ Alle Objekte der Klasse sind nach diesem Typ aufgebaut In der extensionalen Sicht dage gen ist eine Klasse eine Menge von Objekten H ufig werden beide Sichten miteinander ver mischt Klassen stehen wie folgt in Beziehung zueinander e Assoziation Die Objekte einer Klasse sind Merkmale von Objekten einer anderen Klasse Gilt in der Regel auch umgekehrt d h Assoziationen sind bidirektional e Benutzung Die Objekte einer Klasse benutzen Attribute oder Operatione
143. ie Pflege der Software f r den Nachweis qualit tsrelevanter Eigenschaften oder f r eine sp tere Auswertung notwendigen Dokumente und Messungen werden archiviert der Rest wird vernichtet 4 4 Software Risikof hrung Projektrisiken sind Ereignisse welche den sachlichen oder wirtschaftlichen Erfolg eines Projekts bedrohen Gut gef hrte Projekte zeichnen sich dadurch aus dass in ihnen die Risiken nicht dem Zufall berlassen werden sondern dass die Projektleiterin oder der Projektleiter eine explizite Risikof hrung betreibt Boehm 1989 1991 Charette 1989 Bild 4 5 zeigt die Aufgaben der Risikof hrung 4 Software Projektf hrung 43 Risikoerkennung Risikobestimmung Risikoanalyse Risikobewertung Risikof hrung Risikoplanung Risikosteuerung Risikominderung Risikoverfolgung BILD 4 5 Aufgaben der Risikof hrung 4 4 1 Risikobestimmung Als erstes m ssen die Risiken eines Projekts erkannt werden Eine Checkliste oder zumindest das Durchgehen der Liste der h ufigsten Software Projektrisiken Tabelle 4 1 ist dabei hilfreich TABELLE 4 1 Die 10 h ufigsten Software Risiken nach Boehm 1991 Risiko m gliche Ma nahmen zuwenig Leute gute Leute einstellen vorhandene Leute ausbilden Motivation und Arbeitsklima f rdern den richtigen Leuten die richtigen Aufgaben geben unrealistische Kosten und sorgf ltige Aufwandsch tzung Entwicklung mit Wachstumsmodell Terminpl ne Anforderungen reduzieren kostenorientierte
144. ien Inkrementeller Auf Modellfragmente bau der Anforde CE rungsspezifikation Pr fen und fertige Spezifikation validieren Dr Korrekturen Freigabe gt validierte Spezifikation Bild 7 3 M glicher Ablauf des Spezifikationsprozesses und Interaktionen der Beteiligten 86 Martin Glinz Software Engineering I 7 3 Dokumentation von Anforderungen 7 3 1 Klassifikation von Anforderungen Es gibt verschiedene Arten von Anforderungen Bild 7 4 Zun chst einmal wird zwischen Projekt und Produktanforderungen unterschieden In diesem Kapitel betrachten wir nur letztere Die Produktanforderungen wiederum gliedern sich in funktionale Anforderungen und Attribute Unter funktionalen Anforderungen verstehen wir alle Anforderungen die sich auf die Funktiona lit t eines Systems beziehen das hei t welche Ergebnisse aufgrund welcher Eingaben zu be rechnen und oder zu liefern sind Die Attribute spezifizieren die Art und Weise in der diese Funktionalit t zu erbringen ist Leistungsanforderungen sind Forderungen bez glich Zeiten Mengen Geschwindigkeiten Raten etc Besondere Qualit tsanforderungen sind Forderungen beispielsweise an Zuverl ssigkeit oder Benutzerfreundlichkeit Randbedingungen schlie lich sind alle Forderungen welche die Menge der m glichen L sungen zus tzlich beschr nken z B Gesetze und Normen Leistungsanforderungen besondere Qualit tsanforderungen und Randbedingungen werden auch nicht funktionale Anford
145. iert Dort wo der Code generiert werden kann bzw soll entsteht ein formelles Entwurfsdoku ment dessen Syntax den Vorschriften des Generators gen gen muss Typische Kandidaten f r die Generierung sind Datenbanken und einfache Datenbankanwendungen einschlie lich der zugeh rigen Bildschirmmasken Aus hinreichend pr zisen teilformalen Entwurfsmodellen k nnen mit geeigneten Werk zeugen Coderahmen generiert werden die dann von Hand auszuprogrammieren sind 8 2 Systematisches Programmieren Die Qualit t der resultierenden Software wie auch der f r die Pr fung erforderliche Aufwand lassen sich durch systematisches Programmieren erheblich beeinflussen Besonders wichtige Punkte sind e die geeignete Wahl von Algorithmen und Datenstrukturen und deren ad quate Programmie rung e die Verwendung geschlossener Ablaufkonstrukte solche mit einem Eingang und einem Aus gang e die saubere Gliederung der Software in Prozeduren und Module e die Verwendung symbolischer Konstanten e die Verwendung selbstdokumentierender Namen f r Prozeduren Variablen Konstanten und Typen e die Dokumentation aller Definitionen durch Kommentare e bei Prozeduren Voraussetzungen die beim Aufruf erf llt sein m ssen Ergebniszusicherun gen Aussagen die nach der Ausf hrung der Prozedur gelten Bedeutung und Kommunika tionsrichtung der Parameter 1994 1996 by Martin Glinz Alle Rechte vorbehalten Reproduktion zum nicht kommerziellen Gebrauch mit Quellenanga
146. ifiziert die Reaktionen des Systems auf eine gegebene Folge u erer Ereignisse Bild 7 12 7 5 4 5 Objektorientierte Spezifikation Objektorientierte Spezifikationsverfahren sind konstruktive teilformale Methoden Es gibt eine Vielzahl verschiedener Ans tze zum Beispiel Booch 1994 Coad und Yourdon 1991a b Jacobson et al 1992 Rumbaugh et al 1991 Wirfs Brock et al 1990 Zur Zeit bildet sich mit der Unified Modeling Language UML Booch Jacobson und Rumbaugh 1997 ein Quasi Standard Nachstehend werden die Prinzipien der objektorientierten Spezifikation be schrieben Die Grundidee ist ein System durch eine Menge von Objekten zu spezifizieren von denen jedes einen in sich geschlossenen Teil der Daten der Funktionalit t und des Verhaltens des Systems beschreibt Dabei wird ein Ausschnitt der Realit t auf Objekte und deren Eigenschaften abgebildet Gleichartige Objekte werden durch Klassen modelliert DEFINITION 7 4 Objekt object Ein individuell erkennbares von anderen Objekten eindeutig unterscheidbares Element der Realit t Beispiel Die konkrete Person Eva M ller 36 Jahre alt Dr oec publ Leiterin Fertigung in der Firma AGP verheiratet ein Kind wird als Objekt modelliert Objekteigenschaften werden als Attribute und Attributwerte als Beziehungen zu anderen Objekten oder als Operationen auf den Objekten modelliert Beispiel Das Objekt EVA M LLER hat das Attribut GESCHLECHT mit dem Wert WEIBLICH d
147. iligten sind gleichberechtigt Proble me und anstehende Entscheidungen werden ausdiskutiert Die Verantwortung wird gemeinsam getragen Der Projektleiter ist in dieser Struktur Vorsitzender aber nicht Chef Bei mehr als ca f nf Beteiligten funktionieren demokratische Teams nicht mehr weil der Kommunikationsbedarf zu stark steigt vgl Bild 1 6 Durch hierarchische Strukturen ein oder 1996 1999 by Martin Glinz Alle Rechte vorbehalten Reproduktion zum nicht kommerziellen Gebrauch mit Quellenangabe gestattet Reproduktion auch auszugsweise zum kommerziellen Gebrauch nur mit schriftlicher Bewilligung des Verfassers gestattet 36 Martin Glinz Software Engineering I zweistufig je nach Personenzahl wird der Kommunikationsbedarf kanalisiert Die Projektleiterin steht an der Spitze dieser Hierarchie ist den Projektbeteiligten gegen ber weisungsbefugt und tr gt die Projektverantwortung allein Bild 4 1 b Bei allen Organisationsformen ist anzustreben dass m glichst viele der Projektbeteiligten m glichst ausschlie lich f r dieses Projekt arbeiten Je mehr Projekte eine Person gleichzeitig bearbeitet desto h her werden die Umschaltverluste beim bergang von der Arbeit am Projekt X zu der am Projekt Y PL PL Projektleiter PL Stab klein mittel gro BILD 4 1 A Demokratisches Team B Hierarchisch organisiertes Team 4 1 2 Der Projektstart Der Projektstart ist eine der kritischen Phasen eines Projekts Hier werden die Weic
148. indest vorl ufige Zuordnung von Ressourcen zu den Komponenten der Software Architektur ist bereits in der Konzipierung notwendig weil sonst die technische Machbarkeit des L sungskonzepts und die Erf llbarkeit der gestellten Anforderungen insbesondere der Leis tungsanforderungen nicht berpr ft werden k nnen Ressourcen K nnen sowohl logischer Art z B Prozesse als auch physischer Art z B Prozessoren sein Folgende Zuordnungen m ssen vorgenommen werden e Module zu Prozessen e Prozesse zu Prozessoren e Daten zu Speichern bzw Medien e Prozesskommunikation zu Kommunikationstechnologien und medien Die wesentlichen Kriterien dabei sind in dieser Reihenfolge Erf llung der Anforderungen Klarheit der Struktur und Ressourceneffizienz Angestrebt wird eine m glichst hohe berein stimmung zwischen der logischen und der physischen Struktur des Systems Solange die Leis tungsanforderungen erf llt sind werden daf r auch Ineffizienzen z B ungleichm ig ausgela stete Prozessoren in Kauf genommen Eine test und nderungsfreundliche Software Struktur ist besser und wirtschaftlicher als eine chaotische Struktur mit optimal ausgelasteten Ressourcen 6 3 7 Aspektorientierung W hrend man insgesamt versucht die L sung in voneinander m glichst unabh ngige Teill sungen zu gliedern gibt es Querschnittsaufgaben die nur in einer Gesamtsicht befriedigend kon zipiert werden k nnen Dabei wird die Darstellung auf den betreff
149. ine Gr enordnung schwieriger e Fehler infolge von emotionalen Fehleinsch tzungen Immaterielles hat keinen Wert und ist total flexibel was im Kleinen geht geht genauso im Gro en etc Software Entwicklung wird daher unbewusst emotional meist als viel einfacher eingesch tzt als sie tats chlich ist Dies f hrt zu unrealistischen Erwartungen und zu von Beginn weg zu tiefen Kosten und Termin sch tzungen Eine besonders h ufige Fehlerursache ist das Denken und Handeln in der Welt von Klein Software w hrend tats chlich gro e Software zu entwickeln ist vgl Tabelle 1 1 Besonders verheerend wirkt sich die lineare Extrapolation von Erfahrungen mit Klein Software auf gro e Software aus Bild 1 7 8 Martin Glinz Software Engineering I Aufwand tats chlicher TAA Aufwand Personen monate lineare Extrapolation von Kleinprojekten Produktgr e Codezeilen BILD 1 7 Fehleinsch tzungen bei linearer Extrapolation 1 3 Software Engineering In der Anfangszeit der Informatik gab es mit der Entwicklung von Software kaum Probleme Dies ist nicht weiter verwunderlich denn die Software bestand aus einzelnen weitgehend von einander unabh ngigen Programmen die jedes f r sich eine beherrschbare Gr e hatten Die Schwierigkeiten der Software Entwicklung manifestierten sich erst in den 60er Jahren als immer umfangreichere Software entwickelt wurde und die bis anhin verwendeten ad hoc Vorge hensweisen zunehmend versa
150. iner Bank hat auf der Grundlage eines Tabellenkalkulationsprogramms eine kleine pers nliche Anwendung geschrieben die sie bei der berpr fung der Kredite der von ihr betreuten Firmen unterst tzt Die notwendigen Daten gibt sie jeweils von Hand ein Der Abteilungsleiter sieht diese Anwendung zuf llig ist davon angetan und beschlie t sie allen Kundenbetreuerinnen und betreuer zur Ver f gung zu stellen Die notwendigen Daten sollen neu automatisch als den Datenbanken der Bank bernommen werden Die Kundenbetreuerin gibt an f r die Entwicklung ihrer Anwendung insgesamt etwa vier Arbeitstage aufgewendet zu haben Der Abteilungsleiter veranschlagt daher f r die ber nahme und die gew nschten nderungen einen Aufwand von einer Arbeitswoche Als die ge nderte Anwendung endlich zur Zufriedenheit aller Beteiligten l uft sind jedoch rund acht Arbeitswochen Aufwand investiert Der Abteilungsleiter erz hlt die Geschichte einem befreundeten Berater als Beispiel dass Informatik Projekte nie ihre Termine einhalten Darauf meint der Berater trocken der investierte Aufwand sei v llig realistisch und normal Begr nden Sie warum 1 5 Ein Unternehmen stellt Messger te her in denen Messungen und Ger tebedienung mit Hilfe von Software erfolgen Bei einem in Entwicklung befindlichen neuen Ger t findet die f r die Hardware verantwortliche Abteilung heraus dass pro Ger t 20 Franken eingespart werden k nnen wenn der geplante Prozessor durch ei
151. inigen Kapi teln wurden Aufgaben hinzugef gt und die Darstellung redaktionell bearbeitet In allen Kapiteln wurden verschiedene Details korrigiert und erg nzt Ferner ist die Rechtschreibung den neuen Regeln angepasst worden Zu diesem Skript ist ein Lernzielkatalog erh ltlich aus dem ersichtlich ist welche Teile des Skripts Bestandteil der Vorpr fung in Informatik f r Studierende der Wirtschaftsinformatik und der konomie an der Universit t Z rich sind Z rich im September 1998 Durchgesehene Neuauflage f r das WS 1999 2000 Z rich im August 1999 Durchgesehene geringf gig erg nzte Neuauflage f r das WS 2000 2001 Die Erg nzungen betreffen die Kapitel 2 und 5 sowie das Literaturverzeichnis Z rich im September 2000 Durchgesehene geringf gig erg nzte Neuauflage f r das WS 2001 2002 Die Erg nzungen betreffen die Kapitel 3 neue Aufgabe 3 1 und 5 Regel 5 3 Z rich im September 2001 Martin Glinz 1996 2001 by Martin Glinz Alle Rechte vorbehalten Reproduktion zum nicht kommerziellen Gebrauch mit Quellenangabe gestattet Reproduktion auch auszugsweise zum kommerziellen Gebrauch nur mit schriftlicher Bewilligung des Verfassers gestattet 1 Einf hrung Software Entwicklung als Problem 1 1 Einf hrung Software Entwicklung als Problem Software ist in den vergangenen Jahrzehnten zu einem derjenigen Faktoren geworden ohne die in den hochentwickelten L ndern nichts mehr geht Die Entwickl
152. ischen Rahmen Dieser wird durch das Quali t tsmanagementsystem gebildet 1993 1999 by Martin Glinz Alle Rechte vorbehalten Reproduktion zum nicht kommerziellen Gebrauch mit Quellenangabe gestattet Reproduktion auch auszugsweise zum kommerziellen Gebrauch nur mit schriftlicher Bewilligung des Verfassers gestattet 112 Martin Glinz Software Engineering I Definition 9 3 Qualit tsmanagementsystem Die Struktur Verantwortlichkeiten und Mittel zur Verwirklichung des Qualit tsmanagements ISO 8402 9 1 2 Besonderheiten des Software Qualit tsmanagements Software nimmt insofern eine Sonderstellung ein als e Software ein Produkt ist bei dem nur die Entwicklung schwierig ist die Produktion dagegen aus blo em v llig unproblematischem Kopieren besteht e es praktische keine Traditionen f r Software Entwicklung gibt e Software aufgrund ihres immateriellen Charakters schwierig zu berpr fen ist Bezogen auf Qualit t hei t dies dass die Qualit t der Entwicklung d h der Produkt sch pfung gesichert werden muss dass auf keine Traditionen und kein Berufsethos f r die Her stellung qualitativ hochwertiger Software zur ckgegriffen werden kann und dass die Qualit ts pr fung von Software schwierig ist Vor allem das zweite sorgt f r Schwierigkeiten bei der Einf hrung eines Qualit tsmanagementsystems und bei der notwendigen Verankerung des Qua lit tsbewusstseins in den K pfen der Beteiligten Grunds tzlich gibt es aber k
153. istungs schicht Arzege Tastatur Terminal Infrastruktur Kartenleser treiber Window Printer schicht Bild 6 3 Benutzungshierarchie und Schichtung im Entwurf mit Datenabstraktionen 6 6 3 _Objektorientierte Architektur Im objektorientierten Entwurf wird ein System als eine Menge kooperierender Objekte auf gefasst Wie eine Datenabstraktion besteht ein Objekt aus Daten und allen darauf m glichen Operationen Objekte bzw Klassen d h Objekttypen bilden die Einheiten der Modularisierung Jedes Objekt repr sentiert ein Objekt aus dem Anwendungsbereich zum Beispiel einen Kunden oder einen Artikel oder ein in sich geschlossenes Informatik Element das f r die Probleml sung ben tigt wird zum Beispiel ein Dialogfenster oder einen Schaltknopf in der Benutzer schnittstelle Das Verbergen des Objektinneren nach dem Geheimnisprinzip ist teilweise 74 Martin Glinz Software Engineering I m glich und wird angestrebt Das Prinzip der Vererbung s u l sst jedoch ein konsequentes Information Hiding nicht zu Die Objekte k nnen auf zwei verschiedene Arten kooperieren Erstens durch Benutzung Ein Objekt benutzt in seiner Implementierung Operationen die von anderen Objekten angeboten werden Im Gegensatz zum Entwurf mit Datenabstraktionen wird keine Benutzungshierarchie angestrebt Zweitens durch Vererbung Von jeder Klasse k nnen Unterklassen abgeleitet wer den welche alle Eigenschaften Datenstrukturen und Operationen v
154. it Logik ist deskriptiv Teilformale Spezifikationen basieren auf konstruktiven anschaulichen Modellen deren Kon struktionsregeln mit ihren Bedeutungen teilweise formalisiert sind die aber auch nicht formale Elemente verwenden Entity Relationship Modelle Zustandsautomaten sowie die verschiedenen Arten der strukturierten und der objektorientierten Analyse sind typische Vertreter dieser Art von Spezifikation 92 Martin Glinz Software Engineering I Zeit Ideen und Vor stellungen der Auftraggeber informale Spezifikation teilformale Spezifikation 100 formale Spezifikation Produkt Y Grad der Formalit t Bild 7 9 Verschiedene Wege bei der Formalisierung Bei der Beurteilung der Vor und Nachteile der drei Ans tze sind folgende berlegungen ma geblich e Informale Spezifikationen haben den gro en Vorteil leicht erstellbar zu sein Jedoch enthalten gro e nat rlichsprachige Spezifikationen in der Regel sehr viele Unklarheiten Auslassungen Mehrdeutigkeiten und Widerspr che Diese werden beim Pr fen l ngst nicht alle entdeckt da sorgf ltiges Lesen die einzige zur Verf gung stehende Pr fmethode ist Damit werden die Fehlerkosten zuwenig gesenkt und die Spezifikation wird unwirtschaftlich Formale Spezifikationen sind immer eindeutig die Widerspruchsfreiheit ist formal pr fbar Jedoch ist die Erstellung einer vollst ndig formalen Spezifikation und ihre Pr fung vor allem auf Ad qua
155. it Zeit und Kosten zu sparen 3 Der Software Prozess Diesen Vorteilen stehen folgende Nachteile gegen ber 25 Die Grundannahme dass ganze Systeme genauso wie Einzelkomponenten planvoll in einer Abfolge von Schritten konstruiert werden k nnen ist vor allem f r gro e Systeme mit langer Entwicklungs und Lebensdauer meistens falsch Solche Systeme sind in der Regel nicht konstruierbar sondern sie wachsen evolution r Dies gilt insbesondere dann wenn die Anforderungen an ein System nicht a priori genau bekannt sind Lauff hige Systemteile entstehen erst relativ sp t Die lange Durststrecke in der nur Dokumentation produziert wird ist nachteilig f r die Motivation der Projektbeteiligten Unter Umst nden wird erst sehr sp t erkannt dass vorgesehene L sungen technisch nicht realisierbar sind das System nicht die geforderten Leistungen erbringt oder dass es nicht das leistet was der Auftraggeber eigentlich wollte Das System muss in einem Schritt komplett in Betrieb genommen werden Ergebnisorientierte Phasenmodelle eignen sich daher vor allem dann wenn das Projekt nicht allzu gro ist die Aufgaben welche das zu erstellende System erf llen soll genau bekannt und pr zise be schreibbar sind die Beteiligten ber Know How im betreffenden Problembereich verf gen z B hnliche Pro jekte bereits abgewickelt haben das Entwicklungsrisiko eher gering ist Phasen Projekt definition
156. itte Installieren und Testen der Komponente als Teil des Gesamtsystems DEFINITION 3 3 Software Lebenslauf software life cycle Zeitraum in dem eine Software Komponente bearbeitet oder benutzt wird Beginnt mit der Initiierung der Komponente und en det mit ihrer endg ltigen Au erbetriebsetzung Umfasst typisch die Stadien Initiierung Entwick lung und Nutzung wobei die Entwicklung wiederum in die Stadien Spezifikation der Anforde rungen Konzept der L sung Entwurf und Programmierung Zusammensetzung mit anderen Komponenten und Inbetriebnahme einschlie lich der berpr fung des Entwickelten nach jedem Schritt zerf llt FESTSTELLUNG 3 2 Je kleiner ein St ck Software ist desto mehr verl uft ihr Lebenslauf linear Bei gr eren Komponenten und bei ganzen Systemen gibt es dagegen Iterationen in allen Sta dien des Lebenslaufs Solche Iterationen werden beispielsweise durch sich ndernde Anforderungen oder durch die Entdeckung und Korrektur von Fehlern verursacht Au erdem gibt es auch Prozessmodelle die 3 Der Software Prozess 21 von vornherein Iterationen vorsehen vgl die Ausf hrungen zu Wachstumsmodellen in Ab schnitt 3 2 W hrend der Nutzung eines Systems l st jede Anpassung oder Erweiterung die gleiche Folge von Entwicklungsaktivit ten f r die anzupassenden oder neuen Komponenten aus 3 1 4 Software Evolution Lehman teilt in seinem fundamentalen Artikel von 1980 die Software in drei Klassen ein e Softw
157. k ten zur Folge haben k nnen muss dieses Ph nomen im gew hlten Software Prozessmodell m glichst ber cksichtigt werden 22 Martin Glinz Software Engineering I 3 1 5 Meilensteine Meilensteine sind das wichtigste Mittel um den Ablauf eines Prozesses zu strukturieren und den Fortschritt wirksam zu kontrollieren DEFINITION 3 4 Ein Meilenstein ist eine Stelle in einem Prozess an dem ein geplantes Ergebnis vorliegt Ein Meilenstein wird geplant indem das zu erreichende Ergebnis und die daf r zur Verf gung stehenden Ressourcen Zeit Geld Personal etc festgelegt werden Ein Meilenstein ist er reicht wenn das verlangte Ergebnis nachweislich vorliegt Durch Vergleichen des geplanten mit dem effektiven Ressourcenverbrauch ist eine wirksame quantitative Fortschrittskontrolle m g lich Meilensteine sind nur wirksam wenn das mit einem Meilenstein verkn pfte Ergebnis so be schrieben ist dass die Erreichung des Meilensteins gemessen oder mit hinreichender Sicherheit berpr ft werden kann Bild 3 1 zeigt drei Beispiele Ergebnis in einem Software Prozess Eignung f r Meilenstein Codierung zu 90 beendet unbrauchbar da nicht messbar sondern nur sch tzbar Die Komponente xyz hat internen Abnahmetest geeignet da messbar an Hand des Abnahmetest bestanden Protokolls Die Anforderungsspezifikation liegt vor geeignet wenn Inhalt und Form des Dokuments durch ein Review berpr ft werden BILD 3 1 Eignung von Zwis
158. kennen Bei der Modularisierung m ssen Anwendungssituationen f r Muster erkannt und die entsprechenden Muster verwendet werden Bild 6 9 zeigt das Beobachtermuster observer pattern Gamma et al 1995 als Beispiel Die Intention des Beobachtermusters ist dass Objekte Daten bei einem Informationsanbieter Sub 6 Konzipieren von L sungen 77 jekt abonnieren k nnen Bei jeder nderung der abonnierten Daten werden die Abonnenten Beobachter automatisch ber die nderung informiert bzw werden ihnen die ge nderten Daten zugestellt Dieses Muster hat zwei typische Anwendungen e Entkopplung voneinander abh ngiger Objekte durch Ersetzung direkter Kommunikation ber Aufrufe durch eine indirekte ber Benachrichtigung e Trennung von Informationsbereitsteller und einer Menge von Informationsverarbeitern bzw darstellern Sujk Zuordnen Beobachter gt benachrichtigen Aktualisieren Subjekt L schen Beobachter Benachrichtigen o Fe ger F r alle zugeordneten Beobachter b b Aktualisieren selbst KonkretesSubjekt KonkreterBeobachter lt holt Information m 2 2___________L HoleXXX Aktualisieren Subjekt heuesXXX HoleYYY I Subjekt HoleXXX 1 ZUORDNEN f gt ein Beobachterobjekt in die Liste der zu benachrichtigenden Beobachter ein 2 Nach jeder Ver nderung ruft ein KONKRETESSUBJEKT seine geerbte Operation BENACHRICHTIGEN auf Diese iteriert die Liste der
159. kizze jeder Alternative Grund f r die Verwerfung 2 Struktur der L sung 2 1 bersicht Architekturstil Metapher n und Architekturmuster die der Architektur zugrunde liegen Teilsysteme und ihre Aufgaben 2 2 Prozessstruktur Prozesse und Kommunikation zwischen den Prozessen 2 3 Modulare Struktur Module und ihre Zusammenh nge bei objektorientiertem Entwurf Klassen bzw Objektmodelle 2 4 Entwurf der Module Beschreibung der Schnittstellen ggf Hinweise zur geplanten Implementierung 2 5 Physische Struktur Physische Gliederung der Software in Pakete Komponenten etc Ressourcenzuordnung 3 Aspektbezogene Teilkonzepte Ein Unterkapitel je interessierendem Aspekt zum Beispiel Datenhaltungskonzept Mensch Maschine Kommunikationskonzept Fehlerbehandlungskonzept Fehlertoleranzkonzept Sicherheitskonzept etc 4 Voraussetzungen und ben tigte Hilfsmittel 4 1 Ben tigte Software Beschreibung der ben tigten fertigen Software welche f r Entwicklung und oder Betrieb des Systems zu beschaffen bzw zu verwenden ist 4 2 Ben tigte Hardware Beschreibung der ben tigten Hardware welche f r Entwicklung und oder Betrieb des Systems zu beschaffen bzw zu verwenden ist 4 3 Ben tigtes Umfeld Charakterisierung der f r den Betrieb des Systems erforderlichen organisatorischen und oder technischen Strukturen und Abl ufe Quellennachweis 6 5 Der Entwurfsprozess 6 5 1 Einbettung Die Erstellung des Architekturentwurfs ist
160. kten haben Andernfalls k nnen die Prognosen sehr ungenau sein 5 2 2 Delphi Methode Die Delphi Methode versucht Expertensch tzungen zu objektivieren Mehrere Personen geben unabh ngig voneinander eine begr ndete Sch tzung ab In einer n chsten Runde erh lt jede r Beteiligte eine Zusammenfassung der ersten Sch tzungen Alle erstellen daraufhin eine neue Sch tzung wobei Abweichungen vom Mittelwert der vorhergehenden Runde zu begr nden sind Dies geht ber mehrere Runden bis alle Sch tzungen einigerma en beieinander liegen FESTSTELLUNG 5 2 Die Delphi Methode liefert zuverl ssigere Sch tzungen als die Experten beurteilung weil sie Ausrei er eliminiert Als Nachteil muss ein erheblich h herer Sch tzauf wand in Kauf genommen werden 5 Software Aufwandsch tzung 49 5 3 Algorithmische Sch tzverfahren Algorithmische Methoden bestehen aus einem oder mehreren Algorithmen zur Berechnung einer Kosten bzw Durchlaufzeit Funktion aus einer Reihe von Variablen Bei hinreichend ge nauen Eingaben ergeben sich erstaunlich pr zise Prognosen Bild 5 3 Actual project man months o Organic mode x Semidetached mode amp Embedded mode 5 10 20 50 100 200 500 1000 2000 5000 10 000 Intermediate COCOMO estimated man months Quelle Boehm 1981 BILD 5 3 Genauigkeit von COCOMO Sch tzungen Die Genauigkeit aller algorithmischen Methoden h ngt jedoch entscheidend von zwei Din gen ab e die Eingangsgr en de
161. kten f r Fortschrittskontrolle und Problemerken nung bietet die es bei Software als einem immateriellen Produkt nicht gibt Software Projekte m ssen daher sorgf ltiger geplant berpr ft und gelenkt werden als an dere technische Projekte M gliche Mittel hierf r sind die Verwendung und Einhaltung ge eigneter Prozesse sowie ein ad quater Umgang mit den Projektrisiken FESTSTELLUNG 3 1 Jede systematische Entwicklung von Software und jedes gr ere Software Pflegevorhaben wird als Projekt organisiert 3 1 3 Der Software Lebenslauf Der Software Lebenslauf ist ein grundlegendes Ph nomen f r das Verst ndnis von Software Prozessen Betrachtet man eine beliebige Software Komponente isoliert f r sich so stellt man fest dass jede solche Komponente einen Lebenslauf hat welcher die Stadien Initiierung Ent wicklung Nutzung durchl uft In der Entwicklung laufen f r die Erstellung einer solchen Einzelkomponente folgende T tigkeiten ab Analysieren der Aufgabe und Spezifizieren der Anforderungen Dokumentieren und Pr fen der Anforderungen Konzipieren der L sung Grobkonzept Architekturentwurf Dokumentieren und Pr fen des Konzepts Entwerfen der L sung im Detail Dokumentieren und Pr fen des Entwurfs Codieren des Programmst cks f r die betreffende Einzelkomponente Testen des Programm st cks Integrieren mit den Programmst cken anderer Einzelkomponenten Dokumentieren und Testen der Integrationsschr
162. lanung eines konkreten Projekts wird das Prozessmodell konkretisiert und mit einer personellen Organisationsstruktur verbunden Die per sonelle Organisationsstruktur legt die Funktionen Aufgaben Verantwortlichkeiten und gegen seitigen Beziehungen der am Projekt beteiligten Personen fest Die Organisation von Software Projekten wird hier nicht n her behandelt da grunds tzlich die gleichen Regeln gelten wie f r andere Projekte Es werden nur zwei Aspekte kurz diskutiert die Rolle des Projektleiters und die Beziehungen der Projektbeteiligten untereinander Die Projektleiterin ist eine Schl sselfigur in jedem Software Projekt Ihre Kompetenzen und Verantwortlichkeiten m ssen klar geregelt werden Anzustreben ist eine F hrung durch Zielset zung d h die Auftraggeber bzw die Verantwortlichen in der Linienorganisation erteilen der Projektleiterin einen Auftrag und statten sie mit den daf r notwendigen personellen und materiellen Ressourcen aus Im Rahmen dieses Auftrags handelt die Projektleiterin eigenverantwortlich Sie berichtet der vorgesetzten Stelle regelm ig ber den Projektablauf und informiert insbesondere ber St rungen im Ablauf die mit projekteigenen Mitteln nicht behoben werden k nnen Die Beziehungen der Projektbeteiligten untereinander h ngen von der Zahl der Personen ab Bei wenigen Personen ist eine demokratische Struktur m glich welche Weinberg 1971 ideal typisch als egoless team bezeichnet Bild 4 1 a Alle Bete
163. leinen Projekten werden linear extrapoliert Bild 1 7 e Programmierer programmieren nicht 100 ihrer Zeit 1997 2001 by Martin Glinz Alle Rechte vorbehalten Reproduktion zum nicht kommerziellen Gebrauch mit Quellenangabe gestattet Reproduktion auch auszugsweise zum kommerziellen Gebrauch nur mit schriftlicher Bewilligung des Verfassers gestattet 48 Martin Glinz Software Engineering I Project 1 1777 Project 2 J Percent of source lines of code N N N N N N Model User User Control Help Error Moving Data Comments calculations inputs outputs message processing data declarations processing around form ts Quelle Boehm 1981 BILD 5 2 Woraus ein Programm besteht 5 2 Empirische Sch tzverfahren 5 2 1 Expertenbeurteilung Expertenbeurteilung ist eine vornehme Bezeichnung f r Sch tzungen ber den Daumen Die G te der Sch tzung steht und f llt mit der Erfahrung der Sch tzenden In der Regel wird auf grund von Analogien zu bisher abgewickelten Projekten gesch tzt Dies geht bei erfahrenen Leu ten in der Regel gut wenn Erfahrungen mit analogen Projekten vorliegen Krasse Fehler ergeben sich oft dann wenn Erfahrungen fehlen oder Erfahrungen mit kleinen Projekten auf gro e Pro jekte extrapoliert werden Bild 1 7 FESTSTELLUNG 5 1 Expertenbeurteilung ist ein einfaches und billiges Sch tzverfahren das dann recht gut funktioniert wenn die Sch tzenden Erfahrungen mit gleichartigen Proje
164. lgenden sechs W Fragen geben WARUM Veranlassung und Projektziele WAS die zu liefernden Resultate Produktziele WANN die geplanten Termine DURCH WEN Personen und ihre Verantwortlichkeiten WOMIT die zur Verf gung stehenden Mittel Geld Ger te Software WIE die Vorgehensweise und die Ma nahmen zur Sicherstellung des Projekterfolgs Muster 4 5 zeigt eine m gliche Gliederung eines Projektplans MUSTER 4 5 M gliche Gliederung eines Projektplans 1 Einleitung Projektname Anlass Veranlasser etc 2 Ziele Projektziele Verweis auf die Anforderungsspezifikation f r die Produktziele 3 Arbeitsplan 3 1 Arbeitspakete Was zu tun ist und wie die Arbeit gegliedert wird 3 2 Lieferung und Abnahme Was zu liefern ist wie und von wem es abgenommen wird 4 Software Projektf hrung 39 3 3 Risiken Liste der Risiken und der geplanten Ma nahmen zu ihrer Steuerung 4 Terminplan Was wann fertiggestellt sein soll 5 Personalplan 5 1 Projekt Organigramm wie das Projekt personell strukturiert ist 5 2 Personal Einsatzplan welche Person welche Aufgabe aus dem Arbeitsplan bearbeitet 6 Kostenplan geplante Kosten und ihre Verteilung ber die Projektdauer 7 brige Ressourcen sonstige ben tigte Hilfsmittel Entwicklungsmaschinen Software etc 8 Vorgehen Prozessmodell Einsatz von Methoden und Werkzeugen Qualit ts und Konfigurationsmanagement zu erstellende Dokumente existiert eine Entwicklungsrichtlinie un
165. lieferbare Mengen und Lieferfristen die Bestellungen der Verk uferinnen und Verk ufer aufnehmen und an die Auftragsab wicklung weiterleiten Auskunft ber Status und Liefertermin von Bearbeitung befindlichen Auftr gen geben 18 2 4 2 5 Martin Glinz Software Engineering I Die Verk uferinnen und Verk ufer welche dieses System benutzen sollen verlangen in der Zeit zwischen 8 00 Uhr und 18 00 Uhr eine sehr hohe Systemverf gbarkeit Nehmen Sie an Sie h tten den Auftrag f r diesen Benutzerwunsch ein messbares Ziel zu formulieren Wie gehen Sie vor und wie sieht Ihre Zielformulierung aus Sie sind Leiterin bzw Leiter eines Entwicklungsprojekts f r ein neues Standardsoftware paket zur Erstellung von Steuererkl rungen In einem Strategiepapier des Produkt Marke tings ist f r dieses Softwarepaket eine besonders benutzerfreundliche Bedienung ver langt Was tun Sie Eine Firma vertreibt Systeme mit denen technische Prozesse z B Produktionsstrassen Kraftwerke Wasserversorgungssysteme bedient und der Prozesszustand erfasst und angezeigt werden Ein Kunde welcher ein solches Leitsystem betreibt bestellt zus tzlich ein Programm zur statistischen Auswertung von laufend erfassten Betriebsdaten Nehmen Sie an Sie sind verantwortlich f r dieses Projekt Sie haben k rzlich ein hnliches System f r einen anderen Kunden entwickelt und installiert Der neue Auftrag unterscheidet sich von dem zuvor abgewickelt
166. me Typ Ver Pr fsumme Status LOG 0021 Materialwesen EntwDok 02 0873451 2 freigegeben LOG 0027 St ckliste Prog 03 0372538 1 freigegeben LOG 0028 Verwendungsnachweis Prog 02 0576927 6 in Pr fung Bild 11 2 Registrierung von Software Einheiten Von jeder Einheit k nnen mehrere Versionen gef hrt werden Im einfachsten Fall wird durch aufsteigende Versionsnummern deutlich gemacht in welcher Reihenfolge die Versionen entstan den sind Im allgemeinen Fall wird zwischen Revisionen entstehen durch berarbeitung und Varian ten haben gemeinsame Eigenschaften und in der Regel eine gemeinsame Vorg ngerversion unterschieden Conradi und Westfechtel 1998 11 4 Konfiguration und Release Soll eine Konfiguration an Kunden ausgeliefert werden so wird ein Release vgl Definition 3 10 gebildet Bild 11 3 Wesentliche Aufgaben in der Verwaltung von Releases sind die Buchf hrung dar ber welche Software Einheiten dazugeh ren wie diese voneinander abh ngen und wie aus den Ein heiten ein auslieferbares System generiert wird Software Einheit Versionen 01 02 03 04 05 06 St ckliste O O Verwendungs nachweis O O Teil O O Losgr e O O 1 0 1 1 2 0 2 1 2 2 Releases Bild 11 3 Eine Folge von Releases 11 Konfigurationsverwaltung 137 11 5 nderungswesen Grundlage eines geordneten nderungswesens sind getrennte Umgebungen f r Entwicklung Arbeitsumgebung Verwaltung Referenzumgebung Test Testumgebung u
167. min definiert Jede Lieferung ist betriebsf hig und kann nach Ausliefe rung sofort in Betrieb genommen werden Erfahrungen mit fr hen Lieferungen k nnen bei sp te ren Lieferungen ber cksichtigt werden DEFINITION 3 7 Wachstumsmodell Ein Modell f r den Software Entwicklungsprozess welches die Entwicklung in eine Folge von Iterationen unterteilt In jeder Iteration wird ein vollst ndiges Teilergebnis mit betriebsf higer Software erarbeitet und ausgeliefert Zeit Iteration 1 Iteration 4 Grundlieferung Teillieferung Grobanalyse Iteration 2 Definition der Teillieferung Lieferschritte Iteration 5 Iteration 3 Teillieferung Teillieferung h M glicher Prozess f r Anforderungs t Ab eine Teillieferung spezifikation Realisierung Jei nahm und Architektur Neben Meilensteine pro Teillieferung A A A A A Haupt Meilen steine A BILD 3 5 Beispiel eines Projektablaufs mit einem Wachstumsmodell Jede Lieferung wird als weitgehend autonomes Teilprojekt organisiert Da diese Teilprojekte in der Regel klein und kurz sind kann ein ergebnisorientiertes Phasenmodell als Prozessmodell verwendet werden Bild 3 5 zeigt den zeitlichen Ablauf eines nach einem Wachstumsmodell organisierten Projekts Bei der Definition des Umfangs und der Reihenfolge der Lieferungen wird immer ein schrittweiser Ausbau des Systems bis zum
168. n der Teile Zusammensetzen der Teile Inbetriebnahme Validierung Feststellen ob die Software sich den Auf jeden Entwicklungsschritt muss ein Pr fschritt Erwartungen entsprechend verh lt und n tige folgen sonst wird das Risiko dass das Korrekturen finden am Endprodukt statt Endergebnis unbrauchbar ist viel zu gro Eine Person entwickelt Keine Koordination Mehrere Personen entwickeln gemeinsam mehrerer beteiligter Personen erforderlich keine Koordination und Kommunikation notwendig Kommunikationsbed rfnisse Komplexit t des Problems in der Regel klein Komplexit t des Problems gr er bis sehr gro Strukturieren der Software und Behalten der explizite Ma nahmen zur Strukturierung und bersicht nicht schwierig Modularisierung erforderlich Software besteht aus wenigen Komponenten Software besteht aus vielen Komponenten die spezielle Ma nahmen zur Komponentenverwal tung erfordern In der Regel wird keine Dokumentation erstellt Dokumentation dringend erforderlich damit Software wirtschaftlichen betrieben und gepflegt werden kann Keine Planung und Projektorganisation erforderlich Planung und Projektorganisation zwingend er forderlich f r eine zielgerichtete wirtschaftliche Entwicklung Anzahl beteiligte Personen 1 2 TARA Anzahl Kommunikationspfade 0 1 3 6 10 15 Quantensprung Quantensprung Zahl der Kommunikation Kommunikationspfade ber wird erforderlich steigt Zahl de
169. n einer anderen Klasse zur Bereitstellung ihrer eigenen Attribute und Operationen e Vererbung Eine Klasse ist Unterklasse einer anderen Klasse Sie erbt alle Attribute und Ope rationen dieser Klasse d h alle Objekte der Klasse verf gen ber diese ohne dass sie in der Klasse lokal definiert worden w ren e Zu den Assoziationen werden Kardinalit ten modelliert wieviele Objekte der assoziierten Klasse m ssen mindestens d rfen h chstens mit einem Objekt der eigenen Klasse assoziiert sein KLASSE Mitarbeiter im Monatslohn UNTERKLASSE von Mitarbeiter ATTRIBUTE Name Kardinalit t Wertebereich Leistungslohnanteil 1 1 CHF berzeitsaldo 1 1 Stunde Ferienguthaben 1 1 Tag BEZIEHUNGEN Name Kardinalit t mit Klasse eingestuft in 1 1 Lohnklasse OPERATIONEN Lohn zahlen Voraussetzung Mitarbeiter ist aktiv Ergebniszusicherung Zahlungsauftrag zugunsten des Mitarbeiters ist erteilt mit Grundlohn aus Lohnklasse und Leistungslohnanteil BENUTZT Klasse Operation Zahlungsauftrag Erteilen Bild 7 20 Beispiel einer Klassendefinition am Beispiel einer Klasse aus einem Personal informationssystem Hinweis Da MITARBEITER IM MONATSLOHN eine Unterklasse von MITARBEITER ist wer den alle Attribute zum Beispiel NAME und VORNAME Beziehungen und Operationen der Klasse MITARBEITER automatisch bernommen ohne dass sie nochmals definiert werden m s sten Es gibt heute eine Vielzahl verschiedener Notationen f r Klassenm
170. n folgende Gruppen klassifizieren Editoren Editoren rationalisieren die Schreib und Zeichenarbeiten Struktureditoren und syntaxge steuerte Editoren beschleunigen die Dokumentationserstellung und die Programmierung Spezifikations und Entwurfssysteme Diese Systeme unterst tzen das Erstellen von Anforderungen und von Konzepten Architek turentw rfen f r Systeme vorzugsweise durch graphische Darstellungen und durch geeignete Speicherung der Information in einer Datenbank Programmentwurfssysteme In diese Kategorie fallen Werkzeuge zur Bearbeitung von Struktogrammen Pseudocode Jackson Diagrammen Programmablaufpl nen etc Compiler Browser und Programmierumgebungen Auch die gew hnlichen Compiler f r Programmiersprachen sind Werkzeuge Programmier umgebungen vereinigen Editoren Compiler Browser Software zum Durchst bern der Arbeits umgebung und von Software Bibliotheken evtl Interpreter Laufzeitumgebung Debugger und evtl ein Konfigurationsverwaltungssystem zu einem Satz aufeinander abgestimmter Werkzeuge f r die Programmierung 12 Produktivit tsfaktoren 143 Programmgeneratoren Programmgeneratoren sind bersetzer welche aus einer Hochsprache v a Datenbankspra chen sogen Sprachen der 4 Generation Programme in einer niedrigeren Sprache v a COBOL und Job Steuersprachen erzeugen Mess und Testwerkzeuge Werkzeuge dieser Kategorie dienen dazu interessierende Merkmale eines Programms zum Beispi
171. n im Gro en Berlin etc Springer 387 p Beschreibt im Wesentlichen nur das Problem des Software Entwurfs dieses aber sorgf ltig und gr ndlich Keine Einf hrung in Software Engineering Pagel B U H W Six 1994 Software Engineering Band 1 Die Phasen der Software Ent wicklung Bonn etc Addison Wesley 893 p Beschreibt in diesem ersten Band ausschlie lich die Entwicklungst tigkeiten Diese sind recht breit dargestellt Pfleeger S L 1991 Software Engineering The Production of Ouality Software 2nd edition New York Macmillan Publishing 517 p Leitfadenartig aufgebaut Auswahl und Darstellung vor allem im Detail oberfl chlich unsystematisch und teilweise veraltet Kommentiertes Literaturverzeichnis 149 Pomberger G G Blaschek 1993 Grundlagen des Software Engineering Prototyping und objektorientierte Software Entwicklung M nchen Hanser 337 p Beschreibt die Arbeit in den einzelnen Entwicklungsphasen ca ein Drittel des Buchs behandelt Objektorientierung wenig ber den Management Aspekt des Software Engineerings Pressman R S 1992 Software Engineering A Practitioner s Approach Third Edition New York etc McGrawHill 793 p Ansprechende und praxisorientierte aber sehr umfangreiche Darstellung des Themas Vor allem die technischen Aspekte sind sehr breit dargestellt Schach S R 1996 Classical and Object Oriented Software Engineering Third edition Chicago etc IRWIN 603 p
172. nchen Hanser 1990 Meyer B 1992 Applying Design by Contract IEEE Computer 25 10 Oct 1992 40 51 Meyer B 1997 Object Oriented Software Construction Englewood Cliffs N J Prentice Hall Neuauflage von Meyer 1988 Page Jones M 1988 The Practical Guide to Structured Systems Design Englewood Cliffs N J Prentice Hall Parnas D L 1972 On the Criteria To Be Used in Decomposing Systems into Modules Com munications of the ACM 15 12 Dec 1972 1053 1058 Shaw M D Garlan 1996 Software Architecture Perspectives on an Emerging Discipline Englewood Cliffs N J Prentice Hall 242 p Stevens W G G Myers L Constantine 1974 Structured Design IBM Systems Journal 13 2 115 139 Tresch M 1996 Middleware Schl sseltechnologie zur Entwicklung verteilter Informations systeme Informatik Spektrum 19 5 Okt 1996 249 256 Wirfs Brock R B Wilkerson L Wiener 1990 Designing Object Oriented Software Engle wood Cliffs N J Prentice Hall auf Deutsch Objektorientiertes Software Design M nchen Hanser 1993 Z llighoven H 1998 Das objektorientierte Konstruktionshandbuch Heidelberg dpunkt Ver lag 7 Spezifikation von Anforderungen 83 7 Spezifikation von Anforderungen 7 1 Grundlagen und Motivation 7 1 1 Definitionen und grundlegende Begriffe DEFINITION 7 1 Anforderung requirement 1 Eine Bedingung oder F higkeit die von einer Person zur L sung eines Problem
173. nd operativen Ein satz Produktionsumgebung der Software Einheiten Bild 11 4 Freie nderungen sind nur in Arbeitsumgebungen gestattet F r Software Einheiten in der Referenzumgebung gilt ein strikt reglementiertes nderungsprozedere nderungen in der Produktionsumgebung sind verboten Arbeits umgebungen fertig zur e nderung Referenz umgebung Lieferung zur Pr fung gepr ft t Test Produktions umgebung umgebung en Bild 11 4 Umgebungen f r Herstellung Verwaltung und Nutzung von Software Einheiten Der nderungsstand einer Software Einheit muss jederzeit nachweisbar sein beispielsweise durch F hrung von Formularen auf denen nderungen beantragt bewilligt und ihre Ausf hrung nachgewiesen werden Der Ablauf einer Anderung folgt einem festgelegten Prozess Bild 11 5 11 6 Behandlung von Problemmeldungen Grundlage f r die Behandlung von Problemen die beim Verwender eines Software Systems auftreten ist ein organisiertes Problemmeldungswesen Da die Verwender nicht wissen k nnen ob ihr Problem durch einen Software Fehler oder beispielsweise durch Unkenntnis oder eine Fehlbedienung verursacht ist wird bewusst nicht von Fehlermeldungswesen sondern von Pro blemmeldungswesen gesprochen Ben tigt werden unter anderem ein Problemmeldungsformular siehe Anhang und ein geordneter Bearbeitungsablauf M sglicher Bearbeitungsablauf Registrierung eingegangener Problemmeldungen Analyse der Meldung
174. nden um Jahre auseinander liegen k nnen Sichtbarmachen des Projektfortschritts Dokumente sind greifbare Resultate Der Abschluss jeder Phase der Entwicklung wird nachpr fbar markiert durch die Fertig stellung und Freigabe von Dokumenten Bei den Produktdokumenten wird stets die Endfassung eines Dokuments erzeugt welche nur noch ber ein geordnetes nderungswesen modifizierbar ist Das Erstellen von Zwischendokumenten nur mit dem Zweck des Nachweises abgeschlos sener T tigkeiten ist zu vermeiden 1991 1999 by Martin Glinz Alle Rechte vorbehalten Reproduktion zum nicht kommerziellen Gebrauch mit Quellenangabe gestattet Reproduktion auch auszugsweise zum kommerziellen Gebrauch nur mit schriftlicher Bewilligung des Verfassers gestattet 132 Martin Glinz Software Engineering I Dadurch dass die Abschlussdokumentation schritthaltend mit der Entwicklung entsteht ist der Projektfortschritt besser quantifizierbar 10 1 3 Wirtschaftlichkeit der Dokumentation Dokumentation kostet Entwicklungszeit und geld darum wird sie vor allem unter Termin druck oft nicht oder nur fragmentarisch erstellt Au er bei sehr kurzlebigen Systemen geht die Rechnung mit der Kosteneinsparung jedoch nicht auf Bild 10 1 Wird in einem Unternehmen das seine Software Entwicklung bisher nicht oder nur rudiment r dokumentiert hat sorgf ltiges Dokumentieren eingef hrt so ist folglich zu erwarten dass die Produktivit t in den fr hen Pha
175. ndlicher Software Die F hrbarkeit von Software Entwicklungsprojekten soll erleichtert werden Dies bringt Erleichterungen durch bessere Termin und Kostentreue und erleichtert die Kontrolle der Projek trisiken Letztlich bedeutet dies Senkung der Kosten bei verbesserter Qualit t Die Mittel die zur Erreichung dieser Ziele zur Verf gung stehen sind in Bild 1 8 skizziert Alle folgenden Kapitel sind der n heren Beschreibung dieser Mittel gewidmet Zielsetzung Konfigurations Dokumentation Modelle verwaltung Pr fung Methoden Qualit tsmanagement Sprachen Werk Arbeits Prozesst hrung Projektf hrung rkzguge klima Entwicklungs Projektplanung Mehrf ch gute Leute modelle Aufwand verwendun Prozess sch tzung g beurteilung Risikof hrung und lenkung Projektlenkung Produktivit t Qualit t F hrbarkeit BILD 1 8 Mittel des Software Engineerings und ihre Wirkung Aufgaben 1 1 Begr nden Sie die vier Hauptschwierigkeiten bei der Entwicklung von Software aus den Feststellungen 1 1 bis 1 9 und der Regel 1 1 10 Martin Glinz Software Engineering I 1 2 Ein Mann braucht zum Bau einer 2 m langen Br cke 0 5 Tage Wie lange brauchen 100 Leute f r den Bau einer 2 km langen Br cke Rechne Begr nden Sie warum das eine Milchm dchenrechnung ist Ziehen Sie Parallelen zur Entwicklung von Software 1 3 Was sind die drei grundlegenden Ziele des Software Engineerings 1 4 Eine Kundenbetreuerin im Firmenkundengesch ft e
176. ne Menge zusammengeh riger Objekte bzw zusammengeh riger Klassen die von ihrer Umgebung abgekapselt und nur ber eine oder mehrere Schnittstelle n der Komponente zug nglich sind Komponenten in diesem Sinn sind nach dem Geheimnisprinzip gebildete Module auf einer Stufe oberhalb von Objekten und Klassen die zudem geographisch verteilt sein k nnen Die Komponenten kommunizieren miteinander ber einen Makler broker Einerseits geben sie nach au en eine Schnittstelle bekannt ber die sie angesprochen werden k nnen Anderer seits greifen sie mit Hilfe des Maklers auf Objekte anderer Komponenten zu indem sie in deren Schnittstelle definierte Operationen aufrufen Bild 6 6 Die Komponenten sind stark voneinan 76 Martin Glinz Software Engineering I der entkoppelt Sie brauchen weder die Art der Realisierung der Kommunikation durch den Makler noch die geographische Lokalisierung der Partnerkomponenten noch deren Imple mentierung zu kennen Wenn die Schnittstellen in einer eigenen Schnittstellenbeschreibungs sprache interface definition language IDL beschrieben sind k nnen die Komponenten sogar in unterschiedlichen Programmiersprachen realisiert sein Ein typischer Vertreter einer komponentenorientierten Architektur ist die sogenannte Cli ent Server Architektur Eine Client Server Architektur besteht aus einer Menge von Klienten Clients d h Anwendungsprogrammen welche auf Arbeitsplatzstationen laufen einer Menge von Lieferanten
177. nen Sie ergreifen um diese Risiken zu steuern und oder zu verkleinern Erg nzende und vertiefende Literatur Es gibt eine F lle von Literatur ber Software Projektmanagement Stellvertretend seien hier die folgenden zwei B cher herausgegriffen Fr hauf Ludewig und Sandmayr 1999 geben eine kurz gefasste Einf hrung in die Probleme der Software Projektf hrung Weinberg 1992 geh rt zur Pflichtlekt re f r angehende Software Manager und Projektleiter Glinz 1999 enth lt eine Standortbestimmung sowie weitere Literaturverweise Boehm 1991 gibt einen berblick ber die Problematik der Risikof hrung Charette 1989 ist ein Lehrbuch ber Risikof hrung Boehm 1989 ist ein Tutorium das Artikel verschiedener Autoren zur Risikoproblematik enth lt Zitierte Literatur Boehm B W 1989 Software Risk Management Los Alamitos Ca IEEE CS Press Boehm B W 1991 Software Risk Management Principles and Practice IEEE Software 8 1 Jan 1991 32 41 Charette R N 1989 Software Engineering Risk Analysis and Management New York etc McGraw Hill Fr hauf K Ludewig J Sandmayr H 1999 Software Projektmanagement und Qualit tssicherung Dritte berarbeitete Auflage Z rich vdf Glinz M Hrsg 1999 Software Projektmanagement Informatik Informatique 6 5 Okt 1999 Weinberg G M 1971 The Psychology of Computer Programming New York Van Nostrand Reinhold Weinberg G M 1992 Quality
178. nen primitiveren ersetzt wird Der Verkauf rechnet damit w hrend 5 Jahren je etwa 400 Ger te abzusetzen es kann also eine Einsparung von ca 40 000 Franken erwartet werden Die nderung wird daher beschlossen kleine Anpassungen in der Software sind ja kein Problem Als die Softwareentwickler zwei Monate sp ter mit ersten Tests auf dem Zielsystem beginnen wollen stellt sich heraus dass ihr bisher immer verwendetes Echtzeit Betriebssystem auf dem neuen Prozessor nicht l uft und dass der stattdessen angebotene Echtzeit Kern f r ihre Bed rfnisse nicht ausreicht Durch die Verz gerung und die notwendigen Software Erweiterungen des Echtzeit Kerns entstehen Mehrkosten von ca 100 000 Franken Geben Sie Gr nde an wie es zu einer solchen Fehlentscheidung kommt Wie h tte der Fehler vermieden werden k nnen Erg nzende und vertiefende Literatur Brooks 1995 liefert in einer Sammlung von Essays eine unterhaltsame und lesenswerte Beschreibung von Fehlern im Software Engineering und ihren Ursachen Das Buch von 1995 ist eine Neuausgabe des Originals von 1975 mit zwei neuen Kapiteln IEEE 610 12 1990 ist die Standardreferenz f r die englischsprachige Terminologie im Soft ware Engineering Viele Definitionen in diesem Text sind bersetzungen aus IEEE 610 12 oder lehnen sich an diese an Lehman und Belady 1985 verdanken wir die Erkenntnisse ber die Software Evolution 1 Einf hrung Software Entwicklung als Problem 11 McDermid 19
179. ner gegebenen Wahrscheinlichkeit zu gew hr leisten als dies bei Produkten der klassischen technischen Disziplinen der Fall ist 1 1 3 Wozu dient Software Software dient dazu ein Problem zu l sen oder zu dessen L sung beizutragen indem men schliche oder technische Arbeitsvorg nge automatisiert oder unterst tzt werden Software steht daher in einer st ndigen Wechselwirkung mit Arbeits und Produktionsprozessen und mit den daran beteiligten Menschen Daraus folgen drei weitere wesentliche Eigenschaften von Software FESTSTELLUNG 1 4 Wenn ein Problem von seiner Natur her komplex und schwierig zu l sen ist so ist die Software zur L sung dieses Problems in der Regel nicht weniger komplex und schwierig 1 Einf hrung Software Entwicklung als Problem 5 FESTSTELLUNG 1 5 Bei der L sung von Problemen mit Software sind immer zwei Schwierig keiten gleichzeitig zu bew ltigen 1 Das Problem ist im Kontext seines Sachgebiets zu verstehen und befriedigend zu l sen 2 Die Probleml sung muss auf ad quate Software Strukturen abgebildet werden FESTSTELLUNG 1 6 Probleml sungen schaffen neue Realit ten und wecken neue Bed rfnisse Software ist daher nicht einfach ein Abbild der Realit t und bisheriger manueller Problem l sungen Sie konstruiert und ver ndert die Realit t Beispielsweise erm glicht Logistik Soft ware die Fertigung von G tern nach dem Just in time Prinzip Zulieferteile werden genau dann angeliefert wenn
180. nete Gegenma nahmen getroffen werden k nnen Zielkontrolle ist jedoch nur m glich wenn das Erreichte mit den Zielen verglichen werden kann Es muss daher m glich sein die Ziele zu messen Hierzu m ssen zun chst einmal geeignete Ma e gefunden oder definiert werden Dann m ssen f r jedes Ziel Referenzwerte festgelegt werden Im Minimum sind dies der Zielwert wenn dieser Wert gemessen wird ist das Ziel zu 100 erreicht und ein Schwellwert wenn dieser Wert mindestens erreicht ist wird das Ergebnis als nahe genug beim Ziel akzeptiert 2 4 Messung Durch Messungen werden interessierende Merkmale eines Gegenstands quantitativ erfassbar gemacht 2 4 1 Ma e Ein Ma ordnet mit Hilfe eines Messverfahrens einer Menge von Gegenst nden Messwerte auf einer Skala zu Die Messwerte machen eine Aussage ber das zu messende Merkmal der ge messenen Gegenst nde Dabei m ssen die Menge der Merkmalswerte und die Skala struktur hnlich sein das hei t die Eigenschaften der Skala m ssen mit denen des Merkmals berein stimmen DEFINITION 2 1 Ma Sei D eine Menge gleichartiger Gegenst nde mit einem zu messenden Merkmal M sei M d die Auspr gung des Merkmals M f r den Gegenstand de D und sei M die Menge aller dieser Merkmalsauspr gungen Ein Ma f r das Merkmal M ist eine Abbildung u D gt S welche jedem de D einen Messwert u d auf einer Skala S so zuordnet dass M und S struktur hnlich sind Dies ist genau dann der Fall we
181. ng In Budde et al Hrsg Approaches to Pro totyping Berlin etc Springer 1 19 Gilb T 1988 Principles of Software Engineering Management Reading Mass Addison Wesley Humphrey W S 1989 Managing the Software Process Reading Mass Addison Wesley IEEE 1990 Standard Glossary of Software Engineering Terminology IEEE Std 610 12 1990 IEEE Computer Society Press Kieback A H Lichter M Schneider Hufschmidt H Z llighoven 1992 Prototyping in indu striellen Software Projekten Informatik Spektrum 15 2 April 1992 65 77 Lehman M M 1980 Programs Life Cycles and Laws of Software Evolution Proceedings of the IEEE 68 9 1060 1076 Nachgedruckt als Kapitel 19 in Lehman und Belady 1985 Lehman M M L A Belady Hrsg 1985 Program Evolution Processes of Software Change London etc Academic Press Lehman M M 1992 A Model of Software Evolution and its Implications ABB Computer Science Conference Kopenhagen Mills H D D O Neill R C Linger M Dyer R E Quinnan 1980 The Management of Soft ware Engineering Part I V IBM Systems Journal 19 4 414 477 Royce W 1970 Managing the Development of Large Software Systems Proceedings IEEE WESCON 1 9 Nachgedruckt in Proceedings 9th International Conference on Software Engi neering Monterey 1987 328 338 4 Software Projektf hrung 35 4 Software Projektf hrung Da Software ein immaterielles Produkt ist f hrt eine ad hoc A
182. ng des Rests e die Herstellung eines systematischen Zusammenhangs zwischen bersichten und Detailsich ten In der Konzipierung werden haupts chlich vier Abstraktionsarten verwendet Komposition Benutzung Generalisierung Aspekte e Die hierarchische Zerlegung von komplexen L sungen in gekapselte in sich geschlossene Teill sungen siehe Abschnitt 6 3 2 verwendet die Kompositionsabstraktion e Die Verwendung von Komponenten ohne Kenntnis ihres inneren Aufbaus siehe Abschnitte 6 3 3 6 6 2 und Bild 6 3 ist eine Anwendung der Benutzungsabstraktion e Die Bildung von Klassenhierarchien im objektorientierten Entwurf vgl Abschnitt 6 6 3 bei der jedes Objekt einer Unterklasse einen Spezialfall von Objekten aller ihrer Oberklassen dar stellt basiert auf der Spezialisierungsabstraktion e Die separate Darstellung von Querschnittsaufgaben vgl Abschnitt 6 3 7 ist ein Beispiel f r die Verwendung der Aspektabstraktion 6 3 2 Modularit t Die Modularisierung ist eine der Hauptaufgaben beim Konzipieren von L sungen Sie glie dert eine L sung in kleinere besser verstehbare und berschaubare Teill sungen Module k n nen rekursiv wieder in Module zerlegt werden bis die Teill sungen klein genug sind Modulari sierung ist das Entwurfsprinzip schlechthin Ohne eine gute Modularisierung ist die Komplexit t gro er Systeme nicht mehr beherrschbar DEFINITION 6 4 Modul module Eine benannte klar abgegrenzte Komponente eines System
183. ng l sst sich im Nachhinein oft noch massiv verbessern Der Aufwand f r diese Verbesserungen lohnt sich da ein guter Dokumenten satz die Pflege verbilligt Aufgaben 10 1 Nehmen Sie Stellung zu folgenden Aussagen a Ich dokumentiere nicht weil wir in unserem kleinen Projekt alles auch so im Griff haben b Ich dokumentiere keine Anforderungen weil diese sich im Projektverlauf ja ohnehin ndern c Ich dokumentiere meinen Entwurf sobald sich beim Testen zeigt dass der Entwurf jetzt stabil ist 10 2 Warum m ssen Dokumente der Konfigurationsverwaltung unterliegen 11 Konfigurationsverwaltung 135 11 Konfigurationsverwaltung 11 1 Grundlagen ndern Sie noch eben schnell Die allzu einfache M glichkeit Software zu ndern ver ursacht eine Menge von Problemen zum Beispiel Codieren anhand der falschen Version des Entwurfs Paralleles unkoordiniertes ndern eines Moduls durch mehrere Personen Undokumentierte Schnellreparaturen an in Betrieb befindlicher Software Konfigurationsverwaltung ist das wichtigste Mittel zur Verhinderung bzw zur L sung solcher Probleme Definition 11 1 Software Konfigurationsverwaltung Software Konfigurationsmanagement software configuration management Die Gesamtheit aller Verfahren zur eindeutigen Kennzeichnung der Konfiguration eines Software Systems mit dem Zweck den Aufbau und alle nderungen dieser Konfiguration systematisch zu berwachen die Konsistenz
184. ngi neering sehr gut wieder DEFINITION 1 3 Software Engineering ist das technische und planerische Vorgehen zur syste matischen Herstellung und Pflege von Software die zeitgerecht und unter Einhaltung der ge sch tzten Kosten entwickelt bzw modifiziert wird Das IEEE Standard Glossary of Software Engineering Terminology IEEE 610 12 1990 nimmt das quantitative auf gemessenen Gr en basierene Arbeiten als weiteres Kriterium hinzu 1 Einf hrung Software Entwicklung als Problem 9 DEFINITION 1 4 Software Engineering Die Anwendung eines systematischen disziplinierten und quantifizierbaren Ansatzes auf die Entwicklung den Betrieb und die Wartung von Software das hei t die Anwendung der Prinzipien des Ingenieurwesens auf Software IEEE 610 12 Im deutschen Sprachraum ist anstelle von Software Engineering auch der Terminus Soft waretechnik gebr uchlich 1 4 Ziele und Mittel des Software Engineerings Mit Software Engineering werden drei grunds tzliche Ziele verfolgt Die Produktivit t bei der Herstellung von Software soll gesteigert werden Angesichts der horrenden Summen die j hrlich weltweit f r Software ausgegeben werden Bild 1 2 sind auch kleine Produktivit tssteigerungen von gro em wirtschaftlichem Interesse Die Qualit t der erstellten Software soll verbessert werden Dies bringt neben Wettbewerbs vorteilen durch zufriedene Kunden auch Kostensenkungen bei der Pflege und Weiterentwicklung von in Betrieb befi
185. ngineerings geh rende Themen Als Lehrbuch weniger geeignet Boehm B 1981 Software Engineering Economics Englewood Cliffs N J Prentice Hall 767 p Ein Standardwerk Fundgrube f r empirische und quantitative Aussagen Als Lehrbuch weniger geeignet Boehm B 1983 Seven Basic Principles of Software Engineering Journal of Systems and Soft ware 3 3 24 Ein klassischer Zeitschriften Artikel welcher v a den Management Aspekt des Software Engineerings in sieben Prinzipien zusammengefasst darstellt Brooks F P 1995 The Mythical Man Month Essays on Software Engineering Anniversary Edition Reading Mass etc Addison Wesley Unterhaltsame Beschreibung von Fehlern im Software Engineering und ihren Ursachen Neuausgabe des Originals von 1975 mit zwei neuen Kapiteln Eine Pflichtlekt re f r alle die sich f r Software Engineering interessieren Brooks F P 1987 No Silver Bullet Essence and Accidents of Software Engineering IEEE Computer 20 4 10 19 Klassischer Zeitschriftenartikel ber Einfaches und Schwieriges und die Nichtexistenz von Patentl sungen im Software Engineering Denert E 1991 Software Engineering Berlin etc Springer 452 p Kein Buch ber Software Engineering allgemein sondern ein Lehrbuch ber Entwicklung von Informations systemen nach einer vom Verfasser geschaffenen Methode F r dieses Teilgebiet ein sehr gutes praxisnahes Buch als allgemeine Einf hrung in Software Engineering
186. nicht geeignet Dumke R 1993 Modernes Software Engineering Eine Einf hrung Braunschweig Wies baden Vieweg 305 p Sammelsurium verschiedener Themen aus dem Software Engineering Nicht empfehlenswert Fairley R 1985 Software Engineering Concepts New York McGrawHill 364 p Kompakte sehr gute Einf hrung in die Thematik Leider seit Erscheinen nicht mehr revidiert daher nicht mehr auf dem neuesten Stand z B keine Aussagen ber Objektorientierung Trotzdem immer noch lesenswert Fr hauf K Ludewig J Sandmayr H 1999 Software Projektmanagement und Qualit ts sicherung Dritte berarbeitete Auflage Z rich vdf Einf hrung in zwei zentrale Teilgebiete des Software Engineerings in der Art einer Fibel Empfehlenswert Ghezzi C M Jazayeri D Mandrioli 1991 Fundamentals of Software Engineering Engle wood Cliffs N J Prentice Hall 573 p Ansprechende Darstellung Gewicht mehr auf technischer Seite des SE Beschreibung nicht nur von Auspr gungen sondern auch der zugrundeliegenden Konzepte Empfehlenswert Gilb T 1988 Principles of Software Engineering Management Reading Mass Addison Wesley 442 p Baut auf drei Ideen auf Messbare Anforderungen evolution re Entwicklung Pr fung mit Inspektionen Keine voll st ndige Einf hrung ins Thema Software Engineering Populistischer Stil in der Darstellung 148 Martin Glinz Software Engineering I Jalote P 1991 An Integrated Approach
187. nitte Phasen unterteilt und in jeder Phase einen Teil der insgesamt zu liefernden Ergebnisse erarbei tet Die Reihenfolge der Phasen orientiert sich am Software Lebenslauf Die Phasen in ergebnisorientierten Phasenmodellen sind nach diesem Ergebnis oder nach der vorherrschenden T tigkeit die zum Ergebnis f hrt benannt Es gibt keine Phasen Iteration In jeder Phase k nnen bzw m ssen notwendige Nacharbeiten an in fr heren Phasen erzielten Er gebnissen durchgef hrt werden Jeder Phasenabschluss bildet einen Meilenstein in der Entwicklung Weitere Meilensteine k nnen bei Bedarf hinzugef gt werden Die geforderten Ergebnisse der fr hen Phasen sind typisch Dokumente sp ter bestehen die Ergebnisse aus Code und Dokumenten Wie beim Wasserfall Modell gibt es auch hier eine Vielzahl von Varianten die sich in Rei henfolge und Benennung der Phasen unterscheiden Bild 3 4 zeigt einen typischen Vertreter Ergebnisorientierte Phasenmodelle haben folgende Vorteile Sie sind leicht verst ndlich und folgen dem nat rlichen Software Lebenslauf Sie sind ein geeignetes Instrument f r die Projektf hrung Sie f rdern planvolles Vorgehen mit sorgf ltigem Spezifizieren Konzipieren Pr fen und Do kumentieren Sie verhindern wildes Drauflos Programmieren nach dem Motto Ein hacken Probieren Absturz ndern Probieren Absturz Ausf hrliche Spezifikationen und Entw rfe tragen erheblich dazu bei Fehler fr h zu erkennen und dam
188. nn f r beliebige d1 d2 aus D gilt Zu jeder Relation R auf der Menge der Merkmalsauspr gungen M gibt es eine analoge Relation R auf der Skala S mit folgenden Eigenschaften 1 R M dl M d2 gt R u dl 1 d2 2 R u dl u d2 gt R M dl M d2 und die Aussage R M d1 M d2 ist sinnvoll interpretierbar Ma e f r Software werden in der Literatur oft auch als Metriken bezeichnet Die Bedingungen 1 und 2 werden auch als Repr sentations oder als Homomorphiebedingung bezeichnet H ufig werden Ma e definitorisch eingesetzt d h sie definieren ein intuitives Merkmal einer Menge von Gegenst nden BEISPIEL 2 1 Messung der Gr e eines Programms Ein m gliches Ma y f r das Merkmal Gr e eines Programms besteht aus der Abbildungsvorschrift Z hle die Programmzeilen die nicht leer sind oder ausschlie lich Kommentar enthalten und den nicht negativen ganzen Zahlen als Skala Auf dem Merkmal Gr e eines Programms gibt es zwei Relationen die Merkmalsauspr gungen sind vergleichbar und sie sind additiv Beide Relationen m ssen durch die Abbildungs vorschrift so auf entsprechende Relationen der Skala abgebildet werden dass die Homomorphie bedingung erf llt ist andernfalls w re y kein Ma Es muss also f r beliebige Programme P1 P2 und P3 gelten und sinnvoll interpretierbar sein 1 Gr e Pl lt Gr e P2 gt y Pl lt P2 Gr e P1 Gr e P2 Gr e P3 gt y Pl Y P2 P3
189. ntierten Test White Box Test Glass Box Test erfolgt die Auswahl der Testf lle aufgrund der Programmstruktur Es wird angestrebt die Programmstruktur m glichst vollst ndig abzudecken zum Beispiel alle Anweisungen mindestens einmal zu durchlaufen Die Spezifikation muss ebenfalls bekannt sein damit festgelegt werden kann welche Resultate mit den ausgew hlten Testdaten zu erwarten sind F r Einzelheiten wird auf die Literatur zum Beispiel Beizer 1995 Fr hauf Ludewig und Sandmayr 1991 Liggesmeyer 1990 Myers 1979 verwiesen Aufgaben 9 1 Sie arbeiten an der Entwicklung eines Software Produkts mit Wer ist f r die Qualit t dieses Produkts verantwortlich 9 2 Sie sind Projektleiter in einem Software Entwicklungsprojekt Soeben haben Sie den Review Bericht ber das L sungskonzept der zu entwickelnden Software erhalten Der Bericht weist neben einer Reihe leichter Fehler drei schwere Fehler und eine als kritisch 124 Martin Glinz Software Engineering I eingestufte Auslassung aus Sie sind gegen ber dem Zeitplan drei Wochen in Verzug und m chten daher so rasch wie m glich mit dem Detailentwurf und der Codierung beginnen lassen Wie verhalten Sie sich Was halten Sie von folgenden Ma nahmen a Sie lassen alle festgestellten M ngel beheben und beginnen nicht mit dem Detailent wurf bis das Dokument das Nachreview bestanden hat und freigegeben ist b Sie lassen sofort mit Detailentwurf und Codierung beginnen und beschlie en
190. nur mit schriftlicher Bewilligung des Verfassers gestattet 84 Martin Glinz Software Engineering I weil sie beim Fehlen einer Anforderungsspezifikation typisch erst bei der Abnahme oder im Betrieb gefunden werden und die Fehlerkosten exponentiell mit der Verweildauer der Fehler im System wachsen Bild 7 1 Wenn man Requirements Engineering vern nftig betreibt sind die Einsparungen bei den Fehlerkosten h her als der daf r notwendige Aufwand Das hei t das Spezifizieren von Anforderungen ist wirtschaftlich Bild 7 2 Relative Fehlerbehebungs kosten Spezifikation Entwurf Codierung Test Abnahme Betrieb nach Boehm 1981 Bild 7 1 Kosten f r die Behebung von Fehlern abh ngig von ihrer Verweildauer in der Software K Optimum der Wirtschaftlichkeit Aufwand f r Anforderungsspezifikation Fehlerkosten w hrend Entwicklung und Nutzung des Produkts Bild 7 2 Wirtschaftlichkeit der Anforderungsspezifikation 7 Spezifikation von Anforderungen 85 7 1 3 Merkmale einer guten Spezifikation Um die Fehlerkosten zu senken m ssen wir folglich erreichen dass a wenig Anforderungs fehler gemacht werden und b m glichst viele der dennoch gemachten Fehler m glichst fr h gefunden werden Daf r brauchen wir sowohl eine gute Anforderungsspezifikation als auch einen guten Spezifikationsprozess Eine gute Spezifikation zeichnet sich durch folgende Eigenschaften aus e Ad quatheit das beschreiben was de
191. objektorientiertem Stil Neben der Prozessstruktur und den Architekturen der einzelnen Prozesse muss auch eine Kommunikationsarchitektur entworfen werden Heute erleichtert man sich diese Aufgabe in der Regel durch die Verwendung k uflicher Kommunikationssoftware welche den Prozessen kom fortable Kommunikationsschnittstellen zur Verf gung stellt Die Prozesskommunikation wird so von einer Dienstleistungsschicht bernommen deren Architektur und Realisierung vor den Verwendern verborgen bleibt Bild 6 5 zeigt als Beispiel einer prozessorientierten Architektur die Erfassung Bereitstellung und Archivierung von Wechselkursdaten in einer Bank oder einem Handelshaus Wechselkursrechner Archivrechner Kurse Zeit reihen bilden Kurse und gt Trends Trends bilden Arbeitsplatzrechner aktuelleWerte O Prozess Kommunikation ber Speicher L gemeinsamer Speicherbereich Kommunikation ber Nachrichten Bild 6 5 Beispiel einer prozessorientierten Architektur 6 6 5 Komponentenorientierte Architektur Die komponentenorientierte Architektur ist eine Weiterentwicklung der objektorientierten Architektur insbesondere im Hinblick auf Verteilung und Wiederverwendung Es zeigt sich n mlich dass Klassen als Einheiten f r die geographische Verteilung eines Systems und als Ein heiten k uflicher wiederverwendbarer Software oft zu klein sind In einer komponentenorientierten Architektur versteht man unter einer Komponente ei
192. odelle Die meisten Nota tionen verwenden Rechtecke f r Klassen und Linien f r Assoziationen Die Klassensymbole werden h ufig durch zwei Linien unterteilt oben steht der Klassenname in der Mitte die wich tigsten Attribute unten die wichtigsten Operationen Die Notation f r Benutzung und Vererbung ist sehr uneinheitlich Hier werden verwendet Pfeile f r Benutzung gegabelte Linien f r Verer bung F r die Notation von Kardinalit ten gibt es eine verwirrende F lle von graphischen und numerischen Notationssystemen In Bild 7 21 wird die Notation der UML Unified Modeling Language Booch Jacobson und Rumbaugh 1997 verwendet Die Kardinalit ten sind in Beziehungsrichtung zu lesen zum Beispiel Eine ABTEILUNG BESCH FTIGT mindestens einen und h chstens beliebig viele MITARBEITER ein Stern steht f r beliebig viele 7 Spezifikation von Anforderungen 101 Mitarbeiter Stamm Nr Position 1 Hierarchiestufe Name 0 Stufe von Ferienanspruch Vorname Einstellen besch ftigt in Entlassen F 5 fti Individuallohn ndern 4besch ftigt Lohakiasse N eingestuft in 1 di 4 Klasse von 0 Stundenlohn Monatslohn Stundensatz berzeitsaldo Ferienguthaben Arbeitszeit erfassen Lohn zahlen Lohn zahlen 4 Abteilung N N Name Lohn Sitz Zahlungsauftrag bezahlt mit 0 PETER BEE Erteilen Stornieren Bild 7 21 Beispiel eines Klassenmodells stark vereinfachtes Modell eines Personal informationssy
193. oden und Notationen dargestellt und bilden dann die Anforderungsspezifikation Anforderungsanalyse und darstellung laufen iterativ und zeitlich verzahnt ab Bild 7 3 7 4 3 Die Rolle der IST Analyse In vielen Lehrb chern vor allem solchen lteren Datums klassisch zum Beispiel in McMen amin und Palmer 1984 wird verlangt dass der Spezifikationsprozess mit einer Analyse des IST Zustands beginnt Dabei wird folgendes Vorgehen empfohlen 1 Analyse des IST Systems erstellen eines Modells der gegenw rtigen Implementierung des IST Systems 2 Analysieren der dieser Implementierung zugrundeliegenden Konzepte erstellen des soge nannten essentiellen Modells des IST Systems Dabei wird von allen implementierungsspe zifischen Eigenschaften des IST Systems abstrahiert 7 Spezifikation von Anforderungen 89 3 Ableiten der Anforderungen an das neue System erstellen des essentiellen Modells des SOLL Systems Dieses Modell beschreibt die Anforderungen und ist im Idealfall frei von Entwurfs und Implementierungs berlegungen 4 Entwurfs des SOLL Systems Erstellen des mplementierungsmodells des SOLL Systems Der dritte Schritt in diesem Vorgehen ist der eigentliche Prozess der Anforderungsspezifika tion Dieses Vorgehen h lt jedoch in vielen F llen einer Wirtschaftlichkeitspr fung nicht stand Die Besch ftigung mit dem IST Zustand ist nur dann gerechtfertigt wenn e die Informatiker Analytiker die IST Aufgaben und die IST Arbeitsweise der
194. oftware wird von Menschen gemacht Die F higkeiten dieser Menschen ebenso wie ihre emotionalen Einstellungen und alle ihre Unzul nglichkeiten haben einen direkten und erheblichen Einfluss auf die von ihnen entwickelte Software vgl DeMarco und Lister 1991 Glinz 1988 und Weinberg 1971 1 2 3 Warum ist Software Entwicklung schwierig Wenn wir obenstehende Feststellungen und Regeln und die ihnen zugrundeliegenden Ph no mene analysieren so stellen wir fest dass es Wesentlichen vier Faktoren sind welche die Ent wicklung von Software schwierig machen Es sind dies Die Gr e der zu l senden Probleme Software ist nicht einfacher als die Probleme die sie l st Je gr er und schwieriger die Software desto aufwendiger und schwieriger ist ihre Ent wicklung Fortschritte bei der Beherrschung des Software Entwicklungsprozesses werden durch das Angehen gr erer und schwierigerer Probleme immer wieder kompensiert Die Tatsache dass Software ein immaterielles Produkt ist Die Immaterialit t macht das Arbei ten mit Software schwieriger als dasjenige mit materiellen technischen Produkten vergleichba rer Komplexit t Die Risiken sind schwieriger zu erkennen ad hoc Vorgehensweisen f hren schneller ins Desaster e Sich permanent ver ndernde Ziele aufgrund der Evolution Schon das Bestimmen und Errei chen fixierter Ziele bei der Entwicklung eines Produkts ist keine leichte Aufgabe Sich ver n dernde Ziele machen das Ganze noch um e
195. on der Originalklasse ber nehmen Man sagt auch eine Klasse vererbt ihre Merkmale an ihre Unterklassen Die M glich keit der Vererbung macht die Entw rfe au erordentlich flexibel und er ffnet neue M glichkeiten der Wiederverwendung Der Entwurf und die Realisierung einer Unterklasse erfordern in der Regel jedoch eine zumindest teilweise Kenntnis der inneren Struktur der Klasse von der abge leitet wird Information Hiding ist daher zwischen Ober und Unterklassen nur begrenzt m glich nn IT woe Pi Kontostand Bezug ohne Bezugmit _____ abgeleitet von Erl uterung Modelliert ist ein Ausschnitt aus einem Bancomat System Die m glichen Transaktionen sind als Unterklassen von TRANSAKTION modelliert Dies erlaubt die flexible Erweiterung der Software um weitere Transaktionsarten zum Beispiel berweisung t tigen TRANSAKTION benutzt KonTO f r Kontostandsabfragen und mutationen BEZUG MIT BELEG benutzt QuITTUNG zum Erstellen von Belegen Die Interaktion zwischen TRANSAKTION und ANZEIGE ist nach dem Beobachtermuster vgl Bild 6 7 konstruiert TRANSAKTION benachrichtigt ANZEIGE jedesmal wenn innerhalb von TRANSAKTION oder von einer ihrer Unterklassen eine Ver nderung stattgefunden hat welche die Anzeige beeinflusst ANZEIGE holt sich daraufhin die ben tigte Information ab und zeigt sie an Bild 6 4 Benutzung und Vererbung in einer objektorientierten Architektur Durch die Verwendung von zwei verschiedenen Koopera
196. on geht es darum Abweichungen von der gefor derten Qualit t der Spezifikation festzustellen Mit anderen Worten bei der Pr fung sollen m g lichst viele Fehler L cken Unklarheiten Mehrdeutigkeiten etc gefunden und anschlie end behoben werden Dabei haben nicht alle Qualit tsmerkmale das gleiche Gewicht In erster Priorit t sollte auf Ad quatheit Vollst ndigkeit Widerspruchsfreiheit und Verst ndlichkeit gepr ft werden in zweiter Priorit t auf Pr fbarkeit und Eindeutigkeit und in dritter Priorit t auf alle brigen Merk male Die Pr fung einer Spezifikation auf Ad quatheit Vollst ndigkeit und Widerspruchsfreiheit wird auch Validierung genannt 7 6 2 Beteiligte Die Pr fung erfolgt sinnvollerweise unter Federf hrung von Informatikern die insbesondere die verwendete Darstellung ohne fremde Hilfe interpretieren k nnen Zus tzlich m ssen aber die Vertreter des Kunden zwingend in den Pr fprozess einbezogen werden denn nur sie k nnen schlussendlich die Ad quatheit und Vollst ndigkeit der Spezifikation beurteilen 7 6 3 Zeitpunkt der Pr fung Die abschlie ende Pr fung einer Spezifikation erfolgt zu einem Zeitpunkt wo e die Spezifikation fertig ist e aber noch genug Zeit bleibt die gefundenen M ngel zu beheben Bei umfangreichen Spezifikationen sind zus tzlich Zwischenpr fungen begleitend zur Erstel lung der Spezifikation erforderlich 7 6 4 Pr fverfahren F r die Pr fung einer Anforderungsspezifik
197. orgaben stehen Unter Referenzunterlagen versteht man einerseits Unterlagen welche sachlich inhaltliche Vorgaben enthalten die der Pr fling erf llen muss und andererseits Standards und Pr flisten anhand derer die Pr fung durchgef hrt werden soll Reviews k nnen in jedem Stadium der Software Entwicklung eingesetzt werden In den fr hen Phasen der Entwicklung ist das Review das einzige Mittel f r eine fundierte berpr fung von Resultaten In der Codierung und Integration werden Reviews als zus tzliches Pr fmittel neben den Tests eingesetzt 9 4 1 2 Motivation Sorgf ltig durchgef hrte Reviews verbessern die Qualit t der erzeugten Software erheblich Fagan 1986 berichtet von zwei Projekten bei denen in den Code Reviews 82 bzw 93 aller Fehler entdeckt wurden und dies gemessen ber die gesamte Lebensdauer der jeweiligen Software Andere Quellen sprechen von Senkungen der Restfehlerraten Fehler pro 1000 Zeilen ausgeliefertem Code um bis zu zwei Drittel Solche Qualit tsverbesserungen schlagen nicht nur in h herer Kundenzufriedenheit zu Buche sondern reduzieren sowohl die Entwicklungskosten weniger Aufwand f r Test und Fehlerbehebung als auch die Pflegekosten 9 4 1 3 Positive Nebeneffekte Werden in einer Organisation regelm ig Reviews durchgef hrt so hat dies einen st ndigen Wissens und Kenntnistransfer von den besseren zu den schlechteren Leuten zur Folge Jeder Review Teilnehmer lernt aus den St rken und Sc
198. r stellung und Pflege von Software sind Prozesse Im nicht professionellen Bereich wird Software typischerweise nach einem ad hoc Prozess entwickelt und gepflegt Ein solcher Prozess hat folgende charakteristischen Merkmale Es gibt in der Regel nur vage Sachziele und keine Termin und Kostenvorgaben Spezifikationen werden keine Entw rfe nicht oder nur bruchst ckhaft gemacht Getestet wird nicht oder nur ansatz weise Qualit t ist kein Thema Die Entwicklung hat oft den Charakter des Probierens Die Pro dukte sind eher klein kurzlebig und nicht dokumentiert In der Regel handelt es sich um Einper sonenarbeit f r den Eigengebrauch Pflegema nahmen erfolgen spontan immer dann wenn mit der Software Probleme auftreten die sich nicht anders l sen lassen Im professionellen Bereich hat diese Art von Arbeit ausschlie lich bei experimentellen Ent wicklungen im Forschungsbereich sowie bei der Erstellung von Wegwerf Prototypen vgl Kapi tel 3 3 ihre Berechtigung Man findet sie jedoch leider h ufig auch in der sogenannten Endbe nutzer Entwicklung wo Leute f r ihren PC Software in dieser Art zusammenbasteln Wird Software als Produkt oder als Teil eines Produkts entwickelt so braucht es zwingend systematische d h geplante und gelenkte Prozesse sofern man keine Software Katastrophen will Die Abwicklung wird geplant es bestehen klare Termin Kosten und Sachziele Der Ab lauf des Prozesses wird berpr ft Mit Lenkungsma nahmen werden
199. r Kostenfunktion z B Anzahl Instruktionen m ssen einigerma en zu treffend gesch tzt werden e das Modell muss kalibriert werden d h der Wert der einzelnen Kostenattribute muss an die jeweilige Entwicklungsumgebung angepasst werden Eine solche Kalibrierung ist nur m glich wenn gen gend Messwerte von durchgef hrten Projekten vorliegen FESTSTELLUNG 5 3 Algorithmische Methoden liefern die besten Sch tzungen Sie k nnen aber nur nach entsprechenden Vorarbeiten Kalibrierung berhaupt eingesetzt werden Au erdem sind sie stark abh ngig von der Genauigkeit mit der die Eingangsgr en bestimmt werden k n nen garbage in garbage out Problem 5 4 Beispiele algorithmischer Sch tzverfahren Die zwei wichtigsten algorithmischen Sch tzverfahren COCOMO und Function Point wer den in den folgenden beiden Unterkapiteln vorgestellt 50 Martin Glinz Software Engineering I 5 4 1 COCOMO COCOMDO Constructive Cost Model ist das Kostensch tzverfahren von Boehm 1981 Es geht aus von einer Sch tzung der Produktgr e in KDSI Kilo lines of delivered source instructi ons Aus diesem Grundwert und einer Reihe von Kosten Multiplikatoren werden Kosten und Durchlaufzeit berechnet Die Grundgleichungen lauten 5 1 MM 2 4 KDSI MM man month 0 38 5 2 TDEV 2 5 MM TDEV time to develop 6000 400 300 Embedded mode 3 5000 200 ee 100 4000 rc 20 40 60 80 KDSI v 2 3000 g Semidetached mode 20
200. r Kunde will bzw braucht e Vollst ndigkeit alles beschreiben was der Kunde will bzw braucht e Widerspruchsfreiheit sonst ist die Spezifikation nicht realisierbar e Verst ndlichkeit f r den Kunden und f r die Informatiker e Eindeutigkeit damit Fehler durch Fehlinterpretationen vermieden werden e Pr fbarkeit damit feststellbar ist ob das realisierte System die Anforderungen erf llt Ein guter Spezifikationsprozess ist charakterisiert durch e Kundenorientierung e Methodisches und zielgerichtetes Vorgehen e Verwendung geeigneter Mittel e Integration von Erstellung und Pr fung von Anforderungen 7 2 Der Spezifikationsprozess Der Prozess des Spezifizierens von Anforderungen umfasst im Wesentlichen drei Aufgaben die Gewinnung die Darstellung und die Pr fung der Anforderungen Der Prozess kann jedoch nicht einfach sequentiell in drei entsprechende Schritte gegliedert werden Vielmehr muss der Prozess iterativ in enger und st ndiger Interaktion zwischen Vertretern des Kunden und den die Spezifikation erstellenden Informatikern Analytikern ablaufen Bild 7 3 Kunde Informatiker Analytiker Systembe Auftrag 7 Problem studieren d rfnis Informationsge Fragen winnung planen Fragen be ee Antworten Aussagen nforderungen nennen erg nzende pr zi Analysieren und sierende Fragen auswerten Pr fen durch Kar urn Br spielen rg nzungen icm Glossare Szenar
201. r Personen BILD 1 6 Wachstum und Quantenspr nge beim Kommunikationsbedarf 1 Einf hrung Software Entwicklung als Problem 7 FESTSTELLUNG 1 8 Software ist einer Evolution unterworfen vgl Kapitel 3 1 Die Umwelt und die Bed rfnisse der Benutzenden ver ndern sich st ndig Software die sich in Gebrauch befindet bleibt daher ohne st ndige Anpassungen und Erweiterungen nicht ge brauchstauglich Ferner werden im Betrieb auch immer wieder Fehler entdeckt die behoben werden m ssen Solche Entwicklungsarbeiten an in Betrieb befindlicher Software werden Pflege oder Wartung genannt Das Tempo der Software Evolution ist so hoch dass h ufig schon w hrend der Entwicklung die Entwicklungsziele an ver nderte Bed rfnisse angepasst werden m ssen Die erforderlichen Anpassungen und Erweiterungen bei der Pflege bringen es mit sich dass Umfang und innere Unordnung von in Gebrauch befindlicher Software st ndig zunehmen Die Pflege einer Software wird daher mit zunehmendem Alter immer schwieriger und teurer Dies ist ein Effekt den man auch in anderen Disziplinen beobachten kann Wird zum Beispiel ein Haus ber Jahrzehnte hinweg st ndig erweitert und umgebaut so wird es immer gr er und un ber sichtlicher Je planloser und je h ufiger an oder umgebaut wird desto schwieriger ist es den Bau so auszuf hren dass nicht Teile des Geb udes dabei einst rzen oder danach ihren Verwen dungszweck nicht mehr erf llen FESTSTELLUNG 1 9 S
202. rache bereitgestellt Interes sierte Leserinnen und Leser seien auf die Literatur ber Betriebssysteme verwiesen Informationsaustausch erfolgt entweder ber das Senden und Empfangen von Nachrichten oder ber Speicherbereiche die beiden kommunizierenden Prozessen zug nglich sind Nach richtenaustausch ist etwas langsamer daf r aber sicher und geographisch verteilbar Kommuni kation ber gemeinsame Speicher ist schnell muss daf r aber explizit gesichert werden und ist in der Regel nicht verteilbar Beispiel Ein Informatiksystem soll Devisenh ndler bei ihrer Arbeit unterst tzen Zu diesem Zweck sollen auf einer Arbeitsplatzstation folgende Komponenten verf gbar sein e ein Editor zur Bearbeitung und Anzeige der laufenden Kauf und Verkaufsauftr ge 64 Martin Glinz Software Engineering I ein Archivierer der alle abgewickelten Transaktionen registriert und bei Bedarf anzeigt e ein Telefonbutler der ein Telefonverzeichnis anzeigt bei Anwahl eines Eintrags die zugeh rige Person anruft sowie mehrere Linien gleichzeitig h lt und makelt e ein Kursbeobachter der die aktuellen Kurse und den Kursverlauf der gehandelten W hrungen fortlaufend ermittelt und anzeigt Alle vier Komponenten sollen gleichzeitig arbeiten k nnen und werden daher mit nebenl u figen Prozessen realisiert F r gemeinsame Infrastrukturaufgaben zum Beispiel Datenhaltung werden weitere Prozesse definiert 6 3 6 Ber cksichtigung der Ressourcen Eine zum
203. rementList Zuweisung neuer Listenzeiger temp wert element Zuweisung des einzuf genden Wertes J Weitere Methoden in diesem Beispiel weggelassen MeasurementList ausreisserEntfernen double referenzwert Erste Version in Modula 2 von Martin Glinz 1993 Reimplementiert in JAVA von Martin Arnold 6 12 1996 Letzte Version von Martin Glinz 18 12 1996 PRE Liste ist ordnungsgem ss verkettet Beim letzten Element ist der Zeiger naechstes null POST Die aktuelle Liste ist wie folgt modifiziert Alle Listenelemente deren Wert um mehr als TOLERANZ in Prozent kleiner als der Referenzwert ist sind aus der Liste entfernt Als Funktionswert wird das erste Listenelement Listenanker der bereinigten Liste zur ckgegeben MeasurementList temp this Referenz auf aktuellen Listenbeginn erstes Element Measuremenitlist vorgaenger new Measuremenilist Initialisierung eines Vorgaengerelements MeasurementList listenanker temp Listenanker erstes Listenelement Die Liste wird hier vollst ndig durchlaufen und s mtliche Elemente unterhalb der TOLERANZgrenze werden entfernt while temp naechstes null Liste durchlaufen bis zum letzten Eintrag if temp wert lt referenzwert 1 0 TOLERANZ Element unterhalb der TOLERANZgrenze if vorgaenger naechstes null aktuelles Element ist nicht erstes Listenelement Listenanker vorgaenger naechstes temp naechstes
204. reter der Autorenschaft nimmt aus zwei Gr nden an der Sitzung teil Erstens k nnen Unklarheiten und Missverst ndnisse unter Umst nden sofort gekl rt und mit einer entsprechenden Notiz im Review Bericht erledigt werden Zweitens m ssen die Autoren sp ter anhand des Review Berichts die festgestellten M ngel beheben Die richtige Interpretation 9 Qualit tsmanagement 121 der Befunde im Review Bericht f llt wesentlich leichter wenn ein Vertreter der Autorenschaft bei der Abfassung dieses Berichts dabei gewesen ist 9 4 3 5 Die Qualit tsverantwortung Die Review Teilnehmer sind verantwortlich f r die Qualit t des Reviews d h daf r dass ei nerseits schlechte Produkte als schlecht erkannt werden und m glichst alle M ngel im Review Bericht aufgef hrt sind und dass andererseits gute Produkte als gut erkannt und nicht mit ge suchten und nebens chlichen Schwachstellen belastet werden Sie sind jedoch nicht verantwortlich f r die Qualit t des Produkts Weder k nnen sie f r festgestellte Schw chen haftbar gemacht werden noch daf r dass festgestellte M ngel unter Umst nden nicht behoben werden Die Verantwortung f r die Qualit t eines Produkts muss bei der selben Person liegen wie die Verantwortung f r Sachziele Kosten und Termine Diese Person ist verantwortlich sowohl f r die Veranlassung der Reviews als auch f r die Veranlassung und Nachkontrolle der notwendigen Verbesserungen 9 4 4 Review Regeln e Das zu pr f
205. rganisatorische Gr nde Technisch muss wiederverwendbare Software zun chst einmal geschaffen werden Hierzu muss neu erstellte Software so gestaltet in Komponenten gegliedert und dokumentiert sein dass entsprechende Komponenten berhaupt herausgel st und in einem anderen Kontext sinnvoll wiederverwendet werden k nnen Im Bereich des Organisatorischen gibt es im Wesentlichen drei Probleme welche einer breiten Wiederverwendung von Software im Weg stehen e Wiederverwendbare Software ist in ihrer Herstellung aufwendiger als Einzweck Software weil sie allgemeing ltiger angelegt und ausf hrlicher dokumentiert werden muss F r jemanden der nur f r ein Projekt verantwortlich ist besteht daher kein Anreiz die f r das Projekt notwendige Software wiederverwendbar zu gestalten Wiederverwendbare Software muss deshalb explizit honoriert werden e Wiederverwendung scheitert h ufig daran dass Projektleiter oder Projektmitarbeiter nicht wis sen welche im Unternehmen vorhandene Software in ihrem Projekt wiederverwendet werden k nnte Es muss daher Kataloge wiederverwendbarer Software geben e Wiederverwendung scheitert h ufig daran dass die Urheber von potenziell Wiederverwend barem nicht bereit sind irgendwelche Garantien oder Pflegeverpflichtungen f r ihre Software zu bernehmen Wiederverwendung muss daher wie Beschaffung vertraglich geregelt werden Optimal f r die F rderung von Wiederverwendung w re es wenn es Unternehmen oder un
206. rogramms Ausgaben Erstellungs aufwand Anzahl Anweisungen Speicherbedarf Klarheit des Programms Klarheit der Ausgaben BILD 2 1 Leistungen von Programmierern in Abh ngigkeit von den vorgegebenen Zielen 1 beste Leistung 5 schlechteste Leistung 2 2 Klassifikation von Zielen In den meisten Software Projekten lassen sich die Ziele nach dem in Bild 2 2 gezeigten Schema ordnen Wesentlich ist die Untergliederung der Ziele in Projekt und Produktziele wo bei die Erreichung der Produktziele mit ein zentrales Projektziel ist Die Anforderungen an die bereitzustellende Software sind ein Teil der Zielsetzung Projekt Ziele Termine Kosten Sachziele Projekt Attribute Anforderungen an das Produkt nn Funktionale Anforderungen Attribute Leistungsanforderungen besondere Qualit ten Randbedingungen BILD 2 2 Klassifikationsschema f r Ziele 2 3 Zielverfolgung Zielsetzung ist notwendig f r ein systematisches Vorgehen aber nicht hinreichend Nach der Festlegung der Ziele muss systematisch auf das Erreichen der Ziele hingearbeitet werden Dabei gen gt ein einmaliges Fokussieren auf die Ziele zu Beginn nicht Langsame aber stetige Abwei chungen von den Zielen w hrend der Entwicklung k nnen dazu f hren dass Ziele massiv ver fehlt werden ohne dass dies rechtzeitig bemerkt wird Es braucht daher eine regelm ige Ziel 2 Zielsetzung Messung 15 kontrolle so dass bei Abweichungen geeig
207. rogrammst ck etc nach vorge gebenen Pr fkriterien und listen Ein Review hat zum Ziel sowohl die Schwachstellen und M ngel wie auch die St rken des gepr ften Produkts aufzuzeigen und damit dessen Qualit t festzustellen Man unterscheidet zwei Formen von Reviews Inspektionen und Walkthroughs 118 Martin Glinz Software Engineering I Eine Inspektion ist ein Review bei dem der Pr fling von den Gutachtern systematisch Punkt f r Punkt auf St rken und Schw chen abgeklopft wird Ein Walkthrough ist ein Review bei dem der Autor oder die Autorin die Funktionsweise des Pr flings Schritt f r Schritt beschreibt w hrend die Gutachter aufmerksam zuh ren und berall einhaken wo sie M ngel entdecken In der Regel werden Reviews als Inspektionen durchgef hrt Dementsprechend gelten die Ausf hrungen in den folgenden Kapiteln prim r f r Inspektionen Sie lassen sich sinngem aber auch auf Walkthroughs anwenden Walkthroughs sind dann sinnvoll wenn das Urteil von Gutachtern gefragt ist welche das zu pr fende Produkt oder die Sprache in der es formuliert ist nicht so gut kennen dass sie es ohne F hrung inspizieren k nnen Neben dem zu pr fenden Material braucht es f r ein Review sogenannte Referenzunterlagen In einem Code Review kann beispielsweise die inhaltliche Richtigkeit von Algorithmen und Datenstrukturen nur gepr ft werden wenn als Referenz ein Konzept oder Entwurfsdokument vorhanden ist in welchem entsprechende V
208. rolle immer den bedienenden Menschen e Materialien sind passiv und oder speichernd Sie werden bearbeitet und k nnen sowohl Arbeitsgegenstand als auch Arbeitsergebnis sein e Automaten sind aktiv Sie erledigen Aufgaben vollautomatisch und ohne menschliches Zutun 80 Martin Glinz Software Engineering I Die WAM Metapher eignet sich insbesondere f r die Architektur von Assistenzsystemen d h Systemen welche kreative menschliche Arbeit zum Beispiel Beratungs oder Entwurfs t tigkeiten unterst tzen Materialien sichert einmal t glich alle bearbeiteten Doku mente Bild 6 9 Die WAM Werkzeug Automat Material Metapher 6 8 2 Weitere Architekturmetaphern e Die Organisationshierarchie Die Architektur wird analog zur Organisationshierarchie in einem Unternehmen strukturiert mit Delegation von Aufgaben und Verantwortung von oben nach unten und Berichten von unten nach oben e Die virtuellen Maschinen Die Architektur ist als eine Menge aufeinander aufbauender Schichten von virtuellen d h k nstlichen Maschinen aufgebaut Die Maschinen jeder Schicht bieten Leistungen f r die dar berliegende Schicht an und benutzen dazu die Maschinen der darunterliegenden Schicht Kommunikationsarchitekturen sind meistens nach dieser Metapher konstruiert e Das Steckersystem Die Architektur wird in Analogie zu technischen Steckersystemen auf gebaut In einen Grundrahmen welcher typisch Kommunikations Dialog und Datenverwal tungsdienst
209. ruktur Dritter Bild 7 15 b durch Delegieren von Aufgaben und Anordnung der Aufgaben in Schichten bersichtlich und anschaulich modellieren Die Generalisierung fasst die Gemeinsamkeiten einer Menge hnlicher Komponenten zu einer bergeordneten Komponente zusammen Dies hilft z B bei der Strukturierung der Be griffswelt Zusammenfassung von Begriffen zu Oberbegriffen und erlaubt die Modellierung aufgabengerechter Modelle Bild 7 16 Anlagen element Schalter Abzweig punkt Sammel Leitungs Bild 7 16 Generalisierungsabstraktion Problemgerechte Modellierung der Begriffswelt der Realit t am Beispiel des Engineerings von Unterstationen in Stromverteilungsnetzen Transformator 7 5 4 Ausgew hlte Spezifikationsmethoden 7 5 4 1 Spezifikation mit nat rlicher Sprache Es gibt keine speziellen Methoden f r Spezifikationen mit nat rlicher Sprache In der Regel sind die Anforderungen nummeriert Ferner werden h ufig feste Gliederungschemata verwendet Bild 7 10 zeigt ein Beispiel 7 Spezifikation von Anforderungen 97 7 5 4 2 Algebraische Spezifikation Algebraische Spezifikation ist eine deskriptive formale Spezifikationsmethode Sie wird vor allem f r die formale Spezifikation komplexer Datentypen verwendet Die Grundidee dabei ist die Wirkung von Operationen auf den Objekten eines Typs durch die Angabe von Axiomen Ausdr cken die immer wahr sein m ssen festzulegen Die Syntax des zu
210. s Bei der Modularisierung kommt es wesentlich darauf an dass nicht irgendwie zerlegt wird sondern so dass die Module in sich geschlossene Teill sungen mit m glichst wenigen wohlde finierten Interaktionen zu anderen Modulen bilden Wir verlangen von einer guten Modularisie rung dass sie folgendes leistet e Jeder Modul ist eine in sich geschlossene Einheit e die Verwendung des Moduls erfordert keine Kenntnisse ber seinen inneren Aufbau 6 Konzipieren von L sungen 61 e die Kommunikation eines Moduls mit seiner Umgebung erfolgt ausschlie lich ber eine klar definierte Schnittstelle nderungen im Inneren eines Moduls welche seine Schnittstelle unver ndert lassen haben keine R ckwirkungen auf das brige System e die Korrektheit des Moduls ist ohne Kenntnis seiner Einbettung ins Gesamtsystem nachpr f bar Die G te einer Modularisierung l sst sich im Wesentlichen an folgenden drei Kriterien mes sen den Ma en Koh sion und Kopplung Stevens Myers und Constantine 1974 sowie der ge eigneten Ber cksichtigung von Ressourcen vgl Abschnitt 6 3 6 DEFINITION 6 5 Koh sion cohesion Ein Ma f r die St rke des inneren Zusammenhangs eines Moduls Je h her die Koh sion ist desto besser Module mit zuf lliger Koh sion bunt zusammengew rfelte Teile oder zeitlicher Koh sion zusammengefasst ist was zeitlich miteinander auszuf hren ist sind softwaretechnisch schlecht und sollten vermieden werden Anzustreben
211. s oder zur Erreichung eines Ziels ben tigt wird 2 Eine Bedingung oder F higkeit die eine Software erf llen oder besitzen mu um einen Vertrag eine Norm oder ein anderes formell bestimmtes Dokument zu erf llen IEEE 610 12 1990 DEFINITION 7 2 Anforderungsspezifikation Die Zusammenstellung aller Anforderungen an eine Software Synonyme Anforderungsdokument Software Requirements Specification Im Alltag ist die Sprechweise nicht immer ganz eindeutig mit die Spezifikation ist h ufig je nach Kontext das resultierende Dokument oder der Spezifikationsprozess das hei t der Pro zess des Erfassens Beschreibens und Pr fens von Anforderungen gemeint Werden die Aufgaben im Bereich der Spezifikation und des Spezifizierens systematisch und gezielt angegangen spricht man auch von Requirements Engineering Anforderungstechnik In Definition 7 3 geben wir zwei m gliche Definitionen eine mehr technische welche sich an die Definition von Software Engineering in IEEE 610 12 1990 anlehnt und eine mehr menschen orientierte hnlich derjenigen von Gause und Weinberg 1989 DEFINITION 7 3 Requirements Engineering Anforderungstechnik 1 Das systematische diszi plinierte und quantitativ erfassbare Vorgehen beim Spezifizieren d h Erfassen Beschreiben und Pr fen von Anforderungen an Software 2 Verstehen und Beschreiben was die Kunden w nschen oder brauchen Im deutschen Sprachraum ist im Zusammenhang mit Anforderungen auch d
212. s symbolische Konstanten mit einem selbsterkl renden Namen zu vereinbaren Jede Prozedur hat einen Kommentarkopf in dem die Aufgabe der Prozedur sowie die Bedeutung der Prozedurparameter erkl rt sind 4 Auszug aus der Pr fliste f r Codeinspektionen bereinstimmung des Codes mit Entwurfsdokument Schnittstelle Datenstrukturen ad quat Algorithmen richtig effizient geforderte Ein Ausgaben vorhanden alle verwendeten Variablen initialisiert Schleifen Verhalten am Anfang Verhalten am Ende terminiert die Schleife sicher Weist die Schleife illegale Durchl ufe ab Hat es schleifeninvarianten Code in der Schleife falls Laufvariablen vorhanden Laufvariable initialisiert Fortschaltung der Laufvariablen vorhanden und richtig Ausgabe Zeilenende mit Zeilenfortschaltbefehl abgeschlossen tabellarisch aufgebaute Ausgaben sauber untereinander 10 Dokumentation 131 10 Dokumentation 10 1 Grunds tze der Dokumentation Bei der Entwicklung von Software entsteht kein materielles Produkt Alle Entwicklungs t tigkeiten manifestieren sich letztlich nur in Form von Dokumenten im weitesten Sinn auch Programmcode ist ein Dokument Den Dokumenten kommt daher in der Software Entwicklung eine besondere Bedeutung zu 10 1 1 Dokumentationsarten Es gibt zwei Arten von Dokumentation bei der Software Erstellung e Die Produktdokumentation dokumentiert ein Software Produkt und seine Benutzung e Di
213. sen der Entwicklung absinkt und daf r in den sp ten Phasen sowie in der Nutzung steigt Ferner darf eine Verbesserung der Produktqualit t erwartet werden Nutzen mit Dokumen tation ohne Zeit Entwicklung l Betrieb Wartung Kosten Bild 10 1 Wirtschaftlichkeit eines Software Systems mit und ohne Dokumentation Dokumentation ist nicht Selbstzweck Es darf daher nur soviel wie unbedingt notwendig dokumentiert werden dies aber sorgf ltig und konsequent Au erdem ist das notwendige Mini mum schon recht viel In der Regel wird nicht zuviel sondern zuwenig dokumentiert 10 2 Produktdokumente Die Produktdokumentation muss folgende Aspekte eines Systems dokumentieren e die Anforderungen an das System e das Konzept der L sung e die Einzelheiten der L sung Entw rfe und Realisierungen e die Montage der einzelnen Komponenten Integration und Installation 10 Dokumentation 133 e die Planung von Tests und der Abnahme e die Handhabung des Systems Benutzerdokumentation Die Anforderungsspezifikation legt pr zise detailliert und soweit wie m glich nachpr fbar fest was von dem zu entwickelnden System verlangt wird Das L sungskonzept beschreibt die Architektur der L sung Dies umfasst insbesondere die Gliederung der L sung in Komponenten Teilsysteme Aufteilung in Prozesse Modulari sierung die Kommunikation zwischen diesen Komponenten die Verteilung auf Software und Hardware sowie die Verteilung der Softwar
214. ser Fairley R 1985 Software Engineering Concepts New York etc McGrawHill Glinz M 1988 Emotionales und Rationales im industriellen Software Engineering Techni sche Rundschau 20 88 78 81 Glinz M 1990 Warte nicht auf besere Zeiten Methoden und Werkzeuge in der Software Entwicklung Technische Rundschau 35 90 70 75 IEEE 1992 Themenheft Tools Assesment IEEE Software 9 3 May 1992 Ludewig J 1991 Software Engineering und CASE Begriffskl rung und Standortbestim mung it Informationstechnik 33 3 112 120 Sackman H et al 1968 Exploratory Experimental Studies Comparing Online and Offline Programming Performance Communications of the ACM 11 1 Jan 1968 Weinberg G M 1971 The Psychology of Computer Programming New York Van Nostrand Reinhold Kommentiertes Literaturverzeichnis 147 Kommenitiertes Literaturverzeichnis von Lehrb chern und wichtigen Zeitschriften Artikeln ber Software Engineering Balzert H 1996 Lehrbuch der Software Technik Software Entwicklung Heidelberg Spekt rum Akademischer Verlag 1009 p CD ROM Balzert H 1998 Lehrbuch der Software Technik Software Management Software Qualit ts sicherung Unternehmensmodellierung 769 p CD ROM Enzyklop dische F lle von Material Pr sentation berladen mit Details Konzepte Zusammenh nge und die Bedeutung der einzelnen Themen fehlen oder gehen unter Behandelt auch viele nicht zum Kern des Software E
215. setzt werden sollten sind daher zwar formalisiert d h folgen einem formellen Verfahrensprozedere aber nicht im mathematischen Sinn formal 9 3 2 Pr fverfahren Vier Pr fverfahren sind von praktischer Bedeutung das Review der Test die Simulation und der Prototyp Ein Review ist eine formell organisierte berpr fung eines Arbeitsergebnisses durch eine Gruppe von Gutachtern Trotz nachgewiesener gro er Wirksamkeit werden Reviews heute immer noch viel zu wenig eingesetzt In Kapitel 9 4 ist daher die Reviewtechnik genauer erl utert Ein Test ist die berpr fung eines Programms ob dieses bei gegebenen Eingaben die erwar teten Resultate liefert Nach dem heutigen Stand der Technik ist qualitativ hochwertige Software nur mit systematischem Testen vgl Kapitel 8 3 erstellbar In einer Simulation wird ein bestimmter Aspekt eines Systems modelliert und in seinem Verhalten berpr ft Simulationen dienen vor allem dazu die Erreichung von Leistungsanforde rungen zu berpr fen Ein Prototyp ist eine Vorab Realisierung eines kritischen Systemteils Er dient vor allem dazu Anforderungen zu validieren und Konzepte auf Machbarkeit bzw Einhaltung der Leis tungsanforderungen zu berpr fen vgl Kapitel 3 und 4 9 4 Reviewtechnik 9 4 1 Grundlagen 9 4 1 1 Definition Ziele Definition 9 6 Review Eine formell organisierte Zusammenkunft von Personen zur inhaltlichen oder formellen berpr fung eines Produktteils Dokument P
216. sie in der Produktion ben tigt werden Dies schafft streng termingebundenen Lastwagenverkehr als neue Realit t und softwaregest tzte Optimierung solchen Verkehrs als neues Bed rfnis 1 2 Software Entwicklung 1 2 1 Definition Software Entwicklung umfasst alle T tigkeiten und Ressourcen die zur Herstellung von Software notwendig sind DEFINITION 1 2 Software Entwicklung Die Umsetzung der Bed rfnisse von Benutzern in Soft ware Umfasst Spezifikation der Anforderungen Konzept der L sung Entwurf und Program mierung der Komponenten Zusammensetzung der Komponenten und ihre Einbindung in vorhandene Software Inbetriebnahme der Software sowie berpr fung des Entwickelten nach jedem Schritt 1 2 2 Einige grundlegende Gesetzm igkeiten In diesem Abschnitt zeigen wir einige grundlegende Gesetzm igkeiten f r die Entwicklung von Software die wesentlich dazu beitragen dass Software Entwicklung etwas Schwieriges ist FESTSTELLUNG 1 7 Die Entwicklung von Klein Software unterscheidet sich fundamental von der Entwicklung gr erer Software Letzteres stellt dabei den Normalfall dar Tabelle 1 1 charakterisiert die Unterschiede Viele Probleme existieren f r Klein Software gar nicht Die Erfahrung dass die Entwicklung kleiner Programme recht einfach ist ist der Hauptgrund f r den Trugschluss vieler Leute dass Software Entwicklung generell etwas Einfaches sein m sse REGEL 1 1 Der Aufwand f r die Erstellung von Software
217. spezifizierenden Datentyps wird durch Angabe von Definitions und Wertebereichen festgelegt Das nachfolgen de Beispiel Bild 7 17 zeigt die algebraische Spezifikation eines Stacks Keller oder Stapel speicher bei dem immer das zuletzt gespeicherte Element wieder entnommen werden kann Sei bool der Datentyp mit dem Wertebereich false true und der Booleschen Algebra als Operationen Sei ferner elem der Datentyp f r die Datenelemente die im spezifizierten Stack zu speichern sind TYPE Stack FUNCTIONS new gt Stack neuen leeren Stack anlegen push Stack elem gt Stack Element hinzuf gen pop Stack gt Stack zuletzt hinzugef gtes Element entfernen top Stack gt elem liefert zuletzt hinzugef gtes Element empty Stack gt bool wahr wenn Stack kein Element enth lt full Stack gt bool wahr wenn Stack voll ist AXIOMS v s e Stack e e elem 1 full s gt pop push s e s Pop hebt den Effekt von Push auf 2 full s gt top push s e e Top liefert das zuletzt gespeicherte Element 3 empty new true ein neuer Stack ist leer 4 full s gt empty push s e false nach Push ist ein Stack nicht mehr leer 5 full new false ein neuer Stack ist nicht voll 6 emtpy s full pop s false nach Pop ist ein Stack niemals voll Bild 7 17 Algebraische Spezifikation eines Stacks 7 5 4 3 Datenflussorientierte Spezifikation Strukturi
218. ss in einer Phase Probleme in den Vorgaben d h den Ergebnissen der vor angegangenen Phase auftreten k nnen Es sind daher lokale Iterationen zwischen aufeinander folgenden Phasen vorgesehen um solche Probleme zu beheben 3 Der Software Prozess 23 System feasibility Validation Software plans and requirements Validation Product design a Detailed design Verification 3 Integration Product verification Implementation a Operations and maintenance DEFINITION 3 5 Wasserfall Modell Ein Modell f r den Software Entwicklungsprozess wel ches die Entwicklung in eine Sequenz von Entwicklungs und Pr faktivit ten unterteilt Die Rei henfolge der Entwicklungsaktivit ten folgt dem Software Lebenslauf Quelle Boehm 1981 BILD 3 2 Das Wasserfall Modell Es gibt eine gro e Zahl von Varianten des urspr nglichen Wasserfall Modells welche sich meist geringf gig in Benennung und Reihenfolge der Phasen unterscheiden Allen diesen Modellen ist jedoch gemeinsam dass die Unterteilung der Entwicklung in Phasen nach einer linearen Reihenfolge von T tigkeiten erfolgt Aufgrund der Software Evolution und aufgrund der Tatsache dass die erkannten Fehler nicht immer nur in der gegenw rtigen und der vorangegangenen Phase gemacht wurden sind bei der Anwendung des Wasserfall Modells h ufig Iterationen ber mehrere Phasen hinweg erforderlich Bild 3 3 Dies erschwert die Projektf hrung und hat dem Wasserfall Mo
219. statistisch bestimmbaren Tendenzen und Invarianzen REGEL 3 4 Gesetz der Invarianz des Arbeitsaufwands Global betrachtet ist der Aufwand der in die Pflege eines Programms gesteckt wird w hrend der ganzen Lebenszeit des Programms stati stisch konstant REGEL 3 5 Gesetz der Invarianz des Release Inhalts Der Inhalt der Releases nderungen Er g nzungen Weglassungen ist ber die Folge aller Releases w hrend der Lebenszeit eines Pro gramms statistisch Konstant REGEL 3 6 Gesetz des kontinuierlichen Wachstums Ein Programm muss w hrend seiner ge samten Lebenszeit kontinuierlich wachsen wenn es gebrauchstauglich bleiben soll Number of Modules TE HE RD DE N BE ER EN 2000 3000 4000 Days Quelle Lehman und Belady 1985 p 307 BILD 3 7 Wachstum des Betriebssystems OS 360 370 von IBM ol O 500 1000 W hrend die Mechanismen die zu den Regeln 3 1 3 2 und 3 6 f hren intuitiv klar sind sind die Regeln 3 3 bis 3 5 eher kontra intuitiv Intuitiv w rde man erwarten dass der Pflegeprozess durch einschl gige Management Entscheidungen nachhaltig beeinflussbar ist Die von Lehman und Belady f r mehrere gro en Systeme erhobenen Zahlen belegen jedoch das Gegenteil Das Wachstum folgt klar einer mathematischen Kurve Bild 3 7 die kumulierte Anzahl ge nderter Module folgt einer Geraden d h die nderungsrate ist konstant Bild 3 8 a und die Anzahl der pro Tag ge nderten Module aufgezeichnet ber der Folge der
220. steigt mit wachsender Produktgr e berproportional an Nach Boehm 1981 wird der Zusammenhang beschrieben durch eine Gleichung der Art A bpP Dabei ist A der Aufwand P die Gr e der Software b ein konstanter Faktor und m ein Ex ponent im Bereich zwischen 1 05 und 1 2 Die Regel 1 1 ist eine der wenigen welche empirisch erh rtet sind vgl Boehm 1981 und Kapitel 5 1 Dabei wird unter Programmieren sowohl das Schreiben neuer Programme wie auch das Erweitern oder Modifizieren vorhandener Programme verstanden 6 Martin Glinz Software Engineering I Ursachen f r dieses berproportionale Wachstum sind unter anderem dass der Aufwand zur Beherrschung der wachsenden Komplexit t und der Kommunikationsaufwand berproportional wachsen Das Wachstum einzelner Faktoren ist dabei nicht kontinuierlich sondern weist Quan tenspr nge auf Bild 1 6 TABELLE 1 1 Klein Gro Gegens tze in der Software Entwicklung klein gro Programme von 1 bis ca 300 Zeilen L nge L ngere Programme F r den Eigengebrauch F r den Gebrauch durch Dritte Vage Zielsetzung gen gt das Produkt ist seine Genaue Zielbestimmung d h die Spezifikation von eigene Spezifikation Anforderungen erforderlich Ein Schritt vom Problem zur L sung gen gt die Mehrere Schritte vom Problem zur L sung er L sung wird direkt programmiert forderlich Spezifikation der Anforderungen Kon zept der L sung Entwurf der Teile Program miere
221. stems Als Alternative oder als Erg nzung zu Klassenmodellen k nnen Objektmodelle verwendet werden In solchen Modellen werden keine konkreten Objekte d h solche mit bekannter Identi t t und bekannten Attributwerten modelliert sondern abstrakte Objekte die als Muster bzw als Repr sentanten f r konkrete Objekte stehen In den meisten heute verwendeten Ans tzen werden Objektmodelle entweder gar nicht verwendet oder sie dienen in Erg nzung zu einem Klassen modell zur Modellierung des Arbeitskontextes der Objekte einer Klasse Objektmodelle anstelle von Klassenmodellen haben gro e Vorteile wenn verschiedene Objekte der gleichen Klasse zu modellieren sind und wenn ein Modell hierarchisch in Komponenten zerlegt werden soll Dagegen ist die Modellierung von Assoziationen und Vererbungsbeziehungen in Objekt modellen umst ndlicher als in Klassenmodellen Bild 7 22 zeigt eine Situation in der ein Objektmodell einem Klassenmodell in der Ausdruckskraft berlegen ist In manchen Klassenmodellen so auch in UML behilft man sich 102 Martin Glinz Software Engineering I indem die Beziehung zus tzlich mit den Rollen welche die in Beziehung gesetzten Objekte spielen d h hier TUTOR und ERSTSEMESTER beschriftet werden lt wird betreut von Tutor gt betreut Erstsemester Student gt sun Student lt wird betreut von Student Klassenmodell Objektmodell gt betreut Bild 7 22 Klassenmodell vs Objektmodell 7 5 4
222. t nde in einem Projekt k nnen nur langsam auf oder abgebaut werden Es ist nicht ohne Schaden m glich kurzfristig massive Ver nderungen im Personalbestand eines Projekts vorzunehmen e Zu einem gegebenen Entwicklungsaufwand gibt es eine optimale Gruppengr e f r die Bear beitung und damit eine optimale Durchlaufzeit Die Rechnung die Durchlaufzeit durch den Einsatz von mehr Entwicklern zu verk rzen geht nur in sehr engen Grenzen auf e Das Aufstocken des Personalbestands in einem versp teten Projekt f hrt zu noch mehr Versp tung Gesetz von Brooks Brooks 1995 Arbeitsverteilung Software Entwickler schreiben nicht nur Programme Eine Studie der Bell Labs ergab dass der im Hinblick auf Codeerzeugung produktive Anteil an der Arbeit eines Programmierers nur 13 betr gt Bild 10 1 Programme schreiben 13 Programme und Handb cher lesen 16 Arbeitsbezogene Kommunikation 32 Pers nliches 13 Ausbildung 6 Post 5 Diverses 15 Studie der Bell Labs 1964 zitiert aus Fairley 1985 Bild 12 2 Verteilung der Arbeitszeit eines Programmierers Gruppengr e Jede Entwicklergruppe ben tigt einen Teil ihrer Zeit f r Organisation und Kommunikation innerhalb der Gruppe Mit zunehmender Personenzahl nimmt dieser nicht produktive Aufwand berproportional zu vgl dazu Bild 1 6 12 Produktivit tsfaktoren 145 12 3 2 Emotionales und Rationales in der Software Entwicklung Emotionale Einstellungen der an Software
223. t solche Vermutungen durch Experimente und statistische Verfahren zu untermauern Auf diese Weise gewinnen wir Gesetze zum Beispiel das Gravitationsgesetz oder das Hebelgesetz in der Physik Solche Gesetzm igkeiten kennen wir auch f r Software Im Gegensatz zu den Gesetzen der Naturwissenschaften sind die Software Gesetzm igkeiten jedoch nur ansatzweise quantitativ gefasst und statistisch abgesichert Wir sprechen daher im Folgenden von Feststellungen wenn wir sichere oder empirisch erh rtete Beobachtungen beschreiben und von Regeln wenn wir entsprechende Zusammenh nge von Ph nomenen beschreiben 1 Einf hrung Software Entwicklung als Problem 3 Aufwands f r die Entwicklung von Software allzuoft nur auf die Programme abgestellt Dadurch wird der tats chliche Aufwand um ein Vielfaches untersch tzt BILD 1 3 So wie ein Auto wesentlich mehr ist als nur ein fahrbarer Untersatz so umfasst Software Relativer Anteil am Gesamtaufwand ber die gesamte Lebensdauer wesentlich mehr als nur Programme Spezifikation Detailent Test Anpassung Erweiterung Fehlerbe und Architek wurf und Verbesse hebung turentwurf Codierung rung A m I aua Entwicklung Pflege Wartung nach Boehm 1981 BILD 1 4 Verteilung des Aufwands ber die Lebensdauer eines Software Produkts FESTSTELLUNG 1 2 Software ist ein immaterielles technisches Produkt Man kann Software nicht anfassen Die Konsequenzen dieser trivial scheinenden Festst
224. tandardreferenz f r COCOMO IFPUG 1994 enth lt detaillierte Z hlregeln f r Function Points und illustriert diese anhand von Beispielen Kn ll und Busse 1991 beschreiben verschiedene in der Praxis eingesetzte Verfahren u a auch COCOMO und Function Points Wellman 1992 und Jones 1998 sind Monographien ber Software Kosten letztere pr sentiert den Stand der Technik in umfassender Weise Zitierte Literatur Abdel Hamid T K S E Madnick 1986 Impact of Schedule Estimation on Software Project Behavior IEEE Software 3 4 July 1986 70 75 Albrecht A J 1979 Measuring Application Development Productivity Proceedings Guide Share Application Development Symposium Oct 1979 83 92 Boehm B 1981 Software Engineering Economics Englewood Cliffs N J Prentice Hall IBM 1983 Die Function Point Methode Eine Sch tzmethode f r IS Anwendungs Projekte Brosch re GE 12 1618 0 IBM Deutschland GmbH IFPUG 1994 Function Point Counting Practices Manual Release 4 0 International Function Point Users Group Westerville Ohio USA Jones T C 1995 Backfiring Converting Lines of Code to Function Points IEEE Computer 28 11 Nov 1995 87 88 Jones T C 1996 Software Estimating Rules of Thumb JEEE Computer 29 3 March 1996 116 118 Jones T C 1998 Estimating Software Costs New York McGraw Hill Kn ll H D J Busse 1991 Aufwandsch tzung von Software Projekten in der Praxis Reihe
225. tatdaten und den gelieferten Eingabedaten dargestellt t x fm X Bild 7 6 Deskriptive Beschreibung von Anforderungen 90 Martin Glinz Software Engineering I Beispiele e Darstellung mit Text in nat rlicher Sprache Die Funktion Kontostand liefert den aktuellen Stand des Kontos f r die eingegebene Konto nummer Darstellung in einer formalen Notation Sqrt Real gt Real Pre x 2 0 Post ISqrt x x lt a lt 10 16 lt 10 Eine deskriptive Darstellung hat gewichtige Vorteile Die Beschreibung beschr nkt sich auf das u ere Verhalten das hei t wie das System mit sei ner Umgebung interagiert das ist es worauf es eigentlich ankommt Die Darstellung ist v llig l sungsneutral Diesen Vorteilen stehen jedoch ebenso gewichtige Nachteile gegen ber Eine deskriptive Beschreibung real gro er Systeme mit Text ist sehr umfangreich und wenig strukturiert Die Zusammenh nge zwischen verschiedenen Anforderungen sind oft nicht er kennbar oder gar nicht dargestellt Eine solche Darstellung ist daher fehlertr chtig und schwie rig zu pr fen Eine deskriptive Beschreibung real gro er Systeme mit formalen Mitteln ist sehr schwierig und erfordert bestens ausgebildete Spezialisten Die Pr fung einer solchen Darstellung auf ihre Ad quatheit stellt in vielen F llen ein fast un berwindbares Hindernis dar weil die Vertreter des Kunden die Darstellung weder verstehen noch nachvollziehen k nnen
226. temarchitektur software architecture system architecture 1998 1999 by Martin Glinz Alle Rechte vorbehalten Reproduktion zum nicht kommerziellen Gebrauch mit Quellenangabe gestattet Reproduktion auch auszugsweise zum kommerziellen Gebrauch nur mit schriftlicher Bewilligung des Verfassers gestattet 60 Martin Glinz Software Engineering I Hinweis Wenn von System die Rede ist Kann sowohl die zu erstellende Software als auch die technische bzw organisatorische Umgebung in welche die Software eingebettet ist gemeint sein Die Unterscheidung ergibt sich aus dem Kontext oder durch explizites R ckfragen In die sem Kapitel meint System immer die zu erstellende Software sofern nicht ausdr cklich etwas anderes gesagt wird 6 3 Entwurfsprinzipien 6 3 1 Strukturen und Abstraktionen Ein systematischer Aufbau ist die Grundlage jedes guten Entwurfs Die Systematik besteht in der Wahl bzw Verwendung geeigneter Strukturen und Abstraktionen Die Strukturen gliedern das L sungskonzept in Komponenten Module Prozesse externe Akteure und Interaktionen zwischen Komponenten Aufrufe Beziehungen Nachrichten Die Abstraktionen unterst tzen das Verstehen des Konzepts durch systematische Vergr berung und Verfeinerung der Darstel lung nach verschiedenen Kriterien Sie erm glichen dabei e das Sichtbarmachen gro er Zusammenh nge unter Weglassung der Details e die Darstellung eines Details unter Weglassung starker Vergr beru
227. ten der mittlere Zeitbedarf pro Function Point bestimmt so bekommt man ein Produktivit tsma Das Function Point Verfahren wurde von Albrecht 1979 bei IBM entwickelt und seither von verschiedenen Autoren bzw Gremien erg nzt und weiterentwickelt Seibt 1987 Symons 1988 IFPUG 1994 Das Verfahren basiert auf der Idee die folgenden Gr en eines Software Systems in geeigneter Weise zu z hlen und zu bewerten in Klammern die Terminologie von Albrecht e Dateneingaben External input e Datenausgaben External output e Anfragen External inquiry e Schnittstellen zu externen Datenbest nden External interface file e Interne Datenbest nde Logical internal file Dateneingaben Datenausgaben und Anfragen werden an Hand der logischen Transaktionen die das untersuchte System ausf hren soll gez hlt Tauchen die gleichen Eingabe bzw Ausga 52 Martin Glinz Software Engineering I bedaten in verschiedenen Transaktionen mit unterschiedlicher Verarbeitungslogik auf werden sie mehrmals gez hlt Bei den Datenbest nden werden logische Dateien bzw logische Daten gruppen Entit tstypen Relationen in Datenbanken gez hlt Die Werte k nnen alle bereits in der Anforderungsspezifikation gez hlt werden sofern diese hinreichend vollst ndig und detail liert ist Jede Dateneingabe Datenausgabe Anfrage etc wird als einfach mittel oder komplex bewertet und mit einem entsprechenden Gewicht versehen Tabelle 5 1 zei
228. theit und Vollst ndigkeit in der Regel so aufwendig dass die Kosten im Vergleich zum Nutzen zu hoch sind Wiederum geht die Wirtschaftlichkeitsrechnung nicht auf Teilformale Darstellungen weisen heute das beste Kosten Nutzen Verh ltnis auf Dies gilt ins besondere dann wenn nicht alle Teile der Spezifikation den gleichen Grad der Formalisierung aufweisen m ssen sondern der Formalit tsgrad dem Entwicklungsrisiko das mit den einzel nen Komponenten verbunden ist angepasst werden kann Teilformale Spezifikationen sind da her heute in den meisten F llen das Mittel der Wahl Beispiel Ausschnitte aus der Spezifikation der Steuerung eines Getr nkeautomaten Der Bediener dr ckt eine Wahltaste und bezahlt den Unklarheit Reihenfolge von Auswahl und geforderten Betrag Sobald die Summe der eingeworfenen Bezahlung M nzen den geforderten Betrag bersteigt wird das Ge Fehler Was ist bei Betragsgleichheit tr nk zubereitet und ausgegeben Ferner wird das Wechsel geld berechnet und ausgegeben Der Bedienvorgang endet wenn das Getr nk entnommen wird und wenn die Bedie Mehrdeutigkeit Ist und oder oder gemeint nung f r l nger als 45s unterbrochen wird Mit einer Annul R liertaste kann der Bedienvorgang jederzeit abgebrochen Unklarheit Abbruch w hrend der Ausgabe des werden Bereits eingeworfenes Geld wird beim Dr cken der Getr nks Annulliertaste zur ckgegeben Nach dem Dr cken einer Wahltaste kann entweder bezahlt o
229. tiert kein neues g wie es ist Review erforderlich a kleine nderungen a nicht akzeptiert neues a gro e nderungen Review erforderlich a berarbeitung a Review nicht beendet Review Team Name Funktion Vorberei Unterschrift tungszeit Freigabe nach Nachkontrolle Name Datum Unterschrift 9 Qualit tsmanagement 127 Review Nr Liste der Befunde Review Bericht Seite im zu pr fenden Produkt in den Referenzunterlagen von Nr Ort Befund Ge wicht Gewicht Kritischer Wichtiger Nebens chlicher Befund Gut 128 Martin Glinz Software Engineering I Anhang 2 Unterlagen f r die Codeinspektion aus Aufgabe 9 3 1 Zu inspizierendes Codest ck in Modula 2 PROCEDURE KennlinieTabellieren b REAL e REAL d REAL Tabelliert di verlangte Funktion im Bereich von b bis e VAR lfd REAL laufender x Wert f r Fkt Berechnung FktWert REAL berechneter Funktionswert BEGIN Titel schreiben Werte initialisieren WriteString x F x 2x 2 e x 2 3 WriteLn lfd b Tabellierschleife REPEAT FktWert 2 0 3 141 1lfd lfd exp l1fd lfd 3 0 WriteReal lfd 10 WriteReal FktWert 12 WriteLn lfd lfd d laufenden Wert um Schrittweite erh hen UNTIL lfd e END KennlinieTabellieren Hinweise zum Lesen von Programmen in Modula 2 e Writ
230. tile 36 Daly 1977 Support software 30 120 COCOMO highest 132 Quelle Boehm 1981 BILD 5 7 Zeile Person Raten in der Software Pflege I KDSVFSPM steht f r kilo delivered source instructions per full time software person for maintenance 56 Martin Glinz Software Engineering I Sind die Function Points der gepflegten Systeme bekannt und werden die Pflegeaufwendun gen ber l ngere Zeit erfasst so kann daraus der mittlere Pflegeaufwand pro Function Point f r das betreffende Unternehmen bestimmt werden Eine solche Zahl kann dann auch f r Prognosen ber zu erwartende Pflegeaufwendungen eines neuen Systems verwendet werden Jones 1996 gibt dazu folgende Faustregel an REGEL 5 4 Faustregel von Jones f r Pflegeaufwand Zur Pflege eines Systems von N Function Points sind N 500 Personen erforderlich 5 7 Einfluss der Sch tzung auf den Aufwand Es gibt Hinweise daf r dass Sch tzung und tats chlicher Aufwand keine voneinander unab h ngigen Gr en sind Dies ist das durch das Gesetz von Parkinson Der Aufwand passt sich der verf gbaren Zeit an beschriebene Ph nomen Bild 5 8 Abdel Hamid und Madnick 1986 ha ben in Simulationen eine signifikante Korrelation zwischen der Sch tzung und dem tats chlichen Aufwand gefunden Diese Ergebnisse d rfen allerdings nicht zu falschen Schl ssen verleiten Das Parkinson Ph nomen tritt vor allem dann auf wenn in zu knapp kalkulierten Terminpl nen Luft geschaffen wird Dann w
231. tionsmechanismen Benutzung und Vererbung ist der objektorientierte Entwurf methodisch anspruchsvoller als traditionelle Ent wurfsverfahren Bei richtiger Anwendung ist das resultierende L sungsmodell von hoher Quali t t indem es einerseits ein geradliniges Abbild des Modells der Aufgabenstellung darstellt und andererseits nderbar und erweiterbar ist Unsachgem er und undisziplinierter Gebrauch der Objektorientierung kann jedoch auch zu ausgesprochen schlechten Entw rfen f hren Labyrinthische Benutzungsgeflechte quer ber alle Abstraktionsebenen und die Verwendung der Vererbung als Steinbruch irgendwie Passendes wird durch Ableitung von Unterklassen bernommen Unpassendes wird entfernt oder umdefi niert f hren zu nebenwirkungsreichen schwer verstehbaren Systemen deren Pflege extrem aufwendig werden kann 6 6 4 Prozessorientierte Architektur Nebenl ufige Systeme bestehen aus einer Menge unabh ngig arbeitender untereinander ko operierender Akteure die typisch als Prozesse realisiert sind Die Prozesse kooperieren durch 6 Konzipieren von L sungen 75 Austausch von Nachrichten oder durch Zugriff auf gemeinsame Speicherbereiche Die Prozesse k nnen auf einem Rechner ablaufen oder auf verschiedene Rechner verteilt sein In prozessorientierten Architekturen sind die Prozesse die Module der obersten Stufe Jeder Prozess ist typisch ein sequentiell ablaufender Systemteil der seinerseits modularisiert ist bei spielsweise in
232. tl Erprobung wird die Beschaffungsentscheidung gef llt Die Gr nde sollten kurz schriftlich festgehal ten werden damit die Entscheidung sp ter noch nachvollziehbar ist Erf llt keiner der evaluierten Kandidaten die gestellten Anforderungen so ist als erstes zu pr fen ob der Anforderungskatalog zu streng ist und wo man ggf Abstriche machen kann F hrt dieser Weg nicht zum Ziel so ist eine Beschaffung nicht m glich In diesem Fall muss eine L sung selbst entwickelt werden Bei Wiederverwendung werden in der Regel nur Komponenten keine ganzen Systeme be trachtet Das Vorgehen ist grunds tzlich gleich Im Schritt 3 tritt an die Stelle der Markt bersicht die unternehmensinterne Suche nach wiederverwendbaren Komponenten Es ist zu beachten dass auch bei wiederverwendeter Software meistens Anpassungs und Parametrierungsarbeiten anfallen die etwas kosten Ferner ist f r jede wiederverwendete Komponente die Frage der Pfle geverantwortung Lieferant oder Verwender und der dabei m glicherweise entstehenden Kosten f r Pflegevertr ge zu kl ren 6 6 Ausgew hlte Architekturstile Eine Architektur ist im wesentlichen durch die Art der verwendeten Module die Art en der Kooperation zwischen den Modulen und die Art der Modularisierung bestimmt Sind diese drei Arten aufeinander abgestimmt entsteht ein koh renter Architekturstil In den folgenden Ab schnitten werden einige ausgew hlte Architekturstile skizziert 72 Martin Glinz Softw
233. to Software Engineering Second edition Berlin etc Springer 497 p Konventionelle Einf hrung anhand eines Durchgangs durch den Software Lebenslauf In der zweiten Auflage sind zu den strukturierten Methoden die objektorientierten hinzugekommen Durchgehende Fallstudie Johnson J R 1991 The Software Factory Managing Software Development and Mainte nance 2nd edition Wellesley Mass QED Information Sciences 277 p Etwas oberfl chlich popul rwissenschaftlich Themenauswahl stark auf Entwicklung betrieblicher Informations systeme bezogen St rke Enth lt in den Anh ngen Zahlen zu Messungen im Software Entwicklungsprozess Jones G W 1990 Software Engineering New York John Wiley amp Sons 480 p Vom Inhalt her an sich kein schlechtes Buch Insgesamt aber ist das Material zu breit und zu oberfl chlich darge stellt Schlechtes das Lesen behinderndes Layout Kahlbrandt B 1998 Software Engineering Springer Berlin etc Etwas unsystematische Mischung aus Lehrbuch ber Software Engineering und Einf hrung in die UML Unified Modeling Language Kimm R et al 1979 Einf hrung in Software Engineering Berlin Walter de Gruyter 306 p Zum Zeitpunkt seines Erscheinens eines der besten Lehrb cher zum Thema Aus heutiger Sicht teilweise hoffnungs los veraltet teilweise mit erheblichen L cken Heute als Lehrbuch leider nicht mehr verwendbar Lamb D A 1988 Software Engineering Planning for Change Englewood
234. ts und Verpflichtungen obligations gemacht werden e Invarianten sind Zusicherungen ber Systemeigenschaften die durch die Operation nicht ver ndert werden e Verpflichtungen berbinden dem Verwender einer Operation Pflichten die er erf llen muss um bergeordnete Systeminvarianten nicht zu verletzen 6 Konzipieren von L sungen 63 Die Bedingungen und Zusicherungen beschreiben einen Vertrag zwischen dem Modul als Leistungserbringer und den Klienten welche die Leistungen durch Verwendung von Operatio nen des Moduls nutzen Unter der Bedingung dass der Klient garantiert dass die Voraussetzun gen einer Operation des Moduls zum Zeitpunkt der Aktivierung erf llt sind garantiert der Modul dass die Ergebniszusicherungen der Operation nach ihrem Abschluss erf llt sind Die konsequente Dokumentation aller Modulschnittstellen durch solche Vertr ge tr gt erheblich zur Robustheit und nderbarkeit der Software bei Meyer 1988 1997 und 1992 hat daf r den Aus druck Design by Contract gepr gt 6 3 5 Nebenl ufigkeit Dort wo es m glich ist werden Informatikprobleme durch sequentielle Programme realisiert Unter sequentiellen Programmen verstehen wir solche die ein Problem durch eine sequentielle Folge von Programmschritten l sen Zu jedem Zeitpunkt ist folglich h chstens ein Programm schritt in Bearbeitung Die Bevorzugung sequentieller Programme hat vor allem zwei Gr nde Erstens sind sequentielle Programme auf klassischen
235. twicklungspro zesses kreative Arbeiten sind die nicht automatisierbar sind und nicht durch den Einsatz von Hilfsmitteln massiv beschleunigt werden k nnen Brooks 1987 Leistungssteigerungen von mehreren Gr enordnungen bei gleichem Preis innerhalb weniger Jahre wie man dies bei der Hardware beobachten kann hat es bei der Entwicklung neuer Soft ware nie gegeben und wird es wohl auch nie geben Der Schl ssel f r diesen Unterschied liegt in den verkauften St ckzahlen Die Masse macht es Die Kosten f r die Neuentwicklung komplexer Hardware z B eines Prozessors stehen den Kosten f r die Entwicklung komplexer Software um nichts nach Im Gegensatz zur Software aber werden Hardware Komponenten nach ihrer Entwicklung in gro en St ckzahlen verkauft so dass die Entwicklungskosten pro verkauftem Exemplar drastisch sinken Die einzige M glichkeit die Kosten pro verkauftem Exemplar Software massiv zu senken ist eine ebenso massive Steigerung der St ckzahl in der diese Software verwendet bzw ver kauft wird Besonders wirtschaftlich sind also einerseits gro e Serien eines Produkts mit identi scher Software und andererseits die Wiederverwendung von Software 30 Martin Glinz Software Engineering I 3 4 2 Wiederverwendung Wiederverwendung von Software f llt nicht vom Himmel Sie stellt sich auch nicht automa tisch ein wenn sie als Unternehmensziel postuliert wird sondern man muss ihr auf die Spr nge helfen Dies hat technische und o
236. ums durch Dritte bereit 6 3 3 Das Geheimnisprinzip Information Hiding Das Fundamentalprinzip zur Gliederung komplexer Systeme Das von Parnas 1972 entdeckte Geheimnisprinzip information hiding ist das Gliederungs kriterium welches gute Modularisierungen mit den oben genannten Eigenschaften liefert DEFINITION 6 7 Geheimnisprinzip information hiding Kriterium zur Gliederung eines Ge bildes in Komponenten so dass jede Komponente eine Leistung oder eine Gruppe logisch eng zusammenh ngender Leistungen vollst ndig erbringt und zwar so dass au erhalb der Kompo nente nur bekannt ist was die Komponente leistet Wie sie ihre Leistungen erbringt wird nach au en verborgen Parnas hat das Geheimnisprinzip urspr nglich definiert als das Einkapseln von Entwurfsent scheidungen beim Modularisieren von Software mit dem Ziel die Realisierung der Entwurfs entscheidungen vor den Modulverwendern zu verbergen und die Entw rfe dadurch leichter 62 Martin Glinz Software Engineering I nderbar zu machen Die Definition 6 7 wurde bewusst allgemeiner gefasst um deutlich zu machen dass es sich hier um ein weit ber den Software Entwurf und die Informatik hinausrei chendes allgemeines und fundamentales Abstraktionsprinzip zur Beherrschung komplexer Sys teme handelt Wir benutzen das Geheimnisprinzip tagt glich zur Beherrschung der Komplexit t unserer Umwelt etwa indem wir Auto fahren ohne wissen zu m ssen wie ein Verbrennungsmotor
237. ung von Software wird jedoch bis heute nur ungen gend beherrscht Da die Softwarekosten den Hardwarekosten l ngst den Rang abgelaufen haben Bild 1 1 und weltweit horrende Summen f r Software ausgegeben werden Bild 1 2 ist dies ein sehr unbefriedigender Zustand In diesem Kapitel wird gekl rt was eigentlich Software ist und warum Software Entwicklung schwierig ist Auf diesem Hintergrund werden die Idee die Ziele und die grundlegenden Mittel des Software Engineerings motiviert und eingef hrt 100 Hardware Entwicklung Software Pflege Wartung Anteil an den Gesamtkosten in 0 1950 heute BILD 1 1 Entwicklung des Kostenverh ltnisses von Software und Hardware nach Boehm 1981 J hrliche Kosten 1000 weltweit in Milliarden Dollar 500 USA 200 100 USA DoD 50 20 10 5 1980 1985 1990 1995 2000 Jahr nach Boehm 1987 BILD 1 2 Tendenzen im Wachstum der Software Kosten 1996 1998 by Martin Glinz Alle Rechte vorbehalten Reproduktion zum nicht kommerziellen Gebrauch mit Quellenangabe gestattet Reproduktion auch auszugsweise zum kommerziellen Gebrauch nur mit schriftlicher Bewilligung des Verfassers gestattet 2 Martin Glinz Software Engineering I 1 1 Software 1 1 1 Die Rolle der Software Rechner durchdringen alle Lebensbereiche und mit ihnen die Software welche diese Rech ner steuert Wirtschaft und Gesellschaft sind abh ngig geworden von Software Und die Abh n gigkeit nimmt zu Vi
238. ur datenbankbasierter Systeme 6 7 3 2 Steuermuster Das EVA Eingabe Verarbeitung Ausgabe Muster Ein Steuermodul steuert nacheinander in Sequenz oder iterativ Eingabe Verarbeitungs und Ausgabemodule an Dies ist das klassische Steuermuster f r funktionsorientierte sequen tielle Programme vgl Bild 6 2 Das Hauptschleifenmuster Ein Prozess misst regelt und steuert indem er in einer Endlosschleife zyklisch alle Daten quellen Sensoren etc abfragt und alle Datensenken Anzeigen Aktuatoren mit aktualisier ten Werten versorgt Dieses Muster wird wegen seiner Robustheit gerne f r die Steuerung sicherheitskritischer Anwendungen verwendet Das Hollywood Muster Don t call us we call you Ein Ereignisverwalter registriert alle Eingabeereignisse und ruft die zugeh rigen Dienste auf Das Anwendungsprogramm enth lt kein Hauptprogramm mehr Dieses Muster liegt den meisten k uflichen Anwendungsrahmen zugrunde 6 7 3 3 Modularisierungs Entkopplungsmuster Das Model View Controller MVC Muster Ein System wird in drei Teile gegliedert Das Modell Model enth lt die Anwendungs logik und das Modell des Anwendungsbereichs die Sicht View realisiert die u ere sicht bare Repr sentation des Systems und die Steuerung Controller behandelt alle Benutzereinga 6 Konzipieren von L sungen 79 ben Krasner und Pope 1988 Mit diesem Muster werden die Anwendungslogik die Repr sen tation der An
239. utorium von Freeman und Wasserman 1983 gibt anhand von Originalartikeln einen berblick ber verschiedene klassische Entwurfstechniken Unter anderem ist auch Parnas 1972 abgedruckt Meyer 1997 bzw 1988 ist das klassische Lehrbuch ber objektorientierten Entwurf Weitere lesenswerte B cher ber objektorientierten Entwurf sind Booch 1994 Wirfs Brock Wilkerson Wiener 1990 und Z llighoven 1998 Shaw und Garlan 1996 geben einen berblick ber Software Architektur und gehen insbeson dere auf verschiedene Architekturstile und auf Architekturbeschreibungssprachen ein Garlan und Shaw 1993 ist eine Kurzfassung die sich haupts chlich mit Architekturstilen besch ftigt Gamma Helm Johnson und Vlissides 1995 f hren in das Konzept der Entwurfsmuster ein und beschreiben 23 h ufige und typische Muster im Detail Dijkstra 1968 beschreibt als erster eine Architektur die aus mehreren aufeinander aufbauenden Schichten besteht Parnas 1972 beschreibt als erster das Geheimnisprinzip Information Hiding Z llighoven 1998 beschreibt ein in langj hriger Praxis erprobtes Vorgehen f r die Konstruk tion objektorientierter Systeme Zitierte Literatur Booch G 1994 Object Oriented Analysis and Design with Applications Second Edition Redwood City Ca Benjamin Cummings Dijkstra E W 1968 The Structure of the THE multiprogramming System Communications of the ACM 11 5 May 1968 341 346 Fairley R E 1
240. viel sch tzen wie der Auftraggeber zu zahlen bereit ist Sch tzung nach dem Parkinson schen Gesetz Das Projekt kostet soviel Arbeitskapa zit t wie vorhanden ist usw 5 6 Sch tzung von Pflegekosten Aus Messungen ber Entwicklungs und Pflegekosten von Software ergeben sich die folgenden beiden Faustregeln f r Pflegekosten REGEL 5 2 Das Kostenverh ltnis zwischen Entwicklung und Pflege eines Software Produkts liegt im Bereich von 30 70 bis 50 50 Je l nger ein Produkt lebt und je schlechter seine Qualit t ist desto h her ist der Kostenanteil f r die Pflege REGEL 5 3 Die Kosten f r die Pflege eines Software Produkts verteilen sich etwa wie folgt 60 Verbesserungen 20 Anpassungen und 20 Fehlerbehebung Bild 5 7 zeigt verschiedene Sch tzwerte f r die Anzahl Codezeilen die ein Vollzeit Pflege programmierer betreuen kann Die Aussage 20 KDSVFSPy bedeutet beispielsweise dass zur Pflege eines Programms mit 20000 Codezeilen die volle Arbeitskraft einer Person ber das ganze Jahr hinweg erforderlich ist Source Application Type KDSI FSP u COCOMO lowest 3 Wolverton 1980 Aerospace 8 Ferens Harris 1979 Aerospace 10 COCOMO 25th percentile 10 Daly 1977 Real time 10 30 Griffin 1980 Real time 12 Elliott 1977 Business 20 Graver and others 1977 Business HOL 20 Graver and others 1977 Business MOL 22 COCOMO median 25 Lientz Swanson 1980 Business 487 installations 32 COCOMO 75th percen
241. vor Sie arbeiten das Material durch und markieren bzw notieren alle ihre Feststellungen ber Schw chen und St rken Die eigentliche Review Sitzung dient nicht zum Suchen sondern zum Zusammentragen und Bewerten von Schw chen und St rken Review Sitzungen mit unvorbereiteten Teilnehmern sind Zeitverschwendung Vorgegebene Pr flisten und Standards erleichtern die Arbeit 3 Sitzung Die Review Sitzung wird von einem Moderator geleitet Dieser sorgt f r einen geordneten Sitzungsablauf und wacht ber die Einhaltung der Review Regeln Zu den Aufgaben des Moderators geh ren au erdem die Einladung zur Sitzung die berwachung der rechtzeitigen Verteilung des zu pr fenden Materials sowie die Weiterleitung des Review Berichts an die ver antwortliche Stelle 4 Review Bericht W hrend der Sitzung wird ein Review Bericht erstellt welcher die in der Sitzung genannten und von der Mehrheit der Teilnehmer gebilligten Schwachstellen und St rken auflistet Der Review Bericht soll einen Konsens der am Review Beteiligten ausdr cken er wird am Ende der Sitzung von allen unterschrieben 5 berarbeitung und Nachkontrolle Der Projektverantwortliche entscheidet aufgrund des Review Berichts ber die durchzuf h renden nderungen und gibt diese in Auftrag Je nach Umfang dieser nderungen erfolgt die Nachkontrolle durch ein neues Review oder durch den Projektverantwortlichen 9 4 2 2 Informelle Reviews Der mit formellen Reviews verbundene Or
242. wendung gegen ber der Au enwelt und die Steuerung der Eingaben voneinander entkoppelt Das MVC Muster ist ein zentrales Muster im Entwurf objektorientierter Systeme Es kann auch im Kleinen als Entwurfsmuster verwendet werden Gamma et al 1995 Datenbank Bild 6 8 Architektur eines datenbankbasierten Anwendungssystems nach dem Matrixmuster 6 8 Architekturmetaphern Eine Metapher ist ein sprachlicher Ausdruck bei dem ein Wort aus seinem Bedeutungszu sammenhang in einen anderen bertragen als Bild verwendet wird Definition 6 13 Architekturmetapher Leitbild f r die Gestaltung einer Architektur Eine Architekturmetapher ist ein Modell das eine Architektur ber analoge vertraute Bilder erschlie t Die Metapher erm glicht ein besseres Verst ndnis der Systemstruktur und ist das Leitbild f r die Gestaltung der Architektur In den folgenden Abschnitten werden einige Archi tekturmetaphern kurz vorgestellt 6 8 1 Die WAM Werkzeug Automat Material Metapher Das System besteht aus Materialien fachliche Arbeitsgegenst nde der Anwendung die von den Benutzern mit passenden Werkzeugen interaktiv bearbeitet werden Vollst ndig automati sierbare Routineaufgaben werden von Automaten erledigt Z llighoven 1998 e Werkzeuge sind gegen ber den Materialien aktiv indem sie Materialien bearbeiten Sie wer den von Menschen benutzt bzw bedient Diesen gegen ber verhalten sie sich passiv oder assi stierend sie berlassen die Kont
243. wie ein Objekt aus dem Anwendungsbereich repr sentiert und realisiert ist zum Beispiel ein Konto e wie eine Datenstruktur aufgebaut ist und wie sie bearbeitet werden kann zum Beispiel die Datenhaltung und die Suchfunktion f r die Bereitstellung von Gelben Seiten im WWW e wie Leistungen Dritter realisiert sind zum Beispiel wie ein Datenbanksystem intern funktio niert 6 3 4 Schnittstellen und Vertr ge Schnittstellen interfaces beschreiben das Leistungsangebot eines Moduls In Anwendung des Geheimnisprinzips soll die Beschreibung so weit wie m glich realisierungsneutral sein In der Regel werden Leistungen in Form von Operationen und Datentypen bereitgestellt Die Be reitstellung direkt zugreifbarer Daten wird nach M glichkeit vermieden da sie die Offenlegung der Datenrepr sentation erfordert Voraussetzungen preconditions und Ergebniszusicherungen assertions postconditions gestatten eine realisierungsneutrale Beschreibung der Operationen e Die Voraussetzungen geben an welche Bedingungen erf llt sein m ssen bevor die Operation aktiviert werden darf Die Operation pr ft die von ihr gemachten Voraussetzungen in der Regel nicht Bei verletzten Voraussetzungen ist das Ergebnis der Operation undefiniert e Die Ergebniszusicherungen beschreiben die Ergebnisse der Operation gelieferte Daten nde rungen im Systemzustand Weitere Aussagen sei es f r eine Operation oder f r den ganzen Modul k nnen mit Invarianten invarian
244. yp muss in jedem Einzelfall entschieden werden wie weit die Entwicklung von Prototypen f r die Pr fung von Anforderungen aufgrund des Entwicklungsrisikos notwendig ist Aufgaben 7 1 Welches sind die Eigenschaften einer guten Spezifikation Begr nden Sie ihre Aussagen 7 2 Nehmen Sie an Sie br uchten ein Zutrittskontrollsystem Schl sselkarten o f r die Haust r eines B rogeb udes Beschreiben Sie ihre Vorstellungen ber das Verhalten dieses Systems mit Szenarien 7 3 Spezifizieren Sie einen Taschenrechner Ihrer Wahl in nat rlicher Sprache Gliedern Sie die Anforderungen gem der Struktur der Anforderungen an das Produkt in Bild 7 4 Erg nzende und vertiefende Literatur Davis 1993 ist ein Lehrbuch ber Requirements Engineering das vor allem die klassischen Techniken beschreibt Gause und Weinberg 1989 beleuchten prim r den Aspekt der Anforderungsgewinnung und der sozialen Dimension des Requirements Engineerings Kotonya und Sommerville 1998 ist eine Monographie ber Requirements Engineering Oestereich 1998 gibt eine sehr gute Einf hrung in die UML Verschiedene objektorientierte Spezifikationsverfahren sind beschrieben in Booch 1994 Booch Jacobson und Rumbaugh 1997 Coad und Yourdon 1991a Jacobson et al 1991 Rumbaugh et al 1991 Die folgenden Autoren behandeln klassische Spezifikationsverfahren Information Engineering Martin 1990 SSADM Ashworth und Goodland 1990 Strukturiert
245. zu sammengefasst werden was jedoch mit Modulen die nur eine Funktion enthalten und damit nur einen m glichen Aufruf haben nicht m glich ist Diese ungen genden Abstraktionsm glich keiten erschweren das Verst ndnis und die nderbarkeit gro er funktionsorientierter Entw rfe massiv Key O Data Control information Compute solutions Solution Solution Write solution Formatted Formatted output output Read from Format Write to input file solution output file Bild 6 2 Funktionsorientiert gegliedertes System Good input Get good data item Compute a solution Solution Validate data item Quelle Fairley 1985 6 6 2 Datenorientierte Architektur Entwurf mit Datenabstraktionen Im Zentrum der datenorientierten Architektur steht eine Modularisierung nach dem Geheim nisprinzip vgl 6 3 3 Wie bereits dort erw hnt gibt es dabei vier typische Arten von Entwurfs entscheidungen die zu Modulen f hren a wie eine Funktion realisiert ist b wie ein Objekt aus dem Anwendungsbereich repr sentiert und realisiert ist c wie eine Datenstruktur aufgebaut ist und wie sie bearbeitet werden kann d wie Leistungen Dritter realisiert sind 6 Konzipieren von L sungen 73 Die F lle b c und d ben tigen einen Abstraktionsmechanismus welcher eine Daten struktur und die auf den Daten dieser Struktur m glichen Operationen zu einer Einheit zusam
246. zu testenden Testf lle ausgew hlt eine Testumgebung zur Abarbeitung dieser Testf lle bereitgestellt und die Testvorschriften d h die Vorgabedoku mente gem denen die Tests durchgef hrt werden erstellt Bei der Testdurchf hrung wird zun chst die Testumgebung nach den Angaben der f r diesen Test geltenden Testvorschrift eingerichtet Dann werden die Testf lle der Testvorschrift der Reihe nach ausgef hrt Alle Befunde werden notiert W hrend der Testdurchf hrung wird der Pr fling nicht ver ndert Die Testergebnisse werden in einer Testzusammenfassung festgehalten Die Fehlerbehebung ist kein Bestandteil des Tests Sie erfolgt nachher indem die Test befunde analysiert die Fehlerursachen bestimmt und die Fehler dann behoben werden Es ist sehr wichtig dass die Aufwendungen f r das Testen in jedem Projekt sorgf ltig ge sch tzt und in der Projektplanung ber cksichtigt werden Nur dann ist es m glich die f r das Erreichen der angestrebten Qualit t notwendigen Tests auch tats chlich durchzuf hren 9 2 3 Testverfahren Man unterscheidet zwei Klassen von Testverfahren Beim funktionsorientierten Test Black Box Test erfolgt die Auswahl der Testf lle aufgrund der Spezifikation Die Programmstruktur kann unbekannt sein Es wird angestrebt die geforderten Eigenschaften des Pr flings Funktionalit t Leistungsverhalten weitere Attribute des Pr flings m glichst vollst ndig durch Testf lle abzudecken Beim strukturorie

2001 by Martin Glinz. Alle Rechte vorbehalten. Reproduktion zum

Contents

Download Pdf Manuals

Related Search

Related Contents