Reporte de

Especificación de
Software (RES)
Versión 1.0

“GESTIÓN DE RECEPCIÓN DE MATERIALES EN EL

ALMACÉN EMAPE EN LA CIUDAD DE LIMA, 2022"

____________________________________________________________________________________
Reporte de Especificación de Software (RES) Página 1 de 17
 HISTORIAL DE REVISIONES

Fecha de Fecha de
Versión Autor Descripción Revisado por
Elaboración Revisión
Oropeza -ANTECEDENTE 12/09/2022
1.0 Llerena
Diego Luis -SUPUESTOS 19/09/2022
Orozco -ANTECEDENTES 12/09/2022
Cordova OBJETIVOS
Diana 19/09/2022
-
RESTRICCIONES
Manza -DENTRO DE 13/09/2022
Ocaña ALCANCE
Jhair Enzo
- 20/09/2022
RESTRICCIONES
Valencia -FUERA DE 13/09/2022
Diaz José ALCANCE

-SUPUESTOS 20/09/2022

____________________________________________________________________________________
Reporte de Especificación de Software (RES) Página 2 de 17
 Contenido
ANTECEDENTES 4

OBJETIVOS 4

ALCANCE 4
DENTRO DEL ALCANCE 4
FUERA DEL ALCANCE 4
RESTRICCIONES 4
SUPUESTOS 4

PROCESOS DE NEGOCIO 4
LISTA DE CASOS DE USO DE NEGOCIO 4
LISTA DE ACTORES DEL NEGOCIO 5
DIAGRAMA GENERAL DE CASO DEL NEGOCIO 5
ESPECIFICACIÓN DE LOS CASOS DE USO DEL NEGOCIO 5
CUN01 – NOMBRE DEL CASO DE USO DEL NEGOCIO 5
REALIZACIÓN DE LOS CASOS DE USO DE NEGOCIO 5
LISTA DE TRABAJADORES DE NEGOCIO 5
REGLAS DE NEGOCIO 6

REQUISITOS FUNCIONALES 6

REQUISITOS NO FUNCIONALES 7

MODELO DE CASOS DE USO DEL SISTEMA 9

LISTA DE ACTORES DE SISTEMA 9
DIAGRAMA DE ACTORES DEL SISTEMA 10
ARQUITECTURA DEL SISTEMA – DIAGRAMA DE PAQUETES 10
LISTA DE CASOS DE USO DEL SISTEMA POR PAQUETE 10
DIAGRAMA DE CASOS DE USO POR PAQUETE 10
PRIORIZACIÓN DE LOS CASOS DE USO DEL SISTEMA 10
MATRIZ DE MODELO DE NEGOCIO Y MODELO DE SISTEMA 11
ESPECIFICACIÓN DE LOS CASOS DE USO DEL SISTEMA 12
CUS01 – NOMBRE DEL CASO DE USO 12

FLUJO GENERAL DE NAVEGACIÓN 13

ESQUEMA DE SEGURIDAD 14

MODELO DE ANÁLISIS 14

MODELO CONCEPTUAL 14

____________________________________________________________________________________
Reporte de Especificación de Software (RES) Página 3 de 17
1. Antecedentes
La empresa de EMAPE (empresa municipal administradora del peaje de Lima) se
encuentra ubicado en Km 1.7 Vía de Evitamiento – Lima 15023, Distrito de la Molina,
ofreciendo servicios de mantenimiento de las vías en toda lima, incluye todo lo que es
señalización de las vías como pueden ser las señales de tránsito, pintado de las señales
horizontales del asfalto, pintado de sardinel, pintado de las señales horizontales en la
ciclovía, arreglo de las veredas y mantenimiento al asfalto(pistas). El proceso de la
recepción de los materiales en el almacén de EMAPE es de la siguiente manera:

PROCESO: GESTIÓN DE REQUERIMIENTO DE MATERIALES.

El proceso inicia cuando se requiere materiales para un trabajo en específico, se envía un
topógrafo en verificar el área donde se realizará el mantenimiento de la vía y evalúa
que trabajo en concreto se va a realizar, dependiendo a esto hace un reporte de los
materiales que se van a utilizar. Este informe es enviado al ingeniero seleccionado que se
va a encargar de este mantenimiento y este mismo envía el informe al área de logística.

Por otro lado, el encargado de logística se encarga de hacer la solicitud de dinero

