T E S I S QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS DE LA COMPUTACIÓN P R E S E N T A ING.ERÉNDIRA MIRIAM JIMÉNEZ HERNÁNDEZ

Instituto Politécnico Nacional Centro de Investigación en Computación Secretaría de Investigación y Posgrado META (MEtodología Tradicional y Ágil), UNA METODOLOGÍA HÍBRIDA PARA DESARROLLO DE SOFTWARE WEB PROPUESTA PARA LAS EMPRESAS DE SOFTWARE EN MÉXICO T E S I S QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS DE LA COMPUTACIÓN P R E S E N T A ING.ERÉNDIRA MIRIAM JIMÉNEZ HERNÁNDEZ DIRECTOR DE TESIS: M. en C. SANDRA DINORA ORANTES JIMÉNEZ MÉXICO, D.F. OCTUBRE 2012

Resumen El desarrollo de software es una actividad no trivial, razón por la cual se ha intentado dar solución a dicha problemática a través del uso de metodologías, las cuales proporcionan procesos sistematizados sobre el desarrollo de software con el fin de mejorar la productividad y la calidad. En la actualidad, existen un gran número de metodologías para el desarrollo de software; estas se engloban en tres categorías: las metodologías tradicionales, las metodologías ágiles y las metodologías híbridas. Las metodologías tradicionales propician las buenas prácticas que existen dentro de la Ingeniería de Software; sin embargo, requieren de mucha disciplina para seguir con el riguroso proceso que éstas conllevan. Las metodologías ágiles presentan respuestas rápidas al cambio y son flexibles, aunque generan poca documentación y no hacen uso de métodos formales. Las metodologías híbridas son la nueva tendencia en el área de Ingeniería de Software, su principal característica es que incorporan algunas prácticas de las metodologías tradicionales y ágiles existentes, brindado así una gran ventaja. Este trabajo propone una metodología híbrida para desarrollo de proyectos de software Web, la cual es conocida como MEtodología Tradicional y Ágil (META por sus siglas en español) que combina algunas prácticas de las metodologías RUP (Rational Unified Process, Proceso Unificado de Racional), XP (extreme Programming, Programación Extrema) y Scrum. META se diseñó a partir de un estudio (que se realizó como parte de esta investigación), en el cual se comprobó que las empresas mexicanas dedicadas a desarrollar software son candidatas a utilizar una metodología híbrida. Finalmente META se probó en proyectos de desarrollo de software reales y se evaluó su calidad con la norma NMX-I-055-NYCE; de esta manera se presenta a META como una opción factible para desarrollo de software en México. Eréndira Miriam Jiménez Hernández Octubre 2012 ii

Abstract The software development is a nontrivial activity, this is the reason why it have been used methodologies for trying to solve this problem because they provide a systematic process for software development in order to improve productivity and quality. Currently, there are a lot of methodologies for software development, these falls into three broad categories: traditional methodologies, agile methodologies and hybrid methodologies. The traditional methodologies foster the best practices that exist within Software Engineering; however, they require a lot of discipline to continue the rigorous process that they entail. The agile methodologies have quick responses to change and they are flexible, but they generate little documentation and they do not make use of formal methods. The hybrid methodologies are the new trend in the area of Software Engineering, its main feature is that they incorporate some practices of the existing methodologies, providing a great advantage. This thesis proposes a hybrid methodology for software development of Web projects called META (MEtodología Tradicional y Ágil, Traditional and Agile Methodology), it combines some practices within others methodologies as RUP (Rational Unified Process), XP (extreme programming) and Scrum. META was designed from a study (which was conducted as part of this research), in which it was found that Mexican companies dedicated to developing software are candidates to use a hybrid methodology. Finally META was tested in real projects of software development and it was assessed its quality with the standard NMX-I-055-NYCE; thereby it presents META as a feasible option for software development in Mexico. Eréndira Miriam Jiménez Hernández Octubre 2012 iii

Agradecimientos. Al Instituto Politécnico Nacional. Por brindarme la oportunidad de pertenecer a una de las mejores instituciones de la República Mexicana, ofreciéndome una formación académica de calidad al servicio de mi país. Al Centro de Investigación en Computación. Por proporcionar los recursos humanos y materiales necesarios para la adecuada adquisición de conocimiento. A CONACYT. Por otorgarme una beca que significó un apoyo económico durante el tiempo que cursé la Maestría. A mi Asesora. Por haberme ayudado incondicionalmente y compartir su conocimiento conmigo. Al Comité Tutorial. Por su valiosa aportación en comentarios y recomendaciones que permitieron mejorar mi formación académica y aumentar la calidad de mi proyecto de tesis. A mi Papá. Que siempre me ha guiado y me ha sabido ofrecer sabios consejos en los momentos en que más lo he necesitado, además de ser el ejemplo que siempre me motiva a buscar más en la vida y a obrar con rectitud y congruencia. A mi Mamá. Que ha estado siempre al pendiente de mí brindándome su cariño y comprensión. A mis Hermanos. Mis amiguitos, que han estado a mi lado siempre dándole alegría a mi vida. A mi Novio. Que me anima y me apoya para alcanzar mis sueños y hacerlos realidad Y en general, a aquellas personas que han compartido momentos especiales de su vida conmigo que quedarán por siempre en mi memoria y por los cuales estaré agradecida toda la vida. Eréndira Miriam Jiménez Hernández Octubre 2012 iv

Índice Resumen... ii Abstract... iii Agradecimientos...... iv Glosario... ix 1 Introducción... 11 1.1 Planteamiento del problema... 11 1.2 Objetivos... 12 1.2.1 Objetivo General... 12 1.2.2 Objetivos Específicos... 12 1.3 Justificación... 13 1.4 Beneficios Esperados... 18 1.5 Límites y Alcances... 18 1.6 Organización de la Tesis... 18 1.7 Resumen.... 18 2 Marco Teórico... 19 2.1 Introducción... 19 2.2 Estado del Arte.... 19 2.2.1 Metodologías Tradicionales... 19 2.2.1.1 RUP... 20 2.2.2 Metodologías Ágiles... 23 2.2.2.1 XP... 24 2.2.2.2 Scrum... 27 2.2.3 Metodologías Híbridas... 29 2.2.3.1 EssUP... 29 2.3 Norma Mexicana NMX-I-055-NYCE........ 30 2.3.1 Modelo de Calidad Interna y Externa... 31 2.3.2 Modelo de Calidad para la Calidad en Uso... 31 2.4 Resumen...... 32 3 META... 33 3.1 Introducción... 33 3.2 Características de META... 33 3.3 Requerimientos y Requisitos para el Uso de META.... 33 3.4 Capacitación para el uso de META... 34 3.5 Roles en META... 34 3.6 Principios Metodológicos de META... 36 3.7 Proceso de Desarrollo de META... 42 3.7.1 Planteamiento... 44 3.7.2 Preparación... 50 3.7.3 Construcción... 52 3.7.4 Implantación... 53 3.8 Componentes de META..... 53 Eréndira Miriam Jiménez Hernández Octubre 2012 v

3.9 Ventajas de META..... 55 3.10 Limitaciones de META...... 55 3.11 Resumen...... 55 4 Pruebas y Resultados obtenidos.... 56 4.1 Introducción... 56 4.2 Evaluación de META.... 56 4.3 Opinión respecto a META... 62 4.4 Resumen... 62 5 Conclusiones y Trabajos Futuros...... 63 Bibliografía..... 65 Referencias URL... 66 Apéndices.... 67 1 Características de las Aplicaciones Web... 67 2 Plantilla General del Contrato.... 68 3 Fólder del Proyecto.... 70 4 Calidad Interna del Producto.... 76 5 Calidad Externa del Producto.... 80 6 Calidad en Uso del Producto... 84 Anexos......... 85 1 Metodologías Híbridas para desarrollo de software: una opción factible para México (Revista Digital Universitaria) 2 META: a new hybrid methodology to software development created to suit the current needs in Mexico (ICTA 2011) 3 Metodología Híbrida para desarrollo de software en México (CICIC 2012) Eréndira Miriam Jiménez Hernández Octubre 2012 vi

