Ingeniera de Sistemas

1




MTODO DE ESTIMACIN COSMIC




1. Introduccin

COSMIC es una agrupacin voluntaria mundial de expertos de mtricas de
software. Iniciado en 1998. Originalmente, el mtodo fue desarrollado por un
equipo de la Universidad de Qubec encabezado por el profesor Denis St-Pierre
con el fin de ampliar el dominio funcional del mtodo de puntos funcin hacia
entornos en tiempo real.

COSMIC ha desarrollado el mtodo ms avanzado para medir el tamao funcional
del software. Tales medidas son importantes como las medidas de proyecto de
software de trabajo-producto y para la estimacin de esfuerzo del proyecto, etc

El mtodo es aplicable a los negocios, en tiempo real y software de
infraestructura, es fcil de aprender y fcil de usar. El mtodo es completamente
"abierta".


2. Medida del tamao funcional (FSM)



2.1. Cul es el Tamao funcional?


No existe una escala de medida de tamao para el software como el sistema
mtrico para medir la longitud que se acuerda universalmente
sucesivamente. Slo hay varios mtodos para medir 'un' tamao del software
de la variacin de utilidad, exactitud, facilidad de uso y el valor.


Bsicamente, hay dos tipos de medidas del tamao del software, ya sea que
usted puede medir la cantidad de "funcionalidad" que se requiere el software
para proporcionar, o se puede medir el tamao de los componentes fsicos
del software cuando se crea.


A 'Tamao Funcional "se define en la norma ISO / IEC 14143/1: 2011 como"
un tamao de software derivado mediante la cuantificacin de los Requisitos
Funcionales de Usuario ".
Ingeniera de Sistemas

2



2.2. Ejemplos


Algunos ejemplos muy simplificados del FUR (Requerimientos Funcionales
del Usuario), cuya funcionalidad se puede medir seran:


El software debe ser capaz de registrar datos sobre los nuevos
empleados, y para actualizar los datos a medida que cambian su estado
civil, obtener un ascenso, se van o mueren
El software debe ser capaz de recibir seales de la temperatura real,
compararlo con un pre-temperatura establecido como objetivo y enviar
seales de control a un calentador para mantener la temperatura dentro
de ms o menos 1 grado centgrado de la temperatura objetivo
El software debe recuperar el registro dado de almacenamiento en disco
y, o bien devolverlo o devolver un error que indica mensaje para
recuperar.


Algunos ejemplos de necesidades de los usuarios que no se considerara
contribuir a una medicin del tamao funcional, ya que son los requisitos
tcnicos o de calidad.


2.3. Ventajas


Medidas de tamao funcionales tienen las ventajas, por tanto, que:


Son independientes de la tecnologa utilizada para desarrollar e
implementar el software.
Puede estimarse a partir de las declaraciones de principios de los
requisitos en la vida de un proyecto.


3. Mtodo de Medicin del Tamao Funcional COSMIC

El mtodo COSMIC define los principios, normas y un proceso para medir el
tamao funcional estndar de una pieza de software. "Tamao funcional" es una
medida de la cantidad de funcionalidad que proporciona el software,
completamente independiente de cualquier factor tcnico o de calidad.


3.1. Aplicabilidad del mtodo

El mtodo COSMIC se puede utilizar para software de tamao tal como
aplicaciones de negocios; software en tiempo real; software de infraestructura,
como en los sistemas operativos; e hbridos de stos. La caracterstica comn
de todos estos tipos de software es que estn dominados por las funciones
Ingeniera de Sistemas

3



que los datos de entrada, almacenar y recuperar datos y salida de datos.
El mtodo se puede aplicar para medir el pelaje de software:
En cualquier nivel de descomposicin, por ejemplo, una pieza "todo" de
software o cualquiera de sus componentes, subcomponentes, etc
En cualquier capa de una arquitectura de capas mltiples
En cualquier punto en el ciclo de vida de la pieza de software.


3.2. Los principios para la medicin del tamao funcional COSMIC
de una pieza de software


El mtodo COSMIC mide un tamao como se ve por el 'users funcional "de la
pieza de software a medir, es decir, los remitentes y / o destinatarios de los
datos que debe entrar o salir del software, respectivamente.
El mtodo utiliza un modelo de software, conocido como el 'COSMIC Generic
Software Model', que se basa en los principios fundamentales de ingeniera
de software, a saber:


