Herramienta para Administración de Proyectos en Equipos Autodirigidos que Desarrollan Software de Calidad Edición Única

Texto completo

(1)INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY CAMPUS MONTERREY PROGRAMA DE GRADUADOS EN ELECTRÓNICA, COMPUTACIÓN, INFORMACIÓN Y COMUNICACIONES. HERRAMIENTA PARA ADMINISTRACIÓN DE PROYECTOS EN EQUIPOS AUTODIRIGIDOS QUE DESARROLLAN SOFTWARE DE CALIDAD. TESIS PRESENTADA COMO REQUISITO PARCIAL PARA OBTENER EL GRADO ACADEMICO DE: MAESTRO EN ADMINISTRACIÓN DE TECNOLOGÍAS DE INFORMACIÓN POR: SAÚL ARMANDO SOTO VÉLIZ. MONTERREY, N.L.. DICIEMBRE 2003.

(2) INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY CAMPUS MONTERREY PROGRAMA DE GRADUADOS EN ELECTRÓNICA, COMPUTACIÓN, INFORMACIÓN Y COMUNICACIONES. HERRAMIENTA PARA ADMINISTRACIÓN DE PROYECTOS EN EQUIPOS AUTODIRIGIDOS QUE DESARROLLAN SOFTWARE DE CALIDAD. TESIS PRESENTADA COMO REQUISITO PARCIAL PARA OBTENER EL GRADO ACADEMICO DE: MAESTRO EN ADMINISTRACIÓN DE TECNOLOGÍAS DE INFORMACIÓN POR: SAÚL ARMANDO SOTO VÉLIZ. MONTERREY, N.L.. DICIEMBRE 2003.

(3) INSTITUTO TECNOLÓGICO DE ESTUDIOS SUPERIORES DE MONTERREY DIVISIÓN DE ELECTRÓNICA, COMPUTACIÓN, INFORMACIÓN Y COMUNICACIONES PROGRAMAS DE GRADUADOS EN ELECTRÓNICA, COMPUTACIÓN, INFORMACIÓN Y COMUNICACIONES Los miembros del comité de tesis recomendamos que la presente tesis del Ing. Saúl Armando Soto Véliz sea aceptada como requisito parcial para obtener el grado académico de Maestro en Administración de Tecnologías de Información. Comité de tesis:. __________________________________ Lic. Leticia Almaguer Flores Asesor. __________________________________ Lic. Adriane Lorena Piñones Inclán Sinodal. __________________________________ Ing. Fernando Soto Chiunti Sinodal. _________________________________________ David A. Garza Salazar Director del Programa de Graduados en Electrónica, Computación, Información y Comunicaciones. Diciembre de 2003.

(4) Dedicatoria. A Dios, por haberme dado la mejor familia que nunca cambiaría; además, por haberme dado las herramientas para llegar a la preparación académica con la que cuento. Especialmente a mi sobrina Paola Teresa, que desde que nació ha sido una motivación extra para seguir adelante en mis proyectos. A mis Abuelos Jesusita, Socorro (†), Adrián (†) y Eugenio (†), que en todo momento me apoyaron y me alentaron en seguir superándome en mis estudios. A mis padres Rufina y José Angel, por su apoyo incondicional y por su gran esfuerzo por llevar a cabo mis sueños de terminar mis estudios tanto de profesional como de maestría. A mi hermana Tere y mi hermano Angel, que gracias a ellos he pasado los mejores momentos de mi vida; además, han sido pieza clave para mi deseo constante de superación. A mis tías Alma, Eva y Guadalupe y a mis tíos Adrián, Armando, Edmundo y Víctor, que siempre me motivaron a prepararme lo mejor posible tanto académicamente como profesionalmente..

(5) Agradecimientos. A Dios, por darme todo lo que tengo y por guiarme por el mejor camino. A mi familia, por ayudarme en todo momento a la realización de mis metas. A mis maestros, por proporcionarme su tiempo y sus conocimientos para lograr tener la preparación académica con la que cuento. A la Lic. Leticia Almaguer, por el apoyo brindado para la realización de esta tesis. A la Lic. Adirane Piñones, por su apoyo incondicional tanto académico como profesional. A mis amigos, que me han apoyado en los buenos y malos momentos de mi vida..

(6) Resumen. La Administración de Proyectos es una disciplina que aplica principios, conceptos, herramientas y técnicas para mejorar el desarrollo del proyecto y la efectividad organizacional; así como también, incrementa las probabilidades de éxito en los proyectos. A medida que las organizaciones han reconocido la importancia de la Administración de Proyectos, ésta se ha conv ertido en un punto central para los esfuerzos de mejora. Actualmente la guía del Instituto de Administradores de Proyectos (Project Management Institute) es considerada como uno de los principales estándares en el mundo para las organizaciones que aplican metodologías de Administración de Proyectos. Las organizaciones han venido creando una gran evidencia para demostrar que los equipos logran más que los individuos; sin embargo, a pesar de esto se siguen construyendo estructuras organizacionales indiv idualistas. La gran mayoría de las organizaciones actuales, buscan una nueva arquitectura de equipos cada vez más interfuncionales, autodirigidos y orientados al logro de objetivos comunes; es decir, buscan competitividad en vez de competencia. Se ha observado que el ambiente competitivo de los negocios actuales demanda incrementar la productividad, mejorar la calidad, tiempos de respuesta cortos y bajos costos; para esto, muchas industrias han alcanzado el éxito al remplazar la relación jerárquica jefe-subordinado con Equipos de Trabajo de Alto Desempeño o Equipos Autodirigidos, en un ambiente de equipo donde la gente no es manejada, controlada o supervisada. El adoptar estándares de Calidad en el Software, es una situación que ha despertado la inquietud y el interés de muchas empresas en el ámbito mundial por mejorar sus propios procesos de desarrollo y no quedarse fuera del mercado; por tal motivo, la industria mundial de Desarrollo de Software se ha preocupado por mejorar sus capacidades en el Desarrollo de Software de Calidad. El presente trabajo consiste de una propuesta de una herramienta que contiene los elementos críticos de éxito para llevar a cabo la efectiva Administración de Proyectos en Equipos Autodirigidos que desarrollan Software de Calidad..

(7) Tabla de Contenido. Dedicatoria..................................................................................................................... Agradecimientos........................................................................................................... Resumen......................................................................................................................... Tabla de Contenido...................................................................................................... Lista de Figuras............................................................................................................... Lista de Gráficas............................................................................................................ Lista de Tablas................................................................................................................. iv v vi vii x xi xii. Capítulo 1....................................................................................................................... 1. Introducción......................................................................................................... 1.1. Antecedentes Generales........................................................................... 1.2. Objetivo........................................................................................................ 1.3. Metodología................................................................................................ 1.4. Producto Final.............................................................................................. 1.5. Contribución................................................................................................ 1.6. Trabajos Futuros............................................................................................ 1 1 1 2 3 3 4 4. Capítulo 2....................................................................................................................... 2. Desarrollo de Software de Calidad................................................................... 2.1. Definición de Software y Desarrollo de Software.................................... 2.2. Características del Desarrollo de Software.............................................. 2.3. Evolución del Software............................................................................... 2.4. Ciclo de Vida del Desarrollo de Software................................................ 2.5. Definición de Calidad................................................................................ 2.6. Ingeniería de Software y Software de Calidad....................................... 2.7. Características del Software de Calidad................................................. 2.8. Estándares para la Calidad en el Software............................................. 2.9. La Programación Extrema (eXtreme Programming).............................. 2.10. Conclusiones............................................................................................... 5 5 5 6 7 8 9 10 11 13 14 20. Capítulo 3....................................................................................................................... 3. Administración de Proyectos.............................................................................. 3.1. Definición de Proyecto............................................................................... 3.2. Organización del Proyecto........................................................................ 3.3. Definición de Administrador...................................................................... 3.4. Administración de Proyectos.................................................................... 3.5. Gestiones de la Administración de Proyectos........................................ 3.6. Beneficios de la Administración de Proyectos........................................ 3.7. Conclusiones................................................................................................. 22 22 22 23 25 27 28 45 47. vii.

