Capitulo 1 CALIDAD

1. Capitulo 1CALIDAD

2. ¿Qué es la Calidad? • (Existe más de una decena de definiciones de Calidad) • Conjunto de propiedades y carácterísticas de un producto o servicio, que le confieren aptitud para satisfacer una serie de necesidades explícitas o implícitas. (ISO 8402) • El conjunto de actividades encaminadas a descubrir y satisfacerlas necesidades de un colectivo o de una sociedad en general.Satisfacción del cliente y conformidad con sus requisitos y necesidades.

3. Tipos de Calidad • Necesaria  Calidad que pide el cliente y la que le gustaría recibir. • Programada Es el nivel de calidad que se propone obtener el fabricante. • Realizada  Es la calidad que se puede obtener debido a las personas que realizan el trabajo o a los medios utilizados Se relacionan entre si

4. Características de la calidad del SW • Funcionalidad • Fiabilidad • Facilidad de uso • Eficiencia • Mantenimiento • Movilidad

5. Decálogo de la calidad Los 10 principios considerados basicos de la calidad son: • I -La calidad la definen los clientes. • II -El proceso de calidad se inicia con el liderazgo activo de la Alta Dirección. • III -La calidad es un factor estratégico de competitividad y diferenciación. • IV -La calidad efectiva es garantía de rentabilidad sostenida. • V -La calidad involucra a todos los miembros de la organización. • VI -La calidad involucra a los proveedores. • VII -La calidad debe ser el criterio que configure todos los sistemas y procesos de la empresa. • VIII -La calidad debe comunicarse. • IX -Calidad implica sensibilidad y preocupación de la empresa por su entorno social y medioambiental. • X -La calidad es dinámica.

6. Evolución de la calidad La calidad ha pasado por diferentes etapas desde su desarrollo hasta el momento actual: • Inspección • Control de Calidad • Aseguramiento de Calidad • Gestión de la Calidad Total

7. Inspección (Revolución industrial - 1930 ) • En 1900  Surge el Supervisor, quién asumía la responsabilidad de la calidad del trabajo. • Primer Guerra Mundial (1914 – 1918)  Surgen los inspectores de calidad. Se crear áreas de Inspección separadas de las de producción. Interés principal  detección de los productos defectuosos para separarlos de los aptos para la venta

8. Inspección (Revolución industrial - 1930 ) Características: • La responsabilidad de la consecución de calidad es del departamento de inspección. • La calidad se comprueba. • El papel del profesional de calidad es: inspección, clasificación, conteo y medición. • La visión de calidad es un problema a resolver. • Emplea métodos de fijación de estándares y medición.

9. Control de Calidad (1930 - 1949) • Segunda Guerra Mundial (1939 – 1945)  Nace el control estadístico de la calidad. • Se introduce la inspección por muestreo, en lugar de la inspección al 100 por ciento. • La orientación y enfoque de la calidad pasa de la calidad que se inspecciona a la calidad que se controla Interés principal  que el control garantice no sólo conocer y seleccionar los desperfectos o fallas de productos, sino también la toma de acción correctiva sobre los procesos tecnológicos.

10. Control de Calidad (1930 - 1949) Características: • La responsabilidad de la consecución de calidad es de los departamentos de calidad y de los inspectores. • La calidad se controla. • El papel del profesional de calidad es: la resolución de problemas y aplicación de métodos estadísticos. • La visión de calidad sigue siendo un problema a resolver. • Sus métodos son herramientas y técnicas estadísticas. • Su alcance se relaciona exclusivamente con el producto final.

11. Aseguramiento de la Calidad (1950 - 1980 ) • Del control estadístico de la calidad se pasa a la gestión de la misma. • Se aplican estándares a los sistemas de calidad para procesos. Interés principal  que exista un sistema de calidad documentado con procedimientos e instrucciones técnicas.

12. Aseguramiento de la Calidad (1950 - 1980 ) Características: • Su alcance se limita al proceso de producción y procesos de apoyo. • Sus referencias escritas son normas ISO u otras de ese tipo • La formación es especifica. • La reducción de costes no es un objetivo directo.

13. Gestión Total de la Calidad (1990 - Actual ) • Esta gestión no se basa en normas sino en Modelos. Se busca aplicar los estándares a todas las áreas de la empresa, no solo a la producción del producto. Interés principal  que se logre un impacto estratégico poniendo énfasis en los clientes

