Colaborativo Final

FASE 3
PLANEACION
Presentado por:
ANGELICA MARIA GARZON
RONALD ACEVEDO
CRISTHIAN RAMIREZ
CARLOS VICENTE RINCON SANCHEZ
Presentado a:
PILAR ALEXANDRA MORENO
UNIVERSIDAD ABIERTA Y A DISTANCIA – UNAD

ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA
FACULTAD DE INGENIERIA DE SISTEMAS
INGENIERIA DE SOFTWARE
NOVIEMBRE, OCTUBRE 2017
Especificación de requisitos de
software
Proyecto: Software de vigilancia para el ingreso del
personal que trabaja en las instalaciones de la
empresa Tresla
Revisión 01
TRESLA Noviembre 2017
Descripción de requisitos del sofware

Optimización de sistema de seguridad Rev. [99.99]
Especificación de requisitos de software Pág. 3
Ficha del documento
Fecha Revisión Autor Verificado dep. calidad.

Angélica María Garzón
Ronald Acevedo
Nov 2017 01 [Firma o sello]
Cristian Ramírez
Carlos Vicente Rincón Sánchez
Documento validado por las partes en fecha: Nov 2017
Por el cliente Por la empresa suministradora
Fdo. D./ Dña Gerente Tresla Fdo. D./Dña Carlos Rincon

Contenido
FICHA DEL DOCUMENTO 3
CONTENIDO 4
1 INTRODUCCIÓN 6
1.1 Propósito 6
1.2 Alcance 6
1.3 Personal involucrado 6
1.4 Definiciones, acrónimos y abreviaturas 6
1.5 Referencias 6
1.6 Resumen 6
2 DESCRIPCIÓN GENERAL 7
2.1 Perspectiva del producto 7
2.2 Funcionalidad del producto 7
2.3 Características de los usuarios 7
2.4 Restricciones 7
2.5 Suposiciones y dependencias 7
2.6 Evolución previsible del sistema 7
3 REQUISITOS ESPECÍFICOS 7
3.1 Requisitos comunes de los interfaces 8

3.1.1 Interfaces de usuario 8
3.1.2 Interfaces de hardware 8
3.1.3 Interfaces de software 8
3.1.4 Interfaces de comunicación 8
3.2 Requisitos funcionales 8

3.2.1 Requisito funcional 1 9
3.2.4 Requisito funcional n 9
3.3 Requisitos no funcionales 9

3.3.1 Requisitos de rendimiento 9
3.3.2 Seguridad 9
3.3.3 Fiabilidad 9
3.3.4 Disponibilidad 9

3.3.5 Mantenibilidad 10
3.3.6 Portabilidad 10
3.4 Otros requisitos 10
4 Apéndices 10

1 Introducción
Día a día las empresas e instituciones buscan soluciones prácticas que ayuden a tener un
control permanente en sus instalaciones, es por ello que la industria ha venido
desarrollando sistemas de control que proporciona acceso total o parcial al personal en
áreas específicas dentro de las instalaciones.
En la actualidad se ha incrementado la necesidad de elevar el nivel de seguridad de ingreso

en búsqueda de brindar tranquilidad a quienes hacen parte de una comunidad especifica;
en respuesta a dicha necesidad, el mercado ofrece diversas soluciones especializadas, con
el uso de métodos y herramientas que cumplan con los requerimientos para mejorar la
seguridad.
Últimamente se han creado distintos protocolos y estándares de conexión que dan la
posibilidad de realizar el envío y recepción de información entre dispositivos, dentro de
estos estándares de validación se encuentra el NFC, que se encarga de generar un método
de comunicación inalámbrica, de corto alcance y alta frecuencia permitiendo el intercambio
de datos entre dispositivos. También existe un avance considerable en cuanto a la
identificación por medio de huella dactilar, biométricos que cuentan con algoritmos de rápido
reconocimiento y que dan una lectura con mayor exactitud.
Hoy en día existe gran variedad de tecnologías que permiten validar información para
realizar el control de acceso, entre las cuales encontramos, tarjetas de banda magnética,
tarjetas de chip (Smart Card), tarjetas de proximidad RFID, tarjetas de proximidad NFC y
lectores biométricos, algunas con una validación más confiable y segura que otras. De
dichas tecnologías sobresalen por su confiabilidad y baja vulnerabilidad las tarjetas NFC y
dentro de los lectores biométricos el correspondiente a huella dactilar. Él desarrollo de
Software hoy en día se ha masificado tanto para profesionales o estudiantes de ingeniería
de sistemas, técnicos o tecnólogos como personas en otras disciplinas o campos, es
accesible a todos con pocos o muchos conocimientos en desarrollo, sin embargo por medio
de este trabajo veremos que no basta con saber programar para desarrollar un buen
producto y que es necesario etapas previa para saber entre otras cosas que lenguaje
utilizar, que tipo de software desarrollar y las consideraciones y requisitos y modelos a tener
en cuenta a la hora de hacer software
El desarrollo del software se planeo mediante comunicación por la plataforma de la página
de la universidad abierta y a distancia UNAD, los roles y responsabilidades se repartieron
dentro del foro colaborativo de la siguiente manera:
ACTIVIDAD CRONOGRAMA DE RESPONSABLE

TRABAJO
Lectura de los recursos 31/10/2017 a 20/11/2017 Todos
Teóricos
Carlos Rincón Gestión
del alcance
Angélica Garzón gestión

del alcance
Ronald Acevedo Gestión

Preparación y entrega de los 31/10/2017 a 20/11/2017 del tiempo
recursos individuales
Cristhian Ramírez
Gestión del Costo.
Héctor González Gestión

de riesgos
Interacción del grupo con los 31/10/2017 a 20/11/2017 Todos

trabajos individuales
Organización del documento 20/11/2017 a 22/11/2017 Carlos Rincón
final del grupo
Revisión del producto final a 22/11/2017 Todos
entregar
Preparación del producto 23/11/2017 Carlos Rincón
final con la norma
1.1 Propósito
Documentar la forma como se llevara a cabo el proyecto con los pasos a seguir durante
su desarrollo e implementación del software, se definirán alcance, tiempos de ejecución,
riesgos y responsabilidades de los encargados de la ejecución.
1.2 Alcance
Analizar, diseñar e Implementar un Sistema de Información para el control de los
equipos que se usan en las operaciones de la compañía con la información completa y
disponible para poder tener control tanto de estos, como de la programación de
mantenimiento, repuestos, ubicación y tiempo de trabajo.
El software dará la solución al problema de vigilancia dentro de la empresa Tresla,
donde se desarrollará de tal manera que el personal que trabaja dentro de la empresa
quedara registrado su ingreso y salida, además contara con un registro de tiempo que
dura el trabajador en cada una de las dependencias que se dirija, además contara con
un informe mensual de cada una de los trabajadores, partiendo de unos limites de
tiempo como de acceso a las dependencias que tiene la empresa.
1.3 Personal involucrado
Angélica María Garzón