(8) Capítulo 4....................................................................................................................... 4. Equipos de Trabajo de Alto Desempeño.......................................................... 4.1. Definición de Equipo.................................................................................. 4.2. Fases en el Desarrollo de Equipos............................................................. 4.3. Definición de Equipos de Trabajo de Alto Desempeño......................... 4.4. Origen de los Sistemas de Trabajo de Alto Desempeño........................ 4.5. Características de los Equipos de Alto Desempeño.............................. 4.6. Beneficios de utilizar Equipos de Trabajo de Alto Desempeño............. 4.7. Directrices para incrementar el Éxito en los Equipos Autodirigidos...... 4.8. Caso de Equipos Autodirigidos de Chevron........................................... 4.9. Conclusiones................................................................................................. 48 48 48 49 50 51 53 54 55 58 66. Capítulo 5....................................................................................................................... 5. Metodología de Investigación.......................................................................... 5.1. Objetivo........................................................................................................ 5.2. Hipótesis........................................................................................................ 5.3. Metodología................................................................................................ 5.4. Tipo de Investigación.................................................................................. 5.5. Población..................................................................................................... 5.6. Muestra......................................................................................................... 5.7. Definición de Variables.............................................................................. 5.8. Medición de Variables............................................................................... 5.9. Recolección de Información..................................................................... 5.10. Análisis de la Información........................................................................ 5.11. Conclusiones............................................................................................... 67 67 67 67 68 68 69 70 71 73 74 75 76. Capítulo 6....................................................................................................................... 6. Caso de estudio del Departamento de Proyectos Especiales de la Vicerrectoría de Tecnologías de Información, del Sistema ITESM..................... 6.1. Vicerrectoría de Tecnologías de Información........................................ 6.1.1. Antecedentes de la Organización................................................. 6.1.2. Misión y Visión..................................................................................... 6.1.3. Estrategia............................................................................................ 6.1.4. Funciones que se desempeñan en la Organización.................... 6.2. Departamento de Proyectos Especiales................................................. 6.2.1. Proyectos............................................................................................. 6.2.2. Características del ambiente de trabajo....................................... 6.3. Transición de las herramientas de Administración de Proyectos de Software en Equipos Autodirigidos.................................................................. 6.3.1. Herramientas que en el pasado apoyaban la Administración de Proyectos en Equipos Autodirigidos que desarrollan Software de Calidad.............................................................................................. 6.3.2. Herramientas actuales para la Administración de Proyectos de Software en Equipos Autodirigidos....................................................... 6.4. Conclusiones................................................................................................. 77 77 77 78 79 80 81 82 82 83 85 86 87 90. viii.

(9) Capítulo 7....................................................................................................................... 7. Evaluación de Herramientas y Análisis de Resultados.................................... 7.1. Evaluación de Herramientas..................................................................... 7.2. Análisis de Resultados................................................................................. 7.2.1. Análisis de Resultados por Criterio................................................... 7.2.1.1. Enfoque a la Administración de Proyectos............................ 7.2.1.2. Enfoque a los Equipos de Trabajo........................................... 7.2.1.3. Enfoque al Desarrollo de Software.......................................... 7.2.1.4. Seguridad en las herramientas................................................ 7.2.2. Análisis de Resultados Generales..................................................... 7.3. Conclusiones................................................................................................. 91 91 91 98 98 98 106 109 111 113 115. Capítulo 8....................................................................................................................... 8. Herramienta para la Administración de Proyectos en Equipos Autodirigidos que desarrollan Software de Calidad........................................... 8.1. Administración de Proyectos..................................................................... 8.2. Equipos de Trabajo de Alto Desempeño................................................. 8.3. Desarrollo de Software............................................................................... 8.4. Consideraciones de Seguridad................................................................. 8.5. Conclusiones................................................................................................. 116. Capítulo 9....................................................................................................................... 9. Conclusiones y Trabajos Futuros......................................................................... 9.1. Conclusiones................................................................................................ 9.2. Trabajos Futuros............................................................................................ 136 136 136 138. Bibliografía………………………………………………………………………………… VITA................................................................................................................................... 139 143. 116 117 129 132 134 135. ix.

(10) Lista de Figuras. Figura 2.1 Ciclo de Vida del Desarrollo de Sistemas................................................. Figura 3.1 Procesos de la Administración de Proyectos........................................... Figura 4.1 Fases en el Desarrollo de Equipos.............................................................. Figura 6.1 Estructura Organizacional del Sistema Tecnológico de Monterrey...... Figura 6.2 Estructura Organizacional de la VITI.......................................................... Figura 8.1 Administración de Proyectos en Equipos Autodirigidos que desarrollan Software de Calidad................................................................................ Figura 8.2 Lluvia de Ideas............................................................................................. Figura 8.3 Plantillas WBS................................................................................................ Figura 8.4 Inspección.................................................................................................... Figura 8.5 Estimación Análoga de Costos.................................................................. Figura 8.6 Diagrama de Precedencia y de Flechas................................................. Figura 8.7 Estimación Análoga de Tiempo................................................................. Figura 8.8 Diagrama PERT............................................................................................. Figura 8.9 Lista de Comprobación de Riesgos.......................................................... Figura 8.10 Diagrama de Flujo..................................................................................... Figura 8.11 Análisis Costo / Beneficio para planear la Calidad.............................. Figura 8.12 Recursos Humanos..................................................................................... Figura 8.13 Asignación de Administradores de Proyectos....................................... Figura 8.14 Asignación de Usuarios a Proyectos y a Equipos de Trabajo.............. Figura 8.15 Autoasignación del Trabajo..................................................................... Figura 8.16 Asignación de Recursos de acuerdo a Habilidades............................ Figura 8.17 Coevaluación del Desempeño............................................................... Figura 8.18 Etapas de Desarrollo de Software XP...................................................... Figura 8.19 Manejo de versiones................................................................................. Figura 8.20 Asignación de Roles.................................................................................. Figura 8.21 Reporte de Errores..................................................................................... Figura 8.22 Seguridad.................................................................................................... 8 24 49 77 79 116 117 118 118 119 120 121 122 123 123 125 126 128 129 130 130 131 132 132 133 133 134. x.

