Research article

Propuesta de aplicación de SCRUM para gestionar el proceso de mantenimiento del software: estudio preliminar

Resumen

El mantenimiento del software es parte integral del ciclo de vida. El objetivo es conservar al software operativo el mayor tiempo posible, haciendo rendir al máximo la inversión de las organizaciones. Se presenta un estudio preliminar con el objeto de aportar consideraciones teóricas, que sustenten la aplicación de SCRUM, una metodología ágil, en proyectos de mantenimiento de software. El trabajo se fundamenta en abordar la aplicación de las prácticas SCRUM en las actividades propuestas por el estándar IEEE 1219 para el mantenimiento de software, dado que éste explicita qué hacer, sin dar cuenta del cómo.

Proposed implementation of SCRUM for managing the software maintenance process: a preliminary study

Abstract

Software maintenance is an integral part of the life cycle. The goal is to keep operating software as long as possible, making the most of the investment yield of organizations. The paper presents a preliminary study in order to provide theoretical considerations that support the implementation of SCRUM, an agile methodology, in software maintenance projects. The work is based on addressing the management activities proposed by IEEE, since this standard explicit what to do, without accounting for the how.

Introducción

La Red Universidades Nacionales de Carreras Informáticas, identificada como RedUNCI (2006) menciona que la informática se compone de nueve disciplinas siendo una de ellas la Ingeniería del Software (IS).

Sommerville (2005) expone que la IS es una disciplina de la ingeniería que comprende  los aspectos de la producción de software desde las etapas iniciales de la especificación del sistema, hasta el mantenimiento de éste después de su implementación.

El ciclo de vida del software se puede definir como “un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso” (ISO/IEC 12207, 1995). Tal es la importancia asignada al mantenimiento, que lo ubica como uno de sus procesos principales.

Se considera al mantenimiento del software (MS) como “la modificación de un producto software después de la entrega para corregir fallos, para mejorar el rendimiento u otros atributos, o para adaptar el producto a un entorno modificado” (IEEE STD 1219, 1993). Esta definición indica que las actividades de mantenimiento comienzan después que el producto está en funcionamiento. En ocasiones se considera que algunas actividades pueden comenzar antes de la entrega del producto.

Además, históricamente careció del mismo grado de atención, en comparación con otras fases del proceso como es el desarrollo, a pesar de ser parte integral del ciclo de vida (Swebok, 2004). Lo expuesto está cambiando en las organizaciones ya que éstas se esfuerzan por hacer rendir al máximo la inversión, tratando de conservar al software operativo el mayor tiempo.

INTECO (2009) define una metodología de desarrollo de un producto software como un conjunto integrado de técnicas y métodos que permite abordar de forma homogénea y abierta cada una de las actividades del ciclo de vida de un proyecto de desarrollo. Además, de gestionar y administrar de manera sistemática, indica los procesos a seguir para idear, implementar y mantenerlo, desde que surge la necesidad hasta cumplir el objetivo por el cual fue creado.

Las metodologías tradicionales de desarrollo de software llevan asociadas un marcado énfasis en el control del proceso mediante una rigurosa definición de roles, actividades y artefactos, incluyendo modelado y documentación detallada, y han demostrado ser efectivas y necesarias en proyectos de gran tamaño. Las metodologías ágiles emergen como una posible respuesta ante éste escenario por estar especialmente orientadas a proyectos pequeños y constituyen una solución a medida para esos entornos, aportando una elevada simplificación, sin renunciar a las prácticas esenciales para asegurar la calidad del producto (Canós et al., 2003). La adecuada selección de la metodología para un determinado proyecto es trascendental para el éxito del mismo.

Alguna de las metodologías ágiles más reconocidas son: i) Adaptive Software Development (ASD); ii) Crystal; iii) Feature Driven Development (FDD); iv) Dynamic Systems Development Method (DSDM); v) Lean Software Development; vi) SCRUM; vii) eXtreme Programming (XP).

