Está en la página 1de 20

Universidad Tecnológica Nacional

Fac. Reg. Concepción del Uruguay

Ingeniería en Sistemas de Información


Ing. De Software
Año 2016

Trabajo Práctico Nº
Título Técnicas de estimación
Fecha de presentación 6 de septiembre

Nombre del Grupo Grupo 7


Integrantes Cuba, Martín
Rodríguez Cora, Fernando
Thoma, Luciano

Cátedra Ing. Juan Manuel Rios


Ing. Jorge Adrian de la Cruz
UTN FRCU-I.S.I. – Ing. De Software 2016

COCOMO ........................................................................................................................... 2
Descripción del Proceso ............................................................................................................ 2
Tipos de Proyectos ......................................................................................................................................... 2
Tipos de Modelos ..................................................................................................................... 3
MODELO BASICO COCOMO ........................................................................................................................... 3
EL MODELO COCOMO INTERMEDIO .............................................................................................................. 3
EL MODELO COCOMO AVANZADO/DETALLADO ........................................................................................... 5
Ejemplo .................................................................................................................................... 5
Ventajas de COCOMO ............................................................................................................... 6
Desventajas de COCOMO .......................................................................................................... 6
Herramientas usadas para el desarrollo de la técnica................................................................. 6
Ejemplo de Herramientas Automatizada para realizar una estimación ....................................... 7
Bibliografía ............................................................................................................................... 7
COCOMO II ........................................................................................................................ 8
Introducción ............................................................................................................................. 8
Descripción del Proceso ............................................................................................................ 8
Estimación de Esfuerzo .................................................................................................................................. 8
Estimación de Cronograma .......................................................................................................................... 10
Etapas de la técnica ................................................................................................................ 11
Etapa 1 - Estimación del tamaño ................................................................................................................. 11
Etapa 2 - Definición de parámetros ............................................................................................................. 11
Etapa 3 - Cálculos ......................................................................................................................................... 11
Etapa 4 - Estudio de los Resultados ............................................................................................................. 11
Ejemplo .................................................................................................................................. 11
Herramientas utilizadas para el desarrollo de la técnica........................................................... 12
Ventajas ................................................................................................................................. 14
Desventajas ............................................................................................................................ 14
Webgrafía .............................................................................................................................. 14
COCOTS ........................................................................................................................... 15
COnstructive Commercial Off-The-Shelf modelo de coste de integración .................................. 15
Descripción del Proceso .......................................................................................................... 16
1. Evaluación(Assessment):.......................................................................................................................... 16
2. Contextualización(Tailoring): ................................................................................................................ 16
3. Implementación(Glue Code): ................................................................................................................ 17
4. Mantenimiento(Volatility): ................................................................................................................... 17
Ventajas ................................................................................................................................. 18
Desventajas ............................................................................................................................ 19
Webgrafía .............................................................................................................................. 19

Grupo 7 Página 1
UTN FRCU-I.S.I. – Ing. De Software 2016

COCOMO
Descripción del Proceso
El modelo COCOMO (COnstructive COst MOdel- modelo constructivo de los costos), es el
modelo más exitoso dentro de las métricas que emplean el número de líneas de código
como elemento fundamental. Fue creado por Barry H. Boehm en los 80’ teniendo como
principal característica ser un modelo estático que estudia resultados globales empleando
ecuaciones.
Se conoce también como COCOMO 81, asume que el modelo de desarrollo que se utiliza
es en Cascada y que se utilizan lenguajes imperativos como C, Pascal, etc.

Es un modelo matemático de base empírica que permite la estimación de los costos y la


duración de los Proyectos de Software: esfuerzo y tiempo. Es empírico debido a que se
basa en ecuaciones no lineales obtenidas mediante técnicas de regresión a través de un
histórico de proyectos ya realizados (finalizados).

La mayoría tiene una estructura con la forma:


E = A+B*(ev)c
Donde A, B y C son constantes derivadas empíricamente, E es el esfuerzo en meses por
persona y ev es la variable de estimación
Dependiendo del tipo de proyecto, serán los valores de las constantes que utilizará la
fórmula de COCOMO involucrada

Tipos de Proyectos

