Você está na página 1de 14

El Mtodo COSMIC

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.

Você também pode gostar