COPPEL MANUAL TÉCNICO MCC DE SISTEMAS PROGRAMACIÓN DESCRIPCIÓN DEL PROCESO DE ARQUITECTURA DE SOFTWARE

Transcripción

1 COPPEL MANUAL TÉCNICO MCC DE SISTEMAS PROGRAMACIÓN DESCRIPCIÓN DEL PROCESO DE ARQUITECTURA DE SOFTWARE Creado en May/14 Objetivo: Contar con una guía de las actividades que se deben realizar en esta fase, para que a la persona responsable de ejecutarla, le quede claro el cómo debe funcionar el sistema a diseñar, sus funciones y los entregables a generar para el proyecto. Responsables: Arquitecto de Software (AS), Líder de Proyecto (LP) y Gerente (GTE). Descripción del Diagrama de Flujo Inicio. La Arquitectura de Software inicia una vez que el Líder de Proyecto ha asignado una petición al Equipo de Proyecto. El Arquitecto de Software verificará diariamente las actividades a realizar en la herramienta de Administración de Proyectos, en caso de tener dudas sobre las tareas asignadas o no tener actividades planificadas para ese día en la herramienta antes mencionada, le notifica a su Líder de Proyecto. Nota: El responsable de ejecutar la fase de Arquitectura y Diseño participa en actividades que corresponden a otras fases dentro del proyecto, como lo son la fase de análisis, codificación, pruebas y actividades propias de la administración de proyectos. 1.- AS revisa petición. Una vez que el Líder de Proyecto ha asignado una petición a todo el Equipo de Proyecto para trabajar, el Arquitecto de Software revisa el contenido de la petición que obtiene de la herramienta Administrador de Peticiones de Sistemas (APS). 2.- AS identifica REQ iniciales y genera lista con las dudas y/o propuestas. Arquitecto de Software analiza las necesidades que el Solicitante plasmó en la petición e identifica los requerimientos iniciales, a su vez listará todas las dudas que tenga en relación a los requerimientos generados por el Solicitante, finalmente, listará las propuestas que representen una solución válida, todo lo antes mencionado será presentado por el Arquitecto de Software durante la reunión de inicio de proyecto. Nota: El Arquitecto de Software deberá llevar documentadas la lista de dudas y/o propuestas a la reunión de inicio de proyecto. También deberá llevar documentadas las necesidades iniciales, con el objetivo de que el Analista de Requerimientos las verifique y genere los requerimientos funcionales y no funcionales que sean necesarios para generar un producto que satisfaga las necesidades del Solicitante. 3.- AS asiste a la reunión de inicio. Arquitecto de Software asiste a la reunión de inicio, para lo cual deberá de iniciar la actividad por medio de la huella en la herramienta Administrador de Proyectos. 4.- AS expone las dudas o aporta propuestas al proyecto en la reunión de inicio. Durante la reunión de inicio, el Arquitecto de Software expone las dudas a los integrantes del Equipo de Proyecto con el objetivo de verificar si alguno de los integrantes del equipo puede aclararlas, en caso contrario, será responsabilidad del Analista de Requerimientos anotarlas para revisarlas con el Solicitante. A su vez el Arquitecto de Software presentará propuestas de solución para resolver las necesidades del Solicitante, mismas que serán debatidas durante la reunión para determinar su factibilidad. 5.- AS acepta minuta. Una vez que el Líder de Proyecto ha generado la minuta de la reunión de inicio de proyecto, el Arquitecto de Software revisará el contenido y firmará la minuta a través de su huella en