Ronald Acevedo
Cristian Ramírez
Nombre Carlos Vicente Rincón Sánchez
Rol DESARROLLADORES DE SOFTWARE
Categoría profesional INGENIEROS DE SISTEMAS
Responsabilidades DESARROLLO Y EJECUCION DEL SOFTWARE
Información de contacto CEL 3108670529
Aprobación APROBADO GERENTE DE TRESLA
1.4 Definiciones, acrónimos y abreviaturas

Software: Conjunto de programas y rutinas que permiten a la computadora realizar
determinadas tareas.
Hardware: Conjunto de elementos físicos o materiales que constituyen una computadora
o un sistema informático.
Diseño: Actividad creativa y técnica que consiste en idear un objeto para que sea
producido en serie por medios industriales.
Cámara: Aparato que sirve para registrar imágenes estáticas o en movimiento.
Domótica: Conjunto de técnicas orientadas a automatizar una vivienda, que integran la
tecnología en los sistemas de seguridad, gestión energética, bienestar o
comunicaciones.
Sensor: Dispositivo que capta magnitudes físicas (variaciones de luz, temperatura,
sonido, etc.) u otras alteraciones de su entorno.

1.5 Referencias
Fech
Referencia Titulo Ruta a Autor
Documento Construcción https://ocw.unican.es/pluginfile 2011 Blanco,C.
y Pruebas
de Software
Libro Ingeniería de http://bibliotecavirtual.unad.edu.co:2081 2005 Weitzenfeld,
Software A.
Orientada a
Objetos con
UML
Libro Calidad de http://bibliotecavirtual.unad.edu.co:2081 2005 Weitzenfeld,
Software y A
Modelos de
Madurez del
Proceso
1.6 Resumen
En el presente documento se describen los alcances del proyecto, su implementación,
seguridad, restricciones, costos, riesgos y mejoramiento continuo.
La creación del software tiene como objetivo principal la seguridad autónoma de la
infraestructura de la empresa, control de gastos innecesarios de energía y por último el
control del personal que labora. Se realizaron unos muestreos de acuerdo al problema
hallado el cual arrojo un resultado que corresponde a los procesos de la seguridad de la
empresa, el consumo de energía y el ingreso del personal, los resultados se dieron así.
Con respecto a la seguridad se dio a conocer que ingresa cualquier persona a cualquier
área sin ser registrado de este modo no existe registro. Con relación al consumo de
energía, los empleados suelen dejar las luces, calefacción y ventanas abiertas
conllevando a un elevado gasto de energía innecesaria. Y por último el registro de
ingreso y salida del personal, el cual dicho personal no registraba la hora real de entrada
y salida de la empresa. Este proyecto constituye un ahorro monetario radicado en un
control estricto sobre el uso de cada uno de los elementos que tiene la empresa para
prestar un servicio al cliente, como una calidad de ambiente laboral.
2 Descripción general
2.1 Perspectiva del producto
Este software reunirá todos y cada uno de los problemas hallados en la investigación, lo
cual se pronostica un tiempo de creación, pero para ello se realizará un análisis y
muestreo más a fondo para forjar una relación de usuario / software. Para finalizar el
software que se desarrollara, lograra la unión de un sistema inteligente y amigable para
el usuario como para el administrador así tener una razón de comprender el uso
adecuado de la energía como de la seguridad misma sobre el trabajador.
2.2 Funcionalidad del producto

Nro. Requerimiento Descripción
La aplicación debe validar los el acceso a la aplicación debe
RF1 usuarios antes de permitir ingreso a permitir ingresar un usuario y
la configuración contraseña para su acceso

Los campos de número de teléfono

La aplicación debe permitir envió de de destino así como de correo
correos electrónicos, mensajes por electrónico deben ser modificables
WhatsApp y mensajes de texto por el usuario para asegurarse que
RF2
hacia cualquier operador de estarán correctamente digitados a
telefónica celular y cualquier su vez que la aplicación debe poder
dominio en internet ver el estado de la señal de antena
celular.
Todas las fuentes e iconos deberán
La fuente iconos y demás deben ser de un tamaño tener un tamaño
RF3 ser grandes para mejor el cual permita una fácil lectura e
accesibilidad de los usuarios identificación de la configuración y
opciones
La contraseña para hacer login debe
Las credenciales de ingreso deben ser alfanumérica mínimo 8
RF4
ser fuertes caracteres y debe incluir al menos
un carácter especial.
En la configuración se debe poder
La aplicación debe permitir separar zonas para activar o
RF5
configuración por zonas desactivar sensores de acuerdo a
las preferencias de los usuarios
La aplicación debe ser accesible

La aplicación debe permitir
desde cualquier punto en internet
activación o desactivación de la
RF6 para administrar la alarma por lo
alarma desde internet sin importar
que el servidor también deberá
la ubicación
contar con acceso a internet
A través de la aplicación se deben

poder ejecutar comandos que
Debe permitir la integración con permitan acceder a los controles de
RF7 dispositivos de domótica, como
soluciones de domótica
lámparas, persianas, y otro tipo de
sensores como proximidad,
infrarrojos, humo, etc.
El código fuente debe poderse
El código debe ser fácilmente adaptar fácilmente al desarrollo de
RF8 adaptable a cualquier instalación, cualquier solución grande o
grande o pequeña pequeña de acuerdo a las
necesidades del cliente
Los logs generados durante la

Se debe habilitar un log accesible
manipulación de la aplicación deben
por el usuario donde muestre todas
RF9 ser visualizados por el usuario con
las activaciones o desactivaciones
el fin de llevar visualmente un
de los sensores o de la alarma
registro de actividades
La aplicación debe permitir liberar

espacio del servidor o que se Se deberán poder ejecutar scripts
RF10 programe una auto limpieza con el de limpieza desde la aplicación o
fin de que siempre se tenga espacio programación de estos
libre

El servidor principal debe detectar

La aplicación debe detectar la que dejo de recibir de datos de cada
RF11 perdida de canal de datos de la cliente e informar y verificar que no
fuente. sea producto de violaciones al
sistema
Se debe informar como alarma que

el suministro de energía se ha
La aplicación debe informar de
perdido y que se está trabajando
RF12 fallos del suministro de energía,
con energía de reserva, para revisar
tiempo trascurrido del corte
si es intento de violación o un corte
habitual de luz
El sistema debe poder visualizar

