Rol de un Arquitecto Software | RUP: Fase de Iniciación

Introducción

En las metodologías ágiles, como Scrum, Kanban y XP (Extreme Programming), no se define específicamente un rol de "arquitecto software" como se hace en metodologías más tradicionales como RUP (Rational Unified Process).

RUP es un marco de desarrollo de software que proporciona un enfoque disciplinado y estructurado para la creación de sistemas y aplicaciones de software.

Se organiza en fases que representan etapas claramente definidas del proceso, como Inicio, Elaboración, Construcción y Transición. Cada fase se compone de disciplinas, como la gestión de proyectos, el análisis de requisitos, el diseño de software y las pruebas, que definen las actividades y los artefactos correspondientes a cada etapa del proceso.

Esfuerzo en actividades según fase del proyecto.

A continuación se definen las distintas fases así como el rol que desempeña un Arquitecto Software en cada una de ellas.

Fase de Iniciación

En esta fase se establece la visión del proyecto, se identifican los objetivos y las necesidades del negocio, se realiza un análisis de viabilidad y se define el alcance del proyecto. También se identifican los principales riesgos y se elabora un plan preliminar para el proyecto.

Artefactos de salida

• Visión del proyecto: establece la visión, los objetivos y el alcance del proyecto desde una perspectiva estratégica.

• Plan de proyecto preliminar: proporciona una descripción detallada de cómo se organizará y ejecutará el proyecto desde una perspectiva de gestión. Este plan es una versión inicial del plan de proyecto completo y brinda una visión general de las actividades, los recursos, el roadmap a seguir y los riesgos asociados con el proyecto.

• Diagrama del modelo de dominio: representación gráfica que muestra las entidades y las relaciones clave dentro del ámbito del sistema o aplicación que se está desarrollando.

• Diagrama de casos de uso: representación gráfica que describe las interacciones entre los actores (usuarios o sistemas externos) y el sistema o aplicación que se está desarrollando. El diagrama de casos de uso muestra las diferentes funcionalidades del sistema y cómo los actores interactúan con él.

• Lista de riesgos: Estos riesgos pueden estar relacionados con diversos aspectos del proyecto, como la tecnología, los recursos humanos, los requisitos, el roadmap, etc.

• Requisitos No Funcionales:

  • Tecnologías: se incluyen tecnologías a utilizar como el lenguaje de programación (PHP, Javascript), frameworks (Symfony, React), el mecanismo de persistencia (Sql Server, Mysql), el sistema de mensajería (RabbitMq) u otras tecnologías que se hayan adoptado en la empresa.

  • Seguridad: incluye las distintas soluciones que se hayan adoptado para resolver problemas de seguridad. Por ejemplo, si una aplicación es pública o si se tiene que acceder por la VPN.

  • Rendimiento: Casos de uso que tengan que realizarse en menos de un tiempo determinado.
    

• Concurrencia:

  • X cantidad de usuarios ejecutando un caso de uso en un tiempo determinado sin afectar al rendimiento del caso de uso. Por ejemplo, el sistema tiene que permitir a 100 usuarios solicitar “Crear un pedido” de manera concurrente respondiendo a cada uno de ellos en menos de 1 segundo.

  • X cantidad de usuarios ejecutando un caso de uso que requiere de un único recurso. Por ejemplo, cuando dos usuarios solicitan “Seleccionar el router por número de serie” el sistema mostrará a uno de ellos el mensaje “El router ha sido seleccionado” mientra que al otro mostrará el mensaje “No se ha podido seleccionar el router por ya estar seleccionado”.