I
Universidad de las Ciencias Informáticas
Facultad 3
Trabajo de Diploma para optar por el título de Ingeniero en Ciencias Informáticas
Título: Propuesta de Plan de Aseguramiento de la Calidad para el Centro de Soluciones de Gestión, CESGE.
Autor: Zenia Macias Almira
Tutor: Ing. Adieren Acosta Zamora Colaborador: Ing. Sasha Valdés Jimenez
Ciudad de la Habana
Junio del 2009
II
“La responsabilidad nuestra es luchar porque la calidad del producto que aquí se haga sea de las mejores y la mejor posible...”
Ernesto “Che” Guevara
III
A mis padres, por ser mis motores impulsores, y lo que más quiero en esta vida…
A Leo por enseñarme que el amor si existe.
IV A mis padres, por ser los protagonistas de mi vida, y por haberme educado y convertido en la persona que soy hoy, para ellos va todo mi esfuerzo y dedicación. A mi mamita linda, que no me ha dado la espalda jamás y ha sido mi mejor amiga toda mi vida, mi ángel guardián. A mi papito, que me ha ayudado siempre y ha sido el mejor de los padres.
A mi padrastro Caste, por haberme ayudado tanto y haberme inculcado que la palabra de orden era
“Estudiar, estudiar y estudiar”.
A mi novio Leo por estar siempre para mí, por darme todo el amor que necesito, que es bastante, y hacerme la persona más feliz del mundo. A ti, gracias.
A mis hermanos Arley y Yesenia, por quererme mucho.
A mi primo Santi, por ayudarme y ser mi apoyo en este lugar. Por ser el mejor de los primos. A Yuselis por tanto cariño.
A mi madrastra Dayki, porque se ha convertido en una buenísima amiga, y sin duda la mejor de las madrastras, por todo el cariño que me ha dado.
A mi tutora Adieren por preocuparse por mi trabajo y a Sasha que me ayudó mucho.
A Yeisel, mi amigo del alma, por apoyarme tanto, en todos los momentos.
A las chicas superpoderosas Daymí y Yani, por ser tan buenas amigas y soportarme todo este tiempo (se que ha sido difícil).
A todos los amigos que hice en la universidad, y que no menciono por miedo que se me quede alguno, muchísimas gracias, ha sido todo un placer contar con su amistad.
A todos los profesores que han incidido en mi formación.
V Al Comandante Fidel Castro, por haber creado esta Universidad, haberme dado la posibilidad de formarme en ella.
A mis compañeros de trabajo del ERP-Cuba, que ha sido el mejor equipo de trabajo que jamás tendré.
A las muchachitas de la subdirección de calidad, Yesla, Dailin y todos los demás que son muchos. Gracias por todo.
A mi amiga Yadira, por ser mi confidente y quererme tanto.
A todas las personas que de una forma u otra me han ayudado en mi paso por este lugar… Gracias
VI Resumen
Actualmente en la UCI existen un gran número de proyectos que desarrollan software de gestión, entre ellos el ERP-Cuba. Por esta razón se ha creado un centro que agrupará estos proyectos, llamado Centro de Soluciones de Gestión (CESGE). En dicho centro se hace necesario garantizar la calidad de cada uno de los productos de software resultantes, por lo que se necesita crear un Plan que rija las actividades de aseguramiento y control de calidad que se lleven a cabo en el mismo. En el presente Trabajo de Diploma se propone un plan de aseguramiento para el centro, para su elaboración, se abordan los aspectos teóricos que ayuden a tener dominio del tema, se estudian y analizan cada uno de los aspectos necesarios para elaborar la propuesta, para adaptarlos a las especificidades y características del centro.
Se valida la propuesta consultando los criterios de los expertos para determinar la probabilidad de éxito de la misma.
Palabras claves
Software de gestión, CESGE, Plan, Aseguramiento, Calidad.
VII Tabla de Contenido
Introducción ... 1
Capítulo 1: “fundamentación teórica” ... 5
1.1. Introducción. ... 5
1.2. Calidad de software. Conceptos fundamentales. ... 5
1.2.1. Calidad de software. ... 5
1.2.2. Sistema de calidad ... 6
1.2.3. Gestión de la calidad ... 7
1.2.4. Control de la calidad ... 7
1.2.5. Aseguramiento de la calidad (SQA) ... 8
1.2.5.1. Actividades de SQA ... 10
1.2.5.2. Grupo SQA en un proyecto. ... 12
1.2.5.3. Ventajas y desventajas del SQA. ... 12
1.2.6. Coste de la calidad. ... 13
1.2.7. Modelo de calidad CMMI. ... 15
1.2.7.1. Área de proceso Aseguramiento de la Calidad de los Procesos y Productos ... 21
1.2.7.2. Área de proceso de Verificación ... 23
1.2.7.3. Área de proceso de Validación ... 24
1.3. Plan de aseguramiento de la calidad ... 25
1.3.1. Plan de aseguramiento de la calidad. Conceptos fundamentales. ... 25
1.3.1.1. Normas y estándares. ... 26
1.3.1.2. Métricas ... 27
1.3.1.3. Auditorías. ... 29
1.3.1.4. Pruebas de software ... 30
VIII
1.3.1.5. Revisiones. ... 31
1.3.1.6. Revisiones Técnicas Formales (RTF). ... 31
1.3.1.7. Verificación y Validación. ... 32
1.3.1.8. Gestión de configuración. ... 33
1.3.2. Técnicas, herramientas y metodologías. ... 33
1.3.2.1. Herramientas. ... 34
1.3.2.2. Técnicas que se utilizan para realizar las Pruebas ... 38
1.3.2.3. Técnicas utilizadas en las auditorías. ... 39
1.3.3. Estudio de planes existentes. ... 42
1.3.3.1. Plan de aseguramiento de calidad propuesto por IEEE Std. 730-2002. ... 42
1.3.3.2. Plan de aseguramiento propuesto por el grupo SQA de la UCI. ... 50
1.4. Conclusiones ... 51
Capítulo 2 “propuesta del plan de aseguramiento de la calidad” ... 52
2.1. Introducción ... 52
2.2. Propuesta del plan de aseguramiento. ... 52
2.2.1. Propósito ... 52
2.2.2. Alcance ... 52
2.2.3. Objetivos de Calidad ... 52
2.2.4. Organización ... 57
2.2.5. Roles y responsabilidades. ... 60
2.2.6. Actividades y responsabilidades ... 65
2.2.7. Métricas. ... 75
2.2.8. Estándares y guías. ... 79
2.2.9. Revisiones y auditorías. ... 80
2.2.10. Pruebas y evaluación. ... 87
IX
2.2.11. Resolución de problemas y actividades de corrección. ... 100
2.2.12. Herramientas a utilizar en el centro para desarrollar pruebas, revisiones y auditorías. ... 106
2.2.13. Gestión de Configuración ... 106
2.2.14. Registros de Calidad. ... 108
2.2.15. Entrenamiento ... 111
2.3. Conclusiones ... 113
Capítulo 3 “Validación de la solución propuesta” ... 114
3.1. Introducción ... 114
3.2. Validación de la solución ... 114
3.2.1. Evaluación de la propuesta. ... 114
3.2.2. Método Experto ... 114
3.3. Conclusiones ... 121
Conclusiones Generales ... 123
Recomendaciones ... 124
Bibliografía ... 125
Anexos... 128
Anexo 1 Actividades de aseguramiento por fases ... 128
Anexo 2 Actividades de entrenamiento ... 129
Anexo 3 Aval ... 130
Anexo 4 Encuesta 1 a realizarle a los Expertos ... 131
Anexo 5 Encuesta 2 a realizarle a los Expertos. ... 133
Anexo 6 Tabla de Distribución Chi Cuadrado ... 135
Glosario de términos ... 136
X Índice de figuras.
Figura 1: Coste de resolución de fallos ... 14
Figura 2: Representaciones del modelo CMMI. ... 17
Figura 3: Modelo de McCall ... 28
Figura 4: Organigrama del Centro. ... 57
Figura 5: Organigrama de la Subdirección de Calidad. ... 57
Figura 6: Desglose por Perfiles de Cargo. ... 58
Figura 7: Procedimiento para las revisiones y auditorías. ... 82
Figura 8: Proceso para el Inicio de las auditorías o revisiones. ... 82
Figura 9: Actividades para el desarrollo de las auditorías y revisiones. ... 83
Figura 10: Actividad de fin de la auditoría o revisión. ... 84
Figura 11: Actividad de seguimiento a las auditorías o revisiones. ... 85
Figura 12: Procedimiento para realizar las pruebas. ... 89
Figura 13: Actividad Preparación de las pruebas. ... 90
Figura 14: Realización de la actividad de entrega. ... 91
Figura 15: Proceso de revisión de los artefactos. ... 93
Figura 16: Proceso de corrección. ... 95
Figura 17: Liberación de un artefacto. ... 96
Figura 18: Procedimiento para ejecutar las acciones correctivas ... 101
Figura 19: Proceso de ejecución de las acciones correctivas. ... 102
Figura 20: Subproceso de definición de acciones correctivas ... 103
Figura 21: Ciclo de vida de una acción correctiva ... 104
Figura 22: Organización del comité de control de cambios a nivel de centro. ... 107
Figura 23: Comité de control de cambios a nivel de línea. ... 108
Figura 24: Niveles para los roles de la subdirección de calidad ... 112
Figura 25: Actividades de aseguramiento de la calidad por fases de desarrollo. ... 128
Figura 26: Cursos por roles ... 129
XI Índice de tablas
Tabla 1: Métodos de Aseguramiento de la calidad. ... 10
Tabla 2: Secciones del Plan SQA propuesto por Std. 730-2002 del IEEE. ... 49
Tabla 3: Responsabilidades y competencias de los integrantes de la subdirección de calidad del centro. . 65
Tabla 4: Actividades de aseguramiento de la calidad. ... 75
Tabla 5: Cronograma de revisiones y auditorías. ... 86
Tabla 6: Registros de calidad. Tiempo de duración. ... 111
Tabla 7: Cursos a acreditar por roles. ... 113
Tabla 8: Resultado del trabajo de expertos. ... 117
Tabla 9: Cálculo de la Dispersión (S) para hallar la concordancia entre los expertos. ... 118
Tabla 10: Cálculo de concordancia de Kendall. ... 119
Tabla 11: Calificación de cada criterio. ... 121
1
Introducción
El uso de la tecnología es un factor determinante en los niveles de eficiencia y competitividad tanto desde el punto de vista empresarial como personal. A nivel mundial, la informática y las comunicaciones han logrado alcanzar una gran relevancia, debido al desarrollo de nuevas tecnologías que caracterizó las últimas décadas del siglo XX y que mantienen un ritmo en ascenso durante este siglo. La informática se ha convertido en una base imprescindible para el trabajo del resto de las ciencias y de cualquier actividad del mundo actual, abarcando todas las esferas de trabajo.
La desintegración del campo socialista de Europa del Este, la URSS y el arreciamiento del bloqueo por parte de los gobiernos estadounidenses, provocaron que la introducción de mejoras tecnológicas en el país se vieran frenadas y que las que estaban en uso se volvieran obsoletas. El país en aras de revertir esta situación ha desviado grandes recursos en medida de las posibilidades económicas.
De este modo, durante los primeros años de este siglo, el país se ha centrado en un proceso de informatización de la sociedad, lo que trajo consigo la necesidad de crear sistemas eficientes y a la altura de las nuevas tecnologías, que se van introduciendo como parte del despegue económico que va teniendo el mismo.
A partir del proceso de perfeccionamiento empresarial que se lleva en el país, las empresas trabajan para lograr una mayor eficiencia en su producción o en los servicios que brindan, pero para esto necesitan un software estándar que les permita trabajar sobre la misma base y de forma paralela.
Un tipo de software que permite hacer esto son los llamados ERP. Los sistemas de gestión empresarial (en inglés ERP, acrónimo de Enterprise Resource Planning) son sistemas de gestión de información que integran y automatizan muchas de las prácticas de negocio asociadas con los aspectos operativos o productivos de una empresa, eliminando complejas conexiones entre sistemas de distintos proveedores.
Estos software se desarrollan en distintos países, y hasta hace poco el país se veía en la necesidad de utilizarlos, pero como consecuencia de esta situación, no existía en el país una independencia tecnológica, y los altos costes por concepto de licencia y mantenimiento de software extranjeros ascienden a valores muy altos, degradando así la economía del país.
En la UCI se ha creado un centro para desarrollar soluciones de gestión, el cual agrupará varios proyectos que desarrollen soluciones de este tipo. Un ejemplo es el proyecto ERP-Cuba que desarrolla el Sistema Integral de Gestión de Entidades Cedrux y que pertenece a este centro. A la hora de elaborar cualquier
2 producto de software, es importante destacar lo necesario que se torna formar un sistema que cumpla con la aceptación de los requerimientos dictados por el cliente, además de cumplir con los requisitos propios del producto. A la subdirección de calidad de dicho centro se le ha confiado la importante tarea de garantizar que cada uno de los productos de software resultantes tengan la calidad requerida y esperada de cualquier producto desarrollado profesionalmente.
Lo cual arroja la siguiente situación problémica:
En el centro de soluciones de gestión CESGE se necesita asegurar y controlar la calidad del software con el objetivo de entregar productos confiables y acordes con las expectativas y especificaciones del usuario.
No hacerlo puede traer como consecuencias una serie de inconformidades tanto del cliente como del equipo de desarrollo, problemas como: un producto con defectos, que no cumpla con los estándares establecidos, o fuera del alcance de las expectativas y/o especificaciones del cliente.
Teniendo en cuenta la situación anteriormente planteada se traza el siguiente problema de la investigación: ¿Cómo garantizar un software de gestión con calidad?
Tomando como objeto de estudio: El proceso de aseguramiento de la calidad para software de gestión.
Como parte del objeto de estudio que se va a investigar se definió como campo de acción: El plan de aseguramiento de la calidad para el centro CESGE.
Luego de ser analizado el problema existente se define como objetivo general de la investigación:
Elaborar un plan de aseguramiento de la calidad para el centro CESGE.
Se parte de la siguiente idea a defender: Si se crea un plan de aseguramiento de la calidad para el centro, entonces se disminuye la posibilidad de lograr productos con defectos y se garantiza que los mismos estén acorde con los requerimientos del cliente.
Para dar cumplimiento al objetivo general de la investigación se plantean como objetivos específicos:
1. Fundamentar la investigación.
2. Realizar un estudio sobre los planes de aseguramiento de la calidad existentes.
3 3. Conformar el plan de aseguramiento de la calidad para el Centro de Soluciones de Gestión
CESGE.
4. Validar el plan de aseguramiento de la calidad para el Centro de Soluciones de Gestión CESGE.
Para dar cumplimiento a los objetivos establecidos se plantean las siguientes tareas de investigación:
1. Analizar detalladamente la bibliografía. (Realizar el estudio del arte) 2. Sintetizar los resultados alcanzados en la búsqueda bibliográfica.
3. Definir posición del investigador ante el objeto de estudio.
4. Estudiar las normas, estándares y modelos para la calidad de software.
5. Identificar los objetivos de calidad en el Centro de Soluciones de Gestión CESGE.
6. Definir y documentar las tareas por cada uno de los roles que respondan a las actividades de aseguramiento de calidad, en el Centro de Soluciones de Gestión CESGE.
7. Documentar las métricas haciendo referencia al plan de mediciones que se debe realizar en el Centro de Soluciones de Gestión CESGE.
8. Documentar sobre el procedimiento de revisiones y auditorias que se tiene previsto en el Centro de Soluciones de Gestión CESGE.
9. Documentar sobre el procedimiento de prueba previsto para el Centro de Soluciones de Gestión CESGE.
10. Estudiar y aplicar método experto para validar la propuesta de solución.
Se plantea como posible alcance del trabajo:
A partir de la plantilla definida por el grupo de Calidad del proyecto ERP-Cuba, conformar el Plan de aseguramiento de la calidad para el centro CESGE.
Identificar los lineamientos u objetivos de calidad para los proyectos involucrados con el centro.
Investigar sobre los estándares, normas y metodologías que se aplican en el centro.
4
Realizar una propuesta de métricas que se pudieran aplicar a los proyectos del centro.
Conformar el plan de revisiones y auditorías.
Realizar una propuesta de tipos de prueba que se le pueden aplicar al producto.
Definir las competencias y habilidades que debe poseer los roles involucrados con la subdirección de calidad.
El documento consta de 3 capítulos:
Capitulo I “Fundamentación Teórica” Hace referencia al marco teórico relacionado con el aseguramiento de la calidad de software, al estudio de diferentes definiciones y elementos necesarios para la elaboración de un Plan de Aseguramiento de la Calidad para proyectos de gestión.
Capitulo II “Propuesta de Solución”, se realiza una propuesta del Plan de aseguramiento de la calidad para el centro CESGE.
Capitulo III “Validación de la Solución” se hace un validación mediante el método Experto del plan propuesto.
5
Capítulo 1: “Fundamentación Teórica”
1.1. Introducción.
En este capítulo se realiza un estudio del estado de los elementos fundamentales que componen un Plan de aseguramiento de calidad, así como los distintos puntos a medir en este propuestos por el estándar Std. 730-2002 de la IEEE para planes de aseguramiento de la calidad de software, se hace una valoración del plan de aseguramiento propuesto por el grupo SQA de la Universidad de la Ciencias Informáticas.
Además se estudian los conceptos principales relacionados con la calidad del software que posteriormente serán utilizados en el documento.
1.2. Calidad de software. Conceptos fundamentales.
1.2.1. Calidad de software.
Existen varios conceptos y definiciones sobre calidad de software proporcionados por varios autores de renombre mundial, tal es el caso de la definición brindada por Roger Pressman donde define calidad de software como “…concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente”. (Pressman, 2002)
Otra definición es la dada por ISO 8402 donde se refiere a la Calidad de software como “El conjunto de características de una entidad que le confieren su aptitud para satisfacer las necesidades expresadas y las implícitas”. (ISO_8402)
Entre las definiciones revisadas la más general y completa se encuentra en el Manual de Gestión de la Calidad Total a la Medida con la cual coincide la autora de este trabajo, donde se define Calidad de Software como: “…el conjunto de propiedades y características de un producto o servicio, que le confieren la aptitud para satisfacer necesidades expresadas. Las necesidades pueden incluir aspectos relacionados con la aptitud para el uso, seguridad, disponibilidad, confiabilidad, mantenimiento, aspectos económicos y de medio ambiente. Este término no se emplea para expresar un grado de excelencia en un sentido comparativo, ni se usa con un sentido cuantitativo para evaluaciones”. (Malevski, 1995)
Roger Pressman hace hincapié en tres puntos importantes para definir la calidad de software, estos son:
(Pressman, 2002)
6 Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con
los requisitos es una falta de calidad.
Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se siguen esos criterios, casi siempre habrá falta de calidad.
Existe un conjunto de requisitos implícitos que a menudo no se mencionan (por ejemplo: el deseo por facilitar el uso y un buen mantenimiento). Si el software se ajusta a sus requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del software queda en entredicho.
Para obtener un software con una buena calidad y acorde con las expectativas del usuario es necesario cumplir todos los requisitos implícitos y explícitos en las características del mismo. Para lograr esto es necesario apoyarse en determinados estándares y normas que ayudarán al equipo del proyecto a controlar y asegurar la calidad del software y con ello desarrollar un software con el cual el cliente se sienta satisfecho.
1.2.2. Sistema de calidad
Según la Norma ISO 8402, un sistema de calidad es: “Estructura de la organización, responsabilidades, procedimientos, procesos y recursos que se establecen para llevar a término la gestión de calidad”.
(ISO_8402)
Un sistema de calidad, en sí mismo, no conduce automáticamente a mejorar los procesos de trabajo o la calidad del producto. No resuelve todos los problemas. (López, 2001)
Un sistema de gestión de la calidad es el conjunto de normas interrelacionadas de una empresa u organización por los cuales se administra de forma ordenada la calidad de la misma, en la búsqueda de la satisfacción de sus clientes. Entre dichos elementos, los principales son:
La estructura de la organización: La estructura de la organización responde al organigrama de los sistemas de la empresa donde se jerarquizan los niveles directivos y de gestión.
La estructura de responsabilidades: La estructura de responsabilidades implica a personas y departamentos. La forma más sencilla de explicitar las responsabilidades en calidad, es mediante un
7 cuadro de doble entrada, donde mediante un eje se sitúan los diferentes departamentos y en el otro, las diversas funciones de la calidad.
Procedimientos: Los procedimientos responden al plan permanente de pautas detalladas para controlar las acciones de la organización.
Procesos: Los procesos responden a la sucesión completa de operaciones dirigidos a la consecución de un objetivo específico.
Recursos: Los recursos, no solamente económicos, sino humanos, técnicos y de otro tipo, deberán estar definidos de forma estable y además de estarlo de forma circunstancial.
En si un sistema de calidad es una estructura organizativa que se define o establece con el objetivo de lograr una buena calidad en la organización donde se implante. Es necesario contar con un sistema de calidad pues es el método por el cual se debe asegurar y controlar la calidad en un proyecto u organización, sin un sistema de calidad es muy posible que no se tomen las medidas y procedimientos necesarios para asegurar que le software devengado tenga la calidad requerida por los clientes.
1.2.3. Gestión de la calidad
Según la Norma ISO 8402, la gestión o administración de la calidad son: “…los aspectos de la función de gestión que determinan y aplican la política de la calidad, los objetivos y las responsabilidades y que lo realiza con medios tales como la planificación de la calidad, el control de la calidad, la garantía de calidad y la mejora de la calidad”. (ISO_8402)
En otras palabras la gestión de la calidad de software no es más que un conjunto de actividades de función general de la dirección que determinan la calidad del producto, donde se definen los objetivos y las responsabilidades de los integrantes del equipo y se implanta por medios tales como la planificación de la calidad, así como el aseguramiento y control de la misma, llevando a cabo métodos para la mejora de esta en el marco del sistema de calidad utilizado.
1.2.4. Control de la calidad
Controlar la calidad durante el proceso de desarrollo de un software es de vital importancia para la obtención de un software de calidad. Para controlar la calidad del software es necesario, ante todo, definir los parámetros, indicadores o criterios de medición.
8 Según la Norma ISO 8402 el control de la calidad es: “un conjunto de técnicas y actividades de carácter operativo, utilizadas para verificar los requerimientos relativos a la calidad del producto o servicio”.
(ISO_8402)
El control de la calidad de software son técnicas y actividades de carácter operacional utilizadas para satisfacer los requisitos relativos a la calidad. Se orienta a mantener bajo control los procesos y eliminar las causas que generan comportamientos insatisfactorios en etapas importantes del ciclo de calidad, para conseguir mejores resultados económicos.
Estas técnicas y actividades están centradas en dos objetivos fundamentales: (Lovelle, 1999) 1. Mantener bajo control un proceso
2. Eliminar las causas de los defectos en las diferentes fases del ciclo de vida.
Según el manual de calidad el control de calidad no le garantiza al consumidor el cumplimiento de sus demandas cambiantes y tampoco los resultados económicos de la gestión empresarial.
Para realizar un control de calidad deben ejecutarse frecuentes inspecciones a las metodologías de trabajo y al uso de las herramientas, revisiones de prototipos y de las pruebas formales de los productos finales.
La calidad del producto o software es controlable, mediante revisiones, pruebas y auditorías. Pero es necesario plantearse una pregunta ¿Puede el responsable de calidad de un proyecto garantizar mediante revisiones y pruebas que el software sea lo que verdaderamente el cliente desea? Se piensa que en parte esto no puede ser posible, debido a que se controla que el producto no tenga errores o que sea confiable, pero no se controla que se halla hecho un análisis y un diseño profundo, es por esto que en ocasiones se tienen que abandonar soluciones existentes para un software o que incluso el desarrollo del mismo fracase, estas son cuestiones que son abordadas día a día en el desarrollo del Sistema Integral de Gestión de Entidades Cedrux.
1.2.5. Aseguramiento de la calidad (SQA)
El aseguramiento de la calidad corresponde a la verificación de la correcta aplicación del estándar utilizado. En proyectos pequeños, este rol puede ser desempeñado por el equipo de desarrollo, sin
9 embargo en proyectos de mayor magnitud es necesario un equipo especialmente dedicado a cumplir esta misión. Debe existir un plan de SQA, que indique todas las actividades que debe realizar ese equipo.
Según Lovelle el Aseguramiento de Calidad del software es: ¨el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza en que el producto (software) satisfará los requisitos dados de calidad. Se diseña para cada aplicación antes de comenzar a desarrollarla y no después¨.
(Lovelle, 1999)
Otra definición es consignada por Carlos López cuando dice que: “El aseguramiento de la calidad, se puede definir como el esfuerzo total para plantear, organizar, dirigir y controlar la calidad en un sistema de producción con el objetivo de dar al cliente productos con la calidad adecuada. Es simplemente asegurar que la calidad sea lo que debe ser”. (López, 2001)
Para Yoram Malevski el Aseguramiento de la Calidad: “…son todas aquellas acciones planificadas y sistemáticas, necesarias para proporcionar la confianza adecuada de que un producto o servicio satisface los requisitos de calidad establecidos. Para que sea efectivo, el Aseguramiento de la Calidad requiere, generalmente, una evaluación permanente de aquellos factores que influyen en la adecuación del diseño y de las especificaciones según las aplicaciones previstas, así como también verificaciones y auditorías a las operaciones de producción, instalación e inspección. Dentro de una organización, el Aseguramiento de la Calidad sirve como una herramienta de la Gestión”. (Malevski, 1995)
Pero una definición fácil de entender es brindada en el Estándar Internacional 730 de la IEEE con la cual coincide la autora de este trabajo"…el Aseguramiento de la Calidad de software es un modelo planificado y sistemático de todas las acciones necesarias a fin de asegurar que el ítem o producto cumpla con los requerimientos técnicos establecidos". (Std-730-1998)
El aseguramiento de calidad del software está presente en: (Lovelle, 1999) Métodos y herramientas de análisis, diseño, programación y prueba.
Inspecciones técnicas formales en todos los pasos del proceso de desarrollo del software.
Estrategias de prueba.
Control de la documentación del software y de los cambios realizados.
Procedimientos para ajustarse a los estándares (y dejar claro cuando se está fuera de ellos).
Mecanismos de medida (métricas).
Registro de auditorías y realización de informes.
10 Todo el que este involucrado en el proceso de desarrollo del software es responsable de la calidad, desarrolladores, analistas, arquitectos, jefes de proyectos, clientes y aquellas personas que en los proyectos son llamados grupo de aseguramiento de la calidad.
El aseguramiento de la calidad, como actividad de soporte en el proceso de desarrollo, comprende procedimientos para la aplicación efectiva de métodos y herramientas, revisiones y estrategias de prueba, control de cambios, aseguramiento de ajuste a los estándares entre otras.
Algunos de los métodos utilizados para asegurar la calidad de software son:
Objetivo Método Principal
Evaluación Revisiones técnicas
Verificación Inspección
Validación Pruebas
Confirmación del
cumplimiento Auditorías
Tabla 1: Métodos de Aseguramiento de la calidad.
En un proyecto el aseguramiento de la calidad está enfocado a cumplir los requisitos de calidad del mismo, mediante la planificación y sistematización de las actividades de aseguramiento, esta actividad se enfoca más bien en evaluar, verificar y validar el software a fin de asegurar que lo que se haga sea con calidad pero no se asegura el software sea lo que el cliente desea.
1.2.5.1. Actividades de SQA
A menudo, las actividades de aseguramiento de calidad son supervisadas por un departamento de aseguramiento de calidad o por una organización similar. El soporte de AC1, puede proporcionarse al equipo del proyecto, a la dirección de la organización ejecutante, al cliente o patrocinador, así como a los otros interesados que no participan activamente en el trabajo del proyecto. El AC proporciona también un
1 Aseguramiento de la Calidad
11 paraguas para otra actividad importante de calidad: la mejora continua del proceso, la cual proporciona un medio iterativo para mejorar la calidad de todos los procesos.
Las actividades fundamentales que realiza o facilita el grupo de SQA2 son: (Navarro, 2002)
Planificación de la calidad: Consiste en seleccionar, clasificar y ponderar las propiedades de calidad que se van a establecer como requisitos, con respecto al producto y con respecto al proceso.
Se elegirán también los mecanismos de control de calidad a utilizar para medir y evaluar estas características, además de determinar las metas a alcanzar.
Supervisión de la calidad: Consiste en supervisar y corregir, si es necesario, el trabajo que se está realizando (según los resultados obtenidos en las actividades de control de calidad), con el objetivo de llegar a satisfacer los requisitos establecidos.
Construcción de la calidad: Actividades constructivas son aquellas que sirven para “construir” la calidad, es decir, son actividades preventivas cuyo objetivo es evitar la introducción de errores mediante la puesta en práctica de ciertos principios, métodos, formalismos y herramientas.
Por otro lado, el Instituto de Ingeniería del Software (SEI)3 recomienda un grupo de actividades más amplio, que se enfrentan con la planificación de aseguramiento de calidad, supervisión, mantenimiento de registros, análisis e informes, estas son: (Pressman, 2002)
Establecimiento de un plan de SQA para un proyecto.
Participación en el desarrollo de la descripción del proceso de software del proyecto.
Revisión de las actividades de ingeniería del software para verificar su ajuste al proceso de software definido.
Auditorías de los productos de software designados para verificar el ajuste con los definidos por parte del proceso de software.
Asegurar que las desviaciones del trabajo y los productos del software se documentan y se manejan de acuerdo con un procedimiento establecido.
Registrar lo que no se ajuste a los requisitos e informar a sus superiores.
2 Software Quality Assurance que en español significa Aseguramiento de la calidad de software.
3 Software Engineers Institute que en español significa Instituto de Ingeniería del Software.
12 Coordinar el control y la gestión de los cambios.
Recopilar y analizar las métricas del software.
De forma general estas actividades se resumen en: un enfoque de gestión de la calidad; tecnología de ingeniería de software efectiva (métodos y herramientas); revisiones técnicas formales (RTF) que se aplican durante el proceso del software; una estrategia de prueba; el control de la documentación del software y de los cambios realizados; un procedimiento que se ajuste a los estándares de desarrollo del software cuando sea posible y por último un mecanismo de medición y de generación de informes.
(Pressman, 2002)
Se pensará en ocasiones que estas actividades están sobreestimadas, pero para un desarrollo efectivo del aseguramiento de la calidad estas actividades son el soporte fundamental, debido a que solo se puede asegurar la calidad si se tiene un control efectivo y estricto de los artefactos que se generan en el proyecto como resultado de la ingeniería de software llevada a cabo, si se tiene un control de cambio del trabajo desarrollado y sobre todo si se supervisa constantemente que los requisitos se ajustan al análisis hecho.
La autora de este trabajo piensa que estas actividades son el soporte del aseguramiento y que todas tienen importancia pues cada una forma parte de una actividad mayor que es garantizar la calidad del producto o software.
1.2.5.2. Grupo SQA en un proyecto.
El grupo de SQA sirve como representación del cliente en casa. Es decir, la gente que lleva a cabo la SQA debe mirar al software desde el punto de vista del cliente. Tiene la responsabilidad de la planificación de garantía de calidad, supervisión, mantenimiento de registros, análisis e informes. (Pressman, 2002)
El grupo de SQA trata de ayudar al equipo de ingeniería del software en la consecución de un producto final de alta calidad, cumpliendo las actividades definidas para el aseguramiento de la calidad. Es el encargado de velar por los intereses del cliente y asegurar que se mantiene la calidad del software.
1.2.5.3. Ventajas y desventajas del SQA.
La implantación del aseguramiento de la calidad en determinadas empresas o proyectos trae como consecuencia ventajas y desventajas, las que se mencionan a continuación: (GISC, 1999)
Ventajas
Menos defectos latentes en el software.
13 Menor esfuerzo y tiempo, tanto de prueba como de mantenimiento.
Mayor fiabilidad y satisfacción del cliente.
Reducción de los costes de mantenimiento.
Disminución del coste del ciclo de vida.
Desventajas
No disponibilidad de recursos necesarios en empresas pequeñas.
La dificultad del cambio cultural.
La necesidad de un gasto destinado a la ingeniería del software.
A pesar que el SQA posee desventajas para ciertas empresas se considera que las ventajas de implantarlo en cualquier sistema de calidad son mucho mayores, permitiendo de esta forma que se reduzcan la mayor cantidad de defectos, y así se estaría disminuyendo el coste y el esfuerzo de mantenimiento, garantizando una mayor fiabilidad del software.
1.2.6. Coste de la calidad.
El coste de calidad incluye todos los costes acarreados en la búsqueda de la calidad o en las actividades relacionadas en la obtención de la calidad.
Los costes de calidad se pueden dividir en costes asociados con la prevención, la evaluación y los fallos.
(Pressman, 2002)
Entre los costes de prevención se incluyen:
Planificación de la calidad.
Revisiones técnicas formales.
Equipo de pruebas.
Formación.
Entre los costes de evaluación se incluyen actividades para tener una visión más profunda de la condición del producto. A continuación se incluyen algunos ejemplos de costes de evaluación:
Inspección en el proceso y entre procesos.
Calibrado y mantenimiento del equipo.
Pruebas.
14 Los costes de fallos son los costes que desaparecerían si no surgieran defectos antes del envío de un producto a los clientes. Estos costes se pueden subdividir en costes de fallos internos y costes de fallos externos. Los internos se producen cuando se detecta un error en el producto antes de su envío. Entre estos se incluyen:
Retrabajo (revisión).
Reparación.
Análisis de las modalidades de fallos.
Los costes de fallos externos son los que se asocian a los defectos encontrados una vez enviado el producto al cliente. A continuación se incluyen algunos ejemplos de costes de fallos externos:
Resolución de quejas.
Devolución y sustitución de productos.
Soporte de línea de ayuda.
Trabajo de garantía.
Como es de esperar, los costes relativos para encontrar y reparar un defecto aumentan dramáticamente a medida que se cambia de prevención a detección y desde el fallo interno al externo.
Figura 1: Coste de resolución de fallos
Evidentemente, cuanto más se demore la corrección de un fallo, más costosa será su resolución.
15 1.2.7. Modelo de calidad CMMI.
Los modelos de calidad son sistemas basados en estudios experimentales de mejores prácticas que ayudan a una organización a implantar un sistema de de calidad, pueden ser utilizados para construir mejores productos y asegurar su calidad.
Los modelos de calidad se dividen en modelos de referencia, que indican cuáles son las prácticas pero no cómo se consiguen, y los modelos de implantación que se enfocan en cómo se consiguen aquellas prácticas.
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 subcaracterísticas que pueden usarse como una lista de comprobación de aspectos relacionados con la calidad.
Uno de los modelos de calidad más utilizado es CMMI o Capability Maturity Model Integration, es un modelo de referencia que se diferencia de otros modelos por el hecho de estar basado en prácticas ajustables a cualquier dominio de producción y poseer un enfoque global e integrado de la organización, con el propósito de alcanzar los objetivos del negocio para la mejora o evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software. Fue desarrollado por el Instituto de Ingeniería del Software (SEI) de la Universidad Carnegie Mellon y publicado en su primera versión en enero de 2002.
Capability Maturity Model Integration (CMMI)
El modelo para software (SW-CMM)4 establece 5 niveles de madurez para clasificar a las organizaciones, en función de qué áreas de procesos consiguen sus objetivos y se gestionan con principios de ingeniería.
Es lo que se denomina un modelo escalonado, o centrado en la madurez de la organización.
El modelo para ingeniería de sistemas (SE-CMM) establece 6 niveles posibles de capacidad para una de las 18 áreas de proceso implicadas en la ingeniería de sistemas. No agrupa los procesos en 5 tramos para definir el nivel de madurez de la organización, sino que directamente analiza la capacidad de cada proceso por separado. Es lo que se denomina un modelo continuo.
4 CMM for software
16 En el equipo de desarrollo de CMMI había defensores de ambos tipos de representaciones. El resultado fue la publicación del modelo con dos representaciones: continua y escalonada. Son equivalentes, y cada organización puede optar por adoptar la que se adapte a sus características y prioridades de mejora.
(Palacio, 2006)
La visión continua de una organización mostrará la representación de nivel de capacidad de cada una de las áreas de proceso del modelo.
La visión escalonada definirá a la organización dándole en su conjunto un nivel de madurez del 1 al 5.
Los 6 niveles definidos en CMMI para medir la capacidad de los procesos son: (Palacio, 2006) 0.- Incompleto: El proceso no se realiza, o no se consiguen sus objetivos.
1.- Ejecutado: El proceso se ejecuta y se logra su objetivo.
2.- Gestionado: Además de ejecutarse, el proceso se planifica, se revisa y se evalúa para comprobar que cumple los requisitos.
3.- Definido: Además de ser un proceso gestionado se ajusta a la política de procesos que existe en la organización, alineada con las directivas de la empresa.
4.- Cuantitativamente gestionado: Además de ser un proceso definido se controla utilizando técnicas cuantitativas.
5.- Optimizado: Además de ser un proceso cuantitativamente gestionado, de forma sistemática se revisa y modifica o cambia para adaptarlo a los objetivos del negocio.
Los 5 niveles definidos para determinar la madurez de la organización son: (Palacio, 2006)
Inicial: Los resultados de calidad obtenidos son consecuencia de las personas y de las herramientas que emplean. No de los procesos, porque o no los hay o no se emplean.
Administrado: Se considera un nivel 2 de madurez cuando se llevan a cabo prácticas básicas de gestión de proyectos, de gestión de requisitos, control de versiones y de los trabajos realizados por subcontratistas. Los equipos de los proyectos pueden aprovechar las prácticas realizadas para aplicarlas en nuevos proyectos.
17 Definido: Los procesos comunes para desarrollo y mantenimiento del software están documentados de manera suficiente en una biblioteca accesible a los equipos de desarrollo. Las personas han recibido la formación necesaria para comprender los procesos.
Cuantitativamente administrado: La organización mide la calidad del producto y del proceso de forma cuantitativa en base a métricas establecidas. La capacidad de los procesos empleados es previsible, y el sistema de medición permite detectar si las variaciones de capacidad exceden los rangos aceptables para adoptar medidas correctivas.
Optimizado: La mejora continua de los procesos afecta a toda la organización, que cuenta con medios para identificar las debilidades y reforzar la prevención de defectos. Se analizan de forma sistemática datos relativos a la eficacia de los procesos de software para analizar el coste y el beneficio de las adaptaciones y las mejoras. Se analizan los defectos de los proyectos para determinar las causas, y su mapeado sobre los procesos.
A continuación se muestra una representación gráfica de ambas representaciones de CMMI: la continua y la escalonada.
Figura 2: Representaciones del modelo CMMI.
Ventajas y desventajas de usar CMMI
Algunas ventajas y desventajas de implantar CMMI en una organización son:
18 Desventajas
Requiere mucho esfuerzo, compromiso de toda la organización.
Comenzar a diseñar y/o documentar procesos, luego desplegarlos y ponerlos en práctica.
Requiere un mínimo de cantidad de personal (no menos de 10 personas en la práctica).
Fuerte inversión económica.
Ventajas
Reducción en los costes y en las desviaciones en plazo de los Proyectos Software.
Mayor eficacia en la detección de errores a lo largo del ciclo de vida de los Proyectos Software, reduciendo drásticamente el número de errores que afecta directamente a los clientes y usuarios.
Resultados más predecibles en los proyectos.
Implementación de técnicas pro-activas de gestión, mitigando los riesgos que afectan a los proyectos. Resultados más predecibles en los proyectos.
Disposición de información de gestión útil a la hora de tomar decisiones ya sean éstas relacionadas con la Gestión de Proyectos Software, bien con la mejora continua del Proceso Software.
Mejorar el posicionamiento frente al mercado.
Es evidente que aunque CMMI tiene desventajas las ventajas que ofrece a la organización que lo implemente son mayores, pues estas organizaciones o sistemas de calidad alcanzan un nivel de madurez en sus procesos que garantizarán la confiabilidad, la capacidad y la eficiencia.
Cada nivel de capacidad tiene asociados objetivos y prácticas genéricas así como objetivos y prácticas específicas, pero ¿Qué son estos?
Objetivos: Los objetivos genéricos asociados a un nivel de capacidad establecen lo que una organización debe alcanzar en ese nivel de capacidad. El logro de cada uno de esos objetivos en un área de proceso significa mejorar el control en la ejecución del área de proceso. Los objetivos específicos se aplican a una única área de proceso y localizan las particularidades que describen que se debe implementar para satisfacer el propósito del área de proceso. (Palacio, 2006)
Prácticas: Una práctica genérica se aplica a cualquier área de proceso porque puede mejorar el funcionamiento y el control de cualquier proceso. Las prácticas específicas describen las actividades esperadas para lograr la meta específica de un área de proceso. (Palacio, 2006)
19 A continuación se detallan los objetivos y prácticas de los niveles 2 y 3, puesto que las áreas de procesos que se estudian tienen su desarrollo en estos niveles.
Objetivo genérico del nivel de madurez 2 Institucionalizar un proceso administrado Prácticas genéricas
Establecer una política organizacional Planear el proceso
Proveer recursos
Asignar responsabilidades Entrenar a los recursos
Establecer y mantener el proceso definido Administrar la configuración
Involucrar a los interesados relevantes Colectar información de mejora
Evaluar la adherencia al proceso
Revisar el estado con la alta administración del proceso
Para el nivel 3 de CMMI también se establecen su respectivo objetivo y prácticas genéricas.
Objetivo genérico nivel de madurez 3 Institucionalizar un proceso definido Prácticas genéricas
Establecer una política organizacional Establecer el proceso definido
Planear el proceso Proveer recursos
Asignar responsabilidades Entrenar a los recursos
20 Administrar la configuración
Establecer y mantener el proceso definido Involucrar a los interesados relevantes Monitorear y controlar el proceso Colectar información de mejora Evaluar la adherencia al proceso
Revisar el estado con la alta administración del proceso
CMMI identifica 22 áreas de procesos. Un área de proceso es un conjunto de prácticas relativas a un área, que desarrolladas de manera colectiva, satisfacen un conjunto de objetivos considerados importantes para hacer una mejora en dicha área. Estas áreas de procesos vistas desde la representación continua del modelo, se agrupan en 4 categorías según su finalidad: Gestión de proyectos, Ingeniería, Gestión de procesos y Soporte a las otras categorías. Vistas desde la representación escalonada, se clasifican en los 5 niveles de madurez. Al nivel de madurez 2 pertenecen las áreas de proceso cuyos objetivos debe lograr la organización para alcanzarlo, esto mismo pasa con los niveles 3, 4 y 5.
Las áreas de procesos vinculadas al nivel 2 de CMMI son:
Gestión de acuerdos con proveedores Administración de Requisitos
Aseguramiento de la calidad de procesos y productos (PPQA) Gestión de la configuración
Planificación de proyectos
Monitorización y Control de proyectos Medición y Análisis
Para el nivel 3 de CMMI las áreas de procesos definidas son:
Desarrollo de Requisitos Soluciones Técnicas Integración de Producto Verificación
Validación
21 Atención al Proceso Organizacional
Definición del Proceso Organizacional Capacitación Organizacional
Gestión Integrada de Proyectos para DIPP Gestión de Riesgos
Integración de Equipos
Decisión, Análisis y Resolución
Entorno Organizacional para la Integración
Solo se especifican las áreas de procesos de estos niveles puesto que el centro para el cual está destinado este trabajo, vincula sus actividades de aseguramiento y control de la calidad con las áreas de procesos de estos niveles, como por ejemplo con las áreas de PPQA, Validación y Verificación.
1.2.7.1. Área de proceso Aseguramiento de la Calidad de los Procesos y Productos
Para una mejor comprensión del área de proceso de CMMI de Aseguramiento de la calidad de los productos y procesos, se hace un breve resumen de los aspectos que se plantean en esta y se vinculan las actividades de aseguramiento (revisión y auditoría) del centro con los objetivos y metas de la misma.
El propósito del área de proceso del Aseguramiento de la calidad del Proceso y de Producto (PPQA) es proporcionar una visión objetiva al personal y a la dirección, sobre los procesos que se desarrollan y los productos de trabajo asociados. Esta área de proceso apoya la entrega de productos y servicios de buena calidad proporcionando al personal de todos los niveles y gerentes del proyecto la visibilidad apropiada y retroalimentación de procesos y productos de trabajo asociados a lo largo del la vida del proyecto. Las prácticas del área de proceso PPQA aseguran que los procesos planeados sean implementados.
Según se plantea en el documento IPP-3520_2009 Libro de Proceso para PPQA v.5 la política de PPQA establece como metas específicas: (SQA_UCI, 2009)
1. Evaluar objetivamente adherencia a procesos y productos de trabajo.
2. Asegurar la resolución de las no conformidades detectadas.
3. Registrar y comunicar los resultados de las evaluaciones y el análisis de tendencias.
Además establece como principales subprocesos:
Planear PPQA.
22 Evaluación de la adherencia a procesos y productos.
Seguimiento/escalamiento de no conformidades.
Análisis de Resultados.
La integridad en el Aseguramiento de la Calidad del Proceso y de Producto es crítico para el éxito del proyecto. Los ejemplos de maneras de realizar las evaluaciones objetivas incluyen a lo siguiente:
Las auditorías formales se deben realizar por una organización separada de las organizaciones de aseguramiento de la calidad.
Revisiones que pueden realizarse a los varios niveles de formalidad.
Revisiones profundadas al lugar de trabajo.
Distribuir revisiones y comentarios de productos de trabajo.
Por ejemplo, llevando a cabo un par de revisiones como un método de evaluación objetivo:
Los miembros están especializados y se asignan roles para las personas que asisten a las revisiones.
Un miembro de la revisión que no produjo este producto se asigna realice el papel de asegurador de calidad.
Las listas de chequeo están disponibles para apoyar la actividad de aseguramiento de la calidad.
Se graban los defectos como la parte del informe de revisión y son rastreados y llevados fuera del proyecto cuando sea necesario.
Si el aseguramiento de la calidad es incluido en el proceso, varios problemas deben ser dirigidos para asegurar la objetividad. Todo el que lleve a cabo las actividades de aseguramiento de la calidad de software debe ser entrenado en el aseguramiento de la calidad. Aquellos que estén vinculados al aseguramiento de la calidad del producto deben estar separados de aquellos que están directamente vinculados al desarrollo o mantenimiento del producto.
El aseguramiento de la calidad debe empezar en las fases tempranas de un proyecto estableciendo los planes, procesos, normas, y procedimientos que le dará valor al proyecto y satisfará los requisitos del proyecto y las políticas de la organización.
23 Esta representación del aseguramiento de la calidad estará presente en el establecimiento de planes, procesos, normas y procedimientos, para asegurar que estos encajan en las necesidades del proyecto, y que serán utilizados para realizar evaluaciones a la calidad del software.
1.2.7.2. Área de proceso de Verificación
El propósito de esta área es asegurar que el producto seleccionado cumple con los requisitos especificados, la misma involucra las siguientes actividades: la preparación de la verificación, la realización de la misma, e identificación de acciones correctivas.
Incluye la verificación del producto final y del producto intermedio contra todos los requisitos seleccionados, es inherentemente un proceso incremental ya que ocurre a lo largo del desarrollo del producto, empezando con la comprobación de los requisitos, progresando a través de la evolución del mismo y culmina cuando este ha sido desarrollado en su totalidad.
Objetivos y prácticas específicas para esta área.
OE5 1 Preparar la verificación
PE6 1.1 Seleccionar los artefactos para la verificación.
PE 1.2 Establecer el ambiente de la verificación.
PE 1.3 Establecer procedimientos y criterios de la verificación.
OE 2 Realizan las revisiones.
PE 2.1 Preparar las revisiones PE 2.2 Conducir las revisiones.
PE 2.3 Analizan los datos de revisión.
OE 3 Verificar los productos de trabajo seleccionados PE 3.1 Realizar la verificación o comprobación.
PE 3.2 Analizar los resultados de la comprobación e identificar las acciones correctivas.
5 Objetivo Específico
6 Práctica Específica
24 Esta área de proceso tiene un gran vínculo con otra llamada Validación, solo que esta última enfoca su acción desde otro punto de vista, pues la verificación está enfocada a saber si se construye correctamente el producto, mientas la validación está enfocada a saber si se construye el producto correcto.
1.2.7.3. Área de proceso de Validación
El propósito de la validación es demostrar que un producto o componente cumple su uso intencional cuando se encuentra en el ambiente definido.
Las actividades de validación pueden ser aplicadas a todos los aspectos del producto en cualquiera de sus marcos intencionales, como puede ser el funcionamiento, el entrenamiento, la construcción, el mantenimiento y servicios de apoyo.
La validación demuestra que el producto, realmente cumple con el propósito para le cual fue pensado, considerando que mediante esta actividad se comprueba si el producto propiamente refleja los requisitos especificados, asegurando que realmente se construyó el producto deseado por el cliente. A menudo los usuarios o clientes están vinculados con esta actividad, lo cual es apropiado pues solo el cliente puede demostrar que realmente se desarrolló el producto deseado.
Cuando se identifican los problemas de validación, se envían a los involucrados con el desarrollo de requisitos, la solución técnica, o proyecto que supervisa y controla las áreas del proceso para la resolución de estos.
Objetivos y prácticas específicas para esta área.
OE 1 Preparar la validación
PE 1.1 Seleccionar los productos para la validación PE 1.2 Establecer el ambiente de validación
PE 1.3 Establecer los procedimientos y criterios de validación OE 2 Validar el producto o componentes del producto
PE 2.1 Realizar la validación
PE 2.2 Analizar los resultados de la validación
Para realizar la propuesta del plan de aseguramiento, se hizo un estudio de estos procesos, y se proponen actividades que estén vinculadas a los objetivos y metas de estas áreas de procesos.
25
1.3. Plan de aseguramiento de la calidad
Cuando se decide comenzar con la realización de un producto de software se debe hacer una planificación y un Plan de Aseguramiento de la Calidad.
En este Plan se definen las actividades de Calidad que se tienen que realizar, en qué momentos tiene que intervenir la función de Aseguramiento de la Calidad, que a diferencia de Control de Calidad intervendrá proponiendo y supervisando los procesos de calidad a realizar en la fase de generación de los distintos componentes, adherencia a estándares, y la intensidad de aplicación de la misma según la criticidad de los productos y el nivel de riesgos que se haya encontrado en la evaluación del sistema.
El plan de aseguramiento de calidad generado por un grupo de aseguramiento de un proyecto sirve como guía para el desarrollo e institución de las actividades de aseguramiento de la calidad. Un plan de aseguramiento debe contener por lo general:
Objetivos de la calidad del proyecto y su enfoque para su consecución.
Documentación referenciada en el plan.
Gestión del aseguramiento de la calidad.
Documentación de desarrollo y de control o gestión.
Estándares, normas o prácticas que hay que cumplir.
Actividades de revisión y auditorías.
Gestión de la configuración del software.
Informes de problemas Pruebas
Herramientas, técnicas y métodos de apoyo.
Recogida, mantenimiento y almacenamiento de datos sobre la documentación de actividades de aseguramiento de la calidad realizadas en el proyecto.
A estos puntos se pueden añadir otros en dependencia del proyecto según lo estime conveniente el grupo de aseguramiento de la calidad del mismo.
1.3.1. Plan de aseguramiento de la calidad. Conceptos fundamentales.
26 1.3.1.1. Normas y estándares.
Una norma es un documento que ha sido desarrollado y establecido dentro de los principios de consenso de la organización que la concibe y que cumple los requisitos de los procedimientos y regulaciones de esta organización.
Estándar puede ser conceptualizado como la definición clara de un modelo, criterio, regla de medida o de los requisitos mínimos aceptables para la operación de procesos específicos, con el fin asegurar la calidad. Los estándares señalan claramente el comportamiento esperado y deseado de determinado ente y son utilizados como guías para evaluar su funcionamiento y lograr el mejoramiento continuo de los servicios.
Durante este epígrafe se hace una revisión de las principales normas y estándares mencionados en el documento y que han sido tomados como referencia. El objetivo de este es dar una visión más abarcadora de cada uno de estos estándares, para que luego se entienda su uso en el documento.
ISO 9126
La ISO, bajo la norma ISO-9126, ha establecido un estándar internacional para la evaluación de la calidad de productos de software el cual fue publicado en 1992 con el nombre de “Information technology – Software product evaluation: Quality characteristics and guidelines for their use”, en el cual se establecen las características de calidad para productos de software.
El estándar ISO-9126 establece que cualquier componente de la 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 subcaracterísticas que permiten profundizar en la evaluación de la calidad de productos de software.
IEEE Std. 730-2002
Este estándar es una revisión del estándar IEEE Std.730-1998 para planes de aseguramiento de la calidad, y va dirigido a asistir a los especialistas de calidad en la preparación del Plan SQA para un proyecto de software. Proporciona una norma para conformar un plan con los requisitos mínimos que estos deben contener, brindando una guía para desarrollar los mismos. Se dirige hacia el desarrollo y mantenimiento del software.
27 La utilización de estos estándares es importante debido a que es la forma de normalizar el comportamiento de las personas que intervengan en la realización de un software con el objetivo de que se hable un solo lenguaje si a términos de calidad se refieren, y lograr una uniformidad en la conformación de artefactos necesarios para garantizar la calidad del software.
1.3.1.2. Métricas
Una métrica es una definición operativa que describe, en términos muy específicos, lo que algo es y cómo lo mide el proceso de control de calidad. Una medición es un valor real. Las métricas de calidad se usan en los procesos de Aseguramiento de la calidad (Quality Assurance QA) y Control de la calidad (Quality Control QC). (Lovelle, 1999)
Las métricas representan medidas indirectas, es decir, nunca se mide realmente la calidad, sino algunas de sus manifestaciones. El factor que lo complica es la relación precisa entre la variable que es medida y la calidad del software. No se puede medir directamente la calidad del software por la naturaleza subjetiva de esta actividad.
Es difícil, y en algunos casos, imposible, desarrollar medidas directas de los factores de calidad del software. Cada factor de calidad se puede obtener como combinación de una o varias métricas.
En ocasiones los factores de calidad pueden ser tomados como listas de comprobación para garantizar la calidad del producto. Estos se centran en tres aspectos importantes de un producto de software: sus características operativas, su capacidad de soportar los cambios y su adaptabilidad a nuevos entornos.
Según Juan Carlos Granja, estos son los factores que afectan la calidad del software, y se pueden categorizar en: (Granja, 2007)
Factores que se pueden medir directamente, como por ejemplo los defectos por punto de función.
Factores que se pueden medir sólo indirectamente, como por ejemplo la facilidad de uso o mantenimiento.
En todos los casos debe aparecer la medición. Debe ser posible comparar el software (documentos, programas, datos) con una referencia y llegar a una conclusión sobre la calidad. Debe ser posible comparar el software (documentos, programas, datos) con una referencia y llegar a una conclusión sobre la calidad.
28 Algunos de los factores de calidad son los propuestos por el estándar Internacional para la evaluación del software ISO 9126, el mismo identifica seis atributos claves para la calidad del producto de software, los mismos se exponen a continuación: (Granja, 2007)
Funcionalidad: El grado en que el software satisface las necesidades indicadas por los siguientes subatributos: idoneidad, corrección, interoperabilidad, conformidad y seguridad.
Confiabilidad: Cantidad de tiempo que el software está disponible para su uso. Está referido por los siguientes subatributos: madurez, tolerancia a fallos y facilidad de recuperación.
Usabilidad: Grado en que el software es fácil de usar. Viene reflejado por los siguientes subatributos: facilidad de comprensión, facilidad de aprendizaje y operatividad.
Eficiencia: Grado en que el software hace óptimo el uso de los recursos del sistema. Viene reflejado por los siguientes subatributos: tiempo de uso y recursos utilizados.
Facilidad de mantenimiento: La facilidad con que una modificación puede ser realizada. Está indicada por los siguientes subatributos: facilidad de análisis, facilidad de cambio, estabilidad y facilidad de prueba.
Portabilidad: La facilidad con que el software puede ser llevado de un entorno a otro. Está referido por los siguientes subatributos: facilidad de instalación, facilidad de ajuste, facilidad de adaptación al cambio
Otros factores de calidad son los presentados en el modelo McCall:
Figura 3: Modelo de McCall
29 McCall presenta en su modelo tres puntos de vista de calidad, operación del producto, revisión del producto y transición del producto. Incluye 41 métricas, entendidas como medidas directas de los atributos, y 11 factores de calidad.
El equipo de SQA debe establecer métricas consistentes y útiles, alineadas con los objetivos del proyecto, que permitan medir fiabilidad y calidad en el desarrollo. La mayoría de estas métricas están concentradas en el proceso de pruebas, los responsables de las pruebas deben fiarse de las métricas definidas anteriormente para que sirvan de guía en el diseño y ejecución de los Casos de pruebas.
Las métricas tienen una importancia significativa en el proceso de desarrollo de software pues es una forma de medir que tan buena es la calidad del software que se está desarrollando, aunque en cierta forma la medición se hace de una forma subjetiva, proporciona una idea clara de cuales son los factores principales que están afectando la calidad del software y de esta forma corregirlos a tiempo. Un buen uso de métricas proporcionaría una calidad mejorada del producto, un incremento en la productividad del equipo de desarrollo, una mayor estimación, planificación y gestión del proyecto, una mayor cultura de calidad del equipo de desarrollo y una mejora de la satisfacción del cliente.
1.3.1.3. Auditorías.
Una auditoría de calidad tiene como objetivo mostrar la situación real para aportar confianza y destacar las áreas que pueden afectar adversamente esa confianza. Otro objetivo consiste en suministrar una evaluación objetiva de los productos y procesos para corroborar la conformidad con los estándares, las guías, las especificaciones y los procedimientos.
Según la ISO 8402 una auditoría de calidad es: ¨un análisis sistemático e independiente para determinar si las actividades de calidad y sus resultados cumplen las disposiciones establecidas y si estas son implantadas eficazmente y son apropiadas para alcanzar los objetivos¨. (ISO_8402)
Las auditorías son la forma que tienen los auditores de software de verificar si se cumplen las disposiciones generales de calidad dictadas por el equipo SQA del proyecto y si se llevan a cabo todas las actividades de calidad necesarias para producir un software de buena calidad, con todos los artefactos necesarios para un buen entendimiento del mismo, y sobre todo si los estandares definidos en el proyecto son cumplidos eficazmente.
