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

Transcripción

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

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]

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

5 1. LA INDUSTRIA DEL SOFTWARE TIPO DE EMPRESA NUMERO DE EMPLEADOS NÚMERO DE EMPRESAS PORCENTAJE MICRO 1 a % PEQUEÑA 11 a % MEDIANA 51 a % GRANDE Más de %

6 LA INDUSTRIA DEL SOFTWARE Tipo de Empresa Número de organizaciones Número de empleados de sistemas Número de Empleados Departamentos internos de software 12, máximo Dedicadas al Desarrollo de Software 759 De 11 a 25 De 57 a 100 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 GESTIÓN?

7 GESTIÓN DE PROYECTOS Planificación Medición Aná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

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: CARACTERIZAR Para que me sirve la medición? EVALUAR PREDECIR MEJORAR

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. de Software Proyecto de Software Recopilación de datos Cálculo de métricas Medidas Métricas Producto de Software Evaluación de métricas Indicadores

10 CLASIFICACIÓN DE LAS MÉTRICAS ENTIDADES DE SOFTWARE Entregables Actividades Personas Recursos Materiales Financieros ATRIBUTOS Esfuerzo o tiempo Longitud de un programa Experiencia del equipo de trabajo Consumo de papel y cinta Estado del presupuesto Directas o indirectas Internas y Externas Complejas o sencillas Publicas o privadas

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

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

13 3. Métricas Aplicadas a la Gestión de Proyectos Requisitos Tamaño Esfuerzo Tiempo Riesgos

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

15 METRICAS APLICADAS A LA GPOO REQUISITOS TAMAÑO DE LA APLICACION VALIDACION DE REQ (VR) CLASES CLAVE (CC) CLASES SOPORTE (CS) CLASES TOTALES (CT) CIENTOS DE INSTRUCCINES FUENTE (CIF)

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.

17 ... MÉTODOS Y HERRAMIENTAS METODOS Y HERRAM. TIEMPO GRADO DEL RIGOR DEL PROYECTO PERSONAS-DIA-CLASE. CONTROL DE CAMBIOS RIGOR DEL PROYECTO IMPACTO DE RIESGO

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 ALCANZAR: INTERROGAN- TE QUE RESUELVE: Obtener un número de requerimientos faltantes en el diagrama de clases. Los requerimientos han sido cubiertos en el diagrama de clases?

19 ... validación de requisitos Datos requeridos: Requerimientos del cliente Diagrama de clases Cálculo: Clases Requisito Clase1 Clase2... Clase n R1 R2... Sugerencias Rn Cuantas veces aplicaste la métrica? Como 20, nada más!!!! REGRESAR

20 TAMAÑO DE LA APLICACIÓN Métrica: Clases Clave (CC) OBJETIVOS: Indicar el volumen de trabajo necesario, cantidad de clases principales VALOR OBJETIVO A ALCANZAR: INTERROGAN- TE QUE RESUELVE: Obtener un número de clases clave, que representan el dominio del proyecto a desarrollar. Cuántas clases dominan sistema a desarrollar?

21 ... clases clave Datos requeridos: Requerimientos del cliente Diagrama de clases Cálculo: El número de CC depende directamente de las clases identificadas y consideradas de vital importancia para el cliente. Interrogantes: 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? REGRESAR

22 Métrica: Clases Soporte (CS) OBJETIVOS: VALOR OBJETIVO A ALCANZAR: INTERROGAN- TE QUE RESUELVE: 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?

23 ... clases soporte 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 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 OBJETIVO A ALCANZAR: INTERROGAN- TE QUE RESUELVE: Obtener un dato cuantitativo del tamaño total del proyecto cuál es el tamaño total del proyecto?

25 ... clases totales Datos requeridos: Cálculo: CC CS 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 ALCANZAR: INTERROGAN- TE QUE RESUELVE: Calcular el tamaño del proyecto en base a instrucciones fuente. cuál es el tamaño del proyecto en base instrucciones fuente?

27 ... Cientos de instrucciones fuente Datos requeridos: Número de clases totales Cálculo: CIF = F/100 Sugerencias 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

