Softwaretechnik WS 2013/14. Fomuso Ekellem

Transkript

1 WS 2013/14

2 Inhalt Einführung Begriffe Prozess Modelle Planungsphase 2

3 Einführung Um was geht es hier in der Vorlesung? Das Gebiet der befasst sich mit der Planung, Entwicklung, Anwendung und Wartung von Software und daher mit Prinzipien, Methoden und Werkzeugen, weshalb dieses Gebiet damit eine Menge von Teildisziplinen integriert. Man sagt auch Programmierung von Software als Ganzes, oder Programmierung in Großen. Programmierung in kleinen ist die eigentliche Programmierung(Implementierung) von Software. 3

4 -Lernziele Lernstufe-Wissen(Klausur) Elementare Kenntnisse. Darunter: Begriffen, Fakten, Klassifikationen und Kriterien. Lernstufe-Verstehen(Klausur) Funktionale Kenntnisse. Darunter sind u.a. Beschreibung Darunter: Verfahren, Methoden, Regeln und Gesetzmäßigkeiten. Lernstufe-Anwenden (Projektarbeit) Sachkundigen Umgang mit Formeln und Verfahren zur Lösung von Problemen, zu denen die Übertragung von Wissen und Verstehen in Direktem Bezug auf einzelne und konkrete Situationen notwendig ist. Lernstufe-Beurteilen (Projektarbeit) Lösung komplexer Aufgaben, zu denen anhand von Analysen Auswahlentscheidungen zu treffen und/oder Verfahren zu entwickeln sind. 4

5 Begriffe: Projekt Ein Projekt ist ein Vorhaben welches zeitlich durch einen definierten Anfangs- und Endtermin begrenzt ist, welches durch die Einmaligkeit seiner Bedingungen, wie zum Beispiel Projektziele, Projektabgrenzung, an der Umsetzung Mitwirkenden Organisationen und Ressourcen, sowie deren Erfahrungsgrad gekennzeichnet ist. Projekt-Lernziele Grundbegriffe über Projekte lernen Projektplanung Bedeutung von Projektmodellen einschätzen lineare und evolutionäre Sichtweise unterscheiden 5

6 Begriffe: Aktivitäten Mit Aktivitäten ist immer die Frage: Wer, erstellt was wann mit welcher Praktik, Methode, Werkzeug Beispiel Aktivitäten in der : Anforderungsanalyse Design Implementierung Anforderungstest usw 6

7 Begriffe: Prozesse Prozesse sind hierarchische Gruppierung von Aktivitäten, die Eingangsdaten in Ausgangsdaten transformieren. Oder auch Hierarchische Gruppierung von Teilergebnisse und deren Entstehungsbeziehung. Beispiel Prozesse: Projektmanagement Anforderungsmanagement Software Design Software Konstruktion Softwaretest Konfigurations-, Qualität-, Risiko- und Lieferantenmanagement. usw Prozesse-Lernziele Softwareentwicklung als Entwicklungsprozess betrachten Prozessmodelle kennenlernen 7

8 Begriffe: Workflow Workflow: Arbeitsteilig durchgeführter Arbeitsprozesse Man kann Dynamische und Statische Workflow unterscheiden. Workflowbeispiel von projektstart: Erstellung der Projektdefinition Freigabe der Projektdefinition durch die Geschäftsleitung Kickoff Meeting Projektstart Workshop Freigabe Baseline Projektplan. 8

9 Begriffe: Artefakte und Verantwortung Damit in jedem Projekt nicht alles neu erfunden werden muss, als Basis für die Projektplanung und Verbesserungen: Werden Erfahrungen gesammelt und genutzt Wird Sicherheit erstellt, das Richtige zur richtigen Zeit zu tun Werden Vorlage für die tägliche Arbeit auch erstellt Zur Positionsbestimmung Frühzeitige Erkennung von Problemen Transparenz im Projekt (Zeit, Kosten, Qualität) Gruppierung von Tätigkeiten. Beispiele: Projektmanager, Software-Entwickler, System-Tester Verantwortlichkeiten für bestimmte Dokumente Unterscheidung: Autor, Co-Autor, Prüfer, usw Personelle Zuordnung durch die Projektplanung: Mehrere Personen eine Rolle oder Mehrere Rollen eine Person 9

10 Problematik der Softwareentwicklung Software ist ein immaterielles Produkt; Man kann nicht immer erkennen, was ein Entwickler gerade macht. Software unterliegt keinem Verschleiß; Software wird nicht durch physikalische Gesetze begrenzt; Software ist im Allgemeinen leichter und schneller änderbar als ein technisches Produkt; Für Software gibt es keine Ersatzteile; Software altert; Software ist schwer zu vermessen. 10

