FACULTAD DE INGENIERIA

ESCUELA PROFESIONAL DE INGENIERIA INFORMATICA Metodologa de Aseguramiento y Control de Calidad de Software

INFORME DE EXPERIENCIA PROFESIONAL PARA OBTENER EL TTULO PROFESIONAL DE INGENIERO INFORMATICO

PRESENTADO POR: GRACE JULIANNE BELLIDO CHOCANO
LIMA PER 2013

1.

Introduccin
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 metodologa de calidad de software que implemente para las empresas en las cuales trabaje. Como analista de calidad de software he trabajado con varias metodologas y buenas prcticas las cuales plasmare en el presente informe. Para validar las mejores prcticas que propongo he estudiado como la metodologa 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), Metodologa BaQEM para pruebas funcionales de software, metodologa RUP, conceptos del ISTQB. 1.1 Marco Situacional

En los ltimos aos se ha venido escuchando de procesos y/o metodologas 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 tambin aplicadas por entidades certificadoras como en Espaa Spanish Software TestingQualificationBoard (ISTQB), en Hispanoamrica el HispanicAmerica Software TestingQualificationBoard (HASTQB) conformado por Argentina, Colombia, Bolivia, Mxico, 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 propsito que se desarroll. Segn el autor PRESSMAN, ROGER.S. menciona: Al igual que el ser humano, la empresa necesita de un mecanismo de comunicacin interna, "un sistema nervioso" que coordine sus acciones. Un sistema nervioso digital que le permita realizar operaciones a la velocidad del pensamiento: condicin clave del xito en el siglo XXI. Ahora bien Data Mining, EIS, DSS, e-business, ERP, CRM, Knowledge Management, GroupWare, Intranets, Sistemas Dinmicos, COBIT, RUP, CMM, son slo algunos de los conceptos que prometen llevar a las organizaciones a un desempeo de clase mundial, a la ruta de la excelencia y a la calidad en sus productos y al control de mejores prcticas sobre los niveles que garanticen la confianza y seguridad de los clientes, donde ellos son quienes 2

deciden, donde adems, ahora ms que nunca el futuro es impredecible. La calidad de software debe de interpretarse, como la concordancia con los requisitos funcionales y de rendimientos explcitamente documentados y con las caractersticas implcitas 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 prcticas 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 metodologa capaz de utilizar buenas prcticas y estndares 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 tecnologa disponible y en el conocimiento que se tenga de ella, sino tambin en la forma en que el proyecto no lleva un control de calidad durante su desarrollo [3]. El desempeo 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 combinacin de ellos [5]. Las empresas donde he laborado tenan los siguientes problemas No contaban con actividades y procedimientos de calidad de software lo cual originaba una baja calidad del producto, Errores en produccin, Demora en la entrega de proyectos, Necesidad de Organizarse y hacer las cosas bien. El tiempo para las pruebas se reduce cada vez ms 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 metodologas utilizadas en el entorno laboral

A travs de mi experiencia aplique los siguientes modelos de proceso y metodologas de calidad de software las cuales detallare a continuacin:

4.1 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 inters 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 mltiples 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 mtodos de ingeniera en una organizacin de desarrollo de software comprometida con la calidad.

Del modelo de CMM adquiri las siguientes buenas prcticas de calidad de software,

El rea de proceso Verificacin (VER) asegura que los productos de trabajo seleccionados cumplan los requisitos especificados. El rea de proceso Verificacin selecciona los productos de trabajo y mtodos de verificacin que se usarn para verificar los productos de trabajo frente a los requisitos especificados. La verificacin es generalmente un proceso incremental, que comienza con la verificacin de componentes de producto y normalmente concluye con la verificacin de los productos totalmente ensamblados. La verificacin tambin trata las revisiones entre pares. Las revisiones entre pares son un mtodo probado para eliminar defectos de manera temprana y proporcionar una visin de valor sobre los productos de trabajo y los componentes de producto que estn siendo desarrollados y mantenidos.[]

