Spanish - COSMIC - v3-0-1 PDF

E El l M M t to od do o C CO OS SM MI IC C d de el l T Ta am ma a o o F Fu un nc ci io on na al l d de el l S So of ft tw wa ar re e
V Ve er rs si i n n 3 3. .0 0. .1 1

M
M
a
a
n
n
u
u
a
a
l
l
d
d
e
e
M
M
e
e
d
d
i
i
c
c
i
i
n
n

(Gua COSMIC de implementacin de ISO/IEC 19761: 2003)

Mayo de 2009
Manual de Medicin, Mtodo COSMIC Versin 3.0.1. Copyright 00!.
"ll rights reser#ed. $he Co%%on So&t'are Measure%ent International Consortiu% (COSMIC)

A Ag gr ra ad de ec ci im mi ie en nt to os s
Equipo Principal de Autores de la Versin 2.0
1
de COSMIC (por orden alfabtico)
Alain Abran, cole de technologie suprieure Universidad de Qubec,
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 Versin 2.0 1998/1999 (por orden alfabtico)
Moritsugu Araki, JECS Systems
Research, Japan
Thomas Fetcke, Germany Patrice Nolin, Hydro Qubec,
Canada
Fred Bootsma, Nortel, Canada Eric Foltin, University of Magdeburg,
Germany
Marie ONeill, Software Management
Methods, Ireland
Denis Bourdeau, Bell Canada,
Canada
Anna Franco, CRSSM, Canada Jolijn Onvlee, The Netherlands *
Pierre Bourque, , Cole de
Technologie suprieure, Canada
Paul Goodman, Software
Measurement Services,United
Kingdom
Laura Primera, UQAM, Canada
Gunter Guerhen, Brhen & Partner,
Germany
Nihal Kececi, University of Maryland,
United States
Paul Radford, Charismatek, Australia
Sylvain Clermont, Hydro Qubec,
Canada
Robyn Lawrie, Australia Eberhard Rudolph, Germany
David Dry, CGI, Canada Ghislain Lvesque, UQAM, Canada Grant Rule, Software Measurement
Services, United Kingdom*
Gilles Desoblins, France Roberto Meli, Data Processing
Organization, Italy
Richard Stutzke, Science
Applications Intl Corporation, United
States
Martin DSouza, Total Metrics,
Australia
Pam Morris, Total Metrics, Australia* Ilionar Sylva, UQAM, Canada
Reiner Dumke, University of
Magdeburg, Germany
Risto Nevalainen, Software
Technology Transfer Finland,
Finland *
Vinh T. Ho, UQAM, Vietnam
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 versin 2.0 fue la primera versin pblicamente disponible del mtodo COSMIC-FFP, tal como fue conocida

3

Revisores de la Versin 3.0 2006/07 (por orden alfabtico)
Alain Abran, cole de Technologie
Suprieure, Universit du Qubec,
Canada
Jean-Marc Desharnais, Software
Engineering Lab in Applied Metrics
SELAM, Canada
Arlan Lesterhuis*, Sogeti, The
Netherlands
Bernard Londeix, Telmaco, United
Kingdom
Roberto Meli, Data Processing
Organization, Italy
Pam Morris, Total Metrics, Australia
Serge Oligny, Bell Canada Marie ONeill, Software Management
Methods, Ireland
Tony Rollo, Software Measurement
Services, United Kingdom
Grant Rule, Software Measurement
Services, United Kingdom
Luca Santillo, Agile Metrics, Italy Charles Symons*, United Kingdom
Hannu Toivonen, Nokia Siemens
Networks, Finland
Frank Vogelezang, Sogeti, The
Netherlands

* Editores de las versiones 3.0 y 3.0.1 del mtodo COSMIC

Equipo de traduccin de la Versin 3.0.1 de COSMIC al Espaol
Juan J. Cuadrado-Gallego, EVALA
Software Measurement Consulting,
Spain. jjcg@cosmicon.com
Cristina Albarrn, EVALA Software
Measurement Consulting, Spain
Alfonso Gnzalez, EVALA
Software Measurement Consulting,
Spain
Ivan Pinedo, EVALA Software
Isaac Snchez, EVALA Software
Roi Vzquez, EVALA Software
Measurement Consulting, Spain.
La traduccin de la Versin 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 Comn 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 ttulo de la
publicacin, su nmero de versin, 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 especfico.
Una versin de dominio pblico del Manual de Medicin COSMIC y otros informes tcnicos,
incluyendo traducciones a otros idiomas se pueden encontrar en la Web en
www.gelog.etsmtl.ca/cosmic-ffp

*
C Co on nt tr ro ol l d de e v ve er rs si io on ne es s
La tabla siguiente muestra la historia de las versiones de este documento
FECHA REVISORES Modificaciones / Aadidos
31-03-99 Serge Oligny Primer borrador, emiti los comentarios de los revisores
31-07-99 Vase Agradecimientos Revisado, incluyendo comentarios de los revisores
06-10-99 Vase Agradecimientos Revisado, incluyendo comentarios del IWSM 99 workshop
2

29-10-99 Equipo Principal de
COSMIC
Revisado, comentarios finales antes de la publicacin del
ensayo prctico de la versin 2.0.
01-05-01 Equipo Principal de
COSMIC
Revisado conforme a la norma ISO/IEC 14143-1: 1998 + las
aclaraciones sobre las normas de medicin de la versin 2.1.
31-01-03 Comit de Prcticas de
Medicin COSMIC
Revisado conforme a la norma ISO/IEC FDIS 19761: 2002 +
las aclaraciones sobre las normas de medicin de la versin
2.2
Medicin COSMIC
Revisado para ms aclaraciones y aadidos de las normas de
medicin de la versin 3.0, particularmente en el rea de la
fase de la estrategia de medicin. El nombre del mtodo fue
cambiado de mtodo COSMIC-FFP al de mtodo COSMIC.
En la actualizacin a la v3.0 de la v2.2, se separaron partes del
Manual de Medicin v2.2 en otros documentos vase el
prlogo a continuacin y el Apndice D
Medicin COSMIC
Revisada la versin 3.0 a v3.0.1 para hacer mejoras en la
redaccin y aclaraciones menores, y para distinguir ejemplos
ms claramente. Esta versin tambin incorpora los cambios
propuestos en los Boletines de Actualizacin del Mtodo
(MUB), 3, 4 y 5. Vase el Apndice D para obtener ms
detalles sobre estos cambios.

2
Procedimientos del Taller Internacional de la Medicin del Software IWSM 99, Lac Suprieur, Qubec, Canad, 8-10 de
Septiembre de 1999. Vase para ms detalle http://www.gelog.etsmtl.ca/iwsm99/index2.html.

+
P Pr r l lo og go o
El propsito del mtodo COSMIC es proporcionar un mtodo estandarizado de medicin del tamao
funcional de software para los dominios funcionales comnmente denominados como Software de
Aplicaciones de Negocio ( Management Information Systems, MIS) y Software de Tiempo Real.
El mtodo COSMIC fue aceptado por el ISO/IEC JTC1 SC7 en diciembre de 2002 como el Estndar
Internacional ISO/IEC 19761 Ingeniera del Software - COSMIC-FFP - Mtodo de Medicin de
Tamao 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 mtodo. El propsito del Manual de Medicin es no slo proporcionar estas normas y
definiciones, sino tambin proporcionar una explicacin ms detallada y muchos ms ejemplos a fin
de ayudar a los medidores a comprender plenamente y poder aplicar el mtodo. Sin embargo, a
medida que se ha ido adquiriendo ms y ms experiencia con el mtodo, se ha encontrado valioso
aadir reglas y ejemplos para afinar las definiciones de algunos de los conceptos subyacentes. El
Consorcio Comn Internacional de Medicin de Software (COSMIC) prev que estas adiciones y
mejoras se presentarn a la ISO para su inclusin en la norma ISO/IEC 19761 en la fecha prevista
para su revisin en 2007/08.
Este manual de medicin es uno de los cuatro documentos COSMIC que definen la versin 3.0 del
mtodo. Los otros tres son:
Descripcin de la documentacin y Glosario de trminos (El Glosario define todos los trminos
que son comunes a todos los documentos COSMIC. Este documento describe tambin que se
dispone de otros documentos de apoyo tales como casos de estudio y directrices de aplicacin en
dominios especficos)
Descripcin del Mtodo
Temas Avanzados y Relacionados (Este documento tratar en ms detalle las tareas que
permitan garantizar la comparacin de las mediciones de tamao funcional e incluir captulos
sobre aproximacin temprana o rpida de medicin y convertibilidad de las mediciones, los cuales
aparecieron anteriormente en la versin 2.2 del Manual de Medicin.)
A los lectores principiantes para quienes sea nueva la medicin de tamao funcional (FSM) o que
estn familiarizados con otros mtodos FSM se les recomienda encarecidamente que lean el
documento Descripcin del Mtodo antes de leer este manual de medicin.
Los principales cambios de esta versin 3.0 del Mtodo COSMIC
El cambio en la designacin de la versin del mtodo COSMIC de 2.2 a 3.0 indica que esta versin
representa un avance significativo sobre la versin anterior. Al elaborar esta versin 3.0 del Mtodo
COSMIC, a partir de la versin anterior que se define en el Manual de Medicin de la versin 2.2, los
principales cambios introducidos han sido los siguientes:
Con el fin de hacer la documentacin del Mtodo COSMIC ms fcil de aplicar, la versin 3.0 del
mtodo se define ahora en cuatro documentos.
Se han incorporado las propuestas de los dos Boletines de Actualizacin del Mtodo que fueron
publicados desde la publicacin de la ltima versin 2.2 de la Medicin Manual. Estos son MUB 1
Propuesta de Mejoras para la Definicin y Caractersticas de una Capa de Software y MUB 2
Propuesta de Mejora a la definicin de un objeto de inters. (La versin 3.0.1 incorpora tres
Boletines de Actualizacin ms ver Apndice D.)
Ha sido definida por separado una fase de Estrategia de Medicin como la primera fase del
proceso de medicin. La fase de estrategia ha sido tambin mejorada introduciendo una gua
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 comparacin de las
mediciones a travs 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 medicin manual en la versin 2.2, pueden ser
reemplazados por el concepto ms 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
tamao en una aplicacin 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 mtodo se ha cambiado de Unidad de Tamao Funcional
COSMIC (abreviado como Cfsu) a Punto de Funcin COSMIC (abreviado como CFP). Este
cambio se ha hecho para facilitar la lectura y pronunciacin, y para proporcionar al mtodo en
conformidad con otros mtodos de Puntos de Funcin. Y para obtener una mayor simplificacin,
el nombre del mtodo 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 Descripcin Documental y Glosario de Trminos.
Algunos materiales, en particular en los conceptos de anlisis de datos se han eliminado. En la
actualidad se incluyen en la Gua de Medicin de Software de Gestin utilizando COSMIC, ya
que es muy especfica para un dominio y no es especfica para el mtodo COSMIC.
Se han realizado muchas mejoras y aadidos editoriales para mejorar la consistencia de la
terminologa y para mejorar la comprensin. Entre ellas, se ha realizado una distincin ms
consistente entre los principios y las reglas del mtodo mediante la adopcin de una
convencin 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 Apndice D.
Los lectores familiarizados con la versin 2.2 del Manual de Medicin observarn que el mayor
nmero de cambios en esta versin 3.0 se encuentra en la recin separada fase de Estrategia de
Medicin.
Consecuencias principales de los cambios en mediciones existentes
Los principios originales del mtodo COSMIC han permanecido sin cambios desde su primera
publicacin en el primer borrador del Manual de Medicin 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 versin 3.0.1 del Manual de Medicin.
Los tamaos funcionales medidos de acuerdo a los principios y normas de las versiones 3.0 y 3.0.1
del Manual de Medicin pueden variar de tamao utilizando las versiones anteriores slo porque las
nuevas normas tienen la intencin de ser ms precisas. Por lo tanto disponen un margen menor de
discrecionalidad en materia de interpretacin personal de las normas que era posible con versiones
anteriores. Los cambios en el mbito de la Estrategia de Medicin y el cambio de nombre de la
unidad de medida dan lugar a diferencias triviales en las reglas para la presentacin de mediciones
en comparacin con versiones anteriores.
Explicacin de los principales cambios de la versin 2.2 a la versin 3.0 del Manual de
Medicin
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 versin pblica del Manual
de Medicin COSMIC-FFP en el ao 1999. Este es el equivalente COSMIC de, por ejemplo, una
unidad de medida estndar como el metro. Pero el tamao funcional de una aplicacin software
puede medirse de muchas maneras, y es a veces un problema, para cualquier Mtodo de Medicin
de Tamao Funcional (Functional Size Method, FSM), responder a la pregunta de qu tamao
debemos medir?

-
El primer problema es que sabemos que cualquier aplicacin software proporciona funcionalidad para
los distintos tipos de Usuarios, donde un usuario se define en la terminologa del estndar ISO/IEC
14143/1 (Principios de FSM) esencialmente como cualquier cosa que interacta con el software que
se est midiendo. De ello se deduce que el tamao funcional de una aplicacin software depende de
a quin o a qu se define como su usuario(s).
Permtanos considerar como ejemplo el software de un telfono mvil. Los usuarios podran ser un
humano que presiona los botones, los dispositivos de hardware (por ejemplo, la pantalla, teclado,
etc.) que interactan con la aplicacin, o el sistema operativo sobre el que funciona el software o,
incluso separados por aplicaciones de software que interactan con la aplicacin que se est
midiendo. Los cuatro tipos de usuarios exigen diferentes funciones (de ah que el tamao funcional
difiera en funcin de a quin o a qu se define como el usuario). Entonces, Cmo, si se nos da un
tamao funcional, vamos a saber qu o quin fue el usuario(s)?, es decir, Qu funcionalidad se
midi?
Fue esta cuestin la que inicialmente llev al Comit de Prcticas de Medicin COSMIC
(Measurement Practices Committee, MPC) a introducir en la versin 2.2 del Manual de Medicin, los
Puntos de Vista de Medicin del Usuario Final y del Desarrollador. Sin embargo, la experiencia ha
demostrado que estas definiciones, especialmente la de los Punto de Vista de la Medicin del
Desarrollador, no son lo suficientemente generales como para ayudar a definir todas las
necesidades de medicin. El MPC ha llegado a la conclusin de que la manera ms correcta y ms
general de enfocarlo es definir el concepto de Usuario Funcional y que los cambios en el tamao
funcional dependan de qu o quin es definido como el usuario funcional. La identificacin del usuario
funcional depende de la finalidad de la medicin y el usuario funcional debera 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 ms la idea de definir un Punto de
vista de la Medicin especfico.
El segundo problema es que sabemos que los FUR evolucionan a medida que el proyecto avanza y,
dependiendo de cmo se mida el tamao, su tamao puede parecer que crece. La primera versin
del FUR de una nueva aplicacin 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 tamao 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 cmo 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 Medicin ofrecen recomendaciones sobre este aspecto, que es especialmente importante
cuando los tamaos son medidos a principios de la vida de un proyecto cuando los FUR estn en
plena evolucin. Este aspecto se vuelve crtico cuando los tamaos son utilizados para mediciones
del funcionamiento que deben compararse a partir de diferentes fuentes, como en ejercicios de
evaluacin 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 Medicin no
tienen por qu ser nicos para el mtodo COSMIC. Son aplicables a todos los mtodos de medicin
del Tamao Funcional de Software (FSM). Debido a que el mtodo COSMIC se basa en slidos
principios de ingeniera de software y es aplicable a una gama ms amplia de dominios de software
que la 1 generacin de Mtodos FSM, ha sido reconocido el problema de definir adecuadamente
qu tamao deberamos medir? y se ha encontrado una solucin.
La mayora de medidores que utilizan COSMIC con el propsito de medir el rendimiento (por ejemplo,
para la estimacin, evaluacin comparativa, etc.), no tendrn que perder tiempo en la identificacin 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 Medicin del Manual de Medicin y el captulo
relativo a garantizar la posibilidad de comparacin de las mediciones de tamao en el documento
Temas Avanzados y Relacionados, examina con mayor profundidad los factores a considerar.

.
El Comit de Prcticas de Medicin COSMIC
Mayo 2009

!

T Ta ab bl la a d de e C Co on nt te en ni id do os s
1 INTRODUCCIN .............................................................................................................................11
1.1 Aplicabilidad del mtodo COSMIC .............................................................................................. 11
1.1.1 Dominios de aplicacin ..................................................................................................... 11
1.1.2 Dominio no aplicable ........................................................................................................ 11
1.1.3 Limitaciones de los factores que contribuyen a tamao funcional .................................. 11
1.1.4 Limitaciones en la medicin de aplicaciones software muy pequeas ........................... 12
1.2 Requisitos Funcionales de Usuarios ........................................................................................... 12
1.2.1 Extraccin de los requisitos funcionales de usuario a partir de los artefactos del software
en la prctica ..................................................................................................................... 12
1.2.2 Deduccin de los requisitos funcionales de usuario a partir de software instalado ........ 13
1.2.3 Extraccin o deduccin de los requisitos funcionales de usuario a partir de artefactos
software ............................................................................................................................. 13
1.3 Modelo COSMIC de Contexto de Software ................................................................................ 14
1.4 Modelo Genrico del Software .................................................................................................... 14
1.5 El Proceso de Medicin COSMIC ............................................................................................... 15
2 FASE DE ESTRATEGIA DE MEDICIN ........................................................................................17
2.1 Definir el propsito de la Medicin ............................................................................................. 18
2.1.1 El propsito de una medicin determina el tamao que ser medido ............................. 18
2.1.2 La importancia del propsito ............................................................................................. 19
2.2 Definir el alcance de la medicin ..................................................................................................... 19
2.2.1 El alcance de una medicin depende de la finalidad........................................................ 20
2.2.2 Tipos genricos de alcance .............................................................................................. 21
2.2.3 Niveles de descomposicin .............................................................................................. 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 tamao funcional vara 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 estndar ......................................................... 28
2.4.2 Aclaracin del nivel de granularidad ................................................................................. 29
2.4.3 El nivel de granularidad estndar ..................................................................................... 29
2.5 Observaciones finales sobre la Fase de Estrategia de la de Medicin ...................................... 32
3 FASE DE REPRESENTACIN .......................................................................................................34
3.1 Aplicacin del Modelo Genrico COSMIC de software .............................................................. 35
3.2 Identificacin de los procesos funcionales .................................................................................. 36
3.2.1 Definiciones ....................................................................................................................... 36
3.2.2 La aproximacin 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 Ms sobre procesos funcionales separados .................................................................... 40
3.2.6 El proceso funcional de componentes semejantes .......................................................... 40
3.3 Identificacin objetos de inters y grupos de datos .................................................................... 41
3.3.1 Definiciones y principios ................................................................................................... 41
3.3.2 Sobre la materializacin de un grupo de datos ................................................................ 42
3.3.3 Sobre la identificacin de objetos de inters y grupos de datos ...................................... 42
3.3.4 Grupos de datos o datos que son candidatos a movimientos de datos. .......................... 43

10
3.3.5 El usuario funcional como objeto de inters ..................................................................... 44
3.4 Identificacin de los atributos de datos (opcional) ...................................................................... 44
3.4.1 Definicin .......................................................................................................................... 44
3.4.2 Sobre la asociacin de atributos de datos y grupos de datos .......................................... 44
4 FASE DE MEDICIN ......................................................................................................................45
4.1. Identificar los movimientos de datos ........................................................................................... 45
4.1.1 Definicin de los tipos de movimientos de datos .............................................................. 46
4.1.2. Identificacin de entradas (E) ........................................................................................... 47
4.1.3. Identificacin de salidas (X) .............................................................................................. 48
4.1.4. Identificacin 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 funcin de medicin ................................................................................................ 58
4.3. Agregar resultados de medicin ................................................................................................. 58
4.3.1 Reglas generales de agregacin ...................................................................................... 58
4.3.2. Ms sobre la agregacin del tamao funcional ................................................................ 59
4.4 Ms en la medicin del tamao de los cambios de software...................................................... 60
4.4.1. Modificando funcionalidades ............................................................................................. 61
4.4.2 Tamao del software funcionalmente modificado ........................................................... 62
4.5. Extensiones del mtodo de medicin COSMIC. ............................................................................ 62
4.5.1. Introduccin ....................................................................................................................... 62
4.5.2. Extensiones locales con algoritmos complejos. ............................................................... 62
4.5.3. Extensin 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
APNDICE A DOCUMENTANDO LA MEDICIN COSMIC - FFP ...................................................66
APNDICE B RESUMEN DE LOS PRINCIPIOS DEL MTODO COSMIC ......................................67
APNCIDE C RESUMEN DE LAS REGLAS DEL METODO COSMIC ............................................71
APNDICE D HISTORIA DEL MTODO COSMIC ...........................................................................77
De la versin 2.2 a la versin 3.0 .......................................................................................................... 77
De la versin 3.0 a la versin 3.0.1 ....................................................................................................... 82
APNDICE E PROCEDIMIENTO DE SOLICITUD DE CAMBIOS Y COMENTARIOS .....................84


11
1
1

INTRODUCCIN
1.1 Aplicabilidad del mtodo COSMIC
1.1.1 Dominios de aplicacin
El mtodo de medicin del tamao funcional COSMIC est concebido para ser aplicable a la
funcionalidad del software de los siguientes dominios:
Aplicaciones Software de Gestin, las cuales son las tpicamente utilizadas para dar soporte a la
administracin de negocios, tales como banca, seguros, contabilidad, personal, compras,
distribucin o fabricacin. 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 estn
sucediendo en el mundo real. Algunos ejemplos seran el software para centrales telefnicas y de
intercambio de mensajes, el software incluido en dispositivos para el control de mquinas tales
como los electrodomsticos, ascensores, motores de automviles y aeronaves, para el control de
procesos y la adquisicin automtica de datos, y software de los sistemas operativos de los
ordenadores.
Hbridos de lo anterior, como por ejemplo los sistemas de reservas en tiempo real de compaas
areas u hoteles.
1.1.2 Dominio no aplicable
El mtodo de medicin COSMIC an no ha sido diseado para tener en cuenta la funcionalidad del
software matemticamente intensivo, esto es, software caracterizado por algoritmos matemticos
complejos o otra reglas complejas especializadas, como por ejemplo sistemas expertos, software de
simulacin, software de auto-aprendizaje, sistemas de prediccin meteorolgica, etc., o de procesado
continuo de variables tales como sonidos de audio o imgenes de vdeo, tales como, por ejemplo,
software para juegos de ordenador, instrumentos musicales, etc.
Para los programas con dicha funcionalidad es posible definir extensiones locales al mtodo COSMIC
de medicin. El manual de medicin explica en qu contextos tales extensiones locales se deben
utilizar y proporciona ejemplos de una extensin local. Cuando se usan, estas extensiones locales
deben ser reportadas de acuerdo a los convenios presentados en el captulo reportado de mediciones
de este Manual de Medicin.
1.1.3 Limitaciones de los factores que contribuyen a tamao funcional
Adems, dentro de su dominio de aplicabilidad, el mtodo de medicin de tamao funcional COSMIC
no intenta medir todos los posibles aspectos de la funcionalidad que podran considerarse para
contribuir al tamao del software. Por ejemplo, ni la influencia de la complejidad
(independientemente de su definicin), ni la influencia del nmero de atributos de datos por el
movimiento de datos en el tamao funcional del software son utilizados por este mtodo de medicin
(para ms sobre este ltimo, vase el captulo de la Fase de Representacin del Manual de
Medicin). Como se describe en la seccin 1.1.2, si as lo desea, por ejemplo, tales aspectos pueden
ser tenidos en cuenta a travs de una extensin local al mtodo de medicin COSMIC.

1

1.1.4 Limitaciones en la medicin de aplicaciones software muy pequeas
Todos los mtodos de medicin funcional estn basados en la hiptesis 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 estimacin) tamaos de software muy pequeos, y especialmente los cambios
muy pequeos de una aplicacin software, donde las consideraciones medias pueden no ser
aplicables. En el caso del mtodo COSMIC, 'muy pequeo' significa con pocos movimientos de datos.
1.2 Requisitos Funcionales de Usuarios
El mtodo de medicin COSMIC supone la aplicacin de un conjunto de modelos, principios, reglas y
procesos a los Requisitos Funcionales de los Usuarios (o Functional User Requirements, FUR) de
una determinada aplicacin software. El resultado es un valor de una cantidad numrico (tal y como
se define en ISO), que representa el tamao funcional de la aplicacin software de acuerdo con el
mtodo COSMIC.
Los tamaos funcionales medidos por el mtodo COSMIC estn diseados para ser independientes
de cualesquiera decisiones de implementacin propias de los artefactos operacionales del software
que se desea medir. "Funcionalidad" se refiere al procesamiento de la informacin que el software
debe realizar para sus usuarios.
Ms concretamente, una declaracin de FUR describe qu debe hacer el software por los usuarios
funcionales, que son los remitentes y destinatarios de los datos, hacia y desde el software. Una
declaracin del FUR excluye cualesquiera requisitos tcnicos o los de calidad que digan cmo debe
funcionar el software. (Para leer la definicin formal de FUR, vase la seccin 2.2.) A la hora de medir
el tamao funcional slo los FUR son tenidos en cuenta.
1.2.1 Extraccin de los requisitos funcionales de usuario a partir de los artefactos del software en la
prctica
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 interpretacin. Esto significa
que por lo general el medidor tendr que extraer los FUR tal y como se suministren, explcita o
implcitamente, en artefacto de software, antes de representarlos como conceptos de los modelos de
software de COSMIC.

