MeRinde+Guía+Detallada+V1 0

Centro Nacional de Tecnologas de Informacin
METODOLOGA DE LA RED NACIONAL DE INTEGRACIN Y DESARROLLO DE SOFTWARE LIBRE (MeRinde)
Gua Detallada
Este documento describe las caractersticas principales y la estructura de la metodologa
Autores:

Carlos David Marrero. Kiberley Kristal. Santos Rosillo.
MeRinde Gua Detallada
LICENCIA
Copyright (C) 2007 CNTI. Todos los derechos reservados. El material escrito que se distribuye estan bajo la licencia de Documentacin Libre de GNU, sin restricciones adicionales. Es libre de copiar, distribuir y modificar este texto segn los trminos de esta licencia. El texto completo de la licencia puede consultarse en la URL http://www.gnu.org/copyleft/fdl.es.html
TABLA DE CONTENIDOS
Pgina COLABORADORES.................................................................................................... 5 INTRODUCCIN.........................................................................................................6 JUSTIFICACIN..........................................................................................................7 AUDIENCIA.................................................................................................................9 METODOLOGA PROPUESTA................................................................................10 Mejores Prcticas Implementadas en la Metodologa.......................................... 10 Estructura del Proceso de MeRinde......................................................................19 Mantenimiento .....................................................................................................20 Fundamentos de MeRinde.................................................................................... 22 ESTRUCTURA DINMICA DE LA METODOLOGA.......................................... 24 Fases de la Metodologa....................................................................................... 24 Inicio...............................................................................................................25 Elaboracin.....................................................................................................26 Construccin...................................................................................................27 Transicin....................................................................................................... 28 ESTRUCTURA ESTTICA DE LA METODOLOGA........................................... 31 Roles Definidos en la Metodologa...................................................................... 32 Descripcin de los Roles................................................................................ 34 El Modelo de Equipo para Proyectos............................................................. 38 Artefactos..............................................................................................................40 Descripcin de los Artefactos de la Metodologa...........................................40 Artefactos Compuestos ..................................................................................44 Disciplinas de la Metodologa.............................................................................. 45 Modelado del Negocio................................................................................... 47 Implementacin.............................................................................................. 52 Pruebas........................................................................................................... 54 Implantacin................................................................................................... 57 Gestin de Configuracin y Cambios.............................................................59 Gestin del Proyecto.......................................................................................61 Gestin del Ambiente .................................................................................... 64 Marco de Desarrollo de MeRinde........................................................................ 66 APORTES, VENTAJAS Y DESVENTAJAS DE LA METODOLOGA................. 70 Aportes de la Metodologa................................................................................... 70 Ventajas de la Metodologa.................................................................................. 73 3
MeRinde Gua Detallada Desventajas de la Metodologa.............................................................................76 SNTESIS DE LA METODOLOGA MERINDE.................................................... 77 REFERENCIAS BIBLIOGRFICAS........................................................................ 83 APNDICES............................................................................................................... 84 DESCRIPCIN DE LOS ARTEFACTOS PROPUESTOS DE MERINDE ............ 85 DESCRIPCIN DE LAS ACTIVIDADES Y TAREAS .........................................142 PROPUESTAS DE MERINDE................................................................................ 142 LLENADO DE LAS PLANTILLAS........................................................................ 226 PLANTILLAS DEL HABILITADOR WEB............................................................231
COLABORADORES Lderes del Proyecto y Desarrolladores Carlos David Marrero Fernando Muro Henry Rivero Jasmin Snchez Esculpi Kiberley Kristal Santos Rosillo Odalis Pereira
Colaboradores del Proyecto Sin ninguno de ustedes hubiese sido posible llevar a cabo este trabajo: Kenyer Piadaktay Domnguez Martnez Mara Anglica Prez de Ovalles
INTRODUCCIN MeRinde es un proyecto de Software Libre (SL) que propone un estndar para el proceso de desarrollo de software que puede ser empleado y adaptado segn los requerimientos de cualquier comunidad u organizacin para el desarrollo de sistemas y adems para producir y mantener una librera de plantillas reutilizables para la ingeniera 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 ms rpido 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 documentacin de sus sistemas. Se aclara que el proceso propuesto y las plantillas no son universales y no intentan proveer guas 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 cdigos de los sistemas sino que tambin se compartan la documentacin como gua 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 diseo documental bibliogrfico, debido a que una buena parte de esta investigacin est sustentada en revisiones bibliogrficas de diversas fuentes y por un diseo de campo, para ello se emple las instalaciones del CNTI.
JUSTIFICACIN El software tiene un papel muy destacado en la sociedad dado los mltiples uso que a este se le puede dar, por lo que es importante garantizar mtodos claros en sus diferentes fases de produccin y explotacin. Diversas tendencias y metodologas de desarrollo de software han aparecido en aos recientes, buscando resolver los problemas que proyectos ms tradicionales, no han conseguido enfrentar. Entre ellas estn los frameworks de proyectos, las metodologas giles y los modelos de medicin de madurez. Junto con estos marcos de trabajo, ciertas estrategias especficas han permitido a los equipos de desarrollo producir software ms robusto, predecible, reutilizable y de fcil mantenimiento. En Venezuela, el CNTI como ente adscrito al Ministerio del Poder Popular para las Telecomunicaciones y la Informtica (MPPTI), noto que hacia falta involucrar para el desarrollo de sus proyectos de software equipos que hicieran uso de una metodologa y documentacin estandarizada, para alcanzar una trazabilidad entre documentos, seguir un mismo estndar 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 metodologa estndar 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 debera 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 metodologa estndar 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 definicin de roles y sus actividades a cumplir, motivo por el cual un individuo realiza determinadas tareas que no le corresponden o no le deberan corresponder, lo
MeRinde Gua Detallada cual implica un mayor nmero de errores en los sistemas y un mayor tiempo a ser empleado para poner en produccin un sistema. Los paquetes existentes de software para procesos de desarrollo y con plantillas de ingeniera de software son muy costosos, y estn limitadas por la autora 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 administracin pblica y en su rol tecnolgico que le compete se plante como uno de sus objetivos poder tener y ofrecer una metodologa, con una documentacin para el desarrollo de software que emplee un mismo patrn, que este basado en SL y estndares abiertos, que propicie un proceso de desarrollo y producto final de calidad.
AUDIENCIA Esta Metodologa 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 Tecnologas de Informacin (CNTI) y tambin a cualquier individuo, comunidad u organizacin 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, anlisis y diseo, implementacin, pruebas, implantacin, gestin de configuracin y cambios, gestin del proyecto y gestin del ambiente. Es til para analistas y usuarios finales (que especifican la estructura y comportamiento requeridos por el sistema), para los diseadores (que disean los sistemas que satisfacen esos requerimientos), para desarrolladores (que convierten esos diseos en cdigo ejecutable), para probadores (que verifican y validan la estructura y comportamiento del sistema) y para lderes del proyecto.
CAPTULO I METODOLOGA PROPUESTA
Para comenzar este captulo se procede a detallar la metodologa propuesta, sentado primero las mejores prcticas de desarrollo de software que sern implementadas y que servirn de lnea base para determinar cmo deber ser abordados los proyectos durante el ciclo de vida de desarrollo al emplear la presente propuesta metodolgica. Mejores Prcticas Implementadas en la Metodologa El proceso de software propuesto por MeRinde se inspira en catorce (14) mejores prcticas, 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 mximo los recursos disponibles de una forma eficaz y eficiente. A continuacin se listan las mejores prcticas consideradas:

Adaptar el proceso de desarrollo Alto nivel de abstraccin Centrarse en la arquitectura Cdigo estndar Colaboracin entre equipo Demostrar resultados iterativamente e incrementalmente Dirigido por Casos de Uso Diseo simple Enfoque continuo en la calidad Enfoque en los riesgos 10

Fomento del aprendizaje de experiencias Interaccin continua con cliente Modelar el software Permanecer gil y esperar los cambios.
Seguidamente se describir como cada una de las mejores prcticas listadas anteriormente ser implementada por la metodologa 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 representacin 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 ms grandes sean
requerirn 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 documentacin, la cantidad de revisiones, entro otros; pero fundamentalmente esto es proporcional al tamao del proyecto, la distribucin de los equipos de desarrollo, la cantidad de personas involucradas, la complejidad de las tecnologas 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 abstraccin: MeRinde favorece a que se tenga un alto nivel de abstraccin para reducir la complejidad y mejorar la comunicacin entre los 11
MeRinde Gua Detallada involucrados de los proyectos, a travs de la recomendacin de emplear herramientas de modelado de alto nivel como UML, el empleo de estndares abiertos, heredados y el empleo de software de cdigo libre. Centrarse en la arquitectura: MeRinde adems de empelar los Casos de Uso para guiar el proceso de desarrollo, presta especial atencin al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores durante la construccin y el mantenimiento. La arquitectura de los proyectos es representada a travs del modelo de las 4+1 vistas propuesto por Kruchten en 1995, con el fin de proveer una representacin arquitectnica estndar para que todos los involucrados en el desarrollo la puedan comprender, discutir y razonar. Adicionalmente al acuerdo de la representacin de la arquitectura, MeRinde provee un proceso para disear la arquitectura a travs 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 travs del ciclo de vida del sistema va refinando la arquitectura y hacindola ms robusta. Cdigo estndar: MeRinde propicia para las organizaciones el empleo de cdigo estndar dentro de las actividades de implementacin, a fin de favorecer la reduccin de la complejidad, la reutilizacin de componentes y que cualquier involucrado con los conocimientos pertinentes pueda entender, revisar y opinar sobre cualquier componente implementado. Colaboracin entre equipo: Esta prctica 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 comunicacin y la 12 el establecimiento temprano de la arquitectura, reutilizacin de componentes, sistemas
MeRinde Gua Detallada colaboracin 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 estn divididas en iteraciones, cuyo resultado es una versin ejecutable (hito secundario), el Objetivo de la metodologa con cada iteracin ser mitigar los riesgos de mayor a menor, donde el concepto de riesgo se refiere a ciertos casos de uso que son ms crticos a la hora de hacer el proyecto. La figura 1 seala como son representadas las iteraciones dentro de la metodologa.
Figura 1. Representacin Grfica de una Iteracin 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 iteracin 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 iteracin se analiza cuando termina. Se puede determinar si han aparecido nuevos requerimientos o han cambiado los existentes, afectando a las iteraciones siguientes.
13
MeRinde Gua Detallada Las actividades en MeRinde durante la planificacin de los detalles de cada una de las iteraciones permiten que el equipo examine cmo afectarn los riesgos que an quedan al trabajo en curso. Toda la retroalimentacin de una iteracin hecha permite reajustar los objetivos para las siguientes iteraciones. Esta dinmica contina hasta que se haya finalizado por completo con la versin actual del producto. MeRinde divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn 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 sern aquellas que impliquen mayores riesgos, ya que seguramente tendrn una fuerte influencia en la arquitectura del sistema o subsistema a construir y ayudarn a detectar en una fase temprana los problemas que retroalimentarn la siguiente Iteracin, donde sern resueltos. Las primeras iteraciones en un proyecto bajo MeRinde se deben enfocar hacia la comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto, la eliminacin de los riesgos crticos, 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 travs de un conjunto de actividades y define un artefacto fundamental llamado Plan de Iteracin y como soporte ofrece varios artefactos adicionales para la gestin de los riesgos. Para cada iteracin se selecciona algunos Casos de Uso, se refina su anlisis y diseo y se procede a su implementacin y pruebas. Se realiza una pequea espiral para cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementacin de la nueva versin del producto. En cada fase participan todas las disciplinas, pero que dependiendo de la fase el esfuerzo dedicado a una disciplina vara.
14
MeRinde Gua Detallada Toda iteracin para un proyecto debe ser corta y contar con una duracin fija (2 a 6 semanas). Para una iteracin se elige un conjunto reducido de requerimientos, se disea, implementa y prueba. El resultado de cada iteracin es un sistema que puede ser probado, integrado y ejecutado. La salida es un subconjunto con calidad de produccin final. Si existiesen inconvenientes para terminar una iteracin planificada en lugar de retrasar el final de sta se recomienda eliminar algunos de los requerimientos (se dejan para la siguiente iteracin). Dirigido por Casos de Uso: Para MeRinde los casos de uso son la herramienta estndar empleada para especificar los requerimientos funcionales del sistema, son los que guan el diseo, implementacin y pruebas de todo el sistema, y adicionalmente son los elementos que permiten la trazabilidad. Diseo simple: MeRinde apoya que los equipos de desarrollo eliminen las complejidades innecesarias y cdigo extra, que el nfasis se deposite en disear la solucin ms 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 ms funcionalidad si as se requiere. Enfoque continuo en la calidad: MeRinde contiene mecanismos para que la calidad de todos los artefactos se evale en varios puntos durante todo el proceso de desarrollo, especialmente al final de cada iteracin. 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 Revisin, Registro de Evaluacin, 15
MeRinde Gua Detallada Criterios de Aceptacin, entre otros ms 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 tambin se asegura que no solo se cumplan con las actividades bsicas 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 retroalimentacin 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 gestin de los riesgos es contemplada MeRinde desde el inicio del proyecto hasta el final del mismo a travs de diferentes artefactos, fundamentalmente se manejan dos artefactos pilotos el Plan de Gestin de Riesgos y el Registro de Riesgos, donde se describen los posibles riesgos de recursos, tcnicos, o del negocio implicados en el proyecto, y formula un plan para abordar los mismos con medidas de mitigacin 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 metodologa MeRinde propicia como parte de obtener ms eficacia y eficiencia en los futuros desarrollos. Dicha prctica es fomentada por MeRinde a travs 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 travs del compartimiento de conocimiento y de lecciones aprendidas; la reutilizacin de 16
MeRinde Gua Detallada componentes y con actividades que promueven proyectos. Interaccin continua con cliente: El cliente esta inmiscuido dentro de los involucrados en MeRinde, rol fundamental en la metodologa 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 prdida de recursos y malentendidos durante el desarrollo. Modelar el software: El tipo de artefacto ms fundamental utilizado en la Metodologa MeRinde es el modelo. Cada rol necesita una perspectiva diferente del sistema. El diseo de MeRinde permite identificar todos los roles y cada una de las perspectivas que posiblemente podran necesitar. Las perspectivas recogidas de todos los roles se estructuran en unidades ms grandes, es decir, modelos, de modo que un rol pueda tomar una perspectiva concreta del conjunto de modelos. La eleccin de los modelos para un sistema es una de las decisiones ms importantes del equipo de desarrollo. En la figura 2 se pueden observar los modelos principales propuestos de la Metodologa MeRinde. la continua mejora de los
componentes empleados para los proyectos para su actual y futuro empleo en los
Diversos Modelos Propuestos en MeRinde
17
Figura 2. Diversos Modelos Propuestos en MeRinde. La Metodologa MeRinde contempla un conjunto de modelos propuestos relacionados que facilitan el entendimiento del sistema para todos los involucrados, incluyendo a los clientes, usuarios y lderes de proyecto. Fueron elegidos para satisfacer las necesidades de informacin de esos roles. La Metodologa 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 crtico en los proyectos de software, ante los cuales MeRinde crea las condiciones necesarias a travs de sus actividades para gestionarlos con un enfoque gil lo ms tempranamente posible con su proceso iterativo e incremental, con la participacin continua del cliente y con las actividades de retroalimentacin. entrega del producto, sino que durante el proceso de desarrollo. Los artefactos software cambian no slo debido a acciones de mantenimiento posteriores a la
18
MeRinde asume que las cosas estn constantemente cambiando y que ningn proyecto est aislado del impacto de estos cambios. Es importante para abordar ms 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 seccin dedica a las mejores prcticas encontradas en la metodologa propuesta, lo cual permite continuar con la definicin de estructura que conforma la metodologa, para adentrar un poco ms en los detalles de esta. Estructura del Proceso de MeRinde La metodologa 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 dinmicos del proceso. Indica las caractersticas del ciclo de vida del proceso expresado en trminos de fases, iteraciones e hitos. Eje vertical: Representa los aspectos estticos del proceso. Describe el proceso en trminos de componentes de proceso, disciplinas, actividades, artefactos y roles.
19

Esfuerzo en Actividades segn la Fase del Proyecto
Figura 3. Esfuerzo en Actividades segn la Fase del Proyecto en Merinde. En los dos captulos posteriores se proceder a describir tanto el eje de los aspectos dinmicos de MeRinde como el eje de los aspectos estticos. A continuacin se presenta los fundamentos sobre los cuales MeRinde se inspira. Mantenimiento A continuacin se describir como se lleva a cabo el mantenimiento de software desarrollado con MeRinde en sus cuatro categoras adaptativo, correctivo, perfectivo y preventivo. MeRinde posee en sus dos estructuras la esttica y la dinmica, y en las mejores prcticas sorbe las cuales esta se fundamenta, las herramientas necesarias 20
MeRinde Gua 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 travs del conjunto de actividades descritas por la metodologa. Un mantenimiento no es ms que un nuevo recorrido por todas las fases propuesta en MeRinde, donde las actividades y el esfuerzo de desarrollo sern directamente proporcionales a lo especificado en los requerimientos 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 documentacin del sistema ya existe, motivo por el cual lo que se hace es actualizar dicha documentacin u artefactos para ponerlos acorde a los nuevos cambios solicitados. Al igual que el sistema con los cambios pasa a una nueva versin igual ocurrir con la documentacin del sistema. Las actividades, tareas, roles y artefactos a considerar para el mantenimiento son tambin 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. para el
21
MeRinde Gua 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, mitigacin de riesgos, control de calidad, gestin del proyecto y control de configuracin. En general, esta metodologa est fuertemente fundamentada en los requerimientos del CNTI y en varias metodologas como UP, OpenUP, RUP, entre otras que a continuacin sern sealadas. Cabe destacar que los elementos de esta metodologa fueron considerados mediante un anlisis de varias metodologas en la que se compararon las mismas con respecto a sus elementos, esto permiti la escogencia de los elementos para esta metodologa que han tenido xito en el proceso de elaboracin de software, as como tambin 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 metodologa se puede decir que las mejores prcticas para el desarrollo de software congregadas en MeRinde estn inspiradas en UP, RUP, XP, MSF y OpenUP. MeRinde propone una estructura como UP basada en aspectos dinmicos y estticos. Las fases e hitos que corresponde los aspectos dinmicos considerados son las de UP y las disciplinas que corresponde a los aspectos estticos de la metodologa se fundamentan en las de UP, OpenUP y RUP. Los flujos de trabajos que envuelve cada disciplina estn inspirados en RUP, as como tambin 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 metodologa 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 estn basados en los de Readyset, UP y
22
MeRinde Gua Detallada artefactos existentes en la organizacin. Tambin se ven reflejadas las ideas y recomendaciones de los autores en muchos aspectos que envuelve MeRinde. Estas metodologas en las que se basa MeRinde son algunas de las ms usadas, adems de que permiten la adaptacin, es decir son un marco de trabajo que permiten escoger elementos segn las caractersticas de cada proyecto. Por la cual estas sirvieron de insumo para armar la metodologa del CNTI para el desarrollo de software con un enfoque de calidad que satisfaga las necesidades de dicha organizacin. Una vez ya culminados los aspectos generales de la metodologa propuesta, se procede a describir la estructura dinmica de MeRinde en detalle en el prximo captulo como haba sido indicado anteriormente.
23
CAPTULO II ESTRUCTURA DINMICA DE LA METODOLOGA
En este apartado se reflejan los aspectos dinmicos del proceso de desarrollo en trminos 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 generacin del producto y consta de cuatro fases. Cada fase se subdivide a la vez en iteraciones, el nmero 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 crticas y alcanzar las metas clave antes de pasar a la siguiente fase, ese hito principal de cada fase se compone de hitos menores que podran ser los criterios aplicables a cada iteracin. Los hitos son puntos de control en los cuales los involucrados en el proyecto revisan el progreso del proyecto. Fases de la Metodologa 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, Elaboracin, Construccin y Transicin. Al final de cada fase el equipo gestor del proyecto realiza una evaluacin para determinar si los objetivos se cumplieron y as pasar a la fase siguiente.
24

Fases e Hitos encontrados en MeRinde
Figura 4. Fases e Hitos encontrados en MeRinde. A continuacin se muestran el objetivo general, los objetivos especficos y las iteraciones recomendadas para cada una de las fases antes mencionadas. Inicio Su propsito 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 especficos de esta fase son: Establecer el mbito del proyecto y sus lmites. Encontrar los casos de uso crticos del sistema, los escenarios bsicos 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 identificacin de los principales riesgos y la viabilidad del proyecto.
25

