Institut für Wirtschaftsinformatik und Neue Medien Ludwig-Maximilians-Universität München -1- Gastvortrag - Prof. Dr. Peter Buxmann, TU Darmstadt

Transkript

1 Institut für Wirtschaftsinformatik und Neue Medien Ludwig-Maximilians-Universität München SS 2007 : Vorgehensmodelle zur Softwareentwicklung Prof. Dr. T. Hess -1- Vorlesungsübersicht SS 2007 VL Datum Thema Einführung Bedeutung der IT im Unternehmen Strategische Ausrichtung der IT Organisation der IT Gastvortrag - Prof. Dr. Peter Buxmann, TU Darmstadt IT-Management Wirtschaftlichkeitsanalyse IT-Controlling Vorgehensmodelle zur Softwareentwicklung Klassische Instrumente I - Prozess- bzw. datenorientierte Modellierung Gastvortrag - Joachim Fischer, integranova GmbH Klassische Instrumente II - Entwurf von Datenbanken IT-Entwicklung Neue Instrumente I - Objektorientierte Fachkonzeption Neue Instrumente II - Objektorientierte technische Konzeption Reserve Vorlesung 1

2 Agenda 1. Modellierungsgrundlagen 2. Vorgehensmodelle 3. Computer-Aided Software Engineering (CASE) Modellierung - Einführung Wirklichkeitsausschnitt / Gegenstand Homomorphismus (Gleichförmigkeit, Strukturgleichheit) Modell Rückwirkung? Abhängig von Zweck Modellierungsmethode Modellierungssemantik

3 Modellierung - Einführung Modell 1 Modell n Mitarbeiter sind Abteilungen zugeordnent, können aber an mehreren Projekten partizipieren. If mitarb='meiser' then x:= 0;... else call lohnber ; while... do... Problem Problem Lösung Lösung Komplexreduktion durch Folge von Modellen Modellierung - Einführung Vereinfachende Abbildung (abstrakte Repräsentation) eines Wirklichkeitsausschnittes / Gegenstands Abhängig von dem verfolgten Zweck bzw. der Sichtweise Eingeschränkt durch die Modellierungsmethode bzw. die entsprechenden Modellierungskonstrukte (z.b. UML, epk, ERM) Beachtung von Grundsätzen ordnungsmäßiger Modellierung Subjektiver Prozess (in der Regel nicht automatisierbar) Dient insbesondere der Bewältigung von Komplexität Voraussetzung für eine informationstechnische Umsetzung Basiert in der Regel auf Abstraktion (Verallgemeinerung, Loslösung vom Konkreten, Theoretisierung): Typisierung relevanter Sachverhalte Nicht-Abbildung irrelevanter Aspekte Unternehmensmodellierung: Das Unternehmen bzw. betriebliche Gegebenheiten stellen den betrachteten Wirklichkeitsausschnitt dar

4 Modellierung in der Softwareentwicklung Wirklichkeit Fachliches Problem Fachkonzept DV-Konzept Betrieb Implementierung Informationstechnik Modellierung in der Softwareentwicklung fachlich dv-technisch Analyse -> Entwurf -> Implementierung natürlichsprachlich formalisiert/ausführbar Komplexitätsreduktion durch Bildung von Entwicklungsstufen

5 Modellierung in der Softwareentwicklung Komplexitätsreduktion durch Sichtenbildung Modellierung - Klassifikationsmerkmale Betrachtungsgegenstand Zweck / Charakter: Beschreibung, Erklärung, Gestaltung Sicht: Daten, Funktionen, Prozesse, Detaillierung (Granularität) Betrachtungsebene: fachlich, DV-, Implementierung Individualität: unternehmensspezifisch vs. Referenz Abstraktionsgrad: Ausprägung, Typ, Meta Formalisierung: nicht formal, semi-formal, formal Integration: Sichten, Ebenen, Gegenstand, Detaillierung,

6 Modellierung Zweck/Charakter Aufgaben der Wirtschaftsinformatik: Beschreibung, Erklärung, Gestaltung,... Modellierung kann verschiedenen Zwecken dienen Modellcharakter: Vorbild (Soll) vs. Nachbild (Ist) Beispiele für konkrete Zwecke: Gestaltung von Informationssystemen / Softwareentwicklung Planung einer integrierten Datenhaltung Dokumentation / Analyse / Verbesserung von Geschäftsprozessen Unterstützung von Konfiguration und Einführung von Standard-Anwendungssoftware Simulation einer neuen Fertigungsanlage Ableitung von (objektivem) Informationsbedarf Wissensmanagement Prozesskostenrechnung Agenda 1. Modellierungsgrundlagen 2. Vorgehensmodelle 3. Computer-Aided Software Engineering (CASE)

