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 (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. 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. 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. 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. 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:
• 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. 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 – 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. 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. Técnicas de estimación
Alcance 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. 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. 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.