Spanish - COSMIC - v3-0-1 PDF

El Método COSMIC del Tamaño Funcional del Software
Versión 3.0.1
Manual de Medición
(Guía COSMIC de implementación de ISO/IEC 19761: 2003)
Mayo de 2009
Agradecimientos
1
Equipo Principal de Autores de la Versión 2.0 de COSMIC (por orden alfabético)
Alain Abran, École de technologie supérieure – Universidad de Québec,
Jean-Marc Desharnais, Software Engineering Laboratory in Applied Metrics - SELAM,
Serge Oligny, Bell Canadá,
Denis St-Pierre, DSA Consulting Inc.,
Charles Symons, Software Measurement Services Ltd.
Revisores de la Versión 2.0 1998/1999 (por orden alfabético)
Moritsugu Araki, JECS Systems Thomas Fetcke, Germany Patrice Nolin, Hydro Québec,
Research, Japan Canada
Fred Bootsma, Nortel, Canada Eric Foltin, University of Magdeburg, Marie O’Neill, Software Management
Germany Methods, Ireland
Denis Bourdeau, Bell Canada, Anna Franco, CRSSM, Canada Jolijn Onvlee, The Netherlands *
Canada
Pierre Bourque, , ÉCole de Paul Goodman, Software Laura Primera, UQAM, Canada
Technologie supérieure, Canada Measurement Services,United
Kingdom
Gunter Guerhen, Bürhen & Partner, Nihal Kececi, University of Maryland, Paul Radford, Charismatek, Australia
Germany United States
Sylvain Clermont, Hydro Québec, Robyn Lawrie, Australia Eberhard Rudolph, Germany
Canada
David Déry, CGI, Canada Ghislain Lévesque, UQAM, Canada Grant Rule, Software Measurement
Services, United Kingdom*
Gilles Desoblins, France Roberto Meli, Data Processing Richard Stutzke, Science
Organization, Italy Applications Int’l Corporation, United
States
Martin D’Souza, Total Metrics, Pam Morris, Total Metrics, Australia* Ilionar Sylva, UQAM, Canada
Australia
Reiner Dumke, University of Risto Nevalainen, Software Vinh T. Ho, UQAM, Vietnam
Magdeburg, Germany Technology Transfer Finland,
Finland *
Peter Fagg, United Kingdom Jin Ng, Hmaster, Australia
* Los miembros fundadores del Equipo Principal de COSMIC, junto con los autores de COSMIC-FFP
1
La versión 2.0 fue la primera versión públicamente disponible del método COSMIC-FFP, tal como fue conocida
Manual de Medición, Método COSMIC Versión 3.0.1. Copyright © 2009. 2

All rights reserved. The Common Software Measurement International Consortium (COSMIC)
Revisores de la Versión 3.0 2006/07 (por orden alfabético)
Alain Abran, École de Technologie Jean-Marc Desharnais, Software Arlan Lesterhuis*, Sogeti, The
Supérieure, Université du Québec, Engineering Lab in Applied Metrics – Netherlands
Canada SELAM, Canada
Bernard Londeix, Telmaco, United Roberto Meli, Data Processing Pam Morris, Total Metrics, Australia
Kingdom Organization, Italy
Serge Oligny, Bell Canada Marie O’Neill, Software Management Tony Rollo, Software Measurement
Methods, Ireland Services, United Kingdom
Grant Rule, Software Measurement Luca Santillo, Agile Metrics, Italy Charles Symons*, United Kingdom
Services, United Kingdom
Hannu Toivonen, Nokia Siemens Frank Vogelezang, Sogeti, The

Networks, Finland Netherlands
* Editores de las versiones 3.0 y 3.0.1 del método COSMIC
Equipo de traducción de la Versión 3.0.1 de COSMIC al Español
Juan J. Cuadrado-Gallego, EVALÚA Cristina Albarrán, EVALÚA Software Alfonso Gónzalez, EVALÚA
Software Measurement Consulting, Measurement Consulting, Spain Software Measurement Consulting,
Spain. jjcg@cosmicon.com Spain
Ivan Pinedo, EVALÚA Software Isaac Sánchez, EVALÚA Software Roi Vázquez, EVALÚA Software
Measurement Consulting, Spain Measurement Consulting, Spain Measurement Consulting, Spain.
La traducción de la Versión 3.0.1 de COSMIC ha sido realizada bajo los auspicios de AEMES,
Spanish Software Measurement Association
Copyright 2009. Todos los derechos quedan reservados. El Común Consorcio Internacional de la
Medida del Software, (COSMIC). El permiso para copiar todo o una parte de este material se
concederá siempre que las copias no se hagan ni se distribuyan comercialmente y que el título de la
publicación, su número de versión, y su fecha se citen y se notifique que la copia tiene el permiso del
Common Software Measurement International Consortium (COSMIC). Para la copia de otra manera
se requiere un permiso específico.
Una versión de dominio público del Manual de Medición COSMIC y otros informes técnicos,
incluyendo traducciones a otros idiomas se pueden encontrar en la Web en
www.gelog.etsmtl.ca/cosmic-ffp

Control de versiones
La tabla siguiente muestra la historia de las versiones de este documento
FECHA REVISORES Modificaciones / Añadidos

31-03-99 Serge Oligny Primer borrador, emitió los comentarios de los revisores
31-07-99 Véase Agradecimientos Revisado, incluyendo comentarios de los revisores
2
06-10-99 Véase Agradecimientos Revisado, incluyendo comentarios del IWSM ’99 workshop
29-10-99 Equipo Principal de Revisado, comentarios finales antes de la publicación del
COSMIC “ensayo práctico” de la versión 2.0.
01-05-01 Equipo Principal de Revisado conforme a la norma ISO/IEC 14143-1: 1998 + las
COSMIC aclaraciones sobre las normas de medición de la versión 2.1.
31-01-03 Comité de Prácticas de Revisado conforme a la norma ISO/IEC FDIS 19761: 2002 +
Medición COSMIC las aclaraciones sobre las normas de medición de la versión
2.2
01-09-07 Comité de Prácticas de Revisado para más aclaraciones y añadidos de las normas de
Medición COSMIC medición de la versión 3.0, particularmente en el área de la
fase de la estrategia de medición. El nombre del método fue
cambiado de ‘método COSMIC-FFP’ al de ‘método COSMIC’.
En la actualización a la v3.0 de la v2.2, se separaron partes del
‘Manual de Medición’ v2.2 en otros documentos – véase el
prólogo a continuación y el Apéndice D
01-05-09 Comité de Prácticas de Revisada la versión 3.0 a v3.0.1 para hacer mejoras en la
Medición COSMIC redacción y aclaraciones menores, y para distinguir ejemplos
más claramente. Esta versión también incorpora los cambios
propuestos en los Boletines de Actualización del Método
(MUB), 3, 4 y 5. Véase el Apéndice D para obtener más
detalles sobre estos cambios.
2
Procedimientos del Taller Internacional de la Medición del Software IWSM ’99, Lac Supérieur, Québec, Canadá, 8-10 de
Septiembre de 1999. Véase para más detalle http://www.gelog.etsmtl.ca/iwsm99/index2.html.

Prólogo
El propósito del método COSMIC es proporcionar un método estandarizado de medición del tamaño
funcional de software para los dominios funcionales comúnmente denominados como Software de
Aplicaciones de Negocio (ó Management Information Systems, MIS) y Software de Tiempo Real.
El método COSMIC fue aceptado por el ISO/IEC JTC1 SC7 en diciembre de 2002 como el Estándar
Internacional ISO/IEC 19761 “Ingeniería del Software - COSMIC-FFP - Método de Medición de
Tamaño Funcional” (en lo sucesivo en este documento se referirá el mismo como ISO/IEC 19761).
Para mayor claridad, ISO/IEC 19761 contiene las definiciones de las normativas fundamentales y de
las reglas del método. El propósito del Manual de Medición es no sólo proporcionar estas normas y
definiciones, sino también proporcionar una explicación más detallada y muchos más ejemplos a fin
de ayudar a los medidores a comprender plenamente y poder aplicar el método. Sin embargo, a
medida que se ha ido adquiriendo más y más experiencia con el método, se ha encontrado valioso
añadir reglas y ejemplos para afinar las definiciones de algunos de los conceptos subyacentes. El
Consorcio Común Internacional de Medición de Software (COSMIC) prevé que estas adiciones y
mejoras se presentarán a la ISO para su inclusión en la norma ISO/IEC 19761 en la fecha prevista
para su revisión en 2007/08.
Este manual de medición es uno de los cuatro documentos COSMIC que definen la versión 3.0 del
método. Los otros tres son:
• Descripción de la documentación y Glosario de términos (El Glosario define todos los términos
que son comunes a todos los documentos COSMIC. Este documento describe también que se
dispone de otros documentos de apoyo tales como casos de estudio y directrices de aplicación en
dominios específicos)
• Descripción del Método
• Temas Avanzados y Relacionados (Este documento tratará en más detalle las tareas que
permitan garantizar la comparación de las mediciones de tamaño funcional e incluirá capítulos
sobre aproximación temprana o rápida de medición y convertibilidad de las mediciones, los cuales
aparecieron anteriormente en la versión 2.2 del Manual de Medición.)
A los lectores principiantes para quienes sea nueva la medición de tamaño funcional (FSM) o que
están familiarizados con otros métodos FSM se les recomienda encarecidamente que lean el
documento “Descripción del Método” antes de leer este manual de medición.
Los principales cambios de esta versión 3.0 del Método COSMIC

El cambio en la designación de la versión del método COSMIC de 2.2 a 3.0 indica que esta versión
representa un avance significativo sobre la versión anterior. Al elaborar esta versión 3.0 del Método
COSMIC, a partir de la versión anterior que se define en el Manual de Medición de la versión 2.2, los
principales cambios introducidos han sido los siguientes:
• Con el fin de hacer la documentación del Método COSMIC más fácil de aplicar, la versión 3.0 del
método se define ahora en cuatro documentos.
• Se han incorporado las propuestas de los dos Boletines de Actualización del Método que fueron
publicados desde la publicación de la última versión 2.2 de la Medición Manual. Estos son MUB 1
“Propuesta de Mejoras para la Definición y Características de una Capa de Software” y MUB 2
“Propuesta de Mejora a la definición de un objeto de interés”. (La versión 3.0.1 incorpora tres
Boletines de Actualización más – ver Apéndice D.)
• Ha sido definida por separado una fase de “Estrategia de Medición” como la primera fase del
proceso de medición. La fase de estrategia ha sido también mejorada introduciendo una guía
para considerar el concepto de “Nivel de Granularidad” de las Necesidades Funcionales de los
Usuarios del software que será medido, y así ayudar a garantizar la comparación de las
mediciones a través de diferentes aplicaciones software.

• La experiencia ha demostrado que los puntos de vista de los conceptos del Usuario Final y del
Desarrollador, que fueron introducidos en la medición manual en la versión 2.2, pueden ser
reemplazados por el concepto más simple de Usuario Funcional. Este último puede ser
simplemente definido como el remitente o destinatario de los datos en los Requerimientos
Funcionales del Usuario (FUR) del software que se desea medir. Todas las mediciones de
tamaño en una aplicación software se definen entonces como la funcionalidad entregada a los
usuarios de la funcionalidad del software tal como es identificada en sus FUR.
• El nombre de la unidad de medida del método se ha cambiado de Unidad de Tamaño Funcional
COSMIC (abreviado como Cfsu) a Punto de Función COSMIC (abreviado como CFP). Este
cambio se ha hecho para facilitar la lectura y pronunciación, y para proporcionar al método en
conformidad con otros métodos de “Puntos de Función”. Y para obtener una mayor simplificación,
el nombre del método se ha cambiado de COSMIC-FFP a COSMIC.
• El Glosario ha sido actualizado y ampliado para mejorar la legibilidad y se ha trasladado al nuevo
documento de “Descripción Documental y Glosario de Términos”.
• Algunos materiales, en particular en los conceptos de análisis de datos se han eliminado. En la
actualidad se incluyen en la “Guía de Medición de Software de Gestión utilizando COSMIC”, ya
que es muy específica para un dominio y no es específica para el método COSMIC.
• Se han realizado muchas mejoras y añadidos editoriales para mejorar la consistencia de la
terminología y para mejorar la comprensión. Entre ellas, se ha realizado una distinción más
consistente entre los “principios” y las “reglas” del método mediante la adopción de una
convención procedente del mundo de la contabilidad que dice que las “reglas existen para ayudar
a aplicar las definiciones y los principios”. Ambos, principios y reglas deben ser considerados
como obligatorios. De ahí que, muchos ejemplos se hayan trasladado de las definiciones de
principios y normas al cuerpo principal del texto.
Todos estos cambios se resumen en el Apéndice D.
Los lectores familiarizados con la versión 2.2 del Manual de Medición observarán que el mayor
número de cambios en esta versión 3.0 se encuentra en la recién separada fase de “Estrategia de
Medición”.
Consecuencias principales de los cambios en mediciones existentes
Los principios originales del método COSMIC han permanecido sin cambios desde su primera
publicación en el primer borrador del Manual de Medición en 1999, a pesar de los refinamientos y
adiciones necesarias para producir la norma internacional y para producir las versiones 2.1, 2.2, 3.0 y
esta última versión 3.0.1 del Manual de Medición.
Los tamaños funcionales medidos de acuerdo a los principios y normas de las versiones 3.0 y 3.0.1
del Manual de Medición pueden variar de tamaño utilizando las versiones anteriores sólo porque las
nuevas normas tienen la intención de ser más precisas. Por lo tanto disponen un margen menor de
discrecionalidad en materia de interpretación personal de las normas que era posible con versiones
anteriores. Los cambios en el ámbito de la Estrategia de Medición y el cambio de nombre de la
unidad de medida dan lugar a diferencias triviales en las reglas para la presentación de mediciones
en comparación con versiones anteriores.
Explicación de los principales cambios de la versión 2.2 a la versión 3.0 del Manual de
Medición
En primer lugar debemos destacar que la unidad de medida COSMIC, el Cfsu (ahora rebautizado con
el nombre de CFP), no ha cambiado desde que se introdujo en la primera versión pública del Manual
de Medición COSMIC-FFP en el año 1999. Este es el equivalente COSMIC de, por ejemplo, una
unidad de medida estándar como el metro. Pero el tamaño funcional de una aplicación software
puede medirse de muchas maneras, y es a veces un problema, para cualquier Método de Medición
de Tamaño Funcional (Functional Size Method, FSM), responder a la pregunta de ¿qué tamaño
debemos medir?

El primer problema es que sabemos que cualquier aplicación software proporciona funcionalidad para
los distintos tipos de Usuarios, donde un usuario se define en la terminología del estándar ISO/IEC
14143/1 (“Principios de FSM”) esencialmente como cualquier cosa que interactúa con el software que
se está midiendo. De ello se deduce que el tamaño funcional de una aplicación software depende de
a quién o a qué se define como su usuario(s).
Permítanos considerar como ejemplo el software de un teléfono móvil. Los usuarios podrían ser un
humano que presiona los botones, los dispositivos de hardware (por ejemplo, la pantalla, teclado,
etc.) que interactúan con la aplicación, o el sistema operativo sobre el que funciona el software o,
incluso separados por aplicaciones de software que interactúan con la aplicación que se está
midiendo. Los cuatro tipos de usuarios exigen diferentes funciones (de ahí que el tamaño funcional
difiera en función de a quién o a qué se define como el usuario). Entonces, ¿Cómo, si se nos da un
tamaño funcional, vamos a saber qué o quién fue el usuario(s)?, es decir, ¿Qué funcionalidad se
midió?
Fue esta cuestión la que inicialmente llevó al Comité de Prácticas de Medición COSMIC
(Measurement Practices Committee, MPC) a introducir en la versión 2.2 del Manual de Medición, los
Puntos de Vista de Medición del “Usuario Final” y del “Desarrollador”. Sin embargo, la experiencia ha
demostrado que estas definiciones, especialmente la de los Punto de Vista de la Medición del
“Desarrollador”, no son lo suficientemente generales como para ayudar a definir todas las
necesidades de medición. El MPC ha llegado a la conclusión de que la manera más correcta y más
general de enfocarlo es definir el concepto de “Usuario Funcional” y que los cambios en el tamaño
funcional dependan de qué o quién es definido como el usuario funcional. La identificación del usuario
funcional depende de la finalidad de la medición y el usuario funcional debería ser normalmente
identificable a partir de los Requisitos Funcionales de Usuario (Functional User Requirements, FUR)
del software que se desea medir. Por lo tanto ya no se necesitará más la idea de definir un “Punto de
vista de la Medición” específico.
El segundo problema es que sabemos que los FUR evolucionan a medida que el proyecto avanza y,
dependiendo de cómo se mida el tamaño, su tamaño puede parecer que crece. La primera versión
del FUR de una nueva aplicación software puede ser especificado a un “alto nivel”. A medida que el
proyecto avanza y los requisitos son elaborados con mayor detalle, los FUR se especifican con mayor
detalle, o a un “menor nivel” y su tamaño puede parecer que aumenta. Distinguimos estos diferentes
niveles de detalle como “niveles de granularidad”.
Por lo tanto, el problema que tiene que ser abordado ahora es ¿cómo podemos estar seguros de que
dos mediciones se han hecho en el mismo nivel de granularidad? Las versiones 3.0 y 3.0.1 del
Manual de Medición ofrecen recomendaciones sobre este aspecto, que es especialmente importante
cuando los tamaños son medidos a principios de la vida de un proyecto cuando los FUR están en
plena evolución. Este aspecto se vuelve crítico cuando los tamaños son utilizados para mediciones
del funcionamiento que deben compararse a partir de diferentes fuentes, como en ejercicios de
evaluación comparativa.
Es importante destacar que estos nuevos conceptos de “usuario funcional” y “nivel de granularidad” y
los procesos asociados para determinarlos que se han introducido en la “Estrategia de Medición” no
tienen por qué ser únicos para el método COSMIC. Son aplicables a todos los métodos de medición
del Tamaño Funcional de Software (FSM). Debido a que el método COSMIC se basa en sólidos
principios de ingeniería de software y es aplicable a una gama más amplia de dominios de software
que la “1ª generación” de Métodos FSM, ha sido reconocido el problema de definir adecuadamente
¿qué tamaño deberíamos medir? y se ha encontrado una solución.
La mayoría de medidores que utilizan COSMIC con el propósito de medir el rendimiento (por ejemplo,
para la estimación, evaluación comparativa, etc.), no tendrán que perder tiempo en la identificación de
los usuarios funcionales o sobre el nivel de granularidad con el que deben medir, ya que será
evidente. Sin embargo, para las mediciones donde las opciones pueden no ser tan evidentes, los
nuevos materiales de la “Fase de Estrategia de Medición” del Manual de Medición y el capítulo
relativo a garantizar la posibilidad de comparación de las mediciones de tamaño en el documento
“Temas Avanzados y Relacionados”, examina con mayor profundidad los factores a considerar.

El Comité de Prácticas de Medición COSMIC
Mayo 2009

Tabla de Contenidos
1 INTRODUCCIÓN .............................................................................................................................11
1.1 Aplicabilidad del método COSMIC .............................................................................................. 11
1.1.1 Dominios de aplicación ..................................................................................................... 11
1.1.2 Dominio no aplicable ........................................................................................................ 11
1.1.3 Limitaciones de los factores que contribuyen a tamaño funcional .................................. 11
1.1.4 Limitaciones en la medición de aplicaciones software muy pequeñas ........................... 12
1.2 Requisitos Funcionales de Usuarios ........................................................................................... 12
1.2.1 Extracción de los requisitos funcionales de usuario a partir de los artefactos del software
en la práctica ..................................................................................................................... 12
1.2.2 Deducción de los requisitos funcionales de usuario a partir de software instalado ........ 13
1.2.3 Extracción o deducción de los requisitos funcionales de usuario a partir de artefactos
software ............................................................................................................................. 13
1.3 Modelo COSMIC de Contexto de Software ................................................................................ 14
1.4 Modelo Genérico del Software .................................................................................................... 14
1.5 El Proceso de Medición COSMIC ............................................................................................... 15
2 FASE DE ESTRATEGIA DE MEDICIÓN ........................................................................................17

2.1 Definir el propósito de la Medición ............................................................................................. 18
2.1.1 El propósito de una medición determina el tamaño que será medido............................. 18
2.1.2 La importancia del propósito ............................................................................................. 19
2.2 Definir el alcance de la medición ..................................................................................................... 19
2.2.1 El alcance de una medición depende de la finalidad........................................................ 20
2.2.2 Tipos genéricos de alcance .............................................................................................. 21
2.2.3 Niveles de descomposición .............................................................................................. 21
2.2.4 Capas ................................................................................................................................ 22
2.2.5 Componentes Semejantes o Pares (Peer) ....................................................................... 24
2.3 Identificar los usuarios funcionales ............................................................................................. 26
2.3.1 El tamaño funcional varía con el usuario funcional .......................................................... 26
2.3.2 Usuarios Funcionales ....................................................................................................... 26
2.4 Identificando el nivel de granularidad.......................................................................................... 28
2.4.1 La necesidad de un nivel de granularidad estándar ......................................................... 28
2.4.2 Aclaración del nivel de granularidad ................................................................................. 29
2.4.3 El nivel de granularidad estándar ..................................................................................... 29
2.5 Observaciones finales sobre la Fase de Estrategia de la de Medición ...................................... 32
3 FASE DE REPRESENTACIÓN .......................................................................................................34

3.1 Aplicación del Modelo Genérico COSMIC de software .............................................................. 35
3.2 Identificación de los procesos funcionales .................................................................................. 36
3.2.1 Definiciones ....................................................................................................................... 36
3.2.2 La aproximación para identificar procesos funcionales .................................................... 37
3.2.3 Eventos disparadores y procesos funcionales en el ámbito de aplicaciones de negocio 38
3.2.4 Ejemplos en el dominio de aplicaciones en tiempo real. .................................................. 39
3.2.5 Más sobre procesos funcionales separados .................................................................... 40
3.2.6 El proceso funcional de componentes semejantes .......................................................... 40
3.3 Identificación objetos de interés y grupos de datos .................................................................... 41
3.3.1 Definiciones y principios ................................................................................................... 41
3.3.2 Sobre la materialización de un grupo de datos ................................................................ 42
3.3.3 Sobre la identificación de objetos de interés y grupos de datos ...................................... 42
3.3.4 Grupos de datos o datos que son candidatos a movimientos de datos. .......................... 43

3.3.5 El usuario funcional como objeto de interés ..................................................................... 44
3.4 Identificación de los atributos de datos (opcional) ...................................................................... 44
3.4.1 Definición .......................................................................................................................... 44
3.4.2 Sobre la asociación de atributos de datos y grupos de datos .......................................... 44
4 FASE DE MEDICIÓN ......................................................................................................................45

4.1. Identificar los movimientos de datos ........................................................................................... 45
4.1.1 Definición de los tipos de movimientos de datos .............................................................. 46
4.1.2. Identificación de entradas (E) ........................................................................................... 47
4.1.3. Identificación de salidas (X) .............................................................................................. 48
4.1.4. Identificación de Lecturas (R) ........................................................................................... 49
4.1.5. Identificando escrituras (W) .............................................................................................. 49
4.1.6. Sobre las manipulaciones de datos asociadas con los movimientos de datos ................ 50
4.1.7 Movimientos de datos únicos y posibles excepciones ..................................................... 51
4.1.8. Cuando un proceso funcional mueve datos para o desde un fichero de almacenamiento.
53
4.1.9 Cuando un proceso funcional requiere datos de un usuario funcional............................. 56
4.1.10 Comandos de control ........................................................................................................ 57
4.2. Aplicando la función de medición................................................................................................ 58
4.3. Agregar resultados de medición ................................................................................................. 58
4.3.1 Reglas generales de agregación ...................................................................................... 58
4.3.2. Más sobre la agregación del tamaño funcional ................................................................ 59
4.4 Más en la medición del tamaño de los cambios de software...................................................... 60
4.4.1. Modificando funcionalidades............................................................................................. 61
4.4.2 Tamaño del software funcionalmente modificado ........................................................... 62
4.5. Extensiones del método de medición COSMIC. ............................................................................ 62
4.5.1. Introducción....................................................................................................................... 62
4.5.2. Extensiones locales con algoritmos complejos. ............................................................... 62
4.5.3. Extensión Local con sub-unidades de medida ................................................................. 63
5 INFORME DE MEDIDAS .................................................................................................................64

5.1 Etiquetado ....................................................................................................................................... 64
5.2 Archivando los resultados de medida COSMIC .............................................................................. 65
APÉNDICE A – DOCUMENTANDO LA MEDICIÓN COSMIC - FFP ...................................................66
APÉNDICE B – RESUMEN DE LOS PRINCIPIOS DEL MÉTODO COSMIC ......................................67
APÉNCIDE C – RESUMEN DE LAS REGLAS DEL METODO COSMIC ............................................71
APÉNDICE D – HISTORIA DEL MÉTODO COSMIC ...........................................................................77

De la versión 2.2 a la versión 3.0 .......................................................................................................... 77
De la versión 3.0 a la versión 3.0.1 ....................................................................................................... 82
APÉNDICE E – PROCEDIMIENTO DE SOLICITUD DE CAMBIOS Y COMENTARIOS .....................84

1
INTRODUCCIÓN
1.1 Aplicabilidad del método COSMIC
1.1.1 Dominios de aplicación
El método de medición del tamaño funcional COSMIC está concebido para ser aplicable a la
funcionalidad del software de los siguientes dominios:
• Aplicaciones Software de Gestión, las cuales son las típicamente utilizadas para dar soporte a la
administración de negocios, tales como banca, seguros, contabilidad, personal, compras,
distribución o fabricación. Este software esta a menudo caracterizado como "rico en datos", ya
que está centrado principalmente en la necesidad de gestionar grandes cantidades de datos
acerca de aspectos del mundo real.
• Software en tiempo real, cuya tarea es mantener o controlar acontecimientos que están
sucediendo en el mundo real. Algunos ejemplos serían el software para centrales telefónicas y de
intercambio de mensajes, el software incluido en dispositivos para el control de máquinas tales
como los electrodomésticos, ascensores, motores de automóviles y aeronaves, para el control de
procesos y la adquisición automática de datos, y software de los sistemas operativos de los
ordenadores.
• Híbridos de lo anterior, como por ejemplo los sistemas de reservas en tiempo real de compañías
aéreas u hoteles.
1.1.2 Dominio no aplicable
El método de medición COSMIC aún no ha sido diseñado para tener en cuenta la funcionalidad del
software matemáticamente intensivo, esto es, software caracterizado por algoritmos matemáticos
complejos o otra reglas complejas especializadas, como por ejemplo sistemas expertos, software de
simulación, software de auto-aprendizaje, sistemas de predicción meteorológica, etc., o de procesado
continuo de variables tales como sonidos de audio o imágenes de vídeo, tales como, por ejemplo,
software para juegos de ordenador, instrumentos musicales, etc.
Para los programas con dicha funcionalidad es posible definir extensiones locales al método COSMIC
de medición. El manual de medición explica en qué contextos tales extensiones locales se deben
utilizar y proporciona ejemplos de una extensión local. Cuando se usan, estas extensiones locales
deben ser reportadas de acuerdo a los convenios presentados en el capítulo reportado de mediciones
de este Manual de Medición.
1.1.3 Limitaciones de los factores que contribuyen a tamaño funcional
Además, dentro de su dominio de aplicabilidad, el método de medición de tamaño funcional COSMIC

no intenta medir todos los posibles aspectos de la funcionalidad que podrían considerarse para
contribuir al “tamaño” del software. Por ejemplo, ni la influencia de la “complejidad”
(independientemente de su definición), ni la influencia del número de atributos de datos por el
movimiento de datos en el tamaño funcional del software son utilizados por este método de medición
(para más sobre este último, véase el capítulo de la Fase de Representación del Manual de
Medición). Como se describe en la sección 1.1.2, si así lo desea, por ejemplo, tales aspectos pueden
ser tenidos en cuenta a través de una extensión local al método de medición COSMIC.

1.1.4 Limitaciones en la medición de aplicaciones software muy pequeñas
Todos los métodos de medición funcional están basados en la hipótesis de un modelo simplificado de
funcionalidad de software que se supone que es razonable “de media” para el dominio de
aplicabilidad en que es utilizado. Es necesario por tanto cierto cuidado al medir, comparar o utilizar
(por ejemplo, para la estimación) tamaños de software muy pequeños, y especialmente los cambios
muy pequeños de una aplicación software, donde las consideraciones “medias” pueden no ser
aplicables. En el caso del método COSMIC, 'muy pequeño' significa con pocos movimientos de datos.
1.2 Requisitos Funcionales de Usuarios
El método de medición COSMIC supone la aplicación de un conjunto de modelos, principios, reglas y

