AO DE LA INTEGRACIN NACIONAL Y EL RECONOCIMIENTO DE NUESTRA DIVERSIDAD

Universidad San Luis Gonzaga de Ica

TEMA

FUNDAMENTOS DE PRUEBA DE SOFTWARE

Curso Catedrtico Integrantes

: Pruebas de Software : Ing. Alonso Morales Loaiza : Alvarado Yoshidaira, Sole Alejandra Alvarado Pachas, Euler Hardy Bautista Ramos, Katherine Jeaneth Pastor Rodriguez, Rocio del Pilar

Ciclo

: IX- S1

ICA PER

INDICE
PGINA
Introduccin 1 Calidad y el Software 1.1 Concepto bsico de calidad 1.2 Calidad de Software: Concepto 1.3 Aseguramiento de calidad de Software y Tcnicas Asociadas 1.3.1 Definicin 1.3.2 SQA no es lo mismo que SQC 1.3.3 Funciones generales de SQA 1.3.4 Actividades del Proceso de SQA 2 Modelos de Calidad de Software 2.1 Definicin 2.2 Estructura de un modelo de calidad de Software 2.2.1 Estructura 2.3Ventajas de los Modelos de calidad de Software 2.4 Modelos de calidad de Software 2.4.1 Modelos de calidad de Software a nivel de Proceso 2.4.2 Modelos de calidad de Software a nivel de Producto 3 Definicin de verificacin y validacin 3.1 Verificacin del Software 3.1.1 Definicin 3.1.2 Revisin Del Producto 3.2 Validacin del Software 3.2.1 Definicin 4- Objetivos de la Prueba 4.1 Objetivos 4.2 Limitaciones de las Pruebas de Software 5 Planificacin y Control de Pruebas 6 Mtricas y mediciones del Software 6.1 Medida del Software 6.2Mtricas del Software 6.3Tipos de Mtricas 7 Verificacin y Validacin en el proceso de desarrollo de Software Conclusiones Bibliografa 2 3 3 3 3 4 4 6 8 11 11 12 12 13 14 14 18 22 22 22 24 23 23 23 23 25 30 34 34 34 35 42 51 52

Introduccin Es una gran oportunidad y un reto para la industria del software desarrollar las estrategiasque le permitan un posicionamiento y un reconocimiento internacional con productoscompetitivos de exportacin, lo que requerir entre otras, de la implantacin de un Software sea genrico o a medida para el tratamiento adecuado de la informacin, as como la eleccin de un Modelo de calidad de Software que se ajuste a las necesidades de la organizacin, dejando de lado la informalidad que caracteriza anuestra industria nacional de software. Cualquier organizacin que se dedica a la investigacin, produccin y comercializacin de software debe considerar la calidad, como tarea

imprescindible paratener xito, alcanzar los niveles de competitividad de las organizaciones extranjeras con elfin de lograr una certificacin,donde existe un mercado en el cual el cliente es cada vez ms exigente, no slo en lo que se refiere al precio, sino sobre todo, en cuanto a los servicios y a la confiabilidad que brindan los productos de software. Para alcanzar un buen nivel de confiabilidad en el producto software es necesario realizar Pruebas de Software antes de implantar el sistema para la produccin. En muchos sentidos la prueba es un proceso autnomo, y el nmero de tipos diferentes de prueba varia tanto como los diferentes enfoques de desarrollo. Durante muchos aos la nica defensa contra los errores de programacin fueron el diseo cuidadoso y la inteligencia natural del programador. Ahora estamos en la era en que las tcnicas modernas de diseo y las revisiones de las tcnicas formales nos estn ayudando a reducir el nmero de errores iniciales inherentes al cdigo. Esta bsqueda de reconocimiento internacional de calidad,que se ha iniciado en algunas empresas del sector, permitir enfrentar los mercados conmayores posibilidades de xito y abrir las puertas para que otras empresas se animen aestos procesos y se desate en el medio un alto inters y compromiso hacia la incorporacinde Software y sus respectivos Modelos de calidad.

1. CALIDAD Y EL SOFTWARE 1.1. Conceptos bsico de calidad Podemos encontrar muchas definiciones en los textos de calidad todas de ellas muy similares: Propiedad o conjunto de propiedades inherentes a un objeto que permiten apreciarlo como mejor, igual o peor que otros objetos de su especie. [DRAE: Diccionario de la Real Acadmica Espaola] Conjunto de propiedades y de caractersticas de un producto o servicio que le confieren capacidad para satisfacer necesidades expresadas o implcitas. [ISO 8042:1994] 1.2. Calidad de software: Conceptos La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario. [IEEE, Std 610-1900] Concordancia del software producido con los requerimientos explcitamente establecidos, con los estndares de desarrollo prefijados y con los requerimientos implcitos no establecidos formalmente, que desea el usuario. [Pressman, 1998] 1.3. Aseguramiento de calidad del software y tcnicas asociadas 1.3.1. Definicin El Aseguramiento de Calidad del Software es el conjunto de actividades planificadas y sistemticas, cuyo primer objetivo es evaluar la calidad y la adherencia de los productos de software a los estndares, procesos y procedimientos. Este aseguramiento se disea para cada aplicacin antes de comenzar a desarrollarla y no despus. 3

1.3.2. SQA no es lo mismo que SQC (SoftwareQuality Control)) Generalmente cuando le preguntamos a un profesional de sistemas que es lo que entiende por aseguramiento de la calidad del software, inmediatamente comienza a hablar de testing, algunos de ellos incluyen a la validacin y verificacin y luego empiezan a hablar de revisiones, las cuales son slo extensiones del testing. Es decir, a menudo hay una confusin entre SQA y el testing (el cual actualmente forma parte del rea de control de calidad del software SQC).

Haciendo slo testing y revisiones no aseguramos la calidad de los productos, sino aseguramos el cumplimiento de especificaciones tanto funcionales como tcnicas. En el desarrollo de software la diferencia entre SQC y SQA no est clara y estos trminos a menudo se confunden, SQA se encarga de controlar el cumplimiento del proceso, mientras que SQC son aquellas acciones del

aseguramiento de la calidad que proporcionan un medio para controlar y medir las caractersticas de un elemento, proceso o facilidad respecto a los requisitos establecidos.

La siguiente tabla expone sintticamente las diferencias entre control de calidad y aseguramiento de la calidad.

Control de calidad Detecta problemas en

Aseguramiento de calidad los Asegura la adherencia a los

productos de trabajo.

procesos, estndares y planes.

Verifica que los productos de Evala que los procesos, planes trabajo cumplan con los y estndares utilizados en el estndares de calidad proyecto cumplan con los especificados en el plan de estndares organizacionales. proyecto. Revisa producto. el contenido del

Revisa procesos.

Tabla: Control de calidad vs. Aseguramiento de la calidad

En conclusin, el rol del SQA es auditar que los distintos equipos de la organizacin, inclusive el de SQC siguen los procedimientos, estndares y procesos establecidos. El equipo de SQA debera establecer mtricas para medir la efectividad del proceso. Como complemento el rol de SQC es tomar una actitud activa de verificacin y validacin del resultado o salida del proceso implementado.

1.3.3. Funciones generales del SQA Describir los diferentes roles que puede jugar el equipo de SQA en una organizacin nos dar una visin clara de las funciones que puede llevar a cabo. Como polica del proceso

el trabajo del equipo de SQA es

asegurar que el desarrollo sigue el proceso establecido. Entre sus funciones en este rol se encuentran: Auditar los productos del trabajo para identificar deficiencias. Determinar el cumplimiento del plan de desarrollo del proyecto y del proceso de desarrollo de software. Juzgar el proceso y no el producto.

Como abogado del cliente el trabajo del equipo de SQA es representar al cliente. Entre sus funciones en este rol se encuentran: Identificar la funcionalidad que al cliente le gustara encontrar. Ayudar a la organizacin a sensibilizarse con las necesidades del cliente. Actuar como un cliente de prueba para obtener una alta satisfaccin del cliente. Como analista el trabajo del equipo de SQA es recabar informacin. Entre sus funciones en este rol se encuentran: Juntar muchos datos sobre todos los aspectos del producto y del proceso. Con esta informacin ayudar a mejorar los procesos y los productos.

