Im Jahre 1999 entstand auf der Basis von FPA unter Führung des Common Software Measurement International Konsortium das Verfahren COSMIC FFP, in dem die speziellen Gegebenheiten objektorientierter Software berücksichtigt werden. Beispielsweise ist es mit dieser Metrik möglich, den Umfang eines Software-Systems, das in der Definitionssprache UML (Unifed Modelling Language ) definiert wurde, abzuschätzen. Das Verfahren wurde 2003 als internationaler Standard definiert, der in 2008 als ISO/IEC 19761:2008 an die Version 3 von COSMIC angepasst wurde.
Die Elementarprozesse werden in dem Modell functional process type genannt und umfassen nicht nur die aus Anwendersicht geforderten Funktionalitäten, sondern auch die aus Entwicklersicht zusätzlich notwendigen systeminternen Prozesse. Dadurch können systeminterne Gegebenheiten und Technologieaspekte besser berücksichtigt werden.
Jeder Elementarprozess wird danach untersucht, in welchem Umfang er bestimmte Datenbewegungen nämlich Read bzw.Write als Lesen oder Schreiben von im System verwalteten Datenbeständen und Entry bzw. Exit als Annahme bzw. Abgabe von Daten an externe Systeme oder Anwender vornimmt.
Die Anzahl der Datenbewegungen bestimmt dann die Vergabe von sog. CFSUs, COSMIC functional size units. Die Summe aller CFSUs ist in dem Modell, ähnlich wie bei FPA, das Maß für den Programmieraufwand der Software und dient dazu, den Quellcode-Umfang abzuschätzen.
Die übrigen Charakteristika eines Softwareentwicklungsprojektes (vgl. Kostentreiberfaktoren in COCOMO) werden auch hier nicht betrachtet.
Als Resultat dieser Anwendung von Modellen, Regeln und Prozeduren liefert die Methode einen quantitativen Wert für die Größe bzw. den Umfang des Softwareproduktes aus funktionaler Sicht, allgemein als Functional Size bezeichnet. Dabei ist die Anwendung der COSMIC-FFP Methode unabhängig von der für die Softwareentwicklung verwendeten Implementationstechniken.
Als Grundlage für die Aufwandsschätzung mit der COSMIC-FFP Methode sind in einem ersten Schritt sogenannte Functional User Requirements (FUR) zu bestimmen. Diese funktionalen Systemanforderungen sind als Anforderungen aus der Sicht des Anwenders bzw. Nutzers zu verstehen, die allein die Funktionalität einer Software betreffen. Anforderungen technischer Art oder qualitative Anforderungen an eine Software werden durch die „COSMIC-FFP Methode“ nicht betrachtet. Aus den mittels Regeln und Prozeduren bestimmten FURs wird in einem als „Mapping Phase“ bezeichneten Arbeitsschritt iteraktiv ein „COSMIC-FFP Generic Software Model“ erzeugt, welches ein standardisiertes Modell darstellt, auf welchem die Messung bzw. Zählung der Full-Function-Points durchgeführt werden kann. Die Messung bzw. Zählung wird als „Measuring Phase“ bezeichnet.
Ein Problem der Aufwandsabschätzung mit der „COSMIC-FFP Methode“ vor der eigentlichen Entwicklung einer Software besteht im frühzeitigen Messen bzw.
Abschätzen von Datenbewegungen einzelner funktionaler Prozesse, da in einer frühen Entwicklungsphase noch nicht das Level der Definition von funktionalen Prozessen und Sub-Prozessen erreicht wird. Dieses Dilemma der Software-Messung anhand der Datenbewegungen kann mit der COSMIC-FFP Methode nur durch eine Schätzung der Datenbewegungen gelöst werden. Dafür sollten Skalierungsfaktoren aus schon vorhandenen Software-Produkten bestimmt werden. Unter der Annahme, dass existierende Software nutzbare Ergebnisse über die Anzahl der extrahierten funktionalen Prozesse geliefert hat, könnte eine Lösung darin bestehen, den Mittelwert der Anzahl der funktionalen Prozesse zu ermitteln. Anhand dieses Mittelwertes und einer weiteren Annahme über die in jedem funktionalen Prozess wahrscheinlich zu erwartenden Datenbewegungen, kann so zu einem frühen Zeitpunkt eine Abschätzung für die zu erwartenden Datenbewegungen erreicht werden. Die Generalisierung von Skalierungsfaktoren für die „COSMIC-FFP Methode“ befindet sich allerdings noch im Entwicklungsstadium. (vgl. [COSMIC 03] S.24) Nachdem die Bestimmung der Datenbewegungen innerhalb der funktionalen Prozesse durchgeführt wurde, muss auf diese Datenbewegungen die oben angesprochene Messfunktion angewendet werden.
Techniken zur Aufwandsschätzung auf der Grundlage von COSMIC-FFP
Für die endgültige Bestimmung des Aufwandes (in Personenmonaten, Projektzeit oder –kosten) werden so genannte Kostentreiber herangezogen.
Beim COCOMO II sind dies beispielsweise die Produktattribute:
- CPLX: Komplexität des Produktes,
- DATA: Größe der Datenbasis,
- DOCU: entwicklungsbegleitende Dokumentation,
- RCPX: Zuverlässigkeitsanforderungen,
- RELY: geforderte Zuverlässigkeit,
- RUSE: Entwicklung für die Wiederverwendung; die Hardware-Eigenschaften:
- VOL: Plattformdynamik,
- STOR: benötigter Speicherplatz,
- TIME: benötigte Rechenzeit,
- TURN: Zugangsformen; die Personalattribute:
- ACAP: Fähigkeit zur Analyse,
- APEX: Anwendungserfahrungen,
- LTEX: Erfahrungen mit der Programmiersprache,
- PCAP: Programmierkenntnisse,
- PCON: Personalstabilität,
- PDIF: Plattformschwierigkeiten,
- PERS: Personalfähigkeiten,
- PLEX: Plattformerfahrungen,
- PREX: Personalerfahrungen,
- TEAM: Teamstabilität; die Projektattribute:
- FCIL: Einsatzmöglichkeiten,
- FLEX: Entwicklungsdynamik,
- MODP: moderne Programmierpraktiken,
- PREC: Erstentwicklungsform,
- RESL: Risikomanagement,
- PMAT: Prozessgüte nach dem
- CMM, SITE: Entwicklungsteamverteilung,
- SCED: erforderliche Entwicklungszeit,
- TOOL: Anwendung von CASE-Tools.
Die Bewertungsvorgabe nach Boehm gibt für diese Kostentreiber Wertintervalle vor, bei die 1,0 als Faktor keinen Einfluss bedeutet und die Intervalle von maximal 7,8 bis minimal 0,5 reichen.
Wichtig ist dabei, dass COCOMO II beispielsweise folgende Projektausrichtungen unterscheidet:
- COCOMO: für die Aufwandsschätzung „allgemeiner“ Projekt zur Neuentwicklung und zur Wartung.
- COPSEMO: für Projekte, die OO-Systeme entwickeln und dabei den RUP-Prozess zugrunde legen,
- CORADMO: für die Aufwandsschätzung von Entwicklungsprojekten nach dem Rapid Application Development (RAP) Verfahren,
- COCOTS: für die Aufwandsschätzung für Projekte nach der komponentenbasierten Software- Entwicklung,
- COPROMO: für Projekte, die vor allem phasenweise Produktivitätsangaben berücksichtigen können