Metodologías de Desarrollo de Sistemas

METODOLOGÍAS DE
DESARROLLO DE SISTEMAS
UNIDAD II
DR. JUAN MUÑOZ LÓPEZ
CONTENIDO
1. Métricas de Proceso
1. Métricas de Estimación de Esfuerzo
1. Puntos de casos de uso
2. COCOMO
2. Métricas del Producto

1. Métricas de Longitud (KLOCs, Puntos de Función)
2. Métricas de Complejidad
3. Métricas de Mantenibilidad
4. Métricas de Programación Orientada a Objetos
3. Software para obtener métricas y registrar esfuerzo.

1. Analizadores de Código
MÉTRICAS
 Medir: Se refiere a comparar entre una cantidad y su correspondiente unidad para determinar
cuántas veces se encuentra contenida en la cantidad en cuestión. Consiste en determinar qué
proporción existe entre una dimensión de algún objeto y una cierta unidad de medida.
 Para que esto sea posible, el tamaño de lo medido y la unidad escogida tienen que compartir
una misma magnitud.
 Magnitud, es una propiedad de un cuerpo que puede ser medida, como el tamaño, el peso o
la extensión.
 La unidad de medida, es el patrón que se emplea para concretar la medición.
 La unidad de medida debe ser:
1. Inalterable, no se modifica con el tiempo, ni de acuerdo con quien lleva a cabo la medición
2. Universal, debe poder usarse igual en cualquier parte
3. Fácil de producir, poder crear instrumentos de medición sin demasiada complejidad
 Métrica, es el resultado de comparar una cantidad con su escala de medición.
CARACTERÍSTICAS DE LAS MÉTRICAS
 Exactas: Se refiere a cuán cerca del valor real se encuentra
el valor medido. En términos estadísticos, la exactitud está
relacionada con el sesgo de una estimación. Cuanto menor
es el sesgo más exacta es una estimación. Cuando se
expresa la exactitud de un resultado, se expresa mediante el
error absoluto que es la diferencia entre el valor
experimental y el valor verdadero.
 Precisas: No se pierde información al manejar las
mediciones (por ejemplo, al redondear). Se refiere a la
dispersión del conjunto de valores obtenidos de mediciones
repetidas de una magnitud.
 Consistentes: Siempre que medimos un atributo
obtenemos el mismo resultado, independientemente de
quien lo mida.
 Comparables: Están normalizadas y son utilizadas en 200 ml 200 ml 100 ml 200 ml 200 ml
diferentes casos por lo que podemos establecer similitudes,
diferencias, proporciones, grados o cualquier otra forma de
confronta.
ELEMENTOS NECESARIOS PARA UN SISTEMA DE MÉTRICAS
 Objeto a medir: Establecer con precisión cuál es el objeto de

medición
 Objetivo de medición: Saber que característica deseo medir (y
para qué)
 Escala: Tener una unidad de medida establecida
 Estándar: Saber contra qué vamos a estar comparando cada vez
que midamos
ESTIMAR
 Producir una afirmación del valor aproximado de una cantidad que

describe o caracteriza un objeto
 Un objeto puede ser un artefacto (modulo de software, parte de
hardware, documento, etc.) o una actividad (planeación, pruebas,
instalación, etc.)
¿QUÉ NOS OBLIGA A ESTIMAR?
 El objeto no es
accesible (puede estar
en uso continuo)
 El objeto aún no existe
 Hacer las mediciones
sería muy caro o
peligroso
PARÁMETROS QUE DETERMINAN LOS MODELOS DE COSTO
DE SOFTWARE
 Tamaño del producto final
 Número de instrucciones fuente (cantidad de líneas de código)
 Número de puntos de función requeridos para implementar alguna funcionalidad
 Proceso utilizado para producir el producto final
 Habilidad del proceso para evitar actividades que no añaden valor
 Capacidades del personal de ingeniería de software
 Experiencia en las ciencias de la computación
 Experiencia en el dominio de la aplicación
 El ambiente para soportar el desarrollo del software y la automatización del
proceso
 Herramientas
 Técnicas
 La calidad requerida del producto
 Características
 Desempeño
 Confiabilidad
 Adaptabilidad
RELACIÓN ENTRE LOS PARÁMETROS DE ESTIMACIÓN DE
SOFTWARE
 La estimación del esfuerzo para el desarrollo de software es el proceso de predecir de la
manera más realista posible el esfuerzo, en términos de personas por hora o dinero, que se
requiere para desarrollar o mantener un producto de software basado en entradas
incompletas, inciertas o inexactas
 En general los parámetros de estimación se relacionan de la siguiente forma:
 Esfuerzo = (TamañoProceso)(Personal)(Ambiente)(Calidad)
 Si el proceso es mayor a 1.0 se presenta una deseconomía de escala de desarrollo de

software
 Entre más software se construya será más caro producir una nueva unidad
 Existen diferentes métodos para realizar la estimación del esfuerzo
 En general para calcular la exactitud de los estimados se utiliza la fórmula de la Magnitud
Media del Error Relativo (MMRE):
 MagnitudMediaErrorRelativo = (EsfuerzoReal – EsfuerzoCalculado) / (EsfuerzoReal)
RAZONES PARA ESTIMAR Y MEDIR (1/3)
 Tamaño del producto, desempeño y calidad

 Evaluar la factibilidad de los requerimientos
 Analizar diseños de productos alternativos
 Determinar la capacidad requerida y la velocidad de los componentes de
hardware
 Cuantificar los recursos necesarios para desarrollar, desplegar y soportar un
producto
 Identificar y asegurar riesgos del producto
 Proveer bases técnicas para el seguimiento y control
RAZONES PARA ESTIMAR Y MEDIR (2/3)
 Esfuerzo del proyecto, costo y calendario

 Determinar la factibilidad de proyecto en términos de costo y tiempo
 Identificar y asegurar los riesgos del proyecto
 Negociar acuerdos alcanzables
 Preparar presupuestos y planes realistas
 Evaluar el valor del negocio (contra su beneficio)
 Proveer bases de costo y programación para dar seguimiento y llevar el control
RAZONES PARA ESTIMAR Y MEDIR(3/3)
 Capacidad y desempeño de proceso

 Predecir el consumo y eficiencia de recursos
 Establecer normas de desempeño aceptable
 Identificar oportunidades de mejora
FALTA DE PRECEDENTES
 Un sistema con precedentes cumple con los

siguientes criterios:
 Los requerimientos son consistentes y bien
comprendidos
 Se conoce una arquitectura factible del sistema que
puede satisfacer los requerimientos
 Todos los participantes han trabajado juntos
previamente para desarrollar un sistema similar
 Cualquier sistema que falla en estos criterios
se dice que le faltan precedentes, por lo que
aumenta su dificultad de estimación
PROBLEMAS DE LAS ESTIMACIONES (1/3)
 Las estimaciones en general se ven afectadas por tres factores: Omisiones,

Incertidumbre y Cambios
 Omisiones
 Se puede fallar al identificar todos los elementos que contribuyen a la estimación
 Se pueden presuponer algunos elementos
 Desconocimiento de todas o algunas de las características del objeto
 Puntos de vista diferentes
 La omisión nos lleva a una sub estimación (desviación)
 Con el tiempo las omisiones son descubiertas y el valor de estimación crece
PROBLEMAS CON LAS ESTIMACIONES (2/3)
 Incertidumbre
 Las estimaciones se basan en un conocimiento incompleto o imperfecto sobre las
propiedades de los objetos y los valores de estas propiedades
 Puede darse que:
 La propiedad sea identificada y el valor conocido adecuadamente
 La propiedad sea identificada pero el valor sea desconocido
 La propiedad no sea identificada
 La incertidumbre es un error probable

 Normalmente decrece sobre el tiempo cuando se tiene información más detallada sobre el
problema
 Disminuye lentamente al principio pues se requiere un tiempo de aprendizaje
 La experiencia previa reduce la incertidumbre con productos o servicios similares
PROBLEMAS CON LAS ESTIMACIONES (3/3)
 Cambio
 Las suposiciones acerca del producto, proceso y proyecto pueden cambiar
durante el curso del proyecto
 Las características requeridas del producto, las interfaces con otros sistemas,
las regulaciones, los objetivos de la empresa, entre otros factores, también
pueden cambiar
 El monto del cambio es proporcional a la duración de proyecto
PREGUNTAS DE INTERÉS CON RESPECTO A LA ESTIMACIÓN
 ¿Qué modelo de estimación conviene usar?

 ¿Se debe medir el tamaño de software en líneas de código o en
puntos de función?
 ¿Qué constituye un buen estimado?
CICLO DE VIDA DE LA ESTIMACIÓN
Requerimientos Definir el proyecto