Como proveedor de informacin el trabajo del equipo de SQA es revisar qu es lo que est hecho y decir cules objetivos tcnicos realmente estn cumplidos para que la gerencia pueda tomar mejores decisiones de negocios. Entre sus funciones en este rol se encuentran: Proveer informacin tcnica objetiva para que la gerencia pueda usarla para tomar mejores decisiones. Proveer informacin apropiada de las clases de productos y de los riesgos asociados con estos. Concentrarse ms en la reduccin de los riesgos que en el cumplimiento del proceso. Como responsable de la elaboracin del proceso el trabajo del equipo de SQA es participar en la definicin de los planes, procesos, estndares y procedimientos para asegurar que se ajustan a las necesidades del proyecto y que pueden ser usados para realizar las evaluaciones de QA y cumplir los requerimientos del proyecto y las polticas de la organizacin. Para cumplir este rol el aseguramiento de la calidad debera comenzar en las fases tempranas del proyecto. Aqu conviene aclarar que no necesariamente las personas que definen la metodologa a seguir pertenecen al equipo de QA. Definir la metodologa puede llegar a ser o no una actividad del equipo de QA. Una estructura posible en el proceso de mejora del software puede ser contar con un SEPG (Software Engineering Process Group) totalmente independiente del equipo de QA, encargado de definir la metodologa mientras que el equipo de QA se limita a verificar que se cumpla dicha metodologa.

1.3.4. Actividades del proceso de SQA La conformidad con los estndares y procedimientos es evaluada a travs del monitoreo de procesos, la evaluacin del producto y las auditoras. El monitoreo de procesos y la evaluacin del producto

corresponden a las actividades de SQA responsables de verificar que el plan del proyecto, los procedimientos y estndares son seguidos correctamente durante el desarrollo y el control de los procesos. La auditora es una tcnica, que analiza con detenimiento los procesos y productos sobre la base de su adherencia a los

procedimientos y estndares. Su propsito es garantizar que se cuenta con un proceso de control adecuado, que la documentacin es mantenida y que los informes de los desarrolladores reflejan el estado de la actividad que desempean. Y su producto, un informe de guas y recomendaciones para los procesos de calidad y desarrollo dirigido a la administracin superior. Si bien estas tareas son las principales actividades de SQA, aun son demasiado generales con relacin a una implantacin de esta rea de prcticas. Por ello, es necesario establecer y definir las tareas que permitan materializar el monitoreo de procesos, la evaluacin del producto y las auditorias al interior de una organizacin. Estas actividades son: Estndares Revisiones Prueba Anlisis de defectos Gestin de configuracin de

1.3.4.1 Estndares Los estndares son los cimientos de cualquier sistema de calidad de software, pues proveen la base para la evaluacin y medicin de las actividades y de los productos de trabajo durante todo el ciclo de vida del software. Por tanto, ellos establecen el marco de trabajo para el desarrollo de software, constituyndose en un factor crtico de este ltimo. Su aplicacin otorga uniformidad, consistencia, rigurosidad, y fortaleza a los mtodos y a las actividades del desarrollo de software. Es ms, los estndares entregan mtodos y prcticas comunes que permiten concretar una tarea repetidas veces en la misma forma. Para SQA es de gran importancia contar tempranamente con estndares confiables y apropiados, pues las tareas de monitoreo, evaluacin y auditora toman como entrada estas definiciones. 1.3.4.2 Revisiones Las revisiones constituyen la primera forma de monitorear y evaluar la calidad de los productos de trabajo, y adems, proveen mayor visibilidad al desarrollo. Las revisiones son una metodologa definida, estructurada y disciplinada para la deteccin e identificacin de defectos en los productos de trabajo durante el ciclo de vida del software. El rol de SQA es observar, participar de ser necesario y verificar que las revisiones de realicen y documenten correctamente. Tambin debe supervisar que cualquier accin requerida, fruto de estas actividades, sea asignada, documentada, programada y actualizada.

1.3.4.3 Prueba La prueba es la ltima actividad de evaluacin del producto que permite detectar defectos y establecer el nivel de satisfaccin de los requerimientos. Sus actividades incluyen la planificacin, diseo, ejecucin y reporte sobre los diferentes niveles de prueba existentes durante el proyecto. Es responsabilidad de SQA verificar que la prueba se realice de acuerdo a los planes y procedimientos establecidos. Tambin, debe corroborar la completitud y adherencia a los estndares de la documentacin de la prueba. Esto incluye a los planes,

especificaciones, procedimientos e informes. 1.3.4.4 Anlisis de defectos Los defectos ocurren a lo largo de todo el ciclo de vida del software sin excepcin. Por ello resulta natural concentrar esfuerzos en su deteccin y correccin. No obstante a que la correccin de defectos es importante, ms lo es su prevencin. SQA debe responsabilizarse de crear un mtodo de identificacin de defectos de deficiencias del proceso y de realizar los cambios necesarios para mejorar su eficacia y eficiencia. Es ms, debe apoyar a la gestin en la definicin y perfeccionamiento de los procesos. Por tanto, el anlisis de defectos es una actividad de su entera responsabilidad.

10

2. MODELOS DE CALIDAD DE SOFTWARE

2.1 Definicin Los Modelos de Calidad son aquellos documentos que integran la mayor parte de las mejores prcticas, proponen temas de administracin en los que cada organizacin debe hacer nfasis, integran diferentes prcticas dirigidas a los procesos clave y permiten medir los avances en calidad.Permiten definir criterios de desarrollo que guan la forma en que se aplica la Ingeniera del Software. Se debe entender que un modelo de calidad no es una metodologa que nos resuelva la vida de forma sencilla y clara, los modelos de calidad nos dicen QUE hacer, no COMO hacerlo. Los Modelos y/o Estndares permiten que las Empresas de Software realicen sus tareas y funciones teniendo en cuenta la Calidad. Cualquier organizacin que se dedica a la investigacin, produccin y

comercializacin de software debe considerar la calidad, hoy con ms razn, donde existe un mercado en el cual el cliente es cada vez ms exigente, no slo en lo que se refiere al precio, sino sobre todo, en cuanto a los servicios y a la confiabilidad que brindan los productos de software. La calidad desempea un rol determinante para la competitividad de la empresa. Cuando una empresa est funcionando y decide implantar un Modelo / Estndar de Calidad del Software, es seal que la empresa tiene el propsito de permanecer y crecer en el mercado, ser competitiva, proteger los intereses de los accionistas, cuidar la fuente de trabajo y mejorar la calidad de vida de su personal. Implantar Modelos o Estndares de Calidad tiene como objetivo principal que las empresas desarrollen sistemticamente, productos, bienes y servicios de mejor calidad y cumplan con las necesidades y deseos de los clientes.

11

La base para disear e implantar un buen Modelo / Estndar de Calidad es conocer profundamente las caractersticas y necesidades de la empresa que lo aplicar y los deseos y pretensiones de sus clientes actuales y potenciales.

2.2 Estructura De Un Modelo De Calidad De Software

2.2.1 Estructura En los Modelos de Calidad, la calidad se define de forma jerrquica. Es un concepto que se deriva de un conjunto de sub-conceptos, cada uno de los cuales se va a evaluar a travs de un conjunto de indicadores o mtricas. Tienen una estructura, por lo general, en tres niveles:

12

2.1.1-1

Factores de la Calidad de

En el nivel ms alto de la jerarqua se encuentran los Factores

Calidad, que representan la calidad desde el punto de vista del usuario. Son las caractersticas que componen la calidad. Tambin se les llama Atributos de Calidad Externos.

2.1.1-2

Criterios de Calidad del Producto

Cada uno de los factores se descompone en un conjunto de Criterios de calidad. Son atributos que, cuando estn presentes, contribuyen al aspecto de la calidad que el factor asociado representa. Se trata de una visin de la calidad desde el punto de vista del producto software. Tambin se les llama Atributos de Calidad Internos.

2.1.1-3

Mtricas del Producto

Para cada uno de los criterios de calidad se definen entonces un conjunto de Mtricas, que son medidas cuantitativas de ciertas caractersticas del producto que, cuando estn presentes, dan una indicacin del grado en que dicho producto posee un determinado atributo de calidad.

2.3 Ventajas de los Modelos de Calidad del Software

Las ventajas de implantar Modelos de Calidad del Software son: Tener una oportunidad para corregir los procesos de software que se hayan desajustado con el tiempo. Reducir los costos en todos los procesos. Cambiar la actitud del personal de la empresa. Realizar una mejora continua en la calidad de los procesos de software utilizados, servicios y productos de software.