Índice de Figuras Figura 1.1. Metodologías utilizadas en las empresas mexicanas... 12 Figura 1.2. Área bajo la curva de la distribución normal... 16 Figura 1.3. Intervalo de confianza...... 17 Figura 2.1. Etapas de RUP.... 22 Figura 2.2. Etapas de XP... 27 Figura 2.3. Proceso de Scrum... 29 Figura 2.4. Modelo para la calidad del producto....... 30 Figura 2.5. Modelo para la calidad interna y externa.... 31 Figura 2.6. Modelo para la calidad en uso..... 32 Figura 3.1. Roles en META.... 36 Figura 3.2. Ciclo de Deming.... 38 Figura 3.3. Proceso de desarrollo de META... 43 Figura 3.4. Ejemplo de Diagrama Interfaz-Navegación de la página de inicio del sitio... 45 Figura 3.5. Ejemplo de Diagrama Interfaz-Navegación de la página principal de los Clientes... 45 Figura 3.6. Ejemplo de Diagrama Interfaz-Navegación de la página principal de las Tiendas... 46 Figura 3.7. Estimación con META-Software.... 47 Figura 3.8. Generación de contrato con META-Software... 48 Figura 3.9. Plan de proyecto general para el mes de diciembre... 49 Figura 3.10. Plan de proyecto general para el mes de enero... 49 Eréndira Miriam Jiménez Hernández Octubre 2012 vii

Índice de Tablas META (MEtodología Tradicional y Ágil), una metodología híbrida para Tabla 2.1. Metodologías Ágiles vs. Metodologías Tradicionales..... 24 Tabla 3.1. Roles en META......... 34 Tabla 3.2. Tabla de Actividad-Responsabilidad........... 50 Tabla 3.3. Tabla de Gestión de Riesgos y Problemas...... 52 Tabla 3.4. Componentes de META...... 54 Tabla 4.1. Tabla de Normalización de las Métricas para la evaluación del Producto... 57 Tabla 4.2. Tabla Calidad Interna del Producto (Media aritmética y porcentaje)... 58 Tabla 4.3. Tabla Calidad Externa del Producto (Media aritmética y porcentaje)... 59 Tabla 4.4. Media Aritmética y Porcentaje de las Características de la Calidad Interna del Producto............ 60 Tabla 4.5. Media Aritmética y Porcentaje de las Características de la Calidad Externa del Producto............ 60 Tabla 4.6. Media Aritmética y Porcentaje de las Características de la Calidad en Uso del Producto............ 61 Tabla 4.7. Calidad del Producto......... 61 Eréndira Miriam Jiménez Hernández Octubre 2012 viii

Glosario Glosario de Términos Base de Datos Calidad Caso de Uso Evaluación de Calidad Híbrido Ingeniería de Software Metodología Métrica Puntos de Función Software Web Es una colección de datos interrelacionados almacenados conjuntamente en uno o más ficheros de computadora [IEE90]. Totalidad de las características de una entidad que nacen de su capacidad para satisfacer las necesidades explícitas e implícitas [NYC06]. Es una funcionalidad del sistema que proporciona al usuario un valor añadido [IBM11]. Examen sistemático del grado al cual una entidad es capaz de cumplir los requisitos especificados [NYC06]. Se dice de todo lo que es producto de elementos de distinta naturaleza [RAE01]. Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo operación (funcionamiento) y mantenimiento del software: es decir, la aplicación de Ingeniería al software [IEE93]. Conjunto de pasos y procedimientos que deben seguirse para desarrollar sistemas computacionales [SOM09]. Es una medida cuantitativa o cualitativa del grado en que un sistema, componente o proceso posee un atributo determinado [IEE93]. Es una métrica empleada para medir la funcionalidad que entrega un sistema a través del conocimiento del número de entradas externas, salidas externas, consultas externas, archivos lógicos internos y archivos de interfaz externos [ALB79]. Conjunto de programas, instrucciones y reglas informáticas para ejecutar ciertas tareas en una computadora [RAE01]. Protocolo basado en hipertexto, que permite conectar su contenido mediante hipervínculos, fue pensado como una fuente de material de sólo lectura, que se encontraba en una gran estructura de servidores cargados con miles de datos [BER96]. Eréndira Miriam Jiménez Hernández Octubre 2012 ix

Glosario de Acrónimos COCOMO CRC DSA INEGI META OMT PERT RUP UML UP XP COnstructive COst MOdel, Modelo Constructivo de Costos Class Responsibility-Collaboration, Clase Responsabilidad-Colaboración Development Software Adaptative, Desarrollo de Software Adaptativo Instituto Nacional de Estadística y Geografía MEtodología Tradicional y Ágil Object Modeling Technique, Técnica de Modelado de Objetos Program Evaluation and Review Technique, Técnica de Evaluación y Revisión de Programas Rational Unified Process, Proceso Unificado de Racional Unified Modeling Language, Lenguaje Unificado de Modelado Unified Process, Proceso Unificado extreme Programming, Programación Extrema Eréndira Miriam Jiménez Hernández Octubre 2012 x

1 Introducción El software se ha convertido en una tecnología indispensable en los negocios, la ciencia y la ingeniería; ha permitido la creación, la expansión y el fin de tecnologías. En la actualidad, el software está relacionado con sistemas de todo tipo: de transporte, médicos, de telecomunicaciones, militares, industriales, de entretenimiento, entre otros. A medida que la importancia del software ha crecido, la Ingeniería de Software ha intentado desarrollar tecnologías que faciliten y disminuyan el tiempo y el costo de construcción y mantenimiento del software; entre las cuales se pueden mencionar a las metodologías como una aportación que ha simplificado la labor no trivial de desarrollo de software. Una metodología para desarrollo de software, es un conjunto de pasos y procedimientos que deben seguirse para desarrollar sistemas computacionales [SOM09]. Por lo que se espera que al utilizar una metodología para desarrollo de software, ésta proporcione un conjunto de prácticas y herramientas que faciliten el proceso de desarrollo, obteniendo un producto con alta calidad, seguridad y que satisfaga las expectativas del cliente. 1.1 Planteamiento del Problema En México el 79% de las empresas desarrolladoras de software utilizan las metodologías conocidas como RUP (Rational Unified Process, Proceso Unificado de Racional), XP (extreme Programming, Programación Extrema) y Scrum [JIM12]. De manera específica, el 37% de las empresas utilizan RUP, el 26% utilizan XP y el 16% Scrum (véase Figura 1.1); considerando esta información se puede observar que el 42% de las empresas hacen uso de metodologías ágiles (porque XP y Scrum se consideran ágiles) y el 37% de una metodología tradicional (RUP); de este modo, al investigar cuál es la situación de esas empresas, permite plantear la posibilidad de diseño de una metodología que se adapte específicamente a sus necesidades porque no existe una metodología genérica que funcione para todos los proyectos y tanto RUP, XP y Scrum surgieron para el ámbito de desarrollo estadounidense y europeo, por lo cual al implantarlas en México no resultan ser siempre la mejor elección. Eréndira Miriam Jiménez Hernández Octubre 2012 11

1.2 Objetivos Figura 1.1. Metodologías utilizadas en las empresas mexicanas [JIM12] 1.2.1 Objetivo General Diseñar una metodología que se adapte al contexto actual de las empresas de desarrollo de software en México, basada en la nueva tendencia en el área de Ingeniería de Software: metodologías híbridas. 1.2.2 Objetivos Específicos Identificar las necesidades y prácticas de Ingeniería de Software presentes en las empresas dedicadas a desarrollar software en México. Definir una metodología híbrida para desarrollo de software que tome en cuenta lo investigado en el punto anterior. Probar la utilidad de la metodología propuesta en algunas empresas dedicadas a desarrollar software en México. Eréndira Miriam Jiménez Hernández Octubre 2012 12

