S.E.P.               S.N.E.S.T           D.G.E.S.T.

INSTITUTO TECNOLÓGICO DE MORELIA
DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN

“Métricas para la Gestión de

Proyectos de Software”

Presenta:

M .C. Esperanza Aguillón Robles

 CONTENIDO
1. La Industria del Software

3. La medición y las métricas

5. Métricas aplicadas a la Gestión de Proyectos

7. Caso de Estudio

9. Conclusiones
SIGUIENTE
 ANTECEDENTES

Ingeniería de Software: La aplicación de un enfoque

sistemático, disciplinado y cuantificable hacia el
desarrollo, operación y mantenimiento de software.
[IEEE, 1993]

SIGUIENTE
 ANTECEDENTES
Tecnología Multicapa:

HERRAMIENTAS

MÉTODOS

PROCESO

UN ENFOQUE DE CALIDAD

SIGUIENTE
1. LA INDUSTRIA DEL SOFTWARE

TIPO DE NUMERO DE NÚMERO DE PORCENTAJE

EMPRESA EMPLEADOS EMPRESAS

MICRO 1 a 10 619 41%

PEQUEÑA 11 a 50 629 42%

MEDIANA 51 a 100 130 9%

GRANDE Más de 100 114 8%

SIGUIENTE
LA INDUSTRIA DEL SOFTWARE…
Tipo de Número de Número de Número de
Empresa organizaciones empleados de Empleados
sistemas

Departamentos 12,521 10 máximo

internos de
software
Dedicadas al 759 De 11 a 25 De 57 a
Desarrollo de
Software
100

•Administradores sin experiencia en obtención de productos de

calidad
•Proyectos entregados fuera de tiempo ¿
GESTIÓN?
•Desorganización en las empresas
•No tienen visión cuantitativa
•Procesos inmaduros SIGUIENTE
 GESTIÓN DE PROYECTOS

Marco Común
Planificación
Medición Estimación

Análisis y control de
Gestión de Recursos
riegos
Planificación temporal Seguimiento del Progreso
y control
Gestión de Riesgos

SIGUIENTE
2. MEDICIÓN DEL SOFTWARE
Es el proceso por el cual se asignan números o símbolos a
atributos de entidades del mundo real de tal manera que describa
dichos atributos de una forma significativa de acuerdo a las
reglas claramente definidas.

?
PARA:

¿ Para que me sirve la medición

 CARACTERIZAR

 EVALUAR

 PREDECIR

 MEJORAR

SIGUIENTE
MÉTRICAS
“Una métrica software es una correspondencia entre uno o más
atributos del entorno de desarrollo del software, y cualquier otro
atributo” [Fenton,1997].

Proceso de Ing.
Recopilación de
de Software datos
Medidas
Cálculo de
Proyecto de métricas
Software Métricas
Evaluación de
Producto de
métricas
Software
Indicadores

SIGUIENTE
CLASIFICACIÓN DE LAS MÉTRICAS

ENTIDADES DE •Directas o indirectas

SOFTWARE •Internas y Externas

•Entregables •Complejas o sencillas

•Publicas o privadas
•Actividades ATRIBUTOS
•Esfuerzo o tiempo
•Personas
•Longitud de un programa
•Recursos •Experiencia del equipo de
Materiales trabajo

Financieros •Consumo de papel y cinta

•Estado del presupuesto

SIGUIENTE
CARACTERÍSTICAS DE LAS MÉTRICAS

 Unidades de medición
 Escalas de medición
 Simples y fáciles de calcular
 Empírica e intuitivamente persuasivas
 Consistentes y objetivas
 Independiente del lenguaje de programación
 Un eficaz mecanismo para la realimentación de
la calidad
SIGUIENTE
CÓMO DEFINIR MÉTRICAS PROPIAS

?
PROCESO
• Identificar las métricas
• Especificar las métricas
•Especificar la recolección de
datos
• Realizar un prototipo
• Recolectar los datos y
calcular los valores de las
métricas
• Analizar e implementar los
resultados obtenidos
• Validar las métricas SIGUIENTE
 3. Métricas Aplicadas a la
Gestión de Proyectos
s
to
isi
qu
Re

o
añ
m

zo
Ta

er
fu o
Es em
p
s
Ti o
sg
e
Ri
LÍNEA BASE EN LA GESTIÓN

•ÁMBITO DEL PROYECTO

