Estimación temprana de proyectos Software.

Alfonso Tienda Braulio

Twitter: @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 (InteractiveProductivityand QualityEstimator, rebautizada posteriormente como DevelopmentPlanningSystem) [Jones 1977]

• 1975: Publicación de ―Themythicalman-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 Boehmpublica su libro Software EngineeringEconomics(Boehm 1981), introduce COCOMO (así como el desarrollo espiral)

• 1982 Tom DeMarcopublica 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 tofunctionpoints), SPQR/20 y SPR (featurepoints)

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 lasestimaciones se realizan al principio

del ciclo de vida. Tienesentido hasta

quenosdamoscuentaqueestimamos sin tenerclaros los

requerimientos. La estimación se hace, por lo tanto, en

el momentoequivocado. [Pressman 1992]

La estimación de software: Algunos hechos

• La mayoría de lasestimaciones de software son realizadaspor la gerencia o por marketing/ventas, no porla gentequeva a realizar o supervisar los trabajos. Por lo tanto, estánhechaspor la genteequivocada. [CASE 1991]

• Las estimacionesraravez se ajustan a medidaqueavanzael proyecto, por lo quelasestimacionesquefueronhechasen el momentoequivocadopor la genteequivocada 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:

o Code&Pray

o MakeTests&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

o Unitarios (imprescindibles)

o 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 (excels internas, 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 – PlanningPoker

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

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

o (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 1Software individual 1No procedural

2Módulo 2Shareware 2Web applet

3Módulo reutilizable 3Software académico 3Batch

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

5Prototipo evolucionable 5 Interno - Multilocalización 5

GUI interactivo o basado en

Web

6Programa independiente 6

Proyecto contratado -

Civil 6Batch - DB

7Componente de sistema 7Time Sharing 7BD - Interactivo

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

9Nuevo sistema 9 Internet 9Matemático

10Sistema Compuesto 10SaaS 10Sistemas

11Bundle 11Comunicaciones

12Comercial a la venta 12Control de proceso

13Contrato de outsourcing 13Sistema fiable

14Contrato gubernamental 14Embebido

15Contrato militar 15Procesamiento de imagen

16Multimedia

17Robótica

18 Inteligencia Artificial

19Red neuronal

20Híbrido

Programa independiente = 6

Interno, 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

o Java 50:1

o SmallTalk, Ruby 15:1

ScopeCreep: 2% mensual. Mínimo 15%

Documentación: FP1,15

Número de casos de TEST: FP1,2

Bibliografía

• [Aaron 1970] Aaron, JD ―EstimatingResourcesforlargeprogrammingsystems‖, Software EngineeringTechinques, NATO ConferenceReport, October 1969, April1970 p.68-84

• [Brooks, 1975] Brooks, Fred Themythicalman-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.