Necesidades de los usuarios funcionales de una pieza de software se
pueden analizar los procesos funcionales nicas, que consisten en sub-
procesos. Un sub-proceso puede ser o bien un movimiento de datos o
una manipulacin de datos
Cada proceso funcional es desencadenada por un movimiento de datos
"Entrada" de un usuario funcional que informa al proceso funcional que el
usuario funcional ha identificado un caso de que el software debe
responder a
Un movimiento de datos mueve un solo grupo de datos de atributos que
describe un nico "objeto de inters", en el que el ltimo es una "cosa" de
inters para un usuario funcional.


Hay cuatro tipos de sub-procesos de movimiento de datos:
Entry mueve un grupo de datos en el software de un usuario
funcional.
Exit mueve un grupo de datos fuera.
Escribe
Lee se mueve un grupo de datos hacia y desde el almacenamiento
persistente, respectivamente.


El tamao de una pieza de software se define como el nmero total de
movimientos de datos (entradas, salidas, lee y escribe) sumados por todos los
procesos funcionales de la pieza de software.
Ingeniera de Sistemas

4



4. Los usos de COSMIC Tamao Funcional

Los usos principales de tamaos de software, especialmente de un tamao
funcional COSMIC que se pueden medir y volver a medir como un proyecto pase
son:


4.1. Proyecto de Estimacin


Cmo es de grande? es la primera pregunta que viene a la mente cuando un
director de proyecto se enfrenta a una demanda para estimar el costo de
desarrollo de una nueva pieza de software. Si somos capaces de poner una
medida de tamao en los requisitos para una nueva pieza de software,
entonces hemos dado el primer paso fundamental para estimar el costo y el
tiempo que se necesitar para su desarrollo. Varias herramientas de
estimacin de proyectos comercialmente disponibles aceptarn tamaos
funcionales COSMIC como entrada.


4.2. Medicin del Desempeo del Proyecto


La capacidad de medir el rendimiento es fundamental para comprender y
mejorar el rendimiento. "Productividad". Para el desarrollo de software se
interpreta como 'software tamao funcional' / 'esfuerzo del proyecto'.


Otras medidas importantes de desempeo de desarrollo de proyectos de
software incluyen:


La velocidad de la entrega = Tamao de software / transcurrido el tiempo.
Densidad de defectos = Nmero de defectos identificados en un
determinado perodo /' tamao del software.



4.3. Alcance Control de Proyectos


Si un proveedor le da una estimacin a un cliente por el costo de un nuevo
desarrollo, y el cliente luego aade nuevos requisitos, el proveedor quiera
responder, ya sea aumentando la estimacin del costo o mediante la
negociacin sobre el alcance de las necesidades del cliente. De cualquier
manera, la capacidad de medir el tamao del software y / o de cualquier
propuesta de cambio en funcin de los requisitos es un parmetro crtico para
ambas partes en las negociaciones.
Ingeniera de Sistemas

5



4.4. Control de Calidad de Requerimientos de Software


El proceso de medicin de un tamao funcional de una exposicin de las
necesidades proporciona un muy buen control sobre la calidad (claridad,
completitud y consistencia) de los requisitos. Si los requisitos no estn claros
de manera que un tamao funcional no puede ser medida correctamente,
entonces los desarrolladores tambin se enfrentan a las dificultades; van a
tener que hacer suposiciones, que pueden o no ser correcta.

4.5. Bases para la Prueba de Planificacin del Caso


El proceso de medicin de un tamao funcional COSMIC de los requisitos de
una pieza de software implica la identificacin de los procedimientos
funcionales" del software (consulte la seccin "Mtodo" de este sitio). Una
lista de los procesos funcionales de una pieza de software es una muy buena
base para la planificacin de casos de prueba.


5. Ventajas



5.1. Las ventajas del mtodo COSMIC


El mtodo COSMIC tiene las siguientes ventajas nicas. El mtodo:


Tiene la aplicabilidad ms amplia de cualquier mtodo estndar ISO FSM.


