Successfully reported this slideshow.
INTRODUCCIÓN A LA ESTIMACIÓN   Putnam, UC Punto Función y Experiencias        Dr. D. Javier Garzás Parra  Project Manager ...
INDICE1.  INTRODUCCIÓN2.  EL MODELO SLIM O DE PUTNAM3.  CASOS DE USO PUNTO FUNCIÓN4.  PRINCIPIOS, RECOMENDACIONES, CONSEJO...
6%, 200% de                             retraso                                         No se puede mostrar la imagen. Pue...
INTRODUCCIÓN      Principales Razones del Fracaso en los Proyectos              q Requisitos y Especificaciones Incomplet...
INTRODUCCIÓN                            Timeline:                           KPMG Survey                     Failure Projec...
INTRODUCCIÓNIMPACTO NO LINEALDEBIDO A ERRORESEN LAPLANIFICACIÓN,                      Coste               IMPACTO LINEALER...
¿CUÁLES SON LAS CLAVES DEL ÉXITO? “Q: What are the most exciting/promising software engineering ideas or techniques on the...
MODELOS DE ESTIMACIÓN DEL SOFTWARE(basado en Boehm, Software Engineering Economics)      q Basados en la experiencia     ...
METODOLOGÍA GENERAL               Effort              Cost             Estimation         Estimation   Size               ...
EL MODELO SLIM O DE PUTNAM    ESTIMACIÓN DEL ESFUERZO
LA ECUACIÓN DEL SOFTWARE La cantidad de trabajo que se encuentra en cualquier producto se puede ver como el producto del e...
LA ECUACIÓN DEL SOFTWARE La cantidad de trabajo que se encuentra en cualquier producto se puede ver como el producto del e...
PRODUCTIVIDAD DEL PROCESO La ecuación anterior tiene mayor sentido si la expresamos como            Producto = Productivid...
PRODUCTIVIDAD DEL PROCESO     Aunque de esta manera la Productividad no está definida precisamente, se supone que incluye ...
SLIM (Software LIfecycle Management) o de Putnam         Putnam et al. estudian una Base de Datos (QSM):  750 sistemas pro...
SLIM (Software LIfecycle Management) o de Putnam          Elemento central del metodo de Putnam...                  Ecuaci...
SLIM (Software LIfecycle Management) o de Putnam    El factor “B” es una función del tamaño del sistema...                ...
JUSTIFICACIÓN DE LAS POTENCIAS 1/3 Y 4/3  Se observa que pequeños cambios en el tiempo de desarrollo       provocan grande...
JUSTIFICACIÓN DE LAS POTENCIAS 1/3 Y 4/3       El método de validación fue el de reordenar la ecuación como             Es...
PARÁMETRO DE LA PRODUCTIVIDAD (PP)  Se obtiene por Calibración a partir de sistemas ya concluidos.                 Product...
PARÁMETRO DE LA PRODUCTIVIDAD (PP)Se calculó el PP de los sistemas registrados en QSM, estos se grupan                    ...
UTILIZACIÓN DE LA ECUACIÓN PARA LA ESTIMACIÓN  La utilización es estimar tiempo y esfuerzo al comienzo de un              ...
SOLUCIÓN DETERMINISTA:MODELO DE PROCESO DE NORDENBasandose en datos históricos, se estudiaron 20 proyectos, Norden        ...
MODELO DE PROCESO DE NORDEN  Pico de esfuerzo en el mes 7 requiere 5 personas, Pocas personas al comienzo,                ...
MODELO DE PROCESO DE NORDENRequirements                  Design   Code   Test     Maintenance                             ...
PUTNAM OBSERVÓ QUEq El momento en que la curva de Rayleigh toma su máximo valor correspondea las pruebas de sistema – ent...
PUTNAM OBSERVÓ QUEq Parámetro de incremento de personal (PIP)q Relación entre Esfuerzo total (E) y el tiempo de desarrol...
Javier Garzás ©, Introducción a la Estimación Software                                                    28
PUTNAM OBSERVÓ QUE  Esfuerzo Total (E) = Esfuerzo de Desarrollo (Ed) / 0.39 = PIP * (Td)3                                 ...
La decisión de aumentar rápidamente el personal deldesarrollo (PIP) de un proyecto tiene mas efecto en el coste y el      ...
CONSIDERACIONES AL MODELO DE PUTNAMq El modelo de Putnam muestra una extrema penalización a la hora decomprimir tiemposq...
EXPERIENCIASq Nosotros utilizamos la herramienta de “Construx”                                                      Javie...
EXPERIENCIAS                                 Curva de Rayleigh en la realidadManpower (m)                                 ...
Use Cases Function Points     Estimación del Tamaño
The Use Case Points Estimation q The Use Case Points Estimation Method (1993) fué desarrollado por G. Karner. q Método i...
The Use Case Points Estimation       Nosotros hemos seleccionado este método por:         q  Probado         q  UCFP bas...
PRE REQUISITO PARA UTILIZAR EL MÉTODO              CASOS DE USO Y NIVEL DE DETALLE    El modelo de casos de uso debe ser d...
CASOS DE USO    “A use case is a narrative document that describes the   sequence of events of an actor (an external agent...
EJEMPLO   Use Case Name: Place Order   Short description: The customer provides address information and a list of product ...
MÉTODO                                     Use cases Actors categorizados                                 categorizados se...
Unadjusted Use Case Point (UUCP)     1º) Cada actor categorizado según complejidad y peso                    ACTOR TYPE   ...
Unadjusted Use Case Point (UUCP)     2º) La complejidad de los UC es medida en número de                         transacci...
Unadjusted Use Case Point (UUCP) 3º) Los “unadjusted use case points” se calculan añadiendo los                 pesos por ...
FACTORES TÉCNICOS4º) Los “unadjusted use case points” se ajustan en base a 13 factores                                    ...
FACTORES DE ENTORNO 5º) Los “unadjusted use case points” se ajustan en base a 8 factores                                  ...
PUNTOS CASO DE USO     USE CASE POINTS (UCP) = UUCP * TCF * EF                                  Javier Garzás ©, Introducc...
PRODUCTIVIDAD         ESTIMATE = UCP * Productivity factor                                        Javier Garzás ©, Introdu...
FACTOR DE PRODUCTIVIDAD                            APROXIMACIONES                   Karner propone 20 horas por use case p...
Jones’ First-Order Estimation Practice Take the function-point total and raise it to the appropriate power.  Kind of Softw...
Putman Model (our next step)                               2               a = 1/2*td2   p(t) = 2.a.Effort.t .   e-atIniti...
AJUSTE DE FACTORES A NUESTRO CASO CONCRETO Productivity Factor, hemos validado el rango pero necesitamos ajustarlo, con da...
CONSIDERACIONESq Son más dificiles de comparar con otras organizaciones... pero no nos importaestoq Un valor muy importa...
CONSIDERACIONES                         20%Sobre/Bajo ProcentajeDe Esfuerzo Estimado                          0%          ...
PRINCIPIOS, RECOMENDACIONES,  CONSEJOS Y CONCLUSIONES
PRINCIPIOS Y MEJORES PRÁCTICASq Evitar estimaciones improvisadasq Dedicar tiempo a estimarq Usar datos de proyectos ant...
PRINCIPIOS Y MEJORES PRÁCTICAS  ESTIMACIÓN DE PROYECTO ≠ ESTIMACIÓN SOFTWARE        Hardware, software, comunicaciones, et...
PRINCIPIOS Y MEJORES PRÁCTICAS q La exactitud de la estimación es directamente proporcional a la definición del producto....
MUERTES POR ESTIMACIÓN...  q Estimar cuánto tiempo antes de saber qué  q Asumir que las estimaciones más fiables vienen ...
“LINES OF CODE”q La mayoría de los modelos se basan en las KLOCq Problemas:    q Equivalencia: entre instru. fuente de ...
MUERTES POR ESTIMACIÓN...  q  Asumir que estimar por abajo no tiene impacto  q Boehm observó que hay un límite más allá ...
Political disorders can be quickly healed if they are seen well in advance; when, for lack of a diagnosis, they are allowe...
INTRODUCCIÓN A LA ESTIMACIÓN            Dr. D. Javier Garzás Parra  Project Manager / Process Engineering Leader          ...
Upcoming SlideShare
Loading in …5
×

