Monterrey, Nuevo León a
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY
PRESENTE.
Por medio de la presente hago constar que soy autor y titular de la obra
, en los sucesivo LA OBRA, en virtud de lo cual autorizo a el Instituto Tecnológico y de Estudios Superiores de Monterrey (EL INSTITUTO) para que efectúe la divulgación, publicación, comunicación pública, distribución, distribución pública y reproducción, así como la digitalización de la misma, con fines académicos o propios al objeto de EL INSTITUTO, dentro del círculo de la comunidad del Tecnológico de Monterrey.
El Instituto se compromete a respetar en todo momento mi autoría y a otorgarme el crédito correspondiente en todas las actividades mencionadas anteriormente de la obra.
De la misma manera, manifiesto que el contenido académico, literario, la edición y en general cualquier parte de LA OBRA son de mi entera responsabilidad, por lo que deslindo a EL INSTITUTO por cualquier violación a los derechos de autor y/o propiedad intelectual y/o cualquier responsabilidad relacionada con la OBRA que cometa el suscrito frente a terceros.
Nombre y Firma AUTOR (A)
Prácticas de Estimación de Esfuerzo en Proyectos de Desarrollo
de Software en Monterrey N.L., un Estudio Exploratorio-Edición
Única
Title Prácticas de Estimación de Esfuerzo en Proyectos de Desarrollo de Software en Monterrey N.L., un Estudio Exploratorio-Edición Única
Authors Sergio Omar Flores Pineda
Affiliation Tecnológico de Monterrey, Campus Monterrey
Issue Date 2008-03-01
Item type Tesis
Rights Open Access
Downloaded 19-Jan-2017 01:23:45
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS
SUPERIORES DE MONTERREY
CAMPUS MONTERREY
PROGRAMA DE GRADUADOS EN MECATRÓNICA Y
TECNOLOGÍAS DE INFORMACIÓN
TECNOLÓGICO
DE MONTERREY
PRÁCTICAS DE ESTIMACIÓN DE ESFUERZO EN PROYECTOS DE DESARROLLO DE SOFTWARE EN MONTERREY, N.L., UN
ESTUDIO EXPLORATORIO
TESIS
PRESENTADA COMO REQUISITO PARCIAL PARA OBTENER EL GRADO ACADÉMICO DE:
MAESTRO EN ADMINISTRACIÓN DE TECNOLOGÍAS DE INFORMACIÓN
POR:
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY
DIVISIÓN DE MECATRÓNICA Y TECNOLOGÍAS DE INFORMACIÓN
PROGRAMA DE GRADUADOS EN MECATRÓNICA Y TECNOLOGÍAS DE INFORMACIÓN
Los miembros del comité de tesis recomendamos que la presente tesis del Ing. Sergio Ornar Flores Pineda sea aceptada como requisito parcial para obtener el grado académico de Maestro en Administración de Tecnologías de Información.
Comité de tesis:
Director del Programa de Graduados en Mecatrónica y Tecnologías de Información
PRÁCTICAS DE ESTIMACIÓN DE ESFUERZO EN
PROYECTOS DE DESARROLLO DE SOFTWARE EN MONTERREY,
N.L., UN ESTUDIO EXPLORATORIO
POR:
SERGIO OMAR FLORES PINEDA
TESIS
Presentada al Programa de Graduados en Mecatrónica y Tecnologías de Información
Este trabajo es requisito parcial para obtener el grado de Maestro en Administración de Tecnologías de Información
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY
Dedicatoria
Dedico el presente trabajo a mis padres, Guillermo Flores Leal y María Luisa Pineda de Flores, por haberme apoyado y alentado siempre y ser la guía de todos mis proyectos.
A mis hijos Sergio Ornar y Lorena, por ser la inspiración y motivación más grande de mi vida.
A mi esposa Nora, por acompańarme en este camino inexorable.
Agradecimientos
A mi esposa e hijos, por darle sentido a mi vida.
A mi asesor, Dr. Juan Carlos Lavariega, por tanto esfuerzo y enseńanzas que invirtió en mi proyecto.
A mis sinodales, Dr. Macedonio Alanis e Ing. Rafael Salazar, por ayudarme a dirigir, enfocar y darle mayor valor a este trabajo.
A las personas que con sus respuestas apoyaron la realización del presente estudio.
A mis compańeros de Altumware, por compartir sus experiencias y apoyarme en las mejoras en el proceso de estimaciones de esfuerzo de desarrollo de software.
Resumen
A nivel mundial, la demanda de software se incrementa rápidamente, generando a su vez un crecimiento en las actividades de desarrollo de software. Tradicionalmente, los parámetros de medición del éxito de un proyecto de desarrollo de software incluyen al menos tres dimensiones: costo, tiempo y alcance, es decir, que el producto del proyecto de desarrollo de software debe incluir la funcionalidad esperada (alcance), en el tiempo prometido y con el costo prometido. Usando estos parámetros, aproximadamente una tercera parte de los proyectos de desarrollo de software no son exitosos.
Considerando que el esfuerzo es uno de los factores principales para el costo y el tiempo requeridos para el desarrollo de software, la estimación de esfuerzo se vuelve uno de los procesos más importantes en la administración de un proyecto.
Sin embargo, también es uno de los procesos más difíciles del desarrollo de software. Existen una serie de dificultades e influencias que generan variaciones importantes entre el esfuerzo estimado y el esfuerzo real de un proyecto, por lo que resulta importante contar con capacitación constante en el tema. Además, la misma terminología utilizada en el proceso de estimación de esfuerzo puede resultar una fuente de problemas.
En el presente estudio se mencionarán conceptos, dificultades y problemática del proceso de estimación de esfuerzo de desarrollo de software encontradas en investigaciones previas; se generará un modelo basado en estas mismas investigaciones y se mostrarán los resultados de la investigación de campo realizada respecto a las prácticas de estimación de esfuerzo en la ciudad de Monterrey, Nuevo León, donde destaca una falta de capacitación en estimaciones en la industria.
Capítulo 4 Análisis de Resultados 34 4.1 Información general 34 4.2 Respuestas a la encuesta 34 4.3 Tamańo de la muestra 34 4.4 Análisis de Variables 36 4.5 Resultados obtenidos 63 4.6 Conclusiones 64 Capítulo 5 Recomendaciones en prácticas de estimación de esfuerzo 66
5.1 Recomendaciones para las organizaciones de desarrollo de software 66
5.2 Recomendaciones para proyectos de desarrollo de software 68
5.3 Casos de ejemplo 70 5.4 Material Recomendado 73 Capítulo 6 Conclusiones y trabajos futuros 75
6.1 Trabajos futuros 77 Anexo A. Encuesta aplicada 78
Encuesta sobre prácticas de estimación de esfuerzo en proyectos de desarrollo de software 78
Referencias 89
Lista de Figuras
Figura 11 3 Figura 31 28 Figura 41 37 Figura 42 39 Figura 43 40 Figura 44 41 Figura 45 43 Figura 46 44 Figura 47 44 Figura 48 45 Figura 49 46 Figura 410 47 Figura 411 48 Figura 412 , 49
[image:12.612.164.571.115.552.2]Lista de Tablas
Tabla 41 36 Tabla 42 37 Tabla 43 38
Tabla 44 40
[image:13.612.150.553.116.256.2]Capítulo 1 Introducción
1.1 Estimaciones fallidas
Según estudios recientes acerca de las estimaciones de software, se encontró que entre el 60 y 80% de los proyectos se terminaban con un esfuerzo o tiempo mayor que el planeado. La magnitud de la diferencia entre la estimación y la realidad está entre el 30 y 40% (Mol0kken0stvold et al., 2004).
Jorgensen y Mol0kken0stvold (2002) menciona que las predicciones del esfuerzo requerido para completar un proyecto no puede esperarse que sean precisas cuando los requerimientos están incompletos, el ambiente de desarrollo es inestable, los miembros del equipo de proyecto carecen de la experiencia requerida o los participantes clave del proyecto lo abandonan a la mitad; sin embargo, estas condiciones están presentes todavía en la mayoría de los proyectos de software.
Se comenta que las estimaciones de tiempo en los proyectos de desarrollo de software han sido desde hace mucho un problema difícil. El "CHAOS Report" del Standish Group indica que solo el 20% de los proyectos terminan a tiempo, en relación con el plan original (Little, 2006).
En el "CHAOS Report" de 1999 se encontró una relación significativa entre el tamańo del proyecto y su éxito. Se menciona que uno de los mayores determinantes para esta correlación es la separación física de los equipos, que suele ser el caso entre más grande sea el proyecto (Keil, Paulish, y Sangwan, 2006).
Por su parte, Mol0kken0stvold et al., (2004) menciona un estudio de Moore y Edwards que encontró que el 91% de los administradores encuestados respondieron que sí veían a las estimaciones de software como un problema. Un hallazgo de este estudio es que los administradores reportaron que un nivel de estimación aceptable tendría una precisión de +/ 20%.
expertos llevara a una estimación más precisa o con menos polarización, en comparación con el uso exclusivo de juicio de expertos.
1.2 Conceptos relacionados a las estimaciones
De acuerdo al diccionario, una estimación es una predicción de cuánto tomará un proyecto o cuánto costará. Sin embargo, la estimación de proyectos de software también se interrelaciona con metas de negocio, compromisos y control, pero la finalidad de las estimaciones es determinar si las metas de un proyecto son realistas y permitirán controlarlo para alcanzarlas (McConnell, 2006).
Se ha encontrado que el factor más importante en una estimación de software es el tamańo de la aplicación de software a desarrollar, debido a que existe mayor variación en el tamańo que en cualquier otro factor (McConnell, 2006).
En el contexto de estimaciones de software, se deben distinguir los términos "tamańo" y "esfuerzo". El tamańo de una aplicación de software se refiere al conjunto de funcionalidades que el usuario obtiene del producto terminado, y se puede medir en líneas de código fuente, puntos de función, puntos de objetos, etc., siendo las primeras 2 las más populares. El esfuerzo se refiere a la cantidad de tiempo del equipo de desarrollo requerida para generar la aplicación de software de un cierto tamańo, y depende principalmente de dos factores: tamańo de la aplicación y productividad del equipo de proyecto; el esfuerzo típicamente se mide en personas por mes (Parthasarathy, 2007).
Normalmente se asume que un sistema que es 10 veces más grande en tamańo que otro sistema de referencia tomaría 10 veces más esfuerzo para construirlo. Sin embargo, se ha encontrado en el desarrollo de software que los incrementos en tamańo tienen un efecto exponencial en el incremento de esfuerzo, debido principalmente al número de comunicaciones requerido para coordinar el proyecto, que crece como función cuadrática del número de personas en el proyecto. A este efecto se le conoce como "deseconomías de escala" (McConnell, 2006).
El tiempo necesario para entregar la aplicación de software puede determinarse a partir del esfuerzo estimado y la productividad del equipo de desarrollo. A este proceso se le denomina calendarización y genera la lista de entregables del proyecto y la fecha estimada para dicha entrega. Durante la ejecución de proyectos de desarrollo de software existe incertidumbre sobre las decisiones que se tomarán a lo largo del proyecto para resolver los aspectos relacionados con la aplicación de software. Esta incertidumbre es máxima en las etapas iniciales y va disminuyendo conforme avanza el proyecto. Si se graficara en el eje horizontal el tiempo y los mayores entregables y en el eje vertical el factor de error comúnmente encontrado en estimaciones, el resultado sería una figura de cono, comúnmente denominado el "cono de incertidumbre", como se muestra en la Figura 11 (McConnell, 2006). 4* i ra 8 1 > 1.5» 125* 1.0* 0.8* 0JS7* . 0.5* 025* 1 Corcrept RaqDtretneiiia Compíete Product Time User Interface Dssign Complete Figura 11 Dcfcúká Dssign Complete Software Complete
1.3 Importancia de las estimaciones de proyectos de software
Parthasarathy (2007) coincide en resaltar la importancia de las estimaciones de los proyectos de software, indicando que la habilitad para estimar los parámetros que controlarán la ejecución del proyecto, como tamańo, tiempo y calidad, son uno de los factores críticos que determinarán el éxito del proyecto.
Para la administración de proyectos, tanto la estimación de esfuerzo como la estimación de tiempo son necesarias, pero el tener una estimación de esfuerzo disponible vuelve al resto de las estimaciones más sencillas, por eso el enfoque de los proyectos de software normalmente está en la estimación de esfuerzo. Además, la estimación de esfuerzo es esencial por razones de negocio, ya que normalmente los contratos entre clientes y proveedores en proyectos de desarrollo de software se basan en las estimaciones de costo y tiempo; sin estas estimaciones, el cliente no tiene bases para juzgar una propuesta. De esta manera, una buena estimación es extremadamente importante para cualquier organización de software, pero en particular para las que desarrollan software para terceros (Jalóte, 2000).
Además, las estimaciones de costo y de tiempo deben ser desarrolladas para todos los proyectos, y ambas estimaciones son normalmente proporcionales al esfuerzo aplicado a un proyecto de software. De esta manera, el costo es frecuentemente determinado utilizando la estimación de esfuerzo y las tarifas estándar. La estimación de tiempo se convierte también en la aplicación de un modelo que tome de base la estimación de esfuerzo. Puede decirse por tanto que sin una buena estimación de esfuerzo, no es posible una planeación efectiva de un proyecto de software (Jalóte, 2000).
Según Galorath y Evans (2006), los problemas derivados de estimaciones de software inapropiadas son de los más difíciles de afrontar para el equipo de desarrollo. Entre otras cosas, mencionan que es muy común que a los ingenieros de software sin preparación en estimaciones se les soliciten estimaciones.
Sin embargo, Galorath y Evans (2006) también mencionan que usadas apropiadamente, las estimaciones pueden proveer una fuente de identificación de riesgos, limitaciones de recursos y opciones disponibles, ayudando a definir y planear mejor el proyecto.
1.4 Confusión en la terminología
significativamente mientras avanza el proyecto. En su lugar, (Little, 2006) encontró que la incertidumbre restante era esencialmente constante durante la vida del proyecto.
Boehm y Fairley (2000) se refieren a dos importantes aspectos acerca de las estimaciones de software:
1. Es mejor entender el contexto de la estimación antes de usarla
2. Es mejor orientar el enfoque de la estimación al uso que se le dará a la misma
Jorgensen (2003) menciona que el uso incorrecto y la falta de claridad en el uso del término "estimación de costo" parece ser típico en la industria del software. En el mismo estudio, reportan haber observado que el término estimación es aplicado algunas veces a "costo más probable de desarrollo de software", algunas veces a "costo de desarrollo de software tomando en cuenta los riesgos", algunas veces a "costo planeado reducido de desarrollo de software" y algunas veces incluso aplicado al "precio al cliente" o "propuesta de proyecto". Jorgensen comenta que la mayoría de los textos y artículos de investigación que describen estimaciones de costo no clarifican cuál es la interpretación de "estimación de costo" que utilizan, e incluso algunos artículos interpretan el exceso del presupuesto como el exceso del proyecto, pero sin clarificar a qué tipo de presupuesto se refieren.
Jorgensen (2003) también reporta que debido a esta falta de claridad es que los promedios de precisión de estimaciones sobre datos con diferentes interpretaciones de "estimación de costo" pueden no ser realmente significativos, y generar los siguientes problemas:
1. Problemas de estimación debidos a metas en conflicto. Propuestas, presupuestos y estimaciones de costo probable tienen propósitos diferentes, por lo que la falta de claridad en el término "estimación" puede ser una razón importante para el sobre optimismo típico en las estimaciones de proyectos de software.
2. Problemas de comunicación. Una confusión frecuentemente observada es que el estimador se refiere a "costo más probable" y la administración o incluso el cliente lo interpreta como "costo de desarrollo tomando en cuenta riesgos", o "precio fijo".
1.5 Complejidad de las estimaciones
Fayad, Laitinen, y Ward (2000) menciona que la mayoría de las empresas de desarrollo de software son pequeńas, y aunque han sido ignoradas en la literatura y sociedades de ingeniería de software, generan la mayor parte de los productos y servicios de software. Sin embargo, la mayor parte de las técnicas, modelos y herramientas de estimación de proyectos de desarrollo de software no están orientados a las empresas pequeńas, e incluso son de difícil adaptación.
Por su parte, Mol0kken0stvold et al., (2004) menciona que existen diferentes estimaciones en un mismo proyecto de software. En primer lugar, las estimaciones frecuentemente cambian durante el curso de un proyecto, dependiendo de la etapa en la que la estimación se genera; por ejemplo, un proyecto puede tener una estimación temprana basada en requerimientos vagos, una estimación para planeación basada en una especificación detallada de requerimientos, y una o más estimaciones durante el desarrollo del proyecto. Las estimaciones podrían ser todas acerca del esfuerzo necesario para el proyecto pero podrían tener diferencias muy amplias entre ellas.
En segundo lugar, un factor muy importante es el destinatario de la estimación; por ejemplo, se pueden tener estimaciones diferentes si el destinatario es el administrador de proyecto o si es el cliente final (Mol0kken0stvold et al., 2004).
De acuerdo a Boehm y Ross (1989), la administración de proyectos de software es un arte hoy día. La integración de tecnologías de software, economías y relaciones humanas en el contexto específico de un proyecto de software no es una tarea sencilla. Humphrey (2005)comenta también que las estimaciones son parte análisis, parte diseńo, parte proyección y parte cálculo de riesgos, y que aún con un conjunto de prácticas y herramientas adecuados y sólidos, es normal tener errores.
Por otro lado, un aspecto poco estudiado es el tamańo de la organización de desarrollo de software. Como menciona Fayad et al., (2000), el crecimiento de la industria del software ha producido muchas compańías pequeńas, lo que genera al menos cuatro aspectos a considerar en la ingeniería de software:
1. Tamańo de la compańía 2. Modo de desarrollo 3. Tamańo del desarrollo 4. Velocidad de desarrollo
software y procesamiento de información, las prácticas y procesos de desarrollo de software están normalmente orientados a empresas grandes, dejando en desventaja a la mayoría de los participantes en esta industria.
Según Tsoi (1999), dos de los principales problemas en el desarrollo de software son excederse en el presupuesto y entrega tardía, ya que antes de iniciar cualquier proyecto los administradores deben estimar el tamańo de una aplicación para poder determinar niveles de recursos adecuados y un tiempo de entrega realista. Sin embargo, y debido a que muchos proyectos exceden ambos parámetros, muchos proyectos son forzados a ser abortados, a dejar sin implementar algunos componentes o son entregados sin la depuración necesaria. En pocas palabras, la planeación exitosa de un proyecto de software depende principalmente de una buena estimación de esfuerzo, y el éxito del proyecto se determinará con base en las estimaciones iniciales de esfuerzo, tiempo y presupuesto.
Brooks (1987) establece que las entidades de software son más complejas respecto a su tamańo que quizá cualquier otra elaboración humana, ya que no hay dos partes iguales. Además, la complejidad del software es esencial, no accidental.
"La esencia de una entidad de software es la elaboración de conceptos interrelacionados: conjunto de datos, relaciones entre los datos, algoritmos e invocación de funciones. Esta esencia es abstracta en el sentido de que la elaboración conceptual es la misma bajo diferentes representaciones, aunque es altamente precisa y detallada", menciona Brooks (1987).
1.6 Definición del Problema
Como menciona Brooks (1987), en la industria de software hay esperanzas y búsqueda frecuente de la "bala de plata" que destruya al monstruo de las fechas fallidas, presupuestos rebasados y productos defectuosos, algo que puede hacer caer a los costos de software tan rápidamente como caen los costos del hardware.
Según Jalóte (2002), aproximadamente un tercio de los proyectos tienen costos y tiempos que exceden más del 125% sus presupuestos.
Grimstad (2006) hace referencia al "CHAOS Report" del Standish Group que concluye que las estimaciones confiables son uno de los diez factores más importantes en proyectos de software.
Aunque cada organización de desarrollo de software es diferente, la mayoría de ellas emplea estimaciones de desarrollo de software al inicio de los proyectos, y precisamente al inicio de los proyectos es cuando el tamańo, complejidad y esfuerzo requeridos tienen la mayor incertidumbre. Además, es común el pensamiento de que es imposible determinar con exactitud el tiempo requerido para desarrollar o actualizar un producto, el tamańo del mismo y la productividad del equipo de desarrollo (Galorath y Evans, 2006).
Por otro lado, uno de los factores determinantes del esfuerzo a aplicar en el desarrollo de una aplicación de software es el tamańo, por lo que si su estimación es incorrecta, es muy probable que la estimación de esfuerzo sea incorrecta. Pero como el tamańo de una aplicación de software mide funcionalidad, existe una variedad interesante de unidades, lo que dificulta la comparación de esfuerzo entre diferentes proyectos y por lo tanto dificulta la determinación de productividad de un equipo de desarrollo. Además, las estimaciones de tamańo son normalmente aceptadas sin una guía consistente, por lo que puede existir variación de su aplicación entre proyectos (Galorath y Evans, 2006).
Además, la exactitud de las estimaciones de proyectos de software depende de muchos factores, pero muy pocos de ellos son comunes, precisos y están disponibles cuando la estimación es hecha. Los problemas para generar estimaciones precisas y consistentes pueden encontrarse en el proceso, en sus elementos básicos y en su representación, así como en las diferentes motivaciones y objetivos, experiencia, entrenamiento e influencias en los estimadores. Además, es común tratar de ligar los resultados de los procesos de estimación con metas, objetivos o compromisos administrativos. Entre otras, destacan las siguientes razones para que las estimaciones fallen:
• Falta o uso inadecuado de datos históricos • Administración del proyecto muy optimista • Problemas para utilizar la estimación
• Problemas para mantener actualizada la estimación
1.7 Clasificaciones de métodos de estimación
Parthasarathy (2007) menciona que la mayoría de los métodos y modelos de estimación pueden ser clasificados en dos grandes enfoques:
1. Enfoque heurístico, donde expertos y profesionales en el área de estimaciones utilizan la experiencia y práctica en estimaciones para resolver el problema de las estimaciones. Ejemplos de este enfoque son los métodos basados en juicio de expertos, métodos basados en analogías, métodos "bottomup", "topdown" y algorítmicos, entre otros.
2. Enfoque paramétrico, en el que modelos estadísticos y probabilísticas son utilizados para resolver el problema de estimaciones utilizando información y características del proyecto, de la empresa e incluso de los desarrolladores. Se usa el término "estimación" de manera amplia, incluyendo frecuentemente tamańo, esfuerzo y costo. Entre los ejemplos más conocidos están el método SLIM ("Software Lifecycle Model"), SEER SEM, SELEC Estimator, COCOMO II, COSMICFFP, Puntos de Función (en inglés "Function Points"), entre otros.
1.8 Dificultades comunes
Mol0kken0stvold et al., (2004) encontró que proponer para ganar (en inglés, "Pricing to win") es listado como un método de estimación, pero se cree que la mayoría de los administradores no lo reportarían como un método de estimación aún y que tuviera un impacto en sus estimaciones. Esto puede deberse a que los administradores no están conscientes del efecto de las expectativas de los clientes en las estimaciones de esfuerzo. Ellos podrían pensar que no es un método de estimación, o creer que no deberían verse impactados por él.
En Jorgensen y Mol0kken0stvold (2002), se encontró que existe una mayor polarización hacia estimaciones muy bajas cuando los miembros del grupo de estimación pertenecían a la misma especialidad (por ejemplo, desarrolladores). Sin embargo, esta polarización podía disminuir si se realizaba en equipos multidisciplinarios. Asimismo, se encontró que las estimaciones basadas en el promedio de las estimaciones de un grupo son más precisas que las estimaciones individuales, probablemente por la misma polarización mencionada antes.
1. Apoyar las negociaciones entre costo del software, tiempo, calidad, desempeńo y funcionalidad
2. Proveer la parte del costo de un análisis costobeneficio o de retorno sobre inversión
3. Apoyar los análisis de costos y riesgos
4. Apoyar las decisiones de inversión de mejora de calidad o productividad del software.
1.9 Objetivo del estudio
El objetivo de este trabajo es realizar un estudio exploratorio de las prácticas de estimación de esfuerzo de desarrollo de software en Monterrey, para identificar y analizar los métodos, modelos y técnicas de estimación de esfuerzo de desarrollo de software más utilizados y generar una serie de recomendaciones para identificar los métodos, modelos o técnicas de estimación de esfuerzo de desarrollo de software más adecuados para una organización.
La decisión de realizar el estudio en el área metropolitana de Monterrey obedece principalmente a que representa por sí misma aproximadamente el 13.1% de las empresas desarrolladoras de software (González Báńales, 2005). Además, según PROSOFT (2004), el desarrollo de software es la actividad
principal del 42% de las empresas orientadas a servicios de Tecnologías de Información. Por último, Nuevo León representa el 13.33% de los fondos de apoyo aprobados por el programa gubernamental PROSOFT (Facultad de Economía de la UNAM, 2006).
1.10 Estructura de la tesis
Esta tesis se compone de seis capítulos. El capítulo 1 sirve de introducción al tema de investigación y muestra una panorámica del problema identificado, su importancia, así como los objetivos y estructura de la tesis.
El capítulo 2 está formado por el marco teórico (revisión literaria) en el que se sustenta la investigación y se definen los elementos y hallazgos relacionados al tema de investigación.
El capítulo 4 muestra los resultados obtenidos en la investigación de campo, así como la estadística descriptiva de los resultados.
En el capítulo 5 se enlistan las recomendaciones derivadas de la investigación de campo y de la revisión de la literatura disponible, divididas en recomendaciones para la organización y recomendaciones para el proyecto.
Las conclusiones del presente estudio así como los trabajos futuros que podrían realizarse para darle seguimiento a esta investigación se muestran en el capítulo 6. Después de este capítulo se muestran las referencias bibliográficas utilizadas en el desarrollo de esta tesis.
1.11 Conclusiones
El éxito o fracaso de los proyectos de desarrollo de software dependen en gran medida de las estimaciones, que normalmente se realizan muy temprano en la vida del proyecto, con pocos datos y mucha incertidumbre. Además, el proceso de estimación suele ser complejo por los cambios frecuentes en el alcance de cualquier proyecto de desarrollo de software. Para agregar más complejidad, la terminología utilizada en la industria, en los estudios y en los textos sigue siendo confusa.
En el presente estudio se busca identificar el problema de los procesos de estimación, así como identificar las prácticas actualmente llevadas a cabo. Se
Capítulo 2 Antecedentes y Marco Teórico
2.1 Proyectos de desarrollo de software
Jalóte (2002) define dos dimensiones principales de las actividades de un proyecto de software: ingeniería y administración. La dimensión de ingeniería abarca la construcción del sistema y se enfoca en los detalles de diseńo, pruebas, codificación, etc. La dimensión de administración de proyecto se enfoca en la planeación y control de las actividades de ingeniería de tal forma que se alcance los objetivos de costo, tiempo y calidad.
Sin embargo, Jalóte también menciona que para ejecutar exitosamente proyectos grandes, la formalidad y el rigor deben incrementarse en ambas dimensiones, al igual que Bryant (2000), que encuentra criterios comunes para los que el desarrollo de software requiere de una base rigurosa, que se encuentra en la ingeniería. Concluye que el software requiere un salto cuántico respecto de sus orígenes, donde la idea de "ingeniería de software" ha permanecido en el centro del desarrollo de software desde 1968, con la duda de si la metáfora era solamente una broma.
Boehm y Ross (1989) seńala que el principal problema de los administradores de proyectos de software es la necesidad de satisfacer simultáneamente a todos los interesados: usuarios, clientes, equipo de desarrollo, administración, etc.
En Boehm (1983) se enlistan los siete principios encontrados como básicos en la administración de proyectos de desarrollo de software:
1. Administrar utilizando un plan por fases del ciclo de vida 2. Realizar validaciones continuamente
3. Mantener un control de producto
4. Utilizar prácticas de programación modernas 5. Mantener una contabilización de resultados clara 6. Utilizar pocos pero buenos miembros del equipo 7. Mantener un compromiso para mejorar el proceso
1. Cubren todo el espectro de buenas prácticas, comparados con otras listas de principios, de tal suerte que el uso de los siete principios propuestos pueden implicar o incluir el resto de los principios de otras listas.
2. Son independiente entre sí, de tal suerte que no hay combinaciones de seis o menos principios que impliquen o incluyan los restantes.
De acuerdo a Sengupta y AbdelHamid (1996), la administración de proyectos de software puede ser vista como un caso de toma de decisiones en ambientes reactivos y dinámicos con tres características comunes:
1. La tarea requiere realizar una serie de decisiones a través del tiempo 2. Las decisiones no son independientes
3. El ambiente de decisión cambia a través del tiempo, de manera autónoma pero también en reacción a las decisiones del administrador
2.2 El rol de estimador
Londeix (1987) considera que el administrador debe delegar la tarea de estimación a un especialista externo, con la finalidad de minimizar los aspectos no racionales y mantener en la medida de lo posible una visión objetiva del proyecto.
Cualquiera relacionado directamente con el resultado de un proyecto, ya sea en tiempo o en costo, no debería realizar la estimación, según Londeix (1987), en particular los siguientes roles:
1. Administradores de proyectos, encargados del control y seguimiento de proyectos.
2. Administradores de software, responsables por la administración, configuración y cambios en el software, incluyendo herramientas e infraestructura.
3. Analistas e ingenieros de software, quienes generan el diseńo, arquitectura y desarrollan el software en general.
DeMarco (1982) coincide en la necesidad de separar las funciones de estimación de las del resto del desarrollo de software, y sugiere que los éxitos e incentivos del estimador deben separarse de los del equipo de desarrollo; además sugiere responsabilizar al estimador por la medición del proyecto.
Londeix (1987) enlista las siguientes características deseables en un estimador:
3. Contar con un método documentado que pueda ser explicado, cuestionado, discutido y auditado por expertos
4. Cuando utilice una herramienta, debe hacerlo de tal manera que la herramienta cumpla su objetivo y soporte el método, además de ser controlable y documentada
5. Debe ser capaz de describir su experiencia en estimación, como los problemas que enfrenta, el éxito del método, etc.
6. Debe ser capaz de documentar su estimación, incluyendo la información necesaria para que la estimación se repetible y verificable
Sin embargo, a pesar de las evidencias que demuestran lo contrario, otros estudios consideran que la responsabilidad de las estimaciones recae principalmente en el administrador de proyecto (McConnell, 2006; Nasir, 2006; Agarwal et al., 2001; Boehm y Ross, 1989).
2.3 Definición de estimación de esfuerzo de desarrollo de software
Grimstad (2006) define a la estimación de esfuerzo de desarrollo de software como una predicción del esfuerzo requerido más probable para implementar un proyecto de desarrollo de software.
McConnell (2006) cita a Conté, Dunsmore, y Shen (1986) que proponen la definición de un buen esquema de estimación como aquel que está dentro del 25% de los resultados reales el 75% del tiempo; esta definición es comúnmente usada para evaluar la precisión de una estimación.
Como menciona DeMarco (1982), los ingenieros de software son estimadores muy pobres; algunas de las principales razones son:
1. No desarrollan habilidades de estimación
2. No hacen las provisiones adecuadas para cancelar el efecto de la polarización
3. No tienen un claro entendimiento de lo que una estimación debe ser
4. No tienen buenas relaciones con problemas políticos que afectan el proceso de estimación
5. No basan las estimaciones en el desempeńo de proyectos anteriores
Una estimación es una predicción que es igualmente probable de estar encima o debajo del resultado real.
Ray Wolverton, en Londeix (1987), coincide con esta definición al mencionar que las soluciones puntuales (un número de horas/hombre) representa la solución promedio.
Londeix (1987) considera la estimación un juicio, una opinión acerca de algo, pero con la característica de que pretende ser cierto bajo ciertos límites. Para arribar a un resultado, la estimación debe ser basada en un método de estimación. Define los siguientes criterios para considerar exitoso al método de estimación:
1. La estimación temprana está dentro de un rango de 30% del costo final 2. El método permite refinamiento de la estimación durante el ciclo de vida de
software
3. El método es fácil de usar para un estimador
4. Las reglas son entendidas por todos los involucrados
5. El método está documentado y es soportado por herramientas
6. El proceso de estimación es confiable para el equipo de desarrollo de software y sus administradores
2.4 Métodos de estimación de esfuerzo de desarrollo de software
Nasir (2006) hace una revisión de la literatura y propone una clasificación de las prácticas y modelos adoptados en la industria:
2.4.1 Metodologías
1. Método de Analogía, donde el proyecto a estimar es comparado con proyectos terminados del mismo tipo.
2. Método de arriba hacia abajo ("topdown"), toma los requerimientos de más alto nivel y empieza a evaluar hacia el detalle, tomando en cuenta las características del sistema.
3. Método de abajo hacia arriba ("bottomup"), descompone el proyecto a desarrollar en componentes, aplica la estimación a los componentes y combina las estimaciones para dar una estimación general del proyecto.
2.4.2 Técnicas
2.5 Métodos de estimación de esfuerzo de desarrollo de software más utilizados
Jorgensen (2004, 2005 y 2007) menciona que las estimaciones de esfuerzo basadas en juicio de expertos es el enfoque más utilizado hoy día, y define el criterio para considerar una estrategia, técnica o método de estimación como basada en juicio de expertos a aquella en la que el trabajo de estimación es conducido por una persona reconocida como un experto en la tarea, y donde una parte significativa del proceso de estimación está basada en un proceso racional no explícito y no recuperable, y donde no hay un modelo formal como núcleo del proceso de estimación.
Jorgensen (2004) también menciona que múltiples revisiones de la práctica de estimaciones sugieren que la estimación de expertos es la estrategia dominante en cuanto a estimaciones de esfuerzo de desarrollo de software, y aunque las características y definiciones no son las mismas en los diferentes estudios, existe una fuerte evidencia que apoya la afirmación de que las estimaciones de expertos son aplicadas con mayor frecuencia que las estimaciones basadas en modelos. Además, menciona que esta marcada tendencia no es inusual, ya que se han identificado hallazgos similares en otras áreas, como pronósticos de negocios.
Una de las razones más fuertes para basar las estimaciones en juicio de expertos es que no hay evidencia suficiente que demuestre que el uso de modelos formales lleve a estimaciones más precisas, en comparación con las de expertos (Jorgensen 2004, 2005). En investigaciones en la literatura disponible, se encontró un número igual de estudios que afirmaban que las estimaciones basadas en juicio humano tenían una mayor precisión, en comparación con los estudios que afirmaban que las estimaciones basadas en modelos eran más precisas.
2.6 Recomendaciones para evitar confusión en los términos de estimaciones
Jorgensen (2003) recomienda las siguientes acciones para evitar la confusión relacionada a la falta de claridad en los términos de estimaciones de costo:
1. Utilizar términos claros, reemplazando por ejemplo "costo estimado" con "costo más probable", o utilizando "precio", "propuesta", "costo planeado" en otras situaciones.
2. Capacitar a la gente en la separación de los términos y la diferencia en la finalidad de cada concepto.
3. Asegurarse de que el rol del estimador es similar antes de comparar la precisión de diferentes proyectos.
4. Separar los procesos de la organización de estimación de costos de los de planeación de proyectos y de las propuestas a los clientes.
Como menciona Vesterinen (1999), existen varios modelos y métodos de estimación de esfuerzo de desarrollo de software, pero un modelo que funciona bien para una compańía no lo hace para otra, o incluso en la misma compańía no se comporta igual para todos los tipos de proyecto.
Grimstad (2006) menciona a Kitchenham, que sugiere que antes de mejorar un proceso de estimación se deben resolver los problemas administrativos. También cita a DeMarco y Lister, que consideran a la "falla de calendarización" como el mayor riesgo de los proyectos de software, definiendo a falla de calendarización a no hacer distinción entre estimaciones optimistas, la meta, la estimación más probable y el calendario. Encuentra una falta de mejoras en las estimaciones de software en los últimos 20 ańos, y una de las razones que enlista es falta de precisión de la terminología de estimaciones de esfuerzo en la industria, derivada a su vez de de la falta de precisión en la terminología encontrada en textos y artículos de investigación.
"Las organizaciones de desarrollo de software deben mejorar el uso de la terminología de estimaciones para evitar confusiones, incrementar el apego a la
realidad de sus estimaciones y mejorar las experiencias de aprendizaje. Los investigadores necesitan una terminología precisa para incrementar la validez de sus resultados de investigación cuando, por ejemplo, comparan dos modelos de estimación formales" (Grimstad et al., 2006).
1. No mezclar estimaciones tipo esfuerzo más probable con planeación, presupuesto o propuesta económica.
2. Al revisar la precisión de las estimaciones, asegurarse que el esfuerzo estimado y aplicado son comparables.
2.8 Fuentes de error de las estimaciones
McConnell (2006) identifica una serie de fuentes de error en el proceso de estimación de esfuerzo de desarrollo de software:
1. Incertidumbre del proyecto. Todos los proyectos tienen un cierto nivel de incertidumbre respecto al esfuerzo a aplicar, y esta incertidumbre es mucho mayor al inicio del proyecto y va disminuyendo durante la vida del mismo. Si graneáramos el nivel de incertidumbre respecto a la vida del proyecto, la imagen es similar a la de un cono (cono de incertidumbre). Aún los proyectos mejor llevados conllevan un nivel de incertidumbre.
2. Proceso de desarrollo caótico, por ejemplo, con requerimientos tomados a la ligera, falta de validación de requerimientos del usuario final, diseńo pobre, prácticas de codificación pobres, personal inexperto, planeación de proyectos incompleta, miembros del equipo con aires de superioridad, abandonar la planeación del proyecto ante la presión, falta de control automático de versiones, entre muchos otros ejemplos.
3. Requerimientos inestables, que hacen que un proyecto se suma en el caos, pero también pueden provocar que los nuevos requerimientos no se documenten debidamente y por lo tanto no se genere una nueva estimación basada en estos requerimientos.
4. Omitir actividades, tanto a nivel individual como a nivel de proyecto. Estas actividades pueden ser tanto para requerimientos omitidos, para actividades de desarrollo de software y para actividades no relacionadas al desarrollo. 5. Optimismo infundado, esperando aumentar la productividad respecto al
proyecto anterior, cometer menos errores que en el pasado, atenuar rápidamente la curva de aprendizaje, etc.
6. Subjetividad y polarización, donde interviene tanto la experiencia previa del estimador, como sus habilidades y nivel de optimismo. Las principales manifestaciones son optimismo, polarización consciente y polarización inconsciente.
7. Estimaciones de la manga, sin bases, fundamentos o justificaciones y que suelen ser generadas bajo presión o como solicitudes informales.
8. Precisión sin garantías, tratando de dar más solidez a la presentación de las estimaciones solo se provocan expectativas difíciles de cumplir.
2.9 Influencias de las estimaciones
1. Tamańo del proyecto, debido a las deseconomías de escala, esto es, entre más grande es un proyecto, más esfuerzo por unidad. 2. Tipo de software a ser desarrollado: si se desarrolla software vital en algún sentido, se puede esperar mucho mayor esfuerzo que en un proyecto de tamańo similar en un área de negocios. En lo general, es conveniente utilizar los datos históricos de la organización para incorporar el factor específico a la industria en cuestión. 3. Lenguaje de programación, indicando que puede tener un impacto hasta del 40%, de acuerdo a los datos de COCOMO II, debido a que algunos lenguajes ofrecen mayor funcionalidad que otros por línea de código. 4. Factores personales, entre los que destacan los siguientes: a. Capacidad del analista de requerimientos, es decir, la capacidad para generar y especificar correctamente los requerimientos de un sistema. Es el factor más influyente de todos. b. Capacidad (en general) del desarrollado^ tanto eficiencia como eficacia para desarrollo. c. Rotación del personal, entre mayor sea, mayor será el esfuerzo necesario para ejecutar un proyecto. d. Experiencia en el área de negocios de la aplicación. Equipos que no están familiarizados con el área del proyecto requieren significativamente más tiempo. e. Experiencia en el lenguaje y herramientas de desarrollo. Equipos con experiencia en el lenguaje y herramientas de desarrollo trabajan moderadamente más eficientes que los que están aprendiendo. f. Experiencia en la plataforma. Experiencia en la plataforma tecnológica reduce el esfuerzo necesario para completar un proyecto. g. Cohesión del equipo, que se manifiesta típicamente con interacciones cooperativas o contenciosas. h. De acuerdo a COCOMO II, estos factores combinados pueden provocar una diferencia de hasta 22 veces entre el mejor y el peor caso. Esta diferencia es sostenida por múltiples estudios al respecto.
2.10 Estimación de tamaño
Las unidades de tamańo pueden ser muy variadas, dependiendo del
método que se esté utilizando, y entre las más populares están las líneas de
código fuente (LCF), puntos de función (PF), puntos de objetos (PO) y puntos de características (PC). Cada unidad es única en el sentido de que no puede expresarse directamente en términos de alguna otra, además de que representan el tamańo de una aplicación de software desde diferentes perspectivas (Parthasarathy, 2007).
El cálculo del tamańo de una aplicación de software adquiere mayor interés durante la evaluación de proveedores para el desarrollo de la aplicación, incluso para determinar si la aplicación debe desarrollarse internamente o por un equipo externo. Permite también que se soliciten cotizaciones basadas en tamańo y plataforma de desarrollo. Además, permite que el dueńo o patrocinador de la aplicación pueda mantenerse ajeno a los detalles del proceso de desarrollo de software.
2.11 Productividad de desarrollo
Conocer la capacidad de producción del equipo de desarrollo es uno de los elementos críticos de las estimaciones de esfuerzo de desarrollo de software. Sin embargo, la medición de productividad de los programadores es un proceso largo e iterativo, que requiere de mucha disciplina organizacional e individual. En lo general, nos referiremos a la productividad de desarrollo como la razón entre tamańo del software entre unidad de tiempo, por lo que sus unidades dependerán del método de estimación de tamańo. Por ejemplo, si utilizamos líneas de código como unidad de tamańo, la productividad la mediríamos en líneas de código por mes, por día o por hora (Parthasarathy, 2007).
La cantidad de líneas de código fuente por programador/mes es una métrica muy utilizada para la productividad, y se obtiene contando el número total de líneas de código fuente de la aplicación de software y dividiendo entre el tiempo total de programadores/mes aplicados en el proyecto. De esta manera se consideran todas las etapas del ciclo de vida del proyecto, aún las que no generan código fuente (Sommerville y Flores Suárez, 1988).
Los elementos que mayor impacto tienen en la productividad de un equipo de desarrollo de software son:
1. La aplicación de software, incluyendo su contexto, finalidad, objetivo, etc.
2. El proceso de desarrollo, que define las etapas y actividades de cada etapa durante el ciclo de vida de desarrollo de software
3. El ambiente de desarrollo de software, donde la robustez de los mecanismos de control de calidad y la reutilización de componente de software mejoran la productividad.
Parthasarathy (2007) también menciona que la productividad de una organización o equipo de proyecto debe especificarse en base a las competencias de los programadores, una tecnología específica y un ambiente de desarrollo específico, ya que las diferencias entre estos parámetros pueden tener una influencia muy amplia en la medición de la productividad, sin mencionar el efecto que podrían generar las deseconomías de escala. En este mismo sentido, Sommerville y Flores Suárez (1988) comentan que la modificación de por ejemplo el lenguaje de programación utilizado vuelve incorrecta la productividad, ya que diferentes lenguajes requieren un número diferente de líneas de código para implementar la misma funcionalidad.
2.12 Cálculo del esfuerzo de desarrollo
Parthasarathy (2007) menciona que la estimación de esfuerzo de un proyecto de desarrollo de software es dependiente de dos entradas críticas: tamańo de la aplicación y productividad del equipo de proyecto, y proporciona los siguientes pasos para obtener una estimación de esfuerzo de desarrollo de software:
1. Dadas las especificaciones de una aplicación, calcular el tamańo.
2. Asegurarse de contar con la productividad del equipo del proyecto para la plataforma tecnológica de la aplicación. Si no se tuviera, existen promedios de productividad de la industria para cada lenguaje y plataforma, que deberán ser ajustados con datos históricos del equipo de proyecto.
3. Convertir el tamańo de la aplicación a esfuerzo, multiplicando el tamańo de la aplicación por la productividad del equipo de proyecto, el resultado en debe convertirse para quedar en mesespersona.
Capítulo 3 Metodología y contexto del problema
3.1 Explicación del modelo particular
El modelo particular está diseńado para encontrar la relación entre las características de la estimación, las características del proyecto y la precisión de la estimación de esfuerzo inicial, así como la relación entre las características del equipo de desarrollo con el esfuerzo realmente aplicado (ver Figura 31).
[image:41.612.70.511.235.673.2]Además, según McConnell (2006), existe una fuerte relación entre el estimador y sus polarizaciones personales y la precisión de la estimación, así como entre el tipo de software a desarrollar y el esfuerzo a aplicar.
Grimstad y Jorgensen (2006) encontraron también relaciones entre la experiencia en proyectos similares y la disminución del error en las estimaciones de esfuerzo.
Aunque el problema es esencial y siempre ha estado presente, es muy común que los responsables de la administración y/o patrocinio de proyectos de desarrollo de software lo ignoren y se repitan las mismas prácticas que llevan a estimaciones de esfuerzo equivocadas.
Esta situación, sin embargo, ha sido poco estudiada en México y en especial en la zona metropolitana de la ciudad de Monterrey, Nuevo León, de tal suerte que no se ha podido localizar un solo estudio en la región ni en el país respecto a estimaciones para proyectos de software.
3.2 Tipo de Investigación
De acuerdo a los objetivos de esta investigación, el presente estudio se clasifica como exploratorio, que según la clasificación de Hernández Sampieri, Fernández Collado, y Baptista Lucio (2006) "se realizan cuando el objetivo es examinar un tema o problema de investigación poco estudiado, del cual se tienen muchas dudas o no se ha abordado antes...o bien, si deseamos indagar sobre temas y áreas desde nuevas perspectivas".
Los estudios exploratorios sirven para "...obtener información sobre la posibilidad de llevar a cabo una investigación más completa respecto de un contexto particular" (Hernández Sampieri et al., 2006). El campo de estimaciones de esfuerzo de desarrollo de software en Monterrey, Nuevo León, se considera poco estudiado ya que no se encuentran referencias en la literatura, además de que el campo mismo muestra una variación muy amplia con el paso del tiempo.
El estudio será no experimental ya que "no se manipularán deliberadamente las variables, es decir, no hacemos variar en forma intencional las variables independientes para ver su efecto sobre otras variables. Lo que hacemos...es observar fenómenos tal y como se dan en su contexto natural, para después analizarlos" (Hernández Sampieri et al., 2006).
ai. (2006) recolectan datos en un solo momento, en un tiempo único y su propósito es describir variables y analizar su incidencia e interrelación en un momento dado.
Por lo tanto, el diseńo de este estudio es transeccional exploratorio, cuyo propósito es comenzar a conocer una variable o un conjunto de variables, en un momento específico, y que se aplican a problemas de investigación nuevos o poco conocidos, constituyendo el preámbulo de otros diseńos. Sus resultados son exclusivamente válidos para el tiempo y lugar en que se efectuaron.
3,3 Población
Para la presente investigación se requieren personas que participen en los procesos de estimación de esfuerzo de desarrollo de software, tanto para uso interno como para su comercialización. Además, deben estar ubicadas en el área metropolitana de la ciudad de Monterrey, Nuevo León.
Como referencia, la industria de desarrollo de software en Monterrey representa alrededor del 13% del total nacional, y junto con Jalisco, Sinaloa y DF, representan en conjunto el 70% del total nacional (González Báńales, 2005).
3.4 Muestra
Se utilizará para la presente investigación una muestra no probabilística, en la que de acuerdo a Hernández Sampieri et al. (2006) "la elección de los elementos no depende de la probabilidad...sino de causas relacionadas con las características de la investigación o de quien hace la muestra". Para la muestra, se elegirán personas directamente relacionadas a los procesos de estimación, como administradores de proyecto, ejecutivos comerciales, líderes de proyecto o estimadores especialistas.
indicadores de la industria de tecnologías de información, directorio de empresas de tecnologías de información, 2007).
Además, para la selección de la muestra se tomó en cuenta que se tuviera experiencia en la estimación de esfuerzo de desarrollo de software, ya sea como parte de las responsabilidades y actividades actuales como de anteriores.
3.5 Variables
De acuerdo a la clasificación de Hernández Sampieri et al. (2006), las variables forman una relación causal multivariada. Estas variables se han encontrado por separado en los modelos propuestos por diferentes estudios: Jorgensen (2007), Boehm (2000), McConnell (2006), entre otros. McConnell (2006) menciona que en los datos de COCOMO II se encuentran datos estadísticos respecto a la influencia de cada variable, pero esta influencia depende a su vez de los valores de las otras. Por ejemplo, el efecto del tipo de software a desarrollar depende también del nivel de experiencia del equipo de desarrollo.
Esta compleja relación se discute ampliamente en Brooks (1987), explicando la dificultad esencial del desarrollo de software y por consiguiente de su estimación de esfuerzo, sobre todo si esta es antes de iniciar el proyecto, y se menciona a la estimación de esfuerzo de desarrollo de software como una de las actividades más complejas realizadas por el hombre.
Las variables que se medirán son: 1. Variables independientes
i. Parámetros y técnicas de estimación utilizados
a. Datos históricos de proyectos anteriores: tamańo y esfuerzo
b. Finalidad de las estimaciones: propuesta al cliente, compromiso de proyecto, tiempo más probable de desarrollo.
ii. Características del estimador
a. Experiencia en estimaciones y manejo de las técnicas de la organización
b. Polarización por el rol desempeńado en el desarrollo iii. Características de la compańía que desarrollará el software
a. Tamańo de la compańía o departamento: pequeńo, mediano, grande
b. Tamańo máximo del equipo de desarrollo: menos de 5, entre 5 y 10, más de 10 personas
e. Experiencia en estimaciones de proyectos anteriores: żcuenta con registro o base de datos de proyectos anteriores?
iv. Características del proyecto
a. Tamańo del proyecto: Rango de puntos de función (FP) b. Ambiente de desarrollo: hostil/amistoso, estable/inestable
c. Tipo de software a producir: aplicaciones de negocios, aplicaciones de tiempo real, aplicaciones médicas.
2. Variables dependientes
i. Esfuerzo inicial estimado, en meses/hombre ii. Esfuerzo realmente aplicado, en meses/hombre
iii. Precisión de la estimación en base al error relativo, donde el error relativo se calcula como
iv. Error Relativo (RE) = (Esfuerzo Aplicado Esfuerzo Estimado) / Esfuerzo Estimado
3.6 Instrumento de Recolección de Datos
De acuerdo a las variables mencionadas en el modelo particular y tomando en cuenta los objetivos del presente estudio, se elaboró una encuesta para llevar a cabo la recolección de datos (ver
Anexo A. Encuesta aplicada). La encuesta se dividió en 3 secciones:
1. Características de la organización donde se desempeńa la persona encuestada
2. Características del estimador
3. Características de los proyectos estimados
La sección 1 incluye los datos generales de la persona encuestada, como edad, sexo, puesto desempeńado y ańos en el puesto. Incluye además los datos generales de la organización, tales como tamańo según el número de empleados, el sector de la industria al que pertenece, así como las prácticas de estimación de la organización.
La sección 3 se refiere a las características de los proyectos, tales como tamańo promedio, estilo de desarrollo, ambiente de desarrollo, y algunas otras.
Se generó una versión inicial o piloto de la encuesta que fue aplicada a dos personas, y en base a sus comentarios se ajustó la encuesta para aclarar los puntos que causaron confusión durante el piloto.
3.7 Estrategia de Recolección de Datos
Este estudio utilizará como instrumento de recolección de datos la encuesta o cuestionario, que de acuerdo a Hernández Sampieri et al. (2006) "consiste en un conjunto de preguntas respecto a una o más variables a medir". Se utilizarán preguntas cerradas en la medida de lo posible para aprovechar su facilidad de codificación y preparación para su análisis.
La encuesta se aplicó de manera auto administrada, lo que significa que el cuestionario se proporcionó directamente a los participantes para su contestación, pero en dos contextos: individual y por envío vía correo electrónico.
Los datos se registrarán y almacenarán en una base de datos en formato Microsoft Office Access 2007.
3.8 Análisis de Datos
Capítulo 4 Análisis de Resultados
4.1 Información general
La encuesta se diseńo con tres secciones que corresponden a los grupos de factores más influyentes en la precisión de las estimaciones, de acuerdo a McConnell (2006).
Estos grupos están representados como variables independientes dentro del modelo propuesto, y corresponden a las secciones de Características de la organización, Características del estimador y Características de los proyectos.
4.2 Respuestas a la encuesta
En total se recibieron respuestas de 22 encuestas entre el 27 de agosto y el 9 de septiembre del 2007 de un total de 25 enviadas, dando una tasa de respuesta del 88%. La encuesta fue el único instrumento de recolección de datos utilizado, y se aplicó según el plan en un esquema auto administrado, mediante aplicaciones individuales y enviadas por correo.
Para proteger la confidencialidad de las empresas que forman parte de la muestra, la encuesta no recopiló el nombre de la organización donde se desempeńan los que las respondieron.
El procedimiento para recolección de datos inició con la solicitud de encuesta vía telefónica o por correo electrónico. Posteriormente se les envió vía correo electrónico o en persona, de acuerdo a las preferencias y disponibilidad de la persona.
4.3 Tamaño de la muestra
Se consideró el error muestral definido con la siguiente ecuación:
E = Z * V * (1 P) * Nn
n Nl
donde:
E = error muestral
Z = nivel de confiabilidad p = probabilidad de éxito n = tamańo de la muestra N = tamańo de la población
Entonces, para determinar el tamańo de la muestra en la estimación de la proporción media se tendrá:
donde:
n' = tamańo de la muestra sin ajustar
Aplicando el factor de corrección en poblaciones finitas, el ajuste en el cálculo del tamańo de la muestra es:
n' = V * (1 P)
E2
n n =
Aplicando los parámetros esperados en la presente investigación Z = 0.95
p = 0.935 E = 0.05 nos queda:
