Mejoramiento de procesos de desarrollo de software tomando como base el proceso Qualdev

Texto completo

(1)MEJORAMIENTO DE PROCESOS DE DESARROLLO DE SOFTWARE TOMANDO COMO BASE EL PROCESO QUALDEV. ANDRÉS RUBIO PÁRAMO. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA DE SISTEMAS BOGOTÁ D.C. 2006.

(2) TABLA DE CONTENIDO INTRODUCCIÓN 1. GENERALIDADES 1.1. TÍTULO 1.2. PLANTEAMIENTO DEL PROBLEMA 1.3. OBJETIVOS 1.3.1. Objetivo General 1.3.2. Objetivos Específicos 1.4. DESCRIPCIÓN DEL PROYECTO 2. MARCO TEÓRICO 2.1. GRUPO QUALDEV 2.2. QUALDEV COMMUNITY 2.3 MODELO IDEAL 2.3.1. Etapa de inicialización 2.3.2. Etapa de Diagnóstico 2.3.3. Etapa de Establecimiento 2.3.4. Etapa de Ejecución 2.3.5. Etapa de Aprendizaje 2.4. RUP (RATIONAL UNIFIED PROCESS) 2.5. QUALDEV PROCESS 2.5.1. Lanzamiento 2.5.2. Estrategia 2.5.3. Análisis 2.5.4. Diseño 3. DESARROLLO DEL TRABAJO CON LA EMPRESA 3.1. INICIALIZACIÓN 3.2. DIAGNÓSTICO 3.3. ESTABLECIMIENTO 3.4. EJECUCIÓN 3.5. APRENDIZAJE 3.6. PROPUESTA DE MANEJO DE LA WIKI 4. CONCLUSIONES 4.1 CONCLUSION GENERAL 4.2 CONCLUSIONES ESPECIFICAS BIBLIOGRAFÍA. 1 2 2 2 2 2 2 3 4 4 5 6 7 7 7 8 8 8 11 11 13 14 15 17 17 18 20 22 23 26 29 29 29 30.

(3) INTRODUCCIÓN En el siguiente documento se ve evidenciado el trabajo realizado dentro de los parámetros de un proyecto iniciado por el grupo de desarrollo del departamento de Ingeniería de Sistemas y Computación de la Universidad de los Andes, con una empresa del sector del desarrollo de software. La idea principal del proyecto mencionado, es el de apoyar a las pequeñas y medianas empresas con procesos y procedimientos que se definieron dentro del grupo y que han sido aplicados por el mismo con resultados satisfactorios, para así poder dar un valor agregado a la sociedad y al mismo tiempo poner esos procesos y procedimientos en un ambiente un poco más real a como se desempeña una empresa en la realidad, para así poder seguir enriqueciéndolo y lograr un crecimiento del mismo grupo. Uno de los procesos que se tienen definidos en este grupo, es el de administración del conocimiento, y éste es el que más va ligado de acuerdo a los intereses de este trabajo en particular. De manera general lo que se desea en este trabajo es el explicar como se realizó un trabajo de apoyo al proceso de administración del conocimiento en una empresa en particular de desarrollo de software, como se trazaron los objetivos y que metodología se utilizó para la implantación de las mejoras dentro de la misma, como esta experiencia ayudó a mejorar el desempeño de la empresa y como se puede ver retroalimentado el grupo de desarrollo..

(4) 1. GENERALIDADES 1.1. “MEJORAMIENTO DE PROCESOS DE DESARROLLO DE SOFTWARE TOMANDO COMO BASE EL PROCESO QUALDEV” 1.2. PLANTEAMIENTO DEL PROBLEMA Dentro del grupo QUALDEV de desarrollo de software de la Universidad de los Andes, se ha venido trabajando en un proceso de desarrollo con base en aportes e investigaciones realizadas por los distintos miembros del grupo; la idea que se tiene es el poder apoyar a pequeñas y medianas empresas de desarrollo a poder mejorar sus procesos y su calidad con elementos del proceso, dando así un valor agregado a la sociedad y de la misma manera tener una buena retroalimentación para el crecimiento del proceso y del grupo de desarrollo. 1.3. OBJETIVOS A continuación se procede a mencionar los objetivos generales del proyecto Qualdev Community del grupo de desarrollo QUALDEV de la Universidad de los Andes, y los objetivos específicos de este desarrollo del proyecto en particular. 1.3.1. Objetivos Generales Como se expresa en la página de la WIKI del grupo QUALDEV el objetivo principal es el de apoyar con los proceso desarrollados internamente los procesos que se desarrollan en las empresas para poder mejorar su desempeño yla calidad de sus 1 productos 1.3.2. Objetivos Específicos. 1. •. Se desea implementar un sistema de administración de conocimiento en el cual se pueda centralizar la información concerniente a los proyectos que se manejan en la empresa.. •. Se desean iniciar con la implantación del proceso de desarrollo de software creado por el grupo QUALDEV.. Grupo QUALDEV. QUALDEV community. Recuperado el 28 de Diciembre del 2005, del sitio web del grupo QUALDEV de la Universidad de los Andes: http://chie.uniandes.edu.co/~changeset/process/doku.php?id=development:projects:empresas:emp resas.

(5) •. Se desea integrar el proceso de desarrollo de software con el proceso de administración del conocimiento.. 1.4. DESCRIPCIÓN DEL PROYECTO En este proyecto se desea en primera instancia dejar un sistema que permita centralizar el conocimiento de los proyectos de la empresa, y que además sirva de apoyo para definir y documentar cuatro de los procesos de desarrollo que se tienen en la actualidad en el grupo de desarrollo QUALDEV, con sus plantillas y artefactos; teniendo muy presente el hecho que se está buscando mejorar la calidad de los productos que ahí se desarrollan y los que se van a desarrollar a futuro, para así poder dar un paso importante en la búsqueda de una certificación de calidad.. 3.

(6) 2. MARCO TEÓRICO A continuación se procede a establecer el marco teórico en el cual se está apoyando este proyecto. 2.1. GRUPO QUALDEV El grupo QUALDEV como se ha venido mencionando pertenece al grupo de Construcción de Software del departamento de sistemas y computación de la Universidad de los Andes, además pertenece a grupo de TICSw reconocido y 2 clasificado por colciencias. Este grupo tiene como objetivo el mejorar las prácticas de la ingeniería de software. Surgió como un laboratorio de experimentación en los temas de diseño, procesos, 3 tecnologías y otros afines; en Agosto del año 2003. La sigla QUALDEV significa Quality Development, que claramente refleja el objetivo del trabajo del grupo, es una breve descripción de la misión del grupo; el siempre buscar la excelencia y la calidad en el desarrollo de software buscando procesos ágiles que permitan construir en poco tiempo un producto que cumpla unos altos estándares de calidad. El grupo más que comportarse como un grupo, se comporta más como un equipo de trabajo; en este momento el equipo se conforma por estudiantes de pregrado, estudiantes de maestría y profesores de la Universidad de los Andes; el equipo tiene una alta rotación del personal, por lo que siempre está buscando el desarrollo de procesos que sean muy ágiles y que sean fáciles de adaptar. En ese laboratorio que tiene el grupo QUALDEV para explorar los procesos y las tecnologías, se tienen en el momento tres proyectos que son CHANGESET, Planning Tool, y QUALDEV community; el primero es sistema de administración de configuraciones diseñado para ser usado por casas desarrolladoras de software como una herramienta que permite un mejor manejo de sus productos, ya sea manejando su versionamiento, su agrupamiento en líneas de base, o el. 2. Grupo QUALDEV.Qualdev Group. Recuperado el 28 de Diciembre del 2005, del sitio web del grupo QUALDEV de la Universidad de los Andes: http://chie.uniandes.edu.co/~changeset/process/doku.php?id=presentacion 3 Ibid..

