Centro Nacional de Tecnologías de Información METODOLOGÍA DE LA RED NACIONAL DE INTEGRACIÓN Y DESARROLLO DE SOFTWARE LIBRE (MeRinde) Guía Detallada Este documento describe las características principales y la estructura de la metodología Autores: • Carlos David Marrero. • Kiberley Kristal. Santos Rosillo.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Centro Nacional de Tecnologías de Información
METODOLOGÍA DE LA RED NACIONAL DE INTEGRACIÓN Y DESARROLLO DE SOFTWARE LIBRE
(MeRinde)
Guía Detallada
Este documento describe las características principales y la estructura de la metodología
Autores:
• Carlos David Marrero.• Kiberley Kristal. Santos Rosillo.
MeRinde Guía Detallada
LICENCIA
Copyright (C) 2007 CNTI. Todos los derechos reservados.
El material escrito que se distribuye estan bajo la licencia de Documentación
Libre de GNU, sin restricciones adicionales. Es libre de copiar, distribuir y modificar
este texto según los términos de esta licencia. El texto completo de la licencia puede
consultarse en la URL http://www.gnu.org/copyleft/fdl.es.html
METODOLOGÍA PROPUESTA................................................................................10Mejores Prácticas Implementadas en la Metodología.......................................... 10Estructura del Proceso de MeRinde......................................................................19Mantenimiento .....................................................................................................20Fundamentos de MeRinde.................................................................................... 22
ESTRUCTURA DINÁMICA DE LA METODOLOGÍA.......................................... 24Fases de la Metodología....................................................................................... 24
ESTRUCTURA ESTÁTICA DE LA METODOLOGÍA........................................... 31Roles Definidos en la Metodología...................................................................... 32
Descripción de los Roles................................................................................ 34El Modelo de Equipo para Proyectos............................................................. 38
Artefactos..............................................................................................................40Descripción de los Artefactos de la Metodología...........................................40Artefactos Compuestos ..................................................................................44
Disciplinas de la Metodología.............................................................................. 45Modelado del Negocio................................................................................... 47Implementación.............................................................................................. 52Pruebas........................................................................................................... 54Implantación................................................................................................... 57Gestión de Configuración y Cambios.............................................................59Gestión del Proyecto.......................................................................................61Gestión del Ambiente .................................................................................... 64
Marco de Desarrollo de MeRinde........................................................................ 66
APORTES, VENTAJAS Y DESVENTAJAS DE LA METODOLOGÍA................. 70Aportes de la Metodología................................................................................... 70Ventajas de la Metodología.................................................................................. 73
3
MeRinde Guía Detallada
Desventajas de la Metodología.............................................................................76
SÍNTESIS DE LA METODOLOGÍA MERINDE.................................................... 77
DESCRIPCIÓN DE LOS ARTEFACTOS PROPUESTOS DE MERINDE ............ 85
DESCRIPCIÓN DE LAS ACTIVIDADES Y TAREAS .........................................142
PROPUESTAS DE MERINDE................................................................................ 142
LLENADO DE LAS PLANTILLAS........................................................................ 226
PLANTILLAS DEL HABILITADOR WEB............................................................231
4
MeRinde Guía Detallada
COLABORADORES
Líderes del Proyecto y Desarrolladores
Carlos David Marrero
Fernando Muro
Henry Rivero
Jasmin Sánchez Esculpi
Kiberley Kristal Santos Rosillo
Odalis Pereira
Colaboradores del Proyecto
Sin ninguno de ustedes hubiese sido posible llevar a cabo este trabajo:
Kenyer Piadaktay Domínguez Martínez
María Angélica Pérez de Ovalles
5
MeRinde Guía Detallada
INTRODUCCIÓN
MeRinde es un proyecto de Software Libre (SL) que propone un estándar para
el proceso de desarrollo de software que puede ser empleado y adaptado según los
requerimientos de cualquier comunidad u organización para el desarrollo de sistemas
y además para producir y mantener una librería de plantillas reutilizables para la
ingeniería de software. Estas plantillas proveen un punto partida para los documentos
utilizados en proyectos de desarrollo de software, con lo que pueden ayudar a los
desarrolladores a trabajar más rápido y evitar pasar por alto aspectos importantes del
proceso de desarrollo.
Este proyecto pretende entre sus principales objetivos apoyar a las
comunidades de desarrollo de SL en sus proyectos, suministrando las herramientas
necesarias para que estos cumplan con un proceso de desarrollo y documentación de
sus sistemas. Se aclara que el proceso propuesto y las plantillas no son universales y
no intentan proveer guías prescriptivas en el proceso general de desarrollo de
sistemas.
Con el proceso de desarrollo y con las plantillas se busca a su vez estimular a
la transferencia del conocimiento entre las comunidades desarrolladoras de SL con lo
cual no solo se pretende que sea compartido los códigos de los sistemas sino que
también se compartan la documentación como guía de referencia para mejoras por
terceros al sistema o para que sirva como modelo a otras comunidades para el
desarrollo de sus propios sistemas.
El contexto del presente proyecto está enmarcado dentro de un diseño
documental bibliográfico, debido a que una buena parte de esta investigación está
sustentada en revisiones bibliográficas de diversas fuentes y por un diseño de campo,
para ello se empleó las instalaciones del CNTI.
6
MeRinde Guía Detallada
JUSTIFICACIÓN
El software tiene un papel muy destacado en la sociedad dado los múltiples
uso que a este se le puede dar, por lo que es importante garantizar métodos claros en
sus diferentes fases de producción y explotación.
Diversas tendencias y metodologías de desarrollo de software han aparecido
en años recientes, buscando resolver los problemas que proyectos más tradicionales,
no han conseguido enfrentar. Entre ellas están los frameworks de proyectos, las
metodologías ágiles y los modelos de medición de madurez. Junto con estos marcos
de trabajo, ciertas estrategias específicas han permitido a los equipos de desarrollo
producir software más robusto, predecible, reutilizable y de fácil mantenimiento.
En Venezuela, el CNTI como ente adscrito al Ministerio del Poder Popular
para las Telecomunicaciones y la Informática (MPPTI), noto que hacia falta
involucrar para el desarrollo de sus proyectos de software equipos que hicieran uso de
una metodología y documentación estandarizada, para alcanzar una trazabilidad entre
documentos, seguir un mismo estándar para el proceso de desarrollo y tener varias
medidas para el aseguramiento de calidad de los sistemas.
Así mismo, se observo que al no existir una metodología estándar para el
desarrollo de los proyectos, no existe un consenso en cuanto a los artefactos a
desarrollar ni al contenido que cada uno de estos debería llevar, y por lo tanto muchos
de los artefactos que son entregados por los entes contratados poseen datos
redundantes o ausencia de los mismos. Por otro lado, la falta de una metodología
estándar conlleva a la ausencia de mecanismos que permitan determinar las funciones
que corresponde a cada personal que interviene en un proyecto, dado que no hay una
definición de roles y sus actividades a cumplir, motivo por el cual un individuo
realiza determinadas tareas que no le corresponden o no le deberían corresponder, lo
7
MeRinde Guía Detallada
cual implica un mayor número de errores en los sistemas y un mayor tiempo a ser
empleado para poner en producción un sistema.
Los paquetes existentes de software para procesos de desarrollo y con
plantillas de ingeniería de software son muy costosos, y están limitadas por la autoría
de solo unas cuantas personas, por relaciones cliente-vendedor o por un conjunto de
herramientas ofrecidas por un distribuidor en particular.
Por los motivos anteriormente mencionados el CNTI como parte de la
administración pública y en su rol tecnológico que le compete se planteó como uno
de sus objetivos poder tener y ofrecer una metodología, con una documentación para
el desarrollo de software que emplee un mismo patrón, que este basado en SL y
estándares abiertos, que propicie un proceso de desarrollo y producto final de calidad.
8
MeRinde Guía Detallada
AUDIENCIA
Esta Metodología para el desarrollo de software está destinada a cualquier
persona implicada en el proceso de desarrollo de software que se lleva a cabo en el
Centro Nacional de Tecnologías de Información (CNTI) y también a cualquier
individuo, comunidad u organización interasada. Se dirige principalmente a
miembros del equipo de desarrollo que se dedican a las siguientes actividades del
ciclo de vida del desarro de sistemas: modelado del negocio, requerimientos, análisis
y diseño, implementación, pruebas, implantación, gestión de configuración y
cambios, gestión del proyecto y gestión del ambiente. Es útil para analistas y usuarios
finales (que especifican la estructura y comportamiento requeridos por el sistema),
para los diseñadores (que diseñan los sistemas que satisfacen esos requerimientos),
para desarrolladores (que convierten esos diseños en código ejecutable), para
probadores (que verifican y validan la estructura y comportamiento del sistema) y
para líderes del proyecto.
9
MeRinde Guía Detallada
CAPÍTULO I
METODOLOGÍA PROPUESTA
Para comenzar este capítulo se procede a detallar la metodología propuesta,
sentado primero las mejores prácticas de desarrollo de software que serán
implementadas y que servirán de línea base para determinar cómo deber ser
abordados los proyectos durante el ciclo de vida de desarrollo al emplear la presente
propuesta metodológica.
Mejores Prácticas Implementadas en la Metodología
El proceso de software propuesto por MeRinde se inspira en catorce (14)
mejores prácticas, dirigidas a facilitar el desarrollo colaborativo de software entre
equipos de trabajo de diversa magnitud e índole, con el fin de que se desarrolle
productos de software con alta calidad, aprovechando al máximo los recursos
disponibles de una forma eficaz y eficiente. A continuación se listan las mejores
prácticas consideradas:
• Adaptar el proceso de desarrollo
• Alto nivel de abstracción
• Centrarse en la arquitectura
• Código estándar
• Colaboración entre equipo
• Demostrar resultados iterativamente e incrementalmente
• Dirigido por Casos de Uso
• Diseño simple
• Enfoque continuo en la calidad
• Enfoque en los riesgos
10
MeRinde Guía Detallada
• Fomento del aprendizaje de experiencias
• Interacción continua con cliente
• Modelar el software
• Permanecer ágil y esperar los cambios.
Seguidamente se describirá como cada una de las mejores prácticas listadas
anteriormente será implementada por la metodología MeRinde.
Adaptar el proceso de desarrollo: MeRinde es un marco de desarrollo
ajustable que tiene como objetivo mantener la agilidad durante el proceso de
desarrollo, establecer planes con representación realista, y estimaciones conforme a
las condiciones del proyecto y durante todo el ciclo de vida del proyecto. MeRinde
propicia a que los planificadores de los proyectos ajusten el proceso de desarrollo a
sus necesidades ya que no tiene como objetivo ser prescriptiva.
Los proyectos de software en MeRinde mientras más grandes sean
requerirán un mayor control para asegurar que se cumplan con los objetivos del
mismo y que no existan desviaciones.
Son muchos los factores que determinan el control que se debe tener sobre un
proyecto, la cantidad de artefactos a emplear, el detalle de la documentación, la
cantidad de revisiones, entro otros; pero fundamentalmente esto es proporcional al
tamaño del proyecto, la distribución de los equipos de desarrollo, la cantidad de
personas involucradas, la complejidad de las tecnologías con que se trabaje,
complejidad de los requerimientos, etc. Por ello MeRinde es un marco de trabajo que
se presenta como ajustable, y no descarta que se empleen componentes externos a los
aquí presentados y a su vez tampoco descarta que sus componentes sirvan para
otros marcos de trabajo.
Alto nivel de abstracción: MeRinde favorece a que se tenga un alto nivel de
abstracción para reducir la complejidad y mejorar la comunicación entre los
11
MeRinde Guía Detallada
involucrados de los proyectos, a través de la recomendación de emplear herramientas
de modelado de alto nivel como UML, el empleo de estándares abiertos, el
establecimiento temprano de la arquitectura, reutilización de componentes, sistemas
heredados y el empleo de software de código libre.
Centrarse en la arquitectura: MeRinde además de empelar los Casos de
Uso para guiar el proceso de desarrollo, presta especial atención al establecimiento
temprano de una buena arquitectura que no se vea fuertemente impactada ante
cambios posteriores durante la construcción y el mantenimiento. La arquitectura de
los proyectos es representada a través del modelo de las 4+1 vistas propuesto por
Kruchten en 1995, con el fin de proveer una representación arquitectónica estándar
para que todos los involucrados en el desarrollo la puedan comprender, discutir y
razonar.
Adicionalmente al acuerdo de la representación de la arquitectura, MeRinde
provee un proceso para diseñar la arquitectura a través de un conjunto de actividades
y define un artefacto fundamental llamado Documento de Arquitectura del Software
(DAS) para describir las vistas asociadas con los proyectos. MeRinde especifica un
rol responsable de la arquitectura del sistema denominado Arquitecto de Software, el
cual a través del ciclo de vida del sistema va refinando la arquitectura y haciéndola
más robusta.
Código estándar: MeRinde propicia para las organizaciones el empleo de
código estándar dentro de las actividades de implementación, a fin de favorecer la
reducción de la complejidad, la reutilización de componentes y que cualquier
involucrado con los conocimientos pertinentes pueda entender, revisar y opinar sobre
cualquier componente implementado.
Colaboración entre equipo: Esta práctica en MeRinde es fundamental y es
abordada por el modelo de trabajo propuesto, por las actividades y por los roles
contemplados. MeRinde es un marco de trabajo donde la comunicación y la
12
MeRinde Guía Detallada
colaboración entre los miembros del equipo de trabajo son favorecidas a fin de crear
un ambiente de trabajo altamente productivo.
Demostrar resultados iterativamente e incrementalmente: En MeRinde las
fases están divididas en iteraciones, cuyo resultado es una versión ejecutable (hito
secundario), el Objetivo de la metodología con cada iteración será mitigar los
riesgos de mayor a menor, donde el concepto de riesgo se refiere a ciertos casos de
uso que son más críticos a la hora de hacer el proyecto. La figura 1 señala como son
representadas las iteraciones dentro de la metodología.
1
Figura 1. Representación Gráfica de una Iteración en Me Rinde.
La cantidad de iteraciones a realizar en un proyecto va a ser directamente
proporcional a la magnitud del proyecto y el tipo de proyecto. Cada iteración con
MeRinde debe ser contralada y se debe abordar una parte de la funcionalidad total,
pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. Cada
iteración se analiza cuando termina. Se puede determinar si han aparecido nuevos
requerimientos o han cambiado los existentes, afectando a las iteraciones siguientes.
13
MeRinde Guía Detallada
Las actividades en MeRinde durante la planificación de los detalles de cada
una de las iteraciones permiten que el equipo examine cómo afectarán los riesgos que
aún quedan al trabajo en curso. Toda la retroalimentación de una iteración hecha
permite reajustar los objetivos para las siguientes iteraciones. Esta dinámica continúa
hasta que se haya finalizado por completo con la versión actual del producto.
MeRinde divide el proceso en cuatro fases, dentro de las cuales se realizan
varias iteraciones en número variable según el proyecto y en las que se hace un mayor
o menor hincapié en los distintas actividades.
Las iteraciones deben estar dirigidas por el riesgo. Las primeras iteraciones
que se deben abordar serán aquellas que impliquen mayores riesgos, ya que
seguramente tendrán una fuerte influencia en la arquitectura del sistema o subsistema
a construir y ayudarán a detectar en una fase temprana los problemas que
retroalimentarán la siguiente Iteración, donde serán resueltos. Las primeras
iteraciones en un proyecto bajo MeRinde se deben enfocar hacia la comprensión del
problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de
los riesgos críticos, y al establecimiento de una base para la arquitectura.
Como soporte a las organizaciones de desarrollo MeRinde provee un proceso
para planificar las iteraciones de los proyectos a través de un conjunto de actividades
y define un artefacto fundamental llamado Plan de Iteración y como soporte ofrece
varios artefactos adicionales para la gestión de los riesgos.
Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y
diseño y se procede a su implementación y pruebas. Se realiza una pequeña espiral
para cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementación
de la nueva versión del producto. En cada fase participan todas las disciplinas, pero
que dependiendo de la fase el esfuerzo dedicado a una disciplina varía.
14
MeRinde Guía Detallada
Toda iteración para un proyecto debe ser corta y contar con una duración fija
(2 a 6 semanas). Para una iteración se elige un conjunto reducido de requerimientos,
se diseña, implementa y prueba. El resultado de cada iteración es un sistema que
puede ser probado, integrado y ejecutado. La salida es un subconjunto con calidad de
producción final. Si existiesen inconvenientes para terminar una iteración planificada
en lugar de retrasar el final de ésta se recomienda eliminar algunos de los
requerimientos (se dejan para la siguiente iteración).
Dirigido por Casos de Uso: Para MeRinde los casos de uso son la
herramienta estándar empleada para especificar los requerimientos funcionales del
sistema, son los que guían el diseño, implementación y pruebas de todo el sistema, y
adicionalmente son los elementos que permiten la trazabilidad.
Diseño simple: MeRinde apoya que los equipos de desarrollo eliminen las
complejidades innecesarias y código extra, que el énfasis se deposite en diseñar la
solución más simple susceptible de implementarse en el momento. Es sumamente
importante que el equipo cumpla con las metas planteadas para cada una de las
iteraciones, para ello se debe manejar metas alcanzables y evitar complejidades que
no sean necesarias, posteriormente alcanzado el nivel funcional planteado si se
dispone de los recursos se podrá aplicar más funcionalidad si así se requiere.
Enfoque continuo en la calidad: MeRinde contiene mecanismos para que la
calidad de todos los artefactos se evalúe en varios puntos durante todo el proceso de
desarrollo, especialmente al final de cada iteración. A lo largo de todo el proceso de
desarrollo de MeRinde se pueden encontrar actividades enfocadas a probar, evaluar y
revisar, las cuales juegan un papel fundamental para asegurar calidad no solo al final
de los proyectos sino que por el contrario durante todo su ciclo de vida.
Existen una gama de artefactos destinados al enfoque continuo de calidad en
MeRinde que soportan las actividades planteadas por los flujos de trabajos, entre
dichos artefactos tenemos: Plan de Pruebas, Registro de Pruebas, Resumen del Ciclo
de Pruebas, Resultados de Pruebas, Registro de Revisión, Registro de Evaluación,
15
MeRinde Guía Detallada
Criterios de Aceptación, entre otros más que fortalecen la calidad constante durante el
desarrollo. Adicionalmente a esto MeRinde contempla dos (2) roles fundamentales
para asegurar calidad y menor perdida de recursos como son el Mentor y el Analista
de Calidad, con los cuales también se asegura que no solo se cumplan con las
actividades básicas de calidad sino que las actividades se sigan de la mejor manera y
que se apliquen con la suficiente profundidad requerida.
Otro papel muy importante en cuanto a calidad en MeRinde lo juegan las
continuas actividades provistas de retroalimentación a las que son expuestos los
sistemas, las cuales permiten evaluar el proceso y hacer los ajustes que sean
necesarios, ampliar la experiencia del equipo de trabajo y permiten mejorar los
recursos para el proyecto actual como para los futuros.
Enfoque en los riesgos: La gestión de los riesgos es contemplada MeRinde
desde el inicio del proyecto hasta el final del mismo a través de diferentes artefactos,
fundamentalmente se manejan dos artefactos pilotos el Plan de Gestión de Riesgos y
el Registro de Riesgos, donde se describen los posibles riesgos de recursos, técnicos,
o del negocio implicados en el proyecto, y formula un plan para abordar los mismos
con medidas de mitigación y correctivas para afrontar cada uno de ellos. El enfoque
en los riesgos en MeRinde sirve de punto principal para la programar las actividades
que deben ejecutarse durante las iteraciones.
Fomento del aprendizaje de experiencias: El fomento del aprendizaje de las
experiencias obtenidas en cada uno de los proyectos realizados es un papel
fundamental que la metodología MeRinde propicia como parte de obtener más
eficacia y eficiencia en los futuros desarrollos.
Dicha práctica es fomentada por MeRinde a través de las continuas
retroalimentaciones que se ven en las diversas actividades con los involucrados; el
establecimiento de un ambiente de desarrollo donde tanto el equipo como cada
individuo tiene la oportunidad de aprender y mejorar sus conocimientos a través del
compartimiento de conocimiento y de lecciones aprendidas; la reutilización de
16
MeRinde Guía Detallada
componentes y con actividades que promueven la continua mejora de los
componentes empleados para los proyectos para su actual y futuro empleo en los
proyectos.
Interacción continua con cliente: El cliente esta inmiscuido dentro de los
involucrados en MeRinde, rol fundamental en la metodología para llevar a cabo
muchas de las actividades fundamentales del proceso de desarrollo de software a lo
largo de todo el ciclo de vida propuesto, con lo cual se busca de que el cliente
participe continuamente para satisfacer sus requerimientos a fin de evitar la pérdida
de recursos y malentendidos durante el desarrollo.
Modelar el software: El tipo de artefacto más fundamental utilizado en la
Metodología MeRinde es el modelo. Cada rol necesita una perspectiva diferente del
sistema. El diseño de MeRinde permite identificar todos los roles y cada una de las
perspectivas que posiblemente podrían necesitar. Las perspectivas recogidas de todos
los roles se estructuran en unidades más grandes, es decir, modelos, de modo que un
rol pueda tomar una perspectiva concreta del conjunto de modelos. La elección de los
modelos para un sistema es una de las decisiones más importantes del equipo de
desarrollo. En la figura 2 se pueden observar los modelos principales propuestos de la
Metodología MeRinde.
Diversos Modelos Propuestos en MeRinde
17
MeRinde Guía Detallada
2
Figura 2. Diversos Modelos Propuestos en MeRinde.
La Metodología MeRinde contempla un conjunto de modelos propuestos
relacionados que facilitan el entendimiento del sistema para todos los involucrados,
incluyendo a los clientes, usuarios y líderes de proyecto. Fueron elegidos para
satisfacer las necesidades de información de esos roles.
La Metodología del CNTI MeRinde emplea UML como único lenguaje de
modelamiento para el desarrollo de todos los modelos dada las ventajas de este
lenguaje y la trazabilidad que permite.
Permanecer ágil y esperar los cambios: El cambio es un factor de riesgo
crítico en los proyectos de software, ante los cuales MeRinde crea las condiciones
necesarias a través de sus actividades para gestionarlos con un enfoque ágil lo más
tempranamente posible con su proceso iterativo e incremental, con la participación
continua del cliente y con las actividades de retroalimentación. Los artefactos
software cambian no sólo debido a acciones de mantenimiento posteriores a la
entrega del producto, sino que durante el proceso de desarrollo.
18
MeRinde Guía Detallada
MeRinde asume que las cosas están constantemente cambiando y que ningún
proyecto está aislado del impacto de estos cambios. Es importante para abordar más
eficientemente cualquier cambio que se presente, que el equipo de proyecto se
mantenga ágil para gestionar los cambios y que todos los involucrados participen de
manera activa para obtener diferentes perspectivas para abordar estos.
Con esto concluye la sección dedica a las mejores prácticas encontradas en la
metodología propuesta, lo cual permite continuar con la definición de estructura que
conforma la metodología, para adentrar un poco más en los detalles de esta.
Estructura del Proceso de MeRinde
La metodología MeRinde propone una estructura como la de UP, la cual tiene
dos dimensiones como lo muestra la Figura 3:
• Eje horizontal: Representa el tiempo y es considerado el eje de los
aspectos dinámicos del proceso. Indica las características del ciclo de
vida del proceso expresado en términos de fases, iteraciones e hitos.
• Eje vertical: Representa los aspectos estáticos del proceso. Describe el
proceso en términos de componentes de proceso, disciplinas,
actividades, artefactos y roles.
19
MeRinde Guía Detallada
Esfuerzo en Actividades según la Fase del Proyecto
3
Figura 3. Esfuerzo en Actividades según la Fase del Proyecto en Merinde.
En los dos capítulos posteriores se procederá a describir tanto el eje de los
aspectos dinámicos de MeRinde como el eje de los aspectos estáticos. A continuación
se presenta los fundamentos sobre los cuales MeRinde se inspira.
Mantenimiento
A continuación se describirá como se lleva a cabo el mantenimiento de
software desarrollado con MeRinde en sus cuatro categorías adaptativo, correctivo,
perfectivo y preventivo.
MeRinde posee en sus dos estructuras la estática y la dinámica, y en las
mejores prácticas sorbe las cuales esta se fundamenta, las herramientas necesarias
20
MeRinde Guía Detallada
para poder ejecutar cualquiera de los cuatro tipos de mantenimientos mencionados
anteriormente.
Un proyecto llevado a cabo con MeRinde por su enfoque iterativo e
incremental continuamente estará refinando, corrigiendo o mejorando los artefactos
del sistema, lo cual se observa a través del conjunto de actividades descritas por la
metodología.
Un mantenimiento no es más que un nuevo recorrido por todas las fases
propuesta en MeRinde, donde las actividades y el esfuerzo de desarrollo serán
directamente proporcionales a lo especificado en los requerimientos para el
mantenimiento a ser llevado a cabo.
A diferencia de un nuevo proyecto, cuando se trabaja el mantenimiento de un
sistema ya desarrollo con MeRinde se parte de que la documentación del sistema ya
existe, motivo por el cual lo que se hace es actualizar dicha documentación u
artefactos para ponerlos acorde a los nuevos cambios solicitados. Al igual que el
sistema con los cambios pasa a una nueva versión igual ocurrirá con la
documentación del sistema.
Las actividades, tareas, roles y artefactos a considerar para el mantenimiento
son también proporcionales a este. Lo que se quiere enfatizar es que para cualquier
tipo de mantenimiento MeRinde con su estructura contiene los mecanismos
necesarios para hacer el mantenimiento. Cabe destacar que MeRinde es tanto
adaptable como extensible, motivo por el cual se puede ajustar MeRinde conforme a
las particularidades del proyecto.
21
MeRinde Guía Detallada
Fundamentos de MeRinde
MeRinde establece una estructura que cubre todo el ciclo de vida de
desarrollo de software, por ello incluye fases, roles, actividades, artefactos,
disciplinas, flujos de trabajo, mitigación de riesgos, control de calidad, gestión del
proyecto y control de configuración. En general, esta metodología está fuertemente
fundamentada en los requerimientos del CNTI y en varias metodologías como UP,
OpenUP, RUP, entre otras que a continuación serán señaladas.
Cabe destacar que los elementos de esta metodología fueron considerados
mediante un análisis de varias metodologías en la que se compararon las mismas con
respecto a sus elementos, esto permitió la escogencia de los elementos para esta
metodología que han tenido éxito en el proceso de elaboración de software, así como
también elementos que se ajustan a las necesidades del CNTI y al contexto de
desarrollo de SL en Venezuela.
Especificando los elementos que fueron estudiados, analizados y comparados
de cada metodología se puede decir que las mejores prácticas para el desarrollo de
software congregadas en MeRinde están inspiradas en UP, RUP, XP, MSF y
OpenUP. MeRinde propone una estructura como UP basada en aspectos dinámicos y
estáticos. Las fases e hitos que corresponde los aspectos dinámicos considerados son
las de UP y las disciplinas que corresponde a los aspectos estáticos de la metodología
se fundamentan en las de UP, OpenUP y RUP.
Los flujos de trabajos que envuelve cada disciplina están inspirados en RUP,
así como también en los procesos de desarrollo del CNTI y en la realidad y el deber
ser del desarrollo de software. En cuanto a los roles, tareas y artefactos contenidos en
una actividad se puede decir que la metodología está fuertemente inspirada en los
roles de MSF, las actividades en RUP, OpenUP, UP y las observadas del ambiente de
desarrollo en el CNTI, y los artefactos están basados en los de Readyset, UP y
22
MeRinde Guía Detallada
artefactos existentes en la organización. También se ven reflejadas las ideas y
recomendaciones de los autores en muchos aspectos que envuelve MeRinde.
Estas metodologías en las que se basa MeRinde son algunas de las más
usadas, además de que permiten la adaptación, es decir son un marco de trabajo que
permiten escoger elementos según las características de cada proyecto. Por la cual
estas sirvieron de insumo para armar la metodología del CNTI para el desarrollo de
software con un enfoque de calidad que satisfaga las necesidades de dicha
organización.
Una vez ya culminados los aspectos generales de la metodología propuesta, se
procede a describir la estructura dinámica de MeRinde en detalle en el próximo
capítulo como había sido indicado anteriormente.
23
MeRinde Guía Detallada
CAPÍTULO II
ESTRUCTURA DINÁMICA DE LA METODOLOGÍA
En este apartado se reflejan los aspectos dinámicos del proceso de desarrollo
en términos de fases, iteraciones e hitos.
MeRinde se repite a lo largo de una serie de ciclos que constituyen la vida de
un producto. Cada ciclo concluye con una generación del producto y consta de cuatro
fases. Cada fase se subdivide a la vez en iteraciones, el número de iteraciones en cada
fase es variable.
Cada fase se concluye con un hito bien definido, un punto en el tiempo en el
cual se deben tomar ciertas decisiones críticas y alcanzar las metas clave antes de
pasar a la siguiente fase, ese hito principal de cada fase se compone de hitos menores
que podrían ser los criterios aplicables a cada iteración. Los hitos son puntos de
control en los cuales los involucrados en el proyecto revisan el progreso del proyecto.
Fases de la Metodología
El ciclo de vida de un proyecto de software desarrollado por el CNTI se
descompone en el tiempo en cuatro fases secuenciales (ver figura 4) que son: Inicio,
Elaboración, Construcción y Transición. Al final de cada fase el equipo gestor del
proyecto realiza una evaluación para determinar si los objetivos se cumplieron y así
pasar a la fase siguiente.
24
MeRinde Guía Detallada
Fases e Hitos encontrados en MeRinde
4
Figura 4. Fases e Hitos encontrados en MeRinde.
A continuación se muestran el objetivo general, los objetivos específicos y
las iteraciones recomendadas para cada una de las fases antes mencionadas.
Inicio
Su propósito general es establecer los objetivos para el ciclo de vida del
producto (ver figura 5). Durante esta fase se define el modelo del negocio y el alcance
del proyecto. Se identifican todos los actores y casos de uso. Se desarrolla, un plan de
negocio para determinar qué recursos deben ser asignados al proyecto.
Los objetivos específicos de esta fase son:
• Establecer el ámbito del proyecto y sus límites.
• Encontrar los casos de uso críticos del sistema, los escenarios básicos
que definen la funcionalidad.
• Mostrar al menos una arquitectura candidata para los escenarios
principales.
• Estimar el costo en recursos y tiempo de todo el proyecto.
• Estimar los riesgos, las fuentes de incertidumbre.
El hito en esta fase finaliza con el establecimiento del ámbito del producto, e
identificación de los principales riesgos y la viabilidad del proyecto.
25
MeRinde Guía Detallada
Fase de Inicio e Hito en MeRinde
5
Figura 5. Fase de Inicio e Hito en MeRinde.
Se recomienda utilizar dos iteraciones en esta fase. Sin embargo, algunos de
los proyectos podrían requerir más o menos iteraciones para alcanzar su objetivo.
Elaboración
Su objetivo general es plantear la arquitectura para el ciclo de vida del
producto (ver figura 6). Se construye un modelo de la arquitectura, que se desarrolla
en iteraciones sucesivas hasta obtener el producto final, este prototipo debe contener
los casos de uso críticos que fueron identificados en la fase de inicio. En esta fase se
realiza la captura de la mayor parte de los requerimientos funcionales, manejando los
riesgos que interfieran con los objetivos del sistema, acumulando la información
necesaria para el plan de construcción y obteniendo suficiente información para hacer
realizable el caso del negocio.
Los objetivos específicos de esta fase son:
• Definir, validar y establecer la arquitectura.
• Completar la visión.
• Crear un plan fiable para la fase de construcción. Este plan puede
evolucionar en sucesivas iteraciones. Debe incluir los costos si procede.
• Demostrar que la arquitectura propuesta soportará la visión con un costo
razonable y en un tiempo razonable.
26
MeRinde Guía Detallada
El hito en la fase de elaboración finaliza con la obtención de una línea base de
la arquitectura del sistema, la captura de la mayoría de los requerimientos y la
reducción de los riesgos importantes así como permitir la escalabilidad del equipo del
proyecto durante la fase de construcción.Fase de Elaboración e Hito en Merinde
6
Figura 6. Fase de Elaboración e Hito en Merinde.
Se recomienda utilizar dos iteraciones en la fase de elaboración. Aunque
algunos de los proyectos en esta fase podrían requerir más iteraciones para alcanzar
su objetivo.
Construcción
El objetivo general de esta fase es alcanzar la capacidad operacional del
producto (ver figura 7) de forma incremental a través de las sucesivas iteraciones. En
esta fase todas las características, componentes, y requerimientos deben ser
integrados, implementados, y probados en su totalidad, obteniendo una versión
aceptable del producto comúnmente llamada versión beta.
Se hace énfasis en controlar las operaciones realizadas, administrando los
recursos eficientemente, de tal forma que se optimicen los costos, los calendarios y la
calidad.
27
MeRinde Guía Detallada
Los objetivos específicos de esta fase son:
• Minimizar los costos de desarrollo mediante la optimización de recursos
y evitando el tener que rehacer un trabajo o incluso desecharlo.
• Conseguir una calidad adecuada tan rápido como sea práctico.
• Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba)
tan rápido como sea práctico.
El hito en esta fase culmina con el desarrollo del sistema con calidad de
producción y la preparación para la entrega al equipo de transición. Toda la
funcionalidad debe haber sido implementada y las pruebas para el estado beta de la
aplicación completadas. Si el proyecto no cumple con estos criterios de cierre,
entonces la transición deberá posponerse una iteración.
Fase de Construcción e Hito en MeRinde
7
Figura 7. Fase de Construcción e Hito en MeRinde.
Para esta fase se recomienda realizar tres iteraciones. Tomando en cuenta las
dimensiones de algunos proyectos el número de iteraciones puede variar.
Transición
Tiene como objetivo general entregar el producto funcional (ver figura 8) en
manos de los usuarios finales una vez realizadas las pruebas de aceptación por un
grupo especial de usuarios, para lo que se requerirá desarrollar nuevas versiones
actualizadas del producto, entrenar a los usuarios en el manejo del sistema, completar
28
MeRinde Guía Detallada
la documentación, y en general tareas relacionadas con la configuración, instalación y
usabilidad del producto.
Los objetivos específicos de esta fase son:
• Garantizar que el usuario aprenda a operar y mantener el sistema.
• Conseguir un producto final que cumpla los requerimientos esperados.
El hito en la fase de transición corresponde a haber decidido si los objetivos se
cumplieron y el comienzo de otro ciclo de desarrollo. El cliente debe haber revisado y
aceptado los artefactos que le han sido entregado.Fase de Transición e Hito en MeRinde
8
Figura 8. Fase de Transición e Hito en MeRinde.
Las iteraciones de esta fase irán dirigidas normalmente a conseguir una nueva
versión. La complejidad de esta fase depende totalmente de la naturaleza del
proyecto, de su alcance y de la organización en la que deba implantarse. En esta fase
se recomienda utilizar dos iteraciones para los proyectos.
En cada fase se persiguen objetivos, se finaliza con un hito y se puede realizar
las iteraciones recomendadas o las que se consideren necesarias dependiendo de la
magnitud y complejidad del proyecto.
Como se pudo observar la estructura dinámica de la MeRinde tiene cuatro
fases y cuatro hitos fundamentales, y además en cada fase se pueden realizar las
iteraciones que convengan según las características del proyecto. Como criterio de
cierre de una fase y comienzo de la otra se debe haber finalizado la fase con un hito.
29
MeRinde Guía Detallada
En el siguiente capítulo se explica la parte estática del proceso de desarrollo
de software MeRinde.
30
MeRinde Guía Detallada
CAPÍTULO III
ESTRUCTURA ESTÁTICA DE LA METODOLOGÍA
Un proceso de desarrollo de software define quién hace qué, cómo y cuándo.
El proceso de MeRinde define cuatro elementos: los roles, que responden a la
pregunta ¿Quién?, las actividades que responden a la pregunta ¿Cómo?, los
artefactos, que responden a la pregunta ¿Qué? y los flujos de trabajo de las disciplinas
que responde a la pregunta ¿Cuándo?, así como se muestra en la figura 9.Dimensión Estática de MeRinde
9
Figura 9. Dimensión Estática de MeRinde. Elaborado por los Autores, con imagenes de Kopete Vista Icono Theme por Joachim Farouz, 2006.
31
MeRinde Guía Detallada
A continuación se describen cada uno de los elementos antes mencionados.
Roles Definidos en la Metodología
Una de las razones principales de la adopción de esta metodología para el
desarrollo de software consiste en la definición de las tareas que serán llevadas a cabo
por los individuos que participan en un proyecto. En MeRinde un rol (ver figura 10)
define las responsabilidades de un individuo, o de un grupo de individuos trabajando
juntos como un equipo. Este se encarga de la realización de tareas, las cuales generan
artefactos.Representación Gráfica del Ícono que Específica un Rol en MeRinde
10
Figura 10. Representación Gráfica del Ícono que Específica un Rol en MeRinde. Tomado de Kopete Vista Icono Theme por Joachim Farouz, 2006.
Existen artefactos que necesitan de más de un solo rol para poder ser
elaborados (ver figura 11).Representación Gráfica del Ícono que Específica los Involucrados en MeRinde
11
Figura 11. Representación Gráfica del Ícono que Específica los Involucrados en MeRinde. Tomado de Kopete Vista Icono Theme por Joachim Farouz, 2006.
La cantidad de roles a utilizar para el desarrollo de un proyecto de software a
realizar con esta metodología depende de la magnitud del proyecto. Mientras más
grande y complejo sea el proyecto requerirá de una mayor cantidad de participantes
para su elaboración y más roles especializados. Otro factor importante a considerar
para elegir los roles a participar en el proyecto es el tiempo asignado al desarrollo del
proyecto.
32
MeRinde Guía Detallada
Esta metodología más que proponer una serie de roles estáticos para un
proyecto establece que se pueden utilizar los roles que se consideren necesario para
realizar el proyecto según las características y el tiempo requerido por este.
Los roles de esta metodología serán agrupados por participación en
actividades relacionadas. Todos los roles dentro de un grupo trabajan con técnicas
similares y tienen habilidades en común, pero cada uno de estos poseen métodos
específicos para la ingeniería del software en su área en particular.
La metodología del CNTI propone ocho (8) roles básicos que deben tomarse
en cuenta para la elaboración de software como son:
a. Analista de Calidad.
b. Analista de Producto.
c. Arquitecto de Software.
d. Desarrollador.
e. Involucrado.
f. Líder del Proyecto.
g. Mentor.
h. Probador.
Es importante destacar que todos los proyectos pequeños o grandes que
utilicen esta metodología en su proceso de desarrollo, deben considerar estos ocho (8)
roles entre los roles definidos para el proyecto.
Esta metodología señala una serie de roles recomendados pero cabe destacar
que un rol puede ser desempeñado por varias personas y una persona puede
representar varios roles, es por ello que esta metodología brinda la oportunidad de
incorporar un número indefinido de personas a los proyectos de desarrollo.
El trabajo en equipo entre todos los involucrados es un principio fundamental
para alcanzar el éxito en cualquier proyecto. MeRinde reconoce esto y asigna roles y
33
MeRinde Guía Detallada
responsabilidades a cada persona involucrada en un proyecto, tanto del lado del
cliente como del de los desarrolladores, y permite que estos trabajen continuamente
en equipo.
A continuación se describirán los grupos de roles definidos en esta
metodología, así como también se señala algunos roles específicos que se pueden
considerar dentro de estos grupos y el modelo de equipo de proyecto propuesto.
Descripción de los Roles
Analista de calidad.
Se encarga de revisar todos los documentos que reflejan el avance del
proyecto (diagrama Gantt, reporte de estado, actas de reunión, reporte de pendientes,
y otras afines al control y seguimiento del proyecto), y de verificar que los objetivos
del marco de desarrollo se cumplan. En estas actividades también participan los
miembros del proyecto que están involucrados en su elaboración.
Este rol se puede descomponer en los siguientes subroles:
• Comité de dirección.
• Comité de seguimiento.
Analista de producto.
Se encarga de dirigir el proceso de captura de requerimientos, definir los
actores y casos de uso y estructurar el modelo de casos de uso, estableciendo la forma
en que funcionará el sistema y cuáles son las restricciones del mismo.
Este rol se puede descomponer en el siguiente subrol:
• Especificador de requerimientos.
34
MeRinde Guía Detallada
Arquitecto de software.
Se encarga de la definición de la arquitectura que guiará el desarrollo, y de la
continua refinación de la misma en cada iteración; debe construir cualquier prototipo
necesario para probar aspectos riesgosos desde el punto de vista técnico del proyecto;
definirá los lineamientos generales del diseño y la implementación.
Este rol se puede descomponer en los siguientes subroles:
• Diseñador.
• Diseñador de base de datos.
• Diseñador de interfaz de usuario.
• Diseñador de paquetes.
Desarrollador.
Esta persona tiene a su cargo la codificación de los componentes en código
fuente en algún lenguaje de alto nivel a desarrollar en la iteración; debe elaborar y
ejecutar las pruebas unitarias realizadas sobre el código desarrollado; es responsable
de las clases que ha desarrollado debiendo documentarlas, actualizarlas ante cambios
y mantenerlas bajo el control de configuración de las mismas mediante la herramienta
utilizada.
Este rol se puede descomponer en los siguientes subroles:
• Implementador.
• Integrador.
35
MeRinde Guía Detallada
Involucrados.
Cualquier persona que se vea afectada por el resultado del proyecto es
considerada como un involucrado. Comprende un grupo de personas interesadas en
que sus necesidades sean satisfechas por el proyecto.
Este rol se puede descomponer en los siguientes subroles:
• Cliente.
• Cualquier rol.
• Desarrollador de cursos.
• Directores de usuarios.
• Diseñador gráfico.
• Documentador técnico.
• Especialista en herramientas.
• Experto del Negocio.
• Usuarios.
Líder del proyecto.
Este rol se encarga de establecer las condiciones de trabajo. Por tal motivo
tiene la función de dirigir y asignar recursos, coordina las interacciones con los
clientes y usuarios finales, planifica las iteraciones, planifica y asigna el trabajo,
define la organización del proyecto, establece las prácticas que aseguran la integridad
y calidad de los artefactos del proyecto, entre otras responsabilidades.
Este rol se puede descomponer en los siguientes subroles:
• Ingeniero de procesos.
• Jefe de configuración.
• Jefe de control de cambios.
• Jefe de implantación.
36
MeRinde Guía Detallada
• Jefe de pruebas.
• Revisor de gestión del proyecto.
Mentor.
El Mentor es aquella persona que está íntimamente ligada con el proceso de
desarrollo de software, que conoce todas las prácticas involucradas y entiende el
porqué de la misma. Acompaña y apoya a los equipos de trabajo mediante revisiones
de los artefactos y haciendo recomendaciones de cómo mejorar los mismos durante
todo el ciclo de vida del sistema. Este rol está en capacidad de aclarar cualquier duda
que puede surgir del proceso, así como también contribuye a que la calidad se
mantenga durante el desarrollo del sistema.
Este rol se puede descomponer en los siguientes subroles:
• Revisor técnico.
• Revisor.
Probador.
La función del probador es realizar las pruebas identificadas y definidas
previamente, utilizando las instrucciones, métodos y herramientas necesarias para
este rol. Debido a la realización de las pruebas debe obtener los resultados de las
mismas.
Este rol se puede descomponer en los siguientes subroles:
• Analista de pruebas.
• Diseñador de pruebas.
• Especialista en Pruebas.
37
MeRinde Guía Detallada
Cabe destacar que la metodología MeRinde tiene 8 roles fundamentales y
cada rol tiene asociado su función. Para proyectos que por su magnitud requieran más
roles que los ocho recomendados, se debe tomar en cuenta que los roles se clasifican
por grupos como se mencionó anteriormente, debido a que para muchos proyectos
pueden requerir personal específico para determinadas funciones.
Seguidamente se describen el modelo de equipo propuesto para la
metodología con base en los roles descritos anteriormente.
El Modelo de Equipo para Proyectos
El desarrollo de SL vinculado a organizaciones puede estar conformado por
equipos de personas que trabajan en conjunto en áreas geográficas que pueden ser
distantes, es decir distribuidos o por el contrario que pueden coincidir en un punto;
adicionalmente a esto se tiene que el desarrollo de un proyecto puede estar a cargo de
personal tanto interno como externo a una organización, en donde a su vez el personal
externo a una organización puede ser de diversa índole jurídica como cooperativas,
fundaciones, entes gubernamentales, compañías, personas naturales, entre otras. Todo
lo anteriormente señalado impacta la configuración de un equipo ideal, para la cual es
importante considerar todos los roles propuestos por MeRinde y que las
responsabilidades individuales sean asignadas apropiadamente para alcanzar el éxito.
MeRinde para solucionar las restricciones anteriormente expuestas propone
como modelo para equipos de trabajo una estructura que puede ser observada en la
figura 12, donde un individuo puede asumir múltiples roles o donde por el contrario
muchos individuos pueden asumir un rol. En la figura 12 los rectángulos contienen
los diversos roles contemplados por la metodología, las líneas que conectan el
diagrama representan líneas de comunicación, las elipses representan los equipos y
los fuertes enlaces comunicacionales que existen entre estos, y la elipse central es
núcleo del modelo donde se ve el equipo como un todo en donde existe una
constante comunicación, coordinación y cooperación.
38
MeRinde Guía Detallada
Representación Gráfica del Modelo de Equipo de Proyecto
12
Figura 12. Representación Gráfica del Modelo de Equipo de Proyecto.
El modelo de equipo para proyectos está conformado por:
• Un equipo de gestión de proyecto el cual es interno a la organización
que conlleva el proyecto, cuya misión es mantener y establecer los
lineamientos del proyecto y mantener la calidad durante todo el ciclo de
vida del proyecto.
• Uno o más equipos de desarrollo que conllevan el análisis, diseño e
implementación del proyecto. Estos por ejemplo pueden representar
desde una organización como una cooperativa hasta individuos que
participan en el proyecto, los cuales a su vez se pueden ser interno,
externo ó ambas inclusive a la organización. El caso en que una
organización cuenta con personal interno y externo a la vez puede ser el
más difícil de comprender, para el caso de MeRinde ambos son equipos
distintos y con tareas especificas pero que entran en la elipse central
39
MeRinde Guía Detallada
donde hay una alta comunicación, coordinación y cooperación para
desarrollar el proyecto en conjunto.
• Uno o más probadores ajenos a los equipos de gestión y de desarrollo.
• Uno o más involucrados en el proyecto que colaboren.
• Un equipo de proyecto, conformado por todos los elementos
anteriormente listados, el cual está integrado por una cantidad de
individuos que pueden variar durante las diversas etapas del desarrollo.
El modelo en general no pretende ser una estructura jerárquica, sino por el
contrario representa un modelo de trabajo flexible basado en la comunicación,
cooperación y la coordinación para aplicar las prácticas y flujos de trabajos
especificados en MeRinde. El Modelo se ajusta a desarrollos tanto internos como
externos a una organización y a las restricciones geográficas de los equipos de trabajo
y a los cambios que puedan ocurrir por la salida o entrada de individuos a un
proyecto.
A continuación se describen los artefactos que son otro elemento considerado
como aspecto estático en esta metodología.
Artefactos
Descripción de los Artefactos de la Metodología
MeRinde propone setenta y seis (76) artefactos que pueden ser creados
durante el proceso de desarrollo de software. Estos artefactos van desde el propio
código fuente hasta la documentación aportada por el cliente y la entregada por el
equipo de desarrollo al culminar cada hito dentro del proyecto. Partiendo de estos
artefactos se pueden crear sólo los artefactos que se consideren necesarios para el
proyecto, adicionalmente según los lineamientos establecidos se les puede hacer
modificaciones a los mismos y también se pueden establecer artefactos adicionales a
los aquí propuestos.
40
MeRinde Guía Detallada
Es importante que la documentación del sistema permanezca actualizada y
consistente durante todo el ciclo de vida de desarrollo del sistema.
Hay artefactos que se convierten en documentos, así mismo cuando se
desarrolla un sistema para un tercero hay artefactos que pueden ser entregados al
cliente y otros que no, esto depende fundamentalmente por el acuerdo que se realice
entre las partes. En la figura 13 se presenta el ícono de un artefacto para MeRinde.Representación Gráfica del Ícono que Específica un Artefacto
13
Figura 13. Representación Gráfica del Ícono que Específica un Artefacto.
Es fundamental que antes del comienzo del proceso de desarrollo se decida
cuales son los artefactos que serán empleados a lo largo del ciclo de vida del
desarrollo del proyecto, así como es recomendado que se defina entre las partes los
artefactos que serán entregados.
A efectos de esta metodología los artefactos que se describen en esta no son
en su totalidad estrictos en su empleo, es decir cada artefacto dependiendo del
proyecto puede ser excluido, esto también conforme al acuerdo entre las partes que
intervienen en el proyecto. Fundamentalmente se recomienda que se emplee la
mayoría de los artefactos que son aquí señalados sobre todo si la magnitud del
proyecto es grande. Mientras mayor documentación exista que detalle en profundidad
los aspectos de un sistema, mejor será el entendimiento de los grupos de trabajo sobre
el proyecto, así mismo esta documentación flexibiliza el proceso posterior de
mantenimiento que el sistema puede llegar a tener, adicionalmente es una buena
práctica para la elaboración de proyectos que involucran un gran número de personas
y roles.
Cabe destacar que es válido emplear artefactos adicionales a los aquí
recomendados siempre que estos faciliten y cumplan con los requerimientos.
41
MeRinde Guía Detallada
A continuación se lista en la tabla 1 los artefactos que se proponen en esta
metodología y adicionalmente se indican cuales son los artefactos mínimos a ser
tomados en cuenta para el desarrollo de un sistema de software con MeRinde:
Tabla 1Artefactos Propuestos en MeRinde con Indicación de Necesidad1
Nombre del Artefacto NecesarioArtefactos de InstalaciónCalificación de los Aspectos Técnicos de los Servicios de Desarrollo de SistemasCapsulaCasos de PruebasComponente Operacional del SistemaCriterios de AceptaciónDatos de PruebasDocumento de Arquitectura del Negocio (DAN)Documento de Arquitectura del Software (DAS) √Elemento de ImplementaciónElemento de Soporte de PruebaEl Sistema √Entidad del NegocioEscenarios por Casos de UsoEspecificación de Migración de DatosEspecificación de Requerimientos del Software (ERS) √Especificaciones SuplementariasEvaluación de la Organización Objetivo (EOO)Glosario del Sistema √HerramientasInfraestructura de DesarrolloLicitación de PersonalLineamientos del ProyectoLista de Ideas de las PruebasLista de MaterialesManual de InstalaciónManual de UsuarioMapa de NavegaciónMarco de DesarrolloMaterial de AdiestramientoMecanismo de RetroalimentaciónModelo de AnálisisModelo de Análisis del NegocioModelo de Casos de UsoModelo de Casos de Uso del NegocioModelo de DatosModelo de Diseño √Modelo de Diseño del Negocio
42
MeRinde Guía Detallada
Nombre del Artefacto NecesarioModelo de ImplantaciónModelo de Implantación del NegocioModelo de ImplementaciónModelo de ServicioNotas de LanzamientoOferta de Servicio del PersonalOrden de TrabajoPlan de AdiestramientoPlan de Gestión de ConfiguraciónPlan de Gestión de Riesgos √Plan de Implantación √Plan de IntegraciónPlan de IteraciónPlan de Pruebas √Planificación del Proyecto √Plantillas para el ProyectoPrototipo de la Interfaz de UsuarioPrueba de Concepto Arquitectónico del NegocioRealizaciones de los Casos de UsoRealizaciones de los Casos de Uso del NegocioRegistro de EvaluaciónRegistro de RevisiónRegistro de RiesgosReglas del NegocioRepositorio de Versiones √Resultado de PruebaResumen del Ciclo de PruebaScript de PruebasSolicitud de CambioSolicitudes de InvolucradosSolicitud del Sistema √Subsistema de ImplementaciónTérminos de Referencia para el Equipo de Desarrolladores del Sistema
√
Términos de Referencia del Sistema √Trabajador del NegocioUnidad de ImplantaciónVisión del NegocioVisión del Sistema √
En el Apéndice A se detallan cada uno de los artefactos propuestos en MeRinde por
orden alfabético, indicando una descripción breve, su rol responsable, la disciplina a
la cual pertenece, si posee plantilla, y si aplica se señala su artefacto contenedor y los
43
MeRinde Guía Detallada
que este contenga. A continuación se listaran los artefactos compuestos dentro del
proceso de desarrollo propuesto en MeRinde.
Artefactos Compuestos
Los artefactos mencionados anteriormente que serán generados y utilizados
por el proyecto constituyen los entregables. Algunos artefactos están contenidos
dentro de otros artefactos, dichos artefactos constituidos por otros se presentan a
continuación en la tabla 2:
Tabla 2Listado de Artefactos Compuestos2
Artefacto Contenedor Artefactos Contenidos
El SistemaLista de MaterialesArtefactos de InstalaciónUnidad de Implantación
Especificación de Requerimientos del Software (ERS)
Modelo de Caso de UsoEspecificaciones Suplementarias
Infraestructura de Desarrollo HerramientasMarco de Desarrollo Lineamientos del Proyecto
Modelo de Análisis del NegocioEntidad del NegocioTrabajador del NegocioReglas del Negocio
Modelo de Diseño CapsulaRealizaciones de los Casos de Uso
Modelo de Diseño del Negocio
Entidad del NegocioRealizaciones de los Casos de Uso del NegocioTrabajador del Negocio
Modelo de ImplementaciónElemento de ImplementaciónSubsistema de ImplementaciónElemento de Soporte de Prueba
Plan de Pruebas
Casos de PruebasCriterios de AceptaciónDatos de PruebasEscenarios por Caso de UsoLista de Ideas de las PruebasResumen del Ciclo de Prueba
44
MeRinde Guía Detallada
No todos los proyectos requieren todos los artefactos, ni con igual grado de
profundidad o detalle. Los artefactos son opcionales, y se recomienda usar pocos
artefactos, eligiendo los de mayor valor práctico para cada proyecto.
En la siguiente sección se mostrará otro componente fundamental de la
estructura estática de la metodología propuesta como lo son las disciplinas, las cuales
responden a la pregunta cuándo del proceso de desarrollo.
Disciplinas de la Metodología
La metodología propuesta MeRinde se organiza en disciplinas. Las disciplinas
poseen flujos de trabajos en donde cada uno conlleva a actividades (ver figura 14)
que a su vez están compuestos por un conjunto de tareas (ver figura 15) realizadas en
un área determinada, las cuales tienen como objetivo producir artefactos. A su vez, en
MeRinde existen actividades que se dividen en subactividades (ver figura 16) con el
fin de facilitar la agrupación de tareas relacionadas.
Las disciplinas que conforman esta metodología se dividirán en dos grupos. El
primero comprende las disciplinas fundamentales asociadas con las áreas de
ingeniería:
a. Modelado del Negocio.
b. Requerimientos.
c. Análisis y Diseño.
d. Implementación.
e. Pruebas.
f. Implantación.
El segundo grupo lo integran las disciplinas llamadas de soporte o gestión:
a. Gestión de Configuración y Cambios.
b. Gestión del Proyecto.
c. Gestión del Ambiente.
45
MeRinde Guía Detallada
Estas son todas las áreas que de una manera u otra definen el ámbito de la
aplicación. Estas disciplinas definen los flujos básicos sobre los cuales se va a ir
iterando durante las fases del proyecto.Representación Gráfica del Ícono que Específica una Actividad
14
Figura 14. Representación Gráfica del Ícono que Específica una Actividad.
Representación Gráfica del Ícono que Específica una Tarea
15
Figura 15. Representación Gráfica del Ícono que Específica una Tarea.
Representación Gráfica del Ícono que Específica una Subactividad
16
Figura 16. Representación Gráfica del Ícono que Específica una Subactividad.
Las disciplinas serán explicadas de forma separada, lo que da una impresión
de que el proceso de desarrollo de software en general, del comienzo al fin del
proyecto, pasa por las disciplinas sólo una vez, lo cual recuerda erróneamente a las
etapas de una metodología en cascada. Esta impresión es incorrecta puesto que como
se ha mencionado anteriormente los flujos de trabajo son recorridos secuencialmente
por cada iteración que se realice, no una sola vez para el proyecto completo. Por tanto
si se tienen nueve iteraciones sobre las cuatro fases del proceso, se recorrerían las
disciplinas nueve veces.
Es importante destacar que para cada iteración no necesariamente se tiene que
recorrer las nueve disciplinas descritas en igual esfuerzo, es decir, según sea
46
MeRinde Guía Detallada
necesario para cada iteración se debe aplicar mayor esfuerzo en las disciplinas
precisas para cumplir el objetivo de la iteración.
A continuación se describen cada una de las disciplinas antes mencionadas.
Modelado del Negocio
Con esta disciplina se pretende llegar a un mejor entendimiento de la
organización donde se va a implantar el sistema de software. Los principales motivos
para ejecutar esta disciplina son los siguientes: asegurarse de que el producto será
algo útil y no un obstáculo; conseguir que se ajuste de la mejor forma posible en la
organización donde se va a implantar; y tener un marco común para el equipo de
proyecto, los clientes y los usuarios finales. Esta disciplina no será siempre necesaria.
Si sólo se añaden funcionalidades que no verán los usuarios directamente, no hará
falta.
Los objetivos específicos de la disciplina modelado de negocio son:
• Asegurar que clientes, usuarios finales y desarrolladores tengan un
entendimiento común de la organización objetivo.
• Derivar los requerimientos del sistema necesarios para apoyar a la
organización objetivo en su mejora.
• Entender el problema actual en la organización objetivo e identificar
potenciales mejoras.
• Entender la estructura y la dinámica de la organización para la cual el
sistema va a ser desarrollado (organización objetivo).
Para lograr estos objetivos, el modelado de negocio describe como desarrollar
una visión de la nueva organización, basado en esta visión se definen procesos, roles
y responsabilidades de la organización por medio de un Modelo de Casos de Uso del
Negocio. Los artefactos del modelo de negocio sirven como entrada y referencia para
la definición de los requerimientos del sistema.
47
MeRinde Guía Detallada
La importancia de esta disciplina radica en que sin el panorama completo del
alcance del negocio y sin el entendimiento de sus procesos no podrán identificarse las
necesidades inmediatas de mejora y continuidad relativa a las actividades
relacionadas con los sistemas informáticos, que son el producto final del desarrollo.
Flujo de trabajo.
En la figura 17 se señala el flujo de trabajo de la disciplina Modelado del
Negocio a fin presentar como MeRinde contempla la secuencia de acciones,
actividades o tareas utilizadas para la ejecución de la disciplina mencionada.Flujo de Trabajo de la Disciplina Modelado del Negocio
17
Figura 17. Flujo de Trabajo de la Disciplina Modelado del Negocio.
El objetivo principal de esta disciplina es establecer las funciones que se
quiere que satisfaga el sistema a construir. En esta línea los requerimientos son el
contrato que se debe cumplir, de modo que los usuarios finales tienen que
comprender y aceptar los requerimientos que se especifiquen. Para obtener los
48
MeRinde Guía Detallada
requerimientos se deben aplicar prácticas de licitación a los involucrados en el
proyecto, anotar y validar todas sus solicitudes.
Los objetivos específicos de la disciplina requerimientos son:
• Definir el ámbito del sistema.
• Definir una interfaz de usuarios para el sistema, enfocada a las
necesidades y metas del usuario.
• Establecer y mantener un acuerdo entre clientes y otros involucrados
sobre lo que el sistema debería hacer.
• Proveer a los desarrolladores un mejor entendimiento de los
requerimientos del sistema.
• Proveer una base para estimar recursos y tiempo de desarrollo del
sistema.
• Proveer una base para la planeación de los contenidos técnicos de las
iteraciones.
Los requerimientos pueden ser divididos en dos grupos: Los requerimientos
funcionales, los cuales describen las funciones que el software va a ejecutar; por
ejemplo, ajustarse a un formato de texto o modular una señal. Los requerimientos no
funcionales, los cuales especifican criterios que pueden usarse para juzgar la
operación de un sistema en lugar de sus funciones específicas.
En esta disciplina, y como parte de los requerimientos de facilidad de uso, se
diseña la interfaz gráfica del usuario. Para ello habitualmente se construyen
prototipos de la interfaz gráfica de usuario que se validan con el usuario final.
Flujo de trabajo.
En la figura 18 se señala el flujo de trabajo de la disciplina Requerimientos a
fin presentar como MeRinde contempla la secuencia de acciones, actividades o tareas
utilizadas para la ejecución de la disciplina mencionada.
49
MeRinde Guía Detallada
Flujo de Trabajo de la Disciplina Requerimientos
18
Figura 18. Flujo de Trabajo de la Disciplina Requerimientos.
El objetivo principal de esta disciplina es transformar los requerimientos a una
especificación que describa cómo implementar el sistema. El análisis
fundamentalmente consiste en obtener una visión que se preocupa de ver que hace el
sistema de software a desarrollar, por tal motivo este se interesa en los requerimientos
funcionales. Por otro lado, el diseño es un refinamiento que toma en cuenta los
requerimientos no funcionales, por lo cual se centra en como el sistema cumple sus
objetivos.
50
MeRinde Guía Detallada
Los objetivos específicos de la disciplina análisis y diseño son:
• Adaptar el diseño para que sea consistente con el entorno de
implementación.
• Desarrollar una arquitectura para el sistema.
• Transformar los requerimientos al diseño del futuro sistema.
Al principio de la fase de elaboración hay que definir una arquitectura
candidata: crear un esquema inicial de la arquitectura del sistema, identificar clases de
análisis y actualizar las realizaciones de los Casos de Uso con las interacciones de las
clases de análisis. Durante la fase de elaboración se va refinando esta arquitectura
hasta llegar a su forma definitiva. En cada iteración hay que analizar el
comportamiento para diseñar componentes.
Flujo de Trabajo.
En la figura 19 se señala el flujo de trabajo de la disciplina Análisis y Diseño
a fin presentar como MeRinde contempla la secuencia de acciones, actividades o
tareas utilizadas para la ejecución de la disciplina mencionada.
51
MeRinde Guía Detallada
Flujo de Trabajo de la Disciplina Análisis y Diseño
19
Figura 19. Flujo de Trabajo de la Disciplina Análisis y Diseño.
Implementación
El objetivo principal de esta disciplina es convertir los elementos del diseño
en elementos de implementación, dichos elementos son códigos fuentes, ejecutables,
binarios, entre otros. Otra parte de esta disciplina son las pruebas de unidad, las
cuales se limitan a los componentes de software implementados. De esta disciplina se
obtiene un sistema ejecutable estable, constituido de los resultados producidos por los
programadores individuales.
52
MeRinde Guía Detallada
Los objetivos específicos de la disciplina implementación son:
• Cada desarrollador decide en quequé orden implementa los elementos
del subsistema.
• Integrar el sistema siguiendo el plan.
• Notificar los errores de diseño, si se encuentran.
• Planificar qué subsistemas deben ser implementados y en quequé orden
deben ser integrados, formando el Plan de Integración.
• Probar los subsistemas individualmente.
La estructura de todos los elementos implementados forma el Modelo de
Implementación. La integración debe ser incremental, es decir, en cada momento sólo
se añade un elemento. De este modo es más fácil localizar fallos y los componentes
se prueban más a fondo. En fases tempranas del proceso se pueden implementar
prototipos para reducir el riesgo. Su utilidad puede ir desde ver si el sistema es viable
desde el principio, probar tecnologías o diseñar la interfaz de usuario. Los prototipos
pueden ser exploratorios (desechables) o evolutivos. Estos últimos llegan a
transformarse en el sistema final.
Flujo de trabajo.
En la figura 20 se señala el flujo de trabajo de la disciplina Implementación a
fin presentar como MeRinde contempla la secuencia de acciones, actividades o tareas
utilizadas para la ejecución de la disciplina mencionada.
53
MeRinde Guía Detallada
Flujo de Trabajo de la Disciplina Implementación
20
Figura 20. Flujo de Trabajo de la Disciplina Implementación.
Pruebas
El principal objetivo de esta disciplina es de evaluar la calidad del producto
que se está desarrollando a través de las diferentes fases por las cuales este pasa,
mediante la aplicación de pruebas concretas para validar que las suposiciones hechas
en el diseño y los requerimientos se estén cumpliendo satisfactoriamente, esto quiere
decir que se verifica que el producto funcione como se diseñó y que los
requerimientos son satisfechos cabalmente. Esta disciplina brinda soporte para
encontrar y documentar (y solucionar) defectos en la calidad del sistema a las otras
disciplinas. Esta disciplina debe estar presente en todo el ciclo de vida del desarrollo
del sistema para ir refinándolo y no al final del mismo.
54
MeRinde Guía Detallada
Los objetivos específicos de la disciplina pruebas son:
• Encontrar y documentar defectos en la calidad del software.
• Notificar la calidad percibida del software.
• Proveer un medio de validación para las suposiciones hechas en el
diseño y especificaciones de requerimientos por medio de
demostraciones concretas.
• Validar las funciones del producto de software según lo diseñado.
• Validar que los requerimientos fueron implementados apropiadamente.
El desarrollo de esta disciplina consistirá en planificar que es lo que hay que
probar, diseñar cómo se va a llevar a cabo la prueba, implementar lo necesario para
llevarlas a cabo, ejecutarlas en los niveles necesarios y obtener los resultados, de
forma que la información obtenida sirva para ir refinando el producto a desarrollar.
El papel de las pruebas no es asegurar la calidad, pero sí evaluarla, y
proporcionar una realimentación a tiempo, de forma que los aspectos de calidad
puedan resolverse de manera efectiva en tiempo y costo.
Los principales aspectos a ser evaluados en un producto software son la
funcionalidad (hace lo que debe), la fiabilidad (resistente a fallos), y el rendimiento
(lleva a cabo su trabajo de manera efectiva). Las pruebas pueden hacerse a diferentes
niveles dependiendo del objetivo de los mismos, entre algunos tenemos: Pruebas de
unidad (se prueban las unidades mínimas por separado, y normalmente se hace
durante la implementación misma), de integración (varias unidades juntas), de
sistema (sobre la aplicación o sistema completo) y de aceptación (realizado sobre el
sistema global por los usuarios o terceros).
55
MeRinde Guía Detallada
Flujo de trabajo
En la figura 21 se señala el flujo de trabajo de la disciplina Pruebas a fin
presentar como MeRinde contempla la secuencia de acciones, actividades o tareas
utilizadas para la ejecución de la disciplina mencionada.Flujo de Trabajo de la Disciplina Pruebas
21
Figura 21. Flujo de Trabajo de la Disciplina Pruebas.
56
MeRinde Guía Detallada
Implantación
Esta disciplina tiene como objetivo distribuir e instalar con éxito el sistema
elaborado por el equipo de desarrollo y asegurar la disponibilidad del producto para
los usuarios finales.
Sus objetivos específicos son:
• Formar a los usuarios y al cuerpo encargado de distribuir el sistema.
• Instalar el software.
• Migrar el software existente.
• Probar el producto en su entorno de ejecución final.
• Proveer asistencia y ayuda a los usuarios.
Se lleva a cabo con mayor intensidad en la fase de transición, debido a que su
propósito es asegurar una aprobación y adaptación sin que existan dificultades del
software por parte del usuario. Esta disciplina debe iniciar en fases anteriores, para
preparar el camino, sobre todo con actividades relacionadas a la planificación, pero
también con la elaboración del manual de usuario y tutoriales. Debido al extenso
nivel de aplicaciones que se pueden obtener y las diversas características de los
productos necesarios para esta disciplina, se pueden obtener grandes variaciones
dependiendo del tipo de sistema a desarrollar. El objeto clave es una distribución del
producto.
Dado las diversas especificaciones de implantación que se pueden dar para
cada proyecto, se le otorga en esta metodología pocos detalles a esta fase.
Aunque el sistema esté bien diseñado y desarrollado correctamente su éxito
dependerá de su implantación y ejecución por lo que es importante capacitar al
usuario con respecto a su uso y mantenimiento.
57
MeRinde Guía Detallada
Flujo de Trabajo.
En la figura 22 se señala el flujo de trabajo de la disciplina Implantación a fin
presentar como MeRinde contempla la secuencia de acciones, actividades o tareas
utilizadas para la ejecución de la disciplina mencionada.
Flujo de Trabajo de la Disciplina Implantación
22
Figura 22. Flujo de Trabajo de la Disciplina Implantación.
58
MeRinde Guía Detallada
Gestión de Configuración y Cambios
El objetivo de esta disciplina es mantener la integridad de todos los objetos
que se crean en el proceso y controlar los cambios. Se debe identificar elementos de
configuración, restringir y auditar los cambios a esos elementos, y definir y dirigir la
distribución de los mismos.
Sus objetivos específicos son:
• Asegurar que los productos desarrollados sean completados y
corregidos debidamente.
• Dar soporte a los métodos de desarrollo.
• Mantener la consistencia de los productos durante la evolución de los
mismos.
• Mantener la integridad del producto.
• Proveer datos para medir el progreso.
• Proveer los medios eficientes para adaptarse apropiadamente a los
cambios y a los replanteamientos de planes de trabajo.
• Proveer un ambiente estable durante el desarrollo del producto.
• Proveer una brecha para auditorías que permita identificar el por qué,
cuándo y por quién ha sido modificado un proyecto.
• Restringir los cambios a los productos según las políticas del proyecto.
Esta disciplina abarca tres funciones como son:
• La gestión de la configuración, que maneja estructura del producto,
configuraciones, la identificación de los elementos, versiones y espacio
de trabajo.
• La gestión de solicitudes de cambio, regula el proceso de cambiar
artefactos de una forma estable.
• Las métricas y estatus, que permite extraer información de las dos
herramientas anteriores, para conducir correctamente el proyecto.
59
MeRinde Guía Detallada
Entre algunas de las causas por las que la evolución de los artefactos puede
causar problemas son:
• Actualización simultánea: Se da cuando dos personas trabajan por
separado sobre el mismo artefacto a la vez, el último en hacer las
modificaciones sobrescribe lo hecho por el primero.
• Múltiples versiones: Cuando se trabaja con diferentes versiones del
producto al mismo tiempo en diferentes flujos de trabajo, pueden surgir
problemas si los cambios no son convenientemente monitorizados y
propagados.
• Notificación limitada: Cuando un problema ha sido resuelto en un
artefacto compartido por varios roles y algunos de ellos no son
notificados del cambio.
Flujo de trabajo.
En la figura 23 se señala el flujo de trabajo de la disciplina Gestión de
Configuración y Cambios a fin presentar como MeRinde contempla la secuencia de
acciones, actividades o tareas utilizadas para la ejecución de la disciplina
mencionada.
60
MeRinde Guía Detallada
Flujo de Trabajo de la Disciplina Gestión de Configuración de Cambios
23
Figura 23. Flujo de Trabajo de la Disciplina Gestión de Configuración de Cambios.
Gestión del Proyecto
El objetivo de la gestión del proyecto es conseguir alcanzar los objetivos
propuestos, administrar el riesgo y superar las restricciones para desarrollar un
producto que sea acorde a los requerimientos de los clientes y usuarios.
Los objetivos específicos de la disciplina Gestión del Proyecto son:
• Proveer guías prácticas para realizar planeación, contratar personal,
ejecutar y monitorear el proyecto.
• Proveer un marco de trabajo para gestionar riesgos.
• Proveer un marco de trabajo para la gestión de proyectos de software
intensivos.
Para conseguir estos objetivos el flujo de trabajo de esta metodología se
centra en tres aspectos:
61
MeRinde Guía Detallada
a. Administrar el riesgo.
b. Monitorear el progreso del proyecto a través de métricas.
c. Planificar un proyecto iterativo y cada iteración en
particular.
Monitorear un proyecto es importante para mantenerlo bajo control. Esto
permite medir la magnitud en la que el proyecto se ajusta a los planes, la calidad
requerida y los requerimientos. También es necesario para planificar de forma precisa
y ver cuál es el comportamiento del proyecto frente a cambios.
La administración del riesgo consiste en ocuparse de las incógnitas de un
proyecto, las cuestiones que puede afectar el desarrollo del proyecto y llevarlo al
fracaso. En concreto hay que identificar los riesgos, típicamente en la fase de inicio, y
hacerles frente, mitigar, transferirlos o asumirlos. En este último caso habrá que tratar
de mitigar el riesgo y definir un plan de contingencia por si el riesgo se convierte en
un problema real. En definitiva la administración del riesgo consistirá en gestionar
una lista de riesgos.
Flujo de trabajo.
En la figura 24 se señala el flujo de trabajo de la disciplina Gestión del
Proyecto a fin presentar como MeRinde contempla la secuencia de acciones,
actividades o tareas utilizadas para la ejecución de la disciplina mencionada.
62
MeRinde Guía Detallada
Flujo de Trabajo de la Disciplina Gestión del Proyecto
24
Figura 24. Flujo de Trabajo de la Disciplina Gestión del Proyecto. Elaborado por los Autores con datos de Rational Unified Process de IBM Corporation, 2006.
63
MeRinde Guía Detallada
Gestión del Ambiente
La finalidad de esta disciplina es dar soporte al proyecto con los procesos,
métodos y herramientas correctas. Ofrece una descripción de las herramientas que se
van a necesitar para el apropiado desarrollo del software, que contendrá las
herramientas de desarrollo y del proceso, plantillas, documentos, lineamientos a
seguir, y cualquier otro elemento necesario para llevar adelante con éxito el desarrollo
del proyecto.
En concreto los objetivos específicos de esta disciplina son:
• Configurar el proceso.
• Establecer y configurar las herramientas para que se ajusten a la
organización.
• Mejorar el proceso de desarrollo.
• Proveer los servicios técnicos necesarios.
• Seleccionar y adquirir herramientas.
Flujo de trabajo.
En la figura 25 se señala el flujo de trabajo de la disciplina Gestión del
Ambiente a fin presentar como MeRinde contempla la secuencia de acciones,
actividades o tareas utilizadas para la ejecución de la disciplina mencionada.
64
MeRinde Guía Detallada
Flujo de Trabajo de la Disciplina Gestión del Ambiente
25
Figura 25. Flujo de Trabajo de la Disciplina Gestión del Ambiente. Elaborado por los Autores con datos de Rational Unified Process de IBM Corporation, 2006.
En conclusión MeRinde tiene nueve (9) disciplinas, una de ellas que es la de
Modelado de Negocio es opcional, es decir se puede o no tomar en cuenta, todo
depende de las particularidades propias del proyecto. En MeRinde las disciplinas
serán visitadas una y otra vez por cada iteración a lo largo de todo el proceso.
Además, las disciplinas tienen asociadas flujos de trabajo, actividades y tareas. Una
actividad refleja la relación entre roles, tareas y artefactos.
65
MeRinde Guía Detallada
En el Apéndice B se señala en detalle cada una de las Actividades propuestas
que aparecen en los Flujos de Trabajo de cada una de las disciplinas, así como
también las Tareas que conforman cada una de las Actividades.
Seguidamente se presentará el Marco de Desarrollo propuesto, el cual
demarca la configuración de MeRinde, es decir las disciplinas y sus artefactos, y se
indica un estimado de cuando se deben elaborar cada uno de los artefactos durante el
proceso de desarrollo de software.
Marco de Desarrollo de MeRinde
La Tabla 3 que se presenta seguidamente resume las disciplinas de MeRinde y
sus artefactos asociados, indicando también, para las fases de esta, el grado
aproximado de desarrollo de cada uno de sus artefactos.
Tabla 3Relación entre los Componentes y las Fases de la Metodología3
COMPONENTES FASES Disciplina Artefacto I E C T
Modelado del Negocio
Documento de Arquitectura del Negocio cEvaluación de la Organización Objetivo (EOO) cVisión del Negocio cModelo de Análisis del Negocio:
Entidad del NegocioTrabajador del NegocioReglas del Negocio
c
Modelo de Caso de Uso del Negocio cModelo de Diseño del Negocio:
Entidad del NegocioRealizaciones de los Casos de Uso del NegocioTrabajador del Negocio
c
Modelo de Implantación del Negocio cPrueba de Concepto Arquitectónico del Negocio c
66
MeRinde Guía Detallada
COMPONENTES FASES Disciplina Artefacto I E C T
Requerimientos
Especificación de Requerimientos de Software:Especificaciones SuplementariasModelo de Casos de Uso
c r r
Glosario del Sistema c r r rSolicitud de Involucrados c r r rVisión del Sistema c r
Análisis y Diseño
Documento de Arquitectura del Software c r rEspecificación de Migración de Datos cMapa de Navegación c rModelo de Análisis cModelo de Datos c rPrototipo de la Interfaz de Usuario cModelo de Diseño:
CapsulaRealizaciones de los Casos de Uso
c r
Modelo de Implantación c rModelo de Servicio c
Implementación
Componente Operacional del Sistema c c cModelo de Implementación:
Elemento de ImplementaciónSubsistema de ImplementaciónElemento de Soporte de Prueba
c r r
Plan de Integración c r r
Pruebas
Resultado de Prueba c c cPlan de Pruebas:
Casos de PruebasCriterios de Aceptación Datos de PruebasEscenarios por Caso de UsoLista de Ideas de las PruebasResumen del Ciclo de Prueba
c r r r
Script de Pruebas c
67
MeRinde Guía Detallada
COMPONENTES FASES Disciplina Artefacto I E C T
Implantación
El Sistema:Lista de MaterialesArtefactos de InstalaciónUnidad de Implantación
c
Manual de Instalación c rManual de Usuario c r rMaterial de Adiestramiento c rMecanismo de Retroalimentación cNotas de Lanzamiento cPlan de Adiestramiento c rPlan de Implantación c
Gestión de Configuración y
Cambios
Plan de Gestión de Configuración c r r rSolicitud de Cambio c c c cRepositorio de Versiones c r r r
Gestión del Proyecto
Calificación de los Aspectos Técnicos de los Servicios de Desarrollo de Sistemas c
Licitación de Personal cOferta de Servicio del Personal cOrden de Trabajo c c c cPlan de Gestión de Riesgos c r r rPlan de Iteración c r r rPlanificación del Proyecto c rRegistro de Evaluación c c c cRegistro de Revisión c c c cRegistro de Riesgos c r r rSolicitud del Sistema cTérminos de Referencia del Sistema cTérminos de Referencia para el Equipo de Desarrolladores del Sistema c
Gestión del Ambiente
Infraestructura de Desarrollo:Herramientas c r
Marco de Desarrollo:Lineamientos del Proyecto c r r
Plantillas para el Proyecto cNota. Tabla elaborada por los Autores.I: Fase de Inicio. E: Fase de Elaboración. C. Fase de Construcción. T: Fase de Transición. c: Comienzo de la construcción del artefacto. r: Refinamiento del artefacto (ampliación, corrección).
68
MeRinde Guía Detallada
Una vez conocidas las dos (2) estructuras de MeRinde se procederá a detallar
su habilitar Web, medio a través del cual será implantada y distribuida la
metodología.
69
MeRinde Guía Detallada
CAPÍTULO IV
APORTES, VENTAJAS Y DESVENTAJAS DE LA METODOLOGÍA
Aportes de la Metodología
La Metodología para el desarrollo de software MeRinde posee algunas
características que hace de esta un proceso único. A continuación se presentan los
aportes de la MeRinde a los proyectos del CNTI y demás instituciones del estado
dedicadas al desarrollo de sistemas, lo cual la diferencia de otras metodologías.
Estandarización del proceso de desarrollo, documentación y
herramientas: Una de las primeras facilidades que una persona encuentra al utilizar
y aprender MeRinde es el uso de un proceso de desarrollo, documentación y
herramientas estandarizados. La metodología estandariza el proceso de desarrollo de
software ya que esta provee y rige el uso de una serie de conceptos asociados a
actividades, tareas, roles y artefactos que permiten tener una definición concisa del
proceso de desarrollo entre las personas involucradas en un proyecto.
Adicionalmente las plantillas de los artefactos que envuelve dicha
metodología también ofrecen un estándar, ya que estos son un modelo o guía para
documentar adecuadamente los sistemas. Por otro lado, dicha metodología propone el
uso del Lenguaje de Modelado unificado (UML) como herramienta para elaborar los
diagramas que corresponde a los modelos y las vistas de la arquitectura.
Flujos de trabajo que refleja la realidad del desarrollo de software: La
metodología propuesta en este trabajo de investigación refleja flujos de trabajo por
disciplina adaptados a la realidad y el deber ser del desarrollo de software que se vive
70
MeRinde Guía Detallada
en el CNTI con las cooperativas y pequeñas empresas contratadas. MeRinde con el
establecimiento de los flujo de trabajo fortalece la planificación y coordinación del
proceso de desarrollo de software, dado que cada flujo de trabajo tipifica una serie de
actividades que muestran los roles, tareas y artefactos que deben ser satisfechos para
desarrollar un sistema.
Proceso de desarrollo, documentación y herramientas basadas en
estándares abiertos: La metodología MeRinde fue desarrollada utilizando estándares
abiertos, lo cual incluye las plantillas propuestas de sus artefactos y el habilitador
Web que la contempla. Adicionalmente la metodología está publicada sin
restricciones de ningún tipo, se puede adoptar libremente y está controlada por una
organización pública que vela por su evolución, en este caso dicha organización es el
CNTI. Con el uso de estándares abiertos, es posible destinar tiempo, talento y dinero
para conducir a las empresas, la industria, la Administración Pública y a toda la
sociedad hacia una situación de mayor progreso.
Modelo de equipo para el desarrollo de software que supera limitaciones
geográficas: MeRinde propone un modelo de equipo que supera las restricciones
impuestas por la ubicación del equipo de proyecto, a su vez sirve para cuando se
desarrolla software con personal interno, externo o ambos inclusive, a una
organización. Adicionalmente este modelo se fundamenta en tres (3) conceptos
básicos para su funcionamiento óptimo como son la cooperación, colaboración y la
coordinación entre todos los miembros del equipo de proyecto.
Propicia calidad en el proceso y en el producto final: MeRinde permite que
se desarrolle software con un enfoque continuo en la calidad. Por tal motivo incluye
dos roles fundamentales para garantizar calidad al proceso y al sistema desarrollado
que son el Mentor y el Analista de Calidad. El Mentor considerado como un experto
en la metodología que se está empleando apoya la calidad con la revisión de los
documentos generados durante el proyecto, así como también aclarando cualquier
duda a los participantes en el proyecto acerca del proceso de desarrollo que se está
71
MeRinde Guía Detallada
siguiendo; y el Analista de Calidad decide que modificaciones se van a realizar de las
recomendadas por el Mentor, revisa los documentos que reflejan el avance del
proyecto y verifica que los objetivos preestablecidos se cumplan.
Plantillas de los artefactos: MeRinde ofrece una serie de plantillas que
ayudarán a los responsables de elaborar los artefactos sugeridos. Estas establecen
unas pautas recomendadas para documentar diversos aspectos de los sistemas de
software sobre los cuales el equipo de proyecto puede trabajar. La idea de las mismas
es adaptarlas de acuerdo a la realidad de los proyectos manejados por la organización.
Cabe destacar que las plantillas que aporta esta metodología fueron realizadas por los
autores tomando en cuenta las plantillas de otras metodologías y de un proyecto que
provee plantillas de ingeniería de software reutilizables, además involucra plantillas
que ya existían en la organización para documentar los sistemas.
De acuerdo a lo recomendado por MeRinde todos los artefactos generados que
tienen asociado una plantilla se convierten en documentos, estos serán revisados y
puestos bajo control de versiones, por la cual se debe contar con un repositorio de
documentos. Esto permite tener una documentación adecuada y organizada para cada
uno de los proyectos, permitiendo la mantenibilidad y reutilización.
Adaptación de varias prácticas probadas por el aprendizaje: MeRinde se
basa en un conjunto de prácticas que se alejan de ser nuevas pero se combinan de
forma tal que se adaptan a las necesidades del CNTI y al contexto en que se halla el
SL en Venezuela. Las prácticas propuestas por MeRinde no son creadas por los
autores de dicha metodología pero surgen del aprendizaje de una serie de autores que
han participado en el desarrollo de muchos proyectos. Cabe destacar que las prácticas
que envuelve MeRinde han sido probadas con tiempo suficiente y además han tenido
el éxito que se considera para ubicarlas en la categoría de “Mejores Prácticas”.
72
MeRinde Guía Detallada
Ventajas de la Metodología
Entre algunas de las ventajas de emplear la metodología se encuentran:
Trazabilidad del Proceso de desarrollo: La metodología admite trazabilidad
en la documentación de los sistemas, ya que algunos de sus artefactos se relacionan
entre sí, es decir algunos artefactos son insumos de otros. MeRinde permite
trazabilidad a partir de los casos de uso, ya que estos permiten realizar el análisis, el
diseño y los casos de prueba.
Además, la metodología proporciona procedimientos que permiten registrar e
identificar cada producto generado desde el inicio hasta el final del proceso de
desarrollo de software. En algunas plantillas de los artefactos aportadas por la
metodología contienen un historial de revisiones que permite llevar un control de las
revisiones de las versiones de algún documento, y con respecto al registro de
versiones y de las modificaciones hechas al software, estos se plasman en un artefacto
denominado Notas de Lanzamiento. Con esto también la metodología garantiza
trazabilidad del proceso de desarrollo permitiendo comparar un versión con otra y
observar los avances.
Adaptación y extensión de la metodología según las particularidades del
proyecto: MeRinde es un marco de trabajo que puede ser adaptado y/o extendido a
una amplia gama de actividades, artefactos y roles conforme a las distintas
necesidades de proyectos pequeños, medianos y grandes, es decir, permite seleccionar
los elementos de la metodología o incluir elementos que no proporciona la
metodología pero que se consideran necesarios dependiendo de las características
particulares del proyecto. Adicionalmente MeRinde proporciona un artefacto llamado
Marco de Desarrollo donde se reflejan las configuraciones que se ajustan a las
necesidades del proyecto.
73
MeRinde Guía Detallada
Habilitador metodológico fácil de manejar: MeRinde está contenida en un
habilitador Web, es decir, un manejador de contenidos Web que refleja la
información de la metodología junto a las plantillas de sus artefactos de una forma
agradable al usuario y sobre todo con una navegación sencilla por intuición y ayuda
en línea. El habilitador tiene una baja curva de aprendizaje, ya que solo requiere para
su utilización que el usuario conozca aspectos básicos de la navegación de páginas
Web.
Planificación, agilidad y control de los procesos de desarrollo de
software: MeRinde se basa en la planificación que conlleva a tener una gestión y
toma de decisiones de alta calidad. La planificación se logra mediante un proceso de
descubrimiento de la información que lleve a estimaciones razonables. Hay casos en
que la realidad no se parece a lo previsto, por la cual hay que hacer ciertos ajustes. La
metodología involucra entre sus artefactos planes para el proyecto, iteraciones,
implantación, pruebas, entre otros. Esto permite organizar, controlar, evaluar y
mejorar el proceso de desarrollo de software, lo cual es de valor cuando se desarrolla
software para el estado.
Reutilización de componentes: La metodología MeRinde propicia la
reutilización de modelos, proceso, etc. ya definidos en implementaciones previas de
esta metodología. Permite que cuando se vaya a realizar un módulo desde cero se
haga una búsqueda para tratar de localizar algún componente reutilizable de fuente
abierta que pueda simplificar el desarrollo del módulo. Por lo cual la documentación
y módulos de algún sistema capaz de operar independientemente desarrollados con
esta metodología pueden ser tomados en cuenta para futuros proyectos dentro o fuera
del CNTI. La reutilización basada en componentes permite reducir los costos y el
tiempo en el proceso de desarrollo de software.
Mayor integración entre el cliente y los desarrolladores: La metodología
involucra al cliente en el proceso de desarrollo de software con una continua
participación en determinadas actividades que se repiten a lo largo del ciclo de vida
74
MeRinde Guía Detallada
de desarrollo, ya que este es quien finalmente evaluará, aprobará o desaprobará el
proyecto. La integración y la comunicación entre el cliente y los desarrolladores
evitará malos entendidos y evitará perder tiempo en rehacer el sistema. Por lo cual la
opinión del cliente acerca del proyecto es la base para hacer los reajustes si algo no
estuviese del todo bien.
En las actividades de algunas disciplinas reflejadas en MeRinde hace su
aparición el cliente como involucrado en el proyecto, al cual se le atribuye algunas
tareas que debe realizar en colaboración con otros involucrados. El cliente sirve de
apoyo en tareas orientadas a entender el negocio, identificar los requerimientos,
hacer planes, acordar las pruebas, enviar solicitudes de cambio, entre otras.
Fortalecimiento del perfil de las empresas, cooperativas y comunidades
desarrolladoras de SL: Con MeRinde las organizaciones pueden adoptar una
metodología libre, para aumentar su capacidad de control, trazabilidad y reutilización.
Por otro lado, la definición de actividades, tareas y roles permitirá a las
organizaciones aumentar la planificación, distribuir funciones entre los miembros del
equipo y mitigar el caos implícito en el desarrollo de software. A su vez, MeRinde
contribuye con la educación y la formación del capital humano en el uso y aplicación
de las TIC.
Habilitador Web con Foro: El habilitador Web incorpora un foro como
herramienta para que personas de las comunidades de desarrollo ayuden al
fortalecimiento de la metodología y de sus artefactos con el aporte de ideas, y para
discutir cualquier clase de dudas que se les pueda presentar a los usuarios sobre la
metodología.
75
MeRinde Guía Detallada
Desventajas de la Metodología
Entre algunas de las desventajas observadas en la metodología se encuentran:
Falta de plantillas para un grupo determinado de artefactos: MeRinde no
provee plantillas para todos los artefactos que esta contempla, pero ninguno de esos
artefactos planteados son considerados para los proyectos como esenciales,
adicionalmente hay artefactos que por su descripción se puede sobreentender su
contenido y estructura.
La metodología puede ser vista como muy pesada: El contenido de la
metodología es muy amplio y complejo, lo que puede ser visto como muy pesado, por
tal motivo, quienes desconozcan que esta es un marco de trabajo es posible que no la
utilicen, ya que caen en el error de pensar que hay que considerar todos los elementos
que esta ofrece y que esta no admite adaptabilidad ni extensibilidad dependiendo de
las particularidades del proyecto, lo cual no es cierto.
No contempla una herramienta para instanciar el proceso de desarrollo:
MeRinde solo contempla la instanciación del proceso conforme a todos sus
artefactos, actividades y tareas, pero no posee una herramienta para hacer las
personalizaciones a los proyectos, para ello se sugiere el empleo de herramientas de
terceros como el Eclipse Process Framework Project (EPF) disponible en
http://www.eclipse.org/epf/.
No especifica la instanciación del proceso para pequeños, medianos y
grandes proyectos: MeRinde no especifica que disciplinas, actividades, tareas, roles
y subroles se deben emplear conforme a la magnitud del proyecto, pero si especifica
cuáles son las disciolinas, artefactos y roles esenciales para el desarrollo de cualquier
proyecto.
76
MeRinde Guía Detallada
SÍNTESIS DE LA METODOLOGÍA MERINDE
La Metodología MeRinde es un proceso de desarrollo de software. Un
proceso de desarrollo de software es el conjunto de actividades necesarias para
transformar los requerimientos de un usuario en un sistema software. Sin embargo,
La Metodología MeRinde más que un proceso simple; es un marco de trabajo
genérico que puede especializarse para una gran variedad de sistemas software, para
diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles
de aptitud y diferentes tamaños de proyecto.
La Metodología MeRinde está basado en componentes, lo cual quiere decir
que el sistema software en construcción está formado por componentes software
interconectados a través de de interfaces bien definidas.
La Metodología MeRinde utiliza el Lenguaje Unificado de Modelado (Unified
Modeling Language, UML) para preparar todos los esquemas de un sistema software.
Esta propuesta metodológica, la cual fue utilizada en la experiencia descrita
en este documento, surge de la combinación y adaptación de modelos y metodologías
ampliamente utilizadas para el desarrollo de software.
77
MeRinde Guía Detallada
GLOSARIO
En esta sección se presentará una lista que contiene las definiciones de los
términos utilizados en este trabajo de investigación. Dichos términos se definen en
orden alfabético a continuación:
Actividad: Es una unidad de trabajo que una persona que desempeñe un rol
puede ser solicitado a que realice. Las actividades tienen un objetivo concreto,
normalmente expresado en términos de crear o actualizar algún producto.
Administración Pública: Descripción de la base metodológica para el
desarrollo del proyecto y el logro de los resultados esperados. Conjunto de
organismos e instituciones que se encargan de esta organización.
Artefacto: Es un trozo de información que es producido, modificado o usado
durante el proceso de desarrollo de software. Los artefactos son los resultados
tangibles del proyecto.
Caso de Uso: Es una técnica para la captura de requerimientos de un nuevo
sistema o una actualización software.
Ciclo de Vida: Conjunto de fases sucesivas compuestas por tareas
planificables que contribuyen a generar un producto intermedio, necesario para
continuar hacia el producto final y facilitar la gestión del proyecto.
Componente: Representa una parte modular del sistema que encapsula su
contenido y cuya manifestación es reemplazable dentro de su ambiente.
Comunicación: intercambio con otro u otros de información.
78
MeRinde Guía Detallada
Configuración: Es una colección de propiedades que determinan el
comportamiento del proceso de elaboración del software.
Cooperación: Realización de un trabajo o tarea con otro u otros para un
mismo alcanzar un mismo fin.
Coordinación: Reunión de medios, esfuerzos, etc., para una acción común.
Diagrama: Representación gráfica en el que se muestran las relaciones entre
las diferentes partes de un conjunto o sistema.
Disciplina: es un conjunto de actividades realizadas en un área determinada.
Las actividades producen artefactos.
Estándar: Es una norma que regula la realización de ciertos procesos o la
fabricación de componentes. En otras palabras es un modelo que se sigue para
realizar un proceso o una guía que se sigue para no desviarnos de un lugar al que se
desea llegar.
Estereotipo: Un nuevo tipo de elemento de modelado que extiende la
semántica de un metamodelo. Los estereotipos deben basarse en ciertos tipos
existentes o clases en el metamodelo. Los estereotipos pueden extender la semántica,
pero no la estructura o tipos pre-existentes y clases.
Fase: Expresa cómo ha progresado el desarrollo de un software y cuánto
desarrollo puede requerir.
Fichero: Es todo conjunto organizado de datos de carácter personal,
cualquiera que fuere la forma o modalidad de su creación, almacenamiento,
organización y acceso.
79
MeRinde Guía Detallada
Finde Forge: Herramienta de software libre que ayuda a gestionar todo el
ciclo de vida de desarrollo de proyectos de software.
“Framework” o Marco de Trabajo: Es una estructura de soporte definida
en la cual otro proyecto de software puede ser organizado y desarrollado. Provee una
estructura y una metodología de trabajo la cual extiende o utiliza las aplicaciones del
dominio.
Flujo de Trabajo: es el estudio de los aspectos operacionales de una
actividad de trabajo: cómo se estructuran las tareas, cómo se realizan, cuál es su
orden correlativo, cómo se sincronizan, cómo fluye la información que soporta las
tareas y cómo se le hace seguimiento al cumplimiento de las tareas.
Habilitador: Que habilita a alguien. Es un intermediario entre el usuario y la
información.
Herramienta: Funciones que ofrece un programa a través de una barra con
íconos, que representan los distintos recursos del software para realizar una tarea
determinada.
Hito: Punto de control de objetivo intermedio antes de que el proyecto
finalice.
Iteración: Repetición de una secuencia de instrucciones o eventos.
Lenguaje Unificado de Modelado (UML): Es un lenguaje gráfico para
visualizar, especificar, construir y documentar un sistema de software.
Licencia: El derecho de uso de una versión específica de un producto.
80
MeRinde Guía Detallada
Mentoría: Es un proceso mediante el cual una persona o varios personas con
experiencia ayuda a otras personas a lograr sus metas y cultivar sus habilidades a
través de una serie de reuniones de tipo personal, confidencial y limitadas en cuanto
al tiempo y otras actividades de aprendizaje, dentro de una organización.
Metodología: Manera sistemática de hacer cierta cosa.
Modelo: Es una vista de un sistema del mundo real, es decir, una abstracción
de dicho sistema considerando un cierto propósito.
Módulo: Es un componente autocontrolado de un sistema, el cual posee una
interfaz bien definida hacia otros componentes.
Plantilla: Es un conjunto predefinido de formas que establece la estructura
necesaria para crear contenido rápidamente.
Repositorio: Es un sitio centralizado donde se almacena y mantiene
información, habitualmente bases de datos o archivos informáticos.
Requerimiento: Es una necesidad documentada sobre el contenido, forma o
funcionalidad de un producto o servicio.
Reutilización: Puede entenderse como el hecho de volver a utilizar los bienes
o productos. La utilidad puede venir para el usuario mediante una acción de mejora o
restauración, o sin modificar el producto si es útil para un nuevo usuario.
Rol: Define el comportamiento y responsabilidades de un individuo, o de un
grupo de individuos trabajando juntos como un equipo.
81
MeRinde Guía Detallada
Script: Es un guión o conjunto de instrucciones. Permiten automatizar tareas
creando pequeñas utilidades. Son interpretadas por un intérprete y usualmente son
archivos de texto.
Stakeholder: Toda aquella persona u organización siendo influenciada o
ejerciendo influencia sobre el software que está siendo construido.
Sociedad del Conocimiento: sociedad dotada de habilidad, capacidad y
pericia para generar y captar nuevos conocimientos y tener acceso a la información, a
los datos y a los conocimientos absorberlos y utilizarlos eficazmente con el apoyo de
las Tecnologías de Información y Comunicación.
Tarea: Parte de una Actividad. Las tareas son actividades específicas que
contribuyen al cumplimiento de la misión general u otros requerimientos.
Tecnología de Información y Comunicación (TIC): Concepto empleado
para designar lo relativo a la informática conectada con los medios de comunicación,
especialmente con Internet, son medios que nos aportan un flujo ininterrumpido de
información.
Trazabilidad: Aquellos procedimientos preestablecidos y autosuficientes que
permiten conocer el histórico, la ubicación y la trayectoria de un producto o lote de
productos a lo largo de la cadena de suministros en un momento dado, a través de
unas herramientas determinadas.
82
MeRinde Guía Detallada
REFERENCIAS BIBLIOGRÁFICAS
Farouz, Joachim (2006) Kopete Vista Icono Theme [Document en línea]. Disponible:
http://www.kde-look.org/content/show.php?content=48635 como 48635-
Kopete_Vista.tar [consulta: 2006, Diciembre 16].
83
MeRinde Guía Detallada
APÉNDICES
84
MeRinde Guía Detallada
APÉNDICE A
DESCRIPCIÓN DE LOS ARTEFACTOS PROPUESTOS DE MERINDE
85
MeRinde Guía Detallada
A continuación se detallan y se establecen las relaciones en orden alfabético
de cada uno de los artefactos que se proponen MeRinde:
Artefactos de Instalación
Este artefacto tiene como objetivo permitir que la instalación del sistema sea
llevado a cabo por alguien. Se basa en los programas e instrucciones documentadas
requeridos para que ese alguien instale el producto. Puede incluir: instrucciones,
scripts, iconos, archivos de licencia, etc.
Los Artefactos de Instalación son necesarios cuando se quiere configurar el
sistema mediante los programas de instalación y pueden ser descartados si el sistema
es instalado una vez, ya sea porque el sistema es de uso interno en un servidor
corporativo. Las instrucciones de instalación se reflejan en el Manual de Instalación y
si se espera que el usuario instale el producto (sistema) puede reflejarse en el Manual
de Usuario.
Relaciones de Artefactos de InstalaciónRol Responsable: Desarrollador
Disciplina: Implantación
Artefacto Contenedor: El Sistema
Artefacto(s) Contenido(s): No aplica
Plantilla: No posee
Calificación de los Aspectos Técnicos de los Servicios de Desarrollo de Sistemas
Este artefacto debe contener instrumentos para la recolección de los aspectos
técnicos de los servicios de desarrollo de sistemas que han prestado las potenciales
contratistas que ofrezcan sus servicios para el desarrollo del producto, a fin de ser
86
MeRinde Guía Detallada
evaluados por los miembros del comité de selección para elegir las contratistas que
sean necesarias para el proyecto.
Para la elaboración de este artefacto se debe haber suministrado a las
potenciales contratistas el artefacto Términos de Referencia del Sistema, a fin de que
ellas plasmen en este artefacto conforme al proyecto que se desea realizar: una
propuesta de servicio, su experiencia en trabajos anteriores, su método o forma de
trabajo, una planificación para la ejecución del trabajo, descripción de la cantidad y
nivel académico del personal con que dispondrán, entre otras características que se
puedan evaluar para la selección de la mejor oferta.
Relaciones del Artefacto Calificación de los Aspectos Técnicos de los Servicios de Desarrollo de Sistemas Rol Responsable: Involucrados
Disciplina: Gestión del Proyecto
Artefacto Contenedor: No aplica
Artefacto(s) Contenido(s): No aplica
Plantilla: Si posee
Capsula
Este artefacto es un modelo de diseño específico que representa a un hilo de
control en el sistema en desarrollo, es útil para modelar y diseñar sistemas que tienen
un alto grado de concurrencia, y su empleo como notación facilita el diseño.
Una capsula es un elemento compuesto y se representa como una clase
estereotipada con el nombre de <<capsule>>. Para ver su notación se debe revisar
UML 2.0 o superior en la sección sobre Estructuras Compuestas.
87
MeRinde Guía Detallada
Relaciones del Artefacto CapsulaRol Responsable: Arquitecto de Software
Disciplina: Análisis y Diseño
Artefacto Contenedor: Modelo de Diseño
Artefacto(s) Contenido(s): No aplica
Plantilla: No posee
Casos de Pruebas
Este artefacto define un conjunto de datos de entradas, condiciones de
ejecución y resultados esperados de las pruebas, identificados para hacer una
evaluación de los aspectos específicos de un elemento objeto de prueba. Cada Caso
de de Prueba está asociado a un escenario de un Caso de Uso en particular.
Los casos de prueba deben ser escritos con el detalle suficiente para que el
probador pueda empezar rápidamente a ejecutar pruebas y a encontrar defectos.
Además, estos reflejan trazabilidad con los casos de uso, las especificaciones
suplementarias de requerimientos y diseño del sistema, garantizando que los
procedimientos de pruebas sean compatibles con las necesidades de los
usuarios/clientes.
En la metodología los Casos de Uso dirigen todo el proceso de desarrollo, es
por ello que los Casos de Uso se transforman en un activo que puede directamente
conducir el proceso de pruebas. Un Caso de Prueba no es igual a un Caso de Uso. El
Caso de Prueba extiende o amplía la información contenida en un Caso de Uso.
Relaciones del Artefacto Casos de PruebaRol Responsable: Probador
Disciplina: Pruebas
Artefacto Contenedor: Plan de Pruebas
88
MeRinde Guía Detallada
Artefacto(s) Contenido(s): No aplica
Plantilla: Si posee
Componente Operacional del Sistema
Este artefacto es una versión operacional del sistema o parte de este que cubre
un subconjunto especificado de los requerimientos que el sistema final cumplirá. Este
comprende uno o más elementos de la aplicación (funciones ejecutables) que son
creados de otros elementos mediante un proceso de compilación y unión del código
fuente. Agrupa un conjunto de Subsistemas de Implementación. Cabe destacar que
cada una de las funciones y capacidades que representan una parte del sistema pueden
ser probadas durante su ejecución.
Relaciones del Artefacto Componente Operacional del SistemaRol Responsable: Desarrollador
Disciplina: Implementación
Artefacto Contenedor: No aplica
Artefacto(s) Contenido(s): No aplica
Plantilla: No posee
Criterios de Aceptación
Este artefacto determina la precisión mínima requerida o las características
específicas de funcionamiento necesarias para que los resultados obtenidos en las
pruebas e inspecciones puedan garantizar la adecuación del producto a sus
especificaciones.
Este artefacto describe cómo el cliente evaluará los entregables del proyecto y
bajo qué condiciones aceptará el producto, incluyendo los casos de pruebas del
proyecto a ejecutarse.
89
MeRinde Guía Detallada
Es responsabilidad del equipo de gestión del proyecto y del cliente acordar
los criterios de aceptación del producto y efectuar las pruebas necesarias que
verifiquen dichos criterios. Los criterios de aceptación son capturados a través de:
• El artefacto Términos de Referencia del Sistema
• El artefacto Casos de Prueba.
Relaciones del Artefacto Criterios de AceptaciónRol Responsable: Involucrados
Disciplina: Pruebas
Artefacto Contenedor: Plan de Pruebas
Artefacto(s) Contenido(s): No aplica
Plantilla: Si posee
Datos de Pruebas
Este artefacto define una lista de variables y sus posibles valores a introducir
para la ejecución de las pruebas, así como también los resultados esperados de la
ejecución para propósitos comparativos. Se pueden tomar en cuenta valores
específicos o describir rangos de valores. Los Datos de Pruebas se utilizan como
fuente de engaño al objeto de prueba y así encontrar errores. Cabe destacar que cada
caso de prueba deberá ser ejecutado una vez por cada combinación de valores.
Relaciones del Artefacto Datos de PruebasRol Responsable: Probador
Disciplina: Pruebas
Artefacto Contenedor: Plan de Pruebas
Artefacto(s) Contenido(s): No aplica
Plantilla: Si posee
90
MeRinde Guía Detallada
Documento de Arquitectura del Negocio (DAN)
El DAN ayuda a conocer la realidad del negocio, ya que proporciona una
visión general de los objetivos, estructura y funcionamiento del negocio. Este
describe el qué, por qué y cómo del negocio, y contiene varias vistas que muestran
aspectos claves del mismo como son: Vista del Mercado, Vista del Proceso de
Negocio, Vista de la Organización, Vista Geográfica, Vista del Recurso Humano,
Vista del Dominio y Vista de Comunicación. Cada una de estas vistas nos da una
diferente perspectiva del negocio.
Las vistas incluidas en el Documento de Arquitectura del Negocio (DAN) se
describen a continuación.
Vista del Mercado: Describe los mercados en el que opera el negocio, los
perfiles de los clientes y las ofertas, o los productos y servicios que ofrece el negocio
a los clientes en los mercados designados.
Esta vista sólo se debe tomar en cuenta si se estarán tomando decisiones con
respecto a la estrategia del negocio, para mostrar cómo la arquitectura del negocio es
afectada o en los casos dónde la estrategia del negocio puede verse influenciada por
las decisiones referidas a la arquitectura. En este sentido la realización de la Vista del
Mercado es opcional.
Vista de Procesos del Negocio: Esta vista que incluye los procesos claves del
negocio, es un subconjunto del artefacto Modelo de Caso de Uso del Negocio. La
Vista de Procesos representa los casos de uso del negocio mediante un diagrama que
refleja la relación existente entre los actores del negocio y los casos de uso del
negocio. Es significativo identificar la jerarquía de actores del negocio y realizar un
diagrama de clases con ellos. Esta vista es obligatoria.
91
MeRinde Guía Detallada
Vista de la Organización: Esta vista es inicialmente un subconjunto del
Artefacto Modelo de Análisis del Negocio, incluyendo elementos que son
significativos para la arquitectura del negocio. Como el Modelo de Análisis del
Negocio es refinado en el artefacto Modelo de Diseño del Negocio, la vista de la
organización cambia para mostrar cómo se enlazan los roles en el negocio a las
personas, software y hardware.
La Vista de la Organización describe a los trabajadores más importantes,
entidades y eventos del negocio, su agrupación en los sistemas del negocio, y la
organización de éstos en capas. También incluye las realizaciones de los casos de uso
del negocio más importantes y descripciones de los modelos generales de conducta.
Su realización es obligatoria.
Vista Geográfica: Muestra la distribución de la estructura de la organización,
funciones y recursos a través de las localizaciones físicas como las ciudades y países.
Esta vista emplea un diagrama de clases donde cada locación es una clase, y también
se muestra dependencias y relaciones entre ellas.
Esta vista es opcional, ya que se realiza solamente si se necesita entender el
efecto que tiene la distribución geográfica de las operaciones del negocio en los
procesos del negocio y la estructura.
Vista de Recurso Humano: Describe los perfiles de remuneración y los
mecanismos de incentivo, las características y mecanismos culturales más
importantes, el ambiente de competencia, aspectos referentes a educación y
mecanismos de entrenamiento.
Esta vista sólo se realiza si la reorganización implica cambios significativos
en la forma de trabajar de las personas y las relaciones entre ellas, por lo tanto es
opcional.
92
MeRinde Guía Detallada
Vista del Dominio: Se refiere a los elementos más importantes de un Modelo
de Análisis para la organización. Describe los principales conceptos del negocio y
estructuras de la información usadas por el negocio.
Es opcional, ya que sólo se realiza si la información del negocio se considera
significativa y si se necesita aclarar los conceptos que son importantes para el
dominio del negocio. Esta es muy útil para mejorar la comunicación y el
entendimiento entre los diferentes departamentos, proyectos o externos.
Vista de Comunicación: Describe las vías de comunicación dentro del
negocio. Es opcional y por la tanto sólo se realiza si se quiere entender los cambios
internos y externos en la comunicación.
Relaciones del Artefacto Documento de Arquitectura del Negocio (DAN)Rol Responsable: Involucrados
Disciplina: Modelado del Negocio
Artefacto Contenedor: No aplica
Artefacto(s) Contenido(s): No aplica
Plantilla: Si posee
Documento de Arquitectura del Software (DAS)
Es una especificación de las ideas principales del diseño. El DAS proporciona
una descripción entendible de la arquitectura del sistema software y sirve como
medio de comunicación entre el arquitecto de software y otros miembros de equipo
del proyecto con respecto a las decisiones arquitectónicamente significativas que se
han tomado en el proyecto. Contiene varias vistas que muestran aspectos distintos del
sistema como son: Vista de Casos de Uso, Vista Lógica, Vista de Implementación,
Vista del Proceso, Vista de Implantación y Vista de Datos.
93
MeRinde Guía Detallada
Las vistas involucradas en el Documento de Arquitectura del Software (DAS)
se detallan a continuación.
Vista de Casos de Uso: Esta vista muestra la funcionalidad del sistema como
es percibida desde el exterior. Así como también describe un conjunto de escenarios y
casos de uso que tienen una cobertura arquitectónicamente significativa o que ilustran
un punto específico de la arquitectura. Es un subconjunto del Modelo de Casos de
Uso y además su realización es obligatoria.
Vista Lógica: Describe el diseño más importante de las clases y su
organización en paquetes y subsistemas, y la organización de éstos en capas. También
contiene algunas realizaciones de casos de uso. Esta muestra cómo la funcionalidad
es diseñada en el interior del sistema, en términos de la estructura estática y
comportamiento dinámico del sistema. Es un subconjunto del Modelo de Casos de
Uso y su realización es obligatoria.
Vista de Implementación: Esta vista muestra la organización del código y el
código actual de ejecución. Contiene una visión general del Modelo de
Implementación y su organización en términos de módulos en paquetes y capas.
También se describe la asignación de paquetes y clases de la Vista Lógica a los
paquetes y módulos de la Vista de Implementación. Es un subconjunto del Modelo de
Implementación.
Esta vista es opcional, ya que sólo se realiza en los casos donde la
implementación no se conduce estrictamente por el diseño. Si el empaquetado de los
modelos de diseño y de implementación son idénticos, esta vista puede ser omitida.
Vista de Procesos: En esta vista se describe las tareas, sus interacciones y
configuraciones, y la asignación de objetos del diseño y clases a las tareas. Muestra
los elementos relacionados con el desempeño incluyendo escalabilidad, concurrencia
y tiempo base de desempeño. Es un subconjunto del Modelo de Diseño y se usa sólo
94
MeRinde Guía Detallada
si el sistema tiene un grado significante de concurrencia, por lo tanto es una vista
opcional.
Vista de Implantación: Describe varios nodos físicos para las
configuraciones más típicas de las plataformas y la asignación de las tareas de la
Vista del Proceso a los nodos físicos. Es un subconjunto del Modelo de
Implantación. Esta vista se realiza sólo si el sistema es distribuido a través de más de
un nodo, por lo tanto es opcional.
Vista de Datos: Esta vista especifica arquitectónicamente los elementos
constantes en el Modelo de Datos. Describe una apreciación global del modelo de los
datos y su organización por lo que se refiere a las tablas, vistas y almacenamiento de
los procedimientos que proporcionan la persistencia al sistema. También describe la
cartografía de clases constantes de la Vista Lógica a la estructura de los datos de la
base de datos.
Esta vista es opcional, ya que sólo se realiza si la persistencia es un aspecto
significante del sistema y el traslado del Modelo de Diseño al Modelo de Datos no se
hace automáticamente por el mecanismo de persistencia.
Relaciones del Artefacto Documento de Arquitectura del Software (DAS)Rol Responsable: Arquitecto de Software
Disciplina: Análisis y Diseño
Artefacto Contenedor: No aplica
Artefacto(s) Contenido(s): No aplica
Plantilla: Si posee
Elemento de Implementación
El elemento de implementación es un artefacto que representa el más bajo
nivel de composición de un componente de software, es decir, un conjunto de
95
MeRinde Guía Detallada
elementos de implementación son los que conforman a un componente del sistema.
Este artefacto puede ser un código fuente, un código binario, un archivo, un
ejecutable, entre otros.
Relaciones del Artefacto Elemento de ImplementaciónRol Responsable: Desarrollador
Disciplina: Implementación
Artefacto Contenedor: Modelo de Implementación
Artefacto(s) Contenido(s): No aplica
Plantilla: No posee
Elemento de Soporte de Prueba
Este artefacto contribuye a facilitar las pruebas que se van a ejecutar al
sistema, tanto manuales como automáticas. Es un elemento que realiza una función
específica para una determinada prueba que el software soporta. Estos artefactos
comúnmente son creados ó modificados en paralelo con los elementos ó componentes
que están siendo implementados. Dos ejemplos de esta clase de artefacto son:
• Cuando se implementa una determinada interfaz ó salida para informar
cuando se produce una acción específica en el sistema.
• Cuando se simula la función de un componente determinado que aun no
ha sido implementado a fin de poder probar otras funcionalidades del
sistema.
Relaciones del Artefacto Elemento de Soporte de PruebaRol Responsable: Desarrollador
Disciplina: Implementación
Artefacto Contenedor: Modelo de Implementación
Artefacto(s) Contenido(s): No aplica
Plantilla: No posee
96
MeRinde Guía Detallada
El Sistema
Este artefacto es el producto final, es decir, el sistema ya funcionando que
puede ser instalado y ser utilizado por el cliente. Un Sistema se diferencia de una
unidad de implantación, ya que el sistema puede contener varias unidades de
implantación. Cabe destacar que dichas unidades de implantación que reúne el
sistema pueden ser exportadas a una unidad de almacenamiento.
Relaciones del Artefacto SistemaRol Responsable: Involucrados
Disciplina: Implantación
Artefacto Contenedor: No aplica
Artefacto(s) Contenido(s): • Lista de Materiales• Artefactos de Instalación• Unidad de Implantación
Plantilla: No posee
Entidad del Negocio
Este artefacto representa una pieza de información significativa que es
manipulada por los actores y trabajadores del negocio. Se refiere al estado de la
información que pasará entre cada capa como un conjunto de datos que la identifican
una entidad. Las entidades del negocio de una aplicación representa entidades reales y
además suelen ser sustantivos, como por ejemplo: Cliente, Nómina, Factura,
Depósito, etc. Asimismo, las entidades de negocio son la base para compartir
documentos entre los trabajadores del negocio y estas pueden ser utilizadas en
diversas Realizaciones de los Casos de Uso del Negocio.
97
MeRinde Guía Detallada
Relaciones del Artefacto Entidad del NegocioRol Responsable: Involucrados
Disciplina: Modelado del Negocio
Artefactos Contenedores: • Modelo de Análisis del Negocio
• Modelo de Diseño del Negocio
Artefacto(s) Contenido(s): No aplica
Plantilla: No posee
Escenarios por Casos de Uso
Este artefacto se representa a través de una matriz en la cual se indica los
escenarios que contiene un caso de uso. Esta matriz contiene la identificación del
escenario, el flujo básico y los flujos alternos del escenario. Cabe destacar que cada
flujo o combinación de ellos es un posible escenario que puede ser ejecutado y
probado.
Relaciones del Artefacto Escenarios por Casos de UsoRol Responsable: Probador
Disciplina: Pruebas
Artefacto Contenedor: Plan de Pruebas
Artefacto(s) Contenido(s): No aplica
Plantilla: Si posee
Especificación de Migración de Datos
Este artefacto debe contener el perfil de los datos que van ser migrados, así
mismo se debe incluir la relación entre la fuente de los datos con la base de datos a la
cual serán migrados.
98
MeRinde Guía Detallada
Relaciones del Artefacto Especificación de Migración de DatosRol Responsable: Arquitecto de Software
Disciplina: Análisis y Diseño
Artefacto Contenedor: No aplica
Artefacto(s) Contenido(s): No aplica
Plantilla: No posee
Especificación de Requerimientos del Software (ERS)
El objetivo de este artefacto es documentar todos los requerimientos del
sistema, este describe las funciones del sistema, los requerimientos no funcionales,
características del diseño, y otros elementos necesarios para proporcionar una
descripción completa y comprensiva de los requerimientos para el software a
desarrollar.
Los requerimientos pueden ser levantados con diferentes herramientas,
también se pueden encontrar dispersos en varios artefactos y herramientas. Es por
ello, que esta metodología propone capturar todos los requerimientos para el ERS en
un solo artefacto, el cual está conformado por dos (2) artefactos que describen los
requerimientos que son: Modelo de Casos de Uso y Especificaciones Suplementarias.
El artefacto ERS controla la evolución del sistema durante toda el ciclo de
desarrollo del proyecto, cuando las nuevas características son añadidas o modificadas
al artefacto de visión, son aclarados dentro del artefacto ERS.
Las decisiones hechas escribiendo el ERS están basadas en información de los
documentos de la propuesta del proyecto y en requerimientos del usuario. El
conjunto de requerimientos especificados en el ERS deben ser satisfechos en el
diseño del sistema. Cualquier requerimiento funcional o no funcional que no sea
identificado en el ERS, no debe aparecer en el producto final.
99
MeRinde Guía Detallada
Relaciones del Artefacto Especificación de Requerimientos del Software (ERS)Rol Responsable: Analista de Producto
Disciplina: Requerimientos
Artefacto Contenedor: No aplica
Artefacto(s) Contenido(s): • 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, desempeño, mantenibilidad,
seguridad, restricciones de diseño, requerimientos de documentación en línea y de
sistemas de ayuda, componentes comprados, interfaces, requerimientos de
licenciamiento, y aspectos legales, derecho de autor y otros avisos.
Relaciones del Artefacto Especificaciones SuplementariasRol Responsable: Analista de Producto
Disciplina: Requerimientos
Artefacto Contenedor: Especificación de Requerimientos del Software (ERS)
Artefacto(s) Contenido(s): No aplica
Plantilla: Si posee
Evaluación de la Organización Objetivo (EOO)
Este artefacto describe la situación actual en que se encuentra la organización
objetivo, es decir, la organización en la que el sistema será implantado. La
100
MeRinde Guía Detallada
descripción está en términos de procesos actuales, herramientas, competencias entre
personas, actitudes de las personas, clientes, competidores, tendencias técnicas,
problemas y áreas de mejora.
El EOO también es usado para crear motivación y comprensión entre las
personas en la organización objetivo que son directamente o indirectamente
afectadas, así como también explicar al involucrado por qué existe la necesidad de
cambiar los procesos del negocio, y además proporcionar la entrada al Marco de
Desarrollo y al Plan de Iteración.
Relaciones del Artefacto Evaluación de la Organización Objetivo (EOO)Rol Responsable: Involucrados
Disciplina: Modelado del Negocio
Artefacto Contenedor: No aplica
Artefacto(s) Contenido(s): No aplica
Plantilla: Si posee
Glosario del Sistema
Es una lista que contiene las definiciones de los términos a hacer utilizados
durante la realización del proyecto, que deben ser comprendidos por los participantes
de tal manera que haya una buena comunicación y evitar interpretaciones dispares o
ambiguas de los términos del dominio del problema.
Documentar las definiciones de términos y acrónimos ayuda a otros artefactos
a ser más concisos y precisos. En algunos proyectos donde la planeación del negocio
y del dominio no se realiza, el Glosario es el artefacto principal para capturar la
información sobre el dominio de negocio del proyecto.
101
MeRinde Guía Detallada
Relaciones del Artefacto Glosario del SistemaRol Responsable: Analista de Producto
Disciplina: Requerimientos
Artefacto Contenedor: No aplica
Artefacto(s) Contenido(s): No aplica
Plantilla: Si posee
Herramientas
Este artefacto corresponde con las herramientas necesarias para apoyar el
esfuerzo de desarrollo del software. Cabe destacar que un proceso de Ingeniería de
software requiere de las herramientas para apoyar todas las actividades en el ciclo de
vida de un sistema.
Relaciones del Artefacto HerramientasRol Responsable: Involucrados
Disciplina: Gestión del Ambiente
Artefacto Contenedor: Infraestructura de Desarrollo
Artefacto(s) Contenido(s): No aplica
Plantilla: No posee
Infraestructura de Desarrollo
Este artefacto incluye el software y hardware, tal como computadoras y
sistemas operativos, en los cuales funcionan las herramientas. La Infraestructura de
Desarrollo también incluye el hardware y el software que son usados para
interconectar las computadoras y a los usuarios. Varias son las infraestructuras de
desarrollo requeridas durante el ciclo de vida de elaboración del producto, una
infraestructura estándar debe existir para permitir que ocurra el esfuerzo de
102
MeRinde Guía Detallada
desarrollo, otra infraestructura se puede configurar para las pruebas realizadas dentro
de la organización y otra se puede requerir para la puesta en marcha del sistema en las
instalaciones del cliente.
Relaciones del Artefacto Infraestructura de DesarrolloRol Responsable: Involucrados
Disciplina: Gestión del Ambiente
Artefacto Contenedor: No aplica
Artefacto(s) Contenido(s): Herramientas
Plantilla: No posee
Licitación de Personal
Este artefacto es una orden generada si se desea contratar personal externo a la
organización para el desarrollo del proyecto especificado en el artefacto Términos de
Referencia del Sistema. El artefacto puede ser una oferta que consista en realizar un
concurso público para organizaciones de diversa índole de base tecnológica como
cooperativas y empresas interesadas en participar en el desarrollo del sistema.
Relaciones del Artefacto Licitación de PersonalRol Responsable: Líder del Proyecto
Disciplina: Gestión del Proyecto
Artefacto Contenedor: No aplica
Artefacto(s) Contenido(s): No aplica
Plantilla: No posee
103
MeRinde Guía Detallada
Lineamientos del Proyecto
En este artefacto se detallan las prescripciones necesarias para ejecutar
determinadas tareas durante el proyecto, además es donde se captura cualquier
decisión que involucre la modificación o adaptación de algún artefacto y debe ser
empleado por todos los miembros del proyecto para la ejecución de las actividades
que le han sido asignadas.
Generalmente los lineamientos para la elaboración de los proyectos son
controlados y establecidos por un grupo de personas internos a la organización para la
cual se va a desarrollar el producto, y deben estar contenidos dentro de determinados
repositorios de la misma.
Relaciones del Artefacto Lineamientos del ProyectoRol Responsable: Involucrados
Disciplina: Gestión del Ambiente
Artefacto Contenedor: Marco de Desarrollo
Artefacto(s) Contenido(s): No aplica
Plantilla: No posee
Lista de Ideas de las Pruebas
Este artefacto contiene las ideas que potencialmente serán las pruebas más
útiles a realizar. La Lista de Ideas de las Pruebas ayuda a pensar sobre las pruebas
desde etapas muy tempranas y sobre las primeras pruebas a ejecutarse. Es
particularmente útil cuando los artefactos están inasequibles o incompletos.
Pueden estar contenidas dentro del Plan de Pruebas en la sección de Ideas
Iníciales y otras Fuentes de referencia.
104
MeRinde Guía Detallada
Relaciones del Artefacto Lista de Ideas de las PruebasRol Responsable: Probador
Disciplina: Pruebas
Artefacto Contenedor: Plan de Pruebas
Artefacto(s) Contenido(s): No aplica
Plantilla: Si posee
Lista de Materiales
Este artefacto lista los componentes de una versión dada de un producto y
define donde los componentes físicos pueden ser encontrados. Además, describe los
cambios realizados en la versión y se refiere a la forma en que el producto puede ser
instalado.
Relaciones del Artefacto Lista de MaterialesRol Responsable: Líder del Proyecto
Disciplina: Implantación
Artefacto Contenedor: El Sistema
Artefacto(s) Contenido(s): No aplica
Plantilla: No posee
Manual de Instalación
El manual de instalación es un artefacto que refleja los lineamientos que hay
que seguir para instalar el sistema. Contiene información sobre la infraestructura de
instalación e instrucciones para la instalación y actualización del software.
105
MeRinde Guía Detallada
Relaciones del Artefacto Manual de InstalaciónRol Responsable: Involucrados
Disciplina: Implantación
Artefacto Contenedor: No aplica
Artefacto(s) Contenido(s): No aplica
Plantilla: Si posee
Manual de Usuario
Este artefacto provee una ayuda a las personas que manipularán directamente
el producto, acerca del uso que le debe dar al sistema. Dicho artefacto debe ser
discutido y aprobado por el cliente.
Elaborar el manual de usuario durante las primeras iteraciones del proyecto
permitirá al equipo de probadores conocer el sistema antes de que comiencen las
pruebas, adicionalmente provee los mecanismos básicos para elaborar los planes de
pruebas y los casos de pruebas, y permite la elaboración de sistemas automatizados
para las pruebas.
Según el tipo de sistema se define el comienzo del desarrollo del Manual de
Usuario. Sistemas con interfaces complejas o con mucha interacción requerirán
versiones tempranas del manual de usuario así como de prototipos de interfaces.
Sistemas con poca interacción probablemente no requieran que la documentación del
usuario se elabore muy temprano.
Relaciones del Artefacto Manual de UsuarioRol Responsable: Involucrados
Disciplina: Implantación
Artefacto Contenedor: No aplica
Artefacto(s) Contenido(s): No aplica
Plantilla: Si posee
106
MeRinde Guía Detallada
Mapa de Navegación
Este artefacto expresa la estructura de los elementos de la interfaz de usuario
del sistema, junto a los caminos de navegación principales. Este permite al usuario
una adecuada navegación en el sistema y sobre todo saber en qué punto del sistema se
encuentra y hacia donde puede ir. Sin un Mapa de Navegación no se podría
aprovechar al máximo un sistema. Cabe destacar que existirá solamente uno de estos
artefactos en el sistema.
Relaciones del Artefacto Mapa de NavegaciónRol Responsable: Arquitecto de Software
Disciplina: Análisis y Diseño
Artefacto Contenedor: No aplica
Artefacto(s) Contenido(s): No aplica
Plantilla: No posee
Marco de Desarrollo
El Marco de Desarrollo no es más que una configuración para amoldarse a las
necesidades del sistema. Su objetivo fundamental consiste en proveer ayuda y soporte
a los miembros del proyecto de desarrollo de software. Este artefacto establece cómo
cada objetivo específico propuesto debe irse cumpliendo, y cuáles van a ser las
normativas para el proyecto.
Este artefacto también es conocido como el proceso específico del proyecto, y
no es más que un artefacto que permite ajustar la configuración de la metodología
para el desarrollo de software a las necesidades del proyecto que se quiera desarrollar.
Es un artefacto compuesto que contiene: el caso de desarrollo, plantillas y normativas
para el proyecto.
107
MeRinde Guía Detallada
Como se ha especificado con anterioridad, conforme al proyecto se deben
definir cuáles son los elementos a emplear de la presente metodología, este artefacto
fue diseñado precisamente con la idea de ofrecer los mecanismos para poder
organizar los aspectos metodológicos a considerar para el ciclo de vida del proceso de
desarrollo del sistema.
Relaciones del Artefacto Marco de DesarrolloRol Responsable: Involucrados
Disciplina: Gestión del Ambiente
Artefacto Contenedor: No aplica
Artefacto(s) Contenido(s): Lineamientos del Proyecto
Plantilla: Si posee
Material de Adiestramiento
El propósito del Material de Adiestramiento, dependiendo de los
requerimientos del proyecto, es enseñar a los usuarios cómo utilizar, operar o
mantener el producto. Este material se piensa para el uso en cursos de aprendizaje.
Relaciones del Artefacto Material de AdiestramientoRol Responsable: Involucrados
Disciplina: Implantación
Artefacto Contenedor: No aplica
Artefacto(s) Contenido(s): No aplica
Plantilla: No posee
Mecanismo de Retroalimentación
Este artefacto provee un mecanismo para captar los comentarios de los
clientes al probar el producto beta, tiene como fin de que los usuarios hagan pruebas
al sistema sobre el conjunto de características disponibles y en lo posible,
108
MeRinde Guía Detallada
retroalimentar a sus desarrolladores con el descubrimiento de fallos y haciendo
sugerencias en cuanto a la funcionalidad, etc.
Relaciones del Artefacto Mecanismo de RetroalimentaciónRol Responsable: Involucrados
Disciplina: Implantación
Artefacto Contenedor: No aplica
Artefacto(s) Contenido(s): No aplica
Plantilla: No posee
Modelo de Análisis
Este modelo es usado para representar la estructura global del sistema,
describe la realización de casos de uso, sirve como una abstracción del Modelo de
Diseño y se centra en los requerimientos no funcionales.
Este modelo de análisis no es un diagrama final que describe todos los
posibles conceptos y sus relaciones, es un primer intento por definir los conceptos
claves que describen el sistema. Este artefacto es opcional, pero también tiene a su
vez la propiedad de ser temporal en el caso en que se planea su desarrollo. Su utilidad
radica en que permite una apreciación global conceptual del sistema.
El Modelo de Análisis puede contener: las clases y paquetes de análisis, las
realizaciones de los casos de uso, las relaciones y los diagramas.
Es opcional detallar aquí las realizaciones de los casos de uso ya que estas
pueden estar en el modelo de diseño donde se recomienda que se encuentre.
A diferencia del Modelo de Casos de Uso que captura la funcionalidad del
sistema, el Modelo de Análisis da forma a la arquitectura para soportar las
funcionalidades que en el anterior modelo se expresa.
109
MeRinde Guía Detallada
Para representar los diagramas del Modelo de Análisis se pueden emplear
diferentes diagramas de UML tales como:
• Diagramas de Clase.
• Diagramas de Secuencia
Relaciones del Artefacto Modelo de AnálisisRol Responsable: Arquitecto de Software
Disciplina: Análisis y Diseño
Artefacto Contenedor: No aplica
Artefacto(s) Contenido(s): No aplica
Plantilla: No posee
Modelo de Análisis del Negocio
Este modelo es interno al negocio, describe la realización de los casos de uso
del negocio, para lo cual detalla cómo cada caso de uso de negocio es llevado a cabo
por un grupo de trabajadores u sistemas que emplean entidades del negocio y
unidades de trabajo recíprocamente.
A diferencia del Modelo de Casos de Uso del Negocio el cual describe qué
pasa entre el negocio y los actores de negocio, el Modelo de Análisis define los
trabajadores internos de negocio y la información que ellos emplean (entidades de
negocio). Describe su organización estructural en unidades independientes (sistema
de negocio) y precisa cómo ellos interactúan para ejecutar el comportamiento
señalado en los casos de uso de negocio.
El Modelo de Análisis del Negocio puede contener: los diagramas,
trabajadores, sistemas, entidades, reglas, las relaciones, colaboraciones, entre otros
elementos del negocio.
110
MeRinde Guía Detallada
Para representar los diagramas del Modelo de Análisis del Negocio se pueden
emplear diferentes diagramas de UML tales como:
• Diagramas de Colaboración.
• Diagramas de Secuencia.
• Diagrama de Análisis del Negocio.
• Diagramas de Actividad.
• Diagramas de Estado.
Relaciones del Artefacto Modelo de Análisis del NegocioRol Responsable: Involucrados
Disciplina: Modelado del Negocio
Artefacto Contenedor: No aplica
Artefacto(s) Contenido(s): • Entidad del Negocio• Reglas del Negocio
• Trabajador del Negocio
Plantilla: No posee
Modelo de Casos de Uso
Este artefacto se basa en la descripción de elementos o usuarios externos al
sistema (actores) y de la funcionalidad del sistema (casos de uso). Un Modelo de
Casos de Uso describe los requerimientos funcionales de un actor (usuario, sistema,
dispositivo, etc.) en términos de las interacciones que éste ejecuta con el sistema. El
modelado de casos de uso es una técnica efectiva y a la vez simple para modelar los
requerimientos del sistema desde la perspectiva del usuario. Presenta el sistema desde
la perspectiva de su uso y esquematiza como proporcionará valor a sus usuarios.
El modelo de casos de uso sirve como acuerdo entre clientes y desarrolladores
para limitar las funciones con que dispondrá el sistema luego de ser implementado,
111
MeRinde Guía Detallada
además proporciona la entrada fundamental para el análisis, el diseño, la
implementación y las pruebas. Cabe recordar que MeRinde está dirigido por casos de
uso, de aquí la importancia de este modelo.
Este modelo está formado por los diagramas de casos de uso y las narrativas
de los casos de uso. Para representar los diagramas del Modelo de Casos de Uso se
puede emplear el diagrama de UML de Caso de Uso.
Relaciones del Artefacto Modelo de Casos de UsoRol Responsable: Analista de Producto
Disciplina: Requerimientos
Artefacto Contenedor: Especificación de Requerimientos del Software (ERS)
Artefacto(s) Contenido(s): No aplica
Plantilla: No posee
Modelo de Casos de Uso del Negocio
Este modelo permite visualizar el alcance de la organización, representando lo
que abarca y cuáles son sus límites. Así mismo, modela las actividades y procesos
qué ejecuta una organización, señala gráficamente las funciones y metas que persigue
el negocio, y también permite identificar cuáles son los entregables y roles dentro de
la organización.
Muestra los casos de uso del negocio, trabajadores del negocio, actores del
negocio y las interacciones entre ellos relacionadas con los procesos del negocio que
se encuentran dentro de la organización y dentro del alcance del sistema que se está
planeando realizar. Este servirá para proveer los fundamentos para el artefacto
Modelo de Casos de Uso.
112
MeRinde Guía Detallada
Para representar los diagramas del Modelo de Casos de Uso se puede emplear
el diagrama de UML de estereotipo llamado <<Caso de Uso del Negocio>>.
Relaciones del Artefacto Modelo de Casos de Uso del NegocioRol Responsable: Involucrados
Disciplina: Modelado del Negocio
Artefacto Contenedor: No aplica
Artefacto(s) Contenido(s): No aplica
Plantilla: No posee
Modelo de Datos
Describe la representación física y lógica de los datos constantes utilizados
por la aplicación. Se utilizará siempre que se necesiten manejar datos constantes.
Usualmente describirá los diferentes elementos componentes de la estructura de una
base de datos relacional. El Modelo de Datos debe contener las interacciones entre los
componentes en los casos en que el sistema emplee un Sistema Administrador de
Bases de Datos Relacional.
El Modelo de Datos se emplea concretamente cuando la estructura de los
datos constante no puede ser derivada automáticamente ni mecánicamente de la
estructura persistente de clases en el Modelo de Diseño. Se usa para definir la
relación entre las constantes clases del diseño y las estructuras de datos, y para definir
las mismas estructuras de datos constantes.
113
MeRinde Guía Detallada
Relaciones del Artefacto Modelo de Modelo de DatosRol Responsable: Arquitecto de Software
Disciplina: Análisis y Diseño
Artefacto Contenedor: No aplica
Artefacto(s) Contenido(s): No aplica
Plantilla: No posee
Modelo de Diseño
Es una abstracción del Modelo de Implementación y su código fuente, el cual
fundamentalmente se emplea para representar y documentar su diseño. Es usado
como entrada esencial en las actividades relacionadas a implementación. Representa a
los casos de uso en el dominio de la solución.
El Modelo de Diseño puede contener: los diagramas, las clases, paquetes,