Ir al contenido principal

Modelo Constructivo de Costos

RUBIO HARO RODRIGO RODOLFO



MODELO CONSTRUCTIVO DE COSTOS

Una de las tareas de mayor importancia en la administración de proyectos de software es la estimación de costos, y sin duda alguna una de las tareas mas complicadas. Si bien es una de las primeras actividades, inmediatamente posterior al establecimiento de los requerimientos, indudablemente se ejecuta regularmente a medida que el proyecto progresa con el fin de ajustar la precisión en la estimación. Los dos usos mas importantes para la estimación de costos de un proyecto son:

Durante la etapa de planeamiento

Permite decidir el personal necesario para llevar a cabo el proyecto y poder establecer el cronograma de actividades adecuado.

Para controlar el progreso del proyecto

Es de una esencial importancia evaluar el estado de evolución del proyecto de acuerdo al cronograma para tomar acciones correctivas en caso de que sea necesario. Para esto se requiere contar con métricas que permitan medir el nivel de cumplimiento del desarrollo del software. Es importante reconocer la fuerte relación entre costo, cronograma y calidad. Estos tres aspectos están íntimamente relacionados y confrontados entre sí. De esta manera, se hace difícil incrementar la calidad sin aumentar el costo y/o el cronograma del software a desarrollar. Similar-mente, el cronograma de desarrollo no puede reducirse dramáticamente sin deteriorar la calidad del producto de software y/o incrementar el costo de desarrollo. Los modelos de estimación juegan un papel importante ya que permiten equilibrar estos tres factores.

Atecedentes Históricos

En 1981 Barry Boehm publica el modelo COCOMO, acorde a las prácticas de desarrollo de software de aquel momento, convirtiéndose en el modelo de estimación de costos más amplia-mente utilizado en el mundo.
En los 90, las técnicas de desarrollo de software cambiaron dramáticamente. Estos cambios comenzaron a generar problemas en la aplicación del modelo COCOMO. La solución fue reinventar el modelo. Después de algunos años, y de un esfuerzo combinado organizaciones privadas y algunas universidades, aparece COCOMO II. Las incorporaciones a este modelo lo reforzaron e hicieron apto para ser aplicado en proyectos vinculados a tecnologías como orientación a objetos, desarrollo incremental, composición de aplicación, y re-ingeniería. 
Para evitar confusión el modelo COCOMO original fue re-diseñado con el nombre COCOMO’ 81. Así todas las referencias de COCOMO encontradas en la literatura antes de 1995 se refieren a lo que ahora llamamos COCOMO’81. La mayoría de las referencias publicadas a partir de 1995 se refieren a COCOMO II.

Funcionamiento de COCOMO

COCOMO’ 81 está compuesto, básicamente,  por tres modelos (correspondientes a distintos niveles de detalle y precisión). Estos son: Modelo Básico, Intermedio y Detallado. 


El modelo básico

Estima el coste del proyecto en función de número de líneas de código estimadas, es importante destacar que esta diseñado para proyectos pequeños o medianos. En este modelo, el algoritmo COCOMO establece varios criterios de desarrollo, dependiendo el nivel de dificultad y no del nivel de experiencia de los desarrolladores sino de posibles dificultades que se pueden encontrar en el desarrollo o limitaciones del hardware usado en el desarrollo del software.

El modelo intermedio

Se utiliza para estimaciones más complejas. Éste incluye 15 atributos, a su vez dentro de 4 categorías, del software para determinar el coste del proyecto.

  • Atributos del producto.
  • Atributos del o los ordenadores usados.
  • Atributos del personal o equipo de trabajo.
  • Atributos del proyecto.

Todos estos atributos son ponderado matemáticamente atendiendo su relevancia. Aproximando así, el coste estimado mas real posible.

El modelo detallado

Incorpora las características del modelo intermedio y lleva a cabo una evaluación del impacto de los motivantes del coste en cada caso. En modelo COCOMO es uno de los sistemas de estimación de costes más utilizados en proyectos de desarrollo de software. La estandarización de su uso y la facilidad de la aplicación del mismo junto con la aproximación al coste real, han convertido a este modelo en uno de los referentes en este tipo de proyectos.

Ecuaciones