Fase de Inicio e Hito en MeRinde
Figura 5. Fase de Inicio e Hito en MeRinde. Se recomienda utilizar dos iteraciones en esta fase. Sin embargo, algunos de los proyectos podran requerir ms o menos iteraciones para alcanzar su objetivo. Elaboracin 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 crticos 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 informacin necesaria para el plan de construccin y obteniendo suficiente informacin para hacer realizable el caso del negocio. Los objetivos especficos de esta fase son: Definir, validar y establecer la arquitectura. Completar la visin. Crear un plan fiable para la fase de construccin. Este plan puede evolucionar en sucesivas iteraciones. Debe incluir los costos si procede. Demostrar que la arquitectura propuesta soportar la visin con un costo razonable y en un tiempo razonable.
26
MeRinde Gua Detallada El hito en la fase de elaboracin finaliza con la obtencin de una lnea base de la arquitectura del sistema, la captura de la mayora de los requerimientos y la reduccin de los riesgos importantes as como permitir la escalabilidad del equipo del proyecto durante la fase de construccin.
Fase de Elaboracin e Hito en Merinde
Figura 6. Fase de Elaboracin e Hito en Merinde. Se recomienda utilizar dos iteraciones en la fase de elaboracin. Aunque algunos de los proyectos en esta fase podran requerir ms iteraciones para alcanzar su objetivo. Construccin El objetivo general de esta fase es alcanzar la capacidad operacional del producto (ver figura 7) de forma incremental a travs de las sucesivas iteraciones. En esta fase todas las caractersticas, componentes, y requerimientos deben ser integrados, implementados, y probados en su totalidad, obteniendo una versin aceptable del producto comnmente llamada versin 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 Gua Detallada Los objetivos especficos de esta fase son: Minimizar los costos de desarrollo mediante la optimizacin de recursos y evitando el tener que rehacer un trabajo o incluso desecharlo. Conseguir una calidad adecuada tan rpido como sea prctico. Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba) tan rpido como sea prctico. El hito en esta fase culmina con el desarrollo del sistema con calidad de produccin y la preparacin para la entrega al equipo de transicin. Toda la funcionalidad debe haber sido implementada y las pruebas para el estado beta de la aplicacin completadas. Si el proyecto no cumple con estos criterios de cierre, entonces la transicin deber posponerse una iteracin.
Fase de Construccin e Hito en MeRinde
Figura 7. Fase de Construccin e Hito en MeRinde. Para esta fase se recomienda realizar tres iteraciones. Tomando en cuenta las dimensiones de algunos proyectos el nmero de iteraciones puede variar. Transicin Tiene como objetivo general entregar el producto funcional (ver figura 8) en manos de los usuarios finales una vez realizadas las pruebas de aceptacin 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 Gua Detallada la documentacin, y en general tareas relacionadas con la configuracin, instalacin y usabilidad del producto. Los objetivos especficos 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 transicin 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 Transicin e Hito en MeRinde
Figura 8. Fase de Transicin e Hito en MeRinde. Las iteraciones de esta fase irn dirigidas normalmente a conseguir una nueva versin. La complejidad de esta fase depende totalmente de la naturaleza del proyecto, de su alcance y de la organizacin 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 dinmica de la MeRinde tiene cuatro fases y cuatro hitos fundamentales, y adems en cada fase se pueden realizar las iteraciones que convengan segn las caractersticas del proyecto. Como criterio de cierre de una fase y comienzo de la otra se debe haber finalizado la fase con un hito. 29
En el siguiente captulo se explica la parte esttica del proceso de desarrollo de software MeRinde.
30
CAPTULO III ESTRUCTURA ESTTICA DE LA METODOLOGA
Un proceso de desarrollo de software define quin hace qu, cmo y cundo. El proceso de MeRinde define cuatro elementos: los roles, que responden a la pregunta Quin?, las actividades que responden a la pregunta Cmo?, los artefactos, que responden a la pregunta Qu? y los flujos de trabajo de las disciplinas que responde a la pregunta Cundo?, as como se muestra en la figura 9.
Dimensin Esttica de MeRinde
Figura 9. Dimensin Esttica de MeRinde. Elaborado por los Autores, con imagenes de Kopete Vista Icono Theme por Joachim Farouz, 2006. 31
MeRinde Gua Detallada A continuacin se describen cada uno de los elementos antes mencionados. Roles Definidos en la Metodologa Una de las razones principales de la adopcin de esta metodologa para el desarrollo de software consiste en la definicin de las tareas que sern 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 realizacin de tareas, las cuales generan artefactos.
Representacin Grfica del cono que Especfica un Rol en MeRinde
10
Figura 10. Representacin Grfica del cono que Especfica un Rol en MeRinde. Tomado de Kopete Vista Icono Theme por Joachim Farouz, 2006. Existen artefactos que necesitan de ms de un solo rol para poder ser elaborados (ver figura 11).
Representacin Grfica del cono que Especfica los Involucrados en MeRinde
11
Figura 11. Representacin Grfica del cono que Especfica 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 metodologa depende de la magnitud del proyecto. Mientras ms grande y complejo sea el proyecto requerir de una mayor cantidad de participantes para su elaboracin y ms 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 Gua Detallada Esta metodologa ms que proponer una serie de roles estticos para un proyecto establece que se pueden utilizar los roles que se consideren necesario para realizar el proyecto segn las caractersticas y el tiempo requerido por este. Los roles de esta metodologa sern agrupados por participacin en actividades relacionadas. Todos los roles dentro de un grupo trabajan con tcnicas similares y tienen habilidades en comn, pero cada uno de estos poseen mtodos especficos para la ingeniera del software en su rea en particular. La metodologa del CNTI propone ocho (8) roles bsicos que deben tomarse en cuenta para la elaboracin de software como son: a. Analista de Calidad. b. Analista de Producto. c. Arquitecto de Software. d. Desarrollador. e. Involucrado. f. Lder del Proyecto. g. Mentor. h. Probador. Es importante destacar que todos los proyectos pequeos o grandes que utilicen esta metodologa en su proceso de desarrollo, deben considerar estos ocho (8) roles entre los roles definidos para el proyecto. Esta metodologa seala una serie de roles recomendados pero cabe destacar que un rol puede ser desempeado por varias personas y una persona puede representar varios roles, es por ello que esta metodologa brinda la oportunidad de incorporar un nmero 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 Gua 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 continuacin se describirn los grupos de roles definidos en esta metodologa, as como tambin se seala algunos roles especficos que se pueden considerar dentro de estos grupos y el modelo de equipo de proyecto propuesto. Descripcin 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 reunin, 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 tambin participan los miembros del proyecto que estn involucrados en su elaboracin. Este rol se puede descomponer en los siguientes subroles: Comit de direccin. 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 cules son las restricciones del mismo. Este rol se puede descomponer en el siguiente subrol: Especificador de requerimientos.
34
Arquitecto de software. Se encarga de la definicin de la arquitectura que guiar el desarrollo, y de la continua refinacin de la misma en cada iteracin; debe construir cualquier prototipo necesario para probar aspectos riesgosos desde el punto de vista tcnico del proyecto; definir los lineamientos generales del diseo y la implementacin. Este rol se puede descomponer en los siguientes subroles: Diseador. Diseador de base de datos. Diseador de interfaz de usuario. Diseador de paquetes. Desarrollador. Esta persona tiene a su cargo la codificacin de los componentes en cdigo fuente en algn lenguaje de alto nivel a desarrollar en la iteracin; debe elaborar y ejecutar las pruebas unitarias realizadas sobre el cdigo desarrollado; es responsable de las clases que ha desarrollado debiendo documentarlas, actualizarlas ante cambios y mantenerlas bajo el control de configuracin de las mismas mediante la herramienta utilizada. Este rol se puede descomponer en los siguientes subroles: Implementador. Integrador.
35
MeRinde Gua 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. Diseador grfico. Documentador tcnico. Especialista en herramientas. Experto del Negocio. Usuarios. Lder del proyecto. Este rol se encarga de establecer las condiciones de trabajo. Por tal motivo tiene la funcin de dirigir y asignar recursos, coordina las interacciones con los clientes y usuarios finales, planifica las iteraciones, planifica y asigna el trabajo, define la organizacin del proyecto, establece las prcticas 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 configuracin. Jefe de control de cambios. Jefe de implantacin. 36
MeRinde Gua Detallada Jefe de pruebas. Revisor de gestin del proyecto. Mentor. El Mentor es aquella persona que est ntimamente ligada con el proceso de desarrollo de software, que conoce todas las prcticas involucradas y entiende el porqu de la misma. Acompaa y apoya a los equipos de trabajo mediante revisiones de los artefactos y haciendo recomendaciones de cmo 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 tambin contribuye a que la calidad se mantenga durante el desarrollo del sistema. Este rol se puede descomponer en los siguientes subroles: Revisor tcnico. Revisor. Probador. La funcin del probador es realizar las pruebas identificadas y definidas previamente, utilizando las instrucciones, mtodos y herramientas necesarias para este rol. Debido a la realizacin de las pruebas debe obtener los resultados de las mismas. Este rol se puede descomponer en los siguientes subroles: Analista de pruebas. Diseador de pruebas. Especialista en Pruebas.
37
MeRinde Gua Detallada Cabe destacar que la metodologa MeRinde tiene 8 roles fundamentales y cada rol tiene asociado su funcin. Para proyectos que por su magnitud requieran ms 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 especfico para determinadas funciones. Seguidamente se describen el modelo de equipo propuesto para la metodologa 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 geogrficas 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 organizacin, en donde a su vez el personal externo a una organizacin puede ser de diversa ndole jurdica como cooperativas, fundaciones, entes gubernamentales, compaas, personas naturales, entre otras. Todo lo anteriormente sealado impacta la configuracin 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 mltiples roles o donde por el contrario muchos individuos pueden asumir un rol. En la figura 12 los rectngulos contienen los diversos roles contemplados por la metodologa, las lneas que conectan el diagrama representan lneas de comunicacin, las elipses representan los equipos y los fuertes enlaces comunicacionales que existen entre estos, y la elipse central es ncleo del modelo donde se ve el equipo como un todo en donde existe constante comunicacin, coordinacin y cooperacin. 38 una

Representacin Grfica del Modelo de Equipo de Proyecto
12
Figura 12. Representacin Grfica del Modelo de Equipo de Proyecto. El modelo de equipo para proyectos est conformado por: Un equipo de gestin de proyecto el cual es interno a la organizacin que conlleva el proyecto, cuya misin es mantener y establecer los lineamientos del proyecto y mantener la calidad durante todo el ciclo de vida del proyecto. Uno o ms equipos de desarrollo que conllevan el anlisis, diseo e implementacin del proyecto. Estos por ejemplo pueden representar desde una organizacin como una cooperativa hasta individuos que participan en el proyecto, los cuales a su vez se pueden ser interno, externo ambas inclusive a la organizacin. El caso en que una organizacin cuenta con personal interno y externo a la vez puede ser el ms difcil de comprender, para el caso de MeRinde ambos son equipos distintos y con tareas especificas pero que entran en la elipse central 39
MeRinde Gua Detallada donde hay una alta comunicacin, coordinacin y cooperacin para desarrollar el proyecto en conjunto. Uno o ms probadores ajenos a los equipos de gestin y de desarrollo. Uno o ms 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 jerrquica, sino por el contrario representa un modelo de trabajo flexible basado en la comunicacin, cooperacin y la coordinacin para aplicar las prcticas y flujos de trabajos especificados en MeRinde. El Modelo se ajusta a desarrollos tanto internos como externos a una organizacin y a las restricciones geogrficas de los equipos de trabajo y a los cambios que puedan ocurrir por la salida o entrada de individuos a un proyecto. A continuacin se describen los artefactos que son otro elemento considerado como aspecto esttico en esta metodologa. Artefactos Descripcin de los Artefactos de la Metodologa MeRinde propone setenta y seis (76) artefactos que pueden ser creados durante el proceso de desarrollo de software. Estos artefactos van desde el propio cdigo fuente hasta la documentacin 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 slo los artefactos que se consideren necesarios para el proyecto, adicionalmente segn los lineamientos establecidos se les puede hacer modificaciones a los mismos y tambin se pueden establecer artefactos adicionales a los aqu propuestos. 40
MeRinde Gua Detallada Es importante que la documentacin 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.
Representacin Grfica del cono que Especfica un Artefacto
13
Figura 13. Representacin Grfica del cono que Especfica un Artefacto. Es fundamental que antes del comienzo del proceso de desarrollo se decida cuales son los artefactos que sern 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 sern entregados. A efectos de esta metodologa 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 tambin conforme al acuerdo entre las partes que intervienen en el proyecto. Fundamentalmente se recomienda que se emplee la mayora de los artefactos que son aqu sealados sobre todo si la magnitud del proyecto es grande. Mientras mayor documentacin 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 documentacin flexibiliza el proceso posterior de mantenimiento que el sistema puede llegar a tener, adicionalmente es una buena prctica para la elaboracin de proyectos que involucran un gran nmero de personas y roles. Cabe destacar que es vlido emplear artefactos adicionales a los aqu recomendados siempre que estos faciliten y cumplan con los requerimientos. 41
MeRinde Gua Detallada A continuacin se lista en la tabla 1 los artefactos que se proponen en esta metodologa y adicionalmente se indican cuales son los artefactos mnimos a ser tomados en cuenta para el desarrollo de un sistema de software con MeRinde: Tabla 1 Artefactos Propuestos en MeRinde con Indicacin de Necesidad
1
Nombre del Artefacto Artefactos de Instalacin Calificacin de los Aspectos Tcnicos de los Servicios de Desarrollo de Sistemas Capsula Casos de Pruebas Componente Operacional del Sistema Criterios de Aceptacin Datos de Pruebas Documento de Arquitectura del Negocio (DAN) Documento de Arquitectura del Software (DAS) Elemento de Implementacin Elemento de Soporte de Prueba El Sistema Entidad del Negocio Escenarios por Casos de Uso Especificacin de Migracin de Datos Especificacin de Requerimientos del Software (ERS) Especificaciones Suplementarias Evaluacin de la Organizacin Objetivo (EOO) Glosario del Sistema Herramientas Infraestructura de Desarrollo Licitacin de Personal Lineamientos del Proyecto Lista de Ideas de las Pruebas Lista de Materiales Manual de Instalacin Manual de Usuario Mapa de Navegacin Marco de Desarrollo Material de Adiestramiento Mecanismo de Retroalimentacin Modelo de Anlisis Modelo de Anlisis del Negocio Modelo de Casos de Uso Modelo de Casos de Uso del Negocio Modelo de Datos Modelo de Diseo Modelo de Diseo del Negocio
Necesario
42

Nombre del Artefacto Modelo de Implantacin Modelo de Implantacin del Negocio Modelo de Implementacin Modelo de Servicio Notas de Lanzamiento Oferta de Servicio del Personal Orden de Trabajo Plan de Adiestramiento Plan de Gestin de Configuracin Plan de Gestin de Riesgos Plan de Implantacin Plan de Integracin Plan de Iteracin Plan de Pruebas Planificacin del Proyecto Plantillas para el Proyecto Prototipo de la Interfaz de Usuario Prueba de Concepto Arquitectnico del Negocio Realizaciones de los Casos de Uso Realizaciones de los Casos de Uso del Negocio Registro de Evaluacin Registro de Revisin 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 Implementacin Trminos de Referencia para el Equipo Desarrolladores del Sistema Trminos de Referencia del Sistema Trabajador del Negocio Unidad de Implantacin Visin del Negocio Visin del Sistema Necesario
de
En el Apndice A se detallan cada uno de los artefactos propuestos en MeRinde por orden alfabtico, indicando una descripcin breve, su rol responsable, la disciplina a la cual pertenece, si posee plantilla, y si aplica se seala su artefacto contenedor y los
43
MeRinde Gua Detallada que este contenga. A continuacin se listaran los artefactos compuestos dentro del proceso de desarrollo propuesto en MeRinde. Artefactos Compuestos Los artefactos mencionados anteriormente que sern generados y utilizados por el proyecto constituyen los entregables. Algunos artefactos estn contenidos dentro de otros artefactos, dichos artefactos constituidos por otros se presentan a continuacin en la tabla 2: Tabla 2 Listado de Artefactos Compuestos
2
Artefacto Contenedor
El Sistema Especificacin de Requerimientos del Software (ERS) Infraestructura de Desarrollo Marco de Desarrollo Modelo de Anlisis del Negocio Modelo de Diseo Modelo de Diseo del Negocio
Artefactos Contenidos
Lista de Materiales Artefactos de Instalacin Unidad de Implantacin 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 Implementacin Subsistema de Implementacin Elemento de Soporte de Prueba Casos de Pruebas Criterios de Aceptacin Datos de Pruebas Escenarios por Caso de Uso Lista de Ideas de las Pruebas Resumen del Ciclo de Prueba
Modelo de Implementacin
Plan de Pruebas
44
MeRinde Gua 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 prctico para cada proyecto. En la siguiente seccin se mostrar otro componente fundamental de la estructura esttica de la metodologa propuesta como lo son las disciplinas, las cuales responden a la pregunta cundo del proceso de desarrollo. Disciplinas de la Metodologa La metodologa 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 estn 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 agrupacin de tareas relacionadas. Las disciplinas que conforman esta metodologa se dividirn en dos grupos. El primero comprende las disciplinas fundamentales asociadas con las reas de ingeniera: a. Modelado del Negocio. b. Requerimientos. c. Anlisis y Diseo. d. Implementacin. e. Pruebas. f. Implantacin. El segundo grupo lo integran las disciplinas llamadas de soporte o gestin: a. Gestin de Configuracin y Cambios. b. Gestin del Proyecto. c. Gestin del Ambiente. 45
MeRinde Gua Detallada Estas son todas las reas que de una manera u otra definen el mbito de la aplicacin. Estas disciplinas definen los flujos bsicos sobre los cuales se va a ir iterando durante las fases del proyecto.
Representacin Grfica del cono que Especfica una Actividad
14
Figura 14. Representacin Grfica del cono que Especfica una Actividad.
Representacin Grfica del cono que Especfica una Tarea
15
Figura 15. Representacin Grfica del cono que Especfica una Tarea.
Representacin Grfica del cono que Especfica una Subactividad
16
Figura 16. Representacin Grfica del cono que Especfica una Subactividad. Las disciplinas sern explicadas de forma separada, lo que da una impresin de que el proceso de desarrollo de software en general, del comienzo al fin del proyecto, pasa por las disciplinas slo una vez, lo cual recuerda errneamente a las etapas de una metodologa en cascada. Esta impresin es incorrecta puesto que como se ha mencionado anteriormente los flujos de trabajo son recorridos secuencialmente por cada iteracin 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 recorreran las disciplinas nueve veces. Es importante destacar que para cada iteracin no necesariamente se tiene que recorrer las nueve disciplinas descritas en igual esfuerzo, es decir, segn sea
46
MeRinde Gua Detallada necesario para cada iteracin se debe aplicar mayor esfuerzo en las disciplinas precisas para cumplir el objetivo de la iteracin. A continuacin se describen cada una de las disciplinas antes mencionadas. Modelado del Negocio Con esta disciplina se pretende llegar a un mejor entendimiento de la organizacin 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 obstculo; conseguir que se ajuste de la mejor forma posible en la organizacin donde se va a implantar; y tener un marco comn para el equipo de proyecto, los clientes y los usuarios finales. Esta disciplina no ser siempre necesaria. Si slo se aaden funcionalidades que no vern los usuarios directamente, no har falta. Los objetivos especficos de la disciplina modelado de negocio son: Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento comn de la organizacin objetivo. Derivar los requerimientos del sistema necesarios para apoyar a la organizacin objetivo en su mejora. Entender el problema actual en la organizacin objetivo e identificar potenciales mejoras. Entender la estructura y la dinmica de la organizacin para la cual el sistema va a ser desarrollado (organizacin objetivo). Para lograr estos objetivos, el modelado de negocio describe como desarrollar una visin de la nueva organizacin, basado en esta visin se definen procesos, roles y responsabilidades de la organizacin por medio de un Modelo de Casos de Uso del Negocio. Los artefactos del modelo de negocio sirven como entrada y referencia para la definicin de los requerimientos del sistema. 47
MeRinde Gua 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 podrn identificarse las necesidades inmediatas de mejora y continuidad relativa a las actividades relacionadas con los sistemas informticos, que son el producto final del desarrollo. Flujo de trabajo. En la figura 17 se seala 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 ejecucin 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 lnea 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 Gua Detallada requerimientos se deben aplicar prcticas de licitacin a los involucrados en el proyecto, anotar y validar todas sus solicitudes. Los objetivos especficos 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 debera 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 planeacin de los contenidos tcnicos 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 seal. Los requerimientos no funcionales, los cuales especifican criterios que pueden usarse para juzgar la operacin de un sistema en lugar de sus funciones especficas. En esta disciplina, y como parte de los requerimientos de facilidad de uso, se disea la interfaz grfica del usuario. Para ello habitualmente se construyen prototipos de la interfaz grfica de usuario que se validan con el usuario final. Flujo de trabajo. En la figura 18 se seala el flujo de trabajo de la disciplina Requerimientos a fin presentar como MeRinde contempla la secuencia de acciones, actividades o tareas utilizadas para la ejecucin de la disciplina mencionada. 49

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 especificacin que describa cmo implementar el sistema. El anlisis fundamentalmente consiste en obtener una visin 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 diseo 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 Gua Detallada Los objetivos especficos de la disciplina anlisis y diseo son: Adaptar el diseo para que sea consistente con el entorno de implementacin. Desarrollar una arquitectura para el sistema. Transformar los requerimientos al diseo del futuro sistema. Al principio de la fase de elaboracin hay que definir una arquitectura candidata: crear un esquema inicial de la arquitectura del sistema, identificar clases de anlisis y actualizar las realizaciones de los Casos de Uso con las interacciones de las clases de anlisis. Durante la fase de elaboracin se va refinando esta arquitectura hasta llegar a su forma definitiva. En cada iteracin hay que analizar el comportamiento para disear componentes. Flujo de Trabajo. En la figura 19 se seala el flujo de trabajo de la disciplina Anlisis y Diseo a fin presentar como MeRinde contempla la secuencia de acciones, actividades o tareas utilizadas para la ejecucin de la disciplina mencionada.
51

Flujo de Trabajo de la Disciplina Anlisis y Diseo
19
Figura 19. Flujo de Trabajo de la Disciplina Anlisis y Diseo.
Implementacin El objetivo principal de esta disciplina es convertir los elementos del diseo en elementos de implementacin, dichos elementos son cdigos 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 Gua Detallada Los objetivos especficos de la disciplina implementacin son: Cada desarrollador decide en quequ orden implementa los elementos del subsistema. Integrar el sistema siguiendo el plan. Notificar los errores de diseo, si se encuentran. Planificar qu subsistemas deben ser implementados y en quequ orden deben ser integrados, formando el Plan de Integracin. Probar los subsistemas individualmente. La estructura de todos los elementos implementados forma el Modelo de Implementacin. La integracin debe ser incremental, es decir, en cada momento slo se aade un elemento. De este modo es ms fcil localizar fallos y los componentes se prueban ms 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 tecnologas o disear 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 seala el flujo de trabajo de la disciplina Implementacin a fin presentar como MeRinde contempla la secuencia de acciones, actividades o tareas utilizadas para la ejecucin de la disciplina mencionada.
53

Flujo de Trabajo de la Disciplina Implementacin
20
Figura 20. Flujo de Trabajo de la Disciplina Implementacin. Pruebas El principal objetivo de esta disciplina es de evaluar la calidad del producto que se est desarrollando a travs de las diferentes fases por las cuales este pasa, mediante la aplicacin de pruebas concretas para validar que las suposiciones hechas en el diseo y los requerimientos se estn 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 refinndolo y no al final del mismo. 54
Los objetivos especficos de la disciplina pruebas son: Encontrar y documentar defectos en la calidad del software. Notificar la calidad percibida del software. Proveer un medio de validacin para las suposiciones hechas en el diseo y especificaciones de requerimientos por medio de demostraciones concretas. Validar las funciones del producto de software segn lo diseado. Validar que los requerimientos fueron implementados apropiadamente. El desarrollo de esta disciplina consistir en planificar que es lo que hay que probar, disear cmo 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 informacin 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 realimentacin 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 mnimas por separado, y normalmente se hace durante la implementacin misma), de integracin (varias unidades juntas), de sistema (sobre la aplicacin o sistema completo) y de aceptacin (realizado sobre el sistema global por los usuarios o terceros).
55
MeRinde Gua Detallada Flujo de trabajo En la figura 21 se seala el flujo de trabajo de la disciplina Pruebas a fin presentar como MeRinde contempla la secuencia de acciones, actividades o tareas utilizadas para la ejecucin de la disciplina mencionada.
Flujo de Trabajo de la Disciplina Pruebas
21
Figura 21. Flujo de Trabajo de la Disciplina Pruebas.
56
MeRinde Gua Detallada Implantacin 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 especficos 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 ejecucin final. Proveer asistencia y ayuda a los usuarios. Se lleva a cabo con mayor intensidad en la fase de transicin, debido a que su propsito es asegurar una aprobacin y adaptacin 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 planificacin, pero tambin con la elaboracin del manual de usuario y tutoriales. Debido al extenso nivel de aplicaciones que se pueden obtener y las diversas caractersticas de los productos necesarios para esta disciplina, se pueden obtener grandes variaciones dependiendo del tipo de sistema a desarrollar. El objeto clave es una distribucin del producto. Dado las diversas especificaciones de implantacin que se pueden dar para cada proyecto, se le otorga en esta metodologa pocos detalles a esta fase. Aunque el sistema est bien diseado y desarrollado correctamente su xito depender de su implantacin y ejecucin por lo que es importante capacitar al usuario con respecto a su uso y mantenimiento.
57
MeRinde Gua Detallada Flujo de Trabajo. En la figura 22 se seala el flujo de trabajo de la disciplina Implantacin a fin presentar como MeRinde contempla la secuencia de acciones, actividades o tareas utilizadas para la ejecucin de la disciplina mencionada.
Flujo de Trabajo de la Disciplina Implantacin
22
Figura 22. Flujo de Trabajo de la Disciplina Implantacin.
58
MeRinde Gua Detallada Gestin de Configuracin 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 configuracin, restringir y auditar los cambios a esos elementos, y definir y dirigir la distribucin de los mismos. Sus objetivos especficos son: Asegurar que los productos desarrollados sean completados y corregidos debidamente. Dar soporte a los mtodos de desarrollo. Mantener la consistencia de los productos durante la evolucin 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 auditoras que permita identificar el por qu, cundo y por quin ha sido modificado un proyecto. Restringir los cambios a los productos segn las polticas del proyecto. Esta disciplina abarca tres funciones como son: La gestin de la configuracin, que maneja estructura del producto, configuraciones, la identificacin de los elementos, versiones y espacio de trabajo. La gestin de solicitudes de cambio, regula el proceso de cambiar artefactos de una forma estable. Las mtricas y estatus, que permite extraer informacin de las dos herramientas anteriores, para conducir correctamente el proyecto. 59
Entre algunas de las causas por las que la evolucin de los artefactos puede causar problemas son: Actualizacin simultnea: 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. Mltiples 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. Notificacin 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 seala el flujo de trabajo de la disciplina Gestin de Configuracin y Cambios a fin presentar como MeRinde contempla la secuencia de acciones, actividades o tareas utilizadas para la ejecucin de la disciplina mencionada.
60