(7) seguimiento de su desarrollo por medio de solicitudes de cambio que se le hagan 4 a sus productos. El segundo proyecto es un nuevo módulo para una aplicación existente llamada dotProject que ayuda a manejar proyectos; lo que se desea realizar es un módulo que permita realizar una mejor labor de planeación y seguimiento de los proyectos, por medio de una interfaz más amigable que permite una mejor usabilidad, además de ofrecer una serie de reportes que ayudan más 5 eficientemente a las evaluaciones de los proyectos. El tercer proyecto del grupo QUALDEV mencionado, por ser el que tiene más referencia con este proyecto, tiene una sección aparte dentro de este documento la cual se presenta a continuación. 2.2. QUALDEV COMMUNITY Como se mencionó en la sección anterior este es uno de los proyectos que están en desarrollo en la actualidad por parte del grupo QUALDEV, y su objetivo principal es el de ayudar a las pequeñas y medianas empresas desarrolladoras de software a mejorar la calidad de sus productos y de sus procesos por medio de los procesos definidos en el laboratorio, y así mismo con base en estas experiencia con las empresas poder retroalimentar los procesos propios para darle crecimiento a los mismos y por ende propiciar el crecimiento del equipo. Se puede decir que este es un proyecto nuevo, tiene su origen en Abril del 2005; después de haber realizado un trabajo de prueba y documentación del proceso del grupo, en paralelo al desarrollo del proyecto changeset; después de verificar que los procesos ayudaban en gran forma al desarrollo del proyecto changeset, se llegó a la conclusión que estos ya tenían un cierto grado de madurez, y a raíz de esto se vislumbró la oportunidad de poder ayudar a las pequeñas y medianas empresas de desarrollo con la implantación de estos procesos que resultan muy ágiles y que no exigen de grandes costos para ser implementados, solo se necesita buena voluntad y el deseo de buscar la mejora para la empresa. En un inicio el proyecto comenzó con cuatro empresas que mostraron interés por estos procesos; en el transcurso del proyecto, dos empresas desistieron y se concluyó una primera etapa con las dos restantes. Como la idea del proyecto es la implantación de nuevos procesos en empresas, se buscó una metodología que hiciese este proceso más amigable y de alguna 4. Grupo QUALDEV. Qualdev - Portal de Desarrollo. Recuperado el 28 de Diciembre del 2005, del sitio web del grupo QUALDEV de la Universidad de los Andes: http://chie.uniandes.edu.co/~changeset/process/doku.php?id=site:projects 5 Ibid.. 5.

(8) manera más formal, de ahí el que en este proyecto se utilice la metodología IDEAL para la implantación de los procesos; esta metodología será explicada con un nivel mayor de detalle en una sección aparte que se encuentra más adelante en este documento. 2.3. MODELO IDEAL Este modelo es desarrollado por el SEI (Instituto de Ingeniería de Software), y fue concebido con un modelo basado en ciclos para la implantación de procesos de software; con esto el modelo provee un acercamiento a una ingeniería disciplinada 6 para la implantación de procesos. El modelo IDEAL consta de 5 etapas cuyas iniciales forman la sigla del modelo; estas etapas son: • • • • •. Initiating (Inicialización) Diagnosing (Diagnóstico) Establishing (Establecimiento) Acting (Ejecución) Learning (Aprendizaje). Cada una de estas etapas tiene actividades específicas asociadas; un buena idea de este modelo se puede ver evidenciada en la siguiente gráfica.. Figura 1.Representación del modelo IDEAL. Tomado de www.sei.cmu.edu/ideal/ideal.gif 6. Gremba, Jennifer., Myers, Chuck.(1997). The IDEAL SM Model: A Practical Guide for Improvement. Recuperado el 30 de Diciembre del 2005: http://www.sei.cmu.edu/ideal/ideal.bridge.html. 6.

(9) A continuación se procede a explicar más en detalle cada una de las etapas del modelo. 2.3.1. Etapa de Inicialización Esta es la primera etapa del ciclo propuesto por el modelo; acá se identifica la necesidad general del cambio o mejora, además se debe fijar un contexto para el trabajo que se desea realizar identificando que áreas son las que van a intervenir en el proceso y que puntos neurálgicos son los que se desean atacar, y por último se debe definir la infraestructura necesaria para poder realizar el trabajo, esto quiere decir que se debe definir quiénes son los participantes internos a la organización que van a tener alguna acción, también los participantes externos que van a intervenir, y se les debe asignar responsabilidades a cada una de estas 7 personas o recursos. 2.3.2. Etapa de Diagnóstico Esta es la segunda etapa del ciclo propuesto por el modelo; en esta etapa se realiza un análisis más detallado del punto que se desea mejorar, con base en lo realizado en la etapa de inicialización; esto se logra haciendo dos caracterizaciones de la empresa u organización, la primera es una identificación de estado actual del punto a trabajar en la empresa, y la segunda es una visualización de cómo se desea que sea el estado de ese punto después de terminado el ciclo; esto da un asentamiento de qué es lo que se quiere hacer yde alguna forma define un alcance del trabajo a realizar; con base en estas caracterizaciones, se puede desarrollar una propuesta de cómo se debe proceder 8 en las siguientes etapas. 2.3.3. Etapa de Establecimiento Esta es la tercera etapa del ciclo propuesto por el modelo; como su nombre lo dice, en esta fase se debe realizar un establecimiento del plan de trabajo detallado; para este fin se deben priorizar las actividades propuestas en la etapa de diagnóstico, tomando como base para este tema cuáles son las situaciones en las cuales la organización tiene más deseo de mejorar. En esta etapa se debe tener un mejor conocimiento de la disponibilidad para trabajar en este tema por parte de los actores identificados en la etapa de inicialización, se definen grupos de trabajo y se asignan roles dentro de estos. 7. Gremba, Jennifer., Myers, Chuck.(1997). The IDEAL SM Model: A Practical Guide for Improvement. Recuperado el 30 de Diciembre del 2005: http://www.sei.cmu.edu/ideal/ideal.bridge.html 8 Ibid.. 7.

(10) grupos y sus respectivas responsabilidades; también se debe identificar los factores técnicos y los no técnicos como lo pueden ser la cultura organizacional. Como punto de partida de esta fase se debe tener un cronograma de actividades 9 con tareas, hitos y entregables. 2.3.4. Etapa de Ejecución Esta es la cuarta etapa del ciclo propuesto por el modelo, y es la etapa en la que se debe invertir más tiempo; se proponen cuatro actividades a desarrollar en esta fase, comienza con la creación de la solución para poder llegar a la mejora propuesta en la fase de diagnóstico; acá es donde se evalúan o crean herramientas, se realizan instalaciones o capacitaciones y cosas por el estilo; después de haber encontrado y creado la solución, se debe realizar una prueba piloto de esa solución en el amiente real de la empresa con el fin de poder encontrar posibles fallas o de identificar mejoras a la solución creada; esta etapa de pruebas puede constar de varios ciclos de pruebas hasta que halla un consenso al final que la solución ya se encuentra lo suficientemente madura como para empezar a usarla en la organización; y por último la implementación de la solución en los distintos proyectos de la empresa. Se debe tener muy presente que en esta etapa debe haber un control permanente por parte del sponsor del cambio, si se puede de la gerencia misma de la organización para garantizar el paso del punto a cambiar al estado deseado 10 identificado en la etapa de diagnóstico. 2.3.5. Etapa de Aprendizaje Esta es la quinta y última etapa del ciclo propuesto por el modelo, por ende es la que cierra el ciclo de mejoramiento; toma como base los documentos realizados en las etapas anteriores del modelo y la experiencia en el desarrollo del ciclo para realizar una evaluación de las lecciones aprendidas, también se hace una validación de los objetivos trazados en un comienzo, si se cumplieron o no, o si los esfuerzos que se destinaron en el inicio sí fueron suficientes o no y se determina si la organización puede seguir creciendo o mejorando otros puntos tomando en 11 cuenta la experiencia en el mejoramiento del punto trabajado durante el ciclo. 2.4. RUP (RATIONAL UNIFIED PROCESS). 9. Gremba, Jennifer., Myers, Chuck.(1997). The IDEAL SM Model: A Practical Guide for Improvement. Recuperado el 30 de Diciembre del 2005: http://www.sei.cmu.edu/ideal/ideal.bridge.html 10 Ibid. 11 Ibid.. 8.

