Practica 3

AA SYSTEMS
Informe técnico del proyecto, Plan de

viabilidad
-
Ingeniería de Requisitos
Antonio Cabezas Jarabo

Alejandro Rovira Domínguez
Página 1
Contenido
ACTIVIDAD EVS 1: ESTABLECIMIENTO DEL ALCANCE DEL SISTEMA.............................................. 3
Tarea EVS 1.1: Estudio de la Solicitud ....................................................................................... 4
Tarea EVS 1.2: Identificación del Alcance del Sistema .............................................................. 6
Tarea 1.3: Especificación del Alcance de EVS............................................................................ 8
ACTIVIDAD EVS 2: ESTUDIO DE LA SITUACIÓN ACTUAL ................................................................ 9
Tarea EVS 2.1: Valoración del Estudio de la Situación Actual ................................................. 10
Tarea EVS 2.2: Identificación de los Usuarios Participantes en el Estudio de la Situación
Actual ...................................................................................................................................... 12
Tarea EVS 2.3: Descripción de los Sistemas de Información Existentes ................................. 13
Tarea EVS 2.4: Realización del Diagnóstico de la Situación Actual ......................................... 16
ACTIVIDAD EVS 3: DEFINICIÓN DE REQUISITOS DEL SISTEMA .................................................... 17
Tarea EVS 3.1: Identificación de las Directrices Técnicas y de Gestión................................... 18
Tarea EVS 3.2: Identificación de Requisitos ............................................................................ 19
Tarea EVS 3.3: Catalogación de Requisitos ............................................................................. 21
ACTIVIDAD EVS 4: ESTUDIO DE ALTERNATIVAS DE SOLUCIÓN ................................................... 24
Tarea EVS 4.1: Preselección de Alternativas de Solución ....................................................... 25
Tarea EVS 4.2: Descripción de las Alternativas de Solución.................................................... 27
ACTIVIDAD EVS 5: VALORACIÓN DE LAS ALTERNATIVAS ............................................................ 29
Tarea EVS 5.1: Estudio de la Inversión .................................................................................... 30
Tarea EVS 5.2: Estudio de los Riesgos ..................................................................................... 36
Tarea EVS 5.3: Planificación de Alternativas ........................................................................... 37
ACTIVIDAD EVS 6: SELECCIÓN DE LA SOLUCIÓN ......................................................................... 39
Tarea EVS 6.1: Convocatoria de la Presentación..................................................................... 40
Tarea EVS 6.2: Evaluación de las Alternativas y Selección ...................................................... 41
Página 2
ACTIVIDAD EVS 1: ESTABLECIMIENTO DEL
ALCANCE DEL SISTEMA
En esta actividad se estudia el alcance de la necesidad planteada por el cliente o usuario,
o como consecuencia de la realización de un PSI, realizando una descripción general de la misma.
Se determinan los objetivos, se inicia el estudio de los requisitos y se identifican las unidades
organizativas afectadas estableciendo su estructura.
Se analizan las posibles restricciones, tanto generales como específicas, que puedan
condicionar el estudio y la planificación de las alternativas de solución que se propongan.
Si la justificación económica es obvia, el riesgo técnico bajo, se esperan pocos problemas
legales y no existe ninguna alternativa razonable, no es necesario profundizar en el estudio de
viabilidad del sistema, analizando posibles alternativas y realizando una valoración y evaluación
de las mismas, sino que éste se orientará a la especificación de requisitos, descripción del nuevo
sistema y planificación.
Se detalla la composición del equipo de trabajo necesario para este proceso y su
planificación. Finalmente, con el fin de facilitar la implicación activa de los usuarios en la definición
del sistema, se identifican sus perfiles, dejando claras sus tareas y responsabilidades.
Tarea Productos Técnicas y Prácticas Participantes

EVS 1.1 Estudio de la - Descripción General del - Catalogación - Comité de Dirección
Solicitud Sistema - Sesiones de trabajo - Jefe de Proyecto
- Catálogo Objetivos EVS - Analistas
- Catálogo de Requisitos
EVS 1.2 Identificación - Descripción General del - Diagramas de Flujo - Comité de Dirección
del Alcance Sistema: de Datos - Jefe de Proyecto
del Sistema o Contexto del Sistema - Diagrama de - Analistas
o Estructura Organizativa Descomposición
- Catálogo de Requisitos Funcional
- Catálogo de Usuarios - Catalogación
- Sesiones de trabajo
EVS 1.3 Especificación - Catálogo de Objetivos del - Catalogación - Comité de Dirección
del Alcance EVS - Sesiones de trabajo - Jefe de Proyecto
del EVS - Catálogo de Usuarios - Analistas
- Plan de Trabajo
Página 3
Tarea EVS 1.1: Estudio de la Solicitud
Se realiza una descripción general de la necesidad planteada por el usuario, y se estudian
las posibles restricciones de carácter económico, técnico, operativo y legal que puedan afectar al
sistema. Antes de iniciar el estudio de los requisitos del sistema se establecen los objetivos
generales del Estudio de Viabilidad, teniendo en cuenta las restricciones identificadas
anteriormente.
Si el sistema objeto de estudio se encuentra en el ámbito de un Plan de Sistemas de
Información vigente, se debe de tomar como referencia el catálogo de requisitos y la arquitectura
de información resultante del mismo, como información adicional para la descripción general del
sistema y determinación de los requisitos iniciales.
Descripción general del sistema

El problema define un Sistema de Información para la Biblioteca de la UCO. La
implementación de este software se debe a un gran incremento del flujo de usuarios de la
biblioteca. Así, nuestro cliente solicita un software capacitado para asumir múltiples funciones de
gestión de la biblioteca; supliendo algunas como la catalogación de un fondo bibliográfico o la
devolución del mismo por parte del cliente.
Catálogo de objetivos EVS

• Software sencillo e intuitivo
• Intervenir en todas las fases del ciclo de vida del producto.
• Diseñar, construir y administrar base de datos
• Dirigir equipos de trabajo de desarrollo software
• Reducir el tiempo de respuesta del software
• Seguridad y privacidad del software
• Agilidad para satisfacer las necesidades del usuario
Catálogo de requisitos
Primeramente, se identifican y clasifican los requisitos funcionales y no funcionales.
Requisitos funcionales
Los requisitos funcionales se refieren a las tareas que se espera que ejecute el sistema
software.
REQUISITOS FUNCIONALES
ID Descripción Versión
RF-01 La plataforma SIBUCO debe permitir el registro de nuevos usuarios. 1.0
RF-02 La plataforma SIBUCO debe permitir a los usuarios el inicio de sesión. 1.0
RF-03 La plataforma SIBUCO debe permitir a los usuarios el cierre de sesión. 1.0
RF-04 La plataforma SIBUCO debe permitir al personal de biblioteca registrar un 1.0
nuevo fondo bibliográfico.
RF-05 La plataforma SIBUCO debe permitir a los usuarios reservar libros sin 1.0
límite de cantidad, independientemente del estado del libro.
RF-06 La plataforma SIBUCO debe permitir a los usuarios ampliar una reserva 1.0
activa de un libro.
Página 4
RF-07 La plataforma SIBUCO debe permitir a los usuarios anular una reserva 1.0
activa de un libro.
RF-08 La plataforma SIBUCO debe permitir a los usuarios consultar una reserva 1.0
activa de un libro.
RF-09 La plataforma SIBUCO debe notificar a los usuarios de la disponibilidad 1.0
de un libro reservado.
RF-10 La plataforma SIBUCO debe cancelar la reserva de un libro a un usuario 1.0
si el plazo de recogida expira y se ha avisado de su disponibilidad.
RF-11 La plataforma SIBUCO debe permitir al personal de la biblioteca registrar 1.0
un préstamo.
RF-12 La plataforma SIBUCO debe permitir al personal de la biblioteca imponer 1.0
multas a los usuarios.
RF-13 La plataforma SIBUCO debe permitir al personal de la biblioteca anular 1.0
una devolución de un libro.
RF-15 La plataforma SIBUCO debe notificar a los usuarios el retraso en una 1.0
devolución.
RF-16 La plataforma SIBUCO debe permitir al personal de la biblioteca editar 1.0
los datos de un fondo bibliográfico.
RF-17 La plataforma SIBUCO debe mantener actualizado el tiempo de duración 1.0
de una reserva.
de un préstamo.
RF-19 La plataforma SIBUCO debe permitir a los usuarios consultar un 1.0
préstamo activo de un libro.
Requisitos no funcionales
Los requisitos no funcionales describen restricciones y comportamientos que el sistema
debe cumplir.
REQUISITOS NO FUNCIONALES
RNF-01 La plataforma SIBUCO debe ser capaz de operar con hasta 100 1.0
usuarios con sesiones recurrentes.
RNF-02 La plataforma SIBUCO debe mantener un tiempo de respuesta inferior 1.0
a 10 segundos para cualquier funcionalidad siempre que haya 20 o
menos usuarios haciendo uso de esta.
RNF-03 La plataforma SIBUCO debe estar operativo las 24 horas del día a lo 1.0
largo de todos los días de la semana.
RNF-04 La plataforma SIBUCO debe tener un tiempo de aprendizaje por 1.0
usuario menor a 3 horas.
RNF-05 La plataforma SIBUCO debe asegurar que los datos estén protegidos 1.0
del acceso no autorizado.
RNF-06 La plataforma SIBUCO debe estar disponible en los idiomas español, 1.0
inglés y francés.
RNF-07 La plataforma SIBUCO debe mantener los datos de los usuarios 1.0
cifrados de extremo a extremo.
Página 5
Tarea EVS 1.2: Identificación del Alcance del Sistema
Se analiza el alcance de la necesidad planteada y se identifican las restricciones relativas
a la sincronización con otros proyectos, que puedan interferir en la planificación y futura puesta a
punto del sistema objeto del estudio. Esta información se recoge en el catálogo de requisitos.
Si el sistema pertenece al ámbito de un Plan de Sistemas de Información, se debe tener
en cuenta la arquitectura de información propuesta para analizar el alcance del sistema e identificar
los sistemas de información que quedan fuera del ámbito del estudio. Además, se estudia el plan
de proyectos, para determinar las posibles dependencias con otros proyectos.
Una vez establecido el alcance, se identifican las unidades organizativas afectadas por el
sistema, así como su estructura y responsables de las mismas. Para determinar los responsables
se tiene en cuenta a quiénes afecta directamente y quiénes pueden influir en el éxito o fracaso del
mismo.
El sistema deberá ser capaz de cubrir las siguientes tareas de la biblioteca:
• Administración de usuarios
• Organización de fondos bibliográficos
• Reserva de fondos bibliográficos
• Préstamo de fondos bibliográficos
• Devolución de fondos bibliográficos
• Gestión de multas
Catálogo de usuarios
Los actores del sistema serán los mostrados a continuación:
• PAS: Es el Personal de Administración y Servicios. Llevarán a cabo las gestiones de la

