Fase 3 Trabajo Colaborativo

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA
FASE 3 – PLANIFICACIÓN
ASIGNATURA: INGENIERÍA DE SOFTWARE
Sistemas Control Ingreso de muestras reportes de ensayos y facturación
MANOLO PAJARO BORRAS C.C. 8.718.129
JAIME ALEXIS BETANCURT LONDOÑO C.C. 10188438
SANTIAGO SAPUY RAMIREZ C.C. 1.117.514.863
EDWIN MARTINEZ ESPINOSA CC: 15373888
CRISTIAN ALBERTO GOMEZ RODRÍGUEZ 1.117.512.168
DOCENTE: Pilar Alexandra Moreno
Noviembre 26 de 2018
Sistemas Control Ingreso de muestras reportes de ensayos y
0.3
facturación
Pág. 2
Especificación de requisitos de software
Especificación de requisitos de
software
Proyecto: Sistemas Control Ingreso de muestras
reportes de ensayos y facturación
Revisión 1.0
Noviembre 2018
Descripción de requisitos del sofware

Sistemas Control Ingreso de muestras reportes
de ensayos y facturación
Ficha del documento
Fecha Revisión Autor Verificado dep. calidad.
12/11/2018 Manolo Pájaro Borrás
Documento validado por las partes en fecha: [Fecha]
Por el cliente Por la universidad
Advisors proambiente SAS Univesidad nacional Abierta UNAD

Sistemas Control Ingreso de muestras reportes Rev.
de ensayos y facturación Pág. 4
Contenido
FICHA DEL DOCUMENTO ........................................................................................................ 3
1 INTRODUCCIÓN .................................................................................................................. 9
1.1 Propósito ........................................................................................................................... 10
1.2 Alcance .............................................................................................................................. 10

