Bachelor Informatik (21) Fallstudie Prozessmodellierung ( 21.3) Teil 2

1. Bachelor Informatik (21)Fallstudie Prozessmodellierung (21.3)Teil 2

2. Allgemeines- Teilgebiete der Softwaretechnik Kernprozesse (1 – 3 relevant für die Fallstudie) 1. Planung 2. Analyse 3. Entwurf (!!!) Anm.: 1. und 2. können zusammen gefasst werden!

3. Allgemeines- Teilgebiete der Softwaretechnik weitere Kernprozesse 4. Programmierung 5. Validierung und Verifikation

4. Allgemeines- Teilgebiete der Softwaretechnik Unterstützungsprozesse 6. Anforderungsmanagement 7. Projektmanagement 8. Qualitätsmanagement 9. Konfigurationsmanagement 10. Dokumentation

5. 1. Planung • Lastenheft (Anforderungsdefinition) • Pflichtenheft (mit technischen Ansätzen verfeinertes Lastenheft) Anm.: in der Ausarbeitung synonym „Planung“ verwenden

6. 1. Planung - Lastenheft • Ein Lastenheft (auch Anforderungs-spezifikation, Kundenspezifikation oder Requirements Specification) beschreibt die unmittelbaren Anforderungen durch den Besteller eines Produktes.

7. 1. Planung - Lastenheft • Es enthält jedoch lediglich im Rahmen eines Werkvertrages oder Werkliefervertrages und der dazu gehörenden formellen Abnahme die nachprüfbaren Leistungen und Lieferungen.

8. 1. Planung - Lastenheft • Es kann nicht die Erwartungen und Wünsche an ein geplantes Produkt enthalten.

9. 1. Planung - Lastenheft • Diese abstrakten Merkmale wären, wenn nicht durch eine Prüfung zu belegen, kaum durch denjenigen, der das Produkt herstellen soll, so einzuschätzen, dass sie zielführend berücksichtigt werden könnten.

10. 1. Planung - Lastenheft • Gemäß DIN 69905 (Begriffe der Projektabwicklung) beschreibt das Lastenheft die „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages“.

11. 1. Planung - Lastenheft • Das Lastenheft beschreibt in der Regel also, was und wofür etwas gemacht werden soll (Fachkonzept). • Die Adressaten des Lastenhefts sind der (externe oder firmeninterne) Auftraggeber sowie die Auftragnehmer.

12. 1. Planung - Lastenheft • In der Softwaretechnik ist das Lastenheft das Ergebnis der Planungsphase und wird in der Regel einvernehmlich von den Bestellern und den Entwicklern als Vorstufe des Pflichtenhefts überarbeitet.

13. 1. Planung - Lastenheft • Um ein Lastenheft übersichtlich zu halten, wird es vorzugsweise in knapp orientierendem Text gefasst und mit Detaillierungen beispielsweise in tabellarischer Form, mit Zeichnungen oder Grafiken ergänzt. • Es gibt dazu auch formalisierende Ansätze, wie die Beschreibungssprache UML.

14. 1. Planung - Lastenheft • Das Pflichtenheft beschreibt dann, was und womit etwas realisiert werden soll. • Dabei können gewöhnlich jeder Anforderung des Lastenhefts eine oder mehrere Leistungen des Pflichtenheftes zugeordnet werden. • So wird auch die Reihenfolge der beiden Dokumente im Entwicklungsprozess deutlich: Die Anforderungen (requirements) werden durch Leistungen (features) erfüllt.

15. 1. Planung - Lastenheft • Nach DIN 69905 enthält das Pflichtenheft die „vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes“.

16. 1. Planung - Lastenheft • Je nach Einsatzgebiet und Branche können sich Lastenhefte in Aufbau und Inhalt stark unterscheiden. Auch werden in der Praxis die Begriffe Lastenheft, Pflichtenheft und Spezifikation oft nicht klar gegeneinander abgegrenzt oder gar synonym verwendet.

17. 1. Planung - Lastenheft • Die unscharfe Verwendung der Begriffe Lastenheft und Pflichtenheft sowie die fehlende Trennung technischer Information und operationeller Absichten ist häufig Ursache für Missverständnisse.

