-
Kartei Details
| Karten | 25 |
|---|---|
| Sprache | Deutsch |
| Kategorie | Informatik |
| Stufe | Universität |
| Erstellt / Aktualisiert | 14.02.2016 / 26.01.2022 |
| Weblink |
https://card2brain.ch/box/betriebliche_softwareentwicklung
|
| Einbinden |
<iframe src="https://card2brain.ch/box/betriebliche_softwareentwicklung/embed" width="780" height="150" scrolling="no" frameborder="0"></iframe>
|
Definition Lastenheft
Ein Lastenheft fast alle Anforderungen zusammen, die das zu entwickelnde Software-Produkt aus Sicht des Auftraggebers erfüllen muss.
Definition Pflichtenheft
Ein Pflichtenheft spezifiziert aus Auftragsnehmersicht das zu entwickelnde Software-Produkt.
- Kann eine Verfeinerung des Lastenhefts sein oder
- in eine andere Form überführt werden.
Bestandteile eines Pflichtenheftes nach VDI 3694
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
Bestandteile eines Lastenheft nach VDI 3694
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
Erläuterung der Schätzmethode Analogoemethode/Relationsmethode
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
Erläuterung der Schätzmethode Expertenschätzung
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)
Erläuterung der Schätzmethode Prozentsatzmethode
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
Anforderungen an SW-Requirements
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)
Aufgabe 2 aus T2
-
Grundlagen der Vererbung
Bild
Bsp. UML-Notation Vererbung und abstrakte Klassen
-
Erläuterung abstrakte Klassen
-
Erläuterung Klassenattribut
-
Aufgabe 1 aus T3
-
Erläuterung von Kapselung: Geheimnisprinzip
-
Zustandsdiagramme in UML
-
Aufgabe 4 aus T3
offen
Ziel des Testens
-
Testgegendstand
-
Was ist SCRUM?
-
Rollen in SCRUM
Auftraggeber
Stakeholder
Scrum Team
- Product Owner
- SCRUM Master
- SCRUM Team
Aufgaben SCRUM Master
- Moderator- und Unterstützungdfunktion für das SCRUM-Team
- Sorgt für die Einhaltung der SCRUM-Regeln und Abläufe
Aufgaben Product Owner
- 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 und Anforderungen des SCRUM Team
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
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