Estimation software y el método Putnam

6,662 views

Published on

Conferencia impartida en Valladolid, 8 de Junio de 2005. Organizada por el Colegio de Ingenieros Informática de CyL

Published in: Technology
  • Be the first to comment

Estimation software y el método Putnam

  1. 1. INTRODUCCIÓN A LA ESTIMACIÓN Putnam, UC Punto Función y Experiencias Dr. D. Javier Garzás Parra Project Manager / Process Engineering Leader mCentric javier.garzas@m-centric.com or jgarzas@gmail.com www.javiergarzas.com Valladolid, 8 de Junio de 2005
  2. 2. INDICE1.  INTRODUCCIÓN2.  EL MODELO SLIM O DE PUTNAM3.  CASOS DE USO PUNTO FUNCIÓN4.  PRINCIPIOS, RECOMENDACIONES, CONSEJOS Y CONCLUSIONES Javier Garzás ©, Introducción a la Estimación Software 2
  3. 3. 6%, 200% de retraso No se puede mostrar la imagen. Puede que su equipo no tenga suficiente memoria para abrir la imagen o que ésta esté dañada. Reinicie el equipo y, a continuación, abra el archivo de nuevo. Si sigue apareciendo la x roja, puede que tenga que borrar la imagen e insertarla de nuevo. Cancelados16 %, entre un 101 y un 29% 200 % tarde9%, entre un 51 y 100% tarde 8%, entre un 21 y un Fuente: Standish Group Survey, 1999 (from a survey of 8000 50% de retraso business systems projects) 6%, un 20% tarde En tiempo 26% Javier Garzás ©, Introducción a la Estimación Software 3
  4. 4. INTRODUCCIÓN Principales Razones del Fracaso en los Proyectos q Requisitos y Especificaciones Incompletas q Pobre Aportación del Usuario q Falta de Recursos q Expectativas Irrealistas q Falta de Soporte Ejecutivo q Cambios en los Requisitos - Especificaciones q Falta de Planificación q Falta de Gestión Tecnológica q Desconocimiento Tecnológico (Standish Group) Javier Garzás ©, Introducción a la Estimación Software 4
  5. 5. INTRODUCCIÓN Timeline: KPMG Survey Failure Project Statistics q 87% of failed projects exceeded schedule > 30% q 56% of failed projects exceed budget > 30% q 45% of failed projects failed to produce expected benefits Javier Garzás ©, Introducción a la Estimación Software 5
  6. 6. INTRODUCCIÓNIMPACTO NO LINEALDEBIDO A ERRORESEN LAPLANIFICACIÓN, Coste IMPACTO LINEALERRORES, Esfuerzo DEBIDO A LA LEY DEPRÁCTICAS DE ALTO PARKINSONRIESGO Estimación por debajo Sobre estimación < 100% 100% >100% Objetivo como porcentaje de la estimación nominal Source: McConnell S. Rapid Development. 1996. Javier Garzás ©, Introducción a la Estimación Software 6
  7. 7. ¿CUÁLES SON LAS CLAVES DEL ÉXITO? “Q: What are the most exciting/promising software engineering ideas or techniques on the horizon? A: I don’t think that the most promising ideas are on the horizon. They are already here and have been here for years but are not being used properly.” David L. Parnas Javier Garzás ©, Introducción a la Estimación Software 7
  8. 8. MODELOS DE ESTIMACIÓN DEL SOFTWARE(basado en Boehm, Software Engineering Economics) q Basados en la experiencia q Históricos - Analogía q De base estadística q Con base teórica (Putnam, COCOMO, Punto Función, etc.) q Compuestos Javier Garzás ©, Introducción a la Estimación Software 8
  9. 9. METODOLOGÍA GENERAL Effort Cost Estimation Estimation Size StaffingEstimation Estimation Duration Estimation Scheduling Javier Garzás ©, Introducción a la Estimación Software 9
  10. 10. EL MODELO SLIM O DE PUTNAM ESTIMACIÓN DEL ESFUERZO
  11. 11. LA ECUACIÓN DEL SOFTWARE La cantidad de trabajo que se encuentra en cualquier producto se puede ver como el producto del esfuerzo realizado en un periodo de tiempo, y se puede escribir como... Producto = (Constante) · Esfuerzo · Tiempo q Producto representa cierta medida sobre la funcionalidad del mismo, y se cree proporcional al producto Esfuerzo * Tiempo. La medida SLOC suele ser una medida habitual de la funcionalidad. q Esfuerzo representa el trabajo humano, medido en personas- mes o personas-año. q Tiempo representa la duración del trabajo, medido en meses o años. q Constante es un factor de proporcionalidad. Una vez establecidas las otras tres variables, esta constante permite igualarlos. Javier Garzás ©, Introducción a la Estimación Software 11
  12. 12. LA ECUACIÓN DEL SOFTWARE La cantidad de trabajo que se encuentra en cualquier producto se puede ver como el producto del esfuerzo realizado en un periodo de tiempo, y se puede escribir como... Producto = (Constante) · Esfuerzo · Tiempo q Producto representa cierta medida sobre la funcionalidad del mismo, y se cree proporcional al producto Esfuerzo * Tiempo. La medida SLOC suele ser una medida habitual de la funcionalidad. q Esfuerzo representa el trabajo humano, medido en personas- mes o personas-año. q Tiempo representa la duración del trabajo, medido en meses o años. q Constante es un factor de proporcionalidad. Una vez establecidas las otras tres Sin embargo parece que la cantidad de producto variables, esta constante permite igualarlos. depende también de "cómo se hacen las cosas", puesto que con el mismo esfuerzo y tiempo, y dependiendo del entorno de trabajo, podremos conseguir mayor o menor cantidad de producto. Javier Garzás ©, Introducción a la Estimación Software 12
  13. 13. PRODUCTIVIDAD DEL PROCESO La ecuación anterior tiene mayor sentido si la expresamos como Producto = Productividad · Esfuerzo · Tiempo de donde podemos obtener el valor de Productividad, si conocemos los otros términos... Productividad = Producto/(Esfuerzo · Tiempo) Javier Garzás ©, Introducción a la Estimación Software 13
  14. 14. PRODUCTIVIDAD DEL PROCESO Aunque de esta manera la Productividad no está definida precisamente, se supone que incluye un conjunto de factores que afectan a toda la organización, incluyendo: q  la gestión del proyecto q  la utilización de buenos requerimientos, q  diseños, q  codificaciones, etc. q  el nivel del lenguaje de programación q  el estado de la tecnología q  la experiencia de los miembros del grupo q  la complejidad de la aplicación. En un determinado momento del proyecto, el valor de la Productividad es fijo. Sin embargo, en el tiempo cambia su valor.Esta productividad es un conjunto de factores y se puede denominar "parámetro de productividad del proceso (PP)". Javier Garzás ©, Introducción a la Estimación Software 14
  15. 15. SLIM (Software LIfecycle Management) o de Putnam Putnam et al. estudian una Base de Datos (QSM): 750 sistemas procedentes de la Air Force Electronic Systems Division, Rome Air Development Center y otros sistemas de procedencias diversas. DEDUCEN QUE LA RELACIÓN ENTRE LOS TERMINOS NO ES LINEAL Javier Garzás ©, Introducción a la Estimación Software 15
  16. 16. SLIM (Software LIfecycle Management) o de Putnam Elemento central del metodo de Putnam... Ecuación del software: Producto = PP * (Esfuerzo / B) (1/3) * Tiempo (4/3) q Producto se mide en SLOC q Parámetro de productividad (PP): Se obtiene por calibración con datos históricos de proyectos, capacidad de desarrollo, se suele derivar de datos históricos aplicando la ecuación. q Esfuerzo en hombres-año: comprende diseño, codificación, test, documentación y supervisión. q B es un parámetro de habilidad: depende del tamaño del producto q Tiempo (o Td) de desarrollo (diseño, codificación, test, documentación y supervisión) en años ¿Por qué se eligió ese modelo? Javier Garzás ©, Introducción a la Estimación Software 16
  17. 17. SLIM (Software LIfecycle Management) o de Putnam El factor “B” es una función del tamaño del sistema... TAMAÑO B (SLOC) q 5-15K q .16 q 20K q .18 q 30K q .28 q 40K q .34 q 50K q .37 q >70K q .39 Javier Garzás ©, Introducción a la Estimación Software 17
  18. 18. JUSTIFICACIÓN DE LAS POTENCIAS 1/3 Y 4/3 Se observa que pequeños cambios en el tiempo de desarrollo provocan grandes modificaciones en el esfuerzo.Por ejemplo, extendiendo el tiempo de desarrollo de 18 meses a 19 meses (5.5% más), disminuye el esfuerzo en un 19.5%. Empíricamente se validó esta relación posteriormente con 70 sistemas más. Después, a mediados de los 80 se utilizaron 750 sistemas Javier Garzás ©, Introducción a la Estimación Software 18
  19. 19. JUSTIFICACIÓN DE LAS POTENCIAS 1/3 Y 4/3 El método de validación fue el de reordenar la ecuación como Esfuerzo = [Producto * B(1/3)/ PP]3 · (1/Tiempo4) Para un sistema concreto, los términos entre corchetes son constantes Esfuerzo = Constante / Tiempo (potencia)Se buscó en la base de datos clases para los que el factor entre corchetes era parecido, encontrándose 8 grupos. Para cada grupo se buscó esa relaciónpotencial. El valor medio del exponente para los ocho grupos es de 3.721 con una desviación estándar de 0.215. La probabilidad que el valor real del exponente esté entre 3.5 y 4.5 es del 84%. Con estos datos, y por razones prácticas se concluyó que el exponente de 4 era un valor razonable en esa ecuación. Javier Garzás ©, Introducción a la Estimación Software 19
  20. 20. PARÁMETRO DE LA PRODUCTIVIDAD (PP) Se obtiene por Calibración a partir de sistemas ya concluidos. Producto = PP * (Esfuerzo / B) (1/3) * Tiempo (4/3) PP = Producto / ( (Esfuerzo / B) (1/3) * Tiempo (4/3) ) Se obtiene calibrando sistemas terminados. Por ejemplo, dado un sistema de 30.000 líneas de Cobol, finalizado en 17 meses con un gasto de recursos de 146 personas-mes, tenemos Parámetro de productividad = (SLOC)/(Esfuerzo/B)(1/3) · Tiempo(4/3) = = 30.000 /(12.17/0.28)(1/3) (1.42)(4/3). Javier Garzás ©, Introducción a la Estimación Software 20
  21. 21. PARÁMETRO DE LA PRODUCTIVIDAD (PP)Se calculó el PP de los sistemas registrados en QSM, estos se grupan según el tipo de sistema... Javier Garzás ©, Introducción a la Estimación Software 21
  22. 22. UTILIZACIÓN DE LA ECUACIÓN PARA LA ESTIMACIÓN La utilización es estimar tiempo y esfuerzo al comienzo de un nuevo proyecto. Producto = PP * (Esfuerzo / B) (1/3) * Tiempo (4/3) q La ecuación del software debe estimar el Tiempo de desarrollo (T) y Esfuerzo de desarrollo (E). Dos incognitas en la ecuación. Soluciones: q Determinista q Simulación q Programación Lineal q Se deben conocer el (PI) PP de la organización mediante proyectos anteriores y una estimación del Producto (LDC)). Javier Garzás ©, Introducción a la Estimación Software 22
  23. 23. SOLUCIÓN DETERMINISTA:MODELO DE PROCESO DE NORDENBasandose en datos históricos, se estudiaron 20 proyectos, Norden comprobó que: q Los procesos de desarrollo de software tienen 5 fases. q Tienen un comportamiento, en cuanto a la producción similar a una curva de Rayleigh. q La cola de la curva se debe al mantenimiento. Javier Garzás ©, Introducción a la Estimación Software 23
  24. 24. MODELO DE PROCESO DE NORDEN Pico de esfuerzo en el mes 7 requiere 5 personas, Pocas personas al comienzo, CURVA DE RAYLEIGH 5,0 4,5 4,0 3,5 PERSONAS MES 3,0 2,5 2,0 1,5 1,0 0,5 0,0 0 5 10 15 20 25 30 MESES Javier Garzás ©, Introducción a la Estimación Software 24
  25. 25. MODELO DE PROCESO DE NORDENRequirements Design Code Test Maintenance CURVA DE RAYLEIGH 5,0 4,5 4,0 3,5 PERSONAS MES 3,0 2,5 2,0 1,5 1,0 0,5 0,0 0 5 10 15 20 25 30 MESES Javier Garzás ©, Introducción a la Estimación Software 25
  26. 26. PUTNAM OBSERVÓ QUEq El momento en que la curva de Rayleigh toma su máximo valor correspondea las pruebas de sistema – entrega del productoq Despues de las pruebas de sistema el número de personas bajaq Aproximadamente el 39% del área está a la izquierda del tiempo máximo dedesarrolloq El esfuerzo hasta ese momento (Ed) es el 39% del esfuerzo total. Esfuerzo de Desarrollo (Ed) = Esfuerzo Total (E) * 0.39 => E = Ed / 0.39 Javier Garzás ©, Introducción a la Estimación Software 26
  27. 27. PUTNAM OBSERVÓ QUEq Parámetro de incremento de personal (PIP)q Relación entre Esfuerzo total (E) y el tiempo de desarrollo (td) PIP = E / (Td)3 => E = PIP * (Td)3 dPIP/dt = - 3 * E/ (Td)4q PIP (potencia-hombre o manpower), valor que se conoce al principio delproceso. Javier Garzás ©, Introducción a la Estimación Software 27
  28. 28. Javier Garzás ©, Introducción a la Estimación Software 28
  29. 29. PUTNAM OBSERVÓ QUE Esfuerzo Total (E) = Esfuerzo de Desarrollo (Ed) / 0.39 = PIP * (Td)3 Javier Garzás ©, Introducción a la Estimación Software 29
  30. 30. La decisión de aumentar rápidamente el personal deldesarrollo (PIP) de un proyecto tiene mas efecto en el coste y el esfuerzo (E) que en el tiempo (T). Javier Garzás ©, Introducción a la Estimación Software 30
  31. 31. CONSIDERACIONES AL MODELO DE PUTNAMq El modelo de Putnam muestra una extrema penalización a la hora decomprimir tiemposq El modelo de Putnam “gratifica” la expansión del tiempoq El modelo de Putnam trabaja razonablemente bien con sistemas grandesq El modelo de Putnam sobre estima mucho el esfuerzo en proyectos depequeño y medio tamaño Javier Garzás ©, Introducción a la Estimación Software 31
  32. 32. EXPERIENCIASq Nosotros utilizamos la herramienta de “Construx” Javier Garzás ©, Introducción a la Estimación Software 32
  33. 33. EXPERIENCIAS Curva de Rayleigh en la realidadManpower (m) t Becario enfermo Caída en producción Caída en producción Caída en producción Javier Garzás ©, Introducción a la Estimación Software 33
  34. 34. Use Cases Function Points Estimación del Tamaño
  35. 35. The Use Case Points Estimation q The Use Case Points Estimation Method (1993) fué desarrollado por G. Karner. q Método inspirado en Function Point method (Albrech) and MKII. q El método se evaluó en: q Mogul AS q Cap Gemini Ernst & Young q IBM q Student projects at NTNU, Trondheim Javier Garzás ©, Introducción a la Estimación Software 35
  36. 36. The Use Case Points Estimation Nosotros hemos seleccionado este método por: q  Probado q  UCFP basado en Function Points q  Function Points son antiguos UCFP más adaptado a nuevos sistemas q  Nuestra metodología está dirigida por casos de uso q  Putman complementa el modelo Javier Garzás ©, Introducción a la Estimación Software 36
  37. 37. PRE REQUISITO PARA UTILIZAR EL MÉTODO CASOS DE USO Y NIVEL DE DETALLE El modelo de casos de uso debe ser descrito a un nivel de detalle apropiado Javier Garzás ©, Introducción a la Estimación Software 37
  38. 38. CASOS DE USO “A use case is a narrative document that describes the sequence of events of an actor (an external agent) using a system to complete a process (Jacobson92) An actor represents a role that the user can play with regard to the system. A use case represents an interaction between an actor and the system.” Javier Garzás ©, Introducción a la Estimación Software 38
  39. 39. EJEMPLO Use Case Name: Place Order Short description: The customer provides address information and a list of product codes. The system confirms the order. Basic flow of events: 1.  Customer enters name and address 2.  Customer enters product codes for items he wishes to order 3.  The system will supply a product description and price for each item 4.  The system will keep a running total of items ordered as they are entered 5.  The customer enters credit card information 6.  The system validates the credit card information 7.  The system issues a receipt to the customer Alternative flow of events: 3.1 The product is out of stock: 3.1.1 The systems informs the customer that the product can not be ordered. 6.1 The credit card is invalid 6.1.1 The system informs the customer that his credit card is invalid 6.1.2 The customer can enter credit card information again or cancel the order. Pre-Conditions: The customer is logged on to the system Post-Conditions: The order has been submitted Javier Garzás ©, Introducción a la Estimación Software 39
  40. 40. MÉTODO Use cases Actors categorizados categorizados según según complejidad complejidad Unadjusted Use Case Technical Factors Environmental Factors Point (UUCP) (TCF) (EF) USE CASE POINTS (UCP) ESTIMATION Javier Garzás ©, Introducción a la Estimación Software 40
  41. 41. Unadjusted Use Case Point (UUCP) 1º) Cada actor categorizado según complejidad y peso ACTOR TYPE WEIGHT Simple (another system with 1 defined API) Average (interaction through a 2 protocol such as TCP/ IP) Complex (interaction through a 3 GUI or Web Page) Javier Garzás ©, Introducción a la Estimación Software 41
  42. 42. Unadjusted Use Case Point (UUCP) 2º) La complejidad de los UC es medida en número de transacciones Num of Transactions (use case USE CASE TYPE steps, including secondary WEIGHT scenarios) Simple 3 or minor 1 Average 4 to 7 2 Complex 7 or major 3 Javier Garzás ©, Introducción a la Estimación Software 42
  43. 43. Unadjusted Use Case Point (UUCP) 3º) Los “unadjusted use case points” se calculan añadiendo los pesos por actor y caso de uso ACTOR WEIGHT USE CASE WEIGHT Actor 1 ACT_w1 UC 1 UC_w1 Actor 2 ACT_w2 UC 2 UC_w2 Actor n ACT_wn UC m UC_wm UNADJUSTED USE CASE POINTS (UUCP) N M ∑ act _ wm + ∑ 1 1 uc _ wm Javier Garzás ©, Introducción a la Estimación Software 43
  44. 44. FACTORES TÉCNICOS4º) Los “unadjusted use case points” se ajustan en base a 13 factores Influence (0 = no influence; 3 Factor Description Weight Resultant = average; 5 strong) T1 Distributed System 2 n1 r1 = 2*n1 T2 Response adjectives 2 n2 r2 = 2*n2 T3 End-user efficiency 1 n3 r3 = 1*n3 T4 Complex processing 1 n4 r4 = 1*n4 T5 Reusable code 1 n5 r5 = 1*n5 T6 Easy to install 0,5 n6 r6 = 0,5*n6 T7 Easy to use 0,5 n7 r7 = 0,5*n7 T8 Portable 2 n8 r8 = 2*n8 T9 Easy to change 1 n9 r9 = 1*n9 T10 Concurrent 1 n10 r10 = 1*n10 T11 Security features 1 n11 r11 = 1*n11 T12 Access for third parties 1 n12 r12 = 1*n12 T13 Special training required 1 n13 r13 = 1*n13 TECHNICAL FACTORS (TCF) r13 0,6 + (0,01* ∑r1 ) Javier Garzás ©, Introducción a la Estimación Software 44
  45. 45. FACTORES DE ENTORNO 5º) Los “unadjusted use case points” se ajustan en base a 8 factores Influence (0 = no influence; 3 Factor Description Weight Resultant = average; 5 strong) F1 Familiar with RUP 1,5 n1 r1 = 1,5*n1 F2 Application experience 0,5 n2 r2 = 0,5*n2 F3 Object-oriented experience 1 n3 r3 = 1*n3 F4 Lead analyst capability Motivation 0,5 n4 r4 = 0,5*n4 F5 Motivation 1 n5 r5 = 1*n5 F6 Stable requirements 2 n6 r6 = 2*n6 F7 Part-time workers -1 n7 r7 = -1*n7 F8 Difficult programming languaje 2 n8 r8 = 2*n8 ENVIROMENT FACTORS (EF) r8 1,4 + (−0,03 * ∑r1 ) Javier Garzás ©, Introducción a la Estimación Software 45
  46. 46. PUNTOS CASO DE USO USE CASE POINTS (UCP) = UUCP * TCF * EF Javier Garzás ©, Introducción a la Estimación Software 46
  47. 47. PRODUCTIVIDAD ESTIMATE = UCP * Productivity factor Javier Garzás ©, Introducción a la Estimación Software 47
  48. 48. FACTOR DE PRODUCTIVIDAD APROXIMACIONES Karner propone 20 horas por use case point Barnerjee “field experience has show that effort can range from 15 to 30 hours per use case point” Javier Garzás ©, Introducción a la Estimación Software 48
  49. 49. Jones’ First-Order Estimation Practice Take the function-point total and raise it to the appropriate power. Kind of Software Best in Class Average Worst in Class Systems 0.43 0.45 0.48 Business 0.41 0.43 0.46 Shrink-wrap 0.39 0.42 0.45 Example 350 function points Average shrink-wrap software organization 3500, 42 ≈ 12months Javier Garzás ©, Introducción a la Estimación Software 49
  50. 50. Putman Model (our next step) 2 a = 1/2*td2 p(t) = 2.a.Effort.t . e-atInitial Slope= 2.a.Effort ∝ ∫0 p(t)dta = speed-up factor = Effort 0 td= 1/√2a Javier Garzás ©, Introducción a la Estimación Software 50
  51. 51. AJUSTE DE FACTORES A NUESTRO CASO CONCRETO Productivity Factor, hemos validado el rango pero necesitamos ajustarlo, con datos históricos. Por el momento hay desviación. Enviroments Factors, necesitamos ajustarlos a nuestra compañía, estos son elementos “vivos” y mejorarán con la madurez de la organización, más productivo (CMM). Influence (0 = no influence; 3 Factor Description Weight Resultant = average; 5 strong) F1 Familiar with RUP 1,5 n1 r1 = 1,5*n1 F2 Application experience 0,5 n2 r2 = 0,5*n2 F3 Object-oriented experience 1 n3 r3 = 1*n3 F4 Lead analyst capability Motivation 0,5 n4 r4 = 0,5*n4 F5 Motivation 1 n5 r5 = 1*n5 F6 Stable requirements 2 n6 r6 = 2*n6 F7 Part-time workers -1 n7 r7 = -1*n7 F8 Difficult programming languaje 2 n8 r8 = 2*n8 Use Cases, necesitamos unificar más en todos los proyectos Javier Garzás ©, Introducción a la Estimación Software 51
  52. 52. CONSIDERACIONESq Son más dificiles de comparar con otras organizaciones... pero no nos importaestoq Un valor muy importante que hemos obtenido es que ahora tenemos un“número” que nos dice el “tamaño del proyecto”q Se observa de manera clara como las mejoras en procesos, etc., mejoran laproductividad Javier Garzás ©, Introducción a la Estimación Software 52
  53. 53. CONSIDERACIONES 20%Sobre/Bajo ProcentajeDe Esfuerzo Estimado 0% -145% Sin Datos Históricos Con Datos Históricos Varianción entre -145% to +20% Varianción entre +20% to -20% (Mayormente en niveles 1 y 2 CMM) (Nivel 3) Fuente: 120 Projects in Boeing Information Systems Javier Garzás ©, Introducción a la Estimación Software 53
  54. 54. PRINCIPIOS, RECOMENDACIONES, CONSEJOS Y CONCLUSIONES
  55. 55. PRINCIPIOS Y MEJORES PRÁCTICASq Evitar estimaciones improvisadasq Dedicar tiempo a estimarq Usar datos de proyectos anteriores. Comparar todo con sus datos históricos.q Usar estimaciones basadas en los desarrolladoresq Revisar las estimacionesq Estimar a bajo nivel de detalleq No omitir las tareas comunesq Usar herramientas de estimación (Excel)q Usar diferentes técnicas, diferentes expertosq Cambiar las prácticas de estimación a la vez que el proyecto avanza Source: McConnell S. Rapid Development. 1996. Javier Garzás ©, Introducción a la Estimación Software 55
  56. 56. PRINCIPIOS Y MEJORES PRÁCTICAS ESTIMACIÓN DE PROYECTO ≠ ESTIMACIÓN SOFTWARE Hardware, software, comunicaciones, etc. Source: McConnell S. Rapid Development. 1996. Javier Garzás ©, Introducción a la Estimación Software 56
  57. 57. PRINCIPIOS Y MEJORES PRÁCTICAS q La exactitud de la estimación es directamente proporcional a la definición del producto. Antes de la especificación de de requisitos el producto es muy bago q Usar rangos para estimar de forma gradual: •  Plus-or-minus qualifiers •  Coarse dates and time periods “6 months, +3 months, -2 months” “3rd quarter 97” •  Ranges •  Confidence factors “5-9 months” April 1 5% •  Risk quantification May 1 50% “6 months... •  Cases +1 month for late subcontractor, Best case April 1 +0.5 month for staff sickness, Planned case May 15 etc...” Worst case July 15 Source: McConnell S. Rapid Development. 1996. Javier Garzás ©, Introducción a la Estimación Software 57
  58. 58. MUERTES POR ESTIMACIÓN... q Estimar cuánto tiempo antes de saber qué q Asumir que las estimaciones más fiables vienen de la gente que “mas grita” q Crear una estimaión para un nuevo proyecto comparandolo con uno anterior… en el que se trabajó fines de semana, hasta las 4 am, etc. q Asumir que el departamento de ventas es el mejor estimando. q Crear estimaciones olvidando formación, reuniones, fiestas, vacaciones, tiempos del cliente Source: McConnell S. Rapid Development. 1996. Javier Garzás ©, Introducción a la Estimación Software 58
  59. 59. “LINES OF CODE”q La mayoría de los modelos se basan en las KLOCq Problemas: q Equivalencia: entre instru. fuente de diferentes lenguajes q Esfuerzo: entre uso de diferentes lenguajes q Ámbito: ¿Qué es una LOC? q La medida de LOC penaliza a los lenguajes de alto nivel q El coste por defecto o coste para escribir una línea de código penaliza a los programas hechos con calidad Javier Garzás ©, Introducción a la Estimación Software 59
  60. 60. MUERTES POR ESTIMACIÓN... q  Asumir que estimar por abajo no tiene impacto q Boehm observó que hay un límite más allá del cual el tiempo no puede reducirse añadiendo más personas, entorno al 25% del tiempo ideal Non-linear impact due to planning errors, upstream defects, Linear impact due to high-risk practices Cost Effort Parkinson’s Law Schedule Underestimation Overestimation < 100% 100% >100% Target as a Percentage of Nominal Estimate Brooks Law: Adding manpower to a late software project makes it later. Fred Brooks, The Mythical Man- Month Source: McConnell S. Rapid Development. 1996. Javier Garzás ©, Introducción a la Estimación Software 60
  61. 61. Political disorders can be quickly healed if they are seen well in advance; when, for lack of a diagnosis, they are allowed to grow in such a way that everyone can recognise them, remedies are too late. Niccolo Machiavelli, Il Principe, 1513 Javier Garzás ©, Introducción a la Estimación Software 61
  62. 62. INTRODUCCIÓN A LA ESTIMACIÓN Dr. D. Javier Garzás Parra Project Manager / Process Engineering Leader mCentric javier.garzas@m-centric.com or jgarzas@gmail.com www.javiergarzas.com Valladolid, 8 de Junio de 2005

×