Fue diseado para medir la aplicacin de negocio, en tiempo real, y el
software de infraestructura (por ejemplo, el software del sistema operativo).


Utiliza un modelo de software basado en los principios fundamentales de
ingeniera de software.


Incluye un nmero de variantes aproximadas del mtodo de medicin de
tamao estndar que puede ser utilizado para la medicin rpida y / o
temprano en la vida de una pieza de software antes de que todos los
detalles de los requisitos han sido completamente definido.


Permite la medicin de diferentes tamaos posibles para cualquier pieza
de software, por ejemplo, de la totalidad y de sus componentes, y como
"visto" por diferentes "usuarios funcionales" del software.


Es fcil de aprender y fcil de usar.
Ingeniera de Sistemas

6



Est completamente abierta. Toda la documentacin est disponible
para su descarga gratuita.


5.2. Ventajas del uso de COSMIC para los usuarios:


Como es fcil de aprender y utilizar y se mantiene estable, basado
en principios y por lo tanto "a prueba de futuro", que es muy rentable de
implementar.


El proceso de medicin y los resultados son bien aceptados por el
personal del proyecto por la compatibilidad del mtodo con los mtodos
de documentacin de requisitos de software modernas.


Posibles requisitos de tamao de forma automtica que se celebran en
las herramientas CASE da mejores resultados


Mejora de la estimacin de la precisin, especialmente para los
proyectos de software ms grandes;


Revela la mejora del rendimiento real en el que el uso de algunos
mtodos anteriores de tamao primera generacin no ha indicado
ninguna mejora debido al corte arbitrario en la escala de tamao;


Dimensionamiento con COSMIC es una excelente manera de controlar
la calidad de los requisitos de software en todas las etapas a medida
que evolucionan.




6. El proceso para medir el tamao funcional COSMIC de una pieza de
software


El proceso de medicin COSMIC tiene tres fases, como se muestra en la
siguiente figura:








Ingeniera de Sistemas

7


EL proceso de COSMIC tiene tres fases como se muestra en la siguiente figura.
Ingeniera de Sistemas

8


7. Manual de medicin



1) Introduccin



1.1) Aplicabilidad del mtodo COSMIC

a. Dominios de aplicacin

El mtodo de medicin del tamao funcional COSMIC est concebido para ser
aplicable a la funcionalidad del software de los siguientes dominios:


Aplicaciones Software de Gestin, las cuales son las tpicamente utilizadas
para dar soporte a la administracin de negocios, tales como banca, seguros,
etc. Gestiona grandes cantidades de datos acerca de aspectos del mundo
real.
Software en tiempo real, cuya tarea es mantener o controlar
acontecimientos que estn sucediendo en el mundo real. Algunos ejemplos
seran el software para centrales telefnicas y de intercambio de mensajes.
Hbridos de lo anterior, como por ejemplo los sistemas de reservas
en tiempo real de compaas areas u hoteles.


b. Dominio no aplicable
El mtodo de medicin COSMIC an no ha sido diseado para tener en
cuenta la funcionalidad del software matemticamente intensivo, esto es,
software caracterizado por algoritmos matemticos complejos, como por ejemplo
sistemas expertos, software de simulacin, software de auto-aprendizaje,
sistemas de prediccin meteorolgica, etc., o de sonidos de audio o imgenes de
vdeo (software para juegos de ordenador, instrumentos musicales, etc.)


c. Limitaciones de los factores que contribuyen a tamao funcional
Adems, dentro de su dominio de aplicabilidad, el mtodo de medicin de
tamao funcional COSMIC no intenta medir todos los posibles aspectos de
la funcionalidad que podran considerarse para contribuir al tamao del
software. Por ejemplo, ni la influencia de la complejidad (independientemente
de su definicin), ni la influencia del nmero de atributos de datos por el
movimiento de datos en el tamao funcional del software son utilizados por este
mtodo de medicin.


d. Limitaciones en la medicin de aplicaciones software muy pequeas
Es necesario cierto cuidado al medir, comparar o utilizar (por ejemplo, para la
estimacin) tamaos de software muy especialmente los cambios muy
pequeos de una aplicacin software, donde las consideraciones medias
Ingeniera de Sistemas

9
pueden no ser aplicables. En el caso del mtodo COSMIC, 'muy pequeo'
significa con pocos movimientos de datos.