13

Lograr que la empresa de software sea ms competitiva. Aumentar la productividad, efectividad y utilidad de la empresa. Asegurar la satisfaccin de los clientes internos y externos. Tener productos de software y servicios con valor agregado. Tener permanentemente mejores procesos, productos de

software y servicios.

2.4 Modelos de Calidad de Software

2.4.1 Modelos de Calidad del Software a Nivel Proceso

2.4.1-1

CMM (Capability Maturity Model)

CMM es un modelo que estudia los procesos de desarrollo de software de una organizacin y produce una evaluacin de la madurez de la organizacin segn una escala de 5 niveles. La madurez de un proceso es un indicador de la capacidad para construir un software de calidad. Fue desarrollado por el Software Engineering Institute (SEI). CMM provee a las organizaciones de software una gua de cmo realizar un control de los procesos de desarrollo y mantenimiento de software. Permite seleccionar estrategias de mejoras de procesos determinando la madurez de los procesos existentes e identificando factores crticos respecto de la calidad del software y del mejoramiento de los procesos. La Madurez del Proceso de Software es aquello en el que un proceso especfico es definido, administrado, medido y controlado. El Nivel de Madurez es un conjunto de metas que cuando son cumplidas constituye un componente del proceso de software. Cada nivel de madurez establece un componente distinto en el proceso de software. Existen 5 niveles de madurez: inicial, repetible, definido, administrado y optimizado. 14

Niveles Nivel 1: Inicial (Initial) Este nivel no provee un ambiente de desarrollo y mantenimiento de software. Se tiene un nmero de entradas, seguidas por cierto proceso que realmente no estaba documentado, ni se documenta. El nivel inicial representa una situacin sin ningn esfuerzo en la garanta de calidad y gestin del proyecto, donde cada equipo del proyecto puede desarrollar software de cualquier forma eligiendo los mtodos, estndares y procedimientos a utilizar que podrn variar desde lo mejor hasta lo peor. En este nivel lo normal es no alcanzar las metas definidas ni en tiempo, ni costos, ni recursos planeados. Se centraliza ms en situaciones particulares que en la organizacin.

Nivel 2: Repetible (Repeatable) En este nivel se establecen polticas para administrar un proyecto de software y procedimientos para implementar las polticas

establecidas. Se realizan revisiones para detectar si el proceso est funcionando correctamente. La planificacin y administracin de proyectos se basa en experiencias anteriores exitosas (repetible). 15

El nivel 2 representa el hecho que un desarrollador de software ha definido ciertas actividades tales como el informe del esfuerzo, el tiempo empleado, y el informe de las tareas realizadas. En este nivel, no se cuenta con mtricas para servicios, solamente para productos.

Nivel 3: Definido (Defined) En este nivel se tiene un proceso de software estndar en la organizacin para desarrollar y mantener el software. Este est documentado y es implementado a lo largo de toda la organizacin en distintos proyectos. Este proceso es la unin de prcticas de Ingeniera de Software y de administracin de procesos. La organizacin tiende a estandarizar sus procesos, ya que los mismos son estables y repetibles. Este representa el hecho que un desarrollador de software ha definido tanto procesos tcnicos como de gestin. La medicin se hace en los productos y servicios.

Nivel 4: Administrado (Managed) Este nivel plantea la calidad y productividad respecto de las actividades del proceso de software. El nivel 4 podra llamarse cuantitativo ya que en l cualquier decisin es respaldada por una base cuantitativa. Se mide el progreso y los problemas. El cliente tendr un entendimiento medible tanto de la capacidad del proceso como del riesgo que ste implica, incluso antes que el proyecto inicie. Se evalan los procesos de software y sus productos respectivos. Este nivel tiene como objetivo las metas de calidad en los procesos y productos y comprende el concepto de medicin y el uso de mtricas. Es importante que el desarrollador comprenda el concepto de mtrica para que alcance el nivel 4 o 5. Estas mtricas se utilizan para supervisar y controlar un proyecto de software. 16

Nivel 5: Optimizado (Optimized) La empresa est en un proceso de mejoramiento continuo. El equipo es capaz de anticiparse a cualquier problema que se avecine, mejorando en forma continua y adaptndose a los cambios. Tiene como objetivo prevenir la ocurrencia de defectos y las

organizaciones analizan los defectos para determinar sus causas. A partir de la eficiencia de nuestro proceso es posible generar informes de costo / beneficio de nuevas tecnologas o proponer cambios al proceso estndar de la organizacin. Alcanzar el Nivel 5 no significa que la organizacin ya no tenga una meta superior a la cual aspirar. Es ms, si la organizacin no persiste en su mejoramiento continuo sta podra bajar a un nivel inferior de la escala de CMM.

2.4.1-2

Personal Software Process (PSP)

El Personal Software Process (PSP) es un proceso de software definido y medido diseado para ser usado por medio de un Ingeniero de Software individual. Tiene como objetivo guiar el planeamiento y desarrollo de los mdulos de software o pequeos programas; y es adaptable a otras tareas del personal. Es una tecnologa de SEI (Software EngineeringInstitute) que trae disciplina a las prcticas de los Ingenieros de Software, mejorando la calidad del producto, aumentando los costos y reduciendo el tiempo del ciclo de desarrollo del software. El PSP est basado en los principios de mejoramiento del proceso. CMM est enfocado respecto del mejoramiento de la capacidad organizacional. El enfoque de PSP es el Ingeniero individual. Para fomentar el mejoramiento a nivel personal, PSP ofrece la administracin y control del proceso al Ingeniero de Software. Con PSP los Ingenieros desarrollan software usando una propuesta estructurada y disciplinada. Los Ingenieros se ocupan de: seguir un 17

proceso definido, planificar, medir y seguir su trabajo, administrar la calidad del producto y aplicar aspectos cuantitativos para mejorar los procesos de trabajo personales.

2.4.1-3

Team Software Process (TSP)

El objetivo era suministrar un proceso operacional que ayude a los Ingenieros hacer trabajos de calidad. El principal motivador para el desarrollo de TSP fue la conviccin que los equipos de Ingenieros puedan hacer el trabajo de manera extraordinaria, pero solo si ellos son formados y entrenados. El objetivo del TSP es construir y guiar a los equipos. Los equipos son requeridos para la mayora de los proyectos de Ingeniera. El desarrollo de sistemas es una actividad en equipo, y la efectividad del equipo determina la calidad de la Ingeniera. En Ingeniera, los equipos de desarrollo tienen mltiples especialidades y todos los miembros trabajan en vista de un objetivo en comn. Los objetivos de TSP son: Ayudar a los equipos de Ingeniera de Software a elaborar productos de calidad dentro de los costos y tiempos establecidos. Tener equipos rpidos y confiables. Optimizar el performance del equipo durante todo el proyecto.

18

2.4.2

Modelos de Calidad del Software a Nivel Producto

2.4.2-1

Modelo de McCall

El modelo de McCall organiza los factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar la calidad de un producto. Cada punto de vista se descompone en una serie de factores que

determinan la calidad de cada una de ellos. Cada factor determinante de la calidad, se descompone, a su vez, en una serie de criterios o propiedades que determinan su calidad. Los criterios pueden ser evaluados mediante un conjunto de mtricas.

Operacin Del Producto Requiere que el software pueda ser entendido fcilmente, que opere eficientemente y que los resultados obtenidos sean los requeridos inicialmente por el usuario.

Revisin Del Producto Tiene como objetivo realizar revisiones durante el proceso de desarrollo para detectar los errores que afecten a la operacin del producto.

Transicin Del Producto Requiere de la definicin de estndares y procedimientos que sirvan como base para el desarrollo de software. 19

Visin del usuario

Factores McCall

de

Calidad

segn

Operacin del producto

Facilidad de Uso Integridad Correccin Eficiencia Confiabilidad -

Revisin del producto

Facilidad

de mantenimiento

Facilidad de prueba - Flexibilidad Transicin del producto Reusabilidad- Interoperabilidad Portabilidad

2.4.2-2

Modelo Boehm

