ESCUELA POLITECNICA

DEL EJERCITO

TECNICAS
DE DESARROLLO DE
SOFTWARE

INGENIERIA EN SISTEMAS E INFORMATICA

DE REQUISITOS SOFTWARE
ESPECIFICACION
IEEE 830
SEGUN
INTEGRANTES:

ESPIN VELASCO LUIS IVAN

BARBA BARBA CRISTIAN JOSE

SALGADO ESCOBAR STALIN SEBASTIAN

SARCHI ALBUJA ELVIS RAMIRO
Lunes,15 de Junio de 2014

Indice

1. INTRODUCCION
1.1. Prop
osito . . . . . . . . . . . . . . . .
1.2. Alcance . . . . . . . . . . . . . . . . .
1.2.1. Objetivo General . . . . . . . .
1.2.2. Objetivos Especficos . . . . . .
1.3. Personal involucrado . . . . . . . . . .
1.4. Definiciones, acr
onimos y abreviaturas
1.5. Referencias . . . . . . . . . . . . . . .
1.6. Resumen . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

4
4
5
5
5
6
7
7
8

GENERAL
2. DESCRIPCION
2.1. Perspectiva del producto . . . . . .
2.2. Funcionalidad del producto . . . .
2.2.1. Diagramas de Casos de Uso
2.3. Caractersticas de los usuarios . . .
2.4. Restricciones . . . . . . . . . . . .
2.5. Suposiciones y dependencias . . . .
2.6. Evoluci
on previsible del sistema . .

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

8
8
9
9
12
12
12
13

3. REQUISITOS ESPEC
IFICOS
3.1. Requisitos comunes de las interfaces
3.1.1. Interfaces de usuario . . . . .
3.1.2. Interfaces de hardware . . . .
3.1.3. Interfaces de software . . . .
3.1.4. Interfaces de comunicacion .
3.2. Requisitos funcionales . . . . . . . .
3.2.1. Requisito funcional RF1-1 . .
3.2.2. Requisito funcional RF1-2 . .
3.2.3. Requisito funcional RF1-3 . .
3.2.4. Requisito funcional RF1-4 . .
3.2.5. Requisito funcional RF1-5 . .
3.2.6. Requisito funcional RF2-1 . .
3.2.7. Requisito funcional RF2-2 . .
3.2.8. Requisito funcional RF2-3 . .
3.2.9. Requisito funcional RF3-1 . .
3.2.10. Requisito funcional RF3-2 . .
3.2.11. Requisito funcional RF3-3 . .
3.2.12. Requisito funcional RF4-1 . .
3.2.13. Requisito funcional RF4-2 . .
3.2.14. Requisito funcional RF4-3 . .
3.2.15. Requisito funcional RF5-1 . .
3.2.16. Requisito funcional RF5-2 . .
3.2.17. Requisito funcional RF5-3 . .
3.3. Requisitos no funcionales . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

14
16
16
16
17
18
18
18
18
19
19
20
20
21
21
22
22
23
23
24
24
25
25
26
27

3.3.1.
3.3.2.
3.3.3.
3.3.4.
3.3.5.
3.3.6.
3.3.7.

Requisitos de rendimiento
Seguridad . . . . . . . . .
Fiabilidad . . . . . . . . .
Disponibilidad . . . . . .
Mantenibilidad . . . . . .
Portabilidad . . . . . . . .
Otros Requisitos . . . . .

4. APENDICES

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

27
27
27
27
28
28
28
29

1.

INTRODUCCION

Este documento es realizado con la finalidad de analizar los requisitos, que es

una de las tareas m
as importantes en el ciclo de vida del desarrollo de software.
En este caso el desarrollo del sitio WEB: www.topcallsevice.com, puesto que
en este documento se determinan los planos de la nueva aplicacion WEB. Los
requisitos son las necesidades del producto que se van a desarrollar. Por ello, en
la fase de an
alisis de requisitos se deben identificar claramente estas necesidades
y documentarlas. Como resultado de esta fase este documento describe lo que el
futuro sistema debe hacer. Por tanto, no se trata simplemente de una actividad
de an
alisis.
El sitio WEB que se desarrollara permitira registrar, administrar, gestionar,
las actividades que ofrece la empresa Top Servicie Centro de Servicio Tecnico
Autorizado Whirlpool a los clientes que adquieren los productos de la marca.
Actualmente se han visto en la necesidad de un sitio web privado que sea: Usable, Funcional, Confiable, Eficiente con la Facilidad de recibir Mantenimiento,
que ayude a la administracion global de la Empresa, que es la administracion
y control de la informaci
on de Clientes, Tecnicos, Rutas y Horarios, Gestion de
Ordenes de Servicio Tecnico y Reportes especficos de la Empresa.

