Metricas

“Métricas para la Gestión de Proyectos de Software”

Presenta:

M.C. Esperanza Aguillón Robles

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

INSTITUTO TECNOLÓGICO DE MORELIADEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN

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

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]

ANTECEDENTES

SIGUIENTE

Tecnología Multicapa:

ANTECEDENTES

SIGUIENTE

HERRAMIENTAS

MÉTODOS

PROCESO

UN ENFOQUE DE CALIDAD

1. LA INDUSTRIA DEL SOFTWARE

SIGUIENTE

8%114Más de 100GRANDE

9%13051 a 100MEDIANA

42%62911 a 50PEQUEÑA

41%6191 a 10MICRO

PORCENTAJENÚMERO DE EMPRESAS

NUMERO DE EMPLEADOS

TIPO DE EMPRESA

•Administradores sin experiencia en obtención de productos de calidad

•Proyectos entregados fuera de tiempo

•Desorganización en las empresas

•No tienen visión cuantitativa

•Procesos inmaduros

LA INDUSTRIA DEL SOFTWARE…

SIGUIENTE

¿ GESTIÓN?

De 57 a 100

De 11 a 25759Dedicadas al Desarrollo de

Software

10 máximo12,521Departamentos internos de

software

Número de Empleados

Número de empleados de

sistemas

Número de organizaciones

Tipo de Empresa

GESTIÓN DE PROYECTOS

PlanificaciónMediciónAnálisis y control de riegos Planificación temporal y control

Marco Común

Estimación

Gestión de Recursos

Seguimiento del Progreso

Gestión de Riesgos

SIGUIENTE

2. MEDICIÓN DEL SOFTWAREEs 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 que me sirve la medición?PARA:

CARACTERIZAR

EVALUAR

PREDECIR

MEJORAR

SIGUIENTE

Proceso de Ing. de Software

Proyecto de Software

Producto de Software

Recopilación de datos

Cálculo de métricas

Evaluación de métricas

Medidas

Métricas

Indicadores

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

SIGUIENTE

ATRIBUTOS

•Esfuerzo o tiempo

•Longitud de un programa

•Experiencia del equipo de trabajo

•Consumo de papel y cinta

•Estado del presupuesto

ENTIDADES DE SOFTWARE

•Entregables

•Actividades

•Personas

•Recursos

Materiales

Financieros

CLASIFICACIÓN DE LAS MÉTRICAS

•Directas o indirectas

•Internas y Externas

•Complejas o sencillas

•Publicas o privadas

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étricasSIGUIENTE

3. Métricas Aplicadas a la Gestión de ProyectosTam

añoReq

uisito

s

Esfuerz

o

Tiempo

Riesgos

LÍNEA BASE EN LA GESTIÓN

•ÁMBITO DEL PROYECTO

•TAMAÑO

•ESFUERZO

•EQUIPO DE TRABAJO

•TIEMPO

•HERRAMIENTAS

•RIGOR

•RIEGOS SIGUIENTESIGUIENTE

CLASES SOPORTE (CS)

CLASES CLAVE (CC)

CLASES TOTALES (CT)

CIENTOS DE INSTRUCCINES FUENTE (CIF)

METRICAS APLICADAS A LA GPOO

REQUISITOS

TAMAÑO DE LA APLICACION

VALIDACION DE REQ (VR)

SIGUIENTE

.....

ESFUERZO CON REUTILIZACIÓN

TAMAÑO DEL E. T.

ESTIMACIÓN DE ESFUERZO

PERSONAL

EXPERTOS PARA EL AREA

ESFUERZO DEL PROYECTO

EXPERIENCIA COMO E. T.

SIGUIENTE

PERSONAS-DIA-CLASE.

MÉTODOS Y HERRAMIENTAS

TIEMPO

METODOS Y HERRAM.

GRADO DEL RIGOR DEL PROYECTO

CONTROL DE CAMBIOS

RIGOR DEL PROYECTO

IMPACTO DE RIESGO

....

SIGUIENTE

Métrica: “ Validación de Requisitos”

Examinar y asegurar que los requisitos propuestos por el cliente han sido establecidos sin ambigüedad, sin inconsistencia, sin omisiones.

Obtener un número de requerimientos faltantes en el diagrama de clases.

