DUOC UC - Escuela de informática y telecomunicaciones

Propuesta de Proyecto
y Especificación de
Requisitos de Software
Proyecto: Sistema de escritorio RRHH
Revisión: [01]
07/07/2022

Planificación y Especificación de Requisitos según estándares; IEEE 830, ISO9000 y PMI.

 Especificación de Requisitos, estándar de IEEE 830

Contenido
FICHA DEL DOCUMENTO 3

1. INTRODUCCIÓN 4

1.1. PROPÓSITO 4
1.2. ÁMBITO DEL SISTEMA 4
1.3. DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS 4
1.4. REFERENCIAS 4
1.5. VISIÓN GENERAL DEL DOCUMENTO 4

2. DESCRIPCIÓN GENERAL 5

2.1. PERSPECTIVA DEL PRODUCTO 5

2.2. FUNCIONES DEL PRODUCTO 5
2.3. CARACTERÍSTICAS DE LOS USUARIOS 5
2.4. RESTRICCIONES 5
2.5. SUPOSICIONES Y DEPENDENCIAS 6
2.6. REQUISITOS FUTUROS 6

3. REQUISITOS ESPECÍFICOS 7

3.1 REQUISITOS COMUNES DE LAS INTERFACES 8

3.1.1 Interfaces de usuario 8
3.1.2 Interfaces de hardware 8
3.1.3 Interfaces de software 8
3.1.4 Interfaces de comunicación 8
3.2 REQUISITOS FUNCIONALES 8
3.3 REQUISITOS NO FUNCIONALES 9
3.3.1 Requisitos de rendimiento 9
3.3.2 Seguridad 9
3.3.3 Fiabilidad 10
3.3.4 Disponibilidad 10
3.3.5 Mantenibilidad 10
3.3.6 Portabilidad 10
3.4 OTROS REQUISITOS 10

4. PROPUESTA DE PLANIFICACIÓN 11

4.1 DESCRIPCIÓN GENERAL ACERCA DE LA PLANIFICACIÓN 11

4.1.2 Definición del Equipo de Trabajo 11
4.1.3 Definición de Actividades principales del Proyecto 11
4.1.4 Diagrama EDT 11
4.1.5 Carta Gantt 11
4.1.6 Resumen Costos del Desarrollo del Proyecto 11

2
 Especificación de Requisitos, estándar de IEEE 830

4.2 PLAN DE CONTROL DE CAMBIO 12

5. ANEXOS 12
5.1 Acta de Proyecto 12
5.2 Matriz Especificación de Requerimientos 12
5.3 Diagrama de Casos de Uso General 12
5.4 Planilla Casos de Uso 12
5.5 Prototipado de Software 13
5.6 Resultado Análisis de Calidad Diagramas Modelamiento 13
5.7 Resultado Análisis de Calidad Prototipado No funcional del Sistema 13
5.8 Planilla entregables del Proyecto 13
5.9 Matriz de Control de Cambios 13
5.10 Matriz EDT. Planilla Detallada Cálculo de Esfuerzo 13

Ficha del documento

Fecha Revisión Autor Modificación

Ignacio Riffo Desarrollo de la Propuesta de

21/06/20
1 Proyecto y Especificación de
22 Daniel Orellana Requisitos de Software

Documento validado por las partes en fecha:

Integrantes:
Nombre Integrante del Equipo Rol Definido

Daniel Orellana Jefe de proyecto

Ignacio Riffo Analista

Nicolás Martinez Diseñador

Nicolás Arriagada Programador

3
 Especificación de Requisitos, estándar de IEEE 830

Javier Zamorano Asegurador de Calidad

1. Introducción
En esta sección se proporcionará una introducción a todo el documento de Especificación de
Requisitos Software (ERS). Consta de varias subsecciones: propósito, ámbito del sistema,
definiciones, referencias y visión general del documento.

1.1. Propósito
El propósito de la Especificación de Requisitos del Sistema (ERS) es servir como medio de
comunicación entre clientes, usuarios, ingenieros de requisitos y desarrolladores. En la ERS deben
recogerse tanto las necesidades de clientes y usuarios, como los requisitos que debe cumplir el
sistema software a desarrollar para satisfacer dichas necesidades.

1.2. Ámbito del Sistema

• Nombre del Sistema: RRHH Instalum.

