¡Descarga Técnicas de estimación y más Diapositivas en PDF de Desarrollo de Software solo en Docsity!
PONTIFICIA UNIVERSIDAD CATOLICA DEL ECUADOR
SEDE IBARRA
Recopilación por Ing. Juan Carlos Armas MSc. 11/05/ Técnicas de estimación de software Una de las tareas más complejas pero de vital importancia en la gestión de todo proyecto de desarrollo de software es la estimación de esfuerzo y costo, es causa frecuente de errores y puede significar la diferencia entre el éxito o el fracaso de los proyectos. Una estimación de proyectos de software puede tener diversos fines, analizar la viabilidad económica de un proyecto, elaborar una propuesta de servicios, determinar con exactitud el presupuesto de un proyecto luego que ha sido aprobado, determinar el precio de un software, entre otros. Dependiendo del grado de exactitud que necesitemos, aplicaremos un método u otro. Existen diversas técnicas de estimación de software, las que utilizan el juicio de experto, analogías por medio de comparación con proyectos anteriores y también están los modelos de estimación de proyectos de software como COCOMO II, análisis de puntos de función y COSMIC. A continuación, se presentan 10 técnicas de estimación de software. ¿Qué es una estimación de software? Una estimación de software es una predicción de cuánto tiempo durará o costará su desarrollo y mantenimiento. Si se trata de una estimación de tiempo, el esfuerzo puede expresarse en horas-persona u otra unidad, si se trata de estimación de costo, se puede expresar en la moneda de preferencia. El reto de elaborar estimaciones de software, es realizar predicciones realistas, basándose en información incompleta e incierta.
En Ingeniería de software y gestión de proyectos de software, las estimaciones se utilizan para: Desarrollar planes de proyectos. Elaborar planificaciones de iteración en desarrollo de software. Elaborar presupuestos. Realizar análisis de inversión. Fijación de precios de un software para un cliente empresarial. Análisis para determinar el precio en software dirigido al consumidor. Para planificar estrategia cuando se dispone a participar en subastas de contratos en los que participan varios proveedores. Tipos de estimación de software Las técnicas de estimación de proyectos de software se pueden clasificar en cuatro tipos: Estimación de software por juicio de expertos Los métodos de estimación de software por juicio de experto, consisten entregar la información de levantamiento de requisitos de software (por ejemplo el documento de especificación de requisitos de software ) y entregárselo a uno o varios conocedores del desarrollo de software y del área de negocio que se dispone representar en el nuevo sistema. Estimación de software por analogía Este tipo de estimación de proyectos de software consiste en comparar el desarrollo de software propuesto con proyectos previos similares. La ventaja sobre la estimación por juicio experto, es que la analogía se basa en experiencias que están documentadas, por lo cual esta se basa en números documentados.
Técnicas para medir y estimar el tamaño del software a partir de la complejidad de sus funcionalidades. 10 Técnicas de estimación de software Los tipos de estimaciones de software en los que se pueden clasificar las distintas técnicas. En lo que sigue del artículo, explicaremos las siguientes técnicas de estimación: Juicio de expertos: o 1 solo punto. o 3 puntos. Método Wideband Delphi. Estimación por analogía. Descomposición: o Top down. o Bottom up. Modelos de estimación de proyectos de software: COCOMO II. Puntos de función IFPUG. Puntos de función COSMIC. Estimación de proyectos ágiles por medio de Planning Poker. Estimación mediante juicio de expertos Posiblemente el juicio de experto sea la forma más común utilizada por muchos para obtener un estimado, ¿Parece fácil no? Simplemente consigue un experto con experiencia directa en el software que quieres desarrollar y su modelo de negocio, pásale los requerimientos de software y ve que te dice.
Claro está, debes asegurarte que todos tengan un mismo entendimiento de cómo debe funcionar el software a desarrollar y que se espera de él. También otro reto que las personas que van a hacer el estimado sean las que vayan a hacer el proyecto. Las técnicas de estimación mediante juicio de experto consideran siempre algún tipo de descomposición funcional del software en sus partes. Una vez que el experto o grupo de expertos ha dividido el problema en actividades, pueden proceder a asignar un estimado a cada una, por medio de las siguientes técnicas. 1.- Un solo punto En esta técnica se asigna únicamente un solo estimado a cada actividad, usualmente por una sola persona. Una vez que se tienen los estimados de cada actividad, se puede calcular la duración total. Esta es una de las técnicas más usadas, sin embargo tiene dos problemas, primero el estimado está altamente influenciado por el sesgo y las premisas del estimado. ¿Qué sucede si alguna pieza clave de información es omitida? ¿O algún aspecto no es considerado? Además, el estimado también podría “inflar” sus estimados. 2.- Tres puntos ¿Qué sucedería si en lugar de pedir un estimado como en el caso anterior pedimos 3 estimados? Más allá, ¿Qué opinarías si entregamos la especificación a tres expertos diferentes y vemos los estimados de cada uno? Si tenemos tres estimados podemos asignar a cada actividad una estimación pesimista, más probable y optimista, luego podemos determinar el estimado de la actividad por medio de una formula. La estimación de tres puntos no es campo exclusivo de la Ingeniería del software, de hecho el Project Management Institute (PMI) la describe en su guía del PMBOK 6 como un método de estimación. Siguiendo el
y Farquhar desarrollaron el método Wideband Delphi, que reduce las discusiones y debates. Para realizar una estimación Wideband Delphi se siguen los siguientes pasos:
- Un coordinador presenta a cada experto una especificación de software y el formulario de estimación.
- Cada experto trabaja individualmente en su estimación.
- Se sostiene una reunión en la cual los expertos hablan sobre posibles problemas en sus estimaciones, de esta manera cada experto proporciona Feedback a los demás sin influir directamente en el estimado final que producirá.
- Cada experto prepara un formulario de estimación y se los presenta al coordinador de forma anónima.
- El coordinador prepara un resumen y lo distribuye al grupo de expertos.
- El coordinador y los expertos se reúnen, viendo las variaciones en las estimaciones. También producen una estimación media.
- Los expertos votan de forma anónima si aceptan la estimación media. El voto debe ser unánime, si alguien vota que no se debe regresar al paso 3, es decir, el grupo debe discutir nuevamente los problemas en sus estimaciones, para luego elaborar nuevos estimados. Como puedes observar el hecho que los estimadores elaboren sus estimados sin comunicarse entre sí y que el voto en la estimación final sea anónimo elimina el sesgo de dinámica grupal, con lo que se busca obtener estimados más realistas. Estimación por analogía 4.- Métodos de estimación de software por analogía La estimación por analogía tiene como premisa que la organización debe contar con una base de datos en la cual se registre la información
necesaria sobre las características, duración real y costo real de proyectos previos. El reto de este método de estimación es el tener una base de datos lo suficientemente detallada que permita identificar las características de los proyectos y determinar si son comparables con el proyecto a estimar. Además, para una organización de constante innovación o muchos proyectos disimiles, puede ser un reto el aplicar este método. Su aplicación es factible si se están elaborando estimados de baja exactitud y alta incertidumbre, es decir si se tienen tolerancia de desviación respecto al estimado de 50% o más. También es más fácil su aplicación si la organización ejecuta proyectos similares y comparables entre sí. Estimación de software mediante descomposición. 5.- Descomposición Top-Down
Para aplicar este método, se necesita una estructura de desglose de trabajo (EDT) detallada, lo cual en Ingeniería de software implicaría prácticamente realizar todo el análisis y diseño de la solución. Por ende, es una técnica mejor empleada en proyectos que ya te han aprobado y que cuentas con presupuesto para todo el análisis que requiere realizar este tipo de estimación. Cada tarea de la EDT se estima individualmente, para luego ir agregando los estimados y tener números de mayor nivel. Al aplicar esta técnica obtendrás estimados de mayor exactitud que con el método Top-Down, sin embargo, la inversión de tiempo es mayor. Técnicas revisadas hasta ahora La principal diferencia entre las técnicas de descomposición y las técnicas de juicio experto vistas anteriormente es el análisis detallado del proyecto que estas implican. Para el caso de técnicas de juicio experto, si bien cada experto puede realizar un desglose de tareas en su análisis individual, la técnica no lo requiere (aunque es recomendable). Por otro lado, las técnicas de descomposición establecen formalmente la necesidad de analizar y diseñar la solución, en el caso de Bottom-Up, se requieren detalles que solamente se pueden lograr después que te has comprometido en el proyecto y cuentas con presupuesto y un equipo de trabajo asignado. Sin embargo, las técnicas de descomposición aún requieren que alguien (un experto) estime cada paquete de trabajo, lo que conlleva la posible aplicación de estándares disimiles entre un estimado u otro, así como sesgo, o que el estimador sea muy optimista y pesimista. A continuación, una serie de métodos que buscan evitar esta situación. Técnicas basadas en modelos de estimación de proyectos de software
Los modelos de estimación buscan producir estimaciones de proyectos de software a partir de fórmulas matemáticas que puedan aplicarse de igual manera de un proyecto a otro, trayendo como beneficio que todos los proyectos sean evaluados objetivamente, además, producen estimados exactos que se pueden desglosar y analizar en partes, por ejemplo, analizando el esfuerzo y costo de alguna funcionalidad especifica o módulo de software. 7.- COCOMO II Las siglas COCOMO significan Constructive Cost Model, o “Modelo constructivo de costos” en español (COCOMO II). El método COCOMO fue desarrollado originalmente por el Dr. Barry Boehm en 1981. Luego en los años 90 se realizó una actualización y a partir de 1995 se conoce como COCOMO II. COCOMO II está documentado en el Manual COCOMO II , disponible en el sitio web de la Universidad del Sur de California (University of Southern California). Para realizar estimaciones de proyectos de software, COCOMO II utiliza tres submodelos, cada uno con mayor nivel de fidelidad que el anterior, estos modelos son: Composición de aplicaciones. Diseño inicial (Diseño temprano). Modelos post arquitectura. El Modelo de composición de aplicaciones se utiliza para analizar el software a desarrollar y modificar, identificando componentes, subcomponentes, dividiéndolos y clasificándolos. Los modelos de diseño inicial y post arquitectura son los que producen la estimación, ambos utilizan las siguientes ecuaciones: Esfuerzo expresado en personas meses (E)= a (Kl)^b x m (X) donde: a, b: Constantes con valores asignados según el modelo que se esté
requerido es mejor que simplemente valernos de la opinión del estimador. COCOMO II con puntos de función La estimación de costos por puntos de función se basa en la cantidad de funcionalidad involucrada en el software a desarrollar, son útiles porque se basan en información que está disponible desde que se realiza el análisis del proyecto. Los puntos de función no ajustados miden un proyecto de software por medio de la cuantificación de las funcionalidades de procesamiento de información, clasificando las mismas en Entradas o salidas de datos, archivos lógicos internos o externos. Para cada uno se asigna una cantidad predeterminada de puntos de función, que nos aporta una medición funcional del software. COCOMO II sigue las mismas definiciones el método de puntos de función IFPUG, el cual veremos en más detalle en la siguiente técnica de estimación de proyectos de software. 8.- Puntos de función IFPUG
Si bien el Análisis de puntos de función puede utilizarse conjuntamente con COCOMO II, el método puede funcionar por sí solo como técnica para estimación de proyectos de software. Fue desarrollado originalmente por Allan Albrecht en 1979 mientras trabajaba para IBM, quien definió conceptos para medir el software a partir de valoraciones de funcionalidades entregadas al usuario y no a partir de aspectos técnicos, con la intención de producir valoraciones independientes de la tecnología y fases del ciclo de vida utilizado. El trabajo de Albrecht fue continuado por el grupo internacional de usuarios de puntos de función, quienes plasmaron sus conceptos en el método IFPUG-FPA. IFPUG-FPA realiza las valoraciones a partir de la funcionalidad del sistema, primero clasificándolas, luego asignando una complejidad y ponderación a cada una según unas tablas predefinidas, determinando así el valor de puntos de función. Para mayor información del método se recomienda la lectura de artículos sobre el método de puntos de función del IFPUG: > Introducción a la estimación de proyectos de software por puntos de función
Estimación de proyectos de software con puntos de
función: Determinar tipo de conteo y componentes
funcionales
El Análisis de puntos de función, mide el tamaño de los sistemas de información en base a la funcionalidad entregada a los usuarios desde una perspectiva externa de los requerimientos funcionales. Por lo tanto, la medición de los requisitos del software se expresa en término de las transacciones de negocio que el usuario puede ejecutar y de los datos de negocio que se pueden almacenar y acceder. Al ejecutar un Análisis de puntos de función se dice que estamos realizando un “conteo”. El primer paso a realizar es establecer el tipo de conteo y el segundo paso consiste identificar las transacciones y componentes de datos que vamos a contar. En esta segunda parte de la serie, presentaremos los distintos tipos de conteo que se pueden realizar y a describir cómo se identifican las transacciones de negocio y componentes de datos. En una tercera parte de la serie se profundizará sobre el cálculo y suma de los puntos de función.
¿Qué es el análisis de puntos de función?
Si estás buscando información introductoria sobre que es el método de puntos de función y cuáles son sus aplicaciones para estimar esfuerzo y costos en proyectos de software, o medir la funcionalidad entregada para efectos de facturación de servicios, te recomendamos la primera parte de esta serie.
> Estimación de proyectos de software por puntos
de función: Introducción
Para realizar un conteo de puntos de función, necesitas los siguientes pasos:
- Determinar el tipo de conteo de puntos de función.
- Identificar los componentes funcionales que formarán parte el conteo.
- Determinar el conteo de puntos función antes de ajuste.
- Determinar el valor del factor de ajuste.
- Calcular el conteo de puntos de función ajustado. En esta segunda parte de nuestra serie de estimación de proyectos de software con análisis de puntos de función nos enfocaremos en los pasos 1 y 2, relacionados con el tipo de conteo de identificación de componentes funcionales. En una tercera parte de la serie abordaremos el cómo realizar el conteo, determinar el factor de ajuste y calcular el conteo ajustado.
1.- Determinar el tipo de conteo de puntos de
función
Desde la perspectiva del análisis de puntos de función, existen 3 tipos básicos de proyectos de ingeniería de software, a saber: Desarrollo e instalación de una aplicación por primera vez. Modificación de una aplicación existente. Medición de una aplicación existente (No se está realizando ningún desarrollo de software). Respectivamente, existen 3 tipos de conteos de puntos de función que se pueden realizar: Conteo de puntos de función de un proyecto de desarrollo. Conteo de puntos de función de un proyecto de mejoras. Conteo de puntos de función de una aplicación.
¿Por qué necesitamos establecer el tipo de
proyecto y conteo?
Las reglas para sumar los puntos al final del conteo varían según el tipo de conteo que se esté realizando, por lo cual necesitas establecerlo desde el comienzo. Una de las actividades fundamentales en los proyectos de ingeniería de software, es el poder estimar el esfuerzo, medido en horas o jornadas que tomara el proyecto. La técnica del análisis de Puntos de Función (FPA) es considerada la principal herramienta para la medición funcional de productos de software y de los procesos involucrados en su desarrollo.
2.- Identificar los componentes funcionales que
formarán parte el conteo
Una vez definido el tipo de conteo de puntos de función, el siguiente paso es determinar los limites (frontera) y el alcance del conteo. El alcance del conteo será definido por la cantidad y complejidad de los componentes funcionales que integran la aplicación, es decir por los almacenes de datos, pantallas, reportes y otros componentes. Debes identificar todos los componentes estimables según el tipo de conteo: Proyecto de desarrollo: Debes contar los nuevos almacenes de datos, pantallas o reportes. Proyecto de mejoras: Debes identificar los almacenes de datos, pantallas o reportes que se estén modificando Conteo de una aplicación: Debes identificar los almacenes de datos, pantallas o reportes de toda la aplicación o parte de ella, según el alcance que tengas definido para el conteo. Al realizar el conteo, no debes realizar suposiciones sobre comportamientos que aparentemente faltan, si este es el caso, lo recomendable es retornar la documentación de ingeniería de requisitos de vuelta al emisor para que incluya la información que falte.
De esta forma el sistema pasa a estar compuestos por "funciones puras" que pueden ser reusadas o reemplazadas sin afectar a las demás. Viendo esta descomposición con un sencillo ejemplo, supongamos que estas diseñando un sistema de ventas al detal, entonces, este lo puedes dividir en un módulo de fijación de precios, módulo de inventario, módulo de ventas al público y módulo de reportes tributarios. Seguidamente, puedes dividir cada módulo en submodulos y estos a su vez en transacciones de negocio, como por ejemplo Fijar precio, Realizar venta, Registrar salida de inventario, emitir reporte de impuesto al valor agregado, entre otros. La descomposición en sus partes integrantes de mayor nivel de detalle se convertirán en las transacciones de negocio que serán sujeto del conteo de puntos de función. Para realizar la descomposición funcional también debes apoyarte en métodos de modelado funcional, como por ejemplo diagramas de bloques funcionales, diagramas de flujo de datos (DFD), técnicas de análisis de sistemas estructuradas y muchas otras. Para realizar la descomposición del sistema en sus partes integrantes, además de técnicas de ingeniería de software también puedes apoyarte en técnicas de la gerencia de proyectos (project management),
¿Cómo puedo validar que la descomposición
funcional está bien?
Puedes aplicar los siguientes criterios para asegurarte que cada transacción funcional que has identificado es un proceso único y que por ende no duplicaras el conteo: Tiene lógica de procesamiento como por ejemplo edición o validación que es diferente de otras transacciones similares. Accede una combinación única de campos y archivos. Puede ser definida y reconocida por el usuario. Fue definida a partir de un requerimiento de negocio (funcional) y no a partir de un requerimiento técnico. Es lógicamente independiente de otras transacciones. (Aunque es permisible que pueda ser desencadenada por otra transacción). Es desencadenada por un evento externo. Está orientada a un objetivo de negocio y no un objetivo técnico.
2.2 - Identificar los componentes de datos
Igualmente, las técnicas de modelado de datos, también conocida como diagramado entidad relación, que forman parte de la ingeniería de software son las que se usan para identificar los componentes de datos a contar. Por medio del modelado, identificas cuales son los datos del sistema y las relaciones entre ellos. Los archivos de datos son relacionados con las transacciones que los acceden formando una jerarquía. Los archivos constituyen grupos maestros lógicos de datos, vistos desde una perspectiva de usuario de negocio, tiende a ser creados como conjuntos de datos, aunque existen partes de los
datos que pueden ser modificados independientemente. Pueden ser del tipo de referencia para el negocio, es decir que sólo son leídos y usados para hacer cálculos en las transacciones de negocio pero que no son modificados. Se pueden clasificar en 2 tipos: Archivo interno: Almacena datos ingresados por las transacciones de sistemas internos. Archivo externo: Datos cuyo mantenimiento es realizado por otros sistemas externos. Los archivos de datos no incluyen archivos que sean creados por razones técnicas, de desempeño, seguridad o navegación. También corresponden con los datos permanentes, los datos temporales no están incluidos en esta definición. Para realizar el modelado de datos, sigue los siguientes pasos: A partir de la ingeniería de requisitos, elaborar el modelo de datos conceptual, el cual: o Es independiente de la tecnología de implementación. o Se usa para conversar con los interesados sobre los requerimientos iniciales. o Se construye revisando el modelo de actividad o flujo de datos y determinando a partir de este las necesidades de información para cumplir con los procesos. Traducir el modelo conceptual al modelo lógico de datos: o Documenta las estructuras que pueden implementarse en una base de datos. o Se documentan utilizando técnicas de modelado de datos y lenguaje de definición de datos. o La técnica de modelado más difundida es la de Entidad relación y al modelo que resulta se le conoce como diagrama entidad relación. o Existen otras técnicas de modelado de datos como el modelado de datos genérico y modelado de datos semántico. Traducir el modelo lógico al modelo físico de datos, el cual: o Organiza los datos en tablas físicas. o Contempla las definiciones para el acceso, desempeño y almacenamiento. o Suele documentarse en un “diccionario de datos” detallado. Luego: Tomas el modelo físico de datos o inclusive el modelo lógico, coloca en un listado las tablas y vistas. Clasifica cada tabla en interna o externa. La tabla será interna si el sistema que estamos desarrollando la modifica y externa si es modificada por un sistema externo. Una vez listado, habrás identificado los componentes de datos que formaran parte del conteo para medir la aplicación Las funciones estimables, son las transacciones de entrada, salida y consulta, así como los archivos internos y archivos de interfaz externa. Las funciones las puedes obtener de la documentación de desarrollo de sistemas a implementar. Por lo tanto, es requisito haber avanzado sustancialmente en las fases de análisis y diseño de software.