¿Los requerimientos han sido cubiertos en el diagrama de clases?

OBJETIVOS:

VALOR OBJETIVO A ALCANZAR:

INTERROGAN-TE QUE RESUELVE:

✔

✔

✔

SIGUIENTE

... validación de requisitosDatos requeridos:

Cálculo:

✔

✔

•Requerimientos del cliente

•Diagrama de clases

✔ Sugerencias

REGRESAR

¿Cuantas veces aplicaste la métrica?

Como 20, nada más !!!!

√Rn

...

√R2

√R1

Clase n...Clase2Clase1 Clases

Requisito

SIGUIENTE

Indicar el volumen de trabajo necesario, cantidad de clases principales

Obtener un número de clases clave, que representan el dominio del proyecto a desarrollar.

¿Cuántas clases dominan sistema a desarrollar ?

OBJETIVOS:



✔

✔

✔

TAMAÑO DE LA APLICACIÓN

Métrica: “ Clases Clave (CC)”

Datos requeridos:

Cálculo:

Interrogantes:

✔

✔

✔

•Requerimientos del cliente

•Diagrama de clases

REGRESAR

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 dominio sin esta clase?

¿El cliente puede considerar este objeto importante?

¿El diagrama de clases incluye esta clase?

... clases clave

SIGUIENTE

Identificar las clases que no son indispensables para el dominio del problema, pero proporcionan funcionalidades valiosas para CC y las complementa.

Obtener un número de clases secundarias para el cálculo del tamaño del proyecto, tomando en cuenta la interfaz de las clases.

¿Cuántas son las clases secundarias?

OBJETIVOS:



✔

✔

✔

Métrica: “ Clases Soporte (CS)”

Datos requeridos:

Cálculo:

✔

✔

•CC

•Tipo de interfaz

•Sin interfaz _______________2.0

•Simple basada en texto ______ 2.25

•Interfaz Gráfica ________________ 2.50

•Interfaz Compleja_______________3.00

CS = CC x FIU

... clases soporte

REGRESAR

Métrica:“ Clases Totales (CT)”

SIGUIENTE

Realizar una estimación del tamaño de una aplicación al inicio de un proyecto.

Obtener un dato cuantitativo del tamaño total del proyecto

¿cuál es el tamaño total del proyecto?

OBJETIVOS:



✔

✔

✔

Datos requeridos:

Cálculo:

✔

✔

•CC

•CS

CT=CS+CC

... clases totales

✔ Sugerencias

REGRESAR

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

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

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.

Calcular el tamaño del proyecto en base a instrucciones fuente.

¿ cuál es el tamaño del proyecto en base instrucciones fuente?

OBJETIVOS:



✔

✔

✔

SIGUIENTE

Datos requeridos:

Cálculo:

✔

✔

•Número de clases totales

CIF = F/100

✔ Sugerencias

REGRESAR

... Cientos de instrucciones fuente

Para convertir el total de las clases a desarrollar en cientos de instrucciones nos puede ayudar a obtener una comparación con otros proyectos que se hayan medido con la misma base

Métrica: “ Esfuerzo del proyecto”

Examinar los factores de esfuerzo para cuantificar el esfuerzo empleado para el desarrollo.

Obtener un valor numérico de personas-mes necesarios para el desarrollo de un proyecto en particular.

¿En cuanto esfuerzo necesito para el desarrollo del proyecto?

OBJETIVOS:



✔

✔

✔

SIGUIENTE

Datos requeridos:

Cálculo:

✔

✔

... esfuerzo del proyecto

✔ Sugerencias

REGRESAR

EsfReal (mes-hombre)= EsfNom x FEC

EsfNom= 2.94 x CIF

B = 1.01 + 0.01 * Σ Wi

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

B

• CIF

Factores

Factores

COCOMO dijo que esto es lo mejor !!

Wi CONSIDERACIONES Muy

Bajo (5) Bajo (4)

Nominal

(3) Alto (2)

Muy Alto (1)

Extra alto (0)

PREC

• Objetivos del producto y comprensión organizacional

• Exigencia trabajando con sistemas de software relacionados

• Desarrollo concurrente asociando nuevo hardware y nuevos procedimientos operacionales

Necesidad para la innovación en arquitectura de datos y algoritmos

Completa Completa Algo Familiar Muy Familiar Absoluta-

