FORMULACIÓN DEL PROYECTO InTLink

POR
NATALIA ARTEAGA LÓPEZ
CARLOS DELGADO CALVACHE
RICAR DONALDO PATIÑO

AL PROFESOR: EDUARDO
ROJAS PINEDA
UNIVERSIDAD DEL CAUCA

FACULTAD DE INGENIERIA ELECTRONICA Y TELECOMUNICACIONES

POPAYÁN, CAUCA.
OCTUBRE 2016.
 FORMULACIÓN DEL PROYECTO

1. PLANEACIÓN DE LA FORMULACIÓN DEL PROYECTO

1.1. Revisión de los compromisos establecidos como resultado de la fase anterior
Para asegurar el cumplimiento de las condiciones requeridas para iniciar la fase de
Formulación del Proyecto, en la fase del Estudio de Prefactibilidad se realizó la presentación con
todo el Equipo Humado del Proyecto, analizando los compromisos y resultados de esta
fase, además de realizar modificaciones pertinentes. Los subproductos esenciales de la
fase del Estudio de Prefactibilidad son las entradas requeridas para la fase de Formulación.

Declaración Inicial del Negocio

Lista de Características del Sistema
Modelo Inicial del Negocio
Modelo Inicial de Casos de Uso del Sistema
Arquitectura Inicial del Sistema
Lista Inicial de Riesgos
Lista de Priorización de Casos de Uso del Sistema
Plan Inicial del Proyecto
Caso Inicial del Negocio

1.2 Elaboración del Plan de Trabajo para el Formulación del Proyecto

Se define la organización de las actividades requeridas para realizar la fase de Formulación del
Proyecto y establecer la organización del personal involucrado.
1. Cronograma: Actividades a realizar y duración estimada
Esfuerzo Días de trabajo
Duración
Id Actividades (Horas x
(Horas) 12 17 19 24 26 31 02
Persona)
oct oct oct oct oct oct nov
1.1 Revisión de los compromisos establecidos
1
4.5 1.5
como resultado de la fase anterior
1.2 Elaboración del Plan de Trabajo para el
2 1.5 0.5
Formulación del Proyecto
1.3 Establecimiento de los Criterios de
3 3 1
Evaluación
2.1 Extensión del Modelo Inicial de Casos de
4 3 1
Uso del Servicio
2.2 Elaboración del Modelo Esencial de
5 3 1
Análisis del Servicio
2.3 Descripción de la Arquitectura de
6 3 1
Referencia para el Servicio
 2.4 Actualización del Modelo Inicial del
7 1.5 0.5
Negocio
8 3.1 Lista de Riesgos 4.5 1.5
4.1 Actualización de los recursos requeridos
9 1.5 0.5
para la construcción del servicio.
4.2 Actualización del cronograma inicial
10 1.5 0.5
establecido para el Proyecto
5.1 Evaluación de los subproductos
11 6 2
elaborados
12 5.2 Actualización del Caso Inicial del Negocio 3 1

13 Presentación de la Formulación del Proyecto 6 2

Total 42 horas 14 horas 7 días

2. Asignación de responsabilidades

Nombre de la persona Rol que desempeña Responsabilidades

Natalia Arteaga López Arquitecta del sistema Procesar las peticiones grupales.
Control de cambios de la configuración del
sistema.
Gestión de recursos y riesgos.
Desarrollo software del sistema solución.
Carlos Delgado Calvache Ingeniero de casos de uso Control de calidad del sistema
Ingeniero de requisitos Diseño de la arquitectura del sistema
Descripción y desarrollo de casos de uso
del sistema.
Desarrollo software del sistema solución
Ricar Patiño Delgado Analista del sistema Control de actividades y cronograma.
Organización y comunicación del equipo.
Control de criterios de evaluación.
Desarrollo software del sistema solución.
Ing. Eduardo Rojas Asesor, docente del curso Asesoría y soporte en el desarrollo del
proyecto.
Evaluación de los avances realizados por el
grupo de desarrollo.

4. Descripción de los recursos requeridos y las respectivas ventanas de disponibilidad

Los siguientes recursos se encuentran disponibles totalmente para esta fase:

Instalaciones:

Sala de Énfasis 334. Disponibilidad 16 horas semanales, promedio de uso 4 horas

semanales.
Hardware:

Préstamo de computadores con conexión a Internet en las salas de computación FIET.

Préstamo de computadores personales.

Software:

Recursos ofimáticos (Microsoft: Word, Excel, Power Point) (préstamo Universidad).

StarUML 2

5. Estimación de los costos de realización de la fase de Formulación del Proyecto

Recursos Humanos
Nombre Tiempo total c/u Puntos por hora Valor del punto c/u TOTAL
(Horas)

Integrantes grupo (3) 14 1,5 12.939 815.157

Asesores (2) 5 2,5 12.939 323.475

Recursos Hardware

Equipo Costo Cantidad Horas Costo de uso

Equipo (computador 1) 1.485.200 1 12 678
Equipo (computador 2) 1.000.000 1 12 456
Recursos computacionales y laboratorios 110.657 - - 110.657
Recursos ofimáticos (Licencia gratuita) 0 0

Costo total: $ 1.250.423 pesos

1.3 Establecimiento de los Criterios de Evaluación

Se define el conjunto de aspectos fundamentales que debe obtener evaluación satisfactoria para
poder dar por terminado la fase de Formulación del Proyecto.

Los criterios iniciales de evaluación para la fase de Formulación del Proyecto, basados en 4 temas
importantes para el Proyecto los cuales son requisitos, arquitectura, riesgos y caso del negocio.
Lista de comprobaciones:

CRITERIOS DE EVALUACIÓN
Especificación adecuada de requerimientos
1. ¿Se han identificado los requerimientos, los actores y los casos de uso del sistema telemático
requeridos para diseñar la línea de base de la arquitectura del sistema, identificar los riesgos
significativos y soportar el caso del negocio y el contrato?
2. ¿Se han detallado lo suficiente los requerimientos como para satisfacer los objetivos de esta
fase?
3. ¿Se tiene un Modelo de Casos de Uso del sistema suficiente y
convenientemente estructurado?
4. ¿Se tiene un Modelo Esencial de Análisis del Sistema Telemático apropiado?
Establecimiento de una adecuada línea de base para la arquitectura
1. ¿Satisface la línea de base de la arquitectura no sólo los requerimientos formalmente
capturados, sino también las futuras necesidades del cliente y/o usuarios?
2. ¿Es la línea de base de la arquitectura lo suficientemente robusta como para soportar
la construcción del sistema telemático y la adición de las características que se requieran
en futuras versiones del mismo?
Mitigación de los riesgos críticos
1. ¿Se han mitigado adecuadamente los riesgos críticos, esto es, se han eliminado o se
ha elaborado un plan de contingencia?
2. ¿Se han identificado todos los riesgos significativos?
3. ¿Se han analizado los riesgos significativos a tal punto que se los considera manejables?
4. ¿Son los riesgos significativos que están aún en la lista de riesgos, susceptibles de controlarse
fácilmente en la fase de Ejecución del Proyecto?
Favorabilidad del caso de negocio
1. ¿Está el proyecto suficientemente bien definido en cuanto a precio del contrato, cronograma
y calidad del sistema telemático a construir?
2. ¿Indica el caso del negocio un retorno de inversión satisfactorio para el Cliente?
3. ¿Estamos listos para comprometernos con un contrato de precio fijo?

Complementario: Lista de comprobaciones

Entidades bajo Gestión de Configuración:

Entidad Descripción Acción

Documento Plan de trabajo para la etapa formulación del proyecto Creación
Lista Criterios de evaluación Creación
Documento Plan de Gestión de Configuración Actualización
Modelo Modelo de casos de uso del sistema Actualización
Modelo Modelo esencial de análisis del sistema Creación
Modelo Modelo del negocio Actualización
Lista Requerimientos no funcionales Actualización
Lista Riesgos del proyecto Actualización
Documento Plan de trabajo para el Proyecto Actualización
Documento Caso del negocio Actualización
Presentación Formulación del proyecto Creación
Asignación de Responsabilidades de gestión:

Comité de control de cambios (CCC): está conformado por el Ing. Eduardo Rojas (Asesor del
proyecto y docente) y la estudiante Natalia Arteaga (parte del equipo de desarrollo)
encargada de procesar las peticiones grupales; están encargados de la evaluación y control
y cambios de la configuración del sistema.
Administrador de configuración (AC): el integrante del equipo Carlos Delgado, encargado de
controlar la calidad de la configuración del sistema.
Administrador de desarrollo (AD): el integrante del equipo Ricar Patiño, encargado de
llevar el control de las actividades del proyecto.
Equipo Desarrolladores del sistema (EDS): integrantes del equipo de trabajo.

Políticas para la gestión y control de versiones:

Las dificultades encontradas en el desarrollo del sistema, descritas por el AC y AD

son evaluadas en el EDS.
Los cambios requeridos en el desarrollo del sistema deben ser descritos en la gestión de
configuración y evaluados por el EDS y mediante el CCC se toman las decisiones
oportunas.
Los nuevos cambios deben ser considerados en actividades por el EDS y controlados luego
por el AD.
Se manejan dos tipos de modificaciones: las versiones y las revisiones de los documentos,
denotadas así: <documento >_v.r. Las versiones inician desde 1 y aumentan de igual
forma. Las revisiones inician desde 0 y aumentan de 1 en 1.
La gestión de las pruebas de funcionalidad (módulos) y versiones del sistema (módulos
unidos), están a cargo del AC, esto mediante etiquetas. Para prueba de funcionalidad:
prueba_<módulo>_1.r. Para versión del sistema: sistema_1.r. NOTA: si hay un cambio de
elementos en un módulo, se tomaría la etiqueta 2.r, y así sucesivamente.
Los documentos, listas y modelos tendrán versiones, para esto, se nota el nombre con:
<tipo documentación>_1.r.
Las revisiones que requieran del aporte separado de los integrantes, se notarán al final de
cada nombre adicionando la revisión anterior y la nueva, utilizando las letras N,C,R
correspondientes a los nombres de los integrantes. La notación será así:
<documento>_v.r_N_R, donde la revisión anterior es la de Natalia y la nueva
revisión modificada es la de Ricar. La notación numérica es igual para todo documento.
2. DEFINICIÓN DE UNA ARQUITECTURA DE REFERENCIA PARA EL SISTEMA
2.1 Extensión Del Modelo Inicial De Casos De Uso Del Servicio

Se identificaron nuevos casos de uso necesarios para un proceso de préstamos más interactivo y
conveniente para los clientes, también la necesidad de buscar préstamos y elementos por parte del
administrador, estos se presentan y explican en las siguientes secciones.

Diagrama de casos de uso del sistema

Lista De Casos De Uso Esenciales Para El Sistema Telemático

Solicitar Préstamo: Representa una funcionalidad critica al ser el caso de uso que le permite
al cliente buscar un elemento, solicitar su préstamo, y que el registro de este se lleve de
forma segura y fácil de supervisar por parte del administrador.

Gestionar Elemento: Representa una funcionalidad arquitecturalmente significativa ya que es el

caso de uso que presenta la interfaz al administrador que le permitirá dirigirse a los diferentes
casos de uso relacionados la gestión de los elementos.

Agregar Elemento: Se considera que su funcionalidad es crítica porque es una de las bases
del sistema, al permitir al administrador ingresar nuevos elementos a la base de datos.