(11) Lista de Gráficas. Gráfica 7.1 Metodología de Administración de Proyectos.................................. Gráfica 7.2 Alcance.................................................................................................. Gráfica 7.3 Costo....................................................................................................... Gráfica 7.4 Tiempo.................................................................................................... Gráfica 7.5 Integración............................................................................................. Gráfica 7.6 Riesgos.................................................................................................... Gráfica 7.7 Calidad................................................................................................... Gráfica 7.8 Recursos Humanos................................................................................ Gráfica 7.9 Comunicación....................................................................................... Gráfica 7.10 Abastecimiento................................................................................... Gráfica 7.11 Administrador de Proyectos............................................................... Gráfica 7.12 Multiproyectos...................................................................................... Gráfica 7.13 Generación de Reportes.................................................................... Gráfica 7.14 Asignación de Equipos....................................................................... Gráfica 7.15 Asignación de Recursos de acuerdo a Habilidades...................... Gráfica 7.16 Asignación de Sueldos........................................................................ Gráfica 7.17 Retroalimentación a los Equipos de Trabajo................................... Gráfica 7.18 Coevaluación del Desempeño entre Integrantes del Equipo de Trabajo......................................................................................................................... Gráfica 7.19 Metodología de Desarrollo de Software.......................................... Gráfica 7.20 Manejo de Versiones........................................................................... Gráfica 7.21 Asignación de Roles de Desarrolladores.......................................... Gráfica 7.22 Manejo de Errores................................................................................ Gráfica 7.23 Control de Acceso.............................................................................. Gráfica 7.24 Integración de Personal Externo al Proyecto................................... Gráfica 7.25 Información Restringida...................................................................... Gráfica 7.26 Porcentaje obtenido por las herramientas de acuerdo al enfoque........................................................................................................................ 99 99 100 100 101 102 102 103 103 104 105 105 106 106 107 107 108 108 109 110 110 111 111 112 113 114. xi.

(12) Lista de Tablas. Tabla 3.1 Técnicas y/o Herramientas para los procesos de la gestión de Integración.................................................................................................................... Tabla 3.2 Técnicas y/o Herramientas para los procesos de la gestión de Alcance.......................................................................................................................... Tabla 3.3 Técnicas y/o Herramientas para los procesos de la gestión de Tiempo............................................................................................................................ Tabla 3.4 Técnicas y/o Herramientas para los procesos de la gestión de Costo.............................................................................................................................. Tabla 3.5 Técnicas y/o Herramientas para los procesos de la gestión de Calidad.......................................................................................................................... Tabla 3.6 Técnicas y/o Herramientas para los procesos de la gestión de Recursos Humanos........................................................................................................ Tabla 3.7 Técnicas y/o Herramientas para los procesos de la gestión de Comunicación.............................................................................................................. Tabla 3.8 Técnicas y/o Herramientas para los procesos de la gestión de Riesgos............................................................................................................................ Tabla 3.9 Técnicas y/o Herramientas para los procesos de la gestión de Abastecimiento............................................................................................................. Tabla 3.10 Encuesta a compañías sobre sus proyectos.......................................... Tabla 7.1 Características generales del producto................................................... Tabla 7.2 Enfoque a la Administración de Proyectos............................................... Tabla 7.3 Enfoque a los Equipos de Trabajo.............................................................. Tabla 7.4 Enfoque al Desarrollo de Software............................................................. Tabla 7.5 Seguridad en las herramientas................................................................... Tabla 7.6 Porcentaje obtenido por las herramientas de acuerdo al enfoque...... 30 32 34 36 38 40 41 43 45 46 93 94 95 96 97 114. xii.

(13) Capítulo 1 1. Introducción En este capítulo se presenta una síntesis del contenido general de esta investigación. Primeramente se mencionan los antecedentes de la investigación, posteriormente el objetivo del estudio, luego una breve explicación de la metodología utilizada, después se menciona el producto final obtenido con la investigación; finalmente se da a conocer la contribución del producto y los posibles trabajos futuros que se pueden desarrollar basándose en esta. 1.1. Antecedentes Generales Los proyectos son críticos para el éxito de cualquier organización. Las actividades de dichos proyectos son las que dan como resultado productos, servicios, entornos, procesos y organizaciones nuevas o mejoradas. Los proyectos incrementan las ventas, mejoran la satisfacción de los clientes, reducen costos, mejoran el ambiente de trabajo y dan otros beneficios como resultado. La Administración de Proyectos es una disciplina que aplica principios, conceptos, herramientas y técnicas para mejorar el desarrollo del proyecto y la efectividad organizacional; además, esta metodología agrega valor mediante el incremento de las probabilidades de éxito en los proyectos. La Administración de Proyectos efectiva requiere esfuerzos en conjunto de los participantes directos e indirectos del proyecto (equipo del proyecto, clientes y demás partes interesadas). A medida que las organizaciones han reconocido la importancia de la Administración de Proyectos para su éxito, ésta se ha conv ertido en un punto central para los esfuerzos de mejora. Actualmente la guía del Instituto de Administradores de Proyectos (Project Management Institute) es considerada como uno de los principales estándares en el mundo para las organizaciones que aplican metodologías de Administración de Proyectos. Por otro lado, a lo largo de la historia de las organizaciones, se ha venido creando una gran evidencia para demostrar que los equipos logran más que los individuos; sin embargo, conociendo estos antecedentes, aunque suene ilógico, se siguen construyendo estructuras organizacionales individualistas. La gran mayoría de las organizaciones en el mundo de hoy en día, buscan una nueva arquitectura de equipos cada vez más interfuncionales, autodirigidos y orientados al logro de objetivos comunes; es decir, buscan competitividad en vez de competencia. Se considera que para lograr el éxito y sobrevivir en el gran ambiente competitivo de la actualidad se requiere una organización que logre una cultura de trabajo en equipo. El ambiente competitivo actual de los negocios demanda el.

(14) incremento de la productividad, mejora de la calidad, tiempos de respuesta cortos y bajos costos. Muchas corporaciones han alcanzado el éxito al remplazar la -subordinado con Equipos de Trabajo de Alto Desempeño, en un ambiente de equipo donde la gente no es manejada, controlada o supervisada. Finalmente se sabe que en los últimos años, la industria mundial de Desarrollo de Software se ha preocupado por mejorar sus capacidades en el Desarrollo de Software de Calidad. Las empresas están invirtiendo en la mejora de los procesos de desarrollo para poder distinguirse en el mercado. El área encargada del aseguramiento y de la Calidad en el Software es conocida como Ingeniería de Software. Se han definido varios modelos basados en las experiencias exitosas de la Ingeniería de Software que sirven de guía para las mejoras y unifican los criterios de evaluación de las empresas, tal como el modelo estadounidense conocido como Modelo de Capacidad de Madurez (Capability Maturity Model), considerado uno de los más reconocidos mundialmente. El adoptar estándares de Calidad en el Software, es una situación que ha despertado la inquietud y el interés de muchas empresas mejorar sus propios procesos de desarrollo y no quedarse fuera del mercado. Para las empresas medianas y pequeñas los principales problemas que impiden adoptar un estándar de Calidad en el Software son: la selección del modelo a seguir, su comprensión e interpretación y el costo de la implantación en la empresa. Otra razón es que los modelos de referencia mencionados son complejos, voluminosos y están definidos en términos que no son fácilmente entendibles; además, fueron s pensando en grandes empresas, lo que dificulta su adopción a las Tomando en cuenta lo anterior, se ha decidido llevar a cabo una propuesta de una herramienta enfocada en las tres áreas antes mencionadas (Administraci de Proyectos, Equipos de Trabajo de Alto Desempeño y Desarrollo de Software de Calidad), que permita conjuntar los beneficios de cada área; logrando así, cumplir con los objetivos de las organizaciones de manera exitosa.. 1.2. Objetivo El objetivo de estudio de esta investigación consiste en: “Proponer una herramienta que contenga los elementos críticos de éxito para llevar a cabo la efectiva Administración de Proyectos en Equipos Autodirigidos que ..