1.1.

Prop
osito

Este documento ha sido redactado con el fin de marcar las pautas generales y las especificaciones que debera seguir el software a desarrollar (aplicacion
WEB), con el objetivo final de resolver las necesidades que el cliente ha planteado.
Servir
a como canal de comunicacion entre la Empresa: Top Servicie Centro
de Servicio Tecnico Autorizado Whirlpool y Equipo de desarrollo.
Este documento est
a sujeto a revisiones, especialmente por los potenciales usuarios, hasta alcanzar su aprobacion. Una vez aprobado servira de base al equipo
de desarrollo del sitio WEB: www.topcallsevice.com para la construccion del
nuevo sitio WEB.

1.2.

Alcance

Se implementar
a el sitio web privado con el fin de dar sol
ucion a los problemas por los que act
ualmente atraviesa la Empresa: Top Servicie Centro de
Servicio Tecnico A
utorizado Whirlpool, en la administracion y control de la informaci
on de Clientes, Tecnicos, R
utas, Gestion de Ordenes de Servicio Tecnico
y Reportes.
Los m
od
ulos q
ue el sistema debe manejar son:
uario.
Administraci
on de C
uentas de Us
Administraci
on de Informacion de Clientes.
Administraci
on de Informacion de Tecnicos.

Administraci
on de Ordenes
de Servicio Tecnico.
Administraci
on de R
utas y horarios de Servicio Tecnico
Administraci
on de Reportes.
1.2.1.

Objetivo General

Desarrollar e implementar un sitio WEB para la administracion y control de

la informaci
on de Clientes, Empleados, Rutas y Horarios, Gestion de Ordenes de
Servicio Tecnico y Reportes. La cual podra ser utilizada desde las Sucursales de
la Empresa. Mejorando Administracion y la Calidad de la Empresa Top Service
Centro de Servicio Tecnico Autorizado Whirlpool.
1.2.2.

Objetivos Especficos

Levantar nuevos requisitos para tener claro la situacion actual de la empresa.

Hacer uso de los requerimientos obtenidos para desarrollar un aplicativo
que cumpla con las necesidades de la empresa.
Ejecutar Pruebas para satisfacer las necesidades del usuario
Modelar una Base de Datos para registrar datos de Clientes, Empleados,
Rutas y Horarios, Gestion de Ordenes de Servicio Tecnico y Reportes
existentes.
Presentar reportes de los tenicos de la empresa con relacion a la informaci
on recaudada por las Ordenes de Trabajo.
Gestionar la rutas y horarios para mejorar el servicio tecnico y la rapidez
en la Atenci
on al Cliente.

1.3.

Personal involucrado

Nombre
Rol
Categora Profesional
Responsabilidad
Informaci
on de contacto

Ivan Espn Herrera

Jefe de la Empresa.
Ingeniero.
Administracion y supervision de los procesos en la Empresa.
09833714924

Cuadro 1: Personal involucrado: Grupo Empresarial.

Nombre
Rol
Categora Profesional
Responsabilidad
Informaci
on de contacto

Varias Colaboradoras
Seretarias de la Empresa.
Ingenieras y Bachilleres.
Recepcion de informacion en la Empresa.

Cuadro 2: Personal involucrado: Grupo Empresarial.

Nombre
Rol
Categora Profesional
Responsabilidad
Informaci
on de contacto

Varios Colaboradores
Tecnicos de la Empresa.
Ingenieros y Bachilleres.
Asistencia Tecnica.

Cuadro 3: Personal involucrado: Grupo Empresarial.

Nombre
Rol
Categora Profesional
Responsabilidad
Informaci
on de contacto

Luis Ivan Espn Velasco

Analista, dise
nador y programador.
Estudiante Universitario.
Analisis de informacion, dise
no y programacion del sistema.
liespin2@espe.edu.ec

Cuadro 4: Personal involucrado: Grupo de Analisis y Desarrollo

Nombre
Rol
Categora Profesional
Responsabilidad
Informaci
on de contacto

Cristian Jose Barba Barba

Analista, dise
nador y programador.
Estudiante Universitario.
Analisis de informacion, dise
no y programacion del sistema.
cjbarba@espe.edu.ec