1.3 Justificación META (MEtodología Tradicional y Ágil), una metodología híbrida para En México, más del 50% de las empresas dedicadas al desarrollo de software son candidatas a utilizar una metodología híbrida. Por lo cual, las metodologías existentes son tradicionales o ágiles y no se acoplan a las necesidades de las empresas [JIM12]. Por lo que el diseñar una metodología híbrida para que las empresas de desarrollo de software en México la puedan utilizar, es una buena opción para incrementar la productividad en dichas empresas. Lo anterior se comprobó a través de un estudio realizado con las empresas de software en México, dicho estudio se puede ver a detalle en el Artículo publicado en la Revista Digital Universitaria (véase Anexo 1). Para poder realizar el estudio se planteó una encuesta con 19 preguntas, con respuestas de opción múltiple (la cual se incluye en el Apéndice A del Anexo 1). También se recurrió a los datos estadísticos de INEGI (Instituto Nacional de Estadística y Geografía). Según INEGI, en el año 2010 se contabilizaron 9540 empresas en México dedicadas al desarrollo de software [INE11]. Para calcular el tamaño de la muestra, se aplicó la encuesta a un grupo piloto con 20 empresas y se obtuvo que: 40% se inclinaron por el uso de metodologías híbridas 60% no se inclinaron por el uso de metodologías híbridas Estos porcentajes representan los valores estadísticos de p y q respectivamente, mismos que se utilizaron para encontrar el tamaño de la muestra en la siguiente fórmula matemática [WAL99]: 2 Z pqn n = 2 2 NE + Z pq Donde: n es el tamaño de la muestra Z es el nivel de confianza p es la variabilidad positiva q es la variabilidad negativa N es el tamaño de la población E es la precisión o el error Eréndira Miriam Jiménez Hernández Octubre 2012 13

Considerando una población de 9540 empresas, un nivel de confianza del 95% y un error estándar en experimentos científicos del 5% [COC84], se tiene: 2 (0.95) (0.40)(0.60)(9540) n = 2 (9540)(0.05) + (0.95)(0.40)(0.60) n = 85.86 n 86 Por lo tanto, se seleccionaron aleatoriamente a 86 empresas de la lista que proporcionó el INEGI para que respondieran la encuesta. Si el porcentaje de error se hubiera disminuido, entonces el número de empresas a encuestar habría aumentado significativamente, incrementando los costos para obtener la información. Es importante mencionar que la selección de las empresas a las cuales se les aplicó la encuesta fue en forma aleatoria, que no todas las empresas señaladas por el INEGI se pudieron encontrar y que no todas mostraron interés en participar, de tal manera que en ese caso fueron sustituidas en forma aleatoria por otras empresas, hasta completar la muestra. Después de encuestar a las 86 empresas mexicanas dedicadas a desarrollar software, se obtuvieron los siguientes resultados de la tabla que se muestra en el Apéndice B del Anexo 1. En dicha tabla, sólo se muestra la información de las preguntas 3, 4, 6, 7, 8 y 13 de la encuesta; porque estas preguntas son las que permiten determinar el tipo de metodología utilizada por una determinada empresa para desarrollar software. (El nombre de las empresas que corresponden a los números de dicha tabla se encuentran en el Apéndice C del Anexo 1). Los valores que aparecen como respuesta a las preguntas fueron asignados dependiendo del tipo de metodología: Valor Tipo de metodología 1 Metodología Ágil 2 Metodología Híbrida 3 Metodología Tradicional Al analizar los datos, se encontró que el número de empresas que prefieren los tres tipos de metodologías se distribuyen de la siguiente manera: Tipo de metodología Número de empresas Metodologías Ágiles 22 Metodologías Híbridas 50 Metodologías Tradicionales 14 TOTAL 86 Eréndira Miriam Jiménez Hernández Octubre 2012 14

Se puede observar que el número de empresas que prefieren metodologías híbridas es de 50 y no híbridas de 36. Tipo de Número de metodología empresas HIBRIDA 50 NO HIBRIDAS 36 Para determinar si una empresa tiene inclinación por usar una determinada metodología, no se empleó una sola pregunta, sino los valores de las preguntas que distinguen a dicha metodología. En las preguntas donde era permitido responder más de una opción, se sumó la puntuación y se dividió entre el número de respuestas para encontrar el promedio de una pregunta determinada. Tomando en cuenta los datos mencionados, se realizó una prueba de hipótesis con proporciones donde: p 1 : Proporción de empresas desarrolladoras de software con una inclinación hacia metodologías híbridas. Hipótesis H 0 : p 1 0.50 H 1 : p 1 <0.50 La interpretación de la hipótesis es la siguiente: H 0 : H 1 : El 50% o más de las empresas desarrolladoras de software tienen una inclinación hacia el uso de metodologías híbridas. Menos del 50% de las empresas desarrolladoras de software tienen una inclinación hacia el uso de metodologías híbridas. El estadístico de prueba es [WAL99]: Donde: z p z = p p p( 1 p) n es el estadístico de prueba es la proporción de la muestra que tiene inclinación hacia el uso de metodologías híbridas p es la proporción de la población = 0.50 n tamaño de la muestra Eréndira Miriam Jiménez Hernández Octubre 2012 15

Sustituyendo: z = 50 0.50 86 0.50(1 0.50) 86 = 1.5096 La información obtenida en el estudio tiene una distribución normal, de tal manera que con un nivel de significancia (o error) del 5% el área de rechazo o no rechazo de la hipótesis nula H 0 es como se muestra en la Figura 1.2: Figura 1.2. Área bajo la curva de la distribución normal NOTA: El valor del área bajo la curva normal (-1.645) se obtuvo de tablas estadísticas [WAL99] Se observa en la Figura 1.2 que el estadístico de prueba cae en la zona de no rechazo; por lo tanto, no se rechaza H 0 y se dice que: El 50% o más de las empresas desarrolladoras de software tiene una inclinación hacia el uso de metodologías híbridas. Para corroborar la prueba de hipótesis se realizó un intervalo de confianza, el cual podría no hacerse, pero como su nombre lo indica, proporciona mayor certeza al experimento; así que el intervalo de confianza se hizo para un nivel de significancia del 5% (porque la prueba de hipótesis se realizó con un error del 5% y se tiene que considerar la misma en el intervalo). Los límites de dicho intervalo se muestran a continuación (véase Figura 1.3): Eréndira Miriam Jiménez Hernández Octubre 2012 16

z α 2 = z = z 0.05 2 0.025 = 1.96 Figura 1.3. Intervalo de confianza [WAL99] Lo cual implica que con un error del 5% la proporción de desarrolladores de software que prefieren metodologías híbridas se encuentran entre el 47.77% y el 68.5% pq p zα < p < p+ z n 2 α 2 pq n 50 86 50 50 1 86 86 1.96 < p < 86 50 + 1.96 86 50 50 1 86 86 86 0.4770 < p < 0.6855 En la investigación se puede observar que una metodología híbrida será de gran ayuda para las empresas desarrolladoras de Software de la República Mexicana, pero dadas las similitudes de México con los países latinoamericanos seguramente estos resultados se pueden extrapolar también para esos países, con las respectivas diferencias propias de cada una de esas naciones, empresas de desarrollo de software y grupos de trabajo. En resumen esta investigación mostró que es factible utilizar una metodología híbrida para desarrollar software en México. Además, proporcionó información útil para el diseño de la misma. Eréndira Miriam Jiménez Hernández Octubre 2012 17

1.4 Beneficios Esperados Elaborar una Metodología Híbrida para desarrollar software que cumpla con las características de calidad de la Norma Mexicana NMX-I-055-NYCE Contribuir con la Ingeniería de Software con una nueva Metodología Híbrida para desarrollo de proyectos de software. 1.5 Limites y Alcances Cada etapa del proceso de desarrollo será definida como un conjunto de tareas generales, de tal forma que existirán actividades como la estimación de costos o la elaboración de diagramas de UML (Unified Modeling Language, Lenguaje Unificado de Modelado) que no serán especificados con detalle. La herramienta META-Software sólo proporcionará apoyo en la generación de documentación descrita dentro del proceso de desarrollo de META. La metodología será probada en proyectos reales dentro de empresas mexicanas para comparar resultados, los proyectos seleccionados deberán cumplir con las características para las cuales es ideal utilizar la metodología propuesta. 1.6 Organización de la Tesis Esta tesis está dividida en cinco capítulos, a continuación se describe cada uno de ellos: Capítulo 1. Introducción. Planteamiento general del problema, descripción y alcance del trabajo, objetivos y beneficios esperados. Capítulo 2. Marco Teórico. Metodologías existentes, definiciones, terminología y conceptos a ser manejados en el trabajo. Capítulo 3. Metodología Propuesta: META. Descripción de la metodología, así como de la herramienta de apoyo llamada META-Software. Capítulo 4. Pruebas y resultados obtenidos. Capítulo 5. Conclusiones y trabajos futuros. 1.7 Resumen Las metodologías se han convertido en un elemento clave para la producción de sistemas y productos de software con alta calidad; de esta manera y con el objetivo de contribuir en el crecimiento de la industria dedicada a desarrollar software en México, se presenta la propuesta de una metodología basada en la nueva tendencia en el área de Ingeniería de Software: las metodologías híbridas. Eréndira Miriam Jiménez Hernández Octubre 2012 18

