Zwei Welten für die Schätzung von Softwareprojekten

Auf den ersten Blick scheint es, dass es zwei Welten für die Schätzung von Softwareprojekten gibt, der Einfachheit halber, Ich werde die "chaotische" und die "kontrollierte" Welt nennen. Die chaotische Welt ist geprägt von der Mehrheit der Organisationen, deren Projekte häufig den Zeit- und Budgetrahmen überschreiten, oder die völlig scheitern. In der kontrollierten Welt gibt es eine sehr viel kleinere Anzahl vorbildlicher Organisationen, deren Projekte angeblich regelmäßig im Zeit- und Budgetrahmen umgesetzt werden. Die interessante Frage ist, warum Organisationen in der chaotischen Welt nicht einfach das Verhalten derjenigen in der kontrollierten Welt lernen und kopieren und sich so viel Geld sparen können.
Dieser Artikel untersucht die beiden Welten und zielt darauf ab, die Unterschiede zu erklären, die teilweise intrinsisch und zu einem gewissen Grad unvermeidbar sind, und teilweise aufgrund einer Mischung aus kulturellen, Prozess- und technische Faktoren, Einige davon können mit genügend Anstrengung und Ausdauer überwunden werden.
Zuerst, der Beweis für die beiden Welten.

Die chaotische Welt

Es gab mehrere Umfragen, deckt die Ergebnisse Tausender Softwareprojekte ab, hauptsächlich in den USA und Großbritannien und hauptsächlich von Projekten aus dem Bereich Unternehmensanwendungssoftware, im öffentlichen oder privaten Sektor. Streng genommen sollte man von „softwareintensiven Systemprojekten“ sprechen., Denn bei vielen dieser Projekte ist die Lieferung der Software nur ein Teil eines Projekts, das ein Hardware-/Softwaresystem und oft auch organisatorische Veränderungen liefern muss. Der Einfachheit halber verwende ich „Softwareprojekte“.. Die Ergebnisse variieren, deuten jedoch darauf hin, dass zwischen 10% – 30% der Softwareprojekte scheitern komplett, d.h.. Sie werden gestoppt, bevor sie etwas Nützliches liefern. Noch eins ungefähr 50% Zeit- und/oder Budgetüberschreitung um mindestens 10%. Das geht nur 20% – 40% von Projekten, die termin- und budgetgerecht geliefert wurden.

jedoch, Diese Zahlen spiegeln nicht die Tatsache wider, dass viele Projekte weniger Funktionalität oder Geschäftswert liefern als ursprünglich geplant. Des Weiteren, Ein unbekannter Anteil der Projekte, die „im Zeit- und Budgetrahmen“ abgeschlossen wurden, wurde möglicherweise von vornherein überschätzt und hätte schneller und zu geringeren Kosten umgesetzt werden können. Abdel-Hamid stellte fest, dass das Parkinson-Gesetz für Softwareprojekte wie für jede andere Aktivität gilt, d.h.. Die Arbeit dehnt sich aus, um die für ihre Vollendung zur Verfügung stehende Zeit auszufüllen.

Die Kosten dieser Überschreitungen und Ausfälle sind enorm. Eine gut dokumentierte Analyse von 105 vertraglich vereinbarte Softwareprojekte, die in den letzten zehn Jahren abgeschlossen wurden 2007 zwischen Kunden des öffentlichen Sektors im Vereinigten Königreich und externen Lieferanten belief sich auf einen Gesamtwert von 29,5 Milliarden Pfund. Von diesen, 30% wurden beendet, 57% es kam zu Kostenüberschreitungen bei der Durchschnittsbildung 30.5% (Überschreitungen in Höhe von insgesamt 9 Milliarden Pfund), während 33% kam es zu erheblichen Verzögerungen. Ein wichtiger Punkt ist, dass alle diese Projekte von externen Lieferanten durchgeführt wurden, die weltweit tätig sind und in ihrem Marketing behaupten würden, „Weltklasse“ zu sein.. Des Weiteren, Die Gewinnspanne der Lieferanten aus den Verträgen lag fast immer darüber 10%, reicht bis zu 25%.