El sistema debe permitir la señales de video enviadas de
RF13 integración con camas de seguridad cámaras de seguridad para poder
IP conocer si las alertas son falsos
positivos
2.3 Características de los usuarios
Tipo de usuario Común

Formación Bachiller, Técnicos, Ingenieros, auxiliares
Habilidades Manejo de aplicación celular y software del programa
Actividades Monitoreo del sistema
2.4 Restricciones
La aplicación debe tener rendimiento aceptablemente alto ya que las alarmas deben
enviarse en tiempo real y no debe haber delay entre el paso de información entre
aplicaciones.
La aplicación debe estar disponible 7/24*365 debido a que es un software crítico para el
objetivo del proyecto.
Se debe garantizar que la aplicación instalada tenga acceso a las señales generada por
los sensores.
2.5 Suposiciones y dependencias

Falla de energía: Falla de energía que afecte el funcionamiento de la UPS y que deje por
fuera el sistema.
Malware: Virus en el programa por descarga de aplicaciones.
2.6 Evolución previsible del sistema

Por los avances tecnológicos se puede mejorar el sistema de seguridad.
3 Requisitos específicos
Requisito 1 Suministrar e instalar un sistema completo de alarmas contra
robo e intrusos, incluyendo central de alarmas, detectores
volumétricos, pulsadores de alarmas, teclados, etc., es decir

todos los elementos necesarios de acuerdo con la propuesta.

Nombre de requisito Suministro de equipos
Tipo Requisito Restricción
Fuente del requisito Proveedores de equipos
Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional
Requisito 2 Suministrar e instalar un sistema completo de vigilancia por

cámaras de video, distribuidas de acuerdo con lo indicado en
planos y asociadas a un sistema de grabación de imágenes. El
mismo brindará seguridad a la totalidad del edificio principal y al
local anexo, incluyendo movimiento exterior al local, accesos a
los locales, pasillos, accesos a escaleras y ascensor, salas de
espera, y poniendo especial énfasis en espacios de atención al
público, de movimiento de valores, salas de servidores y
depósitos. Las cámaras deberán tener precisión adecuada para
identificar un rostro humano, y poder registrar con escasa
iluminación.
Nombre de requisito Instalación de cámaras
Requisito 3 La grabación será durante las 24hs. Se busca mantener la

grabación en línea por al menos 2 semanas, debiendo
especificar opciones para 1 mes o más.
Se deberá indicar si su solución puede utilizar el
almacenamiento existente en la Caja (storage array EMC
Clariion Ax4 5i); en caso que así sea, indicar el tipo de discos
y capacidad necesarios para cada caso (2 semanas, 1 mes y
más de 1 mes). En caso de no poder utilizarse, deberá preverse
el almacenamiento en el sistema escojido.
Nombre de requisito Grabacion
Requisito 4 Se suministrará el software adecuado para programación y

visualización gráfica de las alarmas, así como también la
habilitación o corte de las mismas y manejo de fallas, pruebas y
registro fiel de eventos en archivos informatizados y de fácil
lectura por un operador.
Se contará con un sistema de alarmas para detectar eventos
relevantes, como una cámara apagada.
Nombre de requisito Software
Fuente del requisito Programador
Requisito 5 Se deberá poder ver desde múltiples estaciones de trabajo

cualquier combinación de cámaras en vivo y grabaciones, por lo
menos 4 videos simultáneos en ambos casos. Se deberá incluir
como opcional licencias concurrentes de visualización si
correspondiere.
Nombre de requisito Visualización

Fuente del requisito programador

Requisito 6 Se valorará positivamente la posibilidad de contar con la

funcionalidad de repetición (“replay”) de video y permitir el
pausado de video en vivo, adelantamiento (“forward”) y
retroceso (“backward”) de videos grabados y retornar al video
en vivo..
Nombre de requisito Back up
Requisito 7 A nivel de funcionalidades, cada usuario deberá disponer de un

Login personal y seguro.
Nombre de requisito Login

en vivo..
Requisito 9 Se valorará positivamente que el operador disponga de:

 vistas flexibles
 poder realizar zoom digital y replay instantáneo
Nombre de requisito Operacion

en vivo..
Requisito 11 Se deberá poder controlar la grabación en base a eventos.

Se valorará positivamente la disponibilidad de software que
permita la búsqueda en las grabaciones de video por eventos.
Eventos deseables serán por ejemplo: movimiento, apertura de
puerta, encendido de luz, día/hora, etc.
Nombre de requisito adicionales



en vivo..
Requisito 13 En caso de requerir un servidor para el software de

administración del sistema, el mismo deberá ser cotizado en
forma opcional y en forma independiente deberán incluirse
todas las licencias de software necesarias para su
funcionamiento (incluyendo sistema operativo si
correspondiere).
Requisito 14 El servidor deberá ser, al igual que el resto del equipamiento, de

marca reconocida mundialmente, con certificado ISO9001 de
calidad y con certificado de compatibilidad con el sistema
operativo requerido.
Requisito 15 Se deberá indicar si es posible la utilización de una máquina

virtual en servidor existente en la Caja, con lo cual el costo del
servidor no será incluido en el costo total de la solución.
Requisito 16 Se deberá indicar la capacidad de crecimiento en cámaras y

tiempo de grabación. Deberá indicarse cuantas cámaras
soporta el hardware del servidor ofertado. El sistema deberá
permitir ser ampliable en el futuro con cámaras que no sean de
la misma marca de la ofertada.
Requisito 17 Recomendar para los dos edificios la ubicación de todos los

detectores y cámaras, para un mejor aprovechamiento o

cumplimiento de su función.
Requisito 18 Suministrar e instalar todo el mobiliario necesario para la

correcta instalación de las centrales de los sistemas y sus
componentes. El equipamiento será modular, de primera
calidad, diseñado de acuerdo con las necesidades físicas del
hardware a instalar.

3.1 Requisitos comunes de los interfaces
3.1.1 Interfaces de usuario
3.1.2 Interfaces de hardware
3.1.3 Interfaces de software
3.1.4 Interfaces de comunicación
3.2 Requisitos funcionales
3.2.1 Requisito funcional 1
3.2.4 Requisito funcional n
3.3 Requisitos no funcionales
3.3.1 Requisitos de rendimiento

 El sistema tendrá una respuesta de 3 segundos para enviar el mensaje se
recepción al usuario.
 La aplicación funcionara en Android y OS.
 El almacenamiento de los usuarios ingresados se basará en Windows
Server, MySql.

 Si no funciona la seguridad por envió de mensaje de texto con un grado

de efectividad del 75% se enviará una llamada al supervisor de vigilancia
con un grado de efectividad del 98%.
3.3.2 Seguridad
 Todo el personal que labora, será ingresado en la base de datos con