1.2) Requisitos Funcionales de Usuarios


El mtodo de medicin COSMIC supone la aplicacin de un conjunto de modelos,
principios, reglas y procesos a los Requisitos Funcionales de los Usuarios (o
Functional User Requirements, FUR) de una determinada aplicacin software. El
resultado es un valor de una cantidad numrico (tal y como se define en ISO), que
representa el tamao funcional de la aplicacin software de acuerdo con el mtodo
COSMIC.


Una declaracin de FUR describe qu debe hacer el software por los usuarios
funcionales, que son los remitentes y destinatarios de los datos, hacia y desde el
software. Una declaracin del FUR excluye cualesquiera requisitos tcnicos o los de
calidad que digan cmo debe funcionar el software. A la hora de medir el tamao
funcional slo los FUR son tenidos en cuenta.


Extraccin de los requisitos funcionales de usuario a partir de los
artefactos del software en la prctica
Deduccin de los requisitos funcionales de usuario a partir de
software instalado
Extraccin o deduccin de los requisitos funcionales de usuario a partir de
artefactos software.

2) Fase de estrategia de medicin

Cuatro parmetros fundamentales de medicin del tamao funcional del software que
debe ser considerados antes de comenzar a medir, estos son: el propsito y el alcance
de la medicin, la identificacin de los usuarios funcionales y el nivel de granularidad
que debe medirse. Determinar estos parmetros ayuda a abordar las cuestiones de
qu tamao debe medirse? o, para una medicin existente, cmo debemos
interpretar esta medida?










Ingeniera de Sistemas

10



2.1) Definir el propsito de la Medicin

Una declaracin que define por qu una medida es necesaria, y para qu se
utilizar el resultado.



El propsito de una medicin determina el tamao que ser medido,
ejemplos: Medir el tamao de los FUR a medida que evolucionan, como
entrada a un proceso de estimacin del esfuerzo de desarrollo, Medir el
tamao de los cambios de FUR despus de haber sido inicialmente
acordados, con el fin de gestionar el alcance avanzado de un proyecto,
etc.


La importancia del propsito: Determina el alcance que debe medirse y
los aparatos que sern necesarios para la medicin, los usuarios funcionales,
el momento en el ciclo de vida del proyecto en el que la medicin se llevar a
cabo.



Ingeniera de Sistemas

11







2.2) Definir el alcance de la medicin

El conjunto de los requisitos funcionales de usuario que deben incluirse en un
determinado ejercicio de medicin de tamao funcional.


El alcance de una medicin depende de la finalidad: Es
importante definir el alcance de una medicin antes de comenzar un
ejercicio de medicin. El propsito de la medicin debe ser siempre
utilizado para determinar (a) qu software es incluido o excluido del alcance
global y (b) la forma en que el software incluido puede que sea necesario
dividirlo en partes separadas, cada una con su propio alcance, que deben
medirse por separado.



Tipos genricos de alcance: Ejemplos:


La cartera de proyectos de una empresa
Un acuerdo contractual de especificacin de requisitos
El producto entregado por el equipo de trabajo de un proyecto.
Una aplicacin.
Un objeto de clase re-utilizable.



Niveles de descomposicin: Cualquier nivel resultante de dividir una parte de software en
componentes (denominados Nivel 1, por ejemplo), de dividir dichos componentes en
subcomponentes (Nivel
2), y de dividir estos subcomponentes en sub-sub componentes
(Nivel 3), etc.

Capas: Dado que el alcance de una aplicacin software que debe medirse debe limitarse a
una sola capa de software, el proceso de definir el alcance podr requerir que el medidor
primero tenga que decidir cules son las capas de la arquitectura del software. Por lo tanto en
esta seccin vamos a definir y discutir capas y peer componentes de software tal y como
estos trminos son utilizados en el mtodo COSMIC






Ingeniera de Sistemas

12









Componentes Semejantes o Pares (Peer): Dos partes de software
son semejantes una a el otro si se encuentran en la misma capa. Los componentes semejantes
pueden ser identificados de acuerdo a la siguiente definicin y principios.


2.3) Identificar los usuarios funcionales


