Grundlagen von Software- Entwicklungsprozessen

Transkript

1 Grundlagen von Software- Entwicklungsprozessen Oliver Hummel Seite 1

2 Zur Erinnerung: Software Process A process is a structured set of activities required to develop a software system Differences in Software Processes in number, nature and coordination of process steps number and nature of developed products A software process model is an abstract representation of a process It presents a description of a process from some particular perspective Generic development activities include Specification Design Development Validation Evolution Seite 2

3 Abgrenzung: Business Process Ein Geschäftsprozess (business process) ist ein Vorgang oder Ablauf (von Einzeltätigkeiten), der einem betriebswirtschaftlichen Geschäftsoder Unternehmensziel dient Ein Geschäftsprozess besteht aus einer Reihe von Aktivitäten, die parallel oder nacheinander ausgeführt werden Aktivitäten können manuell oder automatisiert ausgeführt werden Ein Geschäftsprozess kann innerhalb eines Unternehmens stattfinden oder die Unternehmensgrenzen überschreiten Beispiel: Das Anmelden eines Kunden bei einer Kreditkartenfirma, die Überprüfung seiner Daten und das Ausstellen und Zusenden seiner Kreditkarte Seite 3

4 Abgrenzung: Workflow Ein Workflow ist ein teilweise oder vollständig automatisierter Geschäftsprozess dient der Koordination von Aktivitäten, die von verschiedenen Mitarbeitern ausgeführt werden die Aktivitäten werden dabei von einem Workflow-Management-System verwaltet Ein Workflow hat einen eindeutig definierten Anfang und ein Ende sowie ablaufsteuernde Regeln Beispiel: Ein Patient kommt für eine OP in ein Krankenhaus und muss davor und danach verschiedene Untersuchungen über sich ergehen lassen. Je nach Art der OP wird dieser Ablauf von einem Workflow-Management- System gesteuert. Seite 4

5 Vorgehensmodelle... empfehlen Richtlinien für Rollen (Verantwortlichkeiten) Aufgaben Dokumente (Artefakte, Arbeitsergebnisse) Aktivitäten Phasen Methoden [[Bunse/v. Knethen]] Seite 5

6 Generische Elemente von Vorgehensmod. Rollen Kunden stellen Finanzen Nutzer verwenden das Software-System Entwickler erstellen die Software. Prozess-Beschreibung formal oder informell als Teil der Firmenkultur Grundsätzliche Schritte Zu durchlaufende Phasen (vgl. nächste Folie) Zwischenprodukte Verschiedene Dokumente und Prototypen Kontrollmechanismen Wie wird kontrolliert, gemessen und wie werden Fehler gefunden und behoben? Seite 6

7 Common Phases Analysis study, understand and specify the system requirements (services, constraints, goals ) Design study, understand and design the system architecture Identify and describe the fundamental software system abstractions and their relationships Implementation and unit testing create individual code units and verify that each fulfills its responsibilities Integration and system testing Integrate and test increasingly large modules, up to the level of the system as a whole Deliver validated system to the customer Operation and maintenance System is installed and put into practical use update software to correct errors, improve implementation and satisfy new requirements Seite 7

8 Versch. Benennungen von SE-Phasen Anforderungsanalyse Modellierung Entwurf Implementierung Komponententest Systemintegration FU Berlin 1995 Req. Analysis and System Specification System Design Class Design Implementation TU München 1997 Overall Req. Definition Functional Req. Specification Design Specification Prototype Efficient Software TU Berlin 1990 Seite 8

9 Generische vs. Software Prozesse Generisch Allgemeine Produktentwicklung Software Spezifikation Anforderungen und Einschränkungen Entwurf Papiermodell des Systems Produktion Herstellung des Systems Test Überprüfung auf Erfüllung der Anforderungen Installation Auslieferung an den Kunden Wartung - Fehlerbehebung Unvollständige Spezifikationen sind oft normal Fließende Übergänge zwischen Spezifikation, Entwurf und Implementierung Keine physische Realisierung des Systems zum Test Software altert nicht Kein einfacher Austausch von Teilen Die Produktion einer Software kann vernachlässigt werden Seite 9

10 Software Specification The process of establishing what services are required and the constraints on the system s operation and development Requirements engineering process Feasibility study Requirements specification Requirements elicitation and analysis Requirements validation [Sommerville] Seite 10

11 Software Design and Implementation The process of converting the system specification into an executable system Software design Design a software structure that realises the specification Implementation Translate this structure into an executable program The activities of design and implementation are closely related and may be inter-leaved Seite 11

12 Design process activities Architectural design Component design Abstract specification Data structure design Interface design Algorithm design Seite 12

13 Structured Methods Systematic approaches to developing a software design The design is usually documented as a set of graphical models Possible models Object model Sequence model State transition model Structural model Data-flow model Seite 13

14 Programming and Debugging Translating a design into a program and removing errors from that program Programming is a personal activity there is no generic programming process Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process Seite 14

15 Software Validation Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the system customer. Involves checking and review processes and system testing System testing involves executing the system with test cases derived from the specification of the real data to be processed by the system Seite 15

16 Testing phases Seite 16

17 Software Evolution Software is inherently flexible and can change As requirements change through changing business circumstances, the software that supports the business must also evolve and change Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new Seite 17