Modificar Elemento: Existe la necesidad de poder modificar los elementos que se encuentran en la
base de datos por esta razón es un funcionalidad critica el poder realizar estos cambios, este caso
de uso le permite al administrador mediante una interfaz modificar los datos registrados
previamente de algún elemento
Gestionar Préstamo: Representa una funcionalidad arquitecturalmente significativa ya que es el
caso de uso que presenta la interfaz al administrador que le permitirá dirigirse a los diferentes
casos de uso relacionados la gestión de los préstamos.

Agregar Préstamo: Es el caso de uso que se encarga de mostrar al administrador las solicitudes de
préstamos y donde el puede decidir si aceptarlas o no, por esta razón representa una
funcionalidad crítica.

Modificar Préstamo: Su funcionalidad es crítica porque en este caso de uso el administrador puede
cambiar el estado de un préstamo para poder indicar que los elementos prestados se regresaron o
registrar cualquier eventualidad después del realizado el préstamo.

Ver Contenido del Carrito: Es fundamental que el cliente tenga la posibilidad de visualizar los
elementos que tiene en su Carrito para tomar decisiones a partir de ello, este caso de uso
lo permite por eso es una funcionalidad critica del sistema.

2.1.2 Descripción De Los Escenarios De Los Casos De Uso Esenciales Del Sistema Telemático

Caso de Uso N.º 1 Solicitar Préstamo

Iniciador Cliente
Propósito Solicitar uno o varios elementos para un préstamo interno
Precondiciones El elemento es solicitado después de ser buscado
Los elementos son solicitados desde el Carro
Escenarios

Actor(es)
2. El cliente ingresa los datos del elemento
que desea buscar
4. El cliente visualiza el elemento y puede decidir 5.Según la elección del cliente el sistema hace
entre las opciones:
4.1. El cliente elije “agregar al carro”
4.2. El cliente busca otro objeto
Sistema
1. El sistema le presenta al cliente la interfaz
que le permite buscar un elemento y solicitar
préstamo, según lo elegido por el cliente el
sistema se dirige a un paso:
1.1. Buscar elemento: lo envía al paso 2
1.2. Solicita Préstamo: lo envía al paso 6
3. El sistema busca el elemento y le muestra la
información al cliente junto con la opción de
“agregar al carro”
lo siguiente:
5.2. Agrega el elemento al carro (lista de
objetos a solicitar)
5.3. El sistema regresa al paso 2
6. El sistema le muestra al cliente la lista en el
carro y las opciones de confirmar o cancelar,
según la elección del cliente el sistema hace lo
siguiente:
6.1. Confirmar, el sistema envía la solicitud de
 préstamo
6.2. Cancelar: El sistema regresa al paso 1
Poscondiciones La solicitud del préstamo enviada y agregada a la lista de solicitud de
préstamos.
Flujos Alternativos
Actor(es) Sistema
En 6 si no existen elementos en la lista se le
informa al Cliente
En 3 el sistema puede no encontrar el elemento
en este caso se le informa al cliente.
En 5 puede existir un error al momento de
agregar el elemento al carro, esto es informado
al cliente.
Excepciones
Actor(es) Sistema
Fallo en la conexión con la base de datos
Fallo en la conexión con el servidor
Interfaces de Usuario
Relacionadas

Caso de Uso N.º 2 Gestionar Elemento

Iniciador Administrador
Propósito Gestionar los elementos del laboratorio
Precondiciones -
Escenarios

Actor(es) Sistema
1. El sistema le presenta al administrador la
interfaz para gestionar elemento.
2. El administrador decide entre las opciones 3.Según la elección del administrador el sistema
“Agregar Elemento”, ”Eliminar Elemento” o lo envía a un determinado caso de uso:
“Modificar elemento”
2.1. El administrador elije “Agregar Elemento” 3.1. El sistema lo envía al caso de uso Agregar
Elemento
2.2. El administrador elije “Eliminar Elemento” 3.2. El sistema lo envía al caso de uso Eliminar
Elemento
2.3, El administrador elije “Modificar Elemento” 3.3. El sistema lo envía al caso de uso Modificar
Elemento
Poscondiciones Cliente con la posibilidad de agregar elemento
Cliente con la posibilidad de modificar elemento
Cliente con la posibilidad de eliminar elemento
Flujos Alternativos
Actor(es) Sistema

Excepciones
Actor(es) Sistema
Fallo en la conexión con la base de datos
Fallo en la conexión con el servidor
Interfaces de Usuario IUGestion_Elemento(Le permite al administrador elegir entre las
Relacionadas opciones de agregar, modificar y eliminar elemento )

Caso de Uso N.º 3 Agregar Elemento

Iniciador Administrador
Propósito Agregar un elemento a la base de datos
Precondiciones -
Escenarios

Actor(es)
2. El administrador ingresa los datos del
elemento que desea agregar
Sistema
1. El sistema le presenta al administrador la
interfaz para agregar un elemento.
3. El sistema captura los datos y los guarda en la
base de datos
4. El sistema le informa al administrador que el
elemento fue guardado con éxito

Poscondiciones Un elemento agregado a la base de datos

Flujos Alternativos
Actor(es) Sistema
En 3 algún dato puede ser incorrecto, se le
informa al administrador de este error
En 3 puede existir un error al guardar los datos
en la base de datos, se le notifica de esto al
administrador.
Excepciones
 Actor(es) Sistema
Fallo en la conexión con la base de datos
Fallo en la conexión con el servidor
Interfaces de Usuario IUAgregar_Elemento (Le presenta al administrador el formulario donde
Relacionadas se ingresan los datos del elemento que se desea agregar)

Caso de Uso N.º 4 Modificar Elemento

Iniciador Administrador
Propósito Modificar un elemento de la base de datos
Precondiciones Que exista al menos un elemento en la base de datos
Escenarios