El tamao funcional vara con el usuario funcional: el tamao de un objeto puede variar
dependiendo de la funcionalidad que es de inters para diferentes tipos de usuarios del
objeto. En el caso del software, diferentes usuarios funcionales podrn exigir y utilizar
diferentes funcionalidades y, por tanto, los tamaos funcionales varan con la eleccin de
los usuarios funcionales.

Usuarios Funcionales: Un usuario se define, en la norma ISO/IEC 14143/1:2007,
como cualquier cosa que interacta con el software que se est midiendo. Esta definicin
es demasiado amplia para las necesidades del mtodo COSMIC. Para el mtodo COSMIC, la
eleccin de un usuario (o usuarios) se determina por los requisitos del usuario funcional
que deben medirse. Este (tipo de) usuario, es conocido como el usuario funcional.



2.4) Identificando el nivel de granularidad



La necesidad de un nivel de granularidad estndar: En las etapas iniciales de un
proyecto de desarrollo de software, los requisitos funcionales de los usuarios (FUR) se
especifican en alto nivel, es decir, en el esbozo, o en pocos detalles. A medida que el proyecto
progresa, los FUR, son refinados.

Aclaracin del nivel de granularidad: la ampliacin de la descripcin de software de
un nivel de granularidad superior a uno inferior implica revelar ms detalles pero sin
modificar su alcance. Este proceso no debe confundirse con cualquiera de los siguientes.

El nivel de granularidad estndar: Un nivel de granularidad de la descripcin de aplicacin
software en el que los usuarios funcionales:

Son humanos individuales o dispositivos de ingeniera o elementos de software (y no
grupos de estos).

Detectan ocurrencias nicas de eventos a los que la aplicacin software debe responder (y no
Ingeniera de Sistemas

13
cualquier nivel en el cual se han definido grupos de eventos).



2.5) Observaciones finales sobre la Fase de Estrategia de la de Medicin


Si se consideran cuidadosamente los cuatro elementos del proceso de
estrategia de medicin antes de empezar una medicin se debera
asegurar que el tamao resultante pueda ser interpretado correctamente.
Los cuatro elementos son los siguientes:



a) Establecer el propsito de la medicin
.
b) Definir el alcance global de la aplicacin software a medir y el alcance
de las partes a ser medidas por separado, teniendo en cuenta las
capas y los componentes semejantes de la arquitectura de software.
c) Establecer los usuarios funcionales de la aplicacin software medida.
d) Establecer el nivel de granularidad de los artefactos de software a
medir y cmo, si es necesario, llevar las medidas a al estndar de
nivel de granularidad de proceso funcional



3) Fase de Representacin





Ingeniera de Sistemas

14



3.1) Aplicacin del Modelo Genrico COSMIC de software

El Modelo Genrico COSMIC de Software se aplicar de forma separada
a cada parte de los requisitos funcionales de usuario para la cual se ha
definido un alcance de la medicin.

Aplicar el Modelo Genrico COSMIC de Software significa identificar el
conjunto de eventos desencadenadores detectados por cada (tipo de)
usuario funcional identificado en los FUR para, a continuacin, identificar
los correspondientes procesos funcionales, objetos de inters, grupos de
datos y los movimientos de datos que deben ser proporcionados para
responder a esos eventos.


3.2) Identificacin de los procesos funcionales.

Este paso consiste en identificar el conjunto de procesos funcionales de
la aplicacin software que se va a medir a partir de sus Requisitos
Funcionales de Usuario.



Proceso funcional.

Un proceso funcional es un componente elemental de un conjunto de
requisitos funcionales de usuario que constituyen una serie de
movimientos de datos nica, cohesiva e independientemente
ejecutable. Es desencadenada por un movimiento de datos (una
Entrada) desde un usuario funcional que informa al componente de
software que el usuario funcional ha identificado un evento
disparador. Se completa cuando ha ejecutado todo lo que se requiere
hacer en respuesta al evento desencadenante.


3.2.1 La aproximacin para identificar procesos funcionales.

La aproximacin para identificar procesos funcionales depende de
los artefactos de software que estn disponibles para el medidor, los
cuales dependen del momento del ciclo de vida del software cuando
se requiere la medida y de los mtodos de anlisis, diseo y
desarrollo del software en uso.