El modelo de Boehm (1978) agrega algunas caractersticas a las existentes en el modelo de McCall y representa una estructura jerrquica de caractersticas, cada una de las cuales contribuye a la calidad total. Consiste en un modelo de descomposicin de caractersticas de calidad del software en 3 niveles (usos principales, componentes intermedios y componentes primitivos) previos a la aplicacin de mtricas. Este modelo plantea factores de calidad formados por criterios de calidad y mtricas respectivas. El modelo de Boehm tiene como finalidad que a travs de la calidad del software, el software: Realice lo que desea el usuario Utilice recursos informticos de manera correcta y eficiente Sea fcil de utilizar y aprender Sea bien diseado, codificado, probado y mantenido. Este modelo es similar al de McCall ya que presenta una jerarqua de caractersticas, est basado en un amplio rango de caractersticas e incorpora 19 criterios que incluyen caractersticas de performance del hardware.

20

Las mtricas directas e indirectas son usadas para determinar el nivel de acuerdo a un criterio en particular que afecta a los principales factores de calidad. Factores tales como portabilidad, confiabilidad, facilidad de mantenimiento y facilidad de modificacin son propiedades estticas. Cada factor es descompuesto en varios criterios. La facilidad de prueba y la eficiencia dependen del comportamiento de las interpretaciones especficas y constituyen propiedades dinmicas

2.4.2-3

Modelo FURPS

El modelo FURPS cuenta con 5 caractersticas de calidad del software: Funcionalidad Facilidad de uso Confiabilidad Performance Facilidad de soporte Adems plantea 2 categoras de requerimientos, las cuales son:

Requerimientos funcionales (F): especifican funciones que el sistema debe ser capaz de realizar, sin tomar restricciones fsicas a consideracin, y se definen a travs de las entradas y salidas esperadas. 21

Requerimientos no funcionales (URPS):Usability (Facilidad de uso), Reliability (Confiabilidad), Performance y Supportability (Facilidad de soporte). Describen atributos del sistema o atributos del ambiente del sistema.

3.

DEFINICIN DE VERIFICACIN Y VALIDACIN 3.1 VERIFICACIN DE SOFTWARE:

3.1.1

Definicin:

Por verificacin se entienden todas las actividades que son emprendidas para asegurar que el software cumple con sus objetivos. Verificar software es quizs ms difcil que verificar otros productos de ingeniera. Busca coherencia, la integridad y exactitud de los software y su documentacin de apoyo, ya que se est

desarrollando, y proporciona apoyo a una conclusin posterior de que el software se valida.

22

3.2

VALIDACIN DE SOFTWARE: 3.2.3 Definicin:

La validacin es un proceso que asegura que el software cumple las expectativas del cliente. Va ms all de comprobar si el sistema est acorde con su especificacin, para probar que el software hace lo que el usuario espera a diferencia de lo que se ha especificado. El software debera hacer lo que el cliente realmente pide. En la validacin tambin es una evaluacin del sistema o componentes slo que es en el transcurso o al final del proceso del desarrollo para determinar si cumple con lo especificado. 4. Objetivos de la prueba

Un buen prembulo, antes de establecer los objetivos de la prueba de software es recordar la afirmacin realizada por Dijkstra en los aos 70, en donde se plantea que el hecho de Realizar una prueba puede ser una forma muy efectiva de mostrar la presencia de defectos, pero no garantiza la ausencia de stos.1 La prueba de software se realiza con el propsito de encontrar algo que difiera a las especificaciones planteadas para el producto o bien, para detectar la presencia de situaciones que pudieran generar resultados inapropiados. 4.1 Objetivos El proceso de pruebas del Software tiene dos objetivos distintos: Para demostrar al desarrollador y al cliente que el software satisface sus requerimientos. Para el software a medida, esto significa que debera haber al menos una prueba para cada requerimiento de los documentos de requerimientos del sistema y del usuario. Para productos de software genricos, significa que debera haber pruebas para todas las caractersticas del sistema que se incorporaran en la entrega del producto.
1

Edsger W. Dijkstra, TheHumbleProgrammer, traducido de, Octubre 1972, Volumen 15, 864 p.

23

Algunos sistemas pueden tener una fase de pruebas de aceptacin explicita en la que el cliente comprueba formalmente que el sistema entregado cumple su especificacin

Para descubrir defectos en el software en que el comportamiento de este es incorrecto, no deseable o no cumple su especificacin. La prueba de defectos est relacionada con la eliminacin de todos los tipos de comportamientos del sistema no deseables, tales como cadas del sistema, interacciones no permitidas con otros sistemas, clculos incorrectos y corrupcin de datos.

Generalmente, por lo tanto el objetivo de las pruebas del software es convencer a los desarrolladores del sistema y a los clientes de que el software es lo suficientemente bueno para su uso operacional. La prueba es un proceso que intenta proporcionar confianza en el software. Una de las sorpresas con las que suelen encontrar los nuevos programadores es la enorme cantidad de tiempo y esfuerzo que requiere esta fase. Se estima que la mitad del esfuerzo de desarrollo de un programa (tanto en tiempo como en gastos) se va en esta fase. Si hablamos de programas que involucran vidas humanas (medicina, equipos nucleares, etc.) el costo de la fase de pruebas puede fcilmente superar el 80%. Pese a su enorme impacto en el coste de desarrollo, es una fase que muchos programadores an consideran clasificable como un arte y, por tanto, como difcilmente conceptualizable. Es muy difcil entrenar a los nuevos programadores, que aprendern mucho ms de su experiencia que de lo que les cuenten en los cursos de programacin.

24

4.2 LIMITACIONES DE LAS PRUEBAS DE SOFTWARE

Algunas de las limitaciones existentes a nivel de pruebas de software son:

No existe una recopilacin formal que especifique y describa los tipos de prueba que se deben aplicar a una pieza de software y se detalle la implementacin precisa de cada uno de ellos. Aunque

existen algunos documentos, en su mayora son de carcter muy acadmico y poco prctico. Por otro lado, y aunque ISO plantea en normas como la ISO/IEC91262 ciertos aspectos en los cuales el producto de software debe ser conforme, no es suficientemente especifico como para ligarlo con una prueba de software con pormenores de ejecucin, llevando esto a que a que dicho estndar por si solo sea poco prctico.

Las tcnicas de pruebas generalmente son subestimadas como tiles, en tanto que no se usan en la prctica para el diseo de casos de prueba formales. En general y en entornos productivos, las tcnicas utilizadas para la deteccin de errores son del tipo

suposicin de errores y en el mejor de los casos de tipo aleatorio el cual por sus caractersticas propias no es un mtodo que aporte mucho a la deteccin de errores en el producto de software; todo esto se une a que habitualmente cuando se construyen pruebas de software (casos de prueba) no se formaliza el uso de tcnicas especficas en tanto que no es considerado importante o no se cuenta con el conocimiento y entrenamiento suficiente para su uso.

Los desarrolladores, evaluadores, gerentes de calidad y compradores pueden seleccionar mtricas de ISO/IEC 9126-4 para definir los requisitos, la evaluacin de los productos de software, la medicin de aspectos de calidad y otros propsitos.

25

TMM (Testing Maturity Model)3 es un modelo de pruebas reciente y como tal poco maduro en su interior. TMM est basado en CMM pero este hecho no implica que se herede la experiencia y solides de CMM; por otra parte TMM no ha sido sometido a revisiones que generen diferentes versiones, ni puesto ampliamente en prctica en productos del mundo real, por lo cual las deficiencias y problemas del modelo pueden no haber sido detectadas ni corregidas. TMM es un modelo poco difundido en el mbito de software latinoamericano y pocas compaas a nivel global lo implementan o lo usan dentro de sus procesos de calidad. A pesar de todo, la iniciativa de TMM es bastante buena y debe ser sometida a la madurez que la industria y el tiempo le confieran.

Los estndares existentes que se refieren a pruebas de software y aseguramiento de la calidad del producto tanto en ISO como en la IEEE tienen un acceso muy restringido, siendo difcil lograr adquirir la documentacin relacionada. Adicionalmente, y basados en que dichos estndares en la mayora de los casos son muy especficos y aplicarlos sin difcil. un modelo de calidad y desarrollo es sumamente

Los estndares y modelos planteados en torno al aseguramiento de la calidad de los productos de software por su carcter de genricos son muy poco especficos a la hora de realizar implementaciones en entornos

universales y

describir la forma de

productivos reales; en la mayora de los casos la generalidad es una de sus principales caractersticas.

