Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Estimación temprana de proyectos software #pmot #pmlat

1,269 views

Published on

Presentación de Alfonso Tienda (@afoone) en las IX Jornadas de gestión de proyectos del PMI Valencia

Published in: Business
  • Login to see the comments

  • Be the first to like this

Estimación temprana de proyectos software #pmot #pmlat

  1. 1. Estimación temprana de proyectos Software. Alfonso Tienda Braulio Twitter: @afoone @iprocuratio linkedIn: http://www.linkedin.com/in/alfonsotiendaIX jornadas PMI Valencia – 29 de noviembre 2012
  2. 2. La estimación de software: Primeros pasos• 50’s y 60’s : Estimación manual basada en la experiencia del programador• 1969: Joel Aaron de IBM [Aaron 1970] realiza una presentación sobre estimación de software en la Otan. Barry Boehm(TRW) y Larry Putnam (US Army) empiezan sus trabajos al respecto• 1973: Charles Turk y Capers Jones construyen la primera herramienta automática de costes software (Interactive Productivity and Quality Estimator, rebautizada posteriormente como Development Planning System) [Jones 1977]• 1975: Publicación de “The mythical man-month” de Frederick Brooks, [Brooks 1975] – “Asignar más programadores a un proyecto atrasado sólo lo atrasará más”; la fórmula de la comunicación grupal – El prototipado – Captura la necesidad de herramientas de costes de software
  3. 3. La estimación de software: Nacen las técnicas• 1975: Allan Albrecht trabaja en la primera versión de los puntos de función de IBM, basados en Inputs, Outputs, Inquires, Logical Files e Interfaces• 1977: PRICE-S, primera herramienta comercial de estimación de costes, de Frank Freiman, todavía a la venta.• 1979: Allan Albrecht publica sus trabajos sobre puntos de función [Albrecht 1979]• 1981: Barry Boehm publica su libro Software Engineering Economics (Boehm 1981), introduce COCOMO (así como el desarrollo espiral)• 1982 Tom DeMarco publica su versión de puntos de función (De Marco 1981)• 1983 Charles Symons publica Mark II, también de puntos de función (Symons 1983)• 1984-1986 Trabajos de Allan Albrecht y Capers Jones en Backfiring (LOC to function points), SPQR/20 y SPR (feature points)
  4. 4. La estimación de software: Algunos hechos• Las dos principales razones para que un proyecto esté fuera de control son la mala estimación y la inestabilidad de los requerimientos. [Cole 1995] [Van Genuchten 1991]• La mayoría de las estimaciones se realizan al principio del ciclo de vida. Tiene sentido hasta que nos damos cuenta que estimamos sin tener claros los requerimientos. La estimación se hace, por lo tanto, en el momento equivocado. [Pressman 1992]
  5. 5. La estimación de software: Algunos hechos• La mayoría de las estimaciones de software son realizadas por la gerencia o por marketing/ventas, no por la gente que va a realizar o supervisar los trabajos. Por lo tanto, están hechas por la gente equivocada. [CASE 1991]• Las estimaciones rara vez se ajustan a medida que avanza el proyecto, por lo que las estimaciones que fueron hechas en el momento equivocado por la gente equivocada no se corrijen.• Dado que las estimaciones son tan defectuosas, hay pocas razones para preocuparse cuando los proyectos de software no alcanzan los objetivos previstos. Pero todo el mundo está preocupado de todos modos.
  6. 6. La estimación de software: Algunos hechos• Hay una desconexión entre la dirección y sus programadores. En un estudio de investigación de un proyecto que no cumplió con sus estimaciones y fue visto por su gestión como un fracaso, los participantes técnicos lo veían como el proyecto más exitoso que habían trabajado jamás . [Linberg 1999]• La respuesta a un estudio de viabilidad es casi siempre SI.
  7. 7. La estimación de software: Problemática• La mayoría de los trabajos en base a estimaciones software se realizan sobre análisis completados• En ocasiones tenemos que hacer valoraciones tempranas – Valoraciones para licitaciones públicas en las cuales se nos presentan datos mínimos – Valoraciones estratégicas• No tenemos suficientes datos para realizar valoraciones mediante los modelos estándar• ¿Influyen las metodologías empleadas?
  8. 8. Estimación temprana: primeros pasos• Primer consejo: Como hemos visto antes, intentar no hacerla. Intentar negociar otro modelo si es posible. En proyectos internos, dejar claro el rango de error de la estimación estratégica.• Recabar la mayor cantidad de datos posible: – Hacer preguntas a los clientes, internos o externos. A los licitadores. Solicitar documentación. – Intentar que los técnicos aporten información (personas correctas)
  9. 9. Estimación temprana: mantenimiento de aplicaciones• Un consejo en cuanto al código legado: – Existen dos formas de evolucionar el código de otro: • Code & Pray • Make Tests & Modify – El dato más importante para evaluar la complejidad de evolucionar un sistema legado NO es la documentación (que suele estar obsoleta) sino la cobertura de TESTS (suele ser un dato objetivo)-> Pidámosla • Unitarios (imprescindibles) • Integración
  10. 10. Costes en PMI
  11. 11. Tras la EDT• Realizar una EDT tan precisa como nos sea posible, basada en el producto, no en las fases de desarrollo• Utilizar las técnicas de estimación que nos convengan en el desarrollo que hacemos (excels internas, tres puntos…). Realizarla de forma realista, descomponiendo el proyecto, no sus fases.• Corregir la estimación con factores de ajustes• Descomponer
  12. 12. Técnicas de estimación• Juicio de expertos – Agile – Planning Poker – Ascendente, en la medida de lo posible• Estimación Análoga: LOC’s – Cuando tenemos un sistema con el que compararnos Tamaño en líneas de LOC por Esfuerzo de Esfuerzo de no Esfuerzo total código hora codificación Esfuerzo en Test % codificación % (horas) LOC netas por hora 100 15,15 6,60 40% 40% 11,88 8,42 1.000 13,26 75,41 50% 80% 173,45 5,77 10.000 11,36 880,28 75% 100% 2.420,77 4,13 100.000 9,09 11.001,10 100% 150% 38.503,85 2,60 1.000.000 7,58 131.926,12 125% 150% 494.722,96 2,02
  13. 13. Técnicas de estimación– Tres valores. Según mi experiencia, le daría más peso al caso peor, especialmente en entornos de incertidumbre.– Mínima información: Estimación super-rápida de Puntos de Función • (Alcance + Clase + Tipo)2.35
  14. 14. Técnicas de estimaciónAlcance Clase Tipo– Tres valores. Según mi experiencia, le daría más 1 Subrutina, método, clase 1 Software individual 1 No procedural 2 Módulo 2 Shareware 2 Web applet 3 Módulo reutilizable 3 Software académico 3 Batch peso al caso peor, especialmente en entornos de 4 Prototipo desechable 5 Prototipo evolucionable 4 Interno - Ubicación única 5 Interno - Multilocalización 4 Interactivo 5 GUI interactivo o basado en Web incertidumbre. 6 Programa independiente 7 Componente de sistema 6 Proyecto contratado - Civil 7 Time Sharing 6 Batch - DB 7 BD - Interactivo 8 Versión del sistema 8 Militar 8 Cliente / Servidor– Mínima información: Estimación super-rápida de 9 Nuevo sistema 10 Sistema Compuesto 9 Internet 10 SaaS 9 Matemático 10 Sistemas Puntos de Función 11 Bundle 12 Comercial a la venta 11 Comunicaciones 12 Control de proceso 13 Contrato de outsourcing 13 Sistema fiable 14 Contrato gubernamental 14 Embebido 15 Contrato militar 15 Procesamiento de imagen 16 Multimedia Programa independiente = 6 17 Robótica 18 Inteligencia Artificial Interno, ubicación única = 4 19 Red neuronal Cliente servidor = 6 20 Híbrido (6+4+6)2,35 = 891
  15. 15. La “A” de Ajustes– Todos los ajustes han de ser tenidos en cuenta y corregidos especialmente teniendo en cuenta el cliente finalç– Líneas de código <-> PF • Java 50:1 • SmallTalk, Ruby 15:1– Scope Creep: 2% mensual. Mínimo 15%– Documentación: FP1,15– Número de casos de TEST: FP1,2
  16. 16. Bibliografía• [Aaron 1970] Aaron, JD “Estimating Resources for large programming systems”, Software Engineering Techinques, NATO Conference Report, October 1969, April 1970 p.68-84• [Brooks, 1975] Brooks, Fred The mythical man-month, Addison-Weley, Reading, Mass. 1975 rev. 1995• [CASE, 1991] "CASE/CASM Industry Survey Report." HCS, Inc., P.O. Box 40770, Portland, OR.• [Cole 1995] Cole, Andy. 1995. "Runaway Projects—Causes and Effects." Software World (UK) 26, no. 3.• [Jones 1977] Jones, Capers. “Program Quality and Programmer Productivity. IBM Technical Report TR 02.766. San Jose, CA, Jan 1977• [Linberg 1999] Linberg, K. R. 1999. "Software Developer Perceptions about Software Project Failure: A Case Study." Journal of Systems and Software 49, nos. 2/3, Dec. 30• [Pressman 1992] Pressman, Roger S. 1992. "Software Project Management: Q and A." American Programmer, Dec.• [Van Genuchten 1991]Van Genuchten, Michiel. 1991. "Why Is Software Late?" IEEE Transactions on Software Engineering, June.

×