(11) RUP es un proceso iterativo de desarrollo de software, que fue creado por Rational Software, dentro de RUP hay una gran cantidad de actividades, se puede de alguna forma adaptar a diferentes tipos de proyectos de software o a diferentes tipos de estilo que pueden llegar a tener las distintas empresas que se dedican a esta actividad; su aplicabilidad es reconocida particularmente a equipos grandes 12 de desarrollo que trabajan en proyectos relativamente grandes. Este proceso tiene sus orígenes como respuesta a los fallos de diversos proyectos de desarrollo de software, estos fallos pueden ser originados por una combinación de diferentes factores y cada proyecto falla en una forma única; del análisis de los distintos factores que pueden intervenir en el fallo de un desarrollo surgieron una 13 serie de mejores prácticas que reunidas forman el RUP. Con el uso de RUP, los ciclos de vida de un software son divididos en varios ciclos de desarrollo, estos ciclos a su vez son reunidos en fases de desarrollo; las fases que contempla el RUP son las siguientes: • • • •. Inicio Elaboración Construcción Transición. A continuación se procede a realizar una definición de cada una de estas fases nombrando las tareas que ahí se deben desarrollar grosso modo. •. Inicio: Esta es la fase inicial del proceso de desarrollo propuesto por RUP, acá se establecen los casos de uso del negocio, estos casos de uso incluyen ítems como una definición del contexto y los factores que determinan el éxito o la aceptación del caso; como apoyo a estos casos del negocio se deben realizar modelos de caso de uso, identificar posibles riesgos asociados, un plan del proyecto y una definición general del proyecto. Esta fase se puede repetir tantas veces hasta que las definiciones que ahí se deben realizar hallan sido aceptadas por todos los stakeholders 14 del proyecto, o hasta que se decida no continuar con el proyecto.. •. Elaboración: Esta es la segunda fase del proceso propuesto por RUP, yacá se realiza un análisis del problema a resolver, y la arquitectura que se debe implementar empieza a tomar forma; para que esta fase se pueda dar por terminada, debe pasar las siguientes condiciones:. 12. Rational Unified Process. Recuprado el 30 de Diciembre del 2005: http://en.wikipedia.org/wiki/Rational_Unified_Process 13 Ibid. 14 Ibid.. 9.

(12) o Debe haber una documentación de al menos el 80% de los casos de uso en donde se deben haber identificado los actores y se debe tener la descripción de cada uno de ellos. o Una descripción de la arquitectura. o Una lista aceptada por los stakeholders con los casos del negocio y los riesgos identificados o Un plan de desarrollo para el proyecto. Al igual que la fase anterior, esta fase puede tener tantas iteraciones hasta que se llegue a el logro de los puntos nombrados anteriormente, o si se decide que los cambios o la implementación a realizar parece tan costosa 15 que se prefiere desechar el proyecto. •. Construcción: Esta es la tercera fase del proceso propuesto por RUP, y es en esta en la que se realiza el desarrollo de los componentes que van a ser parte de la aplicación; en esta fase se produce un primer lanzamiento del producto. También durante esta fase pueden ocurrir pequeños cambios a las definiciones de los casos de uso, por lo que al igual que las anteriores, 16 puede tener más de una iteración.. •. Transición: Esta es la cuarta y última fase del proceso propuesto por RUP y se origina en el momento en que la aplicación pasa de las manos del desarrollador a las manos del cliente final; las actividades de esta fase consisten en manera general a realizar capacitaciones de la herramienta a los usuarios finales; además se pueden realizar unas pruebas beta del producto para así poder conocer cambios que se le deban realizar a la aplicación; además se pone en prueba la aplicación y se mira si se logra obtener el nivel de aceptación definido en la etapa de inicialización, en caso de no lograr cumplir con las expectativas, se vuelve al desarrollo de los cambios; en el momento en que se cumplan todas las expectativas, se da 17 por finalizado el proceso de desarrollo.. Para tener una mejor idea de cómo funciona RUP, se presenta la siguiente figura.. 15. Rational Unified Process. Recuprado el 30 de Diciembre del 2005: http://en.wikipedia.org/wiki/Rational_Unified_Process 16 Ibid. 17 Ibid.. 10.

(13) Figura 2.Representación de RUP. Tomado de http://mgmt.iisc.ernet.in/~hema/SoftwareArchitecture_Session1.htm. 2.5. QUALDEV PROCESS El QUALDEV PROCESS es un proceso resultado de la compilación de las distintas investigaciones realizadas por los antiguos miembros del grupo QUALDEV con base en procesos de desarrollo de software; este proceso se encuentra basado en el proceso propuesto por Watts Humphrey TSP (Team Software Process), tiene todas las fases del desarrollo propuestas por TSP pero en su funcionamiento tienen ciertos rasgos de otro método de desarrollo más ágil que es el Xtreme Programming (XP), como resultado de esta combinación de procesos se logró un proceso bastante ágil que permite realizar desarrollos de software en ciclos de desarrollo relativamente cortos; además cuenta con unos procesos de soporte a los procesos de desarrollo que se han venido puliendo con el transcurso del crecimiento del grupo QUALDEV como lo son los procesos de planeación, administración de configuraciones, administración del conocimiento y el de la administración de los riesgos. El proceso propuesto por el grupo QUALDEV tiene también sus bases en el tema de los equipos de trabajo, en donde no es solamente un grupo de desarrollo sino más bien un equipo de desarrollo en donde todos los miembros siempre buscan realizar actividades para el beneficio de los objetivos del equipo y no solamente buscan la realización de las actividades que se le asignaron; además se manejan roles dentro de los miembros del equipo en el que cada uno tiene tanto tareas de verificación de su tema específico, como tareas de desarrollo del proyecto. Con base en la experiencia del grupo en los distintos proyectos que lleva a cabo, se ha logrado una dinámica que logra llevar estos procesos en paralelo logrando. 11.

(14) de esta forma un desarrollo ágil sin descuidar el tema de la calidad de los productos. Para efectos del desarrollo de este trabajo solo se van a tener en cuenta las propuestas hechas por el QUALDEV PROCESS a cuatro de las etapas del proceso de desarrollo que en principio fueron definidos para TSP; estas son las etapas de lanzamiento, estrategia, análisis y diseño; las cuales se van a explicar más en detalle a continuación. 2.5.1. Lanzamiento Este es la primera fase del proceso de desarrollo, y consiste en organizar el equipo y el proceso para el proyecto que se va a iniciar; es la primera etapa a superar cada ciclo de desarrollo, sin embargo su principal aporte se ve evidenciado al inicio del proyecto ya que ahí se organiza la infraestructura para 18 poder trabajar. Las actividades a realizar que se proponen en esta fase son las siguientes: •. Definición de roles necesarios: Como el proceso se encuentra basado en equipos de trabajo, dentro de los equipos deben existir ciertas figuras que se van a encargar del buen funcionamiento y desarrollo de las actividades a realizar, estas figuras son los roles; se toman como base los siguientes roles. o Líder del proyecto o Líder de planeación o Líder de proceso y calidad o Líder de desarrollo o Líder de soporte Dependiendo de la naturaleza del proyecto puede ser necesario la inclusión de otros roles, para el caso particular de los proyectos que buscan cierta agilidad, resulta importante el incluir un nuevo rol que es el Líder de pruebas; por cada rol es importante definir cuáles son sus responsabilidades. En conclusión en esta tarea se debe definir que roles van a intervenir en el ciclo de desarrollo o en el proyecto, se debe crear un documento con la definición de los roles, y este debe ser actualizado a medida que vayan 19 surgiendo nuevos roles.. 18. Grupo QUALDEV. QUALDEV process. Recuperado el 28 de Diciembre del 2005, del sitio web del grupo QUALDEV de la Universidad de los Andes: http://chie.uniandes.edu.co/~changeset/pdescription/ 19 Ibid.. 12.

