Software Engineering I Grundlagen des Software Engineerings

Transkript

1 Software Engineering I Grundlagen des Software Engineerings Sommersemester 2012, Dr. Andreas Metzger Software Engineering I, SS12, Dennis Wikczynski

2 Motivation komplexe Software wird in allen Bereichen des Lebens benötigt (Eingebettete Software in PKWs und Haushaltsgeräten, Steuerung in der Verkehrs- und Energietechnik, Geschäftsprozesse in fast allen Unternehmen) Software dient als Innovationstreiber (MP3-Player, GPS, ebanking, Youtube, Facebook) Software realisiert in immer größerem Umfang zentrale Produktfunktionalität und wird damit in zunehmendem Maße integraler Bestandteil komplexer Produkte und Dienstleistungen. Systematische, geplante, ingenieurmäßige Softwareentwicklung (d.h. Software Engineering) maßgeblich für den Projekt- und Markterfolg. Ziel des Software Engineering Prinzipien, Techniken, Methoden und Werkzeuge zur Verfügung stellen, um Software zu vorhersehbaren Kosten, in vorhersagbarer Zeit und zu vorhersagbarer Qualität zu produzieren.! Software Engineering I, SS12, Dennis Wikczynski! 2

3 Kapitel 1: Einleitung Essentielle Charakteristiken des Software Engineering Konstruktion von großen Programm-Systemen Komplexitätsbewältigung Regelmässige Kooperation von Menschen Software wird kontinuierlich weiterentwickelt Effizienz, mit der Software entwickelt wird Software muss ihre Benutzer effektiv unterstützen Besonderheiten des Software Engineerings: Software ist ein immaterielles Gut (Konstruktionsfehler sind oft nicht sichtbar, Aufwand für Identifikation und Behebung von Defekten sehr hoch) Kosten werden ausschließlich durch Personalkosten bestimmt (Entwicklungskosten) Qualität des Personals ist ein entscheidender Erfolgsfaktor um Produktivität und Qualität in der Entwicklungsphase zu gewährleisten Inbetriebnahme und Nutzung von Softwaresystemen führt zur Klärung von Anforderungen und Identifikation neuer Anforderungen Ein Software-Ingenieur sollte in der Lage sein verschiedene Abstraktionsebenen (Modellbildung) zu kreieren, diese Modelle und Spezifikationen verwenden können, mit Menschen kommunizieren um unterschiedliche Zielsetzungen umzusetzen und Fähigkeiten im Bereich der Arbeitsplanung und -koordination (Projektmanagement) besitzen! Software Engineering I, SS12, Dennis Wikczynski! 3