Flujo de Trabajo de la Disciplina Gestin de Configuracin de Cambios
23
Figura 23. Flujo de Trabajo de la Disciplina Gestin de Configuracin de Cambios. Gestin del Proyecto El objetivo de la gestin 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 especficos de la disciplina Gestin del Proyecto son: Proveer guas prcticas para realizar planeacin, contratar personal, ejecutar y monitorear el proyecto. Proveer un marco de trabajo para gestionar riesgos. Proveer un marco de trabajo para la gestin de proyectos de software intensivos. Para conseguir estos objetivos el flujo de trabajo de esta metodologa se centra en tres aspectos: 61
MeRinde Gua Detallada a. Administrar el riesgo. b. Monitorear el progreso del proyecto a travs de mtricas. c. Planificar un proyecto iterativo y cada iteracin 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. Tambin es necesario para planificar de forma precisa y ver cul es el comportamiento del proyecto frente a cambios. La administracin del riesgo consiste en ocuparse de las incgnitas de un proyecto, las cuestiones que puede afectar el desarrollo del proyecto y llevarlo al fracaso. En concreto hay que identificar los riesgos, tpicamente 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 administracin del riesgo consistir en gestionar una lista de riesgos. Flujo de trabajo. En la figura 24 se seala el flujo de trabajo de la disciplina Gestin del Proyecto a fin presentar como MeRinde contempla la secuencia de acciones, actividades o tareas utilizadas para la ejecucin de la disciplina mencionada.
62

Flujo de Trabajo de la Disciplina Gestin del Proyecto
24
Figura 24. Flujo de Trabajo de la Disciplina Gestin del Proyecto. Elaborado por los Autores con datos de Rational Unified Process de IBM Corporation, 2006.
63
MeRinde Gua Detallada Gestin del Ambiente La finalidad de esta disciplina es dar soporte al proyecto con los procesos, mtodos y herramientas correctas. Ofrece una descripcin 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 especficos de esta disciplina son: Configurar el proceso. Establecer y configurar las herramientas para que se ajusten a la organizacin. Mejorar el proceso de desarrollo. Proveer los servicios tcnicos necesarios. Seleccionar y adquirir herramientas.
Flujo de trabajo. En la figura 25 se seala el flujo de trabajo de la disciplina Gestin del Ambiente a fin presentar como MeRinde contempla la secuencia de acciones, actividades o tareas utilizadas para la ejecucin de la disciplina mencionada.
64