su huella digital.
 Él envió de los mensajes de texto estarán codificados.
 El sistema de grabación se encontrará protegido para el ingreso por
tres niveles de seguridad.
 Se almacenará todo registro del ingreso al sistema, por concepto de
actualización, verificación y supervisión del sistema
 El control de acceso implementado debe permitir asignar los perfiles
para cada uno de los roles identificados.
 El sistema deberá contar con mecanismos que permitan el registro de
actividades con identificación de los usuarios que los realizaron
3.3.3 Fiabilidad
 Reducción del 96% de fallos respecto al ingreso de los usuarios.
 El sistema no sufrirá más de dos fallos de nivel uno al mes
 Él envió de mensajes no exitosos será del 0.5% al mes
 La salida de llamadas no exitosas será del 0.2% al día
3.3.4 Disponibilidad
Estar disponible 100% durante las 24 horas de lunes a sábado, los días domingos
tendrá una interrupción de 2 horas mientras se realiza el Backup’s de los
servidores de almacenamiento de usuarios y de la grabación de las cámaras se
seguridad, como de la detección de sensores.
3.3.5 Mantenibilidad
 El sistema de seguridad debe estar en la capacidad de admitir en un
futuro el mantenimiento que al respecta sobre posibles errores en las
diferentes actualizaciones, como también por la manipulación del usuario
y administrador del software.
 El sistema contara con interfaz de administración de vigilancia,

administración de parámetros y administración de módulos, siendo así
que para cada una de estas secciones ofrezca todas las opciones de
administración disponible para cada uno.
 El software como el sistema en general contara con toda la

documentación, además cada uno de los componentes del software
estarán debidamente documentados tanto en el código fuente como en
los manuales de administración y de usuario.

3.3.6 Portabilidad
 El software se desarrollará bajo la plataforma de JAVA, por su
aceptabilidad en una gran cantidad de plataformas móviles como de
escritorio.
 El cambio de un servidor tendrá la misma disposición para uno nuevo.
 No se tendrá la restricción de un solo proveedor de partes del
hardware
3.4 Otros requisitos

 El software debe independientemente sistema operativo.
 El software debe tener una interfaz gráfica de administración y operación por
parte de los usuarios como también debe estar toda en español
 La información de los formularios que corresponda a listas de selección deberá
ser parametrizada y administrable
4 Apéndices
[Inserte aquí el texto]
Pueden contener todo tipo de información relevante para la SRS pero que, propiamente, no
forme parte de la SRS.
MÉTODO DE GESTIÓN DE RIESGOS
El método de Gestión de Riesgos fue definido con el fin de establecer las bases necesarias
para la aplicación de software, donde el objetivo es alcanzar un enfoque disciplinado y
sistemático para llevar a cabo el proceso. A medida que se van desarrollando cada una de las
fases establecidas, se recoge información de las mejores prácticas y se analiza los parámetros
necesarios y comunes para crear un marco de trabajo general, de tal forma que sea aplicable a
diferentes ámbitos.
Los tipos de riesgos que podemos encontrar en el desarrollo de software son los riesgos del
proyecto los cuales de hacerse realidad es probable que retrasen la planificacion temporal del
proyecto y que aumenten los costos. Estos riesgos identifican los problemas potenciales de
presupuesto, planificación temporal, personal, recursos, cliente y requisitos y su impacto en un
proyecto de software.
El siguiente tipo de riesgos es de los riegos técnicos los cuales amenazan la calidad y la
planificación temporal Si un riesgo técnico se convierte en realidad, la implementación puede
llegar a ser difícil o imposible. Los riesgos técnicos identifican problemas potenciales de diseño,
implementación, de interfaz, verificación y de mantenimiento. Además, las ambigüedades de
especificaciones, incertidumbre técnica, técnicas anticuadas y las nuevas tecnologías son
también factores de riesgo. Los riesgos técnicos ocurren porque el problema es más difícil de
resolver de lo que se pensaba.
El último tipo de riesgo es el riesgo del negocio los cuales amenazan la viabilidad del software
a desarrollar
El método presenta un ciclo continuo, en el que se maneja un flujo lógico de información entre
las fases que lo componen. Consta de cinco pasos fundamentales como la identificación, el
análisis, la planificación, el seguimiento y control, y la comunicación. Como mejores prácticas
se encuentra que en la fase de identificación se llevan a cabo evaluaciones de riesgos
utilizando la taxonomía y la fase de comunicación que se define como el núcleo de todo el
proceso.
No siempre funciona una categorización tan sencilla y algunos riesgos son simplemente
imposibles de predecir.

Pasos Método de Gestión de Riesgos

El objetivo es encontrar los principales riesgos antes de que
1. IDENTIFICACIÓN afecten negativamente a un proyecto, por lo tanto, debe
llevarse a cabo por medio de una técnica que permita
identificar los riesgos de forma continua la cual fue
nombrada taxonomía
Transformación de los datos de los riesgos en información para
llevar a cabo su gestión. Cada riesgo debe conocerse lo
2. ANÁLISIS suficiente como para permitir que quien los gestiona pueda tomar
decisiones sobre ellos.
Incluye acciones de manejo de los riesgos, priorizándolos y

3. PLANIFICACIÓN llevando a cabo un plan de gestión.
4. MONITOREO Monitorear es el proceso que conlleva recoger, analizar y

posteriormente divulgar los datos para los riesgos que están en
observación o mitigación.
Fase necesaria para la aplicación eficaz de un plan. Se debe

5. SEGUIMIENTO Y verificar la integración con la gestión global del proyecto
CONTROL
6. COMUNICACIÓN Se considera como un elemento indispensable para que el

proceso sea viable, debido a que facilita la interacción entre
todas las fases anteriores.
El método de identificación basado en taxonomías trabaja agrupando las distintas fuentes de

riesgos en varias categorías para realizar un proceso sistemático. Provee un marco para
organizar los datos y la información. Adicionalmente, la estructura fundamental consta de tres
niveles y sub niveles en que se detallan todos los posibles componentes implicados en el
análisis a realizar
Niveles de Taxonomía
CLASES ELEMENTOS ATRIBUTOS

Ingeniería de producto: Incluye  Especialidades  Estabilidad
los aspectos técnicos del trabajo  Requerimientos  Escala
que debe ser realizado.
Entorno de desarrollo: Involucra
los métodos, procedimientos y  Proceso de  Control de
herramientas empleadas para desarrollo producto
crear el producto  Entorno de trabajo  Formalidad
Restricciones del programa:  Externas  Calendario

Abarca los factores  Recursos  Instalaciones
contractuales, organizacionales y
operacionales.
Metodología.

