4.1 CONCEPTOS DE GESTION

Transcripción

1 MODULO IV Ingeniería de Software INF CONCEPTOS DE GESTION 14/05/09 Resumen preparado por Miguel Cotaña 1

2 Gestión de Proyectos Cuando se planifica un proyecto se tiene que obtener estimaciones del costo y esfuerzo humano requerido por medio de las mediciones de software que se utilizan para recolectar los datos cualitativos acerca del software y sus procesos para aumentar su calidad. 2

3 La gestión del proyecto consiste en la utilización de las técnicas y actividades de gestión requeridas para conseguir un producto de calidad, de acuerdo con las necesidades de los usuarios, dentro de un presupuesto y con una planificación de tiempos establecidos previamente. 3

4 Qué es un Proyecto? Es un esfuerzo temporal comprometido a crear un producto o servicio único. Entre sus características principales: Temporalidad; Unicidad; Progresividad; Ejecutado por personas; Limitado a ciertos recursos; Planificado, ejecutado y controlado. 4

5 Tareas críticas en la gestión de proyectos El número de tareas identificables son muchas. Sin embargo, 3 son críticas y que deben ser desarrolladas correctamente: Estimación de duración, coste y esfuerzo necesarios para construir el producto; Planificación de tareas a realizar, asignación de personas, tiempos. Seguimiento 5

6 Estimación de proyectos Se define como la predicción de personal, del esfuerzo, de los costes y de la planificación que se requerirá para realizar todas las actividades y construir todos los productos asociados con el proyecto. Uno de los parámetros críticos de la estimación es determinar su exactitud. 6

7 Estimación enfoque tradicional Estimar Horas hombre Estimar El costo Determinar Plazos de entrega Determinar Personal involucrado 7

8 Estimación: método COCOMO Determinar Lineas de Estimar Horas hombre Determinar Personal involucrado codigo Establecer Plazo de entrega Estimar Tiempo total Estimar El costo 8

9 Estimación: método Punto Función Puntos de Función sin ajustar Puntos de Funcion ajustados Líneas De código Del software Ratio Líneas de Código PF 9

10 Larry Putnam, ha apuntado que la gestión del desarrollo de software considera la estimación como una actividad que permite obtener, prinicipalmente, respuestas a las siguientes preguntas: Cuánto Costará? Cuánto tiempo llevará hacerlo? 10

11 Razones de difícil estimación No existe un modelo universal; Hay muchas personas implicadas en los proyectos que precisan de estimaciones; La utilidad de una estimación dependerá de la etapa de desarrollo en la que nos encontremos; La estimación, a menudo se realiza superficialmente; 11

12 Las estimaciones claras, completas y precisas son difíciles de formular; Las características del Sw y de su desarrollo hacen difícil la estimación; Existe tendencia aparente hacia la subestimación; Existen malas interpretaciones; El estimador tiende a reducir en algún grado, para hacer más aceptable la oferta. 12

13 QUÉ producto CON QUÉ siginificado Tamaño sw Restricciones Ordenador Calidad requerida Complejidad del Sw Nivel de utilización Organización Documentación Tipo aplicación Tiempo ejec. Resp. Mem. Herramientas Técnicas Programación Equipo de programación QUIÉN Personal Calidad personal CÓMO Proyecto Req. durac. Proyecto Experiencia Dilatación comprensi. PARA QUIÉN usuario participación estabilidad experiencia Prototipado conocimientos Modelado ágil Matriz de organizació Equipos procedimiento 13

14 Requisitos de un buen estimador No tiene ningún interés, directo ni indirecto en los resultados del proceso de estimación: Formación y experiencia profesional; Juicio independiente; Basarse en metodos que pueda ser explicado, cuestionado, discutido y auditado por otros expertos; Usa herramientas de estimación; Documentar la estimación. 14

15 Salidas del proceso de estimación cuánta gente se necesita?; De qué perfiles?; Cuáles son los riesgos?; Cómo afectan las restricciones impuestas a las estimaciones?; Cuánto esfuerzo se necesita para realizar cada fase del ciclo de vida?; Cómo impacta este proceso en el resto de proyectos de la empresa?; 15