•TAMAÑO
•ESFUERZO
•EQUIPO DE TRABAJO
•TIEMPO
•HERRAMIENTAS
•RIGOR
•RIEGOS
SIGUIENTE
METRICAS APLICADAS A LA GPOO

REQUISITOS
VALIDACION DE REQ (VR)

TAMAÑO DE LA APLICACION

CLASES CLAVE (CC)

CLASES SOPORTE (CS)

CLASES TOTALES (CT)

CIENTOS DE INSTRUCCINES FUENTE (CIF)

SIGUIENTE
 .....
ESTIMACIÓN DE ESFUERZO

ESFUERZO DEL PROYECTO

ESFUERZO CON REUTILIZACIÓN

PERSONAL

TAMAÑO DEL E. T.

EXPERTOS PARA EL AREA

EXPERIENCIA COMO E. T.

SIGUIENTE
 ....
MÉTODOS Y HERRAMIENTAS

METODOS Y HERRAM.

TIEMPO

PERSONAS-DIA-CLASE.

GRADO DEL RIGOR DEL PROYECTO

RIGOR DEL PROYECTO

CONTROL DE CAMBIOS

IMPACTO DE RIESGO

SIGUIENTE
 Métrica: “ Validación de Requisitos”

✔ OBJETIVOS: Examinar y asegurar que los requisitos

propuestos por el cliente han sido
establecidos sin ambigüedad, sin
inconsistencia, sin omisiones.

✔ VALOR
OBJETIVO A Obtener un número de requerimientos
faltantes en el diagrama de clases.
ALCANZAR:
✔
¿Los requerimientos han sido cubiertos
INTERROGAN- en el diagrama de clases?
TE QUE
RESUELVE:

SIGUIENTE
 ... validación de requisitos
Datos
✔ requeridos: •Requerimientos del cliente
•Diagrama de clases
✔ Cálculo: Clases
Clase1 Clase2 ... Clase n
Requisito
R1 √

R2 √

...

Rn √
✔ Sugerencias

¿Cuantas veces Como 20,

aplicaste la nada más !!!!
métrica? REGRESAR
 TAMAÑO DE LA APLICACIÓN

Métrica: “ Clases Clave (CC)”

✔ OBJETIVOS: Indicar el volumen de trabajo
necesario, cantidad de clases
principales

Obtener un número de clases clave,

✔ VALOR
OBJETIVO A
que representan el dominio del
proyecto a desarrollar.
ALCANZAR:
✔
¿Cuántas clases dominan sistema a
INTERROGAN- desarrollar ?
TE QUE
RESUELVE: SIGUIENTE
 ... clases clave
Datos •Requerimientos del cliente
✔ requeridos:
•Diagrama de clases

✔ Cálculo: El número de CC depende directamente de las

clases identificadas y consideradas de vital
importancia para el cliente.

¿Se puede desarrollar la aplicación en este

✔ Interrogantes:
dominio sin esta clase?
¿El cliente puede considerar este objeto
importante?
¿El diagrama de clases incluye esta clase?

REGRESAR
 Métrica: “ Clases Soporte (CS)”

✔ OBJETIVOS: Identificar las clases que no son

indispensables para el dominio del
problema, pero proporcionan
funcionalidades valiosas para CC y las
complementa.

✔ VALOR Obtener un número de clases

OBJETIVO A secundarias para el cálculo del tamaño
del proyecto, tomando en cuenta la
ALCANZAR: interfaz de las clases.
✔
INTERROGAN-
¿Cuántas son las clases secundarias?
TE QUE
RESUELVE:

SIGUIENTE
 ... clases soporte

Datos
✔ requeridos: •CC
•Tipo de interfaz
✔ Cálculo:
•Sin interfaz _______________2.0
•Simple basada en texto ______ 2.25
•Interfaz Gráfica ________________ 2.50
•Interfaz Compleja_______________3.00

CS = CC x FIU

REGRESAR
 Métrica:“ Clases Totales (CT)”

✔ OBJETIVOS: Realizar una estimación del tamaño de

una aplicación al inicio de un proyecto.

✔ VALOR Obtener un dato cuantitativo del

OBJETIVO A tamaño total del proyecto
ALCANZAR:
✔ ¿cuál es el tamaño total del proyecto?
INTERROGAN-
TE QUE
RESUELVE:

SIGUIENTE
 ... clases totales