18. 1. Planung - Lastenheft • Auf einen Kaufvertrag nach BGB §433 oder einen rechtlich gleichgestellten Liefervertrag sind die Kriterien eines Lastenheftes in der Regel nicht anzuwenden, da die Lieferungen im Kaufvertrag von einer durch den Lieferanten einseitig vorgegebenen Spezifikation in der Art und von der durch den Besteller einseitig vorgegebenen Liefermenge bestimmt werden.

19. 1. Planung - Lastenheft • Auf einen Dienstvertrag sind die Kriterien eines Lastenheftes in der Regel nicht anzuwenden, da die Leistungen im Dienstvertrag nicht einer formellen Abnahme unterzogen werden.

20. 1. Planung - Pflichtenheft • Das Pflichtenheft, auch Technische Richtlinien, Fachspezifikation, fachliche Spezifikation, Fachfeinkonzept, Sollkonzept, Funktionelle Spezifikation, oder Feature Specification beschreibt die unmittelbaren Anforderungen durch den Besteller in der Interpretation des Herstellers für sein Produkt.

21. 1. Planung - Pflichtenheft • Es enthält jedoch lediglich im Rahmen eines Werkvertrages oder Werkliefervertrages und der dazu gehörenden formellen Abnahme die prüfbaren Leistungen und Lieferungen.

22. 1. Planung - Pflichtenheft • Es kann, genauso wie das Lastenheft, nicht die Erwartungen und Wünsche an ein geplantes Produkt enthalten.

23. 1. Planung - Pflichtenheft • Solche abstrakten Merkmale wären, wenn nicht durch eine Prüfung oder Messung zu belegen, durch denjenigen, der das Produkt herstellt, auch eher nicht so einzuschätzen, dass sie zielführend während der Bearbeitung des Werkes und final bei der Abnahme berücksichtigt werden könnten.

24. 1. Planung - Pflichtenheft • Das Pflichtenheft ist die vertraglich bindende, detaillierte Beschreibung eines zu erstellenden Werkes, zum Beispiel des Aufbaus einer technischen Anlage, der Konstruktion eines Werkzeugs oder auch der Erstellung eines Computerprogramms.

25. 1. Planung - Pflichtenheft • Die dazu erforderliche Arbeit liegt allein in der Verantwortung des Herstellers oder Auftragnehmers, diese ist zunächst nicht der Einrede des Bestellers oder Auftraggebers unterworfen, es sei denn, beide arbeiten gemeinsam an dem zu erstellenden Werk.

26. 1. Planung - Pflichtenheft • Laut DIN 69905 umfasst das Pflichtenheft die „vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts“.

27. 1. Planung - Pflichtenheft • Die Inhalte des zuvor ausgearbeiteten Lastenhefts (auch grobes Pflichtenheft genannt) sind nun präzisiert, vollständig und nachvollziehbar sowie mit technischen Festlegungen der Betriebs- und Wartungsumgebung verknüpft.

28. 1. Planung - Pflichtenheft • Das Pflichtenheft wird vom Auftragnehmer (Entwicklungsabteilung/-firma) formuliert und auf dessen Wunsch vom Auftraggeber bestätigt. Idealerweise sollten erst nach dieser Bestätigung die eigentlichen Entwicklungs-/Implementierungsarbeiten beginnen.

29. 1. Planung - Pflichtenheft • Der Auftragnehmer hat einen durch den Vertrag bestimmten Anspruch auf solche Bestätigung (Mitwirkungspflicht nach §643 BGB).

30. 1. Planung - Pflichtenheft • Im Gegensatz zum technischen Design (auch technische Spezifikation – Wie wird es umgesetzt?) beschreibt das Pflichtenheft die geplante technische Lösung – in unserem Beispiel die Software – als Black Box (Was wird umgesetzt?).

31. 1. Planung - Pflichtenheft • Entsprechend enthält es in der Regel nicht die betriebliche Lösung der Aufgabenstellungen des Auftraggebers. • Schon gar nicht beschreibt es die (hier beim Softwarebeispiel) Implementierungsprobleme, sondern allenfalls die Schnittstellen, deren sorgfältige Beschreibung solche Probleme vermeiden soll.

32. 1. Planung - Pflichtenheft • Es ist bewährte Praxis, bei der Erstellung eines Pflichtenheftes das Ein- und Ausschlussprinzip zu verwenden, d. h., konkrete Fälle explizit ein- oder auszuschließen.