Flujo de Trabajo de la Disciplina Gestin del Ambiente
25
Figura 25. Flujo de Trabajo de la Disciplina Gestin del Ambiente. Elaborado por los Autores con datos de Rational Unified Process de IBM Corporation, 2006. En conclusin 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 sern visitadas una y otra vez por cada iteracin a lo largo de todo el proceso. Adems, las disciplinas tienen asociadas flujos de trabajo, actividades y tareas. Una actividad refleja la relacin entre roles, tareas y artefactos.
65
MeRinde Gua Detallada En el Apndice B se seala en detalle cada una de las Actividades propuestas que aparecen en los Flujos de Trabajo de cada una de las disciplinas, as como tambin las Tareas que conforman cada una de las Actividades. Seguidamente se presentar el Marco de Desarrollo propuesto, el cual demarca la configuracin 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 tambin, para las fases de esta, el grado aproximado de desarrollo de cada uno de sus artefactos. Tabla 3 Relacin entre los Componentes y las Fases de la Metodologa
3
COMPONENTES Disciplina Artefacto Documento de Arquitectura del Negocio Evaluacin de la Organizacin Objetivo (EOO) Visin del Negocio Modelo de Anlisis del Negocio: Entidad del Negocio Trabajador del Negocio Reglas del Negocio Modelado del Modelo de Caso de Uso del Negocio Negocio Modelo de Diseo del Negocio: Entidad del Negocio Realizaciones de los Casos de Uso del Negocio Trabajador del Negocio Modelo de Implantacin del Negocio Prueba de Concepto Arquitectnico del Negocio
FASES I E C c c c c c c c c
66
MeRinde Gua Detallada COMPONENTES Disciplina Artefacto Especificacin de Requerimientos de Software: Especificaciones Suplementarias Modelo de Casos de Uso Requerimientos Glosario del Sistema Solicitud de Involucrados Visin del Sistema Documento de Arquitectura del Software Especificacin de Migracin de Datos Mapa de Navegacin Modelo de Anlisis Modelo de Datos Anlisis y Prototipo de la Interfaz de Usuario Diseo Modelo de Diseo: Capsula Realizaciones de los Casos de Uso Modelo de Implantacin Modelo de Servicio Componente Operacional del Sistema Modelo de Implementacin: Elemento de Implementacin Implementacin Subsistema de Implementacin Elemento de Soporte de Prueba Plan de Integracin Resultado de Prueba Plan de Pruebas: Casos de Pruebas Criterios de Aceptacin 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 c c c c r r r r r c c c c c c r r r r r r r r T
r c r c r r c
c c c c c
c r r c
67
MeRinde Gua Detallada COMPONENTES Disciplina Artefacto El Sistema: Lista de Materiales Artefactos de Instalacin Unidad de Implantacin Manual de Instalacin Implantacin Manual de Usuario Material de Adiestramiento Mecanismo de Retroalimentacin Notas de Lanzamiento Plan de Adiestramiento Plan de Implantacin Plan de Gestin de Configuracin Gestin de Configuracin y Solicitud de Cambio Cambios Repositorio de Versiones Calificacin de los Aspectos Tcnicos de los Servicios de Desarrollo de Sistemas Licitacin de Personal Oferta de Servicio del Personal Orden de Trabajo Plan de Gestin de Riesgos Plan de Iteracin Gestin del Planificacin del Proyecto Proyecto Registro de Evaluacin Registro de Revisin Registro de Riesgos Solicitud del Sistema Trminos de Referencia del Sistema Trminos de Referencia para el Equipo de Desarrolladores del Sistema Infraestructura de Desarrollo: Herramientas Gestin 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 r r c r
c c c c c c c c c c c c c c c c
r c r
c r r r c c r
c r r c c r
c r r c c r
c c c r
r r
Nota. Tabla elaborada por los Autores. I: Fase de Inicio. E: Fase de Elaboracin. C. Fase de Construccin. T: Fase de Transicin. c: Comienzo de la construccin del artefacto. r: Refinamiento del artefacto (ampliacin, correccin).
68
MeRinde Gua Detallada Una vez conocidas las dos (2) estructuras de MeRinde se proceder a detallar su habilitar Web, medio a travs del cual ser implantada y distribuida la metodologa.
69
CAPTULO IV APORTES, VENTAJAS Y DESVENTAJAS DE LA METODOLOGA
Aportes de la Metodologa La Metodologa para el desarrollo de software MeRinde posee algunas caractersticas que hace de esta un proceso nico. A continuacin se presentan los aportes de la MeRinde a los proyectos del CNTI y dems instituciones del estado dedicadas al desarrollo de sistemas, lo cual la diferencia de otras metodologas. Estandarizacin del proceso de desarrollo, documentacin y
herramientas: Una de las primeras facilidades que una persona encuentra al utilizar y aprender MeRinde es el uso de un proceso de desarrollo, documentacin y herramientas estandarizados. La metodologa 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 definicin concisa del proceso de desarrollo entre las personas involucradas en un proyecto. Adicionalmente las plantillas de los artefactos que envuelve dicha metodologa tambin ofrecen un estndar, ya que estos son un modelo o gua para documentar adecuadamente los sistemas. Por otro lado, dicha metodologa 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 metodologa propuesta en este trabajo de investigacin refleja flujos de trabajo por disciplina adaptados a la realidad y el deber ser del desarrollo de software que se vive 70
MeRinde Gua Detallada en el CNTI con las cooperativas y pequeas empresas contratadas. MeRinde con el establecimiento de los flujo de trabajo fortalece la planificacin y coordinacin 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, documentacin y herramientas basadas en estndares abiertos: La metodologa MeRinde fue desarrollada utilizando estndares abiertos, lo cual incluye las plantillas propuestas de sus artefactos y el habilitador Web que la contempla. Adicionalmente la metodologa est publicada sin restricciones de ningn tipo, se puede adoptar libremente y est controlada por una organizacin pblica que vela por su evolucin, en este caso dicha organizacin es el CNTI. Con el uso de estndares abiertos, es posible destinar tiempo, talento y dinero para conducir a las empresas, la industria, la Administracin Pblica y a toda la sociedad hacia una situacin de mayor progreso. Modelo de equipo para el desarrollo de software que supera limitaciones geogrficas: MeRinde propone un modelo de equipo que supera las restricciones impuestas por la ubicacin del equipo de proyecto, a su vez sirve para cuando se desarrolla software con personal interno, externo o ambos inclusive, a una organizacin. Adicionalmente este modelo se fundamenta en tres (3) conceptos bsicos para su funcionamiento ptimo como son la cooperacin, colaboracin y la coordinacin 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 metodologa que se est empleando apoya la calidad con la revisin de los documentos generados durante el proyecto, as como tambin aclarando cualquier duda a los participantes en el proyecto acerca del proceso de desarrollo que se est 71
MeRinde Gua 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 ayudarn 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 organizacin. Cabe destacar que las plantillas que aporta esta metodologa fueron realizadas por los autores tomando en cuenta las plantillas de otras metodologas y de un proyecto que provee plantillas de ingeniera de software reutilizables, adems involucra plantillas que ya existan en la organizacin 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 sern revisados y puestos bajo control de versiones, por la cual se debe contar con un repositorio de documentos. Esto permite tener una documentacin adecuada y organizada para cada uno de los proyectos, permitiendo la mantenibilidad y reutilizacin. Adaptacin de varias prcticas probadas por el aprendizaje: MeRinde se basa en un conjunto de prcticas 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 prcticas propuestas por MeRinde no son creadas por los autores de dicha metodologa pero surgen del aprendizaje de una serie de autores que han participado en el desarrollo de muchos proyectos. Cabe destacar que las prcticas que envuelve MeRinde han sido probadas con tiempo suficiente y adems han tenido el xito que se considera para ubicarlas en la categora de Mejores Prcticas.
72
MeRinde Gua Detallada Ventajas de la Metodologa Entre algunas de las ventajas de emplear la metodologa se encuentran: Trazabilidad del Proceso de desarrollo: La metodologa admite trazabilidad en la documentacin 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 anlisis, el diseo y los casos de prueba. Adems, la metodologa 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 metodologa contienen un historial de revisiones que permite llevar un control de las revisiones de las versiones de algn 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 tambin la metodologa garantiza trazabilidad del proceso de desarrollo permitiendo comparar un versin con otra y observar los avances. Adaptacin y extensin de la metodologa segn 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 pequeos, medianos y grandes, es decir, permite seleccionar los elementos de la metodologa o incluir elementos que no proporciona la metodologa pero que se consideran necesarios dependiendo de las caractersticas 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 Gua Detallada Habilitador metodolgico fcil de manejar: MeRinde est contenida en un habilitador Web, es decir, un manejador de contenidos Web que refleja la informacin de la metodologa junto a las plantillas de sus artefactos de una forma agradable al usuario y sobre todo con una navegacin sencilla por intuicin y ayuda en lnea. El habilitador tiene una baja curva de aprendizaje, ya que solo requiere para su utilizacin que el usuario conozca aspectos bsicos de la navegacin de pginas Web. Planificacin, agilidad y control de los procesos de desarrollo de software: MeRinde se basa en la planificacin que conlleva a tener una gestin y toma de decisiones de alta calidad. La planificacin se logra mediante un proceso de descubrimiento de la informacin 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 metodologa involucra entre sus artefactos planes para el proyecto, iteraciones, implantacin, 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. Reutilizacin de componentes: La metodologa MeRinde propicia la reutilizacin de modelos, proceso, etc. ya definidos en implementaciones previas de esta metodologa. Permite que cuando se vaya a realizar un mdulo desde cero se haga una bsqueda para tratar de localizar algn componente reutilizable de fuente abierta que pueda simplificar el desarrollo del mdulo. Por lo cual la documentacin y mdulos de algn sistema capaz de operar independientemente desarrollados con esta metodologa pueden ser tomados en cuenta para futuros proyectos dentro o fuera del CNTI. La reutilizacin basada en componentes permite reducir los costos y el tiempo en el proceso de desarrollo de software. Mayor integracin entre el cliente y los desarrolladores: La metodologa involucra al cliente en el proceso de desarrollo de software con una continua participacin en determinadas actividades que se repiten a lo largo del ciclo de vida 74
MeRinde Gua Detallada de desarrollo, ya que este es quien finalmente evaluar, aprobar o desaprobar el proyecto. La integracin y la comunicacin entre el cliente y los desarrolladores evitar malos entendidos y evitar perder tiempo en rehacer el sistema. Por lo cual la opinin 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 aparicin el cliente como involucrado en el proyecto, al cual se le atribuye algunas tareas que debe realizar en colaboracin 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 metodologa libre, para aumentar su capacidad de control, trazabilidad y reutilizacin. Por otro lado, la definicin de actividades, tareas y roles permitir a las organizaciones aumentar la planificacin, distribuir funciones entre los miembros del equipo y mitigar el caos implcito en el desarrollo de software. A su vez, MeRinde contribuye con la educacin y la formacin del capital humano en el uso y aplicacin 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 metodologa 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 metodologa.
75
MeRinde Gua Detallada Desventajas de la Metodologa Entre algunas de las desventajas observadas en la metodologa 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 descripcin se puede sobreentender su contenido y estructura. La metodologa puede ser vista como muy pesada: El contenido de la metodologa 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 instanciacin 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 instanciacin del proceso para pequeos, 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 cules son las disciolinas, artefactos y roles esenciales para el desarrollo de cualquier proyecto.
76
SNTESIS DE LA METODOLOGA MERINDE La Metodologa 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 Metodologa MeRinde ms que un proceso simple; es un marco de trabajo genrico que puede especializarse para una gran variedad de sistemas software, para diferentes reas de aplicacin, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaos de proyecto. La Metodologa MeRinde est basado en componentes, lo cual quiere decir que el sistema software en construccin est formado por componentes software interconectados a travs de de interfaces bien definidas. La Metodologa MeRinde utiliza el Lenguaje Unificado de Modelado (Unified Modeling Language, UML) para preparar todos los esquemas de un sistema software. Esta propuesta metodolgica, la cual fue utilizada en la experiencia descrita en este documento, surge de la combinacin y adaptacin de modelos y metodologas ampliamente utilizadas para el desarrollo de software.
77
GLOSARIO En esta seccin se presentar una lista que contiene las definiciones de los trminos utilizados en este trabajo de investigacin. Dichos trminos se definen en orden alfabtico a continuacin: Actividad: Es una unidad de trabajo que una persona que desempee un rol puede ser solicitado a que realice. Las actividades tienen un objetivo concreto, normalmente expresado en trminos de crear o actualizar algn producto. Administracin Pblica: Descripcin de la base metodolgica para el desarrollo del proyecto y el logro de los resultados esperados. Conjunto de organismos e instituciones que se encargan de esta organizacin. Artefacto: Es un trozo de informacin 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 tcnica para la captura de requerimientos de un nuevo sistema o una actualizacin software. Ciclo de Vida: Conjunto de fases sucesivas compuestas por tareas planificables que contribuyen a generar un producto intermedio, necesario continuar hacia el producto final y facilitar la gestin del proyecto. Componente: Representa una parte modular del sistema que encapsula su contenido y cuya manifestacin es reemplazable dentro de su ambiente. Comunicacin: intercambio con otro u otros de informacin. para
78
MeRinde Gua Detallada Configuracin: Es una coleccin de propiedades que determinan el comportamiento del proceso de elaboracin del software. Cooperacin: Realizacin de un trabajo o tarea con otro u otros para un mismo alcanzar un mismo fin. Coordinacin: Reunin de medios, esfuerzos, etc., para una accin comn. Diagrama: Representacin grfica 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. Estndar: Es una norma que regula la realizacin de ciertos procesos o la fabricacin de componentes. En otras palabras es un modelo que se sigue para realizar un proceso o una gua 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 semntica de un metamodelo. Los estereotipos deben basarse en ciertos tipos existentes o clases en el metamodelo. Los estereotipos pueden extender la semntica, pero no la estructura o tipos pre-existentes y clases. Fase: Expresa cmo ha progresado el desarrollo de un software y cunto desarrollo puede requerir. Fichero: Es todo conjunto organizado de datos de carcter personal, cualquiera que fuere la forma o modalidad de su creacin, almacenamiento, organizacin y acceso.
79
MeRinde Gua 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 metodologa 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: cmo se estructuran las tareas, cmo se realizan, cul es su orden correlativo, cmo se sincronizan, cmo fluye la informacin que soporta las tareas y cmo se le hace seguimiento al cumplimiento de las tareas. Habilitador: Que habilita a alguien. Es un intermediario entre el usuario y la informacin. Herramienta: Funciones que ofrece un programa a travs 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. Iteracin: Repeticin de una secuencia de instrucciones o eventos. Lenguaje Unificado de Modelado (UML): Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema de software. Licencia: El derecho de uso de una versin especfica de un producto.
80
MeRinde Gua Detallada Mentora: 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 travs de una serie de reuniones de tipo personal, confidencial y limitadas en cuanto al tiempo y otras actividades de aprendizaje, dentro de una organizacin. Metodologa: Manera sistemtica de hacer cierta cosa. Modelo: Es una vista de un sistema del mundo real, es decir, una abstraccin de dicho sistema considerando un cierto propsito. Mdulo: 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 rpidamente. Repositorio: Es un sitio centralizado donde se almacena y mantiene informacin, habitualmente bases de datos o archivos informticos. Requerimiento: Es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Reutilizacin: Puede entenderse como el hecho de volver a utilizar los bienes o productos. La utilidad puede venir para el usuario mediante una accin de mejora o restauracin, 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 Gua Detallada Script: Es un guin o conjunto de instrucciones. Permiten automatizar tareas creando pequeas utilidades. Son interpretadas por un intrprete y usualmente son archivos de texto. Stakeholder: Toda aquella persona u organizacin 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 informacin, a los datos y a los conocimientos absorberlos y utilizarlos eficazmente con el apoyo de las Tecnologas de Informacin y Comunicacin. Tarea: Parte de una Actividad. Las tareas son actividades especficas que contribuyen al cumplimiento de la misin general u otros requerimientos. Tecnologa de Informacin y Comunicacin (TIC): Concepto empleado para designar lo relativo a la informtica conectada con los medios de comunicacin, especialmente con Internet, son medios que nos aportan un flujo ininterrumpido de informacin. Trazabilidad: Aquellos procedimientos preestablecidos y autosuficientes que permiten conocer el histrico, la ubicacin y la trayectoria de un producto o lote de productos a lo largo de la cadena de suministros en un momento dado, a travs de unas herramientas determinadas.
82
REFERENCIAS BIBLIOGRFICAS
Farouz, Joachim (2006) Kopete Vista Icono Theme [Document en lnea]. Disponible: http://www.kde-look.org/content/show.php?content=48635 Kopete_Vista.tar [consulta: 2006, Diciembre 16]. como 48635-
83
APNDICES
84
APNDICE A DESCRIPCIN DE LOS ARTEFACTOS PROPUESTOS DE MERINDE
85
MeRinde Gua Detallada A continuacin se detallan y se establecen las relaciones en orden alfabtico de cada uno de los artefactos que se proponen MeRinde: Artefactos de Instalacin Este artefacto tiene como objetivo permitir que la instalacin 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 Instalacin son necesarios cuando se quiere configurar el sistema mediante los programas de instalacin 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 instalacin se reflejan en el Manual de Instalacin y si se espera que el usuario instale el producto (sistema) puede reflejarse en el Manual de Usuario. Relaciones de Artefactos de Instalacin Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Desarrollador Implantacin El Sistema No aplica No posee
Calificacin de los Aspectos Tcnicos de los Servicios de Desarrollo de Sistemas Este artefacto debe contener instrumentos para la recoleccin de los aspectos tcnicos 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 Gua Detallada evaluados por los miembros del comit de seleccin para elegir las contratistas que sean necesarias para el proyecto. Para la elaboracin de este artefacto se debe haber suministrado a las potenciales contratistas el artefacto Trminos 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 mtodo o forma de trabajo, una planificacin para la ejecucin del trabajo, descripcin de la cantidad y nivel acadmico del personal con que dispondrn, entre otras caractersticas que se puedan evaluar para la seleccin de la mejor oferta. Relaciones del Artefacto Calificacin de los Aspectos Tcnicos de los Servicios de Desarrollo de Sistemas Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Involucrados Gestin del Proyecto No aplica No aplica Si posee Capsula Este artefacto es un modelo de diseo especfico que representa a un hilo de control en el sistema en desarrollo, es til para modelar y disear sistemas que tienen un alto grado de concurrencia, y su empleo como notacin facilita el diseo. Una capsula es un elemento compuesto y se representa como una clase estereotipada con el nombre de <<capsule>>. Para ver su notacin se debe revisar UML 2.0 o superior en la seccin sobre Estructuras Compuestas.
87
MeRinde Gua Detallada Relaciones del Artefacto Capsula Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Arquitecto de Software Anlisis y Diseo Modelo de Diseo No aplica No posee Casos de Pruebas Este artefacto define un conjunto de datos de entradas, condiciones de ejecucin y resultados esperados de las pruebas, identificados para hacer una evaluacin de los aspectos especficos 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 rpidamente a ejecutar pruebas y a encontrar defectos. Adems, estos reflejan trazabilidad con los casos de uso, las especificaciones suplementarias de requerimientos y diseo del sistema, garantizando que los procedimientos de pruebas sean compatibles con las necesidades de los usuarios/clientes. En la metodologa 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 ampla la informacin contenida en un Caso de Uso. Relaciones del Artefacto Casos de Prueba Rol Responsable: Disciplina: Artefacto Contenedor: Probador Pruebas Plan de Pruebas
88
MeRinde Gua Detallada Artefacto(s) Contenido(s): Plantilla: No aplica Si posee Componente Operacional del Sistema Este artefacto es una versin operacional del sistema o parte de este que cubre un subconjunto especificado de los requerimientos que el sistema final cumplir. Este comprende uno o ms elementos de la aplicacin (funciones ejecutables) que son creados de otros elementos mediante un proceso de compilacin y unin del cdigo fuente. Agrupa un conjunto de Subsistemas de Implementacin. Cabe destacar que cada una de las funciones y capacidades que representan una parte del sistema pueden ser probadas durante su ejecucin. Relaciones del Artefacto Componente Operacional del Sistema Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Desarrollador Implementacin No aplica No aplica No posee Criterios de Aceptacin Este artefacto determina la precisin mnima requerida o las caractersticas especficas de funcionamiento necesarias para que los resultados obtenidos en las pruebas e inspecciones puedan garantizar la adecuacin del producto a sus especificaciones. Este artefacto describe cmo el cliente evaluar los entregables del proyecto y bajo qu condiciones aceptar el producto, incluyendo los casos de pruebas del proyecto a ejecutarse.
89
Es responsabilidad del equipo de gestin del proyecto y del cliente acordar los criterios de aceptacin del producto y efectuar las pruebas necesarias que verifiquen dichos criterios. Los criterios de aceptacin son capturados a travs de: El artefacto Trminos de Referencia del Sistema El artefacto Casos de Prueba. Relaciones del Artefacto Criterios de Aceptacin Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Involucrados Pruebas Plan de Pruebas No aplica Si posee Datos de Pruebas Este artefacto define una lista de variables y sus posibles valores a introducir para la ejecucin de las pruebas, as como tambin los resultados esperados de la ejecucin para propsitos comparativos. Se pueden tomar en cuenta valores especficos o describir rangos de valores. Los Datos de Pruebas se utilizan como fuente de engao al objeto de prueba y as encontrar errores. Cabe destacar que cada caso de prueba deber ser ejecutado una vez por cada combinacin de valores. Relaciones del Artefacto Datos de Pruebas Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Probador Pruebas Plan de Pruebas No aplica Si posee
90
MeRinde Gua Detallada Documento de Arquitectura del Negocio (DAN) El DAN ayuda a conocer la realidad del negocio, ya que proporciona una visin general de los objetivos, estructura y funcionamiento del negocio. Este describe el qu, por qu y cmo 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 Organizacin, Vista Geogrfica, Vista del Recurso Humano, Vista del Dominio y Vista de Comunicacin. 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 continuacin. 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 slo se debe tomar en cuenta si se estarn tomando decisiones con respecto a la estrategia del negocio, para mostrar cmo la arquitectura del negocio es afectada o en los casos dnde la estrategia del negocio puede verse influenciada por las decisiones referidas a la arquitectura. En este sentido la realizacin 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 relacin existente entre los actores del negocio y los casos de uso del negocio. Es significativo identificar la jerarqua de actores del negocio y realizar un diagrama de clases con ellos. Esta vista es obligatoria.
91
MeRinde Gua Detallada Vista de la Organizacin: Esta vista es inicialmente un subconjunto del Artefacto Modelo de Anlisis del Negocio, incluyendo elementos que son significativos para la arquitectura del negocio. Como el Modelo de Anlisis del Negocio es refinado en el artefacto Modelo de Diseo del Negocio, la vista de la organizacin cambia para mostrar cmo se enlazan los roles en el negocio a las personas, software y hardware. La Vista de la Organizacin describe a los trabajadores ms importantes, entidades y eventos del negocio, su agrupacin en los sistemas del negocio, y la organizacin de stos en capas. Tambin incluye las realizaciones de los casos de uso del negocio ms importantes y descripciones de los modelos generales de conducta. Su realizacin es obligatoria. Vista Geogrfica: Muestra la distribucin de la estructura de la organizacin, funciones y recursos a travs de las localizaciones fsicas como las ciudades y pases. Esta vista emplea un diagrama de clases donde cada locacin es una clase, y tambin 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 distribucin geogrfica de las operaciones del negocio en los procesos del negocio y la estructura. Vista de Recurso Humano: Describe los perfiles de remuneracin y los mecanismos de incentivo, las caractersticas y mecanismos culturales ms importantes, el ambiente de competencia, aspectos referentes a educacin y mecanismos de entrenamiento. Esta vista slo se realiza si la reorganizacin implica cambios significativos en la forma de trabajar de las personas y las relaciones entre ellas, por lo tanto es opcional.
92
MeRinde Gua Detallada Vista del Dominio: Se refiere a los elementos ms importantes de un Modelo de Anlisis para la organizacin. Describe los principales conceptos del negocio y estructuras de la informacin usadas por el negocio. Es opcional, ya que slo se realiza si la informacin 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 comunicacin y el entendimiento entre los diferentes departamentos, proyectos o externos. Vista de Comunicacin: Describe las vas de comunicacin dentro del negocio. Es opcional y por la tanto slo se realiza si se quiere entender los cambios internos y externos en la comunicacin. Relaciones del Artefacto Documento de Arquitectura del Negocio (DAN) Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Involucrados Modelado del Negocio No aplica No aplica Si posee
Documento de Arquitectura del Software (DAS) Es una especificacin de las ideas principales del diseo. El DAS proporciona una descripcin entendible de la arquitectura del sistema software y sirve como medio de comunicacin entre el arquitecto de software y otros miembros de equipo del proyecto con respecto a las decisiones arquitectnicamente 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 Lgica, Vista de Implementacin, Vista del Proceso, Vista de Implantacin y Vista de Datos.
93
MeRinde Gua Detallada Las vistas involucradas en el Documento de Arquitectura del Software (DAS) se detallan a continuacin. Vista de Casos de Uso: Esta vista muestra la funcionalidad del sistema como es percibida desde el exterior. As como tambin describe un conjunto de escenarios y casos de uso que tienen una cobertura arquitectnicamente significativa o que ilustran un punto especfico de la arquitectura. Es un subconjunto del Modelo de Casos de Uso y adems su realizacin es obligatoria. Vista Lgica: Describe el diseo ms importante de las clases y su organizacin en paquetes y subsistemas, y la organizacin de stos en capas. Tambin contiene algunas realizaciones de casos de uso. Esta muestra cmo la funcionalidad es diseada en el interior del sistema, en trminos de la estructura esttica y comportamiento dinmico del sistema. Es un subconjunto del Modelo de Casos de Uso y su realizacin es obligatoria. Vista de Implementacin: Esta vista muestra la organizacin del cdigo y el cdigo actual de ejecucin. Contiene una visin general del Modelo de Implementacin y su organizacin en trminos de mdulos en paquetes y capas. Tambin se describe la asignacin de paquetes y clases de la Vista Lgica a los paquetes y mdulos de la Vista de Implementacin. Es un subconjunto del Modelo de Implementacin. Esta vista es opcional, ya que slo se realiza en los casos donde la implementacin no se conduce estrictamente por el diseo. Si el empaquetado de los modelos de diseo y de implementacin son idnticos, esta vista puede ser omitida. Vista de Procesos: En esta vista se describe las tareas, sus interacciones y configuraciones, y la asignacin de objetos del diseo y clases a las tareas. Muestra los elementos relacionados con el desempeo incluyendo escalabilidad, concurrencia y tiempo base de desempeo. Es un subconjunto del Modelo de Diseo y se usa slo 94
MeRinde Gua Detallada si el sistema tiene un grado significante de concurrencia, por lo tanto es una vista opcional. Vista de Implantacin: Describe varios nodos fsicos para las
configuraciones ms tpicas de las plataformas y la asignacin de las tareas de la Vista del Proceso a los nodos fsicos. un nodo, por lo tanto es opcional. Vista de Datos: Esta vista especifica arquitectnicamente los elementos constantes en el Modelo de Datos. Describe una apreciacin global del modelo de los datos y su organizacin por lo que se refiere a las tablas, vistas y almacenamiento de los procedimientos que proporcionan la persistencia al sistema. Tambin describe la cartografa de clases constantes de la Vista Lgica a la estructura de los datos de la base de datos. Esta vista es opcional, ya que slo se realiza si la persistencia es un aspecto significante del sistema y el traslado del Modelo de Diseo al Modelo de Datos no se hace automticamente por el mecanismo de persistencia. Relaciones del Artefacto Documento de Arquitectura del Software (DAS) Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Arquitecto de Software Anlisis y Diseo No aplica No aplica Si posee Es un subconjunto del Modelo de Implantacin. Esta vista se realiza slo si el sistema es distribuido a travs de ms de
Elemento de Implementacin El elemento de implementacin es un artefacto que representa el ms bajo nivel de composicin de un componente de software, es decir, un conjunto de 95
MeRinde Gua Detallada elementos de implementacin son los que conforman a un componente del sistema. Este artefacto puede ser un cdigo fuente, un cdigo binario, un archivo, un ejecutable, entre otros. Relaciones del Artefacto Elemento de Implementacin Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Desarrollador Implementacin Modelo de Implementacin No aplica No posee
Elemento de Soporte de Prueba Este artefacto contribuye a facilitar las pruebas que se van a ejecutar al sistema, tanto manuales como automticas. Es un elemento que realiza una funcin especfica para una determinada prueba que el software soporta. Estos artefactos comnmente son creados modificados en paralelo con los elementos componentes que estn siendo implementados. Dos ejemplos de esta clase de artefacto son: Cuando se implementa una determinada interfaz salida para informar cuando se produce una accin especfica en el sistema. Cuando se simula la funcin 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: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Desarrollador Implementacin Modelo de Implementacin No aplica No posee 96
MeRinde Gua 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 implantacin, ya que el sistema puede contener varias unidades de implantacin. Cabe destacar que dichas unidades de implantacin que rene el sistema pueden ser exportadas a una unidad de almacenamiento. Relaciones del Artefacto Sistema Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Involucrados Implantacin No aplica Lista de Materiales Artefactos de Instalacin Unidad de Implantacin
Plantilla:
No posee
Entidad del Negocio Este artefacto representa una pieza de informacin significativa que es manipulada por los actores y trabajadores del negocio. Se refiere al estado de la informacin que pasar entre cada capa como un conjunto de datos que la identifican una entidad. Las entidades del negocio de una aplicacin representa entidades reales y adems suelen ser sustantivos, como por ejemplo: Cliente, Nmina, Factura, Depsito, 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 Gua Detallada Relaciones del Artefacto Entidad del Negocio Rol Responsable: Disciplina: Artefactos Contenedores: Involucrados Modelado del Negocio
Modelo de Anlisis del Negocio Modelo de Diseo del Negocio
Artefacto(s) Contenido(s): Plantilla:
No aplica No posee Escenarios por Casos de Uso
Este artefacto se representa a travs de una matriz en la cual se indica los escenarios que contiene un caso de uso. Esta matriz contiene la identificacin del escenario, el flujo bsico y los flujos alternos del escenario. Cabe destacar que cada flujo o combinacin de ellos es un posible escenario que puede ser ejecutado y probado. Relaciones del Artefacto Escenarios por Casos de Uso Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Probador Pruebas Plan de Pruebas No aplica Si posee Especificacin de Migracin de Datos Este artefacto debe contener el perfil de los datos que van ser migrados, as mismo se debe incluir la relacin entre la fuente de los datos con la base de datos a la cual sern migrados.
98
MeRinde Gua Detallada Relaciones del Artefacto Especificacin de Migracin de Datos Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Arquitecto de Software Anlisis y Diseo No aplica No aplica No posee
Especificacin 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, caractersticas del diseo, y otros elementos desarrollar. Los requerimientos pueden ser levantados con diferentes herramientas, tambin se pueden encontrar dispersos en varios artefactos y herramientas. Es por ello, que esta metodologa 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 evolucin del sistema durante toda el ciclo de desarrollo del proyecto, cuando las nuevas caractersticas son aadidas o modificadas al artefacto de visin, son aclarados dentro del artefacto ERS. Las decisiones hechas escribiendo el ERS estn basadas en informacin 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 diseo del sistema. Cualquier requerimiento funcional o no funcional que no sea identificado en el ERS, no debe aparecer en el producto final. 99 necesarios para proporcionar una descripcin completa y comprensiva de los requerimientos para el software a
MeRinde Gua Detallada Relaciones del Artefacto Especificacin de Requerimientos del Software (ERS) Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Analista de Producto Requerimientos No aplica
Modelo de Caso de Uso Especificaciones Suplementarias
Plantilla:
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, desempeo, mantenibilidad, seguridad, restricciones de diseo, requerimientos de documentacin en lnea 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: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Analista de Producto Requerimientos Especificacin de Requerimientos del Software (ERS) No aplica Si posee Evaluacin de la Organizacin Objetivo (EOO) Este artefacto describe la situacin actual en que se encuentra la organizacin objetivo, es decir, la organizacin en la que el sistema ser implantado. La 100
MeRinde Gua Detallada descripcin est en trminos de procesos actuales, herramientas, competencias entre personas, actitudes de las personas, clientes, competidores, tendencias tcnicas, problemas y reas de mejora. El EOO tambin es usado para crear motivacin y comprensin entre las personas en la organizacin objetivo que son directamente o indirectamente afectadas, as como tambin explicar al involucrado por qu existe la necesidad de cambiar los procesos del negocio, y adems proporcionar la entrada al Marco de Desarrollo y al Plan de Iteracin. Relaciones del Artefacto Evaluacin de la Organizacin Objetivo (EOO) Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Involucrados Modelado del Negocio No aplica No aplica Si posee
Glosario del Sistema Es una lista que contiene las definiciones de los trminos a hacer utilizados durante la realizacin del proyecto, que deben ser comprendidos por los participantes de tal manera que haya una buena comunicacin y evitar interpretaciones dispares o ambiguas de los trminos del dominio del problema. Documentar las definiciones de trminos y acrnimos ayuda a otros artefactos a ser ms concisos y precisos. En algunos proyectos donde la planeacin del negocio y del dominio no se realiza, el Glosario es el artefacto principal para capturar la informacin sobre el dominio de negocio del proyecto.
101
MeRinde Gua Detallada Relaciones del Artefacto Glosario del Sistema Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Analista de Producto Requerimientos No aplica No aplica Si posee
Herramientas Este artefacto corresponde con las herramientas necesarias para apoyar el esfuerzo de desarrollo del software. Cabe destacar que un proceso de Ingeniera 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: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Involucrados Gestin del Ambiente Infraestructura de Desarrollo No aplica 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 tambin 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 elaboracin del producto, una infraestructura estndar debe existir para permitir que ocurra el esfuerzo de
102
MeRinde Gua Detallada desarrollo, otra infraestructura se puede configurar para las pruebas realizadas dentro de la organizacin 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: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Involucrados Gestin del Ambiente No aplica Herramientas No posee
Licitacin de Personal Este artefacto es una orden generada si se desea contratar personal externo a la organizacin para el desarrollo del proyecto especificado en el artefacto Trminos de Referencia del Sistema. El artefacto puede ser una oferta que consista en realizar un concurso pblico para organizaciones de diversa ndole de base tecnolgica como cooperativas y empresas interesadas en participar en el desarrollo del sistema. Relaciones del Artefacto Licitacin de Personal Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Lder del Proyecto Gestin del Proyecto No aplica No aplica No posee
103
MeRinde Gua Detallada Lineamientos del Proyecto En este artefacto se detallan las prescripciones necesarias para ejecutar determinadas tareas durante el proyecto, adems es donde se captura cualquier decisin que involucre la modificacin o adaptacin de algn artefacto y debe ser empleado por todos los miembros del proyecto para la ejecucin de las actividades que le han sido asignadas. Generalmente los lineamientos para la elaboracin de los proyectos son controlados y establecidos por un grupo de personas internos a la organizacin 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: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Involucrados Gestin del Ambiente Marco de Desarrollo No aplica No posee
Lista de Ideas de las Pruebas Este artefacto contiene las ideas que potencialmente sern las pruebas ms 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 estn inasequibles o incompletos. Pueden estar contenidas dentro del Plan de Pruebas en la seccin de Ideas Inciales y otras Fuentes de referencia.
104
MeRinde Gua Detallada Relaciones del Artefacto Lista de Ideas de las Pruebas Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Probador Pruebas Plan de Pruebas No aplica Si posee
Lista de Materiales Este artefacto lista los componentes de una versin dada de un producto y define donde los componentes fsicos pueden ser encontrados. Adems, describe los cambios realizados en la versin y se refiere a la forma en que el producto puede ser instalado. Relaciones del Artefacto Lista de Materiales Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Lder del Proyecto Implantacin El Sistema No aplica No posee
Manual de Instalacin El manual de instalacin es un artefacto que refleja los lineamientos que hay que seguir para instalar el sistema. Contiene informacin sobre la infraestructura de instalacin e instrucciones para la instalacin y actualizacin del software.
105
MeRinde Gua Detallada Relaciones del Artefacto Manual de Instalacin Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Involucrados Implantacin No aplica No aplica Si posee Manual de Usuario Este artefacto provee una ayuda a las personas que manipularn 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 bsicos para elaborar los planes de pruebas y los casos de pruebas, y permite la elaboracin de sistemas automatizados para las pruebas. Segn el tipo de sistema se define el comienzo del desarrollo del Manual de Usuario. Sistemas con interfaces complejas o con mucha interaccin requerirn versiones tempranas del manual de usuario as como de prototipos de interfaces. Sistemas con poca interaccin probablemente no requieran que la documentacin del usuario se elabore muy temprano. Relaciones del Artefacto Manual de Usuario Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Involucrados Implantacin No aplica No aplica Si posee 106
MeRinde Gua Detallada Mapa de Navegacin Este artefacto expresa la estructura de los elementos de la interfaz de usuario del sistema, junto a los caminos de navegacin principales. Este permite al usuario una adecuada navegacin en el sistema y sobre todo saber en qu punto del sistema se encuentra y hacia donde puede ir. Sin un Mapa de Navegacin no se podra aprovechar al mximo un sistema. Cabe destacar que existir solamente uno de estos artefactos en el sistema. Relaciones del Artefacto Mapa de Navegacin Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Arquitecto de Software Anlisis y Diseo No aplica No aplica No posee
Marco de Desarrollo El Marco de Desarrollo no es ms que una configuracin 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 cmo cada objetivo especfico propuesto debe irse cumpliendo, y cules van a ser las normativas para el proyecto. Este artefacto tambin es conocido como el proceso especfico del proyecto, y no es ms que un artefacto que permite ajustar la configuracin de la metodologa 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 Gua Detallada Como se ha especificado con anterioridad, conforme al proyecto se deben definir cules son los elementos a emplear de la presente metodologa, este artefacto fue diseado precisamente con la idea de ofrecer los mecanismos para poder organizar los aspectos metodolgicos a considerar para el ciclo de vida del proceso de desarrollo del sistema. Relaciones del Artefacto Marco de Desarrollo Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Involucrados Gestin del Ambiente No aplica Lineamientos del Proyecto Si posee
Material de Adiestramiento El propsito del Material de Adiestramiento, dependiendo de los requerimientos del proyecto, es ensear a los usuarios cmo 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: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Involucrados Implantacin No aplica No aplica No posee Mecanismo de Retroalimentacin 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 caractersticas disponibles y en lo posible, 108
MeRinde Gua Detallada retroalimentar a sus desarrolladores con el descubrimiento de fallos y haciendo sugerencias en cuanto a la funcionalidad, etc. Relaciones del Artefacto Mecanismo de Retroalimentacin Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Involucrados Implantacin No aplica No aplica No posee
Modelo de Anlisis Este modelo es usado para representar la estructura global del sistema, describe la realizacin de casos de uso, sirve como una abstraccin del Modelo de Diseo y se centra en los requerimientos no funcionales. Este modelo de anlisis 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 tambin 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 apreciacin global conceptual del sistema. El Modelo de Anlisis puede contener: las clases y paquetes de anlisis, 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 diseo donde se recomienda que se encuentre. A diferencia del Modelo de Casos de Uso que captura la funcionalidad del sistema, el Modelo de Anlisis da forma a la arquitectura para soportar las funcionalidades que en el anterior modelo se expresa. 109
MeRinde Gua Detallada Para representar los diagramas del Modelo de Anlisis se pueden emplear diferentes diagramas de UML tales como: Diagramas de Clase. Diagramas de Secuencia Relaciones del Artefacto Modelo de Anlisis Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Arquitecto de Software Anlisis y Diseo No aplica No aplica No posee
Modelo de Anlisis del Negocio Este modelo es interno al negocio, describe la realizacin de los casos de uso del negocio, para lo cual detalla cmo 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 recprocamente. 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 Anlisis define los trabajadores internos de negocio y la informacin que ellos emplean (entidades de negocio). Describe su organizacin estructural en unidades independientes (sistema de negocio) y precisa cmo ellos interactan para ejecutar el comportamiento sealado en los casos de uso de negocio. El Modelo de Anlisis del Negocio puede contener: los diagramas, trabajadores, sistemas, entidades, reglas, las relaciones, colaboraciones, entre otros elementos del negocio.
110
MeRinde Gua Detallada Para representar los diagramas del Modelo de Anlisis del Negocio se pueden emplear diferentes diagramas de UML tales como: Diagramas de Colaboracin. Diagramas de Secuencia. Diagrama de Anlisis del Negocio. Diagramas de Actividad. Diagramas de Estado. Relaciones del Artefacto Modelo de Anlisis del Negocio Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Involucrados Modelado del Negocio No aplica

Entidad del Negocio Reglas del Negocio Trabajador del Negocio
Plantilla:
No posee
Modelo de Casos de Uso Este artefacto se basa en la descripcin 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 trminos de las interacciones que ste ejecuta con el sistema. El modelado de casos de uso es una tcnica 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 Gua Detallada adems proporciona la entrada fundamental para el anlisis, el diseo, la implementacin 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: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Analista de Producto Requerimientos Especificacin de Requerimientos del Software (ERS) No aplica No posee
Modelo de Casos de Uso del Negocio Este modelo permite visualizar el alcance de la organizacin, representando lo que abarca y cules son sus lmites. As mismo, modela las actividades y procesos qu ejecuta una organizacin, seala grficamente las funciones y metas que persigue el negocio, y tambin permite identificar cules son los entregables y roles dentro de la organizacin. 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 organizacin 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 Gua Detallada Para representar los diagramas del Modelo de Casos de Uso se puede emplear el diagrama de UML de estereotipo llamado <<Caso de Uso del Negocio>>. Relaciones del Artefacto Modelo de Casos de Uso del Negocio Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Involucrados Modelado del Negocio No aplica No aplica No posee
Modelo de Datos Describe la representacin fsica y lgica de los datos constantes utilizados por la aplicacin. 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 automticamente ni mecnicamente de la estructura persistente de clases en el Modelo de Diseo. Se usa para definir la relacin entre las constantes clases del diseo y las estructuras de datos, y para definir las mismas estructuras de datos constantes.
113
MeRinde Gua Detallada Relaciones del Artefacto Modelo de Modelo de Datos Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Arquitecto de Software Anlisis y Diseo No aplica No aplica No posee
Modelo de Diseo Es una abstraccin del Modelo de Implementacin y su cdigo fuente, el cual fundamentalmente se emplea para representar y documentar su diseo. Es usado como entrada esencial en las actividades relacionadas a implementacin. Representa a los casos de uso en el dominio de la solucin. El Modelo de Diseo 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 Diseo se pueden emplear diferentes diagramas de UML tales como: Diagramas de Clase. Diagramas de Colaboracin. Diagramas de Estado. Diagramas de Paquetes. Diagramas de Secuencia.
114
MeRinde Gua Detallada Relaciones del Artefacto Modelo de Diseo Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Arquitecto de Software Anlisis y Diseo No aplica Plantilla: Capsula Realizaciones de los Casos de Uso
No posee
Modelo de Diseo del Negocio Este artefacto es un refinamiento del Modelo de Anlisis del Negocio, por lo que describe en mayor detalle el cmo el negocio trabaja internamente para llevar a cabo las funciones que ejecuta. Este artefacto se recomienda emplear cuando con la implantacin del sistema que se tiene estimado existirn cambios del negocio en sus procesos, en las responsabilidades de los roles o en la estructura de la organizacin. El Modelo de Diseo 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 Diseo del Negocio se pueden emplear diferentes diagramas de UML tales como: Diagramas de Colaboracin. Diagramas de Secuencia. Diagrama de Anlisis del Negocio. Diagramas de Actividad. Diagramas de Estado. 115
MeRinde Gua Detallada Relaciones del Artefacto Modelo de Diseo del Negocio Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Involucrados Modelado del Negocio No aplica