11 Bedeutung von Software Was ist überhaupt Software? Software (engl., eigtl.»weiche Ware«), Abk. SW, Sammelbezeichnung für Programme, die für den Betrieb von Rechensystemen zur Verfügung stehen, einschl. der zugehörigen Dokumentation (Brockhaus Enzyklopädie) Software, die zum Betrieb einer Datenverarbeitungsanlage erforderlichen nichtapparativen Funktionsbestandteile (Fremdwörter-Duden) Software:... unter Software subsumiert man alle immateriellen Teile, d.h. alle auf einer Datenverarbeitungsanlage einsetzbaren Programme (Lexikon der Informatik und Datenverarbeitung [Schneider86]) Software: Menge von Programmen oder Daten zusammen mit begleitenden Dokumenten, die für ihre Anwendung notwendig oder hilfreich sind (Ein Begriffssystem für die [Hesse84]). 11

12 Bedeutung von Software Software-Produkt Ein Produkt ist ein in sich abgeschlossenes, i. A. für einen Auftraggeber bestimmtes Ergebnis eines erfolgreich durchgeführten Projekts oder Herstellungsprozesses. Als Teilprodukt bezeichnen wir einen abgeschlossenen Teil eines Produkts. SW-Produkt: Produkt, das aus Software besteht. Software-System Unter einem System wird ein Ausschnitt aus der realen oder gedanklichen Welt, bestehend aus Gegenständen (z. B. Menschen, Materialien, Maschinen oder anderen Produkten) und darauf vorhandenen Strukturen (z. B. deren Aufbau aus Teileinheiten oder Beziehungen untereinander) verstanden. [Hesse84]. Software-System ist dementsprechend ein System, dessen Systemkomponenten und Systemelemente aus Software bestehen. 12

13 Bedeutung von Software Systemsoftware Software die für eine spezielle Hardware oder Hardwarefamilie entwickelt wurde um den Betrieb und die Wartung dieser Hardware zu ermöglichen. Dazu gehören das Betriebssystem, Compiler,... Orientiert sich grundsätzlich an den Eigenschaften der Hardware, für die sie geschaffen wurde und ergänzt deren Fähigkeiten Anwendungssoftware (application software) Software die Aufgabe des Nutzers mit Hilfe eines Computersystems löst. Setzt in Regel auf der Systemsoftware der verwendeten Hardware auf bzw. benutzt sie zur Erfüllung der eigenen Aufgaben 13

14 Bedeutung von Software Computersystem (DV-System) Anwender Benutzer Anwendungssoftware + Systemsoftware + Hardware Angehörige einer Institution oder organisatorischen Einheit die ein Computersystem zur Erfüllung ihrer fachlichen Aufgaben einsetzen Personen, die ein Computersystem unmittelbar einsetzen und bedienen Technisches System Computersystem + technische Einrichtungen 14

15 Bedeutung von Software Organisatorisches System Mitarbeiter in ihrer Rolle als Auftraggeber einschließlich Anwendern und Benutzern Informationssystem Menschen und Maschinen die Information erzeugen und/oder benutzen und durch Kommunikationsbeziehungen verbunden sind. Enthält es mehrere Computersysteme, so spricht man von einem computergestützten Informationssystem Computergestütztes Informationssystem System bei dem die Erfassung, Speicherung, Übertragung, Auswertung und/oder Transformation von Information durch Computersysteme teilweise automatisiert ist. Software-Entwicklung Ausschließliche Entwicklung von Software. System-Entwicklung Entwicklung eines Systems, dass aus Hardware und Softwarekomponenten besteht. 15

16 Schwierigkeiten bei der Entwicklung Zunehmend Außer-Haus-Entwicklung Trend: Software nicht selbst zu entwickeln, sondern Auftragsentwicklung Prognose: Von den Software-Produkten und den zugehörigen Dienstleistungen werden generell etwa 55% intern und 45% extern erbracht werden. Durch die zunehmende Produktintegration von Software (eingebettete Systeme) wird der Prozentsatz intern erstellter Software nicht drastisch zurückgehen. Zunehmend Altlasten Anwendungssoftware wird oft 20 Jahre und länger eingesetzt Da sich die Einsatzumgebung dieser Anwendungssoftware ständig ändert, muss diese Software ebenfalls ständig angepasst werden Diese permanenten Anpassungsprozesse verursachen oft 2/3 aller Software-Kosten 16

17 Schwierigkeiten bei der Entwicklung Hardware-Zykluszeit: 3 Jahre Systemsoftware-Zykluszeit: 6 Jahre Anwendungssoftware-Zykluszeit: 10 bis 15 Jahre 17