biblioteca.
• Usuario registrado: Usuarios registrados en el sistema. Pueden realizar cualquier función
dentro del software.
• Usuario no registrado: Usuarios no registrados en el sistema. Disponen de menos
funciones.
Una vez identificados los usuarios finales del sistema, a continuación, mostraremos una tabla
donde se podrá observar las funciones que posee cada uno:
Actor Descripción
Personal de la biblioteca - Añadir, eliminar o modificar usuarios al
sistema.
- Añadir o eliminar fondos bibliográficos.
- Añadir, eliminar o modificar préstamos.
- Añadir, eliminar o consultar multas de los
usuarios.
- Añadir, eliminar o consultar reservas de
fondos bibliográficos.
Página 6
- Consultar disponibilidad de fondos
bibliográficos.
Usuario registrado - Realizar reserva, eliminarla o consultarla de
fondos bibliográficos.
- Realizar préstamo, eliminarlo o consultarlo
de fondos bibliográficos.
- Realizar devolución, eliminarla o consultarla
de fondos bibliográficos.
Usuario no registrado - Consultar datos disponibles de fondos
bibliográficos.
Página 7
Tarea 1.3: Especificación del Alcance de EVS
En función del alcance del sistema y los objetivos del Estudio de Viabilidad del Sistema,
se determinan las actividades y tareas a realizar. En particular, hay que decidir si se realiza o no
el estudio de la situación actual y, en el caso de considerarlo necesario, con qué objetivo. Si el
sistema pertenece al ámbito de un Plan de Sistemas de Información, los criterios que pueden
orientar sobre la necesidad de llevar a cabo el estudio de la situación actual dependen de la
arquitectura de información propuesta, en cuanto a la identificación de los sistemas de información
actuales, implicados en el ámbito de este estudio, que se haya decidido conservar.
Se identifican los usuarios participantes de las distintas unidades organizativas afectadas
para la realización del Estudio de Viabilidad del Sistema, determinando previamente sus perfiles y
responsabilidades.
Debe comunicarse el plan de trabajo a los usuarios identificados como implicados en el
Estudio de Viabilidad, solicitando su aceptación y esperando su confirmación.
Plan de trabajo
Estudio de Actividades
viabilidad
EVS-1 EVS-2 EVS-3 EVS-4 EVS-5 EVS-6
del sistema
Jefe del
X X X X X X
proyecto
Personal de
X X
la biblioteca
Analista de
X X X X
requisitos
Analista de
X
costes
Arquitecto de
X X X
software
Analista del
X X
proyecto
Equipo de
Soporte X
técnico
Las actividades a desarrollar son:
• EVS-1: Establecimiento del alcance del sistema