procesos a los Requisitos Funcionales de los Usuarios (o Functional User Requirements, FUR) de
una determinada aplicación software. El resultado es un “valor de una cantidad” numérico (tal y como
se define en ISO), que representa el tamaño funcional de la aplicación software de acuerdo con el
método COSMIC.
Los tamaños funcionales medidos por el método COSMIC están diseñados para ser independientes
de cualesquiera decisiones de implementación propias de los artefactos operacionales del software
que se desea medir. "Funcionalidad" se refiere al “procesamiento de la información que el software
debe realizar para sus usuarios”.
Más concretamente, una declaración 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
declaración del FUR excluye cualesquiera requisitos técnicos o los de calidad que digan “cómo” debe
funcionar el software. (Para leer la definición formal de FUR, véase la sección 2.2.) A la hora de medir
el tamaño funcional sólo los FUR son tenidos en cuenta.
1.2.1 Extracción de los requisitos funcionales de usuario a partir de los artefactos del software en la
práctica
En el mundo real de desarrollo de software es raro encontrar artefactos para el software en los que
los FUR sean claramente distinguibles de otros tipos de requisitos y que sean expresados en un
formato adecuado para realizar mediciones directas, sin necesidad de interpretación. Esto significa
que por lo general el medidor tendrá que extraer los FUR tal y como se suministren, explícita o
implícitamente, en artefacto de software, antes de representarlos como conceptos de los “modelos de
software” de COSMIC.
Data Artifacts from

Requirements
analysis / modelling functional decomposition
definition artifacts
artifacts of requirements
Functional User Requirements (‘FUR’) in the

artifacts of the software to be measured
Figura 1.2.1 – Modelo COSMIC de la pre-implementación de los requisitos funcionales de usuario

Como se ilustra en la figura 1.2.1, el FUR puede ser derivado de artefactos de ingeniería de software
que se producen antes de que el software exista. Por lo tanto, el tamaño funcional del software puede
medirse antes de su implementación como un sistema informático.
Es importante señalar que los artefactos que se producen antes de que el software sea
implementado, por ejemplo, durante la recopilación o el análisis de requisitos, podrían describir el
software en diferentes “niveles de granularidad” mientras los requisitos evolucionan - véase también
más abajo la sección 2.4.
Nota: Los requisitos funcionales de usuario pueden ser producidos antes de que sean asignados al
hardware o al software. Dado que el método COSMIC está destinado a medir el FUR de una
aplicación software, sólo se medirán los FUR asignados a aplicación software. Sin embargo, en
principio el método COSMIC puede aplicarse a los FUR antes de que sean asignados a un software o
hardware, independientemente de la decisión eventual de asignación. Por ejemplo, es sencillo medir
el tamaño de funcionalidad de una calculadora de bolsillo utilizando COSMIC sin conocimiento que
hardware o software (si lo hubiera) será utilizado. Sin embargo, la afirmación de que el método
COSMIC se puede utilizar para medir FUR asignado a hardware, necesita más pruebas prácticas
antes de que pueda considerarse como plenamente validado sin la necesidad de más reglas.
1.2.2 Deducción de los requisitos funcionales de usuario a partir de software instalado
En otras circunstancias, se puede necesitar medir algunas aplicaciones de software existentes sin
que hubiera algún, o quizá sólo unos pocos, artefactos de diseño o arquitectura disponibles, y el FUR
podría no estar documentado (por ejemplo, para el legado del software). En tales circunstancias, aún
es posible obtener los FUR a partir de los artefactos instalados en el sistema incluso después de que
haya sido implementado, como se ilustra en el gráfico 1.2.2.
Functional User Requirements (‘FUR’) in the

artifacts of the software to be measured
Software
operations Physical
Physical data storage
programs manual and
procedures artifacts
Figura 1.2.2 – Modelo COSMIC de la post-implementación de los requisitos funcionales de usuario
1.2.3 Extracción o deducción de los requisitos funcionales de usuario a partir de artefactos software
Los procesos para ser utilizados y, por tanto, el esfuerzo necesario para extraer el FUR de diferentes
tipos de artefactos de ingeniería de software o para derivar de ellos el software instalado y para su
expresión en la forma requerida para la medición en el método COSMIC evidentemente variarán;
estos procesos no pueden ser tratados en el Manual de Medición. Se asume que los requisitos
funcionales del software que será medido bien existen o pueden ser extraídos o derivados de sus
artefactos, a la luz del propósito de la medición.

El Manual de Medición se limita, por lo tanto, a describir y definir los conceptos de modelos de
software COSMIC, es decir, los objetivos de la extracción o derivación. Estos conceptos están
plasmados en un conjunto de principios establecidos en dos modelos de software COSMIC - el
“Modelo de Contexto de Software” y el “Modelo Genérico de Software”.
Estos dos modelos se describen en el documento de “Descripción del Método”. Los lectores que
requieran una comprensión general y una justificación de los modelos se les refieren al documento de
“Descripción del Método”. Los modelos se copian a continuación para mayor comodidad y se
exponen respectivamente en detalle en los capítulos 2 y 3 del presente Manual de Medición.
1.3 Modelo COSMIC de Contexto de Software
Una aplicación software que va a ser medida con el método COSMIC debe ser cuidadosamente
definida (en el alcance de medición) y esta definición debe tener en cuenta su contexto de cualquier
otro software y/o hardware con los que interactúa. Este Modelo de Contexto de Software introduce el
modelo de principios y conceptos necesarios para esta definición.
Nótese bien, Los términos se indican en negrita cuando se utilizan por primera vez en las siguientes
secciones 1.3 y 1.4 se utilizan con significados que pueden ser específicos para el método COSMIC.
Para la definición formal, véase el documento: “Descripción Documental y Glosario de Términos”.
Todos estos términos se explican en mayor detalle en los capítulos 2, 3 y 4.
Principios del Modelo COSMIC de Contexto de Software:

a) El software está limitado por el hardware
b) El software está típicamente estructurado en capas
c) Una capa puede contener una o más aplicaciones de software semejante, y
cualquier aplicación software puede consistir de uno o más componentes del
mismo tipo separados.
d) Cualquier aplicación software que deba medirse, se define por su alcance de
medición, que se limitará en su totalidad dentro de una sola capa
e) El alcance de aplicación software debe medirse en función de la finalidad de la
medición
f) Los usuarios funcionales de una aplicación software se identificarán a partir de los
FUR de la aplicación software que se medirá como los remitentes y/o
destinatarios de los datos
g) Una aplicación software interactúa con sus usuarios a través de movimientos de
datos por una frontera y la aplicación software puede mover datos hacia y desde
zonas de almacenamiento persistente dentro de unos límites
h) Los FUR de software pueden expresarse en distintos niveles de granularidad
i) El nivel de granularidad en que las mediciones se hacen normalmente es el de los
procesos funcionales
Si no es posible medir a nivel de granularidad del proceso funcional, entonces los
FUR del software deben ser medido por aproximación y escalado al nivel de
granularidad funcional del proceso
Los conceptos del Modelo de Contexto del Software se detallan en la “Estrategia de medición” en el
Capítulo 2 de este Manual de Medición.
1.4 Modelo Genérico del Software
Después de haber interpretado los FUR del software a ser medido en términos del “Modelo de
Contexto del Software”, debemos ahora aplicar el Modelo Genérico del Software a los FUR para
identificar los componentes de la funcionalidad que se medirán. Este Modelo Genérico de Software
asume que los siguientes principios generales son ciertos para cualquier software que puede ser
medido con el método. (Como se señala en el glosario, cualquier método de medición de tamaño

funcional tiene por objeto identificar los “tipos” y no las “ocurrencias” de los datos o funciones. En el
texto que figura a continuación, el sufijo “tipo” será por lo tanto omitido al mencionar los conceptos
básicos COSMIC a menos que sea esencial para distinguir “tipos” de “ocurrencias”.)
Principios del Modelo de Software COSMIC Genérico:

a) El Software recibe los datos de entrada de sus usuarios funcionales y produce
datos de salida, y/u otro resultado, para los usuarios funcionales
b) Las requisitos funcionales de los usuarios de la aplicación software a medir
pueden representarse como procesos funcionales únicos
c) Cada proceso funcional consiste en sub-procesos
d) Una sub-proceso puede ser, o bien un movimiento de datos o una
manipulación de datos
e) Cada proceso funcional es activado por un movimiento de entrada de datos
desde un usuario funcional que informa al proceso funcional que el usuario
funcional ha identificado un evento
f) Un movimiento de datos mueve un sólo grupo de datos
g) Un grupo de datos consiste en un conjunto único de atributos de datos que
describen un único objeto de interés.
h) Existen cuatro tipos de movimientos de datos: Una Entrada, mueve un grupo de
datos hacia el software desde un usuario funcional. Una Salida mueve un grupo
de datos del software hacia un usuario funcional. Una Escritura mueve un grupo
de datos desde el software hacia un almacén persistente. Una Lectura mueve
un grupo de datos desde un almacén persistente hacia el software
i) Un proceso funcional deberá incluir al menos un movimiento de entrada y, o
bien un movimiento de Salida o Escritura de datos, es decir que deberá incluir
un mínimo de dos movimientos de datos
j) Como una aproximación para fines de medición, los sub-procesos de
manipulación de datos no se miden por separado; la funcionalidad de cualquier
manipulación de datos se supone que se explica por el movimiento de datos con
el que está asociado
Los conceptos del Modelo Genérico de Software se detallan en la “Fase de Representación” Capítulo
3 del presente Medición Manual.
Cuando el FUR a ser medido ha sido representado en el Modelo Genérico de Software, puede ser
entonces medido utilizando los procesos de la Fase de Medición (Capítulo 4). Los resultados de la
medición deberían ser documentados de acuerdo con las convenciones del Capítulo 5 “Informes de
Medición”.
1.5 El Proceso de Medición COSMIC
El proceso de medición COSMIC se compone de tres fases:
• La Fase de Estrategia de Medición, en la cual el Modelo de Contexto de Software se aplica al

software a ser medido (Capítulo 2)
• La Fase de la Representación de la Medición, en la cual el Modelo Genérico de Software se
aplica al software a ser medido (Capítulo 3)
• La Fase de Medición, en la cual se obtienen las mediciones reales (capítulo 4)
El resultado de aplicar el proceso de medición a una aplicación software es una medida de tamaño
funcional de los Requisitos Funcionales de Usuario de la aplicación software expresada en “Puntos
de Función COSMIC” (ó CFP)
La relación entre estas tres fases del método COSMIC se muestra en la Fig. 1.5.

Purpose of the
Goals Chapter 3 measurement. Scope of
Measurement each piece of software
Software Context Model Strategy to be measured
Functional User Requirements (FUR) in the Chapter 4

artefacts of the software to be measured FUR in the form of the
Mapping
Generic Software Model
Generic Software Model Phase
Chapter 5 Functional
Measurement size of the
Phase software in
units of CFP
The Measurement Process
Figura 1.5 – Estructura del método COSMIC

2
FASE DE ESTRATEGIA DE MEDICIÓN
En este capítulo se abordan los cuatro parámetros fundamentales de medición del tamaño funcional
del software que debe ser considerados antes de comenzar a medir, estos son: el propósito y el
alcance de la medición, la identificación de los usuarios funcionales y el nivel de granularidad que
debe medirse. Determinar estos parámetros ayuda a abordar las cuestiones de ¿qué tamaño debe
medirse? o, para una medición existente, ¿cómo debemos interpretar esta medida?
Es importante señalar que estos cuatro parámetros y conceptos relacionados no son específicos del
método de la medición del tamaño funcional COSMIC, pero debe ser común a todos los métodos
FSM (Functional Size Measurement). Otros métodos FSM pueden no distinguir diferentes tipos de
usuarios funcionales y pueden no discutir los diferentes niveles de granularidad, etc. Sólo la
aplicación más amplia y la flexibilidad del método COSMIC requieren que se tomen en cuenta estos
parámetros más cuidadosamente que con otros métodos FSM.
Es muy importante guardar los datos resultantes de esta fase de “Estrategia de Medición” (que se
enumeran en la sección 5.2) al guardar el resultado de cualquier medición. La falta de definición y
registro de estos parámetros dará lugar a mediciones que no pueden ser interpretadas fiablemente y,
o ser utilizadas para procesos tales como la estimación de esfuerzo del proyecto.
Las cuatro secciones de este capítulo dan las definiciones formales, principios, normas y algunos
ejemplos para cada uno de los principales parámetros para ayudar al medidor a través del proceso de
determinar una “Estrategia de Medición”, como se muestra en la figura 2.0 mostrada más abajo.
Cada sección ofrece explicaciones de por qué el parámetro clave es importante, utilizando analogías
para mostrar por qué el parámetro se da por sentado en otros campos de medición, razón por la cual
también debe ser considerado en el ámbito de de medición de tamaño funcional de software.
COSMIC MEASUREMENT STRATEGY PHASE
Section 2.1 Section 2.2

Input from the
Determine Determine
MEASUREMENT
PURPOSE of the SCOPE of the
SPONSOR
measurement measurement
Section 2.3
Identify the
FUNCTIONAL
USERS
ITERATE
Section 2.4
Determine the
THE
LEVEL OF GRANULARITY
MEASUREMENT
of the measurement
STRATEGY
Figure 2.0 – El proceso de determinar la Estrategia de Medición

2.1 Definir el propósito de la Medición
El término 'propósito' es usado en su significado inglés.
Definición – Propósito de la medición
Una declaración que define por qué una medida es necesaria, y para qué se utilizará el
resultado
2.1.1 El propósito de una medición determina el tamaño que será medido
Hay muchas razones para medir el tamaño funcional del software, así como hay muchas razones
para medir, por ejemplo, las superficies de una casa. Cuando el objetivo es estimar el coste de un
nuevo desarrollo de software, podría ser necesario medir el tamaño funcional del software antes de
su desarrollo, del mismo modo que podría ser necesario medir las superficies de una casa antes de
su construcción. En un contexto diferente, por ejemplo, cuando se necesitan comparar con los costes
reales con los estimados, tal vez sea necesario medir el tamaño funcional del software una vez se ha
puesto en producción, del mismo modo que podría ser útil medir las superficies de una casa después
de haber sido construida para comprobar que las dimensiones se ajustan a los planes convenidos. La
razón por la cual se ha tomado una medida tiene un impacto a lo que se está midiendo, sin que ello
afecte a la unidad de medida o a los principios de medición.
En el ejemplo anterior de la casa, la medición de su superficie antes de la construcción se basa,

obviamente, en los planos de construcción. Las dimensiones (longitud y anchura) se extraen de los
planos usando la adecuada escala y las superficies se calculan de acuerdo a convenios establecidos.
Del mismo modo, medir el tamaño funcional del software antes de su desarrollo se basa en las
necesidades de los usuarios funcionales de software que se derivan de sus planos, es decir, los
artefactos de software producidos antes de su desarrollo. Las necesidades funcionales de los
usuarios son extraídas de estos aparatos que usando los convenios adecuados y las dimensiones
necesarias (el número de movimientos de datos) se identifican de modo que se pueda calcular el
tamaño.
Para continuar con la analogía de la casa, la medición de su superficie después de que haya sido
construida implica un proceso de medición diferente. Ahora, las dimensiones (longitud y anchura) son
extraídas del propio edificio utilizando una herramienta diferente (cinta métrica). Sin embargo, a pesar
de que el objeto físico que se mide es diferente (la casa en lugar de sus planos), las dimensiones, la
unidad de medida (incluyendo cualquier convención de escala) y todos los principios de medición
siguen siendo los mismos.
Del mismo modo, medir el tamaño funcional del software después de que haya sido puesto en la
producción implica un proceso diferente de medición cuando las dimensiones necesarias se extraen
de los diversos aparatos del software en sí. Aunque la naturaleza de estos aparatos es diferente, las
dimensiones, la unidad de medida y los principios de medición siguen siendo los mismos.
Es decisión del medidor, basándose en el propósito de la medición, determinar si el objeto a ser

medido es la casa a partir de la descripción verbal de su propietario; la casa, tal como se describe a
través de los planos; o la casa, una vez que ha sido construida; así como seleccionar los artefactos
más apropiados para la medición. Es evidente que los tres tamaños podrían ser diferentes. El mismo
razonamiento se aplica a la medición de software.
EJEMPLOS: Algunos propósitos típicos de la medición

• Medir el tamaño de los FUR a medida que evolucionan, como entrada a un proceso de
estimación del esfuerzo de desarrollo
• Medir el tamaño de los cambios de FUR después de haber sido inicialmente acordados, con el fin
de gestionar el alcance avanzado de un proyecto

• Medir el tamaño de los FUR a la entrega de software como entrada para la medición del
rendimiento de los desarrolladores
• Medir el tamaño de los FUR del software se han entregado, y también el tamaño de los FUR del
software que han sido desarrollado, con el fin de obtener una medida funcional de la reutilización
• Medir el tamaño de los FUR de los programas existentes, como entrada a la medición del
desempeño de los responsables de mantener y sostener el software
• Medir el tamaño de algunos cambios en (el FUR de) un sistema de software existente, como una
medida del tamaño de un proyecto de mejora
• Para medir el tamaño de la funcionalidad del software entregado a usuarios funcionales humanos
2.1.2 La importancia del propósito
El propósito ayuda a los medidores a determinar:
• El alcance que debe medirse y los aparatos que serán necesarios para la medición
• Los usuarios funcionales (como se indica en la sección 2.3, el tamaño de los cambios funcionales
es función de lo que se defina como el usuario funcional)
• El momento en el ciclo de vida del proyecto en el que la medición se llevará a cabo
• La precisión necesaria de la medición, y por lo tanto, si debería utilizarse la medición con el
método COSMIC, o si debería se debería utilizar una aproximación derivada localmente de
COSMIC (por ejemplo, de manera temprana en el ciclo de vida de un proyecto, antes de que los
FUR estén totalmente elaborados). Ambos de estos dos últimos puntos determinan el nivel de
granularidad al cual serán medidos los FUR.
2.2 Definir el alcance de la medición
Definición – Alcance de una medición
El conjunto de los requisitos funcionales de usuario que deben incluirse en un

determinado ejercicio de medición de tamaño funcional.
Nota: Se debe hacer una distinción entre el alcance general, es decir, todo el software
que debe medirse en función del objetivo, y el alcance de cualquier aplicación software
en el alcance global, cuyo tamaño debe medirse por separado. En este Manual de
Medición, el término “alcance” (o la expresión “alcance de la medición”) se refieren a una
aplicación única de software, cuyo tamaño debe medirse por separado.
Los Requisitos Funcionales de los Usuarios son definidos por ISO como sigue:
Definición – Requisitos Funcionales de los Usuarios (Functional Users

Requirements, FUR)
Subconjunto de los Requisitos de los Usuarios. Requisitos que describen lo que el

software deberá hacer, en términos de funciones y servicios.
Nota: Los requisitos funcionales de los usuarios incluyen, pero no están limitados a:
• Transferencia de datos (por ejemplo de entrada de datos de clientes; enviar señal
de control)
• Transformación de datos (por ejemplo calcular los intereses bancarios; derivar
temperatura media)
• Almacenamiento de datos (por ejemplo pedidos de clientes; recopilar datos de
temperatura ambiente durante un tiempo)
• Recuperación de datos (por ejemplo listas de los empleados actuales; recuperar la
última posición de una aeronave)
Ejemplos de requisitos de los usuarios que no son requisitos funcionales de los usuarios

incluyen, pero no están limitados a:
• Restricciones de calidad (por ejemplo, facilidad de uso, fiabilidad, eficiencia y
portabilidad)
• Restricciones de organización (por ejemplo, localización de operación, hardware
objetivo y cumplimiento de normas)
• Restricciones medioambientales (por ejemplo, interoperabilidad, seguridad,
privacidad y seguridad)
• Aplicación de limitaciones (por ejemplo, lenguaje de desarrollo, calendario de
entrega)
Reglas – Alcance
a) El alcance de una medición de tamaño funcional (FSM) se obtendrá del propósito de
la medición.
b) El alcance de una medición no se extenderá a más de una capa de software que
debe medirse
2.2.1 El alcance de una medición depende de la finalidad
Es importante definir el alcance de una medición antes de comenzar un ejercicio de medición.
Siguiendo con la analogía de la construcción de casas, puede ser necesario, si el propósito es la

estimación de costes, medir el tamaño de diferentes partes de la casa por separado, por ejemplo, los
cimientos, las paredes y el techo, debido a que utilizan diferentes métodos de construcción. Lo mismo
es válido para la estimación de costes de desarrollo de software.
En caso de un sistema de software sucede que consta de partes que residen en diferentes capas de
la arquitectura del sistema, por consiguiente tendrá que ser medido por separado el tamaño del
software en cada capa, es decir, cada parte tendrá un alcance diferente para los propósitos de
medición de tamaño. Esto se desprende del principio (d) del Modelo de Contexto de Software. (Para
más información sobre capas, consulte la sección 2.2.4 a continuación.)
Del mismo modo, si el software debe ser desarrollado como un conjunto de componentes semejantes
dentro de una sola capa, cada una de ellas utilizando diferentes tecnologías, entonces será necesario
definir un alcance de la medición separado para cada uno de los componentes antes de la medición
de su tamaño.
Ejemplo 1: Si cada componente de software usa una tecnología diferente y las medidas son usadas para la estimación del
esfuerzo de desarrollo, entonces debería ser definida para cada componente una medida separada porque cada medición
del tamaño irá asociada con una cifra de productividad diferente (para más información de componentes semejantes, véase
la sección 2.2.5 más abajo).
El propósito también ayudará a decidir qué software debe ser incluido y excluido del alcance de la
medición.
Ejemplo 2: Si el propósito es medir el tamaño funcional de una pieza de software desarrollada por un equipo de proyecto en
particular, primero será necesario definir los requisitos funcionales del usuario de los diversos componentes que serán
desarrollados por el equipo. Estos podrían incluir los FUR de una aplicación software que es utilizada sólo una vez para
convertir datos de un software que se está reemplazando.
Ejemplo 3: Si el propósito es medir el tamaño de un nuevo software que está disponible para su uso operativo, este podría
ser más pequeño que para el ejemplo 2, ya que los FUR del software utilizado para la conversión no serían incluidos en el
ámbito de la medición de tamaño.

En resumen, el propósito de la medición 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.
2.2.2 Tipos genéricos de alcance
Ejemplos
• La cartera de proyectos de una empresa
• Un acuerdo contractual de especificación de requisitos
• El producto entregado por el equipo de trabajo de un proyecto (es decir, incluyendo los parámetros obtenidos por la
explotación de los programas informáticos existentes, paquetes comprados y código re-utilizable, cualquier programa
utilizado para la conversión de datos y posteriormente desechado, y utilidades y software de pruebas desarrollados
específicamente para este proyecto)
• El producto desarrollado por el equipo de trabajo de un proyecto (es decir, incluyendo cualquier software desarrollado
por el equipo y utilizado para la conversión de datos, pero posteriormente descartado, y cualquier utilidad y software de
pruebas de software desarrollado específicamente para este proyecto, pero con exclusión de toda la funcionalidad
obtenida por el cambio parámetros y la explotación de el código re-utilizable o comprada en paquetes comerciales)
• Todo el software de una capa
• Un paquete software
• Una aplicación
• Un componente par o semejante principal de una aplicación
• Una objeto de clase re-utilizable
• Todos los cambios necesarios para una nueva versión de una aplicación software existente
En la práctica, una declaración de alcance tiene que ser explícita en lugar de genérica, por ejemplo, el
producto de un proyecto desarrollado por el equipo de trabajo “A”, o la aplicación “B”, o la cartera de
la empresa “C”. La declaración de alcance también puede tener, para una mayor claridad, necesidad
de establecer lo que ha sido excluido.
2.2.3 Niveles de descomposición
Tenga en cuenta que algunos de los ‘tipos genéricos de alcance’ de los mencionados, corresponden
a diferentes ‘niveles de la descomposición’ del software, definidos de la siguiente manera:
Definición – Nivel de descomposición
Cualquier nivel resultante de dividir una parte de software en componentes

(denominados ‘Nivel 1’, por ejemplo), de dividir dichos componentes en sub-
componentes (‘Nivel 2’), y de dividir estos subcomponentes en sub-sub componentes
(‘Nivel 3’), etc.
Nota 1: No debe confundirse con ‘nivel de granularidad’.
Nota 2: Las mediciones de tamaño de componentes de una parte del software sólo
pueden ser comparadas con componentes semejantes, por ejemplo, componentes del
mismo nivel de descomposición.
Ejemplo: De los diferentes niveles de descomposición, correspondientes a diferentes “tipos genéricos de alcance” podría ser
una “cartera de aplicaciones” que consiste en “múltiples aplicaciones”, cada una de las cuales puede consistir en
“componentes especiales semejantes”, cada una de los cuales puede consistir a su vez en “clases de objetos re-utilizables”.
Determinar el alcance de una medida puede ser, por consiguiente, algo más que una simple cuestión
de decidir qué funcionalidad debería incluirse en la medición. La decisión también puede conllevar un
examen del nivel de descomposición de software donde se medirá. Se trata de una decisión
importante de la “Estrategia de Medición”, depende de la finalidad de la medición, porque las
mediciones a diferentes niveles de descomposición no pueden ser comparadas fácilmente. Esto
surge porque, como se verá en la sección 4.3.1, el tamaño de cualquier aplicación software no se
puede obtener simplemente sumando los tamaños de sus componentes.
2.2.4 Capas
Dado que el alcance de una aplicación 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
cuáles son las capas de la arquitectura del software. Por lo tanto en esta sección vamos a definir y
discutir “capas” y “peer componentes” de software tal y como estos términos son utilizados en el
método COSMIC.
Las razones por las que necesitamos estas definiciones y reglas son las siguientes:
• El medidor puede encontrase con la medición de algún tipo de software en un entorno de

software “legado” que ha evolucionado a lo largo de muchos años sin haber sido diseñado de
acuerdo a una arquitectura subyacente (la llamada arquitectura espagueti) El medidor puede, por
tanto, necesitar orientación de cómo distinguir las capas de acuerdo con la terminología COSMIC.
• Las expresiones “capa”, “arquitectura en capas” y “componente semejante” no se utilizan
consistentemente en la industria del software. Si el medidor debe medir algún tipo de software
que ha sido descrito mediante una “arquitectura de capas”, es aconsejable comprobar que las
“capas” en esta arquitectura están definidas de una manera que sea compatible con el método
COSMIC. Para ello, el medidor debería establecer la equivalencia entre determinados objetos
arquitectónicos en el paradigma de “arquitectura de capas” y el concepto de capas, tal como se
definen en este manual.
Las capas pueden ser identificadas conforme a las siguientes definiciones y principios.
Definición – Capa
Una capa es una partición resultante de la división funcional de una arquitectura de

software que junto con el hardware en su conjunto forma un sistema informático en el
que:
• las capas están organizadas en una jerarquía
• sólo hay una capa en cada nivel en la jerarquía
• exista una dependencia jerárquica “superior/subordinado” entre los servicios
funcionales prestados por el software en dos capas en la arquitectura de software
que intercambia datos directamente
• el software en cualesquiera dos capas en la arquitectura del software que
intercambian datos interpreta sólo parte de los datos de forma idéntica
La identificación de capas es un proceso iterativo. Las capas exactas serán refinadas a medida que el
proceso de representación avance. Una vez identificadas, cada una de las capas candidatas deben
cumplir con los principios y reglas siguientes:
Principios – Capa
c) El Software en una capa intercambia datos con el software en otro nivel a través de
sus respectivos procesos funcionales.
d) La “dependencia jerárquica” entre capas es tal que el software en cualquier capa
puede utilizar los servicios funcionales de cualquier software en cualquier capa
debajo en la jerarquía. En caso de que existan relaciones de dicho uso,
designamos a la capa que da uso al software como la capa “superior” y cualquier
capa que contiene el software usado como “subordinada”. El software en la capa
superior se basa en los servicios de software de las capas subordinadas para
funcionar correctamente, estas, a su vez se basan en el software de sus capas
subordinadas, y así sucesivamente desciende en la jerarquía. Por el contrario, el
software en una capa subordinada, junto con el software en cualquier capa