18 Weitere Begriffe Bei der Entwicklung eines Software-Produkts wird oft von folgenden Begriffen gesprochen: Spezikation: Festlegung der Anforderungen. Verikation: Verfahren zum Beweisen der Korrektheit. Validierung: Ist der dokumentierte Nachweis, dass die Leistungskriterien reproduzierbar erfüllt werden. Konsistenz von Dokumentation und Code : beschreibt den Grad, in dem die definierten Anforderungen widerspruchsfrei sind. 18

19 Quelle: Band 2 Balzert 19

20 Grobe Entwicklungszyklus Die Phasen eines typischen Softwareentwicklungszyklus: Dies ist unser Vorlesungsmodel. Somit können wir über der Kriterien von Definitionsphase betonen. 20

21 Entwicklungszyklus Eine andere Blickwinkle. Alle Phasen werden analysiert, geplant, definiert und abgewickelt in Hinblick auf Projektmanagement. Projektmanagement (Planung und Abwicklung von Phasen) 21

22 Allgemein zu Phasen in mit Dokumentation 22

23 Allgemein zu Phasen Jede Phase zeichnet sich durch folgende Punkte aus: Ziele der Phase Durchzuführende Aktivitäten Aktivitäten/Rollenzuordnung Zu erstellende Artefakte Zu verwendende Artefakt-Muster Zu beachtende Methoden, Richtlinien, Konventionen und Checklisten Einzusetzende Werkzeuge und Sprachen 23

24 Allgemein zu Phasen Grafische Darstellung des Ablaufs der einzelnen Aktivitäten in einer Phase im sieht wie folgt aus: 24

25 Prozess Modelle Prozess Modelle legen fest Reihenfolge des Arbeitsablaufs Entwicklungsstufen Phasenkonzepte Jeweils durchzuführende Aktivitäten Definition der Teilprodukte einschließlich Layout und Inhalt Fertigstellungskriterien Notwendige Mitarbeiterqualifikationen Verantwortlichkeiten und Kompetenzen Anzuwendende Standards, Richtlinien, Methoden und Werkzeuge Also = die verschiedenen Stadien der Entwicklung und Nutzung eines Softwareproduktes werden beschrieben. Hierzu werden die erforderlichen Aktivitäten (in ihrer Reihenfolge) und die zu erzielenden Ergebnisse festgelegt. 25

26 Prozess Modelle Es gibt eine Menge Prozess Modelle, u.a. Das Wasserfall-Modell** Das V-Modell** Das Prototypen-Modell Das evolutionäre/inkrementelle Modelle Das nebenläufige Modelle Das Spiralmodell Das objektorientierte Modell** 26

27 Prozess Modelle Wasserfall-Modell Software wird in sukzessiven Stufen entwickelt. Ergebnisse einer Phase fallen wie bei einem Wasserfall in die nächste Phase. Jede Aktivität ist in der richtigen Reihenfolge und in der vollen Breite vollständig durchzuführen. Am Ende jeder Aktivität steht ein fertiggestelltes Dokument (Dokumentengetriebenes Modell). Der Entwicklungsablauf ist sequentiell (Jede Aktivität muss beendet sein, bevor die nächste anfängt). Benötigt nur wenig Managementaufwand. Benutzerbeteiligung ist nur in der Definitionsphase vorgesehen. Iterationen sind nur zwischen aufeinanderfolgenden Stufen erlaubt. 27

28 Prozess Modelle Wasserfall-Modell (System-Anforderungen, Software-Anforderungen, Analyse) 28

29 Prozess Modelle Wasserfall Modell: Vorteile Einfach, verständlich, sequentiell (vom Allgemeinen zum Speziellen(Top Down)), fester Lösungsweg. Geringer Management-Aufwand Disziplinierter, kontrollierbarer und sichtbarer Prozessablauf. 29

30 Prozess Modelle Wasserfall Modell : Nachteile Es ist nicht immer sinnvoll alle Entwicklungsschritte in der vollen Breite und vollständig durchzuführen alle Entwicklungsschritte sequentiell durchzuführen Gefahr, dass die Dokumentation wichtiger wird, als das eigentliche System Risikofaktoren werden unter Umständen zu spät erkannt, da der einmal festgelegte Entwicklungsablauf schon weit fortgeschritten ist. Möglichkeit von Feedback ist kaum gegeben. Benutzerbeteiligung ist nur bei der Anforderungsanalyse und in der Betriebsphase. D.h., Kunde wird erst mit dem fertigen Produkt konfrontiert (Wasserfallsystem eignet sich somit nicht für große Projekte, da alle Spezifikationen bekannt sein müssen ). 30

31 Prozess Modelle Wasserfall-Modell 31