16 Cuál será el esfuerzo para mantener este proyecto?; Cuál será el tamaño del sistema (lineas de código)?; Cuántos defectos tendrá el producto?; Cuánta documentación será generada?; Cuál será el esfuerzo para generar dicha documentación?. 16

17 El espectro de la gestión La gestión eficaz de la gestión de proyectos software se enfoca sobre las cuatro P: Personal; Producto; Proceso; Proyecto. 17

18 Personal El SEI ha desarrollado un modelo de madurez de la capacidad de gestión de personal (MMCGP), que define: Reclutamiento; Selección; Gestión del desempeño; Entrenamiento; Retribución; Desarrollo de la carrera; Desarrollo de la cultura de equipo. 18

19 Los participantes Se clasifican en 5 categorías: Gestores ejecutivos, que definen los aspectos del negocio; Gestores (técnicos) del proyecto, quienes planifican, motivan, organizan y controlan a los profesionales que realizan el trabajo de software; Profesionales, proporcionan las habilidades técnicas necesarias; 19

20 Clientes, quienes especifican los requisitos para la ingeniería de software y otros elementos que tienen un interés mínimo en el resultado; Usuarios finales, quienes interactúan con el software una vez que se libera su uso productivo. 20

21 Líderes de equipo Weinberg, sugiere un modelo de liderazgo: Motivación, la habilidad para alentar (mediante el empuje o jalón ) al personal técnico; Organización, la habilidad para adecuar los procesos existentes; Ideas o innovación, la habilidad para alentar a la gente para crear y sentir creativamente. 21

22 Otra visión, define los rasgos: Resolución de problemas, un gestor puede diagnosticar los conflictos técnicos y organizativos; Dotes de gestión, encabezar y dirigir Incentivos, un gestor debe recompensar la iniciativa y los logros; Influencia y fomento de la cultura en equipo, mantener el control en situaciones de tensión emocional. 22

23 El equipo de software La mejor estructura de equipo depende del estilo de gestión de cada organización, del número de personas que integran el equipo y de sus grados de habilidad. Los factores: La dificultad del problema; El tamaño del programa; El tiempo que el equipo; El grado de modularidad; La calidad y confiabilidad; La rigidez en fechas de entrega. 23

24 Constantine, sugiere 4 paradigmas organizacionales para los equipos: Un paradigma cerrado, jerarquía tradicional de autoridad; Un paradigma aleatorio, estructura un equipo libremente y depende de la iniciativa individual de los miembros del equipo. Cuando se requiere innovación o adelantos tecnológicos, serán excelentes. Pero no son ordenados; 24

25 Un paradigma abierto, intenta estructurar un equipo en una forma que logre algunos de los controles asociados con el paradigma cerrado. El trabajo se desarrolla en colaboración. La sólida comunicación y la toma de decisiones basadas en el consenso, son sus características; Un paradigma sincrónico, se apoya en partes del problema con poca comunicación activa entre ellos. 25

26 Equipos ágiles La filosofía ágil alienta la satisfacción del cliente y la temprana entrega incremental del software; pequeños equipos de trabajo enormemente motivados; métodos informales; mínimos productos de trabajo de IS; y simplicidad global de desarrollo. Estos equipos (ágiles) son autoorganizados 26

27 Muchos modelos de proceso ágil (por ejemplo, Scrum) brindan al equipo ágil una autonomía significativa para realizar la gestión del proyecto y tomar las decisiones técnicas requeridas para cumplir el trabajo. La planificación se mantiene en el mínimo, y al equipo se le permite seleccionar su propio enfoque, sólo restringido por los requisitos del negocio y estándares organizacionales 27

28 El producto El gestor de un proyecto de software se enfrenta con un dilema desde el principio de un proyecto de IS. Se requieren estimaciones cuantitativas y un plan organizado, pero no dispone de información sólida. En consecuencia, se deben examinar el producto y el problema que se intenta resolver al inicio del proyecto. Se debe establecer y acotar el ámbito del producto. 28

