manual de medición - cosmic sizing v3-0-1.pdf · el método cosmic del tamaño funcional del...

EEll MMééttooddoo CCOOSSMMIICC ddeell TTaammaaññoo FFuunncciioonnaall ddeell SSooff ttwwaarree

VVeerrssiióónn 33..00..11

MMaannuuaall ddee MMeeddiicc iióónn

(Guía COSMIC de implementación de ISO/IEC 19761: 20 03)

Mayo de 2009

Manual de Medición, Método COSMIC Versión 3.0.1. Copyright © 2009. All rights reserved. The Common Software Measurement International Consortium (COSMIC)

2

AAggrraaddeecciimmiieennttooss

Equipo Principal de Autores de la Versión 2.0 1 de COSMIC (por orden alfabético)

Alain Abran, École de technologie supérieure – Universidad de Québec, Jean-Marc Desharnais, Software Engineering Laboratory in Applied Metrics - SELAM, Serge Oligny, Bell Canadá, Denis St-Pierre, DSA Consulting Inc., Charles Symons, Software Measurement Services Ltd.

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

Moritsugu Araki, JECS Systems Research, Japan

Thomas Fetcke, Germany Patrice Nolin, Hydro Québec, Canada

Fred Bootsma, Nortel, Canada Eric Foltin, University of Magdeburg, Germany

Marie O’Neill, Software Management Methods, Ireland

Denis Bourdeau, Bell Canada, Canada

Anna Franco, CRSSM, Canada Jolijn Onvlee, The Netherlands *

Pierre Bourque, , ÉCole de Technologie supérieure, Canada

Paul Goodman, Software Measurement Services,United Kingdom

Laura Primera, UQAM, Canada

Gunter Guerhen, Bürhen & Partner, Germany

Nihal Kececi, University of Maryland, United States

Paul Radford, Charismatek, Australia

Sylvain Clermont, Hydro Québec, Canada

Robyn Lawrie, Australia Eberhard Rudolph, Germany

David Déry, CGI, Canada Ghislain Lévesque, UQAM, Canada Grant Rule, Software Measurement Services, United Kingdom*

Gilles Desoblins, France Roberto Meli, Data Processing Organization, Italy

Richard Stutzke, Science Applications Int’l Corporation, United States

Martin D’Souza, 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 versión 2.0 fue la primera versión públicamente disponible del método COSMIC-FFP, tal como fue conocida


3

Revisores de la Versión 3.0 2006/07 (por orden alfa bético)

Alain Abran, École de Technologie Supérieure, Université du Québec, 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 O’Neill, 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 método COSMIC

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

Juan J. Cuadrado-Gallego, EVALÚA Software Measurement Consulting, Spain. [email protected]

Cristina Albarrán, EVALÚA Software Measurement Consulting, Spain

Alfonso Gónzalez, EVALÚA Software Measurement Consulting, Spain

Ivan Pinedo, EVALÚA Software Measurement Consulting, Spain

Isaac Sánchez, EVALÚA Software Measurement Consulting, Spain

Roi Vázquez, EVALÚA Software Measurement Consulting, Spain.

La traducción de la Versión 3.0.1 de COSMIC ha sido realizada bajo los auspicios de AEMES, Spanish Software Measurement Association

Copyright 2009. Todos los derechos quedan reservados. El Común Consorcio Internacional de la Medida del Software, (COSMIC). El permiso para copiar todo o una parte de este material se concederá siempre que las copias no se hagan ni se distribuyan comercialmente y que el título de la publicación, su número de versión, y su fecha se citen y se notifique que la copia tiene el permiso del Common Software Measurement International Consortium (COSMIC). Para la copia de otra manera se requiere un permiso específico.

Una versión de dominio público del Manual de Medición COSMIC y otros informes técnicos, incluyendo traducciones a otros idiomas se pueden encontrar en la Web en www.gelog.etsmtl.ca/cosmic-ffp


4

CCoonnttrrooll ddee vveerrssiioonneess

La tabla siguiente muestra la historia de las versiones de este documento

FECHA REVISORES Modificaciones / Añadidos

31-03-99 Serge Oligny Primer borrador, emitió los comentarios de los revisores

31-07-99 Véase Agradecimientos Revisado, incluyendo comentarios de los revisores

06-10-99 Véase Agradecimientos Revisado, incluyendo comentarios del IWSM ’99 workshop2

29-10-99 Equipo Principal de COSMIC

Revisado, comentarios finales antes de la publicación del “ensayo práctico” de la versión 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 medición de la versión 2.1.

31-01-03 Comité de Prácticas de Medición COSMIC

Revisado conforme a la norma ISO/IEC FDIS 19761: 2002 + las aclaraciones sobre las normas de medición de la versión 2.2


Revisado para más aclaraciones y añadidos de las normas de medición de la versión 3.0, particularmente en el área de la fase de la estrategia de medición. El nombre del método fue cambiado de ‘método COSMIC-FFP’ al de ‘método COSMIC’. En la actualización a la v3.0 de la v2.2, se separaron partes del ‘Manual de Medición’ v2.2 en otros documentos – véase el prólogo a continuación y el Apéndice D


Revisada la versión 3.0 a v3.0.1 para hacer mejoras en la redacción y aclaraciones menores, y para distinguir ejemplos más claramente. Esta versión también incorpora los cambios propuestos en los Boletines de Actualización del Método (MUB), 3, 4 y 5. Véase el Apéndice D para obtener más detalles sobre estos cambios.

2

Procedimientos del Taller Internacional de la Medición del Software IWSM ’99, Lac Supérieur, Québec, Canadá, 8-10 de Septiembre de 1999. Véase para más detalle http://www.gelog.etsmtl.ca/iwsm99/index2.html.


5

PPrróóllooggoo

El propósito del método COSMIC es proporcionar un método estandarizado de medición del tamaño funcional de software para los dominios funcionales comúnmente denominados como Software de Aplicaciones de Negocio (ó Management Information Systems, MIS) y Software de Tiempo Real.

El método COSMIC fue aceptado por el ISO/IEC JTC1 SC7 en diciembre de 2002 como el Estándar Internacional ISO/IEC 19761 “Ingeniería del Software - COSMIC-FFP - Método de Medición de Tamaño Funcional” (en lo sucesivo en este documento se referirá el mismo como ISO/IEC 19761).

Para mayor claridad, ISO/IEC 19761 contiene las definiciones de las normativas fundamentales y de las reglas del método. El propósito del Manual de Medición es no sólo proporcionar estas normas y definiciones, sino también proporcionar una explicación más detallada y muchos más ejemplos a fin de ayudar a los medidores a comprender plenamente y poder aplicar el método. Sin embargo, a medida que se ha ido adquiriendo más y más experiencia con el método, se ha encontrado valioso añadir reglas y ejemplos para afinar las definiciones de algunos de los conceptos subyacentes. El Consorcio Común Internacional de Medición de Software (COSMIC) prevé que estas adiciones y mejoras se presentarán a la ISO para su inclusión en la norma ISO/IEC 19761 en la fecha prevista para su revisión en 2007/08.

Este manual de medición es uno de los cuatro documentos COSMIC que definen la versión 3.0 del método. Los otros tres son:

• Descripción de la documentación y Glosario de términos (El Glosario define todos los términos que son comunes a todos los documentos COSMIC. Este documento describe también que se dispone de otros documentos de apoyo tales como casos de estudio y directrices de aplicación en dominios específicos)

• Descripción del Método • Temas Avanzados y Relacionados (Este documento tratará en más detalle las tareas que

permitan garantizar la comparación de las mediciones de tamaño funcional e incluirá capítulos sobre aproximación temprana o rápida de medición y convertibilidad de las mediciones, los cuales aparecieron anteriormente en la versión 2.2 del Manual de Medición.)

A los lectores principiantes para quienes sea nueva la medición de tamaño funcional (FSM) o que están familiarizados con otros métodos FSM se les recomienda encarecidamente que lean el documento “Descripción del Método” antes de leer este manual de medición.

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

El cambio en la designación de la versión del método COSMIC de 2.2 a 3.0 indica que esta versión representa un avance significativo sobre la versión anterior. Al elaborar esta versión 3.0 del Método COSMIC, a partir de la versión anterior que se define en el Manual de Medición de la versión 2.2, los principales cambios introducidos han sido los siguientes:

• Con el fin de hacer la documentación del Método COSMIC más fácil de aplicar, la versión 3.0 del método se define ahora en cuatro documentos.

• Se han incorporado las propuestas de los dos Boletines de Actualización del Método que fueron publicados desde la publicación de la última versión 2.2 de la Medición Manual. Estos son MUB 1 “Propuesta de Mejoras para la Definición y Características de una Capa de Software” y MUB 2 “Propuesta de Mejora a la definición de un objeto de interés”. (La versión 3.0.1 incorpora tres Boletines de Actualización más – ver Apéndice D.)

• Ha sido definida por separado una fase de “Estrategia de Medición” como la primera fase del proceso de medición. La fase de estrategia ha sido también mejorada introduciendo una guía para considerar el concepto de “Nivel de Granularidad” de las Necesidades Funcionales de los Usuarios del software que será medido, y así ayudar a garantizar la comparación de las mediciones a través de diferentes aplicaciones software.


6

• La experiencia ha demostrado que los puntos de vista de los conceptos del Usuario Final y del Desarrollador, que fueron introducidos en la medición manual en la versión 2.2, pueden ser reemplazados por el concepto más simple de Usuario Funcional. Este último puede ser simplemente definido como el remitente o destinatario de los datos en los Requerimientos Funcionales del Usuario (FUR) del software que se desea medir. Todas las mediciones de tamaño en una aplicación software se definen entonces como la funcionalidad entregada a los usuarios de la funcionalidad del software tal como es identificada en sus FUR.

• El nombre de la unidad de medida del método se ha cambiado de Unidad de Tamaño Funcional COSMIC (abreviado como Cfsu) a Punto de Función COSMIC (abreviado como CFP). Este cambio se ha hecho para facilitar la lectura y pronunciación, y para proporcionar al método en conformidad con otros métodos de “Puntos de Función”. Y para obtener una mayor simplificación, el nombre del método se ha cambiado de COSMIC-FFP a COSMIC.

• El Glosario ha sido actualizado y ampliado para mejorar la legibilidad y se ha trasladado al nuevo documento de “Descripción Documental y Glosario de Términos”.

• Algunos materiales, en particular en los conceptos de análisis de datos se han eliminado. En la actualidad se incluyen en la “Guía de Medición de Software de Gestión utilizando COSMIC”, ya que es muy específica para un dominio y no es específica para el método COSMIC.

• Se han realizado muchas mejoras y añadidos editoriales para mejorar la consistencia de la terminología y para mejorar la comprensión. Entre ellas, se ha realizado una distinción más consistente entre los “principios” y las “reglas” del método mediante la adopción de una convención procedente del mundo de la contabilidad que dice que las “reglas existen para ayudar a aplicar las definiciones y los principios”. Ambos, principios y reglas deben ser considerados como obligatorios. De ahí que, muchos ejemplos se hayan trasladado de las definiciones de principios y normas al cuerpo principal del texto.

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

Los lectores familiarizados con la versión 2.2 del Manual de Medición observarán que el mayor número de cambios en esta versión 3.0 se encuentra en la recién separada fase de “Estrategia de Medición”.

Consecuencias principales de los cambios en medicio nes existentes

Los principios originales del método COSMIC han permanecido sin cambios desde su primera publicación en el primer borrador del Manual de Medición en 1999, a pesar de los refinamientos y adiciones necesarias para producir la norma internacional y para producir las versiones 2.1, 2.2, 3.0 y esta última versión 3.0.1 del Manual de Medición.

Los tamaños funcionales medidos de acuerdo a los principios y normas de las versiones 3.0 y 3.0.1 del Manual de Medición pueden variar de tamaño utilizando las versiones anteriores sólo porque las nuevas normas tienen la intención de ser más precisas. Por lo tanto disponen un margen menor de discrecionalidad en materia de interpretación personal de las normas que era posible con versiones anteriores. Los cambios en el ámbito de la Estrategia de Medición y el cambio de nombre de la unidad de medida dan lugar a diferencias triviales en las reglas para la presentación de mediciones en comparación con versiones anteriores.

Explicación de los principales cambios de la versió n 2.2 a la versión 3.0 del Manual de Medición

En primer lugar debemos destacar que la unidad de medida COSMIC, el Cfsu (ahora rebautizado con el nombre de CFP), no ha cambiado desde que se introdujo en la primera versión pública del Manual de Medición COSMIC-FFP en el año 1999. Este es el equivalente COSMIC de, por ejemplo, una unidad de medida estándar como el metro. Pero el tamaño funcional de una aplicación software puede medirse de muchas maneras, y es a veces un problema, para cualquier Método de Medición de Tamaño Funcional (Functional Size Method, FSM), responder a la pregunta de ¿qué tamaño debemos medir?


7

El primer problema es que sabemos que cualquier aplicación software proporciona funcionalidad para los distintos tipos de Usuarios, donde un usuario se define en la terminología del estándar ISO/IEC 14143/1 (“Principios de FSM”) esencialmente como cualquier cosa que interactúa con el software que se está midiendo. De ello se deduce que el tamaño funcional de una aplicación software depende de a quién o a qué se define como su usuario(s).

Permítanos considerar como ejemplo el software de un teléfono móvil. Los usuarios podrían ser un humano que presiona los botones, los dispositivos de hardware (por ejemplo, la pantalla, teclado, etc.) que interactúan con la aplicación, o el sistema operativo sobre el que funciona el software o, incluso separados por aplicaciones de software que interactúan con la aplicación que se está midiendo. Los cuatro tipos de usuarios exigen diferentes funciones (de ahí que el tamaño funcional difiera en función de a quién o a qué se define como el usuario). Entonces, ¿Cómo, si se nos da un tamaño funcional, vamos a saber qué o quién fue el usuario(s)?, es decir, ¿Qué funcionalidad se midió?

Fue esta cuestión la que inicialmente llevó al Comité de Prácticas de Medición COSMIC (Measurement Practices Committee, MPC) a introducir en la versión 2.2 del Manual de Medición, los Puntos de Vista de Medición del “Usuario Final” y del “Desarrollador”. Sin embargo, la experiencia ha demostrado que estas definiciones, especialmente la de los Punto de Vista de la Medición del “Desarrollador”, no son lo suficientemente generales como para ayudar a definir todas las necesidades de medición. El MPC ha llegado a la conclusión de que la manera más correcta y más general de enfocarlo es definir el concepto de “Usuario Funcional” y que los cambios en el tamaño funcional dependan de qué o quién es definido como el usuario funcional. La identificación del usuario funcional depende de la finalidad de la medición y el usuario funcional debería ser normalmente identificable a partir de los Requisitos Funcionales de Usuario (Functional User Requirements, FUR) del software que se desea medir. Por lo tanto ya no se necesitará más la idea de definir un “Punto de vista de la Medición” específico.

El segundo problema es que sabemos que los FUR evolucionan a medida que el proyecto avanza y, dependiendo de cómo se mida el tamaño, su tamaño puede parecer que crece. La primera versión del FUR de una nueva aplicación software puede ser especificado a un “alto nivel”. A medida que el proyecto avanza y los requisitos son elaborados con mayor detalle, los FUR se especifican con mayor detalle, o a un “menor nivel” y su tamaño puede parecer que aumenta. Distinguimos estos diferentes niveles de detalle como “niveles de granularidad”.

Por lo tanto, el problema que tiene que ser abordado ahora es ¿cómo podemos estar seguros de que dos mediciones se han hecho en el mismo nivel de granularidad? Las versiones 3.0 y 3.0.1 del Manual de Medición ofrecen recomendaciones sobre este aspecto, que es especialmente importante cuando los tamaños son medidos a principios de la vida de un proyecto cuando los FUR están en plena evolución. Este aspecto se vuelve crítico cuando los tamaños son utilizados para mediciones del funcionamiento que deben compararse a partir de diferentes fuentes, como en ejercicios de evaluación comparativa.

Es importante destacar que estos nuevos conceptos de “usuario funcional” y “nivel de granularidad” y los procesos asociados para determinarlos que se han introducido en la “Estrategia de Medición” no tienen por qué ser únicos para el método COSMIC. Son aplicables a todos los métodos de medición del Tamaño Funcional de Software (FSM). Debido a que el método COSMIC se basa en sólidos principios de ingeniería de software y es aplicable a una gama más amplia de dominios de software que la “1ª generación” de Métodos FSM, ha sido reconocido el problema de definir adecuadamente ¿qué tamaño deberíamos medir? y se ha encontrado una solución.

La mayoría de medidores que utilizan COSMIC con el propósito de medir el rendimiento (por ejemplo, para la estimación, evaluación comparativa, etc.), no tendrán que perder tiempo en la identificación de los usuarios funcionales o sobre el nivel de granularidad con el que deben medir, ya que será evidente. Sin embargo, para las mediciones donde las opciones pueden no ser tan evidentes, los nuevos materiales de la “Fase de Estrategia de Medición” del Manual de Medición y el capítulo relativo a garantizar la posibilidad de comparación de las mediciones de tamaño en el documento “Temas Avanzados y Relacionados”, examina con mayor profundidad los factores a considerar.


8

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

Mayo 2009


9

TTaabbllaa ddee CCoonntteenniiddooss

1 INTRODUCCIÓN .............................................................................................................................11 1.1 Aplicabilidad del método COSMIC .............................................................................................. 11

1.1.1 Dominios de aplicación ..................................................................................................... 11 1.1.2 Dominio no aplicable ........................................................................................................ 11 1.1.3 Limitaciones de los factores que contribuyen a tamaño funcional .................................. 11 1.1.4 Limitaciones en la medición de aplicaciones software muy pequeñas ........................... 12

1.2 Requisitos Funcionales de Usuarios ........................................................................................... 12 1.2.1 Extracción de los requisitos funcionales de usuario a partir de los artefactos del software

en la práctica ..................................................................................................................... 12 1.2.2 Deducción de los requisitos funcionales de usuario a partir de software instalado ........ 13 1.2.3 Extracción o deducción de los requisitos funcionales de usuario a partir de artefactos

software ............................................................................................................................. 13 1.3 Modelo COSMIC de Contexto de Software ................................................................................ 14 1.4 Modelo Genérico del Software .................................................................................................... 14 1.5 El Proceso de Medición COSMIC ............................................................................................... 15

2 FASE DE ESTRATEGIA DE MEDICIÓN .................. ......................................................................17 2.1 Definir el propósito de la Medición ............................................................................................. 18

2.1.1 El propósito de una medición determina el tamaño que será medido ............................. 18 2.1.2 La importancia del propósito ............................................................................................. 19

2.2 Definir el alcance de la medición ..................................................................................................... 19 2.2.1 El alcance de una medición depende de la finalidad........................................................ 20 2.2.2 Tipos genéricos de alcance .............................................................................................. 21 2.2.3 Niveles de descomposición .............................................................................................. 21 2.2.4 Capas ................................................................................................................................ 22 2.2.5 Componentes Semejantes o Pares (Peer) ....................................................................... 24

2.3 Identificar los usuarios funcionales ............................................................................................. 26 2.3.1 El tamaño funcional varía con el usuario funcional .......................................................... 26 2.3.2 Usuarios Funcionales ....................................................................................................... 26

2.4 Identificando el nivel de granularidad.......................................................................................... 28 2.4.1 La necesidad de un nivel de granularidad estándar ......................................................... 28 2.4.2 Aclaración del nivel de granularidad ................................................................................. 29 2.4.3 El nivel de granularidad estándar ..................................................................................... 29

2.5 Observaciones finales sobre la Fase de Estrategia de la de Medición ...................................... 32

3 FASE DE REPRESENTACIÓN .......................... .............................................................................34 3.1 Aplicación del Modelo Genérico COSMIC de software .............................................................. 35 3.2 Identificación de los procesos funcionales .................................................................................. 36

3.2.1 Definiciones ....................................................................................................................... 36 3.2.2 La aproximación para identificar procesos funcionales .................................................... 37 3.2.3 Eventos disparadores y procesos funcionales en el ámbito de aplicaciones de negocio 38 3.2.4 Ejemplos en el dominio de aplicaciones en tiempo real. .................................................. 39 3.2.5 Más sobre procesos funcionales separados .................................................................... 40 3.2.6 El proceso funcional de componentes semejantes .......................................................... 40

3.3 Identificación objetos de interés y grupos de datos .................................................................... 41 3.3.1 Definiciones y principios ................................................................................................... 41 3.3.2 Sobre la materialización de un grupo de datos ................................................................ 42 3.3.3 Sobre la identificación de objetos de interés y grupos de datos ...................................... 42 3.3.4 Grupos de datos o datos que son candidatos a movimientos de datos. .......................... 43


10

3.3.5 El usuario funcional como objeto de interés ..................................................................... 44 3.4 Identificación de los atributos de datos (opcional) ...................................................................... 44

3.4.1 Definición .......................................................................................................................... 44 3.4.2 Sobre la asociación de atributos de datos y grupos de datos .......................................... 44

4 FASE DE MEDICIÓN ......................................................................................................................45 4.1. Identificar los movimientos de datos ........................................................................................... 45

4.1.1 Definición de los tipos de movimientos de datos .............................................................. 46 4.1.2. Identificación de entradas (E) ........................................................................................... 47 4.1.3. Identificación de salidas (X) .............................................................................................. 48 4.1.4. Identificación de Lecturas (R) ........................................................................................... 49 4.1.5. Identificando escrituras (W) .............................................................................................. 49 4.1.6. Sobre las manipulaciones de datos asociadas con los movimientos de datos ................ 50 4.1.7 Movimientos de datos únicos y posibles excepciones ..................................................... 51 4.1.8. Cuando un proceso funcional mueve datos para o desde un fichero de almacenamiento.

53 4.1.9 Cuando un proceso funcional requiere datos de un usuario funcional............................. 56 4.1.10 Comandos de control ........................................................................................................ 57

4.2. Aplicando la función de medición ................................................................................................ 58 4.3. Agregar resultados de medición ................................................................................................. 58

4.3.1 Reglas generales de agregación ...................................................................................... 58 4.3.2. Más sobre la agregación del tamaño funcional ................................................................ 59

4.4 Más en la medición del tamaño de los cambios de software...................................................... 60 4.4.1. Modificando funcionalidades ............................................................................................. 61 4.4.2 Tamaño del software funcionalmente modificado ........................................................... 62

4.5. Extensiones del método de medición COSMIC. ............................................................................ 62 4.5.1. Introducción ....................................................................................................................... 62 4.5.2. Extensiones locales con algoritmos complejos. ............................................................... 62 4.5.3. Extensión Local con sub-unidades de medida ................................................................. 63

5 INFORME DE MEDIDAS .................................................................................................................64 5.1 Etiquetado ....................................................................................................................................... 64 5.2 Archivando los resultados de medida COSMIC .............................................................................. 65

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

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

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

APÉNDICE D – HISTORIA DEL MÉTODO COSMIC ........... ................................................................77 De la versión 2.2 a la versión 3.0 .......................................................................................................... 77 De la versión 3.0 a la versión 3.0.1 ....................................................................................................... 82

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


11

11 INTRODUCCIÓN

1.1 Aplicabilidad del método COSMIC

1.1.1 Dominios de aplicación

El método de medición del tamaño funcional COSMIC está concebido para ser aplicable a la funcionalidad del software de los siguientes dominios:

• Aplicaciones Software de Gestión, las cuales son las típicamente utilizadas para dar soporte a la administración de negocios, tales como banca, seguros, contabilidad, personal, compras, distribución o fabricación. Este software esta a menudo caracterizado como "rico en datos", ya que está centrado principalmente en la necesidad de gestionar grandes cantidades de datos acerca de aspectos del mundo real.

• Software en tiempo real, cuya tarea es mantener o controlar acontecimientos que están sucediendo en el mundo real. Algunos ejemplos serían el software para centrales telefónicas y de intercambio de mensajes, el software incluido en dispositivos para el control de máquinas tales como los electrodomésticos, ascensores, motores de automóviles y aeronaves, para el control de procesos y la adquisición automática de datos, y software de los sistemas operativos de los ordenadores.

• Híbridos de lo anterior, como por ejemplo los sistemas de reservas en tiempo real de compañías aéreas u hoteles.

1.1.2 Dominio no aplicable

El método de medición COSMIC aún no ha sido diseñado para tener en cuenta la funcionalidad del software matemáticamente intensivo, esto es, software caracterizado por algoritmos matemáticos complejos o otra reglas complejas especializadas, como por ejemplo sistemas expertos, software de simulación, software de auto-aprendizaje, sistemas de predicción meteorológica, etc., o de procesado continuo de variables tales como sonidos de audio o imágenes de vídeo, tales como, por ejemplo, software para juegos de ordenador, instrumentos musicales, etc.

Para los programas con dicha funcionalidad es posible definir extensiones locales al método COSMIC de medición. El manual de medición explica en qué contextos tales extensiones locales se deben utilizar y proporciona ejemplos de una extensión local. Cuando se usan, estas extensiones locales deben ser reportadas de acuerdo a los convenios presentados en el capítulo reportado de mediciones de este Manual de Medición.

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

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


12

1.1.4 Limitaciones en la medición de aplicaciones software muy pequeñas

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

1.2 Requisitos Funcionales de Usuarios

El método de medición COSMIC supone la aplicación de un conjunto de modelos, principios, reglas y procesos a los Requisitos Funcionales de los Usuarios (o Functional User Requirements, FUR) de una determinada aplicación software. El resultado es un “valor de una cantidad” numérico (tal y como se define en ISO), que representa el tamaño funcional de la aplicación software de acuerdo con el método COSMIC.

Los tamaños funcionales medidos por el método COSMIC están diseñados para ser independientes de cualesquiera decisiones de implementación propias de los artefactos operacionales del software que se desea medir. "Funcionalidad" se refiere al “procesamiento de la información que el software debe realizar para sus usuarios”.

Más concretamente, una declaración de FUR describe “qué” debe hacer el software por los usuarios funcionales, que son los remitentes y destinatarios de los datos, hacia y desde el software. Una declaración del FUR excluye cualesquiera requisitos técnicos o los de calidad que digan “cómo” debe funcionar el software. (Para leer la definición formal de FUR, véase la sección 2.2.) A la hora de medir el tamaño funcional sólo los FUR son tenidos en cuenta.

1.2.1 Extracción de los requisitos funcionales de usuario a partir de los artefactos del software en la práctica

En el mundo real de desarrollo de software es raro encontrar artefactos para el software en los que los FUR sean claramente distinguibles de otros tipos de requisitos y que sean expresados en un formato adecuado para realizar mediciones directas, sin necesidad de interpretación. Esto significa que por lo general el medidor tendrá que extraer los FUR tal y como se suministren, explícita o implícitamente, en artefacto de software, antes de representarlos como conceptos de los “modelos de software” de COSMIC.

Requirements

definition artifacts

Dataanalysis / modelling

artifacts

Artifacts fromfunctional decomposition

of requirements

Functional User Requirements (‘FUR’) in the artifacts of the software to be measured

Requirements

definition artifacts

Dataanalysis / modelling

artifacts

Artifacts fromfunctional decomposition

of requirements


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


13

Como se ilustra en la figura 1.2.1, el FUR puede ser derivado de artefactos de ingeniería de software que se producen antes de que el software exista. Por lo tanto, el tamaño funcional del software puede medirse antes de su implementación como un sistema informático.

Es importante señalar que los artefactos que se producen antes de que el software sea implementado, por ejemplo, durante la recopilación o el análisis de requisitos, podrían describir el software en diferentes “niveles de granularidad” mientras los requisitos evolucionan - véase también más abajo la sección 2.4.