Requirements
definition artifacts
Data
analysis / modelling
artifacts
Artifacts from
functional decomposition
of requirements
Functional User Requirements (FUR) in the
artifacts of the software to e measured
Requirements
definition artifacts
Data
analysis / modelling
artifacts
Artifacts from
functional decomposition
of requirements

Figura 1.2.1 Modelo COSMIC de la pre-implementacin de los requisitos funcionales de usuario


13
Como se ilustra en la figura 1.2.1, el FUR puede ser derivado de artefactos de ingeniera de software
que se producen antes de que el software exista. Por lo tanto, el tamao funcional del software puede
medirse antes de su implementacin como un sistema informtico.
Es importante sealar que los artefactos que se producen antes de que el software sea
implementado, por ejemplo, durante la recopilacin o el anlisis de requisitos, podran describir el
software en diferentes niveles de granularidad mientras los requisitos evolucionan - vase tambin
ms abajo la seccin 2.4.
Nota: Los requisitos funcionales de usuario pueden ser producidos antes de que sean asignados al
hardware o al software. Dado que el mtodo COSMIC est destinado a medir el FUR de una
aplicacin software, slo se medirn los FUR asignados a aplicacin software. Sin embargo, en
principio el mtodo COSMIC puede aplicarse a los FUR antes de que sean asignados a un software o
hardware, independientemente de la decisin eventual de asignacin. Por ejemplo, es sencillo medir
el tamao de funcionalidad de una calculadora de bolsillo utilizando COSMIC sin conocimiento que
hardware o software (si lo hubiera) ser utilizado. Sin embargo, la afirmacin de que el mtodo
COSMIC se puede utilizar para medir FUR asignado a hardware, necesita ms pruebas prcticas
antes de que pueda considerarse como plenamente validado sin la necesidad de ms reglas.
1.2.2 Deduccin 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 algn, o quiz slo unos pocos, artefactos de diseo o arquitectura disponibles, y el FUR
podra no estar documentado (por ejemplo, para el legado del software). En tales circunstancias, an
es posible obtener los FUR a partir de los artefactos instalados en el sistema incluso despus de que
haya sido implementado, como se ilustra en el grfico 1.2.2.

!hysical
programs
"oftware
operations
manual and
procedures
!hysical
data storage
artifacts
!hysical
programs
"oftware
operations
manual and
procedures
!hysical
data storage
artifacts
!hysical
data storage
artifacts

Figura 1.2.2 Modelo COSMIC de la post-implementacin de los requisitos funcionales de usuario

1.2.3 Extraccin o deduccin 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 ingeniera de software o para derivar de ellos el software instalado y para su
expresin en la forma requerida para la medicin en el mtodo COSMIC evidentemente variarn;
estos procesos no pueden ser tratados en el Manual de Medicin. Se asume que los requisitos
funcionales del software que ser medido bien existen o pueden ser extrados o derivados de sus
artefactos, a la luz del propsito de la medicin.

1*
El Manual de Medicin se limita, por lo tanto, a describir y definir los conceptos de modelos de
software COSMIC, es decir, los objetivos de la extraccin o derivacin. Estos conceptos estn
plasmados en un conjunto de principios establecidos en dos modelos de software COSMIC - el
Modelo de Contexto de Software y el Modelo Genrico de Software.
Estos dos modelos se describen en el documento de Descripcin del Mtodo. Los lectores que
requieran una comprensin general y una justificacin de los modelos se les refieren al documento de
Descripcin del Mtodo. Los modelos se copian a continuacin para mayor comodidad y se
exponen respectivamente en detalle en los captulos 2 y 3 del presente Manual de Medicin.
1.3 Modelo COSMIC de Contexto de Software
Una aplicacin software que va a ser medida con el mtodo COSMIC debe ser cuidadosamente
definida (en el alcance de medicin) y esta definicin debe tener en cuenta su contexto de cualquier
otro software y/o hardware con los que interacta. Este Modelo de Contexto de Software introduce el
modelo de principios y conceptos necesarios para esta definicin.
Ntese bien, Los trminos 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 especficos para el mtodo COSMIC.
Para la definicin formal, vase el documento: Descripcin Documental y Glosario de Trminos.
Todos estos trminos se explican en mayor detalle en los captulos 2, 3 y 4.
Principios del Modelo COSMIC de Contexto de Software:
a) El software est limitado por el hardware
b) El software est tpicamente estructurado en capas
c) Una capa puede contener una o ms aplicaciones de software semejante, y
cualquier aplicacin software puede consistir de uno o ms componentes del
mismo tipo separados.
d) Cualquier aplicacin software que deba medirse, se define por su alcance de
medicin, que se limitar en su totalidad dentro de una sola capa
e) El alcance de aplicacin software debe medirse en funcin de la finalidad de la
medicin
f) Los usuarios funcionales de una aplicacin software se identificarn a partir de los
FUR de la aplicacin software que se medir como los remitentes y/o
destinatarios de los datos
g) Una aplicacin software interacta con sus usuarios a travs de movimientos de
datos por una frontera y la aplicacin software puede mover datos hacia y desde
zonas de almacenamiento persistente dentro de unos lmites
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 aproximacin y escalado al nivel de
granularidad funcional del proceso
Los conceptos del Modelo de Contexto del Software se detallan en la Estrategia de medicin en el
Captulo 2 de este Manual de Medicin.
1.4 Modelo Genrico del Software
Despus de haber interpretado los FUR del software a ser medido en trminos del Modelo de
Contexto del Software, debemos ahora aplicar el Modelo Genrico del Software a los FUR para
identificar los componentes de la funcionalidad que se medirn. Este Modelo Genrico de Software
asume que los siguientes principios generales son ciertos para cualquier software que puede ser
medido con el mtodo. (Como se seala en el glosario, cualquier mtodo de medicin de tamao

1+
funcional tiene por objeto identificar los tipos y no las ocurrencias de los datos o funciones. En el
texto que figura a continuacin, el sufijo tipo ser por lo tanto omitido al mencionar los conceptos
bsicos COSMIC a menos que sea esencial para distinguir tipos de ocurrencias.)
Principios del Modelo de Software COSMIC Genrico:
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 aplicacin 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
manipulacin 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 slo grupo de datos
g) Un grupo de datos consiste en un conjunto nico de atributos de datos que
describen un nico objeto de inters.
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 almacn persistente. Una Lectura mueve
un grupo de datos desde un almacn 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 mnimo de dos movimientos de datos
j) Como una aproximacin para fines de medicin, los sub-procesos de
manipulacin de datos no se miden por separado; la funcionalidad de cualquier
manipulacin de datos se supone que se explica por el movimiento de datos con
el que est asociado
Los conceptos del Modelo Genrico de Software se detallan en la Fase de Representacin Captulo
3 del presente Medicin Manual.
Cuando el FUR a ser medido ha sido representado en el Modelo Genrico de Software, puede ser
entonces medido utilizando los procesos de la Fase de Medicin (Captulo 4). Los resultados de la
medicin deberan ser documentados de acuerdo con las convenciones del Captulo 5 Informes de
Medicin.
1.5 El Proceso de Medicin COSMIC
El proceso de medicin COSMIC se compone de tres fases:
La Fase de Estrategia de Medicin, en la cual el Modelo de Contexto de Software se aplica al
software a ser medido (Captulo 2)
La Fase de la Representacin de la Medicin, en la cual el Modelo Genrico de Software se
aplica al software a ser medido (Captulo 3)
La Fase de Medicin, en la cual se obtienen las mediciones reales (captulo 4)
El resultado de aplicar el proceso de medicin a una aplicacin software es una medida de tamao
funcional de los Requisitos Funcionales de Usuario de la aplicacin software expresada en Puntos
de Funcin COSMIC ( CFP)
La relacin entre estas tres fases del mtodo COSMIC se muestra en la Fig. 1.5.

1,
artefacts of the software to be measured
Chapter 3
Measurement
Strategy
The Measurement Process
Generic Software Model
Chapter 4
Mapping
Phase
Purpose of the
measurement. Scope of
each piece of software
to be measured
FUR in the form of the
Chapter 5
Measurement
Phase
Goals
Software Context Model
Functional
size of the
software in
units of CFP
artefacts of the software to be measured
Chapter 3
Measurement
Strategy
The Measurement Process
Chapter 4
Mapping
Phase
Purpose of the
measurement. Scope of
each piece of software
to be measured
FUR in the form of the
Chapter 5
Measurement
Phase
Goals
Software Context Model
Functional
size of the
software in
units of CFP

Figura 1.5 Estructura del mtodo COSMIC


1-
2
2

FASE DE ESTRATEGIA DE MEDICIN
En este captulo se abordan los cuatro parmetros fundamentales de medicin del tamao funcional
del software que debe ser considerados antes de comenzar a medir, estos son: el propsito y el
alcance de la medicin, la identificacin de los usuarios funcionales y el nivel de granularidad que
debe medirse. Determinar estos parmetros ayuda a abordar las cuestiones de qu tamao debe
medirse? o, para una medicin existente, cmo debemos interpretar esta medida?
Es importante sealar que estos cuatro parmetros y conceptos relacionados no son especficos del
mtodo de la medicin del tamao funcional COSMIC, pero debe ser comn a todos los mtodos
FSM (Functional Size Measurement). Otros mtodos FSM pueden no distinguir diferentes tipos de
usuarios funcionales y pueden no discutir los diferentes niveles de granularidad, etc. Slo la
aplicacin ms amplia y la flexibilidad del mtodo COSMIC requieren que se tomen en cuenta estos
parmetros ms cuidadosamente que con otros mtodos FSM.
Es muy importante guardar los datos resultantes de esta fase de Estrategia de Medicin (que se
enumeran en la seccin 5.2) al guardar el resultado de cualquier medicin. La falta de definicin y
registro de estos parmetros dar lugar a mediciones que no pueden ser interpretadas fiablemente y,
o ser utilizadas para procesos tales como la estimacin de esfuerzo del proyecto.
Las cuatro secciones de este captulo dan las definiciones formales, principios, normas y algunos
ejemplos para cada uno de los principales parmetros para ayudar al medidor a travs del proceso de
determinar una Estrategia de Medicin, como se muestra en la figura 2.0 mostrada ms abajo.
Cada seccin ofrece explicaciones de por qu el parmetro clave es importante, utilizando analogas
para mostrar por qu el parmetro se da por sentado en otros campos de medicin, razn por la cual
tambin debe ser considerado en el mbito de de medicin de tamao funcional de software.
THE
MEASUREMENT
STRATEGY
COSMIC MEASUREMENT STRATEGY PHASE
Section 2.1
Determine
PURPOSE of the
measurement
Input from the
MEASUREMENT
SPONSOR
Section 2.2
Determine
SCOPE of the
measurement
Section 2.3
Identify the
FUNCTIONAL
USERS
Section 2.4
Determine the
LEVEL OF GRANULARITY
of the measurement
ITERATE
THE
MEASUREMENT
STRATEGY
COSMIC MEASUREMENT STRATEGY PHASE
Section 2.1
Determine
PURPOSE of the
measurement
Input from the
MEASUREMENT
SPONSOR
Section 2.2
Determine
SCOPE of the
measurement
Section 2.3
Identify the
FUNCTIONAL
USERS
Section 2.4
Determine the
of the measurement
ITERATE

Figure 2.0 El proceso de determinar la Estrategia de Medicin

1.
2.1 Definir el propsito de la Medicin
El trmino 'propsito' es usado en su significado ingls.
Definicin Propsito de la medicin
Una declaracin que define por qu una medida es necesaria, y para qu se utilizar el
resultado
2.1.1 El propsito de una medicin determina el tamao que ser medido
Hay muchas razones para medir el tamao 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, podra ser necesario medir el tamao funcional del software antes de
su desarrollo, del mismo modo que podra ser necesario medir las superficies de una casa antes de
su construccin. En un contexto diferente, por ejemplo, cuando se necesitan comparar con los costes
reales con los estimados, tal vez sea necesario medir el tamao funcional del software una vez se ha
puesto en produccin, del mismo modo que podra ser til medir las superficies de una casa despus
de haber sido construida para comprobar que las dimensiones se ajustan a los planes convenidos. La
razn 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 medicin.
En el ejemplo anterior de la casa, la medicin de su superficie antes de la construccin se basa,
obviamente, en los planos de construccin. 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 tamao 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 extradas de estos aparatos que usando los convenios adecuados y las dimensiones
necesarias (el nmero de movimientos de datos) se identifican de modo que se pueda calcular el
tamao.
Para continuar con la analoga de la casa, la medicin de su superficie despus de que haya sido
construida implica un proceso de medicin diferente. Ahora, las dimensiones (longitud y anchura) son
extradas del propio edificio utilizando una herramienta diferente (cinta mtrica). Sin embargo, a pesar
de que el objeto fsico que se mide es diferente (la casa en lugar de sus planos), las dimensiones, la
unidad de medida (incluyendo cualquier convencin de escala) y todos los principios de medicin
siguen siendo los mismos.
Del mismo modo, medir el tamao funcional del software despus de que haya sido puesto en la
produccin implica un proceso diferente de medicin 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 medicin siguen siendo los mismos.
Es decisin del medidor, basndose en el propsito de la medicin, determinar si el objeto a ser
medido es la casa a partir de la descripcin verbal de su propietario; la casa, tal como se describe a
travs de los planos; o la casa, una vez que ha sido construida; as como seleccionar los artefactos
ms apropiados para la medicin. Es evidente que los tres tamaos podran ser diferentes. El mismo
razonamiento se aplica a la medicin de software.
/0/M12OS3 "lgunos propsitos t4picos de la %edicin
Medir el tamao de los FUR a medida que evolucionan, como entrada a un proceso de
estimacin del esfuerzo de desarrollo
Medir el tamao de los cambios de FUR despus de haber sido inicialmente acordados, con el fin
de gestionar el alcance avanzado de un proyecto

1!
Medir el tamao de los FUR a la entrega de software como entrada para la medicin del
rendimiento de los desarrolladores
Medir el tamao de los FUR del software se han entregado, y tambin el tamao de los FUR del
software que han sido desarrollado, con el fin de obtener una medida funcional de la reutilizacin
Medir el tamao de los FUR de los programas existentes, como entrada a la medicin del
desempeo de los responsables de mantener y sostener el software
Medir el tamao de algunos cambios en (el FUR de) un sistema de software existente, como una
medida del tamao de un proyecto de mejora
Para medir el tamao de la funcionalidad del software entregado a usuarios funcionales humanos
2.1.2 La importancia del propsito
El propsito ayuda a los medidores a determinar:
El alcance que debe medirse y los aparatos que sern necesarios para la medicin
Los usuarios funcionales (como se indica en la seccin 2.3, el tamao de los cambios funcionales
es funcin de lo que se defina como el usuario funcional)
El momento en el ciclo de vida del proyecto en el que la medicin se llevar a cabo
La precisin necesaria de la medicin, y por lo tanto, si debera utilizarse la medicin con el
mtodo COSMIC, o si debera se debera utilizar una aproximacin derivada localmente de
COSMIC (por ejemplo, de manera temprana en el ciclo de vida de un proyecto, antes de que los
FUR estn totalmente elaborados). Ambos de estos dos ltimos puntos determinan el nivel de
granularidad al cual sern medidos los FUR.
2.2 Definir el alcance de la medicin
Definicin Alcance de una medicin
El conjunto de los requisitos funcionales de usuario que deben incluirse en un
determinado ejercicio de medicin de tamao funcional.
Nota: Se debe hacer una distincin entre el alcance general, es decir, todo el software
que debe medirse en funcin del objetivo, y el alcance de cualquier aplicacin software
en el alcance global, cuyo tamao debe medirse por separado. En este Manual de
Medicin, el trmino alcance (o la expresin alcance de la medicin) se refieren a una
aplicacin nica de software, cuyo tamao debe medirse por separado.
Los Requisitos Funcionales de los Usuarios son definidos por ISO como sigue:
Definicin 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 trminos de funciones y servicios.
Nota: Los requisitos funcionales de los usuarios incluyen, pero no estn limitados a:
Transferencia de datos (por ejemplo de entrada de datos de clientes; enviar seal
de control)
Transformacin 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)
Recuperacin de datos (por ejemplo listas de los empleados actuales; recuperar la
ltima posicin de una aeronave)
Ejemplos de requisitos de los usuarios que no son requisitos funcionales de los usuarios

0
incluyen, pero no estn limitados a:
Restricciones de calidad (por ejemplo, facilidad de uso, fiabilidad, eficiencia y
portabilidad)
Restricciones de organizacin (por ejemplo, localizacin de operacin, hardware
objetivo y cumplimiento de normas)
Restricciones medioambientales (por ejemplo, interoperabilidad, seguridad,
privacidad y seguridad)
Aplicacin de limitaciones (por ejemplo, lenguaje de desarrollo, calendario de
entrega)

Reglas Alcance
a) El alcance de una medicin de tamao funcional (FSM) se obtendr del propsito de
la medicin.
b) El alcance de una medicin no se extender a ms de una capa de software que
debe medirse
2.2.1 El alcance de una medicin depende de la finalidad
Es importante definir el alcance de una medicin antes de comenzar un ejercicio de medicin.
Siguiendo con la analoga de la construccin de casas, puede ser necesario, si el propsito es la
estimacin de costes, medir el tamao de diferentes partes de la casa por separado, por ejemplo, los
cimientos, las paredes y el techo, debido a que utilizan diferentes mtodos de construccin. Lo mismo
es vlido para la estimacin 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 tamao del
software en cada capa, es decir, cada parte tendr un alcance diferente para los propsitos de
medicin de tamao. Esto se desprende del principio (d) del Modelo de Contexto de Software. (Para
ms informacin sobre capas, consulte la seccin 2.2.4 a continuacin.)
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 tecnologas, entonces ser necesario
definir un alcance de la medicin separado para cada uno de los componentes antes de la medicin
de su tamao.
/5e%plo 13 Si cada co%ponente de so&t'are usa una tecnolog4a di&erente y las %edidas son usadas para la esti%acin del
es&uer6o de desarrollo, entonces de7er4a ser de&inida para cada co%ponente una %edida separada por8ue cada %edicin
del ta%a9o ir: asociada con una ci&ra de producti#idad di&erente (para %:s in&or%acin de co%ponentes se%e5antes, #ase
la seccin ..+ %:s a7a5o).
El propsito tambin ayudar a decidir qu software debe ser incluido y excluido del alcance de la
medicin.
/5e%plo 3 Si el propsito es %edir el ta%a9o &uncional de una pie6a de so&t'are desarrollada por un e8uipo de proyecto en
particular, pri%ero ser: necesario de&inir los re8uisitos &uncionales del usuario de los di#ersos co%ponentes 8ue ser:n
desarrollados por el e8uipo. /stos podr4an incluir los ;<= de una aplicacin so&t'are 8ue es utili6ada slo una #e6 para
con#ertir datos de un so&t'are 8ue se est: ree%pla6ando.
/5e%plo 33 Si el propsito es %edir el ta%a9o de un nue#o so&t'are 8ue est: disponi7le para su uso operati#o, este podr4a
ser %:s pe8ue9o 8ue para el e5e%plo , ya 8ue los ;<= del so&t'are utili6ado para la con#ersin no ser4an incluidos en el
:%7ito de la %edicin de ta%a9o.

1
En resumen, el propsito de la medicin debe ser siempre utilizado para determinar (a) qu software
es incluido o excluido del alcance global y (b) la forma en que el software incluido puede que sea
necesario dividirlo en partes separadas, cada una con su propio alcance, que deben medirse por
separado.
2.2.2 Tipos genricos de alcance
/5e%plos
2a cartera de proyectos de una e%presa
<n acuerdo contractual de especi&icacin de re8uisitos
/l producto entregado por el e8uipo de tra7a5o de un proyecto (es decir, incluyendo los par:%etros o7tenidos por la
e>plotacin de los progra%as in&or%:ticos e>istentes, pa8uetes co%prados y cdigo re?utili6a7le, cual8uier progra%a
utili6ado para la con#ersin de datos y posterior%ente desechado, y utilidades y so&t'are de prue7as desarrollados
espec4&ica%ente para este proyecto)
/l producto desarrollado por el e8uipo de tra7a5o de un proyecto (es decir, incluyendo cual8uier so&t'are desarrollado
por el e8uipo y utili6ado para la con#ersin de datos, pero posterior%ente descartado, y cual8uier utilidad y so&t'are de
prue7as de so&t'are desarrollado espec4&ica%ente para este proyecto, pero con e>clusin de toda la &uncionalidad
o7tenida por el ca%7io par:%etros y la e>plotacin de el cdigo re?utili6a7le o co%prada en pa8uetes co%erciales)
$odo el so&t'are de una capa
<n pa8uete so&t'are
<na aplicacin
<n co%ponente par o se%e5ante principal de una aplicacin
<na o75eto de clase re?utili6a7le
$odos los ca%7ios necesarios para una nue#a #ersin de una aplicacin so&t'are e>istente
En la prctica, una declaracin de alcance tiene que ser explcita en lugar de genrica, por ejemplo, el
producto de un proyecto desarrollado por el equipo de trabajo A, o la aplicacin B, o la cartera de
la empresa C. La declaracin de alcance tambin puede tener, para una mayor claridad, necesidad
de establecer lo que ha sido excluido.
2.2.3 Niveles de descomposicin
Tenga en cuenta que algunos de los tipos genricos de alcance de los mencionados, corresponden
a diferentes niveles de la descomposicin del software, definidos de la siguiente manera:
Definicin Nivel de descomposicin
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 tamao de componentes de una parte del software slo
pueden ser comparadas con componentes semejantes, por ejemplo, componentes del
mismo nivel de descomposicin.
/5e%plo3 @e los di&erentes ni#eles de desco%posicin, correspondientes a di&erentes Atipos genricos de alcanceB podr4a ser
una Acartera de aplicacionesB 8ue consiste en A%Cltiples aplicacionesB, cada una de las cuales puede consistir en
Aco%ponentes especiales se%e5antesB, cada una de los cuales puede consistir a su #e6 en Aclases de o75etos re?utili6a7lesB.
Determinar el alcance de una medida puede ser, por consiguiente, algo ms que una simple cuestin
de decidir qu funcionalidad debera incluirse en la medicin. La decisin tambin puede conllevar un
examen del nivel de descomposicin de software donde se medir. Se trata de una decisin
importante de la Estrategia de Medicin, depende de la finalidad de la medicin, porque las
mediciones a diferentes niveles de descomposicin no pueden ser comparadas fcilmente. Esto

surge porque, como se ver en la seccin 4.3.1, el tamao de cualquier aplicacin software no se
puede obtener simplemente sumando los tamaos de sus componentes.
2.2.4 Capas
Dado que el alcance de una aplicacin software que debe medirse debe limitarse a una sola capa de
software, el proceso de definir el alcance podr requerir que el medidor primero tenga que decidir
cules son las capas de la arquitectura del software. Por lo tanto en esta seccin vamos a definir y
discutir capas y peer componentes de software tal y como estos trminos son utilizados en el
mtodo COSMIC.
Las razones por las que necesitamos estas definiciones y reglas son las siguientes:
El medidor puede encontrase con la medicin de algn tipo de software en un entorno de
software legado que ha evolucionado a lo largo de muchos aos sin haber sido diseado de
acuerdo a una arquitectura subyacente (la llamada arquitectura espagueti) El medidor puede, por
tanto, necesitar orientacin de cmo distinguir las capas de acuerdo con la terminologa COSMIC.
Las expresiones capa, arquitectura en capas y componente semejante no se utilizan
consistentemente en la industria del software. Si el medidor debe medir algn tipo de software
que ha sido descrito mediante una arquitectura de capas, es aconsejable comprobar que las
capas en esta arquitectura estn definidas de una manera que sea compatible con el mtodo
COSMIC. Para ello, el medidor debera establecer la equivalencia entre determinados objetos
arquitectnicos 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.
Definicin Capa
Una capa es una particin resultante de la divisin funcional de una arquitectura de
software que junto con el hardware en su conjunto forma un sistema informtico en el
que:
las capas estn organizadas en una jerarqua
slo hay una capa en cada nivel en la jerarqua
exista una dependencia jerrquica 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 slo parte de los datos de forma idntica
La identificacin de capas es un proceso iterativo. Las capas exactas sern refinadas a medida que el
proceso de representacin 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 travs de
sus respectivos procesos funcionales.
d) La dependencia jerrquica entre capas es tal que el software en cualquier capa
puede utilizar los servicios funcionales de cualquier software en cualquier capa
debajo en la jerarqua. 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 jerarqua. Por el contrario, el
software en una capa subordinada, junto con el software en cualquier capa