4 Kapitel 2: Eigenschaften und Prinzipien von Software Eigenschaften von Software (Überblick) Prozess- vs. Produkteigenschaften Prozesseigenschaften: Charakteristika/ Attribute bezüglich der Erstellung des Produkts (Software-Entwicklungsprozess) Produkteigenschaften: Charakteristika/ Attribute bezüglich des eigentlichen Produkts (Software-Systeme) Externe vs. interne Eigenschaften Extern: Wie gut erfüllt das Produkt die Anforderungen der Nutzer? (Bezieht sich in der Regel auf Ausführung der Software) Intern: Wie gut erfüllt das Produkt die Anforderungen der Software- Ingenieure? (Bezieht sich in der Regel auf Entwicklungsartefakte) Prozess vs. Produkteigenschaften Prozesseigenschaften haben Einfluss auf die Qualität der Produkteigenschaften (in der Praxis werden häufig Produkteigenschaften überprüft, d.h. Beseitigung schlechter Qualität durch Nachbesserung. Eine bessere Lösung wäre die Ursache für die schlechte Qualität zu finden und entsprechende Prozessverbesserung durchzuführen Wichtige Eigenschaften von Software (Übersicht) Korrektheit: Übereinstimmung eines Programms mit seiner (funktionalen) Spezifikation d.h. ist die Korrektheit der Software nachweislich gegeben? Zuverlässigkeit: ist ein relatives Kriterium d.h. zuverlässige Software kann immer noch Defekte aufweisen (mangelnde Zuverlässigkeit wird in manchen Bereichen toleriert ist aber z.b. bei der Steuerung eines AKW eine folgenschwere Angelegenheit)! Software Engineering I, SS12, Dennis Wikczynski! 4

5 Präzisierung: beinhaltet die Fähigkeit des Systems, den Vorstellungen des Benutzers zu genügen ( dependability ) oder die Wahrscheinlichkeit, dass Software innerhalb einer bestimmten Zeitspanne kein Fehlverhalten aufweist ( reliability ) Robustheit: Toleranz gegenüber nicht spezifizierter Bedienung/ nicht spezifizierten Rahmenbedingungen, z.b. Hardwarefehlern oder unerwarteten Benutzereingaben (Beispiel: Flasche Eingaben führen zum Systemabsturz oder eine nichtspezifizierte Nachricht eines Systems führt zum Datenverlust) Performanz: Erfüllung der Anforderungen an Antwortzeitverhalten und ökonomischer Umgang mit Ressourcen (CPU, Hauptspeicher, Netzwerk). Wesentliche Eigenschaften einer Software sollten mit einem Prototypen getestet werden, da spätere Änderungen ein sehr kosten- und zeitintensives Redesign bedeuten könnten Benutzerfreundlichkeit: Intuitive, fehlerrobuste Bedienung der Software unter Umständen beeinflusst durch Gestaltung der Dialoge, einfache Konfigurierbarkeit und einfachem Aufbau und Ablauf Wartbarkeit: Fähigkeit eine Software nach ihrer Auslieferung Anpassungen, Änderungen und Weiterentwicklungen zu ermöglichen (Wartbarkeit hängt stark von der Strukturierung/Architektur ab!). Folgende Wartungs-Arten existieren: Korrektive Wartung: Beseitigung von Fehlern Adaptive Wartung: nachträgliche Anpassung an geänderte Umgebung/ Rahmenbedingungen, z.b. gesetzliche Änderungen, neue Organisation Perfekte Wartung: Verbesserung im Hinblick auf die nicht-funktionale Anforderungen, z.b. Performanz, Ergonomie Enhansive Wartung: hinzufügen von Funktionalität Wiederverwendbarkeit: Einsatzfähigkeit der Software in einem anderen Kontext. Ebenfalls können gewisse Kernfunktionen übernommen werden, in diesem Kontext spricht man von Variabilität. Portierbarkeit: Ergibt sich aus dem Aufwand der nötig ist, um eine Software auf einer anderen Plattform (d.h. Hardware oder Software) lauffähig zu machen. Hohe Portierbarkeit wird durch Kapselung von Plattformabhängigkeiten sowie der Berücksichtigung von Standards (Design Patterns) erreicht. Interoperabilität: Maß für die Fähigkeit eines Systems, mit anderen Systemen zu koopieren. Wird immer wichtiger, da Office-Werkzeuge, Großrechner-Software, Datenmodellierungssoftware etc. diesen Aspekt immer häufiger nutzen. Software Engineering I, SS12, Dennis Wikczynski! 5

6 Prinzipien der Software-Entwicklung Terminologie Prinzip = Grundsatz, den man seinem Handeln zu Grunde legt (Beispiel: Strukturierung der Software in Objekte und Beziehungen) Technik = Vorschrift zur Durchführung einer Tätigkeit (Beispiel: Programmiersprache Java) - Was ist wie zu tun? Methode = Bündelung von Techniken zur Erreichung vorgegebener Ziele (Beispiel: Unified Process) - Was ist wie und unter welchen Rahmenbedingungen zu tun, so dass ein gutes Ergebnis erreicht wird? Werkzeug: Rechnerunterstützung für Techniken und Methoden (Beispiel: Eclipse JDE) Prinzipien Striktheit und Formalität: Strikte ( präzise ) Dokumentation des Software-Prozesses und seiner Ergebnisse (bspw. Anforderungsdefinition, Entwurf, Testfälle, Wartungsdokumente). Ist notwendig für das Verständnis, im Hinblick auf spätere Änderbarkeit und im Hinblick auf Schadenspotential von Missverständnissen Strukturierung: Ziel ist Seperation of concerns also die Unterteilung in Aspekte/ Bereiche und die seperante Behandlung dieser Bereiche (Bsp.: Qualität in Performanz, Robustheit und Korrektheit). Vorteile sind u.a. Überschaubarkeit und Handhabbarkeit, Komplexitätsreduktion Modularität: Ziel ist die Unterteilung eines komplexen Systems in Komponente/Module ( divide and conquer ). Modularität ist dabei Voraussetzung für Wiederverwendung in kleinen Teilen und lokale Änderbarkeit, sowieso Ergebnis der Dekomposition bzw. Grundlage der Komponierbarkeit. Eine gute Modularität wird durch eine hohe Kohäsion, d.h. enger interner Zusammenhalt innerhalb eines Moduls und durch geringe Kopplung, d.h. wenig Wechselwirkungen mit anderen Modulen, erreicht! Software Engineering I, SS12, Dennis Wikczynski! 6

7 Sicherheit: Beinhaltet die Angriffssicherheit (Schutz der Software vor der Umgebung, inkl. User) und die Betriebssicherheit (Schutz der Umgebung von der Software) Abstraktion: Das Ziel ist die Trennung von wichtigen und unwichtigen Merkmalen zum Zweck der Konzentration auf das Wesentliche. Im Software Engineering ist dies beispielsweise das Klassendiagramm, welches von der Programmiersprache abstrahiert. (Für den Anwender ist z.b. die Funktion des User Interfaces relevant und die Architektur der Software nebensächlich) Änderbarkeit: Software unterliegt kontinuierlichen Änderungen oder die einzige Konstante ist die Änderung. Flexible Änderungen können zusätzliche Kundenwünsche, Produktlinien erfüllen aber es besteht auch das Risiko, dass ein Großteil der Software verändert werden muss! Sie gewährleistet konsistente Systeme und wird als Ursache für Wartungsintensität angesehen. Weitere Ursachen für Änderungen: Enhansive Wartung: Erweiterung der Funktionalität basierend auf Erkenntnisgewinn Korrektive Wartung: Beseitigung von Fehlern Perfekte Wartung: Verbesserung nicht-funktionaler/qualitäts-eigenschaften Adaptive Wartung: Erweiterung der Funktionalität wegen sich ändernder Rahmenbedingungen! Software Engineering I, SS12, Dennis Wikczynski! 7

8 Allgemeinheit: Beinhaltet das Ziel die Software für verwandte Aufgaben und Zwecke einzusetzen. Die Umsetzung erfolgt zumeist durch Anpassung/Änderung. Allgemeine Software lässt sich beispielsweise bei Rahmenbedingungen einsetzen, welche ständig mit aktuellen Parametern versorgt werden (Allgemeinheit verursacht Aufwand!) Inkrementalität: Gliedert Tätigkeiten in Schritte um nach jedem Schritt entsprechende Rückkopplungen durchzuführen (Beispiel: Es werden einzelne Dialoge entwickelt und abgestimmt, bevor alle Dialoge entwickelt werden). Inkrementalität basiert auf der Erkenntnis, dass während der Entwicklung in aller Regel Änderungen nötig sind, trägt dem Erkenntnisgewinn während der Entwicklung bei und erlaubt Risikominimierung. Es wird grundsätzlich mit den wichtigen Funktionen (Kernfunktionen) begonnen. Imkrementelle SW-Entwicklung: Das zu entwickelnde System bleibt in seinem Gesamtumfang offen; es wird in Ausbaustufen realisiert. Die 1. Stufe ist das Kernsystem. Jede Stufe erweitert das vorhandene System...Mit der Bereitstellung einer Erweiterung ist in aller Regel auch (wie bei der iterativen Entwicklung) eine Verbesserung der alten Komponenten verbunden. Iterative SW-Entwicklung: Es wird in mehreren geplanten und kontrolliert durchgeführten Iterationsschritten entwickelt. Ziel dabei ist, dass in jedem Iterationsschritt - beginnend bei der 2. Iteration - das vorhandene System auf der Basis der im Einsatz erkannten Mängel korrigiert und verbessert wird...! Software Engineering I, SS12, Dennis Wikczynski! 8

9 Kapitel 3: Software-Entwicklungs-Prozesse Begriffsbildung und Abgrenzung Lebenszyklusmodell: Beinhaltet die Festlegung wesentlicher Entwicklungsaktivitäten und ihrer Abhängigkeiten bzw. deren prinzipielle Vorgehensweise Software-Prozessmodell: Definiert Aktivitäten, die in einer Software-Entwicklung durchzuführen sind; die Reihenfolge der Aktivitäten; die Werkzeuge, Methoden und Techniken zur Unterstützung dieser Aktivitäten und die Typen der Artefakte, die erzeugt und verarbeitet werden Software-Prozess: Entspricht der konkreten Durchführung einer Software-Entwicklung und ist gekennzeichnet durch wann und von wem welche Aktivitäten durchgeführt werden und welche Artefakte bei der Durchführung der Aktivität verarbeitet/ erzeugt werden Entwicklungsprojekte können strukturell dermaßen unterschiedliche Anforderungen stellen, dass ein einziges Lebenszyklusmodell nicht für alle Projekte verwendbar ist. Das zum Projekt passende Lebenszyklusmodell muss ausgewählt werden und gegebenenfalls während der Entwicklung angepasst werden (und damit auch am Software- Prozessmodell). Lebenszyklus-Modelle Code and Fix - Modell: (Programmcode schreiben = Code ; Fehler im Programmcode beheben = Fix ) Stellt kein geeignetes Lebenszyklusmodell dar, da Bux-Fixing zu unstrukturiertem Programmcode führt, dies führt zu teuren Wartungskosten, da Code nicht strukturiert, modulär, änderbar und allgemein ist. Es wird also insgesamt zu wenig Strukturierung für große Systeme geboten, Teamarbeit nicht gefördert, Änderungen sind nur schwer umsetzbar und die Produktion wird als nicht zuverlässig, nicht vorhersehbar und nicht effizient genug erachtet Endergebnis erfüllt nicht die Anforderungen der Nutzer = Ablehnung der Software/ Neuentwicklung)! Software Engineering I, SS12, Dennis Wikczynski! 9

