Informe Final DEVELUTA PDF

UNIVERSIDAD DE TARAPACÁ
FACULTAD UNIVERSITARIA DE INGENIERÍA
Departamento de Ingeniería en Computación e Informática
ETAPA FINAL: DEVELUTA
Autores: Iván Cardemil

Octavio Flores
Patricio Tudela
José Vásquez
Curso: Ingeniería de software
Profesor: Raúl Herrera Acuña
Arica, Julio 17 de 2019

Ingeniería de software
Etapa final: DEVELUTA
Contenido
RESUMEN..............................................................................................6
I. INTRODUCCIÓN....................................................................................7
II. OBJETIVOS........................................................................................8
2.1 Propósito......................................................................................8
2.2 Objetivo general.............................................................................8
2.3 Objetivos específicos.......................................................................8
III. DESARROLLO.....................................................................................9
3.1 Antecedentes generales....................................................................9
3.1.1 Descripción de la empresa desarrolladora.........................................9
3.1.1.1 Visión...............................................................................9
3.1.1.2 Misión..............................................................................9
3.1.1.3 Historia............................................................................9
3.1.1.4 Productos..........................................................................9
3.1.1.5 Factor Humano..................................................................10
3.1.1.6 Organigrama.....................................................................11
3.1.1.7 Proveedores.....................................................................12
3.1.1.8 Ventas............................................................................12
3.1.1.9 Servicios post venta............................................................12
3.1.1.10 Infraestructura y tecnología de información..............................12
3.1.1.11 Unidades de producción......................................................12
3.1.2 Descripción de la empresa dueña del proyecto.................................13
3.1.2.1 Visión.............................................................................13
3.1.2.2 Misión.............................................................................13
3.1.2.3 Historia...........................................................................14
3.1.2.4 Productos........................................................................14
3.1.2.5 Factor Humano..................................................................15
3.1.2.6 Organigrama.....................................................................19
3.1.2.7 Proveedores.....................................................................20
3.1.2.8 Ventas............................................................................20
3.1.2.8.1 Servicios post venta......................................................20
3.1.2.8.2 Infraestructura y tecnología de información.........................20
3.1.2.8.3 Unidades de producción.................................................20
3.2 Definición del proyecto...................................................................21
3.2.1 El problema o necesidad............................................................21
3.2.2 Por qué es importante abordar el proyecto......................................22
3.2.3 Requerimientos del Cliente/Usuario..............................................22
3.2.4 Requisitos elecitados................................................................23
3.2.4.1 Requisitos funcionales.........................................................23
3.2.4.2 Requisitos no funcionales.....................................................23
3.2.4.3 Restricciones del software....................................................24
3.2.4.4 Diagrama de casos de uso para el sistema..................................25
3.2.5 Descripción del producto y proceso...............................................26
Preparado por Iván Cardemil – Octavio Flores – Patricio Tudela – José Vásquez 2
3.2.5.1 Características del producto..................................................26

3.2.5.1.1 Modelo general del software definido y del prototipo a ser
entregado..............................................................................27
3.2.5.1.2 Funcionalidades que ofrecerá (mapeadas a los requisitos)........30
3.2.5.1.3 Funciones de seguridad..................................................31
3.2.5.1.4 Funciones de interfaz de usuario.......................................32
3.2.5.2 Características preliminares del procesos..................................33
3.2.5.2.1 Tipo de proceso...........................................................33
3.2.5.2.2 Duración y etapas del proceso..........................................34
3.2.6 Restricciones..........................................................................35
3.3 Plan temporal..............................................................................36
3.3.1 Carta Gantt del proyecto...........................................................37
3.3.2 Red de proyecto......................................................................37
3.3.3 Ruta crítica............................................................................38
3.4 Estimación de costos......................................................................39
3.4.1 Costos asociados al proyecto.......................................................39
3.4.1.1 Costos de gestión...............................................................39
3.4.1.2 Costos tecnológicos............................................................39
3.4.1.2.1 Hardware...................................................................39
3.4.1.2.2 Software....................................................................40
3.4.1.3 Costo total estimado...........................................................40
3.4.2 Beneficios asociados al proyecto..................................................41
3.4.3 Costos de la etapa de desarrollo del software..................................42
3.4.3.1 Puntos de caso de uso.........................................................56
3.4.3.1.1 Puntos de caso de uso (UCP)............................................56
3.4.3.1.2 Esfuerzo Horas-Hombre..................................................63
3.4.4 Tabla de costos vs beneficios proyectado en meses............................65
3.5 Diagrama contextualizado del proyecto y organización del desarrollo............66
3.5.1 Diagrama organizativo del proyecto..............................................66
3.5.2 Diagrama organizativo del desarrollo de software..............................67
3.6 Mecanismo de comunicación y sus responsables......................................68
3.6.1 Reuniones formales..................................................................68
3.6.2 Correo electrónico...................................................................68
3.6.3 Llamadas IP...........................................................................68
3.7 Riesgos.......................................................................................69
3.7.1 Tabla de riesgos del proyecto......................................................69
3.7.2 Reducción, supervisión y gestión del riesgo......................................71
IV. CONCLUSIONES.................................................................................77
V. REFERENCIAS BIBLIOGRÁFICAS................................................................78
VI. ANEXOS..........................................................................................78
Tablas
Tabla 1: Factor humano DEVELUTA.............................................................10
Tabla 2: Factor humano Universidad de Tarapacá...........................................15
Tabla 3: Requisitos funcionales..................................................................23
Tabla 4: Requisitos no funcionales..............................................................23
Tabla 5: Funcionalidades del software.........................................................30
Tabla 6: Funciones de seguridad................................................................31
Tabla 7: Funciones de interfaz de usuario.....................................................32
Tabla 8: Procesos del proyecto..................................................................33
Tabla 9: Etapas del proyecto....................................................................34
Tabla 10: Restricciones del proyecto...........................................................35
Tabla 11: Actividades del proyecto.............................................................36
Tabla 12: Costos de gestión......................................................................39
Tabla 13: Costos del software...................................................................40
Tabla 14: Costo total estimado..................................................................40
Tabla 15: Beneficio del proyecto................................................................41
Tabla 16: Caso de uso: "Login"...................................................................42
Tabla 17: Caso de uso: "Ingresar recurso"......................................................43
Tabla 18: Caso de uso: "Modificar recurso"....................................................44
Tabla 19: Caso de uso: "Eliminar recurso".....................................................45
Tabla 20: Caso de uso: "Mostrar recurso"......................................................46
Tabla 21: Caso de uso: "Ingresar observación"................................................47
Tabla 22: Caso de uso: "Mostrar observaciones"..............................................48
Tabla 23: Caso de uso: "Registrar préstamo"..................................................49
Tabla 24: Caso de uso: "Cargar archivo"........................................................50
Tabla 25: Caso de uso: "Crear reserva".........................................................51
Tabla 26: Caso de uso: "Entregar reserva".....................................................52
Tabla 27: Caso de uso: "Retornar recurso".....................................................53
Tabla 28: Caso de uso: "Gestión de recurso"..................................................54
Tabla 29: Caso de uso: "Gestión de permiso"..................................................55
Tabla 30: Equivalencia de peso de actores....................................................56
Tabla 31: Peso de actores........................................................................56
Tabla 32: Equivalencia de casos de uso........................................................57
Tabla 33: Peso de casos de uso..................................................................57
Tabla 34: Equivalencia de complejidad técnica..............................................59
Tabla 35: Pesos de factores técnicos...........................................................60
Tabla 36: Equivalencia de complejidad ambiental...........................................61
Tabla 37: Peso de factores ambientales.......................................................61
Tabla 38: Esfuerzo por etapa....................................................................63
Tabla 39: Beneficio proyectado por meses....................................................65
Tabla 40: Tabla de riesgos del proyecto.......................................................69
Tabla 41: Descripción de riesgos................................................................70
Figuras
Figura 1: Organigrama DEVELUTA..............................................................11
Figura 2: Organigrama Universidad de Tarapacá.............................................19
Figura 3: Diagrama de caso de uso del sistema..............................................25
Figura 4: Modelo del software, verificación de disponibilidad............................27
Figura 5: Modelo de software, validación de datos de alumno............................28
Figura 6: Casos de uso implementados en el prototipo.....................................29
Figura 7: Carta Gantt del proyecto............................................................37
Figura 8: Red del proyecto......................................................................37
Figura 9: Obtención de la ruta crítica.........................................................38
Figura 10: Diagrama organizativo del proyecto..............................................66
Figura 11: Diagrama organizativo del desarrollo de software.............................67
RESUMEN
La importancia de la Universidad de Tarapacá en el norte del país ha crecido en los
últimos años, pero ciertos aspectos de manejo de información sobre esta quedan
estancados en el tiempo. Lo cual no es adecuado para una institución de tal calibre.
Los directores de esta Universidad han reunido a miembros estudiantiles, a los cuales
les ha encargado la solución a las problemáticas existentes de la institución. Gracias a
esto nace la organización de alumnos llamada “DEVELUTA”.
De acuerdo a la investigación realizada y las reuniones sostenidas con diversos actores

de la Universidad, se logra detectar el problema de gestión de los recursos en el
departamento ingeniería de computación e informática (DICI).
Luego, el equipo de desarrollo debió formular una propuesta de software para abordar
el problema señalado, donde se especificó sus principales funcionalidades en áreas
como la seguridad o interfaz de usuario. Además, se especifica las características del
software y el alcance del prototipo a entregar.
Finalmente, el documento contiene el plan de como es que el equipo desea aborda el

proyecto, donde se describe la tareas a realizar, la estimación de costo y el manejo
de riesgos.
I. INTRODUCCIÓN
El presente informe dará cuenta de la descripción de las primeras etapas de un
proyecto que dará solución a un problema que aqueja al departamento de ingeniería
computación e informática (DICI).
Para dar con el problema, el equipo de trabajo se reunió con el encargado de

laboratorio del departamento, quien hizo ver los problemas que tenía para realizar el
control de los recursos que son prestados a los alumnos del área, ya que el único
método que tienen para resguardar la seguridad de los recursos, es el de la retención
de un documento de identificación, por ejemplo, la cédula de identidad o el pase
escolar. Otra reunión que sostuvo el equipo, fue con la dirección de logística de la
Universidad, quien mostró interés en empujar soluciones informáticas que utilicen la
tarjeta universitaria inteligente (TUI).
Con está información el equipo realizará la propuesta de implementar un software

bautizado como ORGANILAB, que servirá como una herramienta de trabajo para los
encargados de departamento y laboratorio, que les ayude en tareas de control sobre
los recursos del departamento. Donde el uso de la tarjeta TUI se verían en procesos
como los de registrar el préstamo de un recurso, ya que la tarjeta sería de utilidad
para capturar los datos del alumno solicitante.
En esta propuesta se abordará aspectos como los costos de desarrollo, los tiempos de
trabajo y los riesgos que se puede enfrentar el proyecto.
II. OBJETIVOS
2.1 Propósito
Entregar información y comunicar de manera ordenada y comprensible la propuesta
realizada por la empresa DEVELUTA al departamento de computación e informática.
2.2 Objetivo general