Nota: Los requisitos funcionales de usuario pueden ser producidos antes de que sean asignados al hardware o al software. Dado que el método COSMIC está destinado a medir el FUR de una aplicación software, sólo se medirán los FUR asignados a aplicación software. Sin embargo, en principio el método COSMIC puede aplicarse a los FUR antes de que sean asignados a un software o hardware, independientemente de la decisión eventual de asignación. Por ejemplo, es sencillo medir el tamaño de funcionalidad de una calculadora de bolsillo utilizando COSMIC sin conocimiento que hardware o software (si lo hubiera) será utilizado. Sin embargo, la afirmación de que el método COSMIC se puede utilizar para medir FUR asignado a hardware, necesita más pruebas prácticas antes de que pueda considerarse como plenamente validado sin la necesidad de más reglas.

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

En otras circunstancias, se puede necesitar medir algunas aplicaciones de software existentes sin que hubiera algún, o quizá sólo unos pocos, artefactos de diseño o arquitectura disponibles, y el FUR podría no estar documentado (por ejemplo, para el legado del software). En tales circunstancias, aún es posible obtener los FUR a partir de los artefactos instalados en el sistema incluso después de que haya sido implementado, como se ilustra en el gráfico 1.2.2.

Physicalprograms

Softwareoperationsmanual and

procedures

Physicaldata storage

artifacts


Physicalprograms

Softwareoperationsmanual and

procedures


artifacts


artifacts


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

1.2.3 Extracción o deducción de los requisitos funcionales de usuario a partir de artefactos software

Los procesos para ser utilizados y, por tanto, el esfuerzo necesario para extraer el FUR de diferentes tipos de artefactos de ingeniería de software o para derivar de ellos el software instalado y para su expresión en la forma requerida para la medición en el método COSMIC evidentemente variarán; estos procesos no pueden ser tratados en el Manual de Medición. Se asume que los requisitos funcionales del software que será medido bien existen o pueden ser extraídos o derivados de sus artefactos, a la luz del propósito de la medición.


14

El Manual de Medición se limita, por lo tanto, a describir y definir los conceptos de modelos de software COSMIC, es decir, los objetivos de la extracción o derivación. Estos conceptos están plasmados en un conjunto de principios establecidos en dos modelos de software COSMIC - el “Modelo de Contexto de Software” y el “Modelo Genérico de Software”.

Estos dos modelos se describen en el documento de “Descripción del Método”. Los lectores que requieran una comprensión general y una justificación de los modelos se les refieren al documento de “Descripción del Método”. Los modelos se copian a continuación para mayor comodidad y se exponen respectivamente en detalle en los capítulos 2 y 3 del presente Manual de Medición.

1.3 Modelo COSMIC de Contexto de Software

Una aplicación software que va a ser medida con el método COSMIC debe ser cuidadosamente definida (en el alcance de medición) y esta definición debe tener en cuenta su contexto de cualquier otro software y/o hardware con los que interactúa. Este Modelo de Contexto de Software introduce el modelo de principios y conceptos necesarios para esta definición.

Nótese bien, Los términos se indican en negrita cuando se utilizan por primera vez en las siguientes secciones 1.3 y 1.4 se utilizan con significados que pueden ser específicos para el método COSMIC. Para la definición formal, véase el documento: “Descripción Documental y Glosario de Términos”. Todos estos términos se explican en mayor detalle en los capítulos 2, 3 y 4.

Principios del Modelo COSMIC de Contexto de Softwar e:

a) El software está limitado por el hardware b) El software está típicamente estructurado en capas c) Una capa puede contener una o más aplicaciones de software semejante, y

cualquier aplicación software puede consistir de uno o más componentes del mismo tipo separados.

d) Cualquier aplicación software que deba medirse, se define por su alcance de medición, que se limitará en su totalidad dentro de una sola capa

e) El alcance de aplicación software debe medirse en función de la finalidad de la medición

f) Los usuarios funcionales de una aplicación software se identificarán a partir de los FUR de la aplicación software que se medirá como los remitentes y/o destinatarios de los datos

g) Una aplicación software interactúa con sus usuarios a través de movimientos de datos por una frontera y la aplicación software puede mover datos hacia y desde zonas de almacenamiento persistente dentro de unos límites

h) Los FUR de software pueden expresarse en distintos niveles de granularidad i) El nivel de granularidad en que las mediciones se hacen normalmente es el de los

procesos funcionales Si no es posible medir a nivel de granularidad del proceso funcional, entonces los FUR del software deben ser medido por aproximación y escalado al nivel de granularidad funcional del proceso

Los conceptos del Modelo de Contexto del Software se detallan en la “Estrategia de medición” en el Capítulo 2 de este Manual de Medición.

1.4 Modelo Genérico del Software

Después de haber interpretado los FUR del software a ser medido en términos del “Modelo de Contexto del Software”, debemos ahora aplicar el Modelo Genérico del Software a los FUR para identificar los componentes de la funcionalidad que se medirán. Este Modelo Genérico de Software asume que los siguientes principios generales son ciertos para cualquier software que puede ser medido con el método. (Como se señala en el glosario, cualquier método de medición de tamaño


15

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

Principios del Modelo de Software COSMIC Genérico:

a) El Software recibe los datos de entrada de sus usuarios funcionales y produce datos de salida , y/u otro resultado, para los usuarios funcionales

b) Las requisitos funcionales de los usuarios de la aplicación software a medir pueden representarse como procesos funcionales únicos

c) Cada proceso funcional consiste en sub-procesos d) Una sub-proceso puede ser, o bien un movimiento de datos o una

manipulación de datos e) Cada proceso funcional es activado por un movimiento de entrada de datos

desde un usuario funcional que informa al proceso funcional que el usuario funcional ha identificado un evento

f) Un movimiento de datos mueve un sólo grupo de datos g) Un grupo de datos consiste en un conjunto único de atributos de datos que

describen un único objeto de interés. h) Existen cuatro tipos de movimientos de datos: Una Entrada, mueve un grupo de

datos hacia el software desde un usuario funcional. Una Salida mueve un grupo de datos del software hacia un usuario funcional. Una Escritura mueve un grupo de datos desde el software hacia un almacén persistente. Una Lectura mueve un grupo de datos desde un almacén persistente hacia el software

i) Un proceso funcional deberá incluir al menos un movimiento de entrada y, o bien un movimiento de Salida o Escritura de datos, es decir que deberá incluir un mínimo de dos movimientos de datos

j) Como una aproximación para fines de medición, los sub-procesos de manipulación de datos no se miden por separado; la funcionalidad de cualquier manipulación de datos se supone que se explica por el movimiento de datos con el que está asociado

Los conceptos del Modelo Genérico de Software se detallan en la “Fase de Representación” Capítulo 3 del presente Medición Manual.

Cuando el FUR a ser medido ha sido representado en el Modelo Genérico de Software, puede ser entonces medido utilizando los procesos de la Fase de Medición (Capítulo 4). Los resultados de la medición deberían ser documentados de acuerdo con las convenciones del Capítulo 5 “Informes de Medición”.

1.5 El Proceso de Medición COSMIC

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

• La Fase de Estrategia de Medición, en la cual el Modelo de Contexto de Software se aplica al software a ser medido (Capítulo 2)

• La Fase de la Representación de la Medición, en la cual el Modelo Genérico de Software se aplica al software a ser medido (Capítulo 3)

• La Fase de Medición, en la cual se obtienen las mediciones reales (capítulo 4)

El resultado de aplicar el proceso de medición a una aplicación software es una medida de tamaño funcional de los Requisitos Funcionales de Usuario de la aplicación software expresada en “Puntos de Función COSMIC” (ó CFP)

La relación entre estas tres fases del método COSMIC se muestra en la Fig. 1.5.


16

Functional User Requirements (FUR) in the artefacts of the software to be measured

Chapter 3Measurement

Strategy

The Measurement Process

Generic Software Model

Chapter 4Mapping

Phase

Purpose of the measurement. Scope of each piece of software

to be measured

FUR in the form of the Generic Software Model


Phase

Goals

Software Context Model

Functional size of the software in

units of CFP

Functional User Requirements (FUR) in the artefacts of the software to be measured


Strategy

The Measurement Process

Generic Software Model

Chapter 4Mapping

Phase

Purpose of the measurement. Scope of each piece of software

to be measured

FUR in the form of the Generic Software Model


Phase

Goals

Software Context Model

Functional size of the software in

units of CFP

Figura 1.5 – Estructura del método COSMIC


17

22 FASE DE ESTRATEGIA DE MEDICIÓN

En este capítulo se abordan los cuatro parámetros fundamentales de medición del tamaño funcional del software que debe ser considerados antes de comenzar a medir, estos son: el propósito y el alcance de la medición, la identificación de los usuarios funcionales y el nivel de granularidad que debe medirse. Determinar estos parámetros ayuda a abordar las cuestiones de ¿qué tamaño debe medirse? o, para una medición existente, ¿cómo debemos interpretar esta medida?

Es importante señalar que estos cuatro parámetros y conceptos relacionados no son específicos del método de la medición del tamaño funcional COSMIC, pero debe ser común a todos los métodos FSM (Functional Size Measurement). Otros métodos FSM pueden no distinguir diferentes tipos de usuarios funcionales y pueden no discutir los diferentes niveles de granularidad, etc. Sólo la aplicación más amplia y la flexibilidad del método COSMIC requieren que se tomen en cuenta estos parámetros más cuidadosamente que con otros métodos FSM.

Es muy importante guardar los datos resultantes de esta fase de “Estrategia de Medición” (que se enumeran en la sección 5.2) al guardar el resultado de cualquier medición. La falta de definición y registro de estos parámetros dará lugar a mediciones que no pueden ser interpretadas fiablemente y, o ser utilizadas para procesos tales como la estimación de esfuerzo del proyecto.

Las cuatro secciones de este capítulo dan las definiciones formales, principios, normas y algunos ejemplos para cada uno de los principales parámetros para ayudar al medidor a través del proceso de determinar una “Estrategia de Medición”, como se muestra en la figura 2.0 mostrada más abajo.

Cada sección ofrece explicaciones de por qué el parámetro clave es importante, utilizando analogías para mostrar por qué el parámetro se da por sentado en otros campos de medición, razón por la cual también debe ser considerado en el ámbito de de medición de tamaño funcional de software.

THEMEASUREMENT

STRATEGY

COSMIC MEASUREMENT STRATEGY PHASE

Section 2.1

DeterminePURPOSE of the

measurement

Input from theMEASUREMENT

SPONSOR

Section 2.2

DetermineSCOPE of themeasurement

Section 2.3

Identify theFUNCTIONAL

USERS

Section 2.4

Determine theLEVEL OF GRANULARITY

of the measurement

ITERATE

THEMEASUREMENT

STRATEGY

COSMIC MEASUREMENT STRATEGY PHASE

Section 2.1

DeterminePURPOSE of the

measurement

Input from theMEASUREMENT

SPONSOR

Section 2.2

DetermineSCOPE of themeasurement

Section 2.3

Identify theFUNCTIONAL

USERS

Section 2.4

Determine theLEVEL OF GRANULARITY

of the measurement

ITERATE

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


18

2.1 Definir el propósito de la Medición

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

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

Una declaración que define por qué una medida es necesaria, y para qué se utilizará el resultado

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

Hay muchas razones para medir el tamaño funcional del software, así como hay muchas razones para medir, por ejemplo, las superficies de una casa. Cuando el objetivo es estimar el coste de un nuevo desarrollo de software, podría ser necesario medir el tamaño funcional del software antes de su desarrollo, del mismo modo que podría ser necesario medir las superficies de una casa antes de su construcción. En un contexto diferente, por ejemplo, cuando se necesitan comparar con los costes reales con los estimados, tal vez sea necesario medir el tamaño funcional del software una vez se ha puesto en producción, del mismo modo que podría ser útil medir las superficies de una casa después de haber sido construida para comprobar que las dimensiones se ajustan a los planes convenidos. La razón por la cual se ha tomado una medida tiene un impacto a lo que se está midiendo, sin que ello afecte a la unidad de medida o a los principios de medición.

En el ejemplo anterior de la casa, la medición de su superficie antes de la construcción se basa, obviamente, en los planos de construcción. Las dimensiones (longitud y anchura) se extraen de los planos usando la adecuada escala y las superficies se calculan de acuerdo a convenios establecidos.

Del mismo modo, medir el tamaño funcional del software antes de su desarrollo se basa en las necesidades de los usuarios funcionales de software que se derivan de sus planos, es decir, los artefactos de software producidos antes de su desarrollo. Las necesidades funcionales de los usuarios son extraídas de estos aparatos que usando los convenios adecuados y las dimensiones necesarias (el número de movimientos de datos) se identifican de modo que se pueda calcular el tamaño.

Para continuar con la analogía de la casa, la medición de su superficie después de que haya sido construida implica un proceso de medición diferente. Ahora, las dimensiones (longitud y anchura) son extraídas del propio edificio utilizando una herramienta diferente (cinta métrica). Sin embargo, a pesar de que el objeto físico que se mide es diferente (la casa en lugar de sus planos), las dimensiones, la unidad de medida (incluyendo cualquier convención de escala) y todos los principios de medición siguen siendo los mismos.

Del mismo modo, medir el tamaño funcional del software después de que haya sido puesto en la producción implica un proceso diferente de medición cuando las dimensiones necesarias se extraen de los diversos aparatos del software en sí. Aunque la naturaleza de estos aparatos es diferente, las dimensiones, la unidad de medida y los principios de medición siguen siendo los mismos.

Es decisión del medidor, basándose en el propósito de la medición, determinar si el objeto a ser medido es la casa a partir de la descripción verbal de su propietario; la casa, tal como se describe a través de los planos; o la casa, una vez que ha sido construida; así como seleccionar los artefactos más apropiados para la medición. Es evidente que los tres tamaños podrían ser diferentes. El mismo razonamiento se aplica a la medición de software.

EJEMPLOS: Algunos propósitos típicos de la medición

• Medir el tamaño de los FUR a medida que evolucionan, como entrada a un proceso de estimación del esfuerzo de desarrollo

• Medir el tamaño de los cambios de FUR después de haber sido inicialmente acordados, con el fin de gestionar el alcance avanzado de un proyecto


19

• Medir el tamaño de los FUR a la entrega de software como entrada para la medición del rendimiento de los desarrolladores

• Medir el tamaño de los FUR del software se han entregado, y también el tamaño de los FUR del software que han sido desarrollado, con el fin de obtener una medida funcional de la reutilización

• Medir el tamaño de los FUR de los programas existentes, como entrada a la medición del desempeño de los responsables de mantener y sostener el software

• Medir el tamaño de algunos cambios en (el FUR de) un sistema de software existente, como una medida del tamaño de un proyecto de mejora

• Para medir el tamaño de la funcionalidad del software entregado a usuarios funcionales humanos

2.1.2 La importancia del propósito

El propósito ayuda a los medidores a determinar:

• El alcance que debe medirse y los aparatos que serán necesarios para la medición • Los usuarios funcionales (como se indica en la sección 2.3, el tamaño de los cambios funcionales

es función de lo que se defina como el usuario funcional) • El momento en el ciclo de vida del proyecto en el que la medición se llevará a cabo • La precisión necesaria de la medición, y por lo tanto, si debería utilizarse la medición con el

método COSMIC, o si debería se debería utilizar una aproximación derivada localmente de COSMIC (por ejemplo, de manera temprana en el ciclo de vida de un proyecto, antes de que los FUR estén totalmente elaborados). Ambos de estos dos últimos puntos determinan el nivel de granularidad al cual serán medidos los FUR.

2.2 Definir el alcance de la medición

Definición – Alcance de una medición

El conjunto de los requisitos funcionales de usuario que deben incluirse en un determinado ejercicio de medición de tamaño funcional.

Nota: Se debe hacer una distinción entre el alcance general, es decir, todo el software que debe medirse en función del objetivo, y el alcance de cualquier aplicación software en el alcance global, cuyo tamaño debe medirse por separado. En este Manual de Medición, el término “alcance” (o la expresión “alcance de la medición”) se refieren a una aplicación única de software, cuyo tamaño debe medirse por separado.

Los Requisitos Funcionales de los Usuarios son definidos por ISO como sigue:

Definición – Requisitos Funcionales de los Usuarios (Functional Users Requirements, FUR)

Subconjunto de los Requisitos de los Usuarios. Requisitos que describen lo que el software deberá hacer, en términos de funciones y servicios.

Nota: Los requisitos funcionales de los usuarios incluyen, pero no están limitados a:

• Transferencia de datos (por ejemplo de entrada de datos de clientes; enviar señal de control)

• Transformación de datos (por ejemplo calcular los intereses bancarios; derivar temperatura media)

• Almacenamiento de datos (por ejemplo pedidos de clientes; recopilar datos de temperatura ambiente durante un tiempo)

• Recuperación de datos (por ejemplo listas de los empleados actuales; recuperar la última posición de una aeronave)

Ejemplos de requisitos de los usuarios que no son requisitos funcionales de los usuarios


20

incluyen, pero no están limitados a:

• Restricciones de calidad (por ejemplo, facilidad de uso, fiabilidad, eficiencia y portabilidad)

• Restricciones de organización (por ejemplo, localización de operación, hardware objetivo y cumplimiento de normas)

• Restricciones medioambientales (por ejemplo, interoperabilidad, seguridad, privacidad y seguridad)

• Aplicación de limitaciones (por ejemplo, lenguaje de desarrollo, calendario de entrega)

Reglas – Alcance

a) El alcance de una medición de tamaño funcional (FSM) se obtendrá del propósito de la medición.

b) El alcance de una medición no se extenderá a más de una capa de software que debe medirse

2.2.1 El alcance de una medición depende de la finalidad

Es importante definir el alcance de una medición antes de comenzar un ejercicio de medición.

Siguiendo con la analogía de la construcción de casas, puede ser necesario, si el propósito es la estimación de costes, medir el tamaño de diferentes partes de la casa por separado, por ejemplo, los cimientos, las paredes y el techo, debido a que utilizan diferentes métodos de construcción. Lo mismo es válido para la estimación de costes de desarrollo de software.

En caso de un sistema de software sucede que consta de partes que residen en diferentes capas de la arquitectura del sistema, por consiguiente tendrá que ser medido por separado el tamaño del software en cada capa, es decir, cada parte tendrá un alcance diferente para los propósitos de medición de tamaño. Esto se desprende del principio (d) del Modelo de Contexto de Software. (Para más información sobre capas, consulte la sección 2.2.4 a continuación.)

Del mismo modo, si el software debe ser desarrollado como un conjunto de componentes semejantes dentro de una sola capa, cada una de ellas utilizando diferentes tecnologías, entonces será necesario definir un alcance de la medición separado para cada uno de los componentes antes de la medición de su tamaño.

Ejemplo 1: Si cada componente de software usa una tecnología diferente y las medidas son usadas para la estimación del esfuerzo de desarrollo, entonces debería ser definida para cada componente una medida separada porque cada medición del tamaño irá asociada con una cifra de productividad diferente (para más información de componentes semejantes, véase la sección 2.2.5 más abajo).

El propósito también ayudará a decidir qué software debe ser incluido y excluido del alcance de la medición.

Ejemplo 2: Si el propósito es medir el tamaño funcional de una pieza de software desarrollada por un equipo de proyecto en particular, primero será necesario definir los requisitos funcionales del usuario de los diversos componentes que serán desarrollados por el equipo. Estos podrían incluir los FUR de una aplicación software que es utilizada sólo una vez para convertir datos de un software que se está reemplazando.

Ejemplo 3: Si el propósito es medir el tamaño de un nuevo software que está disponible para su uso operativo, este podría ser más pequeño que para el ejemplo 2, ya que los FUR del software utilizado para la conversión no serían incluidos en el ámbito de la medición de tamaño.


21

En resumen, el propósito de la medición debe ser siempre utilizado para determinar (a) qué software es incluido o excluido del alcance global y (b) la forma en que el software incluido puede que sea necesario dividirlo en partes separadas, cada una con su propio alcance, que deben medirse por separado.

2.2.2 Tipos genéricos de alcance

Ejemplos

• La cartera de proyectos de una empresa

• Un acuerdo contractual de especificación de requisitos

• El producto entregado por el equipo de trabajo de un proyecto (es decir, incluyendo los parámetros obtenidos por la explotación de los programas informáticos existentes, paquetes comprados y código re-utilizable, cualquier programa utilizado para la conversión de datos y posteriormente desechado, y utilidades y software de pruebas desarrollados específicamente para este proyecto)

• El producto desarrollado por el equipo de trabajo de un proyecto (es decir, incluyendo cualquier software desarrollado por el equipo y utilizado para la conversión de datos, pero posteriormente descartado, y cualquier utilidad y software de pruebas de software desarrollado específicamente para este proyecto, pero con exclusión de toda la funcionalidad obtenida por el cambio parámetros y la explotación de el código re-utilizable o comprada en paquetes comerciales)

• Todo el software de una capa

• Un paquete software

• Una aplicación

• Un componente par o semejante principal de una aplicación

• Una objeto de clase re-utilizable

• Todos los cambios necesarios para una nueva versión de una aplicación software existente

En la práctica, una declaración de alcance tiene que ser explícita en lugar de genérica, por ejemplo, el producto de un proyecto desarrollado por el equipo de trabajo “A”, o la aplicación “B”, o la cartera de la empresa “C”. La declaración de alcance también puede tener, para una mayor claridad, necesidad de establecer lo que ha sido excluido.

2.2.3 Niveles de descomposición

Tenga en cuenta que algunos de los ‘tipos genéricos de alcance’ de los mencionados, corresponden a diferentes ‘niveles de la descomposición’ del software, definidos de la siguiente manera:

Definición – Nivel de descomposición

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

Nota 1: No debe confundirse con ‘nivel de granularidad’.

Nota 2: Las mediciones de tamaño de componentes de una parte del software sólo pueden ser comparadas con componentes semejantes, por ejemplo, componentes del mismo nivel de descomposición.

Ejemplo: De los diferentes niveles de descomposición, correspondientes a diferentes “tipos genéricos de alcance” podría ser una “cartera de aplicaciones” que consiste en “múltiples aplicaciones”, cada una de las cuales puede consistir en “componentes especiales semejantes”, cada una de los cuales puede consistir a su vez en “clases de objetos re-utilizables”.

Determinar el alcance de una medida puede ser, por consiguiente, algo más que una simple cuestión de decidir qué funcionalidad debería incluirse en la medición. La decisión también puede conllevar un examen del nivel de descomposición de software donde se medirá. Se trata de una decisión importante de la “Estrategia de Medición”, depende de la finalidad de la medición, porque las mediciones a diferentes niveles de descomposición no pueden ser comparadas fácilmente. Esto


22

surge porque, como se verá en la sección 4.3.1, el tamaño de cualquier aplicación software no se puede obtener simplemente sumando los tamaños de sus componentes.

2.2.4 Capas

Dado que el alcance de una aplicación software que debe medirse debe limitarse a una sola capa de software, el proceso de definir el alcance podrá requerir que el medidor primero tenga que decidir cuáles son las capas de la arquitectura del software. Por lo tanto en esta sección vamos a definir y discutir “capas” y “peer componentes” de software tal y como estos términos son utilizados en el método COSMIC.

Las razones por las que necesitamos estas definiciones y reglas son las siguientes:

• El medidor puede encontrase con la medición de algún tipo de software en un entorno de software “legado” que ha evolucionado a lo largo de muchos años sin haber sido diseñado de acuerdo a una arquitectura subyacente (la llamada arquitectura espagueti) El medidor puede, por tanto, necesitar orientación de cómo distinguir las capas de acuerdo con la terminología COSMIC.

• Las expresiones “capa”, “arquitectura en capas” y “componente semejante” no se utilizan consistentemente en la industria del software. Si el medidor debe medir algún tipo de software que ha sido descrito mediante una “arquitectura de capas”, es aconsejable comprobar que las “capas” en esta arquitectura están definidas de una manera que sea compatible con el método COSMIC. Para ello, el medidor debería establecer la equivalencia entre determinados objetos arquitectónicos en el paradigma de “arquitectura de capas” y el concepto de capas, tal como se definen en este manual.

Las capas pueden ser identificadas conforme a las siguientes definiciones y principios.

Definición – Capa

Una capa es una partición resultante de la división funcional de una arquitectura de software que junto con el hardware en su conjunto forma un sistema informático en el que:

• las capas están organizadas en una jerarquía • sólo hay una capa en cada nivel en la jerarquía • exista una dependencia jerárquica “superior/subordinado” entre los servicios

funcionales prestados por el software en dos capas en la arquitectura de software que intercambia datos directamente

• el software en cualesquiera dos capas en la arquitectura del software que intercambian datos interpreta sólo parte de los datos de forma idéntica

La identificación de capas es un proceso iterativo. Las capas exactas serán refinadas a medida que el proceso de representación avance. Una vez identificadas, cada una de las capas candidatas deben cumplir con los principios y reglas siguientes:

Principios – Capa

c) El Software en una capa intercambia datos con el software en otro nivel a través de sus respectivos procesos funcionales.

d) La “dependencia jerárquica” entre capas es tal que el software en cualquier capa puede utilizar los servicios funcionales de cualquier software en cualquier capa debajo en la jerarquía. En caso de que existan relaciones de dicho uso, designamos a la capa que da uso al software como la capa “superior” y cualquier capa que contiene el software usado como “subordinada”. El software en la capa superior se basa en los servicios de software de las capas subordinadas para funcionar correctamente, estas, a su vez se basan en el software de sus capas subordinadas, y así sucesivamente desciende en la jerarquía. Por el contrario, el software en una capa subordinada, junto con el software en cualquier capa


23

subordinada de la que depende, puede funcionar sin necesidad de los servicios de software en cualquier capa superior en la jerarquía.

e) El Software en una capa no necesariamente usa todos los servicios funcionales prestados por una capa subordinada.

f) Los datos que se intercambian entre software en dos capas se define e interpreta de manera diferente en los respectivas FUR de las dos partes de software, es decir, las dos partes de software reconocen diferentes atributos de datos y/o sub-agrupaciones de los datos que intercambian. Sin embargo, deben existir uno o más atributos de datos o sub-grupos definidos de forma similar para permitir que el software en la capa receptora pueda interpretar los datos que ha pasado el software en la capa emisora, de acuerdo con las necesidades de recepción de software.

Reglas – Capa

a) Si el software está concebido utilizando una arquitectura de capas como se entiende aquí, entonces que la arquitectura debe ser usada para identificar las capas usadas a efectos de medición.

b) En el dominio SIM o software empresarial, la capa más alta, es decir la capa que no está subordinada a ninguna otra capa, normalmente se denomina la capa de aplicación. Una aplicación de software en esta capa se basa en última instancia en los servicios de software en todas las otras capas para funcionar adecuadamente. En el dominio de a tiempo real software, el software en la capa superior comúnmente se denomina como un sistema, como por ejemplo en el software de un sistema de control de procesos, o también por ejemplo en un software de sistema de control de vuelo.

c) No se puede asumir que ningún software que se ha desarrollado sin ningún tipo de consideración de diseño arquitectónico o estructuración puede dividirse en capas de acuerdo al modelo COSMIC.

Los paquetes de software de servicios funcionales tales como los sistemas de gestión de bases de datos, sistemas operativos o controladores de dispositivo, debe considerarse en principio que se situarán en capas separadas.

