El documento describe el rol de las mediciones formales en proyectos de tecnología. Explica que la tercerización de servicios tecnológicos requiere elementos objetivos de control y monitoreo de proyectos. Luego, presenta un caso práctico donde se midieron puntos de función en un proyecto de una fábrica de software, Genexus, lo que permitió estimar mejor los costos y la productividad del equipo. Finalmente, concluye que las métricas son una necesidad de negocio para controlar proyectos tercerizados.

1. Rol de mediciones formales en proyectos de tecnología Alejandra Lemos [email_address] Irene Pazos [email_address]

2. Rol de mediciones formales en proyectos de tecnología RESUMEN La especialización en servicios tecnológicos es una realidad que introduce hoy actores tercerizados, ejecutando actividades de ingeniería en los proyectos de software. Contar con elementos formales y objetivos de control y monitoreo del proyecto, es una necesidad -de negocio- ineludible.

3. Agenda Dónde estamos Caso: Fábrica de Software Genexus Conclusiones

4. Agenda Dónde estamos Caso: Fábrica de Software Genexus Conclusiones

5. Dónde estamos Sofware Product Line Métricas

6. Software Product Line XVIII : Revolución CARACTERIZACIÓN Economía industrial desplaza economía de trabajo manual. Mecanización de industrias textiles y desarrollo de procesos del hierro. Expansión de comercio favorecida por mejora de las rutas de transportes (el ferrocarril). Innovación tecnológica (máquina de vapor), genera enormes incrementos de producción. Automatización soportados con tecnología (information higway) (todas) industrial !? artesanal érase una vez … (los “tiempos modernos”) cuando en los garages de sillicon valley ya no cabían coches

7. Software Product Line Organización científica del trabajo Frederick Taylor pretende eliminar por completo los movimientos innecesarios de los obreros para maximizar el potencial productivo de la industria. Cronometró tiempo de cada tarea, con el objetivo de eliminar los movimientos inútiles. érase una vez … (los “tiempos modernos”)

8. Software Product Line baby boomers: managers are born El sistema de Taylor bajó costos de producción (incluso se pagaba menos dinero por pieza para que los obreros se diesen más prisa) Para que esto funcionara era imprescindible supervisar a los trabajadores, y así surgió un grupo especial de empleados, encargado de supervisión, organización y dirección. érase una vez … (los “tiempos modernos”)

9. Software Product Line 1er. Línea de Montaje 1913 - volante del Ford T aumento productividad 55 % (1 pieza =20min  1 pieza = 9min) CONSECUENCIA … a fines de 1923 había dos automóviles por cada tres familias -en una ciudad norteamericana típica-. érase una vez … (los “tiempos modernos”) muestra de 123 familias: 49% tenía coche, 21% tenía coche viviendo en casa maltrecha, 17% tenía coche y casa maltrecha sin bañera.

10. Software Product Line Information Technology Software factory especialización tercerización automatización - generadores de código - robots de pruebas * tecnología como vehículo de negocio, disparador de cambios económicos & sociales valga la (gruesa) expresión ! los “tiempos modernos” post-Chaplin …

11. Software Product Line PROYECTOS roles, procesos, biblioteca de activos … tiempos modernos actuales: otra dimensión ortogonal

12. Software Product Line tiempos modernos actuales: otra dimensión ortogonal ciclo de vida de proyectos … * consultora A consultora B consultora C consultora D ortonormal

13. Software Product Line conceptos “ A software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.” A product line succeeds because the commonalities shared by the software products can be exploited to achieve economies of production. The products are built from common assets in a prescribed way. Product lines are, of course, nothing new in manufacturing http:// www.sei.cmu.edu / productlines ISO 9000:2000 7.4 CMMI-DEV: SAM CMMI-ACQ

14. Software Product Line desarrollar vs comprar adquirir sistemas como un producto desarrollado por una línea de producción, representa una mejora económica en tiempo de entrega, capacitación y costo. comprar: riesgos El enfoque de adquirir constituye una nueva estrategia, con nuevos problemas y riesgos institucionales y de gestión, nada obvios.

15. Software Product Line definición de objetivos en proyecto, y qué mediciones ayudarán a controlarlos identificación de criterios de éxito con indicadores por objetivo definición de métricas apropiadas desarrollar un plan para instrumentar y verificar métricas. FIJAR ALCANCE DESVIO < 15 % PUNTOS FUNCIONALES ESTÁNDAR (IFPUG) ISO/IEC 20926:2003 * medición & seguimiento Framework Version 5.0 – practice area: technical management - Measurement and Tracking