TMM (TestingMaturityModel) Modelo de Madurez de Prueba. TMM ha surgido como un complemento a CMM.Los objetivos de madurez del modelo son: planear y desarrollar las pruebas,controlar y monitorear, prevenir defectos, evaluar y controlar la calidad, medir y optimizar las pruebas; cada uno de estos objetivos se alcanza en los diferentes niveles de madurez y el modelo como tal provee las actividades que se deben realizar para obtener un proceso de pruebas metodolgico y adaptable.

26

Esto permite que su aplicacin en diversos ambientes sea posible, pero limita las prcticas a realizar puesto que deben ser diseadas en su detalle por la organizacin, lo cual en muchos casos exige un conocimiento experto y compaa aferrarse a asesoras externas que hacen a una una prctica con un conjunto de

particularidades que no siempre son las mejores.

Tomando en cuenta que una organizacin debe estar basada en un modelo de calidad que permita un tratamiento global de los adicionalmente deben existir un conjunto de

procesos, y que

estndares, reglas, prcticas y normativas extras no especificadas en el modelo aplicado a la misma, es importante comentar la

inexistencia casi total de una descripcin formal que encierre en conjunto un modelo de calidad, un modelo de pruebas, una metodologa y unas prcticas especficas en pruebas de software que sean concordantes entre si y entre las polticas generales de un modelo de calidad determinado; en cambio de ello toda la desagregada mediante modelos y estndares. mediana medida generar cierta claridad

informacin est

Aunque 4ISTQB logra en

acerca de un conjunto de actividades para el aseguramiento de la calidad del producto, por s solo no se puede considerar como se debe tener en

maduro y totalmente confiable, adicionalmente

cuenta, que cualquier modelo de pruebas, debe de una forma u otra acoplarse al sistema de produccin del producto de software lo cual en gran medida no es contemplado a cabalidad por dicho organismo. La ISTQB aunque en entornos acadmicos formales es poco reconocida, en la industria se constituye como un organismo realizar certificaciones a nivel de un conjunto de

internacional encargado de

pruebas de software teniendo como base

4

ISTQB (International Software TestingQualificationsBoard) :Ha construido el esquema ms conocido por los probadores de software de certificacin. Esquema que se ha convertido en el lder mundial en la certificacin de competencias en las pruebas de software.

27

metodologas y caractersticas particulares, que a pesar de basarse en estndares internacionales sigue siendo muy genrico y de cierto modo descontextualizado de la realidad organizacional en la industria del software.

La implementacin de prcticas como verificacin,

validacin y en

aseguramiento de la calidad contempladas en CMMI y

normativas especficas de la IEEE y la implantacin de modelos como TMM especficos de pruebas de software, suele ser

sumamente difcil de implantar debido a que requiere gran inversin por parte de las organizaciones en recursos como: personal

capacitado, conocimiento y orientacin experta, esfuerzo adicional, tiempo, dinero, compromiso organizacional, entre otras. Lo ms

comn es tener modelos de calidad y de mejoramiento continuo como ISO 9000 y CMMI con el fin de que la aplicacin de estndares de aseguramiento de calidad exigentes como los mencionados tengan elementos suficientes como para procesos organizacionales sea exitosa. La razn por la cual la industria no adopta metodologas y estndares es la dificultad de la utilizacin de estos para pruebas de software. En las pequeas y medianas empresas la dificultad radica en la necesidad que estas tienen de competir mediante tiempos y precios y dada la poca practicidad que los estndares tienen asociados se incurre en consumos de recursos poco tolerables; por otra parte las grandes compaas adems de los factores anteriores, compiten mediante calidad y para lograr un buen indicador deben implementar los diferentes metodologas y estndares que que su adhesin a los

garanticen la madurez de los procesos, para estas compaas la falta de practicidad de los estndares en ms un requisito de sus clientes que un riesgo asociado al uso de recursos.

28

Implementar un proceso de pruebas al interior de una compaa es costoso, adems el proceso debe madurar para que se adapte a las necesidades especficas de la organizacin; este hecho obliga a muchas empresas a subcontratar los procesos de pruebas. En ocasiones esta es una buena opcin puesto que evita posibles

sesgos en las pruebas pero en general puede conllevar serios problemas al interior de la organizacin que van desde la

confidencialidad de la informacin hasta el incremento de los tiempos de desarrollo. Las pruebas de software ms complejas basan su diseo y su ejecucin en los artefactos desarrollados en etapas de anlisis y diseo; si estos artefactos no son construidos o tienen deficiencias como falta de consistencia y coherencia; aparte de afectar todo el proceso de desarrollo se ver comprometido el aseguramiento de la calidad y dentro de ste las pruebas, los tipos de pruebas de software que buscan hallar defectos ms profundos. La buena ingeniera de software se convierte en una necesidad bsica para el correcto desarrollo de las pruebas de software. Los testers desconocen el dominio o los tipos y tcnicas a utilizar cuando se requieren pruebas de alto nivel, en general este problema se da al tener personal poco capacitado para la labor. Los proveedores de pruebas generalmente posponen la labor de pruebas a las etapas finales del ciclo de vida del software, lo que ocasiona problemas por retrasos. Estos retrasos se dan

generalmente por que el equipo de pruebas debe adquirir el conocimiento del dominio necesario y disear las pruebas, tareas que se pueden realizar de forma transversal al proceso de desarrollo optimizando los recursos disponibles. En ocasiones los testers no cuentan con los insumos necesarios para realizar un proceso de pruebas maduro y completo.

29

Estos insumos corresponden a una buena documentacin y a un completo y correcto levantamiento de requisitos, que orienten al probador, tanto en la ejecucin y desarrollo de las pruebas como en el aprendizaje del dominio.

5.

PLANIFICACION Y CONTROL DE PRUEBAS

Durante la planificacin se deben seleccionar los participantes, asignarles roles, preparar un calendario para la reunin y distribuir el material a probar. Los papeles que existen en una inspeccin son: Organizador.- El organizador planifica las actividades de prueba en un proyecto. Moderador.- El moderador debe garantizar que se sigan los procedimientos de la prueba as como que los miembros del equipo cumplan sus responsabilidades.Adems, modera las reuniones, lo que significa que el xito de la reunin depende de esta persona y, por tanto, debe actuar como lder. Testers.- Son los responsables de detectar defectos en el producto software bajo prueba. Habitualmente, todos los participantes en una prueba actan tambin como testers, independientemente de que, adems, jueguen algn otro papel. Lector/Presentador.- Durante la reunin para la inspeccin en grupo, el lector dirigir al equipo a travs del material de modo completo y lgico. El material debe ser parafraseado significa que el lector debe explicar e interpretar el producto en lugar de leerlo literalmente. Autor.- El autor es la persona que ha desarrollado el producto que se est probando y es el responsable de la correccin de los defectos durante la fase de correccin. Durante la reunin, el autor contesta a las preguntas que el lector no es capaz de responder. El autor no debe actuar al mismo tiempo ni de moderador, ni de lector, ni de escriba.

30

Escriba.- El secretario o escriba es responsable de incorporar todos los defectos en una lista de defectos durante la reunin. Recolector.- El recolector recoge los defectos encontrados por los testers en caso de no haber una reunin de prueba.

Un equipo de testing nunca debera contar con ms de cinco miembros. Por otro lado, el nmero mnimo de participantes son dos: el autor (que acta tambin de tester) y un tester. Lo recomendable es comenzar con un equipo de tres o cuatro personas: el autor, uno o dos testers y el moderador (que acta tambin como lector y escriba). Tras unas cuantas inspecciones la organizacin puede experimentar incorporando un inspector ms al grupo y evaluar si resulta rentable en trminos de defectos encontrados.

Si se tiene en cuenta que la prueba de un gran sistema podra implicar la escritura, ejecucin y verificacin de decenas de miles de casos de prueba, el manejo de miles de mdulos, la reparacin de miles de errores, y que emplea a cientos de personas durante un lapso de un ao o ms, es evidente que usted se enfrenta con un desafo de gestin de proyectos inmensa en la planificacin, seguimiento y control del proceso de pruebas. El problema es tan enorme que se podra dedicar un libro entero slo a la gestin de pruebas de software.