Describir la propuesta de solución del problema sobre la gestión de los recursos del
departamento de ingeniería computación e informática.
2.3 Objetivos específicos

• Describir aspectos y características de la empresa “Universidad de Tarapacá”.
• Describir aspectos y características de la empresa “DEVELUTA”.
• Describir el problema del departamento de ingeniería en computación e
información.
• Realizar la descripción del producto.
• Identificar las restricciones del proyecto.
• Identificar actividades y estimar sus tiempos, en el contexto universitario.
• Realizar la estimación de costos del proyecto.
• Definir los mecanismo de comunicación y sus responsables.
• Identificar y definir los riesgos del proyecto.
III. DESARROLLO
3.1 Antecedentes generales
3.1.1 Descripción de la empresa desarrolladora
3.1.1.1 Visión
La empresa busca comprometerse con la comunidad para entregar soluciones de
software de alta calidad, generando con esto el reconocimiento de sus servicios. Esta
labor se realizará de forma ética y satisfactoria para la empresa, sus clientes y el
resto de la comunidad.
3.1.1.2 Misión
Entregar soluciones informáticas confiables y de calidad a las problemáticas de
nuestros clientes y así brindarles un servicio ejemplar.
3.1.1.3 Historia
DEVELUTA nace en el año 2019. Surge a partir de la necesidad de generar un software
prototipo capaz de solucionar una problemática de la Universidad de Tarapacá,
enfocada en el área de gestión de información que ésta requería. Para esto, tres
alumnos de tal establecimiento fueron los encargados de realizar esta tarea aplicando
las bases de ingeniería y ética profesional que han aprendido durante sus años de
aprendizaje.
3.1.1.4 Productos
Desarrollo de software: La empresa cuenta con la experiencia suficiente para realizar
un diagnóstico del negocio de los potenciales clientes, logrando así, proponer un
software hecho a la medida de las necesidades de la empresa teniendo siempre como
horizonte la optimización de los procesos de negocio y disminuir los potenciales
riesgos. En específico la empresa entrega diferentes productos informáticos como
aplicaciones, ampliación y mejoras de sistemas de información existentes.
Mantención: Además la empresa entrega un servicio de seguimiento y mantención

post-venta de sus productos que será especificado más tarde en el documento.
3.1.1.5 Factor Humano

Cada integrante de esta empresa cumple un rol en esta. A continuación se declaran
los roles, el nombre del encargado y su funcionamiento:
Tabla 1: Factor humano DEVELUTA

Nombre Cargo Función
Iván Cardemil Jefe de proyecto Representante público del
equipo. Encargado de
organizar, planear, prever y
velar por el correcto
funcionamiento del producto
final.
José Vásquez Jefe de Unidad Financiera Encargado de realizar balances

financieros y gestión de
recursos.
Patricio Tudela Jefe de Unidad de Recursos Encargado de garantizar una
Humanos buena comunicación entre los
niveles, coordinar programas
de capacitación, controlar el
proceso de posibles
reclutamientos y verificar los
procesos de servicios en la
administración del personal.
Octavio Flores Jefe de Unidad Informática Encargado de controlar el
análisis y diseño del producto,
controlar los equipos de
desarrollo y dirigir programas
de mantención y depuración de
sistemas.
Preparado por Iván Cardemil – Octavio Flores – Patricio Tudela – José Vásquez
10
3.1.1.6 Organigrama
Figura 1: Organigrama DEVELUTA
11
3.1.1.7 Proveedores
El principal proveedor de DEVELUTA es la Universidad de Tarapacá, la cual entrega
distintos servicios para la realización de las actividades de la empresa, como el
espacio de trabajo, conexión a la red estable, equipos de trabajo, herramientas e
información.
3.1.1.8 Ventas
Como proceso de venta la empresa establece una serie de reuniones con los gerentes o
directores de las áreas del negocio del cliente con el objetivo de realizar un
diagnóstico de la condición de la empresa. Luego se entregará un informe donde se
especifica la propuesta de software en conjunto a un calendario de trabajo y el costo
asociado a la creación de la aplicación.
3.1.1.9 Servicios post venta

El servicio de post-venta se divide en dos categorías, la primera es el compromiso de
la empresa en encargarse de la mantención del software por seis meses después de la
primera entrega de la aplicación cómo forma de garantía. El segundo servicio que
entrega la empresa es el de capacitar al personal de la empresa del cliente en el uso
de la software.
3.1.1.10 Infraestructura y tecnología de información

La sede de la empresa se encuentra en Arica siendo esta una unidad móvil. La mayoría
de sus procesos se ejecutan bajo la infraestructura, herramientas y recursos
permitidos que ofrece la Universidad de Tarapacá, en concreto el departamento de
computación e informática.
3.1.1.11 Unidades de producción

Las unidades de producción se encuentran ubicadas en la ciudad de Arica, con base en
la Universidad de Tarapacá. En ese lugar se encuentran las oficinas administrativas.
12
3.1.2 Descripción de la empresa dueña del proyecto

3.1.2.1 Visión
Ser un referente como universidad estatal, regional y fronteriza, reconocida por su
calidad y aporte a la equidad, al desarrollo y a la integración académica e
intercultural en la Macro Región Centro Sur Andina.
Esta aspiración estratégica de largo alcance implica:

1) Posicionarse estratégicamente como un referente de calidad en el ámbito de las
universidades estatales y regionales del sistema de educación superior.
2) Consolidarse como una Universidad de excelencia académica, con un modelo
educativo propio, en la formación de pre y postgrado, en la Macro Región
Centro Sur Andina.
3) Contribuir al progreso regional y nacional, generando movilidad y desarrollo
social, a través de la formación de profesionales de alta calidad preparados
para actuar en ambientes globales.
4) Posicionarse como una institución referente, en relación con su productividad
relativa en materia de generación, promoción y transferencia científico-
tecnológica de conocimientos a la comunidad científica regional, nacional e
internacional.
5) Contribuir al desarrollo regional a través de actividades y proyectos de
vinculación y gestión compartida del conocimiento con actores relevantes del
medio social, cultural y productivo.
3.1.2.2 Misión
La Universidad de Tarapacá es una institución de Educación Superior Estatal que está
comprometida con la excelencia académica y el mejoramiento continuo de su calidad.
La institución realiza su quehacer en la Región de Arica y Parinacota y en la Región de
Tarapacá, con proyección del mismo hacia el país y a la Macro Región Centro Sur
Andina.
Sus principales áreas de desarrollo son: la docencia de pregrado orientada a la

formación de profesionales que se inserten con éxito en el mercado laboral,
promoviendo la educación continua y la movilidad social; la investigación y el
postgrado en aquellas áreas en las cuales la Universidad posee ventajas competitivas
significativas; la vinculación con el medio y la extensión académica en la perspectiva
de contribuir al desarrollo regional e integración transfronteriza. La Universidad de
Tarapacá, además, asume el desafío de custodiar la Cultura Chinchorro, la que
constituye un patrimonio cultural milenario de valor inestimable para la Región, así
como para la nación.
13
3.1.2.3 Historia
Mediante Decreto con Fuerza de Ley N 150 del 11 de diciembre de 1981 del Ministerio
de Educación Pública, se crea la Universidad de Tarapacá, fusionando el Instituto
Profesional de Arica con la sede Arica de la Universidad del Norte.
El primer rector delegado, nombrado por Decreto Nº 131, a contar del 1 de febrero de
1982, fue Carlos Raúl Valcarce Medina.
El 2007 la Universidad logra la acreditación institucional, otorgada por la Comisión

Nacional de Acreditación, por cinco años y en las áreas obligatorias de Gestión
Institucional, Docencia de Pregrado y en las áreas electivas de Vinculación con el
medio y de Investigación.
3.1.2.4 Productos
La Universidad entrega como producto al usuario certificados por sus experiencias,
capacitaciones, seminarios, academias y al finalizar la carrera, el diploma de
titulación de la carrera.
Por otra parte, la Universidad ofrece los siguientes servicios a la comunidad

estudiantil:
1. Servicio de atención psicológica
2. Clínica odontológica
3. Estudios clínicos
4. Maternidad
5. Asesorías jurídicas
14
3.1.2.5 Factor Humano

Tabla 2: Factor humano Universidad de Tarapacá
Elementos de la organizión Director/ Jefe/ Encargado/ Función
Honorable Junta Directiva Elizabeth Bastías Marín -Designar Funcionarios
Superiores de la Uta.
-Aprobación de Grados,
Titulaciones y Presupuesto
Contraloría Patricio Zapata Valenzuela -Ver los Asuntos legales de la

UTA.
-Controlar los bienes de la UTA.
Rectoría Emilio Rodríguez Ponce -Nombrar y remover al
personal Académico de la UTA.
-Proponer nuevos académicos
y presupuesto a la junta
directiva
Dirección General de Carmen Araneda Guirriman -Tomar las acciones necesarias
Gabinete para optimizar la gestión de la
Rectoría.
-Apoyar y administrar asuntos
junto a la rectoría.
Secretaría Luis Tapia Iturrieta -Registro de todas las
reuniones de la directiva,
comités y juntas de la UTA.
-Guardar Documentos de la
UTA.
Dirección de asuntos Legales Gladys Acuña Rosales -Estudio de decretos y
resoluciones.
-Asesorar al Rector.
Vicerrectoría Académica Alfonso Díaz Aguad -Realizar propuestas en
materia Académica.
- Participación en análisis y
formulario de presupuesto en
las unidades académicas
Vicerrectoría de Desarrollo Jenniffer Peralta Montecinos -Asesoramiento en materia
Estratégico nacional e internacional.
-Generar políticas y promover
el desarrollo estratégico de
calidad de la universidad.
15
-Formulación de Presupuesto y
Vicerrectoría de Administración propuestas de ajuste al
Álvaro Palma Quiroz
y Finanzas presupuesto anual.
-Conocer la situación financiera
y económica de la UTA.
Facultades
-Dirigir y ejercer control sobre
las actividades que involucran
Sergio González Miranda la sede.
Dirección General de Sede
- Establecer vínculos con
organizaciones del medio
externo.
-Ver los temas de desarrollo a
mediano y largo plazo de la
universidad, de modo de
promover y evaluar su
Dirección de Planificación y Bernardina Cisternas Arapio implementación.
Proyectos -Proponer y responder a los
requerimientos internos en
estudios sobre materias
académicas, administrativas y
económicas.
-Gestión de los proceso de
acreditación institucional ante
la sistema Nacional de
Dirección de Calidad Aseguramiento de calidad.
Hernando Bustos Andreu
Institucional -Mantenimiento del sistema de
Aseguramiento de la calidad de
la Universidad de Tarapacá,
orientando al mejoramiento de
proceso y resultados.
-Diseñar y proponer políticas y
programas en materia de su
competencia.
Dirección de Administración y
Jorge Bernal Peralta -Participar y coordinar las
Finanzas
actividades políticas, normas,
reglamentos y/o
procedimientos que afecten a
la institución.
Dirección de Información y Nieves Rubio Medina -Diseñar e implementar el
control de Gestión sistema de control financiero
16
de la UTA.
-Generar información de
resultados incluyendo análisis y
propuestas de mejoras
Registraduría Marlene Cisternas Riveros -Llevar un registro de los