Actor(es) Sistema
1. El sistema le presenta al administrador la
interfaz para modificar un elemento.
2. El administrador busca el elemento que 3. El sistema le proporciona al administrador un
desea modificar o lo elije buscando en la lista de formulario con la información actual del
elementos que se encuentran en la base de elemento.
datos
4. El administrador modifica los datos del 4. El sistema modifica los datos del elemento en
elemento la base de datos.

5.El sistema le informa al administrador que el

cambio fue realizado con éxito

Poscondiciones Un elemento modificado en la base de datos

Flujos Alternativos
Actor(es) Sistema
En 4 algún dato puede ser incorrecto, se le
informa al administrador de este error
En 4 puede existir un error al modificar los datos
en la base de datos, se le notifica de esto al
administrador.
Excepciones
Actor(es) Sistema
Fallo en la conexión con la base de datos
Fallo en la conexión con el servidor
Interfaces de Usuario IUModificar_Elemento (Le presenta al administrador el formulario
Relacionadas donde están y puede cambiar los del datos del elemento que se desea
modificar)

Caso de Uso N.º 5 Gestionar Préstamo

Iniciador Administrador
Propósito Gestionar los préstamos internos del laboratorio
Precondiciones -
Escenarios

Actor(es) Sistema
1. El sistema le presenta al administrador la
interfaz para gestionar préstamo.
2. El administrador decide entre las opciones 3.Según la elección del administrador el sistema
“Agregar Préstamo”, ”Eliminar Préstamo” o lo envía a un determinado caso de uso:
“Modificar Préstamo”
2.1. El administrador elije “Agregar Préstamo” 3.1. El sistema lo envía al caso de uso Agregar
Préstamo
2.2. El administrador elije “Eliminar Préstamo” 3.2. El sistema lo envía al caso de uso Eliminar
Préstamo
2.3, El administrador elije “Modificar Préstamo” 3.3. El sistema lo envía al caso de uso Modificar
Préstamo
Poscondiciones Cliente con la posibilidad de agregar préstamo
Cliente con la posibilidad de modificar préstamo
Cliente con la posibilidad de eliminar préstamo
Flujos Alternativos
Actor(es) Sistema

Excepciones
Actor(es) Sistema
Fallo en la conexión con la base de datos
Fallo en la conexión con el servidor
Interfaces de Usuario IUGestion_Prestamo (Le permite al administrador elegir entre las
Relacionadas opciones de agregar, modificar y eliminar prestamo)
Caso de Uso N.º 6 Agregar Préstamo
Iniciador Administrador
Propósito Agregar un préstamo a la base de datos
Precondiciones -
Escenarios

Actor(es)
3. El administrador elije el préstamo que desea
agregar (prestar los elementos solicitados)
Sistema
1. El sistema le presenta al administrador la
interfaz para agregar un préstamo.
2. El sistema muestra al administrador las
solicitudes pendientes de préstamos
4. El sistema agrega el préstamo y le informa al
cliente que su solicitud fue aceptada
5. El sistema le informa al administrador que el
préstamo fue agregado exitosamente

Poscondiciones Un préstamo agregado a la base de datos

Flujos Alternativos
Actor(es) Sistema
En 4 puede que alguno o todos los elementos
solicitados no se encuentren disponibles en ese
momento, esto se le informara tanto al cliente
como al administrador
En 4 puede existir un error al guardar el
préstamo en la base de datos, se le notifica de
esto al administrador.
Excepciones
Actor(es) Sistema
Fallo en la conexión con la base de datos
Fallo en la conexión con el servidor
Interfaces de Usuario IUSolicitudes_de_Prestamo (Le permite al administrador seleccionar
Relacionadas una de las solicitudes de prestamo)
IUAgregar_Prestamo (Le presenta al administrador la información de la
solicitud y le permite agregar o no dicho prestamo)
Caso de Uso N.º 7 Modificar Préstamo
Iniciador Administrador
Propósito Modificar un préstamo de la base de datos
Precondiciones Que exista al menos un préstamo en la base de datos
Escenarios

Actor(es) Sistema
1. El sistema le presenta al administrador la
interfaz para modificar un préstamo.
2. El administrador busca el préstamo que desea 3. El sistema le proporciona al administrador un
modificar o lo elije buscando en la lista de formulario con la información actual del
préstamos que se encuentran en la base de préstamo.
datos
4. El administrador modifica los datos del 4. El sistema modifica los datos del préstamo en
préstamo la base de datos.

5.El sistema le informa al administrador que el

cambio fue realizado con éxito

Poscondiciones Un préstamo modificado en la base de datos

Flujos Alternativos
Actor(es) Sistema
En 4 algún dato puede ser incorrecto, se le
informa al administrador de este error
En 4 puede existir un error al modificar los datos
en la base de datos, se le notifica de esto al
administrador.
Excepciones
Actor(es) Sistema
Fallo en la conexión con la base de datos
Fallo en la conexión con el servidor
Interfaces de Usuario IUModificar_Prestamo (Le presenta al administrador el formulario
Relacionadas donde están y puede cambiar los del datos del prestamo que se desea
modificar)
Caso de Uso N.º 8 Ver Contenido del Carro
Iniciador Cliente
Propósito Ver el contenido que tiene el carro con la lista de elementos que se desea
solicitar
Precondiciones
Escenarios

Actor(es)
2.El cliente puede elegir entre:
2.1. Eliminar algún elemento del carro
2.3. Regresar a Solicitar Préstamo
Sistema
1. El sistema le muestra al cliente la interfaz con la
lista de elementos
3.Según la elección del Cliente el sistema realiza las
siguientes acciones:
3.1. El sistema borra el elemento del carro y le
informa al cliente el éxito de esta operación,
3.3. El sistema lo envía al menú principal

Poscondiciones Un posible elemento menos en el carro

