Capitulo 1 CALIDAD

Post on 30-Dec-2015

64 views 4 download

description

Capitulo 1 CALIDAD. ¿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) - PowerPoint PPT Presentation

Transcript of Capitulo 1 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.

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

Funcionalidad

Fiabilidad

Facilidad de uso

Eficiencia

Mantenimiento Movilidad

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.

Inspección

Control de Calidad

Aseguramiento de Calidad

Gestión de la Calidad Total

La calidad ha pasado por diferentes etapas desde su desarrollo hasta el momento actual:

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

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.

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.

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.

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.

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.

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

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.

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

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

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

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

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)

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.

Árbol de profundidad de herencia

Í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 claseN° 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.

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ónComplejidad de operaciónNú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.

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ónTan largo como sea el número de parámetros de operación, más compleja será la colaboración entre objetos

Se agrupan según características de diseño importantes

Encapsulamiento

Porcentaje público y protegidoEsta 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 miembrosIndica 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.

Herencia

Número de Clases RaízRecuento 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 DirectosEs 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.

Le otorgan al jefe de proyecto una visión interna adicional sobre el progreso de su proyecto

Número de escenarioNúmero de clases claveNú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.

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.

Autores

Enfoque

Ámbito

Objetiva/ Subjetiva

Validación Teórica

Validación Empírica

Herramienta

Kesh (1995)

Ontologico y de comportamiento

Modelo ER

Objetivas y Subjetivas

NO NO NO

Moody (1998)

Varios factores de Calidad

Modelo ER

Objetivas y Subjetivas

NO NO NO

Piattini (2000)

Complejidad

Modelo ER

Objetivas SI Parcial SI

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.

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 = Ó Cipara i = 1 hasta nEl número de métodos y su complejidad es un indicador razonable de lacantidad 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.

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.

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 puedecrear una tabla de datos orientados al tamaño como se muestra en la siguiente figura:

Productividad = KLDC/persona-mesCalidad = errores/KLDCDocumentación = pags. Doc/ KLDCCosto = $/KLDC

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.

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ónAcoplamiento.Modularidad globalMorfología e “impurezas” del árbolReutilización internaFlujo de InformaciónDe 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.

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.

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 cuantificablesRepresentativas de las entidades que miden

Rango de valores: escala ordinal / escala de ratio (Zuse)Objetivas, valor independiente de quién lo mideRelación entre el nivel medido y un idealSe consolidan para determinar los ‘Factores de Calidad’

Definición y utilización Validación teórica

que mida correctamente el atributo

Validación empírica: que la medida sea útilque tenga la relación esperada con otras variables

Existen modelos estándar de calidadGQM (Goal Question Metrics) / QMS (Quality Management System)Definen Factores y Métricas globalmente aceptados

Tipos de métricas (Kitchenham) Tipificación y validación teórica

DirectasNo 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ónCada unidad que contribuye en la medida debe ser equivalenteDiferentes entidades pueden tener el mismo valor

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 consistenteSin discontinuidad (que siempre estén definidos sus componentes)Correcta definición de unidades y escalas (según sus componentes)

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.

Ejemplo: Definición de métricas

Ponderación de las métricasPara este caso todas tienen el mismo peso relativoFuncionalidad = S mi / 9

ResultadoNivel de calidad del factor funcionalidadValor entre 0 y 1

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

Integrantes