Softwareengineering & Projektmanagement Zusammenfassung

Transkript

1 Softwareengineering & Projektmanagement Zusammenfassung Block 1-1 Einführung Begriffsdefinitionen Software: Beinhaltet alle Instruktionen die dem Computer vorschreiben, was er zu tun hat. Programme, die die Hardware des Computers kontrollieren. Software Engineering: Vorgehensweise zur systematischen Erstellung von Software nach ingenieurmäßigen Prinzipien. Analyse: Erfassen und Verarbeiten von Anforderungen (Pflichtenheft). Design: Entwurf der internen Struktur des Systems (Systemarchitektur). Validierung: Überprüfung des Verhaltens eines Programms durch festgesetzte Testfälle (gemäß den Anforderungen). Capability Maturity Model Integrated (CMMI) Reifegrade für Prozesse. Block 1-2 Projekttypen Unterscheidungsmerkmale Merkmal Messbare Attribute Beispiel Größe Anzahl der beteiligten Personen Personen: 50 Dauer Anzahl Tage bzw. Wochen Dauer: 52 Wochen Personen-Jahre: PY Verwendete Technologien Art, Anzahl, Alter der Technologien Art: Scriping language, Alter: 4 J., Anzahl: 5 Komplexität Anzahl Klassen, Module, Datenbanken; verwendete Technologien, Codezeilen Datenbanken: 2 Klassen: 42 mit Zeilen Seite 1

2 Block 1-2 Projekttypen (Fortsetzung) Softwarebeschaffung Entspricht den Anforderungen Änderbarkeit Preis Kauf Abänderung Neuerstellung Ungefähr (oft viele Oft ist keine exakte Genau ungenützte Funktionen Anpassung möglich oder ein paar fehlende) Beschränkung durch Schwierig, da technische Details oft nicht transparent sind Nach Anforderung + Verbreitung Beispiele für Softwareprojekte technische Grenzen Ausgangsprodukt wurde selbst hergestellt: leicht änderbar, Durch andere hergestellt: Schwer änderbar - durch eigene IT- Abteilung: kalkulierbar - durch andere: kostenintensiver Gut möglich (Dokumentation der Entwicklung und somit techn. Transparenz vorhanden) Teuer Kommerzielle Systeme (Benutzergesteuert, Zuverlässigkeit oft nicht entscheidend, ), eingebettete Systeme/Echtzeitsysteme (Ereignisgesteuert, oft auch vollständig automatisiert; Zuverlässigkeit sehr wichtig, ), Webapplikationen, Computerspiele, Unterschiedlicher Fokus auf Benutzerschnittstelle, Anwendung und Betriebssystem Top Ten der Gründe, warum Projekte scheitern 1. Unvollständige Anforderungen 2. Anwender nicht involviert 3. Zu wenig Ressourcen 4. Unrealistische Zeit- und Kostenpläne 5. Keine Management Unterstützung 6. Häufige Änderung der Anforderungen 7. Qualitätsmängel bei extern vergebenen Komponenten 8. Qualitätsmängel bei extern vergebenen Aufgaben 9. Fehlende Planung 10. Projekt wird nicht mehr benötigt Faktoren für ein erfolgreiches Projekt 1. Einbringung und Berücksichtigung der Anwender 2. Adäquates Projektmanagement: nicht zu viel aber auch nicht zu wenig 3. Anforderungen müssen eindeutig beschrieben, realisierbar und auch überprüfbar sein 4. Flexibler, realistischer Projektplan, der mögl. Verzögerungen berücksichtigt 5. Realistische Kostenschätzung und Budget, inkl. Risikoanalyse 6. Angemessene Ziele 7. Schlüsselteammitglieder haben genügend Projekterfahrung 8. Gute Teamarbeit, funktionierende Kommunikation im Team Zusammenfassung Verschiedene Anforderungen erfordern verschiedene Lösungsansätze Mit der Projektgröße ändern sich viele Faktoren des Projekts - Komplexität, Bedarf an Planung, Organisation etc. Die Eigenentwicklung von Software ist nicht immer die beste Lösung Unterschiede eingebettete Systeme vs. kommerzielle Software Seite 2

3 Block 1-3 Softwareprozesse und Produkte Produktqualitäten Anforderungen - stabil und ausreichend genau beschrieben, übersichtliche Darstellung - Systembeschreibung, Anwendungsfälle, Nichtfunktionale Anforderungen Design - Skalierbarkeit, Performance, Erweiterbarkeit - Übereinstimmung mit Anforderungen, ausreichend dokumentiert Testplan - Testrahmen, Teststrategie, Testfälle, Testzeitplan - Nachvollziehbare Beschreibung, Anforderungen vollständig abgedeckt Testbericht - Version des Systems und der DB, Testfälle mit unerwartetem Ergebnis - verwendete Eingabedaten, welche Korrekturen sind nötig Benutzerschnittstelle - Usability für Zielgruppen, Überprüfung mit Prototyp - Dialoge nicht überladen, einheitliches Layout, Fehlermeldungen einheitlich Datenbank - Redundanzfrei, Wachstum der Datenbestände berücksichtigen - Übereinstimmung mit Klassenmodellen, Integritätsbedingungen Technische Dokumentation - Verständlich, korrekt, vollständig, Format und Stil ansprechend - Lehrbuchteil, Nachschlageteil, Stichworte/Glossar, Online-Hilfe Projektplan - Alle Tätigkeiten mit Verantwortlichen und Mitarbeitern - Realistische Angaben für Aufwand, geeignete Darstellung Prozessmodelle im Überblick Modell Phasen Eigenschaften Wasserfallmodell V-Modell Inkrementelles Modell Iteratives Modell (z.b. Unified Prozess) Extreme Programmierung Zusammenfassung Anforderungen, Spezifizierung, Planung, Design, Implementierung, Integration (jeweils mit Verifizierung) Voruntersuchung, Analyse, Design, Implementierung, Test, Integration Analyse, Entwurf, Implementierung Integration, Auslieferung an Kunden Etablierung, Entwurf, Konstruktion, Übergang Coding, Testing, Listening, Designing laufen dauern parallel ab und nicht in Phasen Umsetzung des Life Cycles, sehr einfach, Risikominimierung durch Phasenabschlüsse, starke Auswirkung von Fehlern, keine parallele Entwicklung, Anforderungen wichtig Einfache Kontrolle des Projektfortschritts, für große Projekte mit Qualitätsanspruch Stufenweise Entwicklung, für große komplexe Systeme mit langer Entwicklungszeit bei jeder Iteration wird mehr Funktionalität realisiert, Granulare Abstufung Projekte mit schnell wechselnden oder vagen Anforderungen, mit kleinen Entwicklergruppen, zeitkritische Projekte Unterschiedliche Projekttypen erfordern die Wahl des richtigen Vorgehensmodells Produkte haben mehrere Qualitäten, die zu beachten sind Im gesamten Projekt müssen die Anforderungen immer gegenwärtig bleiben, d.h. es muss überprüft werden, ob die gewünschten Anforderungen erfüllt werden und geänderte Anforderungen müssen berücksichtigt werden. Seite 3