Die gleichen Gründe für diese Ausfälle und Überschreitungen werden wiederholt angeführt, gehe zumindest zurück 30 Jahre, wie im Buch Crash beschrieben! Sie fallen in zwei Hauptgruppen.

1. Mangelndes Engagement der Geschäftsleitung und mangelnde Einbeziehung der Benutzer, was zu unklaren Zielen führt, was zu Stakeholder-Konflikten führt, und unklare und sich ändernde Anforderungen.
2. Schlechtes Projektmanagement (z.B.. im Management von Fortschritten und Veränderungen), Unerfahrenheit des Personals, vor allem, wenn es um neue Technologien geht, und Personalfluktuation.

Während die Kosten für Ausfälle und Überschreitungen möglicherweise stark durch Abschreibungen auf die Hardware belastet werden, die Kosten für die Anstellung von zusätzlichem Personal, entgangene Leistungen, etc., Die Ursachen sind fast immer auf Probleme bei der Spezifikation und Entwicklung der Software zurückzuführen.

In all den verschiedenen Analysen, warum Softwareprojekte scheitern oder überzogen werden, Es ist ungewöhnlich, dass „schlechte Schätzungen“ als eine der Ursachen aufgeführt werden. Bei den scheiternden Projekten ist das nicht verwunderlich. Eine schlechte Schätzung scheint ein unwahrscheinlicher Grund für den Abbruch eines Projekts zu sein. Es ist wahrscheinlicher, dass es gestoppt wurde, weil sich die Prioritäten seit Beginn geändert haben und es nichts Nützliches mehr liefern wird, Oder es ist so lange über das ursprüngliche Budget hinausgegangen, dass das Management beschließt, die Verluste zu begrenzen. Aber falls, sagen, 57% aller Software-Projekte werden im Durchschnitt um mehr als übertroffen 30%, Man muss sich fragen: „Ist in diesen Umgebungen etwas systematisch falsch mit dem Schätzprozess?“?‘

Die kontrollierte Welt

Von Zeit zu Zeit erhalten wir Einblicke in diese andere Welt, wenn eine Organisation Ergebnisse veröffentlicht, die ihre Erfolge bei der Schätzung von Softwareprojekten belegen. Das Exemplar, das ich verwenden werde, ist Renault, der französische Fahrzeughersteller, das seine Fortschritte bei der erfolgreichen Schätzung von Softwareprojekten veröffentlicht hat, zuletzt in 2014.

Ein modernes durchschnittliches Familienauto hat ungefähr 50 Elektronische Steuergeräte (Steuergeräte), kleine Prozessoren, die ein verteiltes Netzwerk bilden, um nahezu jede Funktion zu überwachen und/oder zu steuern, z.B.. Motor, Beleuchtung, Klimaanlage, Reifendruck, Navigation, Fahrerinformationen, etc. Die Steuergeräte und ihre eingebettete Software werden meist von Komponentenlieferanten zusammen mit den dazugehörigen Sensoren gekauft, Vorbehaltlich der von Renault herausgegebenen Spezifikationen.
Renault sammelt seit einigen Jahren Daten zu Kosten und Leistung seiner Lieferanten von Steuergerätesoftware. Der Prozess, nach dem die Beschaffung von ECUs abgeschlossen wird, ist kurz:

• Renault-Softwareabteilungen, spezialisiert auf Fahrzeugfunktionsbereiche (z.B.. Antriebsstrang), Entwickeln Sie Spezifikationen für neue oder erweiterte Steuergerätesoftware und speichern Sie diese im Matlab Simulink-Tool;
• Ein von Renault entwickeltes Tool berechnet dann automatisch eine funktionale Größe jeder Spezifikation (oder die Vergrößerung, wenn es sich um eine Verbesserung handelt) unter Verwendung des ISO-Standards COSMIC Methode;
• Mithilfe vergangener Messungen und statistisch ermittelter Zusammenhänge wird der Aufwand vorhergesagt, den der Lieferant für die Entwicklung der Software benötigen wird (siehe Abb. 1) und seine Speichergröße (Feige. 2);
• Diese Informationen werden von der Einkaufsabteilung verwendet, um den Preis für das Steuergerät auszuhandeln. Des Weiteren, Die Renault zur Verfügung stehenden Informationen sind mittlerweile hinreichend fundiert, sodass sie für die Aushandlung jährlicher Preisänderungen auf die gleiche Weise genutzt werden können, wie Automobilhersteller regelmäßig Preise für andere Materialien wie Stahl aushandeln, Farben usw., und andere Komponenten. (Feige. 3);
• COSMIC-Funktionsgrößen werden auch zur Überwachung der Leistung der internen Softwareabteilung verwendet, da Renault für seine Arbeit eine Beziehung zwischen Spezifikation, Größe und Personalebene etabliert hat.

Renault gibt das am Ende einer neuen Softwareentwicklung an, die Differenz zwischen dem ursprünglich geschätzten Aufwand aus der ermittelten Korrelation und dem tatsächlichen Wert „muss kleiner als 5 % sein“ (siehe Abb. 4).

Feige. 1 Aufwand vs. COSMIC-Größe für ECU-Software

Feige. 2 Speichernutzung vs. COSMIC-Größe

Feige. 3 Verhandlungen mit der Einkaufsabteilung

Feige. 4 Kontrolle der Genauigkeit von Kostenschätzungen

Unterschiede zwischen der chaotischen und der kontrollierten Welt der Softwareprojektschätzung

Im Folgenden, da Projektschätzungen für die gesamte Projektlaufzeit erforderlich sind, unabhängig vom Projektmanagementansatz, Der Einfachheit halber verwende ich ein Wasserfallmodell der Projektphasen. Unterschiede bei der Verwendung eines iterativen oder agilen Modells werden bei Auftreten erwähnt. Das müssen wir auch bei den Vergleichen der chaotischen und kontrollierten Welten annehmen, Die Organisationen in beiden Welten verfügen über einigermaßen wiederholbare Prozesse und verwenden Technologien, mit denen sie einigermaßen vertraut sind, d.h.. Wir werden Umgebungen ignorieren, in denen die Unreife der Prozesse und die mit der Verwendung neuer Technologien verbundenen Risiken kaum eine Chance für die Entwicklung genauer Schätzmethoden lassen.

Unterschiedliche Bedingungen für die Schätzung. In gewisser Hinsicht, Es ist unfair, einen Vergleich zwischen den beiden Welten anzustellen, da es einige wesentliche Unterschiede zwischen ihnen gibt.

Der erste und offensichtlichste Unterschied besteht in der chaotischen Welt, Für ein Geschäftsanwendungsprojekt ist in der Regel zu Beginn seiner Laufzeit eine Kostenschätzung für die gesamte Lebensdauer erforderlich, bevor die Anforderungen im Detail bekannt sind, um die Kosten-Nutzen-Analyse für die Software zu erstellen.

Im Gegensatz, Schätzungen zur Fertigstellung von Projekten in der kontrollierten Welt von Renault werden erst vorgenommen, wenn das Softwaredesign vollständig spezifiziert ist, d.h.. Es handelt sich nicht wirklich um Schätzungen für das ganze Leben. Zu diesem Zeitpunkt, Schätzungen können auch auf einer niedrigen Zerlegungsebene vorgenommen werden (Simulink blockiert im Fall Renault) vor der Aggregation zu den Kosten der gesamten ECU.

Natürlich würde man erwarten, dass die Renault-Schätzungen viel genauer sind als diejenigen, die in den frühen Phasen eines typischen Geschäftsanwendungsprojekts erstellt wurden. Nachdem ich das gesagt habe, Dann ist es berechtigt zu fragen, warum Schätzungen so früh im Projektleben vorgenommen werden, wenn es noch so viel Unsicherheit gibt, werden als fest akzeptiert, so dass es häufig zu Überschreitungen kommt. Des Weiteren, Die laufenden Wartungs- und Supportkosten, die zum Geschäftsszenario beitragen, fallen oft viel höher aus als zu diesem frühen Zeitpunkt prognostiziert.