Boehm consideró en el modelo COCOMO que los proyectos se pueden clasificar de 3 tipos:
● Organic (Orgánico): Proyectos desarrollados con grupos de trabajo pequeños y de
mucha experiencia, en un ambiente familiar y con pocas restricciones, y
construyendo aplicaciones que les son familiares. Usualmente el proyecto tiene un
tamaño pequeño o mediano (decenas de miles de líneas de código). La dimensión
del proyecto suele ser de hasta 50.000 LDC.
● Semi Detached (Semi-acoplado): Etapa intermedia entre proyectos orgánicos y de
modo incorporado. proyectos intermedios en tamaño y complejidad, varios niveles
de experiencia. Pueden llegar a tener una dimensión de 300.000 LDC.
● Embedded (De modo incorporado: se trata de un proyecto único, y que
posiblemente no se repita, con condicionantes estrictas de todo tipo, que debe ser
realizado con un costo determinado y entregado en una fecha precisa, para una
plataforma determinada.

Grupo 7 Página 2
UTN FRCU-I.S.I. – Ing. De Software 2016

Tipos de Modelos

MODELO BASICO COCOMO


Estima el esfuerzo y el tiempo empleado en el desarrollo de un proyecto de software usando
dos variables predictivas denominadas factores de costo (cost drivers): el tamaño del
software y el modo de desarrollo. Las ecuaciones básicas son:
Esfuerzo PM = A x (KSLOC)B
Donde:
● PM es el esfuerzo estimado. Representa los meses-persona necesarios para
ejecutar el proyecto. Un mes-persona equivale a 152 horas de trabajo y corresponde
a la cantidad de tiempo que una persona dedica durante un mes a trabajar en un
proyecto de desarrollo de software. (Este valor tiene en cuenta los fines de semana
pero excluye feriados y vacaciones).
● KSLOC es el tamaño del software a desarrollar en miles de líneas de código
● A y B son coeficientes que varían según el Modo de Desarrollo (Orgánico,
Semiacoplado, Empotrado)

Cronograma: TDEV = C x (PM)D


Donde:
● TDEV representa los meses de trabajo que se necesitan para ejecutar el proyecto
● C y D son coeficientes que varían según el Modo de Desarrollo (Orgánico,
Semiacoplado, Empotrado)

Variación de la fórmula de estimación de esfuerzo y cronograma para los tres Modos de


Desarrollo:
Modo de Desarrollo Esfuerzo Cronograma

Orgánico PM=2.4 x (KSLOC)1.05 TDEV = 2.5 x (PM)0.38

Semi-Acoplado PM=3.0 x (KSLOC)1.12 TDEV = 2.5 x (PM)0.35

Embebido PM=3.6 x (KSLOC)1.20 TDEV = 2.5 x (PM)0.32

Este modelo es adecuado para una estimación rápida y temprana, pero su precisión es muy
limitada debido a que no contempla factores que tienen significativa influencia en los costos,
como por ejemplo, restricciones de hardware, experiencia y calidad del equipo de trabajo, y
uso de técnicas y herramientas modernas

EL MODELO COCOMO INTERMEDIO


Modifica las ecuaciones de estimación añadiendo un parámetro multiplicador, el cual será
calculado en base a una tabla que evalúa la complejidad añadida debido a otros atributos
asociados al proyecto.
Las fórmulas entonces quedan de la forma:
E = FAE*B*(ev)c
Donde FAE = producto de multiplicadores y es la multiplicación de los valores de la tabla
escogidos para cada atributo. Y ev es la variable de estimación (PF).

Grupo 7 Página 3
UTN FRCU-I.S.I. – Ing. De Software 2016
Factores de costo del proyecto
Existen diversos factores a considerar en el desarrollo de un buen modelo de estimación de
costos de un proyecto de software. Para reducir el número a una cantidad relativamente
manejable se utilizaron fundamentalmente dos principios:
1. Eliminar aquellos factores que son significativos solamente en una fracción
relativamente pequeña o en situaciones especiales.
2. Eliminar los factores que están altamente correlacionados con el tamaño y
comprimir aquellos factores correlacionados entre sí.

Los factores seleccionados se agrupan en cuatro categorías:


● Atributos del producto de software
a. RELY Confiabilidad Requerida
b. DATA Tamaño de la Base de Datos
c. CPLX Complejidad del Producto
● Atributos del hardware
a. TIME Restricción del Tiempo de Ejecución
b. STOR Restricción del Almacenamiento Principal
c. VIRT Volatilidad de la Máquina Virtual∗
d. TURN Tiempo de Respuesta de la computadora expresado en horas
● Atributos del personal involucrado en el proyecto
a. ACAP Capacidad del Analista
b. AEXP Experiencia en Aplicaciones Similares
c. PCAP Capacidad del Programador
d. VEXP Experiencia en la máquina virtual
e. LEXP Experiencia en el Lenguaje de Programación
● Atributos propios del proyecto
a. MODP Prácticas Modernas de Programación
b. TOOL Uso de Herramientas de Software
c. SCED Cronograma de Desarrollo Requerido

El proceso de estimación del esfuerzo puede sintetizarse en los siguientes pasos:


● Se calcula el esfuerzo nominal PMNominal al igual que en el modelo Básico, donde los
únicos factores de costo son el tamaño y el modo de desarrollo.
● Se determina el Factor de Ajuste del Esfuerzo (EAF, Effort Adjustment Factor) según
la fórmula: 𝑬𝑨𝑭 = ∏𝟏𝟓𝒊=𝟏 EMi
Donde cada EM, llamado factor multiplicador de esfuerzo, es el valor que
corresponde a cada atributo de acuerdo al grado de influencia (Muy Bajo, Bajo,
Nominal, Alto, Muy Alto, Extra Alto) en el esfuerzo del desarrollo del software.
● Finalmente, se ajusta el esfuerzo nominal aplicando el EAF.
PM = A× EAF ×(KSLOC)B

Modo de desarrollo Esfuerzo Nominal Esfuerzo Ajustado Cronograma

Orgánico PM=3.2 x (KSLOC)1.05 PM=3.2 x EAF x (KSLOC)1.05 TDEV = 2.5 x (PM)0.38

Semiacoplado PM=3.0 x (KSLOC)1.12 PM=3.0 x EAF x (KSLOC)1.12 TDEV = 2.5 x (PM)0.35

Empotrado PM=2.8 x (KSLOC)1.20 PM=2.8 x EAF x (KSLOC)1.20 TDEV = 2.5 x (PM)0.32

Grupo 7 Página 4
UTN FRCU-I.S.I. – Ing. De Software 2016
Comparado con el modelo básico, éste provee un nivel de detalle y de precisión superior,
por lo cual es más apropiado para la estimación de costos en etapas de mayor
especificación.

Es importante destacar que este modelo tiene dos limitaciones importantes a la hora de
estimar grandes proyectos de software:
● La estimación de la distribución del esfuerzo para cada fase resulta imprecisa.
● No es muy práctico si el producto de software tiene un gran número de
componentes.

EL MODELO COCOMO AVANZADO/DETALLADO


Incorpora todas las características de la versión intermedia y provee los medios para
generar estimaciones con mayor grado de precisión y detalle. Difiere del Modelo Intermedio
en dos aspectos principales que ayudan a superar las limitaciones mencionadas.
● Jerarquía de niveles del producto. Aplica al producto de software una
descomposición jerárquica de tres niveles:
En el nivel inferior, nivel de módulo, la estimación se basa en el número de
líneas de código del módulo (SLOC) y aquellos factores que tienden a variar en ese
nivel: complejidad del módulo y adaptación del software existente, nivel de capacidad
y experiencia del programador, con el lenguaje y la máquina virtual sobre la que se
construirá el software.
El segundo nivel, nivel de subsistema, está descripto por el resto de los
factores de costo que pueden variar de un subsistema a otro, pero que tienden a ser
los mismos para todos los módulos dentro de un subsistema. Entre ellos se
encuentran: restricciones de tiempo y espacio, capacidad del analista, herramientas,
etc.
El nivel superior, nivel de sistema, se usa para aplicar las ecuaciones de
esfuerzo nominal y cronograma y calcular las estimaciones tanto para todo el
proyecto como para cada fase.
● Multiplicadores de Esfuerzo (EM Effort Multipliers) sensitivos a las fases. El
modelo Detallado provee un conjunto de multiplicadores diferentes para cada factor
de costo, según la fase del ciclo de desarrollo que se considere. De esta forma los
multiplicadores se utilizan para determinar el esfuerzo requerido para completar cada
fase.

Es interesante observar que el lenguaje de programación no es dato explícito y que la


metodología exige que la estimación del número de líneas del proyecto se realice mediante
técnicas que no forman parte de la metodología COCOMO.

Ejemplo
Usando COCOMO Intermedio, con un modo orgánico de tamaño = 200 KDSI
Factores de costo:
● Baja Confiabilidad => 0.88
● Alta Complejidad del producto => 1.15
● Baja experiencia en la aplicación => 1.13
● Alta experiencia en los lenguajes de programación => 0.95
● Otros manejadores de costo asumen a ser nominales => 1.00

Grupo 7 Página 5
UTN FRCU-I.S.I. – Ing. De Software 2016
EAF = .88 * 1.15 * 1.13 * .95 = 1.086
PM = 3.2 * ( 2001.05 ) * 1.086 = 906 mes-hombre
TDEV = 2.5 * 9060.38 = 33.24
P=PM/TDEV = 906/33.24 = 27 personas

Ventajas de COCOMO
● Transparencia. A diferencia de otros modelos como SLIM, COCOMO permite ver
cómo es su funcionamiento.
● Los factores de costo ayudan al estimador a saber en qué parte del proyecto
aumentan más los costos.

Desventajas de COCOMO
● Depende mucho de los datos históricos de la organización (como algunos factores),
datos que no siempre están disponibles.
● No se puede asumir que el modelo sea válido para todos los entornos de desarrollo.
● El éxito de la estimación depende mucho del modo de desarrollo que se vaya a
utilizar (los valores varían según orgánico, semiacoplado o embebido).

Herramientas usadas para el desarrollo de la técnica


Las herramientas automáticas de estimación permiten al planificador estimar costes y
esfuerzos, así como llevar a cabo análisis del tipo "qué pasa si" con importantes variables
del proyecto, tales como la fecha de entrega o la selección de personal. Aunque existen
muchas herramientas automáticas de estimación, todas exhiben las mismas características
generales y todas requieren una o más de las siguientes clases de datos:

1. Una estimación cuantitativa del tamaño del proyecto (por ejemplo. en LDC) o de la
funcionalidad (datos sobre puntos de función)
2. Características cualitativas del proyecto, tales como la complejidad, la fiabilidad requerida
o el grado crítico del negocio.
3. Alguna descripción del personal de desarrollo y/o del entorno de desarrollo.

Existen herramientas automáticas que estiman costos basados en COCOMO como son:
Costar, COCOMO 81.
SystemStar & Costar -- Tools for Software Estimation & Systems Engineering Estimation.

SystemStar is a cost estimation tool based on COCOMO and the Constructive Systems
Engineering Model (COSYSMO) created by Dr. Ricardo Valerdi. Engineers use SystemStar
to produce estimates of a project's cost. SystemStar lets you make trade-offs and experiment
with "what-if" analyses to arrive at a satisfactory project plan.

We plan to implement the COCOMO III and COSYSMO 3.0 models as soon as they are
completed.

Grupo 7 Página 6
UTN FRCU-I.S.I. – Ing. De Software 2016
To learn about SystemStar before you download it, check out the SystemStar Guided Tour
(http://www.softstarsystems.com/tour.htm).

Ejemplo de Herramientas Automatizada para realizar una estimación

Bibliografía

 Gestión de Proyectos de Software. Juan Grompone. 1996.


http://www.grompone.org/libros_y_cuentos/textos_completos/GPS.pdf

 -COCOMO- Un modelo de estimación de proyectos de software.


https://blogadmi1.files.wordpress.com/2010/11/cocom0llfull.pdf

 Estimación para proyectos de software y modelo COCOMO. Universidad Autónoma


de Tlaxcala.. http://ingenieria.uatx.mx/marva/files/2011/02/COCOMO.pdf

 Pressman, R.S., Ingeniería del Software. Un enfoque práctico.

Grupo 7 Página 7
UTN FRCU-I.S.I. – Ing. De Software 2016

COCOMO II
Introducción
Surgió como una variante a COCOMO I debido a la tendencia a el desarrollo basado en
ensamblado y reutilización de componentes.
Esta técnica considera diferentes enfoques para el desarrollo de software, como el de la
construcción de prototipos, el desarrollo basado en componentes y el uso de programación
con base de datos.
Soporta el modelo de desarrollo en espiral y engloba varios niveles que producen
estimaciones detalladas de forma incremental.
Los objetivos tenidos en cuenta para el desarrollo del modelo fueron:
● Desarrollar un modelo de estimación de costo y cronograma de proyectos de
software que se adaptara tanto a las prácticas de desarrollo de la década del 90
como a las futuras.
● Construir una base de datos de proyectos de software que permitiera la calibración
continua del modelo, y así incrementar la precisión en la estimación.
● Implementar una herramienta de software que soportará el modelo.
● Proveer un marco analítico cuantitativo y un conjunto de herramientas y técnicas que
evaluarán el impacto de las mejoras tecnológicas de software sobre los costos y
tiempos en las diferentes etapas del ciclo de vida de desarrollo.

Está compuesto por tres modelos.


● Composición de aplicación: es el modelo de estimación utilizado en los proyectos
de software que se construyen a partir de componentes pre-empaquetados.
○ Se emplean Puntos Objetos para estimar el tamaño del software.
○ Este modelo es empleado en desarrollo de software durante la etapa de
prototipación.

● Diseño temprano: se utiliza en las primeras etapas del desarrollo en las cuales se
evalúan las alternativas de hardware y software del proyecto.
○ En esta etapa se tiene poca información.
○ Se utiliza el concepto de Punto de Función para realizar la estimación del
tamaño y reducir el número de factores de costo.

● Post-arquitectura: se aplica en la etapa de desarrollo propiamente dicho, después


que se define la arquitectura del sistema y en la etapa de funcionamiento.
○ Utiliza Punto Función y/o Líneas de Código para estimar el tamaño.
○ Utiliza 17 atributos denominados factores de costo que permiten considerar
características del proyecto que tienen injerencia en los costos.
○ Cinco factores que determinan un exponente.

Descripción del Proceso

Estimación de Esfuerzo
El esfuerzo necesario para concretar un proyecto de desarrollo de software, cualquiera sea
el modelo empleado, se expresa en meses/persona (PM) y representa los meses de trabajo
de una persona fulltime, requeridos para desarrollar el proyecto.

Grupo 7 Página 8
UTN FRCU-I.S.I. – Ing. De Software 2016
Modelo Composición de Aplicación
𝑵𝑶𝑷
La fórmula propuesta en este modelo es 𝑷𝑴 =
𝑷𝑹𝑶𝑫

- NOP: es el tamaño del nuevo software a desarrollar expresado en PO (puntos


objeto) y se calcula como NOP = OP (100-%reuso) / 100.
- OP: tamaño del software expresado en Puntos Objeto.
- %reuso: porcentaje de reuso que se espera lograr en el proyecto.

- PROD: representa la productividad promedio determinada a partir del análisis de


datos de proyectos.

Modelo Post-Arquitectura
Es el modelo más detallado y suele aplicarse cuando la arquitectura del proyecto está
completamente definida.

El esfuerzo nominal se ajusta usando 17 factores multiplicadores de esfuerzo. Esto permite


analizar con más exactitud el conocimiento disponible en las últimas etapas de desarrollo,
ajustando el modelo de tal forma que refleje fielmente el producto de software bajo
desarrollo. La fórmula para el cálculo del esfuerzo es la siguiente:

Modelo Diseño Temprano


Ajusta el esfuerzo nominal usando siete factores de costo. La fórmula para el cálculo del
esfuerzo es la siguiente:

- PMEstimado : es el esfuerzo Nominal ajustado por 7 factores, que reflejan otros


aspectos propios del proyecto que afectan al esfuerzo necesario para la ejecución
del mismo.

Grupo 7 Página 9
UTN FRCU-I.S.I. – Ing. De Software 2016
- KSLOC: es el tamaño del SW a desarrollar expresado en miles de líneas de código
fuente.
- A: constante que captura los efectos lineales sobre el esfuerzo de acuerdo a la
variación del tamaño, (A=2.94).
- B: es el factor exponencial de escala, toma en cuenta las características
relacionadas con las economías y deseconomías de escala producidas cuando un
proyecto de software incrementa su tamaño.
- EMi : corresponde a los factores de costo que tienen un efecto multiplicativo sobre el
esfuerzo. Cada factor se puede clasificar en seis niveles diferentes que expresan el
impacto del multiplicador sobre el esfuerzo de desarrollo. Esta escala varía desde un
nivel Extra Bajo hasta un nivel Extra Alto. Cada nivel tiene un peso asociado. El peso
promedio o nominal es 1.0. Si el factor provoca un efecto nocivo en el esfuerzo de un
proyecto, el valor del multiplicador correspondiente será mayor que 1.0, caso
contrario el multiplicador será inferior a 1.0.

Clasificados en categorías, los 7 Multiplicadores de Esfuerzo son:


Del Producto
RCPX: Confiabilidad y Complejidad del producto
RUSE: Reusabilidad Requerida
De la Plataforma
PDIF: Dificultad de la Plataforma
Del Personal
PERS: Aptitud del Personal
PREX: Experiencia del Personal
Del Proyecto
FCIL: Facilidades
SCED: Cronograma de Desarrollo Requerido

Estimación de Cronograma
Luego de obtener una estimación del esfuerzo se puede realizar la estimación de
cronograma.
La estimación de cronograma se expresa en cantidad de meses, tomando como fecha de
inicio la determinación de requerimientos, y fecha de fin la culminación de una actividad que
certifique el cumplimiento de las mismas (TDV).
Se utiliza la siguiente ecuación para la obtención de esta estimación:

TDEV: tiempo de calendario en


meses.
PM: esfuerzo expresado en meses por persona.
B: factor de escala.
SCED%: porcentaje de compresión/expansión del cronograma.

Grupo 7 Página 10
UTN FRCU-I.S.I. – Ing. De Software 2016

Etapas de la técnica

Etapa 1 - Estimación del tamaño


● Identificar los módulos que componen el sistema.
● Identificar tamaño de cada módulo (se lo puede expresar de varias formas).
● Calcular el tamaño total del sistema.

Etapa 2 - Definición de parámetros


● Definir el Factor Exponencial de Escala (B - se tiene en cuenta cinco factores,
varían desde Muy bajo hasta Extra alto).
● Definir los niveles de los factores de costo (TOOL, SITE y SCED).
● Obtener el Factor de Ajuste del Esfuerzo (EAF - factores de costo que tienen un
efecto multiplicativo sobre el esfuerzo).
● Definir el Costo del Mes/Persona (expresado en miles de dólares).

Etapa 3 - Cálculos
● Calcular el Esfuerzo y la Productividad.
● Determinar el Tiempo de Desarrollo Estimado del proyecto TDEV.
● Calcular el Costo por instrucción en US$ (cociente entre el Costo de Desarrollo y
el Tamaño del Módulo).

Etapa 4 - Estudio de los Resultados

Ejemplo
Se necesita realizar una aplicación para llevar a cabo el control de stock de una farmacia.
El cliente requiere conocer una estimación de costos de duración y esfuerzo del proyecto.

A continuación se puntualizan los pasos a seguir para el desarrollo de la técnica.

Para realizar esta estimación se utilizará la herramienta USC-COCOMO II.

Grupo 7 Página 11
UTN FRCU-I.S.I. – Ing. De Software 2016

Herramientas utilizadas para el desarrollo de la técnica


Pantalla principal de la herramienta, en ella se puede definir el nombre de proyecto. Luego
de ello es necesario agregar un nuevo módulo.

Al agregar un nuevo módulo al proyecto es necesario definir alguno valores:


- Nombre: nombre del módulo.
- Tamaño: dimensión estimada del proyecto, puede estar expresada en cantidad de
líneas de código, puntos de función y también brinda la opción para cuando se trata
de una adaptación de un módulo ya realizado.
- Salario: hace referencia a la remuneración que recibe el empleado

En el margen superior derecho se puede especificar la etapa de desarrollo, puede ser post-
arquitectura o un proyecto desde cero, incluyendo todas sus actividades iníciales.

Cabe destacar que además esta herramienta brinda la posibilidad de modificar distintos
factores de escala. Aplicaciones previas desarrolladas por el equipo de trabajo, flexibilidad
del diseño, arquitectura (solidez), cohesión en el equipo de trabajo y claridad de los proc.

Grupo 7 Página 12
UTN FRCU-I.S.I. – Ing. De Software 2016

Luego de especificar las características del proyecto, ya es posible dar una estimación.
En la parte inferior se obtiene información al respecto. Brinda tres posibles estimaciones por
filas, la optimista (supone la existencia nula de contratiempos), pesimista (ocurren varios
contratiempos) y la promedio.
Brinda información relacionada al esfuerzo necesario, cantidad de semanas para llevar a
cabo el trabajo, costo intelectual, y la cantidad de personas requeridas (personal).

Para este caso en particular suponiendo un único módulo constituido de 2500 líneas, un
salario de $7000, se obtiene que como estimación promedio el desarrollo llevaría poco más
de 7 semanas y no sería necesario más de un único desarrollador.

Grupo 7 Página 13
UTN FRCU-I.S.I. – Ing. De Software 2016

Ventajas
● Fácil de interpretar y de realizar.
● Tiene pocas variables.
● En la mayoría de los casos se acerca a la realidad.

Desventajas
● No se obtienen resultados fiables en proyectos demasiados pequeños.
● La elección de las variables es muy subjetiva y depende de la persona que realiza el
estudio.

Webgrafía
● Ingeniería del Software 7ma. Ed. - Ian Sommerville
● Gómez.A, López.M, Migani.S y Otazú.A. -COCOMO- Un modelo de estimación de
proyectos de software.

Grupo 7 Página 14
UTN FRCU-I.S.I. – Ing. De Software 2016

COCOTS
COnstructive Commercial Off-The-Shelf modelo de coste de
integración
COCOTS es una extensión de COCOMO II que data del año 2000-2002, está
desarrollado para estimar el costo de integrar COTS (componentes comerciales de
software general) dentro de un nuevo sistema software. El porque es COCOTS una
extensión a COCOMO II, se debe a que este último sólo permite calcular el esfuerzo,
costo y tiempo de desarrollo de un proyecto software cuando se tiene acceso al código
fuente de los componentes a utilizar.

El ser humano ha aprendido a través del tiempo a reutilizar conocimiento existente para
plantearse metas aún más complejas, esto nos asegura no cometer errores reiterativos
teniendo una base firme y de calidad.
El concepto de reutilizar aplicado al software, es uno de los primero que nos enseñan al
iniciarnos en el mundo del desarrollo de software.

En la actualidad los proyectos software son cada vez más exigentes y deben realizarse
en tiempo record con la más alta calidad posible, para hacer frente a esta cuestión se
concibió CBSE (component based software engineering - ingeniería de software basada
en componentes).
La CBSE se centra en diseñar y construir sistemas computacionales utilizando
componentes de software reutilizable sacando provecho del beneficio inherente de la
calidad de software, la productividad al desarrollar y sobre todo en la disminución de
costos, puntualmente COTS enfatiza el que sean piezas de código pre elaborado de
índole comercial .

Componente: es un paquete de software el cual ofrecer servicios a través de interfaces,


capaz de utilizarse de forma independiente.
Esto introduce tres perspectivas diferentes de los componentes:
● Paquete: conjunto de elementos organizados que son utilizados como una unidad
● Servicio: entidad que brinda cierta prestaciones a un consumidor, teniendo un
contrato bien definido y conocido los interesados
● Integridad: refiere a un al buen manejo de los datos con que interactúa y la
independencia de éste con el contexto

Los componentes pueden ser de dos tipos:


● Caja Blanca: Son componentes donde el desarrollador tiene acceso a la
documentación y también al código fuente, pudiendo leer y modificar el mismo a
merced
● Caja Negra: Se obtienen compilados o en forma de binario, siendo imposible
modificarlos directamente, teniendo acceso solo a la documentación de las
funcionalidades bajo una interfaz pública bien conocida

Grupo 7 Página 15
UTN FRCU-I.S.I. – Ing. De Software 2016
Siendo el modelo COCOTS (ampliamente utilizado en CBSE para estimar esfuerzo,
costo y tiempo en sistemas donde se desea integrar componentes (del tipo caja negra)
para su desarrollo.

Descripción del Proceso


En las actividades de Modelado y Construcción se incorporan las siguientes etapas,
basadas en un enfoque evolutivo:

1. Evaluación(Assessment):
Se investiga y valora los distintos componentes disponibles, sus aspectos de
integración para el tipo de aplicación que se va a desarrollar.
Los componentes COTS generalmente suelen agruparse en clases en basado en
sus funciones básicas tales como interfaces gráficas, constructores, sistema
operativo, base de datos, procesamiento de texto, etc ya que permite una forma
eficaz de recopilar datos de los mismos para su posterior comparación.

Esfuerzo de Evaluación (EE) = Filtro Inicial (FI) + Selección Final (SF)


FI = (# Cantidad de Componentes por CLASE)*(Promedio de esfuerzo de filtrado por
Candidato)
SF=𝛴(# Cantidad de Componentes por CLASE)*(Promedio del esfuerzo de
cumplimiento del atributo bajo cierto dominio por el Candidato)
sumatoria de los atributos a considerar

Tanto la cantidad de candidatos a considerar como los atributos y su ponderación


dependen del proyecto puntual.
Dentro de los atributos a considerar podrían estar: Correctitud, Robustez, Seguridad,
Performance, Entendibilidad/Facilidad de Uso, Compatibilidad entre Versiones,
Compatibilidad Inter-Componentes, Flexibilidad, Facilidad de
Instalación/Actualización, Portabilidad, Funcionalidad, Precio, Madurez, Soporte del
Proveedor, Entrenamiento, etc

2. Contextualización(Tailoring):
Se diseña una arquitectura de software para que reciba los componentes, así como
también se configura distintos parámetros (instalación, protocolos, formatos de
recepción/emisión de información, seguridad, etc.) de los componentes para un buen
funcionamiento dentro de esta.

Con el fin de estimar el esfuerzo de esta etapa, se genera un rango de 5 niveles de


complejidad (Very Low, Low, Nominal, High y VeryHigh) que se aplica a cada tipo de
parámetro de todos los componentes a utilizar.

Grupo 7 Página 16
UTN FRCU-I.S.I. – Ing. De Software 2016

Esfuerzo de Contextualización (EC)= 𝛴(# Complejidad de Componentes para ser


Adaptado)*(Promedio del esfuerzo de adaptación según su complejidad particular al
proyecto)
sumatoria de los niveles de complejidad

3. Implementación(Glue Code):
Se implementan los componentes en la arquitectura y se realizan pruebas
exhaustivas que aseguren el cumplimiento de su finalidad.
Esta sección hace foco en 3 cuestiones: facilitar la transición de información o datos
entre los componentes y el resto del sistema (integración) y también entre los mismos
componentes (interconexión), asimismo, debe generarse el código que solucione las
funcionalidades requeridas basándose en el uso de los componentes y demás partes
del sistema.

4. Mantenimiento(Volatility):
Se refiere a que el sistema sea independiente del efecto generado por las
actualizaciones o nuevas versiones del componente software utilizado, durante el
desarrollo del sistema y su despliegue (costo, esfuerzo) subsecuente.

El momento de mayor esfuerzo insumido según datos recopilados hasta la fecha, en


proyectos con la utilización de esta metodología, está centrado en la etapa de
implementación o Glue Code donde aparecen los problemas de integración del
componente a la arquitectura planteada, problema imposible de avizorar hasta que se
ejecuta la adhesión del componente y que puede implicar la necesidad de re-diseñar y
efectuar re-work.

Grupo 7 Página 17
UTN FRCU-I.S.I. – Ing. De Software 2016
En contraparte, el momento de menor implicancia de esfuerzo aunque no deja de ser
importante es el de evaluación o Assessment, aun así los proyectos más exitosos no
relegan esfuerzo en esta etapa, realizando una revisión algo más profunda para
corroborar si los componentes son todo lo que el proveedor dice que son o que hace.
También el manejo del efecto de la volatilidad de los componentes en un sistema
grande tiende a requerir mayor esfuerzo que el Assessment, teniendo gran significancia
a la hora de refinar la definición del modelo.
En la siguiente figura se representa el esfuerzo requerido para construir un sistema de
software a partir de código nuevo y COTS, utilizando el modelo COCOTS relacionado
con el modelo COCOMO II.

Ventajas
● Menor tiempo y costo de desarrollo (en comparación a la generación del componente
por parte del equipo)
● Interfaces bien definidas y documentadas
● Utilización de componentes comerciales ampliamente probados
● Soporte de la misma por el proveedor

Grupo 7 Página 18
UTN FRCU-I.S.I. – Ing. De Software 2016

Desventajas
● Mayor trabajo a la hora de integrar el componente(por tener que adaptarlo a la
arquitectura del software o por un cambio de uno por otro al variar ampliamente
según cada proveedor)
● El código fuente del producto/componente no está disponible (si el código compilado)
● La evolución del componente y su periodicidad no es controlable
● No se controla la performance o predisposición a interconectarse con otros COTS
por parte del producto

Webgrafía
· Department of Computer Science, BRCM college of Engineering and Technology
(Bahal,India)
-A Review on Optimizing COCOTS model in Component based software engineering
approach
· University of Southern California (Los Ángeles, CA, Estados Unidos)
-COCOTS: A COTS Software Integration Lifecycle Cost Model - Model Overview and
Preliminary Data Collection Findings
-COCOTS Web Page
-COCOTS (COnstructive COTS) Software Integration Cost Model: An Overview
http://www.psmsc.com/ug1998/presentations/cocots%201998.pdf
· Pennsylvania State University (University Park, PA, Estados Unidos)
-http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.19.1250&rep=rep1&type=pdf
· Universidad de Almería (La Cañada de San Urbano, Almería, España)
- http://acacia.ual.es/profesor/LIRIBARNE/research/Jis00ref05/node2.html
· Ingeniería del Software: Un enfoque Práctico (7ma Edición) , Roger S. Pressman

Grupo 7 Página 19

También podría gustarte