4 Block 2 Projektmanagement (Teil 1) Begriffsdefinition Projekt Zeitlich begrenztes, einmaliges Vorhaben Beschränkte Ressourcen Klar definierte Ziele Ein Projekt ist ein einmaliges Vorhaben mit einem definierbaren Anfang, einem definierbaren Ende und mehrere Personen sind daran beteiligt. Erfordert oft interdisziplinäre Zusammenarbeit Kein Tagesgeschäft/Permanentes Vorhaben Keine Maßnahme/Temporäres Vorhabe Besitzt in der Regel definierte Kriterien (Dauer, Budget, Risiko, Komplexität, Innovationsgrad, ) - MUSS-Kriterien sind entscheidend ob Projektmanagement notwendig ist oder nicht! - KANN-Kriterien bestimmen Umfang beziehungsweise Aufwand für das Projektmanagement Begriffsdefinition Projektmanagement Projektmanagement ist eine Gesamtheit von Methoden und Verhaltensweisen zur effizienteren Steuerung und Abwicklung von besonderen Aufgabenstellungen (Projekten). Bei der effizienten Steuerung geht es grundsätzlich immer um Projektmanagement im engeren Sinn = Projektleitung (für die Führung/Steuerung eines Projektes verantwortliche Person/Stelle) Projektmanagement im weiteren Sinn = Gesamtheit der Peronen/Stellen, die mit der Führung/Steuerung eines Projektes befasst sind Elemente des Projektmanagements Projektablauf was ist zu tun? (Start, Verfolgung, Abschluss) Arbeitsstruktur wer ist wofür zuständig? Informationswesen wer informiert wen, worüber, wann, wie? Dabei müssen die notwendige Methodenunterstützung, psychologische Aspekte sowie Umfeldbedingungen beachtet werden Seite 4

5 Block 2 Projektmanagement (Teil 1) (Fortsetzung) Projektstart Projektstart = Der Abschnitt von der Projektidee bis zum Kick off Projektinitiative (Idee, Design der Verantwortlichkeiten, Organisieren der Planung) Es muss entschieden werden a) ob ein Projektmanagement überhaupt notwendig ist. b) ob es sich überhaupt um ein Projekt handelt (existieren Muss-Kriterien?). c) in welcher Form das Projekt stattfinden soll. d) wann und wie die ersten Planungsgespräche stattfinden sollen. Vorarbeiten (Evaluierung der Projektidee, eventuell Erstellung einer Vorstudie, Ersteinschätzung der Ressourcenanforderungen) sind notwendig a) um zu entscheiden, ob ein Projekt überhaupt in Angriff genommen werden soll. b) zur Konkretisierung einzelner Punkte des Projekt c) um das Projektrisiko zu minimieren. Projektbeauftragung (Konkretisierung von Leistungen, Termine, Budget und Ressourceneinsatz im Rahmen von Planungsbesprechungen; Ausarbeitung eines Projektauftrags; Ausverhandlung des Projektauftrags mit Auftraggeber) Der Projektauftrag ist eine schriftliche (Ziel-)Vereinbarung zwischen Auftraggeber und Auftragnehmer, ein Projekt zu bestimmten Bedingungen durchzuführen. Er wird auch Projektantrag, Projekterklärung, Projektdefinition und Projektbeschreibung genannt und ist eine Management-Unterlage, d.h. er umfasst alle wichtigen Daten für die zukünftige Projektabwicklung. Kick-off (Freigabe durch den Auftraggeber, Startarbeiten, Einleitung der Projektverfolgung) Block 4 Software Engineering Phasen Software Life-Cycle Abfolge von Schritten (Phasen) mit qualitätsverbessernden Maßnahmen Basiskonzept für Prozesse und Vorgehensmodelle Seite 5