2 la herramienta Administrador de Proyectos. Nota: Durante la reunión de inicio, el Equipo de Proyecto debe asegurarse de identificar el hardware, software, así como identificar a las áreas que será necesario solicitar datos como: configuraciones, periféricos y otros, mismos que deberán quedar plasmados en la minuta de la reunión de inicio que genera el Líder de Proyecto, con el objetivo de que los mismos estén listos antes de generar los entregables de cada una de las fases del proceso de desarrollo. 6.- AS recibe parcial o total del contrato. Arquitecto de Software recibe parcial o total del contrato, el cual contiene n requerimientos que ya han sido aprobados por todos los integrantes del Equipo de Proyecto. 7.- AS tiene dudas sobre el contenido del contrato? Nos hacemos esta pregunta para verificar si el Arquitecto de Software tiene alguna duda sobre los requerimientos plasmados en el contrato parcial o total, en caso de no tener ninguna duda continúa en la Actividad 10 AS entrega estimación y determina complejidad, en caso contrario continúa en la siguiente actividad. 8.- AS revisa dudas con AR o EQP. Arquitecto de Software revisa las dudas sobre el contenido del contrato con el Analista de Requerimientos u otra duda con algún integrante del Equipo de Proyecto. 9.- Se resolvieron las dudas? Nos hacemos esta pregunta para verificar si se resolvieron las dudas al Arquitecto de Software, en caso de que las dudas no hayan sido aclaradas, se regresa a la Actividad 8 AS revisa dudas con AR o EQP, en caso contrario continua en la siguiente actividad AS entrega estimación y determina complejidad. Arquitecto de Software toma el parcial o total del Contrato y en base a las especificaciones de funcionalidad (requerimientos) realiza un análisis técnico y dimensiona el impacto que se tendrá en las diferentes funcionalidades del sistema y en otros sistemas, es decir, determina la complejidad, la cual servirá para realizar la estimación de cada una de las actividades que se realizarán durante la fase de Diseño y Arquitectura, dicha estimación deberá ser entregada al Líder de Proyecto, quien se encargará de registrarlas en el Cronograma del Proyecto. Es importante mencionar que en la fase de Arquitectura se va a estimar por cada uno de los requerimientos, quedando establecidas las siguientes complejidades: Notas: Requerimiento bajo = 2 horas. Requerimiento medio = 4 horas. Requerimiento alto = 8 horas. El impacto consiste en identificar los componentes de código que será necesario crear y/o modificar para cumplir con la funcionalidad plasmada en el parcial o total del Contrato. En esta actividad, el Arquitecto de Software consulta toda la documentación que haya resultado del Análisis de Requerimientos y en caso de que tenga dudas sobre lo plasmado en la documentación, las revisará con el Analista de Requerimientos asignado al proyecto y le informará a su Líder de Proyecto. En caso de que el Líder de Proyecto considere que se deban realizar ajustes a las actividades y tiempos que el Arquitecto de Software propone, se negociará entre ambos para llegar a un acuerdo que más convenga al proyecto AS genera / actualiza parcial o total de los entregables de arquitectura. El Arquitecto de Software genera / actualiza la Arquitectura de Software que consiste en plasmar en un nivel técnico la interacción de los componentes de código necesarios para cumplir con la funcionalidad del sistema, por lo tanto, el Arquitecto de Software elabora los entregables dependiendo de las necesidades del proyecto y comienza con los Entregables Iniciales que son los que deben estar listos para iniciar con la fase de codificación. Finalmente, existen Entregables Finales que se generarán conforme el

3 proyecto vaya avanzando y deben estar terminados antes de que finalice el proyecto. A continuación se mencionan los entregables, los cuales dependerán de los siguientes criterios: Sistemas o módulos nuevos y reingeniería de sistemas Modelo de Secuencia (entregable final). Modelo de Clases (entregable inicial). Modelo de Componentes (entregable final). Modelo de Despliegue (entregable final). Modelo de Datos (entregable inicial). Mantenimiento de sistemas existentes con documentación Modelo de Secuencia * (entregable final) Modelo de Clases * (entregable inicial). Modelo de Componentes * (entregable final). Mantenimiento de sistemas existentes sin documentación Diagrama Técnico de Proceso (DTP) * (entregable inicial). Modelo de Componentes * (entregable final) Documento de liberación (entregable final). Es importante mencionar que los entregables marcados con un (*) estarán sujetos a actualizaciones (sistemas con documentación) o se generarán (sistemas sin documentación) dependiendo del resultado que se obtiene de la aplicación del Check list Entregables de Arquitectura, el cual se aplica en todos los proyectos que se trabajen bajo el tratamiento de Mantenimiento. Dicho check list se encuentra en el repositorio de proceso que corresponde a la versión vigente del proceso de Arquitectura de Software. Nota: Una vez que un determinado rol ha terminado los entregables (iniciales y finales) que corresponden a su fase en una parcialidad, el mismo puede continuar con la generación de otra sin necesidad de que se hayan ejecutado todas las fases del proceso de desarrollo en una parcialidad anterior, es decir, no es necesario que el resto de los roles hayan culminado los entregables que le corresponden para esa parcialidad El EQP valida que se entreguen parciales o total de entregables? Nos hacemos esta pregunta para verificar si el parcial o total que generó el Arquitecto de Software se podrá trabajar en el resto de las fases que conforman el proceso de desarrollo, en caso de que no se valide el parcial o total se regresa a la Actividad 8.- AS revisa dudas con AR o EQP., en caso contrario continúa en la siguiente actividad AS entrega parcial o total de entregables de arquitectura. Una vez que el Equipo de Proyecto ha validado el contenido del parcial o total, el Arquitecto de Software proporciona los Entregables Iniciales necesarios al Programador y al resto de los integrantes del Equipo de Proyecto.