32 Prozess Modelle V-Modell Erweiterung des Wasserfall-Modells Integriert die Qualitätssicherung in das Wasserfall-Modell Verifikation und Validation der Teilprodukte sind Bestandteile des V-Modells Submodelle im V-Modell: PM: Projektmanagement SE: Systemerstellung QS: Qualitätssicherung KM: Konfigurationsmanagement Was ist zu tun? Wie ist etwas zu tun? Womit ist etwas zu tun? 32

33 Prozess Modelle V-Modell 33

34 Prozess Modelle V-Modell Standardisierungskonzept der Bundesbehörden (V-Modell XT) Erstmals 1992, überarbeitet 1997 (V-Modell 97) Neufassung 2004 (V-Modell XT) Verbindlich für IT-Vorhaben in Bundesbehörden Auch in der Industrie verbreitet (Automobil-Industrie) Sehr umfangreiches Modell, das für eine konkrete Entwicklung angepasst werden muss (Tailoring). Extrem viele Schritte in mehreren Subsystemen. Extrem viele Rollen (Manager, Entwickler,...). 34

35 Prozess Modelle V-Modell: Rollen 35

36 Prozess Modelle V-Modell: Vorteile Integrierte, detaillierte Darstellung von SE, QS, KM und PM. Generisches Vorgehensmodell mit definierten Möglichkeiten zur Anpassung an projektspezifischen Anforderungen. Ermöglicht eine standardisierte Abwicklung von Systemerstellungs-Projekten. Gut geeignet für große Projekte. 36

37 Prozess Modelle V-Modell: Nachteile Die Vorgehenskonzepte, die für große Projekte geeignet sind werden unreflektiert auf andere kleinere Projekte übertragen. Für kleine und mittlere Softwareentwicklungen führt das V-Modell zu einer unnötigen Bürokratie. Ohne geeignete Werkzeug-Unterstützung ist das V-Modell nicht handhabbar 37

38 Prozess Modelle Zusammenfassung 38

39 Prozess Modelle Wasserfall und V-Modell (Nachteil) Alle Anforderungen müssen am Anfang bekannt sein (Vorteil) Sehr einfach und strukturiert, Konzentration auf Dokumentation 39

40 Objektorientiertes Vorgehensmodelle OOP setzt Objektorientierte Analyse (OOA) und Objektorientierte Design(OOD) um in eine Implementierung(Programmierung) In OOA ist Wichtig: Identifikation der relevante Teile und Umsetzung der Requirement in Objektmodelle. OOD erweitert die Ergebnisse von OOA mit dem Fokus auf eine geplante Implementierung und deren Strukturierung. Zentrales Basiskonzept aller objektorientierten Analysemethoden ist ein objektorientiertes Klassenmodell Klassen als gemeinsame Kapselungseinheit von Daten und Funktionen Abbildung von Struktur und Verhalten einer Klasse durch Attribute und Operationen Ein wesentliches Merkmal ist wie bei allen Vorgehensmodellen, das Systemmodul entsteht in einem kontinuierlichen Prozess der schrittweise Verfeinerung (Iterativ-Inkrementelles Vorgehen) 40

41 Objektorientiertes Vorgehensmodelle Voraussetzung für die Durchführung des Vorgehensmodels: Es liegt eine vollständige Anforderungsspezifikation(Lastenheft, Pflichtenheft, Systemglossar, Anforderung-Repository) vor Die Anforderungen an die extern sichtbare Systemfunktionalität sind bereits in Form von Anwendungsfällen(Use Cases) beschrieben Eigenschaften Anwendungsfallgetrieben, Architektur- und komponentenzentriert, Iterativ und Inkrementell 41

42 Objektorientiertes Vorgehensmodelle Anwendungsfallgetrieben Funktionale Anforderungen an das zu entwickelnde System werden in Anwendungsfälle zerlegen Aus Sicht der Anwender Bilden Grundlage und Checks für alle weiteren Schritte Anwendungsfälle können priorisiert werden bzgl. der Reihenfolge der Umsetzung 42

43 Objektorientiertes Vorgehensmodelle Architektur- und komponentenzentriert Eigenschaften und Besonderheiten einer vorhandenen Anwendungsarchitektur müssen berücksichtigt werden. Die Anwendungsarchitektur bestimmt, welche Artefakte überhaupt zu entwickeln sind. Beispiel einer Anwendungsarchitektur ist die Verwendung eines Anwendungs-Frameworks Systeme können in Komponenten und Subsysteme gegliedert sein. Auch das ist zu berücksichtigen Die Vorgehensweise sollte also die Erarbeitung der durch die Architektur vorgegebenen Artefakte optimal unterstützen 43