• El sistema será una aplicación de escritorio, la cual podrá registrar las contrataciones,
bonificaciones y capacitaciones de los trabajadores. Las bonificaciones deben ser calculadas en
base a la información de las encuestas de servicio que entregará automáticamente el sistema
actual de la empresa. Se mantendrá un listado con las capacitaciones anuales a realizar en la
empresa. Se deberá garantizar un sistema seguro en el cual no haya fuga de datos y mantener la
confidencialidad de la información de los usuarios. Los usuarios podrán entrar al sistema sólo si
poseen una cuenta habilitada.

1.3. Definiciones, Acrónimos y Abreviaturas

1. Administrar: Acción de agregar, modificar, eliminar o visualizar la información dentro del
sistema.
2. Software: Programa previamente modificado que realiza una determinada tarea.
3. Hardware: Elementos físicos que forman parte de un equipo.
4. Login: Algoritmo que permite el ingreso de un usuario al sistema, mediante un usuario y
contraseña previamente creados.
5. Sistema: Aplicación final, donde el usuario administra la información.
6. Cuestionario: Conjunto de datos específicos que debe llenar el usuario en un ambiente
digital para interferir en el sistema.
7. Reporte: Resultado registrado tras una interacción en el sistema.
8. Datos: Información independiente o conjunto de ella.
9. Aplicación: Conjunto de algoritmos que terminan formando un sistema con determinadas
funciones.
10. Algoritmo: Instrucciones dadas a una computadora para realizar lo que se solicita.

4
 Especificación de Requisitos, estándar de IEEE 830

1.4. Referencias
➔ Documentación de caso de usos.
➔ Planificación y especificación de requisitos según estándares.
➔ Matriz de requerimientos.
➔ Minuta Kickoff.
➔ Planilla de requerimientos.
➔ Acta de constitución.
➔ Modelo requisitos funcionales y no funcionales.

1.5. Visión General del Documento

En el presente documento se encontrará la información acerca de las características del sistema
de software, características de los usuarios, descripción de los requerimientos funcionales, no
funcionales del sistema. El documento concluye con las propuestas de planificación del producto
entregable, con definición del equipo de trabajo, actividades relacionadas, Carta Gantt y estimado
presupuestario del costo del sistema, etc.

2. Descripción General
En esta sección se describen todos aquellos factores que afectan al producto y a sus requisitos. No
se describen los requisitos, sino su contexto. Esto permitirá definir con detalle los requisitos en la
sección 3, haciendo que sean más fáciles de entender.

Normalmente, esta sección consta de las siguientes subsecciones: Perspectiva del producto,
funciones del producto, características de los usuarios, restricciones, factores que se asumen y
futuros requisitos.

2.1. Perspectiva del Producto

➔ El sistema de software estará diseñado para funcionar en Windows 7 en adelante.
➔ Estará relacionado con un almacenamiento en base de datos (ORCL).

2.2. Funciones del Producto

A. Autenticar y validar el ingreso de sus usuarios.
B. Registrar datos de la cuenta de un usuario.
C. Diferenciar roles según cargo.
D. Administrar Usuarios (Agregar, Modificar, Eliminar y Visualizar).
E. Administrar Colaboradores (Agregar, Modificar, Eliminar y Visualizar).
F. Administrar Bonificaciones (Calcular, Agregar, Modificar, Eliminar y Visualizar).
G. Administrar Contrataciones (Agregar, Modificar, Eliminar y Visualizar).
H. Administrar Capacitaciones (Agregar, Modificar, Eliminar y Visualizar).

5
 Especificación de Requisitos, estándar de IEEE 830

2.3. Características de los Usuarios

La interacción con el software contará con acceso de cuatro tipos de usuarios, Los cuales son: TI,
Administrador de Contrataciones, Administrador de Bonificaciones, Administrador de
Capacitaciones.

A. TI: Usuario con la capacidad de administrar los otros tipos de usuarios, el TI por lo general
posee un nivel de educación superior en relación al área informática por lo que se encarga
de administrar.
B. Administrador de Contrataciones: Usuario encargado de administrar las contrataciones, él
es el que las agrega, las modifica, elimina o visualiza. Por lo general este cargo lo ocupa
alguien técnico en administración, o con estudios superiores relacionados a lo mismo. En
este caso específico puede ser utilizado para alguien sin estudios o con estudios en otras
áreas.

C. Administrador de Bonificaciones: Usuario destinado a administrar las bonificaciones, las

