Post on 05-Jul-2015
description
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.