29 Ámbito del software La primera actividad de gestión : Contexto. cómo encaja el software que se desarrollará en el negocio y qué restricciones se imponen?; Objetivos de información. qué objetos de datos se requieren de entrada?; Función y desempeño. qué funciones realiza el software para transformar los datos en salida?. 29

30 Descomposición del problema A veces llamada partición o elaboración del problema, es una actividad de la IR. Durante la actividad de fijación del ámbito no se intenta en descomponer completamente el problema Un problema complejo se divide en problemas menores que resultan más manejables. Ésta es la estrategia que se aplica cuando comienza la planificación del proyecto 30

31 El proceso Las actividades del marco de trabajo que caracterizan al proceso de software son aplicables a todos los proyectos de software. El gestor del proyecto debe decidir cuál modelo de proceso es más adecuado para: 1) Los clientes que solicitaron y personas que realizarán el trabajo; 2) Las características del producto; 3) El ambiente del proyecto. 31

32 Combinación del producto y el proceso La planeación del proyecto comienza con la combinación del producto y el proceso. Cada función que el equipo de software someterá a ingeniería debe pasar a través del conjunto de actividades del marco de trabajo: Comunicación, planificación, modelado, construcción y despliegue. 32

33 Descomposición del proceso La descomposición del proceso comienza cuando el gerente de proyecto pregunta: cómo logramos esta actividad del marco de trabajo? Para un proyecto complejo se puede requerir las siguientes tareas de trabajo para la actividad de comunicación: 1. Revisar la petición del cliente; 2. Planificar reunión formal; 3. Llevar a cabo investigaciones; 33

34 4) Preparar documento de trabajo; 5) Celebrar reunión; 6) Desarrollar y revisar miniprospectos o caso de uso para valorar su corrección; 7) Ensamblar miniprospectos en un documento más amplio; 8) Revisar el documento con implicados; 9) Modificar el documento. 34

35 El proyecto La gestión de un proyecto de software exitoso requiere entender qué puede salir mal. J. Reel, define 10 señales: 1.El personal de software no entiende las necesidades de sus clientes; 2.El ámbito del producto está mal definido; 3.Los cambios se gestionan mal; 4.La tecnología elegida cambia; 35

36 5. Las necesidades comerciales cambian (o están mal definidas); 6. Los plazos de entrega no son realistas; 7. Los usuarios se resisten; 8. Se pierde el patrocinio; 9. El equipo carece de personal con las habilidades apropiadas; 10.Los gestores (y profesionales) evitan las mejores prácticas y las lecciones aprendidas. 36

37 El principio W 5 HH Se necesita un principio organizador que escale hacia abajo para proporcionar planes simples para proyectos simples. Boehm, realiza una serie de preguntas. Por qué se desarrolla el sistema? Qué se hará? Cuándo se hará? Quién es el responsable de una función? 37

38 Dónde están ubicados en la organización? Cómo se hará el trabajo desde los puntos de vista técnico y de gestión? Cuánto de cada recurso se necesita? 38

39 MODULO IV Ingeniería de Software INF METRICAS DE PROCESO Y PROYECTO 14/05/09 Resumen preparado por Miguel Cotaña 39

40 La medición permite obtener una visión del proceso y el proyecto pues proporciona un mecanismo para lograr una evaluación objetiva. La medición se aplica al proceso de software con la finalidad de mejorarlo de manera continua. La medición se utiliza a lo largo de un proyecto de software como apoyo en la estimación, el control de calidad, la valoración de la productividad y el control del proyecto. 40

41 El proceso de software y las métricas del proyecto son medidas cuantitativas que permiten a los IS obtener una visión de la eficacia del proceso de software y los proyectos que llevan a cabo utilizando el proceso como marco de trabajo. Se recopilan datos básicos de calidad y productividad. 41

42 Luego, dichos datos se analizan, comparan con promedios pasados y valoran para determinar si han ocurrido mejoras en la calidad y la productividad. Las métricas también se emplean para marcar las áreas problema de modo que se puedan desarrollar remedios y mejorar el proceso de software. 42