(15) •. Conformación del equipo: Esta tarea consiste en escoger del recurso humano disponible, quienes son los que van a integrar el equipo de desarrollo, y dependiendo de las habilidades de cada uno de los miembros escogidos, se asignan roles y responsabilidades a cada uno de estos; cabe resaltar que independientemente de las tareas y obligaciones que conllevan los roles de acuerdo a su definición, todos los miembros del equipo también 20 deben cumplir tareas operativas de desarrollo y documentación.. •. Establecimiento de objetivos: En esta tarea se deben identificar objetivos de dos tipos, unos son los objetivos del equipo y los segundos son los objetivos a cumplir en el proyecto o en el ciclo de desarrollo; cada uno de estos objetivos debe tener asociada una métrica de aceptación, para así en la última fase del proceso de desarrollo poder evaluar si el objetivo fue 21 logrado o no.. •. Establecimiento de las reglas del equipo: La idea es que el equipo de desarrollo funcione de manera independiente, por la misma idea que se maneja de equipo, en donde todos deben apoyarse para buscar un bien común al mismo; para que este buen funcionamiento se logre, se deben definir una serie de reglas o normas para la totalidad de los miembros que 22 se deben cumplir a cabalidad.. 2.5.2. Estrategia Esta es la segunda fase del proceso de desarrollo, y consiste a grandes rasgos en definir una planeación inicial del trabajo que se debe realizar en el proyecto o en el ciclo de desarrollo, también se debe empezar a realizar una primera definición de los riesgos que se pueden presentar en el transcurso del ciclo y una modificación a los procesos o a las fases que se deben seguir a continuación, dependiendo de la naturaleza del ciclo; a continuación se procede a explicar un poco más en 23 detalle las tareas que se deben realizar en esta etapa. •. Planeación preliminar: Esta tarea consiste en realizar una estimación de los recursos necesarios para el desarrollo de los casos de uso, y con base en esto se realiza un compilado con una planeación global del ciclo de 24 desarrollo.. 20. Grupo QUALDEV. QUALDEV process. Recuperado el 28 de Diciembre del 2005, del sitio web del grupo QUALDEV de la Universidad de los Andes: http://chie.uniandes.edu.co/~changeset/pdescription/. 21 Ibid. 22 Ibid. 23 Ibid. 24 Ibid.. 13.

(16) •. Administración del riesgo: En esta parte se debe realizar en primera instancia una identificación y definición de los riesgos que se pueden presentar durante el ciclo de desarrollo, acto seguido se deben clasificar estos riesgos en una matriz que mide la probabilidad de ocurrencia del riesgo y el nivel del impacto que este puede llegar a causar sobre la herramienta, sobre el desarrollo, sobre el equipo, etc; ya teniendo esta matriz llena, se deben escoger los riesgos a los cuales se le va a hacer seguimiento durante el ciclo y por último después de haber hecho esa discriminación, se le deben definir planes de mitigación tanto de probabilidad como de impacto, y se le debe definir un plan de contingencia 25 en caso que ocurra.. •. Modificación de procesos: De acuerdo a los objetivos trazados en la fase anterior, se debe realizar una evaluación de cómo se deben llevar las fases siguientes del desarrollo, que tanto se va a realizar de éstas y que tanto no se va a realizar para hacer que el proceso se vuelva ágil; o por el otro lado si se deben realizar modificaciones a el manejo o a la forma en la que se 26 debe realizar las actividades en las fases siguientes.. 2.5.3. Análisis Esta es la tercera fase del proceso de desarrollo y es la base fundamental para la construcción de software, como su nombre lo indica, en esta fase se realiza un análisis del proyecto para poder empezar a vislumbrar la forma en la cual se va a realizar la implementación de la solución; a continuación se pueden encontrar las distintas actividades que se propone se realicen en esta fase con su explicación 27 respectiva. •. Análisis de requerimientos: Este análisis es el punto de partida del proyecto, para el desarrollo de este existen varias propuestas en la literatura, pero para el contexto de proyectos ágiles se aconseja tratar este tema por medio de casos de uso; para este fin se tienen dos etapas, la primera tiene como fin el levantar un documento de levantamiento de requerimientos como resultado de las distintas reuniones con el cliente; teniendo este documento, se puede empezar a levantar los primeros casos de uso y se clasifican de acuerdo a una prioridad dada por el cliente, esto ayuda a que en paralelo se logre una primera evaluación general del proyecto; luego se puede realizar un análisis más en detalle de cada uno de los casos de uso,. 25. Grupo QUALDEV. QUALDEV process. Recuperado el 28 de Diciembre del 2005, del sitio web del grupo QUALDEV de la Universidad de los Andes: http://chie.uniandes.edu.co/~changeset/pdescription/. 26 Ibid. 27 Ibid.. 14.

(17) dejando este bien documentado como base para el trabajo de los siguientes 28 ciclos. •. Construcción del modelo conceptual: La construcción de este modelo se realiza tomando como base el documento de levantamiento de requerimientos logrado en la tarea anterior; se debe realizar un modelo conceptual de todo el proyecto al inicio del mismo, y en el desarrollo de cada ciclo de trabajo se debe realizar un modelo conceptual de los temas 29 que se van a trabajar en ese ciclo con un nivel mayor de detalle.. •. Diseño y construcción de planes de prueba: Esta es una tarea que maneja el aseguramiento de la calidad, sigue el principio de pruebas antes de diseño, y además de apoyar el proceso de verificación, también ayuda a el proceso de validación de los casos de uso, ya que permiten que los conceptos de cada caso de uso queden totalmente claros para 30 desarrolladores y clientes.. •. Diseño y construcción de planes de prueba del sistema: En esta tarea se debe realizar un compilado de las pruebas que se consideren más importantes creadas en la tarea anterior, para así poder tener en un solo documento las pruebas que debe pasar el sistema para que éste pueda ser aprobado por parte del cliente, por eso es importante que el cliente apruebe 31 este documento y de ser posible que participe en la creación del mismo.. 2.5.4. Diseño Esta es la cuarta fase del proceso de desarrollo, y es esencial, no se puede dejar de realizar; el diseño se debe realizar a varios niveles como lo son a nivel de interfaz, a nivel de base de datos, a nivel de la lógica del negocio, etc; cada uno de estos niveles cuenta con una serie de gráficas y diagramas cuyo nivel y cantidad son definidos por el equipo de desarrollo de acuerdo a las características propias del proyecto. Es importante que el equipo también acuerde estándares de desarrollo de estos diagramas para que se puedan interpretar más fácilmente yse puedan mantener de igual forma. Las tareas que se proponen en esta fase se 32 explican a continuación. •. Construcción de la arquitectura del sistema: La arquitectura contiene lo concerniente a todo lo referente con el diseño de alto nivel del sistema, en. 28. Grupo QUALDEV. QUALDEV process. Recuperado el 28 de Diciembre del 2005, del sitio web del grupo QUALDEV de la Universidad de los Andes: http://chie.uniandes.edu.co/~changeset/pdescription/ 29 Ibid. 30 Ibid. 31 Ibid. 32 Ibid.. 15.