• La revisión bibliográfica permitió detectar, en coincidencia con Rodríguez González (2008), que aunque la mayor parte del desarrollo de software, se dedica a mantenerlo, pocos estudios se orientaron a la evolución y su permanencia utilizando metodologías ágiles y a la obtención de datos empíricos que apoyen la utilización eficaz de las mismas  en la aplicación a este proceso.
• Un estudio presentado en Chapin (2004), examinó como los procesos de agilidad aplicados en la evolución del software, contribuyen en forma favorable ó desfavorable a los diferentes tipos de perfiles que intervienen: usuarios, clientes y personal de sistemas de información.
• En Capiluppi et al. (2007), se abordó la medición de la evolución de un sistema mediante Programación Extrema (Extreme Programming o XP). El trabajo proporcionó pruebas concluyentes de que ésta metodología, permite disminuir los problemas de complejidad del código y aumentar la satisfacción del cliente, al recibir rápidamente la funcionalidad requerida.   
• En Poole y Huisman (2001) y Poole et al. (2001), citados en Rico (2008), se presentaron los resultados obtenidos al utilizar XP para el mantenimiento de software, en lugar del método tradicional basado en cascada.

A partir de la investigación bibliográfica revelada, este estudio preliminar pretende aportar información, con miras a apoyar la idea de que las prácticas del desarrollo ágil pueden ser aplicables a proyectos de mantenimiento de software, en particular SCRUM. Esta propuesta, se fundamenta en que SCRUM brindaría soporte para los procesos descriptos por el estándar IEEE 1219 (IEEE STD 1219, 1993), indicando “cómo” llevar a cabo las actividades, puesto  que explicita “qué” hacer, sin dar cuenta del “cómo”.

El artículo está organizado como sigue. En la sección 2 se describe la metodología utilizada en la elaboración de este trabajo. La sección 3 introduce en el mantenimiento del software. La sección 4 se centra en las metodologías ágiles y en SCRUM, presentando sus características, el proceso y las prácticas propuestas. La sección 5 describe la propuesta que permite a prori la gestión y control del proceso del mantenimiento del software, detallándose sus principales características. Finalmente se exponen las conclusiones y futuras líneas de trabajo.

Metodología de trabajo

La metodología aplicada en este trabajo se basó en las siguientes etapas:

• Revisión de bibliografía sobre experiencias concretas y antecedentes de mantenimiento del software.
• Recopilación, selección, estudio de metodologías ágiles y su aplicación al proceso de mantenimiento.
• Elaboración de una propuesta que sustente la aplicación de las prácticas de SCRUM en proyectos de mantenimiento de software. Se sugiere abordar las actividades mencionadas por el estándar IEEE 1219, dado que este explicita “qué” hacer, sin dar cuenta del “cómo”.

Mantenimiento de software

Los sistemas desarrollados, inevitablemente sufren cambios para su permanencia y utilidad. Una vez que el software comienza a emplearse, surgen nuevos requisitos y los existentes cambian. Algunas partes del mismo tienen que modificarse para corregir errores detectados en su funcionamiento, adaptarlo a una nueva plataforma, mejorar su rendimiento, entre otras características no funcionales. El proceso de desarrollo no se detiene cuando un sistema es entregado, sino que continúa a lo largo del tiempo de vida del mismo (Sommerville, 2005). Tan larga es la vida útil del software, que es uno de los motivos por lo cual es muy alto el costo del mantenimiento.

Para Piattini y García (2003), los motivos de costos altos se deben a que la mayoría de las organizaciones, aunque utilizan alguna metodología para ejecutar sus nuevos desarrollos, afirman no seguir ninguna para gestionar el proceso de mantenimiento. Los departamentos informáticos están orientados al control del proceso de los nuevos desarrollos, pero el mayor porcentaje del trabajo que realizan es de mantenimiento. Siguiendo a Piattini y García (2003) se puede considerar reducir este costo, si se dispone de una metodología para gestionarlo.

Tal lo planteado anteriormente existen diferentes factores que inciden en la ejecución de esta actividad, para lo cual Métrica versión 3 (Métrica V.3., 2000), establece los siguientes tipos de mantenimiento:

• Correctivo: cambios precisos para corregir errores del producto software.
• Evolutivo: incorporaciones, modificaciones y eliminaciones necesarias en un producto software para cubrir la expansión o cambio en las necesidades del usuario.
• Adaptativo: modificaciones que afectan a los entornos en los que el sistema opera.
• Perfectivo: acciones llevadas a cabo para mejorar la calidad interna de los sistemas en cualquiera de sus aspectos.

