Control de Calidad Del Software

MODELOS DE CALIDAD DE SOFTWARE

“Año de la Integración Nacional y el Reconocimiento de Nuestra Diversidad”

UNIVERSIDAD NACIONAL “SAN LUIS GONZAGA DE ICA”

TEMA :

CURSO

:

CONTROL DE CALIDAD DE SOFTWARE

INTEGRANTES

:

Bautista Quispe Leydi Chaico Lebanoandrea Gavilan Pecho Luisa Guillen Martinez Margoth Mandujano Bendezú Alexander Marca Juarez Mayda

CICLO

:

VIII

DOCENTE

:

Antonio Alonso Morales Loaiza

ICA – PERU 2012

1


ÍNDICE Índice De Tablas Y Figuras …………………………………………………………………………………… Introducción …………………….…………………………………………………………………………………. 1. Modelo ………………………………………………………………………………………………………… 2. Modelos De Calidad..……………………………………………………………………………………. 3. Modelos De Calidad De Software………………………………………………………………….

(4) (5) (6) (6) (6)

3.1. Ventajas De Los Modelos De Calidad De Software …………………………………………. 3.2. Pasos Para El Uso De Un Modelo De Calidad Del Software …………………………….. 3.2.1. Principio Del Proyecto ……………………………………………………………………….

(7) (7)

4.

5.

6.

3.2.2. Durante El Proyecto …………………………………………………………………….….. 3.2.3. Final Del Proyecto ……………………………………………………………………........ Estructura De Los Modelos De Calidad De Software …………………………………….. 4.1. Factores De Calidad ……………………………………………………………………………….... 4.2. Criterios De Calidad ………………………………………………………………………………….. 4.3. Métricas …………………………………………………………………………………………………. Tipos De Modelos De Calidad De Software………………………………………………….. 5.1. Tipos De Modelos De Calidad De Producto………………………………………………….. 5.1.1. Modelos Fijos………………………………………………………………………………….. 5.1.2. Modelos De Calidad A Medida……………………………………………………………. 5.1.3. Modelos Mixtos……………………………………………………………………………….. Modelos De Calidad De Software………………………………………………………………….. 6.1. Modelo De Mccall…………………………………………………………………………………………… 6.1.1. Perspectivas Para Definir E Identificar La Calidad De Un Producto Software

6.1.2. Factores De Calidad………………………………………………………………………….. I. Factores De Revisión………………………………………………………………….. II. Factores De Transición……………………………………………………………….. III. Factores De Operación ……………………………………………………………….. 6.1.3. Criterios De Calidad ………………………………………………………………………….. 6.1.4. Métricas De Calidad ………………………………………………………………………….. 6.2. Modelo De Boehm…………………………………………………………………………………………… 6.2.1. Características De Alto Nivel …………………………………………………………….. 6.2.2. Características De Nivel Intermedio …………………………………………………… 6.2.3. Características Primitivas …………………………………………………………………. 6.2.4. Comparación De Modelos Mccall – Boehm …………………………………………. 6.2.5. Evaluación De Modelos Mccall – Boehm …………………………………………….. 6.3. Modelo Arthur ………………………………………………………………………………………….. 6.4. Modelo FURPS …………………………………………………………………………………………...

(7) (9) (10) (10) (10) (10) (11) (11) (11) (11) (12) (12) (13) (14) (14) (14) (14) (14) (15) (15) (20) (20) (21) (21) (21) (23) (23) (24) (24) 2


6.5. Modelo Gilb …………………………………………………………………………………………….

(25) 6.6. Modelo Deutsch ………………………………………………………………………………………. (26) 6.6.1. Factores ……………………………………………………………………………………….. (27) 6.6.2. Criterios ……………………………………………………………………………………….. (27) 6.7. Modelo De Dromey ………………………………………………………………………………….. (27) 6.8. Modelo De Reboot ……………………………………………………………………………………. (28) 6.9. Modelo ISO ……………………………………………………………………………………………… (29) 6.9.1. Iso 9000 ……………………………………………………………………………………….. (29) 6.9.2. Iso 9126 ……………………………………………………………………………………….. (29) 6.9.2.1. Antecedentes …………………………………………………………………... (29) 6.9.2.2. Iso 9126-1 Modelo De Calidad (Iso/Iec, 2001) ……………………………. (30) 6.9.2.2.1. Metricas De Calidad Del Producto …………………. (36) 6.9.2.2.2. La Calidad En El Uso …………………………………. (38) 6.9.2.2.3. Utilidad De Las Normas Iso / Iec 9126 ………….... (39) 6.10. 6.11. 6.12. 6.13. 6.14. 6.15. 6.16. 6.17. 6.18. 6.19. 6.20. 6.21. 6.22.

Modelo Parasuraman …………………………………………………………………………… (40) Modelo Cai (2000) ………………………………………………………………………………… (40) Modelo Fernandez And Rossi (2000) …………………………………………………….. (40) Modelo Propuesto Bertoa y Vallecillo (2002)………………………………………… (42) Modelo De Calidad Quint2 (Niessink, 2002) ………………………………………….. (41) Modelo En Zo And Ramamurhty (2002) ………………………………………………… (41) Modelo En Web And Web (2002) ………………………………………………………….. (41) Modelo De Simao Y Belchior (2003) ………………………………………………………. (41) Modelo De Calidad Propuesto Por Franch And Carvallo (2003) ………………. (41) Modelo Botella (2003) …………………………………………………………………………… (41) Modelo Wqm ………………………………………………………………………………………... (41) Modelo Gqm (Goal Question Metric) ………………………………………………………. (41) Modelo CMMI ……………………………………………………………………………………… .. (42) 6.22.1. Niveles De CMMI ………………………………………………………………………. (42)

Conclusiones ………………………………………………………………………………………………………………… (45) Recomendaciones ………………………………………………………………………………………………….. (45) Bibliografía ……………………………………………………………………………………………………………. (46)

3


ÍNDICE DE TABLAS Y FIGURAS 1. INDICE DE FIGURAS

Figura N°1. Estructura De Modelos De Calidad Software

10

Figura N°2. Tipos de Modelos de Calidad Software

11

Figura N°3. Línea de Tiempo de los Modelos de Calidad de Software

13

Figura N°4. Modelo de Boehm

22

Figura N°5. Modelo de REBOOT

28

Figura N°6. Estándar 9126

30

Figura N°7. Características Modelo de Calidad para Calidad Interna y Externa

31

Figura N°8. Características de Vista en Uso

35

Figura N°9. Proceso del Modelos de Calidad ISO/IEC9126

38

Figura N°10. Niveles del Modelo CMMI

44

2. INDICE DE TABLAS

Tabla N°1. Beneficios Frente A Coste De Los Factores De Calidad

8

Tabla N°2. Ejemplos de Tipo de Modelos de Calidad Software

13

Tabla N°3. Modelo de McCall

19

Tabla N°4. Comparación de Modelos McCall – Boehm

23

Tabla N°5. Modelo de FURPS

24

Tabla N°6. Factores del Modelo de Calidad de Deutsch

27

Tabla N°7. Criterios del Modelo de Deutsch

27

4