10 Wasserfall-Modell: Das Wasserfallmodell ist klar an die Bedürfnisse des Managements ausgerichtet und besitzt Klare (Phasen-) Enden mit eindeutig zugeordneten Ergebnissen (Dokumenten) bzw. Klare Verantwortungen für Phasen. Implementierung erfolgt (im Gegensatz zum Code and Fix ) erst nach Verständnis des Problems. Leider spiegelt die Trennung der Phasen die Natur der Software-Entwickler nicht wieder, soll heißen, dass keine erkenntnisgetriebene Entwicklung stattfindet, Phasen sich zwangsläufig überlappen, Reviews Zeit beanspruchen und das ganze sehr bürokratisch/dokumentenzentriert ist. Die grundlegende Philosophie: keine (späte) Änderungen Spiralmodell: Ziel ist die Minimierung des Risikos, deshalb werden die Festlegung der nächsten Schritte und eine Risikoeinschätzung iteriert. (Iteration = Ziele, Randbedingungen und Alternativen identifizieren; Risiko-Management d.h. Evaluation der Alternativen, Risiko-Einschätzung und Risiko-Behandlung; Entwicklung und Test von Teilergebnissen und Review der Resultate und Planung der nächsten Phase) Vorteile Überprüfung in regelmässigen Intervallen (unter Umständen erneute Festlegung des Prozessablaufs in Abhängigkeit von den Risiken) Flexibles Modell Ein Prozess wird nicht für die gesamte Entwicklung festgelegt Integration anderer Lebenszyklusmodelle als Spezialfälle Fehler und ungeeignete Alternativen werden frühzeitig eliminiert Nachteile Hoher Managementaufwand wegen vieler Entscheidungen bzgl. des Prozessablaufs Für kleine/mittlere Projekte ungeeignet Spiralmodell ist kein Lebenszyklusmodell im engeren Sinne, denn es schlägt keinen konkreten Lebenszyklus vor, es werden gewisse Elemente von Lebenszyklusmodellen in einer allgemeinen Art und Weise angesiedelt! Software Engineering I, SS12, Dennis Wikczynski! 10