Datos
✔ requeridos: •CC
•CS
✔ Cálculo:

CT=CS+CC

✔ Sugerencias Proyectos con una importante gestión de interfaz

de usuario, conllevan de dos a tres veces el número
de clases clave para las clases soporte
Proyectos con una gestión mas sencilla de interfaz
de usuario implica una o dos veces el número de
clases clave para las clases soporte

REGRESAR
Métrica:“ Cientos de Instrucciones Fuente
(CIF)”

✔ OBJETIVOS: Convertir el número de clases totales

en un número de instrucciones fuente,
que nos indica un 30% de reducción del
código fuente.

✔ VALOR
OBJETIVO A Calcular el tamaño del proyecto en
base a instrucciones fuente.
ALCANZAR:
✔
¿ cuál es el tamaño del proyecto en
INTERROGAN- base instrucciones fuente?
TE QUE
RESUELVE:

SIGUIENTE
 ... Cientos de instrucciones fuente

Datos
✔ requeridos: •Número de clases totales

✔ Cálculo:
CIF = F/100

Para convertir el total de las clases a

✔ Sugerencias desarrollar en cientos de instrucciones nos puede
ayudar a obtener una comparación con otros
proyectos que se hayan medido con la misma base

REGRESAR
 Métrica: “ Esfuerzo del proyecto”

✔ OBJETIVOS: Examinar los factores de esfuerzo

para cuantificar el esfuerzo empleado
para el desarrollo.

✔ VALOR Obtener un valor numérico de

OBJETIVO A personas-mes necesarios para el
desarrollo de un proyecto en
ALCANZAR: particular.
✔
INTERROGAN- ¿En cuanto esfuerzo necesito para el
TE QUE
desarrollo del proyecto?
RESUELVE:

SIGUIENTE
 ... esfuerzo del proyecto
Datos • CIF
✔ requeridos:
✔ Cálculo:
EsfReal (mes-hombre)= EsfNom x FEC
B
EsfNom= 2.94 x CIF

B = 1.01 + 0.01 * Σ Wi Factores

FEC = PERS x RUSE x PDIF x PREX x SCED x FCIL

Factores

✔ Sugerencias

COCOMO dijo
que esto es lo
mejor !! REGRESAR
 Nomina Extra
Muy Bajo Muy
Wi CONSIDERACIONES l Alto (2) alto
Bajo (5) (4) Alto (1)
(3) (0)
• Objetivos del producto y
comprensión organizacional
• Exigencia trabajando con
sistemas de software
relacionados Absoluta-
PREC • Desarrollo concurrente Completa Completa Algo Familiar Muy Familiar mente
asociando nuevo hardware y Familiar
nuevos procedimientos
operacionales
Necesidad para la innovación en
arquitectura de datos y algoritmos
• Necesidad de que el software se Gene-
Algo Algo de Objetivos
FLEX ajuste a las especificaciones de Riguroso Ocasional
de relajación
ralmente
conformidad Generales
interfaces externas Conforme
• Indica la fortaleza de la
Gene-
arquitectura y métodos de A menudo Mayor- Totalmente
RESL estimación y reducción de
Poco (20%) Algo (40%)
(60%)
ralmente
Mente (90 %) (100 %)
(75%)
riesgos.
Básicament
Algo
e
• Indica la cohesión y madurez Interacción Dificultad Altamente Interacción
TEAM del equipo de trabajo muy difícil de
hay Cooperativa
cooperativa total
interacción
interacción
cooperativa

REGRESAR
 FACTORES CONSIDERACIONES MUY BAJO NOMINAL ALTO MUY VALORES
BAJO ALTO
Capacidad Se considera la
de los capacidad de análisis
analistas y diseño, eficiencia,
habilidad para 15% 35% 55% 75% 90%
PERS trabajar en equipo.
No se considera el
nivel de experiencia
Capacidad Se considera la
De los capacidad de trabajo
programadores en equipo, eficiencia
y habilidad para 15% 35% 55% 75% 90%
comunicarse. No se
considera el nivel de
experiencia
Continuidad Expresa el porcentaje
del personal de rotación anual del 48% 24% 12% 6% 3%
(al año) personal afectado al al año al año al año al año al año
proyecto
FACTOR DE ESCALA

Reusabilidad Identificar elemento a Por Por múltiples