1.2.1 Alcance del producto ...................................................................................................... 10
1.2.2 Alcance del proyecto ...................................................................................................... 10
1.2.3 Definición del alcance. ................................................................................................... 11
1.2.5. Creación de la EDT(WBS .......................................................................................... 12
1.2.6. Control del alcance ..................................................................................................... 13
1.2.7. Verificación del Alcance ............................................................................................ 13
1.3 Personal involucrado........................................................................................................ 14
1.4 Definiciones, acrónimos y abreviaturas ......................................................................... 15
1.5 Referencias ........................................................................................................................ 15
1.6 Resumen ............................................................................................................................ 15
2 DESCRIPCIÓN GENERAL ............................................................................................... 16
2.1 Perspectiva del producto ................................................................................................. 16
2.2 Funcionalidad del producto............................................................................................. 16
2.3 Características de los usuarios ........................................................................................ 16
2.4 Restricciones ..................................................................................................................... 17
2.5 Suposiciones y dependencias ........................................................................................... 17
2.6 Evolución previsible del sistema ..................................................................................... 17
3 REQUISITOS ESPECÍFICOS ........................................................................................... 17
3.1 Recopilación de Requisitos (Características y Funciones) ........................................... 17

3.2 Fronteras del proyecto ..................................................................................................... 18
3.3 Requisitos comunes de los interfaces .............................................................................. 18

3.3.1 Interfaces de usuario....................................................................................................... 19
3.3.2 Interfaces de hardware ................................................................................................... 20
3.3.3 Interfaces de software..................................................................................................... 20
3.3.4 Interfaces de comunicación ............................................................................................ 20
3.4 Requisitos funcionales ...................................................................................................... 21
Administración de procesos......................................................................................................... 26
INSUMOS DE LABORATORIO .................................................................................................. 32
3.5 Requisitos no funcionales................................................................................................. 34
REQUISITOS DEL BANCO DE DATOS LÓGICO................................................................ 36
ATRIBUTOS DEL SOFTWARE DEL SISTEMA ................................................................... 38

3.5.1 Requisitos de rendimiento .............................................................................................. 39
3.5.2 Seguridad ........................................................................................................................ 39
3.5.3 Fiabilidad ........................................................................................................................ 39
 El sistema debe tener una interfaz de uso intuitiva y sencilla ............................................ 39
 La interfaz de usuario debe ajustarse a las características de la web de la empresa, dentro
de la cual estará incorporado el sistema de gestión de procesos y incluyendo el de inventario de
insumos químicos ....................................................................................................................... 39
3.5.4 Disponibilidad ................................................................................................................ 39
3.5.5 Mantenibilidad ............................................................................................................... 39
3.5.6 Portabilidad .................................................................................................................... 40
4 GESTIÓN DEL TIEMPO ................................................................................................... 41
4.1 REQUISITOS ................................................................................................................... 41

4.1.1 Análisis de requisitos: .................................................................................................... 41
4.1.2 Requerimientos Funcionales: ......................................................................................... 41
4.1.3 Requerimientos no Funcionales: Con esta actividad se procederá a identificar ............ 42
4.1.4 Especificaciones de funcionamiento: ............................................................................. 42
4.2 DISEÑO: ........................................................................................................................... 42

4.2.1 Diseño de datos: ............................................................................................................. 42
4.2.2 Diseño Arquitectónico: .................................................................................................. 43

4.2.3 Diseño Procedimental: ................................................................................................... 43

4.2.4 Diseño interfaces: ........................................................................................................... 43
4.3 DESARROLLO ................................................................................................................ 44

4.3.1 Selección de herramientas de desarrollo: ....................................................................... 44
4.3.2 División modular: ........................................................................................................... 44
4.3.3 Codificación: .................................................................................................................. 44
4.3.4 Creación de prototipos: .................................................................................................. 44
4.3.5 Pruebas de unidad: ......................................................................................................... 44
4.3.6 Creación de manuales: ................................................................................................... 45
4.4 PRUEBAS ......................................................................................................................... 45

4.4.1 Selección de objetivos a evaluar: ................................................................................... 45
4.4.2 Pruebas generales: .......................................................................................................... 45
4.4.3 Pruebas de usuario:......................................................................................................... 45
4.4.4 Certificación técnica:...................................................................................................... 46
4.5 IMPLEMENTACIÓN Y ENTREGA ............................................................................. 46

4.5.1 Reporte de ejecución ...................................................................................................... 46
4.5.2 Pruebas preliminares ...................................................................................................... 46
4.5.3 Formación al personal .................................................................................................... 46
4.5.4 Acta de entrega ............................................................................................................... 46
4.6 ESTIMACIÓN DE LOS RECURSOS DE LAS ACTIVIDADES ............................... 48

4.6.1 GRAFICO GRANT........................................................................................................ 48
4.6.2 tabla de datos .................................................................................................................. 49
4.7 Definición de Cantidades ................................................................................................. 50

4.7.1 REQUISITOS................................................................................................................. 50
4.8 DISEÑO............................................................................................................................. 50
4.9 DESARROLLO ................................................................................................................ 50

4.9.1 Selección de herramientas de desarrollo: ....................................................................... 50
4.9.2 División modular: ........................................................................................................... 50
4.9.3 Codificación: .................................................................................................................. 50
4.9.4 Creación de prototipos: .................................................................................................. 50
1 personas, 1 portátil, Lenguaje de programación, software ...................................................... 50
4.9.5 Pruebas de unidad: ......................................................................................................... 50
2 personas, 2 portátiles, Lenguaje de programación, software .................................................. 50
4.9.6 Creación de manuales: ................................................................................................... 50
4.10 4. PRUEBAS ..................................................................................................................... 51

4.10.1 Selección de objetivos a evaluar: ............................................................................... 51

4.10.2 Pruebas generales: ...................................................................................................... 51
4.10.3 Pruebas de usuario:..................................................................................................... 51
4.10.4 4.4. Certificación técnica:........................................................................................... 51
4.11 IMPLEMENTACIÓN Y ENTREGA ............................................................................. 51
III. ESTIMACIÓN DE LA DURACIÓN DE LAS ACTIVIDADES ................................. 52
5 GESTIÓN DE LOS COSTES ............................................................................................. 55
5.1 Costos de las unidades de medida del proyecto (Puntos de función) .......................... 58
5.2 ESTIMACIÓN DE COSTES .......................................................................................... 59
6 GESTIÓN DE RIESGOS .................................................................................................... 61
6.1 La aplicación no procesa los informes en el momento debido como se esperaba ....... 62
6.1.1 Documentación sobre el uso de la aplicación ................................................................ 62
6.1.2 Tiempo de entrega subestimado: .................................................................................... 62
6.1.3 Incorrecta definición y estructuración de los datos establecidos ................................... 62
6.1.4 La estimación del tamaño puede ser muy bajo: ............................................................. 62
6.1.5 Desconocimiento de la lógica de negocio: ..................................................................... 62
6.1.6 Mantenimiento. .............................................................................................................. 62
6.1.7 Datos mal gestionados .................................................................................................... 62
6.1.8 Personal sin experiencia ................................................................................................. 62
6.2 RIESGO EN EL MANEJO DE BASES DE DATOS.................................................... 62
6.3 RIESGO DE DATOS MAL GESTIONADOS .............................................................. 62
6.4 RIESGOS EN ENTREGA DEL PROYECTO .............................................................. 63
6.5 RIESGO EN PRUEBAS .................................................................................................. 64
6.6 RIESGO DE COMPATIBILIDAD ................................................................................ 64
6.7 Planificación de Respuesta al Riesgo .............................................................................. 66
7 CONCLUSIONES ................................................................................................................ 68
8 BIBLIOGRAFÍA .................................................................................................................. 69


1 Introducción
El presente documento contiene una especificación de los requisitos del software
(SISENFA)1 n, esta especificación se ha estructurado basadas en la directrices dadas por el
modelo estándar IEEE, practica recomendada para la especificaciones de requisitos de
Software ANSI/IEEE-830.
La planificación del desarrollo de un proyecto de software es una de las tareas más

importantes, pues en esta se estimas además del alcance del proyecto, los tiempos
establecidos para su desarrollo, así como los costes estimados en la implementación de las
tareas. Al mismo tiempo se define la importante gestión del riesgo, que determina todos los
aspectos a tener en cuenta para evitar o dar solución a los inconvenientes que surjan durante
el desarrollo del proyecto.
A continuación, se desarrolla la planificación para el desarrollo del proyecto de software

Sistema de Control de Ingreso de muestras reportes de ensayos y facturación, para lo cual
cada integrante del grupo seleccionó una de las gestiones a desarrollar, así:
Manolo Pájaro, Santiago Sapuy Ramírez – Gestión del Alcance

Jaime Alexis Betancurt – Gestión del Tiempo
Edwin Martínez- Gestión del Riesgo
Cristian Alberto Gómez – Gestión de los Costes
Para dar cumplimiento a las actividades, se estimó inicialmente como fecha límite el día 16
de noviembre, fecha que fue ampliada hasta el sábado 17. En el mismo sentido, el grupo
estableció roles a fin de aportar y hacer seguimiento de manera oportuna a las actividades,
así:
Manolo Pájaro Líder Comunicador y Compilador

Edwin Martínez – Vigía del Tiempo y Revisor
Jaime Alexis Betancurt – Dinamizador del Proceso y Alertas
Cristian Alberto Gómez – Utilero y Evaluador
Santiago Sapuy Ramírez – Relator y Entregas
1
Sistemas Control Ingreso de muestras reportes de ensayos y facturación
1.1 Propósito
El propósito del presente documento es definir las especificaciones funcionales y no
funcionales para el desarrollo del sistema WEB SISENFA1 que nos permitirá gestionar le
recorrido que tendrá una muestra o una Consultoría en la empresa desde que se ingresa a
la parte de laboratorios y/o consultoría todo su proceso administrativo hasta la entrega
final al cliente, asi como
1.2 Alcance
1.2.1 Alcance del producto
El software a construir tiene como objetivo principal apoyar en la gestión del
Laboratorio en todo lo relacionado con la secuencia procesos de información que nos
permita ejercer un control sobre los métodos en la generación de informes
fisicoquímicos, hidrológicos de aguas, suelos y sedimentos microbiológicos. Se
desea automatizar fundamentalmente el proceso de muestreo y microbiológico
integrando en forma rápida la parte técnica, todo lo relacionado con los parámetros
físico-químicos, con la parte de facturación al cliente, sin que exista para ello la
duplicidad de procesos, desde el momento en la muestra o asesoría llega a la
recepción hasta su entrega final, todos estos procesos generados automáticamente,
agilizando así la comunicación con el cliente.
Esta aplicación funcionara en un entorno WEB permitiendo un control sobre la

entrada de muestras, proyectos y consultorías que la empresa facture, así como
indicadores de calidad de cada uno de los funcionarios involucrados en el proyecto,
la aplicación permitirá la consulta en línea de cada uno de los procesos que tenga el
laboratorio realizando un seguimiento de cómo va cada proceso la aplicación dará
apoyo a los siguientes procesos:
Administración
Facturación
Control de laboratorio
Generación de estadísticas.
Inventario de insumos.
1.2.2 Alcance del proyecto

SISENFA1 es un proyecto que tendrá una flexibilidad de acceso a la información en
todo lo que se relaciona con el control de ingresos, de muestras, consultorías, y
proyectos, donde se podrá tener un control de cómo va el proceso en cualquier
momento. El sistema permitirá realizar el ingreso de la muestra, consultoría o
proyecto, se podrá consultar el personal involucrado en cada en cada uno de los

proyectos, los procesos realizados, mostrará los avances que se tenga en el proceso,
hasta su facturación.
1.2.3 Definición del alcance.

Este proceso aplica a las actividades realizadas por el personal inherente al proceso de
informes técnicos, custodia de los documentos, procesamiento de estos que forman
parte del proceso
Cliente: Proceso para registrar la persona natural o jurídica que contrate los servicios
con ADVISORS PROMBIENTE SAS
Inscripción: Proceso el cliente se registra en el sistema en caso de que sea la primera
vez que requiera los servicios.
Hoja de ensayo: Proceso que se realiza mediante unos formatos diseñados en el
software, mediante el cual se muestran los resultados de los ensayos realizados a la
muestra
Consultar Información: Proceso en el que se verifica el estado de una muestra, una
consultaría o un proyecto
Cancelar trabajo: Proceso en el personal administrativo cancela un contrato.
Precio de Inscripción: Valor establecido que el cliente debe pagar para ingresar a un
seminario.
Informe técnico: proceso mediante el cual se registra el resultado referente a las
muestras de mediciones de campo, condiciones ambientales y los resultados de los
ensayos generados en los laboratorios de la empresa y/o de los laboratorios
subcontratados
ODS: Proceso que genera un código numérico consecutivo asignado para la
identificación y trazabilidad de la información y de los ítems de ensayos de los clientes
de Advisors Proambiente S.A.S

1.2.5. Creación de la EDT(WBS
Sistemas Control
Ingreso de muestras
reportes de ensayos y
facturación
1. REQUISITOS 2. DISEÑO 3. DESARROLLO 4. PRRUEBAS 5. IMPLEMENTACIÓN

Y ENTREGA
3.1
1.1 4.1 5.1
2.1 Diseño de datos Seleccion de
Análisis de Selección de Reporte de
programas de
requisitos objetivos a evaluar ejecución
desarrollo
1.2 5.2
2.2. Diseño 3.2 4.2 Pruebas
Requerimientos Pruebas
Arquitectónico Division modular generales
Funcionales preliminares
1.3 5.3
2.3. Diseño 4.3 Pruebas de
Requerimientos no 3.3. Codificación Formación al
Procedimental usuario
funcionales personal
3.4
1.4 Especificaciones 2.4. Diseño de 4.4 Certificación 5.4
de funcionamiento Interfaces Creación de técnica Acta de entrega
prototipos
3.5
Creación de
manuales

1.2.6. Control del alcance

Para la realización del control de cambios se diseñó una plantilla para con los
siguientes elementos para llevar así un control efectivo
Solicitud de cambio
Solicitante: Fecha:
Cedula:
Cambio Justificación Procesos que afecta
Recibió:
Se Entregarlo al responsable del proyecto

Aprobación de cambio:
Para la aprobación de cualquier cambio se contará con el análisis por parte de:
 Directivos o personal autorizado para el proceso
 Los encargados del proyecto
 Los desarrolladores del proyecto.
Si se considera pertinente el cambio se realizará los ajustes al proyecto para que estos
cambios sean adaptados a: EDT, cronograma y presupuesto.
Una vez ajustado el cambio se comunicará para que puedan ser realizadas las
modificaciones.
1.2.7. Verificación del Alcance

Una vez Realizado el proyecto se verificará que el mismo haya sido acorde a lo que
solicitó la empresa, para ello se verificará mediante un documento que acredite
conformidad con el proceso realizado.
VERIFICACIÓN DEL ALCANCE

Criterios a verificar cumplió No cumplió A mejorar
Se puede ingresar al sistema
Los formularios registran lo solicitado por
el cliente
El diseño de los formularios refleja lo
solicitado por el cliente
Las pruebas del sistema se desarrollaron a
cabalidad
Se cuenta con los manuales
Los manuales son claros para el usuario

Los informes son claros
Los procesos de cálculo reflejan la
1.3 Personal involucrado

Nombre Cristian Alberto Gómez
Rol Analista programador
Categoría profesional Estudiante ingeniería sistemas
Responsabilidades Análisis y diseño
Información de
cristian.gomez8@yahoo.com
contacto
Nombre Edwin Alberto Martínez

Responsabilidades Proceso de calidad y testeo
Información de
edwinmartinez787@hotmail.com
contacto
Nombre Jaime Alexis Betancurt

Responsabilidades Programación
Información de
jabetancurtl@undvirtual.edu.co
contacto
Nombre Santiago Sapuy Ramírez

Responsabilidades Programación
Información de
contacto
Nombre Manolo Pájaro Borrás

Responsabilidades Scrum Master
Información de
manolopajaroborras@gmail.com
contacto
1.4 Definiciones, acrónimos y abreviaturas
Nombre Descripción
USR Personal que usará el sistema gestionará procesos
Sistema de Información Web para la gestión de procesos
SWB Administrativos y desarrollo
ERS Especificación de Requisitos Software
RF Requerimientos Funcionales
RNF Requerimientos no funcionales
ERS Especificación Requerimientos software
1.5 Referencias
Referencia Titulo Ruta Fecha Autor
IEEE Standar IEEE 830
1.6 Resumen
Este documento consta de tres secciones. En la primera sección se realiza una introducción al
mismo y se proporciona una visión general de la especificación de recursos del sistema.
En la segunda sección del documento se realiza una descripción general del sistema, con el fin de
conocer las principales funciones que éste debe realizar, los datos asociados y los factores,
restricciones, supuestos y dependencias que afectan al desarrollo, sin entrar en excesivos detalles.
Por último, la tercera sección del documento es aquella en la que se definen detalladamente los
requisitos que debe satisfacer el sistema

2 Descripción general
2.1 Perspectiva del producto
El sistema SISENFA será un producto diseñado para trabajar en entornos WEB, lo
que permitirá su utilización de forma rápida y eficaz, además se integrará
conjuntamente al hardware que posee el laboratorio evitando con ello una doble
digitación de información
2.2 Funcionalidad del producto

La aplicación SISENFAen un CRM que integra los procesos de análisis de
muestras, consultorías ambientales en un solo bloque con el sistema de facturación
con los clientes
2.3 Características de los usuarios

Tipo de usuario Operador Nivel 3
Formación No tiene una formación Definida es la persona que
interactúa en forma directa con la aplicación en este
caso la recepcionista, los del laboratorio
Habilidades Conocimiento básico sobre navegación en paginas
Web
Actividades Alimentar el sistema y consultas especificas
.
Formación Profesional o director Área (Ingeniero Químico,
Biólogo, administrador o Contador
Web, además sobre el área específica que supervisa
Actividades Revisión y supervisión Trabajos

Formación Profesional administrador del sistema (ingeniero o
tecnólogo en computación
Web, Manejo de bases de datos, y conocimiento
profundo sobre la aplicación
Actividades Otorgamiento de permisos, mantenimiento del sistema,
Intermediario con el personal de desarrollo de la
aplicación

2.4 Restricciones
La restricciones que se deben tener en cuenta para el desarrollo de esta aplicación es a
nivel de hardware, el mismo debe tener como mínimo 4 gigas de ram, internet 10
megas, ya que el sistema operativo que tenga la maquina es indiferente, por trabajar a
nivel web las restricciones se pueden dar al trabajarlo en navegadores diferente a:
Firefox versión 4.0 o superior.
Internet Explorer versión 8.0 o superior.
Safari versión 4.1 o superior.
Google Chrome versión 9.0 o superior.
Opera versión 10.0 o superior.
Al ser desarrollado en una Versión 11 de Odoo presenta estas restricciones
2.5 Suposiciones y dependencias

Al ser desarrollado en Python como bajo ambiente web Odoo como herramienta de
desarrollo minimiza aquellos factores que pueden incidir en el sistema en si el funciona
bajo una plataforma web por consiguiente es independiente al sistema operativo que se
tenga se puede trabajar el navegadores tale como Chrome, Firefox, Opera, Explore por
esta sencilla razón la SRS/ERS2 es poco probable que cambie
2.6 Evolución previsible del sistema

El desarrollo de la aplicación se realizará bajo Odoo que es un sistema de gestión
empresarial integrado de código abierto ERP y CRM por ser un sistema modular se
puede ir actualizando a futuro, ya que el mismo es desarrollado bajo arquitectura web
al estar desarrollado en el lenguaje Python los módulos que se desarrollan no son mas
que carpetas con una estructura predefinida en XML, pudiéndose tomar módulos ya
construidos como plantilla para la creación de otros módulos que se necesiten, esto
agiliza en gran manera el tiempo de desarrollo, dando asi soluciones más rápidas.
3 Requisitos específicos
El sistema SISENFA no tendrá interconexión con otros sistemas de información, por lo
tanto, no es necesario la utilización de interfaz alguna, el mismos estará
alojado en un servidor web.
3.1 Recopilación de Requisitos (Características y Funciones)

Los requerimientos de software por parte de Advisors Proambiente SAS son los
siguientes:
2
Especificación de requerimientos de software
 Se necesita un Software que se adapte a las especificaciones de hardware

que tiene la empresa.
 Que sea Modular
 Que se adapte al software interno que tienen los equipos de laboratorio
 Que se pueda medir el grado de cumplimiento del personal que realiza las
muestra
 De manejo sencillo y que este en la web independiente del sistema
operativo.
3.2 Fronteras del proyecto

El software que se pretende implementar será CRM que integre cada uno de los
departamentos que tiene la empresa, en donde el objetivo principal radique en un
cliente satisfecho, para los cual se entregara el software montado en un servidor
web Linux, donde además de la empresa se pueda accesar desde cualquier parte
siempre y cuando la persona este autorizada y haya servicio de internet, se
realizarán seminarios de capacitación al personal autorizado, se realizaran durante
el primer año cuatro mantenimientos preventivos, cualquier cambio que tenga la
aplicación que no esté dentro de los parámetros aprobados tendrá un cobro
adicional.
Una vez terminado el proyecto se entregará un manual del Usuario en formato

digital, un software instalado en un Hosting que designe la empresa. La aplicación
Objeto en medio Magnético.
A partir del segundo año si la empresa contratante asi lo decide se realizará un

contrato de mantenimiento preventivo de cuatro visitas anuales, donde solo se
cubrirán cambios modulares que no excedan más de 10 horas de desarrollo
3.3 Requisitos comunes de los interfaces

Para el desarrollo de esta aplicación está dividido en Tres (3) grandes bloques o
entradas Recepción de muestras, facturación y clientes cada uno de ellos manejara
una interfaz diferente pero interconectadas entre si

3.3.1 Interfaces de usuario

En las dos graficas se muestra el front end de la aplicación la cual se dividió en tres módulos el
primero cuando se recibe la muestra se asigna al respectivo laboratorio esta interface asigna a la
persona responsable de procesar la muestra esta interface le envía al cliente un seguimiento de la
misma cómo va el proceso, una vez terminado el mismo pasa al bloque de facturación, una vez
terminado este proceso, pasa al modulo de registros de entregas
3.3.2 Interfaces de hardware

 Adaptadores de red
 Servidor con ram de 8 gigas
 Muse, teclado
 Monitores plasma
3.3.3 Interfaces de software

Al estar la aplicación en la web el sistema operativo puede ser Linux o
Windows.
En el aparte de restricciones se describe las interfaces de explorador
necesarias para el buen funcionamiento de la aplicación
3.3.4 Interfaces de comunicación

Los servidores, clientes y aplicaciones se comunicarán entre sí, mediante
protocolos estándares en internet, siempre que sea posible. Por ejemplo,
para transferir archivos o documentos deberán utilizarse protocolos
existentes (FTP u otros convenientes).

3.4 Requisitos funcionales

Entrada al sistema
Número de requisito RF001

Nombre de requisito Apertura a la aplicación
Descripción El sistema debe permitir ingresar por medio de la
cabecera HTTP
Tipo Requisito Restricción
Fuente del requisito Red y explorador web
Prioridad del requisito Alta/Esencial Baja/
Media/Deseado Opcional
Entradas Salida Destino Restricciones

El IP del computador
Pantalla en
en donde se El ingreso solo lo realiza el
opción de
encuentre pantallas personal autorizado para tal
registrar al
conectado o evento.
usuario
URL
El sistema debela tener un nombre por medio del cual permita su
Proceso ingreso digitándolo en la barra del navegador: http//nombre…. Todo
esto debidamente configurado en el servidor Web.
Efecto Para este sistema la dirección será: http://sisenfa.com

Colateral

Administrador de usuarios
Número de requisito RF001.1

Nombre de requisito Ingreso o supresión de roles
Descripción El sistema debe permitir el ingreso de uno o más roles y
de igual manera su supresión.
Fuente del requisito Formulario de ingreso de datos
Entradas Fuente Salida Destino Restricciones

Formulario Usuarios con
Usuarios del Cada usuario tendrá un rol
de ingreso de su rol Base de datos
sistema rol como mínimo.
datos asignado
En la administración del sistema tendrá la opción de administrar
usuarios, Una vez el usuario administrador del sistema de la opción
Proceso de guardar, el sistema pide confirmación y luego procederá a
almacenar los cambios.

Nombre de requisito Creación de usuarios
Descripción El sistema debe permitir la creación de diferentes
usuarios para asignarles permisos de acuerdo a sus tareas
Fuente del requisito Formulario ingreso de datos


Datos del usuario:
Password, Nombre,
Usuario con Los campos son
Apellidos, Base de
acceso al obligatorios y no puede
Cargo, Tipo de Usuario, datos.
sistema. haber usuarios repetidos.
Cédula, email.
El administrador del sistema tendrá una opción que le permitirá

Administrar los usuarios definiendo su tipo, le permitirá crear
usuarios. El sistema verificara que la información necesaria para crear
un usuario este completa y luego al dar la opción de guardar esta
Proceso
información, el sistema creara el usuario en la BD y lo dejara
disponible para que pueda ingresar. Antes de almacenarse la
información en la BD el sistema le presenta al usuario una pantalla
con la confirmación de los datos ingresados.

Nombre de requisito Actualización password de usuarios
Descripción El sistema debe permitir la actualización de los
passwords de los usuarios.

Confirmación Base de
Identificación y password Máximo 10 caracteres.
por pantalla datos.
Administrar los usuarios para la modificación de su password, por
medio de un formulario ya definido en el cual se solicitará el número
Proceso
de identificación y el password actual y el nuevo password. Al
confirmar la operación su nuevo password se almacenará en la base
de datos y el usuario lo verificara en su próximo ingreso.


Nombre de requisito Habilitar o deshabilitar usuarios
Descripción El sistema debe permitir habilitar o deshabilitar usuarios.

El usuario administrador del
Propiedad del
Identificación de Confirmación sistema no podrá ser
usuario
usuario por pantalla deshabilitado ya que es el
modificada
quien lo maneja.
listar los usuarios para habilitar o deshabilitarlo, enfrente de su
Proceso nombre existirá una casilla que el utilizará de acuerdo a la acción
que desea realizar. La opción de habilitar la tiene los usuarios
deshabilitados y la de deshabilitar los usuarios habilitados.

Nombre de requisito Crear un cliente
Descripción El sistema debe crear los datos necesarios para la
creación de un cliente


Nit cliente, nombre,
fecha de registro, Dir, telf, Confirmación No deben existir datos
Base de
email, rep. empresa, por pantalla repetidos en cuanto a
datos
direccion del cliente clientes.
El usuario del sistema con el pw del sistema tendrá una opción que le
permitirá Administrar los clientes, le permitirá crear cliente. El
sistema verificará que la información necesaria para crear un cliente
este completa y luego al dar la opción de guardar esta información, el
Proceso sistema creará el seminario en la BD y lo dejará disponible para que
pueda ser observado por el coordinador del seminario asignado.
Antes de almacenarse la información en la BD el sistema le presenta
al usuario una pantalla con la confirmación de los datos ingresados.

Nombre de requisito Modificar y deshabilitar cliente
Descripción El sistema debe permitir modificar y deshabilitar un
cliente
Entrada Salida Destino Restricciones

El cliente se deshabilitará
Confirmación Base de solo en el momento que sea
Nit cliente
por pantalla datos cancelado o se haya
realizado.
El administrador ingresará en la opción de administración de clientes,
en donde aparecerá un listado de los clientes creados o podrá
buscarlo a través del nit del cliente. El administrador decidirá si la
Proceso acción a seguir es deshabilitar el cliente, para el sistema solicitará
confirmación de la operación. En caso de modificar los datos del
cliente, el administrador introducirá los datos correspondientes y
grabará los cambios.

Efecto Ningún cliente cuando ha sido creado y si tuvo algún tipo de

Colateral movimiento se eliminará ya que eso ocasionaría problemas de
integridad
Administración de procesos

Nombre de requisito Asignar Código proceso
Descripción El sistema Generara Automáticamente un código de
proceso

Los datos deben
Nombre proceso, fecha Confirmación
llenarse a totalidad, el
proceso, por pantalla de Base de datos
seminario debe estar
Código Responsable asignación.
creado
El empleado que toma el proceso ingresara su código para que se le
Proceso
pueda asignar el trabajo.
Efecto Si el código no existe no se podrá realizar el trabajo con ese usuario
Colateral y se le solicitara al usuario administrador que le genere una clave

Nombre de requisito procesos
Descripción Una vez ingresado al sistema el sistema debe mostrar un
menú en donde se indique el tipo de trabajo a realizar

Los datos deben llenarse a
Proceso
Codigo proceso Base de datos totalidad, con todos la
asignado.
información que genere el
formulario para que el mismo

genere resultado
El usuario responsable una asignado su trabajo procesara toda la

Proceso información pedida por el sistema, para que en ese momento, el
proceso comience a generar resultados
Efecto Colateral El no asignar el código correcto del proceso generara resultados
erróneos

Nombre de requisito Modificar y eliminar proceso
Descripción El sistema debe permitir modificar y eliminar un
determinado proceso.

La modificación solo la realiza el
Confirmación
Cód. proceso Usuario administrador previa
del proceso Base de datos
Cód. usuario confirmación del porque se
asignado
realiza
El usuario administrador tiene la opción de eliminar y modificar
un determinado proceso. Ingresa su identificación en un
Proceso
formato diseñado y la información es verificada por el sistema.
Se debe anexar por qué se eliminó ese proceso

Nombre de requisito Modificar usuario
Descripción Se realiza para la reasignación de uno o más usuarios a
un determinado proceso


La modificación solo la
Confirmación realiza el
Código del proceso
del proceso Base de datos Usuario administrador
Código del usuario
asignado previa confirmación del
porque se realiza
Proceso El usuario administrador es el único que reasigna procesos
por lo cual se le pide la clave para poder reasignarlo


Nombre de requisito Facturación
Una vez que los diferentes procesos se han culminado se
Descripción procede a generar una factura, la misma se generara
automáticamente en forma consecutiva
Fuente del requisito Formulario de Facturación

Despliegue de
No. Factura Antes de hacer llegar la
la factura por
Nit del cliente factura al cliente se debe
pantalla Contabilidad
Fecha Factura entregar a la gerencia
mostrando los
Cód. usuario para su revisión
resultados
La coordinadora de servicios de mercadeo hace entrega al asistente
de facturación de todos los soportes. orden de servicio, que ha sido
Proceso
procesada por el sistema, soporte de autorización del cliente, una
vez verificado eso se procede a facturar
Efecto
Revisión del proceso en el cual se hayan calculado todos los costos
Colateral

Descripción Modificación o anulación de factura

Despliegue de la
Antes de hacer llegar la factura
No. Factura factura por pantalla
Contabilidad al cliente se debe entregar a la
Cod Usuario mostrando los
gerencia para su revisión
resultados
El usuario con los privilegios del sistema, procede a modificar o
Proceso
anular la factura dato el caso
Efecto
Menor posibilidad de error en el ingreso de los datos.
Colateral

Descripción Impresión de factura

Despliegue de la factura Antes de hacer llegar la factura
No. Factura
por pantalla mostrando cliente al cliente se debe entregar a la
Cod Usuario
los resultados gerencia para su revisión
El usuario con los privilegio asociados, procederá a hacer entrega de
Proceso
la factura escrita para que sea enviada al cliente
Efecto
Menor posibilidad de error en el ingreso de los datos.
Colateral

Nombre de requisito Informes técnicos
Descripción Creación de informes técnicos

Despliegue de los
Código Informe El informe debe tener el
diferentes informes Gerencia
Código Usuario(s) aval de revisión de la
generados por el Técnica
asignados al proceso gerencia técnica
software
El sistema generara un consecutivo de informe ya sea para
Proceso
trabajo de laboratorio, proyecto y consultoría


Descripción Modificación o anulación de informes técnicos
Fuente del requisito Formularios de Informes

Despliegue de los
Código Informe El informe debe tener el
diferentes informes Gerencia
Código Usuario(s) aval de revisión de la
generados por el Técnica
asignados al proceso gerencia técnica
software
El usuario con ese tipo de privilegio podrá anular el informe o
cambiar los usuario que intervienen el mismo previa orden de
Proceso
gerencia técnicas, por orden de gerencia siempre deben ser 2
como mínimo que intervengan en un proceso técnico

Descripción Elaboración de informes de ensayo
Fuente del requisito Formulario de Informes plantilla del reporte de ensayo

Código Informe Despliegue de los
El informe debe tener el
Código Usuario(s) diferentes informes Gerencia
aval de revisión de la
asignados al generados por el Técnica
gerencia técnica
proceso software
Para este proceso de elaboración del informe técnico, se debe
registrar en la planilla de informes que desplegara el sistema se
Proceso
deben tener en cuenta Mediciones de campo, tabla de resultados
diaria si así lo amerita el sistema debe generar unos gráficos
Efecto El no llevarse a cabo en forma estricta los parámetros observados el
Colateral sistema generara errores

Descripción Envío de informes en medio magnético
Fuente del requisito Formulario de Informes plantilla del reporte de ensayo

Código Informe Despliegue de archivo en
El informe debe tener el
Código Usuario(s) formato PDF, con el fin de Gerencia
aval de revisión de la
asignados al conservar los resultados y Técnica
gerencia técnica
proceso la información registrada
Para este proceso de elaboración del informe técnico, se debe
registrar en la planilla de informes que desplegara el sistema se
Proceso deben tener en cuenta Mediciones de campo, tabla de resultados
diaria si así lo amerita el sistema debe generar unos gráficos todo
esto será enviado via email al cliente en forma automática
Efecto El no llevarse a cabo en forma estricta los parámetros observados el
Colateral sistema generara errores
Insumos de laboratorio
Nombre de requisito Control de insumos
Es el proceso encargado de llevar a cabo el control de
Descripción
insumos llevados en cualquier proceso técnico de ensayo
Fuente del requisito Formulario o planilla web en donde se ejecutara el
proceso


Despliegue en formato
Cód. del usuario escrito de los elementos El informe debe tener el
Gerencia
Cód. Autorización a utilizar en dicho aval de revisión de la
Técnica
Cód. elemento proceso descontándose gerencia técnica
del inv. Del laboratorio
Una vez que el usuario autorizado digita su clave hace un
requerimiento de los insumos químicos necesario para la
Proceso
elaboración de un proceso, esto se realizara mediante una
autorización de la gerencia técnica antes de efectuar el proceso
Efecto Colateral El no llevarse este proceso en un determinado momento no se
sabrá si existe o no un insumo necesario

Nombre de requisito Control de insumos
Es el proceso encargado de llevar a cabo el control de
Descripción
insumos llevados en cualquier proceso técnico de ensayo
Fuente del requisito Formulario o planilla web en donde se ejecutara el
proceso

Cód. del usuario Informe proceso de El informe debe tener el
Gerencia
Cód. Autorización modificación del aval de revisión de la
Técnica
Cód. elemento insumo gerencia técnica
Este proceso se realiza en caso que se necesite modificar, eliminar o
Proceso agregar otro insumo

3.5 Requisitos no funcionales

Número de requisito RNF001
Nombre de requisito Cantidad de usuarios concurrentes.
El número máximo dependerá de la capacidad del
Descripción servidor. El Sistema debe soportar un número de
usuarios de acuerdo a los recursos de infraestructura
Fuente del requisito Arquitectura del sistema

Número de Si se desea incrementar los
Sistema usuarios debe revisarse la
Infraestructura usuarios
SISENFA infraestructura.
soportados
Proceso El usuario podrá las veces que sea necesario al sistema.

Efecto Si el administrador no ha planificado bien la infraestructura el
Colateral sistema en algún momento puede colapsar.

Nombre de requisito Cantidad de información almacenada
El sistema debe soportar un número de inscripciones de
Descripción
acuerdo a los recursos de infraestructura

Número de Si se desea incrementar las
Infraestructura inscripciones Sistema SISENFA inscripciones debe revisarse la
soportadas infraestructura.
El sistema permitirá realizar todas las adiciones que sea

Proceso necesaria, que ocurra los cuellos de botella

Efecto Si el administrador no ha planificado bien la infraestructura el

Colateral sistema en algún momento puede colapsar.

Nombre de requisito Base de datos
El sistema debe permitir la manipulación de la
Descripción información por medio de un motor de base de datos,
escogido por el grupo de desarrollo
Fuente del requisito Documentación

Esquema de la Ejecución de Scripts de la La carga de la aplicación de la base
base de datos consultas aplicación de datos debe estar distribuida
Las consultas que permiten la interacción de los scripts con la base
Proceso
de datos debe permitir interactuar con el motor de base de datos.

Nombre de requisito Sistema operativo
El sistema debe permitir instalar en un sistema operativo
Descripción y debe ser transparente al mismo debe funcionar el los
browser tales como mozilla, Chrome, Explorer

Características de la
arquitectura No aplica No aplica Se instalara en sistema _______
La aplicación debe ser independiente del sistema operativo

Proceso
utilizado.


Nombre de requisito Servidor Web
Descripción El sistema debe ejecutarse bajo el servidor web Linux
Fuente del requisito No Aplica

Características de la
No aplica No aplica No aplica
arquitectura
Se entregara toda la documentación necesaria para configurar el
Proceso
servidor para la aplicación.
Requisitos del Banco de Datos Lógico.

Nombre de requisito Retención de datos
Descripción El sistema debe ejecutarse bajo el servidor web Linux
Fuente del requisito No Aplica

Procesos que Base de
administren información No aplica No aplica
datos
El sistema debe tener en cuenta que información solo puede ser
Proceso
eliminada y cual es de gran importancia.
Efecto
La infraestructura debe ser capaz de soportar estos procedimientos.
Colateral


Nombre de requisito Multinivel
La arquitectura de la solución debe ser multinivel o
Descripción
multicapa
Fuente del requisito Software que soporte este proceso
Prioridad del Alta/Esencial Baja/
requisito Media/Deseado Opcional

Procesos que
administren información No aplica No aplica
Proceso Se debe desarrollar el sistema para que se trabaje en multicapa

Efecto
Colateral

Nombre de requisito Multiempresa
La solución permite la configuración unificada para
varias empresas, pero permitiendo que se maneje
independientemente la información de cada una y se
Descripción
puedan generar informes unificados de las mismas.
Además debe permitir manejar configuración particular
por cada empresa
Fuente del requisito Software SISENFA

Nit de la empresa Software
No aplica
a personalizar configurado
Proceso Permitir la configuración personalizada para cada empresa
Efecto
Colateral

Atributos del software del sistema

Nombre de requisito Disponibilidad del sistema
El sistema debe ofrecer una disponibilidad completa en
Descripción
todos sus procesos
Fuente del requisito

Arquitectura de diseño Depende de controladores
No aplica No aplica
y factores externos.
El sistema deberá estar disponible a menos que sucedan causas
Proceso externas como: perdida de fluido eléctrico y que el administrador
este actualizando la información.

Nombre de requisito Seguridad de password
El sistema debe permitir encriptar los password para
Descripción
mayor seguridad

Contraseña de un Password
Base de datos Proceso de encriptación
usuario encriptado
Al momento que se cree un usuario en el sistema el script
correspondiente encriptará la clave para almacenarla en la BD. Al
momento que un usuario requiera ser validado en el sistema, este le
Proceso presentara una pantalla de autenticación de usuario para que el usuario
ingrese su nombre y contraseña, al momento de enviar estos datos el
script encripta la contraseña ingresada por el usuario y compara estos
datos contra los de la base de datos.
Efecto Usuario que no se encuentre registrado en la base de datos no se le
Colateral permitirá el acceso.
3.5.1 Requisitos de rendimiento

Garantizar que el diseño de las consultas u otro proceso no afecte el
desempeño de la base de datos, ni afecte considerablemente el tráfico de la
red.
3.5.2 Seguridad
 Garantizar la confiabilidad, la seguridad y el desempeño del sistema
informático a los diferentes usuarios. En este sentido la información
almacenada o registros realizados podrán ser consultados y actualizados
permanente y simultáneamente, sin que se afecte el tiempo de respuesta.
 Garantizar la seguridad del sistema con respecto a la información y datos
que se manejan tales sean documentos, archivos y contraseñas.
 Facilidades y controles para permitir el acceso a la información al
personal autorizado a través de Internet, con la intención de consultar y
subir información pertinente para cada una de ellas.
3.5.3 Fiabilidad
 El sistema debe tener una interfaz de uso intuitiva y sencilla
 La interfaz de usuario debe ajustarse a las características de la web de la

empresa, dentro de la cual estará incorporado el sistema de gestión de
procesos y incluyendo el de inventario de insumos químicos
3.5.4 Disponibilidad
La disponibilidad del sistema debe ser continua con un nivel de servicio
para los usuarios de 7 días por 24 horas, garantizando un esquema
adecuado que permita la posible falla en cualquiera de sus componentes,
contar con una contingencia, generación de alarmas.
3.5.5 Mantenibilidad
 El sistema debe disponer de una documentación fácilmente actualizable
que permita realizar operaciones de mantenimiento con el menor esfuerzo
posible
 La interfaz debe estar complementada con un buen sistema de ayuda (la
administración puede recaer en personal con poca experiencia en el uso
de aplicaciones informáticas)

3.5.6 Portabilidad
Por ser una aplicación web y al ser implementada por Odoo se hace
necesario que se instale en un hosting Linux ya sea que la empresa cree uno
local o en la nube

4 GESTIÓN DEL TIEMPO

I. IDENTIFICACIÓN DE ACTIVIDADES:
Teniendo en cuenta el diagrama EDT y las actividades que se han planteado, se procede a
identificar cada una de las actividades a desarrollar, así:
4.1 REQUISITOS
En esta fase de se analizarán y describirán los requerimientos y o requisitos que el Sistema
de control de ingreso de muestras reportes de ensayos y facturación, ofrecerá para su
funcionamiento. En este proceso se identificarán tanto los requerimientos funcionales como
los no funcionales. Los primeros haciendo referencia a las interacciones entre el usuario y el
sistema, y los segundos mostrando incluso las restricciones o atributos del sistema como
tiempo de respuesta y precisión. Se da inicio con la extracción de datos al cliente y usuarios
finales del sistema haciendo uso de técnicas eficientes y seguras tales como introspección,
entrevistas de cuestionarios, entrevistas de final abierto y discusiones, etc.
4.1.1 Análisis de requisitos:

Esta actividad se plantea, luego identificar los requisitos de la aplicación, evaluar que
tan necesarios e indispensables son, así como su consistencia y completitud. Se
asegura además la viabilidad en cuanto a la parte técnica, de costes y planificación. Se
debe dialogar con el cliente a fin de aclarar las y replantear si es necesario los
requisitos a fin de dar solución a inconsistencias, limitaciones y carencias encontradas
y finalmente llegar a un mutuo acuerdo que satisfaga a todos los usuarios para así
poder realizar la priorización de requerimientos.
4.1.2 Requerimientos Funcionales:

identificados los requisitos y requerimientos, se procederá de manera más técnica a
declarar los servicios que debe proporcionar el sistema, de la manera en que éste debe
reaccionar a entradas y de cómo se debe comportar en situaciones particulares. En
esta fase se describirá lo que el sistema debe hacer, lo cual dependerá de todos los
requerimientos que se han obtenido en la fase de análisis, es decir, se describirá con
detalle la función de éste, sus entradas y salidas, excepciones, y demás características
necesarias para comprender el funcionamiento de la aplicación y poder así pasa a la
etapa de desarrollo.

4.1.3 Requerimientos no Funcionales: Con esta actividad se procederá a

identificar
aspecto y/o restricciones de los servicios o funciones ofrecidos por el sistema. Así se
incluirá restricciones de tiempo, sobre el proceso de desarrollo y estándares. Así
mismo, Los requerimientos no funcionales a menudo se aplican al sistema en su
totalidad. Normalmente apenas se aplican a características o servicios individuales
del sistema.
Además, se identificarán aspectos como fiabilidad, tiempo de respuesta y capacidad
de almacenamiento, incluyendo incluso restricciones del sistema como la capacidad
de los dispositivos de entrada/salida y las representaciones de datos que se utilizan en
las interfaces del sistema.
4.1.4 Especificaciones de funcionamiento:

Al finalizar esta etapa actividades, se tendrá un documento donde se especifican cada
uno de los requerimientos acordados, de forma clara, detallada y verificable. Cabe
aclarar que la construcción de este documento iniciará a la par con la actividad de
análisis y que durante esta fase se irá adecuando hasta poder obtener el documento
final.
4.2 DISEÑO:
Durante esta fase de determinará cómo el sistema a desarrollar cumplirá los requerimientos
identificados durante la fase de análisis.
4.2.1 Diseño de datos:

Con el documento final de la actividad 1.4 se procede a la definición de aspectos
como los tipos de datos que se requieren para lograr el funcionamiento correcto de la
aplicación. Además, se debe definir las personas o entidades que van a estar
involucradas, así como las relaciones que se pueden presentar entre estos
dependiendo el tipo de procesos u operaciones que deba cumplir la aplicación.
Esta actividad permitirá entonces definir los procesos y las características de los datos
de la aplicación, definiendo entre otras cosas los datos, la definición de tipo de estos y
los mecanismos de almacenamiento adecuados, también se definen reglas de empresa
y mecanismos de exigencia los cuales garanticen la integridad de los datos.
Esta actividad tendrá la importante tarea de definir el Modelo Entidad Relación, así
como el Diccionario de Datos. El diseño de datos incluye las subactividades de
Diseño Lógico, Modelo Entidad Relación, Diseño Físico y pruebas.

4.2.2 Diseño Arquitectónico:

En esta actividad se procederá a definir un modelo o representación técnica del
software que se va a desarrollar, identificando los principales elementos estructurales
del software y sus relaciones, obteniendo una visión global de la aplicación. Se
identificarán todos los subsistemas existentes y se establecerá un marco para el
control y la comunicación entre todos. El objetivo principal del diseño arquitectónico
es desarrollar una estructura de programa modular y representar las relaciones de
control entre los módulos.
4.2.3 Diseño Procedimental:

durante esta actividad se transformarán los elementos estructurales definidos en el paso
anterior, en una descripción procedimental del software. Esta etapa incluye el
modelado de algoritmos, diagramas de flujo, de funcionamiento interno de cada uno de
los módulos que compone el sistema, definidos en el subproceso arquitectónico y las
relaciones u operaciones que deben realizar dentro de la aplicación final. A esta fase
también la definiremos como diseño de componentes, pues se centrará en el diseño y
construcción de componentes o módulos reutilizables.
Es indispensable que se haya establecido la estructura del programa y de datos, de esta
manera se puede proceder a especifica los detalles algorítmicos del software. En el
diseño procedimental se utiliza una técnica conocida como programación estructurada,
cuya filosofía es la construcción de algoritmos y programas modulares, descendentes
(top-down) y de una entrada- una salida, lo cual facilita la legibilidad, prueba y
mantenimiento (itlalaguna.edu.mx, s.f., pág. 8).
4.2.4 Diseño interfaces:

En esta actividad se definirán cada una de las interfaces que se van a utilizar para
permitir la interacción de la aplicación con el usuario. Para esta fase es importante
definir aspectos de calidad tales como navegación, amigabilidad, colores, ayuda,
control de acceso, textos, entre otros, a fin de garantizar que el diseño de interfaz va a
cumplir con la necesidad para la cual es creado, ya que este finalmente va a ser
utilizado por el cliente como mecanismo para interactuar y operar los diferentes
componentes que vienen inmersos en la aplicación final.

4.3 DESARROLLO
Finalizada la fase de diseño, debe iniciarse la etapa de desarrollo o codificación, es decir la
ejecución de la fase en la cual se toman los diseños planteados, algoritmos, flujogramas,
casos de uso, diagramas de actividades y de secuencia, entre otros, y se llevan a un lenguaje
de programación específico.
4.3.1 Selección de herramientas de desarrollo:

En esta etapa se procede a seleccionar el software destinado a la generación de los
elementos definidos en la etapa de diseño, programación, ensamblaje, visualización,
incorporación de multimedios, almacenamiento y procesamiento, con base en las
consideraciones planteadas en el diseño lógico y físico. (García Sánchez, Vite
Chávez, Navarrate Sánchez, García Sánchez, & Torres Cosío, 2016).
4.3.2 División modular:

durante esta actividad el desarrollo de la aplicación se dividirá en componentes con
nombres y ubicaciones determinados, que se denominan módulos y que se integran
para satisfacer los requisitos del problema. Lo anterior a fin de poder dar solución
al planteamiento de forma más organizada, permitiendo el desarrollo paralelo de las
diferentes partes del sistema reduciendo la complejidad y facilitando futuros
cambios. (Godoy Giménez, 2002, pág. 19).
4.3.3 Codificación:
Con esta actividad se plasmará el diseño elaborado del sistema en el lenguaje de
codificación utilizado para desarrollarlo. Se tendrá en cuenta además un estándar de
codificación a seguir, con el fin que todos los desarrolladores lo hagan de igual
manera y hagan igual manejo de los diferentes ambientes de desarrollo utilizados.
4.3.4 Creación de prototipos:

con cada fase de codificación, se entregará un prototipo, a fin de verificar su
funcionalidad. Es importante que durante esta actividad se desarrolle también la
Revisión de la Codificación, con lo cual encontrar los defectos en el código y
corregirlos inmediatamente.
4.3.5 Pruebas de unidad:

con esta actividad será posible determinar si un módulo del programa está listo y
correctamente terminado. El objetivo de las pruebas unitarias es el aislamiento de
partes de código y demostrar que estas no contienen errores. Al final de esta
actividad todas las pruebas deben pasar como exitosas a fin de considerarse como
terminada. (Ospina Molares, 2012)

4.3.6 Creación de manuales:

en esta actividad se crearán los manuales de usuario, así como el manual técnico
con el propósito de mantenimiento futuro y ampliaciones al sistema. Las tareas de
esta etapa se inician ya en la primera fase, pero sólo finalizan una vez terminadas
las pruebas. ([Xavi], 2013).
4.4 PRUEBAS
En esta fase se realizará una verificación del comportamiento de cada uno de los módulos
que ya fue codificado, teniendo como referencia las especificaciones o comportamiento
esperado según, los requerimientos definidos en el documento de la fase de análisis,
haciendo uso de un conjunto de casos de pruebas, seleccionados de manera adecuada según
los diferentes escenarios que se pueden presentar por cada validación puntual del software
que se desee probar.
4.4.1 Selección de objetivos a evaluar:

Durante esta actividad se realiza la preparación y planificación de las pruebas a
ejecutar, se establece el entorno de pruebas, se disponen de los procedimientos y los
criterios a aplicar en las pruebas, también se selecciona la estrategia de pruebas
adecuada. La planificación de pruebas es de suma importancia ya que es la base
para los subsiguientes procesos de la misma fase, por tanto, se debe tener claro los
Tipos Pruebas, Numero de Ciclos de pruebas, Recursos Físicos, Recursos humanos,
Calendario de pruebas, Restricciones/Limitaciones, Dependencias.
4.4.2 Pruebas generales:

esta fase permitirá la aplicación de pruebas aplicadas por el grupo desarrollador, a
fin de determinar la funcionalidad, operabilidad, usabilidad y demás características
de calidad, que se pretende para la aplicación desarrollada.
4.4.3 Pruebas de usuario:

con esta actividad se harán pruebas, haciendo que los usuarios finales usen el
aplicativo. Es básico determinar en esta fase el nivel de usabilidad del sistema, pues
será el usuario quien finalmente indique que tan fácil es navegar y encontrar la
información que desea en el aplicativo.

4.4.4 Certificación técnica:

Una vez se hayan practicado las diferentes pruebas en cada uno de los módulos
diseñados, y se hayan realizado las correcciones pertinentes, se aplicará la
evaluación del modelo de calidad de software, con el fin de entregar un producto
funcional, que cumple con los requerimientos iniciales, así como las normas de
calidad en diseño de software.
4.5 IMPLEMENTACIÓN Y ENTREGA

En esta fase se realizan las diferentes actividades para poner a disposición de los
usuarios la aplicación desarrollada, se hace la preparación de la infraestructura
necesaria para configurar el entorno, la instalación de los componentes, la activación
de los procedimientos manuales y automáticos asociados, y cuando sea necesario la
migración o carga inicial de datos. Adicional a esto se debe cumplir con la
capacitación a los usuarios finales, en esta se debe garantizar la correcta puesta en
marcha, y la corrección de los errores que se lleguen presentando al momento de la
integración con el ambiente del cliente. En esta fase se entrega la última versión del
proyecto probada y aprobada; con el análisis realizado a la base documental.
4.5.1 Reporte de ejecución
4.5.2 Pruebas preliminares
4.5.3 Formación al personal
4.5.4 Acta de entrega

II. SECUENCIAMIENTO DE ACTIVIDADES

4.6 ESTIMACIÓN DE LOS RECURSOS DE LAS ACTIVIDADES

4.6.1 GRAFICO GRANT

4.6.2 tabla de datos

4.7 Definición de Cantidades

4.7.1 REQUISITOS
Análisis: 2 personas, 2 portátiles, software ofimático, papel, lapiceros
Requerimientos Funcionales: 2 personas, 2 portátiles, software ofimático, papel,
lapiceros
Requerimientos NO Funcionales: 2 personas, 2 portátiles, software ofimático,
papel, lapiceros
Especificaciones de funcionamiento: 2 personas, 2 portátiles, software
ofimático, papel
4.8 DISEÑO
Diseño de datos: 2 personas, 2 portátiles, software ofimático, motor de BD,
papel, lapiceros
Diseño Arquitectónico: 3 personas, 3 portátiles, software ofimático, papel,
lapiceros
Diseño Procedimental: 2 personas, 3 portátiles, software ofimático, papel,
lapiceros
Diseño de Interfaces: 2 personas, 3 portátiles, software ofimático, papel,
lapiceros
4.9 DESARROLLO
4.9.1 Selección de herramientas de desarrollo:
2 personas, 2 portátiles, Lenguaje de programación, software ofimático
4.9.2 División modular:
4.9.3 Codificación:
1 personas, 1 portátil, Lenguaje de programación, software ofimático
4.9.4 Creación de prototipos:
1 personas, 1 portátil, Lenguaje de programación, software ofimático
4.9.5 Pruebas de unidad:

4.9.6 Creación de manuales:

1 personas, 1 portátil, software ofimático, papel, lapiceros

4.10 4. PRUEBAS
4.10.1 Selección de objetivos a evaluar:
2 personas, 1 portátil, Lenguaje de programación, Motor BD, software ofimático
4.10.2 Pruebas generales:

4.10.3 Pruebas de usuario:

2 personas, 1 portátil, Lenguaje de programación, Motor BD, software ofimático,
papel, lapiceros
4.10.4 4.4. Certificación técnica:

4.11 IMPLEMENTACIÓN Y ENTREGA

Reporte de ejecución: 2 personas, 1 portátil, software ofimático
Pruebas preliminares: 2 personas, 1 portátil, software ofimático
Formación al personal: 2 personas, 1 portátil, software ofimático, papel, lapiceros
Acta de entrega: 2 personas, 1 portátil, software ofimático, papel, lapiceros

III. ESTIMACIÓN DE LA DURACIÓN DE LAS ACTIVIDADES
Para estimar la duración de las actividades, en mi aporte individual he hecho uso de las
experiencias de otras personas, en este caso, ingenieros de sistemas del área donde laboró, así
como la experiencia personal propia. Sin embargo, es claro que de un proyecto a otro puede
presentarse diferencia sustancial.
IV. DESARROLLO DEL CRONOGRAMA (PROJECT SCHEDULE)

a. Tabla de datos, duración y cronograma de actividades

b. Grant, duración y cronograma de actividades

Rev. 0:0
Pág. 54
V. CONTROL DEL CRONOGRAMA
Controlar el cronograma permitirá hacer seguimiento al grado de la ejecución del

proyecto y si este se está dando dentro de las fechas establecidas, es decir permite
controlar los cambios en la línea base del cronograma. Este control debe aplicarse
verificando en cada punto de control el estado actual del avance de las actividades
respecto del cronograma del proyecto, así al encontrar actividades o factores que
modifiquen o cambien el cronograma, es posible aplicar correctivos sobre estas a
fin de lograr una estabilidad del flujo y poder controlar el proceso. Posterior a ello
es necesario además que se analicen los elementos del cronograma que cambiaron,
por posibles ajustes, y determinar el impacto del estos al desarrollo del proyecto.
Es necesario entonces llevar un control integrado de cambios en el cronograma, a
fin de que, si se debe ajustar fechas, procesos, etapas, se pueda realizar un
seguimiento a dicho cambio.
Para efectuar un correcto control del cronograma se requiere:
 Plan para la Dirección del Proyecto
 Cronograma del Proyecto
 Datos sobre el desempeño del trabajo
 Calendario del Proyecto
Para medir el avance efectivo del cronograma y controlar su ejecución, podemos

hacer uso de revisiones del desempeño, midiendo, comparando y analizando las
fechas reales de inicio y finalización, así como el porcentaje de ejecución o avance
del proyecto. (CASTAÑO, s.f.)

Rev. 0:0
Pág. 55
5 GESTIÓN DE LOS COSTES

Gestionar los costes es una de las tareas más importantes del proyecto, ya que de una
buena estimación del valor del proyecto dependerá en gran parte definir si el proyecto es
realizable o no, así como conocer el nivel de rentabilidad de este, tanto para el product
owner como para el equipo de desarrollo.
Habiendo definido el EDT del proyecto y con la definición de las actividades planeadas
para el desarrollo de la aplicación, es posible entonces estimar los costes del proyecto,
para cual, se utilizará le Método Basado en Función que medirá la cantidad o valor de la
funcionalidad útil producida, durante el desarrollo de cada una de las etapas del
proyecto.
Como primer paso, es importante definir la complejidad de las tareas a desarrollar en
cada una de las fases o etapas, con lo cual, asignando un valor entre alto, medio y bajo,
se definirá en la tabla 1, los valores que dentro del proyecto se dio a cada una de las
tareas en la cuales fue dividido el proyecto.
Tablas de Complejidades
Complejidad
ACTIVIDAD
Baja Media Alta
1. REQUISITOS
1.1. Análisis X
1.2. Requerimientos Funcionales X
1.3. Requerimientos NO Funcionales X
1.4. Especificaciones de funcionamiento X
2. DISEÑO
2.1. Diseño de datos X
2.2. Diseño Arquitectónico X
2.3. Diseño Procedimental X
2.4. Diseño de Interfaces X
3. DESARROLLO
3.1. Selección de herramientas de desarrollo X
3.2. División modular X
3.3. Codificación X
3.4. Creación de prototipos X
3.5. Pruebas de unidad X
3.6. Creación de manuales X
4. PRUEBAS
4.1. Selección de objetivos a evaluar X
4.2. Pruebas generales X
4.3. Pruebas de usuario X
4.4. Certificación técnica X
5. IMPLEMENTACIÓN Y ENTREGA
5.1. Reporte de ejecución X
5.2. Pruebas preliminares X
5.3. Formación al personal X
5.4. Acta de entrega X
Tabla 1. Complejidades de las tareas del proyecto.

Rev. 0:0
Pág. 56
Definidas las complejidades, es necesario entonces asignar unos puntos para cada nivel
de complejidad, lo cual dependerá también de la complejidad de la etapa. En este orden
de ideas, las etapas de Análisis y Desarrollo podrían catalogarse como las de mayor
complejidad, puesto que en la primera se define gran parte del proyecto, y en la segunda
es donde empieza la codificación.
Teniendo en cuenta lo anterior, conociendo cada una de las etapas del proyecto, se
asignarán puntos a cada nivel de complejidad, dependiendo al mismo tiempo de la etapa
de desarrollo, así:
Complejidad
ACTIVIDAD
Baja Media Alta
1. REQUISITOS 7 10 15
2. DISEÑO 8 10 12
3. DESARROLLO 7 10 15
4. PRUEBAS 4 5 6
5. IMPLEMENTACIÓN Y ENTREGA 4 5 6
Definidos los puntos de complejidad establecidos a cada etapa, podemos entonces

calcular para cada actividad y en general para el proyecto los valores de los niveles de
complejidad establecidos.
Complejidad
ACTIVIDAD
Baja Media Alta
1. REQUISITOS
1.1. Análisis 15
1.2. Requerimientos Funcionales 15
1.3. Requerimientos NO Funcionales 15
1.4. Especificaciones de funcionamiento 10
2. DISEÑO
2.1. Diseño de datos 12
2.2. Diseño Arquitectónico 10
2.3. Diseño Procedimental 10
2.4. Diseño de Interfaces 12
3. DESARROLLO
3.1. Selección de herramientas de desarrollo 7
3.2. División modular 10
3.3. Codificación 15
3.4. Creación de prototipos 15
3.5. Pruebas de unidad 10
3.6. Creación de manuales 10
4. PRUEBAS
4.1. Selección de objetivos a evaluar 4
4.2. Pruebas generales 4
4.3. Pruebas de usuario 4
4.4. Certificación técnica 6
5.1. Reporte de ejecución 5
5.2. Pruebas preliminares 4
5.3. Formación al personal 5
5.4. Acta de entrega 4
TOTALES 27 70 10
Puntos de Función Calculados 202

Rev. 0:0
Pág. 57
Al determinar los puntos de función tenemos una medida de la magnitud del tamaño del
software y del esfuerzo que se requiere para desarrollarlo.
Conociendo entonces que se ha calculado 202 puntos de función, es necesario definir
algunas características a fin de continuar con el calculo de los costes del proyecto. En
este punto, es necesario establecer cuan productivo puede ser el equipo, midiendo la
cantidad de esfuerzo que se requiere para completar un punto de función. Para una
buena estimación se necesita tener información de proyectos pasados que tenga la
organización, o información de otras fuentes u organizaciones. Sin embargo, como no
se cuenta con datos históricos de la productividad, se iniciará con una estimación inicial
de productividad, para posteriormente, tan pronto como se vaya viendo el desarrollo de
la aplicación, ajustarla.
Para el caso, se determinará que con un equipo de trabajo compuesto por un Scrum
Master, un programador, dos analistas y un testeador, se producirá alrededor de 50
puntos de función al mes.
Para continuar, es necesario entonces establecer las jornadas de trabajo. Calculando que
cada mes tenga un total de 21 días laborales, se procede a determinar cuantas jornadas
de trabajo se necesitas para producir los 50 puntos de función en un mes.
Se requerirían entonces: 21 jornadas de Scrum Master
21 Jornadas de Programación
42 Jornadas de Análisis y Diseño
21 Jornadas de Testing
Al dividir los puntos de función entre las jornadas, se obtiene que la productividad del
equipo es:
50 PF / 21 jornadas de Scrum Master = 2,38 Puntos de Función por jornada
50 PF / 21 Jornadas de Programación = 2,38 Puntos de Función por jornada
50 PF / 42 Jornadas de Análisis y Diseño = 1,19 Puntos de Función por jornada
50 PF / 21 Jornadas de Testing = 2,38 Puntos de Función por jornada
Ahora se procede con la estimación de esfuerzo y personal necesarios en base a la

productividad. Conociendo que el desarrollo de software tiene una medición de 202
puntos de función, se puede determinar que necesitamos:
jornadas de Scrum Master: 84,84
Jornadas de Programación: 84,84
Jornadas de Análisis y Diseño: 169,68
Jornadas de Testing: 84,84
Teniendo definido el número de jornadas que requiere el proyecto de desarrollo de
software, se determina ahora los costos, con lo cual inicialmente se requiere el costo por
jornada del personal.
Según estimaciones varias, obtenidas de investigación con profesionales del área de
sistemas, consultas web, entre otros, los costos mensuales del personal para el proyecto
serán los siguientes:
Gerente de proyecto: $4.000.000
Desarrollador y Analistas: $3.500.000
Tester: 3.200.000

Rev. 0:0
Pág. 58
5.1 Costos de las unidades de medida del proyecto (Puntos de función)

Tomando los costos de personal, el costo mensual del equipo de desarrollo de
software sería de $17.700.000:
Gerente de proyectos (1 persona): $4.000.000.
Desarrollador y Analistas (3 personas): $10.500.000
Tester (1 personas): $3.200.000.
En un mes de trabajo el equipo puede desarrollar 50 puntos de función, por lo
tanto, el costo por unidad de medida es:
Costo por unidad de medida = Costo total / Nro. De unidades de medida
Costo por unidad de medida = $17.700.000 / 50 puntos de función
Será un total de $354.000 por punto de función.
Ahora conociendo el valor por punto de función y conociendo además el total de

puntos de función estimados para el proyecto, se puede entonces calcular el costo
total del proyecto:
Costo Total = Vrl por punto de función X 202 - total puntos x función.
Costo Total = $354.000 * 202
Costo Total = $71.508.000
CLASIFICACIÓN DE COSTES
Estimación de detalle
Complejidad
ACTIVIDAD
Baja Media Alta
1. REQUISITOS
1.1. Análisis 0 0 5310000
1.2. Requerimientos Funcionales 0 0 5310000
1.3. Requerimientos NO Funcionales 0 0 5310000
1.4. Especificaciones de funcionamiento 0 3540000 0
2. DISEÑO
2.1. Diseño de datos 0 0 4248000
2.2. Diseño Arquitectónico 0 3540000 0
2.3. Diseño Procedimental 0 3540000 0
2.4. Diseño de Interfaces 0 0 4248000
3. DESARROLLO
3.1. Selección de herramientas de
2478000 0 0
desarrollo
3.2. División modular 0 3540000 0
3.3. Codificación 0 0 5310000
3.4. Creación de prototipos 0 0 5310000
3.5. Pruebas de unidad 0 3540000 0
3.6. Creación de manuales 0 3540000 0
4. PRUEBAS
4.1. Selección de objetivos a evaluar 1416000 0 0
4.2. Pruebas generales 1416000 0 0
4.3. Pruebas de usuario 1416000 0 0
4.4. Certificación técnica 0 0 2124000
5.1. Reporte de ejecución 0 1770000 0
5.2. Pruebas preliminares 1416000 0 0

Rev. 0:0
Pág. 59
Complejidad
ACTIVIDAD
Baja Media Alta
5.3. Formación al personal 0 1770000 0
5.4. Acta de entrega 1416000 0 0
TOTALES 9558000 24780000 3540000
Puntos de Función Calculados 71508000
Costes directos
Salario del personal, imprevistos, papelería y suministros de oficina, asesoría
personalizada.
Costes fijos
Arriendo de la instalación, pago de servicios públicos.
Fondo de contingencia
Imprevistos.
5.2 ESTIMACIÓN DE COSTES

La estimación de costes se realizó mediante el método de detalle, realizándose
una investigación online y física de los costes aproximados de los rubros,
también teniendo en cuenta la experiencia cercana de un profesional.
RUBRO Descripción Mes 1 Mes 2 Mes 3 Mes 4 Total/gast

o por rubro
Salario de los
5
salarios desarrollador 17.700.000 17.700.000 17.700.000 18.408.000 71.508.000
es: 4'000.000
mensual
Honorarios
pagados a 1
Honorarios desarrollador
por para realizar
mantenimie 1.500.000 1.500.000 1.500.000 1.500.000 6.000.000
los 4
nto en el
1er año mantenimient
os
preventivos
Asesor en
temas
Asesoría concernientes 2.000.000 2.000.000 4.000.000
con el
software
Incluyen
computadore
papelería y s, papel,
suministros 800.000 800.000 1.600.000
lapiceros y
de oficina
demás
suministros.

Rev. 0:0
Pág. 60
Arriendo de
Arriendo las 600.000 600.000 600.000 600.000 2.400.000
instalaciones
Servicios (Agua, luz,
públicos e 200.000 200.000 200.000 200.000 800.000
telefonía)
internet
Fondos de
Imprevistos 5.000.000 5.000.000
contingencia
Total gastos 27.800.000 20.000.000 20.800.000 22.708.000 91.308.000
Total/ mes
por mes
Totalidad de gastos
91.308.000
NOVENTA Y UN MILLONES TRESCIENTOS OCHO MIL PESOS

Rev. 0:0
Pág. 61
6 GESTIÓN DE RIESGOS
Riegos se define como aquel Evento o circunstancia cuya probabilidad de ocurrencia es
incierta, pero que, en caso de aparecer, tiene un efecto (positivo o negativo) sobre los
objetivos de un proyecto.
Los riesgos conllevan cambios, elecciones y dudas. Podremos conocer o no los riesgos,
o simplemente son impredecibles.
La gestión de riesgos está directamente relacionada con las fases de análisis,

diseño, pruebas, codificación y entregas
1).
6.1
Identificación de Riesgos
1.1. Abuso de Privilegios
1.2. Capacitación
1.3. falta de presupuesto
1.4. Requerimientos incompletos:
1.5. incorporación continua de nuevos requerimientos
1.6. Modificación cronograma actividades
1.7. No hay suficientes recursos y/o ingresan demasiado tarde:
1.8. Competencia
1.9. Capacitación superficial a usuarios final

Rev. 0:0
Pág. 62
6.1 La aplicación no procesa los informes en el momento debido

como se esperaba
6.1.1 Documentación sobre el uso de la aplicación
6.1.2 Tiempo de entrega subestimado:
6.1.3 Incorrecta definición y estructuración de los datos
establecidos
6.1.4 La estimación del tamaño puede ser muy bajo:
6.1.5 Desconocimiento de la lógica de negocio:
6.1.6 Mantenimiento.
6.1.7 Datos mal gestionados
6.1.8 Personal sin experiencia
6.2 RIESGO EN EL MANEJO DE BASES DE DATOS

 Abuso de Privilegios. Los usuarios pueden llegar a abusar de los privilegios
legítimos de bases de datos para fines no autorizados, por ejemplo, sacar
información confidencial para fines personales
6.3 RIESGO DE DATOS MAL GESTIONADOS

 Datos con mala gestión: no hay entendimiento por parte del personal acerca
de los datos.
 Capacitación: es de vital importancia hacer ciclos de capacitación con el fin
de familiarizar los usuarios del sistema con el fin de evitar fallos en la
alimentación de parámetros que requiere nuestra página web
RIESGO EN LA SEGURIDAD FISICA DE LOS DATOS

 Grandes cantidades de datos almacenados: se dificultaría la
implementación del proyecto, se aumentan costos en servidores.
RIESGO ECONOMICO
 El riesgo de falta de presupuesto: Quizá este no sea un riego mayor
debido a la financiación del proyecto por parte del gobierno local o
alguna de sus secretarias debido al carácter de la información allí tratada
y de su relevancia para el municipio o ciudad.
RIESGOS DEL PROYECTO
 Requerimientos incompletos: Los Requerimientos no se definieron de manera

clara y completa.

Rev. 0:0
Pág. 63
 incorporación continua de nuevos requerimientos: El cliente no tiene claridad de

lo que desea. Necesidad nueva por por parte del mercado, del gobierno o del
negocio.
 Modificación cronograma actividades: se ingresan Actividades no contempladas

y con cierta Complejidad del desarrollo de actividades no estimadas.
 No hay suficientes recursos y/o ingresan demasiado tarde: Ingreso tardío del
personal a los roles necesitados. Personal reducido donde se necesitan mas de
los asignados.
 Competencia: un rival ofrece un proyecto de software similar con anterioridad,

generando dudas sobre nuestro proyecto a los clientes.
6.4 RIESGOS EN ENTREGA DEL PROYECTO
 Capacitación superficial a usuarios finales: Por limitación o subestimación del

tiempo se realiza una capacitación incompleta sobre el uso de la aplicación.
 La aplicación no procesa los informes en el momento debido como se esperaba:
La codificación del procedimiento de los informes es poco eficiente en el tiempo
de respuesta.
 Documentación sobre el uso de la aplicación: Generación pobre de documentos
necesarios para la instalación y uso efectivo de la aplicación.
 Mantenimiento: se necesita más dedicación después de la entrega final.
 Incertidumbre técnica: se necesita mayor conocimiento sobre el área.
 Tiempo de entrega subestimado: no se cumple el tiempo estimado para la
entrega del software al cliente en la fecha solicitada
 Personal sin experiencia: al no tener experiencia puede haber malos manejos del
software por parte del personal
RIESGO EN EL DISEÑO
 errores de programación: conllevan a una eventual caída o una pérdida de
información importante.
 Incorrecta definición y estructuración de los datos establecidos: pobre definición
de tipos de datos e integridad, y poco entendimiento sobre la relación o
dependencia de los mismos
 La estimación del tamaño puede ser muy bajo: Al realizar el diseño se

subestima el software con respecto a las necesidades del cliente.
 Desconocimiento de la lógica de negocio: Mala interpretación y/o interpretación

superficial de los requisitos para hacer el diseño detallado del sistema

Rev. 0:0
Pág. 64
6.5 RIESGO EN PRUEBAS
No se realiza completitud en las pruebas: las pruebas que se están

implementando no son lo suficiente para tener una excelente calidad del
software.
6.6 RIESGO DE COMPATIBILIDAD

 Software no compatible: no contar con el aval e ir acorde y compatible
con lo que exige la norma NTC ISO/IEC17025, PICCAP
 El software no se adapta al hardware de la empresa: Inestabilidad de la
red y/o Internet. Caída o afectación por virus de los servidores.
2) Análisis de Riesgos
Para calificar cada uno de los riesgos identificados se realiza la matriz de
probabilidad e impacto
ANALISIS CUALITATIVO DE RIESGOS MEDIANTE LA MATRIZ
PROBABILIDAD- IMPACTO
Probabilidad 0,9 0,05 0,09 0,18 0,32 0,72
0,7 0,04 0,07 0,14 0,28 0,56
0,5 0,03 0,05 0,10 0,20 0,40
0,3 0,02 0,03 0,06 0,12 0,24
0,1 0,01 0,01 0,02 0,04 0,08
IMPACTO 0,05 0,1 0,2 0,4 0,8
Muy bajo bajo medio alto Muy alto
RIESGO = PROBABILIDAD * IMPACTO

Los espacios en rojo nos arrojan un mayor riesgo que debe ser atendiendo con prioridad
Los espacios en amarillo riesgos no tan prioritarios pero que también necesitan ser
atendidos con media prioridad
Los espacios en verde nos arrojan riesgos que no son tan importantes y pueden demorar
un poco en ser atendidos
 Abuso de Privilegios: 0,28 alto
 falta de presupuesto: 0,18 medio
 Requerimientos incompletos: 0,68 muy alto
 incorporación continua de nuevos requerimientos: 0,60 alto
 Modificación cronograma actividades: 0,50 alto
 No hay suficientes recursos y/o ingresan demasiado tarde: 0,45 medio
 Competencia: 0,20 medio
 Capacitación superficial a usuarios finales: 0,56 muy alto
 La aplicación no procesa los informes en el momento debido como se esperaba:
0,65 muy alto
 Documentación sobre el uso de la aplicación: 0,40 alto
 Tiempo de entrega subestimado: 0,45 alto
Rev. 0:0
Pág. 65
 Incorrecta definición y estructuración de los datos establecidos: 0,52 alto

 La estimación del tamaño puede ser muy bajo: 0,65 muy alto
 Desconocimiento de la lógica de negocio: 0,30 medio
 El software no se adapta al hardware de la empresa: 0,6 alto
 Mantenimiento: 0,56 alto
 Datos mal gestionados: 0,54 alto
 No se realiza completitud en las pruebas: 0,6 alto
RIESGOS CATEGORIA PROBABILIDAD IMPACTO
Requerimientos incompletos PP 60% 2
Ausencia de una integración ED 45% 1
tanto funcional como
técnica
Seguridad física de los datos IO 46% 1
No se realiza completitud en ET 60% 3
las pruebas
Datos mal gestionados IO 35% 3
La estimación del tamaño TP 55% 2
puede ser muy bajo
datos mal gestionados IO 43%
El software no se adapta al T 50% 3
hardware de la empresa
Personal sin experiencia ET 40% 3
Cambios en los ED 35% 2
requerimiento requeridos,
reajustar el diseño
Capacitación superficial a ED 56% 1
usuarios finales
Falta de compatibilidad ED 55% 2
Gran cantidad de datos ED 60% 2
almacenados
Errores de programación ED 56% 3
 Grandes cantidades de datos almacenados: 0,6 alto
 Errores de programación : 0,7 alto
3) Tabla de Riesgos

Rev. 0:0
Pág. 66
6.7 Planificación de Respuesta al Riesgo
Riesgo Nivel de riesgo Respuesta al riego Plan

Falta de Alto mitigación Realizar con
compatibilidad anterior pruebas
Requerimientos Muy alto Mitigación Incorporar los
incompletos o nuevos
ambiguos requerimientos de
forma rápida ,
clara y oportuna
para que se
cumpla con el
objetivo dado
falta de presupuesto Alto Mitigación creando un
o mantenimiento administrador de
las bases de datos
y pagina web que
sea asignado por
el gobierno local
ya que garantice el
funcionamiento de
esta a través del
tiempo
Errores de alto mitigacion implementar una
programación etapa de prueba
con parámetros
aleatorios y cargas
de datos que nos
permitan auditar el
comportamiento
de nuestro sitio
web y así entregar
parámetros de
auditoria para el
gestor del sitio
que estará
encargado del
monitoreo.
Software difícil de Alto Mitigación Acompañamientos

implementar por expertos en el
tema
Tiempo de entrega Alto Aceptacion Alertar al cliente
subestimado: de las dificultades
más posibles a
suceder y las
Rev. 0:0
Pág. 67
posibilidades de
retraso
Personal sin Alto Transferencia Se contrata a una
experiencia compañía con
experiencia en la
tecnología de este
proyecto
Grandes cantidades alto Eliminación no tener grandes
de datos cantidades de
almacenados: datos almacenados
o redundantes
El software no se Alto Aceptación Tener plan alterno
adapta al hardware por si llegan a
de la empresa haber fallas en los
recursos de
software
Hacer pruebas con
anterioridad
Datos mal Alto Eliminación crear nuestros
gestionados formularios vía
internet de la
manera más
entendible y
practica ya que se
asume que los
encargados de
estas muestras no
son
necesariamente
especialistas en el
campo de la
informática
No se realiza alto eliminación Pruebas hechas
completitud en las con tiempo
pruebas estimado y con
una óptima
planeación en
cómo se
ejecutaran las
actividades

Rev. 0:0
Pág. 68
7 CONCLUSIONES
Durante el desarrollo de la planificación del proyecto de software se evidencia la
importancia que tiene esta etapa para la implementación de la aplicación, por lo cual
debe dársele la prioridad pertinente. Sin embargo, sin demeritar las demás gestiones, la
gestión del alcance junto con la gestión del tiempo, son los puntos que dan forma al
proyecto, pues delimitan y establecen las actividades a desarrollar, y con esto las
responsabilidades, así como las fechas o cronogramas de ejecución. Por lo anterior, ver
como un proyecto coge forma podría considerarse como lo mejor del desarrollo de esta
actividad.
Por el contrario, lo peor del desarrollo de la actividad está enmarcado en la cantidad de

aspectos a analizar para cada una de las gestiones. Por ejemplo, la gestión del Alcance
es una de las más complejas de desarrollar, pues debe delimitarse en todos los sentidos
el proyecto, por lo cual hay que analizar cada aspecto de la aplicación, sus límites, sus
funcionalidades, personas a cargo, entre otros, lo que en todo caso estima una gran
cantidad de análisis.
En el mismo sentido, la preparación de gestión del riesgo conlleva una responsabilidad

total, en la definición, análisis y planteamiento de la solución, para cada una de las
posibles fallas que podamos encontrar en el antes, durante y posterior al desarrollo de la
aplicación.

Rev. 0:0
Pág. 69
8 Bibliografía
[Xavi]. (2013). Las cinco etapas de ingeniería del software. Obtenido de
http://proyectosguerrilla.com/blog/2013/02/las-cinco-etapas-en-la-ingenieria-
del-software/.
830, I. (s.f.). Obtenido de
https://www.fdi.ucm.es/profesor/gmendez/docs/is0809/ieee830.pdf
García Sánchez, E., Vite Chávez, O., Navarrate Sánchez, M. Á., García Sánchez, M. Á.,
& Torres Cosío, V. (2016). Metodología para el desarrollo de software
multimedia educativo MEDESM. (v. O.-l. CPU-e. Revista de Investigación
Educativa, Editor) Obtenido de
http://www.scielo.org.mx/scielo.php?script=sci_arttext&pid=S1870-
53082016000200216.
Godoy Giménez, J. M. (2002). Diseño de Proyectos de software en código abierto.
Obtenido de ftp://ftp.inf.utfsm.cl/pub/Linux/Docs/LuCaS/Tutoriales/doc-
dise%F1o-software/doc-dise%F1o-software-parte-1.pdf.
itlalaguna.edu.mx. (s.f.). Ingenieria de Software I. EL PROCESO DE DISEÑO DEL
SOFTWARE. Obtenido de
http://www.itlalaguna.edu.mx/academico/carreras/sistemas/ingsofware1/unidad6
.pdf.
Mendez, G. (2010). IFIUcm. Obtenido de
https://www.fdi.ucm.es/profesor/gmendez/docs/is0809/03-Requisitos.pdf
Ospina Molares, C. E. (2012). ANÁLISIS, DISEÑO, DESARROLLO, PRUEBAS Y
DESPLIEGUE DE SOFTWARE, CON LOS ESTÁNDARES DE CALIDAD,
PROCESO Y TECNOLOGÍAS USADAS EN PRAGMA S.A. Obtenido de
http://repository.lasallista.edu.co/dspace/bitstream/10567/737/1/Metodologia_de
sarrollo_software_Pragma.pdf.
Ruben Rodrigues Prado Gestion de Alcance. (s.f.). Obtenido de
https://es.slideshare.net/RubenPrado1/03-gestion-del-alcance
Siscoop. (s.f.). Obtenido de
http://dspace.espoch.edu.ec/bitstream/123456789/188/1/EspecificacionRequerim
ientosSoftware.pdf
Wikipwdia. (s.f.). Obtenido de https://es.wikipedia.org/wiki/Odoo
Wikiversity.(s,f). Riesgos de proyecto de software. recuperado de
https://es.wikiversity.org/wiki/Gesti%C3%B3n_de_riesgos_de_proyectos_software
https://es.slideshare.net/lecastillox/gestion-del-riesgo

Fase 3 Trabajo Colaborativo

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fase 3 Trabajo Colaborativo

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

ASIGNATURA: INGENIERÍA DE SOFTWARE

Sistemas Control Ingreso de muestras reportes de ensayos y facturación

MANOLO PAJARO BORRAS C.C. 8.718.129

JAIME ALEXIS BETANCURT LONDOÑO C.C. 10188438

SANTIAGO SAPUY RAMIREZ C.C. 1.117.514.863

EDWIN MARTINEZ ESPINOSA CC: 15373888

CRISTIAN ALBERTO GOMEZ RODRÍGUEZ 1.117.512.168

DOCENTE: Pilar Alexandra Moreno

Descripción de requisitos del sofware

Ficha del documento

Fecha Revisión Autor Verificado dep. calidad.

12/11/2018 Manolo Pájaro Borrás

Documento validado por las partes en fecha: [Fecha]

Por el cliente Por la universidad

Advisors proambiente SAS Univesidad nacional Abierta UNAD

FICHA DEL DOCUMENTO ........................................................................................................ 3

1.1 Propósito ........................................................................................................................... 10

1.2 Alcance .............................................................................................................................. 10

1.3 Personal involucrado........................................................................................................ 14

1.4 Definiciones, acrónimos y abreviaturas ......................................................................... 15

1.5 Referencias ........................................................................................................................ 15

1.6 Resumen ............................................................................................................................ 15

2 DESCRIPCIÓN GENERAL ............................................................................................... 16

2.1 Perspectiva del producto ................................................................................................. 16

2.2 Funcionalidad del producto............................................................................................. 16

2.3 Características de los usuarios ........................................................................................ 16

2.4 Restricciones ..................................................................................................................... 17

2.5 Suposiciones y dependencias ........................................................................................... 17

2.6 Evolución previsible del sistema ..................................................................................... 17

3 REQUISITOS ESPECÍFICOS ........................................................................................... 17

3.1 Recopilación de Requisitos (Características y Funciones) ........................................... 17

3.2 Fronteras del proyecto ..................................................................................................... 18

3.3 Requisitos comunes de los interfaces .............................................................................. 18

3.4 Requisitos funcionales ...................................................................................................... 21

INSUMOS DE LABORATORIO .................................................................................................. 32

3.5 Requisitos no funcionales................................................................................................. 34

REQUISITOS DEL BANCO DE DATOS LÓGICO................................................................ 36

ATRIBUTOS DEL SOFTWARE DEL SISTEMA ................................................................... 38

4 GESTIÓN DEL TIEMPO ................................................................................................... 41

4.1 REQUISITOS ................................................................................................................... 41

4.2 DISEÑO: ........................................................................................................................... 42

Descripción de requisitos del sofware

4.2.3 Diseño Procedimental: ................................................................................................... 43

4.3 DESARROLLO ................................................................................................................ 44

4.4 PRUEBAS ......................................................................................................................... 45

4.5 IMPLEMENTACIÓN Y ENTREGA ............................................................................. 46

4.6 ESTIMACIÓN DE LOS RECURSOS DE LAS ACTIVIDADES ............................... 48

4.7 Definición de Cantidades ................................................................................................. 50

4.9 DESARROLLO ................................................................................................................ 50

4.10 4. PRUEBAS ..................................................................................................................... 51

4.10.1 Selección de objetivos a evaluar: ............................................................................... 51

4.11 IMPLEMENTACIÓN Y ENTREGA ............................................................................. 51

III. ESTIMACIÓN DE LA DURACIÓN DE LAS ACTIVIDADES ................................. 52

5 GESTIÓN DE LOS COSTES ............................................................................................. 55

5.2 ESTIMACIÓN DE COSTES .......................................................................................... 59

6 GESTIÓN DE RIESGOS .................................................................................................... 61

6.2 RIESGO EN EL MANEJO DE BASES DE DATOS.................................................... 62

6.3 RIESGO DE DATOS MAL GESTIONADOS .............................................................. 62

6.4 RIESGOS EN ENTREGA DEL PROYECTO .............................................................. 63

6.5 RIESGO EN PRUEBAS .................................................................................................. 64

6.6 RIESGO DE COMPATIBILIDAD ................................................................................ 64

6.7 Planificación de Respuesta al Riesgo .............................................................................. 66

Descripción de requisitos del sofware