Post on 03-Jan-2016
FACULTAD DE INGENIERIA
ESCUELA PROFESIONAL DE INGENIERIA INFORMATICA
Metodología de Aseguramiento y Control de Calidad de Software
INFORME DE EXPERIENCIA PROFESIONAL
PARA OBTENER EL TÌTULO PROFESIONAL DE
INGENIERO INFORMATICO
PRESENTADO POR:
GRACE JULIANNE BELLIDO CHOCANO
LIMA – PERÙ
2013
1
1. Introducción
Mediante el informe de experiencia laboral daré a conocer la importancia de la
calidad de software en el ciclo de vida de un proyecto, presentare la metodología de
calidad de software que implemente para las empresas en las cuales trabaje. Como
analista de calidad de software he trabajado con varias metodologías y buenas prácticas
las cuales plasmare en el presente informe. Para validar las mejores prácticas que
propongo he estudiado como la metodología de calidad se adaptar al cliente utilizando
diversos modelos como CMM Modelo de Madurez de la Capacidad del Software, Modelo
TickIT, modelo TPI (Test Process Improvement), Metodología BaQEM para pruebas
funcionales de software, metodología RUP, conceptos del ISTQB.
1.1 Marco Situacional
En los últimos años se ha venido escuchando de procesos y/o metodologías para el
aseguramiento y control de calidad del software las cuales fueron desarrolladas por la
misma experiencia en el campo laboral, usando algunos artefactos principales o también
aplicadas por entidades certificadoras como en España “Spanish Software
TestingQualificationBoard (ISTQB)”, en Hispanoamérica el “HispanicAmerica Software
TestingQualificationBoard (HASTQB)” conformado por Argentina, Colombia, Bolivia,
México, Perú y Uruguay.
Por ello el aseguramiento y control de calidad tiene la finalidad de determinar que el
software cumpla con los requisitos especificados y que sean aptos para el propósito que
se desarrolló.
Según el autor PRESSMAN, ROGER.S. menciona: “Al igual que el ser humano, la
empresa necesita de un mecanismo de comunicación interna, "un sistema nervioso" que
coordine sus acciones. Un sistema nervioso digital que le permita realizar operaciones a
la velocidad del pensamiento: condición clave del éxito en el siglo XXI. Ahora bien Data
Mining, EIS, DSS, e-business, ERP, CRM, Knowledge Management, GroupWare,
Intranets, Sistemas Dinámicos, COBIT, RUP, CMM, son sólo algunos de los conceptos
que prometen llevar a las organizaciones a un desempeño de clase mundial, a la ruta de
la excelencia y a la calidad en sus productos y al control de mejores prácticas sobre los
niveles que garanticen la confianza y seguridad de los clientes, donde ellos son quienes
2
deciden, donde además, ahora más que nunca el futuro es impredecible. La calidad de
software debe de interpretarse, como la concordancia con los requisitos funcionales y de
rendimientos explícitamente documentados y con las características implícitas que se
espera de todo software desarrollado profesionalmente” [2] PRESSMAN, ROGER.S.
2. Objetivo
El objetivo de este informe es proponer y dar a conocer una serie de mejores prácticas
para el aseguramiento y control de Calidad de Software, para mejorar los procesos de
calidad de software de las empresas donde he laborado, para esto realice una
metodología capaz de utilizar buenas prácticas y estándares internacionales existentes en
las áreas de calidad de software como RUP, CMMI, ISO, ISTQB.
3. Problemas encontrados en el área de calidad
Estudios realizados demuestran que un alto porcentaje del éxito o fracaso del proyecto no
solamente está en la tecnología disponible y en el conocimiento que se tenga de ella, sino
también en la forma en que el proyecto no lleva un control de calidad durante su
desarrollo [3].
El desempeño de los proyectos de sistemas actualmente es: 26% de ellos son exitosos,
un 46% son proyectos cuestionables y un 28% son proyectos fallidos, arrojando una cifra
de 97 Miles de Millones de USD de desperdicio, (Standish Group International). Casi el
25% de los proyectos de software son cancelados por atraso o por salirse del
presupuesto, o por tener una baja calidad, o por experimentar alguna combinación de
ellos [5].
Las empresas donde he laborado tenían los siguientes problemas
No contaban con actividades y procedimientos de calidad de software lo cual
originaba una baja calidad del producto,
Errores en producción,
Demora en la entrega de proyectos,
Necesidad de Organizarse y hacer las cosas bien.
El tiempo para las pruebas se reduce cada vez más por qué no se sabe el alcance
de las pruebas.
Dudas en lo que se entrega al usuario es realmente lo que el pidió.
3
4. Procesos y metodologías utilizadas en el entorno laboral
A través de mi experiencia aplique los siguientes modelos de proceso y metodologías de
calidad de software las cuales detallare a continuación:
1.2 CMMI-DEV: El Modelo CMM o Modelo de Madurez de la Capacidad del Software,
definido en 1986 por el Software Engineering Institute, SEI de la Carnegie Mellon
University, despertó alto interés en la industria de software debido a que las primeras
instituciones que lo adoptaron, como el Departamento de la Defensa de los Estados
Unidos, reportaron acerca de los múltiples beneficios proporcionados, tanto
cualitativos como cuantitativos. El marco de referencia de la madurez, fundamento del
Modelo de Madurez de la Capacidad consiste en modelo de cinco niveles que
incluyen 368 actividades, desde el nivel 2 al 5, para los métodos de ingeniería en una
organización de desarrollo de software comprometida con la calidad.
Del modelo de CMM adquiri las siguientes buenas prácticas de calidad de software,
El área de proceso Verificación (VER) asegura que los productos de trabajo
seleccionados cumplan los requisitos especificados. El área de proceso Verificación
selecciona los productos de trabajo y métodos de verificación que se usarán para verificar
los productos de trabajo frente a los requisitos especificados. La verificación es
generalmente un proceso incremental, que comienza con la verificación de componentes
de producto y normalmente concluye con la verificación de los productos totalmente
ensamblados. La verificación también trata las revisiones entre pares. Las revisiones
entre pares son un método probado para eliminar defectos de manera temprana y
proporcionar una visión de valor sobre los productos de trabajo y los componentes de
producto que están siendo desarrollados y mantenidos.[]
4
1.3 El Modelo TickIT: En 1991, el Consejo Nacional de Acreditación de los Organismos
de Certificación (National Accreditation Council of Certification Bodies, NACCB),
introdujo en el Reino Unido el programa TickIT como respuesta a las quejas emitidas
por las empresas dedicadas a la elaboración de software con respecto a la calidad y
consistencia de las evaluaciones para la certificación ante la norma ISO 9001; el
objetivo del programa TickIT era ayudar a las organizaciones de software a crear
sistemas de calidad que agregaran valor a sus empresas y que cumplieran con la
norma ISO 9001.
En términos generales al proceso de desarrollo de software, se adoptaron los
siguientes elementos del modelo:
- Análisis y especificación de los requerimientos del sistema de información
asegurando que sean revisados y acordados con el área de desarrollo y/o cliente.
- Planeación, control y monitoreo del avance del desarrollo respecto al plan
comunicando a las partes afectadas y que avise oportunamente de problemas
potenciales.
Específicamente en Calidad:
- Se hace planeación de las actividades de calidad en los proyectos, especificando
las inspecciones, revisiones y pruebas requeridas durante el desarrollo.
- Se hacen Inspecciones de los productos usando como referente los estándares y
requerimientos aplicables.
- Se hacen pruebas de los entregables del diseño para verificar que satisfagan la
especificación.
- En integración se proponen pruebas e inspecciones del sistema, para demostrar
que el sistema integrado funciona correctamente y satisface su especificación.
5
1.4 El modelo TPI (Test Process Improvement) está basado en las mejores prácticas de
la industria relativas a la mejora del proceso de pruebas. El modelo incluye guías
prácticas para evaluar el nivel de madurez de pruebas de una organización así como
los pasos para mejorar el proceso.
El modelo se compone de 20 Áreas Claves, que constituyen la base para mejorar y
estructurar el proceso de pruebas, de las cuales, fueron heredadas por la estrategia y
metodología de Pruebas:
1. Estrategia de pruebas
2. Modelo del Ciclo de Vida
3. Estimación y Planeamiento
4. Técnicas de Diseño de Pruebas
5. Técnicas de Pruebas Estáticas
6. Métricas
7. Herramientas de Prueba
8. Entorno de Pruebas
9. Compromiso y Motivación
10. Funciones de Pruebas y capacitación
11. Comunicación
12. Informes
13. Manejo de Defectos
14. Administración del Testware (elementos de prueba)
15. Administración del Proceso de pruebas
16. Pruebas de Caja Blanca
6
1.5 RUP (RATIONAL UNIFIED PROCESS)
En 1995 Rational Software Corporation adquiere Objectory AB y entre 1995 y 1997 se
desarrolla Rational Objectory Process (ROP) a partir de Objectory 3.8 y del Enfoque
Rational (Rational Approach) adoptando UML como lenguaje de modelado. Desde
ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y James Rumbaugh,
Rational Software desarrolló e incorporó diversos elementos para expandir ROP,
destacándose especialmente el flujo de trabajo conocido como modelado del negocio.
En junio del 1998 se lanza Rational Unified Process.
7
Ciclo de Vida del RUP
RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias iteraciones
en número variable según el proyecto y en las que se hace un mayor o menor
hincapié en los distintas actividades [4]:
1) Inicio:
Durante la fase de inicio se define el modelo del negocio y el alcance del proyecto.
Se identifican todos los actores y Casos de Uso, se diseñan los Casos de Uso más
esenciales (aproximadamente el 20% del modelo completo). Se desarrolla, un plan
de negocio para determinar que recursos deben ser asignados al proyecto. Los
objetivos de esta fase son [4]:
Establecer el ámbito del proyecto y sus límites.
Encontrar los Casos de Uso críticos del sistema, los escenarios básicos que definen la funcionalidad.
Mostrar al menos una arquitectura candidata para los escenarios principales
Estimar el coste en recursos y tiempo de todo el proyecto.
Estimar los riesgos, las fuentes de incertidumbre.
2) Elaboración:
El propósito de la fase de elaboración es analizar el dominio del problema,
establecer los cimientos de la arquitectura, desarrollar el plan del proyecto y
eliminar los mayores riesgos. En esta fase se construye un prototipo de la
arquitectura, que debe evolucionar en iteraciones sucesivas hasta convertirse en
el sistema final. Este prototipo debe contener los Casos de Uso críticos
identificados en la fase de inicio.
8
3) Construcción:
La finalidad principal de esta fase es alcanzar la capacidad operacional del
producto de forma incremental a través de las sucesivas iteraciones. Durante esta
fase todos los componentes, características y requisitos deben ser implementados,
integrados y probados en su totalidad, obteniendo una versión aceptable del
producto.
Los objetivos incluyen:
Minimizar los costes de desarrollo mediante la optimización de recursos y evitando el tener que rehacer un trabajo o incluso desecharlo.
Conseguir una calidad adecuada tan rápido como sea práctico.
Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba) tan rápido como sea práctico. Los resultados de la fase de construcción deben ser
Los resultados de la fase de construcción deben ser
Modelos Completos (Casos de Uso, Análisis, Diseño, Despliegue e Implementación)
Arquitectura íntegra (mantenida y mínimamente actualizada)
Riesgos Presentados Mitigados
Plan del Proyecto para la fase de Transición.
Manual Inicial de Usuario (con suficiente detalle)
Prototipo Operacional – beta
Caso del Negocio Actualizado
4) Transición:
La finalidad de la fase de transición es poner el producto en manos de los usuarios
finales, para lo que se requiere desarrollar nuevas versiones actualizadas del
producto, completar la documentación, entrenar al usuario en el manejo del
producto, y en general tareas relacionadas con el ajuste, configuración, instalación
y facilidad de uso del producto.
Algunas de las cosas que puede incluir esta fase:
9
Prueba de la versión Beta para validar el nuevo sistema frente a las expectativas de los usuarios.
Funcionamiento paralelo con los sistemas legados que están siendo sustituidos por nuestro proyecto.
Conversión de las bases de datos operacionales.
Entrenamiento de los usuarios y técnicos de mantenimiento.
Traspaso del producto a los equipos de marketing, distribución y venta.
Los principales objetivos de esta fase son:
Conseguir que el usuario se valga por sí mismo.
Un producto final que cumpla los requisitos esperados, que funcione y satisfaga suficientemente al usuario.
Los resultados de la fase de transición son
Prototipo Operacional
Documentos Legales
Caso del Negocio Completo
Línea de Base del Producto completa y corregida que incluye todos los modelos del sistema
Descripción de la Arquitectura completa y corregida
Las iteraciones de esta fase irán dirigidas normalmente a conseguir una nueva versión.
Los criterios de evaluación de esta fase son los siguientes:
El usuario se encuentra satisfecho.
Son aceptables los gastos actuales versus los gastos planificados.
10
Proceso de Calidad de Software del RUP
RUP brinda un proceso para realizar las pruebas de un proyecto de software
mediante los siguientes puntos mostrare el propósito y parte de la metodología de
calidad brindada.
Etapas del procedimiento de pruebas
1. Planificar las Pruebas : El principal artefacto producido es el Plan de Pruebas.
2. Diseñar las Pruebas : Los principales artefactos producidos son el Modelo de
Pruebas (Test Model), los Casos de Prueba (Test Case), los Procedimientos de
Prueba (Test Procedures) y el documento de Análisis de Carga de Trabajo
(Workload Analysis Document).
3. Implementar las Pruebas : Los principales artefactos producidos son el Script de la
Prueba y el Componente de la Prueba.
4. Ejecutar las Pruebas en la etapa de Integración de Pruebas : El principal artefacto
producido es el documento Resultado de Pruebas.
5. Ejecutar las Pruebas en la etapa de Pruebas del Sistema: El principal artefacto
producido es el documento Resultado de Pruebas.
6. Evaluar las Pruebas : Los principales artefactos producidos son el Sumario de
Evaluación de Pruebas (Test Evaluation Summary) y los Requerimientos de
Cambio (Change Request).
11
Cada actividad en el procedimiento es esencial para probar el proyecto
exitosamente. Ninguna actividad debe ser removida del proceso de Pruebas.
El RUP maneja seis principios de los cuales uno de ellos aplica para calidad de
software el cual indica lo siguiente: Enfocarse en la calidad, el control de calidad no
debe realizarse al final de cada iteración, sino en todos los aspectos de la producción.
[4]
12
ACTIVIDADES DE PRUEBAS
13
En RUP, las pruebas son enfocadas a través del uso de un proceso iterativo y de
herramientas. Un enfoque iterativo para probar permite a la organización tratar las
pruebas casi de la misma forma que el desarrollo de software es enfocado. Cada
elemento del proyecto es un objetivo para las pruebas. Según se vayan produciendo
nuevos productos de trabajo, el cuerpo de pruebas será añadido y refinado.
Eventualmente, todas las pruebas en el cuerpo de pruebas serán acumuladas de tal
manera que pueden ser usadas para las posteriores pruebas de regresión en el ciclo
de vida del desarrollo de software.
El propósito del procedimiento de RUP es:
Verificar la interacción entre objetos
Verificar la interacción apropiada de todos los componentes del software
Verificar que todos los requerimientos hayan sido implementados correctamente
Identificar y asegurar que los defectos se hayan atendido y resuelto antes del despliegue del software
Este enfoque permite a una organización:
Identificar posibles riesgos al inicio de un proyecto.
Reducir el costo de corregir fallas enfocando los recursos cuando y donde tendrán el mayor impacto.
Maximizar la efectividad por medio de adaptar el enfoque, el proceso o el presupuesto según va progresando el proyecto.
Este procedimiento de Pruebas está relacionado a otros workflows del RUP como sigue:
El Workflow de Requerimientos captura el input principal para identificar cuales pruebas efectuar en la forma de requerimientos en un modelo de casos de uso.
El Workflow de Análisis y Diseño captura el input principal para identificar cuales pruebas efectuar describiendo cómo desarrollar un diseño.
El Workflow de Implementación produce las construcciones de software del modelo de implementación que es probado por medio del Workflow de Pruebas.
14
Dentro de una iteración, hay varias construcciones probadas: la primera cuando el
sistema es integrado y la última para probar todo el sistema.
CONTRIBUCIÓN DE LOS ANALISTAS DE CALIDAD A LAS 4 FASES DE RUP
El siguiente diagrama muestra de forma general las pruebas realizadas en RUP:
ARTEFACTOS DE PRUEBAS
Los artefactos presentados en la siguiente tabla son productos finales e intermedios que son realizados y usados durante el Workflow de Pruebas de un proyecto. Los artefactos de Pruebas capturan y comunican información de pruebas y pueden tomar la forma de un documento, un modelo o un elemento de modelo.
La Tabla 1: Identifica algunos de los artefactos que deben ser desarrollados en el Workflow de Pruebas.
Artefactos
Creado / Revisado
Revisar Detalles
Herramientas Usadas
Incep
Elab
Cons
Trans
15
Caso de Pruebas
X Informal - Interno
Test Manager
Plan de Pruebas / Procedimientos
X X Formal – Externo o Prueba Interna
Manager
Resultados de las Pruebas
X X Formal Interno
Test Manager
Script de Pruebas
X X X Informal – Interno
Robot, Manual Test
5. Soporte teórico del informe
3.1 Calidad de Software
Clásicamente se refiere al cumplimiento de las especificaciones también es reconocida
como un arma competitiva clave para el mejor desempeño del software transformando a
las certificaciones de calidad en una necesidad.
De acuerdo a la norma ISO/IEC-9126 define que la calidad de software es:
“La totalidad de la funcionabilidad y las características de un producto software que
contribuyen a su habilidad de satisfacer necesidades especificadas o implícitas”i
Y está constituida por:
- Funcionalidad
- Fiabilidad
- Usabilidad
- Eficiencia
- Mantenibilidad
16
- Portabilidad
El Aseguramiento de la Calidad da confianza en que el producto reúne las características
necesarias para satisfacer todos los requisitos del Sistema de Información.
Por tanto, para asegurar la calidad de los productos resultantes el equipo de Calidad
deberá realizar un conjunto de actividades que servirán para prevenir, reducir y eliminar
las deficiencias de calidad de los productos para la satisfacción del cliente y el usuario.
Se divide en dos tipos:
- Actividades constructivas, con el objeto de prevenir defectos, por
ejemplo a través de la aplicación de métodos apropiados de ingeniería de
software.
QA Contructivo
(Gestión de Calidad)
Organizació
n
Guías
Estándares
Listas de comprobación
Reglas de proceso y normas
Requisitos legales
Técnico Métodos
Herramientas
Lenguajes
Listas / Plantillas
Entorno de desarrollo Integrado (IDE).
- Actividades analíticas, con el objetivo de detectar defectos, por ejemplo a
través de pruebas conducentes a la corrección de defectos y prevención de
fallos. Incrementando así la calidad del software.
QA Analítico
(Verificación y
Pruebas)
Dinámico Técnica
de Caja
Negra
Clases de equivalencia.
Análisis de valores límite.
Pruebas de transición de estado.
Tablas de decisión.
Algoritmos “Pairwise” (En parejas).
Técnicas basadas en la experiencia
17
Técnica
de Caja
Blanca
Cobertura de sentencia
Cobertura de rama
Cobertura de condición
Cobertura de camino
Estático Revisiones / Ensayos
Análisis de flujo de control
Análisis de flujo de datos
Métricas del compilador / analizador.
6. Conclusiones
El desarrollo del presente informe está motivado por el deseo de demostrar que la calidad
de software debe ser aplicada a cualquier empresa, institución o consultora que provee
servicios de desarrollo de sistemas de información.
La calidad de un producto como el software no es un añadido que puede incluirse como
un accesorio. Es inherente al software y debe regirse por el principal objetivo de satisfacer
las necesidades del cliente, a veces claramente especificadas y en otras ocasiones
posiblemente implícitas (por ejemplo, el cliente no expresa explícitamente que desea un
producto cuyo mantenimiento no sea problemático porque es algo que da por hecho). Así,
la calidad se encuentra estrechamente relacionada con el proceso de desarrollo del
software.
7. Bibliografía
18
i
[1] PERRY, WILLIAM E, “Quality assurance for information systems”. En: QED technical publishing group; Primera Edición ; Wellesley, MA, U.S.A.; 1991.119[2] PRESSMAN, ROGER.S.; ingeniería de Software. Un enfoque práctico. Cuarta Edición. Mc Graw Hill. 1998[3] TOTAL QUALITY MANAGEMENT (TQM) Stauss/ Friege: Zehn Lektionen in TQM; in: Havard Business manager, 2/96; Seite 20-33 Oess: Total Quality Management; Wiesbaden 1993[4] JACABOSON, I., BOOCH, G., RUMBAUGH J., El Proceso Unificado de Desarrollo de Software, 2000 Addison Wesley[5] GUILLERMO PANTALEON, “Calidad en el desarrollo del software” Editorial Marcombo; Primera Edición.[6] ISO 12207 estándar internacional
Definición: Calidad Software(Según ISO/IEC-9126)http://www.ieee.org.sv/imagenes/eventos/abril/2012/03/01/HOJA%20MEETING%20PONENCIA%20INTERNACIONAL.pdf
http://www.kybeleconsulting.com/servicios/calidad-gestion-ingenieria-del-software/puntos-funcion/http://iso25000.com/