2 Marco Teórico 2.1 Introducción META (MEtodología Tradicional y Ágil), una metodología híbrida para De acuerdo con el Diccionario de la Real Academia Española, la palabra metodología es un conjunto de métodos que se siguen en una investigación científica o en una exposición doctrinal [RAE01]. En el área de Ingeniería de Software, el término metodología se refiere a un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo de sistemas computacionales [PRE05]. Actualmente hay dos tipos de metodologías: las tradicionales y las ágiles; aunque existe una nueva propuesta: las metodologías híbridas [JIH12]. Las metodologías de desarrollo de software han evolucionando a medida que los paradigmas de programación también lo han hecho, de tal manera que se acoplaron a ellos tratando de ajustarse a las nuevas necesidades; dichas metodologías han proporcionando herramientas y prácticas que ayudan en el proceso de desarrollo de software. Así que resulta de vital importancia revisar la evolución de las metodologías existentes para poder proponer una metodología híbrida que satisfaga las necesidades actuales de las empresas de desarrollo de software en México. 2.2 Estado del Arte 2.2.1 Metodologías Tradicionales Existen dos tipos de metodologías tradicionales: las metodologías para el paradigma estructurado y las metodologías orientadas a objetos [BRA00]. Con el surgimiento del paradigma estructurado, nacieron algunas metodologías acordes a dicho paradigma; como la creada por Yourdon [YOU76], en la cual el uso de Diagramas de Flujos de Datos, Diagramas de Contexto, Diagramas de Transición de Estados y Diagramas de Entidad-Relación, aparecían como una constante en el modelado del sistema. Cuando el paradigma de programación orientado a objetos apareció, surgieron metodologías para esta nueva forma de programar también; como OMT (Object Modeling Technique, Técnica de Modelado de Objetos) [RUM90], Métrica 3 [MPE11], RUP (Rational Unified Process, Proceso Unificado de Racional) [IBM11], entre otras. Las metodologías orientadas a objetos contribuyeron positivamente a las metodologías tradicionales existentes, al ser incrementales e iterativas. Además promovieron la Eréndira Miriam Jiménez Hernández Octubre 2012 19

asignación de roles dentro del equipo de desarrollo, facilitaron las división del sistema en varios subsistemas y fomentaron el rehúso de componentes. Así que de manera general, las metodologías tradicionales consideraron la importancia de documentar el sistema, permitiendo entender, extender y mantener el software; porque estas metodologías proveen una estructura bien definida y un orden. Sin embargo, también tienen algunas desventajas, entre las cuales se puede señalar que se requiere de un alto grado de disciplina, no se tiene respuesta rápida a cambios, se genera documentación innecesaria y se invierte mucho tiempo en el modelado del sistema. Además estás metodologías tienen un plan de proyecto muy riguroso. Por lo cual de manera general, no consideran que el análisis, el diseño y la construcción son impredecibles la mayoría de las veces. 2.2.1.1 RUP El Proceso Unificado de Racional, por sus siglas en inglés RUP, es un proceso de desarrollo de software que en conjunto con UML (Unified Modeling Language, Lenguaje Unificado de Modelado) [OMG11], constituye una de las metodologías estándar más utilizadas para el análisis, implementación y documentación de sistemas orientados a objetos y de información [PRE05]. Originalmente se diseñó una metodología genérica y de dominio público, UP (Unified Process, Proceso Unificado) [JAC05], sin embargo fue comprada por Rational Corporation de la empresa IBM, adoptando así el nombre de Rational Unified Process [IBM11], por lo cual para conocer RUP basta con aprender UP puesto que la esencia es la misma. RUP es una metodología creada por Ivar Jacobson, Grady Booch y James Rumbaugh. Los autores de RUP destacan que el proceso de software propuesto por RUP tiene tres características esenciales: a. Está dirigido por Casos de Uso. Un Caso de Uso es un fragmento de funcionalidad del sistema que proporciona al usuario un valor añadido; por lo que los Casos de Uso, representan los requisitos funcionales del sistema [IBM11]. En RUP los Casos de Uso no sólo son una herramienta de especificación de los requerimientos del sistema; también guían su diseño, implementación y prueba. Por lo que los Casos de Uso no sólo inician el proceso de desarrollo, sino que proporcionan un hilo conductor, permitiendo establecer trazabilidad entre los artefactos que son generados en las diferentes actividades del proceso de desarrollo. Eréndira Miriam Jiménez Hernández Octubre 2012 20

b. Está centrado en la arquitectura. La arquitectura de un sistema es la organización o estructura de las partes consideradas relevantes, lo que permite tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una perspectiva del sistema completo. La arquitectura involucra los aspectos estáticos y dinámicos significativos del sistema, está relacionada con la toma de decisiones que indican cómo tiene que ser construido el sistema y ayuda a determinar en qué orden; además, toma en cuenta los elementos de calidad del sistema, rendimiento, reutilización y capacidad de evolución. Por lo que RUP además de utilizar los Casos de Uso para guiar el proceso, presta especial atención al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactaba ante cambios posteriores durante la construcción y el mantenimiento. Cada producto tiene tanto una función como una forma y la función corresponde a la funcionalidad reflejada en los Casos de Uso y la forma proporciona la arquitectura. c. Es iterativo e incremental. RUP propone un proceso iterativo e incremental en donde el trabajo se divide en partes más pequeñas o mini proyectos. Permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya logrando durante cada mini proyecto, así durante todo el proceso de desarrollo. Cada mini proyecto puede verse como una iteración del cual se obtiene un incremento que produce un crecimiento del producto. Una iteración puede realizarse por medio de una cascada, es decir se pasa por los flujos fundamentales (Requisitos, Análisis, Diseño, Implementación y Pruebas). El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteración aborda una parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. RUP consta de 5 fases, las cuales se muestran en la Figura 2.1. Eréndira Miriam Jiménez Hernández Octubre 2012 21

Figura 2.1. Etapas de RUP [PRE05] La fase de inicio abarca la comunicación con el cliente y las actividades de planeación. Al colaborar con los clientes y los usuarios finales se identifican los requisitos de negocios para el software, se propone una arquitectura aproximada para el sistema y se desarrolla un plan la naturaleza iterativa e incremental del sistema subsiguiente. La fase de elaboración abarca la comunicación con el cliente y las actividades de modelado del modelo genérico del proceso. La elaboración refina y expande los casos de uso preliminares que se desarrollan como una parte de la fase de inicio, además, expande la representación arquitectónica para incluir cinco visiones diferentes del software: el modelo de casos de uso, el modelo de análisis, el modelo de diseño, el modelo implementación y el modelo de despliegue. La fase de construcción es idéntica a la actividad de construcción definida para el proceso genérico del software. La fase de transición abarca las últimas etapas de la actividad genérica de construcción y la primera parte de la actividad genérica de despliegue. El software se entrega a los usuarios finales para realizar pruebas beta y la retroalimentación del usuario reporta tanto defectos como cambios necesarios. Además, el equipo de software crea la información de soporte necesaria (por ejemplo, manuales de usuarios, guía de resolución de problemas, procedimientos de instalación) para el lanzamiento. Al final de la fase de transición el incremento de software se convierte en un lanzamiento de software utilizable. Eréndira Miriam Jiménez Hernández Octubre 2012 22

