El documento aborda la evolución de la estimación en proyectos de software desde sus inicios en los años 50 y 60, resaltando la importancia de métodos y herramientas desarrolladas durante las décadas posteriores. Se observan problemáticas en las estimaciones, tales como su realización por personas inadecuadas y la falta de ajuste durante el ciclo del proyecto. Se ofrecen consejos prácticos para realizar estimaciones tempranas manteniendo la precisión y abordando normativas de desarrollo y mantenimiento de aplicaciones.

1. 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

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

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 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)

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 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]

5. La estimación de software: Algunos hechos
• La mayoría de lasestimaciones de software son
realizadaspor la gerencia o por marketing/ventas, no por
la gentequeva a realizar o supervisar los trabajos. Por lo
tanto, estánhechaspor la genteequivocada. [CASE 1991]
• Las estimacionesraravez se ajustan a medidaqueavanza
el proyecto, por lo quelasestimacionesquefueronhechas
en 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.

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. 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. 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. 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

10. Costes en PMI

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. 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 LOC por Esfuerzo de Esfuerzo en Test Esfuerzo de no Esfuerzo total
código hora codificación % 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. 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

14. Técnicas de estimación
Alcance Clase Tipo
 Subrutina, método,
Tres valores. Según 1 Software individual
1 clase mi experiencia, le daría más peso al caso
1 No procedural
peor, especialmente 3 Software académico de incertidumbre.
2 Módulo
3 Módulo reutilizable
en entornos
2 Shareware 2 Web applet
3 Batch
 Mínima información: 4Estimación única
4 Prototipo desechable Interno - Ubicación super-rápida de Puntos de
4 Interactivo
GUI interactivo o basado en
Función
5 Prototipo evolucionable 5 Interno - Multilocalización 5 Web
Proyecto contratado -
6 Programa independiente 6 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
Programa independiente = 6 15 Contrato militar 15 Procesamiento de imagen
Interno, ubicación única = 4 16 Multimedia
17 Robótica
Cliente servidor = 6 18 Inteligencia Artificial
(6+4+6)2,35 = 891 19 Red neuronal
20 Híbrido

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

16. Bibliografía
• [Aaron 1970] Aaron, JD ―EstimatingResourcesforlargeprogrammingsystems‖,
Software EngineeringTechinques, NATO ConferenceReport, October 1969, April
1970 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.