(15) 1.3. Metodología Para llevar a cabo el objetivo de la investigación, primeramente se analiza un caso de estudio del Departamento de Proyectos Especiales de la Vicerrectoría de Tecnologías de Información (VITI), del Tecnológico de Monterrey. Este caso pretende dar a conocer algunas de las características encontradas en la Administración de Proyectos en Equipos Autodirigidos que desarrollan Software de Calidad. Posteriormente, con base en los resultados de la tesis de Flores (2002), se obtienen variables adicionales que complementaron la investigación. Además, mediante entrevistas se determinan algunas características relevantes para el análisis de las herramientas que existen en el mercado. Finalmente, las variables obtenidas del caso de estudio, de la literatura consultada y de las entrevistas, ayudan a realizar un análisis de las herramientas que se encuentran actualmente en el mercado. El análisis de las herramientas aunado con las investigaciones realizadas, son la base para la propuesta de una nueva herramienta que cumpla con el objetivo establecido.. 1.4. Producto Final El producto final de esta investigación, consiste en la propuesta de una herramienta que contiene los elementos críticos de éxito para llevar a cabo la efectiv a Administración de Proyectos en Equipos Autodirigidos que desarrollan Software de Calidad. Para llevar a cabo lo anterior, se tomaron en cuenta la literatura investigada, el caso de estudio de la VITI y los resultados obtenidos en las evaluaciones de las herramientas que actualmente se utilizan en el mercado para la Administración de Proyectos de Software. Para llevar a cabo la propuesta, en el área de Administración de Proyectos se Project Management Institute (PMI), debido a que ésta se considera como el estándar predominante en la Administración de Proyectos. Por otro lado, con respecto al área de Desarrollo de Software de Calidad se contempla la metodología de Programación Extrema, debido a que se basa en una serie de reglas y principios que se han ido gestionando a lo largo de la historia de la Ingeniería de Software según Harrison (2000). Esta metodología ha sido muy popular en la actualidad, debido a que ayuda en gran medida al Desarrollo de Software de Calidad. Finalmente, para el área de Equipos de Trabajo de Alto Desempeño no existe una metodología como base, debido a que es una rama que está en proceso de.

(16) desarrollo y aún no existe alguna guía o metodología predominante; sin embargo, la propuesta se basa en literatura encontrada, así como en el caso de estudio analizado.. 1.5. Contribución La contribución esperada con esta investigación; por un lado, pretende dar las bases para crear un prototipo o incluso una nueva herramienta de Software para la Administración de Proyectos en Equipos Autodirigidos que desarrollan Software de Calidad. Además, este estudio puede servir como base para una nueva investigación sobre la funcionalidad que puede tener esta herramienta en las el país o incluso en el ámbito mundial. Por otro lado, busca que organizaciones que están utilizando el enfoque de Administración de Proyectos en Equipos Autodirigidos que desarrollan de Software de Calidad, utilicen o tomen en cuenta los puntos críticos referentes a este enfoque, encontrados en la herramienta propuesta en esta investigación. Finalmente, en esta investigación se encuentra una evaluación de herramientas que puede servir a las organizaciones para determinar cuál de dichas herramientas se puede utilizar en la empresa, de acuerdo a sus recursos y/o necesidades.. 1.6. Trabajos Futuros El tema que ha sido sujeto de esta investigación, sugiere la continuación en las. q. q. q. Creación de un prototipo de Software de la herramienta propuesta, el cual contemple cada uno de los elementos mencionados en la investigación. Realización de una investigación y análisis de la utilidad que puede tener la herramienta propuesta, ya sea en escala regional, nacional o inclusive en el ámbito global. Incursión de Bases de Datos de proyectos históricos (repositorios centralizados) en una herramienta para la Administración de Proyectos en Equipos Autodirigidos que desarrollan de Software de Calidad..

(17)

(18) Capítulo 2 2. Desarrollo de Software de Calidad En los últimos años la industria mundial de Desarrollo de Software se ha preocupado por mejorar sus capacidades en el Desarrollo de Software de Calidad. Las empresas están invirtiendo en la mejora de los procesos de desarrollo para poder distinguirse en el mercado. El área encargada del aseguramiento y de la Calidad en el Software es conocida como Ingeniería de Software. Se han definido varios modelos basados en las experiencias exitosas de la Ingeniería de Software que sirven mejoras y unifican los criterios de evaluación de las empresas, tal como el modelo estadounidense conocido como Capability Maturity Model (CMM), considerado uno de los más reconocidos en el ámbito mundial. El adoptar estándares de Calidad en el Software, es una situación que ha despertado la inquietud y el interés de muchas empresas a nivel mundial por mejorar sus propios procesos de desarrollo y no quedarse fuera del mercado. Para las empresas medianas y pequeñas los problemas principales que impiden adoptar un estándar de Calidad en el Software son: la selección del modelo a seguir, su comprensión e interpretación y el costo de la implantación en la empresa. Otra razón es que los modelos de referencia mencionados son complejos, voluminosos y están definidos en términos que no son fácilmente entendibles. Además, fueron diseñados pensando en grandes empresas, lo que dificulta su adopción a las. 2.1. Definición de Software y Desarrollo de Software Para empezar a conocer un poco más respecto al tema a tratar, es básico conocer el significado de lo que es el Software y Desarrollo de Software. Software es la suma total de los programas de computadora, procedimientos, reglas, la documentación asociada y los datos que pertenecen a un sistema de cómputo. [Lewis, 1994] Desarrollo de Software es aquel proceso en que las necesidades del usuario son traducidas en requerimientos de Software, estos requerimientos transformados en diseño y el diseño implementado en código, el código es probado, documentado y certificado para su uso operativo. Concretamente, define quién está haciendo qué, cuándo hacerlo y cómo alcanzar un cierto objetivo. [Jacobson, 1998] Las definiciones presentadas anteriormente, son fundamentales para las secciones siguientes. Ya conociendo las definiciones de Software y Desarrollo de.

(19) Software, se requiere identificar algunas de las características principales, estás se revisarán en la siguiente sección.. 2.2. Características del Desarrollo de Software Una vez que se conoce el significado de lo que es el Desarrollo de Software, es conveniente determinar las características del mismo. Las características del Desarrollo de Software son: q. q. q. q. q. Incertidumbre: Se convierte en la característica fundamental de este tipo de servicio, se debe en buena parte a que los requerimientos iniciales del usuario son incompletos y se van clarificando a medida que avanza el proyecto. Este alto nivel de incertidumbre hace que los procesos de estimación del esfuerzo, costo y tiempo sean también inciertos y complejos. El proceso de Desarrollo de Software es de por sí incierto. Puesto que se trata de un trabajo eminentemente creativo e intelectual, la productividad individual y los alcances de un proyecto están rodeados de incertidumbre. Un estimativo incorrecto conduce a sobrecostos que hace al potencial contratista no competitivo o a una estimación baja que lleva a los desarrolladores a la crisis financiera. Magnitud: Estos proyectos por lo general involucran inversiones cuantiosas y un buen número de proyectos de Desarrollo de Software son de gran tamaño. Algunos proyectos de desarrollo pueden tomar tiempos que van de los cinco a diez años de construcción. Decisiones Complejas: Estos proyectos involucran decisiones gerenciales y tecnológicas dirigidas a "blancos en movimiento", pues las empresas contratantes están en cambio continuo; además se toman decisiones con relación a tecnología que cambia de una forma muy acelerada. Interdependencia e integración con la Organización: Un producto de Software se debe integrar a la vida laboral de las personas; debe ser construido pensando en el cumplimiento del trabajo, enfocado en una organización específica, de modo que se tengan en cuenta las regl procedimientos, misión y visión de la organización para la cual se construye. Requerimiento de mecanismos complejos de comunicación formal e informal: Aunque la comunicación formal (documentación de todo lo que se realice dentro del proceso de construcción de Software) es quizás uno de los mayores factores de éxito de los proyectos, la comunicación informal también juega un papel importante en el éxito del proceso, siendo el correo electrónico uno de los instrumentos fundamentales en este tipo de comunicación. La comunicación y el compromiso entre el cliente y proveedor ayudan a bajar el grado de incertidumbre de este tipo de proyectos, haciendo que el producto.