43 Clasificación Clasificación 1: Métricas de producto. Métricas de proceso. Clasificación 2: Métricas basadas en atributos internos del producto: Medidas de estructuración de un programa. Métricas de complejidad. Métricas de cobertura de pruebas. Métricas de calidad del diseño. Métricas basadas en atributos externos del producto: Métricas de portabilidad. Métricas de defectos. Métricas de usabilidad. Métricas de mantenibilidad. Métricas de fiabilidad. 43

44 Métricas basadas en código fuente: Nº de líneas de código. Nº de líneas de comentario. Nº de instrucciones. Densidad de documentación. Métricas basadas en estructura de diseño: Relacionadas con el control intramodular. Relacionadas con el acoplamiento entre clases. Métricas para sistemas orientados a objetos: Acoplamiento. Herencia. Cohesión. 44

45 Se aplica las métricas para valorar la calidad de los productos. Proporcionan una manera sistemática de valorar la calidad basándose en un conjunto de reglas. Se aplican a todo el ciclo de vida permitiendo descubrir y corregir problemas potenciales. 45

46 Los requisitos del Software son la base de las medidas de calidad. La falta de concordancia con los requisitos es una falta de calidad. Unos estándares específicos definen un conjunto de criterios de desarrollo que guían la manera en que se hace la ingeniería del Software. Si no se siguen los criterios, habrá seguramente poca calidad. 46

47 Factores de calidad de McCall Los factores que afectan la calidad se pueden categorizar en: Factores que se pueden medir directamente, como por ejemplo los defectos por punto de función. Factores que se pueden medir sólo indirectamente, como por ejemplo la facilidad de uso o mantenimiento. En todos los casos debe aparecer la medición. Debe ser posible comparar el software (documentos, programas, datos) con una referencia y llegar a una conclusión sobre la calidad. 47

48 Facilidad de mantenimiento Flexibilidad Facilidad de prueba Revisión del Producto Transición del producto Portabilidad Reusabilidad Interoperatividad Operación del producto Corrección Fiabilidad Usabilidad Integridad Eficiencia 48

49 Corrección HACE LO QUE QUIERO? Hasta donde satisface un programa una especificación y logra los objetivos del cliente. Fiabilidad Lo hace de forma fiable todo el tiempo? Hasta donde se puede esperar que un programa lleve a cabo su función pretendida con la exactitud requerida 49

50 Eficiencia Se ejecutará en mi HW lo mejor que se pueda? La cantidad de recursos informáticos y código necesaria para que un programa realice su función. Seguridad Es seguro? Hasta donde se puede controlar el acceso al software o a los datos por personas no autorizadas. 50

51 Usabilidad Es fácil de manejar? El esfuerzo necesario para aprender, operar, preparar datos de entrada e interpretar salidas (resultados) de un programa. Facilidad de mantenimiento Puedo corregirlo? El esfuerzo necesario para localizar y arreglar un error en un programa. 51

52 Flexibilidad Puedo cambiarlo? El esfuerzo necesario para modificar un programa operativo. Facilidad de prueba Puedo probarlo? El esfuerzo necesario para probar un programa y asegurarse de que realiza la función pretendida. 52

53 Portabilidad Podré usarlo en otra máquina? El esfuerzo necesario para transferir el programa de un entorno de sistema de HW y/o SW a otro; Reusabilidad Podré reutilizar alguna parte del SW? Hasta donde se puede volver a emplear un programa (o partes de un programa) en otras aplicaciones; Interoperabilidad Podré hacerlo interactuar con otro sistema? El esfuerzo necesario para acoplar un sistema con otro. 53

54 54

55 Es difícil desarrollar medidas directas de los factores de calidad señalados anteriormente, se definen un conjunto de métricas para desarrollar expresiones que utilicen los factores: Fq = c1 x m1 + c2 x m2 +.+cn x mn Fq es factor de calidad Cn son coeficientes de regresión Mn son las métricas que afectan al factor calidad. 55

56 Lamentablemente muchas de las métricas definidas por McCall solamente pueden medirse de manera subjetiva. Las métricas se acomodan en una lista de comprobación que se emplea para puntuar atributos específicos del software. El esquema de puntuación que se propone es una escala del 0 (bajo) al 10 (alto) 56

57 Factores de calidad de Boehm 57