Entidad del Negocio Realizaciones de los Casos de Uso del Negocio Trabajador del Negocio
Plantilla:
No posee
Modelo de Implantacin Seala la configuracin de nodos de procesamiento existentes en tiempo de ejecucin y cada uno de los componentes y objetos que residen en ellos, lo cual representa la implantacin de los componentes del sistema en desarrollo sobre los dispositivos fsicos que se dispondrn para la ejecucin del sistema. As mismo, seala como se llevar a cabo la comunicacin entre dichos nodos. Este modelo es opcional para sistemas con un solo procesador para sistemas simples que tienen poca o ninguna distribucin de procesos. El Modelo de Implantacin puede contener uno o varios diagramas, nodos, dispositivos y conectores. Para representar los diagramas del Modelo de Implantacin se puede emplear el diagrama de UML de Implantacin (Despliegue).
116
MeRinde Gua Detallada Relaciones del Artefacto Modelo de Implantacin Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Arquitecto de Software Anlisis y Diseo No aplica No aplica No posee
Modelo de Implantacin del Negocio El objetivo de este artefacto es relacionar los elementos lgicos que se han detallado en los modelos de Casos de Uso, Anlisis y Diseo del Negocio con los elementos fsicos que tienen asociados, lo cual podra ser representado mediante localizaciones geogrficas y sus caractersticas, canales de comunicacin empleados y sus propiedades, entre otros recursos fsicos. Para representar los diagramas del Modelo de Implantacin del Negocio se puede emplear el diagrama de UML de estereotipo llamado <<Modelo de Implantacin del Negocio>>. Relaciones del Artefacto Modelo de Implantacin del Negocio Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Involucrados Modelado del Negocio No aplica No aplica No posee
117
MeRinde Gua Detallada Modelo de Implementacin El Modelo de Implementacin es comprendido por un conjunto de componentes y subsistemas que constituyen la composicin fsica de la implementacin del sistema. Entre los componentes podemos encontrar datos, archivos, ejecutables, cdigo fuente y los directorios. Fundamentalmente, se describe la relacin que existe desde los paquetes y clases del modelo de diseo a subsistemas y componentes fsicos. Este artefacto describe cmo se implementan los componentes,
congregndolos en subsistemas organizados en capas y jerarquas, y seala las dependencias entre stos. Para representar los diagramas del Modelo de Implementacin se puede emplear el diagrama de UML de Componentes. Relaciones del Artefacto Modelo de Implementacin Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Arquitecto de Software Implementacin No aplica

Elemento de Implementacin Subsistema de Implementacin Elemento de Soporte de Prueba
Plantilla:
No posee
Modelo de Servicio Este artefacto se emplea para concebir y documentar el diseo de los servicios que estarn presentes en el sistema a desarrollar. Adicionalmente, es la base de los
118
MeRinde Gua 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 <<Modelo de Servicio>>. Relaciones del Artefacto Modelo de Servicio Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Arquitecto de Software Anlisis y Diseo No aplica No aplica No posee
Notas de Lanzamiento Este artefacto contiene las notas de entrega para la versin x.y.z del producto. Aqu se detalla la entrega y se provee informacin de ltima hora y otros datos que complementan la documentacin principal. Incluye la descripcin 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 tcnico encargado de redactar el material de soporte a los usuarios encontrarn las notas de lanzamiento tiles para conducir sus actividades. 119
MeRinde Gua Detallada Relaciones del Artefacto Notas de Lanzamiento Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Lder del Proyecto Implantacin No aplica No aplica Si posee
Oferta de Servicio del Personal Este artefacto describe la oferta de servicio del personal de desarrollo para su seleccin y contratacin. Este incluye el propsito, las actividades, tiempo y forma de pago para un servicio en particular. Relaciones del Artefacto Oferta de Servicio del Personal Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Lder del Proyecto Gestin del Proyecto No aplica No aplica No posee
Orden de Trabajo Este artefacto es el mecanismo por medio del cual el Lder del Proyecto comunica los planes a los miembros del equipo del proyecto de lo que se har y cundo dentro de las iteraciones. Esta orden puede ser desde ejecutar una actividad un conjunto, bajo una planificacin definida y con unos determinados entregables, esfuerzo, alcance y restricciones de recursos. Su representacin depende directamente de los mecanismos internos de la organizacin para la gestin de personal.
120
MeRinde Gua Detallada Relaciones del Artefacto Orden de Trabajo Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Lder del Proyecto Gestin del Proyecto No aplica No aplica No posee Plan de Adiestramiento Muestra el plan detallado de adiestramiento. El propsito de este plan es que las personas que vayan a utilizar el sistema, se capaciten para su utilizacin 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 sern impartidos a los usuarios finales para ensearles el uso, operacin y mantenimiento del sistema. Relaciones del Artefacto Plan de Adiestramiento Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Involucrados Implantacin No aplica No aplica Si posee Plan de Gestin de Configuracin Este documento describe todas las actividades de Gestin de Configuracin y Cambios que sern 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 Gua Detallada El Plan de Gestin de Configuracin contiene informacin 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 visin general en otro plan, suministre los detalles ms significativos en este plan y haga referencias necesarias desde los otros planes hacia este plan. Asegrese que las secciones de este artefacto cubran solamente las reas que no han sido cubiertas anteriormente en otro lugar. Relaciones del Artefacto Plan de Gestin de Configuracin Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Lder del Proyecto Gestin de Configuracin y Cambios No aplica No aplica No posee
Plan de Gestin de Riesgos Artefacto en el cual se describe los posibles riesgos de recursos, tcnicos, o del negocio implicados en el proyecto, y formula un plan para abordar los posibles riesgos, con medidas de mitigacin 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 Gestin del Riesgo debe ser documentado a comienzos del proyecto, durante la fase de inicio. El plan es emprendido ante la fase de elaboracin para asegurar que ninguno los riesgos identificados sean direccionados durante la misma fase de elaboracin. Apenas el plan haya sido documentado, el proceso de
122
MeRinde Gua Detallada prevencin de riesgos estar ocupado para monitorear y controlar la probabilidad y el impacto de los riesgos sobre el proyecto. Relaciones del Artefacto Plan de Gestin de Riesgos Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Lder del Proyecto Gestin del Proyecto No aplica No aplica Si posee
Plan de Implantacin 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 transicin sencilla para el cliente, para ello se debe minimizar el impacto que la implantacin del sistema pueda llegar a causar en el personal del cliente, los sistemas de produccin 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 instalacin del nuevo sistema, instrucciones especficas sobre la sustitucin de antiguos sistemas, compatibilidad del sistema, y estrategias de migracin y adaptacin 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 especficos, entre otros.
123
MeRinde Gua Detallada Relaciones del Artefacto Plan de Implantacin Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Lder del Proyecto Implantacin No aplica No aplica Si posee Plan de Integracin Este documento muestra un plan detallado de la integracin dentro de una iteracin. El propsito de este plan es definir el orden en que los componentes del sistema deben llevarse acabo, los resultados al integrar el sistema y cmo sern evaluados. Es recomendando ajustar el plan de integracin confirme a la magnitud del proyecto, si el proyecto es grande debe realizar una serie de estos documento para cada integracin de componentes, as mismo si el mdulo del sistema a integrar es crtico se recomienda que para esta integracin se realice un plan individual. Relaciones del Artefacto Plan de Integracin Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Desarrollador Implementacin No aplica No aplica Si posee Plan de Iteracin 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 iteracin del ciclo de vida del proyecto un artefacto de este tipo. 124
MeRinde Gua Detallada Para cada iteracin existe una serie de objetivos los cuales son usados como referencia de evaluacin para determinar diferentes aspectos, como grado de terminacin de una determinada funcin, rendimiento, niveles de calidad, etc. Para cada plan de iteracin es necesario detallar la programacin estimada para la iteracin, los recursos a emplear, los casos de uso y escenarios que van ser tomados en cuenta y finamente se deben establecer los criterios de evaluacin que se van a tener para la iteracin. Es recomendable para las iteraciones emplear herramientas para la planeacin de proyectos con el fin de hacer mas fcil y organizada esta tarea, de ser empleada cualquier herramienta sus resultados debe ser reflejados en el plan de iteracin. Para poder definir una iteracin es necesario tomar en cuenta: La planificacin 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 nmero 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 iteracin. La lista de los cambios que deben ser incorporados (correccin de errores, cambios de requerimientos.) Los riegos que se pueden correr en la iteracin. Relaciones del Artefacto Plan de Iteracin Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Lder del Proyecto Gestin del Proyecto No aplica No aplica Si posee
125
MeRinde Gua Detallada Plan de Pruebas Es la coleccin formada por los casos de prueba y procedimientos de prueba. Este artefacto incluye el propsito 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 tambin se reflejan las caractersticas de hardware y
software que sern empleados para realizar el conjunto de las pruebas al sistema. Relaciones del Artefacto Plan de Pruebas Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Involucrados Pruebas No aplica

Casos de Prueba Criterios de Aceptacin Datos de Pruebas Escenarios por Casos de Uso Lista de Ideas de Pruebas Resumen del Ciclo de Prueba
Plantilla:
Si posee Planificacin del Proyecto
Este documento est compuesto por toda la informacin necesaria para llevar a cabo la direccin del proyecto. Es utilizado por la direccin 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 (gestin de riesgos, aseguramiento de calidad, resolucin de problemas, entre otros).
126
MeRinde Gua Detallada Relaciones del Artefacto Planificacin del Proyecto Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Lder del Proyecto Gestin del Proyecto No aplica No aplica Si posee
Plantillas para el Proyecto Comprende el conjunto de plantillas que ayudarn a los responsables del proyecto a elaborar los artefactos considerados para el desarrollo del sistema. Relaciones del Artefacto Plantillas para el Proyecto Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Involucrados Gestin del Ambiente No aplica No aplica No posee Prototipo de la Interfaz de Usuario Este documento contiene todo lo relacionado con la interfaz. Son elementos de diseo visual que permiten al usuario tener una idea de las interfaces que mostrar el sistema, para obtener una retroalimentacin sobre los requerimientos del sistema. Se realizan unas cuantas imgenes de pantalla o un esqueleto de interfaz de usuario ejecutable. El propsito de crear interfaces de usuario es para probar el diseo 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 Gua 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: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Arquitecto de Software Anlisis y Diseo No aplica No aplica No posee
Prueba de Concepto Arquitectnico del Negocio Este artefacto es una solucin que simplemente puede ser conceptual a los requerimientos arquitectnicamente significativos del negocio. El propsito de la Prueba de Concepto Arquitectnico del Negocio es determinar si existe, o es probable que exista, una solucin (o un sistema de soluciones) que satisfaga los requerimientos arquitectnicamente significativos. Relaciones del Artefacto Prueba de Concepto Arquitectnico del Negocio Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Involucrados Modelado del Negocio No aplica No aplica 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 especfico. La realizacin del caso de uso debe cumplir con los
128
MeRinde Gua Detallada requerimientos establecidos y debe reflejar el comportamiento de su caso de uso correspondiente. Este artefacto se halla dentro del Modelo de Diseo 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 comunicacin y secuencia que expresan el comportamiento del caso del uso en trminos de objetos de colaboracin, y dichos diagramas deben elaborarse haciendo uso del Lenguaje de Modelado Unificado (UML). Relaciones del Artefacto Realizaciones de los Casos de Uso Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Arquitecto de Software Anlisis y Diseo Modelo de Diseo No aplica No posee
Realizaciones de los Casos de Uso del Negocio Este artefacto expresa la colaboracin 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 realizacin de casos de uso del negocio describe la manera en que estos pasos se realizan dentro de la organizacin. Adems, las Realizaciones de los Casos de uso del Negocio son utilizadas por los involucrados para verificar que el equipo del proyecto y dems involucrados entienden la estructura y el funcionamiento del negocio.
129
MeRinde Gua Detallada Relaciones del Artefacto Realizaciones de los Casos de Uso del Negocio Rol Responsable: Disciplina: Artefactos Contenedores: Artefacto(s) Contenido(s): Plantilla: Involucrados Modelado del Negocio Modelo de Diseo del Negocio No aplica No posee
Registro de Evaluacin Es el documento creado para registrar los resultados obtenidos de una evaluacin aplicada a uno ms artefactos revisados del proyecto. Relaciones del Artefacto Registro de Evaluacin Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Analista de Calidad Gestin del Proyecto No aplica No aplica No posee
Registro de Revisin Este documento es creado para registrar los resultados obtenidos de una revisin aplicada a uno ms 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 revisin de un artefacto en este documento.
130
MeRinde Gua Detallada Relaciones del Artefacto Registro de Revisin Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Mentor Gestin del Proyecto No aplica No aplica 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 mitigacin de los riesgos identificados. En este documento se relaciona cada riesgo identificado con sus acciones preventivas y de contingencia, y es fundamental para la planificacin de las iteraciones. Relaciones del Artefacto Registro de Riesgos Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Involucrados Gestin del Proyecto No aplica No aplica Si posee
Reglas del Negocio Una Regla del Negocio es la declaracin de polticas y restricciones de negocio de una organizacin. Este artefacto consiste en definir una exigencia especfica o invariable que debe satisfacerse por el negocio. Las Reglas del Negocio pueden aplicarse siempre o slo bajo una condicin especfica. Es necesario que la
131
MeRinde Gua Detallada aplicacin muestre las restricciones que existen en el negocio, de tal forma que no sea posible realizar acciones invlidas. Relaciones del Artefacto Reglas del Negocio Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Involucrados Modelado del Negocio Modelo de Anlisis del Negocio No aplica 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 cdigo fuente, documentacin, planes, imgenes, cartas, etc., reflejados en una nueva versin. Puede estar preparado para distribuirse sirvindose de una red informtica como Internet o en un medio fsico como un disco compacto. Este repositorio puede ser de acceso pblico 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: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Lder del Proyecto Gestin de Configuracin y Cambios No aplica No aplica No posee 132
MeRinde Gua Detallada Resultado de Prueba Representa los resultados obtenidos por el Desarrollador al probar los elementos y subsistemas de implementacin 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: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Desarrollador Implementacin No aplica No aplica 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: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Probador Pruebas Plan de Pruebas No aplica Si posee
133
MeRinde Gua Detallada Script de Pruebas Su propsito es proveer la implementacin 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 ejecucin de las pruebas automticamente, en este ltimo caso este artefacto es un programa de software que automatiza la ejecucin de un procedimiento de prueba o una parte de este. Relaciones del Artefacto Solicitud de Cambio Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Probador Pruebas No aplica No posee 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: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Involucrados Gestin de Configuracin y Cambios No aplica No aplica Si posee
134
MeRinde Gua Detallada Solicitudes de Involucrados Es el documento que contiene los requerimientos de cualquier tipo hechos por los involucrados, los cuales deberan estar satisfechos en el sistema a ser desarrollado. Relaciones del Artefacto Solicitudes de Involucrados Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Analista de Producto Requerimientos No aplica No aplica 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 informacin significativa sobre la descripcin del proceso que se quiera crear o mejorar mediante la implantacin de un nuevo sistema, se debe determinar la necesidad del mismo, cules son sus objetivos y se debe plantear cules son los beneficios que este podra llegar a brindar. S existe documentacin relacionada a la solicitud como pueden ser procedimientos, diagramas que reflejen la relacin entre procesos, leyes, resoluciones, decretos, normas en general, etc. deberan ser anexadas. Relaciones del Artefacto Solicitud del Sistema Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Involucrados Gestin del Proyecto No aplica No aplica No posee
135
MeRinde Gua Detallada Subsistema de Implementacin Este artefacto agrupa un conjunto de Elementos de Implementacin. Con el Modelo de Implementacin y con la Vista de Implementacin contenida en el Documento de Arquitectura del Software (DAS) se sealan y se definen cuales son los Subsistemas de Implementacin que componen el sistema. Relaciones del Artefacto Subsistema de Implementacin Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Desarrollador Implementacin Modelo de Implementacin No aplica No posee
Trminos de Referencia para el Equipo de Desarrolladores del Sistema Es el convenio de prestacin de servicios que se estable con la contratista seleccionada para llevar a cabo el proyecto descrito en el artefacto Trminos de Referencia del Sistema. Representa el acuerdo jurdico entre la organizacin que contrata y el contratista a fin de regular las obligaciones, para el proyecto. Relaciones del Artefacto Trminos de Referencia para el Equipo de Desarrolladores del Sistema Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Lder del Proyecto Gestin del Proyecto No aplica No aplica Si posee 136 responsabilidades, actividades, resultados, planificacin y honorarios de los servicios a ser prestados
MeRinde Gua Detallada Trminos de Referencia del Sistema Este artefacto contiene una descripcin del sistema a realizar, los objetivos, las caractersticas tcnicas, alcance y documentos a producirse. Todo proyecto comienza por una necesidad. Identificar plenamente dicha necesidad conlleva tiempo, se requiere recopilar informacin sobre el problema, clarificar la forma ms adecuada de resolverlo, tomar la decisin de ejecutarlo y definir ciertos requisitos que deben cumplir las personas u organizaciones para solventarlos. El artefacto Trminos de Referencia permite al cliente expresar con claridad sus necesidades, problemas u oportunidades y permite al potencial contratista percibir con claridad la dimensin 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 redaccin y entrega de los trminos 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 trminos 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 Trminos de Referencia del Sistema Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Lder del Proyecto Gestin del Proyecto No aplica No aplica Si posee
137
MeRinde Gua Detallada Trabajador del Negocio Un Trabajador del Negocio representa a un ser humano, software o hardware que desempea un rol dentro de las Realizaciones del Caso de Uso del Negocio. Este trabajador interacta 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 desempear varios roles pero slo tiene una posicin en la organizacin. Esta Conceptualizacin permite identificar mejoras en los procesos del negocio y considerar el efecto de la automatizacin del proceso del negocio o del outsourcing de proceso del negocio. Relaciones del Artefacto Trminos de Trabajador del Negocio Rol Responsable: Disciplina: Artefactos Contenedores: Involucrados Modelado del Negocio
Modelo de Anlisis del Negocio Modelo de Diseo del Negocio
Artefacto(s) Contenido(s): Plantilla:
No aplica No posee
Unidad de Implantacin Este artefacto comprende una coleccin de componentes ejecutables, documentos como las notas de lanzamiento y el material de apoyo al usuario, y los artefactos de instalacin. Una Unidad de implantacin se asocia tpicamente a un solo nodo en la red total de los sistemas informticos o de los perifricos. Esta definicin cabe en los casos donde est disponible el producto sobre el Internet, la unidad de implantacin se puede descargar directamente e instalar por el usuario. Cabe destacar 138
MeRinde Gua Detallada que la unidad de implantacin tambin se puede instalar desde un dispositivo de almacenamiento. Relaciones del Artefacto Unidad de Implantacin Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Lder del Proyecto Implantacin El Sistema No aplica No posee
Visin del Negocio Este documento describe los objetivos del esfuerzo de un modelado de
negocio. Proporciona la entrada al proceso de aprobacin 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 propsito del sistema que se desea desarrollar: Creacin de un negocio: consiste en aplicar ingeniera al negocio para crear un nuevo proceso de negocio, una nueva lnea de negocio una nueva organizacin. Reingeniera del negocio: reingeniera es la revisin fundamental y el rediseo radical de procesos del negocio para alcanzar mejoras satisfactorias en medidas crticas y actuales de rendimiento, tales como costos, calidad, servicio y rapidez. El objetivo es hacer las tareas que ya se estn haciendo, pero hacerlo mejor, trabajar ms inteligentemente. Mejoras al Negocio: consiste en aplicar ingeniera al negocio para mejorar algunos procesos locales y que no afectan al negocio entero.
139
MeRinde Gua Detallada Se recomienda aplicar este documento en su totalidad si lo que se va a realizar es una creacin de un negocio o una reingeniera del negocio. Si el propsito es realizar mejoras al negocio se recomienda que se utilice este artefacto pero no en su totalidad sino enfocndose en las secciones de introduccin, Posicin y objetivos del modelado del negocio. Muchos documentos que sirven para este artefacto podran encontrarse ya elaborados dentro de la organizacin, de ser as no es necesario volver a trabajar en general estos, se puede hacer referencia dentro del documento de visin del negocio a estos. Relaciones del Artefacto Visin del Negocio Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Involucrados Modelado del Negocio No aplica No aplica Si posee
Visin 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 descripcin del sistema a ser desarrollado desde la perspectiva de los requerimientos ms importantes. Este documento captura las expectativas de los que soportan el desarrollo del proyecto. Se recomienda que este artefacto se conserve lo ms claro y resumido posible para que pueda llegar lo ms pronto posible a los involucrados en el proyecto y para que sea ms fcil de entender por estos. Este documento debe incluir solamente las principales descripciones de los requerimientos y debe evitar muchos detalles 140
MeRinde Gua Detallada especficos. Adicionalmente lmites del sistema. Relaciones del Artefacto Visin del Sistema Rol Responsable: Disciplina: Artefacto Contenedor: Artefacto(s) Contenido(s): Plantilla: Analista de Producto Requerimientos No aplica No aplica Si posee debe especificar las capacidades operacionales
(volmenes de trabajo, tiempos de respuestas, precisin), perfiles de usuario, y los
141
APNDICE B DESCRIPCIN DE LAS ACTIVIDADES Y TAREAS PROPUESTAS DE MERINDE
142
MeRinde Gua Detallada En este apndice se detallaran todas las actividades y subactividades presentadas en los flujos de trabajos por cada disciplina propuesta en el Captulo VI en la seccin de Disciplinas. Las actividades y subactividades sern listadas agrupadas por disciplinas y en el mismo orden de su aparicin en el mencionado Captulo. As mismo, se proceder a la descripcin de cada una de las tareas que integran cada actividad o subactividades a fin de completar todo la informacin necesaria para poder ejecutar la propuesta MeRinde. Modelado del Negocio Actividades Evaluar el Status del Negocio: Esta actividad busca evaluar la situacin actual del negocio y fijar los objetivos de modelado del negocio. Est conformada por las siguientes tareas: Mantener las Reglas del Negocio. Evaluar la Organizacin 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 Organizacin Objetivo. Analizar la Arquitectura del Negocio.
143
MeRinde Gua Detallada Definir el Negocio: Esta actividad trata sobre definir cul 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 Gua 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. Disear las Realizaciones de los Procesos del Negocio: Con esta subactividad se busca hacer las realizaciones de los casos de uso del negocio en trminos 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 Diseo del Negocio. Explorar la Automatizacin del Proceso: Esta actividad trata sobre analizar las oportunidades de automatizacin para los procesos del negocio en estudio.
145
MeRinde Gua Detallada Est conformada por las siguientes tareas: Definir la Automatizacin de los Requerimientos. Formular la Prueba de Concepto Arquitectnico del Negocio. Desarrollar el Modelo de Dominio: Esta actividad se basa en desarrollar un subconjunto del modelo de anlisis 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 Anlisis del Negocio. Tareas Tabla 4 Tarea: Mantener las Reglas del Negocio
4
Rol Responsable: Involucrados. Descripcin: 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:
Visin del Negocio. Modelo de Anlisis del Negocio (Reglas del Negocio).
Artefacto(s) de Salida:
Tabla 5 Tarea: Evaluar la Organizacin Objetivo