Una vez identificadas, cada capa puede ser registrada como un “componente” separado en la matriz del Modelo Genérico de Software (anexo A), con la correspondiente etiqueta.

Ejemplo 1: La estructura física de una típica arquitectura de software en capas (utilizando el término “capa” como ha sido definido aquí) que soporte aplicaciones software de gestión se da en la figura 2.2.4.1:


24

Middleware Layer (Utilities, etc)

Operating System Layer

KeyboardDriver

ScreenDriver

VDUScreen

KeyboardHardware

Software

Layers

DiskDriver

Hard DiskDrive

PrintDriver

PrinterCentral

Processor

Database Management System Layer DBMS 1 DBMS 2

App 1Application Layer App 2 App ‘n’

SubordinateLayer

SuperiorLayer

relies on

Key:

Middleware Layer (Utilities, etc)


KeyboardDriver

ScreenDriver

VDUScreen

KeyboardHardware

Software

Layers

DiskDriver

Hard DiskDrive

DiskDriver

Hard DiskDrive

PrintDriver

Printer

PrintDriver

PrinterCentral

ProcessorCentral

Processor

Database Management System Layer DBMS 1 DBMS 2

App 1Application Layer App 2 App ‘n’

SubordinateLayer

SuperiorLayer

relies on

Key:

SubordinateLayer

SuperiorLayer

relies on

SubordinateLayer

SuperiorLayer

relies on

Key:

Figura 2.2.4.1 – Típica arquitectura de software en capas de un sistema de negocios Ejemplo 2: La estructura física de una típica arquitectura de software en capas (de nuevo utilizando el término “capa” como ha sido definido aquí) soportando una parte imbuida de una aplicación en tiempo real se muestra en la figura 2.2.4.2:


SensorDriver

Display

Mem. ChipDriver

CVDriver

ControlValve(s)

MemoryChip

CentralProcessor

Sensor(s)Hardware

(Examples)

DisplayDriver

Embedded Application Layer

SubordinateLayer

SuperiorLayer

relies on

Key:

Software

Layers Operating System Layer

SensorDriver

Display

Mem. ChipDriver

CVDriver

ControlValve(s)

MemoryChip

CentralProcessor

Sensor(s)Hardware

(Examples)

DisplayDriver

DisplayDriver

Embedded Application Layer

SubordinateLayer

SuperiorLayer

relies on

Key:

SubordinateLayer

SuperiorLayer

relies on

SubordinateLayer

SuperiorLayer

relies on

Key:

Software

Layers

Figure 2.2.4.2 – Típica arquitectura en capas de un sistema software embebido de tiempo real

2.2.5 Componentes Semejantes o Pares (Peer)

Visto el concepto de capas, ‘peer’ se define de la siguiente manera:

Definición – Semejante

Dos partes de software son semejantes una a la otra si se encuentran en la misma capa.

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


25

Los componentes semejantes pueden ser identificados de acuerdo a la siguiente definición y principios.

Definición – Componente semejante

Un componente usa un juego de componentes cooperativos, todos en el mismo nivel de descomposición, que resulta de dividir una parte de software dentro de una capa, donde cada componente llena una porción de los requerimientos funcionales de usuario de esa parte de software.

Nota: La división de una pieza del software en componentes semejantes puede ser una respuesta a requerimientos de usuarios funcionales y/o no funcionales.

Una vez identificados, cada uno de los supuestos componentes pares deben cumplir con los siguientes principios:

Principios – Componente semejante

a) En una capa de un conjunto de componentes semejantes de una pieza no existe dependencia jerárquica entre los componentes semejantes como hay entre las capas. Los FUR homólogos de todos los componentes de una pieza de software en cualquier capa se encuentran en al mismo nivel en la jerarquía de capas.

b) Todos los componentes semejantes de una pieza de software deben cooperar mutuamente con el fin de que la pieza de software pueda funcionar correctamente.

c) El FUR de componentes semejantes en toda una capa que emita o comparta datos en común define esos datos idénticamente, es decir, reconoce los mismos datos y sub-agrupaciones de datos que pasan o comparten.

Una vez identificados, cada uno de los componentes semejantes pueden ser registrados como un componente individual en la matriz del modelo genérico de software (anexo A), con la correspondiente etiqueta.

Ejemplo: Cuando una aplicación de gestión se desarrolla en tres grandes componentes, denominados “interfaz de usuario” (o “front-end”), “reglas de negocio” y “datos de servicio”, los tres componentes son componentes semejantes.

NOTA: Dos partes de software separadas pero semejantes en la misma capa y que intercambian datos entre sí pueden hacerlo tanto por cualquiera de las secuencias alternativas definidas en el principio c) para dos componentes semejantes.

El siguiente diagrama muestra una situación que ilustra el ejemplo. Todo el software mostrado reside en la misma capa de la aplicación. Los intercambios entre dos componentes semejantes de la Aplicación X y entre dos partes semejantes de software (Componente 2 de la Aplicación X y Aplicación Y) pueden darse a través de cualquiera de las secuencias alternativas que se definen en el principio c) para dos componentes semejantes.

App X App Y

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 XExchanges 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 XExchanges between two peer pieces of software

Level 1 of decomposition of App X

Figure 2.2.5.1 – Relación entre los conceptos de ‘s emejantes’, ‘componente’ y ‘componentes semejantes’


26

2.3 Identificar los usuarios funcionales

2.3.1 El tamaño funcional varía con el usuario funcional

A partir de una analogía, la medición de la superficie de una oficina puede llevarse a cabo de acuerdo con cuatro diferentes convenios, como se indica a continuación (nótese que el alcance – la oficina en particular – es la misma para los cuatro convenios).

• El propietario del edificio tiene que pagar impuestos por la oficina. Para el propietario, la superficie es el bruto de los metros cuadrados, determinado a partir de las dimensiones externas y, por tanto, incluidos todos los pasillos públicos, el espacio ocupado por las paredes, etc.

• El responsable del aire acondicionado del edificio está interesado en la red de metros cuadrados, es decir, las zonas de interior, incluidos los las zonas públicas y en el espacio tomado por los ascensores, pero excluyendo el espesor de las paredes

• El contratista del servicio de limpieza contratado por una oficina específica del edificio está interesado en los metros cuadrados netos, que excluye los espacios públicos, pero que incluye los pasillos utilizados por el arrendatario.

• El responsable de la planificación de oficinas solo está interesado en los metros cuadrados netos útiles.

La lección de esta analogía es que el tamaño de un objeto puede variar dependiendo de la funcionalidad que es de interés para diferentes tipos de usuarios del objeto. En el caso del software, diferentes usuarios funcionales podrán exigir y utilizar diferentes funcionalidades y, por tanto, los tamaños funcionales varían con la elección de los usuarios funcionales.

2.3.2 Usuarios Funcionales

Un “usuario” se define, en la norma ISO/IEC 14143/1:2007, como “cualquier cosa que interactúa con el software que se está midiendo”. Esta definición es demasiado amplia para las necesidades del método COSMIC. Para el método COSMIC, la elección de un usuario (o usuarios) se determina por los requisitos del usuario funcional que deben medirse. Este (tipo de) usuario, es conocido como el “usuario funcional” y se define como sigue.

Definición – Usuario Funcional

Es un usuario aquel remitente y/o destinatario de datos de los Requisitos Funcionales de Usuario de una aplicación software.

En el método COSMIC es esencial distinguir a los usuarios funcionales de una parte del software que debe ser medido de entre todos sus posibles usuarios.

Ejemplo 1: Considere una aplicación empresarial; Sus usuarios funcionales normalmente incluirían humanos y otras aplicaciones semejantes con las que la aplicación interactúa. Para una aplicación en tiempo real, los usuarios funcionales normalmente serían dispositivos hardware u otros software semejantes que interactúen con ella. Las necesidades de los usuarios funcionales (FUR) de dicho software normalmente se expresan de modo que los usuarios funcionales son los que envían datos y/o los destinatarios de los datos hacia y desde el software, respectivamente.

Sin embargo, el conjunto total de “usuarios”, es decir, incluida cualquier cosa que interactúa con el software, debe incluir el sistema operativo. Pero los FUR de cualquier aplicación nunca incluirían el sistema operativo como un usuario. Cualquier limitación que el sistema operativo pueda imponer a una aplicación será común para todas las aplicaciones, por lo general, se encargarán de ella el compilador o intérprete, y son invisibles para los usuarios funcionales reales de la aplicación. En la práctica de medición de tamaño funcional, un sistema operativo nunca sería considerado como un usuario funcional de una aplicación.

Pero no siempre se da el caso de que lo usuarios funcionales sean obvios.


27

Ejemplo 2: Tomemos el ejemplo de la aplicación software de un teléfono móvil (se mencionó por primera vez en la Introducción). A pesar de que hemos eliminado el sistema operativo del teléfono móvil como un posible usuario funcional de la aplicación, los usuarios podrían ser (a) los seres humanos que pulsan las teclas, o (b) los dispositivos de hardware (por ejemplo, la pantalla, teclado, etc.) y aplicaciones semejantes que interactúan directamente con la aplicación del teléfono. El usuario humano, por ejemplo, verá sólo un subconjunto de toda la funcionalidad de la que debe ser provista a fin de que la aplicación del teléfono móvil funcione. Por lo tanto, estos dos tipos de usuarios verán diferente funcionalidad, el tamaño de los FUR para los usuarios humanos será menor que el tamaño de los FUR que deben desarrollarse para hacer la aplicación de teléfono funcione.

Reglas – Usuarios Funcionales

a) Los usuarios funcionales de una aplicación software que se hayan de medir se derivan del propósito de la medición

b) Cuando el propósito de una medición de una aplicación software está relacionado con el esfuerzo para desarrollar o modificar el software, entonces los usuarios funcionales deben ser aquellos para los cuales se está modificando o proporcionando este nuevo software.

Una vez identificados los usuarios funcionales, entonces es sencillo determinar la frontera, ya que, simplemente se encuentra entre la pieza de software que se está midiendo y sus usuarios funcionales.

Definición – Frontera

La Frontera se define como un interfaz conceptual entre el software que está siendo medido y sus usuarios funcionales.

Nota: La frontera de una aplicación software es la línea divisoria conceptual entre esta pieza y el medio en el que opera, ya que se percibe externamente desde la perspectiva de sus usuarios funcionales. La frontera permite que el medidor distinga, sin ambigüedad, lo que se incluye dentro del software a ser medido de lo que es parte del medio en el que opera el software.

Nótese, que esta definición de frontera está tomada de la norma ISO/IEC 14143/1:2007, modificada por la adición de la palabra ‘funcional’ para calificar al ‘usuario’. Para evitar la ambigüedad, tenga en cuenta que la frontera no debe confundirse con ninguna línea que pueda dibujarse alrededor de ningún programa que deba ser medido para definir el alcance de la medición. La frontera no se utiliza para definir el alcance de la medición.

Las siguientes reglas podrían ser útiles para confirmar la condición de una posible frontera:

Reglas – Frontera

a) Identificar los usuarios funcionales que interactúan con el software que se mide. La frontera se encuentra entre los usuarios funcionales y este software.

b) Por definición, hay una frontera entre cada par de capas identificadas donde el software en una capa es el usuario funcional del software en otra capa, y este último va a ser medido.

c) Hay una frontera entre dos partes cualquiera de un programa, incluidos los componentes que son semejantes entre sí; en este caso cada parte de programa y/o cada componente puede ser un usuario funcional de su semejante.

La frontera permite establecer una distinción clara entre todo lo que forma parte de la aplicación software que va a ser medida (es decir, que se encuentra en la zona de software de la frontera) y todo lo que forma parte del medio de los usuarios funcionales (es decir, que se encuentra en la zona del usuario funcional de la frontera). Los almacenes persistentes no se consideran como un usuario del software y, por tanto, se encuentran en la zona del software de la frontera.


28

2.4 Identificando el nivel de granularidad

2.4.1 La necesidad de un nivel de granularidad estándar

Cuando se comienza un proyecto para diseñar y construir una nueva casa, los primeros planos de un arquitecto se encuentran en la casa en una situación de “alto nivel”, es decir, que muestran un esquema y pocos detalles. A medida que el proyecto avanza hacia la fase de construcción, se necesitan los planos más detallados (“bajo nivel”).

Lo mismo puede decirse para el software. En las etapas iniciales de un proyecto de desarrollo de software, los requisitos funcionales de los usuarios (FUR) se especifican en alto nivel, es decir, en el esbozo, o en pocos detalles. A medida que el proyecto progresa, los FUR, son refinados, (por ejemplo, a través de las versiones 1, 2, 3, etc.), revelando más detalle a un menor nivel. Estos diferentes grados de detalle de los FUR, son conocidos con los diferentes “niveles de granularidad”. (Véase también la sección 2.4.3 para otros términos que pueden confundirse con el concepto de nivel de granularidad como es definido aquí).

Definición – Nivel de granularidad

Cualquier nivel de expansión de la descripción de una sola aplicación software (por ejemplo, una declaración de requisitos, o una descripción de la estructura de la aplicación software) de tal manera que a cada aumento del nivel de expansión, la descripción de la funcionalidad de la aplicación software se encuentra en un nivel de detalle mayor y uniforme.

Nota: Los medidores deben ser conscientes de que cuando los requisitos van apareciendo a principios de la vida de un proyecto de software, diferentes partes de la funcionalidad necesaria del software normalmente se habrán documentado en los diferentes niveles de granularidad.

Los planos de construcción de viviendas usan escalas estándar, y es fácil traducir dimensiones de en un dibujo a otro dibujo realizado con una escala distinta. En cambio no hay escalas estándar para los diversos niveles de granularidad con que el software puede ser especificado, por lo que puede ser difícil tener la certeza de que dos declaraciones de los requisitos funcionales de los usuarios (FUR) se encuentran al mismo nivel de granularidad. Sin un acuerdo en algún nivel de granularidad de a que escala se debe medirse es imposible saber con certeza que dos mediciones de tamaño funcional pueden compararse. Y los medidores tienen que desarrollar su propio método para pasar las mediciones de un nivel de granularidad a otro.

Para ilustrar aún más los problemas, consideremos otra analogía. Un conjunto de mapas de carreteras revela los detalles de una red nacional de carreteras en tres niveles de granularidad.

• Mapa A muestra sólo las autopistas y carreteras principales • Mapa B muestra todas las carreteras principales y carreteras secundarias (como en un atlas para

los automovilistas), • Mapa C muestra todas las carreteras secundarias (como en una serie de mapas del distrito local),

Si no reconocemos el fenómeno de los diferentes niveles de granularidad, parece que se exponen tres mapas diferentes de la red de carreteras de la nación. Por supuesto, con mapas de carreteras todo el mundo reconoce los diferentes niveles de detalle y hay escalas estándar para interpretar el tamaño de la red descrita en cualquier nivel. El concepto abstracto de nivel de granularidad se esconde detrás de las escalas de estos mapas distintos.

Para la medición del software, sólo hay un nivel de granularidad que es posible definir sin ambigüedades. Es el nivel de granularidad en el cual se han identificado los distintos procesos funcionales y se han definido sus movimientos de datos. Las mediciones deben hacerse a este nivel o a escala de este nivel siempre que sea posible.


29

2.4.2 Aclaración del nivel de granularidad

Antes de continuar, es importante asegurar que no haya malentendidos sobre el significado de nivel de granularidad en el método COSMIC. Tal como se define aquí, la ampliación de la descripción de software de un nivel de granularidad “superior” a uno “inferior” implica revelar más detalles pero sin modificar su alcance. Este proceso no debe confundirse con cualquiera de los siguientes.

• Detallar un artefacto que describa algún tipo de software a fin de revelar diferentes sub-conjuntos de la funcionalidad entregada a los diferentes usuarios, por lo tanto, probablemente limitando la funcionalidad que debe medirse

• Detallar un artefacto que describa algún tipo de software, o el propio software y, al mismo tiempo descomponerlo a fin de revelar la estructura de sus componentes, sub-componentes, etc. (es decir, revelar los diferentes niveles de descomposición - véase la sección 2.2.2). Detallar a niveles más bajos la descomposición del software puede dar lugar (a partir de los efectos de la medición) en sub-dividir el alcance global de la medición

• Mostrar la descripción de algún tipo de software a medida que avanza su ciclo de desarrollo, por ejemplo, de los requisitos al el diseño lógico, diseño físico, etc. Cualquiera que sea la fase del desarrollo de algún software, sólo estamos interesadas en los FUR para propósitos de medición.

El concepto de “nivel de granularidad” se aplica únicamente a los requisitos de los usuarios funcionales de software (FUR). Otras formas de detallar software o sus diversas descripciones también pueden ser muy importantes cuando se utilizan para comparar las mediciones de tamaño funcional. Estos serán tratados en el documento “Temas Avanzados y Relacionados, v3.0”, en el capítulo “Garantizando la Comparación de Mediciones de Tamaño”.

2.4.3 El nivel de granularidad estándar

El nivel de granularidad estándar para la medición es el “nivel de proceso funcional” y se define como sigue:

Definición – Nivel de Granularidad de un Proceso fu ncional

Un nivel de granularidad de la descripción de aplicación software en el que los usuarios funcionales:

a) Son humanos individuales o dispositivos de ingeniería o elementos de software (y no grupos de estos) Y

b) detectan ocurrencias únicas de eventos a los que la aplicación software debe responder (y no cualquier nivel en el cual se han definido grupos de eventos)

Nota 1: En la práctica, la documentación de software que contiene las necesidades de los usuarios funcionales a menudo describe la funcionalidad en diferentes niveles de granularidad, sobre todo cuando la documentación aún está en construcción.

Nota 2: Grupos de usuarios funcionales podrían ser, por ejemplo, un departamento cuyos miembros manejan muchos tipos de procesos funcionales, o un panel de control que tiene muchos tipos de instrumentos.

Nota 3: Un grupo de casos puede, por ejemplo, indicarse en una declaración de FUR en un alto nivel de granularidad de un flujo de entrada a un sistema de software de contabilidad, etiquetados como transacciones de venta, o de un flujo de entrada a un sistema de software de aviónica, etiquetado como comandos del piloto.

Con esta definición, podemos ahora definir las siguientes reglas y una recomendación.

Reglas – Nivel de granularidad de un proceso funcio nal

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


30

b) Cuando se necesita la medida del tamaño funcional de algunos FUR que no han evolucionado aún a un nivel al cual se hayan identificado sus procesos funcionales y no se hayan definido aún los detalles de todos sus movimientos de datos, las mediciones deberían ser hechas a partir de la funcionalidad que ha sido definida, y después escalada a un nivel de granularidad de procesos funcionales. (Ver el documento “Aspectos Avanzados y Relacionados” para los métodos de “medición aproximada, es decir, estimando el tamaño funcional de forma temprana en el proceso de establecer los FUR).

Además de las reglas, COSMIC recomienda que el nivel de granularidad de un proceso funcional deba ser el estándar al que se requiera medir el tamaño funcional cuando sea utilizado por los proveedores para una evaluación comparativa de los servicios y de las herramientas de software diseñados para sostener o utilizar las mediciones de tamaño funcional, por ejemplo para estimar el esfuerzo de un proyecto.

Ejemplo: Funcionalidad en diferentes niveles de granularidad

El ejemplo, del dominio de software de gestión, será de un conocido sistema de comprar productos a través de Internet, que llamaremos el sistema “Everest”. (El documento de “Temas Avanzados y Relacionados” contiene un ejemplo del dominio de software de tiempo real.). La descripción que figura a continuación está muy simplificada para los propósitos de esta ilustración de los niveles de granularidad. La descripción también cubre únicamente a las funcionalidades disponibles para los usuarios del "Everest". Por lo tanto, excluye las funcionalidades que deben estar presentes para que el sistema pueda completar la entrega de bienes a un cliente, tales como la funcionalidad disponible para el personal de "Everest", proveedores de productos, anunciantes, el pago los proveedores de servicios, etc.

El alcance de la medición, por lo tanto, se define como las partes del sistema de aplicación "Everest" accesibles a los clientes a través de Internet. Asumimos que el objetivo de la medición es determinar el tamaño funcional de la aplicación a disposición los usuarios humanos (como usuarios funcionales). Al más alto “nivel 1” la definición de todos los requisitos funcionales de los usuarios (RUF) del sistema de compra "Everest" sería una simple declaración como la siguiente.

“El sistema Everest deberá permitir a los clientes informarse sobre, seleccionar, pedir, pagar y obtener la entrega de cualquier elemento de la gama de productos Everest, incluidos los productos disponibles desde terceros proveedores.”

Detallando esta declaración de más alto nivel más nos encontramos con que en el próximo nivel inferior 2, el sistema consiste en cuatro sub-sistemas, tal y como se muestra en Fig. 2.4.3.1.


31

EverestOrderingSystem

OrderFollow-up

Sub-system

AccountMaintenance

System

Checkout/Payment

Sub-system

Enquiry/Order

Sub-system

Review, maintainconfirm order

Sub-sub-system

Select delivery/packaging optionsSub-sub-system

Pay for orderSub-sub-system

Display & e-mailorder confirmationSub-sub-system

Register newcustomerprocess

Pay for orderprocess

Maintainpayment methodSub-sub-system

Maintaincustomer detailsSub-sub-system

Delete existingmeans-of-payment

process

Add newmeans-of-payment

process

Level 1

Level 2

Level 3

Level 4

Enquire oncurrent

order process

Enquire onhistoric

orders process

Returned goodsSub-sub-system

(not analyzed)

(not analyzed) (n/a) (n/a) (n/a)


OrderFollow-up

Sub-system

AccountMaintenance

System

Checkout/Payment

Sub-system

Enquiry/Order

Sub-system


OrderFollow-up

Sub-system

AccountMaintenance

System

Checkout/Payment

Sub-system

Enquiry/Order

Sub-system

Review, maintainconfirm order

Sub-sub-system

Select delivery/packaging optionsSub-sub-system

Pay for orderSub-sub-system

Display & e-mailorder confirmationSub-sub-system





Maintainpayment methodSub-sub-system

Maintaincustomer detailsSub-sub-system


process


process


process


process

Level 1

Level 2

Level 3

Level 4

Enquire oncurrent

order process

Enquire onhistoric

orders process

Returned goodsSub-sub-system

(not analyzed)

(not analyzed) (n/a)(n/a) (n/a)(n/a) (n/a)(n/a)

Figura 2.4.3.1 – Análisis parcial del Sistema Everest con cuatro niveles de análisis

Los cuatro sub-sistemas son los siguientes:

• El sub-sistema de la Solicitud/Orden que permite a un cliente encontrar cualquier producto en la base de datos de Everest, así como su precio y disponibilidad y añadir cualquier producto seleccionado a una cesta de compra. Este sub-sistema también promueve las ventas sugiriendo las ofertas especiales, que ofrece comentarios de los elementos seleccionados y permite preguntas generales como las condiciones de entrega, etc. Se trata de un sub-sistema muy complejo y no es analizado en más detalle por debajo del nivel 2 a efectos del presente ejemplo.

• El sub-sistema de la compra/pago que permite a un cliente comprometerse con el pedido y pagar por la mercancía de la cesta.

• El sub-sistema del Seguimiento del pedido que permite a un cliente a preguntar hasta qué punto un pedido existente ha avanzado en el proceso de entrega, para mantener su pedido (por ejemplo, cambiar la dirección de entrega) y para devolver bienes no satisfactorios.

• El sub-sistema del Mantenimiento de la cuenta que permite a un cliente existente, mantener diversos detalles de su cuenta tales como domicilio, medios de pago, etc.

La figura 2.4.3.1 también muestra algún detalle que se pone de manifiesto cuando detallamos los otros dos niveles del sub-sistema de La Compra/Pago, del Seguimiento del Pedido y el subsistema de Mantenimiento de la Cuenta. En este proceso, es importante señalar que:

• no hemos cambiado el alcance del sistema de la aplicación que habrá de medirse, y

• todos los niveles de la descripción del sistema de software "Everest" muestran la funcionalidad disponible para los clientes (como los usuarios funcionales). Un cliente puede ver la funcionalidad del sistema en todos estos los niveles de análisis

La figura 2.4.3.1 revela también que cuando detallamos niveles más bajos de este análisis de los tres sub-sistemas, nos encontramos con los distintos procesos funcionales en el nivel 3 (para dos consultas del sub-sistema de Seguimiento del Pedido) y en el nivel 4 para los otros dos sub-sistemas. Este ejemplo demuestra, por tanto, que cuando alguna funcionalidad es analizada en un enfoque de arriba abajo, no se puede suponer que la funcionalidad mostrada en un nivel en un diagrama se corresponde siempre con el mismo nivel de granularidad tal y como este concepto es definido en el método COSMIC. (Esta definición exige que a cualquier nivel de granularidad la funcionalidad esté a un “nivel comparable de detalle”).


32

Por otra parte, otros analistas podrían dibujar el diagrama de forma diferente, mostrando otras agrupaciones de funcionalidades en cada nivel del diagrama, ya que no hay una única forma correcta de analizar la funcionalidad de un sistema.

Teniendo en cuenta estas variaciones que inevitablemente ocurren en la práctica, un medidor debe examinar cuidadosamente los diversos niveles de un diagrama de análisis para encontrar los procesos funcionales que deben medirse. En caso de que en la práctica esto no sea posible, por ejemplo debido a que el análisis aún no ha alcanzado el nivel donde todos los procesos funcionales se han revelado, debe aplicarse la regla (b) descrita más arriba. Para ilustrar esto, vamos a examinar el caso del sub-subsistema Mantener Detalles del Cliente (véase la figura 2.4.3.1), en la primera rama de el sub-sistema de Mantenimiento de la Cuenta.

Para un medidor con experiencia, la palabra mantener casi siempre sugiere un grupo de casos y por lo tanto, un grupo de procesos funcionales. Por lo tanto, podemos asumir con seguridad que este sub-subsistema de mantener debe estar integrado por tres procesos funcionales, es decir, base de datos de detalles del cliente, actualización de los detalles del cliente y eliminar el cliente. (Evidentemente el proceso de creación del cliente también existe pero esto ocurre en otra rama del sistema, que es cuando un cliente hace un pedido por primera vez. Está fuera del ámbito de aplicación de este ejemplo).

Un medidor con experiencia debe poder estimar un tamaño de este sub-subsistema en unidades PFC tomando el supuesto número de procesos funcionales (tres en este caso) y multiplicando este número por el tamaño medio de un proceso funcional. Este tamaño medio se obtendría calibrando en otras partes de este sistema o en otros sistemas comparables. Ejemplos de este proceso de calibración se dan en el documento de “Temas Avanzados y Relacionados” que en la aproximación de mediciones contiene también otras aproximaciones al tamaño aproximado.

Evidentemente, estos métodos de aproximación tienen sus limitaciones. Si aplicamos este enfoque al nivel 1 de la declaración FUR de la forma arriba señalada (El sistema "Everest" deberá permitir a los clientes informarse sobre, seleccionar, comprar, pagar y obtener la entrega de cualquier elemento de la gama de productos Everest….), podríamos identificar unos procesos funcionales. Pero un análisis más detallado podría revelar que el verdadero número de procesos funcionales de este complejo sistema debe ser mucho mayor. Esa es la razón por la que tamaños funcionales aparentan aumentar a medida que se establecen más detalles en los requisitos, incluso sin cambios en el alcance de la aplicación. Estos métodos de aproximación, por lo tanto, deben ser utilizados con sumo cuidado a los altos niveles de granularidad, cuando está disponible muy poca información.