estudiantes en la UTA.
-Llevar también un registro de
academias, seminarios,
prácticas de cada estudiante.
Dirección de Docencia Carlos Leiva Sajuria -Control de la labor académica.
-Proponer normas, leyes,
reglamentos y/o
procedimientos para el
desarrollo de la actividad
docente
Dirección Académica de Sede Yasna Godoy Henriquez -Coordinar, supervisar y
controlar la ejecución y
desarrollo de la labor
académica de la sede.
-Supervisar la carga académica
y los programas de
capacitación de la sede.
Dirección de Equidad de Claudia Moraga Contreras -Coordinar acciones frente a
Género denuncias y programas de
intervención preventivos en
materia de acoso laboral.
-Ser participe en actividades o
decisiones orientadas a la
equidad de género.
Dirección de Relaciones Bernardo Arriaza Torres -Proponer e implementar
Internacionales políticas generales en materias
de asuntos internacionales.
Direccion de Logistica, Obras y Jorge Cáceres Godoy -Dirigir y coordinar con la
Operaciones Unidad signataria del proyecto
la elaboración del programa de
uso y especificaciones técnicas.
-Proponer normas, medidas,
reglamentos y/o
procedimientos, de
administración y mantención.
17
Dirección de Gestión de Paulina Ortuño Fariña -Velar por la correcta

Personas y Bienestar Laboral aplicación de las normas y
reglamentos personales y de
las disposiciones legales
atingentes.
-Manejo de la administración
personas y legislación laboral,
de modo de aplicar las normas
correspondientes.
Dirección de Asuntos Ingrid Fernandez Carvajal -Coordinar y planificar los
Estudiantiles diferentes programas de
servicio para el estudiante.
-Plan de desarrollo de
asistencia al Estudiante
Dirección de Investigación, Sebastian Lorca Pizarro -Coordinar, supervisar,
Postgrado y Transferencia asesorar y ejecutar las
Tecnológica actividades de investigación.
-Asesorar al vicerrector
académico en programas de su
competencia
Dirección de Administración y Pablo Galvez Castex -Proporcionar soporte de
Finanzas de Sede gestión de recursos humanos y
materiales tecnológicos para el
eficiente funcionamiento
administrativo de la sede.
Dirección de Extensión y Alberto Díaz Araya -Ver temas de extensión
Vinculación con el Medio académica cultural y
ambiente vinculación con los sectores
productivos sociales de la
región, ciudad, país o países
vecinos.
Dirección Biblioteca Sergio Medina Parra -Dirigir y coordinar los servicios
bibliotecario.
-Mantener intercambios en el
ámbito bibliográfico a nivel
nacional e internacional.
18
3.1.2.6 Organigrama
Figura 2: Organigrama Universidad de Tarapacá
19
3.1.2.7 Proveedores
La Universidad al ser una entidad de carácter público debe realizar sus comprar por
medio de la plataforma “Mercado Público”, donde se puede encontrar la lista que
contiene el número de orden de compra, nombre del orden compra, nombre del
proveedor, la fecha de envío y el estado de la orden.
3.1.2.8 Ventas
Como servicio de venta, la Universidad ofrece al usuario una completa formación
profesional pregrado o postgrado en las carreras disponibles, acceso a los beneficios
como estudiante en la biblioteca, el casino, becas, transporte y la posibilidad de hacer
intercambio con otras instituciones. Además el usuario escoge el nivel de formación
que quiere tener como Técnico, Profesional, Magister o Doctorado.
3.1.2.8.1 Servicios post venta

La universidad además entrega servicios de capacitación y aumento de grado a sus
usuarios egresados, dando la posibilidad de tomar otros cursos en horario nocturno,
magíster y doctorado. El servicio está disponible también para clientes externos a la
universidad.
3.1.2.8.2 Infraestructura y tecnología de información

La Universidad está presente en las ciudades de Arica, donde se encuentra su Casa
Central, y la ciudad de Iquique. En la ciudad de Arica cuenta con tres campus y cuatro
laboratorios de alta investigación.
Desde el punto de vista de la tecnología la Universidad cuenta con una Intranet, donde
los alumnos pueden ver sus notas, becas, avance curricular, mensajes de los
profesores, la página web oficial de la institución y sus derivados (área de recursos,
biblioteca en línea), donde se publican las últimas noticias que involucran a la
Universidad y actividades.
Además, la Universidad posee la infraestructura de soporte tecnológico que permite

organizar áreas de recursos computacionales, salas de conferencia y proyección, Wi-Fi
en todo el campus, pizarras didácticas, laboratorios.
3.1.2.8.3 Unidades de producción

La casa central de la Universidad de Tarapacá se encuentra en 18 de Septiembre 2222,
Arica, Región de Arica y Parinacota.
20
3.2 Definición del proyecto

3.2.1 El problema o necesidad
Los ayudantes del departamento de Ingeniería en Computación e Informática, poseen
un sistema de gestión de recursos arcaico el cual presenta falencias en la seguridad y
poca eficiencia del tiempo. El sistema actual no tiene la capacidad de responder con
exactitud las preguntas ¿Quién ocupó el recurso? ¿Cuándo ocupó el recurso? y ¿Dónde
ocupó el recurso?.
El sistema actual de los ayudantes del DICI consta de prestar recursos a los alumnos y
profesores mediante la entrega de una identificación, para ser más preciso la cédula
de identidad del usuario. Esta identificación es retenida hasta que el usuario devuelva
el recurso a la sala, por ende, si el usuario la necesita para otras actividades, no la
podrá utilizar. Mientras el ayudante tenga la identificación, este debe anotar en una
hoja de papel física las respuestas a las preguntas anteriormente planteadas. Para
guiarse un poco mejor, utiliza una numeración de los recursos de tipo portátil los
cuales quedan ligados a la identificación del usuario por el tiempo que dure su uso.
Lo anteriormente planteado posee problemas naturales, como el uso de una hoja del
papel que puede quedar fácilmente inutilizada, como también los usuarios pueden
presentar identificaciones vencidas u otros métodos para saltarse la seguridad y evitar
ser culpados por los daños a los recursos. Además según la información recaudada de
los ayudantes, este sistema se está dejando de lado debido a la gran cantidad de
usuarios que piden los recursos implicando que deben hacer un mayor papeleo, lo cual
toma bastante tiempo.
Por esto surge la necesidad de crear un sistema de gestión de recursos organizado,

eficiente y seguro.
21
3.2.2 Por qué es importante abordar el proyecto

La importancia de realizar el proyecto es que va a permitir un mejor control y manejo
de los recursos que se encuentran en el departamento de ingeniería en computación e
informática, otorgando no solo una facilidad y comodidad a los encargados, sino
también a los usuarios que requieran disponer de estos recursos, permitiéndoles
realizar pedidos y reservas de los recursos del DICI.
Con la implementación de la mejora, aumentará la comodidad de los clientes los

cuales no deberán entregar una identificación necesaria para otras actividades. Para
los encargados se ve reducido el esfuerzo y tiempo que toma, recibir pedidos y
realizar el historial de uso de cada uno de los recursos, cientos de veces al día.
Desde el punto de vista de la organización del departamento, el proyecto permitirá

mejorar la gestión de los recursos, ya que este podrá realizar un seguimiento del uso
de estos, por lo que podrá saber quién fue el alumno o funcionario que solicitó el
préstamo, dónde lo utilizó, cuándo lo utilizo y por cuánto tiempo lo utilizó. Las
funciones descritas
Con esto, no solo se implementa esta tecnología para el área local, sino que a futuro
podría ser aplicado a los distintos departamentos de la Universidad que posean
recursos para sus alumnos.
3.2.3 Requerimientos del Cliente/Usuario

De acuerdo a la reuniones sostenidas con el cliente, el encargado de laboratorio, este
puso el énfasis en aquellas características relacionadas con la experiencia del usuario,
por ejemplo, la posibilidad de cambiar de colores ciertos módulos del software.
Fue el equipo de trabajo, que al darse cuenta que el sistema utilizado por el
departamento tiene serias falencias en aspectos como la seguridad, eficiencia del de
los recursos, por lo que propuso el desarrollo de un software de gestión de inventario.
Una de las reuniones que se tuvo con el director de logística de la Universidad,
comentó el interés de hacer uso de las tarjetas universitarias inteligente (Tarjeta
TUI).
A partir de lo anterior se pueden definir tres áreas de requisitos:
 Obtener una experiencia de uso agradable para el usuario.

 Implementar medidas de seguridad, para resguardar de mejor forma los
recursos del departamento.
 Utilizar la tarjeta TUI en las operaciones del software.
22
3.2.4 Requisitos elecitados

3.2.4.1 Requisitos funcionales
A continuación se presenta una tabla con los requerimientos funcionales del software.
Tabla 3: Requisitos funcionales

Código Requisitos
RF1 El sistema debe verificar al alumno
RF2 El sistema debe permitir el ingreso y retiro de recursos
RF3 El sistema debe registrar observaciones de recursos
RF4 El sistema debe permitir la gestión de los préstamos de recursos
RF5 El sistema debe almacenar la información asociada a cada préstamo
RF6 El sistema permitir la carga de archivos con datos de los recursos
RF7 El sistema debe permitir gestionar usuarios
RF8 El sistema debe permitir registrar reservas de recursos
RF9 El sistema debe permitir gestionar los permisos de sus usuarios
3.2.4.2 Requisitos no funcionales

En la siguiente tabla se describirán los requisitos no funcionales del software.
Tabla 4: Requisitos no funcionales

Código Requisitos
RnF1 El sistema debe cumplir con los estándares de diseño de la Universidad
RnF2 La interfaz debe tener los colores representativos de la Universidad de Tarapacá
RnF3 El sistema debe tener un enfoque web
RnF4 El sistema debe garantizar su funcionamiento en el navegador Mozilla Firefox
RnF5 La interfaz debe ser intuitiva y fácil de utilizar
RnF6 El sistema debe ser capaz de comunicarse con bases de datos MySQL
RnF7 El sistema deberá ser desarrollado utilizando el framework de Laravel
23
3.2.4.3 Restricciones del software

Se lograron identificar las siguientes restricciones del software:
 Se debe utilizar la tecnología NFC para identificar a los alumnos.
 Solo se pueden utilizar tecnologías libres al momento de desarrollar el
software.
 Debe cumplir con la características de portabilidad.
 Se debe entregar en un tiempo límite.
24
3.2.4.4 Diagrama de casos de uso para el sistema

A continuación se presenta el diagrama de caso de uso para el sistema, el detalle de
estos se encuentra en la sección de estimación de costos, ya que se descripción es
necesaria para obtener las transacciones que son utilizadas en el método de Karner.
Figura 3: Diagrama de caso de uso del sistema
25
3.2.5 Descripción del producto y proceso