El proceso de mantenimiento, proporciona las acciones necesarias y detalladas de las entradas y salidas a esas actividades, las que se describen en las normas de mantenimiento de software IEEE 1219 e ISO/IEC 14764 (SWEBOK, 2004).

IEEE STD 1219 (1993) define cambios en un producto de software a través de un proceso dividido en fases. Éste es iterativo y en cascada, con una gran semejanza al ciclo de vida del desarrollo clásico. Las fases se detallan a lo largo del estándar, indicando en cada una los elementos de los que se dispone al empezar, por ejemplo la documentación, las tareas ha realizar, la manera de seguir fielmente los estándares, y por último el resultado de la misma (documentación generada, código, entre otras). Se distinguen las siguientes: i) identificación y clasificación del problema o de la modificación; ii) análisis, iii) diseño, iv) implementación, v) pruebas del sistema, vi) pruebas de aceptación, vii) liberación del producto.

Metodologías ágiles

En febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace el término “ágil” aplicado al desarrollo de software. De la misma participaron un grupo de 17 expertos de esta industria, incluyendo algunos de los creadores o impulsores de éstas metodologías. Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar software rápidamente y responder a los cambios que puedan surgir a lo largo del proyecto.

Se pretendió ofrecer una alternativa a los procesos de desarrollos tradicionales, caracterizados por ser rígidos y dirigidos por la documentación generada en cada una de las actividades abordadas.

Tras esta reunión se creó “La Alianza Ágil”, una organización, sin fines de lucro, dedicada a promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las organizaciones para que adopten dichos conceptos. El punto de partida fue el “Manifiesto Ágil”, un documento que resume la filosofía de este tipo de metodología (Letelier y Penadés, 2006).

El Manifiesto por el Desarrollo Ágil de Software (2001), enumera los principales valores del desarrollo ágil:

• Individuos e interacciones sobre procesos y herramientas.
• Software funcionando sobre documentación extensiva.
• Colaboración con el cliente sobre negociación contractual.
• Respuesta a los cambios más que seguir estrictamente un plan.
• Estos valores anteriores inspiran los doce Principios del Manifiesto Ágil (2001), características que diferencian un proceso ágil de uno tradicional.

En Palacio y Ruata (2011) se mencionan algunas como son: i) Agile Database Techniques (AD); ii) Agile Modeling (AM); iii) Adaptive Software Development (ASD); iv) Agile Unified Process (AUP); v) Crystal; vi) Feature Driven Development (FDD); vii) Dynamic Systems Development Method (DSDM); viii) Lean Software Development; ix) SCRUM; x) Test Driven Design (TDD); xi) eXtreme Programming (XP). Los métodos AD, AM o XP cubren áreas concretas de la ingeniería del software (diseño, desarrollo,  pruebas) y otras se centran en la gestión del proyecto: i) Adaptive Software Development (ASD); ii) Agile Unified Process (AUP); iii) Crystal; iv) Dynamic Systems Development Method (DSDM) y  v) SCRUM.

SCRUM