INTRODUCCIÓN Hoy en día nos encontramos en un mundo cada vez más globalizado, donde cada día la calidad aparece como una necesidad, la cual permite competir con mayores posibilidades de éxito. La calidad en productos de software ha tenido un auge importante en la sociedad informatizada de hoy. Los modelos de calidad son una parte fundamental en los procesos de desarrollo y evaluación de la calidad del software Se debe entender que un modelo de calidad no es una metodología que nos resuelva la vida de forma sencilla y clara, los modelos de calidad nos dicen QUE hacer, no COMO hacerlo. Debido a la necesidad de obtener un software de calidad que debe satisfacer los requerimientos dados por el usuario, han surgido modelos de calidad que resultan la predicción de confiabilidad y la gerencia de calidad durante el proceso de desarrollo y medición de la complejidad de un sistema de software. En este presente documento muestra una breve descripción y estructura de los modelos de calidad de software de McCall, Boehm, ISO/IEC 9126 entre otros. El modelo de McCall fue el primero en ser presentado en 1977, busca reducir la brecha entre usuarios y desarrolladores enfocándose a factores de calidad. Modelo Boehm introduce características de alto nivel, características de nivel intermedio y características primitivas, cada una de las cuales contribuye al nivel general de calidad ISO/IEC 9126 ISO 9126-1 propone un modelo de calidad categorizando la calidad de los atributos software en seis características (funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad

5


1. MODELO Un modelo es una representación de un objeto, sistema o idea, de forma diferente al de la entidad misma. El propósito de los modelos es ayudarnos a explicar, entender o mejorar un sistema. Un modelo de un objeto puede ser una réplica exacta de éste o una abstracción de las propiedades dominantes del objeto. 2. MODELOS DE CALIDAD Los Modelos de Calidad son herramientas que guían a las Organizaciones a la Mejora Continua y la Competitividad dándoles especificaciones de qué tipo de requisitos debe de implementar para poder brindar productos y servicios de alto nivel. Conjunto de criterios agrupados en áreas o capítulos que sirven como referencia para estructurar un plan de calidad total en una empresa u organización, o de una de sus partes. Los modelos de calidad permiten: a. b. c. d.

Definición estructurada de criterios de evaluación Especificación de requisitos con relación a ellos Descripción de componentes en un marco común Definición de métricas y prioridades

3. MODELOS DE CALIDAD DE SOFTWARE La obtención de un software con calidad implica la utilización de modelos o procedimientos estándares para el análisis, diseño, desarrollo y prueba del software que permitan uniformar la filosofía de trabajo, para lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software. Un modelo de calidad del software es un conjunto de buenas prácticas para el ciclo de vida del software, enfocado en los procesos de gestión y desarrollo de proyectos. Construir un modelo de calidad es bastante complejo y es usual que estos modelos descompongan la calidad del producto software jerárquicamente en una serie de características y sub-características que pueden usarse como una lista de comprobación de aspectos relacionados con la calidad.

6


3.1. VENTAJAS DE LOS MODELOS DE CALIDAD DEL SOFTWARE Las ventajas de implantar Modelos de Calidad del Software son: a) Tener una oportunidad para corregir los procesos de software que se hayan desajustado con el tiempo. b) Reducir los costos en todos los procesos. c) Cambiar la actitud del personal de la empresa. d) Realizar una mejora continua en la calidad de los procesos de software utilizados, servicios y productos de software. e) Lograr que la empresa de software sea más competitiva. f) Aumentar la productividad, efectividad y utilidad de la empresa. g) Asegurar la satisfacción de los clientes internos y externos. h) Tener productos de software y servicios con valor agregado. i) Tener permanentemente mejores procesos, productos de software y Servicios 3.2. PASOS PARA EL USO DE UN MODELO DE CALIDAD DEL SOFTWARE 3.2.1 AL PRINCIPIO DEL PROYECTO: Al especificar la calidad requerida de un producto software hay que: A. Seleccionar cuáles de los factores de calidad van a ser requisitos de calidad del sistema. Para ello hay que tener varias cosas en consideración: 1. La relación que tienen los factores con las características peculiares del producto o proyecto. Así, por ejemplo, si se espera que el ciclo de vida del sistema sea largo, la ‘facilidad de mantenimiento’ y la ‘flexibilidad’ se convierten en un requisito; si el sistema es experimental y se espera que las especificaciones del sistema cambien frecuentemente, la ‘flexibilidad’ será importante y sin embargo la ‘eficiencia’ apenas tendrá importancia; si el sistema se 7


desarrolla para un entorno en el que el hardware evoluciona rápidamente, la ‘portabilidad’ es esencial; si se espera que ciertas funciones del sistema se utilicen por un largo período de tiempo, aunque el resto del sistema cambie, la ‘facilidad de reutilización’ será fundamental, etc. 2. El coste del factor de calidad frente al beneficio que proporciona. La siguiente tabla indica, para cada factor, el ahorro que se puede esperar cuando se consigue frente al coste necesario para conseguir dicho factor.

FACTOR

3. El coste del factor de calidad frente al beneficio que proporciona. La siguiente tabla indica, para cada factor, el ahorro que se puede esperar cuando se consigue frente al coste necesario para conseguir dicho factor.

Corrección Fiabilidad Eficiencia Integridad Facilidad de Uso Facilidad de Mantenimiento Facilidad de Prueba Flexibilidad Portabilidad Reusabilidad Interoperabilidad

BENEFICIOS FRENTE A COSTE ALTO MEDIO BAJO           

Tabla N°1. Beneficios Frente A Coste De Los Factores De Calidad

4. Las implicaciones de los factores de calidad sobre el ciclo de vida, es decir, en qué etapas es necesario evaluar cada uno de los factores de calidad, y en qué etapas se dejan sentir los efectos de una calidad pobre con respecto a cada uno de estos factores. 5. Las interrelaciones entre factores. Algunos factores pueden ser conflictivos entre sí. La eficiencia, por ejemplo, está en conflicto con 8


prácticamente todos los demás factores de calidad. La siguiente tabla indica la dependencia entre los factores de McCall. B. Una vez seleccionados los factores de calidad que son requisitos para el producto, es necesario organizarlos en orden de importancia. C. Una vez establecidos los factores de calidad, el modelo de calidad proporciona automáticamente el conjunto de atributos o criterios relacionados con dichos factores. D. Para cada uno de los criterios de calidad se definen o eligen entonces un conjunto de métricas. E. Se debe entonces establecer valores deseables para los criterios en función de datos históricos, el promedio en la industria, etc. Se pueden establecer valores finales, es decir, los que se desea obtener una vez finalizado el desarrollo, y también valores intermedios o predictivos en cada período de medición durante el desarrollo. F. Por último, se deberán establecer los valores mínimos aceptables. La explicación para cualquier selección o decisión deberá ser adecuadamente documentada. 3.2.2 DURANTE EL DESARROLLO: Todo lo anterior se realizará al principio del proyecto. Ahora bien, durante el desarrollo será necesario: a) Implementar las métricas, es decir, tomar las medidas necesarias b) Analizar los resultados de las métricas c) Tomar medidas correctivas si es necesario, es decir, si los valores obtenidos están por debajo de los valores mínimos aceptables. Estas medidas correctivas pueden afectar tanto al proceso de desarrollo como al proceso de gestión.

9


3.2.3 AL FINAL DEL PROYECTO: Una vez finalizado el proyecto, será necesario validar las medidas predictivas utilizadas, y comprobar si en efecto se pueden tomar como indicadores de los valores finales

4. ESTRUCTURA DE LOS MODELOS DE CALIDAD DE SOFTWARE Los modelos de calidad en software comparten una estructura en forma de árbol, compuesta por un conjunto de atributos de calidad de alto nivel que identifican y miden atributos de bajo nivel a los cuales están conectados. Los modelos de calidad son creados para proveer las bases para la evaluación de software; por lo tanto a los atributos de calidad se les tiene que asignar métricas que permitan su medición. Generalmente tienen una estructura en tres niveles:

CALIDAD DE SOFTWARE

Factores de Calidad

Criterios de Calidad

Métricas

Figura N°1. Estructura De Modelos De Calidad Software

4.1. FACTORES DE CALIDAD: Se encuentran en el nivel más alto de la jerarquía, representan la calidad desde el punto de vista del usuario, son las características que componen la calidad. También conocidos como Atributos de Calidad Externos. 4.2. CRITERIOS DE CALIDAD: Cada factor se descompone en un conjunto de Criterios De Calidad. Son atributos que, contribuyen al aspecto de la calidad que el factor asociado representa. Se trata 10


de una visión de la calidad desde el punto de vista del producto software. También conocidos como Atributos de Calidad Internos. 4.3. METRICAS: Para cada uno de los criterios de calidad se definen un conjunto de Métricas, que son medidas cuantitativas de ciertas características del producto que, cuando están presentes, dan una indicación del grado en que dicho producto posee un determinado atributo de calidad.

5. TIPOS DE MODELOS DE CALIDAD DE SOFTWARE

PROCESOS

PROYECTO DE SW

ORGANIZACIO N

PRODUCTO DE SW

Figura N°2. Tipos de Modelos de Calidad Software

