Pflichtenheft von byteme - PI - Praktische Informatik
Pflichtenheft von byteme - PI - Praktische Informatik
Pflichtenheft von byteme - PI - Praktische Informatik
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
68 KA<strong>PI</strong>TEL 7. QUALITÄTSSICHERUNG<br />
7.6.1 Mangelhafter Zeitplan<br />
Problem:<br />
Der Projektumfang wird <strong>von</strong> Anfang an komplett unterschätzt. Es ist möglich, dass<br />
wirklich eine ehrliche Schätzung versucht wurde und diese völlig falsch lag, doch oftmals<br />
ist eher der Grund, dass Wunschtermine zu festen Lieferdaten gemacht werden.<br />
Zusammen mit anderen unumstößlichen Randbedingungen des Projekts führt dies zu<br />
einem Projekt, das nach [1] „overconstrained“ ist.<br />
Risiko:<br />
Mittel - Der Umfang des Projektes scheint in unseren Augen gut abschätzbar zu sein.<br />
Vorbeugende Maßnahmen:<br />
Der Abgabetermin ist <strong>von</strong> Seiten der Universität festgesetzt und somit unabänderlich.<br />
Wir benutzen jedoch einen iterativen Entwicklungsprozess, wodurch sichergestellt ist,<br />
dass auch frühe Versionen unserer Software bereits eine gewisse Kernfunktionalität<br />
besitzen. In jedem Fall sollte der <strong>von</strong> uns aufgestellte Iterationsplan im Auge behalten<br />
werden, um Verzögerungen im Zeitplan schnell zu erkennen und darauf zu reagieren.<br />
Wenn das Risiko zu einem Problem wird:<br />
Sollten wir unter hohen Zeitdruck geraten, bietet sich an, nur die Kernfunktionalitäten<br />
des Programms zu implementieren. Zu diesem Zweck sind die Use Cases nach<br />
Schwierigkeit und Priorität sortiert. Sollte sich das Risiko manifestieren, so werden<br />
wir im Zweifelsfall trotz der Einplanung einer Pufferzone am Ende unseres Zeitplans<br />
einige niedrig-priorisierte Features nicht fertiggestellen können. Da das Projekt auch<br />
nach Abschluss der Software Engineering-Veranstaltung als Open-Source-Projekt weitergeführt<br />
wird, besteht dennoch Hoffnung, dass noch nicht implementierte Features<br />
<strong>von</strong> anderen Entwicklern der Open-Source-Gemeinde aufgegriffen und außerhalb des<br />
Rahmens dieser Veranstaltung verwirklicht werden.<br />
7.6.2 Keine ordentliche Spezifikation<br />
Problem:<br />
Der Auftraggeber kann sich nicht zu einer genauen Spezifikation des zu erstellenden<br />
Softwareprodukts durchringen bzw. es gibt widersprüchliche Anforderungen <strong>von</strong> verschiedenen<br />
Seiten.<br />
Risiko:<br />
Hoch - Die bisher vom Auftraggeber erhaltenen Anforderungen sind sehr allgemein<br />
gehalten. Ein Grund dafür mag sein, dass das Projekt nicht die Erstellung <strong>von</strong> unternehmenskritischer<br />
Software zum Ziel hat, sondern mehr als Machbarkeitsstudie, fast<br />
schon als „Experiment“ gesehen wird.
Change language