La fase de producción coincide con la actividad de despliegue del proceso genérico. Durante esta fase se monitorea el uso subsiguiente del software, se proporciona el soporte para el ambiente operativo (infraestructura) y se reciben y evalúan los informes de defectos y los requerimientos de cambios. 2.2.2 Metodologías Ágiles El esquema propuesto por las metodologías tradicionales ha demostrado ser efectivo y necesario en proyectos de gran tamaño (respecto a tiempo y recursos). Sin embargo, este enfoque no resulta ser totalmente adecuado para algunos proyectos actuales donde el entorno del sistema es cambiante y se exige reducir drásticamente los tiempos de desarrollo; en este escenario, nacieron las metodologías ágiles, que en esencia combinan una filosofía y un conjunto de directrices de desarrollo [SOM09]. La filosofía busca la satisfacción del cliente y la entrega temprana del software incremental; equipos de proyectos pequeños y con alta motivación; métodos informales; un mínimo de productos de trabajo y una simplicidad general de desarrollo. Las directrices de desarrollo resaltan la entrega sobre el análisis y el diseño, la comunicación activa y continúa entre los desarrolladores y los clientes. La agilidad es más que una respuesta efectiva al cambio; estimula las estructuras y actitudes de los equipos para que la comunicación (entre los miembros del equipo, los técnicos, la gente de negocios, los ingenieros de software y los clientes) sea menos complicada; resalta la entrega rápida del software; adopta al cliente como una parte del equipo de desarrollo y reconoce que la planeación tiene sus límites en un mundo incierto por lo cual el plan de trabajo debe ser flexible. Todas las metodologías ágiles se ajustan (en menor o mayor proporción) al manifiesto para el desarrollo de software y a los 12 principios señalados en la Alianza Ágil [PRE05]. Entre las metodologías ágiles pueden mencionarse: XP (extreme Programming, Programación Extrema) [BEC99], DSA (Development Software Adaptative, Desarrollo de Software Adaptativo) [HIG99], Scrum [SCR86] y Crystal [COC04]. Las metodologías ágiles, al igual que las metodologías tradicionales poseen ciertas ventajas y desventajas. Algunas de las ventajas es que presentan respuestas rápidas y efectivas al cambio. Tienen un plan de proyecto flexible y presentan una gran simplicidad de manera general en el desarrollo. Eréndira Miriam Jiménez Hernández Octubre 2012 23

Sin embargo, las metodologías ágiles generan poca documentación. Y no hacen uso de métodos formales. En la Tabla 1 se realiza una comparación entre las principales características de las metodologías ágiles con las metodologías tradicionales. Tabla 2.1. Metodologías Ágiles vs. Metodologías Tradicionales [JIM11]. Metodologías Ágiles Basadas en heurísticas provenientes de prácticas de producción de código. Proceso menos controlado, con pocos principios. Pocos artefactos. Pocos roles. Menos énfasis en la arquitectura del software. Metodologías Tradicionales Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo. Proceso mucho más controlado, con numerosas políticas/normas. Más artefactos. Más roles. La arquitectura del software es esencial. Producen poca documentación. Producen una gran cantidad de documentación. Fáciles de aprender e implementar. No requieren mucha disciplina. Especialmente preparados para cambios durante el proyecto. No existe contrato tradicional o al menos es bastante flexible. Difíciles de aprender e implementar. Requieren mucha disciplina. Cierta resistencia a los cambios. Existe un contrato prefijado. 2.2.2.1 XP XP, por sus siglas en inglés, Programación Extrema, es el proceso ágil que más se utiliza en México (véase Anexo 1); el trabajo fundamental sobre XP fue publicado por Kent Beck, en 1999. XP se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad; considera que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. La Programación Extrema se basa en 12 principios básicos [BEC99] agrupados en cuatro categorías: Eréndira Miriam Jiménez Hernández Octubre 2012 24

Retroalimentación a escala fina. o o o o El principio de pruebas: consiste en establecer un período de pruebas de aceptación del programa (llamado también período de caja negra), donde se definirán las entradas al sistema y los resultados esperados de estas entradas. XP recomienda automatizar estas pruebas para poder hacer varias simulaciones del sistema en funcionamiento. Proceso de planificación: en este principio, el usuario tendrá que escribir sus necesidades, definiendo las actividades que realizará el sistema, con esto se creará un documento llamado Historias del usuario. Se consideran suficientes entre 20 y 80 historias (todo dependiendo de la complejidad del problema) para formar el Plan de Liberación, el cual define de forma específica los tiempos de entrega de la aplicación para recibir retroalimentación por parte del usuario. Por regla general, cada una de las Historias del usuario suele necesitar de una a tres semanas de desarrollo. El cliente como parte del equipo: el cliente tiene la facultad de determinar los requerimientos, definir la funcionalidad, señalar las prioridades y responder preguntas de los programadores. Esta fuerte interacción cara a cara con el programador disminuye el tiempo de comunicación y la cantidad de documentación, junto con los altos costes de su creación y mantenimiento; razones por las cuales el cliente o el representante del cliente debe estar con el equipo de trabajo durante toda la realización del proyecto. Programación en parejas: es un concepto clave durante la actividad de codificación; XP recomienda que dos personas trabajen juntas en una misma computadora para crear el código de una historia. Esto es un mecanismo de resolución de problemas en tiempo real ( dos cabezas piensan mejor que una ) y el aseguramiento de la calidad en las mismas condiciones. Proceso continuo en lugar de por lotes. o o Integración continua: este principio permite al equipo hacer un rápido progreso implementando las nuevas características del software, en lugar de crear builds (o versiones) estables de acuerdo a un cronograma establecido. Los equipos de programadores XP pueden reunir su código y reconstruir el sistema varias veces al día, esto reduce los problemas de integración comunes en proyectos largos y estilo cascada. Refactorización: permite mejorar el diseño del sistema durante todo el proceso de desarrollo a los programadores XP, ellos evalúan continuamente el diseño y recodifican lo necesario, la finalidad es mantener un sistema enfocado a la minimización del código duplicado y/o ineficiente. Eréndira Miriam Jiménez Hernández Octubre 2012 25

o Entregas pequeñas: este principio consiste en colocar un sistema en producción, el cual se actualiza de forma rápida y constante permitiendo que el producto sea evaluado en un ambiente real. Entendimiento compartido. o o Diseño simple: se enfoca en proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni más ni menos. Este proceso permite eliminar redundancias y rejuvenecer los diseños obsoletos. Metáfora: empleada por los programadores al inicio del proyecto, y se utiliza en la creación de las historias y las tarjetas CRC (Class Responsibility- Collaboration, Clase Responsabilidad-Colaboración). XP centra su construcción en historias, que son breves descripciones de una función de un sistema, en lugar de los tradicionales diagramas y modelos UML. Las tarjetas CRC ayudan a definir actividades durante el diseño del sistema. Cada tarjeta representa una clase en el paradigma de programación orientado a objetos y define sus responsabilidades (lo que ha de hacer) y las colaboraciones con las otras clases (cómo se comunica con ellas). De esta manera la metáfora se utiliza como un recurso para describir los requerimientos del sistema. o o Propiedad colectiva del código: el principio señala que se debe generar un código con propiedad compartida; nadie es el propietario de nada, todos son el propietario de todo. Este método difiere en mucho a los métodos tradicionales en los que un programador posee un conjunto de código; XP señala que mientras haya más gente trabajando en un módulo, menos errores aparecerán. Estándar de codificación: es necesario definir las reglas para escribir y documentar el código desarrollado por diferentes equipos o personas; de tal manera que el código en el sistema se vea como si hubiera estado escrito por una sola persona. Bienestar del programador. o La semana de 40 horas: XP sostiene que los programadores cansados escriben código de menor calidad, por lo que es necesario minimizar las horas extras y mantener a los programadores frescos, de esta manera generarán código de mayor calidad; por lo cual XP sugiere que los programadores no laboren más de 40 horas a la semana. Eréndira Miriam Jiménez Hernández Octubre 2012 26