14. Gestión Total de la Calidad (1990 - Actual ) Características: • La calidad pasa a ser una ventaja competitiva. • La responsabilidad es de todos. • Se controla los gastos. • Ampliación de las referencias escritas. • Se busca la Calidad Concertada.

15. Resumen

16. Para mejorar la calidad del producto y del servicio como variable del negocio. El cliente va a estar dispuesto a pagar más por un producto de calidad sobresaliente. Sirven para medir el desempeño y facilitan las actitudes de mejoramiento de los empleados de todos los niveles de la empresa Proporcionan los medios para planificar y controlar los costos de la calidad futuros Costos de Calidad - ¿Para qué?

17. Prevención y verificación (INVERSIONES) Costos de Verificación: Son los costos de medir, evaluar, ensayar y auditar el producto – servicio, para asegurar su conformidad con las especificaciones de calidad antes de la entrega a los clientes. Costos de Prevención: Son los costos de todas las actividades específicamente destinadas a prevenir la ocurrencia de defectos en el producto (o servicio), desde la concepción hasta la garantía de post venta Costos de No Calidad (PÉRDIDAS) Costos de Falla Internas: son los detectados antes de transferir el producto al cliente o antes de prestar el servicio. Costos de Falla Externas: son los detectados después de transferir el producto al cliente o prestar el servicio Costos de Calidad - Tipos

18. 1 : Detectar y arreglar problemas en el área de trabajo 10 : Detectar y arreglar problemas una vez que han salido del área de trabajo 100 : Reparar problemas detectados por el usuario externo Costos de Calidad

19. Capitulo 5METRICAS

20. Métricas Orientas a Objetos • Aparecieron por la necesidad de poder cuantificar la calidad del software no tradicional. • El software orientado a objetos posee características conceptuales que al no respetarlas pueden afectar la calidad del producto. • Hay distintos tipos de MOO, como por ejemplo: • Métricas orientadas a clases • Métricas orientadas a operaciones • Métricas para pruebas orientadas a objetos • Métricas para proyectos orientados a objetos

21. Métricas orientadas a Clase Algunos métodos de este tipo de métricas son: • Métodos ponderados por clase (C&K) • Árbol de profundidad de herencia (C&K) • Número de Descendientes (C&K) • Tamaño de Clase (Lorenz y Kidd) • Índice de Especialización (Lorenz y Kidd)

22. Métricas orientadas a Clase Número de Descendientes (C&K) Mide la calidad de la clase según la cantidad de descendientes que ésta tenga. Utiliza como base para la determinación de la calidad, el concepto de que si bien los descendientes indican reutilización, una cantidad elevada de descendientes puede diluir la abstracción utilizada para la creación de la súper clase. Árbol de profundidad de herencia (C&K) Se plantea sobre el árbol de herencia y mide la distancia desde el nodo hasta la hoja más lejana. Busca medir el grado de herencia que esta fuertemente a la reutilización. Sin embargo, altos niveles de herencia pueden traer problemas como la complejidad en el diseño y objetos difíciles de testear.

23. Métricas orientadas a Clase Árbol de profundidad de herencia

24. Métricas orientadas a Clase Índice de Especialización (Lorenz y Kidd) Mide el grado de especialización de una clase planteando una relación entre la cantidad de métodos de una clase realizando el siguiente cálculo: IES = N° de operaciones redefinidas * nivel de jerarquía de clase N° total de métodos Tamaño de Clase (Lorenz y Kidd) Busca medir el tamaño de clase sumarizando la cantidad de operaciones y atributos. Una clase grande indica alta responsabilidad para la clase y baja reutilización.

25. Métricas orientadas a operaciones • Existen menor cantidad de métricas de este tipo por el hecho de que son las clases las que preponderan en el software OO. • Tamaño medio de operación • Complejidad de operación • Número Medio de Parámetros por operación • Tamaño medio de operación (Lorenz y Kidd) • La cantidad de líneas de código no son una buena unidad de medida para determinar la calidad de una operación, por lo tanto para determinar ésta se persigue la contabilización de mensajes. Muchos mensajes evidencian un alto grado de responsabilidad por parte de la operación lo cual no es aconsejable.

26. Métricas orientadas a operaciones Complejidad de operación (Lorenz y Kidd) En este caso puede utilizarse cualquier métrica existente para el software tradicional debido a que esta medición no se ve relacionada con el paradigma de la POO. Número Medio de Parámetros por operación Tan largo como sea el número de parámetros de operación, más compleja será la colaboración entre objetos