Kulturelle Unterschiede. Eine Studie von Jorgensen über Schätzpraktiken verrät uns viel über die Kultur der chaotischen Welt. Seine Forschung ergab, dass die „Expertenschätzung“ die vorherrschende Strategie zur Schätzung des Gesamtaufwands für Entwicklungsprojekte ist. Er definierte Expertenschätzung als „Arbeit, die von einer Person durchgeführt wird, die als Experte für die Aufgabe anerkannt ist.“, und dass ein wesentlicher Teil des Schätzprozesses auf einem nicht expliziten und nicht wiederherstellbaren Argumentationsprozess basiert, d.h.. 'Intuition''. Obwohl diese Forschung in veröffentlicht wurde 2004, Jorgensen sagte mir kürzlich, dass ihm keine veröffentlichten Daten bekannt seien, die diese Ansicht ändern würden, dass Expertenschätzungen immer noch die Schätzung des Projektaufwands dominieren.

Im Gegensatz, Meine informelle Beobachtung ist, dass es sich bei den Organisationen in der kontrollierten Welt, die Daten veröffentlichen, die auf eine hohe Genauigkeit für Projektschätzungen hinweisen, größtenteils um High-Tech-Produktionsunternehmen handelt, produzieren oft sicherheits- oder geschäftskritische Software. Bei diesen Projekten muss viel Wert auf Qualität gelegt werden, Sie beginnen also mit dem Vorteil einer „echten“ Ingenieursmentalität, Verlassen Sie sich auf Daten und nicht nur auf Urteile.

Diese kulturellen Unterschiede wirken sich auf die Genauigkeit der Projektschätzung aus. Daniel Kahneman, ein Psychologe, der gewonnen hat 2002 Der Nobelpreis für Wirtschaftswissenschaften beschreibt zwei Arten menschlichen Denkens, intuitiv und rational. Meistens denken wir intuitiv; Es erfordert echte Disziplin, rational zu denken. Seine wichtigste für die Schätzung relevante Erkenntnis ist, dass intuitives Denken fast immer optimistisch ist und dazu neigt, Statistiken und vergangene Erfahrungen zu ignorieren (z.B.. im Glauben: „Dieses Mal werden wir es schaffen“). Er empfiehlt, endgültige Vorhersageentscheidungen Formeln zu überlassen, und vorzugsweise einfache mit wenigen Variablen.

Anwendung dieser Empfehlung auf eine Projektkostenschätzung basierend auf intuitivem Denken, z.B.. analog, schlägt vor, dass die Umwelt die oben genannte Erfolgsbilanz für Projekte des öffentlichen Sektors im Vereinigten Königreich vorweisen kann, Dann sollte der Business Case berücksichtigt werden 30% Gefahr eines Totalausfalls, und jede intuitive Kostenschätzung sollte automatisch um erhöht werden 15% – 20% mit einem entsprechenden Anstieg der Unsicherheit.

Kahneman hat weitere Empfehlungen, die für die Einschätzung wichtig sind, wenn harte Daten fehlen, z.B.. der Einsatz von Verfahren wie Wideband Delphi (oder „Planning Poker“ in der agilen Welt), anstatt sich auf das Fachwissen einer Person zu verlassen.

Verständnis der Rollen der verschiedenen an der Schätzung beteiligten Akteure. Die Verantwortung eines Schätzers besteht darin, auf der Grundlage der besten verfügbaren Daten eine Projektaufwandszahl zu erstellen, mit einer angemessenen Angabe des Unsicherheitsbereichs der Schätzung. Das ist alles.

Es ist die Aufgabe des Managers, die Annahmen des Schätzers zu verstehen, das Risiko und die Unsicherheit einschätzen, und letztendlich über das Projektbudget zu entscheiden. Wenn die Mentalität des Managers darin besteht, sich auf den Schätzer zu verlassen und Risiken zu ignorieren (z.B.. mit der Einstellung von Dilberts Manager: „Gib mir einfach eine Nummer“) Das Projekt ist dazu verdammt, sein Budget zu verfehlen.