44 Objektorientiertes Vorgehensmodelle Iterativ und Inkrementell Das Model wird in mehreren Iterationsschritten(nach und ggf. nebeneinander) erstellt und dabei permanent verbessert und verfeinert. Zunächst Anwendungsfälle: Grobe Anforderungsbeschreibung. Dann ggf. Bildung von Subsystemen Subsysteme können von separaten Teams realisiert werden Teilergebnisse der Teams müssen regelmäßig synchronisiert werden Zwischenergebnisse werden in Reviews validiert und verifiziert Jedes Team legt zu festgelegten Zeiten Ergebnisse vor: Gliederung des Entwicklungsprozesses jedes Teams in Iterationen Jede Iteration liefert ein Teilergebnis Inkrementell: Gesamtfunktionalität wächst mit jedem Schritt Jedes Modell-Inkrement wird vor seiner Freigabe geeigneten qualitätssichernden Maßnahmen unterzogen. 44

45 Objektorientiertes Vorgehensmodelle Ein einfaches Vorgehensmodell: In der LifeCycle werden wir mehr sehen 45

46 Planungsphase Ziele und Inhalt Ziele: Inhalte: Vorbereitung Projektdurchführung Überwachung und Steuerung Durchführung Anforderung analysieren Planung: Aufgabe Definition: Was ist zu tun? Vorgaben/Hilfsmittel: Wie ist es zu tun? Definition Termine: (Bis) Wann ist es zu tun? Definition Verantwortung: Wer hat es zu tun? 46

47 Aufklärung- Entwicklungszyklus Die Phasen eines typischen Softwareentwicklungszyklus: Dies ist unser Vorlesungsmodel. Somit können wir über der Kriterien von Definitionsphase betonen. 47

48 Planungsphase Man beachte: Die Planungsphase und Definitionsphase sind so sehr mit einander verknüpft, und man braucht viel Erfahrung um die auseinander zu halten. Manchmal werden die als eine Phase gesehen. Planungsphase ist die erste Phase einer Software-Entwicklung. In ihr wird geprüft, ob ein Produkt durchführbar ist. Die fachlichen Anforderungen werden im Lastenheft festgehalten. Im Glossar werden die verwendeten Begriffe definiert. Die Ergebnisse der Planungsphase werden in einer Durchführbarkeitsstudie (feasibility study) zusammengefasst. Sie enthält eine Empfehlung, ob die Entwicklung fortgeführt oder abgebrochen werden soll. 48

49 Planungsphase 49

50 Requirement Engineering Anforderung Analyse(Requirement Engineering) Das Requirements Engineering beinhaltet die Ermittlung, die Analyse, die Definition, das Tracing und die Änderungsverwaltung von Anforderungen Anforderungsanalyse ist iterativ. Tätigkeiten: Ermittlung, Analyse, Prüfung, Verfolgung und Validierung von Anforderungen. Systeme haben viele Gesichtspunkte mit unterschiedlichen Anforderungen und unterschiedliche Sichten auf das selbe zu entwickelnde System Häufigster Fehler: Dem Kunden zu geben, was er braucht und nicht, was er will. Wichtige Fragen: Was sind Anforderungen? Vorgehensweise beim Requirements Engineering Anforderungsdefinition Requirement-Tracing 50

51 Requirement Engineering Lernziele Verstehen, was Anforderungen sind Erklären können, was für unterschiedliche Anforderungsarten es gibt Verstehen, wie Anforderungen definiert werden Den Prozess der Anforderungsdefinition erklären können Erklären können, was Requirements Tracing ist 51

52 Requirement Engineering-was sind Anforderungen Arten von Anfoderungen Bei der Ermittlung und Beschreibung der Anforderungen ist zu unterscheiden zwischen: funktionalen Anforderungen Was soll das zu entwickelnde Softwaresystem tun? nichtfunktionalen Anforderungen Welche Eigenschaften soll das zu entwickelnde Softwaresystem zusätzlich zur Funktionalität aufweisen? 52

53 Requirement Engineering-was sind Anforderungen Funktionale Anforderungen Funktionalitäten Daten Algorithmen Abläufe Eingaben Ausgaben Datenmodelle Schnittstellen Benutzungsschnittstellen Schnittstellen zu anderen Systemen 53

54 Requirement Engineering-was sind Anforderungen Nichtfunktionale Anforderungen Leistungsanforderungen z. B. Benutzerzahl, Datenumfang, Antwortzeiten, Prozesshäufigkeit Qualitätsanforderungen z. B. Zuverlässigkeit, Sicherheit, Robustheit, Portierbarkeit,... Realisierungsanforderungen Entwicklung, Entwicklungsmethode Aufwand Richtlinien Abnahme Wartung Dokumentation 54

55 Requirement Engineering Definition: Anforderungen (Requirements)legen die qualitativen und quantitativen Eigenschaften eines Produkts fest. Problematik bei der Festlegung von Anforderungen: Anforderungen sind: mehrdeutig nicht erfüllbar überbestimmt unvollständig inkonsistent Die Anforderungsbeschreibung legt fest, was ein Produkt können soll, wie es aussieht und mit welchen Mitteln es realisiert werden soll, NICHT: wie es realisiert wird. 55