calcula, las ingresa, las modifica, elimina y también las visualiza. Al igual que el
administrador de contrataciones, este tipo de cargo lo utiliza un usuario con un nivel
técnico o de ingeniero en administración. En este caso específico puede ser utilizado para
alguien sin estudios o con estudios en otras áreas.

D. Administrador de Capacitaciones: Usuario designado a administrar las capacitaciones, las

agrega, las modifica o elimina, también puede visualizarlas cuando amerite la ocasión. Este
cargo también tiende a ser utilizado por técnicos o ingenieros en administración. En este
caso específico puede ser utilizado para alguien sin estudios o con estudios en otras áreas.

2.4. Restricciones
Esta subsección describe aquellas limitaciones que se imponen sobre los desarrolladores del
producto:

• Políticas de la empresa. (La licencia del software es de uso exclusivo para la empresa Instalum.)

• Limitaciones del hardware. (Para la instalación del programa se requiere que soportar ORCL)

• Interfaces con otras aplicaciones. (el software no necesita conexiones con otros sistemas)

• Operaciones paralelas. (No aplica)

• Funciones de auditoría. (Evitar cambios desautorizados)

• Funciones de control. (Controlar los permisos de cada usuario)

• Lenguaje(s) de programación. (Python y ORCL)

6
 Especificación de Requisitos, estándar de IEEE 830

• Protocolos de comunicación. (Lenguaje principal Español)

• Requisitos de habilidad. (La administración de los departamentos debe esta ligada a la realidad)

• Criticidad de la aplicación. (sistema deberá ser sometido a una serie de pruebas)

• Consideraciones acerca de la seguridad. (Datos privados deben estar encriptados)

2.5. Suposiciones y Dependencias

Esta subsección de la ERS describe aquellos factores que, si cambian, pueden afectar a los
requisitos. Por ejemplo, los requisitos pueden presuponer una cierta organización de ciertas
unidades de la empresa, o pueden presuponer que el sistema correrá sobre cierto sistema
operativo. Si cambian dichos detalles en la organización de la empresa, o si cambian ciertos
detalles técnicos, como el sistema operativo, puede ser necesario revisar y cambiar los requisitos.

Debe realizarse una capacitación adecuada y acorde a lo que cada usuario va a realizar. Su
capacitación se hará en el momento que sea necesaria y a las personas indicadas.
Sólo se trabajará con el software en sistemas operativos Windows.

2.6. Requisitos Futuros

No aplica.

3. Requisitos Específicos
Esta sección contiene los requisitos a un nivel de detalle suficiente como para permitir a los
diseñadores diseñar un sistema que satisfaga estos requisitos, y que permita al equipo de pruebas
planificar y realizar las pruebas que demuestren si el sistema satisface, o no, los requisitos. Todo
requisito aquí especificado describirá comportamientos externos del sistema, perceptibles por
parte de los usuarios, operadores y otros sistemas. Esta es la sección más larga e importante de la
ERS. Deberán aplicarse los siguientes principios:

• El documento debería ser perfectamente legible por personas de muy distintas

formaciones e intereses.

• Deberán referenciarse aquellos documentos relevantes que poseen alguna influencia

sobre los requisitos.

• Todo requisito deberá ser unívocamente identificable mediante algún código o sistema de
numeración adecuado.

• Lo ideal, aunque en la práctica no siempre realizable, es que los requisitos posean las
siguientes características:

7
 Especificación de Requisitos, estándar de IEEE 830