4 14.- PG tiene dudas? Nos hacemos esta pregunta para verificar si el Programador tiene alguna duda durante el transcurso de la generación de sus entregables basado en la documentación generada por el Arquitecto de Software, en caso de que el programador no tenga dudas continua en la Actividad 17 Se ha generado el último parcial del proyecto?, en caso contrario continúa en la siguiente actividad AS puede resolver? Nos hacemos esta pregunta para verificar si el Arquitecto de Software puede resolver las dudas planteadas por el Programador, en caso de no poder resolver las dudas se regresa a la Actividad 8.- AS revisa dudas con AR o EQP., en caso contrario continúa en la siguiente actividad AS resuelve dudas. Arquitecto de Software resuelve las dudas relacionadas al contenido del parcial o total de los Entregables Iniciales de Arquitectura al Programador Se ha generado el último parcial del proyecto? Nos hacemos esta pregunta para verificar si el Arquitecto de Software ha generado el último parcial del proyecto, es decir, la etapa de elicitación ha finalizado, ya que el Arquitecto de Software en conjunto con el Equipo de Proyecto ha aclarado todas las dudas sobre el contenido de la petición y tiene claro el objetivo, requerimientos y entregables esperados por el Solicitante. En caso de no haber generado el último parcial se regresa a la Actividad 6 AS recibe parcial o total del contrato, en caso contrario continúa en la siguiente actividad EQP termina elicitación. Arquitecto de Software coloca su huella para finalizar la etapa de Elicitación una vez que el Analista de Requerimientos ha detonado la terminación de la etapa antes mencionada por medio de la huella en la herramienta Administrador de Peticiones de Sistemas (APS) AS recibe documentación de contrato y modelos. Arquitecto de Software recibe del Analista de Requerimientos la documentación generada en dicha fase una vez que el contrato ha sido autorizado por el Solicitante AS genera / actualiza estimación y complejidad del proyecto. Arquitecto de Software basado en las especificaciones de funcionalidad (requerimientos) realiza el análisis técnico para determinar el impacto del proyecto, es decir, determina la complejidad del proyecto considerando los n parciales que se generaron para posteriormente realizar la estimación total de las actividades del proyecto que se ejecutarán durante la fase de Diseño y Arquitectura, la cual será entregada al Líder de Proyecto, quien se encargará de registrarlas en el Cronograma del Proyecto. Es importante mencionar que en la fase de Arquitectura se va a estimar por cada uno de los requerimientos, quedando establecidas las siguientes complejidades: Requerimiento bajo = 2 horas. Requerimiento medio = 4 horas. Requerimiento alto = 8 horas. Nota: Cuando no se generen parcialidades, es decir, cuando se genera el Contrato Total, esta actividad se cumple en la Actividad 10 AS entrega estimación y determina complejidad AS actualiza entregables de arquitectura. El Arquitecto de Software concluye la elaboración de los Entregables Finales de la fase de Arquitectura de Software que consiste en plasmar en un nivel técnico la interacción de los componentes de código necesarios para cumplir con la funcionalidad del sistema. A continuación se mencionan los entregables, los cuales dependerán de los siguientes criterios: Sistemas o módulos nuevos y reingeniería de sistemas Modelo de Secuencia (entregable final). Modelo de Clases (entregable inicial).

5 Modelo de Componentes (entregable final). Modelo de Despliegue (entregable final). Modelo de Datos (entregable inicial). Mantenimiento de módulos nuevos y reingeniería Modelo de Secuencia * (entregable final) Modelo de Clases * (entregable inicial). Modelo de Componentes * (entregable final). Mantenimiento de sistemas existentes sin documentación Diagrama Técnico de Proceso (DTP) * (entregable inicial). Modelo de Componentes * (entregable final) Documento de liberación (entregable final). Es importante mencionar que los entregables marcados con un (*) estarán sujetos a actualizaciones (sistemas con documentación) o se generarán (sistemas sin documentación) dependiendo del resultado que se obtiene de la aplicación del Check list Entregables de Arquitectura, el cual se aplica en todos los proyectos que se trabajen bajo el tratamiento de Mantenimiento. Dicho check list se encuentra en el repositorio de proceso que corresponde a la versión vigente del proceso de Arquitectura de Software. Notas: Definición de Mantenimiento de Producto (DMP): es un documento que contempla las especificaciones técnicas que debe contener el sistema a generar. Será utilizado en los proyectos de Mantenimiento para describir el cambio o la modificación del sistema, es importante mencionar que en dicho documento no se debe de incluir código fuente, además la información capturada en el DMP es complementada con los requerimientos y reglas de negocio definidas por el Analista de Requerimientos. El DMP electrónico permitirá realizar liberación por componente afectado con la finalidad de ir avanzando con el desarrollo Los diagramas de Arquitectura de Software se crean sobre el archivo de diagramas generado en la fase de Análisis de Requerimientos correspondiente al mismo sistema. Documento de Liberación: El arquitecto de Software genera el Documento de Liberación, mismo que será complementado en fases posteriores del proceso de desarrollo por el Programador, Tester e Implementador, por lo antes mencionado, el Arquitecto se Software llenará los apartados de: Introducción, Datos de la solicitud, Datos de la versión. Además es importante mencionar que en la fase de Arquitectura se identificarán los componentes de código que se necesitan para llevar a cabo lo especificado en la petición del Solicitante que se especificará en el apartado Descripción breve del proyecto y en el campo "componente" del apartado "Componentes de código"; también plasmará la secuencia de instalación del producto en el apartado Requerimientos de instalación y/o ejecución y llenará el apartado de "Dependencias externas". Es importante mencionar que el Arquitecto puede asignar la ruta