El principal error en la planificacin de un proceso de prueba es la suposicin tcita de que no hay errores que sern encontrados. El resultado evidente de este error es que los recursos previstos (personas, tiempo transcurrido y el tiempo de ordenador) ser muchsimo mayor. Para agravar el problema surge el hecho de que el proceso de prueba cae al final del ciclo de desarrollo, lo que significa que los cambios de recursos son difciles. Un segundo problema, quizs ms significativo es que la definicin errnea de la prueba se est utilizando, ya que es difcil ver cmo alguien que usa la definicin correcta de la prueba (el objetivo es encontrar los errores) se planea una prueba con el supuesto de que no hay errores que encontrar. 31

Como es el caso de la mayora de las empresas, el plan es la parte crucial de la gestin del proceso de pruebas. Los componentes de un buen plan de prueba son los siguientes: Objetivos. Los objetivos de cada fase de pruebas deben ser definidos. Criterios. Los criterios deben ser diseados para especificar que cada fase de pruebas ser juzgada para ser completa. Programa. Los planes de calendario de tiempo son necesarios para cada fase. Se debe indicar que los casos de prueba sern diseados, escritos y ejecutados. Algunas metodologas de software tales como Extreme Programming requieren que el diseo de los casos de prueba y pruebas unitarias de codificacin se inicien antes de la aplicacin. Responsabilidades. Para cada fase, las personas que van a disear, escribir, ejecutar, y verificar los casos de prueba, y la gente que repara los errores descubiertos, deben ser identificados. Dado que en los grandes proyectos pueden surgir disputas en torno a si los resultados de pruebas particulares representan los errores, el rbitro debe ser identificado. Libreras de casos de prueba y normas. En un proyecto grande, se deben identificar mtodos sistemticos, es necesario escribir y almacenar los casos de prueba. Herramientas. Las herramientas de prueba requeridas deben ser

identificadas, incluyendo un plan para que desarrollar o adquirir, cmo se van a utilizar, y cuando se necesitan. Tiempo de Ordenador. Este es un plan para la cantidad de tiempo necesaria para cada ordenador por fase de prueba. Esto incluye servidores que se utilizan para aplicaciones de compilacin, si fuera necesario, las mquinas de escritorio necesarias para las pruebas de instalacin, los servidores Web para aplicaciones basadas en Web, los dispositivos conectados en red, si fuera necesario. Configuracin del hardware. Si son necesarias las configuraciones de hardware o dispositivos especiales, se requiere un plan en que se describan los requisitos, cmo se van a cumplir, y cuando se necesitan. 32

Integracin. Es parte del plan de pruebas, es una definicin de cmo se ensamblan los componentes del sistema. Un sistema que contiene los principales subsistemas o programas puede ser reconstruido de forma incremental, utilizando el enfoque de arriba hacia abajo o de abajo hacia arriba, pero solo en donde los bloques de construccin son los programas o subsistemas. Si este es el caso, un plan de integracin de sistemas es necesario. El plan de integracin del sistema define el orden de integracin, la capacidad funcional de cada versin del sistema, y las responsabilidades para la produccin de "andamiaje", cdigo que simula el funcionamiento de los componentes que no existen.

Seguimiento de los procedimientos. Los medios deben ser identificados para realizar un seguimiento de diversos aspectos del progreso de las pruebas, incluyendo la ubicacin de los mdulos susceptibles de error y estimacin de sus progresos con respecto a la programacin, los recursos y los criterios de terminacin.

Depuracin de procedimientos. Los mecanismos deben ser definidos para informar de los errores detectados, el seguimiento del progreso de las correcciones, y la adicin de las correcciones al sistema. Los horarios, responsabilidades, herramientas y equipo de tiempo / recursos tambin debe ser parte del plan de depuracin.

Pruebas de regresin. Las pruebas de regresin se lleva a cabo despus de realizar una mejora funcional o reparacin para el programa. Su propsito es determinar si el cambio ha retrocedido otros aspectos del programa. Por lo general, se lleva a cabo al volver a ejecutar un subconjunto de casos de prueba del programa. Las pruebas de regresin son importantes porque los cambios y correcciones de errores tienden a mostrarse mucho ms que en el cdigo del programa original (en la misma forma que los errores tipogrficos en la mayora de los peridicos son el resultado de los ltimos cambios en la redaccin al minuto, en lugar de cambios en la copia original).

33

6.

Mtricas y mediciones del software 6.1 Medida del software: se refiere a derivar un valor numrico desde algn atributo del software o del proceso, comparando estos valores entre s y con los estndares aplicados en la organizacin, es posible sacar conclusiones de la calidad del software o de los procesos para desarrollo. Las mediciones del software pueden utilizarse para: Hacer predicciones generales acerca del sistema. Haciendo mediciones de las caractersticas de los componentes del sistema y reuniendo estas, podremos derivar una estimacin general de algunos atributos del sistema, como el nmero de fallos. Identificar componentes anmalos. Mediante las mediciones

podemos identificar componentes que se salgan de lo normal. Por ejemplo, podemos medir los componentes para identificar los de complejidad ms alta, los cuales suponemos que sern los que tengan ms errores, para centrarnos en ellos en el proceso de revisin. 6.2 Mtrica del software: es cualquier tipo de medida relacionada con un sistema, proceso o documentacin de software. Algunos ejemplos son las medidas que se utilizan para calcular el tamao de un producto en lneas de cdigo; el nmero de fallos encontrados en un producto software entregado; y el nmero de personas/da requeridas para desarrollar un componente del sistema.

6.3 Tipos de Mtricas: Mtricas de prediccin. Se asocian con los productos del software, como por ejemplo la complejidad ciclomtica de un mdulo, la longitud promedio de los indicadores en un programa y el nmero de atributos y operaciones asociados con los objetos de un diseo. 34

 Mtricas de control. Se asocian con los procesos del software, como por ejemplo el esfuerzo y el tiempo promedio requerido para reparar los defectos reportados.

6.4 Clasificacin de las Mtricas de software

6.4.1

Mtricas de Control 6.4.1-1 Segn los criterios:

Mtricas de complejidad: son todas las mtricas de software que definen de una u otra forma la medicin de la complejidad; tales como volumen, tamao, anidaciones, costo (estimacin), agregacin, configuracin y flujo. Estas son los puntos crticos de la concepcin, viabilidad, anlisis y diseo de software. Mtricas de calidad: son todas las mtricas de software que definen de una u otra forma la calidad del software; tales como exactitud, estructuracin o modularidad, pruebas, mantenimiento, reusabilidad, cohesin del mdulo, acoplamiento del mdulo, etc. Estas son los puntos crticos en el diseo, codificacin, pruebas y mantenimiento. Mtricas de competencia: son todas las mtricas que intentan valorar o medir las actividades de productividad de los

programadores o practicantes con respecto a su certeza, rapidez, eficiencia y competencia. No se ha alcanzado mucho en esta rea, a pesar de la intensa investigacin acadmica. Mtricas de desempeo: corresponden a las mtricas que miden la conducta de mdulos y sistemas de un software, bajo la supervisin del sistema operativo o hardware. Generalmente tienen que ver con la eficiencia de ejecucin, tiempo, almacenamiento, complejidad de algoritmos computacionales, etc.

35

 Mtricas estilizadas: son las mtricas de experimentacin y de preferencia; por ejemplo: estilo de cdigo, las convenciones denominando de datos, las limitaciones, etc. Pero estas no se deben confundir con las mtricas de calidad o complejidad. 6.4.1-2 Segn el contexto en que se utilizan:

Mtricas de proceso: se recopilan de todos los proyectos y durante un largo periodo de tiempo. Son caracterizadas por el control y ejecucin del proyecto y la medicin de tiempos de las fases. Mtricas de proyecto: permiten evaluar el estado del proyecto. Permiten seguir la pista de los riesgos. Mtricas de producto: se centran en las caractersticas del software y no en cmo fue producido. Tambin son productos los artefactos, documentos, modelos y componentes que conforman el software. Se miden cosas como el tamao la calidad, la totalidad, la volatilidad y el esfuerzo. Mtricas de Calidad El principal objetivo de los que desarrollan software es producir sistemas, aplicaciones o productos de alta calidad. Para las evaluaciones que se quieran obtener en necesario la utilizacin de medidas tcnicas, que evalan la calidad de manera objetiva.

36

6.5 Modelos conocidos

6.5.1