• EVS-2: Estudio de la situación actual
• EVS-3: Definición de requisitos del sistema
• EVS-4: Estudio de alternativas de solución
• EVS-5: Valoración de las alternativas
• EVS-6: Selección de la solución
Página 8
ACTIVIDAD EVS 2: ESTUDIO DE LA
SITUACIÓN ACTUAL
La situación actual es el estado en el que se encuentran los sistemas de información
existentes en el momento en el que se inicia su estudio.
Teniendo en cuenta el objetivo del estudio de la situación actual, se realiza una valoración
de la información existente acerca de los sistemas de información afectados. En función de dicha
valoración, se especifica el nivel de detalle con que se debe llevar a cabo el estudio. Si es
necesario, se constituye un equipo de trabajo específico para su realización y se identifican los
usuarios participantes en el mismo. Si se decide documentar la situación actual, normalmente es
conveniente dividir el sistema actual en subsistemas. Si es posible se describirán cada uno de los
subsistemas, valorando qué información puede ser relevante para la descripción.
Como resultado de esta actividad se genera un diagnóstico, estimando la eficiencia de los
sistemas de información existentes e identificando los posibles problemas y las mejoras.
Tarea Productos Técnicas y Prácticas Participantes
EVS 2.1 - Valoración del - Descripción de la - Sesiones de Trabajo - Jefe de Proyecto
Estudio de la Situación Actual - Personal de la
Situación Actual biblioteca
EVS 2.2 - Identificación de - Catálogo de - Sesiones de Trabajo - Jefe de Proyecto
los Usuarios Usuarios - Catalogación - Personal de la
Participantes en biblioteca
el Estudio de la
Situación Actual
EVS 2.3 - Descripción de - Descripción de la - Modelo - Jefe de Proyecto
los Sistemas de Situación Actual: Entidad/Relación - Personal de la
Información o Descripción - Diagrama de Flujo de biblioteca
Existentes Lógica del datos - Equipo de
Sistema Actual - Sesiones de Trabajo Soporte Técnico
- Analistas
EVS 2.4 - Realización del - Descripción de la - Jefe de Proyecto
Diagnóstico de la Situación Actual: - Personal de la
Situación Actual o Diagnóstico de biblioteca
la situación - Analistas
actual
Página 9
Tarea EVS 2.1: Valoración del Estudio de la Situación Actual
Descripción de la situación actual
En análisis contextual del sistema tenemos que el cliente nos solicita un software con el
objetivo de simplificar múltiples funciones asignadas al personal de biblioteca, permitiendo la
liberación de una parte de la carga de trabajo y garantizando así una gestión adecuada del
funcionamiento y recursos de la biblioteca.
Los sistemas de información extraídos en el problema dado por el cliente, se corresponden
con las tareas detalladas en el EVS 1.2 y serían los siguientes:
• Catalogación de fondos bibliográficos
• Reservas de fondos bibliográficos
• Préstamos de fondos bibliográficos
A continuación, se especifican las distintas funcionalidades que cubrirán las necesidades
marcadas por nuestro cliente:
- El sistema debe proporcionar una lista con el conjunto de usuarios dados de alta
en él, ofreciendo una gestión de servicios al personal de la biblioteca en las
cuentas de usuario, entre los que se incluyen: el servicio tanto de reserva, como
de préstamo, la posibilidad de cambio de contraseña en caso de ser solicitado por
el usuario, la gestión de información del perfil, permitiendo su modificación y por
último, las acciones de eliminar o agregar una cuenta.
- El sistema debe proporcionar una funcionalidad tal que viabilice el tratamiento de
los fondos bibliográficos, de modo que el personal de la biblioteca, tendrá la
capacidad de ejecutar las siguientes acciones: agregar, editar o excluir la
información de un fondo. En adición a lo anterior, se deberá incluir la acción de
consulta de los fondos bibliográficos, permitiendo tanto a usuarios registrados
como no registrados, además del personal de biblioteca, examinar la
disponibilidad de un fondo que se encuentre registrado, así como su información.
- El sistema debe garantizar un servicio dedicado a la reserva de ejemplares de
fondos bibliográficos, independientemente de la disponibilidad del libro en ese
momento; será apto para usuarios registrados, dando soporte para las siguientes
acciones en relación a una reserva: registro, ampliación del plazo, consulta del
estado y eliminación.
- El sistema también debe garantizar un servicio dedicado al préstamo de
ejemplares de fondos bibliográficos. Concretamente, hará viable la formalización
de un préstamo en el sistema por el personal de la biblioteca, permitiendo a su
vez, la gestión pertinente de dicho préstamo una vez esté activo, dando además,
P á g i n a 10
la posibilidad de consultar el estado de éste al usuario registrado asociado. De
modo que se dará soporte a las 11 siguientes funciones en relación a un
préstamo: formalización, modificación, consulta y eliminación.
- El sistema, en consonancia con los préstamos, también debe garantizar un
servicio dedicado a la devolución de estos, tal que, se de soporte para la
formalización de una devolución asociada a un préstamo activo de un fondo
bibliográfico, recayendo la responsabilidad de esta en el personal de la biblioteca.
Una vez que el personal de la biblioteca haya registrado la acción de devolución,
el sistema reflejará de forma automática si el fondo ha sido devuelto en plazo o
no.
- El sistema debe garantizar un servicio dedicado a la gestión de sanciones, con el
fin de la imposición de una multa a un usuario registrado, con motivo de:
expiración del plazo de devolución de un préstamo de un fondo de la biblioteca.
Esta función será supervisada por el personal de la biblioteca, otorgándole los
privilegios de llevar a cabo las acciones de agregación, anulación y consulta de
multas. Además, la consulta también estará disponible para el usuario asociado
a una multa activa.
P á g i n a 11
Tarea EVS 2.2: Identificación de los Usuarios Participantes
en el Estudio de la Situación Actual
Catálogo de usuarios
Se procede a identificar los usuarios participantes de cada una de las unidades
organizativas mencionadas anteriormente como sistemas de información, con el objetivo de,
posteriormente, informar a dichos usuarios implicados, solicitando su aceptación y
manteniéndonos a la espera de su confirmación. Dicha identificación se muestra en la tabla situada
más abajo.
Unidad Organizativa / Sistema de
Usuario implicado
Información
Personal de la biblioteca Administración de usuarios
Personal de la biblioteca Organización de fondos bibliográficos
Usuario registrado
Usuario no registrado
Usuario registrado Reservas de fondos bibliográficos
Personal de la biblioteca Préstamos de fondos bibliográficos
Usuario registrado
Personal de la biblioteca Devolución de fondos bibliográficos
Usuario registrado
Personal de la biblioteca Gestión de multas
P á g i n a 12
Tarea EVS 2.3: Descripción de los Sistemas de Información
Existentes
Ahora, se describen los sistemas de información existentes afectados, según el alcance
y nivel de detalle establecido previamente en la tarea Valoración del Estudio de la Situación
Actual (EVS 2.1), mediante sesiones de trabajo con los usuarios designados para este estudio.
Descripción lógica de los sistemas de información Establecemos las operaciones a

implementar en cada sistema de información, definiendo así de forma lógica el funcionamiento:
- Se le atribuye la sección de administración de usuarios en el sistema, donde el
personal de biblioteca cuenta con la posibilidad de consultar y gestionar la lista de
todos los usuarios que han sido registrados en el sistema. Se incluye la posibilidad
de llevar a cabo las siguientes opciones:
- Agregar cuenta: Creación de una cuenta de usuario. Esta acción sólo deberá
utilizarse en circunstancias especiales, ya que son los propios usuarios los
que formalizan el registro en la plataforma.
- Eliminar cuenta: Desactivación y borrado de una cuenta de usuario
registrada en la lista de usuarios del sistema.
- Se le atribuye la sección de organización de fondos bibliográficos en el sistema,
donde el personal de la biblioteca podrá llevar a cabo las siguientes funciones:
• Agregar libro: Adición de un fondo bibliográfico a la lista del sistema.
• Modificar libro: Edición de los datos de un fondo bibliográfico ya registrado
en la lista del sistema.
• Consultar libro: Visualización de la información de un fondo bibliográfico
seleccionado, así como de la disponibilidad de éste. Esta opción también se
encuentra disponible para usuarios registrados y no registrados.
• Eliminar libro: Supresión de un fondo bibliográfico de la lista de libros del
sistema.
- Se le atribuye la sección de reservas de fondos bibliográficos en el sistema, accesible
por el personal de la biblioteca y los usuarios registrados. Dentro de la sección se
podrán llevar a cabo las siguientes opciones:
• Registrar reserva: Registro de la reserva de un ejemplar correspondiente al
libro seleccionado.
• Anular reserva: Anulación de una reserva activa seleccionada.
• Ampliar reserva: Ampliación del plazo de una reserva activa.
• Consultar reserva: Visualización del plazo y la información respectiva a la
reserva.
- Se le atribuye la sección de préstamos de fondos bibliográficos en el sistema,
accesible por el personal de la biblioteca, qué podrá hacer uso de las siguientes
funcionalidades:
• Formalizar préstamo: Concreción de un préstamo de un ejemplar asociado
a un libro de la lista del sistema.
P á g i n a 13
• Eliminar préstamo: Eliminación de un préstamo activo de un ejemplar
asociado a un libro de la lista del sistema.
• Modificar préstamo: Modificación de los datos asociados a un préstamo
activo de un ejemplar de un libro de la lista del sistema.
• Consultar préstamo: Visualización del plazo y los datos relacionados con el
préstamo activo seleccionado. Esta opción también se encuentra disponible
para los usuarios registrados.
- Se le atribuye la sección de devolución de fondos bibliográficos en el sistema,
accesible por el personal de la biblioteca, qué podrá hacer uso de las siguiente
funcionalidad:
• Formalizar devolución: Concreción de la devolución de un ejemplar sobre
un préstamo previamente activo.
- El personal autorizado podrá acceder a la gestión de multas del sistema, se podrán
observar tres acciones a realizar:
- Agregar multa: Agregación de una multa que estará debidamente asociada a un
usuario y al préstamo, cuyo plazo de devolución haya expirado.
- Anular multa: Anulación de una multa asociada a un usuario registrado en el
sistema.
- Consultar multa: Visualización de las multas asociadas a un usuario registrado en el
sistema. Esta opción también se encuentra disponible para los usuarios registrados.
• Bases de datos
- Respecto al almacenamiento de datos, proponemos la integración de las siguientes
bases de datos respectivas:
• BD de usuarios y multas
• BD de reservas, préstamos y devoluciones.
• BD de fondos bibliográficos
Para favorecer la comprensión del sistema se han llevado a cabo los diagramas de Flujo
de Datos y de Entidad / Relación.
P á g i n a 14
Imagen 1 – Diagrama de Flujo de Datos
Imagen 2 – Diagrama Entidad/Relación de la BD
P á g i n a 15
Tarea EVS 2.4: Realización del Diagnóstico de la Situación
Actual
Se procede con la elaboración del diagnóstico de la situación actual analizando la
información de los sistemas de información existentes, obtenida en la tarea anterior e identificando
posibles problemas, deficiencias y mejoras.
Diagnóstico de la situación actual