28 Métrica: Esfuerzo del proyecto OBJETIVOS: Examinar los factores de esfuerzo para cuantificar el esfuerzo empleado para el desarrollo. VALOR OBJETIVO A ALCANZAR: INTERROGAN- TE QUE RESUELVE: 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?

29 ... esfuerzo del proyecto Datos requeridos: Cálculo: CIF EsfReal (mes-hombre)= EsfNom x FEC EsfNom= 2.94 x CIF B B = * Σ 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 W i 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 del equipo de trabajo madurez Muy Bajo (5) Bajo (4) Nomina l (3) Alto (2) Muy Alto (1) Completa Completa Algo Familiar Muy Familiar Riguroso Ocasional Poco (20%) Algo (40%) Interacción muy difícil Algo Dificultad de interacción Algo de relajación A menudo (60%) Básicament e hay interacción cooperativa Generalmente Conforme Generalmente (75%) Cooperativa Algo de conformidad Mayor- Mente (90 %) Altamente cooperativa Extra alto (0) Absolutamente Familiar Objetivos Generales Totalmente (100 %) Interacción total REGRESAR

31 PERS FACTORES CONSIDERACIONES MUY BAJO BAJO NOMINAL ALTO MUY ALTO Capacidad Se considera la de los capacidad de análisis analistas y diseño, eficiencia, habilidad para 15% 35% 55% 75% 90% 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 VALORES RUSE Reusabilidad Identificar elemento a Reusar Nada Por proye cto Por programa Por línea de product o Por múltiples líneas de producto FACTOR DE ESCALA

32 PDIF FACTORES CONSIDERACIONES MUY BAJO 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 BAJO <= 50% de uso de los recursos disponibl es NOMIN ALTO MUY AL ALTO 70% 85% 95% VALO RES PREX Volatilidad de plataforma Experiencia en aplicaciones Experiencia en la plataforma Expresa la velocidad de cambio del hardware y software usados como plataforma Contempla el nivel de experiencia del grupo de desarrollo (analistas) en aplicaciones equivalentes Refleja la experiencia del grupo de desarrollo (programadores) en el uso de las herramientas de software y hardware utilizado como plataforma Experiencia en Refleja la experiencia del grupo el lenguaje y de desarrolladores en el lenguaje herramientas de de programación y las desarrollo herramientas de desarrollo utilizadas Cambios mayores cada 12 meses y cambios menores cada mes 2 meses 2 meses 2 meses Mayores :6 meses, menore s: 2 semana s 6 meses 6 meses 6 meses Mayores : 2 meses, menores: 1 semanas Mayores : 2 semanas, menores: 2 días FACTOR DE ESCALA 1 año 1 año 1 año 2 años 6 años 2 años 6 años 2 años 6 años FACTOR DE ESCALA

33 SCED FCIL FACTOR Calendario de desarrollo Uso de herramientas de software Desarrollo en múltiples ubicaciones CONSIDERACION ES Restricciones impuestas al grupo de desarrolladores sobre la agenda nominal estimada del proyecto Contempla el uso de herramientas desde la edición hasta el manejo de todo el ciclo de vida Involucra la ubicación física y el soporte de comunicaciones MUY BAJO 75% del nominal Edición con programas de texto Algo de teléfono y mail BAJO NOMINAL ALTO MUY ALTO 85 % 100% 130% 160% CASE simple y de poca integraci ón Fax, teléfonos individual es FACTOR DE ESCALA Herramientas básicas para todo el ciclo de vida con moderada integración Red de correo electrónico interno Potentes herramient as a hacer usadas en todo el ciclo de vida con integración moderada Comunicac iones electrónica s que cubren todas las ubicacione s FACTOR DE ESCALA potentes y preactivas, muy bien integradas con el proceso, los métodos y la reusabilida d Multimedia VALORES REGRESAR

34 Métrica: Esfuerzo con Reutilización OBJETIVOS: Reducir la estimación de esfuerzo utilizando reutilización. VALOR OBJETIVO A ALCANZAR: INTERROGAN- TE QUE RESUELVE: Obtener el esfuerzo real usando reutilización de clases Y si tengo reutilización de clases, cual es mi esfuerzo real?

35 ... esfuerzo con reutilización Datos requeridos: Cálculo: Esfuerzo real Porcentaje de reutilización 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 ALCANZAR: INTERROGAN- TE QUE RESUELVE: Cantidad de hombres necesarios para el desarrollar un proyecto orientado a objetos cuanta gente se requiere para la elaboración del proyecto?

