Voici les des principes et règles trouvé dans la méthode de mesure COSMIC v4.0.2
Agrégation des résultats de mesure
Règles
a) Pour tout processus fonctionnel, les tailles fonctionnelles des mouvements de données individuels doivent être regroupées en une seule valeur de taille fonctionnelle en unités de CFP en les additionnant.
Taille (processus fonctionnel) = Σ taille (entrées) + Σ taille (sorties) + Σ taille (lectures) + Σ taille (écritures)
b) Pour tout processus fonctionnel, la taille fonctionnelle des modifications apportées à ses exigences fonctionnelles d'utilisateur doit être agrégée à partir des tailles des mouvements de données qui ont été ajoutées, modifiées ou supprimées dans le processus fonctionnel pour donner une taille de changement en unités de CFP. , selon la formule suivante.
Taille (Changement (processus fonctionnels)) =
Σ taille (mouvements de données ajoutés) +
Taille Σ (mouvements de données modifiés) + taille Σ (mouvements de données supprimés)
Pour en savoir plus sur l'agrégation de la taille fonctionnelle, voir la section 4.3.2. Pour mesurer la taille du logiciel modifié, voir la section 4.4.2.
c) La taille d'un logiciel dans une portée définie doit être obtenue en agrégeant les tailles des processus fonctionnels pour le morceau, sous réserve des règles e) et f) ci-dessous.
d) La taille de toute modification apportée à un logiciel dans une portée définie doit être obtenue en agrégeant les tailles de toutes les modifications apportées à tous les processus fonctionnels pour le logiciel, sous réserve des règles e) et f) ci-dessous.
e) Les tailles de logiciels ou de modifications apportées à des logiciels ne peuvent être additionnées que si elles sont mesurées au même niveau de granularité de processus fonctionnel de leur FUR.
f) Les tailles des logiciels et/ou les changements dans la taille des logiciels au sein d'une couche ou de différentes couches doivent être additionnés uniquement si cela a du sens, aux fins de la mesure.
g) La taille d'un morceau de logiciel peut être obtenue en additionnant les tailles de ses composants (quelle que soit la façon dont le morceau est décomposé) et en éliminant les contributions de taille des mouvements de données entre les composants.
h) Une seule sortie doit être identifiée pour tous les messages d'erreur/confirmation émis par un processus fonctionnel à un utilisateur fonctionnel humain.
i) Si la méthode COSMIC est étendue localement (par exemple pour mesurer un aspect de la taille non couvert par la méthode standard), alors la taille mesurée via l'extension locale doit être déclarée séparément comme décrit dans la section 5.1 et ne doit PAS être ajoutée à la méthode COSMIC. taille obtenue par la méthode standard, mesurée en CFP (voir plus loin dans la section 4.5).
Commandes de contrôle dans les applications avec une interface humaine
Règle
Dans une application avec une interface humaine, les « commandes de contrôle » doivent être ignorées car elles n'impliquent aucun mouvement de données sur un objet d'intérêt.
Rapports de mesures COSMIC
Règle
En plus des mesures réelles, enregistrées comme en 5.1, certains ou tous les attributs suivants de chaque mesure doivent être enregistrés, en fonction de l'objectif de la mesure et du niveau souhaité de comparabilité avec d'autres mesures, par exemple à des fins d'analyse comparative.
a) Identification du composant logiciel mesuré (nom, ID de version ou ID de configuration).
b) Les sources d'informations utilisées pour identifier le FUR utilisé pour la mesure
c) Le domaine du logiciel
d) Une description de l'architecture des couches dans lesquelles la mesure est effectuée, le cas échéant.
e) Une déclaration sur le but de la mesure.
f) Une description de la portée de la mesure et de sa relation avec la portée globale d'un ensemble de mesures connexe, le cas échéant. (Utilisez les catégories de portée génériques de la section 2.2)
g) Le modèle de stratégie de mesure utilisé (COSMIC ou local), avec le mode de traitement (en ligne ou batch)
h) Les utilisateurs fonctionnels du logiciel
i) Le niveau de granularité des artefacts logiciels disponibles et le niveau de décomposition du logiciel.
j) Le moment du cycle de vie du projet auquel la mesure a été effectuée (en particulier si la mesure est une estimation basée sur des exigences incomplètes ou a été effectuée sur la base de fonctionnalités réellement fournies).
k) La marge d'erreur cible ou supposée de la mesure.
l) Indications si la méthode de mesure standard COSMIC a été utilisée, et/ou une approximation locale de la méthode standard, et/ou si des extensions locales ont été utilisées (voir section 4.5). Utilisez les conventions d'étiquetage des sections 5.1 ou 5.2.
m) Une indication si la mesure concerne une fonctionnalité développée ou livrée (la fonctionnalité « développée » est obtenue par la création d'un nouveau logiciel ; la fonctionnalité « livrée » inclut la fonctionnalité « développée » et inclut également la fonctionnalité obtenue par d'autres moyens que la création d'un nouveau logiciel, c'est-à-dire incluant toutes les formes de réutilisation de logiciels existants, implémentation de progiciels, utilisation de paramètres existants pour ajouter ou modifier des fonctionnalités, etc.).
n) Une indication indiquant si la mesure concerne une fonctionnalité nouvellement fournie ou si elle est le résultat d'une activité « d'amélioration » (c'est-à-dire que la somme concerne les fonctionnalités ajoutées, modifiées et supprimées – voir 4.4).
o) Le nombre de composants principaux, le cas échéant, dont les tailles ont été additionnées pour obtenir la taille totale enregistrée.
p) Le pourcentage de fonctionnalités implémentées par des logiciels réutilisés
q) Pour chaque champ d'application de la portée globale des mesures, une matrice de mesure, comme spécifié à l'annexe A.
r) Le nom du mesureur et toute qualification de certification COSMIC ; la date de la mesure
Étiquetage des mesures COSMIC
Règles
Un résultat de mesure COSMIC doit être noté « x CFP (v) », où :
- 'x' représente la valeur numérique de la taille fonctionnelle,
- « v » représente l'identification de la version standard de la méthode COSMIC utilisée pour obtenir la valeur numérique de taille fonctionnelle « x ». REMARQUE : Si une méthode d'approximation locale a été utilisée pour obtenir la mesure, mais que dans le cas contraire, la mesure a été effectuée en utilisant les conventions de une version COSMIC standard, la convention d'étiquetage ci-dessus doit être utilisée, mais l'utilisation de la méthode d'approximation doit être notée ailleurs – voir la section 5.2. Étiquetage des extensions locales COSMIC
Règle
Un résultat de mesure COSMIC utilisant des extensions locales doit être noté comme suit : 'x CFP (v) + z Local FP', où :
- 'x' représente la valeur numérique obtenue en agrégeant tous les résultats de mesures individuelles selon la méthode standard COSMIC, version v,
- «v» représente l'identification de la version standard de la méthode COSMIC utilisée pour obtenir la valeur numérique de taille fonctionnelle «x».
- « z » représente la valeur numérique obtenue en agrégeant tous les résultats de mesures individuels obtenus à partir d'extensions locales de la méthode COSMIC.
Groupe de données
Principe
Chaque groupe de données identifié doit être unique et distinctif grâce à sa collection unique d'attributs de données.
Identifier différents groupes de données (et donc différents objets d'intérêt) déplacés dans le même processus fonctionnel
Règle
Pour tous les attributs de données apparaissant en entrée d'un processus fonctionnel :
- a) des ensembles d'attributs de données qui ont des fréquences d'occurrence différentes décrivent différents objets d'intérêt ;
- b) des ensembles d'attributs de données qui ont la même fréquence d'occurrence mais des attributs clés d'identification différents décrivent différents objets d'intérêt ;
- c) tous les attributs de données d'un ensemble résultant de l'application des parties a) et b) de cette règle appartiennent au même type de groupe de données, à moins que le FUR ne précise qu'il peut y avoir plus d'un type de groupe de données décrivant le même objet d'intérêt. dans l'entrée du processus fonctionnel (voir Note 3)
Cette même règle s'applique à tous les attributs de données apparaissant dans la sortie d'un processus fonctionnel, ou à tous ceux qui sont déplacés d'un processus fonctionnel vers un stockage persistant, ou à tous ceux qui sont déplacés d'un stockage persistant vers un processus fonctionnel.
NOTE 1. Il peut être utile lors de l'analyse de résultats complexes, par exemple des rapports contenant des données décrivant plusieurs objets d'intérêt, de considérer chaque groupe de données candidats distinct comme s'il était produit par un processus fonctionnel distinct. Chacun des types de groupes de données ainsi identifiés doit également être distingué et compté lors de la mesure du rapport complexe. Pour des exemples, voir le « Guideline for sizing business application software » [7], en particulier l'exemple de la section 2.6.1 et son analyse en 2.6.2. Voir également l'analyse des exemples 4 et 5 dans la section 4.2.4.
NOTE 2. L'examen de la manière dont les attributs de données sont physiquement regroupés ou séparés en entrée ou en sortie peut aider à distinguer différents types de groupes de données, mais ne peut pas être fiable pour les distinguer. À titre d'exemple, deux ou plusieurs ensembles d'attributs de données apparaissant sur la même entrée ou sortie et physiquement séparés pour des raisons esthétiques ou pour faciliter la compréhension, appartiendront au même type de groupe de données s'ils satisfont à la règle ci-dessus.
NOTE 3. Voir la section 3.5 du Manuel de mesure pour les définitions, principes et règles pour les mouvements de données qui déplacent des groupes de données, et la section 3.5.7 (exemples 2, 3, 4 et 5) et 3.5.11 pour les exceptions à ces règles. pour les mouvements de données, conformément à la règle c ci-dessus.
Règles
a) Un processus fonctionnel doit appartenir entièrement au périmètre de mesure d'un logiciel dans une et une seule couche.
b) Un processus fonctionnel doit comprendre au minimum deux mouvements de données, à savoir l'Entrée déclenchante plus soit une Sortie, soit une Ecriture, soit une taille minimale de 2 CFP. Il n'y a pas de limite supérieure au nombre de mouvements de données dans un processus fonctionnel et donc pas de limite supérieure à sa taille.
c) Un processus fonctionnel en cours d'exécution doit être considéré comme terminé lorsqu'il a satisfait à son FUR pour toutes les réponses possibles à son entrée déclenchante. Une pause pendant le traitement pour des raisons techniques ne sera pas considérée comme une fin du processus fonctionnel.
Granularité du processus fonctionnel
|
Niveau de granularité du processus fonctionnel Règles
|
|
Seconde. |
DESCRIPTION DES PRINCIPES ET RÈGLES |
|
approche approximative. Ces approches définissent la manière dont les exigences peuvent être mesurées à des niveaux de granularité plus élevés. Des facteurs d'échelle sont ensuite appliqués aux mesures au(x) niveau(x) de granularité supérieur(s) pour produire une taille approximative au niveau de granularité des processus fonctionnels et de leurs sous-processus de mouvement de données. Voir les « Lignes directrices pour la mesure approximative de la taille fonctionnelle COSMIC » [6]. |
|
Voir également processus fonctionnel
Un processus fonctionnel nécessitant des données d'un utilisateur fonctionnel
Règles
a) Un processus fonctionnel doit obtenir un groupe de données via un mouvement de données d'entrée auprès d'un utilisateur fonctionnel, lorsque le processus fonctionnel n'a pas besoin d'indiquer à l'utilisateur fonctionnel quelles données envoyer, comme dans l'un des quatre cas suivants :
- lorsqu'un utilisateur fonctionnel envoie un groupe de données via une entrée de déclenchement qui lance le processus fonctionnel ;
- lorsqu'un processus fonctionnel, ayant reçu un groupe de données via une entrée de déclenchement, attend, attendant l'arrivée d'un autre groupe de données de l'utilisateur fonctionnel via une entrée (cela peut se produire lorsqu'un utilisateur fonctionnel humain saisit des données dans un logiciel d'application métier) ;
- lorsqu'un processus fonctionnel, après avoir démarré, demande à l'utilisateur fonctionnel « envoyez-moi vos données maintenant, si vous en avez » et que l'utilisateur fonctionnel envoie ses données ;
-
lorsqu'un processus fonctionnel, après avoir démarré, inspecte l'état d'un utilisateur fonctionnel et récupère les données dont il a besoin.
Dans ces deux derniers cas (qui se produisent généralement dans un logiciel de « sondage » en temps réel), par convention, aucune sortie du processus fonctionnel ne doit être identifiée pour obtenir les données requises. Le processus fonctionnel doit simplement envoyer un message d'invite à un utilisateur fonctionnel et la fonctionnalité de ce message d'invite est considérée comme faisant partie de l'entrée. Le processus fonctionnel sait à quelles données s’attendre. Une seule inscription sera identifiée pour ce cas.
b) Lorsqu'un processus fonctionnel doit obtenir les services d'un utilisateur fonctionnel (par exemple pour obtenir des données) et que l'utilisateur fonctionnel doit savoir quoi envoyer (généralement lorsque l'utilisateur fonctionnel est un autre logiciel en dehors de la portée du logiciel étant mesuré), une sortie suivie d'un mouvement de données d'entrée doit être identifiée. La sortie envoie la demande pour les données spécifiques ; l'entrée reçoit les données renvoyées.
Utilisateurs fonctionnels
Règles
a) Les utilisateurs fonctionnels d'un logiciel à mesurer doivent dépendre de l'objectif de la mesure.
b) Lorsque le but d'une mesure d'un morceau de logiciel est lié à l'effort de développement ou de modification du morceau de logiciel, alors les utilisateurs fonctionnels devraient être tous les différents types d'expéditeurs et/ou de destinataires prévus de données vers/depuis le logiciel. fonctionnalité nouvelle ou modifiée, comme l'exige sa FUR.
REMARQUE : FUR peut spécifier qu'un ensemble d'utilisateurs fonctionnels doit être identifié individuellement. Néanmoins ils seront du même type si chaque occurrence est soumise au même FUR
Le modèle logiciel générique
Des principes
a) Un logiciel interagit avec ses utilisateurs fonctionnels au-delà d'une frontière et avec un stockage persistant à l'intérieur de cette frontière.
b) Les exigences fonctionnelles des utilisateurs d'un logiciel à mesurer peuvent être cartographiées en processus fonctionnels uniques.
c) Chaque processus fonctionnel est constitué de sous-processus.
d) Un sous-processus peut être soit un mouvement de données, soit une manipulation de données.
e) Un mouvement de données déplace un seul groupe de données.
f) Il existe quatre types de mouvements de données : entrée, sortie, écriture et lecture.
- Une entrée déplace un groupe de données vers un processus fonctionnel à partir d'un utilisateur fonctionnel.
- Une sortie déplace un groupe de données d'un processus fonctionnel vers un utilisateur fonctionnel.
- Une écriture déplace un groupe de données d'un processus fonctionnel vers un stockage persistant.
- Une lecture déplace un groupe de données du stockage persistant vers un processus fonctionnel.
g) Un groupe de données se compose d'un ensemble unique d'attributs de données qui décrivent un seul objet d'intérêt.
h) Chaque processus fonctionnel est démarré par son déclenchement du mouvement des données d'entrée. Le groupe de données déplacé par l'entrée déclenchante est généré par un utilisateur fonctionnel en réponse à un événement déclencheur.
i) La taille d'un processus fonctionnel est égale au nombre total de ses mouvements de données
j) Un processus fonctionnel doit inclure au moins le mouvement de données d'entrée déclencheur et un mouvement de données d'écriture ou de sortie, c'est-à-dire qu'il doit inclure un minimum de deux mouvements de données. Il n'y a pas de limite supérieure au nombre de mouvements de données dans un processus fonctionnel
k) À titre d'approximation à des fins de mesure, les sous-processus de manipulation des données ne sont pas mesurés séparément ; la fonctionnalité de toute manipulation de données est supposée être prise en compte par le mouvement de données auquel elle est associée
REMARQUE : Le modèle logiciel générique COSMIC, comme son nom l'indique, est un « modèle » logique qui expose les unités dans lesquelles le logiciel traite les données adaptées à la mesure de la taille fonctionnelle. Le modèle n'a pas l'intention de décrire la séquence physique des étapes par lesquelles le logiciel s'exécute ni aucune implémentation technique du logiciel.
Couche
Des principes
a) Les logiciels d'une couche fournissent un ensemble de services cohérents selon un critère défini et que les logiciels des autres couches peuvent utiliser sans savoir comment ces services sont mis en œuvre.
b) La relation entre les logiciels dans deux couches quelconques est définie par une « règle de correspondance » qui peut être soit
- « hiérarchique », c'est-à-dire que les logiciels de la couche A sont autorisés à utiliser les services fournis par les logiciels de la couche B mais pas l'inverse (où la relation hiérarchique peut être ascendante ou descendante), ou
- « bidirectionnel », c'est-à-dire que les logiciels de la couche A sont autorisés à utiliser les logiciels de la couche B, et vice versa.
c) Les logiciels d'une couche échangent des groupes de données avec les logiciels d'une autre couche via leurs processus fonctionnels respectifs.
d) Les logiciels d'une couche n'utilisent pas nécessairement tous les services fonctionnels fournis par les logiciels d'une autre couche.
e) Les logiciels d'une couche d'une architecture logicielle définie peuvent être partitionnés en d'autres couches selon une architecture logicielle définie différente.
Le modèle de contexte du logiciel COSMIC
Des principes
- a) Le logiciel est limité par le matériel.
- b) Les logiciels sont généralement structurés en couches.
- c) Une couche peut contenir un ou plusieurs logiciels « homologues » distincts.
- d) Tout logiciel à mesurer doit être défini par sa portée de mesure, qui doit être entièrement confinée dans une seule couche.
- e) La portée d'un logiciel à mesurer doit dépendre de l'objectif de la mesure.
- f) Les utilisateurs fonctionnels d'un logiciel à mesurer doivent être identifiés à partir de ses exigences fonctionnelles d'utilisateur (FUR) en tant qu'expéditeurs et/ou destinataires prévus de données vers/depuis le logiciel, respectivement.
- g) Les exigences fonctionnelles du logiciel peuvent être exprimées à différents niveaux de granularité.
- h) Une mesure précise de la taille COSMIC d'un logiciel nécessite que ses FUR soient connus aux niveaux de granularité auxquels ses processus et sous-processus fonctionnels peuvent être identifiés.
- i) Une mesure approximative de la taille COSMIC d'un logiciel est possible si ses exigences fonctionnelles sont mesurées à un niveau élevé de granularité par une approche d'approximation et adaptées aux niveaux de granularité des processus et sous-processus fonctionnels.
Niveaux de granularité pour mesurer un processus fonctionnel
Règles
- a) Une mesure de la taille fonctionnelle d'un logiciel nécessite que ses FUR soient connus aux niveaux de granularité auxquels ses processus fonctionnels et ses sous-processus de mouvement de données peuvent être identifiés.
- b) Si certaines exigences doivent être mesurées avant d'avoir été définies de manière suffisamment détaillée pour une mesure précise, les exigences peuvent être mesurées en utilisant une approche approximative. Ces approches définissent la manière dont les exigences peuvent être mesurées à des niveaux de granularité plus élevés. Des facteurs d'échelle sont ensuite appliqués aux mesures au(x) niveau(x) de granularité supérieur(s) pour produire une taille approximative aux niveaux de granularité des processus fonctionnels et de leurs sous-processus de mouvement de données. Voir les lignes directrices pour la mesure précoce ou rapide de la taille fonctionnelle COSMIC par approches d'approximation. [6].
Entrée (E)
Des principes
a) Une entrée doit déplacer un seul groupe de données décrivant un seul objet d'intérêt depuis un utilisateur fonctionnel à travers la frontière et dans le processus fonctionnel dont l'entrée fait partie. Si l'entrée d'un processus fonctionnel comprend plusieurs groupes de données, chacun décrivant un objet d'intérêt différent, identifiez une entrée pour chaque groupe de données unique dans l'entrée. (Voir également la section 3.5.7 sur « Unicité du mouvement des données ».)
b) Une entrée ne doit pas sortir de données au-delà des limites, ni lire ou écrire des données depuis/vers un stockage persistant.
Règles
a) Le groupe de données d'une Entrée déclenchante peut être constitué d'un seul attribut de données qui informe simplement le logiciel qu'« un événement Y s'est produit ». Très souvent, notamment dans les logiciels d'application métier, le groupe de données de l'entrée déclenchante possède plusieurs attributs de données qui informent le logiciel qu'« un événement Y s'est produit et voici les données sur cet événement particulier ».
b) Les tics d'horloge qui déclenchent des événements doivent toujours être externes au logiciel mesuré. Par conséquent, par exemple, un événement de tic-tac se produisant toutes les 3 secondes doit être associé à une entrée déplaçant un groupe de données d'un attribut de données. Notez que cela ne fait aucune différence si l'événement déclencheur est généré périodiquement par le matériel ou par un autre logiciel en dehors des limites du logiciel mesuré.
c) Sauf si un processus fonctionnel spécifique est nécessaire, l'obtention de la date et/ou de l'heure à partir de l'horloge du système ne sera pas considérée comme provoquant une entrée ou tout autre mouvement de données.
d) Si l'occurrence d'un événement spécifique provoque l'entrée d'un groupe de données comprenant jusqu'à « n » attributs de données d'un objet d'intérêt particulier et que le FUR permet que d'autres occurrences du même événement puissent provoquer l'entrée d'un groupe de données qui a valeurs pour les attributs d'un sous-ensemble seulement des « n » attributs de l'objet d'intérêt, alors une entrée doit être identifiée, déplaçant un groupe de données comprenant tous les « n » attributs de données.
e) Lors de l'identification des entrées dans un écran qui permet aux utilisateurs fonctionnels humains de saisir des données dans des processus fonctionnels, analysez uniquement les écrans remplis de données. Ignorez tout écran formaté mais autrement « vide », à l'exception des valeurs par défaut possibles, et ignorez tous les champs et autres en-têtes qui permettent aux utilisateurs humains de comprendre les données d'entrée requises.
NOTE. Il peut être nécessaire de prendre en compte les champs et autres en-têtes lors de la mesure du FUR pour les modifications apportées aux entrées – voir la section 4.4.1.
Sortie (X)
Des principes
a) Une sortie doit déplacer un seul groupe de données décrivant un seul objet d'intérêt du processus fonctionnel dont la sortie fait partie à travers la frontière vers un utilisateur fonctionnel. Si la sortie d'un processus fonctionnel comprend plus d'un groupe de données, identifiez une sortie pour chaque groupe de données unique dans la sortie. (Voir également la section 3.5.7 sur « Unicité du mouvement des données ».)
b) Un Exit ne doit pas saisir de données à travers la frontière, ni lire ou écrire des données depuis/vers un stockage persistant.
Règles
a) Une demande qui génère un texte fixe (où « fixe » signifie que le message ne contient aucune valeur de données variable, par exemple le résultat de l'appui sur un bouton pour les « Conditions générales » sur un site Web d'achat), doit être modélisée comme ayant une sortie pour la sortie de texte fixe.
REMARQUE : Pour connaître le résultat de la fonctionnalité « Aide », consultez les « Directives de dimensionnement des logiciels d'application métier ». Pour l'émission de messages concernant des conditions d'erreur ou confirmant le succès, voir la section 3.5.11 de ce manuel de mesure.
b) Si une sortie d'un processus fonctionnel déplace un groupe de données comprenant jusqu'à « n attributs de données d'un objet d'intérêt particulier et que le FUR permet que le processus fonctionnel puisse avoir une occurrence d'une sortie qui déplace un groupe de données qui a des valeurs pour les attributs d'un sous-ensemble seulement des « n » attributs de l'objet d'intérêt, alors une sortie doit être identifiée, déplaçant un groupe de données comprenant tous les « n » attributs de données.
c) Lors de l'identification des sorties, ignorez tous les champs et autres en-têtes qui permettent aux utilisateurs humains de comprendre les données de sortie.
REMARQUE : Il peut être nécessaire de prendre en compte le champ et d'autres en-têtes lors de la mesure du FUR pour les modifications apportées aux sorties – voir la section 4.4.1.
Lire (R)
Des principes
a) Une lecture doit déplacer un seul groupe de données décrivant un seul objet d'intérêt du stockage persistant vers un processus fonctionnel dont la lecture fait partie. Si le processus fonctionnel doit récupérer plusieurs groupes de données à partir du stockage persistant, identifiez une lecture pour chaque groupe de données unique récupéré. (Voir également la section 3.5.7 sur « Unicité du mouvement des données ».)
b) Une lecture ne doit pas recevoir ou sortir de données au-delà de la frontière ni écrire de données dans un stockage persistant.
c) Au cours d'un processus fonctionnel, mouvement ou manipulation de constantes ou de variables internes au processus fonctionnel et qui ne peuvent être modifiées que par un programmeur, ou calcul de résultats intermédiaires dans un calcul, ou de données stockées par un processus fonctionnel résultant uniquement provenant de la mise en œuvre, plutôt que du FUR, ne doivent pas être considérés comme des mouvements de données de lecture.
d) Un mouvement de données de lecture inclut toujours toute fonctionnalité de « demande de lecture » (un mouvement de données distinct ne doit donc jamais être comptabilisé pour une fonctionnalité de « demande de lecture »). Voir également la section 3.5.9.
Règles
a) Identifiez une lecture lorsque, selon le FUR, le logiciel mesuré doit récupérer un groupe de données à partir d'un stockage persistant.
b) N'identifiez pas de lecture lorsque le FUR du logiciel mesuré spécifie un utilisateur fonctionnel du logiciel ou du matériel comme source d'un groupe de données, ou comme moyen de récupérer un groupe de données stocké de manière persistante. (Pour ce cas, voir les principes et règles d'entrées et de sorties.)
Écrire (W)
Des principes
a) Une écriture doit déplacer un seul groupe de données décrivant un seul objet d'intérêt du processus fonctionnel dont l'écriture fait partie vers le stockage persistant. Si le processus fonctionnel doit déplacer plusieurs groupes de données vers un stockage persistant, identifiez une écriture pour chaque groupe de données unique déplacé vers un stockage persistant. (Voir également la section 3.5.7 sur « Unicité du mouvement des données ».)
b) Une écriture ne doit pas recevoir ou sortir de données au-delà de la frontière, ni lire des données à partir d'un stockage persistant.
c) L'exigence de supprimer un groupe de données du stockage persistant doit être mesurée comme un seul mouvement d'écriture de données.
d)
Les éléments suivants ne doivent pas être considérés comme des mouvements de données d’écriture :
- Le déplacement ou la manipulation de toute donnée qui n'existait pas au début d'un processus fonctionnel et qui n'a pas été rendue persistante une fois le processus fonctionnel terminé ;
- Création ou mise à jour de variables ou de résultats intermédiaires internes au processus fonctionnel ;
- Stockage des données par un processus fonctionnel résultant uniquement de la mise en œuvre, et non du FUR. (Un exemple serait l'utilisation du stockage pour stocker temporairement des données lors d'un processus de tri important dans une tâche traitée par lots.)
Règles
a) Identifiez une écriture lorsque, selon le FUR, le logiciel mesuré doit déplacer un groupe de données vers un stockage persistant.
b) N'identifiez pas d'écriture lorsque le FUR du logiciel mesuré spécifie un utilisateur fonctionnel de logiciel ou de matériel comme destination du groupe de données, ou comme moyen de stockage du groupe de données. (Pour ce cas, voir les principes et règles d'entrées et de sorties.)
Manipulation de données associée aux mouvements de données
Principe
Toute manipulation de données dans un processus fonctionnel doit être associée aux quatre types de mouvement de données (E, X, R et W). Par convention, les mouvements de données d'un processus fonctionnel sont supposés également tenir compte de la manipulation des données du processus fonctionnel.
Règles
a) Un mouvement de données d'entrée prend en compte toutes les manipulations de données pour permettre à un groupe de données d'être saisi par un utilisateur fonctionnel (par exemple, manipulations de formatage et de présentation) et d'être validé.
b) Un mouvement de données de sortie représente toutes les manipulations de données pour créer les attributs de données d'un groupe de données à sortir et/ou pour permettre au groupe de données d'être sorti (par exemple, manipulations de formatage et de présentation) et d'être acheminé vers l'utilisateur fonctionnel prévu. .
c) Un mouvement de données de lecture représente tous les calculs et/ou traitements logiques nécessaires pour récupérer un groupe de données à partir d'un stockage persistant.
d) Un mouvement de données d'écriture représente tous les calculs et/ou traitements logiques pour créer ou mettre à jour un groupe de données à écrire, ou pour supprimer un groupe de données.
e) La manipulation de données associée à l'un de ces mouvements de données n'inclut aucune manipulation de données nécessaire une fois le mouvement de données terminé avec succès, ni aucune manipulation de données associée à tout autre mouvement de données.
Unicité du mouvement des données et exceptions possibles
Règles
NB Toutes les règles COSMIC concernent les types d'utilisateurs fonctionnels, les groupes de données, les mouvements de données, les processus fonctionnels et les objets d'intérêt. Pour faciliter la lecture, nous omettons généralement le mot « type » dans ces termes. Cette convention est suivie dans les règles a), b) et c) ci-dessous, mais dans la règle d), nous incluons le « type » lorsqu'il est utile de distinguer un « type » d'une « occurrence ».
a) À moins que les exigences fonctionnelles de l'utilisateur ne soient celles indiquées dans les règles b) ou c), toutes les données décrivant un objet d'intérêt qui doit être saisi dans un processus fonctionnel doivent être identifiées comme un groupe de données déplacé par une entrée.
REMARQUE : Un processus fonctionnel peut, bien entendu, avoir plusieurs entrées, chacune déplaçant des données décrivant un objet d'intérêt différent.
La même règle équivalente s'applique à tout mouvement de données de lecture, d'écriture ou de sortie dans n'importe quel processus fonctionnel.
b) Si les exigences fonctionnelles des utilisateurs précisent que différents groupes de données doivent être saisis dans un processus fonctionnel, chacun provenant d'un utilisateur fonctionnel différent, où chaque groupe de données décrit le même objet d'intérêt, alors une entrée doit être identifiée pour chacun de ces différents groupes de données.
La même règle équivalente s'applique aux sorties de données vers différents utilisateurs fonctionnels à partir d'un même processus fonctionnel.
REMARQUE : Tout processus fonctionnel ne doit avoir qu'une seule entrée de déclenchement.
c) Si les exigences fonctionnelles de l'utilisateur précisent que différents groupes de données doivent être déplacés du stockage persistant vers un seul processus fonctionnel, chacun décrivant le même objet d'intérêt, alors une lecture doit être identifiée pour chacun de ces différents groupes de données.
La même règle équivalente s'applique aux écritures dans tout processus fonctionnel donné.
REMARQUE : Cette règle est analogue à la règle b). Dans le cas du FUR destiné à lire différents groupes de données décrivant le même objet d'intérêt, ils proviendront probablement de différents utilisateurs fonctionnels. Dans le cas du FUR destiné à écrire différents groupes de données, ils seront probablement mis à disposition pour être lus par différents utilisateurs fonctionnels.
d) Les occurrences répétées de tout type de mouvement de données lors de son exécution ne doivent pas être comptées.
Cela s'applique même si plusieurs occurrences du type de mouvement de données diffèrent dans leur exécution, car différentes valeurs des attributs de données du groupe de données déplacé entraînent le suivi de différents chemins de traitement à travers le type de processus fonctionnel.
Messages d'erreur/confirmation et autres indications de conditions d'erreur
Règles
a) Une sortie doit être identifiée pour prendre en compte tous les types de messages d'erreur/confirmation émis par tout processus fonctionnel du logiciel mesuré à partir de toutes les causes possibles en fonction de son FUR, par exemple les succès ou les échecs de : la validation des données saisies ou pour un appel pour récupérer des données ou pour rendre les données persistantes, ou pour la réponse d'un service demandé à un autre logiciel.
REMARQUE : Si les FUR du processus fonctionnel ne nécessitent l'émission d'aucun type de message d'erreur/confirmation, n'identifiez aucune sortie correspondante.
b) Si un message adressé à un utilisateur fonctionnel humain fournit des données en plus de confirmer que les données saisies ont été acceptées ou que les données saisies sont erronées, alors ces données supplémentaires doivent être identifiées comme un groupe de données déplacé par une sortie de la manière normale. , en plus de l'erreur/confirmation Quitter.
c) Toutes les autres données, émises ou reçues par le logiciel mesuré, vers/depuis ses utilisateurs fonctionnels matériels ou logiciels doivent être analysées conformément au FUR en tant que sorties ou entrées respectivement, selon les règles COSMIC normales, que le les valeurs des données indiquent une condition d’erreur.
d) Les lectures et les écritures sont considérées comme prenant en compte tout rapport associé de conditions d'erreur. Par conséquent, aucune entrée dans le processus fonctionnel mesuré ne doit être identifiée pour toute indication d'erreur reçue à la suite d'une lecture ou d'une écriture de données persistantes.
e) Aucune entrée ou sortie ne doit être identifiée pour tout message indiquant une condition d'erreur qui pourrait survenir lors de l'utilisation du logiciel mesuré mais qui ne doit pas être traité de quelque manière que ce soit par le FUR de ce logiciel, par exemple un message d'erreur émis par le système d’exploitation.
Modifier un mouvement de données
Règles
a) Si un mouvement de données doit être modifié en raison d'un changement dans la manipulation des données associée au mouvement de données et/ou en raison d'un changement dans le nombre ou le type d'attributs dans le groupe de données déplacé, un CFP modifié doit être mesuré, quel que soit le nombre réel de modifications dans un mouvement de données.
b) Si un groupe de données doit être modifié, les mouvements de données déplaçant le groupe de données modifié dont la fonctionnalité n'est pas affectée par la modification du groupe de données ne doivent pas être identifiés comme des mouvements de données modifiés.
REMARQUE : Une modification de toute donnée apparaissant sur les écrans d'entrée ou de sortie qui n'est pas liée à un objet d'intérêt pour un utilisateur fonctionnel ne doit pas être identifiée comme un CFP modifié. (Voir la section 3.3.3 pour des exemples de telles données.)
Taille du logiciel fonctionnellement modifié
Règle
Après avoir modifié fonctionnellement un logiciel :
Nouvelle taille totale (logiciel modifié) = Ancienne taille totale (logiciel)
+ Taille Σ (mouvements de données ajoutés) – Taille Σ (mouvements de données supprimés)
Manuel de mesure, v4.0.2 Copyright © 2017
COSMIC Sizing est conforme à la norme internationale : ISO 19761:2011
Articles récents
Les archives
- avril 2024
- décembre 2023
- novembre 2023
- septembre 2023
- août 2023
- juillet 2023
- juin 2023
- avril 2023
- mars 2023
- janvier 2023
- décembre 2022
- novembre 2022
- octobre 2022
- septembre 2022
- juillet 2022
- juin 2022
- mai 2022
- avril 2022
- mars 2022
- février 2022
- janvier 2022
- décembre 2021
- octobre 2021
- juin 2021
- mai 2021
- avril 2021
- mars 2021
- janvier 2021
- décembre 2020
- octobre 2020
- septembre 2020
- juillet 2020
- juin 2020
- avril 2020
- février 2020
- janvier 2020
- décembre 2019
- novembre 2019
- octobre 2019
- septembre 2019
- août 2019
- juillet 2019
- juin 2019
- mai 2019
- mars 2019
- février 2019
- janvier 2019
- décembre 2018
- novembre 2018
- septembre 2018
- août 2018
- juillet 2018
- juin 2018
- mai 2018
- avril 2018
- mars 2018
- janvier 2018
- décembre 2017
- novembre 2017
Commentaires récents