Utilizaremos el Método de Gestión de Riesgos de Boehm, este método divide la gestión en dos
aspectos fundamentales, Evaluación de Riesgo y Control del Riesgo, estos a su vez se
subdividen en pasos que se valen de un conjunto de técnicas para llevarse adelante.
Puede ser utilizado en todas las fases del desarrollo de software. Este método produce buenos
resultados si se cuenta con un gestor con experiencia capaz de manejar los factores de éxito
relacionados con personas y tecnología involucradas en proyectos de software. Es
relativamente simple.
La desventaja es que no maneja de forma explícita los riesgos genéricos.
Evaluación Identificación de Riesgos Listas de Verificación

del Riesgo Análisis de Conductores de
Decisiones
Análisis de Supuestos
Descomposición
Tormenta de Ideas
Análisis de Análisis de Decisiones
Riesgos Análisis de Red
Modelos de Costo
Análisis de Factores de
Calidad
Análisis de Desempeño
Priorización Exposición al Riesgo
del Riesgo Análisis de la Reducción del
Riesgo
Reducción del Riesgo
Compuesto
Control del Planificación Comprar Información
Riesgo de la Gestión Evitar el Riesgo
de Riesgos Transferir el Riesgo
Reducir el Riesgo
Planificar los elementos de
Riesgo
Integración de la Planificación
de Riesgos
Resolución Prototipos
del Riesgo Simulaciones
Evaluación comparativa
(Benchmarking)
Análisis
Reclutar Personal
Monitoreo del Seguimiento de hitos
Riesgo Seguimiento de los 10 mas
importantes
Reevaluación del Riesgo
Acciones Correctivas
Riesgo/Técnica
Riesgo Técnica
Déficit de personal Contratar los mejores talentos; Trabajo en equipo;
Construcción de moral; Entrenamiento cruzado; Planificar
con antelación recursos claves
Calendario y presupuesto Estimación detallada de calendario y costos realizada por
irreales varias fuentes; Diseño para el costo; Desarrollo incremental;
Reutilización de software; Limpieza de requerimientos
Desarrollo de las funciones de Análisis de la organización; Análisis de la misión; Encuestas

software incorrectas a usuarios; Hacer prototipos; Manuales de usuario temprano

Desarrollo de la interfaz de Prototipado; Escenarios; Análisis de tareas
usuario incorrecta
Depuración de los Limpieza de requerimientos; Prototipado; Análisis costo-
requerimientos beneficio; Diseño para el costo
Flujo continuo de cambios en Gran umbral a cambios; Ocultamiento de la información;
los Desarrollo incremental (diferir los cambios a incrementos
requerimientos posteriores)
Déficit en tareas realizadas por Verificación de referencias; Auditorias de adjudicación
terceros previa; Contactos de adjudicación de honorarios; Diseño
competitivo o
prototipado; Trabajo en equipo
Déficit en componentes de Evaluación comparativa; Inspecciones; Verificación de
terceros referencias; Análisis de compatibilidad
Déficit en desempeño en tiempo Simulación; Evaluación comparativa; Modelado; Prototipado;
real Instrumentación; Puesta a punto
Forzar las capacidades de la Análisis técnico; Análisis costo-beneficio; Prototipado;
informática Verificación de referencias
Revisión de las metas

La plantilla propuesta por el método es la siguiente:
Atributo de la Meta: Descripción
Nombre Nombre de la meta.
Tipo Objetivo / Conductor / Restricción.
Descripción Descripción de la meta.
Parte Interesada Nombre de los interesados en la meta.
Unidad de Medida Unidad de la medida utilizada para medir le meta.
Valor Buscado Valor buscado para la meta. Relevante para objetivos y
posiblemente para restricciones también.
Dirección de incremento de la Definición si un incremento o decremento del valor de la
utilidad meta aumenta la utilidad, es decir, si un incremento es
bueno o malo para la meta.
Rango de Valores requeridos Valor mínimo y máximo para la meta, si aplica.
PLANIFICACIÓN DE LA GESTIÓN DE RIESGOS
Los riesgos se reflejan desde el inicio del proyecto, por esta razón se debe realizar la gestión
en el grupo de procesos de planificación del proyecto. De igual forma esta gestión debe ser
aplicada a cada una de las fases del desarrollo de software, lo cual permitirá garantizar la
disminución de riesgos presentes en estas, evitando sobre costos y demoras en el proyecto.

Categorías de riesgos de software
- 1. Riesgos del proyecto: Amenazan al plan del proyecto; la planificación temporal y

los costos. Ej.: Pérdida de un desarrollador experimentado.
- 2. Riesgos del producto: Amenazan la calidad y la planificación temporal del

software; la implementación puede llegar a ser difícil o imposible. Ej.: Rendimiento de
un componente menor al esperado
- 3. Riesgos del negocio: Amenazan la viabilidad del software a construir. Ej.: la

competencia introduzca un nuevo producto.
Para la gestión de riesgos del proyecto de desarrollo de software de vamos a utilizar la

metodología con los procesos de identificación y análisis de riesgos del proyecto plasmada en
la siguiente tabla:
La idea del proceso de gestión de riesgos es la de desarrollar una estrategia global para
gestionar riesgos en el proyecto, decidir cómo se ejecutarán los procesos implicados, e
integrarse a las actividades de la administración del proyecto. Para cumplir con esta premisa se
requiere de un plan, en el que se describa de qué manera se llevarán a cabo los procesos y
cómo se relacionarán con otros.

IDENTIFICACION Y ANALISIS DE RIESGOS DEL PROYECTO

ALTERNATIVAS DE
MITIGACION
RIESGO PROBA
TIPO DE ETAP ACCIONE ACCIONE RESPONSA IMPACT
(Descripción BILIDA
RIESGO A S S BLE O
) D
CORRECT PREVENTI
IVAS VAS
1. Desde el
principio,
1. Se debe
más de
tener
dos
establecid
personas
o un
involucrad
mecanism
as en el
o que
proyecto
asegure
deben de
Cambio de que
compartir
personal: cuando un
sus
alguno de los funcionario
conocimien
desarrollador se va
PERSON tos con Gerencia del
es con más Todas queda Alto Media
AL respecto al proyecto
experiencia dentro de
proyecto
renuncia, o el sus
2. para
director del responsabi
cada
proyecto lidades
actividad
hacer
siempre
transferen
deben de
cia de
estar como
conocimie
responsabl
nto de lo
es un
que ha
mínimo de
aprendido
2
en CNT.
personas.
El personal 1. cambio
1.
asignado al o apoyo de
contratar
proyecto es personal
personal
nuevo o no que si
con perfil
PERSON tiene tenga el Gerencia del
Todas adecuado Medio medio
AL conocimiento conocimie proyecto
para el
en el área de nto. 2.
desarrollo
desarrollo capacitaci
del
(perfil ones
proyecto.
inadecuado). continuas
1. Realizar
el
Replantear
cronogram
las fechas de los
a con
entregas de tiempos de Gerencia del
TIEMPO Todas fechas Alto baja
los avances entrega de proyecto
posibles y
es corta los
con los
avances
tiempos
dados.