Reusar Por línea líneas de
Por
RUSE
Nada proye de producto
programa
cto product
o
FACTOR DE ESCALA
SIGUIENTE
PDIF FACTORES CONSIDERACIONES MUY
BAJO
BAJO NOMIN
AL
ALTO MUY
ALTO
VALO
RES
Restricciones Se expresa en términos de <= 50% 70% 85% 95%
de tiempo de porcentaje de de uso
ejecución disponibilidad de tiempo de de los
ejecución que será usado recursos
por el sistema contra los disponibl
recursos disponibles es

Volatilidad de Cambios Mayores Mayores : Mayores :

plataforma Expresa la velocidad de mayores :6 2 meses, 2
cambio del hardware y cada 12 meses, menores: semanas,
software usados como meses y menore 1 semanas menores:
plataforma cambios s: 2 2 días
menores semana

PREXExperiencia en
cada mes s
FACTOR DE ESCALA
Contempla el nivel de experiencia
2 6 1 2
aplicaciones del grupo de desarrollo (analistas) 6 años
meses meses año años
en aplicaciones equivalentes
Experiencia en Refleja la experiencia del grupo
la plataforma de desarrollo (programadores) en
2 6 1 2
el uso de las herramientas de 6 años
meses meses año años
software y hardware utilizado
como plataforma
Experiencia en Refleja la experiencia del grupo
el lenguaje y de desarrolladores en el lenguaje
6 1 2
herramientas de de programación y las 2 meses 6 años
meses año años
desarrollo herramientas de desarrollo
utilizadas
FACTOR DE ESCALA

SIGUIENTE
SCEDFACTOR CONSIDERACION MUY BAJO NOMINAL ALTO MUY VALORES
ES BAJO ALTO
Calendario Restricciones
de impuestas al grupo de
75% del
desarrollo desarrolladores sobre nominal 85 % 100% 130% 160%
la agenda nominal
estimada del proyecto

FCILUso de Contempla el uso de Edición con CASE

FACTOR DE ESCALA
Herramientas Potentes
potentes y
herramientas herramientas desde la programas simple y básicas para herramient
preactivas,
de software edición hasta de texto de poca todo el ciclo as a hacer
muy bien
el manejo de todo integraci de vida con usadas en
integradas
el ciclo de vida ón moderada todo el con el
integración ciclo de
proceso,
vida con los
integración
métodos y
moderada la
reusabilida
d
Desarrollo en Involucra la ubicación Algo de Fax, Red de Comunicac Multimedia
múltiples física y el soporte de teléfono y teléfonos correo iones
ubicaciones comunicaciones mail individual electrónico electrónica
es interno s que
cubren
todas las
ubicacione
s
FACTOR DE ESCALA

REGRESAR
 Métrica: “Esfuerzo con Reutilización”

✔ OBJETIVOS: Reducir la estimación de esfuerzo

utilizando reutilización.

✔ VALOR Obtener el esfuerzo real usando

OBJETIVO A reutilización de clases
ALCANZAR:
✔ ¿Y si tengo reutilización de clases,
INTERROGAN- cual es mi esfuerzo real ?
TE QUE
RESUELVE:

SIGUIENTE
 ... esfuerzo con reutilización

Datos
✔ requeridos: •Esfuerzo real
•Porcentaje de reutilización
✔ Cálculo:

Esfuerzo con Reutilización = EsfReal x (100 - %r)

100

✔ Sugerencias
Tengo un proyecto
igualito !!

REGRESAR
Métrica: “ Tamaño del Equipo de Trabajo”

✔ OBJETIVOS: Medir el tamaño del equipo de trabajo

para predecir el número de elementos
necesarios para el desarrollo del
proyecto.

✔ VALOR
OBJETIVO A Cantidad de hombres necesarios para
el desarrollar un proyecto orientado a
ALCANZAR: objetos
✔
INTERROGAN- ¿cuanta gente se requiere para la
TE QUE
elaboración del proyecto?
RESUELVE:

SIGUIENTE
 ... tamaño del equipo de trabajo
Datos
✔ requeridos: •Clases Totales
•Número de clases promedio de
personas por clase
✔ Cálculo:

Cantidad de Hombres = Total Clases /

Promedio de las clase por persona

✔ Sugerencias

QUE EXIGENTES
LORENZ Y KIDD !!
REGRESAR
Métrica: “Expertos para el Área”