− Corrección: La ERS es correcta si y sólo si todo requisito que figura aquí (y que será
implementado en el sistema) refleja alguna necesidad real. La corrección de la ERS implica
que el sistema implementado será el sistema deseado.
− No ambiguos: Cada requisito tiene una sola interpretación. Para eliminar la ambigüedad
inherente a los requisitos expresados en lenguaje natural, se deberán utilizar gráficos o
notaciones formales. En el caso de utilizar términos que, habitualmente, poseen más de
una interpretación, se definirán con precisión en el glosario.
− Completos: Todos los requisitos relevantes han sido incluidos en la ERS. Conviene incluir
todas las posibles respuestas del sistema a los datos de entrada, tanto válidos como no
válidos.
− Consistentes: Los requisitos no pueden ser contradictorios. Un conjunto de requisitos
contradictorios no es implementable.
− Clasificados: Normalmente, no todos los requisitos son igual de importantes. Los
requisitos pueden clasificarse por importancia (esenciales, condicionales u opcionales) o
por estabilidad (cambios que se espera que afecten al requisito). Esto sirve, ante todo,
para no emplear excesivos recursos en implementar requisitos no esenciales.
− Verificables: La ERS es verificable si y sólo si todos sus requisitos son verificables. Un
requisito es verificable (testable) si existe un proceso finito y no costoso para demostrar
que el sistema cumple con el requisito. Un requisito ambiguo no es, en general,
verificable. Expresiones como a veces, bien, adecuado, etc. Introducen ambigüedad en los
requisitos. Requisitos como “en caso de accidente la nube tóxica no se extenderá más allá
de 25 Km" no es verificable por el alto costo que conlleva.
− Modificables: La ERS es modificable si y sólo si se encuentra estructurada de forma que los
cambios a los requisitos pueden realizarse de forma fácil, completa y consistente. La
utilización de herramientas automáticas de gestión de requisitos facilita enormemente
esta tarea.
− Trazables: La ERS es trazable si se conoce el origen de cada requisito y se facilita la
referencia de cada requisito a los componentes del diseño y de la implementación. La
trazabilidad hacia atrás indica el origen (documento, persona, etc.) de cada requisito. La
trazabilidad hacia delante de un requisito R indica qué componentes del sistema son los
que realizan el requisito R.

3.1 Requisitos comunes de las interfaces

3.1.1 Interfaces de usuario

Describir los requisitos del interfaz de usuario para el producto. Esto puede estar en la forma de
descripciones del texto o pantallas del interfaz. Por ejemplo, posiblemente el cliente ha
especificado el estilo y colores del producto. Describa exactamente cómo el producto aparecerá a
su usuario previsto.

8
 Especificación de Requisitos, estándar de IEEE 830

1.- Inicio de sesión: Pantalla donde el usuario debe ingresar su cuenta. En esta misma pantalla,
selecciona previamente a que menú quiere ingresar, teniendo cuatro opciones; TI, Contrataciones,
Bonificaciones, Capacitaciones.

1.1.- Menú TI: En caso de que el ingreso fuese a la sección TI y además la cuenta es validada por el
sistema, se ingresará a la interfaz del menú TI compuesto por las siguientes funciones; ‘Asignar
perfil, Crear perfil, Eliminar perfil, Modificar perfil, Visualizar perfil. “

1.2.- Menú contrataciones: En caso de que el ingreso fuese a la sección de contrataciones y la

cuenta es validada por el sistema, entonces se direccionará al menú de contrataciones, compuesto
por diferentes funciones, tales como; “ Ingresar contrato, Eliminar contrato, Modificar contrato,
Visualizar contrato. “

1.3.- Menú Bonificaciones: En caso de que el usuario marque la sección de bonificaciones y el

ingreso de sesión sea exitoso, pasará al menú de bonificaciones, compuesto por las siguientes
funciones; “Ingresar bonificación, Eliminar bonificación, Modificar bonificación, Visualizar
bonificación, Asignar bonificación. “

1.4.- Menú Capacitaciones: En caso de que el usuario seleccione la sección de capacitaciones y

además el sistema valide el inicio de sesión, será redirigido al menú de capacitaciones, compuesto
por las siguiente funciones; “Ingresar capacitación, Eliminar capacitación, Modificar capacitación,
Visualizar capacitación, Asignar capacitación. “

3.1.2 Interfaces de hardware

Especificar las características lógicas para cada interfaz entre el producto y los componentes de
hardware del sistema. Se incluirán características de configuración.

Tras cada acción, habrá una reacción específica la cual será enviada a la pantalla para que el
usuario determine el actuar por venir. Ejemplos de esto;

➔ Iniciar sesión: Se mostrará en pantalla la interfaz de usuario; iniciar sesión.

Con el mouse se puede seleccionar la opción que tenga intención y con el teclado se ingresan los
datos solicitados para cada proceso.

3.1.3 Interfaces de software

Indicar si hay que integrar el producto con otros productos de software.

− Para cada producto de software debe especificarse lo siguiente:

− Descripción del producto software utilizado
− Propósito del interfaz
− Definición del interfaz: contenido y formato

9
 Especificación de Requisitos, estándar de IEEE 830

3.1.4 Interfaces de comunicación

Describir los requisitos del interfaz de comunicación si hay comunicaciones con otros sistemas y
cuáles son los protocolos de comunicación.

