Estimación temprana de proyectos Software.

Alfonso Tienda BraulioTwitter: @afoone @iprocuratio

linkedIn: http://www.linkedin.com/in/alfonsotienda

IX jornadas PMI Valencia – 29 de noviembre 2012

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 (InteractiveProductivity 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

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 tofunction points), SPQR/20 y SPR (feature points)

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 tenerclaros los requerimientos. La estimación se hace, por lo tanto, en el momento equivocado. [Pressman 1992]

La estimación de software: Algunos hechos

• La mayoría de las estimaciones de software son realizadaspor la gerencia o por marketing/ventas, no por la gente queva a realizar o supervisar los trabajos. Por lo tanto, estánhechas 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.

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.

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?

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)

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

Costes en PMI

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 (excelsinternas, tres puntos…). Realizarla de forma realista, descomponiendo el proyecto, no sus fases.

• Corregir la estimación con factores de ajustes

• Descomponer

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 compararnosTamaño en

líneas de código

LOC por hora

Esfuerzo de codificación Esfuerzo en Test %

Esfuerzo de no codificación %

Esfuerzo total (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

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

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

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

4 Prototipo desechable 4 Interno - Ubicación única 4 Interactivo

5 Prototipo evolucionable 5 Interno - Multilocalización 5 GUI interactivo o basado en Web

6 Programa independiente 6 Proyecto contratado - Civil 6 Batch - DB

7 Componente de sistema 7 Time Sharing 7 BD - Interactivo

8 Versión del sistema 8 Militar 8 Cliente / Servidor

9 Nuevo sistema 9 Internet 9 Matemático

10 Sistema Compuesto 10 SaaS 10 Sistemas

11 Bundle 11 Comunicaciones

12 Comercial a la venta 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

17 Robótica

18 Inteligencia Artificial

19 Red neuronal

20 Híbrido

Programa independiente = 6Interno, ubicación única = 4

Cliente servidor = 6(6+4+6)2,35 = 891

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

Bibliografía

• [Aaron 1970] Aaron, JD “Estimating Resources for large programming systems”, Software Engineering Techinques, NATO Conference Report, October 1969, April1970 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.