Modelo McCall Describe la calidad como un concepto elaborado mediante relaciones jerrquicas entre factores de calidad, en base a criterios. Los factores de calidad se concentran en tres aspectos importantes de un producto de software: caractersticas operativas, capacidad de cambios y adaptabilidad a nuevos entornos. Las mtricas desarrolladas estn relacionadas con los factores de calidad y la relacin que se establece se mide en funcin del grado de cumplimiento de los criterios.

Criterios asociados a los factores de calidad 6.5.2 Modelo DROMEY Resalta el hecho de que la calidad del producto es altamente determinada por los componentes del mismo (incluyendo requerimientos, guas de usuarios, diseos y cdigo). Sugiere el uso de cuatro factores que implican propiedades de calidad, que son: correctitud, internas, contextuales y

descriptivas. 37

Criterios asociados a los factores de calidad 6.5.3 Modelo FURPS Modelo desarrollado por HP en 1987, desarrollando un conjunto de factores de calidad de software y sus respectivos atributos. Funcionalidad confiabilidad (Functionality), (Reliability), usabilidad (Usability), y

desempeo

(Performance)

capacidad de soporte (Supportability). Se utilizan para establecer mtricas de la calidad para todas las actividades del proceso de desarrollo de un software inclusive de un sistema de informacin.

38

6.5.4

Modelo MOSCA

Consta de 4 niveles: dimensiones, categoras, caractersticas y las mtricas. En base de tres ramas: el producto, el proceso y la humana. Contiene un total de 715 mtricas.

39

6.6

Mtricas de prediccin: frecuentemente, es imposible medir los

atributos de calidad del software directamente. Los atributos de calidad como la mantenibilidad, la comprensin y la usabilidad son atributos externos que nos dicen cmo ven el software los desarrolladores y los usuarios. Estos se ven afectador por diversos factores y no existe un camino simple para medirlos. Ms bien es necesario medir atributos internos (como su tamao) y suponer que existe una relacin clara y vlida ente los atributos internos y externos del software. La figura muestra algunos atributos externos de la calidad que nos sern interesantes y los atributos internos relativos a ellos, pero no dice qu relacin es. Para que la medida del atributo interno sea un indicador til de la caracterstica externa, se deben cumplir tres condiciones: 1. El atributo debe medirse de forma precisa 2. Debe existir una relacin entre lo que se puede medir y el atributo de comportamiento externo. 3. Esta relacin se comprende, ha sido validad y se puede expresar en trminos de una frmula o modelo.

40

La formulacin del modelo comprende identificar la forma funcional del modelo (lineal, exponencial, etc.) a travs del anlisis de los datos recogidos, identificar los parmetros que se van a incluir en el modelo y calibrarlos utilizando datos existentes. El desarrollo del modelo, si se confa en l, requiere que se tenga experiencia en tcnicas estadsticas e, idealmente alguien con experiencia y conocimientos debe definir el modelo Ejemplo:

Una organizacin lleva a cabo un proyecto de desarrollo de un software X.

El responsable del proyecto necesita saber si la productividad es adecuada.

Conocer el nivel de productividad de los programadores del proyecto en comparacin con lo habitual en otros proyectos de la organizacin.

Las mtricas a utilizar para este caso podran ser:

Directas
LCF: lneas de cdifo fuente escritas

Indirectas
HPT: horas- programador totales. LCFH: lneas de cdigo fuente por hora de programador.

Indicadores

HPD: horas - programador diarias.

CTP: coste total actual del proyecto, en unidades monetarias. CLCF: coste por lnea de cdigo fuente.

PROD: productividad de los programadores.

CHP: coste por hora programador, en unidades monetarias.

41

7. V & V en el proceso de desarrollo de software 7.1 Definicin de V&V Sommerville Verificacin Busca comprobar que el sistema cumple con los

requerimientos especificados (funcionales y no funcionales). El software est de acuerdo a su especificacin? Validacin Busca comprobar que el software hace lo que el usuario espera. El Software cumple las expectativas del cliente? IEEE 1012 2004[IEEE, 2004] Verificacin El proceso de evaluar un sistema o componente para determinar si los productos de una fase de desarrollo determinada satisfacen las condiciones impuestas al inicio de la etapa. Validacin El proceso de evaluar un sistema o componente durante o al final del proceso de desarrollo para determinar si satisface los requerimientos especificados.

7.2 Concepto: V& V es un conjunto de procedimientos, actividades, tcnicas y herramientas que se utilizan paralelamente al desarrollo de software, para asegurar que un producto software resuelva el problema inicialmente planteado. V&V comienza con revisiones de los requerimientos y contina con revisiones del diseo e inspecciones de cdigo hasta la prueba del producto.

42

7.3 Principio: actuar sobre los productos intermedios que se generan durante el desarrollo para detectar y corregir cuanto antes sus defectos y las desviaciones respecto al objetivo fijado. 7.4 Objetivos: Detectar y corregir los defectos tan pronto como sea posible en el ciclo de vida del software. Disminuir los riesgos, las desviaciones sobre los presupuestos y sobre el calendario o programa de tiempos del proyecto. Mejorar la calidad y fiabilidad del software Mejorar la visibilidad de la gestin del proceso de desarrollo Valorar rpidamente los cambios propuestos y sus consecuencias

7.5 Actividades de V&V: Verificacin Estamos construyendo correctamente el producto? El software debe ser conforme a su especificacin Tcnica ms utilizada: Inspecciones de SW Objetivo: demostrar la consistencia, complecin y correccin de los artefactos software entre las fases del ciclo de desarrollo de un proyecto. Validacin Estamos construyendo el producto correcto? El software debe hacer lo que el usuario realmente quiere Tcnica ms utilizada: Pruebas SW Objetivo: determinar la correccin del producto final respecto a las necesidades del usuario

43

7.6 V&V dinmica y esttica: V&V dinmica: se refiere al ejercicio y observacin del

comportamiento del producto (prueba) V&V esttica: se refiere al anlisis de las representacin estticas (documentos, diagramas, cdigo fuente) del sistema para descubrir problemas (inspecciones)

Inspecciones de Software

Especificaciones de requerimientos

Diseo de alto nivel

Especificaci n formal

Diseo detallado

Programa

Prototipo

Prueba de programas

Verificacin y validacin esttica y dinmica 7.7 Tcnicas de V&V: Tcnicas Estticas: tienen que ver con el anlisis y control de las representaciones del sistema, es decir de los diferentes modelos construidos durante el proceso de desarrollo de software tales como documentos de requerimientos, diagramas de anlisis y diseo y cdigo fuente.

44

Tcnicas Dinmicas: tambin conocidas como testing (prueba) se basan en ejercitar una implementacin. Por lo tanto, solo pueden ser aplicadas si existe una versin operativa o ejecutable del producto

Tcnicas estticas de V&V: Revisiones de Software (esttica): el objetivo fundamental de esta tcnica es detectar y registrar los defectos de un producto intermedio o entregable.

Consiste en: Verificar si el producto satisface sus especificaciones o atributos de calidad Verificar si el producto se ajusta a los estndares utilizados en la empresa Sealar desviaciones sobre los estndares y las

especificaciones Recopilar datos que realimenten inspecciones posteriores (defectos recogidos, esfuerzo empleado, etc.) y ayudar a su utilizacin prctica No pretende analizar alternativas o aspectos de estilo Las revisiones de software pueden ser: Informales: no hay procedimientos definidos por lo que la revisin se realiza de la forma ms rpida y flexible. Semi formales: se definen unos procedimientos mnimos a seguir (walkthroughs) Formales (inspecciones): se define completamente el proceso, los participantes y sus funciones, los documentos, etc.

45

Inspecciones de Software Las inspecciones de software son un proceso de V&V esttico en el que un sistema software se revisa para encontrar errores, omisiones y anomalas. Generalmente, las inspecciones se centran en el cdigo fuente, pero puede inspeccionarse cualquier representacin legible del software como los requerimientos o un modelo de diseo. Cuando se inspecciona un sistema, se utiliza conocimiento del sistema, su dominio de aplicacin y el lenguaje de programacin o modelo de diseo para descubrir errores. Existen tres ventajas fundamentales de la inspeccin sobre las pruebas: 1. Durante las pruebas, los errores pueden enmascarar (ocultar) errores. Cuando se descubre un error, nunca se puede estar seguro de si otras anomalas de salida con debidas a un nuevo error o son efectos laterales del error original. 2. Pueden inspeccionarse versiones incompletas de un sistema sin costes adicionales. Si un programa est incompleto, entonces se necesita desarrollar software de soporte especializado para las pruebas a fin de probar aquellas partes que estn disponibles. 3. Adems de buscar los defectos en el programa, una inspeccin tambin puede considerar atributos de calidad ms amplios de un programa tales como grado de cumplimiento con los estndares, portabilidad y mantenibilidad.