mente Familiar

FLEX • Necesidad de que el software se

ajuste a las especificaciones de interfaces externas

Riguroso Ocasional Algo

de relajación

Gene-ralmente

Conforme

Algo de conformidad

Objetivos Generales

RESL • Indica la fortaleza de la

arquitectura y métodos de estimación y reducción de riesgos.

Poco (20%) Algo (40%) A menudo

(60%)

Gene-ralmente

(75%)

Mayor- Mente (90 %)

Totalmente (100 %)

TEAM • Indica la cohesión y madurez del equipo de trabajo

Interacción muy difícil

Algo Dificultad

de interacción

Básicamente

hay interacción

cooperativa

Cooperativa Altamente

cooperativa Interacción

total

REGRESAR

FACTORES CONSIDERACIONES MUY BAJO

BAJO NOMINAL ALTO MUY ALTO

VALORES

Capacidad de los analistas

Se considera la capacidad de análisis y diseño, eficiencia, habilidad para trabajar en equipo. No se considera el nivel de experiencia

15% 35% 55% 75% 90%

Capacidad De los programadores

Se considera la capacidad de trabajo en equipo, eficiencia y habilidad para comunicarse. No se considera el nivel de experiencia

15% 35% 55% 75% 90%

Continuidad del personal (al año)

Expresa el porcentaje de rotación anual del personal afectado al proyecto

48% al año

24% al año

12% al año

6% al año

3% al año

FACTOR DE ESCALA

Reusabilidad Identificar elemento a Reusar

Nada Por

proyecto

Por programa

Por línea de

producto

Por múltiples líneas de producto

FACTOR DE ESCALA

PERS

RUSE

SIGUIENTE

FACTORES CONSIDERACIONES MUY BAJO

BAJO NOMINAL

ALTO MUY ALTO

VALORES

Restricciones de tiempo de ejecución

Se expresa en términos de porcentaje de disponibilidad de tiempo de ejecución que será usado por el sistema contra los recursos disponibles

<= 50% de uso de los recursos disponibles

70% 85% 95%

Volatilidad de plataforma

Expresa la velocidad de cambio del hardware y software usados como plataforma

Cambios mayores cada 12 meses y cambios menores cada mes

Mayores :6 meses, menores: 2 semanas

Mayores : 2 meses, menores: 1 semanas

Mayores : 2 semanas, menores: 2 días

FACTOR DE ESCALA Experiencia en aplicaciones

Contempla el nivel de experiencia del grupo de desarrollo (analistas) en aplicaciones equivalentes

2 meses

6 meses

1 año

2 años

6 años

Experiencia en la plataforma

Refleja la experiencia del grupo de desarrollo (programadores) en el uso de las herramientas de software y hardware utilizado como plataforma

2 meses

6 meses

1 año

2 años

6 años

Experiencia en el lenguaje y herramientas de desarrollo

Refleja la experiencia del grupo de desarrolladores en el lenguaje de programación y las herramientas de desarrollo utilizadas

2 meses 6

meses 1

año 2

años 6 años

FACTOR DE ESCALA

PREX

SIGUIENTE

PDIF

FACTOR CONSIDERACIONES

MUY BAJO

BAJO NOMINAL ALTO MUY ALTO

VALORES

Calendario de desarrollo

Restricciones impuestas al grupo de desarrolladores sobre la agenda nominal estimada del proyecto

75% del nominal

85 % 100% 130% 160%

FACTOR DE ESCALA Uso de herramientas de software

Contempla el uso de herramientas desde la edición hasta el manejo de todo el ciclo de vida

Edición con programas de texto

CASE simple y de poca integraci

ón

Herramientas básicas para todo el ciclo de vida con moderada integración

Potentes herramientas a hacer usadas en

todo el ciclo de vida con

integración moderada

potentes y preactivas, muy bien

integradas con el

proceso, los

métodos y la

reusabilidad

Desarrollo en múltiples ubicaciones

Involucra la ubicación física y el soporte de comunicaciones

Algo de teléfono y

mail

Fax, teléfonos individual

es

Red de correo

electrónico interno

Comunicaciones

electrónicas que

cubren todas las

ubicaciones

Multimedia

FACTOR DE ESCALA

REGRESAR

FCIL

SCED