subordinada de la que depende, puede funcionar sin necesidad de los servicios de
software en cualquier capa superior en la jerarquía.
e) El Software en una capa no necesariamente usa todos los servicios funcionales
prestados por una capa subordinada.
f) Los datos que se intercambian entre software en dos capas se define e interpreta
de manera diferente en los respectivas FUR de las dos partes de software, es decir,
las dos partes de software reconocen diferentes atributos de datos y/o sub-
agrupaciones de los datos que intercambian. Sin embargo, deben existir uno o más
atributos de datos o sub-grupos definidos de forma similar para permitir que el
software en la capa receptora pueda interpretar los datos que ha pasado el
software en la capa emisora, de acuerdo con las necesidades de recepción de
software.
Reglas – Capa
a) Si el software está concebido utilizando una arquitectura de capas como se
entiende aquí, entonces que la arquitectura debe ser usada para identificar las
capas usadas a efectos de medición.
b) En el dominio SIM o software empresarial, la capa más alta, es decir la capa que no
está subordinada a ninguna otra capa, normalmente se denomina la capa de
aplicación. Una aplicación de software en esta capa se basa en última instancia en
los servicios de software en todas las otras capas para funcionar adecuadamente.
En el dominio de a tiempo real software, el software en la capa superior
comúnmente se denomina como un sistema, como por ejemplo en el software de
un sistema de control de procesos, o también por ejemplo en un software de
sistema de control de vuelo.
c) No se puede asumir que ningún software que se ha desarrollado sin ningún tipo de
consideración de diseño arquitectónico o estructuración puede dividirse en capas
de acuerdo al modelo COSMIC.
Los paquetes de software de servicios funcionales tales como los sistemas de gestión de bases de
datos, sistemas operativos o controladores de dispositivo, debe considerarse en principio que se
situarán en capas separadas.
Una vez identificadas, cada capa puede ser registrada como un “componente” separado en la matriz
del Modelo Genérico de Software (anexo A), con la correspondiente etiqueta.
Ejemplo 1: La estructura física de una típica arquitectura de software en capas (utilizando el término “capa” como ha sido
definido aquí) que soporte aplicaciones software de gestión se da en la figura 2.2.4.1:

Application Layer App 1 App 2 App ‘n’
Key:
Superior
Middleware Layer (Utilities, etc) Layer
Software relies on
Database Management
Layers DBMS 1 DBMS 2
System Layer Subordinate
Layer
Operating System Layer
Keyboard Screen Print Disk

Driver Driver Driver Driver
VDU Hard Disk Central

Hardware Keyboard Printer
Screen Drive Processor
Figura 2.2.4.1 – Típica arquitectura de software en capas de un sistema de negocios
Ejemplo 2: La estructura física de una típica arquitectura de software en capas (de nuevo utilizando el término “capa” como
ha sido definido aquí) soportando una parte imbuida de una aplicación en tiempo real se muestra en la figura 2.2.4.2:
Embedded Application Layer Key:
Superior
Layer
Software
relies on
Layers Operating System Layer
Subordinate
Layer
Sensor CV Display Mem. Chip
Driver Driver Driver Driver
Hardware Sensor(s)
Control
Display
Memory Central
(Examples) Valve(s) Chip Processor
Figure 2.2.4.2 – Típica arquitectura en capas de un sistema software embebido de tiempo real
2.2.5 Componentes Semejantes o Pares (Peer)

Visto el concepto de capas, ‘peer’ se define de la siguiente manera:
Definición – Semejante
Dos partes de software son semejantes una a la otra si se encuentran en la misma

capa.
Nota: Dos piezas semejantes de software no tienen que estar en el mismo nivel de
descomposición.

Los componentes semejantes pueden ser identificados de acuerdo a la siguiente definición y
principios.
Definición – Componente semejante
Un componente usa un juego de componentes cooperativos, todos en el mismo nivel

de descomposición, que resulta de dividir una parte de software dentro de una capa,
donde cada componente llena una porción de los requerimientos funcionales de
usuario de esa parte de software.
Nota: La división de una pieza del software en componentes semejantes puede ser una
respuesta a requerimientos de usuarios funcionales y/o no funcionales.
Una vez identificados, cada uno de los supuestos componentes pares deben cumplir con los
siguientes principios:
Principios – Componente semejante

a) En una capa de un conjunto de componentes semejantes de una pieza no existe
dependencia jerárquica entre los componentes semejantes como hay entre las
capas. Los FUR homólogos de todos los componentes de una pieza de software en
cualquier capa se encuentran en al mismo nivel en la jerarquía de capas.
b) Todos los componentes semejantes de una pieza de software deben cooperar
mutuamente con el fin de que la pieza de software pueda funcionar correctamente.
c) El FUR de componentes semejantes en toda una capa que emita o comparta datos
en común define esos datos idénticamente, es decir, reconoce los mismos datos y
sub-agrupaciones de datos que pasan o comparten.
Una vez identificados, cada uno de los componentes semejantes pueden ser registrados como un
componente individual en la matriz del modelo genérico de software (anexo A), con la
correspondiente etiqueta.
Ejemplo: Cuando una aplicación de gestión se desarrolla en tres grandes componentes, denominados “interfaz de usuario”
(o “front-end”), “reglas de negocio” y “datos de servicio”, los tres componentes son componentes semejantes.
NOTA: Dos partes de software separadas pero semejantes en la misma capa y que intercambian
datos entre sí pueden hacerlo tanto por cualquiera de las secuencias alternativas definidas en el
principio c) para dos componentes semejantes.
El siguiente diagrama muestra una situación que ilustra el ejemplo. Todo el software mostrado reside
en la misma capa de la aplicación. Los intercambios entre dos componentes semejantes de la
Aplicación X y entre dos partes semejantes de software (Componente 2 de la Aplicación X y
Aplicación Y) pueden darse a través de cualquiera de las secuencias alternativas que se definen en el
principio c) para dos componentes semejantes.
App X App Y
Level 1 of decomposition of
App X Comp 1 Comp 2 Comp 3
Application X consists of 3 peer components, each to be measured separately
Exchanges between two peer components of Application X

Exchanges between two peer pieces of software
Figure 2.2.5.1 – Relación entre los conceptos de ‘semejantes’, ‘componente’ y ‘componentes semejantes’

2.3 Identificar los usuarios funcionales
2.3.1 El tamaño funcional varía con el usuario funcional
A partir de una analogía, la medición de la superficie de una oficina puede llevarse a cabo de acuerdo
con cuatro diferentes convenios, como se indica a continuación (nótese que el alcance – la oficina en
particular – es la misma para los cuatro convenios).
• El propietario del edificio tiene que pagar impuestos por la oficina. Para el propietario, la superficie
es el bruto de los metros cuadrados, determinado a partir de las dimensiones externas y, por
tanto, incluidos todos los pasillos públicos, el espacio ocupado por las paredes, etc.
• El responsable del aire acondicionado del edificio está interesado en la red de metros cuadrados,
es decir, las zonas de interior, incluidos los las zonas públicas y en el espacio tomado por los
ascensores, pero excluyendo el espesor de las paredes
• El contratista del servicio de limpieza contratado por una oficina específica del edificio está
interesado en los metros cuadrados netos, que excluye los espacios públicos, pero que incluye
los pasillos utilizados por el arrendatario.
• El responsable de la planificación de oficinas solo está interesado en los metros cuadrados netos
útiles.
La lección de esta analogía es que el tamaño de un objeto puede variar dependiendo de la

funcionalidad que es de interés para diferentes tipos de usuarios del objeto. En el caso del software,
diferentes usuarios funcionales podrán exigir y utilizar diferentes funcionalidades y, por tanto, los
tamaños funcionales varían con la elección de los usuarios funcionales.
2.3.2 Usuarios Funcionales
Un “usuario” se define, en la norma ISO/IEC 14143/1:2007, como “cualquier cosa que interactúa con
el software que se está midiendo”. Esta definición es demasiado amplia para las necesidades del
método COSMIC. Para el método COSMIC, la elección 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” y se define como sigue.
Definición – Usuario Funcional
Es un usuario aquel remitente y/o destinatario de datos de los Requisitos Funcionales

de Usuario de una aplicación software.
En el método COSMIC es esencial distinguir a los usuarios funcionales de una parte del software que
debe ser medido de entre todos sus posibles usuarios.
Ejemplo 1: Considere una aplicación empresarial; Sus usuarios funcionales normalmente incluirían humanos y otras
aplicaciones semejantes con las que la aplicación interactúa. Para una aplicación en tiempo real, los usuarios funcionales
normalmente serían dispositivos hardware u otros software semejantes que interactúen con ella. Las necesidades de los
usuarios funcionales (FUR) de dicho software normalmente se expresan de modo que los usuarios funcionales son los que
envían datos y/o los destinatarios de los datos hacia y desde el software, respectivamente.
Sin embargo, el conjunto total de “usuarios”, es decir, incluida cualquier cosa que interactúa con el software, debe incluir el
sistema operativo. Pero los FUR de cualquier aplicación nunca incluirían el sistema operativo como un usuario. Cualquier
limitación que el sistema operativo pueda imponer a una aplicación será común para todas las aplicaciones, por lo general,
se encargarán de ella el compilador o intérprete, y son invisibles para los usuarios funcionales reales de la aplicación. En la
práctica de medición de tamaño funcional, un sistema operativo nunca sería considerado como un usuario funcional de una
aplicación.
Pero no siempre se da el caso de que lo usuarios funcionales sean obvios.

Ejemplo 2: Tomemos el ejemplo de la aplicación software de un teléfono móvil (se mencionó por primera vez en la
Introducción). A pesar de que hemos eliminado el sistema operativo del teléfono móvil como un posible usuario funcional de
la aplicación, los usuarios podrían ser (a) los seres humanos que pulsan las teclas, o (b) los dispositivos de hardware (por
ejemplo, la pantalla, teclado, etc.) y aplicaciones semejantes que interactúan directamente con la aplicación del teléfono. El
usuario humano, por ejemplo, verá sólo un subconjunto de toda la funcionalidad de la que debe ser provista a fin de que la
aplicación del teléfono móvil funcione. Por lo tanto, estos dos tipos de usuarios verán diferente funcionalidad, el tamaño de
los FUR para los usuarios humanos será menor que el tamaño de los FUR que deben desarrollarse para hacer la aplicación
de teléfono funcione.
Reglas – Usuarios Funcionales
a) Los usuarios funcionales de una aplicación software que se hayan de medir se
derivan del propósito de la medición
b) Cuando el propósito de una medición de una aplicación software está relacionado
con el esfuerzo para desarrollar o modificar el software, entonces los usuarios
funcionales deben ser aquellos para los cuales se está modificando o
proporcionando este nuevo software.
Una vez identificados los usuarios funcionales, entonces es sencillo determinar la frontera, ya que,
simplemente se encuentra entre la pieza de software que se está midiendo y sus usuarios
funcionales.
Definición – Frontera
La Frontera se define como un interfaz conceptual entre el software que está siendo
medido y sus usuarios funcionales.
Nota: La frontera de una aplicación software es la línea divisoria conceptual entre esta
pieza y el medio en el que opera, ya que se percibe externamente desde la perspectiva
de sus usuarios funcionales. La frontera permite que el medidor distinga, sin
ambigüedad, lo que se incluye dentro del software a ser medido de lo que es parte del
medio en el que opera el software.
Nótese, que esta definición de frontera está tomada de la norma ISO/IEC 14143/1:2007, modificada
por la adición de la palabra ‘funcional’ para calificar al ‘usuario’. Para evitar la ambigüedad, tenga en
cuenta que la frontera no debe confundirse con ninguna línea que pueda dibujarse alrededor de
ningún programa que deba ser medido para definir el alcance de la medición. La frontera no se utiliza
para definir el alcance de la medición.
Las siguientes reglas podrían ser útiles para confirmar la condición de una posible frontera:
Reglas – Frontera
a) Identificar los usuarios funcionales que interactúan con el software que se mide. La
frontera se encuentra entre los usuarios funcionales y este software.
b) Por definición, hay una frontera entre cada par de capas identificadas donde el
software en una capa es el usuario funcional del software en otra capa, y este último
va a ser medido.
c) Hay una frontera entre dos partes cualquiera de un programa, incluidos los
componentes que son semejantes entre sí; en este caso cada parte de programa
y/o cada componente puede ser un usuario funcional de su semejante.
La frontera permite establecer una distinción clara entre todo lo que forma parte de la aplicación
software que va a ser medida (es decir, que se encuentra en la zona de software de la frontera) y
todo lo que forma parte del medio de los usuarios funcionales (es decir, que se encuentra en la zona
del usuario funcional de la frontera). Los almacenes persistentes no se consideran como un usuario
del software y, por tanto, se encuentran en la zona del software de la frontera.

2.4 Identificando el nivel de granularidad
2.4.1 La necesidad de un nivel de granularidad estándar
Cuando se comienza un proyecto para diseñar y construir una nueva casa, los primeros planos de un
arquitecto se encuentran en la casa en una situación de “alto nivel”, es decir, que muestran un
esquema y pocos detalles. A medida que el proyecto avanza hacia la fase de construcción, se
necesitan los planos más detallados (“bajo nivel”).
Lo mismo puede decirse para el software. 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, (por
ejemplo, a través de las versiones 1, 2, 3, etc.), revelando más detalle a un menor nivel. Estos
diferentes grados de detalle de los FUR, son conocidos con los diferentes “niveles de granularidad”.
(Véase también la sección 2.4.3 para otros términos que pueden confundirse con el concepto de nivel
de granularidad como es definido aquí).
Definición – Nivel de granularidad
Cualquier nivel de expansión de la descripción de una sola aplicación software (por

ejemplo, una declaración de requisitos, o una descripción de la estructura de la
aplicación software) de tal manera que a cada aumento del nivel de expansión, la
descripción de la funcionalidad de la aplicación software se encuentra en un nivel de
detalle mayor y uniforme.
Nota: Los medidores deben ser conscientes de que cuando los requisitos van
apareciendo a principios de la vida de un proyecto de software, diferentes partes de la
funcionalidad necesaria del software normalmente se habrán documentado en los
diferentes niveles de granularidad.
Los planos de construcción de viviendas usan escalas estándar, y es fácil traducir dimensiones de en
un dibujo a otro dibujo realizado con una escala distinta. En cambio no hay escalas estándar para los
diversos niveles de granularidad con que el software puede ser especificado, por lo que puede ser
difícil tener la certeza de que dos declaraciones de los requisitos funcionales de los usuarios (FUR) se
encuentran al mismo nivel de granularidad. Sin un acuerdo en algún nivel de granularidad de a que
escala se debe medirse es imposible saber con certeza que dos mediciones de tamaño funcional
pueden compararse. Y los medidores tienen que desarrollar su propio método para pasar las
mediciones de un nivel de granularidad a otro.
Para ilustrar aún más los problemas, consideremos otra analogía. Un conjunto de mapas de
carreteras revela los detalles de una red nacional de carreteras en tres niveles de granularidad.
• Mapa A muestra sólo las autopistas y carreteras principales

• Mapa B muestra todas las carreteras principales y carreteras secundarias (como en un atlas para
los automovilistas),
• Mapa C muestra todas las carreteras secundarias (como en una serie de mapas del distrito local),
Si no reconocemos el fenómeno de los diferentes niveles de granularidad, parece que se exponen

tres mapas diferentes de la red de carreteras de la nación. Por supuesto, con mapas de carreteras
todo el mundo reconoce los diferentes niveles de detalle y hay escalas estándar para interpretar el
tamaño de la red descrita en cualquier nivel. El concepto abstracto de nivel de granularidad se
esconde detrás de las escalas de estos mapas distintos.
Para la medición del software, sólo hay un nivel de granularidad que es posible definir sin
ambigüedades. Es el nivel de granularidad en el cual se han identificado los distintos procesos
funcionales y se han definido sus movimientos de datos. Las mediciones deben hacerse a este nivel o
a escala de este nivel siempre que sea posible.

2.4.2 Aclaración del nivel de granularidad
Antes de continuar, es importante asegurar que no haya malentendidos sobre el significado de nivel
de granularidad en el método COSMIC. Tal como se define aquí, la ampliación de la descripción de
software de un nivel de granularidad “superior” a uno “inferior” implica revelar más detalles pero sin
modificar su alcance. Este proceso no debe confundirse con cualquiera de los siguientes.
• Detallar un artefacto que describa algún tipo de software a fin de revelar diferentes sub-conjuntos
de la funcionalidad entregada a los diferentes usuarios, por lo tanto, probablemente limitando la
funcionalidad que debe medirse
• Detallar un artefacto que describa algún tipo de software, o el propio software y, al mismo tiempo
descomponerlo a fin de revelar la estructura de sus componentes, sub-componentes, etc. (es
decir, revelar los diferentes niveles de descomposición - véase la sección 2.2.2). Detallar a
niveles más bajos la descomposición del software puede dar lugar (a partir de los efectos de la
medición) en sub-dividir el alcance global de la medición
• Mostrar la descripción de algún tipo de software a medida que avanza su ciclo de desarrollo, por
ejemplo, de los requisitos al el diseño lógico, diseño físico, etc. Cualquiera que sea la fase del
desarrollo de algún software, sólo estamos interesadas en los FUR para propósitos de medición.
El concepto de “nivel de granularidad” se aplica únicamente a los requisitos de los usuarios

funcionales de software (FUR). Otras formas de detallar software o sus diversas descripciones
también pueden ser muy importantes cuando se utilizan para comparar las mediciones de tamaño
funcional. Estos serán tratados en el documento “Temas Avanzados y Relacionados, v3.0”, en el
capítulo “Garantizando la Comparación de Mediciones de Tamaño”.
2.4.3 El nivel de granularidad estándar
El nivel de granularidad estándar para la medición es el “nivel de proceso funcional” y se define como
sigue:
Definición – Nivel de Granularidad de un Proceso funcional
Un nivel de granularidad de la descripción de aplicación software en el que los usuarios

funcionales:
a) Son humanos individuales o dispositivos de ingeniería o elementos de software (y
no grupos de estos) Y
b) detectan ocurrencias únicas de eventos a los que la aplicación software debe
responder (y no cualquier nivel en el cual se han definido grupos de eventos)
Nota 1: En la práctica, la documentación de software que contiene las necesidades de
los usuarios funcionales a menudo describe la funcionalidad en diferentes niveles de
granularidad, sobre todo cuando la documentación aún está en construcción.
Nota 2: Grupos de usuarios funcionales podrían ser, por ejemplo, un departamento
cuyos miembros manejan muchos tipos de procesos funcionales, o un panel de control
que tiene muchos tipos de instrumentos.
Nota 3: Un grupo de casos puede, por ejemplo, indicarse en una declaración de FUR
en un alto nivel de granularidad de un flujo de entrada a un sistema de software de
contabilidad, etiquetados como transacciones de venta, o de un flujo de entrada a un
sistema de software de aviónica, etiquetado como comandos del piloto.
Con esta definición, podemos ahora definir las siguientes reglas y una recomendación.
Reglas – Nivel de granularidad de un proceso funcional

a) La medición de tamaño funcional se deberá efectuar al nivel de granularidad del
proceso funcional

b) Cuando se necesita la medida del tamaño funcional de algunos FUR que no han
evolucionado aún a un nivel al cual se hayan identificado sus procesos funcionales
y no se hayan definido aún los detalles de todos sus movimientos de datos, las
mediciones deberían ser hechas a partir de la funcionalidad que ha sido definida, y
después escalada a un nivel de granularidad de procesos funcionales. (Ver el
documento “Aspectos Avanzados y Relacionados” para los métodos de “medición
aproximada, es decir, estimando el tamaño funcional de forma temprana en el
proceso de establecer los FUR).
Además de las reglas, COSMIC recomienda que el nivel de granularidad de un proceso funcional
deba ser el estándar al que se requiera medir el tamaño funcional cuando sea utilizado por los
proveedores para una evaluación comparativa de los servicios y de las herramientas de software
diseñados para sostener o utilizar las mediciones de tamaño funcional, por ejemplo para estimar el
esfuerzo de un proyecto.
Ejemplo: Funcionalidad en diferentes niveles de granularidad
El ejemplo, del dominio de software de gestión, será de un conocido sistema de comprar productos a través de Internet, que
llamaremos el sistema “Everest”. (El documento de “Temas Avanzados y Relacionados” contiene un ejemplo del dominio de
software de tiempo real.). La descripción que figura a continuación está muy simplificada para los propósitos de esta
ilustración de los niveles de granularidad. La descripción también cubre únicamente a las funcionalidades disponibles para
los usuarios del "Everest". Por lo tanto, excluye las funcionalidades que deben estar presentes para que el sistema pueda
completar la entrega de bienes a un cliente, tales como la funcionalidad disponible para el personal de "Everest",
proveedores de productos, anunciantes, el pago los proveedores de servicios, etc.
El alcance de la medición, por lo tanto, se define como las partes del sistema de aplicación "Everest" accesibles a los
clientes a través de Internet. Asumimos que el objetivo de la medición es determinar el tamaño funcional de la aplicación a
disposición los usuarios humanos (como usuarios funcionales). Al más alto “nivel 1” la definición de todos los requisitos
funcionales de los usuarios (RUF) del sistema de compra "Everest" sería una simple declaración como la siguiente.
“El sistema Everest deberá permitir a los clientes informarse sobre, seleccionar, pedir, pagar y obtener la entrega de
cualquier elemento de la gama de productos Everest, incluidos los productos disponibles desde terceros proveedores.”
Detallando esta declaración de más alto nivel más nos encontramos con que en el próximo nivel inferior 2, el sistema
consiste en cuatro sub-sistemas, tal y como se muestra en Fig. 2.4.3.1.

Everest
Level 1 Ordering
System
Enquiry/ Checkout/ Order Account

Level 2 Order Payment Follow-up Maintenance
Sub-system Sub-system Sub-system System
Enquire on Maintain
Review, maintain
Level 3 (not analyzed) current (n/a) customer details (n/a)
confirm order (n/a)
order process Sub-sub-system
Sub-sub-system
Select delivery/ Enquire on Maintain

packaging options historic payment method
Sub-sub-system orders process Sub-sub-system
Returned goods
Pay for order
Sub-sub-system
Sub-sub-system
Display & e-mail

order confirmation
Sub-sub-system
Register new Add new

customer (not analyzed) means-of-payment
process process
Level 4
Pay for order Delete existing

process means-of-payment
process
Figura 2.4.3.1 – Análisis parcial del Sistema Everest con cuatro niveles de análisis
Los cuatro sub-sistemas son los siguientes:

• El sub-sistema de la Solicitud/Orden que permite a un cliente encontrar cualquier producto en la base de datos de
Everest, así como su precio y disponibilidad y añadir cualquier producto seleccionado a una cesta de compra. Este
sub-sistema también promueve las ventas sugiriendo las ofertas especiales, que ofrece comentarios de los elementos
seleccionados y permite preguntas generales como las condiciones de entrega, etc. Se trata de un sub-sistema muy
complejo y no es analizado en más detalle por debajo del nivel 2 a efectos del presente ejemplo.
• El sub-sistema de la compra/pago que permite a un cliente comprometerse con el pedido y pagar por la mercancía de
la cesta.
• El sub-sistema del Seguimiento del pedido que permite a un cliente a preguntar hasta qué punto un pedido existente ha
avanzado en el proceso de entrega, para mantener su pedido (por ejemplo, cambiar la dirección de entrega) y para
devolver bienes no satisfactorios.
• El sub-sistema del Mantenimiento de la cuenta que permite a un cliente existente, mantener diversos detalles de su
cuenta tales como domicilio, medios de pago, etc.
La figura 2.4.3.1 también muestra algún detalle que se pone de manifiesto cuando detallamos los otros dos niveles del sub-
sistema de La Compra/Pago, del Seguimiento del Pedido y el subsistema de Mantenimiento de la Cuenta. En este proceso,
es importante señalar que:
• no hemos cambiado el alcance del sistema de la aplicación que habrá de medirse, y
• todos los niveles de la descripción del sistema de software "Everest" muestran la funcionalidad disponible para los
clientes (como los usuarios funcionales). Un cliente puede ver la funcionalidad del sistema en todos estos los niveles
de análisis
La figura 2.4.3.1 revela también que cuando detallamos niveles más bajos de este análisis de los tres sub-sistemas, nos
encontramos con los distintos procesos funcionales en el nivel 3 (para dos consultas del sub-sistema de Seguimiento del
Pedido) y en el nivel 4 para los otros dos sub-sistemas. Este ejemplo demuestra, por tanto, que cuando alguna
funcionalidad es analizada en un enfoque de arriba abajo, no se puede suponer que la funcionalidad mostrada en un nivel
en un diagrama se corresponde siempre con el mismo nivel de granularidad tal y como este concepto es definido en el
método COSMIC. (Esta definición exige que a cualquier nivel de granularidad la funcionalidad esté a un “nivel comparable
de detalle”).

Por otra parte, otros analistas podrían dibujar el diagrama de forma diferente, mostrando otras agrupaciones de
funcionalidades en cada nivel del diagrama, ya que no hay una única forma correcta de analizar la funcionalidad de un
sistema.
Teniendo en cuenta estas variaciones que inevitablemente ocurren en la práctica, un medidor debe examinar
cuidadosamente los diversos niveles de un diagrama de análisis para encontrar los procesos funcionales que deben
medirse. En caso de que en la práctica esto no sea posible, por ejemplo debido a que el análisis aún no ha alcanzado el
nivel donde todos los procesos funcionales se han revelado, debe aplicarse la regla (b) descrita más arriba. Para ilustrar
esto, vamos a examinar el caso del sub-subsistema Mantener Detalles del Cliente (véase la figura 2.4.3.1), en la primera
rama de el sub-sistema de Mantenimiento de la Cuenta.
Para un medidor con experiencia, la palabra mantener casi siempre sugiere un grupo de casos y por lo tanto, un grupo de
procesos funcionales. Por lo tanto, podemos asumir con seguridad que este sub-subsistema de mantener debe estar
integrado por tres procesos funcionales, es decir, base de datos de detalles del cliente, actualización de los detalles del
cliente y eliminar el cliente. (Evidentemente el proceso de creación del cliente también existe pero esto ocurre en otra rama
del sistema, que es cuando un cliente hace un pedido por primera vez. Está fuera del ámbito de aplicación de este ejemplo).
Un medidor con experiencia debe poder estimar un tamaño de este sub-subsistema en unidades PFC tomando el supuesto
número de procesos funcionales (tres en este caso) y multiplicando este número por el tamaño medio de un proceso
funcional. Este tamaño medio se obtendría calibrando en otras partes de este sistema o en otros sistemas comparables.
Ejemplos de este proceso de calibración se dan en el documento de “Temas Avanzados y Relacionados” que en la
aproximación de mediciones contiene también otras aproximaciones al tamaño aproximado.
Evidentemente, estos métodos de aproximación tienen sus limitaciones. Si aplicamos este enfoque al nivel 1 de la
declaración FUR de la forma arriba señalada (El sistema "Everest" deberá permitir a los clientes informarse sobre,
seleccionar, comprar, pagar y obtener la entrega de cualquier elemento de la gama de productos Everest….), podríamos
identificar unos procesos funcionales. Pero un análisis más detallado podría revelar que el verdadero número de procesos
funcionales de este complejo sistema debe ser mucho mayor. Esa es la razón por la que tamaños funcionales aparentan
aumentar a medida que se establecen más detalles en los requisitos, incluso sin cambios en el alcance de la aplicación.
Estos métodos de aproximación, por lo tanto, deben ser utilizados con sumo cuidado a los altos niveles de granularidad,
cuando está disponible muy poca información.
El documento de “Temas Avanzados y Relacionados” da un tipo diferente de ejemplo de medición en

diversos niveles de granularidad, es el caso de un tipo de software que es parte de una arquitectura
de software de telecomunicaciones. Este ejemplo es más complejo que el “Everest” ya que los
usuarios funcionales de parte de la arquitectura que se está midiendo son el resto de las otras partes
de software de la misma arquitectura. Este ejemplo, por lo tanto, también se ocupa de diversos
niveles de descomposición del software que se está midiendo y de sus usuarios funcionales.
2.5 Observaciones finales sobre la Fase de Estrategia de la de Medición
Si se consideran cuidadosamente los cuatro elementos del proceso de estrategia de medición antes
de empezar una medición se debería asegurar que el tamaño resultante pueda ser interpretado
correctamente. Los cuatro elementos son los siguientes:
a) establecer el propósito de la medición
b) definir el alcance global de la aplicación 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 aplicación software medida
d) establecer el nivel de granularidad de los artefactos de software a medir y cómo, si es necesario,
llevar las medidas a al estándar de nivel de granularidad de proceso funcional
Pueden ser necesarias algunas repeticiones de los pasos (b), (c) y (d) cuando están evolucionando
los requisitos y los nuevos datos indican la necesidad de perfeccionar la definición del alcance.
La gran mayoría de las mediciones de tamaño funcional se llevan a cabo con una finalidad que está
relacionada de algún modo con el esfuerzo de desarrollo, por ejemplo, para la medición del
rendimiento de los desarrolladores, o para la estimación del proyecto. En estas situaciones, la
definición de la estrategia de medición debe ser muy sencilla. El propósito y el alcance son
generalmente fáciles de definir, los usuarios son los usuarios funcionales para los cuales el
desarrollador debe proporcionar la funcionalidad y el nivel de granularidad en que se requieren las
mediciones es el nivel en el cual los usuarios funcionales detectan eventos individuales.
Sin embargo, no todas las mediciones se ajustan a esta pauta común, por lo que la estrategia de
medición debe ser definida para en cada situación.