correspondiente para la compra de los materiales.

PROCESO: EVALUACIÓN DE LOS MATERIALES.

Se designa a un Técnico de materiales para buscar una empresa y comprar los materiales
necesarios para el área donde se realizará el mantenimiento de vía, el Técnico elige la
empresa y realiza las evaluaciones correspondientes a los materiales en venta para ver si
son óptimos o no; en caso no pase las evaluaciones de calidad a los materiales, se dirige
a otra empresa y realiza las mismas evaluaciones. Una vez elegidos los materiales a
comprar se emite una orden de compra al encargado de logística y se hace la
transacción, y todos los materiales son llevados al almacén.

PROCESO: GESTIÓN DE RECEPCIÓN DE MATERIALES.

Los materiales llegan al almacén junto con el personal de la empresa y un representante
de la misma que provee los materiales al almacén, el representante entrega un
comprobante de compra al encargado del almacén, este se comunica con el encargado
de logística para confirmar la compra y los materiales adquiridos, una vez que todo esté
en orden se procede a descargar los materiales dentro del almacén.

____________________________________________________________________________________
Reporte de Especificación de Software (RES) Página 4 de 17
2. Objetivos

3. Alcance

3.1. Dentro del Alcance

- Controlar la recepción de los materiales.

- Controlar la calidad del requerimiento realizado.
- Controlar el flujo de trabajo de los informes de requerimientos.
- Controlar la evaluación de los materiales.

3.2. Fuera del Alcance

- Verificar el precio de los productos

- Controlar la contratación de nuevos empleados
- Gestionar los puestos de trabajo.
- Gestionar el pago de empleados

3.3. Restricciones

- Los materiales solo serán recibidos si el comprobante está acorde con la compra
realizada.
- El material que se necesita para el mantenimiento no puede ser comprado mientras
no pase por las evaluaciones correspondientes.
- El encargado de logística no puede enviar dinero para comprar los materiales si es
que no aceptan su solicitud.
- La compra de materiales no puede exceder del presupuesto que sea establecido por
la persona a cargo.
- El material solo podrá ser usado previa aprobación del encargado de logística.
- La empresa proveedora deberá entregar todos los materiales comprados en la fecha
que se pacte para su entrega y su correcto almacenado.

____________________________________________________________________________________
Reporte de Especificación de Software (RES) Página 5 de 17
 3.4. Supuestos
- El personal del área de logística y almacén deben estar capacitados en el uso de
herramientas de tecnología.
- El almacén cuenta con equipos de cómputo necesarios para el registro de materiales.
- El técnico de materiales debe estar muy bien capacitado para realizar las
evaluaciones de material lo mejor posible.
- El topógrafo debe tener en conocimiento que ingenieros están a disposición para el
mantenimiento.
- El ingeniero debe estar bien capacitado para recibir informes y realizar el
mantenimiento.

4. Procesos de Negocio

4.1. Lista de Casos de Uso de Negocio

Caso de uso del Descripción

negocio
DIEGO

diego

diana

diana

4.1.1. Lista de Actores del Negocio

Actor del Negocio Descripción

____________________________________________________________________________________
Reporte de Especificación de Software (RES) Página 6 de 17
 JOSE

INGENIERO DE TRANSPORTE(JOSE)

JHAIR
Recibe la información de los materiales que se
necesitan y solicita el dinero correspondiente.
Recibe la orden de compra y autoriza esta.
Solicitará la información del almacenero para la
corroborar el correcto almacenado de los materiales
comprados y recibir el recibo de compra.

JHAIR
Este se encarga de seleccionar la empresa donde se
comprarán los materiales y de hacer las respectivas
evaluaciones de calidad a estos, en caso de que la
calidad no sea buena, cambiara de empresa y hará
el proceso de calidad de nuevo. Una vez elegida la
empresa, se emitirá una orden de compra que será
dirigida al Encargado de Logística para su posterior
aprobación.

DIEGO

4.1.2. Diagrama General de Caso del Negocio

____________________________________________________________________________________
Reporte de Especificación de Software (RES) Página 7 de 17
 4.1.3. Especificación de los Casos de Uso del Negocio