37 ... tamaño del equipo de trabajo 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 Sugerencias QUE EXIGENTES LORENZ Y KIDD!! REGRESAR

38 Métrica: Expertos para el Área OBJETIVOS: Identificar si la persona es la indicada para el área. VALOR OBJETIVO A ALCANZAR: INTERROGAN- TE QUE RESUELVE: El nivel de eficiencia por cada integrante El nivel de eficiencia del Equipo de Trabajo El trabajo asignado para... es el adecuado?

39 ... expertos para el área Cálculo: Definir criterios de adaptación por participante Asignación de peso peso= Núm. Aptitudes/ Valor que el participante aporta por cada actividad Muy bajo = 0 Bajo = 2 Nominal = 5 Alto = 8 Muy alto = 10 Sin aptitud Algo de Relación Capaz de aplicarlo, pero no enfatiza Altamente Cooperativo Totalmente aplicable (conocimientos) FORMATO 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 Director del proyecto Arquitectos Expertos al dominio del problema Control de gestión Control mediante métricas OO Proporciona incentivos para el reuso Planificación Subtotal Posee los contratos del subsistema Conoce las clases llaves del proyecto Subtotal Dominio acerca de la industria Proveedor de la clasificación 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 ALCANZAR: INTERROGAN- TE QUE RESUELVE: El nivel de experiencia como Equipo de Trabajo El equipo de trabajo estimado que nivel de experiencia tiene?

42 ... experiencia del equipo de trabajo Datos requeridos: Comparativas de eficiencia en el proyecto Comparativas de comportamiento humano Cálculo: Valor = D 1 D 2 Valor = 0 Excelente Valor < D 1 / 2 Bueno Valor = D 1 /2 Medio Valor > D 1 / 2 Malo Sugerencias D 1 D 2 Valor Escala Comentario PRea PCon PCon PMar PCon Ptie PMar Preq EE ES PI PD PC PsC REGRESAR

43 métrica Métodos y Herramientas OBJETIVOS: Identificar si las herramientas y métodos son indispensables para el desarrollo del proyecto. VALOR OBJETIVO A ALCANZAR: INTERROGAN- TE QUE RESUELVE: 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...?

44 ... métodos y herramientas Cálculo: ESCALA DESCRIPCION No se usan herramientas Sirven de ayuda en el 20 % de la documentación 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 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 ALCANZAR: INTERROGAN- TE QUE RESUELVE: 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?

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

47 Métrica: Rigor del Proyecto OBJETIVOS: VALOR OBJETIVO A ALCANZAR: INTERROGAN- TE 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?

48 Datos requeridos: Cálculo:... rigor del proyecto 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 Sugerencias: n VRigor = productos / No de criterios i VRigor < 1.2 Casual 1.0 < VRigor> 3.0 Estructurado VRigor > 2.4 Estricto REGRESAR

49 Métrica: Impacto de riesgo OBJETIVOS: VALOR OBJETIVO A ALCANZAR: INTERROGAN- TE 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

50 ... impacto de riesgo Cálculo: Catastrófico 1 num. Riesgo = Impacto Critico 2 Impacto <= num. Riesgo *2 Marginal 3 Impacto <= num. riesgo *3 Despreciable 4 Impacto <= num. riesgo *4 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 REGRESAR

51 4. CASO DE ESTUDIO SELLER

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 REQUERIMIENTOS Todos los requerimientos han sido cubiertos en las clases, en un solo nivel de abstracción. TAMAÑO DEL PROYECTO EN BASE A CLASES CC 28 INTERFAZ GRÁFICA (2.5) CS 70 CT 98 CIF.98

53 ... métricas aplicadas a SELLER ESFUERZO cálculo CIF B EsfNom FEC EsReal 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)

54 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 RESL La arquitectura es sólida y los riesgos generalmente se mitigan TEAM La interacción del equipo es altamente cooperativa EsfNom= 2.94 x (.98) 1.08 Nominal 3 Alto 2 Muy alto 1 B 1.08 EsfNom 3.11 mes hombre B = * 7 EsfReal = 3.11 x 1.54 FEC = 1.13 x 1.03 x 1.08 x 1.14 x 1.03 x 1.05 REGRESAR FEC