4.2 El Modelo TickIT: En 1991, el Consejo Nacional de Acreditacin de los Organismos de Certificacin (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 elaboracin de software con respecto a la calidad y consistencia de las evaluaciones para la certificacin 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 trminos generales al proceso de desarrollo de software, se adoptaron los siguientes elementos del modelo:

- Anlisis y especificacin de los requerimientos del sistema de informacin asegurando que sean revisados y acordados con el rea de desarrollo y/o cliente. - Planeacin, control y monitoreo del avance del desarrollo respecto al plan comunicando a las partes afectadas y que avise oportunamente de problemas potenciales. Especficamente en Calidad:

- Se hace planeacin 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 estndares y requerimientos aplicables. - Se hacen pruebas de los entregables del diseo para verificar que satisfagan la especificacin. - En integracin se proponen pruebas e inspecciones del sistema, para demostrar que el sistema integrado funciona correctamente y satisface su especificacin.

4.3 El modelo TPI (Test Process Improvement) est basado en las mejores prcticas de la industria relativas a la mejora del proceso de pruebas. El modelo incluye guas prcticas para evaluar el nivel de madurez de pruebas de una organizacin 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 metodologa de Pruebas: 1. Estrategia de pruebas 2. Modelo del Ciclo de Vida 3. Estimacin y Planeamiento 4. Tcnicas de Diseo de Pruebas 5. Tcnicas de Pruebas Estticas 6. Mtricas 7. Herramientas de Prueba 8. Entorno de Pruebas 9. Compromiso y Motivacin 10. Funciones de Pruebas y capacitacin 11. Comunicacin 12. Informes 13. Manejo de Defectos 14. Administracin del Testware (elementos de prueba) 15. Administracin del Proceso de pruebas 16. Pruebas de Caja Blanca

4.4 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,

destacndose especialmente el flujo de trabajo conocido como modelado del negocio. En junio del 1998 se lanza Rational Unified Process.

Ciclo de Vida del RUP RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias iteraciones

en nmero variable segn 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 disean los Casos de Uso ms 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 lmites. Encontrar los Casos de Uso crticos del sistema, los escenarios bsicos 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) Elaboracin: El propsito de la fase de elaboracin 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 crticos identificados en la fase de inicio.

3) Construccin: La finalidad principal de esta fase es alcanzar la capacidad operacional del producto de forma incremental a travs de las sucesivas iteraciones. Durante esta fase todos los componentes, caractersticas y requisitos deben ser implementados, integrados y probados en su totalidad, obteniendo una versin aceptable del producto. Los objetivos incluyen: Minimizar los costes de desarrollo mediante la optimizacin de recursos y evitando el tener que rehacer un trabajo o incluso desecharlo. Conseguir una calidad adecuada tan rpido como sea prctico. Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba) tan rpido como sea prctico. Los resultados de la fase de construccin deben ser Los resultados de la fase de construccin deben ser Modelos Completos (Casos de Uso, Anlisis, Diseo, Despliegue e Implementacin) Arquitectura ntegra (mantenida y mnimamente actualizada) Riesgos Presentados Mitigados Plan del Proyecto para la fase de Transicin. Manual Inicial de Usuario (con suficiente detalle) Prototipo Operacional beta Caso del Negocio Actualizado 4) Transicin: La finalidad de la fase de transicin es poner el producto en manos de los usuarios finales, para lo que se requiere desarrollar nuevas versiones actualizadas del producto, completar la documentacin, entrenar al usuario en el manejo del producto, y en general tareas relacionadas con el ajuste, configuracin, instalacin y facilidad de uso del producto.

Algunas de las cosas que puede incluir esta fase:

 Prueba de la versin Beta para validar el nuevo sistema frente a las expectativas de los usuarios. Funcionamiento paralelo con los sistemas legados que estn siendo sustituidos por nuestro proyecto. Conversin de las bases de datos operacionales. Entrenamiento de los usuarios y tcnicos de mantenimiento. Traspaso del producto a los equipos de marketing, distribucin 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 transicin son Prototipo Operacional Documentos Legales Caso del Negocio Completo Lnea de Base del Producto completa y corregida que incluye todos los modelos del sistema Descripcin de la Arquitectura completa y corregida Las iteraciones de esta fase irn dirigidas normalmente a conseguir una nueva versin. Los criterios de evaluacin 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 propsito y parte de la metodologa de calidad brindada. Etapas del procedimiento de pruebas 1. Planificar las Pruebas: El principal artefacto producido es el Plan de Pruebas. 2. Disear 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 Anlisis 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 Integracin 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 Evaluacin 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 iteracin, sino en todos los aspectos de la produccin. [4]

12

ACTIVIDADES DE PRUEBAS

13