Hay dos aplicaciones que se comunican la una con la otra, sería la base de datos, hecha en ORCL
MySQL y con el programa generado en Python.

3.2 Requisitos funcionales

Definición de acciones fundamentales que debe realizar el software al recibir información,
procesarla y producir resultados.

En ellas se incluye:

− Comprobación de validez de las entradas

− Secuencia exacta de operaciones
− Respuesta a situaciones anormales (desbordamientos, comunicaciones, recuperación de
errores)
− Parámetros
− Generación de salidas
− Relaciones entre entradas y salidas (secuencias de entradas y salidas, fórmulas para la
conversión de información)
− Especificación de los requisitos lógicos para la información que será almacenada en base
de datos (tipo de información, requerido)

Los requisitos funcionales principales pueden ser divididos en sub-secciones.

● Login: sistema que permite ingresar al sistema con un usuario y contraseña.

● Jerarquía: Sistema que organiza el acceso de los usuarios según su departamento.
● Administración: sistema permite agregar, modificar, eliminar y visualizar los datos.

Nota: Los Requerimientos específicos se detallarán en los anexos de Planillas de

Requerimientos.

3.3 Requisitos no funcionales

3.3.1 Requisitos de rendimiento

Especificación de los requisitos relacionados con la carga que se espera tenga que soportar el
sistema. Por ejemplo, el número de terminales, el número esperado de usuarios simultáneamente
conectados, número de transacciones por segundo que deberá soportar el sistema, etc.

Todos estos requisitos deben ser mensurables. Por ejemplo, indicando “el 95% de las
transacciones deben realizarse en menos de 1 segundo”, en lugar de “los operadores no deben
esperar a que se complete la transacción”.

10
 Especificación de Requisitos, estándar de IEEE 830

1.-Tendrá una capacidad total de 100 usuarios a su 100 %, pero estará ajustada mayormente para
un flujo de 50-60 personas, para que funcione siempre en su mejor manera.

3.3.2 Seguridad
Especificación de elementos que protegerán al software de accesos, usos y sabotajes maliciosos,
así como de modificaciones o destrucciones maliciosas o accidentales. Los requisitos pueden
especificar:

− Empleo de técnicas criptográficas.

− Registro de ficheros con “logs” de actividad.
− Asignación de determinadas funcionalidades a determinados módulos.
− Restricciones de comunicación entre determinados módulos.
− Comprobaciones de integridad de información crítica.

− Sistema de verificación de seguridad: Extra al inicio de sesión, agregando un código

personal para poder hacer ingreso al sistema, agregando 1 minuto al login. En caso de
perder el código personal, algún trabajador TI debe tener respaldo de todo.

− Cortafuegos con el internet dejando la aplicación sin internet.

3.3.3 Fiabilidad
Especificación de los factores de fiabilidad necesaria del sistema. Esto se expresa generalmente
como el tiempo entre los incidentes permisibles, o el total de incidentes permisibles.

● En posibles errores del sistema, tiene un reinicio forzado, que toma máximo 1 minuto,
estos casos pueden ser debido a algún incidente , al usar el reinicio forzado se genera un
guardado automático de archivos para así evitar la pérdida del progreso de los
trabajadores.
● La aplicación hará continuamente respaldos con toda la información, comprimidos para
evitar un uso excesivo de memoria en el sistema.

3.3.4 Disponibilidad
Especificación de los factores de disponibilidad final exigidos al sistema. Normalmente expresados
en % de tiempo en los que el software tiene que mostrar disponibilidad.

3.3.5 Mantenibilidad
Identificación del tipo de mantenimiento necesario del sistema.

Especificación de quién debe realizar las tareas de mantenimiento, por ejemplo usuarios, o un
desarrollador.

11
 Especificación de Requisitos, estándar de IEEE 830

Especificación de cuándo deben realizarse las tareas de mantenimiento. Por ejemplo, generación
de estadísticas de acceso semanales y mensuales.

La aplicación cumple funciones reiteradas debido al tipo de trabajo, haciendo que su código sea el
mismo, proveyendo así un sistema estable que requiera solo actualizaciones cuando la empresa
haga un cambio. Esto habla de que nuestro producto es adaptable, en estos casos se cuenta con el
contacto directo con nuestra empresa, siendo nosotros los que actualizaremos el software con lo
que amerite la ocasión.

3.3.6 Portabilidad
Especificación de atributos que debe presentar el software para facilitar su traslado a otras
plataformas y entornos. Pueden incluirse:

− Uso de un determinado lenguaje por su portabilidad.

− Uso de un determinado compilador o plataforma de desarrollo.
− Uso de un determinado sistema operativo.

− Instalable en cualquier Hardware de escritorio con Windows entre 7 y 10.

− Portatil, teniendo en cuenta que tendrá un instalador se vuelve portátil, puede ajustarse a
cualquier unidad de memoria, como por ejemplo, pendrives, celulares, etc.

3.4 Otros Requisitos

No aplica

4. Propuesta de Planificación

4.1 Descripción general acerca de la Planificación

El trabajo será abordado en 3 meses, trabajando en las distintas áreas como análisis, diseño,
desarrollo e implementación, El horario de trabajo se llevará a cabo de lunes a viernes.

4.1.2 Definición del Equipo de Trabajo

DICCIONARIO EDT
ROL SIGLA NOMBRE COSTO x HORA
ROL 1  JP  Daniel Orellana   $9350
ROL 2  AC  Ignacio Riffo.   $6086
ROL 3  QA  Javier Zamorano.   $5569
ROL 4  ADC  Nicolas Arriagada   $6874
ROL 5  DS  Nicolas Martinez.   $5565

12
 Especificación de Requisitos, estándar de IEEE 830

4.1.3 Definición de Actividades principales del Proyecto

Fase de Planificación
Kick Off
Acta de Constitución de proyecto
Aprobación del Acta
Definición de requerimientos Generales del proyecto
Organización del equipo
Fase de Análisis y diseño
Captura de requerimientos específicos
Análisis de requerimientos
Diseño de la solución. Modelamientos
Propuesta ERS
Plan de proyecto
Fase de Desarrollo
Implementación ambiente de desarrollo
Administrar Contratación
Añadir Contrato
Modificar Contrato
Eliminar Contrato
Visualizar Contrato
Asignar Contrato
Administrar Bonificación
Añadir Bonificación
Modificar Bonificación
Eliminar Bonificación
Visualizar Bonificación
Asignar Bonificación
Administrar Capacitación
Añadir Capacitación
Modificar Capacitación
Eliminar Capacitación
Visualizar Capacitación
Asignar Capacitación
Administrar Usuario
Crear Usuario
Modificar Usuario
Eliminar Usuario
Asignar Usuario

13
 Especificación de Requisitos, estándar de IEEE 830

Visualizar Usuario
Fase de Pruebas y Control de calidad
Matriz Prueba
Informe de resultado
Informe de calidad
Integración del sistema
Fase de implementación y cierre
Pruebas unitarias componente 1, 2
Pruebas unitarias componente 3, 4
Pruebas unitarias componente 5
Pruebas de integración
Migración del sistema a producción
Pruebas de integración final
Marcha blanca
Capacitación
Cierre de proyecto

4.1.4 Diagrama EDT

Diagrama EDT.pptx

4.1.5 Carta Gantt

Carta Gantt

4.1.6 Resumen Costos del Desarrollo del Proyecto

COSTO POR FASE

Fase de Planificación $295.516
Fase de Análisis y Diseño $1.427.982
Fase de Desarrollo $2.874.967
Fase de Pruebas y Control de Calidad $248.593
Fase de Implementación y Cierre $500.088
TOTAL HH FASES $5.347.144

COSTO HH POR ROL

Jefe de Proyecto $1.795.390
Analista de Calidad $1.101.507
Programador $974.589
Asegurador de calidad $852.415

14
 Especificación de Requisitos, estándar de IEEE 830

Diseñador $623.244
TOTAL HH $5.347.144

4.2 Plan de Control de Cambio

No aplica

5. Anexos

5.1 Acta de Proyecto

Acta de constitución.docx

5.2 Matriz Especificación de Requerimientos

Planilla de Requerimientos.xlsx

5.3 Diagrama de Casos de Uso General

Diagrama de Casos de Uso

5.4 Planilla Casos de Uso

Especificación de Requerimientos.docx

5.5 Prototipado de Software

Mockup

5.6 Resultado Análisis de Calidad Diagramas Modelamiento

No aplica

5.7 Resultado Análisis de Calidad Prototipado No funcional del Sistema

No aplica

5.8 Planilla entregables del Proyecto

No aplica

5.9 Matriz de Control de Cambios

No aplica

5.10 Matriz EDT. Planilla Detallada Cálculo de Esfuerzo

Matriz_EDT.xlsx

15