(producto y proceso)
Antes Estructura de división del
Factores ambientales y trabajo
Identificar y evaluar
de negocio
riesgos
Habilidades y disponibilidad
del equipo Costo y
Estimar costo y tiempo tiempo
Ciclo 2 Plan del proyecto
Ciclo 1
Re-estimar costo y Estimado del proyecto
tiempo Realizar actividades
planeadas / Medir
Durante Cambios en requerimientos,
diseño y ambiente Realidades del
proyecto
Entradas revisadas Comparar valores reales contra
planeados Estatus y estimaciones de
finalización
Reporte
Modelos de estimación
aproximado
documentados Calibrar
Después Mejoras Datos históricos de la
Procedimientos organización
actualizados y listas de Mejorar
verificación proceso
 Capacidades imprescindibles
CRITERIOS PARA LOGRAR “BUENAS” ESTIMACIONES

 Identificar los factores clave a considerar
 Producir un estimado bien documentado (alcance, suposiciones, valores, incertidumbres)
 Validar el estimado documentado
 Aprobar el estimado (como base)
 Capacidades deseables
 Soporte del refinamiento de estimados según se desarrolle el proyecto (estimar hasta finalizar)
 Promover un mejor entendimiento de los factores contributivos (análisis de sensibilidad)
 Practicidad
 Ajustar características del dominio de la aplicación y del producto
 Ajustar los procesos de la organización y la experiencia previa
 Provee una exactitud aceptable de acuerdo con los recursos (esfuerzo, tiempo, dinero)
 Aceptado por todos los interesados (credibilidad)
 Utiliza datos de entrada que están disponibles cuando se necesitan
 Resiste entradas erróneas (revisiones de validez y sanidad)
CRITERIOS PARA BUENAS MEDICIONES
 Relevancia: Características de interés

 Exactitud: Monto o grado de la característica
 Precisión adecuada: Nivel alcanzable de detalle
 Dependible: Mediciones hechas consistentemente
 Actualizada: Los valores se reciben a tiempo
 Económica: El valor de la estimación excede su costo de obtención
 Predecible: Es posible hacer pronósticos adecuados
 Controlable: Se pueden hacer acciones para influenciar el valor
CRITERIOS PARA UN ESTIMADO BIEN DOCUMENTADO
Un estimado bien documentado debe contener los siguientes
elementos para poder evaluar su calidad:
 Directivas
 Objetivos y alcance
 Condiciones
 Restricciones
 Resultados
 Supuestos
 Referencias (modelos, herramientas, datos históricos)
 Valores de entrada
 Valores de salida
 Riesgos potenciales y desconocimientos
 Proyecto
CANTIDADES DE INTERÉS EN LA ESTIMACIÓN DE SOFTWARE
 Esfuerzo (actividades; directo e indirecto)
 Equipo (cantidad, habilidades, experiencia, rotación)
 Tiempo (fases, hitos, épocas)
 Costos (de mano de obra, otros)
 Recursos de cómputo para el desarrollo y pruebas
 Desempeño (capacidad, exactitud, velocidad, tiempo de respuesta)
 Calidad (cumplimiento de requerimientos, dependibilidad)
 Precio y costo total de propiedad
 Tamaño o monto (creado, modificado, comprado)
 Proceso
 Efectividad
 Eficiencia
 Flexibilidad
PUNTOS QUE HACEN DIFÍCIL ESTIMAR EL SOFTWARE
 Es difícil precisar los requerimientos
 El producto es esencialmente invisible hasta que se termina
 El producto es difícil de medir (intangible)
 La aceptabilidad del producto depende del gusto del cliente
 Los sistemas intensivos en software son complejos (contienen muchos
componentes que interactúan con otros y con el ambiente externo)
 Se requieren muchos procesos de abstracción para ir de los requerimientos al
producto que requieren creatividad y pensamiento analítico
 La productividad individual del desarrollador varía en un rango mayor al de otras
disciplinas
 Los procesos creativos son difíciles de planear
 Las personas solamente pueden pensar hasta cierta velocidad (hay un tiempo
límite mínimo para completar el desarrollo)
GRÁFICA DE COSTOS DE LOS ERRORES DE BOEHM
1000
500
200 Métodos
100 normales
(pesados)
50
20 Métodos ágiles
10
5
2
1
Requerimient Diseño Codificación Pruebas de Pruebas de Operación
os desarrollo aceptación
ENFOQUE PRÁCTICO DE ESTIMACIÓN
 Las estimaciones al principio pueden ser imperfectas
 Durante el proyecto deben irse mejorando
 Se debe usar un proceso de retroalimentación para seguir y
controlar las tareas del proyecto, las características del producto y
los procesos de producción
 Si las variaciones superan la variación esperada basadas en
normas históricas o muestran tendencias negativas se deben
realizar acciones correctivas
 La exactitud necesaria depende de las metas del proyecto, los
riegos financieros o de negocio, el tiempo requerido para hacer
decisiones y otros factores.
 Normalmente es adecuada una variación de +/- 20% en costo y
tiempo
 Las metas de exactitud deben ser más estrechas al final del
proyecto ya que se tiene menos tiempo para corregir problemas
MEJORAS EN LAS ESTIMACIONES DE SOFTWARE
 Antes de comenzar el proyecto
 Entender los requerimientos y arquitectura del producto
 Escoger un proceso y herramientas adecuados de producción
 Usar una mezcla de técnicas de estimación, modelos y datos históricos
 Producir el estimado disciplinadamente
 Durante el proyecto
 Recolectar mediciones reales (costo, desempeño, progreso)
 Vigilar las violaciones a supuestos de estimación
 Vigilar cambios en los factores claves (tamaño del software, rotación)
 Actualizar las estimaciones con la última información
Antes
(concepci Durante
Después
ón y (ejecución
(cierre)
 Después del proyecto planeació )
n)
 Recolectar mediciones finales
 Analizar datos y lecciones aprendidas
 Capturar la nueva información (calibrar modelos, actualizar listas de verificación)
MÉTRICA DE SOFTWARE
 Cualquier medida o conjunto de medidas destinadas a conocer o

estimar el tamaño u otra característica de un producto de software
o de un sistema de información, generalmente para realizar
comparativas o para la planificación de proyectos de desarrollo.
INSTRUMENTOS QUE INCLUYEN LAS MÉTRICAS DE
SOFTWARE
 Modelos de Estimación de Costo y Esfuerzo: En base los requerimientos del proyecto se estiman los
costos y el tamaño del proyecto (normalmente en líneas de código)
 Modelos de Productividad: Mide en función del valor y del costo
 Modelos de Métricas de Calidad: Proporcionan una indicación sobre como se ajusta el software a los
requerimientos explícitos e implícitos del cliente
 Modelos de Acumulación (recolección) de Datos: Se enfocan en técnicas automáticas o manuales
para recolectar datos que ayudan a medir aspectos específicos
 Modelos de Confiabilidad: Se enfocan en estimar las posibles fallas (probabilidad, tasa de ocurrencia,
tiempo medio entre fallas, disponibilidad, etc.). Son adaptaciones de modelos utilizados en elementos de
hardware
 Modelos de Evaluación de Desempeño: Miden la conducta de módulos y sistemas de un software,
bajo la supervisión del sistema operativo o hardware. Generalmente tienen que ver con la eficiencia de
ejecución, tiempo, almacenamiento, complejidad de algoritmos computacionales, etc
 Modelos de Estructura y Complejidad: Definen de una u otra forma la medición de la complejidad;
Tales como volumen, tamaño, anidaciones, costo (estimación), agregación, configuración, y flujo. Estas
son los puntos críticos de la concepción, viabilidad, análisis y diseño de software
 Evaluación de Métodos y Herramientas: Miden la productividad del equipo de desarrollo en función
MÉTRICAS DE PROCESO
PUNTOS DE CASOS DE USO
 Es un método de estimación de esfuerzo para proyectos de software, a partir de sus casos de
uso.
 Fue desarrollado por Gustav Karner en 1993, basándose en el método de puntos de función, y
supervisado por Ivar Jacobson. Ha sido analizado posteriormente en otros estudios, como la
tesis de Kirsten Ribu (Universidad de Oslo) en 2001.
 Toma en cuenta costo, tiempo y asignación de recursos
 Considera que el tiempo para completar el proyecto se ve afectado por: Número de pasos para
completar los casos de uso, cantidad y complejidad de los actores, requerimientos técnicos del
caso de uso, factores externos o ambientales (como la experiencia y conocimientos del equipo
de desarrollo)
 Considera los siguientes porcentajes como parte del esfuerzo de realización del proyecto:
Actividad Porcentaje
Análisis 10%
Diseño 20%
Programación 40%
Pruebas 15%
Sobrecarga 15%
PUNTOS DE CASO DE USO (UCP: USE CASE POINTS)
 Ofrece la posibilidad de estimar las horas-hombre de un proyecto de software que requiere de

casos de uso
 Ecuación:
 UCP=UUCP*TCF*ECF*PF
 UUCP (Unadjusted Use Case Points): Puntos de Caso de Uso sin Ajustar
 UUCP = UAW + UUCW
 UAW (Unadjusted Actors Weights): Pesos de los Actores sin Ajustar
 UUCW (Unadjusted Use Case Weights): Pesos de los casos de uso sin ajustar
 TCF (Technical Complexity Factor): Factor de Complejidad Técnica

 ECF (Environment Complexity Factor): Factor de Complejidad del Ambiente
 PF (Productivity Factor): Factor de Productividad
CÁLCULO DE UUCW
Categoría de Caso de Uso Descripción Peso (factor)

Simple Transacciones= 3 o menos 5
Clases= 4 o menos
Medio Transacciones= 4 a 7 10
Clases= 5 a 10
Complejo Transacciones= 8 o más 15
Clases= 11 o más
UUCW= ∑(Cantidad de cada tipo de caso de uso * Peso)

CÁLCULO DE UAW
Tipo de Actor Descripción Peso (factor)

Simple Otro sistema que actúa con el sistema a 1
desarrollar mediante una interfaz de
programación (API)
Medio Otro sistema interactuando mediante un 2
protocolo (ej. TCP/IP) o de una persona
interactuando a través de una interfaz en
modo texto
Complejo Una persona que interactúa con el sistema a 3
través de una interfaz gráfica (GUI)
UAW= ∑(Cantidad de cada tipo de actor * Peso)

CÁLCULO DE TCF
 Se compone de 13 puntos que evalúan la complejidad de los módulos del sistema que se desarrolla
 Cada factor tiene: Un peso definido (de acuerdo a la tabla) y un factor de complejidad percibido subjetivamente y determinado por la
percepción del equipo de desarrollo
 Se evalúan cada uno de los 13 factores multiplicándolos cada uno por un valor de factor de complejidad y se suman
 Luego la suma se multiplica * 0.01 y al resultado se le suma 0.6
Factor Descripción Peso Factor de
Valor
T1 Sistema distribuido. 2 Complejidad
T2 Rendimiento o tiempo de respuesta. 1 Irrelevante De 0 a 2.
T3 Eficiencia del usuario final. 1
Medio De 3 a 4.
T4 Procesamiento interno complejo. 1
T5 El código debe ser reutilizable. 1 Esencial 5
T6 Facilidad de instalación. 0.5
T7 Facilidad de uso. 0.5
T8 Portabilidad. 2
T9 Facilidad de cambio. 1
TCF= (∑(Peso*Valor)*0.01)+0.6
T10 Concurrencia. 1
T11 Incluye objetivos especiales de seguridad. 1
T12 Provee acceso directo a terceras partes. 1
Se requiere facilidades especiales de entrenamiento a
T13 1
usuario.
CÁLCULO DE ECF
 Se compone de 8 puntos que evalúan las habilidades y experiencia del grupo de personas en el equipo de desarrollo (se
evalúa al grupo como conjunto)
 Cada factor tiene: Un peso definido (de acuerdo a la tabla) y una calificación entre 0 y 5 (la calificación es de menor a
mayor y es subjetivamente asignada)
 Se evalúan cada uno de los 8 factores multiplicando el peso por una calificación y se suman
 Luego la suma se multiplica * -0.03 y al resultado se le suma 1.4
Factor Descripción Peso

Familiaridad con el modelo de
E1 1.5 ECF= (∑(Peso*Calificación)*-0.03)+1.4
proyecto utilizado.
E2 Experiencia en la aplicación. 0.5
Experiencia en orientación a
E3 1
objetos.
E4 Capacidad del analista líder. 0.5
E5 Motivación. 1
E6 Estabilidad de los requerimientos 2
E7 Personal part-time -1
Dificultad del lenguaje de
E8 -1
programación
CÁLCULO DEL PF
 Se usan datos históricos sobre la relación horas hombre requeridos para realizar cada caso
de uso.
 La cantidad de horas hombre se obtiene mediante la fórmula:
 PF=UCP * CF
 UCP, son los puntos de caso de uso ajustados
 CF, son las horas hombre requeridas para completar un caso de uso
 Si no se cuenta con datos históricos, se puede:
 Hacer una estimación con base en otros proyectos similares
 Utilizar un valor entre 15 y 30, dependiendo de la experiencia y logros obtenidos en el pasado por
el equipo de desarrollo. Si se trata de un nuevo equipo se recomienda considerar un valor de 20
 Suponer un sistema para un cajero automático:
EJERCICIO:
 Casos de uso: Retirar dinero, depositar dinero y transferir fondos (3)
 Actores: Cliente, sistema bancario (2)
 Considerar que se trata de un proyecto nuevo

 Solución:
 UCP=UUCP*TCF*ECF*PF
 UUCP= UAW + UUCW
 UAW = 1* 2 + 1 * 3 = 2 + 3 = 5
 UUCW = 5 * 5 + 5 * 5 + 5 * 5 = 15
 UUCP = 20
 TCF= (∑(Peso*Valor)*0.01)+0.6 = (2*1 + 1*5 + 1*5 + 1*3 + 1*0 + 0.5*5 + 0.5*5 + 2*0 + 1*0 + 0.5*5
+ 0.5*5 + 2*0 + 1*5 +1*5 + 1*5 + 1*3 + 1*0) *0.01 + 0.6 = 38 * 0.01 + 0.6 = 0.98
 ECF= (∑(Peso*Calificación)*-0.03)+1.4 = (1.5*5 + -1*3 + 0.5*5 + 0.5*5 + 1*5 + 1*5 + -1*5 + 2*5)*-