7 Softwareentwicklung - Einführung Gründe für ingenieurmäßiges Vorgehen bei der Softwareentwicklung aufgrund hoher Komplexität: Das Produkt ist immateriell: Man kann es nicht berühren. Der Manager ist abhängig von der Dokumentation, um den Entwicklungsfortschritt einschätzen zu können. Hoher Grad an Abstraktion, bei gleichzeitig niedrigem Grad an Normierung. Es gibt kein 100%ig klares Verständnis vom Entwicklungsprozess ( Nichts ist vorhersagbar ), da sich die zugrunde liegenden Technologien sehr schnell wandeln und sich im Laufe des Entwicklungsprozesses neue Erkenntnisse ergeben. Oft sehr spezialisierte Aufgabenverteilung, welche eine schnelle Austauschbarkeit von Mitarbeitern oft unmöglich macht. Planvolles, systematisches Vorgehen notwendig (Projektmanagement) Softwareentwicklung findet zumeist in der Projektsituation statt mit vielen Mitarbeitern und hohem Kommunikationsaufkommen, intensiven Kundenkontakten zur Anforderungsbestimmung Zerlegung in Aufgabeneinheiten: sowohl inhaltlich (Abstraktionsebene) als auch zeitlich (Phasen) Diese Zerlegung bezeichnet man als Vorgehens- bzw. Prozessmodell, Das zum Verständnis vor der Situation (Theorie) und zur Anleitung in der Situation (Methode) dient. BMBF-Studie 2000: Anwendung von Vorgehensmodellen in Unternehmen Quelle: Broy, M. / Rombach, D., et al. (2000): Studie für das BMBF: Analyse und Evaluation der Software-Entwicklung in Deutschland, Dezember Primärbranche: Softwareunternehmen Sekundärbranchen: Unternehmen aller Anwendungsbranchen (z.b. TK, Maschinenbau, Banken und Versicherungen, etc.)

8 Phasenkonzept und Vorgehensmodelle der Softwareeigenentwicklung Verschiedene Vorgehensmodelle des Software Engineerings: Phasenkonzept als konzeptionelle Basis Planung Analyse Entwurf Implem. Einf. & Wartung Wasserfallmodell V-Modell Spiralmodell/ Prototyping Generelles Phasenkonzept Dokumentation Planungsphase Potentielle DV-Projekte, Lastenheft Definitionsphase Pflichtenheft Entwurfsphase Fach- und DV-techn. Entwurf Implementierungsphase Programmcode Abnahme- und Einführungsphase Kernidee Ein Softwareprojekt lässt sich in klar abgrenzbare Phasen zerlegen Phasen können einzeln abgearbeitet werden Über alle Phasen sollte eine Dokumentation angefertigt werden, um später das Vorgehen leichter verstehen zu können Legende Phase Getestete Anwendung Wartungsphase Modifizierte Programme (Zwischen-) Ergebnis Phase

9 Ausprägung 1a: lineares Wasserfallmodell ( stagewise model ) Problem Problem Planungsphase Planungsphase Definitionsphase Definitionsphase Entwurfsphase Entwurfsphase Kernideen Sequenzielle Stufen: Jede Aktivität ist in der richtigen Reihenfolge und in der vollen Breite vollständig durchzuführen. Jeder Aktivität muss beendet sein, bevor die nächste anfängt. Am Ende jeder Aktivität steht ein fertig gestelltes Dokument. Top-Down-Vorgehen : Ergebnisse einer Phase fallen wie bei einem Wasserfall in die nächste Phase Benutzerbeteiligung nur in der Definitionsphase. Betrieb Betrieb Ausprägung 1b: Wasserfallmodell mit Rückkopplungsschleifen -18- System-Zulässigkeit Validation Software-Anforderungen Validation Produkt-Entwurf Validation Detail-Entwurf Validation Nachteile Nicht immer ist es sinnvoll, alle Entwicklungsschritte in der vollen Breite, vollständig und sequenziell durchzuführen. Risikofaktoren werden u.u. zu wenig berücksichtigt, da immer der einmal festgelegte Entwicklungsablauf durchgeführt wird. Dies kann auch zu Inflexibilitäten gegenüber neuen Entwicklungen führen. Code Integration Validation Validation Implementierung Wartung Validation Validation -17- Implementierungssphase Implementierungssphase Abnahme Abnahme und und Einführung Einführung

