El propsito del mtodo COSMIC es proporcionar un mtodo estandarizado de
medicin del tamao funcional de software para los dominios funcionales comnmente denominados como Software de Aplicaciones de Negocio ( Management Information Systems, MIS) y Software de Tiempo Real. El mtodo COSMIC fue aceptado por el ISO/IEC JTC1 SC7 en diciembre de 2002 como el Estndar Internacional ISO/IEC 19761 Ingeniera del Software - COSMIC-FFP - Mtodo de Medicin de Tamao Funcional (en lo sucesivo en este documento se referir el mismo como ISO/IEC 19761). Para mayor claridad, ISO/IEC 19761 contiene las definiciones de las normativas fundamentales y de las reglas del mtodo. El propsito del Manual de Medicin es no slo proporcionar estas normas y definiciones, sino tambin proporcionar una explicacin ms detallada y muchos ms ejemplos a fin de ayudar a los medidores a comprender plenamente y poder aplicar el mtodo. Sin embargo, a medida que se ha ido adquiriendo ms y ms experiencia con el mtodo, se ha encontrado valioso aadir reglas y ejemplos para afinar las definiciones de algunos de los conceptos subyacentes. El Consorcio Comn Internacional de Medicin de Software (COSMIC) prev que estas adiciones y mejoras se presentarn a la ISO para su inclusin en la norma ISO/IEC 19761 en la fecha prevista para su revisin en 2007/08. Este manual de medicin es uno de los cuatro documentos COSMIC que definen la versin 3.0 del mtodo. Los otros tres son:
Descripcin de la documentacin y Glosario de trminos (El Glosario define todos los trminos que son comunes a todos los documentos COSMIC. Este documento describe tambin que se dispone de otros documentos de apoyo tales como casos de estudio y directrices de aplicacin en dominios especficos) Descripcin del Mtodo Temas Avanzados y Relacionados (Este documento tratar en ms detalle las tareas que permitan garantizar la comparacin de las mediciones de tamao funcional e incluir captulos sobre aproximacin temprana o rpida de medicin y convertibilidad de las mediciones, los cuales aparecieron anteriormente en la versin 2.2 del Manual de Medicin.)
Niveles Para ello el software se entiende que est dividido en distintos Niveles (Layers) de forma jerrquica. Cada Nivel slo puede comunicarse con sus niveles inmediatamente superior o inmediatamente inferior. Dentro de cada nivel el software se agrupa en componentes llamados Pares (Peers)teniendo todos ellos el mismo nivel jerrquico. Los Procesos Funcionales se recogen dentro de los distintos Pares. El intercambio de informacin entre distintos niveles se realiza a travs de sus respectivos Procesos Funcionales. Las entidades de una aplicacin se asocian en Grupos de Datos.
Movimientos de Datos Un Proceso Funcional se forma de distintos Movimientos de Datos que son la unidad en la que mide el mtodo. Hay 4 tipos de movimientos de datos bsicos que son: Entrada E (Entry). Un dato que cruza la aplicacin hasta el proceso funcional. Salida X (Exit). Un dato que cruza la aplicacin fuera del proceso funcional. Lectura R (Read). Mueve un nico grupo de datos a travs de la frontera de la aplicacin desde el grupo de datos hasta el proceso funcional. Escritura W (Write). Mueve un nico grupo de datos a travs de la frontera de la aplicacin desde el proceso funcional hasta el medio de almacenamiento persistente. Todo Proceso Funcional debe contemplar al menos dos movimientos de datos: una Entrada (Entry). una Salida (Exit) una Escritura (Write). Es decir, que como mnimo debe aceptar un dato de entrada y debe mostrar un dato en la salida o debe guardar en el almacenamiento persistente. Tamao El Tamao de un Proceso Funcional viene determinado por la suma del tamao de los movimientos de datos que lo forman. El tamao de una Pieza de Software en un determinado mbito se obtiene sumando los tamaos funcionales de los procesos funcionales de los cuales consta dicha pieza de software. En el caso de que estemos hablando de modificaciones de software existente, el tamao de la modificacin de un proceso funcional es la suma de los tamaos de los movimientos de datos que han sido aadidos, modificados o eliminados de dicho proceso funcional. De igual forma, el tamao de los cambios de una Pieza de Software en un determinado mbito se obtendr como la agregacin de los tamaos de los cambios de los procesos funcionales de los cuales consta dicha pieza de software. La suma total nos dar el tamao funcional del software que estamos midiendo.
Aplicabilidad del mtodo COSMIC 1.1.1 Dominios de aplicacin El mtodo de medicin del tamao funcional COSMIC est concebido para ser aplicable a la funcionalidad del software de los siguientes dominios: Aplicaciones Software de Gestin, las cuales son las tpicamente utilizadas para dar soporte a la administracin de negocios, tales como banca, seguros, contabilidad, personal, compras, distribucin o fabricacin. Este software esta a menudo caracterizado como "rico en datos", ya que est centrado principalmente en la necesidad de gestionar grandes cantidades de datos acerca de aspectos del mundo real. Software en tiempo real, cuya tarea es mantener o controlar acontecimientos que estn sucediendo en el mundo real. Algunos ejemplos seran el software para centrales telefnicas y de intercambio de mensajes, el software incluido en dispositivos para el control de mquinas tales como los electrodomsticos, ascensores, motores de automviles y aeronaves, para el control de procesos y la adquisicin automtica de datos, y software de los sistemas operativos de los Ordenadores
1.2 Requisitos Funcionales de Usuarios El mtodo de medicin COSMIC supone la aplicacin de un conjunto de modelos, principios, reglas y procesos a los Requisitos Funcionales de los Usuarios (o Functional User Requirements, FUR) de una determinada aplicacin software. El resultado es un valor de una cantidad numrico (tal y como se define en ISO), que representa el tamao funcional de la aplicacin software de acuerdo con el mtodo COSMIC. Los tamaos funcionales medidos por el mtodo COSMIC estn diseados para ser independientes de cualesquiera decisiones de implementacin propias de los artefactos operacionales del software que se desea medir. "Funcionalidad" se refiere al procesamiento de la informacin que el software debe realizar para sus usuarios.
Principios del Modelo COSMIC de Contexto de Software: a) El software est limitado por el hardware b) El software est tpicamente estructurado en capas c) Una capa puede contener una o ms aplicaciones de software semejante, y cualquier aplicacin software puede consistir de uno o ms componentes del mismo tipo separados. d) Cualquier aplicacin software que deba medirse, se define por su alcance de medicin, que se limitar en su totalidad dentro de una sola capa e) El alcance de aplicacin software debe medirse en funcin de la finalidad de la medicin f) Los usuarios funcionales de una aplicacin software se identificarn a partir de los FUR de la aplicacin software que se medir como los remitentes y/o destinatarios de los datos g) Una aplicacin software interacta con sus usuarios a travs de movimientos de datos por una frontera y la aplicacin software puede mover datos hacia y desde zonas de almacenamiento persistente dentro de unos lmites h) Los FUR de software pueden expresarse en distintos niveles de granularidad i) El nivel de granularidad en que las mediciones se hacen normalmente es el de los procesos funcionales Si no es posible medir a nivel de granularidad del proceso funcional, entonces los FUR del software deben ser medido por aproximacin y escalado al nivel de granularidad funcional del proceso
El proceso de medicin COSMIC se compone de tres fases: La Fase de Estrategia de Medicin, en la cual el Modelo de Contexto de Software se aplica al software a ser medido La Fase de la Representacin de la Medicin, en la cual el Modelo Genrico de Software se aplica al software a ser medido La Fase de Medicin, en la cual se obtienen las mediciones reales (captulo 4) El resultado de aplicar el proceso de medicin a una aplicacin software es una medida de tamao funcional de los Requisitos Funcionales de Usuario de la aplicacin software expresada en Puntos de Funcin COSMIC ( CFP)
Medicin y Estimacin de Software con el mtodo COSMIC Todos los mtodos de medicin del tamao funcional - FSM - de primera generacin (los definidos por el IFPUG) establecen lmites empricos inferiores y superiores a la cantidad de puntos de funcin que una funcionalidad pueda medir y su aplicacin bsica categoriza las funcionalidades en una camada de aplicaciones.
En los escenarios en que las demandas de medicin incluyen un nmero grande o suficiente de funcionalidades, tiende a no ser un problema en funcin del mayor potencial de los efectos de una funcionalidad subestimada, ser anulado por los efectos de una funcionalidad superestimada.
De forma similar tambin, no hay problema cuando las demandas de medicin se refieren solo a intervenciones en la camada de aplicaciones, sin la necesidad de desarrollo o manutencin en camadas de infraestructura. Pero, y si ese no fuera el caso?...Ah entra una prxima generacin de mtricas.
Cuando hay demandas pequeas donde una transaccin punturara mximo 6 FP por el mtodo del IFPUG, as hubiera necesidad de reformular toda una infraestructura en la arquitetura de software, lo que sucede es una prdida de previsibilidad en la estimacin del esfuerzo o costo a partir de la medicin; en los modelos en que la medicin cumple el papel de preescribir el costo, se aumenta el riesgo para la contratada y se potencializan precios mayores o desequilbrio econmico financiero.
En esos casos, demandas con muchos puntos de funcin y que requieren poco esfuerzo (no porque el equipo sea superproductivo) provocan una tendencia de menores tasas de entrega. Demandas con pocos puntos de funcin pero que requieren mucho esfuerzo (no porque el equipo sea incompetente) provocan mayores tasas de entrega.
El mtodo de medicin del tamao funcional de COSMIC no establece lmites arbitrarios para medicin de una funcin y naturalmente permite medir software no solo en la camada de la aplicacin, sino tambin, en camadas de infraestructura o en la necesidad de una intervencin en un componente aislado en la camada de la aplicacin... todo eso de forma adherente a las normas de la ISO(14143).
a partir de ah, ser posible un mejor:
Soporte en la generacin y evaluacin de indicadores (esfuerzo, plazo y costo) Estimacin de proyectos de desarrollo y manutencin de software Prescripcin de metas de productividad en la remuneracin de contratos
El uso de COSMIC proporciona el aumento de previsibilidad y menor variabilidad en la relacin entre la medicin del tamao funcional y del costo o esfuerzo invertido. Pudiendo ser usado en conjunto con el FPA del IFPUG o aisladamente.
Independientemente del uso del mtodo, el primer paso es conocerlo y entender como funciona la medicin para la generacin de los CFP (COSMIC Function Points). Para conocer un poco mas sobre el mtodo, consulte la pgina de la organizacin de COSMIC y tambin en nuestro Blog.
Objetivo
En lo que se refiere al mtodo de medicin del tamao funcional de COSMIC, este curso le permitir: Entender lo bsico del mtodo de medicin del tamao funcional; Discutir los principios y reglas para actividades durante todas sus fases; Medir y aproximar el tamao funcional (una de las dimensiones del alcance de un software) usando el mtodo. FASE DE ESTRATEGIA DE MEDICIN Identificar los usuarios funcionales 2.3.1 El tamao funcional vara con el usuario funcional A partir de una analoga, la medicin de la superficie de una oficina puede llevarse a cabo de acuerdo con cuatro diferentes convenios, como se indica a continuacin (ntese que el alcance la oficina en particular es la misma para los cuatro convenios). El propietario del edificio tiene que pagar impuestos por la oficina. Para el propietario, la superficie es el bruto de los metros cuadrados, determinado a partir de las dimensiones externas y, por tanto, incluidos todos los pasillos pblicos, el espacio ocupado por las paredes, etc. El responsable del aire acondicionado del edificio est interesado en la red de metros cuadrados, es decir, las zonas de interior, incluidos los las zonas pblicas y en el espacio tomado por los ascensores, pero excluyendo el espesor de las paredes El contratista del servicio de limpieza contratado por una oficina especfica del edificio est interesado en los metros cuadrados netos, que excluye los espacios pblicos, pero que incluye los pasillos utilizados por el arrendatario. El responsable de la planificacin de oficinas solo est interesado en los metros cuadrados netos tiles. La leccin de esta analoga es que el tamao de un objeto puede variar dependiendo de la funcionalidad que es de inters para diferentes tipos de usuarios del objeto. En el caso del software, diferentes usuarios funcionales podrn exigir y utilizar diferentes funcionalidades y, por tanto, los tamaos funcionales varan con la eleccin de los usuarios funcionales. 2.3.2 Usuarios Funcionales Un usuario se define, en la norma ISO/IEC 14143/1:2007, como cualquier cosa que interacta con el software que se est midiendo. Esta definicin es demasiado amplia para las necesidades del mtodo COSMIC. Para el mtodo COSMIC, la eleccin de un usuario (o usuarios) se determina por los requisitos del usuario funcional que deben medirse. Este (tipo de) usuario, es conocido como el usuario funcional y se define como sigue. Definicin Usuario Funcional Es un usuario aquel remitente y/o destinatario de datos de los Requisitos Funcionales de Usuario de una aplicacin software. En el mtodo COSMIC es esencial distinguir a los usuarios funcionales de una parte del software que debe ser medido de entre todos sus posibles usuarios. Reglas Usuarios Funcionales a) Los usuarios funcionales de una aplicacin software que se hayan de medir se derivan del propsito de la medicin b) Cuando el propsito de una medicin de una aplicacin software est relacionado con el esfuerzo para desarrollar o modificar el software, entonces los usuarios funcionales deben ser aquellos para los cuales se est modificando o proporcionando este nuevo software. Definicin Nivel de Granularidad de un Proceso funcional Un nivel de granularidad de la descripcin de aplicacin software en el que los usuarios funcionales: a) Son humanos individuales o dispositivos de ingeniera o elementos de software (y no grupos de estos) b) detectan ocurrencias nicas de eventos a los que la aplicacin software debe responder (y no cualquier nivel en el cual se han definido grupos de eventos) Nota 1: En la prctica, la documentacin de software que contiene las necesidades de los usuarios funcionales a menudo describe la funcionalidad en diferentes niveles de granularidad, sobre todo cuando la documentacin an est en construccin. Nota 2: Grupos de usuarios funcionales podran ser, por ejemplo, un departamento cuyos miembros manejan muchos tipos de procesos funcionales, o un panel de control que tiene muchos tipos de instrumentos. Nota 3: Un grupo de casos puede, por ejemplo, indicarse en una declaracin de FUR en un alto nivel de granularidad de un flujo de entrada a un sistema de software de contabilidad, etiquetados como transacciones de venta, o de un flujo de entrada a un sistema de software de avinica. FASE DE REPRESENTACIN
3.2 Identificacin de los procesos funcionales Este paso consiste en identificar el conjunto de procesos funcionales de la aplicacin software que se va a medir a partir de sus Requisitos Funcionales de Usuario. 3.2.1 Definiciones Definicin Proceso funcional Un proceso funcional es un componente elemental de un conjunto de requisitos funcionales de usuario que constituyen una serie de movimientos de datos nica, cohesiva e independientemente ejecutable. Es desencadenada por un movimiento de datos (una Entrada) desde un usuario funcional que informa al componente de software que el usuario funcional ha identificado un evento disparador. Se completa cuando ha ejecutado todo lo que se requiere hacer en respuesta al evento desencadenante.
Nota: Adems de informar al componente de software de que el evento ha ocurrido, la entrada desencadenante puede incluir datos sobre el objeto de inters asociado al evento.
Definicin Evento desencadenante Un evento (algo que ocurre) que causa un usuario funcional del componente de software para iniciar (trigger) uno o ms procesos funcionales. En un conjunto de requisitos funcionales de usuario, cada evento que causa que un usuario funcional desencadene un proceso funcional: no puede ser sub-dividido para ese conjunto de FUR, y ha ocurrido o no ha ocurrido Nota: El reloj y los eventos de tiempo pueden ser eventos desencadenantes.
3.2.2 La aproximacin para identificar procesos funcionales La aproximacin para identificar procesos funcionales depende de los artefactos de software que estn disponibles para el medidor, los cuales dependen del momento del ciclo de vida del software cuando se requiere la medida y de los mtodos de anlisis, diseo y desarrollo del software en uso. Puesto que stos ltimos varan enormemente, incluso dentro del un dominio de software dado, est fuera del alcance de este Manual de Medida el proporcionar uno o ms procesos generales para identificar procesos funcionales.
3.2.4 Ejemplos en el dominio de aplicaciones en tiempo real. a) Un evento desencadenante es detectado tpicamente por un sensor Ejemplo 1: Cuando la temperatura alcanza un valor determinado (evento desencadenante), se produce que un sensor (usuario funcional) enve una seal (movimiento de datos de Entrada desencadenante) para encender una luz de alarma (proceso funcional). Ejemplo 2: Un avin 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 envindole un mensaje (Entrada desencadenante) diciendo por ejemplo: el sensor 2 ha detectado un misil, adems quizs tambin enva un flujo de datos sobre la velocidad del misil que se acerca y sus coordenadas. El misil es el objeto de inters. Manual de Medicin. b) Seales peridicas de una reloj (ticks de reloj) pueden desencadenar un proceso funcional Ejemplo 3: En algn software de control de procesos en tiempo real, un tick (evento desencadenante) de un reloj (usuario funcional) produce que el reloj enve una seal (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 inters, y lleva a cabo cualquier accin necesaria. No hay otros datos que acompaen el tick del reloj.
FASE DE MEDICION Definicin de los tipos de movimientos de datos Definicin Movimiento de datos Un componente con base funcional que mueve un nico tipo de grupo de datos. Nota 1: Hay cuatro tipos de movimiento de datos: Entrada, Salida, Lectura y Escritura Nota 2: Para la medicin, cada tipo de movimiento de datos se considera que incluye ciertas manipulaciones de datos asociadas - Ver seccin 4.1.6 para ms detalles. Nota 3: Ms precisamente, es una ocurrencia de un movimiento datos, no un tipo de movimiento de datos, que realmente mueve las ocurrencias del grupo de datos (no los tipos). Este comentario se aplica tambin a las definiciones de Entrada, salida, lectura y escritura.
Definicin Entrada, (Entry, E) Una entrada (E) es un movimiento de datos que mueve un grupo de datos desde un usuario funcional a travs de la frontera hacia el proceso funcional donde se necesitan Nota: Se considera que una entrada incluye ciertas manipulaciones de datos asociadas
Definicin Salida, (Exit, X) Una salida (X) es un movimiento de datos que mueve un grupo de datos desde un proceso funcional a travs de la frontera haca el usuario funcional que los requiere. Nota: Se considera que una salida incluye ciertas manipulaciones de datos asociadas
Definicin Lectura (Read, R) Un movimiento de un grupo de datos desde un almacn permanente dentro del alcance del proceso funcional que los requiere. Nota: Se considera que una lectura incluye ciertas manipulaciones de datos asociadas
Definicin Escritura (Write, W) Un movimiento a un almacn permanente de un grupo de datos que se encuentra dentro de un proceso funcional. Nota: Se considera que una escritura incluye ciertas manipulaciones de datos asociadas
Identificacin de entradas (E) Una vez identificado, un candidato a movimiento de datos de Entrada debe cumplir con los siguientes principios: Principios Entradas (E) a) Una entrada deber mover un nico grupo de datos describiendo un solo objeto de inters de un usuario funcional a travs de la frontera y dentro de un proceso funcional del que la entrada forma parte. Si la entrada a un proceso funcional comprende ms de un grupo de datos, se identifica una entrada por cada grupo de datos que entra. (Vase tambin la seccin 4.1.7 sobre El nico movimiento de datos) b) Una entrada no deber salir de la frontera, ni leer ni escribir datos c) Donde un proceso funcional necesite obtener datos de un usuario funcional pero ms tarde no necesite que se le diga que datos enviar o el usuario funcional es incapaz de reaccionar a ningn mensaje entrante, identificar una Entrada al proceso funcional para obtener los datos. Cualquier mensaje del proceso funcional al usuario funcional buscando recuperar los datos no debe ser contado como una Salida en estos casos. Sin embargo, cuando un proceso funcional deba obtener algn dato de un usuario funcional y el proceso funcional deba decirle al usuario funcional con datos que despus requieran rellenar la peticin, contar una Salida para la peticin y una Entrada para la devolucin de los datos pedidos (para ms informacin ver seccin
4.1.3. Identificacin de salidas (X) Una vez identificados, un candidato a movimiento de datos de Salida debe cumplir con los siguientes principios: Principios Salidas (X) a) Una salida deber mover un nico grupo de datos describiendo un solo objeto de inters desde el proceso funcional del que la salida forma parte a cruzando la frontera hacia un usuario funcional. Si la salida de un proceso funcional comprende ms de un grupo de datos, hay que identificar una salida para cada grupo de datos que sale. (Vase tambin la seccin 4.1.7 sobre los movimientos de datos nicos.) b) Una salida no introducir datos a travs de la frontera, ni lecturas, ni escrituras.
Identificacin de Lecturas (R) Una vez identificado, un candidato a movimiento de datos de Lectura debe cumplir con los siguientes principios: Principios Lecturas (R) a) Una lectura deber mover un nico grupo de datos describiendo un solo objeto de inters del almacn permanente a un proceso funcional del cual la lectura forma parte. Si el proceso funcional debe recuperar ms de un grupo de datos del almacn, identificar una Lectura para cada grupo de datos que es recuperado. (Vase tambin la seccin 4.1.7 sobre los movimientos de datos nicos.) b) Una lectura no recibir ni sacar datos a travs de la frontera ni escribir datos c) Durante un proceso funcional, el movimiento o manipulacin de constantes o variables que son internas del proceso funcional y que slo se pueden cambiar por un programador, o mediante los resultados intermedios en un clculo, o de los datos almacenados en un proceso funcional slo resultantes de la aplicacin, ms que de los requisitos funcionales, no se considerar como una Lectura. d) Una Lectura siempre incluye cualquier funcionalidad de solicitud de lectura (as, un movimiento de datos separado nunca ser contado para cualquier funcionalidad de solicitud de lectura).
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 Manual de Medicin , inters del proceso funcional del que la Escritura forma parte hacia un almacn permanente. Si el proceso funcional debe pasar ms de un grupo de datos al almacn permanente, identificar una Escritura por cada grupo de datos que se mueve a un almacn permanente. b) Una escritura no recibir ni sacar datos de la frontera, ni leer los datos c) Un requisito para borrar un grupo de datos de un almacn permanente se medir como una sola Escritura d) Durante un proceso funcional, el movimiento o manipulacin de los datos que no persista cuando el proceso funcional sea completado, o la actualizacin de variables que son internas del proceso funcional o la produccin de resultados intermedios en un clculo no se considerarn como una Escritura.
Movimiento de Datos de Entrada (E) Una entrada incluye toda manipulacin de datos Para permitir a un grupo de datos debe ser introducida por un usuario funcional (por ejemplo manipulaciones de formato y presentacin) y/o para ser validado Pero no todas las manipulaciones que involucran otro movimiento de datos, ni manipulaciones despus de que el grupo de datos se ha introducido y validado. Ejemplo: Una entrada incluye toda manipulacin, formato y presentacin en una pantalla de los datos introducidos salvo alguna Lectura(s) que podra ser necesaria para validar algunos cdigos introducidos o para obtener algunas descripciones 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 . Movimiento de Datos de Salida (X) Una Salida incluye todas las manipulaciones de datos para crear los atributos de un grupo de datos de salida y/o para permitir que el grupo de datos sea salida (por ejemplo las manipulaciones de formato y presentacin) y sea encaminado a los usuarios funcionales. pero no cualquier manipulacin que involucre otro movimiento de datos. Ejemplo: Una Salida incluye todo el tratamiento para formatear y preparar la impresin de algunos atributos, incluidos los encabezados para aumentar la legibilidad por los humanos, salvo cualquier Lectura o Entrada que podra ser necesaria para proporcionar los valores o descripciones de algunos atributos de impresin. Movimiento de datos de Lectura (R) Una Lectura incluye todo tratamiento y/o clculo necesario a fin de recuperar un grupo de datos del almacn permanente pero no a manipulaciones con otro tipo de movimiento de datos ni manipulaciones despus de que la lectura se complete con xito. Ejemplo: Una lectura incluye todas las operaciones matemticas y transformaciones lgicas necesarias para recuperar un grupo de datos de un almacn permanente pero no la manipulacin de los atributos despus de que el grupo de datos se haya obtenido. Una Lectura tambin incluye siempre cualquier funcionalidad de solicitud de lectura
Movimiento de datos de Escritura (W) Una Escritura incluye todos los tratamientos y/o clculos para crear un grupo de datos que ser escrito pero no cualquier manipulacin que incluya otro tipo de movimiento de datos, ni tampoco manipulaciones de que la Escritura termine con xito despus de que la Escritura termine con xito. Ejemplo: Una Escritura incluye todas las operaciones matemticas y transformaciones lgicas necesarias para crear o actualizar un grupo de datos de Escritura, o para ser borrados excepto las lecturas o entradas que podran 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 Genrico de Software supone que normalmente en cualquier proceso funcional todos los datos describen un objeto de inters que se traduce en un solo movimiento de datos de tipo Entrada y/o en uno de tipo Lectura y/o en uno de tipo Escritura y/o en la produccin de un movimiento de datos de tipo Salida. El modelo supone tambin que toda manipulacin de los datos resultantes de todos los valores de los atributos los datos de un grupo que se mueve est asociado con un movimiento de datos.