[Por cada caso de uso de negocio deberá indicar el flujo de trabajo del Caso de Uso
del Negocio. Deberá usar la plantilla que a continuación se detalla:

1. CUN01 – Nombre del Caso de Uso del Negocio

1. Breve Descripción
Reutilizar el resumen del punto 4.1
2. Objetivo
Referido al negocio y alineado al producto software.
3. Flujo de Trabajo
3.1 Flujo Básico
2. Indicar el flujo básico del CUN
3.2 Flujos Alternativos
1. Detalle del flujo alterno.
4. Categoría
Se coloca si es básica, estratégica o de apoyo.
5. Gestor del proceso
Se identifica a la persona que está interesada en el éxito o fracaso del proceso.

4.2. Realización de los Casos de Uso de Negocio

[En esta sección deberá desarrollar los diagramas de actividades y diagrama de
clases de negocio por cada Caso de Uso de Negocio identificado en la sección
4.1. Por cada juego de diagramas deberá identificar cuáles serán las actividades
que serán automatizadas.]

4.3. Lista de Trabajadores de Negocio

[En esta sección deberá listar a los trabajadores de negocio incluyendo una
descripción por cada uno.]
____________________________________________________________________________________
Reporte de Especificación de Software (RES) Página 8 de 17
 Trabajador del
Descripción
Negocio

4.4. Reglas de Negocio

[En esta sección deberá identificar las reglas que regulan la estructura del
negocio y cómo ellos operan afectando el funcionamiento de los procesos de
negocio. Dichas reglas de negocio son las que se considerarán para el diseño del
sistema. Cada Regla de Negocio deberá ser identificada con un código único y
correlativo. Ejemplo: RN01. Para identificar las reglas de negocio puede
considerar la siguiente clasificación:

Reglas de Estructura: Ejemplo (Todo pedido debe ser realizado por un cliente, y
que el mismo debe estar dado de alta. Además una vez que el cliente haya
hecho algún pedido, se deberá garantizar que no es posible eliminarlo, al menos
que previamente se eliminen todos sus pedidos)

Reglas de Derivación: Ejemplo (El total de un pedido se puede calcular a partir

de distintas líneas que lo componen, mientras que el total de cada línea se puede
calcular a partir del número de unidades vendidas y el precio por unidad)

Reglas de Interfaz o de Modelo de Datos: Ejemplo (No hay precio de artículos

negativos, el sexo de una persona sólo puede ser masculino o femenino, una
fecha tiene que ser siempre una fecha válida - no existe 30 de febrero)

Reglas de Operación o Reglas de Flujo: Ejemplo (Un cliente puede hacer una
petición de análisis al laboratorio que anota un encargado: hecho esto, se genera
un parte para uno o más analistas, estos realizan las mediciones
correspondientes y devuelven los partes con la información pertinente, a partir
de la cual se genera un informe de análisis, que será un análisis válido solo
cuando sea firmado por los responsables de garantizar su corrección)

Código Descripción
RN-001
[Descripción de la Regla 001]
RN-002
[Descripción de la Regla 002]

RN-00n

5. Requisitos Funcionales
[De acuerdo a lo solicitado explícitamente por el área usuaria, listar todos los requisitos
funcionales del producto software. Considere que los requisitos funcionales que liste
deberán ser asociados posteriormente a los casos de uso (funciones de software). Cada
Requisito Funcional deberá ser identificado con un código único y correlativo. Ejemplo:
RF01.
Nota: Esta lista proviene de la Matriz de Actividades Vs. Requisitos. Y de la Matriz de
Requisitos Funcionales Adicionales.]

Código Descripción Proceso de Negocio

[Código del [Descripción detallada del requisito [Identificador del proceso
____________________________________________________________________________________
Reporte de Especificación de Software (RES) Página 9 de 17
 Código Descripción Proceso de Negocio
requisito de negocio asociado]
funcional.]
funcional]
[Descripción detallada del requisito [CUN01]
RF-001
funcional 1.]
[Descripción detallada del requisito
RF-002
funcional 2.]

... ....
[Descripción detallada del requisito
RF-00n
funcional n.]

6. Requisitos No Funcionales
[Listar los requisitos no funcionales los mismos que deberán ser considerados para el
modelo de calidad de producto. Cada Requisito No Funcional deberá ser identificado con
un código único y correlativo. Ejemplo: RNF01.]

Tipo de Requisito Implementació

Código Descripción
n
[Código del [Descripción detallada [Describir como se
[Nombre del tipo de
requisito no del requisito no implementará el
requisito no funcional]
funcional] funcional.] RNF-00n]
Restricciones del Diseño
[Definir cualquier tipo de
restricción de diseño, tales
como: proceso de desarrollo
de software, sistemas [Descripción detallada
operativos, lenguajes de RNF-001 del requisito no
programación, funcional 1.]
administrador de base de
datos, conexión a la BD,
generador de reportes,
manejo de información,
etc.]
[Descripción detallada
RNF-002 del requisito no
funcional 2.]
Componentes a Adquirir
[Identificar los componentes
que se deben adquirir o
tener en cuenta, para llevar [Descripción detallada
acabo el desarrollo y RNF-003 del requisito no
ejecución del sistema. funcional 3.]
Ejemplo: lenguajes de
programación, servidores,
estaciones de trabajo, etc.]
[Descripción detallada
RNF-004 del requisito no
funcional 4.]

____________________________________________________________________________________
Reporte de Especificación de Software (RES) Página 10 de 17
 Tipo de Requisito Implementació
Código Descripción
n
Interfaces de Usuario
[Describir las interfaces de
usuario que serán
implementados en el [Descripción detallada
software. Esto incluye por RNF-005 del requisito no
ejemplo: formatos de la funcional 5.]
pantalla, página o
esquemas de las ventanas,
reportes, menús, etc.]
[Descripción detallada
RNF-006 del requisito no
funcional 6.]
Interfaces de Hardware
[Definir cualquier interfase
de hardware que será [Descripción detallada
soportado por el software, RNF-007 del requisito no
incluyendo estructura funcional 7.]
lógica, direcciones físicas,
etc.]
[Descripción detallada
RNF-008 del requisito no
funcional 8.]
Interfaces de Software
[Especificar el uso de otros [Descripción detallada
productos software RNF-009 del requisito no
requeridos e interfaces con funcional 9.]
otros sistemas de la
aplicación.]
[Descripción detallada
RNF-010 del requisito no
funcional 10.]
Interfaces de
Comunicaciones
[Describir las interfaces de [Descripción detallada
comunicación para otros RNF-011 del requisito no
sistemas ó dispositivos, funcional 11.]
tales como: redes de área
local, dispositivos de serie
remota.]
[Descripción detallada
RNF-012 del requisito no
funcional 12.]
Requerimientos de
Licenciamiento [Descripción detallada
[Identificar las licencias que RNF-013 del requisito no
se requieran para el funcional 13.]
desarrollo del sistema.]

____________________________________________________________________________________
Reporte de Especificación de Software (RES) Página 11 de 17
 Tipo de Requisito Implementació
Código Descripción
n
[Descripción detallada
RNF-014 del requisito no
funcional 14.]
Seguridad
[Descripción detallada
[Describir como será RNF-015 del requisito no
controlada la seguridad del funcional 15.]
sistema.]
[Descripción detallada
RNF-016 del requisito no
funcional 16.]
Estándares aplicables
[Descripción detallada
[Especificar con qué RNF-017 del requisito no
estándares trabaja el funcional 17.]
sistema.]
[Descripción detallada
RNF-018 del requisito no
funcional 18.]
Requisitos del Sistema
[Especificar los [Descripción detallada
requerimientos de RNF-019 del requisito no
plataforma tecnológica funcional 19.]
necesarios para el diseño y
el desarrollo del sistema.]
[Descripción detallada
RNF-020 del requisito no
funcional 20.]
Requisitos de
Desempeño
[Listar y especificar los [Descripción detallada
requisitos de desempeño RNF-021 del requisito no
con los que debe trabajar el funcional 21.]
sistema. Ejemplo: Tiempo
de respuesta en alguna
consulta del sistema.]
[Descripción detallada
RNF-022 del requisito no
funcional 22.]

7. Modelo de Casos de Uso del Sistema

[En esta sección deberá desarrollar el modelo de sistema o modelo de requisitos. Para
ello deberá indicar los actores de sistemas, la arquitectura de sistema (organizada en
paquetes) y la relación de casos de uso por cada paquete. Cada Caso de Uso deberá ser
identificado con un código único y correlativo. Ejemplo: CUS01.]

____________________________________________________________________________________
Reporte de Especificación de Software (RES) Página 12 de 17
 7.1. Lista de Actores de Sistema
[Listar a los actores de sistema.]

Actor del sistema Descripción

7.2. Diagrama de Actores del Sistema

[Incorpore el diagrama de actores del sistema.]

7.3. Arquitectura del Sistema – Diagrama de Paquetes

[Incorpore el diagrama de paquetes que representa la arquitectura modular del
sistema. Cada Paquete deberá ser identificado con un código único y correlativo.
Ejemplo: P01.]

7.4. Lista de Casos de Uso del Sistema por Paquete

[En esta sección deberá listar todos los casos de uso del sistema que se han
identificado. Para hacerlo deberá tomar como referencia la organización del
sistema de acuerdo al diagrama de paquetes del punto 7.3.]
Paquete: P01 – Nombre del Paquete
Caso de uso del sistema Descripción

CUS01 – [Nombre del Caso [Descripción del caso de uso. En la descripción

de Uso] deberá indicar las acciones que permitirá el
caso de uso.]
CUS02 – [Nombre del Caso [Descripción del caso de uso. En la descripción
de Uso] deberá indicar las acciones que permitirá el
caso de uso.]

7.5. Diagrama de Casos de Uso por Paquete

[Incorpore el diagrama de casos del uso del sistema de acuerdo a los paquetes y
la lista trabajada en el punto 7.4.]

Paquete: P01 – Nombre del Paquete

7.6. Priorización de los Casos de Uso del Sistema

7.6.1. Clasificación de los Casos de Uso del Sistema

[En esta sección deberá clasificar los casos de uso de sistema indicando
si son primarios o secundarios.]

0,4 0,3 0,2 0,1

IMPORTANCI COMPLEJIDA RIESG IMPACTO CLASIFICACIÓ
CASO DE USO A D O RNF TOTAL N DE CU
CUS01-
XXXXXX           Primario
CUS02-
XXXXXX           Secundario
CUS03-
XXXXXX           Secundario

____________________________________________________________________________________
Reporte de Especificación de Software (RES) Página 13 de 17
 7.6.2. Ciclos de Desarrollo de los Casos de Uso del Sistema
[En esta sección deberá indicar en qué ciclo de desarrollo se trabajarán
cada uno de los casos de uso del sistema.]

Ciclo de desarrollo Nombre del caso de uso Clasificación

Núcleo central o Ciclo 0 CUS01 – Nombre del caso de uso Primario
Ciclo 1 CUS02 – Nombre del caso de uso Secundario
CUS03 – Nombre del caso de uso Secundario

7.7. Matriz de Modelo de Negocio y Modelo de Sistema

[En esta sección deberá incluir una matriz en la que se pueda evidenciar la
trazabilidad entre los procesos de negocio y las funciones del producto software.]

Caso del uso Actividad a automatizar Requerimiento Caso de uso del

del negocio funcional sistema
Nº Nombr N Nombre Responsabl Nº Nombre Nº Nombr Acto
e º e e r
CUN0 Caso de 1 Actividad a Trabajador RF- Requisito CUS0 Casos Actor
1 Uso de ser de Negocio 001 Funcional 1 de Uso
Negocio automatizad de
a Sistema
2 Actividad a Trabajador
ser de Negocio
automatizad
a
3 Actividad a Trabajador
ser de Negocio
automatizad
a

3.

____________________________________________________________________________________
Reporte de Especificación de Software (RES) Página 14 de 17
 7.8. Especificación de los Casos de Uso del Sistema

7.8.1. Especificación de Alto Nivel

[En esta sección deberá incluir la especificación de alto nivel de los
casos de uso del sistema. Asimismo deberá indicar que requisitos
funcionales están asociados a cada caso de uso, tomando como
referencia lo indicado en la matriz del punto 7.7.]

Caso de uso: CUS01 – Nombre del Caso de Uso

Actor(es): Nombre del actor
Propósito: Indicar el propósito del caso de uso
Caso de uso Indicar si existe algún caso de uso asociado. De no haber
asociado: indicar No Aplica.
Resumen: Describir brevemente el caso de uso. Para ello deberá
indicar como empieza el caso de uso, que actividades
desarrolla y como termina.
Clasificación Indicar la clasificación del caso de uso
Requisitos Indicar el(los) códigos de requisitos funcionales asociados.

7.8.2. Especificación Expandida

[Por cada caso de uso de sistema especificado deberá incluir la
especificación expandida de casos de uso. Para ello deberá indicar el
flujo básico y los flujos alternos e incorporará el prototipo con la
inclusión de los controles. Deberá usar la plantilla que a continuación se
detalla:

CUS01 – Nombre del caso de Uso

1. Actores
Indicar la lista de actores
2. Propósito
Indicar el propósito
3. Breve Descripción
Reutilizar el resumen del punto 7.4
4. Flujo Básico de Eventos
Indicar el flujo básico de eventos
Es posible hacer referencia a las reglas de negocio.
5. Sub Flujos
Indicar los subflujos del flujo básico.
6. Flujos Alternos
6.1. Nombre del flujo alterno
1. Detalle del Flujo alterno
Se pueden incluir reglas de negocio.
7. Precondiciones

____________________________________________________________________________________
Reporte de Especificación de Software (RES) Página 15 de 17
 Descripción de la precondición

8. Pos condiciones
Descripción de la pos condición

9. Puntos de Extensión
Indicar si existen puntos de extensión.
10. Requerimientos Especiales
Indicar si existen requerimientos especiales.
11. Prototipos
Incluir los prototipos asociados al caso de uso.

8. Flujo General de Navegación

[Incluir un árbol de navegación que permita entender el flujo que se seguirá en la
navegación por el aplicativo. El siguiente ejemplo muestra un árbol de navegación:
Aplicación/módulo/opción/subopción]

Ver
Agend
a
Encargar
Acción

A Ver
ge Accione
nd s
a
Ver
Alarma
s
Acción
Propia

APLICAC Cli
en
Con
sult
ION te ar
Pará
metro
s
s
T Resul
a tados
b
l
a Ra
Manteni zo
s
miento ne
s
Matriz
CAP
Relac
iones
Matriz
GAF

Acciones
Enviadas

Av
an
ce
Re Resultados
s
port Históricos
es
Resulta
doAcc
de
ion
es
Seguimiento
Semanal

____________________________________________________________________________________
Reporte de Especificación de Software (RES) Página 16 de 17
9. Esquema de Seguridad
[En esta se documenta los esquemas de seguridad en base a perfiles y su acceso a su
información. Para ello se utiliza una matriz de perfiles de usuario y accesos por
Aplicativo/Módulo/Función.]

Aplicativo
Funciones por Módulo Perfil 1 Perfil 2 ... Perfil N
Módulo A x x X x
Consulta de información de
empresas
Consulta de operadores x x X x
autorizados
Modificación de operadores x x X x
autorizados

Módulo B
Modificación de cuentas afiliadas x x X x
Modificación de combinaciones x x X x
autorizadas

10. Modelo de Análisis

10.1.Realización de Casos de Uso – Análisis
[Esta sección ilustra cómo el software trabaja a partir de los casos de uso o
escenarios seleccionados, y explica cómo varios elementos del modelo de
análisis contribuyen con ellos funcionalmente. Por cada caso de uso deberá
desarrollar un diagrama de secuencia y de clases de análisis. Para ello deberá
usar el patrón MVC. Para la realización deberá identificar los escenarios. Dichos
escenarios se obtienen de las combinaciones entre el flujo principal y flujos
alternativos del la especificación expandida de casos de uso (ver punto 7.8.2).]

Código del CUS – Nombre del CUS

Nombre del Escenario
[Identifica el escenario a ser realizado y una breve descripción. Se recomienda
identificar con un código único a cada escenario. Por ejemplo ESC01]

Diagrama de Secuencia de Análisis

[Incluya el diagrama de secuencia de análisis en el cual se observe el uso del
patrón MVC que implementa el escenario identificado.]

Diagrama de Clases de Análisis

[Incluya el diagrama de clases de análisis obtenido del conjunto de diagramas
de secuencia que se implementan por cada escenario.]

11. Modelo Conceptual

[Esta sección ilustra cómo a partir de las clases del tipo entidad se pueden identificar una
primera propuesta de modelo de persistencia. Para ello se utiliza un diagrama clases por
cada paquete que forma parte de la arquitectura del sistema. Se puede hacer uso de
tarjetas CRC para documentar las responsabilidades y colaboraciones de cada clase de
persistencia identificada.]

____________________________________________________________________________________
Reporte de Especificación de Software (RES) Página 17 de 17