Y como las matemáticas están presentes en todo, no nos queda mas que usar ecuaciones al momento de determinar los costos, facilitando así las negociaciones al usar estándares aceptados.
La función básica que utilizan los tres submodelos es: 
E = a(Kl) b * m(X)
Donde: a y b son constantes con valores definidos. Kl cantidad de lineas de codigo en miles. m(X) multiplicador que depende de 15 atributos. 
Cada submodelo también se divide modos según el tipo de proyecto:
  • Modo orgánico: Pequeño grupo de programadores experimentados desarrollan en un entorno familiar. 
  • Modo rígido: Proyecto con fuertes restricciones cuyo problema a resolver es único y es difícil basarse en la experiencia. 
  • Modo semilibre: Intermedio entre orgánico y rígido con una mezcla de personas experimentadas y otras que no.
Esta es una breve investigación, sin embargo si se requiere mas información el trabajo de Adriana Gómez, María del C.López y de Silvina Migani, Alejandra Otazú, que ha sido la base de esta entrada, es un trabajo realmente elaborado sobre la estimación de costos. *Vease en referencias


Referencias:

  • Adriana Gómez, María del C.López, Silvina Migani, Alejandra Otazú. -COCOMO- UN MODELO DE ESTIMACION DE PROYECTOS DE SOFTWARE. recuperado: 29/05/2017. https://blogadmi1.files.wordpress.com/2010/11/cocom0llfull.pdf
  • “El modelo COCOMO para estimar costes en un proyecto de software” extraído el 28 de mayo de 2017 desde la fuente: http://www.eoi.es/blogs/cesaraparicio/2012/05/06/el-modelo-cocomo-para-estimar-costes-en-un-proyecto-de-software/



RUBIO HARO RODRIGO RODOLFO
INSTITUTO POLITÉCNICO NACIONAL
CENTRO DE ESTUDIOS CIENTÍFICOS Y TECNOLÓGICOS 9
"JUAN DE DIOS BÁTIZ"

Entradas populares de este blog

Tabla Periódica de la Web: Resumen

  Resumen. Al momento de desarrollar un proyecto, se propone la fase de resumen del proyecto en donde se recolecta la información necesaria para proceder con la planeación del proyecto. Aunque todas las etapas de desarrollo son importantes, al ser la primera, definirá en gran parte si el proyecto tiene éxito o no. Veremos el desglose de cada uno de los elementos de esta etapa. En la etapa de resumen tenemos 8 elementos. 1. Definición de Proyecto (PrD) Definir el proyecto es establecer la idea principal del proyecto, la piedra angular. En este primer elemento debemos considerar que deberá moldearse y pulirse esa idea. 2. Target (Ta) Definida la idea principal del proyecto, tenemos que delimitar lo más posible el público objetivo o target que se verá beneficiado del proyecto.  3. Objetivos (Go) Establecer objetivos específicos sobre que tendrá que realizar el sistema, estos deben de estar en función del público elegido. 4. Especificaciones Técnicas (TS) Las especificaciones Técn...

Tabla Periódica de la Web: Planeación

Planeación. Una vez que tenemos claro que cosas se quieren llevar a cabo en nuestra webapp, diseñar un plan teniendo en cuenta nuestros objetivos, recursos, presupuesto, entre otros factores, nos permitirá desarrollar nuestro proyecto enfocado completamente a las necesidades planteadas.  Es importante integrar al equipo de desarrollo en la etapa de planeación, se fomenta el sentimiento de propiedad y usualmente se verán más comprometidos con el proyecto. Este punto se puede argumentar con el principio de los equipos autónomos de las metodologías ágiles. 1. Investigación y desarrollo de Conceptos Una vez dados los primeros requisitos del cliente, se deberá hacer una investigación, está dependerá de la complejidad de lo solicitado. Investigar y desarrollar los conceptos dados. La investigación tiene como fin que el equipo de desarrollo comience a formular propuestas para la arquitectura de la aplicación. 2. Lluvia de ideas Organizar sesiones de este tipo, permitirá al equipo de desar...

Documentación de Software: Artefactos

Concepto Un artefacto es un producto tangible resultante del proceso de desarrollo de software. Ya sea un documento o un modelo. Para hacer el desarrollo de un sistema de Software manejable completo, los artefactos están organizados en conjuntos correspondientes a las disciplinas. Como lo pueden ser para arquitectura de software, diseño de software o para la base de datos. Los roles usan artefactos para ejecutar actividades y producen artefactos durante la ejecución de sus actividades. Arquitectura de Software  Modelo de desarrollo Modelo de análisis Modelo de Diseño  Documento de Arquitectura de Software Modelo de Implementación Directrices de Programación Diseño de Software  Diagramas de casos de Uso Análisis de clases (Diagramas de clase y objetos) Diagramas de secuencia Base de Datos Modelo de datos Entidad-relación Modelo de diseño Modelo conceptual Modelo físico Modelo lógico Artefactos