27. Métricas orientadas a objetos Se agrupan según características de diseño importantes Encapsulamiento Porcentaje público y protegido Esta métrica indica el porcentaje de atributos de una clase que son públicos. Valores altos para PPP incrementan la probabilidad de efectos colaterales entre clases. Acceso público a miembros Indica el número de clases (o métodos) que pueden acceder a los atributos de otras clases, una violación de encapsulación. Valores altos para APD producen potencialmente efectos colaterales entre clases.

28. Métricas orientadas a objetos Herencia Número de Clases Raíz Recuento de las distintas jerarquías de clases, que se describen en el modelo de diseño. A medida que el NCR se incrementa, el esfuerzo de comprobación también. Número de Padres Directos Es una indicación de herencia múltiple. NPD > 1 indica que la clase hereda sus atributos y operaciones de más de una clase raíz. Se debe evitar que NPD > 1 tanto como sea posible.

29. Métricas para proyectos orientados a objetos • Le otorgan al jefe de proyecto una visión interna adicional sobre el progreso de su proyecto • Número de escenario • Número de clases clave • Número de subsistemas • Número de escenario • Es directamente proporcional al número de clases requeridas para cubrir los requisitos, el número de estados para cada clase, el número de métodos, atributos y colaboraciones.

30. Métricas para proyectos orientados a objetos Número de clases clave Las clases claves son aquellas dedicadas al dominio del negocio y siendo su implementación más dedicada y su factor de reutilización menor. Este tipo de clases deberá estar entre en 20 y el 40 % frente al total de las clases. Número de subsistemas Da una visión sobre la asignación de recursos, la planificación y el esfuerzo de integración global. Pueden aplicarse sobre proyectos pasados para estimar proyectos actuales.

31. Metricas Conceptuales Tradicionales.

32. Metricas orientadas a Operaciones: Hacen gran hincapié en el tamaño y complejidad de las operaciones individuales, pero se centra principalmente en el nivel de la clase por ejemplo aca tenemos tres metricas muy sencillas: 1.   Tamaño medio de operación: es el numero de mensajes enviados por la operación, ya que a medida que crecen los mensajes  es posible que su responsabilidad no haya sido bien asignada  dentro de la clase. 2.    Complejidad de la operación las operaciones deben limitarse a una responsabilidad especifica es decir mantener  baja la complejidad de operaciones. 3.    Numero medio de parámetros por operaciones:  entre mas grande es el numero de parámetros de la operación mas será la colaboración entre objetos.

33. Metricas O.O. Ejemplo de metodos ponderados por clase (MPC): Primero se definen métodos de complejidad C1, C2..., Cn, para una clase C. La métrica de complejidad específica que se selecciona debe de normalizarse de tal modo que la complejidad nominal para un método tome el valor 1.0. MPC = Ó Ci para i = 1 hasta n El número de métodos y su complejidad es un indicador razonable de la cantidad de esfuerzo necesaria para implementar y comprobar una clase. Además, cuanto mayor sea el número de métodos, más complejo será el árbol de herencia, (todas las subclases heredan el método de sus predecesores). Finalmente, a medida que el número de métodos crece para una clase dada; es más probable que se vuelva cada vez más específico de la aplicación, imitando por tanto su potencial de reutilización. Por todas estas razones, MPC debería de mantener un valor tan bajo como sea razonable.

34. Metricas para Proyectos OO De forma mas general podemos definir un ejemplo para proyectos orientados a objetos: Estas métricas hacen mucho hincapié en el encapsulamiento, la herencia, complejidad de clases  y polimorfismo como anteriormente se ha dicho además de poder aportar ideas acerca del tamaño del software por ejemplo: * Definir el numero de guiones de escenario:  el numero de casos practicos debe ser proporcional  al numero de clases necesarias para satisfacer los requerimientos * Definir el numero de clases claves. Ademas debo tener en cuenta el numero de subsitemas para dar una idea general de cómo deben distribuirse los recursos y esfuerzo de globalización.

35. Metricas orientadas al tamaño. Es para saber en que tiempo voy a terminar el software y cuantas personas voy a necesitar. Son medidas directas al software y el proceso por el cual se desarrolla, si una organización de software mantiene registros sencillos, se puede crear una tabla de datos orientados al tamaño como se muestra en la siguiente figura: Productividad = KLDC/persona-mes Calidad = errores/KLDC Documentación = pags. Doc/ KLDC Costo = $/KLDC