En 1993, Jeff Sutherland aplicó el modelo SCRUM al desarrollo de software en Easel Corporation (Empresa que en los macro juegos de compras y fusiones se integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 presentó, junto con Ken Schwaber, las prácticas que empleaba como proceso formal, para gestión del desarrollo de software en OOPSLA 96 (Schwaber y Sutherland: 1996). En 2001 formaron parte de los firmantes del Manifiesto Ágil. Las prácticas diseñadas por Schwaber y Sutherland para gestionar el desarrollo de software están incluidas en la lista de modelos ágiles de Agile Alliance (Palacio y Ruata: 2011).

Siguiendo lo expuesto en Schwaber (1995) se mencionan algunas implementaciones de SCRUM.

Diversas variantes del enfoque SCRUM para el desarrollo de nuevos productos con equipos pequeños de alto rendimiento, fue observada por primera vez por Takeuchi y Nonaka (1986) en el Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox y Hewlett-Packard. Un enfoque similar aplicado al desarrollo de software en Borland lo indicó Coplien (1994). Además, un enfoque refinado para este proceso lo aplicó Sutherland (1996) al desarrollo en Smalltalk y Schwaber (1996) a la producción en Delphi.

SCRUM es utilizado por empresas grandes y pequeñas, incluyendo Yahoo, Microsoft, Google, Lockheed Martin, Motorola, SAP, Cisco, GE, CapitalOne y la Reserva Federal de los EE.UU (Deemer et al., 2010).

Díaz (2009) define a SCRUM, como una colección de procesos para la gestión de proyectos, que permite centrarse en la entrega de valor para el cliente y la potenciación del equipo para lograr su máxima eficiencia, dentro de un esquema de mejora continua.

Como método ágil:

• Es un modo de desarrollo adaptable, antes que predictivo.
• Orientado a las personas, más que a los procesos.
• Emplea el modelo de construcción incremental basado en iteraciones y revisiones.
• En Canós et al. (2003) se resumen las principales características de SCRUM:
• Especialmente indicada para proyectos con un rápido cambio de requisitos.
• El desarrollo de software se realiza mediante iteraciones, denominadas Sprints, con una duración de 30 días. El resultado de cada Sprint es un incremento ejecutable que se muestra al cliente.
• La realización de reuniones a lo largo del proyecto, entre ellas se destaca la diaria del equipo de desarrollo, con una duración aproximada de 15 minutos y con miras a la coordinación e integración de actividades.

SCRUM propone las siguientes tres fases (Méndez Calo et al., 2010):

• Fase de Planificación:
  • Planeación: se define el equipo, herramientas, el sistema de desarrollo y se crea el product backlog con la lista de requerimientos conocidos junto con sus prioridades y se estima el esfuerzo necesario para llevarlo a cabo.
  • Diseño Arquitectónico: se define la arquitectura del producto que permita implementar los requerimientos.
• Fase de Desarrollo: es la parte ágil, donde el sistema se desarrolla en Sprints.
• Fase de Finalización: incluye integración, testing y documentación. Indica la implementación de todos los requerimientos, quedando el product backlog vacío.

Los roles, artefactos y eventos principales se resumen en la  Figura 1.

Figura 1. Roles, artefactos y eventos principales de SCRUM (Fuente: Deemer et al., 2009)

Propuesta preliminar de aplicación de SCRUM

Siguiendo a Piattini y García (2003) se puede considerar la reducción del costo del mantenimiento del software si se dispone de una metodología para gestionarlo. Por lo tanto, se seleccionó SCRUM para gestionar el proceso descripto por el estándar IEEE 1219 (IEEE STD 1219, 1993), teniendo en cuenta que las prácticas de ésta metodología han sido aplicadas con éxito en varios proyectos mencionados anteriormente.

En la Tabla 1, se expone las fases y actividades asociadas, explicitadas por el estándar IEEE 1219 y la correspondencia propuesta con las fases de SCRUM. A partir de allí, es posible derivar la integración de SCRUM en el manteniendo de software. Específicamente se asocia a cada fase de SCRUM las correspondientes actividades del estándar IEEE 1219.

La Figura 2 muestra la mejora propuesta elaborada a partir de la gráfica referente a roles, artefactos y eventos principales de SCRUM expuesta en Deemer et al. (2009). Se ilustran las fases de SCRUM y las correspondientes del estándar IEEE 1219 a implementar en cada una de ellas.

A continuación se describe una visión general del proceso de mantenimiento y se enuncian las prácticas de SCRUM, que sustentan a priori la incorporación de las actividades propuestas por el estándar IEEE 1219.

Al inicio del proyecto (fase de planificación), se define el equipo de trabajo. Se reciben las solicitudes de modificación del producto software, que son plasmadas y priorizadas en las pilas de productos o Product Backlog y en función a los requerimientos del cliente se seleccionan las peticiones de modificación a incluir en el Sprint. Además, se establece la viabilidad de la solicitud, el impacto que pueda producir, los problemas que puedan causar y se evalúa el esfuerzo necesario para llevar a cabo las modificaciones, por medio de la estimación de las pruebas de Póker ó Fibonacci y se preparan los contenidos de las nuevas versiones. El alcance de las modificaciones, se determina a través de la pila de productos a modificar.

Se definen además, los siguientes roles: i) Cliente: es el propietario del producto; ii) Equipo de desarrollo: quien implementa la solicitud de modificación del software; iii) Responsable de Mantenimiento (ScrumMaster): se encarga de ordenar la pila de productos ó solicitud de modificación, asignando prioridad a la petición, actúa de intermediario entre el cliente y el equipo y verifica que se cumplen los valores y principios de SCRUM. También forma parte del equipo de desarrollo.

