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 EMPRESA

NUMERO DE EMPLEADOS

NÚMERO DE EMPRESAS

PORCENTAJE

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 Empresa

Número de organizaciones

Número de empleados de sistemas

Departamentos internos de software

12,521

10 máximo

Dedicadas al Desarrollo de Software

759

De 11 a 25

Número de Empleados

De 57 a 100

•Administradores sin experiencia en obtención de productos de calidad •Proyectos entregados fuera de tiempo •Desorganización en las empresas

¿ GESTIÓN?

•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 riegos

Gestión de Recursos

Planificación temporal y control

Seguimiento del Progreso 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 que me sirve la medición

?

PARA:  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. de Software Proyecto de Software Producto de Software

Recopilación de datos

Medidas

Cálculo de métricas

Métricas

Evaluación de métricas Indicadores SIGUIENTE

CLASIFICACIÓN DE LAS MÉTRICAS ENTIDADES DE SOFTWARE

•Directas o indirectas •Internas y Externas •Complejas o sencillas

•Entregables •Actividades •Personas •Recursos

ATRIBUTOS

•Publicas o privadas

•Esfuerzo o tiempo •Longitud de un programa

Materiales

•Experiencia del equipo de 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

Ta m añ o

Re qu isi to s

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

o z r e u f Es

o p em i T

s o g s 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:

✔

VALOR OBJETIVO A ALCANZAR:

✔ INTERROGANTE QUE RESUELVE:

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?

SIGUIENTE

... validación de requisitos Datos ✔ requeridos:

•Requerimientos del cliente •Diagrama de clases

✔ Cálculo:

Clases Clase1

Clase2

...

Clase n

Requisito R1 R2

√ √

...

✔ Sugerencias

¿Cuantas veces aplicaste la métrica?

√

Rn

Como 20, nada más !!!! REGRESAR

TAMAÑO DE LA APLICACIÓN Métrica: ✔

OBJETIVOS:

✔

VALOR OBJETIVO A

“ Clases Clave (CC)” Indicar el volumen necesario, cantidad principales

de de

trabajo clases

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

ALCANZAR: ✔ INTERROGANTE QUE RESUELVE:

¿Cuántas clases dominan sistema a desarrollar ? SIGUIENTE

... clases clave Datos ✔ requeridos: ✔ Cálculo:

✔ Interrogantes:

•Requerimientos del cliente •Diagrama de clases 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 importante?

puede

considerar

este

objeto

¿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 OBJETIVO A

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

ALCANZAR: ✔ INTERROGANTE QUE RESUELVE:

¿Cuántas son las clases secundarias?

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 OBJETIVO A

Obtener un dato cuantitativo tamaño total del proyecto

del

ALCANZAR:

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

✔ INTERROGANTE 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:

✔

VALOR OBJETIVO A ALCANZAR:

✔ INTERROGANTE QUE RESUELVE:

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?

SIGUIENTE

... Cientos de instrucciones fuente Datos ✔ requeridos: ✔ Cálculo:

✔ Sugerencias

•Número de clases totales

CIF = F/100

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

REGRESAR

Métrica: “

Esfuerzo del proyecto”

✔

OBJETIVOS:

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

✔

VALOR OBJETIVO A

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

ALCANZAR:

de el en

✔ INTERROGANTE QUE RESUELVE:

¿En cuanto esfuerzo necesito para el desarrollo del proyecto? SIGUIENTE

... esfuerzo del proyecto Datos ✔ requeridos: ✔ Cálculo:

• CIF

EsfReal (mes-hombre)= EsfNom x FEC EsfNom= 2.94 x CIF

B

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

Wi

PREC

FLEX RESL TEAM

CONSIDERACIONES • 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 • Necesidad de que el software se ajuste a las especificaciones de interfaces externas • Indica la fortaleza de la arquitectura y métodos de estimación y reducción de riesgos. • Indica la cohesión y madurez del equipo de trabajo

Nomina l Alto (2) (3)

Muy Alto (1)

Extra alto (0)

Familiar

Muy Familiar

Absolutamente Familiar

Algo de relajación

Generalmente Conforme

Algo de conformidad

Objetivos Generales

Algo (40%)

A menudo (60%)

Generalmente (75%)

MayorTotalmente Mente (90 %) (100 %)

Algo Dificultad de interacción

Básicament e hay interacción cooperativa

Cooperativa

Muy Bajo (5)

Bajo (4)

Completa

Completa

Algo

Riguroso

Ocasional

Poco (20%)

Interacción muy difícil

Altamente cooperativa

Interacción total

REGRESAR

FACTORES

CONSIDERACIONES MUY BAJO Capacidad Se considera la de los capacidad de análisis analistas y diseño, eficiencia, habilidad para 15% 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% comunicarse. No se considera el nivel de experiencia Continuidad Expresa el porcentaje del personal de rotación anual del 48% (al año) personal afectado al al año proyecto

PERS

BAJO NOMINAL ALTO

MUY ALTO

35%

55%

75%

90%

35%

55%

75%

90%

24% al año

12% al año

6% al año

3% al año

VALORES

FACTOR DE ESCALA

Reusabilidad

RUSE

Identificar elemento a Reusar

Por Por múltiples Por línea líneas de Por Nada proye de producto programa cto product o FACTOR DE ESCALA SIGUIENTE

PDIF

FACTORES

CONSIDERACIONES

MUY BAJO

BAJO

NOMIN AL 70%

ALTO

MUY ALTO 95%

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

D1 / 2

Malo

EE

ES

PI

PD

PC

PsC

✔ Sugerencias

Valor Escala Comentario

REGRESAR

métrica

“ Métodos y Herramientas” ✔

OBJETIVOS:

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

✔

VALOR OBJETIVO A

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

ALCANZAR: ✔ INTERROGANTE QUE RESUELVE:

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

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 Para documentar al menos 50% del diseño de alto nivel y diseño detallado Para el diseño y a generación automática de código de la menos el 50% del sistema Para el diseño y la generación automática de código de al menos el 90% del sistema

3 4 5

REGRESAR

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

OBJETIVOS:

✔

VALOR OBJETIVO A ALCANZAR:

✔ INTERROGANTE QUE RESUELVE:

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? SIGUIENTE

..personas-Día-Clase 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

REGRESAR

Métrica: “Rigor del Proyecto” ✔

OBJETIVOS:

✔

VALOR OBJETIVO A ALCANZAR:

✔ INTERROGANTE QUE RESUELVE:

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?

SIGUIENTE

... rigor del proyecto Datos ✔ requeridos:

•

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

•

Multiplicador de entrada 1 o 0

•

PRODUCTO = Grado x Peso x ME

✔ Cálculo:

•

importancia a cada criterio va desde 0.8 a 1.2

n

VRigor = ∑productos / No de criterios i

✔ Sugerencias:

VRigor < 1.2 1.0 < VRigor> 3.0 VRigor > 2.4

Casual Estructurado Estricto

REGRESAR

Métrica: “Impacto de riesgo” ✔

OBJETIVOS:

✔

VALOR OBJETIVO A ALCANZAR:

✔ INTERROGANTE QUE RESUELVE: ✔

DATOS REQUERIDOS :

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 SIGUIENTE

... impacto de riesgo ✔ Cálculo:

RIESGOS

Catastrófico

1

num. Riesgo = ∑Impacto Critico

2

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

∑Impacto