33. 1. Planung - Pflichtenheft • Bei Lieferung der Software wird formell eine Abnahme vollzogen, die die Ausführung des Werkvertrages oder auch des Kaufvertrages beschließt. • Diese Abnahme wird häufig über einen Akzeptanztest ausgeführt, der feststellt, ob die Software die Forderungen des Pflichtenheftes in dem Verständnis des Bestellers erfüllt.

34. 2. Analyse • Anforderungsanalyse • Auswertung • Mock-up • Prozessanalyse / Prozessmodell • Systemanalyse • Strukturierte Analyse (SA) • Objektorientierte Analyse (OOA)

35. 2. Analyse - Anforderungsanalyse • Das ingenieurmäßige Erheben der Anforderungen (englisch requirements engineering) ist ein Teil des Software- und Systementwicklungsprozesses.

36. 2. Analyse - Anforderungsanalyse • Ziel ist es, die Anforderungen des Auftraggebers an das zu entwickelnde System (oft ein Anwendungsprogramm) zu ermitteln und zu verwalten.

37. 2. Analyse - Anforderungsanalyse IEEE - Institute of Electrical and Electronics Engineers • Die Anforderungserhebung kann in Anforderungsaufnahme (requirements elicitation), Anforderungsanalyse (requirements analysis), Anforderungsspezifikation (requirements specification) und Anforderungsbewertung (requirements validation) unterteilt werden. Diese Schritte überlappen einander und werden oft auch mehrfach – iterativ – durchgeführt. http://www.ieee.org/index.html

38. 2. Analyse - Anforderungsanalyse SEI, Carnegie Mellon • Das Software Engineering Institute der Carnegie Mellon Universität unterscheidet in ihrem Capability Maturity Model Integration das Management von Anforderungen, und die Entwicklung der Anforderungen.

39. 2. Analyse - Anforderungsanalyse Volere • In dem von den Robertsons entwickelten Vorgehensmodell existieren Anforderungsspezifikation, Stakeholder-Analyse, Bedarfsanalyse, Analyse der Priorisierung, und die Aufzeichnung der elementaren Anforderungen.

40. 2. Analyse - Anforderungsanalyse • Sammeln, Analysieren

41. 2. Analyse - Anforderungsanalyse • Beim Sammeln der Anforderungen (engl. elicitation) ist der Übersetzungsprozess zwischen Fachseite und Entwickler von besonderer Bedeutung.

42. 2. Analyse - Anforderungsanalyse • vollständig - alle Anforderungen des Kunden müssen explizit beschrieben sein, es darf keine impliziten Annahmen des Kunden über das zu entwickelnde System geben.

43. 2. Analyse - Anforderungsanalyse • eindeutig definiert / abgegrenzt- präzise Definitionen helfen, Missverständnisse zwischen Entwickler und Auftraggeber zu vermeiden.

44. 2. Analyse - Anforderungsanalyse • verständlich beschrieben - damit sowohl der Auftraggeber als auch der Entwickler mit vertretbarem Aufwand die gesamte Anforderung lesen und verstehen können.

45. 2. Analyse - Anforderungsanalyse • atomar - es darf nur eine Anforderung pro Abschnitt oder Satz beschrieben sein. Das Kriterium für ein "Atom" sollte die Entscheidbarkeit einer Anforderung sein.

46. 2. Analyse - Anforderungsanalyse • identifizierbar - jede Anforderung muss eindeutig identifizierbar sein (z. B. über eine Kennung oder Nummer).

47. 2. Analyse - Anforderungsanalyse • einheitlich dokumentiert - die Anforderungen und ihre Quellen sollten nicht in unterschiedlichen Dokumenten stehen oder unterschiedliche Strukturen haben.

48. 2. Analyse - Anforderungsanalyse • notwendig - gesetzliche Vorschriften sind unabdingbar.

49. 2. Analyse - Anforderungsanalyse • nachprüfbar - die Anforderungen sollten mit Abnahmekriterien verknüpft werden, damit bei der Abnahme geprüft werden kann, ob die Anforderungen erfüllt wurden (Ableitung von Testfällen aus den Abnahmekriterien).

50. 2. Analyse - Anforderungsanalyse • rück- und vorwärtsverfolgbar- damit einerseits erkennbar ist, ob jede Anforderung vollständig erfüllt wurde und andererseits für jede implementierte Funktionalität erkennbar ist, aus welcher Anforderung sie resultiert, also nicht Überflüssiges entwickelt wird.