Des Weiteren, wenn ein Kunde ein ITT ausstellt, um Software von einem externen Lieferanten zu beziehen, Der Kunde muss andere Faktoren verstehen, die Einfluss darauf haben, wie ein Lieferant zu seinen Schätzungen und Angebotspreisen gelangt.

Anbieter von ausgelagerten Softwaresystemen sind für ihr Überleben auf zuverlässige Schätzungen angewiesen – und wir haben oben festgestellt, dass sie in der Regel eine gute Erfolgsbilanz bei der Rentabilität vorweisen können. Daher nehmen sie die Erfassung von Softwaremetriken und deren Verwendung für Schätzungen normalerweise sehr ernst, weit mehr als eine typische interne IT-Abteilung oder die vom Kunden übernommene IT-Funktion, die seine ausgelagerten IT-Lieferanten verwaltet.

Bei einem Lieferanten, Der Kostenvoranschlag auf der Grundlage der im ITT des Kunden enthaltenen Anforderungsinformationen wird vom Vertriebsteam in ein Preis-Leistungs-Verhältnis umgewandelt. In diesem Prozess, Sie berücksichtigen viele offensichtliche Faktoren, wie zum Beispiel das voraussichtliche Budget des Kunden, die wahrscheinliche Konkurrenz, zukünftiger Cashflow, gewünschte Rentabilität, etc.

Zwei weitere weniger geschätzte, aber wichtige Faktoren werden ebenfalls berücksichtigt. Zuerst, während das Projekt fortschreitet, Dem Kunden fallen zwangsläufig neue oder geänderte Anforderungen ein, die über den Angebotspreis hinaus zusätzlich berechnet werden können. Zweite, Der Gewinner des ersten Entwicklungsprojekts ist am besten in der Lage, die laufenden Wartungs- und Supportarbeiten während der gesamten Lebensdauer des Systems zu gewinnen. Sowohl diese zusätzlichen als auch laufenden Aktivitäten können viel profitabler sein als die anfängliche Entwicklungsarbeit. Folglich, Ein Lieferant kann ein niedriges Gebot für die Erstentwicklung abgeben, um sich den Zuschlag zu sichern.

Unglücklicherweise, als vor über zwanzig Jahren die erste große Welle des IT-Outsourcings für den öffentlichen Sektor im Vereinigten Königreich begann, Der Großteil der Erfahrung mit Softwaremetriken und -schätzungen wurde im Rahmen langfristiger Verträge an die Lieferanten ausgelagert. Dies hat zu einer schwerwiegenden „Informationsasymmetrie“ zwischen Kunden und ihren Lieferanten geführt und ist mit ziemlicher Sicherheit eine Hauptursache für die hohen Budgetüberschreitungen bei IT-Projekten des öffentlichen Sektors im Vereinigten Königreich.

Für einen Automobilhersteller, Der Einkauf ist eine seiner wichtigsten Funktionen. Im Fall der IT-Beschaffung im öffentlichen Sektor des Vereinigten Königreichs, Tatsächlich übergab der Wildhüter sein Metrik-Know-how an die Wilderer.

Eine weitere Ursache für Projektüberschreitungen kann in der Art und Weise liegen, wie die Rücklagen für unvorhergesehene Ausgaben verwaltet werden. Diese sollten von einem Manager auf Projektportfolioebene verwaltet und bei Bedarf an Projektmanager weitergegeben werden, anstatt von Anfang an einzelnen Projekten zugewiesen zu werden. Zuerst, Die Kenntnis der in einem Kostenvoranschlag enthaltenen Eventualverbindlichkeiten gibt dem Projektmanager Trost und das Parkinson-Gesetz stellt sicher, dass diese auch genutzt werden. Das Gleiche gilt für eine ausgelagerte Beziehung, wo Kahneman zitiert: „Eine Haushaltsreserve ist für Auftragnehmer wie rotes Fleisch für Löwen.“; sie verschlingen es‘.