6 Block 4 Software Engineering Phasen (Fortsetzung) Software Life-Cycle Phasenbeschreibung Anforderungen zeigen die Wünsche des Kunden in Bezug auf das Softwareprodukt. (user/customer view) Anforderungen müssen testbar sein und getestet werden! Eine Spezifikation beschreibt das System aus technischer Sicht (engineering view). Planung: Erstellung des Projektplans: Zeit, Dauer, und Kosten (project management). Entwurf / Design: technische Lösung der Systemanforderungen (Komponenten, Packages, Datenbankdesign). Implementierung und Testen: Erzeugung des Softwareprodukts. Integration und Testen: Zusammenfügen und Test der einzelnen Komponenten auf Architektur- und Systemebene. Operation und Wartung: Fehlerbehebung, Unterstützung, Erweiterungen des Softwareproduktes während des laufenden Betriebes. Retirement: Nach der Einsatzphase, d.h. am Ende des Produktlebenszyklus, muss das Softwareprodukt kontrolliert aus dem Betrieb genommen werden. Begriffsdefinition Anforderungen Durch Anforderungen wird ein gemeinsames Verständnis hergestellt, was das Produkt können soll, und sie drücken das gewünschte Verhalten aus Nutzersicht aus. Berücksichtigung unterschiedlicher Stakeholders (Kunde/Anwender, Entwickler, usw.) Anforderungen müssen testbar und nachvollziehbar sein! Anforderungen werden validiert! (Entwickeln wir das richtige Produkt?) Viele Hauptgründe für Projektfehlschläge lassen sich auf Anforderungen zurückführen. Anforderungen an die Anforderungen: Gültigkeit, Konsistenz, Vollständigkeit, Realismus, Überprüfbarkeit, Verständlichkeit, Verfolgbarkeit, Anpassbarkeit Vier Richtlininien - Value-driven requirements Erfordert Geschäftsfall-Analyse - Shared-vision driven requirements Stakeholder bewerten regelmäßig die Anforderungen Gesamtheitliche Sicht ist wichtiger als präzise Anforderungen Arten von Anforderungen - Change-driven requirements Die Erweiterbarkeit und Anpassung wird oft vernachlässigt - Risk-driven requirements Wie detailliert müssen Anforderungen sein? If it s risky to leave it out, put it in Funktionale Anforderungen (z.b. Use-Cases) - Was beziehungsweise welche Funktionen sollen umgesetzt werden? - Wie soll sich das System in definierten Situationen verhalten? Nicht-funktionale Anforderungen (z.b. Qualitätskriterien) - Welche sonstigen Anforderungen müssen umgesetzt werden, die nicht direkt auf die Funktionalität abzielen, sie aber beeinflussen, z.b. Leistung und Performance (z.b. Optimierung des Informationsflusses). Usability und menschliche Faktoren (z.b. Einfachheit der Bedienung, Training). Sicherheit (z.b. Zugangskontrolle), Wartbarkeit (Trennung von Anwendung und Daten), Erweiterbarkeit. Designbedingungen - Worauf soll beim technischen Entwurf geachtet werden, z.b. Schnittstellen, Plattformen und Entwicklungsumgebung, verteilte Entwicklung. Prozessbedingungen - Rahmenbedingungen im Softwareprojekt, z.b. Ressourcen, Dokumentation. Seite 6

7 Block 4 Software Engineering Phasen (Fortsetzung) Priorisierung von Anforderungen Hauptanforderungen (must-be Kritieren). Gewünschte Anforderungen (expected, nicht entscheidend aber wichtig). Optionale Anforderungen (nice-to-have Kriterien). Entwurf und Design Beinhalten Architekturdefinitionen, Schnittstellendefinitionen, Domänen- und Datenbankmodelle, Komponentendefinitionen, User Interfaces, technische Anwendungsfälle (mit Anforderungen an Subsysteme und Lösungsweg) In der Regel in der Sprache der Techniker verfasst. Das Designdokument ist Grundlage der Implementierung! Wesentliche Komponenten: Software Architectural Design & Software Detailed Design 4+1 View Model of Architecture Teilaspekte der Architektur und des Designs und die spezifischen Eigenschaften eines Systems über verschiedene Sichten (views) beschrieben. Stammt aus der UML-Familie. Logical View Funktionale Anforderungen. Fokus auf den End-User. Beispiele: Design Packages, Subsysteme, Klassen. UML 2: Klassendiagramme, State-Machines, Package Diagrams usw. Process View Nicht-funktionale Anforderungen. Fokus auf Systemintegration. Beispiele: Laufzeitbedingungen, wie Concurrency, Lastverteilung, Fehlertoleranz. UML 2: Sequence, Activity Diagrams, Communication Diagrams. Implementation View Beschreibt statische Softwarekomponenten. Fokus auf Implementierung. Beispiele: Configuration Management, Source Code UML 2: Component Diagram der vorhandenen Softwareteile. Deployment View Ausführbare Applikationen (zur Laufzeit) unter Berücksichtigung der Plattform. Fokus auf Software Engineers. Beispiele: Deployment, Installation, Performance. UML 2: Deployment Diagrams. Seite 7

8 Block 4 Software Engineering Phasen (Fortsetzung) Use Case View Als Ergänzung zu den bisherigen Views, bildet der Use Case View den gemeinsamen Nenner, in dem die Anwendungsfälle und die Aktivitäten (als Szenarien) abgebildet und in einen Zusammenhang gesetzt werden. Fokus auf Systemanalyse sowie Entwurf und Design. - Der Use Case View bildet die Schnittstellenfunktion zwischen den anderen Sichten aus der Architektursicht - und beinhaltet Schlüsselszenarien (key scenarios) der Applikation aus der Sicht der Geschäftsprozesse. Fokus auf Implementierung und Transition - Verifikation und Validierung der Anforderungen (Test) und der vier Architektur-Views. UML 2: Use Case Diagram + Beschreibung, Aktivitätsdiagramme. Design Principles System Control (Wer übernimmt die Kontrolle im System?) Stair - Verteilte Kontrolle. - Schrittweise Ausführung von Funktionen, dadurch wechselt die Kontrolle. - Verbesserung der Wiederverwendbarkeit der Methoden (z.b. durch Vererbung). - Die spätere Wartung wird erschwert. Fork - Ein zentrales Objekt kontrolliert den gesamten Use Case. - Wiederverwendung von Datenobjekten (ohne Business Logik) wird erleichtert. - Wartbarkeit wird verbessert, da nur ein Objekt geändert werden muss. Abstraction Concept (z.b. Klasse) vs. Value (z.b. Objekt): Reduktion der Komplexität durch ignorieren von Details; z.b. Generalisierung in UML Klassendiagrammen. Decomposition und Modularisierung Aufteilung großer Systeme in mehrere kleinere unabhängige Teile (Komponentenorientierung). Trennung von funktionalen Anforderungen. Verbesserte Wiederverwendbarkeit. Encapsulation / Information Hiding Packaging von Instanzvariablen und Methoden in eine Klasse um die Komplexität des Objekts und der Implementierung zu reduzieren. z.b. private variables <> public properties. Trennung von Interface und Implementierung (z.b. durch Public und Private Interfaces) Die Implementierung einer Komponente kann geändert werden, solange das Interface unverändert bleibt. Seite 8

