Dies sind die Prinzipien Und Regeln gefunden in der COSMIC Measurement Method v4.0.2
Aggregieren von Messergebnissen
Regeln
a) Für jeden Funktionsprozess werden die Funktionsgrößen einzelner Datenbewegungen durch Addition zu einem einzigen Funktionsgrößenwert in CFP-Einheiten zusammengefasst.
Größe (funktionale Prozesse) = Σ Größe (Einträge) + Σ Größe (Ausgänge) + Σ Größe (Lesevorgänge) + Σ Größe (Schreibvorgänge)
b) Für jeden Funktionsprozess wird die funktionale Größe der Änderungen an seinen funktionalen Benutzeranforderungen aus den Größen der Datenbewegungen aggregiert, die im Funktionsprozess hinzugefügt, geändert oder gelöscht wurden, um eine Größe der Änderung in CFP-Einheiten zu erhalten , gemäß der folgenden Formel.
Größe (Änderung(funktionale Prozesse)) =
Σ Größe (hinzugefügte Datenbewegungen) +
Σ-Größe (geänderte Datenbewegungen) +Σ-Größe (gelöschte Datenbewegungen)
Weitere Informationen zur Aggregation der Funktionsgröße finden Sie in Abschnitt 4.3.2. Zur Messung der Größe der geänderten Software siehe Abschnitt 4.4.2.
c) Die Größe eines Softwareteils innerhalb eines definierten Umfangs wird durch Aggregieren der Größen der funktionalen Prozesse für das Teil ermittelt, vorbehaltlich der nachstehenden Regeln e) und f).
d) Der Umfang jeder Änderung an einem Teil der Software innerhalb eines definierten Umfangs wird durch Aggregieren der Größen aller Änderungen an allen funktionalen Prozessen für den Teil ermittelt, vorbehaltlich der nachstehenden Regeln e) und f).
e) Größen von Softwareteilen oder Änderungen an Softwareteilen dürfen nur dann addiert werden, wenn sie auf der gleichen funktionalen Prozessebene der Granularität ihrer FUR gemessen werden.
f) Größen von Softwareteilen und/oder Änderungen in der Größe von Softwareteilen innerhalb einer Schicht oder aus verschiedenen Schichten dürfen nur addiert werden, wenn dies für den Zweck der Messung sinnvoll ist.
g) Die Größe eines Softwareteils kann durch Addition der Größen seiner Komponenten (unabhängig davon, wie das Teil zerlegt wird) und Eliminieren der Größenbeiträge von Datenbewegungen zwischen Komponenten ermittelt werden.
h) Es darf nur ein Exit für alle Fehler-/Bestätigungsmeldungen identifiziert werden, die von einem funktionalen Prozess an einen menschlichen funktionalen Benutzer ausgegeben werden.
i) Wenn die COSMIC-Methode lokal erweitert wird (z. B. um einen Aspekt der Größe zu messen, der nicht von der Standardmethode abgedeckt wird), muss die über die lokale Erweiterung gemessene Größe separat gemeldet werden, wie in Abschnitt 5.1 beschrieben, und darf NICHT zur hinzugefügt werden nach der Standardmethode ermittelte Größe, gemessen in CFP (siehe weiter unten in Abschnitt 4.5).
Steuerbefehle in Anwendungen mit einer Benutzeroberfläche
Regel
In einer Anwendung mit einer menschlichen Schnittstelle sollten „Steuerbefehle“ ignoriert werden, da sie keine Bewegung von Daten über ein interessierendes Objekt beinhalten.
COSMIC-Messberichte
Regel
Zusätzlich zu den tatsächlichen Messungen, die wie in 5.1 aufgezeichnet werden, sollten einige oder alle der folgenden Attribute jeder Messung aufgezeichnet werden, abhängig vom Messzweck und dem gewünschten Grad der Vergleichbarkeit mit anderen Messungen, z. B. für Benchmarking-Zwecke.
a) Identifikation der gemessenen Softwarekomponente (Name, Versions-ID oder Konfigurations-ID).
b) Die Informationsquellen, die zur Identifizierung des für die Messung verwendeten FUR verwendet werden
c) Die Domäne der Software
d) Gegebenenfalls eine Beschreibung der Architektur der Schichten, in denen die Messung durchgeführt wird.
e) Eine Angabe zum Zweck der Messung.
f) Eine Beschreibung des Umfangs der Messung und ihrer Beziehung zum Gesamtumfang einer zugehörigen Reihe von Messungen, falls vorhanden. (Verwenden Sie die generischen Geltungsbereichskategorien in Abschnitt 2.2)
g) Das verwendete Messstrategiemuster (COSMIC oder lokal) mit dem Verarbeitungsmodus (online oder Batch)
h) Die funktionalen Benutzer der Software
i) Der Granularitätsgrad der verfügbaren Softwareartefakte und der Zerlegungsgrad der Software.
j) Der Punkt im Projektlebenszyklus, an dem die Messung durchgeführt wurde (insbesondere, ob es sich bei der Messung um eine Schätzung auf der Grundlage unvollständiger Anforderungen handelt oder ob sie auf der Grundlage der tatsächlich gelieferten Funktionalität durchgeführt wurde).
k) Die angestrebte oder angenommene Fehlerspanne der Messung.
l) Angabe, ob die Standard-COSMIC-Messmethode verwendet wurde und/oder eine lokale Annäherung an die Standardmethode und/oder ob lokale Erweiterungen verwendet wurden (siehe Abschnitt 4.5). Verwenden Sie die Kennzeichnungskonventionen der Abschnitte 5.1 oder 5.2.
m) Eine Angabe, ob es sich bei der Messung um eine entwickelte oder gelieferte Funktionalität handelt („entwickelte“ Funktionalität wird durch die Erstellung neuer Software erhalten; „gelieferte“ Funktionalität umfasst „entwickelte“ Funktionalität und umfasst auch Funktionalität, die auf andere Weise als durch die Erstellung neuer Software erlangt wurde, d. h. einschließlich aller Formen von Wiederverwendung vorhandener Software, Implementierung von Softwarepaketen, Verwendung vorhandener Parameter zum Hinzufügen oder Ändern von Funktionen usw.).
n) Eine Angabe, ob es sich bei der Messung um neu bereitgestellte Funktionalität handelt oder ob sie das Ergebnis einer „Verbesserungs“-Aktivität ist (dh die Summe besteht aus hinzugefügter, geänderter und gelöschter Funktionalität – siehe 4.4).
o) Gegebenenfalls die Anzahl der Hauptkomponenten, deren Größen zur erfassten Gesamtgröße addiert wurden.
p) Der Prozentsatz der durch wiederverwendete Software implementierten Funktionalität
q) Für jeden Bereich innerhalb des gesamten Messbereichs eine Messmatrix, wie in Anhang A angegeben.
r) Name des Vermessers und etwaige COSMIC-Zertifizierungsqualifikationen; das Datum der Messung
KOSMISCHE Messkennzeichnung
Regeln
Ein COSMIC-Messergebnis ist als „x CFP (v)“ zu notieren, wobei:
- 'x' stellt den numerischen Wert der Funktionsgröße dar,
- „v“ stellt die Identifikation der Standardversion der COSMIC-Methode dar, die zum Erhalten des numerischen Funktionsgrößenwerts „x“ verwendet wird Wenn es sich um eine Standard-COSMIC-Version handelt, muss die obige Beschriftungskonvention verwendet werden, die Verwendung der Näherungsmethode sollte jedoch an anderer Stelle vermerkt werden – siehe Abschnitt 5.2. Beschriftung lokaler COSMIC-Erweiterungen
Regel
Ein COSMIC-Messergebnis unter Verwendung lokaler Erweiterungen ist wie folgt zu notieren: „x CFP (v) + z Local FP“, wobei:
- „x“ stellt den numerischen Wert dar, der durch Aggregieren aller einzelnen Messergebnisse gemäß der Standard-COSMIC-Methode, Version v, erhalten wird.
- „v“ stellt die Identifikation der Standardversion der COSMIC-Methode dar, die zum Erhalten des numerischen Funktionsgrößenwerts „x“ verwendet wird.
- „z“ stellt den numerischen Wert dar, der durch die Aggregation aller einzelnen Messergebnisse aus lokalen Erweiterungen der COSMIC-Methode erhalten wird.
Datengruppe
Prinzip
Jede identifizierte Datengruppe muss einzigartig und durch ihre einzigartige Sammlung von Datenattributen unterscheidbar sein.
Identifizieren verschiedener Datengruppen (und damit verschiedener interessierender Objekte), die im selben funktionalen Prozess verschoben werden
Regel
Für alle Datenattribute, die in der Eingabe eines Funktionsprozesses erscheinen:
- a) Sätze von Datenattributen, die unterschiedlich häufig vorkommen, beschreiben verschiedene interessierende Objekte;
- b) Sätze von Datenattributen, die die gleiche Häufigkeit des Auftretens, aber unterschiedliche identifizierende Schlüsselattribute aufweisen und unterschiedliche Objekte von Interesse beschreiben;
- c) alle Datenattribute in einem Satz, der sich aus der Anwendung der Teile a) und b) dieser Regel ergibt, gehören zu demselben Datengruppentyp, es sei denn, die FUR legt fest, dass es mehr als einen Datengruppentyp geben kann, der dasselbe interessierende Objekt beschreibt im Input zum Funktionsprozess (siehe Anmerkung 3)
Dieselbe Regel gilt für alle Datenattribute, die in der Ausgabe eines funktionalen Prozesses erscheinen, oder für alle, die von einem funktionalen Prozess in den persistenten Speicher verschoben werden, oder für alle, die vom persistenten Speicher in einen funktionalen Prozess verschoben werden.
HINWEIS 1. Bei der Analyse komplexer Ausgaben, z. B. Berichte mit Daten, die mehrere interessierende Objekte beschreiben, kann es hilfreich sein, jede einzelne Kandidatendatengruppe so zu betrachten, als ob sie von einem separaten Funktionsprozess ausgegeben würde. Jeder der so identifizierten Datengruppentypen muss auch bei der Messung des komplexen Berichts unterschieden und gezählt werden. Beispiele finden Sie im „Leitfaden zur Dimensionierung von Unternehmensanwendungssoftware“ [7], insbesondere im Beispiel in Abschnitt 2.6.1 und dessen Analyse in 2.6.2. Siehe auch die Analyse der Beispiele 4 und 5 in Abschnitt 4.2.4.
ANMERKUNG 2: Die Untersuchung, wie Datenattribute bei der Eingabe oder Ausgabe physisch gruppiert oder getrennt werden, kann bei der Unterscheidung verschiedener Datengruppentypen hilfreich sein, kann jedoch nicht als verlässliche Grundlage für die Unterscheidung herangezogen werden. Beispielsweise gehören zwei oder mehr Sätze von Datenattributen, die an derselben Ein- oder Ausgabe vorkommen und aus ästhetischen Gründen oder zum besseren Verständnis physisch getrennt sind, zu demselben Datengruppentyp, wenn sie die obige Regel erfüllen.
HINWEIS 3. Siehe Abschnitt 3.5 des Messhandbuchs für die Definitionen, Grundsätze und Regeln für die Datenbewegungen, die Datengruppen verschieben, und Abschnitt 3.5.7 (Beispiele 2, 3, 4 und 5) und 3.5.11 für Ausnahmen von diesen Regeln für Datenbewegungen gemäß Regel c oben.
Regeln
a) Ein funktionaler Prozess muss vollständig zum Messumfang einer Software in einer und nur einer Schicht gehören.
b) Ein funktionaler Prozess muss mindestens zwei Datenbewegungen umfassen, nämlich den auslösenden Eintrag plus entweder einen Ausstieg oder einen Schreibvorgang, was einer Mindestgröße von 2 CFP entspricht. Es gibt keine Obergrenze für die Anzahl der Datenbewegungen in einem Funktionsprozess und daher auch keine Obergrenze für seine Größe.
c) Ein ausgeführter Funktionsprozess gilt als beendet, wenn er seine FUR für alle möglichen Reaktionen auf seinen auslösenden Eintrag erfüllt hat. Eine Unterbrechung der Verarbeitung aus technischen Gründen gilt nicht als Beendigung des Funktionsablaufs.
Funktionale Prozessgranularität
|
Funktionale Prozessgranularitätsebene Regeln
|
|
Sek. |
BESCHREIBUNG DER GRUNDSÄTZE UND REGELN |
|
ungefähre Annäherung. Diese Ansätze definieren, wie Anforderungen auf höheren Granularitätsebenen gemessen werden können. Anschließend werden Skalierungsfaktoren auf die Messungen auf der/den höheren Granularitätsebene(n) angewendet, um eine ungefähre Größe auf der Granularitätsebene der funktionalen Prozesse und ihrer Datenbewegungs-Unterprozesse zu ermitteln. Siehe die „Richtlinie zur ungefähren Messung der kosmischen Funktionsgröße“ [6]. |
|
Siehe auch funktioneller Prozess
Ein funktionaler Prozess, der Daten von einem funktionalen Benutzer erfordert
Regeln
a) Ein funktionaler Prozess muss eine Datengruppe über eine Eingabedatenverschiebung von einem funktionalen Benutzer erhalten, wenn der funktionale Prozess dem funktionalen Benutzer nicht mitteilen muss, welche Daten er senden soll, wie in einem der folgenden vier Fälle:
- wenn ein funktionaler Benutzer eine Datengruppe über einen auslösenden Eintrag sendet, der den funktionalen Prozess initiiert;
- wenn ein funktionaler Prozess, nachdem er eine Datengruppe über einen auslösenden Eintrag erhalten hat, wartet und auf die Ankunft einer weiteren Datengruppe vom funktionalen Benutzer über einen Eintrag wartet (kann auftreten, wenn ein menschlicher funktionaler Benutzer Daten in die Geschäftsanwendungssoftware eingibt);
- wenn ein funktionaler Prozess nach dem Start den funktionalen Benutzer auffordert: „Senden Sie mir jetzt Ihre Daten, falls Sie welche haben“ und der funktionale Benutzer seine Daten sendet;
-
wenn ein funktionaler Prozess nach dem Start den Status eines funktionalen Benutzers überprüft und die erforderlichen Daten abruft.
In den beiden letztgenannten Fällen (die typischerweise bei Echtzeit-Polling-Software auftreten) darf vereinbarungsgemäß kein Ausstieg aus dem Funktionsprozess identifiziert werden, um die erforderlichen Daten zu erhalten. Der funktionale Prozess muss lediglich eine Aufforderungsnachricht an einen funktionalen Benutzer senden und die Funktionalität dieser Aufforderungsnachricht wird als Teil des Eintrags betrachtet. Der funktionale Prozess weiß, welche Daten ihn erwarten. Für diesen Fall wird nur ein Eintrag identifiziert.
b) Wenn ein funktionaler Prozess die Dienste eines funktionalen Benutzers erhalten muss (z. B. um Daten zu erhalten) und dem funktionalen Benutzer mitgeteilt werden muss, was er senden soll (normalerweise, wenn der funktionale Benutzer ein anderes Stück Software außerhalb des Anwendungsbereichs der Software ist). gemessen wird), muss ein Exit gefolgt von einer Entry-Datenbewegung identifiziert werden. Der Exit sendet die Anfrage nach den spezifischen Daten; Der Eintrag empfängt die zurückgegebenen Daten.
Funktionale Benutzer
Regeln
a) Die funktionalen Benutzer einer zu messenden Software richten sich nach dem Zweck der Messung.
b) Wenn der Zweck einer Messung einer Software mit dem Aufwand zur Entwicklung oder Änderung der Software zusammenhängt, sollten die funktionalen Benutzer alle verschiedenen Arten von Absendern und/oder vorgesehenen Empfängern von Daten an/von der Software sein neue oder geänderte Funktionalität, wie in der FUR gefordert.
HINWEIS: FUR kann festlegen, dass eine Gruppe funktionaler Benutzer individuell identifiziert werden muss. Dennoch sind sie vom gleichen Typ, wenn jedes Vorkommen dem gleichen FUR unterliegt
Das generische Softwaremodell
Prinzipien
a) Eine Software interagiert mit ihren funktionalen Benutzern über eine Grenze hinweg und mit persistentem Speicher innerhalb dieser Grenze.
b) Funktionale Benutzeranforderungen einer zu messenden Software können in einzigartige funktionale Prozesse abgebildet werden.
c) Jeder Funktionsprozess besteht aus Teilprozessen.
d) Ein Teilprozess kann entweder eine Datenverschiebung oder eine Datenmanipulation sein.
e) Eine Datenverschiebung verschiebt eine einzelne Datengruppe.
f) Es gibt vier Datenbewegungstypen: Eintritt, Austritt, Schreiben und Lesen.
- Ein Eintrag verschiebt eine Datengruppe von einem funktionalen Benutzer in einen funktionalen Prozess.
- Ein Exit verschiebt eine Datengruppe aus einem funktionalen Prozess zu einem funktionalen Benutzer.
- Ein Schreibvorgang verschiebt eine Datengruppe von einem funktionalen Prozess in den dauerhaften Speicher.
- Ein Lesevorgang verschiebt eine Datengruppe vom persistenten Speicher in einen funktionalen Prozess.
g) Eine Datengruppe besteht aus einem eindeutigen Satz von Datenattributen, die ein einzelnes interessierendes Objekt beschreiben.
h) Jeder Funktionsprozess wird durch die auslösende Eingabedatenbewegung gestartet. Die vom auslösenden Eintrag verschobene Datengruppe wird von einem funktionalen Benutzer als Reaktion auf ein auslösendes Ereignis generiert.
i) Die Größe eines Funktionsprozesses entspricht der Gesamtzahl seiner Datenbewegungen
j) Ein funktionaler Prozess muss mindestens die auslösende Datenbewegung „Eintritt“ und entweder eine Datenbewegung „Schreiben“ oder „Exit“ umfassen, d. h. er muss mindestens zwei Datenbewegungen umfassen. Für die Anzahl der Datenbewegungen in einem Funktionsprozess gibt es keine Obergrenze
k) Als Näherungswert für Messzwecke werden Teilprozesse der Datenmanipulation nicht separat gemessen; Es wird davon ausgegangen, dass die Funktionalität einer Datenmanipulation durch die Datenbewegung, mit der sie verbunden ist, erklärt wird
HINWEIS: Das COSMIC Generic Software Model ist, wie der Name schon sagt, ein logisches „Modell“, das Einheiten offenlegt, in denen Software Daten verarbeitet, die für die funktionale Größenmessung geeignet sind. Das Modell beabsichtigt nicht, die physische Abfolge der Schritte zu beschreiben, mit denen die Software ausgeführt wird, noch eine technische Implementierung der Software.
Schicht
Prinzipien
a) Software in einer Schicht stellt eine Reihe von Diensten bereit, die nach einem definierten Kriterium zusammenhängend sind und die Software in anderen Schichten nutzen kann, ohne zu wissen, wie diese Dienste implementiert sind.
b) Die Beziehung zwischen Software in zwei beliebigen Schichten wird durch eine „Korrespondenzregel“ definiert, die entweder sein kann
- „hierarchisch“, dh Software in Schicht A darf die von Software in Schicht B bereitgestellten Dienste nutzen, jedoch nicht umgekehrt (wobei die hierarchische Beziehung nach oben oder unten verlaufen kann), oder
- „bidirektional“, dh Software in Schicht A darf Software in Schicht B verwenden und umgekehrt.
c) Software einer Schicht tauscht über ihre jeweiligen Funktionsprozesse Datengruppen mit Software einer anderen Schicht aus.
d) Software in einer Schicht nutzt nicht unbedingt alle funktionalen Dienste, die von Software in einer anderen Schicht bereitgestellt werden.
e) Software in einer Schicht einer definierten Softwarearchitektur kann entsprechend einer anderen definierten Softwarearchitektur in andere Schichten aufgeteilt werden.
Das COSMIC Software-Kontextmodell
Prinzipien
- a) Software ist durch Hardware begrenzt.
- b) Software ist typischerweise in Schichten strukturiert.
- c) Eine Schicht kann eine oder mehrere separate „Peer“-Softwareteile enthalten.
- d) Jede zu messende Software muss durch ihren Messumfang definiert werden, der vollständig auf eine einzige Schicht beschränkt sein muss.
- e) Der Umfang einer zu messenden Software richtet sich nach dem Zweck der Messung.
- f) Die funktionalen Benutzer einer zu messenden Software müssen anhand ihrer funktionalen Benutzeranforderungen (FUR) als Absender und/oder beabsichtigte Empfänger von Daten an/von der Software identifiziert werden.
- g) Die funktionalen Anforderungen an Software können auf unterschiedlichen Granularitätsebenen ausgedrückt werden.
- h) Eine präzise KOSMISCHE Größenmessung einer Software erfordert, dass ihre FUR auf den Granularitätsebenen bekannt sind, auf denen ihre funktionalen Prozesse und Unterprozesse identifiziert werden können.
- i) Eine ungefähre KOSMISCHE Größenmessung einer Software ist möglich, wenn ihre funktionalen Anforderungen durch einen Näherungsansatz auf einem hohen Granularitätsniveau gemessen und auf die Granularitätsebenen der funktionalen Prozesse und Teilprozesse skaliert werden.
Granularitätsebenen zur Messung eines Funktionsprozesses
Regeln
- a) Eine funktionale Größenmessung einer Software erfordert, dass ihre FUR auf den Granularitätsebenen bekannt ist, auf denen ihre funktionalen Prozesse und Teilprozesse der Datenbewegung identifiziert werden können.
- b) Wenn einige Anforderungen gemessen werden müssen, bevor sie für eine genaue Messung ausreichend detailliert definiert wurden, können die Anforderungen mithilfe eines Näherungsansatzes gemessen werden. Diese Ansätze definieren, wie Anforderungen auf höheren Granularitätsebenen gemessen werden können. Anschließend werden Skalierungsfaktoren auf die Messungen auf den höheren Granularitätsebenen angewendet, um eine ungefähre Größe auf den Granularitätsebenen der funktionalen Prozesse und ihrer Datenbewegungs-Unterprozesse zu ermitteln. Siehe „Leitlinie für frühe oder schnelle COSMIC-Funktionsgrößenmessung durch Approximationsansätze“. [6].
Eintrag (E)
Prinzipien
a) Ein Eintrag verschiebt eine einzelne Datengruppe, die ein einzelnes Objekt von Interesse beschreibt, von einem funktionalen Benutzer über die Grenze und in den funktionalen Prozess, zu dem der Eintrag gehört. Wenn die Eingabe in einen Funktionsprozess mehr als eine Datengruppe umfasst, die jeweils ein anderes interessierendes Objekt beschreibt, identifizieren Sie einen Eintrag für jede eindeutige Datengruppe in der Eingabe. (Siehe auch Abschnitt 3.5.7 zur „Eindeutigkeit der Datenbewegung“.)
b) Ein Eintrag darf keine Daten über die Grenze hinaus ausgeben oder Daten aus/in den persistenten Speicher lesen oder schreiben.
Regeln
a) Die Datengruppe eines auslösenden Eintrags darf nur aus einem Datenattribut bestehen, das der Software einfach mitteilt, dass „ein Ereignis Y aufgetreten ist“. Sehr oft, insbesondere in Geschäftsanwendungssoftware, verfügt die Datengruppe des auslösenden Eintrags über mehrere Datenattribute, die die Software darüber informieren, dass „ein Ereignis Y aufgetreten ist und hier sind die Daten zu diesem bestimmten Ereignis“.
b) Clock-Ticks, die Ereignisse auslösen, müssen immer außerhalb der gemessenen Software liegen. Daher muss beispielsweise ein alle 3 Sekunden auftretendes Clock-Tick-Ereignis mit einem Eintrag verknüpft sein, der eine Datengruppe eines Datenattributs verschiebt. Beachten Sie, dass es keinen Unterschied macht, ob das auslösende Ereignis periodisch von der Hardware oder von einer anderen Software außerhalb der Grenzen der gemessenen Software generiert wird.
c) Sofern kein spezifischer funktionaler Prozess erforderlich ist, gilt das Abrufen des Datums und/oder der Uhrzeit aus der Systemuhr nicht als Ursache für einen Eintrag oder eine andere Datenbewegung.
d) Wenn ein Auftreten eines bestimmten Ereignisses den Eintrag einer Datengruppe verursacht, die bis zu „n“ Datenattribute eines bestimmten Objekts von Interesse umfasst, und die FUR zulässt, dass andere Vorkommnisse desselben Ereignisses einen Eintrag einer Datengruppe verursachen können, die dies getan hat Werte für Attribute nur einer Teilmenge der „n“ Attribute des Objekts von Interesse, dann soll ein Eintrag identifiziert werden, der eine Datengruppe verschiebt, die alle „n“ Datenattribute umfasst.
e) Analysieren Sie beim Identifizieren von Einträgen in einem Bildschirm, die es menschlichen funktionalen Benutzern ermöglichen, Daten in funktionale Prozesse einzugeben, nur Bildschirme, die mit Daten gefüllt sind. Ignorieren Sie alle Bildschirme, die formatiert, aber ansonsten „leer“ sind, mit Ausnahme möglicher Standardwerte, und ignorieren Sie alle Feld- und anderen Überschriften, die es menschlichen Benutzern ermöglichen, die erforderlichen Eingabedaten zu verstehen.
NOTIZ. Bei der Messung von FUR für Änderungen an Einträgen kann es erforderlich sein, Feld- und andere Überschriften zu berücksichtigen – siehe Abschnitt 4.4.1.
Ausgang (X)
Prinzipien
a) Ein Exit soll eine einzelne Datengruppe, die ein einzelnes Objekt von Interesse beschreibt, aus dem Funktionsprozess, zu dem der Exit gehört, über die Grenze zu einem funktionalen Benutzer verschieben. Wenn die Ausgabe eines Funktionsprozesses mehr als eine Datengruppe umfasst, identifizieren Sie einen Exit für jede eindeutige Datengruppe in der Ausgabe. (Siehe auch Abschnitt 3.5.7 zur „Eindeutigkeit der Datenbewegung“.)
b) Ein Exit darf keine Daten über die Grenze eingeben oder Daten aus/in den persistenten Speicher lesen oder schreiben.
Regeln
a) Eine Anfrage, die festen Text ausgibt (wobei „fest“ bedeutet, dass die Nachricht keine variablen Datenwerte enthält, z. B. das Ergebnis des Drückens einer Schaltfläche „Allgemeine Geschäftsbedingungen“ auf einer Einkaufswebsite), muss so modelliert werden, dass sie einen Exit für hat die feste Textausgabe.
HINWEIS: Die Ausgabe der „Hilfe“-Funktionalität finden Sie in der „Richtlinie zur Dimensionierung von Geschäftsanwendungssoftware“. Zur Ausgabe von Meldungen zu Fehlerzuständen oder zur Erfolgsbestätigung siehe Abschnitt 3.5.11 dieses Messhandbuchs.
b) Wenn ein Exit eines Funktionsprozesses eine Datengruppe verschiebt, die bis zu n Datenattribute eines bestimmten Objekts von Interesse umfasst, und die FUR zulässt, dass der Funktionsprozess einen Exit aufweisen kann, der eine Datengruppe mit Werten verschiebt Für Attribute nur einer Teilmenge der „n“ Attribute des interessierenden Objekts muss ein Exit identifiziert werden, der eine Datengruppe verschiebt, die alle „n“ Datenattribute umfasst.
c) Ignorieren Sie bei der Identifizierung von Exits alle Feld- und anderen Überschriften, die es menschlichen Benutzern ermöglichen, die Ausgabedaten zu verstehen.
HINWEIS: Bei der Messung der FUR für Änderungen an Ausgängen kann es erforderlich sein, Feld- und andere Überschriften zu berücksichtigen – siehe Abschnitt 4.4.1
Lesen (R)
Prinzipien
a) Ein Lesevorgang verschiebt eine einzelne Datengruppe, die ein einzelnes Objekt von Interesse beschreibt, aus dem dauerhaften Speicher in einen funktionalen Prozess, zu dem der Lesevorgang gehört. Wenn der Funktionsprozess mehr als eine Datengruppe aus dem persistenten Speicher abrufen muss, identifizieren Sie einen Lesevorgang für jede eindeutige Datengruppe, die abgerufen wird. (Siehe auch Abschnitt 3.5.7 zur „Eindeutigkeit der Datenbewegung“.)
b) Ein Lesevorgang darf keine Daten über die Grenze hinweg empfangen oder ausgeben oder Daten in den dauerhaften Speicher schreiben.
c) Während eines Funktionsprozesses die Bewegung oder Manipulation von Konstanten oder Variablen, die in den Funktionsprozess integriert sind und nur von einem Programmierer geändert werden können, oder die Berechnung von Zwischenergebnissen in einer Berechnung oder von Daten, die nur durch einen Funktionsprozess gespeichert werden aus der Implementierung und nicht aus der FUR, gelten nicht als Lesedatenbewegungen.
d) Eine Lesedatenbewegung umfasst immer alle „Anfrage-zu-Lese“-Funktionalitäten (daher darf eine separate Datenverschiebung niemals für eine „Anfrage-zu-Lese“-Funktionalität gezählt werden). Siehe auch Abschnitt 3.5.9.
Regeln
a) Identifizieren Sie einen Lesevorgang, wenn die gemessene Software laut FUR eine Datengruppe aus dem persistenten Speicher abrufen muss.
b) Identifizieren Sie keinen Lesevorgang, wenn die FUR der gemessenen Software einen funktionalen Software- oder Hardwarebenutzer als Quelle einer Datengruppe oder als Mittel zum Abrufen einer dauerhaft gespeicherten Datengruppe angibt. (Für diesen Fall siehe die Grundsätze und Regeln für Ein- und Ausgänge.)
Schreiben (W)
Prinzipien
a) Ein Schreibvorgang verschiebt eine einzelne Datengruppe, die ein einzelnes interessierendes Objekt beschreibt, aus dem Funktionsprozess, zu dem der Schreibvorgang gehört, in den dauerhaften Speicher. Wenn der Funktionsprozess mehr als eine Datengruppe in den persistenten Speicher verschieben muss, identifizieren Sie einen Schreibvorgang für jede eindeutige Datengruppe, die in den persistenten Speicher verschoben wird. (Siehe auch Abschnitt 3.5.7 zur „Eindeutigkeit der Datenbewegung“.)
b) Ein Schreibvorgang darf keine Daten über die Grenze hinweg empfangen oder ausgeben oder Daten aus dem persistenten Speicher lesen.
c) Die Anforderung, eine Datengruppe aus dem dauerhaften Speicher zu löschen, wird als eine einzelne Schreibdatenbewegung gemessen.
D)
Folgendes gilt nicht als Schreibdatenbewegungen:
- Die Verschiebung oder Manipulation von Daten, die zu Beginn eines Funktionsprozesses nicht vorhanden waren und die nach Abschluss des Funktionsprozesses nicht dauerhaft gespeichert wurden;
- Erstellung oder Aktualisierung von Variablen oder Zwischenergebnissen, die innerhalb des Funktionsprozesses liegen;
- Speicherung von Daten durch einen funktionalen Prozess, der nur aus der Implementierung und nicht aus der FUR resultiert. (Ein Beispiel wäre die Verwendung von Speicher zum vorübergehenden Speichern von Daten während eines großen Sortiervorgangs in einem Stapelverarbeitungsauftrag.)
Regeln
a) Identifizieren Sie einen Schreibvorgang, wenn die gemessene Software gemäß FUR eine Datengruppe in den dauerhaften Speicher verschieben muss.
b) Identifizieren Sie keinen Schreibvorgang, wenn die FUR der gemessenen Software einen beliebigen Software- oder Hardware-Funktionsbenutzer als Ziel der Datengruppe oder als Mittel zum Speichern der Datengruppe angibt. (Für diesen Fall siehe die Grundsätze und Regeln für Ein- und Ausgänge.)
Datenmanipulation im Zusammenhang mit Datenbewegungen
Prinzip
Alle Datenmanipulationen in einem Funktionsprozess müssen mit den vier Arten der Datenbewegung (E, X, R und W) verknüpft sein. Konventionell wird davon ausgegangen, dass die Datenbewegungen eines Funktionsprozesses auch für die Datenmanipulation des Funktionsprozesses verantwortlich sind.
Regeln
a) Eine Eingabedatenbewegung berücksichtigt alle Datenmanipulationen, um die Eingabe einer Datengruppe durch einen funktionalen Benutzer (z. B. Formatierungs- und Präsentationsmanipulationen) und die Validierung zu ermöglichen.
b) Eine Exit-Datenverschiebung berücksichtigt alle Datenmanipulationen, um die Datenattribute einer auszugebenden Datengruppe zu erstellen und/oder um die Ausgabe der Datengruppe (z. B. Formatierungs- und Präsentationsmanipulationen) und die Weiterleitung an den vorgesehenen funktionalen Benutzer zu ermöglichen .
c) Eine Lesedatenbewegung berücksichtigt alle Berechnungen und/oder logischen Verarbeitungen, die zum Abrufen einer Datengruppe aus dem persistenten Speicher erforderlich sind.
d) Eine Schreibdatenbewegung umfasst alle Berechnungen und/oder logischen Verarbeitungen zum Erstellen oder Aktualisieren einer zu schreibenden Datengruppe oder zum Löschen einer Datengruppe.
e) Die mit einer dieser Datenbewegungen verbundene Datenmanipulation umfasst weder Datenmanipulationen, die nach erfolgreichem Abschluss der Datenverschiebung erforderlich sind, noch Datenmanipulationen, die mit anderen Datenbewegungen verbunden sind.
Eindeutigkeit der Datenbewegung und mögliche Ausnahmen
Regeln
Hinweis: Alle COSMIC-Regeln betreffen Arten funktionaler Benutzer, Datengruppen, Datenbewegungen, funktionale Prozesse und interessierende Objekte. Der besseren Lesbarkeit halber verzichten wir in diesen Begriffen normalerweise auf „Typ“. Diese Konvention wird in den folgenden Regeln a), b) und c) befolgt, aber in Regel d) schließen wir „Typ“ ein, wenn es hilfreich ist, einen „Typ“ von einem „Vorkommen“ zu unterscheiden.
a) Sofern die funktionalen Benutzeranforderungen nicht den in den Regeln b) oder c) genannten entsprechen, werden alle Daten, die ein Objekt von Interesse beschreiben und in einen funktionalen Prozess eingegeben werden müssen, als eine Datengruppe identifiziert, die um einen Eintrag verschoben wird.
HINWEIS: Ein funktionaler Prozess kann natürlich mehrere Einträge haben, von denen jeder Daten verschiebt, die ein anderes Objekt von Interesse beschreiben.
Die gleiche entsprechende Regel gilt für alle Lese-, Schreib- oder Ausgangsdatenbewegungen in einem funktionalen Prozess.
b) Wenn funktionale Benutzeranforderungen festlegen, dass unterschiedliche Datengruppen jeweils von einem anderen funktionalen Benutzer in einen funktionalen Prozess eingegeben werden müssen, wobei jede Datengruppe dasselbe interessierende Objekt beschreibt, muss für jede dieser unterschiedlichen Datengruppen ein Eintrag identifiziert werden.
Die gleiche äquivalente Regel gilt für Exits von Daten an verschiedene funktionale Benutzer aus einem funktionalen Prozess.
HINWEIS: Jeder Funktionsprozess darf nur einen auslösenden Eintrag haben.
c) Wenn funktionale Benutzeranforderungen festlegen, dass unterschiedliche Datengruppen aus dem persistenten Speicher in einen funktionalen Prozess verschoben werden müssen, die jeweils dasselbe interessierende Objekt beschreiben, muss für jede dieser unterschiedlichen Datengruppen ein Lesevorgang identifiziert werden.
Die gleiche äquivalente Regel gilt für Schreibvorgänge in einem bestimmten Funktionsprozess.
HINWEIS: Diese Regel ist analog zu Regel b). Im Falle der FUR zum Lesen verschiedener Datengruppen, die dasselbe interessierende Objekt beschreiben, stammen diese wahrscheinlich von unterschiedlichen funktionalen Benutzern. Im Falle der FUR zum Schreiben verschiedener Datengruppen werden diese wahrscheinlich zum Lesen durch verschiedene funktionale Benutzer verfügbar gemacht.
d) Wiederholte Vorkommnisse einer Datenbewegungsart während der Ausführung werden nicht gezählt.
Dies gilt auch dann, wenn sich mehrere Vorkommen des Datenverschiebungstyps in ihrer Ausführung unterscheiden, da unterschiedliche Werte der Datenattribute der verschobenen Datengruppe dazu führen, dass unterschiedliche Verarbeitungspfade durch den funktionalen Prozesstyp durchlaufen werden.
Fehler-/Bestätigungsmeldungen und andere Hinweise auf Fehlerbedingungen
Regeln
a) Ein Exit muss identifiziert werden, um alle Arten von Fehler-/Bestätigungsmeldungen zu berücksichtigen, die von einem funktionalen Prozess der gemessenen Software aus allen möglichen Ursachen entsprechend seiner FUR ausgegeben werden, z. B. Erfolge oder Misserfolge bei: Validierung eingegebener Daten oder für a Aufruf, um Daten abzurufen oder Daten dauerhaft zu machen, oder für die Antwort eines von einer anderen Software angeforderten Dienstes.
HINWEIS: Wenn die FUR des Funktionsprozesses keine Ausgabe irgendeiner Art von Fehler-/Bestätigungsmeldung erfordert, identifizieren Sie keinen entsprechenden Exit.
b) Wenn eine Nachricht an einen menschlichen funktionalen Benutzer zusätzlich zur Bestätigung, dass eingegebene Daten akzeptiert wurden oder dass eingegebene Daten fehlerhaft sind, Daten bereitstellt, sollten diese zusätzlichen Daten als eine Datengruppe identifiziert werden, die auf normale Weise durch einen Exit verschoben wird , zusätzlich zum Fehler-/Bestätigungs-Exit.
c) Alle anderen Daten, die von der zu messenden Software an/von ihren Hardware- oder Software-Funktionsbenutzern ausgegeben oder empfangen werden, sollten gemäß der FUR als Exits bzw. Einträge analysiert werden, gemäß den normalen COSMIC-Regeln, unabhängig davon, ob dies der Fall ist oder nicht Datenwerte weisen auf einen Fehlerzustand hin.
d) Lese- und Schreibvorgänge berücksichtigen alle damit verbundenen Meldungen von Fehlerbedingungen. Daher darf für eine Fehlermeldung, die als Ergebnis eines Lese- oder Schreibvorgangs persistenter Daten eingeht, kein Eintrag in den gemessenen Funktionsprozess identifiziert werden.
e) Für Meldungen, die auf einen Fehlerzustand hinweisen, der möglicherweise während der Verwendung der zu messenden Software ausgegeben wird, aber nicht in irgendeiner Weise von der FUR dieser Software verarbeitet werden muss, z. B. eine von ausgegebene Fehlermeldung, darf kein Ein- oder Ausgang identifiziert werden das Betriebssystem.
Ändern einer Datenverschiebung
Regeln
a) Wenn eine Datenverschiebung aufgrund einer Änderung der mit der Datenverschiebung verbundenen Datenmanipulation und/oder aufgrund einer Änderung der Anzahl oder des Typs der Attribute in der verschobenen Datengruppe geändert werden muss, muss ein geänderter CFP gemessen werden. unabhängig von der tatsächlichen Anzahl der Änderungen in der einen Datenverschiebung.
b) Wenn eine Datengruppe geändert werden muss, werden Datenbewegungen, die die geänderte Datengruppe verschieben und deren Funktionalität durch die Änderung der Datengruppe nicht beeinträchtigt wird, nicht als geänderte Datenbewegungen identifiziert.
HINWEIS: Eine Änderung an Daten, die auf Eingabe- oder Ausgabebildschirmen angezeigt werden und sich nicht auf ein Objekt beziehen, das für einen funktionalen Benutzer von Interesse ist, wird nicht als geändertes CFP identifiziert. (Beispiele für solche Daten finden Sie in Abschnitt 3.3.3.)
Größe der funktional veränderten Software
Regel
Nach funktionaler Änderung einer Software:
Neue Gesamtgröße (geänderte Software) = Alte Gesamtgröße (Software)
+ Σ-Größe (hinzugefügte Datenbewegungen) – Σ-Größe (gelöschte Datenbewegungen)
Messhandbuch, v4.0.2 Copyright © 2017
COSMIC Sizing entspricht dem internationalen Standard: ISO 19761:2011
Neueste Beiträge
Archive
- April 2024
- Dezember 2023
- November 2023
- September 2023
- August 2023
- Juli 2023
- Juni 2023
- April 2023
- März 2023
- Januar 2023
- Dezember 2022
- November 2022
- Oktober 2022
- September 2022
- Juli 2022
- Juni 2022
- Mai 2022
- April 2022
- März 2022
- Februar 2022
- Januar 2022
- Dezember 2021
- Oktober 2021
- Juni 2021
- Mai 2021
- April 2021
- März 2021
- Januar 2021
- Dezember 2020
- Oktober 2020
- September 2020
- Juli 2020
- Juni 2020
- April 2020
- Februar 2020
- Januar 2020
- Dezember 2019
- November 2019
- Oktober 2019
- September 2019
- August 2019
- Juli 2019
- Juni 2019
- Mai 2019
- März 2019
- Februar 2019
- Januar 2019
- Dezember 2018
- November 2018
- September 2018
- August 2018
- Juli 2018
- Juni 2018
- Mai 2018
- April 2018
- März 2018
- Januar 2018
- Dezember 2017
- November 2017
Neueste Kommentare