Estos son los principios y normas encontrado en el Método de Medición COSMIC v4.0.2
Agregar resultados de medición
Normas
a) Para cualquier proceso funcional, los tamaños funcionales de los movimientos de datos individuales se agregarán en un único valor de tamaño funcional en unidades de CFP sumándolos.
Tamaño (proceso funcional) = Σ tamaño(Entradas) + Σ tamaño(Salidas) +Σ tamaño(Lecturas) + Σ tamaño(Escrituras)
b) Para cualquier proceso funcional, el tamaño funcional de los cambios en sus Requisitos Funcionales del Usuario se agregará a partir de los tamaños de los movimientos de datos que se han agregado, modificado o eliminado en el proceso funcional para dar un tamaño del cambio en unidades de CFP. , según la siguiente fórmula.
Tamaño (Cambio (proceso funcional)) =
Σ tamaño (movimientos de datos agregados) +
Σ tamaño (movimientos de datos modificados) +Σ tamaño (movimientos de datos eliminados)
Para obtener más información sobre cómo agregar tamaño funcional, consulte la sección 4.3.2. Para medir el tamaño del software modificado, consulte la sección 4.4.2.
c) El tamaño de una pieza de software dentro de un alcance definido se obtendrá sumando los tamaños de los procesos funcionales de la pieza, sujeto a las reglas e) yf) siguientes
d) El tamaño de cualquier cambio en una pieza de software dentro de un alcance definido se obtendrá sumando los tamaños de todos los cambios en todos los procesos funcionales de la pieza, sujeto a las reglas e) yf) siguientes.
e) Los tamaños de piezas de software o de cambios en piezas de software se pueden sumar solo si se miden en el mismo nivel de granularidad del proceso funcional de su FUR.
f) Los tamaños de piezas de software y/o cambios en los tamaños de piezas de software dentro de cualquier capa o de diferentes capas se sumarán solo si tiene sentido hacerlo, para el propósito de la medición.
g) El tamaño de una pieza de software se puede obtener sumando los tamaños de sus componentes (independientemente de cómo se descomponga la pieza) y eliminando las contribuciones de tamaño de los movimientos de datos entre componentes.
h) Sólo se identificará una Salida para todos los mensajes de error/confirmación emitidos por cualquier proceso funcional a un usuario funcional humano.
i) Si el método COSMIC se extiende localmente (por ejemplo, para medir algún aspecto del tamaño no cubierto por el método estándar), entonces el tamaño medido a través de la extensión local debe informarse por separado como se describe en la sección 5.1 y NO se agregará al tamaño obtenido por el método estándar, medido en CFP (ver más en la sección 4.5).
Comandos de control en aplicaciones con interfaz humana.
Regla
En una aplicación con una interfaz humana, los 'comandos de control' se ignorarán ya que no implican ningún movimiento de datos sobre un objeto de interés.
Informes de medición COSMIC
Regla
Además de las mediciones reales, registradas como en 5.1, se deben registrar algunos o todos los siguientes atributos de cada medición, dependiendo del propósito de la medición y del nivel deseado de comparabilidad con otras mediciones, por ejemplo, con fines de evaluación comparativa.
a) Identificación del componente software medido (nombre, ID de versión o ID de configuración).
b) Las fuentes de información utilizadas para identificar el FUR utilizado para la medición
c) El dominio del software
d) Una descripción de la arquitectura de capas en las que se realiza la medición, si procede.
e) Una declaración del propósito de la medición.
f) Una descripción del alcance de la medición y su relación con el alcance general de un conjunto de mediciones relacionado, si lo hubiera. (Utilice las categorías de alcance genérico en la sección 2.2)
g) El patrón de estrategia de medición utilizado (COSMIC o local), con el modo de procesamiento (en línea o por lotes)
h) Los usuarios funcionales del software
i) El nivel de granularidad de los artefactos de software disponibles y el nivel de descomposición del software.
j) El momento del ciclo de vida del proyecto en el que se realizó la medición (especialmente si la medición es una estimación basada en requisitos incompletos o se realizó sobre la base de la funcionalidad realmente entregada).
k) El margen de error objetivo o estimado de la medición.
l) Indicaciones de si se utilizó el método de medición estándar COSMIC y/o una aproximación local al método estándar, y/o si se utilizaron extensiones locales (ver sección 4.5). Utilice las convenciones de etiquetado de las secciones 5.1 o 5.2.
m) Una indicación de si la medición es de funcionalidad desarrollada o entregada (la funcionalidad 'desarrollada' se obtiene mediante la creación de nuevo software; la funcionalidad 'entregada' incluye la funcionalidad 'desarrollada' y también incluye la funcionalidad obtenida por otros medios además de la creación de nuevo software, es decir, incluyendo todas las formas de reutilización de software existente, implementación de paquetes de software, uso de parámetros existentes para agregar o cambiar funcionalidad, etc.).
n) Una indicación de si la medición es de funcionalidad recién proporcionada o es el resultado de una actividad de 'mejora' (es decir, la suma es de funcionalidad agregada, modificada y eliminada – ver 4.4).
o) El número de componentes principales, en su caso, cuyos tamaños se hayan sumado para obtener el tamaño total registrado.
p) El porcentaje de funcionalidad implementada por software reutilizado
q) Para cada alcance dentro del alcance general de medición, una matriz de medición, según se especifica en el Apéndice A.
r) El nombre del Medidor y cualquier calificación de certificación COSMIC; la fecha de la medición
Etiquetado de medidas COSMIC
Normas
El resultado de una medición COSMIC se indicará como «x CFP (v)», donde:
- 'x' representa el valor numérico del tamaño funcional,
- 'v' representa la identificación de la versión estándar del método COSMIC utilizado para obtener el valor numérico del tamaño funcional 'x'. NOTA: Si se utilizó un método de aproximación local para obtener la medición, pero de lo contrario la medición se realizó utilizando las convenciones de En una versión estándar de COSMIC, se utilizará la convención de etiquetado anterior, pero el uso del método de aproximación debe indicarse en otra parte; consulte la sección 5.2. Etiquetado de extensiones locales de COSMIC.
Regla
El resultado de una medición COSMIC utilizando extensiones locales se indicará como:' x CFP (v) + z Local FP', donde:
- 'x' representa el valor numérico obtenido al agregar todos los resultados de mediciones individuales según el método estándar COSMIC, versión v,
- 'v' representa la identificación de la versión estándar del método COSMIC utilizado para obtener el valor numérico del tamaño funcional 'x'.
- 'z' representa el valor numérico obtenido al agregar todos los resultados de mediciones individuales obtenidos de extensiones locales del método COSMIC.
Grupo de datos
Principio
Cada grupo de datos identificado será único y distinguible a través de su colección única de atributos de datos.
Identificar diferentes grupos de datos (y por tanto diferentes objetos de interés) movidos en el mismo proceso funcional
Regla
Para todos los atributos de datos que aparecen en la entrada de un proceso funcional:
- a) conjuntos de atributos de datos que tienen diferentes frecuencias de aparición describen diferentes objetos de interés;
- b) conjuntos de atributos de datos que tienen la misma frecuencia de aparición pero diferentes atributos clave de identificación describen diferentes objetos de interés;
- c) todos los atributos de datos en un conjunto resultante de la aplicación de las partes a) y b) de esta regla pertenecen al mismo tipo de grupo de datos, a menos que el FUR especifique que puede haber más de un tipo de grupo de datos que describa el mismo objeto de interés. en la entrada al proceso funcional (ver Nota 3)
Esta misma regla se aplica a todos los atributos de datos que aparecen en la salida de un proceso funcional, o todos los que se mueven de un proceso funcional al almacenamiento persistente, o todos los que se mueven del almacenamiento persistente a un proceso funcional.
NOTA 1. Puede resultar útil al analizar resultados complejos, por ejemplo, informes con datos que describen varios objetos de interés, considerar cada grupo de datos candidato por separado como si fuera el resultado de un proceso funcional independiente. Cada uno de los tipos de grupos de datos identificados de esta manera también debe distinguirse y contarse al medir el informe complejo. Para ver ejemplos, consulte la 'Guía para dimensionar el software de aplicaciones empresariales' [7], en particular el ejemplo de la sección 2.6.1 y su análisis en 2.6.2. Véase también el análisis de los ejemplos 4 y 5 en el apartado 4.2.4.
NOTA 2. Examinar cómo se agrupan o separan físicamente los atributos de datos en la entrada o salida puede ayudar a distinguir diferentes tipos de grupos de datos, pero no se puede confiar en él para distinguirlos. Por ejemplo, dos o más conjuntos de atributos de datos que ocurren en la misma entrada o salida y que están físicamente separados por razones estéticas o para facilitar la comprensión, pertenecerán al mismo tipo de grupo de datos si satisfacen la regla anterior.
NOTA 3. Consulte la sección 3.5 del Manual de Medición para las definiciones, principios y reglas para los movimientos de datos que mueven grupos de datos, y la sección 3.5.7 (ejemplos 2, 3, 4 y 5) y 3.5.11 para las excepciones a estas reglas. para movimientos de datos, según la regla c anterior.
Normas
a) Un proceso funcional deberá pertenecer enteramente al alcance de medición de una pieza de software en una y solo una capa.
b) Un proceso funcional comprenderá un mínimo de dos movimientos de datos, es decir, la Entrada desencadenante más una Salida o una Escritura, dando un tamaño mínimo de 2 CFP. No existe un límite superior para el número de movimientos de datos en un proceso funcional y, por tanto, no hay límite superior para su tamaño.
c) Un proceso funcional en ejecución se considerará terminado cuando haya satisfecho su FUR para todas las respuestas posibles a su Entrada desencadenante. Una pausa durante el procesamiento por razones técnicas no se considerará como terminación del proceso funcional.
Granularidad del proceso funcional
|
Nivel de granularidad del proceso funcional. Normas
|
|
Segundo. |
PRINCIPIOS Y NORMAS DESCRIPCIÓN |
|
enfoque aproximado. Estos enfoques definen cómo se pueden medir los requisitos en niveles más altos de granularidad. Luego se aplican factores de escala a las mediciones en los niveles superiores de granularidad para producir un tamaño aproximado en el nivel de granularidad de los procesos funcionales y sus subprocesos de movimiento de datos. Consulte la 'Guía para la medición aproximada del tamaño funcional COSMIC' [6]. |
|
Ver también proceso funcional
Un proceso funcional que requiere datos de un usuario funcional.
Normas
a) Un proceso funcional deberá obtener un grupo de datos a través de un movimiento de datos de entrada de un usuario funcional, cuando el proceso funcional no necesita decirle al usuario funcional qué datos enviar, como en cualquiera de los siguientes cuatro casos:
- cuando un usuario funcional envía un grupo de datos a través de una Entrada desencadenante que inicia el proceso funcional;
- cuando un proceso funcional, después de haber recibido un grupo de datos a través de una Entrada desencadenante, espera, esperando la llegada de un grupo de datos adicional del usuario funcional a través de una Entrada (puede ocurrir cuando un usuario funcional humano ingresa datos en un software de aplicación empresarial);
- cuando un proceso funcional, habiendo iniciado, solicita al usuario funcional, 'envíame ahora tus datos, si los tienes' y el usuario funcional envía sus datos;
-
cuando un proceso funcional, una vez iniciado, inspecciona el estado de un usuario funcional y recupera los datos que requiere.
En los dos últimos casos (que normalmente ocurren en software de 'sondeo' en tiempo real), por convención no se identificará ninguna salida del proceso funcional para obtener los datos requeridos. El proceso funcional simplemente necesita enviar un mensaje rápido a un usuario funcional y la funcionalidad de ese mensaje rápido se considera parte de la Entrada. El proceso funcional sabe qué datos esperar. Sólo se identificará una Entrada para este caso.
b) Cuando un proceso funcional necesita obtener los servicios de un usuario funcional (por ejemplo, para obtener datos) y es necesario decirle al usuario funcional qué enviar (normalmente cuando el usuario funcional es otra pieza de software fuera del alcance del software). midiendo), se identificará una Salida seguida de un movimiento de datos de Entrada. La Salida envía la solicitud de los datos específicos; la Entrada recibe los datos devueltos.
Usuarios funcionales
Normas
a) Los usuarios funcionales de un software a medir dependerán del propósito de la medición.
b) Cuando el propósito de una medición de una pieza de software está relacionado con el esfuerzo de desarrollar o modificar la pieza de software, entonces los usuarios funcionales deben ser todos los diferentes tipos de remitentes y/o destinatarios previstos de datos hacia/desde el funcionalidad nueva o modificada, según lo requiera su FUR.
NOTA: FUR puede especificar que un conjunto de usuarios funcionales deben identificarse individualmente. Sin embargo serán del mismo tipo si cada ocurrencia está sujeta al mismo FUR
El modelo de software genérico
Principios
a) Una pieza de software interactúa con sus usuarios funcionales a través de un límite y con el almacenamiento persistente dentro de este límite.
b) Los requisitos funcionales del usuario de una pieza de software que se va a medir se pueden mapear en procesos funcionales únicos.
c) Cada proceso funcional consta de subprocesos.
d) Un subproceso puede ser un movimiento de datos o una manipulación de datos.
e) Un movimiento de datos mueve un único grupo de datos.
f) Hay cuatro tipos de movimiento de datos, Entrada, Salida, Escritura y Lectura.
- Una entrada mueve un grupo de datos a un proceso funcional desde un usuario funcional.
- Una salida mueve un grupo de datos de un proceso funcional a un usuario funcional.
- Una escritura mueve un grupo de datos de un proceso funcional a un almacenamiento persistente.
- Una lectura mueve un grupo de datos del almacenamiento persistente a un proceso funcional.
g) Un grupo de datos consta de un conjunto único de atributos de datos que describen un único objeto de interés.
h) Cada proceso funcional se inicia al desencadenar el movimiento de datos de Entrada. El grupo de datos movido por la entrada desencadenante es generado por un usuario funcional en respuesta a un evento desencadenante.
i) El tamaño de un proceso funcional es igual al recuento total de sus movimientos de datos.
j) Un proceso funcional incluirá al menos el movimiento de datos de entrada desencadenante y un movimiento de datos de escritura o de salida, es decir, incluirá un mínimo de dos movimientos de datos. No existe un límite superior para la cantidad de movimientos de datos en un proceso funcional.
k) Como aproximación para fines de medición, los subprocesos de manipulación de datos no se miden por separado; Se supone que la funcionalidad de cualquier manipulación de datos se debe al movimiento de datos con el que está asociada.
NOTA: El modelo de software genérico COSMIC, como su nombre indica, es un "modelo" lógico que expone unidades en las que el software procesa datos que son adecuados para la medición del tamaño funcional. El modelo no pretende describir la secuencia física de los pasos mediante los cuales se ejecuta el software ni ninguna implementación técnica del software.
Capa
Principios
a) El software en una capa proporciona un conjunto de servicios que son cohesivos según algún criterio definido, y que el software en otras capas puede utilizar sin saber cómo se implementan esos servicios.
b) La relación entre el software en dos capas cualesquiera se define mediante una "regla de correspondencia" que puede ser
- 'jerárquico', es decir, el software de la capa A puede utilizar los servicios proporcionados por el software de la capa B, pero no al revés (donde la relación jerárquica puede ser superior o inferior), o
- 'bidireccional', es decir, el software de la capa A puede utilizar software de la capa B, y viceversa.
c) El software de una capa intercambia grupos de datos con el software de otra capa a través de sus respectivos procesos funcionales.
d) El software en una capa no necesariamente utiliza todos los servicios funcionales proporcionados por el software en otra capa.
e) El software en una capa de una arquitectura de software definida puede dividirse en otras capas de acuerdo con una arquitectura de software definida diferente.
El modelo de contexto del software COSMIC
Principios
- a) El software está limitado por el hardware.
- b) El software suele estar estructurado en capas.
- c) Una capa puede contener una o más piezas de software "pares" separadas.
- d) Cualquier pieza de software a medir estará definida por su alcance de medición, que estará confinado completamente dentro de una sola capa.
- e) El alcance de una pieza de software a medir dependerá del propósito de la medición.
- f) Los usuarios funcionales de una pieza de software a medir deberán identificarse a partir de sus Requisitos de Usuario Funcional (FUR) como los remitentes y/o destinatarios previstos de los datos hacia/desde el software, respectivamente.
- g) Los requisitos funcionales del software pueden expresarse en diferentes niveles de granularidad.
- h) Una medición precisa del tamaño COSMIC de una pieza de software requiere que se conozca su FUR en los niveles de granularidad en los que se pueden identificar sus procesos y subprocesos funcionales.
- i) Una medición aproximada del tamaño COSMIC de una pieza de software es posible si sus requisitos funcionales se miden con un alto nivel de granularidad mediante un enfoque de aproximación y se escalan a los niveles de granularidad de los procesos y subprocesos funcionales.
Niveles de granularidad para medir un proceso funcional.
Normas
- a) Una medición del tamaño funcional de una pieza de software requiere que se conozcan sus FUR en los niveles de granularidad en los que se pueden identificar sus procesos funcionales y subprocesos de movimiento de datos.
- b) Si algunos requisitos deben medirse antes de que se hayan definido con suficiente detalle para una medición precisa, los requisitos se pueden medir utilizando un enfoque aproximado. Estos enfoques definen cómo se pueden medir los requisitos en niveles más altos de granularidad. Luego se aplican factores de escala a las mediciones en los niveles superiores de granularidad para producir un tamaño aproximado en los niveles de granularidad de los procesos funcionales y sus subprocesos de movimiento de datos. Consulte la Guía para la medición temprana o rápida del tamaño funcional COSMIC mediante enfoques de aproximación. [6].
Entrada (E)
Principios
a) Una Entrada moverá un único grupo de datos que describe un único objeto de interés de un usuario funcional a través de los límites y hacia el proceso funcional del que forma parte la Entrada. Si la entrada a un proceso funcional comprende más de un grupo de datos, cada uno de los cuales describe un objeto de interés diferente, identifique una entrada para cada grupo de datos único en la entrada. (Consulte también la sección 3.5.7 sobre 'Unicidad del movimiento de datos'.)
b) Una Entrada no deberá salir de datos a través del límite, ni leer o escribir datos desde/hacia un almacenamiento persistente.
Normas
a) El grupo de datos de una Entrada desencadenante puede consistir en un solo atributo de datos que simplemente informa al software que "ha ocurrido un evento Y". Muy a menudo, especialmente en software de aplicaciones empresariales, el grupo de datos de la entrada desencadenante tiene varios atributos de datos que informan al software que "ha ocurrido un evento Y y aquí están los datos sobre ese evento en particular".
b) Los tics de reloj que desencadenan eventos siempre serán externos al software que se está midiendo. Por lo tanto, por ejemplo, un evento de tic de reloj que ocurre cada 3 segundos se asociará con una entrada que mueve un grupo de datos de un atributo de datos. Tenga en cuenta que no hay diferencia si el evento desencadenante se genera periódicamente por hardware o por otra pieza de software fuera de los límites del software que se está midiendo.
c) A menos que sea necesario un proceso funcional específico, no se considerará que la obtención de la fecha y/o la hora del reloj del sistema causa una Entrada o cualquier otro movimiento de datos.
d) Si una ocurrencia de un evento específico causa la Entrada de un grupo de datos que comprende hasta 'n' atributos de datos de un objeto de interés particular y el FUR permite que otras ocurrencias del mismo evento puedan causar una Entrada de un grupo de datos que tiene valores para atributos de sólo un subconjunto de los 'n' atributos del objeto de interés, entonces se identificará una Entrada, moviendo un grupo de datos que comprende todos los 'n' atributos de datos.
e) Al identificar Entradas en una pantalla que permite a los usuarios funcionales humanos ingresar datos en procesos funcionales, analice solo las pantallas que estén llenas de datos. Ignore cualquier pantalla formateada pero que esté "en blanco", excepto los posibles valores predeterminados, e ignore todos los campos y otros encabezados que permitan a los usuarios humanos comprender los datos de entrada requeridos.
NOTA. Puede ser necesario considerar campos y otros encabezados al medir FUR para cambios en las Entradas; consulte la sección 4.4.1.
Salir (X)
Principios
a) Una Salida moverá un único grupo de datos que describe un único objeto de interés desde el proceso funcional del que forma parte la Salida a través de la frontera hasta un usuario funcional. Si la salida de un proceso funcional comprende más de un grupo de datos, identifique una Salida para cada grupo de datos único en la salida. (Consulte también la sección 3.5.7 sobre 'Unicidad del movimiento de datos'.)
b) Una Salida no ingresará datos a través del límite, ni leerá ni escribirá datos desde/hacia un almacenamiento persistente.
Normas
a) Una consulta que genera texto fijo (donde "fijo" significa que el mensaje no contiene valores de datos variables, por ejemplo, el resultado de presionar un botón para "Términos y condiciones" en un sitio web de compras), se modelará con una salida para la salida de texto fijo.
NOTA: Para conocer el resultado de la funcionalidad 'Ayuda', consulte la 'Guía para dimensionar el software de aplicaciones empresariales'. Para la salida de mensajes relacionados con condiciones de error o confirmación de éxito, consulte la sección 3.5.11 de este Manual de medición.
b) Si una Salida de un proceso funcional mueve un grupo de datos que comprende hasta 'n' atributos de datos de un objeto de interés particular y el FUR permite que el proceso funcional pueda tener una ocurrencia de una Salida que mueve un grupo de datos que tiene valores para atributos de sólo un subconjunto de los 'n' atributos del objeto de interés, se identificará una Salida, moviendo un grupo de datos que comprenda todos los 'n' atributos de datos.
c) Al identificar Salidas, ignore todos los campos y otros encabezados que permitan a los usuarios humanos comprender los datos de salida.
NOTA: Puede ser necesario considerar campos y otros encabezados al medir FUR para cambios en las Salidas; consulte la sección 4.4.1
Leer (R)
Principios
a) Una lectura moverá un único grupo de datos que describe un único objeto de interés desde el almacenamiento persistente a un proceso funcional del que forma parte la lectura. Si el proceso funcional debe recuperar más de un grupo de datos del almacenamiento persistente, identifique una lectura para cada grupo de datos único que se recupere. (Consulte también la sección 3.5.7 sobre 'Unicidad del movimiento de datos'.)
b) Una lectura no recibirá ni saldrá de datos a través del límite ni escribirá datos en un almacenamiento persistente.
c) Durante un proceso funcional, movimiento o manipulación de constantes o variables que son internas al proceso funcional y que sólo pueden ser cambiadas por un programador, o cálculo de resultados intermedios en un cálculo, o de datos almacenados por un proceso funcional que resulta únicamente provenientes de la implementación, y no del FUR, no se considerarán movimientos de datos de lectura.
d) Un movimiento de datos de lectura siempre incluye cualquier funcionalidad de 'solicitud de lectura' (por lo que un movimiento de datos separado nunca se contará para ninguna funcionalidad de 'solicitud de lectura'). Véase también la sección 3.5.9.
Normas
a) Identificar una Lectura cuando, según el FUR, el software que se está midiendo debe recuperar un grupo de datos del almacenamiento persistente.
b) No identificar una Lectura cuando el FUR del software que se está midiendo especifica cualquier usuario funcional de software o hardware como fuente de un grupo de datos, o como medio para recuperar un grupo de datos almacenado persistentemente. (Para este caso ver los principios y reglas de Entradas y Salidas.)
Escribir (W)
Principios
a) Una escritura moverá un único grupo de datos que describe un único objeto de interés desde el proceso funcional del que forma parte la escritura al almacenamiento persistente. Si el proceso funcional debe mover más de un grupo de datos al almacenamiento persistente, identifique una escritura para cada grupo de datos único que se mueva al almacenamiento persistente. (Consulte también la sección 3.5.7 sobre 'Unicidad del movimiento de datos'.)
b) Una escritura no recibirá ni saldrá de datos a través del límite, ni leerá datos del almacenamiento persistente.
c) El requisito de eliminar un grupo de datos del almacenamiento persistente se medirá como un único movimiento de datos de escritura.
d)
No se considerarán movimientos de datos de escritura:
- El movimiento o manipulación de cualquier dato que no existía al inicio de un proceso funcional y que no se haya hecho persistente cuando se complete el proceso funcional;
- Creación o actualización de variables o resultados intermedios internos al proceso funcional;
- Almacenamiento de datos mediante un proceso funcional resultante únicamente de la implementación, y no del FUR. (Un ejemplo sería el uso del almacenamiento para almacenar datos temporalmente durante un proceso de clasificación grande en un trabajo procesado por lotes).
Normas
a) Identificar una Escritura cuando, según el FUR, el software que se está midiendo debe mover un grupo de datos a un almacenamiento persistente.
b) No identificar una Escritura cuando el FUR del software que se está midiendo especifique cualquier usuario funcional de software o hardware como destino del grupo de datos, o como medio para almacenar el grupo de datos. (Para este caso ver los principios y reglas de Entradas y Salidas.)
Manipulación de datos asociada a movimientos de datos.
Principio
Toda manipulación de datos en un proceso funcional estará asociada a los cuatro tipos de movimiento de datos (E, X, R y W). Por convención, se supone que los movimientos de datos de un proceso funcional también tienen en cuenta la manipulación de datos del proceso funcional.
Normas
a) Un movimiento de datos de entrada representa toda la manipulación de datos para permitir que un usuario funcional ingrese un grupo de datos (por ejemplo, manipulaciones de formato y presentación) y lo valide.
b) Un movimiento de datos de salida representa toda la manipulación de datos para crear los atributos de datos de un grupo de datos que se generará y/o para permitir que el grupo de datos se genere (por ejemplo, manipulaciones de formato y presentación) y se enrute al usuario funcional previsto. .
c) Un movimiento de lectura de datos representa todos los cálculos y/o procesamiento lógico necesarios para recuperar un grupo de datos del almacenamiento persistente.
d) Un movimiento de datos de escritura representa todo el cálculo y/o procesamiento lógico para crear o actualizar un grupo de datos que se va a escribir, o para eliminar un grupo de datos.
e) La manipulación de datos asociada con cualquiera de estos movimientos de datos no incluye ninguna manipulación de datos que sea necesaria después de que el movimiento de datos se haya completado con éxito, ni incluye ninguna manipulación de datos asociada con ningún otro movimiento de datos.
Unicidad del movimiento de datos y posibles excepciones.
Normas
NB Todas las reglas de COSMIC se refieren a tipos de usuarios funcionales, grupos de datos, movimientos de datos, procesos funcionales y objetos de interés. Para facilitar la lectura, normalmente omitimos "tipo" en estos términos. Esta convención se sigue en las reglas a), b) yc) siguientes, pero en la regla d) incluimos "tipo" cuando es útil distinguir un "tipo" de una "ocurrencia".
a) A menos que los Requisitos Funcionales del Usuario sean los indicados en las reglas b) o c), todos los datos que describan cualquier objeto de interés que deba ingresarse en un proceso funcional se identificarán como un grupo de datos movido por una Entrada.
NOTA: Un proceso funcional puede, por supuesto, tener múltiples Entradas, cada una de las cuales mueve datos que describen un objeto de interés diferente.
La misma regla equivalente se aplica a cualquier movimiento de datos de lectura, escritura o salida en cualquier proceso funcional.
b) Si los Requisitos Funcionales del Usuario especifican que se deben ingresar diferentes grupos de datos en un proceso funcional, cada uno de ellos desde un usuario funcional diferente, donde cada grupo de datos describe el mismo objeto de interés, entonces se identificará una Entrada para cada uno de estos diferentes grupos de datos.
La misma regla equivalente se aplica a las Salidas de datos a diferentes usuarios funcionales desde cualquier proceso funcional.
NOTA: Cualquier proceso funcional deberá tener solo una Entrada desencadenante.
c) Si los Requisitos Funcionales del Usuario especifican que se deben mover diferentes grupos de datos del almacenamiento persistente a un proceso funcional, cada uno de los cuales describe el mismo objeto de interés, entonces se identificará una Lectura para cada uno de estos diferentes grupos de datos.
La misma regla equivalente se aplica a las escrituras en cualquier proceso funcional determinado.
NOTA: Esta regla es análoga a la regla b). En el caso de que el FUR lea diferentes grupos de datos que describen el mismo objeto de interés, probablemente se originarán en diferentes usuarios funcionales. En el caso de que el FUR escriba diferentes grupos de datos, es probable que estén disponibles para ser leídos por diferentes usuarios funcionales.
d) No se computarán las ocurrencias repetidas de cualquier tipo de movimiento de datos durante su ejecución.
Esto se aplica incluso si varias apariciones del tipo de movimiento de datos difieren en su ejecución porque diferentes valores de los atributos de datos del grupo de datos movido dan como resultado que se sigan diferentes rutas de procesamiento a través del tipo de proceso funcional.
Mensajes de error/confirmación y otras indicaciones de condiciones de error
Normas
a) Se identificará una salida para dar cuenta de todos los tipos de mensajes de error/confirmación emitidos por cualquier proceso funcional del software que se mide desde todas las causas posibles según su FUR, por ejemplo, éxitos o fracasos de: validación de datos ingresados o para una llamada para recuperar datos o para hacer que los datos sean persistentes, o para la respuesta de un servicio solicitado de otra pieza de software.
NOTA: Si los FUR del proceso funcional no requieren emitir ningún tipo de mensaje de error/confirmación, no identificar ninguna Salida correspondiente.
b) Si un mensaje a un usuario funcional humano proporciona datos además de confirmar que los datos ingresados han sido aceptados, o que los datos ingresados son erróneos, entonces estos datos adicionales deben identificarse como un grupo de datos movido por una Salida de la manera normal. , además del error/confirmación Salir.
c) Todos los demás datos, emitidos o recibidos por el software que se está midiendo, hacia/desde sus usuarios funcionales de hardware o software deben analizarse de acuerdo con el FUR como Salidas o Entradas respectivamente, de acuerdo con las reglas COSMIC normales, independientemente de si el los valores de datos indican una condición de error.
d) Se considera que las lecturas y escrituras tienen en cuenta cualquier informe asociado de condiciones de error. Por lo tanto, no se identificará ninguna entrada al proceso funcional que se está midiendo para ninguna indicación de error recibida como resultado de una lectura o escritura de datos persistentes.
e) No se identificará ninguna Entrada o Salida para ningún mensaje que indique una condición de error que podría emitirse mientras se utiliza el software que se está midiendo pero que no requiere ser procesado de ninguna manera por el FUR de ese software, por ejemplo, un mensaje de error emitido por El sistema operativo.
Modificar un movimiento de datos
Normas
a) Si un movimiento de datos debe modificarse debido a un cambio en la manipulación de datos asociada con el movimiento de datos y/o debido a un cambio en el número o tipo de atributos en el grupo de datos movido, se medirá un CFP modificado. independientemente del número real de modificaciones en un movimiento de datos.
b) Si es necesario modificar un grupo de datos, los movimientos de datos que muevan el grupo de datos modificado cuya funcionalidad no se vea afectada por la modificación del grupo de datos no se identificarán como movimientos de datos modificados.
NOTA: Una modificación de cualquier dato que aparezca en las pantallas de entrada o salida que no esté relacionada con un objeto de interés para un usuario funcional no se identificará como un CFP modificado. (Consulte la sección 3.3.3 para ver ejemplos de dichos datos).
Tamaño del software funcionalmente modificado
Regla
Después de cambiar funcionalmente una pieza de software:
Nuevo tamaño total (pieza de software modificada) = Tamaño total antiguo (pieza de software)
+ Σ tamaño (movimientos de datos agregados) – Σ tamaño (movimientos de datos eliminados)
Manual de medición, v4.0.2 Copyright © 2017
COSMIC Sizing cumple con la norma internacional: ISO 19761:2011
Entradas recientes
- Dimensionamiento del trabajo pendiente y control de calidad con un solo clic para Jira Software
- Evaluación comparativa de software y evaluaciones comparativas apropiadas
- Disponibilidad del servidor ScopeMaster
- Reseñas de 5 estrellas
- Dimensionamiento y aseguramiento de proyectos de transformación digital
Archivos
- abril 2024
- diciembre 2023
- noviembre 2023
- septiembre 2023
- agosto 2023
- julio 2023
- junio 2023
- abril 2023
- marzo 2023
- enero 2023
- diciembre 2022
- noviembre 2022
- octubre 2022
- septiembre 2022
- julio 2022
- junio 2022
- mayo 2022
- abril 2022
- marzo 2022
- febrero 2022
- enero 2022
- diciembre 2021
- octubre 2021
- junio 2021
- mayo 2021
- abril 2021
- marzo 2021
- enero 2021
- diciembre 2020
- octubre 2020
- septiembre 2020
- julio 2020
- junio 2020
- abril 2020
- febrero 2020
- enero 2020
- diciembre 2019
- noviembre 2019
- octubre 2019
- septiembre 2019
- agosto 2019
- julio 2019
- junio 2019
- mayo 2019
- marzo 2019
- febrero 2019
- enero 2019
- diciembre 2018
- noviembre 2018
- septiembre 2018
- agosto 2018
- julio 2018
- junio 2018
- mayo 2018
- abril 2018
- marzo 2018
- enero 2018
- diciembre 2017
- noviembre 2017
Comentarios recientes