3
subordinada de la que depende, puede funcionar sin necesidad de los servicios de
software en cualquier capa superior en la jerarqua.
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 ms
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 recepcin 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 medicin.
b) En el dominio SIM o software empresarial, la capa ms alta, es decir la capa que no
est subordinada a ninguna otra capa, normalmente se denomina la capa de
aplicacin. Una aplicacin 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
comnmente se denomina como un sistema, como por ejemplo en el software de
un sistema de control de procesos, o tambin por ejemplo en un software de
sistema de control de vuelo.
c) No se puede asumir que ningn software que se ha desarrollado sin ningn tipo de
consideracin de diseo arquitectnico o estructuracin puede dividirse en capas
de acuerdo al modelo COSMIC.
Los paquetes de software de servicios funcionales tales como los sistemas de gestin de bases de
datos, sistemas operativos o controladores de dispositivo, debe considerarse en principio que se
situarn en capas separadas.
Una vez identificadas, cada capa puede ser registrada como un componente separado en la matriz
del Modelo Genrico de Software (anexo A), con la correspondiente etiqueta.
/5e%plo 13 2a estructura &4sica de una t4pica ar8uitectura de so&t'are en capas (utili6ando el tr%ino AcapaB co%o ha sido
de&inido a8u4) 8ue soporte aplicaciones so&t'are de gestin se da en la &igura ..*.13

*
Middleware Layer (Utilities, etc)
Operating System Layer
Keyboard
Driver
Screen
Driver
VDU
Screen
Keyboard
Hardware
Software
Layers
Disk
Driver
Hard Disk
Drive
Print
Driver
Printer
Central
Processor
Database Management
System Layer
DBMS 1 DBMS 2
App 1 Application Layer App 2 App n
Subordinate
Layer
Superior
Layer
relies on
Key:
Middleware Layer (Utilities, etc)
Keyboard
Driver
Screen
Driver
VDU
Screen
Keyboard
Hardware
Software
Layers
Disk
Driver
Hard Disk
Drive
Disk
Driver
Hard Disk
Drive
Print
Driver
Printer
Print
Driver
Printer
Central
Processor
Central
Processor
Database Management
System Layer
DBMS 1 DBMS 2
App 1 Application Layer App 2 App n
Subordinate
Layer
Superior
Layer
relies on
Key:
Subordinate
Layer
Superior
Layer
relies on
Subordinate
Layer
Superior
Layer
relies on
Key:

Figura 2.2.4.1 Tpica arquitectura de software en capas de un sistema de negocios
/5e%plo 3 2a estructura &4sica de una t4pica ar8uitectura de so&t'are en capas (de nue#o utili6ando el tr%ino AcapaB co%o
ha sido de&inido a8u4) soportando una parte i%7uida de una aplicacin en tie%po real se %uestra en la &igura ..*.3

Sensor
Driver
Display
Mem. Chip
Driver
CV
Driver
Control
Valve(s)
Memory
Chip
Central
Processor
Sensor(s)
Hardware
(Examples)
Display
Driver
Embedded Application Layer
Subordinate
Layer
Superior
Layer
relies on
Key:
Software
Layers Operating System Layer
Sensor
Driver
Display
Mem. Chip
Driver
CV
Driver
Control
Valve(s)
Memory
Chip
Central
Processor
Sensor(s)
Hardware
(Examples)
Display
Driver
Display
Driver
Embedded Application Layer
Subordinate
Layer
Superior
Layer
relies on
Key:
Subordinate
Layer
Superior
Layer
relies on
Subordinate
Layer
Superior
Layer
relies on
Key:
Software
Layers

Figure 2.2.4.2 Tpica 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:
Definicin 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
descomposicin.


+
Los componentes semejantes pueden ser identificados de acuerdo a la siguiente definicin y
principios.
Definicin Componente semejante
Un componente usa un juego de componentes cooperativos, todos en el mismo nivel
de descomposicin, que resulta de dividir una parte de software dentro de una capa,
donde cada componente llena una porcin de los requerimientos funcionales de
usuario de esa parte de software.
Nota: La divisin 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 jerrquica entre los componentes semejantes como hay entre las
capas. Los FUR homlogos de todos los componentes de una pieza de software en
cualquier capa se encuentran en al mismo nivel en la jerarqua 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 comn define esos datos idnticamente, 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 genrico de software (anexo A), con la
correspondiente etiqueta.
/5e%plo3 Cuando una aplicacin de gestin se desarrolla en tres grandes co%ponentes, deno%inados Ainter&a6 de usuarioB
(o A&ront?endB), Areglas de negocioB y Adatos de ser#icioB, los tres co%ponentes son co%ponentes se%e5antes.
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 situacin que ilustra el ejemplo. Todo el software mostrado reside
en la misma capa de la aplicacin. Los intercambios entre dos componentes semejantes de la
Aplicacin X y entre dos partes semejantes de software (Componente 2 de la Aplicacin X y
Aplicacin Y) pueden darse a travs de cualquiera de las secuencias alternativas que se definen en el
principio c) para dos componentes semejantes.
App X App Y
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
Level 1 of decomposition of
App X
App X App Y
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
Level 1 of decomposition of
App X

Figure 2.2.5.1 Relacin entre los conceptos de semejantes, componente y componentes semejantes


,
2.3 Identificar los usuarios funcionales
2.3.1 El tamao funcional vara con el usuario funcional
A partir de una analoga, la medicin de la superficie de una oficina puede llevarse a cabo de acuerdo
con cuatro diferentes convenios, como se indica a continuacin (ntese 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 pblicos, 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 pblicas 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 especfica del edificio est
interesado en los metros cuadrados netos, que excluye los espacios pblicos, pero que incluye
los pasillos utilizados por el arrendatario.
El responsable de la planificacin de oficinas solo est interesado en los metros cuadrados netos
tiles.
La leccin de esta analoga es que el tamao de un objeto puede variar dependiendo de la
funcionalidad que es de inters para diferentes tipos de usuarios del objeto. En el caso del software,
diferentes usuarios funcionales podrn exigir y utilizar diferentes funcionalidades y, por tanto, los
tamaos funcionales varan con la eleccin de los usuarios funcionales.
2.3.2 Usuarios Funcionales
Un usuario se define, en la norma ISO/IEC 14143/1:2007, como cualquier cosa que interacta con
el software que se est midiendo. Esta definicin es demasiado amplia para las necesidades del
mtodo COSMIC. Para el mtodo COSMIC, la eleccin de un usuario (o usuarios) se determina por
los requisitos del usuario funcional que deben medirse. Este (tipo de) usuario, es conocido como el
usuario funcional y se define como sigue.
Definicin Usuario Funcional
Es un usuario aquel remitente y/o destinatario de datos de los Requisitos Funcionales
de Usuario de una aplicacin software.
En el mtodo COSMIC es esencial distinguir a los usuarios funcionales de una parte del software que
debe ser medido de entre todos sus posibles usuarios.
/5e%plo 13 Considere una aplicacin e%presarialD Sus usuarios &uncionales nor%al%ente incluir4an hu%anos y otras
aplicaciones se%e5antes con las 8ue la aplicacin interactCa. 1ara una aplicacin en tie%po real, los usuarios &uncionales
nor%al%ente ser4an dispositi#os hard'are u otros so&t'are se%e5antes 8ue interactCen con ella. 2as necesidades de los
usuarios &uncionales (;<=) de dicho so&t'are nor%al%ente se e>presan de %odo 8ue los usuarios &uncionales son los 8ue
en#4an datos yEo los destinatarios de los datos hacia y desde el so&t'are, respecti#a%ente.
Sin e%7argo, el con5unto total de AusuariosB, es decir, incluida cual8uier cosa 8ue interactCa con el so&t'are, de7e incluir el
siste%a operati#o. 1ero los ;<= de cual8uier aplicacin nunca incluir4an el siste%a operati#o co%o un usuario. Cual8uier
li%itacin 8ue el siste%a operati#o pueda i%poner a una aplicacin ser: co%Cn para todas las aplicaciones, por lo general,
se encargar:n de ella el co%pilador o intrprete, y son in#isi7les para los usuarios &uncionales reales de la aplicacin. /n la
pr:ctica de %edicin de ta%a9o &uncional, un siste%a operati#o nunca ser4a considerado co%o un usuario &uncional de una
aplicacin.
Pero no siempre se da el caso de que lo usuarios funcionales sean obvios.

-
/5e%plo 3 $o%e%os el e5e%plo de la aplicacin so&t'are de un tel&ono %#il (se %encion por pri%era #e6 en la
Introduccin). " pesar de 8ue he%os eli%inado el siste%a operati#o del tel&ono %#il co%o un posi7le usuario &uncional de
la aplicacin, los usuarios podr4an ser (a) los seres hu%anos 8ue pulsan las teclas, o (7) los dispositi#os de hard'are (por
e5e%plo, la pantalla, teclado, etc.) y aplicaciones se%e5antes 8ue interactCan directa%ente con la aplicacin del tel&ono. /l
usuario hu%ano, por e5e%plo, #er: slo un su7con5unto de toda la &uncionalidad de la 8ue de7e ser pro#ista a &in de 8ue la
aplicacin del tel&ono %#il &uncione. 1or lo tanto, estos dos tipos de usuarios #er:n di&erente &uncionalidad, el ta%a9o de
los ;<= para los usuarios hu%anos ser: %enor 8ue el ta%a9o de los ;<= 8ue de7en desarrollarse para hacer la aplicacin
de tel&ono &uncione.
Reglas Usuarios Funcionales
a) Los usuarios funcionales de una aplicacin software que se hayan de medir se
derivan del propsito de la medicin
b) Cuando el propsito de una medicin de una aplicacin 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.
Definicin 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 aplicacin software es la lnea 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
ambigedad, lo que se incluye dentro del software a ser medido de lo que es parte del
medio en el que opera el software.
Ntese, que esta definicin de frontera est tomada de la norma ISO/IEC 14143/1:2007, modificada
por la adicin de la palabra funcional para calificar al usuario. Para evitar la ambigedad, tenga en
cuenta que la frontera no debe confundirse con ninguna lnea que pueda dibujarse alrededor de
ningn programa que deba ser medido para definir el alcance de la medicin. La frontera no se utiliza
para definir el alcance de la medicin.
Las siguientes reglas podran ser tiles para confirmar la condicin de una posible frontera:
Reglas Frontera
a) Identificar los usuarios funcionales que interactan con el software que se mide. La
frontera se encuentra entre los usuarios funcionales y este software.
b) Por definicin, 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 distincin clara entre todo lo que forma parte de la aplicacin
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 estndar
Cuando se comienza un proyecto para disear y construir una nueva casa, los primeros planos de un
arquitecto se encuentran en la casa en una situacin de alto nivel, es decir, que muestran un
esquema y pocos detalles. A medida que el proyecto avanza hacia la fase de construccin, se
necesitan los planos ms 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 travs de las versiones 1, 2, 3, etc.), revelando ms detalle a un menor nivel. Estos
diferentes grados de detalle de los FUR, son conocidos con los diferentes niveles de granularidad.
(Vase tambin la seccin 2.4.3 para otros trminos que pueden confundirse con el concepto de nivel
de granularidad como es definido aqu).
Definicin Nivel de granularidad
Cualquier nivel de expansin de la descripcin de una sola aplicacin software (por
ejemplo, una declaracin de requisitos, o una descripcin de la estructura de la
aplicacin software) de tal manera que a cada aumento del nivel de expansin, la
descripcin de la funcionalidad de la aplicacin 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 habrn documentado en los
diferentes niveles de granularidad.
Los planos de construccin de viviendas usan escalas estndar, y es fcil traducir dimensiones de en
un dibujo a otro dibujo realizado con una escala distinta. En cambio no hay escalas estndar para los
diversos niveles de granularidad con que el software puede ser especificado, por lo que puede ser
difcil 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 algn nivel de granularidad de a que
escala se debe medirse es imposible saber con certeza que dos mediciones de tamao funcional
pueden compararse. Y los medidores tienen que desarrollar su propio mtodo para pasar las
mediciones de un nivel de granularidad a otro.
Para ilustrar an ms los problemas, consideremos otra analoga. Un conjunto de mapas de
carreteras revela los detalles de una red nacional de carreteras en tres niveles de granularidad.
Mapa A muestra slo 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 fenmeno de los diferentes niveles de granularidad, parece que se exponen
tres mapas diferentes de la red de carreteras de la nacin. Por supuesto, con mapas de carreteras
todo el mundo reconoce los diferentes niveles de detalle y hay escalas estndar para interpretar el
tamao de la red descrita en cualquier nivel. El concepto abstracto de nivel de granularidad se
esconde detrs de las escalas de estos mapas distintos.
Para la medicin del software, slo hay un nivel de granularidad que es posible definir sin
ambigedades. 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 Aclaracin del nivel de granularidad
Antes de continuar, es importante asegurar que no haya malentendidos sobre el significado de nivel
de granularidad en el mtodo COSMIC. Tal como se define aqu, la ampliacin de la descripcin de
software de un nivel de granularidad superior a uno inferior implica revelar ms detalles pero sin
modificar su alcance. Este proceso no debe confundirse con cualquiera de los siguientes.
Detallar un artefacto que describa algn 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 algn 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 descomposicin - vase la seccin 2.2.2). Detallar a
niveles ms bajos la descomposicin del software puede dar lugar (a partir de los efectos de la
medicin) en sub-dividir el alcance global de la medicin
Mostrar la descripcin de algn tipo de software a medida que avanza su ciclo de desarrollo, por
ejemplo, de los requisitos al el diseo lgico, diseo fsico, etc. Cualquiera que sea la fase del
desarrollo de algn software, slo estamos interesadas en los FUR para propsitos de medicin.
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
tambin pueden ser muy importantes cuando se utilizan para comparar las mediciones de tamao
funcional. Estos sern tratados en el documento Temas Avanzados y Relacionados, v3.0, en el
captulo Garantizando la Comparacin de Mediciones de Tamao.
2.4.3 El nivel de granularidad estndar
El nivel de granularidad estndar para la medicin es el nivel de proceso funcional y se define como
sigue:
Definicin Nivel de Granularidad de un Proceso funcional
Un nivel de granularidad de la descripcin de aplicacin software en el que los usuarios
funcionales:
a) Son humanos individuales o dispositivos de ingeniera o elementos de software (y
no grupos de estos) Y
b) detectan ocurrencias nicas de eventos a los que la aplicacin software debe
responder (y no cualquier nivel en el cual se han definido grupos de eventos)
Nota 1: En la prctica, la documentacin de software que contiene las necesidades de
los usuarios funcionales a menudo describe la funcionalidad en diferentes niveles de
granularidad, sobre todo cuando la documentacin an est en construccin.
Nota 2: Grupos de usuarios funcionales podran 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 declaracin 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 avinica, etiquetado como comandos del piloto.
Con esta definicin, podemos ahora definir las siguientes reglas y una recomendacin.
Reglas Nivel de granularidad de un proceso funcional
a) La medicin de tamao funcional se deber efectuar al nivel de granularidad del
proceso funcional

30
b) Cuando se necesita la medida del tamao funcional de algunos FUR que no han
evolucionado an a un nivel al cual se hayan identificado sus procesos funcionales
y no se hayan definido an los detalles de todos sus movimientos de datos, las
mediciones deberan ser hechas a partir de la funcionalidad que ha sido definida, y
despus escalada a un nivel de granularidad de procesos funcionales. (Ver el
documento Aspectos Avanzados y Relacionados para los mtodos de medicin
aproximada, es decir, estimando el tamao funcional de forma temprana en el
proceso de establecer los FUR).
Adems de las reglas, COSMIC recomienda que el nivel de granularidad de un proceso funcional
deba ser el estndar al que se requiera medir el tamao funcional cuando sea utilizado por los
proveedores para una evaluacin comparativa de los servicios y de las herramientas de software
diseados para sostener o utilizar las mediciones de tamao funcional, por ejemplo para estimar el
esfuerzo de un proyecto.
/5e%plo3 ;uncionalidad en di&erentes ni#eles de granularidad
/l e5e%plo, del do%inio de so&t'are de gestin, ser: de un conocido siste%a de co%prar productos a tra#s de Internet, 8ue
lla%are%os el siste%a A/#erestB. (/l docu%ento de A$e%as "#an6ados y =elacionadosB contiene un e5e%plo del do%inio de
so&t'are de tie%po real.). 2a descripcin 8ue &igura a continuacin est: %uy si%pli&icada para los propsitos de esta
ilustracin de los ni#eles de granularidad. 2a descripcin ta%7in cu7re Cnica%ente a las &uncionalidades disponi7les para
los usuarios del F/#erestF. 1or lo tanto, e>cluye las &uncionalidades 8ue de7en estar presentes para 8ue el siste%a pueda
co%pletar la entrega de 7ienes a un cliente, tales co%o la &uncionalidad disponi7le para el personal de F/#erestF,
pro#eedores de productos, anunciantes, el pago los pro#eedores de ser#icios, etc.
/l alcance de la %edicin, por lo tanto, se de&ine co%o las partes del siste%a de aplicacin F/#erestF accesi7les a los
clientes a tra#s de Internet. "su%i%os 8ue el o75eti#o de la %edicin es deter%inar el ta%a9o &uncional de la aplicacin a
disposicin los usuarios hu%anos (co%o usuarios &uncionales). "l %:s alto Ani#el 1B la de&inicin de todos los re8uisitos
&uncionales de los usuarios (=<;) del siste%a de co%pra F/#erestF ser4a una si%ple declaracin co%o la siguiente.
A/l siste%a /#erest de7er: per%itir a los clientes in&or%arse so7re, seleccionar, pedir, pagar y o7tener la entrega de
cual8uier ele%ento de la ga%a de productos /#erest, incluidos los productos disponi7les desde terceros pro#eedores.B
@etallando esta declaracin de %:s alto ni#el %:s nos encontra%os con 8ue en el pr>i%o ni#el in&erior , el siste%a
consiste en cuatro su7?siste%as, tal y co%o se %uestra en ;ig. .*.3.1.

31
Everest
Ordering
System
Order
Follow-up
Sub-system
Account
Maintenance
System
Checkout/
Payment
Sub-system
Enquiry/
Order
Sub-system
Review, maintain
confirm order
Sub-sub-system
Select delivery/
packaging options
Sub-sub-system
Pay for order
Sub-sub-system
Display & e-mail
order confirmation
Sub-sub-system
Register new
customer
process
Pay for order
process
Maintain
payment method
Sub-sub-system
Maintain
customer details
Sub-sub-system
Delete existing
means-of-payment
process
Add new
means-of-payment
process
Level 1
Level 2
Level 3
Level 4
Enquire on
current
order process
Enquire on
historic
orders process
Returned goods
Sub-sub-system
(not analyzed)
(not analyzed)
(n/a) (n/a) (n/a)
Everest
Ordering
System
Order
Follow-up
Sub-system
Account
Maintenance
System
Checkout/
Payment
Sub-system
Enquiry/
Order
Sub-system
Everest
Ordering
System
Order
Follow-up
Sub-system
Account
Maintenance
System
Checkout/
Payment
Sub-system
Enquiry/
Order
Sub-system
Review, maintain
confirm order
Sub-sub-system
Select delivery/
packaging options
Sub-sub-system
Pay for order
Sub-sub-system
Display & e-mail
order confirmation
Sub-sub-system
Register new
customer
process
Pay for order
process
Register new
customer
process
Pay for order
process
Maintain
payment method
Sub-sub-system
Maintain
customer details
Sub-sub-system
Delete existing
means-of-payment
process
Add new
means-of-payment
process
Delete existing
means-of-payment
process
Add new
means-of-payment
process
Level 1
Level 2
Level 3
Level 4
Enquire on
current
order process
Enquire on
historic
orders process
Returned goods
Sub-sub-system
(not analyzed)
(not analyzed)
(n/a) (n/a) (n/a) (n/a) (n/a) (n/a)

Figura 2.4.3.1 Anlisis parcial del Sistema Everest con cuatro niveles de anlisis
2os cuatro su7?siste%as son los siguientes3
/l su7?siste%a de la SolicitudEOrden 8ue per%ite a un cliente encontrar cual8uier producto en la 7ase de datos de
/#erest, as4 co%o su precio y disponi7ilidad y a9adir cual8uier producto seleccionado a una cesta de co%pra. /ste
su7?siste%a ta%7in pro%ue#e las #entas sugiriendo las o&ertas especiales, 8ue o&rece co%entarios de los ele%entos
seleccionados y per%ite preguntas generales co%o las condiciones de entrega, etc. Se trata de un su7?siste%a %uy
co%ple5o y no es anali6ado en %:s detalle por de7a5o del ni#el a e&ectos del presente e5e%plo.
/l su7?siste%a de la co%praEpago 8ue per%ite a un cliente co%pro%eterse con el pedido y pagar por la %ercanc4a de
la cesta.
/l su7?siste%a del Segui%iento del pedido 8ue per%ite a un cliente a preguntar hasta 8u punto un pedido e>istente ha
a#an6ado en el proceso de entrega, para %antener su pedido (por e5e%plo, ca%7iar la direccin de entrega) y para
de#ol#er 7ienes no satis&actorios.
/l su7?siste%a del Manteni%iento de la cuenta 8ue per%ite a un cliente e>istente, %antener di#ersos detalles de su
cuenta tales co%o do%icilio, %edios de pago, etc.
2a &igura .*.3.1 ta%7in %uestra algCn detalle 8ue se pone de %ani&iesto cuando detalla%os los otros dos ni#eles del su7?
siste%a de 2a Co%praE1ago, del Segui%iento del 1edido y el su7siste%a de Manteni%iento de la Cuenta. /n este proceso,
es i%portante se9alar 8ue3
no he%os ca%7iado el alcance del siste%a de la aplicacin 8ue ha7r: de %edirse, y
todos los ni#eles de la descripcin del siste%a de so&t'are F/#erestF %uestran la &uncionalidad disponi7le para los
clientes (co%o los usuarios &uncionales). <n cliente puede #er la &uncionalidad del siste%a en todos estos los ni#eles
de an:lisis
2a &igura .*.3.1 re#ela ta%7in 8ue cuando detalla%os ni#eles %:s 7a5os de este an:lisis de los tres su7?siste%as, nos
encontra%os con los distintos procesos &uncionales en el ni#el 3 (para dos consultas del su7?siste%a de Segui%iento del
1edido) y en el ni#el * para los otros dos su7?siste%as. /ste e5e%plo de%uestra, por tanto, 8ue cuando alguna
&uncionalidad es anali6ada en un en&o8ue de arri7a a7a5o, no se puede suponer 8ue la &uncionalidad %ostrada en un ni#el
en un diagra%a se corresponde sie%pre con el %is%o ni#el de granularidad tal y co%o este concepto es de&inido en el
%todo COSMIC. (/sta de&inicin e>ige 8ue a cual8uier ni#el de granularidad la &uncionalidad est a un Ani#el co%para7le
de detalleB).