XP está organizado como cuatro actividades del marco de trabajo (planeación, diseño, codificación y pruebas), tal como se puede observar en la Figura 2.2. 2.2.2.2 Scrum Figura 2.2. Etapas de XP [PRE05] Scrum o también conocida como Melé, es una metodología ágil que define un conjunto de prácticas y roles. Fue propuesta en 1986 por Hirotaka Takeuchi e Ikujiro Nonaka [SCR86]. Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (interesados externos o internos) y el Team que incluye a los desarrolladores. Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Eréndira Miriam Jiménez Hernández Octubre 2012 27

Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint. Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint. Además durante un sprint, se deben realizar las Reuniones de Melé. Estas son reuniones cortas (por lo general de 15 minutos) y están presentes todos los miembros del equipo. Existen 3 preguntas que plantean y responden todos los miembros: 1. Qué se realizó desde la última reunión? 2. Cuáles son los obstáculos se encontraron? 3. Qué se espera lograr para la siguiente reunión del equipo? El ScrumMaster, preside la reunión y evalúa las respuestas de cada persona. Cada reunión de Melé ayuda al equipo a descubrir problemas potenciales tan pronto como sea posible. Estas reuniones diarias también conducen a la socialización del conocimiento y, por ende, a promover una estructura con organización propia (véase Figura 2.3). Scrum permite la creación de equipos auto organizado impulsando la co-localización de todos los miembros del equipo y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto. Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn) y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes. Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras, hasta paquetes de software. Eréndira Miriam Jiménez Hernández Octubre 2012 28

Figura 2.3. Proceso de Scrum [SCR86]. 2.2.3 Metodologías Híbridas Como se puede observar, existen una gran diversidad de metodologías; sin embargo, todas ellas caen dentro de alguna de las dos clasificaciones mencionadas: ágiles o tradicionales. Así que partiendo del significado de la palabra híbrido, según el Diccionario de la Real Academia Española [RAE01]: Se dice de todo lo que es producto de elementos de distinta naturaleza. Las metodologías híbridas pretenden retomar las ventajas de las metodologías existentes, de tal forma que sean una combinación de las mejores prácticas descritas en cada una de ellas. Dentro las metodologías híbridas existentes se puede mencionar a EssUP (Essential Unified Process, Proceso Esencial Unificado) como la pionera [JAC10]. 2.2.3.1 EssUP EssUP es una metodología creada por Ivar Jacobson en el 2010, basada en el UP, los métodos ágiles y la madurez de procesos [JAC10]. EssUP intenta ser ágil porque no pretende imponer un proceso específico, además toma en cuenta que es necesario tener flexibilidad y respuestas rápidas ante los cambios; pero, si deja en claro que es necesario documentar y modelar en UML, con lo cual retoma una importante característica de las metodologías tradicionales orientadas a objetos. Por consiguiente es considerada una metodología híbrida conceptualmente, ya que en la práctica el equipo de desarrollo de software que pretenda utilizar esta metodología debe Eréndira Miriam Jiménez Hernández Octubre 2012 29

seleccionar el modelo de ciclo de vida de desarrollo de software que mejor se adapte a sus necesidades, asignar los roles que crean convenientes y seleccionar las mejores prácticas. Con lo cual se presenta un problema que podría considerarse una desventaja de EssUp, se necesita experiencia y conocimiento suficiente para saber elegir las mejores prácticas dentro de la Ingeniería de Software y aplicarlas de manera adecuada en cada proyecto de software. EssUP presenta una nueva tendencia en metodologías para desarrollo de software, ya que intenta retomar algunas ventajas de las metodologías tradicionales y de las ágiles, convirtiéndola en la primera metodología considerada híbrida. 2.3 Norma Mexicana NMX-I-055-NYCE Esta norma está incluida dentro de las Normas Mexicanas para el área de Tecnología de la Información y es empleada en Ingeniería de Software para evaluar la Calidad de Producto (se utiliza para medir la calidad de las metodologías porque son un producto); está basada en la Norma Internacional ISO/IEC 9126-1: 2001 [ISO01]. Esta Norma Mexicana describe un modelo para la calidad del producto constituido por dos partes (véase Figura 2.4): 1. Calidad interna y externa. 2. Calidad en uso. Figura 2.4. Modelo para la calidad del producto [NYC06]. La primera parte del modelo especifica seis características para la calidad interna y externa, las cuales están subdivididas a la vez en subcaracterísticas. Estas subcaracterísticas se manifiestan externamente cuando el producto se usa y son el resultado de los atributos internos del mismo. Eréndira Miriam Jiménez Hernández Octubre 2012 30

La segunda parte del modelo especifica cuatro características de la calidad en uso, pero no elabora el modelo para la calidad en uso a un nivel inferior al de características, porque la calidad en uso es el efecto percibido por el usuario como el resultado de la combinación de las seis características de calidad del producto. 2.3.1 Modelo de Calidad Interna y Externa. Los atributos de calidad del producto se clasifican en seis características (funcionalidad, confiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad), las cuales son a su vez subdivididas en subcaracterísticas (véase Figura 2.5). Las subcaracterísticas se pueden medir mediante métricas internas o externas. Cada una de las características y subcaracterísticas se encuentran definidas en la norma. Figura 2.5. Modelo para la calidad interna y externa [NYC06]. 2.3.2 Modelo de Calidad para la Calidad en Uso. Los atributos de calidad en uso se clasifican en cuatro características: efectividad, productividad, seguridad y satisfacción (véase Figura 2.6). Estas características al igual que las de Calidad Interna y Externa, se encuentran definidas en la NMX-I-055-NYCE. Eréndira Miriam Jiménez Hernández Octubre 2012 31

Figura 2.6. Modelo para la calidad en uso [NYC06]. 2.4 Resumen El desarrollo de software requiere de hacer uso de metodologías, las cuales proveen una guía al equipo de desarrollo para crear un sistema con calidad. Por lo que resulta importante conocer qué tipo de metodologías existen, para qué tipo de proyectos están diseñadas y cómo deben de aplicarse en el ambiente real de desarrollo. Eréndira Miriam Jiménez Hernández Octubre 2012 32

3 Metodología Propuesta: META 3.1 Introducción Como resultado de la investigación realizada surge META (MEtodología Tradicional y Ágil), una metodología híbrida para desarrollo de proyectos de software. META fue creada a partir de un estudio realizado con empresas mexicanas desarrolladoras de software [JIM12]. Por esta razón, META se diseñó tomando en cuenta las necesidades actuales de esas empresas mexicanas; sin embargo puede aplicarse en empresas de otros países en las cuales se desee desarrollar proyectos de software que cumplan con las características para las cuales es ideal utilizar META. META en una metodología que combina algunas prácticas existentes dentro de las metodologías RUP (Rational Unified Process, Proceso Unificado de Racional), XP (extreme Programming, Programación Extrema) y Scrum; por lo cual es un híbrido entre lo tradicional y lo ágil. 3.2 Características de META META es una metodología diseñada para desarrollar proyectos de software con las siguientes características: Proyectos de desarrollo de aplicaciones Web (en el Apéndice 1 se pueden ver las características de una aplicación Web). Proyectos que se desarrollen en un lapso de 2 a 6 meses. Equipos de desarrollo conformados a lo más por 10 integrantes (sin contar a los usuarios y al cliente). 3.3 Requerimientos y Requisitos para el Uso de META Es necesario contar y cumplir con los tres siguientes requerimientos y requisitos para hacer uso de META: 1. Requerimientos Materiales: Papel rotafolio. Notas adhesivas. Cinta adhesiva. Marcadores de colores. Carpetas o Folders. Hojas blancas. Eréndira Miriam Jiménez Hernández Octubre 2012 33

2. Requisitos de Conocimientos Previos: Saber realizar Diagramas en UML (Unified Modeling Language, Lenguaje Unificado de Modelado) [OMG11]. Saber realizar Diagramas Entidad-Relación [ROS08]. Saber realizar Estimaciones de Costos. Saber realizar Prototipos de software. Saber programar en el lenguaje a utilizar con META. 3. Requisitos de la Empresa: Seleccionar proyectos de desarrollo de software que cumplan con las características para las cuales es ideal utilizar META (véase Sección 3.2) Tener los equipos de cómputo necesarios para que cada integrante del equipo META pueda desarrollar su función adecuadamente. Proporcionar al equipo de desarrollo un espacio de trabajo dentro de las instalaciones de la empresa que les permita estar co-localizados. 3.4 Capacitación para el uso de META Para utilizar META es necesario contar con los requerimientos y conocer: 1. Los roles que deben existir. 2. Los principios metodológicos de META. 3. El proceso de desarrollo de META. 3.5 Roles en META En META se plantea que deben existir los siguientes roles o papeles dentro del equipo de desarrollo, véase Tabla 3.1: Tabla 3.1. Roles en META ROL Cliente Líder del proyecto DESCRIPCION Especifica los requerimientos y es quién financia el proyecto de software. Se encarga de buscar nuevos proyectos, recopilar la información necesaria para establecer los requerimientos y negociar los proyectos; por lo que es el integrante del equipo de desarrollo que tiene más relación con el cliente/usuarios, así que debe tener facilidad para comunicarse con ellos en términos que el cliente/usuarios comprendan. Es además, el intermediario entre el cliente y el administrador del proyecto, por lo cual debe de saber cómo se realiza el Eréndira Miriam Jiménez Hernández Octubre 2012 34