El documento de “Temas Avanzados y Relacionados” da un tipo diferente de ejemplo de medición en diversos niveles de granularidad, es el caso de un tipo de software que es parte de una arquitectura de software de telecomunicaciones. Este ejemplo es más complejo que el “Everest” ya que los usuarios funcionales de parte de la arquitectura que se está midiendo son el resto de las otras partes de software de la misma arquitectura. Este ejemplo, por lo tanto, también se ocupa de diversos niveles de descomposición del software que se está midiendo y de sus usuarios funcionales.

2.5 Observaciones finales sobre la Fase de Estrateg ia de la de Medición

Si se consideran cuidadosamente los cuatro elementos del proceso de estrategia de medición antes de empezar una medición se debería asegurar que el tamaño resultante pueda ser interpretado correctamente. Los cuatro elementos son los siguientes:

a) establecer el propósito de la medición b) definir el alcance global de la aplicación software a medir y el alcance de las partes a ser medidas

por separado, teniendo en cuenta las capas y los componentes semejantes de la arquitectura de software

c) establecer los usuarios funcionales de la aplicación software medida d) establecer el nivel de granularidad de los artefactos de software a medir y cómo, si es necesario,

llevar las medidas a al estándar de nivel de granularidad de proceso funcional

Pueden ser necesarias algunas repeticiones de los pasos (b), (c) y (d) cuando están evolucionando los requisitos y los nuevos datos indican la necesidad de perfeccionar la definición del alcance.

La gran mayoría de las mediciones de tamaño funcional se llevan a cabo con una finalidad que está relacionada de algún modo con el esfuerzo de desarrollo, por ejemplo, para la medición del


33

rendimiento de los desarrolladores, o para la estimación del proyecto. En estas situaciones, la definición de la estrategia de medición debe ser muy sencilla. El propósito y el alcance son generalmente fáciles de definir, los usuarios son los usuarios funcionales para los cuales el desarrollador debe proporcionar la funcionalidad y el nivel de granularidad en que se requieren las mediciones es el nivel en el cual los usuarios funcionales detectan eventos individuales.

Sin embargo, no todas las mediciones se ajustan a esta pauta común, por lo que la estrategia de medición debe ser definida para en cada situación.


34

33 FASE DE REPRESENTACIÓN

Este capítulo presenta las reglas y el método para el proceso de representación. El método general para la representación del software en el Modelo COSMIC Genérico del Software se resume en la figura 3.0.

FUR in the formof the COSMIC

Generic SoftwareModel

Section 3.2

IDENTIFYDATA

GROUPSSection 3.3 (*)

IDENTIFYDATA

ATTRIBUTES

COSMIC MAPPING PHASE

Section 3.1

IDENTIFYFUNCTIONAL PROCESSES

(*): This step is not a mandatory part of the COSMIC method.

Chapter 2

PURPOSE, SCOPE,FUNCTIONAL USERS &

LEVEL OF GRANULARITYof the piece of software

to be measured

Functional User Requirements

in the artefactsof the software

to be measured





Section 3.2

IDENTIFYDATA

GROUPS

Section 3.2

IDENTIFYDATA

GROUPSSection 3.3 (*)

IDENTIFYDATA

ATTRIBUTES

Section 3.3 (*)

IDENTIFYDATA

ATTRIBUTES

COSMIC MAPPING PHASE

Section 3.1


Section 3.1


(*): This step is not a mandatory part of the COSMIC method.

Chapter 2



to be measured

Chapter 2Chapter 2



to be measured



to be measured



to be measured



to be measured

Figure 3.0 – Método General del proceso de mapeo CO SMIC

Cada paso de este método es el tema de una sección específica (indicada en el título de cada paso de la figura 3) donde se presentan las definiciones y las reglas, junto con algunos principios que sirven de guía y ejemplos.

El método general resumido en la figura 3 de arriba se ha diseñado para ser aplicado a una muy amplia gama de artefactos de software. Un proceso más sistemático y detallado proporcionaría reglas precisas de representación para una mayor cantidad de artefactos altamente específicos, por lo que se disminuiría el nivel de ambigüedad al generar el Modelo Genérico COSMIC de Software. Un proceso así sería, por definición, altamente dependiente de la naturaleza de los artefactos, lo que depende de la metodología de ingeniería del software que se use en cada organización.

El documento “Guía para Medir Aplicaciones de Gestión utilizando COSMIC” sirve de guía en la representación desde varios datos de análisis y métodos de obtención de requisitos usados en el dominio de las aplicaciones de gestión a los conceptos del método COSMIC.


35

3.1 Aplicación del Modelo Genérico COSMIC de softwa re

Principio – Aplicando el Modelo Genérico COSMIC de Software

El Modelo Genérico COSMIC de Software se aplicará de forma separada a cada parte de los requisitos funcionales de usuario para la cual se ha definido un alcance de la medición.

“Aplicar el Modelo Genérico COSMIC de Software” significa identificar el conjunto de eventos desencadenadores detectados por cada (tipo de) usuario funcional identificado en los FUR para, a continuación, identificar los correspondientes procesos funcionales, objetos de interés, grupos de datos y los movimientos de datos que deben ser proporcionados para responder a esos eventos.

Las figuras 3.1.1 y 3.1.2 de abajo ilustran respectivamente, la aplicación del principio (g) del Modelo de Contexto del Software y los principios del Modelo Genérico del Software a una aplicación de gestión y a un típico software empotrado de tiempo real.

Mientras que las figuras 2.2.3.1 y 2.2.3.2 de arriba mostraban visiones físicas reales de las arquitecturas a capas del software, las figuras 3.3.1 y 3.1.2 muestran una visión lógica de las relaciones de varios conceptos definidos en los modelos COSMIC. En esta visión lógica los usuarios funcionales interaccionan con el software que va a ser medido a través de una frontera vía movimientos de datos de Entrada y de Salida. El software mueve datos hacia y desde los almacenes persistentes vía movimientos de datos de Escritura y Lectura respectivamente. En estas visiones lógicas se ignora todo el hardware y software que se necesita para permitir que estos intercambios tengan lugar entre el software que se está midiendo, sus usuarios funcionales y el almacenamiento persistente.

Applicationbeing

measured

A ‘peer’application

functional user The

application

layer

Boundary

Humanfunctionaluser (s)

E

Entries

Exits

Reads Writes

Boundary

Persistentstorage

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

Applicationbeing

measured

A ‘peer’application

functional user The

application

layer

BoundaryBoundary

Humanfunctionaluser (s)

E

Entries

Exits

Reads Writes

Boundary

Persistentstorage

X

X EX 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 Indicates a message that is issued as an Exit data movement, crosses a boundary, and is received as an Entry data movement

X E

Figure 3.1.1 – Una aplicación de gestión con seres humanos y otras aplicaciones ‘semejantes’, como sus usuarios funcionales (vista lógica)


36

The

‘Application

Layer’

Applicationbeing

measured

Boundary

Hardwareengineered

deviceFunctionalUser (s)

Entries

Exits

Reads Writes

PersistentStorage

The

‘Application

Layer’

Applicationbeing

measured

BoundaryBoundary

Hardwareengineered

deviceFunctionalUser (s)

Entries

Exits

Reads Writes

PersistentStorage

Figura 3.1.2 – Una aplicación en tiempo real con va rios dispositivos hardware integrados como usuarios funcionales (vista lógica)

3.2 Identificación de los procesos funcionales

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

3.2.1 Definiciones

Definición – Proceso funcional

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

Nota: Además de informar al componente de software de que el evento ha ocurrido, la “entrada desencadenante” puede incluir datos sobre el objeto de interés asociado al evento.

Definición – Evento desencadenante

Un evento (algo que ocurre) que causa un usuario funcional del componente de software para iniciar (“trigger”) uno o más procesos funcionales. En un conjunto de requisitos funcionales de usuario, cada evento que causa que un usuario funcional desencadene un proceso funcional:

• no puede ser sub-dividido para ese conjunto de FUR, y • ha ocurrido o no ha ocurrido

Nota: El reloj y los eventos de tiempo pueden ser eventos desencadenantes.


37

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

Triggeringevent

is sensed by

TriggeringEntry

Boundary

Functionaluser

Functionalprocess

Triggeringevent

is sensed by

TriggeringEntry

Boundary

Functionaluser

Functionalprocess

Figura 3.2.1 – Relación entre un evento disparador, un usuario funcional y un proceso funcional

La Entrada desencadenante es normalmente un mensaje positivo e inequívoco que informa al software de que el usuario funcional ha identificado un evento desencadenante. La Entrada desencadenante usualmente incluye también datos sobre un objeto de interés asociado con el evento. Después de que se ha recibido la Entrada desencadenante, se puede requerir un proceso funcional para recibir y procesar otras Entradas que describen otros objetos de interés.

Si un usuario funcional envía datos incorrectos, por ejemplo porque un sensor no funciona o una orden introducida por un humano tiene errores, es habitualmente tarea del proceso funcional determinar si un evento realmente ocurrió y/o si los datos introducidos son realmente válidos y cómo responder.

3.2.2 La aproximación para identificar procesos funcionales

La aproximación para identificar procesos funcionales depende de los artefactos de software que están disponibles para el medidor, los cuales dependen del momento del ciclo de vida del software cuando se requiere la medida y de los métodos de análisis, diseño y desarrollo del software en uso. Puesto que éstos últimos varían enormemente, incluso dentro del un dominio de software dado, está fuera del alcance de este Manual de Medida el proporcionar uno o más procesos generales para identificar procesos funcionales.

La “Guía para medición de aplicaciones de gestión software usando COSMIC”, sección 4.4 da más reglas y ejemplos sobre cómo identificar y distinguir procesos funcionales en el dominio de las aplicaciones software de gestión.

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

Utilice las siguientes reglas para comprobar que los procesos funcionales candidatos han sido adecuadamente identificados.

Reglas – Proceso funcional

a) En proceso funcional se derivará de al menos un Requisito Funcional de Usuario identificable dentro del alcance acordado

b) Un proceso funcional se llevará a cabo cuando ocurra un evento desencadenante


38

identificable c) Un evento específico puede desencadenar uno o más procesos funcionales que se

ejecutan en paralelo. Un proceso funcional puede ser desencadenado por más de un evento

d) Un proceso funcional constará de al menos dos movimientos de datos, una Entrada más una Salida o una Escritura

e) Un proceso funcional pertenecerá enteramente una, y solo una, capa o estrato del software

f) En el contexto de software a tiempo real, un proceso funcional se considerará terminado cuando entre en un estado de espera auto inducido (por ejemplo el proceso funcional ha hecho todo lo requerido en respuesta al evento desencadenante y espera hasta recibir la próxima Entrada desencadenante)

g) Un proceso funcional se identificará incluso si sus FUR permiten que el proceso funcional pueda ocurrir con diferentes sub-series de su máximo número de atributos de datos de entrada, e incluso aunque dichas variaciones y/o valores de datos de entrada distintos puedan dar lugar a diferentes rutas de procesamiento a través del proceso funcional.

h) Se deberían distinguir Eventos diferentes y por tanto Procesos Funcionales diferentes en los siguientes casos:

• Cuando las decisiones resultan en eventos separados que están desconectados en el tiempo (por ejemplo meter datos de una orden hoy y después confirmar que se acepta la orden, requiriendo una decisión separada, debería ser considerado como indicativo de procesos funcionales separados)

• Cuando las responsabilidades de actividades están separadas (por ejemplo en un sistema personal donde la responsabilidad para mantener datos personales básicos está separada de la responsabilidad del mantenimiento de datos de nóminas, indicando procesos funcionales separados; o para un paquete de software puesto en marcha donde hay funcionalidad disponible para un administrador del sistema para mantener los parámetros del paquete, lo que está separado de la funcionalidad disponible para el usuario funcional “habitual”.

3.2.3 Eventos disparadores y procesos funcionales en el ámbito de aplicaciones de negocio

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

Ejemplo 1: En una compañía, se recibe una orden (evento desencadenante), causando que un empleado (usuario funcional) meta los datos de la orden (Entrada desencadenante que comunica datos sobre el objeto de interés “orden”), como el primer movimiento de datos del proceso funcional “entrada de orden”

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

Ejemplo 2: Supóngase que al recibir una orden en el ejemplo a) a la aplicación de la orden se la requiere que envíe detalles del cliente a una aplicación central de registro de clientes, lo cual se está midiendo. Ahora la aplicación de la orden se ha convertido en un usuario funcional de la aplicación central. La aplicación de la orden detecta el evento de recepción de los datos del cliente y desencadena un proceso funcional en la aplicación central del registro de clientes para almacenar estos datos, enviando datos sobre el objeto de interés “cliente” como una Entrada desencadenante a la aplicación central.

c) No hay diferencia en el principio para el análisis de un proceso funcional si se requiere un procesamiento on-line o un tratamiento por lotes. El procesamiento durante la noche es una decisión de puesta en marcha técnica, y “todo lo que se requiere hacer” no ha ocurrido hasta que


39

el proceso durante la noche se haya completado. Un flujo de procesado por lotes consiste en uno o más procesos funcionales, cada uno de los cuales debería ser analizado “end-to-end”, independientemente de cualquier otro proceso funcional en el mismo flujo. Cada proceso funcional tiene su propia Entrada desencadenante que debe medirse.

Ejemplo 3: Supóngase que las órdenes del ejemplo de a) se meten on-line pero son almacenadas para un procesado por lotes automático durante la noche. El usuario funcional es todavía el humano que metió las órdenes on-line; la Entrada desencadenante son todavía los datos de la orden. Hay un proceso funcional por entrada y procesado de las órdenes.

d) Las señales periódicas de un reloj (ticks) pueden físicamente desencadenar un proceso funcional.

Ejemplo 4: Supóngase un FUR para un proceso por lotes a final de año para informar de los resultados del negocio durante el año y para reajustar puestos para comienzos del año que viene. Físicamente, el tick de fin de año de un reloj originado por el sistema operativo ocasiona que el flujo por lote comience, consistiendo en uno o más procesos funcionales. Estos procesos funcionales del flujo que usan datos de entrada en el flujo deberían ser analizados de modo normal (por ejemplo los datos de entrada para cualquier proceso funcional constan de una o más Entradas, la primera de las cuales es la Entrada desencadenante de dicho proceso).

Sin embargo, se asúmase que hay un proceso funcional particular en el flujo que no requiere ningún dato de entrada para producir sus series de informes. Físicamente, el usuario funcional (humano) ha delegado en el sistema operativo la tarea de desencadenar este proceso funcional. Puesto que todos los procesos funcionales deben tener una Entrada desencadenante, podríamos considerar que el tick de fin de año del reloj que comenzó el flujo por lotes desempeña este papel para este proceso. El proceso funcional podría entonces necesitar diferentes Lecturas y muchas Salidas para producir sus informes. Lógicamente, el análisis de este ejemplo no es diferente si el usuario funcional inicia la producción de uno o más informes vía un clic del ratón en un icono del menú on-line, en vez de delegar la producción del informe al sistema operativo vía flujo por lotes.

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

Ejemplo 5: Un tick de reloj de fin de semana produce que comience la generación de informes y el proceso de revisión de la caducidad de los límites de tiempo en un sistema automático.

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

Ejemplo 6: En un sistema bancario, un extracto de cuenta puede ser desencadenado por un proceso por lotes de fin de mes pero también porque un cliente específico lo haya pedido.

Para diversos ejemplos de cómo distinguir eventos desencadenantes y procesos funcionales en flujos por lotes, ver la “Guía de Medición de Aplicaciones de Gestión utilizando COSMIC” en la sección 4.6.3.

3.2.4 Ejemplos en el dominio de aplicaciones en tiempo real.

a) Un evento desencadenante es detectado típicamente por un sensor

Ejemplo 1: Cuando la temperatura alcanza un valor determinado (evento desencadenante), se produce que un sensor (usuario funcional) envíe una señal (movimiento de datos de Entrada desencadenante) para encender una luz de alarma (proceso funcional).

Ejemplo 2: Un avión militar tiene un sensor que detecta el evento “un misil se acerca”. El sensor es un usuario funcional del software integrado que debe responder a la amenaza. Para este software, solo cuando el sensor detecta algo ocurre un evento, y es el sensor (el usuario funcional) el que pone en funcionamiento al software enviándole un mensaje (Entrada desencadenante) diciendo por ejemplo: “el sensor 2 ha detectado un misil”, además quizás también envía un flujo de datos sobre la velocidad del misil que se acerca y sus coordenadas. El misil es el objeto de interés.


40

b) Señales periódicas de una reloj (ticks de reloj) pueden desencadenar un proceso funcional

Ejemplo 3: En algún software de control de procesos en tiempo real, un tick (evento desencadenante) de un reloj (usuario funcional) produce que el reloj envíe una señal (Entrada desencadenante), un mensaje de un bit que le dice al proceso funcional que repita su ciclo de control normal. El proceso funcional entonces lee varios sensores, recibiendo datos sobe objetos de interés, y lleva a cabo cualquier acción necesaria. No hay otros datos que acompañen el tick del reloj.

c) Un solo evento puede desencadenar uno o más procesos funcionales que se ejecuten independientemente en paralelo

Ejemplo 4 Un situación de emergencia detectada en una central nuclear puede desencadenar procesos funcionales independientes en zonas diferentes de la central para bajar las barreras de control, accionar el enfriamiento de emergencia, cerrar válvulas, hacer sonar las alarmas para alertar a los operarios, etc.

d) Un solo proceso funcional puede ser desencadenado por más de un evento desencadenante.

Ejemplo 5: La retracción en las ruedas de un avión puede ser desencadenada por el detector “sin peso en el suelo” o por una orden del piloto.

3.2.5 Más sobre procesos funcionales separados

El software diferencia eventos y proporciona los correspondientes procesos funcionales dependiendo solo de sus FUR. Al medir el software puede a veces ser difícil decidir qué eventos separados se requiere que el software reconozca. Este es especialmente el caso cuando los FUR originales no están ya disponibles y cuando, por ejemplo, los que fabrican el software haya visto que es económico combinar varios requisitos. Podría ayudar con el análisis examinar la organización de los datos de entrada (ver abajo) o examinar los menús de algún software instalado para ayudar a distinguir los eventos separados a los que el software debe responder y los correspondientes procesos funcionales.

Ejemplo 1: Cuando hay un requisito de un usuario funcional para reducción de impuestos por un hijo adicional y también por “créditos por tasas de trabajo” para los que tienen un sueldo bajo, estos son requisitos a los que el software debe responder como dos eventos separados en el mundo de los usuarios funcionales humanos. Por tanto, debería haber dos procesos funcionales, aunque solo se haya utilizado un formulario de impuestos para recoger los datos en ambos casos.

Ejemplo 2: Si el salario en un ejemplo (para una persona) excede el límite por créditos por tasas de trabajo en reducción de impuestos y en otro ejemplo (para otra persona) no lo excede, esta diferencia no da lugar a dos procesos funcionales separados, pero indica dos condiciones separadas de las que encargarse en el único proceso funcional.

Ejemplo 3: Como ejemplo de la regla (g), si ocurre una incidencia específica que desencadena la Entrada de un grupo de datos que consta de atributos de datos A, B y C, y los FUR permiten que otra incidencia del mismo evento desencadene una Entrada de un grupo de datos que tiene valores para los atributos A y B únicamente, esto no resulta en identificar dos procesos funcionales. Solo son identificados una Entrada y un proceso funcional, moviendo y manipulando atributos de datos A, B y C.

Una vez identificados, cada proceso funcional puede ser registrado en una línea individual, bajo la capa o estrato adecuado o bajo el componente semejante, en la matriz del Modelo Genérico de Software (apéndice A), bajo la correspondiente etiqueta.

3.2.6 El proceso funcional de componentes semejantes

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


41

Del proceso de cada medición (… definir el alcance, luego los usuarios funcionales y la frontera, etc.…), se deduce que si una parte del software consta de dos o más componentes similares, no puede haber ninguna superposición del alcance de medición de cada componente. El alcance de medición para cada componente debe definir un conjunto completo de procesos funcionales. Por ejemplo, no puede haber un proceso funcional con una parte en un alcance y otra parte en otro. De la misma manera, los procesos funcionales dentro del alcance de medición de un componente no saben de los procesos funcionales en el alcance de otro componente, incluso aunque se produzca el intercambio de mensajes entre dos componentes.

El usuario o usuarios funcionales de cada componente se determinan examinando dónde suceden los eventos que disparan los procesos funcionales del componente que está siendo examinado (la activación de eventos sólo puede ocurrir en el mundo de un usuario funcional).

La figura 4.1.8.2 ilustra el proceso funcional de dos componentes semejantes y los movimientos de datos que intercambian.

3.3 Identificación objetos de interés y grupos de d atos

3.3.1 Definiciones y principios

Este paso consiste en identificar grupos de datos referenciados por el software que se va a medir. Para identificar los grupos de datos, especialmente en el dominio de software de gestión, es habitualmente útil identificar los objetos de interés y probablemente también sus atributos. Los grupos de datos se mueven a “movimientos de datos”, los cuales serán identificados en el capítulo siguiente.

Definición – Objeto de interés

Cualquier “cosa” que sea identificada desde el punto de vista de los requisitos del usuario funcional. Puede ser cualquier cosa física, como también cualquier objeto conceptual o parte de un objeto conceptual en el mundo del usuario funcional sobre el que al software se le requiere que procese y/o almacene datos.

Nota: En el método COSMIC, el término “objeto de interés” se usa para evitar términos relacionados con métodos específicos de ingeniería del software. El término no implica “objetos” en el sentido usado en los métodos Orientados a Objetos.

Definición – Grupo de datos

Un grupo de datos es un conjunto único, no vacío, no ordenado y no redundante de atributos de datos donde cada atributo de datos incluido describe un aspecto complementario del mismo objeto de interés

Definición – Almacén persistente

Un almacén persistente es un almacén que permite a un proceso funcional almacenar un grupo de datos más allá de la vida del proceso funcional y/o del cual un proceso funcional puede recuperar un grupo de datos almacenado por otro proceso funcional, o almacenado por una ocurrencia anterior del mismo proceso funcional, o almacenado por otro proceso.

Nota 1: En el modelo COSMIC, debido a que el almacén persistente está en la parte del software de la frontera, no es considerado como un usuario del software.

Nota 2: Un ejemplo de “otros procesos” sería la manufactura de memoria de solo lectura.


42

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

Principios – grupo de datos

a) Cada grupo de datos identificado será único y distinguible a través de su colección única de atributos de datos

b) Cada grupo de datos estará directamente relacionado con un objeto de interés en los requisitos funcionales de usuario

c) Un grupo de datos será materializado dentro del ordenador que ejecuta el software

Una vez identificados, cada grupo de datos puede ser registrado en una columna individual en la matriz del Modelo Genérico de Software (apéndice A), bajo la correspondiente etiqueta.

3.3.2 Sobre la materialización de un grupo de datos

En la práctica, la materialización de un grupo de datos puede tomar muchas formas, por ejemplo:

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

b) Como una estructura física en la memoria volátil del ordenador (estructura de datos asignada dinámicamente o a través un bloque pre-asignado de espacio de memoria)

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

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

3.3.3 Sobre la identificación de objetos de interés y grupos de datos

Las definiciones y los principios de los objetos de interés y de los grupos de datos son intencionalmente amplios con el objetivo de que se puedan aplicar al rango más amplio posible de software. Esta cualidad hace que algunas veces resulte difícil de aplicar la definición y los principios cuando se mide una parte específica del software. Por tanto, los casos siguientes y los ejemplos se han diseñado para ayudar en la aplicación de los principios a casos específicos.

Al enfrentarnos a la necesidad de analizar un grupo de atributos de datos que son movidos dentro o fuera de un proceso funcional o que son movidos por un proceso funcional a o desde un almacén persistente, es de una importancia crítica decidir si todos los atributos comunican datos sobre un único “objeto de interés”, ya que es éste último el que determina el número de “grupos de datos” separados tal y como los define el método COSMIC. Por ejemplo, si los atributos de datos que van a ser los datos de entrada de un proceso funcional son atributos de tres objetos de interés separados, entonces necesitamos identificar tres movimientos de datos de Entrada separados.

Objetos de interés y grupos de datos en el dominio de las aplicaciones de gestión

Ejemplo 1: En el dominio de software de aplicaciones de gestión, un objeto de interés podría ser “empleado” (físico) o “pedido” (conceptual), asumiendo que se requiere que el software almacene datos sobre empleados o pedidos. En el caso de pedidos, normalmente desde el FUR de pedidos multilínea se identifican dos objetos de interés: “pedido” y “línea de pedido”. Los grupos de datos correspondientes podrían llamarse “datos de pedidos” o “línea de datos de pedidos”.

Los grupos de datos se forman cuando sea que haya una consulta ad hoc que pida datos sobre una “cosa” que no se tiene en el almacén persistente, pero que se puede derivar de datos que están en el almacén persistente. El movimiento de datos de Entrada en una consulta ad hoc (los parámetros de selección para derivar los datos requeridos) y el movimiento de datos de Salida (que contienen los atributos deseados), ambos mueven grupos de datos sobre dicha “cosa”. Estos son grupos de datos transitorios que no sobreviven a la ejecución del proceso funcional. Son grupos de datos válidos porque cruzan el límite o frontera entre el software y su usuario o usuarios.


43

Ejemplo 2: Dada un consulta ad hoc contra una base de datos personal para extraer una lista de nombres de todos los empleados de más de 35 años. La Entrada mueve un grupo de datos que contiene los parámetros de la selección. La Salida mueve un grupo de datos que contiene solo el atributo “nombre”; el objeto de interés (o “cosa”) es “todos los empleados de más de 35 años”. Es importante al grabar el proceso funcional nombrar claramente un grupo de datos transitorios en relación con su objeto de interés, mejor que relacionarlo con el objeto de interés del cual se deriva el resultado de la consulta ad hoc.

Para una discusión detallada sobre métodos de análisis de datos para determinar objetos de interés y grupos de datos separados, el lector puede ir a “Guía para Medir Aplicaciones de Gestión utilizando COSMIC”.

Objetos de interés y grupos de datos en el dominio de las aplicaciones en tiempo real.

Ejemplo 3: Movimientos de datos que son Entradas desde dispositivos físicos típicamente contienen datos sobre el estado de un solo objeto de interés, tales como si un válvula está abierta o cerrada, o indican un tiempo en el que datos a corto plazo, almacenamiento volátil es válido o inválido, o contienen datos que indican que ha ocurrido un evento crítico y qué causa una interrupción. De un modo similar un comando de Salida para encender o apagar una lámpara de aviso comunica datos sobre un solo objeto de interés.

Ejemplo 4: Un intercambio de mensajes puede recibir un grupo de datos de mensajes tales como una Entrada y guiarlo adelante sin cambios como una Salida, como requisito de una parte del software en particular. Los atributos del grupo de datos de mensajes podrían ser, por ejemplo, “el que lo envía, recipiente, ruta-código y mensaje-contenido; el objeto de interés del mensaje es “mensaje”.

Ejemplo 5: Una estructura de datos habitual, representando objetos de interés que se mencionan en los requisitos funcionales de usuario, que puede ser mantenida por procesos funcionales, y que es accesible para la mayoría de procesos funcionales encontrados en el software medido.

Ejemplo 6: Una estructura de datos de referencia, representando gráficos o tablas de valores encontrados en los requisitos funcionales de usuario, los cuales están en memoria permanente (memoria ROM por ejemplo) y accesible para la mayoría de procesos funcionales encontrados en el software medido.

Ejemplo 7: Archivos, comúnmente designados como “archivos planos”, representando objetos de interés mencionados en los requisitos funcionales de usuario, los cuales se mantienen en un dispositivo de almacenamiento continuo.