5.1. TIPOS DE MODELO DE CALIDAD DE PRODUCTO 5.1.1. MODELOS FIJOS Existe un catálogo de factores de calidad de partida que se usa como base para la evaluación de la calidad. Este enfoque supone que el modelo de calidad contiene todos los factores de calidad posibles, y que se usará un subconjunto de dichos factores para cada proyecto concreto. En general, la propuesta típica de un modelo de calidad fijo consiste en una estructuración de los factores en una jerarquía multinivel, con un conjunto de factores de más alto nivel, unos criterios que descomponen dichos factores, y eventualmente métricas para la medida de cada criterio. La ventaja de estos modelos fijos es que proporcionan una vista común y comparable que se reutiliza en cada proyecto, ya que el conjunto de factores 11


de calidad siempre es el mismo. Ahora bien, tiene como inconveniente su poca flexibilidad debido a que asumen que siempre bastará con un subconjunto de sus factores para evaluar la calidad en cualquier proyecto. Ejemplos: Los modelos de McCall et al. (1997), Boehm et al. (1978) y el modelo con un enfoque más industrial FURPS (Grady y Caswell, 1987) 5.1.2. MODELOS DE CALIDAD A MEDIDA No existe ningún catálogo de factores de partida, y dichos factores deben ser identificados para cada proyecto. La idea que guía la construcción de estos modelos es que se debe partir de la identificación de los objetivos a alcanzar. Dichos objetivos serían los factores más abstractos que deben descomponerse en factores más concretos hasta llegar a hacer operativos los objetivos, de forma que pueda ser medida su consecución. Así, los modelos son creados desde cero para todo nuevo proyecto. Existen diversas propuestas de métodos para crear los modelos de calidad a medida. La ventaja de estos modelos es su total adaptabilidad. Tienen como inconveniente que el coste de su construcción es muy alto comparado con el de los modelos fijos, y la reutilización de modelos de un proyecto a otro es difícil, dado que los factores identificados para un proyecto no tienen por qué ser adecuados para otro. Ejemplos: GQM (Goal-Question-Metric) 5.1.3. MODELOS MIXTOS Se intenta combinar las ventajas de los dos tipos anteriores de modelos. La idea es que exista un conjunto de factores de calidad más abstractos que sean reutilizados en virtualmente todos los proyectos posibles, y que puedan ser refinados y operacionalizados para un proyecto particular. Ejemplos: El modelo de Gilb (1988) y el modelo propuesto en el estándar ISO/IEC 9126-1 (2001)

12


ASPECTO PROYECTO (Ciclo de Vida del Software) ORGANIZACIÓN (Gobierno de TI) PROCESO (Procesos de la Empresa)

MODELOS DE CALIDAD CMMI SPICE ISO 12207 ISO 9001 – 2008 ISO 9003 COBIT PMI – PMBOOK ITIL PRINCE2

PRODUCTO (Producto de Software)

McCALL ISO 14598

Tabla N°2. Ejemplos de Tipo de Modelos de Calidad Software

6. MODELOS DE CALIDAD DE SOTFWARE

1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 -

Modelo de McCall Modelo de Boehm

Modelo de Arthur Modelo de FURFPS Modelo de Gilb / Modelo de Desutsch

Figura N°3. Línea de Tiempo de los Modelos de Calidad de Software

Modelo de Gillies / Modelo de REBOOT

Modelo de Dromey

ISO

13


6.1. MODELO DE MCCALL (1977) El modelo de Jim McCall, desarrollado inicialmente para la Fuerza Aérea de los EE.UU en 1977 que tenía la misión de proporcionar las normas y orientación de técnicas para la adquisición del software, es uno de los más renombrados actualmente. Este modelo busca reducir la brecha entre usuarios y desarrolladores enfocándose en un número de factores de calidad que reflejen las prioridades de ambos. El modelo establece una jerarquía de Perspectivas (3), Factores (11), Criterios de Calidad (23) y Métricas (41). Antes de utilizar este modelo hay que seguir las siguientes pautas: 1. Se aceptan los factores, criterios y métricas que propone los modelos. 2. Se aceptan las relaciones entre factores y criterios, y entre criterios y métricas. 3. Se selecciona un subconjunto de factores de calidad sobre los que aplica los requisitos de calidad establecidos para el proyecto. 6.1.1. PERSPECTIVAS PARA DEFINIR E PRODUCTO SOFTWARE:

IDENTIFICAR LA CALIDAD DE UN

I. Revisión Del Producto habilidad para ser cambiado. II. Transición Del Producto adaptabilidad al nuevo ambiente. III. Operación Del Producto características de operación. 6.1.2. FACTORES DE CALIDAD I. FACTORES DE REVISIÓN La revisión del producto incluye los siguientes factores de calidad: a) Mantenibilidad esfuerzo requerido para localizar y corregir fallas. b) Flexibilidad facilidad de realizar cambios. c) Testeabilidad facilidad para realizar el testing, para asegurarse que el producto no tiene errores y cumple con la especificación. II. FACTORES DE TRANSICIÓN. La transición del producto incluye los siguientes factores de calidad: a) Portabilidad esfuerzo requerido para transferir entre distintos ambientes de operación. b) Reusabilidad facilidad de reusar el software en diferentes contextos. 14


c) Interoperabilidad esfuerzo requerido para acoplar el producto con otros sistemas. III. FACTORES DE OPERACIÓN. La operación del producto incluye los siguientes factores de calidad: a) Correctitud grado en el que el producto cumple con su especificación. b) Confiabilidad la habilidad del producto de responder ante situaciones no esperadas. c) Eficiencia el uso de los recursos tales como tiempo de ejecución y memoria de ejecución. d) Integridad protección del programa y sus datos de accesos no autorizados. e) Usabilidad facilidad de operación del producto por parte de los usuarios 6.1.3. CRITERIOS DE CALIDAD: A. CRITERIOS DEL FACTOR MANTENIBILIDAD     

Consistencia. Simplicidad. Consistencia. Auto-descripción. Modularidad.

Pero la mantenibilidad ha cambiado bastante desde 1977, encontrar y corregir errores es sólo un aspecto más. Mantenibilidad está muy influenciado por el uso de buenas prácticas a lo largo de todo el ciclo de desarrollo algunas de estas buenas prácticas son:  

 

Seguir una metodología bien definida. Usar buenas técnicas de diseño, tanto de procedimientos como de datos, para aumentar cohesión y reducir acoplamiento. Observar la documentación interna. Usar buenas prácticas de programación: nombres significativos, código legible, etc.

15


B. CRITERIOS DEL FACTOR FLEXIBILIDAD    

Expandibilidad. Generalidad. Auto-descripción. Modularidad.

Con el correr de los años este criterio se ha fusionado con mantenibilidad de hecho, en la definición original, dos de los criterios de flexibilidad estaban compartidos con mantenibilidad. C. CRITERIOS DEL FACTOR TESTEABILIDAD  Simplicidad.  Instrumentación. Dado su ubicación en tradicionales modelos de ciclo de vida de software, la facilidad de testing se define claramente como un criterio de calidad. El testeo interactúa con otros criterios de calidad, por ejemplo correctitud y eficiencia debe ser llevado a cabo siguiendo planes predefinidos, con datos conocidos y cuyos resultados sean predeterminados la testeabilidad puede ser maximizada usando herramientas automáticas, buenas estrategias de cohesión y de diseño, y buenas prácticas de programación McCall definió originalmente métricas para testeabilidad consistentes en una matriz de complejidad que involucra número y tamaño de módulos, tamaño de procedimientos, profundidad de anidamiento, número de errores por unidad de tiempo, etc. D. CRITERIOS DEL FACTOR PORTABILIDAD    

Auto-descripción. Modularidad. Independencia de la máquina. Independencia del sistema operativo.

Algunos autores (Sommerville) lo consideran parte de la reusabilidad se favorece mediante el seguimiento de estándares, tanto de procedimientos (X Windows) como de datos (XML) la existencia de compiladores cruzados favorece la portabilidad. E.

CRITERIOS DEL FACTOR REUSABILIDAD 16


    

Generalidad. Modularidad. Auto-descripción. Independencia de la máquina. Independencia del sistema operativo.

Se puede favorecer la reusabilidad usando librerías de software, y técnicas de programación orientada a objetos hay que tener en cuenta que el desarrollo de código reusable cuesta más tiempo y dinero existe un factor económico difícil de medir: el costo de código reusable y la ganancia por reusar código ya desarrollado. F.