Métrica: “Esfuerzo con Reutilización”

Reducir la estimación de esfuerzo utilizando reutilización.

Obtener el esfuerzo real usando reutilización de clases

¿Y si tengo reutilización de clases, cual es mi esfuerzo real ?

OBJETIVOS:



✔

✔

✔

SIGUIENTE

Datos requeridos:

Cálculo:

✔

✔

•Esfuerzo real

•Porcentaje de reutilización

... esfuerzo con reutilización

✔ Sugerencias

REGRESAR

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

Tengo un proyecto igualito !!

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

Medir el tamaño del equipo de trabajo para predecir el número de elementos necesarios para el desarrollo del proyecto.

Cantidad de hombres necesarios para el desarrollar un proyecto orientado a objetos

¿cuanta gente se requiere para la elaboración del proyecto?

OBJETIVOS:



✔

✔

✔

SIGUIENTE

Datos requeridos:

Cálculo:

✔

✔

•Clases Totales

•Número de clases promedio de personas por clase

Cantidad de Hombres = Total Clases / Promedio de las clase por persona

... tamaño del equipo de trabajo

✔ Sugerencias

REGRESAR

QUE EXIGENTES LORENZ Y KIDD !!

Métrica: “Expertos para el Área”

OBJETIVOS:



✔

✔

✔

SIGUIENTE

Identificar si la persona es la indicada para el área.

El nivel de eficiencia por cada integrante

El nivel de eficiencia del Equipo de Trabajo

¿El trabajo asignado para .... es el adecuado ?

Cálculo:✔• Definir criterios de adaptación por participante

• Asignación de peso peso= Núm. Aptitudes/100

... expertos para el área

REGRESAR

1. Valor que el participante aporta por cada actividad

Muy bajo = 0 Sin aptitud

Bajo = 2 Algo de Relación

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

FORMATO

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

Control mediante métricas OO

Proporciona incentivos para el reuso

Planificación

Director del proyecto

Subtotal Posee los contratos del subsistema

Conoce las clases llaves del proyecto

Arquitectos

Subtotal Dominio acerca de la industria

Proveedor de la clasificación de los requerimientos y la terminología

Expertos al dominio

del problema

Subtotal

Nivel de eficiencia por equipo de trabajo:

REGRESAR

Métrica: “Experiencia del Equipo de Trabajo”

Asegurar que los integrantes del equipo de trabajo elaborar eficientemente de manera conjunta.

El nivel de experiencia como Equipo de Trabajo

¿El equipo de trabajo estimado que nivel de experiencia tiene ?

OBJETIVOS:



✔

✔

✔

SIGUIENTE

Datos requeridos:

Cálculo:

✔

✔

•Comparativas de eficiencia en el proyecto

•Comparativas de comportamiento humano

Valor = D1 – D2

Valor = 0 Excelente

Valor < D1 / 2 Bueno

Valor = D1 /2 Medio

Valor > D1 / 2 Malo

... experiencia del equipo de trabajo

✔ Sugerencias

REGRESAR

D1 D2 Valor Escala Comentario

PRea PCon

PCon PMar

PCon Ptie

PMar Preq

EE ES

PI PD

PC PsC

métrica

“ Métodos y Herramientas”

Identificar si las herramientas y métodos son indispensables para el desarrollo del proyecto.

Obtener un número que nos indique el nivel de importancia de las Herramientas y Métodos sobre el proyecto

¿Qué tan indispensables el uso de Herramientas y Métodos para desarrollo ... ?

OBJETIVOS:



✔

✔

✔

SIGUIENTE

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

Para el diseño y a generación automática de código de la menos el 50% del sistema

4

Para el diseño y la generación automática de código de al menos el 90% del sistema

5

Para documentar al menos 50% del diseño de alto nivel y diseño detallado

3

Para documentar el menos del 50% del diseño de alto nivel

2

Sirven de ayuda en el 20 % de la documentación1

No se usan herramientas0

DESCRIPCIONESCALA

REGRESAR

Métrica: “Personas-Día-Clase”

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

El tiempo aproximado para desarrollar un proyecto OO.

¿El tiempo establecido por el cliente es el adecuado ?

¿cuánto tiempo me llevará desarrollar el proyecto?

OBJETIVOS:



✔

✔

✔