(20) final se acomode a los requerimientos del usuario cumpliendo los plazos y costos estipulados. [Cuevas, 1996] El conocer las características del Desarrollo de Software es importante, ya que permite anticiparte, prepararte o atacar problemas que regularmente ocurren al desarrollar Software de acuerdo a expertos.. 2.3. Evolución del Software El Software no ha sido el mismo desde sus inicios, ha presentado cambios trascendentes a lo largo de la historia. A continuación se presenta las características más importantes encontradas en la historia de la evolución del Software. Hace 3000 años, en la cultura China se utilizaba un instrumento denominado ábaco como herramienta indispensable para efectuar transacciones comerciales, de manera rápida y eficaz. Se esperó hasta el siglo XVII para que en francés Blaise Pascal, inventara un aparato al cual denominó máquina calculadora. A mediados del siglo XIX, con el descubrimiento de la electricidad, las máquinas mecánicas decayeron; las máquinas se simplificaron, Herman Hollerit, fue uno de los primeros en utilizar los principios básicos de la electricidad, su máquina fue importante en el proceso electoral de 1890, en EE.UU. Posteriormente, aparecieron un gran número de máquinas similares, fue en el siglo XX que John Von Neumann, propuso el uso de un programa interno, para que la máquina pueda realizar de manera automática su trabajo, su idea tuvo sólo fundamento teórico, pero en 1944 un grupo de científicos en los Estados Unidos elaboró lo que sería el primer tipo de ordenador, el E.N.I.A.C. (Electronic Numerical Integrator and Calculator), vinculado a la trayectoria de proyectiles. A mitad de la década de los 50 la tecnología electrónica avanzaba de manera vertiginosa, a partir de esto se pueden distinguir cinco generaciones debidamente diferenciales. q. q. Primera Generación. Se caracterizó por reunir todas aquellos ingenios que incluían válvulas como elemento electrónico fundamental en su diseño. Segunda Generación. Se caracterizó por el uso del transistor como elemento principal de su diseño, de tamaño.

(21) q. q. q. Tercera Generación. Se perfeccionan los componentes electrónicos, de menor tamaño, se fabrica el primer circuito integrado, se esgrimió el concepto de multiprogramación (correr varios programas a la vez independientemente). Cuarta Generación. Surge el primer microprocesador o CHIP, o surge la microelectrónica. Ésta es la generación de actualidad con relación al hardware. Quinta Generación. Es el avance de la inteligencia artificial, robótica, cionado al uso del Software). [Assen, 1997]. La evolución del Software se ha dado debido a la necesidad de crear nuevos instrumentos de Software que cumplan con los requerimientos de los usuarios de la mejor manera. Después de haber conocido un poco sobre la evolución del Software, es conveniente identificar las etapas que se tienen en un Desarrollo de Software.. 2.4. Ciclo de Vida del Desarrollo de Software El Desarrollo de Software cuenta con varias etapas o fases, a estas etapas en conjunto se le conoce como Ciclo de Vida del Desarrollo de Software. A continuación se presenta el ciclo de vida más común en el Desarrollo de Software. Kendall & Kendall (1995) consideran que el Ciclo de Vida de Desarrollo de Sistemas es un enfoque por fases del análisis y diseño que sostiene que los sistemas son desarrollados de mejor manera mediante el uso de un ciclo específico de actividades del usuario y del analista. Los analistas no están de acuerdo con qué tantas fases exactas hay en el Ciclo de Vida de Desarrollo de Sistemas, pero por lo general apoyan su enfoque organizado. Las fases del Ciclo de Vida de Desarrollo de Sistemas según Kendall & Kendall (1995) se representan en la Figura 2.1. 1.Identificación de problemas, oportunidades y objetivos. 2. Deterninación de los requerimientos de información. 3. Análisis de las necesidades del sistema. 7. Implementación y evaluación del sistema. 6. Prueba y mantenimiento del sistema. 4. Diseño del sistema recomendado 5. Desarrollo y documentación del software. Figura 2.1 Ciclo de Vida del Desarrollo de Sistemas [Kendall & Kendall, 1995].

(22) Las fases son las siguientes: 1. 2. 3. 4. 5. 6. 7.. Identificación de problemas, oportunidades y objetivos. Determinación de los requerimientos de información. Análisis de las necesidades del sistema. Diseño del sistema recomendado. Desarrollo y documentación del Software. Prueba y mantenimiento del sistema. Implementación y evaluación del sistema.. La importancia de conocer el ciclo del Desarrollo de Software básicamente es para tener una idea general de las actividades involucradas al crear un producto de Software. El crear productos de Software no es tan complicado como el crearlos de acuerdo con todas las especificaciones del cliente, para esto último se requiere contar con estándares de calidad. Por tal motivo se requiere conocer un poco más sobre el concepto de calidad.. 2.5. Definición de Calidad Otro concepto trascendente respecto al tema de Desarrollo de Software, es la calidad, a continuación se presenta su significado. Bounds et al. (1994), menciona que de acuerdo a una encuesta realizada a ejecutivos expertos, administradores, trabajadores y académicos, Calidad se puede definir de las siguientes maneras: q. q q. q q. q. Paradigma sistemático de mejora continua, el camino para organizar exitosamente máquinas y personas. Significado de excelencia. El continuo esfuerzo de las organizaciones por entender, reunir, y exceder las necesidades de sus clientes. El mejor producto que puedas producir con los materiales disponibles. Producir un producto o servicio que reúna las necesidades o expectativas de los clientes. Crear los productos con cero defectos.. Con base en las definiciones anteriores se puede notar que la calidad es crear productos que sobrepasen las características requeridas por los consumidores. La.