3
FASE DE REPRESENTACIÓN
Este capítulo presenta las reglas y el método para el proceso de representación. El método general
para la representación del software en el Modelo COSMIC Genérico del Software se resume en la
figura 3.0.
COSMIC MAPPING PHASE
Chapter 2
PURPOSE, SCOPE,
FUNCTIONAL USERS &
LEVEL OF GRANULARITY
of the piece of software
to be measured
Section 3.1
Functional User
Requirements
IDENTIFY
in the artefacts FUNCTIONAL
of the software PROCESSES
to be measured Section 3.2
IDENTIFY FUR in the form

DATA of the COSMIC
GROUPS Generic Software
Section 3.3 (*) Model
IDENTIFY
DATA
ATTRIBUTES
(*): This step is not a mandatory part of the
COSMIC method.
Figure 3.0 – Método General del proceso de mapeo COSMIC
Cada paso de este método es el tema de una sección específica (indicada en el título de cada paso
de la figura 3) donde se presentan las definiciones y las reglas, junto con algunos principios que
sirven de guía y ejemplos.
El método general resumido en la figura 3 de arriba se ha diseñado para ser aplicado a una muy
amplia gama de artefactos de software. Un proceso más sistemático y detallado proporcionaría reglas
precisas de representación para una mayor cantidad de artefactos altamente específicos, por lo que
se disminuiría el nivel de ambigüedad al generar el Modelo Genérico COSMIC de Software. Un
proceso así sería, por definición, altamente dependiente de la naturaleza de los artefactos, lo que
depende de la metodología de ingeniería del software que se use en cada organización.
El documento “Guía para Medir Aplicaciones de Gestión utilizando COSMIC” sirve de guía en la
representación desde varios datos de análisis y métodos de obtención de requisitos usados en el
dominio de las aplicaciones de gestión a los conceptos del método COSMIC.

3.1 Aplicación del Modelo Genérico COSMIC de software
Principio – Aplicando el Modelo Genérico COSMIC de Software
El Modelo Genérico 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
medición.
“Aplicar el Modelo Genérico COSMIC de Software” significa identificar el conjunto de
eventos desencadenadores detectados por cada (tipo de) usuario funcional identificado
en los FUR para, a continuación, identificar los correspondientes procesos funcionales,
objetos de interés, grupos de datos y los movimientos de datos que deben ser
proporcionados para responder a esos eventos.
Las figuras 3.1.1 y 3.1.2 de abajo ilustran respectivamente, la aplicación del principio (g) del Modelo
de Contexto del Software y los principios del Modelo Genérico del Software a una aplicación de
gestión y a un típico software empotrado de tiempo real.
Mientras que las figuras 2.2.3.1 y 2.2.3.2 de arriba mostraban visiones físicas reales de las
arquitecturas a capas del software, las figuras 3.3.1 y 3.1.2 muestran una visión lógica de las
relaciones de varios conceptos definidos en los modelos COSMIC. En esta visión lógica los usuarios
funcionales interaccionan con el software que va a ser medido a través de una frontera vía
movimientos de datos de Entrada y de Salida. El software mueve datos hacia y desde los almacenes
persistentes vía movimientos de datos de Escritura y Lectura respectivamente. En estas visiones
lógicas se ignora todo el hardware y software que se necesita para permitir que estos intercambios
tengan lugar entre el software que se está midiendo, sus usuarios funcionales y el almacenamiento
persistente.
Boundary Boundary
Entries X E
Human Application A ‘peer’
functional being application
user (s) measured functional user The
Exits E X
application
Reads Writes
layer
Persistent
storage
X E Indicates a message that is issued as an Exit data movement,

crosses a boundary, and is received as an Entry data movement
Figure 3.1.1 – Una aplicación de gestión con seres humanos y otras aplicaciones ‘semejantes’, como sus
usuarios funcionales (vista lógica)

Boundary
Entries
Hardware
engineered Application
device being
Functional measured The
User (s) Exits ‘Application
Reads Writes Layer’
Persistent
Storage
Figura 3.1.2 – Una aplicación en tiempo real con varios dispositivos hardware integrados como usuarios
funcionales (vista lógica)
3.2 Identificación de los procesos funcionales
Este paso consiste en identificar el conjunto de procesos funcionales de la aplicación software que se
va a medir a partir de sus Requisitos Funcionales de Usuario.
3.2.1 Definiciones
Definición – 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.
Nota: Además de informar al componente de software de que el evento ha ocurrido, la

“entrada desencadenante” puede incluir datos sobre el objeto de interés asociado al
evento.
Definición – Evento desencadenante
Un evento (algo que ocurre) que causa un usuario funcional del componente de
software para iniciar (“trigger”) uno o más procesos funcionales. En un conjunto de
requisitos funcionales de usuario, cada evento que causa que un usuario funcional
desencadene un proceso funcional:
• no puede ser sub-dividido para ese conjunto de FUR, y
• ha ocurrido o no ha ocurrido
Nota: El reloj y los eventos de tiempo pueden ser eventos desencadenantes.

La relación entre un evento desencadenante, el usuario funcional y el movimiento de datos de
Entrada que desencadena un proceso funcional se esquematiza en la figura 3.2.1 de abajo. La
interpretación de este diagrama es: un evento es detectado por un usuario funcional, y el usuario
funcional desencadena el proceso funcional.
Functional
process
Triggering is sensed Functional Triggering

event by user Entry
Boundary
Figura 3.2.1 – Relación entre un evento disparador, un usuario funcional y un proceso funcional
La Entrada desencadenante es normalmente un mensaje positivo e inequívoco que informa al

software de que el usuario funcional ha identificado un evento desencadenante. La Entrada
desencadenante usualmente incluye también datos sobre un objeto de interés asociado con el
evento. Después de que se ha recibido la Entrada desencadenante, se puede requerir un proceso
funcional para recibir y procesar otras Entradas que describen otros objetos de interés.
Si un usuario funcional envía datos incorrectos, por ejemplo porque un sensor no funciona o una
orden introducida por un humano tiene errores, es habitualmente tarea del proceso funcional
determinar si un evento realmente ocurrió y/o si los datos introducidos son realmente válidos y cómo
responder.
3.2.2 La aproximación para identificar procesos funcionales
La aproximación para identificar procesos funcionales depende de los artefactos de software que
están disponibles para el medidor, los cuales dependen del momento del ciclo de vida del software
cuando se requiere la medida y de los métodos de análisis, diseño y desarrollo del software en uso.
Puesto que éstos últimos varían enormemente, incluso dentro del un dominio de software dado, está
fuera del alcance de este Manual de Medida el proporcionar uno o más procesos generales para
identificar procesos funcionales.
La “Guía para medición de aplicaciones de gestión software usando COSMIC”, sección 4.4 da más
reglas y ejemplos sobre cómo identificar y distinguir procesos funcionales en el dominio de las
aplicaciones software de gestión.
El consejo general más 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 más 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 transición a la que el software se debe enfrentar se corresponde con
un evento.
Utilice las siguientes reglas para comprobar que los procesos funcionales candidatos han sido
adecuadamente identificados.
Reglas – Proceso funcional

a) En proceso funcional se derivará de al menos un Requisito Funcional de Usuario
identificable dentro del alcance acordado
b) Un proceso funcional se llevará a cabo cuando ocurra un evento desencadenante

identificable
c) Un evento específico puede desencadenar uno o más procesos funcionales que se
ejecutan en paralelo. Un proceso funcional puede ser desencadenado por más de
un evento
d) Un proceso funcional constará de al menos dos movimientos de datos, una Entrada
más una Salida o una Escritura
e) Un proceso funcional pertenecerá enteramente una, y solo una, capa o estrato del
software
f) En el contexto de software a tiempo real, un proceso funcional se considerará
terminado cuando entre en un estado de espera auto inducido (por ejemplo el
proceso funcional ha hecho todo lo requerido en respuesta al evento
desencadenante y espera hasta recibir la próxima Entrada desencadenante)
g) Un proceso funcional se identificará incluso si sus FUR permiten que el proceso
funcional pueda ocurrir con diferentes sub-series de su máximo número de atributos
de datos de entrada, e incluso aunque dichas variaciones y/o valores de datos de
entrada distintos puedan dar lugar a diferentes rutas de procesamiento a través del
proceso funcional.
h) Se deberían distinguir Eventos diferentes y por tanto Procesos Funcionales
diferentes en los siguientes casos:
• Cuando las decisiones resultan en eventos separados que están desconectados
en el tiempo (por ejemplo meter datos de una orden hoy y después confirmar
que se acepta la orden, requiriendo una decisión separada, debería ser
considerado como indicativo de procesos funcionales separados)
• Cuando las responsabilidades de actividades están separadas (por ejemplo en
un sistema personal donde la responsabilidad para mantener datos personales
básicos está separada de la responsabilidad del mantenimiento de datos de
nóminas, indicando procesos funcionales separados; o para un paquete de
software puesto en marcha donde hay funcionalidad disponible para un
administrador del sistema para mantener los parámetros del paquete, lo que está
separado de la funcionalidad disponible para el usuario funcional “habitual”.
3.2.3 Eventos disparadores y procesos funcionales en el ámbito de aplicaciones de negocio
a) Eventos desencadenantes de una aplicación de negocio on-line normalmente ocurren en el

mundo real de los usuarios funcionales humanos de la aplicación. El usuario humano comunica la
incidencia de un evento a un proceso funcional metiendo datos sobre el evento
Ejemplo 1: En una compañía, se recibe una orden (evento desencadenante), causando que un empleado (usuario
funcional) meta los datos de la orden (Entrada desencadenante que comunica datos sobre el objeto de interés “orden”),
como el primer movimiento de datos del proceso funcional “entrada de orden”
b) Algunas veces, para una aplicación A podría haber una aplicación par B que necesite enviar datos
a u obtener datos de la aplicación A. En este caso, si la aplicación B desencadena un proceso
funcional cuando necesita enviar datos u obtener datos de la aplicación A, entonces la aplicación
B es un usuario funcional de la aplicación A
Ejemplo 2: Supóngase que al recibir una orden en el ejemplo a) a la aplicación de la orden se la requiere que envíe
detalles del cliente a una aplicación central de registro de clientes, lo cual se está midiendo. Ahora la aplicación de la
orden se ha convertido en un usuario funcional de la aplicación central. La aplicación de la orden detecta el evento de
recepción de los datos del cliente y desencadena un proceso funcional en la aplicación central del registro de clientes
para almacenar estos datos, enviando datos sobre el objeto de interés “cliente” como una Entrada desencadenante a la
aplicación central.
c) No hay diferencia en el principio para el análisis de un proceso funcional si se requiere un

procesamiento on-line o un tratamiento por lotes. El procesamiento durante la noche es una
decisión de puesta en marcha técnica, 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 más procesos funcionales, cada uno de los cuales debería 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.
Ejemplo 3: Supóngase que las órdenes del ejemplo de a) se meten on-line pero son almacenadas para un procesado
por lotes automático durante la noche. El usuario funcional es todavía el humano que metió las órdenes on-line; la
Entrada desencadenante son todavía los datos de la orden. Hay un proceso funcional por entrada y procesado de las
órdenes.
d) Las señales periódicas de un reloj (ticks) pueden físicamente desencadenar un proceso funcional.
Ejemplo 4: Supóngase un FUR para un proceso por lotes a final de año para informar de los resultados del negocio
durante el año y para reajustar puestos para comienzos del año que viene. Físicamente, el tick de fin de año de un reloj
originado por el sistema operativo ocasiona que el flujo por lote comience, consistiendo en uno o más procesos
funcionales. Estos procesos funcionales del flujo que usan datos de entrada en el flujo deberían ser analizados de
modo normal (por ejemplo los datos de entrada para cualquier proceso funcional constan de una o más Entradas, la
primera de las cuales es la Entrada desencadenante de dicho proceso).
Sin embargo, se asúmase que hay un proceso funcional particular en el flujo que no requiere ningún dato de entrada
para producir sus series de informes. Físicamente, el usuario funcional (humano) ha delegado en el sistema operativo
la tarea de desencadenar este proceso funcional. Puesto que todos los procesos funcionales deben tener una Entrada
desencadenante, podríamos considerar que el tick de fin de año del reloj que comenzó el flujo por lotes desempeña
este papel para este proceso. El proceso funcional podría entonces necesitar diferentes Lecturas y muchas Salidas
para producir sus informes. Lógicamente, el análisis de este ejemplo no es diferente si el usuario funcional inicia la
producción de uno o más informes vía un clic del ratón en un icono del menú on-line, en vez de delegar la producción
del informe al sistema operativo vía flujo por lotes.
e) Un solo evento puede desencadenar uno o más procesos funcionales que se ejecuten
independientemente.
Ejemplo 5: Un tick de reloj de fin de semana produce que comience la generación de informes y el proceso de revisión
de la caducidad de los límites de tiempo en un sistema automático.
f) Un solo proceso funcional puede ser desencadenado por más de un tipo de evento
desencadenante.
Ejemplo 6: En un sistema bancario, un extracto de cuenta puede ser desencadenado por un proceso por lotes de fin de
mes pero también porque un cliente específico lo haya pedido.
Para diversos ejemplos de cómo distinguir eventos desencadenantes y procesos funcionales en flujos
por lotes, ver la “Guía de Medición de Aplicaciones de Gestión utilizando COSMIC” en la sección
4.6.3.
3.2.4 Ejemplos en el dominio de aplicaciones en tiempo real.
a) Un evento desencadenante es detectado típicamente por un sensor
Ejemplo 1: Cuando la temperatura alcanza un valor determinado (evento desencadenante), se produce que un sensor
(usuario funcional) envíe una señal (movimiento de datos de Entrada desencadenante) para encender una luz de
alarma (proceso funcional).
Ejemplo 2: Un avión militar tiene un sensor que detecta el evento “un misil se acerca”. El sensor es un usuario funcional
del software integrado que debe responder a la amenaza. Para este software, solo cuando el sensor detecta algo
ocurre un evento, y es el sensor (el usuario funcional) el que pone en funcionamiento al software enviándole un
mensaje (Entrada desencadenante) diciendo por ejemplo: “el sensor 2 ha detectado un misil”, además quizás también
envía un flujo de datos sobre la velocidad del misil que se acerca y sus coordenadas. El misil es el objeto de interés.

b) Señales periódicas de una reloj (ticks de reloj) pueden desencadenar un proceso funcional
Ejemplo 3: En algún software de control de procesos en tiempo real, un tick (evento desencadenante) de un reloj
(usuario funcional) produce que el reloj envíe una señal (Entrada desencadenante), un mensaje de un bit que le dice al
proceso funcional que repita su ciclo de control normal. El proceso funcional entonces lee varios sensores, recibiendo
datos sobe objetos de interés, y lleva a cabo cualquier acción necesaria. No hay otros datos que acompañen el tick del
reloj.
c) Un solo evento puede desencadenar uno o más procesos funcionales que se ejecuten
independientemente en paralelo
Ejemplo 4 Un situación de emergencia detectada en una central nuclear puede desencadenar procesos funcionales
independientes en zonas diferentes de la central para bajar las barreras de control, accionar el enfriamiento de
emergencia, cerrar válvulas, hacer sonar las alarmas para alertar a los operarios, etc.
d) Un solo proceso funcional puede ser desencadenado por más de un evento desencadenante.
Ejemplo 5: La retracción en las ruedas de un avión puede ser desencadenada por el detector “sin peso en el suelo” o
por una orden del piloto.
3.2.5 Más sobre procesos funcionales separados
El software diferencia eventos y proporciona los correspondientes procesos funcionales dependiendo

solo de sus FUR. Al medir el software puede a veces ser difícil decidir qué eventos separados se
requiere que el software reconozca. Este es especialmente el caso cuando los FUR originales no
están ya disponibles y cuando, por ejemplo, los que fabrican el software haya visto que es económico
combinar varios requisitos. Podría ayudar con el análisis examinar la organización de los datos de
entrada (ver abajo) o examinar los menús de algún software instalado para ayudar a distinguir los
eventos separados a los que el software debe responder y los correspondientes procesos
funcionales.
Ejemplo 1: Cuando hay un requisito de un usuario funcional para reducción de impuestos por un hijo adicional y también por
“créditos por tasas de trabajo” para los que tienen un sueldo bajo, estos son requisitos a los que el software debe responder
como dos eventos separados en el mundo de los usuarios funcionales humanos. Por tanto, debería haber dos procesos
funcionales, aunque solo se haya utilizado un formulario de impuestos para recoger los datos en ambos casos.
Ejemplo 2: Si el salario en un ejemplo (para una persona) excede el límite por créditos por tasas de trabajo en reducción de
impuestos y en otro ejemplo (para otra persona) no lo excede, esta diferencia no da lugar a dos procesos funcionales
separados, pero indica dos condiciones separadas de las que encargarse en el único proceso funcional.
Ejemplo 3: Como ejemplo de la regla (g), si ocurre una incidencia específica que desencadena la Entrada de un grupo de
datos que consta de atributos de datos A, B y C, y los FUR permiten que otra incidencia del mismo evento desencadene
una Entrada de un grupo de datos que tiene valores para los atributos A y B únicamente, esto no resulta en identificar dos
procesos funcionales. Solo son identificados una Entrada y un proceso funcional, moviendo y manipulando atributos de
datos A, B y C.
Una vez identificados, cada proceso funcional puede ser registrado en una línea individual, bajo la
capa o estrato adecuado o bajo el componente semejante, en la matriz del Modelo Genérico de
Software (apéndice A), bajo la correspondiente etiqueta.
3.2.6 El proceso funcional de componentes semejantes
Cuando el propósito de la medición es medir separadamente el tamaño de cada componente

semejante, debe ser definido un alcance de medición diferente para cada componente. En un caso
como ese, la definición del tamaño del proceso funcional de cada componente sigue las normas ya
descritas.

Del proceso de cada medición (… definir el alcance, luego los usuarios funcionales y la frontera,
etc.…), se deduce que si una parte del software consta de dos o más componentes similares, no
puede haber ninguna superposición del alcance de medición de cada componente. El alcance de
medición para cada componente debe definir un conjunto completo de procesos funcionales. Por
ejemplo, no puede haber un proceso funcional con una parte en un alcance y otra parte en otro. De la
misma manera, los procesos funcionales dentro del alcance de medición de un componente no saben
de los procesos funcionales en el alcance de otro componente, incluso aunque se produzca el
intercambio de mensajes entre dos componentes.
El usuario o usuarios funcionales de cada componente se determinan examinando dónde suceden los
eventos que disparan los procesos funcionales del componente que está siendo examinado (la
activación de eventos sólo puede ocurrir en el mundo de un usuario funcional).
La figura 4.1.8.2 ilustra el proceso funcional de dos componentes semejantes y los movimientos de
datos que intercambian.
3.3 Identificación objetos de interés y grupos de datos
3.3.1 Definiciones y principios

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 gestión, es
habitualmente útil identificar los objetos de interés y probablemente también sus atributos. Los grupos
de datos se mueven a “movimientos de datos”, los cuales serán identificados en el capítulo siguiente.
Definición – Objeto de interés
Cualquier “cosa” que sea identificada desde el punto de vista de los requisitos del
usuario funcional. Puede ser cualquier cosa física, como también cualquier objeto
conceptual o parte de un objeto conceptual en el mundo del usuario funcional sobre el
que al software se le requiere que procese y/o almacene datos.
Nota: En el método COSMIC, el término “objeto de interés” se usa para evitar términos
relacionados con métodos específicos de ingeniería del software. El término no implica
“objetos” en el sentido usado en los métodos Orientados a Objetos.
Definición – Grupo de datos
Un grupo de datos es un conjunto único, no vacío, no ordenado y no redundante de

atributos de datos donde cada atributo de datos incluido describe un aspecto
complementario del mismo objeto de interés
Definición – Almacén persistente
Un almacén persistente es un almacén que permite a un proceso funcional almacenar

un grupo de datos más 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.
Nota 1: En el modelo COSMIC, debido a que el almacén persistente está en la parte del
software de la frontera, no es considerado como un usuario del software.
Nota 2: Un ejemplo de “otros procesos” sería la manufactura de memoria de solo
lectura.

Una vez identificado, cada grupo de datos candidato debe cumplir con los siguientes principios:
Principios – grupo de datos

a) Cada grupo de datos identificado será único y distinguible a través de su colección
única de atributos de datos
b) Cada grupo de datos estará directamente relacionado con un objeto de interés en
los requisitos funcionales de usuario
c) Un grupo de datos será materializado dentro del ordenador que ejecuta el software
Una vez identificados, cada grupo de datos puede ser registrado en una columna individual en la
matriz del Modelo Genérico de Software (apéndice A), bajo la correspondiente etiqueta.
3.3.2 Sobre la materialización de un grupo de datos
En la práctica, la materialización de un grupo de datos puede tomar muchas formas, por ejemplo:
a) Como una estructura física grabada en un dispositivo de almacenamiento continuo (archivo, tabla
de base de datos, memoria ROM, etc.)
b) Como una estructura física en la memoria volátil del ordenador (estructura de datos asignada
dinámicamente o a través un bloque pre-asignado de espacio de memoria)
c) Como la presentación agrupada de atributos de datos relacionados funcionalmente en un
dispositivo input/output (pantalla de visualización, informe impreso, panel de control de
visualización, etc.)
d) Como un mensaje transmitido entre un dispositivo y un ordenador, o sobre una red, etc.
3.3.3 Sobre la identificación de objetos de interés y grupos de datos
Las definiciones y los principios de los objetos de interés y de los grupos de datos son
intencionalmente amplios con el objetivo de que se puedan aplicar al rango más amplio posible de
software. Esta cualidad hace que algunas veces resulte difícil de aplicar la definición y los principios
cuando se mide una parte específica del software. Por tanto, los casos siguientes y los ejemplos se
han diseñado para ayudar en la aplicación de los principios a casos específicos.
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 almacén
persistente, es de una importancia crítica decidir si todos los atributos comunican datos sobre un
único “objeto de interés”, ya que es éste último el que determina el número de “grupos de datos”
separados tal y como los define el método COSMIC. Por ejemplo, si los atributos de datos que van a
ser los datos de entrada de un proceso funcional son atributos de tres objetos de interés separados,
entonces necesitamos identificar tres movimientos de datos de Entrada separados.
Objetos de interés y grupos de datos en el dominio de las aplicaciones de gestión
Ejemplo 1: En el dominio de software de aplicaciones de gestión, un objeto de interés podría ser “empleado” (físico) o
“pedido” (conceptual), asumiendo que se requiere que el software almacene datos sobre empleados o pedidos. En el caso
de pedidos, normalmente desde el FUR de pedidos multilínea se identifican dos objetos de interés: “pedido” y “línea de
pedido”. Los grupos de datos correspondientes podrían llamarse “datos de pedidos” o “línea de datos de pedidos”.
Los grupos de datos se forman cuando sea que haya una consulta ad hoc que pida datos sobre una
“cosa” que no se tiene en el almacén persistente, pero que se puede derivar de datos que están en el
almacén persistente. El movimiento de datos de Entrada en una consulta ad hoc (los parámetros de
selección para derivar los datos requeridos) y el movimiento de datos de Salida (que contienen los
atributos deseados), ambos mueven grupos de datos sobre dicha “cosa”. Estos son grupos de datos
transitorios que no sobreviven a la ejecución del proceso funcional. Son grupos de datos válidos
porque cruzan el límite o frontera entre el software y su usuario o usuarios.

Ejemplo 2: Dada un consulta ad hoc contra una base de datos personal para extraer una lista de nombres de todos los
empleados de más de 35 años. La Entrada mueve un grupo de datos que contiene los parámetros de la selección. La Salida
mueve un grupo de datos que contiene solo el atributo “nombre”; el objeto de interés (o “cosa”) es “todos los empleados de
más de 35 años”. Es importante al grabar el proceso funcional nombrar claramente un grupo de datos transitorios en
relación con su objeto de interés, mejor que relacionarlo con el objeto de interés del cual se deriva el resultado de la
consulta ad hoc.
Para una discusión detallada sobre métodos de análisis de datos para determinar objetos de interés y
grupos de datos separados, el lector puede ir a “Guía para Medir Aplicaciones de Gestión utilizando
COSMIC”.
Objetos de interés y grupos de datos en el dominio de las aplicaciones en tiempo real.
Ejemplo 3: Movimientos de datos que son Entradas desde dispositivos físicos típicamente contienen datos sobre el estado
de un solo objeto de interés, tales como si un válvula está abierta o cerrada, o indican un tiempo en el que datos a corto
plazo, almacenamiento volátil es válido o inválido, o contienen datos que indican que ha ocurrido un evento crítico y qué
causa una interrupción. De un modo similar un comando de Salida para encender o apagar una lámpara de aviso comunica
datos sobre un solo objeto de interés.
Ejemplo 4: Un intercambio de mensajes puede recibir un grupo de datos de mensajes tales como una Entrada y guiarlo
adelante sin cambios como una Salida, como requisito de una parte del software en particular. Los atributos del grupo de
datos de mensajes podrían ser, por ejemplo, “el que lo envía, recipiente, ruta-código y mensaje-contenido; el objeto de
interés del mensaje es “mensaje”.
Ejemplo 5: Una estructura de datos habitual, representando objetos de interés que se mencionan en los requisitos
funcionales de usuario, que puede ser mantenida por procesos funcionales, y que es accesible para la mayoría de procesos
funcionales encontrados en el software medido.
Ejemplo 6: Una estructura de datos de referencia, representando gráficos o tablas de valores encontrados en los requisitos
funcionales de usuario, los cuales están en memoria permanente (memoria ROM por ejemplo) y accesible para la mayoría
de procesos funcionales encontrados en el software medido.
Ejemplo 7: Archivos, comúnmente designados como “archivos planos”, representando objetos de interés mencionados en
los requisitos funcionales de usuario, los cuales se mantienen en un dispositivo de almacenamiento continuo.
3.3.4 Grupos de datos o datos que son candidatos a movimientos de datos.
Datos cualesquiera que aparezca en pantallas de entrada o salida o en informes y que no están
relacionados con un objeto de interés para un usuario funcional no deberían ser identificados
indicando un movimiento de datos, por tanto no deberían medirse. Los ejemplos incluyen:
Ejemplo 1: Datos generales de la aplicación tales como encabezamientos y pies de página (nombre de la compañía,
nombre de la aplicación, fecha del sistema, etc.) que aparecen en todas las pantallas.
Ejemplo 2: Comandos de control (un concepto definido solo en el ámbito de aplicaciones de gestión) que permite a un
usuario funcional controlar su uso del software más que mover datos, por ejemplo los comandos de página arriba/abajo,
pulsar “OK” para admitir un mensaje de error, etc. - ver la sección 4.1.10 más adelante.
El modelo Genérico COSMIC de Software asume que toda manipulación de datos dentro de un
proceso funcional está asociada con unos de los cuatro tipos de movimientos de datos- ver sección
4.1.6. Por tanto ningún movimiento o manipulación de datos dentro de un proceso funcional puede
ser identificado como candidato para movimiento de datos junto con las Entradas, Salidas, Lecturas y
Escrituras. (Para ver ejemplos de manipulación y movimientos de datos que puedan ser mal
interpretados como movimientos de datos ver sección 4.1.4, principio c) para Lecturas, y sección
4.1.5 principio d) para Escrituras.

3.3.5 El usuario funcional como objeto de interés
En muchos casos simples de software en tiempo real como el descrito en el primer punto del caso 2
de la sección 3.3.3 de arriba, el dispositivo físico -un usuario funcionales indistinguible del objeto de
interés del movimiento de datos que genera o recibe. En dichos casos añade poco valor al
documento un objeto de interés como si fuera algo separado del usuario funcional. El punto
importante es usar estos conceptos, cuando sirvan de ayuda, para distinguir los diferentes grupos de
datos y en consecuencia movimientos de datos separados.
Ejemplo: Supóngase un sensor de temperatura “A” que, cuando es preguntado por un proceso funcional, envía la
temperatura actual al proceso. El usuario funcional es el sensor A: el nombre del mensaje de Entrada podría ser
“temperatura actual en A”; el objeto de interés de este mensaje podría también ser considerado como “sensor A”.
Teóricamente, el objeto de interés no es “sensor A”, sino “el material u objeto cuya temperatura está siendo detectada por el
sensor A”. En la práctica sin embargo añaden poco valor al documento estas finas distinciones y puede que no merezca la
pena identificar el objeto de interés separadamente.
3.4 Identificación de los atributos de datos (opcional)
Esta sección discute la identificación de atributos de datos referenciados por la parte del software que
se va a medir. En esta versión del método 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 interés. Los atributos de datos pueden también ser
identificados si una sub-unidad de la medida del tamaño es requerida, como se presenta en la
sección 4.5 “Extendiendo el método de medida COSMIC”.
3.4.1 Definición
Definición – Atributo de datos
Un atributo de datos es la pieza más pequeña de información, 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 gestión 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 lógico.
Ejemplo 2: Atributos de datos en el contexto de las aplicaciones a tiempo real del software como por ejemplo atributos de
datos de una señal recibida de un sensor y atributos de datos de un mensaje en transmisión.
3.4.2 Sobre la asociación de atributos de datos y grupos de datos
En teoría, 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 interés. En la práctica,
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
gestión.