Administrador del proyecto Programadores Probador Documentador META (MEtodología Tradicional y Ágil), una metodología híbrida para software también. Debe de tener la habilidad de unir ideas, personas y recursos; así como tener facilidad para la toma de decisiones. Se encarga de coordinar a los programadores, al probador y al documentador. Además organiza las reuniones necesarias para analizar los requerimientos, realizar el diseño, el plan de proyecto y las pruebas. Debe acompañar al líder del proyecto en las reuniones con el cliente. Son los responsables de codificar el diseño. Se encarga de realizar las pruebas en todo momento. Es decir, verifica que se realizan las actividades de manera adecuada en cada fase del proceso de desarrollo de software. Además deberá cumplir con la tarea de asegurar la calidad, haciendo uso del Ciclo y los 14 Principios de Deming. Su función principal es generar los documentos que respalden y documenten lo que se va generando a lo largo del proceso de software. Usuarios finales Son las personas que interactúan con el software una vez que se libera para su uso productivo. META retoma una importante característica de las metodologías ágiles: incluir a los usuarios finales y al cliente como parte del equipo de desarrollo. Esto ayuda en gran medida a lograr el éxito del proyecto, ya que son ellos quienes saben lo que quieren, por lo tanto, se debe tener el cuidado de propiciar un ambiente de confianza y colaboración con ellos. Si el equipo de desarrollo es menor a 5 integrantes, es decir que no se pueda asignar al menos un rol a cada integrante (Líder del Proyecto, Administrador del Proyecto, Programador, Probador y Documentador), pueden hacerse las adecuaciones necesarias para que una persona cumpla con uno o dos roles; aunque se sugiere que una persona sea destinada a cumplir sólo un rol. De manera general, se puede resumir el flujo de comunicación entre los integrantes del equipo de desarrollo tal como se muestra en la Figura 3.1. Eréndira Miriam Jiménez Hernández Octubre 2012 35

Figura 3.1. Roles en META * * El diagrama utilizado para representar el flujo de comunicación es un diagrama con simbología propia, así como otros diagramas utilizados en este capítulo, en caso contrario llevan la referencia respectiva a su autor. 3.6 Principios Metodológicos de META Para poder utilizar adecuadamente META se deben conocer los siguientes principios metodológicos: Hacer uso de papel rotafolio. Es un papel bond de medidas 63.5cm x 77.47cm aproximadamente. Es usado como una herramienta de comunicación para aplicarse durante el trabajo cara a cara porque facilita la interacción y el debate. Se puede utilizar en exposiciones, con explicaciones dialogadas u observaciones, así como en la presentación de resultados de un trabajo en equipo o para realizar lluvias de ideas temáticas. Es conveniente el uso de este tipo de papel porque tiene un bajo costo, es fácil de transportar, propicia la participación en un grupo y se pueden retomar los contenidos debido a la permanencia del mensaje, lo cual no se asegura si se escribe en un pizarrón por ejemplo. Eréndira Miriam Jiménez Hernández Octubre 2012 36

Además se sugiere hacer uso de marcadores o plumones de distintos colores para tratar de proporcionar mayor presentación a lo escrito en el rotafolio. Realizar lluvias de ideas durante las juntas. Esta técnica consiste en la reunión del equipo de trabajo para intentar descubrir cuál es el problema, cuál es la causa de un problema y cómo resolverlo; a través de la participación de cada miembro con sus ideas. El proceso que se sigue para esta técnica es el siguiente: a) Seleccionar el tema. b) Generar la lluvia de ideas a través de la participación de los involucrados. c) Realizar el análisis de las ideas. d) Seleccionar las mejores ideas. Para obtener mejores resultados se recomienda seguir las siguientes reglas: 1) El líder debe analizar con anterioridad los puntos a tratar, de manera que presente sólo opciones a los demás. 2) Todos los presentes en la reunión deben participar. 3) Se deben anotar las ideas en el papel rotafolio. 4) Se deben analizar las ideas; sin embargo, el líder del proyecto será quien tome las decisiones finales tomando en cuenta la experiencia de los demás miembros del equipo. Hacer uso del Ciclo de Deming [DEM90] para la Gestión de Riesgos durante todo el proceso de desarrollo de META. Durante el proceso de desarrollo del software, se tendrán que prevenir riesgos y eliminarlos, resultando conveniente hacer uso del Ciclo de Deming, véase Figura 3.2. Como parte de los documentos que se deben elaborar, se tiene un apartado de documentación para la gestión de riesgos y problemas, mismos que se explicarán en la sección del Proceso de Desarrollo de META; sin embargo aquí se describe el método adecuado para realizar dichas gestiones. Eréndira Miriam Jiménez Hernández Octubre 2012 37

Figura 3.2. Ciclo de Deming [DEM90] En el Ciclo de Deming se identifican 4 actividades primordiales, las cuales se describen a continuación: Planear: se requiere identificar los objetivos y procesos que se requieren mejorar; para después recopilar los datos para profundizar en el conocimiento del proceso. Posteriormente se deben analizar e interpretar los datos, establecer los objetivos de mejora, detallar las especificaciones de los resultados esperados y definir los procesos necesarios para conseguir estos objetivos. Hacer: Implementar los procesos necesarios para llevar a cabo el plan elaborado con anterioridad. Verificar: Comprobar que se implementaron las cosas según lo planeado. Actuar: Documentar el ciclo para tener presente cómo mejorar la próxima vez. Considerar los 14 Principios de Calidad de Deming [DEM90], para garantizar calidad en el proceso y en el producto de software. Los 14 principios han sido adecuados para ser empleados en una empresa de desarrollo de software. La razón por la cual se consideró el Ciclo y los Principios de Deming como una opción viable para ser incluida en META, fue porque la mayoría de los estándares internacionales de calidad adoptan el Sistema Deming como punto de referencia en sus propuestas; esto se determinó después de realizar una estancia de investigación Eréndira Miriam Jiménez Hernández Octubre 2012 38

con el Dr. Francisco Ortiz Zaragoza en la Universidad Politécnica de Cartagena, en España. Los 14 principios se describen a continuación: 1) Crear constancia, con la finalidad de ser más competitivos y permanecer en el mercado. En este punto se tratan las mejoras a la compañía, como son el tener y hacer uso de tecnología actualizada, contar con equipo de buena calidad, procesos y procedimientos adecuados para la elaboración del producto de software; con lo cual se garantizará la permanencia en el mercado de la empresa. 2) Comprender y adoptar la nueva filosofía. La calidad debe convertirse en la nueva cultura. Ante el reto de la competitividad internacional, es necesario que todos los miembros del equipo tengan consciencia de eliminar errores, defectos, mala calidad y malas prácticas. De esta manera, un servicio confiable reduce los costos, las demoras y los errores. Para el logro de la calidad se tendrá que concientizar a todos los integrantes del equipo de desarrollo. Ya que la calidad debe ser compromiso de todos. 3) Terminar con la dependencia de la inspección masiva. Es necesario acabar con las inspecciones de volúmenes grandes de información o de grandes módulos, ya que esto resulta costo y no necesariamente es acertado. A cambio de esto, es necesario concientizar a los integrantes del equipo que deben obtener desde un principio pequeños módulos o productos de software de calidad. 4) Terminar con la práctica de hacer negocios con base al precio. Antes de adquirir hardware o software, se debe asegurar que cuentan con la calidad que se requiere, en lugar de comprar porque tienen el menor costo. 5) Encontrar y resolver problemas para mejorar el sistema de desarrollo de software, constante y permanentemente. Es necesario que el equipo esté preparado para afrontar los problemas que se presenten día a día. Con esta pauta, se analizarán y se detectarán los Eréndira Miriam Jiménez Hernández Octubre 2012 39