56 Requirement Engineering Eigenschaften guter Anforderungen Klare Struktur Aufteilung in Kapitel, Unterkapitel, etc. Strukturierung von Anforderungen Einzelanforderungen erkennbar und nachprüfbar Identifizierung Klassifizierung Vollständigkeit Analysierbarkeit von Anforderungen Widerspruchsfreiheit Analysierbarkeit von Anforderungen Verständlichkeit Bilder sagen mehr als Worte natürliche Sprache statt Formeln Konflikt Testfälle 56

57 Requirement Engineering- Vorgehensweise Ziele des Requirement Engineering Unterstützung des Auftraggebers bei der Ermittlung der Anforderungen Unterstützung der Entwickler bei der Aufbereitung der Anforderungen Formulieren Klassifizieren Hierarchisieren Präzisieren Unterstützung der Qualitätssicherung bei der Validierung des Systems Vorgehensweise: Einordnung in den Entwicklungsprozess (Vorgehensmodell) Vertrag über WAS das System können sollte 57

58 Requirement Engineering- Vorgehensweise Risiken des Requirement Engineering Übersehen von entscheidenden Anforderungen Unzulängliche Darstellungen der Anforderungen gegenüber dem Kunden Modellierung ausschließlich funktionaler Anforderungen Keine Prüfung der Anforderungen Vorwegnahme von Entwurfsentscheidungen 58

59 Requirement Engineering- Vorgehensweise Bewältigung der Risiken Kategorisierung Gruppierung von Anforderungen und konsequente Verwendung von Vorlagen Organisierung Priorisierung Verwendung von Tools zum Verstehen und Verfolgen der Anforderungen Striktes Änderungsmanagement Ermittlung der Reihenfolge basierend auf Notwendigkeit und Risiken Realisierung in Inkrementen in der Reihenfolge der Prioritäten 59

60 Requirement Engineering- Vorgehensweise Schwachpunkte des Requirement Engineering Ausdrucksmittel für Anforderungsbeschreibungen Verständlichkeit versus Verarbeitbarkeit Probleme bei der Gewinnung von Anforderungen Unvollständige und inkonsistente Informationen Unterschiede und Widersprüche werden nicht erkannt Keine klaren Entscheidungen im Konfliktfall Mögliche Auswirkungen werden nicht aufgezeigt Unterschiedliche Interessen auf Kundenseite Systemumgebung ist nicht klar beschrieben Systemumgebung ändert sich 60

61 Anforderungsdefinition-Lastenheft Derzeit ist es eher die Ausnahme, dass tatsächlich Lasten- und Pflichtenhefte erstellt werden. Diese Schritte bis zur Angebotserstellung laufen vielmehr über Meetings und Telefonate ab. Dokumentationen dieser Art, so eine verbreitete Meinung, verzögern und verteuern den Entwicklungsprozess nur unnötig. Es scheint zunächst wichtiger zu sein, eine Software fertig zu stellen, als eine Vorgabe dafür zu erarbeiten. Bislang hat sich keine verbindliche Regelung durchsetzen können, wie ein Lasten- oder Pflichtenheft auszusehen hat. 61

62 Anforderungsdefinition-Lastenheft Definition: Das Lastenheft des Auftraggebers beschreibt die Zielsetzungen, Aufgabenstellungen und Eckdaten des Projektes und bedient sich dabei der Dokumentation des Istzustands mit anschließender Erläuterung des Sollzustands. Im Lastenheft wird definiert was zu lösen ist und wofür etwas zu lösen ist. Das fachliche Ergebnisdokument der Planungsphase wird oft als Lastenheft oder grobes Pflichtenheft bezeichnet. Die Aufgabe des Lastenheft ist die Zusammenfassung der Anforderungen aus Anwendersicht an ein Produkt/eine Leistung einschließlich aller Randbedingungen. Diese sollten quantifizierbar und prüfbar sein. Das Lastenheft wird von einem Auftraggeber oder in dessen Auftrag erstellt und dient als Ausschreibungs-, Angebots- und Vertragsgrundlage. Bei kleinen Projekten (weniger als 6 Tage) wird eher auf Basis eines Lastenheft mit der Entwicklung begonnen, weil die Projekte dann häufig so überschaubar sind, dass das Lastenheft schon ausreichend sein kann. 62