9 Block 4 Software Engineering Phasen (Fortsetzung) Standardisierung der Implementierung im Projekt Durch Implementierung einer ausreichenden und einheitlichen Dokumentation, zum Beispiel: Namenskonventionen zur Verbesserung der Lesbarkeit des Codes, z.b. gleiche Notation von Variablen, Methoden und Klassen. Formatierungsrichtlinien z.b. Einrückungen, gleicher Methoden und Komponentenaufbau erleichtern das Zurechtfinden in fremdem Code. Versionierungen ermöglichen einen raschen Überblick aller (Teil-)Produkte innerhalb eines Projektes und die Verwendung der letztgültigen Versionen (z.b. CVS, Dokumenttagebücher). Verwendung eines Headerblocks in jeder Komponente. Interne Standards (auf Unternehmensebene) zur Koordination der Teamaktivitäten, um Komplexität zu reduzieren und Lesbarkeit und Verständnis der Doukumente und des Source Codes zu gewährleisten versus übergereifende Standards Kommunikationsmethoden (z.b. Format und Inhalt der Nachrichten), Programmiersprachen (z.b. Syntax in Java), Plattformen (z.b. Interfaces zu Betriebssystemaufrufen), Tools (z.b. Notationen wie UML). Standardisierung durch Traceability Traceability ist die Nach- oder Rückverfolgbarkeit einer Information durch ihren gesamten Entwicklungszyklus (z.b. bei sicherheitskritischen Anwendungen gefordert). Änderungsverfolgung = die Fähigkeit, den Lebenszyklus einer Anforderung vom Ursprung der Anforderung über die verschiedenen Verfeinerungs- und Spezifikationsschritte bis hin zur Berücksichtigung der Anforderung in nachgelagerten Entwicklungsartefakten verfolgen zu können. Typische Fragestellungen: Woher kommt eine Anforderung und wo wurde sie umgesetzt? Welche Artefakte sind von einer Änderung der Anforderung betroffen? Welche Anforderungen sind von einer Änderung der Umsetzung betroffen? Arten der Traceability Seite 9

10 Block 4 Software Engineering Phasen (Fortsetzung) Systemintegration Durch Modularisierung (erleichtert Lesbar-, Wartbar- & Verständlichkeit der Softwarekomponenten) entstehen (komplexe) Systeme mit meist vielen unterschiedlichen getesteten Komponenten. Systemintegration bezeichnet die Integration unterschiedlicher Komponenten zu größeren (Sub-)Systemen. Dies geschieht auf unterschiedliche Art (je nach Komplexität und Systemtyp): Big-Bang Integration (für kleine, überschaubare Projekte) Gleichzeitige Integration aller Komponenten. - Vorteil: Da alle Komponenten verfügbar, kein zusätzlicher Testaufwand für Test-Stubs - Nachteile: Fehler sind schwer zu lokalisieren (z.b. Seiteneffekte), hohes Risiko Top-Down / Bottom-Up Integration Integration ausgewählter Komponenten mit eingeschränkter Gesamt-Funktionalität. - Top-Down Integration (Schrittweise Integration, ausgehend von den Geschäftsfällen) o Vorteil: ausführbares Produktframework früh verfügbar ( Prototypen, für Testfälle) o Nachteile: Zusätzlicher Aufwand für Test-Stubs, späte Integration (zusätzliches Risiko) - Bottom-Up Integration (Schrittweise Integration, beginnend bei der Hardware) o Vorteil: Stabiles System (basierend auf Hardwareinterfaces) o Nachteile: Ausführbares Gesamtsystem spät verfügbar, zusätzlicher Aufwand Build Integration Schrittweise Integration entsprechend den Business Cases (über unter-schiedliche Layer hinweg; z.b. über priorisierte Liste von Use-Cases). Phasen-orientierte Integration. - Vorteile: Frühe Verfügbarkeit von funktionalen Anforderungen (über alle Layer), also Prototypen, Berücksichtigung priorisierter Anforderungen möglich. - Nachteil: Komponentenwiederverwendung schwierig, Regressions-Tests erforderlich. Wartungsprozesse im Software Life-Cycle (Wartung Evolution Retirement) Beginnend mit der Inbetriebnahme, beginnt die Wartung (korrektiv, adaptiv und verbessernd) und endet mit der kontrollierten Außerbetriebnahme beziehungsweise Ersetzung durch anderes System. Wartungsprozesse beinhalten dieselben Phasen wie der Life-Cycle Prozess; einen speziellen Stellenwert nehmen die Anforderungsänderungen ein. Unterschiedliche Sichten auf die Wartung: Activity-View: Änderung des Software Systems nach Auslieferung (Delivery) und Inbetriebnahme (Deployment bzw. Product Launch). Process-View: Schritte zur Durchführung einer Wartungsaufgabe. Phase-Oriented-View: Die Wartungsphase beginnt mit der Auslieferung und Inbetriebnahme und Ende mit Stilllegung des Softwareproduktes. Wartungskategorien Correction Enhancement Proactive Preventive Perfective Reactive Corrective Adaptive Vorbeugende Wartung (Preventive) Verbesserung im Hinblick auf zukünftige Wartung (z.b. Ergänzung der Dokumentation). Korrektive Wartung (Korrektive) Bug- und Fehlerkorrektur (patches, workarounds, updates). Produktpflege und Verbesserung (Perfektive) Produktverbesserung (Erweiterungen, Verbesserung der Effizienz). Adaptive Wartungsaktivitäten (Adaptive) Berücksichtigung geänderter externer Anforderungen (Hardware, Softwareänderungen). Seite 10