5
Rol Responsable: Involucrados. Descripcin: Esta tarea se refiere a cmo evaluar el estado actual que presenta la organizacin en la que el sistema ser implantado, es decir, la organizacin objetivo. 146
MeRinde Gua Detallada Incluye describir el estado actual en trminos de procesos actuales, herramientas, destrezas, competidores, clientes, etc. Adems, permite identificar los involucrados para el esfuerzo de modelado del negocio. Artefacto(s) de Entrada: No tiene. Artefacto(s) de Salida:
Evaluacin de la Organizacin Objetivo.
Tabla 6 Tarea: Analizar la Arquitectura del Negocio

6
Rol Responsable: Involucrados. Descripcin: Esta tarea se centra en definir una arquitectura del negocio candidata. Se identifican los sistemas, trabajadores y entidades del negocio, as como tambin 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:
Visin del Negocio. Documento de Arquitectura del Negocio. Modelo de Anlisis del Negocio. Modelo de Diseo del Negocio. Modelo de Implantacin del Negocio.

Tabla 7 Tarea: Encontrar los Actores y los Casos de Uso del Negocio
7
Rol Responsable: Involucrados. Descripcin: Esta tarea se basa en definir los actores y casos de uso que interactan
147
MeRinde Gua Detallada con el negocio, as como tambin se enfoca en los lmites 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:
Visin del Negocio. Modelo de Casos de Uso del Negocio.
Tabla 8 Tarea: Priorizar los Casos de Uso del Negocio

8
Rol Responsable: Involucrados. Descripcin: Esta tarea se concentra en identificar y priorizar los casos de uso del negocio arquitectnicamente significativos. Incluye definir un conjunto de escenarios y casos de uso del negocio que tienen una cobertura arquitectnicamente significativa, que dichos casos de uso y escenarios sean analizados en la iteracin en curso y adems sean el centro de cierta funcionalidad significativa. Artefacto(s) de Entrada:

Modelo de Casos de Uso del Negocio. Visin del Negocio. Documento de Arquitectura del Negocio. 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. Descripcin: 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 Gua 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 ms fciles de comprender. Artefacto(s) de Entrada:
Modelo de Casos de Uso del Negocio. Modelo de Casos de Uso del Negocio.
Tabla 10 Tarea: Detallar el Caso de Uso del Negocio

10
Rol Responsable: Involucrados. Descripcin: 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 tambin 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. Modelo de Casos de Uso del Negocio.
Tabla 11 Tarea: Revisar el Modelo de Caso de Uso del Negocio

11
Rol Responsable: Mentor. Descripcin: Esta tarea se refiere a cundo y cmo se lleva a cabo la revisin del artefacto Modelo de Casos de Uso del Negocio y cmo abordar los resultados obtenidos de la revisin. Permite verificar que los resultados de dicho artefacto coincidan con la visin que tienen los involucrados del negocio. Artefacto(s) de Entrada: 149
Modelo de Casos de Uso del Negocio. Registro de Revisin.
Tabla12 Tarea: Realizar los Casos de Uso del Negocio

12
Rol Responsable: Involucrados. Descripcin: Se refiere a cmo desarrollar una realizacin 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. Modelo de Diseo del Negocio (Realizaciones de los Casos de Uso del Negocio).
Tabla 13 Tarea: Detallar los Trabajadores del Negocio

13
Rol Responsable: Involucrados. Descripcin: 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 tambin permite asegurar que este trabajador pueda llevar a cabo sus actividades dentro del negocio. Artefacto(s) de Entrada:
Modelo de Diseo del Negocio (Realizaciones de los Casos de Uso del
150
MeRinde Gua Detallada Negocio).
Modelo de Anlisis del Negocio (Trabajadores del Negocio). Modelo de Diseo del Negocio (Trabajadores del Negocio).
Tabla 14 Tarea: Detallar las Entidades del Negocio

14
Rol Responsable: Involucrados. Descripcin: Esta tarea se basa en describir de manera entendible y suficiente una entidad del negocio. Su propsito 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 Anlisis del Negocio (Entidad del Negocio). Modelo de Anlisis del Negocio (Realizaciones de los Casos de Uso del Negocio).
Modelo de Diseo del Negocio (Entidad del Negocio).
Tabla 15 Tarea: Revisar el Modelo de Diseo del Negocio

15
Rol Responsable: Mentor. Descripcin: Esta tarea define cundo y cmo se conduce la revisin del Modelo de Diseo del Negocio y cmo tratar los resultados de las revisiones. Adems, permite la verificacin formal de que los resultados del artefacto Modelo de Diseo del Negocio coinciden con la visin que tienen los involucrados del negocio. Artefacto(s) de Entrada:
Modelo de Diseo del Negocio.
Artefacto(s) de Salida: 151
Registro de Revisin.
Tabla 16 Tarea: Definir la Automatizacin de los Requerimientos

16
Rol Responsable: Involucrados. Descripcin: En esta tarea se explora las tecnologas candidatas para hacer que la organizacin objetivo sea ms efectiva. Permite determinar el nivel de automatizacin en la organizacin objetivo y obtener los requerimientos del sistema de los artefactos de modelado del negocio. Artefacto(s) de Entrada:
Evaluacin de la Organizacin Objetivo. Especificacin de los Requerimientos del Software (Modelo de Casos de Uso). Especificacin de los Requerimientos del Software (Especificaciones Suplementarias). Modelo de Anlisis.

Tabla 17 Tarea: Formular la Prueba de Concepto Arquitectnico del Negocio

17
Rol Responsable: Involucrados. Descripcin: En esta tarea se describe cmo desarrollar una prueba de concepto arquitectnico en un contexto de negocio basado en los requerimientos ms significativos. Permite sintetizar al menos una solucin de forma conceptual que cubre los requerimientos arquitectnicos crticos. Artefacto(s) de Entrada:
Documento de Arquitectura del Negocio. Prueba de Concepto Arquitectnico del Negocio.
152
MeRinde Gua Detallada Tabla 18 Tarea: Revisar el Modelo de Anlisis del Negocio
18
Rol Responsable: Mentor. Descripcin: Esta tarea define cundo y cmo se ejecuta la revisin del artefacto Modelo de Anlisis del Negocio y cmo abordar los resultados de dicha revisin. Asimismo, permite verificar formalmente que los resultados del artefacto coinciden con la visin que tienen los involucrados del negocio. Artefacto(s) de Entrada:
Modelo de Anlisis del Negocio. Registro de Revisin.
Requerimientos Actividades Analizar el Problema: Esta actividad consiste en estudiar el problema a ser solucionado y proponer una solucin de alto nivel. Est conformada por las siguientes tareas: Establecer la Visin del Sistema. Determinar la Terminologa 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 servirn de solucin. Est conformada por las siguientes tareas: Gestionar Dependencias. 153
MeRinde Gua Detallada Determinar los Actores y los Casos de Uso. Determinar la Terminologa a Usar. Obtener Requerimientos de los Involucrados. Establecer la Visin del Sistema. Desarrollar Especificaciones Suplementarias. Definir el Sistema: En esta actividad se debe definir el alcance del sistema y los requerimientos ms importantes. Est conformada por las siguientes tareas: Gestionar Dependencias. Determinar los Actores y los Casos de Uso. Determinar la Terminologa a Usar. Establecer la Visin del Sistema. Desarrollar Especificaciones Suplementarias. Revisar la Visin 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 iteracin. Est conformada por las siguientes tareas: Gestionar Dependencias. Establecer la Visin del Sistema. Dar Prioridad a los Casos de Uso. Refinar la Definicin 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 Gua Detallada Detallar los Casos de Uso. Detallar los Requerimientos del Software. Desarrollar las Especificaciones Suplementarias. Revisar la Especificacin 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 Visin del Sistema
19
Rol Responsable: Analista de Producto. Descripcin: Esta tarea describe cmo desarrollar la visin total para el sistema, incluyendo el problema a ser solucionado, el alcance, las caractersticas 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 Iteracin. Trminos de Referencia del Sistema. Solicitudes de Involucrados. Visin del Sistema.
155
Tabla 20 Tarea: Determinar la Terminologa a Usar

20
Rol Responsable: Analista de Producto. Descripcin: Esta tarea se refiere a cmo definir el vocabulario comn 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. Descripcin: Se identifican los actores y casos de uso para apoyar los requerimientos que se estn llevando a cabo. El propsito de esta tarea es definir el alcance del sistema y un perfil de la funcionalidad del sistema. Una tcnica 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 Iteracin. Solicitudes de Involucrados. Especificacin de Requerimientos del Software (Modelo de Casos de Uso).
Tabla Tarea: Gestionar Dependencias Rol Responsable: Analista de Producto. Descripcin: En esta tarea se describe cmo hacer uso de las dependencias que existen 156
MeRinde Gua 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:
Visin del Sistema.
Tabla 22 Tarea: Obtener Requerimientos de los Involucrados

22
Rol Responsable: Analista de Producto. Descripcin: Se refiere a la forma de obtener los requerimientos que a los involucrados (clientes, usuarios, etc.) les gustara que el sistema incluyera. Esta tarea permite comprender quines 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. Descripcin: 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 documentacin. Artefacto(s) de Entrada: 157

Plan de Iteracin. Solicitudes de Involucrados. Especificacin de Requerimientos del Software (Especificaciones Suplementarias).
Tabla 24 Tarea: Revisar la Visin del Sistema

24
Rol Responsable: Mentor. Descripcin: Describe cundo y cmo se debe llevar a cabo la revisin del artefacto Visin del Sistema y cmo abordar los resultados de la revisin. Artefacto(s) de Entrada:
Visin del Sistema. Registro de Revisin.
Tabla 25 Tarea: Dar Prioridad a los Casos de Uso

25
Rol Responsable: Arquitecto de Software. Descripcin: Es donde los casos de uso con significado arquitectnico 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:

Especificacin de Requerimientos del Software (Modelo de Casos de Uso). Plan de Iteracin. Registro de Riesgo. Documento de Arquitectura del Software.
158
MeRinde Gua Detallada Tabla 26 Tarea: Detallar los Casos de Uso

26
Rol Responsable: Analista de Producto. Descripcin: En esta tarea se agregan los detalles a un caso de uso especfico. La finalidad de esta tarea es describir con detalles suficientes uno o ms flujos de eventos de los casos de uso, para poder empezar el desarrollo del software. Artefacto(s) de Entrada:

Especificacin de Requerimientos del Software (Modelo de Casos de Uso). Plan de Iteracin. Especificacin de Requerimientos del Software (Modelo de Casos de Uso).
Tabla 27 Tarea: Detallar los Requerimientos del Software

27
Rol Responsable: Analista de Producto. Descripcin: Permite recoger, detallar y organizar el sistema de los artefactos que describen los requerimientos del sistema. Esta tarea asegura que todos los requerimientos estn especificados con el nivel de detalle necesario para que puedan ser entendidos por los diseadores, desarrolladores, probadores y dems roles que participen en el proyecto. Artefacto(s) de Entrada:

Plan de Iteracin. Visin del Sistema. Especificacin de Requerimientos del Software.
Tabla 28 Tarea: Revisar la Especificacin de Requerimientos del Software

28
Rol Responsable: Mentor.
159
MeRinde Gua Detallada Descripcin: Esta tarea define cmo se lleva a cabo la revisin del artefacto Especificacin de Requerimientos del Software (ERS). Su propsito es verificar que los resultados de las actividades de los requerimientos coinciden con la visn que tiene el cliente del sistema. Artefacto(s) de Entrada:
Especificacin de Requerimientos del Software. Registro de Revisin.
Tabla 29 Tarea: Estructurar el Modelo de Casos de Uso

29
Rol Responsable: Analista de Producto. Descripcin: 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 ms fciles de comprender. Artefacto(s) de Entrada:
Especificacin de Requerimientos del Software (Modelo de Casos de Uso). Glosario del Sistema. Especificacin de Requerimientos del Software (Modelo de Casos de Uso). Especificacin de Requerimientos del Software (Especificaciones Suplementarias).

Tabla 30 Tarea: Verificar los Requerimientos

30
Rol Responsable: Lder del Proyecto. Descripcin: En esta tarea se busca verificar que los requerimientos encontrados en el
160
MeRinde Gua Detallada sistema satisfacen las necesidades que fueron planteadas por los clientes. Por otro lado, esta tarea describe cundo y cmo deben ser realizadas las supervisiones, as como tambin plantea cuales deben ser las acciones a tomar en caso de que se encuentren discordancia con lo esperado. Artefacto(s) de Entrada:

Especificacin de Requerimientos del Software. Trminos de Referencia del Sistema. Plan de Iteracin. Registro de Evaluacin.
Anlisis y Diseo 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 diseo del sistema. Est conformada por las siguientes tareas: Identificar los Elementos de Diseo. Analizar los Casos de Uso. 161
MeRinde Gua Detallada Generar Prototipo de la Interfaz de Usuario Disear la Interfaz de Usuario. Revisar el Diseo. Refinar la Arquitectura: Esta actividad refina la arquitectura para una iteracin. Est conformada por las siguientes tareas: Identificar los Elementos de Diseo. Describir la Arquitectura en Tiempo de Ejecucin. Describir la Distribucin. Identificar los Mecanismos de Diseo. Incorporar Elementos de Diseo Existentes. Identificar Servicios. Revisar Artefacto de la Arquitectura. Disear 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: Disear Servicios. Disear los Componentes: Esta actividad refina el diseo del sistema. Est conformada por las siguientes tareas: Disear Clases. Disear Subsistemas. Disear Casos de Uso. Disear Cpsulas. Disear los Elementos Soporte de Prueba. 162
MeRinde Gua Detallada Revisar el Diseo. Disear la Base de Datos: En esta actividad se identifican las clases de diseo que formaran parte de la base de datos del sistema y estructuras de la base de datos. Est conformada por las siguientes tareas: Disear Clases. Disear la Base de Datos. Especificar Migracin de Datos. Revisar el Diseo. Tareas Tabla 31 Tarea: Analizar la Arquitectura
31
se especifica las
Rol Responsable: Arquitecto de Software. Descripcin: Esta tarea permite definir una arquitectura candidata basada en la experiencia obtenida de sistemas similares o en dominios del problema similares, y restringir las tcnicas arquitectnicas a ser usadas en el sistema. Se definen los diagramas de las vistas arquitectnicas, 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:

Visin del Sistema. Glosario del Sistema. Registro de Riesgo. Modelo de Anlisis. Modelo de Diseo.

163

Modelo de Implantacin. Documento de Arquitectura del Software.
Tabla 32 Tarea: Analizar los Casos de Uso

32
Rol Responsable: Arquitecto de Software. Descripcin: Se basa en cmo desarrollar las Realizaciones de los Casos de Uso del nivel de anlisis 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 adems observar los mecanismos arquitectnicos. Artefacto(s) de Entrada:
Especificacin de Requerimientos del Software (Modelo de Casos de Uso). Modelo de Anlisis. Modelo de Diseo (Realizaciones de los Casos de Uso).

Tabla 33 Tarea: Identificar los Elementos de Diseo

33
Rol Responsable: Arquitecto de Software. Descripcin: Esta tarea se refiere a cmo identificar subsistemas, clases, clases activas, interfaces de subsistemas, eventos y seales tanto externas como internas del sistema. Su propsito es refinar las clases de anlisis en los elementos del Modelo de Diseo apropiados. Artefacto(s) de Entrada:

Modelo de Servicio. Modelo de Anlisis. Modelo de Diseo.
164
Modelo de Servicio.
Tabla 34 Tarea: Generar Prototipo de la Interfaz de Usuario

34
Rol Responsable: Arquitecto de Software. Descripcin: Esta tarea se refiere a cmo disear e implementar un prototipo de la interfaz de usuario y obtener retroalimentacin de requerimientos funcionales y usabilidad. Artefacto(s) de Entrada:
Mapa de Navegacin. Prototipo de la Interfaz de Usuario.
Tabla 35 Tarea: Disear la Interfaz de Usuario

35
Rol Responsable: Arquitecto de Software. Descripcin: Explica cmo llevar a cabo el diseo de la interfaz de usuario haciendo nfasis en la usabilidad. Se describe las caractersticas de los usuarios, se define un mapa de navegacin y se detallan los elementos de diseo de la interfaz de usuario. Esta tarea permite crear un diseo de la interfaz de usuario que apoye el razonamiento y el realce de su usabilidad. Artefacto(s) de Entrada:
Especificacin de Requerimientos del Software. Mapa de Navegacin.
165
MeRinde Gua Detallada Tabla 36 Tarea: Revisar el Diseo

36
Rol Responsable: Analista de Calidad. Descripcin: En esta tarea se define cmo llevar a cabo la revisin del diseo y cmo abordar los resultados de dicha revisin. Permite verificar que el Modelo de Diseo cumpla con los requerimientos del sistema y que sirva como una buena base para su implementacin, as como tambin asegura que dicho modelo sea consistente con respecto a las pautas de diseo generales. Artefacto(s) de Entrada:

Modelo de Diseo. Mapa de Navegacin. Registro de Evaluacin.
Tabla 37 Tarea: Describir la Arquitectura en Tiempo de Ejecucin

37
Rol Responsable: Arquitecto de Software. Descripcin: Se define una arquitectura de proceso para el sistema en trminos 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 comunicacin entre procesos y asignar recursos entre procesos de coordinacin, y para distribuir los elementos modelos entre procesos. Artefacto(s) de Entrada:

Documento de Arquitectura del Software. Modelo de Diseo. Documento de Arquitectura del Software. Modelo de Diseo.

166
MeRinde Gua Detallada Tabla 38 Tarea: Describir la Distribucin

38
Rol Responsable: Arquitecto de Software. Descripcin: Esta tarea define la arquitectura de la implantacin para un sistema distribuido en trminos de nodos fsicos y sus interconexiones. Se analizan los requerimientos de distribucin del sistema y se define la topologa y configuracin de la red. Cabe destacar que esta tarea se aplica solamente a los sistemas distribuidos. Artefacto(s) de Entrada:

Modelo de Diseo. Documento de Arquitectura del Software. Modelo de Implantacin. Documento de Arquitectura del Software.

167
MeRinde Gua Detallada Tabla 39 Tarea: Identificar los Mecanismos de Diseo

39
Rol Responsable: Arquitecto de Software. Descripcin: Esta tarea describe cmo refinar los mecanismos del anlisis en mecanismos del diseo. Cabe destacar que dicho refinamiento se basa en las restricciones impuestas por el ambiente de implementacin. Se categorizan clientes de mecanismos de anlisis, se realiza un inventario de los mecanismos de implementacin y se documentan las maneras de producirse la arquitectura. Artefacto(s) de Entrada:

Modelo de Servicio. Modelo de Anlisis. Documento de Arquitectura del Software. Modelo de Diseo. Modelo de Servicio.

Tabla 40 Tarea: Incorporar Elementos de Diseo Existentes

40
Rol Responsable: Arquitecto de Software. Descripcin: Esta tarea describe cmo desarrollar y refinar el Modelo de Diseo. Incluye analizar las interacciones de las clases de anlisis para encontrar interfaces, clases del diseo y subsistemas del diseo, refinar la arquitectura haciendo reutilizacin cuando sea posible, identificar soluciones a los problemas comnmente encontrados del diseo, e incluir elementos arquitectnicamente significativos del modelo del diseo en la seccin lgica de la visin del documento de la arquitectura del software. Artefacto(s) de Entrada:

Modelo de Servicio. Modelo de Diseo. 168
Documento de Arquitectura del Software. Modelo de Servicio. Modelo de Diseo. Documento de Arquitectura del Software.

Tabla 41 Tarea: Identificar Servicios

41
Rol Responsable: Arquitecto de Software. Descripcin: Esta tarea identifica el Modelo de Diseo de una aplicacin orientada a servicio (SOA) en trminos de servicios y aplicaciones y documentos de especificacin inicial de esos servicios. Tambin incluye determinar las dependencias inciales y la comunicacin entre servicios. Artefacto(s) de Entrada:
Modelo de Servicio. Modelo de Servicio.
Tabla 42 Tarea: Revisar Artefacto de la Arquitectura

42
Rol Responsable: Mentor. Descripcin: Esta tarea describe cundo y cmo llevar a cabo la revisin de la arquitectura y como tratar los resultados de la revisin. Se basa en las recomendaciones por cada revisin, las definiciones del alcance y los objetivos de la revisin, la documentacin de los resultados y la toma de acciones en los defectos identificados de la revisin. Artefacto(s) de Entrada:
Documento de Arquitectura del Software.
Registro de Revisin.
Tabla 43 Tarea: Disear Servicios

43
Rol Responsable: Arquitecto de Software. Descripcin: En esta tarea se define y especifica los servicios y estructura de una solucin orientada a servicios en trminos de colaboraciones de los elementos contenidos del diseo y de subsistemas/interfaces externos. Incluye documentar las especificaciones de servicios y determinar las dependencias y comunicacin entre servicios. Artefacto(s) de Entrada:

Modelo de Servicio. Modelo de Diseo. Documento de Arquitectura del Software. Especificacin de Requerimientos del Software (Especificaciones Suplementarias).

Modelo de Diseo. Modelo de Servicio.
Tabla 44 Tarea: Disear Clases

44
Rol Responsable: Arquitecto de Software. Descripcin: Esta tarea se basa en cmo disear 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 informacin suficiente es proporcionada para implementar la clase sin equivocaciones, para manejar requerimientos no funcionales relacionados con las clases y para incluir los mecanismos de diseo utilizados por la clase.
170
MeRinde Gua Detallada Artefacto(s) de Entrada:
Modelo de Anlisis. Modelo de Diseo.
Tabla 45 Tarea: Disear Subsistemas

45
Rol Responsable: Arquitecto de Software. Descripcin: Esta tarea se refiere a documentar los elementos de subsistemas, definir las clases de diseo o subsistemas de diseo, 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 Diseo.
Tabla 46 Tarea: Disear Casos de Uso

46
Rol Responsable: Arquitecto de Software. Descripcin: En esta tarea se define cmo refinar los productos de anlisis de casos de uso desarrollando las Realizaciones de los Casos de Uso del nivel de diseo. Incluye determinar las Realizaciones de los Casos de Uso en trminos de interacciones, describir las interacciones entre los objetos de diseo, refinar la descripcin de flujo de eventos y unificar las clases de diseo y subsistemas. Artefacto(s) de Entrada:
Especificacin de Requerimientos del Software (Modelo de Casos de Uso).
Modelo de Diseo.
Tabla 47 Tarea: Disear Capsulas

47
Rol Responsable: Arquitecto de Software. Descripcin: Esta tarea describe las caractersticas del diseo de capsulas. Tiene como propsito elaborar y refinar las descripciones de una capsula. Las capsulas son usadas para definir hilos simultneos de ejecucin en el sistema. Estas capsulas son representadas en UML 2.0. Artefacto(s) de Entrada:
Modelo de Diseo. Modelo de Diseo (Capsula).
Tabla 48 Tarea: Disear los Elementos Soporte de Prueba

48
Rol Responsable: Arquitecto de Software. Descripcin: Permite identificar y disear las clases y los paquetes que suministrar la funcionalidad especfica de las pruebas necesarias, disear las interfaces para las herramientas de pruebas automatizadas y automatizar los procedimientos de prueba para los que no tienen ninguna herramienta de prueba automtica disponible. Artefacto(s) de Entrada: No tiene. Artefacto(s) de Salida:
Modelo de Diseo.
Tabla 49 Tarea: Disear la Base de Datos

49
Rol Responsable: Arquitecto de Software. 172
MeRinde Gua Detallada Descripcin: En esta tarea se refleja cmo disear una base de datos para implementar persistencia dentro de una aplicacin. Se basa en definir un modelo del diseo lgico de la base de datos y los detalles del diseo fsico de la base de datos, as como tambin permite asegurar la integridad y la calidad del modelo de datos mediante revisiones de los resultados. Artefacto(s) de Entrada:
Modelo de Diseo. Modelo de Datos.
Tabla 50 Tarea: Especificar Migracin de Datos