Una posible solicitud de préstamo enviada
Flujos Alternativos
Actor(es) Sistema
En 3.1 puede existir un problema al eliminar el
elemento, el sistema le informa al cliente.
En 1 si no existen elementos el sistema le informa
esto al cliente
Excepciones
Actor(es) Sistema
Fallo en la conexión con la base de datos
Fallo en la conexión con el servidor
Interfaces de Usuario
Relacionadas

Casos De Uso No Funcionales

1. Funcionamiento en horas de atención

Tipo descripción Disponibilidad
Descripción La aplicación debe estar disponible en los horarios de atención de los
laboratorios.
2. Baja complejidad de manejo
Tipo descripción Interfaz de usuario
Descripción La interfaz de usuario debe tener un manejo poco completo el cual permita
mejorar el control sobre las salas y no hacerlo más complicado para los
laboratoristas.

3. Adaptarse a los recursos del Hosting

Tipo descripción Implementación
Descripción El motor de base de datos es MySQL y el lenguaje de programación HTML y
PHP

2.2 Elaboración Del Modelo Esencial De Análisis Del Sistema Telemático

Diagrama de paquetes del servicio

Relación de clases de análisis contenidas en los paquetes

Datos

SolicitudPrestamo
Elemento
Prestamo

Usuarios
Cliente
Administrador
ControlSolicitud

IUSolicitudPrestamo
IUMostrarContenido
GestorSolicitudPrestamo
 ControlCarro

IUCarro
IUVerCarro
IUAgregarElementoAlCarro
GestorCarro
DatosCarro
ControlPrestamo

IUAgregarPrestamo
IUModificarPrestamo
IUMostrarSolicitud
IUPrestamoModificado
GestorAgregarPrestamo
GestorModificarPrestamo

ControlElemento

IUAgregarElemento
IUElementoAgregado
IUModificarElemento
IUElementoModificado
GestorAgregarElemento
GestorModificarElemento

Documento de análisis para casos de uso esenciales

Descripción de las clases de análisis identificadas

Clases tipo entidad

Nombre de la Clase SolicitudPrestamo

Tipo Entidad
Responsabilidades Esta clase es responsable de modelar la información relacionada con las
solicitudes de préstamo por parte de los clientes hacia el administrador.
Esta información esta descrita a través de propiedades tales como la
identificación del préstamo, el cliente que lo solicita, los elementos que
se solicitan, hora de solicitud y estado de la solicitud.
Nombre de la Clase Prestamo
Tipo Entidad
Responsabilidades Esta clase es responsable de modelar la información relacionada con los
prestamos realizados por el administrador. Esta información esta descrita
a través de propiedades tales como la identificación del préstamo,, el
cliente que la solicito, el administrador que realizo el préstamo, los
elementos que se solicitan, la fecha del préstamo y el estado del
préstamo.

Nombre de la Clase Elemento

Tipo Entidad
Responsabilidades Esta clase es responsable de modelar la información relacionada con los
elementos del laboratorio. Esta información esta descrita a través de
propiedades tales como identificación del elemento, nombre del
elemento, foto del elemento y cantidad.

Nombre de la Clase Cliente

Tipo Entidad
Responsabilidades Esta clase es responsable de modelar la información relacionada con los
clientes del sistema. Es responsable de guardar datos personales como el
correo electrónico y el nombre. Esta clase solo existe temporalmente
mientras dure la navegación

Nombre de la Clase Administrador

Tipo Entidad
Responsabilidades Esta clase es responsable de modelar la información relacionada con los
administradores del sistema. Guarda información como nombre, correo
electrónico, teléfono, dirección
 Clases tipo control

Nombre de la Clase GestorSolicitudPrestamo

Tipo Control
Responsabilidades Se encarga de buscar el elemento con la información suministrada por el
cliente, posteriormente de enviar ese resultado a la interfaz
IUSolicitarPrestamo, también es el responsable por agregar un elemento
al contenido del carro, y de crear una solicitud de préstamo cuando el
cliente confirme que el contenido del carro es lo que desea solicitar.

Nombre de la Clase GestorCarro

Tipo Control
Responsabilidades Cuando el usuario ingresa a IUCarro se encarga de consultar el contenido
de que tiene DatosCarro para posteriormente buscar los elementos y
crear una interfaz de usuario IUVerCarro que mostrara los elementos al
Cliente.
Al recibir información de alguna modificación se encarga de actualizar el
contenido del carro.

Nombre de la Clase GestorAgregarElemento

Tipo Control
Responsabilidades Es el responsable de con la informacion que le envia la interfaz
IUAgregarElemento crear un nuevo elemento en la base de datos y
activar la interfaz IUElementoAgregado para mostrar el resultado al
administrador.

Nombre de la Clase GestorModificarElemento

Tipo Control
Responsabilidades Es el responsable de buscar el elemento, crear la interfaz que le muestra
al administrador los datos del elemento y al recibir los datos modificados
guardar los cambios en la base de datos.

Nombre de la Clase GestorAgregarPrestamo

Tipo Control
Responsabilidades Se encarga de consultar las solicitudes de préstamo y mostrarlas al
administrador activando la interfaz IUMostrarSolicitud, al recibir una
respuesta se encarga de crear un Préstamo
Nombre de la Clase GestorModificarPrestamo
Tipo Control
Responsabilidades Es el responsable de buscar el préstamo. crear la interfaz que le muestra
al administrador los datos del préstamo y al recibir los datos modificados
guardar los cambios en la base de datos.

Clases tipo interfaz

Nombre de la Clase IUSolicitarPrestamo

Tipo Interfaz
Responsabilidades Es la clase que abstrae la interfaz de usuario donde se le muestra el
formulario donde puede ingresar los datos del elemento que desea
solicitar, posteriormente con el resultado de la búsqueda es quien le
muestra al cliente el resultado y captura la decisión de agregar al carro o
solicitar préstamo

Nombre de la Clase IUVerContenidoCarro

Tipo Interfaz
Responsabilidades Es la clase que abstrae la interfaz de usuario que contiene los datos de
los elementos almacenados en el carro, cada elemento tiene la opción de
eliminar del carro