58 Métricas en los dominios del proceso y el proyecto Las métricas del proceso se recopilan en el curso de todos los proyectos y durante largos periodos. Su objetivo es proporcionar un conjunto de indicadores de proceso que conduzcan a la mejora de los procesos de software a largo plazo 58

59 Las métricas del proyecto permiten que un gestor de proyecto de software: 1) Valore el estado de un proyecto en curso; 2) Rastree los riesgos potenciales; 3) Descubra las áreas problema antes de que se vuelvan críticas ; 4) Ajuste el flujo de trabajo o las tareas; 5) Evalué la habilidad del equipo. 59

60 Métricas del proceso y mejora del proceso Sw La única forma de racional de mejorar cualquier proceso es medir sus atributos específicos, desarrollar un conjunto de métricas significativas con base en dichos atributos y luego emplear las métricas para ofrecer indicadores que conducirán a una estrategia de mejora. 60

61 Producto Características del cliente Condiciones del negocio proceso Personal Entorno de desarrollo Tecnología 61

62 Algunas métricas de proceso son privadas para el equipo del proyecto de software, pero públicas para todos los miembros del equipo. Las métricas públicas por lo general asimilan información que originalmente era privada para los individuos y equipo 62

63 La métricas de proceso de software ofrecen beneficios significativos conforme una organización trabaja en mejor grado global de madurez del proceso. Sin embargo, como todas las métricas, éstas pueden emplearse mal y crear más problemas de los que solucionan 63

64 Grady, sugiere las siguientes reglas: Aplique sentido común y sensibilidad organizativa cuando interprete datos métricos; Ofrezca retroalimentación regular a los individuos y equipos que recopilan medidas y métricas; No utilice las métricas para evaluar a los individuos; 64

65 Trabaje con los profesionales y equipos para establecer metas claras y las métricas que se emplearán para conseguirlas; Nunca use métricas para amenazar a los individuos o equipos; Los datos métricos que indican un área problema no deben considerarse negativos; No obsesionarse con una sola métrica. 65

66 Métricas del proyecto A diferencia de las métricas del proceso de software que se utilizan con propósitos estratégicos, las métricas del proyecto de software son tácticas. Es decir, un gerente de proyecto y un equipo de software emplean las métricas del proyecto y los indicadores que se deducen de ellas para adaptar el flujo de trabajo del proyecto y las actividades técnicas 66

67 La primera aplicación de las métricas del proyecto ocurre durante la estimación. Las métricas recopiladas de los proyectos previos se aprovechan como base desde la cual se realizan estimaciones de esfuerzo y tiempo. Conforme el proyecto avanza, las medidas de esfuerzo y tiempo utilizados se comparan con originales 67

68 Mientras comienza el trabajo técnico, las otras métricas comienzan a tener significado. Se miden los índices de producción representados en términos de modelos creados, hora de revisión, puntos de función y líneas fuente entregadas. Además, se les da seguimiento a los errores descubiertos durante cada tarea de IS. 68

69 Conforme el software evoluciona desde los requisitos hasta el diseño, se recopilan métricas técnicas para valorar la calidad del diseño y mejorar los indicadores que influirán en el enfoque que se adopte para la generación y prueba del código. 69

70 Medición del software Se clasifican en 2 categorías: 1. Medidas directas del proceso de software (costo, esfuerzo aplicados) y del producto (líneas de código, rapidez de ejecución y defectos reportados); 2. Medidas indirectas del producto que influyen funcionalidad, calidad, complejidad, eficiencia, confiabilidad, facilidad de mantenimiento, etc. 70

71 Métricas orientadas al tamaño Las métricas del software orientadas al tamaño preceden de la normalización de las medidas de calidad o productividad considerando el tamaño de software que se ha producido. Si una organización de software mantiene registros simples es factible crear una tabla de medidas orientadas al tamaño. 71

72 Proyecto LDC esfuerzo $ Pag.doc errores defectos personal Beta Alfa Gamma El desarrollo de métricas que se asimilen con métricas similares procedentes de otros proyectos requiere elegir líneas de código con valor de normalización