11 Prototyping-Modelle: Beruht auf der Annahme/Beobachtung, dass der Anwender die Software zuerst sehen muss bevor er wirklich weiß was er haben will. Sollte Prototyp nur zur Klärung von Anforderungen dienen, dann sollte er mit geringem Aufwand erstellt werden (alleine schon, um die Klärung möglichst früh zu ermöglichen). Man unterscheidet zwischen Wegwerf-Prototypen und Evolutionären/Inkrementellen Prototypen. Die Implementierung der Funktionalität wird in Horizontal und Vertikale Prototypen unterschieden. Wegwerf-Prototypen Dient ausschließlich zur Sammlung von Erfahrungen und/oder zur Klärung von Anforderungen (können quick-and-dirty entwickelt werden) wird nicht Bestandteil des endgültigen Produkts (was eine gewisse Schlampigkeit bei der Realisierung des Prototyps erlaubt) Funktionieren der Software wird anhand von wesentlichen Aspekten erreicht, Details sind nicht notwendig Evolutionäre/Inkrementelle Prototypen Gleicher Zweck wie der Wegwerf- Prototyp, wird aber zum Produkt weiterentwickelt (auf keinen Fall quickand-dirty entwickeln!) Wesentliche Aspekte sind verstanden und können das rudimentäre Funktionieren sicherstellen (andere Aspekte sind unklar wie z.b. Schnittstellen zu anderen Systemen) Dieses Modell muss Qualitätsanforderungen von vornherein berücksichtigen Zielkonflikt: frühe Verfügbarkeit versus Erweiterbarkeit!! Software Engineering I, SS12, Dennis Wikczynski! 11