3.2.5.1 Características del producto
El producto a crear es una aplicación web, esta será desarrollada utilizando el
framework PHP Laravel. Está se conectará a una base de datos Oracle, para realizar el
registro de la transacciones del sistema.
El equipo de desarrollo eligió realizar una aplicación web debido a que cumple con la
propiedad de portabilidad, que además, es una restricción de software. Si bien el
problema se está abordando desde la perspectiva del departamento de Informática, se
espera que este pueda ser utilizado por otras unidades de la organización, por lo que
su portabilidad es un aspecto fundamental, entonces si el usuario solo debe
conectarse a una dirección en la web, se cumple con creces esta propiedad.
Otro motivo por el que se decanto por la aplicación web, es que este podría
convertirse en un posible módulo del sistema interno de la Universidad de Tarapacá,
por lo que que haría del trabajo de integración una tarea más sencilla, ya que solo se
tendría que hacer ajustes en la rutas de acceso, debido a que el manejo de roles de
usuario y permisos, ya está integrado al sistema.
Respecto a la herramientas utilizadas para desarrollar el software, se eligió laravel

debido a que es un framework de PHP muy popular en la actualidad, por lo que su
cuenta con una documentación actualizada, además de tener una comunidad de
programadores muy activa, por lo tanto, algunas de las funcionalidades propuestas,
como por ejemplo, la de cargar archivos excel al sistema, ya están disponibles en
forma de plugin. Esto es muy útil, ya que aliviana la carga del equipo de desarrollo. En
el caso de la base de datos Oracle, se eligió debido a que la Universidad trabaja con
servidores de este tipo.
26
3.2.5.1.1 Modelo general del software definido y del prototipo a ser entregado
En la siguiente figura se muestra el modelo de cómo es que funcionará el software a

desarrollar. Además, se ilustra el proceso completo de solicitar el préstamo de un
recurso del departamento.
Entonces en la primera parte, el alumno solicita un recurso, por lo que el encargado
verificará la disponibilidad del recurso en el sistema .
Figura 4: Modelo del software, verificación de disponibilidad
27
Si el sistema está disponible, el encargado solicitará la tarjeta TUI del alumno. Cuando
el alumno le entregue la tarjeta al encargado, este la pondrá sobre el dispositivo que
puede leer NFC. El sistema verificará los datos del alumno y se registrará el préstamo
en el sistema.
El proceso termina cuando el encargado entrega los recursos solicitados al alumno.
Figura 5: Modelo de software, validación de datos de alumno
28
Del diagrama de casos de uso expuesto en el punto 3.2.4.4 se implementaron en el

prototipo los siguientes casos de uso que se encuentran destacados.
Figura 6: Casos de uso implementados en el prototipo
Para más información sobre como utilizar el prototipo, dirigirse al Manual de Usuario
que viene como anexo a este informe.
29
3.2.5.1.2 Funcionalidades que ofrecerá (mapeadas a los requisitos)

En la siguiente tabla se describen las funcionalidades ofrecidas por el software. La
columna que tiene como identificador “RFX” asociara la función con uno o más
requisitos funcionales.
Tabla 5: Funcionalidades del software
Función Descripción RFX
Permite el ingreso, retiro y actualización de información de recursos al

Gestión de recurso RF2
sistema. Además permite agrupar recursos por categoría.
Cambia el estado de un recurso a “Ocupado” y lo enlaza a un alumno

Registrar préstamo RF4
por un intervalo de tiempo.
Registrar Permite ingresar “notas” en caso de que un recurso necesite

RF3
observaciones mantención.
Almacena la actividad asociada al recurso. Se profundiza en esta

Guardar historial RF5
función en el apartado de seguridad.
Cambia el estado de un recurso a “Reservado” y lo enlaza a un alumno

Gestionar reservas RF8
por un intervalo de tiempo, dependiendo de los bloques horarios.
Permite realizar una carga de datos desde una fuentes externa al

Cargar Archivos RF6
sistema, esto facilitará la labor de ingresar nuevos recursos.
Permite agregar usuarios al sistema. Estos usuarios ingresarán con el

Gestión de usuarios RF8
rol de encargado de laboratorio.
Permite modificar los permisos de los usuarios cuyo rol sea encargado
Gestión de permisos RF9
de laboratorio.
30
3.2.5.1.3 Funciones de seguridad
Tabla 6: Funciones de seguridad
Función Descripción RFX
Permite identificar si el alumno que está solicitando el uso del recurso

pertenece a la carrera. Para abordar esto, el alumno deberá
identificarse por medio de su tarjeta universitaria inteligente (TUI),
Verificar alumno RF1
donde el sistema realizará una comparación de los datos extraídos de
la tarjeta, con la información relacionada con el alumno que se
encuentra almacenada en la base de datos de la Universidad.
Realiza el registro de las personas que han utilizado algún recurso del
departamento. Además, almacena cuándo y dónde lo utilizó. Esta
Registrar historial RF5
función es muy importante para llevar el control de los recursos del
departamento, y en caso de daño, encontrar al responsable.
31
3.2.5.1.4 Funciones de interfaz de usuario
Tabla 7: Funciones de interfaz de usuario

Función Descripción
Inicio de sesión Permite al encargado ingresar al sistema para
su uso.
Gestionar recursos. Permite al encargado agregar, eliminar,
suspender los recursos del sistema.
Captura de datos de Alumno Permite capturar los datos del alumno
entregados por su tarjeta TUI.
Reserva de recursos Permite al encargado reservar recursos para los
alumnos en un horario dado.
Asignar Recurso Una vez obtenido los datos del alumno se
enlaza un recurso a un alumno por el tiempo
que este lo desee utilizar. Para esto utiliza
categorías de recursos con sus ID’s únicas.
Gestionar estado del recurso. Permite al encargado de los recursos observar y
editar el estado del recurso en forma de
comentarios. De esta forma se puede anotar si
un recurso necesita mantención o actualización.
Mostrar uso de los recursos Permite al encargado observar quién y dónde
está ocupando el recurso actualmente. Asi
saber su posición teórica por si se necesita una
intervención.
Mostrar historial de recurso Permite al encargado observar quien, donde y
cuando ocupó el recurso a lo largo del tiempo
solicitado.
32
3.2.5.2 Características preliminares del procesos

3.2.5.2.1 Tipo de proceso
Para la realización del proyecto se utilizará una metodología tradicional, donde hay un
mayor énfasis en la planificación del proyecto. De esto se desprenden cinco procesos.
Tabla 8: Procesos del proyecto
Proceso Descripción
Etapa donde el equipo de DEVELUTA estudió a la organización cliente, osea, la

Universidad, con la finalidad de encontrar una situación problemática para
Inicio
darle solución. En esta etapa se debió estudiar con mayor detalle como es el
proceso de Gestionar los prestamos en el departamento.
Identificada la situación problemática, en esta etapa el equipo debió generar

un documento, en el que explica el cómo es que se quiere abordar el
Planificación proyecto. Por lo que el equipo debió realizar una propuesta donde se plantean
los beneficios que traería el proyecto a la organización. Además, se realizó un
acercamiento a cómo es que será la solución final.
Es esta etapa se ejecutará el plan de proyecto. Se realiza el proceso de

aseguramiento de la calidad. Se establece establecen los objetivos para cada
etapa de la ejecución. En el caso de la empresa DEVELUTA la metodología a
Ejecución
utilizar es cascada, debido a que el equipo lo conforman en su totalidad
estudiantes, por lo que intentar implementar una metodología ágil, podría
atentar al rendimiento en el resto de los cursos.
Se controla el cumplimiento de los objetivos del proyecto, mediante un

Control
seguimiento y tomando acciones correctivas para llegar a cumplirlos.
Cierre Se tiene la aceptación del proyecto y cumplido esto se lleva a su finalización.
33
3.2.5.2.2 Duración y etapas del proceso

El proceso tendrá una duración de cuatro meses y una semana para llevar a cabo su
desarrollo.
Tabla 9: Etapas del proyecto

Proceso Etapas Duración (Semanas)
Reunión con clientes 1
Inicio
Levantar requerimientos 1
Total 2
Estudio de la tecnología NFC 1
Diseño de los casos de uso 1
Planificación
Asignación de tareas 1
Total 3
Codificación 3
Ejecución
Codificación de ARDUINO como 1
lector NFC
Integración con base de datos 1
Integración de módulos 2
Total 7
Pruebas de los prototipos 1
Control
Ajuste a la carta Gantt 1
Total 2
Pruebas 1
Cierre
Mantención 2
Total 3
34
3.2.6 Restricciones
En la siguiente tabla se presentará las restricciones del proyecto
Tabla 10: Restricciones del proyecto
Restricción Descripción
El presupuesto será una estimación de los costos del proyecto, que se

Presupuesto
medirá en términos de esfuerzo requerido por persona/mes por año.
Según el tiempo total establecido para desarrollar el proyecto es de cuatro

Plazo meses. El cuál comenzará el 5 de Agosto del 2019 al 6 de Diciembre de
2019.
El proyecto está constituido por cuatro estudiantes de pregrado de la

Personal carrera Ingeniería en computación e informática, donde cada es encargado
de un área específica del proyecto.
 Equipos: Notebooks, smartphones y computadores de escritorio.

 Uso de la tecnología NFC.
Tecnologías  Ambiente Google Drive para el almacenamiento de los documentos
e informes.
 Para la implementación y diseño se utilizarán software libres.
Métodos Metodología cascada.
35
3.3 Plan temporal

Como etapa inicial de este informe, se presentarán la lista de actividades relacionadas
al desarrollo del software que permita “La gestión de recursos del departamento”.
Tabla 11: Actividades del proyecto
Actividad Descripción Predecesor Duración(Semanas)
A Realizar el chárter de proyecto - 1
B Descubrir los procesos de la organización A 1
C Requerimientos del software B 2
D Análisis de software C 2
E Diseño de software D 2
F Desarrollo de la interfaz gráfica del E 3

usuario
G Desarrollo de la funciones del software E 3
H Integración de módulos F-G 2
I Pruebas H 2
J Mantención I 2
36
3.3.1 Carta Gantt del proyecto

En la siguiente figura se puede observar la Carta Gantt del proyecto, con las
estimaciones de tiempo en semanas.
Figura 7: Carta Gantt del proyecto
3.3.2 Red de proyecto

En el siguiente diagrama se puede observar el orden de cómo es que se ejecutarán las
actividades del proyecto y las dependencias entre actividades.
Figura 8: Red del proyecto
37
3.3.3 Ruta crítica

Para establecer la ruta crítica es necesario calcular 4 tiempos que son: El tiempo de
inicio temprano, el tiempo de terminación temprano, el tiempo de terminación más
lejano y el tiempo de inicio más lejano. En la siguiente figura se puede observar como
están distribuidos estos tiempos. Además, se calcularán los tiempos de acuerdo a la
tabla de actividades del proyecto.
Figura 9: Obtención de la ruta crítica
De acuerdo a la figura anterior, y calculando la holgura de cada actividad (H = LF –

EF), se logra identificar dos rutas críticas en el proyecto, que serían:
1. Inicio-A-B-C-D-E-F-H-I-J-Cierre
2. Inicio-A-B-C-D-E-G-H-I-J-Cierre
38
3.4 Estimación de costos