3
1or otra parte, otros analistas podr4an di7u5ar el diagra%a de &or%a di&erente, %ostrando otras agrupaciones de
&uncionalidades en cada ni#el del diagra%a, ya 8ue no hay una Cnica &or%a correcta de anali6ar la &uncionalidad de un
siste%a.
$eniendo en cuenta estas #ariaciones 8ue ine#ita7le%ente ocurren en la pr:ctica, un %edidor de7e e>a%inar
cuidadosa%ente los di#ersos ni#eles de un diagra%a de an:lisis para encontrar los procesos &uncionales 8ue de7en
%edirse. /n caso de 8ue en la pr:ctica esto no sea posi7le, por e5e%plo de7ido a 8ue el an:lisis aCn no ha alcan6ado el
ni#el donde todos los procesos &uncionales se han re#elado, de7e aplicarse la regla (7) descrita %:s arri7a. 1ara ilustrar
esto, #a%os a e>a%inar el caso del su7?su7siste%a Mantener @etalles del Cliente (#ase la &igura .*.3.1), en la pri%era
ra%a de el su7?siste%a de Manteni%iento de la Cuenta.
1ara un %edidor con e>periencia, la pala7ra %antener casi sie%pre sugiere un grupo de casos y por lo tanto, un grupo de
procesos &uncionales. 1or lo tanto, pode%os asu%ir con seguridad 8ue este su7?su7siste%a de %antener de7e estar
integrado por tres procesos &uncionales, es decir, 7ase de datos de detalles del cliente, actuali6acin de los detalles del
cliente y eli%inar el cliente. (/#idente%ente el proceso de creacin del cliente ta%7in e>iste pero esto ocurre en otra ra%a
del siste%a, 8ue es cuando un cliente hace un pedido por pri%era #e6. /st: &uera del :%7ito de aplicacin de este e5e%plo).
<n %edidor con e>periencia de7e poder esti%ar un ta%a9o de este su7?su7siste%a en unidades 1;C to%ando el supuesto
nC%ero de procesos &uncionales (tres en este caso) y %ultiplicando este nC%ero por el ta%a9o %edio de un proceso
&uncional. /ste ta%a9o %edio se o7tendr4a cali7rando en otras partes de este siste%a o en otros siste%as co%para7les.
/5e%plos de este proceso de cali7racin se dan en el docu%ento de A$e%as "#an6ados y =elacionadosB 8ue en la
apro>i%acin de %ediciones contiene ta%7in otras apro>i%aciones al ta%a9o apro>i%ado.
/#idente%ente, estos %todos de apro>i%acin tienen sus li%itaciones. Si aplica%os este en&o8ue al ni#el 1 de la
declaracin ;<= de la &or%a arri7a se9alada (/l siste%a F/#erestF de7er: per%itir a los clientes in&or%arse so7re,
seleccionar, co%prar, pagar y o7tener la entrega de cual8uier ele%ento de la ga%a de productos /#erestG.), podr4a%os
identi&icar unos procesos &uncionales. 1ero un an:lisis %:s detallado podr4a re#elar 8ue el #erdadero nC%ero de procesos
&uncionales de este co%ple5o siste%a de7e ser %ucho %ayor. /sa es la ra6n por la 8ue ta%a9os &uncionales aparentan
au%entar a %edida 8ue se esta7lecen %:s detalles en los re8uisitos, incluso sin ca%7ios en el alcance de la aplicacin.
/stos %todos de apro>i%acin, por lo tanto, de7en ser utili6ados con su%o cuidado a los altos ni#eles de granularidad,
cuando est: disponi7le %uy poca in&or%acin.
El documento de Temas Avanzados y Relacionados da un tipo diferente de ejemplo de medicin 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 ms 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, tambin se ocupa de diversos
niveles de descomposicin del software que se est midiendo y de sus usuarios funcionales.
2.5 Observaciones finales sobre la Fase de Estrategia de la de Medicin
Si se consideran cuidadosamente los cuatro elementos del proceso de estrategia de medicin antes
de empezar una medicin se debera asegurar que el tamao resultante pueda ser interpretado
correctamente. Los cuatro elementos son los siguientes:
a) establecer el propsito de la medicin
b) definir el alcance global de la aplicacin software a medir y el alcance de las partes a ser medidas
por separado, teniendo en cuenta las capas y los componentes semejantes de la arquitectura de
software
c) establecer los usuarios funcionales de la aplicacin software medida
d) establecer el nivel de granularidad de los artefactos de software a medir y cmo, si es necesario,
llevar las medidas a al estndar de nivel de granularidad de proceso funcional
Pueden ser necesarias algunas repeticiones de los pasos (b), (c) y (d) cuando estn evolucionando
los requisitos y los nuevos datos indican la necesidad de perfeccionar la definicin del alcance.
La gran mayora de las mediciones de tamao funcional se llevan a cabo con una finalidad que est
relacionada de algn modo con el esfuerzo de desarrollo, por ejemplo, para la medicin del

33
rendimiento de los desarrolladores, o para la estimacin del proyecto. En estas situaciones, la
definicin de la estrategia de medicin debe ser muy sencilla. El propsito y el alcance son
generalmente fciles 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 comn, por lo que la estrategia de
medicin debe ser definida para en cada situacin.

3*
3
3

FASE DE REPRESENTACIN
Este captulo presenta las reglas y el mtodo para el proceso de representacin. El mtodo general
para la representacin del software en el Modelo COSMIC Genrico del Software se resume en la
figura 3.0.

FUR in the form
of the COSMIC
Generic Software
Model
Section 3.2
IDENTIFY
DATA
GROUPS
Section 3.3 (*)
IDENTIFY
DATA
ATTRIBUTES
COSMIC MAPPING PHASE
Section 3.1
IDENTIFY
FUNCTIONAL
PROCESSES
(*): This step is not a mandatory part of the
COSMIC method.
Chapter 2
PURPOSE, SCOPE,
FUNCTIONAL USERS &
of the piece of software
to be measured
Functional User
Requirements
in the artefacts
of the software
to be measured
FUR in the form
of the COSMIC
Generic Software
Model
FUR in the form
of the COSMIC
Generic Software
Model
Section 3.2
IDENTIFY
DATA
GROUPS
Section 3.2
IDENTIFY
DATA
GROUPS
Section 3.3 (*)
IDENTIFY
DATA
ATTRIBUTES
Section 3.3 (*)
IDENTIFY
DATA
ATTRIBUTES
COSMIC MAPPING PHASE
Section 3.1
IDENTIFY
FUNCTIONAL
PROCESSES
Section 3.1
IDENTIFY
FUNCTIONAL
PROCESSES
(*): This step is not a mandatory part of the
COSMIC method.
Chapter 2
PURPOSE, SCOPE,
FUNCTIONAL USERS &
to be measured
Chapter 2 Chapter 2
PURPOSE, SCOPE,
FUNCTIONAL USERS &
to be measured
PURPOSE, SCOPE,
FUNCTIONAL USERS &
to be measured
Functional User
Requirements
in the artefacts
of the software
to be measured
Functional User
Requirements
in the artefacts
of the software
to be measured

Figure 3.0 Mtodo General del proceso de mapeo COSMIC
Cada paso de este mtodo es el tema de una seccin especfica (indicada en el ttulo de cada paso
de la figura 3) donde se presentan las definiciones y las reglas, junto con algunos principios que
sirven de gua y ejemplos.
El mtodo general resumido en la figura 3 de arriba se ha diseado para ser aplicado a una muy
amplia gama de artefactos de software. Un proceso ms sistemtico y detallado proporcionara reglas
precisas de representacin para una mayor cantidad de artefactos altamente especficos, por lo que
se disminuira el nivel de ambigedad al generar el Modelo Genrico COSMIC de Software. Un
proceso as sera, por definicin, altamente dependiente de la naturaleza de los artefactos, lo que
depende de la metodologa de ingeniera del software que se use en cada organizacin.
El documento Gua para Medir Aplicaciones de Gestin utilizando COSMIC sirve de gua en la
representacin desde varios datos de anlisis y mtodos de obtencin de requisitos usados en el
dominio de las aplicaciones de gestin a los conceptos del mtodo COSMIC.

3+

3.1 Aplicacin del Modelo Genrico COSMIC de software
Principio Aplicando el Modelo Genrico COSMIC de Software
El Modelo Genrico COSMIC de Software se aplicar de forma separada a cada parte
de los requisitos funcionales de usuario para la cual se ha definido un alcance de la
medicin.
Aplicar el Modelo Genrico COSMIC de Software significa identificar el conjunto de
eventos desencadenadores detectados por cada (tipo de) usuario funcional identificado
en los FUR para, a continuacin, identificar los correspondientes procesos funcionales,
objetos de inters, grupos de datos y los movimientos de datos que deben ser
proporcionados para responder a esos eventos.
Las figuras 3.1.1 y 3.1.2 de abajo ilustran respectivamente, la aplicacin del principio (g) del Modelo
de Contexto del Software y los principios del Modelo Genrico del Software a una aplicacin de
gestin y a un tpico software empotrado de tiempo real.
Mientras que las figuras 2.2.3.1 y 2.2.3.2 de arriba mostraban visiones fsicas reales de las
arquitecturas a capas del software, las figuras 3.3.1 y 3.1.2 muestran una visin lgica de las
relaciones de varios conceptos definidos en los modelos COSMIC. En esta visin lgica los usuarios
funcionales interaccionan con el software que va a ser medido a travs de una frontera va
movimientos de datos de Entrada y de Salida. El software mueve datos hacia y desde los almacenes
persistentes va movimientos de datos de Escritura y Lectura respectivamente. En estas visiones
lgicas 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.
Application
being
measured
A peer
application
functional user
The
application
layer
Boundary
Human
functional
user (s)
E
Entries
Exits
Reads Writes
Boundary
Persistent
storage
X
X E
Indicates a message that is issued as an Exit data movement,
crosses a boundary, and is received as an Entry data movement
X E
Application
being
measured
A peer
application
functional user
The
application
layer
Boundary Boundary
Human
functional
user (s)
E
Entries
Exits
Reads Writes
Boundary
Persistent
storage
X
X E X E
Indicates a message that is issued as an Exit data movement,
X E Indicates a message that is issued as an Exit data movement,
X E

Figure 3.1.1 Una aplicacin de gestin con seres humanos y otras aplicaciones semejantes, como sus
usuarios funcionales (vista lgica)


3,
The
Application
Layer
Application
being
measured
Boundary
Hardware
engineered
device
Functional
User (s)
Entries
Exits
Reads Writes
Persistent
Storage
The
Application
Layer
Application
being
measured
Boundary Boundary
Hardware
engineered
device
Functional
User (s)
Entries
Exits
Reads Writes
Persistent
Storage

Figura 3.1.2 Una aplicacin en tiempo real con varios dispositivos hardware integrados como usuarios
funcionales (vista lgica)
3.2 Identificacin de los procesos funcionales
Este paso consiste en identificar el conjunto de procesos funcionales de la aplicacin software que se
va a medir a partir de sus Requisitos Funcionales de Usuario.
3.2.1 Definiciones
Definicin 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: Adems de informar al componente de software de que el evento ha ocurrido, la
entrada desencadenante puede incluir datos sobre el objeto de inters asociado al
evento.

Definicin Evento desencadenante
Un evento (algo que ocurre) que causa un usuario funcional del componente de
software para iniciar (trigger) uno o ms 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.


3-
La relacin 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
interpretacin de este diagrama es: un evento es detectado por un usuario funcional, y el usuario
funcional desencadena el proceso funcional.
Triggering
event
is sensed
by
Triggering
Entry
Boundary
Functional
user
Functional
process
Triggering
event
is sensed
by
Triggering
Entry
Boundary
Functional
user
Functional
process

Figura 3.2.1 Relacin entre un evento disparador, un usuario funcional y un proceso funcional
La Entrada desencadenante es normalmente un mensaje positivo e inequvoco que informa al
software de que el usuario funcional ha identificado un evento desencadenante. La Entrada
desencadenante usualmente incluye tambin datos sobre un objeto de inters asociado con el
evento. Despus 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 inters.
Si un usuario funcional enva 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 vlidos y cmo
responder.
3.2.2 La aproximacin para identificar procesos funcionales
La aproximacin para identificar procesos funcionales depende de los artefactos de software que
estn disponibles para el medidor, los cuales dependen del momento del ciclo de vida del software
cuando se requiere la medida y de los mtodos de anlisis, diseo y desarrollo del software en uso.
Puesto que stos ltimos varan enormemente, incluso dentro del un dominio de software dado, est
fuera del alcance de este Manual de Medida el proporcionar uno o ms procesos generales para
identificar procesos funcionales.
La Gua para medicin de aplicaciones de gestin software usando COSMIC, seccin 4.4 da ms
reglas y ejemplos sobre cmo identificar y distinguir procesos funcionales en el dominio de las
aplicaciones software de gestin.
El consejo general ms importante es que es casi siempre til intentar identificar los diferentes
eventos en el mundo de los usuarios funcionales a los que el software debe responder, ya que cada
evento da lugar normalmente a un (pero a veces a ms de uno) proceso funcional. Los eventos
pueden ser identificados a partir de diagramas de estado y a partir de los diagramas de ciclo de vida
la de entidad, puesto que cada transicin a la que el software se debe enfrentar se corresponde con
un evento.
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

3.
identificable
c) Un evento especfico puede desencadenar uno o ms procesos funcionales que se
ejecutan en paralelo. Un proceso funcional puede ser desencadenado por ms de
un evento
d) Un proceso funcional constar de al menos dos movimientos de datos, una Entrada
ms 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 prxima 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 mximo nmero 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 travs del
proceso funcional.
h) Se deberan distinguir Eventos diferentes y por tanto Procesos Funcionales
diferentes en los siguientes casos:
Cuando las decisiones resultan en eventos separados que estn desconectados
en el tiempo (por ejemplo meter datos de una orden hoy y despus confirmar
que se acepta la orden, requiriendo una decisin separada, debera ser
considerado como indicativo de procesos funcionales separados)
Cuando las responsabilidades de actividades estn separadas (por ejemplo en
un sistema personal donde la responsabilidad para mantener datos personales
bsicos est separada de la responsabilidad del mantenimiento de datos de
nminas, 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 parmetros 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 aplicacin de negocio on-line normalmente ocurren en el
mundo real de los usuarios funcionales humanos de la aplicacin. El usuario humano comunica la
incidencia de un evento a un proceso funcional metiendo datos sobre el evento
/5e%plo 13 /n una co%pa94a, se reci7e una orden (e#ento desencadenante), causando 8ue un e%pleado (usuario
&uncional) %eta los datos de la orden (/ntrada desencadenante 8ue co%unica datos so7re el o75eto de inters AordenB),
co%o el pri%er %o#i%iento de datos del proceso &uncional Aentrada de ordenB
b) Algunas veces, para una aplicacin A podra haber una aplicacin par B que necesite enviar datos
a u obtener datos de la aplicacin A. En este caso, si la aplicacin B desencadena un proceso
funcional cuando necesita enviar datos u obtener datos de la aplicacin A, entonces la aplicacin
B es un usuario funcional de la aplicacin A
/5e%plo 3 Supngase 8ue al reci7ir una orden en el e5e%plo a) a la aplicacin de la orden se la re8uiere 8ue en#4e
detalles del cliente a una aplicacin central de registro de clientes, lo cual se est: %idiendo. "hora la aplicacin de la
orden se ha con#ertido en un usuario &uncional de la aplicacin central. 2a aplicacin de la orden detecta el e#ento de
recepcin de los datos del cliente y desencadena un proceso &uncional en la aplicacin central del registro de clientes
para al%acenar estos datos, en#iando datos so7re el o75eto de inters AclienteB co%o una /ntrada desencadenante a la
aplicacin central.
c) No hay diferencia en el principio para el anlisis de un proceso funcional si se requiere un
procesamiento on-line o un tratamiento por lotes. El procesamiento durante la noche es una
decisin de puesta en marcha tcnica, y todo lo que se requiere hacer no ha ocurrido hasta que

3!
el proceso durante la noche se haya completado. Un flujo de procesado por lotes consiste en uno
o ms procesos funcionales, cada uno de los cuales debera ser analizado end-to-end,
independientemente de cualquier otro proceso funcional en el mismo flujo. Cada proceso
funcional tiene su propia Entrada desencadenante que debe medirse.
/5e%plo 33 Supngase 8ue las rdenes del e5e%plo de a) se %eten on?line pero son al%acenadas para un procesado
por lotes auto%:tico durante la noche. /l usuario &uncional es toda#4a el hu%ano 8ue %eti las rdenes on?lineD la
/ntrada desencadenante son toda#4a los datos de la orden. Hay un proceso &uncional por entrada y procesado de las
rdenes.
d) Las seales peridicas de un reloj (ticks) pueden fsicamente desencadenar un proceso funcional.
/5e%plo *3 Supngase un ;<= para un proceso por lotes a &inal de a9o para in&or%ar de los resultados del negocio
durante el a9o y para rea5ustar puestos para co%ien6os del a9o 8ue #iene. ;4sica%ente, el ticI de &in de a9o de un relo5
originado por el siste%a operati#o ocasiona 8ue el &lu5o por lote co%ience, consistiendo en uno o %:s procesos
&uncionales. /stos procesos &uncionales del &lu5o 8ue usan datos de entrada en el &lu5o de7er4an ser anali6ados de
%odo nor%al (por e5e%plo los datos de entrada para cual8uier proceso &uncional constan de una o %:s /ntradas, la
pri%era de las cuales es la /ntrada desencadenante de dicho proceso).
Sin e%7argo, se asC%ase 8ue hay un proceso &uncional particular en el &lu5o 8ue no re8uiere ningCn dato de entrada
para producir sus series de in&or%es. ;4sica%ente, el usuario &uncional (hu%ano) ha delegado en el siste%a operati#o
la tarea de desencadenar este proceso &uncional. 1uesto 8ue todos los procesos &uncionales de7en tener una /ntrada
desencadenante, podr4a%os considerar 8ue el ticI de &in de a9o del relo5 8ue co%en6 el &lu5o por lotes dese%pe9a
este papel para este proceso. /l proceso &uncional podr4a entonces necesitar di&erentes 2ecturas y %uchas Salidas
para producir sus in&or%es. 2gica%ente, el an:lisis de este e5e%plo no es di&erente si el usuario &uncional inicia la
produccin de uno o %:s in&or%es #4a un clic del ratn en un icono del %enC on?line, en #e6 de delegar la produccin
del in&or%e al siste%a operati#o #4a &lu5o por lotes.
e) Un solo evento puede desencadenar uno o ms procesos funcionales que se ejecuten
independientemente.
/5e%plo +3 <n ticI de relo5 de &in de se%ana produce 8ue co%ience la generacin de in&or%es y el proceso de re#isin
de la caducidad de los l4%ites de tie%po en un siste%a auto%:tico.
f) Un solo proceso funcional puede ser desencadenado por ms de un tipo de evento
desencadenante.
/5e%plo ,3 /n un siste%a 7ancario, un e>tracto de cuenta puede ser desencadenado por un proceso por lotes de &in de
%es pero ta%7in por8ue un cliente espec4&ico lo haya pedido.
Para diversos ejemplos de cmo distinguir eventos desencadenantes y procesos funcionales en flujos
por lotes, ver la Gua de Medicin de Aplicaciones de Gestin utilizando COSMIC en la seccin
4.6.3.
3.2.4 Ejemplos en el dominio de aplicaciones en tiempo real.
a) Un evento desencadenante es detectado tpicamente por un sensor
/5e%plo 13 Cuando la te%peratura alcan6a un #alor deter%inado (e#ento desencadenante), se produce 8ue un sensor
(usuario &uncional) en#4e una se9al (%o#i%iento de datos de /ntrada desencadenante) para encender una lu6 de
alar%a (proceso &uncional).
/5e%plo 3 <n a#in %ilitar tiene un sensor 8ue detecta el e#ento Aun %isil se acercaB. /l sensor es un usuario &uncional
del so&t'are integrado 8ue de7e responder a la a%ena6a. 1ara este so&t'are, solo cuando el sensor detecta algo
ocurre un e#ento, y es el sensor (el usuario &uncional) el 8ue pone en &unciona%iento al so&t'are en#i:ndole un
%ensa5e (/ntrada desencadenante) diciendo por e5e%plo3 Ael sensor ha detectado un %isilB, ade%:s 8ui6:s ta%7in
en#4a un &lu5o de datos so7re la #elocidad del %isil 8ue se acerca y sus coordenadas. /l %isil es el o75eto de inters.

*0
b) Seales peridicas de una reloj (ticks de reloj) pueden desencadenar un proceso funcional
/5e%plo 33 /n algCn so&t'are de control de procesos en tie%po real, un ticI (e#ento desencadenante) de un relo5
(usuario &uncional) produce 8ue el relo5 en#4e una se9al (/ntrada desencadenante), un %ensa5e de un 7it 8ue le dice al
proceso &uncional 8ue repita su ciclo de control nor%al. /l proceso &uncional entonces lee #arios sensores, reci7iendo
datos so7e o75etos de inters, y lle#a a ca7o cual8uier accin necesaria. Jo hay otros datos 8ue aco%pa9en el ticI del
relo5.
c) Un solo evento puede desencadenar uno o ms procesos funcionales que se ejecuten
independientemente en paralelo
/5e%plo * <n situacin de e%ergencia detectada en una central nuclear puede desencadenar procesos &uncionales
independientes en 6onas di&erentes de la central para 7a5ar las 7arreras de control, accionar el en&ria%iento de
e%ergencia, cerrar #:l#ulas, hacer sonar las alar%as para alertar a los operarios, etc.
d) Un solo proceso funcional puede ser desencadenado por ms de un evento desencadenante.
/5e%plo +3 2a retraccin en las ruedas de un a#in puede ser desencadenada por el detector Asin peso en el sueloB o
por una orden del piloto.
3.2.5 Ms 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 difcil decidir qu eventos separados se
requiere que el software reconozca. Este es especialmente el caso cuando los FUR originales no
estn ya disponibles y cuando, por ejemplo, los que fabrican el software haya visto que es econmico
combinar varios requisitos. Podra ayudar con el anlisis examinar la organizacin de los datos de
entrada (ver abajo) o examinar los mens de algn software instalado para ayudar a distinguir los
eventos separados a los que el software debe responder y los correspondientes procesos
funcionales.
/5e%plo 13 Cuando hay un re8uisito de un usuario &uncional para reduccin de i%puestos por un hi5o adicional y ta%7in por
Acrditos por tasas de tra7a5oB para los 8ue tienen un sueldo 7a5o, estos son re8uisitos a los 8ue el so&t'are de7e responder
co%o dos e#entos separados en el %undo de los usuarios &uncionales hu%anos. 1or tanto, de7er4a ha7er dos procesos
&uncionales, aun8ue solo se haya utili6ado un &or%ulario de i%puestos para recoger los datos en a%7os casos.
/5e%plo 3 Si el salario en un e5e%plo (para una persona) e>cede el l4%ite por crditos por tasas de tra7a5o en reduccin de
i%puestos y en otro e5e%plo (para otra persona) no lo e>cede, esta di&erencia no da lugar a dos procesos &uncionales
separados, pero indica dos condiciones separadas de las 8ue encargarse en el Cnico proceso &uncional.
/5e%plo 33 Co%o e5e%plo de la regla (g), si ocurre una incidencia espec4&ica 8ue desencadena la /ntrada de un grupo de
datos 8ue consta de atri7utos de datos ", K y C, y los ;<= per%iten 8ue otra incidencia del %is%o e#ento desencadene
una /ntrada de un grupo de datos 8ue tiene #alores para los atri7utos " y K Cnica%ente, esto no resulta en identi&icar dos
procesos &uncionales. Solo son identi&icados una /ntrada y un proceso &uncional, %o#iendo y %anipulando atri7utos de
datos ", K y C.
Una vez identificados, cada proceso funcional puede ser registrado en una lnea individual, bajo la
capa o estrato adecuado o bajo el componente semejante, en la matriz del Modelo Genrico de
Software (apndice A), bajo la correspondiente etiqueta.
3.2.6 El proceso funcional de componentes semejantes
Cuando el propsito de la medicin es medir separadamente el tamao de cada componente
semejante, debe ser definido un alcance de medicin diferente para cada componente. En un caso
como ese, la definicin del tamao del proceso funcional de cada componente sigue las normas ya
descritas.

