Modelos de Calidad de Software

MODELOS DE CALIDAD DE SOFTWARE
Ao de la Integracin Nacional y el Reconocimiento de Nuestra Diversidad
UNIVERSIDAD NACIONAL SAN LUIS GONZAGA DE ICA
TEMA :
CURSO INTEGRANTES
: :
CONTROL DE CALIDAD DE SOFTWARE Bautista Quispe Leydi Chaico Lebanoandrea Gavilan Pecho Luisa Guillen Martinez Margoth Mandujano Bendez Alexander Marca Juarez Mayda VIII Antonio Alonso Morales Loaiza
CICLO DOCENTE
: :
ICA PERU 2012
NDICE
ndice De Tablas Y Figuras Introduccin .. 1. Modelo 2. Modelos De Calidad... 3. Modelos De Calidad De Software.
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 .
(4) (5) (6) (6) (6)

(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. Mtricas . 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 Revisin.. II. Factores De Transicin.. III. Factores De Operacin .. 6.1.3. Criterios De Calidad .. 6.1.4. Mtricas De Calidad .. 6.2. Modelo De Boehm 6.2.1. Caractersticas De Alto Nivel .. 6.2.2. Caractersticas De Nivel Intermedio 6.2.3. Caractersticas Primitivas . 6.2.4. Comparacin De Modelos Mccall Boehm . 6.2.5. Evaluacin 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) Bibliografa . (46)
NDICE DE TABLAS Y FIGURAS