73 A partir de los datos rudimentarios de la tabla se desarrolla un conjunto de métricas simples orientadas al tamaño para cada proyecto. La métricas orientadas al tamaño no se aceptan universalmente como la forma de medir el proceso del software 73

74 Métricas orientadas a la función Las métricas del software orientadas a la función emplean como un valor de normalización una medida de la funcionalidad que entrega la aplicación. La métrica orientada a la función utilizada con mayor amplitud es el punto de función (PF). El cálculo del PF se basa en características del dominio de información y la complejidad del software 74

75 La métrica del punto de función (PF) se puede utilizar como medio para predecir el tamaño de un sistema obtenido a partir de un modelo de análisis. Para visualizar esta métrica se utiliza un diagrama de flujo de datos, el cual se evalua para determinar las siguientes medidas clave que son necesarias para el cálculo de la métrica de punto de función: 75

76 Número de entradas del usuario; Número de salidas del usuario; Número de consultas del usuario; Número de archivos; Número de interfaces externas. 76

77 La cuenta total debe ajustarse utilizando la siguiente ecuación: PF = c-total x (0,65 + 0,01 x Fi) Donde c-total es la suma de todas las entradas PF obtenidas y Fi (i=1 a 14) son los "valores de ajuste de complejidad". 77

78 Se asume que la Fi es 46 (un producto moderadamente complejo), por consiguiente: PF = 50 x (0,65 + 0,01 x 46) = 56 Factor de ponderación Parámetro de medición Cuenta Simple Media Compl. Número de entradas del usuario 3 X = 9 Número de salidas del usuario 2 X = 8 Número de consultas del usuario 2 X = 6 Número de archivos 1 X = 7 Número de interfaces externas 4 X = 20 Cuenta total 50 Cálculo de puntos de función 78

79 Métricas orientadas a objetos Las métricas de proyectos de software convencionales (LDC o PF) se aplican en la estimación de proyectos de software OO. Sin embargo, estas métricas no proporcionan suficiente granularidad para la planificación y los ajustes de esfuerzo que se requieren conforme se itera a lo largo de un proceso evolutivo o incremental. 79

80 Lorenz y Kidd, sugieren el siguiente conjunto de métricas OO: Número de guiones de escenario. Es una secuencia detallada de pasos que describen la interacción entre el usuario y la aplicación; Número de clases clave. Son los componentes enormemente independientes definidos con antelación en análisis OO; 80

81 Número de clases de apoyo. Es un indicio de la cantidad de esfuerzo indispensable para desarrollar el software, así como un indicio de la cantidad de reutilización; Número promedio de clases de apoyo por clase clave. Las clases clave se conocen en etapas iníciales. Las clases de apoyo se definen a lo largo del curso de éste; Número de subsistemas. 81

82 Métricas orientadas a casos de uso Los casos de uso se define en etapas tempranas del proceso de software, lo que permite emplearlo en la estimación antes de iniciar las actividades significativas de modelado y construcción. Los casos de uso describen (al menos indirectamente) funciones y características visibles al usuario que son requisitos básicos para un sistema 82

83 El caso de uso es independiente del lenguaje de programación. Además, el número de casos de uso es directamente proporcional al tamaño de la aplicación en LDC, así como al número de casos de prueba que tendrán que diseñarse para ejercitar completamente la aplicación. 83

84 Métricas de proyectos de IWeb Entre las medidas que se pueden recopilar son: Número de páginas web estáticas; Número de páginas web dinámicas; Número de vínculos internos de página; Número de objetos de datos persistentes; 84

85 Número de sistemas externos en interfaz; Número de objetos de contenido estático; Número de objetos de contenido dinámico; Número de funciones ejecutables. 85

86 Métricas para calidad del software La meta primordial de la IS es producir un sistema, aplicación o producto de alta calidad dentro de un marco temporal que satisfaga una necesidad del mercado. El logro de esta meta requiere que los IS apliquen métodos eficaces acoplados con herramientas modernas. Además se debe medir si se logrará la alta calidad. 86

87 Se pueden utilizar muchas medidas de calidad, el impulso primario, es medir los errores y defectos. Las métricas derivadas de estas medidas proporcionan un indicio de la efectividad de la garantía de la calidad del software y de las actividades de control tanto de los individuos como del grupo. 87