Cuadro 5: Personal involucrado: Grupo de Analisis y Desarrollo

Nombre
Rol
Categora Profesional
Responsabilidad
Informaci
on de contacto

Elvis Ramiro Sarchi Albuja

Analista, dise
nador y programador.
Estudiante Universitario.
Analisis de informacion, dise
no y programacion del sistema.
ersarchi@espe.edu.ec

Cuadro 6: Personal involucrado: Grupo de Analisis y Desarrollo

Nombre
Rol
Categora Profesional
Responsabilidad
Informaci
on de contacto

Stalin Sebastian Salgado Escobar

Analista, dise
nador y programador.
Estudiante Universitario.
Analisis de informacion, dise
no y programacion del sistema.
sssalgado@espe.edu.ec

Cuadro 7: Personal involucrado: Grupo de Analisis y Desarrollo

1.4.

Definiciones, acr
onimos y abreviaturas

En esta parte se definen todos los terminos, abreviaturas y acronimos necesarios para interpretar apropiadamente este documento.
Nombre
Usuario
TCS
ERS
RF
RFN

Descripci
on
Persona que utilizara el sitio WEB.
www.topcallsevice.com
Especificacion de Requerimientos Software.
Requerimiento Funcional.
Requerimiento no Funcional.

Cuadro 8: Definiciones, acronimos y abreviaturas del Documento.

1.5.

Referencias

Referencia
1
2

Titulo
IEEE 830 SRS
INGENIERIA DEL SOFTWARE

Ruta
standards.ieee.org
f reelibros.org

Cuadro 9: Referencias del Documento.

Fecha
1998
2006

Autor
Roger Pressman.

1.6.

Resumen

Este documento consta de tres secciones. En la primera seccion se realiza una

introducci
on al mismo y se proporciona una vision general de la especificacion
de recursos del sistema.
En la segunda secci
on del documento se realiza una descripcion general del
sistema, con el fin de conocer las principales funciones que este debe realizar,
los datos asociados y los factores, restricciones, supuestos y dependencias que
afectan al desarrollo, sin entrar en excesivos detalles.
Por u
ltimo, la tercera secci
on del documento es aquella en la que se definen
detalladamente los requerimientos que debe satisfacer el sistema.

2.
2.1.

GENERAL
DESCRIPCION
Perspectiva del producto

Este proceso abarca desde que el cliente solicita el servicio hasta que se
cumple con el trabajo y el cliente queda satisfecho. Incluye registro de datos de
cliente, tecnico, Orden de Servicio, Rutas y Horarios y tambien Reportes si es
el caso. En este proceso intervienen distintos actores:
Administrador (Jefe): Podra crear cuenta de usuario, Rutas y Horarios
de Trabajo, Generar Reportes ademas de tener acceso total del sistema.
Recepcionista (Secretaria): Personal encargada de la demanda de atenci
on al cliente, que tiene como funcion principal la recepcion de informaci
on de los clientes, ademas la asignacion de tecnicos a las Ordenes de
Servicio.
T
ecnico: Proporciona la informacion necesaria de la Orden de Servicio y
el Cliente.
Cliente: Puede acceder al sistema atreves de las secretarias y solicitar
un nuevo servicio, confrmalo o cancelarlo, siendo una de las principales
fuentes de informaci
on.

Figura 1: Diagram de Roles del Sistema: aplicacion TopCallService

2.2.

Funcionalidad del producto

EL Sistema, aplicaci
on Web: TopCallService.com debe ser capaz de proporcionar Informaci
on a los usuarios una forma amigable de administrar
recursos.
Abarca m
ultiples aspectos en la gestion de cualquier sucursal de la Empresa: Top Servicie Centro de Servicio Tecnico Autorizado Whirlpool, tales
como: La administraci
on y control de la informacion de Clientes, Tecnicos,
Rutas, Gesti
on de Ordenes de Servicio Tecnico y Reportes.
Se adaptara a cualquier n
umero de profesionales (Jefes o Secretarias) sin
perder de vista la planificacion diaria de estos, contribuyendo a una gestion
optima en el servicio al cliente.

Gesti
on de Informaci
on de Clientes, Tecnicos, Rutas, Gestion de Ordenes
de Servicio Tecnico y Reportes en tiempo real.
Posibilidad de utilizacion mediante navegador WEB.

2.2.1.

Diagramas de Casos de Uso