El consejo general ms importante es que es casi siempre til
intentar identificar los diferentes eventos en el mundo de los usuarios
funcionales a los que el software debe responder, ya que cada
evento da lugar normalmente a un (pero a veces a ms de uno)
proceso funcional. Los eventos pueden ser identificados a partir de
diagramas de estado y a partir de los diagramas de ciclo de vida la
de entidad, puesto que cada transicin a la que el software se debe
enfrentar se corresponde con un evento.
Ingeniera de Sistemas

15



3.2.2 Eventos disparadores y procesos funcionales en el mbito de
aplicaciones de negocio.

a) Eventos desencadenantes de una aplicacin de negocio on-line
normalmente ocurren en el mundo real de los usuarios funcionales
humanos de la aplicacin. El usuario humano comunica la incidencia
de un evento a un proceso funcional metiendo datos sobre el evento.

b) Algunas veces, para una aplicacin A podra haber una aplicacin
par B que necesite enviar datos a u obtener datos de la aplicacin A.
En este caso, si la aplicacin B desencadena un proceso funcional
cuando necesita enviar datos u obtener datos de la aplicacin A,
entonces la aplicacin B es un usuario funcional de la aplicacin A.


c) No hay diferencia en el principio para el anlisis de un proceso
funcional si se requiere un procesamiento on-line o un tratamiento
por lotes. El procesamiento durante la noche es una decisin de
puesta en marcha tcnica, y todo lo que se requiere hacer no ha
ocurrido hasta que el proceso durante la noche se haya completado.
Un flujo de procesado por lotes consiste en uno o ms procesos
funcionales, cada uno de los cuales debera ser analizado end-to-
end, independientemente de cualquier otro proceso funcional en el
mismo flujo. Cada proceso funcional tiene su propia Entrada
desencadenante que debe medirse.


d) Las seales peridicas de un reloj (ticks) pueden fsicamente
desencadenar un proceso funcional.


e) Un solo evento puede desencadenar uno o ms procesos
funcionales que se ejecuten independientemente.


f) Un solo proceso funcional puede ser desencadenado por ms de un
tipo de evento desencadenante.


3.3) Identificacin objetos de inters y grupos de datos.


Este paso consiste en identificar grupos de datos referenciados por el
software que se va a medir.

Para identificar los grupos de datos, especialmente en el dominio de
software de gestin, es habitualmente til identificar los objetos de inters
y probablemente tambin sus atributos. Los grupos de datos se mueven a
movimientos de datos, los cuales sern identificados en el captulo
siguiente.

Objeto de inters
Cualquier cosa que sea identificada desde el punto de vista de los
requisitos del usuario funcional. Puede ser cualquier cosa fsica,
como tambin cualquier objeto conceptual o parte de un objeto
conceptual en el mundo del usuario funcional sobre el que al
Ingeniera de Sistemas

16
software se le.
Ingeniera de Sistemas

17



Grupo de datos
Un grupo de datos es un conjunto nico, no vaco, no ordenado y no
redundante de atributos de datos donde cada atributo de datos
incluido describe un aspecto complementario del mismo objeto de
inters.

Almacn persistente
Un almacn persistente es un almacn que permite a un proceso
funcional almacenar un grupo de datos ms all de la vida del
proceso funcional y/o del cual un proceso funcional puede recuperar
un grupo de datos almacenado por otro proceso funcional, o
almacenado por una ocurrencia anterior del mismo proceso
funcional, o almacenado por otro proceso.


3.3.1 Sobre la materializacin de un grupo de datos.

En la prctica, la materializacin de un grupo de datos puede tomar
muchas formas, por ejemplo:

a. Como una estructura fsica grabada en un dispositivo de
almacenamiento continuo (archivo, tabla de base de datos,
memoria ROM, etc.)

b. Como una estructura fsica en la memoria voltil del ordenador
(estructura de datos asignada dinmicamente o a travs un
bloque pre-asignado de espacio de memoria).

c. Como la presentacin agrupada de atributos de datos
relacionados funcionalmente en un dispositivo input/output
(pantalla de visualizacin, informe impreso, panel de control de
visualizacin, etc.)

d. Como un mensaje transmitido entre un dispositivo y un
ordenador, o sobre una red, etc.