(18) otras palabras los componente que van a conformar el sistema, la relación entre cada uno de estos el detalle de los mismos hasta el punto de llegar a vislumbrar el manejo de las excepciones; esta labor se realiza en el primer ciclo de desarrollo, en los siguientes ciclos solo se le hace mantenimiento 33 de acuerdo a los cambios que se vayan presentando. •. Construcción de diagrama de clases: Un diagrama de clases es una refinación del modelo conceptual; en esta tarea se deben realizar dos diagramas, un primer diagrama de clases tradicional que debe detallar la funcionalidad de cada clase para así poder consolidar un diseño más detallado de la herramienta; y un segundo diagrama de componentes que describa la interacción entre estos, logrando así un diseño de la 34 arquitectura del sistema.. •. Construcción de diagramas de secuencia: Estos diagramas hacen parte del 35 diseño detallado del sistema y sirven para validar el diagrama de clases.. •. Diseño de interfaz: Esta tarea consiste en la construcción de unos prototipos de las pantallas que se van a desarrollar, esta tarea tiene como punto de entrada es el modelo conceptual realizado en una de las fases anteriores, se usa este y no el diagrama de clases para poder realizar las 36 dos actividades en paralelo.. •. Diseño de base de datos: El diseño de una base de datos consiste en realizar un diagrama entidad relación de las tablas que van a conformar la base de datos, este diagrama es creado en el primer ciclo del desarrollo y es mantenido durante los ciclos siguientes, y tiene como punto de partida el 37 diagrama de clases.. •. Diseño y construcción de casos de prueba: La codificación de las pruebas es un tema que debe tener un diseño específico, se parte del diseño de cada requerimiento y de los planes de prueba realizados en la fase anterior, debe existir al menos un caso de prueba por cada plan de prueba y sirven 38 únicamente para las pruebas funcionales.. 33. Grupo QUALDEV. QUALDEV process. Recuperado el 28 de Diciembre del 2005, del sitio web del grupo QUALDEV de la Universidad de los Andes: http://chie.uniandes.edu.co/~changeset/pdescription/. 34 Ibid. 35 Ibid. 36 Ibid. 37 Ibid. 38 Ibid.. 16.

(19) 3. DESARROLLO DEL TRABAJO CON LA EMPRESA Este trabajo hace parte del proyecto QUALDEV COMMUNITY del grupo QUALDEV, como se expresó en el punto anterior. Este proyecto tiene como objetivo el dar apoyo a pequeñas y medianas empresas de desarrollo de software por medio de la implantación de los procesos del grupo en las mismas, así se logra dar un valor agregado a la sociedad y de la misma manera se logra retroalimentar el proceso y el equipo para poder seguir en la búsqueda del crecimiento. El objetivo que se trazó con respecto al trabajo con esta empresa era el de realizar un primer acercamiento con respecto al tema de la administración del conocimiento, implementando así un sistema en el cual se va a centralizar la información relevante de la misma (dokuwiki), y dejar una base para la definición e implantación del QUALDEV process en un futuro cercano. Con respecto al tema de la implantación del QUALDEV process, se realizaron definiciones de las fases de lanzamiento, estrategia, análisis y diseño, las cuales quedaron documentadas en la wiki de la empresa con sus respectivos artefactos. Como se explicó una sección anterior, el proyecto maneja el modelo IDEAL para la implantación de las mejoras en las empresas con las cuales se está trabajando; a continuación se procede a explicar el trabajo realizado en cada una de estas etapas del modelo; al final se realiza una serie de sugerencias con respecto al manejo que se le debe dar al espacio de administración del conocimiento como guía para la empresa. 3.1. INICIALIZACION Como se explicó una sección anterior, en esta etapa se debe identificar la necesidad en la cual se va a trabajar en el ciclo de mejoramiento; de común acuerdo con la persona a cargo de este proceso por parte de la empresa, se concluyó que se va a trabajar en el tema de la administración de conocimiento, como objetivos globales del ciclo de mejoramiento, se identificaron los siguientes: • • •. Centralizar el conocimiento del Grupo de Desarrollo. Mejorar la metodología de Construcción de Software del Grupo de Desarrollo. Integrar el proceso de Construcción de Software del Grupo de Desarrollo con el proceso de Administración del Conocimiento..

(20) El alcance del trabajo propuesto para este ciclo es el de realizar la Implantación de un espacio de administración del conocimiento que soporte un proceso válido dentro de normas y estándares de calidad mundial. En este proyecto, se van a ver involucrados todos los miembros del grupo de desarrollo de la empresa, va a haber una persona encargada de realizar la aprobación de los puntos concernientes al proceso definido y a la implementación de la wiki y el autor de este trabajo como participante del grupo QUALDEV. 3.2. DIAGNÓSTICO En secciones anteriores se explicó que en este paso del modelo IDEAL, se debe realizar un entendimiento de cómo se encuentra el punto a trabajar en la empresa, y como es el estado en el cual se desea que quede después del trabajo de mejoramiento. También se realizó una profundización en los objetivos que se deben cumplir, estos objetivos se manejan por niveles en donde a medida que aumenta el nivel, aumenta el nivel de especificación del objetivo; estos quedaron de la siguiente manera: •. Nivel 1: Implementación de un sistema de administración de conocimiento que apoye un proceso de construcción de software basado en estándares de calidad. •. Nivel 2: o Administrar y centralizar el conocimiento. o Integrar el proceso de Construcción de Software con el Proceso de Administración de Conocimiento. o Definición formal de los procesos de desarrollo de software en la empresa.. •. Nivel 3: o Definición y adaptación de un espacio para la administración de conocimiento: Wiki o Sharepoint. o Definir las fases (Análisis, Diseño, Lanzamiento y Estrategia en caso TSP; Inicialización y Elaboración en caso RUP), las actividades necesarias por fase y sus plantillas.. En el momento de realizar esa fase, no se tenían claras dos cosas que se iban a trabajar posteriormente, en primera instancia no se tenía certeza de si el espacio en el cual se pretendía centralizar el conocimiento iba a ser la implementación de una WIKI o si iba a ser una implementación de sharepoint; como segunda medida,. 18.

(21) tampoco se tenía la seguridad de que la definición del proceso se fuera a basar en TSP o si se iba a basar en RUP. Con respecto a el estado actual del proceso, se consignó la información referente a este en la siguiente tabla.. En el proceso de Administración del conocimiento se tiene un repositorio en el cual se tienen almacenado una serie de documentación, el resultado de los proyectos y algunas Descripción plantillas, también hay información de esta índole dispersa entre general cada uno de los miembros del grupo de desarrollo; las plantillas no siguen ningún estándar, son desarrolladas de acuerdo al estilo del desarrollador y a las que se piden por parte de los clientes. En este momento cada desarrollador actualiza periódicamente el repositorio de los documentos (Hoja de vida del proyecto, cronogramas, actas, manuales, etc), pero este período no es el Detalle de la mismo para todos; se tienen unas carpetas en las cuales metodología también se tiene información sobre los proyectos en material actual impreso, también se tiene una política de backups que son almacenados en CD´s con versiones del código fuente de los proyectos y algunas personas usan carpetas compartidas de outlook. - No está centralizado. - No es de fácil acceso. - No es estructurado. Puntos de falla - No es completo. identificados - No cumple con los requisitos de un proceso formal de desarrollo. - No es confiable. - No es estándar ni el manejo ni la totalidad de los documentos que se utilizan. Herramientas de Se tiene un repositorio, se posee una aplicación WEB para el manejo con RUP, y hay esfuerzos y algo de conocimiento por Soporte un intento fallido de uso de sharepoint Reportes y entregables. - CD´s de backup - Documentos que cada integrate del grupo de desarrollo coloca en el repositorio - Folder de consignación de documentos impresos. La documentación referente al estado deseado del proceso de administración del conocimiento, se consignó en la siguiente tabla.. 19.

