Documentos de Académico
Documentos de Profesional
Documentos de Cultura
UTN - FRC
12/08/2010
Director:
Diego Rubio
Maestrando:
Versin: 1.0.1
HISTORIAL DE CAMBIOS
Versin
Fecha
1.0.0_Draft_A
01-Abril2010
28-Abril2010
30-Mayo2010
11-Junio2010
05-Agosto2010
12-Agosto2010
1.0.0_Draft_B
1.0.0_Draft_C
1.0.0
1.0.1_Draft_A
1.0.1
Descripcin
Versin inicial.
Cambios en referencias y
fundamentacin
Cambios en la descripcin de los
objetivos y fundamentacin
A lnea base despus de revisin con
el Director
Cambios realizados a partir de la
revisin del comit
A lnea base
Pgina 2 de 16
Preparado por
Juan Pablo
Bruno
Juan Pablo
Bruno
Juan Pablo
Bruno
Juan Pablo
Bruno
Juan Pablo
Bruno
Juan Pablo
Bruno
versin 1.0.1
Versin: 1.0.1
TABLA DE CONTENIDOS
Historial de Cambios ........................................................................................................... 2
Tabla de Contenidos ........................................................................................................... 3
Tabla de Figuras y Cuadros ................................................................................................ 3
Justificacin del tema elegido .............................................................................................. 4
Fundamentacin del tema elegido..................................................................................... 11
Objetivos del trabajo de tesis............................................................................................. 12
Metodologa de desarrollo ................................................................................................. 13
Cronograma del plan de trabajo de tesis ........................................................................... 14
Bibliografia ......................................................................................................................... 15
Pgina 3 de 16
versin 1.0.1
Versin: 1.0.1
No Realizado
Significa que una o ms de las metas especficas del rea de proceso no se satisfacen. No
existen metas genricas para este nivel porque no hay razones para institucionalizar un
proceso parcialmente implementado.
-
Realizado
Es un proceso que satisface las metas especficas del rea de proceso. Las mejoras
alcanzadas se pueden perder con el tiempo si no se institucionalizan. Ayuda y permite que se
lleve a cabo el trabajo necesario para realizar productos.
-
Administrado
Trabajo de exploracin realizado como parte del proyecto de investigacin Desarrollo y transferencia de
conocimientos tericos y prcticos para la implementacin del modelo CMMI en empresas de software con
cdigo EIPRCO779 realizado dentro del marco de la Secretara de Ciencia y Tcnica de la UTN - FRC
Autor: Bruno, Juan Pablo
Pgina 4 de 16
versin 1.0.1
Versin: 1.0.1
Es un proceso Realizado (Nivel de Capacidad 1) que tiene una estructura bsica para
soportar el proceso. Es un proceso planeado y ejecutado de acuerdo a una poltica
predefinida, que posee personal capacitado que cuenta con los recursos para controlar las
salidas y para monitorear, controlar y revisar el proceso. Las disciplinas que se establecen en
este nivel ayudan a asegurar que las prcticas se van a mantener en momentos de stress.
-
Definido
Cuantitativamente Administrado
Optimizado
Pgina 5 de 16
versin 1.0.1
Versin: 1.0.1
A partir del conocimiento de este tipo de causas, una vez identificadas, se puede
proceder a extraer de una muestra el ruido (causas especiales) para su posterior anlisis
de causa [6 pg. 508]. Una vez extradas las causas especiales de variacin, utilizando
las cartas de control podremos determinar si el proceso es estable.
La importancia de la estabilidad estadstica de los procesos radica en que, citando a
W. E. Deming slo en el estado de control estadstico que la teora de estadstica provee,
con un alto nivel de confianza, prediccin de la performance en el futuro inmediato [5
pg. 20].
Para decirlo de otra manera, la estabilidad de procesos es crucial para lograr que una
organizacin ejecute sus procesos o produzca de acuerdo a lo planificado [7 pg. 71].
Un proceso es estable cuando sus caractersticas de posicin, dispersin y forma se
mantienen en el tiempo.
La ingeniera de software como tal, adopta el uso de herramientas estadsticas en
general, y la carta de control en particular, como una manera objetiva de planificar y
ejecutar mejoras sobre los procesos a partir de datos estadsticos.
El CMMI como modelo de madurez, define al control estadstico de procesos como
una prctica de alta madurez, y esto se ve reflejado que introduce su utilizacin a partir
del Nivel 4 de Madurez (Cuantitativamente Administrado).
c. Introduccin a Scrum
Debido al crecimiento de la importancia del Software, y para poder hacer frente a las
demandas en las que los mtodos tradicionales parecen no poder resolver, durante los
90 las metodologas giles surgen como marcos de trabajo con menor cantidad de
restricciones a la hora de lidiar con condiciones cada vez ms cambiantes [3]
El principal objetivo de estas metodologas giles es enfocarse en el concepto de
iteraciones cortas en las que al final de cada una, se espera que exista una nueva versin
de Software lista para entregarse. Esta nueva versin es, entonces, mostrado a los
interesados que a partir de la revisin del mismo, retroalimentan el equipo de desarrollo
con nuevos requerimientos o modificaciones a los requerimientos implementados.
Estas metodologas, parten del supuesto de que, los dueos del producto (clientes)
mantienen una lista de requerimientos de software priorizada de acuerdo al valor de
negocio que cada una de ellas provee. De esta lista, se toman los principales tems para
el desarrollo de cada iteracin. En definitiva, el foco se pone en los requerimientos que
mayor valor proveen al dueo del producto, y que al final de cada iteracin, el equipo de
desarrollo deber implementar de manera tal que la versin de software se convierta en
candidato a su entrega.
Scrum es uno de los marcos de trabajo bajo el paragua de estas metodologas giles.
Los resultados esperados de implementar Scrum como marco de desarrollo estn
relacionados con incrementar la productividad, calidad, satisfaccin de los clientes y de
los integrantes de los equipos de desarrollo acortando los plazos de entrega.[8]
Autor: Bruno, Juan Pablo
Pgina 6 de 16
versin 1.0.1
Versin: 1.0.1
Versin: 1.0.1
Pgina 8 de 16
versin 1.0.1
Versin: 1.0.1
Por otra parte, las prcticas giles, en particular Scrum ver Figura 2, surgen como
marco a ser utilizado cuando no es posible predecir todo lo que pueda llegar a ocurrir, ni
definir completamente desde un principio el producto que se pretende obtener, ofreciendo
prcticas que hacen visible todo lo que ocurre, y que a partir del concepto de las
iteraciones permite adaptar y ajustar mientras se avanza el progreso del proyecto de
desarrollo [9 pg. xvii].
La predictibilidad de Scrum, no est necesariamente alineada a la utilizacin de
mtodos estadsticos, si no a la gestin emprica [9 pg. 2] de procesos y a la serie de
herramientas que proporciona Scrum para hacer visible diariamente los riesgos de no
lograr lo comprometido y al final de cada iteracin el estado de avance del desarrollo del
producto [11 pgs. 108-110].
Se encuentra entonces una aparente disparidad de criterios entre lo propuesto en
modelos como CMMI y en metodologas como Scrum, donde en el primero (CMMI) se
menciona al control estadstico de procesos definidos, que permitan su repetitividad,
mientras que Scrum aflora como un nuevo paradigma (control emprico) tomando como
base que cada proyecto es diferente y no existen procesos realmente definidos, al nivel
de detalle adecuado para asegurar esa repetitividad. [11 pgs. 94-100].
Al ser enfoques aparentemente opuestos para el desarrollo de software, existe una
confrontacin de paradigmas entre aquellos que se identifican con uno de stos, sin lograr
apreciar que son totalmente compatibles [2 pg. 1], [19]. Sin embargo, ambos marcos de
trabajo reconocen la necesidad de coexistir [2 pgs. 20-26] [19]. De hecho, Scrum puede
definirse como uno de los procesos de desarrollo en una organizacin con un nivel 3 de
madurez segn el modelo CMMI [17 pg. 3] [11 pgs. 152-153], Es decir, un proceso
marco definido a nivel organizacional, a partir del cual los proyectos de desarrollo se
basan para su implementacin y ejecucin. Segn se logre avanzar a travs de los
niveles de madurez definidos por CMMI, existen reportes de experiencia donde se utilizan
mtricas derivadas de las actividades propias de metodologas giles y que contemplan
las nociones de agilidad incluidas en el Agile Manifesto incluyendo adems la teora del
Autor: Bruno, Juan Pablo
Pgina 9 de 16
versin 1.0.1
Versin: 1.0.1
control estadstico de procesos como una fuente de anlisis para la toma de decisiones a
partir de la variacin de estos procesos de desarrollo [20 pg. 12] [21 pgs. 2-3]. En
definitiva, podemos entonces comenzar a concluir, que la comprensin de ambos marcos
de trabajo (Scrum & CMMI) permite mejorar notablemente la performance de los procesos
de desarrollo. En este sentido, aprovechando las fortalezas de los procesos giles, se
utiliza a CMMI como fuente de institucionalizacin de los procesos claves [22 pg. 4]
Pgina 10 de 16
versin 1.0.1
Versin: 1.0.1
Proceso definido: Un proceso definido es un proceso administrado que es una adaptacin del conjunto de
procesos organizacionales de acuerdo a las guas de adaptacin existentes, descripto, y aporta subproductos, mtricas, y otra informacin de mejora de procesos a los artefactos del proceso organizacional.
[1]
Pgina 11 de 16
versin 1.0.1
Versin: 1.0.1
Pgina 12 de 16
versin 1.0.1
Versin: 1.0.1
METODOLOGA DE DESARROLLO
Para el desarrollo de este trabajo, se plantean las siguientes etapas:
Etapa 1.
(Exploracin): Anlisis de bibliografa existente referida a procesos
productivos en entornos giles, a modelos/normas y estndares de calidad y
mejora de procesos, Control estadstico de procesos.
Etapa 2.
(Anlisis): Anlisis de implementaciones actuales de prcticas de alta
madurez (segn modelo CMMI) en entornos de desarrollo basados en Scrum.
Etapa 3.
(Experimentacin): Desarrollo del proceso definido para la gestin
cuantitativa de proyectos en entornos de desarrollo utilizando Scrum. Diseo de la
herramienta que permita la automatizacin de la generacin de cartas de control a
partir de los datos obtenidos de la aplicacin de gestin de proyectos basados en
Scrum.
Etapa 4.
(Demostracin de Hiptesis): Plan para la ejecucin del proceso definido
en un proyecto piloto en su contexto real.
Etapa 5.
(Implementacin): Validacin del proceso definido propuesto, y definicin
de elementos para la posterior generacin de e-learning.
Etapa 6.
Conclusiones finales del trabajo.
Pgina 13 de 16
versin 1.0.1
Versin: 1.0.1
Pgina 14 de 16
versin 1.0.1
Versin: 1.0.1
BIBLIOGRAFIA
1. CMMI Product Team. CMMI for Development, version 1.2. Pittsburgh, Pennsylvania,
USA : Software Engineering Institute (SEI), August 2006. CMU/SEI-2006-TR-008.
2. Hillel Glazed, Jeff Dalton, David Anderson, Mike Konrad, Sandy Shrum. CMMI or
Agile, Why not Embrace Both. s.l. : Software Engineering Institute (SEI), Carnegie Mellon
University, 2008. CMU/SEI-2008-TN-003.
3. Agile Methods and CMMI: Compatibility or Conflict? Fritzsche Martin, Keil Patrick. 1,
s.l. : e-Informatica Software Engineering Journal, 2007, Vol. 1.
4. Mary Walton, W.Edwards Deming. Cmo Administrar con el Mtodo Deming. s.l. :
The Berkley Publishing Group, 1986. 0-399-55000-3.
5. William A. Florac, Robert E. Park, Anita D. Carleton. Practical Software
Measurement: Measuring the Process Management and Improvement. s.l. : Software
Engineering Institute, 1997. CMU/SEI-97-HB-003.
6. Humphrey, Watts S. A Discipline For Software Engineering. s.l. : Addison-Wesley
Publishing Company, Inc., 1997. 0-201-54610-8.
7. William A. Florac, Anita D. Carleton. Measuring The Software Process - Statistical
Process Control for Software Process Improvement. s.l. : Addison-Wesley, 1999. 0-20160444-2.
8. Cohn, Mike. Mountaing Goat Software. [Online] [Cited: 04 01, 2010.]
http://www.mountaingoatsoftware.com/scrum/figures.
9. Schwaber, Ken. Agile Project Management with Scrum. s.l. : Microsoft Press, 2004.
ISBN 0-7356-1993-X.
10. Mapping CMMI Project Management Process Areas to Scrum Practices. Marcal Ana
Sofia, Freitas Bruno Celso, Furtado Felipe, Belchior Arnaldo Dias. Baltimore, MD,
USA : IEEE, 31st IEEE Software Engineering Workshop (SEW 2007), 2007. 0-7695-28627.
11. Ken Schwaber, Mike Beedle. Agile Software Development with Scrum. s.l. : Prentice
Hall, 2001. ISBN 0-13-067634-9.
12. Software's Chronic Crisis, TRENDS IN COMPUTING. Gibbs, W. Wayt. s.l. : Scientyfic
American, September 1994.
http://www.cis.gsu.edu/~mmoore/CIS3300/handouts/SciAmSept1994.html.
13. Montogmery, Douglas C. Introduction to Statistical Quality Control. 4th. s.l. : John
Wiley & Sons Inc., 2001. 0-471-31648-2.
14. Wheeler, Donald J. Understanding Variation, The Key for Managing Chaos. s.l. : SPC
Press, 2000. 0-945320-53-1.
15. Standardization, International Organization for. ISO 9126-4:2004, Software
Engineering - Product Quality. s.l. : ISO, 2004. ICS 35.080.
16. . ISO 9001:2008, Quality Management System Requirements. s.l. : ISO, 2008. ICS
01.040.03.
17. An Approach for Using CMMI in Agile Software Development Assessments:
Experiences from Three Case Studies. Mntyniemi, Minna Pikkarainen - Annuka.
Luxemburgo : SPICE 2006 conference, 2006.
18. Diane L. Gibson, Dennis R. Goldenson, Keith Kost. Performance Results of CMMI Based Process Improvement. s.l. : Software Engineering Institute, 2006. CMU/SEI-2006TR004, ESC-TR-2006-004.
Autor: Bruno, Juan Pablo
Pgina 15 de 16
versin 1.0.1
Versin: 1.0.1
19. Shelton, Cindy. Scrum Alliance. Agile and CMMI: Better Together. [Online] Scrum
Alliance, 2008. [Cited: 04 01, 2010.] http://www.scrumalliance.org/articles/100-agile-andcmmi-better-together.
20. Stretching Agile to fit CMMI Level 3. Anderson, David J. Denver : Agile Conference
Denver 2005, 2005.
http:agilemanagement.net/index.php/site/comments/stretching_agile_to_fit_cmmi_level_3.
21. Scrum and CMMI - Going from Good to Great. Carsten Ruseng Jakobsen, Jeff
Sutherland. Nashville : Agile Conference Nashville 2009, 2009.
22. Scrum and CMMI Level 5: The Magic Portion for Code Warriors. Jeff Sutherland,
Carsten Ruseng Jakobsen, Kent Johnson. Hawaii : International Conference on
System Sciences, 2008. Proceedings of the 41st Hawaii International Conference on
System Sciences.
23. Justicia, Comercio y. Comercio y Justicia. Grandes Firmas de Software Cordobs
Apuestan a las Metodologas giles. [Online] Comercio y Justicia, 04 23, 2009. [Cited: 04
19, 2010.] http://www.comercioyjusticia.info/pagina.asp?id=11658.
24. D. Rubio, N. Andriano, A. Ruiz de Mendarozqueta, C. Bart. An integrated
improvement framework for sharing assessment lessons learned. La Rioja : Proceedings
del XIV Congreso Argentino de Ciencias de la Computacin, 2008. ISBN 987-24611-0-2.
25. IBM. Rational Team Concert. [Online] Rational Software. [Cited: 04 29, 2010.]
http://www.ibm.com/developerworks/rational/products/rtc/.
Pgina 16 de 16
versin 1.0.1