Nombre de la Clase IUCarro

Tipo Interfaz
Responsabilidades Es la clase que abstrae la interfaz de usuario que contiene los elementos
que el cliente ha adicionado al carro. Contiene un enlace para Ver el
Contenido del Carro

Nombre de la Clase IUAgregarElemento

Tipo Interfaz
Responsabilidades Es la clase que abstrae la interfaz de usuario que contiene el formulario
que el administrador usa para agregar un elemento a la base de datos.
Nombre de la Clase IUElementoAgregado
Tipo Interfaz
Responsabilidades Es la clase que abstrae la interfaz de usuario que muestra al
administrador que el proceso de agregar un elemento fue finalizado.

Nombre de la Clase IUModificarElemento

Tipo Interfaz
Responsabilidades Es la clase que abstrae la interfaz de usuario que contiene el campo
donde el administrador puede ingresar la información del elemento que
desea modificar.

Nombre de la Clase IUElementoModificar

Tipo Interfaz
Responsabilidades Es la clase que abstrae la interfaz de usuario que contiene los datos del
elemento que se desea modificar, estos datos se presentan en campos
que el administrador puede cambiar.

Nombre de la Clase IUAgregarPrestamo

Tipo Interfaz
Responsabilidades Es la clase que abstrae la interfaz de usuario donde se presenta la lista de
solicitudes de prestamos en donde el administrador puede elegir alguna
de ellas para realizar el proceso de agregar préstamo

Nombre de la Clase IUMostrarSolicitud

Tipo Interfaz
Responsabilidades Es la clase que abstrae la interfaz de usuario que le muestra al
administrador la información de la solicitud de préstamo y donde él
puede decidir si aceptarla o no.

Nombre de la Clase IUModificarPrestamo

Tipo Interfaz
Responsabilidades Es la clase que abstrae la interfaz de usuario que contiene el campo
donde el administrador puede ingresar la información del préstamo que
desea modificar.
Nombre de la Clase IUPrestamoModificar
Tipo Interfaz
Responsabilidades Es la clase que abstrae la interfaz de usuario que contiene los datos del
préstamo que se desea modificar, estos datos se presentan en campos
que el administrador puede cambiar.

Diagramas de Colaboración para los Casos de Uso esenciales

Solicitar Préstamo
Ver Contenido del Carro

Agregar Elemento
 Modificar Elemento

Agregar Préstamo
Modificar Préstamo

2.3 Descripción de la Arquitectura de referencia para el Servicio

Descripción Inicial de las Clases de diseño

Cliente

Atributos Operaciones
Nombre Tipo de Nombre Descripción
Dato

Nombre String OptenerDatos Retorna los datos del cliente

CorreoElectronico String
Administrador

Atributos Operaciones
Nombre Tipo de Nombre Descripción
Dato

Nombre String ObtenerDatos Retorna los datos del administrador

CorreoElectronico String
Telefeno String

Direccion String

Elemento

Atributos Operaciones
Nombre Tipo de Dato Nombre Descripción
Id_Elemento Int ObtenerDatos Retorna los datos del Elemento
Nombre String
Foto String

Cantidad int

Prestamo

Atributos Operaciones
Nombre Tipo de Dato Nombre Descripción
Id_Prestamo int ObtenerDatos Retorna los datos del prestamo
Correo_Cliente String
Admin_Encargado String

Id_Elemento int

Fecha_Prestamo date

Estado_Prestamo Int
SolicitudPrestamo

Atributos Operaciones
Nombre Tipo de Dato Nombre Descripción
Id_Soli_Prestamo int ObtenerDatos Retorna los datos de la Solictud de
prestamo
Correo_Cliente_Soli String
Id_Elemento int

Fecha_Soli date

Estado_Soli Int

Modelo inicial de despliegue:

2.4 Actualización del Modelo Inicial de Negocios

Modelo De Casos De Uso Del Negocio

Elaboración Del Modelo De Objetos Del Negocio

Caso del Negocio Nº.1 Realizar Préstamo

Iniciador Cliente
Propósito Realizar un prestado solicitado por un cliente.
Resumen El cliente le solicita al administrador el préstamo de uno o varios
elementos, el administrador los busca y se los entrega después de
anotar los elementos en un cuaderno (En ocasiones este registro no se
hace), el cliente debe dejar el carnet de la universidad del cauca hasta
que regrese el préstamo, cuando esto sucede el préstamo termina y es
modificado en el registro que se lleva en un cuaderno. Los elementos
son probados antes y después del préstamo para verificar su correcto
funcionamiento.
Caso del Negocio Nº.2 Buscar Deudor
Iniciador Cliente
Propósito Verificar si una persona es o no un deudor
Resumen El cliente solicita que se le firme que está a paz y salvo con los
laboratorios de telemática, el administrador busca en un registro que se
lleva a mano si el cliente está registrado como deudor y según eso firma
o no el paz y salvo.

Caso del Negocio Nº.3 Gestión de Elementos

Iniciador Administrador
Propósito Gestionar elementos de los laboratorios
Resumen La gestión de los elementos es muy poca, se tiene una tabla en Excel
donde se han registrado, modificado y eliminado elementos
anteriormente, pero por falta de gestión esta lista está algo
desactualizada.
3. MITIGACIÓN DE LOS RIESGOS
3.1 Lista de riesgos

Riesgos críticos

Compatibilidad del sistema operativo (Lenguajes de programación)

Descripción Las características del entorno (lenguajes de programación, base de
datos, entre otros) donde se implementará el sistema puede afectar al
desarrollo del mismo si no existe compatibilidad lo que ocasionaría un
mal funcionamiento.
Categoría Software
Probabilidad 40%
Impacto Crítico
Plan de contingencia 1. Conocer los lenguajes de programación que maneja el cliente y
ajustar la solución al entorno.
2. Implementar en el cliente la arquitectura y lenguajes necesarios
para que el sistema opere correctamente.