(22) Descripción general. Se desea un lugar digital en donde se pueda encontrar fácilmente orientación acerca del proceso de desarrollo yque sirva como un repositorio de ubicación de documentación de proyectos, fuentes de código y documentación de interes para la empresa; además de tener links a distintas referencias de lectura.. Herramientas que Una Wiki o uso de un portal de sharepoint, que se actualice se pueden fácil y continuamente implementar El QUALDEV process puede apoyar con todo el Know How acerca de centralización de la información, y su organización Diagnóstico de la para que sea de fácil acceso; también puede ayudar en la ayuda del definición de un proceso de calidad de desarrollo de software QUALDEV Process que sea ágil, y en definición de plantillas, checklists para cada etapa del proceso de desarrollo.. 3.3. ESTABLECIMIENTO En el momento de iniciar esta fase, se hicieron un par de análisis para poder resolver los temas en los que se tenía duda de la fase anterior; las conclusiones a las que se llegaron fueron las siguientes, con respecto al tema de la herramienta de centralización del conocimiento, se decidió implementar una wiki debido a que se tenía mayor conocimiento de cómo implementar esta y no tanto de cómo implementar un portal de sharepoint, además de las ventajas de búsqueda y presentación que ofrece a wiki. Por otro lado, con respecto a sobre cuál proceso se iba a basar el nuevo proceso a definir, se hizo una evaluación acerca de las ventajas y desventajas que ofrece el rup, se tiene que rup es una gran herramienta que si se implementa con todo el rigor que merece, puede de entrada dar un aseguramiento alto de calidad a un software, sin embargo aunque la intención con rup es que este fuese adaptable a las características de las empresas, sí resulta ser costoso, ya que se deben invertir muchos recursos para que funcione de manera correcta, ahora si no se invierten recursos y se intenta implementar, lo que pasa es que habría una sobrecarga de trabajo que finalmente converge en un proceso mal llevado y por ende un mal aseguramiento de la calidad; rup es un proceso para empresas que se pueden considerar entre medianas y grandes, la empresa en la que se trabajó no puede costear este asunto, por eso se decidió basar el proceso en TSP más concretamente en el QUALDEV process que resulta ser un poco más ágil. Ya habiendo definido este par de puntos inconclusos, se procedió a la realización del plan del proyecto, este plan quedó de la siguiente manera.. 20.

(23) Id. 1. 2. 3. 4. 5. 6. Duración Fecha Responsable estimada del Nombre de la Descripción de la desarrollo de Estimada de la Actividad Actividad Actividad la Actividad de Entrega (horas) Adaptación de la Inicio de la Noviembre Andrés Rubio fase de 2 Fase de 18 y Jorge Rojas Lanzamiento del Ejecución QUALDEV Process Adaptación de la Noviembre Andrés Rubio fase de Estrategia Estrategia 2 23 y Jorge Rojas del QUALDEV Process Adaptación de la Noviembre Andrés Rubio Análisis 2 fase de Análisis del 25 y Jorge Rojas QUALDEV Process Adaptación de la Noviembre Andrés Rubio Diseño 2 fase de Diseño del 28 y Jorge Rojas QUALDEV Process Instalacion y puesta Noviembre WIKI 10 Andrés Rubio a punto de la doku 29 wiki. Paso de Lanzamiento documentacion de 1 Diciembre 1 Andrés Rubio WIKI lanzamiento a la WIKI.. Paso de Estrategia documentacion de 7 WIKI estrategia a la WIKI. Paso de 8 Análisis WIKI documentacion de análisis a la WIKI. Paso de 9 Diseño WIKI documentacion de diseño a la WIKI. Cierre de Fase de Finalización establecimiento, 10 Fase de inicio de fase de Ejecución aprendizaje.. 21. 1. Diciembre 1 Andrés Rubio. 1. Diciembre 1 Andrés Rubio. 1. Diciembre 1 Andrés Rubio. 10. Diciembre 1 Andrés Rubio.

(24) 3.4. EJECUCIÓN Con respecto al desarrollo de esta fase del modelo IDEAL en este proyecto, el cronograma no se pudo cumplir a cabalidad por tareas propias de la empresa, las cuales tenían una mayor prioridad a las actividades de este proyecto, de todas formas se logró realizar toda la implementación de las tareas a realizar; una breve explicación de estas se expone a continuación basada en las actas de las reuniones realizadas para la definición de las distintas etapas del desarrollo para el proceso y por último la instalación y adecuación del espacio de centralización y administración del conocimiento. Se definieron 4 etapas del proceso de desarrollo, éstas son lanzamiento, estrategia, análisis y diseño; como se mencionó en la sección anterior, se tomó como base el QUALDEV process y la metodología fue más bien sencilla, se hizo una reunión por cada etapa; en cada reunión se hizo una explicación de la definición hecha por el grupo QUALDEV y de cada una de las tareas asociadas con la etapa, se discutieron un poco y se dejó una primera versión de la especificación, acto seguido se pasó a revisar la definición que hace RUP acerca del tema que se está tratando y se mira que puede aportar a la primer versión de la definición sin perder la noción de dejar el proceso lo más ágil posible, y con base en estas posibles adiciones y la primera versión de la especificación, se realiza la versión final. Luego se tiene la instalación del sitio de administración del conocimiento; se montó una dokuwiki y se le hicieron modificaciones tales como un menú lateral yla creación de unos namespaces para ingresar la información del proceso que se está definiendo, y para ingresar información acerca de los proyectos que se desarrollan en el momento en la empresa; se pasaron las definiciones realizadas de las etapas y se hizo una definición de cómo se deben manejar los proyectos en la wiki tomando como caso de prueba uno de los mismos. La estrategia que se siguió para el desarrollo de cada una de las tareas fue en primera instancia el realizar todas las reuniones concernientes a la definición de las etapas del desarrollo, se hizo de esta manera para poder aprovechar la motivación que tenía la empresa al inicio de este proyecto, ya que las tareas de definición tenían que ser realizadas conjuntamente con algún miembro del grupo de desarrollo de la empresa, esto quiere decir que se tenía cierta dependencia del tiempo que pudiese asignar la misma a este proyecto, por lo que se asumió que era mejor aprovechar ese entusiasmo inicial y terminar esas tareas dependientes desde un comienzo así las tareas que no dependieran de la empresa tan directamente se podían realizar con un tiempo un poco más holgado o al menos no con tanta presión como la que hubiese existido en el caso tal que se acerque la fecha final y se tengan problemas por la falta de realización de esas tareas porque. 22.

(25) la empresa no pudo asignar el tiempo necesario para las mismas, fue una forma de mitigar ese riesgo; de esto se deduce que en segunda instancia se realizó la instalación y adecuación del espacio de administración de conocimiento y por último se colocaron las definiciones realizadas con anterioridad en el mismo. 3.5. APRENDIZAJE En secciones anteriores se explicó que en este paso del modelo IDEAL, se realizan los análisis de cumplimiento de los distintos objetivos que se trazaron en fases anteriores, por eso se trae a colación de nuevo, el listado de los objetivos de este proyecto, con la adición de la evaluación de los mismos. Como se expuso en la fase de diagnóstico, los objetivos de este proyecto se encuentran discriminados por niveles, y a medida que aumenta el nivel, aumenta el grado de especificación de los mismos; esto significa que para el logro de los objetivos de los niveles superiores se deben cumplir todos y cada uno de los objetivos de los niveles inferiores; de este hecho se parte para analizar el cumplimiento de los objetivos trazados. Para empezar se procede a analizar los objetivos que se encuentran en el tercer nivel, estos son: •. Definición y adaptación de un espacio para la administración de conocimiento ( DokuWiki ). Como se mencionó en la fase de ejecución, se implantó una herramienta para la administración del conocimiento en la empresa, y se adaptó para unas primeras necesidades de la misma, centrándola en primera instancia en el manejo de la información concerniente a todo lo concerniente con el área de desarrollo, para ser más exactos se crearon tres espacios, un primer espacio para almacenar la información del proceso de desarrollo que se definió, un segundo espacio para consignar la información pertinente a los proyectos que se llevan a cabo en el momento y un tercer espacio para almacenar plantillas, tutoriales e investigaciones que sean comunes para los proyectos, para el proceso, etc. En un comienzo se intentó correr la herramienta en un ambiente basado en tecnología desarrollada por Microsoft, pero hubo muchas dificultades para que pudiese reconocer el php que se instaló en la máquina, por lo que se optó por instalar la herramienta en un servidor Apache; por otro lado, la máquina en la cual se instaló la herramienta es una máquina virtual, a petición de la empresa, pero también causa inconvenientes de manera un tanto esporádica, ya que se debe estar muy pendiente de la máquina real que contiene a la virtual, si esta se cae o sufre algún reinicio, toca subir prácticamente dos máquinas para poder dejar la aplicación disponible de nuevo, esto significa el realizar el doble de trabajo cuando los inconvenientes ocurran. Sin embargo, la empresa expresó su satisfacción con la instalación realizada y dio como aprobado este objetivo,. 23.