Durante el Sprint (fase de desarrollo) se realizan una serie de reuniones diarias, con el fin de gestionar el riesgo de forma continua en cada iteración y solucionar posibles problemas que puedan impedir su normal avance. Al terminar una petición, se realiza una reunión de revisión, para validar y verificar el producto con el cliente y reuniones de retrospectiva, con la finalidad de aprender de los conocimientos y experiencias adquiridas hasta el momento. Se aplican  los cambios y ajustes si son necesarios, y se marcan los aspectos positivos y negativos, que servirán de realimentación para el siguiente Sprint. El Sprint como iteración abordaría las siguientes fases propuestas por el estándar IEEE 1219: i) diseño, ii) implementación, iii) pruebas del sistema.

Dependiendo del tipo de mantenimiento, la duración del Sprint será de 1, 2 ó 4 semanas. Esto es una decisión del equipo y seguirá siempre las actividades y fases establecidas  en la Tabla 1.

Al finalizar el proceso de mantenimiento, es decir, cuando la lista de peticiones de modificación se encuentra vacía, se pasa a la fase de finalización, realizando las actividades descriptas en la Tabla 1.

Figura 2. Roles, artefactos y eventos principales de SCRUM (Fuente: Deemer et al., 2009), adaptada a la propuesta expuesta

Conclusión y trabajos futuros

En los últimos años, la comunidad de la ingeniería del software mostró un creciente interés en metodologías de desarrollo ágil. Estos enfoques surgieron como respuesta a la necesidad de procesos más rápidos, flexibles y eficientes para el desarrollo de software.

Aún cuando SCRUM, se creó para ser aplicado a proyectos de desarrollo de software, en este trabajo se abordó un estudio preliminar, qué propone implementar SCRUM en el proceso de mantenimiento. Se establecieron de qué forma las prácticas de ésta abarcarían las actividades propuestas por el estándar IEEE 1219. Por lo tanto, a prori es posible su aplicación para actividades de mantenimiento.

Esta propuesta permitirá:

i) agilizar el proceso de mantenimiento, a través de las entregas frecuentes;

ii) comprender mejor el producto software a mantener, mediante la colaboración y comunicación en el equipo de mantenimiento;

iii) flexibilizar los requerimientos de modificación, con la incorporación de nuevas solicitudes y la asignación de nuevas prioridades;

iv) disminuir los costos asociados a este tipo de proceso.

A partir de lo expuesto, se propone profundizar en esta línea de investigación y aportar a la calidad del mantenimiento de software utilizando metodologías ágiles.

En líneas futuras se detallarán algunas experiencias de la efectivización concreta de la propuesta en empresas u organizaciones con fines de testear la misma y obtener datos empíricos que la sustenten.

Referencias

Canós, J., Letelier P. y Penadés M. (2003). Metodologías Ágiles en el Desarrollo de Software. Universidad Politécnica de Valencia. Consulta: 15 de agosto del 2010. Disponible en: http://www.willydev.net/descargas/prev/TodoAgil.pdf.

Capiluppi, A., Fernandez Ramil, J., Higman, J., Sharp, H. y Smith, N. (2007). An Empirical Study of the Evolution of an Agile-Developed Software System. 29th International Conference on Software Engineering, 20-26 May 2007, Minneapolis, USA. Consulta: 16 de agosto del 2010. Disponible en: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.103.1959&rep=rep1&type=pdf

Coplien, J. (1994). Borland Software Craftsmanship: A New Look at Process, Quality and Productivity. Proceedings of the 5th Annual Borland International Conference, June 5, 1994. Orlando, Florida.

Chapin, N. (2004). Agile Methods' Contributions in Software Evolution., 20th IEEE International Conference on Software Maintenance (ICSM'04), pp.522, 2004. Consulta: 15 de agosto del 2010. Disponible en: http://www.computer.org/portal/web/csdl/doi/10.1109/ICSM.2004.1357864.

Deemer, P., Benefield, G., Larman, C. y Vodde, B. (2010). The Scrum Primer. Version 1.12. Scrum Training Institute, 2010. Consulta: 20 de enero del 2011. Disponible en: http://assets.scrumtraininginstitute.com/downloads/1/scrumprimer121.pdf.