0.03 + 1.4 = 24.5 * -0.03 + 1.4 = 0.665
 PF = 20
 UCP = 20 * 0.98 * 0.665 * 20 = 260.68 Horas hombre
 Si tenemos 40 horas por semana, entonces empleamos aproximadamente 7 semanas (redondeando el
TAREA 03, CALCULO DE PUNTOS DE CASOS DE USO:
 Se desea realizar un sistema que permita controlar las ventas de una tienda. El sistema se
conecta con el sistema de almacén para hacer las afectaciones de inventario y con el
sistema de contabilidad para registrar ingresos y egresos. Los usuarios son los vendedores
y el contador de la tienda quienes acceden a través de una GUI.
 Los casos de uso son: Registro de ventas, devoluciones, listado de ventas por período,
listado de ventas por vendedor, apertura de caja, cierre de caja y liquidaciones por lote.
 Calcular el tiempo estimado para realizar el sistema utilizando el método de Puntos de
Casos de Uso
 Considerar que es un sistema totalmente nuevo.
COCOMO Y COCOMO II
 Creado por Barry Boehm en 1981, aparece en el libro “Economía de la Ingeniería del Software”
 El acrónimo COCOMO significa COnstructive COst MOdel (Modelo Constructivo de Costos)
 En 1996 evolucionó a un modelo de estimación más amplio llamado COCOMO II
 Es una jerarquía de modelos de estimación que incluye:
 Modelo de composición de la aplicación. Se emplea durante las primeras etapas de la ingeniería de software, cuando son
primordiales la elaboración de prototipos de las interfaces de usuario, la interacción del software y el sistema, la valoración
del desempeño y la evaluación de la madurez de la tecnología
 Modelo de etapa de diseño temprano. Se utiliza una vez que se han estabilizado los requerimientos y se ha establecido la
arquitectura básica del software
 Modelo de etapa posterior a la arquitectura. Se emplea durante la construcción del software
 Para la estimación del tamaño utiliza tres opciones:

 Puntos de aplicación (Application Points), los cuales son una extensión de los puntos de objeto (object points). Son una
cuenta de pantallas, reportes y modulos desarrollados en la aplicación, cada uno ponderado por un factor de grado de
complejidad.
 Puntos de función (Function Points), miden un proyecto de software mediante la cuantificación de la funcionalidad de
procesamiento de información asociado con entradas, salidas, archivos, interfaces y consultas.
 Líneas de código fuente (Source Lines of Code), cuenta la cantidad de líneas de código, generalmente medidas en millares
(KSLOC)
ESTADIOS DE COCOMO II (1/2)
Aspecto Estadio 1: Composición Estadio 2: Diseño temprano Estadio 3:
de la aplicación Postarquitectura
Tamaño Puntos de aplicación Puntos de función (FP) y lenguaje PF y lenguaje o líneas de
código fuente(SLOC)
Reutilización Implícito en el modelo SLOC equivalente como función SLOC equivalente como
de otras variables función de otras variables
Cambio a los Implícito en el modelo % del cambio expresado como un % del cambio expresado
requerimiento factor del costo como un factor del costo
s
Mantenimient Aplicación, puntual, anual, Función de ACT (Anual Change Función de ACT, compresión
o cambio, tráfico Traffic), compresión del software, del software, no familiaridad
no familiaridad
Escala (C) en 1.0 0.91 a 1.23, dependiendo de la 0.91 a 1.23, dependiendo de
la ecuación precedencia, conformidad, la precedencia, conformidad,
nominal de arquitectura temprana, arquitectura temprana,
esfuerzo resolución de riesgo, cohesión del resolución de riesgo, cohesión
equipo y madurez del proceso de del equipo y madurez del
ESTADIOS DE COCOMO II (2/2)
Aspecto Estadio 1: Composición de Estadio 2: Diseño Estadio 3:
la aplicación temprano Postarquitectura
Costos del Ninguno Complejidad, reutilización Confiabilidad, tamaño de base
producto requerida de datos, necesidades de
documentación, reutilización
requerida y complejidad del
producto
Costos de la Ninguno Dificultad de la plataforma Restricciones del tiempo de
plataforma ejecución, restricciones de
memoria principal y
volatilidad de la máquina
virtual
Costos del Ninguno Capacidad y experiencia del Capacidad del analista,
personal personal experiencia en las
aplicaciones, capacidad del
programador, experiencia del
lenguaje y las herramientas y
continuidad del personal
TABLA I: NIVELES DE COMPLEJIDAD PARA PUNTOS DE
APLICACIÓN
Para Pantallas Para Informes

Número y fuentes de las tablas de Número y fuentes de las tablas de
datos datos
Número Total < 4 Total < 8 Total Número Total < 4 Total < 8 Total
de vistas (<2 (2 a 3 mayor a 8 de (<2 (2 a 3 mayor a 8
contenida servidores servidores (>3 secciones servidores servidores (>3
s , <3 ,3a5 servidores contenida , <3 ,3a5 servidores
clientes) clientes) , >5 s clientes) clientes) , >5
clientes) clientes)
<3 Simple Simple Medio 0o1 Simple Simple Medio
3-7 Simple Medio Complejo 2o3 Simple Medio Complejo
8 o más Medio Complejo Complejo 4 o más Medio Complejo Complejo
ar servidores como tablas de datos que están en un servidor y que se usan como base para la pantalla o e
ar clientes como tablas de datos que están en un cliente y que se usan como base para la pantalla o el rep
TABLA II: PESOS DE COMPLEJIDAD PARA LOS PUNTOS DE
APLICACIÓN
Tipo de elemento Simple Medio Complejo

Pantalla 1 2 3
Informe 2 5 8
Componente de 3 GL - - 10
(librería)
TABLA III: CÁLCULO DE LA PRODUCTIVIDAD ESTIMADA
Experiencia Muy baja Baja Nominal Alta Muy Alta

y capacidad (De 3 a (De 5 a (De 9 meses (De 1 a (De 2 a
de los menos de 5 menos de 9 a menos de menos de 2 menos de 4
desarrollado meses de meses de 1 año de años de años de
res experiencia) experiencia) experiencia) experiencia) experiencia)
Madurez y Muy baja Baja Nominal Alta Muy Alta
capacidad
ICASE
Tasa de 4 7 13 25 50
productividad
PROCEDIMIENTO PARA CONTAR LOS PUNTOS DE APLICACIÓN
(ESTADIO I)
1. Estimar el número de pantallas, reportes y componentes 3GL que componen la aplicación.

2. Clasificar cada instancia de objeto en simple, media o compleja dependiendo de los valores de sus
dimensiones características (Tabla I)
3. Ponderar el número de puntos para cada instancia de objeto simple asignándole puntos de acuerdo
a su complejidad (Tabla II) PuntosObjeto=∑(ObjetoClasificado*Puntos)
4. Estimar el porcentaje de re-uso que se espera alcanzar en el proyecto:
NuevosPuntosObjeto=(PuntosObjeto)*(100 - %Re-uso)/100
5. Determinar una tasa de productividad para el equipo (Tabla III)
Productividad=TasaDeProductividad
6. Determinar la cantidad esperada de esfuerzo medido en persona-mes
PersonaMes=NuevosPuntosObjeto/Productividad
EJERCICIO 1/2:
 Suponer un sistema para un cajero automático:

 Funcionalidades a desarrollar: Retirar dinero, depositar dinero y transferir fondos
 Considerar que se trata de un proyecto nuevo

 Solución:
 Estimar la cantidad de pantallas, reportes y componentes 3GL
 Se considera que Retirar dinero lleva una vista de solicitar datos, una de confirmación y una de entrega de dinero
 Depositar dinero lleva una vista de solicitar datos, una de solicitud del dinero y una de confirmación
 Se requiere un reporte para el saldo del usuario que tiene una sola sección
 Transferir fondos requiere de una vista de datos y una vista de confirmación
 Se requiere un componente 3GL para transacciones con el sistema bancario
 Damos una clasificación a cada instancia de objeto:

 Retirar dinero, pantalla con 3 a 7 vistas, manejo de dos tablas en el servidor: Medio
 Depositar dinero, pantalla con 3 a 7 vistas, manejo de dos tablas en el servidor: Medio
 Informe de Saldo: reporte con 2 secciones (datos de cliente y totales), manejo de tres tablas en el servidor: Medio
 Transferir fondos: pantalla con 2 vistas, manejo de 4 tablas servidor: Medio
 Componente 3GL de Transacciones
EJERCICIO 2/2:
 Damos una clasificación a cada instancia de objeto:

 Retirar dinero, pantalla con 3 a 7 vistas, manejo de dos tablas en el servidor: Medio
 Depositar dinero, pantalla con 3 a 7 vistas, manejo de dos tablas en el servidor: Medio
 Informe de Saldo: reporte con 2 secciones (datos de cliente y totales), manejo de tres tablas en el servidor: Medio
 Transferir fondos: pantalla con 2 vistas, manejo de 4 tablas servidor: Medio
 Componente 3GL de Transacciones
 Ponderar la cantidad de puntos de cada instancia

 3 Pantallas medio: 3*2=6
 1 Informe medio: 1*5=5
 1 Componente 3GL 1*10=10
 PuntosObjeto = 6 + 5 + 10 = 21
 Estimar reutilización (en este caso es 0)

 NuevosPuntosObjeto = 21 * (100-0)/100 = 21 * 1 = 21
 Obtener productividad:
 Se estima un equipo con experiencia estándar, se entiende como nominal, valor 13 según la tabla:
 Productividad = 13
 Calcular la cantidad esperada de esfuerzo:

 PersonaMes = 21 / 13 = 1.62 meses de esfuerzo de una persona
TAREA 04 (ESTIMACIONES DE SOFTWARE CON COCOMO II):
 Se desea realizar un sistema que permita controlar las ventas de una tienda. El sistema se
conecta con el sistema de almacén para hacer las afectaciones de inventario y con el
sistema de contabilidad para registrar ingresos y egresos. Los usuarios son los vendedores
y el contador de la tienda quienes acceden a través de una GUI.
 Los casos de uso son: Registro de ventas, devoluciones, listado de ventas por período,
listado de ventas por vendedor, apertura de caja, cierre de caja y liquidaciones por lote.
 Calcular el tiempo estimado para realizar el sistema utilizando el método de COCOMO II
para estadio 1
 Considerar que es un sistema que reutilizará un 10 % de componentes anteriores
 Su equipo tiene baja experiencia en el desarrollo de este tipo de aplicaciones
ESTADIO 2: CONTEO DE PUNTOS DE FUNCIÓN (1/2)
 El enfoque de estimación de costos mediante puntos de función se basa en el monto de funcionalidad en un
proyecto de software y en un conjunto de factores individuales del proyecto.
 Los puntos de función miden un proyecto de software mediante la cuantificación de la funcionalidad de
procesamiento asociada a los mayores datos externos, controles de entrada, controles de salida o tipos de archivo.
 Los tipos de funciones de usuario son:
 Entrada externa (Inputs, Entradas, EI): Cuenta cada dato de usuario único o tipo de control de entrada de usuario que (i)
Ingresa la frontera externa del software bajo medición, y (ii) añade o modifica datos en un archivo lógico interno.
 Salida externa (Outputs, Salidas, EO): Cuenta cada dato de usuario único o tipo de control de salida que abandona la frontera
externa del software que está siendo medido.
 Archivo lógico interno (Files, Archivos, ILF): Cuenta cada grupo principal de datos de usuario o información de control en el
sistema de software como un tipo de archivo lógico interno. Incluye cada archivo lógico (por ejemplo, cada grupo lógico de
datos) que es generado, utilizado o mantenido por el sistema de software.
 Archivos de interface externa (Interfaces, Interfaces, EIF): Archivos que se pasan o comparten entre sistemas de software
deberán ser contados como archivos de tipo de interface interna dentro de cada sistema.
 Cuestionamiento externo (Queries, Consultas, EQ): Cuenta cada combinación única de entrada-salida, donde la entrada
causa y genera una salida inmediata, como un tipo de consulta externa.
 Cada instancia de estos tipos de función se clasifica conforme a su complejidad. Los niveles de complejidad
determinan un conjunto de pesos que son aplicados a sus correspondientes conteos de función para determinar la
cantidad de Puntos de Función sin Ajustar.
ESTADIO 2: CONTEO DE PUNTOS DE FUNCIÓN (2/2)
 COCOMO II utiliza como mediciones para estimar tamaño los Puntos de Función partiendo de
los Puntos de Función sin Ajustar.
 El procedimiento usual de conteo de Puntos de Función involucra asegurar el Grado de
Influencia (DI) de catorce características del proyecto de software determinado conforme a
una escala de calificación entre 0.0 y 0.05 para cada característica.
 Las catorce características son sumadas y se añaden a un nivel base de 0.65 para producir un
factor general de ajuste de características que va entre 0.65 y 1.35.
 Cada una de esas catorce características, tales como: funciones distribuidas, desempeño y
reusabilidad, significan un máximo de 5% de contribución al esfuerzo estimado.
 COCOMO II utiliza los Puntos de Función sin Ajustar para medir y aplica factores de
reutilización, multiplicadores de esfuerzo de conducción de costo, y factores de escala
exponencial para cuantificar el tamaño.
PROCEDIMIENTO DE CONTEO DE PUNTOS DE FUNCIÓN SIN
AJUSTAR Y CONVERSIÓN A LÍNEAS DE CÓDIGO
1. Determinar la cantidad de cada uno de los cinco tipos de función y clasificarlos

según su nivel de complejidad (Tabla 1).
2. Aplique los pesos de complejidad (Tabla 2) a las funciones, multiplicando la suma
de cada tipo de función según su complejidad por sus pesos correspondientes
3. Sumar todas las funciones a las que se aplicaron los pesos de complejidad para
obtener la cantidad de puntos de función sin ajustar
4. Convertir los puntos de función sin ajustar a líneas de código fuente (SLOC)
conforme al lenguaje de programación a utilizar, según su equivalencia (Tabla 3)
http://www.cs.bsu.edu/homepages/dmz/cs697/langtbl.htm (a 1996) y
http://www.qsm.com/resources/function-point-languages-table (a 2016)
5. Convertir las líneas de código fuente (SLOC) a miles de líneas de código fuente
(KSLOC). Dividir SLOC entre 1000 para obtener KSLOC
PROCEDIMIENTO DE CALCULO DE LOS FACTORES DE COSTO
 Los factores de costo se utilizan para capturar las características del desarrollo de software que
afectan al esfuerzo para completar el proyecto
 Los factores de costo tienen un nivel de calificación que expresan el impacto del factor en el
esfuerzo de desarrollo (PM)
 El rango puede variar de extra bajo a extra alto
 Para el propósito del análisis cuantitativo, cada factor de costo tiene un peso asociado con él
 El peso se conoce como Multiplicador de Esfuerzo (EM)
 Multiplicador de Esfuerzo promedio asignado a un factor de costo es de 1.0 y el nivel de
 El
calificación asociado al peso es llamado Nominal
 Si un nivel de calificación es mayor a 1 significa que hay un mayor esfuerzo, si es menor a 1
significa que el esfuerzo se reduce
 La formula para calcular los factores de costo es:
 Los factores de costo que se usan en el Estadio 2 (diseño temprano) se presentan en la Tabla 4
TABLA 1: NIVELES DE COMPLEJIDAD
Para ILF y EIF Para EO y EQ Para EI

Elementos de Datos Elementos de Datos Tipos Elementos de Datos
Element
Tipos de de
os de 1a 20 a 51 o 6a 20 o 5a 16 o
Archivos 1a5 Archivo 1a4
Registro 19 50 más 19 más 15 más
s
Prom
1 Bajo Bajo 0o1 Bajo Bajo Prom. 0o1 Bajo Bajo Prom.
.
Prom
2a5 Bajo Alto 2a3 Bajo Prom. Alto 2a3 Bajo Prom. Alto
.
Prom
6 o más Alto Alto 4 o más Prom. Alto Alto 4 o más Prom. Alto Alto
.
TABLA 2: PESOS POR NIVEL DE COMPLEJIDAD
Pesos de Complejidad
Tipo de función
Bajo Promedio Alto
Archivo Interno Lógico (ILF) 7 10 15
Archivos de Interface
5 7 10
Externa (EIF)
Entradas Externas (EI) 3 4 6
Salidas Externas (EO) 4 5 7
Consultas Externas (EQ) 3 4 6
TABLA 3: EQUIVALENCIAS DE PUNTOS DE FUNCIÓN SIN AJUSTAR A LÍNEAS
DE CÓDIGO EN DIFERENTES LENGUAJES DE PROGRAMACIÓN (1/17)
Líneas (sentencias) de
Código Fuente (SLOC)
Lenguaje Nivel
Promedio por Punto de
Función
1a Generación default 1.00 320
Lenguaje Nivel SLOC/UF Lenguaje Nivel SLOC/UF Lenguaje Nivel SLOC/UF
P P P
20.00 16 16.00 20 25.00 13
1032/AF ADS/Online ANSWER/DB
3.50 91 6.50 49 10.00 32
AAS Macro AI shell default APL 360/370
20.00 16 6.50 49 10.00 32
ABAP/4 AI SHELLS APL default
17.00 19 3.00 107 10.00 32
ACCEL ALGOL 68 APL*PLUS
APPLESOFT
8.50 38 3.00 107 2.50 128
Access ALGOL W BASIC
Application
15.00 21 10.00 32 16.00 20
ACTOR AMBUSH Builder
Application
11.50 28 6.50 49 9.00 36
Acumen AML Manager
4.50 71 5.00 64 19.00 17
Ada 83 AMPPL II APS
6.50 49 5.00 64 4.50 71
Ada 95 ANSI BASIC APT
8.00 40 3.00 107 16.00 20
ADR/DL ANSI COBOL 74 APTools
16.00 20 3.50 91 6.50 49
ADR/IDEAL/PDL ANSI COBOL 85 ARC
16.00 20 25.00 13 3.00 107
ADS/Batch ANSI SQL Ariel
P P P
6.50 49 1.00 320 50.00 6
ARITY Autocoder BOEINGCALC
5.00 64 15.00 21 25.00 13
Arity PROLOG awk BTEQ
6.50 49 2.50 128 2.50 128
ART Aztec C C
7.00 46 3.00 107 3.50 91
ART-IM BALM C Set 2
7.00 46 6.00 53 6.00 53
ART Enterprise BASE SAS C++
8.00 40 3.00 107 2.50 128
Artemis BASIC C86Plus
17.00 19 2.50 128 8.00 40
AS/SET BASIC A CA-dBFast
25.00 13 1.00 320 11.50 28
ASI/INQUIRY Basic assembly CA-EARL
7.00 46 3.50 91 6.50 49
ASK Windows Berkeley PASCAL CAST
1.00 320 3.50 91 3.50 91
Assembly (Basic) BETTER BASIC CBASIC
1.50 213 3.00 107 16.00 20
Assembly (Macro) BLISS CDADL
Associative
5.00 64 9.00 36 7.00 46
default BMSGEN CELLSIM
P P P
6.00 53 17.00 19 5.00 64
Centerline C++ CMSGEN Common LISP
Concurrent
3.00 107 3.00 107 4.00 80
CHILI COBOL PASCAL
3.00 107 3.00 107 5.00 64
CHILL COBOL II CONNIVER
7.00 46 3.50 91 3.00 107
CICS Cobol/400 CORAL 66
5.50 58 16.00 20 17.00 19
CLARION COBRA CORVET
4.00 80 9.00 36 22.00 15
CLASCAL CodeCenter CorVision
10.00 32 9.00 36 2.00 160
CLI Cofac CPL
17.00 19 9.00 36 16.00 20
CLIPPER COGEN Crystal Reports
8.00 40 9.00 36 6.50 49
CLIPPER DB COGNOS CSL
15.00 21 4.50 71 6.00 53
CLOS COGO CSP
8.00 40 4.00 80 7.00 46
CLOUT COMAL CSSL
3.00 107 5.00 64 25.00 13
CMS2 COMIT II CULPRIT
P P P
6.50 49 17.00 19 27.00 12
CxPERT DNA-4 EDA/SQL
17.00 19 2.50 128 15.00 21
CYGNET DOS Batch Files EIFFEL
8.00 40 2.00 160 7.00 46
Data base default DSP Assembly ENFORM
English-based
8.00 40 7.00 46 6.00 53
Dataflex DTABL default
16.00 20 7.00 46 11.00 29
Datatrieve DTIPT Ensemble
8.00 40 4.50 71 16.00 20
dBase III DYANA EPOS
9.00 36 7.00 46 8.00 40
dBase IV DYNAMO-III Erlang
1.50 213 11.00 29 8.00 40
DCL EASEL ESF
8.00 40 6.50 49 6.50 49
DEC-RALLY EASY ESPADVISOR
Decision support
9.00 36 25.00 13 4.50 71
default EASYTRIEVE + ESPL/I
11.00 29 6.50 49 3.00 107
DELPHI Eclipse EUCLID
8.00 40 6.00 53 51.00 6
DL/1 ED-Scheme 3.4 EXCEL 1-2
P P P
55.00 6 11.00 29 8.00 40
EXCEL 3-4 FlexGen FOXPRO 1
57.00 6 8.00 40 9.50 34
EXCEL 5 FOCUS FOXPRO 2.5
9.00 36 6.00 53 50.00 6
EXPRESS FOIL FRAMEWORK
6.50 49 18.00 18 6.50 49
EXSYS Forte G2
Extended
5.75 56 5.00 64 20.00 16
Common LISP FORTH GAMMA
9.00 36 2.50 128 12.00 27
EZNOMAD FORTRAN 66 Genascript
16.00 20 3.00 107 25.00 13
Facets FORTRAN 77 GENER/OL
11.00 29 4.00 80 21.00 15
FactoryLink IV FORTRAN 90 GENEXUS
9.00 36 4.50 71 17.00 19
FAME FORTRAN 95 GENIFER
9.00 36 3.00 107 20.00 16
FileMaker Pro FORTRAN GeODE 2.0
11.00 29 2.50 128 9.50 34
FLAVORS FORTRAN II GFA Basic
7.00 46 11.00 29 7.00 46
FLEX Foundation GML
P P P
Golden Common
5.00 64 16.00 20 10.00 32
LISP IBM ADF I IFPS/PLUS
7.00 46 18.00 18 8.00 40
GPSS IBM ADF II IMPRS
IBM Advanced
11.50 28 3.25 98 8.00 40
GUEST BASIC INFORMIX
6.50 49 8.00 40 8.00 40
Guru IBM CICS/VS INGRES
IBM Compiled
3.25 98 3.50 91 25.00 13
GW BASIC BASIC INQUIRE
8.50 38 3.00 107 6.50 49
Haskell IBM VS COBOL INSIGHT2
2.50 128 3.50 91 20.00 16
High C IBM VS COBOL II INSTALL/1
5.50 58 4.50 71 6.00 53
HLEVEL ICES INTELLECT
2.50 128 4.00 80 5.50 58
HP BASIC ICON INTERLISP
Interpreted
20.00 16 8.00 40 3.00 107
HTML 2.0 IDMS BASIC
22.00 15 23.00 14 2.50 128
HTML 3.0 IEF Interpreted C
20.00 16 23.00 14 5.50 58
Huron IEW IQLISP
P P P
25.00 13 5.00 64 15.00 21
IQRP KLO LOOPS
4.50 71 6.50 49 50.00 6
JANUS KNOWOL LOTUS 123 DOS
6.00 53 5.50 58 3.00 107
JAVA KRL LOTUS Macros
1.45 221 15.00 21 51.00 6
JCL KSH LUCID 3D
3.00 107 9.00 36 6.00 53
JOSS Ladder Logic LYRIC
3.00 107 5.00 64 20.00 16
JOVIAL LAMBIT/L M
8.00 40 2.50 128 5.00 64
KAPPA Lattice C macFORTH
6.50 49 2.50 128 8.00 40
KBMS Liana MACH1
Machine
5.00 64 4.50 71 0.50 640
KCL LILITH language
6.50 49 23.00 14 1.50 213
KEE LINC II Macro assembly
8.00 40 5.00 64 20.00 16
Keyplus LISP MAESTRO
5.00 64 5.50 58 20.00 16
KL LOGLISP MAGEC
P P P
15.00 21 2.50 128 6.00 53
MAGIK Microsoft C NATURAL 1
15.00 21 16.00 20 7.00 46
MAKE MicroStep NATURAL 2
NATURAL
8.00 40 8.00 40 13.00 25
MANTIS Miranda Construct
6.00 53 8.50 38 0.10 3200
MAPPER Model 204 Natural language
8.00 40 4.00 80 17.00 19
MARK IV MODULA 2 NETRON/CAP
9.00 36 50.00 6 6.50 49
MARK V MOSAIC NEXPERT
60.00 5 6.00 53 6.50 49
MATHCAD MS C ++ V. 7 NIAL
MS Compiled
9.00 36 3.50 91 8.00 40
MDL BASIC NOMAD2
Non-procedural
6.00 53 5.00 64 9.00 36
MENTOR MSL default
3.00 107 5.00 64 9.00 36
MESA muLISP Notes VIP
Microfocus
4.00 80 17.00 19 6.00 53
COBOL MUMPS Nroff
Object-Oriented
5.00 64 4.50 71 11.00 29
microFORTH NASTRAN default
P P P
OBJECT
5.00 64 8.00 40 6.00 53
Assembler ORACLE PILOT
Oracle
11.00 29 14.00 23 4.00 80
Object LISP Developer/2000 PL/I
11.00 29 3.00 107 4.50 71
Object LOGO Oscar PL/M
11.00 29 22.00 15 3.50 91
Object PASCAL PACBASE PL/S
20.00 16 8.00 40 6.00 53
Object Star PACE PLANIT
12.00 27 9.00 36 5.00 64
Objective-C PARADOX/PAL PLANNER
13.00 25 3.50 91 45.00 7
ObjectVIEW PASCAL PLANPERFECT 1
4.00 80 9.00 36 6.00 53
OGL PC FOCUS PLATO
8.00 40 15.00 21 5.00 64
OMNIS 7 PDL Millenium polyFORTH
11.00 29 6.00 53 5.50 58
OODL PDP-11 ADE POP
7.00 46 15.00 21 5.50 58
OPS PERL POPLOG
Persistance
5.50 58 15.00 21 6.50 49
OPS5 Object Builder Power BASIC
P P P
20.00 16 3.00 107 11.50 28
PowerBuilder PROTEUS Quickbuild
23.00 14 5.50 58 22.00 15
POWERHOUSE QBasic QUIZ
8.00 40 25.00 13 8.00 40
PPL (Plus) QBE RALLY
12.00 27 22.00 15 8.00 40
Pro-C QMF RAMIS II
5.50 58 6.50 49 11.50 28
PRO-IV QNIAL RapidGen
Problem-oriented
4.50 71 51.00 6 3.50 91
default QUATTRO RATFOR
Procedural
3.00 107 51.00 6 8.00 40
default QUATTRO PRO RDB
Professional
3.50 91 25.00 13 7.00 46
PASCAL Query default REALIA
Program
20.00 16 5.00 64 8.00 40
Generator default QUICK BASIC 1 Realizer 1.0
9.00 36 5.25 61 9.00 36
PROGRESS V4 QUICK BASIC 2 Realizer 2.0
5.00 64 5.50 58 8.00 40
PROLOG QUICK BASIC 3 RELATE/3000
3.00 107 2.50 128 60.00 5
PROSE Quick C Reuse default
P P P
4.00 80 10.00 32 7.00 46
REXX (MVS) SAS Simulation default
7.00 46 25.00 13 15.00 21
REXX (OS/2) SAVVY SMALLTALK 286
3.50 91 3.50 91 15.00 21
RM BASIC SBASIC SMALLTALK 80
3.00 107 4.50 71 15.00 21
RM COBOL SCEPTRE SMALLTALK/V
3.00 107 6.00 53 4.00 80
RM FORTRAN SCHEME SNAP
Screen painter
4.00 80 57.00 6 2.50 128
RPG I default SNOBOL2-4
5.50 58 27.00 12 23.00 14
RPG II SEQUAL SoftScreen
5.75 56 15.00 21 5.50 58
RPG III SHELL SOLO
5.50 58 9.00 36 9.00 36
RT-Expert 1.4 SIMPLAN SPEAKEASY
10.00 32 7.00 46 9.00 36
S-PLUS SIMSCRIPT Spinnaker PPL
Spreadsheet
3.00 107 7.00 46 50.00 6
SAIL SIMULA default
20.00 16 7.00 46 1.00 320
SAPIENS SIMULA 67 SPS
P P P
10.00 32 5.00 64 22.00 15
SPSS SYMBOLANG TRANSFORM
TRANSLISP
25.00 13 18.00 18 5.75 56
SQL Synchroworks PLUS
27.00 12 17.00 19 5.00 64
SQL-Windows SYNON/2E TREET
10.00 32 9.00 36 5.00 64
Statistical default System-W TREETRAN
Tandem Access TRS80 BASIC
9.00 36 3.50 91 2.50 128
STRATEGEM Language II,III
4.50 71 5.00 64 5.00 64
STRESS TCL TRUE BASIC
Strongly typed
3.50 91 20.00 16 2.50 128
default TELON Turbo C
7.00 46 8.00 40 6.00 53
STYLE TESSARACT TURBO C++
9.00 36 50.00 6 6.50 49
SUPERBASE 1.3 THE TWIN TURBO EXPERT
50.00 6 25.00 13 6.50 49
SURPASS THEMIS Turbo PASCAL >5
Turbo PASCAL 1-
8.00 40 23.00 14 4.00 80
SYBASE TI-IEF 4
Turbo PASCAL 4-
11.00 29 11.00 29 4.50 71
Symantec C++ Topspeed C ++ 5
P P P
4.00 80 17.00 19 16.00 20
Turbo PROLOG VHDL Visual COBOL
4.00 80 6.50 49 20.00 16
TURING Visible C Visual Objects
6.00 53 8.00 40 15.00 21
TUTOR Visible COBOL VisualAge
6.50 49 35.00 9 18.00 18
TWAICE Visicalc 1 VisualGen
3.50 91 11.00 29 10.00 32
UCSD PASCAL Visual 4.0 VS-REXX
9.00 36 7.00 46 5.00 64
UFO/IMS Visual Basic 1 VULCAN
10.00 32 7.50 43 9.00 36
UHELP Visual Basic 2 VZ Programmer
20.00 16 8.00 40 8.00 40
UNIFACE Visual Basic 3 WARP X
UNIX Shell
15.00 21 9.00 36 2.50 128
Scripts Visual Basic 4 WATCOM C
5.50 58 11.00 29 2.50 128
VAX ACMS Visual Basic 5 WATCOM C/386
8.00 40 8.00 40 2.50 128
VAX ADE Visual Basic DOS Waterloo C
3.00 107 9.50 34 3.50 91
VECTRAN Visual C++ Waterloo PASCAL
P P P
WATFIV 3.75 85
WATFOR 3.50 91
WHIP 3.50 91
Wizard 11.50 28
XLISP 5.00 64
YACC 6.00 53
YACC++ 6.00 53
ZBASIC 3.50 91
ZIM 17.00 19
ZLISP 5.00 64
Lenguaje SLOC/UF SLOC/UF Lenguaje SLOC/UF SLOC/UF Lenguaje SLOC/UF SLOC/UF

P P P P P P
(promedi (median (promedi (median (promedi (median
o) a) o) a) o) a)
ABAP (SAP) * 28 18 Cool:Gen/IEF * 32 24 LINC II 29 30
ASP* 51 54 Datastage 71 65 Lotus Notes * 23 21
Assembler * 119 98 Excel * 209 191 Natural * 40 34
Brio + 14 14 Focus * 43 45 .NET * 57 60
C* 97 99 FoxPro 36 35 Oracle * 37 40
C++ * 50 53 HTML * 34 40 PACBASE * 35 32
C# * 54 59 J2EE * 46 49 Perl * 24 15
COBOL * 61 55 Java * 53 53 PL/1 * 64 80
Cognos
Impromptu 47 42 JavaScript * 47 53 PL/SQL * 37 35
Scripts +
Cross System
Products (CSP) 20 18 JCL * 62 48 Powerbuilder * 26 28
+
Lenguaje SLOC/UF SLOC/UF Lenguaje SLOC/UF SLOC/UF Lenguaje SLOC/UF SLOC/UF

P P P P P P
(promedi (median (promedi (median (promedi (median
o) a) o) a) o) a)
REXX * 77 80
Sabretalk * 70 66
SAS * 38 37
Siebel * 59 60
SLOGAN * 75 75
SQL * 21 21
VB.NET * 52 60
Visual Basic * 42 44
RELACIÓN DEL NIVEL DEL LENGUAJE CONTRA LA
PRODUCTIVIDAD (TABLA 3, 1 AL 15)
Nivel del Productividad Promedio Por Persona por Mes

Lenguaje
1a3 5 a 10 puntos de función
4a8 10 a 20 puntos de función
9 a 15 16 a 23 puntos de función
Mayor a 55 40 a 100 puntos de función
TABLA 4: FACTORES DE COSTO USADOS EN DISEÑO
TEMPRANO (ESTADIO 2) Y EN POST-ARQUITECTURA
(ESTADIO 3)
Acrónimo Significado
Factores de Diseño Contraparte Combinada Capacidad de los Analistas
ACAP (3)
Temprano (2) en Post-Arquitectura (3) AEXP (3) Experiencia en Aplicaciones Semejantes
CPLX (3) Complejidad del Producto de Software
RCPX RELY, DATA, CPLX, DOCU DATA (3) Tamaño de la Base de Datos
Necesidades de documentación contra ciclo de vida
RUSE RUSE DOCU (3)
FCIL (2) Facilidades
PDIF TIME, STOR, PVOL LTEX (3) Experiencia en el Lenguaje y Herramientas de Desarrollo
PCAP (3) Capacidad de los Programadores
PERS ACAP, PCAP, PCON PCON (3) Continuidad del Personal
PDIF (2) Dificultad de la Plataforma
PREX AEXP, PLEXP, LTEX PERS (2) Capacidad Personal
Experiencia en la Plataforma de Desarrollo
FCIL TOOL, SITE PLEXP (3)
PREX (2) Experiencia del Personal
SCED SCED PVOL (3) Volatilidad de la Plataforma
RCPX (2) Confiabilidad y Complejidad del Producto
Calificació Calificación RELY (3) Confiabilidad Requerida del Software
n Numérica RUSE (2, 3) Reusabilidad Requerida
Muy Bajo 1 SCED (2) Programa (cronograma)
Bajo 2 SITE (3) Desarrollo multi-sitio
STOR (3) Restricciones del almacenamiento principal
Nominal 3
TIME (3) Restricciones en el tiempo de ejecución
Alto 4 TOOL (3) Uso de Herramientas de Software de Desarrollo
Muy Alto 5
Extra Alto 6
TABLA 6: CAPACIDAD DEL PERSONAL (PERS)
Extra Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto
Bajo
PERS 3,4 5,6 7,8 9 10,11 12,13 14,15
2.12 1.62 1.26 1.00 0.83 0.63 0.50
ACAP: Percentil Percentil Percentil Percentil Percentil
Capacidad 15 35 55 75 90
del Analista 1.42 1.19 1.00 0.85 0.71
PCAP: Percentil Percentil Percentil Percentil Percentil

Capacidad 15 35 55 75 90
del 1.34 1.15 1.00 0.88 0.76
Programador
PCON: Continuida Continuida Continuida Continuida Continuida
Continuidad d anual d anual d anual d anual 6% d anual 3%
del Personal 48% 24% 12% 0.90 0.81
1.29 1.12 1.00
TABLA 6: CONFIABILIDAD Y COMPLEJIDAD (RCPX)
Extra Bajo Muy Bajo Nominal Alto Muy Alto Extra Alto
Bajo
RCPX 5, 6 7, 8 9 a 11 12 13 a 15 16 a 18 19 a 21
0.49 0.60 0.83 1.00 1.33 1.91 2.72
RELY: Énfasis Muy poco Poco Algo Básico Fuerte Muy Fuerte Extremo
en la 1.23 1.10 1.00 0.99 1.07
confiabilidad
DATA: Pequeño Pequeño Pequeño Moderado Grande Muy Extremo
Tamaño de 0.90 1.00 1.14 Grande
la base de 1.28
datos
CPLX: Muy simple Simple Algo Moderado Complejo Muy Extremada
Complejidad 0.73 0.87 1.00 1.17 Complejo mente
del producto 1.34 complejo
1.74
TABLA 7: REUTILIZACIÓN REQUERIDA (RUSE)
Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto

RUSE 1 2 3 4 5 6
Nada Sobre todo Sobre todo Sobre la Sobre
0.95 el proyecto el programa línea de múltiples
1.00 1.07 productos líneas de
1.15 productos
1.24
TABLA 8: DIFICULTAD DE LA PLATAFORMA (PDIF)
Bajo Nominal Alto Muy Alto Extra

Alto
PDIF 8 9 10 a 12 13 a 15 16, 17
0.87 1.00 1.29 1.81 2.61
TIME: <=50% <=50% 70% 85% 95%
Restricciones 1.00 1.11 1.29 1.63
de tiempo
STOR: <=50% <=50% 70% 85% 95%
Restricciones 1.00 1.05 1.17 1.46
de
almacenamie
nto
PVOL: Muy Estable Algo Volátil Altamente
Volatilidad de Estable 1.00 Volátil 1.30 Volátil
la plataforma 0.87 1.15
TABLA 9: EXPERIENCIA DEL PERSONAL (PREX)
Extra Bajo Muy Bajo Nominal Alto Muy Alto Extra Alto
Bajo
PREX 3, 4 5, 6 7, 8 9 10, 11 12, 13 14, 15
1.59 1.33 1.22 1.00 0.87 0.74 0.62
APEX: <=2 6 meses 1 año 3 años 6 años
Experiencia meses 1.10 1.00 0.88 0.81
en las 1.22
aplicaciones
PLEXP: <=2 6 meses 1 año 3 años 6 años
en la 1.19
plataforma
LTEX: <=2 6 meses 1 año 3 años 6 años
en el 1.20
lenguaje y
TABLA 10: FACILIDADES (FCIL)
Extra Muy Bajo Nominal Alto Muy Alto Extra Alto
Bajo Bajo
PREX 2 3 4,5 6 7,8 9,10 11
1.43 1.30 1.10 1.0 0.87 0.73 0.62
TOOL: Uso Mínimo Algo Herramien Herramien Buena; Fuerte; Fuerte;
de 1.17 tas CASE tas básicas moderada moderada bien
herramienta simples de ciclo de 0.90 0.78 integrada
s 1.09 vida
1.00
SITE: Débil Algún Algún Soporte Fuerte de Fuerte de Fuerte de
Condiciones soporte soporte soporte de básico de soporte de soporte de soporte de
de de de desarrollo desarrollo desarrollo desarrollo desarrollo
desarrollo desarroll desarroll multisitio multisitio multisitio multisitio multisitio
en múltiples o o moderada moderada moderada simple colocado o
sitios multisitio multisitio mente mente mente 0.86 simple
(comunicaci complejo complejo complejo complejo complejo 0.80
ones) 1.22 1.09 1.00 0.93
TABLA 11: PROGRAMA DE TRABAJO (SCED)
Muy Bajo Bajo Nominal Alto Muy Alto

SCED 1 2 3 4 5
75% de 85% 100% 130% 160%
nominal 1.14 1.00 1.00 1.00
1.43
TABLA 12: FACTORES DE ESCALA (SF)
Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto

PREC: Sin Pocos Algún Algo Familiar Muy Familiar Extremadam
Precedentes precedente precedentes precedente 2.48 1.24 ente familiar
s 4.96 3.72 0.00
6.20
FLEX: Riguroso Relajación Alguna Conformidad Alguna Metas
Flexibilidad de 5.07 ocasional relajación general conformidad generales
Desarrollo 4.05 3.04 2.03 1.01 0.00
RESL: Poco (20%) Algo (40%) Seguido(60 Generalmen Casi siempre Completame
Resolución de 7.07 5.65 %) te (75%) (90%) nte (100%)
arquitectura/rie 4.24 2.83 1.41 0.00
sgos
TEAM: Cohesión Interaccion Alguna Cooperación Cooperativo Altamente Cooperación
del equipo es muy dificultad al básica s Cooperativo sin
difíciles interactuar 3.29 2.19 s problemas
5.48 4.38 1.10 0.00
PMAT: Madurez CMM Nivel CMM Nivel 1 CMM Nivel 2 CMM Nivel 3 CMM Nivel 4 CMM Nivel 5
ESTIMACIÓN DEL TAMAÑO (SLOC) USANDO PUNTOS DE
FUNCIÓN
 Un Punto de Función se define como una función comercial de usuario final.

 Clasificar cada Función conforme a las tablas de Niveles de Complejidad
 Obtener los Puntos de Función sin Ajustar determinando los pesos para cada Función y
hacer la sumatoria correspondiente
 Utilizar la tabla de Equivalencias de puntos de función sin ajustar a líneas de código en
diferentes lenguajes de programación para obtener el equivalente en líneas de código
 Obtener
FORMULAS USUALES DE COCOMO II EN ESTADIO 2
 Cantidad de esfuerzo en personas por mes para un programa nominal

 EM son los multiplicadores de esfuerzo (son 6 para el diseño temprano y 16 para post-arquitectura)
 El tamaño es SLOC (las líneas de código fuente estimadas)
 Cantidad de tiempo nominal para desarrollar el producto

 SF son los factores de escala exponenciales

 F=0.2x(E-B)
 En el 2000 los valores para:

 A = 2.94
 B = 0.91
 C = 3.67
 D = 0.28
FORMULAS
INVESTIGACIÓN 04: MÉTRICAS
 Explique como se hace el cálculo de Puntos de Función y el Esfuerzo

de Desarrollo para el estadio 3 de COCOMO II, proporcione un ejemplo
 Explique que métricas de producto existen para cada uno de los
siguientes factores, defina cada una de las métricas, explique el
procedimiento de cálculo y proporcione un ejemplo:
 Tamaño (longitud)
 Complejidad
 Mantenibilidad
 Explique que métricas se han creado para apoyar la medición de

sistemas orientados a objetos, explique los procedimientos de cálculo
y proporcione ejemplos

Metodologías de Desarrollo de Sistemas

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Metodologías de Desarrollo de Sistemas

Caricato da

Copyright:

Formati disponibili

METODOLOGÍAS DE

2. Métricas del Producto

3. Software para obtener métricas y registrar esfuerzo.

 Objeto a medir: Establecer con precisión cuál es el objeto de

 Producir una afirmación del valor aproximado de una cantidad que

 Si el proceso es mayor a 1.0 se presenta una deseconomía de escala de desarrollo de

 Tamaño del producto, desempeño y calidad

 Esfuerzo del proyecto, costo y calendario

 Capacidad y desempeño de proceso

 Un sistema con precedentes cumple con los

 Las estimaciones en general se ven afectadas por tres factores: Omisiones,

 La incertidumbre es un error probable

 ¿Qué modelo de estimación conviene usar?

Requerimientos Definir el proyecto

CRITERIOS PARA LOGRAR “BUENAS” ESTIMACIONES

 Relevancia: Características de interés

 Cualquier medida o conjunto de medidas destinadas a conocer o

 Ofrece la posibilidad de estimar las horas-hombre de un proyecto de software que requiere de

 UAW (Unadjusted Actors Weights): Pesos de los Actores sin Ajustar

 TCF (Technical Complexity Factor): Factor de Complejidad Técnica

Categoría de Caso de Uso Descripción Peso (factor)

UUCW= ∑(Cantidad de cada tipo de caso de uso * Peso)

Tipo de Actor Descripción Peso (factor)

UAW= ∑(Cantidad de cada tipo de actor * Peso)

Factor Descripción Peso

 Considerar que se trata de un proyecto nuevo

 Para la estimación del tamaño utiliza tres opciones:

Para Pantallas Para Informes

Tipo de elemento Simple Medio Complejo

Experiencia Muy baja Baja Nominal Alta Muy Alta

1. Estimar el número de pantallas, reportes y componentes 3GL que componen la aplicación.

 Suponer un sistema para un cajero automático:

 Considerar que se trata de un proyecto nuevo

 Damos una clasificación a cada instancia de objeto:

 Damos una clasificación a cada instancia de objeto:

 Ponderar la cantidad de puntos de cada instancia

 Estimar reutilización (en este caso es 0)

 Calcular la cantidad esperada de esfuerzo:

1. Determinar la cantidad de cada uno de los cinco tipos de función y clasificarlos

Para ILF y EIF Para EO y EQ Para EI

Lenguaje SLOC/UF SLOC/UF Lenguaje SLOC/UF SLOC/UF Lenguaje SLOC/UF SLOC/UF

Lenguaje SLOC/UF SLOC/UF Lenguaje SLOC/UF SLOC/UF Lenguaje SLOC/UF SLOC/UF

Nivel del Productividad Promedio Por Persona por Mes

PCAP: Percentil Percentil Percentil Percentil Percentil

Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto

Bajo Nominal Alto Muy Alto Extra

Muy Bajo Bajo Nominal Alto Muy Alto

Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto

 Un Punto de Función se define como una función comercial de usuario final.

 Cantidad de esfuerzo en personas por mes para un programa nominal

 Cantidad de tiempo nominal para desarrollar el producto

 En el 2000 los valores para:

 Explique como se hace el cálculo de Puntos de Función y el Esfuerzo

 Explique que métricas se han creado para apoyar la medición de

Potrebbero piacerti anche