Zusammenfassung
=======
Scope Kriechen ist ein erhebliches Risiko in Software-Entwicklungsprojekten. Wir diskutieren, warum dies so ist, und wie man sie vermeiden oder zumindest zu mildern das Risiko.

Was ist Anwendungsbereich kriechen?
================
Neue Software entwickelt, ist in der Regel als Folge eines Kunden (der kann es sich um eine interne oder eine externe Organisation) ermitteln müssen. Der nächste Schritt besteht darin, festzulegen, wie die Software, die es erfüllen; speziell, was Funktionalität entwickelt werden. Dies ist der "Geltungsbereich" des Projekts. Die Projektpläne erstellt, basierend auf den Schätzungen für die Entwicklung und Bereitstellung der spezifizierten Funktionalität und ein Enddatum vereinbart.

Entwicklung beginnt und das Projekt scheint zu sein, kommt gut voran. Aber dann die Kunden realisiert, dass es zusätzliche Anforderungen sie vergaß zu erwähnen, oder zusätzliche Elemente der Funktionalität, die sie benötigen. Oft ist das Hinzufügen dieser Extras wird dazu führen, dass das Projekt auf Dauer verlängert werden, was zu verpassten Fristen und erhöhte Kosten, was zu einer Aushöhlung des Marge auf das Projekt und potenziell Kunden Unzufriedenheit und den Verlust der Glaubwürdigkeit wegen verspäteter Lieferung.

Der Umgang mit den Anwendungsbereich Kriechen
======================
Es ist wichtig, dass eine funktionale Spezifikation hergestellt wird bereits am Anfang geschrieben, dass im Hinblick auf den Kunden verstehen können. Beispiel: Ein Gang durch die der Prozess, der die Software-Unterstützung, vielleicht illustriert mit spottete-up Screen Shots, helfen zu klären, wie das neue System funktionieren wird aus der Sicht des Anwenders.

Die funktionale Spezifikation muss vereinbart und unterzeichnet durch den Kunden, und sollte eine Scope Statement. Diese besagt, dass nur die Funktionalität, die ausdrücklich in der Spezifikation ist im Rahmen des Projekts, und dass alles, was nicht beschrieben ist "draußen Reichweite".

Wenn der Kunde später weitere Elemente identifiziert wird Bezug genommen auf die Spezifikation: Ist die geforderte Funktionalität beschrieben oder angedeutet? Ist dies nicht der Fall, dann der Neubau außerhalb der Reichweite ist.

Der nächste Schritt ist, um die Auswirkungen der Entwicklung der neuen Funktionalität: was zusätzliche Anstrengungen erforderlich? Welche Auswirkungen hat dies auf die gesamte Laufzeit des Projekts? Welche zusätzlichen Kosten anfallen werden und wie wird sich dies auf die Projekt-Marge?

Wenn die Wirkung ist trivial, so kann vereinbart werden, um die neue Funktionalität in das bestehende Projekt, sondern im Idealfall sollte dies in Schriftform durch die Ausgabe eine überarbeitete Spezifikation. Die Gefahr dabei ist, dass der Kunde der Ansicht, dass ein Präzedenzfall geschaffen wurde und dass weitere Revisionen werden in ähnlicher Weise: Es ist wichtig zu kommunizieren, die Gründe für die Zulassung der Revision in diesem Fall.

Es ist eher wahrscheinlich, dass die zusätzliche Entwicklung wird dazu führen, dass Verzögerungen und / oder zusätzliche Kosten. Der Kunde muss darauf hingewiesen werden, daß die Auswirkungen der Revision im Hinblick auf ihre Auswirkungen auf die Fristen und Kosten sowie eine Spezifikation der Ergänzungen und Änderungen sollten schriftlich (mit einem eigenen Scope Statement). Es liegt dann an den Kunden zu entscheiden, ob sie bereit sind, mehr zu bezahlen, und wenn sie akzeptieren kann die überarbeitete Enddatum für das Projekt. Wenn sie damit einverstanden sind, die neue Spezifikation sollte wie bisher.

Brauchen wir wirklich ein Scope Statement?
=============================
Sie mögen glauben, dass schriftlich eine hinreichend genaue Spezifikation zu können, machen den Scope Statement würde bedeuten, mehr Zeit (und Kosten) als gerechtfertigt ist durch den Wert des Projekts als Ganzes. Zum Beispiel, wenn das gesamte Projekt wird voraussichtlich nur ein paar Wochen und würde es 5 Tage zu schreiben, eine detaillierte Spezifikation, eine Kosten-Nutzen-Analyse würde zeigen, dass es sich nicht lohnt tun.

Wenn dies der Fall ist, beurteilen die Wahrscheinlichkeit des Risikos (basierend auf dem Wissen des Kunden und wie zuversichtlich sind Sie, dass alle Anforderungen festgestellt worden) und die möglichen Auswirkungen, und bauen in ausreichender Kontingenz in Ihrem Schätzungen von Zeit und Kosten auf alle, aber die meisten wichtigen Änderungen der Spezifikationen.

Article Source: http://www.articleset.com