Figura 2: Diagramas: Casos de Uso del Sietema

Figura 3: Diagrama Administracion de Cuentas de Usuario

Figura 4: Diagrama Administracion de Informacion de Clientes

10

Figura 5: Diagrama Administracion de Informacion de Tecnicos

Figura 6: Diagrama Administracion de Rutas y Horarios de Servicio Tecnico

Figura 7: Diagrama Administracion de Ordenes

de Servicio Tecnico
11

Figura 8: Diagrama Administracion de Reportes.

2.3.

Caractersticas de los usuarios

Este sistema estar

a orientado a usuarios de tipo basico, intermedio y avanzado. Con conocimientos en herramientas Microsoft.
Tipo de Usuario
Formaci
on
Actividades

Administrador (Jefe).
Academica y Profesional
Administracion de la Empresa y el Sistema.

Cuadro 10: Caractersticas de Usuario.

Tipo de Usuario
Formaci
on
Actividades

Resepcionistas (Secretarias).
Academica entre Bachillerato y Universidad.

Recepcion de datos de Clientes, Ordenes

y Tecnicos.

Cuadro 11: Caractersticas de Usuario.

2.4.

Restricciones
Se ejecutara solo en plataformas que soporte Flash Player.
Se ejecutar
a desde cualquier navegador.
Ocupar
a base de datos Oracle.
Adobe Flash + ZEND AMF Library.
PHP utilizando AMF para la comunicacian entre Cliente - Servidor.

2.5.

Suposiciones y dependencias

Los requisitos descritos en este documento pueden cambiar, pues los procesos son din
amicos y por lo tanto cambia los requisitos del software, para lo cual
es necesario que las fases de analisis y dise
no esten bien documentadas y ademas
definir una fase y metodologa de mantenimiento del sistema.
El sitio Web: TopCallService.com funciona independientemente, sin necesidades de comunicarse con otros sistemas externos, por lo que no hay dependencias
respecto de otros sistemas.

12

2.6.

Evoluci
on previsible del sistema
Se deber
a implementar una interfaz exclusiva para visualizar con estadsticas el desempe
no de Tecnicos y Secretarias. En esta interfaz se podran
visualizar los siguientes datos:
Se visualizara una descripcion del individuo.
Datos de evoluciones de servicio con relacion al individuo.
Reporte de clientes Atendidos con relacion al individuo.
Gr
aficas de Desempe
no de acuerdo a valores establecidos.
Personal disponible en ese instante.
Optimizaci
on de los tiempos de la organizacion.
Personal disponible en ese instante.

13

3.

REQUISITOS ESPECIFICOS

Figura 9: Lista de Requisitos Funcionales

14

Figura 10: Trazabilidad y Validacion de los Requisitos Funcionales

15

3.1.

Requisitos comunes de las interfaces

Cuando el usuario interact

ua con un sistema basado en computadora, se
aplica un conjunto de principios fundamentales y lineamientos generales de dise
no.

DE LA INTERFAZ DE LA WEB APP.

Figura 11: DISENO
3.1.1.

Interfaces de usuario

El usuario que manipulara el sistema lo hara mediante el teclado y el mouse.

Las interfaces se elaborar
an en la plataforma de ASP.net C# e incluiran:
Botones
Men
us desplegables
Mensajes informativos
Mensajes de error
Dise
no Mixto de Navegacion Web para el ingreso, modificacion, actualizaci
on y b
usqueda de datos.
Otros
3.1.2.

Interfaces de hardware

La pantalla del monitor el software debera mostrar informacion al usuario a traves de la pantalla del monitor.
Rat
on el software debe interactuar con el movimiento del raton y los
botones del rat
on. El raton activara las zonas de entrada de datos, botones
de comando y seleccionara las opciones de los men
us.
Teclado el software debera interactuar con las pulsaciones del teclado.
16

 DE ARQUITECTURA
Figura 12: DISENO
3.1.3.

Interfaces de software

Figura 13: CUADRO COMPARATIVO DE NAVEGABILIDAD

17

3.1.4.

Interfaces de comunicaci
on

El sistema no cuenta con comunicacion con otros sistemas.

3.2.
3.2.1.

Requisitos funcionales
Requisito funcional RF1-1

Figura 14: Requisito funcional RF1-1

3.2.2.

Requisito funcional RF1-2

Figura 15: Requisito funcional RF1-2

18

3.2.3.

Requisito funcional RF1-3