50
Rol Responsable: Arquitecto de Software. Descripcin: En esta tarea se define el alcance de la migracin, los perfiles de datos y la correspondencia entre las fuentes de datos y la base de datos objetivo. Adems, se identifican cules partes de las fuentes de datos pueden ser migradas automticamente y cules partes pueden ser migradas manualmente. Artefacto(s) de Entrada:
Modelo de Diseo. Especificacin de Migracin de Datos.
Implementacin Actividades Estructurar el Modelo de Implementacin: En esta actividad se propone una estructura para la implementacin, con el fin de conseguir facilitar la implementacin, integracin y desarrollo de los procesos.
173
Est conformada por la siguiente tarea: Estructurar el Modelo de Implementacin. Planificar la Integracin: Esta actividad se planifica la integracin del sistema para la iteracin en curso. Est conformada por la siguiente tarea: Planificar la Integracin del Sistema. Implementar Componentes: Esta actividad completa una parte de la implementacin del sistema con el propsito de que pueda ser distribuido para la integracin. Est conformada por las siguientes tareas: Planear la Integracin de Subsistemas. Analizar el Comportamiento en Tiempo de Ejecucin. Implementar los Elementos de Diseo. Ejecutar Pruebas a los Elementos y Subsistemas de Implementacin. Revisar el Cdigo. Integrar cada Subsistema: Esta actividad integra los cambios de los desarrolladores para crear una nueva versin consistente de la implementacin de un subsistema. Est conformada por las siguientes tareas: Integrar Subsistema. Ejecutar Pruebas a los Elementos y Subsistemas de Implementacin.
174
MeRinde Gua Detallada Integrar el Sistema: Esta actividad integra los subsistemas implementados para crear una nueva versin consistente del sistema en conjunto. Est conformada por la siguiente tarea: Integrar el Sistema.
175
MeRinde Gua Detallada Tareas Tabla 51 Tarea: Estructurar el Modelo de Implementacin del Sistema
51
Rol Responsable: Arquitecto de Software. Descripcin: En esta tarea se estructura del Modelo de implementacin, se ajustan los subsistemas formados por los elementos de implementacin, se define las dependencias entre subsistemas, se considera cmo tratar los programas ejecutables y las pruebas de los artefactos de dicho modelo, y se actualiza la vista de Implementacin. Artefacto(s) de Entrada:
Modelo de Diseo. Modelo de Implementacin. Documento de Arquitectura del Software.

Tabla 52 Tarea: Planificar la Integracin del Sistema

52
Rol Responsable: Desarrollador. Descripcin: Esta tarea consiste en determinar los subsistemas que participan en los casos de uso y escenarios para la iteracin en curso, definir los componentes operacionales para integrar el sistema y se evala el artefacto Plan de Integracin. Artefacto(s) de Entrada:
Plan de Iteracin. Plan de Integracin.
176
MeRinde Gua Detallada Tabla 53 Tarea: Planear la Integracin de Subsistemas

53
Rol Responsable: Desarrollador. Descripcin: Esta tarea describe cmo planear el orden de integracin de los elementos contenidos en un subsistema de implementacin. Se describe los componentes operacionales y se determinan las clases que participan en los escenarios seleccionados. Adems, se consideran los subsistemas de implementacin que son necesarios para el componente operacional. Artefacto(s) de Entrada:

Modelo de Implementacin (Subsistema de Implementacin). Plan de Iteracin. Plan de Integracin.
Tabla 54 Tarea: Analizar el Comportamiento en Tiempo de Ejecucin

54
Rol Responsable: Desarrollador. Descripcin: Esta tarea se basa en la observacin del comportamiento de un componente durante su ejecucin 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 Implementacin (Elemento de Implementacin). Resultado de Prueba.
Tabla 55 Tarea: Implementar los Elementos de Diseo

55
Rol Responsable: Desarrollador. Descripcin: En esta tarea se prepara la implementacin y se produce una 177
MeRinde Gua Detallada implementacin basada en el diseo (clases, realizaciones de los casos de uso, o entidad de base de datos). Cabe destacar que la implementacin debe reflejar lo acordado en el diseo y si se hacen modificaciones a los elementos de implementacin (cdigo fuente y archivos de datos) se debe actualizar el Modelo de Diseo. Artefacto(s) de Entrada:

Modelo de Diseo. Modelo de Implementacin (Elemento de Implementacin). Modelo de Implementacin (Elemento de Implementacin). Modelo de Implementacin (Subsistema de Implementacin).

Tabla 56 Tarea: Ejecutar Pruebas a los Elementos y Subsistemas de Implementacin

56
Rol Responsable: Desarrollador. Descripcin: Esta tarea se basa en la creacin y ejecucin de un conjunto de pruebas para validar que los elementos y subsistemas implementados por el desarrollador estn trabajando apropiadamente antes de que la prueba ms formal sea llevada a cabo. Artefacto(s) de Entrada:

Modelo de Implementacin (Elemento de Implementacin). Modelo de Implementacin (Subsistema de Implementacin). Resultado de Prueba.
Tabla 57 Tarea: Revisar el Cdigo

57
Rol Responsable: Analista de Calidad. Descripcin: En esta tarea se revisa el cdigo para verificar la implementacin. Se realizan recomendaciones y se documentan los resultados de la revisin para asegurar
178
MeRinde Gua Detallada que los defectos sean documentados. Artefacto(s) de Entrada:
Modelo de Implementacin (Elemento de Implementacin). Registro de Evaluacin.
Tabla 58 Tarea: Integrar Subsistema

58
Rol Responsable: Desarrollador. Descripcin: Esta tarea se refiere a la integracin de los elementos de implementacin hasta obtener un subsistema de implementacin. Artefacto(s) de Entrada:

Plan de Integracin. Modelo de Implementacin (Elemento de Implementacin). Componente Operacional del Sistema. Modelo de Implementacin (Subsistema de Implementacin).

Tabla 59 Tarea: Integrar el Sistema

59
Rol Responsable: Desarrollador. Descripcin: Esta tarea consiste en integrar los subsistemas de implementacin por partes hasta obtener el Componente Operacional del Sistema. Artefacto(s) de Entrada:

Modelo de Implementacin (Subsistema de Implementacin). Plan de Integracin. Componente Operacional del Sistema.
179
MeRinde Gua Detallada Pruebas Actividades Definir la Misin de las Pruebas: En esta actividad se debe identificar la misin a alcanzar con la realizacin de las pruebas para el sistema, se deben determinar el enfoque de las pruebas para una determinada iteracin y se debe llegar a un acuerdo con todos los involucrados sobre dicha misin que dirigir el esfuerzo de las pruebas. Est conformada por las siguientes tareas: Identificar la Misin de las Pruebas Identificar los Motivadores de las Pruebas Identificar las Ideas de Pruebas Identificar los Objetos de Pruebas Acordar la Misin de las Pruebas Definir Criterios de Aceptacin 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 Gua 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 estn 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 Trminos de su Misin: En esta actividad se detallan los resultados obtenidos de las pruebas aplicadas, y se evalan en conformidad a los criterios para el lanzamiento propuestos y la misin 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 Gua Detallada Preparar los Lineamientos del Proyecto Verificar el Enfoque de las Pruebas: En esta actividad se debe comprobar que las pruebas planificadas cumplirn con los objetivos que se tienen estimados a alcanzar y se debe estimar si dichas pruebas son las ms adecuadas para producir los resultados esperados con los recursos disponibles. Est conformada por las siguientes tareas: Establecer la Configuracin del Ambiente de Pruebas Definir los Detalles de las Pruebas Acordar las Pruebas a Realizar
182
MeRinde Gua Detallada Tareas Tabla 60 Tarea: Identificar la Misin de las Pruebas
60
Rol Responsable: Probador. Descripcin: 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 realizacin del sistema y los recursos que se tienen disponibles para ejecutar las pruebas al mismo. Artefacto(s) de Entrada:

Visin del Sistema. Plan de Iteracin. Plan de Pruebas.
Tabla 61 Tarea: Identificar los Motivadores de las Pruebas

61
Rol Responsable: Probador. Descripcin: Se deben identificar el conjunto de razones positivas y factores, que impulsan la accin de realizar las pruebas al sistema en la iteracin. Artefacto(s) de Entrada:

Plan de Iteracin. Documento de Arquitectura de Software. Especificacin de Requerimientos de Software. Visin del Sistema. Plan de Pruebas.
183
MeRinde Gua Detallada Tabla 62 Tarea: Identificar las Ideas de Pruebas

62
Rol Responsable: Probador. Descripcin: En esta tarea se deben identificar de forma preliminar cules son las posibles pruebas que se le pueden aplicar al sistema y cules seran los posibles objetos sobre los cuales se podran aplicar dicho conjunto de pruebas, dados los motivadores y objetivos que se tengan. Artefacto(s) de Entrada:

Plan de Iteracin. Plan de Pruebas. Especificacin de Requerimientos de Software (Modelo de Casos de Uso). Plan de Pruebas (Lista de Ideas de las Prueba).
Tabla 63 Tarea: Identificar los Objetos de Pruebas

63
Rol Responsable: Probador. Descripcin: En esta tarea se deben identificar cules son los objetos (hardware y software) sobre los cuales se aplicaran un conjunto de casos de pruebas en la iteracin 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 Iteracin. Modelo de Implementacin. Modelo de Implantacin. Modelo de Diseo (Realizaciones de los Casos de Uso). Plan de Pruebas (Lista de Ideas de Prueba).
184
Plan de Pruebas (Escenarios por Caso de Uso).
Tabla64 Tarea: Definir el Enfoque de Pruebas

64
Rol Responsable: Probador. Descripcin: 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 Iteracin. Plan de Pruebas (Escenarios por Caso de Uso). Especificacin de Requerimientos de Software. Documento de Arquitectura del Software. Visin del Sistema. Plan de Pruebas (Casos de Prueba). Plan de Pruebas (Matriz de trazabilidad de Pruebas).

Tabla 65 Tarea: Acordar la Misin de las Pruebas

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

Plan de Iteracin. Plan de Pruebas. Plan de Pruebas.
185
MeRinde Gua Detallada Tabla 66 Tarea: Definir Criterios de Aceptacin de los Casos de Prueba
66
Rol Responsable: Involucrados. Descripcin: En esta tarea se deben establecer entre los involucrados del proyecto cuales van a ser los criterios bajo los cuales los Casos de Prueba sern aceptados como suficientes pala misin que se tiene planteada. Artefacto(s) de Entrada:
Plan de Pruebas (Casos de Prueba). Plan de Pruebas (Criterios de Aceptacin).
Tabla 67 Tarea: Definir los Detalles de las Pruebas

67
Rol Responsable: Probador. Descripcin: En esta tarea se detallan el conjunto de pasos, mtodos 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. Plan de Pruebas (Casos de Prueba). Plan de Pruebas (Datos de Prueba). Script de Pruebas.

186
MeRinde Gua Detallada Tabla 68 Tarea: Implementar las Pruebas

68
Rol Responsable: Probador. Descripcin: En esta tarea se implementan todos aquellos Script de Prueba que se preparen para realizar pruebas automticas 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. Script de Pruebas.
Tabla 69 Tarea: Ejecutar el Conjunto de Pruebas

69
Rol Responsable: Probador. Descripcin: 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 observacin importante que el probador pueda aportar para mejorar la calidad del sistema. Artefacto(s) de Entrada:

Componente Operacional del Sistema. Plan de Pruebas. Plan de Pruebas (Casos de Prueba).
187
MeRinde Gua Detallada Tabla 70 Tarea: Determinar los Resultados de las Pruebas
70
Rol Responsable: Probador. Descripcin: 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). Plan de Pruebas (Resumen del Ciclo de Pruebas).
Tabla 71 Tarea: Analizar Pruebas Fallidas

71
Rol Responsable: Probador. Descripcin: 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 observacin importante para la mejora de la calidad y tambin cuando no se estn cumpliendo los criterios de aceptacin de los involucrados sobre determinado objeto. Artefacto(s) de Entrada:
Plan de Pruebas (Casos de Prueba). Solicitud de Cambio.
Tabla 72 Tarea: Evaluar y Defender la Calidad

72
Rol Responsable: Analista de Calidad Descripcin: 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 Gua Detallada desarrollar el sistema. Artefacto(s) de Entrada:

Plan de Pruebas (Resumen del Ciclo de Prueba). Plan de Iteracin. Plan de Pruebas (Resumen del Ciclo de Prueba).
Tabla 73 Tarea: Evaluar y Mejorar el Esfuerzo de las Pruebas

73
Rol Responsable: Probador. Descripcin: Esta tarea contempla los cambios que se le puede hacer a los Casos de Prueba durante la ejecucin 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 Iteracin. Plan de Pruebas. Plan de Pruebas (Resumen del Ciclo de Prueba).

Tabla 74 Tarea: Preparar los Lineamientos del Proyecto

74
Rol Responsable: Mentor. Descripcin: En esta tarea el mentor con los resultados obtenidos al aplicar un conjunto de pruebas determinados para una iteracin 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 Gua Detallada No Aplica. Artefacto(s) de Salida:
Marco de Desarrollo (Lineamientos del Proyecto).
Tabla 75 Tarea: Establecer la Configuracin del Ambiente de Pruebas

75
Rol Responsable: Probador. Descripcin: 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. Plan de Pruebas.
Tabla 76 Tarea: Acordar las Pruebas a Realizar

76
Rol Responsable: Involucrados. Descripcin: En esta tarea los involucrados en el proyecto deben llegar a un consenso sobre el conjunto de pruebas que sern ejecutadas a fin de evaluar la calidad del sistema en desarrollo. Artefacto(s) de Entrada:
Plan de Pruebas. Plan de Pruebas.
190
MeRinde Gua Detallada Implantacin Actividades Planificar la Implantacin: En esta actividad se planifica la implantacin del producto, en la cual se toma en cuenta cmo y cundo el producto ser entregado al usuario final. Est conformada por las siguientes tareas: Definir el Listado de Materiales Desarrollar el Plan de Implantacin 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 Aceptacin: 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 Aceptacin Ejecutar el Conjunto de Pruebas Determinar los Resultados de las Pruebas Preparar el Ambiente de Desarrollo
191
MeRinde Gua Detallada Producir Unidad de Implantacin: En esta actividad se produce una unidad de implantacin, la cual permite que el producto de software sea eficazmente instalado y usado. Est conformada por las siguientes tareas: Crear Unidad de Implantacin Elaborar Notas de Lanzamiento Pruebas del Producto Beta: Esta actividad solicita retroalimentacin sobre el producto (Beta) a un subconjunto de usuarios mientras todava est en desarrollo la versin definitiva del producto. Est conformada por las siguientes tareas: Gestionar las Pruebas Beta Probar el Producto Beta Gestionar las Pruebas de Aceptacin 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 especializacin de Gestionar las Pruebas de Aceptacin, la cual se lleva acabo instalando el producto dentro de las instalaciones del cliente. Est conformada por las siguientes tareas: Gestionar las Pruebas de Aceptacin 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 implantacin para exportarla a algn dispositivo de almacenamiento.
192
MeRinde Gua Detallada Est conformada por las siguientes tareas: Agrupar las Unidades de Implantacin Verificar manufactura del Producto Proveer el Acceso para el Sitio de Descarga: En esta actividad se hace disponible el producto para su descarga a travs 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. Descripcin: 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 observacin importante que el probador pueda aportar para mejorar la calidad del sistema. Artefacto(s) de Entrada:

Componente Operacional del Sistema. Plan de Pruebas. Plan de Pruebas (Casos de Prueba).
193
MeRinde Gua Detallada Tabla 78 Tarea: Determinar los Resultados de las Pruebas
78
Rol Responsable: Probador. Descripcin: 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). Plan de Pruebas (Resumen del Ciclo de Pruebas).
Tabla 79 Tarea: Definir el Listado de Materiales

79
Rol Responsable: Lder del Proyecto. Descripcin: En esta tarea se establecen el listado de materiales que conformaran parte del sistema en desarrollo. Artefacto(s) de Entrada:

Plan de Iteracin. Planificacin del Proyecto. El Sistema (Lista de Materiales).
194
MeRinde Gua Detallada Tabla 80 Tarea: Desarrollar el Plan de Implantacin

80
Rol Responsable: Lder del Proyecto. Descripcin: Esta tarea tiene como objetivo planificar la implantacin 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 Iteracin. Planificacin del Proyecto. Plan de Implantacin.
Tabla 81 Tarea: Elaborar el Plan de Adiestramiento

81
Rol Responsable: Involucrados. Descripcin: Esta tarea tiene como objetivo que se establezca un plan para capacitar a los usuarios del sistema para su utilizacin. Artefacto(s) de Entrada:

Plan de Iteracin. Planificacin del Proyecto. Plan de Adiestramiento.
195
MeRinde Gua Detallada Tabla 82 Tarea: Desarrollar los Materiales de Adiestramiento

82
Rol Responsable: Involucrados. Descripcin: En esta tarea se deben desarrollar el conjunto de materiales destinados a capacitar a los usuarios del sistema para su utilizacin. Artefacto(s) de Entrada:

Plan de Iteracin. Plan de Adiestramiento. Material de Adiestramiento.
Tabla 83 Tarea: Desarrollar Materiales de Apoyo

83
Rol Responsable: Involucrados. Descripcin: En esta tarea se deben desarrollar el conjunto de materiales destinados a ayudar a los usuarios del sistema para su manipulacin. Artefacto(s) de Entrada:

Plan de Iteracin. Componente Operacional del Sistema. Manual de Usuario. Manual de Instalacin.

196
MeRinde Gua Detallada Tabla 84 Tarea: Desarrollar Instalador de Componentes

84
Rol Responsable: Desarrollador. Descripcin: En esta tarea se debe desarrollar el software necesario para poder instalar y desinstalar de forma fcil y segura el sistema para las mltiples plataformas que se consideren para el proyecto. Artefacto(s) de Entrada:
Componente Operacional del Sistema. El Sistema (Artefactos de Instalacin).
Tabla 85 Tarea: Gestionar las Pruebas de Aceptacin

85
Rol Responsable: Lder del Proyecto. Descripcin: 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 Implantacin. Plan de Pruebas (Criterios de Aceptacin). Solicitud de Cambio.
197
MeRinde Gua Detallada Tabla 86 Tarea: Preparar el Ambiente de Desarrollo

86
Rol Responsable: Involucrados. Descripcin: 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 polticas de mantenimiento, administracin, respaldo, entre otros. Artefacto(s) de Entrada:
Infraestructura de Desarrollo. Infraestructura de Desarrollo.
Tabla 87 Tarea: Crear Unidad de Implantacin

87
Rol Responsable: Lder del Proyecto. Descripcin: En esta tarea se procede a la elaboracin de una componente del sistema que est contemplado a ser implantado y concedido al cliente. Artefacto(s) de Entrada:
Componente Operacional del Sistema. El Sistema (Unidad del Implantacin).
198
MeRinde Gua Detallada Tabla 88 Tarea: Elaborar Notas de Lanzamiento

88
Rol Responsable: Lder del Proyecto. Descripcin: Se desarrolla la informacin detallada de la versin del sistema que est siendo entregado al cliente que, esta complementa la documentacin principal del sistema. Artefacto(s) de Entrada:
Plan de Implantacin. Notas de Lanzamiento.
Tabla 89 Tarea: Gestionar las Pruebas Beta

89
Rol Responsable: Lder del Proyecto. Descripcin: En esta tarea se recopilan y gestionan las observaciones encontradas por los usuarios que han empleado la versin beta del producto y han notificado algn error que emite el sistema al ejecutar una determinada funcin. 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 Retroalimentacin. Plan de Implantacin. El Sistema (Unidad de Implantacin). Solicitud de Cambio.
Tabla 90 Tarea: Probar el Producto Beta

90
Rol Responsable: Lder del Proyecto.
199
MeRinde Gua Detallada Descripcin: 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 Retroalimentacin. El Sistema (Unidad de Implantacin). Mecanismo de Retroalimentacin.
Tabla 91 Tarea: Agrupar las Unidades de Implantacin

91
Rol Responsable: Involucrados. Descripcin: En esta tarea se contempla el empaquetamiento de los componentes del sistema que estn destinados a ser implantados y concedidos al cliente. Artefacto(s) de Entrada:
El Sistema (Unidades de Implantacin). El Sistema.
200
MeRinde Gua Detallada Tabla 92 Tarea: Verificar manufactura del Producto

92
Rol Responsable: Involucrados. Descripcin: En esta tarea se verifica el procedimiento de produccin en masa del sistema, para su posterior distribucin a los clientes. Artefacto(s) de Entrada:
El Sistema. El Sistema.
Tabla 93 Tarea: Proveer Acceso al Sitio de Descarga

93
Rol Responsable: Involucrados. Descripcin: 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 Implantacin. El Sistema (Unidades de Implantacin). El Sistema (Unidades de Implantacin).
201
MeRinde Gua Detallada Gestin de Configuracin 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 Configuracin 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 Gestin de Configuracin Establecer las Polticas de Gestin de Configuracin Establecer los Procesos de Control de Cambios Registrar y Almacenar los Cambios: Esta actividad asegura que los cambios realizados al sistema, documentacin, recursos, fechas, planes, etc. sean registrados y que el repositorio de versiones sea actualizado.
202
MeRinde Gua Detallada Est conformada por la siguiente tarea: Guardar y Registrar Cambios Tareas Tabla 94 Tarea: Enviar Solicitud de Cambios
94
Rol Responsable: Involucrados. Descripcin: 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 elaboracin. 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. Descripcin: 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. Solicitud de Cambio. Registro de Evaluacin.

Tabla 96 Tarea: Revisar Solicitudes de Cambio

96
Rol Responsable: Lder del Proyecto. 203
MeRinde Gua Detallada Descripcin: En esta tarea se examinan todas aquellas solicitudes de cambio recibidas. Artefacto(s) de Entrada:

Plan de Iteracin. Solicitud de Cambio. Solicitud de Cambio.
Tabla 97 Tarea: Confirmar Duplicados o Rechazar Cambios de Requerimientos

97
Rol Responsable: Lder del Proyecto. Descripcin: 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. Solicitud de Cambio.
Tabla 98 Tarea: Programar y Asignar el Trabajo

98
Rol Responsable: Lder del Proyecto. Descripcin: En esta tarea se incorpora dentro de la planificacin 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:
Planificacin del Proyecto. 204
Plan de Iteracin. Planificacin del Proyecto. Plan de Iteracin. Orden de Trabajo.

Tabla 99 Tarea: Escribir el Plan de Gestin de Configuracin

99
Rol Responsable: Lder del Proyecto. Descripcin: Se debe desarrollar el Plan de Gestin de Configuracin a fin de describir todas las actividades de Gestin de Configuracin y Cambios que sern realizadas durante todo el ciclo de vida del proyecto. Artefacto(s) de Entrada:
Planificacin del Proyecto. Plan de Gestin de Configuracin.
Tabla 100 Tarea: Establecer las Polticas de Gestin de Configuracin

100
Rol Responsable: Lder del Proyecto. Descripcin: Se debe establecer los mecanismos que sern empleados para gestionar las actividades de Configuracin y Cambios que sern 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:
205
MeRinde Gua Detallada Tabla 101 Tarea: Establecer los Procesos de Control de Cambios
101
Rol Responsable: Lder del Proyecto. Descripcin: 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:
Tabla 102 Tarea: Guardar y Registrar Cambios