En nuestro caso, tras haber analizado con detalle el proceso seguido en la tarea anterior,
concluimos que no existen defectos que imposibiliten o dificulten el avance en el proyecto. Para
ello, hemos examinado los sistemas de información resultantes, así como los diagramas
anteriores, tratando de encontrar contradicciones e inconsistencias.
P á g i n a 16
ACTIVIDAD EVS 3: DEFINICIÓN DE
REQUISITOS DEL SISTEMA
En esta actividad se procede a la determinación de los requisitos generales, mediante una
serie de sesiones de trabajo. Una vez finalizadas, se analiza la información obtenida y definimos
los requisitos y sus prioridades, que se añaden al catálogo de requisitos que servirá para el estudio
y valoración de las distintas alternativas de solución que se propongan.
Técnicas y
Tarea Productos Participantes
Prácticas
EVS 3.1 - Identificación de las - Catálogo de - Catalogación - Jefe de Proyecto
Directrices Técnicas Normas - Analistas
y de Gestión
EVS 3.2 - Identificación de - Identificación - Sesiones de - Jefe de Proyecto
Requisitos de Requisitos Trabajo - Analistas
EVS 3.3 - Catalogación de - Catálogo de - Catalogación - Jefe de Proyecto
Requisitos Requisitos - Analistas
P á g i n a 17
Tarea EVS 3.1: Identificación de las Directrices Técnicas y de
Gestión
Se procede con la consideración de los términos de referencia para el sistema en estudio
desde el punto de vista de directrices tanto técnicas como de gestión.
Catálogo de normas
Se llevaría a cabo la catalogación de información y estándares referentes a las diferentes
políticas y directrices a tratar, que serían las siguientes:
• Políticas técnicas:
o Gestión de Proyectos
▪ Seguimiento.
▪ Revisión.
▪ Aprobación final.
o Desarrollo de Sistemas
▪ Existencia de normativas.
▪ Metodologías.
▪ Técnicas de programación.
o Arquitectura de Sistemas
▪ Centralizada.
▪ Distribuida.
▪ Política de Seguridad
o Control de accesos
o Integridad de datos
o Disponibilidad de aplicaciones
• Directrices de Planificación.
• Directrices de Gestión de Cambios.
• Directrices de Gestión de Calidad
P á g i n a 18
Tarea EVS 3.2: Identificación de Requisitos
Para la obtención de las necesidades que ha de cubrir el sistema en estudio, se debe
decidir qué tipo de sesiones de trabajo se realizarán y con qué frecuencia tendrán lugar, en función
de la disponibilidad de los usuarios participantes.
Para esta actividad se procede con las sesiones de trabajo pertinentes. Además, se lleva
a cabo la selección de determinada información de interés de los sistemas de información
establecidos en la actividad EVS 2.4 para el desarrollo de dichas sesiones de trabajo.
Una vez finalizado el proceso correspondiente a las sesiones de trabajo con los usuarios
participantes, se continúa con la Identificación de Requisitos. En este caso, dicha identificación fue
realizada en el apartado número 1 de la actividad EVS 1, luego se muestra a continuación:
Identificación de Requisitos (Funcionales y No Funcionales)

