Desarrollo de Software y Sistemas: Casos de Uso, Requisitos y Arquitectura

Diferencias entre Extend e Include en Diagramas de Casos de Uso

La principal diferencia radica en la obligatoriedad. Extend se utiliza para representar una relación opcional, mientras que Include indica una relación obligatoria.

• Extend: Indica que un caso de uso puede, opcionalmente, extender el comportamiento de otro caso de uso base. Es decir, la extensión *podría* ocurrir, pero no es esencial para el caso de uso base.
• Include: Indica que un caso de uso *siempre* incluye el comportamiento de otro caso de uso. El caso de uso base *necesita* el caso de uso incluido para completar su función.

Toma de Requisitos para un Sistema de Cajas y Atención al Cliente

Para mejorar un sistema de cajas y atención al cliente, la toma de requisitos debe seguir un enfoque jerárquico, comenzando por los niveles superiores de la organización.

Actores

• Cajeros
• Jefe de Atención al Cliente

La toma de requisitos debe iniciar con el Jefe de Atención al Cliente, descendiendo luego a los Cajeros. Esto asegura que se capturen las necesidades estratégicas y operativas.

Documento para Registrar Acuerdos de una Reunión

Los documentos clave para registrar los acuerdos de una reunión son:

• Minuta: Un resumen conciso de los temas tratados, decisiones tomadas y acciones a seguir.
• Acta de Reunión: Un registro formal y detallado de la reunión, que incluye la lista de asistentes, los temas discutidos, las decisiones tomadas y las responsabilidades asignadas.

Modelo Cascada: Cuándo Utilizarlo

El modelo de desarrollo en cascada (o tradicional) es adecuado en los siguientes escenarios:

• Proyectos pequeños y bien definidos.
• Proyectos con requisitos estables y poco propensos a cambios.
• Cuando se requiere un flujo de trabajo lineal y secuencial.
• Cuando la funcionalidad está claramente definida desde el inicio.

Casos de Uso Alternativos para la Tarjeta Bip

Un caso de uso principal para la tarjeta Bip en el Metro es "Validar Viaje". Dos casos de uso alternativos son:

• Tarjeta sin Saldo: El usuario intenta validar el viaje, pero la tarjeta no tiene saldo suficiente.
• Tarjeta Dañada: El usuario intenta validar el viaje, pero la tarjeta está dañada o es ilegible.

Elementos del Sistema de una Biblioteca

Al definir un sistema de biblioteca, se deben considerar los siguientes elementos:

• Registro Curricular (Matrícula): Para verificar si los usuarios son alumnos o no.
• Caja: Para gestionar el pago de multas y otros servicios.
• Escuelas: Para gestionar la relación con las diferentes facultades o departamentos.
• Editorial: Para gestionar las publicaciones propias de la institución (si aplica).

Aprobación del Informe de Requisitos

Para lograr la aprobación del informe de requisitos, se recomienda seguir estos pasos:

1. Distribución: Enviar el informe a todas las partes interesadas para su revisión.
2. Retroalimentación: Solicitar y recopilar observaciones y comentarios antes de la reunión formal.
3. Consolidación: Incorporar los comentarios recibidos y generar una versión actualizada del informe.
4. Reunión de Aprobación: Convocar a una reunión para discutir los cambios y obtener la aprobación formal.

Componentes de una Aplicación de Radio Taxi

Una aplicación de radio taxi se compone de interfaces y lógica de negocio.

Interfaces

• Selección de Vehículo
• Listado de Vehículos Disponibles

Lógica de Negocio

• Vehículo
• Calle
• Chofer

Importancia de los Requisitos No Funcionales

Los requisitos no funcionales son cruciales para definir la arquitectura tecnológica de un sistema porque establecen las *características* y *restricciones* del sistema, *más allá de la funcionalidad específica*. No describen *qué* hace el sistema, sino *cómo* lo hace.

Ejemplos clave y su impacto en la arquitectura:

• Disponibilidad (24/7): Implica la necesidad de una infraestructura robusta, redundancia y mecanismos de recuperación ante fallos.
• Rendimiento (Tiempo de Respuesta): Requiere optimización de código, bases de datos y una infraestructura de red adecuada.
• Escalabilidad: Demanda un diseño modular y flexible que permita agregar más capacidad (hardware o software) según sea necesario.
• Compatibilidad con Dispositivos: Define las plataformas y tecnologías que deben ser soportadas, influyendo en las decisiones de desarrollo y pruebas.