10 Ausprägung 2: V-Modell Das V-Modell integriert die Qualitätssicherung in das Wasserfall-Modell. Die Verifikation und Validation der Teilprodukte sind Bestandteile des V-Modells: Verifikation: Wird ein korrektes Produkt entwickelt? Validation: Wird das richtige Produkt entwickelt? Anwendungsszenarien Testfälle Testfälle Validierung Verifikation Tests -19- Anforderungsdefinition Grobentwurf Feinentwurf Modulimplementation Modul- Test Ausprägung 2: V-Modell Das V-Modell ist in vier Submodelle gegliedert: Systemerstellung (SE), Qualitätssicherung (QS), Konfigurationsmanagement (KM) und Projektmanagement (PM) PM Projekt planen und kontrollieren SEU = Software- Entwicklungs-Umgebung Voraussetzungen schaffen und die SEU bereitstellen Istdaten Plandaten SEU Plandaten Plandaten Istdaten Istdaten QS- Ergebnis QS- Anforderungen vorgeben Produkte prüfen QS- Anforderungen SE Produkt entwickeln Konfigurationsstruktur Produktstruktur planen Produkte/ Rechte verwalten QS Produkt/Rechte KM Integrationstest Systemtest Abnahmetest -20-

11 Ausprägung 3: Spiralmodell/Prototyping Verzicht auf vollständige Spezifikation des fachlichen- und DVtechnischen Konzepts Entwurfsphase Implementierungsphase Schnelle Entwicklung eines ersten ablauffähigen Prototypen des Anwendungssystems Prototyp enthält i.d.r. nur wesentliche Funktionen die Benutzungsoberfläche des späteren Anwendungssystems Planungsphase Prototyp 1 Prototyp 2 Prototyp 3 Das vollständige Anwendungssystem wird sukzessive in enger Zusammenarbeit mit der Fachabteilung entwickelt Definitionsphase Abnahmephase/ Benutzertest -21- Ausprägung 3: Spiralmodell/Prototyping Kombination von Prototyping und phasenorientiertem Vorgehen Planung von Anwendungssystemen Prototyping vollständige fachliche Konzeption Bau von Prototypen vollständige DVtechnische Konzeption Abstimmen der Benutzungsoberfläche mit dem Anwender Realisierung von Anwendungssystemen -22-

12 Extreme Programming als Alternative (1) Extreme Programming ist eine Variante der sog. Agilen Softwareentwicklung Extreme Programming (XP) ist ein Prozeß zum schnellen Programmerstellen in unsicherem Umfeld Antwort auf übermäßige Prozessmodellierung der 90er Eigenschaften: Arbeiten in kleinen Gruppen (max. 10 Personen) Kurzfristige Planung (bis zum nächsten Termin) Konzentration auf das, was gemacht werden muss Flexibilität ist Trumpf! Extreme Programming als Alternative (2) Das XP-Vorgehensmodell Stories Mitarbeiter neu einteilen Komplexes Problem einfache Lösung Test nicht bestanden Hilferuf Neue Paarbildung Neue Aufgabe Paarbildung Test entwerfen Test bestanden Programmieren in Paaren Neue Tests Neue Features Kontinuierliche Integration Zu komplexer Code Abnahmetest erfolglos Vereinfachter Code Gnadenloses Umstrukturieren Alle Tests bestanden Abnahmetest Abnahmetest erfolgreich Abnahme