18 Verteilung der Entwicklungs- und Fehlerkosten für Individualsoftware Boehm s first law: [Endres/Rombach] Errors are most frequent during requirements and design activities and are the more expensive the later they are removed. Seite 18

19 Anwendung von Vorgehensmodellen Software Entwicklung ist ein Prozess, der auf einem Vorgehensmodell basieren sollte Verschiedene Vorgehensmodelle haben verschiedene Stärken es gibt kein Modell für alle Lebenslagen Nicht immer sind alle Vorgaben eines Vorgehensmodells auch für alle Organisationen notwendig daher kann das Customizing eines Modells sinnvoll werden Anpassung eines Vorgehensmodells erfolgt meist iterativ über mehrere Projekte => Vorgehensmodell wird zum firmeninternen Referenzmodell Das V-Modell XT sieht das Customizing explizit vor möchte durch extreme Tailoring allen Anforderungen gerecht werden Seite 19

20 Team-Arbeit Große Software-Projekte erfordern Team-Arbeit teilweise müssen hunderte von Mitarbeitern koordiniert werden Vorgehensmodelle müssen daher Zusammenarbeit nach folgenden Prinzipien ermöglichen Aufgabenteilung für Spezialisten Paralleles Arbeiten Verfolgbarkeit von Beziehungen zwischen Aufgaben Einige Probleme, die in diesem Zusammenhang auftreten können: konträre Ansichten zwischen Teammitgliedern schlechtes Management spät erkannte Anforderungen Anforderungen an den Prozess, nicht nur an das Produkt Seite 20

21 Erwarteter Nutzen von Vorgehensmodellen Auf Grund der genannten Empfehlungen von Vorgehensmodellen wird folgender Nutzen erwartet Planungssicherheit vergleichbare Produkte vergleichbar erstellen Effizienz nichts vergessen, Nachbearbeitungen reduzieren Kostenreduzierung Fehler schnell erkennen, Fehlentscheidungen vermeiden Qualität von Anfang an ein kontrolliertes Vorgehen verwenden Seite 21

22 Some Software Process Models The waterfall model The "V" model Evolutionary development Formal systems development Cleanroom Prototypical Development Reuse-based development Iterative and incremental development RUP Spiral model Agile development Scrum, XP, Crystal, etc. Seite 22

23 Bringing Order to Process Models Sequenzielle Modelle Wasserfall-Modell V-Modell ältere Phasenmodelle Formale Entwicklungsmodelle Prototypische Modelle Wiederholende Modelle Spiralmodell Inkrementelle Modelle Agile Entwicklungsansätze Scrum, XP, Crystal, FDD... Evolutionäre Modelle Wiederverwendungsorientierte Modelle Rekursive Modelle KobrA Seite 23

24 Entwicklungsparadigmen Die meisten Vorgehensmodelle setzen ein bestimmtes Entwicklungsparadigma voraus also die Denkweise der später eingesetzten Programmiersprache(nfamilie) Die existierenden Paradigmen lassen sich in zwei Klassen einteilen imperative Paradigmen WIE soll etwas berechnet werden Ein Programm ist eine lineare Abfolge von Befehlen deklarative Paradigmen WAS soll berechnet werden keine Seiteneffekte Korrektheitsbeweise möglich (vgl. Lamda-Kalkül) bekannt sind vor allem funktionale (LISP) und logische Programmierung (Prolog) Seite 24

25 Imperative Programmierparadigmen Strukturierte Programmierung Goto Statement Considered Harmful [Dijkstra 1968] Alle Programme werden über drei Arten von Anweisungen formuliert Sequenz Verzweigung Wiederholung Prozedurale Programmierung Code wird in wiederverwendbare Teileinheiten aufgespalten Modulare Programmierung Funktionalität und Daten werden in sog. Modulen zusammengefasst Objektorientierte Programmierung Software-Objekte werden an Konzepten aus der wahren Welt orientiert Daten und Funktionalität werden eng in sog. Objekte gekapselt Objekte interagieren durch Nachrichten-Austausch Seite 25

26 What is an Object? [Booch 91] Booch s hypothesis: Object model reduces communication problems between analysts and users. Seite 26

27 Aspect-Oriented Programming (AOP) AOP zielt darauf ab sog. crosscutting Concerns oder logische Aspekte aus Klassen herauszulösen d.h. solche Concerns werden separat entwickelt und von einem Tool in das System gewebt ; sie ersparen damit Wartungsaufwand wie hier am Beispiel eines Hauses einmal werden nur die blauen Concerns gezeigt (z.b. die Wasserleitungen) und einmal nur die orangenen (z.b. die Heizungsrohre) Seite 27

28 good modularity [AspectJ presentation] socket creation in Tomcat colored lines show relevant lines of code fits nicely into one package (3 classes) Seite 28

29 pretty good modularity class loading in Tomcat colored lines show relevant lines of code mostly in one package (9 classes) Seite 29

30 not so good modularity logging in Tomcat scattered across the packages and classes error handling, security, business rules, solution? separation of concerns Seite 30

31 Zusammenfassung Praktisch alle Vorgehensmodelle enthalten Anweisungen für die folgenden Entwicklungsaktivitäten Specification Design Development Validation Evolution...und sollten zusätzlich auch die folgenden Elemente beschreiben Rollen Prozess-Beschreibung Zwischenprodukte Kontrollmechanismen Beim nächsten Mal geht es weiter mit den Eigenschaften von sequentiellen und iterativen Modellen Seite 31