Identificar si la persona es la
✔ OBJETIVOS:
indicada para el área.

El nivel de eficiencia por cada

integrante
✔ VALOR
OBJETIVO A El nivel de eficiencia del Equipo de
Trabajo
ALCANZAR:
✔
¿El trabajo asignado para .... es el
INTERROGAN- adecuado ?
TE QUE
RESUELVE:

SIGUIENTE
 ... expertos para el área
✔ Cálculo:
• Definir criterios de adaptación por participante
• Asignación de peso peso= Núm. Aptitudes/100
1. Valor que el participante aporta por cada actividad
Muy bajo = 0 Sin aptitud
Bajo = 2 Algo de Relación
FORMATO
Nominal = 5 Capaz de aplicarlo, pero no enfatiza
Alto = 8 Altamente Cooperativo
Muy alto = 10 Totalmente aplicable (conocimientos)
• Por aptitud Nivel de Eficiencia = (PESO X GRADO) /10
• Por participante NEParticipante = ∑ NEfic
• Por equipo NEEquiT= ∑ NEPart/ No. de participantes

REGRESAR
PARTICIPANTE ACTIVIDAD PESO Grado NEfic
Motivación para el equipo
técnico
Habilidad para amoldar
procesos existentes
Resolución de problemas
Control de gestión
Director del proyecto
Control mediante métricas
OO
Proporciona incentivos para
el reuso
Planificación
Subtotal
Posee los contratos del
subsistema
Arquitectos Conoce las clases llaves del
proyecto
Subtotal
Dominio acerca de la
industria
Expertos al dominio Proveedor de la clasificación
del problema de los requerimientos y la
terminología
Subtotal

Nivel de eficiencia por equipo de

trabajo:

REGRESAR
 Métrica: “Experiencia del Equipo de
Trabajo”

✔ OBJETIVOS: Asegurar que los integrantes del

equipo de trabajo elaborar
eficientemente de manera conjunta.

✔ VALOR
OBJETIVO A El nivel de experiencia como Equipo de
Trabajo
ALCANZAR:
✔
INTERROGAN-
¿El equipo de trabajo estimado que
TE QUE nivel de experiencia tiene ?
RESUELVE:

SIGUIENTE
 ... experiencia del equipo de trabajo
Datos •Comparativas de eficiencia en el proyecto
✔ requeridos:
•Comparativas de comportamiento humano

✔ Cálculo: D1 D2 Valor Escala Comentario

Valor = D1 – D2 PRea PCon

PCon PMar
Valor = 0 Excelente
Valor < D1 / 2 Bueno PCon Ptie

Valor = D1 /2 Medio PMar Preq

Valor > D1 / 2 Malo EE ES

PI PD
PC PsC
✔ Sugerencias

REGRESAR
 métrica
“ Métodos y Herramientas”

✔ OBJETIVOS: Identificar si las herramientas y

métodos son indispensables para el
desarrollo del proyecto.

✔ VALOR Obtener un número que nos indique el

OBJETIVO A nivel de importancia de las
Herramientas y Métodos sobre el
ALCANZAR: proyecto
✔ ¿Qué tan indispensables el uso de
INTERROGAN- Herramientas y Métodos para
TE QUE desarrollo ... ?
RESUELVE:

SIGUIENTE
 ... métodos y herramientas
✔ Cálculo:

ESCALA DESCRIPCION
0 No se usan herramientas
1 Sirven de ayuda en el 20 % de la documentación

2 Para documentar el menos del 50% del diseño

de alto nivel
3 Para documentar al menos 50% del diseño de
alto nivel y diseño detallado
4 Para el diseño y a generación automática de
código de la menos el 50% del sistema
5 Para el diseño y la generación automática de
código de al menos el 90% del sistema
REGRESAR
Métrica: “Personas-Día-Clase”

✔ OBJETIVOS: Determinar un número promedio de los

días de esfuerzo necesario para una
clase y así obtener un dato estimado
del tiempo de desarrollo del proyecto

✔ VALOR
OBJETIVO A El tiempo aproximado para desarrollar
un proyecto OO.
ALCANZAR:
✔
¿El tiempo establecido por el cliente
INTERROGAN- es el adecuado ?
TE QUE
RESUELVE: ¿cuánto tiempo me llevará desarrollar
el proyecto?
SIGUIENTE
 ..personas-Día-Clase

Datos •10 a 15 días para una clase en producción,