Schätztechniken. Viel Softwareprojektkalkulation in der kontrollierten Welt, am Beispiel von Renault, versucht, die vorherrschende kostengetriebene Frage „Wie groß ist es?“ zu beantworten?’ durch erfahrungsbasierte Schätzungen der Anzahl der Quellcodezeilen (SLOCK). Die bekannte Schätzmethode COCOMO II und die meisten kommerziell erhältlichen Schätzwerkzeuge wurden mit SLOC-Größen als Eingabe kalibriert. Trotz der vielen, oft beklagte Nachteile von SLOC-Größen, Es wird typischerweise behauptet, dass die Schätzgenauigkeit, die auf Expertenmeinungen aus detaillierten Entwürfen beruht, bis ins kleinste Detail genau ist 10% auf Komponentenebene.

In der chaotischen Welt, wenn für Schätzungen mehr als Intuition oder Expertenmeinung erforderlich ist, obwohl nur grobe Anforderungen vorliegen, Am häufigsten wird zunächst die Größe der Anforderungen mithilfe der Funktionspunktanalyse geschätzt (FPA). Anschließend wird die Größe mithilfe von Produktivitätsbenchmarks aus früheren ähnlichen Projekten in Aufwand umgerechnet. Albrechts ursprüngliche FPA-Idee Ende der 1970er Jahre, ein Maß für die Größe eines Softwaresystems basierend auf seinen funktionalen Anforderungen vorzuschlagen, war ein brillantes Stück Querdenken. Aber diese Methode, jetzt von der IFPUG-Organisation entwickelt und unterstützt, zeigt sein Alter.

Das KOSMISCHE Methode Die von Renault verwendete Software wurde von einer internationalen Gruppe von Experten für Softwaremetriken so konzipiert, dass sie auf Unternehmen anwendbar ist, Echtzeit- und Infrastruktursoftware, basierend auf grundlegenden Prinzipien der Softwareentwicklung. Variationen der Methode zur Ermittlung ungefährer Größen stehen zur Verfügung, um Anforderungen zu messen, bevor sie für eine genaue Messung ausreichend detailliert bekannt sind, und die Methode wurde oder wird auf verschiedene Weise automatisiert. (Automatisierte Messungen sind für Renault von entscheidender Bedeutung; Eine manuelle Zählung wäre für ihren Entwicklungsprozess zu langsam.) Die Methode eignet sich hervorragend zur Anforderungsmessung auf allen Aggregationsebenen in agilen Entwicklungen, z.B.. Benutzergeschichten. Iterationen, Veröffentlichungen, etc., und für die Komponenten verteilter Systeme.

Ein Beispiel für ein Problem, das durch die Verwendung der COSMIC-Methode vermieden werden kann, trat bei einem großen europäischen Pensionsfonds auf, der die IFPUG-FPA-Methode zur Dimensionierung als Grundlage für die Schätzung verwendet hatte. Die FPA-Skala bietet nur einen engen Größenbereich für Transaktionen; Die COSMIC-Methode misst auf einer Verhältnisskala ohne Obergrenze. Ein Projekt wurde untersucht, um herauszufinden, inwiefern es stark unterschätzt wurde. Einige Transaktionen, die das IFPUG-Maximum von erreichten 6 oder 7 Die FPs wurden mit der COSMIC-Methode erneut gemessen und es wurde festgestellt, dass sie überschritten waren 60 KOSMISCHE FPs. Die Transaktionen mit Größe über 40 COSMIC FPs machten fast alle aus 80% der Budgetüberschreitung.

Was kann getan werden, um die Schätzlücke von der chaotischen zur kontrollierten Welt zu schließen??

Jorgensens Ratschläge, wie man das Beste aus Expertenschätzungen herausholen kann, werden dringend empfohlen und Kahnemans Beobachtungen zu Prognosen, die auf intuitivem Urteilsvermögen basieren, müssen berücksichtigt werden. Aber wenn die chaotische Welt die Lücke schließen soll, Es muss mehr tun, als sich auf intuitive Schätzungen zu verlassen. Es muss konkrete Leistungsdaten zu abgeschlossenen Projekten sammeln und unter Einsatz moderner Methoden der Anforderungsmessung einfache Schätzmethoden entwickeln. Beim Kauf von einem externen Lieferanten, Kunden müssen lernen, wie Lieferanten ihre Angebotspreise festlegen.

