Cuadro comparativo de normas para evaluar la calidad de sftware

NORMAS  MODELOS

CARACTERISTICA

DIFERENCIAS

VENTAJAS

DESVENTAJAS

MALCOLM BALDRIGE

Esta herramienta es para la evaluación, mejora y planificación de la gestión de calidad total de una empresa.

Tiene un aumento en la productividad, y en la participación en el mercado.

Conlleva demasiado tiempo y esfuerzo para desarrollarlo.

SPICE

Posee un marco para los requisitos de evaluación de procesos.

Trabaja en niveles de madurez en la organización: Inmadura, básica, gestiona, establecida, predictible y optimizada.

Establece una base para ser evaluada, con resultados repetibles.

Minimiza las diferencias de los resultados.

Se relaciona con ISO/IEC 12207/08 y es muy apta para las PYMES.

Se requiere de un gran trabajo para implantar las evaluaciones, resultando más caro para percibir alguna estrategia de mejorar el proceso.

DEMING

Se comprueba que, mediante la implantación del control de calidad, se obtengan buenos resultados.

Ve la producción como un sistema para mejorar la calidad en la línea de la producción desde la materia prima hasta el más importante que es el consumidor.

Estabiliza y mejora la calidad, la productividad, reduce costos, incrementa las ventas.

Enmarca diferentes sistemas de dirección.

Utiliza mucho tiempo en el desarrollo de evaluación.

LA

EXCELENCIA DE EFQM

Se basa en los principios de la Gestión de la Calidad Total y fundamenta su desarrollo en la autoevaluación de las organizaciones como método de mejora continua.

Establece puntos fuertes y las áreas a mejorar en la organización.

Evalúa en hechos y no en percepciones subjetivas.

Se puede comparar con resultados de otras organizaciones

Favorece la gestión por procesos y permite hacer un diagnóstico sobre su evolución.

No tiene completa facilidad de actualización.

Contiene cierto grado de dificultad de comprensión y cierto nivel de complejidad.

SHINGO PRIZE

Identifica la evolución de una compañía que atraviesa por una transformación y para apoyar a los directivos a detectar en dónde se encuentran sus compañías en su jornada, y evaluar el nivel de profundidad y entendimiento de esta filosofía dentro de su empresa.

Asegura la calidad en la fuente, adoptando el pensamiento científico, centrado en su proceso, pensando sistemáticamente.

Su proceso de aplicación de este modelo es complejo.

DIRECCIÓN POR CALIDAD

Fomenta y promueve la competitividad, comunicación y el intercambio en las organizaciones.

Su cultura es basada en la mejora continua y la creación de valor a clientes y usuarios finales, personal, accionistas, comunidad y entorno.

Se eleva la efectividad y la eficiencia.

Crea el valor para los productos o servicios ofrecidos.

Se necesita de un gran esfuerzo para implantar las evaluaciones.

DESARROLLO EN ESPIRAL

Las actividades se conforman en una espiral en la que cada bucle o iteración representa un conjunto de actividades.

En cada iteración se toma en cuenta los objetivos, alternativas el desarrollo y verificación del software.

Tiene una reducción de riesgos del proyecto, incorporando objetivos de calidad.

Relaciona el desarrollo con el mantenimiento.

Gasta mucho tiempo en el desarrollo del sistema.

Es un modelo costoso.

Requiere experiencia en la identificación de riesgos.

CMMI

1984

Fue desarrollado Software Engineering Institute (SEI) perteneciente a Carnegie Mellon University

Son normas para calidad enfocada al mundo del Software, aplicables a los diferentes procesos que hay que llevar a cabo para lograr producir software con calidad, es muy importante mencionar que igual que las normas ISO 90003, este modelo nos dice que hay que hacer, y no como hay que hacerlo.

Describe los componentes del modelo y sus relaciones.

Comprende las áreas de proceso.

Localiza información relevante en el modelo.

