Einführung in Software Engineering
Einführung in Software Engineering
Einführung in Software Engineering
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
(7) Spr<strong>in</strong>t Backlog<br />
(a) Aufgabenliste für e<strong>in</strong>en Spr<strong>in</strong>t<br />
(b) täglich vom Team präzise geführt<br />
(8) Spr<strong>in</strong>t Rewiev Meet<strong>in</strong>g<br />
(a) Sitzung am Ende e<strong>in</strong>es Spr<strong>in</strong>ts<br />
(b) Vorstellung fertiger Funktionalitäten – ke<strong>in</strong>e Dummies oder Grafiken<br />
(9) Scrum‐Master<br />
(a) Für Scrum‐Prozess verantwortliche Person<br />
(b) sorgt für korrekte Implementierung und maximalen Nutzen des Prozesses<br />
(c) sollte ke<strong>in</strong>e Doppelfunktion als Teammitglied haben<br />
(d) sollte ke<strong>in</strong> Vorgesetzter se<strong>in</strong><br />
(e) ke<strong>in</strong> Projektleiter im herkömmlichen S<strong>in</strong>ne – eher Vermittler, Unterstützer<br />
l) V‐Modell XT<br />
• Weiterentwicklung des V‐Modells<br />
• Erlaubt „Agile Projektdurchführungsstrategie“<br />
4) Kap 4. Requirements Eng<strong>in</strong>eer<strong>in</strong>g<br />
a) Durchführungsprüfung von <strong>Software</strong> Projekten<br />
• ökonomische, fachliche, personelle Durchführung prüfen<br />
• Unterscheidung zwischen <strong>Software</strong>projekten:<br />
(1) für konkreten Auftraggeber<br />
(a) Was genau will dieser?<br />
(2) anonymer Markt<br />
(a) Bedarf und Rentabilität klären<br />
• Ökonomische Durchführbarkeit (Machbarkeitsstudie)<br />
(1) ROI‐Return on Investment <strong>Software</strong>entwicklung muss sich lohnen<br />
(2) Trifft nicht zu bei:<br />
(a) Änderungen aufgrund neuer gesetzlicher Bestimmungen<br />
(b) Ablösung veralteter Technologie<br />
(3) Problem bei Kostenabschätzung<br />
(a) Was soll man alles berücksichtigen – Schulungen, Krankheit …<br />
(4) Problem bei Nutzenabschätzung<br />
(a) Was br<strong>in</strong>gt es wenn Mitarbeiter besser auf Informationen zugreifen können<br />
(5) Bestandteile e<strong>in</strong>er Machbarkeitsstudie<br />
(a) Lastenheft: grobe Auflistung fachlicher Anforderungen des Auftraggebers<br />
(b) Projektkalkulation: geschätzte Kosten für <strong>Software</strong>produkt<br />
(c) Projektplan: Zeitplan für Projektdurchführung, mit Phasen, Phasenergebnissen<br />
und Verantwortlichen<br />
(d) Große Probleme:<br />
(i) wie ist Umfang/Größe e<strong>in</strong>es <strong>Software</strong>produkts def<strong>in</strong>iert?<br />
(ii) wie lässt sich Produktumfang ohne Betrachtung der Realisierung schätzen?<br />
(iii) <strong>in</strong> welchem Verhältnis stehen Produktumfang, Entwicklungszeit und –<br />
kosten?<br />
• Ermittlung von Anforderungen (Anforderungsanalyse)<br />
(1) Needs – Problembeschreibung/ Warum die <strong>Software</strong><br />
(2) Features – Lastenheft mit Hauptfunktionen<br />
(3) <strong>Software</strong> Requirements = Pflichtenheft – detaillierte Beschreibung der<br />
<strong>Software</strong>funktionen<br />
(4) Fast e<strong>in</strong> Drittel bis zur Auslieferung nicht entdeckter Fehler s<strong>in</strong>d Analysefehler,<br />
dessen Beseitigung sehr teuer ist.<br />
(5) Arten von Anforderungen<br />
(a) funktionale Anforderungen: primäre Funktionen und E<strong>in</strong>‐ Ausgabeverhalten<br />
(b) nichtfunktionale Anforderungen:
Change language