✔ requeridos: es decir, incluyendo documentación y
pruebas de las clases
✔ Cálculo: •6 a 8 días para desarrollar un prototipo
que contiene una clase, sin tener en cuenta
la integracion y las pruebas formales de la
clase

TDes (días) = (CT * Día-Clase) / EsfReal

REGRESAR
Métrica: “Rigor del Proyecto”

✔ OBJETIVOS: Establecer el nivel de exigencia con el

que será tratado el proceso de
desarrollo del proyecto, definiendo
criterios de adaptación recomendable
para POO.
✔ VALOR
OBJETIVO A
Nivel de rigor
ALCANZAR:
✔
¿qué tan exigente es el proyecto?
INTERROGAN-
TE QUE
RESUELVE:

SIGUIENTE
 ... rigor del proyecto
Datos • Definir criterios de adaptación por participante
✔ requeridos:
• Asignación de grados de 1 (pequeño subconjunto de
tareas) hasta 5 (conjunto completo de tareas,
✔ Cálculo: metodologías y documentación)

• El Peso es asignado como indicador de la relativa

importancia a cada criterio va desde 0.8 a 1.2

• Multiplicador de entrada 1 o 0
• PRODUCTO = Grado x Peso x ME

• n
VRigor = ∑productos / No de criterios
i

✔ Sugerencias: VRigor < 1.2 Casual

1.0 < VRigor> 3.0 Estructurado
VRigor > 2.4 Estricto REGRESAR
Métrica: “Impacto de riesgo”
✔ OBJETIVOS: Medir el nivel de probabilidad de un
proyecto sea riesgoso, además de
identificar los tipos de riesgo que se
pueden presentar.
✔ VALOR
OBJETIVO A
Nivel de riesgo del proyecto.
ALCANZAR:
✔
¿se pueden presentar riegos durante el
INTERROGAN-
desarrollo del proyecto? ¿A qué nivel?
TE QUE
RESUELVE:

Riesgos, el grado de incertidumbre que

✔
DATOS mantendrá el presupuesto, el grado de
REQUERIDOS : incertidumbre de pacilidad para corregirse
SIGUIENTE
 ... impacto de riesgo
✔ Cálculo:
RIESGOS PROBAB. IMPACTO
La estimación del tamaño fue erróneo
Catastrófico 1
Mayor número de usuarios de los previstos
num. Riesgo = ∑Impacto
Menos reutilización de la prevista
Critico 2 Los usuarios finales se resisten al sistema
∑Impacto <= num. Riesgo *2 La fecha de entrega estará muy ajustada
Marginal 3 Se perderán los presupuestos
∑Impacto <= num. riesgo *3 El cliente cambiara los requisitos

Despreciable 4 La tecnología no alcanzará las expectativas

Falta de formación en las herramientas
∑Impacto <= num. riesgo *4
Personal sin experiencia
Cambios de personal
Total de Riesgo sobre el Proyecto

REGRESAR
4. CASO DE ESTUDIO

ER
LL
SE

SIGUIENTE
Métricas aplicadas a SELLER
CLASES CLAVE CC = 28 clases
Clases que representan el 100% del dominio del
problema, identificadas por los analistas

VALIDACION DE Todos los requerimientos han sido

REQUERIMIENTOS cubiertos en las clases, en un solo
nivel de abstracción.

CC INTERFAZ CS CT CIF
TAMAÑO DEL
PROYECTO EN
BASE A CLASES 28 GRÁFICA (2.5) 70 98 .98

SIGUIENTE
 ... métricas aplicadas a SELLER
ESFUERZO cálculo

CIF B EsfNom FEC EsReal

.98 1.08 3.11 1.54 4.78
Esfuerzo Real = 5 Hombres

TIEMPO
TDes= (98 clases totales * 12 días-clase)
7 personas

TDes = 168 días = 8.4 meses
(incluyendo documentación y prueba)

SIGUIENTE
 Wi CONSIDERACIONES PONDERACIÓN VALOR

PREC • El sistema es muy familiar Muy Alto 1

• Algo de relajación en cuanto a flexibilidad del

FLEX Nominal 3
desarrollo
• La arquitectura es sólida y los riesgos
RESL Alto 2
generalmente se mitigan
• La interacción del equipo es altamente
TEAM Muy alto 1
cooperativa
B 1.08
3.11
EsfNom
mes hombre
EsfNom= 2.94 x (.98) 1.08

B = 1.01 + 0.01 * 7

EsfReal = 3.11 x 1.54

FEC

FEC = 1.13 x 1.03 x 1.08 x 1.14 x 1.03 x 1.05 REGRESAR

 MULTI-
FACTORES PONDERACIÓN VALORES FACTOR ESCALA
PLICADOR

Capacidad de los analistas MUY ALTO 5

PERS Capacidad de los
NOMINAL 3 1.13
programadores
Continuidad del personal (al
ALTO 4
año)
RUSE Reusabilidad BAJO 2 1.03
Restricciones de tiempo de
MUY ALTO 5
PDIF ejecución 1.08
Volatilidad de plataforma BAJO 2
Experiencia en aplicaciones ALTO 4
PREX Experiencia en la plataforma MUY ALTO 5 1.14
Experiencia en el lenguaje y
ALTO 4
herramientas de desarrollo
SCED Calendario de desarrollo BAJO 2 1.03
Uso de herramientas
NOMINAL 3
de software
FCIL 1.05
Desarrollo en múltiples
MUY BAJO 1
ubicaciones

FACTOR DE ESCALA = ∑VALOR /100 +1.01 REGRESAR

 ... métricas aplicadas a SELLER
EXPERTOS EficET = 55.24% cálculo
PARA
Rango NOMINAL de eficiencia, se detectaron
EL ÁREA deficiencias en las actividades para desarrollar un
POO.

EXPERIENCIA ExpET = 44% cálculo

COMO
EQUIPO DE Rango MEDIO, laboran eficientemente, cumplen con
TRABAJO los requerimientos del cliente, a tiempo paro sin
factores de calidad.

MÉTODOS Y MyH = 3%
HERRAMIENTAS
Rango NOMINAL, uso de herramientas solo en la
fase de diseño
SIGUIENTE
 PARTICIPANTES ACTIVIDAD PESO Grado NEfic
Motivación para el equipo técnico 14.28 8 11.42
Habilidad para amoldar procesos existentes 14.28 8 11.42
Resolución de problemas 14.28 8 11.42
Control de gestión 14.28 8 11.42
Director del
Control mediante métricas OO 14.28 0 0
proyecto
Proporcionar incentivos para el reuso 14.28 5 7.14
Planificación 14.28 8 11.42
Subtotal 64.24
%
Posee los contratos del subsistema 30 8 24
Arquitectos Conoce las clases llaves del proyecto 70 8 56
Subtotal 80 %
Expertos al Dominio acerca de la industria 50 5 25
dominio Proveedor de la clasificación de los requerimientos y la terminología 50 5 25
del problema Subtotal 50 %
Aportan las experiencias prácticas de la tecnología orientada a objeto para el
35 5 17.5
Guías del proyecto
enfoque Capaces de cambiar el paradigma 30 8 24
Orientado a Adiestran al núcleo del equipo. 35 8 28
Objetos Subtotal 69.5
%
Diseñadores de la llave del modelo de clases 50 5 25
Desarrolladores
Trabajan desde la biblioteca de reuso 50 5 25
De clases
Subtotal 50 %
Construyen la aplicación a partir de bloques reusables 60 5 30
Desarrolladores Escriben relativamente un pequeño porcentaje del nuevo código para
40 2 8
de la aplicación especializar y completar la aplicación
Subtotal 38 %
Interactúan a lo largo del desarrollo 25 8 20
Organizan las pruebas de función del software basadas en los guiones 25 2 5
Escriben ayudas en línea y parte de los manuales de cómo el sistema es
Probadores 25 2 5
construido
Proporcionan los resultados de la prueba de usabilidad durante el análisis 25 5 5
Subtotal 35 %
REGRESAR
Nivel de eficiencia por equipo de trabajo: 55.24
 VARIABLES D1 D2 Valor Escala COMENTARIO
