Mail: Web: Telefon: 0172/

Transkript

1 Mail: Web: Telefon: 0172/ Termine - Montag, 4. April, Freitag, 15. April, Freitag, 22. April, Freitag, 29. April, Freitag, 6. Mai, Freitag, 27. Mai, Montag, 20. Juni, (Klausurvorbereitung) 1

2 Erwartungen - Systematische Einführung in SW-EP Prozess, Vorgehensmodell - Programmierparadigmen (Sprachen, OO vs. funktional) - Mögliche Problem, Fallen - Motivation - Teamarbeit, Projektarbeit - Umsetzung der Anforderungen - Spass! 2

3 2. Entwicklungsprozesse 2.1. Einführung IT Disaster - Toll-Collect - Arbeitsvermittlung - FISCUS - HERCULES - Lufthansa - Gesundheitskarte - B52 - Hapag Lloyd - F16 - THERTATEC Ursachen - zu neue Technologie - zu kurze/zu wenig Tests - falsche Projektplanung - Bedienbarkeit - falsche Implementierung - Wartbarkeit - Sicherheit - Unklare Anforderungen - Stabilität - Gemeinsamkeiten - zu teuer - zu langsam - zu schlechte Qualität 3

4 Qualität (DIN55359): Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines Produktes oder einer Tätigkeit, die sich auf deren Eignzung zu Erfüllung gegebener Erfordernisse bezieht. Fehlerfreiheit Stabilität Benutzbarkeit Effizienz: "do the things right" Funktionalität Effektivität: "do the right things" 4

5 Prozess - Projekt - Produkt - Projekt: Ist das Zusammenwirken von Tätigkeiten, Akteuren, und Hilfsmitteln, um ein gemeinsames Ziel mit definiertem Ergebnis, mit zugeteilten Resourcen, mit bestimmten Anfangs- und Endtermin zu erreichen. Charakteristikum: Aspekt der Einmaligkeit - Produkt: Ist das Ergebnis einer Tätigkeit, das nützlich für Anwender oder Kunden sein kann/soll (Bsp: Applikation, Dokument) - Prozess: Ein Vorgehensmuster im Projekt zur Erstellung des Produkts mit einer Beschreibung von Planungsablauf, Realsierungsablauf, Definition von Aktivitäten, Meilensteinen, Phasen und Rollen 5

6 Autobau - Einzelteile produzieren - Zusammenbauen - Lackieren - Testen Koordination, Planung der Fertigungsreihenfolge 6

7 2.2 V-Modell Business case Business result Anforderungen Spezifikation (WAS?) Funktionstest Validierung Design (Wie?) Integrations- Systemtests Verifizierung Implementierung Modultests Verifizierung V-Modell XT ( Tom de Marco: Der Termin, Bärentango 7

8 2.3 Rational Unified Process (RUP) www-106.ibm.com/developerworks/rational/library/354.html 8

9 2.4 extreme Programming 9

10 Zuordnung von Konstruktion & Tests Rücksprung mögl. Test-Kaskade mittel -gross Paarprogrammierung Testgetrieben iterativ & inkrementell Stets lauffähiges Produkt Refactoring klein - mittel Trennung Phase und Workflow UML, Prototyping Architekturzentriert Use Case driven mittel-gross staatl. Projekte OO-Projekte erfahrene Teams statische Anforderungen Kundenverfügbarkeit Softwareprojekt OO-SW-Projekte Fehler spät entdeckt Mangelnde Zeit für Tests, da am Projektende langfristige Strategie geht verloren anpassen an eigenes Projekt 10

11 3. Anforderungsanalyse WAS? Wie? Projektmanagement Anforderungsanalyse Beschaffung von SW Vertrieb Machbarkeitsstudien Implementierung Administration 11

12 Zu beantwortende Fragen: - Was kann das Programm (Funktionalität)? - Was ist das System (was ist zu entwickeln)? - Was ist des Nutzen des Systems? 12

13 Exkurs: UML Use Cases 13

14 Use Cases - Vorgehensweise 1. Akteure festlegen => Systemgrenzen bestimmen 2. Alle Aktivitäten und damit Uses Cases identifizieren => Gesamtfunktionalität 3. Akteure und Use Cases verbinden => Berechtigungskonzept 4. Verfeinerungen durch Vererbungen sowie <<include>> und <<extend>> vornehmen Literatur: Jeckle et al. "UML glasklar", Hanser Verlag Ende Exkurs Use Cases 14

15 3.1. Inhalt einer Anforderungsanalyse Problemstellung (Wo bin ich?) - Beschreibung und Analyse des Problems Aufgabenstelung, Erwartung (Wo will ich hin)? - Erwartungen, Nutzen (Schein, Geld, Image) - Zielszenarios Lösungsansatz (Was ist das System, das mich ans Ziel bringt)? - Funktionale Anforderungen - Nichtfunktionale Anforderung (Verfügbarkeit, Erweiterbarkeit, Wartbarkeit, Testbarkeit,..., Antwortzeit, Stabilität) Funktionstests (Validierung), Funktions- u. Akzeptanztests Welchen Teil der Lösung gilt es zu realisieren - Was gehört zum System? - Was sind Fremd- (Dritt-) systeme? Zu beantwortende Fragen: - Was kann das Programm (Funktionalität)? - Was ist das System (was ist zu entwickeln)? - Was ist des Nutzen des Systems? 15

16 Einschränkungen, Randbedinungen, Annahmen - Geld - Zeit - Stakeholder (s.u.) - Technologie (Sprache, OS, Plattform, existierende SW (Versionen) - Gesetze Annahmen - Volumina, Häufigkeit der Benutzung - Benutzerskills, Stakeholder (Alle an Entwicklung, Betrieb, Vermarktung Beteiligte oder Betroffene) - Benutzer - Auftraggeber - Abnehmer - Profiteure - Betreiber 16

17 3.2 Aktivitäten - Brainstorming, - Gespräch, Workshop - Use Case Analyse - Prototyping - Vorstudie (Alternative, Problemstellung) 3.3. Ergebnisse, Artefakte - Freitext - UML Diagramme (Use Cases, Klassendiagramme,..) - GUI (Papier, Grafik, Dummy (VB),...) - Benutzerhandbuch - Glossare, Abkürzungsverzeichnisse,... Tipps für die Beschreibung - Gegenstände, Personen => Geschäftklassen - Rollen und Personen, Berechtigungen - Arbeitsabläufe (workflow) - Ereignisse ("wenn,...") - Bedingungen ("benötigt", "hat immer") - Kommunikation 17

18 Allgemeine Anforderungen - Vollständig - Widerspruchsfrei, konsistenz - Nicht redundant - Verständlich -Dokumentiert - Nachvollziehbar (durch verschiedene Phasen, "tracking") 18