jueves, 15 de junio de 2023

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

En esta etapa se realiza la entrega del sistema al cliente y se lleva a cabo su despliegue. Se realizan pruebas de integración, pruebas de aceptación y se realiza la documentación necesaria. Además, se brinda soporte para la puesta en marcha del sistema y se realizan ajustes y correcciones según las necesidades del cliente.

Disciplina de Despliegue

Se enfoca en planificar y ejecutar la entrega y puesta en marcha del sistema desarrollado en su entorno de producción.

El rol de un Arquitecto Software se centra en:

  • Revisión y propuestas del Mecanismo de Despliegue para facilitar el mismo.

     

Bibliografía



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

En esta etapa se lleva a cabo la implementación del sistema, se construyen los componentes y se realiza la integración de los mismos. Se desarrollan las funcionalidades del sistema de acuerdo con los requisitos establecidos. También se realizan pruebas unitarias y se corrigen los errores identificados.

Disciplina de Implementación

El propósito es convertir el diseño del sistema en código ejecutable y en realizar las pruebas de integración para asegurar que los componentes del sistema funcionen correctamente juntos.

El rol de un Arquitecto Software se centra en:

  • Implementación de las primeras líneas para crear las estructuras físicas así como las capas lógicas de aspectos relevantes.

  • Mentorización del equipo de desarrollo.

  • Revisión del desarrollo para mantener la integridad de la arquitectura de software.

Disciplina de Pruebas

El propósito es verificar y validar el software desarrollado, asegurando que cumpla con los requisitos establecidos y funcione correctamente.

El rol de un Arquitecto Software se centra en:

  • Revisión de los casos de pruebas requisitos funcionales.

  • Revisión de los casos de pruebas requisitos no funcionales.

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

En esta etapa se realiza un análisis más detallado de los requisitos, se define y se refina la arquitectura del sistema, se identifican los componentes principales y se establecen las bases para la implementación del sistema. También se desarrolla un plan detallado del proyecto, se estiman los recursos y se elabora un plan de pruebas.

Disciplina de Requisitos

El objetivo principal de la disciplina de requisitos es comprender y documentar los objetivos y necesidades del cliente, usuarios y otras partes interesadas, para poder diseñar, desarrollar y entregar un sistema que cumpla con esos requisitos y expectativas.

El rol de un Arquitecto Software se centra en:

  • Se realizan actividades de refinamiento y clarificación para asegurarse de que los requisitos sean completos, consistentes y verificables. Se utilizan y refinan los Diagrama del Modelo de Dominio, Diagramas de Casos de Uso, Diagramas de Máquinas de Estados de Entidades, Diagramas de Flujos entre otros. La documentación de requisitos proporciona una descripción detallada de lo que el sistema debe hacer y cómo debe comportarse.

  • Evaluación de la complejidad técnica de los casos de uso, considerando factores como la integración con otros sistemas, la escalabilidad, el rendimiento y la seguridad. Basándose en esta evaluación, puede proporcionar recomendaciones sobre la prioridad de los casos de uso.

Disciplina de Análisis

El objetivo principal de esta disciplina es analizar y modelar los requisitos del sistema para obtener una comprensión clara de las necesidades de los usuarios y las capacidades requeridas del software.

Análisis de la Arquitectura del Sistema

El rol de un Arquitecto Software se centra en:

  • Análisis de las necesidades de los Requisitos No Funcionales con especial atención a tecnologías requeridas, de rendimiento y concurrencia entre otras. Esto también incluye las tecnologías como tipo y versiones del lenguaje de programación, frameworks de desarrollo, Mecanismos de Persistencia , Sistemas de mensajería, etc.

  • Analizar la estructura general de la Arquitectura del Sistema, determinando los subsistemas y componentes principales del sistema, como por ejemplo los componentes Frontend, Backend y Api, mecanismo de persistencia para el almacenamiento de información, etc.

  • Analizar las necesidades de interfaces y las interacciones entre los diferentes componentes del sistema u otros sistemas. La interacción entre los sistemas se realiza a través de peticiones REST o Sistemas de Mensajería. Evitar la interacción entre los mecanismos de persistencia como los procedimientos almacenados de un sistema que cambian el estado de otro sistema.

Análisis de la Arquitectura del Software

El rol de un Arquitecto Software se centra en:

  • Análisis de la Arquitectura de Software la cuál puede ser determinada capas lógicas y físicas (monolito, MVC, Arquitectura Hexagonal, CQRS, etc). Esto incluye, el análisis de los distintos paquetes, reutilización de código, etc.

  • Se puede realizar una prueba de concepto para validar la viabilidad técnica y la factibilidad de una idea o enfoque arquitectónico. Consiste en construir un prototipo o una versión simplificada del sistema que demuestre la funcionalidad o la solución técnica propuesta.

Disciplina de Diseño

El objetivo principal de esta disciplina es diseñar la estructura, los componentes y las interfaces del sistema de software de manera efectiva y eficiente.

Diseñar la Arquitectura del Sistema

El rol de un Arquitecto Software se centra en:

  • Diseño, organización y definición de la estructura del sistema en términos de subsistemas y componentes. Se definen las tecnologías específicas que se van a utilizar para la construcción del sistema.

  • Se definen las relaciones y las interacciones entre los componentes y se define la distribución y el despliegue físico del sistema.

  • Reutilización de otros componentes o elementos.

Diseñar la Arquitectura de Software

El rol de un Arquitecto Software se centra en:

  • Definición de las interfaces de los componentes, los detalles de su implementación y su interacción con otros componentes.

  • Definición de diagramas de clases, diagramas de paquetes, para representar el diseño de la arquitectura de software. capas físicas (repositorios, estructuras de carpetas) y lógicas.

  • Definición de paquetes de software para su reutilización.

  • Definición de guías de codificación, estándares, etc.

Diseñar el mecanismo de persistencia

El rol de un Arquitecto Software se centra en:

  • En esta actividad, se realiza el diseño de la estructura del mecanismo de persistencia que respalda el sistema.

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”.