4
FASE DE MEDICIÓN
Este capítulo presenta las reglas y el método para la fase de medición del proceso de medición
COSMIC. El método general para medir una aplicación software cuando sus Requisitos Funcionales
de Usuario se han expresado en términos del Modelo Genérico COSMIC de Software se resume en
el gráfico 4.0 debajo.
COSMIC MEASUREMENT PHASE
Section 4.1
FUR in the form
of the COSMIC IDENTIFY
Generic Software DATA MOVEMENTS
Model
Section 4.2
APPLY
MEASUREMENT
FUNCTION
All
NO
functional processes
measured ?
YES
Section 4.3
Functional Size
AGREGATE recorded information
of the measured
MEASUREMENT software
RESULTS
Figura 4.0 – Proceso general de la Fase de Medición COSMIC
Cada paso de este método es el objeto de una sección específica de este capítulo, donde se
presentan las definiciones y principios a aplicar, junto con algunas reglas y ejemplos.
4.1. Identificar los movimientos de datos
Este paso consiste en identificar los movimientos de datos (Entrada, salida, lectura y escritura) de
cada proceso funcional.

4.1.1 Definición de los tipos de movimientos de datos
Definición – Movimiento de datos
Un componente con base funcional que mueve un único tipo de grupo de datos.
Nota 1: Hay cuatro tipos de movimiento de datos: Entrada, Salida, Lectura y Escritura
Nota 2: Para la medición, cada tipo de movimiento de datos se considera que incluye
ciertas manipulaciones de datos asociadas - Ver sección 4.1.6 para más detalles.
Nota 3: Más precisamente, es una ocurrencia de un movimiento datos, no un tipo de
movimiento de datos, que realmente mueve las ocurrencias del grupo de datos (no los
tipos). Este comentario se aplica también a las definiciones de Entrada, salida, lectura y
escritura.
Definición – Entrada, (Entry, E)
Una entrada (E) es un movimiento de datos que mueve un grupo de datos desde un
usuario funcional a través de la frontera hacia el proceso funcional donde se necesitan
Nota: Se considera que una entrada incluye ciertas manipulaciones de datos asociadas
(ver sección 4.1.6)
Definición – Salida, (Exit, X)
Una salida (X) es un movimiento de datos que mueve un grupo de datos desde un
proceso funcional a través de la frontera hacía el usuario funcional que los requiere.
Nota: Se considera que una salida incluye ciertas manipulaciones de datos asociadas
Definición – Lectura (Read, R)
Un movimiento de un grupo de datos desde un almacén permanente dentro del alcance

del proceso funcional que los requiere.
Nota: Se considera que una lectura incluye ciertas manipulaciones de datos asociadas
Definición – Escritura (Write, W)
Un movimiento a un almacén permanente de un grupo de datos que se encuentra

dentro de un proceso funcional.
Nota: Se considera que una escritura incluye ciertas manipulaciones de datos asociadas

La figura 4.1.1, debajo, ilustra la relación general existente entre los cuatro tipos de movimientos de
datos, el proceso funcional al que pertenecen y la frontera del software medido.
Functional users
Boundary
Functional
Entry (E) process Exit (X)
1 data group 1 data group
Read (R) Write (W)

1 data group 1 data group
Persistent
storage
Figura 4.1.1 - Los cuatro tipos de movimiento de datos y su relación con el proceso funcional y los
grupos de datos.
4.1.2. Identificación de entradas (E)
Una vez identificado, un candidato a movimiento de datos de Entrada debe cumplir con los siguientes
principios:
Principios – Entradas (E)

a) Una entrada deberá mover un único grupo de datos describiendo un solo objeto de
interés de un usuario funcional a través de la frontera y dentro de un proceso
funcional del que la entrada forma parte. Si la entrada a un proceso funcional
comprende más de un grupo de datos, se identifica una entrada por cada grupo de
datos que entra. (Véase también la sección 4.1.7 sobre “El único movimiento de
datos”)
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
más tarde no necesite que se le diga que datos enviar o el usuario funcional es
incapaz de reaccionar a ningún 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.
Sin embargo, cuando un proceso funcional deba obtener algún dato de un usuario
funcional y el proceso funcional deba decirle al usuario funcional con datos que
después requieran rellenar la petición, contar una Salida para la petición y una
Entrada para la devolución de los datos pedidos (para más información ver sección
4.1.9).
Las siguientes reglas ayudan a confirmar la condición de un candidato a movimiento de datos de

entrada:
Reglas – Entradas (E)

a) El grupo de datos que disparen una entrada puede constar de sólo un atributo de

datos que simplemente informa al software que “un evento Y ha ocurrido”. Muy a
menudo, especialmente en el software de gestión, el grupo de datos que dispara
una entrada tiene muchos atributos que informan al software de que “un evento Y ha
ocurrido y aquí están los datos sobre ese evento en particular”.
b) Las ticks de reloj que están provocando eventos serán siempre externos al software
que está siendo medido. Por lo tanto, por ejemplo, un evento de tick de reloj cada 3
segundos estará asociada a una entrada que mueve un grupo de datos con un sólo
atributo. Se debe notar que no hay ninguna diferencia si el hecho desencadenante
es generado periódicamente por el hardware o por otra parte del software fuera de
los límites del software medido.
c) Salvo que sea necesario en un proceso funcional especifico, obtener el tiempo
desde el reloj del sistema no será considerado como causa de una entrada.
d) Si una ocurrencia de un evento específico desencadena la entrada de un grupo de
datos que comprende hasta “n” atributos de un objeto de interés en particular y los
FUR permiten que otras ocurrencias del mismo evento puedan disparar una Entrada
de un grupo de datos que tiene valores de atributos de sólo un subconjunto de ‘n’
atributos del objeto de interés, entonces será identificada una entrada, compuesto
por todos ‘n’ atributos.
Un ejemplo que ilustra la regla c): cuando un proceso funcional escribe un certificado de fecha de registro, no se identifica
ninguna Entrada para obtener el valor del reloj del sistema.
Una vez identificados, cada movimiento de datos de Entrada puede ser registrado marcando la casilla
correspondiente a la tabla del Modelo Genérico de Software (apéndice A) con una “E”.
4.1.3. Identificación de salidas (X)
Una vez identificados, un candidato a movimiento de datos de Salida debe cumplir con los siguientes
principios:
Principios – Salidas (X)

a) Una salida deberá mover un único grupo de datos describiendo un solo objeto de
interés desde el proceso funcional del que la salida forma parte a cruzando la
frontera hacia un usuario funcional. Si la salida de un proceso funcional comprende
más de un grupo de datos, hay que identificar una salida para cada grupo de datos
que sale. (Véase también la sección 4.1.7 sobre los movimientos de datos únicos.)
b) Una salida no introducirá datos a través de la frontera, ni lecturas, ni escrituras.
Las siguientes normas podrían ser útiles para confirmar la condición de un candidato a movimiento de
datos de tipo Salida:
Reglas – Salidas (X)

a) Todos los mensajes generados y las salidas producidas por el software sin datos del
usuario (por ejemplo mensajes de error) deberán ser considerados valores de un
atributo de un objeto de interés (el cual debería ser nombrado ‘indicación de error’).
Por lo tanto, deberá ser identificada una sola Salida para representar todos estos
mensajes dentro de cada proceso funcional donde son requeridos por los requisitos
funcionales de Usuario.
b) Si una salida de un proceso funcional mueve un grupo de datos comprendiendo
hasta ‘n’ atributos de un objeto de interés y los requisitos funcionales de usuario
permiten que el proceso funcional pueda tener una ocurrencia de una salida que
mueve un grupo de datos que tiene valores de atributos de sólo un subconjunto de
‘n’ atributos del objeto de interés, entonces será identificada una salida, compuesta
por todos los ‘n’ atributos.
Ejemplos de la regla a) anterior son los siguientes:

Ejemplo 1: En un diálogo persona-ordenador, ejemplos de mensajes de error ocurridos durante la validación de datos
podrían ser “error de formato”, “Cliente no encontrado”, “error: marcar la casilla que indica que los términos y condiciones
han sido leídos”, “límite crédito excedido”, etc. Todos esos mensajes de error deben considerarse como ocurrencias de una
salida en cada proceso funcional en el que tales mensajes se producen (que podría ser nombrado “mensajes de error”)
Ejemplo 2: Los mensajes de error que salen a los usuarios humanos pero que no son generados por la aplicación de
software deberían ser ignorados por completo en la medición de la aplicación. Un ejemplo de ese mensaje al pasar por el
sistema operativo podría ser “La impresora X no responde”.
Ejemplo 3: En un diálogo persona-ordenador, si un mensaje es la salida de un error de situaciones pero contiene datos
funcionales de usuario, entonces debe contarse como una salida en el proceso funcional donde ocurre. Un ejemplo de ese
mensaje podría ser “PELIGRO: la cantidad que desea retirar supera su límite por 100€” (donde los 100€ son una variable
calculada). En este ejemplo, la salida contiene un grupo de datos sobre la cuenta bancaria del cliente
Ejemplo 4: En un sistema en tiempo real, un proceso funcional que revisa periódicamente el correcto funcionamiento de
todos los dispositivos de hardware podría emitir un mensaje que informe “SENSOR X ha fallado”, donde “X” es una variable.
Este mensaje debe ser identificado como una salida en ese proceso funcional (independientemente del valor de “X”)
Ejemplo 5: Considerar procesos funcionales A y B. “A” puede potencialmente emitir 2 mensajes distintos de confirmación y 5
mensajes de error a sus usuarios funcionales y “B” puede potencialmente emitir 8 mensajes de error a sus usuarios
funcionales. En este ejemplo, será identificada una salida en el proceso funcional “A” (manejando 5 + 2 = 7 mensajes) y se
identificará una salida separada en el proceso funcional “B” (manejando 8 mensajes).
Una vez identificados, cada movimiento de datos de Salida puede ser registrado marcando la casilla
correspondiente de la tabla del modelo genérico de Software (apéndice A) con un “X”.
4.1.4. Identificación de Lecturas (R)
Una vez identificado, un candidato a movimiento de datos de Lectura debe cumplir con los siguientes
principios:
Principios – Lecturas (R)

a) Una lectura deberá mover un único grupo de datos describiendo un solo objeto de
interés del almacén permanente a un proceso funcional del cual la lectura forma
parte. Si el proceso funcional debe recuperar más de un grupo de datos del
almacén, identificar una Lectura para cada grupo de datos que es recuperado.
(Véase también la sección 4.1.7 sobre los movimientos de datos únicos.)
b) Una lectura no recibirá ni sacará datos a través de la frontera ni escribirá datos
c) Durante un proceso funcional, el movimiento o manipulación de constantes o
variables que son internas del proceso funcional y que sólo se pueden cambiar por
un programador, o mediante los resultados intermedios en un cálculo, o de los datos
almacenados en un proceso funcional sólo resultantes de la aplicación, más que de
los requisitos funcionales, no se considerará como una Lectura.
d) Una Lectura siempre incluye cualquier funcionalidad de ‘solicitud de lectura’ (así, un
movimiento de datos separado nunca será contado para cualquier funcionalidad de
‘solicitud de lectura’). Véase también la sección 4.1.9.
Una vez identificados, cada movimiento de datos de Lectura puede ser registrado por marcando la
casilla correspondiente de la Matriz de Modelo Genérico del Software (apéndice A) con una ‘R’.
4.1.5. Identificando escrituras (W)
Una vez identificado, el candidato como movimiento de datos de Escritura debe cumplir con los
siguientes principios:
Principios – Escritura (W)

a) Una escritura deberá mover un único grupo de datos describiendo un solo objeto de

interés del proceso funcional del que la Escritura forma parte hacia un almacén
permanente. Si el proceso funcional debe pasar más de un grupo de datos al
almacén permanente, identificar una Escritura por cada grupo de datos que se
mueve a un almacén permanente. (Véase también la sección 4.1.7 sobre
movimientos únicos de datos)
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 almacén permanente se medirá
como una sola Escritura
d) Durante un proceso funcional, el movimiento o manipulación de los datos que no
persista cuando el proceso funcional sea completado, o la actualización de variables
que son internas del proceso funcional o la producción de resultados intermedios en
un cálculo no se considerarán como una Escritura.
Una vez identificadas, cada Escritura puede ser registrada marcando la casilla correspondiente de la
tabla del modelo de software genérico (apéndice A) con un ‘W’.
4.1.6. Sobre las manipulaciones de datos asociadas con los movimientos de datos
Sub-procesos son, tal como se define en el principio (d) del Modelo Genérico de Software (ver
sección 1.4), o bien movimientos de datos, o bien manipulaciones de datos. Sin embargo, por un
convenio actual de COSMIC (véase el principio (j) del Modelo Genérico de Software), no se reconoce
la existencia separada de manipulación de datos y sub-procesos.
Definición – Manipulación de datos
Todo lo que le sucede a los datos, distinto de un movimiento de datos en o de un

proceso funcional, o entre un proceso funcional y almacén permanente.
El siguiente principio determina como el método COSMIC trata la manipulación de datos.
Principio – Manipulación de datos asociada con los movimientos de datos
Todas las manipulaciones de datos en un proceso funcional serán asociadas con los
cuatro tipos de movimiento datos (E, X, R, y W). Por convención, los movimientos de
datos de un proceso funcional se supone que también representan la manipulación de
los datos del proceso funcional
La necesidad de definir qué clase de manipulación de los datos está asociada con qué tipos de
movimientos datos surge sólo cuando hay que medir los cambios de software (ver sección 4.4). Un
cambio típico necesario afecta tanto a los atributos reubicados como a la manipulación asociada con
un movimiento de datos, pero puede afectar sólo a la manipulación de los datos, y no al movimiento
de los datos. Ese cambio todavía necesita ser identificado y medido.
A continuación están las directrices generales para identificar la manipulación de los datos
representados por cada uno de los movimientos de datos.
Movimiento de Datos de Entrada (E)
Una entrada incluye toda manipulación de datos

• Para permitir a un grupo de datos debe ser introducida por un usuario funcional (por ejemplo
manipulaciones de formato y presentación) y/o para ser validado
• Pero no todas las manipulaciones que involucran otro movimiento de datos, ni manipulaciones
después de que el grupo de datos se ha introducido y validado.
Ejemplo: Una entrada incluye toda manipulación, formato y presentación en una pantalla de los datos introducidos salvo
alguna Lectura(s) que podría ser necesaria para validar algunos códigos introducidos o para obtener algunas descripciones
asociadas.
Una Entrada de datos incluye cualquier funcionalidad “solicitud de entrada” excepto cuando el
proceso funcional debe informar al usuario funcional qué datos va a enviar (véase el punto 4.1.9 para
qué datos enviar y 4.1.10 para el tratamiento de una pantalla vacía como entrada).
Movimiento de Datos de Salida (X)
Una Salida incluye todas las manipulaciones de datos

• para crear los atributos de un grupo de datos de salida y/o
• para permitir que el grupo de datos sea salida (por ejemplo las manipulaciones de formato y
presentación) y sea encaminado a los usuarios funcionales.
• pero no cualquier manipulación que involucre otro movimiento de datos.
Ejemplo: Una Salida incluye todo el tratamiento para formatear y preparar la impresión de algunos atributos, incluidos los
encabezados para aumentar la legibilidad por los humanos, salvo cualquier Lectura o Entrada que podría ser necesaria para
proporcionar los valores o descripciones de algunos atributos de impresión.
Movimiento de datos de Lectura (R)
Una Lectura incluye todo tratamiento y/o cálculo necesario a fin de recuperar un grupo de datos del
almacén permanente pero no a manipulaciones con otro tipo de movimiento de datos ni
manipulaciones después de que la lectura se complete con éxito.
Ejemplo: Una lectura incluye todas las operaciones matemáticas y transformaciones lógicas necesarias para recuperar un
grupo de datos de un almacén permanente pero no la manipulación de los atributos después de que el grupo de datos se
haya obtenido.
Una Lectura también incluye siempre cualquier funcionalidad de “solicitud de lectura” (véase el punto
4.1.9).
Movimiento de datos de Escritura (W)
Una Escritura incluye todos los tratamientos y/o cálculos para crear un grupo de datos que será
escrito pero no cualquier manipulación que incluya otro tipo de movimiento de datos, ni tampoco
manipulaciones de que la Escritura termine con éxito después de que la Escritura termine con éxito.
Ejemplo: Una Escritura incluye todas las operaciones matemáticas y transformaciones lógicas necesarias para crear o
actualizar un grupo de datos de Escritura, o para ser borrados excepto las lecturas o entradas que podrían ser necesarias
para dar valor a los atributos incluidos en el grupo que va a ser escrito o suprimido.
4.1.7 Movimientos de datos únicos y posibles excepciones
El Modelo Genérico de Software supone que normalmente en cualquier proceso funcional todos los
datos describen un objeto de interés que se traduce en un solo movimiento de datos de tipo Entrada
y/o en uno de tipo Lectura y/o en uno de tipo Escritura y/o en la producción de un movimiento de
datos de tipo Salida. El modelo supone también que toda manipulación de los datos resultantes de
todos los valores de los atributos los datos de un grupo que se mueve está asociado con un
movimiento de datos.
Ejemplo que ilustra este último supuesto; consideremos dos ocurrencias de un determinado proceso funcional dado.
Supongamos que en la primera ocurrencia los valores de algunos atributos se trasladan a una manipulación de datos del
sub-proceso “A” y que en otra ocurrencia del mismo proceso funcional el valor del atributo es conducido a otra manipulación
de datos del sub-proceso “B”. En tales circunstancias, tanto la manipulación de datos del sub-proceso “A” como “B” deben
asociarse con el mismo movimiento de datos y de ahí normalmente sólo un movimiento datos debe identificarse y ser
contado en ese proceso funcional.

Sin embargo, en excepcionales circunstancias en las que datos de diferente grupo de tipos describen
el mismo objeto de interés puede ser necesario (en los FUR) reubicarlos en un movimiento de datos
del mismo tipo (E, R, W, X) en el mismo proceso funcional. Por otra parte, y de nuevo
excepcionalmente, se puede requerir que el mismo grupo de datos sea movido en el mismo tipo de
movimiento (E, R, W o X) en el mismo proceso funcional, pero con diferentes manipulaciones de
datos asociadas.
Las siguientes reglas y ejemplos cubren la situación normal, excepciones validadas posibles y
ejemplos que podrían parecer como válidos, pero que no lo son.
Regla – Movimientos de Datos Únicos y posibles excepciones

a) A menos que los Requisitos Funcionales de Usuario especifiquen lo contrario, todos
los atributos describen un objeto de interés que está obligado a ser entrada en un
proceso funcional, y todas las manipulaciones de datos asociadas serán
identificadas y se contarán como una Entrada.
Nota: Un proceso funcional puede, por supuesto, estar obligado a manejar múltiples
Entradas, cada movimiento de un grupo de datos describe un objeto de interés
diferente
La misma norma se aplica a cualquier movimiento de datos de tipo Lectura,
Escritura o Salida en cualquier proceso funcional.
b) Cuando hay más de un movimiento de datos de Entrada, cada movimiento de un
grupo de datos que describa el mismo objeto de interés en un proceso funcional
puede ser identificado y contado si existe un Requisito Funcional de Usuario para
estas múltiples entradas. Asimismo, puede ser identificada y contada más de una
Entrada moviendo el mismo grupo de datos en el mismo proceso funcional, pero
cada una con diferentes manipulaciones de datos asociadas, si existe un Requisito
Funcional de Usuario para las mismas
Tales FUR pueden surgir cuando, en un proceso funcional, las múltiples entradas
proceden de diferentes usuarios funcionales que introduzcan diferentes grupos de
datos (cada uno describiendo el mismo objeto de interés)
La misma norma se aplica a cualquier Lectura, Escritura o Salida en cualquier
proceso funcional.
c) Si se repiten ocurrencias de un mismo tipo de movimiento de datos (es decir se
mueve el mismo grupo de datos con la misma manipulación de datos) no deberán
ser y contadas más de una vez en un proceso funcional.
d) Si las múltiples ocurrencias de un tipo de movimiento de datos en un determinado
proceso funcional difieren en sus manipulaciones de datos asociadas, porque los
diferentes valores de los atributos del grupo de datos movido han resultado de
caminos de procesamiento distintos, el tipo de movimiento de datos no deberá ser
identificado ni contado más de una vez en ese proceso.
Los siguientes ejemplos ilustran las reglas anteriores.
Ejemplo 1 para una regla a): en un proceso funcional, todas las Lecturas de datos que describen un objeto de interés en
particular pueden considerarse lógicamente para devolver todos los atributos que describen ese objeto de interés (es decir,
el conjunto del “vector de estados” de ese objeto de interés). Por lo tanto normalmente, sólo una Lectura de cualquier dato
sobre un objeto de interés es funcionalmente necesaria y debe ser identificada en un proceso funcional.
Ejemplo 2 de las reglas a) y b): Después del Ejemplo 1, todos los datos que son leídos deben haberse hecho persistentes
por una Escritura, este es el caso en que normalmente sería identificada una Escritura por mover un grupo de datos que
contiene todos los atributos de un objeto de interés y que debe hacerse persistente en un determinado proceso funcional,
según la norma a). Es posible, sin embargo, que existan FUR para un único proceso funcional para escribir dos datos
diferentes grupos describiendo el mismo objeto de interés, por ejemplo, para un uso posterior por dos usuarios funcionales
distintos en otros procesos funcionales. Este sería un Ejemplo donde la norma b) se aplica, cuando dos Escrituras de datos
que describen el mismo objeto de interés pueden ser identificadas y contadas en el mismo proceso funcional.

Ejemplo 3 para la regla b): Es posible que existan FUR para un único proceso funcional que produzcan dos o más Salidas
de diferentes grupos de datos describiendo el mismo objeto de interés, destinados a diferentes usuarios funcionales. Por
ejemplo, cuando un nuevo empleado llega a una empresa, se produce un informe por el empleado para firmar sus datos
personales como válidos y un mensaje es enviado a Seguridad para autorizar al empleado a entrar en el edificio.
Ejemplo 4 por regla c): Suponga que se requiere una Lectura en los requisitos funcionales de usuario que en la práctica
requiere muchas recuperaciones de ocurrencias, como en la búsqueda de un fichero. Para la medición, identificar sólo una
Lectura.
Ejemplo 5 por regla c): Suponga que en un proceso funcional de tiempo real los requisitos funcionales de usuario requieren
que los datos entren desde un determinado usuario funcional, por ejemplo, un dispositivo de hardware, dos veces en un
intervalo de tiempo para medir un tipo de cambio o para comprobar si un valor ha cambiado durante el proceso. Siempre
que las dos entradas sean idénticas en términos del grupo de datos reubicado y las manipulaciones de datos asociadas,
sólo deberá ser identificada una entrada.
Ejemplo 6 para la norma c): véase la sección 4.1.2, Norma d) para entradas, y la sección 4.1.3, Norma b) para las salidas.
Ejemplo 7 para regla d): Suponga un proceso funcional en el que es necesario que proporcione diversas opciones de
manipulación de datos dependiendo de los valores de los atributos de una entrada. Para la medición, identificar sólo una
entrada.
Ejemplo 8: Supongamos que una Lectura de un grupo de datos es necesaria en los requisitos funcionales de usuario, pero
el desarrollador decide implementarla mediante dos comandos para recuperar diferentes sub-series de atributos del mismo
objeto de interés de las ficheros de almacenamiento en diferentes puntos del proceso funcional. Identificar sólo una lectura.
4.1.8. Cuando un proceso funcional mueve datos para o desde un fichero de almacenamiento.
Esta sección explica los movimientos de datos involucrados cuando un proceso funcional de parte de
una aplicación software es requerido para desplazar datos hasta o desde un fichero de
almacenamiento, de manera local o remota. Los casos también mostrar cómo el almacenamiento de
una aplicación necesita ser manipulado por otro software que soporta la aplicación en otra capa, tales
como el almacenamiento permanente en un dispositivo.
Los casos ilustran la aplicación del principio (g) del Modelo de Contexto Software y los principios del
Modelo Genérico del Software. La clave para entender los casos es que estos principios deben ser
aplicados por separado a cada parte de software que deba ser medida.
El primer caso trata con los movimientos de datos de una consulta en una aplicación donde el
requisito para recuperar datos persistentes es manejado por un controlador software local en otra
capa. El segundo caso muestra cómo los diferentes movimientos de datos difieren cuando el requisito
de recuperar es satisfecho primero por parte semejante o par del software en la misma capa de la
aplicación.
En términos prácticos, los casos son aplicables cuando la tarea consiste en medir dos partes de
software que tienen una relación jerárquica (es decir, cuando las dos piezas están en diferentes
capas) o tienen una relación cliente-servidor (es decir, cuando las dos piezas están en la misma
capa). Los casos muestran cómo son medidos y modelados los movimientos de datos que son
físicamente intercambiados entre las dos partes de software.
Los ejemplos se ilustran usando los convenios de Diagramas de Secuencia de Mensajes. La notación
de estos diagramas es como se explica a continuación:
• Una flecha vertical hacia abajo representa un proceso funcional

• Las flechas horizontales representan los movimientos de datos, etiquetados como E, X, R o W
para la Entrada, Salida, Lectura y Escritura, respectivamente. Entradas y Lecturas se muestran
como flechas de llegada al proceso funcional y las Salidas y Escrituras como flechas salientes;
aparecen en la secuencia necesaria, de arriba a abajo, del proceso funcional

• Una línea vertical punteada (discontinua) representa un límite frontera
Ejemplo 1: Cuando un proceso funcional debe mover datos hasta o desde un fichero de almacenamiento local
Este ejemplo implica dos aplicaciones software, aplicación “A” y aplicación “B” que es el driver para un dispositivo de
almacenamiento que la aplicación software utiliza. (Para simplificar ignoramos la probable presencia de un sistema
operativo; el sistema operativo efectivamente transmite las peticiones de la aplicación al driver del dispositivo y devuelve los
resultados de las peticiones.)
El concepto de capas nos dice que las dos aplicaciones software están en diferentes capas: la capa de aplicación y la capa
de drivers de dispositivos. Físicamente, hay una relación jerárquica entre las dos piezas y (ignorando el sistema operativo)
una interfaz física entre el software de las dos capas, como por ejemplo en la Fig. 2.2.3.1.
Normalmente, los requisitos funciones de usuario de la aplicación “A” especificarán los procesos funcionales que incluyen la
necesidad de Leer y Escribir en el fichero de almacenamiento pero no en lo concerniente a cómo las Lecturas y Escrituras
son manejadas por otras infraestructuras software.
Aplicando el modelo de COSMIC a las dos piezas de software, los usuarios funcionales del software A en la capa de
aplicación podrían ser, por ejemplo, usuarios humanos, mientras que los usuarios funcionales del software B en la capa del
controlador es la aplicación A (ignorando el sistema operativo).
Supongamos que una consulta del proceso funcional ‘FP A’ del software A en la capa de aplicación exige una Lectura. La
figura 4.1.8.1 (a) muestra el modelo COSMIC de la aplicación en la que se busca información. La recuperación física de los
datos necesarios de los ficheros de almacenamiento es manejado por un proceso funcional ‘B’ del software B en la capa del
controlador. La figura 4.1.8.1 (b) muestra el modelado de este proceso funcional del driver del dispositivo.
Persistent storage
Application in Layer A device driver in Layer B
FP A FP B
E Functional E
user of Functional
Functional software in X
User:
user of R
layer B Persistent
application X E storage
in layer A X (=
application hardware
in layer A) device
Figuras 4.1.8.1 (a) y (b) Solución para una lectura emitida por el software 'A' en la capa de aplicación del
software a 'B' en la capa del controlador.
La figura 4.1.8.1 a) muestra la búsqueda de información desencadenada por una entrada, seguida de una lectura y luego
una salida con el resultado de la búsqueda. El proceso funcional A no tiene conocimiento de donde se obtienen los datos, ni
que en la práctica la lectura es delegada a algunos controladores de dispositivos software.
La figura 4.1.8.1 b) muestra que funcionalmente la Lectura solicita que la aplicación A es recibida como un evento de
Entrada al proceso funcional PF B, que luego recupera los datos solicitados desde el dispositivo físico de almacenamiento y
devuelve los datos a la aplicación como una salida. La aplicación A es pues un usuario funcional de los controladores del
software B.
El aparente desencuentro entre el número de movimientos de datos de la “Lectura” del software en la capa de aplicación y
la ‘Entrada/Salida par’ de software en la capa del dispositivo es debido al hecho de que por convenio, una Lectura de datos
se considera que incluye cualquier funcionalidad de ‘solicitud de lectura’.
Exactamente modelos análogos se aplicarían si el proceso funcional FP A fuera requerido para crear algún dato
permanente mediante una Escritura. En este caso, la salida del proceso funcional PF B del dispositivo software contendría
cualquier “código de retorno” o mensaje de error.
Ejemplo 2: Cuando un proceso funcional debe obtener datos de un componente homólogo o par de software