13 Extreme Programming als Alternative (3) Eigenschaften des XP-Vorgehensmodells Teil I Stories (Szenarien) treiben den Entwicklungsprozeß: Eine Story beschreibt einen konkreten Vorfall, der für den Betrieb des Produktes notwendig ist. Beispiel eine Parkhaus -Story: Der Fahrer bleibt an der geschlossenen Schranke stehen und fordert einen Parkschein an. Hat er diesen entnommen, öffnet sich die Schranke. Der Fahrer passiert die Schranke, die sich dann wieder schließt. Weitere Situationen (volles Parkhaus, Stromausfall... ) werden ebenfalls durch eigene Stories beschrieben. Zu jeder Story wird ein Testfall entworfen (der die Funktionalität der Story abdeckt. Die Entwicklung ist beendet, wenn alle Testfälle erfüllt sind. Extreme Programming als Alternative (4) Eigenschaften des XP-Vorgehensmodells Teil II Pair Programming (Programmieren in Paaren) sorgt für ständiges Gegenlesen durch den Partner Häufiger, ständiger Rollenwechsel (Programme schreiben/lesen) Teams werden stets neu zusammengestellt Auch der Kunde kann so beteiligt sein Ständiges automatisches Testen sorgt dafür, dass Funktionalität erhalten bleibt Für jede neue Funktionalität gibt es einen Testfall Testfälle werden vor dem Programm geschrieben Jeder kann jederzeit die Software umstrukturieren (refactoring) Software muss entsprechend wandlungsfähig sein Testfälle müssen weiterhin erfüllt werden Code-Qualität muss auf hohem Niveau bleiben

14 Extreme Programming als Alternative (5) Einsatzbedingungen von XP Programming Extreme Programming ist geeignet... wenn die Anforderungen vage sind wenn die Anforderungen sich schnell ändern wenn das Projekt klein bis mittelgroß ist (< Programmierer) Extreme Programming ist ungeeignet... wenn es auf beweisbare Programmeigenschaften ankommt wenn späte Änderungen zu teuer werden wenn häufiges Testen zu teuer ist wenn das Team zu groß oder nicht an einem Ort ist Exkurs Einführung von betrieblicher Standardsoftware : Vorgehen (1) 1: Planungsphase 2: Analysephase 3: Auswahlphase 4: Realisierungsphase 5: Einführungsphase 6: Wartungsphase

15 Exkurs Einführung von betrieblicher Standardsoftware : Vorgehen (2) Phase 1. Planungsphase 2. Analysephase Inhalt und Ergebnisse Identifikation und Abgrenzung des zu unterstützenden Ausschnitts aus dem Unternehmen; Projektplanung, Bereitstellen von Ressourcen, Zieldefinitionen; Wirtschaftlichkeitsbetrachtungen Ist-Analyse, d.h. strukturierte Erfassung der bestehenden Ablauf- und Aufbauorganisation sowie der eingesetzten Informationssysteme, Schwachstellenanalyse sowie qualitativen und ökonomischen Aspekten; Erstellung eines fachlichen Soll-Konzepts in Form eines Pflichtenheftes, bestehend aus Funktions-, Prozess- und konzeptionellen Datenmodellen; Analyse des relevanten Softwaremarktes Vorauswahl, Reduzierung der weiterverfolgten Produkte auf maximal drei bis fünf; Feinauswahl, Entscheidung für eine der Alternativen; Vertragsgestaltung und -abschluss 4. Realisierungsphase Anpassung der Standardsoftware an die Anforderungen 5. Einführungsphase 6. Wartungsphase Installation der Standardsoftware in der produktiven Umgebung; Benutzerschulung Produktiver Einsatz des Systems; Wartung, d.h. Beseitigung von Fehlern und Weiterentwicklung bzw. Anpassung der Funktionalität durch neue Anforderungen, meist in Form von neuen Programmversionen (Releases) -29- Agenda 1. Modellierungsgrundlagen 2. Vorgehensmodelle 3. Computer-Aided Software Engineering (CASE) 3. Auswahlphase -30-

16 CASE-Tool-Unterstützung (1): Entwicklungen im Software-Engineering CASE-Tools (= Computer-Aided Software Engineering) unterstützen den Softwareentwicklungsprozess in einzelnen Phasen oder phasenübergreifend. Entwicklung zu einer fortschreitenden Integration von phasenbezogenen zu phasenübergreifenden CASE-Tools. Methoden Strukturierte Programmierung Strukturiertes Design Strukturierte Analyse Software Engineering Methoden Engineering Werkzeuge Höhere Programmiersprachen Interaktive Test- Werkzeuge Lower CASE Upper CASE Integrated CASE Meta- CASE Quelle: Heym, M. (1993), S GLs IPSE -31- CASE-Tool-Unterstützung (2): Konkrete Beispiele Analysephase Entwurfsphase Implementierungsphase Testphase Rational Rose (IBM) ARIS (IDS Scheer) Eclipse (IBM), JBuilder (Borland) -32-

17 Vorlesungsablauf Softwareentwicklung In den nachfolgenden Vorlesungen werden die Sicht Prozesse : Fachkonzept (Analyse), die Sicht Daten : Fachkonzept (Analyse) und DV-Konzept (Design) sowie die objektorientierte Sicht auf zu entwickelnde computergestützte Informationssysteme besprochen, welche durch nebenstehende Modellierungssemantiken bzw. Werkzeuge modelliert werden können. Analyse Design Implementierung Klassische Verfahren Prozesse: epks Daten: ERM Daten: Normalisierung Neuere Verfahren OO-Sicht: Statische UML- Diagramme OO-Sicht: Statische u. dynamische UML-Diagramme OO-Sicht: Softwarecode -33- Literatur Balzert, H. (2000): Lehrbuch der Softwaretechnik: Software-Entwicklung, Spektrum Akademischer Verlag, Heidelberg, Berlin: Überblickdarstellungen: S (im Semesterapparat) Balzert, H. (1998): Lehrbuch der Softwaretechnik: Software-Management, Software- Qualitätssicherung, Unternehmensmodellierung, Spektrum Akademischer Verlag, Heidelberg, Berlin: Vorgehensmodelle: S (im Semesterapparat) -34-