Introduccin

La estimacin del tamao de un producto software es de gran utilidad para estimar costos
y dems recursos.

Propsito

Esta actividad tiene la finalidad de que reflexiones sobre la estimacin del tamao de un
producto de software y determinar la factibilidad de utilizar mtodos de estimacin como
Proxy o PROBE de acuerdo a los escenarios propuestos mediante casos de anlisis.

Instrucciones

1. Analiza Los siguientes dos escenarios.

Escenario 1:

Una empresa de software va a realizar su primer proyecto para un cliente determinado. Sin
embargo, la empresa no cuenta con datos histricos de proyectos anteriores.

Escenario 2:

Una empresa de software va a realizar un nuevo proyecto de software. La empresa ha

desarrollado varios proyectos con anterioridad y cuenta con los datos histricos de tamao
y tiempos de desarrollo de dichos proyectos. Sin embargo, para este nuevo proyecto, se
ha visto en la necesidad de contratar un nuevo equipo de desarrolladores para las tareas
de codificacin y pruebas unitarias.

b) La empresa podra realizar la estimacin del proyecto utilizando el mtodo PROXY?

Por qu? En el caso de la estimacin de tiempos a travs del mtodo PROBE, qu
recomendacin le daras y por qu?, por ejemplo, tomar la productividad de desarrollo ms
baja y con esa base estimar los tiempos.

3. Analiza el o los casos correspondientes e identifica el o los mtodos de estimacin que

consideres responden a las necesidades de cada caso.

4. Redacta una recomendacin en relacin con el uso del o los mtodos identificados.
Justifica tu recomendacin.
Contesta las siguientes preguntas sobre los escenarios anteriormente descritos.

a) En el escenario 1, la empresa debera utilizar el mtodo PROBE para estimar y planear

el trabajo? Por qu? Qu recomendacin le proporcionaras?
No ya que el mtodo PROBE, utiliza historiales basados en proyectos anteriores, adems
de que no se cuenta con estimaciones en base a mtodo proxy, el cual se divide en
proyectos pequeos que al sumarlo dan una estimacin ms precisa. As pues, no se podra
utilizar el mtodo PROBE, para este escenario. Personalmente recomendara el uso de un
mtodo paramtrico, los cuales realizan predicciones y aproximaciones al principio de vida
del volumen del software, como por ejemplo:
COCOMO (Constructive Cost Model) II, este modelo fue propuesto por primera vez en 1981,
por Boehm, en el cual supone una revisin y toma el tamao del software y un conjunto de
factores como entrada y estima el esfuerzo en personas por mes.

b) La empresa podra realizar la estimacin del proyecto utilizando el mtodo PROXY?

Por qu? En el caso de la estimacin de tiempos a travs del mtodo PROBE, qu
recomendacin le daras y por qu?, por ejemplo, tomar la productividad de desarrollo ms
baja y con esa base estimar los tiempos.

As es, ya que PROXY, se basa en los datos histricos y en la experiencia con respecto a
otros proyectos, con los cuales realiza unas pequeas divisiones de trabajo, que al final, se
juntan para conformar la estimacin ms precisa del software.
Para la estimacin PROBE, obviamente est basada en mtodo PROXY, pero yo
recomendara, la productividad de desarrollo ms similar y completo con respecto a lo que
se requiere en el proyecto, no necesariamente la ms baja.

3. Analiza el o los casos correspondientes e identifica el o los mtodos de estimacin que

consideres responden a las necesidades de cada caso.
En el caso 2 podamos utilizar PROXY, ya que como menciona; se cuenta con antecedentes
de desarrollo previos que han sido documentados y medidos por lo cual se cuenta con un
historial de los mismos, adems de que se ha decidido contratar a nuevos desarrolladores
para las pruebas unitarias, pienso que es una buena eleccin ya que incluso considera los
siguientes puntos:
La medida del proxy debe estar altamente relacionada con el esfuerzo requerido
para desarrollar el producto.
El contenido proxy de un producto debe ser automticamente contable.
El proxy debe ser fcil de visualizar al inicio del proyecto.
El proxy debe ser personalizable a las necesidades de cada proyecto y
desarrollador.
El proxy debe ser sensible a las variaciones de implementacin que afectan los
costos de desarrollo o esfuerzo.
Para el caso 1 debemos considerar otras opciones debido a que no se cuenta con datos
histricos, podramos proponer para este caso COCOMO II (Constructive Cost Model)
surge como una alternativa para incluir componentes de incerteza en las estimaciones
conforme al nivel de informacin disponible. Este es un modelo paramtrico que establece
ecuaciones matemticas para describir las relaciones entre el tamao del software - factor
primario de costo usualmente representado en trminos de puntos de funcin - y otros
factores secundarios que buscan capturar particularidades de producto, proceso, personas
y plataforma. Esos factores son denominados Cost Drivers, siendo algunos de efecto
proporcional y otros de efecto exponencial. Pudiera funcionar bien.
4. Redacta una recomendacin en relacin con el uso del o los mtodos identificados.
Justifica tu recomendacin.

En relacin a la recomendacin, creo que el modelo ms adecuado es el del caso 2,

propondra PROXY. Es muy difcil realizar la estimacin del tamao de un programa basado
nicamente en los requerimientos del cliente. Se requiere de algn proxy que permita
relacionar el tamao del producto con las funciones que se desean incorporar en el
programa. Un proxy no es ms que un sustituto del cual conocemos su tamao. Ejemplos
de proxies son tablas, clases, campos o pantallas.
Eso solo como una justificacin de por qu elegirlo, de igual manera es de fcil visualizacin
al inicio del proyecto y es personalizable a las necesidades de cada proyecto. En mi opinin
es una buena eleccin.

Conclusiones

Elegir un mtodo de estimacin es algo que debemos tomar muy en serio ya que de ello
depende parte del xito de nuestro proyecto y debemos mostrar las mejores cualidades del
mismo dando una optimizacin de cada arte de nuestro proyecto incluyendo nuestros
recursos humanos y tiempos de realizacin.
De pronto pudiera ser muy engorroso el hecho de elegir mtodos de estimacin, pero en s
hacerlo nos ayuda a tener un plan muy bien definido.

Fuentes:

Humphrey, W. (1995) A discipline for software engineering (The complete PSP Book) United
States of America: Addison Wesley.
Humphrey, W. (2005) PSP a Self-improvement process for software engineers. United
States of America: Addison Wesley.
Humphrey, W. (2006). TSP (SM) Leading a Development Team. United States of America:
Addison-Wesley.
Zapata, J., Garca, J., Cerrada, J. (2001) Introduccin al proceso software personalSM.
Madrid, Espaa: Addison Wesley.

Universidad de Pamplona. (24 de agosto de 2009). Introduciendo PSP (Procesos

Personal De Software) en el Aula.
Recuperado de:
http://www.unipamplona.edu.co/unipamplona/portalIG/home_40/recursos/03_v13_18/revis
ta_16/27102011/01.pdf

Conacyt. (S/F). Casos de xito.

Recuperado de:
http://www.cimat.mx/es/casos_de_exito