En este ejemplo, los dos pares de componentes de software a ser medidos se supone que son un ‘cliente/servidor’, es decir,
donde un componente, el cliente, recibe los servicios y/o datos del otro componente, ‘servidor’. La figura 4.1.8.2 muestra un
ejemplo de esa relación, en la que las dos piezas son importantes componentes de la misma aplicación. La misma relación
que existiría y el mismo esquema se aplicarían si las dos piezas fueran aplicaciones homólogas separadas, donde una es
necesaria para obtener datos de la otra.
Físicamente, los dos componentes pares podrían ejecutarse en diferentes procesadores; en tal caso intercambiarían datos
a través de los respectivos sistemas operativos y cualquier otra capa intermedia de sus procesadores en una arquitectura
software tal como la Fig. 2.2.3.1. Pero lógicamente, aplicando el modelo COSMIC, los dos componentes intercambian datos
a través de ‘Entrada/Salida’. Todo el software y hardware que interviene es ignorado en este modelo (como también se
indica en el lado derecho de figura. 3.1.1).
La Figura 4.1.8.2 muestra un proceso funcional FP C1 de un componente cliente C1 que es desencadenado por una
Entrada de su usuario funcional que comprende, por ejemplo los parámetros de la información buscada. Los requisitos
funcionales del componente C1 reconocerán que este componente debe pedir al componente servidor C2 los datos
requeridos, y debe decirle qué datos son necesarios.
La Salida cruza la frontera entre C1 y C2 y se convierte en el desencadenante de la entrada de un proceso funcional FP C2

en el componente C2. El proceso funcional FP C2 del componente C2 obtiene los datos necesarios mediante un proceso de
lectura, y envía los datos a C1 mediante una salida. El Proceso Funcional FP C1 del componente C1 recibe este
movimiento de datos como una entrada. FP C1 pasa entonces los datos como una Salida para satisfacer la búsqueda de su
usuario funcional. Este caso 2 por lo tanto requiere 7 movimientos de datos para satisfacer la solicitud. Esto se compara con
los 3 movimientos de datos (1 x E, 1 x R y 1 x X) que habrían sido necesarios si el componente C1 hubiera sido capaz de
recuperar los datos del fichero de almacenamiento local como en la figura 4.1.8.1 (a).
Component C1 (Client) Component C2 (Server)
E FP C1 FP C2
X E
Functional user of
component C1 R
E X
X
Figura 4.1.8.2 Intercambio de datos entre componentes semejantes en la misma capa
El Componente C2 probablemente, por supuesto, utilice los servicios de algunos dispositivos de almacenamiento en una
capa inferior de la arquitectura software para recuperar los datos del hardware, como en el caso 1.
Comparando los casos 1 y 2, vemos que en el caso 1, los modelos de la aplicación A y el dispositivo
controlador B no pueden combinarse como en el ejemplo 2. Esto es porque una lectura no cruza una
frontera. La Figura 4.1.8.1 (B) muestra que la aplicación A es un usuario funcional de un dispositivo
controlador del software B. Pero lo contrario no es cierto, demostrando así el carácter jerárquico del
software en diferentes niveles.
En contraste, Fig. 4.1.8.2 puede mostrar los dos componentes en un modelo porque intercambian
datos como ‘pares’ o iguales. El Componente C1 es un usuario funcional del componente C2, y
viceversa, y comparten una frontera común.

Nota: En estos dos casos hemos ignorado, por simplificar, la posibilidad de un ‘código de retorno’ que
acompañe a la Lectura, que podría conducir a la generación de un mensaje de error además de la
salida como el resultado de la búsqueda en la aplicación o el componente C1.
4.1.9 Cuando un proceso funcional requiere datos de un usuario funcional
Como por el principio c) para una entrada (ver sección 4.1.2), si un proceso funcional debe obtener
datos de un usuario funcional hay dos casos. Si el proceso funcional no necesita decirle al usuario
funcional qué datos enviar, una sola Entrada es suficiente (por objeto de interés). Si el proceso
funcional debe decirle al usuario funcional qué datos va a enviar, es necesaria una entrada/salida par.
Las normas son las siguientes:
Reglas – Cuando un proceso funcional requiere datos de un usuario funcional

a) Cuando un proceso funcional requiere datos de un usuario funcional un proceso
funcional deberá obtener un grupo de datos por medio de una Entrada de un usuario
funcional, cuando no tiene que decirle al usuario qué datos va a enviar, como en
cualquiera de los siguientes cuatro casos:
• Cuando un usuario funcional envía una entrada que desencadena el inicio del
proceso funcional
• Cuando un proceso funcional, habiéndose iniciado, espera, expectante a la
próxima Entrada desde el usuario funcional (típica en el software de negocio de
aplicación, de un usuario funcional humano).
• Cuando un proceso funcional, habiéndose iniciado, pide al usuario funcional que
le envíe ‘envíame tus datos ahora, si tienes alguno’, y el proceso funcional envía
sus datos.
• Cuando un proceso funcional, habiéndose iniciado, inspecciona los datos de un
usuario funcional y recupera los datos que necesita.
En estos dos últimos casos (típico de un sistema de votación en tiempo real), por
convenio, no habrá una Salida desde el proceso funcional que deba ser identificada
para obtener los datos requeridos. El proceso funcional sólo debe enviar pronto un
mensaje a un usuario funcional para ingresar sus datos y la funcionalidad del
mensaje se considera parte de la entrada. El usuario funcional sabe lo que se puede
enviar y el proceso funcional sabe lo que puede esperar. Sólo una entrada es
necesaria para este caso.
b) Cuando un proceso funcional debe obtener los servicios de un usuario funcional (por
ejemplo, para obtener datos) y las necesidades de los usuarios le digan lo que
enviar (normalmente cuando el usuario funcional es otra parte del software fuera del
alcance del software que se mide), un par de movimientos de datos de
Entrada/Salida serán identificados. La salida contiene la solicitud específica de los
datos; la entrada contiene los datos.
Ejemplo 1 de la regla a), primer y segundo punto: donde un proceso funcional proporciona a un humano una pantalla de
entrada de datos, como en una aplicación de negocios on-line, el visualizar la pantalla ‘en blanco’ no se cuenta como una
Salida. Solo rellenar la pantalla es contado como una o más entradas (ver también la sección 4.1.10).
Ejemplo 2 de la regla a), tercer o cuarto escenario: Supongamos que un proceso funcional de un sistema con proceso
software de control en tiempo real necesario para comprobar un array con idénticos sensores. Las cuestiones relativas al
proceso son una Entrada (tipo). (De los sensores solo se identifica y se cuenta una Entrada, aunque hay múltiples
ocurrencias.)Supongamos que la Entrada debe en la práctica pasar a un dispositivo controlador de software en una capa
inferior de la arquitectura, que físicamente obtiene los datos necesarios desde el sensor como se ilustra en la Fig. 2.2.3.2.
Los procesos funcionales del proceso software de control y de los controladores software para los sensores sería como se
muestra en las Figuras 4.1.9.1 (a) y (b) debajo.

Process Control software Dumb sensor device
in Layer A driver in Layer B
FP A FP B
E1 Functional E
user of
Functional software in
user of E2 E Dumb
Dumb layer B
application X sensor
sensor (= process
in layer A
control
software in
(etc) layer A)
La figura 4.1.9.1 (a) y b) Solución para una entrada emitida por el software 'A' en la capa de la aplicación
del proceso de control recibida por el software 'B' en la capa del dispositivo de control del sensor.
La figura 4.1.9.1 (a) Muestra que el proceso software de control del proceso funcional ‘FP A’ es desencadenado por una
entrada ‘E1’ por ejemplo de un golpe de reloj. El proceso funcional luego obtiene la entrada ‘E2’ desde el array de sensores
para recibir las múltiples ocurrencias de los sensores de lecturas. Los sensores son también usuarios funcionales del
proceso software de control.
La figura 4.1.9.1 (b) Muestra que el software que impulsa el dispositivo del sensor recibe la Entrada (probablemente en la
práctica mediante un sistema operativo) como el disparador de un proceso funcional ‘FP B’. Este proceso funcional obtiene
una Entrada de su usuario funcional (tipo) y del sensor (tipo) para obtener los datos de los sensores que se reintegrarán al
proceso software de control como una salida. El proceso funcional del proceso software luego continúa con su
transformación de los datos del sensor. El hecho de que hay múltiples ocurrencias de este ciclo de recopilación de datos de
cada uno de los idénticos sensores es ignorado en el modelado.
El aparente emparejamiento entre la única Entrada del proceso software de control y la Entrada/Salida par de los
controladores software es debida al modo en que una Entrada es considerada como cualquier ‘solicitud de entrada’
funcional.
Ejemplo 3 de la norma b): Suponga que un proceso funcional envía a uno de sus usuarios funcionales como un dispositivo
hardware ‘inteligente’ o otro par de piezas software con algunos parámetros para una consulta o los parámetros de un
cálculo, o algunos datos para ser comprimidos. La respuesta de los usuarios funcionales se obtiene mediante una
entrada/salida par, tal como se describe en la sección 4.1.8, Caso 2.
4.1.10 Comandos de control
Un “comando de control" es una categoría especial de un movimiento de datos que es reconocido

sólo en el dominio de aplicaciones de negocio y que debe pasarse por alto cuando al medir un
tamaño funcional. La definición es:
Definición – Comando de control
Un comando de control es un comando que le permite al usuario funcional controlar su

uso del software pero que no implica ningún movimiento de datos sobre el objeto de
interés.
Nota: El término ‘comando de control’ es utilizado sólo en el contexto de medición
software de aplicación de negocios. En este contexto, un comando de control no es un
movimiento de datos porque el comando no mueve datos sobre el objeto de interés.
Ejemplos son barras de desplazamiento; pinchar sobre una pestaña o escribir una
clave, hacer clic en el ‘OK’ para confirmar una acción anterior, etc.

Regla – Comandos de control en el dominio de aplicaciones de negocio.
En el dominio de aplicaciones de negocio, los ‘comandos de control’ serán ignorados ya

que no implican ningún movimiento de datos sobre el objeto de interés.
Ejemplos de comandos de control en el dominio de aplicaciones de negocio son las funciones que permiten a un usuario
funcional controlar la cabecera de una pantalla (o no) o los subtotales que han sido calculados, navegar arriba y abajo y la
navegación física entre pantallas, hacer clic en ‘OK’ al reconocer un mensaje de error o confirmar algunos datos
introducidos, etc. Los Comandos de Control por lo tanto también incluyen comandos del menú que permiten al usuario
funcional navegar por uno o más procesos funcionales pero no iniciar un proceso funcional, y comandos para mostrar una
pantalla o formulario en blanco para ingresar datos.
No obstante, fuera del dominio de aplicaciones de negocio, el concepto de un ‘comando de control’ no

tiene un significado especial y cualquier señal o movimiento de datos sobre el objeto de interés
procedente de un usuario funcional debe justificarse, es decir, deberá medirse.
4.2. Aplicando la función de medición
Este paso consiste en la aplicación de la medida funcional de COSMIC a cada uno de los
movimientos de datos identificados en cada proceso funcional.
Definición – Medición funcional COSMIC
La medición funcional de COSMIC es una función matemática que asigna un valor a su

argumento basado en el estándar de medición COSMIC. El argumento de la medición
funcional COSMIC es el movimiento de datos.
Definición – Medida estándar COSMIC
La medición estándar de COSMIC, 1 PPC (Punto de Función COSMIC) se define como

el tamaño de un movimiento de datos.
Según esta función de medición, cada instancia de un movimiento de datos (Entrada, Salida, lectura o
Escritura) que se requiere para ser añadido, cambiado o suprimido y que ha sido identificado según la
sección 4.1 recibe una puntuación de 1 PPC.
4.3. Agregar resultados de medición
Este paso consiste en sumar los resultados de la medida funcional, tal como se aplica a todos los
movimientos de datos, en un único valor de tamaño funcional. Este paso se realiza según los
siguientes principios y reglas.
4.3.1 Reglas generales de agregación
Reglas – Agregando los resultados de la medición

a) Para cualquier proceso funcional, el tamaño funcional de cada movimiento de datos
individual debe ser agregado en un único valor de tamaño funcional en unidades de
CFP para luego sumar todos juntos.
Tamaño (proceso funcionali) = Σ tam(Entradassi) + Σ tam(Salidasi) +
Σ tam(Lecturassi) + Σ size(Escriturasi)
b) Para cualquier proceso funcional, el tamaño funcional de los cambios en requisitos
funcionales de usuario se sumarán al tamaño de movimientos de datos que han sido
añadidos, modificados o eliminados en proceso funcional para dar un tamaño del

cambio en unidades de CFP, según la siguiente fórmula.
Tamaño (Cambio(procedso funcionali)) = Σ tam (movimientos datos añadidosi) +
Σ tam (movimientos datos modificadosi) +
Σ tam (movimientos datos eliminadosi)
Para más información sobre el agregando del tamaño funcional, véase la sección
4.3.2. Para medir el tamaño de los cambios en el software, véase la sección 4.4.
c) El tamaño de una pieza de software dentro de un ámbito de aplicación se obtendrá
sumando los tamaños de sus procesos funcionales, sujeto a las normas e) y f) debajo
d) El tamaño de cualquier cambio en una pieza de software dentro de un ámbito de
aplicación se obtendrá sumando los tamaños de todos los cambios a todos sus
procesos funcionales, sujeto a las normas e) y f) abajo
e) Los Tamaños de piezas de software o de cambios de piezas de software en el interior
de las capas podrán sumarse sólo si se mide al mismo proceso funcional su nivel de
granularidad de sus requisitos funcionales de usuario.
f) Los Tamaños de piezas de software y/o cambios en los tamaños de la misma dentro
de una capa o de diferentes capas serán sumados sólo si tiene sentido hacerlo, a
efectos de la medición.
g) El tamaño de una aplicación software no puede obtenerse sumando los tamaños de
sus componentes (independientemente de cómo se descompone) al menos que el
tamaño de las contribuciones de los movimientos de datos inter-componentes sean
eliminadas.
h) Si el método COSMIC se extiende localmente (por ejemplo para medir algún aspecto
del tamaño no recogido por el método estándar), entonces el tamaño medido por la
extensión local debe ser informado por separado como se describe en la sección 5.1 y
no puede ser añadido al tamaño obtenido por el método estándar, medido en CFP
(véase además la sección 4.5)
Ejemplo 1 de las normas b) y c): Un cambio solicitado para una pieza de software podría ser: ‘añadir un nuevo proceso
funcional de tamaño 6 CFP’, y en otro proceso funcional agregar un movimiento de datos, hacer modificaciones a otros tres
movimientos de datos y suprimir dos movimientos. ‘El tamaño total del cambio solicitado es de 6 + 1 + 3 + 2 = 12 CPF.
Ejemplo 2 de la regla f): Si diversas partes importantes de una pieza de software se desarrollan utilizando tecnologías
diferentes, por diferentes proyectos sub-equipos, no puede haber ningún valor práctico en añadir sus tamaños juntos.
Ejemplo 3 para la regla g): Si un trozo de software es

• Primera medición ‘como un todo’, es decir, todos dentro del mismo alcance.
• Entonces en segundo lugar el tamaño de cada uno de sus componentes se mide por separado,
cada uno dentro de su propio ámbito.
El tamaño total de la suma del tamaño de todos los componentes por separado (en el segundo caso) superará al tamaño
cuando se mide ‘como un todo’ (en el primer caso) debido a la contribución de tamaño de todos los movimientos de datos
inter-componentes. Estos movimientos no son visibles cuando la pieza se midió ‘como un todo’ y debe ser eliminado para
obtener el tamaño ‘del todo’. Véase también el ejemplo en la sección sobre la medición en distintos niveles de granularidad
en arquitecturas de software puro en el documento “Temas avanzados y relacionados".
Es de señalar que, dentro de cada capa identificada, la agregación funcional es totalmente escalable.
Por lo tanto un sub-total puede ser generado para los distintos procesos funcionales o para todo el
software en una capa, dependiendo de la finalidad y alcance de cada ejercicio de medición y bajo las
normas d), e) y f) de arriba.
4.3.2. Más sobre la agregación del tamaño funcional
En un contexto donde el tamaño funcional deba utilizarse como una variable en un modelo, para
estimar el esfuerzo por ejemplo, y el software a ser medido tenga más de una capa o componente

par, la agregación normalmente se realizará por capas o por pares de componentes ya que no son
ejecutados a menudo con la misma tecnología.
Ejemplo 1: Considere un software donde la capa de aplicación se ejecutará utilizando 3GL y un conjunto de bibliotecas
existentes, mientras la capa de transporte podría estar implementada utilizando lenguaje ensamblador. La unidad de
esfuerzo asociada con la construcción de cada capa, muy probablemente, sea diferente, y, en consecuencia, una
estimación del esfuerzo será preparada por separado para cada capa sobre la base de su tamaño respectivo.
Ejemplo 2: Si un equipo del proyecto ha de desarrollar una serie de importantes piezas de software y está interesado en su
productividad global, se puede sumar el trabajo-hora necesario para desarrollar cada pieza. De manera similar, se pueden
sumar los tamaños de las principales piezas que ha desarrollado si (pero sólo si) esos tamaños satisfacen las normas dadas
anteriormente.
La razón por la que tamaños de grandes partes de software de diferentes capas de una arquitectura
estándar por capas, medida en el mismo nivel de granularidad del proceso, puedan sumarse es que
esa arquitectura tiene un conjunto coherente definido de usuarios funcional. Cada capa es un usuario
funcional de las capas bajas que se usan y cualquier pieza de software de una capa puede ser un
usuario funcional de cualquier otro par de piezas de software en la misma capa. Los requisitos de
dicha arquitectura imponen que los requisitos funcionales de usuario de las diversas piezas deberán
intercambiar mensajes. Es lógico y razonable que los tamaños de las distintas piezas puedan
sumarse, siempre sujeto a las normas d), e) y f) arriba indicadas. Sin embargo, en contraste con esto,
el tamaño de una pieza grande de software puede no ser obtenido sumando el tamaño de sus
componentes reutilizables a menos que el que los movimientos de datos del inter-objeto sean
eliminados, como por regla f) de arriba.
Agregar los resultados de las mediciones por tipo de los movimientos de datos podría ser útil para
analizar la contribución de cada tipo en el tamaño total de una capa y podría ayudar así a caracterizar
la naturaleza funcional de la capa medida.
4.4 Más en la medición del tamaño de los cambios de software
Un ‘cambio funcional’ de software existente es interpretado en el método COSMIC como ‘cualquier

combinación de sumas de nuevos movimientos de datos o de modificaciones o eliminaciones de los
movimientos de datos existentes’. Los términos ‘Mejora y Mantenimiento’ se utilizan a menudo para lo
que aquí llamamos un ‘cambio funcional’.
La necesidad de un cambio de software puede surgir de cualquier

• Nuevo Requisito Funcional de usuario (es decir, sólo sumas a la funcionalidad existente), o
• Desde un cambio en el requisito (quizá con sumas, modificaciones y eliminaciones) o
• Desde un ‘mantenimiento’ necesidad de corregir un defecto.
Las normas para la medición del tamaño de cualquiera de estos cambios son las mismas pero el
medidor es alertado a distinguir las diversas circunstancias cuando se hacen mediciones del
rendimiento y estimaciones.
Cuando un software es reemplazado por completo, por ejemplo al re-escribir, con o sin ampliar y/u
omitir funcionalidades, el tamaño funcional de este cambio es el tamaño del software del reemplazo,
medido según las reglas normales para la medición del software nuevo. Este caso no será examinado
nuevamente en esta sección. El medidor debe ser consciente, sin embargo, de la necesidad que hay
cuando se hacen mediciones del rendimiento o estimaciones para distinguir entre los proyectos a
desarrollar enteramente con software nuevo y proyectos para ‘re-hacer o ‘reemplazar’ software
existente.
A menudo, una parte obsoleta de una aplicación es suprimida («desconectada sería una mejor
descripción) por abandonar el código de programa en lugar de sólo eliminar el contacto con la
funcionalidad obsoleta. Cuando la funcionalidad de la parte obsoleta asciende a 100 CFP pero la

parte puede ser desconectada por cambiar, digamos, 2 movimientos de datos, 100 y no 2
movimientos de datos serán identificados como el tamaño del cambio funcional. Podemos medir el
tamaño de la exigencia, no el tamaño que fue implementado.
Nota: La diferencia entre el tamaño de los cambios funcionales (discutido aquí) y el cambio en el
tamaño funcional del software. Generalmente, son diferentes. El tamaño de la última está recogido en
la sección 4.4.3.
4.4.1. 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 asociadas
(para el último, véase la sección 4.1.6). Por lo tanto para la medición un movimiento de datos se
considera que es modificado funcionalmente si:
• El Grupo de datos es reubicado y/o
• Está asociado a una manipulación de datos
Son modificados en modo alguno.
Un grupo de datos es modificado si:
• Se añaden nuevos atributos a este grupo de datos y/o
• Los atributos son retirados de los grupos de datos y/o
• uno o más atributos existentes son modificados, por ejemplo, en sentido o formato (pero no en
sus valores)
Una manipulación de datos es modificada si es funcionalmente ha cambiado en modo alguno, por