(23) calidad no sólo ha sido adoptada en productos tangibles, sino que también se ha incorporado a intangibles, como lo es el caso del Desarrollo de Software. En las secciones siguientes se tratará el tema de calidad enfocado al Desarrollo de Software.. 2.6. Ingeniería de Software y Software de Calidad La Ingeniería de Software se ha preocupado por encontrar las directrices más importantes referentes al Desarrollo de Software de Calidad, a continuación se presenta el significado de Ingeniería de Software de acuerdo a varios autores. Chung (2002) menciona que basado en una definición oficial encontrada en el Estándar 610.12 del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE por sus siglas en Inglés), Ingeniería de Software se refiere a: q. q. La aplicación de una metodología sistemática, disciplinada y cuantificable al desarrollo, operación y mantenimiento del Software; que es, la aplicación de El estudio de dichas metodologías (como en el punto anterior).. Ingeniería de Software es el establecimiento y uso de principios de ingeniería robustos, orientados a obtener Software económico que sea fiable y funcione de manera eficiente sobre máquinas reales. [Pressman, 1995] Ingeniería de Software es un conjunto de etapas parcialmente ordenadas con la intención de lograr un objetivo; en este caso, la obtención de un producto de Software de Calidad. [Jacobson, 1998] La Ingeniería de Software es la rama de la ingeniería que aplica los principios de la ciencia de la computación y las matemáticas para lograr soluciones costoefectivas (eficaces en costo o económicas) a los problemas de Desarrollo de Software; es decir, permite elaborar consistentemente productos correctos, utilizables y costo-efectivos. [Cota, 1994] La definición de Software de Calidad de acuerdo a Wesenberg (1991) es: Se puede decir que el Software tiene calidad si cumple o excede las expectativas del usuario en cuanto a funcionalidad (que sirva un propósito), ejecución (que sea que haga lo que debe), disponibilidad (que funcione bajo cualquier circunstancia) y apoyo, a un costo menor o igual al que el usuario está dispuesto a pagar. Medir el Software es un desafío; sin embargo, es componente esencial de la salud y capacidad de la cultura de Ingeniería de Software. [Wiegers, 1999].

(24) Las organizaciones que cuentan con tecnología de información están trabajando por mejorar sus procesos de Desarrollo de Software. Los temas claves para mejorar los procesos de Desarrollo de Software son definir requerimientos y entender el proyecto completo como tal, identificando e incluyendo a los involucrados y realizando revisiones después del proyecto para aprender de cada experiencia. [Cosgrove, 2001] Desarrollar y mantener un proyecto de Software puede ser complicado y consumir tiempo, especialmente cuando el proyecto de Software es complicado y requiere el esfuerzo de más de un individuo. Pensando en términos de un Ingeniero de Software común, la mayoría de los proyectos de Software empiezan cuando un consumidor va y comunica al Ingeniero de Software que quiere ayuda en el desarrollo de un proyecto de Software y que requiere que se haga dicho Software. Esos son los requerimientos del Software. Desde ese momento hasta que se termina el proyecto de Software, existen varias actividades involucradas. La Ingeniería de Software estudia dichas actividades; es decir, estudia el Ciclo de Vida del Desarrollo de Software. [Chung, 2002] De acuerdo a las definiciones presentadas por varios autores, se puede crear una nueva definición que contemple las características trascendentes de este concepto. La nueva definición sería, la Ingeniería de Software es un área de la ciencia encargada de estudiar y aplicar una metodología sistemática, disciplinada y cuantificable al desarrollo, operación y mantenimiento del Software para obtener un producto de Software que sea fiable y funcione de la manera más eficiente. Como se puede ver esta rama de la ciencia busca obtener un Software de Calidad; sin embargo, ¿qué es un Software de Calidad?. La definición de Software de Calidad que se presentó anteriormente, se basa en cumplir con las características como funcionalidad, confiabilidad, disponibilidad, etcétera. Existen características adicionales del Software de Calidad, éstas se presentan en la. 2.7. Características del Software de Calidad Como se ha observado a lo largo del capítulo, el tener Software de Calidad en las industrias, es de suma importancia, ya que permite tener productos tal y cual los requeridos por el cliente. Ahora bien, el lograr Software de Calidad no es tarea fácil, requiere de una buena inversión en tiempo, dinero y recursos. A continuación se presentan las características que el Software de Calidad debe tener. De acuerdo con Robert Grady (citado por Díaz, 2001), la manera como se definen cada uno de los factores de calidad, es a través de un conjunto de subfactores, lo cual explica más detalladamente lo que el autor desea expresar tos son:.

(25) q. q. q. q. q. Funcionalidad. Se refiere al conjunto de características operativas, capacidades funcionales, generalidad y seguridad del producto de Software. Usabilidad. Se refiere a los factores humanos involucrados, estética, l producto de Software. Confiabilidad. Se refiere a la frecuencia y gravedad de las fallas, recuperación y predicción de errores, exactitud y oportunidad de la falla. Capacidad de ejecución. Se refiere a la velocidad de ejecución eficiencia, consumo de recursos, razón de entradas por salidas y tiempo de respuesta. Facilidad de apoyo. Se refiere a la facilidad de prueba, facilidad de adaptación, facilidad de expansión, facilidad de mantener, compatibilidad, facilidad para configurar, facilidad de instalación y capacidad de servicio.. Por otra parte, Arthur Jay (citado por Díaz, 2001) menciona los siguientes factores de calidad para la evaluación de sistemas de información: q. q. q q. Facilidad de mantenimiento. ¿Puede arreglarse el código?, ¿Requiere poco esfuerzo arreglarlo o modificar el defecto?, ¿Está bien documentado con prólogo y puntos de decisión?, ¿Son los módulos simples? Flexibilidad. ¿Se le pueden añadir al programa nuevos módulos sin problemas?, ¿Contiene código con demasiados bucles?, ¿Hay copia de bibliotecas para definiciones de datos? Confiabilidad. ¿Correrá y producirá resultados correctos todo el tiempo? Facilidad de uso. ¿Puede el usuario / cliente aprender y usar el sistema fácilmente?, ¿Pueden las operaciones ejecutarse?. q. Eficiencia. ¿Corre en el hardware tan rápido como es posible?. q. Habilidad para probarse. ¿Pueden probarse todas las opciones del sistema de. q. Portabilidad. ¿Puede moverse fácilmente de un hardware y/o ambiente de. q. Interoperabilidad. ¿Puede interactuar fácilmente con otros sistemas?. q. Integridad. ¿Son la aplicación y sus datos completos, exactos y consistentes?, ¿Es controlado el acceso a la información?.

(26) Como se puede ver de acuerdo a lo presentado por los autores, ambos coinciden en varias de las características que debe contener el Software de Calidad, entre éstas se encuentran: facilidad de uso, confiabilidad y funcionalidad. Una vez conocidas algunas de las características del Software de Calidad, es necesario conocer alguno de los estándares más comunes en la industria del Software. Estos estándares pretenden incorporar mediante metodologías, las características mencionadas anteriormente.. 2.8. Estándares para la Calidad en el Software En la industria de Softw are moderna, los estándares juegan un papel muy importante para lograr la calidad en los productos de Software, por tal motivo, es necesario determinar la importancia y características de algunos de estos estándares. Básicamente en este apartado nos enfoca que es uno de los más reconocidos mundialmente. Wan (2002) dice que de acuerdo a un estudio realizado por el Centro de Información de la Industria del Software (SIIC por sus siglas en inglés) en el 2001 7% de las compañías de Software entrevistadas tenían implementado un programa de Calidad de Software. Este estudio mostró que el ISO 9000 es el estándar de calidad más común con 11.3%. En muchos mercados de Software, los procesos flexibles y el tiempo para sacar al mercado los productos son considerados con frecuencia más importantes que la calidad. Hayes (2002) menciona que de la investigación realizada por InformationWeek a 800 administradores de negocios de tecnología, 97% reportaron problemas con errores en el Software y fallas en años anteriores; además, nueve de cada 10 reportó altos costos, pérdida de ingresos o ambos como resultado. Por tal motivo, algunas compañías como USAA Group están usando el CMM para mejorar los los procesos de Desarrollo de Software. Hayes (2002) comenta que el CMM es un estándar de cinco pasos para la calidad en procesos de desarrollo y fue creado por el Instituto de Ingeniería de Software. Jalote (2000) muestra los cinco niveles del CMM, éstos son: 1. Inicial (nivel 1). Una organización ejecuta un proyecto en una manera en la que el equipo y el Administrador de Proyectos dan por hecho. 2. Repetible (nivel 2). Aplica a una organización en la cual las prácticas de ctos están bien establecidas, a pesar de que los procesos en toda la organización no existan..