Proceso de Inspeccin de programas La inspeccin de programas es un proceso formal realizado por un equipo de al menos cuatro personas. Los miembros del equipo analizan sistemticamente el cdigo y sealan posibles defectos.

46

ROL

Descripcin El programador o diseador responsable de generar el programa o

Autor o propietario

documento. Responsable de reparar los defectos descubiertos durante el proceso de inspeccin. Encuentra errores, omisiones e inconsistencias en los programas y

Inspector

documentos. Tambin puede identificar cuestiones ms generales que estn fuera del mbito del equipo de inspeccin.

Lector Secretario Presidente moderador Moderador jefe

Presenta el cdigo o documento en una reunin de inspeccin. Registra los resultados de la reunin de inspeccin. o Gestiona el proceso y facilita la inspeccin. Realiza un informe de los resultados del proceso para el moderador jefe. Responsable de las mejoras del proceso de inspeccin, actualizacin de las listas de comprobacin, estndares de desarrollo, etc.

Roles en el proceso de Inspeccin Tcnicas dinmicas de V&V: Prueba de programas (dinmica): el uso de esta tcnica puede revelar la presencia de errores, no su ausencia. Los defectos se descubren examinando las salidas y buscando las anomalas. Debe ser usada en conjunto con la verificacin esttica. Tipos de pruebas Pruebas de validacin Intentan demostrar que el software es el que el cliente quiere (que satisface sus requerimientos).

Prueba de defectos Pruebas diseadas para descubrir defectos en el sistema. Una prueba de defectos exitosa es aquella que revela la presencia de defectos en el sistema.

47

Prueba y depuracin La prueba de defectos y la depuracin son procesos distintos: La prueba de defectos se refiere a la confirmacin de la presencia de errores. La depuracin se refiere a la localizacin y reparacin de estos errores. La depuracin involucra la formulacin de una hiptesis acerca del comportamiento del programa y la prueba de la hiptesis para encontrar los errores en el sistema. No existe un mtodo sencillo para la depuracin de programas. Los depuradores habilidosos buscan patrones en las salidas de las pruebas en donde se ponen de manifiesto los defectos y utilizan su conocimiento sobre el tipo de defecto, el patrn de salida, el lenguaje de programacin y el proceso de programacin para localizar el defecto. Durante el proceso de depuracin, puede utilizarse el conocimiento de errores comunes de programacin (como olvidar incrementar un contador) y hacer corresponder stos con los patrones observados. Tambin deberan buscarse errores caractersticos de los lenguajes de programacin, tales como errores de direccionamiento de punteros en C.

Resultados de Pruebas

Especificacin

Casos de Prueba

Localizar error

Disear reparacin de errores El proceso de Depuracin

Reparar errores

Probar nuevamente el programa

48

Planificacin de la V&V La verificacin y validacin es un proceso caro. Para algunos sistemas, tales como los sistemas de tiempo real con restricciones no funcionales complejas, ms de la mitad del presupuesto para el desarrollo del sistema puede invertirse en V&V. es necesaria una planificacin cuidadosa para obtener el mximo provecho de las inspecciones y pruebas y controlar los costes del proceso de verificacin y validacin. Consiste en: Describir las fases principales del proceso de pruebas Necesaria para obtener el mximo provecho de los costos disponibles para V&V Estimar la planificacin general y la asignacin de recursos Debe realizarse en etapas tempranas del proceso de desarrollo del software Debe equilibrar V&V estticas y dinmicas Utilizar estndares y procedimientos
Servicio Especificacin de requerimientos Plan de pruebas de aceptacin Especificacin del sistema Plan de pruebas de integracin del sistema

Prueba de Aceptacin

Prueba de Integracin del Sistema

Diseo del sistema

Prueba de integracin de los subsistemas

Plan de pruebas de integracin de los subsistemas

Diseo detallado

49
Cdigo y prueba de los mdulos y unidades

El grfico muestra que los planes de prueba deberan derivarse a partir de la especificacin y diseo del sistema. Este modelo tambin divide la V&V del sistema en varias etapas. Cada etapa est conducida por las pruebas que tienen que definirse para comprobar la conformidad del programa con su diseo y especificacin. Como parte del proceso de planificacin de V&V, habra que decidir un equilibrio entre las aproximaciones estticas y dinmicas de la verificacin y validacin, y pensar en estndares y procedimientos para las inspecciones y pruebas del software, establecer listas de comprobacin para conducir las inspecciones de programas y definir el plan de pruebas del software. El relativo esfuerzo destinado a las inspecciones y las pruebas depende del tipo de sistema a desarrollar y de los expertos de la organizacin en la inspeccin de programas. Como regla general, cuanto ms crtico sea el sistema, debera dedicarse ms esfuerzo a las tcnicas de verificacin estticas. La planificacin de las pruebas est relacionada con el establecimiento de estndares para el proceso de las pruebas, no slo con la descripcin de los productos de las pruebas. Los planes de pruebas, adems de ayudar a los gestores a asignar recursos y estimar el calendario de las pruebas, son de utilidad para los ingenieros del software implicados en el diseo y la realizacin de las pruebas del sistema.

50

CONCLUSIONES

La Ingeniera del Software abarca un amplio conjunto de temas, entre los cuales se encuentra Modelos de Calidad del Software, los cuales permiten que las empresas puedan implementar la calidad a nivel de procesosy productos. Cada Modelo tiene una aplicacin concreta, la cual contribuye a lograr mejor los objetivos.

Teniendo en cuenta los objetivos de la empresa, se puede pensar en poder aplicar y/o integrar modelos o estndares. Debido a la existencia de un nmero determinado de Modelos de Calidad de Software, se debe determinar qu Modelo utilizar segn los objetivos que se pretendan alcanzar.

Los diferentes requerimientos de software como pueden ser desarrollo y mantenimiento de software permitirn la aplicacin de un Modelo de Calidad de Software; y el uso de herramientas y tcnicas de calidad, normas o estndares asociadas al software que ayudan al cumplimiento de los requerimientos.

De la mayora de los requerimientos, se obtiene un software que podr ser evaluado segn las Pruebas de Software. Esta evaluacin puede generar cambios y/o modificaciones en el desarrollo del software. Tambin, se puede lograr una certificacin que permita mejorar la posicin competitiva de la empresa. Generalmente, por lo tanto el objetivo de las pruebas del software es convencer a los desarrolladores del sistema y a los clientes de que el software es lo suficientemente bueno para su uso operacional. La prueba es un proceso que intenta proporcionar confianza en el software.

51

BIBLIOGRAFIA http://www.eqsoft.net/presentas/modelos_de_calidad_y_software_libre.pdf http://iidia.com.ar/rgm/tesistas/scalone-tesis-maestria-ingenieria-en-calidad.pdf http://www.slideshare.net/zcfranco/modelo-de-calidad-de-desarrollo-de-software http://www.slideshare.net/miguelangelquintero/iso-1948470 http://www.usabilitynet.org/tools/r_international.htm#9126-1 [PRE98] Pressman, R. Ingeniera del software. Un enfoque prctico. Cuarta Edicin. McGraw-Hill/Interamericana de Espaa. 1998. Captulo 13 [MYE79] Glenford J. Myers. The art of software testing.SegundaEdicion. 1979. Chapter 2: The Psychology and Economics of Program Testing, 20 p.Chapters 6: Higher-Order Testing. 105 106 p. http://www.slideshare.net/mstabare/introduccin-de-pruebas-de-software http://issuu.com/ojo_critico/docs/procesotesting TESIS: PROPUESTA METODOLGICA PARA LA REALIZACIN DE PRUEBAS DE SOFTWARE EN UN AMBIENTES PRODUCTIVOS http://www.bdigital.unal.edu.co/930/1/8357252_2009.pdf http://www.tmmifoundation.org/ http://www.iso.org/ Iansommerville - ingeniera de software - sptima edicin. captulo 23. 492 493 p.

52