6 donde se encontrará almacenado el componente en el campo URL del apartado de Componentes de código a pesar de que es responsabilidad del Programador, quien se encargará de verificar que se haya asignado la ruta correcta. La plantilla del documento DMP, Modelos y Documento de Liberación se encuentran en el repositorio de proceso que corresponda a la versión vigente del proceso de Arquitectura de Software. En el apartado de Aclaraciones se hace una breve descripción de cada uno de los modelados. 22- AS genera línea base junto con LP. Una vez que el Arquitecto de Software ha finalizado todos los entregables de la fase de Diseño y Arquitectura genera la Línea Base de Arquitectura, misma que realiza por medio de la herramienta Enterprise Architect (modelados). Aclaraciones: A continuación se hace una breve descripción del contenido de cada uno de los modelos generados durante la fase de Arquitectura: Modelo de Datos: El modelo de datos se elabora siempre que en un proyecto sufra cambios la estructura de la base de datos lo cual se define con la aplicación del check list. Un modelo de base de datos puede contener lo siguiente: tablas, campos y relaciones entre tablas, funciones, procedimientos almacenados, llaves primarias y llaves foráneas. Es importante mencionar que cuando se diseñan tablas por primera vez, éstas deben de estar apegadas a las reglas de estandarización de Base de Datos. El modelo de datos se diseñará con la participación del Administrador de Base de Datos, quien deberá validar el diseño final así como tomar la responsabilidad en conjunto con el Arquitecto de Software sobre el diseño propuesto. Modelo de Clases: Es un diagrama el cual debe ser elaborado antes de iniciar la fase de Codificación y lo mínimo que debe contener son los nombres de clases a desarrollar con sus relaciones, las clases deben de estar bien documentadas con la funcionalidad para la que será creada. En el caso de que se identifique necesaria la implementación de un patrón de diseño se deberá hacer mención de éste para que sea codificado de acuerdo al estándar que define el diagrama del patrón. El Arquitecto de Software en conjunto con el Programador podrá definir los nombres de los métodos de cada una de las clases, parámetros, tipos de datos, etc. A medida que avanza la codificación. Al finalizar el proyecto el Arquitecto de Software debe dejar documentación completa de todas las clases afectadas o creadas ya sea aplicando ingeniería inversa o diseño directo sobre la herramienta utilizada para realizar el diseño (Enterprise Architect). Modelo de Secuencia: El diagrama de secuencia se realiza de manera general sin definir métodos de clases a detalle, se definen los flujos principales sin llegar a detalle de describir estructuras de control, este diagrama se puede generar durante el proceso de desarrollo del proyecto a medida como se avance la fase de Codificación, el Arquitecto de Software deberá estar en constante comunicación con el Programador para asegurarse que se esté siguiendo el diseño preestablecido. Modelo de Componentes: Es un diagrama de componentes con todas las relaciones que existen entre cada una de ellas, los componentes se refieren a componentes de sistema de archivos, ejemplo (archivos binarios, ejecutables, librerías, etc.). Modelo de Despliegue: Se realizará la identificación inicial de servidores o hardware necesario para desarrollo/pruebas, ésta información se podrá plasmar en el documento de liberación con el siguiente contenido: versiones del DBMS, IP/DNS, puertos. Durante el proceso de desarrollo del proyecto se va a elaborar el diagrama de despliegue con la información ya identificada y con nuevos requerimientos de infraestructura, protocolos, puertos y servicios detectados.

7 Los entregables que se generan al finalizar el proceso de Arquitectura de Software son: Proyecto de Desarrollo Nuevo: Modelo de Arquitectura de Software del Sistema (incluye Diagrama Técnico de Proceso). Documento de Liberación. Proyecto de Mantenimiento: Definición de Mantenimiento de Producto (DMP) Modelo de Arquitectura de Software del Sistema en caso de aplicar. Diagrama Técnico de Proceso para proyectos de Mantenimiento sin documentación en caso de aplicar. Documento de Liberación. Y con esto se da por terminado el proceso de Arquitectura de Software.