Diferencia entre revisiones de «Estimación de proyectos software»
Contenido eliminado Contenido añadido
Sin resumen de edición |
Sin resumen de edición |
||
Línea 1:
<div class="messagebox cleanup">Este ''recurso de aprendizaje'' es una lección creada originalmente como material didáctico del ''proyecto de aprendizaje'' [[Dirección y Gestión de Proyectos y Sistemas Informáticos]].</div>
La estimación de proyectos software es una tarea muy compleja, pero de vital importancia en toda la etapa de desarrollo del software.
==Introducción==
Estimar es difícil, ya que:
Línea 15 ⟶ 17:
* Buena información histórica.
* Confianza en las métricas y la experiencia.
La estimación depende de varios factores:
* Complejidad del proyecto.
Línea 22 ⟶ 28:
* Estructura de la información.
* Disponibilidad de información histórica.
Algunos de los principios que hay que tener presentes:
* Retrasar la estimación lo máximo posible. Cuanto más se retrase, más precisa será.▼
* Ley de Parkinson. El trabajo se extiende para rellenar el tiempo disponible.▼
* Precio para ganar. El coste se estima en todo el dinero que el cliente puede gastar en el proyecto.▼
*
*
==Estimación de recursos==
Línea 30 ⟶ 44:
* Fecha cronológica en la que se requiere.
* Tiempo durante el que será aplicado.
Respecto al personal hay que especificar su posición en la organización y su especialidad.<br/>
Los componentes software, por su parte, pueden estar:
* Ya desarrollados.
* Ya experimentados.
Línea 37 ⟶ 53:
* Nuevos.
==
Técnicas de estimación:▼
▲* Retrasar la estimación lo máximo posible. Cuanto más se retrase, más precisa será.
▲* Estimación por analogía. Utilizar el coste de proyectos similares.
▲* Ley de Parkinson. El trabajo se extiende para rellenar el tiempo disponible.
▲* Precio para ganar. El coste se estima en todo el dinero que el cliente puede gastar en el proyecto.
▲* Técnicas de descomposición. Estimas el coste descomponiendo el producto y/o el proceso.
▲* Modelos empíricos. Modelos de regresión que relacionan esfuerzo con tamaño o funcionalidad.
▲==Modelos paramétricos de estimación==
La estructura global de los modelos paramétricos de estimación es:<br/>▼
''<big>E = A + Bx^C <br/></big>''▼
donde: <br/>▼
E: esfuerzo (pm)<br/>▼
A, B, C: constantes obtenidas empíricamente<br/>▼
x: variable de estimación (LDC o PF)<br/><br/>▼
Para la mayoría de los proyectos, el factor fundamental del coste es el
esfuerzo. El esfuerzo es el número de personas-mes necesarias para desarrollar el
Línea 88 ⟶ 64:
esfuerzo y el coste de desarrollar un proyecto.
A continuación se presentan algunas de las más conocidas técnicas de estimación.
▲====Juicio u opinión de expertos====
En su forma más simple, se basa en realizar una estimación del esfuerzo a partir de la experiencia y conocimiento de otras personas.
La organización puede disponer de tablas de estimación disponibles porque han ido guardando un registro a lo largo de su historia.
Los '''modelos de regresión o modelos algorítmicos''' son modelos derivados de la realización de análisis de regresión sobre proyectos anteriores.<br/>▼
===Modelos algorítmicos de estimación ===
▲La estructura global de todos los modelos paramétricos de estimación es:<br/>
▲''<big>E = A + Bx^C <br/></big>''
▲donde: <br/>
▲E: esfuerzo (pm)<br/>
▲A, B, C: constantes obtenidas empíricamente<br/>
▲x: variable de estimación (LDC o PF)<br/><br/>
▲Los '''modelos de regresión
Algunos modelos orientados a LDC son:<br/>
*Walston‐Felix: E = 5,2KLDC^0,91 (i)<br/>
Línea 107 ⟶ 93:
*Proyectos pequeños: E = ‐12,88+0,405PF (i)<br/>
Para el mismo valor de LDC o PF los modelos difieren por lo que necesitan calibración para las necesidades locales.<br/>
El modelo COCOMO original está compuesto de tres modelos:
*'''Básico''': Calcula el esfuerzo en función del tamaño estimado (KLDC).
Línea 123 ⟶ 110:
COCOMO es el modelo empírico más completo para la estimación del software publicado hasta la fecha.<br/>
▲Constituye una mejora y avance importante sobre COCOMO 81 y pasa a llamarse COCOMO II.
=====SLIM=====
Putnam (1991) desarrolló un modelo de restricciones denominado SLIM para proyectos que superan las 70 mil líneas de código (70 KLDC). Este modelo de estimación se propone encontrar las variables estratégicas del proceso de desarrollo de software, derivar de su comportamiento un sistema de ecuaciones e introducir dichas ecuaciones en una computadora para su estudio y análisis. (ii) <br/>
Encontrar estas variables o factores ha sido el objetivo de la mayoría de los estudios acerca de la estimación. En la mayor parte de los casos estos factores han sido ordenados según su importancia, pero no medidos de forma precisa. La ordenación es subjetiva, depende del individuo que la realiza o de casos particulares; este modelo lo que pretende es medir estos factores de forma objetiva y exacta, de forma que cualquier observador determinará los mismos valores y grado de influencia para los factores que están siendo estudiados.
Los '''modelos no algorítmicos o modelos heurísticos''' de estimación se basan también en la aplicación de algoritmos... pero algoritmos no deterministas. Las principales técnicas aplicadas son:<br/>
*Redes neuronales
*Minería de datos
Línea 144 ⟶ 131:
*Enfoque a nivel de sistema. Debido a que la estimación se basa en la experiencia previa en proyectos completados, tendrá en cuenta todos los subsistemas a implementar del proyecto.<br/>
Como inconvenientes:
*No suele identificar problemas a bajo nivel para los que sería conveniente emplearse a fondo en la estimación.<br/>
*Se olvida de pequeños subsistemas que no están previstos en principio a desarrollar.<br/>
*Tiene menos estabilidad que una estimación por componentes.<br/><br/>
En la '''estimación ''bottom-up''''' (de abajo a arriba), el coste de cada componente se estima por un individuo distinto, frecuentemente por la persona que será el responsable de su desarrollo. Después, esos costes son sumados para conseguir el total del producto.<br/>
Esta estimación es complementaria al ''top-down'', siendo las debilidades de esta última las virtudes de la primera, y viceversa. Debido a que la estimación ''bottom-up'' se centra en cada uno de los componentes, pierde de vista costes globales como la integración, gestión de calidad, etc.; que están asociados al desarrollo de un proyecto. Por todo esto, estas estimaciones suelen ser un poco optimistas.<br/>
Se ha de añadir que este tipo de estimación requiere un mayor esfuerzo que la ''top-down'', siendo esto en muchos aspectos una ventaja.<br/>
Además, una estimación ''bottom-up'' tiende a ser bastante más estable en el sentido de que los errores posibles en la estimación de varios componentes pueden compensarse mutuamente.
==Conclusiones==
Estimar el esfuerzo que nos requiere la realización de un proyecto debería ser siempre el primer paso que demos para acometerlo. En Ingeniería del Software una adecuada estimación es la base de toda planificación creíble y útil, por lo que debemos conocer las distintas técnicas existentes y usarlas (a menudo de manera combinada) como medio para elaborar un plan de proyecto orientado hacia el éxito.
==Referencias==
Línea 157 ⟶ 149:
*(ii) http://oa.upm.es/1105/1/PFC_FERNANDO_GOMEZ_FERNANDEZ.pdf
==
*[[Usuario:Josecgon|Josecgon]] ([[Usuario discusión:Josecgon|discusión]]) 10:57 15 oct 2014 (UTC)
*[[Usuario:Albertogil|Alberto Gil]] ([[Usuario discusión:Albertogil|discusión]]) 11:13 15 oct 2014 (UTC)
|