3.4.1 Costos asociados al proyecto
En las siguientes tablas se muestran los costos asociados a los distintos aspectos del
proyecto:
3.4.1.1 Costos de gestión
Tabla 12: Costos de gestión
Nombre Horas Costo hora Cantidad Total (CLP)
Gerente del 160 $ 21.875 1 $ 3.500.000

proyecto
Jefe de proyecto 160 $ 16.259 1 $ 2.600.000
Analista de Sistema 160 $ 10.625 1 $ 1.700.000
Desarrollador PHP 160 $ 6.250 2 $ 2.000.000
Diseñador UI/UX 160 $ 4.687,5 1 $ 750.000
Total del costo estimado de sueldos por mes $ 10.550.000
3.4.1.2 Costos tecnológicos

3.4.1.2.1 Hardware
Nombre Cantidad Precio por unidad Total (CLP)
Computadores 5 $ 450.000 $ 2.250.000
Servidores 1 (*)
Arduino Uno - R3 1 $ 16.990 $ 16.990
NFC Shield v2.1 1 $ 32.990 $ 32.990
NFC Tags 215 10 $ 1.000 $ 10.000
Total del costo estimado del hardware $ 2.309.980
39
3.4.1.2.2 Software
Tabla 13: Costos del software
Nombre Cantidad Precio por unidad Total (CLP)
Balsamiq 1 $ 62.000 $ 62.000
Github 1 - -
Netbeans 4 - -
SQL Developer 4 - -
Libre Office 4 - -
Google Drive 4 - -
Arduino IDE 1 - -
Total del costo estimado del software $ 62.000
3.4.1.3 Costo total estimado
Tabla 14: Costo total estimado
Nombre Total (CLP)
Costo de gestión $ 42.200.000
Costo de hardware $ 62.000
Costo de software $ 2.309.980
Total de costo estimado $ 44.571.980
40
3.4.2 Beneficios asociados al proyecto

A continuación se muestra la tabla de los beneficios esperados, asociados al proyecto.
Tabla 15: Beneficio del proyecto
Beneficio Descripción Total (CLP)
Mejora la seguridad de los Esto permitirá al departamento mantener $ 33.280.000

recursos. un mejor control de los recursos. Además,
evitará a lo largo del tiempo que los
alumnos dañen algún recurso, ya que se
podrá identificar quién fue el
responsable.
Ahorro en mantenimiento Al implementar el sistema de $ 33.280.000

de los recursos. observaciones , los recursos defectuosos
del laboratorio estarán sometidos a
mantenimiento constante. Esto provocará
que el recurso no quedé 100%
inutilizable.
Total del beneficio estimado $ 66.560.000
Como se puede observar en la tabla, ambos beneficios tienen el mismo valor. Eso es
debido a que el recurso que más se pide como préstamo en el departamento son los
notebooks. Además, se consideró que estos son los recursos que más se ven
beneficiados con el desarrollo del proyecto, entonces se utilizó el precio de uno de
estos como base para el cálculo de los beneficios.
De acuerdo al punto anterior, se definieron dos variable; el primero es el precio del

recurso (PR) en pesos chilenos y la cantidad de semanas que hay en un año académico
(TA) por lo que se considera que un recurso es solicitado al menos una vez por
semana. Esto es multiplicado por dos, porque se considerá el quiebre del horario
semanal que ocurre en la hora del almuerzo. Por lo que se propone la siguiente
fórmula para calcular el beneficio:
Beneficio PR*TA*2
Beneficio 520.000 * 32 * 2
Beneficio 33.280.000
El total del beneficio estimado que se muestra en la tabla solo corresponde a un año
académico. Considerando que la vida útil de un notebook es de al menos cinco años se
puede determinar que el beneficio a la largo del tiempo aumente drásticamente.
41
3.4.3 Costos de la etapa de desarrollo del software

De acuerdo con el diagrama de caso de uso expuesto en los punto 3.2.4.4, se
procederá a realizar las plantillas de caso de uso correspondiente, para obtener la
cantidad de transacciones que serán necesarias a la hora de utilizar el método de
Karner.
a) Caso de uso “Login”

Tabla 16: Caso de uso: "Login"
NOMBRE CASO DE USO Login
DESCRIPCIÓN Identifica al usuario en el sistema
ACTOR Encargado de laboratorio y Encargado de

departamento
PRECONDICIONES: El actor debe estar registrado en el sistema
FLUJO NORMAL:
1) El encargado ingresa a la opción de Login.
2) El sistema despliega los campos para que el encargado de laboratorio ingrese su RUN y
contraseña.
3) El encargado rellena los campos con sus datos y acepta.
4) El sistema valida los datos y envía al encargado al menú principal de la aplicación.
FLUJO ALTERNATIVO:
4) El sistema envía un mensaje indicando que los campos fueron rellenados de forma
incorrecta.
POSTCONDICIONES: El encargado de laboratorio ingresó al sistema.
42
b) Caso de uso “Ingresar recurso”

Tabla 17: Caso de uso: "Ingresar recurso"
NOMBRE CASO DE USO Ingresar recurso
DESCRIPCIÓN Permite al encargado ingresar nuevos recursos

al sistema.
ACTOR Encargado de laboratorio
PRECONDICIONES: El actor debe estar identificado en el sistema
FLUJO NORMAL:
1) El encargado ingresa a la opción de “Crear recursos”.
2) El sistema despliega los campos para que el encargado ingrese:
a) Nombre del recurso
b) Descripción
c) Cantidad
3) El encargado ingresa los datos solicitados y acepta.
4) El sistema verifica que todas las casillas estén con todos los datos requeridos, y envía un
mensaje de “Recurso creado de forma satisfactoria”.
FLUJO ALTERNATIVO:
4) El sistema envía un mensaje indicando que se deben rellenar todos los campos.
POSTCONDICIONES: Se ha ingresado un nuevo recurso al sistema.
43
c) Caso de uso “Modificar recurso”

Tabla 18: Caso de uso: "Modificar recurso"
NOMBRE CASO DE USO Modificar recurso
DESCRIPCIÓN Permite al encargado modificar la información

de un recurso.
FLUJO NORMAL:
1) El encargado selecciona la opción de “Modificar recurso”
2) El sistema despliega los campos de recurso, mostrando la información antigua del recurso
en formato de placeholder.
3) El encargado ingresa los datos que desea cambiar y acepta.
4) El sistema envía un mensaje de “Cambio realizado de forma satisfactoria”
FLUJO ALTERNATIVO:
No aplica
POSTCONDICIONES: Se ha modificado recurso del sistema.
44
d) Caso de uso “Eliminar recursos”

Tabla 19: Caso de uso: "Eliminar recurso"
NOMBRE CASO DE USO Eliminar recurso
DESCRIPCIÓN Permite al encargado eliminar todos los

elementos de un recurso del sistema.
FLUJO NORMAL:
1) El encargado selecciona la opción de “Eliminar recurso”.
2) El sistema solicita la confirmación de la acción al encargado, mostrando un botón de
“Confirmar” y “Cancelar”.
3) El encargado selecciona “Confirmar”.
4) El sistema verifica que todas las instancias de recurso estén en estado “DISPONIBLE”.
5) El sistema envía un mensaje de “Recurso eliminado de forma satisfactoria”
FLUJO ALTERNATIVO:
4) El sistema detecta que uno o más instancias del recurso están en estado “OCUPADO”.
5) El sistema envía un mensaje de “No se puede eliminar el recurso porque está siendo
utilizado.”
POSTCONDICIONES: Se ha eliminado el recurso del sistema.
45
e) Caso de uso “Mostrar recursos”

Tabla 20: Caso de uso: "Mostrar recurso"
NOMBRE CASO DE USO Mostrar recursos
DESCRIPCIÓN Permite al encargado ver un listado de todos los

recursos en el sistema.
PRECONDICIONES: El actor debe estar identificado en el sistema y debe estar en el menú principal
de recursos.
FLUJO NORMAL:
1) El encargado ingresa al menú de recursos.
2) El sistema muestra un listado de cada instancia de los recursos, separándolos según su
estado, que puede ser “DISPONIBLE”, “OCUPADO” y “RESERVADO”
FLUJO ALTERNATIVO:
2) El sistema enseña una opción de “Ingresar recurso”.
POSTCONDICIONES: El encargado puede ver los recursos del sistema.
46
f) Caso de uso “Ingresar observación”
Tabla 21: Caso de uso: "Ingresar observación"
NOMBRE CASO DE USO Ingresar observación
DESCRIPCIÓN Permite al encargado ingresar una “nota” u

“observación” de una instancia de recurso al
sistema.
de recursos.
FLUJO NORMAL:
1) El encargado selecciona la opción “Ingresar observación”.
2) El sistema despliega los campos para que el encargado ingrese:
a) Título de observación
b) Cuerpo de observación
3) El encargado ingresa los datos solicitados e ingresa la opción de “Confirmar”
4) El sistema asocia la observación a las instancia del recurso y deja esta observación en estado
“PENDIENTE”.
FLUJO ALTERNATIVO: No aplica
POSTCONDICIONES: El sistema ha registrado una observación de la instancia.
47
g) Caso de uso “Mostrar observaciones”
Tabla 22: Caso de uso: "Mostrar observaciones"
NOMBRE CASO DE USO Mostrar observaciones
DESCRIPCIÓN Permite al encargado ver un listado de todas las

observaciones asociados a cada instancia de
recurso.
de recursos.
FLUJO NORMAL:
1) El encargado ingresa al menú de observaciones.
2) El sistema muestra un listado de cada observación ingresada al sistema, donde enseña la
siguiente información:
a) Nombre del recurso
b) Identificación de la instancia de recurso
c) Título de la observación
d) Cuerpo de la observación
e) Fecha de creación (YYYY-MM-DD HH:MM:SS)
f) Una casilla para verificación
3) El encargado presiona la casilla de verificación de una observación.
4) El sistema cambia el estado de la observación a “REALIZADA” y agrega un campo de
“Fecha de realización (YYYY-MM-DD HH:MM:SS)”
FLUJO ALTERNATIVO:
No aplica
POSTCONDICIONES: El encargado puede ver las observaciones asociadas a los recursos del
sistema.
48
h) Caso de uso “Registrar préstamo”
Tabla 23: Caso de uso: "Registrar préstamo"
NOMBRE CASO DE USO Registrar préstamo
DESCRIPCIÓN Permite al encargado de laboratorio ingresar un

préstamo de recursos solicitado por un alumno.
ACTOR Encargado de laboratorio y alumno.
PRECONDICIONES: El encargado debe estar identificado en el sistema y el alumno debe poseer

