Introducción La estimación del tamaño de un producto software es de gran utilidad para estimar costos y demás recursos. Propósito Esta actividad tiene la finalidad de que reflexiones sobre la estimación del tamaño de un producto de software y determinar la factibilidad de utilizar métodos de estimación como Proxy o PROBE de acuerdo a los escenarios propuestos mediante casos de análisis. 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 históricos 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 históricos de tamaño 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 codificación y pruebas unitarias.
b) ¿La empresa podría realizar la estimación del proyecto utilizando el método PROXY? ¿Por qué? En el caso de la estimación de tiempos a través del método PROBE, ¿qué recomendación le darías y por qué?, por ejemplo, tomar la productividad de desarrollo más baja y con esa base estimar los tiempos. 3. Analiza el o los casos correspondientes e identifica el o los métodos de estimación que consideres responden a las necesidades de cada caso. 4. Redacta una recomendación en relación con el uso del o los métodos identificados. Justifica tu recomendación.
Contesta las siguientes preguntas sobre los escenarios anteriormente descritos. a) En el escenario 1, ¿la empresa debería utilizar el método PROBE para estimar y planear el trabajo? ¿Por qué? ¿Qué recomendación le proporcionarías? No ya que el método PROBE, utiliza historiales basados en proyectos anteriores, además de que no se cuenta con estimaciones en base a método proxy, el cual se divide en proyectos pequeños que al sumarlo dan una estimación más preci sa. Así pues, no se podría utilizar el método PROBE, para este escenario. Personalmente recomendaría el uso de un método paramétrico, 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 revisión y toma el tamaño del software y un conjunto de factores como entrada y estima el esfuerzo en personas por mes. b) ¿La empresa podría realizar la estimación del proyecto utilizando el método PROXY? ¿Por qué? En el caso de la estimación de tiempos a través del método PROBE, ¿qué recomendación le darías y por qué?, por ejemplo, tomar la productividad de desarrollo más baja y con esa base estimar los tiempos. Así es, ya que PROXY, se basa en los datos históricos y en la experiencia con respecto a otros proyectos, con los cuales realiza unas pequeñas divisiones de trabajo, que al final, se juntan para conformar la estimación más precisa del software. Para la estimación PROBE, obviamente está basada en método PROXY, pero yo recomendaría, la productividad de desarrollo más similar y completo con respecto a lo que se requiere en el proyecto, no necesariamente la más baja. 3. Analiza el o los casos correspondientes e identifica el o los métodos de estimación que consideres responden a las necesidades de cada caso. En el caso 2 podíamos 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, además de que se ha decidido contratar a nuevos desarrolladores para las pruebas unitarias, pienso que es una buena elección 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 automáticamente contable. El proxy debe ser fácil 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 implementación que afectan los costos de desarrollo o esfuerzo. Para el caso 1 debemos considerar otras opciones debido a que no se cuenta con datos históricos, podríamos 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 información disponible. Este es un modelo paramétrico que establece ecuaciones matemáticas para describir las relaciones entre el tamaño del software - factor primario de costo usualmente representado en términos de puntos de función - 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 recomendación en relación con el uso del o los métodos identificados. Justifica tu recomendación. En relación a la recomendación, creo que el modelo más adecuado es el del caso 2, propondría PROXY. Es muy difícil realizar la estimación del tamaño de un programa basado únicamente en los requerimientos del cliente. Se requiere de algún proxy que permita relacionar el tamaño del producto con las funciones que se desean incorporar en el programa. Un proxy no es más que un sustituto del cual conocemos su tamaño. Ejemplos de proxies son tablas, clases, campos o pantallas. Eso solo como una justificación de por qué elegirlo, de igual manera es de fácil visualización al inicio del proyecto y es personalizable a las necesidades de cada proyecto. En mi opinión es una buena elección. Conclusiones Elegir un método de estimación 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 optimización de cada arte de nuestro proyecto incluyendo nuestros recursos humanos y tiempos de realización. De pronto pudiera ser muy engorroso el hecho de elegir métodos de estimación, 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., García, J., Cerrada, J. (2001) Introducción al proceso software personalSM. Madrid, España: 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