no se cuenta
con las
máquinas y de ser
servidores necesario Validar la
para tener actualizarl plataforma,
PLATAFO Gerencia del
todos los Todas a para no administrar Alto baja
RMA proyecto
programas detener el la de forma
necesarios proceso de adecuada
para el desarrollo
desarrollo del
sistema.
Adquirir Verificació
disponibilidad
herramient n de
y calidad de
as licencias
las
necesarias necesarias
PLATAFO herramientas Gerencia del
Todas para la para la Alta Baja
RMA que se van a proyecto
ejecución gestion y
emplear en la
del realización
construcción
proyecto del
del producto.
proyecto
Replantear
complejidad Cambio de el proyecto
Planeació desar Director de
del sistema a plan de cada vez media Baja
n rollo planeación
construir proyecto que se
requiera
Replantear Validar el
Dinero para
presupuest presupuest
ECONO la Gerencia del
todas o y o, Alta media
MICOS culminación proyecto
necesidad seguimient
del proyecto
es os
IDENTIFICACIÓN DE RIESGO

La idea de la identificación de riesgos es la de detectar la mayor cantidad posible de éstos y de

manera iterativa dado que siempre existe la posibilidad de riesgos no detectados o emergentes.
El nivel de exposición varía en el tiempo como resultado de decisiones y acciones tomadas
previamente en el proyecto y cambios externos impuestos, es por esto que se plantean varias
técnicas que ayudan al desarrollo de este paso y brindan una perspectiva de detalle según lo
requiera el proyecto
ANÁLISIS CUALITATIVO DE RIESGO
Análisis Cualitativo de Riesgos es normalmente una forma rápida y rentable de establecer

prioridades para la Planificación de la Respuesta, y calcula y evalúa las características
individuales de lo identificado, prioriza en función de los ítems acordados. Como tal no trata el
proyecto global en los objetivos que puedan ocasionar efectos combinados y sus posibles
interacciones. Para el desarrollo de este análisis existen las siguientes técnicas y herramientas,
que soportan toda caracterización:
ANÁLISIS CUANTITATIVO DE RIESGOS
El análisis cuantitativo determina el efecto de los riesgos y les asigna una calificación numérica
ayudando a estudiar la probabilidad de ocurrencia y sus consecuencias en los objetivos del
proyecto, así como magnitud del riesgo total, lo que brinda la opción de adoptar sus técnicas
según la disposición de la organización.
PLANIFICACIÓN DE LA RESPUESTA A LOS RIESGOS
La Planificación de la Respuesta a los Riesgos es el proceso de desarrollar opciones y

determinar acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del
proyecto. Estas deben ser congruentes con la importancia, ser aplicadas a su debido tiempo,
ser realistas dentro del contexto del proyecto y a cargo de una persona responsable. También

es conocido como un documento de registros donde se detallan todas las variables de

importancia en el análisis:
 Todos los riesgos identificados, sus descripciones, causas, áreas afectadas.

Responsables del riesgo y responsabilidades asignadas.
 Resultados de los procesos de análisis cualitativo o cuantitativo del riesgo.
 Respuestas acordadas para cada riesgo: evitar, transferir, mitigar, optimizar o
aceptar.
 Planes de contingencia y planes de reserva.
SEGUIMIENTO Y CONTROL DE RIESGOS
Durante la ejecución del proyecto, se debe monitorear constantemente el ambiente en caso de

que alguna de las variables definidas en los procesos anteriores se presente. Es posible que en
el desarrollo del proyecto surjan nuevos riesgos u oportunidades que no estaban presentes al
principio del mismo, y otros pueden tienden a desaparecer por su poca probabilidad de
ocurrencia por lo que es necesaria una continua labor de gestión periódica, haciendo de esta
actividad un ciclo que soporta los demás procesos.
GESTIÓN DE COSTOS
Los costos en Contabilidad, son una inversión que se realiza en trabajo o dinero para obtener el
objetivo empresarial, de esta forma vamos a calcular el costo de nuestro producto en función
de la inversión que realizaremos para obtener el producto que deseamos desarrollar.
Para esto vamos a diferenciar los valores de acuerdo a su categoría en la clasificación de

costos.
Inicialmente calcularemos la totalidad del proyecto de software para posteriormente describir

los elementos del costo dentro del proyecto y analizar el precio de venta con un % de utilidad y
un margen de rentabilidad mostrándonos cuál debe ser nuestro objetivo de ventas.
Clasificación de los costes
Definiciones
Costos Directos:
Mano de obra directa

Materiales o materia prima
Comisión al área de ventas
Transporte desde el lugar de distribución o venta al consumidor.
Costos indirectos
Son los costos comunes a muchos productos o servicios y por lo tanto no son directamente
identificables con ninguno de los bienes ofrecidos por la empresa. Los costos indirectos se
cargan por lo general a los artículos o áreas utilizando técnicas de asignación o absorción,
dependiendo de la participación en ventas.
Servicios públicos
Nomina
Costos de insumos genéricos como cables
Costo variable
Son aquellos donde la inversión cambia directamente con el volumen de producción pero que
su valor unitario permanece constante.

Costos Fijos
Son las inversiones que se realizan y permanecen constantes sin importar la cantidad de
productos o servicios que la empresa comercialice en un periodo determinado.
Datos de la empresa:
Resumen de la materia prima y mano de obra 2 de los elementos del costo que se necesita
para el proyecto donde se ha determinado una hora de desarrollo para la aplicación móvil y el
servidor, este tiempo está basado en el costeo por hora de producción una vez se haya
desarrollado el software y esto corresponde a la instalación y configuración de las aplicaciones
y no al desarrollo de la aplicación.

Por cada unidad realizada y desarrollada el costo variable por unidad es de 950.400
Relación de la Materia Prima con su valor y número de unidades para hallar el costo variable.
Valor del presupuesto 738.333
Presupuesto de costos indirectos de fabricación

Determinación del precio de venta de acuerdo a la obtención del punto de equilibrio lo que nos
da que con una venta de 50 unidades y una participación en ventas del 3% nuestro precio de
venta deberá ser de 255.843.
Determinación del precio de venta por el sistema de costos por absorción lo que nos da que por
cada unidad y una utilidad operacional deseada del 35% y una participación en ventas del
producto del 25% nuestro precio de venta deberá ser de 735.835