Figura 16: Requisito funcional RF1-3

3.2.4.

Requisito funcional RF1-4

Figura 17: Requisito funcional RF1-4

19

3.2.5.

Requisito funcional RF1-5

Figura 18: Requisito funcional RF1-5

3.2.6.

Requisito funcional RF2-1

Figura 19: Requisito funcional RF2-1

20

3.2.7.

Requisito funcional RF2-2

Figura 20: Requisito funcional RF2-2

3.2.8.

Requisito funcional RF2-3

Figura 21: Requisito funcional RF2-3

21

3.2.9.

Requisito funcional RF3-1

Figura 22: Requisito funcional RF3-1

3.2.10.

Requisito funcional RF3-2

Figura 23: Requisito funcional RF3-2

22

3.2.11.

Requisito funcional RF3-3

Figura 24: Requisito funcional RF3-3

3.2.12.

Requisito funcional RF4-1

Figura 25: Requisito funcional RF4-1

23

3.2.13.

Requisito funcional RF4-2

Figura 26: Requisito funcional RF4-2

3.2.14.

Requisito funcional RF4-3

Figura 27: Requisito funcional RF4-3

24

3.2.15.

Requisito funcional RF5-1

Figura 28: Requisito funcional RF5-1

3.2.16.

Requisito funcional RF5-2

Figura 29: Requisito funcional RF5-2

25

3.2.17.

Requisito funcional RF5-3

Figura 30: Requisito funcional RF5-3

26

3.3.

Requisitos no funcionales

3.3.1.

Requisitos de rendimiento

Rendimiento del Sistema:

El sistema de puede ser utilizado por varios usuarios a la vez ya que son
el n
umero de operadores del sistema ya sea para atender al cliente o para
la asignaci
on del tecnico requerido en dicho momento.
El espacio magnetico o espacio requerido en memoria se especificara cuando se implemente o se desarrolle el sistema en su totalidad.
3.3.2.

Seguridad

La seguridad del sistema esta especificada en los siguientes parametros:

La Interacci
on en tiempo real de los clientes contratantes con la gestion
del sistema que generara confianza y seguridad en la gestion.
El Firewall que es el elemento de seguridad que permite controlar las
comunicaciones que se establecen entre la red de area local y el exterior.
Cada usuario tendr
a su contrase
na por defecto inicialmente pero en el
primer ingreso al sistema tendra que cambiar obligadamente su contrase
na
brindando mayor seguridad.
Para crear nuevos usuarios sera gestionada directamente desde el administrador del sistema evitando a los usuarios no deseados.
3.3.3.

Fiabilidad

Fiabilidad del Sistema:

El acceso al sistema de manera incondicional sera gestionado por el administrador designado. El n
umero de intentos fallidos al acceso al sistema
ser
a propuesto por el administrador. As se proveera la obtencion de informaci
on de personas particulares del Sistema.
Tambien se podr
a realizar respaldos cada cierto tiempo especificado dependiendo del n
umero de actividades y necesidades.
3.3.4.

Disponibilidad

Disponibilidad del Sistema:

El sistema estar
a disponible cuando los usuarios lo requieran, en particular
al tiempo que est
a dispuesto por el codigo laboral del pas es decir las 8
horas diarias de trabajo.

27

La Web App es capaz de satisfacer las necesidades de los usuarios desde

cualquier lugar. En sentido tecnico, la disponibilidad es la medida porcentual del tiempo que una Web App . El usuario final com
un espera que las
Web Apps se hallen disponibles las 24 horas de los 365 das del a
no.
3.3.5.

Mantenibilidad

Dependiendo del grado de satisfaccion del usuario final los desarrolladores

deben estar posteriormente dispuestos a las actualizaciones o cambios que sugiera el usuario con previa anticipacion, o cumpliendo lo establecido en un contrato
inicial que puede ser semestralmente, anualmente dependiendo de las clausulas
del contrato.
3.3.6.

Portabilidad

El Sistema se realizar
a en formato Web App que requiere solo acceso al
internet para poder acceder al sistema.
La base de datos se puede afirmar que es 100 % portable porque la herramienta de MySQL puede instalarse en los sistemas operativos mas utilizados como son Windows y Linux, sin ning
un problema.
En el caso que el sistema requiera ser implementado en plataforma cliente/servidor se limitara su portabilidad a un porcentaje mayor.
3.3.7.

Otros Requisitos

28

4.

APENDICES

29