De 2 proyectos realizados, solo 1
PRea PCon 2 1 1 MEDIO fue concluido debido a la mala
planeación.
Los concluidos fueron puestos en
PCon PMar 1 1 0 EXCELENTE
marcha
No fue entregado debido a la mala
PCon Ptie 1 0 1 MALO
planeación
Todos han cumplido los
PMar Preq 1 1 0 EXCELENTE
requerimientos del cliente
PReq Pcal 1 0 1 MALO No se tomaron en cuenta los
factores de la calidad, solo cubre
PCon Pcal 1 0 1 MALO un 40 % de calidad.
De los dos proyectos entregados
solo 15 de 20 errores han sido
EE ES 20 15 5 BUENO
solucionados, debido a no tener los
recursos disponibles
3 de los programadores no aportan
PI PD 5 3 2 BUENO iniciativas, dependen del jefe de
proyecto.
Se confía plenamente en el
PC PsC 5 5 1 BUENO
personal
REGRESAR
 ... métricas aplicadas a SELLER

RIGOR cálculo

RIGOR = 2.9
Grado de Rigor ESTRICTO, esto es, aplicar el
proceso completo para el proyecto con un grado de
disciplina tal que garantice una alta calidad

cálculo
RIESGOS

RIESGO = 23
Dejar de cumplir alguno de los requisitos provocaría la
degradación de la misión, pero además de los riesgos
lo planeado todavía puede ser alcanzable.

SIGUIENTE
 CRITERIOS GRADO PESO MULTIPLICADOR PRODUCTO
DE ADAPTACIÓN DE ENTRADA
Tamaño del proyecto 2 1.2 1 2.4
Número de usuarios 3 1.1 1 3.3
Importancia para el negocio 4 1.1 1 4.4
Estabilidad de los requisitos 2 0.9 1 1.8
Enfoque orientado a objetos 3 1.2 1 3.6
Facilidad de comunicación 3 0.9 1 2.7
Madurez de tecnología 3 0.9 1 2.7
Limitaciones de rendimiento 3 0.8 1 2.4
Personal del proyecto 2 1.0 1 2.0
Interoperabilidad 4 1.1 1 4.4
Factores de Reuso 2 1.2 1 2.4
Valor de rigor 2.9

REGRESAR
 RIESGOS PROBABILIDAD IMPACTO
La estimación del tamaño depende ser
60% 2
significativamente baja
Mayor número de usuarios de los previstos 30% 3
Menos reutilización de la prevista 70% 2
Los usuarios finales se resisten al sistema 40% 3
La fecha de entrega estará muy ajustada 50% 2
Se perderán los presupuestos 40% 1
El cliente cambiara los requisitos 80% 2
La tecnología no alcanzará las expectativas 30% 1
Falta de formación en las herramientas 80% 3
Personal sin experiencia 30% 2
Total de riesgo
23
sobre proyecto
REGRESAR
VALIDACION DE LA GESTIÓN “SELLER”
Estructuración al inicio del proyecto.
Se encontró la dimensión del proyecto.
Uso de herramientas.
Subestimación del personal, 2 personas de más.
Tiempo de desarrollo sobrepasó el tiempo de entrega
identificando la falta de la Gestión de Riesgos.
Al personal:
Técnicas de reuso de SW
Desarrollo de componentes reusables
Técnicas de modelado
Esquemas estrictos de calidad
Se identificó el Rigor del proyecto. REGRESAR
 RIESGOS PROBABILIDAD IMPACTO
La estimación del tamaño depende ser significativamente
30% 2
baja
Mayor número de usuarios de los previstos 10% 2
Menos reutilización de la prevista 0% 0
Los usuarios finales se resisten al sistema 20% 1
La fecha de entrega estará muy ajustada 70% 1
Se perderán los presupuestos 30% 3
El cliente cambiara los requisitos 20% 2
La tecnología no alcanzará las expectativas 50% 3
Falta de formación en las herramientas 80% 3
Personal sin experiencia 20% 2
Total de riesgo
19
sobre proyecto

REGRESAR
 5. CONCLUSIONES
• No son las métrica perfectas, pero si son un indicador para cuantificar
cualquier actividad dentro de la Ingeniería de Software.

• Indicador de Madurez del Gestor y de la Empresa.

• Se da pie a nuevos procesos de medición aplicables a cualquier

actividad dentro de la Ingeniería de software.

• Crear procesos de medición propios, basándose en las necesidades de

cada organización.

• Crear una Pyme de software haciendo uso de MOPROSOFT.

SIGUIENTE
 S.E.P.               S.N.E.S.T           D.G.E.S.T.

INSTITUTO TECNOLÓGICO DE MORELIA
DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN

GRACIAS POR SU ATENCION

M .C. Esperanza Aguillón Robles
aguillon@ itmorelia.edu.mx

peraguillon@ gmail.com