problemas, para su corrección y prevención. Para lo cual se debe hacer uso del Ciclo de Deming descrito anteriormente. 6) Instruir métodos modernos de adiestramiento. Es de suma importancia que a los integrantes del equipo se les destine recursos, tanto de tiempo como de dinero, para que puedan adquirir un adiestramiento adecuado y les sea más sencillo acoplarse a la empresa de desarrollo de software y al equipo con el cual trabajarán. 7) Adoptar e implantar el liderazgo. Dentro de la empresa como dentro del equipo de desarrollo, debe existir el liderazgo. Un buen líder (como lo define Deming), crea confianza e impulsa a los demás para que busquen nuevas maneras para hacer las cosas. Además dirige los cambios, busca modelos de acción para hacer lo que está bien y opera con los recursos emocionales de los integrantes del equipo, con valores, compromisos y aspiraciones. Es decir, un buen líder hace sentir a los demás integrantes un alto nivel de realización, mostrándoles cómo contribuye su trabajo a la realización de las metas del proyecto; con lo cual se estimula la necesidad humana de: sentirse importante, diferente y útil. 8) Expulsar el miedo dentro del equipo de desarrollo. Los integrantes necesitan trabajar en un ambiente estable y seguro, que ofrezca apoyo y no amenazas. Por esta razón, se deberá tener cuidado en los siguientes aspectos para evitar el temor: a) Posibilidad de perder el empleo b) Posibilidad de sufrir algún daño físico. c) Evaluación del desempeño. d) Fracasos en la capacitación. e) Mala supervisión. f) Falta de definiciones operacionales. 9) Romper las barreras entre los integrantes del equipo. Es muy importante que todos los integrantes del equipo de desarrollo estén interrelacionados entre sí, que formen un equipo con un fin común, que es el de producir un producto de software de excelente calidad y entregarlo a Eréndira Miriam Jiménez Hernández Octubre 2012 40

tiempo. Por lo cual es importante quitar las barreras que impiden la comunicación. Los factores más comunes de las barreras son: a) Mala comunicación o ausencia de la comunicación b) Desconocimiento de las metas c) Decisiones o políticas confusas y que requieren interpretación d) Cuotas y normas de trabajo e) Celos por posiciones y salarios f) Problemas interpersonales Es importante tener en cuenta que la duración y el éxito de una empresa y/o equipo de desarrollo, estará condicionado por las buenas relaciones, la comunicación y la confianza que se les profese. Para lo cual, se tiene que cambiar la actitud de los miembros del equipo o de la empresa; entendiéndose que todos deben estar abiertos a la comunicación y dar apoyo completo para realizar las tareas necesarias. 10) Eliminar las metas numéricas. Las metas numéricas que se fijan para los integrantes del equipo de desarrollo, sin ofrecer una guía que lleve a la meta, son contra producentes, ya que generan frustración y resentimiento. Algunos ejemplos de carteles y metas numéricas son: a) Hacerlo bien la primera vez. b) Nuestro trabajo es la calidad. c) Incrementar las ventas en un 10% el siguiente año. 11) Eliminar estándares de trabajo que estipulen cantidad y no calidad. Las cuotas numéricas sólo toman en cuenta los números, no la calidad ni los métodos. Porque estimulan a la gente para que produzcan cantidad en vez de calidad. Por lo que no se debe recurrir a las cuotas cuando lo que se requiere es liderazgo. Los objetivos no son malos; el problema es cuando se fijan objetivos sin proveer los medios para alcanzarlos, o cuando los mismos son utilizados con criterio de inspección final. Eréndira Miriam Jiménez Hernández Octubre 2012 41

Un estándar de trabajo apropiado definirá lo que es y lo que no es aceptable en cuanto a calidad, para lo cual sugiere Deming que se estudie el trabajo y que se definan los límites del trabajo. 12) Eliminar las barreras que impiden al integrante del equipo estar orgulloso de su labor. Es importante que los miembros del equipo de desarrollo estén enterados de cuál trabajo es aceptable y cuál no; ya que esto los motivará a hacer las cosas bien y les permite hacer una autoevaluación. Para esto es recomendable: a) Proporcionar a los integrantes del equipo y de la empresa, materiales, herramientas y métodos apropiados. b) Atender las necesidades básicas de los integrantes. c) Cerciorarse de que los integrantes entienden la gran importancia que desempeñan dentro del proceso de desarrollo del software. 13) Educación y entrenamiento. Esto permitirá adaptar a las personas a nuevos proyectos y nuevas responsabilidades. Además, permite la superación, el desenvolvimiento y la confianza del integrante del equipo. 14) Crear una estructura que impulse día a día los trece puntos anteriores. Esto se requiere para tener un proceso de calidad que genere productos de software que satisfagan las expectativas del cliente, cumplan lo pactado en tiempo y recursos. Por lo que con dichos principios se guían las actividades dentro del proceso de desarrollo de META. 3.7 Proceso de Desarrollo de META Dentro de META se tienen 4 fases o etapas principales (Planteamiento, Preparación, Construcción e Implantación), tal como se puede apreciar en la Figura 3.3, las cuales se describirán más adelante: Eréndira Miriam Jiménez Hernández Octubre 2012 42

Figura 3.3. Proceso de desarrollo de META El proceso de manera general se puede comparar con lo que pasa en una carrera de obstáculos, en donde todo el equipo de desarrollo corre como un solo individuo hasta llegar Eréndira Miriam Jiménez Hernández Octubre 2012 43

a la meta; haciendo la analogía, cada una de las etapas son obstáculos que el equipo debe pasar. Pero, a diferencia de lo que pasa en una carrera de obstáculos, si no se puede brincar una etapa en un primer intento, existe un camino alternativo que permite realizar una serie de iteraciones para poder estar preparados y saltar para continuar con la siguiente fase. 3.7.1 Planteamiento En esta etapa se deben cumplir los siguientes objetivos: Definir los requerimientos del proyecto que se va a desarrollar. Esto se hace en constante comunicación entre el líder y el cliente a través de reuniones con lluvias de ideas. Es recomendable que el administrador del proyecto también esté presente para poder brindar una asesoría técnica en caso de ser necesario. Las propuestas o ideas deben escribirse en un papel rotafolio de tal manera que sea visible para todos los involucrados lo que se plantea; se sugiere que el líder sea quien escriba las ideas, aunque si el cliente o el administrador desean escribir personalmente algo es válido. Para esta actividad en particular, se sugiere que se le dé al cliente la oportunidad de expresar sus ideas, porque en muchas de las ocasiones los desarrolladores creen saber lo que él cliente quiere y se puede cometer el error de diseñar algo que no se desea. Después de escuchar lo que el cliente desea, se deben elaborar los Diagramas de Casos de Uso tal como los plantea UML [OMG11], los cuales describirán la funcionalidad del sistema a desarrollar para corroborar así, que se comprendió lo que el cliente desea. Además, se debe(n) elaborar el Diagrama de Interfaz-Navegación de la(s) ventana(s) principal(es), con la intención de tener una referencia del diseño que tendrán las demás ventanas. Estos diagramas permitirán al cliente visualizar el software, por lo que son de gran ayuda al momento de definir lo requerimientos. Una pauta a considerar para saber cuántas ventanas deben dibujarse a través de un Diagrama de Interfaz-Navegación, es tomando en cuenta el número de actores diferentes o usuarios del sistema. Por ejemplo se pueden ver los Diagramas de Interfaz-Navegación de las Figuras 3.4, 3.5 y 3.6, en ellas se muestran los elementos que incluirán la ventana principal o la página de inicio del sitio, y se indican hacia a dónde se dirigen los botones con Eréndira Miriam Jiménez Hernández Octubre 2012 44

números encerrados en círculos de color verde; este ejemplo muestra cómo deben de especificarse estos diagramas en el papel rotafolio. Figura 3.4. Ejemplo de Diagrama Interfaz-Navegación de la página de inicio del sitio. Figura 3.5. Ejemplo de Diagrama Interfaz-Navegación de la página principal de los Clientes. Eréndira Miriam Jiménez Hernández Octubre 2012 45