55 MULTI- PLICADOR FACTORES PONDERACIÓN VALORES FACTOR ESCALA Capacidad de los analistas MUY ALTO 5 PERS Capacidad de los programadores NOMINAL Continuidad del personal (al año) ALTO 4 RUSE Reusabilidad BAJO PDIF Restricciones de tiempo de ejecución MUY ALTO 5 Volatilidad de plataforma BAJO 2 Experiencia en aplicaciones ALTO PREX Experiencia en la plataforma MUY ALTO Experiencia en el lenguaje y herramientas de desarrollo ALTO 4 SCED Calendario de desarrollo BAJO FCIL Uso de herramientas de software Desarrollo en múltiples ubicaciones NOMINAL 3 MUY BAJO FACTOR DE ESCALA = VALOR / REGRESAR

56 ... métricas aplicadas a SELLER EXPERTOS PARA EL ÁREA EficET = 55.24% Rango NOMINAL de eficiencia, se detectaron deficiencias en las actividades para desarrollar un POO. cálculo EXPERIENCIA COMO EQUIPO DE TRABAJO ExpET = 44% cálculo Rango MEDIO, laboran eficientemente, cumplen con los requerimientos del cliente, a tiempo paro sin factores de calidad. MÉTODOS Y HERRAMIENTAS MyH = 3% Rango NOMINAL, uso de herramientas solo en la fase de diseño

57 PARTICIPANTES ACTIVIDAD PESO Grado NEfic Motivación para el equipo técnico Habilidad para amoldar procesos existentes Resolución de problemas Director del proyecto Arquitectos Control de gestión Control mediante métricas OO Proporcionar incentivos para el reuso Planificación Subtotal % Posee los contratos del subsistema Conoce las clases llaves del proyecto Subtotal 80 % Dominio acerca de la industria Proveedor de la clasificación de los requerimientos y la terminología Expertos al dominio del problema Subtotal 50 % Aportan las experiencias prácticas de la tecnología orientada a objeto para el Guías del proyecto enfoque Capaces de cambiar el paradigma Orientado a Adiestran al núcleo del equipo Objetos Subtotal 69.5 % Diseñadores de la llave del modelo de clases Desarrolladores De clases Desarrolladores de la aplicación REGRESAR Probadores Trabajan desde la biblioteca de reuso Subtotal 50 % Construyen la aplicación a partir de bloques reusables Escriben relativamente un pequeño porcentaje del nuevo código para especializar y completar la aplicación Subtotal 38 % Interactúan a lo largo del desarrollo Organizan las pruebas de función del software basadas en los guiones Escriben ayudas en línea y parte de los manuales de cómo el sistema es construido Proporcionan los resultados de la prueba de usabilidad durante el análisis Subtotal 35 % Nivel de eficiencia por equipo de trabajo: 55.24

58 VARIABLES D 1 D 2 Valor Escala COMENTARIO PRea PCon MEDIO PCon PMar EXCELENTE PCon Ptie MALO PMar Preq EXCELENTE PReq Pcal MALO PCon Pcal MALO EE ES BUENO PI PD BUENO PC PsC BUENO REGRESAR De 2 proyectos realizados, solo 1 fue concluido debido a la mala planeación. Los concluidos fueron puestos en marcha No fue entregado debido a la mala planeación Todos han cumplido los requerimientos del cliente No se tomaron en cuenta los factores de la calidad, solo cubre un 40 % de calidad. De los dos proyectos entregados solo 15 de 20 errores han sido solucionados, debido a no tener los recursos disponibles 3 de los programadores no aportan iniciativas, dependen del jefe de proyecto. Se confía plenamente en el personal

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 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. cálculo

60 CRITERIOS DE ADAPTACIÓN GRADO PESO MULTIPLICADOR PRODUCTO DE ENTRADA Tamaño del proyecto Número de usuarios Importancia para el negocio Estabilidad de los requisitos Enfoque orientado a objetos Facilidad de comunicación Madurez de tecnología Limitaciones de rendimiento Personal del proyecto Interoperabilidad Factores de Reuso Valor de rigor 2.9 REGRESAR

61 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

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

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