RF-01 La plataforma SIBUCO debe permitir el registro de nuevos usuarios. 1.0
RF-02 La plataforma SIBUCO debe permitir a los usuarios el inicio de sesión. 1.0
RF-03 La plataforma SIBUCO debe permitir a los usuarios el cierre de sesión. 1.0
RF-04 La plataforma SIBUCO debe permitir al personal de biblioteca registrar un 1.0
nuevo fondo bibliográfico.
RF-05 La plataforma SIBUCO debe permitir a los usuarios reservar libros sin 1.0
límite de cantidad, independientemente del estado del libro.
RF-06 La plataforma SIBUCO debe permitir a los usuarios ampliar una reserva 1.0
activa de un libro.
RF-07 La plataforma SIBUCO debe permitir a los usuarios anular una reserva 1.0
activa de un libro.
RF-08 La plataforma SIBUCO debe permitir a los usuarios consultar una reserva 1.0
activa de un libro.
RF-09 La plataforma SIBUCO debe notificar a los usuarios de la disponibilidad 1.0
de un libro reservado.
RF-10 La plataforma SIBUCO debe cancelar la reserva de un libro a un usuario 1.0
si el plazo de recogida expira y se ha avisado de su disponibilidad.
un préstamo.
RF-12 La plataforma SIBUCO debe permitir al personal de la biblioteca imponer 1.0
RF-13 La plataforma SIBUCO debe permitir al personal de la biblioteca anular 1.0
una devolución de un libro.
RF-15 La plataforma SIBUCO debe notificar a los usuarios el retraso en una 1.0
devolución.
RF-16 La plataforma SIBUCO debe permitir al personal de la biblioteca editar 1.0
los datos de un fondo bibliográfico.
de una reserva.
P á g i n a 19
de un préstamo.
RF-19 La plataforma SIBUCO debe permitir a los usuarios consultar un 1.0
préstamo activo de un libro.
RNF-01 La plataforma SIBUCO debe ser capaz de operar con hasta 100 1.0
usuarios con sesiones recurrentes.
RNF-02 La plataforma SIBUCO debe mantener un tiempo de respuesta inferior 1.0
a 10 segundos para cualquier funcionalidad siempre que haya 20 o
menos usuarios haciendo uso de esta.
RNF-03 La plataforma SIBUCO debe estar operativo las 24 horas del día a lo 1.0
largo de todos los días de la semana.
RNF-04 La plataforma SIBUCO debe tener un tiempo de aprendizaje por 1.0
usuario menor a 3 horas.
RNF-05 La plataforma SIBUCO debe asegurar que los datos estén protegidos 1.0
del acceso no autorizado.
RNF-06 La plataforma SIBUCO debe estar disponible en los idiomas español, 1.0
inglés y francés.
RNF-07 La plataforma SIBUCO debe mantener los datos de los usuarios 1.0
cifrados de extremo a extremo.
P á g i n a 20
Tarea EVS 3.3: Catalogación de Requisitos
Ahora, procedemos al análisis de la totalidad de la información, obtenida durante la
Identificación de Requisitos, definiendo la siguiente catalogación de los requisitos que debe
satisfacer el sistema, incluyendo la priorización de estos a través del método MoSCow. Se incluirán
también requisitos relativos a distribución geográfica y entorno tecnológico.
Catálogo de Requisitos (Funcionales, No Funcionales, Geográficos y

Tecnológicos)
ID Descripción Prioridad Versión
RF-01 La plataforma SIBUCO debe permitir el registro de nuevos M 1.0
usuarios.
RF-02 La plataforma SIBUCO debe permitir a los usuarios el inicio M 1.0
de sesión.
RF-03 La plataforma SIBUCO debe permitir a los usuarios el cierre M 1.0
de sesión.
RF-04 La plataforma SIBUCO debe permitir al personal de M 1.0
biblioteca registrar un nuevo fondo bibliográfico.
RF-05 La plataforma SIBUCO debe permitir a los usuarios reservar S 1.0
libros sin límite de cantidad, independientemente del estado
del libro.
RF-06 La plataforma SIBUCO debe permitir a los usuarios ampliar S 1.0
una reserva activa de un libro.
RF-07 La plataforma SIBUCO debe permitir a los usuarios anular S 1.0
una reserva activa de un libro.
RF-08 La plataforma SIBUCO debe permitir a los usuarios S 1.0
consultar una reserva activa de un libro.
RF-09 La plataforma SIBUCO debe notificar a los usuarios de la S 1.0
disponibilidad de un libro reservado.
RF-10 La plataforma SIBUCO debe cancelar la reserva de un libro S 1.0
a un usuario si el plazo de recogida expira y se ha avisado
de su disponibilidad.
RF-11 La plataforma SIBUCO debe permitir al personal de la M 1.0
biblioteca registrar un préstamo.
biblioteca imponer multas a los usuarios.
biblioteca anular multas a los usuarios.
biblioteca registrar una devolución de un libro.
RF-15 La plataforma SIBUCO debe notificar a los usuarios el C 1.0
retraso en una devolución.
biblioteca editar los datos de un fondo bibliográfico.
RF-17 La plataforma SIBUCO debe mantener actualizado el tiempo M 1.0
de duración de una reserva.
P á g i n a 21
RF-18 La plataforma SIBUCO debe mantener actualizado el tiempo M 1.0
de duración de un préstamo.
RF-19 La plataforma SIBUCO debe permitir a los usuarios M 1.0
consultar un préstamo activo de un libro.
RF-20 La plataforma SIBUCO debe permitir al personal de la S 1.0
biblioteca gestionar los usuarios del sistema.
RF-21 La plataforma SIBUCO debe permitir al personal de la W 1.0
biblioteca visualizar la lista de usuarios por orden según:
apellidos, tipo o fecha de registro.
RF-22 La plataforma SIBUCO debe permitir a los usuarios solicitar S 1.0
la recuperación de la contraseña.
RNF-01 La plataforma SIBUCO debe ser capaz de operar con hasta M 1.0
100 usuarios con sesiones recurrentes.
RNF-02 La plataforma SIBUCO debe mantener un tiempo de M 1.0
respuesta inferior a 10 segundos para cualquier
funcionalidad siempre que haya 20 o menos usuarios
haciendo uso de esta.
RNF-03 La plataforma SIBUCO debe estar operativo las 24 horas del M 1.0
día a lo largo de todos los días de la semana.
RNF-04 La plataforma SIBUCO debe tener un tiempo de aprendizaje S 1.0
por usuario menor a 3 horas.
RNF-05 La plataforma SIBUCO debe asegurar que los datos estén M 1.0
protegidos del acceso no autorizado.
RNF-06 La plataforma SIBUCO debe estar disponible en los idiomas S 1.0
español, inglés y francés.
RNF-07 La plataforma SIBUCO debe mantener los datos de los M 1.0
usuarios cifrados de extremo a extremo.
REQUISITOS GEOGRÁFICOS
RG-1 Toda la infraestructura referente al sistema debe estar M 1.0
localizada en un área protegida de la biblioteca.
RG-2 La plataforma SIBUCO solamente podrá ser gestionada con M 1.0
todos los permisos de administración desde la red de la
biblioteca.
RG-3 La plataforma SIBUCO podrá ser utilizada en cualquier lugar M 1.0
por usuarios registrados y no registrados.
P á g i n a 22
REQUISITOS TECNOLÓGICOS
RT-1 La aplicación SIBUCO debe ser compatible con las versiones M 1.0
8 y 10 de Windows.
RT-2 La aplicación SIBUCO deberá consumir menos de 2 GB de M 1.0
memoria RAM.
RT-3 La plataforma SIBUCO deber ser compatible con los M 1.0
navegadores Google Chrome y Mozilla Firefox.
RT-4 La aplicación SIBUCO deber estar disponible para su M 1.0
descarga en sistemas iOS y Android.
RT-5 La aplicación no podrá ocupar más de 15 GB de espacio en M 1.0
disco.
RT-6 Las bases de datos deben estar conectadas entre sí. M 1.0
P á g i n a 23
ACTIVIDAD EVS 4: ESTUDIO DE
ALTERNATIVAS DE SOLUCIÓN
Con respecto a esta actividad, se llevará a cabo un estudio centrado en la proposición de
múltiples alternativas que respondan satisfactoriamente a los requisitos planteados, considerando
también los resultados obtenidos en el Estudio de la Situación Actual (EVS 2).
Técnicas y
Prácticas
EVS 4.1 - Preselección de - Alternativas de - Diagramas de - Jefe de Proyecto
Alternativas de Solución a Estudiar Representación - Analistas
Solución
EVS 4.2 - Descripción de las - Alternativas de - Catalogación - Jefe de Proyecto
Alternativas de Solución a Estudiar - Analistas
Solución
P á g i n a 24
Tarea EVS 4.1: Preselección de Alternativas de Solución
Una vez definidos los requisitos a cubrir por el sistema, se estudian las diferentes opciones
que hay para configurar la solución. Entre ellas, hay que considerar la adquisición de productos
software estándar del mercado, desarrollos a medida o soluciones mixtas.
Dependiendo del alcance del sistema y las posibles opciones, puede ser conveniente
realizar inicialmente una descomposición del sistema en subsistemas. Se establecen las posibles
alternativas sobre las que se va a centrar el estudio de la solución, combinando las opciones que
se consideren más adecuadas.
A continuación, se muestra la descomposición del sistema en subsistemas:
• Gestión de usuarios: Realizará el registro, inicio de sesión y actualizar los usuarios
en la base de datos.
• Gestión de libros: Realizará la actualización de los estados de los libros de la base
de datos y lo relacionado con estos
• Gestión de calendario: Realizará un calendario que contendrá las fechas de todos
los préstamos reservas y fechas de devolución.
Este es el planteamiento de alternativas y su solución:
• Adquirir un software ya creado: En primer lugar, esta opción sería la más económica,
ya que el mercado ofrece una amplia variedad de productos fácilmente adaptables al
presupuesto. También se ahorraría una gran cantidad de tiempo puesto que la mayoría
de las herramientas se instalarán en breves minutos. Sin embargo, deberíamos
seleccionar el software muy a medida; este debe ofrecernos todas las necesidades del
sistema y esta selección será muy difícil.
• Desarrollar un software a medida: Por otra parte, esta opción sería más costosa, por lo
que se necesita hacer una inversión considerable. En cuanto al tiempo de espera, sería
mucho mayor, ya que ciertas actividades como el diseño de la herramienta o realizar las
pruebas y evaluaciones. Al desarrollar el software a medida, puedes diseñar todas las
funcionalidades que sean necesarias para el sistema; tiene un alto grado de adaptabilidad.
Esto también sería útil para un posible cambio de las necesidades del sistema, bastaría
con actualizar el software para ajustarlo a los nuevos planes
• Solución mixta: Es una combinación entre las dos propuestas anteriores. Sería barato,
porque podemos escoger la mitad de funcionalidades ya creadas y la otra mitad
desarrollarlas por nosotros mismos. De igual forma sería el tiempo, si esta requiere poco
desarrollo de software.
Como representación esquemática de las alternativas y sus especificaciones hemos
realizado el siguiente diagrama:
P á g i n a 25
Imagen 3 – Diagrama de representación de alternativas
P á g i n a 26
Tarea EVS 4.2: Descripción de las Alternativas de Solución
Para cada alternativa propuesta, se identifican los subsistemas que cubre y los requisitos
a los que se da respuesta.
Se deben considerar también aspectos relativos a la cobertura geográfica (ámbito y
limitaciones) de procesos y datos, teniendo en cuenta a su vez la gestión de comunicaciones y
control de red.
En la definición de cada alternativa, se propone una estrategia de implantación teniendo
en cuenta tanto la cobertura global del sistema como la cobertura geográfica.
Si la alternativa incluye desarrollo se describe el modelo abstracto de datos y el modelo
de procesos, y en el caso de Orientación a Objetos, el modelo de negocio y, opcionalmente, el
modelo de dominio. Se propone el entorno tecnológico que se considera más apropiado para la
parte del sistema basada en desarrollo y se describen los procesos manuales.
Si la alternativa incluye una solución basada en producto se analiza su evolución prevista,
adaptabilidad y portabilidad, así como los costes ocasionados por licencias, y los estándares del
producto. Igualmente se valora y determina su entorno tecnológico.
Adquirir un software ya creado
• Subsistemas: Esta alternativa cubrirá 3 subsistemas: gestión de usuarios, gestión de libros
y gestión de calendario.
• Catálogo de requisitos actualizado: De los requisitos funcionales se obtiene respuesta de
la mayoría de ellos, y de los funcionales todos; puesto que es fundamental obtener una
respuesta del diseño. Todos los requisitos, funcionales como no funcionales se cubrirán
con todos los subsistemas establecidos.
• Localización Geográfica: Será Córdoba, puesto que el software será diseñado para la
biblioteca de la Universidad de Córdoba.
• Entorno tecnológico y comunicaciones: Será el servidor de conexión que proporciona la
Universidad de Córdoba.
• Estrategia de Implantación Global del Sistema: Gracias a la herramienta de Moodle,
tenemos acceso a todo tipo de contacto con los usuarios. Un método de implantación sería
notificar a todos los alumnos de la Universidad de Córdoba que se ha obtenido un nuevo
software para la biblioteca de la universidad y se daría acceso al mismo. De la misma
forma, se pondrían paneles informativos alrededor de todas las facultades de estudio para,
así, notificar al alumno de manera online y presencial.
Desarrollo de software a medida
• Subsistemas: En esta alternativa, se cubriría el 100% de los subsistemas de forma
completa, ya que el software es desarrollado específicamente para ello, proporcionando
así, la totalidad de las funcionalidades esperadas.
• Catálogo de requisitos actualizado: Debido al tipo de desarrollo en el que trataremos, se
cumplirán la totalidad de los requisitos, tanto funcionales, como no funcionales,
geográficos y tecnológicos.
P á g i n a 27
Solución mixta
• Subsistemas: Esta propuesta cubrirá los subsistemas de gestión de usuarios, gestión de
libros y gestión de calendario.
• Catálogo de requisitos actualizado: Al ser esta alternativa una combinación de las dos
anteriores, se obtendrían casi todas las funcionalidades, supliendo las faltas de las
mismas al adquirir software a través del software desarrollado.
P á g i n a 28
ACTIVIDAD EVS 5: VALORACIÓN DE LAS
ALTERNATIVAS
A continuación, se procede a la valoración de las alternativas especificadas y detalladas
en la actividad anterior, considerando el impacto en la organización, tanto desde el punto de vista
tecnológico y organizativo como de operación, y los posibles beneficios que se esperan
contrastados con los costes asociados. También, se llevará a cabo un análisis de los riesgos,
determinando posteriormente, cómo enfocar el plan de acción para minimizar los mismos.
Asimismo, se calcularán los recursos y plazos precisos para planificar cada alternativa.
Técnicas y
Prácticas
EVS 5.1 - Estudio de la - Valoración de - Análisis Coste / - Jefe de Proyecto
Inversión Alternativas: Beneficio - Analistas
• Impacto en la
Organización de
Alternativas
• Coste / Beneficio de
Alternativas
EVS 5.2 - Estudio de los - Valoración de - Impacto en la - Jefe de Proyecto
Riesgos Alternativas: Organización - Analistas
• Valoración de
Riesgos
EVS 5.3 - Planificación de - Plan de Trabajo de Cada - Planificación - Jefe de Proyecto
Alternativas Alternativa: - Analistas
• Enfoque del Plan de
Trabajo de Cada
Alternativa
• Planificación de
Cada Alternativa
P á g i n a 29
Tarea EVS 5.1: Estudio de la Inversión
A continuación, llevaremos a cabo la valoración del impacto en la organización y la
determinación de la viabilidad económica para cada alternativa de solución propuesta, mediante
un análisis coste/beneficio que determina los costes del sistema y los pondera con los beneficios
tangibles, cuantificables directamente, y con los beneficios intangibles, buscando el modo de
cuantificarlos.
Valoración de Alternativas:
Para la resolución de este apartado, procedemos con el análisis de los puntos de función
asociados al sistema, que nos permitirá medir las funcionalidades que se le proporcionan al
usuario conjuntamente con la primera instalación del software producido cuando el proyecto esté
terminado.
Primeramente, dividimos el sistema en componentes de entrada (EI), salida (EO), consulta
(EQ) y en ficheros (lógicos internos (ILF) y lógicos externos (ELF)).
Funciones transaccionales Ficheros lógicos
EI EO EQ ILF ELF
Iniciar sesión Cerrar sesión Consultar Registrar libro Registrar usuario
reserva
Buscar libro Notificar Consultar Registrar reserva Editar usuario
disponibilidad multas
Buscar usuario Notificar Consultar Formalizar
expiración préstamo préstamo
devolución
Generar informe Consultar Anular reserva
de libros disponibilidad
de libros
Generar informe Ampliar reserva
de préstamos
Generar informe Eliminar libro
de usuarios con
multas
Editar libro
Registrar multa
Anular multa
Finalizar préstamo
Formalizar
devolución
Seguidamente, sabiendo que la complejidad de los ficheros lógicos, tanto internos como
externos se basa en la cuenta de DETs y RETS, procedemos a la extracción de estos:
En primer lugar, contaremos los DETS, sabiendo que debemos contar un DET por cada
uno de los campos reconocibles por el usuario que componen el fichero. Luego, tras llevar a cabo
el conteo sobre el diagrama de entidad - relación definido previamente, nos quedan los siguientes:
P á g i n a 30
CONTEO DETS
Entidad
Usuario Reserva Préstamo Ejemplar Libro Total
Registrado
usuario id_reserva id_prestamo codigo_ejemplar codigo_libro
contraseña
e-mail
plazo_reserva
titulo_libro
plazo_prestamo estado
titulo_libro
titulo
autores
21
nombre_completo nombre_usuario edicion
Fecha_nacimiento categoria
editorial
tipo
En segundo lugar, contaremos los RETS, sabiendo que debemos contar un RET cada
subgrupo de datos elementales reconocibles por el usuario. Luego, tras llevar a cabo el conteo
sobre el diagrama de entidad - relación definido previamente, nos quedan los siguientes:
CONTEO RETS
Entidad Total
Usuario Reserva Préstamo Ejemplar Libro
Registrado 5
Una vez identificados los DETs y RETs, utilizamos la siguiente tabla para determinar su
complejidad:
1 a 19 DETs 20 a 50 DETs 51 o más DETs
1 RET Baja Baja Media
2 a 5 RETs Baja Media Alta
6 o más RETs Media Alta Alta
Posteriormente, tras haber determinado el tipo de complejidad, que en nuestro caso será
media, procedemos a determinar el número de puntos de función a obtener según las
complejidades y el tipo de función:
• EI
Tipos de función Puntos de función Puntos de función Puntos de función
(Dificultad baja) (Dificultad media) (Dificultad alta)
Entrada x3PF x4PF x6PF
• EO
Salida x4PF x5PF x7PF
P á g i n a 31
• EQ
Consulta x3PF x4PF x6PF
• ILF
Fichero Lógico x7PF x10PF x15PF
Interno
• ELF
Fichero Lógico x5PF x7PF x10PF
Externo
• Total de PF sin ajustar