*1
Del proceso de cada medicin ( definir el alcance, luego los usuarios funcionales y la frontera,
etc.), se deduce que si una parte del software consta de dos o ms componentes similares, no
puede haber ninguna superposicin del alcance de medicin de cada componente. El alcance de
medicin 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 medicin 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 dnde suceden los
eventos que disparan los procesos funcionales del componente que est siendo examinado (la
activacin de eventos slo 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 Identificacin objetos de inters 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 gestin, es
habitualmente til identificar los objetos de inters y probablemente tambin sus atributos. Los grupos
de datos se mueven a movimientos de datos, los cuales sern identificados en el captulo siguiente.
Definicin Objeto de inters
Cualquier cosa que sea identificada desde el punto de vista de los requisitos del
usuario funcional. Puede ser cualquier cosa fsica, como tambin cualquier objeto
conceptual o parte de un objeto conceptual en el mundo del usuario funcional sobre el
que al software se le requiere que procese y/o almacene datos.
Nota: En el mtodo COSMIC, el trmino objeto de inters se usa para evitar trminos
relacionados con mtodos especficos de ingeniera del software. El trmino no implica
objetos en el sentido usado en los mtodos Orientados a Objetos.

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

Definicin Almacn persistente
Un almacn persistente es un almacn que permite a un proceso funcional almacenar
un grupo de datos ms all de la vida del proceso funcional y/o del cual un proceso
funcional puede recuperar un grupo de datos almacenado por otro proceso funcional, o
almacenado por una ocurrencia anterior del mismo proceso funcional, o almacenado por
otro proceso.
Nota 1: En el modelo COSMIC, debido a que el almacn 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 sera 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 travs de su coleccin
nica de atributos de datos
b) Cada grupo de datos estar directamente relacionado con un objeto de inters 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 Genrico de Software (apndice A), bajo la correspondiente etiqueta.
3.3.2 Sobre la materializacin de un grupo de datos
En la prctica, la materializacin de un grupo de datos puede tomar muchas formas, por ejemplo:
a) Como una estructura fsica grabada en un dispositivo de almacenamiento continuo (archivo, tabla
de base de datos, memoria ROM, etc.)
b) Como una estructura fsica en la memoria voltil del ordenador (estructura de datos asignada
dinmicamente o a travs un bloque pre-asignado de espacio de memoria)
c) Como la presentacin agrupada de atributos de datos relacionados funcionalmente en un
dispositivo input/output (pantalla de visualizacin, informe impreso, panel de control de
visualizacin, etc.)
d) Como un mensaje transmitido entre un dispositivo y un ordenador, o sobre una red, etc.
3.3.3 Sobre la identificacin de objetos de inters y grupos de datos
Las definiciones y los principios de los objetos de inters y de los grupos de datos son
intencionalmente amplios con el objetivo de que se puedan aplicar al rango ms amplio posible de
software. Esta cualidad hace que algunas veces resulte difcil de aplicar la definicin y los principios
cuando se mide una parte especfica del software. Por tanto, los casos siguientes y los ejemplos se
han diseado para ayudar en la aplicacin de los principios a casos especficos.
Al enfrentarnos a la necesidad de analizar un grupo de atributos de datos que son movidos dentro o
fuera de un proceso funcional o que son movidos por un proceso funcional a o desde un almacn
persistente, es de una importancia crtica decidir si todos los atributos comunican datos sobre un
nico objeto de inters, ya que es ste ltimo el que determina el nmero de grupos de datos
separados tal y como los define el mtodo 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 inters separados,
entonces necesitamos identificar tres movimientos de datos de Entrada separados.
Objetos de inters y grupos de datos en el dominio de las aplicaciones de gestin
/5e%plo 13 /n el do%inio de so&t'are de aplicaciones de gestin, un o75eto de inters podr4a ser Ae%pleadoB (&4sico) o
ApedidoB (conceptual), asu%iendo 8ue se re8uiere 8ue el so&t'are al%acene datos so7re e%pleados o pedidos. /n el caso
de pedidos, nor%al%ente desde el ;<= de pedidos %ultil4nea se identi&ican dos o75etos de inters3 ApedidoB y Al4nea de
pedidoB. 2os grupos de datos correspondientes podr4an lla%arse Adatos de pedidosB o Al4nea de datos de pedidosB.
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 almacn persistente, pero que se puede derivar de datos que estn en el
almacn persistente. El movimiento de datos de Entrada en una consulta ad hoc (los parmetros de
seleccin 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 ejecucin del proceso funcional. Son grupos de datos vlidos
porque cruzan el lmite o frontera entre el software y su usuario o usuarios.

*3
/5e%plo 3 @ada un consulta ad hoc contra una 7ase de datos personal para e>traer una lista de no%7res de todos los
e%pleados de %:s de 3+ a9os. 2a /ntrada %ue#e un grupo de datos 8ue contiene los par:%etros de la seleccin. 2a Salida
%ue#e un grupo de datos 8ue contiene solo el atri7uto Ano%7reBD el o75eto de inters (o AcosaB) es Atodos los e%pleados de
%:s de 3+ a9osB. /s i%portante al gra7ar el proceso &uncional no%7rar clara%ente un grupo de datos transitorios en
relacin con su o75eto de inters, %e5or 8ue relacionarlo con el o75eto de inters del cual se deri#a el resultado de la
consulta ad hoc.
Para una discusin detallada sobre mtodos de anlisis de datos para determinar objetos de inters y
grupos de datos separados, el lector puede ir a Gua para Medir Aplicaciones de Gestin utilizando
COSMIC.
Objetos de inters y grupos de datos en el dominio de las aplicaciones en tiempo real.
/5e%plo 33 Mo#i%ientos de datos 8ue son /ntradas desde dispositi#os &4sicos t4pica%ente contienen datos so7re el estado
de un solo o75eto de inters, tales co%o si un #:l#ula est: a7ierta o cerrada, o indican un tie%po en el 8ue datos a corto
pla6o, al%acena%iento #ol:til es #:lido o in#:lido, o contienen datos 8ue indican 8ue ha ocurrido un e#ento cr4tico y 8u
causa una interrupcin. @e un %odo si%ilar un co%ando de Salida para encender o apagar una l:%para de a#iso co%unica
datos so7re un solo o75eto de inters.
/5e%plo *3 <n interca%7io de %ensa5es puede reci7ir un grupo de datos de %ensa5es tales co%o una /ntrada y guiarlo
adelante sin ca%7ios co%o una Salida, co%o re8uisito de una parte del so&t'are en particular. 2os atri7utos del grupo de
datos de %ensa5es podr4an ser, por e5e%plo, Ael 8ue lo en#4a, recipiente, ruta?cdigo y %ensa5e?contenidoD el o75eto de
inters del %ensa5e es A%ensa5eB.
/5e%plo +3 <na estructura de datos ha7itual, representando o75etos de inters 8ue se %encionan en los re8uisitos
&uncionales de usuario, 8ue puede ser %antenida por procesos &uncionales, y 8ue es accesi7le para la %ayor4a de procesos
&uncionales encontrados en el so&t'are %edido.
/5e%plo ,3 <na estructura de datos de re&erencia, representando gr:&icos o ta7las de #alores encontrados en los re8uisitos
&uncionales de usuario, los cuales est:n en %e%oria per%anente (%e%oria =OM por e5e%plo) y accesi7le para la %ayor4a
de procesos &uncionales encontrados en el so&t'are %edido.
/5e%plo -3 "rchi#os, co%Cn%ente designados co%o Aarchi#os planosB, representando o75etos de inters %encionados en
los re8uisitos &uncionales de usuario, los cuales se %antienen en un dispositi#o de al%acena%iento 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 estn
relacionados con un objeto de inters para un usuario funcional no deberan ser identificados
indicando un movimiento de datos, por tanto no deberan medirse. Los ejemplos incluyen:
/5e%plo 13 @atos generales de la aplicacin tales co%o enca7e6a%ientos y pies de p:gina (no%7re de la co%pa94a,
no%7re de la aplicacin, &echa del siste%a, etc.) 8ue aparecen en todas las pantallas.
/5e%plo 3 Co%andos de control (un concepto de&inido solo en el :%7ito de aplicaciones de gestin) 8ue per%ite a un
usuario &uncional controlar su uso del so&t'are %:s 8ue %o#er datos, por e5e%plo los co%andos de p:gina arri7aEa7a5o,
pulsar AOLB para ad%itir un %ensa5e de error, etc. ? #er la seccin *.1.10 %:s adelante.
El modelo Genrico COSMIC de Software asume que toda manipulacin de datos dentro de un
proceso funcional est asociada con unos de los cuatro tipos de movimientos de datos- ver seccin
4.1.6. Por tanto ningn movimiento o manipulacin 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 manipulacin y movimientos de datos que puedan ser mal
interpretados como movimientos de datos ver seccin 4.1.4, principio c) para Lecturas, y seccin
4.1.5 principio d) para Escrituras.

**
3.3.5 El usuario funcional como objeto de inters
En muchos casos simples de software en tiempo real como el descrito en el primer punto del caso 2
de la seccin 3.3.3 de arriba, el dispositivo fsico -un usuario funcionales indistinguible del objeto de
inters del movimiento de datos que genera o recibe. En dichos casos aade poco valor al
documento un objeto de inters 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.
/5e%plo3 Supngase un sensor de te%peratura A"B 8ue, cuando es preguntado por un proceso &uncional, en#4a la
te%peratura actual al proceso. /l usuario &uncional es el sensor "3 el no%7re del %ensa5e de /ntrada podr4a ser
Ate%peratura actual en "BD el o75eto de inters de este %ensa5e podr4a ta%7in ser considerado co%o Asensor "B.
$erica%ente, el o75eto de inters no es Asensor "B, sino Ael %aterial u o75eto cuya te%peratura est: siendo detectada por el
sensor "B. /n la pr:ctica sin e%7argo a9aden poco #alor al docu%ento estas &inas distinciones y puede 8ue no %ere6ca la
pena identi&icar el o75eto de inters separada%ente.
3.4 Identificacin de los atributos de datos (opcional)
Esta seccin discute la identificacin de atributos de datos referenciados por la parte del software que
se va a medir. En esta versin del mtodo de medida no es obligatorio identificar los atributos de los
datos. Sin embargo, puede ser de ayuda analizar e identificar los atributos de datos en el proceso de
distinguir los grupos de datos y los objetos de inters. Los atributos de datos pueden tambin ser
identificados si una sub-unidad de la medida del tamao es requerida, como se presenta en la
seccin 4.5 Extendiendo el mtodo de medida COSMIC.
3.4.1 Definicin
Definicin Atributo de datos
Un atributo de datos es la pieza ms pequea de informacin, dentro de un grupo de
datos identificados, que tiene un significado desde la perspectiva de los requisitos
funcionales del software.
/5e%plo 13 "tri7utos de datos en el conte>to del do%inio de aplicaciones de gestin co%o por e5e%plo ele%entos de datos
registrados en el diccionario de datos y atri7utos de datos 8ue aparecen en un %odelo de datos conceptual o lgico.
/5e%plo 3 "tri7utos de datos en el conte>to de las aplicaciones a tie%po real del so&t'are co%o por e5e%plo atri7utos de
datos de una se9al reci7ida de un sensor y atri7utos de datos de un %ensa5e en trans%isin.
3.4.2 Sobre la asociacin de atributos de datos y grupos de datos
En teora, un grupo de datos puede contener solo un atributo de datos si esto es suficiente, desde la
perspectiva de los requisitos funcionales de usuario, para describir el objeto de inters. En la prctica,
dichos casos ocurren normalmente en las aplicaciones a tiempo real del software (por ejemplo: la
Entrada que transmite el tick de un reloj a tiempo real); stos son menos comunes en el software de
gestin.

*+
4
4

FASE DE MEDICIN
Este captulo presenta las reglas y el mtodo para la fase de medicin del proceso de medicin
COSMIC. El mtodo general para medir una aplicacin software cuando sus Requisitos Funcionales
de Usuario se han expresado en trminos del Modelo Genrico COSMIC de Software se resume en
el grfico 4.0 debajo.
Functional Size
of the measured
software
Section 4.1
IDENTIFY
DATA MOVEMENTS
Section 4.2
APPLY
MEASUREMENT
FUNCTION
COSMIC MEASUREMENT PHASE
Section 4.3
AGREGATE
MEASUREMENT
RESULTS
recorded information
All
functional processes
measured ?
YES
NO
FUR in the form
of the COSMIC
Generic Software
Model
Functional Size
of the measured
software
Section 4.1
IDENTIFY
DATA MOVEMENTS
Section 4.1 Section 4.1
IDENTIFY
DATA MOVEMENTS
APPLY
MEASUREMENT
FUNCTION
COSMIC MEASUREMENT PHASE COSMIC MEASUREMENT PHASE
Section 4.3
AGREGATE
MEASUREMENT
RESULTS
AGREGATE
MEASUREMENT
RESULTS
recorded information
All
measured ?
All
measured ?
YES
NO
FUR in the form
of the COSMIC
Generic Software
Model

Figura 4.0 Proceso general de la Fase de Medicin COSMIC
Cada paso de este mtodo es el objeto de una seccin especfica de este captulo, 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 Definicin de los tipos de movimientos de datos
Definicin 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 medicin, cada tipo de movimiento de datos se considera que incluye
ciertas manipulaciones de datos asociadas - Ver seccin 4.1.6 para ms detalles.
Nota 3: Ms 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 tambin a las definiciones de Entrada, salida, lectura y
escritura.

Definicin Entrada, (Entry, E)
Una entrada (E) es un movimiento de datos que mueve un grupo de datos desde un
usuario funcional a travs de la frontera hacia el proceso funcional donde se necesitan
Nota: Se considera que una entrada incluye ciertas manipulaciones de datos asociadas
(ver seccin 4.1.6)

Definicin Salida, (Exit, X)
Una salida (X) es un movimiento de datos que mueve un grupo de datos desde un
proceso funcional a travs de la frontera haca el usuario funcional que los requiere.
Nota: Se considera que una salida incluye ciertas manipulaciones de datos asociadas
(ver seccin 4.1.6)

Definicin Lectura (Read, R)
Un movimiento de un grupo de datos desde un almacn permanente dentro del alcance
del proceso funcional que los requiere.
Nota: Se considera que una lectura incluye ciertas manipulaciones de datos asociadas
(ver seccin 4.1.6)

Definicin Escritura (Write, W)
Un movimiento a un almacn 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
(ver seccin 4.1.6)


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

Figura 4.1.1 - Los cuatro tipos de movimiento de datos y su relacin con el proceso funcional y los
grupos de datos.
4.1.2. Identificacin 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
inters de un usuario funcional a travs de la frontera y dentro de un proceso
funcional del que la entrada forma parte. Si la entrada a un proceso funcional
comprende ms de un grupo de datos, se identifica una entrada por cada grupo de
datos que entra. (Vase tambin la seccin 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
ms tarde no necesite que se le diga que datos enviar o el usuario funcional es
incapaz de reaccionar a ningn mensaje entrante, identificar una Entrada al proceso
funcional para obtener los datos. Cualquier mensaje del proceso funcional al usuario
funcional buscando recuperar los datos no debe ser contado como una Salida en
estos casos.
Sin embargo, cuando un proceso funcional deba obtener algn dato de un usuario
funcional y el proceso funcional deba decirle al usuario funcional con datos que
despus requieran rellenar la peticin, contar una Salida para la peticin y una
Entrada para la devolucin de los datos pedidos (para ms informacin ver seccin
4.1.9).
Las siguientes reglas ayudan a confirmar la condicin de un candidato a movimiento de datos de
entrada:
Reglas Entradas (E)
a) El grupo de datos que disparen una entrada puede constar de slo un atributo de

*.
datos que simplemente informa al software que un evento Y ha ocurrido. Muy a
menudo, especialmente en el software de gestin, el grupo de datos que dispara
una entrada tiene muchos atributos que informan al software de que un evento Y ha
ocurrido y aqu estn los datos sobre ese evento en particular.
b) Las ticks de reloj que estn provocando eventos sern 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 slo
atributo. Se debe notar que no hay ninguna diferencia si el hecho desencadenante
es generado peridicamente por el hardware o por otra parte del software fuera de
los lmites 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 especfico desencadena la entrada de un grupo de
datos que comprende hasta n atributos de un objeto de inters 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 slo un subconjunto de n
atributos del objeto de inters, entonces ser identificada una entrada, compuesto
por todos n atributos.
<n e5e%plo 8ue ilustra la regla c)3 cuando un proceso &uncional escri7e un certi&icado de &echa de registro, no se identi&ica
ninguna /ntrada para o7tener el #alor del relo5 del siste%a.
Una vez identificados, cada movimiento de datos de Entrada puede ser registrado marcando la casilla
correspondiente a la tabla del Modelo Genrico de Software (apndice A) con una E.
4.1.3. Identificacin 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
inters 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
ms de un grupo de datos, hay que identificar una salida para cada grupo de datos
que sale. (Vase tambin la seccin 4.1.7 sobre los movimientos de datos nicos.)
b) Una salida no introducir datos a travs de la frontera, ni lecturas, ni escrituras.
Las siguientes normas podran ser tiles para confirmar la condicin 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) debern ser considerados valores de un
atributo de un objeto de inters (el cual debera ser nombrado indicacin 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 inters 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 slo un subconjunto de
n atributos del objeto de inters, entonces ser identificada una salida, compuesta
por todos los n atributos.
Ejemplos de la regla a) anterior son los siguientes:

*!
/5e%plo 13 /n un di:logo persona?ordenador, e5e%plos de %ensa5es de error ocurridos durante la #alidacin de datos
podr4an ser Aerror de &or%atoB, ACliente no encontradoB, Aerror3 %arcar la casilla 8ue indica 8ue los tr%inos y condiciones
han sido le4dosB, Al4%ite crdito e>cedidoB, etc. $odos esos %ensa5es de error de7en considerarse co%o ocurrencias de una
salida en cada proceso &uncional en el 8ue tales %ensa5es se producen (8ue podr4a ser no%7rado A%ensa5es de errorB)
/5e%plo 3 2os %ensa5es de error 8ue salen a los usuarios hu%anos pero 8ue no son generados por la aplicacin de
so&t'are de7er4an ser ignorados por co%pleto en la %edicin de la aplicacin. <n e5e%plo de ese %ensa5e al pasar por el
siste%a operati#o podr4a ser A2a i%presora M no respondeB.
/5e%plo 33 /n un di:logo persona?ordenador, si un %ensa5e es la salida de un error de situaciones pero contiene datos
&uncionales de usuario, entonces de7e contarse co%o una salida en el proceso &uncional donde ocurre. <n e5e%plo de ese
%ensa5e podr4a ser A1/2IN=O3 la cantidad 8ue desea retirar supera su l4%ite por 100OB (donde los 100O son una #aria7le
calculada). /n este e5e%plo, la salida contiene un grupo de datos so7re la cuenta 7ancaria del cliente
/5e%plo *3 /n un siste%a en tie%po real, un proceso &uncional 8ue re#isa peridica%ente el correcto &unciona%iento de
todos los dispositi#os de hard'are podr4a e%itir un %ensa5e 8ue in&or%e AS/JSO= M ha &alladoB, donde AMB es una #aria7le.
/ste %ensa5e de7e ser identi&icado co%o una salida en ese proceso &uncional (independiente%ente del #alor de AMB)
/5e%plo +3 Considerar procesos &uncionales " y K. A"B puede potencial%ente e%itir %ensa5es distintos de con&ir%acin y +
%ensa5es de error a sus usuarios &uncionales y AKB puede potencial%ente e%itir . %ensa5es de error a sus usuarios
&uncionales. /n este e5e%plo, ser: identi&icada una salida en el proceso &uncional A"B (%ane5ando + P Q - %ensa5es) y se
identi&icar: una salida separada en el proceso &uncional AKB (%ane5ando . %ensa5es).
Una vez identificados, cada movimiento de datos de Salida puede ser registrado marcando la casilla
correspondiente de la tabla del modelo genrico de Software (apndice A) con un X.
4.1.4. Identificacin 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
inters del almacn permanente a un proceso funcional del cual la lectura forma
parte. Si el proceso funcional debe recuperar ms de un grupo de datos del
almacn, identificar una Lectura para cada grupo de datos que es recuperado.
(Vase tambin la seccin 4.1.7 sobre los movimientos de datos nicos.)
b) Una lectura no recibir ni sacar datos a travs de la frontera ni escribir datos
c) Durante un proceso funcional, el movimiento o manipulacin de constantes o
variables que son internas del proceso funcional y que slo se pueden cambiar por
un programador, o mediante los resultados intermedios en un clculo, o de los datos
almacenados en un proceso funcional slo resultantes de la aplicacin, ms que de
los requisitos funcionales, no se considerar como una Lectura.
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). Vase tambin la seccin 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 Genrico del Software (apndice 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

+0
inters del proceso funcional del que la Escritura forma parte hacia un almacn
permanente. Si el proceso funcional debe pasar ms de un grupo de datos al
almacn permanente, identificar una Escritura por cada grupo de datos que se
mueve a un almacn permanente. (Vase tambin la seccin 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 almacn permanente se medir
como una sola Escritura
d) Durante un proceso funcional, el movimiento o manipulacin de los datos que no
persista cuando el proceso funcional sea completado, o la actualizacin de variables
que son internas del proceso funcional o la produccin de resultados intermedios en
un clculo no se considerarn como una Escritura.
Una vez identificadas, cada Escritura puede ser registrada marcando la casilla correspondiente de la
tabla del modelo de software genrico (apndice 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 Genrico de Software (ver
seccin 1.4), o bien movimientos de datos, o bien manipulaciones de datos. Sin embargo, por un
convenio actual de COSMIC (vase el principio (j) del Modelo Genrico de Software), no se reconoce
la existencia separada de manipulacin de datos y sub-procesos.
Definicin Manipulacin 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 almacn permanente.
El siguiente principio determina como el mtodo COSMIC trata la manipulacin de datos.
Principio Manipulacin de datos asociada con los movimientos de datos
Todas las manipulaciones de datos en un proceso funcional sern asociadas con los
cuatro tipos de movimiento datos (E, X, R, y W). Por convencin, los movimientos de
datos de un proceso funcional se supone que tambin representan la manipulacin de
los datos del proceso funcional
La necesidad de definir qu clase de manipulacin de los datos est asociada con qu tipos de
movimientos datos surge slo cuando hay que medir los cambios de software (ver seccin 4.4). Un
cambio tpico necesario afecta tanto a los atributos reubicados como a la manipulacin asociada con
un movimiento de datos, pero puede afectar slo a la manipulacin de los datos, y no al movimiento
de los datos. Ese cambio todava necesita ser identificado y medido.
A continuacin estn las directrices generales para identificar la manipulacin de los datos
representados por cada uno de los movimientos de datos.
Movimiento de Datos de Entrada (E)
Una entrada incluye toda manipulacin de datos
Para permitir a un grupo de datos debe ser introducida por un usuario funcional (por ejemplo
manipulaciones de formato y presentacin) y/o para ser validado
Pero no todas las manipulaciones que involucran otro movimiento de datos, ni manipulaciones
despus de que el grupo de datos se ha introducido y validado.
/5e%plo3 <na entrada incluye toda %anipulacin, &or%ato y presentacin en una pantalla de los datos introducidos sal#o
alguna 2ectura(s) 8ue podr4a ser necesaria para #alidar algunos cdigos introducidos o para o7tener algunas descripciones
asociadas.

+1
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 (vase el punto 4.1.9 para
qu datos enviar y 4.1.10 para el tratamiento de una pantalla vaca 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
presentacin) y sea encaminado a los usuarios funcionales.
pero no cualquier manipulacin que involucre otro movimiento de datos.
/5e%plo3 <na Salida incluye todo el trata%iento para &or%atear y preparar la i%presin de algunos atri7utos, incluidos los
enca7e6ados para au%entar la legi7ilidad por los hu%anos, sal#o cual8uier 2ectura o /ntrada 8ue podr4a ser necesaria para
proporcionar los #alores o descripciones de algunos atri7utos de i%presin.
Movimiento de datos de Lectura (R)
Una Lectura incluye todo tratamiento y/o clculo necesario a fin de recuperar un grupo de datos del
almacn permanente pero no a manipulaciones con otro tipo de movimiento de datos ni
manipulaciones despus de que la lectura se complete con xito.
/5e%plo3 <na lectura incluye todas las operaciones %ate%:ticas y trans&or%aciones lgicas necesarias para recuperar un
grupo de datos de un al%acn per%anente pero no la %anipulacin de los atri7utos despus de 8ue el grupo de datos se
haya o7tenido.
Una Lectura tambin incluye siempre cualquier funcionalidad de solicitud de lectura (vase el punto
4.1.9).
Movimiento de datos de Escritura (W)
Una Escritura incluye todos los tratamientos y/o clculos para crear un grupo de datos que ser
escrito pero no cualquier manipulacin que incluya otro tipo de movimiento de datos, ni tampoco
manipulaciones de que la Escritura termine con xito despus de que la Escritura termine con xito.
/5e%plo3 <na /scritura incluye todas las operaciones %ate%:ticas y trans&or%aciones lgicas necesarias para crear o
actuali6ar un grupo de datos de /scritura, o para ser 7orrados e>cepto las lecturas o entradas 8ue podr4an ser necesarias
para dar #alor a los atri7utos incluidos en el grupo 8ue #a a ser escrito o supri%ido.
4.1.7 Movimientos de datos nicos y posibles excepciones
El Modelo Genrico de Software supone que normalmente en cualquier proceso funcional todos los
datos describen un objeto de inters 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 produccin de un movimiento de
datos de tipo Salida. El modelo supone tambin que toda manipulacin 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.
/5e%plo 8ue ilustra este Clti%o supuestoD considere%os dos ocurrencias de un deter%inado proceso &uncional dado.
Suponga%os 8ue en la pri%era ocurrencia los #alores de algunos atri7utos se trasladan a una %anipulacin de datos del
su7?proceso A"B y 8ue en otra ocurrencia del %is%o proceso &uncional el #alor del atri7uto es conducido a otra %anipulacin
de datos del su7?proceso AKB. /n tales circunstancias, tanto la %anipulacin de datos del su7?proceso A"B co%o AKB de7en
asociarse con el %is%o %o#i%iento de datos y de ah4 nor%al%ente slo un %o#i%iento datos de7e identi&icarse y ser
contado en ese proceso &uncional.

+
Sin embargo, en excepcionales circunstancias en las que datos de diferente grupo de tipos describen
el mismo objeto de inters 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 situacin normal, excepciones validadas posibles y
ejemplos que podran parecer como vlidos, 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 inters que est obligado a ser entrada en un
proceso funcional, y todas las manipulaciones de datos asociadas sern
identificadas y se contarn como una Entrada.
Nota: Un proceso funcional puede, por supuesto, estar obligado a manejar mltiples
Entradas, cada movimiento de un grupo de datos describe un objeto de inters
diferente
La misma norma se aplica a cualquier movimiento de datos de tipo Lectura,
Escritura o Salida en cualquier proceso funcional.
b) Cuando hay ms de un movimiento de datos de Entrada, cada movimiento de un
grupo de datos que describa el mismo objeto de inters en un proceso funcional
puede ser identificado y contado si existe un Requisito Funcional de Usuario para
estas mltiples entradas. Asimismo, puede ser identificada y contada ms 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 mltiples entradas
proceden de diferentes usuarios funcionales que introduzcan diferentes grupos de
datos (cada uno describiendo el mismo objeto de inters)
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 manipulacin de datos) no debern
ser y contadas ms de una vez en un proceso funcional.
d) Si las mltiples 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 ms de una vez en ese proceso.
Los siguientes ejemplos ilustran las reglas anteriores.
/5e%plo 1 para una regla a)3 en un proceso &uncional, todas las 2ecturas de datos 8ue descri7en un o75eto de inters en
particular pueden considerarse lgica%ente para de#ol#er todos los atri7utos 8ue descri7en ese o75eto de inters (es decir,
el con5unto del A#ector de estadosB de ese o75eto de inters). 1or lo tanto nor%al%ente, slo una 2ectura de cual8uier dato
so7re un o75eto de inters es &uncional%ente necesaria y de7e ser identi&icada en un proceso &uncional.
/5e%plo de las reglas a) y 7)3 @espus del /5e%plo 1, todos los datos 8ue son le4dos de7en ha7erse hecho persistentes
por una /scritura, este es el caso en 8ue nor%al%ente ser4a identi&icada una /scritura por %o#er un grupo de datos 8ue
contiene todos los atri7utos de un o75eto de inters y 8ue de7e hacerse persistente en un deter%inado proceso &uncional,
segCn la nor%a a). /s posi7le, sin e%7argo, 8ue e>istan ;<= para un Cnico proceso &uncional para escri7ir dos datos
di&erentes grupos descri7iendo el %is%o o75eto de inters, por e5e%plo, para un uso posterior por dos usuarios &uncionales
distintos en otros procesos &uncionales. /ste ser4a un /5e%plo donde la nor%a 7) se aplica, cuando dos /scrituras de datos
8ue descri7en el %is%o o75eto de inters pueden ser identi&icadas y contadas en el %is%o proceso &uncional.