Utiliza niveles jerárquicos.

Aplica los conocimientos a su entorno de trabajo y en un equipo de evaluación de componentes y sus relaciones de un modelo.

Estudia los procesos de desarrollo de software de una organización.

Produce una evaluación de la madurez de la organización según una escala de 5 niveles, con el objetivo de establecer una guía que les permita mejorar sus procesos y su habilidad para organizar, desarrollar, adquirir y mantener productos y servicios informáticos.

Mejora el gran impacto en procesos de desarrollo de productos software, tales como reducción del coste de desarrollo, localización y resolución de defectos; mejora en la fiabilidad de la planificación, en términos de dedicación y de calendario.

Aumenta la productividad y la efectividad sobre la planificación

Reducción de los trabajos derivados de correcciones tras las fases de pruebas.

Método evolucionado y flexible. Compatible con la norma ISO/IEC 15504.

Mejor organización interna y homogeneización en procesos de actuación

Mejora de la imagen de la marca..

No posee adecuación al enfoque a servicio que está experimentando el sector de las TI en todas sus líneas de actividad, así como el alto esfuerzo de implantación que exige.

Costo alto para la preparación y el soporte, también lo es la valoración del modelo.

Proceso de valoración pesado y lento.

Se utiliza para empresas grandes.

Tamaño y complejidad mucho mayor que modelos vigentes.

La complejidad de la evaluación continua puede atentar contra la definición de objetivos concretos de madurez.

FURPS

Robert Grady y

Hewlett Packard Co (HP) 1987.

[pic 1]

Tiene 5 características de las cuales se deriva su nombre;

Funcionalidad.

Facilidad de Uso.

Confiabilidad.

Desempeño.

Facilidad de Soporte.

Los requisitos se clasifican en dos categorías:

Requisitos funcionales (F): que son los que especifican funciones que el sistema debe ser capaz de realizar sin tener en cuenta las restricciones físicas.

Requerimientos no funcionales (URPS): que puntualizan atributos del sistema o del medio ambiente del sistema.

Contempla las fallas en el producto y en el proceso, esto permite una mayor corrección.

Se podría utilizar no para uno sino para varios proyectos.

Los criterios son claramente entendibles, lo que implica su fácil utilización.

En cierta forma su división en factores funcionales y no funcionales es convenientes para determinar la calidad, aun así, hayan restricciones físicas.

Se requiere de muchas métricas, esto  implica un mayor esfuerzo de tiempo y costo.

BOEHM

Barry Boehm (1978)

[pic 2]

Define la calidad de software en términos de atributos cualitativos y los mide usando métricas.

El modelo no es muy distinto al de McCall, porque muchos de sus factores de calidad son los mismos. Éste modelo también presenta sus factores de calidad estructurados jerárquicamente de alto a bajo nivel.

El modelo se basa en que el software debe:

Hacer lo que el usuario quiere que haga.

Utilizar los recursos de la computadora correcta y eficientemente.

Ser fácil de usar y de aprender para los usuarios.

Estar bien diseñado, bien codificado y ser probado y mantenido fácilmente.

Este modelo introduce características de alto nivel, de nivel intermedio que se constituyen en los factores de calidad, y las características primitivas, cada una de las cuales contribuyen al nivel general de calidad.

Está fundamentado en modelo ISO 9000 y CMMi

No requiere esfuerzo adicional para mejorar y obtener una certificación en ISO 9000. 

Las mejoras al SW se hacen por medio de ciclos de espiral partiendo desde el centro.

En cada ciclo analiza objetivos, alternativas (características, formas de gestión, riesgo asumido) y desarrollo y verificación.

Conjuga lo interactivo del modelo MCP con lo sistemático del Modelo Cascada.

Tiene pocas desventajas.

Aunque no especifica muchos aspectos relacionados con el usuario

Bootstrap.

ESPRIT

5441 BOOTSTRAP