1. INDICE DE FIGURAS
Figura N1. Estructura De Modelos De Calidad Software Figura N2. Tipos de Modelos de Calidad Software Figura N3. Lnea de Tiempo de los Modelos de Calidad de Software Figura N4. Modelo de Boehm Figura N5. Modelo de REBOOT Figura N6. Estndar 9126 Figura N7. Caractersticas Modelo de Calidad para Calidad Interna y Externa Figura N8. Caractersticas de Vista en Uso Figura N9. Proceso del Modelos de Calidad ISO/IEC9126 Figura N10. Niveles del Modelo CMMI
10 11 13 22 28 30 31 35 38 44
2. INDICE DE TABLAS
Tabla N1. Beneficios Frente A Coste De Los Factores De Calidad Tabla N2. Ejemplos de Tipo de Modelos de Calidad Software Tabla N3. Modelo de McCall Tabla N4. Comparacin de Modelos McCall Boehm Tabla N5. Modelo de FURPS Tabla N6. Factores del Modelo de Calidad de Deutsch Tabla N7. Criterios del Modelo de Deutsch
8 13 19 23 24 27 27
INTRODUCCIN
Hoy en da nos encontramos en un mundo cada vez ms globalizado, donde cada da 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 evaluacin de la calidad del software Se debe entender que un modelo de calidad no es una metodologa 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 prediccin de confiabilidad y la gerencia de calidad durante el proceso de desarrollo y medicin de la complejidad de un sistema de software. En este presente documento muestra una breve descripcin 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 enfocndose a factores de calidad. Modelo Boehm introduce caractersticas de alto nivel, caractersticas de nivel intermedio y caractersticas 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 caractersticas (funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad
1. MODELO Un modelo es una representacin de un objeto, sistema o idea, de forma diferente al de la entidad misma. El propsito de los modelos es ayudarnos a explicar, entender o mejorar un sistema. Un modelo de un objeto puede ser una rplica exacta de ste o una abstraccin de las propiedades dominantes del objeto. 2. MODELOS DE CALIDAD Los Modelos de Calidad son herramientas que guan a las Organizaciones a la Mejora Continua y la Competitividad dndoles 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 captulos que sirven como referencia para estructurar un plan de calidad total en una empresa u organizacin, o de una de sus partes. Los modelos de calidad permiten: a. b. c. d. Definicin estructurada de criterios de evaluacin Especificacin de requisitos con relacin a ellos Descripcin de componentes en un marco comn Definicin de mtricas y prioridades
3. MODELOS DE CALIDAD DE SOFTWARE La obtencin de un software con calidad implica la utilizacin de modelos o procedimientos estndares para el anlisis, diseo, desarrollo y prueba del software que permitan uniformar la filosofa 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 prcticas para el ciclo de vida del software, enfocado en los procesos de gestin y desarrollo de proyectos. Construir un modelo de calidad es bastante complejo y es usual que estos modelos descompongan la calidad del producto software jerrquicamente en una serie de caractersticas y sub-caractersticas que pueden usarse como una lista de comprobacin de aspectos relacionados con la calidad.
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 ms competitiva. f) Aumentar la productividad, efectividad y utilidad de la empresa. g) Asegurar la satisfaccin 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 cules de los factores de calidad van a ser requisitos de calidad del sistema. Para ello hay que tener varias cosas en consideracin: 1. La relacin que tienen los factores con las caractersticas 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 rpidamente, la portabilidad es esencial; si se espera que ciertas funciones del sistema se utilicen por un largo perodo de tiempo, aunque el resto del sistema cambie, la facilidad de reutilizacin 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. 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. BENEFICIOS FRENTE A COSTE ALTO MEDIO BAJO
Correccin Fiabilidad Eficiencia Integridad Facilidad de Uso Facilidad de Mantenimiento Facilidad de Prueba Flexibilidad Portabilidad Reusabilidad Interoperabilidad
FACTOR
Tabla N1. 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
prcticamente todos los dems 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 automticamente 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 mtricas. E. Se debe entonces establecer valores deseables para los criterios en funcin de datos histricos, el promedio en la industria, etc. Se pueden establecer valores finales, es decir, los que se desea obtener una vez finalizado el desarrollo, y tambin valores intermedios o predictivos en cada perodo de medicin durante el desarrollo. F. Por ltimo, se debern establecer los valores mnimos aceptables. La explicacin para cualquier seleccin o decisin 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 mtricas, es decir, tomar las medidas necesarias b) Analizar los resultados de las mtricas c) Tomar medidas correctivas si es necesario, es decir, si los valores obtenidos estn por debajo de los valores mnimos aceptables. Estas medidas correctivas pueden afectar tanto al proceso de desarrollo como al proceso de gestin.
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 estn conectados. Los modelos de calidad son creados para proveer las bases para la evaluacin de software; por lo tanto a los atributos de calidad se les tiene que asignar mtricas que permitan su medicin. Generalmente tienen una estructura en tres niveles:
CALIDAD DE SOFTWARE
Factores de Calidad
Criterios de Calidad
Mtricas
Figura N1. Estructura De Modelos De Calidad Software
4.1. FACTORES DE CALIDAD: Se encuentran en el nivel ms alto de la jerarqua, representan la calidad desde el punto de vista del usuario, son las caractersticas que componen la calidad. Tambin 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 visin de la calidad desde el punto de vista del producto software. Tambin conocidos como Atributos de Calidad Internos. 4.3. METRICAS: Para cada uno de los criterios de calidad se definen un conjunto de Mtricas, que son medidas cuantitativas de ciertas caractersticas del producto que, cuando estn presentes, dan una indicacin 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 N2. Tipos de Modelos de Calidad Software
5.1. TIPOS DE MODELO DE CALIDAD DE PRODUCTO 5.1.1. MODELOS FIJOS Existe un catlogo de factores de calidad de partida que se usa como base para la evaluacin 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 tpica de un modelo de calidad fijo consiste en una estructuracin de los factores en una jerarqua multinivel, con un conjunto de factores de ms alto nivel, unos criterios que descomponen dichos factores, y eventualmente mtricas para la medida de cada criterio. La ventaja de estos modelos fijos es que proporcionan una vista comn 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 ms industrial FURPS (Grady y Caswell, 1987) 5.1.2. MODELOS DE CALIDAD A MEDIDA No existe ningn catlogo de factores de partida, y dichos factores deben ser identificados para cada proyecto. La idea que gua la construccin de estos modelos es que se debe partir de la identificacin de los objetivos a alcanzar. Dichos objetivos seran los factores ms abstractos que deben descomponerse en factores ms concretos hasta llegar a hacer operativos los objetivos, de forma que pueda ser medida su consecucin. As, los modelos son creados desde cero para todo nuevo proyecto. Existen diversas propuestas de mtodos 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 construccin es muy alto comparado con el de los modelos fijos, y la reutilizacin de modelos de un proyecto a otro es difcil, 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 ms 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 estndar ISO/IEC 9126-1 (2001)
12
ASPECTO PROYECTO (Ciclo de Vida del Software) ORGANIZACIN (Gobierno de TI) PROCESO (Procesos de la Empresa) PRODUCTO (Producto de Software)
MODELOS DE CALIDAD CMMI SPICE ISO 12207 ISO 9001 2008 ISO 9003 COBIT PMI PMBOOK ITIL PRINCE2 McCALL ISO 14598
Tabla N2. 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 N3. Lnea 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 Area de los EE.UU en 1977 que tena la misin de proporcionar las normas y orientacin de tcnicas para la adquisicin del software, es uno de los ms renombrados actualmente. Este modelo busca reducir la brecha entre usuarios y desarrolladores enfocndose en un nmero de factores de calidad que reflejen las prioridades de ambos. El modelo establece una jerarqua de Perspectivas (3), Factores (11), Criterios de Calidad (23) y Mtricas (41). Antes de utilizar este modelo hay que seguir las siguientes pautas: 1. Se aceptan los factores, criterios y mtricas que propone los modelos. 2. Se aceptan las relaciones entre factores y criterios, y entre criterios y mtricas. 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. Revisin Del Producto habilidad para ser cambiado. II. Transicin Del Producto adaptabilidad al nuevo ambiente. III. Operacin Del Producto caractersticas de operacin. 6.1.2. FACTORES DE CALIDAD I. FACTORES DE REVISIN La revisin 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 especificacin. II. FACTORES DE TRANSICIN. La transicin del producto incluye los siguientes factores de calidad: a) Portabilidad esfuerzo requerido para transferir entre distintos ambientes de operacin. 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 OPERACIN. La operacin del producto incluye los siguientes factores de calidad: a) Correctitud grado en el que el producto cumple con su especificacin. b) Confiabilidad la habilidad del producto de responder ante situaciones no esperadas. c) Eficiencia el uso de los recursos tales como tiempo de ejecucin y memoria de ejecucin. d) Integridad proteccin del programa y sus datos de accesos no autorizados. e) Usabilidad facilidad de operacin del producto por parte de los usuarios 6.1.3. CRITERIOS DE CALIDAD: A. CRITERIOS DEL FACTOR MANTENIBILIDAD Consistencia. Simplicidad. Consistencia. Auto-descripcin. Modularidad.
Pero la mantenibilidad ha cambiado bastante desde 1977, encontrar y corregir errores es slo un aspecto ms. Mantenibilidad est muy influenciado por el uso de buenas prcticas a lo largo de todo el ciclo de desarrollo algunas de estas buenas prcticas son: Seguir una metodologa bien definida. Usar buenas tcnicas de diseo, tanto de procedimientos como de datos, para aumentar cohesin y reducir acoplamiento. Observar la documentacin interna. Usar buenas prcticas de programacin: nombres significativos, cdigo legible, etc.
15
B. CRITERIOS DEL FACTOR FLEXIBILIDAD Expandibilidad. Generalidad. Auto-descripcin. Modularidad.
Con el correr de los aos este criterio se ha fusionado con mantenibilidad de hecho, en la definicin original, dos de los criterios de flexibilidad estaban compartidos con mantenibilidad. C. CRITERIOS DEL FACTOR TESTEABILIDAD Simplicidad. Instrumentacin. Dado su ubicacin en tradicionales modelos de ciclo de vida de software, la facilidad de testing se define claramente como un criterio de calidad. El testeo interacta 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 automticas, buenas estrategias de cohesin y de diseo, y buenas prcticas de programacin McCall defini originalmente mtricas para testeabilidad consistentes en una matriz de complejidad que involucra nmero y tamao de mdulos, tamao de procedimientos, profundidad de anidamiento, nmero de errores por unidad de tiempo, etc. D. CRITERIOS DEL FACTOR PORTABILIDAD Auto-descripcin. Modularidad. Independencia de la mquina. Independencia del sistema operativo.
Algunos autores (Sommerville) lo consideran parte de la reusabilidad se favorece mediante el seguimiento de estndares, 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-descripcin. Independencia de la mquina. Independencia del sistema operativo.
Se puede favorecer la reusabilidad usando libreras de software, y tcnicas de programacin orientada a objetos hay que tener en cuenta que el desarrollo de cdigo reusable cuesta ms tiempo y dinero existe un factor econmico difcil de medir: el costo de cdigo reusable y la ganancia por reusar cdigo ya desarrollado. F. CRITERIOS DEL FACTOR INTEROPERABILIDAD Modularidad. Interoperabilidad en comunicacin. Interoperabilidad en datos. La interoperabilidad est relacionada con la reusabilidad en la actualidad su importancia ha crecido debido al creciente inters de conectarse con sistemas legacy se favorece mediante la adopcin de estndares. G. CRITERIOS DEL FACTOR CORRECTITUD Trazabilidad. Completitud. Consistencia. Correctitud es un factor muy difcil de identificar debido a la falta de terminologa estndar se lo pueden confundir con otros factores, tales como confiabilidad e integridad para medirlo es necesario tener disponible una especificacin formal de los requerimientos, cosa muy rara salvo en proyecto de alto presupuesto y sistemas crticos las tcnicas para verificarlo pueden ser: inspecciones de cdigo, verificacin matemtica y analizadores estticos 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 tcnica de programacin tales como tolerancia a las fallas, manejo de excepciones y programacin defensiva ayudan puede ser medido con medidas como: I. Tiempo medio entre fallas. Tiempo medio antes de mantenimiento. Tiempo medio antes de recuperacin. Probabilidad de falla.
CRITERIOS DEL FACTOR EFICIENCIA Eficiencia en tiempo. Eficiencia en espacio. Muchas tcnicas favorecen este factor: el lenguaje de programacin, el sistema operativo, optimizacin de algoritmos, normalizacin de datos.
J.
CRITERIOS DEL FACTOR INTEGRIDAD Control de acceso. Auditora de acceso. Involucra tanto evitar el acceso malintencionado, as como los daos causados por errores involuntarios de usuarios autorizados.
K. CRITERIOS DEL FACTOR USABILIDAD Operabilidad. Entrenamiento. Comunicacin. Volumen de E/S. Tasa de E/S.
La usabilidad ha cambiado mucho desde la poca de McCall incluye aspectos tales como adaptabilidad, aprendizaje, adecuacin al contexto algunos autores consideran por ejemplo que facilidad de aprendizaje es un factor de calidad independiente se puede subdividir en: Ergonoma general el equipo es adecuado para el uso previsto. Ergonoma de software estilos de dilogos, metforas, diseo de pantallas, etc.
18
Tabla N3. Modelo de McCall ASPECTOS O EJES