102
Rol Responsable: Lder del Proyecto. Descripcin: Durante esta tarea se registran y se guardan en un repositorio de versiones, los cambios hechos no slo al sistema, sino tambin a los documentos, planes, los recursos, las fechas, imgenes, etc. Artefacto(s) de Entrada:

Artefactos del Proyecto. Repositorio de Versiones. No Aplica.
Gestin 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 decisin inicial y razonada para evaluar si se decide continuar o abandonar el proyecto. 206
Est conformada por las siguientes tareas: Elaborar Solicitud del Sistema Desarrollar Trminos de Referencia Identificar y Evaluar los Riesgos Iniciar el Proyecto Evaluar el Alcance y los Riesgos del Proyecto: En esta actividad se revala 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 planificacin del proyecto. Est conformada por las siguientes tareas: Planear las Fases y las Iteraciones Definir la Organizacin del Proyecto y del Personal Seleccin y Contratacin del Personal de Desarrollo Desarrollar el Plan de Gestin de Riesgos Definir los Mecanismos de Monitoreo y Control del Proceso Determinar los Aspectos Tcnicos a Evaluar para la Seleccin del Contratista Revisar la Planificacin del Proyecto Planear el Resto de la Iteracin Inicial: Esta actividad permite refinar el plan de la iteracin inicial.
207
MeRinde Gua Detallada Est conformada por las siguientes tareas: Desarrollar el Plan de Iteracin Revisar el Plan de Iteracin Gestionar Iteracin: Esta actividad contiene las actividades que empiezan, terminan y revisan una iteracin. Est conformada por las siguientes tareas: Iniciar Iteracin Revisar los Criterios de Evaluacin de la Iteracin Identificar y Evaluar los Riesgos Revaluar el Alcance y los Riesgos del Proyecto: Esta actividad revala 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 lder del proyecto prepara el proyecto para su cierre. Est conformada por las siguientes tareas: Preparar Cierre-Salida para el Proyecto Evaluar la Aceptacin del Proyecto Cerrar- Salir de la Fase: En esta actividad, el lder 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 Gua Detallada Supervisar los Hitos del Ciclo de Vida Planificar la Prxima Iteracin: Esta actividad crea un plan de iteracin detallado para controlar la prxima iteracin. Est conformada por las siguientes tareas: Desarrollar el Plan de Iteracin Revisar el Plan de Iteracin Refinar la Planificacin del Proyecto: Esta actividad refina la planificacin del proyecto. Est conformada por las siguientes tareas: Planear las Fases y las Iteraciones Definir la Organizacin del Proyecto y del Personal Seleccin y Contratacin del Personal de Desarrollo Desarrollar el Plan de Gestin de Riesgos Definir los Mecanismos de Monitoreo y Control del Proceso Determinar los Aspectos Tcnicos a Evaluar para la Seleccin del Contratista Revisar la Planificacin del Proyecto Monitorear y Controlar el Proyecto: Esta actividad capta el trabajo diario y continuo del lder del proyecto, incluyendo el monitoreo del estado del proyecto, informar a grupos de involucrados y resolucin de problemas. Est conformada por las siguientes tareas: Organizar Evaluacin Conducir Evaluacin del Proyecto Conducir Evaluacin del Proceso de Desarrollo Programar y Asignar el Trabajo 209
MeRinde Gua Detallada Monitorear el Estado del Proyecto Solventar Problemas Tareas Tabla 103 Tarea: Elaborar Solicitud del Sistema
103
Rol Responsable: Involucrados. Descripcin: 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 Trminos de Referencia

104
Rol Responsable: Involucrados. Descripcin: En esta tarea se elabora el artefacto Trminos de Referencia del Sistema, el cual contiene una descripcin del sistema a realizar. Artefacto(s) de Entrada:
Solicitud del Sistema. Trminos de Referencia del Sistema.
Tabla 105 Tarea: Identificar y Evaluar los Riesgos

105
Rol Responsable: Involucrados. Descripcin: En esta tarea se deben estimar los posibles riesgos a los que est expuesto
210
MeRinde Gua 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: Lder del Proyecto. Descripcin: En esta tarea se establecen los criterios inciales que se estiman sern necesarios para llevar a cabo el proyecto. Artefacto(s) de Entrada:
Trminos de Referencia del Sistema. Planificacin del Proyecto.
Tabla Tarea: Determinar el Alcance del Sistema Rol Responsable: Lder del Proyecto. Descripcin: En esta tarea se establece en el artefacto Trminos de Referencia del Sistema los aspectos a ser abarcados y desarrollados en el proyecto a realizar. Artefacto(s) de Entrada:
Trminos de Referencia del Sistema. Trminos de Referencia del Sistema
211
MeRinde Gua Detallada Tabla 107 Tarea: Planear las Fases y las Iteraciones
107
Rol Responsable: Lder del Proyecto. Descripcin: En esta tarea se debe determinar el conjunto de fases e iteraciones que sern consideradas para el proyecto, adems se debe estimar sus objetivos y duracin. Artefacto(s) de Entrada:

Trminos de Referencia del Sistema. Registro de Riesgos. Marco de Desarrollo. Planificacin del Proyecto.
Tabla 108 Tarea: Definir la Organizacin del Proyecto y del Personal

108
Rol Responsable: Lder del Proyecto. Descripcin: En esta tarea se debe estimar los recursos humanos necesarios para el proyecto, adicionalmente se debe estimar como sern distribuidos los mismos. Artefacto(s) de Entrada:

Trminos de Referencia del Sistema. Registro de Riesgos. Planificacin del Proyecto. Licitacin del Personal.

Tabla 109 Tarea: Seleccin y Contratacin del Personal de Desarrollo

109
Rol Responsable: Lder del Proyecto. Descripcin: Esta tarea se ejecuta cuando se va a trabajar con personal externo a la organizacin. En esta se evalan segn unos criterios definidos por la organizacin a
212
MeRinde Gua Detallada los grupos de contratistas que postulen sus servicios para el desarrollo del proyecto. Posteriormente se procede a la contratacin y al establecimiento de los aspectos legales necesarios para acordar las responsabilidades entre las partes. Artefacto(s) de Entrada:
Calificacin de los Aspectos Tcnicos de los Servicios de Desarrollo de Sistemas. Oferta de Servicio del Personal. Planificacin del Proyecto. Trminos de Referencia para el Equipo de Desarrolladores del Sistema.
Tabla 110 Tarea: Desarrollar el Plan de Gestin de Riesgos

110
Rol Responsable: Lder del Proyecto. Descripcin: Se debe establecer un plan donde se debe contemplar los riesgos que sean identificados para el proyecto, adicionalmente dicho plan puede contener las descripciones, anlisis, prioridades y estrategias que sirvan para minimizar el impacto que los riesgos puedan llegar a tener. Artefacto(s) de Entrada:
Registro de Riesgos. Plan de Gestin de Riesgos.
Tabla 111 Tarea: Definir los Mecanismos de Monitoreo y Control del Proceso
111
Rol Responsable: Lder del Proyecto. Descripcin: Se deben establecer los mecanismos que permitirn evaluar y supervisar continuamente el proceso de desarrollo del proyecto. Artefacto(s) de Entrada: 213
MeRinde Gua Detallada No Aplica. Artefacto(s) de Salida:
Planificacin del Proyecto.
Tabla 112 Tarea: Determinar los Aspectos Tcnicos a Evaluar para la Seleccin del Contratista
112
Rol Responsable: Involucrados. Descripcin: Esta tarea se ejecuta cuando se va a trabajar con personal externo a la organizacin. Se debe determinar un mecanismo que permita a la organizacin hacer un proceso de seleccin 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:
Calificacin de los Aspectos Tcnicos de los Servicios de Desarrollo de Sistemas.
Tabla 113 Tarea: Revisar la Planificacin del Proyecto

113
Rol Responsable: Analista de Calidad. Descripcin: En esta tarea se supervisa la planificacin que ha sido estimada para el proceso de desarrollo del sistema, adicionalmente se pude emitir cualquier observacin necesaria para mejorar el mismo. Artefacto(s) de Entrada:
Planificacin del Proyecto. Registro de Evaluacin.
214
MeRinde Gua Detallada Tabla 114 Tarea: Desarrollar el Plan de Iteracin

114
Rol Responsable: Lder del Proyecto. Descripcin: El objetivo de esta tarea es planificar detalladamente para cada iteracin a realizarse el conjunto de tareas, actividades y recursos que sern empleados. Artefacto(s) de Entrada:

Planificacin del Proyecto. Registro de Riesgos. Marco de Desarrollo. Plan de Iteracin.
Tabla 115 Tarea: Revisar el Plan de Iteracin

115
Rol Responsable: Analista de Calidad. Descripcin: En esta tarea se supervisa la planificacin que ha sido estimada para una iteracin del ciclo de vida de desarrollo del sistema, adicionalmente se pude emitir cualquier observacin necesaria para mejorar la misma. Artefacto(s) de Entrada:

Plan de Iteracin. Registro de Riesgos. Registro de Evaluacin.
Tabla 116 Tarea: Iniciar Iteracin

116
Rol Responsable: Lder del Proyecto. Descripcin: Con esta tarea el recurso humano asignado al proyecto da inicio al conjunto de actividades estimadas dentro del Plan de Iteracin vigente.
215

Plan de Iteracin. Planificacin del Proyecto. Orden de Trabajo.
Tabla 117 Tarea: Revisar los Criterios de Evaluacin de la Iteracin

117
Rol Responsable: Analista de Calidad. Descripcin: En esta tarea se supervisa los criterios considerados para determinar el progreso del proyecto al final de la iteracin, adicionalmente se pude emitir cualquier observacin necesaria para mejorar estos. Artefacto(s) de Entrada:

Plan de Iteracin. Planificacin del Proyecto. Registro de Evaluacin.
Tabla 118 Tarea: Preparar Cierre-Salida para el Proyecto

118
Rol Responsable: Lder del Proyecto. Descripcin: En esta tarea se deben completar los requerimientos formales establecidos para el cierre-salida del proyecto, se debe verificar la aceptacin del proyecto, la reasignacin de los recursos, el traslado de responsabilidades de desarrollo y soporte, entre otros. Artefacto(s) de Entrada:
Planificacin del Proyecto. Planificacin del Proyecto. 216
Registro de Evaluacin.
Tabla 119 Tarea: Evaluar la Aceptacin del Proyecto

119
Rol Responsable: Analista de Calidad. Descripcin: Se debe verificar y revisar que se hayan cumplido satisfactoriamente todos los pasos establecidos para la aceptacin por parte del cliente del sistema y de todos sus entregables. Artefacto(s) de Entrada:
Tabla 120 Tarea: Preparar Cierre-Salida para la Fase

120
Rol Responsable: Lder del Proyecto. Descripcin: 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 supervisin de los hitos planteados para la fase dentro del ciclo de vida de desarrollo del sistema. Artefacto(s) de Entrada:
Planificacin del Proyecto. Planificacin del Proyecto. Registro de Evaluacin.

Tabla 121 Tarea: Supervisar los Hitos del Ciclo de Vida

121
Rol Responsable: Analista de Calidad. Descripcin: Se debe verificar y revisar que se hayan alcanzado todos los hitos 217
MeRinde Gua Detallada planificados para el fin de la fase. Adicionalmente se pude emitir cualquier observacin necesaria para mejorar el proceso tanto para otra fase del proyecto como para otro proyecto. Artefacto(s) de Entrada:
Tabla 122 Tarea: Conducir Evaluacin del Proyecto

122
Rol Responsable: Analista de Calidad. Descripcin: Esta tarea representa el conjunto de revisiones continuas que puede ejecutar el Analista de Calidad a fin de evaluar cmo se estn llevando a cabo las actividades planificadas para una iteracin. Adicionalmente se pude emitir cualquier observacin necesaria para mejorar el proceso de desarrollo del proyecto. Artefacto(s) de Entrada:
Plan de Iteracin. Registro de Evaluacin.
Tabla 123 Tarea: Conducir Evaluacin del Proceso de Desarrollo

123
Rol Responsable: Mentor. Descripcin: Esta tarea representa el conjunto de revisiones continuas que puede ejecutar el Mentor a fin de evaluar cmo se est desarrollando y siguiendo el proceso de desarrollo planificado para el proyecto y tambin sirve para medir la calidad en general con la que est siendo llevado el proceso de desarrollo. Adicionalmente se pude emitir cualquier observacin necesaria para mejorar el proceso de desarrollo del proyecto.
218

Plan de Iteracin. Planificacin del Proyecto. Marco de Desarrollo. Registro de Evaluacin.
Tabla 124 Tarea: Organizar Evaluacin

124
Rol Responsable: Involucrados. Descripcin: Esta tarea representa el conjunto de revisiones que puede ejecutar cualquier involucrado en el desarrollo del proyecto a fin de evaluar cmo se est desarrollando y siguiendo el proceso de desarrollo y las actividades planificadas para la iteracin. Adicionalmente se pude emitir cualquier observacin necesaria para mejorar el proceso de desarrollo del proyecto. Artefacto(s) de Entrada:
Plan de Iteracin. Registro de Evaluacin.
Tabla 125 Tarea: Monitorear el Estado del Proyecto

125
Rol Responsable: Lder del Proyecto. Descripcin: Esta tarea representa el conjunto de revisiones continuas que puede ejecutar el Lder del Proyecto a fin de evaluar el estado actual del proyecto conforme a lo que est planificado. Adicionalmente se pude emitir cualquier observacin necesaria para mejorar el proceso de desarrollo del proyecto. Artefacto(s) de Entrada:

Planificacin del Proyecto. Registro de Riesgos.
219
MeRinde Gua Detallada Artefacto(s) de Salida:

Registro de Riesgos. Registro de Evaluacin.
Tabla 126 Tarea: Solventar Problemas

126
Rol Responsable: Lder del Proyecto. Descripcin: 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: Lder del Proyecto. Descripcin: En esta tarea se incorpora dentro de la planificacin 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:

Planificacin del Proyecto. Plan de Iteracin. Planificacin del Proyecto. Plan de Iteracin. Orden de Trabajo.

220
Gestin 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 Iteracin: Esta actividad consiste en preparar el ambiente de desarrollo del proyecto para la iteracin 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 Instalacin y Configuracin de las Herramientas Apoyar el Ambiente durante una Iteracin: Esta actividad permite apoyar el ambiente para el desarrollo de un proyecto durante la iteracin en curso, incluye tanto el proceso como las herramientas. 221
Est conformada por la siguiente tarea: Apoyar el Desarrollo Tareas Tabla 128 Tarea: Elaborar el Marco de Desarrollo del Proyecto
128
Rol Responsable: Involucrados. Descripcin: En esta tarea se debe desarrollar el Marco de Desarrollo a fin de ajustar la configuracin de la metodologa 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. Descripcin: En esta tarea se establecen las directrices que sern 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 Gua Detallada Tabla 130 Tarea: Adaptar el Marco de Desarrollo para el Proyecto
130
Rol Responsable: Involucrados. Descripcin: 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. Trminos de Referencia del Sistema. Marco de Desarrollo.
Tabla 131 Tarea: Preparar las Plantillas para el Proyecto

131
Rol Responsable: Involucrados. Descripcin: 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. Plantillas del Proyecto.
Tabla 132 Tarea: Seleccionar y Adquirir Herramientas

132
Rol Responsable: Involucrados. Descripcin: 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 Gua Detallada Artefacto(s) de Salida:
Infraestructura de Desarrollo (Herramientas).
Tabla 133 Tarea: Configurar las Herramientas

133
Rol Responsable: Involucrados. Descripcin: Durante esta tarea las herramientas que se emplearan para el proceso de desarrollo del proyecto sern ajustadas conforme a las necesidades del proyecto que se va a ejecutar. Artefacto(s) de Entrada:
Infraestructura de Desarrollo (Herramientas). Infraestructura de Desarrollo (Herramientas).
Tabla 134 Tarea: Verificar la Instalacin y Configuracin de las Herramientas

134
Rol Responsable: Involucrados. Descripcin: Durante esta tarea se verifica que las herramientas que se emplearan para el proceso de desarrollo del proyecto estn ajustadas conforme a las necesidades del proyecto que se va a ejecutar. Artefacto(s) de Entrada:
Infraestructura de Desarrollo (Herramientas). Registro de Evaluacin.
Tabla 135 Tarea: Apoyar el Desarrollo

135
Rol Responsable: Involucrados. Descripcin: Durante esta tarea se verifica que la Infraestructura de Desarrollo que se 224
MeRinde Gua 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. Infraestructura de Desarrollo.
225
APNDICE C LLENADO DE LAS PLANTILLAS
226
MeRinde Gua Detallada Llenado de las plantillas Las plantillas son un conjunto predefinido de formas que establece la estructura necesaria para crear contenido rpidamente. Para aquellos que empiezan elaborar artefactos con una pgina en blanco, puede ser demasiado trabajo y es fcil olvidar partes importantes. En MeRinde se proporcionan una serie de plantillas orientadas a facilitar el conocimiento que se debe tener acerca de la informacin 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 ms rpido, pero tambin ayudarn a evitar discusiones y a evitar pasar por alto problemas importantes. Estas plantillas no son universales y no intentan proveer guas 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 travs de www.merinde.rinde.gob.ve/index.php?option=com_remository&Itemid=37 Las plantillas se distribuyen bajo la licencia de Documentacin Libre de GNU, sin restricciones adicionales. Es libre de copiar, distribuir y modificar este texto segn los trminos 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 apndice es servir de gua para la instalacin y uso de las plantillas de los productos de la Metodologa para el Desarrollo de Software del CNTI.
227
MeRinde Gua Detallada Paso 1. Obtener las plantillas. Las plantillas de los artefactos correspondientes a la Metodologa se pueden conseguir en la siguiente direccin: https://www.merinde.rinde.gob.ve/index.php?option=com_remository&Itemid=37 Adicionalmente desde el portal web de la metodologa se pueden descargar los artefactos individualmente desde el portal dedicado a cada uno de ellos, visite la siguiente direccin: http://merinde.noip.info/index.php?option=com_remository&Itemid=37&func=select&id=1 Paso 2. Instalacin. Descomprima el archivo con extensin ZIP TAR si se ha descargado todos los artefactos. Para poder utilizar las plantillas se recomienda emplear OpenOffice.org 2.0 o superior, especficamente 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 tambin estn disponibles para ser editados con Office 2000 o superior. OpenOffice.org puede ser conseguido gratuitamente desde la siguiente direccin electrnica: http://es.openoffice.org/ Adicionalmente los artefactos estn disponibles en Formato de Documento Porttil (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 Gua Detallada Paso 3. Uso. Para comenzar a emplear los artefactos abra la herramienta de su preferencia, seleccin 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 automticos de los artefactos (campos con fondo gris) en OpenOffice.org Writer, debe seleccionar Archivo>Propiedades y en la pestaa descripcin sustituya los campos de Ttulo, Tema y Comentarios por la informacin apropiada para este documento. Despus de cerrar el dilogo, los campos automticos sern actualizados automticamente. Para actualizar la numeracin del ndice de Contenido haga clic derecho sobre este campo automtico y luego clic en Actualizar ndice/Tabla. informacin sobre el trabajo con campos. Una vez abierto el artefacto solo queda completarlo, para ello se dispone en cada seccin 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 comn, 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 sealar a que versin del sistema corresponde el cambio, hay que poner la fecha, una muy breve descripcin del cambio y el o los autores. Vea la ayuda del OpenOffice.org para ms
229
MeRinde Gua Detallada ndice de Contenido ndice del documento. Se rellena automticamente, no tocar. Para actualizar la numeracin el contenido del ndice de Contenido haga clic derecho sobre este campo automtico y luego clic en Actualizar ndice/Tabla. Introduccin Todos los artefactos tienen una introduccin para indicar para qu sirven. Esta seccin est compuesta por los siguientes aspectos: Objetivo El propsito del documento. Alcance Se refiere a una definicin especfica de las reas, procesos, etc. que van a ser afectadas por el artefacto y sus resultados. Definiciones, Acrnimos y Abreviaturas Se trata de un pequeo glosario especfico de este documento. Documentos Relacionados Lista de documentos que son referenciados en ste artefacto que aportan informacin relevante y que ya han sido elaborados.
230

MeRinde+Guía+Detallada+V1 0

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

MeRinde+Guía+Detallada+V1 0

Cargado por

Copyright:

Formatos disponibles

Centro Nacional de Tecnologas de Informacin

METODOLOGA DE LA RED NACIONAL DE INTEGRACIN Y DESARROLLO DE SOFTWARE LIBRE (MeRinde)

Este documento describe las caractersticas principales y la estructura de la metodologa

Carlos David Marrero. Kiberley Kristal. Santos Rosillo.

MeRinde Gua Detallada

MeRinde Gua Detallada

MeRinde Gua Detallada

MeRinde Gua Detallada

MeRinde Gua Detallada

MeRinde Gua Detallada

MeRinde Gua Detallada

CAPTULO I METODOLOGA PROPUESTA

MeRinde Gua Detallada

Diversos Modelos Propuestos en MeRinde

MeRinde Gua Detallada

MeRinde Gua Detallada

MeRinde Gua Detallada

MeRinde Gua Detallada

CAPTULO II ESTRUCTURA DINMICA DE LA METODOLOGA

MeRinde Gua Detallada

MeRinde Gua Detallada

MeRinde Gua Detallada

MeRinde Gua Detallada

CAPTULO III ESTRUCTURA ESTTICA DE LA METODOLOGA

MeRinde Gua Detallada

MeRinde Gua Detallada

MeRinde Gua Detallada

Representacin Grfica del cono que Especfica una Subactividad

MeRinde Gua Detallada

MeRinde Gua Detallada

Figura 19. Flujo de Trabajo de la Disciplina Anlisis y Diseo.

MeRinde Gua Detallada

MeRinde Gua Detallada

Figura 21. Flujo de Trabajo de la Disciplina Pruebas.

Figura 22. Flujo de Trabajo de la Disciplina Implantacin.

MeRinde Gua Detallada

MeRinde Gua Detallada

MeRinde Gua Detallada

MeRinde Gua Detallada

MeRinde Gua Detallada

CAPTULO IV APORTES, VENTAJAS Y DESVENTAJAS DE LA METODOLOGA

MeRinde Gua Detallada

MeRinde Gua Detallada

MeRinde Gua Detallada

MeRinde Gua Detallada

MeRinde Gua Detallada

APNDICE A DESCRIPCIN DE LOS ARTEFACTOS PROPUESTOS DE MERINDE

MeRinde Gua Detallada

Modelo de Anlisis del Negocio Modelo de Diseo del Negocio

Artefacto(s) Contenido(s): Plantilla:

No aplica No posee Escenarios por Casos de Uso

Modelo de Caso de Uso Especificaciones Suplementarias

Entidad del Negocio Reglas del Negocio Trabajador del Negocio

Elemento de Implementacin Subsistema de Implementacin Elemento de Soporte de Prueba

Si posee Planificacin del Proyecto

Modelo de Anlisis del Negocio Modelo de Diseo del Negocio

Artefacto(s) Contenido(s): Plantilla:

(volmenes de trabajo, tiempos de respuestas, precisin), perfiles de usuario, y los

MeRinde Gua Detallada

APNDICE B DESCRIPCIN DE LAS ACTIVIDADES Y TAREAS PROPUESTAS DE MERINDE

Tabla 5 Tarea: Evaluar la Organizacin Objetivo

Evaluacin de la Organizacin Objetivo.

Tabla 6 Tarea: Analizar la Arquitectura del Negocio