Este precio nos pone en una desventaja competitiva con otras empresas del sector al tener un
precio elevado por unidad de producto por lo que nuestra proyección de ventas con el mismo
margen de utilidad teniendo una reducción en el valor de venta con una proporción competitiva
frente a la competencia nos muestra que debemos aumentar nuestro volumen de ventas con
datos de 50 unidades a vender ya nuestro precio de venta nos baja a 457.541 precio más
competitivo en el mercado.
Determinación del Precio de Venta Sistema Margen de contribución

Con un margen de utilidad deseado del 35% podemos ver como el margen de contribución es
del 65% con un costo variable igual al margen de utilidad y un valor de venta sugerido de
392.923, valor que aunque está por encima de la estimación de 200.000 pesos que
seleccionamos como precio de venta deseable nos da un precio sugerido, competitivo con el
valor de venta de la competencia y precio razonable con los encontrados en el mercado de
sistemas similares.
Estimación del Coste por el método COCOMO básico
Calcularemos el esfuerzo y el costo del desarrollo en función del tamaño del programa
estimado en LOC. Se utiliza para un proyecto pequeño y relativamente sencillo.
Ecuaciones del modelo COCOMO básico:
Dónde:
Los coeficientes a y c y los exponentes b y d se obtienen de la siguiente tabla:
Pequeño grupo de programadores experimentados desarrollan software en un

Orgánico entorno familiar. El tamaño del software varía desde unos pocos miles de
líneas (tamaño pequeño) a unas decenas de miles (medio).
corresponde a un esquema intermedio entre el orgánico y el rígido; el grupo
Semiaclopado de desarrollo puede incluir una mezcla de personas experimentadas y no
experimentadas

el proyecto tiene fuertes restricciones, que pueden estar relacionadas con la

Empotrado funcionalidad y/o pueden ser técnicas. El problema a resolver es único y es
difícil basarse en la experiencia, puesto que puede no haberla.
Aplicando el modelo COCOMO básico y usando un tipo de proyecto orgánico obtenemos una
estimación para el esfuerzo:
E = 2.4*KLOC
Para calcular la duración del proyecto usamos la estimación de esfuerzo:
El valor de la duración del proyecto permite al planificador recomendar un

número de personas N para el proyecto.
El planificador puede decidir emplear sólo una o dos personas y ampliar por
tanto la duración del proyecto.
Definimos la complejidad del proyecto de acuerdo a la siguiente tabla:
Identificamos la complejidad del proyecto de acuerdo a su factor de ponderación de

complejidad

0 = Sin influencia
1 = Incidental
2 = Moderado
3 = Promedio
4 = Significativo
5 = Esencial
Los puntos de función es: 45.98
Encontraremos LOC (Líneas de código) eligiendo el lenguaje de programación que usaremos

en el proyecto
LOC: 1379.40

N = E/D
N= 3.36/3.96
N = 0.84
Para el proyecto necesitaremos el esfuerzo de 3.36 hombres por mes con una duración de 3.96
meses y un total de 1379.40 líneas de código de acuerdo al análisis realizado por este método,
sugiriendo un total de un desarrollador.
Resumen
E 3,36 Hombres por mes se requieren para el proyecto

D 3,96 meses requeridos para el desarrollo del software
N 1 programador necesario para llevar a cabo el desarrollo de la aplicación
KLOC 1379,4 líneas de código necesarias para terminar la aplicación
Clasificación de los costes
Definiciones
Costos Directos:
Mano de obra directa

Materiales o materia prima
Comisión al área de ventas
Transporte desde el lugar de distribución o venta al consumidor.
Costos indirectos
Son los costos comunes a muchos productos o servicios y por lo tanto no son directamente
identificables con ninguno de los bienes ofrecidos por la empresa. Los costos indirectos se
cargan por lo general a los artículos o áreas utilizando técnicas de asignación o absorción,
dependiendo de la participación en ventas.
Servicios públicos
Nomina
Costos de insumos genéricos como cables

Costo variable
Son aquellos donde la inversión cambia directamente con el volumen de producción pero que
su valor unitario permanece constante.
Costos Fijos
Son las inversiones que se realizan y permanecen constantes sin importar la cantidad de
productos o servicios que la empresa comercialice en un periodo determinado.
Datos de la empresa:
Resumen de la materia prima y mano de obra 2 de los elementos del costo que se necesita
para el proyecto donde se ha determinado una hora de desarrollo para la aplicación móvil y el
servidor, este tiempo está basado en el costeo por hora de producción una vez se haya
desarrollado el software y esto corresponde a la instalación y configuración de las aplicaciones
y no al desarrollo de la aplicación.

Por cada unidad realizada y desarrollada el costo variable por unidad es de 950.400
Relación de la Materia Prima con su valor y número de unidades para hallar el costo variable.
Valor del presupuesto 738.333
Presupuesto de costos indirectos de fabricación
Determinación del precio de venta de acuerdo a la obtención del punto de equilibrio lo que nos
da que con una venta de 50 unidades y una participación en ventas del 3% nuestro precio de
venta deberá ser de 255.843.

Determinación del precio de venta por el sistema de costos por absorción lo que nos da que por
cada unidad y una utilidad operacional deseada del 35% y una participación en ventas del
producto del 25% nuestro precio de venta deberá ser de 735.835

Este precio nos pone en una desventaja competitiva con otras empresas del sector al tener un
precio elevado por unidad de producto por lo que nuestra proyección de ventas con el mismo
margen de utilidad teniendo una reducción en el valor de venta con una proporción competitiva
frente a la competencia nos muestra que debemos aumentar nuestro volumen de ventas con
datos de 50 unidades a vender ya nuestro precio de venta nos baja a 457.541 precio más
competitivo en el mercado.
Determinación del Precio de Venta Sistema Margen de contribución
Con un margen de utilidad deseado del 35% podemos ver como el margen de contribución es
del 65% con un costo variable igual al margen de utilidad y un valor de venta sugerido de
392.923, valor que aunque está por encima de la estimación de 200.000 pesos que
seleccionamos como precio de venta deseable nos da un precio sugerido, competitivo con el
valor de venta de la competencia y precio razonable con los encontrados en el mercado de
sistemas similares.

5 GESTION DEL TIEMPO

5.1 IDENTIFICACION DE ACTIVIDADES
5.1.1 Fase de Inicio

1. Análisis de requisitos
2. Recolección de información
a. Entrevistas
b. Cuestionarios
c. Encuesta
d. Observación
3. Requerimientos del software
5.1.2 Fase de Elaboración

4. Diseño del sistema
a. Modelación del trabajo
b. Estructuración de datos
c. Diseño arquitectónico
d. Diseño interfaz
5.1.3 Fase de Construcción