En RUP, las pruebas son enfocadas a travs del uso de un proceso iterativo y de herramientas. Un enfoque iterativo para probar permite a la organizacin 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. Segn se vayan produciendo nuevos productos de trabajo, el cuerpo de pruebas ser aadido y refinado. Eventualmente, todas las pruebas en el cuerpo de pruebas sern acumuladas de tal manera que pueden ser usadas para las posteriores pruebas de regresin en el ciclo de vida del desarrollo de software. El propsito del procedimiento de RUP es: Verificar la interaccin entre objetos Verificar la interaccin 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 organizacin: Identificar posibles riesgos al inicio de un proyecto. Reducir el costo de corregir fallas enfocando los recursos cuando y donde tendrn el mayor impacto. Maximizar la efectividad por medio de adaptar el enfoque, el proceso o el presupuesto segn 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 Anlisis y Diseo captura el input principal para identificar cuales pruebas efectuar describiendo cmo desarrollar un diseo. El Workflow de Implementacin produce las construcciones de software del modelo de implementacin que es probado por medio del Workflow de Pruebas.

14

Dentro de una iteracin, hay varias construcciones probadas: la primera cuando el sistema es integrado y la ltima para probar todo el sistema.

CONTRIBUCIN 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 informacin 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 Incep Elab Cons Trans Caso de Pruebas X Revisar Herramientas Detalles Usadas Informal Test Manager - Interno
15

Plan de Pruebas / Procedimientos

Formal Manager Externo o Prueba Interna X X Formal Interno Test Manager

Resultados de las Pruebas Script de Pruebas X

X X

Informal Robot, Manual Test Interno

5.

Soporte terico del informe

3.1 Calidad de Software Clsicamente se refiere al cumplimiento de las especificaciones tambin es reconocida como un arma competitiva clave para el mejor desempeo 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 caractersticas de un producto software que contribuyen a su habilidad de satisfacer necesidades especificadas o implcitasi Y est constituida por: Funcionalidad Fiabilidad Usabilidad Eficiencia Mantenibilidad Portabilidad

El Aseguramiento de la Calidad da confianza en que el producto rene las caractersticas necesarias para satisfacer todos los requisitos del Sistema de Informacin. Por tanto, para asegurar la calidad de los productos resultantes el equipo de Calidad deber realizar un conjunto de actividades que servirn para prevenir, reducir y eliminar las deficiencias de calidad de los productos para la satisfaccin del cliente y el usuario.

16

Se divide en dos tipos: Actividades constructivas, con el objeto de prevenir defectos, por ejemplo a travs de la aplicacin de mtodos apropiados de ingeniera de software.

QA Contructivo (Gestin de Calidad)

Organizacin Guas Estndares Listas de comprobacin Reglas de proceso y normas Requisitos legales Tcnico Mtodos Herramientas Lenguajes Listas / Plantillas Entorno de desarrollo Integrado (IDE).

Actividades analticas, con el objetivo de detectar defectos, por ejemplo a travs de pruebas conducentes a la correccin de defectos y prevencin de fallos. Incrementando as la calidad del software.

QA Analtico (Verificacin y Pruebas)

Dinmico Tcnica de Caja Negra

Clases de equivalencia. Anlisis de valores lmite. Pruebas de transicin de estado. Tablas de decisin. Algoritmos Pairwise (En parejas). Tcnicas basadas en la experiencia

Tcnica de Caja Blanca

Cobertura de sentencia Cobertura de rama Cobertura de condicin Cobertura de camino

Esttico

Revisiones / Ensayos Anlisis de flujo de control Anlisis de flujo de datos Mtricas del compilador / analizador. 17

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, institucin o consultora que provee servicios de desarrollo de sistemas de informacin. La calidad de un producto como el software no es un aadido 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 implcitas (por ejemplo, el cliente no expresa explcitamente que desea un producto cuyo mantenimiento no sea problemtico porque es algo que da por hecho). As, la calidad se encuentra estrechamente relacionada con el proceso de desarrollo del software.

7.

Bibliografa

[1] PERRY, WILLIAM E, Quality assurance for information systems. En: QED technical publishing group; Primera Edicin ; Wellesley, MA, U.S.A.; 1991.119 [2] PRESSMAN, ROGER.S.; ingeniera de Software. Un enfoque prctico. Cuarta Edicin. 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 Edicin. [6] ISO 12207 estndar internacional
i

Definicin: Calidad Software(Segn ISO/IEC-9126) http://www.ieee.org.sv/imagenes/eventos/abril/2012/03/01/HOJA%20MEETING%20PONENCIA%20INTERN ACIONAL.pdf http://www.kybeleconsulting.com/servicios/calidad-gestion-ingenieria-del-software/puntos-funcion/ http://iso25000.com/

18