CRITERIOS DEL FACTOR INTEROPERABILIDAD  Modularidad.  Interoperabilidad en comunicación.  Interoperabilidad en datos. La interoperabilidad está relacionada con la reusabilidad en la actualidad su importancia ha crecido debido al creciente interés de conectarse con sistemas legacy se favorece mediante la adopción de estándares.

G. CRITERIOS DEL FACTOR CORRECTITUD  Trazabilidad.  Completitud.  Consistencia. Correctitud es un factor muy difícil de identificar debido a la falta de terminología estándar se lo pueden confundir con otros factores, tales como confiabilidad e integridad para medirlo es necesario tener disponible una especificación formal de los requerimientos, cosa muy rara salvo en proyecto de alto presupuesto y sistemas críticos las técnicas para verificarlo pueden ser: inspecciones de código, verificación matemática y analizadores estáticos de programas. H. CRITERIOS DEL FACTOR CONFIABILIDAD    

Tolerancia a errores. Consistencia. Simplicidad. Exactitud.

17


Combina la tolerancia tanto a errores de hardware como de software técnica de programación tales como tolerancia a las fallas, manejo de excepciones y programación defensiva ayudan puede ser medido con medidas como:     I.

Tiempo medio entre fallas. Tiempo medio antes de mantenimiento. Tiempo medio antes de recuperación. Probabilidad de falla.

CRITERIOS DEL FACTOR EFICIENCIA  Eficiencia en tiempo.  Eficiencia en espacio. Muchas técnicas favorecen este factor: el lenguaje de programación, el sistema operativo, optimización de algoritmos, normalización de datos.

J.

CRITERIOS DEL FACTOR INTEGRIDAD  Control de acceso.  Auditoría de acceso. Involucra tanto evitar el acceso malintencionado, así como los daños causados por errores involuntarios de usuarios autorizados.

K. CRITERIOS DEL FACTOR USABILIDAD     

Operabilidad. Entrenamiento. Comunicación. Volumen de E/S. Tasa de E/S.

La usabilidad ha cambiado mucho desde la época de McCall incluye aspectos tales como adaptabilidad, aprendizaje, adecuación al contexto algunos autores consideran por ejemplo que facilidad de aprendizaje es un factor de calidad independiente se puede subdividir en:  Ergonomía general el equipo es adecuado para el uso previsto.  Ergonomía de software estilos de diálogos, metáforas, diseño de pantallas, etc. 18

19 Tabla N°3. Modelo de McCall 

Reusabilidad





Transportabilidad



Interoperabilidad

 

Flexibilidad

Facilidad de Prueba



  

Formación Control de Accesos Facilidad de Auditorías Seguridad

 

Completitud Trazabilidad Precisión Tolerancia a Fallos

    

Modularidad Simplicidad Exactitud Eficiencia en Ejecución Concisión Auto Descripción Instrumentación

CRITERIOS



TRANSCISIÓN DE PRODUCTO

REVISIÓN DE PRODUCTO Facilidad de Mantenimiento

Eficiencia

Fiabilidad

Corrección(Exactitud)

Facilidad de Operación



Integridad(Seguridad)

Facilidad de Uso

FACTORES Facilidad de Comunicación



OPERACIÓN DE PRODUCTO

ASPECTOS O EJES Facilidad de Aprendizaje

   

    

 

  

 



Capacidad de Expansión Generalidad Independencia entre Sistemas y Hardware

Independencia del Hardware Compatibilidad de Comunicaciones Compatibilidad de Datos Consistencia

  



 

Eficiencia en Almacenamiento Estandarización de Datos





6.1.4. MÉTRICAS DE CALIDAD La medición de cualquiera de estos factores está definida en este modelo en base a 41métricas para cada criterio existe una lista de condiciones que se deben cumplir en distintas etapas: requerimientos (R), diseño (D), implementación (I) se cuentan las condiciones que se satisfacen en cada una de las etapas, sobre el total posible eso da una medida del criterio, que se pondera en partes iguales para medir el factor con los otros criterios asociados al factor. Para medir el criterio completitud del factor correctitud McCall sugiere las siguientes condiciones:        

Referencias no ambiguas [R,D,I] Referencias a datos bien definidas, o externas [R,D,I] Todas las funciones definidas son usadas [R,D,I] Todas las condiciones y procesamientos están definidos para cada punto de decisión [R,D,I] Todos los parámetros formales y actuales coinciden [D,I] Todos los reportes de problemas han sido resueltos [R,D,I] El diseño concuerda con los requerimientos [D] El código concuerda con el diseño [I]

Entonces se cuentan la cantidad de sí en cada etapa, resultando en la métrica de completitud:

Luego la correctitud se mide como la media entre las medidas de sus criterios (COMPLETITUD +TRAZABILIDAD +CONSISTENCIA) 3 6.2. MODELO DE BOEHM El segundo modelo de calidad más conocido es el presentado por Barry Boehm en1978 este modelo introduce características de alto nivel, características de nivel intermedio y características primitivas, cada una de las cuales contribuye al nivel general de calidad.

20


6.2.1. CARACTERÍSTICAS DE ALTO NIVEL Las características de alto nivel representan requerimientos generales de uso pueden ser:  Utilidad per-se cuan (usable, confiable, eficiente) es el producto en sí mismo.  Mantenibilidad cuán fácil es modificarlo, entenderlos y retestearlo.  Utilidad general si puede seguir usándose si se cambia el ambiente. 6.2.2. CARACTERÍSTICAS DE NIVEL INTERMEDIO Las características de nivel intermedio representan los factores de calidad de Boehm:       

Portabilidad (utilidad general). Confiabilidad (utilidad per-se). Eficiencia (utilidad per-se). Usabilidad (utilidad per-se). Testeabilidad (mantenibilidad). Facilidad de entendimiento (mantenibilidad). Modificabilidad o flexibilidad (mantenibilidad).

6.2.3. CARACTERÍSTICAS PRIMITIVAS El nivel más bajo corresponde a características directamente asociadas a una o dos métricas de calidad: A. DE PORTABILIDAD:       

Independencia de dispositivos. Auto-contención. De confiabilidad Auto-contención. Exactitud. Completitud. Consistencia. Robustez/integridad.

B. DE EFICIENCIA:  Accesibilidad.  Eficiencia de uso de dispositivos.

21


C. DE USABILIDAD:  Robustez/integridad.  Accesibilidad.  Comunicación. D. DE TESTEABILIDAD:  Comunicación.  Auto descripción.  Estructuración. E. DE ENTENDIBILIDAD:    

Consistencia. Estructuración. Concisidad. Legibilidad.

F. DE MODIFICABILIDAD:  Estructuración.  Aumentabilidad. INDEPENDENCIA DE DISPOSITIVO

AUTO - CONTENCIÓN

PRECISIÓN

Portabilidad

COMPLETITUD

Fiabilidad

ROBUSTEZ - INTEGRIDAD

Eficiencia UTILIDAD GENERAL

POR LA UTILIDAD

Mantenibilidad

CONSISTENCIA

CONTABILIDAD

Ingeniería Humana

EFICIENCIA DE DISPOSITIVO

Prueba

ACCESIBILIDAD

Entendibilida d

COMUNICABILIDAD

Modificabilidad

AUTO - DESCRIPTIVO

ESTRUCTURACIÓN

CONCISIÓN

LEGIBILIDAD

Figura N°4. Modelo de Boehm

AUMENTABILIDAD

22


6.2.4. COMPARACIÓN DE MODELOS MCCALL-BOEHM Aunque parezcan similares, la diferencia está en que McCall focaliza en medidas precisas de alto nivel, mientras que Boehm presenta un rango más amplio de características primarias la mantenibilidad está más desarrollada en Boehm. CRITERIO Correctitud Integridad Eficiencia Testeabilidad Flexibilidad Portabilidad Modificabilidad Entendibilidad Confiabilidad Usabilidad Mantenible Interoperabilidad Reusabilidad Claridad Documentación Validez

McCALL + + + + + +

+ + + + +

BOEHM + + + + + + + + + + + + + +

Tabla N°4 Comparación de Modelos McCall - Boehm

6.2.5. EVALUACIÓN DE LOS MODELOS DE MCCALL Y BOEHM Estos modelos tienen sus límites: Es difícil que las características y sub-características sean siempre perfectamente independientes falta una asociación explícita entre los modelos y el proceso de software, cómo realizar software de calidad las características son en general propiedades abstractas medible mediante métricas. No siempre existe una relación perfectamente lineal entre los valores de las métricas y las características que deben estimar.

