MeRinde Guía Detallada V1.0

Centro Nacional de Tecnologías de Información

METODOLOGÍA DE LA RED NACIONAL DE INTEGRACIÓN Y DESARROLLO DE SOFTWARE LIBRE (MeRinde)

Guía Detallada

Este documento describe las características principales y la estructura de la metodología

Autores: • •

Carlos David Marrero. Kiberley Kristal. Santos Rosillo.

MeRinde Guía Detallada

LICENCIA

Copyright (C) 2007 CNTI. Todos los derechos reservados. El material escrito que se distribuye estan bajo la licencia de Documentación Libre de GNU, sin restricciones adicionales. Es libre de copiar, distribuir y modificar este texto según los términos de esta licencia. El texto completo de la licencia puede consultarse en la URL http://www.gnu.org/copyleft/fdl.es.html

2

MeRinde Guía Detallada

TABLA DE CONTENIDOS Página COLABORADORES.................................................................................................... 5 INTRODUCCIÓN.........................................................................................................6 JUSTIFICACIÓN..........................................................................................................7 AUDIENCIA.................................................................................................................9 METODOLOGÍA PROPUESTA................................................................................10 Mejores Prácticas Implementadas en la Metodología.......................................... 10 Estructura del Proceso de MeRinde......................................................................19 Mantenimiento .....................................................................................................20 Fundamentos de MeRinde.................................................................................... 22 ESTRUCTURA DINÁMICA DE LA METODOLOGÍA.......................................... 24 Fases de la Metodología....................................................................................... 24 Inicio...............................................................................................................25 Elaboración.....................................................................................................26 Construcción...................................................................................................27 Transición....................................................................................................... 28 ESTRUCTURA ESTÁTICA DE LA METODOLOGÍA........................................... 31 Roles Definidos en la Metodología...................................................................... 32 Descripción de los Roles................................................................................ 34 El Modelo de Equipo para Proyectos............................................................. 38 Artefactos..............................................................................................................40 Descripción de los Artefactos de la Metodología...........................................40 Artefactos Compuestos ..................................................................................44 Disciplinas de la Metodología.............................................................................. 45 Modelado del Negocio................................................................................... 47 Implementación.............................................................................................. 52 Pruebas........................................................................................................... 54 Implantación................................................................................................... 57 Gestión de Configuración y Cambios.............................................................59 Gestión del Proyecto.......................................................................................61 Gestión del Ambiente .................................................................................... 64 Marco de Desarrollo de MeRinde........................................................................ 66 APORTES, VENTAJAS Y DESVENTAJAS DE LA METODOLOGÍA................. 70 Aportes de la Metodología................................................................................... 70 Ventajas de la Metodología.................................................................................. 73 3

MeRinde Guía Detallada Desventajas de la Metodología.............................................................................76 SÍNTESIS DE LA METODOLOGÍA MERINDE.................................................... 77 REFERENCIAS BIBLIOGRÁFICAS........................................................................ 83 APÉNDICES............................................................................................................... 84 DESCRIPCIÓN DE LOS ARTEFACTOS PROPUESTOS DE MERINDE ............ 85 DESCRIPCIÓN DE LAS ACTIVIDADES Y TAREAS .........................................142 PROPUESTAS DE MERINDE................................................................................ 142 LLENADO DE LAS PLANTILLAS........................................................................ 226 PLANTILLAS DEL HABILITADOR WEB............................................................231

4

MeRinde Guía Detallada

COLABORADORES Líderes del Proyecto y Desarrolladores Carlos David Marrero Fernando Muro Henry Rivero Jasmin Sánchez Esculpi Kiberley Kristal Santos Rosillo Odalis Pereira

Colaboradores del Proyecto Sin ninguno de ustedes hubiese sido posible llevar a cabo este trabajo: Kenyer Piadaktay Domínguez Martínez María Angélica Pérez de Ovalles

5

MeRinde Guía Detallada

INTRODUCCIÓN MeRinde es un proyecto de Software Libre (SL) que propone un estándar para el proceso de desarrollo de software que puede ser empleado y adaptado según los requerimientos de cualquier comunidad u organización para el desarrollo de sistemas y además para producir y mantener una librería de plantillas reutilizables para la ingeniería de software. Estas plantillas proveen un punto partida para los documentos utilizados en proyectos de desarrollo de software, con lo que pueden ayudar a los desarrolladores a trabajar más rápido y evitar pasar por alto aspectos importantes del proceso de desarrollo. Este proyecto pretende entre sus principales objetivos apoyar a las comunidades de desarrollo de SL en sus proyectos, suministrando las herramientas necesarias para que estos cumplan con un proceso de desarrollo y documentación de sus sistemas. Se aclara que el proceso propuesto y las plantillas no son universales y no intentan proveer guías prescriptivas en el proceso general de desarrollo de sistemas. Con el proceso de desarrollo y con las plantillas se busca a su vez estimular a la transferencia del conocimiento entre las comunidades desarrolladoras de SL con lo cual no solo se pretende que sea compartido los códigos de los sistemas sino que también se compartan la documentación como guía de referencia para mejoras por terceros al sistema o para que sirva como modelo a otras comunidades para el desarrollo de sus propios sistemas. El contexto del presente proyecto está enmarcado dentro de un diseño documental bibliográfico, debido a que una buena parte de esta investigación está sustentada en revisiones bibliográficas de diversas fuentes y por un diseño de campo, para ello se empleó las instalaciones del CNTI.

6

MeRinde Guía Detallada

JUSTIFICACIÓN El software tiene un papel muy destacado en la sociedad dado los múltiples uso que a este se le puede dar, por lo que es importante garantizar métodos claros en sus diferentes fases de producción y explotación. Diversas tendencias y metodologías de desarrollo de software han aparecido en años recientes, buscando resolver los problemas que proyectos más tradicionales, no han conseguido enfrentar. Entre ellas están los frameworks de proyectos, las metodologías ágiles y los modelos de medición de madurez. Junto con estos marcos de trabajo, ciertas estrategias específicas han permitido a los equipos de desarrollo producir software más robusto, predecible, reutilizable y de fácil mantenimiento. En Venezuela, el CNTI como ente adscrito al Ministerio del Poder Popular para las Telecomunicaciones y la Informática (MPPTI),

noto que hacia falta

involucrar para el desarrollo de sus proyectos de software equipos que hicieran uso de una metodología y documentación estandarizada, para alcanzar una trazabilidad entre documentos, seguir un mismo estándar para el proceso de desarrollo y tener varias medidas para el aseguramiento de calidad de los sistemas. Así mismo, se observo que al no existir una metodología estándar para el desarrollo de los proyectos, no existe un consenso en cuanto a los artefactos a desarrollar ni al contenido que cada uno de estos debería llevar, y por lo tanto muchos de los artefactos que son entregados por los entes contratados poseen datos redundantes o ausencia de los mismos. Por otro lado, la falta de una metodología estándar conlleva a la ausencia de mecanismos que permitan determinar las funciones que corresponde a cada personal que interviene en un proyecto, dado que no hay una definición de roles y sus actividades a cumplir, motivo por el cual un individuo realiza determinadas tareas que no le corresponden o no le deberían corresponder, lo

7

MeRinde Guía Detallada cual implica un mayor número de errores en los sistemas y un mayor tiempo a ser empleado para poner en producción un sistema. Los paquetes existentes de software para procesos de desarrollo y con plantillas de ingeniería de software son muy costosos, y están limitadas por la autoría de solo unas cuantas personas, por relaciones cliente-vendedor o por un conjunto de herramientas ofrecidas por un distribuidor en particular. Por los motivos anteriormente mencionados el CNTI como parte de la administración pública y en su rol tecnológico que le compete se planteó como uno de sus objetivos poder tener y ofrecer una metodología, con una documentación para el desarrollo de software que emplee un mismo patrón, que este basado en SL y estándares abiertos, que propicie un proceso de desarrollo y producto final de calidad.

8

MeRinde Guía Detallada

AUDIENCIA Esta Metodología para el desarrollo de software está destinada a cualquier persona implicada en el proceso de desarrollo de software que se lleva a cabo en el Centro Nacional de Tecnologías de Información (CNTI) y también a cualquier individuo, comunidad u organización interasada. Se dirige principalmente a miembros del equipo de desarrollo que se dedican a las siguientes actividades del ciclo de vida del desarro de sistemas: modelado del negocio, requerimientos, análisis y diseño, implementación, pruebas, implantación, gestión de configuración y cambios, gestión del proyecto y gestión del ambiente. Es útil para analistas y usuarios finales (que especifican la estructura y comportamiento requeridos por el sistema), para los diseñadores (que diseñan los sistemas que satisfacen esos requerimientos), para desarrolladores (que convierten esos diseños en código ejecutable), para probadores (que verifican y validan la estructura y comportamiento del sistema) y para líderes del proyecto.

9

MeRinde Guía Detallada

CAPÍTULO I METODOLOGÍA PROPUESTA

Para comenzar este capítulo se procede a detallar la metodología propuesta, sentado primero las mejores prácticas de desarrollo de software que serán implementadas y que servirán de línea base para determinar cómo deber ser abordados los proyectos durante el ciclo de vida de desarrollo al emplear la presente propuesta metodológica. Mejores Prácticas Implementadas en la Metodología El proceso de software propuesto por MeRinde se inspira en catorce (14) mejores prácticas, dirigidas a facilitar el desarrollo colaborativo de software entre equipos de trabajo de diversa magnitud e índole, con el fin de que se desarrolle productos de software con alta calidad, aprovechando al máximo los recursos disponibles de una forma eficaz y eficiente. A continuación se listan las mejores prácticas consideradas: •

Adaptar el proceso de desarrollo

•

Alto nivel de abstracción

•

Centrarse en la arquitectura

•

Código estándar

•

Colaboración entre equipo

•

Demostrar resultados iterativamente e incrementalmente

•

Dirigido por Casos de Uso

•

Diseño simple

•

Enfoque continuo en la calidad

•

Enfoque en los riesgos 10

MeRinde Guía Detallada •

Fomento del aprendizaje de experiencias

•

Interacción continua con cliente

•

Modelar el software

•

Permanecer ágil y esperar los cambios.

Seguidamente se describirá como cada una de las mejores prácticas listadas anteriormente será implementada por la metodología MeRinde. Adaptar el proceso de desarrollo: MeRinde es un marco de desarrollo ajustable que tiene como objetivo mantener la agilidad durante el proceso de desarrollo, establecer planes con representación realista, y estimaciones conforme a las condiciones del proyecto y durante todo el ciclo de vida del proyecto. MeRinde propicia a que los planificadores de los proyectos ajusten el proceso de desarrollo a sus necesidades ya que no tiene como objetivo ser prescriptiva. Los proyectos

de software

en MeRinde mientras más grandes sean

requerirán un mayor control para asegurar que se cumplan con los objetivos del mismo y que no existan desviaciones. Son muchos los factores que determinan el control que se debe tener sobre un proyecto, la cantidad de artefactos a emplear, el detalle de la documentación, la cantidad de revisiones, entro otros; pero fundamentalmente esto es proporcional al tamaño del proyecto, la distribución de los equipos de desarrollo, la cantidad de personas involucradas, la complejidad de las tecnologías con que se trabaje, complejidad de los requerimientos, etc. Por ello MeRinde es un marco de trabajo que se presenta como ajustable, y no descarta que se empleen componentes externos a los aquí presentados y a su vez tampoco descarta que sus componentes sirvan para otros marcos de trabajo. Alto nivel de abstracción: MeRinde favorece a que se tenga un alto nivel de abstracción para reducir la complejidad y mejorar la comunicación entre los 11

MeRinde Guía Detallada involucrados de los proyectos, a través de la recomendación de emplear herramientas de modelado de alto nivel como UML, el empleo de estándares abiertos,

el

establecimiento temprano de la arquitectura, reutilización de componentes, sistemas heredados y el empleo de software de código libre. Centrarse en la arquitectura: MeRinde además de empelar los Casos de Uso para guiar el proceso de desarrollo, presta especial atención al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores durante la construcción y el mantenimiento. La arquitectura de los proyectos es representada a través del modelo de las 4+1 vistas propuesto por Kruchten en 1995, con el fin de proveer una representación arquitectónica estándar para que todos los involucrados en el desarrollo la puedan comprender, discutir y razonar. Adicionalmente al acuerdo de la representación de la arquitectura, MeRinde provee un proceso para diseñar la arquitectura a través de un conjunto de actividades y define un artefacto fundamental llamado Documento de Arquitectura del Software (DAS) para describir las vistas asociadas con los proyectos. MeRinde especifica un rol responsable de la arquitectura del sistema denominado Arquitecto de Software, el cual a través del ciclo de vida del sistema va refinando la arquitectura y haciéndola más robusta. Código estándar: MeRinde propicia para las organizaciones el empleo de código estándar dentro de las actividades de implementación, a fin de favorecer la reducción de la complejidad, la reutilización de componentes y que cualquier involucrado con los conocimientos pertinentes pueda entender, revisar y opinar sobre cualquier componente implementado. Colaboración entre equipo: Esta práctica en MeRinde es fundamental y es abordada por el modelo de trabajo propuesto, por las actividades y por los roles contemplados. MeRinde es un marco de trabajo donde la comunicación y la 12

MeRinde Guía Detallada colaboración entre los miembros del equipo de trabajo son favorecidas a fin de crear un ambiente de trabajo altamente productivo. Demostrar resultados iterativamente e incrementalmente: En MeRinde las fases están divididas en iteraciones, cuyo resultado es una versión ejecutable (hito secundario), el Objetivo de la metodología con cada iteración será mitigar los riesgos de mayor a menor, donde el concepto de riesgo se refiere a ciertos casos de uso que son más críticos a la hora de hacer el proyecto. La figura 1 señala como son representadas las iteraciones dentro de la metodología.

1

Figura 1. Representación Gráfica de una Iteración en Me Rinde. La cantidad de iteraciones a realizar en un proyecto va a ser directamente proporcional a la magnitud del proyecto y el tipo de proyecto. Cada iteración con MeRinde debe ser contralada y se debe abordar una parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. Cada iteración se analiza cuando termina. Se puede determinar si han aparecido nuevos requerimientos o han cambiado los existentes, afectando a las iteraciones siguientes.

13

MeRinde Guía Detallada Las actividades en MeRinde durante la planificación de los detalles de cada una de las iteraciones permiten que el equipo examine cómo afectarán los riesgos que aún quedan al trabajo en curso. Toda la retroalimentación de una iteración hecha permite reajustar los objetivos para las siguientes iteraciones. Esta dinámica continúa hasta que se haya finalizado por completo con la versión actual del producto. MeRinde divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en los distintas actividades. Las iteraciones deben estar dirigidas por el riesgo. Las primeras iteraciones que se deben abordar serán aquellas que impliquen mayores riesgos, ya que seguramente tendrán una fuerte influencia en la arquitectura del sistema o subsistema a construir y ayudarán a detectar en una fase temprana los problemas que retroalimentarán la siguiente Iteración, donde serán resueltos. Las primeras iteraciones en un proyecto bajo MeRinde se deben enfocar hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una base para la arquitectura. Como soporte a las organizaciones de desarrollo MeRinde provee un proceso para planificar las iteraciones de los proyectos a través de un conjunto de actividades y define un artefacto fundamental llamado Plan de Iteración y como soporte ofrece varios artefactos adicionales para la gestión de los riesgos. Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña espiral para cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementación de la nueva versión del producto. En cada fase participan todas las disciplinas, pero que dependiendo de la fase el esfuerzo dedicado a una disciplina varía.

14

MeRinde Guía Detallada Toda iteración para un proyecto debe ser corta y contar con una duración fija (2 a 6 semanas). Para una iteración se elige un conjunto reducido de requerimientos, se diseña, implementa y prueba. El resultado de cada iteración es un sistema que puede ser probado, integrado y ejecutado. La salida es un subconjunto con calidad de producción final. Si existiesen inconvenientes para terminar una iteración planificada en lugar de retrasar el final de ésta se recomienda eliminar algunos de los requerimientos (se dejan para la siguiente iteración). Dirigido por Casos de Uso: Para MeRinde los casos de uso son la herramienta estándar empleada para especificar los requerimientos funcionales del sistema, son los que guían el diseño, implementación y pruebas de todo el sistema, y adicionalmente son los elementos que permiten la trazabilidad. Diseño simple: MeRinde apoya que los equipos de desarrollo eliminen las complejidades innecesarias y código extra, que el énfasis se deposite en diseñar la solución más simple susceptible de implementarse en el momento. Es sumamente importante que el equipo cumpla con las metas planteadas para cada una de las iteraciones, para ello se debe manejar metas alcanzables y evitar complejidades que no sean necesarias, posteriormente alcanzado el nivel funcional planteado si se dispone de los recursos se podrá aplicar más funcionalidad si así se requiere. Enfoque continuo en la calidad: MeRinde contiene mecanismos para que la calidad de todos los artefactos se evalúe en varios puntos durante todo el proceso de desarrollo, especialmente al final de cada iteración. A lo largo de todo el proceso de desarrollo de MeRinde se pueden encontrar actividades enfocadas a probar, evaluar y revisar, las cuales juegan un papel fundamental para asegurar calidad no solo al final de los proyectos sino que por el contrario durante todo su ciclo de vida. Existen una gama de artefactos destinados al enfoque continuo de calidad en MeRinde que soportan las actividades planteadas por los flujos de trabajos, entre dichos artefactos tenemos: Plan de Pruebas, Registro de Pruebas, Resumen del Ciclo de Pruebas, Resultados de Pruebas, Registro de Revisión, Registro de Evaluación, 15

MeRinde Guía Detallada Criterios de Aceptación, entre otros más que fortalecen la calidad constante durante el desarrollo. Adicionalmente a esto MeRinde contempla dos (2) roles fundamentales para asegurar calidad y menor perdida de recursos como son el Mentor y el Analista de Calidad, con los cuales también se asegura que no solo se cumplan con las actividades básicas de calidad sino que las actividades se sigan de la mejor manera y que se apliquen con la suficiente profundidad requerida. Otro papel muy importante en cuanto a calidad en MeRinde lo juegan las continuas actividades provistas de retroalimentación a las que son expuestos los sistemas, las cuales permiten evaluar el proceso y hacer los ajustes que sean necesarios, ampliar la experiencia del equipo de trabajo y permiten mejorar los recursos para el proyecto actual como para los futuros. Enfoque en los riesgos: La gestión de los riesgos es contemplada MeRinde desde el inicio del proyecto hasta el final del mismo a través de diferentes artefactos, fundamentalmente se manejan dos artefactos pilotos el Plan de Gestión de Riesgos y el Registro de Riesgos, donde se describen los posibles riesgos de recursos, técnicos, o del negocio implicados en el proyecto, y formula un plan para abordar los mismos con medidas de mitigación y correctivas para afrontar cada uno de ellos. El enfoque en los riesgos en MeRinde sirve de punto principal para la programar las actividades que deben ejecutarse durante las iteraciones. Fomento del aprendizaje de experiencias: El fomento del aprendizaje de las experiencias obtenidas en cada uno de los proyectos realizados es un papel fundamental que la metodología MeRinde propicia como parte de obtener más eficacia y eficiencia en los futuros desarrollos. Dicha práctica es fomentada por MeRinde a través de las continuas retroalimentaciones que se ven en las diversas actividades con los involucrados; el establecimiento de un ambiente de desarrollo donde tanto el equipo como cada individuo tiene la oportunidad de aprender y mejorar sus conocimientos a través del compartimiento de conocimiento y de lecciones aprendidas; la reutilización de 16

MeRinde Guía Detallada componentes y con actividades que promueven

la continua mejora de los

componentes empleados para los proyectos para su actual y futuro empleo en los proyectos. Interacción continua con cliente: El cliente esta inmiscuido dentro de los involucrados en MeRinde, rol fundamental en la metodología para llevar a cabo muchas de las actividades fundamentales del proceso de desarrollo de software a lo largo de todo el ciclo de vida propuesto, con lo cual se busca de que el cliente participe continuamente para satisfacer sus requerimientos a fin de evitar la pérdida de recursos y malentendidos durante el desarrollo. Modelar el software: El tipo de artefacto más fundamental utilizado en la Metodología MeRinde es el modelo. Cada rol necesita una perspectiva diferente del sistema. El diseño de MeRinde permite identificar todos los roles y cada una de las perspectivas que posiblemente podrían necesitar. Las perspectivas recogidas de todos los roles se estructuran en unidades más grandes, es decir, modelos, de modo que un rol pueda tomar una perspectiva concreta del conjunto de modelos. La elección de los modelos para un sistema es una de las decisiones más importantes del equipo de desarrollo. En la figura 2 se pueden observar los modelos principales propuestos de la Metodología MeRinde.

Diversos Modelos Propuestos en MeRinde

17

MeRinde Guía Detallada

2

Figura 2. Diversos Modelos Propuestos en MeRinde. La Metodología MeRinde contempla un conjunto de modelos propuestos relacionados que facilitan el entendimiento del sistema para todos los involucrados, incluyendo a los clientes, usuarios y líderes de proyecto. Fueron elegidos para satisfacer las necesidades de información de esos roles. La Metodología del CNTI MeRinde emplea UML como único lenguaje de modelamiento para el desarrollo de todos los modelos dada las ventajas de este lenguaje y la trazabilidad que permite. Permanecer ágil y esperar los cambios: El cambio es un factor de riesgo crítico en los proyectos de software, ante los cuales MeRinde crea las condiciones necesarias a través de sus actividades para gestionarlos con un enfoque ágil lo más tempranamente posible con su proceso iterativo e incremental, con la participación continua del cliente y con las actividades de retroalimentación.

Los artefactos

software cambian no sólo debido a acciones de mantenimiento posteriores a la entrega del producto, sino que durante el proceso de desarrollo.

18

MeRinde Guía Detallada

MeRinde asume que las cosas están constantemente cambiando y que ningún proyecto está aislado del impacto de estos cambios. Es importante para abordar más eficientemente cualquier cambio que se presente, que el equipo de proyecto se mantenga ágil para gestionar los cambios y que todos los involucrados participen de manera activa para obtener diferentes perspectivas para abordar estos. Con esto concluye la sección dedica a las mejores prácticas encontradas en la metodología propuesta, lo cual permite continuar con la definición de estructura que conforma la metodología, para adentrar un poco más en los detalles de esta. Estructura del Proceso de MeRinde La metodología MeRinde propone una estructura como la de UP, la cual tiene dos dimensiones como lo muestra la Figura 3: • Eje horizontal: Representa el tiempo y es considerado el eje de los aspectos dinámicos del proceso. Indica las características del ciclo de vida del proceso expresado en términos de fases, iteraciones e hitos. • Eje vertical: Representa los aspectos estáticos del proceso. Describe el proceso en términos de componentes de proceso, disciplinas, actividades, artefactos y roles.

19

MeRinde Guía Detallada Esfuerzo en Actividades según la Fase del Proyecto

3

Figura 3. Esfuerzo en Actividades según la Fase del Proyecto en Merinde. En los dos capítulos posteriores se procederá a describir tanto el eje de los aspectos dinámicos de MeRinde como el eje de los aspectos estáticos. A continuación se presenta los fundamentos sobre los cuales MeRinde se inspira. Mantenimiento A continuación se describirá como se lleva a cabo el mantenimiento de software desarrollado con MeRinde en sus cuatro categorías adaptativo, correctivo, perfectivo y preventivo. MeRinde posee en sus dos estructuras la estática y la dinámica, y en las mejores prácticas sorbe las cuales esta se fundamenta, las herramientas necesarias 20

MeRinde Guía Detallada para poder ejecutar cualquiera de los cuatro tipos de mantenimientos mencionados anteriormente. Un proyecto llevado a cabo con

MeRinde por su enfoque iterativo e

incremental continuamente estará refinando, corrigiendo o mejorando los artefactos del sistema, lo cual se observa a través del conjunto de actividades descritas por la metodología. Un mantenimiento no es más que un nuevo recorrido por todas las fases propuesta en MeRinde, donde las actividades y el esfuerzo de desarrollo serán directamente proporcionales a lo especificado en los requerimientos

para el

mantenimiento a ser llevado a cabo. A diferencia de un nuevo proyecto, cuando se trabaja el mantenimiento de un sistema ya desarrollo con MeRinde se parte de que la documentación del sistema ya existe, motivo por el cual lo que se hace es actualizar dicha documentación u artefactos para ponerlos acorde a los nuevos cambios solicitados. Al igual que el sistema con los cambios pasa a una nueva versión igual ocurrirá con la documentación del sistema. Las actividades, tareas, roles y artefactos a considerar para el mantenimiento son también proporcionales a este. Lo que se quiere enfatizar es que para cualquier tipo de mantenimiento MeRinde con su estructura contiene los mecanismos necesarios para hacer el mantenimiento. Cabe destacar que MeRinde es tanto adaptable como extensible, motivo por el cual se puede ajustar MeRinde conforme a las particularidades del proyecto.

21

MeRinde Guía Detallada Fundamentos de MeRinde MeRinde establece una estructura que cubre todo el ciclo de vida de desarrollo de software, por ello incluye fases, roles, actividades, artefactos, disciplinas, flujos de trabajo, mitigación de riesgos, control de calidad, gestión del proyecto y control de configuración. En general, esta metodología está fuertemente fundamentada en los requerimientos del CNTI y en varias metodologías como UP, OpenUP, RUP, entre otras que a continuación serán señaladas. Cabe destacar que los elementos de esta metodología fueron considerados mediante un análisis de varias metodologías en la que se compararon las mismas con respecto a sus elementos, esto permitió la escogencia de los elementos para esta metodología que han tenido éxito en el proceso de elaboración de software, así como también elementos que se ajustan a las necesidades del CNTI y al contexto de desarrollo de SL en Venezuela. Especificando los elementos que fueron estudiados, analizados y comparados de cada metodología se puede decir que las mejores prácticas para el desarrollo de software congregadas en MeRinde están inspiradas en UP, RUP, XP, MSF y OpenUP. MeRinde propone una estructura como UP basada en aspectos dinámicos y estáticos. Las fases e hitos que corresponde los aspectos dinámicos considerados son las de UP y las disciplinas que corresponde a los aspectos estáticos de la metodología se fundamentan en las de UP, OpenUP y RUP. Los flujos de trabajos que envuelve cada disciplina están inspirados en RUP, así como también en los procesos de desarrollo del CNTI y en la realidad y el deber ser del desarrollo de software. En cuanto a los roles, tareas y artefactos contenidos en una actividad se puede decir que la metodología está fuertemente inspirada en los roles de MSF, las actividades en RUP, OpenUP, UP y las observadas del ambiente de desarrollo en el CNTI, y los artefactos están basados en los de Readyset, UP y

22

MeRinde Guía Detallada artefactos existentes en la organización. También se ven reflejadas las ideas y recomendaciones de los autores en muchos aspectos que envuelve MeRinde. Estas metodologías en las que se basa MeRinde son algunas de las más usadas, además de que permiten la adaptación, es decir son un marco de trabajo que permiten escoger elementos según las características de cada proyecto. Por la cual estas sirvieron de insumo para armar la metodología del CNTI para el desarrollo de software con un enfoque de calidad que satisfaga las necesidades de dicha organización. Una vez ya culminados los aspectos generales de la metodología propuesta, se procede a describir la estructura dinámica de MeRinde en detalle en el próximo capítulo como había sido indicado anteriormente.

23

MeRinde Guía Detallada

CAPÍTULO II ESTRUCTURA DINÁMICA DE LA METODOLOGÍA

En este apartado se reflejan los aspectos dinámicos del proceso de desarrollo en términos de fases, iteraciones e hitos. MeRinde se repite a lo largo de una serie de ciclos que constituyen la vida de un producto. Cada ciclo concluye con una generación del producto y consta de cuatro fases. Cada fase se subdivide a la vez en iteraciones, el número de iteraciones en cada fase es variable. Cada fase se concluye con un hito bien definido, un punto en el tiempo en el cual se deben tomar ciertas decisiones críticas y alcanzar las metas clave antes de pasar a la siguiente fase, ese hito principal de cada fase se compone de hitos menores que podrían ser los criterios aplicables a cada iteración. Los hitos son puntos de control en los cuales los involucrados en el proyecto revisan el progreso del proyecto. Fases de la Metodología El ciclo de vida de un proyecto de software desarrollado por el CNTI se descompone en el tiempo en cuatro fases secuenciales (ver figura 4) que son: Inicio, Elaboración, Construcción y Transición. Al final de cada fase el equipo gestor del proyecto realiza una evaluación para determinar si los objetivos se cumplieron y así pasar a la fase siguiente.

24

MeRinde Guía Detallada Fases e Hitos encontrados en MeRinde

4

Figura 4. Fases e Hitos encontrados en MeRinde. A continuación se muestran el objetivo general, los objetivos específicos y las iteraciones recomendadas para cada una de las fases antes mencionadas. Inicio Su propósito general es establecer los objetivos para el ciclo de vida del producto (ver figura 5). Durante esta fase se define el modelo del negocio y el alcance del proyecto. Se identifican todos los actores y casos de uso. Se desarrolla, un plan de negocio para determinar qué recursos deben ser asignados al proyecto. Los objetivos específicos de esta fase son: • Establecer el ámbito del proyecto y sus límites. • Encontrar los casos de uso críticos del sistema, los escenarios básicos que definen la funcionalidad. • Mostrar al menos una arquitectura candidata para los escenarios principales. • Estimar el costo en recursos y tiempo de todo el proyecto. • Estimar los riesgos, las fuentes de incertidumbre. El hito en esta fase finaliza con el establecimiento del ámbito del producto, e identificación de los principales riesgos y la viabilidad del proyecto.

25

MeRinde Guía Detallada Fase de Inicio e Hito en MeRinde

5

Figura 5. Fase de Inicio e Hito en MeRinde. Se recomienda utilizar dos iteraciones en esta fase. Sin embargo, algunos de los proyectos podrían requerir más o menos iteraciones para alcanzar su objetivo. Elaboración Su objetivo general es plantear la arquitectura para el ciclo de vida del producto (ver figura 6). Se construye un modelo de la arquitectura, que se desarrolla en iteraciones sucesivas hasta obtener el producto final, este prototipo debe contener los casos de uso críticos que fueron identificados en la fase de inicio. En esta fase se realiza la captura de la mayor parte de los requerimientos funcionales, manejando los riesgos que interfieran con los objetivos del sistema, acumulando la información necesaria para el plan de construcción y obteniendo suficiente información para hacer realizable el caso del negocio. Los objetivos específicos de esta fase son: • Definir, validar y establecer la arquitectura. • Completar la visión. • Crear un plan fiable para la fase de construcción. Este plan puede evolucionar en sucesivas iteraciones. Debe incluir los costos si procede. • Demostrar que la arquitectura propuesta soportará la visión con un costo razonable y en un tiempo razonable.

26

MeRinde Guía Detallada El hito en la fase de elaboración finaliza con la obtención de una línea base de la arquitectura del sistema, la captura de la mayoría de los requerimientos y la reducción de los riesgos importantes así como permitir la escalabilidad del equipo del proyecto durante la fase de construcción. Fase de Elaboración e Hito en Merinde

6

Figura 6. Fase de Elaboración e Hito en Merinde. Se recomienda utilizar dos iteraciones en la fase de elaboración. Aunque algunos de los proyectos en esta fase podrían requerir más iteraciones para alcanzar su objetivo. Construcción El objetivo general de esta fase es alcanzar la capacidad operacional del producto (ver figura 7) de forma incremental a través de las sucesivas iteraciones. En esta fase todas las características, componentes, y requerimientos deben ser integrados, implementados, y probados en su totalidad, obteniendo una versión aceptable del producto comúnmente llamada versión beta. Se hace énfasis en controlar las operaciones realizadas, administrando los recursos eficientemente, de tal forma que se optimicen los costos, los calendarios y la calidad.

27

MeRinde Guía Detallada Los objetivos específicos de esta fase son: • Minimizar los costos de desarrollo mediante la optimización de recursos y evitando el tener que rehacer un trabajo o incluso desecharlo. • Conseguir una calidad adecuada tan rápido como sea práctico. • Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba) tan rápido como sea práctico. El hito en esta fase culmina con el desarrollo del sistema con calidad de producción y la preparación para la entrega al equipo de transición. Toda la funcionalidad debe haber sido implementada y las pruebas para el estado beta de la aplicación completadas. Si el proyecto no cumple con estos criterios de cierre, entonces la transición deberá posponerse una iteración. Fase de Construcción e Hito en MeRinde