16. Métricas VALIDEZ ( validity ) se está midiendo lo que se pretende medir? FIDELIDAD ( reliability ) el proceso de medición genera resultados consistentes y estables? criterios de evaluación de métricas

17. Métricas tamaño en # obj (tecnología) caso: balanza de feria … * medición: validez & fiabilidad F -> V ALTA BAJA datos inconsistentes y fuera de target BAJA BAJA eureka ! ALTA ALTA Consistencia en obtener datos malos o fuera de alcance BAJA ALTA CASO VALIDEZ FIDELIDAD

18. Métricas criterio : tome seriamente la validez & fiabilidad métricas básicas : no ignore el poder de las métricas simples líneas de código : haga buen uso de los datos LOC, con todas las garantías y recaudos posibles normalizar o no hacerlo?: no “normalice” cualquier cosa contra cualquier otra riesgo de generar información “creíble” control, calibración (son casi-gratis) LOC en JAVA cvt a PF Mantenimiento de 1 sistema * IBM-SEPG do's and don'ts

19. Métricas Líneas de código (LOC) puede introducir incertidumbre de orden de magnitud (incluir: código ejecutable –líneas físicas/delimitadas?-, declaraciones?, comentarios? ...) Caper Jones: afirma que usar LOC en estudios de productividad involucrando múltiples lenguajes, y actividades cubriendo todo el ciclo de vida, debe ser visto como mala práctica profesional. Puntos Funcionales (FP) Confiable, buena aceptación en contratos de software Comité de estandarización internacional Requiere capacitación y recursos para conteo y seguimiento * normalización

20. Agenda Dónde estamos Caso: Fábrica de Software Genexus Conclusiones

21. Fábrica de Sofware Genexus Entorno y especificaciones Estimación inicial Metodología y criterios Resultado

22. Entorno

23. Estimación Inicial Estándar IFPUG Equipo de Fábrica

24. Entorno Interacción Fábrica – Equipo Funcional

25. Especificaciones Procesos Casos de Uso

26. Especificaciones Modelo de datos lógico Casos de prueba

27. Metodología y Criterios Fijar alcance Modelos de medición Fijar factores de ajuste (VAF) Puntos de función sin ajustar (UFPC)

28. Metodología y Criterios Fijar alcance La regla para fijar los limites consiste en tomar perspectiva de lo que el usuario percibe como funcionalidad Modelos de medición Conteo de Caja Negra Conteo de Caja Blanca (Piloto de validación)

29. Conteo de Caja Negra Conteo bottom-up de objetos GX Necesidad de Filtros Reusabilidad Uso de patterns Tecnología web Mapeos Reporte – EO/EQ Transacción - EI

30. Conteo de Caja Blanca Opción de menú Pantalla Objeto Tablas Atributos Trazabilidad

31. Piloto

32. Agenda Dónde estamos Caso: Fábrica de Software Genexus Conclusiones

33. Conclusiones Obtuvimos la aprobación del cliente Medimos la productividad de nuestro equipo – 80PF m/h Herramienta automática de medida

34. conclusiones costó 171hs. (22 días) medir piloto: 1.734 FP (1.845 UFPC) 2 x módulo: 3.417 FP (3.254 UFPC) (hs. incluyen total de esfuerzo en proceso de medición, no sólo conteo estricto) resultado de medición resultó elemento clave en determinar diferencia de orden presupuestado para alcance original. o sea: costo de 171hs. vs. costo de …?? * en números

35. conclusiones una necesidad de negocio * métricas hoy

36. referencias Software Product Lines Essentials - Linda Northrop. Software Engineering Institute - Carnegie Mellon University SPL-essentials_7_08.pdf Basics in Software Measurement and Analysis -Some Do's and Don'ts SEPG 2006 March 3 -6, Nashville, Tennessee Steve Kan IBM Rochester, MN http://www.columbia.edu/ccnmtl/projects/qmss/meas_valrel.html Kish, Leslie. 1987. Statistical Design for Research. New York: John Wiley and Sons. 3-Tiered Software Product Line Methodology - Report #200709261. September 26, 2007. www.biglever.com SOFTWARE_QUALITY_IN_2002_CAPERS_JONES.pdf Critical Problems in Software Measurement (April 1993) Caper Jones http://es.wikipedia.org *

37. muchas gracias preguntas? Irene Pazos [email_address] Alejandra Lemos [email_address]