Betriebliche Softwareentwicklung

Ein Pflichtenheft spezifiziert aus Auftragsnehmersicht das zu entwickelnde Software-Produkt.

- Kann eine Verfeinerung des Lastenhefts sein oder

- in eine andere Form überführt werden.

1. Ziele des Systems

Muss-, Kann- und Abgrenzungskriterien

2. Einatzbedingungen

Anwendungsbereiche, Zielgruppen, Betriebsbedingungen

3. Produktübersicht

4. Produktfunktionen

5. Produktdaten

6. Leistungen (Performance)

7. Qualitätsziele

Portabilität, Änderbarkeit, Wartbarkeit

8. Benutzeroberfläche

9. Nichtfunktionale Anforderungen

Gesetze, Normen, Testat, Revisionsfähigkeit

10. Technische Produktumgebung

11. Entwicklungsumgebung

12. Gliederung in Teilprodukte

13. Ergänzungen

Bereitstellung von Testdaten und -personal

1. Einführung in das Projekt

Veranlassung, Zielsetzung, Projektumfeld, Termine, Personal, Kostenrahmen

2. Beschreibung der Ausgangslage (Ist-Zustand)

Arbeitsgebiete, Verantwortlichkeiten, Zuständigkeiten

3. Aufgabenstellung, Funktionale Anforderungen

4. Schnittstellen

5. Anforderungen an die Systemtechnik

- Leistungsdaten (Antwortzeiten, Durchsatz)

- Verfügbarkeit

- Robustheit

6. Anforderungen für die Inbetriebnahme und den Einsatz

Dokumentation, Inbetriebnahme, Probebetrieb, Abnahmen, Schulung, Betriebsablauf, Instandhaltung

7. Anforderungen an die Qualität

Qualitätsmerkmale, Qualitätsicherung

8. Anforderungen an die Projektabwicklung

Personal, Zuständigkeit, Projektplanung

Anhang

Begriffe und Defiitionen

Gesetze, Normen, Richtlinien

Abkürzungen

Vorgehen

- Identifikation eines ähnlichen, abgeschlossenes Projekts

- Verwendung des Aufwand des abgeschlossenen Projekts als Schätzwert für das neue Projekt

- Ggf. Verwendung von Korrekturfaktoren (bekannte vs. unbekannte Domäne, Erfahrungen MA, Vertrautheit mit der Technologie)

Voraussetzungen

- Passende abgeschlossene Projekte existieren

- Der Aufwand wurde korrekt erfasst

- beide Projekt sind so gut beschrieben, dass eine Analogie festgestellt werden kann

Aufwand

- gering bis mittel

Vorgehen

- Aufwandsschätzung durch Experten

- Zerlegung des Projekts in Teilaufgaben

- Schätzung der Teilaufgaben (ggf. Diskussion, falls 2 Schätzungen stark abweichen)

- Gesamtaufwand = Summe der Teilaufgaben

Voraussetzungen

- Es gibt Experten

- Das Projekt wurde in Teilaufgaben zerlegt

Aufwand

- mittel bis hoch (je nach Anzahl der Experten und Teilaufgaben)

Vorgehen

Annahme, das die Phasen einer SW-Entwicklung immer einen ähnlichen Anteil am Gesamtaufwand haben.

z.B.

- Anforderungsdefinition: 25%

- Design: 10%

- Programmierung: 15%

- Test: 25%

- Inbetriebnahme: 25%

Nach Abschluss einer Phase kann der Gesamtaufwand hochgerechnet werden.

Voraussetzungen

- Es wurden Prozentsätze dür die Phasen in historischen Projekten gebildet

- Mind. eine Phase ist abgeschlossen

- Das SW-Projekt kann in Phasen eingeteilt werden

Aufwand

- gering

SW-Requirements

- sind Anforderungen des Kunden an die Funktionen uns Qulität des Systems

- müssen von allen Projektbeteiligten verstanden werden (meist in natürlicher Sprache geschrieben)

- werden in einem Dokument zusammengefasst (z.B. Lastenheft, Spezifikation oder Pflichtenheft)

- sind die Grundlage der Tests. (ohne Requirements ist kein Akzeptanztest möglich)

-

Bild

-

-

-

-

-

-

offen

-

-

-

Auftraggeber

Stakeholder

Scrum Team

- Product Owner

- SCRUM Master

- SCRUM Team

- Moderator- und Unterstützungdfunktion für das SCRUM-Team

- Sorgt für die Einhaltung der SCRUM-Regeln und Abläufe

- Vertritt das Interes des Kunden und ist verantwortlich für das Produkt-Backlog

- Definiert und Priorisiert die Anforderungen und legt somit die Prioritäten für die Arbeiten im Team fest

Aufgaben

- Entwicklung eines Produkts entsprechend der Anforderungen aus dem Product-Backlog

Anforderungen

- Selbstorganisierend

- Deckt alle benötigten Fähigkeiten und Fachkenntnisse ab

- nicht mehr als 7 Teilnehmer

- Anpassungen nach jedem Sprint möglich

Scrum– Artefakte

• Vision (Idee)
• ProductBacklog: Alle noch zu liefernden Funktionalitäten (eine vom ProductOwner nach Geschäftswert geordnete Liste von Produktanforderungen)
• ProductBacklog Item: Die zu liefernden Funktionalitäten, die in einem ProductBacklog aufgelistet sind
• Sprint Goal: Ziel des Sprints (festgelegt von Team und ProductOwner)
• Selected ProductBacklog: Für diesen Sprint ausgewählte Backlog Items (entsteht im Sprint Planning Meeting 1)
• Aufgaben: alles was getan werden muss, um das Ziel des Sprints zu erreichen
• Sprint Backlog: Täglich aktualisierte Liste von offenen Backlog Items des akt. Sprints (entsteht im Sprint Planning Meeting 2)
• Releaseplan: Übersichtsplan (informativ) der Backlog Items und Ihrer zugehörigen Sprints (zeigt, in welchem Sprint welches Backlog Item vom Team geliefert werden kann)
• ImpedimentBacklog: Liste aller Blockaden, die ausgeräumt werden müssen