SlideShare una empresa de Scribd logo
1 de 16
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 (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
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 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.
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 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
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

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

Más contenido relacionado

Similar a Estimación temprana de proyectos software #pmot #pmlat @iprocuratio

Administración de proyectos de desarrollo de software
Administración de proyectos de desarrollo de softwareAdministración de proyectos de desarrollo de software
Administración de proyectos de desarrollo de software
jose_macias
 
Oportunidad de negocio con Windows 7
Oportunidad de negocio con Windows 7Oportunidad de negocio con Windows 7
Oportunidad de negocio con Windows 7
MICProductivity
 
Aspect Oriented Programming Middleware
Aspect Oriented Programming MiddlewareAspect Oriented Programming Middleware
Aspect Oriented Programming Middleware
Lenin Lozano
 
El rol de mediciones formales en proyectos de tecnología
El rol de mediciones formales en proyectos de tecnologíaEl rol de mediciones formales en proyectos de tecnología
El rol de mediciones formales en proyectos de tecnología
GeneXus Consulting
 

Similar a Estimación temprana de proyectos software #pmot #pmlat @iprocuratio (20)

Administración de proyectos de desarrollo de software
Administración de proyectos de desarrollo de softwareAdministración de proyectos de desarrollo de software
Administración de proyectos de desarrollo de software
 
Meetup Oracle Technology MAD_BCN: 6.2 DevOps y DataOps
Meetup Oracle Technology MAD_BCN: 6.2 DevOps y DataOpsMeetup Oracle Technology MAD_BCN: 6.2 DevOps y DataOps
Meetup Oracle Technology MAD_BCN: 6.2 DevOps y DataOps
 
Cocomo basico
Cocomo basicoCocomo basico
Cocomo basico
 
Ingenieria software
Ingenieria softwareIngenieria software
Ingenieria software
 
Tecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareTecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto software
 
MODELO COCOMO (INGENIERA DE SOFTWARE)
MODELO COCOMO (INGENIERA DE SOFTWARE)MODELO COCOMO (INGENIERA DE SOFTWARE)
MODELO COCOMO (INGENIERA DE SOFTWARE)
 
Diseño orientado a objeto
Diseño orientado a objetoDiseño orientado a objeto
Diseño orientado a objeto
 
Operational Data Graph: Un enfoque innovador para optimizar las operaciones d...
Operational Data Graph: Un enfoque innovador para optimizar las operaciones d...Operational Data Graph: Un enfoque innovador para optimizar las operaciones d...
Operational Data Graph: Un enfoque innovador para optimizar las operaciones d...
 
Oportunidad de negocio con Windows 7
Oportunidad de negocio con Windows 7Oportunidad de negocio con Windows 7
Oportunidad de negocio con Windows 7
 
Nerdear.la 2018 | Journey to Stability - Cómo reducimos costos y aumentamos l...
Nerdear.la 2018 | Journey to Stability - Cómo reducimos costos y aumentamos l...Nerdear.la 2018 | Journey to Stability - Cómo reducimos costos y aumentamos l...
Nerdear.la 2018 | Journey to Stability - Cómo reducimos costos y aumentamos l...
 
Estimacion de Proyectos, Ingeniería de Software
Estimacion de Proyectos, Ingeniería de SoftwareEstimacion de Proyectos, Ingeniería de Software
Estimacion de Proyectos, Ingeniería de Software
 
Aspect Oriented Programming Middleware
Aspect Oriented Programming MiddlewareAspect Oriented Programming Middleware
Aspect Oriented Programming Middleware
 
Estimación de Proyectos de Software
Estimación de Proyectos de SoftwareEstimación de Proyectos de Software
Estimación de Proyectos de Software
 
Construyendo tu propio laboratorio de pentesting
Construyendo tu propio laboratorio de pentestingConstruyendo tu propio laboratorio de pentesting
Construyendo tu propio laboratorio de pentesting
 
¿Quién va a desarrollar las Apps del futuro? (aviso: no serán los programador...
¿Quién va a desarrollar las Apps del futuro? (aviso: no serán los programador...¿Quién va a desarrollar las Apps del futuro? (aviso: no serán los programador...
¿Quién va a desarrollar las Apps del futuro? (aviso: no serán los programador...
 
16 Cast Software Solo Pruebas 2009
16 Cast Software Solo Pruebas 200916 Cast Software Solo Pruebas 2009
16 Cast Software Solo Pruebas 2009
 
El rol de mediciones formales en proyectos de tecnología
El rol de mediciones formales en proyectos de tecnologíaEl rol de mediciones formales en proyectos de tecnología
El rol de mediciones formales en proyectos de tecnología
 
Desarrollo de Software Guiado por Pruebas
Desarrollo de Software Guiado por PruebasDesarrollo de Software Guiado por Pruebas
Desarrollo de Software Guiado por Pruebas
 
Metodologías Ágiles en la Práctica
Metodologías Ágiles en la PrácticaMetodologías Ágiles en la Práctica
Metodologías Ágiles en la Práctica
 
Procesos de Ingenieria de Software
Procesos de Ingenieria de SoftwareProcesos de Ingenieria de Software
Procesos de Ingenieria de Software
 

Último

Fundamentos_de_ADMINISTRACION_CONCEPTOS.pdf
Fundamentos_de_ADMINISTRACION_CONCEPTOS.pdfFundamentos_de_ADMINISTRACION_CONCEPTOS.pdf
Fundamentos_de_ADMINISTRACION_CONCEPTOS.pdf
schicaizas
 
MENTORÍA HABILIDADES BLANDAS COMUNICACIÓN EFECTIVA, EMPATÍA Y GESTIÓN DE CONF...
MENTORÍA HABILIDADES BLANDAS COMUNICACIÓN EFECTIVA, EMPATÍA Y GESTIÓN DE CONF...MENTORÍA HABILIDADES BLANDAS COMUNICACIÓN EFECTIVA, EMPATÍA Y GESTIÓN DE CONF...
MENTORÍA HABILIDADES BLANDAS COMUNICACIÓN EFECTIVA, EMPATÍA Y GESTIÓN DE CONF...
Oxford Group
 
Informe_Técnico_-_PPLA_Marzo_2024,_Area_Electricidad_Rev_3.docx
Informe_Técnico_-_PPLA_Marzo_2024,_Area_Electricidad_Rev_3.docxInforme_Técnico_-_PPLA_Marzo_2024,_Area_Electricidad_Rev_3.docx
Informe_Técnico_-_PPLA_Marzo_2024,_Area_Electricidad_Rev_3.docx
CandoCuya1
 
Explicación de los objetivos del Modulo de compras
Explicación de los objetivos del Modulo de comprasExplicación de los objetivos del Modulo de compras
Explicación de los objetivos del Modulo de compras
Jose Diaz
 
CV MAYLI cv_Mayli Rojas Duran cv_Mayli Rojas Duran
CV MAYLI cv_Mayli Rojas Duran cv_Mayli Rojas DuranCV MAYLI cv_Mayli Rojas Duran cv_Mayli Rojas Duran
CV MAYLI cv_Mayli Rojas Duran cv_Mayli Rojas Duran
MayliRD
 

Último (20)

Fundamentos_de_ADMINISTRACION_CONCEPTOS.pdf
Fundamentos_de_ADMINISTRACION_CONCEPTOS.pdfFundamentos_de_ADMINISTRACION_CONCEPTOS.pdf
Fundamentos_de_ADMINISTRACION_CONCEPTOS.pdf
 
catalogo de rodamientos nks linea pesada
catalogo de rodamientos nks linea pesadacatalogo de rodamientos nks linea pesada
catalogo de rodamientos nks linea pesada
 
BPM-N_Administración Servicio y Calidad.pdf
BPM-N_Administración Servicio y Calidad.pdfBPM-N_Administración Servicio y Calidad.pdf
BPM-N_Administración Servicio y Calidad.pdf
 
NORMA TÉCNICA COLOMBIANA NTC 1500 actualizada 2023.pptx
NORMA TÉCNICA COLOMBIANA NTC 1500 actualizada 2023.pptxNORMA TÉCNICA COLOMBIANA NTC 1500 actualizada 2023.pptx
NORMA TÉCNICA COLOMBIANA NTC 1500 actualizada 2023.pptx
 
MANUAL PROCEDIMIENTOS BOMBEROS SOPO CUNDI
MANUAL PROCEDIMIENTOS BOMBEROS SOPO CUNDIMANUAL PROCEDIMIENTOS BOMBEROS SOPO CUNDI
MANUAL PROCEDIMIENTOS BOMBEROS SOPO CUNDI
 
DOC-20240503-WA0003. cadena de valor.pdf
DOC-20240503-WA0003. cadena de valor.pdfDOC-20240503-WA0003. cadena de valor.pdf
DOC-20240503-WA0003. cadena de valor.pdf
 
MENTORÍA HABILIDADES BLANDAS COMUNICACIÓN EFECTIVA, EMPATÍA Y GESTIÓN DE CONF...
MENTORÍA HABILIDADES BLANDAS COMUNICACIÓN EFECTIVA, EMPATÍA Y GESTIÓN DE CONF...MENTORÍA HABILIDADES BLANDAS COMUNICACIÓN EFECTIVA, EMPATÍA Y GESTIÓN DE CONF...
MENTORÍA HABILIDADES BLANDAS COMUNICACIÓN EFECTIVA, EMPATÍA Y GESTIÓN DE CONF...
 
Informe_Técnico_-_PPLA_Marzo_2024,_Area_Electricidad_Rev_3.docx
Informe_Técnico_-_PPLA_Marzo_2024,_Area_Electricidad_Rev_3.docxInforme_Técnico_-_PPLA_Marzo_2024,_Area_Electricidad_Rev_3.docx
Informe_Técnico_-_PPLA_Marzo_2024,_Area_Electricidad_Rev_3.docx
 
mi Curriculum vitaebreendamaldonadosilvapdf
mi Curriculum vitaebreendamaldonadosilvapdfmi Curriculum vitaebreendamaldonadosilvapdf
mi Curriculum vitaebreendamaldonadosilvapdf
 
Explicación de los objetivos del Modulo de compras
Explicación de los objetivos del Modulo de comprasExplicación de los objetivos del Modulo de compras
Explicación de los objetivos del Modulo de compras
 
DISEÑO DE ESTRATEGIAS EN MOMENTOS DE INCERTIDUMBRE
DISEÑO DE ESTRATEGIAS EN MOMENTOS DE  INCERTIDUMBREDISEÑO DE ESTRATEGIAS EN MOMENTOS DE  INCERTIDUMBRE
DISEÑO DE ESTRATEGIAS EN MOMENTOS DE INCERTIDUMBRE
 
Operación y Apilador electrico en el trabajo
Operación y Apilador electrico en el trabajoOperación y Apilador electrico en el trabajo
Operación y Apilador electrico en el trabajo
 
CV MAYLI cv_Mayli Rojas Duran cv_Mayli Rojas Duran
CV MAYLI cv_Mayli Rojas Duran cv_Mayli Rojas DuranCV MAYLI cv_Mayli Rojas Duran cv_Mayli Rojas Duran
CV MAYLI cv_Mayli Rojas Duran cv_Mayli Rojas Duran
 
GRUPO 14-DIAPOSITIVAS DEL PROYECTO.pptx,
GRUPO 14-DIAPOSITIVAS DEL PROYECTO.pptx,GRUPO 14-DIAPOSITIVAS DEL PROYECTO.pptx,
GRUPO 14-DIAPOSITIVAS DEL PROYECTO.pptx,
 
NGANGAS_pdf.pdf9uhrg9hrg8hre8rg8rg4tg45g4
NGANGAS_pdf.pdf9uhrg9hrg8hre8rg8rg4tg45g4NGANGAS_pdf.pdf9uhrg9hrg8hre8rg8rg4tg45g4
NGANGAS_pdf.pdf9uhrg9hrg8hre8rg8rg4tg45g4
 
CURRICULUM VITAE-MARIELENA ANGIE SOPAN VIGO.pdf
CURRICULUM VITAE-MARIELENA ANGIE SOPAN VIGO.pdfCURRICULUM VITAE-MARIELENA ANGIE SOPAN VIGO.pdf
CURRICULUM VITAE-MARIELENA ANGIE SOPAN VIGO.pdf
 
OBRAS QUE NO NECESITAN PERMISO DE CONSTRUCCIÓN
OBRAS QUE NO NECESITAN PERMISO DE CONSTRUCCIÓNOBRAS QUE NO NECESITAN PERMISO DE CONSTRUCCIÓN
OBRAS QUE NO NECESITAN PERMISO DE CONSTRUCCIÓN
 
CURRICULUM VITAEMOISES PIZANGOTAPULLIMA .pdf
CURRICULUM VITAEMOISES PIZANGOTAPULLIMA .pdfCURRICULUM VITAEMOISES PIZANGOTAPULLIMA .pdf
CURRICULUM VITAEMOISES PIZANGOTAPULLIMA .pdf
 
Dinamica del plan contable general empresarial.pptx
Dinamica del plan contable general empresarial.pptxDinamica del plan contable general empresarial.pptx
Dinamica del plan contable general empresarial.pptx
 
CONTRATO DE TRABAJO EN COLOMBIA PPT.pptx
CONTRATO DE TRABAJO  EN COLOMBIA PPT.pptxCONTRATO DE TRABAJO  EN COLOMBIA PPT.pptx
CONTRATO DE TRABAJO EN COLOMBIA PPT.pptx
 

Estimación temprana de proyectos software #pmot #pmlat @iprocuratio

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