7

Figura 7. Fase de Construcción e Hito en MeRinde. Para esta fase se recomienda realizar tres iteraciones. Tomando en cuenta las dimensiones de algunos proyectos el número de iteraciones puede variar. Transición Tiene como objetivo general entregar el producto funcional (ver figura 8) en manos de los usuarios finales una vez realizadas las pruebas de aceptación por un grupo especial de usuarios, para lo que se requerirá desarrollar nuevas versiones actualizadas del producto, entrenar a los usuarios en el manejo del sistema, completar

28

MeRinde Guía Detallada la documentación, y en general tareas relacionadas con la configuración, instalación y usabilidad del producto. Los objetivos específicos de esta fase son: • Garantizar que el usuario aprenda a operar y mantener el sistema. • Conseguir un producto final que cumpla los requerimientos esperados. El hito en la fase de transición corresponde a haber decidido si los objetivos se cumplieron y el comienzo de otro ciclo de desarrollo. El cliente debe haber revisado y aceptado los artefactos que le han sido entregado. Fase de Transición e Hito en MeRinde

8

Figura 8. Fase de Transición e Hito en MeRinde. Las iteraciones de esta fase irán dirigidas normalmente a conseguir una nueva versión. La complejidad de esta fase depende totalmente de la naturaleza del proyecto, de su alcance y de la organización en la que deba implantarse. En esta fase se recomienda utilizar dos iteraciones para los proyectos. En cada fase se persiguen objetivos, se finaliza con un hito y se puede realizar las iteraciones recomendadas o las que se consideren necesarias dependiendo de la magnitud y complejidad del proyecto. Como se pudo observar la estructura dinámica de la MeRinde tiene cuatro fases y cuatro hitos fundamentales, y además en cada fase se pueden realizar las iteraciones que convengan según las características del proyecto. Como criterio de cierre de una fase y comienzo de la otra se debe haber finalizado la fase con un hito. 29

MeRinde Guía Detallada

En el siguiente capítulo se explica la parte estática del proceso de desarrollo de software MeRinde.

30

MeRinde Guía Detallada

CAPÍTULO III ESTRUCTURA ESTÁTICA DE LA METODOLOGÍA

Un proceso de desarrollo de software define quién hace qué, cómo y cuándo. El proceso de MeRinde define cuatro elementos: los roles, que responden a la pregunta ¿Quién?, las actividades que responden a la pregunta ¿Cómo?, los artefactos, que responden a la pregunta ¿Qué? y los flujos de trabajo de las disciplinas que responde a la pregunta ¿Cuándo?, así como se muestra en la figura 9. Dimensión Estática de MeRinde

9

Figura 9. Dimensión Estática de MeRinde. Elaborado por los Autores, con imagenes de Kopete Vista Icono Theme por Joachim Farouz, 2006. 31

MeRinde Guía Detallada A continuación se describen cada uno de los elementos antes mencionados. Roles Definidos en la Metodología Una de las razones principales de la adopción de esta metodología para el desarrollo de software consiste en la definición de las tareas que serán llevadas a cabo por los individuos que participan en un proyecto. En MeRinde un rol (ver figura 10) define las responsabilidades de un individuo, o de un grupo de individuos trabajando juntos como un equipo. Este se encarga de la realización de tareas, las cuales generan artefactos. Representación Gráfica del Ícono que Específica un Rol en MeRinde

10

Figura 10. Representación Gráfica del Ícono que Específica un Rol en MeRinde. Tomado de Kopete Vista Icono Theme por Joachim Farouz, 2006. Existen artefactos que necesitan de más de un solo rol para poder ser elaborados (ver figura 11). Representación Gráfica del Ícono que Específica los Involucrados en MeRinde

11

Figura 11. Representación Gráfica del Ícono que Específica los Involucrados en MeRinde. Tomado de Kopete Vista Icono Theme por Joachim Farouz, 2006. La cantidad de roles a utilizar para el desarrollo de un proyecto de software a realizar con esta metodología depende de la magnitud del proyecto. Mientras más grande y complejo sea el proyecto requerirá de una mayor cantidad de participantes para su elaboración y más roles especializados. Otro factor importante a considerar para elegir los roles a participar en el proyecto es el tiempo asignado al desarrollo del proyecto. 32

MeRinde Guía Detallada Esta metodología más que proponer una serie de roles estáticos para un proyecto establece que se pueden utilizar los roles que se consideren necesario para realizar el proyecto según las características y el tiempo requerido por este. Los roles de esta metodología serán agrupados por participación en actividades relacionadas. Todos los roles dentro de un grupo trabajan con técnicas similares y tienen habilidades en común, pero cada uno de estos poseen métodos específicos para la ingeniería del software en su área en particular. La metodología del CNTI propone ocho (8) roles básicos que deben tomarse en cuenta para la elaboración de software como son: a. Analista de Calidad. b. Analista de Producto. c. Arquitecto de Software. d. Desarrollador. e. Involucrado. f. Líder del Proyecto. g. Mentor. h. Probador. Es importante destacar que todos los proyectos pequeños o grandes que utilicen esta metodología en su proceso de desarrollo, deben considerar estos ocho (8) roles entre los roles definidos para el proyecto. Esta metodología señala una serie de roles recomendados pero cabe destacar que un rol puede ser desempeñado por varias personas y una persona puede representar varios roles, es por ello que esta metodología brinda la oportunidad de incorporar un número indefinido de personas a los proyectos de desarrollo. El trabajo en equipo entre todos los involucrados es un principio fundamental para alcanzar el éxito en cualquier proyecto. MeRinde reconoce esto y asigna roles y 33

MeRinde Guía Detallada responsabilidades a cada persona involucrada en un proyecto, tanto del lado del cliente como del de los desarrolladores, y permite que estos trabajen continuamente en equipo. A continuación se describirán los grupos de roles definidos en esta metodología, así como también se señala algunos roles específicos que se pueden considerar dentro de estos grupos y el modelo de equipo de proyecto propuesto. Descripción de los Roles Analista de calidad. Se encarga de revisar todos los documentos que reflejan el avance del proyecto (diagrama Gantt, reporte de estado, actas de reunión, reporte de pendientes, y otras afines al control y seguimiento del proyecto), y de verificar que los objetivos del marco de desarrollo se cumplan. En estas actividades también participan los miembros del proyecto que están involucrados en su elaboración. Este rol se puede descomponer en los siguientes subroles: • Comité de dirección. • Comité de seguimiento. Analista de producto. Se encarga de dirigir el proceso de captura de requerimientos, definir los actores y casos de uso y estructurar el modelo de casos de uso, estableciendo la forma en que funcionará el sistema y cuáles son las restricciones del mismo. Este rol se puede descomponer en el siguiente subrol: • Especificador de requerimientos.

34

MeRinde Guía Detallada

Arquitecto de software. Se encarga de la definición de la arquitectura que guiará el desarrollo, y de la continua refinación de la misma en cada iteración; debe construir cualquier prototipo necesario para probar aspectos riesgosos desde el punto de vista técnico del proyecto; definirá los lineamientos generales del diseño y la implementación. Este rol se puede descomponer en los siguientes subroles: • Diseñador. • Diseñador de base de datos. • Diseñador de interfaz de usuario. • Diseñador de paquetes. Desarrollador. Esta persona tiene a su cargo la codificación de los componentes en código fuente en algún lenguaje de alto nivel a desarrollar en la iteración; debe elaborar y ejecutar las pruebas unitarias realizadas sobre el código desarrollado; es responsable de las clases que ha desarrollado debiendo documentarlas, actualizarlas ante cambios y mantenerlas bajo el control de configuración de las mismas mediante la herramienta utilizada. Este rol se puede descomponer en los siguientes subroles: • Implementador. • Integrador.

35

MeRinde Guía Detallada Involucrados. Cualquier persona que se vea afectada por el resultado del proyecto es considerada como un involucrado. Comprende un grupo de personas interesadas en que sus necesidades sean satisfechas por el proyecto. Este rol se puede descomponer en los siguientes subroles: • Cliente. • Cualquier rol. • Desarrollador de cursos. • Directores de usuarios. • Diseñador gráfico. • Documentador técnico. • Especialista en herramientas. • Experto del Negocio. • Usuarios. Líder del proyecto. Este rol se encarga de establecer las condiciones de trabajo. Por tal motivo tiene la función de dirigir y asignar recursos, coordina las interacciones con los clientes y usuarios finales, planifica las iteraciones, planifica y asigna el trabajo, define la organización del proyecto, establece las prácticas que aseguran la integridad y calidad de los artefactos del proyecto, entre otras responsabilidades. Este rol se puede descomponer en los siguientes subroles: • Ingeniero de procesos. • Jefe de configuración. • Jefe de control de cambios. • Jefe de implantación. 36

MeRinde Guía Detallada • Jefe de pruebas. • Revisor de gestión del proyecto. Mentor. El Mentor es aquella persona que está íntimamente ligada con el proceso de desarrollo de software, que conoce todas las prácticas involucradas y entiende el porqué de la misma. Acompaña y apoya a los equipos de trabajo mediante revisiones de los artefactos y haciendo recomendaciones de cómo mejorar los mismos durante todo el ciclo de vida del sistema. Este rol está en capacidad de aclarar cualquier duda que puede surgir del proceso, así como también contribuye a que la calidad se mantenga durante el desarrollo del sistema. Este rol se puede descomponer en los siguientes subroles: • Revisor técnico. • Revisor. Probador. La función del probador es realizar las pruebas identificadas y definidas previamente, utilizando las instrucciones, métodos y herramientas necesarias para este rol. Debido a la realización de las pruebas debe obtener los resultados de las mismas. Este rol se puede descomponer en los siguientes subroles: • Analista de pruebas. • Diseñador de pruebas. • Especialista en Pruebas.

37

MeRinde Guía Detallada Cabe destacar que la metodología MeRinde tiene 8 roles fundamentales y cada rol tiene asociado su función. Para proyectos que por su magnitud requieran más roles que los ocho recomendados, se debe tomar en cuenta que los roles se clasifican por grupos como se mencionó anteriormente, debido a que para muchos proyectos pueden requerir personal específico para determinadas funciones. Seguidamente se describen el modelo de equipo propuesto para la metodología con base en los roles descritos anteriormente. El Modelo de Equipo para Proyectos El desarrollo de SL vinculado a organizaciones puede estar conformado por equipos de personas que trabajan en conjunto en áreas geográficas que pueden ser distantes, es decir distribuidos o por el contrario que pueden coincidir en un punto; adicionalmente a esto se tiene que el desarrollo de un proyecto puede estar a cargo de personal tanto interno como externo a una organización, en donde a su vez el personal externo a una organización puede ser de diversa índole jurídica como cooperativas, fundaciones, entes gubernamentales, compañías, personas naturales, entre otras. Todo lo anteriormente señalado impacta la configuración de un equipo ideal, para la cual es importante considerar todos los roles propuestos por MeRinde y que las responsabilidades individuales sean asignadas apropiadamente para alcanzar el éxito. MeRinde para solucionar las restricciones anteriormente expuestas propone como modelo para equipos de trabajo una estructura que puede ser observada en la figura 12, donde un individuo puede asumir múltiples roles o donde por el contrario muchos individuos pueden asumir un rol. En la figura 12 los rectángulos contienen los diversos roles contemplados por la metodología, las líneas que conectan el diagrama representan líneas de comunicación, las elipses representan los equipos y los fuertes enlaces comunicacionales que existen entre estos, y la elipse central es núcleo del modelo donde se ve el equipo como un todo en donde existe

una

constante comunicación, coordinación y cooperación. 38

MeRinde Guía Detallada Representación Gráfica del Modelo de Equipo de Proyecto

12

Figura 12. Representación Gráfica del Modelo de Equipo de Proyecto. El modelo de equipo para proyectos está conformado por: • Un equipo de gestión de proyecto el cual es interno a la organización que conlleva el proyecto, cuya misión es mantener y establecer los lineamientos del proyecto y mantener la calidad durante todo el ciclo de vida del proyecto. • Uno o más equipos de desarrollo que conllevan el análisis, diseño e implementación del proyecto. Estos por ejemplo pueden representar desde una organización como una cooperativa hasta individuos que participan en el proyecto, los cuales a su vez se pueden ser interno, externo ó ambas inclusive a la organización. El caso en que una organización cuenta con personal interno y externo a la vez puede ser el más difícil de comprender, para el caso de MeRinde ambos son equipos distintos y con tareas especificas pero que entran en la elipse central 39

MeRinde Guía Detallada donde hay una alta comunicación, coordinación y cooperación para desarrollar el proyecto en conjunto. • Uno o más probadores ajenos a los equipos de gestión y de desarrollo. • Uno o más involucrados en el proyecto que colaboren. • Un equipo de proyecto, conformado por todos los elementos anteriormente listados, el cual está integrado por una cantidad de individuos que pueden variar durante las diversas etapas del desarrollo. El modelo en general no pretende ser una estructura jerárquica, sino por el contrario representa un modelo de trabajo flexible basado en la comunicación, cooperación y la coordinación para aplicar las prácticas y flujos de trabajos especificados en MeRinde. El Modelo se ajusta a desarrollos tanto internos como externos a una organización y a las restricciones geográficas de los equipos de trabajo y a los cambios que puedan ocurrir por la salida o entrada de individuos a un proyecto. A continuación se describen los artefactos que son otro elemento considerado como aspecto estático en esta metodología. Artefactos Descripción de los Artefactos de la Metodología MeRinde propone setenta y seis (76) artefactos que pueden ser creados durante el proceso de desarrollo de software. Estos artefactos van desde el propio código fuente hasta la documentación aportada por el cliente y la entregada por el equipo de desarrollo al culminar cada hito dentro del proyecto. Partiendo de estos artefactos se pueden crear sólo los artefactos que se consideren necesarios para el proyecto, adicionalmente según los lineamientos establecidos se les puede hacer modificaciones a los mismos y también se pueden establecer artefactos adicionales a los aquí propuestos. 40

MeRinde Guía Detallada Es importante que la documentación del sistema permanezca actualizada y consistente durante todo el ciclo de vida de desarrollo del sistema. Hay artefactos que se convierten en documentos, así mismo cuando se desarrolla un sistema para un tercero hay artefactos que pueden ser entregados al cliente y otros que no, esto depende fundamentalmente por el acuerdo que se realice entre las partes. En la figura 13 se presenta el ícono de un artefacto para MeRinde. Representación Gráfica del Ícono que Específica un Artefacto

13

Figura 13. Representación Gráfica del Ícono que Específica un Artefacto. Es fundamental que antes del comienzo del proceso de desarrollo se decida cuales son los artefactos que serán empleados a lo largo del ciclo de vida del desarrollo del proyecto, así como es recomendado que se defina entre las partes los artefactos que serán entregados. A efectos de esta metodología los artefactos que se describen en esta no son en su totalidad estrictos en su empleo, es decir cada artefacto dependiendo del proyecto puede ser excluido, esto también conforme al acuerdo entre las partes que intervienen en el proyecto. Fundamentalmente se recomienda que se emplee la mayoría de los artefactos que son aquí señalados sobre todo si la magnitud del proyecto es grande. Mientras mayor documentación exista que detalle en profundidad los aspectos de un sistema, mejor será el entendimiento de los grupos de trabajo sobre el proyecto, así mismo esta documentación flexibiliza el proceso posterior de mantenimiento que el sistema puede llegar a tener, adicionalmente es una buena práctica para la elaboración de proyectos que involucran un gran número de personas y roles. Cabe destacar que es válido emplear artefactos adicionales a los aquí recomendados siempre que estos faciliten y cumplan con los requerimientos. 41

MeRinde Guía Detallada A continuación se lista en la tabla 1 los artefactos que se proponen en esta metodología y adicionalmente se indican cuales son los artefactos mínimos a ser tomados en cuenta para el desarrollo de un sistema de software con MeRinde: Tabla 1 Artefactos Propuestos en MeRinde con Indicación de Necesidad 1

Nombre del Artefacto Artefactos de Instalación Calificación de los Aspectos Técnicos de los Servicios de Desarrollo de Sistemas Capsula Casos de Pruebas Componente Operacional del Sistema Criterios de Aceptación Datos de Pruebas Documento de Arquitectura del Negocio (DAN) Documento de Arquitectura del Software (DAS) Elemento de Implementación Elemento de Soporte de Prueba El Sistema Entidad del Negocio Escenarios por Casos de Uso Especificación de Migración de Datos Especificación de Requerimientos del Software (ERS) Especificaciones Suplementarias Evaluación de la Organización Objetivo (EOO) Glosario del Sistema Herramientas Infraestructura de Desarrollo Licitación de Personal Lineamientos del Proyecto Lista de Ideas de las Pruebas Lista de Materiales Manual de Instalación Manual de Usuario Mapa de Navegación Marco de Desarrollo Material de Adiestramiento Mecanismo de Retroalimentación Modelo de Análisis Modelo de Análisis del Negocio Modelo de Casos de Uso Modelo de Casos de Uso del Negocio Modelo de Datos Modelo de Diseño Modelo de Diseño del Negocio

Necesario

√ √

√ √

√

42

MeRinde Guía Detallada Nombre del Artefacto Modelo de Implantación Modelo de Implantación del Negocio Modelo de Implementación Modelo de Servicio Notas de Lanzamiento Oferta de Servicio del Personal Orden de Trabajo Plan de Adiestramiento Plan de Gestión de Configuración Plan de Gestión de Riesgos Plan de Implantación Plan de Integración Plan de Iteración Plan de Pruebas Planificación del Proyecto Plantillas para el Proyecto Prototipo de la Interfaz de Usuario Prueba de Concepto Arquitectónico del Negocio Realizaciones de los Casos de Uso Realizaciones de los Casos de Uso del Negocio Registro de Evaluación Registro de Revisión Registro de Riesgos Reglas del Negocio Repositorio de Versiones Resultado de Prueba Resumen del Ciclo de Prueba Script de Pruebas Solicitud de Cambio Solicitudes de Involucrados Solicitud del Sistema Subsistema de Implementación Términos de Referencia para el Equipo Desarrolladores del Sistema Términos de Referencia del Sistema Trabajador del Negocio Unidad de Implantación Visión del Negocio Visión del Sistema

Necesario

√ √ √ √

√

√ de

√ √

√

En el Apéndice A se detallan cada uno de los artefactos propuestos en MeRinde por orden alfabético, indicando una descripción breve, su rol responsable, la disciplina a la cual pertenece, si posee plantilla, y si aplica se señala su artefacto contenedor y los

43

MeRinde Guía Detallada que este contenga. A continuación se listaran los artefactos compuestos dentro del proceso de desarrollo propuesto en MeRinde. Artefactos Compuestos Los artefactos mencionados anteriormente que serán generados y utilizados por el proyecto constituyen los entregables. Algunos artefactos están contenidos dentro de otros artefactos, dichos artefactos constituidos por otros se presentan a continuación en la tabla 2: Tabla 2 Listado de Artefactos Compuestos 2

Artefacto Contenedor El Sistema Especificación de Requerimientos del Software (ERS) Infraestructura de Desarrollo Marco de Desarrollo Modelo de Análisis del Negocio Modelo de Diseño Modelo de Diseño del Negocio

Modelo de Implementación

Plan de Pruebas

Artefactos Contenidos Lista de Materiales Artefactos de Instalación Unidad de Implantación Modelo de Caso de Uso Especificaciones Suplementarias Herramientas Lineamientos del Proyecto Entidad del Negocio Trabajador del Negocio Reglas del Negocio Capsula Realizaciones de los Casos de Uso Entidad del Negocio Realizaciones de los Casos de Uso del Negocio Trabajador del Negocio Elemento de Implementación Subsistema de Implementación Elemento de Soporte de Prueba Casos de Pruebas Criterios de Aceptación Datos de Pruebas Escenarios por Caso de Uso Lista de Ideas de las Pruebas Resumen del Ciclo de Prueba

44

MeRinde Guía Detallada No todos los proyectos requieren todos los artefactos, ni con igual grado de profundidad o detalle. Los artefactos son opcionales, y se recomienda usar pocos artefactos, eligiendo los de mayor valor práctico para cada proyecto. En la siguiente sección se mostrará otro componente fundamental de la estructura estática de la metodología propuesta como lo son las disciplinas, las cuales responden a la pregunta cuándo del proceso de desarrollo. Disciplinas de la Metodología La metodología propuesta MeRinde se organiza en disciplinas. Las disciplinas poseen flujos de trabajos en donde cada uno conlleva a actividades (ver figura 14) que a su vez están compuestos por un conjunto de tareas (ver figura 15) realizadas en un área determinada, las cuales tienen como objetivo producir artefactos. A su vez, en MeRinde existen actividades que se dividen en subactividades (ver figura 16) con el fin de facilitar la agrupación de tareas relacionadas. Las disciplinas que conforman esta metodología se dividirán en dos grupos. El primero comprende las disciplinas fundamentales asociadas con las áreas de ingeniería: a. Modelado del Negocio. b. Requerimientos. c. Análisis y Diseño. d. Implementación. e. Pruebas. f. Implantación. El segundo grupo lo integran las disciplinas llamadas de soporte o gestión: a. Gestión de Configuración y Cambios. b. Gestión del Proyecto. c. Gestión del Ambiente. 45

MeRinde Guía Detallada Estas son todas las áreas que de una manera u otra definen el ámbito de la aplicación. Estas disciplinas definen los flujos básicos sobre los cuales se va a ir iterando durante las fases del proyecto. Representación Gráfica del Ícono que Específica una Actividad

14

Figura 14. Representación Gráfica del Ícono que Específica una Actividad. Representación Gráfica del Ícono que Específica una Tarea

15

Figura 15. Representación Gráfica del Ícono que Específica una Tarea.

Representación Gráfica del Ícono que Específica una Subactividad

16

Figura 16. Representación Gráfica del Ícono que Específica una Subactividad. Las disciplinas serán explicadas de forma separada, lo que da una impresión de que el proceso de desarrollo de software en general, del comienzo al fin del proyecto, pasa por las disciplinas sólo una vez, lo cual recuerda erróneamente a las etapas de una metodología en cascada. Esta impresión es incorrecta puesto que como se ha mencionado anteriormente los flujos de trabajo son recorridos secuencialmente por cada iteración que se realice, no una sola vez para el proyecto completo. Por tanto si se tienen nueve iteraciones sobre las cuatro fases del proceso, se recorrerían las disciplinas nueve veces. Es importante destacar que para cada iteración no necesariamente se tiene que recorrer las nueve disciplinas descritas en igual esfuerzo, es decir, según sea

46

MeRinde Guía Detallada necesario para cada iteración se debe aplicar mayor esfuerzo en las disciplinas precisas para cumplir el objetivo de la iteración. A continuación se describen cada una de las disciplinas antes mencionadas. Modelado del Negocio Con esta disciplina se pretende llegar a un mejor entendimiento de la organización donde se va a implantar el sistema de software. Los principales motivos para ejecutar esta disciplina son los siguientes: asegurarse de que el producto será algo útil y no un obstáculo; conseguir que se ajuste de la mejor forma posible en la organización donde se va a implantar; y tener un marco común para el equipo de proyecto, los clientes y los usuarios finales. Esta disciplina no será siempre necesaria. Si sólo se añaden funcionalidades que no verán los usuarios directamente, no hará falta. Los objetivos específicos de la disciplina modelado de negocio son: • Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento común de la organización objetivo. • Derivar los requerimientos del sistema necesarios para apoyar a la organización objetivo en su mejora. • Entender el problema actual en la organización objetivo e identificar potenciales mejoras. • Entender la estructura y la dinámica de la organización para la cual el sistema va a ser desarrollado (organización objetivo). Para lograr estos objetivos, el modelado de negocio describe como desarrollar una visión de la nueva organización, basado en esta visión se definen procesos, roles y responsabilidades de la organización por medio de un Modelo de Casos de Uso del Negocio. Los artefactos del modelo de negocio sirven como entrada y referencia para la definición de los requerimientos del sistema. 47

MeRinde Guía Detallada La importancia de esta disciplina radica en que sin el panorama completo del alcance del negocio y sin el entendimiento de sus procesos no podrán identificarse las necesidades inmediatas de mejora y continuidad relativa a las actividades relacionadas con los sistemas informáticos, que son el producto final del desarrollo. Flujo de trabajo. En la figura 17 se señala el flujo de trabajo de la disciplina Modelado del Negocio a fin presentar como MeRinde contempla la secuencia de acciones, actividades o tareas utilizadas para la ejecución de la disciplina mencionada. Flujo de Trabajo de la Disciplina Modelado del Negocio

17

Figura 17. Flujo de Trabajo de la Disciplina Modelado del Negocio. El objetivo principal de esta disciplina es establecer las funciones que se quiere que satisfaga el sistema a construir. En esta línea los requerimientos son el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requerimientos que se especifiquen. Para obtener los 48

MeRinde Guía Detallada requerimientos se deben aplicar prácticas de licitación a los involucrados en el proyecto, anotar y validar todas sus solicitudes. Los objetivos específicos de la disciplina requerimientos son: • Definir el ámbito del sistema. • Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario. • Establecer y mantener un acuerdo entre clientes y otros involucrados sobre lo que el sistema debería hacer. • Proveer a los desarrolladores un mejor entendimiento de los requerimientos del sistema. • Proveer una base para estimar recursos y tiempo de desarrollo del sistema. • Proveer una base para la planeación de los contenidos técnicos de las iteraciones. Los requerimientos pueden ser divididos en dos grupos: Los requerimientos funcionales, los cuales describen las funciones que el software va a ejecutar; por ejemplo, ajustarse a un formato de texto o modular una señal. Los requerimientos no funcionales, los cuales especifican criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus funciones específicas. En esta disciplina, y como parte de los requerimientos de facilidad de uso, se diseña la interfaz gráfica del usuario. Para ello habitualmente se construyen prototipos de la interfaz gráfica de usuario que se validan con el usuario final. Flujo de trabajo. En la figura 18 se señala el flujo de trabajo de la disciplina Requerimientos a fin presentar como MeRinde contempla la secuencia de acciones, actividades o tareas utilizadas para la ejecución de la disciplina mencionada. 49

MeRinde Guía Detallada Flujo de Trabajo de la Disciplina Requerimientos

18

Figura 18. Flujo de Trabajo de la Disciplina Requerimientos. El objetivo principal de esta disciplina es transformar los requerimientos a una especificación

que

describa

cómo

implementar

el

sistema.

El

análisis

fundamentalmente consiste en obtener una visión que se preocupa de ver que hace el sistema de software a desarrollar, por tal motivo este se interesa en los requerimientos funcionales. Por otro lado, el diseño es un refinamiento que toma en cuenta los requerimientos no funcionales, por lo cual se centra en como el sistema cumple sus objetivos.

50

MeRinde Guía Detallada Los objetivos específicos de la disciplina análisis y diseño son: • Adaptar el diseño para que sea consistente con el entorno de implementación. • Desarrollar una arquitectura para el sistema. • Transformar los requerimientos al diseño del futuro sistema. Al principio de la fase de elaboración hay que definir una arquitectura candidata: crear un esquema inicial de la arquitectura del sistema, identificar clases de análisis y actualizar las realizaciones de los Casos de Uso con las interacciones de las clases de análisis. Durante la fase de elaboración se va refinando esta arquitectura hasta llegar a su forma definitiva. En cada iteración hay que analizar el comportamiento para diseñar componentes. Flujo de Trabajo. En la figura 19 se señala el flujo de trabajo de la disciplina Análisis y Diseño a fin presentar como MeRinde contempla la secuencia de acciones, actividades o tareas utilizadas para la ejecución de la disciplina mencionada.

51

MeRinde Guía Detallada Flujo de Trabajo de la Disciplina Análisis y Diseño

19

Figura 19. Flujo de Trabajo de la Disciplina Análisis y Diseño.

Implementación El objetivo principal de esta disciplina es convertir los elementos del diseño en elementos de implementación, dichos elementos son códigos fuentes, ejecutables, binarios, entre otros. Otra parte de esta disciplina son las pruebas de unidad, las cuales se limitan a los componentes de software implementados. De esta disciplina se obtiene un sistema ejecutable estable, constituido de los resultados producidos por los programadores individuales.

52

MeRinde Guía Detallada Los objetivos específicos de la disciplina implementación son: • Cada desarrollador decide en quequé orden implementa los elementos del subsistema. • Integrar el sistema siguiendo el plan. • Notificar los errores de diseño, si se encuentran. • Planificar qué subsistemas deben ser implementados y en quequé orden deben ser integrados, formando el Plan de Integración. • Probar los subsistemas individualmente. La estructura de todos los elementos implementados forma el Modelo de Implementación. La integración debe ser incremental, es decir, en cada momento sólo se añade un elemento. De este modo es más fácil localizar fallos y los componentes se prueban más a fondo. En fases tempranas del proceso se pueden implementar prototipos para reducir el riesgo. Su utilidad puede ir desde ver si el sistema es viable desde el principio, probar tecnologías o diseñar la interfaz de usuario. Los prototipos pueden ser exploratorios (desechables) o evolutivos. Estos últimos llegan a transformarse en el sistema final. Flujo de trabajo. En la figura 20 se señala el flujo de trabajo de la disciplina Implementación a fin presentar como MeRinde contempla la secuencia de acciones, actividades o tareas utilizadas para la ejecución de la disciplina mencionada.

53

MeRinde Guía Detallada Flujo de Trabajo de la Disciplina Implementación

20

Figura 20. Flujo de Trabajo de la Disciplina Implementación. Pruebas El principal objetivo de esta disciplina es de evaluar la calidad del producto que se está desarrollando a través de las diferentes fases por las cuales este pasa, mediante la aplicación de pruebas concretas para validar que las suposiciones hechas en el diseño y los requerimientos se estén cumpliendo satisfactoriamente, esto quiere decir que se verifica que el producto funcione como se diseñó y que los requerimientos son satisfechos cabalmente. Esta disciplina brinda soporte para encontrar y documentar (y solucionar) defectos en la calidad del sistema a las otras disciplinas. Esta disciplina debe estar presente en todo el ciclo de vida del desarrollo del sistema para ir refinándolo y no al final del mismo. 54

MeRinde Guía Detallada

Los objetivos específicos de la disciplina pruebas son: • Encontrar y documentar defectos en la calidad del software. • Notificar la calidad percibida del software. • Proveer un medio de validación para las suposiciones hechas en el diseño

y

especificaciones

de

requerimientos

por

medio

de

demostraciones concretas. • Validar las funciones del producto de software según lo diseñado. • Validar que los requerimientos fueron implementados apropiadamente. El desarrollo de esta disciplina consistirá en planificar que es lo que hay que probar, diseñar cómo se va a llevar a cabo la prueba, implementar lo necesario para llevarlas a cabo, ejecutarlas en los niveles necesarios y obtener los resultados, de forma que la información obtenida sirva para ir refinando el producto a desarrollar. El papel de las pruebas no es asegurar la calidad, pero sí evaluarla, y proporcionar una realimentación a tiempo, de forma que los aspectos de calidad puedan resolverse de manera efectiva en tiempo y costo. Los principales aspectos a ser evaluados en un producto software son la funcionalidad (hace lo que debe), la fiabilidad (resistente a fallos), y el rendimiento (lleva a cabo su trabajo de manera efectiva). Las pruebas pueden hacerse a diferentes niveles dependiendo del objetivo de los mismos, entre algunos tenemos: Pruebas de unidad (se prueban las unidades mínimas por separado, y normalmente se hace durante la implementación misma), de integración (varias unidades juntas), de sistema (sobre la aplicación o sistema completo) y de aceptación (realizado sobre el sistema global por los usuarios o terceros).

55

MeRinde Guía Detallada Flujo de trabajo En la figura 21 se señala el flujo de trabajo de la disciplina Pruebas a fin presentar como MeRinde contempla la secuencia de acciones, actividades o tareas utilizadas para la ejecución de la disciplina mencionada. Flujo de Trabajo de la Disciplina Pruebas

21

Figura 21. Flujo de Trabajo de la Disciplina Pruebas.

56