3.3.4 Grupos de datos o datos que son candidatos a movimientos de datos.

Datos cualesquiera que aparezca en pantallas de entrada o salida o en informes y que no están relacionados con un objeto de interés para un usuario funcional no deberían ser identificados indicando un movimiento de datos, por tanto no deberían medirse. Los ejemplos incluyen:

Ejemplo 1: Datos generales de la aplicación tales como encabezamientos y pies de página (nombre de la compañía, nombre de la aplicación, fecha del sistema, etc.) que aparecen en todas las pantallas.

Ejemplo 2: Comandos de control (un concepto definido solo en el ámbito de aplicaciones de gestión) que permite a un usuario funcional controlar su uso del software más que mover datos, por ejemplo los comandos de página arriba/abajo, pulsar “OK” para admitir un mensaje de error, etc. - ver la sección 4.1.10 más adelante.

El modelo Genérico COSMIC de Software asume que toda manipulación de datos dentro de un proceso funcional está asociada con unos de los cuatro tipos de movimientos de datos- ver sección 4.1.6. Por tanto ningún movimiento o manipulación de datos dentro de un proceso funcional puede ser identificado como candidato para movimiento de datos junto con las Entradas, Salidas, Lecturas y Escrituras. (Para ver ejemplos de manipulación y movimientos de datos que puedan ser mal interpretados como movimientos de datos ver sección 4.1.4, principio c) para Lecturas, y sección 4.1.5 principio d) para Escrituras.


44

3.3.5 El usuario funcional como objeto de interés

En muchos casos simples de software en tiempo real como el descrito en el primer punto del caso 2 de la sección 3.3.3 de arriba, el dispositivo físico -un usuario funcionales indistinguible del objeto de interés del movimiento de datos que genera o recibe. En dichos casos añade poco valor al documento un objeto de interés como si fuera algo separado del usuario funcional. El punto importante es usar estos conceptos, cuando sirvan de ayuda, para distinguir los diferentes grupos de datos y en consecuencia movimientos de datos separados.

Ejemplo: Supóngase un sensor de temperatura “A” que, cuando es preguntado por un proceso funcional, envía la temperatura actual al proceso. El usuario funcional es el sensor A: el nombre del mensaje de Entrada podría ser “temperatura actual en A”; el objeto de interés de este mensaje podría también ser considerado como “sensor A”. Teóricamente, el objeto de interés no es “sensor A”, sino “el material u objeto cuya temperatura está siendo detectada por el sensor A”. En la práctica sin embargo añaden poco valor al documento estas finas distinciones y puede que no merezca la pena identificar el objeto de interés separadamente.

3.4 Identificación de los atributos de datos (opcio nal)

Esta sección discute la identificación de atributos de datos referenciados por la parte del software que se va a medir. En esta versión del método de medida no es obligatorio identificar los atributos de los datos. Sin embargo, puede ser de ayuda analizar e identificar los atributos de datos en el proceso de distinguir los grupos de datos y los objetos de interés. Los atributos de datos pueden también ser identificados si una sub-unidad de la medida del tamaño es requerida, como se presenta en la sección 4.5 “Extendiendo el método de medida COSMIC”.

3.4.1 Definición

Definición – Atributo de datos

Un atributo de datos es la pieza más pequeña de información, dentro de un grupo de datos identificados, que tiene un significado desde la perspectiva de los requisitos funcionales del software.

Ejemplo 1: Atributos de datos en el contexto del dominio de aplicaciones de gestión como por ejemplo elementos de datos registrados en el diccionario de datos y atributos de datos que aparecen en un modelo de datos conceptual o lógico.

Ejemplo 2: Atributos de datos en el contexto de las aplicaciones a tiempo real del software como por ejemplo atributos de datos de una señal recibida de un sensor y atributos de datos de un mensaje en transmisión.

3.4.2 Sobre la asociación de atributos de datos y grupos de datos

En teoría, un grupo de datos puede contener solo un atributo de datos si esto es suficiente, desde la perspectiva de los requisitos funcionales de usuario, para describir el objeto de interés. En la práctica, dichos casos ocurren normalmente en las aplicaciones a tiempo real del software (por ejemplo: la Entrada que transmite el tick de un reloj a tiempo real); éstos son menos comunes en el software de gestión.


45

44 FASE DE MEDICIÓN

Este capítulo presenta las reglas y el método para la fase de medición del proceso de medición COSMIC. El método general para medir una aplicación software cuando sus Requisitos Funcionales de Usuario se han expresado en términos del Modelo Genérico COSMIC de Software se resume en el gráfico 4.0 debajo.

Functional Sizeof the measured

software

Section 4.1

IDENTIFYDATA MOVEMENTS

Section 4.2

APPLY

MEASUREMENTFUNCTION

COSMIC MEASUREMENT PHASE

Section 4.3

AGREGATEMEASUREMENT

RESULTS

recorded information

All

functional processesmeasured ?

YES

NO



Functional Sizeof the measured

software

Section 4.1


Section 4.1Section 4.1



APPLY

MEASUREMENTFUNCTION

COSMIC MEASUREMENT PHASECOSMIC MEASUREMENT PHASE

Section 4.3

AGREGATEMEASUREMENT

RESULTS


AGREGATEMEASUREMENT

RESULTS

recorded information

All


All


YES

NO



Figura 4.0 – Proceso general de la Fase de Medición COSMIC

Cada paso de este método es el objeto de una sección específica de este capítulo, donde se presentan las definiciones y principios a aplicar, junto con algunas reglas y ejemplos.

4.1. Identificar los movimientos de datos

Este paso consiste en identificar los movimientos de datos (Entrada, salida, lectura y escritura) de cada proceso funcional.


46

4.1.1 Definición de los tipos de movimientos de datos

Definición – Movimiento de datos

Un componente con base funcional que mueve un único tipo de grupo de datos.

Nota 1: Hay cuatro tipos de movimiento de datos: Entrada, Salida, Lectura y Escritura

Nota 2: Para la medición, cada tipo de movimiento de datos se considera que incluye ciertas manipulaciones de datos asociadas - Ver sección 4.1.6 para más detalles.

Nota 3: Más precisamente, es una ocurrencia de un movimiento datos, no un tipo de movimiento de datos, que realmente mueve las ocurrencias del grupo de datos (no los tipos). Este comentario se aplica también a las definiciones de Entrada, salida, lectura y escritura.

Definición – Entrada, (Entry, E)

Una entrada (E) es un movimiento de datos que mueve un grupo de datos desde un usuario funcional a través de la frontera hacia el proceso funcional donde se necesitan

Nota: Se considera que una entrada incluye ciertas manipulaciones de datos asociadas (ver sección 4.1.6)

Definición – Salida, (Exit, X)

Una salida (X) es un movimiento de datos que mueve un grupo de datos desde un proceso funcional a través de la frontera hacía el usuario funcional que los requiere.

Nota: Se considera que una salida incluye ciertas manipulaciones de datos asociadas (ver sección 4.1.6)

Definición – Lectura (Read, R)

Un movimiento de un grupo de datos desde un almacén permanente dentro del alcance del proceso funcional que los requiere.

Nota: Se considera que una lectura incluye ciertas manipulaciones de datos asociadas (ver sección 4.1.6)

Definición – Escritura (Write, W)

Un movimiento a un almacén permanente de un grupo de datos que se encuentra dentro de un proceso funcional.

Nota: Se considera que una escritura incluye ciertas manipulaciones de datos asociadas (ver sección 4.1.6)


47

La figura 4.1.1, debajo, ilustra la relación general existente entre los cuatro tipos de movimientos de datos, el proceso funcional al que pertenecen y la frontera del software medido.

Boundary

Functionalprocess

Functional users

Persistent storage

Read (R)1 data group

Entry (E)1 data group

Exit (X)1 data group

Write (W)1 data group

Boundary

Functionalprocess

Functional users

Persistent 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 da tos y su relación con el proceso funcional y los grupos de datos.

4.1.2. Identificación de entradas (E)

Una vez identificado, un candidato a movimiento de datos de Entrada debe cumplir con los siguientes principios:

Principios – Entradas (E)

a) Una entrada deberá mover un único grupo de datos describiendo un solo objeto de interés de un usuario funcional a través de la frontera y dentro de un proceso funcional del que la entrada forma parte. Si la entrada a un proceso funcional comprende más de un grupo de datos, se identifica una entrada por cada grupo de datos que entra. (Véase también la sección 4.1.7 sobre “El único movimiento de datos”)

b) Una entrada no deberá salir de la frontera, ni leer ni escribir datos c) Donde un proceso funcional necesite obtener datos de un usuario funcional pero

más tarde no necesite que se le diga que datos enviar o el usuario funcional es incapaz de reaccionar a ningún mensaje entrante, identificar una Entrada al proceso funcional para obtener los datos. Cualquier mensaje del proceso funcional al usuario funcional buscando recuperar los datos no debe ser contado como una Salida en estos casos.

Sin embargo, cuando un proceso funcional deba obtener algún dato de un usuario funcional y el proceso funcional deba decirle al usuario funcional con datos que después requieran rellenar la petición, contar una Salida para la petición y una Entrada para la devolución de los datos pedidos (para más información ver sección 4.1.9).

Las siguientes reglas ayudan a confirmar la condición de un candidato a movimiento de datos de entrada:

Reglas – Entradas (E)

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


48

datos que simplemente informa al software que “un evento Y ha ocurrido”. Muy a menudo, especialmente en el software de gestión, el grupo de datos que dispara una entrada tiene muchos atributos que informan al software de que “un evento Y ha ocurrido y aquí están los datos sobre ese evento en particular”.

b) Las ticks de reloj que están provocando eventos serán siempre externos al software que está siendo medido. Por lo tanto, por ejemplo, un evento de tick de reloj cada 3 segundos estará asociada a una entrada que mueve un grupo de datos con un sólo atributo. Se debe notar que no hay ninguna diferencia si el hecho desencadenante es generado periódicamente por el hardware o por otra parte del software fuera de los límites del software medido.

c) Salvo que sea necesario en un proceso funcional especifico, obtener el tiempo desde el reloj del sistema no será considerado como causa de una entrada.

d) Si una ocurrencia de un evento específico desencadena la entrada de un grupo de datos que comprende hasta “n” atributos de un objeto de interés en particular y los FUR permiten que otras ocurrencias del mismo evento puedan disparar una Entrada de un grupo de datos que tiene valores de atributos de sólo un subconjunto de ‘n’ atributos del objeto de interés, entonces será identificada una entrada, compuesto por todos ‘n’ atributos.

Un ejemplo que ilustra la regla c): cuando un proceso funcional escribe un certificado de fecha de registro, no se identifica ninguna Entrada para obtener el valor del reloj del sistema.

Una vez identificados, cada movimiento de datos de Entrada puede ser registrado marcando la casilla correspondiente a la tabla del Modelo Genérico de Software (apéndice A) con una “E”.

4.1.3. Identificación de salidas (X)

Una vez identificados, un candidato a movimiento de datos de Salida debe cumplir con los siguientes principios:

Principios – Salidas (X)

a) Una salida deberá mover un único grupo de datos describiendo un solo objeto de interés desde el proceso funcional del que la salida forma parte a cruzando la frontera hacia un usuario funcional. Si la salida de un proceso funcional comprende más de un grupo de datos, hay que identificar una salida para cada grupo de datos que sale. (Véase también la sección 4.1.7 sobre los movimientos de datos únicos.)

b) Una salida no introducirá datos a través de la frontera, ni lecturas, ni escrituras.

Las siguientes normas podrían ser útiles para confirmar la condición de un candidato a movimiento de datos de tipo Salida:

Reglas – Salidas (X)

a) Todos los mensajes generados y las salidas producidas por el software sin datos del usuario (por ejemplo mensajes de error) deberán ser considerados valores de un atributo de un objeto de interés (el cual debería ser nombrado ‘indicación de error’). Por lo tanto, deberá ser identificada una sola Salida para representar todos estos mensajes dentro de cada proceso funcional donde son requeridos por los requisitos funcionales de Usuario.

b) Si una salida de un proceso funcional mueve un grupo de datos comprendiendo hasta ‘n’ atributos de un objeto de interés y los requisitos funcionales de usuario permiten que el proceso funcional pueda tener una ocurrencia de una salida que mueve un grupo de datos que tiene valores de atributos de sólo un subconjunto de ‘n’ atributos del objeto de interés, entonces será identificada una salida, compuesta por todos los ‘n’ atributos.

Ejemplos de la regla a) anterior son los siguientes:


49

Ejemplo 1: En un diálogo persona-ordenador, ejemplos de mensajes de error ocurridos durante la validación de datos podrían ser “error de formato”, “Cliente no encontrado”, “error: marcar la casilla que indica que los términos y condiciones han sido leídos”, “límite crédito excedido”, etc. Todos esos mensajes de error deben considerarse como ocurrencias de una salida en cada proceso funcional en el que tales mensajes se producen (que podría ser nombrado “mensajes de error”)

Ejemplo 2: Los mensajes de error que salen a los usuarios humanos pero que no son generados por la aplicación de software deberían ser ignorados por completo en la medición de la aplicación. Un ejemplo de ese mensaje al pasar por el sistema operativo podría ser “La impresora X no responde”.

Ejemplo 3: En un diálogo persona-ordenador, si un mensaje es la salida de un error de situaciones pero contiene datos funcionales de usuario, entonces debe contarse como una salida en el proceso funcional donde ocurre. Un ejemplo de ese mensaje podría ser “PELIGRO: la cantidad que desea retirar supera su límite por 100€” (donde los 100€ son una variable calculada). En este ejemplo, la salida contiene un grupo de datos sobre la cuenta bancaria del cliente

Ejemplo 4: En un sistema en tiempo real, un proceso funcional que revisa periódicamente el correcto funcionamiento de todos los dispositivos de hardware podría emitir un mensaje que informe “SENSOR X ha fallado”, donde “X” es una variable. Este mensaje debe ser identificado como una salida en ese proceso funcional (independientemente del valor de “X”)

Ejemplo 5: Considerar procesos funcionales A y B. “A” puede potencialmente emitir 2 mensajes distintos de confirmación y 5 mensajes de error a sus usuarios funcionales y “B” puede potencialmente emitir 8 mensajes de error a sus usuarios funcionales. En este ejemplo, será identificada una salida en el proceso funcional “A” (manejando 5 + 2 = 7 mensajes) y se identificará una salida separada en el proceso funcional “B” (manejando 8 mensajes).

Una vez identificados, cada movimiento de datos de Salida puede ser registrado marcando la casilla correspondiente de la tabla del modelo genérico de Software (apéndice A) con un “X”.

4.1.4. Identificación de Lecturas (R)

Una vez identificado, un candidato a movimiento de datos de Lectura debe cumplir con los siguientes principios:

Principios – Lecturas (R)

a) Una lectura deberá mover un único grupo de datos describiendo un solo objeto de interés del almacén permanente a un proceso funcional del cual la lectura forma parte. Si el proceso funcional debe recuperar más de un grupo de datos del almacén, identificar una Lectura para cada grupo de datos que es recuperado. (Véase también la sección 4.1.7 sobre los movimientos de datos únicos.)

b) Una lectura no recibirá ni sacará datos a través de la frontera ni escribirá datos c) Durante un proceso funcional, el movimiento o manipulación de constantes o

variables que son internas del proceso funcional y que sólo se pueden cambiar por un programador, o mediante los resultados intermedios en un cálculo, o de los datos almacenados en un proceso funcional sólo resultantes de la aplicación, más que de los requisitos funcionales, no se considerará como una Lectura.

d) Una Lectura siempre incluye cualquier funcionalidad de ‘solicitud de lectura’ (así, un movimiento de datos separado nunca será contado para cualquier funcionalidad de ‘solicitud de lectura’). Véase también la sección 4.1.9.

Una vez identificados, cada movimiento de datos de Lectura puede ser registrado por marcando la casilla correspondiente de la Matriz de Modelo Genérico del Software (apéndice A) con una ‘R’.

4.1.5. Identificando escrituras (W)

Una vez identificado, el candidato como movimiento de datos de Escritura debe cumplir con los siguientes principios:

Principios – Escritura (W)

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


50

interés del proceso funcional del que la Escritura forma parte hacia un almacén permanente. Si el proceso funcional debe pasar más de un grupo de datos al almacén permanente, identificar una Escritura por cada grupo de datos que se mueve a un almacén permanente. (Véase también la sección 4.1.7 sobre movimientos únicos de datos)

b) Una escritura no recibirá ni sacará datos de la frontera, ni leerá los datos c) Un requisito para borrar un grupo de datos de un almacén permanente se medirá

como una sola Escritura d) Durante un proceso funcional, el movimiento o manipulación de los datos que no

persista cuando el proceso funcional sea completado, o la actualización de variables que son internas del proceso funcional o la producción de resultados intermedios en un cálculo no se considerarán como una Escritura.

Una vez identificadas, cada Escritura puede ser registrada marcando la casilla correspondiente de la tabla del modelo de software genérico (apéndice A) con un ‘W’.

4.1.6. Sobre las manipulaciones de datos asociadas con los movimientos de datos

Sub-procesos son, tal como se define en el principio (d) del Modelo Genérico de Software (ver sección 1.4), o bien movimientos de datos, o bien manipulaciones de datos. Sin embargo, por un convenio actual de COSMIC (véase el principio (j) del Modelo Genérico de Software), no se reconoce la existencia separada de manipulación de datos y sub-procesos.

Definición – Manipulación de datos

Todo lo que le sucede a los datos, distinto de un movimiento de datos en o de un proceso funcional, o entre un proceso funcional y almacén permanente.

El siguiente principio determina como el método COSMIC trata la manipulación de datos.

Principio – Manipulación de datos asociada con los movimientos de datos

Todas las manipulaciones de datos en un proceso funcional serán asociadas con los cuatro tipos de movimiento datos (E, X, R, y W). Por convención, los movimientos de datos de un proceso funcional se supone que también representan la manipulación de los datos del proceso funcional

La necesidad de definir qué clase de manipulación de los datos está asociada con qué tipos de movimientos datos surge sólo cuando hay que medir los cambios de software (ver sección 4.4). Un cambio típico necesario afecta tanto a los atributos reubicados como a la manipulación asociada con un movimiento de datos, pero puede afectar sólo a la manipulación de los datos, y no al movimiento de los datos. Ese cambio todavía necesita ser identificado y medido.

A continuación están las directrices generales para identificar la manipulación de los datos representados por cada uno de los movimientos de datos.

Movimiento de Datos de Entrada (E)

Una entrada incluye toda manipulación de datos

• Para permitir a un grupo de datos debe ser introducida por un usuario funcional (por ejemplo manipulaciones de formato y presentación) y/o para ser validado

• Pero no todas las manipulaciones que involucran otro movimiento de datos, ni manipulaciones después de que el grupo de datos se ha introducido y validado.

Ejemplo: Una entrada incluye toda manipulación, formato y presentación en una pantalla de los datos introducidos salvo alguna Lectura(s) que podría ser necesaria para validar algunos códigos introducidos o para obtener algunas descripciones asociadas.


51

Una Entrada de datos incluye cualquier funcionalidad “solicitud de entrada” excepto cuando el proceso funcional debe informar al usuario funcional qué datos va a enviar (véase el punto 4.1.9 para qué datos enviar y 4.1.10 para el tratamiento de una pantalla vacía como entrada).

Movimiento de Datos de Salida (X)

Una Salida incluye todas las manipulaciones de datos

• para crear los atributos de un grupo de datos de salida y/o • para permitir que el grupo de datos sea salida (por ejemplo las manipulaciones de formato y

presentación) y sea encaminado a los usuarios funcionales. • pero no cualquier manipulación que involucre otro movimiento de datos.

Ejemplo: Una Salida incluye todo el tratamiento para formatear y preparar la impresión de algunos atributos, incluidos los encabezados para aumentar la legibilidad por los humanos, salvo cualquier Lectura o Entrada que podría ser necesaria para proporcionar los valores o descripciones de algunos atributos de impresión.

Movimiento de datos de Lectura (R)

Una Lectura incluye todo tratamiento y/o cálculo necesario a fin de recuperar un grupo de datos del almacén permanente pero no a manipulaciones con otro tipo de movimiento de datos ni manipulaciones después de que la lectura se complete con éxito.

Ejemplo: Una lectura incluye todas las operaciones matemáticas y transformaciones lógicas necesarias para recuperar un grupo de datos de un almacén permanente pero no la manipulación de los atributos después de que el grupo de datos se haya obtenido.

Una Lectura también incluye siempre cualquier funcionalidad de “solicitud de lectura” (véase el punto 4.1.9).

Movimiento de datos de Escritura (W)

Una Escritura incluye todos los tratamientos y/o cálculos para crear un grupo de datos que será escrito pero no cualquier manipulación que incluya otro tipo de movimiento de datos, ni tampoco manipulaciones de que la Escritura termine con éxito después de que la Escritura termine con éxito.

Ejemplo: Una Escritura incluye todas las operaciones matemáticas y transformaciones lógicas necesarias para crear o actualizar un grupo de datos de Escritura, o para ser borrados excepto las lecturas o entradas que podrían ser necesarias para dar valor a los atributos incluidos en el grupo que va a ser escrito o suprimido.

4.1.7 Movimientos de datos únicos y posibles excepciones

El Modelo Genérico de Software supone que normalmente en cualquier proceso funcional todos los datos describen un objeto de interés que se traduce en un solo movimiento de datos de tipo Entrada y/o en uno de tipo Lectura y/o en uno de tipo Escritura y/o en la producción de un movimiento de datos de tipo Salida. El modelo supone también que toda manipulación de los datos resultantes de todos los valores de los atributos los datos de un grupo que se mueve está asociado con un movimiento de datos.

Ejemplo que ilustra este último supuesto; consideremos dos ocurrencias de un determinado proceso funcional dado. Supongamos que en la primera ocurrencia los valores de algunos atributos se trasladan a una manipulación de datos del sub-proceso “A” y que en otra ocurrencia del mismo proceso funcional el valor del atributo es conducido a otra manipulación de datos del sub-proceso “B”. En tales circunstancias, tanto la manipulación de datos del sub-proceso “A” como “B” deben asociarse con el mismo movimiento de datos y de ahí normalmente sólo un movimiento datos debe identificarse y ser contado en ese proceso funcional.


52

Sin embargo, en excepcionales circunstancias en las que datos de diferente grupo de tipos describen el mismo objeto de interés puede ser necesario (en los FUR) reubicarlos en un movimiento de datos del mismo tipo (E, R, W, X) en el mismo proceso funcional. Por otra parte, y de nuevo excepcionalmente, se puede requerir que el mismo grupo de datos sea movido en el mismo tipo de movimiento (E, R, W o X) en el mismo proceso funcional, pero con diferentes manipulaciones de datos asociadas.

Las siguientes reglas y ejemplos cubren la situación normal, excepciones validadas posibles y ejemplos que podrían parecer como válidos, pero que no lo son.

Regla – Movimientos de Datos Únicos y posibles exce pciones

a) A menos que los Requisitos Funcionales de Usuario especifiquen lo contrario, todos los atributos describen un objeto de interés que está obligado a ser entrada en un proceso funcional, y todas las manipulaciones de datos asociadas serán identificadas y se contarán como una Entrada.

Nota: Un proceso funcional puede, por supuesto, estar obligado a manejar múltiples Entradas, cada movimiento de un grupo de datos describe un objeto de interés diferente

La misma norma se aplica a cualquier movimiento de datos de tipo Lectura, Escritura o Salida en cualquier proceso funcional.

b) Cuando hay más de un movimiento de datos de Entrada, cada movimiento de un grupo de datos que describa el mismo objeto de interés en un proceso funcional puede ser identificado y contado si existe un Requisito Funcional de Usuario para estas múltiples entradas. Asimismo, puede ser identificada y contada más de una Entrada moviendo el mismo grupo de datos en el mismo proceso funcional, pero cada una con diferentes manipulaciones de datos asociadas, si existe un Requisito Funcional de Usuario para las mismas

Tales FUR pueden surgir cuando, en un proceso funcional, las múltiples entradas proceden de diferentes usuarios funcionales que introduzcan diferentes grupos de datos (cada uno describiendo el mismo objeto de interés)

La misma norma se aplica a cualquier Lectura, Escritura o Salida en cualquier proceso funcional.

c) Si se repiten ocurrencias de un mismo tipo de movimiento de datos (es decir se mueve el mismo grupo de datos con la misma manipulación de datos) no deberán ser y contadas más de una vez en un proceso funcional.

d) Si las múltiples ocurrencias de un tipo de movimiento de datos en un determinado proceso funcional difieren en sus manipulaciones de datos asociadas, porque los diferentes valores de los atributos del grupo de datos movido han resultado de caminos de procesamiento distintos, el tipo de movimiento de datos no deberá ser identificado ni contado más de una vez en ese proceso.

Los siguientes ejemplos ilustran las reglas anteriores.

Ejemplo 1 para una regla a): en un proceso funcional, todas las Lecturas de datos que describen un objeto de interés en particular pueden considerarse lógicamente para devolver todos los atributos que describen ese objeto de interés (es decir, el conjunto del “vector de estados” de ese objeto de interés). Por lo tanto normalmente, sólo una Lectura de cualquier dato sobre un objeto de interés es funcionalmente necesaria y debe ser identificada en un proceso funcional.

Ejemplo 2 de las reglas a) y b): Después del Ejemplo 1, todos los datos que son leídos deben haberse hecho persistentes por una Escritura, este es el caso en que normalmente sería identificada una Escritura por mover un grupo de datos que contiene todos los atributos de un objeto de interés y que debe hacerse persistente en un determinado proceso funcional, según la norma a). Es posible, sin embargo, que existan FUR para un único proceso funcional para escribir dos datos diferentes grupos describiendo el mismo objeto de interés, por ejemplo, para un uso posterior por dos usuarios funcionales distintos en otros procesos funcionales. Este sería un Ejemplo donde la norma b) se aplica, cuando dos Escrituras de datos que describen el mismo objeto de interés pueden ser identificadas y contadas en el mismo proceso funcional.


53

Ejemplo 3 para la regla b): Es posible que existan FUR para un único proceso funcional que produzcan dos o más Salidas de diferentes grupos de datos describiendo el mismo objeto de interés, destinados a diferentes usuarios funcionales. Por ejemplo, cuando un nuevo empleado llega a una empresa, se produce un informe por el empleado para firmar sus datos personales como válidos y un mensaje es enviado a Seguridad para autorizar al empleado a entrar en el edificio.

Ejemplo 4 por regla c): Suponga que se requiere una Lectura en los requisitos funcionales de usuario que en la práctica requiere muchas recuperaciones de ocurrencias, como en la búsqueda de un fichero. Para la medición, identificar sólo una Lectura.

Ejemplo 5 por regla c): Suponga que en un proceso funcional de tiempo real los requisitos funcionales de usuario requieren que los datos entren desde un determinado usuario funcional, por ejemplo, un dispositivo de hardware, dos veces en un intervalo de tiempo para medir un tipo de cambio o para comprobar si un valor ha cambiado durante el proceso. Siempre que las dos entradas sean idénticas en términos del grupo de datos reubicado y las manipulaciones de datos asociadas, sólo deberá ser identificada una entrada.

Ejemplo 6 para la norma c): véase la sección 4.1.2, Norma d) para entradas, y la sección 4.1.3, Norma b) para las salidas.

Ejemplo 7 para regla d): Suponga un proceso funcional en el que es necesario que proporcione diversas opciones de manipulación de datos dependiendo de los valores de los atributos de una entrada. Para la medición, identificar sólo una entrada.