Falta de conocimiento
Descripción Falta de conocimiento del entorno del problema y sistema solución
(Software, Lenguaje de programación, etc)
Categoría Equipo
Probabilidad 70%
Impacto Crítico
Plan de contingencia 1. Solicitar asesoría con una persona con amplio conocimiento del
problema a tratar con la respectiva solución planteada.
2. Buscar información y buscar la forma de aprender de
forma personal sobre el entorno de la solución.

Diseño de la base de datos

Descripción Debido al manejo de una gran cantidad de elementos a prestar y
la cantidad de personas solicitantes, es necesario que la base de
datos sea escalable y robusta para el manejo de toda esta
información, características que el equipo de desarrollo no ha manejado
antes.
Categoría Equipo
Probabilidad 70%
Impacto Crítico
Plan de contingencia 1. Solicitar asesoría con una persona con amplio conocimiento del
problema a tratar.
2. Buscar información y buscar información de manera independiente
sobre el entorno de la solución.
Riesgos significativos

Daño o pérdida de dispositivos de almacenamiento

Descripción Daño parcial o pérdida total de la información almacenada en
un equipo.
Categoría Técnico
Probabilidad 60%
Impacto Significativo
Plan de contingencia Mantener la información en diferentes dispositivos y un backup en la
nube para asegurar la seguridad de la información.

Falta de integrante
Descripción La ausencia parcial o completa de un integrante del grupo, llevando al
incumplimiento de las tareas asignadas al miembro faltante.
Categoría Equipo
Probabilidad 30%
Impacto Significativo
Plan de contingencia Reasignar las tareas entre los miembros del grupo.

Manejo del tiempo

Descripción El incumplimiento del desarrollo de las diferentes etapas del sistema
en determinado tiempo representan un atraso que puede llevar a
una implementación poco efectiva o incompleta del sistema solución
Categoría Proyecto
Probabilidad 80%
Impacto Significativo
Plan de contingencia 1. Elaborar un cronograma en el cual se determine las actividades y su
respectiva duración para hacer un mejor control del tiempo que se
debe invertir para el correcto desarrollo del sistema.

2. Ampliar plazos de entrega antes de la presentación del prototipo

(etapa final)

3. Adaptar el alcance del proyecto a medida que las actividades

se van realizando para ajustarse al tiempo disponible.
Capital insuficiente (mala planeación)
Descripción Mala planeación del capital a invertir para llevar a cabo el desarrollo e
implementación del sistema solución debido al incremento de
costo de un elemento no previsto.
Categoría Proyecto
Probabilidad 40%
Impacto Significativo
Plan de contingencia 1. Utilizar recursos brindados por la universidad.
2. Cambiar dispositivos o elementos que incrementan costos por
unos que no representen un elevado valor.

Inconvenientes en el grupo
Descripción Problemas, discusiones y/o desacuerdos entre los integrantes del
grupo.
Categoría Equipo
Probabilidad 30%
Impacto Significativo
Plan de contingencia Al existir conflictos entre los integrantes del grupo buscar ayuda de
un mediador para resolver la problemática.

No disponibilidad del cliente

Descripción Falta de tiempo por parte del cliente para contestar dudas
e inquietudes respecto al proyecto.
Categoría Proyecto
Probabilidad 30%
Impacto Significativo
Plan de contingencia Solicitar citas con anticipación para hablar de los avances con el
cliente.

Reestructuración de los laboratoristas

Descripción Cambio de personal y/o responsabilidades en el manejo de los
laboratorios, cambiando los requerimientos del sistema
Categoría Proyecto
Probabilidad 30%
Impacto Significativo
Plan de contingencia Dialogar con el nuevo personal lo previamente pactado y ver la
posibilidad de agregar o modificar levemente el sistema planteado
evaluando el tiempo disponible restante.
4. ACTUALIZACIÓN DEL PLAN INICIAL DEL PROYECTO
4.1 Actualización de los recursos requeridos

Tipo Categoría Elementos Ventana disponibilidad

Físicos Hardware 1. Computadores 1. Durante todo el proyecto.
2. Conexión internet 2. Durante todo el proyecto.
Técnicos Software 3. Servidor Web 3. Desde el inicio de elaboración
4. Sistema operativo que de prototipo hasta la validación
soporte la del mismo.
implementación del 4. Desde el inicio de elaboración
sistema. de prototipo hasta la validación
5. Herramienta para la del mismo.
gestión de 5. Desde la elaboración inicial del
requerimientos caso de negocio hasta la
6. Recursos ofimáticos validación del prototipo.
6. Durante todo el proyecto.
Humanos Equipo 7. Integrantes del proyecto 7. Durante todo el proyecto
8. Asesores 8. Durante todo el proyecto
9. Clientes 9. Durante todo el proyecto

4.2 Estimación de costos

Recursos Humanos

Nombre Tiempo total c/u Puntos por Valor del punto TOTAL
(Horas) hora c/u

Integrantes grupo (3) 180 1,5 12.939 10.480.590

Asesores (2) 18 2,5 12.939 1.164.510

Recursos Hardware

Equipo Costo Cantidad Horas Costo de uso

Equipo (computador 1) 1.485.200 1 215 12.150
Equipo (computador 2) 1.000.000 1 215 8.181
Recursos computacionales y laboratorios 110.657 - - 110.657
Recursos ofimáticos (Licencia gratuita) 0 0
Elementos Valor Total acumulado
Integrantes grupo (3) 10.480.590 10.480.590
Asesores (2) 1.164.510 11.645.100
Equipo (computador 1) 12.150 11.657.250
Equipo (computador 2) 8.181 11.665.431
Recursos computacionales y laboratorios 110.657 11.776.088
Papelería 10.000 11.786.088
TOTAL 11.786.088