Su principio es reducir costos y mejorar la calidad previendo problemas.

El objetivo es desarrollar un método para la evaluación de procesos de desarrollo de software (SW).

Al comienzo se basó en el modelo de madurez de CMM añadiendo conceptos de calidad de ISO 9000.

Es un modelo robusto, completo en lo concerniente a la estructura. Arquitectura, la descomposición en procesos detallados ofrece un buen marco para la evaluación de procesos.

Su proceso de mejora está muy claro a la hora de aplicarlo. Usa una base de datos global que es beneficioso para la comunicación.

Engloba tanto la evaluación para establecer el diagnóstico de un proceso para desarrollo de software, el cual incluye la organización, los métodos y la capacidad de ingeniería, las herramientas y la tecnología, como la creación de un plan de acción que defina los pasos, los detalles de la implantación y los marcos temporales para que la organización aumente su capacidad de entrega de productos y servicios de calidad.

La metodología tiene una gran ventaja, compara los resultados de la evaluación con los resultados de sus competidores.

Parece que da un gran resultado cuando prioriza qué necesidades se deben mejorar primero.

 Comenzó a implementarse principalmente en Europa.

Incompleto en comparación con otros modelos.

Le falta un poco más de atención en lo que se refiere a la satisfacción del cliente.

No tiene herramientas de terceras partes accesibles para los usuarios.

McCALL.

McCall, Richards y Walters,

(1977)

[pic 3]

Este fue presentado en 1977, y se originó motivado por US Air Force y DoD.

Organiza los factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar la calidad de un producto, basándose en once factores de calidad organizados en torno a los tres ejes y a su vez cada factor se desglosa en otros criterios.

Analiza la calidad como un concepto elaborado mediante relaciones jerárquicas entre factores de calidad, en base a criterios y métricas de calidad.

Su finalidad, atender a las diversas necesidades de las organizaciones que quieren realizar la mejora de sus procesos.

Posee 2 enfoques:

El Continuo: hace hincapié en la capacidad de ciertas áreas para realizar sus actividades de manera adecuada.

El Escalonado: hace especial énfasis en el grado de madurez de los procesos (a semejanza del SW-CMM).

Práctico y fácil de entender y de esta forma fácil de aplicar, esto debido a su estructura jerárquica.

Descubre atributos claves desde el punto de vista del usuario.

Se focaliza en el producto final y en medidas precisas de alto nivel.

Está orientado al producto final, pero, se puede aplicar al proceso.

Se puede utilizar para varios proyectos al mismo tiempo.

En costos resulta viable es de gran ayuda para cualquier organización.

posee en general propiedades abstractas medibles mediante métricas, lo cual iimplica un trabajo tedioso por la cantidad de métricas que se utilizarían.

Implica un trabajo adicional al proceso, debido a que se evalúan muchos factores.

No siempre existe una relación perfectamente lineal entre los valores de las métricas y las características que deben estimar.

GILB

Plantea la creación de una especificación de requisitos de calidad para cada proyecto que deben escribir conjuntamente el usuario y el analista. Es un modelo que permite determinar una lista de características que definen la calidad de la aplicación.

Puede ser de 2 tipos:

(1) Originales

2) de modelos tradicionales.

estas se pueden medir mediante varias subcaracterísticas o métricas detalladas. Para cada una de ellas, se deben especificar los siguientes conceptos:  nombre y definición de la característica, escala o unidades de medición, recopilación de datos o prueba, valor previsto, valor óptimo,  valor en el sistema actual y comentarios.

características de calidad:

corrección, facilidad de mantenimiento, integridad y facilidad de uso.

Contiene una relación directa entre los desarrolladores y el usuario.

Hay relación directa entre atributos y sub-atributos.

Se puede especificar los atributos de la calidad del software cuantitativamente.

Como se evalúan muchos factores esto provoca un mayor trabajo en tiempos y costos.