Clase 3 - Análisis de Requisitos para Biblioteca - PDF

Clase 3 Ejercicio práctico de análisis de requisitos para un sistema de gestión de biblioteca. Contexto: Una biblioteca universitaria necesita modernizar su sistema de gestión. El sistema actual, basado en fichas y registros en papel, es ineficiente y propenso a errores. La biblioteca busca un sis...

Clase 3 Ejercicio práctico de análisis de requisitos para un sistema de gestión de biblioteca. Contexto: Una biblioteca universitaria necesita modernizar su sistema de gestión. El sistema actual, basado en fichas y registros en papel, es ineficiente y propenso a errores. La biblioteca busca un sistema informático que automatice las tareas clave y mejore la experiencia de los usuarios. 1. Estudio de Factibilidad Objetivo: Determinar si es viable desarrollar un nuevo sistema de gestión de biblioteca con las tecnologías actuales y dentro del presupuesto de la biblioteca. Preguntas clave ¿Existen sistemas de gestión de bibliotecas comerciales que se puedan adaptar a las necesidades de la universidad? ¿Es factible desarrollar un sistema a medida? ¿Cuáles son los costos estimados de desarrollo, implementación y mantenimiento de un nuevo sistema? ¿Se cuenta con los recursos humanos y tecnológicos necesarios para el desarrollo y la gestión del nuevo sistema? 2. Obtención y Análisis de Requerimientos Objetivo: Comprender las necesidades de los usuarios (bibliotecarios, estudiantes, profesores) y definir los servicios que debe ofrecer el sistema. Técnicas Entrevistas: Realizar entrevistas abiertas y cerradas con los diferentes tipos de usuarios para comprender sus necesidades y expectativas. Escenarios: Desarrollar escenarios que describan cómo los usuarios interactuarán con el sistema en diferentes situaciones.  Casos de Uso: Modelar los casos de uso del sistema, identificando los actores, las acciones y los flujos de eventos. Observación: Observar a los bibliotecarios en su trabajo diario para identificar las tareas que podrían automatizarse. 3. Especificación de Requerimientos Objetivo: Documentar los requerimientos del sistema en un formato estandarizado. Tipos de Requerimientos Requerimientos Funcionales: Describir las funciones del sistema, incluyendo: Gestión de usuarios: Registro, autenticación y autorización de diferentes tipos de usuarios (bibliotecarios, estudiantes, profesores). Catálogo de libros: Búsqueda, registro, edición y eliminación de libros. Préstamo de libros: Registro de préstamos, devoluciones, reservas, y gestión de multas por retraso. Gestión de informes: Generación de informes sobre el estado de la biblioteca, el uso del sistema, los libros más populares, etc. Requerimientos No Funcionales: Definir las restricciones sobre el sistema, incluyendo: Rendimiento: Tiempos de respuesta del sistema para las diferentes operaciones. Seguridad: Protección de la información y restricción del acceso a funciones sensibles. Disponibilidad: El sistema debe estar disponible las 24 horas del día, los 7 días de la semana. Usabilidad: La interfaz del sistema debe ser intuitiva y fácil de usar para todos los tipos de usuarios. 4. Validación de Requerimientos Objetivo: Asegurar que los requerimientos sean completos, consistentes y realistas. Técnicas: Revisión de Requerimientos: Los usuarios y el equipo de desarrollo revisan el documento de requerimientos para identificar errores, omisiones o inconsistencias. Prototipos: Desarrollar prototipos del sistema para validar la interfaz de usuario y la funcionalidad principal. Herramientas de Desarrollo: Una Herramientas UML: Utilizar esta herramienta para modelar los casos de uso, los diagramas de clases, los diagramas de secuencia, etc  Ejercicio de Aplicación Análisis de Requisitos: Sistema de Gestión de Biblioteca Universitaria 1. Estudio de Factibilidad Objetivo Determinar la viabilidad de desarrollar un nuevo sistema de gestión de biblioteca con las tecnologías actuales y dentro del presupuesto de la Biblioteca Central de la Universidad Tecnológica de Ejemplolandia. Análisis de Factibilidad Sistemas comerciales vs. Desarrollo a medida Tras una investigación de mercado, se identificaron tres sistemas comerciales de gestión de bibliotecas: 1. LibraryMaster Pro: $50,000 licencia inicial + $10,000 anuales 2. EduLib Suite: $75,000 licencia inicial + $15,000 anuales 3. OpenSource LibrarySystem: Gratuito, pero requiere personalización Desarrollo a medida (estimación inicial): Costo de desarrollo: $120,000 Tiempo estimado: 8 meses Mantenimiento anual: $20,000 Análisis de costos (5 años) Opción Año 1 Año 2 Año 3 Año 4 Año 5 Total LibraryMaster Pro $60,000 $10,000 $10,000 $10,000 $10,000 $100,000 EduLib Suite $90,000 $15,000 $15,000 $15,000 $15,000 $150,000 OpenSource $40,000 $10,000 $10,000 $10,000 $10,000 $80,000 LibrarySystem Desarrollo a medida $120,000 $20,000 $20,000 $20,000 $20,000 $200,000 Recursos disponibles Equipo de TI de la universidad: 2 desarrolladores senior, 1 analista de sistemas, 1 diseñador UX Infraestructura: Servidores virtualizados con capacidad de expansión Presupuesto asignado: $150,000 para el primer año, $30,000 anuales para mantenimiento Conclusión del Estudio de Factibilidad Basándonos en el análisis de costos y recursos disponibles, se recomienda proceder con el desarrollo a medida del sistema de gestión de biblioteca. Aunque inicialmente es más costoso, ofrece las siguientes ventajas: 1. Personalización completa según las necesidades específicas de la universidad. 2. Control total sobre el desarrollo y las actualizaciones futuras. 3. Aprovechamiento de los recursos internos de TI. 4. Posibilidad de expandir el sistema en el futuro sin depender de proveedores externos. El costo total en 5 años está dentro del presupuesto asignado, y el desarrollo a medida permite una mejor adaptación a largo plazo. 2. Obtención y Análisis de Requerimientos Entrevistas Se realizaron entrevistas con los siguientes grupos de usuarios: 1. Bibliotecarios (5 entrevistados) 2. Estudiantes (20 entrevistados) 3. Profesores (10 entrevistados) 4. Personal administrativo (3 entrevistados) Resumen de necesidades identificadas: Bibliotecarios: o Sistema de catalogación eficiente o Gestión automatizada de préstamos y devoluciones o Generación de informes y estadísticas Estudiantes: o Búsqueda rápida y precisa de libros o Reserva de libros en línea o Acceso a recursos digitales Profesores: o Reserva de material para cursos o Notificaciones sobre nuevas adquisiciones o Sugerencias de compra de libros Personal administrativo: o Gestión de presupuesto y adquisiciones  o Integración con el sistema de gestión académica Escenarios 1. Escenario: Préstamo de libro María, una estudiante de ingeniería, necesita un libro para su proyecto. Ingresa al sistema, busca el libro, lo encuentra disponible y lo reserva. Al día siguiente, va a la biblioteca, se identifica con su carné estudiantil, y el bibliotecario registra el préstamo en el sistema. 2. Escenario: Devolución tardía Juan, un profesor, devuelve un libro con 5 días de retraso. El sistema automáticamente calcula la multa, la registra en su cuenta y le envía una notificación por email con los detalles. 3. Escenario: Adquisición de nuevos libros La Dra. López sugiere la compra de 10 nuevos títulos para su curso. El bibliotecario jefe revisa la sugerencia, verifica el presupuesto en el sistema y aprueba la compra. El sistema genera automáticamente una orden de compra. Casos de Uso https://www.planttext.com/ https://plantuml.com/es/ https://www.plantuml.com/plantuml/uml/ @startuml left to right direction actor "Estudiante" as est actor "Profesor" as prof actor "Bibliotecario" as bib actor "Administrador" as admin rectangle "Sistema de Gestión de Biblioteca" { usecase "Buscar Libro" as UC1 usecase "Reservar Libro" as UC2 usecase "Prestar Libro" as UC3 usecase "Devolver Libro" as UC4 usecase "Gestionar Catálogo" as UC5 usecase "Generar Informes" as UC6 usecase "Gestionar Usuarios" as UC7 usecase "Sugerir Compra" as UC8 } est --> UC1 est --> UC2 prof --> UC1 prof --> UC2 prof --> UC8 bib --> UC3 bib --> UC4 bib --> UC5 bib --> UC6 admin --> UC7 admin --> UC6 @enduml Este diagrama de casos de uso muestra las principales interacciones de los diferentes tipos de usuarios con el sistema de gestión de biblioteca. Observación Se realizó una observación de 3 días en la biblioteca, siguiendo a los bibliotecarios en sus tareas diarias. Se identificaron los siguientes procesos que podrían automatizarse: 1. Registro manual de préstamos y devoluciones 2. Búsqueda de libros en fichas físicas 3. Conteo manual de libros para el inventario 4. Cálculo manual de multas por retraso 3. Especificación de Requerimientos Requerimientos Funcionales 1. Gestión de Usuarios a. RF1.1: El sistema debe permitir el registro de nuevos usuarios (estudiantes, profesores, personal) b. RF1.2: El sistema debe autenticar a los usuarios mediante ID y contraseña c. RF1.3: El sistema debe asignar permisos basados en el tipo de usuario 2. Catálogo de Libros a. RF2.1: El sistema debe permitir la búsqueda de libros por título, autor, ISBN, o palabras clave b. RF2.2: El sistema debe permitir a los bibliotecarios agregar, editar y eliminar registros de libros c. RF2.3: El sistema debe mostrar la disponibilidad de cada libro en tiempo real 3. Préstamo de Libros a. RF3.1: El sistema debe permitir a los usuarios reservar libros disponibles b. RF3.2: El sistema debe registrar los préstamos y devoluciones de libros c. RF3.3: El sistema debe calcular y aplicar multas por devoluciones tardías automáticamente  4. Gestión de Informes a. RF4.1: El sistema debe generar informes de libros más prestados b. RF4.2: El sistema debe generar informes de usuarios con multas pendientes c. RF4.3: El sistema debe generar informes de inventario de libros Requerimientos No Funcionales 1. Rendimiento a. RNF1.1: El sistema debe cargar los resultados de búsqueda en menos de 3 segundos b. RNF1.2: El sistema debe soportar hasta 500 usuarios concurrentes sin degradación del rendimiento 2. Seguridad a. RNF2.1: Todas las contraseñas deben almacenarse encriptadas b. RNF2.2: El sistema debe realizar copias de seguridad diarias de la base de datos 3. Disponibilidad a. RNF3.1: El sistema debe estar disponible el 99.9% del tiempo b. RNF3.2: El mantenimiento programado debe realizarse fuera del horario de atención de la biblioteca 4. Usabilidad a. RNF4.1: La interfaz de usuario debe ser responsive y funcionar en dispositivos móviles b. RNF4.2: El sistema debe proporcionar ayuda contextual para todas las funciones principales 4. Validación de Requerimientos Revisión de Requerimientos Se realizó una reunión de revisión con representantes de cada grupo de usuarios y el equipo de desarrollo. Los principales puntos de discusión fueron: 1. Clarificación de los procesos de reserva y préstamo 2. Definición de los tipos de informes necesarios 3. Ajuste de los tiempos de respuesta esperados del sistema Prototipos Se desarrollaron prototipos de baja fidelidad para las siguientes interfaces: 1. Página de inicio y búsqueda de libros 2. Perfil de usuario y gestión de préstamos  3. Panel de administración para bibliotecarios Los prototipos se presentaron a un grupo de usuarios para obtener retroalimentación, lo que resultó en ajustes en la disposición de los elementos y la adición de algunas funcionalidades no consideradas inicialmente. Herramientas de Desarrollo Se utilizó Una Herramientas UML para crear los siguientes diagramas: 1. Diagrama de Casos de Uso (presentado anteriormente) 2. Diagrama de Clases @startuml class Usuario { -id: int -nombre: string -email: string -tipo: TipoUsuario +prestarLibro(libr o: Libro): void +devolverLibro(lib ro: Libro): void } class Libro { -isbn: string -titulo: string -autor: string -disponible: boolean +reservar(): void +prestar(): void +devolver(): void } class Prestamo { -id: int -fechaPrestamo: Date - fechaDevolucion: Date +calcularMulta(): float } class Biblioteca { +buscarLibro(crit erio: string): List +generarInforme( tipo: TipoInforme): Informe } class Informe { -contenido: string +mostrar(): void } enum TipoUsuario { ESTUDIANTE PROFESOR BIBLIOTECARIO ADMINISTRADOR } enum TipoInforme { LIBROS_PRESTAD OS USUARIOS_MOR OSOS INVENTARIO } Usuario "1" -- "0..*" Prestamo : realiza > Libro "1" -- "0..*" Prestamo : es prestado en > Biblioteca "1" -- "0..*" Libro : contiene > Biblioteca "1" -- "0..*" Usuario : gestiona > Biblioteca "1" -- "0..*" Informe : genera > @enduml Este diagrama de clases muestra la estructura básica del sistema de gestión de biblioteca, incluyendo las principales entidades y sus relaciones. 3. Diagrama de Secuencia para el proceso de préstamo de libro @startuml actor Usuario participant "Interfaz de Usuario" as UI participant "Sistema de Gestión" as Sistema participant "Base de Datos" as BD Usuario -> UI: Buscar libro activate UI UI -> Sistema: buscarLibro(criterio) activate Sistema Sistema -> BD: consultarLibro(criteri o) activate BD BD --> Sistema: resultadosBúsqueda deactivate BD Sistema --> UI: mostrarResultados deactivate Sistema UI --> Usuario: Mostrar libros disponibles Usuario -> UI: Seleccionar libro UI -> Sistema: solicitarPréstamo(libr o, usuario) activate Sistema Sistema -> BD: verificarDisponibilida d(libro) activate BD BD --> Sistema: disponibilidad deactivate BD alt Libro disponible Sistema -> BD: registrarPréstamo(lib ro, usuario) activate BD BD --> Sistema: confirmación deactivate BD Sistema --> UI: préstamoExitoso UI --> Usuario: Mostrar confirmación else Libro no disponible Sistema --> UI: libroNoDisponible UI --> Usuario: Mostrar mensaje de no disponibilidad end deactivate Sistema deactivate UI @enduml Este diagrama de secuencia ilustra el proceso de préstamo de un libro, desde la búsqueda inicial hasta la confirmación del préstamo o la notificación de no disponibilidad. Las siguientes fases del Proyecto son: Las siguientes fases del desarrollo del proyecto, después del análisis de requisitos que hemos completado, típicamente incluirían: 1. Diseño del Sistema 2. Implementación 3. Pruebas 4. Despliegue 5. Mantenimiento y Evolución Fases de Desarrollo del Proyecto: Sistema de Gestión de Biblioteca 1. Diseño del Sistema En esta fase, se traduce la especificación de requisitos en una representación del software que pueda ser evaluada en cuanto a calidad antes de que comience la codificación. Actividades principales: Diseño de la arquitectura del sistema Diseño de la base de datos Diseño de la interfaz de usuario Diseño de componentes y módulos Entregables: Documento de diseño de arquitectura Modelo de datos Wireframes y mockups de la interfaz de usuario Diagramas de componentes y clases detallados 2. Implementación Esta fase implica la codificación del sistema basándose en el diseño realizado. Actividades principales: Configuración del entorno de desarrollo Codificación de los módulos del sistema Implementación de la base de datos Desarrollo de la interfaz de usuario Integración continua de los componentes Entregables: Código fuente del sistema  Base de datos implementada Documentación del código Builds del sistema 3. Pruebas En esta fase se verifica que el sistema cumple con los requisitos especificados y se identifican posibles defectos. Actividades principales: Pruebas unitarias Pruebas de integración Pruebas de sistema Pruebas de aceptación del usuario Pruebas de rendimiento y carga Entregables: Plan de pruebas Casos de prueba Informes de ejecución de pruebas Registro de defectos y su resolución 4. Despliegue Esta fase implica la instalación del sistema en el entorno de producción y la transición del sistema antiguo al nuevo. Actividades principales: Preparación del entorno de producción Migración de datos del sistema antiguo Instalación y configuración del nuevo sistema Capacitación de usuarios finales Puesta en marcha del sistema Entregables: Plan de despliegue Manual de instalación y configuración Manuales de usuario Sistema en producción Informe de cierre del proyecto 5. Mantenimiento y Evolución Esta fase comienza después del despliegue y continúa durante toda la vida útil del sistema. Actividades principales: Corrección de errores Mejoras y actualizaciones del sistema Adaptación a nuevos requisitos o cambios en el entorno Optimización del rendimiento Entregables: Parches y actualizaciones del sistema Documentación actualizada Informes de mantenimiento Propuestas de mejora y evolución del sistema Estas fases representan el ciclo de vida típico de desarrollo de software después de la fase de análisis de requisitos. Es importante notar que, dependiendo de la metodología de desarrollo utilizada (por ejemplo, Agile, Scrum, etc.), estas fases pueden superponerse o iterarse varias veces a lo largo del proyecto. Para el sistema de gestión de biblioteca que hemos analizado, cada una de estas fases tendría sus particularidades. Por ejemplo: 1. En la fase de diseño, se tendría que considerar cuidadosamente la arquitectura para garantizar la escalabilidad y el rendimiento requeridos en los requisitos no funcionales. 2. Durante la implementación, se podría priorizar el desarrollo de módulos clave como la gestión de usuarios y el catálogo de libros. 3. Las pruebas deberían incluir escenarios específicos de la biblioteca, como la gestión de préstamos y devoluciones con diferentes tipos de usuarios. 4. El despliegue probablemente implicaría una migración cuidadosa de los datos existentes y una fase de transición donde ambos sistemas (el antiguo y el nuevo) podrían coexistir temporalmente. 5. En la fase de mantenimiento, se podrían considerar futuras integraciones con otros sistemas universitarios o la incorporación de nuevas tecnologías como RFID para el seguimiento de libros. Enterprise Architecture Versión 17. 22 Septiembre 2024 lanzada. https://sparxsystems.com/ http://www.sparxsystems.com.ar/ http://www.sparxsystems.com.ar/products/ea/trial.php http://www.sparxsystems.com.ar/EAUserGuide/index.html https://sparxsystems.com/enterprise_architect_user_guide/17.0/guide_books/tech_sysml _getting_started.html Download https://www.youtube.com/@enterprisearchitect_es Un Enterprise Architect (EA) se centra en diseñar y planificar la arquitectura de la organización, incluyendo la tecnología, los procesos y la información. En este sentido, la toma de base y el enfoque de un EA pueden variar dependiendo de las necesidades específicas de la organización. Sin embargo, en general, un EA puede utilizar UML (Lenguaje Unificado de Modelado) como herramienta para: 1. Modelar la arquitectura empresarial: UML puede ayudar a describir la estructura y el comportamiento de la organización, incluyendo los procesos, los sistemas y la información. 2. Definir la arquitectura de software: UML es ampliamente utilizado para modelar la arquitectura de software, incluyendo la estructura de clases, objetos y componentes. 3. Comunicar la visión arquitectónica: UML proporciona un lenguaje común para comunicar la visión arquitectónica a los stakeholders, incluyendo desarrolladores, gerentes y usuarios. Algunos de los diagramas UML más comunes utilizados en Enterprise Architecture son: 1. Diagramas de clase (Class Diagrams) 2. Diagramas de componentes (Component Diagrams) 3. Diagramas de despliegue (Deployment Diagrams) 4. Diagramas de secuencia (Sequence Diagrams) 5. Diagramas de estado (State Machine Diagrams) Sin embargo, un EA no se centra exclusivamente en UML. Otros enfoques y herramientas pueden ser igualmente importantes, como: 1. Arquitectura de Enterprise (EA) frameworks como TOGAF, Zachman, o GARTNER 2. Modelado de procesos de negocio (BPMN) 3. Análisis de requisitos de negocio 4. Diseño de experiencia del usuario (UX)  5. Arquitectura de datos y gestión de datos Un EA puede utilizar UML como herramienta para modelar y comunicar la arquitectura empresarial y de software, pero su enfoque es más amplio y abarca una variedad de disciplinas y herramientas.