(27) 3. Definido (nivel 3). Los procesos de Software de la organización han sido definidos precisamente y se les da seguimiento regularmente. 4. Administrado (nivel 4). El entendimiento cuantitativo de la capacidad de los procesos hace posible predecir cuantitativamente y controlar el desempeño de los procesos en un proyecto. 5. Optimizado (nivel 5). Los procesos mejoran continuamente. Wan (2002) comenta que de acuerdo al Instituto de Ingeniería de Software, 25 de las 42 organizaciones en el mundo que han alcanzado CMM nivel 5 están asentadas en la India. Rassa (2002) menciona que en las últimas décadas el CMM ha sido implementado exitosamente por compañías y organizaciones gubernamentales alrededor del mundo y se han tenido mejoras extraordinarias en costos de Software, calendarización y los errores entregados habían sido solucionados y documentados. Como se puede notar, los estándares han jugado un papel importante en el éxito de las industrias de Software al lograr Software de Calidad. También se observa que uno de los estándares de Calidad de Software más conocidos mundialmente (CMM), sólo se encuentra adoptado por pocas compañías y son mpañías que lo adoptan en su máximo nivel. Actualmente se están desarrollando metodologías que permiten lograr un Desarrollo de Software de Calidad, entre las que se están haciendo más populares se encuentra la conocida como programación extrema (XP). En la siguiente sección se presentan las características principales de dicha metodología.. 2.9. La Programación Extrema (eXtreme Programming) La programación extrema (XP) se basa en una serie de reglas y principios que se han ido gestando a lo largo de toda la historia de la Ingeniería del Software. Usadas conjuntamente proporcionan una nueva metodología para el Desarrollo de Software. [Harrison, 2000] La característica principal de la programación extrema es que la mayoría de sus componentes son conocidos dentro de la rama de la Ingeniería del Software desde hace tiempo, incluso desde sus comienzos. Por lo tanto, cabe mencionar que la programación extrema no se basa en principios nuevos, más bien, es una nueva forma de ver el Desarrollo de Software..

(28) a) El proceso de desarrollo extremo La programación extrema parte del caso habitual de una compañía que desarrolla Software, generalmente Software a medida, en la que hay diferentes roles: un equipo de administración, un equipo de desarrolladores y los clientes. La relación con el cliente es totalmente diferente a lo que se lleva a cabo en las metodologías tradicionales que se basan fundamentalmente en una fase de captura de requisitos previa al desarrollo y una fase de validación posterior al mismo.. o. Interacción con el cliente En la programación extrema el cliente no sólo apoya al equipo de desarrollo, en realidad es parte de él. El cliente se encuentra mucho más cercano al proceso de desarrollo, se elimina la fase inicial de captura de requisitos y se permite que los clientes participen de forma ordenada durante el tiempo que dura el proyecto. El cliente puede cambiar de opinión sobre la marcha y a cambio debe encontrarse siempre disponible para resolver dudas del equipo de desarrollo y para detallar los requisitos especificados cuando sea necesario. El proceso de captura de requisitos de la programación extrema gira entorno a una lista de características que el cliente desea que existan en el sistema final. Cada una de estas características recibe el nombre de historias de usuarios y su definición consta de dos fases: §. §. En la primera fase el cliente describe con sus propias palabras las características del producto, luego el responsable del equipo de desarrollo le informa de la dificultad técnica de cada una de ellas, así como su costo. A través del diálogo resultante el cliente deja por escrito un conjunto de historias y las ordena en función de la prioridad que tienen para él. En este momento ya es posible definir cuáles son los entregables y sus fechas aproximadas. La segunda fase consiste en escoger las primeras historias que serán implementadas (primera iteración) y dividirlas en las tareas necesarias para llevarlas a cabo. En esta fase el cliente también participa, pero hay más peso del equipo de desarrollo; esto da como resultado una planificación más exacta. En cada iteración se repetirá esta segunda fase para las demás historias planificadas.. Este proceso es una de las principales diferencias con las metodologías tradicionales. En lo que al cliente se refiere no se le exige que especifique exactamente lo que quiere al principio con un documento de requisitos de usuario. La parte que se mantiene con este documento es que es el cliente el que tiene que escribir lo que quiere, no se permite que alguien del equipo de desarrolladores lo escriba por él..

(29) Los desarrolladores los que se encargan de catalogar las historias de los usuarios y asignarles una duración. Para ello se sigue una norma simple: las historias de usuarios deben poder ser abordables en un espacio de tiempo de entre una y tres semanas de programación ideal. Historias de los usuarios que requieran menos tiempo de implementación son agrupadas, mientras que aquéllas que necesiten más tiempo deben ser modificadas o divididas. Una semana de programación ideal es una semana (cinco días de trabajo) de desarrollo por parte de un desarrollador sin interferencias de otras partes del proyecto. Al hacer la planificación se aplica un factor de corrección medido de proyectos anteriores, para ajustar este tiempo ideal al real. Las historias de los usuarios se plasman en tarjetas, lo que facilita que el cliente pueda especificar la importancia relativa entre las diferentes historias de usuario, para que los desarrolladores las cataloguen convenientemente.. o. Planificación del proyecto En este punto se lleva a cabo la planificación de entregas; es decir, donde se planifican las distintas iteraciones. La planificación debe seguir ciertas premisas. La primordial es que las entregas se realicen cuanto antes y que con cada iteración el cliente reciba una nueva versión. Se aconsejan muchas entregas y muy frecuentes. De esta forma, un error en una parte esencial del sistema se puede detectar y corregir rápidamente. Los requisitos anteriores en cuanto a la planificación no deben suponer horas extra para el equipo de desarrollo. El argumento que se esboza es que lo que se trabaja de más un día, se deja de trabajar al siguiente. Es común cometer equivocaciones en la planeación; sin embargo, la metodología ya tiene previsto mecanismos de revisión. Por tanto, es normal que cada 3 a 5 iteraciones se tengan que revisar las historias de los usuarios y renegociar nuevamente la planificación. En cada iteración también hay que realizar la planificación de la misma, a esto se le llama planificación iterativa. En la planificación iterativa se especifican las historias de los usuarios cuya implementación se considera primordial y se añaden aquéllas que no han pasado las pruebas de aceptación de anteriores iteraciones. La planificación de una iteración también hace uso de tarjetas en las que se escribirán tareas, que durarán entre uno y tres días. El diseño que se sigue con esta metodología se puede calificar de continuo. Este diseño añade agilidad al proceso de desarrollo y evita.