Tipos de Puntos de Puntos de Puntos de
función función función función
(Dificultad baja) (Dificultad (Dificultad alta)
TOTAL
media)
Entrada 2 x 3PF 1 x 4PF 0 x 6PF 10
Salida 3 x 4PF 2 x 5PF 1 x 7PF 29
Consulta 0 x 3PF 3 x 4PF 1 x 6PF 18
Fichero Lógico 11 x 7PF 0 x 10PF 0 x 15PF 10
Interno
Fichero Lógico 2 x 5PF 0 x 7PF 0 x 10PF 77
Externo
TOTAL 105PF 26PF 13PF 144PF
El siguiente paso es el Ajuste de los Puntos de Función. Su objetivo es la adaptación de

la estimación a las condiciones de trabajo bajo las que el sistema ha de ser desarrollado. De aquí
se obtiene el valor definitivo en Puntos de Función del Sistema.
Existen 14 atributos de ajuste que impactan en el desarrollo y a cada uno se le asigna un
valor entre 0 y 5. Estos son:
• Sin influencia (0): El sistema no contempla este atributo
• Influencia mínima (1): La influencia de este atributo es muy poco significativa.
• Influencia moderada (2): El sistema contempla este atributo y su influencia, aunque
pequeña, ha de ser considerada
• Influencia apreciable (3): La importancia de este atrbuto debe ser tenida en cuenta,
aunque no es fundamental
P á g i n a 32
• Influencia significativa (4): Este atributo tiene una gran importancia para el Sistema
• Influencia muy fuerte (5): Este atributo es esencial para el Sistema y ha de ser tenido en
cuenta a la hora del diseño.
Después de analizar cada atributo enfocado al sistema, llevamos a cabo la estimación de
la influencia de todos y cada uno de ellos, obteniendo como resultado los siguientes valores:
• Comunicación de datos - Influencia 4
• Funciones distribuidas - Influencia 5
• Prestaciones - Influencia 4
• Gran uso de la configuración - Influencia 3
• Velocidad de las transacciones - Influencia 4
• Entrada de datos en línea - Influencia 5
• Diseño para la eficiencia del usuario final - Influencia 4
• Actualización de datos en línea- Influencia 4
• Complejidad del proceso lógico interno de la aplicación - Influencia 1
• Reusabilidad del código - Influencia 3
• Facilidad de instalación - Influencia 1
• Facilidad de operación - Influencia 3
• Localizaciones múltiples - Influencia 2
• Facilidad de cambios - Influencia 3
De modo que la suma de la influencia total sería de 44. A partir de dicha suma,
procedemos a la obtención del factor de ajuste mediante la siguiente fórmula:
𝐹𝐴 = 0,65 + (0,01 ∗ 𝑆𝑉𝐴) FA = Factor de ajuste

SVA = Suma de los valores de los atributos
𝐹𝐴 = 0,65 + (0,01 ∗ 44) = 1,09
Sabiendo el total de puntos de función sin ajustar y el factor de ajuste, aplicamos la