Deemer, P., Benefield, G., Larman, C. y Vodde, B. (2009). Información Básica de Scrum the Scrum Primer Version 1.1. Scrum Training Institute. Traducción de Leo Antoli. Agile-Spain. Consulta: 30 de mayo del 2011. Disponible en: http://www.goodagile.com/scrumprimer/scrumprimer_es.pdf.

Díaz, R. (2009). Las metodologías ágiles como garantía de calidad del software. Revista Española de Innovación, Calidad e Ingeniería del software, Vol.5, Nº 3, 2009.

IEEE STD 1219:1993. Standard for Software Maintenance. IEEE Computer Society Press. USA, 1993.

INTECO. (2009). Instituto Nacional de Tecnologías de la Comunicación. Ingeniería del software: metodologías y ciclos de vida. Consulta: 15 de enero del 2011. Disponible en: http://www.inteco.es/calidad_TIC/descargas/guias/guia_de_ingenieria_del_software.

ISO/IEC 12207:1995. Information Technology - Software life cycle processes.

Letelier P. y Penadés M. (2006). Metodologías ágiles para el desarrollo de software: eXtreme Programming (XP).  Revista Técnica Administrativa. Vol.5, Nº 26. Consulta: 31 de agosto del 2011. Disponible en: http://www.cyta.com.ar/ta0502/v5n2a1.htm

Manifiesto por el desarrollo ágil de software. (2001). Consulta: 10 de marzo del 2010. Disponible en: http://agilemanifesto.org/iso/es/.

Méndez Calo, K., Estevez, E. y Fillottrani, P. (2010). A Quantitative Framework for the Evaluation of Agile Methodologies. Consulta: 20 de enero del 2011. Disponible en: http://journal.info.unlp.edu.ar/journal/journal28/papers/JCST-Jun10-4.pdf.

Métrica V.3. (2000). Metodología de Planificación, Desarrollo y Mantenimiento de Sistemas de Información. Ministerio de Administración Pública de España. Consulta: 20 de febrero del 2010. Disponible en:

http://administracionelectronica.gob.es/?_nfpb=true&_pageLabel=P60085901274201580632&langPae=es.

Palacio, J. y Ruata, C. (2011). Scrum Manager Proyectos, Rev.1.4.0. Consulta:  26 de mayo del 2011. Disponible en: http://www.scrummanager.net/files/sm_proyecto.pdf.

Piattini, V. y García, R., (2003). Calidad en el desarrollo y mantenimiento del software. Ed. Alfaomega.

Principios del manifiesto ágil. (2001). Consulta: 15 de octubre del 2010. Disponible en: http://agilemanifesto.org/iso/es/principles.html.

REDUNCI (2006). Carreras de Grado en Informática. Propuesta de Currícula. Consulta: Consulta: 2 de agosto del 2011. Disponible en: http://redunci.info.unlp.edu.ar/docs/propuesta.doc.

Rico, D. (2008). Agile Methods and Software Maintenance. Consulta: 10 de agosto del 2010. Disponible en: http://davidfrico.com/rico08f.pdf.

Rodríguez González, P. (2008). Estudio de la aplicación de metodologías ágiles para la evolución de productos software. Tesis de Máster. Facultad de Informática, Universidad Politécnica de Madrid.

Schwaber, K. (1996). Controlled Chaos: Living on the Edge American Programmer, April 1996.

Schwaber, K. (1995). Scrum Development Process, in OOPSLA Business Object Design and Implementation Workshop, J. Sutherland, D. Patel, C. Casanave, J. Miller, and G. Hollowell, Eds. London: Springer, 1995.

Sommerville, I. (2005). Ingeniería del Software. 7ª Edición. Ed. Pearson.

Sutherland, J. (1996). ScrumWeb Home Page: A Guide to the SCRUM Development Process Jeff Sutherland’s Object Technology Web Page, 1996.

Takeuchi, H. y Nonaka, I. (1986). The New New Product Development Game. Harvard Business Review, 1986 Jan.

Swebok. (2004). Guide to the Software Engineering Body of Knowledge. Consulta: 15 de agosto del 2010. Disponible en: http://www.computer.org/portal/web/swebok.

Técnica Administrativa
ISSN 1666-1680

http://www.cyta.com.ar -

Vol.:11
Nro.:01
Buenos Aires, 15-01-2012

URL http://www.cyta.com.ar/ta1101/v11n1a4.htm