Introducción Al momento de iniciar un proyecto de desarrollo de un producto de softw’are, es importante poder determinar cuál será el presupuesto en dinero y tiempo que tomará la construcción del mismo.
Un error en la estimación del esfuerzo, costo y tiempo puede resultar desastroso para las personas y organizaciones involucradas en el desarrollo del producto, debido a que probablemente se duplique el costo previsto inicialmente, originando grandes pérdidas ec simplemente se canc proyecto, perdiendo Todo gerente de pro capaz de poder hace ueña del sistema, o PACE 1 orlá s deber(a ser estimación de costos, que se acerque lo más posible al costo real, que supondrá el desarrollo del sistema de información.
Sin embargo esta es una labor dificil, ya que el esfuerzo, el costo y el tiempo que toma hacer el producto, muchas veces deben ser establecidos antes de poseer suficiente información sobre el mismo, incluso antes que comience su diseño, lo que conlleva a que la persona encargada de realizar este análisis deba tener mucha experiencia en el desarrollo de software, para poder realizar una estimación con base en el costo de proyectos anteriores.
Durante mucho tiempo se han realizado estudios y se han creado técnicas oara facilitar abordaremos algunas de las más importantes y destacadas hasta la fecha. Estimación La estimación según la Real Academia Española es el «Aprecio y valor que se da y en que se tasa y considera algo», En el área de informática, la estimación es el análisis del tiempo, esfuerzo y recursos que tomará la creación de un producto de software, es prácticamente una obligación para los gerentes del proyecto hacer este estudio para poder asi determinar el presupuesto necesario para su desarrollo.
Esta labor no es fácil, ya que on muchas las variables que se deben tener en cuenta al momento de realizar el análisis, como son las humanas, técnicas, el entorno y las limitaciones propias del negocio, así como también la poca información inicial de la magnitud del sistema, por lo que se necesita realizar una predicción de los costos, el personal requerido, los insumos y el tiempo que tomará desarrollar cada una de las funcionalidades del software. Un error en el cálculo del presupuesto, podría significar el fracaso del proyecto.
Para reducir los riesgos de subestimar el costo del producto, se han creado varias écnicas, algunas basadas en algoritmos y otras en la pericia y experiencia de expertos, personas que ya han estado involucradas en desarrollos similares antenores. A continuación de detallarán algunas de las técnicas más conocidas, creadas para este fin. Técnicas de Descomposición Para facilitar el proceso de software, el sistema se varias funciones o componentes, para analizarlos por separado y realizar una estimación más sencilla, y así luego poder unir todos los fragmentos y obtener una estimaclón total del costo del proyecto. or tanto la primera métrica en la que nos basamos para realizar ste análisis es el tamaño del software, el cual puede ser medido en líneas de códigos (LDC) o en puntos de funciones (PF). La técnica LDC mide en forma directa el tamaño del software. Se calcula contando todas las instrucciones en códlgo fuente de cada uno de los componentes del sistema, excluyendo los comentarios. Este método tiene como desventaja que la medida del software cambiará dependiendo del lenguaje de programación en que esté escrito, por ejemplo, un programa desarrollado en lenguaje Java tendrá menos líneas que el mismo programa escrito en C.
Mientras tanto la técnica PF hace una medición indirecta, edlante la estimación de las 2 entradas, salidas, archivos de datos, y peticiones externas, según algunos autores, como refiere Pressman dicen que «el PF es independiente del lenguaje de programación, lo que lo hace ideal para aplicaciones que usan lenguajes convencionales y no procedurales, y que se basa en datos que es más probable que se conozcan tempranamente en la evolución de un proyecto, lo que hace al PF más atractivo como enfoque de estimación» (Pressman, 20 mientras que autores detr que este método es difíciles de recopilar.
Hay incluso quienes relacionan ambas métricas y proponen ediciones de líneas de código requeridas para construir un punto de función. Para calcular los puntos de función se usa la siguiente ecuación: Donde el conteo total es la suma de todas las entradas PF obtenidas, que se muestran en la siguiente imagen: Y los ) son factores de ajustes de valor con base en respuestas a las siguientes preguntas: 1 . ¿El sistema requiere respaldo y recuperación confiables? 2. ¿Se requieren comunicaciones de datos especializadas para transferir información hacia o desde la aplicación? 3. ¿Existen funciones de procesamiento distribuidas? . ?El desempeño es crucial? 5. ¿El sistema correrá en un entorno operativo existente enormemente utilizado? 6. ¿El sistema requiere entrada de datos en línea? 7. ¿La entrada de datos en e que la transacción de entrada se construya aplicable) a 5 (absolutamente esencial). Los valores constantes en la ecuación y los factores ponderados que se aplican a los conteos de dominio de información se determinan de manera empírica. Técnica de descomposicion del problema Esta estimación puede basarse en hechos históricos o en la intuición del analista, se apoya en las métricas vistas anteriormente.
Independiente de la variable de estimación que se utilice, se debe comenzar por estimar un rango de valor para cada función y así determinar un valor optimista, otro pesimista y otro más probable. Luego de realizado este paso, se puede calcular un valor de tres puntos o esperado. Este valor esperado se calcula como un promedio ponderado de las estimaciones optimista, más esperada, y la pesimista. Una vez determinado el valor esperado para la variable de estimación se aplican datos de productividad históricos LOC o PP.
En la siguiente imagen se representa el proceso de análisis de stimación por descomposición del problema. 4 Técnica de descomposición basada en proceso Esta técnica de estimación es la más utilizada para estimar un proyecto, usando como base de estimación cada uno de los procesos que se realizaran durante la s OF construcción del software. técnicas basadas en 2010). Después de que se combinan las funciones del sistema y los procesos a utilizar, se estima el esfuerzo (hombre-mes) que se realizará para cada actividad del proyecto.
Luego se aplican las tarifas de la mano de obra (costo/unidad). Estimación Basada en casos de uso Este método cuenta con algunas desventajas de entrada, ya que los casos de uso son visiones subjetivas de lo que debe realizar el sistema, y por tanto los niveles de abstracción pueden llegar a ser muy altos, lo que trae como consecuencia que no se pueda ver a primera vista la complejidad de las operaciones que implica cumplir con ese caso de uso, Además de existen muchas formas de describir un caso de uso, no existe un estándar.
Para utilizar esta técnica primero se define en qué nivel de abstracción va estar cada caso de uso, se considera la cantidad de páginas de cada caso de uso, l tipo de softv. ‘are que se está construyendo y una arquitectura inicial del sistema. «Una vez establecidas dichas características pueden usarse datos empíricos para establecer el número estimado de LOC o PF por caso de uso (por cada nivel de la jerarquía).
Entonces se usan datos históricos a fin de calcular el esfuerzo requerido para desarrollar el sistema. » (Pressman, 2010) La siguiente ecuación repr a de calcular el esfuerzo requerido: ciento de , donde n se define localmente y representa la diferencia entre este proyecto y los proyectos «promedio» escenarios reales por caso de uso scenarios promedio por caso de uso para este tipo de subsistema – páginas reales por caso de uso. páginas promedio por caso de uso para este tipo de subsistema 6 Modelos de Estimación Empíricos Todo modelo de estimación utiliza «fórmulas empíricamente inferidas para predecir el esfuerzo como una función de LOC o PF» (Pressman, 2010), lo cual nos dice que se utilizan los cálculos realizados en proyectos anteriores. Sin embargo se debe tener en cuenta que una misma fórmula no puede servir para todo tipo de software, por tanto hay que tener cierta pericia, al momento de aplicar una fórmula a un nuevo proyecto.
La ecuación básica que utiliza este tipo de modelo es: o donde A, By c son constantes derivadas empíricamente, E es el esfuerzo en persona-meses es la variable de estimación (LOC o PF). Algunos de los modelos de regresión que utilizan este enfoque pueden ser COCOMO es sus versiones avanzada, y el modelo Básico: calcula el esfuerzo y el coste del desarrollo de software en función del tamaño del programa, expresado en las líneas estimadas de código (LDC). 2.
Intermedio: calcula el esfuerzo del desarrollo de software en función del tamaño del programa y de un conjunto de conductores de costo ue incluyen la evaluación subjetiva del producto, del hardware, del personal, y de los atributos del proyecto. 3. Avanzado: incorpora todas las características de la versión intermedia y lleva a cabo una evaluación del impacto de los conductores de costo en cada fase del proceso de desarrollo del sistema. También se definen tres tipos distintos de proyectos de software: 7 1 .
Modo Orgánico: proyectos pequeños y sencillos en los que trabajan pequeños equipos, con buena experiencia en la aplicación, sobre conjunto de requisitos un poco rígidos. 2. Modo Semiacoplado: software intermedio en tamaño y omplejidad, en los que equipos con diferentes niveles de experiencia, deben satisfacer requerimientos un poco o medio rígidos. 3. Modo Empotrado: son aplicaciones que deben ser construidas en un conjunto de hardware, software y restricciones operativas muy restringidas. Las ecuaciones de estimac rzo de desarrollo tienen la los proyectos de pequeño y mediano tamaño.
Se utilizan dos ecuaciones para determinar el esfuerzo de personal y el tiempo de desarrollo. donde se expresa en personas-mes y es el tamaño expresado en miles de lineas de código fuente. expresa el tiempo de desarrollo, donde anterior y e obtiene de la ecuación es el tiempo expresado en meses. Las ecuaciones, anteriormente descritas, se aplican para software de tipo orgánico, en el caso de los modos semiencajado y empotrado se utilizan las mismas ecuaciones pero con diferentes coeficientes.
Cabe destacar que a medida que se incrementa la complejidad del proyecto, aumenta el valor de la constante, ya que se necesita mayor esfuerzo del personal. 8 EN el modelo básico se debe tener cuidado al utilizar estas estimaciones, ya que no s toman en cuenta muchos nciden en el desarrollo de atributos del ordenador, atributos del personal y atributos del royecto. 1 . Atributos del producto • RELY: garantía de funcionamiento requerida al software • DATA: tamaño de la base de datos • CPLX: complejidad del producto 2.
Atributos del ordenador • TIME: restricción de tiempo de ejecución • STOR: restricción del almacenamiento principal • VIRT: volatilidad de la máquina virtual • TURN: tiempo de respuesta del ordenador 3. Atributos del personal • ACAP. capacidad del analista • AEXP: experiencia en la aplicación • PCAP: capacidad del programador • VEXP: experiencia en máquina virtual • LEXP: experiencia en lenguaje de programación . Atributos del proyecta • MODP: prácticas de programación modernas • TOOL: utilización de herramientas software • SCED: plan de desarrollo requerido. (El modelo COCOMO, s. f. ) En la siguiente imagen, se puede ver de forma detallada los valores que toma cada uno de los atributos, dependiendo del tipo de software que se va a construir. En el modelo avanzado se agregan dos caracteristicas, multiplicadores de esfuerzos sensitivos a la fase, ya que en cada fase del desarrollo del software, algunas se ven más afectadas por ciertos atrib 4 producto a tres niveles, q ; y una jerarquía del