SIGUIENTE

..personas-Día-Clase

REGRESAR

Datos requeridos:

Cálculo:

✔

✔

•10 a 15 días para una clase en producción, es decir, incluyendo documentación y pruebas de las clases

•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

Establecer el nivel de exigencia con el que será tratado el proceso de desarrollo del proyecto, definiendo criterios de adaptación recomendable para POO.

Nivel de rigor

¿qué tan exigente es el proyecto?

OBJETIVOS:



✔

✔

✔

SIGUIENTE

Métrica: “Rigor del Proyecto”

... rigor del proyecto

REGRESAR

Datos requeridos:

Cálculo:

✔

✔

✔ Sugerencias:

• Definir criterios de adaptación por participante• Asignación de grados de 1 (pequeño subconjunto de

tareas) hasta 5 (conjunto completo de tareas, 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

VRigor < 1.2 Casual1.0 < VRigor> 3.0 EstructuradoVRigor > 2.4 Estricto

Medir el nivel de probabilidad de un proyecto sea riesgoso, además de identificar los tipos de riesgo que se pueden presentar.

Nivel de riesgo del proyecto.

¿se pueden presentar riegos durante el desarrollo del proyecto? ¿A qué nivel?

Riesgos, el grado de incertidumbre que mantendrá el presupuesto, el grado de incertidumbre de pacilidad para corregirse

OBJETIVOS:



DATOS REQUERIDOS :

✔

✔

✔

✔

SIGUIENTE

Métrica: “Impacto de riesgo”

REGRESAR

Cálculo:✔

... impacto de riesgo

RIESGOS PROBAB. IMPACTO

La estimación del tamaño fue erróneo

Mayor número de usuarios de los previstos

Menos reutilización de la prevista

Los usuarios finales se resisten al sistema

La fecha de entrega estará muy ajustada

Se perderán los presupuestos

El cliente cambiara los requisitos

La tecnología no alcanzará las expectativas

Falta de formación en las herramientas

Personal sin experiencia

Cambios de personal

Total de Riesgo sobre el Proyecto

Catastrófico 1

num. Riesgo = ∑Impacto

Critico 2

∑Impacto <= num. Riesgo *2

Marginal 3

∑Impacto <= num. riesgo *3

Despreciable 4

∑Impacto <= num. riesgo *4

4. CASO DE ESTUDIO

SELLER

SIGUIENTE

CLASES CLAVE

VALIDACION DE REQUERIMIENTOS

CC = 28 clases

Clases que representan el 100% del dominio del problema, identificadas por los analistas

Todos los requerimientos han sido cubiertos en las clases, en un solo nivel de abstracción.

TAMAÑO DEL PROYECTO EN

BASE A CLASES .98 9870GRÁFICA (2.5)28

CIFCTCSINTERFAZCC

SIGUIENTE

Métricas aplicadas a SELLER

... métricas aplicadas a SELLERESFUERZO

4.781.543.111.08.98EsRealFECEsfNomBCIF

Esfuerzo Real = 5 Hombres

cálculo

TIEMPOTDes= (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

FLEX • Algo de relajación en cuanto a flexibilidad del

desarrollo Nominal 3

RESL • La arquitectura es sólida y los riesgos

generalmente se mitigan Alto 2

TEAM • La interacción del equipo es altamente

cooperativa Muy alto 1

B 1.08

EsfNom 3.11

mes hombre

EsfReal = 3.11 x 1.54 FEC

EsfNom= 2.94 x (.98) 1.08

B = 1.01 + 0.01 * 7

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

MULTI- PLICADOR

FACTORES PONDERACIÓN VALORES FACTOR ESCALA

Capacidad de los analistas MUY ALTO 5

Capacidad de los programadores

NOMINAL 3 PERS

Continuidad del personal (al

año) ALTO 4

1.13

RUSE Reusabilidad BAJO 2 1.03

Restricciones de tiempo de ejecución

MUY ALTO 5 PDIF

Volatilidad de plataforma BAJO 2 1.08

Experiencia en aplicaciones ALTO 4

Experiencia en la plataforma MUY ALTO 5 PREX Experiencia en el lenguaje y herramientas de desarrollo

ALTO 4

1.14

SCED Calendario de desarrollo BAJO 2 1.03

Uso de herramientas de software

NOMINAL 3 FCIL

Desarrollo en múltiples ubicaciones

MUY BAJO 1 1.05

FACTOR DE ESCALA = ∑VALOR /100 +1.01 REGRESAR

EXPERTOS

PARA

EL ÁREA

EficET = 55.24%Rango NOMINAL de eficiencia, se detectaron deficiencias en las actividades para desarrollar un POO.

... métricas aplicadas a SELLER

cálculo

EXPERIENCIA COMO

EQUIPO DE TRABAJO

ExpET = 44%Rango MEDIO, laboran eficientemente, cumplen con los requerimientos del cliente, a tiempo paro sin factores de calidad.

SIGUIENTE

MÉTODOS Y HERRAMIENTAS

MyH = 3%Rango NOMINAL, uso de herramientas solo en la fase de diseño

cálculo

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 Control mediante métricas OO 14.28 0 0 Proporcionar incentivos para el reuso 14.28 5 7.14 Planificación 14.28 8 11.42

Director del proyecto

Subtotal 64.24 %

Posee los contratos del subsistema 30 8 24 Conoce las clases llaves del proyecto 70 8 56 Arquitectos

Subtotal 80 % Dominio acerca de la industria 50 5 25 Proveedor de la clasificación de los requerimientos y la terminología 50 5 25

Expertos al dominio

del problema Subtotal 50 % Aportan las experiencias prácticas de la tecnología orientada a objeto para el proyecto

35 5 17.5

Capaces de cambiar el paradigma 30 8 24 Adiestran al núcleo del equipo. 35 8 28

Guías del enfoque

Orientado a Objetos Subtotal 69.5

% Diseñadores de la llave del modelo de clases 50 5 25 Trabajan desde la biblioteca de reuso 50 5 25

Desarrolladores De clases

Subtotal 50 % Construyen la aplicación a partir de bloques reusables 60 5 30 Escriben relativamente un pequeño porcentaje del nuevo código para especializar y completar la aplicación

40 2 8 Desarrolladores de 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 construido

25 2 5

Proporcionan los resultados de la prueba de usabilidad durante el análisis 25 5 5

Probadores

Subtotal 35 %

Nivel de eficiencia por equipo de trabajo: 55.24

REGRESAR

VARIABLES D1 D2 Valor Escala COMENTARIO

PRea PCon 2 1 1 MEDIO De 2 proyectos realizados, solo 1 fue concluido debido a la mala planeación.

PCon PMar 1 1 0 EXCELENTE Los concluidos fueron puestos en marcha

PCon Ptie 1 0 1 MALO No fue entregado debido a la mala planeación

PMar Preq 1 1 0 EXCELENTE Todos han cumplido los requerimientos del cliente

PReq Pcal 1 0 1 MALO

PCon Pcal 1 0 1 MALO

No se tomaron en cuenta los factores de la calidad, solo cubre un 40 % de calidad.

EE ES 20 15 5 BUENO

De los dos proyectos entregados solo 15 de 20 errores han sido solucionados, debido a no tener los recursos disponibles

PI PD 5 3 2 BUENO 3 de los programadores no aportan iniciativas, dependen del jefe de proyecto.

PC PsC 5 5 1 BUENO Se confía plenamente en el personal

REGRESAR

RIESGOS

RIESGO = 23Dejar 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.

... métricas aplicadas a SELLER

cálculo

SIGUIENTE

cálculo

RIGOR

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

CRITERIOS

DE ADAPTACIÓN

GRADO PESO MULTIPLICADOR

DE ENTRADA

PRODUCTO

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

significativamente baja 60% 2

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

sobre proyecto 23

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 SWDesarrollo de componentes reusablesTécnicas de modelado Esquemas estrictos de calidad

Se identificó el Rigor del proyecto. REGRESAR

REGRESAR

RIESGOS PROBABILIDAD IMPACTO

La estimación del tamaño depende ser significativamente

baja 30% 2

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

sobre proyecto 19

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

GRACIAS POR SU ATENCION

M.C. Esperanza Aguillón Robles

aguillon@ itmorelia.edu.mx

peraguillon@ gmail.com

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

INSTITUTO TECNOLÓGICO DE MORELIADEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN

mailto:[email protected]

mailto:[email protected]

Documents

Metricas