63 Anforderungsdefinition-Lastenheft Nutzeranforderungen (ein Teil von Anforderungsdefinition) Problembeschreibung aus der Sicht des Nutzers/Kunden Nutzeranforderungen sind meistens verbal Schwierigkeit: Kunde versteht die formalisierte Beschreibung nicht. Abhilfe: Prototyping und grafische Modellierung der Nutzeranforderungen (Systemverhalten) Es gibt auch Systemanforderungen (die Pflichtenheft): Pflichtenheft werden wir in der Definitionsphase sehen. Problembeschreibung aus der Sicht des Realisierers Analyse mit unterschiedlichen Sichtweisen ist wichtig, da es nicht einen richtigen Weg gibt, die Systemanforderungen zu analysieren. 63

64 Anforderungsdefinition-Lastenheft Die typische Gliederung der Lastenhefte sollte sich an folgenden Schwerpunkten orientieren, wobei immer auf dasselbe Schema zurückgegriffen werden sollte: Aufgabenstellung Unternehmenscharakteristik Istzustand, d.h. Beschreibung der Ausgangssituation Sollzustand, d.h. Beschreibung der Aufgabenstellung Anforderungen an den Projektablauf Allgemeine Hinweise Anlagen 64

65 Anforderungsdefinition-Lastenheft Gliederung eines Lastenhefts nach VDI/VDE-Richtlinien 1 Einführung in das Projekt 1.1 Veranlassung 1.2 Zielsetzung des Automatisierungsvorhabens 1.3 Projektumfeld 1.4 Wesentliche Aufgaben 1.5 Eckdaten für das Projekt 2 Beschreibung der Ausgangssituation (Istzustand) 2.1 Technischer Prozess 2.2 Automatisierungssystem 2.3 Organisation 2.4 Datendarstellung und Mengengerüst 3 Aufgabenstellung (Sollzustand) 3.1 Kurzbeschreibung der Aufgabenstellung 3.2 Gliederung und Beschreibung der Aufgabenstellung (Anforderungen) 3.3 Ablaufbeschreibung (Verknüpfung der Aufgaben untereinander) 3.4 Datendarstellung und Mengengerüst 65

66 Anforderungsdefinition-Lastenheft Gliederung eines Lastenhefts (2) 4 Schnittstellen 4.1 Schnittstellenübersicht 4.2 Technischer Prozess-Rechner 4.3 Mensch-Rechner 4.4 Rechner-Rechner 4.5 Anwendungsprogramm-Rechner 4.6 Anwendungsprogramm-Anwendungsprogramm 5 Anforderungen an die Systemtechnik 5.1 Datenverarbeitung 5.2 Datenhaltung 5.3 Software 5.4 Hardware 5.5 Hardwareumgebung 5.6 Technische Merkmale des Gesamtsystems 5.7 Instandhaltung und Softwarepflege 66

67 Anforderungsdefinition-Lastenheft Gliederung eines Lastenhefts (3) 6 Anforderungen für die Inbetriebnahme und den Einsatz 6.1 Dokumentation 6.2 Montage 6.3 Inbetriebnahme 6.4 Probebetrieb, Abnahmen 6.5 Schulung 6.6 Betriebsablauf 6.7 Instandhaltung und Softwarepflege 7 Anforderungen an die Qualität 7.1 Software-Qualität 7.2 Hardware-Qualität 8 Anforderungen an die Projektabwicklung 8.1 Projektorganisation 8.2 Projektdurchführung 8.3 Konfigurationsmanagement 67

68 Anforderungsdefinition-Lastenheft Ein gute Lastenheft muss vor allem für Ingenieure verständlich sein wird nach der Implementierung nicht mehr benötigt zeigt ausschließlich die funktionalen Anforderungen auf beinhaltet vorwiegend die Wunschanforderungen der Auftraggeber 68

69 Anforderungsdefinition-Glossar Glossar definiert und erläutert Begriffe, um eine einheitliche Terminologie sicherzustellen. Beispiel: Kundensachbearbeiter: Verantwortlich für die Kommunikation mit Kunden und Firmen einschließlich der Auskunftserteilung und Buchung. Wichtig ist, dass die in der jeweiligen Branche üblichen Begriffe verwendet werden, die insbesondere auch für den Produkt- Benutzer verständlich sind. Die Glossarbegriffe werden sowohl für die Benutzungsoberfläche als auch für die Online- Hilfe und das Benutzerhandbuch verwendet. 69

70 Requirement-Tracing Traceability= Verfolgbarkeit, Nachweisbarkeit Ursprungs-Verfolgbarkeit Anforderungen <-->Personen, die Anforderungen vorgeschlagen haben Anforderungs-Verfolgbarkeit Anforderungen <-->abhängige Anforderungen Entwurfs-Nachweisbarkeit Anforderungen <-->Entwurf Test-Nachweisbarkeit Anforderungen <-->Test Code-Nachweisbarkeit Anforderungen <-->Code 70