MeRinde Guía Detallada Implantación Esta disciplina tiene como objetivo distribuir e instalar con éxito el sistema elaborado por el equipo de desarrollo y asegurar la disponibilidad del producto para los usuarios finales. Sus objetivos específicos son: • Formar a los usuarios y al cuerpo encargado de distribuir el sistema. • Instalar el software. • Migrar el software existente. • Probar el producto en su entorno de ejecución final. • Proveer asistencia y ayuda a los usuarios. Se lleva a cabo con mayor intensidad en la fase de transición, debido a que su propósito es asegurar una aprobación y adaptación sin que existan dificultades del software por parte del usuario. Esta disciplina debe iniciar en fases anteriores, para preparar el camino, sobre todo con actividades relacionadas a la planificación, pero también con la elaboración del manual de usuario y tutoriales. Debido al extenso nivel de aplicaciones que se pueden obtener y las diversas características de los productos necesarios para esta disciplina, se pueden obtener grandes variaciones dependiendo del tipo de sistema a desarrollar. El objeto clave es una distribución del producto. Dado las diversas especificaciones de implantación que se pueden dar para cada proyecto, se le otorga en esta metodología pocos detalles a esta fase. Aunque el sistema esté bien diseñado y desarrollado correctamente su éxito dependerá de su implantación y ejecución por lo que es importante capacitar al usuario con respecto a su uso y mantenimiento.

57

MeRinde Guía Detallada Flujo de Trabajo. En la figura 22 se señala el flujo de trabajo de la disciplina Implantación a fin presentar como MeRinde contempla la secuencia de acciones, actividades o tareas utilizadas para la ejecución de la disciplina mencionada. Flujo de Trabajo de la Disciplina Implantación

22

Figura 22. Flujo de Trabajo de la Disciplina Implantación.

58

MeRinde Guía Detallada Gestión de Configuración y Cambios El objetivo de esta disciplina es mantener la integridad de todos los objetos que se crean en el proceso y controlar los cambios. Se debe identificar elementos de configuración, restringir y auditar los cambios a esos elementos, y definir y dirigir la distribución de los mismos. Sus objetivos específicos son: • Asegurar que los productos desarrollados sean completados y corregidos debidamente. • Dar soporte a los métodos de desarrollo. • Mantener la consistencia de los productos durante la evolución de los mismos. • Mantener la integridad del producto. • Proveer datos para medir el progreso. • Proveer los medios eficientes para adaptarse apropiadamente a los cambios y a los replanteamientos de planes de trabajo. • Proveer un ambiente estable durante el desarrollo del producto. • Proveer una brecha para auditorías que permita identificar el por qué, cuándo y por quién ha sido modificado un proyecto. • Restringir los cambios a los productos según las políticas del proyecto. Esta disciplina abarca tres funciones como son: • La gestión de la configuración, que maneja estructura del producto, configuraciones, la identificación de los elementos, versiones y espacio de trabajo. • La gestión de solicitudes de cambio, regula el proceso de cambiar artefactos de una forma estable. • Las métricas y estatus, que permite extraer información de las dos herramientas anteriores, para conducir correctamente el proyecto. 59

MeRinde Guía Detallada

Entre algunas de las causas por las que la evolución de los artefactos puede causar problemas son: • Actualización simultánea: Se da cuando dos personas trabajan por separado sobre el mismo artefacto a la vez, el último en hacer las modificaciones sobrescribe lo hecho por el primero. • Múltiples versiones: Cuando se trabaja con diferentes versiones del producto al mismo tiempo en diferentes flujos de trabajo, pueden surgir problemas si los cambios no son convenientemente monitorizados y propagados. • Notificación limitada: Cuando un problema ha sido resuelto en un artefacto compartido por varios roles y algunos de ellos no son notificados del cambio. Flujo de trabajo. En la figura 23 se señala el flujo de trabajo de la disciplina Gestión de Configuración y Cambios a fin presentar como MeRinde contempla la secuencia de acciones, actividades o tareas utilizadas para la ejecución de la disciplina mencionada.

60

MeRinde Guía Detallada Flujo de Trabajo de la Disciplina Gestión de Configuración de Cambios

23

Figura 23. Flujo de Trabajo de la Disciplina Gestión de Configuración de Cambios. Gestión del Proyecto El objetivo de la gestión del proyecto es conseguir alcanzar los objetivos propuestos, administrar el riesgo y superar las restricciones para desarrollar un producto que sea acorde a los requerimientos de los clientes y usuarios. Los objetivos específicos de la disciplina Gestión del Proyecto son: • Proveer guías prácticas para realizar planeación, contratar personal, ejecutar y monitorear el proyecto. • Proveer un marco de trabajo para gestionar riesgos. • Proveer un marco de trabajo para la gestión de proyectos de software intensivos. Para conseguir estos objetivos el flujo de trabajo de esta metodología se centra en tres aspectos: 61

MeRinde Guía Detallada a. Administrar el riesgo. b. Monitorear el progreso del proyecto a través de métricas. c. Planificar un proyecto iterativo y cada iteración en particular. Monitorear un proyecto es importante para mantenerlo bajo control. Esto permite medir la magnitud en la que el proyecto se ajusta a los planes, la calidad requerida y los requerimientos. También es necesario para planificar de forma precisa y ver cuál es el comportamiento del proyecto frente a cambios. La administración del riesgo consiste en ocuparse de las incógnitas de un proyecto, las cuestiones que puede afectar el desarrollo del proyecto y llevarlo al fracaso. En concreto hay que identificar los riesgos, típicamente en la fase de inicio, y hacerles frente, mitigar, transferirlos o asumirlos. En este último caso habrá que tratar de mitigar el riesgo y definir un plan de contingencia por si el riesgo se convierte en un problema real. En definitiva la administración del riesgo consistirá en gestionar una lista de riesgos. Flujo de trabajo. En la figura 24 se señala el flujo de trabajo de la disciplina Gestión del Proyecto a fin presentar como MeRinde contempla la secuencia de acciones, actividades o tareas utilizadas para la ejecución de la disciplina mencionada.

62

MeRinde Guía Detallada Flujo de Trabajo de la Disciplina Gestión del Proyecto

24

Figura 24. Flujo de Trabajo de la Disciplina Gestión del Proyecto. Elaborado por los Autores con datos de Rational Unified Process de IBM Corporation, 2006.

63

MeRinde Guía Detallada Gestión del Ambiente La finalidad de esta disciplina es dar soporte al proyecto con los procesos, métodos y herramientas correctas. Ofrece una descripción de las herramientas que se van a necesitar para el

apropiado desarrollo del software, que contendrá las

herramientas de desarrollo y del proceso, plantillas, documentos, lineamientos a seguir, y cualquier otro elemento necesario para llevar adelante con éxito el desarrollo del proyecto. En concreto los objetivos específicos de esta disciplina son: • Configurar el proceso. • Establecer y configurar las herramientas para que se ajusten a la organización. • Mejorar el proceso de desarrollo. • Proveer los servicios técnicos necesarios. • Seleccionar y adquirir herramientas.

Flujo de trabajo. En la figura 25 se señala el flujo de trabajo de la disciplina Gestión del Ambiente a fin presentar como MeRinde contempla la secuencia de acciones, actividades o tareas utilizadas para la ejecución de la disciplina mencionada.

64

MeRinde Guía Detallada Flujo de Trabajo de la Disciplina Gestión del Ambiente

25

Figura 25. Flujo de Trabajo de la Disciplina Gestión del Ambiente. Elaborado por los Autores con datos de Rational Unified Process de IBM Corporation, 2006. En conclusión MeRinde tiene nueve (9) disciplinas, una de ellas que es la de Modelado de Negocio es opcional, es decir se puede o no tomar en cuenta, todo depende de las particularidades propias del proyecto. En MeRinde las disciplinas serán visitadas una y otra vez por cada iteración a lo largo de todo el proceso. Además, las disciplinas tienen asociadas flujos de trabajo, actividades y tareas. Una actividad refleja la relación entre roles, tareas y artefactos.

65

MeRinde Guía Detallada En el Apéndice B se señala en detalle cada una de las Actividades propuestas que aparecen en los Flujos de Trabajo de cada una de las disciplinas, así como también las Tareas que conforman cada una de las Actividades. Seguidamente se presentará el Marco de Desarrollo propuesto, el cual demarca la configuración de MeRinde, es decir las disciplinas y sus artefactos, y se indica un estimado de cuando se deben elaborar cada uno de los artefactos durante el proceso de desarrollo de software. Marco de Desarrollo de MeRinde La Tabla 3 que se presenta seguidamente resume las disciplinas de MeRinde y sus artefactos asociados, indicando también, para las fases de esta, el grado aproximado de desarrollo de cada uno de sus artefactos. Tabla 3 Relación entre los Componentes y las Fases de la Metodología 3

COMPONENTES Disciplina Artefacto Documento de Arquitectura del Negocio Evaluación de la Organización Objetivo (EOO) Visión del Negocio Modelo de Análisis del Negocio: Entidad del Negocio Trabajador del Negocio Reglas del Negocio Modelado del Modelo de Caso de Uso del Negocio Negocio Modelo de Diseño del Negocio: Entidad del Negocio Realizaciones de los Casos de Uso del Negocio Trabajador del Negocio Modelo de Implantación del Negocio Prueba de Concepto Arquitectónico del Negocio

FASES I E C c c c

T

c c c c c

66

MeRinde Guía Detallada COMPONENTES Disciplina Artefacto Especificación de Requerimientos de Software: Especificaciones Suplementarias Modelo de Casos de Uso Requerimientos Glosario del Sistema Solicitud de Involucrados Visión del Sistema Documento de Arquitectura del Software Especificación de Migración de Datos Mapa de Navegación Modelo de Análisis Modelo de Datos Análisis y Prototipo de la Interfaz de Usuario Diseño Modelo de Diseño: Capsula Realizaciones de los Casos de Uso Modelo de Implantación Modelo de Servicio Componente Operacional del Sistema Modelo de Implementación: Elemento de Implementación Implementación Subsistema de Implementación Elemento de Soporte de Prueba Plan de Integración Resultado de Prueba Plan de Pruebas: Casos de Pruebas Criterios de Aceptación Pruebas Datos de Pruebas Escenarios por Caso de Uso Lista de Ideas de las Pruebas Resumen del Ciclo de Prueba Script de Pruebas

FASES I E C c

r

r

c c c c

r r r r c c c c c

r r

c

r

c

T

r r

r r r

c

r

c c

c

c

c

r

r

c c

r c

r c

r

r

r

c

67

MeRinde Guía Detallada COMPONENTES Disciplina Artefacto El Sistema: Lista de Materiales Artefactos de Instalación Unidad de Implantación Manual de Instalación Implantación Manual de Usuario Material de Adiestramiento Mecanismo de Retroalimentación Notas de Lanzamiento Plan de Adiestramiento Plan de Implantación Plan de Gestión de Configuración Gestión de Configuración y Solicitud de Cambio Cambios Repositorio de Versiones Calificación de los Aspectos Técnicos de los Servicios de Desarrollo de Sistemas Licitación de Personal Oferta de Servicio del Personal Orden de Trabajo Plan de Gestión de Riesgos Plan de Iteración Gestión del Planificación del Proyecto Proyecto Registro de Evaluación Registro de Revisión Registro de Riesgos Solicitud del Sistema Términos de Referencia del Sistema Términos de Referencia para el Equipo de Desarrolladores del Sistema Infraestructura de Desarrollo: Herramientas Gestión del Marco de Desarrollo: Ambiente Lineamientos del Proyecto Plantillas para el Proyecto

FASES I E C

T c

c r c c c c c r c r

r r r

c r r r c c r

c r r

c r r

c c r

c c r

c

r

r

r

c

c c c

r c r

r r c r

c c c c c c c c c c c c c

c c

Nota. Tabla elaborada por los Autores. I: Fase de Inicio. E: Fase de Elaboración. C. Fase de Construcción. T: Fase de Transición. c: Comienzo de la construcción del artefacto. r: Refinamiento del artefacto (ampliación, corrección).

68

MeRinde Guía Detallada Una vez conocidas las dos (2) estructuras de MeRinde se procederá a detallar su habilitar Web, medio a través del cual será implantada y distribuida la metodología.

69

MeRinde Guía Detallada

CAPÍTULO IV APORTES, VENTAJAS Y DESVENTAJAS DE LA METODOLOGÍA

Aportes de la Metodología La Metodología para el desarrollo de software MeRinde posee algunas características que hace de esta un proceso único. A continuación se presentan los aportes de la MeRinde a los proyectos del CNTI y demás instituciones del estado dedicadas al desarrollo de sistemas, lo cual la diferencia de otras metodologías. Estandarización

del

proceso

de

desarrollo,

documentación

y

herramientas: Una de las primeras facilidades que una persona encuentra al utilizar y aprender MeRinde es el uso de un proceso de desarrollo, documentación y herramientas estandarizados. La metodología estandariza el proceso de desarrollo de software ya que esta provee y rige el uso de una serie de conceptos asociados a actividades, tareas, roles y artefactos que permiten tener una definición concisa del proceso de desarrollo entre las personas involucradas en un proyecto. Adicionalmente las plantillas de los artefactos que envuelve dicha metodología también ofrecen un estándar, ya que estos son un modelo o guía para documentar adecuadamente los sistemas. Por otro lado, dicha metodología propone el uso del Lenguaje de Modelado unificado (UML) como herramienta para elaborar los diagramas que corresponde a los modelos y las vistas de la arquitectura. Flujos de trabajo que refleja la realidad del desarrollo de software: La metodología propuesta en este trabajo de investigación refleja flujos de trabajo por disciplina adaptados a la realidad y el deber ser del desarrollo de software que se vive 70

MeRinde Guía Detallada en el CNTI con las cooperativas y pequeñas empresas contratadas. MeRinde con el establecimiento de los flujo de trabajo fortalece la planificación y coordinación del proceso de desarrollo de software, dado que cada flujo de trabajo tipifica una serie de actividades que muestran los roles, tareas y artefactos que deben ser satisfechos para desarrollar un sistema. Proceso de desarrollo, documentación y herramientas basadas en estándares abiertos: La metodología MeRinde fue desarrollada utilizando estándares abiertos, lo cual incluye las plantillas propuestas de sus artefactos y el habilitador Web que la contempla. Adicionalmente la metodología está publicada sin restricciones de ningún tipo, se puede adoptar libremente y está controlada por una organización pública que vela por su evolución, en este caso dicha organización es el CNTI. Con el uso de estándares abiertos, es posible destinar tiempo, talento y dinero para conducir a las empresas, la industria, la Administración Pública y a toda la sociedad hacia una situación de mayor progreso. Modelo de equipo para el desarrollo de software que supera limitaciones geográficas: MeRinde propone un modelo de equipo que supera las restricciones impuestas por la ubicación del equipo de proyecto, a su vez sirve para cuando se desarrolla software con personal interno, externo o ambos inclusive, a una organización. Adicionalmente este modelo se fundamenta en tres (3) conceptos básicos para su funcionamiento óptimo como son la cooperación, colaboración y la coordinación entre todos los miembros del equipo de proyecto. Propicia calidad en el proceso y en el producto final: MeRinde permite que se desarrolle software con un enfoque continuo en la calidad. Por tal motivo incluye dos roles fundamentales para garantizar calidad al proceso y al sistema desarrollado que son el Mentor y el Analista de Calidad. El Mentor considerado como un experto en la metodología que se está empleando apoya la calidad con la revisión de los documentos generados durante el proyecto, así como también aclarando cualquier duda a los participantes en el proyecto acerca del proceso de desarrollo que se está 71

MeRinde Guía Detallada siguiendo; y el Analista de Calidad decide que modificaciones se van a realizar de las recomendadas por el Mentor, revisa los documentos que reflejan el avance del proyecto y verifica que los objetivos preestablecidos se cumplan. Plantillas de los artefactos: MeRinde ofrece una serie de plantillas que ayudarán a los responsables de elaborar los artefactos sugeridos. Estas establecen unas pautas recomendadas para documentar diversos aspectos de los sistemas de software sobre los cuales el equipo de proyecto puede trabajar. La idea de las mismas es adaptarlas de acuerdo a la realidad de los proyectos manejados por la organización. Cabe destacar que las plantillas que aporta esta metodología fueron realizadas por los autores tomando en cuenta las plantillas de otras metodologías y de un proyecto que provee plantillas de ingeniería de software reutilizables, además involucra plantillas que ya existían en la organización para documentar los sistemas. De acuerdo a lo recomendado por MeRinde todos los artefactos generados que tienen asociado una plantilla se convierten en documentos, estos serán revisados y puestos bajo control de versiones, por la cual se debe contar con un repositorio de documentos. Esto permite tener una documentación adecuada y organizada para cada uno de los proyectos, permitiendo la mantenibilidad y reutilización. Adaptación de varias prácticas probadas por el aprendizaje: MeRinde se basa en un conjunto de prácticas que se alejan de ser nuevas pero se combinan de forma tal que se adaptan a las necesidades del CNTI y al contexto en que se halla el SL en Venezuela. Las prácticas propuestas por MeRinde no son creadas por los autores de dicha metodología pero surgen del aprendizaje de una serie de autores que han participado en el desarrollo de muchos proyectos. Cabe destacar que las prácticas que envuelve MeRinde han sido probadas con tiempo suficiente y además han tenido el éxito que se considera para ubicarlas en la categoría de “Mejores Prácticas”.

72

MeRinde Guía Detallada Ventajas de la Metodología Entre algunas de las ventajas de emplear la metodología se encuentran: Trazabilidad del Proceso de desarrollo: La metodología admite trazabilidad en la documentación de los sistemas, ya que algunos de sus artefactos se relacionan entre sí, es decir algunos artefactos son insumos de otros. MeRinde permite trazabilidad a partir de los casos de uso, ya que estos permiten realizar el análisis, el diseño y los casos de prueba. Además, la metodología proporciona procedimientos que permiten registrar e identificar cada producto generado desde el inicio hasta el final del proceso de desarrollo de software. En algunas plantillas de los artefactos aportadas por la metodología contienen un historial de revisiones que permite llevar un control de las revisiones de las versiones de algún documento, y con respecto al registro de versiones y de las modificaciones hechas al software, estos se plasman en un artefacto denominado Notas de Lanzamiento. Con esto también la metodología garantiza trazabilidad del proceso de desarrollo permitiendo comparar un versión con otra y observar los avances. Adaptación y extensión de la metodología según las particularidades del proyecto: MeRinde es un marco de trabajo que puede ser adaptado y/o extendido a una amplia gama de actividades, artefactos y roles conforme a las distintas necesidades de proyectos pequeños, medianos y grandes, es decir, permite seleccionar los elementos de la metodología o incluir elementos que no proporciona la metodología pero que se consideran necesarios dependiendo de las características particulares del proyecto. Adicionalmente MeRinde proporciona un artefacto llamado Marco de Desarrollo donde se reflejan las configuraciones que se ajustan a las necesidades del proyecto.

73

MeRinde Guía Detallada Habilitador metodológico fácil de manejar: MeRinde está contenida en un habilitador Web, es decir, un manejador de contenidos Web que refleja la información de la metodología junto a las plantillas de sus artefactos de una forma agradable al usuario y sobre todo con una navegación sencilla por intuición y ayuda en línea. El habilitador tiene una baja curva de aprendizaje, ya que solo requiere para su utilización que el usuario conozca aspectos básicos de la navegación de páginas Web. Planificación, agilidad y control de los procesos de desarrollo de software: MeRinde se basa en la planificación que conlleva a tener una gestión y toma de decisiones de alta calidad. La planificación se logra mediante un proceso de descubrimiento de la información que lleve a estimaciones razonables. Hay casos en que la realidad no se parece a lo previsto, por la cual hay que hacer ciertos ajustes. La metodología involucra entre sus artefactos planes para el proyecto, iteraciones, implantación, pruebas, entre otros. Esto permite organizar, controlar, evaluar y mejorar el proceso de desarrollo de software, lo cual es de valor cuando se desarrolla software para el estado. Reutilización de componentes: La metodología MeRinde propicia la reutilización de modelos, proceso, etc. ya definidos en implementaciones previas de esta metodología. Permite que cuando se vaya a realizar un módulo desde cero se haga una búsqueda para tratar de localizar algún componente reutilizable de fuente abierta que pueda simplificar el desarrollo del módulo. Por lo cual la documentación y módulos de algún sistema capaz de operar independientemente desarrollados con esta metodología pueden ser tomados en cuenta para futuros proyectos dentro o fuera del CNTI. La reutilización basada en componentes permite reducir los costos y el tiempo en el proceso de desarrollo de software. Mayor integración entre el cliente y los desarrolladores: La metodología involucra al cliente en el proceso de desarrollo de software con una continua participación en determinadas actividades que se repiten a lo largo del ciclo de vida 74

MeRinde Guía Detallada de desarrollo, ya que este es quien finalmente evaluará, aprobará o desaprobará el proyecto. La integración y la comunicación entre el cliente y los desarrolladores evitará malos entendidos y evitará perder tiempo en rehacer el sistema. Por lo cual la opinión del cliente acerca del proyecto es la base para hacer los reajustes si algo no estuviese del todo bien. En las actividades de algunas disciplinas reflejadas en MeRinde hace su aparición el cliente como involucrado en el proyecto, al cual se le atribuye algunas tareas que debe realizar en colaboración con otros involucrados. El cliente sirve de apoyo en tareas orientadas a entender el negocio, identificar los requerimientos, hacer planes, acordar las pruebas, enviar solicitudes de cambio, entre otras. Fortalecimiento del perfil de las empresas, cooperativas y comunidades desarrolladoras de SL: Con MeRinde las organizaciones pueden adoptar una metodología libre, para aumentar su capacidad de control, trazabilidad y reutilización. Por otro lado, la definición de actividades, tareas y roles permitirá a las organizaciones aumentar la planificación, distribuir funciones entre los miembros del equipo y mitigar el caos implícito en el desarrollo de software. A su vez, MeRinde contribuye con la educación y la formación del capital humano en el uso y aplicación de las TIC. Habilitador Web con Foro: El habilitador Web incorpora un foro como herramienta para que personas de las comunidades de desarrollo ayuden al fortalecimiento de la metodología y de sus artefactos con el aporte de ideas, y para discutir cualquier clase de dudas que se les pueda presentar a los usuarios sobre la metodología.

75

MeRinde Guía Detallada Desventajas de la Metodología Entre algunas de las desventajas observadas en la metodología se encuentran: Falta de plantillas para un grupo determinado de artefactos: MeRinde no provee plantillas para todos los artefactos que esta contempla, pero ninguno de esos artefactos planteados son considerados para los proyectos como esenciales, adicionalmente hay artefactos que por su descripción se puede sobreentender su contenido y estructura. La metodología puede ser vista como muy pesada: El contenido de la metodología es muy amplio y complejo, lo que puede ser visto como muy pesado, por tal motivo, quienes desconozcan que esta es un marco de trabajo es posible que no la utilicen, ya que caen en el error de pensar que hay que considerar todos los elementos que esta ofrece y que esta no admite adaptabilidad ni extensibilidad dependiendo de las particularidades del proyecto, lo cual no es cierto. No contempla una herramienta para instanciar el proceso de desarrollo: MeRinde solo contempla la instanciación del proceso conforme a todos sus artefactos, actividades y tareas, pero no posee una herramienta para hacer las personalizaciones a los proyectos, para ello se sugiere el empleo de herramientas de terceros como el Eclipse Process Framework Project (EPF) disponible en http://www.eclipse.org/epf/. No especifica la instanciación del proceso para pequeños, medianos y grandes proyectos: MeRinde no especifica que disciplinas, actividades, tareas, roles y subroles se deben emplear conforme a la magnitud del proyecto, pero si especifica cuáles son las disciolinas, artefactos y roles esenciales para el desarrollo de cualquier proyecto.

76

MeRinde Guía Detallada

SÍNTESIS DE LA METODOLOGÍA MERINDE La Metodología MeRinde es un proceso de desarrollo de software. Un proceso de desarrollo de software es el conjunto de actividades necesarias para transformar los requerimientos de un usuario en un sistema software. Sin embargo, La Metodología MeRinde más que un proceso simple; es un marco de trabajo genérico que puede especializarse para una gran variedad de sistemas software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyecto. La Metodología MeRinde está basado en componentes, lo cual quiere decir que el sistema software en construcción está formado por componentes software interconectados a través de de interfaces bien definidas. La Metodología MeRinde utiliza el Lenguaje Unificado de Modelado (Unified Modeling Language, UML) para preparar todos los esquemas de un sistema software. Esta propuesta metodológica, la cual fue utilizada en la experiencia descrita en este documento, surge de la combinación y adaptación de modelos y metodologías ampliamente utilizadas para el desarrollo de software.

77

MeRinde Guía Detallada

GLOSARIO En esta sección se presentará una lista que contiene las definiciones de los términos utilizados en este trabajo de investigación. Dichos términos se definen en orden alfabético a continuación: Actividad: Es una unidad de trabajo que una persona que desempeñe un rol puede ser solicitado a que realice. Las actividades tienen un objetivo concreto, normalmente expresado en términos de crear o actualizar algún producto. Administración Pública: Descripción de la base metodológica para el desarrollo del proyecto y el logro de los resultados esperados. Conjunto de organismos e instituciones que se encargan de esta organización. Artefacto: Es un trozo de información que es producido, modificado o usado durante el proceso de desarrollo de software. Los artefactos son los resultados tangibles del proyecto. Caso de Uso: Es una técnica para la captura de requerimientos de un nuevo sistema o una actualización software. Ciclo de Vida: Conjunto de fases sucesivas compuestas por tareas planificables que contribuyen a generar un producto intermedio, necesario

para

continuar hacia el producto final y facilitar la gestión del proyecto. Componente: Representa una parte modular del sistema que encapsula su contenido y cuya manifestación es reemplazable dentro de su ambiente. Comunicación: intercambio con otro u otros de información.

78

MeRinde Guía Detallada Configuración: Es una colección de propiedades que determinan el comportamiento del proceso de elaboración del software. Cooperación: Realización de un trabajo o tarea con otro u otros para un mismo alcanzar un mismo fin. Coordinación: Reunión de medios, esfuerzos, etc., para una acción común. Diagrama: Representación gráfica en el que se muestran las relaciones entre las diferentes partes de un conjunto o sistema. Disciplina: es un conjunto de actividades realizadas en un área determinada. Las actividades producen artefactos. Estándar: Es una norma que regula la realización de ciertos procesos o la fabricación de componentes. En otras palabras es un modelo que se sigue para realizar un proceso o una guía que se sigue para no desviarnos de un lugar al que se desea llegar. Estereotipo: Un nuevo tipo de elemento de modelado que extiende la semántica de un metamodelo. Los estereotipos deben basarse en ciertos tipos existentes o clases en el metamodelo. Los estereotipos pueden extender la semántica, pero no la estructura o tipos pre-existentes y clases. Fase: Expresa cómo ha progresado el desarrollo de un software y cuánto desarrollo puede requerir. Fichero: Es todo conjunto organizado de datos de carácter personal, cualquiera que fuere la forma o modalidad de su creación, almacenamiento, organización y acceso.

79

MeRinde Guía Detallada Finde Forge: Herramienta de software libre que ayuda a gestionar todo el ciclo de vida de desarrollo de proyectos de software. “Framework” o Marco de Trabajo: Es una estructura de soporte definida en la cual otro proyecto de software puede ser organizado y desarrollado. Provee una estructura y una metodología de trabajo la cual extiende o utiliza las aplicaciones del dominio. Flujo de Trabajo: es el estudio de los aspectos operacionales de una actividad de trabajo: cómo se estructuran las tareas, cómo se realizan, cuál es su orden correlativo, cómo se sincronizan, cómo fluye la información que soporta las tareas y cómo se le hace seguimiento al cumplimiento de las tareas. Habilitador: Que habilita a alguien. Es un intermediario entre el usuario y la información. Herramienta: Funciones que ofrece un programa a través de una barra con íconos, que representan los distintos recursos del software para realizar una tarea determinada. Hito: Punto de control de objetivo intermedio antes de que el proyecto finalice. Iteración: Repetición de una secuencia de instrucciones o eventos. Lenguaje Unificado de Modelado (UML): Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de software. Licencia: El derecho de uso de una versión específica de un producto.

80

MeRinde Guía Detallada Mentoría: Es un proceso mediante el cual una persona o varios personas con experiencia ayuda a otras personas a lograr sus metas y cultivar sus habilidades a través de una serie de reuniones de tipo personal, confidencial y limitadas en cuanto al tiempo y otras actividades de aprendizaje, dentro de una organización. Metodología: Manera sistemática de hacer cierta cosa. Modelo: Es una vista de un sistema del mundo real, es decir, una abstracción de dicho sistema considerando un cierto propósito. Módulo: Es un componente autocontrolado de un sistema, el cual posee una interfaz bien definida hacia otros componentes. Plantilla: Es un conjunto predefinido de formas que establece la estructura necesaria para crear contenido rápidamente. Repositorio: Es un sitio centralizado donde se almacena y mantiene información, habitualmente bases de datos o archivos informáticos. Requerimiento: Es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Reutilización: Puede entenderse como el hecho de volver a utilizar los bienes o productos. La utilidad puede venir para el usuario mediante una acción de mejora o restauración, o sin modificar el producto si es útil para un nuevo usuario. Rol: Define el comportamiento y responsabilidades de un individuo, o de un grupo de individuos trabajando juntos como un equipo.

81

MeRinde Guía Detallada Script: Es un guión o conjunto de instrucciones. Permiten automatizar tareas creando pequeñas utilidades. Son interpretadas por un intérprete y usualmente son archivos de texto. Stakeholder: Toda aquella persona u organización siendo influenciada o ejerciendo influencia sobre el software que está siendo construido. Sociedad del Conocimiento: sociedad dotada de habilidad, capacidad y pericia para generar y captar nuevos conocimientos y tener acceso a la información, a los datos y a los conocimientos absorberlos y utilizarlos eficazmente con el apoyo de las Tecnologías de Información y Comunicación. Tarea: Parte de una Actividad. Las tareas son actividades específicas que contribuyen al cumplimiento de la misión general u otros requerimientos. Tecnología de Información y Comunicación (TIC): Concepto empleado para designar lo relativo a la informática conectada con los medios de comunicación, especialmente con Internet, son medios que nos aportan un flujo ininterrumpido de información. Trazabilidad: Aquellos procedimientos preestablecidos y autosuficientes que permiten conocer el histórico, la ubicación y la trayectoria de un producto o lote de productos a lo largo de la cadena de suministros en un momento dado, a través de unas herramientas determinadas.

82

MeRinde Guía Detallada

REFERENCIAS BIBLIOGRÁFICAS

Farouz, Joachim (2006) Kopete Vista Icono Theme [Document en línea]. Disponible: http://www.kde-look.org/content/show.php?content=48635

como

48635-

Kopete_Vista.tar [consulta: 2006, Diciembre 16].

83

MeRinde Guía Detallada

APÉNDICES

84

MeRinde Guía Detallada

APÉNDICE A DESCRIPCIÓN DE LOS ARTEFACTOS PROPUESTOS DE MERINDE

85

MeRinde Guía Detallada A continuación se detallan y se establecen las relaciones en orden alfabético de cada uno de los artefactos que se proponen MeRinde: Artefactos de Instalación Este artefacto tiene como objetivo permitir que la instalación del sistema sea llevado a cabo por alguien. Se basa en los programas e instrucciones documentadas requeridos para que ese alguien instale el producto. Puede incluir: instrucciones, scripts, iconos, archivos de licencia, etc. Los Artefactos de Instalación son necesarios cuando se quiere configurar el sistema mediante los programas de instalación y pueden ser descartados si el sistema es instalado una vez, ya sea porque el sistema es de uso interno en un servidor corporativo. Las instrucciones de instalación se reflejan en el Manual de Instalación y si se espera que el usuario instale el producto (sistema) puede reflejarse en el Manual de Usuario. Relaciones de Artefactos de Instalación Rol Responsable:

Desarrollador

Disciplina:

Implantación

Artefacto Contenedor:

El Sistema

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Calificación de los Aspectos Técnicos de los Servicios de Desarrollo de Sistemas Este artefacto debe contener instrumentos para la recolección de los aspectos técnicos de los servicios de desarrollo de sistemas que han prestado las potenciales contratistas que ofrezcan sus servicios para el desarrollo del producto, a fin de ser

86