12 Horizontaler Prototyp realisiert nur spezifische Ebenen des Systems (Benutzerschnittstellen, funktionale Kernebenen wie Datenbanktransaktionen; die betreffende Ebene wird möglichst vollständig realisiert; Bei Benutzerschnittstelle bedeutet dies z.b., dass die gesamte Oberfläche zu sehen ist, aber keinerlei Funktionalität dahintersteht Vertikaler Prototyp realisiert die Implementierung ausgewählter Teile des Zielsystems vollständig durch alle Ebenen hindurch (geeignet, wo Funktionalitäts- und Implementierungsoptionen noch offen sind. In der Regel der Fall, wenn Pilotsysteme gebaut werden) Die Vorteile des Prototyping-Modells liegen darin, dass das Entwicklungsrisiko reduziert wird, Prototypen durch geeignete Werkzeuge schnell erstellt werden können (Modellbasierte Entwicklung, Simulatoren), eine intensive Rücksprache mit dem Kunden ermöglichen und letztendlich auch die Kreativität der Entwickler gefördert wird. Ein Nachteil könnte beispielsweise die Gefahr sein, dass ein Wegwerf-Prototyp aus Ressourcengründen Teil des Endprodukts wird oder der Prototyp als Ersatz für eine wichtige, ausführliche Dokumentation angesehen wird!! Software Engineering I, SS12, Dennis Wikczynski! 12

13 V-Modell (Lebenszyklusmodell): Ist eine Erweiterung des Wasserfallmodells. Integrations- und Prüfungsaktivitäten werden hier nach der Codierung den Entwicklungsaktivitäten gegenübergestellt. Es ist ein bekanntes und weit verbreitetes Lebenszyklusmodell (z.b. auch zur Definition der unterschiedlichen Testebenen). Die Qualitätssicherung erhält den gleichen Stellenwert wie die Konstruktion. Zudem erfolgt eine klare Gegenüberstellung von konstruktiven und prüfenden Aktivitäten. Moderne Lebenszyklus-Modelle ANMERKUNG: Das folgende Kapitel beinhaltet Agile Prozesse und das Service Live-Cycle- Model (S-Cube). Die Agile Prozesse -Folie ist in englischer Form im Skript zu finden, das S-Cube Modell behandle ich an dieser Stell nicht weiter, da eine genaue Beschreibung im 4. Übungsblatt im Aufgabenbereich 4.1 vorgenommen wurde! Software-Prozessmodelle V-Modell der Bundesrepublik Deutschland (Bund): Ist ein verbindliches Regelwerk für den Bereich des Bundesministeriums für Verteidigung (BMVg). Es orientiert sich am V- Modell (Life-Cycle-Modell), ist mittlerweile aber auch für andere Lebenszyklusmodelle anwendbar. Die Grundlegende Idee ist eine Gliederung in vier Tätigkeitsbereiche (4 Submodelle): Systemerstellung; Qualitätssicherung; Projektmanagement und Konfigurationsmangement. Der Prozess der Erstellung von IT-Systemen wird beschrieben durch Aktivitäten, Produkte, Artefakte und Dokumente. Die Beschreibung von Aktivitäten und Produkten erfolgt auf unterschiedlichen Detaillierungsebenen.! Software Engineering I, SS12, Dennis Wikczynski! 13

14 Zu dem bietet das Modell eine umfassende Möglichkeit des Tailorrings (Anpassung an spezifische Bedürfnisse) und eine explizite Darstellung der Schnittstelle zwischen Auftraggebern und Auftragnehmern (Pflichten-/Lastenheft). Produkt- und Produktspezifisches Tailorring sollte vermeiden, dass es zu viele und vor allem keine nutzlosen Dokumente gibt - die Wichtigkeit der Dokumentation steht im Fokus. Das Tailoring (V-Modell XT) stellt sicher, dass der betriebene Aufwand dem Nutzen entspricht; es findet eine Reduktion des generischen V-Modells auf genau die Elemente, die zur Durchführung des Projekts benötigt werden, statt. Das Resultat: spezifisches V-Modell (dokumentiert im Projekt Manual ) ist projektspezifisch, produkt- und domänenspezifisch und unternehmensspezifisch!! Software Engineering I, SS12, Dennis Wikczynski! 14

15 Unified Process (UP): Besondere Charakteristiken des UP sind Modellbasiert: Abstraktion und Separation of Concerns Iterativ und inkrementell: Entschärfung von Risiken; Handhabung sich ändernder Anforderungen; Erreichung kontinuierlicher Integration; Ermöglichung von frühzeitigem Lernen Use-Case- (Anwendungsfall-) getrieben: bedeutende Anforderungen (bzgl. Mehrwert) zu identifizieren; einfache Erstellung und Validierung der Architektur zu ermöglichen; Prozesse voranzutreiben Architekturzentriert: Strukturierung; Verständnis des Systems vertiefen; Wiederverwendung fördern; Weiterentwicklung unterstützen Das UP besitzt zudem folgende Lebenszyklus-Phasen:! Software Engineering I, SS12, Dennis Wikczynski! 15

16 Vorteile Basierend auf der UML (Standard zur Modellierung von Software-Systemen) Berücksichtigung von Use-Case Berücksichtigung der Wechselwirkungen zwischen Anforderungen Architektur Iterativ & inkrementell (Phasen als Workflows) Basiert auf Erfahrungen mehrerer Vorgehensweisen Teilweise Tool-Unterstützung Nachteile Insgesamt noch teilweise unausgereift, bspw. keine klare Definition von Rollen (noch) nur wenig erprobt zu unkonkret für praktische Anwendung ANMERKUNG: Die weiteren Kapitel werden in den Übungsblättern ausreichend abgedeckt (Rollenverteilung und Software-Tests). Eine Ausführliche Zusammenfassung findet man außerdem auf SE1/Lernskript! Software Engineering I, SS12, Dennis Wikczynski! 16