Aunque cada vez existan más técnicas que facilitan el diseño y desarrollo de los sistemas, las nuevas exigencias de los usuarios y los nuevos dominios de aplicación generan nuevos problemas. Esto crea la necesidad de prestar cada vez más atención a los procesos de planificación, medición y estimación de diversos parámetros software, antes de comenzar con el desarrollo propiamente dicho.
1.1 PROCESO DE ESTIMACIÓN en el ámbito software se hacen las estimaciones en estas fases iniciales, dichas previsiones pueden estar basadas en unos requerimientos erróneos o incompletos, por lo que disminuye mucho su fiabilidad. El proceso de estimación del coste de un producto software está formado por un conjunto de técnicas y procedimientos que se usan en la organización para poder llegar a una predicción fiable.Se divide en los siguientes pasos–
Estimación del tamaño. – Estimación del costo y del esfuerzo.
– Estimación de la programación temporal. – Estimación de la cantidad de recursos computacionales. – Asunción de riesgos. – Inspección y aprobación. – Redacción de informes de estimación – Medición y perfeccionamiento del proceso.
La cantidad de esfuerzo y tiempo dedicada a la estimación depende del tamaño del proyecto, del equipo de desarrollo y del objetivo a cumplir. La naturaleza del proyecto y el entorno en el que se desarrolla son factores determinantes en esta tarea, y afectan en gran medida al método de estimación que se utilice.
existen dos maneras diferentes de estimar el presupuesto y el tiempo para un proyecto software: usando modelos de costo y usando razonamiento basado en similitud. En ambas opciones es necesario recurrir a información histórica y de proyectos anteriores previamente almacenados en bases de datos.
Existen cuatro puntos fundamentales sobre los que se apoya la estimación:
– Las consideraciones y opiniones de los profesionales de la materia, basada en la experiencia y la madurez de los gestores de proyecto, los cuales tendrán que adivinar y predecir el tiempo de realización del proyecto o su coste.
– La participación de expertos, cuyas opiniones no deben ser consideradas y abordadas como las de los profesionales y gestores de proyecto, ya que los expertos no pertenecen a la organización y pueden estar no familiarizados con las prácticas propias de la organización.
– La utilización de factores estándar de tiempos, calculados y establecidos a partir de proyectos anteriores.
– Por último el empleo de fórmulas y funciones, que implica la existencia de datos cuantitativos que representen una buena aproximación a la estimación. Además no deben existir dudas acerca de la fiabilidad y seguridad del predictor usado.
1.2. MEDIDAS Y MÉTRICAS DEL SOFTWARE
Una medida indica cuantitativamente algún atributo de proceso o de producto (extensión, cantidad, dimensiones, capacidad, tamaño, etc.). Una métrica es definida por el Glosario de estándares del IEEE (Institute of Electrical and Electronics Engineers) [IEE93] como una “medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo determinado”.Si se recopila un sólo tipo de datos, como por ejemplo el número de errores dentro de un componente, se ha establecido una medida. Una métrica de software relaciona de alguna manera las medidas individuales. Siguiendo nuestro ejemplo, podríamos tratar el número de errores encontrados en cada revisión o pruebaLos ingenieros de software, a partir de las medidas, elaboran métricas que les proporcionan información para poder controlar el proceso o el proyecto software. Aquí radica la diferencia entre estos términos.
1.3. CLASIFICACIÓN DE LOS MODELOS DE ESTIMACIÓN
Los diferentes modelos de estimación para proyectos pueden ser clasificados de diversas maneras, de entre las cuales se deben destacar las aportadas por dos autores principales
Según Basili Según este autor existen tres modelos:–
Modelos con una o varias variables estáticas, que se basan en aplicar funciones y constantes a algunas propiedades del proyecto, por ejemplo el LOC (Lines Of Code). – Modelos con varias variables dinámicas, que miden el tiempo del proyecto frente a su costo, usando una distribución obtenida de manera empírica. – Modelos teóricos con algoritmos prediseñados, que se basan en una hipótesis para realizar una predicción a través de una función obtenida teniendo en cuenta información histórica.
Según Kitchenham Kitchenham propone una clasificación más simple para estos modelos, basada en distinguir entre aquellos que especifican la relación entre varios parámetros de costo, llamados modelos de restricción, y los que predicen el valor de un parámetro de costo, llamado modelos de factor empírico. Como ejemplo de esta clasificación podemos encontrar entre los modelos de restricción los de Putnam, Jensen, Cocomo, o Parr. Algunos modelos de factor empírico son Esfuerzo de Cocomo, Wolverton, Softcost, Estimacs, o Price.
Otras clasificaciones Otras maneras más simples de clasificar los modelos de estimación distinguen tres categorías básicas: – Juicio experto: aunque no es un método en el sentido estricto de obtener resultados de una manera explícita y repetitiva, es una de las prácticas más extendidas, en las que se combinan las opiniones de varios expertos para obtener estimaciones, como por ejemplo el método Delphi.
– Modelos algorítmicos:
se basan en fórmulas y parámetros con los que realizan las estimaciones. Son también muy conocidos y empleados en la actualidad, encontrándose en este grupo el modelo
COCOMO o puntos de función.
–
Analogía:
puede ser tomada como una variante del juicio experto, ya que también intervienen las opiniones de los estimadores, pero a diferencia de este tipo, necesita caracterizar claramente el proyecto que se va a estimar y almacenar los proyectos previos para buscar entre ellos el más parecido al actual.
1.4. PROBLEMAS PRESENTADOS POR LA ESTIMACIÓN DEL ESFUERZO DE PROYECTOS SOFTWARE
En la práctica, todos los modelos de estimación presentan una serie de problemas:
– Dan unas predicciones muy deficientes cuando se aplican sobre conjuntos de datos independientes entre sí.
– Están basados en apreciaciones subjetivas acerca de las variables de entrada, y por tanto ofrecen resultados muy diferentes cuando se aplican sobre el mismo problema, ya que estas valoraciones están muy influidas por el medio en el que se desarrolla el proyecto y su entorno.
– Estiman el tiempo o costo sólo para las últimas etapas del proceso de desarrollo, olvidándose en la mayoría de los casos las iniciales.
– Usan KLOC (Thousand of Lines of code) o KDSI (Thousand of Delivered Source Instruction) como factores, para estimar el tiempo o costo inicial de la fase de codificación, constituyéndose como base para la estimación del resto de etapas, a pesar de aquellas recomendaciones que afirman que estos factores no son del todo apropiados.
– El factor KDSI no tiene en cuenta los recursos disponibles para el equipo de desarrollo (como herramientas software), ni las carácterísticas propias del equipo, como por ejemplo su grado de experiencia. Sin embargo, como resultados de diversos estudios y experimentos, se demuestra cómo la capacidad del equipo de desarrollo es uno de los factores que más afectan al tiempo total de realización del proyecto.
1.5. MODELOS DE ESTIMACIÓN SOFTWARE
Hay dos aproximaciones principales para estimar el volumen de un proyecto software: paramétricas y heurísticas
1.5.1. Aproximaciones paramétricas
Las estimaciones paramétricas usan como predictor una métrica determinada fácilmente al comienzo del ciclo de vida del software. Una buena métrica nos asegura una correcta correlación con el esfuerzo del proyecto, y facilita la estimación del mismo. Las dos métricas más comúnmente usadas son el número de líneas del código fuente (SLOC. Source Lines of Code) y los puntos de función (FP, Function Points). Para sistemas dirigidos por datos, domina el uso de puntos de función. Es con sistemas dirigidos por computación con los que es más frecuente el uso de SLOC,
COCOMO COCOMO (COnstructive COst MOdel) fue propuesto por Barry Boehm en 1981, y es un ejemplo claro de micromodelo con tecnología ascendente. Además, es el modelo de estimación de costes más utilizado. El principal cálculo en el modelo COCOMO es el uso de la ecuación del esfuerzo para estimar el número de personas o de meses necesarios para desarrollar el proyecto. El resto de resultados del modelo se derivan de esta medida.
ESFUERZO = A x TAMAÑOB En esta sencilla ecuación, A y B son constantes obtenidas empíricamente y dependientes del modo de desarrollo. La estimación del tamaño del proyecto queda expresada en SLOC, definida con las siguientes reglas: – Líneas de código creadas por el personal del proyecto (no el creado por generadores de aplicaciones). – Una instrucción es una línea de código. – Las declaraciones se toman como instrucciones. – Los comentarios no se cuentan como instrucciones.
En COCOMO es fundamental el término que hace referencia al modo de desarrollo del proyecto, que influye directamente en el costo y duración del mismo, y que puede ser:
– Modo orgánico
Cuando el proyecto es desarrollado en un ambiente familiar y estable, y en el que el producto es similar a otros desarrollados previamente. Son además productos pequeños y poco novedosos, con unos requerimientos definidos y poco rígidos.
– Modo empotrado
Para proyectos caracterizados por unos requerimientos y restricciones poco flexibles, que requieren un gran esfuerzo de innovación. También poseen un elevado nivel de complejidad hardware.
– Modo semiacoplado:
es un modelo para proyectos que presentan carácterísticas intermedias entre el orgánico y el empotrado, con un equipo formado por miembros de distintos niveles de experiencia, que trabajan sobre un conjunto de requisitos más o menos flexibles
COCOMO está definido en términos de tres modelos diferentes: modelo básico, intermedio y detallado, que reflejan el nivel de detalle considerado a la hora de realizar la estimación del coste. El modelo básico provee una estimación inicial poco refinada, el intermedio la modifica utilizando una serie de multiplicadores relacionados con el proyecto y el proceso, y el detallado realiza diferentes estimaciones para cada fase del proyecto. Éste último es el más complejo, y cuenta con más factores que influyen en el software, consiguiendo así mejores estimaciones.
COCOMO II es un modelo que permite estimar el coste, el esfuerzo y el tiempo cuando se planifica una nueva actividad de desarrollo software, y está asociado a los ciclos de vida modernos. Fue desarrollado a partir de COCOMO, incluyendo actualizaciones y nuevas extensiones más adecuadas a los requerimientos de los ingenieros software.
Este conjunto de modelos se divide en tres:
– Modelo de composición de aplicaciones, para proyectos de construcción de interfaces gráficas de usuario.
– Modelo de diseño preliminar, utilizado para obtener estimaciones sobre el coste de un proyecto, antes de que esté determinada por completo su arquitectura. –
Modelo post-arquitectura, que es el más detallado, y debe ser usado una vez determinada la arquitectura al completo.
El usar un modelo u otro depende del nivel de detalle del proyecto, de la fidelidad requerida de las estimaciones, y de la definición de los requerimientos y de los detalles de la arquitectura. De una manera general, podemos determinar en qué momentos es más adecuado la utilización de un modelo u otro:- El modelo de composición de aplicaciones se aplicará sobre todo en las primeras fases o ciclos en espiral.
– El modelo de diseño preliminar es útil para las siguientes fases o ciclos espirales, en los que se incluye la exploración de arquitecturas alternativas o estratégicas de desarrollo incremental.
– Una vez que el proyecto está listo para desarrollar y sostener un sistema especializado, el submodelo de Post-arquitectura proporciona información más precisa de los controladores de coste de entradas y permite cálculos de coste más exactos.
Factores que causan efecto en la economía del proyecto, y que son: –
Existencia de precedentes al proyecto. – Flexibilidad del desarrollo. – Resolución de riesgos. – Cohesión del equipo. – Madurez del proceso.
COCOTS Los modelos COCOTS (Constructive Commercial Off-The-Shelf) se utilizan en proyectos caracterizados principalmente por dos aspectos: su código fuente no está disponible para el desarrollador de la aplicación, y su evolución no es supervisada por el mismo. El desarrollo de software utilizando COCOTS implica cuatro actividades:
Valoración de los componentes COTS Esta actividad permite escoger productos software COCOTS para ser integrados en el sistema global. Los candidatos viables se determinan en función de una serie de carácterísticas: – Requerimientos funcionales: capacidad ofrecida. – Requerimientos de rendimiento: restricciones de tiempo y tamaño. – Requerimientos no funcionales: coste, formación, instalación, mantenimiento y fiabilidad. Esta valoración se realiza en dos fases. En la primera, se agrupan componentes viables, eliminando aquellos que no se adecuan al contexto actual, y en la segunda se hace una selección final de productos, en función de las carácterísticas que presentan.
Adaptación de componentes
En esta fase se configuran los productos COTS para ser usados en un contexto específico, realizando principalmente inicialización de parámetros, interfaces de usuario, distribución de los informes de salida, instalación de protocolos de seguridad, etc. Para poder medir y calibrar el esfuerzo empleado en realizar estas labores de adecuación e integración de productos COTS, se asigna a cada tarea de adecuación un valor concreto y establecido según la complejidad de dicha tarea. El esfuerzo total de la fase de adaptación es una función dependiente del número de productos COTS cuya modificación haya sido necesaria. La dificultad del proceso de adaptación se basa en los siguientes aspectos: – Especificación de parámetros. – Desarrollo de scripts. – Especificación de informes de entrada o salida, de interfaces gráficas de usuario. – Inicialización de protocolos de seguridad y acceso – Fiabilidad de las herramientas de adaptación utilizadas.
Código de uníón
En esta fase se ensamblan los diferentes productos COTS, para pasar a formar parte de un sistema mayor. Puede ser necesaria la uníón de productos COTS entre sí o bien con un sistema de un nivel superior.
Puntos de función
El análisis por puntos de función fue desarrollado a mediados de los setenta para intentar superar las dificultades asociadas al uso de las líneas de código como medida del tamaño del software, y para aportar un mecanismo para predecir el esfuerzo necesario para el desarrollo de un proyecto software.
El análisis por puntos de función puede ser usado también para comparar herramientas, entornos o lenguajes entre sí, bien dentro de una misma organización o entre varias. Esta es una de las grandes ventajas de este tipo de análisis. Los puntos de función ofrecen una medida de la funcionalidad entregada por la aplicación
Principales componentes del análisis por puntos de función Desde el momento en que los sistemas computacionales comenzaron a interactuar con otros computadores, fue necesaria la existencia de un límite o frontera alrededor de cada uno de estos sistemas antes de clasificar componentes. Este límite debe ser dibujado desde el punto de vista del usuario, es decir, delimitando el proyecto o aplicación a ser medida y la parte externa de la misma, o dominio del usuario. Una vez que se ha establecido dicha frontera, los componentes pueden ser clasificados, ordenados y tasados. Los cinco componentes principales son
– Entradas de usuario (External Inputs o EI):
son procesos elementales en los que los datos atraviesan la frontera desde fuera hacia dentro de la aplicación. Estos datos pueden provenir de formularios de entrada por pantalla, o de otras aplicaciones, y puede ser información de control o relativa al negocio. Normalmente, los datos relativos al problema son usados para actualizar ciertos archivos relativos a la lógica interna del programa (Internal Logical Files).
– Salidas de usuario (External Outputs o EO):
al contrario que las EI, son procesos que atraviesan la frontera desde dentro hacia la parte externa de la aplicación o sistema. Esta información, que también actualiza ILF’s mediante la creación de informes o ficheros de salida, está orientada al programa. –
Peticiones de usuario (External Queries o EQ):
son procesos de entrada y salida que solicitan información contenida en los ILF’s y en los ficheros de interfaces, sin realizar ningún tipo de actualización de ficheros. Son entradas interactivas que producen la generación de alguna respuesta del software inmediata en forma de salida interactiva. – Ficheros de lógica Interna (Internal Logical Files o ILF): archivos de datos relacionados entre sí que residen en el interior del sistema, como parte de una gran base de datos o como ficheros independientes. –
Ficheros Externos de Interfaz external Interface Files o EIF): Son datos que residen fuera de la aplicación y son mantenidos por otras diferentes. Son ILF para otras aplicaciones, y son usados sólo como referencia. Engloban todas las interfaces legibles por la máquina que se utilizan para transmitir información a otro sistema.
1.5.2. Aproximaciones heurísticas Bottom – up
Esta filosofía de estimación divide el proyecto en pequeñas partes, aplicándole a cada una evaluación directa del esfuerzo. El valor obtenido se normaliza en función del peso y la importancia de cada parte. Posteriormente se irán uniendo estas partes en subsistemas. La principal ventaja que aporta este sistema, es que las personas que realizan la estimación son las mismas que van a hacer el desarrollo. Sin embargo, tiene el inconveniente de que normalmente no se cuenta el tiempo de estimación, que suele ser importante. Otra desventaja sería que si se descubren errores en las partes finales del proceso, habría que rechazar prácticamente toda la estimación hecha hasta el momento
Top – down
En primer lugar se estiman los costes a nivel de sistema, de una manera general, para posteriormente ir obteniendo los costes de cada uno de los diferentes subsistemas identificados [AGA01]. Juicio experto: técnica Delphi La técnica Delphi se basa en la obtención de un consenso de un grupo de expertos, que expresan sus opiniones y ofrecen estimaciones sobre el proyecto en cuestión. Los expertos expresan sus opiniones mediante unos formularios que le son entregados y que rellenan de manera totalmente anónima. Estos cuestionarios contiene cada una de las estimaciones realizadas a nivel personal por cada componente del grupo.
1.5.3. Estimación para proyectos orientados a objetos: Lorenz y Kidd [LOR94] diseñaron un modelo de estimación exclusivo para proyectos software orientados a objetos. La importancia de este paradigma de programación hace que sea comentado junto al resto de técnicas de estimación. Esta técnica se desarrolla siguiendo los siguientes pasos: – Se hacen estimaciones siguiendo cualquier método propio de aplicaciones convencionales. – Posteriormente se aplica el modelado de análisis orientado a objetos, desarrollando casos de uso. – A partir de este modelo de análisis, se calcula el número de clases clave. – Determinar el tipo de interfaz a implementar, asociándole un multiplicador según la siguiente tabla:
– Multiplicar el número de clases clave por el multiplicador, para obtener una estimación del número de clases soporte. – Multiplicar el número total de clases por el número promedio de unidades de trabajo por clase (15-20 personas-día por clase, según Lorenz y Kidd). – Comprobar de manera cruzada la estimación basada en clase al multiplicar el número promedio de unidades de trabajo por caso de uso .
1.5.4. Estimación para desarrollo ágil
Se denomina proyecto ágil de software a aquel que reúne las siguientes carácterísticas [PRE06]: – Es muy difícil predecir aquellos requerimientos de software que persistirán y cuáles cambiarán con el tiempo. – Tienen el diseño y la construcción intercalados, de modo que se prueban los modelos de diseño conforme se crean. – El análisis, el diseño y la implementación no son predecibles. La estimación en este tipo de proyectos sigue los siguientes pasos: – Cada escenario de usuario se considera por separado, y se descompone en un conjunto de funciones y tareas de ingeniería software necesarias para desarrollarlo. – Cada tarea se estima por separado, con cualquier método, y el volumen mediante LDC o puntos de función. – Las estimaciones de cada tarea se suman para obtener una estimación de cada escenario. – El volumen del escenario se traduce en esfuerzo mediante la aplicación de datos históricos. – Las estimaciones de esfuerzo de cada escenario se suman con el fin de obtener el esfuerzo total de cada incremente de software.
– El volumen del escenario se traduce en esfuerzo mediante la aplicación de datos históricos. – Las estimaciones de esfuerzo de cada escenario se suman con el fin de obtener el esfuerzo total de cada incremente de software. 1.5.5. Estimación para proyectos de ingeniería web
Los proyectos de ingeniería web adoptan normalmente el modelo de proceso ágil. Por este motivo, es frecuente utilizar una medición de puntos de función modificada en conjunto con los pasos de la estimación en proyectos ágiles. Para calcular los puntos de función adaptados se utilizan los siguientes valores de dominio de información: – Por entradas se toma cada pantalla o formato de entrada (por ejemplo CGI-beans). – Salidas son cada página web estática o cada guión de página dinámica (ASP, ISAPI, etc.). – Tablas son cada tabla lógica en la base de datos más cada objeto XML, si éste es empleado para almacenar datos en un archivo. – Las interfaces siguen tomándose de igual manera que en puntos de función tradicional- – Consultas son cada interfaz publicada externamente, tales como las referencias externas DCOM o COM. Estos puntos de función calculados son un indicador razonable del volumen de una aplicación web.
1.5.6. Herramientas software de apoyo a la estimación PRICE-S
El modelo PRICE-S (Programming Review of Information Costing and Evaluation Software) fue desarrollado por RCA PRICE Systems. Su filosofía se basa en evitar que los conceptos e ideas sobre las que se apoya el modelo son inaccesibles para el usuario, como es el caso de COCOMO y Puntos de función, que son presentados a los usuarios como una caja negra. Porello, el usuario de PRICE-S envía sus peticiones a un ordenador que trabaja a tiempo compartido situado en EE.UU, Reino Unido o Francia, y devuelve sus estimaciones inmediatamente [HEE92].