MeRinde Guía Detallada evaluados por los miembros del comité de selección para elegir las contratistas que sean necesarias para el proyecto. Para la elaboración de este artefacto se debe haber suministrado a las potenciales contratistas el artefacto Términos de Referencia del Sistema, a fin de que ellas plasmen en este artefacto conforme al proyecto que se desea realizar: una propuesta de servicio, su experiencia en trabajos anteriores, su método o forma de trabajo, una planificación para la ejecución del trabajo, descripción de la cantidad y nivel académico del personal con que dispondrán, entre otras características que se puedan evaluar para la selección de la mejor oferta. Relaciones del Artefacto Calificación de los Aspectos Técnicos de los Servicios de Desarrollo de Sistemas Rol Responsable:

Involucrados

Disciplina:

Gestión del Proyecto

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee Capsula

Este artefacto es un modelo de diseño específico que representa a un hilo de control en el sistema en desarrollo, es útil para modelar y diseñar sistemas que tienen un alto grado de concurrencia, y su empleo como notación facilita el diseño. Una capsula es un elemento compuesto y se representa como una clase estereotipada con el nombre de . Para ver su notación se debe revisar UML 2.0 o superior en la sección sobre Estructuras Compuestas.

87

MeRinde Guía Detallada Relaciones del Artefacto Capsula Rol Responsable:

Arquitecto de Software

Disciplina:

Análisis y Diseño

Artefacto Contenedor:

Modelo de Diseño

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee Casos de Pruebas

Este artefacto define un conjunto de datos de entradas, condiciones de ejecución y resultados esperados de las pruebas, identificados para hacer una evaluación de los aspectos específicos de un elemento objeto de prueba. Cada Caso de de Prueba está asociado a un escenario de un Caso de Uso en particular. Los casos de prueba deben ser escritos con el detalle suficiente para que el probador pueda empezar rápidamente a ejecutar pruebas y a encontrar defectos. Además, estos reflejan trazabilidad con los casos de uso, las especificaciones suplementarias de requerimientos y diseño del sistema, garantizando que los procedimientos de pruebas sean compatibles con las necesidades de los usuarios/clientes. En la metodología los Casos de Uso dirigen todo el proceso de desarrollo, es por ello que los Casos de Uso se transforman en un activo que puede directamente conducir el proceso de pruebas. Un Caso de Prueba no es igual a un Caso de Uso. El Caso de Prueba extiende o amplía la información contenida en un Caso de Uso. Relaciones del Artefacto Casos de Prueba Rol Responsable:

Probador

Disciplina:

Pruebas

Artefacto Contenedor:

Plan de Pruebas

88

MeRinde Guía Detallada Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee Componente Operacional del Sistema

Este artefacto es una versión operacional del sistema o parte de este que cubre un subconjunto especificado de los requerimientos que el sistema final cumplirá. Este comprende uno o más elementos de la aplicación (funciones ejecutables) que son creados de otros elementos mediante un proceso de compilación y unión del código fuente. Agrupa un conjunto de Subsistemas de Implementación. Cabe destacar que cada una de las funciones y capacidades que representan una parte del sistema pueden ser probadas durante su ejecución. Relaciones del Artefacto Componente Operacional del Sistema Rol Responsable:

Desarrollador

Disciplina:

Implementación

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee Criterios de Aceptación

Este artefacto determina la precisión mínima requerida o las características específicas de funcionamiento necesarias para que los resultados obtenidos en las pruebas e inspecciones puedan garantizar la adecuación del producto a sus especificaciones. Este artefacto describe cómo el cliente evaluará los entregables del proyecto y bajo qué condiciones aceptará el producto, incluyendo los casos de pruebas del proyecto a ejecutarse.

89

MeRinde Guía Detallada

Es responsabilidad del equipo de gestión del proyecto y del cliente acordar los criterios de aceptación del producto y efectuar

las pruebas necesarias que

verifiquen dichos criterios. Los criterios de aceptación son capturados a través de: • El artefacto Términos de Referencia del Sistema • El artefacto Casos de Prueba. Relaciones del Artefacto Criterios de Aceptación Rol Responsable:

Involucrados

Disciplina:

Pruebas

Artefacto Contenedor:

Plan de Pruebas

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee Datos de Pruebas

Este artefacto define una lista de variables y sus posibles valores a introducir para la ejecución de las pruebas, así como también los resultados esperados de la ejecución para propósitos comparativos. Se pueden tomar en cuenta valores específicos o describir rangos de valores. Los Datos de Pruebas se utilizan como fuente de engaño al objeto de prueba y así encontrar errores. Cabe destacar que cada caso de prueba deberá ser ejecutado una vez por cada combinación de valores. Relaciones del Artefacto Datos de Pruebas Rol Responsable:

Probador

Disciplina:

Pruebas

Artefacto Contenedor:

Plan de Pruebas

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee

90

MeRinde Guía Detallada Documento de Arquitectura del Negocio (DAN) El DAN ayuda a conocer la realidad del negocio, ya que proporciona una visión general de los objetivos, estructura y funcionamiento del negocio.

Este

describe el qué, por qué y cómo del negocio, y contiene varias vistas que muestran aspectos claves del mismo como son: Vista del Mercado, Vista del Proceso de Negocio, Vista de la Organización, Vista Geográfica, Vista del Recurso Humano, Vista del Dominio y Vista de Comunicación. Cada una de estas vistas nos da una diferente perspectiva del negocio. Las vistas incluidas en el Documento de Arquitectura del Negocio (DAN) se describen a continuación. Vista del Mercado: Describe los mercados en el que opera el negocio, los perfiles de los clientes y las ofertas, o los productos y servicios que ofrece el negocio a los clientes en los mercados designados. Esta vista sólo se debe tomar en cuenta si se estarán tomando decisiones con respecto a la estrategia del negocio, para mostrar cómo la arquitectura del negocio es afectada o en los casos dónde la estrategia del negocio puede verse influenciada por las decisiones referidas a la arquitectura. En este sentido la realización de la Vista del Mercado es opcional. Vista de Procesos del Negocio: Esta vista que incluye los procesos claves del negocio, es un subconjunto del artefacto Modelo de Caso de Uso del Negocio. La Vista de Procesos representa los casos de uso del negocio mediante un diagrama que refleja la relación existente entre los actores del negocio y los casos de uso del negocio. Es significativo identificar la jerarquía de actores del negocio y realizar un diagrama de clases con ellos. Esta vista es obligatoria.

91

MeRinde Guía Detallada Vista de la Organización: Esta vista es inicialmente un subconjunto del Artefacto Modelo de Análisis del Negocio, incluyendo elementos que son significativos para la arquitectura del negocio. Como el Modelo de Análisis del Negocio es refinado en el artefacto Modelo de Diseño del Negocio, la vista de la organización cambia para mostrar cómo se enlazan los roles en el negocio a las personas, software y hardware. La Vista de la Organización describe a los trabajadores más importantes, entidades y eventos del negocio, su agrupación en los sistemas del negocio, y la organización de éstos en capas. También incluye las realizaciones de los casos de uso del negocio más importantes y descripciones de los modelos generales de conducta. Su realización es obligatoria. Vista Geográfica: Muestra la distribución de la estructura de la organización, funciones y recursos a través de las localizaciones físicas como las ciudades y países. Esta vista emplea un diagrama de clases donde cada locación es una clase, y también se muestra dependencias y relaciones entre ellas. Esta vista es opcional, ya que se realiza solamente si se necesita entender el efecto que tiene la distribución geográfica de las operaciones del negocio en los procesos del negocio y la estructura. Vista de Recurso Humano: Describe los perfiles de remuneración y los mecanismos de incentivo, las características y mecanismos culturales más importantes, el ambiente de competencia, aspectos referentes a educación y mecanismos de entrenamiento. Esta vista sólo se realiza si la reorganización implica cambios significativos en la forma de trabajar de las personas y las relaciones entre ellas, por lo tanto es opcional.

92

MeRinde Guía Detallada Vista del Dominio: Se refiere a los elementos más importantes de un Modelo de Análisis para la organización. Describe los principales conceptos del negocio y estructuras de la información usadas por el negocio. Es opcional, ya que sólo se realiza si la información del negocio se considera significativa y si se necesita aclarar los conceptos que son importantes para el dominio del negocio. Esta es muy útil para mejorar la comunicación y el entendimiento entre los diferentes departamentos, proyectos o externos. Vista de Comunicación: Describe las vías de comunicación dentro del negocio. Es opcional y por la tanto sólo se realiza si se quiere entender los cambios internos y externos en la comunicación. Relaciones del Artefacto Documento de Arquitectura del Negocio (DAN) Rol Responsable:

Involucrados

Disciplina:

Modelado del Negocio

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee

Documento de Arquitectura del Software (DAS) Es una especificación de las ideas principales del diseño. El DAS proporciona una descripción entendible de la arquitectura del sistema software y sirve como medio de comunicación entre el arquitecto de software y otros miembros de equipo del proyecto con respecto a las decisiones arquitectónicamente significativas que se han tomado en el proyecto. Contiene varias vistas que muestran aspectos distintos del sistema como son: Vista de Casos de Uso, Vista Lógica, Vista de Implementación, Vista del Proceso, Vista de Implantación y Vista de Datos.

93

MeRinde Guía Detallada Las vistas involucradas en el Documento de Arquitectura del Software (DAS) se detallan a continuación. Vista de Casos de Uso: Esta vista muestra la funcionalidad del sistema como es percibida desde el exterior. Así como también describe un conjunto de escenarios y casos de uso que tienen una cobertura arquitectónicamente significativa o que ilustran un punto específico de la arquitectura. Es un subconjunto del Modelo de Casos de Uso y además su realización es obligatoria. Vista Lógica: Describe el diseño más importante de las clases y su organización en paquetes y subsistemas, y la organización de éstos en capas. También contiene algunas realizaciones de casos de uso. Esta muestra cómo la funcionalidad es diseñada en el interior del sistema, en términos de la estructura estática y comportamiento dinámico del sistema. Es un subconjunto del Modelo de Casos de Uso y su realización es obligatoria. Vista de Implementación: Esta vista muestra la organización del código y el código actual de ejecución. Contiene una visión general del Modelo de Implementación y su organización en términos de módulos en paquetes y capas. También se describe la asignación de paquetes y clases de la Vista Lógica a los paquetes y módulos de la Vista de Implementación. Es un subconjunto del Modelo de Implementación. Esta vista es opcional, ya que sólo se realiza en los casos donde la implementación no se conduce estrictamente por el diseño. Si el empaquetado de los modelos de diseño y de implementación son idénticos, esta vista puede ser omitida. Vista de Procesos: En esta vista se describe las tareas, sus interacciones y configuraciones, y la asignación de objetos del diseño y clases a las tareas. Muestra los elementos relacionados con el desempeño incluyendo escalabilidad, concurrencia y tiempo base de desempeño. Es un subconjunto del Modelo de Diseño y se usa sólo 94

MeRinde Guía Detallada si el sistema tiene un grado significante de concurrencia, por lo tanto es una vista opcional. Vista

de

Implantación:

Describe

varios

nodos

físicos

para

las

configuraciones más típicas de las plataformas y la asignación de las tareas de la Vista del Proceso a los nodos físicos.

Es un subconjunto del Modelo de

Implantación. Esta vista se realiza sólo si el sistema es distribuido a través de más de un nodo, por lo tanto es opcional. Vista de Datos: Esta vista especifica arquitectónicamente los elementos constantes en el Modelo de Datos. Describe una apreciación global del modelo de los datos y su organización por lo que se refiere a las tablas, vistas y almacenamiento de los procedimientos que proporcionan la persistencia al sistema. También describe la cartografía de clases constantes de la Vista Lógica a la estructura de los datos de la base de datos. Esta vista es opcional, ya que sólo se realiza si la persistencia es un aspecto significante del sistema y el traslado del Modelo de Diseño al Modelo de Datos no se hace automáticamente por el mecanismo de persistencia. Relaciones del Artefacto Documento de Arquitectura del Software (DAS) Rol Responsable:

Arquitecto de Software

Disciplina:

Análisis y Diseño

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee

Elemento de Implementación El elemento de implementación es un artefacto que representa el más bajo nivel de composición de un componente de software, es decir, un conjunto de 95

MeRinde Guía Detallada elementos de implementación son los que conforman a un componente del sistema. Este artefacto puede ser un código fuente, un código binario, un archivo, un ejecutable, entre otros. Relaciones del Artefacto Elemento de Implementación Rol Responsable:

Desarrollador

Disciplina:

Implementación

Artefacto Contenedor:

Modelo de Implementación

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Elemento de Soporte de Prueba Este artefacto contribuye a facilitar las pruebas que se van a ejecutar al sistema, tanto manuales como automáticas. Es un elemento que realiza una función específica para una determinada prueba que el software soporta. Estos artefactos comúnmente son creados ó modificados en paralelo con los elementos ó componentes que están siendo implementados. Dos ejemplos de esta clase de artefacto son: • Cuando se implementa una determinada interfaz ó salida para informar cuando se produce una acción específica en el sistema. • Cuando se simula la función de un componente determinado que aun no ha sido implementado a fin de poder probar otras funcionalidades del sistema. Relaciones del Artefacto Elemento de Soporte de Prueba Rol Responsable:

Desarrollador

Disciplina:

Implementación

Artefacto Contenedor:

Modelo de Implementación

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee 96

MeRinde Guía Detallada El Sistema Este artefacto es el producto final, es decir, el sistema ya funcionando que puede ser instalado y ser utilizado por el cliente. Un Sistema se diferencia de una unidad de implantación, ya que el sistema puede contener varias unidades de implantación. Cabe destacar que dichas unidades de implantación que reúne el sistema pueden ser exportadas a una unidad de almacenamiento. Relaciones del Artefacto Sistema Rol Responsable:

Involucrados

Disciplina:

Implantación

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

Plantilla:

• • •

Lista de Materiales Artefactos de Instalación Unidad de Implantación

No posee

Entidad del Negocio Este artefacto representa una pieza de información significativa que es manipulada por los actores y trabajadores del negocio. Se refiere al estado de la información que pasará entre cada capa como un conjunto de datos que la identifican una entidad. Las entidades del negocio de una aplicación representa entidades reales y además suelen ser sustantivos, como por ejemplo: Cliente, Nómina, Factura, Depósito, etc. Asimismo, las entidades de negocio son la base para compartir documentos entre los trabajadores del negocio y estas pueden ser utilizadas en diversas Realizaciones de los Casos de Uso del Negocio.

97

MeRinde Guía Detallada Relaciones del Artefacto Entidad del Negocio Rol Responsable:

Involucrados

Disciplina:

Modelado del Negocio

Artefactos Contenedores:

•

Modelo de Análisis del Negocio

•

Modelo de Diseño del Negocio

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee Escenarios por Casos de Uso

Este artefacto se representa a través de una matriz en la cual se indica los escenarios que contiene un caso de uso. Esta matriz contiene la identificación del escenario, el flujo básico y los flujos alternos del escenario. Cabe destacar que cada flujo o combinación de ellos es un posible escenario que puede ser ejecutado y probado. Relaciones del Artefacto Escenarios por Casos de Uso Rol Responsable:

Probador

Disciplina:

Pruebas

Artefacto Contenedor:

Plan de Pruebas

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee Especificación de Migración de Datos

Este artefacto debe contener el perfil de los datos que van ser migrados, así mismo se debe incluir la relación entre la fuente de los datos con la base de datos a la cual serán migrados.

98

MeRinde Guía Detallada Relaciones del Artefacto Especificación de Migración de Datos Rol Responsable:

Arquitecto de Software

Disciplina:

Análisis y Diseño

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Especificación de Requerimientos del Software (ERS) El objetivo de este artefacto es documentar todos los requerimientos del sistema, este describe las funciones del sistema, los requerimientos no funcionales, características del diseño, y otros elementos

necesarios para proporcionar una

descripción completa y comprensiva de los requerimientos para el software a desarrollar. Los requerimientos pueden ser levantados con diferentes herramientas, también se pueden encontrar dispersos en varios artefactos y herramientas. Es por ello, que esta metodología propone capturar todos los requerimientos para el ERS en un solo artefacto, el cual está conformado por dos (2) artefactos que describen los requerimientos que son: Modelo de Casos de Uso y Especificaciones Suplementarias. El artefacto ERS controla la evolución del sistema durante toda el ciclo de desarrollo del proyecto, cuando las nuevas características son añadidas o modificadas al artefacto de visión, son aclarados dentro del artefacto ERS. Las decisiones hechas escribiendo el ERS están basadas en información de los documentos de la propuesta del proyecto y en

requerimientos del usuario. El

conjunto de requerimientos especificados en el ERS deben ser satisfechos en el diseño del sistema. Cualquier requerimiento funcional o no funcional que no sea identificado en el ERS, no debe aparecer en el producto final. 99

MeRinde Guía Detallada Relaciones del Artefacto Especificación de Requerimientos del Software (ERS) Rol Responsable:

Analista de Producto

Disciplina:

Requerimientos

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

Plantilla:

•

Modelo de Caso de Uso

•

Especificaciones Suplementarias

Si posee

Especificaciones Suplementarias Este artefacto captura los requerimientos del sistema que no fueron recogidos en el Modelo de Casos de Uso. Contiene tanto requerimientos funcionales como no funcionales del sistema. Los requerimientos que deben considerarse para este artefacto son los siguientes: usabilidad, confiabilidad, desempeño, mantenibilidad, seguridad, restricciones de diseño, requerimientos de documentación en línea y de sistemas de ayuda, componentes comprados, interfaces, requerimientos de licenciamiento, y aspectos legales, derecho de autor y otros avisos. Relaciones del Artefacto Especificaciones Suplementarias Rol Responsable:

Analista de Producto

Disciplina:

Requerimientos

Artefacto Contenedor:

Especificación de Requerimientos del Software (ERS)

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee Evaluación de la Organización Objetivo (EOO)

Este artefacto describe la situación actual en que se encuentra la organización objetivo, es decir, la organización en la que el sistema será implantado. La 100

MeRinde Guía Detallada descripción está en términos de procesos actuales, herramientas, competencias entre personas, actitudes de las personas, clientes, competidores, tendencias técnicas, problemas y áreas de mejora. El EOO también es usado para crear motivación y comprensión entre las personas en la organización objetivo que son directamente o indirectamente afectadas, así como también explicar al involucrado por qué existe la necesidad de cambiar los procesos del negocio, y además proporcionar la entrada al Marco de Desarrollo y al Plan de Iteración. Relaciones del Artefacto Evaluación de la Organización Objetivo (EOO) Rol Responsable:

Involucrados

Disciplina:

Modelado del Negocio

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee

Glosario del Sistema Es una lista que contiene las definiciones de los términos a hacer utilizados durante la realización del proyecto, que deben ser comprendidos por los participantes de tal manera que haya una buena comunicación y evitar interpretaciones dispares o ambiguas de los términos del dominio del problema. Documentar las definiciones de términos y acrónimos ayuda a otros artefactos a ser más concisos y precisos. En algunos proyectos donde la planeación del negocio y del dominio no se realiza, el Glosario es el artefacto principal para capturar la información sobre el dominio de negocio del proyecto.

101

MeRinde Guía Detallada Relaciones del Artefacto Glosario del Sistema Rol Responsable:

Analista de Producto

Disciplina:

Requerimientos

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee

Herramientas Este artefacto corresponde con las herramientas necesarias para apoyar el esfuerzo de desarrollo del software. Cabe destacar que un proceso de Ingeniería de software requiere de las herramientas para apoyar todas las actividades en el ciclo de vida de un sistema. Relaciones del Artefacto Herramientas Rol Responsable:

Involucrados

Disciplina:

Gestión del Ambiente

Artefacto Contenedor:

Infraestructura de Desarrollo

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Infraestructura de Desarrollo Este artefacto incluye el software y hardware, tal como computadoras y sistemas operativos, en los cuales funcionan las herramientas. La Infraestructura de Desarrollo también incluye el hardware y el software que son usados para interconectar las computadoras y a los usuarios. Varias son las infraestructuras de desarrollo requeridas durante el ciclo de vida de elaboración del producto, una infraestructura estándar debe existir para permitir que ocurra el esfuerzo de

102

MeRinde Guía Detallada desarrollo, otra infraestructura se puede configurar para las pruebas realizadas dentro de la organización y otra se puede requerir para la puesta en marcha del sistema en las instalaciones del cliente. Relaciones del Artefacto Infraestructura de Desarrollo Rol Responsable:

Involucrados

Disciplina:

Gestión del Ambiente

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

Herramientas

Plantilla:

No posee

Licitación de Personal Este artefacto es una orden generada si se desea contratar personal externo a la organización para el desarrollo del proyecto especificado en el artefacto Términos de Referencia del Sistema. El artefacto puede ser una oferta que consista en realizar un concurso público para organizaciones de diversa índole de base tecnológica como cooperativas y empresas interesadas en participar en el desarrollo del sistema. Relaciones del Artefacto Licitación de Personal Rol Responsable:

Líder del Proyecto

Disciplina:

Gestión del Proyecto

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

103

MeRinde Guía Detallada Lineamientos del Proyecto En este artefacto se detallan las prescripciones necesarias para ejecutar determinadas tareas durante el proyecto, además es donde se captura cualquier decisión que involucre la modificación o adaptación de algún artefacto y debe ser empleado por todos los miembros del proyecto para la ejecución de las actividades que le han sido asignadas. Generalmente los lineamientos para la elaboración de los proyectos son controlados y establecidos por un grupo de personas internos a la organización para la cual se va a desarrollar el producto, y deben estar contenidos dentro de determinados repositorios de la misma. Relaciones del Artefacto Lineamientos del Proyecto Rol Responsable:

Involucrados

Disciplina:

Gestión del Ambiente

Artefacto Contenedor:

Marco de Desarrollo

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Lista de Ideas de las Pruebas Este artefacto contiene las ideas que potencialmente serán las pruebas más útiles a realizar. La Lista de Ideas de las Pruebas ayuda a pensar sobre las pruebas desde etapas muy tempranas y sobre las primeras pruebas a ejecutarse. Es particularmente útil cuando los artefactos están inasequibles o incompletos. Pueden estar contenidas dentro del Plan de Pruebas en la sección de Ideas Iníciales y otras Fuentes de referencia.

104

MeRinde Guía Detallada Relaciones del Artefacto Lista de Ideas de las Pruebas Rol Responsable:

Probador

Disciplina:

Pruebas

Artefacto Contenedor:

Plan de Pruebas

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee

Lista de Materiales Este artefacto lista los componentes de una versión dada de un producto y define donde los componentes físicos pueden ser encontrados. Además, describe los cambios realizados en la versión y se refiere a la forma en que el producto puede ser instalado. Relaciones del Artefacto Lista de Materiales Rol Responsable:

Líder del Proyecto

Disciplina:

Implantación

Artefacto Contenedor:

El Sistema

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Manual de Instalación El manual de instalación es un artefacto que refleja los lineamientos que hay que seguir para instalar el sistema. Contiene información sobre la infraestructura de instalación e instrucciones para la instalación y actualización del software.

105

MeRinde Guía Detallada Relaciones del Artefacto Manual de Instalación Rol Responsable:

Involucrados

Disciplina:

Implantación

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee Manual de Usuario

Este artefacto provee una ayuda a las personas que manipularán directamente el producto, acerca del uso que le debe dar al sistema. Dicho artefacto debe ser discutido y aprobado por el cliente. Elaborar el manual de usuario durante las primeras iteraciones del proyecto permitirá al equipo de probadores conocer el sistema antes de que comiencen las pruebas, adicionalmente provee los mecanismos básicos para elaborar los planes de pruebas y los casos de pruebas, y permite la elaboración de sistemas automatizados para las pruebas. Según el tipo de sistema se define el comienzo del desarrollo del Manual de Usuario. Sistemas con interfaces complejas o con mucha interacción requerirán versiones tempranas del manual de usuario así como de prototipos de interfaces. Sistemas con poca interacción probablemente no requieran que la documentación del usuario se elabore muy temprano. Relaciones del Artefacto Manual de Usuario Rol Responsable:

Involucrados

Disciplina:

Implantación

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee 106

MeRinde Guía Detallada Mapa de Navegación Este artefacto expresa la estructura de los elementos de la interfaz de usuario del sistema, junto a los caminos de navegación principales. Este permite al usuario una adecuada navegación en el sistema y sobre todo saber en qué punto del sistema se encuentra y hacia donde puede ir. Sin un Mapa de Navegación no se podría aprovechar al máximo un sistema. Cabe destacar que existirá solamente uno de estos artefactos en el sistema. Relaciones del Artefacto Mapa de Navegación Rol Responsable:

Arquitecto de Software

Disciplina:

Análisis y Diseño

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Marco de Desarrollo El Marco de Desarrollo no es más que una configuración para amoldarse a las necesidades del sistema. Su objetivo fundamental consiste en proveer ayuda y soporte a los miembros del proyecto de desarrollo de software. Este artefacto establece cómo cada objetivo específico propuesto debe irse cumpliendo, y cuáles van a ser las normativas para el proyecto. Este artefacto también es conocido como el proceso específico del proyecto, y no es más que un artefacto que permite ajustar la configuración de la metodología para el desarrollo de software a las necesidades del proyecto que se quiera desarrollar. Es un artefacto compuesto que contiene: el caso de desarrollo, plantillas y normativas para el proyecto.

107

MeRinde Guía Detallada Como se ha especificado con anterioridad, conforme al proyecto se deben definir cuáles son los elementos a emplear de la presente metodología, este artefacto fue diseñado precisamente con la idea de ofrecer los mecanismos para poder organizar los aspectos metodológicos a considerar para el ciclo de vida del proceso de desarrollo del sistema. Relaciones del Artefacto Marco de Desarrollo Rol Responsable:

Involucrados

Disciplina:

Gestión del Ambiente

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

Lineamientos del Proyecto

Plantilla:

Si posee

Material de Adiestramiento El propósito del Material de Adiestramiento, dependiendo de los requerimientos del proyecto, es enseñar a los usuarios cómo utilizar, operar o mantener el producto. Este material se piensa para el uso en cursos de aprendizaje. Relaciones del Artefacto Material de Adiestramiento Rol Responsable:

Involucrados

Disciplina:

Implantación

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee Mecanismo de Retroalimentación

Este artefacto provee un mecanismo para captar los comentarios de los clientes al probar el producto beta, tiene como fin de que los usuarios hagan pruebas al sistema sobre el conjunto de características disponibles y en lo posible, 108

MeRinde Guía Detallada retroalimentar a sus desarrolladores con el descubrimiento de fallos y haciendo sugerencias en cuanto a la funcionalidad, etc. Relaciones del Artefacto Mecanismo de Retroalimentación Rol Responsable:

Involucrados

Disciplina:

Implantación

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Modelo de Análisis Este modelo es usado para representar la estructura global del sistema, describe la realización de casos de uso, sirve como una abstracción del Modelo de Diseño y se centra en los requerimientos no funcionales. Este modelo de análisis no es un diagrama final que describe todos los posibles conceptos y sus relaciones, es un primer intento por definir los conceptos claves que describen el sistema. Este artefacto es opcional, pero también tiene a su vez la propiedad de ser temporal en el caso en que se planea su desarrollo. Su utilidad radica en que permite una apreciación global conceptual del sistema. El Modelo de Análisis puede contener: las clases y paquetes de análisis, las realizaciones de los casos de uso, las relaciones y los diagramas. Es opcional detallar aquí las realizaciones de los casos de uso ya que estas pueden estar en el modelo de diseño donde se recomienda que se encuentre. A diferencia del Modelo de Casos de Uso que captura la funcionalidad del sistema, el Modelo de Análisis da forma a la arquitectura para soportar las funcionalidades que en el anterior modelo se expresa. 109

MeRinde Guía Detallada Para representar los diagramas del Modelo de Análisis se pueden emplear diferentes diagramas de UML tales como: • Diagramas de Clase. • Diagramas de Secuencia Relaciones del Artefacto Modelo de Análisis Rol Responsable:

Arquitecto de Software

Disciplina:

Análisis y Diseño

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Modelo de Análisis del Negocio Este modelo es interno al negocio, describe la realización de los casos de uso del negocio, para lo cual detalla cómo cada caso de uso de negocio es llevado a cabo por un grupo de trabajadores u sistemas que emplean entidades del negocio y unidades de trabajo recíprocamente. A diferencia del Modelo de Casos de Uso del Negocio el cual describe qué pasa entre el negocio y los actores de negocio, el Modelo de Análisis define los trabajadores internos de negocio y la información que ellos emplean (entidades de negocio). Describe su organización estructural en unidades independientes (sistema de negocio) y precisa cómo ellos interactúan para ejecutar el comportamiento señalado en los casos de uso de negocio. El Modelo de Análisis del Negocio puede contener: los diagramas, trabajadores, sistemas, entidades, reglas, las relaciones, colaboraciones, entre otros elementos del negocio.

110

MeRinde Guía Detallada Para representar los diagramas del Modelo de Análisis del Negocio se pueden emplear diferentes diagramas de UML tales como: • Diagramas de Colaboración. • Diagramas de Secuencia. • Diagrama de Análisis del Negocio. • Diagramas de Actividad. • Diagramas de Estado. Relaciones del Artefacto Modelo de Análisis del Negocio Rol Responsable:

Involucrados

Disciplina:

Modelado del Negocio

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

Plantilla:

• •

Entidad del Negocio Reglas del Negocio

•

Trabajador del Negocio

No posee

Modelo de Casos de Uso Este artefacto se basa en la descripción de elementos o usuarios externos al sistema (actores) y de la funcionalidad del sistema (casos de uso). Un Modelo de Casos de Uso describe los requerimientos funcionales de un actor (usuario, sistema, dispositivo, etc.) en términos de las interacciones que éste ejecuta con el sistema. El modelado de casos de uso es una técnica efectiva y a la vez simple para modelar los requerimientos del sistema desde la perspectiva del usuario. Presenta el sistema desde la perspectiva de su uso y esquematiza como proporcionará valor a sus usuarios. El modelo de casos de uso sirve como acuerdo entre clientes y desarrolladores para limitar las funciones con que dispondrá el sistema luego de ser implementado,

111

MeRinde Guía Detallada además proporciona la entrada fundamental para el análisis, el diseño, la implementación y las pruebas. Cabe recordar que MeRinde está dirigido por casos de uso, de aquí la importancia de este modelo. Este modelo está formado por los diagramas de casos de uso y las narrativas de los casos de uso. Para representar los diagramas del Modelo de Casos de Uso se puede emplear el diagrama de UML de Caso de Uso. Relaciones del Artefacto Modelo de Casos de Uso Rol Responsable:

Analista de Producto

Disciplina:

Requerimientos

Artefacto Contenedor:

Especificación de Requerimientos del Software (ERS)

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Modelo de Casos de Uso del Negocio Este modelo permite visualizar el alcance de la organización, representando lo que abarca y cuáles son sus límites. Así mismo, modela las actividades y procesos qué ejecuta una organización, señala gráficamente las funciones y metas que persigue el negocio, y también permite identificar cuáles son los entregables y roles dentro de la organización. Muestra los casos de uso del negocio, trabajadores del negocio, actores del negocio y las interacciones entre ellos relacionadas con los procesos del negocio que se encuentran dentro de la organización y dentro del alcance del sistema que se está planeando realizar. Este servirá para proveer los fundamentos para el artefacto Modelo de Casos de Uso.

112

MeRinde Guía Detallada Para representar los diagramas del Modelo de Casos de Uso se puede emplear el diagrama de UML de estereotipo llamado . Relaciones del Artefacto Modelo de Casos de Uso del Negocio Rol Responsable:

Involucrados

Disciplina:

Modelado del Negocio

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Modelo de Datos Describe la representación física y lógica de los datos constantes utilizados por la aplicación. Se utilizará siempre que se necesiten manejar datos constantes. Usualmente describirá los diferentes elementos componentes de la estructura de una base de datos relacional. El Modelo de Datos debe contener las interacciones entre los componentes en los casos en que el sistema emplee un Sistema Administrador de Bases de Datos Relacional. El Modelo de Datos se emplea concretamente cuando la estructura de los datos constante no puede ser derivada automáticamente ni mecánicamente de la estructura persistente de clases en el Modelo de Diseño. Se usa para definir la relación entre las constantes clases del diseño y las estructuras de datos, y para definir las mismas estructuras de datos constantes.

113

