Professional Documents
Culture Documents
TABLA DE CONTENIDO
1. PROCESO DE SOFTWARE BAJO UN AMBIENTE DISTRIBUIDO..............................................................5 2. PROPUESTA: DESARROLLO EN COMUNIDAD DE UN ESMS-MI...........................................................85 3. CONCLUSIONES Y RECOMENDACIONES....................................................................................................87 BIBLIOGRAFA........................................................................................................................................................91
Versin 0.5 1 DE 95
TABLA 1: DESAFOS DE AGILE-DISOP................................................................................................................6 TABLA 2: REQUISITOS DE AGILE-DISOP............................................................................................................7 TABLA 3: RESUMEN CONFIGURACIONES DE EQUIPO Y SUS CARACTERSTICAS............................30 TABLA 4: ACTIVIDADES DE LA GESTIN DEL ENTORNO..........................................................................36 TABLA 5: ARTEFACTOS DE LA DISCIPLINA GESTIN DEL ENTORNO..................................................36 TABLA 6: ACTIVIDADES DEL FLUJO DE GESTIN DE LA COMUNIDAD...............................................41 TABLA 7: ACTIVIDADES DEL FLUJO DE GESTIN A NIVEL DE MACRO-PROYECTO.......................47 TABLA 8: ACTIVIDADES DEL FLUJO DE GESTIN A NIVEL DE SUB-PROYECTO..............................49 TABLA 9: ARTEFACTOS DE LA DISCIPLINA GESTIN DEL PROYECTO...............................................50 TABLA 10: ACTIVIDADES DEL FLUJO DE DESARROLLO DURANTE EL ANLISIS.............................57 TABLA 11: ACTIVIDADES DEL FLUJO DE DESARROLLO DURANTE EL DISEO................................58 TABLA 12: ACTIVIDADES DEL FLUJO DE DESARROLLO DURANTE LA IMPLEMENTACIN.........59 TABLA 13: ACTIVIDADES DEL FLUJO DE DESARROLLO DURANTE LAS PRUEBAS..........................60 TABLA 14: ARTEFACTOS DE LA DISCIPLINA DESARROLLO....................................................................61 TABLA 15: ACTIVIDADES DEL NIVEL DE PROCESO PARA EL MODELO DE MEJORA......................64 TABLA 16: ACTIVIDADES DEL NIVEL DEL PROYECTO PARA EL MODELO DE MEJORA................65 TABLA 17: ARTEFACTOS DE LA DISCIPLINA MEJORAMIENTO DEL PROCESO.................................65 TABLA 18: ACTIVIDADES DE LA GESTIN DEL CAMBIO...........................................................................69 TABLA 19: ARTEFACTOS DE LA DISCIPLINA GESTIN DEL PROYECTO.............................................69
Versin 0.5 2 DE 95
FIGURA 1: ORGANIZACIN DE LA DOCUMENTACIN POR DISCIPLINAS...........................................12 FIGURA 2: ORGANIZACIN DE LA DOCUMENTACIN POR FASES........................................................12 FIGURA 3: VISIN GENERAL DE AGILE-DISOP.............................................................................................14 FIGURA 4: VISIN DETALLADA DEL AGILE-DISOP.....................................................................................17 FIGURA 5: ESTIMACIN DEL ESFUERZO Y DURACIN DE LAS FASES.................................................22 FIGURA 6: ESTRUCTURA ORGANIZACIONAL DEL EQUIPO DE NEGOCIOS.........................................24 FIGURA 7: ESTRUCTURA ORGANIZACIONAL DEL EQUIPO CON PROGRAMADOR JEFE...............25 FIGURA 8: ESTRUCTURA ORGANIZACIONAL DEL EQUIPO EN LA SOMBRA......................................26 FIGURA 9: ESTRUCTURA ORGANIZACIONAL DEL EQUIPO DE PRESTACIONES...............................27 FIGURA 10: ESTRUCTURA ORGANIZACIONAL DEL EQUIPO DE BSQUEDA Y RESCATE..............27 FIGURA 11: ESTRUCTURA ORGANIZACIONAL DEL EQUIPO SWAT.......................................................28 FIGURA 12: ESTRUCTURA ORGANIZACIONAL DEL EQUIPO DE ESPECIALISTAS.............................29 FIGURA 13: ESTRUCTURA ORGANIZACIONAL DEL EQUIPO DE TEATRO...........................................30 FIGURA 14: VAS DE COMUNICACIN EN PROYECTOS DE DISTINTOS TAMAOS...........................31 FIGURA 15: ORGANIZACIN DE LOS EQUIPOS EN LA COMUNIDAD DE DESARROLLO..................32 FIGURA 16: FLUJO DE TRABAJO PARA LA GESTIN DEL ENTORNO....................................................34 FIGURA 17: ARQUITECTURA DE LA GESTIN DEL ENTORNO.................................................................37 FIGURA 18: FLUJO DE TRABAJO DE LA GESTIN DE LA COMUNIDAD................................................39 FIGURA 19: FORMULARIO DE REGISTRO PARA NUEVOS USUARIOS....................................................42 FIGURA 20: ARQUITECTURA DE LA GESTIN DE LA COMUNIDAD.......................................................43 FIGURA 21: FLUJO DE TRABAJO PARA LA GESTIN DEL MACRO-PROYECTO.................................45 FIGURA 22: FLUJO DE TRABAJO PARA EL MODELO DE GESTIN EN UN SUB-PROYECTO...........46 FIGURA 23: ARQUITECTURA DEL SUB-MODELO DE PLANIFICACIN..................................................51 FIGURA 24: ARQUITECTURA DEL SUB-MODELO "MONITOREO, CONTROL Y RIESGOS"..............52 FIGURA 25: FLUJO DE TRABAJO PARA LA DISCIPLINA DE DESARROLLO..........................................55
Versin 0.5 3 DE 95
Versin 0.5 4 DE 95
DESAFO
CUESTIONES IMPORTANTES A RESOLVER a. b. c. Cmo se relacionan las personas con otras a travs de las TIC? Cmo reaccionan las personas presencial y/o virtualmente? Cmo interpretan las personas las reacciones en otras?
Comunicacin
Versin 0.5 5 DE 95
Coordinacin
b. a. b. c.
Gestin
d.
e. a. b. c. d.
Formalizacin
AREA
REQUISITOS a. b. c. Debe ser efectivo y eficaz favoreciendo tiempos de desarrollo ms cortos, buen retorno a la inversin y finalmente la calidad del producto final. Su adopcin debe ser incremental. Al principio con poco esfuerzo y progresivamente extendindose hasta su implementacin completa. Debe proveer resultados rpidos y tangibles con el objeto de que su uso y adopcin continua se justifique. Debe adecuar y armonizar principios, prcticas, mtodos y herramientas de demostrada eficacia. Debe proveer mecanismos para el mejoramiento continuo.
1. General
d.
e.
a. 2. Comunicacin b.
Debe concebir actividades peridicas y presenciales de todo el equipo de desarrollo. Debe concebir actividades peridicas y virtuales de todo el equipo de
Versin 0.5 6 DE 95
El software seleccionado como plataforma debe: a. b. c. d. e. 4. Infraestructura o o o o o o o Agendas personales, grupales y globales. Asignacin de tareas personales, grupales y globales Organizacin de contactos y reuniones. Mensajera a travs de e-mail, Chat y mensajes instantneos o SMS. Registro del esfuerzo personal y presentacin de resultados consolidados por grupos y por toda la comunidad. Organizacin de los miembros del equipo en perfiles con diversidad de derechos de acceso. Organizacin, publicacin y descarga de archivos. Ser de fcil uso, interoperable con otras herramientas y portable a varias plataformas. Permitir la planificacin de proyectos, asignacin de recursos, presupuesto, tiempo y personal a tareas. Permitir el intercambio electrnico de informacin a travs de todos los equipos dispersos geogrficamente. Estar disponible, abierto y sin costo para todos los miembros del equipo geogrficamente disperso. Se recomienda Internet. Estar en capacidad de reflejar una estructura organizacional de Macroproyectos y sub-proyectos que incluya:
a. b. c. 5. Gestin d. e.
o Control de versiones en archivos y cdigo fuente. Debe sugerir mecanismos eficaces para medir y/o controlar el avance del proyecto y su presupuesto. Debe sugerir mecanismos que implementan eficazmente la gestin de los riesgos del proyecto y sub-proyectos. Debe garantizar eficazmente la asignacin y evaluacin de tareas y sus resultados. Debe sugerir patrones para el liderazgo efectivo an con miembros del equipo remotos. Debe sugerir patrones para establecer vnculos personales de confianza con miembros del equipo remotos. Debe sugerir estrategias para establecer un clima de pertenencia, confianza y solidaridad dentro de la comunidad de desarrollo. Debe unificar un estilo de desarrollo para toda la comunidad. Debe unificar el modelo de documentacin para toda la comunidad. Debe unificar las herramientas de soporte y su entorno garantizando su disponibilidad, libre acceso y bajo costo para toda la comunidad. Llenar los vacos dejados por las metodologas de desarrollo horizontales, las cules especifican como debe dirigirse el desarrollo de software de forma transversal indicando a veces lo QUE debe hacerse y omitiendo el COMO debe hacerse. Tabla 2: Requisitos de Agile-DISOP
f. a. b. c. 6. Formalizacin d.
Versin 0.5 7 DE 95
Es decir en el contexto de la comunidad de dinmica de sistemas y pensamiento sistmico que agrega a varias universidades publicas del territorio nacional.
Versin 0.5 8 DE 95
No siempre son obvios y pueden provenir de diversas fuentes. No siempre estn claramente expresados. Tenga en cuenta de que no importa que tan cuidadosamente se han definido los requerimientos, estos siempre cambiarn, causando un impacto no solo en las caractersticas del sistema que los implementan, sino tambin en las caractersticas del sistema relativas a requerimientos relacionados.
Los requerimientos pueden estar organizados en diversas categoras y niveles. No necesariamente todos tienen la misma importancia. Lo usual es que se relacionen entre si y tambin con otros sub-productos (artefactos) del proyecto. Finalmente tenga en cuenta de que el nmero de requerimientos puede volverse inmanejable si no se controla.
1.4.5. Promueva una arquitectura basada en Componentes El desarrollo basado en componentes es una variacin del desarrollo tradicional de aplicaciones de software. Este tipo de
desarrollo es ms adecuado para particionar los esfuerzos de programacin sin conflictos bajo ambientes de dispersin geogrfica. Con este enfoque, la aplicacin se construye mediante la implementacin de componentes ejecutables desarrollados de forma independiente por equipos distintos. Estos componentes deben conformarse a interfaces bien definidas y consensuadas en comunidad. No olvide el uso de patrones de diseo para concebir un diseo elegante, sencillo y funcional. De otra parte, incremente su aplicacin mediante la actualizacin y/o mejora de algunos de sus componentes. Considere la posibilidad de compartir componentes entre aplicaciones creando oportunidades para la reutilizacin, pero tenga en cuenta la generacin de interdependencias entre proyectos. Usando un estilo de desarrollo como el sugerido en el numeral 1.4.3, identifique que componentes debera desarrollar (secuencial o concurrentemente), reutilizar o comprar. Considere distintos grados de granularidad para sus pruebas, utilice pruebas de unidad para componentes individuales, pruebas de integracin para el componente versus su entorno y pruebas globales para el sistema versus todos los componentes recin actualizados o integrados. 1.4.6. Promueva el modelado visual del sistema Fomente una conciencia comunitaria que sea positiva respecto al modelamiento visual del sistema. Promueva una sensibilizacin respecto a las ventajas derivadas de esta prctica las cules son:
Mejora sobre el entendimiento de sistemas complejos. Fomente la construccin de modelos para que todos los codesarrolladores de la comunidad se mantengan enfocados en los aspectos esenciales de la arquitectura del sistema (componentes y sus interacciones). El modelado ayudar a la comunidad a visualizar, construir y documentar la arquitectura y comportamiento del sistema al mismo tiempo que se maneja la complejidad.
Exploracin y evaluacin de alternativas de diseo a bajo costo. Convenza a su comunidad de utilizar la creacin y/o modificacin de modelos como una alternativa de exploracin de bajo costo para el diseo. Aquellas ideas innovadoras pueden capturarse y revisarse por co-desarrolladores antes de invertir tiempo, dinero y esfuerzo en desarrollar cdigo.
Versin 0.5 9 DE 95
Implementacin sin improvisacin. Promueva el uso efectivo de las herramientas CASE disponibles como un soporte para la transformacin de modelos del diseo en cdigo de base para la implementacin, esto se conoce mejor como "forward engineering" o "generacin de cdigo". La ingeniera inversa o reverse engineering puede ser aplicada para generar modelos de diseo a partir de cdigo existente, pudiendo ser til para la evaluacin. Tambin puede usar "Round trip engineering" o Ingeniera de Viaje Redondo la cual combina generacin de cdigo e ingeniera inversa para asegurar la consistencia y sincronizacin entre el diseo y el cdigo.
Captura precisa de requerimientos. Tenga en cuenta que los requerimientos expresados en forma precisa y noambigua ayudarn ms efectivamente a todos los interesados en el proyecto, a entender el problema y ponerse de acuerdo sobre su propsito. La expresin clara de los requerimientos separa el comportamiento externo del sistema de los detalles de su implementacin, ayudando a concentrarse ms en el propsito mismo del sistema que en problemas de programacin.
Comunicacin de aspectos clave del diseo sin ambigedad. Unifique el uso de un lenguaje de modelamiento (Ej.: UML), el cul le permitir comunicar sin ambigedades las decisiones de diseo que no son obvias y que no pueden inferirse a partir del cdigo. Adems su utilizacin le permitir el uso de una semntica rica y suficiente para capturar todas las decisiones tcticas y estratgicas. Brinde a los miembros de su comunidad la posibilidad de razonar sobre la arquitectura del sistema, superando las barreras del lenguaje y promueva el uso de herramientas CASE capaces de interpretar y traducir a cdigo los modelos UML.
1.4.7. Verifique calidad constantemente aprovechando la comunidad Promueva un espritu comunitario en la verificacin constante y creciente de la calidad. Evale en comunidad la calidad de todos los artefactos y las actividades que los producen al final de cada iteracin. Cree diversos escenarios de demostracin y prueba para el cdigo ejecutable y publique los resultados a toda la comunidad para exponerlos a debate, as, ms gilmente se negociarn acuerdos sobre los requerimientos y el diseo del sistema. Aproveche la sinergia de la comunidad para resolver problemas. Muchas cabezas sobre un problema determinado encontrarn una solucin ms rpidamente. As mismo, promueva un espritu de calidad comunal, cuyo origen es el co-desarrollador mismo, el cul mediante su aporte comprometido y desinteresado, propaga los beneficios derivados de la elaboracin de sus artefactos y actividades hacia toda la comunidad. Defina un conjunto coherente y prctico de mtricas para valorar la calidad tanto del proceso como del producto, y utilcelo en el marco de un modelo de mejoramiento para el proceso de desarrollo o SPI por ejemplo IMPACT, descrito en el numeral Error: Reference source not found. 1.4.8. Promueva la Gestin del Cambio en Comunidad Una caracterstica importante del desarrollo en comunidad consiste en disponer de una gran cantidad de desarrolladores organizados en mltiples equipos dispersos geogrficamente, todos trabajando juntos en mltiples iteraciones, versiones del producto software y herramientas de desarrollo o soporte, pero sobre una plataforma que permite su integracin como comunidad. En estas condiciones sin un mecanismo de monitoreo y control, el proceso de desarrollo puede degenerar rpidamente en un caos. Cree mecanismos que permitan implementar informaticamente la trazabilidad entre todos los artefactos en cualquier iteracin (para cualquier sub-proyecto), de tal forma que todo cambio en un artefacto debera propagarse a travs de todos sus artefactos relacionados. As mismo, emplee un sistema de control de versiones para el cdigo desarrollado por la comunidad (se recomienda CVS) e intgrelo a su plataforma de gestin de proyecto en comunidad.
Versin 0.5 10 DE 95
Reflexin. Aqu, yace una diferencia esencial entre dos estilos. En el enfoque usado para desarrollar software propietario, los errores y problemas de desarrollo son fenmenos complejos y profundos. Generalmente toma meses de revisin exhaustiva para que unos cuantos alcancen la seguridad de que los errores han sido eliminados del todo. Por eso se dan los intervalos tan largos entre cada versin que se libera y la inevitable desmoralizacin cuando estas versiones, largamente esperadas, no resultan perfectas. En el enfoque usado para desarrollar software abierto y en comunidad, se asume que los errores son fenmenos relativamente evidentes, cuando se exhiben a miles de entusiastas desarrolladores que colaboran sobre cada una de las versiones. Por lo tanto, se libera con frecuencia para poder obtener una mayor cantidad de correcciones en menos tiempo. Una mayor cantidad de usuarios detecta ms errores debido a que tienen diferentes maneras de evaluar el programa. Este efecto se incrementa cuando los usuarios son desarrolladores asistentes. Cada uno enfoca la tarea de la caracterizacin de los errores con instrumentos analticos distintos, desde un ngulo diferente.
Promueva un espritu de tratar a los colaboradores como si fueran el recurso ms valioso, as pues, ellos respondern convirtindose en el recurso ms valioso. Un coordinador o lder de proyecto debe tener una excelente capacidad de comunicacin. Para poder construir una comunidad de desarrollo se necesita atraer gente, interesarla en lo que se est haciendo y mantenerla contenta con el trabajo que se est desarrollando. El entusiasmo tcnico constituye una buena parte para poder lograr esto, pero est muy lejos de ser definitivo. Adems, es importante la personalidad que se proyecta. Por tanto, lo ms importante, despus de tener buenas ideas, es reconocer las buenas ideas de los usuarios. Esto ltimo es a veces mejor. En consecuencia, no es crtico que el coordinador del proyecto sea capaz de originar diseos de calidad excepcional, pero lo que s es absolutamente esencial es que sea capaz de reconocer las buenas ideas de diseo de los dems. Antine de Saint-Exupery afirma que "La perfeccin (en el diseo) se alcanza no cuando ya no hay nada que agregar, sino cuando ya no hay nada que sacar." As, cuando el cdigo va
2
Versin 0.5 11 DE 95
Versin 0.5 12 DE 95
Fijar la duracin de las iteraciones con fechas de finalizacin difusas o distantes. Parkinson (1958) observo con decepcin que: el trabajo se expande de manera que rellena el tiempo disponible para su finalizacin. Cerca del comienzo del proyecto parece ser que existe suficiente tiempo para proceder sin prisa, sin embargo, este efecto se agrava an ms si algunos compromisos tienen fechas de finalizacin difusas o distantes. Este tipo de planificacin, no motivar al equipo de desarrollo a tomar partido y moverse rpido, en cambio, con iteraciones ms cortas y definidas, los equipos de desarrollo tendrn una permanente sensacin de competencia y entrega al final de cada iteracin, creando un clima psicolgico de eficacia y confianza en el equipo y por supuesto esta confianza es propagada a los clientes. Este aspecto se relaciona mucho con las estructuras de equipo que participan en proyectos de ejecucin tctica, vase el numeral 1.8.1. para ms detalles.
Todas las iteraciones se planifican en detalle. Es una tendencia muy generalizada (legado del proceso en cascada), pretender una planificacin exhaustiva y especulativa de cada iteracin desde el inicio hasta el final del proyecto, indicando para cada iteracin: recursos, tiempo, esfuerzo y presupuesto. Lo cierto es que las estimaciones realizadas durante el inicio del proyecto son poco fiables y slo constituyen una gua sobre si vale la pena realizar una estimacin ms profunda luego. Es recomendable realizar un poco de trabajo realista antes de generar estimaciones. Aparentemente esta en contradiccin respecto al anterior prrafo, sin embargo este y el anterior constituyen los dos extremos del espectro de la planificacin.
Adopcin instantnea del proceso. Una tendencia muy generalizada y que a menudo genera malestar entre los desarrolladores consiste en querer implantar el proceso completo (con todo el conocimiento y habilidad que ello implica) de un da para otro, desconociendo el nivel de experiencia de los equipos que conforman la comunidad de desarrollo, esta prctica impacta de forma negativa en la confianza y entusiasmo del equipo, en el sentido en que se asume el proceso como algo complicado, imprctico y en ocasiones hasta intil. Es importante tener en cuenta que un equipo para el que son nuevas muchas de las prcticas y tecnologas, naturalmente ir ms despacio y necesitar ms tiempo para comprender el proceso. Por ejemplo: el equipo asumir un conjunto de prcticas del proceso y en la medida que las domine, podr ir incorporando ms.
Con el propsito de facilitar la comprensin y lectura del presente numeral y segn lo recomendado por (McConell 1997) se ha dispuesto en el Error: Reference source not found un inventario de malas prcticas y errores clsicos adicionales que se relacionan con la planificacin y desarrollo de proyectos informticos. En el mismo sentido, y para conformar Agile-DISOP, se contemplaron y contextualizaron (en el marco de una comunidad de desarrollo) malas prcticas en reas crticas tales como: Personas, Proceso, Producto y Tecnologa. Finalmente, debe asumirse que todo lo que sea contrario a las buenas prcticas (ver numeral 1.4) es considerado como mala prctica aunque no est contemplada en la tabulacin del Error: Reference source not found.
Versin 0.5 13 DE 95
Figura 3: Visin General de Agile-DISOP Mientras que las disciplinas transversales, favorecen la percepcin de unidad en la comunidad, las verticales fomentan la percepcin de totalidad sobre los sub-proyectos distribuidos en un solo Macro-Proyecto. As mismo, cada disciplina estar soportada por servicios informticos disponibles en la plataforma de integracin seleccionada (vase el numeral 1.15) para dar
Versin 0.5 14 DE 95
Conceptos. Consiste en la definicin de trminos especficos contemplados por Agile-DISOP, la cul es imprescindible para la correcta comprensin de los procedimientos propuestos y la adopcin incremental del Agile-DISOP. Con el objeto de facilitar la lectura del documento concentrndose en los elementos esenciales, todos los trminos implicados en la metodologa Agile-DISOP, han sido colocados en el Error: Reference source not found.
Flujo de Trabajo. Segn RUP (2003), la sola enumeracin de todos los roles, actividades y artefactos no constituye un proceso. Se requiere una forma de describir una secuencia de actividades que sea significativa, produciendo un resultado tangible y mostrando las interacciones entre los roles. En trminos de UML, un flujo de trabajo se puede expresar en trminos de un diagrama de secuencia, de colaboracin o de actividad. En este documento se utilizar la forma de un diagrama de actividad para describir el flujo de trabajo de cada disciplina.
Actividades. Segn RUP (2003), una actividad es algo que un rol ejecuta para proveer un resultado significativo en el contexto del proyecto. La actividad es considerada como una unidad de trabajo que se utiliza como punto de partida para planear y determinar el progreso del proyecto. Una actividad tiene un propsito bien definido, el cul, se asocia frecuentemente a la creacin o actualizacin de algunos artefactos. La granularidad de una actividad corresponde a unas pocas horas o das y usualmente involucra a un nico rol. En consecuencia, este descriptor tiene como propsito, especificar el objeto, entradas, salidas y responsable de cada actividad presente en el flujo de trabajo, mediante una tabla.
Artefactos. Este descriptor tiene como propsito, especificar los artefactos que se utilizan y generan dentro de las actividades de la disciplina. Segn RUP (2003), un artefacto consiste en un producto del proceso. Los roles utilizan a los artefactos para ejecutar las actividades y a su vez producen nuevos artefactos en el curso de su ejecucin. En consecuencia, las actividades tienen artefactos de entrada y de salida. Cada artefacto es responsabilidad de un nico rol, de esta forma es fcil identificar, entender y promover la idea de que cada pieza de informacin producida en el proceso, requiere un conjunto especfico de habilidades. En ocasiones aunque un rol posee la responsabilidad sobre un artefacto, otros roles pueden usarlo y hasta actualizarlo si tienen la autorizacin para hacerlo. Los artefactos pueden ser:
1.
Un modelo. Por ejemplo, un modelo de casos de uso o un modelo de clases del diseo, el cul a su vez puede contener a otros artefactos.
2. 3. 4.
Un elemento contenido en un modelo. Por ejemplo, un caso de uso o una clase del diseo.
Un elemento de la implementacin. Por ejemplo, una Base de datos, el cdigo fuente o ejecutable.
Los documentos. Por ejemplo, una especificacin de caso de uso, o un plan de proyecto. Se proveer el estndar en un anexo cuando el artefacto corresponda a un documento.
Versin 0.5 15 DE 95
Premisas. Describe las condiciones y normas de comportamiento que son aceptables en la comunidad de desarrollo durante la ejecucin de las actividades de la disciplina. No es aplicable a todas las disciplinas, en este caso no aparecer el numeral correspondiente en la descripcin de la disciplina.
Mtricas. Sugiere algunas mtricas aplicables dentro de la disciplina, bien sea para elaborar los artefactos o valorar su calidad. No es aplicable a todas las disciplinas, en este caso no aparecer el numeral correspondiente en la descripcin de la disciplina.
Mtodos. Enuncia los mtodos especficos para la elaboracin de los artefactos de la disciplina. No es aplicable a todas las disciplinas, en este caso no aparecer el numeral correspondiente en la descripcin de la disciplina.
1.7. ORGANIZACION DEL PROCESO En la , se puede observar ms concretamente los elementos internos del Agile-DISOP desde dos perspectivas. En primer lugar, el eje horizontal representa el tiempo e ilustra el aspecto dinmico de la metodologa expresado en trminos de fases, iteraciones e hitos. En segundo lugar, el eje vertical, representa el aspecto esttico expresado en trminos de las disciplinas (compuestas por sus flujos de trabajo, artefactos y roles) y su correspondiente nivel de nfasis (medido en unidades de esfuerzo3) el cul est representado por las curvas de rea que varan segn su interseccin con cada fase. Las disciplinas de mejoramiento del proceso y gestin de la comunicacin tienen un nfasis que no es representable por las curvas de rea, puesto que se encuentran en un nivel superior al del producto de software. Se hace nfasis en que Agile-DISOP, se inspira en el proceso unificado de desarrollo, enriquecido con algunas prcticas y recomendaciones de las metodologas de desarrollo de software libre.
Versin 0.5 16 DE 95
Figura 4: Visin Detallada del Agile-DISOP A continuacin se detalla brevemente la organizacin del proceso en trminos de las disciplinas, fases y roles (organizados en equipos). 1.7.1. Disciplinas del Agile-DISOP En este numeral, se describen brevemente las disciplinas contempladas por Agile-DISOP en la misma secuencia que se muestra en la Figura 3 y :
1.
Gestin del Entorno. Su propsito consiste en fortalecer la adecuacin, puesta en marcha y mantenimiento tanto del proceso mismo Agile-DISOP como de la plataforma de integracin para la comunidad de desarrollo seleccionada. El numeral 1.9 trata ms a fondo este elemento de Agile-DISOP.
2.
Gestin de la Comunidad. Su propsito consiste en soportar las necesidades de comunicacin, coordinacin y gestin de la disponibilidad para personas y equipos (i+d) bajo un ambiente de dispersin geogrfica que pertenecen a la comunidad de desarrollo. El numeral 1.10 trata ms a fondo este elemento de Agile-DISOP.
3.
Gestin del Proyecto. Su propsito consiste en proveer un marco metodolgico para la planificacin, monitoreo, control y gestin de riesgos en macro-proyectos y/o sub-proyectos informticos de la comunidad de desarrollo. El numeral 1.11 trata ms a fondo este elemento de Agile-DISOP.
4.
Proceso de Desarrollo. Su propsito consiste en proveer un marco metodolgico para la ejecucin de las disciplinas orientadas hacia la investigacin de requisitos-anlisis, diseo, implementacin y pruebas para el desarrollo software. El numeral 1.12 trata ms a fondo este elemento de Agile-DISOP.
Versin 0.5 17 DE 95
6.
Gestin del Cambio. Su propsito consiste en proveer mecanismos que soportados informaticamente permitan controlar los cambios en los artefactos producidos por la comunidad de desarrollo. El control sobre la documentacin, ayudar a la comunidad a evitar la confusin, asegurando que los artefactos resultantes no tengan conflictos entre s, debido a las actualizaciones simultneas y las numerosas versiones que puede manejar la comunidad de desarrollo en un momento determinado. El numeral 1.13.1 trata ms a fondo este elemento de Agile-DISOP.
1.7.2. Fases del Agile-DISOP Las fases en Agile-DISOP se entienden como los momentos que vive el software a travs de su maduracin desde una idea hasta un producto terminado durante el ciclo de vida de desarrollo. Segn RUP (2003) se proponen 4 de estas fases: Inicio, Elaboracin, Construccin y Transicin. Cada fase una tiene un propsito y unos hitos que determinan cuando la fase termina, dando paso a la siguiente. Agile-Disop, retoma el espritu de estas fases de RUP las cules se describen brevemente a continuacin: 1.7.2.1. Fase de Inicio Su objetivo fundamental consiste en alcanzar la estabilidad de los objetivos del sistema mediante el consenso general de toda la comunidad de desarrollo. Durante esta fase, la comunidad de desarrollo debe ponerse de acuerdo en cuestiones relativas a los alcances, riesgos, requerimientos y objetivos del sistema con el propsito de comprobar la viabilidad del proyecto teniendo en cuenta las condiciones del entorno de desarrollo. Durante esta fase es preciso determinar lo siguiente:
El alcance del proyecto. Determina las caractersticas que estarn en el producto y las que no, mediante la captura de los requerimientos ms importantes y las restricciones del sistema.
Proponer una arquitectura candidata. Los casos que son crticos desde el punto de vista de la arquitectura, ayudarn a seleccionar un estilo arquitectnico. De otro lado, la valoracin de que componentes se van a desarrollar, reutilizar o comprar ayudar a la estimacin de los costos y recursos para el proyecto. Se sugiere el desarrollo de un prototipo rpido que ayude a la estimacin de la viabilidad del proyecto mismo.
Estimar en trminos generales el costo, cronograma y riesgos. Para el proyecto entero haciendo ms nfasis en la fase de Elaboracin que sigue.
Preparar el entorno para soportar la ejecucin del proyecto en comunidad. Valorando y ajustando el proyecto Vs. la comunidad, se seleccionan las herramientas y se decide que partes del proceso se van a adoptar.
Hito de la Fase de Inicio. La estabilizacin de los objetivos y alcances del proyecto determinan la finalizacin de la fase de inicio, en este punto la viabilidad del proyecto es clara y puede decidirse si es favorable continuar aceptando el riesgo o por el contrario lo mejor es cancelar el proyecto entero. Los criterios para determinar si se ha llegado hasta este punto son:
Consenso general del equipo promotor y la comunidad de desarrollo. Sobre el alcance, costo y cronograma para el proyecto as como el esclarecimiento y entendimiento compartidos de un conjunto correcto de requerimientos para el
Versin 0.5 18 DE 95
Definir, validar y estabilizar una arquitectura de forma rpida y estable. Mediante el refinamiento continuo del conocimiento relacionado con el problema, se va conformando un conocimiento slido relacionado con los casos de uso ms crticos que dirigen las decisiones arquitectnicas y de planeacin.
Crear una base de planes detallados para las iteraciones durante la fase de construccin.
Configuracin y puesta en marcha del entorno de desarrollo. Incluye el proceso, las herramientas y la plataforma de integracin requeridos para soportar la comunidad de desarrollo.
arquitectura son evaluados e involucrados en decisiones de reutilizacin, desarrollo o compra con el propsito de estimar con ms confianza los costos y cronogramas de la siguiente fase de construccin. Los componentes seleccionados son integrados y evaluados contra los escenarios ms importantes. obtenidos pueden motivar un rediseo de la arquitectura. Hito de la Fase de Elaboracin. La estabilizacin del ciclo de vida de la arquitectura establece una base para que la comunidad de desarrollo pueda escalar sobre ella durante la siguiente fase de construccin al implementar los casos de uso que no son crticos arquitectnicamente hablando. En este punto, los objetivos y el alcance del sistema han sido examinados, un estilo arquitectnico se ha seleccionado y los riesgos de mayor impacto han sido resueltos. Los criterios para determinar si se ha llegado hasta este punto son: La interpretacin de los resultados de evaluacin
La visin del producto, sus requerimientos y su arquitectura se han estabilizado. Adems toda la comunidad infiere que la visin se alcanzar si el plan de proyecto se ejecuta implementando el producto en el contexto de la arquitectura base.
Versin 0.5 19 DE 95
Hito de la Fase de Construccin. La capacidad operacional inicial, consiste en la certeza de que el producto est listo para ser liberado pues ya se ha implementado toda la funcionalidad y al menos en parte esta ha sido probada. Por otra parte, al menos existe un manual de usuario sobre la versin actual que esta disponible. Los criterios que indican si se ha alcanzado el final de esta fase son: El producto es lo suficientemente maduro y estable como para distribuirlo a la comunidad de usuarios? Todos los interesados estn preparados para recibir la prxima fase de transicin. La diferencia entre el consumo real de los recursos es aceptable respecto del estimado.
Versin 0.5 20 DE 95
Hito de la Fase de Transicin. Al final de esta fase debe valorarse el estado de satisfaccin de los objetivos del sistema y si debe iniciarse un nuevo ciclo de desarrollo para una nueva versin de produccin del software, es posible que este hito coincida con el final de la fase de inicio para el prximo ciclo de desarrollo. Finalmente este hito es alcanzado cuando existe una revisin y aceptacin de la distribucin del producto por parte de los usuarios finales y los recursos-tiempo consumidos son aceptables respecto a lo planificado. En la Figura 5, se ilustra la distribucin sugerida (RUP 2003) del esfuerzo y el tiempo dedicados durante cada una de las fases anteriormente descritas.
Ejemplo: Pruebas beta del nuevo sistema contra las expectativas de los usuarios y operacin en paralelo con el sistema que ser reemplazado.
Versin 0.5 21 DE 95
Figura 5: Estimacin del Esfuerzo y Duracin de las Fases Una comunidad de desarrollo est compuesta en su esencia ms profunda e importante por las personas. En consecuencia, es preciso determinar la topologa de organizacin para la comunidad de desarrollo. En el siguiente apartado se proporciona una panormica que intenta visionar las configuraciones de equipo versus los tipos de proyectos posibles. Finalmente se tiene en cuenta las interacciones de comunicacin involucradas en una comunidad de desarrollo y se sugiere una estructura de equipo para la misma.
1.8. EQUIPO DE DESARROLLO EN COMUNIDAD Segn MacConnell (1997) un equipo se define como: un conjunto de personas pequeo con habilidades complementarias, que estn comprometidas en un propsito, objetivos de rendimiento y enfoque comunes en el que todos y cada uno de los miembros del equipo es responsable ante los dems. Un equipo existe siempre que dos o ms cabezas juntas funcionan mejor que por separado. En consecuencia, no todos los grupos de personas son equipos porque no tienen sinergia en ellos. La sinergia implica un compromiso profundo e incondicional de cada miembro del equipo que fomenta un alto sentido de identidad. Los miembros de un equipo verdadero, se caracterizan por que trabajan duro y unidos, se divierten con su trabajo y pasan gran parte del tiempo centrndose en los objetivos del proyecto. Al contrario, muchos falsos equipos, estn integrados por miembros desmoralizados y dispersos, que trabajan la mayor parte del tiempo en objetivos opuestos a los del proyecto. Lakhanpal (1993) descubri que la unin del grupo, contribua ms a la productividad que las capacidades o experiencias individuales de los miembros del proyecto. Sin embargo los directores de proyecto, escogen a los miembros del equipo basndose en el nivel de experiencia individual en lugar de validar su capacidad para conformar un equipo verdaderamente unido que crea sinergia con su trabajo. En conclusin un equipo
Versin 0.5 22 DE 95
Visin. Los miembros del equipo comparten una alta visin manifestando un fuerte sentido de identidad, al mismo tiempo, disfrutan y se enriquecen con su trabajo. Compromiso. Los miembros del equipo estn muy comprometidos y son competentes en sus responsabilidades particulares. Confianza. El equipo refleja una fluida interdependencia que est fundamentada sobre la confianza mutua y comunicacin efectiva de sus miembros. Resultados. El equipo se basa sobre una estructura dirigida por resultados, esta integrado por pocos miembros y posee una saludable autonoma para tomar decisiones importantes rpidamente.
En el siguiente numeral, se profundiza en la reflexin sobre la configuracin y estructura de los equipos que podran integrar a la comunidad. 1.8.1. Configuracin y Estructura de Equipos Determinar el objetivo del equipo es fundamental para configurar la estructura correcta del mismo. Segn Larson y LaFasto (1989) existen tres estructuras bsicas de equipo dependiendo del objetivo que persiguen y estas son:
Estructura de Equipo Centrado en la Resolucin de problemas. Se enfoca en la resolucin de un problema complejo y/o poco definido. Sus miembros, estn ocupados en una o ms cuestiones especficas. Sus miembros deben ser confiables, inteligentes y pragmticos. Ejemplo: Un grupo de programadores de mantenimiento intentando diagnosticar un nuevo defecto del software.
Estructura de Equipo centrado en la Creatividad. Este equipo explora nuevas posibilidades y alternativas para un producto de software. Sus miembros necesitan estar motivados, ser independientes, creativos y persistentes. La estructura del equipo necesita soportar la autonoma individual y colectiva de los miembros del equipo. Ejemplo: Un grupo de programadores que esta en proceso de concepcin de nuevas alternativas de interfaz grfica de usuario para una aplicaciones multimedia.
Equipo centrado en la Ejecucin Tctica. Este equipo se centra en ejecutar un plan bien definido el cul especifica tareas y funciones concretas. Sus miembros necesitan tener un sentido de la urgencia de su misin, estar ms interesados en la accin que en la intelectualizacin del problema. Para evaluar su desempeo, este tipo de equipo contara con factores crticos de xito claros. Ejemplo: Un equipo de software trabajando sobre una actualizacin bien definida de un producto, en la que el propsito de la actualizacin no es definir nuevas alternativas para el producto, sino poner caractersticas bien conocidas en manos de los usuarios tan pronto como sea posible.
A continuacin, se describen las configuraciones de equipo disponibles para las estructuras arriba mencionadas. 1.8.1.1. Equipo de Negocios. Constituido por un grupo de iguales encabezados por un jefe tcnico. Aparte del jefe tcnico todos los miembros del equipo tienen el mismo estatus, diferencindose en su mbito de experiencia: base de datos, grficos, interfaces de usuario y lenguajes de
Versin 0.5 23 DE 95
EQUIPO DE NEGOCIOS
J efe Tcn ico
Ex p ert o rea 1
Ex p erto rea 2
Ex pert o rea 3
Ex pert o rea 4
Figura 6: Estructura Organizacional del Equipo de Negocios 1.8.1.2. Equipo con Programador Jefe. El equipo con programador jefe saca partido del hecho de que algunos desarrolladores son ms productivos que otros. Las estructuras normales de equipo ponen al mismo nivel a programadores mediocres y a grandes estrellas. Se saca partido de la productividad de las grandes estrellas, pero se sufre la penalizacin de la baja productividad del resto de miembros del equipo. El programador jefe realiza la especificacin completa, hace todo el diseo, escribe la mayora del cdigo de produccin y es el responsable final de prcticamente todas las decisiones del proyecto. El resto de los miembros del equipo son libres para especializarse con el propsito de apoyar al programador jefe. Esta configuracin de equipo, saca partido del hecho de que los especialista tienden a rendir mejor que los generalistas (Jones, 1994). Sus roles principales son:
Programador de Reserva. Apoya al programador jefe como crtico, ayudante de la investigacin, contacto tcnico con grupos externos y por supuesto programador de reserva.
Administrador. Gestiona cuestiones administrativas, como el dinero, las personas, el espacio y los equipos. Aunque el programador jefe tiene la ltima palabra en estas cuestiones, el administrador le libera de tener que tratarlas de forma diaria.
Programador Herrero. Es el responsable de crear herramientas personalizadas solicitadas por el programador jefe. Estara a cargo de crear secuencias de rdenes y archivos ejecutables, de crear macros para su uso en el editor de programas y de ejecutar la construccin diaria.
Versin 0.5 24 DE 95
Adm inistrador
Figura 7: Estructura Organizacional del Equipo con Programador Jefe 1.8.1.3. Equipo en la sombra. Agrupa a un grupo talentoso de desarrolladores de productos creativos y les pone en una situacin en la que son liberados de las restricciones burocrticas habituales de la organizacin, otorgndoles libertad para desarrollar e innovar. Estos equipos son tratados como cajas negras por sus directivos. La directiva no quiere conocer los detalles sobre cmo realizan el trabajo, sino que slo quieren saber que lo estn haciendo. As, el equipo es libre de organizarse como mejor le parezca. Con el paso de tiempo, puede aparecer un lder natural, o el equipo podra designar a un lder desde el principio. Los proyectos en la sombra tienen la ventaja de crear una sensacin de intensa propiedad y compromiso por parte de los desarrolladores implicados. El efecto motivacional puede ser impresionante. Tienen la desventaja de no ofrecer mucha visibilidad del progreso del equipo, caracterstica inherente en los trabajos altamente creativos. De otra parte se sacrifica la visibilidad por rescatar la motivacin. Los equipos en la sombra resultan ms adecuados para proyectos exploratorios en los que la creatividad es absolutamente importante. Los equipos en la sombra son raramente la estructura ms rpida cuando se necesita resolver un problema claramente definido o cuando se necesita ejecutar un plan bien entendido. La Figura 8, ilustra la estructura organizacional de esta configuracin de equipo.
Versin 0.5 25 DE 95
?
Equipo en la Som bra
Productos
Figura 8: Estructura Organizacional del Equipo en la Sombra 1.8.1.4. Equipo de Prestaciones. En un equipo de prestaciones, el desarrollo, el control de calidad, la documentacin, la gestin del programa y el marketing estn organizados con las estructuras jerrquicas tradicionales de responsabilidad. La gente de marketing informa a los responsables de marketing, los desarrolladores a los responsables de desarrollo, etc. Con esta organizacin tradicional se encuentra los equipos que toman uno o ms miembros de cada uno de estos grupos y les asignan la responsabilidad de una parte de la funcionalidad del producto (MacCarthy, 1995). Podra tener un equipo de prestaciones dedicado a la impresin, generacin de informes o la generacin de grficos. El equipo de prestaciones se hace responsable de las decisiones tomadas sobre esa parte del producto. Los equipos de prestaciones presentan las ventajas de potenciacin, facilidad de seguimiento y equilibrio, que se explican a continuacin
Potenciacin. El equipo puede potenciar sensiblemente porque incluye representantes de desarrollo, control de calidad, documentacin, gestin del programa y marketing; es decir, de todas las partes implicadas.
Facilidad de Seguimiento. El equipo considerar todos los puntos de vista necesarios en sus decisiones, y por ello rara vez dar pie a que estas sean cuestionadas. Tienen acceso a todas las personas que necesitan para tomar buenas decisiones.
El equipo est equilibrado. Pueden obtenerse decisiones equilibradas de un grupo que incluye representantes de las secciones de desarrollo, marketing o control de calidad evitando que cualquiera de estos grupos tenga exclusivamente la ltima palabra sobre la especificacin de un producto.
Los equipos de prestaciones resultan adecuados para proyectos de resolucin de problemas, ya que ofrecen el refuerzo y la facilidad de seguimiento necesarios para resolver las cuestiones planteadas de forma expeditiva. Tambin son adecuados para proyectos de creatividad, ya que la composicin interdisciplinaria del equipo puede estimular las ideas. La gestin adicional generada por los equipos de prestaciones se desperdicia en los proyectos de ejecucin tctica: si todas las tareas estn claramente identificadas, los equipos de prestaciones tienen poco que aportar. En la Figura 9, se ilustra la estructura organizacional de esta configuracin de equipo.
Versin 0.5 26 DE 95
n n
EQUIPO DE PRESTACIONES 2
Representante del Producto Representante Marketing Representante Desarrollo Representante SQA Representante Documentaci n
Figura 9: Estructura Organizacional del Equipo de Prestaciones 1.8.1.5. Equipo de Bsqueda y Rescate. Combina un conocimiento especializado de herramientas software, hardware y un entorno comercial determinado. El equipo de bsqueda y rescate es el ms apropiado para equipos que necesiten centrarse en la resolucin de un problema. Est demasiado dirigido a problemas bsicos como para soportar mucha creatividad, y est demasiado orientado a corto plazo como para soportar la ejecucin tctica. La Figura 10, ilustra la estructura organizacional de esta configuracin de equipo.
Versin 0.5 27 DE 95
EQUI P O SW AT
P roblem a
Figura 11: Estructura Organizacional del Equipo SWAT 1.8.1.7. Equipo de Especialistas. En esta configuracin de equipo existe un responsable del desarrollo de software que no necesariamente requiere habilidades en programacin y debe asegurar un camino despejado para que los desarrolladores trabajen de forma eficiente. Los programadores podran desarrollar un producto sin el responsable, pero el responsable no podra desarrollar un producto sin los programadores. En esta configuracin de equipo existen roles altamente especializados y personal cuidadosamente seleccionado. Las especialidades del software pueden incluir: arquitecturas de sistemas, reutilizacin, evaluacin de paquetes, hardware, entornos software, lenguajes de programacin, redes LAN, herramientas CASE, soporte al cliente, pruebas y muchas ms. Este modelo especfico se aplica mejor a los proyectos de ejecucin tctica, que hacen nfasis en los papeles altamente especializados que desarrollan los desarrolladores individuales. La Figura 12, ilustra la estructura organizacional de esta configuracin de equipo.
Versin 0.5 28 DE 95
Especialista rea 1
Especialista rea 2
Especialista rea 3
Especialista rea 4
EQUIPO DE ESPECIALISTAS
R esponsable de Desarrollo
Especialista rea 5
Especialista rea 6
Especialista rea 7
Especialista rea 8
Figura 12: Estructura Organizacional del Equipo de Especialistas 1.8.1.8. Equipo de Teatro. Esta caracterizado por una fuerte direccin y una gran negociacin de los papeles del proyecto. El papel central del proyecto es ocupado por el director, que mantiene la visin del producto y asigna a la gente responsabilidades en reas individuales. Los participantes individuales pueden adaptar sus papeles, sus partes del proyecto, como les dicten sus propios instintos artsticos. Pero no pueden llevar demasiado lejos sus propias ideas, evitando colisionar con la visin del director, la visin del director tiene que prevalecer para la buena marcha del proyecto. Cada participante participa en una audicin, y negocia un papel. El responsable del software o productor debe obtener la financiacin, coordinar las planificaciones, y asegurase de que todo el mundo est en el sitio correcto en el momento adecuado. Generalmente el productor no juega un papel activo en los aspectos artsticos del proyecto. La fuerza del modelo de teatro consiste en que proporciona una va para integrar importantes contribuciones individuales junto con una fuerte visin central en proyectos de creatividad. El modelo de teatro resulta particularmente apropiado para equipos software dominados por fuertes personalidades. El modelo de teatro es un modelo adecuado para proyectos multimedia modernos. Mientras anteriormente los proyectos software necesitaban integrar las contribuciones de varios desarrolladores de software, ahora tiene que integrar las contribuciones de diseadores grficos, escritores, productores de video, productores de audio, editores, ilustraciones, coordinadores de contenido y varios desarrolladores de software. En la Figura 13 se ilustra la estructura organizacional de esta configuracin de equipo.
Versin 0.5 29 DE 95
EQUIPO DE TEATRO
Director de P royecto R esponsable de P royecto
Figura 13: Estructura Organizacional del Equipo de Teatro Para concluir, la siguiente tabla (adaptada de McConell 2003) resume las motivaciones de cada tipo de configuracin de equipo, as como su clasificacin respecto a los objetivos que persiguen (resolucin de problemas, creatividad o ejecucin tctica): OBJETIVO GENERAL Resolucin de Problemas Caracterstica Ejemplo nfasis en el proceso Modelo apropiado de Desarrollo Confianza Mantenimiento Soporte Centrado en cuestiones Codificar-Corregir Espiral Incremental Inteligente Desenvuelto Sensible Integro Creatividad Autonoma Desarrollo de nuevos productos Explorar posibilidades Prototipado. Espiral. Incremental. Cerebral. Independiente Pensador. Con Iniciativa. Tenaz. Negocios Programador Jefe En la sombra Prestaciones Equipo de teatro Ejecucin tctica Claridad Actualizacin de un producto Tareas centradas Funciones claras Cascada. Espiral. Incremental. Leal. Comprometido. De Accin. Diligente. Responsable. Negocios. Programador Jefe Prestaciones SWAT De Especialistas
Tabla 3: Resumen Configuraciones de Equipo y sus Caractersticas Segn la Tabla 3, es evidente que los procesos de desarrollo de software que consideran a este como un producto evolutivo, se adaptan mejor a las motivaciones y configuraciones de todos los equipos de desarrollo. Por esta razn, Agile-DISOP, re-toma este
Versin 0.5 30 DE 95
2 P rogram adores
3 P rogram adores
4 P rogram adores
5 P rogram adores
8 P rogramadores
Figura 14: Vas de Comunicacin en Proyectos de Distintos Tamaos Cuanto ms alto el CC para una comunidad de desarrollo, ms tiempo y esfuerzo se destinara a las comunicaciones entre sus miembros, incrementando la posibilidad de errores en la misma. Sin embargo, aunque en una comunidad de desarrollo que este soportada por una plataforma de integracin (descrita en el numeral 1.15), se facilite establecer canales de comunicacin entre todos sus miembros, es recomendable concebir una estructura organizacional donde existan personas que se comporten como interfaces entre equipos con el fin de lograr una organizacin y formalizacin de las comunicaciones de la comunidad. Para lograr esto, se requiere estructurar algn tipo de jerarqua creando equipos ms compactos y al mismo tiempo, asignar responsabilidades relacionadas con la comunicacin y coordinacin con el propsito de alcanzar la interaccin entre estos equipos y a travs de la plataforma de integracin.
Versin 0.5 31 DE 95
Figura 15: Organizacin de los equipos en la comunidad de desarrollo La Figura 15, ilustra esta estrategia, siguiendo el consejo de McConell (2003) se adopta una estructura organizacional para la comunidad de desarrollo que acople equipos geogrficamente dispersos mediante interfaces humano-computador que son responsables de la garanta, mantenimiento y soporte de los canales de comunicacin con el propsito de asegurar una coordinacin limpia y eficaz al interior de la comunidad. Por otra parte, e independientemente de la organizacin de los equipos pequeos, resulta crtico que haya una persona o equipo como responsable final de la integridad conceptual del producto. Su trabajo consiste en asegurarse de que todas las buenas soluciones locales de los equipos (i+d) conforman una buena solucin global (McConell 2003). En la Figura 15, esta persona o equipo se denota con la sigla R.I.C.P acrnimo de: Responsable de la Integridad Conceptual del Producto. Como se indicara mas adelante en este mismo capitulo, R.I.C.P es desempeado principalmente por el equipo promotor del proyecto. Por otra parte, la Figura 15, ilustra la posibilidad de implementar varias configuraciones de equipo dependiendo de las motivaciones de la comunidad, que pueden incluir: resolucin de problemas, creatividad y ejecucin tctica. En consecuencia en esta figura se observan configuraciones de equipo que obedecen a alguna de estas tres motivaciones, sin embargo cada equipo cuenta con una interfaz de comunicacin y coordinacin con los dems. Finalmente, todo miembro de un equipo cualquiera, tambin es miembro de la comunidad y como tal, tendr disponibilidad de servicios TICs de la plataforma de integracin para comunicarse y coordinarse como miembro individual con cualquier otro. Finalmente, la Figura 15, muestra un equipo dedicado a la gestin de la comunidad misma. Este equipo, debe ser experto en los temas relacionados con la plataforma de integracin de la comunidad, as como en el proceso de desarrollo Agile-DISOP propuesto, con el propsito de centrarse en la resolucin de los problemas cotidianos de la comunidad relativos a la plataforma de
Versin 0.5 32 DE 95
1.9. DISCIPLINA: GESTION DEL ENTORNO DE AGILE-DISOP 1.9.1. Propsito El propsito fundamental de esta disciplina consiste en animar a la comunidad de desarrollo o cualquier equipo (i+d) a configurar el proceso y la plataforma de integracin para cada proyecto en particular. Esta disciplina afirma la prctica propuesta en el numeral 1.4.9 y al mismo tiempo guarda estrecha relacin con la disciplina propuesta en el numeral 1.13. 1.9.2. Conceptos Los conceptos involucrados en esta disciplina son: Entorno, Plataforma de Integracin, Comunidad de Desarrollo, Proyecto, Ingeniero de Procesos, Proceso de Desarrollo, Instanciacin del Proceso de Desarrollo, Infraestructura de Desarrollo, Equipo de Soporte Tcnico, Servicio de Help-Desk. Para encontrar las definiciones correspondientes a los anteriores conceptos favor referirse al Error: Reference source not found. 1.9.3. Flujo de Trabajo Como puede apreciarse en la Figura 16: Flujo de Trabajo para la Gestin del Entorno, en las iteraciones tempranas de la fase de Inicio, se prepara el entorno y la plataforma de integracin el proyecto. Las actividades involucradas en este flujo de trabajo, producirn un proceso de desarrollo especfico para el proyecto. Luego, durante las iteraciones ms tardas, se hace necesario ir ajustando tanto el entorno del proyecto como la plataforma de integracin, con el propsito de adaptar las variaciones imprevistas que surjan durante la ejecucin del proyecto.
Versin 0.5 33 DE 95
[N o I nstalada]
[Final de I teracin]
P royecto Fi nalizado
1.9.4. Actividades A continuacin se especifican las actividades que se muestran en la Figura 16: Flujo de Trabajo para la Gestin del Entorno.
Preparar el Entorno para el Proyecto El propsito de esta actividad consiste en transformar el proceso Agile-DISOP genrico en uno especfico para el proyecto, dependiendo del nivel de habilidad, conocimiento y experiencia del equipo de desarrollo. Adems, esta transformacin tiene que ver con el nivel de rigurosidad y madurez con el que se desea implementar el proceso, pues segn lo recomendado en el numeral 1.5, la adopcin del proceso debe ser iterativa e incremental para no sofocar a los equipos (i+d) con poca experiencia. De otra parte esta actividad est en concordancia con la disciplina explicada en el numeral 1.13 sobre el mejoramiento tambin iterativo e incremental del proceso durante su adopcin y uso con el propsito de alcanzar madurez. Preparar un proceso especfico para el proyecto involucra: Determinar las desviaciones y/o extensiones que se van a realizar al proceso en el marco del desarrollo del proyecto.
Versin 0.5 34 DE 95
Agile-DISOP (Genrico) Ver Error: Reference source not found Agile-DISOP (Especfico para el Proyecto) Ingeniero de Procesos. (RUP 2003)
Instalar la Plataforma de Integracin para la Comunidad Si an no est instalada la plataforma de servicios TIC que integrar a la comunidad de desarrollo, entonces debe hacerse cuanto antes con el propsito de soportar las reas de la gestin, comunicacin coordinacin y control de los equipos (i+d) durante el desarrollo del proyecto. Instaladores de la Plataforma de Integracin, Equipo Servidor y Plataforma SW Plataforma de Integracin Instalada Ingeniero de Procesos. (RUP 2003) Preparar la Plataforma de Integracin para el Proyecto Consiste en configurar y definir la informacin general del proyecto en trminos de tiempo, personas, responsabilidades y productos, mediante el uso de los servicios ofrecidos por la plataforma de integracin que usa la comunidad de desarrollo.
Plataforma de Integracin (Sin informacin especfica para el proyecto) Plan de Proyecto (Ver Error: Reference source not found) Plataforma de Integracin (Con informacin especfica para el proyecto) Gestor del Proyecto. (RUP 2003)
Preparar el Entorno para la Iteracin El propsito de esta actividad es similar al de la actividad Preparar el Entorno para el Proyecto, la nica diferencia es que se va adaptando para cada iteracin en particular.
Agile-DISOP (Especfico para el Proyecto) Plan de Iteracin (Ver Error: Reference source not found) Agile-DISOP (Especfico para la Iteracin) Ingeniero de Procesos. (RUP 2003)
Preparar la Plataforma de Integracin para la Iteracin Consiste en configurar y definir la informacin general del proyecto en trminos de tiempo, personas, responsabilidades, productos entre otros, que son especficos para una iteracin del proyecto mediante el uso de los servicios ofrecidos por la plataforma de integracin que usa la comunidad de desarrollo.
Plataforma de Integracin (Sin informacin especfica para la Iteracin) Plan de Iteracin (Ver Error: Reference source not found) Plataforma de Integracin (Con informacin especfica para la Iteracin) Gestor del Proyecto. (RUP 2003)
Descripcin
Soportar la Plataforma de Integracin para la Iteracin El propsito de esta actividad consiste en soportar al equipo (i+d) en el uso de los servicios informticos que provee la plataforma integracin durante una iteracin especfica. La idea es que el equipo (i+d) no se disperse en peculiaridades tcnicas relacionadas con el funcionamiento de la plataforma. En cualquier caso, el equipo (i+d) realizar peticiones de soporte al equipo de soporte tcnico el cul las recopilar y evaluar para darles respuesta tan pronto como sea posible.
Servicio de Help-Desk de la Plataforma de Integracin seleccionada. Servicio de Help-Desk de la Plataforma de Integracin seleccionada. Ingeniero de Procesos. (RUP 2003) Equipo (i+d)
Versin 0.5 35 DE 95
Descripcin
Plataforma de Integracin
Numeral 1.15.
Plan de Proyecto
Plan de Iteracin
Tabla 5: Artefactos de la Disciplina Gestin del Entorno 1.9.6. Arquitectura Como se muestra en la Figura 17, el proceso Agile-DISOP genrico es personalizado para el proyecto o proyectos que emprenda la comunidad de desarrollo. As en un momento determinado pueden existir varias instancias del mismo proceso Agile-DISOP ejecutndose en diferentes sub-proyectos con un nivel variado de madurez y dentro un macro-proyecto de desarrollo en comunidad. De otra parte, se puede observar que cada proyecto emprendido por la comunidad de desarrollo, ser soportado mediante una plataforma de integracin que usa la comunidad y que se describe suficientemente en el numeral 1.15.
Versin 0.5 36 DE 95
Figura 17: Arquitectura de la Gestin del Entorno 1.9.7. Premisas La plataforma de integracin debe ser accesible por todos y cada uno de los miembros de la comunidad, desde cualquier ubicacin geogrfica, salvo casos de fuerza mayor.
De otra parte la gua del proceso Agile-DISOP, debe estar publicada en la plataforma de integracin u otra plataforma de gestin de contenidos (se recomienda Moodle 3) con el objeto de facilitar la referencia y consulta por parte de los miembros de la comunidad de desarrollo.
Debe existir una configuracin de equipo de bsqueda y rescate (explicado en el numeral 1.8.1.5) disponible para la resolucin gil de problemas que puedan surgir con la instalacin, puesta en marcha y mantenimiento de la plataforma ante toda la comunidad de desarrollo.
Es fundamental que exista un modelo de documentacin que permita instrumentar esta disciplina. Se recomienda la estructura de directorios del Error: Reference source not found. All se muestra la ubicacin exacta de los artefactos de
Versin 0.5 37 DE 95
responsables por distintos aspectos relativos al comportamiento y la auto-regulacin de la comunidad. La gestin de la comunidad es responsabilidad del equipo SWAT mostrado en la Figura 15 y descrito en el numeral 1.8.1.6. La gestin de la comunidad propone un marco para regular lo que la gente puede/no puede, debe/no debe hacer. Esta funcin es crtica, puesto que de la calidad de su ejecucin depende en gran medida el crecimiento o decadencia de la misma. Si la gestin es dbil, entonces la comunidad sucumbir bajo la anarqua; demasiada fuerza en la gestin, har parecer a la comunidad como un centro correccional donde nadie se siente a gusto. Como se observa en la Figura 18, una vez se ha estabilizado la definicin del propsito de la comunidad, la gestin de la comunidad se divide en dos grandes reas:
La gestin de miembros. Constituida por las actividades relacionadas con la gestin del acceso a la comunidad, la gestin de roles y la gestin de la comunicacin efectiva entre los miembros de la comunidad de desarrollo.
La Gestin de Polticas. Constituida por las actividades relacionadas con la gestin del registro de los miembros en la comunidad, la gestin de las polticas de comportamiento y la gestin de la confianza-seguridad a travs de la comunidad.
Versin 0.5 38 DE 95
[Debe Refinarse]
Gestin de Acceso
Gestin de Registro
Gestin de Comportamiento
Figura 18: Flujo de Trabajo de la Gestin de la Comunidad 1.10.4. Actividades A continuacin se especifican las actividades que se muestran en la Figura 18.
Nombre de Actividad
Gestin del Acceso El propsito de esta actividad consiste en determinar y gestionar los requerimientos para unirse o dejar la comunidad de desarrollo. De la misma forma, es importante asegurar que los candidatos a miembros de la comunidad conocen estos requerimientos y los aceptan o rechazan. Polticas de Adhesin. El interesado en formar parte de la comunidad debe: Proporcionar un nombre de usuario y una contrasea. Proporcionar un nombre de cuenta de e-mail activada.
Descripcin
Diligenciar la informacin personal del usuario especificado en el formulario del registro de la Figura 19. Esperar el estudio y aprobacin de la solicitud de suscripcin por parte del equipo de gestin de la comunidad. Polticas de Abandono El miembro de la comunidad debe expresar de forma explcita y durante una sesin activa, que desea retirarse de la comunidad de desarrollo. Requerimientos Tcnicos Acceso a Internet, Navegador de Internet, Ancho de Banda.
Entradas
Versin 0.5 39 DE 95
Polticas de adhesin y/o abandono (Versin i+1) Equipo SWAT de Gestin de la Comunidad (mostrado en la Figura 15)
Gestin de Roles El propsito de esta actividad consiste en la gestin de los diferentes roles que los miembros de la comunidad de desarrollo van asumiendo dentro de la ejecucin de los proyectos o durante la gestin de la comunidad misma. Existen dos (2) tipos de roles: visibles e invisibles. Los primeros hacen parte de los equipos (i+d) durante los proyectos de desarrollo (Ej. analistas, diseadores, desarrolladores, etc.), los segundos (Ej. administradores, moderadores, personal de soporte) hacen parte del equipo de gestin de la comunidad. Es crucial que la declaracin de responsabilidades asociadas a cada rol sea clara para todo miembro en la comunidad de desarrollo con el propsito de evitar malentendidos. De otra parte, es importante tener en cuenta que la contribucin individual de cada rol, debe favorecer el propsito de la comunidad de desarrollo.
Descripcin
Polticas de Gestin de Roles en la Comunidad (Versin i) Polticas de Gestin de Roles en la Comunidad (Versin i+1) Equipo SWAT de Gestin de la Comunidad (mostrado en la Figura 15)
Gestin de la Comunicacin Efectiva Esta actividad tiene como propsito la determinacin y gestin de las formas correctas de expresin en lnea (conos gestuales, jerga) que usan los miembros de la comunidad para comunicarse entre s. Algunas reglas de cortesa pueden ser: Evitar el envo de un mensaje que es relevante para una sola persona a toda una lista de miembros en la comunidad. Responder con palabras como Si, No, sin contexto de la conversacin, ser incomprensibles en pocos das. Siempre debe proporcionarse un contexto a las respuestas. Ejemplo: incluyendo el texto del mensaje al cul se responde o una oracin completa que sea comprensible. No publicar mensajes de poca relevancia en los espacios de la comunidad. Evitar las formas de humor que puedan ser malentendidas o potencialmente ofensivas. Evitar la redaccin de mensajes en letras capitales, la gente lo interpretar como si UD. estuviese gritando. Evitar el uso de auto-respuestas cuando se est suscrito a una lista. Agregue conos gestuales (emoticons) a sus mensajes para incrementar las posibilidades de una interpretacin correcta. Algunos ejemplos de conos gestuales se ilustran a continuacin:
Comunicacin Efectiva con Moderacin As mismo, puede proveerse un mecanismo de mediacin entre los miembros de la comunidad que inician un debate en cualquier punto dentro de la
Versin 0.5 40 DE 95
Polticas de Netiquette (Versin i) Polticas de Netiquette (Versin i+1) Equipo SWAT de Gestin de la Comunidad (mostrado en la Figura 15)
Descripcin
Gestin del Registro El propsito fundamental de esta actividad consiste en regular las polticas de registro que garantizan un mecanismo de moderacin en lo relativo a las personas que pueden unirse a la comunidad. Las polticas de registro pueden concebirse para filtrar determinadas tendencias, capacidades o grupos de personas que podran no contribuir o incluso deteriorar el clima dentro de la comunidad de desarrollo. Las polticas de registro pueden determinar las condiciones para que usuarios potenciales de la comunidad puedan unirse durante un tiempo limitado con carcter de invitado.
Polticas de Registro (Versin i) Polticas de Registro (Versin i+1) Equipo SWAT de Gestin de la Comunidad (mostrado en la Figura 15)
Descripcin
Gestin del Comportamiento El propsito fundamental de esta actividad consiste en establecer y gestionar un cdigo de comportamiento aceptable para todos los miembros de la comunidad de desarrollo, que garantice una relacin cordial y responsable entre los miembros al mismo tiempo que permite a la comunidad crecer y evolucionar. Se proponen las siguientes directivas para empezar: Las expresiones o palabras son responsabilidad del usuario y no expresan el sentir de la comunidad ni de sus directivos. La publicacin de informacin ilegal, flageada o inmoral no est permitida. El trato agresivo no est permitido. Cdigo de Comportamiento (Versin i) Cdigo de Comportamiento (Versin i+1)
Descripcin
Gestin de la Confianza y Seguridad La confianza es crucial en la buena salud de una comunidad. El propsito de esta actividad consiste en asegurar la proteccin sobre la privacidad y confidencialidad de cada miembro de la comunidad de desarrollo. Preece (2003) recomienda los siguientes lineamientos: Proteccin de la informacin confidencial. Proteccin de informacin financiera. Advertir sobre informacin cuyo uso incorrecto puede causar problemas. Crear mecanismos para la proteccin de la propiedad intelectual. Instalar mecanismos que apoyen la confianza. Ejemplo: logos de las universidades y equipos (i+d) involucrados en la comunidad, fotografas e informacin veraz para todos los miembros etc.
Polticas de Gestin de la Confianza y Seguridad (Versin i) Polticas de Gestin de la Confianza y Seguridad (Versin i+1) Equipo SWAT de Gestin de la Comunidad (mostrado en la Figura 15) Tabla 6: Actividades del Flujo de Gestin de la Comunidad
Versin 0.5 41 DE 95
Figura 19: Formulario de Registro para Nuevos Usuarios 1.10.5. Artefactos Los artefactos elaborados y/o refinados durante la ejecucin de la gestin de la comunidad, se describen en la siguiente tabla: No. 1 2 3 Nombre Polticas de Adhesin y/o Abandono. Polticas de Gestin de Roles de la Comunidad. Reglas de Netiquette Propsito Especifica las restricciones para la aceptacin o rechazo del aspirante a miembro de la comunidad. Especifica las responsabilidades de cada rol en la comunidad. Especifica el protocolo aceptable de expresin y comunicacin de los miembros de la comunidad. Especifica los requerimientos tcnicos y de informacin que son exigidos durante el proceso de suscripcin a la comunidad de desarrollo. Especifica el comportamiento aceptable de cada miembro de la comunidad. Especifica el esquema de promocin al reconocimiento de la propiedad intelectual y la proteccin de la informacin personal. Especificado en Error: Reference source not found Error: Reference source not found Error: Reference source not found Error: Reference source not found Error: Reference source not found Error: Reference source not found
Polticas de Registro
1.10.6. Arquitectura Como se muestra en la Figura 20, la arquitectura de la gestin de la comunidad involucra la jerarqua de polticas que regulan el comportamiento de la comunidad con nimo de satisfacer su propsito fundamental. Las polticas de gestin de la comunidad deben estar soportadas por los servicios de la plataforma de integracin y sern gestionadas por el equipo SWAT descrito en el numeral 1.8.1.6 .
Versin 0.5 42 DE 95
Figura 20: Arquitectura de la Gestin de la Comunidad 1.10.7. Premisas Debe existir un proceso continuo de refinamiento y puesta en marcha sobre las polticas de la comunidad que adems est regulado por una vigilancia eficaz sobre el cumplimiento de las mismas. Las polticas deben ser aceptadas, pblicas, consensuadas y claras para todos los miembros de la comunidad de desarrollo, en ningn caso deben promover la discriminacin sobre etnias o grupos sociales especficos, sin embargo un mecanismo de filtro puede implementarse con base en los criterios de: conocimiento, expectativas y contribuciones por parte de los usuarios que aspiran a convertirse en miembros activos de la comunidad. Las polticas deben ser fciles de implementar en la plataforma de integracin con los servicios que esta provee.
Debe existir una configuracin de teatro (explicado en el numeral 1.8.1.8) disponible para la elaboracin del modelo de sociabilidad ante toda la comunidad de desarrollo.
Es fundamental que exista un modelo de documentacin que permita instrumentar esta disciplina. Se recomienda la estructura de directorios del Error: Reference source not found. All se muestra la ubicacin exacta de los artefactos de esta disciplina en el marco de una iteracin para cualquier fase del proceso. La idea es que con cada nueva iteracin, el usuario de Agile-DISOP, slo replicar el sub-directorio Iteracin7, logrando con esto, alcanzar una estructura de documentacin uniforme para todos los proyectos que emprenda la comunidad.
Versin 0.5 43 DE 95
Sub-Disciplina de Planificacin. Se concentra en determinar las caractersticas principales del macro-proyecto como son: Objetivos y alcance del software a desarrollar, costo aproximado, cronograma y recursos (humanos, tecnolgicos, de infraestructura entre otros). As mismo, el sub-modelo de planificacin promover la particin del Macro-Proyecto en Subproyectos ms pequeos, los cules seran ejecutados por equipos (i+d) independientes y geogrficamente dispersos. Lo anterior, es determinado durante la fase de Inicio del macro-proyecto, pero se refinara constantemente de forma ms realista a partir de la fase de Elaboracin que es donde se realizan las primeras iteraciones sobre los casos de uso arriesgados en cualquier sub-proyecto.
Sub-Disciplina de Monitoreo, Control y Gestin de Riesgos. Se concentra en proveer los mecanismos de acompaamiento a las actividades de la planificacin que brindarn el soporte para realizar el seguimiento y evaluacin del estado de avance del macro y micro proyectos dentro de los plazos y costos establecidos. Adems, segn Boehm (1989), la gestin de riesgos se divide en dos: estimacin y control. La estimacin se concentra en la identificacin, anlisis y priorizacin de los riesgos, mientras que el control se preocupa de la planificacin de la gestin, resolucin y monitorizacin de riesgos.
1.11.2. Conceptos Los conceptos involucrados en esta disciplina son: Promotor del Proyecto, Director del Proyecto, Gestin, Monitoreo, Control, Riesgos, Cronograma, Recursos, Productos. Para encontrar las definiciones correspondientes a los anteriores conceptos favor referirse al Error: Reference source not found. 1.11.3. Flujo de Trabajo En la Figura 21: Flujo de Trabajo para la Gestin del Macro-Proyecto y la Tabla 7, se ilustra y describe la secuencia de actividades que se siguen desde la propuesta del macro-proyecto a la comunidad, pasando por su refinamiento y ajuste, hasta su particionamiento en varios sub-proyectos.
Versin 0.5 44 DE 95
[Debe Aclararse]
[Se Acepta]
[Debe Ajustarse]
[Se Acepta]
Figura 21: Flujo de Trabajo para la Gestin del Macro-Proyecto Cada sub-proyecto se ejecuta siguiendo el flujo de trabajo que se muestra en la Figura 22. Obsrvese que el flujo de trabajo
refleja la naturaleza gil, iterativa e incremental y comunitaria del proceso recomendada en la prctica planteada en el numeral 1.4.3. Mas adelante, en la Tabla 8: Actividades del Flujo de Gestin a nivel de Sub-Proyecto se especifican todas las actividades de la Figura 22.
Versin 0.5 45 DE 95
[I teracin Ex itosa]
[Debe Aclararse]
[Se R echaza]
[Se Acepta]
Evaluar Alcance y Riesgos del Proyecto [Se Acepta] [Final de Proyecto] [Final de Fase] [Final I teracin] Sub-Proyecto Cancelado Cerrar Fase Cerrar Proyecto
Sub-Proyecto Cancelado
[Debe Ajustarse]
[N o Aceptado]
[Debe R efinarse] [Opcional] Refinar Plan de Proyecto Elaborar/Refinar Plan Preliminar de Proyecto [Se Acepta] Planear Siguiente Iteracin
Sub-Proyecto Cancelado
Fin de Iteraci n
Figura 22: Flujo de Trabajo para el Modelo de Gestin en un Sub-Proyecto 1.11.4. Actividades La descripcin de las actividades de la Figura 21: Flujo de Trabajo para la Gestin del Macro-Proyecto se especifica a continuacin:
Nombre de Actividad
Descripcin
Proponer el Macro-Proyecto a la Comunidad Consiste en la publicacin ante la comunidad de desarrollo de una idea de software por parte cualquier equipo (i+d). La propuesta estar sometida a la aprobacin de la comunidad para proseguir. El Error: Reference source not found especificada la informacin de esta propuesta en el artefacto Visin del Proyecto. Se recomienda proponer una idea con potencial y ojal acompaada de un prototipo preliminar, tal como plantea la prctica del numeral 1.4.3
Visin de Macro-Proyecto (En Blanco) Vase Error: Reference source not found Visin de Macro-Proyecto (Diligenciado) Opcional: Prototipo Preliminar. Miembro de la comunidad o Sub-Equipo (i+d) (Promotor Proyecto)
Valorar/Ajustar Alcances y Riesgos del Proyecto. Consiste en la estimacin del riesgo que implica el proyecto y el ajuste a los alcances del mismo. As mismo, se transforma el modelo general de mtricas a uno especfico para el proyecto. Esta visin debe refinarse hasta ser aprobada plenamente por la comunidad de desarrollo.
Alcances del Macro-Proyecto (En Blanco) Modelo Mtricas del Macro-Proyecto: Producto (Error: Reference source not found) Modelo de Mtricas del Macro-Proyecto: Proceso (Error: Reference source not
Versin 0.5 46 DE 95
[Aceptado]
[Se Rechaza]
Salidas
Plan Preliminar de Riesgos del Macro-Proyecto (Error: Reference source not found) Alcances del Macro-Proyecto (Diligenciado) Modelo Mtricas del Macro-Proyecto: Producto y Proceso (Especfico) Plan Preliminar de Riesgos del Macro-Proyecto (Diligenciado) Promotor del Proyecto Colaboran: o Equipo (i+d) del Promotor del Proyecto o Comunidad de Desarrollo
Roles Responsables:
Particionar Macro-Proyecto en Sub-Proyectos Consiste en la particin del macro-proyecto en unidades ms compactas denominadas sub-proyectos, los cules son ejecutados por equipos (i+d) independientes geogrficamente dispersos. La aprobacin en comunidad de esta particin garantizar el inicio de la ejecucin de los sub-proyectos distribuidos a travs de la comunidad.
Distribucin del Macro-Proyecto en Sub-Proyectos (En Blanco) Vase Error: Reference source not found. Distribucin del Macro-Proyecto en Sub-Proyectos (Diligenciado) Promotor del Proyecto Colaboran: o Equipo (i+d) del Promotor del Proyecto o Comunidad de Desarrollo
Nombre de Actividad Descripcin Entradas Salidas Roles Responsables: Nombre de Actividad Descripcin
Ejecutar Sub-Proyecto i La especificacin de esta actividad se encuentra en la Figura 22: Flujo de Trabajo para el Modelo de Gestin en un Sub-Proyecto. Ninguna Sub-Proyecto Finalizado / Sub-Proyecto Cancelado
Monitoreo, Control y Gestin de Riesgos Las actividades relacionadas con el monitoreo, control y gestin de riesgos, se realizan tanto a nivel del Macro-Proyecto como a nivel de cada sub-proyecto.
Entradas
Alcances del Macro-Proyecto (Diligenciado) Modelo Mtricas del Macro-Proyecto: Producto y Proceso (Especfico) Plan Preliminar de Riesgos del Macro-Proyecto (Diligenciado) Valoracin: Gestin de Riesgos, Monitoreo y Control (Error: Reference source not found) Valoracin: Gestin de Riesgos, Monitoreo y Control (Diligenciada) Promotor del Proyecto
Tabla 7: Actividades del Flujo de Gestin a nivel de Macro-Proyecto De otra parte, la especificacin de las actividades de la Figura 22: Flujo de Trabajo para el Modelo de Gestin en un Sub-Proyecto se especifican a continuacin:
Elaborar/Refinar Visin de Proyecto El equipo (i+d) que manifiesta su inters a la comunidad sobre el desarrollo de un subproyecto, elabora un documento de solicitud de proyecto de acuerdo al Error: Reference source not found. Este documento se publica ante la comunidad y estar sometido a su aprobacin para proseguir la ejecucin.
Versin 0.5 47 DE 95
Entradas
Alcances del Macro-Proyecto (Diligenciado) Modelo Mtricas del Macro-Proyecto: Producto y Proceso (Especfico)
Salidas
Alcances del Sub-Proyecto (En Blanco) Modelo Mtricas del Sub-Proyecto: Producto y Proceso (En Blanco) Plan Preliminar de Riesgos del Sub-Proyecto (En Blanco) Alcances del Sub-Proyecto (Diligenciado) Modelo Mtricas del Sub-Proyecto: Producto y Proceso (Especfico) Plan Preliminar de Riesgos del Sub-Proyecto (Diligenciado) Director de Sub-Proyecto Colaboran: o Comunidad de Desarrollo. o Equipo (i+d) promotor del Macro-Proyecto. o Miembros del Equipo (i+d) responsable del Sub-Proyecto.
Roles Responsables:
Elaborar/Refinar Plan Preliminar de Proyecto Consiste en la elaboracin preliminar de un Plan para el sub-proyecto que ser ejecutado por el equipo (i+d). La informacin de este documento se puede encontrar en el Error: Reference source not found. El documento diligenciado, debe ser publicado en la plataforma de integracin en un rea pblica con el propsito de que est disponible para consulta o referencia para toda la comunidad de desarrollo.
Plan de Sub-Proyecto (En Blanco) Error: Reference source not found Plan de Sub-Proyecto (Diligenciado) Director de Sub-Proyecto Colaboran con la revisin: o Equipo (i+d) del Promotor del Proyecto o Comunidad de Desarrollo
Planificar Siguiente Iteracin Su propsito consiste en la elaboracin de un plan (de grano fino) que guiar la prxima iteracin. Si existen cambios en el esfuerzo, tiempo y/ costos, puede ejecutarse la actividad 7.
Plan de Iteracin (En Blanco) Error: Reference source not found Plan de Iteracin (Diligenciado) Director de Sub-Proyecto Colaboran: o Equipo (i+d) del Sub-Proyecto
Evaluar Alcances y Riesgos del Proyecto Luego de cada iteracin, se evala y actualiza el estado de avance del proyecto.
Alcances del Sub-Proyecto (Diligenciado) Modelo Mtricas del Sub-Proyecto: Producto y Proceso (Especfico) Plan de Riesgos del Sub-Proyecto (Diligenciado) Alcances del Sub-Proyecto (Ajustado) Modelo Mtricas del Sub-Proyecto: Producto y Proceso (Ajustado) Plan de Riesgos del Sub-Proyecto (Ajustado) Director de Sub-Proyecto
Versin 0.5 48 DE 95
Descripcin
Entradas Salidas Roles Responsables Nombre de Actividad Descripcin Entradas Salidas Roles Responsables Nombre de Actividad Descripcin Entradas Salidas Roles Responsables
Cerrar Fase Consiste en las actividades relacionadas con el cierre de la Fase (Inicio, Elaboracin, Construccin y/o Transicin). Como recomienda Larman (2003), si se dispone de una herramienta de control de versiones, usualmente se crea un punto de control etiquetado y congelado de todas las carpetas de la documentacin. Ver numeral 1.4.11. A la hora de decidir si se cambia o no de fase, tenga en cuenta los hitos: Inicio (numeral 1.7.2.1), Elaboracin (numeral 1.7.2.2), Construccin (numeral 1.7.2.3) y transicin (numeral 1.7.2.4) Ninguna. Ninguna. Director de Sub-Proyecto Cerrar Proyecto Consiste en las actividades relacionadas con el cierre del Proyecto. Como recomienda Larman (2003), si se dispone de una herramienta de control de versiones, usualmente se crea un punto de control etiquetado y congelado de todas las carpetas de la documentacin. Ver numeral 1.4.11. Ninguna. Ninguna. Director de Sub-Proyecto Final de Iteracin Consiste en las actividades relacionadas con el cierre de la iteracin actual. Como recomienda Larman (2003), si se dispone de una herramienta de control de versiones, usualmente se crea un punto de control etiquetado y congelado de todas las carpetas de la documentacin. Ver numeral 1.4.11. Ninguna. Ninguna. Director de Sub-Proyecto Tabla 8: Actividades del Flujo de Gestin a nivel de Sub-Proyecto
1.11.5. Artefactos Los artefactos elaborados, refinados o involucrados durante la ejecucin de las actividades de esta disciplina se relacionan en la siguiente tabla: No. 1 2 Nombre Visin del Macro-Proyecto Alcances del Macro Proyecto Propsito Provee una breve descripcin acerca del problema y objetivos perseguidos. Provee una breve descripcin de los resultados esperados y sus correspondientes indicadores de logro. Especifica un sistema de mtricas para el producto y proceso de software con el propsito de valorar la calidad. Tabula una coleccin preliminar de riesgos as como su correspondiente descripcin y estrategia de mitigacin. Propone una descomposicin del Especificado en Error: Reference source not found Error: Reference source not found Error: Reference source not found y Error: Reference source not found Error: Reference source not found Error: Reference source
Modelo de Mtricas del MacroProyecto: Producto y Proceso Plan Preliminar de Riesgos del Macro-Proyecto Distribucin Macro-Proyecto
4 5
Versin 0.5 49 DE 95
Error: Reference source not found Error: Reference source not found Error: Reference source not found Error: Reference source not found y Error: Reference source not found Error: Reference source not found Error: Reference source not found Error: Reference source not found
Modelo Mtricas del Sub-Proyecto: Producto y Proceso Plan Preliminar de Riesgos del SubProyecto
10
11
Plan de Sub-Proyecto
12
Tabla 9: Artefactos de la Disciplina Gestin del Proyecto 1.11.6. Arquitectura A continuacin, se proporcionan una breve descripcin relativa a los diagramas de clase del anlisis en UML para los sub-modelos: Planificacin y Monitoreo-Control, Gestin de Riesgos.
Versin 0.5 50 DE 95
Figura 23: Arquitectura del Sub-Modelo de Planificacin En el diagrama de la Figura 23: Arquitectura del Sub-Modelo de Planificacin se ilustran los componentes fundamentales de esta disciplina. Como punto central se encuentra el proyecto, el cual puede descomponerse a su vez en sub-proyectos. Cada proyecto contempla un plan que especifica las dimensiones del producto, el cronograma, los objetivos, presupuesto y los recursos (humanos, tecnologa e infraestructura). La planificacin temporal del cronograma se divide por semanas durante las cuales, se ejecutan las actividades del proyecto. En el diagrama de la Figura 24: Arquitectura del Sub-Modelo "Monitoreo, Control y Riesgos", se ilustran los elementos que garantizan el monitoreo y control, mediante las mtricas (las cules pueden compartirse para varios proyectos) y sus metas asociadas. De otra parte, los elementos que implementan la gestin de riesgos, estaran representados en primer lugar por los riesgos y sus correspondientes mtodos de control, y en segundo lugar, por la mitigacin de los riesgos, reflejada en los elementos de progreso a travs de las semanas. El artefacto para la especificacin de los requisitos funcionales y no-funcionales del producto software, se encuentra descrito en detalle en el Error: Reference source not found.
Versin 0.5 51 DE 95
Figura 24: Arquitectura del Sub-Modelo "Monitoreo, Control y Riesgos" 1.11.7. Premisas Las siguientes premisas se consideran verdaderas para la ejecucin del modelo de gestin propuesto por esta metodologa: Existe una plataforma de integracin sobre Internet, la cul soporta los procedimientos relacionados con la gestin de macro-proyectos y sub-proyectos. Cada gerente de proyecto puede obtener una visin global de otros proyectos, sin derecho de realizar alteraciones en su informacin a menos que tambin sea gerente. Los requisitos de cada proyecto no pueden ser alterados por otro equipo de desarrollo, pero si pueden debatirse y negociarse, mediante los servicios de foro de la plataforma de integracin. La plataforma de integracin debe ser accesible por todos y cada uno de los miembros de la comunidad, desde cualquier ubicacin geogrfica, salvo casos de fuerza mayor.
Debe existir una configuracin de equipo con programador jefe (explicado en el numeral 1.8.1.2) disponible para ejecutar las responsabilidades de esta disciplina.
Es fundamental que exista un modelo de documentacin que permita instrumentar esta disciplina. Se recomienda la estructura de directorios del Error: Reference source not found. All se muestra la ubicacin exacta de los artefactos de esta disciplina en el marco de una iteracin para cualquier fase del proceso. La idea es que con cada nueva iteracin, el usuario de Agile-DISOP, slo replicar el sub-directorio Iteracin8, logrando con esto, alcanzar una estructura de documentacin uniforme para todos los proyectos que emprenda la comunidad.
1.11.8. Mtricas
8
Versin 0.5 52 DE 95
Mtricas para la Estimacin del Tamao, Costo, Esfuerzo y Tiempo del Proyecto.
Histrico de los proyectos ejecutados con anterioridad con el propsito de asignar recursos y tiempo a las actividades de proyectos de tamao y complejidad semejante. As mismo, realizar una asignacin de responsabilidades al personal sobre una base de experiencia pasada.
Valorar la calidad de los artefactos elaborados dentro de la Gestin de proyectos y en especial la Visin del Proyecto (Error: Reference source not found) y Plan de Proyecto (Error: Reference source not found).
Valor Ganado. Esta mtrica es muy importante para el seguimiento de la cantidad de trabajo realizado. Esta mtrica se calcula de la siguiente forma:
Pi =
Ci =
1.11.9. Mtodos Se recomienda la utilizacin de los diagramas de Gantt y PERT con el propsito de obtener: Fecha ms temprana para el inicio y finalizacin de una actividad. Fecha ms tarda para el inicio y finalizacin para una actividad. Camino crtico de actividades para el proyecto. Especificar dependencias entre actividades, incluso entre proyectos correlacionados. Calcular el tiempo total del proyecto.
Versin 0.5 53 DE 95
Disponible slo en formato digital Vase Figura 22 y Tabla 8: Actividades del Flujo de Gestin a nivel de Sub-Proyecto 11 El cul realiza y/o implementa el/los caso(s) de uso(s) tomados para la iteracin de turno.
10
Versin 0.5 54 DE 95
2
Elaborar IGU Casos de Uso
3
Implementar IGUs
Perfeccionar Glosario
Anlisis Anlisis
Disear Reportes
Implementar Reportes
Diseo Diseo
PP ruebas ruebas
Anlisis:: Perfeccionar Diagramas de Casos de Uso El diagrama de Casos de Uso describe grficamente la interaccin que ocurre entre los actores y el sistema, sin embargo debe irse refinando a medida que se avanza con el desarrollo del proyecto. Es posible que se encuentren nuevos casos de uso, se reorganicen los ya existentes o se establezcan nuevas relaciones con otros actores o nuevas dependencias con otros casos de uso.
Diagramas de Casos de Uso (Versin anterior) Vase Error: Reference source not found Diagramas de Casos de Uso (Nueva Versin). Analista (RUP 2003)
Anlisis:: Especificar Casos de Uso Esenciales El caso de uso, es un documento narrativo que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema para completar un proceso. Los casos de uso son historias o casos de utilizacin de un sistema; ejemplifican e incluyen tcitamente los requerimientos en las historias que narran. Existen dos momentos para especificar un caso de uso esencial:
Un caso de uso de alto nivel se utiliza para lograr rpidamente un entendimiento de los principales procesos globales. Incluye una descripcin breve sobre el inicio, desarrollo y finalizacin del caso de uso. Un caso de uso en formato expandido muestra ms detalles que el anterior y se utiliza a menudo para entender y conocer ms profundamente los procesos y los requerimientos. Est escrito en trminos de los estmulos enviados por el actor o actores y las reacciones
Versin 0.5 55 DE 95
[Satisfactorias]
[I nsatisfactorias]
Diagramas de Casos de Uso. Ver Error: Reference source not found Especificacin Extendida para los Casos de Uso. Vase Error: Reference source not found Especificador de Requerimientos (RUP 2003)
Descripcin
Anlisis:: Elaborar Diagramas de Secuencia del Sistema Los casos de uso indican cmo los actores interactan con el sistema de software que es en realidad lo que se desea desarrollar. Durante la interaccin, un actor genera eventos dirigidos al sistema, solicitando de este, la ejecucin de una operacin a cambio. El diagrama de secuencia del sistema, es una representacin grfica que muestra, en determinado escenario de un caso de uso, los eventos generados por actores externos, su orden y los eventos internos del sistema. En un diagrama de secuencia del sistema, este ltimo, se trata como una caja negra; los diagramas se centran en los eventos que fluyen desde los actores externos hacia el sistema.
Especificacin Extendida para Casos de Uso. Vase Error: Reference source not found Diagrama de Secuencia del Sistema para los Casos de Uso. Ver Error: Reference source not found Diseador RUP (2003)
Anlisis:: Elaborar Contratos de Operacin Un contrato es un documento que describe lo que una operacin se propone lograr. Suele elaborarse en sentido declarativo, enfatizando en lo que suceder y no como se conseguir. Los contratos suelen expresarse a partir de los cambios ocurridos entre precondiciones y pos-condiciones. El contrato de operacin describe los cambios de estado del sistema total cuando se llama o ejecuta una de sus operaciones. Para preparar contratos en los casos de uso deben tenerse en cuenta las siguientes directrices: Identifique las operaciones del sistema mediante los diagramas de secuencia. Elabore un contrato para cada operacin identificada. En la plantilla del contrato, comience redactando primero la seccin de Responsabilidades describiendo informalmente el propsito de la operacin en esta seccin. A continuacin redacte la seccin Poscondiciones describiendo en forma declarativa uno a uno los cambios de estado en los objetos involucrados en la realizacin de la operacin. Estos objetos deben existir en el modelo conceptual, en caso contrario debe examinarse su inclusin a este. Utilice las siguientes categoras para describir poscondiciones: Creacin y Eliminacin de Instancias. Modificacin de Atributos. Asociaciones formadas y canceladas. Casos de Uso Expandidos y Esenciales. Vase Error: Reference source not found Diagramas de Secuencia del Sistema. Vase Error: Reference source not found Contratos de Operacin para cada Caso de Uso. Especificador de Requerimientos. (RUP 2003)
Descripcin
Entradas
Descripcin
Anlisis:: Perfeccionar el Modelo Conceptual El modelo conceptual explica los conceptos significativos en un dominio del problema; es el artefacto ms importante a crear durante el anlisis orientado a objetos. Identificar muchos objetos o conceptos constituye la esencia del anlisis orientado a objetos. Un modelo conceptual representa cosas del mundo real, no componentes de software y muestra: Conceptos, Asociaciones entre Conceptos y Atributos de Conceptos. Para identificar conceptos puede utilizarse la siguiente lista de categoras: Objetos fsicos o tangibles, Especificaciones, Diseos o Descripciones de Cosas, Lugares, Transacciones, Lnea o rengln de elemento en una transaccin, Papel de las Personas, Contenedores de otras cosas, Cosas dentro de un contenedor, Otros sistemas de computo o electromecnicos externos al sistema, Conceptos de nombres abstractos, Organizaciones, Eventos, Procesos, Reglas y Polticas, Catlogos, Registros de Finanzas, de Contratos, de Asuntos legales, Instrumentos y Servicios Financieros, Manuales y Libros.
Versin 0.5 56 DE 95
Anlisis:: Perfeccionar el Glosario Un glosario es un documento simple en el cul se definen trminos. Este incluye y define todos los trminos que requieren explicacin para mejorar la comunicacin y aminorar el riesgo de malos entendidos. Un significado uniforme y compartido resulta extremadamente importante durante el desarrollo de las aplicaciones, sobre todo cuando muchos miembros del equipo intervienen en el proyecto. Diagramas de Casos de Uso y Casos de Uso Esenciales. Diagramas de Secuencia del Sistema y Contratos de Operacin. Modelo Conceptual
Diagrama de Clases del Anlisis o Modelo Conceptual. Ver Error: Reference source not found Especificador de Requisitos. (RUP 2003) Tabla 10: Actividades del Flujo de Desarrollo durante el Anlisis
Diseo:: Elaborar IGU para Casos de Uso La Interfaz grfica de usuario es el mecanismo de interaccin que dispone el sistema en el marco de un caso de uso para aceptar eventos del actor. En esta actividad se elaboran los diseos preliminares de la (s) interfaz (ces) grfica (s) de usuario para el (los) caso (s) de uso tomados para esta iteracin.
Diagramas de Casos de Uso y Casos de Uso Esenciales. Ver Error: Reference source not found Interfaz Grfica de Usuario IGU para Casos de Uso. Ver Error: Reference source not found Diseador de Interfaz Grfica (RUP 2003)
Entradas
Diseo:: Elaborar Casos de Uso Reales. La versin Real del caso de uso, es simplemente un refinamiento de la versin extendida. En esta versin, la interaccin entre el actor y el sistema se desarrolla en el marco de una interfaz grfica de usuario. Los estmulos del actor sobre el sistema, ahora se convierten en acciones directas (clicks, arrastre, seleccin y chequeo) sobre botones, cuadros de texto, combos de seleccin, etc. Diagramas de Casos de Uso y Casos de Uso Esenciales. Interfaz Grfica de Usuario para los Casos de Uso. Diagramas de Secuencia del Sistema y Contratos de Operacin.
Salidas Roles Responsables Nombre de Actividad Descripcin Entradas Salidas Roles Responsables
Modelo Conceptual. Ver Error: Reference source not found Caso de Uso Real. Ver Error: Reference source not found Especificador de Requisitos. (RUP 2003) Diseador de Interfaces Grficas. (RUP 2003)
Diseo:: Perfeccionar Diagrama de Paquetes Los diagramas de paquetes ayudan a reducir la complejidad de la arquitectura por medio del empaquetamiento de clases en unidades lgicas (paquetes) aisladas, pero dependientes. Por medio del empaquetamiento, se puede organizar la arquitectura en vistas ms pequeas y comprensibles aumentando su Entendibilidad.
Diagrama de Clases. Ver Error: Reference source not found Diagrama de Paquetes. Ver Error: Reference source not found Diseador (RUP 2003)
Versin 0.5 57 DE 95
Descripcin
Diagrama de Clases. Ver Error: Reference source not found Diagramas de Colaboracin. Ver Error: Reference source not found Diseador. (RUP 2003)
Descripcin
Diseo:: Sincronizar los Diagramas de Clase Una vez realizados los diagramas de colaboracin (uno por cada operacin del caso de uso de turno), se deben sincronizar los diagramas de clases del diseo, creando las definiciones de operaciones en las clases involucradas en el diagrama de colaboracin, a partir de los mensajes presentes en el diagrama. Un mtodo se define para una clase, siempre que un objeto o instancia de esta, recibe un mensaje desde otro objeto o instancia presente en el diagrama de colaboracin. Por ltimo, si ya existe un intento anterior de implementar un esquema de bases de datos, es posible que tambin el diagrama de clases se refine a partir de aquel.
Entradas Salidas Roles Responsables Nombre de Actividad Descripcin Entradas Salidas Roles Responsables Nombre de Actividad Descripcin
Diagramas de Colaboracin. Ver Error: Reference source not found Esquemas de Bases de Datos. Ver Error: Reference source not found Diagrama de Clases. Ver Error: Reference source not found Diseador (RUP 2003)
Diseo:: Disear Esquemas de Bases de Datos En caso de que el sistema utilice bases de datos, deben crearse las tablas correspondientes a las clases que intervienen en los casos de uso tomados para esta iteracin.
Diagramas de Clases Ver Error: Reference source not found Diseo del Esquema de Bases de Datos. Ver Error: Reference source not found Diseador de la Base de Datos. (RUP 2003)
Diseo:: Disear Reportes A partir de los requisitos de informacin del sistema se pueden inferir los reportes deseados para este ltimo. Cada reporte debe tener un propsito bien definido. Su estructura se divide en tres grandes partes: Cabecera, Detalle y Pi. Pueden incluir grficos, tablas, formulas o condiciones lgicas. Por ltimo es muy importante que cada reporte se pueda imprimir con una alta fidelidad.
Diseo del Esquema de Bases de Datos Ver Error: Reference source not found Diagrama de Paquetes. Ver Error: Reference source not found Diseador de la Base de Datos (RUP 2003) Tabla 11: Actividades del Flujo de Desarrollo Durante el Diseo
Implementacin:: Implementar IGUs Consiste en la creacin de formularios, ventanas o cuadros de dilogo de cada caso de uso involucrado en la presente iteracin, teniendo muy en cuenta las IGUs y los casos de uso reales elaborados durante el diseo. Esta actividad se realiza en el propio entorno de desarrollo.
Entradas
IGUs Diseadas Ver Error: Reference source not found Casos de Uso Reales Ver Error: Reference source not found
Versin 0.5 58 DE 95
IGUs Implementadas Ver Error: Reference source not found Diseador de Interfaces Grficas (RUP 2003) Desarrollador (RUP 2003)
Implementacin::Definir Paquetes o Unidades en el Cdigo Esta actividad tiene como propsito fundamental, reflejar los diagramas de paquetes del diseo en el cdigo fuente. Usualmente y segn el lenguaje, cada paquete grfico se corresponder con un Package, Unit o NameSpace en el cdigo fuente. Es vital que el cdigo se corresponda fielmente con los diagramas de paquetes para guardar los atributos de correctitud, completitud y entendibilidad de la arquitectura software. Diagrama de Paquetes del Diseo Cdigo Fuente con Paquetes Definidos. Diseador. (RUP 2003) Desarrollador. (RUP 2003) Implementacin:: Implementar Definiciones de Clase y mtodos. Esta actividad tiene como propsito fundamental, reflejar los diagramas de clases del diseo en el cdigo fuente. Usualmente y segn el lenguaje, cada clase en el diagrama se corresponder con un Class en el cdigo fuente. Es vital que el cdigo se corresponda fielmente con los diagramas de clases para guardar los atributos de correctitud, completitud y entendibilidad de la arquitectura software. Por otra parte, los diagramas de colaboracin juegan un papel vital a la hora de definir la implementacin de los mtodos de una clase, en virtud de que facilitan enormemente la concepcin del cdigo fuente que pertenece a un mtodo determinado.
Descripcin
Entradas Salidas Roles Responsables Nombre de Actividad Descripcin Entradas Salidas Roles Responsables Nombre de Actividad Descripcin Entradas Salidas Roles Responsables
Diagramas de Colaboracin. Ver Error: Reference source not found Diagramas de Clase. Ver Error: Reference source not found Clases de la Implementacin. Ver Error: Reference source not found Diseador Desarrollador
Implementacin::Implementar Esquemas de Bases de Datos En caso de que el sistema utilice un mecanismo de almacenamiento persistente (Ej. Una Base de Datos), esta actividad se concentra en el mapeo del esquema de bases de datos diseado para la actual iteracin, a un esquema implementado en un motor de bases de datos elegido.
Diseo del Esquema de Bases de Datos. Ver Error: Reference source not found Esquema de Bases de Datos Implementado. Ver Error: Reference source not found Diseador de Bases de Datos. (RUP 2003)
Implementacin::Implementar Reportes En caso de que el sistema utilice un mecanismo de almacenamiento persistente (Ej. Una Base de Datos), esta actividad se concentra en la implementacin de los reportes diseados para la actual iteracin, sobre el motor de bases de datos elegido.
Diseo de Reportes. Ver Error: Reference source not found Reportes Implementados. Ver Error: Reference source not found Diseador de Bases de Datos. (RUP 2003)
Nombre de Actividad
Descripcin
Pruebas:: Planificar Pruebas y Definir Estrategias Esta actividad tiene como propsito fundamental, la identificacin de informacin y componentes de software del proyecto que se eligen durante esta iteracin para las pruebas, la enumeracin de los requerimientos para realizar las pruebas, recomendar y describir las estrategias de pruebas que se emplearan, identificar los recursos y esfuerzo requeridos para realizar las pruebas y finalmente enumerar los productos entregables al final de las pruebas. Por otra parte, la estrategia de pruebas define: Las herramientas y tcnicas que se usarn. Los criterios de finalizacin exitosa de las pruebas.
Versin 0.5 59 DE 95
Pruebas::Ejecutar Pruebas Consiste en implementar las pruebas sobre los componentes de software elegidos para esta iteracin, aplicando las estrategias concebidas. Modelo del Anlisis Modelo del Diseo Modelo de la Implementacin. Plan de Pruebas de la Iteracin.
Registro de los Resultados de las Pruebas. Ver Prototipo Error: Reference source not found Ingeniero de Pruebas
Pruebas:: Evaluar Pruebas Consiste en la consolidacin, sntesis e interpretacin de los resultados de las pruebas con el objeto de fundamentar la toma de decisiones relacionadas con el rediseo o no de la arquitectura. De la satisfaccin de estos resultados depende que el incremento de software sea publicado o no en la plataforma. Registro de los Resultados de las Pruebas.
Interpretacin de Resultados. Ver Prototipo Error: Reference source not foundb Analista de Pruebas
Descripcin
Pruebas::Publicar en la Comunidad el Incremento de Software Con base en la interpretacin de resultados de las pruebas, se valora la estabilidad y calidad del producto o incremento software desarrollado para la actual iteracin. Si el producto satisface los requerimientos funcionales y no funcionales tomados durante la iteracin, entonces se publica a toda la comunidad para ser integrado como un componente software estable que hace parte del producto final. En caso contrario, se inicia nuevamente desde la sub-disciplina del anlisis-diseo-implementacin para corregir los defectos descubiertos durante las pruebas. Interpretacin de Resultados. Incremento Software Equipo (i+d) Tabla 13: Actividades del Flujo de Desarrollo Durante las Pruebas
1.12.5. Artefactos Los artefactos elaborados, refinados o involucrados durante la ejecucin de las actividades de esta disciplina se relacionan en la siguiente tabla: No. 1 2 3 3 Nombre Diagrama de Casos de Uso Caso de Uso (Alto Nivel) Caso de Uso (Expandido) IGU Propsito Mostrar los casos de uso del sistema y la relacin con sus actores. Especifica brevemente la historia de interaccin entre los actores y el caso de uso. Extiende la declaracin del caso de uso de alto nivel, incluyendo escenarios y excepciones. Representa la interfaz grfica de usuario para la interaccin en el marco de uno o varios casos de uso. Especificado en Error: Reference source not found Error: Reference source not found Error: Reference source not found Error: Reference source not found
Versin 0.5 60 DE 95
Contratos de Operaciones
8 9
10
Diagrama de Paquetes
11
Error: Reference source not found Error: Reference source not found Error: Reference source not found Error: Reference source not found Error: Reference source not found Error: Reference source not found Error: Reference source not found
12 13 14 15 16 17
Reportes Diccionario de Datos Plan De Pruebas de la Iteracin Registro Resultados de Pruebas Interpretacin de Resultados de Pruebas Incremento Software
Tabla 14: Artefactos de la Disciplina Desarrollo 1.12.6. Arquitectura Con el propsito de facilitar la lectura del presente documento, el lector encontrar la arquitectura de esta disciplina en el Error: Reference source not found, especficamente en la ruta siguiente:
Anexos\Anexo5_Modelo_Documentacion\Agile_DISOP\Anexos\Disciplina_Desarrollo.mdl.
1.12.7. Premisas
Versin 0.5 61 DE 95
Es fundamental que exista un modelo de documentacin que permita instrumentar esta disciplina. Se recomienda la estructura de directorios del Error: Reference source not found. All se muestra la ubicacin exacta de los artefactos de esta disciplina en el marco de una iteracin para cualquier fase del proceso. La idea es que con cada nueva iteracin, el usuario de Agile-DISOP, slo replicar el sub-directorio Iteracin12, logrando con esto, alcanzar una estructura de documentacin uniforme para todos los proyectos que emprenda la comunidad.
1.12.8. Mtricas Las mtricas recomendadas para empezar son las descritas en el Error: Reference source not found e implementadas en el Error: Reference source not found. 1.12.9. Mtodos Se recomiendan los mtodos orientados a objetos para las sub-disciplinas de: Anlisis, Diseo, Implementacin y Pruebas. 1.13. DISCIPLINA: MEJORAMIENTO DE AGILE-DISOP 1.13.1. Propsito Esta disciplina tiene como objeto fundamental, la concepcin y puesta en marcha de mecanismos eficaces para emprender un esfuerzo de mejoramiento contnuo sobre el mismo proceso de desarrollo de Agile-DISOP. Se ha determinado que el modelo de mejora IMPACT13 (Scott 2002 ) es un buen punto de partida para, concebir el modelo de mejora para Agile-DISOP, principalmente porque presenta caractersticas clave para que pequeas organizaciones14 lo puedan adoptar iterativa e incrementalmente con poca inversin y esfuerzo alcanzndoles resultados tangibles en un tiempo razonable. 1.13.2. Conceptos Los conceptos involucrados en esta disciplina son: rea de Mejora, Estrategia de Mejora, Gua del Proceso. Para encontrar las definiciones correspondientes a los anteriores conceptos favor referirse al Error: Reference source not found. 1.13.3. Flujo de Trabajo Como puede observase en la Figura 26: Flujo de Trabajo para el Mejoramiento del Proceso, se consideran dos niveles para el proceso de mejoramiento del mismo Agile-DISOP. En primer lugar se especifica el nivel del proyecto (la parte derecha) que es donde se escogen las reas que son objetivo del mejoramiento, luego las estrategias implementadas son valoradas por su impacto en el desempeo del proyecto. En el nivel del proceso, las estrategias exitosas son incorporadas y propagadas a nuevos proyectos que emprenda la comunidad. (Espacio en blanco intencional para mantener el formato del documento)
12 13
Asignndole el nmero de iteracin al directorio recin creado. Especificado en el numeral Error: Reference source not found 14 Equivalentes a los equipos (i+d) geogrficamente dispersos en una comunidad de desarrollo.
Versin 0.5 62 DE 95
2
1 N ivel de N ivel de PP roceso roceso
N ivel de P royecto
Planear reas de Mejora
Gestin del Entorno Ejecutar Proyecto Nivel de Proyecto Ejecutar Estrategias de Mejora
Figura 26: Flujo de Trabajo para el Mejoramiento del Proceso 1.13.4. Actividades La descripcin de las actividades de la Figura 26: Flujo de Trabajo para el Mejoramiento del Proceso se especifica a continuacin: NIVEL DEL PROCESO Gestin del Entorno Su especificacin corresponde al flujo de trabajo descrito en el numeral 1.9.3 Agile-DISOP (General) Agile-DISOP (Especfico) Ingeniero de Procesos Nivel de Proyecto Su especificacin corresponde al flujo de trabajo mostrado en la Figura 26: Flujo de Trabajo para el Mejoramiento del Proceso en la seccin derecha Nivel de Proyecto. Ninguna. Ninguna. Ingeniero de Procesos y Equipo (i+d) responsable del Proyecto. Incorporar estrategias de mejora Consiste en refinar el proceso de desarrollo al reemplazar prcticas actuales por otras ms refinadas y maduras que demostraron beneficios durante la aplicacin en uno o
Nombre de Actividad Descripcin Entradas Salidas Roles Responsables: Nombre de Actividad Descripcin Entradas Salidas Roles Responsables: Nombre de Actividad Descripcin
Versin 0.5 63 DE 95
A continuacin, se especifican las actividades relacionadas con el flujo de trabajo del Proyecto: NIVEL DEL PROYECTO Planear reas de Mejora Consiste en determinar sobre que reas del Agile-DISOP se enfatizar para aplicar un enfoque de mejora. Por ejemplo: Para el proyecto actual, se enfocar en estandarizar toda la documentacin del proceso o se implementar un modelo para el monitoreo y control de los riesgos. En concreto cada rea de mejora se puede enfocar en el refinamiento iterativo e incremental de cada una de las prcticas recomendadas por Agile-DISOP numerales 1.4.1 a 1.4.11 y/o las disciplinas especificadas en los numerales 1.9 a 1.14. Plan de Mejoramiento (En Blanco) Plan de Mejoramiento (Enuncia las reas de Mejora que son objetivo) Ingeniero de Procesos Ejecutar Proyecto
Nombre de Actividad
Descripcin
Entradas Salidas Roles Responsables Nombre de Actividad Descripcin Entradas Salidas Roles Responsables Nombre de Actividad Descripcin Entradas Salidas Roles Responsables Nombre de Actividad Descripcin Entradas Salidas Roles Responsables Nombre de Actividad Descripcin
La especificacin de esta actividad se encuentra en la Disciplina de Gestin del Proyecto numeral 1.11.3, Figura 21: Flujo de Trabajo para la Gestin del Macro-Proyecto, Figura 22: Flujo de Trabajo para el Modelo de Gestin en un SubProyecto y numeral 1.11.4. Ninguna Sub-Proyecto Finalizado / Sub-Proyecto Cancelado
Ejecutar Estrategias de Mejora Consiste en aplicar las estrategias de mejora sobre las reas seleccionadas para mejoramiento mientras se est ejecutando el proyecto de desarrollo.
Plan de Mejoramiento (Enuncia las reas de Mejora que son objetivo) Ninguna Ingeniero de Procesos
Evaluar Impacto de las Estrategias de Mejora Consiste en la valoracin de los impactos (positivos o negativos) derivados de la aplicacin de las estrategias sobre las reas del Agile-DISOP seleccionadas para mejoramiento. Esta valoracin debe presentar informacin estadstica relacionada con variaciones sobre el esfuerzo, el costo, la calidad, el tiempo entre otros.
Informe de Valoracin sobre las Estrategias de Mejora (En Blanco) Informe de Valoracin sobre las Estrategias de Mejora (Diligenciado) Ingeniero de Procesos
Formalizacin de las Estrategias de Mejora Consiste en la estandarizacin de las estrategias de mejora con el propsito de permitir
Versin 0.5 64 DE 95
Documento Formalizacin Estrategias de Mejora (En Blanco) Documento Formalizacin Estrategias de Mejora (Diligenciado) Ingeniero de Procesos
Tabla 16: Actividades del Nivel del Proyecto para el Modelo de Mejora 1.13.5. Artefactos Los artefactos elaborados, refinados o involucrados durante la ejecucin de las actividades de esta disciplina se relacionan en la siguiente tabla: No. 1 2 3 4 5 Nombre Proceso Agile-DISOP Gua Global de Agile-DISOP Plan de Mejoramiento Informe Valoracin sobre las Estrategias de Mejora Documento Formalizacin de las Estrategias de Mejora Propsito Proceso gil para Desarrollo en Comunidad. Documentacin del Proceso que incluye un esquema para seguirlo. Determina que reas se van a mejorar durante un proyecto cualquiera. Determina que impacto tuvo el hacer realidad una mejora dentro de cualquier proyecto. Estandariza las reas de mejora en nuevas prcticas, nuevos artefactos, nuevos flujos de trabajo etc. Especificado en Error: Reference source not found Error: Reference source not found No Disponible No Disponible No Disponible
Tabla 17: Artefactos de la Disciplina Mejoramiento del Proceso 1.13.6. Arquitectura Como puede apreciarse en la figura siguiente, la relacin entre el proceso Agile-DISOP y los proyectos creados a partir de este, tiene implcita informacin correspondiente a las reas de mejora que se proponen de ida para cada proyecto y de vuelta se incorporan al proceso.
Versin 0.5 65 DE 95
La gua del proceso Agile-DISOP, debe estar publicada en la plataforma de integracin u otra plataforma de gestin de contenidos (se recomienda Moodle [8]) con el objeto de facilitar la referencia y consulta por parte de los miembros de la comunidad de desarrollo.
Es fundamental que exista un modelo de documentacin que permita instrumentar esta disciplina. Se recomienda la estructura de directorios del Anexo 5. All se muestra la ubicacin exacta de los artefactos de esta disciplina en el marco de una iteracin para cualquier fase del proceso. La idea es que con cada nueva iteracin, el usuario de Agile-DISOP, slo replicar el sub-directorio Iteracin, logrando con esto, alcanzar una estructura de documentacin uniforme para todos los proyectos que emprenda la comunidad.
1.14. DISCIPLINA: GESTION DEL CAMBIO DE AGILE-DISOP 1.14.1. Propsito Esta disciplina es conforme a la prctica sugerida en el numeral 1.4.8 y su objeto fundamental consiste en: Garantizar la integridad de todos los artefactos del proyecto a medida que estos evolucionan con el devenir de su ejecucin. Asegurar la completitud y correctitud de los modelos con el producto en desarrollo. Proveer un entorno estable para desarrollar sin conflictos.
Versin 0.5 66 DE 95
Actualizacin simultnea sobre los artefactos sin soporte automtico de control de versiones. Cuando dos o ms miembros de un equipo, trabajan de forma separada, posiblemente desde ubicaciones geogrficamente distantes y hasta de forma asncrona, sobre el mismo artefacto, los ltimos cambios hechos, sobrescribirn a los anteriores, generando conflictos entre los responsables del artefacto y ralentizando el proceso de desarrollo.
Notificacin de cambios importante no propagada. Cuando un problema importante es resuelto en artefactos compartidos entre varios desarrolladores sin el soporte de un sistema de gestin del cambio, esta solucin no ser notificada a todos los interesados.
Versiones Mltiples. La mayora del software es desarrollado de forma iterativa e incremental, liberando ocasionalmente versiones del mismo. As, una versin del software puede estar en el entorno de cliente, mientras que otra esta en etapa de pruebas o desarrollo. que controle los cambios. Si se encuentran problemas en alguna de estas versiones, sus soluciones deben ser propagadas a todas las dems. La confusin puede acarrear costos y trabajo innecesarios si no se cuenta con un sistema
1.14.2. Conceptos Los conceptos involucrados en esta disciplina son: Correctitud, Completitud, Artefacto, Sistema de Gestin del Cambio, Solicitud de Cambio, Orden de Cambio. Para encontrar las definiciones correspondientes a los anteriores conceptos favor referirse al Error: Reference source not found. 1.14.3. Flujo de Trabajo En el flujo de trabajo de la Figura 28, las solicitudes de cambios sobre las caractersticas del producto software en desarrollo van pasando por un proceso continuo y gestionado de envo refinamiento, revisin, aprobacin o rechazo. Si estas solicitudes son aprobadas, entonces el responsable (Gestor del Cambio) deber planificar el esfuerzo, tiempo y coste que implica integrar el cambio dentro de la iteracin actual y finalmente asignar a un responsable que integre el cambio aprobado en la solicitud y dentro de la iteracin.
Versin 0.5 67 DE 95
[Duplicado o no V lido]
[N o Duplicado y Vlido]
[Aprobado] [Rechazado]
Figura 28: Flujo de Trabajo de la Gestin del Cambio 1.14.4. Actividades A continuacin se especifican las actividades contenidas en el flujo de trabajo de la Figura 28:
Nombre de Actividad
Descripcin
Envo / Refinamiento de una Solicitud de Cambio Esta actividad tiene como propsito el registro de una solicitud de cambio, la cul puede incluir: Nuevas caractersticas para el sistema o mejora de las existentes. Correccin o cambio en los requerimientos. Correccin, refinamiento o cambio en cualquier modelo o documento. Cualquier Rol, puede enviar una solicitud de cambio como actividad cotidiana dentro del ciclo de vida del proyecto.
Entradas Salidas Roles Responsables Nombre de Actividad Descripcin Entradas Salidas Roles Responsables
Confirmar Duplicidad y/o Validez de la Solicitud de Cambio El propsito de esta actividad consiste en confirmar si una solicitud de cambio est duplicada (ya se ha hecho antes) o si es vlida.
Solicitud de Cambio (Diligenciada) Solicitud de Cambio (Diligenciada y Validada) Gestor Control de Cambios
Versin 0.5 68 DE 95
Solicitud de Cambio (Diligenciada y Validada) Plan de Iteracin Solicitud de Cambio (Diligenciada, Validada y Aceptada Rechazada) Gestor Control de Cambios
Asignar Responsable a Solicitud de Cambio El propsito de esta actividad consiste en acomodar los cambios aprobados tanto al proceso como al producto a medida que se van dando en una iteracin mediante la asignacin de esta responsabilidad al Director del Proyecto.
Entradas
Solicitud de Cambio (Diligenciada, Validada y Aceptada) Plan de Iteracin. Plan de Proyecto. Plan de Iteracin (Ajustado al cambio aprobado) Plan de Proyecto (Ajustado al cambio aprobado) Orden de Cambio Director del Proyecto Tabla 18: Actividades de la Gestin del Cambio
1.14.5. Artefactos Los artefactos elaborados, refinados o involucrados durante la ejecucin de las actividades de esta disciplina se relacionan en la siguiente tabla: No. 1 2 3 4 Nombre Solicitud de Cambio Plan de Iteracin Propsito Registra una solicitud de cambio Especificado en Error: Reference source not found
Artefacto que estima los recursos, productos, tiempo, esfuerzo y Error: Reference source personal para llevar a cabo una not found iteracin. Igual que el anterior pero para todo el Error: Reference source Plan de Proyecto proyecto. not found Emite una orden para realizar un Error: Reference source Orden de Cambio cambio por el que alguien responder. not found Tabla 19: Artefactos de la Disciplina Gestin del Proyecto
1.14.6. Arquitectura En la siguiente figura se ilustra cmo cualquier rol puede solicitar un cambio dentro de cualquier iteracin. Esta solicitud se estudia y es asignada a cualquier rol para su implementacin. Las solicitudes y realizaciones de los cambios, afectan el estado global de la iteracin misma, principalmente porque un cambio realizado significa modificacin en uno o ms artefactos en cualquiera de las disciplinas de Agile-DISOP.
Versin 0.5 69 DE 95
Figura 29: Arquitectura de la Gestin del Cambio 1.14.7. Premisas La comunidad de desarrollo debe soportar las actividades derivadas de la gestin del cambio mediante el uso de una herramienta software que automatice el control de las versiones para cada uno de los artefactos generados durante el proyecto por la comunidad de desarrollo. Se recomienda la herramienta de control de versiones CVS (http://www.cvs.org), cuya distribucin es libre y funciona sobre web. 1.15. PLATAFORMA DE INTEGRACION PARA LA COMUNIDAD Segn lo recomendado en la prctica 1.4.9 es crucial para soportar la consolidacin de la comunidad de desarrollo, la promocin y uso de una herramienta de integracin basada en las TIC para mitigar los efectos devastadores que puede ocasionar la dispersin geogrfica sobre la gestin, coordinacin y control de los equipos de desarrollo y proyectos en comunidad. El proceso de seleccin de la plataforma orientada hacia la integracin para la comunidad cubri un conjunto de actividades que comprendieron desde el estudio y comparacin de algunas herramientas para el soporte a la gerencia de proyectos disponibles en el mercado hasta la seleccin, configuracin y puesta en marcha de la plataforma de integracin escogida. A continuacin se presenta una exploracin de herramientas previa a la seleccin de la plataforma de integracin. 1.15.1. Exploracin de Herramientas para la gerencia de proyectos Esta exploracin se concentro en analizar las caractersticas ms significativas (positivas y negativas) de algunas de las
herramientas para la gerencia de proyectos que estn disponibles en el mercado. Al final se provee una comparacin acerca de las herramientas tratadas con el propsito de determinar un conjunto de criterios que permitan la seleccin de una herramienta que brinde soporte a la ejecucin de proyectos en comunidad.
Versin 0.5 70 DE 95
Versin 0.5 71 DE 95
Figura 30: Interfaz de FastTrack Puntos en Contra. El software permite que se creen enlaces incorrectos entre tareas o entre fases del proyecto. No brinda soporte a la integracin de la comunidad de desarrollo, pues sus servicios solo se limitan al monitoreo y control de un proyecto, no permitiendo la interaccin de los miembros de una comunidad de desarrollo a travs de una intranet o Internet. Al ser software propietario, sus requerimientos de hardware, software y su costo, pueden llegar a ser prohibitivos para algunos usuarios de la comunidad. Finalmente debe instalarse en cada computador que haga para de la comunidad, pero sin la facilidad para compartir datos entre ellos, dando lugar a situaciones donde exista informacin redundante. 1.15.1.2. Task Manager Task Manager es un software que brinda soporte al gerenciamiento de proyectos y un ejemplo de su interfaz se ilustra en la Figura 31. Este software fue desarrollado por OrbiSoft (http://www.orbisoft.com), la versin estudiada fue la 1.00.729. Puntos a Favor.
Versin 0.5 72 DE 95
Versin 0.5 73 DE 95
Figura 31: Interfaz de Task Manager No brinda soporte a la integracin de la comunidad de desarrollo, pues sus servicios solo se limitan al monitoreo y control de un proyecto, no permitiendo la interaccin de los miembros de una comunidad de desarrollo a travs de una intranet o Internet. Al ser software propietario, sus requerimientos de hardware, software y su costo, pueden llegar a ser prohibitivos para algunos usuarios de la comunidad. 1.15.1.3. Delegator Delegator es mucho ms que un software de gerenciamiento de proyectos, cuya interfaz se muestra en la Figura 32. Este software fue desarrollado por Madrigal Soft Tools Inc, (http://www.madrigalsoft.com) con sede en Canad. La versin demo utilizada fue desarrollada en el 2000 y actualmente se encuentra en la versin 3.0. Puntos a Favor. Delegator fue concebido especialmente para gerentes y dems personas que coordinan y administran las actividades de otras. Delegator ayuda a localizar las diversas tareas asignadas a los miembros del equipo, determinar la carga de trabajo del personal y su desempeo. Utiliza grfico de Gantt con el propsito de visualizar las tareas, y sus responsables con la capacidad de ajustar la escala de tiempo deseada (das, semanas, meses o trimestre).
Versin 0.5 74 DE 95
Como punto principal se resaltan los tres planos del cronograma que son dispuestos en el grafico de Gantt (ver Figura 32), la barra en amarillo se refiere a la planificacin temporal inicial especificada por el gerente para una determinada tarea, la barra roja se refiere a una planificacin temporal mas reciente especificada por el gerente, finalmente la barra de color azul, indica la ejecucin temporal real realizada por el grupo responsable de la tarea. A travs de estos tres planos, es posible realizar un comparativo de la ejecucin temporal de las tareas desde su concepcin hasta su conclusin.
Mediante esta herramienta es posible generar informes acerca del desempeo histrico para: personas, equipos y proyectos entre otros. Todos los informes se pueden configurar por parte del usuario, mediante parmetros relativos a las fechas de inicio y finalizacin.
Puntos en Contra. Falta de interactividad con el grafico de Gantt debido a que las tareas dispuestas en el grafico, solo aceptan entrada de datos de forma textual. Adems de esto, no permite establecer dependencia entre tareas. No brinda soporte a la integracin de la comunidad de desarrollo, pues sus servicios solo se limitan al monitoreo y control de un proyecto, no permitiendo la interaccin de los miembros de una comunidad de desarrollo a travs de una intranet o Internet. Al ser software propietario, sus requerimientos de hardware, software y su costo, pueden llegar a ser prohibitivos para algunos usuarios de la comunidad.
Versin 0.5 75 DE 95
Figura 32: Interfaz Delegator 1.15.1.4. AlexSys Team Alexsys Team es un sistema de administracin de equipos para Windows que organiza el trabajo de un grupo humano dentro de una organizacin. La interfaz de esta herramienta se muestra en la Figura 33. Puntos a Favor. El equipo puede definir tareas de forma colectiva y auto-organizarse para ejecutarlas. Tambin, el equipo puede detectar cuando una tarea no se esta ejecutando segn lo planeado.
Durante la instalacin, se copian dos bases de datos: una en blanco y una de muestra. La base de datos en blanco, permite a los gerentes de la organizacin, registrar el trabajo de sus subordinados, mientras que la base de datos de muestra, provee un conjunto de ejemplos que indican las posibilidades de la herramienta.
La informacin pertinente a todas las actividades se registra en tablas anexas que posteriormente son referenciadas dentro de la estructura de cada actividad. Adems, es posible enviar informacin de una tarea a otra persona del proyecto mediante el uso del correo electrnico.
Se destaca la flexibilidad en la configuracin del ambiente de trabajo para ajustarse al estilo del usuario. Por otra parte, es sencilla la creacin y almacenamiento de grficos (con varios estilos) y reportes con base en cualquier informacin almacenada en la base de datos del sistema.
Versin 0.5 76 DE 95
Figura 33: Interfaz de AlexSys Team Puntos en Contra. No existe un grafico (Gantt o PERT) que brinde soporte a la gerencia de tareas y del cronograma, de tal forma que el gerente no puede visualizar la distribucin de las tareas con relacin al tiempo del proyecto. La herramienta tan solo provee un listado de tareas. No brinda soporte a la integracin de la comunidad de desarrollo, pues sus servicios solo se limitan al monitoreo y control de un proyecto, no permitiendo la interaccin de los miembros de una comunidad de desarrollo a travs de una intranet o Internet. Al ser software propietario, sus requerimientos de hardware, software y su costo, pueden llegar a ser prohibitivos para algunos usuarios de la comunidad. 1.15.1.5. MS-Project MS-Project es una herramienta para la gerencia, organizacin y control de proyectos. Para el anlisis se utilizo la versin 2003 sin restricciones. La interfaz de MS-Project se muestra en la Figura 34. Puntos a Favor.
El propsito fundamental de MS-Project consiste en apoyar la gerencia de las tareas en funcin del tiempo. Soporta grficos de Gantt para la visualizacin de tareas, las cuales se representan mediante barras (interactivas) cuya longitud esta directamente relacionada con la duracin de la tarea. En cada tarea se especifica informacin relacionada con el inicio y finalizacin de la misma la cual puede ser accesada directamente sobre las barras graficas de tareas en el diagrama de Gantt.
Versin 0.5 77 DE 95
Figura 34: Interfaz de MS-Project Antes de que ocurran problemas relativos a conflictos en la planificacin temporal, este software implementa una funcionalidad para detectarlos.
Implementa una lnea base que contiene estimaciones originales de costos, recursos y planificacin temporal. Al comparar, las estimaciones de la lnea base con la ejecucin actual, se pueden adaptar la planificacin entera del proyecto.
Se pueden publicar en formato HTML, informacin de inters para el equipo humano que ejecuta el proyecto. Adems se facilita la utilizacin del e-mail como medio para el envo/recepcin de mensajes entre los integrantes del equipo. El asunto de cada mensaje puede variar entre: asignacin, aceptacin, rechazo, actualizacin o informe de avance para cualquier tarea.
Provee flexibilidad en la generacin de informes acerca del proyecto. Existen ms de veinte (20) tipos de informes. Presenta inter-operabilidad con Project Server la cual le permite exportar y compartir informacin para todo el equipo de desarrollo en el Web.
Puntos en Contra.
Versin 0.5 78 DE 95
Al ser software propietario, sus requerimientos de hardware, software y su costo, pueden llegar a ser prohibitivos para algunos usuarios de la comunidad. Finalmente para acceder a los servicios que le permiten compartir informacin a travs de la Web, es necesario instalar otras herramientas propietarias que aumentan todava mas el costo y complejidad del software de la plataforma de integracin para cada equipo (i+d) de la comunidad de desarrollo.
1.15.1.6. SuperProject SuperProject es una herramienta software concebida para la gerencia de proyectos, producida por Computer Associates, cuya interfaz puede observarse en la Figura 35. El software utilizado fue la versin 4.0 sin ninguna restriccin. Esta herramienta se compone de dos mdulos. El primero, denominado Application Program Interface se concentra en la gestin de proyectos. El segundo, denominado CARealizer ofrece un lenguaje para la creacin de macros. Puntos a Favor. Este software permite la gestin de recursos, costo y tiempo de los proyectos, mediante grficos de Gantt y/o PERT. Ofrece la posibilidad de la generacin de proyectos a partir de plantillas. SuperProject es bastante verstil para la elaboracin de informes. Adems, permite ajustar la unidad de tiempo a las necesidades del gerente de proyecto. Adems, provee diversas perspectivas por ejemplo: la utilizacin de recursos, costos involucrados, especificacin de tareas entre otras. Permite incluir sub-proyectos o establecer enlaces entre proyectos asociados externos. Puntos en Contra. No brinda soporte a la integracin de la comunidad de desarrollo, pues sus servicios solo se limitan al monitoreo y control de un proyecto, no permitiendo la interaccin de los miembros de una comunidad de desarrollo a travs de una intranet o Internet. Al ser software propietario, sus requerimientos de hardware, software y su costo, pueden llegar a ser prohibitivos para algunos usuarios de la comunidad. La capacidad de definir proyectos y sub-proyectos solo esta disponible para archivos sobre la misma maquina.
Versin 0.5 79 DE 95
Figura 35: Interfaz de SuperProject 1.15.1.7. SourceForge. NET SourceForge.net es la plataforma web cuya interfaz puede observarse en la Figura 36. Esta plataforma rene a la comunidad ms grande del mundo para desarrollo de software libre. Puntos a Favor. Actualmente soporta ms de 100.000 proyectos y sobrepasa el milln de usuarios, proporcionando una plataforma de servicios para la gestin de proyectos, de equipos y cdigo.
Esta plataforma provee hospedaje gratuito para proyectos de desarrollo de cdigo abierto, el cul tiene como esencia, la rpida creacin de soluciones bajo un ambiente colaborativo que comparten los desarrolladores y usuarios finales, los cules buscan la calidad y viabilidad del software a largo plazo.
Puntos en Contra.
Sin embargo, el proceso de registro y adquisicin de cuentas de usuario resulto complicado y poco confiable como para ser extendido a la comunidad con buena aceptacin.
Versin 0.5 80 DE 95
1.15.1.8. PHProjekt La interfaz de esta plataforma de cdigo abierto puede observarse en la Figura 37, la cul permite la gestin de proyectos a travs de la Web, orientada hacia equipos que pueden estar geogrficamente distribuidos conformando una comunidad. Puntos a Favor.
Ofrece los servicios de: Calendario, Base de Datos de Contactos, Foro, Archivos (descarga y publicacin), proyectos (diagrama de gantt y filtros), timecard (para administrar presupuestos), notas, RTS (Sistema de rastreo de solicitudes), Correo y Administracin. componentes. La versin utilizada fue la 4.2, la cul posee la capacidad de integrar la mayora de
Puntos en Contra.
Su uso no resulto sencillo y la estabilidad de la herramienta no resulto satisfactoria debido a las tremendas diferencias de compatibilidad de la versin 4.2 y sus sucesores.
Versin 0.5 81 DE 95
Figura 37: Interfaz de PHPROJEKT 1.15.1.9. DOTProject Esta plataforma cuya interfaz puede observarse en la Figura 38, permite la gestin de proyectos que nace como alternativa a los costosos productos de Microsoft y otras herramientas disponibles en el mercado. Puntos a Favor.
Interfaz de usuario simple y consistente, funcionalidad para la gestin de proyectos, libre uso-acceso y de cdigo abierto. Algunos servicios de la plataforma incluyen: Gestin de Usuarios, E-mail, Gestin de informacin de clientes y compaas, listado de proyectos, listado jerrquico de tareas, Repositorio de Archivos, Lista de Contactos, Calendario, Foro, Acceso restringido a los recursos.
Puntos en Contra.
Versin 0.5 82 DE 95
La capacidad de especificar una lnea base, es ofrecida por apenas tres herramientas: MS-Project, DotProject y Delegator.
Respecto a los informes, se destacan MS-Project y Alexys Team que ofrecen a sus usuarios una gran variedad y flexibilidad.
Si bien cada herramienta ofrece ayuda en lnea para asistir al usuario en el uso de la misma, se destaca MS-Project la cual provee algunos tpicos especiales respecto de la gestin de proyectos.
Con relacin al soporte del trabajo en grupo bajo un ambiente de dispersin geogrfica, apenas cuatro (4) herramientas ofrecen algn soporte. MS-Project permite la exportacin y publicacin de informacin relacionada con uno o varios proyectos; adems la comunicacin entre los miembros del equipo mediante la automatizacin del correo electrnico. Sin embargo requiere la interoperabilidad de herramientas como Project Server e Internet Information Server, instaladas sobre una plataforma de servidor Windows. No ofrece servicios de comunicacin como los foros, calendarios personales o grupales, help-desk, mensajes instantneos, Chat, ni repositorio de documentos controlado por versiones.
Desde el punto de vista de costo, interoperabilidad y disponibilidad en Internet solo tres (3) plataformas SOURCEFORGE.Net, PHPROJEKT y DOTProject ofrecen una integracin entre la gestin de proyectos y la coordinacin y comunicacin de equipos geogrficamente dispersos.
Versin 0.5 83 DE 95
Contrasea: syncmaster793s
Versin 0.5 84 DE 95
Una red nacional de grupos de investigacin del ms alto nivel, articulada alrededor de un programa comn de trabajo en un rea cientfica y tecnolgica considerada como estratgica para el pas. Cada uno de los grupos que hagan parte de un Centro de Excelencia deben, adems de estar reconocidos o en proceso de reconocimiento al 2005, desarrollar investigacin de frontera en permanente contacto con entidades pares internacionales, apoyar la formacin de recursos humanos en los niveles de maestra y doctorado, transferir el conocimiento generado al sector productivo, presentar los resultados de su trabajo en publicaciones internacionales indexadas y estar comprometidos en los procesos de proteccin de la propiedad intelectual y el patentamiento. En el marco de esta convocatoria, podrn participar tres (3) o ms Grupos de Investigacin Cientfica o Tecnolgica del pas reconocidos por COLCIENCIAS, en forma conjunta a travs de la conformacin, por parte de las entidades o instituciones que los avalan (Universidades, Institutos, Centros de Investigacin y Centros de desarrollo Tecnolgico), de consorcio o unin temporal para la adjudicacin, celebracin y ejecucin del contrato objeto de la presente convocatoria. Las entidades o instituciones que avalen a los Grupos de Investigacin Cientfica o Tecnolgica participantes, debern estar habilitadas jurdicamente para participar en convocatorias, invitaciones o concursos y para celebrar contratos con COLCIENCIAS. Para los efectos de la presente convocatoria se entender como Grupo de Investigacin Cientfica o Tecnolgica, el conjunto de personas que se renen para realizar investigacin en una temtica dada, formulan uno o varios problemas de su inters, trazan un plan estratgico de largo o mediano plazo para trabajar en l y producen unos resultados de conocimiento sobre el tema en cuestin. Un grupo existe siempre y cuando demuestre produccin de resultados tangibles y verificables fruto de proyectos y de otras actividades de investigacin convenientemente expresadas en un plan de accin (proyectos) debidamente formalizado.
Al respecto, el autor del presente trabajo, ha realizado una propuesta que encaja en el macro proyecto planteado por GTI3, denominado CEDUSOC15, elaborado con motivo de esta convocatoria. Con el propsito de facilitar la lectura de este documento, se ha dispuesto el Error: Reference source not found cuyo contenido consiste en un resumen de la visin del Centro de Excelencia propuesto por el GTI 3, sus proyectos, investigadores y grupos, al mismo tiempo que exhibe la propuesta para el desarrollo de un Entorno de Soporte a la Ingeniera del Software en Comunidad, denominado SEDISE (en ingls Support Environment for Distributed Software Engineering), cuyo propsito fundamental consistir en apoyar el trabajo de la comunidad nacional de dinmica de sistemas y pensamiento sistmico, durante el desarrollo del ESMS-MI, entre otros
15
MODELO DE INTEGRACIN DE LAS TIC AL DESARROLLO EDUCATIVO COLOMBIANO EN EL MARCO DE LA SOCIEDAD DEL CONOCIMIENTO
Versin 0.5 85 DE 95
Versin 0.5 86 DE 95
Elaborar los requerimientos funcionales y disear la arquitectura base, para un ESMS de modelos integrados, cuyo punto de partida consiste en las arquitecturas software de las herramientas desarrolladas por el grupo SIMON[14] de la escuela de ingeniera de sistemas de la UIS[19].
Se hizo necesario realizar una investigacin exhaustiva sobre Anlisis y Evaluacin Arquitectnica, la cul, arroj una metodologa de diez (10) etapas y la armonizacin de un modelo de mtricas para la arquitectura, que exigi alrededor de 115 (Horas/Hombre). Es importante destacar que mediante la metodologa concebida, se valor la calidad arquitectnica de una herramienta real17, desarrollada desde hace ms de doce (12) aos al interior del grupo (i+d) SIMON de la UIS. Dicha herramienta con un tamao de 59.277 lneas de cdigo18 fue valorada mediante un modelo de hasta 38 mtricas propuestas por diversos autores y agrupadas por atributos de tamao, herencia, encapsulamiento y complejidad, tambin, se aplicaron 4 heursticas de diseo arquitectnico para determinar problemas relacionados con la Completitud, Correctitud, Nombrado y Estilo. aspectos de la herramienta. Esta valoracin implic un esfuerzo de 200 (horas/hombre) arrojando un total de 31.503 datos dispuestos en 2.184 registros que se organizaron en 20 Por otro lado, con un esfuerzo de 37 (horas/hombre) se encontraron hasta 4.407 problemas Ms adelante y luego de cuatro (4) iteraciones y 159 arquitectnicos de los cules 4.179 problemas se resuelven en la nueva arquitectura del ESMS-MI, quedando 228 problemas que requieren de la atencin de los desarrolladores an sin resolver. (horas/hombre), la arquitectura resultante con un total de: 6 Diagramas de Casos de Uso, 33 Diagramas de Paquetes, 239 Diagramas de Clases, 1 Diagrama de Componentes, 77 Casos de Uso, 448 clases y 245 paquetes, refleja el espritu inicial de los desarrolladores de EVOLUCION 3.5 organizando todos los aspectos de la herramienta de forma que el cdigo fuente y el modelo se correspondan mutuamente sin distorsiones favoreciendo la completitud y correctitud de la arquitectura del ESMS-MI. Adems el nuevo modelo arquitectnico propone en primer lugar, un conjunto de requisitos funcionales y no funcionales para extender la funcionalidad de EVOLUCION 3.5 hacia el nuevo ESMS-MI, adems de algunas mejoras para organizar an ms los elementos de software en el marco de una arquitectura por capas19 la cul permitir involucrar algunos patrones de diseo que se estaran violando en la antigua arquitectura.
16
Que posteriormente ser utilizada en otros proyectos para mejorar la calidad de la estimacin del esfuerzo requerido. 17 EVOLUCIN 3.5. HERRAMIENTA SOFTWARE PARA EL MODELAMIENTO Y SIMULACIN CON DINMICA DE SISTEMAS. 18 En lenguaje DELPHI de Borland. 19 Capa de Presentacin (Implementa la lgica liviana de la Interfaz Grfica de Usuario), Capa de Dominio (Implementa la Lgica Gruesa del Negocio) y Capa de Servicios (Implementa la lgica que puede re-utilizarse entre aplicaciones de la misma familia).
Versin 0.5 87 DE 95
Elaborar una instanciacin de un proceso adecuado para el desarrollo distribuido de software que favorezca las condiciones mnimas para unificar e integrar la comunicacin y gestin durante la ejecucin de un proyecto software orientado a entregar un Entorno de Modelamiento-simulacin de modelos integrados, liderado por el grupo SIMON.
Durante 10 (Horas/Hombre) se realiz una investigacin exhaustiva acerca de los retos relacionados con el desarrollo en comunidad de tal forma que se pudiesen armonizar algunos requisitos fundamentales que el proceso propuesto alcanzara a travs de sucesivos niveles de madurez, al final se determinaron para Agile-DISOP, un total de 24 requisitos dispuestos en 6 categoras. As mismo, durante 6 (Horas/Hombre) se rescataron once (11) valiosas prcticas de la ingeniera del software que conformaron los postulados de Agile-DISOP en materia de desarrollo comunitario y de otra parte en el Error: Reference source not found, se advierte sobre treinta (30) malas prcticas que entorpecen el desarrollo de cualquier proyecto, lo cul exigi 4 (Horas/Hombre), por ltimo con un esfuerzo de 19 (Horas/Hombre), se recopilaron 110 riesgos distribuidos en doce (12) categoras relacionadas con la gestin de proyectos informticos. Por otra parte, se determino la arquitectura misma del proceso en trminos de seis (6) disciplinas de la ingeniera del software y la gestin de proyectos en el marco de una comunidad de desarrollo y se estableci la metodologa (Ver numeral 1.6) para especificar todos los componentes del proceso Agile-DISOP abarcando un total de 152 (Horas/Hombre). Las 229 (Horas/Hombre) restantes se relacionan con: resultados de investigacin sobre las prcticas empresariales de PYMES en el sur-occidente colombiano, la divulgacin del proyecto en una revista y dos eventos (uno nacional y uno internacional) y finalmente el emprendimiento y culminacin de un trabajo de pregrado21 que beneficiara a dos (2) estudiantes del programa de ingeniera de sistemas de la UNICAUCA. Los resultados de este ltimo implicaron para los estudiantes un esfuerzo de 920 (Horas/Hombre), las cules slo 120 (Horas/Hombre) se cuantifican por concepto de la gestin del director. Todos los productos relacionados a este trabajo de pregrado, se incluyen en formato digital en el disco compacto que acompaa a este documento. Finalmente, aunque los resultados entregados son lo suficientemente completos para ser aprovechados por una comunidad de desarrollo, se torna interesante y adems recomendable que mediante el mecanismo dispuesto por Agile-DISOP explicado en el numeral 1.13. DISCIPLINA: MEJORAMIENTO de Agile-DISOP, se incremente de forma continua y sostenida la madurez de: practicas, disciplinas, actividades, roles y artefactos del proceso. Por otra parte y aprovechando el prototipo entregado por el trabajo de pregrado mencionado anteriormente, puede encontrarse muy interesante una propuesta de tesis de maestra que contemple el desarrollo de una plataforma especfica para una comunidad de que utilice no slo Agile-DISOP, sino cualquier otro proceso de desarrollo.
20 21
ESS-Model, SDMetrics y Ms-Excel. Denominado CONSTRUCCIN DE UNA HERRAMIENTA SOFTWARE PARA SOPORTAR UN PROCESO DISTRIBUIDO DE DESARROLLO UTILIZADO POR UNA COMUNIDAD (I+D). Universidad del Cauca. Septiembre de 2005.
Versin 0.5 88 DE 95
1.
Los aspectos tcnicos de la plataforma software de la comunidad no deben ser evidentes ni mucho menos entorpecer la interaccin del usuario al usar los servicios que provee la plataforma. Debe existir un equipo humano trabajando en la sombra para asumir el desgaste tcnico relacionado con el soporte de la comunidad. posibilidad de frustracin y desercin masiva de los usuarios de la comunidad. Este aspecto disminuye la
2.
El usuario de la comunidad debe percibir conscientemente los beneficios personales que la comunidad le ofrece. Este aspecto ayuda a construir la fidelidad del usuario.
3.
La comunidad debe ofrecer permanentemente novedades, recursos e informacin que sean tiles y efectivas para sus miembros. Se recomienda ir siempre un paso adelante, no solamente dndole al usuario lo que quiere, sino tambin sorprendindolo con lo que no espera.
4.
Es clave aliarse con usuarios emprendedores y entusiastas de la comunidad, especialmente si estos se hallan en ubicaciones geogrficas lejanas. Esto se debe a que un usuario entusiasta, como ejemplo viviente, promover en sus ms cercanos los beneficios de agregarse y participar en la comunidad, derrumbando en parte la resistencia de aceptar un paradigma de cooperacin diferente.
5.
Por ltimo, es vital que al principio de la puesta en marcha de una comunidad, no se sature al usuario con una funcionalidad sobre-sofisticada que pueda aturdirlo o confundirlo causndole frustracin y deseo de retirarse. esta ofrece, siempre con ejemplos sencillos y en un ambiente informal de mucha cordialidad y respeto hacia el usuario. Es fundamental que de forma peridica se capacite a los miembros de la comunidad en el uso correcto de los servicios que
En tercer lugar, para alcanzar los resultados que corresponden al objetivo general que plantea:
Elaborar una propuesta ante COLCIENCIAS, que corresponda al diseo de un plan de proyecto (I+D) (de mediano plazo) para el ESMS de modelos integrados apoyado en el proceso distribuido y soportado en la arquitectura base diseada, como alternativa de continuidad.
Se elabor una propuesta de diez (10) pginas para el desarrollo de una plataforma denominada SEDISE23 que publicara la arquitectura del ESMS-MI y apoyara a SIMON adems de otros grupos (i+d) en el desarrollo comunitario de nuevos componentes para la representacin de conocimiento en otros enfoques adems de la dinmica de sistemas. Esta propuesta fue incluida en el documento MODELO DE INTEGRACIN DE LAS TIC AL DESARROLLO EDUCATIVO COLOMBIANO EN EL MARCO DE LA SOCIEDAD DEL CONOCIMIENTO (Error: Reference source not found), presentado por el grupo GTI3de la UNICAUCA 3. La propuesta alcanz a ser evaluada por los pares internacionales que visitaron al GTI en las instalaciones de la UNICAUCA durante 2006, sin embargo recientemente se conoci que no fue aprobada. Se recomienda continuar con la participacin en convocatorias a proyectos con el objeto de financiar la sostenibilidad de los resultados del presente trabajo de investigacin.
22 23
Versin 0.5 89 DE 95
H1: Es posible disear proyectos de desarrollo para comunidades geogrficamente dispersas de (I+D) cuyo propsito sea entregar soluciones software a la comunidad acadmico-investigativa e industrial que compitan en funcionalidadcosto-beneficio con software propietario disponible en el mercado?
H2: Crear las condiciones mnimas para favorecer la consolidacin de una comunidad de desarrollo distribuido como estrategia para enfrentar problemas particulares de la academia, la investigacin y/o la industria en el marco nacional, representa una alternativa seria al desarrollo tradicional de software propietario?
Conclusin. A travs del desarrollo del presente trabajo de tesis el autor ha vivenciado la notoria tendencia que existe actualmente hacia el desarrollo en comunidad. De hecho, a un clic de distancia pueden encontrarse modelos de desarrollo en comunidad muy exitosos, los cules validan la viabilidad y competencia de los productos software desarrollados. Al respecto y tomando lectura de las convocatorias de COLCIENCIAS y otros organismos a Centros de Excelencia, es evidente que cada vez se toma ms percepcin y conciencia acerca de la comunidad (i+d) como un macro-organismo viable e incluso necesario que aborda realidades cada vez ms complejas. El desarrollo de software en comunidad soportado por las TICs es una oportunidad que justifica y posibilita el diseo de proyectos de contexto e impacto nacionales, competitivos internacionalmente. Aqu lo fundamental consiste en contar por una parte en el liderazgo de un grupo (i+d), una arquitectura de software abierta con potencial y en una comunidad interesada en desarrollar sobre esta arquitectura. Estas condiciones estn dadas en el preciso instante de culminacin del presente trabajo de investigacin.
Versin 0.5 90 DE 95
Versin 0.5 91 DE 95
Versin 0.5 92 DE 95
Versin 0.5 93 DE 95
[6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17]
MICROSOFT. Sitio Web de Microsoft Corporation. http://www.microsoft.com MOODLE. Open Source Course Management Tool. http://www.moodle.org PHPROJEKT. Open Source Groupware Suite. http://www.phprojekt.com SDMETRICS. (Visitado en Agosto 12 de 2006). http://www.sdmetrics.com Sitio Web de la Herramienta SDMetrics. [Documento WWW]. URL
SEDISE (A Support Environment for Distributed Software Engineering). Grupo GTI, Lnea de Inters sobre la ingeniera del software bajo ambientes de dispersin geogrfica. http://groups.yahoo.com/group/sedise/ SEI, Software Engineering Institute. http://www.sei.cmu.edu/cmmi/general/ General Information about Capability Maturity Model Integration. CMMI.
SIMEP-SW. "Proyecto para un Sistema Integral de mejoramiento de los procesos de software en Colombia. http://groups.yahoo.com/group/simep-sw/ SIMON, Grupo de Investigacin de modelos http://www.uis.edu.co/site/investigacion/grupos/simon/index.html . y simulacin de la UIS.
SPEM. Software Process Metamoldel. Metamodelo usado para describir y/o especificar visualmente los procesos de desarrollo de software. http://www.omg.org/technology/documents/formal/spem.htm SYSTEMS AND SOFTWARE CONSORTIUM.Software Productivity Consortium. http://www.software.org/pub Sitio web de la asignatura de ingeniera del software del programa de ingeniera de sistemas. Estndares de documentacin para RUP. Elaborado por: Ing. Jorge Jair Moreno Chaustre. Docente Del Departamento de Sistemas. http://atenea.unicauca.edu.co/~jjmoreno/ Sitio web de la Universidad del Cauca. http://www.unicauca.edu.co/ Sitio web de la Universidad Industrial de Santander. http://www.uis.edu.co/
[18] [19]
Versin 0.5 94 DE 95
Versin 0.5 95 DE 95