23


6.3. MODELO ARTHUR Modelo de calidad creado por Arthur Andersen en 1985. Arthur presenta una variante del modelo de calidad propuesto por McCall., consta de dos acciones:  Añadir tres nuevos criterios de valoración: Complejidad, Seguridad, Auditabilidad  Variar las relaciones de los factores y los criterios 6.4. MODELO FURPS Desarrollado por Hewlett-Packard (1987). En este modelo se desarrollan un conjunto de factores de calidad de software, bajo el acrónimo de FURPS: funcionalidad (Functionality), usabilidad (Usability), confiabilidad (Reliability), desempeño (Performance) y capacidad de soporte (Supportability). A continuación se presenta la clasificación de los atributos de calidad que se incluyen en el modelo, junto con las características asociadas a cada uno. FACTOR DE CALIDAD FUNCIONALIDAD

FACILIDAD DE USO

CONFIABILIDAD

RENDIMIENTO

CAPACIDAD DE SOPORTE

ATRIBUTOS Características y Capacidad del Programa Generalidad de las Funciones Seguridad del Sistema Factores Humanos Factores Estéticos Consistencia de la Interfaz Documentación Frecuencia y Severidad de las Fallas Exactitud de las Salidas Tiempo Medio de Fallos Capacidad de Recuperación ante Fallas Capacidad de Predicción Velocidad del Procesamiento Tiempo de Respuesta Consumo de Recursos Rendimiento Efectivo Total Eficacia Extensibilidad Adaptabilidad Capacidad de Pruebas Capacidad de Configuración Compatibilidad Requisitos de Instalación

Tabla N°5. Modelo de FURPS

24


6.5. MODELO GILB Modelo de calidad creado por Gilb en 1988. Este modelo presenta como aspecto fundamental la definición de los atributos de calidad que realmente interesan al usuario y el nivel de calidad que debe tener cada uno de ellos para satisfacerlo ya que no tiene sentido exigir calidad en un producto, si no se cuenta con esta base. Cada atributo tiene subatributos que ayudan a la medición de este. Estos atributos son: a.

Capacidad de trabajo: Evalúa la capacidad natural del sistema para realizar su trabajo. Subatributos: capacidad del proceso, capacidad de respuesta, capacidad de almacenamiento.

b. Disponibilidad: Refleja la medida de la disponibilidad del sistema para realizar de forma útil el trabajo para el que fue diseñado. Subatributos: fiabilidad, Mantenibilidad e integridad. c.

Adaptabilidad: Es la medida de la capacidad de un sistema para ser modificado de manera adecuada. Subatributos: improbabilidad, extensibilidad y transportabilidad.

d. Utilizabilidad: Es la medida de la facilidad con que la gente será capaz y estará motivada para utilizar el sistema en la práctica. Sub-atributos: requisitos de entrada, requisitos de aprendizaje y habilidad de manejo. Gilb propone características como la corrección, la integridad, la facilidad de mantenimiento y la facilidad de uso, como base para proporcionar indicadores útiles para los equipos de trabajo y sugiere las definiciones, puntos de vista y medida para cada uno de las siguientes características: a.

Corrección: Grado en el que el software lleva a cabo su función requerida. Si un programa no opera correctamente, no dará valor agregado a sus usuarios

b. Facilidad de mantenimiento: Posibilidad de corregir un programa si se encuentra un error, adaptarlo si cambia su entorno, mejorarlo si el cliente desea un cambio

25


c.

Integridad: Habilidad de un sistema para resistir ataques, tanto accidentales como intencionados, contra su seguridad, a nivel de cualquiera de los tres principales componentes del software: programas, datos y documentos. Para medir la integridad, Gilb sugiere la utilización de otros dos atributos como base:  Amenaza. es la probabilidad (que se puede estimar o deducir de la evidencia empírica) de que un ataque de cualquier tipo ocurra en un tiempo determinado 

Seguridad. es la probabilidad de que se pueda repeler un determinado ataque

d. Facilidad de uso: Es un intento por cuantificar “lo amigable que puede ser el producto con el usuario”. Las características se pueden medir mediante varias sub-características o métricas detalladas. Para cada una de ellas se debe especificar los siguientes conceptos:  Nombre y definición de la característica.  Escala o unidades de medición.  Recolección de datos o prueba.  El valor previsto.  El valor óptimo.  El valor en el sistema actual. 6.6. MODELO DEUTSCH Es otra variante al modelo de McCall, añadiéndole nuevos factores y criterios y estableciendo nuevas relaciones. Para su establecimiento, Deutsch parte de las necesidades del usuario estimando que éstas pueden clasificarse en dos categorías: a) Necesidades Operacionales. Están relacionadas con la capacidad del software para realizar las tareas que se supone debe llevar a cabo  Funcional  Realización b) Necesidades de Mantenimiento. Se relacionan con la capacidad de modificar el software para ayudar al usuario 26


 Cambio  Gestión Para evaluar cada necesidad, Deutsch necesita 15 factores de calidad, y para evaluar estos se dispone de 27 criterios de calidad. 6.6.1. FACTORES: NECESIDADES DEL USUARIO 6 Funcional . 6 . 2 .

Realización Cambio Gestión

FACTORES DE CALIDAD Integridad – Fiabilidad – Supervivencia – Utilizabilidad Eficiencia – Corrección – Seguridad – Interoperabilidad Mantenibilidad – Expansibilidad – Flexibilidad – Transportabilidad – Reutilizabilidad Verificable - Gestionable

C Tabla N°6. Factores del Modelo de Calidad de Deutsch

6.6.2. CRITERIOS: CRITERIOS Accesibilidad al sistema Consistencia Alcance Funcional Distributivo Aumentabilidad Eficiencia de Almacenamiento Autonomía Eficiencia de Comunicaciones Auto – Descriptivo Eficiencia de Proceso Calidad de Documentación Entrenamiento Compatibilidad del Sistema Gestión de Anomalías Completitud Gestión Segura Común Generalidad

Independencia Modularidad Operatividad Precisión Simplicidad Soporte Seguimiento Virtualidad Visibilidad

Tabla N°7. Criterios del Modelo de Deutsch

6.7. MODELO DE CALIDAD DE DROMEY Un modelo presentado por el Sr. R. Geoff Dromey basados en que reconoce que evaluación de la calidad es diferente para cada producto y que una idea más dinámica para modelar el proceso es necesario lo suficientemente amplia como 27


para solicitar los distintos sistemas. Dromey se centra en la relación entre los atributos de calidad y los sub-atributos, así como intentar conectar propiedades de productos de software con la calidad del software atributos. Este modelo describe la idea de relacionar atributos del producto con atributos de calidad para su evaluación El modelo se estructura en torno a un proceso de 5 pasos: 1. 2. 3. 4. 5.

Elije un conjunto de alto nivel de calidad atributos necesarios para la evaluación. Lista de componentes y módulos en su sistema. Identificar las propiedades de transporte de calidad Determinar la forma en cada uno de los efectos patrimoniales los atributos de calidad. Evaluar el modelo e identificar.

6.8. MODELO DE REBOOT Incorpora dos factores nuevos:  Mantenibilidad. Refleja la facilidad con que se hace el mantenimiento.  Pruebas. Consiste en la capacidad del software para facilitar el establecimiento de criterios, así como la evaluación de dicho software con relación a esos criterios. FIABILIDAD OBSERVADA

CONSISTENCIA

FIABILIDAD AUTO - DESCRIPTIVO

MODELO DE CALIDAD

MANTENIBILIDAD

SIMPLICIDAD MODULARIDAD

PRUEBAS

SEGUIMIENTO COMPLEJIDAD DE COMPONENTES COMPLEJIDAD DEL CODIGO

Figura N°5. Modelo de REBOOT

28