una tarjeta universitaria inteligente (TUI).
FLUJO NORMAL:
1) El alumno solicita el préstamo de uno o más instancias de recursos.
2) El encargado selecciona una instancia del recurso que se encuentre en estado “DISPONIBLE”.
3) El sistema agrega la instancia a una lista llamada ‘Préstamo’
4) El encargado selecciona la opción de “Crear préstamo”
5) El sistema pide la verificación del alumno con su tarjeta TUI.
6) El encargado solicita la tarjeta del alumno y la coloca sobre el dispositivo verificador.
7) El sistema captura la información del alumno y verifica que el alumno pertenezca a la carrera.
8) El sistema despliega y rellena los campos con la siguiente información:
a) RUN
b) Nombres
c) Apellidos
9) El sistema despliega una ventana donde muestra los recursos requeridos por el alumno y
solicita que el encargado rellene el siguiente campo:
a) Laboratorio donde el alumno utilizará los recursos.
10) El encargado solicita la información al alumno y la ingresa al sistema.
11) El sistema verifica que el laboratorio esté registrado en el sistema.
12) El encargado presiona el botón “Realizar préstamo”.
13) El sistema muestra un mensaje señalando que el préstamo se realizó de forma correcta.
FLUJO ALTERNATIVO:
8) El sistema muestra un mensaje indicando que el alumno no pertenece a la carrera.
9) El sistema regresa al menú principal y elimina la lista ‘Préstamo’.
POSTCONDICIONES:
 Se ha ingresado un nuevo préstamo al sistema.
 Se cambia el estado de las instancias de recurso a “OCUPADO”
49
j) Caso de uso “Cargar archivo”
Tabla 24: Caso de uso: "Cargar archivo"
NOMBRE CASO DE USO Cargar archivo
DESCRIPCIÓN Permite al encargado realizar una carga masiva

de datos al sistema sobre un recurso.
PRECONDICIONES: El actor debe estar identificado en el sistema y se debe estar ejecutando el

caso de uso “Ingresar recurso”
FLUJO NORMAL:
1) El encargado selecciona la opción de cargar archivo.
2) El sistema abre una ventana donde el encargado deberá seleccionar el archivo.
3) El encargado selecciona el archivo con los datos y presiona aceptar.
4) El sistema verificará que el archivo siga la siguiente estructura
a) Nombre de recurso
b) Descripción
c) Categoría
d) Cantidad
5) El sistema muestra una tabla donde se puede previsualizar los datos.
6) El encargado selecciona la opción de “Aceptar”
7) El sistema muestra un mensaje de “Recurso creado de forma satisfactoria”.
FLUJO ALTERNATIVO:
5) El sistema muestra un mensaje de “Archivo no válido”.
POSTCONDICIONES: Se han ingresado recursos al sistema.
50
k) Caso de uso “Crear reserva”
Tabla 25: Caso de uso: "Crear reserva"
NOMBRE CASO DE USO Crear reserva
DESCRIPCIÓN Permite al encargado crear un reserva de una

instancia de un recurso.

FLUJO NORMAL:
1) El alumno solicita la reserva de uno o más instancias de recurso.
2) El encargado selecciona una instancia del recurso que se encuentre en estado
“DISPONIBLE”.
3) El sistema agrega la instancia a una lista llamada ‘Reserva’
4) El encargado selecciona la opción de “Crear reserva”
5) El sistema pide la verificación del alumno con su tarjeta TUI.
6) El encargado solicita la tarjeta del alumno y la coloca sobre el dispositivo verificador.
7) El sistema captura la información del alumno y verifica que el alumno pertenezca a la
carrera.
8) El sistema despliega y rellena los campos con la siguiente información:
a) RUN
b) Nombres
c) Apellidos
9) El sistema despliega una ventana donde muestra los recursos requeridos por el alumno y
solicita que el encargado rellene el siguiente campo:
a) Laboratorio donde el alumno utilizará el recurso.
b) Fecha en que utilizará el recurso. (YYYY-MM-DD HH:MM)
10) El encargado solicita la información al alumno y la ingresa al sistema.
11) El sistema verifica que el laboratorio esté registrado en el sistema.
12) El encargado presiona el botón “Registrar reserva”.
13) El sistema muestra un mensaje señalando que el préstamo se realizó de forma correcta y
la reserva queda en estado “PENDIENTE”.
FLUJO ALTERNATIVO:
8) El sistema muestra un mensaje indicando que el alumno no pertenece a la carrera.
9) El sistema regresa al menú principal y elimina la lista ‘Reserva’.
POSTCONDICIONES: Se ha ingresado una nueva reserva al sistema.
51
l) Caso de uso “Entregar reserva”

Tabla 26: Caso de uso: "Entregar reserva"
NOMBRE CASO DE USO Entregar reserva
DESCRIPCIÓN Permite al encargado entregar la instancia de

recurso que se encuentre reservada.

FLUJO NORMAL:
1) El alumno solicita el retiro de su reserva.
2) El encargado entra en el apartado de reserva.
3) El sistema muestra todas las reservas ingresadas al sistema.
4) El encargado pide el nombre del alumno y lo busca en el listado de reserva.
5) El encargado selecciona la reserva del alumno y solicita su tarjeta TUI.
6) El encargado coloca la tarjeta sobre el dispositivo verificador.
7) El sistema captura los datos del alumno, y verifica que el alumno que está solicitando
el retiro es el mismo que realizó la reserva.
8) El sistema muestra un mensaje de “Recurso entregado” y cambia el estado de la
instancia de recurso a “OCUPADO”.
9) El sistema cambia el estado de la reserva a “ENTREGADA”.
FLUJO ALTERNATIVO:
8) El sistema envía un mensaje “No es posible entregar el recurso”
POSTCONDICIONES: Se cambia el estado de una reserva a “ENTREGADA”.
52
m) Caso de uso “Retornar recurso”

Tabla 27: Caso de uso: "Retornar recurso"
NOMBRE CASO DE USO Retornar recurso
DESCRIPCIÓN Permite al encargado registrar cuando un

alumno devuelve un recurso.
ACTOR Encargado de laboratorio y alumno
de recursos.
FLUJO NORMAL:
1) El alumno entra al laboratorio con los recursos que desea regresar.
2) El encargado se dirige a la sección donde están los recursos en estado “OCUPADO”
3) El encargado selecciona la instancia de recurso que el alumno desea devolver.
4) El sistema actualiza el estado de las instancia de recurso a “DISPONIBLE” y actualiza el
historial de la instancia de recurso, modificando los campos:
a) Fecha de entrega
b) Nombre del encargado que recepcionó el préstamo
5) El sistema retorna un mensaje de “Operación realizada de forma exitosa”
FLUJO ALTERNATIVO:
No aplica
POSTCONDICIONES: Se alteró el estado de la instancia de recurso a “DISPONIBLE”.
53
n) Gestión de usuarios
Tabla 28: Caso de uso: "Gestión de recurso"
NOMBRE CASO DE USO Gestión de usuarios
DESCRIPCIÓN Permite al encargado del departamento agregar

usuarios al sistema.
ACTOR Encargado de departamento
de usuarios.
FLUJO NORMAL:
1) El encargado ingresa al apartado de gestión de usuarios del sistema.
2) El sistema despliega una lista con los usuarios del sistema.
3) El encargado selecciona la opción de “Agregar usuario”
4) El sistema despliega los campos de “RUN” y “Contraseña”
5) El encargado rellena los campos y confirma la acción.
FLUJO ALTERNATIVO:
No aplica
POSTCONDICIONES: Se agregó un nuevo usuario al sistema.
54
ñ) Gestión de permisos
Tabla 29: Caso de uso: "Gestión de permiso"
NOMBRE CASO DE USO Gestión de permisos
DESCRIPCIÓN Permite al encargado del departamento

modificar el estado de los usuarios del sistema.
ACTOR Encargado de departamento
de usuarios.
FLUJO NORMAL:
El encargado ingresa al apartado de gestión de usuarios del sistema.
1) El sistema despliega una lista con los usuarios del sistema.
2) El encargado selecciona la opción de “Agregar usuario”
3) El sistema despliega los campos de “RUN” y “Contraseña”
4) El encargado rellena los campos y confirma la acción.
FLUJO ALTERNATIVO:
3) El encargado selecciona a un usuario cuyo estado esa “ACTIVO”.
4) El sistema muestra la información asociada al usuario y presenta las opciones para
cambiar su estado.
5) El encargar selecciona la opción de “INACTIVO” y confirma la acción.
POSTCONDICIONES: Se cambió el estado de un usuario en el sistema.
55
3.4.3.1 Puntos de caso de uso

3.4.3.1.1 Puntos de caso de uso (UCP)
3.4.3.1.1.1 Puntos de caso de uso sin ajustar (UUCP)
Los puntos de casos de uso sin ajustar (UUCP) equivalen a la suma del peso de los
actores (AUW) y el peso de los casos de uso (UUCW). Se obtiene la siguiente fórmula:
UUCP = AUW + UUCW
3.4.3.1.1.1.1 Pesos de actores

El peso de los actores (AUW) se calcular en base de la siguiente tabla:
Tabla 30: Equivalencia de peso de actores
Actor Descripción Factor
Simple Otro sistema que interactúa con el sistema a 1

desarrollar mediante una API.
Medio Otro sistema interactuando a través de un 2

protocolo o una persona interactuando a través de
una interfaz en modo texto.
Complejo Una persona interactuando a través de una GUI o 3

desde una página WEB
Tabla 31: Peso de actores
Actor Tipo Factor
Encargado de laboratorio Complejo 3
Encargado de departamento Complejo 3
Alumno Simple 1
AUW 7
56
3.4.3.1.1.1.2 Pesos de caso de uso

El peso de caso de uso (UUCW) se calcula de acuerdo a la siguiente tabla:
Tabla 32: Equivalencia de casos de uso

Tipo de caso de uso Descripción Factor
Simple 3 transacciones o menos 5
Medio 4-7 transacciones 10
Complejo Más de 7 transacciones 15
Tabla 33: Peso de casos de uso
Caso de uso Tipo Factor
Login Medio 10
Ingresar recursos Medio 10
Modificar recurso Medio 10
Eliminar recursos Medio 10
Mostrar recursos Simple 5
Ingresar observación Medio 10
Mostrar observaciones Medio 10
Registrar préstamo Complejo 15
Mostrar historial Simple 5
Cargar archivo Medio 10
Crear reserva Complejo 15
Entregar reserva Complejo 15
Retornar recursos Medio 10
Gestión de usuarios Simple 5
Gestión de permisos Simple 5
UUCW 145
57
3.4.3.3.1.1.3 Total de puntos de caso de uso sin ajustar

Retornando a la formula descrita en el punto anterior, se obtiene el valor para los
casos de uso no ajustados (UUCP):
UUCP = AUW + UUCW

UUCP = 7 + 145
UUCP = 152
58
3.4.3.1.1.2 Puntos de caso de uso ajustados

Los puntos de caso de uso ajustados nos permiten obtener los factores de complejidad
técnico (TFactor) y el factor de complejidad ambiental (EFactor). Con estos valores
podremos calcular los pesos de factores técnicos (TCF) y el peso de factores
ambientales (EF).
3.4.3.1.1.2.1 Pesos de factores técnicos