+3
/5e%plo 3 para la regla 7)3 /s posi7le 8ue e>istan ;<= para un Cnico proceso &uncional 8ue produ6can dos o %:s Salidas
de di&erentes grupos de datos descri7iendo el %is%o o75eto de inters, destinados a di&erentes usuarios &uncionales. 1or
e5e%plo, cuando un nue#o e%pleado llega a una e%presa, se produce un in&or%e por el e%pleado para &ir%ar sus datos
personales co%o #:lidos y un %ensa5e es en#iado a Seguridad para autori6ar al e%pleado a entrar en el edi&icio.
/5e%plo * por regla c)3 Suponga 8ue se re8uiere una 2ectura en los re8uisitos &uncionales de usuario 8ue en la pr:ctica
re8uiere %uchas recuperaciones de ocurrencias, co%o en la 7Cs8ueda de un &ichero. 1ara la %edicin, identi&icar slo una
2ectura.
/5e%plo + por regla c)3 Suponga 8ue en un proceso &uncional de tie%po real los re8uisitos &uncionales de usuario re8uieren
8ue los datos entren desde un deter%inado usuario &uncional, por e5e%plo, un dispositi#o de hard'are, dos #eces en un
inter#alo de tie%po para %edir un tipo de ca%7io o para co%pro7ar si un #alor ha ca%7iado durante el proceso. Sie%pre
8ue las dos entradas sean idnticas en tr%inos del grupo de datos reu7icado y las %anipulaciones de datos asociadas,
slo de7er: ser identi&icada una entrada.
/5e%plo , para la nor%a c)3 #ase la seccin *.1., Jor%a d) para entradas, y la seccin *.1.3, Jor%a 7) para las salidas.
/5e%plo - para regla d)3 Suponga un proceso &uncional en el 8ue es necesario 8ue proporcione di#ersas opciones de
%anipulacin de datos dependiendo de los #alores de los atri7utos de una entrada. 1ara la %edicin, identi&icar slo una
entrada.
/5e%plo .3 Suponga%os 8ue una 2ectura de un grupo de datos es necesaria en los re8uisitos &uncionales de usuario, pero
el desarrollador decide i%ple%entarla %ediante dos co%andos para recuperar di&erentes su7?series de atri7utos del %is%o
o75eto de inters de las &icheros de al%acena%iento en di&erentes puntos del proceso &uncional. Identi&icar slo una lectura.
4.1.8. Cuando un proceso funcional mueve datos para o desde un fichero de almacenamiento.
Esta seccin explica los movimientos de datos involucrados cuando un proceso funcional de parte de
una aplicacin software es requerido para desplazar datos hasta o desde un fichero de
almacenamiento, de manera local o remota. Los casos tambin mostrar cmo el almacenamiento de
una aplicacin necesita ser manipulado por otro software que soporta la aplicacin en otra capa, tales
como el almacenamiento permanente en un dispositivo.
Los casos ilustran la aplicacin del principio (g) del Modelo de Contexto Software y los principios del
Modelo Genrico 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 aplicacin donde el
requisito para recuperar datos persistentes es manejado por un controlador software local en otra
capa. El segundo caso muestra cmo 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
aplicacin.
En trminos prcticos, los casos son aplicables cuando la tarea consiste en medir dos partes de
software que tienen una relacin jerrquica (es decir, cuando las dos piezas estn en diferentes
capas) o tienen una relacin cliente-servidor (es decir, cuando las dos piezas estn en la misma
capa). Los casos muestran cmo son medidos y modelados los movimientos de datos que son
fsicamente intercambiados entre las dos partes de software.
Los ejemplos se ilustran usando los convenios de Diagramas de Secuencia de Mensajes. La notacin
de estos diagramas es como se explica a continuacin:
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 lnea vertical punteada (discontinua) representa un lmite frontera
/5e%plo 13 Cuando un proceso &uncional de7e %o#er datos hasta o desde un &ichero de al%acena%iento local
/ste e5e%plo i%plica dos aplicaciones so&t'are, aplicacin A"B y aplicacin AKB 8ue es el dri#er para un dispositi#o de
al%acena%iento 8ue la aplicacin so&t'are utili6a. (1ara si%pli&icar ignora%os la pro7a7le presencia de un siste%a
operati#oD el siste%a operati#o e&ecti#a%ente trans%ite las peticiones de la aplicacin al dri#er del dispositi#o y de#uel#e los
resultados de las peticiones.)
/l concepto de capas nos dice 8ue las dos aplicaciones so&t'are est:n en di&erentes capas3 la capa de aplicacin y la capa
de dri#ers de dispositi#os. ;4sica%ente, hay una relacin 5er:r8uica entre las dos pie6as y (ignorando el siste%a operati#o)
una inter&a6 &4sica entre el so&t'are de las dos capas, co%o por e5e%plo en la ;ig. ..3.1.
Jor%al%ente, los re8uisitos &unciones de usuario de la aplicacin A"B especi&icar:n los procesos &uncionales 8ue incluyen la
necesidad de 2eer y /scri7ir en el &ichero de al%acena%iento pero no en lo concerniente a c%o las 2ecturas y /scrituras
son %ane5adas por otras in&raestructuras so&t'are.
"plicando el %odelo de COSMIC a las dos pie6as de so&t'are, los usuarios &uncionales del so&t'are " en la capa de
aplicacin podr4an ser, por e5e%plo, usuarios hu%anos, %ientras 8ue los usuarios &uncionales del so&t'are K en la capa del
controlador es la aplicacin " (ignorando el siste%a operati#o).
Suponga%os 8ue una consulta del proceso &uncional R;1 "S del so&t'are " en la capa de aplicacin e>ige una 2ectura. 2a
&igura *.1...1 (a) %uestra el %odelo COSMIC de la aplicacin en la 8ue se 7usca in&or%acin. 2a recuperacin &4sica de los
datos necesarios de los &icheros de al%acena%iento es %ane5ado por un proceso &uncional RKS del so&t'are K en la capa del
controlador. 2a &igura *.1...1 (7) %uestra el %odelado de este proceso &uncional del dri#er del dispositi#o.

Application in Layer A
FP A
E
R
Functional
user of
application
in layer A
X
Persistent storage
device driver in Layer B
FP B
E
E
X
Functional
user of
software in
layer #
($
application
in layer A)
Functional
User%
!ersistent
storage
hardware
de&ice
X
Application in Layer A
FP A
E
R
Functional
user of
application
in layer A
X
Persistent storage
device driver in Layer B
FP B
E
E
X
Functional
user of
software in
layer #
($
application
in layer A)
Functional
User%
!ersistent
storage
hardware
de&ice
X

Figuras 4.1.8.1 (a) y (b) Solucin para una lectura emitida por el software 'A' en la capa de aplicacin del
software a 'B' en la capa del controlador.
2a &igura *.1...1 a) %uestra la 7Cs8ueda de in&or%acin desencadenada por una entrada, seguida de una lectura y luego
una salida con el resultado de la 7Cs8ueda. /l proceso &uncional " no tiene conoci%iento de donde se o7tienen los datos, ni
8ue en la pr:ctica la lectura es delegada a algunos controladores de dispositi#os so&t'are.
2a &igura *.1...1 7) %uestra 8ue &uncional%ente la 2ectura solicita 8ue la aplicacin " es reci7ida co%o un e#ento de
/ntrada al proceso &uncional 1; K, 8ue luego recupera los datos solicitados desde el dispositi#o &4sico de al%acena%iento y
de#uel#e los datos a la aplicacin co%o una salida. 2a aplicacin " es pues un usuario &uncional de los controladores del
so&t'are K.
/l aparente desencuentro entre el nC%ero de %o#i%ientos de datos de la A2ecturaB del so&t'are en la capa de aplicacin y
la R/ntradaESalida parS de so&t'are en la capa del dispositi#o es de7ido al hecho de 8ue por con#enio, una 2ectura de datos
se considera 8ue incluye cual8uier &uncionalidad de Rsolicitud de lecturaS.
/>acta%ente %odelos an:logos se aplicar4an si el proceso &uncional ;1 " &uera re8uerido para crear algCn dato
per%anente %ediante una /scritura. /n este caso, la salida del proceso &uncional 1; K del dispositi#o so&t'are contendr4a
cual8uier Acdigo de retornoB o %ensa5e de error.
/5e%plo 3 Cuando un proceso &uncional de7e o7tener datos de un co%ponente ho%logo o par de so&t'are

++
/n este e5e%plo, los dos pares de co%ponentes de so&t'are a ser %edidos se supone 8ue son un RclienteEser#idorS, es decir,
donde un co%ponente, el cliente, reci7e los ser#icios yEo datos del otro co%ponente, Rser#idorS. 2a &igura *.1... %uestra un
e5e%plo de esa relacin, en la 8ue las dos pie6as son i%portantes co%ponentes de la %is%a aplicacin. 2a %is%a relacin
8ue e>istir4a y el %is%o es8ue%a se aplicar4an si las dos pie6as &ueran aplicaciones ho%logas separadas, donde una es
necesaria para o7tener datos de la otra.
;4sica%ente, los dos co%ponentes pares podr4an e5ecutarse en di&erentes procesadoresD en tal caso interca%7iar4an datos
a tra#s de los respecti#os siste%as operati#os y cual8uier otra capa inter%edia de sus procesadores en una ar8uitectura
so&t'are tal co%o la ;ig. ..3.1. 1ero lgica%ente, aplicando el %odelo COSMIC, los dos co%ponentes interca%7ian datos
a tra#s de R/ntradaESalidaS. $odo el so&t'are y hard'are 8ue inter#iene es ignorado en este %odelo (co%o ta%7in se
indica en el lado derecho de &igura. 3.1.1).
2a ;igura *.1... %uestra un proceso &uncional ;1 C1 de un co%ponente cliente C1 8ue es desencadenado por una
/ntrada de su usuario &uncional 8ue co%prende, por e5e%plo los par:%etros de la in&or%acin 7uscada. 2os re8uisitos
&uncionales del co%ponente C1 reconocer:n 8ue este co%ponente de7e pedir al co%ponente ser#idor C los datos
re8ueridos, y de7e decirle 8u datos son necesarios.
2a Salida cru6a la &rontera entre C1 y C y se con#ierte en el desencadenante de la entrada de un proceso &uncional ;1 C
en el co%ponente C. /l proceso &uncional ;1 C del co%ponente C o7tiene los datos necesarios %ediante un proceso de
lectura, y en#4a los datos a C1 %ediante una salida. /l 1roceso ;uncional ;1 C1 del co%ponente C1 reci7e este
%o#i%iento de datos co%o una entrada. ;1 C1 pasa entonces los datos co%o una Salida para satis&acer la 7Cs8ueda de su
usuario &uncional. /ste caso por lo tanto re8uiere - %o#i%ientos de datos para satis&acer la solicitud. /sto se co%para con
los 3 %o#i%ientos de datos (1 > /, 1 > = y 1 > M) 8ue ha7r4an sido necesarios si el co%ponente C1 hu7iera sido capa6 de
recuperar los datos del &ichero de al%acena%iento local co%o en la &igura *.1...1 (a).
Component C1 (Client)
FP C1
E
E
X
X
Component C2 (Server)
FP C2
E
X
R
Functional user of
component '(
Component C1 (Client)
FP C1
E
E
X
X
Component C2 (Server)
FP C2
E
X
R
Functional user of
component '(

Figura 4.1.8.2 Intercambio de datos entre componentes semejantes en la misma capa
/l Co%ponente C pro7a7le%ente, por supuesto, utilice los ser#icios de algunos dispositi#os de al%acena%iento en una
capa in&erior de la ar8uitectura so&t'are para recuperar los datos del hard'are, co%o en el caso 1.
Comparando los casos 1 y 2, vemos que en el caso 1, los modelos de la aplicacin 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 aplicacin A es un usuario funcional de un dispositivo
controlador del software B. Pero lo contrario no es cierto, demostrando as el carcter jerrquico 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 comn.

+,
Nota: En estos dos casos hemos ignorado, por simplificar, la posibilidad de un cdigo de retorno que
acompae a la Lectura, que podra conducir a la generacin de un mensaje de error adems de la
salida como el resultado de la bsqueda en la aplicacin 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 seccin 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 inters). 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 enva una entrada que desencadena el inicio del
proceso funcional
Cuando un proceso funcional, habindose iniciado, espera, expectante a la
prxima Entrada desde el usuario funcional (tpica en el software de negocio de
aplicacin, de un usuario funcional humano).
Cuando un proceso funcional, habindose iniciado, pide al usuario funcional que
le enve envame tus datos ahora, si tienes alguno, y el proceso funcional enva
sus datos.
Cuando un proceso funcional, habindose iniciado, inspecciona los datos de un
usuario funcional y recupera los datos que necesita.
En estos dos ltimos casos (tpico de un sistema de votacin 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 slo 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. Slo 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 sern identificados. La salida contiene la solicitud especfica de los
datos; la entrada contiene los datos.
/5e%plo 1 de la regla a), pri%er y segundo punto3 donde un proceso &uncional proporciona a un hu%ano una pantalla de
entrada de datos, co%o en una aplicacin de negocios on?line, el #isuali6ar la pantalla Ren 7lancoS no se cuenta co%o una
Salida. Solo rellenar la pantalla es contado co%o una o %:s entradas (#er ta%7in la seccin *.1.10).
/5e%plo de la regla a), tercer o cuarto escenario3 Suponga%os 8ue un proceso &uncional de un siste%a con proceso
so&t'are de control en tie%po real necesario para co%pro7ar un array con idnticos sensores. 2as cuestiones relati#as al
proceso son una /ntrada (tipo). (@e los sensores solo se identi&ica y se cuenta una /ntrada, aun8ue hay %Cltiples
ocurrencias.)Suponga%os 8ue la /ntrada de7e en la pr:ctica pasar a un dispositi#o controlador de so&t'are en una capa
in&erior de la ar8uitectura, 8ue &4sica%ente o7tiene los datos necesarios desde el sensor co%o se ilustra en la ;ig. ..3..
2os procesos &uncionales del proceso so&t'are de control y de los controladores so&t'are para los sensores ser4a co%o se
%uestra en las ;iguras *.1.!.1 (a) y (7) de7a5o.

+-
Process Control sot!are
in Layer A
FP A
E1
E2
Functional
user of
application
in layer A
"#m$ sensor device
driver in Layer B
FP B
E
E
X
Functional
user of
software in
layer #
($ process
control
software in
layer A)
Dum
sensor
Dum
sensor
(etc)
Process Control sot!are
in Layer A
FP A
E1
E2
Functional
user of
application
in layer A
"#m$ sensor device
driver in Layer B
FP B
E
E
X
Functional
user of
software in
layer #
($ process
control
software in
layer A)
Dum
sensor
"#m$ sensor device
driver in Layer B
FP B
E
E
X
Functional
user of
software in
layer #
($ process
control
software in
layer A)
Dum
sensor
Dum
sensor
(etc)

La figura 4.1.9.1 (a) y b) Solucin para una entrada emitida por el software 'A' en la capa de la aplicacin
del proceso de control recibida por el software 'B' en la capa del dispositivo de control del sensor.
2a &igura *.1.!.1 (a) Muestra 8ue el proceso so&t'are de control del proceso &uncional R;1 "S es desencadenado por una
entrada R/1S por e5e%plo de un golpe de relo5. /l proceso &uncional luego o7tiene la entrada R/S desde el array de sensores
para reci7ir las %Cltiples ocurrencias de los sensores de lecturas. 2os sensores son ta%7in usuarios &uncionales del
proceso so&t'are de control.
2a &igura *.1.!.1 (7) Muestra 8ue el so&t'are 8ue i%pulsa el dispositi#o del sensor reci7e la /ntrada (pro7a7le%ente en la
pr:ctica %ediante un siste%a operati#o) co%o el disparador de un proceso &uncional R;1 KS. /ste proceso &uncional o7tiene
una /ntrada de su usuario &uncional (tipo) y del sensor (tipo) para o7tener los datos de los sensores 8ue se reintegrar:n al
proceso so&t'are de control co%o una salida. /l proceso &uncional del proceso so&t'are luego continCa con su
trans&or%acin de los datos del sensor. /l hecho de 8ue hay %Cltiples ocurrencias de este ciclo de recopilacin de datos de
cada uno de los idnticos sensores es ignorado en el %odelado.
/l aparente e%pare5a%iento entre la Cnica /ntrada del proceso so&t'are de control y la /ntradaESalida par de los
controladores so&t'are es de7ida al %odo en 8ue una /ntrada es considerada co%o cual8uier Rsolicitud de entradaS
&uncional.
/5e%plo 3 de la nor%a 7)3 Suponga 8ue un proceso &uncional en#4a a uno de sus usuarios &uncionales co%o un dispositi#o
hard'are RinteligenteS o otro par de pie6as so&t'are con algunos par:%etros para una consulta o los par:%etros de un
c:lculo, o algunos datos para ser co%pri%idos. 2a respuesta de los usuarios &uncionales se o7tiene %ediante una
entradaEsalida par, tal co%o se descri7e en la seccin *.1.., Caso .
4.1.10 Comandos de control
Un comando de control" es una categora especial de un movimiento de datos que es reconocido
slo en el dominio de aplicaciones de negocio y que debe pasarse por alto cuando al medir un
tamao funcional. La definicin es:
Definicin 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 ningn movimiento de datos sobre el objeto de
inters.
Nota: El trmino comando de control es utilizado slo en el contexto de medicin
software de aplicacin 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 inters.
Ejemplos son barras de desplazamiento; pinchar sobre una pestaa o escribir una
clave, hacer clic en el OK para confirmar una accin anterior, etc.


+.
Regla Comandos de control en el dominio de aplicaciones de negocio.
En el dominio de aplicaciones de negocio, los comandos de control sern ignorados ya
que no implican ningn movimiento de datos sobre el objeto de inters.
/5e%plos de co%andos de control en el do%inio de aplicaciones de negocio son las &unciones 8ue per%iten a un usuario
&uncional controlar la ca7ecera de una pantalla (o no) o los su7totales 8ue han sido calculados, na#egar arri7a y a7a5o y la
na#egacin &4sica entre pantallas, hacer clic en ROLS al reconocer un %ensa5e de error o con&ir%ar algunos datos
introducidos, etc. 2os Co%andos de Control por lo tanto ta%7in incluyen co%andos del %enC 8ue per%iten al usuario
&uncional na#egar por uno o %:s procesos &uncionales pero no iniciar un proceso &uncional, y co%andos para %ostrar una
pantalla o &or%ulario en 7lanco 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 seal o movimiento de datos sobre el objeto de inters
procedente de un usuario funcional debe justificarse, es decir, deber medirse.
4.2. Aplicando la funcin de medicin
Este paso consiste en la aplicacin de la medida funcional de COSMIC a cada uno de los
movimientos de datos identificados en cada proceso funcional.
Definicin Medicin funcional COSMIC
La medicin funcional de COSMIC es una funcin matemtica que asigna un valor a su
argumento basado en el estndar de medicin COSMIC. El argumento de la medicin
funcional COSMIC es el movimiento de datos.

Definicin Medida estndar COSMIC
La medicin estndar de COSMIC, 1 PPC (Punto de Funcin COSMIC) se define como
el tamao de un movimiento de datos.
Segn esta funcin de medicin, cada instancia de un movimiento de datos (Entrada, Salida, lectura o
Escritura) que se requiere para ser aadido, cambiado o suprimido y que ha sido identificado segn la
seccin 4.1 recibe una puntuacin de 1 PPC.
4.3. Agregar resultados de medicin
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 tamao funcional. Este paso se realiza segn los
siguientes principios y reglas.
4.3.1 Reglas generales de agregacin
Reglas Agregando los resultados de la medicin
a) Para cualquier proceso funcional, el tamao funcional de cada movimiento de datos
individual debe ser agregado en un nico valor de tamao funcional en unidades de
CFP para luego sumar todos juntos.
Tamao (proceso funcional
i
) = tam(Entradass
i
) + tam(Salidas
i
) +
tam(Lecturass
i
) + size(Escrituras
i
)
b) Para cualquier proceso funcional, el tamao funcional de los cambios en requisitos
funcionales de usuario se sumarn al tamao de movimientos de datos que han sido
aadidos, modificados o eliminados en proceso funcional para dar un tamao del

+!
cambio en unidades de CFP, segn la siguiente frmula.
Tamao (Cambio(procedso funcional
i
)) = tam (movimientos datos aadidos
i
) +
tam (movimientos datos modificados
i
) +
tam (movimientos datos eliminados
i
)
Para ms informacin sobre el agregando del tamao funcional, vase la seccin
4.3.2. Para medir el tamao de los cambios en el software, vase la seccin 4.4.
c) El tamao de una pieza de software dentro de un mbito de aplicacin se obtendr
sumando los tamaos de sus procesos funcionales, sujeto a las normas e) y f) debajo
d) El tamao de cualquier cambio en una pieza de software dentro de un mbito de
aplicacin se obtendr sumando los tamaos de todos los cambios a todos sus
procesos funcionales, sujeto a las normas e) y f) abajo
e) Los Tamaos de piezas de software o de cambios de piezas de software en el interior
de las capas podrn sumarse slo si se mide al mismo proceso funcional su nivel de
granularidad de sus requisitos funcionales de usuario.
f) Los Tamaos de piezas de software y/o cambios en los tamaos de la misma dentro
de una capa o de diferentes capas sern sumados slo si tiene sentido hacerlo, a
efectos de la medicin.
g) El tamao de una aplicacin software no puede obtenerse sumando los tamaos de
sus componentes (independientemente de cmo se descompone) al menos que el
tamao de las contribuciones de los movimientos de datos inter-componentes sean
eliminadas.
h) Si el mtodo COSMIC se extiende localmente (por ejemplo para medir algn aspecto
del tamao no recogido por el mtodo estndar), entonces el tamao medido por la
extensin local debe ser informado por separado como se describe en la seccin 5.1 y
no puede ser aadido al tamao obtenido por el mtodo estndar, medido en CFP
(vase adems la seccin 4.5)
/5e%plo 1 de las nor%as 7) y c)3 <n ca%7io solicitado para una pie6a de so&t'are podr4a ser3 Ra9adir un nue#o proceso
&uncional de ta%a9o , C;1S, y en otro proceso &uncional agregar un %o#i%iento de datos, hacer %odi&icaciones a otros tres
%o#i%ientos de datos y supri%ir dos %o#i%ientos. R/l ta%a9o total del ca%7io solicitado es de , P 1 P 3 P Q 1 C1;.
/5e%plo de la regla &)3 Si di#ersas partes i%portantes de una pie6a de so&t'are se desarrollan utili6ando tecnolog4as
di&erentes, por di&erentes proyectos su7?e8uipos, no puede ha7er ningCn #alor pr:ctico en a9adir sus ta%a9os 5untos.
/5e%plo 3 para la regla g)3 Si un tro6o de so&t'are es
Primera medicin como un todo, es decir, todos dentro del mismo alcance.
Entonces en segundo lugar el tamao de cada uno de sus componentes se mide por separado,
cada uno dentro de su propio mbito.
/l ta%a9o total de la su%a del ta%a9o de todos los co%ponentes por separado (en el segundo caso) superar: al ta%a9o
cuando se %ide Rco%o un todoS (en el pri%er caso) de7ido a la contri7ucin de ta%a9o de todos los %o#i%ientos de datos
inter?co%ponentes. /stos %o#i%ientos no son #isi7les cuando la pie6a se %idi Rco%o un todoS y de7e ser eli%inado para
o7tener el ta%a9o Rdel todoS. Vase ta%7in el e5e%plo en la seccin so7re la %edicin en distintos ni#eles de granularidad
en ar8uitecturas de so&t'are puro en el docu%ento A$e%as a#an6ados y relacionadosF.
Es de sealar que, dentro de cada capa identificada, la agregacin 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 medicin y bajo las
normas d), e) y f) de arriba.
4.3.2. Ms sobre la agregacin del tamao funcional
En un contexto donde el tamao funcional deba utilizarse como una variable en un modelo, para
estimar el esfuerzo por ejemplo, y el software a ser medido tenga ms de una capa o componente