6.9. MODELO ISO 6.9.1. ISO 9000 Las siglas ISO significa “Organización Internacional para las Standardization”. El ISO es la organización responsable de toda una serie de normas de las cuales la norma ISO 9000 Probablemente es el más conocido, difundir y utilizar. a) ISO 19011:2000 "Directrices para la auditoría Gestión de la Calidad Sistemas. b) ISO 9004:2000"Directrices para la Calidad Gestión de las Organizaciones " c) ISO 9000:2000"Conceptos y Terminología " d) ISO 9001:2000 "Requisitos para Aseguramiento de la Calidad " e) ISO 9001 es un estándar de calidad internacional de gestión de sistemas aplicables a las organizaciones en todo tipo de las empresas. ISO 9001 internos centra en los procesos de una organización y métodos y externamente en la gestión 6.9.2. ISO 9126 6.9.2.1. ANTECEDENTES ISO 9126 se publicó en 1991, con el objeto de “promover un entorno que permita la evaluación de la calidad de software”. En 1994 se entendió que era necesario modificar y adaptar la norma. En esta versión se introducen por primera vez los conceptos de calidad interna y calidad externa. Además se creó una nueva norma (ISO 14598) que asumía el modelo del proceso de evaluación antes incluido en la norma ISO 9126. En 2005 se crea una nueva versión de esa norma, la ISO/IEC 25000, que entrega una guía para el uso de los nuevos estándares internacionales llamados Requisitos y Evaluación de Calidad de Procesos de Software (SQuaRE). La ISO/IEC 25000 establece criterios para la especificación de requisitos de calidad del software, medidas y evaluación, además entrega un modelo de calidad que unifica las definiciones de calidad de los clientes con los atributos durante el desarrollo. 29


El estándar 9126 propone un modelo de calidad que se divide en tres vistas: interior, exterior y de uso. Estas están compuestas por características, las que se dividen en sub características, y estas a su vez se componen de atributos. El estándar está dividido en cuatro partes las cuales dirigen, respectivamente, lo siguiente: a) b) c) d)

ISO 9126-1 Modelo de calidad (ISO/IEC, 2001) ISO 9126-2 Métricas externas (Mide el software en sí mismo) ISO 9126-3 Métricas de internas (mide el comportamiento del sistema) ISO 9126-4 Calidad en el uso de métricas (mide el efecto de usar el software en un contexto específico) CALIDAD DEL PROCESO

9 1 2 6 1

CALIDAD INTERNA

9126 – 3

CALIDAD EXTERNA

9126 – 2

CALIDAD EXTERNA

9126 – 4

Figura N°6 Estándar 9126

6.9.2.2. ISO 9126-1 MODELO DE CALIDAD (ISO/IEC, 2001) La cual se divide en 2: A. MODELO DE CALIDAD PARA CALIDAD INTERNA Y EXTERNA : La norma ISO/IEC 9126 define la calidad interna como: “La totalidad de las características del producto software desde una perspectiva interna. La calidad interna es medida y evaluada en base a los requerimientos de calidad interna. Los detalles de la calidad del producto software pueden ser mejorados durante la implementación, revisión y prueba del código software, pero la naturaleza fundamental de la calidad del producto software

30


representada por la calidad interna permanece sin cambio a menos que sea re diseñado”. La norma ISO/IEC 9126 define la calidad externa como: “La calidad de un producto software debería ser evaluado usando un modelo de calidad. ISO 9126-1 propone un modelo de calidad categorizando la calidad de los atributos software en seis características, los cuales son subdivididos en subcategorías. Las subcategorías pueden ser medidas con métricas internas o externas.” La calidad externa e interna establecen que cualquier componente de calidad del software puede ser descrito en términos de una o más de seis características básicas, las cuales son: funcionalidad, confiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad; cada una de las cuales se detalla a través de un conjunto de sub características que permiten profundizar en la evaluación de la calidad de productos de software y la calidad de las necesidades del usuario o calidad de uso que posee cuatro características que ayuden al usuario a cumplir sus objetivos, ellas son: eficacia, productividad, seguridad y satisfacción.

Figura N°7. Características Modelo de Calidad para Calidad Interna y Externa 31


1.1. Funcionalidad: ¿Las funciones y propiedades satisfacen las necesidades explícitas e implícitas; esto es, el qué...? - En este grupo se conjunta una serie de atributos que permiten calificar si un producto de software maneja en forma adecuada el conjunto de funciones que satisfagan las necesidades para las cuales fue diseñado. Para este propósito se establecen los siguientes atributos:  Adecuación: Capacidad del producto software para proporcionar un conjunto apropiado de funciones para tareas y objetivos de usuario especificados.  Exactitud: Capacidad del producto software para proporcionar los resultados o efectos correctos o acordados, con el grado necesario de precisión.  Interoperabilidad: Capacidad del producto software para interactuar con uno o más sistemas especificados.  Seguridad de acceso: Capacidad del producto software para proteger información y datos de manera que las personas o sistemas no autorizados no puedan leerlos o modificarlos, al tiempo que no se deniega el acceso a las personas o sistemas autorizados  Cumplimiento funcional: Capacidad del producto software para adherirse a normas, convenciones o regulaciones en leyes y prescripciones similares relacionadas con funcionalidad. 1.2. Fiabilidad / Confiabilidad: ¿Puede mantener el nivel de rendimiento, bajo ciertas condiciones y por cierto tiempo? - Aquí se agrupan un conjunto de atributos que se refieren a la capacidad del software de mantener su nivel de ejecución bajo condiciones normales en un periodo de tiempo establecido. Las sub características que el estándar sugiere son:  Madurez: Capacidad del producto software para evitar fallar como resultado de fallos en el software.  Tolerancia a fallos: Capacidad del software para mantener un nivel especificado de prestaciones en caso de fallos software o de infringir sus interfaces especificados. 32


 Capacidad de recuperación: Capacidad del producto software para restablecer un nivel de prestaciones especificado y de recuperar los datos directamente afectados en caso de fallo.  Cumplimiento de la fiabilidad: Capacidad del producto software para adherirse a normas, convenciones o regulaciones relacionadas con la fiabilidad. 1.3. Usabilidad: ¿El software es fácil de usar y de aprender? - Consiste de un conjunto de atributos que permiten evaluar el esfuerzo necesario que deberá invertir el usuario para utilizar el sistema.  Capacidad para ser entendido: Capacidad del producto software que permite al usuario entender si el software es adecuado y cómo puede ser usado para unas tareas o condiciones de uso particulares.  Capacidad para ser aprendido: Capacidad del producto software que permite al usuario aprender sobre su aplicación.  Capacidad para ser operado: Capacidad del producto software que permite al usuario operarlo y controlarlo.  Capacidad de atracción: Capacidad del producto software para ser atractivo al usuario.  Cumplimiento de la usabilidad: Capacidad del producto software para adherirse a normas, convenciones, guías de estilo o regulaciones relacionadas con la usabilidad. 1.4. Mantenibilidad: ¿Es fácil de modificar y verificar? Se refiere a los atributos que permiten medir el esfuerzo necesario para realizar modificaciones al software, ya sea por la corrección de errores o por el incremento de necesidades.  Capacidad para ser analizado: Es la capacidad del producto software para serle diagnosticadas deficiencias o causas de 33


los fallos en el software, o para identificar las partes que han de ser modificadas.  Capacidad para ser cambiado: Capacidad del producto software que permite que una determinada modificación sea implementada.  Estabilidad: Capacidad del producto software para evitar efectos inesperados debidos a modificaciones del software.  Capacidad para ser probado: Capacidad del producto software que permite que el software modificado sea validado.  Cumplimiento de la mantenibilidad: Capacidad del producto software para adherirse a normas relacionadas con la mantenibilidad.

o

convenciones

1.5. Portabilidad: ¿Es fácil de transferir de un ambiente a otro? - En este caso, se refiere a la habilidad del software de ser transferido de un ambiente a otro, y considera los siguientes aspectos:  Adaptabilidad: Evalúa la oportunidad para adaptar el software a diferentes ambientes sin necesidad de aplicarle modificaciones.  Facilidad de Instalación: Es el esfuerzo necesario para instalar el software en un ambiente determinado.  Conformidad: Permite evaluar si el software se adhiere a estándares o convenciones relativas a portabilidad.  Capacidad de reemplazo: Se refiere a la oportunidad y el esfuerzo usado en sustituir el software por otro producto con funciones similares.  Capacidad de portabilidad: capacidad del producto de software de permitir que usuarios alcancen objetivos específicos con eficacia, productividad, seguridad y satisfacción en contextos de uso específicos. 1.6. Eficiencia: Capacidad que permite que los usuarios alcancen objetivos con exactitud e integridad, en un contexto especifico. 34


 Comportamiento

