1. 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

2. 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

3. 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

4. ANTECEDENTES
Tecnología Multicapa:
HERRAMIENTAS
MÉTODOS
PROCESO
UN ENFOQUE DE CALIDAD
SIGUIENTE

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 3. Métricas Aplicadas a la
Gestión de Proyectos
s
to
isi
qu
Re
o
añ
m
rzo
Ta
e
fu po
Es
Tiem os
esg
Ri

14. LÍNEA BASE EN LA GESTIÓN
•ÁMBITO DEL PROYECTO
•TAMAÑO
•ESFUERZO
•EQUIPO DE TRABAJO
•TIEMPO
•HERRAMIENTAS
•RIGOR
•RIEGOS
SIGUIENTE

15. 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

16. .....
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

17. ....
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

18. 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

19. ... 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

20. 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

21. ... clases clave
Datos •Requerimientos del cliente
requeridos:
•Diagrama de clases
El número de CC depende directamente de las
Cálculo:
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

22. 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

23. ... 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

24. 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

25. ... clases totales
Datos
•CC
requeridos:
•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

26. 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

27. ... 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

28. 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

29. ... 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

30. 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

31. 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

32. 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
PREX
cada mes s
FACTOR DE ESCALA
Experiencia en 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

33. 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

34. 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

35. ... 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

36. 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

37. ... 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

38. 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

39. ... 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

40. 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

41. 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

42. ... 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

43. 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

44. ... 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

45. 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

46. ..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

47. 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

48. ... 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

49. 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

50. ... 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

51. 4. CASO DE ESTUDIO
ER
LL
SE
SIGUIENTE

52. 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

53. ... 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

54. 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

55. 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

56. ... 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

57. 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

58. 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

59. ... 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

60. 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

61. 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

62. 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

63. 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

64. 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

65. 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