Ejemplo 8: Supongamos que una Lectura de un grupo de datos es necesaria en los requisitos funcionales de usuario, pero el desarrollador decide implementarla mediante dos comandos para recuperar diferentes sub-series de atributos del mismo objeto de interés de las ficheros de almacenamiento en diferentes puntos del proceso funcional. Identificar sólo una lectura.

4.1.8. Cuando un proceso funcional mueve datos para o desde un fichero de almacenamiento.

Esta sección explica los movimientos de datos involucrados cuando un proceso funcional de parte de una aplicación software es requerido para desplazar datos hasta o desde un fichero de almacenamiento, de manera local o remota. Los casos también mostrar cómo el almacenamiento de una aplicación necesita ser manipulado por otro software que soporta la aplicación en otra capa, tales como el almacenamiento permanente en un dispositivo.

Los casos ilustran la aplicación del principio (g) del Modelo de Contexto Software y los principios del Modelo Genérico del Software. La clave para entender los casos es que estos principios deben ser aplicados por separado a cada parte de software que deba ser medida.

El primer caso trata con los movimientos de datos de una consulta en una aplicación donde el requisito para recuperar datos persistentes es manejado por un controlador software local en otra capa. El segundo caso muestra cómo los diferentes movimientos de datos difieren cuando el requisito de recuperar es satisfecho primero por parte semejante o par del software en la misma capa de la aplicación.

En términos prácticos, los casos son aplicables cuando la tarea consiste en medir dos partes de software que tienen una relación jerárquica (es decir, cuando las dos piezas están en diferentes capas) o tienen una relación cliente-servidor (es decir, cuando las dos piezas están en la misma capa). Los casos muestran cómo son medidos y modelados los movimientos de datos que son físicamente intercambiados entre las dos partes de software.

Los ejemplos se ilustran usando los convenios de Diagramas de Secuencia de Mensajes. La notación de estos diagramas es como se explica a continuación:

• Una flecha vertical hacia abajo representa un proceso funcional • Las flechas horizontales representan los movimientos de datos, etiquetados como E, X, R o W

para la Entrada, Salida, Lectura y Escritura, respectivamente. Entradas y Lecturas se muestran como flechas de llegada al proceso funcional y las Salidas y Escrituras como flechas salientes; aparecen en la secuencia necesaria, de arriba a abajo, del proceso funcional


54

• Una línea vertical punteada (discontinua) representa un límite frontera

Ejemplo 1: Cuando un proceso funcional debe mover datos hasta o desde un fichero de almacenamiento local

Este ejemplo implica dos aplicaciones software, aplicación “A” y aplicación “B” que es el driver para un dispositivo de almacenamiento que la aplicación software utiliza. (Para simplificar ignoramos la probable presencia de un sistema operativo; el sistema operativo efectivamente transmite las peticiones de la aplicación al driver del dispositivo y devuelve los resultados de las peticiones.)

El concepto de capas nos dice que las dos aplicaciones software están en diferentes capas: la capa de aplicación y la capa de drivers de dispositivos. Físicamente, hay una relación jerárquica entre las dos piezas y (ignorando el sistema operativo) una interfaz física entre el software de las dos capas, como por ejemplo en la Fig. 2.2.3.1.

Normalmente, los requisitos funciones de usuario de la aplicación “A” especificarán los procesos funcionales que incluyen la necesidad de Leer y Escribir en el fichero de almacenamiento pero no en lo concerniente a cómo las Lecturas y Escrituras son manejadas por otras infraestructuras software.

Aplicando el modelo de COSMIC a las dos piezas de software, los usuarios funcionales del software A en la capa de aplicación podrían ser, por ejemplo, usuarios humanos, mientras que los usuarios funcionales del software B en la capa del controlador es la aplicación A (ignorando el sistema operativo).

Supongamos que una consulta del proceso funcional ‘FP A’ del software A en la capa de aplicación exige una Lectura. La figura 4.1.8.1 (a) muestra el modelo COSMIC de la aplicación en la que se busca información. La recuperación física de los datos necesarios de los ficheros de almacenamiento es manejado por un proceso funcional ‘B’ del software B en la capa del controlador. La figura 4.1.8.1 (b) muestra el modelado de este proceso funcional del driver del dispositivo.

Application in Layer A

FP A

E

RFunctional

user of application in layer A X

Persistent storage device driver in Layer B

FP BE

EX

Functional user of

software in

layer B

(=

application in layer A)

Functional User:

Persistent

storage hardware

device

X

Application in Layer A

FP A

E

RFunctional

user of application in layer A X

Persistent storage device driver in Layer B

FP BE

EX

Functional user of

software in

layer B

(=

application in layer A)

Functional User:

Persistent

storage hardware

device

X

Figuras 4.1.8.1 (a) y (b) Solución para una lectura emitida por el software 'A' en la capa de aplicació n del software a 'B' en la capa del controlador.

La figura 4.1.8.1 a) muestra la búsqueda de información desencadenada por una entrada, seguida de una lectura y luego una salida con el resultado de la búsqueda. El proceso funcional A no tiene conocimiento de donde se obtienen los datos, ni que en la práctica la lectura es delegada a algunos controladores de dispositivos software.

La figura 4.1.8.1 b) muestra que funcionalmente la Lectura solicita que la aplicación A es recibida como un evento de Entrada al proceso funcional PF B, que luego recupera los datos solicitados desde el dispositivo físico de almacenamiento y devuelve los datos a la aplicación como una salida. La aplicación A es pues un usuario funcional de los controladores del software B.

El aparente desencuentro entre el número de movimientos de datos de la “Lectura” del software en la capa de aplicación y la ‘Entrada/Salida par’ de software en la capa del dispositivo es debido al hecho de que por convenio, una Lectura de datos se considera que incluye cualquier funcionalidad de ‘solicitud de lectura’.

Exactamente modelos análogos se aplicarían si el proceso funcional FP A fuera requerido para crear algún dato permanente mediante una Escritura. En este caso, la salida del proceso funcional PF B del dispositivo software contendría cualquier “código de retorno” o mensaje de error.

Ejemplo 2: Cuando un proceso funcional debe obtener datos de un componente homólogo o par de software


55

En este ejemplo, los dos pares de componentes de software a ser medidos se supone que son un ‘cliente/servidor’, es decir, donde un componente, el cliente, recibe los servicios y/o datos del otro componente, ‘servidor’. La figura 4.1.8.2 muestra un ejemplo de esa relación, en la que las dos piezas son importantes componentes de la misma aplicación. La misma relación que existiría y el mismo esquema se aplicarían si las dos piezas fueran aplicaciones homólogas separadas, donde una es necesaria para obtener datos de la otra.

Físicamente, los dos componentes pares podrían ejecutarse en diferentes procesadores; en tal caso intercambiarían datos a través de los respectivos sistemas operativos y cualquier otra capa intermedia de sus procesadores en una arquitectura software tal como la Fig. 2.2.3.1. Pero lógicamente, aplicando el modelo COSMIC, los dos componentes intercambian datos a través de ‘Entrada/Salida’. Todo el software y hardware que interviene es ignorado en este modelo (como también se indica en el lado derecho de figura. 3.1.1).

La Figura 4.1.8.2 muestra un proceso funcional FP C1 de un componente cliente C1 que es desencadenado por una Entrada de su usuario funcional que comprende, por ejemplo los parámetros de la información buscada. Los requisitos funcionales del componente C1 reconocerán que este componente debe pedir al componente servidor C2 los datos requeridos, y debe decirle qué datos son necesarios.

La Salida cruza la frontera entre C1 y C2 y se convierte en el desencadenante de la entrada de un proceso funcional FP C2 en el componente C2. El proceso funcional FP C2 del componente C2 obtiene los datos necesarios mediante un proceso de lectura, y envía los datos a C1 mediante una salida. El Proceso Funcional FP C1 del componente C1 recibe este movimiento de datos como una entrada. FP C1 pasa entonces los datos como una Salida para satisfacer la búsqueda de su usuario funcional. Este caso 2 por lo tanto requiere 7 movimientos de datos para satisfacer la solicitud. Esto se compara con los 3 movimientos de datos (1 x E, 1 x R y 1 x X) que habrían sido necesarios si el componente C1 hubiera sido capaz de recuperar los datos del fichero de almacenamiento local como en la figura 4.1.8.1 (a).

Component C1 (Client)

FP C1E

EX

X

Component C2 (Server)

FP C2

E

X

RFunctional user of

component C1

Component C1 (Client)

FP C1E

EX

X

Component C2 (Server)

FP C2

E

X

RFunctional user of

component C1

Figura 4.1.8.2 Intercambio de datos entre component es semejantes en la misma capa

El Componente C2 probablemente, por supuesto, utilice los servicios de algunos dispositivos de almacenamiento en una capa inferior de la arquitectura software para recuperar los datos del hardware, como en el caso 1.

Comparando los casos 1 y 2, vemos que en el caso 1, los modelos de la aplicación A y el dispositivo controlador B no pueden combinarse como en el ejemplo 2. Esto es porque una lectura no cruza una frontera. La Figura 4.1.8.1 (B) muestra que la aplicación A es un usuario funcional de un dispositivo controlador del software B. Pero lo contrario no es cierto, demostrando así el carácter jerárquico del software en diferentes niveles.

En contraste, Fig. 4.1.8.2 puede mostrar los dos componentes en un modelo porque intercambian datos como ‘pares’ o iguales. El Componente C1 es un usuario funcional del componente C2, y viceversa, y comparten una frontera común.


56

Nota: En estos dos casos hemos ignorado, por simplificar, la posibilidad de un ‘código de retorno’ que acompañe a la Lectura, que podría conducir a la generación de un mensaje de error además de la salida como el resultado de la búsqueda en la aplicación o el componente C1.

4.1.9 Cuando un proceso funcional requiere datos de un usuario funcional

Como por el principio c) para una entrada (ver sección 4.1.2), si un proceso funcional debe obtener datos de un usuario funcional hay dos casos. Si el proceso funcional no necesita decirle al usuario funcional qué datos enviar, una sola Entrada es suficiente (por objeto de interés). Si el proceso funcional debe decirle al usuario funcional qué datos va a enviar, es necesaria una entrada/salida par. Las normas son las siguientes:

Reglas – Cuando un proceso funcional requiere datos de un usuario funcional

a) Cuando un proceso funcional requiere datos de un usuario funcional un proceso funcional deberá obtener un grupo de datos por medio de una Entrada de un usuario funcional, cuando no tiene que decirle al usuario qué datos va a enviar, como en cualquiera de los siguientes cuatro casos:

• Cuando un usuario funcional envía una entrada que desencadena el inicio del proceso funcional

• Cuando un proceso funcional, habiéndose iniciado, espera, expectante a la próxima Entrada desde el usuario funcional (típica en el software de negocio de aplicación, de un usuario funcional humano).

• Cuando un proceso funcional, habiéndose iniciado, pide al usuario funcional que le envíe ‘envíame tus datos ahora, si tienes alguno’, y el proceso funcional envía sus datos.

• Cuando un proceso funcional, habiéndose iniciado, inspecciona los datos de un usuario funcional y recupera los datos que necesita.

En estos dos últimos casos (típico de un sistema de votación en tiempo real), por convenio, no habrá una Salida desde el proceso funcional que deba ser identificada para obtener los datos requeridos. El proceso funcional sólo debe enviar pronto un mensaje a un usuario funcional para ingresar sus datos y la funcionalidad del mensaje se considera parte de la entrada. El usuario funcional sabe lo que se puede enviar y el proceso funcional sabe lo que puede esperar. Sólo una entrada es necesaria para este caso.

b) Cuando un proceso funcional debe obtener los servicios de un usuario funcional (por ejemplo, para obtener datos) y las necesidades de los usuarios le digan lo que enviar (normalmente cuando el usuario funcional es otra parte del software fuera del alcance del software que se mide), un par de movimientos de datos de Entrada/Salida serán identificados. La salida contiene la solicitud específica de los datos; la entrada contiene los datos.

Ejemplo 1 de la regla a), primer y segundo punto: donde un proceso funcional proporciona a un humano una pantalla de entrada de datos, como en una aplicación de negocios on-line, el visualizar la pantalla ‘en blanco’ no se cuenta como una Salida. Solo rellenar la pantalla es contado como una o más entradas (ver también la sección 4.1.10).

Ejemplo 2 de la regla a), tercer o cuarto escenario: Supongamos que un proceso funcional de un sistema con proceso software de control en tiempo real necesario para comprobar un array con idénticos sensores. Las cuestiones relativas al proceso son una Entrada (tipo). (De los sensores solo se identifica y se cuenta una Entrada, aunque hay múltiples ocurrencias.)Supongamos que la Entrada debe en la práctica pasar a un dispositivo controlador de software en una capa inferior de la arquitectura, que físicamente obtiene los datos necesarios desde el sensor como se ilustra en la Fig. 2.2.3.2. Los procesos funcionales del proceso software de control y de los controladores software para los sensores sería como se muestra en las Figuras 4.1.9.1 (a) y (b) debajo.


57

Process Control software in Layer A

FP A

E1

E2Functional

user of application in layer A

Dumb sensor device driver in Layer B

FP BE

E

X

Functional user of

software in layer B

(= process

control software in

layer A)

Dumb sensor

Dumb sensor

(etc)

Process Control software in Layer A

FP A

E1

E2Functional

user of application in layer A


FP BE

E

X

Functional user of

software in layer B

(= process

control software in

layer A)

Dumb sensor


FP BE

E

X

Functional user of

software in layer B

(= process

control software in

layer A)

Dumb sensor

Dumb sensor

(etc)

La figura 4.1.9.1 (a) y b) Solución para una entrada emitida por el software 'A' en la capa de la aplic ación del proceso de control recibida por el software 'B' en la capa del dispositivo de control del sensor.

La figura 4.1.9.1 (a) Muestra que el proceso software de control del proceso funcional ‘FP A’ es desencadenado por una entrada ‘E1’ por ejemplo de un golpe de reloj. El proceso funcional luego obtiene la entrada ‘E2’ desde el array de sensores para recibir las múltiples ocurrencias de los sensores de lecturas. Los sensores son también usuarios funcionales del proceso software de control.

La figura 4.1.9.1 (b) Muestra que el software que impulsa el dispositivo del sensor recibe la Entrada (probablemente en la práctica mediante un sistema operativo) como el disparador de un proceso funcional ‘FP B’. Este proceso funcional obtiene una Entrada de su usuario funcional (tipo) y del sensor (tipo) para obtener los datos de los sensores que se reintegrarán al proceso software de control como una salida. El proceso funcional del proceso software luego continúa con su transformación de los datos del sensor. El hecho de que hay múltiples ocurrencias de este ciclo de recopilación de datos de cada uno de los idénticos sensores es ignorado en el modelado.

El aparente emparejamiento entre la única Entrada del proceso software de control y la Entrada/Salida par de los controladores software es debida al modo en que una Entrada es considerada como cualquier ‘solicitud de entrada’ funcional.

Ejemplo 3 de la norma b): Suponga que un proceso funcional envía a uno de sus usuarios funcionales como un dispositivo hardware ‘inteligente’ o otro par de piezas software con algunos parámetros para una consulta o los parámetros de un cálculo, o algunos datos para ser comprimidos. La respuesta de los usuarios funcionales se obtiene mediante una entrada/salida par, tal como se describe en la sección 4.1.8, Caso 2.

4.1.10 Comandos de control

Un “comando de control" es una categoría especial de un movimiento de datos que es reconocido sólo en el dominio de aplicaciones de negocio y que debe pasarse por alto cuando al medir un tamaño funcional. La definición es:

Definición – Comando de control

Un comando de control es un comando que le permite al usuario funcional controlar su uso del software pero que no implica ningún movimiento de datos sobre el objeto de interés.

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


58

Regla – Comandos de control en el dominio de aplica ciones de negocio.

En el dominio de aplicaciones de negocio, los ‘comandos de control’ serán ignorados ya que no implican ningún movimiento de datos sobre el objeto de interés.

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

No obstante, fuera del dominio de aplicaciones de negocio, el concepto de un ‘comando de control’ no tiene un significado especial y cualquier señal o movimiento de datos sobre el objeto de interés procedente de un usuario funcional debe justificarse, es decir, deberá medirse.

4.2. Aplicando la función de medición

Este paso consiste en la aplicación de la medida funcional de COSMIC a cada uno de los movimientos de datos identificados en cada proceso funcional.

Definición – Medición funcional COSMIC

La medición funcional de COSMIC es una función matemática que asigna un valor a su argumento basado en el estándar de medición COSMIC. El argumento de la medición funcional COSMIC es el movimiento de datos.

Definición – Medida estándar COSMIC

La medición estándar de COSMIC, 1 PPC (Punto de Función COSMIC) se define como el tamaño de un movimiento de datos.

Según esta función de medición, cada instancia de un movimiento de datos (Entrada, Salida, lectura o Escritura) que se requiere para ser añadido, cambiado o suprimido y que ha sido identificado según la sección 4.1 recibe una puntuación de 1 PPC.

4.3. Agregar resultados de medición

Este paso consiste en sumar los resultados de la medida funcional, tal como se aplica a todos los movimientos de datos, en un único valor de tamaño funcional. Este paso se realiza según los siguientes principios y reglas.

4.3.1 Reglas generales de agregación

Reglas – Agregando los resultados de la medición

a) Para cualquier proceso funcional, el tamaño funcional de cada movimiento de datos individual debe ser agregado en un único valor de tamaño funcional en unidades de CFP para luego sumar todos juntos. Tamaño (proceso funcionali) = Σ tam(Entradassi) + Σ tam(Salidasi) +

Σ tam(Lecturassi) + Σ size(Escriturasi) b) Para cualquier proceso funcional, el tamaño funcional de los cambios en requisitos

funcionales de usuario se sumarán al tamaño de movimientos de datos que han sido añadidos, modificados o eliminados en proceso funcional para dar un tamaño del


59

cambio en unidades de CFP, según la siguiente fórmula. Tamaño (Cambio(procedso funcionali)) = Σ tam (movimientos datos añadidosi) + Σ tam (movimientos datos modificadosi) + Σ tam (movimientos datos eliminadosi)

Para más información sobre el agregando del tamaño funcional, véase la sección 4.3.2. Para medir el tamaño de los cambios en el software, véase la sección 4.4.

c) El tamaño de una pieza de software dentro de un ámbito de aplicación se obtendrá sumando los tamaños de sus procesos funcionales, sujeto a las normas e) y f) debajo

d) El tamaño de cualquier cambio en una pieza de software dentro de un ámbito de aplicación se obtendrá sumando los tamaños de todos los cambios a todos sus procesos funcionales, sujeto a las normas e) y f) abajo

e) Los Tamaños de piezas de software o de cambios de piezas de software en el interior de las capas podrán sumarse sólo si se mide al mismo proceso funcional su nivel de granularidad de sus requisitos funcionales de usuario.

f) Los Tamaños de piezas de software y/o cambios en los tamaños de la misma dentro de una capa o de diferentes capas serán sumados sólo si tiene sentido hacerlo, a efectos de la medición.

g) El tamaño de una aplicación software no puede obtenerse sumando los tamaños de sus componentes (independientemente de cómo se descompone) al menos que el tamaño de las contribuciones de los movimientos de datos inter-componentes sean eliminadas.

h) Si el método COSMIC se extiende localmente (por ejemplo para medir algún aspecto del tamaño no recogido por el método estándar), entonces el tamaño medido por la extensión local debe ser informado por separado como se describe en la sección 5.1 y no puede ser añadido al tamaño obtenido por el método estándar, medido en CFP (véase además la sección 4.5)

Ejemplo 1 de las normas b) y c): Un cambio solicitado para una pieza de software podría ser: ‘añadir un nuevo proceso funcional de tamaño 6 CFP’, y en otro proceso funcional agregar un movimiento de datos, hacer modificaciones a otros tres movimientos de datos y suprimir dos movimientos. ‘El tamaño total del cambio solicitado es de 6 + 1 + 3 + 2 = 12 CPF.

Ejemplo 2 de la regla f): Si diversas partes importantes de una pieza de software se desarrollan utilizando tecnologías diferentes, por diferentes proyectos sub-equipos, no puede haber ningún valor práctico en añadir sus tamaños juntos.

Ejemplo 3 para la regla g): Si un trozo de software es

• Primera medición ‘como un todo’, es decir, todos dentro del mismo alcance. • Entonces en segundo lugar el tamaño de cada uno de sus componentes se mide por separado,

cada uno dentro de su propio ámbito.

El tamaño total de la suma del tamaño de todos los componentes por separado (en el segundo caso) superará al tamaño cuando se mide ‘como un todo’ (en el primer caso) debido a la contribución de tamaño de todos los movimientos de datos inter-componentes. Estos movimientos no son visibles cuando la pieza se midió ‘como un todo’ y debe ser eliminado para obtener el tamaño ‘del todo’. Véase también el ejemplo en la sección sobre la medición en distintos niveles de granularidad en arquitecturas de software puro en el documento “Temas avanzados y relacionados".

Es de señalar que, dentro de cada capa identificada, la agregación funcional es totalmente escalable. Por lo tanto un sub-total puede ser generado para los distintos procesos funcionales o para todo el software en una capa, dependiendo de la finalidad y alcance de cada ejercicio de medición y bajo las normas d), e) y f) de arriba.

4.3.2. Más sobre la agregación del tamaño funcional

En un contexto donde el tamaño funcional deba utilizarse como una variable en un modelo, para estimar el esfuerzo por ejemplo, y el software a ser medido tenga más de una capa o componente


60

par, la agregación normalmente se realizará por capas o por pares de componentes ya que no son ejecutados a menudo con la misma tecnología.

Ejemplo 1: Considere un software donde la capa de aplicación se ejecutará utilizando 3GL y un conjunto de bibliotecas existentes, mientras la capa de transporte podría estar implementada utilizando lenguaje ensamblador. La unidad de esfuerzo asociada con la construcción de cada capa, muy probablemente, sea diferente, y, en consecuencia, una estimación del esfuerzo será preparada por separado para cada capa sobre la base de su tamaño respectivo.

Ejemplo 2: Si un equipo del proyecto ha de desarrollar una serie de importantes piezas de software y está interesado en su productividad global, se puede sumar el trabajo-hora necesario para desarrollar cada pieza. De manera similar, se pueden sumar los tamaños de las principales piezas que ha desarrollado si (pero sólo si) esos tamaños satisfacen las normas dadas anteriormente.

La razón por la que tamaños de grandes partes de software de diferentes capas de una arquitectura estándar por capas, medida en el mismo nivel de granularidad del proceso, puedan sumarse es que esa arquitectura tiene un conjunto coherente definido de usuarios funcional. Cada capa es un usuario funcional de las capas bajas que se usan y cualquier pieza de software de una capa puede ser un usuario funcional de cualquier otro par de piezas de software en la misma capa. Los requisitos de dicha arquitectura imponen que los requisitos funcionales de usuario de las diversas piezas deberán intercambiar mensajes. Es lógico y razonable que los tamaños de las distintas piezas puedan sumarse, siempre sujeto a las normas d), e) y f) arriba indicadas. Sin embargo, en contraste con esto, el tamaño de una pieza grande de software puede no ser obtenido sumando el tamaño de sus componentes reutilizables a menos que el que los movimientos de datos del inter-objeto sean eliminados, como por regla f) de arriba.

Agregar los resultados de las mediciones por tipo de los movimientos de datos podría ser útil para analizar la contribución de cada tipo en el tamaño total de una capa y podría ayudar así a caracterizar la naturaleza funcional de la capa medida.

4.4 Más en la medición del tamaño de los cambios de software

Un ‘cambio funcional’ de software existente es interpretado en el método COSMIC como ‘cualquier combinación de sumas de nuevos movimientos de datos o de modificaciones o eliminaciones de los movimientos de datos existentes’. Los términos ‘Mejora y Mantenimiento’ se utilizan a menudo para lo que aquí llamamos un ‘cambio funcional’.

La necesidad de un cambio de software puede surgir de cualquier

• Nuevo Requisito Funcional de usuario (es decir, sólo sumas a la funcionalidad existente), o • Desde un cambio en el requisito (quizá con sumas, modificaciones y eliminaciones) o • Desde un ‘mantenimiento’ necesidad de corregir un defecto.

Las normas para la medición del tamaño de cualquiera de estos cambios son las mismas pero el medidor es alertado a distinguir las diversas circunstancias cuando se hacen mediciones del rendimiento y estimaciones.

Cuando un software es reemplazado por completo, por ejemplo al re-escribir, con o sin ampliar y/u omitir funcionalidades, el tamaño funcional de este cambio es el tamaño del software del reemplazo, medido según las reglas normales para la medición del software nuevo. Este caso no será examinado nuevamente en esta sección. El medidor debe ser consciente, sin embargo, de la necesidad que hay cuando se hacen mediciones del rendimiento o estimaciones para distinguir entre los proyectos a desarrollar enteramente con software nuevo y proyectos para ‘re-hacer o ‘reemplazar’ software existente.

A menudo, una parte obsoleta de una aplicación es suprimida («desconectada sería una mejor descripción) por abandonar el código de programa en lugar de sólo eliminar el contacto con la funcionalidad obsoleta. Cuando la funcionalidad de la parte obsoleta asciende a 100 CFP pero la


61

parte puede ser desconectada por cambiar, digamos, 2 movimientos de datos, 100 y no 2 movimientos de datos serán identificados como el tamaño del cambio funcional. Podemos medir el tamaño de la exigencia, no el tamaño que fue implementado.

Nota: La diferencia entre el tamaño de los cambios funcionales (discutido aquí) y el cambio en el tamaño funcional del software. Generalmente, son diferentes. El tamaño de la última está recogido en la sección 4.4.3.

4.4.1. Modificando funcionalidades

Cualquier movimiento de datos de un determinado tipo (E, X, R y W) incluye dos tipos de funcionalidad: se mueve un solo grupo de datos y tiene algunas manipulaciones de datos asociadas (para el último, véase la sección 4.1.6). Por lo tanto para la medición un movimiento de datos se considera que es modificado funcionalmente si:

• El Grupo de datos es reubicado y/o • Está asociado a una manipulación de datos

Son modificados en modo alguno.

Un grupo de datos es modificado si:

• Se añaden nuevos atributos a este grupo de datos y/o • Los atributos son retirados de los grupos de datos y/o • uno o más atributos existentes son modificados, por ejemplo, en sentido o formato (pero no en

sus valores)