11 Block 4 Software Engineering Phasen (Fortsetzung) Techniken zur Wartung Herstellen des Produktverständnisses (fremden Code lesen & verstehen, sehr zeitaufwändig, nur bei guter Dokumentation möglich, Key Tool: Code Browser) Reengineering (Überprüfen & Überarbeiten des Codes, gravierend und teuer) Reverse Engineering (Analyse der Software auf Komponenten und Zusammenhänge Modelle basierend auf dem Code auf höheren Abstraktionsniveau (z.b. Code zu UML) Phase Retirement Retirement = Am Ende der Betriebsphase (Betrieb und Wartung) kontrolliertes Stilllegen des Produktes beziehungsweise störungsfreier Übergang zu einem Nachfolgeprodukt. Zusammenfassung Der Life-Cycle Prozess umfasst sämtliche Schritte der Softwareentwicklung von der Konzeptphase bis zur Stilllegung des Softwareprodukts. Die Anforderungserhebung ist kritisch für den Erfolg eines Softwareproduktes. Änderungen oder Fehler wirken sich gravierend in späteren Phasen der Entwicklung aus. Entwurf und Design sind die Basis für die eigentliche Implementierung und legen den Aufbau des Systems fest. Designprinzipien sind zu beachten. Die Implementierung umfasst die Umsetzung der Anforderungen und des Entwurfs. Standards und Dokumentation unterstützen Softwareentwicklungsteams nicht nur bei der Erstellung sondern auch bei der Weiterentwicklung und Wartung. Qualitätssicherung und Testen sin ein integraler Bestandteil während des gesamten Projekt- Lebenszyklus. Sie dürfen nicht als Add-on gesehen werden. Ein Großteil der Wartung umfasst Erweiterungen des Produktes, aber auch Fehlerkorrektur und Anpassungen an geänderte Systemgegebenheiten. Die Retirement-Phase schließt den Software Life-Cycle ab, in dem das Softwareprodukt kontrolliert außer Betrieb genommen beziehungsweise ersetzt wird. Block 6 Modellierung von Anwendungsszenarien Modellierungssprachen Software-Entwicklung erfordert die Herstellung konsistenter Sichten auf Anforderungen und Entwurf eines Systems Modelle Prinzipien der Abstraktion; Information Hiding und Vererbung. Betrachtung des Wesentlichen (Brille) mit Hilfe von Richtlinien (Werkzeugkasten). Umgesetzt in Modellierungs- (mit Codegenerierung) oder Zeichenwerkzeugen (Diagramme) Modell versus Diagramm Ein UML-Modell ist eine Menge von Modellelementen (Klassen, Attribute, Anwendungsfälle). Ein UML-Diagramm ist eine Sicht auf ein Modell (Anwendungsfall-, Klassendiagramm). Elemente in unterschiedlichen Diagrammen können sich auf dasselbe Modell beziehen. Schemata für statische Aspekte UML ( immer ) Anwendungsfälle (Benutzer und Nützlichkeit definiert durch Akteure und Hauptszenarien) Klassen (Menge gleichartiger Objekte mit Attribute udgl., auch Datenbankschemata) Schemata für dynamische Aspekte mit UML ( wenn dann ) Sequenz (ge- und verbotene Interaktionsstrategien, Folgen von Nachrichten) Aktivität (proaktives Verhalten, Datenfluss zwischen Prozess- & Kontrollabläufen) Zustandsautomat (reaktives Verhalten, Zustände und Übergänge/Transitionen wichtig) Seite 11

12 Block 6 Modellierung von Anwendungsszenarien (Fortsetzung) Prozess und Datenfluss Analyse (IDEFØ) Modelliert Daten- und Kontrollfluss beziehungsweise Daten- und Kontrolltoken Aktivitätsdiagramm Zustandsdiagramm Und-Verfeinerung Oder-Verfeinerung Block 7 Ausgewählte Softwareprozesse Traditionelle Ansätze Wasserfallmodell (kleine Entwicklerteams), V-Modell Konzept (Spezifikationsphase versus Realisierung & Testen, große Projekte im öffentlichen Bereich, Doku und Anforderungen!) V-Modell XT (Verpflichtendes Vorgehensmodell für IT Projekte im öffentlichen Bereich in Deutschland, Vorgehensbausteine kapseln Rollen, Produkte [Mittelpunkt] und Aktivitäten) - Projekttypen werden eingeteilt nach Projektgegenstand und Projektrollen Vier Projekttypen o Systementwicklungsprojekt des Auftraggebers. o Systementwicklungsprojekt des Auftragnehmers. o Einführung und Pflege eines organisationsspezifischen Vorgehensmodells. o Systementwicklungsprojekt (Auftraggeber/Auftragnehmer). - Vorgehensbausteine untergliedert in V-Modell Kern (verpflichtende Elemente für alle Projekttypen), Einführung und Pflege, Elemente für die Systementwicklung, Auftraggeber / Auftragnehmer Schnittstelle. Seite 12

13 Block 7 Ausgewählte Softwareprozesse (Fortsetzung) Rational Unified Process (RUP) - Inkrementelle und iterative Vorgehensweise. Mehrere Iterationen pro Phase. - Vier grundlegende Phasen: Inception (Beginn), Elaboration (Entwurf & Design), Construction (Implementierung), Transition (Auslieferung) - Definierte Workflows und Disziplinen: sechs Engineering Workflows, drei Supporting Workflows - Vorteile: Werkzeugunterstützung, Vordefinierte Liste mit erforderlichen Artefakten. - Nachteile: Hohe Komplexität, hoher Dokumentationsaufwand. - Anwendungsbereich: Große Projekte durch eine ganzheitliche Prozess-Sicht auf das gesamte Projekt (inkl. Deployment). Ein Agiler Ansatz: SCRUM Agil bedeutet aber nicht unkontrolliert auch hier existieren Prozesse und Regeln, die eingehalten werden müssen. 12 Prinzipien, die die Basis für agile Entwicklung darstellen. Flexibles Prozessmodell, um auf ändernde Anforderungen im Projektablauf reagieren zu können. SCRUM ist keine Abkürzung; der Begriff stammt aus der Rugby Start-Formation. Der Sprint ist das zentrale Element. Seite 13

14 Block 7 Ausgewählte Softwareprozesse (Fortsetzung) SCRUM-Begriffsdefinitionen Backlog: Beinhaltet alle Arbeitspakete, die in nächster Zeit umgesetzt werden müssen (sowohl klar definierte als auch vage Anforderungen): Produkt vs. Sprint Backlog (priorisierte Gesamtliste versus Features, die in einem einzelnen Sprint umgesetzt werden aufgespalten in Tasks ). Daily-Scrum: Eine tägliche Projektbesprechung um etwaige Fragen / Missverständnisse zu klären; Definition des täglichen Arbeitsauftrags. Scrum Team: Funktionsübergreifendes Team, zuständig für den Sprint Backlog. Burndown Chart: Visuelle Darstellung des Projektfortschritts. Anpassung von Softwareprozessen Fragestellung: Anwendbarkeit von standardisierten Softwareprozessen im konkreten Projekt? Antwort: Standardprozesse eher schwer direkt einsetzbar. Prozess Tailoring (bezogen auf der jeweilige Projekt) Anpassung eines generischen Entwicklungsprozesses an individuelle, spezifische Projektgegebenheiten. Ersetzen einzelner Prozessschritten durch passende alternative Lösungen Wiederverwendung von Best-Practices (Methoden / Tools). Erfordert erfahrene Projektleiter! Fundiertes Verständnis des Modellaufbaus erforderlich! Berücksichtigung von definierten Tailoring-Kriterien und Produktabhängigkeiten wichtig! Prozess Customization (Standardisierung) Anpassung des Vorgehensmodells an unternehmensspezifische Gegebenheiten (Unternehmensstandards) und an Projektstandards (ähnliche Projekte). Verallgemeinerte Form des Tailorings. Diese angepassten Prozesse dienen als Grundlage für projektspezifisches Tailoring. Die Kompatibilität zum zugrunde liegenden Prozess muss sichergestellt werden! Zusammenfassung Softwareprozesse und Vorgehensmodelle ermöglichen vorhersagbare und nachvollziehbare Softwarelösungen. Sie definieren, wie ein Softwareprojekt durchgeführt wird bzw. in welcher Reihenfolge die einzelnen Phasen ablaufen. Systematische Prozesse sind durch ihre Struktur plan-driven und orientieren sich eher an Abläufen mit Schwerpunkt auf Produkten und Dokumentation. Beispiele: Wasserfallmodell, V-Modell (XT), RUP, Inkrementelle Modelle. Agile Ansätze rücken den Kunden und seine konkreten (sich ändernden) Anforderungen in den Vordergrund. Beispiele: extreme Programming, SCRUM. Durch Tailoring wird ein allgemeines Modell auf ein individuelles Projekt angepasst. Customization ermöglicht die Erstellung unternehmensspezifischer Vorgehensmodelle für gleichartige Projekte / Produktgruppen. Seite 14

15 Block 8-1 Qualitätssicherung allgemein Begriffsdefinition Validierung & Verifikation Validierung = Wurde das richtige Produkt entwickelt?, z.b. Akzeptanz- und Abnahmetests (Prüfung gegen Anforderungen) Verifikation = Wurde das Produkt richtig entwickelt?, z.b. Komponententests (Prüfung gegen Spezifikation) Grundsätzliches Testen zielt darauf ab, Fehler zu finden (fehlende, falsche oder inkonsistente Informationen) und nicht der Nachweis, dass das Produkt funktioniert. Die zentralen Fragestellungen eines Testers sind - Wie kann ein Softwareprodukt fehlschlagen? - Mit welchen Szenarien kann ich das Produkt in einen instabilen, nicht mehr vorhersehbaren Zustand bringen? Für die Umsetzung von Qualität und deren Sicherung sind in Projekten notwendig: - Testbare Anforderungen (Definition der Funktionen und Qualitäten) - Verfolgbare Entwicklung der Anforderungen (mit Modellen) in testbare Produkte. Testen ist keine zusätzliche Aktivität am Ende des Softwareprojekts sondern begleitet das Projekt laufend! Block 8-2 Statische Methoden der Qualitätssicherung Begriffsdefinition Review Ein Review ist ein [..] formal geplanter und strukturierter Analyse- und Bewertungsprozess, in dem Projektergebnisse einem Team von Gutachtern präsentiert und von diesen kommentiert oder genehmigt werden. Dienen also vor allem zur qualitativen Beurteilung von Produkten und Prozessen, die quantitativ nur schwer oder gar nicht beurteilt werden können (z.b. Modelle, Dokumente) Unterschiedliche Ausprägungen von Reviews zielen auf unterschiedliche Ziele ab. Arten von Reviews Seite 15

16 Block 8-2 Statische Methoden der Qualitätssicherung (Fortsetzung) Rollen bei Reviews Moderator ( keeper of the process ): Leiter des Reviews Leser ( keeper of focus and pace ) Gutachter ( Reviewer ): Kommentierung des Reviewobjektes. Schreiber ( preserver of knowledge ): Verfasst Protokoll (Notizen während des Reviews) Autor ( author ): Klärung offenener Fragen. Keine Kommentier-/Rechtfertigung der Lösung. Ablauf eines Rewiews Planung ( planning phase ) Initialisierung ( initialisation phase ) Vorbereitung ( preparation phase ) Reviewsitzung ( review ) Sammlung im Team ( meeting ) Reviewbericht ( reporting ) Nacharbeit ( re-work ) Mit Reviews verwandte Tätigkeiten Inspektion (Ziel: Behebung von konkreten Mängeln) - Bedingung: Leser ist nicht Autor Walkthrough (Ziel: Behebung von konkreten Mängeln) - Bedingung: Autor ist Leser & Moderator Audit (Ziel: Überblickende Kontrolle) - Bedingung: Planung durch externe Personen, Projektmitarbeiter nur als Information Block 8-3 Testansätze & Test-Driven Development Elemente der Testfallbeschreibung Beschreibung ist die Komponente im System und eine Funktion (Ablauf aus Anforderungen). Vorbedingungen existieren oder eben nicht. Eingabewerte sind konkrete Parameterbeschreibungen (Äquivalenzklassen). Aktionen sind Aktivitäten zur Eingabe der Werte. Erwartete Ergebnisse sind Zustände und Ausgabeparameter. Ergebnisse zeigen Abweichungen zum tatsächlichen Ergebnis. OK/NOK zeigt ob der Test erfolgreich durchläuft. Grundlegende Testtechniken/-stufen Unit Test: Fokus auf Komponenten und Prüfung auf Übereinstimmung zwischen der Umsetzung der Komponente und technischer Spezifikation ( lebendige Dokumentation ). Integrationstest: Fokus auf Interfaces und Verbindungen zwischen Komponenten innerhalb des (Sub)Systems (inkrementelles Testen vorzuziehen). Systemtest: Übereinstimmung zwischen funktionalen und technischen Bedingungen des Gesamtsystems (nahe an der Zielplattform). Regressionstest: Testen von geänderten Komponenten. Dadurch sollen Fehler, die durch Änderungen, z.b. auch durch Fehlerkorrektur, entstanden sind, verhindert werden. Akzeptanztest: Übereinstimmung der Anforderungen in der Zielumgebung des Kunden. Installationstest: Identifizieren von Fehlern während der Installation. Seite 16

17 Block 8-3 Testansätze & Test-Driven Development (Fortsetzung) Teststrategien/-arten Black Box Tests Basiert auf Spezifikation. Wissen über innere Struktur ignoriert. Data-driven (Input/Output). Anforderungsüberdeckung. Äquivalenzklassenbildung. Keine genaue Fehlerortung möglich. White/Glass Box Tests Basiert auf Code. Wissen über innere Struktur notwendig. Logic-driven. Kontrollflussüberdeckung. Äquivalenzklassen von internen Verzweigungen und Schleifen. Ermöglicht Fehlererkennung und -lokalisierung. Äquivalenzklassen Gleiches Verhalten aus einer Menge von Eingabedaten mit demselben Ergebnis Auswahl eines repräsentativen Wertes zur Reduktion der Testfälle. Jede Klasse(-nkombination) sollte mindestens einmal getestet werden. Dadurch sinkt die Anzahl der Testfälle und somit der Testaufwand. Testfälle müssen gültige (Normalfall, Sonderfall) UND ungültige Eingabewerte (Fehlerfall) berücksichtigen. Beispiel: Anforderung = i>15 3 Äquivalenzklassen Grenzwertanalyse Spezialfall einer Äquivalenzklasse. Geeignete Auswahl der Repräsentanten in der Nähe der Datengrenzen, d.h. Grenzwerte werden als Klassenrepräsentanten gewählt je Klassengrenze ein Testfall. Beispiel: Anforderung = 18 < Alter (ungültig), 19 (gültig), 65 (gültig) & 66 (ungültig) Wertbeitrag von Softwaretests Zentrale Fragestellung: Ist jeder Testfall, jeder Fehler, jede Anforderung gleich viel wert? NEIN, das heißt Value-Based Testing ist vorrangig. Ziel: Vorrangig Unit Tests als Basis, drauf aufbauende ein geringerer Anteil an System und Integrationstests. Seite 17

18 Block 8-3 Testansätze & Test-Driven Development (Fortsetzung) Test-Driven Development Prozessablauf: 1. Think: Spezifikation des Tests. 2. Red: Implementierung des Tests (Test schlägt fehl!). 3. Green: Implementierung der zu testenden Klasse. (Test ist erfolgreich!) 4. Refactor: Veränderung einer Implementation Funktionalität bleibt erhalten. Zusammenfassung TDD als Basis für zielorientierte Software-Entwicklung (Implementierung und QS). Brauchbare Modelle unterstützen das Herstellen effektiver und effizienter Testfälle: - Datenmodellierung (Datenbank) - Datenfluss und Kontrollfluss (Business Logic) - Zustandsübergangsmodelle (z.b. GUI) Reviews helfen die Anforderungen und Modelle vorab zu überprüfen, um eine solide Basis für Testfälle herzustellen. Die Zeit für Unit Tests ist wohl investiert, da sie Integrationstests wesentlich vereinfachen (bottom-up testing). Test Cases sind living documents unterstützen die Kommunikation innerhalb des Teams. Block 9 Persistenzstrategien Grundsätzliche Fragestellungen Soll es eine Trennung zwischen Logik und Daten geben? Sind die zu speichernden Daten strukturiert, semi-strukturiert oder gar unstrukturiert? Grundsätzliche Strategien Es gibt nicht die perfekte Lösung. If you only have a hammer, everything tends to become a nail. Wichtig: Datenstrukturen überleben meist viele Softwaregenerationen! Reine, abstrakte Langzeitspeicherung von Vorteil Schichtenarchitektur Zwei-Schichten-Architektur Präsentationsschicht Anwendungs-/Datenschicht Drei-Schichten-Architektur Präsentationssc hicht Anwendungs-/Logikschicht Datenschicht - Thin-Client ( Heavy Server vs. Server per Layer) / Fat-Client (Data-Server) Data Access Object Pattern Interface Implementation Transfer/Domain Object & Business Object Seite 18

19 Block 9 Persistenzstrategien (Fortsetzung) Data Access Object Pattern Arten der Datenspeicherung Objektorientierte Datenbanken - Vorteile: Nahe an objektorientierten Sprachen (kein Mapping), schnelle DB-Entwicklung - Nachteile: lediglich kleine Anzahl erprobter Systeme (db4o, Cache), keine standardisierte Abfragesprache, keine Open Source Systeme, Versionshandling? Rationale Datenbanken - Vorteile: Neutrale Art der Datenspeicherung, hoch erprobt, große Anzahl an verfügbaren Systemen, Abfragesprachen und (Supporting) Tools (Office Pakete) - Nachteil: Schwelle zwischen Objekten & Relationen (2 verschiedene Modelle/Schemata) No SQL - Schemafrei, Fokus auf Skalierbarkeit nicht auf Konsistenz ( eventually consistent ) Clientabstraktion: Webservices / REST - REST = Representational State Transfer (Basierend auf HTTP [get, post, put, delete]) Stateless, Cacheable, Scaleable, alle Datentypen können transferiert werden - Webservices: XML/Text als Nachricht mit Antworten Speicherung in Clouds - Nutzung von Webservices eines Anbieters ohne eigene Speicher-Infrastruktur - Ziele: Hohe Performance, Hohe Verlässlichkeit, Einfachheit - Beispiel: Amazon S3 Objektrelationales Mapping Problem: Mapping Objekte Tabellen (inkl. Assoziationen), Zugriffsstrategie? Beispiele: mybatis (Data Mapper), Hibernate (voller O/R-Mapper Vorteil: Trennung von relationalen Modell und objektorientierten Modell Geringere Abhängigkeit von der Datenbank Nachteile: Komplexität, Tabelle-Mapping-Problem (Tabelle pro Klasse/konkreter Klasse?), Zeilenidentität (nicht bestimmbar) versus Speicheridentität (bestimmbar), vollständige Trennung zwischen Datenbank und OO oft nicht möglich Block 10 Projektmanagement (Teil 2) Motivation Prozesstheorien: Geben eine Erklärung darüber, wie das Verhalten gesteuert wird, warum ein bestimmtes Verhalten zur Erreichung eines definierten Ziels gewählt wird Inhaltstheorien: Beschreiben Bedürfnisse, Antriebe und Ziele der Menschen - Monothematische Theorien (einzelnes Motiv ausschlaggebend, z.b. Freud: Sexualtrieb) - Polythematische Theorien (mehrere Grundmotive in unterschiedlicher Rangordnung) z.b. Motivationspyramide von Maslow, ERG-Modell, Zufriedenheitstheorie von Herzberg Seite 19

20 Block 10 Projektmanagement (Teil 2) (Fortsetzung) Motivationspyramide nach Maslow Abraham Maslow (1954) geht von fünf Kategorien menschlicher Bedürfnisse aus, welche eine Hierarchie der Dringlichkeiten bilden. Erst wenn eine Stufe in einem gewissen Ausmaß befriedigt ist, wird die darauf aufbauende verfolgt. In dieser Form überholt aber als Ansatzpunkt hilfreich. Produktionsfaktor Mensch Mehr als eine Ressource Mitarbeitermotivation hat besondere Bedeutung Produktivität: Erbrachte Leistung im Verhältnis zur aufgewendeten Zeit; Fehler: - Personal zu mehr Arbeit anhalten - Prozess der Produktentwicklung automatisieren - Qualitätsmaßstäbe für das Produkt modifizieren (i.e. reduzieren) - Vorgehensweisen standardisieren Kontraproduktive Maßnahmen (Verringerung der Arbeitsmotivation, Folge: Fluktuationen) Typische Fluktuationszahlen zwischen 33% und 80%, durchschnittliche Beschäftigungszeit zwischen 15 und 38 Monaten. Der Mythos der Austauschbarkeit wird durch die Maßeinheit Personen-Monat zur Angabe der Projektdauer beschrieben. Dahinter steht die Vorstellung, dass sowohl Personen als auch Monate beliebig austauschbar sind. Diese Vorstellung hat aber nur eine (annähernde) Berechtigung bei Arbeiten, die ohne Kommunikation ausführbar sind! Umwelt-Faktor: Anwesenheitszeit vs. Zeit mit vollem Arbeitseinsatz (Flow nach 15 min) Auswahl von Mitarbeitern (1) Job specification - Auflistung der Anforderungen des Jobs (2) Job holder profile - Auflistung der Anforderungen an die Person, die den Job ausfüllen soll. zum Beispiel: Qualifikationen, Berufserfahrung, Ausbildung,... (3) Bewerbungen einholen - Schalten der Stellenausschreibung in einem geeigneten Medium - Das geeignete Medium lässt sich u.u. aus dem Job holder profile ableiten (4) Auswertung der Bewerbungen - Vergleich der Lebensläufe mit dem Job holder profile - Ungeeignete Kandidaten frühzeitig ausscheiden (5) Auswahl der Mitarbeiter - Durch Portfolio (Auswahl von Produkten ihrer bisherigen Tätigkeiten) - Durch Eignungstests, Anhörungen, Interviews Sieben Wege um Teambildung zu verhindern Defensives Management Bürokratie Physikalische Trennung Zersplitterung der Zeit des Mitarbeiter Formen der Teamorganisation die klassische hierarchische Organisation die typische Matrix-Organisation das Chef-Programmierer -Team Qualitätsreduktion der Produkte (geringere Identifikation) Scheintermine Cliquenzerschlagung das offen strukturierte Team das SWAT-Team das XP-Team Seite 20