4.3 Asignación de responsabilidades

Nombre Responsabilidades
Natalia Arteaga López Procesar las peticiones grupales.
Control de cambios de la
configuración del sistema.
Gestión de recursos y riesgos
Desarrollo software del sistema
solución.
Carlos Andrés Delgado Calvache Control de calidad del sistema
Diseño de la arquitectura del sistema
Descripción y desarrollo de casos de
uso del sistema.
Desarrollo software del sistema
solución
Ricar Donaldo Patiño Análisis del alcance y requisitos.
Control de actividades y cronograma.
Organización y comunicación del
equipo.
Desarrollo software del sistema
solución.
Ing. Eduardo Rojas Asesoría y soporte en el desarrollo del
proyecto.
Evaluación de los avances realizados
por el grupo de desarrollo.
4.4 Actualización del cronograma inicial

Id Actividades Fecha de inicio Fecha final Duración (días)

1 Presentación del 24/08/2017 24/08/2017 1
problema por parte del
cliente
2 Entendimiento del 24/08/2017 29/08/2017 6
entorno del problema,
captura de requisitos
iniciales.
3 Establecimiento de los 03/10/2017 09/10/2017 7
criterios de evaluación
4 Caracterización del 24/08/2017 30/08/2017 7
sistema objetivo
5 Definición del alcance 19/09/2017 31/10/2017 43
del sistema
6 Elaboración de casos de 20/09/2017 10/11/2017 52
uso del sistema
7 Elaboración del caso 19/09/2017 10/10/2017 22
inicial del negocio
8 Elaboración de la lista 01/10/2017 07/11/2017 38
de riesgos del proyecto

9 Elaboración de 05/10/2017 08/10/2017 9

cronograma para el
proyecto 28/10/2017 01/11/2017
10 Estimación de los 25/09/2017 27/09/2017 8
recursos requeridos 28/10/2017 01/11/2017

11 Diseño de la 30/08/2017 31/10/2017 63

arquitectura
12 Evaluación de los 08/10/2017 30/11/2017 54
subproductos
elaborados en cada
etapa

13 Elaboración prototipo 30/10/2017 30/11/2017 32

14 Validación del prototipo 30/11/2017 30/11/2017

1
División en 14 semanas comprendidas desde el 24/08/2017 hasta el 30/11/2017
Duración
n Actividad 1 2 3 4 5 6 7 8 9 10 11 12 13 14
(días)
Presentación del
1 problema por parte 1
del cliente
Entendimiento del
entorno del
2 6
problema, captura de
requisitos iniciales.
Establecimiento de
3 los criterios de 7
evaluación
Caracterización del
4 8
sistema objetivo
Definición del alcance
5 43
del sistema
Elaboración de casos
6 52
de uso del sistema
Elaboración del caso
7 22
inicial del negocio
Elaboración de la lista
8 de riesgos del 38
proyecto
Elaboración de
9 cronograma para el 4
proyecto
Estimación de los 3
10
recursos requeridos
Diseño de la
11 63
arquitectura
Evaluación de los
subproductos
12 54
elaborados en cada
etapa
13 Elaboración prototipo 32
Validación del
14
prototipo 1
5. DETERMINACIÓN PRELIMINAR DE VIABILIDAD DEL PROYECTO
5.1 Beneficios: Mejorar el sistema de préstamos facilitando el registro de los procesos de
solicitud, obtención y devolución.

5.2 Costo estimado: 11.786.088

5.3 Duración aproximada comprendida desde el 24/08/2017-30/11/2017

5.4 Criterios de evaluación

CRITERIOS DE EVALUACIÓN SI NO
Definición del alcance del proyecto
¿Se obtuvo una descripción suficientemente clara de la aplicación y una adecuada X
declaración de su propósito?
¿Se realizó una clara identificación de actores? X
¿Se tienen un modelo inicial del negocio que representa realmente los procesos de X
negocio necesarios?
¿Se tiene un modelo de casos de uso de la aplicación adecuado? X
Resolución de ambigüedades en los requisitos
¿Se ha logrado un reconocimiento satisfactorio de requerimientos (funcionales y X
no funcionales) y en el nivel de detalle adecuado?
¿Se han llevado correctamente esos requerimientos a casos de uso? X
¿Existe coherencia entre los modelos elaborados y la Declaración Inicial del X
Negocio?
¿Se han priorizado convenientemente los casos de uso? X
Viabilidad de la arquitectura inicial
¿Satisface la arquitectura propuesta las necesidades del Cliente y de los usuarios? - -
¿Es factible realizar una implementación de la aplicación estructurada según la X
propuesta?
¿Se han considerado alternativas a ésta? X
¿La arquitectura propuesta utiliza apropiadamente la tecnología existente? X
¿Se han evaluado sus criterios de eficiencia, tolerancia a fallas, adaptabilidad y X
robustez?
¿La arquitectura plantea posibilidad de crecimiento o evolución de la aplicación? X
Mitigación de riesgos críticos
¿Se han identificado todos los riesgos críticos? X
¿Se evaluaron los elementos del entorno de desarrollo y del entorno de ejecución, X
y se han propuesto medidas adecuadas al respecto?
¿Se ha elaborado un presupuesto consistente y acorde a las necesidades? X
¿Se ha elaborado un cronograma o un plan de trabajo a seguir realista? X
Conveniencia del Caso Inicial de Negocio
¿Es el Caso Inicial del Negocio lo suficientemente satisfactorio para justificar X
la continuación del proyecto?
5.5 El proyecto se considera viable teniendo en cuenta las consideraciones de duración y costos, se
tiene una buena disposición del cliente para el suministro de la información y los criterios de
evaluación arrojan buenas condiciones y términos para llevar a cabo el desarrollo del sistema, vale
destacar que se tiene como objetivo mejorar en cada aspecto mencionado en los criterios de
evaluación.