Una manipulación de datos es modificada si es funcionalmente ha cambiado en modo alguno, por ejemplo por cambiar el cálculo, el formato específico, presentación y/o validación de datos. `La presentación’ puede significar, por ejemplo la fuente, el color de fondo, la longitud del campo, el número de decimales, etc.

Los comandos de control y los datos de aplicación general no implican movimientos de datos, ya que no hay datos sobre los objetos de interés que son movidos. Por lo tanto, los cambios de comandos de control y de datos de aplicación general no deben medirse. Por ejemplo, cuando el color de la pantalla para todas las pantallas es cambiado, este cambio no debe medirse. (Ver sección 4.1.10 para una explicación de comandos de control y datos de aplicación general.)

Reglas – Modificando un movimiento de datos

a) Si un movimiento de datos debe ser modificado debido a un cambio de la manipulación de los datos relacionados con el movimiento de datos y/o debido a un cambio en el número o tipo de los atributos del grupo de datos movido, un cambio CFP se medirá, independientemente de la cantidad real de modificaciones en el movimiento de la datos.

b) Si un grupo de datos deben ser modificado, los movimientos de datos moviendo el grupo de datos modificado, cuya funcionalidad no se ve afectada por la modificación del grupo de datos, no serán identificados como movimientos de datos modificados.

Nota 1: Una modificación para un valor de una ocurrencia de un atributo, tales como una modificación de un código individual de un miembro de un atributo cuyos valores son un sistema de codificación no es una modificación de los tipos del atributo.

Nota 2: Una modificación de cualquier dato que figuren en entrada o salida por pantalla que no esté relacionado con el objeto de interés para un usuario funcional no será identificados como un cambio CFP (ver sección 3.3.4 para los ejemplos de estos datos.)

Ejemplo de normas a) y b): Supongamos un requisito para añadir o modificar los atributos de los datos de un grupo D1, que después de la modificación se vuelve D2. En el proceso funcional ‘A’ donde esta modificación es necesaria, todos los


62

movimientos de datos afectados por la modificación deberían ser identificados y contados. Así, según la norma a), si los datos modificados grupo D2 son persistentes y/o es la salida en proceso funcional A, identificar una Escritura y/o una Salida de datos respectivamente modificada. Sin embargo, es posible que otros procesos funcionales sean de Lectura o Entrada en este mismo grupo de datos D2, pero su funcionalidad no se ve afectada por la modificación porque estos no utilizan los cambios ni los nuevos atributos de datos. Estos procesos funcionales siguen para procesar el grupo de datos reubicado como si fuese aún D1. Así, según la norma (b), estos movimientos de datos en los otros procesos funcionales que no son afectados por la modificación del movimiento de dato(s) funcional de un proceso no deben ser identificados y contados como modificados.

4.4.2 Tamaño del software funcionalmente modificado

Después del cambio funcional de una pieza de software, su nuevo tamaño total equivale al tamaño original, más el tamaño funcional de todos los nuevos movimientos de datos, menos el tamaño funcional de todos los movimientos de datos retirados. Los movimientos de datos modificados no tienen influencia sobre el tamaño de la pieza de software ya que estos existen tanto antes como después de que las modificaciones han sido realizadas.

4.5. Extensiones del método de medición COSMIC.

4.5.1. Introducción

El método de medición COSMIC de tamaño funcional no pretende medir todos los aspectos del software ‘tamaño’. Así, el método de medición COSMIC actualmente no está diseñado para proporcionar una forma estándar de contabilidad del tamaño de ciertos tipos de Requisitos funcionales de Usuario, especialmente algoritmos matemáticos complejos o secuencias de normas complejas que se encontraron en sistemas expertos.

También, la influencia del número de atributos por movimiento de datos sobre software en el tamaño del software no es capturado por este método de medición. La influencia sobre el tamaño de la manipulación de sub-procesos de datos es tenida en cuenta para simplificar la suposición de que es válido sólo para determinados dominios de software, tal como se define en la sección 1.1.1 sobre la aplicabilidad del método.

Otros parámetros tales como ‘complexión’ (no obstante definido) se podrían considerar que contribuyen al tamaño funcional. Un debate constructivo sobre esta cuestión es si primero se requerirían definiciones comunes acordadas de los otros elementos dentro de la mala noción definida de ‘tamaño’ como se aplica al software. Tales definiciones son todavía, en este punto, objeto de investigación y de mucho debate.

Sin embargo, la medida de tamaño COSMIC se considera una buena aproximación para el estado del método propuesto y el dominio de aplicabilidad. Sin embargo, puede ser que dentro del entorno local de una organización que utilice el método de medición COSMIC, se desee para tener en cuenta esa funcionalidad en una forma que sea válida como una norma local. Por esta razón, el método de medición COSMIC tiene disposición para extensiones locales.

Cuando esas extensiones locales son utilizadas, los resultados de medición deben ser comunicados según la convención especial presentada en la sección 5.1.

Las siguientes secciones muestran como extender el método con un estándar local.

4.5.2. Extensiones locales con algoritmos complejos.

Si se considera necesario para tener en cuenta algoritmos complejos, puede organizarse un estándar local para esta funcionalidad excepcional. En cualquier proceso funcional donde existe una anormalmente compleja manipulación de datos de un sub-proceso funcional, el medidor está libre de asignar su propia determinación-local de puntos de función.


63

Ejemplo: Una extensión local de la norma puede ser: “En nuestra organización, un punto de función local FP se asigna a algoritmos matemáticos como (lista de definiciones locales y ejemplos bien entendidos). Dos puntos de función locales FP’s son asignados para (otra lista de ejemplos), etc.”

4.5.3. Extensión Local con sub-unidades de medida

Cuando se necesita más precisión en la medición de los movimientos de datos, entonces se puede definir una sub-unidad de medida. Por ejemplo, un medidor puede ser sub-dividido en 100 centímetros o 1000 milímetros. Análogamente, el movimiento de un único atributo podría ser utilizado como sub-unidad de medida. Las mediciones sobre una pequeña muestra de software en los ensayos de campo de COSMIC indican que en la muestra medida, el número promedio de atributos de datos por movimiento de datos no varía mucho en los cuatro tipos de movimiento de datos. Por esta razón y por motivos de facilitar las mediciones, la unidad de medida de COSMIC, 1 CFP, ha sido fijada en el nivel de un movimiento de datos. Sin embargo, la precaución es claramente necesaria cuando se comparan los tamaños medidos en CFP (puntos de función COSMIC) de dos piezas de software distintas donde el número promedio de atributos datos por movimiento difiere notablemente en ambas.

Cualquiera que desee perfeccionar el método COSMIC al introducir una sub-unidad de medida es libre de hacerlo, pero debe dejar claro que el tamaño resultante medido no se expresa en el estándar de puntos de función COSMIC.


64

55 INFORME DE MEDIDAS

El modelo de software genérico puede ser representado en una matriz donde las filas representen procesos funcionales (los cuales puedan ser agrupados en capas), las columnas representan grupos de datos y las celdas describen el sub-proceso identificado (Entrada, Salida, Lectura y Escritura). Esta representación del Modelo de Software Genérico se presenta en el apéndice A.

Los resultados de medida COSMIC deben ser reportados y archivados de acuerdo a las siguientes normas:

5.1 Etiquetado

Al informar de un tamaño funcional COSMIC se debería etiquetar de acuerdo a la siguiente regla, relacionada con el estándar ISO/IEC 14143-1:2007.

Reglas – Etiquetado de las medidas COSMIC

Los resultados de medida COSMIC se deberían anotar como “x CFP(v.y)”, donde:

• “x” representa el valor numérico del tamaño funcional • “v.y” representa la identificación de la versión estándar del método COSMIC usado

para obtener el valor numérico del tamaño funcional “x”.

Nota: Si un método de aproximación local se usó para obtener la medida, pero aparte la medida se hizo utilizando las normas de la versión estándar COSMIC, la regla de etiquetado anterior debería utilizarse, pero en algún sitio se deberá anotar el uso del método de aproximación.-ver sección 5.2.

Ejemplo: Un resultado obtenido empleando las reglas de este Manual de Medición se debería denotar como ‘x CFP (v3.0.1)’.

Cuando se usan extensiones locales, como se define en la sección 4.5, el resultado de la medida debe ser informado como se define a continuación:

Reglas – Etiquetado de extensiones locales COSMIC

Un resultado de medida COSMIC utilizando extensiones locales debería ser anotado como:

“x CFP(v.y) + Z Local FP”, donde:

• “x” representa el valor numérico obtenido al agregar todas los resultados de medidas individuales de acuerdo al método estándar COSMIC, versión v.y.

• “v.y” representa la identificación de la versión estándar del método COSMIC usado para obtener el valor numérico de tamaño funcional “x”.

• “z” representa el valor numérico obtenido al agregar todos los resultados individuales de medida obtenidos de las extensiones locales al método COSMIC.


65

5.2 Archivando los resultados de medida COSMIC

Al archivar los resultados de medida COSMIC, se debe mantener la siguiente información para asegurar que el resultado sea siempre interpretable.

Reglas – Hacer informes de medidas COSMIC

Además de las medidas reales, descritas en el punto 5.1, se deberían tener en cuenta los siguientes atributos de cada medida.

a) Identificación del componente de software medido (nombre, versión ID o Configuración ID)

b) Las fuentes de información usadas para identificar el FUR utilizado para la medida. c) El ámbito del software d) Una declaración del propósito de la medida e) Una descripción del alcance de la medida y su relación con el alcance global de una

serie de medidas relacionadas, si las hubiera. (Usar las categorías de alcance genéricas de la sección 2.2)

f) Los usuarios funcionales del software g) El nivel de granularidad del FUR y el nivel de descomposición del software h) El punto en el ciclo de vida del proyecto cuando se hizo la medida (especialmente si

la medida es una estimación basada en FUR incompletas, o si en realidad se hizo sobre la bases de funcionalidad repartida).

i) El objetivo o margen de error que se cree para la medida j) Indicaciones de si el método de medida estándar COSMIC fue utilizado, y/o se usó

una aproximación local al método estándar y/o se utilizaron extensiones locales (ver sección 4.5). Usar las reglas de etiquetado de las secciones 5.1 y 5.2.

k) Una indicación de si la medida es de funcionalidad desarrollada o entregada (funcionalidad “desarrollada” se obtiene creando nuevo software; funcionalidad “entregada” incluye funcionalidad desarrollada y también incluye funcionalidad obtenida por otros medios diferentes a crear nuevo software, p.ej: incluir todas las formas de reutilización de software existente, el uso de parámetros existentes para añadir o cambiar funcionalidad, etc.).

l) Una indicación de si la medida es de funcionalidad recientemente proporcionada o si es el resultado de un “incremento” de actividad (p.ej: la suma es de funcionalidad añadida, cambiada o borrada-ver 4.4)

m) Una descripción de la arquitectura de capas de las que está hecha la medida, si es aplicable

n) El número de componentes importantes, si es aplicable, cuyos tamaños han sido añadidos para el tamaño total grabado

o) Para cada alcance dentro del alcance global de la medida, una matriz de medida, como se especifica en el apéndice A

p) El nombre del medidor y cualquier certificado de cualificación de COSMIC


66

AAppéénnddiiccee AA

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

La siguiente estructura de matriz puede ser usada para contener los resultados de la mediciones para cada componente identificado del modelo de software al ser medido. Cada alcance dentro del alcance global tiene su propia matriz.

FASE DE REPRESENTACIÓN

• Cada grupo de datos identificados se registra en una columna. • Cada proceso funcional es registrado en una línea específica, agrupados por componente

identificado.

FASE DE MEDICIÓN

• Por cada proceso funcional identificado, los movimientos de datos identificados son anotados en su correspondiente celda de la siguiente manera: “E” para una Entrada, “X” para una Salida, “R” para una Lectura y “W” para una Escritura.

• Por cada proceso funcional identificado, los movimientos de datos se suman por tipo y cada total es registrado en la columna correspondiente en el extremo derecho de la matriz.

• El resumen de la medición puede ser calculado y registrado en los recuadros de cada componente, en la línea de “TOTAL”.


67

AAppéénnddiiccee BB

APÉNDICE B – RESUMEN DE LOS PRINCIPIOS DEL MÉTODO C OSMIC

La siguiente tabla identifica los principios del método COSMIC de medición con el propósito de una referencia precisa.

ID DESCRIPCIÓN PRINCIPAL

P-01 El modelo contextual de Software de COSMIC

a) El hardware es la frontera del software. b) El software, típicamente, se estructura en capas. c) Una capa puede contener una o más partes separadas de software semejante y

cualquier parte de software puede por tanto constar de varios componentes semejantes separados.

d) Cualquier parte de software a medir, debe ser definida por su alcance de aplicación de medición, que debe estar enteramente contenido en una sola capa.

e) El alcance de una parte de programa a medir depende del propósito de la medición. f) Los usuarios funcionales de una parte de software deben ser identificados de los

requerimientos funcionales de usuario de una parte de software a medir como los emisores y/o supuestos destinatarios de datos.

g) Una parte de software interactúa con sus usuarios funcionales a través de movimientos de datos dentro de un entorno y esa parte de programa puede mover datos hacia y desde un almacenamiento permanente dentro de dicho entorno.

h) Los requisitos funcionales de usuario deben ser expresados en diferentes niveles de granularidad .

i) El nivel de granularidad al que las mediciones debería hacerse normalmente es el de los procesos funcionales .

j) Si no es posible medir en el nivel de granularidad los procesos funcionales, entonces los requisitos funcionales de usuario del software debe ser medido por aproximación y escalado al nivel de granularidad del proceso funcional.

P-02 El Modelo Genérico de Software COSMIC

a) El software recibe entradas de datos de sus usuarios funcionales y produce unas salidas de datos , y/u otros resultados, para los usuarios funcionales.

b) Los requerimientos del usuario funcional de una parte de software a medir se puede asignar a un proceso funcional único.

c) Cada proceso funcional consta de sub-procesos d) Un sub-proceso puede ser tanto un movimiento como una manipulación de datos. e) Cada proceso funcional es activado por un movimiento de una entrada de datos de un

usuario funcional el cual informa al proceso funcional de que el usuario funcional ha identifico un evento

f) Un movimiento de datos mueve un único grupo de datos. g) Un grupo de datos consta de un único juego de atributos de datos que describen un

único objeto de interés. h) Hay cuatro tipos de movimientos de datos. Una Entrada introduce un grupo de datos

al software de un usuario funcional. Una Salida manda un grupo de datos desde el programa a un usuario funcional. Una Escritura mueve un grupo de datos desde el software al almacenamiento permanente. Una Lectura mueve un grupo de datos desde el almacenamiento permanente al programa.

i) Un proceso funcional debe incluir al menos un movimiento de Entrada de datos y


68

también otro de Escritura o Salida, esto es, al menos dos movimientos de datos. j) Como una aproximación a efectos de medición, los sub-procesos de manipulación de

datos o se miden por separado; la funcionalidad de cualquier manipulación de datos se asume que debe ser contada por el movimiento de datos al que se encuentra asociada.

P-03 Principio de medida de COSMIC

El tamaño funcional de una parte de software es directamente proporcional al número de sus movimientos de datos

P-04 Capa

a) El software en una capa intercambia datos con el software de otra capa mediante sus respectivos procesos funcionales.

b) La ‘dependencia jerárquica’ entre capas es tal que el software en una capa puede usar los servicios funcionales de cualquier software en una capa jerárquicamente inferior. Done existan ese tipo de relaciones de uso, designamos a la capa que usa el software como la ‘superior’ y cualquiera que contenga el software usado como su ‘subordinada’. El software en la capa superior confía en los servicios del software en dichas capas subordinadas para funcionar correctamente; la subordinada confía a su vez en el de sus capas inferiores para funcionar correctamente, y así sucesivamente hacia abajo en la jerarquía. Inversamente, el software en una capa subordinada junto con el software de cualquier capa de la que dependa puede funcionar sin necesidad de los servicios del software de ninguna de las capas superiores en la jerarquía.

c) El software de una capa no necesita usar todas las funcionalidades suministradas por el software de una capa subordinada.

d) Los datos que se intercambian entre programas en dos capas cualquiera es definido en interpretado de forma diferente en el respectivo FUR de dos partes del software, esto es, dos partes del programa reconoce diferentes atributos de datos y/o subgrupos de datos que intercambian. En cualquier caso debe existir también una o más atributos o subgrupos de datos definidos en común para permitir al programa en la capa receptora interpretar los datos enviados por el programa en la capa emisora, de acuerdo a las necesidades de recepción del programa.

P-05 Componentes semejantes

a) En un conjunto de componentes semejantes de una parte del programa dentro de una capa no hay dependencia jerarquía entre los componentes como la que hay entre las capas. El FUR de todos los componentes similares de una parte del programa en cualquier capa están en el ‘mismo nivel’ en la jerarquía de capas.

b) Todos los componentes semejantes de una parte del programa deben cooperar mutuamente para que esa parte del programa pueda funcionar correctamente.

c) Un grupo de datos puede ser intercambiado directamente entre dos componentes semejantes de una parte del programa a través de un proceso funcional de un primer componente realizando una Salida que es recibido por una Entrada por un proceso funcional del segundo componente. Alternativamente el intercambio puede tener lugar indirectamente a través del proceso funcional de un primer componente enviando haciendo una Escritura de un grupo de datos que puede luego ser recuperado mediante una lectura de un proceso funcional del segundo componente.

P-06 Aplicando el Modelo Genérico de Software COSMIC

El Modelo Genérico de Software COSMIC debe ser aplicado a los requerimientos del usuario funcional para cada parte separada del programa para la que se haya definido un alcance de medición diferente.

‘Aplicando el Modelo Genérico de Software COSMIC’ significa identificar el conjunto de sucesos de activación detectados para cada uno de los usuarios funcionales (tipos), identificados en el FUR, y después identificar los correspondientes procesos funcionales,


69

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

P-07 Grupos de datos

a) Cada grupo de datos identificado debe ser único y distinguible a través de su colección única de atributos de datos.

b) Cada grupo de datos debe estar directamente relacionado con un objeto de interés en los Requisitos Funcionales de Usuario (FUR), del programa.

c) Un grupo de datos se materializa dentro del sistema del ordenador que soporta el programa.

P-08 Entrada (E)

a) Una entrada debe mover un único grupo de datos que describen a un único objeto de interés desde un usuario funcional a través del entorno a un proceso funcional del que esta Entrada forme parte. Si la entrada de un proceso funcional comprende más de un grupo de datos, identificar una Entrada para cada grupo de datos únicos (ver también sección 4.1.7. sobre unicidad de movimiento de datos).

b) Una Entrada no debe enviar datos que crucen la frontera, ni lee ni escribe datos. c) Donde un proceso funcional necesite obtener datos de un usuario funcional pero más

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

Sin embargo, cuando un proceso funcional deba obtener algún dato de un usuario funcional y el proceso funcional deba decirle al usuario funcional con datos que después requieran rellenar la petición, contar una Salida para la petición y una Entrada para la devolución de los datos pedidos (para más información ver sección 4.1.9).

P-09 Salida (X)

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

b) Una Salida no introduce datos a través de la frontera, ni lee ni escribe datos.

P-10 Lectura (R)

a) Una Lectura debe mover un único grupo de datos que describa a un único objeto de interés de un almacenamiento permanente a un proceso funcional del cual forma parte la lectura. Si los procesos funcionales deben recuperar más de un grupo de datos del almacenamiento permanente, identificar una Lectura por cada grupo de datos único que es recuperado (ver también la sección 4.1.7 ‘Movimiento de datos únicos’).

b) Una Lectura no debe recibir ni enviar datos a través de la frontera, ni escribir datos. c) Durante un proceso funcional, el movimiento o manipulación de constantes o variables

que son internas al proceso funcional y que pueden ser cambiadas solo por un programador, o un cómputo de resultados intermedios de un cálculo, o datos almacenados por un proceso funcional que resultan sólo de la implementación, en lugar de del FUR, no deben ser considerados como movimientos de Lectura.

d) Un movimiento de Lectura siempre incluye alguna funcionalidad de ‘petición de Lectura’ (así que no se debe contar nunca un movimiento separado de datos para ninguna ‘petición del Lectura’). Véase también sección 4.1.9.

P-11 Escritura (W)

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


70

interés del proceso funcional del que la Escritura forma parte al almacenamiento permanente. Si el proceso funcional debe mover más de un grupo de datos al almacenamiento permanente, identificar una escritura para cada único grupo de datos que se mueva al almacenamiento permanente (ver también sección 4.1.7).

b) Una Escritura no debe recibir ni enviar datos a través de la frontera, ni leer datos. c) Un requerimiento para borrar un grupo de datos de un almacenamiento permanente

debe ser medido como un único movimiento de datos de Escritura. d) Durante un proceso funcional, el movimiento o la manipulación de los datos que no

continúan cuando el proceso funcional es completado, o la actualización de variables las cuales son internas al proceso funcional, o resultados producidos por un cálculo intermedio no deben ser considerados como una Escritura.

P-12 Manipulación de datos asociada con movimiento de da tos

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


71

AAppéénnddiiccee CC

APÉNCIDE C – RESUMEN DE LAS REGLAS DEL METODO COSMI C

Con el propósito de ser unas referencias precisas, la siguiente tabla identifica cada regla del método COSMIC

ID DESCRIPCIÓN DE LA REGLA

R-01 Alcance

a) El alcance de una Medición del Tamaño Funcional (FSM), debe ser derivada de los propósitos de la medición.

b) El alcance no debe extenderse sobre más de una capa del software a medir.

R-02 Capa

a) Si el software se concibe usando una arquitectura establecida en capas según el modelo COSMIC, entonces dicha arquitectura se debe utilizar para identificar las capas a efectos de medición.

b) En el dominio de MIS o software de gestión, la capa superior (por ejemplo, la capa que no está subordinada a ninguna otra capa), está normalmente referenciada como la capa de ‘aplicación’. El software en esta capa confía en los servicios del software en todas las otras capas para funcionar correctamente. En el dominio del software en tiempo real la ‘capa superior’ se referencia normalmente como ‘sistema’ (como por ejemplo en el ‘software del sistema de control de proceso’, ‘software del sistema de control de vuelo’…).

c) No debe asumirse que cualquier software que se ha desarrollado fuera de cualquier consideración de diseño o estructura puede ser particionada en capas acorde al modelo COSMIC.

R-03 Usuarios Funcionales

a) Los usuarios funcionales de una parte del software medido deben deducirse del propósito de la medición.

b) Cuando el propósito de una medición de una parte del software se relaciona con el esfuerzo para desarrollar o modificar una parte del software, entonces los usuarios funcionales deben ser aquellos para quienes se desarrolla la nueva o modificada funcionalidad.

R-04 Frontera

a) Identifica al usuario o usuarios funcionales que interactúan con el software que está siendo medido. La frontera se encuentra entre los usuarios funcionales y el software.

b) Por definición hay una frontera entre cada par de capas identificadas donde el software en una capa es el usuario funcional del software en la otra, y la última es la que será medida.

c) Hay una frontera entre cualquiera de dos partes de software, incluyendo dos componentes cualquiera que son semejantes entre sí; en este caso cada parte del software y/o cada componente pueden ser un usuario funcional del otro.

R-05 Nivel de granularidad de los procesos funcionales

a) La medida del tamaño funcional debe hacerse en el nivel de granularidad de los procesos funcionales.

b) Cuando la medición de un proceso funcional necesita de algún FUR que no haya evolucionado aún al nivel donde todos los procesos funcionales han sido identificados y todos los detalles de sus movimientos de datos han sido definidos, deben hacerse


72

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

R-06 Procesos Funcionales

a) Un proceso funcional debe ser derivado de al menos un Requisito Funcional de Usuario dentro del alcance acordado.

b) Un proceso funcional debe ser ejecutado cuando ocurre un evento de activación identificable.

c) Un suceso específico puede activar uno o más procesos funcionales que se ejecuten en paralelo. Un proceso funcional específico puede ser activado por más de un suceso.

d) Un proceso funcional abarcará al menos dos movimientos de datos, una Entrada más una Salida o una Escritura.

e) Un proceso funcional debe pertenecer enteramente al alcance de medición de una parte del software en una y sólo una capa.

f) En el contexto de un software de tiempo-real un proceso funcional debe considerarse terminado cuando entra en un estado de espera auto inducido (por ejemplo, el proceso funcional que hace todo lo requerido en respuesta de la activación de un evento y espera hasta que recibe la próxima Entrada que lo activa).

g) Un proceso funcional debe ser identificado incluso si su Requisito Funcional de Usuario permite que el proceso funcional pueda ocurrir con diversos subconjuntos de su máximo número de atributos de datos de entrada, e incluso aunque tales variaciones y/o diferentes valores de datos de entrada puedan dar lugar a diferentes caminos de proceso a través del proceso funcional.

h) Deben distinguirse eventos separados y por lo tanto procesos funcionales separados en los siguientes casos:

• Cuando las decisiones dan lugar a eventos diferentes separados en el tiempo (ejemplo, introducir una orden de datos hoy y después confirmar la aceptación de esa orden requieren decisiones separadas y deben ser considerados como procesos funcionales separados).

• Cuando la responsabilidad de las diferentes actividades no es única (ejemplo, en un sistema personal donde la responsabilidad de mantener los datos personales se encuentra separada de mantener los datos que identifican un pago; o para un paquete implementado de software donde es responsabilidad del administrador el mantenimiento, y eso está separado de la funcionalidad disponible para el usuario normal).

R-07 Entrada (E)

a) El grupo de datos de una Entrada que activa un proceso puede constar de sólo un atributo de datos que simplemente informa al software de que ‘un evento Y ha sucedido’. Muy a menudo, especialmente en aplicaciones de gestión este tipo de entradas tienen varios atributos de datos que informan al programa de que ‘un evento Y ha sucedido, y aquí están los datos sobre ese evento en particular’.

b) Los tics de reloj que disparan sucesos deben ser siempre externos al software que se mide. Así, por ejemplo, un evento activado por un tic que sucede cada 3 segundos debe ser asociado con un movimiento de Entrada de un atributo de datos. Nótese que no hay diferencia si el evento es generado periódicamente por hardware o por otro programa externo a la frontera del software que se está midiendo.

c) Salvo que un proceso funcional específico sea necesario, obtener el tiempo del reloj del sistema no debe considerarse que causa una Entrada.

d) Si una ocurrencia de un evento específico dispara la Entrada de un grupo de datos que comprende ‘n’ atributos de datos de un objeto de interés en particular y el FUR permite que otras ocurrencias del mismo evento puedan activar una Entrada de un


73

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

R-08 Salida (X)

a) Todos los mensajes y datos de salida generados por el software sin interacción del usuario (por ejemplo, mensajes de error), deben ser considerados como valores de un atributo de un objeto de interés (los cuales pueden ser llamados ‘indicación de error’). Por lo tanto, será identificada para representar todas estas ocurrencias una sola Salida dentro de cada proceso funcional donde son requeridas por los FUR.

b) Si una Salida de un proceso funcional mueve un grupo de datos con ‘n’ atributos de un objeto de interés en particular y el FUR permite que el proceso funcional pueda tener una ocurrencia de una Salida que mueve un grupo de datos con valores de atributos de sólo un subconjunto de ‘n’ atributos de un objeto de interés, entonces debe ser considerada una Salida, que comprende los ‘n’ atributos de datos.

R-09 Unicidad de movimiento de datos y posibles excepcio nes

a) A menos que un Requisito Funcional de Usuario especifique otra cosa, todos los atributos de datos que describen cualquier objeto de interés que es requerido para ser incorporado en un proceso funcional, y la manipulación de datos asociada debe ser identificada y contada como una única Entrada. (Nota: Un proceso funcional puede, por supuesto, ser requerido para múltiples procesos de Entrada, cada una moviendo un grupo de datos describiendo un objeto de interés diferente). La misma regla se aplica a cualquier movimiento de datos de Lectura, Escritura o Salida en cualquier proceso funcional).

b) Más de un movimiento de Entrada de datos, cada uno moviendo un grupo de datos que describe el mismo objeto de interés en un proceso funcional dado, puede ser identificado y contado si hay un Requisito Funcional de Usuario de estas Entradas múltiples. Similarmente, más de un movimiento de Entrada que mueve el mismo grupo de datos en el mismo proceso funcional, pero cada uno con diferentes datos manipulados, puede ser identificado y contado si hay un Requisito Funcional de Usuario para estas Entradas múltiples. Ese FUR puede presentarse cuando, en un proceso funcional, las múltiples entradas originadas desde diferentes usuarios funcionales introducen diferentes grupos de datos (cada uno describiendo el mismo objeto de interés). La misma regla se aplica a cualquier movimiento de datos de Lectura, Escritura o Salida en cualquier proceso funcional.

c) Repetidas ocurrencias de un tipo de movimiento de datos (por ejemplo, mover el mismo grupo de datos con la misma manipulación de datos), no debe ser identificada y contada más de una vez en ningún proceso funcional.

d) Incluso si las múltiples ocurrencias de un tipo de movimiento de datos en un proceso funcional dado difieren en la manipulación de datos asociada porque los diferentes valores de los atributos de datos en el grupo de datos movidos dan como resultado el seguir diferentes caminos de proceso, el tipo de movimientos de datos no debe ser identificado y contado más de una vez en el proceso.

R-10 Cuando un proceso funcional requiere datos de un us uario funcional

a) Un proceso funcional debe obtener un grupo de datos en una Entrada de datos de un usuario funcional, cuando no necesita decirle al usuario funcional qué datos enviar, como en uno de los siguientes cuatro casos:

• cuando un usuario funcional envía una Entrada que acciona el inicio del proceso funcional;

• cuando un proceso funcional, habiendo recibido una Entrada de activación, espera, la llegada de otra Entrada adicional desde el usuario funcional, (puede


74

ocurrir cuando una persona introduce datos a la aplicación software); • cuando un proceso funcional habiendo empezado, pide al usuario funcional

‘envíame tus datos ahora, si tienes algo que enviar’, y el usuario funcional envía sus datos;

• cuando un proceso funcional, habiendo empezado, inspecciona el estado de un usuario funcional y recupera los datos que necesita.

En los últimos dos casos (ocurren típicamente en las aplicaciones de tiempo real), por convenio no se identificará ninguna Salida del proceso funcional para obtener los datos requeridos. El proceso funcional necesita simplemente enviar un mensaje de aviso al usuario funcional y la funcionalidad del mensaje de aviso se considera parte de la Entrada. El proceso funcional sabe qué datos espera. Sólo se necesita una Entrada para esta casa.

b) Cuando un proceso funcional necesita obtener los servicios de un usuario funcional (como paso previo a obtener datos), y el usuario funcional necesita que le digan qué enviar (típicamente esto ocurre cuando el usuario funcional es otra parte del software fuera del alcance del software que está siendo medido), deben ser identificados un par de movimientos de datos de Entrada/Salida. La Salida contiene la petición de los datos específicos; la Entrada contiene los datos devueltos.

R-11 Comandos de control en el dominio de las aplicacion es de gestión

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

R-12 Agregación de los resultados de la medición

a) Para cualquier proceso funcional, los tamaños funcionales de los movimientos de datos individuales serán agregados en un solo valor de tamaño funcional en unidades CFP, sumándolas aritméticamente. Tamaño (proceso funcionali) = ∑ tamaño(Entradasi)i+ ∑ tamaño(Salidasi) +

∑ tamaño(Lecturasi) + ∑ tamaño (Escriturasi)

b) Para cualquier proceso funcional, el tamaño funcional de los cambios de sus Requisitos Funcionales de Usuario serán agregados desde los tamaños de los movimientos de datos que han sido añadidos, modificados o borrados en el proceso funcional para dar un tamaño del cambio en unidades CFP, de acuerdo a la siguiente fórmula. Tamaño (Cambios(proceso funcionali)) =

∑ tamaño (movimiento de datosi añadido) +

∑ tamaño (movimiento de datosi modificado) +

∑ tamaño (movimiento de datosi eliminados)

Para más información sobre la agregación del tamaño funcional ver sección 4.3.2. Para la medición del tamaño de los cambios del software, ver sección 4.4.

c) El tamaño de cualquier cambio de una parte del software dentro del alcance definido será obtenido por la agregación de los tamaños de los procesos funcionales de cada parte, sujeto a las reglas e) y f) de abajo.

d) El tamaño de cualquier cambio de una parte del software dentro del alcance definido será obtenido sumando los tamaños de todos los cambios de todos los procesos funcionales de cada parte, sujeto a las reglas e) y f) de más abajo.

e) Los tamaños de las partes del software o de los cambios de las partes del software dentro de las capas pueden ser sumado sólo si se miden en el mismo nivel de granularidad del proceso funcional de su FUR.

f) Además, los tamaños de las partes del software y/o los cambios de los tamaños de una parte del software dentro de una capa o de diferentes capas serán sumados sólo si tiene sentido hacerlo así, según el propósito de la medición.

g) El tamaño de una parte del software no puede ser obtenido sumando los tamaño de


75

sus componentes (sin importar cómo se subdivide), a menos que las contribuciones del tamaño de los movimientos de datos entre componentes se eliminen.

h) Si el método COSMIC se extiende localmente (por ejemplo para medir algunos aspectos de tamaño no cubierto por el método estándar), entonces el tamaño medido por la extensión local debe documentarse separadamente como se describe en la sección 5.1 y no debe añadirse al tamaño obtenido por el método estándar, medido en CFP (ver en la sección 4.5).

R-13 Modificación de un movimiento de datos

a) Si un movimiento de datos debe ser modificado debido a un cambio en la manipulación de los datos asociada al movimiento de datos y/o debido a un cambio en el número o tipo de atributos en el grupo de datos movidos, un CFP cambiado será medido, sin importar el número real de modificaciones en el movimiento de datos.

b) Si un grupo de datos debe ser modificado, los movimientos de datos que mueven los grupos de datos modificados cuya funcionalidad no se ve afectada por la modificación al grupo de los datos no será identificado como movimientos de datos cambiados.

NOTA 1: Una modificación a un valor de una ocurrencia de un atributo, tal como una modificación en un código de un atributo cuyo valor venga dado por un sistema de codificación no es una modificación del tipo del atributo.

NOTA 2: Una modificación a cualquier dato que aparece en pantallas de entrada o salida que no estén relacionadas con un objeto de interés para un usuario funcional no debe identificarse como un CFP cambiado (ver la sección 3.3.4 para ejemplos de ese tipo de datos).

R-14 Etiquetado de la medida COSMIC

El resultado de una medida COSMIC debe ser denotada como ‘x CFP (v.y)’ donde:

• ‘x’ representa el valor numérico del tamaño funcional, • ‘v.y’ representa la versión estándar del método COSMIC usado para la obtención del

valor del tamaño funcional ‘x’.

NOTA: Si se ha usado un método de aproximación local para obtener la medida, pero además la medida se hizo usando las convenciones de una versión estándar de COSMIC, el etiquetado anterior debe ser usado, pero el uso de ese método de aproximación debería ser anotada de alguna manera – ver sección 5.2.

R-15 Etiquetado de la extensiones locales de COSMIC

El resultado de una medida COSMIC usa las extensiones locales denotadas como:

‘x CFP (v. y) + z Local FP’, donde:

• ‘x’ representa el valor numérico obtenido sumando todos los resultados de la medición del método estándar COSMIC, versión v.y,

• ‘v.y’ representa la versión del método estándar COSMIC usado para obtener el valor del tamaño funcional ‘x’,

• ‘z’ representa el valor numérico obtenido sumando todos los resultados individuales obtenidos de las extensiones locales del método COSMIC.

R-16 Inform es de medida COSMIC Además de las medidas reales, deberían ser registrados los siguientes atributos de cada medición. a) Identificación del componente software medido (nombre, identificación de la versión o

identificación de la configuración). b) Las fuentes de información empleadas para la identificación de los FUR en la

medición. c) El dominio del software.


76

d) Una declaración del propósito de la medición. e) Una descripción del alcance de la medición, y su relación con el alcance global de un

conjunto relacionado de medidas, si las hubiere (usar las categorías de alcance genéricas de la sección 2.2).

f) Los usuarios funcionales del software. g) El nivel de granularidad de los FUR y el nivel de descomposición del software. h) El punto del ciclo de vida del proyecto en que la medida fue hecha (especialmente si la

medida es una estimación basada en FUR incompletos, o fue hecha en base a una funcionalidad entregada realmente).

i) El objetivo o margen de error supuesto en la medición. j) Indicaciones de si se ha usado la medición estándar del método COSMIC, y/o una

aproximación local para el método estándar, y/o cualquier extensión local (ver sección 4.5). Usar las convenciones de etiquetado de las secciones 5.1 o 5.2.

k) Una indicación de si la medida es de funcionalidad desarrollada o entregada (la funcionalidad ‘desarrollada’ se obtiene creando software nuevo; la entregada incluye la desarrollada y también la obtenida por cualquier otro medio que no sea la creación de nuevo software como por ejemplo todas las formas de reutilización de software existente, el uso de parámetro preexistentes para añadir o cambiar funcionalidad, etc.).

l) Una indicación de si la medición es de una nueva funcionalidad suministrada o es el resultado de una actividad de ‘mejora’ (por ejemplo la suma de una funcionalidad añadida, cambiada y borrada - ver 4.4).

m) Si fuera aplicable, una descripción de la arquitectura de las capas en la cuales la medición fue realizada.

n) Si fuera aplicable, el número de componentes principales, cuyos tamaños se han sumado para el tamaño total registrado.

o) Para cada alcance dentro del alcance de medición global, una matriz, según lo especificado en el apéndice A.

p) El nombre de la persona que hace la medición y las acreditaciones de calidad COSMIC.


77

AAppéénnddiiccee DD

APÉNDICE D – HISTORIA DEL MÉTODO COSMIC

Este apéndice contiene un resumen de los principales cambios desde la versión 2.2 a través de la versión 3.0 a la versión 3.0.1. del método COSMIC de medición del tamaño funcional. La versión 2.2 del método fue descrita en el ‘Manual de Medición v2.2’ (abreviado como ‘MM’), pero desde la versión 3.0 en adelante la documentación del método está distribuida en cuatro documentos, sólo uno de los cuales es el ‘Manual de Medición’.

El propósito del apéndice es permitir a un lector que esté familiarizado con el MM v2.2 rastrear los cambios que se han hecho para las versiones 3.0 y 3.0.1 y cuando sea necesario para comprender su justificación. (Para los cambios realizados en la obtención de la versión 2.2 desde la versión 2.1, consulte la versión 2.2 del Manual de medición, Apéndice E)

De la versión 2.2 a la versión 3.0

En la tabla siguiente se enseña los principales cambios hechos desde la versión 2.2 a la versión 3.0, se hace referencia a los dos boletines de la actualización del método (‘MUB’). Un MUB es publicado por COSMIC para proponer mejoras al método entre cambios importantes de versión. Los dos MUB son:

• MUB 1 “Mejoras propuestas para las definiciones y características de una ‘capa’ de software”, publicado in Mayo de 2003.

• MUB 2 “Mejoras propuestas para la definición de un ‘objeto de interés’ ”, publicado en Marzo de 2005.

En el proceso de actualización del método de la versión 2.2 a la versión 3.0, se ha hecho un esfuerzo para distinguir entre ‘principios’ y ‘reglas’, y separar de ellos todos los ejemplos. Cambios como estos y muchas mejoras en la redacción no se han descrito en la siguiente tabla.

V2.2 Ref V3.3 Ref Cambios

Reestructuración del Método COSMIC

2.2, 2.7, 3.1, 3.2

1.5, Capítulo 2

Una fase de la ‘Estrategia de Medición’ ha sido separada como la primera fase, de lo que ahora es un método en tres fases.

La fase de la Estrategia de Medición ahora incluye consideraciones sobre ‘capas’, ‘fronteras’, y ‘usuarios (funcionales)’, los cuales se consideran parte de la fase de representación en el MM v2.2.

Reestructuración del Manual de Medición

En la producción de la v3.0 del Método COSMIC, el MM v2.2 ha sido partido en cuatro documentos para facilitar su uso

• ‘COSMIC Method v3.0: Documentation Overview and Glossary of Terms’’ (nuevo)

• ‘COSMIC Method v3.0: Method Overview’ (Capítulos 1 y 2 del MM v2.2)

• ‘COSMIC Method v3.0: Measurement Manual’ (Capítulos 3, 4 y 5 y los apéndices del MM v2.2

• ‘COSMIC Method v3.0: Advanced and Related Topics’ (Capítulos 6 y 7 del MM v2.2)


78

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

Capítulo 4

Capítulo 4

El capítulo sobre la fase de medición se ha reestructurado considerablemente para ofrecer una exposición más lógica.

Apéndice D

-- Este apéndice sobre ‘Más información de las capas del software’ ha sido eliminado, por ser incompatible con MUB 1 y añadir poco valor. Véanse también las notas a continuación sobre los cambios teniendo en cuenta MUB 1.

Cambios en la terminología de los nombres

General El nombre ‘COSMIC-FFP’ del método ha sido simplificado por método ‘COSMIC’.

5.1 4.2 El nombre de la unidad de medición, ‘unidad de tamaño funcional COSMIC’ (abreviado como ‘Cfsu’) ha sido cambiado a ‘Punto de Función COSMIC’ (abreviado como ‘CFP’). Ver el Prólogo del MM v3.0 para la explicación de este cambio.

4.1 4.1.7 La regla de ‘des duplicidad de los movimientos de datos’ ha sido renombrada como la regla de ‘Unicidad de movimientos de datos’.

Conceptos nuevos, reemplazados y eliminados

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

3.2 2.3 El concepto de ‘usuario’ (definido en ISO/IEC 14143/1) ha sido reemplazado por el concepto de ‘usuario funcional’ el cual es un concepto más restrictivo.

Ver el Prólogo del MM v3.0 para más detalles de la explicación de este cambio.

En 2.3.2, han sido introducidos dos ejemplos de dónde el tamaño funcional varía con el tipo de usuario funcional identificado en el FUR, para un teléfono móvil y para un paquete de una aplicación de gestión.

-- 2.2.2 El ‘nivel de descomposición’ del software a medir ha sido introducido en la discusión del alcance de la medición.

-- 2.4 El ‘nivel de granularidad’ de los requisitos funcionales de usuario del software a medir ha sido introducido en la discusión de la estrategia de la medición. Se da un ejemplo para la comprensión. Ver el Prólogo del


79

MM v3.0 para más detalles de la explicación de este cambio.

-- 2.4.3 El ‘nivel de granularidad de un proceso funcional’ ha sido definido y se han dado unas reglas y unas recomendaciones.

3.4 4.2 El concepto de ‘grupo permanente de datos’ incluye tres niveles de permanencia, llamados ‘transitorio’, ‘corto’ y ‘por tiempo indefinido’ ha sido eliminado por ser innecesario. Se ha introducido el concepto de ‘almacén permanente’.

4.1 -- El concepto de ‘des duplicación’ ha sido eliminado como resultado de ser innecesario.

Mejores definiciones y perfeccionamiento de los pri ncipios y reglas

2.3 2.2 La definición de ‘Requisitos Funcionales de Usuario’ ha sido cambiada conforme a la edición de 2007 de ISO/IEC 14143/1

2.4.1 1.3 El ‘Modelo de Contexto del Software’ ha sido extendido y perfeccionado como una declaración de principios.

2.4.2 1.4 El ‘Modelo Genérico del Software’ ha sido extendido y refinado como una declaración de principios.

2.4, 3.1 2.2.3,

2.2.4,

3.1

La definición 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 interacción 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 típica arquitectura física con capas y las Figuras 3.1.1 y 3.1.2 ilustrando la interacción lógica de los usuarios funcionales con el software en capas. El objetivo de este cambio es distinguir más claramente la visión física de los programas típicos de las arquitecturas de capas de la visión lógica de una interacción del usuario funcional con una parte del software a medir de acuerdo con el modelo COSMIC.

-- 3.2.4 El concepto de ‘componente semejante’ ha sido definido y sus principios han sido establecidos tomando como referencia MUB1.

2.5 4.2, 4.3 Las ‘Características’ del proceso de medición descritas en v2.2 han sido establecidas como un conjunto de principios y reglas en v3.0.

2.6 2.4 El material de ‘midiendo el proyecto en una fase temprana: escalado de la medición’ ha sido tratada en parte en la sección 2.4 del MM v3.0 conforme al ‘Nivel de Granularidad’ y está elaborado en el documento ‘COSMIC Method v3.0: Advanced and Related Topics’.

2.7 2.2 Una nota ha sido añadida para la definición del ‘alcance’ para distinguirlo del ‘alcance total’ de un ejercicio de medida (el cual incluye varias partes separadas del software que deben ser medidas) del ‘alcance’ de un tamaño de medida individual.

3.2 4.1.8 Los tres ejemplos que ilustran la interacción de los usuarios a través de una frontera con el software en diferentes capas y desde diferentes ‘puntos de vista’ de medición han sido movidos y reescritos con la intención de eliminar los ‘puntos de vista de la medición’. Véase el


80

punto 4.1.8 (del MM v3.0), más abajo.

-- 3.1 Se ha añadido un principio relativo al Modelo Genérico de la aplicación del software a medir.

3.3 3.2.1 La definición de ‘proceso funcional’ se ha perfeccionado para tener en cuenta la introducción del concepto de ‘usuario funcional’, que sustituye a la de 'actor' en la definición.

3.3 3.2.1 La definición de ‘evento que activa’ ha sido perfeccionada.

-- 3.2.1 La relación entre un evento que activa, un usuario funcional, la activación de una Entrada y proceso funcional, se aclara en la Figura 3.1.1.

3.1 3.2.2 Los principios y reglas para un ‘proceso funcional’ se han fusionado en un conjunto revisado de normas.

-- 3.2.3, 3.2.4, 3.2.5

Se han introducido algunos ejemplos de procesos funcionales y de cómo distinguirlos.

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

3.4 3.3.3 Los ejemplos de la identificación de los objetos de interés y los grupos de datos se han separado de las normas para los grupos de datos. Material específico de los convenios de análisis de datos de entidad-relación han sido trasladados a la ‘Guideline for sizing Business Application Software v1.0’.

-- 3.3.4 Se ha dado una guía ‘para los datos o grupos de datos que no son candidatos a movimientos de datos’.

-- 3.3.5 Se dan orientaciones sobre cuándo, generalmente en software en tiempo real, puede que no valga la pena distinguir un ‘usuario funcional’ de 'un objeto de interés’ sobre qué datos son movidos.

3.5 3.4 La discusión de los ‘atributos de datos’ se ha reducido y simplificado desde que la consideración de los atributos de datos no es una parte obligatoria del método.

4.1 4.1.1 Se ha racionalizado la definición de un ‘movimiento de datos’.

4.1 4.1.7 Las reglas sobre ‘des duplicación de movimientos de datos’ (ahora llamadas como normas de ‘unicidad de movimiento de datos y posibles excepciones’) han sido mucho más claras con varios ejemplos añadidos.

4.1 -- Reglas específicas para cada dominio sobre los movimientos de datos de Lectura y Escritura que actualizan procesos funcionales han sido trasladados al documento ‘Guideline for sizing Business Application Software v1.0’.

4.1 4.1.8 ‘Las reglas para la correspondencia de datos a través de la frontera’ (las cuales en el MM v2.2 se aplicaron a ‘Los puntos de vista del


81

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

4.1 4.1.6 Se ha definido la ‘Manipulación de Datos’ y se ha añadido un principio sobre la ‘manipulación de datos asociada con los movimientos de datos’. Se ha ampliado la guía sobre la manipulación de datos asociada con los diferentes tipos de movimientos de datos.

4.1.1 4.1.2 Se han racionalizado los principios y reglas para una Entrada. Se ha añadido un nuevo principio relativo a la funcionalidad de la ‘petición de entrada’.

4.1.2 4.1.3 Se han racionalizado los principios y reglas de una Salida incluyendo la eliminación de la referencia al ‘punto de vista del usuario final’.

4.1.3 4.1.4 Se han racionalizado los principios de una Lectura. Se ha añadido un nuevo principio concerniente a la funcionalidad de la ‘petición de lectura’.

4.1.4 4.1.5 Se han racionalizado los principios de una Escritura.

-- 4.1.9 Se han añadido nuevas reglas sobre ‘cuándo un proceso funcional requiere datos de un usuario funcional’.

-- 4.1.10 Se ha introducido una definición y una regla para el concepto de ‘comando de control’ los cuales son sólo válidos en el dominio de las aplicaciones de gestión.

4.1.5 4.5 Se ha ampliado la discusión sobre ‘las extensiones locales del método’.

4.3 4.3 Se han cambiado los principios de ‘agregación de los resultados de la medición’ por reglas y se ha ampliado para cubrir las normas sobre la obtención del tamaño de una parte de software mediante la suma de los tamaños de sus componentes. El MM v2.2 se refiere sólo a esas reglas en el concepto de ‘los puntos de vista de desarrollador de la medición’. Esta restricción se ha eliminado.

-- 4.4 Se ha añadido una nueva sección con nuevas reglas sobre ‘la medición del tamaño de los cambios en el software’.

5.1 5.1 Las reglas del etiquetado de los resultados de la medición de la medida han sido cambiadas para reconocer el cambio de la unidad de medida de ‘Cfsu’ a ‘CFP’.

5.2 5.2 Para incluir más artículos se han ampliado las reglas sobre la ‘presentación de informes de la medida’.

Apéndice B Apéndice B

Actualizados a los principios de la v3.0

Apéndice C Apéndice C

Actualizados a las Reglas de la v3.0


82

De la versión 3.0 a la versión 3.0.1

El cambio más importante se encuentra de la versión 3.0 a la 3.0.1 en la mejora de la redacción de algunas definiciones, principios y normas, y algunas partes del texto. Con la excepción de un error, las mejoras han sido realizadas por razones de claridad. La mayoría de los cambios se han publicado en tres Boletines de Actualización del Método anteriores a la versión 3.0.1.

• MUB 3: ‘Corrección de un error en la Figura 4.1.8.1 (b) del Manual de Medición del Método COSMIC v3.0’, publicado en Junio de 2008.

• MUB 4: ‘Aclaración de los principios y reglas de la funcionalidad de ‘Petición de entrada’ en el Manual de Medición del Método COSMIC v3.0’, publicado en Junio de 2008.

• MUB 5: ‘Mejoras propuestas para (a) Definiciones del ‘Nivel de Descomposición’ y de ‘Componentes Semejantes’, y (b) Principio c) para un ‘Componente Semejante’, publicado en Febrero de 2009.

Además, se han hecho varias mejoras en la redacción. Principalmente mediante una separación más clara de los ejemplos en el texto principal, utilizando un tipo diferente de fuente y la introducción de más secciones.

Resumen de los cambios principales:

V 3.0.1 Cambio

2.2.3 Para mayor claridad se ha cambiado la definición del ‘Nivel de Descomposición’ (MUB 5).

2.2.4 En la definición de ‘Capa’, el término ‘arquitectura del software’ se ha sustituido por el de ‘sistema software’, ya que el término arquitectura implica que el software ya está dividido.

Regla c) eliminada. Esta fue una regla general de diseño de software y no específica para las capas y a la medición. La referencia al ‘Apéndice D’ en la versión 3.0 era incorrecta.

2.2.5 Para mayor claridad se insertó la definición de ‘Semejante’ y se cambió la definición de ‘Componente Semejante’. El principio c) para el ‘Componente Semejante’ cambió a un principio que es más importante para FSM.

La Figura 2.2.5.1 se añade para aclarar la relación entre los componentes semejantes y las partes semejantes del software (MUB 5).

2.3.2 La regla c) de los límites ha cambiado para mayor claridad (consecuencia de MUB 5).

2.4.3 En la Figura 2.4.3.1, dos cuadros en la esquina derecha de la parte inferior, ‘método de pago’ se ha cambiado por ‘medios de pago’, ya que éste es un término mejor para, por ejemplo, cheque, tarjeta de crédito, etc.

3.2.2 La regla e) para un proceso funcional se ha visto limitada por la adición de las palabras en cursiva. Ahora es: ‘Un proceso funcional se corresponde totalmente al alcance de la medición de sólo una parte de una aplicación de software, y sólo a una capa’. Esta limitación existe en la directriz para el dimensionamiento de Aplicaciones de Negocios Software' v1.1, pero es válida para el software de cualquier dominio.

3.2.6 Nueva sección añadida titulada ‘Procesos funcionales de componentes semejantes’. Este texto está tomado en gran parte del documento ‘Guideline for Sizing Business


83

Application Software’ v1.1, pero es válida para el software de cualquier dominio. Esto está relacionado con el cambio a la regla e) en el punto 3.2.2.

4.1.2 El principio c) para una Entrada ha sido cambiado para mayor claridad de cómo darse cuenta de una ‘Petición de entrada’ (MUB 4).

4.1.7 Para mayor claridad del significado deseado, ha sido cambiada la frase inicial de la sección sobre ‘Unicidad de Datos y Posibles Excepciones’ de la regla a). El ejemplo 2 también ha sido ampliamente modificado para mayor claridad.

4.1.8 La Figura 4.1.8.1 (b) ha cambiado para corregir un error sobre cómo un controlador de dispositivo interactúa con el hardware (MUB 3).

4.1.9 Para mayor claridad se han cambiado las reglas sobre ‘Cuándo un proceso funcional requiere datos de un usuario funcional’, y los ejemplos relacionados (MUB 4).


84

AAppéénnddiiccee EE

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

El Comité de Prácticas de Medición COSMIC (MPC) está ansioso de recibir opiniones, comentarios y si es necesario, Solicitudes de Cambio para el Manual de Medición COSMIC. Este apéndice precisa cómo comunicarse con el COSMIC MPC.

Todas las comunicaciones con el COSMIC MPC deben ser enviadas por e-mail a la siguiente dirección:

[email protected]

Opiniones y Comentarios Generales de manera Informa l

Los comentarios y/u opiniones concernientes al Manual de Medición, tales como las dificultades de comprensión o la aplicación del método COSMIC, sugerencias para la mejora general, etc. se deben enviar por e-mail a la dirección antes mencionada. Los mensajes se registran y, en general, serán revisados en un plazo máximo de dos semanas desde la recepción. El MPC no puede garantizar ninguna acción en respuesta a estos comentarios generales.

Solicitud de los cambios de manera formal

Podrán ser presentadas una solicitud formal de cambio (‘CR’), cuando el lector del manual de medición crea que hay un error en el texto, por la necesidad de aclaraciones, o algunas necesidades de mejora de texto.

Las CR’s formales serán tomadas en dos semanas desde la recepción. Cada CR recibirá entonces un número de serie y será reenviada a los miembros del COSMIC MPC, un grupo mundial de expertos en el método COSMIC. Su ciclo normal de revisión lleva al menos un mes y puede ser más si el CR es difícil de resolver.

Como resultado de la revisión el CR puede ser aceptado, rechazado o ‘dejado en espera para un discusión más profunda’ (este último caso por ejemplo si hay una dependencia de otro CR), y la salida será comunicada al Remitente tan pronto como sea posible.

Una petición formal de cambio sólo se aceptará si se documenta con toda la información siguiente:

• Nombre, cargo y organización de la persona que presenta la solicitud de cambio. • Datos de contacto de la persona que presenta la solicitud de cambio. • Fecha de presentación. • Declaración general de los efectos de la petición de cambio (por ejemplo, "es necesario mejorar

el texto... '). • Texto real que necesita cambiarse, sustituirse o eliminarse (o su clara referencia). • Texto adicional o de sustitución propuesta. • Explicación completa de por qué el cambio es necesario.

En el sitio www.cosmicon.com está disponible un formulario para la presentación de una petición de cambio.

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


85

Preguntas sobre la aplicación del método COSMIC.

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

manual de medición - cosmic sizing v3-0-1.pdf · el método cosmic del tamaño funcional del...

Documents