88 Las métricas como los errores en el producto de trabajo por punto de función, errores descubiertos por hora de revisión de la eficacia de cada una de las actividades implicadas en la métrica. Los datos de error también se pueden emplear en el cálculo de la eficacia en la eliminación de defectos (EED) 88

89 Medición de la calidad Los indicadores útiles para el equipo de proyecto son: Corrección. La medida más común para la corrección es defectos por KLDC, donde un defecto se define como una falta comprobada de concordancia con los requisitos. Cuando se considera la calidad global de un producto, los defectos son los problemas que reporta el usuario después que se liberó. 89

90 Facilidad de mantenimiento. Es la sencillez con la que un programa puede corregirse si se encuentra un error, adaptarse si su entorno cambia, o mejorar si el cliente desea un cambio en los requisitos. No existe forma de medir directamente, por lo que se emplean medidas indirectas. Una simple medida orientada al tiempo es el tiempo medio de cambio (TMC) 90

91 Integridad. Mide la habilidad de un sistema para resistir ataques a su seguridad. La medición de la integridad requiere definir: amenaza y seguridad. La integridad de un sistema se define: Integridad = 1- (amenaza x (1-seguridad)) Si la probabilidad de amenaza es 0.50 y la posibilidad de repeler un ataque es sólo 0.25, la integridad es 0.63 (inaceptablemente baja). 91

92 Facilidad de uso. Con frecuencia, un programa que no es fácil de usar está condenado al fracaso, incluso si las funciones que realiza son valiosas. Es un intento por cuantificar la sencillez de la aplicación al utilizarla y se puede medir en términos de características 92

93 Eficacia en la eliminación de defectos Una métrica de calidad que ofrece beneficios tanto en ámbito del proyecto como en el proceso es la eficacia en la eliminación de defectos (EED). En esencia, la EED es la medida de la habilidad de filtrar las actividades de la garantía de cualidad y de control conforme se aplica a través de las actividades del marco de trabajo. 93

94 Cuando se considera un proyecto como un todo, la EED se define: EED = E/(E+D) E es el número de errores encontrados antes de entregar el software. D es el número de defectos encontrados después de la carga. El valor ideal de la EED es 1 94

95 La EED también se puede aplicar en el proyecto para valorar la habilidad de un equipo de encontrar errores antes de que pasen a la siguiente actividad. Por ejemplo, la tarea de análisis de requisitos produce un modelo de análisis que se revisa para encontrar y corregir errores. Si no se encuentran errores pasan al diseño. 95

96 Cuando se aplica en este contexto la EED se redefine como: EED i = Ei/(E i +D i+1 ) E i es el número de errores encontrados durante la actividad i de la IS. E i+1 es el número de errores encontrados durante la actividad i+1 de IS que se puede seguir para llegar a errores que no fueron descubiertos en la actividad i de IS 96

97 Integración de las métricas dentro del proceso de Sw La mayoría de los desarrolladores de software todavía no miden y, lamentablemente, muchos tienen poco deseo de comenzar. El problema es cultural!!! 97

98 Argumentos para las métricas del software Si no se mide, no existe una forma real de determinar si se está mejorando. Y si no se mejora, se está perdido. Si se emplea la medición para establecer una línea base del proyecto, cada uno de los temas: desarrollar estimaciones de proyecto significativas, producir sistemas de calidad, tener el producto a tiempo, se vuelven más manejables. 98

99 Establecimiento de una línea base Los datos de la línea base deben tener los siguientes atributos: Los datos deben ser razonablemente precisos; Los datos deben recopilarse para tantos proyectos como sea posible; Las medidas deben ser consistentes; Las aplicaciones deben ser similares al trabajo que se estimará. 99

100 Recopilación, cálculo y evaluación de métricas La recopilación de datos requiere una investigación histórica de los proyectos previos para reconstruir los datos requeridos Proceso de IS Proyecto Recopilacion medidas de SW de datos Cálculo de métricas Producto métricas Evaluación de SW Métricas indicadores 100