MeRinde Guía Detallada Relaciones del Artefacto Modelo de Modelo de Datos Rol Responsable:

Arquitecto de Software

Disciplina:

Análisis y Diseño

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Modelo de Diseño Es una abstracción del Modelo de Implementación y su código fuente, el cual fundamentalmente se emplea para representar y documentar su diseño. Es usado como entrada esencial en las actividades relacionadas a implementación. Representa a los casos de uso en el dominio de la solución. El Modelo de Diseño puede contener: los diagramas, las clases, paquetes, subsistemas, capsulas, protocolos, interfaces, relaciones, colaboraciones, atributos, las realizaciones de los casos de uso, entre otros que se puedan considerar para el sistema en desarrollo. Para representar los diagramas del Modelo de Diseño se pueden emplear diferentes diagramas de UML tales como: • Diagramas de Clase. • Diagramas de Colaboración. • Diagramas de Estado. • Diagramas de Paquetes. • Diagramas de Secuencia.

114

MeRinde Guía Detallada Relaciones del Artefacto Modelo de Diseño Rol Responsable:

Arquitecto de Software

Disciplina:

Análisis y Diseño

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

Plantilla:



Capsula



Realizaciones de los Casos de Uso

No posee

Modelo de Diseño del Negocio Este artefacto es un refinamiento del Modelo de Análisis del Negocio, por lo que describe en mayor detalle el cómo el negocio trabaja internamente para llevar a cabo las funciones que ejecuta. Este artefacto se recomienda emplear cuando con la implantación del sistema que se tiene estimado existirán cambios del negocio en sus procesos, en las responsabilidades de los roles o en la estructura de la organización. El Modelo de Diseño del Negocio puede contener: los diagramas, trabajadores, sistemas, entidades, reglas, las realizaciones de los casos de uso, las relaciones, colaboraciones, entre otros elementos del negocio. Para representar los diagramas del Modelo de Diseño del Negocio se pueden emplear diferentes diagramas de UML tales como: • Diagramas de Colaboración. • Diagramas de Secuencia. • Diagrama de Análisis del Negocio. • Diagramas de Actividad. • Diagramas de Estado. 115

MeRinde Guía Detallada Relaciones del Artefacto Modelo de Diseño del Negocio Rol Responsable:

Involucrados

Disciplina:

Modelado del Negocio

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

Plantilla:

• •

Entidad del Negocio Realizaciones de los Casos de Uso del Negocio

•

Trabajador del Negocio

No posee

Modelo de Implantación Señala la configuración de nodos de procesamiento existentes en tiempo de ejecución y cada uno de los componentes y objetos que residen en ellos, lo cual representa la implantación de los componentes del sistema en desarrollo sobre los dispositivos físicos que se dispondrán para la ejecución del sistema. Así mismo, señala como se llevará a cabo la comunicación entre dichos nodos. Este modelo es opcional para sistemas con un solo procesador ó para sistemas simples que tienen poca o ninguna distribución de procesos. El Modelo de Implantación puede contener uno o varios diagramas, nodos, dispositivos y conectores. Para representar los diagramas del Modelo de Implantación se puede emplear el diagrama de UML de Implantación (Despliegue).

116

MeRinde Guía Detallada Relaciones del Artefacto Modelo de Implantación Rol Responsable:

Arquitecto de Software

Disciplina:

Análisis y Diseño

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Modelo de Implantación del Negocio El objetivo de este artefacto es relacionar los elementos lógicos que se han detallado en los modelos de Casos de Uso, Análisis y Diseño del Negocio con los elementos físicos que tienen asociados, lo cual podría ser representado mediante localizaciones geográficas y sus características, canales de comunicación empleados y sus propiedades, entre otros recursos físicos. Para representar los diagramas del Modelo de Implantación del Negocio se puede emplear el diagrama de UML de estereotipo llamado . Relaciones del Artefacto Modelo de Implantación del Negocio Rol Responsable:

Involucrados

Disciplina:

Modelado del Negocio

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

117

MeRinde Guía Detallada Modelo de Implementación El Modelo de Implementación es comprendido por un conjunto de componentes y subsistemas que constituyen la composición física de la implementación del sistema. Entre los componentes podemos encontrar datos, archivos, ejecutables, código fuente y los directorios. Fundamentalmente, se describe la relación que existe desde los paquetes y clases del modelo de diseño a subsistemas y componentes físicos. Este

artefacto

describe

cómo

se

implementan

los

componentes,

congregándolos en subsistemas organizados en capas y jerarquías, y señala las dependencias entre éstos. Para representar los diagramas del Modelo de Implementación se puede emplear el diagrama de UML de Componentes. Relaciones del Artefacto Modelo de Implementación Rol Responsable:

Arquitecto de Software

Disciplina:

Implementación

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

Plantilla:

• •

Elemento de Implementación Subsistema de Implementación

•

Elemento de Soporte de Prueba

No posee

Modelo de Servicio Este artefacto se emplea para concebir y documentar el diseño de los servicios que estarán presentes en el sistema a desarrollar. Adicionalmente, es la base de los

118

MeRinde Guía Detallada elementos de una Arquitectura Orientada a Servicios (SOA), la cual está constituida por un grupo de servicios interconectados cuyo objetivo es automatizar uno o varios procesos de negocio. El Modelo de Servicio puede contener uno o varios diagramas, los servicios, especificaciones, proveedores, particiones, mensajes, colaboraciones, y todas las relaciones existentes entre ellos. Para representar los diagramas del Modelo de Servicio se puede emplear el diagrama de UML de estereotipo . Relaciones del Artefacto Modelo de Servicio Rol Responsable:

Arquitecto de Software

Disciplina:

Análisis y Diseño

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Notas de Lanzamiento Este artefacto contiene las notas de entrega para la versión x.y.z del producto. Aquí se detalla la entrega y se provee información de última hora y otros datos que complementan la documentación principal. Incluye la descripción de las versiones, las actualizaciones, los cambios recientes, problemas y soluciones. Las notas de lanzamiento son consideradas muy útiles, incluso para aplicarlas en las versiones internas desarrolladas del sistema. El formato de estas puede ser simple, casual o informal. Particularmente los probadores y el personal técnico encargado de redactar el material de soporte a los usuarios encontrarán las notas de lanzamiento útiles para conducir sus actividades. 119

MeRinde Guía Detallada Relaciones del Artefacto Notas de Lanzamiento Rol Responsable:

Líder del Proyecto

Disciplina:

Implantación

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee

Oferta de Servicio del Personal Este artefacto describe la oferta de servicio del personal de desarrollo para su selección y contratación. Este incluye el propósito, las actividades, tiempo y forma de pago para un servicio en particular. Relaciones del Artefacto Oferta de Servicio del Personal Rol Responsable:

Líder del Proyecto

Disciplina:

Gestión del Proyecto

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Orden de Trabajo Este artefacto es el mecanismo por medio del cual el Líder del Proyecto comunica los planes a los miembros del equipo del proyecto de lo que se hará y cuándo dentro de las iteraciones. Esta orden puede ser desde ejecutar una actividad ó un conjunto, bajo una planificación definida y con unos determinados entregables, esfuerzo, alcance y restricciones de recursos. Su representación depende directamente de los mecanismos internos de la organización para la gestión de personal.

120

MeRinde Guía Detallada Relaciones del Artefacto Orden de Trabajo Rol Responsable:

Líder del Proyecto

Disciplina:

Gestión del Proyecto

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee Plan de Adiestramiento

Muestra el plan detallado de adiestramiento. El propósito de este plan es que las personas que vayan a utilizar el sistema, se capaciten para su utilización evitando que el mismo sea mal utilizado. Dicho artefacto debe ser discutido y aprobado por el cliente. Este artefacto está compuesto por secciones para indicar el programa de entrenamiento o cursos que serán impartidos a los usuarios finales para enseñarles el uso, operación y mantenimiento del sistema. Relaciones del Artefacto Plan de Adiestramiento Rol Responsable:

Involucrados

Disciplina:

Implantación

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee Plan de Gestión de Configuración

Este documento describe todas las actividades de Gestión de Configuración y Cambios que serán realizadas durante todo el ciclo de vida del proyecto. Brinda planificaciones detalladas de las actividades, responsabilidades asignadas, recursos necesarios que incluyen personal, herramientas y equipamiento. 121

MeRinde Guía Detallada El Plan de Gestión de Configuración contiene información que puede ser cubierta a una mayor o menor magnitud por otros planes. Los enfoques siguientes pueden ser usados para manejar esta potencial coincidencia: • Haga referencias al contenido relacionado que se encuentre en otro plan. • Provea la visión general en otro plan, suministre los detalles más significativos en este plan y haga referencias necesarias desde los otros planes hacia este plan. • Asegúrese que las secciones de este artefacto cubran solamente las áreas que no han sido cubiertas anteriormente en otro lugar. Relaciones del Artefacto Plan de Gestión de Configuración Rol Responsable:

Líder del Proyecto

Disciplina:

Gestión de Configuración y Cambios

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Plan de Gestión de Riesgos Artefacto en el cual se describe los posibles riesgos de recursos, técnicos, o del negocio implicados en el proyecto, y formula un plan para abordar los posibles riesgos, con medidas de mitigación y correctivas para afrontar cada uno de ellos. Sirve de punto principal para la programar las actividades que deben realizarse y con base en este documento se deben plantear las iteraciones a ser realizadas. Un Plan de Gestión del Riesgo debe ser documentado a comienzos del proyecto, durante la fase de inicio. El plan es emprendido ante la fase de elaboración para asegurar que ninguno los riesgos identificados sean direccionados durante la misma fase de elaboración. Apenas el plan haya sido documentado, el proceso de

122

MeRinde Guía Detallada prevención de riesgos estará ocupado para monitorear y controlar la probabilidad y el impacto de los riesgos sobre el proyecto. Relaciones del Artefacto Plan de Gestión de Riesgos Rol Responsable:

Líder del Proyecto

Disciplina:

Gestión del Proyecto

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee

Plan de Implantación El objetivo principal de este artefacto es asegurar que el sistema llegue satisfactoriamente al conjunto de usuarios para el cual fue destinado. Este artefacto debe definir un conjunto de tareas que defina una transición sencilla para el cliente, para ello se debe minimizar el impacto que la implantación del sistema pueda llegar a causar en el personal del cliente, los sistemas de producción existentes y en todas las rutinas del negocio. Este artefacto describe el conjunto de tareas necesarias para poder poner en funcionamiento el sistema

en las instalaciones de los usuarios. Las actividades

descritas en este documento abarcan temas referentes a la instalación del nuevo sistema, instrucciones específicas sobre la sustitución de antiguos sistemas, compatibilidad del sistema, y estrategias de migración y adaptación al nuevo sistema. Adicionalmente este artefacto describe en detalle las actividades correspondientes a la entrega del producto, el cronograma de actividades, personal responsable, los recursos y fuentes necesarias para el funcionamiento del nuevo sistema, plan de adiestramiento, notas de seguridad, de procedimientos operacionales específicos, entre otros.

123

MeRinde Guía Detallada Relaciones del Artefacto Plan de Implantación Rol Responsable:

Líder del Proyecto

Disciplina:

Implantación

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee Plan de Integración

Este documento muestra un plan detallado de la integración dentro de una iteración. El propósito de este plan es definir el orden en que los componentes del sistema deben llevarse acabo, los resultados al integrar el sistema y cómo serán evaluados. Es recomendando ajustar el plan de integración confirme a la magnitud del proyecto, si el proyecto es grande debe realizar una serie de estos documento para cada integración de componentes, así mismo si el módulo del sistema a integrar es crítico se recomienda que para esta integración se realice un plan individual. Relaciones del Artefacto Plan de Integración Rol Responsable:

Desarrollador

Disciplina:

Implementación

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee Plan de Iteración

El objetivo de este plan es definir detalladamente para cada una de las iteraciones a realizarse un conjunto de tareas, actividades y recursos, por tal motivo existirá para cada iteración del ciclo de vida del proyecto un artefacto de este tipo. 124

MeRinde Guía Detallada Para cada iteración existe una serie de objetivos los cuales son usados como referencia de evaluación para determinar diferentes aspectos, como grado de terminación de una determinada función, rendimiento, niveles de calidad, etc. Para cada plan de iteración es necesario detallar la programación estimada para la iteración, los recursos a emplear, los casos de uso y escenarios que van ser tomados en cuenta y finamente se deben establecer los criterios de evaluación que se van

a tener para la iteración. Es recomendable para las iteraciones emplear