temporal:

Capacidad

del

producto

software para proporcionar tiempos de respuesta, tiempos de proceso y potencia apropiados, bajo condiciones determinadas.  Utilización de recursos: Capacidad del producto software para usar las cantidades y tipos de recursos adecuados cuando el software lleva a cabo su función bajo condiciones determinadas.  Cumplimiento de la eficiencia: Capacidad del producto software para adherirse a relacionadas con la eficiencia.

normas

o

convenciones

B. CALIDAD EN USO La norma ISO/IEC 9126-1 define la calidad en uso como:

“La perspectiva del usuario de la calidad del producto software cuando éste es usado en un ambiente específico y un contexto de uso específico. Ésta mide la extensión para la cual los usuarios pueden conseguir sus metas en un ambiente particular, en vez de medir las propiedades del software en sí mismo”. Para la vista en uso se contemplan 4 características

VISTA EN USO

Efectividad

Productividad

Seguridad

Satisfacción

Figura N°8. Características de Vista en Uso

2.1. Efectividad: capacidad del software de facilitar al usuario alcanzar Objetivos con precisión y completitud.

35


2.2. Productividad: Capacidad del software de permitir a los usuarios gastar la cantidad apropiada de recursos en relación a la efectividad obtenida. 2.3. Seguridad: Capacidad del software para cumplir con los niveles de riesgo emitidos tanto para posibles daños físicos como para posibles riesgos de datos.´ 2.4. Satisfacción: Capacidad del software de cumplir con las expectativas de los usuarios en un contexto determinado.

6.9.2.2.1. MÉTRICAS DE CALIDAD DE PRODUCTO Las métricas de calidad de producto se aplican a los diversos atributos del producto y que permiten determinar posteriormente los niveles de calidad del producto. Las métricas que se pueden aplicar de acuerdo a los atributos están definidas en las normas ISO/IEC 9126-2 para el caso de la calidad externa, las ISO/IEC 9126-3 para el caso de la calidad interna y la ISO/IEC 9126-4 para el caso de la calidad en uso. En todos los casos las normas señalan que las métricas presentadas no pretenden ser exhaustivas, ni limita la posibilidad de usar otras métricas de acuerdo a las necesidades del usuario. El anexo A de la norma ISO/IEC 9126-1 señala lo siguiente: “Se han encontrado que los niveles de ciertos atributos internos influyen los niveles de algunos atributos externos, de modo que haya un aspecto externo y un aspecto interno a la mayoría de las características. Por ejemplo, la confiabilidad puede ser medida externamente observando el número de fallas en un período de tiempo de ejecución dedo durante un ensayo del software e internamente examinando las especificaciones detalladas y el código fuente para determinar el nivel de la tolerancia a fallas. Los atributos internos serían los indicadores de los atributos externos. Un atributo interno puede influenciar a una o más características, y una característica puede ser influenciada por más de un atributo. En este modelo la totalidad de atributos de la calidad del producto software son clasificados en una estructura arborescente jerárquica de características y sub características. El nivel más alto de esta estructura consiste en características de calidad y el nivel más bajo consiste en atributos de calidad de software. 36


La jerarquía no es perfecta, porque algunos atributos pueden contribuir a más de una sub característica”1. A. Métricas externas: son aquellas que miden el comportamiento de todo el software o parte de él, a través de testeos, operaciones y observaciones del software ejecutable en el sistema. Proporcionando a todos los involucrados el beneficio de conocer la calidad del producto software durante las pruebas u operación y sabemos si cumple con la calidad esperada. La norma ISO/IEC 9126-1 señala que: “Antes de adquirir o usar un producto software este debería ser evaluado usando la métrica basada en los objetivos del negocio relacionados al uso, explotación y administración del producto en una organización y un ambiente técnico específico”2. B. Métricas internas: Las métricas internas pueden ser aplicadas durante el diseño y la codificación del producto software no ejecutable (por ejemplo código fuente) y proporciona a todos los involucrados el beneficio de conocer la calidad del producto durante su construcción y tomar decisiones sobre esa base para conseguir el producto con la calidad esperada. La norma ISO/IEC 9126-1 señala que: “Las métricas internas miden atributos internos o indican los atributos externos a través del análisis de las propiedades estáticas de productos intermedio o entregables del producto software. Las medidas de las métricas internas usan números o frecuencias de elementos de composición de software los cuales aparecen por ejemplo en las sentencias de código fuente, gráficos de control, flujo de datos y representaciones de estado de transición”.

1 2

http://inform.pucp.edu.pe/~edavila/publicaciones/calidadproductosoftware_ok.pdf Libro Calidad Del Producto Y Proceso Software, CALERO, C, pág. 38

37


6.9.2.2.2. LA CALIDAD EN EL USO: Si bien el modelo indica que estas sub características a su vez se subdividen en atributos, no se especifica cuáles son esos atributos, ya que se entiende que estos son entidades dependientes del producto software y variarán según varíe la naturaleza del software analizado: lenguaje, paradigma de programación, complejidad tecnológica, etc. a.

Métricas de uso: Mide como un producto cumple con las necesidades de los usuarios para alcancen sus objetivos. La evaluación de la calidad en el uso valida la calidad del producto software en escenarios específicos de uso. Este estándar proviene desde el modelo establecido en 1977 por McCall y sus colegas, los cuales propusieron un modelo para especificar la calidad del software. El modelo de calidad McCall está organizado sobre tres tipos de Características de Calidad:  Factores (especificar): Ellos describen la visión externa del software, como es visto por los usuarios.  Criterios (construir): Ellos describen la visión interna del software, con es visto por el desarrollador.  Métricas (controlar): Ellas son definidas y usadas para proveer una escala y método para la medida. ISO 9126 distingue entre fallos y no conformidad, siendo un fallo el no cumplimiento de los requisitos previos, mientras que la no conformidad afecta a los requisitos especificados. Una distinción similar es hecha entre la validación y la verificación. Contextos de Uso

Influye

Influye Calidad Interna

Proceso de Calidad Depende de

Depende de

PROVEEDOR

Influye Calidad Externa

Calidad En Uso Depende de

USUARIO

Figura N°9. Proceso del Modelos de Calidad ISO/IEC9126

38


6.9.2.2.3. UTILIDAD DE LAS NORMAS ISO / IEC 9126 Este estándar está pensado para los desarrolladores, adquirentes, personal que asegure la calidad y evaluadores independientes, responsables de especificar y evaluar la calidad del producto software. Por tanto, puede servir para validar la completitud de una definición de requisitos, identificar requisitos de calidad de software, objetivos de diseño y prueba, criterios de aseguramiento de la calidad, etc. La calidad de cualquier proceso del ciclo de vida del software (estándar ISO 12.207) influye en la calidad del producto software que, a su vez, contribuye a mejorar la calidad en el uso del producto. La calidad del software puede evaluarse midiendo los atributos internos (medidas estáticas o productos intermedios) o atributos externos (comportamiento del código cuando se ejecuta). El mundo globalizado exige cada vez más la aplicación de estándares internacionales que garanticen la calidad de los productos. Por esta razón, es necesario que todo aquel que se dedica al desarrollo de software incluya en sus procesos, estándares de calidad que permitan certificarse en alguno de los modelos. Aquí se ha presentado un estándar, el ISO-9126, el cual establece una guía para la evaluación de la calidad del software, sin embargo es necesario que cada empresa dedicada a producir software trabaje en establecer su modelo de calidad que le permita valorar el nivel de excelencia de sus productos, en el que deberán incluirse instrumentos de medición que permitan calificar cuantitativamente cada una de las características aquí presentadas. Es importante mencionar, que dependiendo de los distintos tipos de aplicaciones las métricas podrán variar, ya que aunque las características expuestas son comunes a la totalidad de los productos, cada software particular requiere una evaluación específica El estándar ISO 9126, ahora englobado en el proyecto SQuaRE para el desarrollo de la norma ISO 25000, establece un modelo de calidad en el que se recogen las investigaciones de multitud de modelos de calidad propuestos por los investigadores durante los últimos 30 años para la caracterización de la calidad del producto software. 39