,0
par, la agregacin normalmente se realizar por capas o por pares de componentes ya que no son
ejecutados a menudo con la misma tecnologa.
/5e%plo 13 Considere un so&t'are donde la capa de aplicacin se e5ecutar: utili6ando 3N2 y un con5unto de 7i7liotecas
e>istentes, %ientras la capa de transporte podr4a estar i%ple%entada utili6ando lengua5e ensa%7lador. 2a unidad de
es&uer6o asociada con la construccin de cada capa, %uy pro7a7le%ente, sea di&erente, y, en consecuencia, una
esti%acin del es&uer6o ser: preparada por separado para cada capa so7re la 7ase de su ta%a9o respecti#o.
/5e%plo 3 Si un e8uipo del proyecto ha de desarrollar una serie de i%portantes pie6as de so&t'are y est: interesado en su
producti#idad glo7al, se puede su%ar el tra7a5o?hora necesario para desarrollar cada pie6a. @e %anera si%ilar, se pueden
su%ar los ta%a9os de las principales pie6as 8ue ha desarrollado si (pero slo si) esos ta%a9os satis&acen las nor%as dadas
anterior%ente.
La razn por la que tamaos de grandes partes de software de diferentes capas de una arquitectura
estndar 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 debern
intercambiar mensajes. Es lgico y razonable que los tamaos de las distintas piezas puedan
sumarse, siempre sujeto a las normas d), e) y f) arriba indicadas. Sin embargo, en contraste con esto,
el tamao de una pieza grande de software puede no ser obtenido sumando el tamao 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 podra ser til para
analizar la contribucin de cada tipo en el tamao total de una capa y podra ayudar as a caracterizar
la naturaleza funcional de la capa medida.
4.4 Ms en la medicin del tamao de los cambios de software
Un cambio funcional de software existente es interpretado en el mtodo COSMIC como cualquier
combinacin de sumas de nuevos movimientos de datos o de modificaciones o eliminaciones de los
movimientos de datos existentes. Los trminos 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, slo 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 medicin del tamao 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 tamao funcional de este cambio es el tamao del software del reemplazo,
medido segn las reglas normales para la medicin del software nuevo. Este caso no ser examinado
nuevamente en esta seccin. 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 aplicacin es suprimida (desconectada sera una mejor
descripcin) por abandonar el cdigo de programa en lugar de slo eliminar el contacto con la
funcionalidad obsoleta. Cuando la funcionalidad de la parte obsoleta asciende a 100 CFP pero la