siguiente fórmula para hallar los puntos de función ajustados:
𝑃𝐹𝐴 = 𝑃𝐹𝑁𝐴 ∗ 𝐹𝐴 PFA = Puntos de función ajustados

PFNA = Puntos de función no ajustados
FA = Factor de ajuste
𝑃𝐹𝐴 = 144 ∗ 1,09 = 156,96
P á g i n a 33
A continuación, haremos el cálculo del tiempo en días de esfuerzo. Bastará multiplicar el
valor PFA por los días en que se valore cada Punto de Función. Según los valores medios de la
industria informática, 1 Mes de esfuerzo (21 días aprox.) equivale a 13 Puntos de Función. Por lo
que, si un mes equivale a 13PF, 1 día será: 13/21 = 0,62. Al día se desarrollan 0,62PF por persona.
En cuanto a las personas integrantes, sabemos que son 2 (analista de requisitos y
arquitecto de software), luego:
𝑃𝐹/𝑑𝑖𝑎′ = 0,62 ∗ 2 = 1,24 𝑃𝐹

𝑃𝐹/𝑚𝑒𝑠 = 1,24 ∗ 21 = 26,04 𝑃𝐹
Por tanto, el tiempo en días de esfuerzo será:
𝐸𝑠𝑓𝑢𝑒𝑟𝑧𝑜 = 156,96/1,24 = 126 𝑑í𝑎𝑠 𝑎𝑝𝑟𝑜𝑥, 𝑞𝑢𝑒 𝑐𝑜𝑟𝑟𝑒𝑠𝑝𝑜𝑛𝑑𝑒 𝑎 6 𝑚𝑒𝑠𝑒𝑠.
Después, veremos el coste del personal del proyecto y las unidades de medida. El analista
de requisitos cobra 3700€ y el arquitecto del software cobra 4200€. El coste total será de 7700€.
A continuación, calcularemos el costo por unidad de medida. En un mes, el equipo puede
desarrollar aproximadamente 26 puntos de función, por lo que:
𝐶𝑜𝑠𝑡𝑜 𝑝𝑜𝑟 𝑢𝑛𝑖𝑑𝑎𝑑 𝑑𝑒 𝑚𝑒𝑑𝑖𝑑𝑎 = 𝐶𝑜𝑠𝑡𝑜 𝑡𝑜𝑡𝑎𝑙 / 𝑛º 𝑑𝑒 𝑢𝑛𝑖𝑑𝑎𝑑𝑒𝑠 𝑑𝑒 𝑚𝑒𝑑𝑖𝑑𝑎

𝐶𝑜𝑠𝑡𝑜 𝑝𝑜𝑟 𝑢𝑛𝑖𝑑𝑎𝑑 𝑑𝑒 𝑚𝑒𝑑𝑖𝑑𝑎 = 7700/26 = 296€
Más adelante, hallaremos el presupuesto del proyecto a través de la siguiente fórmula:
𝑃𝑟𝑒𝑠𝑢𝑝𝑢𝑒𝑠𝑡𝑜 = 𝑃𝐹 ∗ 𝐶𝑜𝑠𝑡𝑜 𝑝𝑜𝑟 𝑢𝑛𝑖𝑑𝑎𝑑 𝑑𝑒 𝑚𝑒𝑑𝑖𝑑𝑎

144 ∗ 296 = 42.624€
Este coste será aplicado únicamente en la solución mixta debido a que en las demás
alternativas ya existe un coste definido.
Ahora, procedemos al modelo de análisis coste/beneficio, que nos permitirá distinguir qué
alternativa presenta un retorno de inversión más alto.
Dicho retorno de inversión (ROI), será calculado mediante la siguiente fórmula para cada
alternativa:
𝑅𝑂𝐼 = 100 ∗ (𝐵𝑒𝑛𝑒𝑓𝑖𝑐𝑖𝑜 𝑁𝑒𝑡𝑜 𝐴𝑛𝑢𝑎𝑙 − 𝐶𝑜𝑠𝑡𝑒 𝐷𝑒𝑠𝑎𝑟𝑟𝑜𝑙𝑙𝑜 𝐴𝑛𝑢𝑎𝑙𝑖𝑧𝑎𝑑𝑜)/𝐼𝑛𝑣𝑒𝑟𝑠𝑖ó𝑛
P á g i n a 34
• Opción 1: Solución Mixta
Suponiendo:
- Beneficio neto anual estimado en 10.000 €.
- Operatividad del sistema de 5 años.
- Inversión de 42.624 €.
- Se invierte en hardware, software, costes de desarrollo
Nos queda el siguiente retorno de inversión:
𝑅𝑂𝐼 = 100 ∗ (10.000 − 42.624/5)/(42.624/3) = 10,38%
• Opción 2: Adquisición de software

Suponiendo:
- Se invierte únicamente en el software.
𝑅𝑂𝐼 = 100 ∗ (6.000 − 21.500/5)/(21.500/1) = 7,91%
• Opción 3: Desarrollo del software a medida
Suponiendo:
- Se invierte en hardware y coste de desarrollo.
𝑅𝑂𝐼 = 100 ∗ (12.000 − 49.000/5)/(49.000/2) = 8,98%
Por lo tanto, respecto al ROI, podemos deducir que la mejor alternativa será la solución mixta.
P á g i n a 35
Tarea EVS 5.2: Estudio de los Riesgos
Valoración de riesgos
1) Adquirir un software ya creado: Un riesgo puede ser no proporcionar el software en el
tiempo estimado. Una solución sería estimar poco a poco si el software tendrá o no algún
retraso en el desarrollo. Otro riesgo sería la mala adaptación del mismo, puede ocurrir que
el software no cumpla con las funcionalidades mínimas para su lanzamiento. Para ello,
podríamos adoptar la misma solución anterior, para reaccionar ante el problema.
2) Desarrollar un software a medida: Al igual que en la primera alternativa, también podría
ser un riesgo riesgo no proporcionar el software en el tiempo estimado. Una solución sería
estimar poco a poco si el software tendrá o no algún retraso en el desarrollo. Desarrollar
un software puede traer problemas a la hora de la codificación, por eso es fundamental
una buena especificación de requisitos.
3) Solución mixta: Al ser una combinación de ambas propuestas, presenta los riesgos de
ambas y se solucionarían de igual forma.
Para la selección de una alternativa, es necesario un análisis previo de los siguientes factores:
• Coste de adquisición:
- Primera alternativa: 42.624€
- Segunda alternativa: 21.500€
- Tercera alternativa: 49.000€
• Tiempo operativo:
- Primera alternativa: 5 años
- Segunda alternativa: 5 años
- Tercera alternativa: 5 años
• Facilitación de herramientas:
- El nuevo software puede automatizar funciones que realizan los trabajadores de la
biblioteca y así facilitar su trabajo.
P á g i n a 36
Tarea EVS 5.3: Planificación de Alternativas
En función del análisis de riesgos realizado en la tarea anterior, y para cada una de las
alternativas existentes:
- Se determina el enfoque más adecuado para llevar a buen fin la solución propuesta
en cada alternativa.
- Se realiza una planificación, teniendo en cuenta los puntos de sincronismo con otros
proyectos en desarrollo o que esté previsto desarrollar, según se ha recogido en el
catálogo de requisitos. De esta manera se garantiza el cumplimiento del plan de
trabajo en los restantes procesos del ciclo de vida
Plan de trabajo para cada alternativa