a) ISO / IEC 15504 (SPICE6) La norma ISO / IEC 15504: Tecnologías de la Información Software Proceso de Evaluación es un estándar internacional a gran marco para la evaluación de proceso que tiene la intención de abordar todos los procesos que intervienen en: • Software de adquisición • Desarrollo • Operación • Suministro • Mantenimiento • Apoyo ISO / IEC 15504 se compone de 9 componentes que cubren los conceptos, modelo de referencia y mejora de procesos guía, modelo de evaluación y guías, las calificaciones de los evaluadores, y la guía para determinar el proceso de proveedor capacidad: Dada la estructura y el contenido de la norma ISO / IEC 15504 es la documentación más estrechamente relacionados con la norma ISO 9000

6.10. MODELO PARASURAMAN Se describe el modelo SERVQUAL el cual contiene cinco dimensiones y 22 items para medir los diferentes elementos de la calidad de un servicio en general. La idea de este modelo es que puede ser adaptado a diferentes entornos en función de los servicios ofrecidos por cada uno de ellos, adaptando las dimensiones descritas en el modelo original. 6.11. MODELO CAI (2000) Proponen un modelo de calidad para componentes y sistemas basados en componentes. 6.12. MODELO FERNANDEZ AND ROSSI (2000) Define un modelo de calidad para software distribuido.

40


6.13. MODELO PROPUESTO BERTOA Y VALLECILLO (2002). Para componentes software en el que los autores adaptan la norma ISO/IEC 9126 a los componentes COTS (Comercial Off – The - Shelf). 6.14. MODELO DE CALIDAD QUINT2 (NIESSINK, 2002). Presenta una ampliación de la norma ISO/IEC 9126, pensada para valorar la calidad de arquitecturas software. 6.15. MODELO EN ZO AND RAMAMURHTY (2002). Los autores presentan un modelo para valorar y seleccionar los sitios web de comercio electrónico en un entorno B2C (Business To Consumer). 6.16. MODELO EN WEB AND WEB (2002). Presentan los factores de calidad del sitio web que son importantes para los consumidores. 6.17. MODELO DE SIMAO Y BELCHIOR (2003). En el que los autores han ampliado las sub-características y atributos propuestos por la norma ISO/IEC 9126, llegando a identificar 124 atributos de calidad para los componentes software. 6.18. MODELO DE CALIDAD PROPUESTO POR FRANCH AND CARVALLO (2003). Presenta una adaptación de la ISO/IEC 9126para servidores de correo electrónico 6.19. MODELO BOTELLA (2003). Proponen un modelo para la selección de ERP y también escogen como marco de trabajo el estándar de calidad ISO/IEC 9126-1. 6.20. MODELO WQM. Pretende ser un modelo global de calidad de la web. Está caracterizado por 3 elementos: I. La característica de calidad (basada en QUINT2 y en la ISO/IEC 9126) II. El proceso del ciclo de vida (basado en la ISO/IEC 12207) III. Características (contenido, presentación y navegación) 41


6.21. MODELO GQM (GOAL QUESTION METRIC). Enfoque de medición para evaluar la calidad del software basado en la identificación de objetivos a lograr. A continuación se presenta la estructura del modelo I. II.

III. IV.

V.

Nivel conceptual (goal - meta) Se define un objetivo (meta) para un objeto (ente), con respecto a determinado “modelo de calidad”, ara un punto de vista, relativo a un contexto en particular. Nivel operativo (question - pregunta) Se refina un conjunto de preguntas a partir de una meta, identificando el objeto de medición con respecto a características de calidad seleccionadas para un punto de vista. Nivel cuantitativo (metric - metrica)

Se asocia un conjunto de métricas para cada pregunta, de modo de responder a cada una de ellas de un modo cuantitativo3. 6.22. MODELO CMMI Es un modelo de calidad del software que clasifica las empresas en niveles de madurez. Estos niveles sirven para conocer la madurez de los procesos que se realizan para producir software. 6.22.1. Niveles CMMI:  Nivel 1. Inicial: Proceso impredecible, poco controlado y reactivo Este es el nivel en donde están todas las empresas que no tienen procesos. Los presupuestos se disparan, no es posible entregar el proyecto en fechas, te tienes que quedar durante noches y fines de semana para terminar un proyecto. No hay control sobre el estado del proyecto, el desarrollo del proyecto es completamente opaco, no sabes lo que pasa en él.  Nivel 2. Gestionado: frecuentemente reactivo

Proceso

caracterizado

por

proyectos

y

3

OLSINA, Luis. “Ingeniería Web; Marco de medición y evaluación de calidad”. Departamento de informática. Universidad Nacional de San Luis - La Rioja – Catamarca. Año 2007

42


En este nivel el éxito de los resultados obtenidos se pueden repetir. La principal diferencia entre este nivel y el anterior es que el proyecto es gestionado y controlado durante el desarrollo del mismo. El desarrollo no es opaco y se puede saber el estado del proyecto en todo momento. Los procesos que hay que implantar para alcanzar este nivel son: Gestión de requisitos Planificación de proyectos Seguimiento y control de proyectos Gestión de proveedores Aseguramiento de la calidad Gestión de la configuración.  Nivel 3. Definido: Proceso caracterizado por la organización y proactivo. Alcanzar este nivel significa que la forma de desarrollar proyectos (gestión e ingeniería) está definida, por definida quiere decir que está establecida, documentada y que existen métricas (obtención de datos objetivos) para la consecución de objetivos concretos. Los procesos que hay que implantar para alcanzar este nivel son:          

Desarrollo de requisitos Solución Técnica Integración del producto Verificación Validación Desarrollo y mejora de los procesos de la organización Definición de los procesos de la organización Planificación de la formación Gestión de riesgos Análisis y resolución de toma de decisiones

 Nivel 4. Gestionado Cuantitativamente: El proceso es controlado cuantitativamente. Los proyectos usan objetivos medibles para alcanzar las necesidades de los clientes y la organización. Se usan métricas para gestionar la organización. Los procesos que hay que implantar para alcanzar este nivel son: Gestión cuantitativa de proyectos Mejora de los procesos de la organización

43


 Nivel 5. En Optimización: Enfoque en la mejora del proceso Los procesos de los proyectos y de la organización están orientados a la mejora de las actividades. Mejoras incrementales e innovadoras de los procesos que mediante métricas son identificadas, evaluadas y puestas en práctica. Los procesos que hay que implantar para alcanzar este nivel son: Innovación organizacional Análisis y resolución de las causas.

Figura N°10. Niveles del Modelo CMMI

44


Conclusiones Para obtener el éxito en la producción de software debemos hacerlo con calidad y demostrando el grado de ésta, calificando como buena. Esto sólo es posible con la implantación de un Sistema para el Aseguramiento de la Calidad del Software directamente relacionado con la política establecida para su elaboración y que esté en correspondencia con las definiciones internacionales de calidad, ampliamente aceptada, y por los estándares que se manejan hoy en día.

Recomendaciones Finalmente como recomendación se sugiere la aplicación de las normativas establecidas a nivel internacional, mediante la aplicación de métodos de calidad al software a desarrollar. Con ello se logra garantizar la calidad del mismo y que logre cumplir el objetivo esperado.

45


BIBLIOGRAFIA 

http://modelosdegestiondelacalidad.blogspot.com/



http://repositorio.utp.edu.co/dspace/bitstream/11059/1977/1/0053R173e.pdf



http://www.slideshare.net/elsuse/calidad-del-software



http://modelosdegestiondelacalidad.blogspot.com/



http://es.scribd.com/doc/56605621/8/Estructura-de-los-modelos-de-calidad



http://upcommons.upc.edu/pfc/bitstream/2099.1/11310/1/Tesina_Antonio_Perez _Jimenez.pdf



http://gpherrera1990.blogspot.com/2010/07/unidad-1.html



https://export.writer.zoho.com/public/gerardogomez/modelos-de-calidad-desoftware/fullpage



http://clases3gingsof.wetpaint.com/page/FURPS



http://bdigital.eafit.edu.co/PROYECTO/P005.14CDP613/marcoTeorico.pdf



http://repositorio.utp.edu.co/dspace/bitstream/11059/1977/1/0053R173e.pdf



http://cdn.bitbucket.org/cuatrorios/calidad-desoftware/downloads/3.%20Introduccion%20a%20los%20modelos%20de%20calida d.pdf



http://www.slideshare.net/guest768516/modelo-de-calidad-de-desarrollo-desoftware-cmmi

46

Control de Calidad Del Software

Recommend Documents