36. Modelos de métricas tradicionales Métricas de Estructura: Este grupo englobaría las medidas tradicionales para evaluar la estructura interna de un sistema desarrollado con aspectos: flujo de control, flujo de datos y estructura de los datos. Modelo de flujo de control y de datos. Medidas jerarquicas. Los aspectos al ser piezas de código no muy extensas son unos buenos candidatos de ser medidos con la Complejidad Ciclomática de McCabe.

37. Debido a la separación de los distintos aspectos que intervienen en un sistemas mediante su modularización en aspectos software, el DSOA supone un cambio importante en la estructura del sistema, y en el flujo de información entre sus elementos internos (objetos y aspectos, o componentes y aspectos). Por tanto, creemos que las medidas de modularidad y atributos del flujo de información cobran especial relevancia en este caso: Cohesión Acoplamiento. Modularidad global Morfología e “impurezas” del árbol Reutilización interna Flujo de Información De especial interés en este grupo estarían las métricas de acoplamiento que permitan evaluar la Dificultad de Composición de aspectos individuales. Esto influiría tanto en su facilidad de uso como en su mantenimiento y en el del sistema.

38. Métricas Externas: Dentro de este grupo se integran aquellas medidas sobre aspectos software, considerándolos como cajas negras, es decir, sólo observando su interfaz y sin atender a su estructura interna. Ejemplos de tales métricas podían ser el número de invocaciones que recibe un aspecto, o el número de puntos (hot spot) desde donde se invoca.

39. Métricas Necesidad de las métricas • Históricamente: carácterísticas cualitativas Confiabilidad / Facilidad de uso / Facilidad de cambio Sin noción de un nivel de calidad efectivo (Moody) • Más recientemente [~1995]: medidas cuantificables Representativas de las entidades que miden Rango de valores: escala ordinal / escala de ratio (Zuse) Objetivas, valor independiente de quién lo mide Relación entre el nivel medido y un ideal Se consolidan para determinar los ‘Factores de Calidad’

40. Métricas Definición y utilización • Validación teórica que mida correctamente el atributo • Validación empírica: que la medida sea útil que tenga la relación esperada con otras variables • Existen modelos estándar de calidad GQM (Goal Question Metrics) / QMS (Quality Management System) Definen Factores y Métricas globalmente aceptados

41. Métricas Tipos de métricas (Kitchenham) • Tipificación y validación teórica • Directas No dependen de otras (Nro. de defectos, Duración de un proceso) Miden atributos que deben ser perfectamente identificables entre sí La métrica debe cumplir la condición de representación Cada unidad que contribuye en la medida debe ser equivalente Diferentes entidades pueden tener el mismo valor

42. Métricas Tipos de métricas (Kitchenham) • Indirectas Se calculan a partir de otras (Tasa Error = Nro. Defectos / Longitud) Requiere relaciones entre atributos explicitamente definidas (relacionando atributos internos y externos) Modelo de medición dimensionalmente consistente Sin discontinuidad (que siempre estén definidos sus componentes) Correcta definición de unidades y escalas (según sus componentes)

43. Métricas Ejemplo: Definición de métricas • Medición del factor ‘Funcionalidad’ • Escalas de ratio simplificada Solo utilizaremos los valores 0 y 1 • Métricas definidas m1. Todas las referencias son no ambiguas (input,funcion,output). m2. Todas las referencias a datos están definidas, calculadas u obtenidas de una fuente externa. m3. Todas las funciones definidas son utilizadas. m4. Todas las funciones referenciadas están definidas. m5. Todas las condiciones están definidas para cada punto de decisión. m6. Todo lo definido y referenciado al llamar una secuencia de parámetros concuerda. m7. Todos los problemas reportados están resueltos. m8. El diseño concuerda con los requerimientos. m9. El código concuerda con el diseño.

44. Métricas Ejemplo: Definición de métricas • Ponderación de las métricas Para este caso todas tienen el mismo peso relativo Funcionalidad = S mi / 9 • Resultado Nivel de calidad del factor funcionalidad Valor entre 0 y 1

45. Integrantes • Marina Gallegos • Macarena Ramallo Palisa • Juan Pablo Cordone Roselló • Maximiliano Romero • Fernando Simoes • Emiliano Schiano Di cola • Fernanda Solans • Andrés Achiary