Este artículo describe algunos de los procesos y procedimientos que se producen durante el análisis de requisitos técnicos, el que comienza con los documentos de requerimientos creados durante la fase de análisis de negocio.
Utilizando como base los requerimientos de negocio, se pueden seguir los siguientes pasos:
- Realizar un análisis de uso para ayudar a determinar la carga esperada en la implementación.
- Crear un conjunto de casos de uso que modelen la interacción típica del usuario con la implementación.
- Crear un conjunto de requisitos de sistema que se derivan de los requerimientos de negocio, de los casos de uso y análisis de uso que se hizo.
Los casos de uso son, también, la base para diseñar la arquitectura lógica en la fase de diseño. La arquitectura lógica y los componentes del sistema forman, juntos, el escenario de despliegue, que más tarde es una entrada para la fase de diseño de la implementación.
La figura 1 muestra la fase de requisitos técnicos en relación con el análisis de negocio, el diseño lógico y las fases de diseño de la implementación.
La fase de análisis de negocios contiene entradas de requisitos empresariales para la fase de requisitos técnicos. Estas entradas se aplican al análisis de uso, casos de uso y requisitos del sistema.
La fase de requisitos técnicos contiene casos de uso, análisis de uso y requerimientos del sistema. Los casos de uso proporcionan entradas a los requisitos del sistema ya la arquitectura lógica. Los requisitos empresariales de la fase de análisis empresarial también proporcionan información sobre lo que se le pedirá al sistema. El análisis de uso proporciona entradas a la arquitectura lógica, que está en la fase de diseño lógico.
Los requisitos del sistema y la arquitectura lógica forman un escenario de implementación.
Al igual que con el análisis de negocios, no existe una fórmula mágica para evaluar requisitos técnicos que genere el análisis de uso, los casos de uso y los requerimientos del sistema.
Análisis de uso
El análisis de uso implica identificar a los distintos usuarios de la implementación que se está diseñando y determinar los patrones de uso para esos usuarios.
La información recopilada proporciona una idea de las condiciones de carga esperadas y se utiliza posteriormente para determinar los requisitos de rendimiento y otros parámetros del sistema. La información de análisis de uso también es útil cuando se asignan ponderaciones a los casos de uso.
Siempre que sea posible, durante el análisis del uso, se debe entrevistar a los usuarios, investigar los datos existentes sobre los patrones de utilización, y también entrevistar a los constructores y administradores de los sistemas anteriores. En la tabla siguiente se enumeran los temas a considerar al realizar un análisis de uso.
Casos de Uso
Los casos de uso modelan la interacción típica del usuario con la implementación que se está diseñando, describiendo el flujo completo de una operación desde la perspectiva de un usuario final. Priorizar el diseño en torno a un conjunto completo de casos de uso asegura un enfoque continuo en la entrega de la funcionalidad esperada.
Cada caso de uso puede incluir estimaciones cuantitativas sobre el comportamiento del usuario, que puede utilizar posteriormente para determinar los requisitos del sistema para el rendimiento, la disponibilidad y otras cualidades del servicio. Los casos de uso son también el punto de partida para diseñar la arquitectura lógica.
A menudo se asignan pesos relativos a casos de uso, con los de más alta ponderación que representan las tareas de usuario más comunes. La ponderación de los casos ayuda a determinar los requisitos del sistema.
Los casos de uso se pueden describir en dos niveles.
- Diagramas de casos de uso: representación gráfica de las relaciones entre actores y casos de uso.
- Informes de casos de uso: descripciones de casos de uso individuales, incluyendo flujos primarios y alternativos de eventos.
Requisitos del sistema
El análisis de requisitos técnicos requiere una comprensión del dominio empresarial, los objetivos empresariales y la tecnología del sistema subyacente.
Los requisitos del sistema describen la calidad del servicio que debe proporcionar un software desplegado para cumplir con los requerimientos empresariales a los que se llega mediante el análisis del negocio.
Los siguientes conceptos muestran las cualidades del sistema que se usan a menudo para especificar los requisitos del mismo.
Cualidades del sistema que afectan la implementación
Disponibilidad
Una medida de la frecuencia con que los recursos y servicios son accesibles para los usuarios finales, a menudo expresados como el tiempo de actividad de un sistema.
La disponibilidad es una forma de especificar el tiempo de actividad de un sistema desplegado. Normalmente se mide como el porcentaje de tiempo que el sistema es accesible a los usuarios. El tiempo que el sistema no está accesible (tiempo de inactividad) puede deberse a fallos del hardware, software, la red o cualquier otro factor (como la pérdida de potencia) que hace que esté inactivo. En la mayoría de los casos, el tiempo programado para el servicio (mantenimiento y actualizaciones) no se considera tiempo de inactividad.
Normalmente, se mide la disponibilidad por el número de “nueves” que puede lograr. Por ejemplo, el 99% de disponibilidad es de dos nueves. La especificación de “nueves” adicionales afecta significativamente el diseño de implementación para la disponibilidad.
La siguiente tabla muestra el resultado de agregar más nueves de disponibilidad a un sistema que se ejecuta 24×7 durante todo el año, lo que supone un total de 8.760 horas.
Capacidad latente
La capacidad de un sistema para manejar el uso de carga de pico inusual sin recursos adicionales.
Desempeño
La medición del tiempo de respuesta y latencia con respecto a las condiciones de carga del usuario.
Escalabilidad
La posibilidad de añadir en el tiempo capacidad (y usuarios) a un sistema desplegado. La escalabilidad suele implicar la adición de recursos al sistema, pero no debe requerir cambios en la arquitectura de implementación.
Seguridad
Una compleja combinación de factores que describen la integridad de un sistema y sus usuarios. La seguridad incluye la autenticación y la autorización de los usuarios, así como el transporte seguro de la información.
Utilidad
La facilidad con que se puede administrar un sistema desplegado, incluyendo tareas tales como monitorearlo, reparar problemas que surgen y actualizar componentes de hardware y software.
Interrelación
Las cualidades del sistema que afectan al diseño del despliegue están estrechamente interrelacionadas. Los requisitos para una calidad de sistema pueden afectar los requisitos y el diseño para otras cualidades del sistema. Por ejemplo, niveles más altos de seguridad pueden afectar el rendimiento, lo que a su vez puede afectar la disponibilidad. La adición de servidores adicionales para solucionar problemas de disponibilidad puede afectar los costos de mantenimiento (facilidad de servicio).
La comprensión de cómo las cualidades del sistema están interrelacionadas y los compromisos que se deben tomar es la clave para diseñar un sistema que satisfaga con éxito tanto los requisitos del negocio como las limitaciones del mismo.
En las siguientes secciones se examinan de cerca las cualidades del sistema que afectan al diseño del despliegue, proporcionando orientación sobre los factores a considerar al formular los requisitos del sistema. También hay una sección sobre los requisitos de nivel de servicio, que son un conjunto especial de requerimientos utilizados para crear acuerdos de nivel de servicio, también llamados Service Level Agreement (SLA).
Sistemas tolerantes a fallos
Los requisitos de disponibilidad de cuatro o cinco nueves normalmente requieren un sistema que sea tolerante a fallos. Un así debe ser capaz de continuar el servicio incluso durante un fallo de hardware o software. Por lo general, la tolerancia a fallos se logra mediante redundancia en hardware (como CPUs, memoria y dispositivos de red) y software que proporciona servicios clave.
Un único punto de fallo es un componente de hardware o software que no es respaldado por componentes redundantes. La falla de este componente resulta en la pérdida de servicio para el sistema. Al diseñar un sistema tolerante a fallos, debe identificar posibles puntos de fallo individuales y eliminarlos.
Los sistemas tolerantes a fallos pueden ser costosos de implementar y mantener. Asegúrese de entender la naturaleza de los requerimientos de negocio para la disponibilidad y considere las estrategias y los costos de las soluciones de disponibilidad que cumplan con esos requisitos.
Fuente: Oracle Technical Documents
Traducido y adaptado por la División consultoría de EvaluandoERP.com