(30) implementar tareas que no estén programadas (algo que se conoce como programación justo a tiempo). También es cierto que no hay nada que pueda evitar que los retrasos se acumulen; sin embargo, añadir gente a un proyecto retrasado, sólo lo retrasa más. A raíz de lo anterior, se sigue el consejo de optimizar al final. El eslogan subyacente es "hacer que funcione, hacerlo bien y luego hacerlo que sea rápido”, ya que La planificación en iteraciones y el diseño iterativo dan pie a una práctica poco común en el desarrollo tradicional que son las discusiones diarias de pie. De esta forma, se fomenta la comunicación, ya que los desarrolladores cuentan con tiempo para hablar de los problemas a los que se enfrentan.. o. Diseño, desarrollo y pruebas El desarrollo es la pieza clave de todo el proceso de programación extrema. Todas las tareas tienen como objetivo que se desarrollen a la máxima velocidad, sin interrupciones y siempre en la dirección correcta. También se otorga una gran importancia al diseño y establece que éste debe ser revisado y mejorado de forma continua según se van añadiendo funcionalidades al sistema. La clave del proceso de desarrollo de programación extrema es la comunicación. La gran mayoría de los problemas en los proyectos de desarrollo son provocados por falta de comunicación en el equipo. Por lo tanto, se pone un gran énfasis en facilitar que la información fluya lo más eficientemente posible. En este punto entra uno de los términos principales de la programación extrema: la metáfora. El principal objetivo de la metáfora es mejorar la comunicación entre todos los integrantes del equipo al n global y común del sistema que se pretende desarrollar. La metáfora debe estar expresada en términos conocidos para los integrantes del grupo. Aunque también se incluye información sobre las principales clases y patrones que se usarán en el sistema. El diseño es realizado por los propios desarrolladores, aunque en ocasiones se reúnen aquellos con más experiencia o incluso se involucra al cliente para diseñar las partes más complejas. En estas reuniones se emplean un tipo de tarjetas denominadas CRC (Clases, Responsabilidades y Colaboración) cuyo objetivo es facilitar la comunicación y documentar los resultados. Una vez que se ha planificado y dividido las tareas, se llevan a cabo las pruebas unitarias a la par con la codificación. Los creadores de la.

(31) programación extrema argumentan que encontrar un error puede llegar a ser cien veces más caro que realizar las pruebas unitarias. El usar pruebas unitarias ayuda a priorizar y comprobar la evolución del desarrollo, además de ofrecer realim ciclo de desarrollo se basa en implementar una prueba unitaria, codificar la solución y pasar la prueba, con lo que se consigue un código simple y funcional de manera bastante rápida. Por eso es importante que las pruebas se pasen siempre al 100%. [Jeffries-A, 2001]. Las pruebas unitarias no deben confundirse con las pruebas de aceptación, estas últimas son pruebas realizadas por el cliente o por el usuario final para constatar que el sistema hace realmente lo que él quiere. La programación extrema persigue a lo que se conoce como integración continua. De esta manera, integrando continuamente pequeños fragmentos de código, se evita la gran integración final. Las ventajas de este enfoque son por una parte, que permite la realización de pruebas completas y por otro lado, la pronta detección de problemas de incompatibilidad. Además, ya no será necesario un equipo independiente de integración. En todo desarrollo de programación extrema debe existir siempre una tegrada. La sincronización por parte de los desarrolladores con el repositorio central debe darse como mínimo una vez al día, de manera que los cambios siempre se realicen sobre la última versión. De esta manera, se asegura que las modificaciones que se lleven a cabo, no se realicen sobre versiones obsoletas. La programación extrema recalca la importancia de refactorizar. Refactorizar consiste básicamente en quitar redundancia, eliminar funcionalidad que no se usa o "rejuvenecer" diseños viejos. Tiene su justificación principal en que el código no sólo tiene porque funcionar, también debe ser simple. Esto hace que a la larga refactorizar ahorre mucho tiempo y suponga un incremento de calidad. Con la refactorización se evita que cuando un desarrollador deja un proyecto, esto se convierta en un hecho catastrófico. El mejor método para conseguir que el código sea de todos es seguir unos estándares de codificación consistentes, de manera que la lectura (y refactorización) por parte del resto del equipo de desarrollo se facilite al máximo. El proceso de desarrollo no lo va a hacer un desarrollador en solitario, sino siempre con otra persona, algo que se le conoce como programación por parejas. Una pareja de desarrolladores debe compartir la misma computadora. Las parejas deben ir rotando de forma periódica para hacer que el conocimiento del sistema se vaya.

(32) difundiendo por el equipo, a la vez que se fomentan el entrenamiento cruzado. [Jeffries-B, 2001] Los gurús de la programación extrema no dudan en afirmar que dos personas trabajando conjuntamente en pareja generan en cantidad el mismo código (o mejor dicho, la misma funcionalidad) que dos personas por separado, pero con mayor calidad. b) Valores de la programación extrema El proceso de desarrollo descrito en la sección anterior está fundamentado en una serie de valores y principios que lo guían. Los valores representan aquellos aspectos que los autores de la programación extrema han considerado como fundamentales para garantizar el éxito de un proyecto de Desarrollo de Software.. o o o o. Los cuatro valores de la programación extrema son: Comunicación. Simplicidad. Realimentación. Coraje.. Los partidarios de la programación extrema dicen que son los necesarios y códigos simples, métodos eficientes de Desarrollo de Software y clientes contentos. Los valores deben ser intrínsecos al equipo de desarrollo. Detrás del valor del coraje encontramos el lema "si funciona, mejóralo", que varía con la práctica habitual de no tocar algo que funciona. c) Principios de la programación extrema Los principios fundamentales de la programación extrema son realimentación veloz, modificaciones incrementales, trabajo de calidad y asunción de simplicidad. Los principios suponen un puente entre los valores y las prácticas. d) Prácticas de la programación extrema Las prácticas de la programación extrema son las siguientes: 1. 2. 3. 4. 5. 6. 7. 8.. El juego de la planificación Pequeñas entregas Metáfora Diseño simple Pruebas Refactorización Programación por parejas Propiedad colectiva.

(33) 9. Integración continua 10. 40 horas semanales 11. Cliente en casa 12. Estándares de codificación El objetivo final debe ser aplicar todas las prácticas, ya que representan un conjunto completo, el no aplicar todas las prácticas significa no hacer programación extrema. No es fácil aplicar una nueva metodología en un equipo de desarrollo ya que obliga a aprender una nueva forma de trabajar. La programación extrema ha sido adoptada por un gran número de equipos en los últimos años y de sus experiencias se ha extraído una conclusión sencilla: es mejor empezar a hacer programación extrema gradualmente. [Robles & Ferrer, 2002] Esta metodología ha surgido desde la experiencia, como una forma de resolver los problemas encontrados en los procesos de Desarrollo de Software en los que se han visto involucrados sus autores. Hay numerosas opiniones que relatan el éxito de. 2.10. Conclusiones Muchas empresas dedicadas al Desarrollo de Software están haciendo esfuerzos por implantar modelos de Calidad en el Software, buscando con ello obtener ventajas competitivas. En los últimos años, grandes corporaciones internacionales como Motorola, IBM y Volkswagen han introducido estas ideas en México al implementarlas en sus filiales. La evolución que ha tenido el Desarrollo de Software se debe principalmente a la necesidad de crear herramientas de software que cumplan con los requerimientos de los usuarios de la mejor manera posible. Esta evolución es un proceso de mejora que ha permitido una manera más sencilla para crear Software. Por otro lado, los avances en investigaciones que ha tenido la Ingeniería de Software, han creado nuevos estándares y metodologías para lograr la calidad en el Desarrollo de Software. Es notorio que implementar estándares de calidad en las industrias no es cosa fácil, requiere invertir tiempo, dinero y recursos; sin embargo, los beneficios que se.

(34) pueden lograr mediante son innumerables, entre los que se destaca la satisfacción del cliente. La preocupación por la industria del Software es obvia, tanto que muchos organismos están desarrollando o incorporando métodos para el Desarrollo de Software de Calidad; tal es el caso de la reciente metodología conocida como programación extrema..

(35)