(26) planteando las siguientes mejoras encontradas a causa de este desarrollo; primero reconocen que esta herramienta permite una buena organización de la información, segundo, es de fácil uso y se le puede hacer mantenimiento de la misma forma, tercero, puede ser usada por otras áreas de la empresa lo cual van a empezar a implementar, cuarto, es tener algo que no se tenía antes, y por último permite estandarizar de alguna manera el uso de la información hecho que antes no se hacía.. •. Definir las fases (Análisis, Diseño, Lanzamiento y Estrategia), las actividades necesarias por fase y sus plantillas. Con respecto a este objetivo, se había mencionado el que se realizaron reuniones con partes de la empresa para explicar estas fases del QUALDEV process y alimentarlas con la propuesta de RUP para así hacer la definición de las mismas, los inconvenientes que se expresaron en la ejecución de esta objetivo son en primera instancia el que en la etapa de diseño no hubiesen plantillas o ejemplos claros de los resultados de las actividades, esto tiene su origen en que en las reuniones de especificación de cada una de las etapas, se tenía apoyo en los formatos y en los documentos que se tienen en la definición del proceso, y aunque las tareas de la etapa de diseño son obvias y se entienden por parte de personas que se encuentren directamente ligadas con el desarrollo, si parece que hay una deficiencia de apoyo para que lo puedan entender personas que no sean tan ligadas a este punto; en segunda instancia se encuentra el hecho de no tener el proceso en un gráfico que represente bien la correlación de las etapas del proceso en una línea de tiempo, aunque se tiene la información consignada en los documentos, si resulta más fácil para una persona el basarse en un gráfico, ya que puede resultar algo tedioso remitirse a todos los documentos de especificación; y por último el que el proceso se encuentre definido para arquitecturas orientadas a componentes, revisando las especificaciones se pueden adaptar para no tener el proceso ligado a una arquitectura, el proceso debería ser general para cualquier estilo de arquitectura que se maneje en las empresas. En la otra mano se planteó por parte de la empresa la aceptación de este objetivo y se concluyó que éste había sido cumplido en su totalidad, y la empresa expresó que los beneficios que trajo esta primera aproximación al proceso son las siguientes; primero, se creó una conciencia del trabajo en equipo; segundo, se tiene una organización de proceso para desarrollar en la misma; tercero, aunque la empresa tenía un proceso de desarrollo, este no era muy específico, esta tarea permitió sentar dejar radicado parte del nuevo proceso a implantar; cuarto, el tema de la matriz de rastreabilidad es un punto que no se tiene muy en cuenta pero que el uso y mantenimiento de las misma puede ser de gran beneficio para la empresa; y por último el hecho de poder tener un acercamiento o una sensibilización del propósito de cada una de las etapas, aunque a. 24.

(27) primera vista se vean muy obvias, ese ejercicio de las reuniones permitió vislumbrar más claramente el motivo de cada etapa y porqué se deben realizar cada una de sus actividades, fue como abrir esa ventana que permitió observar la importancia de cada una de las actividades que se deben realizar. Ya se nombraron los inconvenientes y mejoras que trajeron los desarrollo de los objetivos del último nivel, y su aceptación por parte de la empresa, esto ya asegura un cumplimiento de los objetivos trazados en los dos niveles restantes, de todas formas se procede a realizar una pequeña explicación del porqué se asumió con consentimiento de la empresa, la realización de estos objetivos. Primero se procede a realizar la explicación con los objetivos discriminados en el nivel 2. •. Administrar y centralizar el conocimiento. Este objetivo se logra con la implantación de la DokuWiki, herramienta que se va a utilizó para el logro de este objetivo.. •. Definición formal de los procesos de desarrollo de software en la empresa. Este objetivo se logró por medio de las reuniones realizadas para la definición de las cuatro etapas mencionadas anteriormente; cabe resaltar que para efectos de este proyecto, solo se había acordado la definición de estas etapas del proceso, con base en esto se asume que este objetivo fue logrado, aunque existe interés por parte de la empresa en terminar de definir las otras etapas del proceso.. •. Integrar el proceso de Construcción de Software con el Proceso de Administración de Conocimiento. Como se mencionó en la fase de ejecución, se dejó la documentación pertinente a las definiciones realizadas de las etapas en el espacio de administración de conocimiento, este hecho permite esa integración entre ambos procesos, además el hecho de haber creado los espacios para que se consigne la información pertinente a cada uno de los proyectos existentes en la empresa también ayuda a concretar este punto.. Ahora se va a realizar la explicación con el objetivo del primer nivel. •. Implementación de un sistema de administración de conocimiento que apoye un proceso de construcción de software basado en estándares de. 25.

(28) calidad. Para la aceptación de este objetivo se parte del hecho que todos los objetivos planteados en los niveles inferiores fueron cumplidos y aceptados; pero entrando un poco más en la explicación, se tiene que se implementó un sistema de administración y centralización de conocimiento, se realizó la definición de un proceso que está basado en una propuesta de proceso que contempla el manejo de la calidad y que se encuentra catalogado como un estándar como lo es TSP, y se hizo una combinación entre estos dos temas de manera que se logró el integrar tanto el proceso de desarrollo basado en estándares de calidad con el proceso de administración del conocimiento que es en otras palabras la definición de este objetivo. Para concluir con esta fase, se identificaron con la empresa las siguientes lecciones aprendidas: • • • •. •. Una herramienta como la dokuwiki permite administrar el conocimiento de manera fácil, y es una muy buena opción para apoyar el proceso. Aunque la dokuwiki es fácil de mantener, no es muy fácil de entender a primera vista, se debería tener una especie de mapa del sitio para que una persona ajena al manejo de la misma la pueda navegar sin complicaciones. Se debería tener el proceso representado por una gráfica para así poder hacer más fácil su entendimiento. Aunque el proceso mantiene controles y manejo de la calidad en cada una de sus etapas, si resulta conveniente el tener un documento aparte que explique el manejo que este brinda a la calidad, en otras palabras un manual de manejo de la calidad, esto para apoyar una posible certificación en calidad. Se debe tener cuidado en el manejo de los namespaces en la dokuwiki yde los links que se hagan a los mismos, para poder hacer esta herramienta aún más mantenible, que estos links no queden sujetos a todo el path del destino.. También se tienen las siguientes propuestas o puntos a mejorar. • •. Se debería llevar en el QUALDEV Community una hoja de vida con lo trabajado en las empresas, que se ha hecho y que queda por hacer. Se desea terminar las definiciones de los distintos procesos y fases, sobre todo los de soporte; en la empresa.. 3.6. PROPUESTA DE MANEJO DE LA WIKI Como se explicó en secciones anteriores se implantó una wiki en la empresa, como herramienta de administración y centralización del conocimiento de la misma; siendo esta una herramienta nueva en la organización, se realizó un. 26.