Opción 1: Solución mixta
En cuanto al enfoque y plan a seguir para la minimización de riesgos llevaríamos a cabo
los siguientes pasos:
• Definición cuidada y detallada de las múltiples las funcionalidades a cubrir por el sistema,
extremando la precaución en el proceso, con el fin de ahorrarnos posibles fallos,
inconsistencias y ambigüedades que podrían afectar negativamente al desarrollo del
sistema.
• Estudio en profundidad de los posibles software a elegir, analizando el ratio de
cumplimiento y satisfacción con respecto a necesidades, funcionalidades y restricciones
del sistema.
• Elección consensuada con el equipo de trabajo del software que más se adapte a nuestras
necesidades
• Observación detallada durante el desarrollo para prevenir posibles errores y resolver
dudas en cualquier aspecto, con el objetivo de evitar futuros retrasos del sistema.
• Pulir, retocar y completar el software con las partes restantes necesitadas.
Opción 2: Adquisición de software
• Redacción de un informe que contemple todo el progreso ocasionado desde la solicitud
de los softwares asociados a los subsistemas definidos.
• Estudio previo del producto a adquirir, realizando un informe de cumplimiento de los
aspectos esperados.
• Revisión periódica para prevenir posibles errores y resolver dudas en cualquier aspecto,
con el objetivo de evitar futuros retrasos del sistema.
Opción 3: Desarrollo del software a medida
• Documentación con alto nivel descriptivo y concreto durante todo el proceso de desarrollo,
especialmente, con las funcionalidades ocupadas en los subsistemas, evitando así errores
P á g i n a 37
funcionales y de entendimiento que terminarían por generar numerosos problemas en el
avance.
• Revisión periódica para prevenir posibles errores y resolver dudas en cualquier aspecto,
con el objetivo de evitar futuros retrasos del sistema.
P á g i n a 38
ACTIVIDAD EVS 6: SELECCIÓN DE LA
SOLUCIÓN
Por último, tras convocar al Comité de Dirección para la presentación de las distintas
alternativas de solución, se debaten las ventajas de cada una de ellas, incorporando las
modificaciones que se consideren oportunas, con el fin de seleccionar la más adecuada, para así,
finalizar con la aprobación de la solución o la determinación de su inviabilidad.
Técnicas y
Prácticas
EVS 6.1 - Convocatoria de - Plan de Presentación de - Presentación - Jefe de Proyecto
Presentación Alternativas
EVS 6.2 - Evaluación de - Plan de Presentación de - Presentación - Comité de
Alternativas y Alternativas - Sesiones de Dirección
Selección Trabajo - Jefe de Proyecto
- Analistas
EVS 6.3 - Aprobación de la - Aprobación de la - Planificación - Comité de
Solución Solución Dirección
- Jefe de Proyecto
P á g i n a 39
Tarea EVS 6.1: Convocatoria de la Presentación
Se efectúa la convocatoria de la presentación de las distintas alternativas propuestas,
adjuntando los productos de la actividad anterior con el fin de que el Comité de Dirección pueda
estudiar previamente su contenido. Se espera confirmación por parte del Comité de Dirección de
las alternativas a presentar.
En dicha presentación se incluirá el planteamiento de las tres alternativas, explicando la
inversión que supone cada una, el análisis realizado previamente de costes/beneficios haciendo
referencia a retorno de inversión de cada una, el plan de reducción de riesgos a seguir, en el que
se mencionan los riesgos presentes en cada alternativa y como se abordarían, para concluir con
una síntesis de las ventajas y desventajas de cada una. Además, se preparará una introducción
previa, tratando el sistema de forma contextual, incluyendo el presupuesto disponible y el alcance
de éste.
P á g i n a 40
Tarea EVS 6.2: Evaluación de las Alternativas y Selección
Una vez recibida la confirmación de qué alternativas van a ser presentadas para su
valoración, se efectúa su presentación al Comité de Dirección, debatiendo sobre las ventajas e
inconvenientes de cada una de ellas y realizando las modificaciones que sugiera dicho Comité,
hasta la selección de la solución final.
A continuación, se exponen las ventajas y desventajas de cada alternativa:
Opción 1: Solución mixta
Pros Contras
Resultado final esperado casi completo Coste de inversión elevado
Tiempo de desarrollo moderadamente bajo
Nivel de dificultad moderado
Posee el ROI más elevado
Opción 2: Adquisición del software
Pros Contras
Posee el coste de inversión más barato Lejos del resultado final esperado
Tiempo de desarrollo bajo Necesidad de adquirir software por cada
subsistema
Nivel de dificultad bajo Posee el ROI más bajo
Opción 3: Desarrollo a medida del software
Pros Contras
Resultado final esperado completo Coste de inversión elevado
Mayor adaptabilidad a las necesidades del Nivel de dificultad elevado
sistema
Tiempo de desarrollo elevado
Luego, si reflejamos los beneficios y las contras de cada alternativa en una tabla
comparativa, nos quedaría lo siguiente:
Ajustado a Tasa de Coste de Tiempo de Dificultad Cercanía
las retorno inversión desarrollo al
TOTAL
necesidad resultado
es esperado
Opción 1 2 3 2 2 2 2 13
Opción 2 1 1 3 3 3 1 12
Opción 3 3 2 1 1 1 3 11
Cada apartado está evaluado del 1 al 3, siendo la mejor puntuación el 3 y la peor el 1.
P á g i n a 41
Tarea EVS 6.3: Aprobación de la Solución
Por último, el Comité de Dirección dará su aprobación formal o determinará la inviabilidad
del sistema, por motivos económicos, de funcionalidad como resultado del incumplimiento de los
requisitos identificados en plazos razonables o de cobertura de los mismos, etc.
Para finalizar este análisis, se detallará la conclusión llegada a través de las diferentes
alternativas del sistema. Como se puede observar en el estudio realizado en el apartado EVS 6.2,
en base a los factores de las necesidades que satisface al cliente, la tasa de retorno, el coste de
inversión, el tiempo de desarrollo, la dificultad y la cercanía al resultado esperado, concluimos que
la mejor opción es la dos, concretamente la solución mixta.
P á g i n a 42

Practica 3

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Practica 3

Cargado por

Copyright:

Formatos disponibles

AA SYSTEMS

Informe técnico del proyecto, Plan de

Antonio Cabezas Jarabo

Tarea Productos Técnicas y Prácticas Participantes

Descripción general del sistema

Catálogo de objetivos EVS

• PAS: Es el Personal de Administración y Servicios. Llevarán a cabo las gestiones de la

Las actividades a desarrollar son:

• EVS-1: Establecimiento del alcance del sistema

Descripción lógica de los sistemas de información Establecemos las operaciones a

Imagen 2 – Diagrama Entidad/Relación de la BD

Diagnóstico de la situación actual

Identificación de Requisitos (Funcionales y No Funcionales)

Catálogo de Requisitos (Funcionales, No Funcionales, Geográficos y

• Total de PF sin ajustar

El siguiente paso es el Ajuste de los Puntos de Función. Su objetivo es la adaptación de

𝐹𝐴 = 0,65 + (0,01 ∗ 𝑆𝑉𝐴) FA = Factor de ajuste

Sabiendo el total de puntos de función sin ajustar y el factor de ajuste, aplicamos la

𝑃𝐹𝐴 = 𝑃𝐹𝑁𝐴 ∗ 𝐹𝐴 PFA = Puntos de función ajustados

𝑃𝐹/𝑑𝑖𝑎′ = 0,62 ∗ 2 = 1,24 𝑃𝐹

Por tanto, el tiempo en días de esfuerzo será:

𝐸𝑠𝑓𝑢𝑒𝑟𝑧𝑜 = 156,96/1,24 = 126 𝑑í𝑎𝑠 𝑎𝑝𝑟𝑜𝑥, 𝑞𝑢𝑒 𝑐𝑜𝑟𝑟𝑒𝑠𝑝𝑜𝑛𝑑𝑒 𝑎 6 𝑚𝑒𝑠𝑒𝑠.

𝐶𝑜𝑠𝑡𝑜 𝑝𝑜𝑟 𝑢𝑛𝑖𝑑𝑎𝑑 𝑑𝑒 𝑚𝑒𝑑𝑖𝑑𝑎 = 𝐶𝑜𝑠𝑡𝑜 𝑡𝑜𝑡𝑎𝑙 / 𝑛º 𝑑𝑒 𝑢𝑛𝑖𝑑𝑎𝑑𝑒𝑠 𝑑𝑒 𝑚𝑒𝑑𝑖𝑑𝑎

Más adelante, hallaremos el presupuesto del proyecto a través de la siguiente fórmula:

𝑃𝑟𝑒𝑠𝑢𝑝𝑢𝑒𝑠𝑡𝑜 = 𝑃𝐹 ∗ 𝐶𝑜𝑠𝑡𝑜 𝑝𝑜𝑟 𝑢𝑛𝑖𝑑𝑎𝑑 𝑑𝑒 𝑚𝑒𝑑𝑖𝑑𝑎

• Opción 2: Adquisición de software

Plan de trabajo para cada alternativa

Opción 2: Adquisición del software

Opción 3: Desarrollo a medida del software

Cada apartado está evaluado del 1 al 3, siendo la mejor puntuación el 3 y la peor el 1.

También podría gustarte