Auch mit diesen Schritten, In der chaotischen Welt besteht nach wie vor das inhärente Problem, dass häufig Schätzungen erforderlich sind und Budgets früh im Leben eines Softwaresystems festgelegt werden müssen, bevor die Anforderungen im Detail bekannt sind. In diesem Stadium muss eine Schätzung zwangsläufig eine sehr große Unsicherheit aufweisen. Was kann also getan werden, um die Auswirkungen dieser Herausforderung abzumildern??

Die Antwort ist ein Prozess, der entwickelt wurde 15 wurde vor Jahren von der Regierung des Bundesstaates Victoria in Australien eingeführt, wurde jedoch nie umfassend angewendet.
In vereinfachter Darstellung, wenn ein Kunde ein ITT mit einer ersten Anforderungserklärung ausstellt, Lieferanten werden gebeten, die letztendliche Gesamtgröße zu schätzen und einen Festpreis pro funktioneller Einheitsgröße zu bieten. Der Gesamtangebotspreis ist dann das Produkt dieser beiden Faktoren. Wann ein Auftrag vergeben wird und wie sich die Anforderungen weiterentwickeln, der Stückpreis bleibt fest, Der Gesamtpreis variiert jedoch im Verhältnis zur Größe der Anforderungen. Die tatsächliche Größe wird von einem unabhängigen Scope Manager überwacht, ein „Mengengutachter“ für Software. Der Kunde trägt daher das Risiko, dass die Anforderungen unterschiedlich groß sind; Der Lieferant trägt das Risiko, aufgrund seiner Kenntnis der Bedürfnisse des Kunden und seiner eigenen Möglichkeiten den richtigen Stückpreis zu bieten. Mit diesem Prozess, Die Informations- und Risikoasymmetrien zwischen Kunde und Lieferant werden deutlich reduziert.

Das australische Verfahren wurde in Finnland verfeinert, wo es als „Northern Scope“ bekannt ist.. Es wird in verschiedenen Ländern angewendet oder erprobt. Befürworter der Methode behaupten, dass Kostenüberschreitungen auf ein Minimum reduziert werden können 10%.

Als größte Vorteile werden jedoch deutliche Einsparungen bei den Stückkosten der Software und Verbesserungen bei der Liefergeschwindigkeit von Softwareprojekten genannt. Die Fähigkeit, Anforderungen zu messen, spielt hier eine größere Rolle, als man sich vorstellen kann, nämlich als Qualitätskontrollfaktor. Wenn Anforderungen nicht präzise genug sind, dass sie gemessen werden können, Die Software kann sicherlich nicht zuverlässig erstellt und getestet werden! Es zeigt sich, dass sowohl der Prozess von Renault zur Verwaltung der Lieferung eingebetteter Software für seine Steuergeräte als auch der Prozess von Northern Scope auf der Preisgestaltung für Softwareeinheiten als Schlüsselmerkmal basieren.

Abschließend, Die Tools stehen der chaotischen Welt zur Verfügung, um die Lücke zur kontrollierten Welt bei der Schätzung von Softwareprojekten weitgehend zu schließen. Aber es gibt keine Wundermittel, keine schnellen und fertigen Antworten. Eine Ingenieursmentalität und die Bereitschaft, in die Erfassung und Analyse tatsächlicher Leistungsdaten zu investieren, sind unerlässlich.

Über den Autor

Charles Symons ist Gründer und ehemaliger Präsident der Common Software Measurement International Consortium. Sie können ihn unter cr.symons@btinternet.com kontaktieren. Dieser Beitrag erschien zuvor in der 2015 Winternewsletter des Gesellschaft für Kostenanalyse und Prognose.

Ein Blogbeitrag repräsentiert die persönliche Meinung des Autors
und muss nicht unbedingt mit den offiziellen Nesma-Richtlinien übereinstimmen.