REVISIN DE PRODUCTO OPERACIN DE PRODUCTO TRANSCISIN DE PRODUCTO
CRITERIOS
19 Fiabilidad Eficiencia Flexibilidad
FACTORES
Facilidad de Uso
Reusabilidad
Interoperabilidad
Integridad(Seguridad)
Correccin(Exactitud)
Facilidad de Mantenimiento
Facilidad de Prueba
Transportabilidad
Facilidad de Operacin Facilidad de Comunicacin Facilidad de Aprendizaje Formacin Control de Accesos Facilidad de Auditoras Seguridad Completitud Trazabilidad Precisin Tolerancia a Fallos Modularidad Simplicidad Exactitud Eficiencia en Ejecucin Concisin Auto Descripcin Instrumentacin Capacidad de Expansin Generalidad
Independencia entre Sistemas y Hardware
Independencia del Hardware Compatibilidad de Comunicaciones Compatibilidad de Datos Consistencia Eficiencia en Almacenamiento Estandarizacin de Datos
6.1.4. MTRICAS DE CALIDAD La medicin de cualquiera de estos factores est definida en este modelo en base a 41mtricas para cada criterio existe una lista de condiciones que se deben cumplir en distintas etapas: requerimientos (R), diseo (D), implementacin (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 denidas, o externas [R,D,I] Todas las funciones denidas son usadas [R,D,I] Todas las condiciones y procesamientos estn denidos para cada punto de decisin [R,D,I] Todos los parmetros formales y actuales coinciden [D,I] Todos los reportes de problemas han sido resueltos [R,D,I] El diseo concuerda con los requerimientos [D] El cdigo concuerda con el diseo [I]
Entonces se cuentan la cantidad de s en cada etapa, resultando en la mtrica 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 ms conocido es el presentado por Barry Boehm en1978 este modelo introduce caractersticas de alto nivel, caractersticas de nivel intermedio y caractersticas primitivas, cada una de las cuales contribuye al nivel general de calidad.
20
6.2.1. CARACTERSTICAS DE ALTO NIVEL Las caractersticas de alto nivel representan requerimientos generales de uso pueden ser: Utilidad per-se cuan (usable, confiable, eficiente) es el producto en s mismo. Mantenibilidad cun fcil es modificarlo, entenderlos y retestearlo. Utilidad general si puede seguir usndose si se cambia el ambiente. 6.2.2. CARACTERSTICAS DE NIVEL INTERMEDIO Las caractersticas 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. CARACTERSTICAS PRIMITIVAS El nivel ms bajo corresponde a caractersticas directamente asociadas a una o dos mtricas de calidad: A. DE PORTABILIDAD: Independencia de dispositivos. Auto-contencin. De confiabilidad Auto-contencin. Exactitud. Completitud. Consistencia. Robustez/integridad.
B. DE EFICIENCIA: Accesibilidad. Eficiencia de uso de dispositivos.
21
C. DE USABILIDAD: Robustez/integridad. Accesibilidad. Comunicacin. D. DE TESTEABILIDAD: Comunicacin. Auto descripcin. Estructuracin. E. DE ENTENDIBILIDAD: Consistencia. Estructuracin. Concisidad. Legibilidad.
F. DE MODIFICABILIDAD: Estructuracin. Aumentabilidad.

INDEPENDENCIA DE DISPOSITIVO AUTO - CONTENCIN
PRECISIN
Portabilidad Fiabilidad Eficiencia UTILIDAD GENERAL

POR LA UTILIDAD
COMPLETITUD
ROBUSTEZ - INTEGRIDAD
CONSISTENCIA
CONTABILIDAD
Ingeniera Humana Prueba
EFICIENCIA DE DISPOSITIVO
ACCESIBILIDAD
Mantenibilidad
Entendibilida d Modificabilidad
COMUNICABILIDAD AUTO - DESCRIPTIVO
ESTRUCTURACIN
CONCISIN
LEGIBILIDAD
Figura N4. Modelo de Boehm
AUMENTABILIDAD
22
6.2.4. COMPARACIN 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 ms amplio de caractersticas primarias la mantenibilidad est ms desarrollada en Boehm. CRITERIO Correctitud Integridad Eficiencia Testeabilidad Flexibilidad Portabilidad Modificabilidad Entendibilidad Confiabilidad Usabilidad Mantenible Interoperabilidad Reusabilidad Claridad Documentacin Validez McCALL + + + + + + BOEHM + + + + + + + + + + + + + +
+ + + + +
Tabla N4 Comparacin de Modelos McCall - Boehm
6.2.5. EVALUACIN DE LOS MODELOS DE MCCALL Y BOEHM Estos modelos tienen sus lmites: Es difcil que las caractersticas y sub-caractersticas sean siempre perfectamente independientes falta una asociacin explcita entre los modelos y el proceso de software, cmo realizar software de calidad las caractersticas son en general propiedades abstractas medible mediante mtricas. No siempre existe una relacin perfectamente lineal entre los valores de las mtricas y las caractersticas 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: Aadir tres nuevos criterios de valoracin: 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 acrnimo de FURPS: funcionalidad (Functionality), usabilidad (Usability), confiabilidad (Reliability), desempeo (Performance) y capacidad de soporte (Supportability). A continuacin se presenta la clasificacin de los atributos de calidad que se incluyen en el modelo, junto con las caractersticas asociadas a cada uno.
FACTOR DE CALIDAD FUNCIONALIDAD ATRIBUTOS Caractersticas y Capacidad del Programa Generalidad de las Funciones Seguridad del Sistema Factores Humanos Factores Estticos Consistencia de la Interfaz Documentacin Frecuencia y Severidad de las Fallas Exactitud de las Salidas Tiempo Medio de Fallos Capacidad de Recuperacin ante Fallas Capacidad de Prediccin Velocidad del Procesamiento Tiempo de Respuesta Consumo de Recursos Rendimiento Efectivo Total Eficacia Extensibilidad Adaptabilidad Capacidad de Pruebas Capacidad de Configuracin Compatibilidad Requisitos de Instalacin
FACILIDAD DE USO
CONFIABILIDAD
RENDIMIENTO
CAPACIDAD DE SOPORTE
Tabla N5. Modelo de FURPS
24
6.5. MODELO GILB Modelo de calidad creado por Gilb en 1988. Este modelo presenta como aspecto fundamental la definicin 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 medicin de este. Estos atributos son: a. Capacidad de trabajo: Evala 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 diseado. 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 prctica. Sub-atributos: requisitos de entrada, requisitos de aprendizaje y habilidad de manejo. Gilb propone caractersticas como la correccin, 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 caractersticas: a. Correccin: Grado en el que el software lleva a cabo su funcin 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 utilizacin de otros dos atributos como base: Amenaza. es la probabilidad (que se puede estimar o deducir de la evidencia emprica) 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 caractersticas se pueden medir mediante varias sub-caractersticas o mtricas detalladas. Para cada una de ellas se debe especificar los siguientes conceptos: Nombre y definicin de la caracterstica. Escala o unidades de medicin. Recoleccin 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, aadindole 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 categoras: a) Necesidades Operacionales. Estn relacionadas con la capacidad del software para realizar las tareas que se supone debe llevar a cabo Funcional Realizacin b) Necesidades de Mantenimiento. Se relacionan con la capacidad de modificar el software para ayudar al usuario
26
Cambio Gestin 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 . C
Tabla N6. Factores del Modelo de Calidad de Deutsch
FACTORES DE CALIDAD Integridad Fiabilidad Supervivencia Utilizabilidad Eficiencia Correccin Seguridad Interoperabilidad Mantenibilidad Expansibilidad Flexibilidad Transportabilidad Reutilizabilidad Verificable - Gestionable
Realizacin Cambio Gestin
6.6.2. CRITERIOS: CRITERIOS Accesibilidad al sistema Consistencia Alcance Funcional Distributivo Aumentabilidad Eficiencia de Almacenamiento Autonoma Eficiencia de Comunicaciones Auto Descriptivo Eficiencia de Proceso Calidad de Documentacin Entrenamiento Compatibilidad del Sistema Gestin de Anomalas Completitud Gestin Segura Comn Generalidad
Tabla N7. Criterios del Modelo de Deutsch
Independencia Modularidad Operatividad Precisin Simplicidad Soporte Seguimiento Virtualidad Visibilidad
6.7. MODELO DE CALIDAD DE DROMEY Un modelo presentado por el Sr. R. Geoff Dromey basados en que reconoce que evaluacin de la calidad es diferente para cada producto y que una idea ms dinmica para modelar el proceso es necesario lo suficientemente amplia como
27
para solicitar los distintos sistemas. Dromey se centra en la relacin 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 evaluacin 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 evaluacin. Lista de componentes y mdulos 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 evaluacin de dicho software con relacin a esos criterios.
FIABILIDAD OBSERVADA
CONSISTENCIA
FIABILIDAD
AUTO - DESCRIPTIVO
MODELO DE CALIDAD
MANTENIBILIDAD
SIMPLICIDAD MODULARIDAD SEGUIMIENTO