,1
parte puede ser desconectada por cambiar, digamos, 2 movimientos de datos, 100 y no 2
movimientos de datos sern identificados como el tamao del cambio funcional. Podemos medir el
tamao de la exigencia, no el tamao que fue implementado.
Nota: La diferencia entre el tamao de los cambios funcionales (discutido aqu) y el cambio en el
tamao funcional del software. Generalmente, son diferentes. El tamao de la ltima est recogido en
la seccin 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, vase la seccin 4.1.6). Por lo tanto para la medicin un movimiento de datos se
considera que es modificado funcionalmente si:
El Grupo de datos es reubicado y/o
Est asociado a una manipulacin de datos
Son modificados en modo alguno.
Un grupo de datos es modificado si:
Se aaden nuevos atributos a este grupo de datos y/o
Los atributos son retirados de los grupos de datos y/o
uno o ms atributos existentes son modificados, por ejemplo, en sentido o formato (pero no en
sus valores)
Una manipulacin de datos es modificada si es funcionalmente ha cambiado en modo alguno, por
ejemplo por cambiar el clculo, el formato especfico, presentacin y/o validacin de datos. `La
presentacin puede significar, por ejemplo la fuente, el color de fondo, la longitud del campo, el
nmero de decimales, etc.
Los comandos de control y los datos de aplicacin general no implican movimientos de datos, ya que
no hay datos sobre los objetos de inters que son movidos. Por lo tanto, los cambios de comandos de
control y de datos de aplicacin general no deben medirse. Por ejemplo, cuando el color de la
pantalla para todas las pantallas es cambiado, este cambio no debe medirse. (Ver seccin 4.1.10
para una explicacin de comandos de control y datos de aplicacin general.)
Reglas Modificando un movimiento de datos
a) Si un movimiento de datos debe ser modificado debido a un cambio de la
manipulacin de los datos relacionados con el movimiento de datos y/o debido a un
cambio en el nmero 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 modificacin
del grupo de datos, no sern identificados como movimientos de datos modificados.
Nota 1: Una modificacin para un valor de una ocurrencia de un atributo, tales como una
modificacin de un cdigo individual de un miembro de un atributo cuyos valores son un
sistema de codificacin no es una modificacin de los tipos del atributo.
Nota 2: Una modificacin de cualquier dato que figuren en entrada o salida por pantalla
que no est relacionado con el objeto de inters para un usuario funcional no ser
identificados como un cambio CFP (ver seccin 3.3.4 para los ejemplos de estos datos.)
/5e%plo de nor%as a) y 7)3 Suponga%os un re8uisito para a9adir o %odi&icar los atri7utos de los datos de un grupo @1, 8ue
despus de la %odi&icacin se #uel#e @. /n el proceso &uncional R"S donde esta %odi&icacin es necesaria, todos los

,
%o#i%ientos de datos a&ectados por la %odi&icacin de7er4an ser identi&icados y contados. "s4, segCn la nor%a a), si los
datos %odi&icados grupo @ son persistentes yEo es la salida en proceso &uncional ", identi&icar una /scritura yEo una Salida
de datos respecti#a%ente %odi&icada. Sin e%7argo, es posi7le 8ue otros procesos &uncionales sean de 2ectura o /ntrada
en este %is%o grupo de datos @, pero su &uncionalidad no se #e a&ectada por la %odi&icacin por8ue estos no utili6an los
ca%7ios ni los nue#os atri7utos de datos. /stos procesos &uncionales siguen para procesar el grupo de datos reu7icado
co%o si &uese aCn @1. "s4, segCn la nor%a (7), estos %o#i%ientos de datos en los otros procesos &uncionales 8ue no son
a&ectados por la %odi&icacin del %o#i%iento de dato(s) &uncional de un proceso no de7en ser identi&icados y contados
co%o %odi&icados.
4.4.2 Tamao del software funcionalmente modificado
Despus del cambio funcional de una pieza de software, su nuevo tamao total equivale al tamao
original, ms el tamao funcional de todos los nuevos movimientos de datos, menos el tamao
funcional de todos los movimientos de datos retirados. Los movimientos de datos modificados no
tienen influencia sobre el tamao de la pieza de software ya que estos existen tanto antes como
despus de que las modificaciones han sido realizadas.
4.5. Extensiones del mtodo de medicin COSMIC.
4.5.1. Introduccin
El mtodo de medicin COSMIC de tamao funcional no pretende medir todos los aspectos del
software tamao. As, el mtodo de medicin COSMIC actualmente no est diseado para
proporcionar una forma estndar de contabilidad del tamao de ciertos tipos de Requisitos
funcionales de Usuario, especialmente algoritmos matemticos complejos o secuencias de normas
complejas que se encontraron en sistemas expertos.
Tambin, la influencia del nmero de atributos por movimiento de datos sobre software en el tamao
del software no es capturado por este mtodo de medicin. La influencia sobre el tamao de la
manipulacin de sub-procesos de datos es tenida en cuenta para simplificar la suposicin de que es
vlido slo para determinados dominios de software, tal como se define en la seccin 1.1.1 sobre la
aplicabilidad del mtodo.
Otros parmetros tales como complexin (no obstante definido) se podran considerar que
contribuyen al tamao funcional. Un debate constructivo sobre esta cuestin es si primero se
requeriran definiciones comunes acordadas de los otros elementos dentro de la mala nocin definida
de tamao como se aplica al software. Tales definiciones son todava, en este punto, objeto de
investigacin y de mucho debate.
Sin embargo, la medida de tamao COSMIC se considera una buena aproximacin para el estado del
mtodo propuesto y el dominio de aplicabilidad. Sin embargo, puede ser que dentro del entorno local
de una organizacin que utilice el mtodo de medicin COSMIC, se desee para tener en cuenta esa
funcionalidad en una forma que sea vlida como una norma local. Por esta razn, el mtodo de
medicin COSMIC tiene disposicin para extensiones locales.
Cuando esas extensiones locales son utilizadas, los resultados de medicin deben ser comunicados
segn la convencin especial presentada en la seccin 5.1.
Las siguientes secciones muestran como extender el mtodo con un estndar local.
4.5.2. Extensiones locales con algoritmos complejos.
Si se considera necesario para tener en cuenta algoritmos complejos, puede organizarse un estndar
local para esta funcionalidad excepcional. En cualquier proceso funcional donde existe una
anormalmente compleja manipulacin de datos de un sub-proceso funcional, el medidor est libre de
asignar su propia determinacin-local de puntos de funcin.

,3
/5e%plo3 <na e>tensin local de la nor%a puede ser3 A/n nuestra organi6acin, un punto de &uncin local ;1 se asigna a
algorit%os %ate%:ticos co%o (lista de de&iniciones locales y e5e%plos 7ien entendidos). @os puntos de &uncin locales ;1Ss
son asignados para (otra lista de e5e%plos), etc.B
4.5.3. Extensin Local con sub-unidades de medida
Cuando se necesita ms precisin en la medicin de los movimientos de datos, entonces se puede
definir una sub-unidad de medida. Por ejemplo, un medidor puede ser sub-dividido en 100
centmetros o 1000 milmetros. Anlogamente, el movimiento de un nico atributo podra ser utilizado
como sub-unidad de medida. Las mediciones sobre una pequea muestra de software en los ensayos
de campo de COSMIC indican que en la muestra medida, el nmero promedio de atributos de datos
por movimiento de datos no vara mucho en los cuatro tipos de movimiento de datos. Por esta razn 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 precaucin es claramente necesaria cuando se
comparan los tamaos medidos en CFP (puntos de funcin COSMIC) de dos piezas de software
distintas donde el nmero promedio de atributos datos por movimiento difiere notablemente en
ambas.
Cualquiera que desee perfeccionar el mtodo COSMIC al introducir una sub-unidad de medida es
libre de hacerlo, pero debe dejar claro que el tamao resultante medido no se expresa en el estndar
de puntos de funcin COSMIC.

,*
5
5

INFORME DE MEDIDAS
El modelo de software genrico 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 representacin del Modelo de Software Genrico se presenta en el apndice A.
Los resultados de medida COSMIC deben ser reportados y archivados de acuerdo a las siguientes
normas:
5.1 Etiquetado
Al informar de un tamao funcional COSMIC se debera etiquetar de acuerdo a la siguiente regla,
relacionada con el estndar ISO/IEC 14143-1:2007.
Reglas Etiquetado de las medidas COSMIC
Los resultados de medida COSMIC se deberan anotar como x CFP(v.y), donde:
x representa el valor numrico del tamao funcional
v.y representa la identificacin de la versin estndar del mtodo COSMIC usado
para obtener el valor numrico del tamao funcional x.
Nota: Si un mtodo de aproximacin local se us para obtener la medida, pero aparte la
medida se hizo utilizando las normas de la versin estndar COSMIC, la regla de
etiquetado anterior debera utilizarse, pero en algn sitio se deber anotar el uso del
mtodo de aproximacin.-ver seccin 5.2.
/5e%plo3 <n resultado o7tenido e%pleando las reglas de este Manual de Medicin se de7er4a denotar co%o R> C;1
(#3.0.1)S.
Cuando se usan extensiones locales, como se define en la seccin 4.5, el resultado de la medida
debe ser informado como se define a continuacin:
Reglas Etiquetado de extensiones locales COSMIC
Un resultado de medida COSMIC utilizando extensiones locales debera ser anotado
como:
x CFP(v.y) + Z Local FP, donde:
x representa el valor numrico obtenido al agregar todas los resultados de
medidas individuales de acuerdo al mtodo estndar COSMIC, versin v.y.
v.y representa la identificacin de la versin estndar del mtodo COSMIC usado
para obtener el valor numrico de tamao funcional x.
z representa el valor numrico obtenido al agregar todos los resultados
individuales de medida obtenidos de las extensiones locales al mtodo COSMIC.


,+

5.2 Archivando los resultados de medida COSMIC
Al archivar los resultados de medida COSMIC, se debe mantener la siguiente informacin para
asegurar que el resultado sea siempre interpretable.
Reglas Hacer informes de medidas COSMIC
Adems de las medidas reales, descritas en el punto 5.1, se deberan tener en cuenta
los siguientes atributos de cada medida.
a) Identificacin del componente de software medido (nombre, versin ID o
Configuracin ID)
b) Las fuentes de informacin usadas para identificar el FUR utilizado para la medida.
c) El mbito del software
d) Una declaracin del propsito de la medida
e) Una descripcin del alcance de la medida y su relacin con el alcance global de una
serie de medidas relacionadas, si las hubiera. (Usar las categoras de alcance
genricas de la seccin 2.2)
f) Los usuarios funcionales del software
g) El nivel de granularidad del FUR y el nivel de descomposicin del software
h) El punto en el ciclo de vida del proyecto cuando se hizo la medida (especialmente si
la medida es una estimacin 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 mtodo de medida estndar COSMIC fue utilizado, y/o se us
una aproximacin local al mtodo estndar y/o se utilizaron extensiones locales (ver
seccin 4.5). Usar las reglas de etiquetado de las secciones 5.1 y 5.2.
k) Una indicacin de si la medida es de funcionalidad desarrollada o entregada
(funcionalidad desarrollada se obtiene creando nuevo software; funcionalidad
entregada incluye funcionalidad desarrollada y tambin incluye funcionalidad
obtenida por otros medios diferentes a crear nuevo software, p.ej: incluir todas las
formas de reutilizacin de software existente, el uso de parmetros existentes para
aadir o cambiar funcionalidad, etc.).
l) Una indicacin 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
aadida, cambiada o borrada-ver 4.4)
m) Una descripcin de la arquitectura de capas de las que est hecha la medida, si es
aplicable
n) El nmero de componentes importantes, si es aplicable, cuyos tamaos han sido
aadidos para el tamao total grabado
o) Para cada alcance dentro del alcance global de la medida, una matriz de medida,
como se especifica en el apndice A
p) El nombre del medidor y cualquier certificado de cualificacin de COSMIC


,,
A Ap p n nd di ic ce e A A
APNDICE A DOCUMENTANDO LA MEDICIN 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 REPRESENTACIN
Cada grupo de datos identificados se registra en una columna.
Cada proceso funcional es registrado en una lnea especfica, agrupados por componente
identificado.
FASE DE MEDICIN
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 medicin puede ser calculado y registrado en los recuadros de cada
componente, en la lnea de TOTAL.

,-
A Ap p n nd di ic ce e B B
APNDICE B RESUMEN DE LOS PRINCIPIOS DEL MTODO COSMIC
La siguiente tabla identifica los principios del mtodo COSMIC de medicin con el propsito de una
referencia precisa.
ID DESCRIPCIN PRINCIPAL
P-01 El modelo contextual de Software de COSMIC
a) El hardware es la frontera del software.
b) El software, tpicamente, se estructura en capas.
c) Una capa puede contener una o ms 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 aplicacin de
medicin, que debe estar enteramente contenido en una sola capa.
e) El alcance de una parte de programa a medir depende del propsito de la medicin.
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 interacta con sus usuarios funcionales a travs 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 debera 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 aproximacin y
escalado al nivel de granularidad del proceso funcional.
P-02 El Modelo Genrico 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 manipulacin 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 inters.
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

,.
tambin otro de Escritura o Salida, esto es, al menos dos movimientos de datos.
j) Como una aproximacin a efectos de medicin, los sub-procesos de manipulacin de
datos o se miden por separado; la funcionalidad de cualquier manipulacin 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 tamao funcional de una parte de software es directamente proporcional al nmero 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 jerrquica entre capas es tal que el software en una capa puede usar
los servicios funcionales de cualquier software en una capa jerrquicamente 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 confa en los servicios del software en dichas capas
subordinadas para funcionar correctamente; la subordinada confa a su vez en el de
sus capas inferiores para funcionar correctamente, y as sucesivamente hacia abajo en
la jerarqua. 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 jerarqua.
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 tambin una o ms atributos
o subgrupos de datos definidos en comn 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 recepcin 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 jerarqua 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 estn en el mismo nivel en la jerarqua 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 travs 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 travs 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 Genrico de Software COSMIC
El Modelo Genrico 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 medicin diferente.
Aplicando el Modelo Genrico de Software COSMIC significa identificar el conjunto de
sucesos de activacin detectados para cada uno de los usuarios funcionales (tipos),
identificados en el FUR, y despus identificar los correspondientes procesos funcionales,

,!
objetos de inters, 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 travs de su coleccin
nica de atributos de datos.
b) Cada grupo de datos debe estar directamente relacionado con un objeto de inters 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
inters desde un usuario funcional a travs del entorno a un proceso funcional del que
esta Entrada forme parte. Si la entrada de un proceso funcional comprende ms de un
grupo de datos, identificar una Entrada para cada grupo de datos nicos (ver tambin
seccin 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 ms
tarde no necesite que se le diga que datos enviar o el usuario funcional es incapaz de
reaccionar a ningn mensaje entrante, identificar una Entrada al proceso funcional
para obtener los datos. Cualquier mensaje del proceso funcional al usuario funcional
buscando recuperar los datos no debe ser contado como una Salida en estos casos.
Sin embargo, cuando un proceso funcional deba obtener algn dato de un usuario
funcional y el proceso funcional deba decirle al usuario funcional con datos que
despus requieran rellenar la peticin, contar una Salida para la peticin y una Entrada
para la devolucin de los datos pedidos (para ms informacin ver seccin 4.1.9).
P-09 Salida (X)
a) Una Salida debe mover un nico grupo de datos que describa un nico objeto de
inters del proceso funcional del que la salida forma parte, a travs de la frontera,
hacia un usuario funcional. Si la Salida de un proceso funcional comprende ms de un
grupo de datos, identificar una Salida para cada grupo nico de datos (ver tambin
seccin 4.1.7).
b) Una Salida no introduce datos a travs 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
inters de un almacenamiento permanente a un proceso funcional del cual forma parte
la lectura. Si los procesos funcionales deben recuperar ms de un grupo de datos del
almacenamiento permanente, identificar una Lectura por cada grupo de datos nico
que es recuperado (ver tambin la seccin 4.1.7 Movimiento de datos nicos).
b) Una Lectura no debe recibir ni enviar datos a travs de la frontera, ni escribir datos.
c) Durante un proceso funcional, el movimiento o manipulacin de constantes o variables
que son internas al proceso funcional y que pueden ser cambiadas solo por un
programador, o un cmputo de resultados intermedios de un clculo, o datos
almacenados por un proceso funcional que resultan slo de la implementacin, en
lugar de del FUR, no deben ser considerados como movimientos de Lectura.
d) Un movimiento de Lectura siempre incluye alguna funcionalidad de peticin de
Lectura (as que no se debe contar nunca un movimiento separado de datos para
ninguna peticin del Lectura). Vase tambin seccin 4.1.9.
P-11 Escritura (W)
a) Una Escritura debe mover un nico grupo de datos que describa un nico objeto de

-0
inters del proceso funcional del que la Escritura forma parte al almacenamiento
permanente. Si el proceso funcional debe mover ms de un grupo de datos al
almacenamiento permanente, identificar una escritura para cada nico grupo de datos
que se mueva al almacenamiento permanente (ver tambin seccin 4.1.7).
b) Una Escritura no debe recibir ni enviar datos a travs 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 manipulacin de los datos que no
continan cuando el proceso funcional es completado, o la actualizacin de variables
las cuales son internas al proceso funcional, o resultados producidos por un clculo
intermedio no deben ser considerados como una Escritura.
P-12 Manipulacin de datos asociada con movimiento de datos
Toda manipulacin 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 manipulacin de datos del proceso
funcional.


-1
A Ap p n nd di ic ce e C C
APNCIDE C RESUMEN DE LAS REGLAS DEL METODO COSMIC
Con el propsito de ser unas referencias precisas, la siguiente tabla identifica cada regla del mtodo
COSMIC
ID DESCRIPCIN DE LA REGLA
R-01 Alcance
a) El alcance de una Medicin del Tamao Funcional (FSM), debe ser derivada de los
propsitos de la medicin.
b) El alcance no debe extenderse sobre ms de una capa del software a medir.
R-02 Capa
a) Si el software se concibe usando una arquitectura establecida en capas segn el
modelo COSMIC, entonces dicha arquitectura se debe utilizar para identificar las
capas a efectos de medicin.
b) En el dominio de MIS o software de gestin, la capa superior (por ejemplo, la capa que
no est subordinada a ninguna otra capa), est normalmente referenciada como la
capa de aplicacin. El software en esta capa confa 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
consideracin de diseo 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
propsito de la medicin.
b) Cuando el propsito de una medicin 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 interactan con el software que est
siendo medido. La frontera se encuentra entre los usuarios funcionales y el software.
b) Por definicin 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 tamao funcional debe hacerse en el nivel de granularidad de los
procesos funcionales.
b) Cuando la medicin de un proceso funcional necesita de algn FUR que no haya
evolucionado an 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 mtodos de medicin aproximada, como por ejemplo estimar
un tamao 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 activacin
identificable.
c) Un suceso especfico puede activar uno o ms procesos funcionales que se ejecuten
en paralelo. Un proceso funcional especfico puede ser activado por ms de un
suceso.
d) Un proceso funcional abarcar al menos dos movimientos de datos, una Entrada ms
una Salida o una Escritura.
e) Un proceso funcional debe pertenecer enteramente al alcance de medicin de una
parte del software en una y slo 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 activacin de un evento y
espera hasta que recibe la prxima 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 mximo nmero 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 travs 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 despus confirmar la aceptacin 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 slo un
atributo de datos que simplemente informa al software de que un evento Y ha
sucedido. Muy a menudo, especialmente en aplicaciones de gestin este tipo de
entradas tienen varios atributos de datos que informan al programa de que un evento
Y ha sucedido, y aqu estn 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. Ntese que
no hay diferencia si el evento es generado peridicamente por hardware o por otro
programa externo a la frontera del software que se est midiendo.
c) Salvo que un proceso funcional especfico sea necesario, obtener el tiempo del reloj
del sistema no debe considerarse que causa una Entrada.
d) Si una ocurrencia de un evento especfico dispara la Entrada de un grupo de datos
que comprende n atributos de datos de un objeto de inters en particular y el FUR
permite que otras ocurrencias del mismo evento puedan activar una Entrada de un

-3
grupo de datos que contiene valores de atributos para slo un subconjunto de los n
atributos del objeto de inters entonces slo 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 interaccin del
usuario (por ejemplo, mensajes de error), deben ser considerados como valores de un
atributo de un objeto de inters (los cuales pueden ser llamados indicacin 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 inters 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 slo un subconjunto de n atributos de un objeto de inters, 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 inters que es requerido para ser
incorporado en un proceso funcional, y la manipulacin de datos asociada debe ser
identificada y contada como una nica Entrada.
(Nota: Un proceso funcional puede, por supuesto, ser requerido para mltiples
procesos de Entrada, cada una moviendo un grupo de datos describiendo un objeto
de inters diferente).
La misma regla se aplica a cualquier movimiento de datos de Lectura, Escritura o
Salida en cualquier proceso funcional).
b) Ms de un movimiento de Entrada de datos, cada uno moviendo un grupo de datos
que describe el mismo objeto de inters en un proceso funcional dado, puede ser
identificado y contado si hay un Requisito Funcional de Usuario de estas Entradas
mltiples. Similarmente, ms 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 mltiples.
Ese FUR puede presentarse cuando, en un proceso funcional, las mltiples entradas
originadas desde diferentes usuarios funcionales introducen diferentes grupos de
datos (cada uno describiendo el mismo objeto de inters).
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 manipulacin de datos), no debe ser identificada
y contada ms de una vez en ningn proceso funcional.
d) Incluso si las mltiples ocurrencias de un tipo de movimiento de datos en un proceso
funcional dado difieren en la manipulacin 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 ms 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 enva una Entrada que acciona el inicio del proceso
funcional;
cuando un proceso funcional, habiendo recibido una Entrada de activacin,
espera, la llegada de otra Entrada adicional desde el usuario funcional, (puede

-*
ocurrir cuando una persona introduce datos a la aplicacin software);
cuando un proceso funcional habiendo empezado, pide al usuario funcional
envame tus datos ahora, si tienes algo que enviar, y el usuario funcional enva
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 tpicamente 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. Slo 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 (tpicamente 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 peticin de los datos
especficos; la Entrada contiene los datos devueltos.
R-11 Comandos de control en el dominio de las aplicaciones de gestin
En el dominio de una aplicacin de gestin los comandos de control sern ignorados
pues no implican ningn movimiento de datos sobre un objeto de inters.
R-12 Agregacin de los resultados de la medicin
a) Para cualquier proceso funcional, los tamaos funcionales de los movimientos de
datos individuales sern agregados en un solo valor de tamao funcional en unidades
CFP, sumndolas aritmticamente.
Tamao (proceso funcional
i
) = tamao(Entradas
i
)
i
+ tamao(Salidas
i
) +
tamao(Lecturas
i
) + tamao (Escrituras
i
)
b) Para cualquier proceso funcional, el tamao funcional de los cambios de sus
Requisitos Funcionales de Usuario sern agregados desde los tamaos de los
movimientos de datos que han sido aadidos, modificados o borrados en el proceso
funcional para dar un tamao del cambio en unidades CFP, de acuerdo a la siguiente
frmula.
Tamao (Cambios(proceso funcional
i
)) =
tamao (movimiento de datos
i
aadido) +
i
modificado) +
i
eliminados)
Para ms informacin sobre la agregacin del tamao funcional ver seccin 4.3.2.
Para la medicin del tamao de los cambios del software, ver seccin 4.4.
c) El tamao de cualquier cambio de una parte del software dentro del alcance definido
ser obtenido por la agregacin de los tamaos de los procesos funcionales de cada
parte, sujeto a las reglas e) y f) de abajo.
d) El tamao de cualquier cambio de una parte del software dentro del alcance definido
ser obtenido sumando los tamaos de todos los cambios de todos los procesos
funcionales de cada parte, sujeto a las reglas e) y f) de ms abajo.
e) Los tamaos de las partes del software o de los cambios de las partes del software
dentro de las capas pueden ser sumado slo si se miden en el mismo nivel de
granularidad del proceso funcional de su FUR.
f) Adems, los tamaos de las partes del software y/o los cambios de los tamaos de
una parte del software dentro de una capa o de diferentes capas sern sumados slo
si tiene sentido hacerlo as, segn el propsito de la medicin.
g) El tamao de una parte del software no puede ser obtenido sumando los tamao de

-+
sus componentes (sin importar cmo se subdivide), a menos que las contribuciones
del tamao de los movimientos de datos entre componentes se eliminen.
h) Si el mtodo COSMIC se extiende localmente (por ejemplo para medir algunos
aspectos de tamao no cubierto por el mtodo estndar), entonces el tamao medido
por la extensin local debe documentarse separadamente como se describe en la
seccin 5.1 y no debe aadirse al tamao obtenido por el mtodo estndar, medido en
CFP (ver en la seccin 4.5).
R-13 Modificacin de un movimiento de datos
a) Si un movimiento de datos debe ser modificado debido a un cambio en la
manipulacin de los datos asociada al movimiento de datos y/o debido a un cambio en
el nmero o tipo de atributos en el grupo de datos movidos, un CFP cambiado ser
medido, sin importar el nmero 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 modificacin
al grupo de los datos no ser identificado como movimientos de datos cambiados.
NOTA 1: Una modificacin a un valor de una ocurrencia de un atributo, tal como una
modificacin en un cdigo de un atributo cuyo valor venga dado por un sistema de
codificacin no es una modificacin del tipo del atributo.
NOTA 2: Una modificacin a cualquier dato que aparece en pantallas de entrada o salida
que no estn relacionadas con un objeto de inters para un usuario funcional no debe
identificarse como un CFP cambiado (ver la seccin 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 numrico del tamao funcional,
v.y representa la versin estndar del mtodo COSMIC usado para la obtencin del
valor del tamao funcional x.
NOTA: Si se ha usado un mtodo de aproximacin local para obtener la medida, pero
adems la medida se hizo usando las convenciones de una versin estndar de
COSMIC, el etiquetado anterior debe ser usado, pero el uso de ese mtodo de
aproximacin debera ser anotada de alguna manera ver seccin 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 numrico obtenido sumando todos los resultados de la medicin
del mtodo estndar COSMIC, versin v.y,
v.y representa la versin del mtodo estndar COSMIC usado para obtener el valor
del tamao funcional x,
z representa el valor numrico obtenido sumando todos los resultados individuales
obtenidos de las extensiones locales del mtodo COSMIC.
R-16
Informes de medida COSMIC
Adems de las medidas reales, deberan ser registrados los siguientes atributos de cada
medicin.
a) Identificacin del componente software medido (nombre, identificacin de la versin o
identificacin de la configuracin).
b) Las fuentes de informacin empleadas para la identificacin de los FUR en la
medicin.
c) El dominio del software.

-,
d) Una declaracin del propsito de la medicin.
e) Una descripcin del alcance de la medicin, y su relacin con el alcance global de un
conjunto relacionado de medidas, si las hubiere (usar las categoras de alcance
genricas de la seccin 2.2).
f) Los usuarios funcionales del software.
g) El nivel de granularidad de los FUR y el nivel de descomposicin del software.
h) El punto del ciclo de vida del proyecto en que la medida fue hecha (especialmente si la
medida es una estimacin basada en FUR incompletos, o fue hecha en base a una
funcionalidad entregada realmente).
i) El objetivo o margen de error supuesto en la medicin.
j) Indicaciones de si se ha usado la medicin estndar del mtodo COSMIC, y/o una
aproximacin local para el mtodo estndar, y/o cualquier extensin local (ver seccin
4.5). Usar las convenciones de etiquetado de las secciones 5.1 o 5.2.
k) Una indicacin de si la medida es de funcionalidad desarrollada o entregada (la
funcionalidad desarrollada se obtiene creando software nuevo; la entregada incluye la
desarrollada y tambin la obtenida por cualquier otro medio que no sea la creacin de
nuevo software como por ejemplo todas las formas de reutilizacin de software
existente, el uso de parmetro preexistentes para aadir o cambiar funcionalidad,
etc.).
l) Una indicacin de si la medicin es de una nueva funcionalidad suministrada o es el
resultado de una actividad de mejora (por ejemplo la suma de una funcionalidad
aadida, cambiada y borrada - ver 4.4).
m) Si fuera aplicable, una descripcin de la arquitectura de las capas en la cuales la
medicin fue realizada.
n) Si fuera aplicable, el nmero de componentes principales, cuyos tamaos se han
sumado para el tamao total registrado.
o) Para cada alcance dentro del alcance de medicin global, una matriz, segn lo
especificado en el apndice A.
p) El nombre de la persona que hace la medicin y las acreditaciones de calidad
COSMIC.


--
A Ap p n nd di ic ce e D D
APNDICE D HISTORIA DEL MTODO COSMIC
Este apndice contiene un resumen de los principales cambios desde la versin 2.2 a travs de la
versin 3.0 a la versin 3.0.1. del mtodo COSMIC de medicin del tamao funcional. La versin 2.2
del mtodo fue descrita en el Manual de Medicin v2.2 (abreviado como MM), pero desde la versin
3.0 en adelante la documentacin del mtodo est distribuida en cuatro documentos, slo uno de los
cuales es el Manual de Medicin.
El propsito del apndice 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 justificacin. (Para los cambios realizados en la obtencin de la versin 2.2 desde la versin 2.1,
consulte la versin 2.2 del Manual de medicin, Apndice E)
De la versin 2.2 a la versin 3.0
En la tabla siguiente se ensea los principales cambios hechos desde la versin 2.2 a la versin 3.0,
se hace referencia a los dos boletines de la actualizacin del mtodo (MUB). Un MUB es publicado
por COSMIC para proponer mejoras al mtodo entre cambios importantes de versin. Los dos MUB
son:
MUB 1 Mejoras propuestas para las definiciones y caractersticas de una capa de software,
publicado in Mayo de 2003.
MUB 2 Mejoras propuestas para la definicin de un objeto de inters , publicado en Marzo de
2005.
En el proceso de actualizacin del mtodo de la versin 2.2 a la versin 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 redaccin no se han descrito en la siguiente tabla.

V2.2 Ref V3.3 Ref Cambios
Reestructuracin del Mtodo COSMIC
2.2, 2.7,
3.1, 3.2
1.5,
Captulo
2
Una fase de la Estrategia de Medicin ha sido separada como la
primera fase, de lo que ahora es un mtodo en tres fases.
La fase de la Estrategia de Medicin ahora incluye consideraciones
sobre capas, fronteras, y usuarios (funcionales), los cuales se
consideran parte de la fase de representacin en el MM v2.2.
Reestructuracin del Manual de Medicin

En la produccin de la v3.0 del Mtodo 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 (Captulos 1 y 2 del MM
v2.2)
COSMIC Method v3.0: Measurement Manual (Captulos 3, 4 y 5 y
los apndices del MM v2.2
COSMIC Method v3.0: Advanced and Related Topics (Captulos 6
y 7 del MM v2.2)

-.
Las referencias al pasado y los trabajos de investigacin se han quitado
del MM. stos estn 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 pgina.
Captulo
4
Captulo
4
El captulo sobre la fase de medicin se ha reestructurado
considerablemente para ofrecer una exposicin ms lgica.
Apndice
D
-- Este apndice sobre Ms informacin de las capas del software ha
sido eliminado, por ser incompatible con MUB 1 y aadir poco valor.
Vanse tambin las notas a continuacin sobre los cambios teniendo
en cuenta MUB 1.
Cambios en la terminologa de los nombres
General El nombre COSMIC-FFP del mtodo ha sido simplificado por mtodo COSMIC.
5.1 4.2 El nombre de la unidad de medicin, unidad de tamao funcional
COSMIC (abreviado como Cfsu) ha sido cambiado a Punto de
Funcin COSMIC (abreviado como CFP). Ver el Prlogo del MM v3.0
para la explicacin 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 abstraccin, punto de vista, Punto de vista de
Medicin, la Medicin del Punto de vista del Usuario final y Punto de
vista del desarrollador de la Medicin han sido eliminados. Se han
remplazado por un concepto ms general de que el tamao funcional
de una parte del software a medir depende de la funcionalidad que se
pondr a disposicin del usuario o usuarios funcionales del software.
Estos deben ser identificables en los Requisitos Funcionales de
Usuario del software a medir. La definicin de usuario o usuarios
funcionales es por tanto un requisito previo para la definicin de qu
tamao debe ser medido o para la interpretacin de un tamao de
medicin existente. Ver el Prlogo del MM v3.0 para ms detalles de la
explicacin 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 ms restrictivo.
Ver el Prlogo del MM v3.0 para ms detalles de la explicacin de este
cambio.
En 2.3.2, han sido introducidos dos ejemplos de dnde el tamao
funcional vara con el tipo de usuario funcional identificado en el FUR,
para un telfono mvil y para un paquete de una aplicacin de gestin.
-- 2.2.2 El nivel de descomposicin del software a medir ha sido introducido en
la discusin del alcance de la medicin.
-- 2.4 El nivel de granularidad de los requisitos funcionales de usuario del
software a medir ha sido introducido en la discusin de la estrategia de
la medicin. Se da un ejemplo para la comprensin. Ver el Prlogo del

-!
MM v3.0 para ms detalles de la explicacin 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
almacn permanente.
4.1 -- El concepto de des duplicacin ha sido eliminado como resultado de
ser innecesario.
Mejores definiciones y perfeccionamiento de los principios y reglas
2.3 2.2 La definicin de Requisitos Funcionales de Usuario ha sido cambiada
conforme a la edicin 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 declaracin de principios.
2.4.2 1.4 El Modelo Genrico del Software ha sido extendido y refinado como
una declaracin de principios.
2.4, 3.1 2.2.3,
2.2.4,
3.1
La definicin de capa ha sido modificada teniendo en cuenta MUB 1.
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 interaccin de los usuarios con el software en capas
fueron sustituidas en la v3.0 por las Figuras 2.2.3.1 y 2.2.3.2 ilustrando
una tpica arquitectura fsica con capas y las Figuras 3.1.1 y 3.1.2
ilustrando la interaccin lgica de los usuarios funcionales con el
software en capas. El objetivo de este cambio es distinguir ms
claramente la visin fsica de los programas tpicos de las arquitecturas
de capas de la visin lgica de una interaccin 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 Caractersticas del proceso de medicin 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 medicin ha sido tratada en parte en la seccin 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 aadida para la definicin 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 tamao de medida individual.
3.2 4.1.8 Los tres ejemplos que ilustran la interaccin de los usuarios a travs de
una frontera con el software en diferentes capas y desde diferentes
puntos de vista de medicin han sido movidos y reescritos con la
intencin de eliminar los puntos de vista de la medicin. Vase el

.0
punto 4.1.8 (del MM v3.0), ms abajo.
-- 3.1 Se ha aadido un principio relativo al Modelo Genrico de la aplicacin
del software a medir.
3.3 3.2.1 La definicin de proceso funcional se ha perfeccionado para tener en
cuenta la introduccin del concepto de usuario funcional, que sustituye
a la de 'actor' en la definicin.
3.3 3.2.1 La definicin de evento que activa ha sido perfeccionada.
-- 3.2.1 La relacin entre un evento que activa, un usuario funcional, la
activacin 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,
3.2.4,
3.2.5
Se han introducido algunos ejemplos de procesos funcionales y de
cmo distinguirlos.
-- 3.3.1 Se ha introducido la definicin de un objeto de inters, en lnea a MUB
2.
3.4 3.3.3 Los ejemplos de la identificacin de los objetos de inters y los grupos
de datos se han separado de las normas para los grupos de datos.
Material especfico de los convenios de anlisis de datos de entidad-
relacin han sido trasladados a la Guideline for sizing Business
Application Software v1.0.
-- 3.3.4 Se ha dado una gua para los datos o grupos de datos que no son
candidatos a movimientos de datos.
-- 3.3.5 Se dan orientaciones sobre cundo, generalmente en software en
tiempo real, puede que no valga la pena distinguir un usuario funcional
de 'un objeto de inters sobre qu datos son movidos.
3.5 3.4 La discusin de los atributos de datos se ha reducido y simplificado
desde que la consideracin de los atributos de datos no es una parte
obligatoria del mtodo.
4.1 4.1.1 Se ha racionalizado la definicin de un movimiento de datos.
4.1 4.1.7 Las reglas sobre des duplicacin de movimientos de datos (ahora
llamadas como normas de unicidad de movimiento de datos y posibles
excepciones) han sido mucho ms claras con varios ejemplos
aadidos.
4.1 -- Reglas especficas 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 travs de la frontera
(las cuales en el MM v2.2 se aplicaron a Los puntos de vista del

.1
desarrollador de la medicin, los cuales han sido eliminados), han sido
borradas pero los conceptos se han combinado con los Casos dados
previamente en la seccin 3.2 del MM v2.2, para hacer una nueva
seccin sobre cundo los procesos funcionales mueven datos hacia o
desde un almacenamiento permanente.
4.1 4.1.6 Se ha definido la Manipulacin de Datos y se ha aadido un principio
sobre la manipulacin de datos asociada con los movimientos de
datos. Se ha ampliado la gua sobre la manipulacin 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
aadido un nuevo principio relativo a la funcionalidad de la peticin de
entrada.
4.1.2 4.1.3 Se han racionalizado los principios y reglas de una Salida incluyendo la
eliminacin 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 aadido un
nuevo principio concerniente a la funcionalidad de la peticin de
lectura.
4.1.4 4.1.5 Se han racionalizado los principios de una Escritura.
-- 4.1.9 Se han aadido nuevas reglas sobre cundo un proceso funcional
requiere datos de un usuario funcional.
-- 4.1.10 Se ha introducido una definicin y una regla para el concepto de
comando de control los cuales son slo vlidos en el dominio de las
aplicaciones de gestin.
4.1.5 4.5 Se ha ampliado la discusin sobre las extensiones locales del mtodo.
4.3 4.3 Se han cambiado los principios de agregacin de los resultados de la
medicin por reglas y se ha ampliado para cubrir las normas sobre la
obtencin del tamao de una parte de software mediante la suma de
los tamaos de sus componentes. El MM v2.2 se refiere slo a esas
reglas en el concepto de los puntos de vista de desarrollador de la
medicin. Esta restriccin se ha eliminado.
-- 4.4 Se ha aadido una nueva seccin con nuevas reglas sobre la medicin
del tamao de los cambios en el software.
5.1 5.1 Las reglas del etiquetado de los resultados de la medicin 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 ms artculos se han ampliado las reglas sobre la
presentacin de informes de la medida.
Apndice B Apndice
B
Actualizados a los principios de la v3.0
Apndice C Apndice
C
Actualizados a las Reglas de la v3.0

.

De la versin 3.0 a la versin 3.0.1
El cambio ms importante se encuentra de la versin 3.0 a la 3.0.1 en la mejora de la redaccin de
algunas definiciones, principios y normas, y algunas partes del texto. Con la excepcin de un error,
las mejoras han sido realizadas por razones de claridad. La mayora de los cambios se han publicado
en tres Boletines de Actualizacin del Mtodo anteriores a la versin 3.0.1.
MUB 3: Correccin de un error en la Figura 4.1.8.1 (b) del Manual de Medicin del Mtodo
COSMIC v3.0, publicado en Junio de 2008.
MUB 4: Aclaracin de los principios y reglas de la funcionalidad de Peticin de entrada en el
Manual de Medicin del Mtodo COSMIC v3.0, publicado en Junio de 2008.
MUB 5: Mejoras propuestas para (a) Definiciones del Nivel de Descomposicin y de
Componentes Semejantes, y (b) Principio c) para un Componente Semejante, publicado en
Febrero de 2009.
Adems, se han hecho varias mejoras en la redaccin. Principalmente mediante una separacin ms
clara de los ejemplos en el texto principal, utilizando un tipo diferente de fuente y la introduccin de
ms secciones.
Resumen de los cambios principales:
V 3.0.1 Cambio
2.2.3 Para mayor claridad se ha cambiado la definicin del Nivel de Descomposicin (MUB
5).
2.2.4 En la definicin de Capa, el trmino arquitectura del software se ha sustituido por el
de sistema software, ya que el trmino arquitectura implica que el software ya est
dividido.
Regla c) eliminada. Esta fue una regla general de diseo de software y no especfica
para las capas y a la medicin. La referencia al Apndice D en la versin 3.0 era
incorrecta.
2.2.5 Para mayor claridad se insert la definicin de Semejante y se cambi la definicin de
Componente Semejante. El principio c) para el Componente Semejante cambi a un
principio que es ms importante para FSM.
La Figura 2.2.5.1 se aade para aclarar la relacin entre los componentes semejantes y
las partes
semejantes del software (MUB 5).
2.3.2 La regla c) de los lmites 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, mtodo de
pago se ha cambiado por medios de pago, ya que ste es un trmino mejor para, por
ejemplo, cheque, tarjeta de crdito, etc.
3.2.2 La regla e) para un proceso funcional se ha visto limitada por la adicin de las palabras
en cursiva. Ahora es: Un proceso funcional se corresponde totalmente al alcance de la
medicin de slo una parte de una aplicacin de software, y slo a una capa. Esta
limitacin existe en la directriz para el dimensionamiento de Aplicaciones de Negocios
Software' v1.1, pero es vlida para el software de cualquier dominio.
3.2.6 Nueva seccin aadida titulada Procesos funcionales de componentes semejantes.
Este texto est tomado en gran parte del documento Guideline for Sizing Business

.3
Application Software v1.1, pero es vlida 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 cmo darse
cuenta de una Peticin de entrada (MUB 4).
4.1.7 Para mayor claridad del significado deseado, ha sido cambiada la frase inicial de la
seccin sobre Unicidad de Datos y Posibles Excepciones de la regla a). El ejemplo 2
tambin ha sido ampliamente modificado para mayor claridad.
4.1.8 La Figura 4.1.8.1 (b) ha cambiado para corregir un error sobre cmo un controlador de
dispositivo interacta con el hardware (MUB 3).
4.1.9 Para mayor claridad se han cambiado las reglas sobre Cundo un proceso funcional
requiere datos de un usuario funcional, y los ejemplos relacionados (MUB 4).

.*
A Ap p n nd di ic ce e E E
APNDICE E PROCEDIMIENTO DE SOLICITUD DE CAMBIOS Y
COMENTARIOS
El Comit de Prcticas de Medicin COSMIC (MPC) est ansioso de recibir opiniones, comentarios y
si es necesario, Solicitudes de Cambio para el Manual de Medicin COSMIC. Este apndice precisa
cmo comunicarse con el COSMIC MPC.
Todas las comunicaciones con el COSMIC MPC deben ser enviadas por e-mail a la siguiente
direccin:
mpc-chair@cosmicon.com
Opiniones y Comentarios Generales de manera Informal
Los comentarios y/u opiniones concernientes al Manual de Medicin, tales como las dificultades de
comprensin o la aplicacin del mtodo COSMIC, sugerencias para la mejora general, etc. se deben
enviar por e-mail a la direccin antes mencionada. Los mensajes se registran y, en general, sern
revisados en un plazo mximo de dos semanas desde la recepcin. El MPC no puede garantizar
ninguna accin en respuesta a estos comentarios generales.
Solicitud de los cambios de manera formal
Podrn ser presentadas una solicitud formal de cambio (CR), cuando el lector del manual de
medicin crea que hay un error en el texto, por la necesidad de aclaraciones, o algunas necesidades
de mejora de texto.
Las CRs formales sern tomadas en dos semanas desde la recepcin. Cada CR recibir entonces un
nmero de serie y ser reenviada a los miembros del COSMIC MPC, un grupo mundial de expertos
en el mtodo COSMIC. Su ciclo normal de revisin lleva al menos un mes y puede ser ms si el CR
es difcil de resolver.
Como resultado de la revisin el CR puede ser aceptado, rechazado o dejado en espera para un
discusin ms 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 peticin formal de cambio slo se aceptar si se documenta con toda la informacin siguiente:
Nombre, cargo y organizacin de la persona que presenta la solicitud de cambio.
Datos de contacto de la persona que presenta la solicitud de cambio.
Fecha de presentacin.
Declaracin general de los efectos de la peticin 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 sustitucin propuesta.
Explicacin completa de por qu el cambio es necesario.
En el sitio www.cosmicon.com est disponible un formulario para la presentacin de una peticin de
cambio.
Finalmente, la decisin resultante por el MPC COSMIC de una peticin de cambio y, si se acepta, se
aplicar en la versin del Manual de Medicin de la peticin de cambio.

.+
Preguntas sobre la aplicacin del mtodo COSMIC.
El MPC COSMIC lamenta el no ser capaz de responder a preguntas relacionadas con el uso o
aplicacin del mtodo COSMIC. Existen organizaciones comerciales que pueden proporcionar la
formacin y la consultora o apoyo para la aplicacin del mtodo. Por favor, consulte la web
www.cosmicon.com para ms detalles.

Spanish - COSMIC - v3-0-1 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Spanish - COSMIC - v3-0-1 PDF

Transféré par

Droits d'auteur :

Formats disponibles

E El l M M t to od do o C CO OS SM MI IC C d de el l T Ta am ma a o o F Fu un nc ci io on na al l d de el l S So of ft tw wa ar re e

Vous aimerez peut-être aussi