3.3.2 Sobre la identificacin de objetos de inters y grupos de
datos.

Las definiciones y los principios de los objetos de inters y de los
grupos de datos son intencionalmente amplios con el objetivo de
que se puedan aplicar al rango ms amplio posible de software.
Esta cualidad hace que algunas veces resulte difcil de aplicar la
definicin y los principios cuando se mide una parte especfica del
software. Por tanto, los casos siguientes y los ejemplos se han
diseado para ayudar en la aplicacin de los principios a casos
especficos.
Al enfrentarnos a la necesidad de analizar un grupo de atributos de
datos que son movidos dentro o fuera de un proceso funcional o que
son movidos por un proceso funcional a o desde un almacn
persistente, es de una importancia crtica decidir si todos los
atributos comunican datos sobre un nico objeto de inters, ya que
es ste ltimo el que determina el nmero de grupos de datos
Ingeniera de Sistemas

18



3.4) Identificacin de los atributos de datos (opcional).


Esta seccin discute la identificacin de atributos de datos referenciados
por la parte del software que se va a medir. En esta versin del mtodo
de medida no es obligatorio identificar los atributos de los datos. Sin
embargo, puede ser de ayuda analizar e identificar los atributos de datos
en el proceso de distinguir los grupos de datos y los objetos de inters.
Los atributos de datos pueden tambin ser identificados si una sub-
unidad de la medida del tamao es requerida.

Atributo de datos

Un atributo de datos es la pieza ms pequea de informacin, dentro
de un grupo de datos identificados, que tiene un significado desde la
perspectiva de los requisitos funcionales del software.

Ejemplo 1: Atributos de datos en el contexto del dominio de
aplicaciones de gestin como por ejemplo elementos de datos
registrados en el diccionario de datos y atributos de datos que
aparecen en un modelo de datos conceptual o lgico.

Ejemplo 2: Atributos de datos en el contexto de las aplicaciones a
tiempo real del software como por ejemplo atributos de datos de una
seal recibida de un sensor y atributos de datos de un mensaje en
transmisin.

3.4.1 Sobre la asociacin de atributos de datos y grupos de datos


En teora, un grupo de datos puede contener solo un atributo de
datos si esto es suficiente, desde la perspectiva de los requisitos
funcionales de usuario, para describir el objeto de inters. En la
prctica, dichos casos ocurren normalmente en las aplicaciones a
tiempo real del software (por ejemplo: la Entrada que transmite el tick
de un reloj a tiempo real); stos son menos comunes en el software
de gestin.



4) Fase de Medicin

4.1) Identificar los movimientos de datos:

Identificar los movimientos de datos (Entrada, salida, lectura y escritura)
de cada proceso funcional.

Hay cuatro tipos de movimiento de datos: Entrada, Salida, Lectura y
Escritura
Ingeniera de Sistemas

19































1) Entradas (E): movimiento de datos que mueve un grupo de datos desde un
usuario funcional a travs de la frontera hacia el proceso funcional donde se
necesitan.

Principios:

a) Una entrada deber mover un nico grupo de datos describiendo un
solo objeto de inters de un usuario funcional a travs de la frontera y
dentro de un proceso funcional del que la entrada forma parte. Si la
entrada a un proceso funcional comprende ms de un grupo de datos,
se identifica una entrada por cada grupo de datos que entra.

b) Una entrada no deber salir de la frontera, ni leer ni escribir datos.

c) Donde un proceso funcional necesite obtener datos de un usuario
funcional pero ms tarde no necesite que se le diga que datos enviar o
el usuario funcional es incapaz de reaccionar a ningn mensaje
entrante, identificar una Entrada al proceso funcional para obtener los
datos. Cualquier mensaje del proceso funcional al usuario funcional
buscando recuperar los datos no debe ser contado como una Salida en
estos casos.

2) Salidas (X): movimiento de datos que mueve un grupo de datos desde un
proceso funcional a travs de la frontera haca el usuario funcional que los
requiere.

Principios:

a) Una salida deber mover un nico grupo de datos describiendo un solo
objeto de inters desde el proceso funcional del que la salida forma
parte a cruzando la frontera hacia un usuario funcional. Si la salida de un
Ingeniera de Sistemas