5. Desarrollo del software
a. Codificación del sistema
6. Montaje y pruebas del software
a. Prueba 1
b. Prueba 2
c. Prueba 3
7. Documentación
a. Elaboración manual técnico
b. Elaboración manual del usuario
5.1.4 Fase de transición (1 Semana)

 Entrega del software
 Entrega de documentación
 Exposición del software
SECUENCIAMENTO DE ACTIVIDADES

ESTIMACIÓN DE RECURSOS DE LAS ACTIVIDADES
5.1.5 Recursos Humanos

 Ingeniero se software (Ronald Acevedo)
 Diseñador de software (Angélica Garzón, Carlos Rincón)
 Programador (Mauricio Ramírez)
5.1.6 Software
 Windows Server
 Lenguaje de programación JAVA
 MySQL
5.1.7 Equipos
 2 equipos de cómputo con procesador Intel Core i7, memoria RAM de 8 GB, tarjeta
aceleradora de video de 2 GB y 2 discos duros de 1 TB.

 1 impresora lasser de alto función
 1 scanner de hoja continua
5.1.8 Materiales y suministros

 Papelería
 Útiles de oficina
5.2 ESTIMACION DE DURACION DE LAS ACTIVIDADES

 Fase de Inicio: 2 semanas
 Fase de Elaboración: 4 Semanas

 Fase de Construcción: 7 Semanas

 Fase de Transición: 1 Semana
Para un total de estimación de este proyecto de 3 meses
5.3 DESARROLLO DEL CRONOGRAMA
5.4 CONTROL DEL CRONOGRAMA

CONCLUCIONES

 La presentación de proyectos por parte de cualquier grupo requiere la unificación de

esfuerzos y un grado de compromiso por parte de los integrantes para desarrollar lo
propuesto en los tiempos acordados y de la calidad exigida sin embargo uno de los
aspectos más difíciles a superar siguió siendo la integración, coordinación del grupo
y la concentración de esfuerzos para desarrollar el proyecto en los plazos
acordados, además de poder entregar un producto de acuerdo a la calidad
esperada.
 Otro aspecto significativo que debido a la no participación de todos los integrantes
quedaron por fuera temas fundamentales del proyecto y que si fuera el caso de una
propuesta real no la podríamos haber cumplido al 100% en el tiempo exigido.
 Lo más difícil en la parte de planificación es el no conocer específicamente la
empresa, se eligió el proyecto propuesto por un compañero, pero la
retroalimentación de los requerimientos específicos y alcance dificultan el correcto
desarrollo de la actividad
 La interacción dentro del grupo es muy poca y no es concreta al desarrollo del
proyecto.
 Los aportes del grupo no fueron entregados a tiempo para su correcto análisis y
desarrollo del proyecto.

BIBLIOGRAFIA
 Blanco, C. & García, F. Carlos. (2015). Gestión de Proyectos Software - Fundamentos.

 Hernández, J. (2011). FundamentosdeGestióndeProyectos.
 Blanco, C. (2011). Alcance de proyectos de software.
 Blanco, C. (2011). Gestión del Tiempo.
 Sánchez, P. (2011). Gestión de Costes en Ingeniería de Sistemas Software.
 Sánchez, P. (2011). Gestión de Riesgos en Proyectos Software.
 https://es.wikipedia.org/wiki/COCOMO
 http://groups.engin.umd.umich.edu/CIS/course.des/cis525/js/f00/gamel/cocomo.html
 Fuentes, I. I. (s.f.). Capítulo 6: Gestión del Tiempo del Proyecto. Recuperado el 15 de
11 de 2016, de
http://dis.unal.edu.co/~icasta/GGP/_Ver_2011_2/2011_2_GGP_Clases/GGP_2011_11_
23_Tiempo/ch06_2011_1_Tiempo_v01.pdf

Colaborativo Final

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

Colaborativo Final

Uploaded by

Copyright:

Available Formats

FASE 3

UNIVERSIDAD ABIERTA Y A DISTANCIA – UNAD

TRESLA Noviembre 2017

Descripción de requisitos del sofware

Ficha del documento

Fecha Revisión Autor Verificado dep. calidad.

Documento validado por las partes en fecha: Nov 2017

Por el cliente Por la empresa suministradora

Fdo. D./ Dña Gerente Tresla Fdo. D./Dña Carlos Rincon

1.3 Personal involucrado 6

1.4 Definiciones, acrónimos y abreviaturas 6

2.1 Perspectiva del producto 7

2.2 Funcionalidad del producto 7

2.3 Características de los usuarios 7

2.5 Suposiciones y dependencias 7

2.6 Evolución previsible del sistema 7

3.1 Requisitos comunes de los interfaces 8

3.2 Requisitos funcionales 8

3.3 Requisitos no funcionales 9

Descripción de requisitos del sofware

3.4 Otros requisitos 10

Descripción de requisitos del sofware

En la actualidad se ha incrementado la necesidad de elevar el nivel de seguridad de ingreso

ACTIVIDAD CRONOGRAMA DE RESPONSABLE

Angélica Garzón gestión

Ronald Acevedo Gestión

Héctor González Gestión

Interacción del grupo con los 31/10/2017 a 20/11/2017 Todos

Descripción de requisitos del sofware

1.3 Personal involucrado

Angélica María Garzón

1.4 Definiciones, acrónimos y abreviaturas

Descripción de requisitos del sofware

2.2 Funcionalidad del producto

Descripción de requisitos del sofware

Los campos de número de teléfono

La aplicación debe ser accesible

A través de la aplicación se deben

Los logs generados durante la

La aplicación debe permitir liberar

Descripción de requisitos del sofware

El servidor principal debe detectar

Se debe informar como alarma que

El sistema debe poder visualizar

2.3 Características de los usuarios

Tipo de usuario Común

2.5 Suposiciones y dependencias

2.6 Evolución previsible del sistema

Descripción de requisitos del sofware

todos los elementos necesarios de acuerdo con la propuesta.

Requisito 2 Suministrar e instalar un sistema completo de vigilancia por

Requisito 3 La grabación será durante las 24hs. Se busca mantener la

Requisito 4 Se suministrará el software adecuado para programación y

Requisito 5 Se deberá poder ver desde múltiples estaciones de trabajo

Descripción de requisitos del sofware

Fuente del requisito programador

Requisito 6 Se valorará positivamente la posibilidad de contar con la

Requisito 7 A nivel de funcionalidades, cada usuario deberá disponer de un

Requisito 8 Se valorará positivamente la posibilidad de contar con la

Requisito 9 Se valorará positivamente que el operador disponga de:

Requisito 10 Se valorará positivamente la posibilidad de contar con la

Requisito 11 Se deberá poder controlar la grabación en base a eventos.

Descripción de requisitos del sofware

Tipo Requisito Restricción