http://publicaciones.uci.cu/index.php/sc Tipo de artículo: Artículo original Temática: Ingeniería de Software Recibido: 19/03/2012 Aceptado: 04/06/2012 Publicado: 15/06/2012 Aplicando el método de Boehm y Turner Applying the Boehm and Turner method Mairelys Boeras Velázquez 1, Laritza Cabrera Barroso 2, Eileén Llano Castro 3, Ana María Sánchez Gonzalez 4, Yaima Oval Riveron 4, Eylin Hernández Luque 4 1 CISED. Departamento de Identificación. Universidad de las Ciencias Informáticas, Carretera a San Antonio de los Baños, km 2 ½, Torrens, Boyeros, La Habana, Cuba. CP.: 19370 2 CENIA. Departamento Gestión Documental. Universidad de las Ciencias Informáticas, Carretera a San Antonio de los Baños, km 2 ½, Torrens, Boyeros, La Habana, Cuba. CP. 19370 3 CENIA. Centro de Informatización Universitaria. Universidad de las Ciencias Informáticas, Carretera a San Antonio de los Baños, km 2 ½, Torrens, Boyeros, La Habana, Cuba. CP. 19370 4 Departamento de Ingeniería y Gestión de Software y PP. Facultad 1. Universidad de las Ciencias Informáticas, Carretera a San Antonio de los Baños, km 2 ½, Torrens, Boyeros, La Habana, Cuba. CP. 19370 Autores para la correspondencia: {mbohera, lcabrera}@uci.cu Resumen La ingeniería de software bajo restricciones de tiempo, costo y calidad trata sobre la aplicación de prácticas y métodos para construir productos de software que cumplan las expectativas de clientes y usuarios. En ocasiones, la mala selección de los métodos no permite obtener los resultados esperados en los proyectos de desarrollo de software. Pero en la actualidad, ya se cuentan con técnicas que teniendo en cuenta las características de estos proyectos permiten realizar una selección más acertada del método de desarrollo a utilizar. En el presente trabajo, tomando como referencia un caso de estudio y utilizando el método de Boehm y, a partir del análisis, sus cinco criterios, se realiza la selección más acertada del enfoque, la metodología y las prácticas a utilizar en el proceso de desarrollo de software. Palabras clave: Enfoque; método de Boehm y Turner; metodología. 1
http://publicaciones.uci.cu/index.php/sc Abstract Software engineering under constraints of time, cost and quality, is about the application of practices and methods to build software products that meet the expectations of customers and users. Sometimes, a poor selection of methods does disallows achieving the expected results in projects. But nowadays, there are some techniques that taking into account the characteristics of a project, allows a proper selection of the right development method to use. In this paper presents, taking a case study as reference and using the Boehm and Turner method from the analysis five criteria, the selection of the most appropriate approach, methodology and practices to use in the software development process. Keywords: Approach, Boehm and Turner method, methodology. Introducción La ingeniería de software supone la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software (IEEE, 1993). Sucede que lo que puede entenderse como sistemático, disciplinado y cuantificable para un equipo de desarrollo, puede resultar inconsecuente o caótico para otros. La experiencia de años de trabajo en el desarrollo de software indica que el éxito radica en una mayor planificación, siguiendo una guía de procesos que permiten la organización y control del proyecto. Por otro lado, tendencias actuales van dirigidas al uso de metodología que parecen contradecir esta visión tradicional. Las necesidades de los clientes pueden ser muy cambiantes y por ello es preciso adoptar mecanismos que faciliten la adaptación rápida a dichos cambios, porque puede correrse el riesgo de estar resolviendo el problema equivocado. Por otro lado, la dinámica del mercado, exige entregas constantes que demandan tiempos de desarrollo cada vez más cortos. A estas corrientes que coexisten en la construcción del software actual se les conoce como enfoque ágil y enfoque prescriptivo de desarrollo. El enfoque prescriptivo, denominado en algunas bibliografías como tradicional o pesado, busca la estructura, orden y consistencia del proyecto de desarrollo de software en cuestión. Se les llama prescriptivos porque prescriben un conjunto de elementos del proceso (acciones, tareas, productos de trabajo, mecanismos de control y aseguramiento de la calidad). Además definen la forma en que los elementos del proceso mencionados anteriormente deben relacionarse entre sí (Pressman, 2005). El enfoque ágil, llamado también como enfoque ligero se centra en los miembros del equipo y su interacción, en la entrega rápida de versiones de software funcional, en la colaboración constante del cliente y la facilidad para manejar los cambios, dándole menor importancia a las herramientas, documentación, la formalidad y planificación exhaustiva del proceso (Manifiesto Ágil, 2001). 2
http://publicaciones.uci.cu/index.php/sc Aunque estas visiones parezcan opuestas, lo cierto es que se requiere disciplina, pero también adaptabilidad y agilidad. La selección de un enfoque y en función de este la metodología a utilizar, dependen de las circunstancias y características específicas de cada proyecto de desarrollo de software. El análisis de estas cuestiones, así como de todas las decisiones que se toman en cuanto a la forma de enfrentar el proyecto, facilitan o no, la adopción de un enfoque. La realidad en la mayoría de los proyectos de software actuales, es que el esfuerzo dedicado a la valoración de estas cuestiones todavía es insuficiente. Esto hace que la selección de la metodología a utilizar parezca un acto de fe, en lugar de una evaluación de alternativas técnicas, costos, beneficios, condiciones sociales y riesgos asociados. La presente investigación tiene como objetivo, a partir de un caso de estudio, seleccionar el enfoque, metodología y prácticas más adecuadas a utilizar en el proceso de desarrollo de software, mediante el método Boehm y Turner que permite caracterizar el proyecto de software a partir de 5 criterios y estimar cuan ágil o prescriptivo debía ser el enfoque a utilizar. Materiales y métodos Por la diversidad de características de los proyectos hoy día, donde se mezclan elementos que favorecen el uso de ambos enfoques, existe una tendencia a utilizar un enfoque híbrido, donde se apliquen las prácticas que se proponen en diferentes metodologías y permitan una mejor adaptación a las particularidades de cada proyecto de desarrollo de software. Es muy común encontrar, la definición de criterios de evaluación para la valoración del ambiente en el que se desarrolla un proyecto, o para la selección de la metodología de desarrollo bajo la que se estará desarrollando el mismo. En búsquedas realizadas para determinar un método que pudiera ser usado en la determinación del enfoque y la metodología para la ejecución del proyecto, se encontraron el de Boehm y Turner y otros que basan su funcionamiento en criterios de selección, como son: la presencia y el conocimiento (Tinoco et al., 2010). Se selecciona el método de Boehm y Turner debido a que los otros métodos encontrados van más encaminados a la selección de la metodología de desarrollo en sí, y no a determinar el enfoque del proyecto dado sus características. El método de Boehm y Turner plantea 5 criterios fundamentales mediante los que se estará valorando el proyecto; estos son: tamaño del equipo, criticidad del producto, dinamismo de los cambios, cultura del equipo y personal con que se cuenta. Cada uno de esos criterios tiene elementos que lo discriminan y por tanto se tienen en cuenta a la hora de seleccionar uno u otro enfoque (Gabardini y Campos, 2004). Para la selección del valor que se ubicará en cada eje 3
http://publicaciones.uci.cu/index.php/sc (uno para cada criterio) de la estrella se debe tener en cuenta el comportamiento de estos criterios en el proyecto. En lo sucesivo se describe cada uno: Tamaño: Este criterio se utiliza para representar el número de personas involucradas en el proyecto. Pueden tenerse en cuenta el nivel de complejidad que pueda presentarse en la comunicación entre los miembros del proyecto y los costos que pueden provocar cambios esperados. Criticidad: Se utiliza para evaluar la naturaleza del daño ocasionado por defectos que no hayan sido detectados al producto. Su evaluación puede ser cualitativa. Dinamismo: Representa la rapidez con la que pueden estar cambiando los requerimientos del proyecto. Personal: Representa la proporción del personal con experiencia alta, media y baja. Los métodos orientados al plan no se ven afectados negativamente por este factor pues no interesa el nivel de experiencia con la que cuenten los miembros del equipo. Cultura: Las organizaciones y las personas que relaciona el proyecto pueden depender de la confianza o de la relación contractual. Esto refleja el nivel de ceremonia necesario y aceptado: documentación, control, formalismo en las comunicaciones. La Figura 1 muestra una representación de la estrella de Boehm y Turner para un proyecto de desarrollo de software. Tomada de (Gabardini et al., 2004). Figura 1. Representación de la estrella de Boehm y Turner. 4
http://publicaciones.uci.cu/index.php/sc Resultados y discusión A través del siguiente caso de estudio se analiza el enfoque, metodologías y prácticas más adecuadas a utilizar, según los criterios que propone el método de Boehm y Turner. Caso de estudio El proyecto para el desarrollo del Sistema para la emisión de pasaportes diplomáticos, de servicio y acreditaciones diplomáticas de la República Bolivariana de Venezuela, perteneciente al Centro de Identificación y Seguridad Digital (CISED), tiene como principal objetivo dotar a este país de un sistema que posibilite la emisión de estos documentos cumpliendo los estándares internacionales para documentos de este tipo. El proyecto dentro del cual se desarrolla el sistema es guiado por un contrato que puede ser difícilmente modificado. El pasaporte diplomático y el pasaporte de servicio son los documentos de viaje que el Gobierno Venezolano emite para los funcionarios que viajarán cumpliendo actividades en función del mismo. La acreditación diplomática es el documento que emite la República Bolivariana de Venezuela para identificar a los ciudadanos extranjeros que son acreditados ante el Gobierno en función del cumplimiento de actividades diplomáticas en el país. Para el desarrollo del sistema fueron seleccionados 11 especialistas graduados del área de informática con una experiencia promedio de 3 años en proyectos de desarrollo de software. De los especialistas, el 20 % ha trabajado anteriormente con la tecnología a utilizar, la otra parte del equipo aunque no domina totalmente la tecnología, se siente comprometido con el nuevo reto a asumir. El equipo de desarrollo trabajará de manera agrupada en un mismo local en Venezuela, donde tendrán todas las condiciones de trabajo necesarias. Cuenta dentro de su estructura organizativa con un jefe de desarrollo; el cual tiene como papel fundamental guiar, organizar y controlar el proceso de desarrollo de software. Entre los miembros del equipo existe confianza y una buena comunicación, lo que propiciará un buen ambiente de trabajo. Por experiencias en otros desarrollos en los que el equipo ha trabajado junto, se evidencia una buena adaptación a los cambios imprevistos. Durante el tiempo de desarrollo del sistema, permanecerán de forman regular especialistas funcionales de la institución venezolana para la que se desarrolla el sistema. La interacción de los especialistas funcionales con el equipo de desarrollo posibilitará el ajuste del software a las necesidades del cliente de forma controlada. A pesar de la presencia de estos especialistas, se pronostican cambios sustanciales en los requerimientos del sistema una vez levantados; pues las áreas involucradas no tienen bien definidos sus procesos. Además, los especialistas funcionales no tienen una clara visión de todas sus necesidades. 5
http://publicaciones.uci.cu/index.php/sc Análisis de la propuesta A continuación se caracteriza el proyecto a partir de los criterios que propone el método y se ubican los resultados en la Estrella de Boehm y Turner. Tamaño: El equipo de desarrollo está formado por 11 especialistas para la implementación de un total de 73 funcionalidades con ciertos elementos de complejidad, características que permiten clasificar el equipo de desarrollo como pequeño y al sistema como mediano. Para determinar la cantidad de especialistas necesarios para el desarrollo del proyecto bajo las condiciones que se han descrito se utilizó el método de estimación COCOMO II. Método de estimación que relaciona características del personal, condiciones o restricciones bajo las cuales se lleva a cabo el proyecto (Gómez y López, 2009). Teniendo en cuenta los elementos antes descritos, el esfuerzo que realizarán los miembros del equipo para dominar la tecnología con la ayuda de los especialistas experimentados, y la experiencia que tienen trabajando como equipo; será posible ubicar el punto de evaluación más cercano al centro del eje de coordenadas apuntando desde esta perspectiva a un enfoque ágil. Criticidad: El equipo de desarrollo tiene una elevada responsabilidad con la calidad del producto a obtener, debido al impacto social del mismo. Este sistema permitirá a los funcionarios venezolanos obtener un pasaporte que cumpla con las normas de la Organización de Aviación Civil Internacional (OACI). Los defectos que se detecten una vez obtenido el producto pueden provocar: o Que los funcionarios extranjeros y venezolanos se vean involucrados en problemas de falsa identidad debido a fallas del sistema. o Gastos para la Institución debido a que la materia prima utilizada para la impresión de los documentos es muy costosa. El valor para este criterio dentro de la estrella se pondera como medio, debido a que los efectos por errores del producto, si bien no provocarán pérdidas de vidas tendrán un fuerte impacto social y monetario para la institución en caso de presencia. Dinamismo: Las áreas de la institución que involucra la solución son objeto de una transformación organizacional, por lo que no se tiene claridad de todos los procesos del negocio que se pretenden automatizar. Como consecuencia de ello pueden aparecer cambios en los requerimientos del sistema en cualquier fase del proceso de desarrollo. El constante cambio en los requisitos es un riesgo que se asumirá durante todo el ciclo de desarrollo del software. Para mitigarlo, deben adoptarse mecanismos que faciliten la asimilación y adaptación rápida a dichos cambios. Tomando en cuenta esta necesidad como una de las ventajas que brinda el enfoque ágil, se ha ubicado este punto bien 6
http://publicaciones.uci.cu/index.php/sc cercano al centro de la Estrella. El valor se tomó teniendo en cuenta la cantidad de funcionalidades que no pudieran cambiar a lo largo del desarrollo, como se prevé que cambien casi todas se determinó que solo el 5 % del total de ellas no cambiarían, valor que se refleja en el eje correspondiente. Personal: Todos los desarrolladores son graduados de la especialidad de informática con un promedio de 3 años de experiencia laboral, pero solo el 20 % domina el trabajo con la tecnología que se pretende utilizar. Estos elementos evidencian claramente que la evaluación del proyecto en este punto no converge a un desarrollo ágil por lo que el punto de evaluación distará en gran medida del centro eje de coordenadas. Para determinar este valor se realizaron evaluaciones a los miembros del equipo donde se determinó si eran programadores Junior (menos experimentados) o Senior (más experimentados). Luego se aplicó el cálculo básico para determinar el porciento que representaba cada grupo del total de miembros. Esto arrojó como resultado que el 80 % de los desarrolladores formaban parte del grupo de programadores poco experimentados y el resto del grupo más experimentado, valores que fueron representados en el eje correspondiente. Cultura: El equipo de proyecto presenta una estructura de mando bien definida, donde cada miembro del equipo conoce sus responsabilidades y actividades. Existe una buena comunicación y confianza entre sus miembros puesto que han trabajado juntos en otras ocasiones. Las decisiones tomadas son previamente analizadas y consultadas con todos los involucrados. Las actividades son planificadas en función de los hitos del proyecto y asignadas a cada miembro, teniendo en cuenta la carga de trabajo y el rol que desempeñan. El trabajo es supervisado por la dirección del proyecto para identificar posibles problemas que provoquen el atraso del mismo. Los elementos antes descritos evidencian organización en el desarrollo del trabajo, pero al ser un equipo pequeño no necesitan relación contractual dada la buena comunicación y confianza entre sus miembros. Cada especialista en el desempeño de su rol será libre de incorporar ideas que no afecten el diseño del sistema, ni los compromisos planificados. Para la obtención del valor colocado en el eje se realizó el siguiente análisis: se fueron ubicando las características en cada uno de los enfoques tratados (ágil o pesado) teniendo en cuenta su fuerte presencia en el mismo. Un ejemplo es: Cada especialista será libre de incorporar ideas al desarrollo, siempre que no afecten el diseño del mismo; esta característica fue ubicada en el grupo de enfoque ágil. Así se hizo con cada una de las características. Después fue sumada la cantidad en cada uno de los grupos, y fue hallado el porciento que representa cada grupo sobre el total de características. Obteniendo como resultado que las agrupadas como ágiles representan el 33 % del total de las analizadas y las pesadas el 67 %. Luego, analizando los valores, se concluye que el equipo presenta poca libertad en el desarrollo del proyecto por lo que se ubica el valor 33 % en el eje, valor más cercano a la formalidad. 7
http://publicaciones.uci.cu/index.php/sc La Figura 2 muestra la representación de los criterios analizados en la Estrella de Boehm y Turner. La forma obtenida no sugiere con claridad la aplicación de un enfoque en específico, los vértices que representan los valores de Dinamismo y Tamaño, se ubican en Territorio ágil, pero aspectos como Personal y Cultura del equipo, apuntan a la utilización de un enfoque prescriptivo. La Criticidad se muestra en un área de incertidumbre donde la agilidad y el formalismo se encuentran balanceados. En resumen, la disposición de las aristas propone la hibridación de los enfoques, pero analizando el peso que tienen criterios como el Dinamismo, debido al elevado riesgo de requisitos cambiantes y el tamaño reducido de personas que involucra el desarrollo de un número considerable de funcionalidades, se propone adoptar un enfoque ágil. Figura 2. Estrella que representa el proyecto según la aplicación de Boehm y Turner. Entre las metodologías de desarrollo ágil más referenciadas se destacan: XP (Letelier y Penadés, 2006), Scrum (Palacio, 2007), FDD (Calabria, 2003) y Crystal (Chicaiza, 2007). Del estudio de estas metodologías, FDD resultó ser la propuesta que mejor se ajusta a las características del proyecto a ejecutar. A pesar de ser clasificada como una metodología ágil, es considerada por sus características una metodología, que está en el punto medio del enfoque ágil y prescriptivo (Amaro y Valverde, 2007). FDD engloba las características que se necesitan mantener en el proceso de 8
http://publicaciones.uci.cu/index.php/sc desarrollo a ejecutar. La selección de una metodología ágil como XP, muy usada en el mundo no se ajusta primero a las características del equipo de desarrollo y luego a la cantidad de documentación que se necesita generar para el proyecto. Por otro lado, una metodología pesada se iría al otro extremo. De utilizar la hibridación de dos metodologías, se está queriendo resolver el problema con la selección de prácticas en diferentes metodologías que podían encontrarse de manera absoluta en la metodología FDD. FDD. Prácticas La metodología FDD está pensada para proyectos con tiempo de desarrollo relativamente cortos. Se basa en un proceso iterativo, con iteraciones cortas que produce un software funcional que el cliente y la dirección de la empresa pueden ver y monitorizar. Las iteraciones se deciden de acuerdo a las funcionalidades o rasgos (Molpeceres, 2003). Estas iteraciones cortas o resultados a corto plazo posibilitarán entregas al cliente en tiempos cortos, lo que permitirá dar cumplimiento a los diferentes hitos registrados como parte del contrato en el que está enmarcado el proyecto. Se concibió para equipos de trabajo pequeños al igual que XP. Basa la obtención de requisitos en la elaboración de una lista de funcionalidades y no en la descripción detallada de casos de uso o historias de usuarios como en RUP y XP respectivamente. La definición de requisitos como lo propone FDD puede ser un elemento favorable cuando hay presencia de requisitos cambiantes o dinámicos. Posibilita al equipo de desarrollo, trabajar con ellos de la manera más conveniente y en caso de cambios no se afectarían ni las historias de usuarios, ni las descripciones de casos de usos. La metodología XP propone no colocar demasiada carga de trabajo (tareas organizativas) sobre los desarrolladores. RUP es un proceso pesado en este sentido, ya que el desarrollador debe documentar su trabajo. Y FDD sin embargo, está en nivel medio, en el sentido de que genera más documentación que XP pero menos que RUP, documenta solo lo que posibilite la integración de desarrolladores fácilmente al proyecto. Esta práctica de FDD es conveniente para el proyecto, pues la inclusión de nuevos desarrolladores no es una idea descartada; además, puede servir de base para la generación de la documentación definida como entregable al cliente, elemento necesario para el cumplimiento de lo pactado en el contrato. RUP para las relaciones con el cliente propone presentar artefactos al final de cada fase, pero para el aseguramiento XP y FDD se basan en controles propios y una comunicación fluida con el cliente. La comunicación frecuente con el cliente será importante debido a que durante el desarrollo los especialistas funcionales pondrán ir validando los release obtenidos de cada una de las iteraciones. Para el conocimiento de la arquitectura, RUP intenta reducir la complejidad del software a producir a través de una planificación intensiva; XP lo hace a través de la programación a pares ya en la creación del código se pueden evitar 9
http://publicaciones.uci.cu/index.php/sc errores y malos diseños; y FDD usa las sesiones de trabajo conjuntas en la fase de diseño para conseguir una arquitectura sencilla y sin errores. La característica de esta última, unida a la decisión de contar con desarrolladores líderes (jefe de desarrollo, arquitecto) dentro del grupo, permite que el conocimiento fluya en el equipo, elemento importante a fomentar teniendo en cuenta experiencia del grupo de trabajo. FDD divide los roles en tres categorías: Roles claves, Roles de soporte y Roles adicionales. (Amaro y Valverde, 2007). En la siguiente Tabla se relacionan los roles que desempeñan los miembros del equipo. En una columna se muestra el rol principal que desarrolla y en la otra se ubican otros que en alguna fase del proyecto podrían estar realizando: Tabla 1. Roles que desempeñan los miembros del equipo. Rol principal Otro incorporado Jefe de proyecto (Project Manager). Ingeniero desarrollador (Build Engineer) Jefe de desarrollo (Development Manager) Jefe de programadores (Chief Programmer) Jefe de versiones (Realese Manager) Ingeniero desarrollador (Build Engineer) Desarrollador (Deployer) Arquitecto principal (Chief Architect) Toolsmith Desarrollador (Deployer) Administrador de sistema (System Administrator) Toolsmith Desarrollador (Deployer) Responsables de clases (Class Owner) Desarrollador (Deployer) Expertos del dominio Jefe de dominio (Domain Manager) Analista Documentador (Technical Writer) Especialista de transformación Probador (Tester) organizacional Ingeniero desarrollador (Build Engineer) Conclusiones El análisis de las condiciones bajo las cuales cada enfoque o metodología tiene mayor probabilidad de éxito, tiene como punto de partida las circunstancias y características del entorno en el que se pretende aplicar. El método de Boehm y Turner constituye una herramienta útil para la valoración de dicho entorno, basado en 5 criterios que permiten diagnosticar cuan ágil o prescriptivo debe ser el proceso de desarrollo a seguir. 10
http://publicaciones.uci.cu/index.php/sc En el caso de estudio analizado, la forma de la figura obtenida como resultado de la ubicación de criterios en la Estrella de Boehm y Turner, no sugiere con claridad la aplicación de un enfoque en específico sino la hibridación de estos. De los 5 criterios analizados, 2 se ubican en territorio ágil, 2 en territorio prescriptivo u orientado al plan y uno se muestra en un área de incertidumbre donde la agilidad y el formalismo se encuentran balanceados. Valorando el peso que tienen para la administración del proyecto de desarrollo de software factores como el Dinamismo, debido al elevado riesgo de requisitos cambiantes en todas las etapas del proceso y el Tamaño reducidos de personas que involucra el desarrollo de un número considerable de funcionalidades, se ha decidido adoptar un enfoque ágil como método base y manejar los riesgos ocasionados por los factores que no están concebidos bajo este enfoque. Para ello, se ha seleccionado como metodología de desarrollo FDD que pesar de ser clasificada como una metodología ágil, es considerada punto medio entre RUP y XP, lo cual favorece considerablemente, la hibridación de enfoques que propone el resultado de la aplicación del método de Boehm y Turner para el proyecto. Referencias AMARO CALDERÓN, SARAH DÁMARIS y VALVERDE REBAZA, JORGE CARLOS. Metodologías Ágiles. 2007. BECK, KENT; BEEDLE, MIKE; BENNEKUM, ARIE VAN; et al., Manifiesto Ágil. 2001. [Consultado el: 20 de febrero de 2012]. Disponible en: [http://www.agilemanifesto.org/iso/es]. CALABRIA, LUIS. Metodología FDD. 2003. CENTELLA HINOJOSA, MILCA. Resumen comparativo entre las metodologías pesadas vs ligeras, Bolivia. 2012. CHICAIZA AYALA, ALEXANDRA PATRICIA. Desarrollo de software de nómina de empleados utilizando la Metodología Crystal, Ingeniería en Sistemas e Informática, Sangolquí. 2007. COCKBURN A. Just-In-Time Methodology Construction. 2000. GABARDINI, JUAN y CAMPOS, LUCAS. Balanceo de Metodologías Orientadas al Plan y Ágiles. Herramientas para la Selección y Adaptación. En: PMI Global Congress Proceedings. Buenos Aires, Argentina. 2004. GÓMEZ, ADRIANA, LÓPEZ, MARÍA DEL C., Migani Silvina, Otazú Alejandra. Un modelo de estimación de proyectos de software. 2009. IEEE. Ingeniería de Software, Pressman capítulos [1-9] 2002 [Consultado el: 20 de febrero de 2012]. Disponible en: [http://es.scribd.com/doc/32166526/ingenieria-de-software-pressman-capitulos-1-9]. 11
http://publicaciones.uci.cu/index.php/sc LETELIER, PATRICIO y PENADÉS, Mª CARMEN. Metodologías ágiles para el desarrollo de software: extreme Programming (XP). 2006. MOLPECERES, ALBERTO. Procesos de desarrollo: RUP, XP, FDD. 2003. [Consultado: 24 de febrero de 2012]. Disponible en: [www.willydev.net/descargas/articulos/general/cualxpfddrup.pdf]. PALACIO, JUAN. Flexibilidad con Scrum. Principios de diseño e implantación de campos de Scrum. 2007. PRESSMAN, ROGER. Ingeniería del Software: Un Enfoque Práctico (Sexta Edición). McGraw-Hill. 2005. P 900. TONOCO GÓMEZ, OSCAR; ROSALES LÓPEZ, PEDRO PABLO y SALAS BACALLA, JULIO. Criterios de selección de metodologías de desarrollo de software. 2010. 12