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/