El peso de factores técnicos se obtiene a partir de la siguiente fórmula:
TCF = 0.6 + (0.01 * TFactor)
El factor de complejidad técnico se calcula utilizando como referencia la siguiente
tabla:
Tabla 34: Equivalencia de complejidad técnica

Factor de complejidad técnico Valor
Irrelevante De 0 a 2
Medio De 3 a 4
Esencial 5
59
Tabla 35: Pesos de factores técnicos
Factor Descripción Peso Nivel Peso * Nivel
T1 Sistema distribuido. 2 4 8
T2 Objetivos de performance o tiempos de respuesta. 1 5 5
T3 Eficiencia del usuario final. 1 5 5
T4 Procesamiento interno complejo. 1 2 2
T5 El código debe ser reutilizable. 1 2 2
T6 Facilidad de instalación. 0.5 4 2
T7 Facilidad de uso. 0.5 4 2
T8 Portabilidad. 2 3 6
T9 Facilidad de cambio. 1 2 2
T10 Concurrencia. 1 2 2
T11 Incluye objetivos especiales de seguridad. 1 4 4
T12 Provee acceso directo a terceras partes. 1 0 0
T13 Se requiere facilidades de entrenamiento a usuario. 1 3 3
TFactor 43
60
Utilizando el TFactor calculado, el peso de los Factores Técnicos (TCF) del proyecto es
el siguiente:
TCF = 0.6 + (0.01*43)

TCF = 1.03
3.4.3.1.1.2.2 Pesos de factores ambientales

El peso de factores técnicos se obtiene a partir de la siguiente fórmula:
EF = 1.4 + (0.03 * EFactor)
El factor de complejidad ambiental se calcula utilizando como referencia la siguiente
tabla:
Tabla 36: Equivalencia de complejidad ambiental
Factor de complejidad ambiental Valor Factor de complejidad ambiental
Sin experiencia, De 0 a 2 Sin experiencia,
motivación,estabilidad, personal motivación,estabilidad, personal
Promedio 3 Promedio
Amplia experiencia, motivación, De 3 a 5 Amplia experiencia, motivación,
estabilidad, personal estabilidad, personal
Tabla 37: Peso de factores ambientales
Factor Descripción Peso Nivel Peso * Nivel
E1 Familiaridad con el modelo del proyecto utilizado. 1.5 3 4.5
E2 Experiencia en la aplicación 0.5 1 0,5
E3 Experiencia en orientación a objetos. 1 3 3
E4 Capacidad del analista líder. 0.5 3 1.5
E5 Motivación. 1 2 2
E6 Estabilidad de los requerimientos. 2 3 6
E7 Personal part-time. -1 0 0
E8 Dificultad del lenguaje de programación. -1 3 -3
EFactor 14.5
61
3.4.3.1.1.3 Total de puntos de caso de uso

Utilizando el EFactor calculado, el peso de los Factores Ambientales (EF) del proyecto
es el siguiente:
EF = 1.4 + (0.03 * 14.5)
EF = 1.835
Por lo tanto, en base a los cálculos realizados en los puntos anteriores, nuestro UCP es
el siguiente:
UCP = UUCP * TCF * EF
UCP = 152 * 1.03 * 1.835
UCP = 287.71
62
3.4.3.1.2 Esfuerzo Horas-Hombre

Finalmente, para completar el modelo de Karner, solo queda estimar la relación de
esfuerzo Horas-Hombre. Este factor se calcula utilizando la siguiente fórmula:
E = UCP * CF
Siguiendo la sugerencia de Gustav Karner, donde indica que el valor Horas-Hombre

debe ser de 20 horas (CF), y ya habiendo calculado el valor de los casos de uso
ajustado (UCP), se puede obtener el valor del esfuerzo estimado (E).
E = 262.71 * 20
E = 5254.2
De acuerdo a las primeras estimaciones realizadas en el informe, donde se contempla

que un empleado trabaje 40 horas semanales, se estima que una sola persona se
tardaría un total de 131.3 semanas en terminar el proyecto. Teniendo en cuenta que
este valor equivale al 40% del total de horas del proyecto, se determinará el resto a
partir de las actividades del proyecto, como se muestra en la siguiente tabla:
Tabla 38: Esfuerzo por etapa
Horas-Hombre total ((5254.2 * 100) / 40) = 13135.3
Actividad Porcentaje Horas-Hombre
Análisis 10% 1313.55
Diseño 20% 2627.06
Implementación 40% 5254.12
Pruebas 15% 1970.295
Sobrecarga 15% 1970.295
Total de esfuerzo 100% 13135.3
63
Utilizando los valores entregados en la anterior tabla, el proyecto tendrá una duración
total de 328.3 semanas sólo para una persona o 54.7 semanas para todos los miembros
del equipo (seis personas).
Tomando la cantidad total de horas-hombre y la cantidad a pagar a cada desarrollador

PHP en la empresa DEVELUTA es de $6.250 (CLP) la hora, se puede obtener que el
costo de desarrollo del proyecto será de:
Total Horas-Hombre * Costo por hora = $ 82.095.625 (CLP)
64
3.4.4 Tabla de costos vs beneficios proyectado en meses

La siguiente tabla presenta el desempeño de los beneficios contra los costos durante
el primer año de vida del proyecto.
Tabla 39: Beneficio proyectado por meses

MES 1 2 3 4 5 6 7 8 9 10 11 12
COSTO 12.92 10.55 10.55 10.55 - - - - - - - -
BENEFICIO - - - 5.54 5.54 5.54 5.54 5.54 5.54 5.54 5.54 5.54
TOTAL -12.92 -10.55 -10.55 -5.01 5.54 5.54 5.54 5.54 5.54 5.54 5.54 5.54
Como se puede ver, los primeros tres meses solo hay costos asociados al proyecto,
pero a partir del cuarto mes, el proyecto comienza a entregar beneficios, ya que se
espera que en ese mes se realice la última actividad de la carta Gantt, que
correspondería a la mantención del software, por lo que se da entender que el cliente
ya tendría en posesión la aplicación desarrollada.
65
3.5 Diagrama contextualizado del proyecto y organización del

desarrollo
3.5.1 Diagrama organizativo del proyecto
La organización de este proyecto será “Proyectizada”, donde el gerente de proyecto
tiene una alta autoridad y dedica casi todo su tiempo en el proyecto.
El siguiente diagrama corresponde al diagrama organizativo del presente proyecto:
Figura 10: Diagrama organizativo del proyecto
66
3.5.2 Diagrama organizativo del desarrollo de software

En la siguiente figura se aprecia el diagrama organizativo del desarrollo del software,
el cual contiene todas las etapas que se seguirán para la construcción del software.
Figura 11: Diagrama organizativo del desarrollo

de software
67
3.6 Mecanismo de comunicación y sus responsables

Para que el proyecto se puede realizar de forma correcta, es necesario definir los
mecanismos de comunicación y asignar a sus responsables. De esta manera los medios
a utilizar en el desarrollo del proyecto es:
3.6.1 Reuniones formales
Junta presencial de carácter formal en donde se tratarán temas relevantes al
proyecto, como el estado, discusión de dificultades, entre otros. Estas reuniones
deben ser agendadas con anticipación y se tomará registro de cada una de ellas.
Responsable: Iván Cardemil
3.6.2 Correo electrónico

Principal medio de multidifusión de información dentro de la organización del
proyecto donde se enviarán boletines. Además, los integrantes del equipo podrán
comunicarse directamente con el gerente y jefe de proyecto a través de este medio.
Responsable:
• Comunicados oficiales: Iván Cardemil
• Mensaje de otro carácter: La persona que lo envió
3.6.3 Llamadas IP
Alternativa a las reuniones formales. Este mecanismo es útil cuando se requiera
trabajar de forma remota. Estas reuniones, al igual que las que son de carácter
formal, estas deben ser agendadas con anticipación por el jefe de proyectos.
Responsable: Iván Cardemil
68
3.7 Riesgos
3.7.1 Tabla de riesgos del proyecto
A continuación, se muestran los riesgos que pueden ocurrir en el proyecto, en cual se
valora el impacto de cada riesgo y se establece una categoría de impacto. Estas
categorías son:
1 = Catastrófico, 2 = Crítico, 3 = Marginal, 4 = Despreciable
Los riesgos identificados están ordenados en función de la probabilidad y el impacto

quedando en la parte superior las de mayor probabilidad y mayor impacto.
Tabla 40: Tabla de riesgos del proyecto

ID Riesgo Categoría Probabilidad Impacto
R1 Interrupción del calendario académico Entorno de desarrollo 50% 3
R2 Falta de experiencia en las herramientas a Experiencia del recurso 25% 3
utilizar humano
R3 El cliente cambiará los requerimientos Riesgos con el cliente 35% 2
R4 Tiempo de desarrollo subestimado Tamaño del producto 25% 2
Línea de corte
R5 No hay herramientas disponibles Riesgos tecnológicos 10% 2
R6 Componentes defectuosos Riesgos tecnológicos 10% 2
R7 Problemas de comunicación entre el equipo Recursos humanos 10% 4
R8 Pérdida de un integrante del equipo Recursos humanos 5% 2
69
A continuación, se describirá cada riesgos es está sobre la línea de corte:

Tabla 41: Descripción de riesgos
ID Riesgo Descripción
R1 Interrupción del calendario académico Teniendo en cuenta que gran parte del trabajo
será desarrollado en la Universidad, la
interrupción del calendario puede afectar a la
carta Gantt.
R2 Falta de experiencia en las herramientas a utilizar Poca experiencia con la tecnología NFC.
R3 El cliente cambiará los requerimientos El cliente puede cambiar los requerimientos.
R4 Tiempo de desarrollo subestimado El tiempo asignado para el proyecto es menor que
el que realimente se necesita.
70
3.7.2 Reducción, supervisión y gestión del riesgo

Como siguiente paso del plan preventivo RSGR es necesario describir las acciones a
tomar para reducir, supervisar y gestionar los riesgos. Considerando los riesgos
presentado en la Tabla N°30 se realizará la identificación de las medidas a tomar para
cada uno:
R1 Interrupción del calendario académico:

a) Reducción
I. Estrategia general: Comunicarse de forma inmediata con el Gerente del
Proyecto.
II. Pasos específicos:
1. Mantener comunicación con el gerente del proyecto.
2. Mantener comunicación con el equipo de trabajo.
3. Identificar que tareas se pueden realizar de forma remota.
4. Re-agendar las actividades pendientes.
b) Supervisión
I. Factores a supervisar:
1. Evaluar las fechas donde se han realizado las últimas interrupciones del
calendario.
II. Enfoque de supervisión:
1. Agendar las actividades que lleven más tiempo realizar, antes de las
fechas descritas en el punto anterior.
c) Gestión
I. Plan de contingencia:
1. Establecer un plan de trabajo remoto y acordar nuevas fechas de las
actividades pendientes.
2. Puede que que los nuevos periodos sean más cortos, en comparación con
la planificación original.
71
R2 Falta de experiencia en las herramientas a utilizar:

a) Reducción
I. Estrategia general:
1. Estudiar la documentación relacionada a la herramienta y si el problema
persiste, cambiar de herramienta si es posible.
1. Buscar algún miembro que tenga experiencia en la herramienta
2. Buscar la documentación oficial de la herramienta.
3. Realizar pequeños ejercicios para entender el funcionamiento de la
herramienta.
4. Analizar si es posible cambiar la herramienta por una más accesible.
b) Supervisión
1. Evaluar el avance de la carta Gantt en aquellas actividades relacionadas
con el desarrollo del software.
2. La estabilidad de los módulos implementados.
1. Como fue descrito en el punto anterior, se pondrá el foco en el avance
de la carta Gantt.
c) Gestión
I. Plan de contingencia
1. En las etapas de previas a la ejecución del proyecto, realizar una ronda
con el equipo de desarrollo para definir cuales son las herramientas que
dominan de mejor forma.
2. Realizar un filtro más exigente a los aspirantes que desean formar parte
del equipo de desarrollo.
72
R3 El cliente cambiará los requerimientos:

a) Reducción
1. Estudiar y evaluar las actividades relacionadas al proyecto para
adecuarse a los nuevos requerimientos.
1. Realizar un balance del estado actual del proyecto, y verificar si este
satisface de algún modo a los nuevos requerimientos del cliente.
2. Realizar un análisis de impacto de los nuevos requerimientos.
3. Solicitar un prorroga de la entrega del software.
4. Modificar las actividades pendientes en función de los nuevos
requerimientos.
5. Calcular nuevamente el costo del software, agregando un “factor de
multa” al cliente por la interrupción del desarrollo.
b) Supervisión
1. Mantener comunicación con el cliente.
1. Poner énfasis en la conducta del cliente durante el ciclo de vida del
proyecto.
c) Gestión
1. Realizar reuniones con el cliente con el objetivo de aclarar dudas y
obtener retroalimentación inmediata.
73
R4 Tiempo de desarrollo subestimado

a) Reducción
1. Identificar los puntos críticos y modificar las tareas de los miembros del
equipo en función de estos.
1. Identificar las actividades que están fuera de plazo.
2. Realizar una lista con estas actividades, ordenándolas según su
importancia en el funcionamiento del software.
3. Diluir las actividades más pesadas en sub-actividades, y asignarlas a los
miembros del equipo que estén libres.
4. Realizar un nuevo ajuste a la carta Gantt, considerado las acciones del
punto anterior.
b) Supervisión
1. El avance de la carta Gantt.
1. Poner el foco en las actividades relacionadas al desarrollo del software,
como lo son el desarrollo de las funcionalidades o la integración de
módulos.
c) Gestión
1. Asignar más tiempo a aquellas tareas que requieren la implementación
del software.
74
R5 No hay herramientas disponibles

a) Reducción
1. Hablar con el Gerente del Proyecto para que realice una orden de
compra para adquirir las herramientas faltantes.
1. Realizar una lista de las herramientas que faltan.
2. Cotizar cada elemento de la lista.
3. Enviar la lista de precios al gerente del proyecto.
b) Supervisión
1. El plan de proyecto y la descripción de arquitectura.
1. En el avance de la carta Gantt y si este se ve afectada por la falta de
herramientas.
c) Gestión
1. El plan de proyecto es en si mismo un plan de contingencia.
R6 Componentes defectuosos
a) Reducción
1. Buscar si el componente se puede reemplazar.
1. Realizar una investigación de si el componente posee algún equivalente.
2. Identificar si el equipo de trabajo posee el componente equivalente.
3. En caso contrario, solicitar la compra del componente original al Gerente
del proyecto.
b) Supervisión
1. La correcta manipulación de aquello componentes que son más
delicados.
1. En la conducta de la persona que manipula los componentes.
c) Gestión
1. Restringir la manipulación de aquellos componentes más delicados a solo
algunos miembros del equipo.
2. Crear un lista con los equivalentes de los componentes.
3. En caso de no aumentar drásticamente el costo del proyecto, tener
componentes de reserva en caso de fallo.
75
R7 Problemas de comunicación entre el equipo

a) Reducción
1. Establecer una reunión para acordar nuevos canales de comunicación.
1. El jefe de proyecto deberá convocar a todos los miembros del equipo a
una reunión.
b) Supervisión
1. Los reportes entregados por los miembros del equipo.
2. El avance de la carta Gantt.
3. Quejas de los miembros.
1. Poner atención en el flujo de las entregas de los miembros del equipo.
c) Gestión
1. Generar un documento donde se específica cuales son los medios de
comunicación oficiales.
2. Habilitar una plataforma abierta donde los miembros del grupo puedan
interactuar y enviar sus informes.
R8 Pérdida de un integrante del equipo

a) Reducción
1. Realizar una nueva asignación de tareas de los integrantes del equipo.
1. Aquellas tareas actividades asignadas al miembro retirado serán
separadas en sub tareas.
2. Estas sub tareas serán asignadas al resto de miembros del equipo.
b) Supervisión
1. El comportamiento de los miembros del equipo.
2. Quejas de los miembros del equipo.
1. En aquel miembro que persiste en sus quejas.
c) Gestión
1. Generar actividades que permitan relajar el ambiente de trabajo.
2. Preocuparse del buen trato con los miembros del equipo.
3. Ofrecer incentivos para que no se tienten en abandonar el proyecto, en caso
que obtengan un mejor oferta laboral.
76
IV. CONCLUSIONES
Gracias a las distintas etapas que se debieron superar, el equipo logró descubrir a la
empresa que postulará el proyecto y a la empresa cliente.
Gracias a esta información, se logró tener una idea bastante concreta de cómo es el
funcionamiento, en teoría, del departamento de ingeniería de computación e
informática, ya que nos permite tener una aproximación de quienes son los
encargados de llevar a cabo sus procesos internos,cuáles son sus objetivos a mediano y
largo plazo, y los servicios que entrega.
De esta manera, el equipo de trabajo logró plantear las bases de una solución que se
haga cargo de los problemas descritos anteriormente, donde se describieron sus
características y funciones principales. Además, junto a la solución propuesta,
también se especificó como es que el equipo piensa abordar el proyecto, mencionando
las etapas del proyecto, describiendo procesos, métodos y la duración de cada uno.
Para finalizar, se describió la etapa de planificación, se logra abordar la importancia

de realizar la estimación del cálculo de los costos y beneficios de cualquier proyecto
que se quiera desarrollar. Esto se hace evidente al momento de realizar la
comparación entre los costos del proyecto, contra la proyección de sus beneficios.
77
V. REFERENCIAS BIBLIOGRÁFICAS
[1] Apuntes del curso Ingeniería de Software. Profesor Raúl Herrera.
[2] Proyectos de desarrollo de software (versión 1.0):Apuntes de clases. Profesor
Marco Villalobos Abarca.
[3] VI Estudio público de sueldos TIC en Chile. Pulso – IT Hunter. Año 2016
[4] Sueldos en la industria UX en Chile. Nelson Rodríguez. Año 2017.
VI. ANEXOS
Como anexos a este documento vendrán
1. El plan de calidad del software
2. Manual de usuario de ORGANILAB
3. Una copia del software llamada organilab3.zip
78

Informe Final DEVELUTA PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Informe Final DEVELUTA PDF

Caricato da

Copyright:

Formati disponibili

UNIVERSIDAD DE TARAPACÁ

FACULTAD UNIVERSITARIA DE INGENIERÍA

Departamento de Ingeniería en Computación e Informática

ETAPA FINAL: DEVELUTA

Autores: Iván Cardemil

Arica, Julio 17 de 2019

3.2.5.1 Características del producto..................................................26

De acuerdo a la investigación realizada y las reuniones sostenidas con diversos actores

Finalmente, el documento contiene el plan de como es que el equipo desea aborda el

Para dar con el problema, el equipo de trabajo se reunió con el encargado de

Con está información el equipo realizará la propuesta de implementar un software

2.2 Objetivo general

2.3 Objetivos específicos

Mantención: Además la empresa entrega un servicio de seguimiento y mantención

3.1.1.5 Factor Humano

Tabla 1: Factor humano DEVELUTA

José Vásquez Jefe de Unidad Financiera Encargado de realizar balances

Figura 1: Organigrama DEVELUTA

3.1.1.9 Servicios post venta

3.1.1.10 Infraestructura y tecnología de información

3.1.1.11 Unidades de producción

3.1.2 Descripción de la empresa dueña del proyecto

Esta aspiración estratégica de largo alcance implica:

Sus principales áreas de desarrollo son: la docencia de pregrado orientada a la

El 2007 la Universidad logra la acreditación institucional, otorgada por la Comisión

Por otra parte, la Universidad ofrece los siguientes servicios a la comunidad

3.1.2.5 Factor Humano

Contraloría Patricio Zapata Valenzuela -Ver los Asuntos legales de la

Registraduría Marlene Cisternas Riveros -Llevar un registro de los

Dirección de Gestión de Paulina Ortuño Fariña -Velar por la correcta

Figura 2: Organigrama Universidad de Tarapacá

3.1.2.8.1 Servicios post venta

3.1.2.8.2 Infraestructura y tecnología de información

Además, la Universidad posee la infraestructura de soporte tecnológico que permite

3.1.2.8.3 Unidades de producción

3.2 Definición del proyecto

Por esto surge la necesidad de crear un sistema de gestión de recursos organizado,

3.2.2 Por qué es importante abordar el proyecto

Con la implementación de la mejora, aumentará la comodidad de los clientes los

Desde el punto de vista de la organización del departamento, el proyecto permitirá

3.2.3 Requerimientos del Cliente/Usuario

 Obtener una experiencia de uso agradable para el usuario.

3.2.4 Requisitos elecitados

Tabla 3: Requisitos funcionales

3.2.4.2 Requisitos no funcionales

Tabla 4: Requisitos no funcionales

3.2.4.3 Restricciones del software

3.2.4.4 Diagrama de casos de uso para el sistema

Figura 3: Diagrama de caso de uso del sistema

3.2.5 Descripción del producto y proceso

Respecto a la herramientas utilizadas para desarrollar el software, se eligió laravel

En la siguiente figura se muestra el modelo de cómo es que funcionará el software a

Figura 4: Modelo del software, verificación de disponibilidad

Figura 5: Modelo de software, validación de datos de alumno

Del diagrama de casos de uso expuesto en el punto 3.2.4.4 se implementaron en el

Figura 6: Casos de uso implementados en el prototipo

3.2.5.1.2 Funcionalidades que ofrecerá (mapeadas a los requisitos)

Tabla 5: Funcionalidades del software

Función Descripción RFX

Permite el ingreso, retiro y actualización de información de recursos al

Cambia el estado de un recurso a “Ocupado” y lo enlaza a un alumno

Registrar Permite ingresar “notas” en caso de que un recurso necesite

Almacena la actividad asociada al recurso. Se profundiza en esta