COMPLEJIDAD DE COMPONENTES COMPLEJIDAD DEL CODIGO
PRUEBAS
Figura N5. Modelo de REBOOT
28
6.9. MODELO ISO 6.9.1. ISO 9000 Las siglas ISO significa Organizacin Internacional para las Standardization. El ISO es la organizacin responsable de toda una serie de normas de las cuales la norma ISO 9000 Probablemente es el ms conocido, difundir y utilizar. a) ISO 19011:2000 "Directrices para la auditora Gestin de la Calidad Sistemas. b) ISO 9004:2000"Directrices para la Calidad Gestin de las Organizaciones " c) ISO 9000:2000"Conceptos y Terminologa " d) ISO 9001:2000 "Requisitos para Aseguramiento de la Calidad " e) ISO 9001 es un estndar de calidad internacional de gestin de sistemas aplicables a las organizaciones en todo tipo de las empresas. ISO 9001 internos centra en los procesos de una organizacin y mtodos y externamente en la gestin 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 evaluacin de la calidad de software. En 1994 se entendi que era necesario modificar y adaptar la norma. En esta versin se introducen por primera vez los conceptos de calidad interna y calidad externa. Adems se cre una nueva norma (ISO 14598) que asuma el modelo del proceso de evaluacin antes incluido en la norma ISO 9126. En 2005 se crea una nueva versin de esa norma, la ISO/IEC 25000, que entrega una gua para el uso de los nuevos estndares internacionales llamados Requisitos y Evaluacin de Calidad de Procesos de Software (SQuaRE). La ISO/IEC 25000 establece criterios para la especificacin de requisitos de calidad del software, medidas y evaluacin, adems entrega un modelo de calidad que unifica las definiciones de calidad de los clientes con los atributos durante el desarrollo.
29
El estndar 9126 propone un modelo de calidad que se divide en tres vistas: interior, exterior y de uso. Estas estn compuestas por caractersticas, las que se dividen en sub caractersticas, y estas a su vez se componen de atributos. El estndar 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 Mtricas externas (Mide el software en s mismo) ISO 9126-3 Mtricas de internas (mide el comportamiento del sistema) ISO 9126-4 Calidad en el uso de mtricas (mide el efecto de usar el software en un contexto especfico)
CALIDAD DEL PROCESO
CALIDAD INTERNA 9 1 2 6 1
9126 3
CALIDAD EXTERNA
9126 2
CALIDAD EXTERNA
9126 4
Figura N6 Estndar 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 caractersticas 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 implementacin, revisin y prueba del cdigo 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 diseado. La norma ISO/IEC 9126 define la calidad externa como: La calidad de un producto software debera ser evaluado usando un modelo de calidad. ISO 9126-1 propone un modelo de calidad categorizando la calidad de los atributos software en seis caractersticas, los cuales son subdivididos en subcategoras. Las subcategoras pueden ser medidas con mtricas internas o externas. La calidad externa e interna establecen que cualquier componente de calidad del software puede ser descrito en trminos de una o ms de seis caractersticas bsicas, las cuales son: funcionalidad, confiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad; cada una de las cuales se detalla a travs de un conjunto de sub caractersticas que permiten profundizar en la evaluacin de la calidad de productos de software y la calidad de las necesidades del usuario o calidad de uso que posee cuatro caractersticas que ayuden al usuario a cumplir sus objetivos, ellas son: eficacia, productividad, seguridad y satisfaccin.
Figura N7. Caractersticas Modelo de Calidad para Calidad Interna y Externa 31
1.1. Funcionalidad: Las funciones y propiedades satisfacen las necesidades explcitas e implcitas; 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 diseado. Para este propsito se establecen los siguientes atributos: Adecuacin: 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 precisin. Interoperabilidad: Capacidad del producto software para interactuar con uno o ms sistemas especificados. Seguridad de acceso: Capacidad del producto software para proteger informacin 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 ejecucin bajo condiciones normales en un periodo de tiempo establecido. Las sub caractersticas que el estndar 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 recuperacin: 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 fcil 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 cmo 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 aplicacin. Capacidad para ser operado: Capacidad del producto software que permite al usuario operarlo y controlarlo. Capacidad de atraccin: Capacidad del producto software para ser atractivo al usuario. Cumplimiento de la usabilidad: Capacidad del producto software para adherirse a normas, convenciones, guas de estilo o regulaciones relacionadas con la usabilidad. 1.4. Mantenibilidad: Es fcil de modificar y verificar? Se refiere a los atributos que permiten medir el esfuerzo necesario para realizar modificaciones al software, ya sea por la correccin 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 modificacin 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. 1.5. Portabilidad: Es fcil 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: Evala la oportunidad para adaptar el software a diferentes ambientes sin necesidad de aplicarle modificaciones. Facilidad de Instalacin: Es el esfuerzo necesario para instalar el software en un ambiente determinado. Conformidad: Permite evaluar si el software se adhiere a estndares 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 especficos con eficacia, productividad, seguridad y satisfaccin en contextos de uso especficos. 1.6. Eficiencia: Capacidad que permite que los usuarios alcancen objetivos con exactitud e integridad, en un contexto especifico.
34
convenciones
Comportamiento
temporal:
Capacidad
del
producto
software para proporcionar tiempos de respuesta, tiempos de proceso y potencia apropiados, bajo condiciones determinadas. Utilizacin de recursos: Capacidad del producto software para usar las cantidades y tipos de recursos adecuados cuando el software lleva a cabo su funcin bajo condiciones determinadas. Cumplimiento de la eficiencia: Capacidad del producto software para adherirse a relacionadas con la eficiencia. B. CALIDAD EN USO
La norma ISO/IEC 9126-1 define la calidad en uso como:
normas
convenciones
La perspectiva del usuario de la calidad del producto software cuando ste es usado en un ambiente especfico y un contexto de uso especfico. sta mide la extensin 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 caractersticas
VISTA EN USO
Efectividad
Productividad
Seguridad
Satisfaccin
Figura N8. Caractersticas de Vista en Uso
2.1. Efectividad: capacidad del software de facilitar al usuario alcanzar Objetivos con precisin y completitud.
35
2.2. Productividad: Capacidad del software de permitir a los usuarios gastar la cantidad apropiada de recursos en relacin a la efectividad obtenida. 2.3. Seguridad: Capacidad del software para cumplir con los niveles de riesgo emitidos tanto para posibles daos fsicos como para posibles riesgos de datos. 2.4. Satisfaccin: Capacidad del software de cumplir con las expectativas de los usuarios en un contexto determinado.
6.9.2.2.1. MTRICAS DE CALIDAD DE PRODUCTO Las mtricas de calidad de producto se aplican a los diversos atributos del producto y que permiten determinar posteriormente los niveles de calidad del producto. Las mtricas que se pueden aplicar de acuerdo a los atributos estn 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 sealan que las mtricas presentadas no pretenden ser exhaustivas, ni limita la posibilidad de usar otras mtricas de acuerdo a las necesidades del usuario. El anexo A de la norma ISO/IEC 9126-1 seala 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 mayora de las caractersticas. Por ejemplo, la confiabilidad puede ser medida externamente observando el nmero de fallas en un perodo de tiempo de ejecucin dedo durante un ensayo del software e internamente examinando las especificaciones detalladas y el cdigo fuente para determinar el nivel de la tolerancia a fallas. Los atributos internos seran los indicadores de los atributos externos. Un atributo interno puede influenciar a una o ms caractersticas, y una caracterstica puede ser influenciada por ms de un atributo. En este modelo la totalidad de atributos de la calidad del producto software son clasificados en una estructura arborescente jerrquica de caractersticas y sub caractersticas. El nivel ms alto de esta estructura consiste en caractersticas de calidad y el nivel ms bajo consiste en atributos de calidad de software.
36
La jerarqua no es perfecta, porque algunos atributos pueden contribuir a ms de una sub caracterstica1. A. Mtricas externas: son aquellas que miden el comportamiento de todo el software o parte de l, a travs 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 operacin y sabemos si cumple con la calidad esperada. La norma ISO/IEC 9126-1 seala que: Antes de adquirir o usar un producto software este debera ser evaluado usando la mtrica basada en los objetivos del negocio relacionados al uso, explotacin y administracin del producto en una organizacin y un ambiente tcnico especfico2. B. Mtricas internas: Las mtricas internas pueden ser aplicadas durante el diseo y la codificacin del producto software no ejecutable (por ejemplo cdigo fuente) y proporciona a todos los involucrados el beneficio de conocer la calidad del producto durante su construccin y tomar decisiones sobre esa base para conseguir el producto con la calidad esperada. La norma ISO/IEC 9126-1 seala que: Las mtricas internas miden atributos internos o indican los atributos externos a travs del anlisis de las propiedades estticas de productos intermedio o entregables del producto software. Las medidas de las mtricas internas usan nmeros o frecuencias de elementos de composicin de software los cuales aparecen por ejemplo en las sentencias de cdigo fuente, grficos de control, flujo de datos y representaciones de estado de transicin.
1 2
http://inform.pucp.edu.pe/~edavila/publicaciones/calidadproductosoftware_ok.pdf Libro Calidad Del Producto Y Proceso Software, CALERO, C, pg. 38
37
6.9.2.2.2. LA CALIDAD EN EL USO: Si bien el modelo indica que estas sub caractersticas a su vez se subdividen en atributos, no se especifica cules son esos atributos, ya que se entiende que estos son entidades dependientes del producto software y variarn segn vare la naturaleza del software analizado: lenguaje, paradigma de programacin, complejidad tecnolgica, etc. a. Mtricas de uso: Mide como un producto cumple con las necesidades de los usuarios para alcancen sus objetivos. La evaluacin de la calidad en el uso valida la calidad del producto software en escenarios especficos de uso. Este estndar 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 Caractersticas de Calidad: Factores (especificar): Ellos describen la visin externa del software, como es visto por los usuarios. Criterios (construir): Ellos describen la visin interna del software, con es visto por el desarrollador. Mtricas (controlar): Ellas son definidas y usadas para proveer una escala y mtodo 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 distincin similar es hecha entre la validacin y la verificacin.
Contextos de Uso
Influye Proceso de Calidad Depende de Calidad Interna
Influye Calidad Externa Depende de
Influye Calidad En Uso Depende de
PROVEEDOR
USUARIO
Figura N9. Proceso del Modelos de Calidad ISO/IEC9126
38
6.9.2.2.3. UTILIDAD DE LAS NORMAS ISO / IEC 9126 Este estndar 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 definicin de requisitos, identificar requisitos de calidad de software, objetivos de diseo y prueba, criterios de aseguramiento de la calidad, etc. La calidad de cualquier proceso del ciclo de vida del software (estndar 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 estticas o productos intermedios) o atributos externos (comportamiento del cdigo cuando se ejecuta). El mundo globalizado exige cada vez ms la aplicacin de estndares internacionales que garanticen la calidad de los productos. Por esta razn, es necesario que todo aquel que se dedica al desarrollo de software incluya en sus procesos, estndares de calidad que permitan certificarse en alguno de los modelos. Aqu se ha presentado un estndar, el ISO-9126, el cual establece una gua para la evaluacin 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 debern incluirse instrumentos de medicin que permitan calificar cuantitativamente cada una de las caractersticas aqu presentadas. Es importante mencionar, que dependiendo de los distintos tipos de aplicaciones las mtricas podrn variar, ya que aunque las caractersticas expuestas son comunes a la totalidad de los productos, cada software particular requiere una evaluacin especfica El estndar 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 aos para la caracterizacin de la calidad del producto software.
39
a) ISO / IEC 15504 (SPICE6) La norma ISO / IEC 15504: Tecnologas de la Informacin Software Proceso de Evaluacin es un estndar internacional a gran marco para la evaluacin de proceso que tiene la intencin de abordar todos los procesos que intervienen en: Software de adquisicin Desarrollo Operacin Suministro Mantenimiento Apoyo ISO / IEC 15504 se compone de 9 componentes que cubren los conceptos, modelo de referencia y mejora de procesos gua, modelo de evaluacin y guas, las calificaciones de los evaluadores, y la gua para determinar el proceso de proveedor capacidad: Dada la estructura y el contenido de la norma ISO / IEC 15504 es la documentacin ms 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 funcin 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 ampliacin 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 electrnico 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-caractersticas 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 adaptacin de la ISO/IEC 9126para servidores de correo electrnico 6.19. MODELO BOTELLA (2003). Proponen un modelo para la seleccin de ERP y tambin escogen como marco de trabajo el estndar 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 caracterstica 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. Caractersticas (contenido, presentacin y navegacin)
41
6.21. MODELO GQM (GOAL QUESTION METRIC). Enfoque de medicin para evaluar la calidad del software basado en la identificacin de objetivos a lograr. A continuacin se presenta la estructura del modelo I. II. 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 medicin con respecto a caractersticas de calidad seleccionadas para un punto de vista. Nivel cuantitativo (metric - metrica)
III. IV.
V.
Se asocia un conjunto de mtricas 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 estn 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
OLSINA, Luis. Ingeniera Web; Marco de medicin y evaluacin de calidad. Departamento de informtica. Universidad Nacional de San Luis - La Rioja Catamarca. Ao 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: Gestin de requisitos Planificacin de proyectos Seguimiento y control de proyectos Gestin de proveedores Aseguramiento de la calidad Gestin de la configuracin. Nivel 3. Definido: Proceso caracterizado por la organizacin y proactivo. Alcanzar este nivel significa que la forma de desarrollar proyectos (gestin e ingeniera) est definida, por definida quiere decir que est establecida, documentada y que existen mtricas (obtencin de datos objetivos) para la consecucin de objetivos concretos. Los procesos que hay que implantar para alcanzar este nivel son: Desarrollo de requisitos Solucin Tcnica Integracin del producto Verificacin Validacin Desarrollo y mejora de los procesos de la organizacin Definicin de los procesos de la organizacin Planificacin de la formacin Gestin de riesgos Anlisis y resolucin 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 organizacin. Se usan mtricas para gestionar la organizacin. Los procesos que hay que implantar para alcanzar este nivel son: Gestin cuantitativa de proyectos Mejora de los procesos de la organizacin
43
Nivel 5. En Optimizacin: Enfoque en la mejora del proceso Los procesos de los proyectos y de la organizacin estn orientados a la mejora de las actividades. Mejoras incrementales e innovadoras de los procesos que mediante mtricas son identificadas, evaluadas y puestas en prctica. Los procesos que hay que implantar para alcanzar este nivel son: Innovacin organizacional Anlisis y resolucin de las causas.
Figura N10. Niveles del Modelo CMMI
44
Conclusiones
Para obtener el xito en la produccin de software debemos hacerlo con calidad y demostrando el grado de sta, calificando como buena. Esto slo es posible con la implantacin de un Sistema para el Aseguramiento de la Calidad del Software directamente relacionado con la poltica establecida para su elaboracin y que est en correspondencia con las definiciones internacionales de calidad, ampliamente aceptada, y por los estndares que se manejan hoy en da.
Recomendaciones
Finalmente como recomendacin se sugiere la aplicacin de las normativas establecidas a nivel internacional, mediante la aplicacin de mtodos 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

Modelos de Calidad de Software

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modelos de Calidad de Software

Uploaded by

Copyright:

Available Formats

MODELOS DE CALIDAD DE SOFTWARE

Ao de la Integracin Nacional y el Reconocimiento de Nuestra Diversidad

UNIVERSIDAD NACIONAL SAN LUIS GONZAGA DE ICA

ICA PERU 2012