ejemplo por cambiar el cálculo, el formato específico, presentación y/o validación de datos. `La
presentación’ puede significar, por ejemplo la fuente, el color de fondo, la longitud del campo, el
número de decimales, etc.
Los comandos de control y los datos de aplicación general no implican movimientos de datos, ya que
no hay datos sobre los objetos de interés que son movidos. Por lo tanto, los cambios de comandos de
control y de datos de aplicación general no deben medirse. Por ejemplo, cuando el color de la
pantalla para todas las pantallas es cambiado, este cambio no debe medirse. (Ver sección 4.1.10
para una explicación de comandos de control y datos de aplicación general.)
Reglas – Modificando un movimiento de datos

a) Si un movimiento de datos debe ser modificado debido a un cambio de la
manipulación de los datos relacionados con el movimiento de datos y/o debido a un
cambio en el número o tipo de los atributos del grupo de datos movido, un cambio
CFP se medirá, independientemente de la cantidad real de modificaciones en el
movimiento de la datos.
b) Si un grupo de datos deben ser modificado, los movimientos de datos moviendo el
grupo de datos modificado, cuya funcionalidad no se ve afectada por la modificación
del grupo de datos, no serán identificados como movimientos de datos modificados.
Nota 1: Una modificación para un valor de una ocurrencia de un atributo, tales como una
modificación de un código individual de un miembro de un atributo cuyos valores son un
sistema de codificación no es una modificación de los tipos del atributo.
Nota 2: Una modificación de cualquier dato que figuren en entrada o salida por pantalla
que no esté relacionado con el objeto de interés para un usuario funcional no será
identificados como un cambio CFP (ver sección 3.3.4 para los ejemplos de estos datos.)
Ejemplo de normas a) y b): Supongamos un requisito para añadir o modificar los atributos de los datos de un grupo D1, que
después de la modificación se vuelve D2. En el proceso funcional ‘A’ donde esta modificación es necesaria, todos los

movimientos de datos afectados por la modificación deberían ser identificados y contados. Así, según la norma a), si los
datos modificados grupo D2 son persistentes y/o es la salida en proceso funcional A, identificar una Escritura y/o una Salida
de datos respectivamente modificada. Sin embargo, es posible que otros procesos funcionales sean de Lectura o Entrada
en este mismo grupo de datos D2, pero su funcionalidad no se ve afectada por la modificación porque estos no utilizan los
cambios ni los nuevos atributos de datos. Estos procesos funcionales siguen para procesar el grupo de datos reubicado
como si fuese aún D1. Así, según la norma (b), estos movimientos de datos en los otros procesos funcionales que no son
afectados por la modificación del movimiento de dato(s) funcional de un proceso no deben ser identificados y contados
como modificados.
4.4.2 Tamaño del software funcionalmente modificado
Después del cambio funcional de una pieza de software, su nuevo tamaño total equivale al tamaño
original, más el tamaño funcional de todos los nuevos movimientos de datos, menos el tamaño
funcional de todos los movimientos de datos retirados. Los movimientos de datos modificados no
tienen influencia sobre el tamaño de la pieza de software ya que estos existen tanto antes como
después de que las modificaciones han sido realizadas.
4.5. Extensiones del método de medición COSMIC.
4.5.1. Introducción
El método de medición COSMIC de tamaño funcional no pretende medir todos los aspectos del
software ‘tamaño’. Así, el método de medición COSMIC actualmente no está diseñado para
proporcionar una forma estándar de contabilidad del tamaño de ciertos tipos de Requisitos
funcionales de Usuario, especialmente algoritmos matemáticos complejos o secuencias de normas
complejas que se encontraron en sistemas expertos.
También, la influencia del número de atributos por movimiento de datos sobre software en el tamaño
del software no es capturado por este método de medición. La influencia sobre el tamaño de la
manipulación de sub-procesos de datos es tenida en cuenta para simplificar la suposición de que es
válido sólo para determinados dominios de software, tal como se define en la sección 1.1.1 sobre la
aplicabilidad del método.
Otros parámetros tales como ‘complexión’ (no obstante definido) se podrían considerar que
contribuyen al tamaño funcional. Un debate constructivo sobre esta cuestión es si primero se
requerirían definiciones comunes acordadas de los otros elementos dentro de la mala noción definida
de ‘tamaño’ como se aplica al software. Tales definiciones son todavía, en este punto, objeto de
investigación y de mucho debate.
Sin embargo, la medida de tamaño COSMIC se considera una buena aproximación para el estado del
método propuesto y el dominio de aplicabilidad. Sin embargo, puede ser que dentro del entorno local
de una organización que utilice el método de medición COSMIC, se desee para tener en cuenta esa
funcionalidad en una forma que sea válida como una norma local. Por esta razón, el método de
medición COSMIC tiene disposición para extensiones locales.
Cuando esas extensiones locales son utilizadas, los resultados de medición deben ser comunicados
según la convención especial presentada en la sección 5.1.
Las siguientes secciones muestran como extender el método con un estándar local.
4.5.2. Extensiones locales con algoritmos complejos.
Si se considera necesario para tener en cuenta algoritmos complejos, puede organizarse un estándar
local para esta funcionalidad excepcional. En cualquier proceso funcional donde existe una
anormalmente compleja manipulación de datos de un sub-proceso funcional, el medidor está libre de
asignar su propia determinación-local de puntos de función.

Ejemplo: Una extensión local de la norma puede ser: “En nuestra organización, un punto de función local FP se asigna a
algoritmos matemáticos como (lista de definiciones locales y ejemplos bien entendidos). Dos puntos de función locales FP’s
son asignados para (otra lista de ejemplos), etc.”
4.5.3. Extensión Local con sub-unidades de medida
Cuando se necesita más precisión en la medición de los movimientos de datos, entonces se puede
definir una sub-unidad de medida. Por ejemplo, un medidor puede ser sub-dividido en 100
centímetros o 1000 milímetros. Análogamente, el movimiento de un único atributo podría ser utilizado
como sub-unidad de medida. Las mediciones sobre una pequeña muestra de software en los ensayos
de campo de COSMIC indican que en la muestra medida, el número promedio de atributos de datos
por movimiento de datos no varía mucho en los cuatro tipos de movimiento de datos. Por esta razón y
por motivos de facilitar las mediciones, la unidad de medida de COSMIC, 1 CFP, ha sido fijada en el
nivel de un movimiento de datos. Sin embargo, la precaución es claramente necesaria cuando se
comparan los tamaños medidos en CFP (puntos de función COSMIC) de dos piezas de software
distintas donde el número promedio de atributos datos por movimiento difiere notablemente en
ambas.
Cualquiera que desee perfeccionar el método COSMIC al introducir una sub-unidad de medida es
libre de hacerlo, pero debe dejar claro que el tamaño resultante medido no se expresa en el estándar
de puntos de función COSMIC.

5
INFORME DE MEDIDAS
El modelo de software genérico puede ser representado en una matriz donde las filas representen
procesos funcionales (los cuales puedan ser agrupados en capas), las columnas representan grupos
de datos y las celdas describen el sub-proceso identificado (Entrada, Salida, Lectura y Escritura).
Esta representación del Modelo de Software Genérico se presenta en el apéndice A.
Los resultados de medida COSMIC deben ser reportados y archivados de acuerdo a las siguientes
normas:
5.1 Etiquetado
Al informar de un tamaño funcional COSMIC se debería etiquetar de acuerdo a la siguiente regla,

relacionada con el estándar ISO/IEC 14143-1:2007.
Reglas – Etiquetado de las medidas COSMIC
Los resultados de medida COSMIC se deberían anotar como “x CFP(v.y)”, donde:

• “x” representa el valor numérico del tamaño funcional
• “v.y” representa la identificación de la versión estándar del método COSMIC usado
para obtener el valor numérico del tamaño funcional “x”.
Nota: Si un método de aproximación local se usó para obtener la medida, pero aparte la
medida se hizo utilizando las normas de la versión estándar COSMIC, la regla de
etiquetado anterior debería utilizarse, pero en algún sitio se deberá anotar el uso del
método de aproximación.-ver sección 5.2.
Ejemplo: Un resultado obtenido empleando las reglas de este Manual de Medición se debería denotar como ‘x CFP
(v3.0.1)’.
Cuando se usan extensiones locales, como se define en la sección 4.5, el resultado de la medida
debe ser informado como se define a continuación:
Reglas – Etiquetado de extensiones locales COSMIC
Un resultado de medida COSMIC utilizando extensiones locales debería ser anotado

como:
“x CFP(v.y) + Z Local FP”, donde:
• “x” representa el valor numérico obtenido al agregar todas los resultados de
medidas individuales de acuerdo al método estándar COSMIC, versión v.y.
• “v.y” representa la identificación de la versión estándar del método COSMIC usado
para obtener el valor numérico de tamaño funcional “x”.
• “z” representa el valor numérico obtenido al agregar todos los resultados
individuales de medida obtenidos de las extensiones locales al método COSMIC.

5.2 Archivando los resultados de medida COSMIC
Al archivar los resultados de medida COSMIC, se debe mantener la siguiente información para
asegurar que el resultado sea siempre interpretable.
Reglas – Hacer informes de medidas COSMIC
Además de las medidas reales, descritas en el punto 5.1, se deberían tener en cuenta
los siguientes atributos de cada medida.
a) Identificación del componente de software medido (nombre, versión ID o
Configuración ID)
b) Las fuentes de información usadas para identificar el FUR utilizado para la medida.
c) El ámbito del software
d) Una declaración del propósito de la medida
e) Una descripción del alcance de la medida y su relación con el alcance global de una
serie de medidas relacionadas, si las hubiera. (Usar las categorías de alcance
genéricas de la sección 2.2)
f) Los usuarios funcionales del software
g) El nivel de granularidad del FUR y el nivel de descomposición del software
h) El punto en el ciclo de vida del proyecto cuando se hizo la medida (especialmente si
la medida es una estimación basada en FUR incompletas, o si en realidad se hizo
sobre la bases de funcionalidad repartida).
i) El objetivo o margen de error que se cree para la medida
j) Indicaciones de si el método de medida estándar COSMIC fue utilizado, y/o se usó
una aproximación local al método estándar y/o se utilizaron extensiones locales (ver
sección 4.5). Usar las reglas de etiquetado de las secciones 5.1 y 5.2.
k) Una indicación de si la medida es de funcionalidad desarrollada o entregada
(funcionalidad “desarrollada” se obtiene creando nuevo software; funcionalidad
“entregada” incluye funcionalidad desarrollada y también incluye funcionalidad
obtenida por otros medios diferentes a crear nuevo software, p.ej: incluir todas las
formas de reutilización de software existente, el uso de parámetros existentes para
añadir o cambiar funcionalidad, etc.).
l) Una indicación de si la medida es de funcionalidad recientemente proporcionada o si
es el resultado de un “incremento” de actividad (p.ej: la suma es de funcionalidad
añadida, cambiada o borrada-ver 4.4)
m) Una descripción de la arquitectura de capas de las que está hecha la medida, si es
aplicable
n) El número de componentes importantes, si es aplicable, cuyos tamaños han sido
añadidos para el tamaño total grabado
o) Para cada alcance dentro del alcance global de la medida, una matriz de medida,
como se especifica en el apéndice A
p) El nombre del medidor y cualquier certificado de cualificación de COSMIC

Apéndice A
APÉNDICE A – DOCUMENTANDO LA MEDICIÓN COSMIC - FFP
La siguiente estructura de matriz puede ser usada para contener los resultados de la mediciones para
cada componente identificado del modelo de software al ser medido. Cada alcance dentro del alcance
global tiene su propia matriz.
FASE DE REPRESENTACIÓN
• Cada grupo de datos identificados se registra en una columna.
• Cada proceso funcional es registrado en una línea específica, agrupados por componente
identificado.
FASE DE MEDICIÓN
• Por cada proceso funcional identificado, los movimientos de datos identificados son anotados en
su correspondiente celda de la siguiente manera: “E” para una Entrada, “X” para una Salida, “R”
para una Lectura y “W” para una Escritura.
• Por cada proceso funcional identificado, los movimientos de datos se suman por tipo y cada total
es registrado en la columna correspondiente en el extremo derecho de la matriz.
• El resumen de la medición puede ser calculado y registrado en los recuadros de cada
componente, en la línea de “TOTAL”.

Apéndice B
APÉNDICE B – RESUMEN DE LOS PRINCIPIOS DEL MÉTODO COSMIC
La siguiente tabla identifica los principios del método COSMIC de medición con el propósito de una
referencia precisa.
ID DESCRIPCIÓN PRINCIPAL
P-01 El modelo contextual de Software de COSMIC

a) El hardware es la frontera del software.
b) El software, típicamente, se estructura en capas.
c) Una capa puede contener una o más partes separadas de software semejante y
cualquier parte de software puede por tanto constar de varios componentes
semejantes separados.
d) Cualquier parte de software a medir, debe ser definida por su alcance de aplicación de
medición, que debe estar enteramente contenido en una sola capa.
e) El alcance de una parte de programa a medir depende del propósito de la medición.
f) Los usuarios funcionales de una parte de software deben ser identificados de los
requerimientos funcionales de usuario de una parte de software a medir como los
emisores y/o supuestos destinatarios de datos.
g) Una parte de software interactúa con sus usuarios funcionales a través de movimientos
de datos dentro de un entorno y esa parte de programa puede mover datos hacia y
desde un almacenamiento permanente dentro de dicho entorno.
h) Los requisitos funcionales de usuario deben ser expresados en diferentes niveles de
granularidad.
i) El nivel de granularidad al que las mediciones debería hacerse normalmente es el de
los procesos funcionales.
j) Si no es posible medir en el nivel de granularidad los procesos funcionales, entonces
los requisitos funcionales de usuario del software debe ser medido por aproximación y
escalado al nivel de granularidad del proceso funcional.
P-02 El Modelo Genérico de Software COSMIC

a) El software recibe entradas de datos de sus usuarios funcionales y produce unas
salidas de datos, y/u otros resultados, para los usuarios funcionales.
b) Los requerimientos del usuario funcional de una parte de software a medir se puede
asignar a un proceso funcional único.
c) Cada proceso funcional consta de sub-procesos
d) Un sub-proceso puede ser tanto un movimiento como una manipulación de datos.
e) Cada proceso funcional es activado por un movimiento de una entrada de datos de un
usuario funcional el cual informa al proceso funcional de que el usuario funcional ha
identifico un evento
f) Un movimiento de datos mueve un único grupo de datos.
g) Un grupo de datos consta de un único juego de atributos de datos que describen un
único objeto de interés.
h) Hay cuatro tipos de movimientos de datos. Una Entrada introduce un grupo de datos
al software de un usuario funcional. Una Salida manda un grupo de datos desde el
programa a un usuario funcional. Una Escritura mueve un grupo de datos desde el
software al almacenamiento permanente. Una Lectura mueve un grupo de datos
desde el almacenamiento permanente al programa.
i) Un proceso funcional debe incluir al menos un movimiento de Entrada de datos y

también otro de Escritura o Salida, esto es, al menos dos movimientos de datos.
j) Como una aproximación a efectos de medición, los sub-procesos de manipulación de
datos o se miden por separado; la funcionalidad de cualquier manipulación de datos se
asume que debe ser contada por el movimiento de datos al que se encuentra
asociada.
P-03 Principio de medida de COSMIC

El tamaño funcional de una parte de software es directamente proporcional al número de
sus movimientos de datos
P-04 Capa
a) El software en una capa intercambia datos con el software de otra capa mediante sus
respectivos procesos funcionales.
b) La ‘dependencia jerárquica’ entre capas es tal que el software en una capa puede usar
los servicios funcionales de cualquier software en una capa jerárquicamente inferior.
Done existan ese tipo de relaciones de uso, designamos a la capa que usa el software
como la ‘superior’ y cualquiera que contenga el software usado como su ‘subordinada’.
El software en la capa superior confía en los servicios del software en dichas capas
subordinadas para funcionar correctamente; la subordinada confía a su vez en el de
sus capas inferiores para funcionar correctamente, y así sucesivamente hacia abajo en
la jerarquía. Inversamente, el software en una capa subordinada junto con el software
de cualquier capa de la que dependa puede funcionar sin necesidad de los servicios
del software de ninguna de las capas superiores en la jerarquía.
c) El software de una capa no necesita usar todas las funcionalidades suministradas por
el software de una capa subordinada.
d) Los datos que se intercambian entre programas en dos capas cualquiera es definido
en interpretado de forma diferente en el respectivo FUR de dos partes del software,
esto es, dos partes del programa reconoce diferentes atributos de datos y/o subgrupos
de datos que intercambian. En cualquier caso debe existir también una o más atributos
o subgrupos de datos definidos en común para permitir al programa en la capa
receptora interpretar los datos enviados por el programa en la capa emisora, de
acuerdo a las necesidades de recepción del programa.
P-05 Componentes semejantes

a) En un conjunto de componentes semejantes de una parte del programa dentro de una
capa no hay dependencia jerarquía entre los componentes como la que hay entre las
capas. El FUR de todos los componentes similares de una parte del programa en
cualquier capa están en el ‘mismo nivel’ en la jerarquía de capas.
b) Todos los componentes semejantes de una parte del programa deben cooperar
mutuamente para que esa parte del programa pueda funcionar correctamente.
c) Un grupo de datos puede ser intercambiado directamente entre dos componentes
semejantes de una parte del programa a través de un proceso funcional de un primer
componente realizando una Salida que es recibido por una Entrada por un proceso
funcional del segundo componente. Alternativamente el intercambio puede tener lugar
indirectamente a través del proceso funcional de un primer componente enviando
haciendo una Escritura de un grupo de datos que puede luego ser recuperado
mediante una lectura de un proceso funcional del segundo componente.
P-06 Aplicando el Modelo Genérico de Software COSMIC

El Modelo Genérico de Software COSMIC debe ser aplicado a los requerimientos del
usuario funcional para cada parte separada del programa para la que se haya definido un
alcance de medición diferente.
‘Aplicando el Modelo Genérico de Software COSMIC’ significa identificar el conjunto de
sucesos de activación detectados para cada uno de los usuarios funcionales (tipos),
identificados en el FUR, y después identificar los correspondientes procesos funcionales,

objetos de interés, grupos de datos y movimientos de datos que deben darse para
responder a esos sucesos.
P-07 Grupos de datos

a) Cada grupo de datos identificado debe ser único y distinguible a través de su colección
única de atributos de datos.
b) Cada grupo de datos debe estar directamente relacionado con un objeto de interés en
los Requisitos Funcionales de Usuario (FUR), del programa.
c) Un grupo de datos se materializa dentro del sistema del ordenador que soporta el
programa.
P-08 Entrada (E)

a) Una entrada debe mover un único grupo de datos que describen a un único objeto de
interés desde un usuario funcional a través del entorno a un proceso funcional del que
esta Entrada forme parte. Si la entrada de un proceso funcional comprende más de un
grupo de datos, identificar una Entrada para cada grupo de datos únicos (ver también
sección 4.1.7. sobre unicidad de movimiento de datos).
b) Una Entrada no debe enviar datos que crucen la frontera, ni lee ni escribe datos.
c) Donde un proceso funcional necesite obtener datos de un usuario funcional pero más
tarde no necesite que se le diga que datos enviar o el usuario funcional es incapaz de
reaccionar a ningún 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.
Sin embargo, cuando un proceso funcional deba obtener algún dato de un usuario
funcional y el proceso funcional deba decirle al usuario funcional con datos que
después requieran rellenar la petición, contar una Salida para la petición y una Entrada
para la devolución de los datos pedidos (para más información ver sección 4.1.9).
P-09 Salida (X)

a) Una Salida debe mover un único grupo de datos que describa un único objeto de
interés del proceso funcional del que la salida forma parte, a través de la frontera,
hacia un usuario funcional. Si la Salida de un proceso funcional comprende más de un
grupo de datos, identificar una Salida para cada grupo único de datos (ver también
sección 4.1.7).
b) Una Salida no introduce datos a través de la frontera, ni lee ni escribe datos.
P-10 Lectura (R)

a) Una Lectura debe mover un único grupo de datos que describa a un único objeto de
interés de un almacenamiento permanente a un proceso funcional del cual forma parte
la lectura. Si los procesos funcionales deben recuperar más de un grupo de datos del
almacenamiento permanente, identificar una Lectura por cada grupo de datos único
que es recuperado (ver también la sección 4.1.7 ‘Movimiento de datos únicos’).
b) Una Lectura no debe recibir ni enviar datos a través de la frontera, ni escribir datos.
c) Durante un proceso funcional, el movimiento o manipulación de constantes o variables
que son internas al proceso funcional y que pueden ser cambiadas solo por un
programador, o un cómputo de resultados intermedios de un cálculo, o datos
almacenados por un proceso funcional que resultan sólo de la implementación, en
lugar de del FUR, no deben ser considerados como movimientos de Lectura.
d) Un movimiento de Lectura siempre incluye alguna funcionalidad de ‘petición de
Lectura’ (así que no se debe contar nunca un movimiento separado de datos para
ninguna ‘petición del Lectura’). Véase también sección 4.1.9.
P-11 Escritura (W)

a) Una Escritura debe mover un único grupo de datos que describa un único objeto de

interés del proceso funcional del que la Escritura forma parte al almacenamiento
permanente. Si el proceso funcional debe mover más de un grupo de datos al
almacenamiento permanente, identificar una escritura para cada único grupo de datos
que se mueva al almacenamiento permanente (ver también sección 4.1.7).
b) Una Escritura no debe recibir ni enviar datos a través de la frontera, ni leer datos.
c) Un requerimiento para borrar un grupo de datos de un almacenamiento permanente
debe ser medido como un único movimiento de datos de Escritura.
d) Durante un proceso funcional, el movimiento o la manipulación de los datos que no
continúan cuando el proceso funcional es completado, o la actualización de variables
las cuales son internas al proceso funcional, o resultados producidos por un cálculo
intermedio no deben ser considerados como una Escritura.
P-12 Manipulación de datos asociada con movimiento de datos

Toda manipulación de datos en un proceso funcional debe ser asociado con uno de los
cuatro tipos de movimientos (E, X, R, y W). Por convenio, se asume que los movimientos
de datos de un proceso funcional representan la manipulación de datos del proceso
funcional.

Apéndice C
APÉNCIDE C – RESUMEN DE LAS REGLAS DEL METODO COSMIC
Con el propósito de ser unas referencias precisas, la siguiente tabla identifica cada regla del método
COSMIC
ID DESCRIPCIÓN DE LA REGLA
R-01 Alcance
a) El alcance de una Medición del Tamaño Funcional (FSM), debe ser derivada de los
propósitos de la medición.
b) El alcance no debe extenderse sobre más de una capa del software a medir.
R-02 Capa
a) Si el software se concibe usando una arquitectura establecida en capas según el
modelo COSMIC, entonces dicha arquitectura se debe utilizar para identificar las
capas a efectos de medición.
b) En el dominio de MIS o software de gestión, la capa superior (por ejemplo, la capa que
no está subordinada a ninguna otra capa), está normalmente referenciada como la
capa de ‘aplicación’. El software en esta capa confía en los servicios del software en
todas las otras capas para funcionar correctamente. En el dominio del software en
tiempo real la ‘capa superior’ se referencia normalmente como ‘sistema’ (como por
ejemplo en el ‘software del sistema de control de proceso’, ‘software del sistema de
control de vuelo’…).
c) No debe asumirse que cualquier software que se ha desarrollado fuera de cualquier
consideración de diseño o estructura puede ser particionada en capas acorde al
modelo COSMIC.
R-03 Usuarios Funcionales

a) Los usuarios funcionales de una parte del software medido deben deducirse del
propósito de la medición.
b) Cuando el propósito de una medición de una parte del software se relaciona con el
esfuerzo para desarrollar o modificar una parte del software, entonces los usuarios
funcionales deben ser aquellos para quienes se desarrolla la nueva o modificada
funcionalidad.
R-04 Frontera
a) Identifica al usuario o usuarios funcionales que interactúan con el software que está
siendo medido. La frontera se encuentra entre los usuarios funcionales y el software.
b) Por definición hay una frontera entre cada par de capas identificadas donde el
software en una capa es el usuario funcional del software en la otra, y la última es la
que será medida.
c) Hay una frontera entre cualquiera de dos partes de software, incluyendo dos
componentes cualquiera que son semejantes entre sí; en este caso cada parte del
software y/o cada componente pueden ser un usuario funcional del otro.
R-05 Nivel de granularidad de los procesos funcionales

a) La medida del tamaño funcional debe hacerse en el nivel de granularidad de los
procesos funcionales.
b) Cuando la medición de un proceso funcional necesita de algún FUR que no haya
evolucionado aún al nivel donde todos los procesos funcionales han sido identificados
y todos los detalles de sus movimientos de datos han sido definidos, deben hacerse

las mediciones sobre la funcionalidad que ha sido definida, y luego escaladas al nivel
de granularidad del proceso funcional (ver el documento ‘Advanced and Related
Topics’ para encontrar métodos de medición aproximada, como por ejemplo ‘estimar
un tamaño funcional anterior en el proceso de conocer un FUR).
R-06 Procesos Funcionales

a) Un proceso funcional debe ser derivado de al menos un Requisito Funcional de
Usuario dentro del alcance acordado.
b) Un proceso funcional debe ser ejecutado cuando ocurre un evento de activación
identificable.
c) Un suceso específico puede activar uno o más procesos funcionales que se ejecuten
en paralelo. Un proceso funcional específico puede ser activado por más de un
suceso.
d) Un proceso funcional abarcará al menos dos movimientos de datos, una Entrada más
una Salida o una Escritura.
e) Un proceso funcional debe pertenecer enteramente al alcance de medición de una
parte del software en una y sólo una capa.
f) En el contexto de un software de tiempo-real un proceso funcional debe considerarse
terminado cuando entra en un estado de espera auto inducido (por ejemplo, el proceso
funcional que hace todo lo requerido en respuesta de la activación de un evento y
espera hasta que recibe la próxima Entrada que lo activa).
g) Un proceso funcional debe ser identificado incluso si su Requisito Funcional de
Usuario permite que el proceso funcional pueda ocurrir con diversos subconjuntos de
su máximo número de atributos de datos de entrada, e incluso aunque tales
variaciones y/o diferentes valores de datos de entrada puedan dar lugar a diferentes
caminos de proceso a través del proceso funcional.
h) Deben distinguirse eventos separados y por lo tanto procesos funcionales separados
en los siguientes casos:
• Cuando las decisiones dan lugar a eventos diferentes separados en el tiempo
(ejemplo, introducir una orden de datos hoy y después confirmar la aceptación de
esa orden requieren decisiones separadas y deben ser considerados como
procesos funcionales separados).
• Cuando la responsabilidad de las diferentes actividades no es única (ejemplo, en
un sistema personal donde la responsabilidad de mantener los datos personales se
encuentra separada de mantener los datos que identifican un pago; o para un
paquete implementado de software donde es responsabilidad del administrador el
mantenimiento, y eso está separado de la funcionalidad disponible para el usuario
normal).
R-07 Entrada (E)

a) El grupo de datos de una Entrada que activa un proceso puede constar de sólo un
atributo de datos que simplemente informa al software de que ‘un evento Y ha
sucedido’. Muy a menudo, especialmente en aplicaciones de gestión este tipo de
entradas tienen varios atributos de datos que informan al programa de que ‘un evento
Y ha sucedido, y aquí están los datos sobre ese evento en particular’.
b) Los tics de reloj que disparan sucesos deben ser siempre externos al software que se
mide. Así, por ejemplo, un evento activado por un tic que sucede cada 3 segundos
debe ser asociado con un movimiento de Entrada de un atributo de datos. Nótese que
no hay diferencia si el evento es generado periódicamente por hardware o por otro
programa externo a la frontera del software que se está midiendo.
c) Salvo que un proceso funcional específico sea necesario, obtener el tiempo del reloj
del sistema no debe considerarse que causa una Entrada.
d) Si una ocurrencia de un evento específico dispara la Entrada de un grupo de datos
que comprende ‘n’ atributos de datos de un objeto de interés en particular y el FUR
permite que otras ocurrencias del mismo evento puedan activar una Entrada de un

grupo de datos que contiene valores de atributos para sólo un subconjunto de los ‘n’
atributos del objeto de interés entonces sólo debe identificarse una Entrada, que
comprenda los ‘n’ atributos de datos.
R-08 Salida (X)

a) Todos los mensajes y datos de salida generados por el software sin interacción del
usuario (por ejemplo, mensajes de error), deben ser considerados como valores de un
atributo de un objeto de interés (los cuales pueden ser llamados ‘indicación de error’).
Por lo tanto, será identificada para representar todas estas ocurrencias una sola Salida
dentro de cada proceso funcional donde son requeridas por los FUR.
b) Si una Salida de un proceso funcional mueve un grupo de datos con ‘n’ atributos de un
objeto de interés en particular y el FUR permite que el proceso funcional pueda tener
una ocurrencia de una Salida que mueve un grupo de datos con valores de atributos
de sólo un subconjunto de ‘n’ atributos de un objeto de interés, entonces debe ser
considerada una Salida, que comprende los ‘n’ atributos de datos.
R-09 Unicidad de movimiento de datos y posibles excepciones

a) A menos que un Requisito Funcional de Usuario especifique otra cosa, todos los
atributos de datos que describen cualquier objeto de interés que es requerido para ser
incorporado en un proceso funcional, y la manipulación de datos asociada debe ser
identificada y contada como una única Entrada.
(Nota: Un proceso funcional puede, por supuesto, ser requerido para múltiples
procesos de Entrada, cada una moviendo un grupo de datos describiendo un objeto
de interés diferente).
La misma regla se aplica a cualquier movimiento de datos de Lectura, Escritura o
Salida en cualquier proceso funcional).
b) Más de un movimiento de Entrada de datos, cada uno moviendo un grupo de datos
que describe el mismo objeto de interés en un proceso funcional dado, puede ser
identificado y contado si hay un Requisito Funcional de Usuario de estas Entradas
múltiples. Similarmente, más de un movimiento de Entrada que mueve el mismo grupo
de datos en el mismo proceso funcional, pero cada uno con diferentes datos
manipulados, puede ser identificado y contado si hay un Requisito Funcional de
Usuario para estas Entradas múltiples.
Ese FUR puede presentarse cuando, en un proceso funcional, las múltiples entradas
originadas desde diferentes usuarios funcionales introducen diferentes grupos de
datos (cada uno describiendo el mismo objeto de interés).
La misma regla se aplica a cualquier movimiento de datos de Lectura, Escritura o
Salida en cualquier proceso funcional.
c) Repetidas ocurrencias de un tipo de movimiento de datos (por ejemplo, mover el
mismo grupo de datos con la misma manipulación de datos), no debe ser identificada
y contada más de una vez en ningún proceso funcional.
d) Incluso si las múltiples ocurrencias de un tipo de movimiento de datos en un proceso
funcional dado difieren en la manipulación de datos asociada porque los diferentes
valores de los atributos de datos en el grupo de datos movidos dan como resultado el
seguir diferentes caminos de proceso, el tipo de movimientos de datos no debe ser
identificado y contado más de una vez en el proceso.
R-10 Cuando un proceso funcional requiere datos de un usuario funcional

a) Un proceso funcional debe obtener un grupo de datos en una Entrada de datos de un
usuario funcional, cuando no necesita decirle al usuario funcional qué datos enviar,
como en uno de los siguientes cuatro casos:
• cuando un usuario funcional envía una Entrada que acciona el inicio del proceso
funcional;
• cuando un proceso funcional, habiendo recibido una Entrada de activación,
espera, la llegada de otra Entrada adicional desde el usuario funcional, (puede

ocurrir cuando una persona introduce datos a la aplicación software);
• cuando un proceso funcional habiendo empezado, pide al usuario funcional
‘envíame tus datos ahora, si tienes algo que enviar’, y el usuario funcional envía
sus datos;
• cuando un proceso funcional, habiendo empezado, inspecciona el estado de un
usuario funcional y recupera los datos que necesita.
En los últimos dos casos (ocurren típicamente en las aplicaciones de tiempo real), por
convenio no se identificará ninguna Salida del proceso funcional para obtener los datos
requeridos. El proceso funcional necesita simplemente enviar un mensaje de aviso al
usuario funcional y la funcionalidad del mensaje de aviso se considera parte de la
Entrada. El proceso funcional sabe qué datos espera. Sólo se necesita una Entrada
para esta casa.
b) Cuando un proceso funcional necesita obtener los servicios de un usuario funcional
(como paso previo a obtener datos), y el usuario funcional necesita que le digan qué
enviar (típicamente esto ocurre cuando el usuario funcional es otra parte del software
fuera del alcance del software que está siendo medido), deben ser identificados un par
de movimientos de datos de Entrada/Salida. La Salida contiene la petición de los datos
específicos; la Entrada contiene los datos devueltos.
R-11 Comandos de control en el dominio de las aplicaciones de gestión

En el dominio de una aplicación de gestión ‘los comandos de control’ serán ignorados
pues no implican ningún movimiento de datos sobre un objeto de interés.
R-12 Agregación de los resultados de la medición

a) Para cualquier proceso funcional, los tamaños funcionales de los movimientos de
datos individuales serán agregados en un solo valor de tamaño funcional en unidades
CFP, sumándolas aritméticamente.
Tamaño (proceso funcionali) = ∑ tamaño(Entradasi)i+ ∑ tamaño(Salidasi) +
∑ tamaño(Lecturasi) + ∑ tamaño (Escriturasi)
b) Para cualquier proceso funcional, el tamaño funcional de los cambios de sus
Requisitos Funcionales de Usuario serán agregados desde los tamaños de los
movimientos de datos que han sido añadidos, modificados o borrados en el proceso
funcional para dar un tamaño del cambio en unidades CFP, de acuerdo a la siguiente
fórmula.
Tamaño (Cambios(proceso funcionali)) =
∑ tamaño (movimiento de datosi añadido) +
∑ tamaño (movimiento de datosi modificado) +
∑ tamaño (movimiento de datosi eliminados)
Para más información sobre la agregación del tamaño funcional ver sección 4.3.2.
Para la medición del tamaño de los cambios del software, ver sección 4.4.
c) El tamaño de cualquier cambio de una parte del software dentro del alcance definido
será obtenido por la agregación de los tamaños de los procesos funcionales de cada
parte, sujeto a las reglas e) y f) de abajo.
d) El tamaño de cualquier cambio de una parte del software dentro del alcance definido
será obtenido sumando los tamaños de todos los cambios de todos los procesos
funcionales de cada parte, sujeto a las reglas e) y f) de más abajo.
e) Los tamaños de las partes del software o de los cambios de las partes del software
dentro de las capas pueden ser sumado sólo si se miden en el mismo nivel de
granularidad del proceso funcional de su FUR.
f) Además, los tamaños de las partes del software y/o los cambios de los tamaños de
una parte del software dentro de una capa o de diferentes capas serán sumados sólo
si tiene sentido hacerlo así, según el propósito de la medición.
g) El tamaño de una parte del software no puede ser obtenido sumando los tamaño de

sus componentes (sin importar cómo se subdivide), a menos que las contribuciones
del tamaño de los movimientos de datos entre componentes se eliminen.
h) Si el método COSMIC se extiende localmente (por ejemplo para medir algunos
aspectos de tamaño no cubierto por el método estándar), entonces el tamaño medido
por la extensión local debe documentarse separadamente como se describe en la
sección 5.1 y no debe añadirse al tamaño obtenido por el método estándar, medido en
CFP (ver en la sección 4.5).
R-13 Modificación de un movimiento de datos

a) Si un movimiento de datos debe ser modificado debido a un cambio en la
manipulación de los datos asociada al movimiento de datos y/o debido a un cambio en
el número o tipo de atributos en el grupo de datos movidos, un CFP cambiado será
medido, sin importar el número real de modificaciones en el movimiento de datos.
b) Si un grupo de datos debe ser modificado, los movimientos de datos que mueven los
grupos de datos modificados cuya funcionalidad no se ve afectada por la modificación
al grupo de los datos no será identificado como movimientos de datos cambiados.
NOTA 1: Una modificación a un valor de una ocurrencia de un atributo, tal como una
modificación en un código de un atributo cuyo valor venga dado por un sistema de
codificación no es una modificación del tipo del atributo.
NOTA 2: Una modificación a cualquier dato que aparece en pantallas de entrada o salida
que no estén relacionadas con un objeto de interés para un usuario funcional no debe
identificarse como un CFP cambiado (ver la sección 3.3.4 para ejemplos de ese tipo
de datos).
R-14 Etiquetado de la medida COSMIC

El resultado de una medida COSMIC debe ser denotada como ‘x CFP (v.y)’ donde:
• ‘x’ representa el valor numérico del tamaño funcional,
• ‘v.y’ representa la versión estándar del método COSMIC usado para la obtención del
valor del tamaño funcional ‘x’.
NOTA: Si se ha usado un método de aproximación local para obtener la medida, pero
además la medida se hizo usando las convenciones de una versión estándar de
COSMIC, el etiquetado anterior debe ser usado, pero el uso de ese método de
aproximación debería ser anotada de alguna manera – ver sección 5.2.
R-15 Etiquetado de la extensiones locales de COSMIC

El resultado de una medida COSMIC usa las extensiones locales denotadas como:
‘x CFP (v. y) + z Local FP’, donde:
• ‘x’ representa el valor numérico obtenido sumando todos los resultados de la medición
del método estándar COSMIC, versión v.y,
• ‘v.y’ representa la versión del método estándar COSMIC usado para obtener el valor
del tamaño funcional ‘x’,
• ‘z’ representa el valor numérico obtenido sumando todos los resultados individuales
obtenidos de las extensiones locales del método COSMIC.
Informes de medida COSMIC
R-16
Además de las medidas reales, deberían ser registrados los siguientes atributos de cada
medición.
a) Identificación del componente software medido (nombre, identificación de la versión o
identificación de la configuración).
b) Las fuentes de información empleadas para la identificación de los FUR en la
medición.
c) El dominio del software.

d) Una declaración del propósito de la medición.
e) Una descripción del alcance de la medición, y su relación con el alcance global de un
conjunto relacionado de medidas, si las hubiere (usar las categorías de alcance
genéricas de la sección 2.2).
f) Los usuarios funcionales del software.
g) El nivel de granularidad de los FUR y el nivel de descomposición del software.
h) El punto del ciclo de vida del proyecto en que la medida fue hecha (especialmente si la
medida es una estimación basada en FUR incompletos, o fue hecha en base a una
funcionalidad entregada realmente).
i) El objetivo o margen de error supuesto en la medición.
j) Indicaciones de si se ha usado la medición estándar del método COSMIC, y/o una
aproximación local para el método estándar, y/o cualquier extensión local (ver sección
4.5). Usar las convenciones de etiquetado de las secciones 5.1 o 5.2.
k) Una indicación de si la medida es de funcionalidad desarrollada o entregada (la
funcionalidad ‘desarrollada’ se obtiene creando software nuevo; la entregada incluye la
desarrollada y también la obtenida por cualquier otro medio que no sea la creación de
nuevo software como por ejemplo todas las formas de reutilización de software
existente, el uso de parámetro preexistentes para añadir o cambiar funcionalidad,
etc.).
l) Una indicación de si la medición es de una nueva funcionalidad suministrada o es el
resultado de una actividad de ‘mejora’ (por ejemplo la suma de una funcionalidad
añadida, cambiada y borrada - ver 4.4).
m) Si fuera aplicable, una descripción de la arquitectura de las capas en la cuales la
medición fue realizada.
n) Si fuera aplicable, el número de componentes principales, cuyos tamaños se han
sumado para el tamaño total registrado.
o) Para cada alcance dentro del alcance de medición global, una matriz, según lo
especificado en el apéndice A.
p) El nombre de la persona que hace la medición y las acreditaciones de calidad
COSMIC.

Apéndice D
APÉNDICE D – HISTORIA DEL MÉTODO COSMIC
Este apéndice contiene un resumen de los principales cambios desde la versión 2.2 a través de la
versión 3.0 a la versión 3.0.1. del método COSMIC de medición del tamaño funcional. La versión 2.2
del método fue descrita en el ‘Manual de Medición v2.2’ (abreviado como ‘MM’), pero desde la versión
3.0 en adelante la documentación del método está distribuida en cuatro documentos, sólo uno de los
cuales es el ‘Manual de Medición’.
El propósito del apéndice es permitir a un lector que esté familiarizado con el MM v2.2 rastrear los
cambios que se han hecho para las versiones 3.0 y 3.0.1 y cuando sea necesario para comprender
su justificación. (Para los cambios realizados en la obtención de la versión 2.2 desde la versión 2.1,
consulte la versión 2.2 del Manual de medición, Apéndice E)
De la versión 2.2 a la versión 3.0
En la tabla siguiente se enseña los principales cambios hechos desde la versión 2.2 a la versión 3.0,
se hace referencia a los dos boletines de la actualización del método (‘MUB’). Un MUB es publicado
por COSMIC para proponer mejoras al método entre cambios importantes de versión. Los dos MUB
son:
• MUB 1 “Mejoras propuestas para las definiciones y características de una ‘capa’ de software”,
publicado in Mayo de 2003.
• MUB 2 “Mejoras propuestas para la definición de un ‘objeto de interés’ ”, publicado en Marzo de
2005.
En el proceso de actualización del método de la versión 2.2 a la versión 3.0, se ha hecho un esfuerzo
para distinguir entre ‘principios’ y ‘reglas’, y separar de ellos todos los ejemplos. Cambios como estos
y muchas mejoras en la redacción no se han descrito en la siguiente tabla.
V2.2 Ref V3.3 Ref Cambios
Reestructuración del Método COSMIC
2.2, 2.7, 1.5, Una fase de la ‘Estrategia de Medición’ ha sido separada como la
3.1, 3.2 Capítulo primera fase, de lo que ahora es un método en tres fases.
2
La fase de la Estrategia de Medición ahora incluye consideraciones
sobre ‘capas’, ‘fronteras’, y ‘usuarios (funcionales)’, los cuales se
consideran parte de la fase de representación en el MM v2.2.
Reestructuración del Manual de Medición
En la producción de la v3.0 del Método COSMIC, el MM v2.2 ha sido

partido en cuatro documentos para facilitar su uso
• ‘COSMIC Method v3.0: Documentation Overview and Glossary of
Terms’’ (nuevo)
• ‘COSMIC Method v3.0: Method Overview’ (Capítulos 1 y 2 del MM
v2.2)
• ‘COSMIC Method v3.0: Measurement Manual’ (Capítulos 3, 4 y 5 y
los apéndices del MM v2.2
• ‘COSMIC Method v3.0: Advanced and Related Topics’ (Capítulos 6
y 7 del MM v2.2)

Las referencias al pasado y los trabajos de investigación se han quitado
del MM. Éstos están ahora disponibles en www.gelog.etsmtl.ca/cosmic-
ffp. Las únicas referencias que quedan de estos cuatro documentos se
ofrecen en las notas al pie de página.
Capítulo Capítulo El capítulo sobre la fase de medición se ha reestructurado

4 4 considerablemente para ofrecer una exposición más lógica.
Apéndice -- Este apéndice sobre ‘Más información de las capas del software’ ha
D sido eliminado, por ser incompatible con MUB 1 y añadir poco valor.
Véanse también las notas a continuación sobre los cambios teniendo
en cuenta MUB 1.
Cambios en la terminología de los nombres
General El nombre ‘COSMIC-FFP’ del método ha sido simplificado por método ‘COSMIC’.
5.1 4.2 El nombre de la unidad de medición, ‘unidad de tamaño funcional

COSMIC’ (abreviado como ‘Cfsu’) ha sido cambiado a ‘Punto de
Función COSMIC’ (abreviado como ‘CFP’). Ver el Prólogo del MM v3.0
para la explicación de este cambio.
4.1 4.1.7 La regla de ‘des duplicidad de los movimientos de datos’ ha sido

renombrada como la regla de ‘Unicidad de movimientos de datos’.
Conceptos nuevos, reemplazados y eliminados
2.7 2.3 Los conceptos de ‘abstracción’, ‘punto de vista’, ‘Punto de vista de

Medición’, la ‘Medición del Punto de vista del Usuario final’ y ‘Punto de
vista del desarrollador de la Medición’ han sido eliminados. Se han
remplazado por un concepto más general de que el tamaño funcional
de una parte del software a medir depende de la funcionalidad que se
pondrá a disposición del ‘usuario o usuarios funcionales’ del software.
Estos deben ser identificables en los Requisitos Funcionales de
Usuario del software a medir. La definición de ‘usuario o usuarios
funcionales’ es por tanto un requisito previo para la definición de qué
tamaño debe ser medido o para la interpretación de un tamaño de
medición existente. Ver el Prólogo del MM v3.0 para más detalles de la
explicación de este cambio.
3.2 2.3 El concepto de ‘usuario’ (definido en ISO/IEC 14143/1) ha sido

reemplazado por el concepto de ‘usuario funcional’ el cual es un
concepto más restrictivo.
Ver el Prólogo del MM v3.0 para más detalles de la explicación de este
cambio.
En 2.3.2, han sido introducidos dos ejemplos de dónde el tamaño
funcional varía con el tipo de usuario funcional identificado en el FUR,
para un teléfono móvil y para un paquete de una aplicación de gestión.
-- 2.2.2 El ‘nivel de descomposición’ del software a medir ha sido introducido en

la discusión del alcance de la medición.
-- 2.4 El ‘nivel de granularidad’ de los requisitos funcionales de usuario del

software a medir ha sido introducido en la discusión de la estrategia de
la medición. Se da un ejemplo para la comprensión. Ver el Prólogo del

MM v3.0 para más detalles de la explicación de este cambio.
-- 2.4.3 El ‘nivel de granularidad de un proceso funcional’ ha sido definido y se

han dado unas reglas y unas recomendaciones.
3.4 4.2 El concepto de ‘grupo permanente de datos’ incluye tres niveles de

permanencia, llamados ‘transitorio’, ‘corto’ y ‘por tiempo indefinido’ ha
sido eliminado por ser innecesario. Se ha introducido el concepto de
‘almacén permanente’.
4.1 -- El concepto de ‘des duplicación’ ha sido eliminado como resultado de

ser innecesario.
Mejores definiciones y perfeccionamiento de los principios y reglas
2.3 2.2 La definición de ‘Requisitos Funcionales de Usuario’ ha sido cambiada

conforme a la edición de 2007 de ISO/IEC 14143/1
2.4.1 1.3 El ‘Modelo de Contexto del Software’ ha sido extendido y perfeccionado

como una declaración de principios.
2.4.2 1.4 El ‘Modelo Genérico del Software’ ha sido extendido y refinado como
una declaración de principios.
2.4, 3.1 2.2.3, La definición de ‘capa’ ha sido modificada teniendo en cuenta MUB 1.
2.2.4, Las Figuras 2.4.1.1, 2.4.1.2 y 2.4.1.3 del MM v2.2 las cuales se usaron
para ilustrar la interacción de los usuarios con el software en ‘capas’
3.1
fueron sustituidas en la v3.0 por las Figuras 2.2.3.1 y 2.2.3.2 ilustrando
una típica arquitectura física con capas y las Figuras 3.1.1 y 3.1.2
ilustrando la interacción lógica de los usuarios funcionales con el
software en capas. El objetivo de este cambio es distinguir más
claramente la visión física de los programas típicos de las arquitecturas
de capas de la visión lógica de una interacción del usuario funcional
con una parte del software a medir de acuerdo con el modelo COSMIC.
-- 3.2.4 El concepto de ‘componente semejante’ ha sido definido y sus

principios han sido establecidos tomando como referencia MUB1.
2.5 4.2, 4.3 Las ‘Características’ del proceso de medición descritas en v2.2 han
sido establecidas como un conjunto de principios y reglas en v3.0.
2.6 2.4 El material de ‘midiendo el proyecto en una fase temprana: escalado de

la medición’ ha sido tratada en parte en la sección 2.4 del MM v3.0
conforme al ‘Nivel de Granularidad’ y está elaborado en el documento
‘COSMIC Method v3.0: Advanced and Related Topics’.
2.7 2.2 Una nota ha sido añadida para la definición del ‘alcance’ para
distinguirlo del ‘alcance total’ de un ejercicio de medida (el cual incluye
varias partes separadas del software que deben ser medidas) del
‘alcance’ de un tamaño de medida individual.
3.2 4.1.8 Los tres ejemplos que ilustran la interacción de los usuarios a través de
una frontera con el software en diferentes capas y desde diferentes
‘puntos de vista’ de medición han sido movidos y reescritos con la
intención de eliminar los ‘puntos de vista de la medición’. Véase el

punto 4.1.8 (del MM v3.0), más abajo.
-- 3.1 Se ha añadido un principio relativo al Modelo Genérico de la aplicación

del software a medir.
3.3 3.2.1 La definición de ‘proceso funcional’ se ha perfeccionado para tener en

cuenta la introducción del concepto de ‘usuario funcional’, que sustituye
a la de 'actor' en la definición.
3.3 3.2.1 La definición de ‘evento que activa’ ha sido perfeccionada.
-- 3.2.1 La relación entre un evento que activa, un usuario funcional, la

activación de una Entrada y proceso funcional, se aclara en la Figura
3.1.1.
3.1 3.2.2 Los principios y reglas para un ‘proceso funcional’ se han fusionado en
un conjunto revisado de normas.
-- 3.2.3, Se han introducido algunos ejemplos de procesos funcionales y de

3.2.4, cómo distinguirlos.
3.2.5
-- 3.3.1 Se ha introducido la definición de un ‘objeto de interés’, en línea a MUB

2.
3.4 3.3.3 Los ejemplos de la identificación de los objetos de interés y los grupos
de datos se han separado de las normas para los grupos de datos.
Material específico de los convenios de análisis de datos de entidad-
relación han sido trasladados a la ‘Guideline for sizing Business
Application Software v1.0’.
-- 3.3.4 Se ha dado una guía ‘para los datos o grupos de datos que no son
candidatos a movimientos de datos’.
-- 3.3.5 Se dan orientaciones sobre cuándo, generalmente en software en

tiempo real, puede que no valga la pena distinguir un ‘usuario funcional’
de 'un objeto de interés’ sobre qué datos son movidos.
3.5 3.4 La discusión de los ‘atributos de datos’ se ha reducido y simplificado

desde que la consideración de los atributos de datos no es una parte
obligatoria del método.
4.1 4.1.1 Se ha racionalizado la definición de un ‘movimiento de datos’.
4.1 4.1.7 Las reglas sobre ‘des duplicación de movimientos de datos’ (ahora
llamadas como normas de ‘unicidad de movimiento de datos y posibles
excepciones’) han sido mucho más claras con varios ejemplos
añadidos.
4.1 -- Reglas específicas para cada dominio sobre los movimientos de datos
de Lectura y Escritura que actualizan procesos funcionales han sido
trasladados al documento ‘Guideline for sizing Business Application
Software v1.0’.
4.1 4.1.8 ‘Las reglas para la correspondencia de datos a través de la frontera’

(las cuales en el MM v2.2 se aplicaron a ‘Los puntos de vista del

desarrollador de la medición’, los cuales han sido eliminados), han sido
borradas pero los conceptos se han combinado con los Casos dados
previamente en la sección 3.2 del MM v2.2, para hacer una nueva
sección sobre ‘cuándo los procesos funcionales mueven datos hacia o
desde un almacenamiento permanente’.
4.1 4.1.6 Se ha definido la ‘Manipulación de Datos’ y se ha añadido un principio

sobre la ‘manipulación de datos asociada con los movimientos de
datos’. Se ha ampliado la guía sobre la manipulación de datos asociada
con los diferentes tipos de movimientos de datos.
4.1.1 4.1.2 Se han racionalizado los principios y reglas para una Entrada. Se ha
añadido un nuevo principio relativo a la funcionalidad de la ‘petición de
entrada’.
4.1.2 4.1.3 Se han racionalizado los principios y reglas de una Salida incluyendo la
eliminación de la referencia al ‘punto de vista del usuario final’.
4.1.3 4.1.4 Se han racionalizado los principios de una Lectura. Se ha añadido un

nuevo principio concerniente a la funcionalidad de la ‘petición de
lectura’.
4.1.4 4.1.5 Se han racionalizado los principios de una Escritura.
-- 4.1.9 Se han añadido nuevas reglas sobre ‘cuándo un proceso funcional

requiere datos de un usuario funcional’.
-- 4.1.10 Se ha introducido una definición y una regla para el concepto de

‘comando de control’ los cuales son sólo válidos en el dominio de las
aplicaciones de gestión.
4.1.5 4.5 Se ha ampliado la discusión sobre ‘las extensiones locales del método’.
4.3 4.3 Se han cambiado los principios de ‘agregación de los resultados de la

medición’ por reglas y se ha ampliado para cubrir las normas sobre la
obtención del tamaño de una parte de software mediante la suma de
los tamaños de sus componentes. El MM v2.2 se refiere sólo a esas
reglas en el concepto de ‘los puntos de vista de desarrollador de la
medición’. Esta restricción se ha eliminado.
-- 4.4 Se ha añadido una nueva sección con nuevas reglas sobre ‘la medición
del tamaño de los cambios en el software’.
5.1 5.1 Las reglas del etiquetado de los resultados de la medición de la medida
han sido cambiadas para reconocer el cambio de la unidad de medida
de ‘Cfsu’ a ‘CFP’.
5.2 5.2 Para incluir más artículos se han ampliado las reglas sobre la
‘presentación de informes de la medida’.
Apéndice B Apéndice Actualizados a los principios de la v3.0

B
Apéndice C Apéndice Actualizados a las Reglas de la v3.0

C

De la versión 3.0 a la versión 3.0.1
El cambio más importante se encuentra de la versión 3.0 a la 3.0.1 en la mejora de la redacción de

algunas definiciones, principios y normas, y algunas partes del texto. Con la excepción de un error,
las mejoras han sido realizadas por razones de claridad. La mayoría de los cambios se han publicado
en tres Boletines de Actualización del Método anteriores a la versión 3.0.1.
• MUB 3: ‘Corrección de un error en la Figura 4.1.8.1 (b) del Manual de Medición del Método
COSMIC v3.0’, publicado en Junio de 2008.
• MUB 4: ‘Aclaración de los principios y reglas de la funcionalidad de ‘Petición de entrada’ en el
Manual de Medición del Método COSMIC v3.0’, publicado en Junio de 2008.
• MUB 5: ‘Mejoras propuestas para (a) Definiciones del ‘Nivel de Descomposición’ y de
‘Componentes Semejantes’, y (b) Principio c) para un ‘Componente Semejante’, publicado en
Febrero de 2009.
Además, se han hecho varias mejoras en la redacción. Principalmente mediante una separación más
clara de los ejemplos en el texto principal, utilizando un tipo diferente de fuente y la introducción de
más secciones.
Resumen de los cambios principales:
V 3.0.1 Cambio
2.2.3 Para mayor claridad se ha cambiado la definición del ‘Nivel de Descomposición’ (MUB
5).
2.2.4 En la definición de ‘Capa’, el término ‘arquitectura del software’ se ha sustituido por el

de ‘sistema software’, ya que el término arquitectura implica que el software ya está
dividido.
Regla c) eliminada. Esta fue una regla general de diseño de software y no específica
para las capas y a la medición. La referencia al ‘Apéndice D’ en la versión 3.0 era
incorrecta.
2.2.5 Para mayor claridad se insertó la definición de ‘Semejante’ y se cambió la definición de

‘Componente Semejante’. El principio c) para el ‘Componente Semejante’ cambió a un
principio que es más importante para FSM.
La Figura 2.2.5.1 se añade para aclarar la relación entre los componentes semejantes y
las partes
semejantes del software (MUB 5).
2.3.2 La regla c) de los límites ha cambiado para mayor claridad (consecuencia de MUB 5).
2.4.3 En la Figura 2.4.3.1, dos cuadros en la esquina derecha de la parte inferior, ‘método de
pago’ se ha cambiado por ‘medios de pago’, ya que éste es un término mejor para, por
ejemplo, cheque, tarjeta de crédito, etc.
3.2.2 La regla e) para un proceso funcional se ha visto limitada por la adición de las palabras
en cursiva. Ahora es: ‘Un proceso funcional se corresponde totalmente al alcance de la
medición de sólo una parte de una aplicación de software, y sólo a una capa’. Esta
limitación existe en la directriz para el dimensionamiento de Aplicaciones de Negocios
Software' v1.1, pero es válida para el software de cualquier dominio.
3.2.6 Nueva sección añadida titulada ‘Procesos funcionales de componentes semejantes’.

Este texto está tomado en gran parte del documento ‘Guideline for Sizing Business

Application Software’ v1.1, pero es válida para el software de cualquier dominio. Esto
está relacionado con el cambio a la regla e) en el punto 3.2.2.
4.1.2 El principio c) para una Entrada ha sido cambiado para mayor claridad de cómo darse
cuenta de una ‘Petición de entrada’ (MUB 4).
4.1.7 Para mayor claridad del significado deseado, ha sido cambiada la frase inicial de la
sección sobre ‘Unicidad de Datos y Posibles Excepciones’ de la regla a). El ejemplo 2
también ha sido ampliamente modificado para mayor claridad.
4.1.8 La Figura 4.1.8.1 (b) ha cambiado para corregir un error sobre cómo un controlador de
dispositivo interactúa con el hardware (MUB 3).
4.1.9 Para mayor claridad se han cambiado las reglas sobre ‘Cuándo un proceso funcional
requiere datos de un usuario funcional’, y los ejemplos relacionados (MUB 4).

Apéndice E
APÉNDICE E – PROCEDIMIENTO DE SOLICITUD DE CAMBIOS Y
COMENTARIOS
El Comité de Prácticas de Medición COSMIC (MPC) está ansioso de recibir opiniones, comentarios y
si es necesario, Solicitudes de Cambio para el Manual de Medición COSMIC. Este apéndice precisa
cómo comunicarse con el COSMIC MPC.
Todas las comunicaciones con el COSMIC MPC deben ser enviadas por e-mail a la siguiente
dirección:
mpc-chair@cosmicon.com
Opiniones y Comentarios Generales de manera Informal
Los comentarios y/u opiniones concernientes al Manual de Medición, tales como las dificultades de
comprensión o la aplicación del método COSMIC, sugerencias para la mejora general, etc. se deben
enviar por e-mail a la dirección antes mencionada. Los mensajes se registran y, en general, serán
revisados en un plazo máximo de dos semanas desde la recepción. El MPC no puede garantizar
ninguna acción en respuesta a estos comentarios generales.
Solicitud de los cambios de manera formal
Podrán ser presentadas una solicitud formal de cambio (‘CR’), cuando el lector del manual de
medición crea que hay un error en el texto, por la necesidad de aclaraciones, o algunas necesidades
de mejora de texto.
Las CR’s formales serán tomadas en dos semanas desde la recepción. Cada CR recibirá entonces un
número de serie y será reenviada a los miembros del COSMIC MPC, un grupo mundial de expertos
en el método COSMIC. Su ciclo normal de revisión lleva al menos un mes y puede ser más si el CR
es difícil de resolver.
Como resultado de la revisión el CR puede ser aceptado, rechazado o ‘dejado en espera para un
discusión más profunda’ (este último caso por ejemplo si hay una dependencia de otro CR), y la
salida será comunicada al Remitente tan pronto como sea posible.
Una petición formal de cambio sólo se aceptará si se documenta con toda la información siguiente:
• Nombre, cargo y organización de la persona que presenta la solicitud de cambio.

• Datos de contacto de la persona que presenta la solicitud de cambio.
• Fecha de presentación.
• Declaración general de los efectos de la petición de cambio (por ejemplo, "es necesario mejorar
el texto... ').
• Texto real que necesita cambiarse, sustituirse o eliminarse (o su clara referencia).
• Texto adicional o de sustitución propuesta.
• Explicación completa de por qué el cambio es necesario.
En el sitio www.cosmicon.com está disponible un formulario para la presentación de una petición de

cambio.
Finalmente, la decisión resultante por el MPC COSMIC de una petición de cambio y, si se acepta, se
aplicará en la versión del Manual de Medición de la petición de cambio.

Preguntas sobre la aplicación del método COSMIC.
El MPC COSMIC lamenta el no ser capaz de responder a preguntas relacionadas con el uso o
aplicación del método COSMIC. Existen organizaciones comerciales que pueden proporcionar la
formación y la consultoría o apoyo para la aplicación del método. Por favor, consulte la web
www.cosmicon.com para más detalles.


Spanish - COSMIC - v3-0-1 PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Spanish - COSMIC - v3-0-1 PDF

Enviado por

Direitos autorais:

Formatos disponíveis

El Método COSMIC del Tamaño Funcional del Software

Revisores de la Versión 2.0 1998/1999 (por orden alfabético)

Manual de Medición, Método COSMIC Versión 3.0.1. Copyright © 2009. 2

Hannu Toivonen, Nokia Siemens Frank Vogelezang, Sogeti, The

* Editores de las versiones 3.0 y 3.0.1 del método COSMIC

Equipo de traducción de la Versión 3.0.1 de COSMIC al Español

Manual de Medición, Método COSMIC Versión 3.0.1. Copyright © 2009. 3

FECHA REVISORES Modificaciones / Añadidos

Manual de Medición, Método COSMIC Versión 3.0.1. Copyright © 2009. 4

Los principales cambios de esta versión 3.0 del Método COSMIC

Manual de Medición, Método COSMIC Versión 3.0.1. Copyright © 2009. 5

Todos estos cambios se resumen en el Apéndice D.

Consecuencias principales de los cambios en mediciones existentes

Manual de Medición, Método COSMIC Versión 3.0.1. Copyright © 2009. 6

Manual de Medición, Método COSMIC Versión 3.0.1. Copyright © 2009. 7

Manual de Medición, Método COSMIC Versión 3.0.1. Copyright © 2009. 8

2 FASE DE ESTRATEGIA DE MEDICIÓN ........................................................................................17

3 FASE DE REPRESENTACIÓN .......................................................................................................34

Manual de Medición, Método COSMIC Versión 3.0.1. Copyright © 2009. 9

4 FASE DE MEDICIÓN ......................................................................................................................45

5 INFORME DE MEDIDAS .................................................................................................................64

APÉNDICE A – DOCUMENTANDO LA MEDICIÓN COSMIC - FFP ...................................................66

APÉNDICE B – RESUMEN DE LOS PRINCIPIOS DEL MÉTODO COSMIC ......................................67

APÉNCIDE C – RESUMEN DE LAS REGLAS DEL METODO COSMIC ............................................71

APÉNDICE D – HISTORIA DEL MÉTODO COSMIC ...........................................................................77

APÉNDICE E – PROCEDIMIENTO DE SOLICITUD DE CAMBIOS Y COMENTARIOS .....................84

Manual de Medición, Método COSMIC Versión 3.0.1. Copyright © 2009. 10

1.1 Aplicabilidad del método COSMIC

1.1.1 Dominios de aplicación

1.1.2 Dominio no aplicable

1.1.3 Limitaciones de los factores que contribuyen a tamaño funcional

Además, dentro de su dominio de aplicabilidad, el método de medición de tamaño funcional COSMIC

Manual de Medición, Método COSMIC Versión 3.0.1. Copyright © 2009. 11

1.2 Requisitos Funcionales de Usuarios

El método de medición COSMIC supone la aplicación de un conjunto de modelos, principios, reglas y

Data Artifacts from

Functional User Requirements (‘FUR’) in the

Figura 1.2.1 – Modelo COSMIC de la pre-implementación de los requisitos funcionales de usuario

Manual de Medición, Método COSMIC Versión 3.0.1. Copyright © 2009. 12

1.2.2 Deducción de los requisitos funcionales de usuario a partir de software instalado

Functional User Requirements (‘FUR’) in the

Figura 1.2.2 – Modelo COSMIC de la post-implementación de los requisitos funcionales de usuario

Manual de Medición, Método COSMIC Versión 3.0.1. Copyright © 2009. 13

1.3 Modelo COSMIC de Contexto de Software

Principios del Modelo COSMIC de Contexto de Software:

1.4 Modelo Genérico del Software

Manual de Medición, Método COSMIC Versión 3.0.1. Copyright © 2009. 14

Principios del Modelo de Software COSMIC Genérico:

1.5 El Proceso de Medición COSMIC

El proceso de medición COSMIC se compone de tres fases:

• La Fase de Estrategia de Medición, en la cual el Modelo de Contexto de Software se aplica al

Manual de Medición, Método COSMIC Versión 3.0.1. Copyright © 2009. 15

Functional User Requirements (FUR) in the Chapter 4

The Measurement Process

Figura 1.5 – Estructura del método COSMIC

Manual de Medición, Método COSMIC Versión 3.0.1. Copyright © 2009. 16

COSMIC MEASUREMENT STRATEGY PHASE

Section 2.1 Section 2.2

Figure 2.0 – El proceso de determinar la Estrategia de Medición

Manual de Medición, Método COSMIC Versión 3.0.1. Copyright © 2009. 17

El término 'propósito' es usado en su significado inglés.

Definición – Propósito de la medición

2.1.1 El propósito de una medición determina el tamaño que será medido