herramientas para la planeación de proyectos con el fin de hacer mas fácil y organizada esta tarea, de ser empleada cualquier herramienta sus resultados debe ser reflejados en el plan de iteración. Para poder definir una iteración es necesario tomar en cuenta: • La planificación del proyecto. • El estado actual en el que se encuentra el proyecto (proyecto dentro de los tiempos estipulados, proyecto retrasado con respecto al tiempo estipulado, un gran número de problemas encontrados, etc. • Los elementos a ser implementados. • La lista de casos de uso y de escenarios que deben ser cumplidos al final de la iteración. • La lista de los cambios que deben ser incorporados (corrección de errores, cambios de requerimientos.) • Los riegos que se pueden correr en la iteración. Relaciones del Artefacto Plan de Iteración Rol Responsable:

Líder del Proyecto

Disciplina:

Gestión del Proyecto

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee

125

MeRinde Guía Detallada Plan de Pruebas Es la colección formada por los casos de prueba y procedimientos de prueba. Este artefacto incluye el propósito de las pruebas, qué elemento se va a probar, las herramientas a utilizar y con qué recursos, así como el documento que va hacer entregado. Al tener el resultado de las pruebas se puede comparar lo obtenido con lo esperado. En este artefacto también se reflejan las características

de hardware y

software que serán empleados para realizar el conjunto de las pruebas al sistema. Relaciones del Artefacto Plan de Pruebas Rol Responsable:

Involucrados

Disciplina:

Pruebas

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

Plantilla:

• • • • •

Casos de Prueba Criterios de Aceptación Datos de Pruebas Escenarios por Casos de Uso Lista de Ideas de Pruebas

•

Resumen del Ciclo de Prueba

Si posee Planificación del Proyecto

Este documento está compuesto por toda la información necesaria para llevar a cabo la dirección del proyecto. Es utilizado por la dirección del proyecto para dirigir las actividades a realizar durante el proceso de desarrollo del software, este comprende un conjunto de artefactos que son desarrollados durante la fase de inicio y que son utilizados durante todo el ciclo de vida del proyecto (gestión de riesgos, aseguramiento de calidad, resolución de problemas, entre otros).

126

MeRinde Guía Detallada Relaciones del Artefacto Planificación del Proyecto Rol Responsable:

Líder del Proyecto

Disciplina:

Gestión del Proyecto

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee

Plantillas para el Proyecto Comprende el conjunto de plantillas que ayudarán a los responsables del proyecto a elaborar los artefactos considerados para el desarrollo del sistema. Relaciones del Artefacto Plantillas para el Proyecto Rol Responsable:

Involucrados

Disciplina:

Gestión del Ambiente

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee Prototipo de la Interfaz de Usuario

Este documento contiene todo lo relacionado con la interfaz. Son elementos de diseño visual que permiten al usuario tener una idea de las interfaces que mostrará el sistema, para obtener una retroalimentación sobre los requerimientos del sistema. Se realizan unas cuantas imágenes de pantalla o un esqueleto de interfaz de usuario ejecutable. El propósito de crear interfaces de usuario es para probar el diseño de las interfaces, incluyendo la usabilidad que estas pueden tener antes de que se comience con el desarrollo del software. De esta manera se valida que se esté cumpliendo con 127

MeRinde Guía Detallada los requerimientos exigidos antes de que se realice todo el esfuerzo necesario para el desarrollo. Relaciones del Artefacto Prototipo de la Interfaz de Usuario Rol Responsable:

Arquitecto de Software

Disciplina:

Análisis y Diseño

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Prueba de Concepto Arquitectónico del Negocio Este artefacto es una solución que simplemente puede ser conceptual a los requerimientos arquitectónicamente significativos del negocio. El propósito de la Prueba de Concepto Arquitectónico del Negocio es determinar si existe, o es probable que exista, una solución (o un sistema de soluciones) que satisfaga los requerimientos arquitectónicamente significativos. Relaciones del Artefacto Prueba de Concepto Arquitectónico del Negocio Rol Responsable:

Involucrados

Disciplina:

Modelado del Negocio

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Realizaciones de los Casos de Uso Las Realizaciones de los Casos de Uso se llevan a cabo como resultado de un caso de uso específico. La realización del caso de uso debe cumplir con los

128

MeRinde Guía Detallada requerimientos establecidos y debe reflejar el comportamiento de su caso de uso correspondiente. Este artefacto se halla dentro del Modelo de Diseño reflejando los productos de trabajo relacionados con el caso de uso pero que pertenecen a dicho modelo. Estos productos de trabajos relacionados consisten en los diagramas de comunicación y secuencia que expresan el comportamiento del caso del uso en términos de objetos de colaboración, y dichos diagramas deben elaborarse haciendo uso del Lenguaje de Modelado Unificado (UML). Relaciones del Artefacto Realizaciones de los Casos de Uso Rol Responsable:

Arquitecto de Software

Disciplina:

Análisis y Diseño

Artefacto Contenedor:

Modelo de Diseño

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Realizaciones de los Casos de Uso del Negocio Este artefacto expresa la colaboración de los sistemas del negocio, los trabajadores del negocio, las entidades del negocio, y los eventos del negocio para realizar un caso de uso del negocio particular. Mientras que un caso de uso del negocio describe los pasos que se deben realizar para aportar valor a un actor del negocio, una realización de casos de uso del negocio describe la manera en que estos pasos se realizan dentro de la organización. Además, las Realizaciones de los Casos de uso del Negocio son utilizadas por los involucrados para verificar que el equipo del proyecto y demás involucrados entienden la estructura y el funcionamiento del negocio.

129

MeRinde Guía Detallada Relaciones del Artefacto Realizaciones de los Casos de Uso del Negocio Rol Responsable:

Involucrados

Disciplina:

Modelado del Negocio

Artefactos Contenedores:

Modelo de Diseño del Negocio

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Registro de Evaluación Es el documento creado para registrar los resultados obtenidos de una evaluación aplicada a uno ó más artefactos revisados del proyecto. Relaciones del Artefacto Registro de Evaluación Rol Responsable:

Analista de Calidad

Disciplina:

Gestión del Proyecto

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Registro de Revisión Este documento es creado para registrar los resultados obtenidos de una revisión aplicada a uno ó más artefactos generados del proyecto de desarrollo de software. El Mentor es el responsable, ya que revisa algunos de los artefactos que son generados en el transcurso del proyecto y plasma los resultados y observaciones correspondientes a la revisión de un artefacto en este documento.

130

MeRinde Guía Detallada Relaciones del Artefacto Registro de Revisión Rol Responsable:

Mentor

Disciplina:

Gestión del Proyecto

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Registro de Riesgos Este es un registro que refleja a manera de resumen todos los riesgos que han sido asociados al proyecto en desarrollo. Este documento debe ser utilizado para monitorear y hacer seguimiento de todas las acciones tomadas para la mitigación de los riesgos identificados. En este documento se relaciona cada riesgo identificado con sus acciones preventivas y de contingencia, y es fundamental para la planificación de las iteraciones. Relaciones del Artefacto Registro de Riesgos Rol Responsable:

Involucrados

Disciplina:

Gestión del Proyecto

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee

Reglas del Negocio Una Regla del Negocio es la declaración de políticas y restricciones de negocio de una organización. Este artefacto consiste en definir una exigencia específica o invariable que debe satisfacerse por el negocio. Las Reglas del Negocio pueden aplicarse siempre o sólo bajo una condición específica. Es necesario que la

131

MeRinde Guía Detallada aplicación muestre las restricciones que existen en el negocio, de tal forma que no sea posible realizar acciones inválidas. Relaciones del Artefacto Reglas del Negocio Rol Responsable:

Involucrados

Disciplina:

Modelado del Negocio

Artefacto Contenedor:

Modelo de Análisis del Negocio

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Repositorio de Versiones Este artefacto es una herramienta orientada a ficheros que permite a los participantes de un proyecto centralizar y coordinar sus trabajos. Son útiles para almacenar los cambios en código fuente, documentación, planes, imágenes, cartas, etc., reflejados en una nueva versión.

Puede estar preparado para distribuirse

sirviéndose de una red informática como Internet o en un medio físico como un disco compacto. Este repositorio puede ser de acceso público o estar protegido. Cabe destacar la existencia de Finde Forge una herramienta que permite crear y administrar repositorios de los ficheros de un proyecto de software. Este se encuentra en un portal del estado denominado Rinde y puede ser utilizado para publicar las distintas versiones de un proyecto. Relaciones del Artefacto Repositorio de Versiones Rol Responsable:

Líder del Proyecto

Disciplina:

Gestión de Configuración y Cambios

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee 132

MeRinde Guía Detallada Resultado de Prueba Representa los resultados obtenidos por el Desarrollador al probar los elementos y subsistemas de implementación que este va elaborando e integrando. Este artefacto puede ser informal o llevarlo el desarrollador para su uso personal. Relaciones del Artefacto Resultado de Prueba Rol Responsable:

Desarrollador

Disciplina:

Implementación

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Resumen del Ciclo de Prueba Este artefacto presenta un resumen de los resultados de las pruebas aplicadas a los componentes operacionales del sistema, lo cual permite revisar y evaluar la calidad del producto que se está desarrollando una vez aplicados una serie de Casos de Prueba. Adicionalmente, este artefacto puede contener observaciones referentes a calidad tanto generales como para cada una de las pruebas realizadas y puede tener recomendaciones para futuros ciclos de pruebas. Relaciones del Artefacto Resumen del Ciclo de Prueba Rol Responsable:

Probador

Disciplina:

Pruebas

Artefacto Contenedor:

Plan de Pruebas

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee

133

MeRinde Guía Detallada Script de Pruebas Su propósito es proveer la implementación de un subconjunto de pruebas requeridas de una manera eficiente y eficaz. Los Scripts de Prueba pueden tomar la forma de instrucciones de texto documentadas que son ejecutadas manualmente o instrucciones legibles por computadora que permiten la ejecución de las pruebas automáticamente, en este último caso este artefacto es un programa de software que automatiza la ejecución de un procedimiento de prueba o una parte de este. Relaciones del Artefacto Solicitud de Cambio Rol Responsable:

Probador

Disciplina:

Pruebas

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No posee

Plantilla:

No posee

Solicitud de Cambio Este documento es utilizado para documentar las solicitudes de cambio realizadas al sistema por los involucrados en el proyecto. Relaciones del Artefacto Solicitud de Cambio Rol Responsable:

Involucrados

Disciplina:

Gestión de Configuración y Cambios

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee

134

MeRinde Guía Detallada Solicitudes de Involucrados Es el documento que contiene los requerimientos de cualquier tipo hechos por los involucrados, los cuales deberían estar satisfechos en el sistema a ser desarrollado. Relaciones del Artefacto Solicitudes de Involucrados Rol Responsable:

Analista de Producto

Disciplina:

Requerimientos

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee Solicitud del Sistema

Este artefacto representa el primer paso en el proceso oficial para el desarrollo de un sistema. En el mismo se debe registrar información significativa sobre la descripción del proceso que se quiera crear o mejorar mediante la implantación de un nuevo sistema, se debe determinar la necesidad del mismo, cuáles son sus objetivos y se debe plantear cuáles son los beneficios que este podría llegar a brindar. Sí existe documentación relacionada a la solicitud como pueden ser procedimientos, diagramas que reflejen la relación entre procesos, leyes, resoluciones, decretos, normas en general, etc. deberían ser anexadas. Relaciones del Artefacto Solicitud del Sistema Rol Responsable:

Involucrados

Disciplina:

Gestión del Proyecto

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

135

MeRinde Guía Detallada Subsistema de Implementación Este artefacto agrupa un conjunto de Elementos de Implementación. Con el Modelo de Implementación y con la Vista de Implementación contenida en el Documento de Arquitectura del Software (DAS) se señalan y se definen cuales son los Subsistemas de Implementación que componen el sistema. Relaciones del Artefacto Subsistema de Implementación Rol Responsable:

Desarrollador

Disciplina:

Implementación

Artefacto Contenedor:

Modelo de Implementación

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Términos de Referencia para el Equipo de Desarrolladores del Sistema Es el convenio de prestación de servicios que se estable con la contratista seleccionada para llevar a cabo el proyecto descrito en el artefacto Términos de Referencia del Sistema. Representa el acuerdo jurídico entre la organización que contrata y el contratista a fin de regular las obligaciones,

responsabilidades,

actividades, resultados, planificación y honorarios de los servicios a ser prestados para el proyecto. Relaciones del Artefacto Términos de Referencia para el Equipo de Desarrolladores del Sistema Rol Responsable:

Líder del Proyecto

Disciplina:

Gestión del Proyecto

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee 136

MeRinde Guía Detallada Términos de Referencia del Sistema Este artefacto contiene una descripción del sistema a realizar, los objetivos, las características técnicas, alcance y documentos a producirse. Todo proyecto comienza por una necesidad. Identificar plenamente dicha necesidad conlleva tiempo, se requiere recopilar información sobre el problema, clarificar la forma más adecuada de resolverlo, tomar la decisión de ejecutarlo y definir ciertos requisitos que deben cumplir las personas u organizaciones para solventarlos. El artefacto Términos de Referencia permite al cliente expresar con claridad sus necesidades, problemas u oportunidades y permite al potencial contratista percibir con claridad la dimensión del trabajo real, estimar los costos que implica, los plazos necesarios y los requisitos que le permita realizar una oferta de sus servicios adecuada. La redacción y entrega de los términos de referencia a un conjunto de potenciales contratistas tiene la ventaja para el cliente que puede contrastar diferentes opciones y establecer rangos de ofertas en términos de calidad, tiempo y presupuestos, y establecer si sus pretensiones han sido bien interpretadas. En el caso de que el desarrollo sea interno y no se manejen contratistas de igual forma se debe realizar este artefacto a fin de que sirva como elemento delimitador del proyecto para el equipo interno de desarrollo. Relaciones del Artefacto Términos de Referencia del Sistema Rol Responsable:

Líder del Proyecto

Disciplina:

Gestión del Proyecto

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee

137

MeRinde Guía Detallada Trabajador del Negocio Un Trabajador del Negocio representa a un ser humano, software o hardware que desempeña un rol dentro de las Realizaciones del Caso de Uso del Negocio. Este trabajador interactúa con entidades y otros trabajadores para que el negocio funcione. Los trabajadores de negocio son roles y no posiciones organizacionales, ya que una persona puede desempeñar varios roles pero sólo tiene una posición en la organización. Esta Conceptualización permite identificar mejoras en los procesos del negocio y considerar el efecto de la automatización del proceso del negocio o del outsourcing de proceso del negocio. Relaciones del Artefacto Términos de Trabajador del Negocio Rol Responsable:

Involucrados

Disciplina:

Modelado del Negocio

Artefactos Contenedores:

•

Modelo de Análisis del Negocio

•

Modelo de Diseño del Negocio

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Unidad de Implantación Este artefacto comprende una colección de componentes ejecutables, documentos como las notas de lanzamiento y el material de apoyo al usuario, y los artefactos de instalación. Una Unidad de implantación se asocia típicamente a un solo nodo en la red total de los sistemas informáticos o de los periféricos. Esta definición cabe en los casos donde está disponible el producto sobre el Internet, la unidad de implantación se puede descargar directamente e instalar por el usuario. Cabe destacar 138

MeRinde Guía Detallada que la unidad de implantación también se puede instalar desde un dispositivo de almacenamiento. Relaciones del Artefacto Unidad de Implantación Rol Responsable:

Líder del Proyecto

Disciplina:

Implantación

Artefacto Contenedor:

El Sistema

Artefacto(s) Contenido(s):

No aplica

Plantilla:

No posee

Visión del Negocio Este documento describe los objetivos del esfuerzo de un

modelado de

negocio. Proporciona la entrada al proceso de aprobación del proyecto. Comunica el por qué y el qué relacionado al proyecto y es una medida contra las cuales deben validarse todas las decisiones futuras. El empleo completo o parcial de este artefacto está sujeto al propósito del sistema que se desea desarrollar: • Creación de un negocio: consiste en aplicar ingeniería al negocio para crear un nuevo proceso de negocio, una nueva línea de negocio ó una nueva organización. • Reingeniería del negocio: reingeniería es la revisión fundamental y el rediseño radical de procesos del negocio para alcanzar mejoras satisfactorias en medidas críticas y actuales de rendimiento, tales como costos, calidad, servicio y rapidez. El objetivo es hacer las tareas que ya se están haciendo, pero hacerlo mejor, trabajar más inteligentemente. • Mejoras al Negocio: consiste en aplicar ingeniería al negocio para mejorar algunos procesos locales y que no afectan al negocio entero.

139

MeRinde Guía Detallada Se recomienda aplicar este documento en su totalidad si lo que se va a realizar es una creación de un negocio o una reingeniería del negocio. Si el propósito es realizar mejoras al negocio se recomienda que se utilice este artefacto pero no en su totalidad sino enfocándose en las secciones de introducción, Posición y objetivos del modelado del negocio. Muchos documentos que sirven para este artefacto podrían encontrarse ya elaborados dentro de la organización, de ser así no es necesario volver a trabajar en general estos, se puede hacer referencia dentro del documento de visión del negocio a estos. Relaciones del Artefacto Visión del Negocio Rol Responsable:

Involucrados

Disciplina:

Modelado del Negocio

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee

Visión del Sistema Este artefacto describe los objetivos principales del proyecto, funcionalidades y restricciones en forma concisa; es un resumen del proyecto apto para la toma de decisiones, ofrece una descripción del sistema a ser desarrollado desde la perspectiva de los requerimientos más importantes. Este documento captura las expectativas de los que soportan el desarrollo del proyecto. Se recomienda que este artefacto se conserve lo más claro y resumido posible para que pueda llegar lo más pronto posible a los involucrados en el proyecto y para que sea más fácil de entender por estos. Este documento debe incluir solamente las principales descripciones de los requerimientos y debe evitar muchos detalles 140

MeRinde Guía Detallada específicos. Adicionalmente

debe especificar las capacidades operacionales

(volúmenes de trabajo, tiempos de respuestas, precisión), perfiles de usuario, y los límites del sistema. Relaciones del Artefacto Visión del Sistema Rol Responsable:

Analista de Producto

Disciplina:

Requerimientos

Artefacto Contenedor:

No aplica

Artefacto(s) Contenido(s):

No aplica

Plantilla:

Si posee

141

MeRinde Guía Detallada

APÉNDICE B DESCRIPCIÓN DE LAS ACTIVIDADES Y TAREAS PROPUESTAS DE MERINDE

142

MeRinde Guía Detallada En este apéndice se detallaran todas las actividades y subactividades presentadas en los flujos de trabajos por cada disciplina propuesta en el Capítulo VI en la sección de Disciplinas. Las actividades y subactividades serán listadas agrupadas por disciplinas y en el mismo orden de su aparición en el mencionado Capítulo. Así mismo, se procederá a la descripción de cada una de las tareas que integran cada actividad o subactividades a fin de completar todo la información necesaria para poder ejecutar la propuesta MeRinde. Modelado del Negocio Actividades Evaluar el Status del Negocio: Esta actividad busca evaluar la situación actual del negocio y fijar los objetivos de modelado del negocio. Está conformada por las siguientes tareas: • Mantener las Reglas del Negocio. • Evaluar la Organización Objetivo. • Analizar la Arquitectura del Negocio. Describir el Negocio Actual: Esta actividad tiene como objetivo comprender y describir el negocio actual. Está conformada por las siguientes tareas: • Mantener las Reglas del Negocio. • Encontrar los Actores y los Casos de Uso del Negocio. • Evaluar la Organización Objetivo. • Analizar la Arquitectura del Negocio.

143

MeRinde Guía Detallada Definir el Negocio: Esta actividad trata sobre definir cuál va a ser el negocio. Incluye el siguiente flujo de trabajo de subactividades:

• Identificar los Procesos del Negocio: En esta subactividad se identifican los procesos del negocio, se describen y se priorizan. Está conformada por las siguientes tareas: a. Mantener las Reglas del Negocio. b. Encontrar los Actores y los Casos de Uso del Negocio. c. Priorizar los Casos de Uso del Negocio. d. Analizar la Arquitectura del Negocio.

144

MeRinde Guía Detallada • Refinar las Definiciones del Proceso de Negocio: Esta subactividad tiene como objetivo detallar un subconjunto de los procesos del negocio que así lo requieran. Está conformada por las siguientes tareas: a. Estructurar el Modelo de Caso de Uso del Negocio. b. Detallar el Caso de Uso del Negocio. c. Priorizar los Casos de Uso del Negocio. d. Revisar el Modelo de Caso de Uso del Negocio. • Diseñar las Realizaciones de los Procesos del Negocio: Con esta subactividad se busca hacer las realizaciones de los casos de uso del negocio en términos de las colaboraciones del sistema de negocio y de los trabajadores del negocio. Está conformada por las siguientes tareas: a. Analizar la Arquitectura del Negocio. b. Mantener las Reglas del Negocio. c. Realizar los Casos de Uso del Negocio. • Refinar los Roles y las Responsabilidades: En esta subactividad se detallan los trabajadores y entidades del negocio. Está conformada por las siguientes tareas: a. Detallar los Trabajadores del Negocio. b. Detallar las Entidades del Negocio. c. Revisar el Modelo de Diseño del Negocio. Explorar la Automatización del Proceso: Esta actividad trata sobre analizar las oportunidades de automatización para los procesos del negocio en estudio.

145

MeRinde Guía Detallada Está conformada por las siguientes tareas: • Definir la Automatización de los Requerimientos. • Formular la Prueba de Concepto Arquitectónico del Negocio. Desarrollar el Modelo de Dominio: Esta actividad se basa en desarrollar un subconjunto del modelo de análisis del negocio, es decir, el modelo de dominio. Está conformada por las siguientes tareas: • Mantener las Reglas del Negocio. • Analizar la Arquitectura del Negocio. • Detallar las Entidades del Negocio. • Revisar el Modelo de Análisis del Negocio. Tareas Tabla 4 Tarea: Mantener las Reglas del Negocio 4

Rol Responsable: Involucrados. Descripción: Esta tarea se basa en identificar las reglas del negocio que se consideran necesarias para un proyecto y en dar definiciones detalladas a dichas reglas. Artefacto(s) de Entrada: •

Visión del Negocio.

Artefacto(s) de Salida: •

Modelo de Análisis del Negocio (Reglas del Negocio).

Tabla 5 Tarea: Evaluar la Organización Objetivo 5

Rol Responsable: Involucrados. Descripción: Esta tarea se refiere a cómo evaluar el estado actual que presenta la organización en la que el sistema será implantado, es decir, la organización objetivo. 146

MeRinde Guía Detallada Incluye describir el estado actual en términos de procesos actuales, herramientas, destrezas, competidores, clientes, etc. Además, permite identificar los involucrados para el esfuerzo de modelado del negocio. Artefacto(s) de Entrada: No tiene. Artefacto(s) de Salida: •

Evaluación de la Organización Objetivo.

Tabla 6 Tarea: Analizar la Arquitectura del Negocio 6

Rol Responsable: Involucrados. Descripción: Esta tarea se centra en definir una arquitectura del negocio candidata. Se identifican los sistemas, trabajadores y entidades del negocio, así como también se priorizan las realizaciones de los casos de uso y se realizan vistas de la arquitectura del negocio. Sirve para entender las fuerzas que afectan significativamente al negocio y definir los diagramas del negocio, los mecanismos claves y los acuerdos de modelado del negocio. Artefacto(s) de Entrada: •

Visión del Negocio.

Artefacto(s) de Salida: •

Documento de Arquitectura del Negocio.

•

Modelo de Análisis del Negocio.

•

Modelo de Diseño del Negocio.

•

Modelo de Implantación del Negocio.

Tabla 7 Tarea: Encontrar los Actores y los Casos de Uso del Negocio 7

Rol Responsable: Involucrados. Descripción: Esta tarea se basa en definir los actores y casos de uso que interactúan

147

MeRinde Guía Detallada con el negocio, así como también se enfoca en los límites del negocio a ser modelados. Permite dar una idea general de los procesos del negocio y crear los diagramas del Modelo de Casos de Uso del Negocio. Artefacto(s) de Entrada: •

Visión del Negocio.

Artefacto(s) de Salida: •

Modelo de Casos de Uso del Negocio.

Tabla 8 Tarea: Priorizar los Casos de Uso del Negocio 8

Rol Responsable: Involucrados. Descripción: Esta tarea se concentra en identificar y priorizar los casos de uso del negocio arquitectónicamente significativos. Incluye definir un conjunto de escenarios y casos de uso del negocio que tienen una cobertura arquitectónicamente significativa, que dichos casos de uso y escenarios sean analizados en la iteración en curso y además sean el centro de cierta funcionalidad significativa. Artefacto(s) de Entrada: •

Modelo de Casos de Uso del Negocio.

•

Visión del Negocio.

•

Documento de Arquitectura del Negocio.

Artefacto(s) de Salida: •

Documento de Arquitectura del Negocio.

•

Modelo de Casos de Uso del Negocio.

Tabla 9 Tarea: Estructurar el Modelo de Caso de Uso del Negocio 9

Rol Responsable: Involucrados. Descripción: Se centra en relacionar los casos de uso del negocio y los actores del negocio, e identificar sus comportamientos opcionales y excepcionales. Se establece

148

MeRinde Guía Detallada las inclusiones, extensiones y generalizaciones entre casos de uso del negocio, y las generalizaciones entre actores del negocio. Esto permite que los requerimientos del negocio sean más fáciles de comprender. Artefacto(s) de Entrada: •

Modelo de Casos de Uso del Negocio.

Artefacto(s) de Salida: •

Modelo de Casos de Uso del Negocio.

Tabla 10 Tarea: Detallar el Caso de Uso del Negocio 10

Rol Responsable: Involucrados. Descripción: Esta tarea se basa en describir de forma clara y completa un caso de uso del negocio. Describe el flujo de trabajo del caso de uso en detalle, así como también permite asegurar que el caso de uso del negocio soporta la estrategia del negocio y que los clientes, usuarios e involucrados puedan entender el flujo de trabajo del caso de uso del negocio. Artefacto(s) de Entrada: •

Modelo de Casos de Uso del Negocio.

Artefacto(s) de Salida: •

Modelo de Casos de Uso del Negocio.

Tabla 11 Tarea: Revisar el Modelo de Caso de Uso del Negocio 11

Rol Responsable: Mentor. Descripción: Esta tarea se refiere a cuándo y cómo se lleva a cabo la revisión del artefacto Modelo de Casos de Uso del Negocio y cómo abordar los resultados obtenidos de la revisión. Permite verificar que los resultados de dicho artefacto coincidan con la visión que tienen los involucrados del negocio. Artefacto(s) de Entrada: 149

MeRinde Guía Detallada •

Modelo de Casos de Uso del Negocio.

Artefacto(s) de Salida: •

Registro de Revisión.

Tabla12 Tarea: Realizar los Casos de Uso del Negocio 12

Rol Responsable: Involucrados. Descripción: Se refiere a cómo desarrollar una realización de caso de uso partiendo de un caso de uso del negocio particular. Permite identificar elementos como sistemas del negocio y trabajadores del negocio que llevan a cabo el flujo de eventos del caso de uso, distribuir comportamiento del caso de uso a esos elementos, identificar responsabilidades, atributos y asociaciones de los sistemas del negocio y los trabajadores del mismo, e identificar las entidades y eventos del negocio. Artefacto(s) de Entrada: •

Documento de Arquitectura del Negocio.

•

Modelo de Casos de Uso del Negocio.

Artefacto(s) de Salida: •

Modelo de Diseño del Negocio (Realizaciones de los Casos de Uso del Negocio).

Tabla 13 Tarea: Detallar los Trabajadores del Negocio 13

Rol Responsable: Involucrados. Descripción: En esta tarea se describe de forma clara y completa cada trabajador del negocio. Incluye describir las responsabilidades de un trabajador del negocio y los requerimientos de competencia, así como también permite asegurar que este trabajador pueda llevar a cabo sus actividades dentro del negocio. Artefacto(s) de Entrada: •

Modelo de Diseño del Negocio (Realizaciones de los Casos de Uso del

150

MeRinde Guía Detallada Negocio). •

Modelo de Análisis del Negocio (Trabajadores del Negocio).

Artefacto(s) de Salida: •

Modelo de Diseño del Negocio (Trabajadores del Negocio).

Tabla 14 Tarea: Detallar las Entidades del Negocio 14

Rol Responsable: Involucrados. Descripción: Esta tarea se basa en describir de manera entendible y suficiente una entidad del negocio. Su propósito es asegurar que la entidad del negocio pueda proveer el comportamiento requerido, identificar los eventos del negocio y analizar las relaciones estructurales de la entidad del negocio. Artefacto(s) de Entrada: •

Modelo de Análisis del Negocio (Entidad del Negocio).

•

Modelo de Análisis del Negocio (Realizaciones de los Casos de Uso del Negocio).

Artefacto(s) de Salida: •

Modelo de Diseño del Negocio (Entidad del Negocio).

Tabla 15 Tarea: Revisar el Modelo de Diseño del Negocio 15

Rol Responsable: Mentor. Descripción: Esta tarea define cuándo y cómo se conduce la revisión del Modelo de Diseño del Negocio y cómo tratar los resultados de las revisiones. Además, permite la verificación formal de que los resultados del artefacto Modelo de Diseño del Negocio coinciden con la visión que tienen los involucrados del negocio. Artefacto(s) de Entrada: •

Modelo de Diseño del Negocio.

Artefacto(s) de Salida: 151

MeRinde Guía Detallada •

Registro de Revisión.

Tabla 16 Tarea: Definir la Automatización de los Requerimientos 16

Rol Responsable: Involucrados. Descripción: En esta tarea se explora las tecnologías candidatas para hacer que la organización objetivo sea más efectiva. Permite determinar el nivel de automatización en la organización objetivo y obtener los requerimientos del sistema de los artefactos de modelado del negocio. Artefacto(s) de Entrada: •

Evaluación de la Organización Objetivo.

Artefacto(s) de Salida: •

Especificación de los Requerimientos del Software (Modelo de Casos de Uso).

•

Especificación de los Requerimientos del Software (Especificaciones Suplementarias).

•

Modelo de Análisis.

Tabla 17 Tarea: Formular la Prueba de Concepto Arquitectónico del Negocio 17

Rol Responsable: Involucrados. Descripción: En esta tarea se describe cómo desarrollar una prueba de concepto arquitectónico en un contexto de negocio basado en los requerimientos más significativos. Permite sintetizar al menos una solución de forma conceptual que cubre los requerimientos arquitectónicos críticos. Artefacto(s) de Entrada: •

Documento de Arquitectura del Negocio.

Artefacto(s) de Salida: •

Prueba de Concepto Arquitectónico del Negocio.

152

MeRinde Guía Detallada Tabla 18 Tarea: Revisar el Modelo de Análisis del Negocio 18

Rol Responsable: Mentor. Descripción: Esta tarea define cuándo y cómo se ejecuta la revisión del artefacto Modelo de Análisis del Negocio y cómo abordar los resultados de dicha revisión. Asimismo, permite verificar formalmente que los resultados del artefacto coinciden con la visión que tienen los involucrados del negocio. Artefacto(s) de Entrada: •

Modelo de Análisis del Negocio.

Artefacto(s) de Salida: •

Registro de Revisión.

Requerimientos Actividades Analizar el Problema: Esta actividad consiste en estudiar el problema a ser solucionado y proponer una solución de alto nivel. Está conformada por las siguientes tareas: • Establecer la Visión del Sistema. • Determinar la Terminología a Usar. • Determinar los Actores y los Casos de Uso. Entender las Necesidades de los Involucrados: Esta actividad consiste en comprender las nuevas necesidades que tienen los involucrados sobre el sistema existente y busca definir los aspectos claves que servirán de solución. Está conformada por las siguientes tareas: • Gestionar Dependencias. 153

MeRinde Guía Detallada • Determinar los Actores y los Casos de Uso. • Determinar la Terminología a Usar. • Obtener Requerimientos de los Involucrados. • Establecer la Visión del Sistema. • Desarrollar Especificaciones Suplementarias. Definir el Sistema: En esta actividad se debe definir el alcance del sistema y los requerimientos más importantes. Está conformada por las siguientes tareas: • Gestionar Dependencias. • Determinar los Actores y los Casos de Uso. • Determinar la Terminología a Usar. • Establecer la Visión del Sistema. • Desarrollar Especificaciones Suplementarias. • Revisar la Visión del Sistema. Gestionar el Alcance del Sistema: Esta actividad busca asegurar que los requerimientos del sistema se han comprendido y establece un conjunto de requerimientos manejables para trabajarlos durante la iteración. Está conformada por las siguientes tareas: • Gestionar Dependencias. • Establecer la Visión del Sistema. • Dar Prioridad a los Casos de Uso. Refinar la Definición del Sistema: En esta actividad se deben detallar los requerimientos que van a ser desarrollados en el ciclo de desarrollo en curso. Está conformada por las siguientes tareas: 154

MeRinde Guía Detallada • Detallar los Casos de Uso. • Detallar los Requerimientos del Software. • Desarrollar las Especificaciones Suplementarias. • Revisar la Especificación de Requerimientos del Software. Gestionar los Cambios de Requerimientos: En esta actividad se administran los cambios de los requerimientos y se mide el impacto general que estos pueden llegar a tener. Está conformada por las siguientes tareas: • Gestionar Dependencias. • Estructurar el Modelo de Casos de Uso. • Verificar los Requerimientos. Tareas Tabla 19 Tarea: Establecer la Visión del Sistema 19

Rol Responsable: Analista de Producto. Descripción: Esta tarea describe cómo desarrollar la visión total para el sistema, incluyendo el problema a ser solucionado, el alcance, las características y las restricciones del sistema. El objetivo de esta tarea es acordar las pautas sobre las cuales los problemas tienen que ser solucionados y describir los rasgos principales del sistema. Artefacto(s) de Entrada: •

Plan de Iteración.

•

Términos de Referencia del Sistema.

•

Solicitudes de Involucrados.

Artefacto(s) de Salida: •

Visión del Sistema.

155

MeRinde Guía Detallada

Tabla 20 Tarea: Determinar la Terminología a Usar 20

Rol Responsable: Analista de Producto. Descripción: Esta tarea se refiere a cómo definir el vocabulario común que va ser utilizado en todas las descripciones textuales del sistema, especialmente en los requerimientos de software. Artefacto(s) de Entrada: No tiene. Artefacto(s) de Salida: •

Glosario del Sistema.

Tabla 21 Tarea: Determinar los Actores y los Casos de Uso 21

Rol Responsable: Analista de Producto. Descripción: Se identifican los actores y casos de uso para apoyar los requerimientos que se están llevando a cabo. El propósito de esta tarea es definir el alcance del sistema y un perfil de la funcionalidad del sistema. Una técnica muy exitosa que puede usarse para encontrar los actores y los casos de uso es proveer un Taller de Caso de Uso para los involucrados. Artefacto(s) de Entrada: •

Plan de Iteración.

•

Solicitudes de Involucrados.

Artefacto(s) de Salida: •

Especificación de Requerimientos del Software (Modelo de Casos de Uso).

Tabla Tarea: Gestionar Dependencias Rol Responsable: Analista de Producto. Descripción: En esta tarea se describe cómo hacer uso de las dependencias que existen 156

MeRinde Guía Detallada entre los requerimientos con el fin de gestionar el alcance del proyecto y manejar los cambios de requerimientos que surjan durante el proceso de desarrollo de software. Artefacto(s) de Entrada: No tiene. Artefacto(s) de Salida: •

Visión del Sistema.

Tabla 22 Tarea: Obtener Requerimientos de los Involucrados 22

Rol Responsable: Analista de Producto. Descripción: Se refiere a la forma de obtener los requerimientos que a los involucrados (clientes, usuarios, etc.) les gustaría que el sistema incluyera. Esta tarea permite comprender quiénes son los involucrados del proyecto, obtener las solicitudes de los mismos que reflejan las necesidades que el sistema debe satisfacer y darle a sus requerimientos un orden de importancia. Artefacto(s) de Entrada: No tiene. Artefacto(s) de Salida: •

Solicitudes de Involucrados.

Tabla 23 Tarea: Desarrollar Especificaciones Suplementarias 23

Rol Responsable: Analista de Producto. Descripción: Se basa en la captura los requerimientos que no fueron considerados en los casos de uso. Cabe destacar que pueden ser tomados en cuenta tanto requerimientos funcionales como no funcionales del sistema. A medida de que se ejecuta esta tarea se debe asegurar que todos los requerimientos sean especificados con el nivel de detalle necesario en la documentación. Artefacto(s) de Entrada: 157

MeRinde Guía Detallada •

Plan de Iteración.

•

Solicitudes de Involucrados.

Artefacto(s) de Salida: •

Especificación de Requerimientos del Software (Especificaciones Suplementarias).

Tabla 24 Tarea: Revisar la Visión del Sistema 24

Rol Responsable: Mentor. Descripción: Describe cuándo y cómo se debe llevar a cabo la revisión del artefacto Visión del Sistema y cómo abordar los resultados de la revisión. Artefacto(s) de Entrada: •

Visión del Sistema.

Artefacto(s) de Salida: •

Registro de Revisión.

Tabla 25 Tarea: Dar Prioridad a los Casos de Uso 25

Rol Responsable: Arquitecto de Software. Descripción: Es donde los casos de uso con significado arquitectónico se identifican y se priorizan. Una vez que se han priorizado los casos de uso se puede decidir el orden de desarrollo del sistema. Artefacto(s) de Entrada: •

Especificación de Requerimientos del Software (Modelo de Casos de Uso).

•

Plan de Iteración.

•

Registro de Riesgo.

Artefacto(s) de Salida: •

Documento de Arquitectura del Software.

158

MeRinde Guía Detallada Tabla 26 Tarea: Detallar los Casos de Uso 26

Rol Responsable: Analista de Producto. Descripción: En esta tarea se agregan los detalles a un caso de uso específico. La finalidad de esta tarea es describir con detalles suficientes uno o más flujos de eventos de los casos de uso, para poder empezar el desarrollo del software. Artefacto(s) de Entrada: •

Especificación de Requerimientos del Software (Modelo de Casos de Uso).

•

Plan de Iteración.

Artefacto(s) de Salida: •

Especificación de Requerimientos del Software (Modelo de Casos de Uso).

Tabla 27 Tarea: Detallar los Requerimientos del Software 27

Rol Responsable: Analista de Producto. Descripción: Permite recoger, detallar y organizar el sistema de los artefactos que describen los requerimientos del sistema. Esta tarea asegura que todos los requerimientos están especificados con el nivel de detalle necesario para que puedan ser entendidos por los diseñadores, desarrolladores, probadores y demás roles que participen en el proyecto. Artefacto(s) de Entrada: •

Plan de Iteración.

•

Visión del Sistema.

Artefacto(s) de Salida: •

Especificación de Requerimientos del Software.

Tabla 28 Tarea: Revisar la Especificación de Requerimientos del Software 28

Rol Responsable: Mentor.

159

MeRinde Guía Detallada Descripción: Esta tarea define cómo se lleva a cabo la revisión del artefacto Especificación de Requerimientos del Software (ERS). Su propósito es verificar que los resultados de las actividades de los requerimientos coinciden con la visón que tiene el cliente del sistema. Artefacto(s) de Entrada: •

Especificación de Requerimientos del Software.

Artefacto(s) de Salida: •

Registro de Revisión.

Tabla 29 Tarea: Estructurar el Modelo de Casos de Uso 29

Rol Responsable: Analista de Producto. Descripción: Se centra en relacionar los casos de uso y los actores del sistema, e identificar sus comportamientos opcionales y excepcionales. Se establece las inclusiones, extensiones y generalizaciones entre casos de uso, y las generalizaciones entre actores. Esto permite que los requerimientos del sistema sean más fáciles de comprender. Artefacto(s) de Entrada: •

Especificación de Requerimientos del Software (Modelo de Casos de Uso).

Artefacto(s) de Salida: •

Glosario del Sistema.

•

Especificación de Requerimientos del Software (Modelo de Casos de Uso).

•

Especificación de Requerimientos del Software (Especificaciones Suplementarias).

Tabla 30 Tarea: Verificar los Requerimientos 30

Rol Responsable: Líder del Proyecto. Descripción: En esta tarea se busca verificar que los requerimientos encontrados en el

160

MeRinde Guía Detallada sistema satisfacen las necesidades que fueron planteadas por los clientes. Por otro lado, esta tarea describe cuándo y cómo deben ser realizadas las supervisiones, así como también plantea cuales deben ser las acciones a tomar en caso de que se encuentren discordancia con lo esperado. Artefacto(s) de Entrada: •

Especificación de Requerimientos del Software.

•

Términos de Referencia del Sistema.

•

Plan de Iteración.

Artefacto(s) de Salida: •

Registro de Evaluación.

Análisis y Diseño Actividades Definir una Arquitectura Candidata: En esta actividad se debe proponer una arquitectura inicial para el software. Está conformada por las siguientes tareas: • Analizar la Arquitectura. • Analizar los Casos de Uso. Analizar el Comportamiento del Sistema: Esta actividad transforma las descripciones del comportamiento de los requerimientos en un conjunto de elementos que permiten realizar el diseño del sistema. Está conformada por las siguientes tareas: • Identificar los Elementos de Diseño. • Analizar los Casos de Uso. 161

MeRinde Guía Detallada • Generar Prototipo de la Interfaz de Usuario • Diseñar la Interfaz de Usuario. • Revisar el Diseño. Refinar la Arquitectura: Esta actividad refina la arquitectura para una iteración. Está conformada por las siguientes tareas: • Identificar los Elementos de Diseño. • Describir la Arquitectura en Tiempo de Ejecución. • Describir la Distribución. • Identificar los Mecanismos de Diseño. • Incorporar Elementos de Diseño Existentes. • Identificar Servicios. • Revisar Artefacto de la Arquitectura. Diseñar los Servicios: Esta actividad permite modelar el comportamiento de los servicios, identificar los proveedores de servicio y las particiones. Está conformada por la siguiente tarea: • Diseñar Servicios. Diseñar los Componentes: Esta actividad refina el diseño del sistema. Está conformada por las siguientes tareas: • Diseñar Clases. • Diseñar Subsistemas. • Diseñar Casos de Uso. • Diseñar Cápsulas. • Diseñar los Elementos Soporte de Prueba. 162

MeRinde Guía Detallada • Revisar el Diseño. Diseñar la Base de Datos: En esta actividad se identifican las clases de diseño que formaran parte de la base de datos del sistema y

se especifica las

estructuras de la base de datos. Está conformada por las siguientes tareas: • Diseñar Clases. • Diseñar la Base de Datos. • Especificar Migración de Datos. • Revisar el Diseño. Tareas Tabla 31 Tarea: Analizar la Arquitectura 31

Rol Responsable: Arquitecto de Software. Descripción: Esta tarea permite definir una arquitectura candidata basada en la experiencia obtenida de sistemas similares o en dominios del problema similares, y restringir las técnicas arquitectónicas a ser usadas en el sistema. Se definen los diagramas de las vistas arquitectónicas, mecanismos claves y los modelos para el sistema. Cabe destacar que analizar la arquitectura resulta beneficioso en el caso donde se desarrollen sistemas que no se hayan hecho antes. Artefacto(s) de Entrada: •

Visión del Sistema.

•

Glosario del Sistema.

•

Registro de Riesgo.

Artefacto(s) de Salida: •

Modelo de Análisis.

•

Modelo de Diseño.

163

MeRinde Guía Detallada •

Modelo de Implantación.

•

Documento de Arquitectura del Software.

Tabla 32 Tarea: Analizar los Casos de Uso 32

Rol Responsable: Arquitecto de Software. Descripción: Se basa en cómo desarrollar las Realizaciones de los Casos de Uso del nivel de análisis de un caso de uso particular. Incluye identificar las clases que llevan a cabo el flujo de eventos de un caso de uso, distribuir el comportamiento de casos de uso a esas clases, identificar atributos, responsabilidades y relaciones entre las clases, y además observar los mecanismos arquitectónicos. Artefacto(s) de Entrada: •

Especificación de Requerimientos del Software (Modelo de Casos de Uso).

Artefacto(s) de Salida: •

Modelo de Análisis.

•

Modelo de Diseño (Realizaciones de los Casos de Uso).

Tabla 33 Tarea: Identificar los Elementos de Diseño 33

Rol Responsable: Arquitecto de Software. Descripción: Esta tarea se refiere a cómo identificar subsistemas, clases, clases activas, interfaces de subsistemas, eventos y señales tanto externas como internas del sistema. Su propósito es refinar las clases de análisis en los elementos del Modelo de Diseño apropiados. Artefacto(s) de Entrada: •

Modelo de Servicio.

•

Modelo de Análisis.

Artefacto(s) de Salida: •

Modelo de Diseño.

164

MeRinde Guía Detallada •

Modelo de Servicio.

Tabla 34 Tarea: Generar Prototipo de la Interfaz de Usuario 34

Rol Responsable: Arquitecto de Software. Descripción: Esta tarea se refiere a cómo diseñar e implementar un prototipo de la interfaz de usuario y obtener retroalimentación de requerimientos funcionales y usabilidad. Artefacto(s) de Entrada: •

Mapa de Navegación.

Artefacto(s) de Salida: •

Prototipo de la Interfaz de Usuario.

Tabla 35 Tarea: Diseñar la Interfaz de Usuario 35

Rol Responsable: Arquitecto de Software. Descripción: Explica cómo llevar a cabo el diseño de la interfaz de usuario haciendo énfasis en la usabilidad. Se describe las características de los usuarios, se define un mapa de navegación y se detallan los elementos de diseño de la interfaz de usuario. Esta tarea permite crear un diseño de la interfaz de usuario que apoye el razonamiento y el realce de su usabilidad. Artefacto(s) de Entrada: •

Especificación de Requerimientos del Software.

Artefacto(s) de Salida: •

Mapa de Navegación.

165

MeRinde Guía Detallada Tabla 36 Tarea: Revisar el Diseño 36

Rol Responsable: Analista de Calidad. Descripción: En esta tarea se define cómo llevar a cabo la revisión del diseño y cómo abordar los resultados de dicha revisión. Permite verificar que el Modelo de Diseño cumpla con los requerimientos del sistema y que sirva como una buena base para su implementación, así como también asegura que dicho modelo sea consistente con respecto a las pautas de diseño generales. Artefacto(s) de Entrada: •

Modelo de Diseño.

•

Mapa de Navegación.

Artefacto(s) de Salida: •

Registro de Evaluación.

Tabla 37 Tarea: Describir la Arquitectura en Tiempo de Ejecución 37

Rol Responsable: Arquitecto de Software. Descripción: Se define una arquitectura de proceso para el sistema en términos de clases activas y sus instancias y las relaciones de éstos a los hilos y procesos del sistema operativo. Esta incluye analizar la concurrencia de requerimientos, identificar procesos y sus ciclos de vidas, identificar mecanismos de comunicación entre procesos y asignar recursos entre procesos de coordinación, y para distribuir los elementos modelos entre procesos. Artefacto(s) de Entrada: •

Documento de Arquitectura del Software.

•

Modelo de Diseño.

Artefacto(s) de Salida: •

Documento de Arquitectura del Software.

•

Modelo de Diseño.

166

MeRinde Guía Detallada Tabla 38 Tarea: Describir la Distribución 38

Rol Responsable: Arquitecto de Software. Descripción: Esta tarea define la arquitectura de la implantación para un sistema distribuido en términos de nodos físicos y sus interconexiones. Se analizan los requerimientos de distribución del sistema y se define la topología y configuración de la red. Cabe destacar que esta tarea se aplica solamente a los sistemas distribuidos. Artefacto(s) de Entrada: •

Modelo de Diseño.

•

Documento de Arquitectura del Software.

Artefacto(s) de Salida: •

Modelo de Implantación.

•

Documento de Arquitectura del Software.

167

MeRinde Guía Detallada Tabla 39 Tarea: Identificar los Mecanismos de Diseño 39

Rol Responsable: Arquitecto de Software. Descripción: Esta tarea describe cómo refinar los mecanismos del análisis en mecanismos del diseño. Cabe destacar que dicho refinamiento se basa en las restricciones impuestas por el ambiente de implementación. Se categorizan clientes de mecanismos de análisis, se realiza un inventario de los mecanismos de implementación y se documentan las maneras de producirse la arquitectura. Artefacto(s) de Entrada: •

Modelo de Servicio.

•

Modelo de Análisis.

Artefacto(s) de Salida: •

Documento de Arquitectura del Software.

•

Modelo de Diseño.

•

Modelo de Servicio.

Tabla 40 Tarea: Incorporar Elementos de Diseño Existentes 40

Rol Responsable: Arquitecto de Software. Descripción: Esta tarea describe cómo desarrollar y refinar el Modelo de Diseño. Incluye analizar las interacciones de las clases de análisis para encontrar interfaces, clases del diseño y subsistemas del diseño, refinar la arquitectura haciendo reutilización cuando sea posible, identificar soluciones a los problemas comúnmente encontrados del diseño, e incluir elementos arquitectónicamente significativos del modelo del diseño en la sección lógica de la visión del documento de la arquitectura del software. Artefacto(s) de Entrada: •

Modelo de Servicio.

•

Modelo de Diseño. 168

MeRinde Guía Detallada •

Documento de Arquitectura del Software.

Artefacto(s) de Salida: •

Modelo de Servicio.

•

Modelo de Diseño.

•

Documento de Arquitectura del Software.

Tabla 41 Tarea: Identificar Servicios 41

Rol Responsable: Arquitecto de Software. Descripción: Esta tarea identifica el Modelo de Diseño de una aplicación orientada a servicio (SOA) en términos de servicios y aplicaciones y documentos de especificación inicial de esos servicios. También incluye determinar las dependencias iníciales y la comunicación entre servicios. Artefacto(s) de Entrada: •

Modelo de Servicio.

Artefacto(s) de Salida: •

Modelo de Servicio.

Tabla 42 Tarea: Revisar Artefacto de la Arquitectura 42

Rol Responsable: Mentor. Descripción: Esta tarea describe cuándo y cómo llevar a cabo la revisión de la arquitectura y como tratar los resultados de la revisión. Se basa en las recomendaciones por cada revisión, las definiciones del alcance y los objetivos de la revisión, la documentación de los resultados y la toma de acciones en los defectos identificados de la revisión. Artefacto(s) de Entrada: •

Documento de Arquitectura del Software.

Artefacto(s) de Salida: 169

MeRinde Guía Detallada •

Registro de Revisión.

Tabla 43 Tarea: Diseñar Servicios 43

Rol Responsable: Arquitecto de Software. Descripción: En esta tarea se define y especifica los servicios y estructura de una solución orientada a servicios en términos de colaboraciones de los elementos contenidos del diseño y de subsistemas/interfaces externos. Incluye documentar las especificaciones de servicios y determinar las dependencias y comunicación entre servicios. Artefacto(s) de Entrada: •

Modelo de Servicio.

•

Modelo de Diseño.

•

Documento de Arquitectura del Software.

•

Especificación de Requerimientos del Software (Especificaciones Suplementarias).

Artefacto(s) de Salida: •

Modelo de Diseño.

•

Modelo de Servicio.

Tabla 44 Tarea: Diseñar Clases 44

Rol Responsable: Arquitecto de Software. Descripción: Esta tarea se basa en cómo diseñar la estructura de las clases de un subsistema o componente. Permite asegurar que las clases provea el comportamiento que las Realizaciones de los Casos de Uso requieran, asegurar que información suficiente es proporcionada para implementar la clase sin equivocaciones, para manejar requerimientos no funcionales relacionados con las clases y para incluir los mecanismos de diseño utilizados por la clase.

170

MeRinde Guía Detallada Artefacto(s) de Entrada: •

Modelo de Análisis.

Artefacto(s) de Salida: •

Modelo de Diseño.

Tabla 45 Tarea: Diseñar Subsistemas 45

Rol Responsable: Arquitecto de Software. Descripción: Esta tarea se refiere a documentar los elementos de subsistemas, definir las clases de diseño o subsistemas de diseño, definir los comportamientos especificados en las interfaces de los subsistemas y determinar las interfaces sobre las que el subsistema es dependiente. En UML 2.0 se puede observar las notaciones referidas a las dependencias de los subsistemas. Artefacto(s) de Entrada: No tiene. Artefacto(s) de Salida: •

Modelo de Diseño.

Tabla 46 Tarea: Diseñar Casos de Uso 46

Rol Responsable: Arquitecto de Software. Descripción: En esta tarea se define cómo refinar los productos de análisis de casos de uso desarrollando las Realizaciones de los Casos de Uso del nivel de diseño. Incluye determinar las Realizaciones de los Casos de Uso en términos de interacciones, describir las interacciones entre los objetos de diseño, refinar la descripción de flujo de eventos y unificar las clases de diseño y subsistemas. Artefacto(s) de Entrada: •

Especificación de Requerimientos del Software (Modelo de Casos de Uso).

Artefacto(s) de Salida: 171

MeRinde Guía Detallada •

Modelo de Diseño.

Tabla 47 Tarea: Diseñar Capsulas 47

Rol Responsable: Arquitecto de Software. Descripción: Esta tarea describe las características del diseño de capsulas. Tiene como propósito elaborar y refinar las descripciones de una capsula. Las capsulas son usadas para definir hilos simultáneos de ejecución en el sistema. Estas capsulas son representadas en UML 2.0. Artefacto(s) de Entrada: •

Modelo de Diseño.

Artefacto(s) de Salida: •

Modelo de Diseño (Capsula).

Tabla 48 Tarea: Diseñar los Elementos Soporte de Prueba 48

Rol Responsable: Arquitecto de Software. Descripción: Permite identificar y diseñar las clases y los paquetes que suministrará la funcionalidad específica de las pruebas necesarias, diseñar las interfaces para las herramientas de pruebas automatizadas y automatizar los procedimientos de prueba para los que no tienen ninguna herramienta de prueba automática disponible. Artefacto(s) de Entrada: No tiene. Artefacto(s) de Salida: •

Modelo de Diseño.

Tabla 49 Tarea: Diseñar la Base de Datos 49

Rol Responsable: Arquitecto de Software. 172

MeRinde Guía Detallada Descripción: En esta tarea se refleja cómo diseñar una base de datos para implementar persistencia dentro de una aplicación. Se basa en definir un modelo del diseño lógico de la base de datos y los detalles del diseño físico de la base de datos, así como también permite asegurar la integridad y la calidad del modelo de datos mediante revisiones de los resultados. Artefacto(s) de Entrada: •

Modelo de Diseño.

Artefacto(s) de Salida: •

Modelo de Datos.

Tabla 50 Tarea: Especificar Migración de Datos 50

Rol Responsable: Arquitecto de Software. Descripción: En esta tarea se define el alcance de la migración, los perfiles de datos y la correspondencia entre las fuentes de datos y la base de datos objetivo. Además, se identifican cuáles partes de las fuentes de datos pueden ser migradas automáticamente y cuáles partes pueden ser migradas manualmente. Artefacto(s) de Entrada: •

Modelo de Diseño.

Artefacto(s) de Salida: •

Especificación de Migración de Datos.

Implementación Actividades Estructurar el Modelo de Implementación: En esta actividad se propone una estructura para la implementación, con el fin de conseguir facilitar la implementación, integración y desarrollo de los procesos.

173

MeRinde Guía Detallada

Está conformada por la siguiente tarea: • Estructurar el Modelo de Implementación. Planificar la Integración: Esta actividad se planifica la integración del sistema para la iteración en curso. Está conformada por la siguiente tarea: • Planificar la Integración del Sistema. Implementar Componentes: Esta actividad completa una parte de la implementación del sistema con el propósito de que pueda ser distribuido para la integración. Está conformada por las siguientes tareas: • Planear la Integración de Subsistemas. • Analizar el Comportamiento en Tiempo de Ejecución. • Implementar los Elementos de Diseño. • Ejecutar Pruebas a los Elementos y Subsistemas de Implementación. • Revisar el Código. Integrar cada Subsistema: Esta actividad integra los cambios de los desarrolladores para crear una nueva versión consistente de la implementación de un subsistema. Está conformada por las siguientes tareas: • Integrar Subsistema. • Ejecutar Pruebas a los Elementos y Subsistemas de Implementación.

174

MeRinde Guía Detallada Integrar el Sistema: Esta actividad integra los subsistemas implementados para crear una nueva versión consistente del sistema en conjunto. Está conformada por la siguiente tarea: • Integrar el Sistema.

175

MeRinde Guía Detallada Tareas Tabla 51 Tarea: Estructurar el Modelo de Implementación del Sistema 51

Rol Responsable: Arquitecto de Software. Descripción: En esta tarea se estructura del Modelo de implementación, se ajustan los subsistemas formados por los elementos de implementación, se define las dependencias entre subsistemas, se considera cómo tratar los programas ejecutables y las pruebas de los artefactos de dicho modelo, y se actualiza la vista de Implementación. Artefacto(s) de Entrada: •

Modelo de Diseño.

Artefacto(s) de Salida: •

Modelo de Implementación.

•

Documento de Arquitectura del Software.

Tabla 52 Tarea: Planificar la Integración del Sistema 52

Rol Responsable: Desarrollador. Descripción: Esta tarea consiste en determinar los subsistemas que participan en los casos de uso y escenarios para la iteración en curso, definir los componentes operacionales para integrar el sistema y se evalúa el artefacto Plan de Integración. Artefacto(s) de Entrada: •

Plan de Iteración.

Artefacto(s) de Salida: •

Plan de Integración.

176

MeRinde Guía Detallada Tabla 53 Tarea: Planear la Integración de Subsistemas 53

Rol Responsable: Desarrollador. Descripción: Esta tarea describe cómo planear el orden de integración de los elementos contenidos en un subsistema de implementación. Se describe los componentes operacionales y se determinan las clases que participan en los escenarios seleccionados. Además, se consideran los subsistemas de implementación que son necesarios para el componente operacional. Artefacto(s) de Entrada: •

Modelo de Implementación (Subsistema de Implementación).

•

Plan de Iteración.

Artefacto(s) de Salida: •

Plan de Integración.

Tabla 54 Tarea: Analizar el Comportamiento en Tiempo de Ejecución 54

Rol Responsable: Desarrollador. Descripción: Esta tarea se basa en la observación del comportamiento de un componente durante su ejecución para así determinar futuras mejoras. Permite entender el comportamiento del componente operacional y encontrar defectos para realizar correcciones sobre el mismo. Artefacto(s) de Entrada: •

Modelo de Implementación (Elemento de Implementación).

Artefacto(s) de Salida: •

Resultado de Prueba.

Tabla 55 Tarea: Implementar los Elementos de Diseño 55

Rol Responsable: Desarrollador. Descripción: En esta tarea se prepara la implementación y se produce una 177

MeRinde Guía Detallada implementación basada en el diseño (clases, realizaciones de los casos de uso, o entidad de base de datos). Cabe destacar que la implementación debe reflejar lo acordado en el diseño y si se hacen modificaciones a los elementos de implementación (código fuente y archivos de datos) se debe actualizar el Modelo de Diseño. Artefacto(s) de Entrada: •

Modelo de Diseño.

•

Modelo de Implementación (Elemento de Implementación).

Artefacto(s) de Salida: •

Modelo de Implementación (Elemento de Implementación).

•

Modelo de Implementación (Subsistema de Implementación).

Tabla 56 Tarea: Ejecutar Pruebas a los Elementos y Subsistemas de Implementación 56

Rol Responsable: Desarrollador. Descripción: Esta tarea se basa en la creación y ejecución de un conjunto de pruebas para validar que los elementos y subsistemas implementados por el desarrollador están trabajando apropiadamente antes de que la prueba más formal sea llevada a cabo. Artefacto(s) de Entrada: •

Modelo de Implementación (Elemento de Implementación).

•

Modelo de Implementación (Subsistema de Implementación).

Artefacto(s) de Salida: •

Resultado de Prueba.

Tabla 57 Tarea: Revisar el Código 57

Rol Responsable: Analista de Calidad. Descripción: En esta tarea se revisa el código para verificar la implementación. Se realizan recomendaciones y se documentan los resultados de la revisión para asegurar

178

MeRinde Guía Detallada que los defectos sean documentados. Artefacto(s) de Entrada: •

Modelo de Implementación (Elemento de Implementación).

Artefacto(s) de Salida: •

Registro de Evaluación.

Tabla 58 Tarea: Integrar Subsistema 58

Rol Responsable: Desarrollador. Descripción: Esta tarea se refiere a la integración de los elementos de implementación hasta obtener un subsistema de implementación. Artefacto(s) de Entrada: •

Plan de Integración.

•

Modelo de Implementación (Elemento de Implementación).

Artefacto(s) de Salida: •

Componente Operacional del Sistema.

•

Modelo de Implementación (Subsistema de Implementación).

Tabla 59 Tarea: Integrar el Sistema 59

Rol Responsable: Desarrollador. Descripción: Esta tarea consiste en integrar los subsistemas de implementación por partes hasta obtener el Componente Operacional del Sistema. Artefacto(s) de Entrada: •

Modelo de Implementación (Subsistema de Implementación).

•

Plan de Integración.

Artefacto(s) de Salida: •

Componente Operacional del Sistema.

179

MeRinde Guía Detallada Pruebas Actividades Definir la Misión de las Pruebas: En esta actividad se debe identificar la misión a alcanzar con la realización de las pruebas para el sistema,

se deben

determinar el enfoque de las pruebas para una determinada iteración y se debe llegar a un acuerdo con todos los involucrados sobre dicha misión que dirigirá el esfuerzo de las pruebas. Está conformada por las siguientes tareas: • Identificar la Misión de las Pruebas • Identificar los Motivadores de las Pruebas • Identificar las Ideas de Pruebas • Identificar los Objetos de Pruebas • Acordar la Misión de las Pruebas • Definir Criterios de Aceptación de los Casos de Prueba • Definir el Enfoque de Pruebas Validar la Estabilidad del Componente Operacional del Sistema: Esta actividad valida que los componentes operacionales del sistema sean estables para iniciar las pruebas detalladas y sus evaluaciones. Está conformada por las siguientes tareas: • Definir los Detalles de las Pruebas • Implementar las Pruebas • Ejecutar el Conjunto de Pruebas • Determinar los Resultados de las Pruebas • Analizar Pruebas Fallidas • Evaluar y Defender la Calidad 180

MeRinde Guía Detallada Probar y Evaluar el Sistema: En esta actividad se deben realizar todas las pruebas intensas al sistema que se tengan programadas para asegurar la calidad de todos los componentes que están siendo evaluados, con el fin de cumplir los objetivos de las pruebas establecidos con anterioridad. Está conformada por las siguientes tareas: • Identificar las Ideas de Pruebas • Definir los Detalles de las Pruebas • Implementar las Pruebas • Ejecutar el Conjunto de Pruebas • Determinar los Resultados de las Pruebas • Analizar Pruebas Fallidas Evaluar las Pruebas en Términos de su Misión: En esta actividad se detallan los resultados obtenidos de las pruebas aplicadas, y se evalúan en conformidad a los criterios para el lanzamiento propuestos y la misión planteada. Está conformada por las siguientes tareas: • Determinar los Resultados de las Pruebas • Evaluar y Mejorar el Esfuerzo de las Pruebas • Evaluar y Defender la Calidad Mejorar los Recursos de Prueba: Esta actividad mantiene y mejora los recursos de las pruebas. Está conformada por las siguientes tareas: • Definir el Enfoque de Pruebas • Identificar las Ideas de Pruebas • Definir los Detalles de las Pruebas • Implementar las Pruebas 181

MeRinde Guía Detallada • Preparar los Lineamientos del Proyecto Verificar el Enfoque de las Pruebas: En esta actividad se debe comprobar que las pruebas planificadas cumplirán con los objetivos que se tienen estimados a alcanzar y se debe estimar si dichas pruebas son las más adecuadas para producir los resultados esperados con los recursos disponibles. Está conformada por las siguientes tareas: • Establecer la Configuración del Ambiente de Pruebas • Definir los Detalles de las Pruebas • Acordar las Pruebas a Realizar

182

MeRinde Guía Detallada Tareas Tabla 60 Tarea: Identificar la Misión de las Pruebas 60

Rol Responsable: Probador. Descripción: Se debe determinar la finalidad para la cual se probará un determinado sistema, tomando en cuenta los objetivos que se tienen planeados alcanzar con la realización del sistema y los recursos que se tienen disponibles para ejecutar las pruebas al mismo. Artefacto(s) de Entrada: •

Visión del Sistema.

•

Plan de Iteración.

Artefacto(s) de Salida: •

Plan de Pruebas.

Tabla 61 Tarea: Identificar los Motivadores de las Pruebas 61

Rol Responsable: Probador. Descripción: Se deben identificar el conjunto de razones positivas y factores, que impulsan la acción de realizar las pruebas al sistema en la iteración. Artefacto(s) de Entrada: •

Plan de Iteración.

•

Documento de Arquitectura de Software.

•

Especificación de Requerimientos de Software.

•

Visión del Sistema.

Artefacto(s) de Salida: •

Plan de Pruebas.

183

MeRinde Guía Detallada Tabla 62 Tarea: Identificar las Ideas de Pruebas 62

Rol Responsable: Probador. Descripción: En esta tarea se deben identificar de forma preliminar cuáles son las posibles pruebas que se le pueden aplicar al sistema y cuáles serían los posibles objetos sobre los cuales se podrían aplicar dicho conjunto de pruebas, dados los motivadores y objetivos que se tengan. Artefacto(s) de Entrada: •

Plan de Iteración.

•

Plan de Pruebas.

•

Especificación de Requerimientos de Software (Modelo de Casos de Uso).

Artefacto(s) de Salida: •

Plan de Pruebas (Lista de Ideas de las Prueba).

Tabla 63 Tarea: Identificar los Objetos de Pruebas 63

Rol Responsable: Probador. Descripción: En esta tarea se deben identificar cuáles son los objetos (hardware y software) sobre los cuales se aplicaran un conjunto de casos de pruebas en la iteración en curso. De ser requerimientos funcionales se empleará las Realizaciones de los Casos de Uso del sistema para determinar los escenarios a probar de un objeto determinado. Artefacto(s) de Entrada: •

Plan de Iteración.

•

Modelo de Implementación.

•

Modelo de Implantación.

•

Modelo de Diseño (Realizaciones de los Casos de Uso).

Artefacto(s) de Salida: •

Plan de Pruebas (Lista de Ideas de Prueba).

184

MeRinde Guía Detallada •

Plan de Pruebas (Escenarios por Caso de Uso).

Tabla64 Tarea: Definir el Enfoque de Pruebas 64

Rol Responsable: Probador. Descripción: En esta tarea se definen para cada uno de los Casos de Prueba a realizar el enfoque y la estrategia a emplear para cada escenario a probar de un objeto. Adicionalmente se establece la trazabilidad entre las pruebas y los objetos. Artefacto(s) de Entrada: •

Plan de Iteración.

•

Plan de Pruebas (Escenarios por Caso de Uso).

•

Especificación de Requerimientos de Software.

•

Documento de Arquitectura del Software.

•

Visión del Sistema.

Artefacto(s) de Salida: •

Plan de Pruebas (Casos de Prueba).

•

Plan de Pruebas (Matriz de trazabilidad de Pruebas).

Tabla 65 Tarea: Acordar la Misión de las Pruebas 65

Rol Responsable: Analista de Calidad. Descripción: Esta tarea tiene como fin que el analista de calidad en conjunto con el probador lleguen a un consenso sobre la misión de las pruebas. Artefacto(s) de Entrada: •

Plan de Iteración.

•

Plan de Pruebas.

Artefacto(s) de Salida: •

Plan de Pruebas.

185

MeRinde Guía Detallada Tabla 66 Tarea: Definir Criterios de Aceptación de los Casos de Prueba 66

Rol Responsable: Involucrados. Descripción: En esta tarea se deben establecer entre los involucrados del proyecto cuales van a ser los criterios bajo los cuales los Casos de Prueba serán aceptados como suficientes pala misión que se tiene planteada. Artefacto(s) de Entrada: •

Plan de Pruebas (Casos de Prueba).

Artefacto(s) de Salida: •

Plan de Pruebas (Criterios de Aceptación).

Tabla 67 Tarea: Definir los Detalles de las Pruebas 67

Rol Responsable: Probador. Descripción: En esta tarea se detallan el conjunto de pasos, métodos y medidas necesarias para llevar a cabo cada uno de los Casos de Prueba a realizar por escenario de los objetos a probar. Artefacto(s) de Entrada: •

Plan de Pruebas (Casos de Prueba).

•

Plan de Pruebas (Datos de Prueba).

•

Plan de Pruebas (Lista de ideas de las Pruebas).

•

Plan de Pruebas.

Artefacto(s) de Salida: •

Plan de Pruebas (Casos de Prueba).

•

Plan de Pruebas (Datos de Prueba).

•

Script de Pruebas.

186

MeRinde Guía Detallada Tabla 68 Tarea: Implementar las Pruebas 68

Rol Responsable: Probador. Descripción: En esta tarea se implementan todos aquellos Script de Prueba que se preparen para realizar pruebas automáticas a un objeto determinado. Artefacto(s) de Entrada: •

Plan de Pruebas (Casos de Prueba).

•

Plan de Pruebas (Datos de Prueba).

•

Plan de Pruebas.

•

Script de Pruebas.

Artefacto(s) de Salida: •

Script de Pruebas.

Tabla 69 Tarea: Ejecutar el Conjunto de Pruebas 69

Rol Responsable: Probador. Descripción: En esta tarea se ejecuta el conjunto de pruebas establecidas en el Plan de Pruebas a un Componente Operacional del Sistema con el fin de evaluar la calidad del producto que se está desarrollado. Los Resultados de cada una de las pruebas ejecutadas deben ser registrados en su respectivo Caso de Prueba así como cualquier observación importante que el probador pueda aportar para mejorar la calidad del sistema. Artefacto(s) de Entrada: •

Componente Operacional del Sistema.

•

Plan de Pruebas.

Artefacto(s) de Salida: •

Plan de Pruebas (Casos de Prueba).

187

MeRinde Guía Detallada Tabla 70 Tarea: Determinar los Resultados de las Pruebas 70

Rol Responsable: Probador. Descripción: Esta tarea recoge los resultados obtenidos al aplicar un conjunto de Casos de Prueba estimados para un determinado ciclo de pruebas, con el fin de obtener resultados globales y observaciones sobre la calidad del sistema en desarrollo. Artefacto(s) de Entrada: •

Plan de Pruebas (Casos de Prueba).

Artefacto(s) de Salida: •

Plan de Pruebas (Resumen del Ciclo de Pruebas).

Tabla 71 Tarea: Analizar Pruebas Fallidas 71

Rol Responsable: Probador. Descripción: En esta tarea se documentan el conjunto de Casos de Prueba que resultaron fallidas al ser ejecutadas. El Probador puede enviar una solicitud de cambio si tiene una observación importante para la mejora de la calidad y también cuando no se estén cumpliendo los criterios de aceptación de los involucrados sobre determinado objeto. Artefacto(s) de Entrada: •

Plan de Pruebas (Casos de Prueba).

Artefacto(s) de Salida: •

Solicitud de Cambio.

Tabla 72 Tarea: Evaluar y Defender la Calidad 72

Rol Responsable: Analista de Calidad Descripción: En esta tarea el Analista de Calidad supervisa los resultados obtenidos al ejecutar un Ciclo de Prueba con el fin de evaluar la calidad que se está obteniendo al 188

MeRinde Guía Detallada desarrollar el sistema. Artefacto(s) de Entrada: •

Plan de Pruebas (Resumen del Ciclo de Prueba).

•

Plan de Iteración.

Artefacto(s) de Salida: •

Plan de Pruebas (Resumen del Ciclo de Prueba).

Tabla 73 Tarea: Evaluar y Mejorar el Esfuerzo de las Pruebas 73

Rol Responsable: Probador. Descripción: Esta tarea contempla los cambios que se le puede hacer a los Casos de Prueba durante la ejecución de un ciclo de prueba con el fin de mejorar la efectividad que estos puedan llegar a tener. Artefacto(s) de Entrada: •

Plan de Pruebas (Resumen del Ciclo de Prueba).

•

Plan de Pruebas.

•

Plan de Iteración.

Artefacto(s) de Salida: •

Plan de Pruebas.

•

Plan de Pruebas (Resumen del Ciclo de Prueba).

Tabla 74 Tarea: Preparar los Lineamientos del Proyecto 74

Rol Responsable: Mentor. Descripción: En esta tarea el mentor con los resultados obtenidos al aplicar un conjunto de pruebas determinados para una iteración puede especificar nuevos lineamientos para futuras iteraciones o proyectos con el fin de buscar mejorar el proceso y la efectividad. Artefacto(s) de Entrada: 189

MeRinde Guía Detallada No Aplica. Artefacto(s) de Salida: •

Marco de Desarrollo (Lineamientos del Proyecto).

Tabla 75 Tarea: Establecer la Configuración del Ambiente de Pruebas 75

Rol Responsable: Probador. Descripción: Esta tarea abarca el proceso que ejecuta el probador para configurar el ambiente de prueba conforme a los requerimientos que se tengan para ejecutar un conjunto determinado de Casos de Prueba. Artefacto(s) de Entrada: •

Documento de Arquitectura del Software.

•

Plan de Pruebas.

Artefacto(s) de Salida: •

Plan de Pruebas.

Tabla 76 Tarea: Acordar las Pruebas a Realizar 76

Rol Responsable: Involucrados. Descripción: En esta tarea los involucrados en el proyecto deben llegar a un consenso sobre el conjunto de pruebas que serán ejecutadas a fin de evaluar la calidad del sistema en desarrollo. Artefacto(s) de Entrada: •

Plan de Pruebas.

Artefacto(s) de Salida: •

Plan de Pruebas.

190

MeRinde Guía Detallada Implantación Actividades Planificar la Implantación: En esta actividad se planifica la implantación del producto, en la cual se toma en cuenta cómo y cuándo el producto será entregado al usuario final. Está conformada por las siguientes tareas: • Definir el Listado de Materiales • Desarrollar el Plan de Implantación Desarrollar Material de Apoyo: En esta actividad se produce el material de apoyo necesario para que los usuarios utilicen correctamente el sistema. Está conformada por las siguientes tareas: • Elaborar el Plan de Adiestramiento • Desarrollar los Materiales de Adiestramiento • Desarrollar Materiales de Apoyo • Desarrollar Instalador de Componentes Gestionar las Pruebas de Aceptación: Esta actividad valida que el sistema es aceptado por el cliente antes de su lanzamiento. Está conformada por las siguientes tareas: • Gestionar las Pruebas de Aceptación • Ejecutar el Conjunto de Pruebas • Determinar los Resultados de las Pruebas • Preparar el Ambiente de Desarrollo

191

MeRinde Guía Detallada Producir Unidad de Implantación: En esta actividad se produce una unidad de implantación, la cual permite que el producto de software sea eficazmente instalado y usado. Está conformada por las siguientes tareas: • Crear Unidad de Implantación • Elaborar Notas de Lanzamiento Pruebas del Producto Beta: Esta actividad solicita retroalimentación sobre el producto (Beta) a un subconjunto de usuarios mientras todavía está en desarrollo la versión definitiva del producto. Está conformada por las siguientes tareas: • Gestionar las Pruebas Beta • Probar el Producto Beta Gestionar las Pruebas de Aceptación en las Instalaciones del Usuario: Esta actividad asegura que el producto sea aceptado por el cliente antes de la puesta en marcha en sus instalaciones. Consiste en una especialización de Gestionar las Pruebas de Aceptación, la cual se lleva acabo instalando el producto dentro de las instalaciones del cliente. Está conformada por las siguientes tareas: • Gestionar las Pruebas de Aceptación • Ejecutar el Conjunto de Pruebas • Determinar los Resultados de las Pruebas • Preparar el Ambiente de Desarrollo Empaquetar el Sistema: Esta actividad consiste en reunir todas las unidades de implantación para exportarla a algún dispositivo de almacenamiento.

192

MeRinde Guía Detallada Está conformada por las siguientes tareas: • Agrupar las Unidades de Implantación • Verificar manufactura del Producto Proveer el Acceso para el Sitio de Descarga: En esta actividad se hace disponible el producto para su descarga a través de Internet. Está conformada por la siguiente tarea: • Proveer Acceso al Sitio de Descarga

Tareas Tabla 77 Tarea: Ejecutar el Conjunto de Pruebas 77

Rol Responsable: Probador. Descripción: En esta tarea se ejecuta el conjunto de pruebas establecidas en el Plan de Pruebas a un Componente Operacional del Sistema con el fin de evaluar la calidad del producto que se está desarrollado. Los Resultados de cada una de las pruebas ejecutadas deben ser registrados en su respectivo Caso de Prueba así como cualquier observación importante que el probador pueda aportar para mejorar la calidad del sistema. Artefacto(s) de Entrada: •

Componente Operacional del Sistema.

•

Plan de Pruebas.

Artefacto(s) de Salida: •

Plan de Pruebas (Casos de Prueba).

193

MeRinde Guía Detallada Tabla 78 Tarea: Determinar los Resultados de las Pruebas 78

Rol Responsable: Probador. Descripción: Esta tarea recoge los resultados obtenidos al aplicar un conjunto de Casos de Prueba estimados para un determinado ciclo de pruebas, con el fin de obtener resultados globales y observaciones sobre la calidad del sistema en desarrollo. Artefacto(s) de Entrada: •

Plan de Pruebas (Casos de Prueba).

Artefacto(s) de Salida: •

Plan de Pruebas (Resumen del Ciclo de Pruebas).

Tabla 79 Tarea: Definir el Listado de Materiales 79

Rol Responsable: Líder del Proyecto. Descripción: En esta tarea se establecen el listado de materiales que conformaran parte del sistema en desarrollo. Artefacto(s) de Entrada: •

Plan de Iteración.

•

Planificación del Proyecto.

Artefacto(s) de Salida: •

El Sistema (Lista de Materiales).

194

MeRinde Guía Detallada Tabla 80 Tarea: Desarrollar el Plan de Implantación 80

Rol Responsable: Líder del Proyecto. Descripción: Esta tarea tiene como objetivo planificar la implantación del sistema en desarrollo, estableciendo el conjunto de tareas y mecanismos necesarios para poder poner en funcionamiento el sistema en las instalaciones de los usuarios. Artefacto(s) de Entrada: •

Plan de Iteración.

•

Planificación del Proyecto.

Artefacto(s) de Salida: •

Plan de Implantación.

Tabla 81 Tarea: Elaborar el Plan de Adiestramiento 81

Rol Responsable: Involucrados. Descripción: Esta tarea tiene como objetivo que se establezca un plan para capacitar a los usuarios del sistema para su utilización. Artefacto(s) de Entrada: •

Plan de Iteración.

•

Planificación del Proyecto.

Artefacto(s) de Salida: •

Plan de Adiestramiento.

195

MeRinde Guía Detallada Tabla 82 Tarea: Desarrollar los Materiales de Adiestramiento 82

Rol Responsable: Involucrados. Descripción: En esta tarea se deben desarrollar el conjunto de materiales destinados a capacitar a los usuarios del sistema para su utilización. Artefacto(s) de Entrada: •

Plan de Iteración.

•

Plan de Adiestramiento.

Artefacto(s) de Salida: •

Material de Adiestramiento.

Tabla 83 Tarea: Desarrollar Materiales de Apoyo 83

Rol Responsable: Involucrados. Descripción: En esta tarea se deben desarrollar el conjunto de materiales destinados a ayudar a los usuarios del sistema para su manipulación. Artefacto(s) de Entrada: •

Plan de Iteración.

•

Componente Operacional del Sistema.

Artefacto(s) de Salida: •

Manual de Usuario.

•

Manual de Instalación.

196

MeRinde Guía Detallada Tabla 84 Tarea: Desarrollar Instalador de Componentes 84

Rol Responsable: Desarrollador. Descripción: En esta tarea se debe desarrollar el software necesario para poder instalar y desinstalar de forma fácil y segura el sistema para las múltiples plataformas que se consideren para el proyecto. Artefacto(s) de Entrada: •

Componente Operacional del Sistema.

Artefacto(s) de Salida: •

El Sistema (Artefactos de Instalación).

Tabla 85 Tarea: Gestionar las Pruebas de Aceptación 85

Rol Responsable: Líder del Proyecto. Descripción: En esta tarea se debe verificar que el sistema desarrollado y probado tanto el ambiente de desarrollo como dentro de las instalaciones del usuario, satisface las necesidades del cliente conforme a sus criterios establecidos previamente. Artefacto(s) de Entrada: •

Plan de Implantación.

•

Plan de Pruebas (Criterios de Aceptación).

Artefacto(s) de Salida: •

Solicitud de Cambio.

197

MeRinde Guía Detallada Tabla 86 Tarea: Preparar el Ambiente de Desarrollo 86

Rol Responsable: Involucrados. Descripción: En esta tarea el ambiente de desarrollo debe configurarse para adaptarse a las necesidades del proyecto en desarrollo y conforme a los recursos existentes, adicionalmente se debe determinar para el desarrollo y pruebas del sistema una serie de políticas de mantenimiento, administración, respaldo, entre otros. Artefacto(s) de Entrada: •

Infraestructura de Desarrollo.

Artefacto(s) de Salida: •

Infraestructura de Desarrollo.

Tabla 87 Tarea: Crear Unidad de Implantación 87

Rol Responsable: Líder del Proyecto. Descripción: En esta tarea se procede a la elaboración de una componente del sistema que está contemplado a ser implantado y concedido al cliente. Artefacto(s) de Entrada: •

Componente Operacional del Sistema.

Artefacto(s) de Salida: •

El Sistema (Unidad del Implantación).

198

MeRinde Guía Detallada Tabla 88 Tarea: Elaborar Notas de Lanzamiento 88

Rol Responsable: Líder del Proyecto. Descripción: Se desarrolla la información detallada de la versión del sistema que está siendo entregado al cliente que, esta complementa la documentación principal del sistema. Artefacto(s) de Entrada: •

Plan de Implantación.

Artefacto(s) de Salida: •

Notas de Lanzamiento.

Tabla 89 Tarea: Gestionar las Pruebas Beta 89

Rol Responsable: Líder del Proyecto. Descripción: En esta tarea se recopilan y gestionan las observaciones encontradas por los usuarios que han empleado la versión beta del producto y han notificado algún error que emite el sistema al ejecutar una determinada función. Se debe comprobar la existencia de los errores notificados y de ser afirmativos se debe generar las Solicitud de Cambio correspondientes. Artefacto(s) de Entrada: •

Mecanismo de Retroalimentación.

•

Plan de Implantación.

•

El Sistema (Unidad de Implantación).

Artefacto(s) de Salida: •

Solicitud de Cambio.

Tabla 90 Tarea: Probar el Producto Beta 90

Rol Responsable: Líder del Proyecto.

199

MeRinde Guía Detallada Descripción: En esta tarea los involucrados deben probar las funcionalidades ofrecidas dentro del Producto Beta con el fin de que estos comenten la experiencia obtenida al usar el mismo. Artefacto(s) de Entrada: •

Mecanismo de Retroalimentación.

•

El Sistema (Unidad de Implantación).

Artefacto(s) de Salida: •

Mecanismo de Retroalimentación.

Tabla 91 Tarea: Agrupar las Unidades de Implantación 91

Rol Responsable: Involucrados. Descripción: En esta tarea se contempla el empaquetamiento de los componentes del sistema que están destinados a ser implantados y concedidos al cliente. Artefacto(s) de Entrada: •

El Sistema (Unidades de Implantación).

Artefacto(s) de Salida: •

El Sistema.

200

MeRinde Guía Detallada Tabla 92 Tarea: Verificar manufactura del Producto 92

Rol Responsable: Involucrados. Descripción: En esta tarea se verifica el procedimiento de producción en masa del sistema, para su posterior distribución a los clientes. Artefacto(s) de Entrada: •

El Sistema.

Artefacto(s) de Salida: •

El Sistema.

Tabla 93 Tarea: Proveer Acceso al Sitio de Descarga 93

Rol Responsable: Involucrados. Descripción: Esta tarea tiene como objetivo habilitar para los clientes un sitio Web para la descarga de los contenidos del sistema. Artefacto(s) de Entrada: •

Plan de Implantación.

•

El Sistema (Unidades de Implantación).

Artefacto(s) de Salida: •

El Sistema (Unidades de Implantación).

201

MeRinde Guía Detallada Gestión de Configuración y Cambios Actividades Gestionar los Cambios de Requerimientos: Esta actividad asegura que los impactos que se puedan generar producto de cambios en el proyecto sean considerados y busca establecer los mecanismos para gestionar adecuadamente estos cambios. Está conformada por las siguientes tareas: • Enviar Solicitud de Cambios • Confirmar Cambios en el Sistema • Revisar Solicitudes de Cambio • Confirmar Duplicados o Rechazar Cambios de Requerimientos • Programar y Asignar el Trabajo Planear la Configuración del Proyecto y el Control de Cambios: Esta actividad establece un plan apropiado para gestionar y controlar los cambios sobre los artefactos que son desarrollados durante el proceso de desarrollo de software. Está conformada por las siguientes tareas: • Escribir el Plan de Gestión de Configuración • Establecer las Políticas de Gestión de Configuración • Establecer los Procesos de Control de Cambios Registrar y Almacenar los Cambios: Esta actividad asegura que los cambios realizados al sistema, documentación, recursos, fechas, planes, etc. sean registrados y que el repositorio de versiones sea actualizado.

202

MeRinde Guía Detallada Está conformada por la siguiente tarea: • Guardar y Registrar Cambios Tareas Tabla 94 Tarea: Enviar Solicitud de Cambios 94

Rol Responsable: Involucrados. Descripción: Consiste en que cualquier involucrado en el proyecto pueda notificar al equipo del proyecto sobre cualquier riesgo-problema que sea observable en el sistema en elaboración. Artefacto(s) de Entrada: No Aplica. Artefacto(s) de Salida: •

Solicitud de Cambio.

Tabla 95 Tarea: Confirmar Cambios en el Sistema 95

Rol Responsable: Analista de Calidad. Descripción: En esta tarea se verifica que los cambios en el Sistema que han sido aprobados se hayan completados. Artefacto(s) de Entrada: •

Componente Operacional del Sistema.

•

Solicitud de Cambio.

Artefacto(s) de Salida: •

Solicitud de Cambio.

•

Registro de Evaluación.

Tabla 96 Tarea: Revisar Solicitudes de Cambio 96

Rol Responsable: Líder del Proyecto. 203

MeRinde Guía Detallada Descripción: En esta tarea se examinan todas aquellas solicitudes de cambio recibidas. Artefacto(s) de Entrada: •

Plan de Iteración.

•

Solicitud de Cambio.

Artefacto(s) de Salida: •

Solicitud de Cambio.

Tabla 97 Tarea: Confirmar Duplicados o Rechazar Cambios de Requerimientos 97

Rol Responsable: Líder del Proyecto. Descripción: Una vez examinada cada una de las solicitudes de cambio se procede a verificar que el cambio sugerido no ha sido ya solventado por alguna solicitud anteriormente recibida y aprobada, adicionalmente de no ser conveniente o incorrecta una solicitud de cambio recibida se colocan en estado de rechazado dichas solicitudes. Artefacto(s) de Entrada: •

Solicitud de Cambio.

Artefacto(s) de Salida: •

Solicitud de Cambio.

Tabla 98 Tarea: Programar y Asignar el Trabajo 98

Rol Responsable: Líder del Proyecto. Descripción: En esta tarea se incorpora dentro de la planificación que se tiene estimada para el proyecto las actividades necesarias para llevar a cabo cualquier cambio considerado en las Solicitudes de Cambio que han sido aprobados para incorporarse en el sistema. Artefacto(s) de Entrada: •

Planificación del Proyecto. 204

MeRinde Guía Detallada •

Plan de Iteración.

Artefacto(s) de Salida: •

Planificación del Proyecto.

•

Plan de Iteración.

•

Orden de Trabajo.

Tabla 99 Tarea: Escribir el Plan de Gestión de Configuración 99

Rol Responsable: Líder del Proyecto. Descripción: Se debe desarrollar el Plan de Gestión de Configuración a fin de describir todas las actividades de Gestión de Configuración y Cambios que serán realizadas durante todo el ciclo de vida del proyecto. Artefacto(s) de Entrada: •

Planificación del Proyecto.

Artefacto(s) de Salida: •

Plan de Gestión de Configuración.

Tabla 100 Tarea: Establecer las Políticas de Gestión de Configuración 100

Rol Responsable: Líder del Proyecto. Descripción: Se debe establecer los mecanismos que serán empleados para gestionar las actividades de Configuración y Cambios que serán realizadas durante todo el ciclo de vida del proyecto, entre las cuales se pueden tener los procedimientos para archivar, identificar, categorizar, etc. Artefacto(s) de Entrada: •

Planificación del Proyecto.

Artefacto(s) de Salida: •

Plan de Gestión de Configuración.

205

MeRinde Guía Detallada Tabla 101 Tarea: Establecer los Procesos de Control de Cambios 101

Rol Responsable: Líder del Proyecto. Descripción: Se identifica cuales van a ser los procedimientos a seguir para gestionar los cambios que se puedan llegar a presentar para el proyecto. Artefacto(s) de Entrada: •

Planificación del Proyecto.

Artefacto(s) de Salida: •

Plan de Gestión de Configuración.

Tabla 102 Tarea: Guardar y Registrar Cambios 102

Rol Responsable: Líder del Proyecto. Descripción: Durante esta tarea se registran y se guardan en un repositorio de versiones, los cambios hechos no sólo al sistema, sino también a los documentos, planes, los recursos, las fechas, imágenes, etc. Artefacto(s) de Entrada: •

Artefactos del Proyecto.

•

Repositorio de Versiones.

Artefacto(s) de Salida: No Aplica.

Gestión del Proyecto Actividades Concebir un Nuevo Proyecto: En esta actividad se trae el proyecto desde una idea inicial hasta un punto en que se es capaz de tomar una decisión inicial y razonada para evaluar si se decide continuar o abandonar el proyecto. 206

MeRinde Guía Detallada

Está conformada por las siguientes tareas: • Elaborar Solicitud del Sistema • Desarrollar Términos de Referencia • Identificar y Evaluar los Riesgos • Iniciar el Proyecto Evaluar el Alcance y los Riesgos del Proyecto: En esta actividad se revalúa el alcance y los riesgos del proyecto y se actualiza el caso de negocio. Está conformada por las siguientes tareas: • Determinar el Alcance del Sistema • Identificar y Evaluar los Riesgos Planear el Proyecto: Esta actividad desarrolla los documentos y componentes necesarios para la planificación del proyecto. Está conformada por las siguientes tareas: • Planear las Fases y las Iteraciones • Definir la Organización del Proyecto y del Personal • Selección y Contratación del Personal de Desarrollo • Desarrollar el Plan de Gestión de Riesgos • Definir los Mecanismos de Monitoreo y Control del Proceso • Determinar los Aspectos Técnicos a Evaluar para la Selección del Contratista • Revisar la Planificación del Proyecto Planear el Resto de la Iteración Inicial: Esta actividad permite refinar el plan de la iteración inicial.

207

MeRinde Guía Detallada Está conformada por las siguientes tareas: • Desarrollar el Plan de Iteración • Revisar el Plan de Iteración Gestionar Iteración: Esta actividad contiene las actividades que empiezan, terminan y revisan una iteración. Está conformada por las siguientes tareas: • Iniciar Iteración • Revisar los Criterios de Evaluación de la Iteración • Identificar y Evaluar los Riesgos Revaluar el Alcance y los Riesgos del Proyecto: Esta actividad revalúa el alcance y los riegos del proyecto. Está conformada por las siguientes tareas: • Determinar el Alcance del Sistema • Identificar y Evaluar los Riesgos Cerrar- Salir del Proyecto: En esta actividad, el líder del proyecto prepara el proyecto para su cierre. Está conformada por las siguientes tareas: • Preparar Cierre-Salida para el Proyecto • Evaluar la Aceptación del Proyecto Cerrar- Salir de la Fase: En esta actividad, el líder del proyecto cierra la fase asegurando que se han conseguido los objetivos de la fase. Está conformada por las siguientes tareas: • Preparar Cierre-Salida para la Fase 208

MeRinde Guía Detallada • Supervisar los Hitos del Ciclo de Vida Planificar la Próxima Iteración: Esta actividad crea un plan de iteración detallado para controlar la próxima iteración. Está conformada por las siguientes tareas: • Desarrollar el Plan de Iteración • Revisar el Plan de Iteración Refinar la Planificación del Proyecto: Esta actividad refina la planificación del proyecto. Está conformada por las siguientes tareas: • Planear las Fases y las Iteraciones • Definir la Organización del Proyecto y del Personal • Selección y Contratación del Personal de Desarrollo • Desarrollar el Plan de Gestión de Riesgos • Definir los Mecanismos de Monitoreo y Control del Proceso • Determinar los Aspectos Técnicos a Evaluar para la Selección del Contratista • Revisar la Planificación del Proyecto Monitorear y Controlar el Proyecto: Esta actividad capta el trabajo diario y continuo del líder del proyecto, incluyendo el monitoreo del estado del proyecto, informar a grupos de involucrados y resolución de problemas. Está conformada por las siguientes tareas: • Organizar Evaluación • Conducir Evaluación del Proyecto • Conducir Evaluación del Proceso de Desarrollo • Programar y Asignar el Trabajo 209

MeRinde Guía Detallada • Monitorear el Estado del Proyecto • Solventar Problemas Tareas Tabla 103 Tarea: Elaborar Solicitud del Sistema 103

Rol Responsable: Involucrados. Descripción: Esta es la primera tarea que da inicio al proceso de desarrollo de un sistema. Artefacto(s) de Entrada: No Aplica. Artefacto(s) de Salida: •

Solicitud del Sistema.

Tabla 104 Tarea: Desarrollar Términos de Referencia 104

Rol Responsable: Involucrados. Descripción: En esta tarea se elabora el artefacto Términos de Referencia del Sistema, el cual contiene una descripción del sistema a realizar. Artefacto(s) de Entrada: •

Solicitud del Sistema.

Artefacto(s) de Salida: •

Términos de Referencia del Sistema.

Tabla 105 Tarea: Identificar y Evaluar los Riesgos 105

Rol Responsable: Involucrados. Descripción: En esta tarea se deben estimar los posibles riesgos a los que está expuesto

210

MeRinde Guía Detallada el proyecto en desarrollo, adicionalmente se deben analizar, priorizar y determinar una estrategia para minimizar el impacto que estos puedan llegar a tener. Artefacto(s) de Entrada: No Aplica. Artefacto(s) de Salida: •

Registro de Riesgos.

Tabla 106 Tarea: Iniciar el Proyecto 106

Rol Responsable: Líder del Proyecto. Descripción: En esta tarea se establecen los criterios iníciales que se estiman serán necesarios para llevar a cabo el proyecto. Artefacto(s) de Entrada: •

Términos de Referencia del Sistema.

Artefacto(s) de Salida: •

Planificación del Proyecto.

Tabla Tarea: Determinar el Alcance del Sistema Rol Responsable: Líder del Proyecto. Descripción: En esta tarea se establece en el artefacto Términos de Referencia del Sistema los aspectos a ser abarcados y desarrollados en el proyecto a realizar. Artefacto(s) de Entrada: •

Términos de Referencia del Sistema.

Artefacto(s) de Salida: •

Términos de Referencia del Sistema

211

MeRinde Guía Detallada Tabla 107 Tarea: Planear las Fases y las Iteraciones 107

Rol Responsable: Líder del Proyecto. Descripción: En esta tarea se debe determinar el conjunto de fases e iteraciones que serán consideradas para el proyecto, además se debe estimar sus objetivos y duración. Artefacto(s) de Entrada: •

Términos de Referencia del Sistema.

•

Registro de Riesgos.

•

Marco de Desarrollo.

Artefacto(s) de Salida: •

Planificación del Proyecto.

Tabla 108 Tarea: Definir la Organización del Proyecto y del Personal 108

Rol Responsable: Líder del Proyecto. Descripción: En esta tarea se debe estimar los recursos humanos necesarios para el proyecto, adicionalmente se debe estimar como serán distribuidos los mismos. Artefacto(s) de Entrada: •

Términos de Referencia del Sistema.

•

Registro de Riesgos.

Artefacto(s) de Salida: •

Planificación del Proyecto.

•

Licitación del Personal.

Tabla 109 Tarea: Selección y Contratación del Personal de Desarrollo 109

Rol Responsable: Líder del Proyecto. Descripción: Esta tarea se ejecuta cuando se va a trabajar con personal externo a la organización. En esta se evalúan según unos criterios definidos por la organización a

212

MeRinde Guía Detallada los grupos de contratistas que postulen sus servicios para el desarrollo del proyecto. Posteriormente se procede a la contratación y al establecimiento de los aspectos legales necesarios para acordar las responsabilidades entre las partes. Artefacto(s) de Entrada: •

Calificación de los Aspectos Técnicos de los Servicios de Desarrollo de Sistemas.

•

Oferta de Servicio del Personal.

•

Planificación del Proyecto.

Artefacto(s) de Salida: •

Términos de Referencia para el Equipo de Desarrolladores del Sistema.

Tabla 110 Tarea: Desarrollar el Plan de Gestión de Riesgos 110

Rol Responsable: Líder del Proyecto. Descripción: Se debe establecer un plan donde se debe contemplar los riesgos que sean identificados para el proyecto, adicionalmente dicho plan puede contener las descripciones, análisis, prioridades y estrategias que sirvan para minimizar el impacto que los riesgos puedan llegar a tener. Artefacto(s) de Entrada: •

Registro de Riesgos.

Artefacto(s) de Salida: •

Plan de Gestión de Riesgos.

Tabla 111 Tarea: Definir los Mecanismos de Monitoreo y Control del Proceso 111

Rol Responsable: Líder del Proyecto. Descripción: Se deben establecer los mecanismos que permitirán evaluar y supervisar continuamente el proceso de desarrollo del proyecto. Artefacto(s) de Entrada: 213

MeRinde Guía Detallada No Aplica. Artefacto(s) de Salida: •

Planificación del Proyecto.

Tabla 112 Tarea: Determinar los Aspectos Técnicos a Evaluar para la Selección del Contratista 112

Rol Responsable: Involucrados. Descripción: Esta tarea se ejecuta cuando se va a trabajar con personal externo a la organización. Se debe determinar un mecanismo que permita a la organización hacer un proceso de selección de contratistas conforme a las necesidades del proyecto y a los recursos que se tengan disponibles. Artefacto(s) de Entrada: No Aplica. Artefacto(s) de Salida: •

Calificación de los Aspectos Técnicos de los Servicios de Desarrollo de Sistemas.

Tabla 113 Tarea: Revisar la Planificación del Proyecto 113

Rol Responsable: Analista de Calidad. Descripción: En esta tarea se supervisa la planificación que ha sido estimada para el proceso de desarrollo del sistema, adicionalmente se pude emitir cualquier observación necesaria para mejorar el mismo. Artefacto(s) de Entrada: •

Planificación del Proyecto.

Artefacto(s) de Salida: •

Registro de Evaluación.

214

MeRinde Guía Detallada Tabla 114 Tarea: Desarrollar el Plan de Iteración 114

Rol Responsable: Líder del Proyecto. Descripción: El objetivo de esta tarea es planificar detalladamente para cada iteración a realizarse el conjunto de tareas, actividades y recursos que serán empleados. Artefacto(s) de Entrada: •

Planificación del Proyecto.

•

Registro de Riesgos.

•

Marco de Desarrollo.

Artefacto(s) de Salida: •

Plan de Iteración.

Tabla 115 Tarea: Revisar el Plan de Iteración 115

Rol Responsable: Analista de Calidad. Descripción: En esta tarea se supervisa la planificación que ha sido estimada para una iteración del ciclo de vida de desarrollo del sistema, adicionalmente se pude emitir cualquier observación necesaria para mejorar la misma. Artefacto(s) de Entrada: •

Plan de Iteración.

•

Registro de Riesgos.

Artefacto(s) de Salida: •

Registro de Evaluación.

Tabla 116 Tarea: Iniciar Iteración 116

Rol Responsable: Líder del Proyecto. Descripción: Con esta tarea el recurso humano asignado al proyecto da inicio al conjunto de actividades estimadas dentro del Plan de Iteración vigente.

215

MeRinde Guía Detallada Artefacto(s) de Entrada: •

Plan de Iteración.

•

Planificación del Proyecto.

Artefacto(s) de Salida: •

Orden de Trabajo.

Tabla 117 Tarea: Revisar los Criterios de Evaluación de la Iteración 117

Rol Responsable: Analista de Calidad. Descripción: En esta tarea se supervisa los criterios considerados para determinar el progreso del proyecto al final de la iteración, adicionalmente se pude emitir cualquier observación necesaria para mejorar estos. Artefacto(s) de Entrada: •

Plan de Iteración.

•

Planificación del Proyecto.

Artefacto(s) de Salida: •

Registro de Evaluación.

Tabla 118 Tarea: Preparar Cierre-Salida para el Proyecto 118

Rol Responsable: Líder del Proyecto. Descripción: En esta tarea se deben completar los requerimientos formales establecidos para el cierre-salida del proyecto, se debe verificar la aceptación del proyecto, la reasignación de los recursos, el traslado de responsabilidades de desarrollo y soporte, entre otros. Artefacto(s) de Entrada: •

Planificación del Proyecto.

Artefacto(s) de Salida: •

Planificación del Proyecto. 216

MeRinde Guía Detallada •

Registro de Evaluación.

Tabla 119 Tarea: Evaluar la Aceptación del Proyecto 119

Rol Responsable: Analista de Calidad. Descripción: Se debe verificar y revisar que se hayan cumplido satisfactoriamente todos los pasos establecidos para la aceptación por parte del cliente del sistema y de todos sus entregables. Artefacto(s) de Entrada: •

Planificación del Proyecto.

Artefacto(s) de Salida: •

Registro de Evaluación.

Tabla 120 Tarea: Preparar Cierre-Salida para la Fase 120

Rol Responsable: Líder del Proyecto. Descripción: En esta tarea se debe preparar el proyecto para el cierre-salida de fase y se debe preparar los ajustes necesarios para proceder a la supervisión de los hitos planteados para la fase dentro del ciclo de vida de desarrollo del sistema. Artefacto(s) de Entrada: •

Planificación del Proyecto.

Artefacto(s) de Salida: •

Planificación del Proyecto.

•

Registro de Evaluación.

Tabla 121 Tarea: Supervisar los Hitos del Ciclo de Vida 121

Rol Responsable: Analista de Calidad. Descripción: Se debe verificar y revisar que se hayan alcanzado todos los hitos 217

MeRinde Guía Detallada planificados para el fin de la fase. Adicionalmente se pude emitir cualquier observación necesaria para mejorar el proceso tanto para otra fase del proyecto como para otro proyecto. Artefacto(s) de Entrada: •

Planificación del Proyecto.

Artefacto(s) de Salida: •

Registro de Evaluación.

Tabla 122 Tarea: Conducir Evaluación del Proyecto 122

Rol Responsable: Analista de Calidad. Descripción: Esta tarea representa el conjunto de revisiones continuas que puede ejecutar el Analista de Calidad a fin de evaluar cómo se están llevando a cabo las actividades planificadas para una iteración. Adicionalmente se pude emitir cualquier observación necesaria para mejorar el proceso de desarrollo del proyecto. Artefacto(s) de Entrada: •

Plan de Iteración.

Artefacto(s) de Salida: •

Registro de Evaluación.

Tabla 123 Tarea: Conducir Evaluación del Proceso de Desarrollo 123

Rol Responsable: Mentor. Descripción: Esta tarea representa el conjunto de revisiones continuas que puede ejecutar el Mentor a fin de evaluar cómo se está desarrollando y siguiendo el proceso de desarrollo planificado para el proyecto y también sirve para medir la calidad en general con la que está siendo llevado el proceso de desarrollo. Adicionalmente se pude emitir cualquier observación necesaria para mejorar el proceso de desarrollo del proyecto.

218

MeRinde Guía Detallada Artefacto(s) de Entrada: •

Plan de Iteración.

•

Planificación del Proyecto.

•

Marco de Desarrollo.

Artefacto(s) de Salida: •

Registro de Evaluación.

Tabla 124 Tarea: Organizar Evaluación 124

Rol Responsable: Involucrados. Descripción: Esta tarea representa el conjunto de revisiones que puede ejecutar cualquier involucrado en el desarrollo del proyecto a fin de evaluar cómo se está desarrollando y siguiendo el proceso de desarrollo y las actividades planificadas para la iteración. Adicionalmente se pude emitir cualquier observación necesaria para mejorar el proceso de desarrollo del proyecto. Artefacto(s) de Entrada: •

Plan de Iteración.

Artefacto(s) de Salida: •

Registro de Evaluación.

Tabla 125 Tarea: Monitorear el Estado del Proyecto 125

Rol Responsable: Líder del Proyecto. Descripción: Esta tarea representa el conjunto de revisiones continuas que puede ejecutar el Líder del Proyecto a fin de evaluar el estado actual del proyecto conforme a lo que está planificado. Adicionalmente se pude emitir cualquier observación necesaria para mejorar el proceso de desarrollo del proyecto. Artefacto(s) de Entrada: •

Planificación del Proyecto.

•

Registro de Riesgos.

219

MeRinde Guía Detallada Artefacto(s) de Salida: •

Registro de Riesgos.

•

Registro de Evaluación.

Tabla 126 Tarea: Solventar Problemas 126

Rol Responsable: Líder del Proyecto. Descripción: Esta tarea abarca solventar todos aquellos problemas a los cuales se enfrentara el proyecto, los cuales pueden llegar a surgir durante cualquier momento en el ciclo de vida de desarrollo del sistema. Artefacto(s) de Entrada: No Aplica. Artefacto(s) de Salida: •

Orden de Trabajo.

Tabla 127 Tarea: Programar y Asignar el Trabajo 127

Rol Responsable: Líder del Proyecto. Descripción: En esta tarea se incorpora dentro de la planificación que se tiene estimada para el proyecto las actividades necesarias para llevar a cabo cualquier cambio considerado en las Solicitudes de Cambio que han sido aprobados para incorporarse en el sistema. Artefacto(s) de Entrada: •

Planificación del Proyecto.

•

Plan de Iteración.

Artefacto(s) de Salida: •

Planificación del Proyecto.

•

Plan de Iteración.

•

Orden de Trabajo.

220

MeRinde Guía Detallada

Gestión del Ambiente Actividades Preparar el Ambiente para el Proyecto: En esta actividad se prepara el ambiente para el desarrollo de un proyecto, incluye tanto el proceso como las herramientas. Está conformada por las siguientes tareas: • Elaborar el Marco de Desarrollo del Proyecto • Determinar los Lineamientos del Proyecto • Adaptar el Marco de Desarrollo para el Proyecto • Preparar las Plantillas para el Proyecto • Seleccionar y Adquirir Herramientas Preparar el Ambiente para una Iteración: Esta actividad consiste en preparar el ambiente de desarrollo del proyecto para la iteración en curso, incluye tanto el proceso como las herramientas. Está conformada por las siguientes tareas: • Elaborar el Marco de Desarrollo del Proyecto • Determinar los Lineamientos del Proyecto • Preparar las Plantillas para el Proyecto • Configurar las Herramientas • Verificar la Instalación y Configuración de las Herramientas Apoyar el Ambiente durante una Iteración: Esta actividad permite apoyar el ambiente para el desarrollo de un proyecto durante la iteración en curso, incluye tanto el proceso como las herramientas. 221

MeRinde Guía Detallada

Está conformada por la siguiente tarea: • Apoyar el Desarrollo Tareas Tabla 128 Tarea: Elaborar el Marco de Desarrollo del Proyecto 128

Rol Responsable: Involucrados. Descripción: En esta tarea se debe desarrollar el Marco de Desarrollo a fin de ajustar la configuración de la metodología para el desarrollo de software a las necesidades del proyecto que se va a ejecutar. Artefacto(s) de Entrada: No Aplica. Artefacto(s) de Salida: •

Marco de Desarrollo.

Tabla 129 Tarea: Determinar los Lineamientos del Proyecto 129

Rol Responsable: Involucrados. Descripción: En esta tarea se establecen las directrices que serán consideradas para ejecutar determinadas tareas durante el proyecto. Artefacto(s) de Entrada: No Aplica. Artefacto(s) de Salida: •

Marco de Desarrollo (Lineamientos del Proyecto).

222

MeRinde Guía Detallada Tabla 130 Tarea: Adaptar el Marco de Desarrollo para el Proyecto 130

Rol Responsable: Involucrados. Descripción: En esta tarea el Marco de Desarrollo es ajustado conforme a las necesidades del proyecto que se va a ejecutar. Artefacto(s) de Entrada: •

Marco de Desarrollo.

•

Términos de Referencia del Sistema.

Artefacto(s) de Salida: •

Marco de Desarrollo.

Tabla 131 Tarea: Preparar las Plantillas para el Proyecto 131

Rol Responsable: Involucrados. Descripción: En esta tarea las plantillas destinadas a ser usadas por los desarrolladores del sistema deben ser ajustadas conforme a las necesidades del proyecto que se va a ejecutar. Artefacto(s) de Entrada: •

Marco de Desarrollo.

Artefacto(s) de Salida: •

Plantillas del Proyecto.

Tabla 132 Tarea: Seleccionar y Adquirir Herramientas 132

Rol Responsable: Involucrados. Descripción: Durante esta tarea se seleccionan y adquieren las herramientas necesarias para el proceso de desarrollo del proyecto. Artefacto(s) de Entrada: •

Marco de Desarrollo.

223

MeRinde Guía Detallada Artefacto(s) de Salida: •

Infraestructura de Desarrollo (Herramientas).

Tabla 133 Tarea: Configurar las Herramientas 133

Rol Responsable: Involucrados. Descripción: Durante esta tarea las herramientas que se emplearan para el proceso de desarrollo del proyecto serán ajustadas conforme a las necesidades del proyecto que se va a ejecutar. Artefacto(s) de Entrada: •

Infraestructura de Desarrollo (Herramientas).

Artefacto(s) de Salida: •

Infraestructura de Desarrollo (Herramientas).

Tabla 134 Tarea: Verificar la Instalación y Configuración de las Herramientas 134

Rol Responsable: Involucrados. Descripción: Durante esta tarea se verifica que las herramientas que se emplearan para el proceso de desarrollo del proyecto están ajustadas conforme a las necesidades del proyecto que se va a ejecutar. Artefacto(s) de Entrada: •

Infraestructura de Desarrollo (Herramientas).

Artefacto(s) de Salida: •

Registro de Evaluación.

Tabla 135 Tarea: Apoyar el Desarrollo 135

Rol Responsable: Involucrados. Descripción: Durante esta tarea se verifica que la Infraestructura de Desarrollo que se 224

MeRinde Guía Detallada prevea para el desarrollo del sistema este ajustada y con los recursos necesarios conforme a las especificaciones del proyecto. Artefacto(s) de Entrada: •

Infraestructura de Desarrollo.

Artefacto(s) de Salida: •

Infraestructura de Desarrollo.

225

MeRinde Guía Detallada

APÉNDICE C LLENADO DE LAS PLANTILLAS

226

MeRinde Guía Detallada Llenado de las plantillas Las plantillas son un conjunto predefinido de formas que establece la estructura necesaria para crear contenido rápidamente. Para aquellos que empiezan elaborar artefactos con una página en blanco, puede ser demasiado trabajo y es fácil olvidar partes importantes. En MeRinde se proporcionan una serie de plantillas orientadas a facilitar el conocimiento que se debe tener acerca de la información fundamental que debe reflejar cada artefacto. Estas plantillas proveen un punto partida para los documentos utilizados en proyectos de desarrollo de software. Utilizando plantillas puede ayudar a los desarrolladores a trabajar más rápido, pero también ayudarán a evitar discusiones y a evitar pasar por alto problemas importantes. Estas plantillas no son universales y no intentan proveer guías prescriptivas en el proceso general de desarrollo. Las plantillas pueden ser llenadas en la secuencia sugerida o en cualquier secuencia que se ajuste a sus procesos existentes. Las plantillas se encuentran disponibles para la descarga a través de www.merinde.rinde.gob.ve/index.php?option=com_remository&Itemid=37 Las plantillas se distribuyen bajo la licencia de Documentación Libre de GNU, sin restricciones adicionales. Es libre de copiar, distribuir y modificar este texto según los términos de esta licencia. El texto completo de la licencia puede consultarse en la URL http://www.gnu.org/copyleft/fdl.es.html El objetivo de este apéndice es servir de guía para la instalación y uso de las plantillas de los productos de la Metodología para el Desarrollo de Software del CNTI.

227

MeRinde Guía Detallada Paso 1. Obtener las plantillas. Las plantillas de los artefactos correspondientes a la Metodología se pueden conseguir

en

la

siguiente

dirección:

https://www.merinde.rinde.gob.ve/index.php?option=com_remository&Itemid=37 Adicionalmente desde el portal web de la metodología se pueden descargar los artefactos individualmente desde el portal dedicado a cada uno de ellos, visite la siguiente

dirección:

http://merinde.no-

ip.info/index.php?option=com_remository&Itemid=37&func=select&id=1 Paso 2. Instalación. Descomprima el archivo con extensión ZIP ó TAR si se ha descargado todos los artefactos. Para poder utilizar las plantillas se recomienda emplear OpenOffice.org 2.0 o superior, específicamente su procesador de textos Writer, herramienta con la cual se podrá manipular los artefactos y utilizarlos indistintamente bajo plataformas GNU Linux, Microsoft Windows, Apple Mac OS X o Sun Solaris, sin tener que convertir los documentos. Así mismo los artefactos también están disponibles para ser editados con Office 2000 o superior. OpenOffice.org puede ser conseguido gratuitamente desde la siguiente dirección electrónica: http://es.openoffice.org/ Adicionalmente los artefactos están disponibles en Formato de Documento Portátil (PDF), con el fin de que los artefactos puedan ser visualizados con diversas herramientas disponibles para plataformas GNU Linux, Microsoft Windows y Apple Mac, sin que se modifiquen ni el aspecto ni la estructura del documento original.

228

MeRinde Guía Detallada Paso 3. Uso. Para comenzar a emplear los artefactos abra la herramienta de su preferencia, selección el menú archivo y haga clic sobre abrir, este proceso debe abrir un explorador de archivos desde el cual se debe indicar la ruta donde se encuentran almacenado el artefacto que desea utilizar. Para personalizar los campos automáticos de los artefactos (campos con fondo gris) en OpenOffice.org Writer, debe seleccionar Archivo>Propiedades y en la pestaña descripción sustituya los campos de Título, Tema y Comentarios por la información apropiada para este documento.

Después de cerrar el diálogo, los

campos automáticos serán actualizados automáticamente. Para actualizar la numeración del Índice de Contenido haga clic derecho sobre este campo automático y luego clic en Actualizar Índice/Tabla.

Vea la ayuda del OpenOffice.org para más

información sobre el trabajo con campos. Una vez abierto el artefacto solo queda completarlo, para ello se dispone en cada sección de este una serie de instrucciones sobre su uso. Es recomendable que antes de comenzar a utilizar cualquiera de los artefactos se lea este documento. Paso 4. Rellenando las plantillas Todos los artefactos tienen algunas de sus secciones en común, las cuales pasaremos a estudiar con detenimiento. Historial de Revisiones Se trata de una tabla que contiene los distintos cambios que se han realizado sobre el documento. En concreto hay que señalar a que versión del sistema corresponde el cambio, hay que poner la fecha, una muy breve descripción del cambio y el o los autores.

229

MeRinde Guía Detallada Índice de Contenido Índice del documento. Se rellena automáticamente, no tocar. Para actualizar la numeración ó el contenido del Índice de Contenido haga clic derecho sobre este campo automático y luego clic en Actualizar Índice/Tabla. Introducción Todos los artefactos tienen una introducción para indicar para qué sirven. Esta sección está compuesta por los siguientes aspectos: Objetivo El propósito del documento. Alcance Se refiere a una definición específica de las áreas, procesos, etc. que van a ser afectadas por el artefacto y sus resultados. Definiciones, Acrónimos y Abreviaturas Se trata de un pequeño glosario específico de este documento. Documentos Relacionados Lista de documentos que son referenciados en éste artefacto que aportan información relevante y que ya han sido elaborados.

230