1. Estimación de
Proyectos de Software
La cara oculta de las diferencias
Patricia Scalzone
Presidente - VEMN SA
patricias@vemn.com.ar
Daniel Laco
Director Ejecutivo - VEMN SA
daniell@vemn.com.ar
2. Temario
• El problema
• Técnicas
• … y las diferencias?
• Contratos
4. El problema “endémico” de la industria
• Sobreestimación
• Subestimación
• Imposible de estimar
5. Registros de Estimación de la Industria
Tamaño en Puntos de Función A Fallados
(y Aprox. Líneas de código) Temprano Tiempo Tarde (Cancelados)
10 FP (1.000 LOC) 11% 81% 6% 2%
100 FP (10.000 LOC) 6% 75% 12% 7%
1.000 FP (100.000 LOC) 1% 61% 18% 20%
10.000 FP (1.000.000 LOC) <1% 28% 24% 48%
100.000 FP (10.000.000 LOC) 0% 14% 21% 65%
6. Qué es estimación?
Es una predicción de cuán largo
es un proyecto o cuánto va a costar
7. Pero...
• Tenemos los objetivos del negocio:
– Necesitamos tener la Versión 2.1 lista para la Expo de
Mayo
– Necesitamos tener la Release estabilizada para las
ventas de vacaciones.
– Necesitamos tener las funciones listas para el 1 de
Julio para cumplir con requisitos de regulaciones del
gobierno.
– Debemos limitar el costo del próximo Release a 2$
millones, porque es el presupuesto máximo que
tenemos.
• Son deseables o imperativos, pero no
necesariamente alcanzables
9. Técnicas de Estimación
• Abordajes Tradicionales
– Líneas de Código
– Function Points
– Use Case Points
• Abordajes Ágiles
– Planning Poker
– Story Points
10. Ballpark Figure
O
“el rango del proyecto”
(método oscilante)
11.
12. Proyecto: Feliz Daniel
Cliente: El Mejor Estimadores Maxi
Andres
Total Estimadores 3
Ronda 1 Ronda 2
Grupo Tarea Subtarea Detalle Daniel Maxi Andres
Daniel Maxi Andres
Sección 1 2 1
Categorías 2 2 2
Ítems Attachs 100 100 40
SeccionAtributos
ABMs CategriasAtributos
Atributos
Back End
Usuarios 4 2 8
Niveles de Autorización 8 13 8
Usuarios / Niveles de
Admin de Seguridad 13 20 3
Autorización
Pantalla de publicación de Proceso de publicación Manejo de Archivos 20 20 13
producto Niveles de autorización 13 20 8
Productos 3 2 5
Soluciones de producción 3 2 5
Recursos de Venta 3 2 5
UI Visualización
Visor MHT 3 2 3
Front End Árbol de navegación de
3 3 5
productos
Búsqueda Rápida 3 3 5
Buscador de productos
Búsqueda Avanzada Filtro Genérico 13 13 20
Localización Multi-idioma 20 20 20
Totales 212 226 151 0 0 0
Ronda 1 Ronda 2
Daniel 212 0
Maxi 226 0
Andres 151 0
Mínimo 151 0
Promedio 196 0
Máximo 226 0
14. Módulo Tipo Nombre Complejidad
DIAGNOSTICO Competencia / Posición competitiva Evualuacion (Criterios) ALTA
DIAGNOSTICO Menú Principal Diagnóstico Diagnostico Interactivo ALTA
Diagnóstico / Resumen del Diagnóstico /
DIAGNOSTICO Conclusiones Conclusiones MEDIA
DIAGNOSTICO no se usa (codigo comentado) Grafico de Ventas y Rentabilidad (1) BAJA
DIAGNOSTICO no se usa (codigo comentado) Grafico de Ventas y Rentabilidad (2) BAJA
Icono en el formulario FrmDIA002
DIAGNOSTICO (Gráfico) Grafico de Ventas y Rentabilidad (3) ALTA
Activación de Indicadores, Reglas e
DIAGNOSTICO Informes Activacion de Indicadores, reglas e informes MEDIA
Diagnóstico / Resumen del Diagnóstico /
DIAGNOSTICO Resumen Resumen de diagnostico - Puntos clave MEDIA
Diagnóstico / Resumen del Diagnóstico /
DIAGNOSTICO F.O.D.A Analisis F.O.D.A ALTA
DIAGNOSTICO icono en el formulario FrmDIA002 (lupa) Informe de indicadores estrategicos (PivotTable) MEDIA
Administración del Sistema / Carga de
DIAGNOSTICO Preguntas del Diagnóstico Ingreso de CheckList ALTA
ARQUITECTURA ALTA
Ponderación Complejidad
Baja 4
Media 5
Alta 20
Testing % 30
Gestión de Proyecto % 10
Implementación % 30
% Riesgo 30
15. … y las diferencias dónde están?
• En la administración de riesgos
• En Ítems que se pierden en las
estimaciones
18. Requerimientos Funcionales
Factor Baja Media Alta
Setup/Instalación
Conversiones de datos
Interoperabildiad del Individual Otros sistemas de la misma Heterogéneo.
Proyecto tecnología Sistemas de diferentes
tecnologías
Procesamiento complejo
interno
19. Requerimientos No Funcionales
Factor Baja Media Alta
Interoperabilidad
Mantenibilidad
Performance Poco exigentes o Exigencia de rendimiento Exigencia de rendimiento muy
sin relevancia estandar exigente
Portabilidad
Confiabilidad
Código que debe ser
rehusado
Seguridad
Capacidad de Supervivencia
Facilidad de uso
Sistema Distribuido
Nro potencial de usuarios < 10 usuarios 10 a 50 usuarios > 50 usuarios
Concurrencia
20. Requerimientos No Funcionales
Factor Baja Media Alta
Características
especiales de
seguridad
Tecnología Estandar, probada Probada, pero nueva en la Novedosa, sin antecedentes
y conocida en la organización.
organización
Testeabilidad Ambiente Ambiente con interacción de Redes y conexiones
Client/Server varios servidores. Ej: complejas. SO dispares,
Arquitectura SOA organización del cliente
restrictiva. Tecnologia nueva y
sin experiencia. La Seguridad
como un factor del ambiente
de prueba (Ej. X509)
Afecta a Sistemas en No Si, pero hay franjas de tiempo El sistema es critico, de 7 x 24
Producción donde se pueden hacer
actualizaciones con parada
del sistema
21. Temas del Proyecto - I
Factor Baja Media Alta
Estabilidad de los Estables y Relativa variacion y definición Inciertos y con mucha
requisitos definidos pobre variación
Tiempo de Entrega Menos de 3 meses 3 a 9 meses Más de 9 meses
Procesar los pedidos
de cambios.
Administrar el
seguimiento de Bugs
Corregir los bugs
Coordinación de la
Gestión. Reuniones
22. Temas del Proyecto - II
Factor Baja Media Alta
Creación de datos de test
Instalación de versiones de
prueba en locaciones del
cliente
Interactuar con Clientes o
Usuarios.
Revisar planificaciones,
estimaciones, arquitectura,
diseños, planes de puesta en
marcha, casos de test, etc.
24. Temas del Equipo
Factor Baja Media Alta
Grupo de Trabajo Con experiencia y Poca experiencia y Sin experiencia en proyectos
capacitación en capacitación en proyectos similares
proyectos similares similares
Mejora de la
Pruductividad
Mentoring de nuevos
miembros.
25. Temas del Cliente - I
Factor Baja Media Alta
Facilidad de
entrenamiento de
usuarios
Cliente Conocido y con buenos Cliente nuevo, con buenas Desconocido, o conocido con
antecedentes referencias o relaciones conocidas problemas en proyectos anteriores
Interlocutores del Buena formación técnica y Formación Media y regular en Desconocido, o conocido con
Cliente en gestión de proyectos. gestión de proyectos. Regular problemas en proyectos anteriores
Buena actitud de ayuda y asistencia en resolución de
servicio. problemas
Impacto en Mínimo. Cambios moderados en Cambios significativos en
Organización organización, cultura, métodos de organización, cultura, métodos de
trabajo trabajo
26. Temas del Cliente - II
Factor Baja Media Alta
Usuarios Pocos usuarios Un Departamento o Unidad Varios Departamentos o
Involucrados de Negocio Empresas
Impacto Externo Afecta principalmente Afecta moderadamente a Afecta a terceros no
al Departamento otros Departamentos, involucrados, ciudadanos,
afectado Organizaciones o Clientes organizaciones
Tecnología Estandar, probada y Probada, pero nueva en la Novedosa, sin antecedentes
conocida en la organización.
organización
Tiempo de Disponibilidad exclusiva El interlocutor tiene otros El interlocutor mantiene
Respuesta del en el proyecto proyectos, pero este tiene muchos proyectos en
Cliente prioridad simultaneo. El interlocutor no
esta asignado al proyecto, solo
colabora
27. Actividades de No Desarrollo
Vacaciones Reuniones de la empresa
Feriados Reuniones del Departamento
Días de enfermedades Configuración de nuevos
puestos de trabajo
Entrenamiento Instalación de nuevas
herramientas
Fines de Semana Resolución de problemas de
Software y Hardware
28. La planificación tradicional trata al
desarrollo de software como una
actividad predecible
El desarrollo de software
es una actividad de creación
y transmutación
de conocimiento.
30. Resumen
• El problema
• Técnicas
• … y las diferencias?
• Contratos
31.
32. Muchas gracias
por su participación
Patricia Scalzone
Presidente - VEMN SA
patricias@vemn.com.ar
Daniel Laco
Director Ejecutivo - VEMN SA
daniell@vemn.com.ar
Editor's Notes
The Software Industry's Systemic ProblemWe often speak of the software industry's estimation problem as though it were a neutral estimation problem—that is, sometimes we overestimate, sometimes we underestimate, and we just can't get our estimates right.But the software does not have a neutral estimation problem. The industry data shows clearly that the software industry has an underestimation problem. Before we can make our estimates more accurate, we need to start making the estimates bigger. That is the key challenge for many organizations.
The Software Industry's Systemic ProblemWe often speak of the software industry's estimation problem as though it were a neutral estimation problem—that is, sometimes we overestimate, sometimes we underestimate, and we just can't get our estimates right.But the software does not have a neutral estimation problem. The industry data shows clearly that the software industry has an underestimation problem. Before we can make our estimates more accurate, we need to start making the estimates bigger. That is the key challenge for many organizations.
3.2 Details on the Software Industry's Estimation Track RecordThe software industry's estimation track record provides some interesting clues to the nature of software's estimation problems. In recent years, The Standish Group has published a biennial survey called "The Chaos Report," which describes software project outcomes. In the 2004 report, 54% of projects were delivered late, 18% failed outright, and 28% were delivered on time and within budget. Figure 3-2 shows the results for the 10 years from 1994 to 2004.Figure 3-2: Project outcomes reported in The Standish Group's Chaos report have fluctuated year to year. About three quarters of all software projects are delivered late or fail outright. What's notable about The Standish Group's data is that it doesn't even have a category for early delivery! The best possible performance is meeting expectations "On Time/On Budget"—and the other options are all downhill from there.Capers Jones presents another view of project outcomes. Jones has observed for many years that project success depends on project size. That is, larger projects struggle more than smaller projects do. Table 3-1 illustrates this point.Table 3-1: Project Outcomes by Project Size Size in Function Points (and Approximate Lines of Code)EarlyOn TimeLateFailed (Canceled)10 FP (1,000 LOC)11%81%6%2%100 FP (10,000 LOC)6%75%12%7%1,000 FP (100,000 LOC)1%61%18%20%10,000 FP (1,000,000 LOC)<1%28%24%48%100,000 FP (10,000,000 LOC)0%14%21%65%Source: Estimating Software Costs (Jones 1998).As you can see from Jones's data, the larger a project, the less chance the project has of completing on time and the greater chance it has of failing outright.Overall, a compelling number of studies have found results in line with the results reported by The Standish Group and Jones, that about one quarter of all projects are delivered on time; about one quarter are canceled; and about half are delivered late, over budget, or both (Lederer and Prasad 1992; Jones 1998; ISBSG 2001; Krasner 2003; Putnam and Myers 2003; Heemstra, Siskens and van derStelt 2003; Standish Group 2004).The reasons that projects miss their targets are manifold. Poor estimates are one reason but not the only reason. We'll discuss the reasons in depth in Chapter 4, "Where Does Estimation Error Come From?"How Late Are the Late Projects?The number of projects that run late or over budget is one consideration. The degree to which these projects miss their targets is another consideration. According to the first Standish Group survey, the average project schedule overrun was about 120% and the average cost overrun was about 100% (Standish Group 1994). But the estimation accuracy is probably worse than those numbers reflect. The Standish Group found that late projects routinely threw out significant amounts of functionality to achieve the schedules and budgets they eventually did meet. Of course, these projects' estimates weren't for the abbreviated versions they eventually delivered; they were for the originally specified, full-featured versions. If these late projects had delivered all of their originally specified functionality, they would have overrun their plans even more.One Company's ExperienceA more company-specific view of project outcomes is shown in the data reported by one of my clients in Figure 3-3.Figure 3-3: Estimation results from one organization. General industry data suggests that this company's estimates being about 100% low is typical. Data used by permission. The points that are clustered on the "0" line on the left side of the graph represent projects for which the developers reported that they were done but which were found not to be complete when the software teams began integrating their work with other groups.The diagonal line represents perfect scheduling accuracy. Ideally, the graph would show data points clustering tightly around the diagonal line. Instead, nearly all of the 80 data points shown are above the line and represent project overruns. One point is below the line, and a handful of points are on the line. The line illustrates DeMarco's common definition of an "estimate"—the earliest date by which you could possibly be finished.The Software Industry's Systemic ProblemWe often speak of the software industry's estimation problem as though it were a neutral estimation problem—that is, sometimes we overestimate, sometimes we underestimate, and we just can't get our estimates right.But the software does not have a neutral estimation problem. The industry data shows clearly that the software industry has an underestimation problem. Before we can make our estimates more accurate, we need to start making the estimates bigger. That is the key challenge for many organizations.
1.1 Estimates, Targets, and CommitmentsStrictly speaking, the dictionary definition of estimate is correct: an estimate is a prediction of how long a project will take or how much it will cost. But estimation on software projects interplays with business targets, commitments, and control.A target is a statement of a desirable business objective. Examples include the following:"We need to have Version 2.1 ready to demonstrate at a trade show in May.""We need to have this release stabilized in time for the holiday sales cycle.""These functions need to be completed by July 1 so that we'll be in compliance with government regulations.""We must limit the cost of the next release to $2 million, because that's the maximum budget we have for that release."Businesses have important reasons to establish targets independent of software estimates. But the fact that a target is desirable or even mandatory does not necessarily mean that it is achievable.While a target is a description of a desirable business objective, a commitment is a promise to deliver defined functionality at a specific level of quality by a certain date. A commitment can be the same as the estimate, or it can be more aggressive or more conservative than the estimate. In other words, do not assume that the commitment has to be the same as the estimate; it doesn't.Tip #1 Distinguish between estimates, targets, and commitments.
1.1 Estimates, Targets, and CommitmentsStrictly speaking, the dictionary definition of estimate is correct: an estimate is a prediction of how long a project will take or how much it will cost. But estimation on software projects interplays with business targets, commitments, and control.A target is a statement of a desirable business objective. Examples include the following:"We need to have Version 2.1 ready to demonstrate at a trade show in May.""We need to have this release stabilized in time for the holiday sales cycle.""These functions need to be completed by July 1 so that we'll be in compliance with government regulations.""We must limit the cost of the next release to $2 million, because that's the maximum budget we have for that release."Businesses have important reasons to establish targets independent of software estimates. But the fact that a target is desirable or even mandatory does not necessarily mean that it is achievable.While a target is a description of a desirable business objective, a commitment is a promise to deliver defined functionality at a specific level of quality by a certain date. A commitment can be the same as the estimate, or it can be more aggressive or more conservative than the estimate. In other words, do not assume that the commitment has to be the same as the estimate; it doesn't.Tip #1 Distinguish between estimates, targets, and commitments.
The answer to the question of what an "estimate" is still leaves us with the question of what a good estimate is. Estimation experts have proposed various definitions of a good estimate. Capers Jones has stated that accuracy with ±10% is possible, but only on well-controlled projects (Jones 1998). Chaotic projects have too much variability to achieve that level of accuracy.In 1986, Professors S.D. Conte, H.E. Dunsmore, and V.Y. Shen proposed that a good estimation approach should provide estimates that are within 25% of the actual results 75% of the time (Conte, Dunsmore, and Shen 1986). This evaluation standard is the most common standard used to evaluate estimation accuracy (Stutzke 2005).Numerous companies have reported estimation results that are close to the accuracy Conte, Dunsmore, and Shen and Jones have suggested. Figure 1-6 shows actual results compared to estimates from a set of U.S. Air Force projects.Figure 1-6: Improvement in estimation of a set of U.S. Air Force projects. The predictability of the projects improved dramatically as the organizations moved toward higher CMM levels. [1]Figure 1-7 shows results of a similar improvement program at the Boeing Company.Figure 1-7: Improvement in estimation at the Boeing Company. As with the U.S. Air Force projects, the predictability of the projects improved dramatically at higher CMM levels. A final, similar example, shown in Figure 1-8, comes from improved estimation results at Schlumberger.Figure 1-8: Schlumberger improved its estimation accuracy from an average overrun of 35 weeks to an average underrun of 1 week. One of my client companies delivers 97% of its projects on time and within budget. Telcordia reported that it delivers 98% of its projects on time and within budget (Pitterman 2000). Numerous other companies have published similar results (Putnam and Myers 2003). Organizations are creating good estimates by both Jones's definition and Conte, Dunsmore, and Shen's definition. However, an important concept is missing from both of these definitions—namely, that accurate estimation results cannot be accomplished through estimation practices alone. They must also be supported by effective project control.[1]The CMM (Capability Maturity Model) is a system defined by the Software Engineering Institute to assess the effectiveness of software organizations.
1.1 Estimates, Targets, and CommitmentsStrictly speaking, the dictionary definition of estimate is correct: an estimate is a prediction of how long a project will take or how much it will cost. But estimation on software projects interplays with business targets, commitments, and control.A target is a statement of a desirable business objective. Examples include the following:"We need to have Version 2.1 ready to demonstrate at a trade show in May.""We need to have this release stabilized in time for the holiday sales cycle.""These functions need to be completed by July 1 so that we'll be in compliance with government regulations.""We must limit the cost of the next release to $2 million, because that's the maximum budget we have for that release."Businesses have important reasons to establish targets independent of software estimates. But the fact that a target is desirable or even mandatory does not necessarily mean that it is achievable.While a target is a description of a desirable business objective, a commitment is a promise to deliver defined functionality at a specific level of quality by a certain date. A commitment can be the same as the estimate, or it can be more aggressive or more conservative than the estimate. In other words, do not assume that the commitment has to be the same as the estimate; it doesn't.Tip #1 Distinguish between estimates, targets, and commitments.
…” Empecemos por refinar un poco qué significa no poder predecir el tamaño del producto. En la práctica, cualquier desarrollador senior puede dar una idea del orden de magnitud de un proyecto. Esto nos brinda lo que en inglés se denomina ballpark figure, un número grueso que nos permite ir pensando si es negocio desarrollar el producto o no. Y es lo primero que debe hacerse, ágil o no ágil. Las probabilidades de estar equivocados en un órden de magnitud son realmente bajas (en ese caso, por favor reconsiderar el titulo de "senior" de los desarrolladores). En mi experiencia, los proyectos tradicionales suelen excederse de sus estimaciones originales en números que van del 30% al 300%. Esto es lo que intentaremos mejorar con la técnica que explicaremos a continuación….”http://www.proyectosagiles.org/introduccion-estimacion-planificacion-agil
…” Empecemos por refinar un poco qué significa no poder predecir el tamaño del producto. En la práctica, cualquier desarrollador senior puede dar una idea del orden de magnitud de un proyecto. Esto nos brinda lo que en inglés se denomina ballpark figure, un número grueso que nos permite ir pensando si es negocio desarrollar el producto o no. Y es lo primero que debe hacerse, ágil o no ágil. Las probabilidades de estar equivocados en un órden de magnitud son realmente bajas (en ese caso, por favor reconsiderar el titulo de "senior" de los desarrolladores). En mi experiencia, los proyectos tradicionales suelen excederse de sus estimaciones originales en números que van del 30% al 300%. Esto es lo que intentaremos mejorar con la técnica que explicaremos a continuación….”http://www.proyectosagiles.org/introduccion-estimacion-planificacion-agil
…” Empecemos por refinar un poco qué significa no poder predecir el tamaño del producto. En la práctica, cualquier desarrollador senior puede dar una idea del orden de magnitud de un proyecto. Esto nos brinda lo que en inglés se denomina ballpark figure, un número grueso que nos permite ir pensando si es negocio desarrollar el producto o no. Y es lo primero que debe hacerse, ágil o no ágil. Las probabilidades de estar equivocados en un órden de magnitud son realmente bajas (en ese caso, por favor reconsiderar el titulo de "senior" de los desarrolladores). En mi experiencia, los proyectos tradicionales suelen excederse de sus estimaciones originales en números que van del 30% al 300%. Esto es lo que intentaremos mejorar con la técnica que explicaremos a continuación….”http://www.proyectosagiles.org/introduccion-estimacion-planificacion-agil
…” Empecemos por refinar un poco qué significa no poder predecir el tamaño del producto. En la práctica, cualquier desarrollador senior puede dar una idea del orden de magnitud de un proyecto. Esto nos brinda lo que en inglés se denomina ballpark figure, un número grueso que nos permite ir pensando si es negocio desarrollar el producto o no. Y es lo primero que debe hacerse, ágil o no ágil. Las probabilidades de estar equivocados en un órden de magnitud son realmente bajas (en ese caso, por favor reconsiderar el titulo de "senior" de los desarrolladores). En mi experiencia, los proyectos tradicionales suelen excederse de sus estimaciones originales en números que van del 30% al 300%. Esto es lo que intentaremos mejorar con la técnica que explicaremos a continuación….”http://www.proyectosagiles.org/introduccion-estimacion-planificacion-agil
http://www.proyectosagiles.org/introduccion-estimacion-planificacion-agil¿En cuantos negocios tiene un coste similar la producción de una unidad que la de un millón? ¿Cuantos negocios tienen un 99% de margen de beneficio en la venta de sus productos? ¿En cuantos negocios las empresas que desarrollan productos terminan incluyendo prestación de servicios, tanto si les gusta como si no? (proporcionando cierta configuración del producto, y servicios técnicos como integración del sistema y mantenimiento). ¿En cuantos negocios los mejores empleados son diez o veinte veces más productivos que los peores? ¿Cuantos negocios toleran como habitual que el 75 o el 80% de los proyectos de desarrollo de productos terminen tarde o desbordando el presupuesto? ¿En cuantas empresas, quienes desarrollan los productos se autoconsideran artistas, y no científicos o ingenieros, y presentan temperamentos difíciles e inestables? ¿En cuantos negocios los clientes terminan siendo cautivos de un determinado proveedor a raíz de las decisiones que alguien tomó diez años antes y que no se pueden eliminar fácilmente?."
Algunos intentan otro tipo de contratos… …”Ante el problema de tener que detallar todo prematuramente, el cliente suele adoptar una posición defensiva que es contraria a sus intereses. El cliente tratará que el sistema sea lo suficientemente flexible para poder cubrir las necesidades que pudieran surgir o cambiar. Por este motivo el sistema implementará ciertas funcionalidades no se llegaran a utilizar.” … “En proyectos reales la aplicación de las metodologías ágiles se enfrenta en muchas situaciones a problemas que la teoría no contemplaba. El principal problema que nosencontramos en los proyectos reales es que los tipos de contratos no encajan con algunas de las prácticas. Estos contratos suelen ser de dos tipos: · Contrato de Alcance Cerrado: Que nos obligan a cerrar los requisitos en la primera fase (Metodologías tradicionales)· Subcontratación de personal: Que no podemos clasificarlo como proyecto, ya que suele ser el cliente el que dicta en qué se emplea ese esfuerzo. Una solución que hemos utilizado en proyectos ha sido definir un nuevo tipo de contrato, en el que especifiquemos la funcionalidad que se va a desarrollar, pero en elque el alcance podrá ser modificado durante la duración del contrato. Este alcance podrá ser modificado porque lo que se ofrece es un esfuerzo que es el que se estima que van a llevar los requisitos acordados, pero que podrán ser intercambiados por otros requisitos de igual dificultad técnica.” http://www.willydev.net/descargas/prev/metodologiasagiles.pdf