20
proceso funcional comprende ms de un grupo de datos, hay que identificar
una salida para cada grupo de datos que sale.

b) Una salida no introducir datos a travs de la frontera, ni lecturas, ni
escrituras

3) Lectura (R): movimiento de un grupo de datos desde un almacn
permanente dentro del alcance del proceso funcional que los requiere.

Principios:

a) Una lectura deber mover un nico grupo de datos describiendo un solo
objeto de inters del almacn permanente a un proceso funcional del
cual la lectura forma parte. Si el proceso funcional debe recuperar ms
de un grupo de datos del almacn, identificar una Lectura para cada
grupo de datos que es recuperado.

b) Una lectura no recibir ni sacar datos a travs de la frontera ni
escribir datos.

c) Durante un proceso funcional, el movimiento o manipulacin de
constantes o variables que son internas del proceso funcional y que
slo se pueden cambiar por un programador, o mediante los resultados
intermedios en un clculo, o de los datos almacenados en un proceso
funcional slo resultantes de la aplicacin, ms que de los requisitos
funcionales, no se considerar como una Lectura.

4) Escritura (W): movimiento a un almacn permanente de un grupo de datos
que se encuentra dentro de un proceso funcional.

Principios:

a) Una escritura deber mover un nico grupo de datos describiendo un
solo objeto de inters del proceso funcional del que la Escritura forma
parte hacia un almacn permanente. Si el proceso funcional debe pasar
ms de un grupo de datos al almacn permanente, identificar una
Escritura por cada grupo de datos que se mueve a un almacn
permanente.

b) Una escritura no recibir ni sacar datos de la frontera, ni leer los
datos.

c) Un requisito para borrar un grupo de datos de un almacn permanente
se medir como una sola Escritura.

d) Durante un proceso funcional, el movimiento o manipulacin de los
datos que no persista cuando el proceso funcional sea completado, o la
actualizacin de variables que son internas del proceso funcional o la
produccin de resultados intermedios en un clculo no se considerarn
como una Escritura.
Ingeniera de Sistemas

21



4.2) Aplicando la funcin de medicin

Medicin funcional COSMIC: funcin matemtica que asigna un valor a
su argumento basado en el estndar de medicin COSMIC. El
argumento de la medicin funcional COSMIC es el movimiento de
datos.

Medida estndar COSMIC: La medicin estndar de COSMIC, 1 PPC
(Punto de Funcin COSMIC) se define como el tamao de un
movimiento de datos.


4.3) Agregar resultados de medicin

Sumar los resultados de la medida funcional, tal como se aplica a todos
los movimientos de datos, en un nico valor de tamao funcional

Reglas:

a) Para cualquier proceso funcional, el tamao funcional de cada
movimiento de datos individual debe ser agregado en un nico valor
de tamao funcional en unidades de CFP para luego sumar todos
juntos.










b) Para cualquier proceso funcional, el tamao funcional de los cambios
en requisitos funcionales de usuario se sumar al tamao de
movimientos de datos que han sido aadidos, modificados o
eliminados en proceso funcional para dar un tamao del cambio en
unidades de CFP, segn la siguiente frmula.






4.4) Modificando funcionalidades

Cualquier movimiento de datos de un determinado tipo (E, X, R y W)
incluye dos tipos de funcionalidad: se mueve un solo grupo de datos y
tiene algunas manipulaciones de datos. Por lo tanto para la medicin un
movimiento de datos se considera que es modificado funcionalmente si:

El Grupo de datos es reubicado y/o
Est asociado a una manipulacin de datos

Un grupo de datos es modificado si:
Se aaden nuevos atributos a este grupo de datos y/o

Tamao (proceso funcional
i
) = tam(Entradass
i
) +tam(Salidas
i
) + tam(Lecturass
i
) +size(Escrituras
i
)


Tamao (Cambio (procedso funcional
i
)) = tam (movimientos datos aadidos
i
) + tam
(movimientos datos modificados
i
)
+ tam (movimientos datos eliminados
i
)

Ingeniera de Sistemas

22
Los atributos son retirados de los grupos de datos y/o uno o ms
atributos existentes son modificados, por ejemplo, en sentido o formato.