Einführung
Dies ist der dritte Teil des Blogs, der sich auf eine Reihe beliebter Methoden zur Messung der Softwaregröße und deren Nützlichkeit für die Schätzung von Softwareprojekten konzentriert.. In diesem dritten Teil werden die nicht funktionalen Größenmessmethoden behandelt. Im nächsten und letzten Blog zu diesem Thema werde ich zukünftige Blogs auf die hybriden Methoden eingehen.
Lesern, die sich für dieses Thema interessieren, wird dringend empfohlen, zuerst die erster Teil und zweiter Teil dieses Blogs, bevor Sie diesen dritten Teil der Blogserie lesen.
Damit eine bestimmte Methode zur Messung der Softwaregröße für die Schätzung von Softwareprojekten nützlich ist, Folgende Eigenschaften sollten zutreffen:
- Die Größenmessmethode kann in einem Objektiv durchgeführt werden (unabhängig von der Person, die es tut), wiederholbar, überprüfbar und daher vertretbar Weg;
- Größe an sich ist nur sinnvoll, wenn historische Daten ist von Projekten verfügbar, die mit dieser Größenmessungsmethode gemessen wurden;
- Die Größenmessmethoden sollten unterstützt werden durch parametrische Modelle und/oder Werkzeuge um projektspezifische Besonderheiten, die die Schätzung beeinflussen, genau zu berücksichtigen, wie zum Beispiel QSM SLIM, SEER für Software, TruePlanning oder COCOMO II.
Na sicher, Jede Methode zur Messung der Softwaregröße, die eines oder mehrere dieser Kriterien nicht erfüllt, kann für ein Unternehmen dennoch sehr nützlich sein, sofern sie ein Verfahren erstellen, um wiederholbare Größenmessungen zu gewährleisten, historische Daten sammeln und analysieren und/oder eigene Schätzmodelle auf der Grundlage der gesammelten Daten erstellen. Für diesen Blog jedoch, Der Fokus liegt auf der theoretischen Nützlichkeit der spezifischen Messmethode für die Schätzung von Softwareprojekten im Kontext von Organisationen, die noch keinen parametrischen Schätzungsprozess haben. Für diese Organisationen, die bereit sind, eine Größenmessmethode zu implementieren, um Softwareprojekte zu schätzen, Dieser Blog kann als Richtlinie für die Auswahl einer bestimmten Methode dienen.
Obwohl alles, was in diesem Blog geschrieben wird, auf persönlichen Erfahrungen und öffentlich zugänglichen Dokumentationen basiert (referenziert), Das möchte ich betonen Dieser Blog spiegelt nur meine persönlichen Ansichten und Überzeugungen wieder und deshalb behaupte ich nicht, dass alles, was in diesem Blog geschrieben wird, die absolute Wahrheit ist. Meine persönlichen Überzeugungen sind nicht unbedingt auch die Überzeugungen der Organisationen, mit denen ich verbunden bin: Meter, Nesma und ISBSG.
Ich ermutige jeden, Kommentare und/oder Feedback zu diesem Blog abzugeben.
Methoden zur Messung nicht funktionaler Größen
Während die Methoden zur Messung der funktionalen Größe nur die Größe der funktionalen Benutzeranforderungen messen (was die Software dem Nutzer bieten soll), die nicht-funktionalen Größenmessmethoden messen (oft Teil der) nicht-funktionale Benutzeranforderungen, das können technische Benutzeranforderungen und/oder qualitative Benutzeranforderungen sein (wie die Software funktionieren soll). Auch die Messung des gelieferten Codes gilt als nicht funktionale Größenmessung.
Das am häufigsten verwendete nicht-funktionale Größenmaß sind Quellcodezeilen (slocs).
Quellcodezeilen (slocs)
Source Lines of Code sprechen viele Menschen und Organisationen an, denn sobald das Softwaresystem fertig ist, es kann automatisch von Quellcodezählern gezählt werden. Häufig, die Entwicklungstools messen die Codezeilen bereits während des Projekts.
Viele Organisationen verwenden die Slocs-Kennzahl als Eingabe für ihre Softwareprojektschätzungsprozesse. Das ist bemerkenswert, da die Anzahl der Slocs erst nach Fertigstellung gemessen werden kann. Dies bedeutet, dass Slocs in der Softwareschätzung verwendet werden, die slocs müssen geschätzt werden, nicht gemessen. Üblicherweise schätzt ein Expertenteam gemeinsam die Anzahl der Quellcodezeilen für das neue Projekt ab und/oder verwendet Analogieverfahren zu bereits abgeschlossenen Projekten, um eine Schätzung der zu liefernden Softwaregröße zu erstellen.
Obwohl das eine gute Idee zu sein scheint, diese Methode birgt große Risiken für die Aufwandsschätzung. Es gibt keinen ISO-Standard (oder jeder andere Standard) verfügbar für Quellcodezeilen. Verschiedene Code-Zählwerkzeuge geben a . zurück (manchmal ganz) anderes Ergebnis nach dem Zählen des gleichen Codes. Manchmal werden physische Linien gemessen, aber auch oft werden Quellenangaben gezählt. Da eine Aussage leicht auf mehrere Zeilen geschrieben werden kann, das zeigt schon ein großes problem.
Und dazu, Die Anzahl der benötigten Quellcodezeilen hängt von Faktoren wie der technischen Umgebung ab, Komplexität und Programmierfähigkeiten. Quellcodezeilen stellen auch keinen wirklichen Wert für die Benutzer dar. Ist es besser, mehr Codezeilen oder weniger Codezeilen zu erhalten?? Mehr Zeilen können mehr Funktionalität bedeuten, aber wenn man einen Lieferanten nach einem Preis pro . bezahlen würde 1000 Quelltextzeilen eines ist sicher… der Kunde würde viel Code bekommen! Codezähler sollten nicht den Code messen, der von den Entwicklungstools generiert wird, aber in Wirklichkeit ist es für diese Tools unmöglich, den generierten Code von der Messung auszuschließen.
Daher ist es in der Regel sehr schwierig, die Slocs eines abgeschlossenen Softwareprojekts als Input für das nächste Softwareprojekt zu verwenden. Experten zu verwenden, um die Gesamtzahl der Quellcodezeilen für ein neues Projekt zu schätzen und dann historische Daten basierend auf Quellcodezeilen zu verwenden, ist äußerst riskant. Durch diese Schätzung, der Haupteingabeparameter der Schätzung enthält bereits einen großen Unsicherheitsprozentsatz.
So, warum schätzen viele organisationen ihre projekte so ein? Einige Veröffentlichungen, zum Beispiel ‘Ursachen und Entfernungsmethoden von Softwarefehlern‘ von Capers Jones, geben an, dass es eine Form von professionellem Fehlverhalten ist, Projekte auf diese Weise einzuschätzen. Es kann manchmal funktionieren, aber das damit verbundene Risiko ist riesig und scheiternde Projekte mit enormen Überschreitungen sind wahrscheinlich nicht zu vermeiden. In Wirklichkeit, genau das wird oft übersehen. Bei großen Projekten geht meist vieles schief, Und am Ende ist es fast immer möglich, einige Betriebsprobleme, die während eines Softwareprojekts immer auftreten, „schuldzubestimmen“ … irgendein technisches Problem, oder ein Product Owner, der nicht genug involviert war, oder die OTAP-Umgebung wurde nicht schnell genug implementiert, oder der Kunde hat seine Anforderungen während des Projekts stark geändert… und so weiter. In den meisten Fällen von Softwarefehlern jedoch, bei der Analyse der wahren Ursache, es beweist, dass das Projekt mit zu optimistischen Erwartungen begonnen hat… das Team ist zu klein, die dauer zu kurz, die kosten zu gering. Expertenschätzungen, und Schätzungen, die nicht auf Industriestandards und Erfahrungsdaten basieren beginne normalerweise mit optimistischen Erwartungen. Organisationen, die die Beziehung zwischen einer realistischen Schätzung und dem Ergebnis des Projekts verstehen, wird sich auf die Implementierung von Instrumenten konzentrieren, die es ihnen ermöglichen, das Projekt so genau wie möglich einzuschätzen, auch zu optimistische Schätzungen von Lieferanten beispielsweise nicht honorieren. jedoch, Organisationen müssen einen gewissen Reifegrad erreichen, um dies zu verstehen, und dieser Reifegrad ist für viele Unternehmen in der Branche noch weit entfernt… selbst für diejenigen, die sich für ziemlich reif halten!
Theoretisch, Quellcodezeilen sind für die Softwareschätzung überhaupt nicht nützlich. Einige Leute berichten von erfolgreichen Projekten, die auf diese Weise geschätzt werden, aber aus theoretischer Sicht könnte dies eher Zufall oder Glück sein.
Die Merkmale zur Bewertung der Nützlichkeit dieser Methode für die Schätzung von Softwareprojekten sind in der nächsten Tabelle aufgeführt:
| Charakteristisch | Ja Nein | Bemerkungen |
| Zielsetzung, wiederholbar, überprüfbar und vertretbar | Nein | Slocs können erst nach Projektabschluss gemessen werden. Für die Projektschätzung können nur „erratene Slocs“ verwendet werden. |
| Historische Daten verfügbar | Ja | ISBSG R13: 180 Projekte. jedoch, Es ist nicht möglich, den gemessenen SLOC-Typ zu überprüfen. |
| Unterstützt von Modellen/Tools | Ja | QSM SLIM, SEER für Software, TruePlanning, COCOMO II. ISBSG |
SNAP-Punkte
SNAP ist die Abkürzung für „Software Non-functional Assessment Process“.,„ein Messverfahren von nicht-funktionaler Softwaregröße“. SNAP Point Sizing ist als Ergänzung zu einer Funktion Point Sizing gedacht, die die funktionale Softwaregröße misst. SNAP ist ein Produkt der Internationale Funktionspunkt-Benutzergruppe (IFPUG), und wird mit dem Handbuch für nicht funktionale Bewertungspraktiken für Software, jetzt in version 2.2.
SNAP ist lose mit dem ISO . verbunden 9126 und ISO 25010 Standards für Softwarequalität. Es versucht, die nicht-funktionalen Anforderungen zu bemessen, die in einem Softwareprojekt implementiert werden. Obwohl das eine gute Idee zu sein scheint, die SNAP-Methode scheint ihr Ziel zu verfehlen. Es bietet kein integriertes Messinstrument für alle nichtfunktionalen Anforderungen und darüber hinaus werden eine Reihe von hochrelevanten nichtfunktionalen Anforderungen überhaupt nicht gemessen. Eine Reihe zusätzlicher Beobachtungen:
- Die meisten in der Industrie verwendeten Dokumentationen enthalten nicht explizit die notwendigen Informationen zu den nicht-funktionalen Anforderungen, die SNAP zu messen versucht. Und dazu, Es ist nicht klar, was zu tun ist, wenn diese Informationen fehlen. Zähle trotzdem etwas…oder zähle nichts?
- Nicht alle ISO 9126 oder ISO 25010 Kategorien nichtfunktionaler Anforderungen werden gemessen. Auch wenn die SNAP-Punkte mit der veröffentlichten Methode gemessen werden können, die nicht-funktionalen Anforderungen, die Menschen als wichtige Kostentreiber ansehen (z.B.. Leistung oder Sicherheit, und so weiter), werden ignoriert;
- Es ist nicht klar, wie die Beziehung zwischen den verschiedenen SNAP-Kategorien bestimmt wird und warum dies gültig wäre. Warum sollte die UI-Komplexität? (SNAP-Punkte = Anzahl der hinzugefügten oder konfigurierten Eigenschaften …2, 3 oder 4 mal die Anzahl der eindeutigen UI-Elemente) von gleicher..oder mehr…oder weniger nicht-funktionaler Größe sein als die für Batch-Prozesse gemessene nicht-funktionale Größe (4 mal, 6 mal oder 10 mal die Anzahl der Datenattribute). Es scheint keinen relevanten Zusammenhang zwischen den Kategorien zu geben und die Art und Weise, wie die SNAP-Punkte gemessen werden, scheint willkürlich zu sein;
- Professor Doktor Abran wies darauf hin, dass die statistischer Beweis der SNAP-Methode die üblichen methodischen Validitätstests nicht besteht, da es den Anschein hat, dass Ausreißer in dem Datensatz, der verwendet wurde, um die Korrelation zwischen SNAP-Punkten und Aufwand zu demonstrieren, nicht entfernt worden zu sein scheinen;
- Einige der nicht-funktionalen Anforderungen, die gemessen werden, sind tatsächlich funktional und werden auch in NESMA- und/oder IFPUG-Methoden gemessen. Das ist seltsam für eine Methode, die behauptet, nur nicht-funktionale Anforderungen zu messen.
Insgesamt, obwohl IFPUG und viele Praktiker die SNAP-Methode als eine gute und gültige Methode für die Schätzung befürworten, Aus praktischer und theoretischer Sicht sind noch viele Fragen zu klären, bevor diese Methode bei der Projektschätzung eingesetzt werden kann. Im Moment sind nur sehr begrenzte historische Daten von in SNAP gemessenen Projekten verfügbar. Im 2013, die International Software Benchmarking Standards Group veröffentlichte a SNAP-Datenerfassungsformular, aber bis jetzt sind keine Projekteinreichungen mit SNAP-Punkten eingegangen.
Zur Zeit, maximal kann es verwendet werden, um zu versuchen, die Leistungs- oder Produktivitätsunterschiede zwischen abgeschlossenen Projekten zu verstehen, aber noch nicht für die Projektschätzung geeignet.
Die Merkmale zur Bewertung der Nützlichkeit dieser Methode für die Schätzung von Softwareprojekten sind in der nächsten Tabelle aufgeführt:
| Charakteristisch | Ja Nein | Bemerkungen |
| Zielsetzung, wiederholbar, überprüfbar und vertretbar | Nein | Das SNAP-Handbuch sollte eine objektive Messung gewährleisten, aber nicht sicher ist, was zu tun ist, wenn notwendige Informationen fehlen, Vermesser werden wahrscheinlich unterschiedliche Annahmen treffen, die zu unterschiedlichen Größen führen. |
| Historische Daten verfügbar | Nein | ISBSG erfasst Projekte in SNAP-Punkten, aber es wurden noch keine Daten übermittelt. Möglicherweise sind Daten in der IFPUG SNAP-Gruppe verfügbar. |
| Unterstützt von Modellen/Tools | Nein |
Nächster Blog
Im nächsten Blog zu diesem Thema, Ich werde meine Meinung zur Nützlichkeit der wichtigsten hybriden Größenmessmethoden für die Schätzung von Softwareprojekten abgeben.
Über den Autor
Harold van Heeringen ist Senior Benchmarking Consultant bei Metri. Abgesehen von seiner Arbeit für Metri, er ist an Nesma beteiligt (Vorstandsmitglied), die International Software Benchmarking Standards Group (ISBSG, aktueller Präsident) und das Common Software Metrics International Consortium (COSMIC, Internationaler Beirat, die Niederlande vertreten).