A Study of Non-linearity in the Statistical Convertibility of Function Points into COSMIC
Function PointsMétodos Agiles: Productividad vs Actualización
Gabriela RobioloFacultad de Ingeniería
Universidad AustralBuenos Aires, Argentina
Motivación
Una nueva forma de trabajo que pareciera satisface las necesidades de la industria del software.
Promete importantes soluciones a problemas recurrentes detectados en los procesos de desarrollo.
¿Son los métodos ágiles un ambiente de mayor productividad o simplemente una evolución de los métodos tradicionales?
21/04/23Dra. Gabriela Robiolo 2
Evidencias empíricas XP [2]
• Difícil de ser adoptado en organizaciones complejas
• Proyectos pequeños
• Funciona
• Diferentes ambientes
• Clientes– Feed-back y respuesta al
cambio
– On site: no es sostenible por un tiempo prolongado
• Grupos experimentados
• Perfiles con facilidad de comunicación interpersonal
• Programación de a pares (opiniones contradictorias)
• Profesionales más satisfechos
• Estudiantes – Entrenamiento para trabajo
futuro
– Dificultad para el testing
21/04/23Dra. Gabriela Robiolo 3
Evidencias empíricas - Productividad
Apple, una experiencia: la inadecuada utilización de las prácticas ágiles podría ser contraproducente [5]
Un proceso ágil (en un contexto académico) no obtuvo un mejor rendimiento de la inversión (ROI) que un proceso tradicional (o conducido por planificación) [6]
21/04/23Dra. Gabriela Robiolo
XP [2]
4
Evidencias empíricas Scrum [3]
Experiencia• Correlación entre el
nivel de adopción del atributo y el éxito del proyecto (medido desde la perspectiva del ingeniero de software)
• Ingenieros de Software (Scrum user group), Recife, PE (Brazil).
Atributo• Entrega regular del software
• Entrega temprana de las características más importantes
• Test de Integración correcto
• Miembros del grupo con alta experiencia
• Aplicación de prácticas de administración de requerimientos de agile
• Aplicación de prácticas de administración de la configuración de agile
• Grupo coherente y auto organizado
• Buena relación con el cliente
21/04/23Dra. Gabriela Robiolo 5
Evidencias empíricas Scrum [4]
Experiencia• Identificación
de problemas en un mega-proyecto en ámbito político.
• 11 Grupos Scrum de diferentes sub-contratistas
• Entrevistados 13 participantes
Problemas• Restricciones en la colaboración debido a incompleta
explicitación contractual de responsabilidades.
• Baja prioridad de cualidades arquitectónicas y técnicas
• Conflictos entre control organizacional y flexibilidad
• Demorada y volátil definición de requerimientos
• Falta de una visión compartida del producto final.
• Limitada difusión de los conocimientos funcionales
• Dependencias excesiva entre las partes del programa.
• Sobrecarga del personal clave.
• Dificultades para mantener el buen funcionamiento de entornos técnicos.
• Dificultades en la coordinación de las pruebas y la implementación con las partes externas.
21/04/23Dra. Gabriela Robiolo 6
Evidencias empíricas Scrum [7]
Caso de estudio
• 150 empleados, distribuidos en distintos grupos
• ¿La aplicación de Scrum mejora la calidad del software, en términos de cantidad de defectos?
21/04/23Dra. Gabriela Robiolo 7
RUP versus Scrum - UA
Motivos de la selección
– Ambos son usados en el ámbito de la industria del software
– Es posible hacer de RUP una metodología ágil
21/04/23Dra. Gabriela Robiolo 8
RUP vs Scrum
Preguntas de investigación:– Tamaño funcional: ¿Scrum > RUP ?– Diseño: ¿RUP es mejor que Scrum ?– Comprensión: ¿ RUP > Scrum ?– ¿Existen diferencias significativas en la
implementación de la arquitectura?
21/04/23Dra. Gabriela Robiolo 9
Definición del experimento
Contexto
– Taller de diseño de 4to año de Ingeniería en Informática
– 3 horas semanales
– Los alumnos desarrollan un producto de software
– Se dividió la clase en 2 grupos: RUP y Scrum equilibrando los grupos en base a:• Rendimiento académico
• Experiencia laboral
• Carga académica
– Ambos grupos desarrollaron un juego de estrategia por turnos partiendo de una misma definición de requerimientos
21/04/23Dra. Gabriela Robiolo 10
Definición del experimento
21/04/23Dra. Gabriela Robiolo 11
Definición del experimento
21/04/23 Dra. Gabriela Robiolo
12/20
Definición del experimento
Atributos estudiados– Tamaño funcional– Calidad de diseño– Grado de comprensión del diseño– Características de implementación de la
arquitectura– Diseño externo– Calidad de programación
21/04/23Dra. Gabriela Robiolo 13
Definición del experimento
Variables controladas–Capacidad del grupo de desarrollo– Ambiente de desarrollo– Tiempo–Nivel de capacitación en el
dominio–Complejidad del producto
21/04/23Dra. Gabriela Robiolo 14
Resultados - Tamaño funcional
Tamaño funcional
RUP Scrum
Transacciones 8 10
menor tiempo dedicado a implementación
código funcional mucho antes
21/04/23Dra. Gabriela Robiolo
re-trabajo
15
Resultados - Calidad de diseño
Calidad de diseño
RUP Scrum
Número de clases afectadas por cambios
8 17
21/04/23Dra. Gabriela Robiolo 16
Resultados Grado de comprensión del diseño
o
Alumno Respuestas Puntaje Total
Claras Confusas Erroneas
Scrum2 3 5 7 14
Rup2 6 4 5 22
Scrum4 7 2 6 23
Scrum3 6 9 0 27
Scrum1 12 3 0 39
Rup3 14 0 1 42
Rup1 15 0 0 45
RUP tenían mayor conocimiento de las clases implementadas por otros integrantes del grupo.
No hay evidencia estadística
21/04/23Dra. Gabriela Robiolo 17
ResultadosDiferencias de implementación
Métrica RUP Scrum
Cantidad de clases 47 86
Métodos ponderados por clase
8,09 4,39
Número de hijos por clase
0,26 0,31
Acoplamiento entre clases
3,66 3,77
Número de métodos públicos por clase
7,32 3,59
doble del número de clases
Menor densidad de métodos
21/04/23 Dra. Gabriela Robiolo
18/20
Requerimientos
Nro. Function Points
Transacciones Objetos de Entidad
Caminos
UseCase 14 98 26 10 52
UserStory 10 68 12 8 8
Importancia del testing y la participación del cliente
21/04/23Dra. Gabriela Robiolo 19
Conclusiones de la comparación
RUP– Menos funcionalidad implementada– Producto más simple, de menor tamaño (menor cantidad de clases)– Diseño de mayor calidad– Mayor comprensión global de la solución implementada
Scrum– Mayor funcionalidad implementada (con mayor tiempo de
programación)– Empezó a producir código funcional en menor tiempo– Producto más grande y complejo– Diseño de menor calidad– Menor comprensión global de la solución implementada
No se puede afirmar taxativamente que un método sea mejor que otro
21/04/23Dra. Gabriela Robiolo 20
Conclusiones
Pocas evidencias empíricasNo hay evidencia de una mayor:– productividad– calidad
Profesionales más satisfechosEs una natural evolución que captura características atrayentes para las empresas y jóvenes desarrolladores
Los métodos ágiles son una tendencia
21/04/23Dra. Gabriela Robiolo 21
Agilidad e informalidad responden a parámetros de conducta de los jóvenes
Código antes
Accentur implementó una herramienta global para registración del tiempo y tarea realizada y gastos ejecutados.
Cada país tenía su propia herrramienta (58 paises diferentes con su propia herramienta)
Una herramienta global que reemplaza todas estas herramientas
Se implentó Agile para dar de baja servidores propios de cada país para ahorrar costos a la compañía
En un año y medio se sumaron a la aplicación los 58 paises, sin necedidad de esperar la finalización de la implementación
21/04/23Dra. Gabriela Robiolo 23
Bibliografía
[1] Zazworka, N., Stapel, K., Knauss, E., Shull, F., Basili, V. R., and Schneider, K. 2010. Are developers complying with the process: an XP study. In Proceedings of the 2010 ACM-IEEE international Symposium on Empirical Software Engineering and Measurement (Bolzano-Bozen, Italy, September 16 - 17, 2010). ESEM '10. ACM, New York, NY, 1-10.
[2] T. Dyba˚, T. Dingsøyr, 2008 Empirical studies of agile software development: A systematic review, Inform. Softw. Technol.
[3] França, A. C., da Silva, F. Q., and de Sousa Mariz, L. M. 2010. An empirical study on the relationship between the use of agile practices and the success of Scrum projects. In Proceedings of the 2010 ACM-IEEE international Symposium on Empirical Software Engineering and Measurement (Bolzano-Bozen, Italy, September 16 - 17, 2010). ESEM '10. ACM, New York, NY, 1-4.
[4] Hannay, J. E. and Benestad, H. C. 2010. Perceived productivity threats in large agile development projects. In Proceedings of the 2010 ACM-IEEE international Symposium on Empirical Software Engineering and Measurement (Bolzano-Bozen, Italy, September 16 - 17, 2010). ESEM '10. ACM, New York, NY, 1-10.
[5] Khramov, Y. The Cost of Code Quality. In Proceedings of the AGILE 2006 (Minneapolis, Minnesota, July, 2006). IEEE Computer Society, 119-125
[6] Rundle, P. J. and Dewar, R. G. Using Return on Investment to Compare Agile and Plan-driven Practices in Undergraduate Group Projects. In Proceedings of the 28 th international conference on Software engineering (Shanghai,China, May, 2006). ACM, 649-654
21/04/23Dra. Gabriela Robiolo 24