71 Requirement-Tracing Änderung der Anforderungen Gründe: Die Priorität der Anforderungen ändert sich während des Entwicklungsprozesses Kunden setzen Anforderungen auf Grund wirtschaftlicher und finanzieller Randbedingungen durch, die im Konflikt mit den Anforderungen des Endbenutzer stehen können Die betriebliche und technische Umgebung des System ändert sich während der Entwicklung 71

72 Requirement-Tracing Änderungsmanagement der Anforderungen Änderungsmanagement der Anforderungen beschäftigt sich mit der Verwaltung der Anforderungen während des Requirements Engineering und der Systementwicklung. Anforderungen sind unvermeidbar unvollständig und inkonsistent Neue Anforderungen treten während des Prozesses auf, da sich Geschäftsziele ändern oder ein besseres Verständnis des Systems entwickelt wurde. Verschiedene Sichten haben verschiedene Anforderungen und diese sind oft widersprüchlich. 72

73 Requirement-Tracing CASE-Werkzeugunterstützung Anforderungsarchivierung Anforderungen sollten in Datenbank gespeichert werden. Änderungsmanagement Der Prozess des Änderungsmanagements ist ein Workflow-Prozess, in dem Phasen definiert und der Informationsfluss zwischen diesen Phasen teilweise automatisiert werden kann. Traceability -Management Automatische Abfrage der Verweise zwischen den Anforderungen Beispiele: Caliber-RM von Borland und DOORS von Telelogic 73

74 Systemanalyse Systemanalyse Grundprinzipien Systemmodelle Analysemethoden Systemanalyse bedeutet: Abgrenzung des Systems gegenüber der Umgebung Entwicklung eines detaillierten Verständnisses des Systems Erstellung einer Systembeschreibung in Form von Systemmodellen Die Systemanalyse basiert im Wesentlichen auf der Modellierung. Ein Modell ist eine abstrakte Systemsicht. Analysemethoden integrieren verschiedene Systemmodelltypen. 74

75 Systemanalyse Lernziele Wissen, was man unter der Systemanalyse versteht Die Grundprinzipien der Systemanalyse erklären können Wissen, was Systemmodelle sind und welche Arten es gibt Wissen, welche Analysemethoden es gibt 75

76 Systemanalyse- Grundprinzipien Präzisierung der Anforderungsdefinition Ausgangspunkt Anforderungsdefinition (Lastenheft / Pflichtenheft) Ziele der Systemanalyse Abgrenzung des Systems von seiner Umgebung Detailliertes Verständnis der Systemfunktionalität Erstellung einer Systembeschreibung basierend auf einem oder mehreren Systemmodellen 76

77 Systemanalyse Hauptprobleme bei der Systemanalyse Verständnis über das Problemgebiet Kommunikation mit Nicht-DV-Spezialisten Ständige Änderung der Anforderungen durch neue Erkenntnisse Erkennung von Gemeinsamkeiten Aufteilung von Arbeiten Systemanalyse benötigt ein sehr gute, erfahrene Entwickler (Systemanalytiker). Er vermitteln zwischen: Kunde/Nutzer, der bestimmt, was gemacht werden soll Entwickler, der die Realisierung durchführt 77

78 Systemanalyse Definition: Die Systemanalyse ist die Untersuchung eines Problemgebiets mit dem Ziel das beobachtbare Verhalten zu beschreiben, das gewünschte Verhalten konsistent, vollständig und realisierbar zu formulieren und die funktionalen Eigenschaften sowie die quantifizierbaren Leistungsparameter mit einzubeziehen. Die größte Teil der Systemanalyse passiert in der Definitionsphase, nachdem die Anforderungsdefinitionen abgeschlossen sind. 78

79 Projektmanagement Projektmanagement Projektplanung Projektabwicklung Zusammenfassung: Gutes Projektmanagement ist entscheidend für den Projekterfolg Die immaterielle Natur der Software verursacht Probleme für das Management Manager haben verschiedene Aufgaben, aber ihre wichtigsten sind: Personalführung, Planung und Verfolgung Planung, Abschätzung und Terminverfolgung sind iterative Prozesse, die sich durch das gesamte Projekt ziehen Ein Projektmeilenstein ist ein vorhersehbarer Zustand, der einen formalen Fortschritt symbolisiert 79

80 Abschluss der Planungsphase Der Abschluss der Planungsphase besteht aus dem Entscheid, mit dem Projekt fortzufahren oder hier abzubrechen. (go oder no-go/stop) Die Ergebnisse der Durchführbarkeitsstudie sind: Lastenheft (grobes Pflichtenheft), Glossar Projektkalkulation : Nicht trivial (Zur Ermittlung der Erstellungskosteneines Software-Produkts werden in der Planungsphase nur einfache Aufwandschätzmethodenangewendet) z.b. Projektplan 80