(29) conjunto de documentos de apoyo para la utilización y entendimiento de la misma, que se va a explicar a continuación. En primera medida se encuentra el documento de instalación de la wiki; la instalación se hizo de acuerdo al documento que tiene el grupo QUALDEV, y de la explicación que hay en el sitio de splitbrain de donde se consiguió la 39 herramienta ; se tomó el documento del grupo QUALDEV y se colocó en el espacio designado para tutoriales, plantillas e investigaciones de la wiki de la empresa; el documento se puede encontrar en la siguiente referencia.40 Un segundo elemento del conjunto, es el documento de adaptación de la wiki; a la herramienta se le hicieron un par de modificaciones para que sea un poco más amigable de manejar, cambios como un menú lateral y una opción para poder exportar los documentos a formato pdf, etc; estas modificaciones fueron 41 implementadas según un tutorial de cambios realizado por el grupo QUALDEV ; este documento también fue consignado en el espacio destinado para este fin en la wiki de la empresa. Por último se tiene un último documento con la forma de uso de la herramienta, este documento se realizó tomando como base el manual que tiene el grupo 42 QUALDEV para el uso de su wiki , con algunos pequeños cambios que se van a mencionar a continuación. La organización que se implementó para el manejo de los espacios se adecuó a la implementación de los espacios en la empresa; la jerarquía de los mismos se puede ver reflejada en el siguiente ejemplo. •. site El propósito de este namespace es contener la información general de la empresa. o proceso En este namespace se encuentra la información general del proceso de desarrollo.. 39. Installation. Recuperado el 3 de Diciembre del 2005: http://wiki.splitbrain.org/wiki:install Grupo QUALDEV. Instalación dokuwiki. Recuperado el 3 de Diciembre del 2005, del sitio web del grupo QUALDEV de la Universidad de los Andes: http://chie.uniandes.edu.co/~changeset/process/doku.php?id=development:resources:tutorials:tools :instalacion_dokuwiki 41 Grupo QUALDEV. Adaptación de dokuwiki. Recuperado el 3 de Diciembre del 2005, del sitio web del grupo QUALDEV de la Universidad de los Andes: http://chie.uniandes.edu.co/~changeset/process/doku.php?id=development:resources:tutorials:tools :adaptacion_dokuwiki 42 Grupo QUALDEV. Uso dokuwiki. Recuperado el 3 de Diciembre del 2005, del sitio web del grupo QUALDEV de la Universidad de los Andes: http://chie.uniandes.edu.co/~changeset/process/doku.php?id=development:resources:tutorials:tools :uso_dokuwiki 40. 27.

(30) desarrollo En este espacio se encuentran las descripciones de las fases o procesos que van ligados directamente al desarrollo. soporte En este espacio se consignan las descripciones de los procesos que dan soporte al desarrollo y ayudan para llevar un proyecto a buen término. o proyectos Acá se consigna la información referente a los proyectos que se están llevando a cabo proyecto1 Este es un espacio en el cual se inserta la información pertinente al proyecto1. o recursos En este espacio se colocan los recursos adicionales como plantillas y tutoriales que están a disposición para los desarrolladores. plantillas Acá se pueden encontrar las plantillas necesarias para el desarrollo que se encuentren definidas para el uso de los desarrolladores. tutoriales En este espacio se tienen los tutoriales de instalación y uso de las herramientas que soportan el desarrollo en la empresa. investigaciones Acá se consigna la información referente a investigaciones sobre herramientas o temas referentes al desarrollo que hallan sido realizadas en la empresa. También se anexó al documento una explicación acerca de cómo se deben crear los namespaces, tomando como ejemplo el caso de insertar un nuevo proyecto en el espacio destinado para este fin; adicionalmente se agregó una explicación de cómo se deben manejar los vínculos internos en la wiki, haciendo énfasis en el hecho de no intentar crearlos colocando toda la ruta del namespace ya que esto puede dificultar el mantenimiento de la herramienta; de resto es muy similar al documento realizado por el grupo QUALDEV.. 28.

(31) 4. CONCLUSIONES 4.1. CONCLUSIÓN GENERAL Un proceso de administración del conocimiento puede ser mejorado de manera sustancial si se apoya en una herramienta que cumpla las características de una dokuwiki; una herramienta que sea fácil de usar, que proporcione una interfaz agradableal usuario y que sea mantenible en el tiempo; pero sobre todo que permita realizar una buena organización de la información que se va a mantener. Agregando a esto, que la herramienta es una aplicación web, que puede ser accesada desde varios lados. 4.2. CONCLUSIONES ESPECIFICAS 4.2.1. Un proceso de administración del conocimiento se mejora en un alto nivel si se apoya en una herramienta como una dokuwiki. 4.2.2. Una ayuda al entendimiento de los procesos puede ser el reflejarlos en un gráfico que sintetice el mismo en una línea de tiempo. 4.2.3. Un proceso de desarrollo no debería ir ligado a una arquitectura en particular, debería ser independiente tanto del tipo de arquitectura que se use como de las características de la tecnología en el cual se pueda desenvolver. 4.2.4. Aunque en el proceso planteado por el grupo QUALDEV, se tiene una noción de manejo de la calidad en el producto, si es importante el plasmar esa estrategia general de calidad en un documento aparte para así poder ayudar más a una posible certificación de calidad..

(32) BIBLIOGRAFÍA. SM Model: A Practical 1. Gremba, Jennifer., Myers, Chuck.(1997). The IDEAL Guide for Improvement. Recuperado el 30 de Diciembre del 2005: http://www.sei.cmu.edu/ideal/ideal.bridge.html . 2. Grupo QUALDEV. Qualdev community. Recuperado el 28 de Diciembre del 2005, del sitio web del grupo QUALDEV de la Universidad de los Andes: http://chie.uniandes.edu.co/~changeset/process/doku.php?id=development:proj ects:empresas:empresas 3. Grupo QUALDEV. Qualdev Group. Recuperado el 28 de Diciembre del 2005, del sitio web del grupo QUALDEV de la Universidad de los Andes: http://chie.uniandes.edu.co/~changeset/process/doku.php?id=presentacion 4. Grupo QUALDEV. Qualdev - Portal de Desarrollo. Recuperado el 28 de Diciembre del 2005, del sitio web del grupo QUALDEV de la Universidad de los Andes: http://chie.uniandes.edu.co/~changeset/process/doku.php?id=site:projects 5. Grupo QUALDEV. QUALDEV process. Recuperado el 28 de Diciembre del 2005, del sitio web del grupo QUALDEV de la Universidad de los Andes: http://chie.uniandes.edu.co/~changeset/pdescription/ 6. Grupo QUALDEV. Instalación dokuwiki. Recuperado el 3 de Diciembre del 2005, del sitio web del grupo QUALDEV de la Universidad de los Andes: http://chie.uniandes.edu.co/~changeset/process/doku.php?id=development:res ources:tutorials:tools:instalacion_dokuwiki. 7. Grupo QUALDEV. Adaptación de dokuwiki. Recuperado el 3 de Diciembre del 2005, del sitio web del grupo QUALDEV de la Universidad de los Andes: http://chie.uniandes.edu.co/~changeset/process/doku.php?id=development:res ources:tutorials:tools:adaptacion_dokuwiki 8. Grupo QUALDEV. Uso dokuwiki. Recuperado el 3 de Diciembre del 2005, del sitio web del grupo QUALDEV de la Universidad de los Andes: http://chie.uniandes.edu.co/~changeset/process/doku.php?id=development:res ources:tutorials:tools:uso_dokuwiki. 9. Installation. Recuperado el 3 de Diciembre del 2005: http://wiki.splitbrain.org/wiki:install 10. Rational Unified Process. Recuprado el 30 de Diciembre del 2005: http://en.wikipedia.org/wiki/Rational_Unified_Process 11. Rational Unified Process (RUP). Recuperado el 30 de Diciembre del 2005: http://mgmt.iisc.ernet.in/~hema/SoftwareArchitecture_Session1.htm.

(33)