Material monster is ii emco

UNIVERSIDAD DE LAS FUERZAS ARMADAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN

CARRERA DE INGENIERÍA EN SISTEMAS E INFORMÁTICA

Ing. Mauricio Campaña Ortega MsC. CCNA. CCIA.

INGENIERÍA DE SOFTWARE II

CALIDAD DEL SOFTWARE La integridad de un producto de software depende

de la acción combinada de tres tipos de disciplinas:

Desarrollo

Gestión

Control

Dentro de las disciplinas de control se encuentra la Garantía de Calidad del Software, cuyo objetivo es asegurar un cierto nivel de calidad en el producto de software desarrollado.

OBJETIVOS Al finalizar esta unidad estará en capacidad de:

Comprender el significado de la terminología utilizada.

Ser capaz de caracterizar la calidad de un producto de software en

términos de un modelo de calidad.

Comprender en que consiste la Garantía de Calidad en un proyecto

de desarrollo de software.

Conocer las consideraciones que se debe tener en cuenta a la hora

de construir un Sistema de Garantía de Calidad.

Ser capaz de participar en una revisión o auditoría.

Ser consciente de las medidas que puede tomar para construir

productos de mayor calidad.

Conocer los principales métodos de evaluación del proceso de

desarrollo de software.

Conocer los principales modelos para la mejora del proceso de

desarrollo de software.

CALIDAD DE PROCESO

CALIDAD DE PROCESO

Conjunto de actividades, métodos, prácticas y transformaciones que la gente usa para desarrollar y mantener software y los productos de trabajo asociados (planes de proyecto, diseño de documentos, código, pruebas y manuales de usuario)”

“Proceso o conjunto de procesos usados por una organización o proyecto, para planificar, gestionar, ejecutar, monitorizar, controlar y mejorar sus actividades software relacionadas”

CALIDAD DEL PRODUCTO DE SOFTWARE

La calidad del producto de software se diferencia de la calidad de otros productos de fabricación industrial, ya que el software tiene ciertas características especiales:

El software es un producto mental, no restringido por las leyes de la física o por los límites de los proceso de fabricación. Es algo abstracto y su calidad también lo es.

Se desarrolla, no se fabrica. El coste esta fundamentalmente en el proceso de diseño, no en la producción. Y los errores se introducen también en el diseño no en la producción.

El software no se deteriora con el tiempo. No es susceptible a los efectos del entorno, y su curva de fallos es muy diferente de la del hardware. Todos los problemas que surjan durante el mantenimiento estaban allí desde el principio y afectan a todas las copias del mismo; no se generan nuevos errores.

Es artesanal en gran medida. El software en su mayoría se construye a medida, en vez de ser construido ensamblando componentes existentes y ya probados, lo que dificulta aún más el control de su calidad. Aunque se ha escrito mucho sobre reutilización de software, hasta ahora se han conseguido pocos éxitos tangibles.

CALIDAD DEL PRODUCTO DE SOFTWARE

El mantenimiento del software es mucho más complejo que el

mantenimiento del hardware. Cuando un componente de hardware se

deteriora se sustituye por una pieza de repuesto, pero cada fallo en el

software implica un error en el diseño o en el proceso mediante el cual

se tradujo el diseño en código máquina ejecutable.

Es engañosamente fácil realizar cambios sobre un producto software,

pero los efectos de estos cambios se pueden propagar de forma

explosiva e incontrolada.

Como disciplina, el desarrollo de software es aún muy joven, por lo que

las técnicas de las que se disponen aún no son totalmente efectivas o no

están totalmente calibradas.

El software con errores no se rechaza. Se asume que es inevitable que el

software presenta errores.

PROBLEMAS DE LA CALIDAD DEL PRODUCTO DE SOFTWARE

Los principales problemas a los que se enfrenta al hablar de la calidad del

producto de software son:

La definición misma de la calidad del software: ¿Es realmente posible

encontrar un conjunto de propiedades en un producto software que de

una indicación de calidad? Para dar respuesta a esta pregunta aparecen

los Modelos de Calidad.

Modelos de Calidad: La calidad de define de forma jerárquica. Resuelven la

complejidad mediante la descomposición. La calidad es un concepto que se deriva

de un conjunto de subconceptos.

La comprobación de la calidad del software: ¿Cómo medir el grado de

calidad de un producto de software? Aparece el concepto de Control de

Calidad.

Control de Calidad: Actividades para evaluar la calidad de los productos

desarrollados.

PROBLEMAS DE LA CALIDAD DEL PRODUCTO DE SOFTWARE

La mejora de la Calidad del Software: Cómo utilizar la información

disponible acerca de la calidad del producto de software para mejorar

su calidad a lo largo del ciclo de vida? No solo es posible “medir” la

calidad, sino también “construir” la calidad durante el proceso de

desarrollo del producto. Aparecen dos conceptos importantes:

Gestión de Calidad: Determinación y Aplicación de las políticas de

calidad de la empresa (objetivos y directrices generales)

Garantía o Aseguramiento de Calidad: Conjunto de Actividades

planificadas y sistemáticas necesaria para proporcionar confianza en

que el producto software satisfacerla los requisitos dados de calidad.

DEFINICIÓN DE CALIDAD

Calidad es “Conformidad con los requisitos y confianza en el funcionamiento” Deming.

“Adecuación para su uso”. Jurán

“Hacerlo bien a la primera” o sea poner más énfasis en la prevención. Crosby

Definiciones de calidad extraídos de estándares internacionales

“La calidad es la suma de todos aspectos o características de un producto o servicio que influye en su capacidad para satisfacer las necesidades, expresadas o implícitas”. ISO 8402.

“Grado con el cual el cliente o usuario percibe que el software satisface sus expectativas”. IEE 729-83.

“Capacidad del producto software para satisfacer los requisitos establecidos”. DoD 2168.

DEFINICIÓN DE CALIDAD

La calidad es algo relativo, depende de los requisitos o necesidades que

se desea satisfacer.

En un producto de software se tendrán tres visiones de la calidad:

Necesaria o requerida: La que quiere el cliente.

Programada o Especificada: La que se ha especificado explícitamente y

se intenta conseguir.

Realizada: la que se ha conseguido.

A la intersección entre la Calidad Requerida y la Calidad Realizada se

llama Calidad Percibida y es la única que el cliente valora. Toda aquella

calidad que se realiza pero no se necesita es un gasto inútil de tiempo y

dinero.

TERMINOLOGÍA BÁSICA

ERROR: como una incorrección cometida por un humano

durante el proceso de desarrollo.

DEFECTO: es la consecuencia de un error. Así por ejemplo , si

una función tiene el objetivo de sumar 10 al valor que recibe

como entrada, y en realidad está sumando 20, eso es un defecto

debido al error del programador que escribió 20 en lugar de 10.

también se llama DEFECTO a una desviación en el valor

esperado para una cierta característica. Los defectos no tienen

porque afectar al funcionamiento del objeto defectuoso. Un

programa poco mantenible, por ejemplo, puede ser totalmente

correcto.

FALLO (failure): la manifestación de un defecto en el software.

Por ejemplo cuando a la función anterior se le da como entrada

el valor 10 y la salida que se obtiene es 30 en lugar de 20 que es

el valor esperado.

TERMINOLOGÍA BÁSICA

FALLAS (fault): son los defectos que aún no han sido detectados y eliminados cuando comienzan las pruebas. Algunas de estas fallas se convierten en fallos si se detectan durante las pruebas o el uso del sistema.

INCIDENTE o INCIDENCIA: a una situación en la que se produce y se informa de un comportamiento no esperado en el sistema. Una incidencia puede venir provocada por un defecto o no.

Estructura de los modelos de calidad En los modelos de calidad, la calidad se define de forma jerárquico. Es un

concepto que se deriva de un conjunto de subconjuntos cada uno de los cuales se

va a evaluar a través de un conjunto de indicadores o métricas. Tienen una

estructura de tres niveles:

Representan la calidad desde el punto de vista del usuario,

son las características que componen la calidad, también

se los conoce como Atributos de Calidad Externos.

Cada uno de los factores se descompone en un conjunto

de CRITERIOS de calidad, representan una visión de la

calidad desde el punto de vista del productos del software,

conocidos como Atributos de Calidad Internos.

Calidad del Software

Factores de Calidad

Criterios de Calidad del

Producto

Métricas del Producto

Son medidas cuantitativas de ciertas características del

producto que cuando están presentes dan una indicación

del grado en que dicho producto posee un determinado

atributo de calidad.

Modelos de Calidad La ventaja de los Modelos de Calidad, está en que la misma se convierte en algo

concreto, que se puede definir, que se puede medir y sobre todo se puede

planificar.

Una desventaja es que aun no se ha demostrado su validez absoluta, las

conexiones que se establecen entre características, atributos y métricas se

derivan de la experiencia y de ahí que existan múltiples modelos.

MC CALL

MÉTODO GQM

BOEHM

ISO 9126

FURPS

Organiza los factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar la calidad del producto:

Operación del Producto.

Revisión del Producto.

Transición del Producto

El Modelo McCall se basa en 11 factores de calidad, que se organizan en torno a los tres ejes de la siguiente forma:

ATRIBUTOS DEL MODELO DE Mc CALL

PUNTO DE VISTA FACTORES

Operación del Producto Facilidad de Uso

Integridad

Corrección

Fiabilidad

Eficiencia

Revisión del Producto Facilidad de Mantenimiento

Facilidad de Prueba

Flexibilidad

Transición del Producto Facilidad de reutilización

Interoperabilidad

Portabilidad

FACILIDAD DE MANTENIMIENTO

(¿Puedo arreglarlo?)

FACILIDAD DE PRUEBA

(¿Puedo probarlo?)

FLEXIBILIDAD

(¿Puedo modificarlo?)

ATRIBUTOS DEL MODELO DE Mc CALL

OPERACIÓN

INTEROPERABILIDAD

(¿Puedo comunicarlo con otro sistema?)

PORTABILIDAD

(¿Podré utilizarlo en otra máquina?)

REUSABILIDAD

(¿Podré utilizar parte del software?)

CORRECCIÓN (¿Hace el software lo que yo quiero?)

FIABILIDAD (¿Lo hace de forma exacta todo el tiempo?)

EFICIENCIA (¿Se ejecutará sobre mi hardware lo mejor posible?)

INTEGRIDAD (¿Es seguro?)

FACILIDAD DE USO (¿Puedo ejecutarlo?)

Los factores de McCall desde el punto de vista de Operación del Producto se definen de la siguiente forma:

FACTORES DE Mc CALL

• El coste y esfuerzo de aprender a manejar un producto, preparar la entrada de datos e interpretar la salida del mismo

Facilidad de Uso

• Hasta que punto se controlan los accesos ilegales a programas o datos. Un programa que permite el acceso de personas no autorizadas a ciertos datos es poco íntegro. Integridad

• Hasta que punto un programa cumple sus especificaciones y satisface los objetivos del usuario. Ejemplo: si un programa debe ser capaz de sumar dos números y en lugar de eso los multiplica. Es quizás el factor más importante, aunque puede no servir de nada sin los demás factores

Corrección

• Hasta que punto se puede confiar en el funcionamiento sin errores del programa. Por ejemplo, si el programa anterior suma dos números, pero en un 25 % de los casos el resultado que da no es correcto, es poco fiable.

Fiabilidad

• Cantidad de código y de recursos informáticos (CPU, memoria) que precisa un programa para desempeñar su función. Un programa que suma dos números y necesita 2 MB de memoria para funcionar, o que tarda 2 horas en dar una respuesta es poco eficiente.

Eficiencia

FACTORES DE Mc CALL

• El Coste de localizar y corregir defectos en un programa que aparecen durante su funcionamiento

Facilidad de Mantenimiento

• El coste de probar un programa para comprobar que satisface sus requisitos. Por ejemplo, si un programa requiere desarrollar una simulación completa de un sistema para poder probar que funciona bien, en un programa difícil de probar.

Facilidad de Prueba

• El coste de modificación del producto cuando cambian sus especificaciones. Flexibilidad

Los factores de McCall desde el punto de vista de Revisión del Producto se definen de la siguiente forma:

FACTORES DE Mc CALL

• Hasta que punto se puede transferir un módulo o programa del presente sistema a otra aplicación, y con que esfuerzo.

Facilidad de Reutilización

• El coste y esfuerzo necesario para hacer que el software pueda operar conjuntamente con otros sistemas o aplicaciones de software externos.

Interoperabilidad

• Conocido como transportabilidad. El coste de transportar o migrar un producto de una configuración hardware o entorno operativo a otro.

Portabilidad

Los factores de McCall desde el punto de vista de Transición del Producto se definen de la siguiente forma:

La Relación Factores – Criterio desde el Punto de Vista de Operación del Producto

FACTORES – CRITERIOS MODELO DE Mc CALL

PUNTO DE VISTA FACTORES

Facilidad de Uso Facilidad de Operación

Facilidad de Comunicación

Facilidad de Aprendizaje

Integridad Control de accesos

Facilidad de auditoría

Corrección Completitud

Consistencia

Trazabilidad

Fiabilidad Precisión

Consistencia

Tolerancia a fallos

Modularidad

Simplicidad

Eficiencia Eficiencia en Ejecución

Eficiencia en almacenamiento

CRITERIOS DE Mc CALL PARA EL FACTOR FACILIDAD DE USO

• Atributos del software que determinan la facilidad de operación del software

Facilidad de Operación

• Atributos del software que proporcionan al usuario entradas y salidas fácilmente asimilables

Facilidad de Comunicación

• Atributos del software que facilitan la familiarización inicial del usuario con el software y la transición desde el modo actual de operación.

Facilidad de Aprendizaje

Los criterios de McCall para el factor FACILIDAD DE USO se descomponen en:

CRITERIOS DE Mc CALL PARA EL FACTOR INTEGRIDAD

• Atributos del software que proporcionan control de acceso al software y los datos que maneja

Control de

Accesos

• Atributos del software que facilitan el registro y la auditoría de los accesos al software.

Facilidad de

Auditoría

Los criterios de McCall para el factor INTEGRIDAD se descomponen en:

CRITERIOS DE Mc CALL PARA EL FACTOR CORRECCIÓN

• Atributos del software que proporcionan la implementación completa de todas las funciones requeridas. Completitud

• Atributos del software que proporcionan uniformidad en las técnicas y notaciones de diseño e implementación utilizadas. Consistencia

• Conocido como Rastreabilidad. Atributos del software que proporcionan una traza desde los requisitos a la implementación con respecto a un entorno operativo concreto.

Trazabilidad

Los criterios de McCall para el factor CORRECCIÓN se descomponen en:

• Atributos del software que proporcionan el grado de precisión requerido en los cálculos y los resultados. Precisión

• Atributos de software que proporcionan uniformidad en las técnicas y notaciones de diseño e implementación utilizadas Consistencia

• Atributos del software que posibilitan la continuidad del funcionamiento bajo condiciones no usuales.

Tolerancia a fallos

• Atributos del software que proporcionan una estructura de módulos altamente independientes. Modularidad

• Atributos del software que posibilitan la implementación de funciones de la forma más compresible posible Simplificidad

CRITERIOS DE Mc CALL PARA EL FACTOR FIABILIDAD

Los criterios de McCall para el factor FIABILIDAD se descomponen en:

• Atributos del software que minimizan el tiempo de procesamiento.

Eficiencia en Ejecución

• Atributos del software que minimizan el espacio de almacenamiento necesario.

Eficiencia en Almacenamiento

Los criterios de McCall para el factor EFICIENCIA se descomponen en:

CRITERIOS DE Mc CALL PARA EL FACTOR EFICIENCIA

La Relación Factores – Criterio desde el Punto de Vista de Revisión del Producto

FACTORES – CRITERIOS MODELO DE Mc CALL

PUNTO DE VISTA FACTORES

Facilidad de Mantenimiento Modularidad

Simplicidad

Consistencia

Concisión

Auto descripción

Facilidad de Prueba Modularidad

Simplicidad

Auto descripción

Instrumentación

Flexibilidad Auto descripción

Capacidad de expansión

Generalidad

Modularidad

• Atributos del software que proporcionan una estructura de módulos altamente independientes. Modularidad

• Atributos del software que posibilitan la implementación de funciones de la forma más compresible posible Simplicidad

• Atributos de software que proporcionan uniformidad en las técnicas y notaciones de diseño e implementación utilizadas. Consistencia

• Atributos del software que posibilitan la implementación de una función con la menor cantidad de código posible. Concisión

• Atributos del software que proporcionan explicaciones sobre la implementación de las funciones.

Auto descripción

CRITERIOS DE Mc CALL PARA EL FACTOR FACILIDAD DE MANTENIMIENTO

Los criterios de McCall para el factor FACILIDAD DE MANTENIMEINTO se descomponen en:

CRITERIOS DE Mc CALL PARA EL FACTOR FACILIDAD DE PRUEBA

• Atributos del software que proporcionan una estructura de módulos altamente independientes.

Modularidad

• Atributos del software que posibilitan la implementación de funciones de la forma más compresible posible

Simplicidad

• Atributos del software que proporcionan explicaciones sobre la implementación de las funciones. Auto descripción

• Atributos del software que posibilitan la observación del comportamiento del software durante su ejecución (para facilitar las mediciones del uso o la identificación de errores )

Instrumentación

Los criterios de McCall para el factor FACILIDAD DE PRUEBA se descomponen en:

CRITERIOS DE Mc CALL PARA EL FACTOR FLEXIBILIDAD

• Atributos del software que proporcionan explicaciones sobre la implementación de las funciones.

Auto descripción

• Atributos del software que posibilitan la expansión del software en cuanto a capacidades funcionales y datos.

Capacidad de expansión

• Atributos del software que posibilitan amplitud a las funciones implementadas. Generalidad

• Atributos del software que proporcionan una estructura de módulos altamente independientes.. Modularidad

Los criterios de McCall para el factor FLEXIBILIDAD se descomponen en:

La Relación Factores – Criterio desde el Punto de Vista de Transición del Producto

FACTORES – CRITERIOS MODELO DE Mc CALL

PUNTO DE VISTA FACTORES

Facilidad de Reutilización Auto descripción

Generalidad

Modularidad

Independencia entre sistema y software

Interoperabilidad Modularidad

Compatibilidad de Comunicaciones

Compatibilidad de datos

Portabilidad Auto descripción

Modularidad

Independencia entre sistema y software

Independencia del hardware

• Atributos del software que proporcionan explicaciones sobre la implementación de las funciones.

Auto descripción

• Atributos de software que proporcionan amplitud a las funciones implementadas

Generalidad

• Atributos del software que proporcionan una estructura de módulos altamente independientes.

Modularidad

• Atributos del software que determinan la independencia del entorno operativo.

Independencia entre sistema y

software

• Atributos del software que determinan su independencia del hardware.

Independencia del hardware

CRITERIOS DE Mc CALL PARA EL FACTOR REUSABILIDAD

Los criterios de McCall para el factor REUSABILIDAD se descomponen en:

CRITERIOS DE Mc CALL PARA EL FACTOR INTEROPRABILIDAD

• Atributos del software que proporcionan una estructura de módulos altamente independientes. Modularidad

• Atributos del software que posibilitan el uso de protocolos de comunicación e interfaces estándar.

Compatibilidad de

Comunicaciones

• Atributos del software que proporcionan representaciones de datos estándar.

Compatibilidad de Datos

Los criterios de McCall para el factor INTEROPERABILIDAD se descomponen en:

CRITERIOS DE Mc CALL PARA EL FACTOR PORTABILIDAD

• Atributos del software que proporcionan explicaciones sobre la implementación de las funciones.

Auto descripción

• Atributos del software que proporcionan una estructura de módulos altamente independientes. Modularidad

• Atributos del software que determinan la independencia del sistema operativo.

Independencia entre sistema y

software

• Atributos del software que determinan su independencia del hardware.

Independencia del hardware

Los criterios de McCall para el factor PORTABILIDAD se descomponen en:

MODELO BOEHM

FURPS

Los factores de calidad FURPS provienen de trabajos anteriores, definiendo los siguientes atributos para cada uno de los cinco factores principales:

• Funcionalidad

• Facilidad de uso

• Fiabilidad

• Rendimiento

• capacidad de soporte.

ISO/IEC 9126: TECNOLOGÍAS DE LA INFORMACIÓN

CALIDAD DE LOS PRODUCTOS SOFTWARE.

• Modelo de Calidad Parte 1

• Métricas Externas Parte 2

• Métricas Internas Parte 3

• Métricas de Calidad en Uso Parte 4

calidad externa

e interna

funcionalidad fiabilidad usabilidad eficiencia mantenibilidad portabilidad

adecuación

exactitud

interoperabilidad

seguridad de

acceso

cumplimiento de

la funcionalidad

madurez

tolerancia a

fallos

capacidad de

recuperación

cumplimiento de

la fiabilidad

capacidad para

ser entendido

capacidad para

ser aprendido

capacidad para

ser operado

capacidad de

atracción

cumplimiento de

la usabilidad

comportamiento

temporal

utilización de

recursos

cumplimiento de

la eficiencia

capacidad para

ser analizado

capacidad para

ser cambiado

estabilidad

capacidad para

ser probado

cumplimiento de

la mantenibilidad

adaptabilidad

instalabilidad

coexistencia

capacidad para

ser reemplazado

cumplimiento de

la portabilidad

MODELO DE CALIDAD PARA CALIDAD INTERNA Y EXTERNA

MODELO DE CALIDAD PARA CALIDAD EN USO

ENTORNOS O MODELOS

Son los 3 vértices donde descansa un proceso de mejora que trabaja sobre 3 niveles de la organización.

CMM se enfoca a nivel organizacional

TSP se enfoca a un proceso de grupos de trabajo

PSP se enfoca a nivel personal

PSP Personal Software Process

Definición

Justificación

Pasos para la Implantación

Ciclo de Vida

DEFINICIÓN

Es un ciclo de vida del proceso de software que se caracteriza por:

Ser definido, conciso

Altamente prescriptivo

Rápido y barato

JUSTIFICACIÓN DEL PSP

Los ingenieros de software rara vez basan su trabajo en prácticas y metodologías establecidas y son prácticamente escépticos a cambiar sus hábitos de trabajo.

Los ingenieros están en un círculo vicioso, "sólo creen en lo que han probado y no prueban otras metodologías", por esta razón para poder implantar PSP, se tuvo que obligarlos y se tuvieron buenos resultados.

PASOS PARA IMPLANTACION PSP

Lo que sigue es optimizar la interacción entre equipos y aquí entraría Team Software Process, el TSP extiende y refina los métodos de CMM y PSP sobre desarrollo y mantenimiento de equipos, y llegar a lo que se le llama un equipo auto dirigido.

Requiere un fuerte soporte de administración, es necesario que los administradores entiendan el PSP, saber como apoyarlos y como monitorear sus avances, sin un adecuado monitoreo los ingenieros caerán otra vez en los malos hábitos.

La Capacitación es sobre grupos o equipos, y serán grupos que así lo han sido y seguirán siendo.

Los ingenieros deben ser entrenados por un instructor calificado de PSP.

CICLO DE VIDA PSP

7 niveles del PSP

PSP3

Proceso Personal Cíclico

PSP2 y PSP2.1

Manejo Personal de calidad

PSP1 y PSP1.1

Proceso Personal de Planeación

PSP0 y PSP0.1

Línea Base del PSP

• Identificar actividades: definición, secuencia

• Bases mejoras: planeación, evaluación, resultados

• Documentar proceso Formas de:

• Actividades (Scripts)

• Tiempos (Logs Time)

• Defectos (Defect Logs)

• Resumir planes, resultados (Proyect plan summary)

PSP 0

• Registrar tamaño del producto y hacer un histórico:

• Líneas de código (LDC)

• Puntos de función (PF)

• Estandarización de la codificación

• Registrar problemas y mejoras de propuestas

PSP 0.1

• Mejora la planeación:

• Con la estimación de recursos

• Introducción de calendarizar, plasmar el plan con números, un presupuesto

PSP 1

• Mejora la ejecución:

• Detección temprana de defectos, en base a la predicción de estos.

• Revisiones de diseño

• Revisiones de código

• Uso de checklists (Listas de verificación

PSP 2

• Mejora el diseño:

• Al hacer uso de formas detalladas de diseño (formas C76, C77)

PSP 2.1

• Mejora el ciclo, mejora del proceso en términos de hacerlo repetible (cíclico):

• Para aplicación a programas de mayor tamaño

• Registro del seguimiento de asuntos importantes

• Análisis del resumen de la planeación, tiempos, tamaños y defectos por cada ciclo.

PSP 3

CICLO DE VIDA PSP

FASE PLANEACIÓN

(PLAN DE PROYECTO)

INPUT

Descripción del problema, resumen

del proyecto, resumen cíclico,

tamaño estimado, tiempo estimado,

formas de planeación.

ACTIVIDAD

Requerimientos, tamaño estimado,

desarrollo estrategia,

estimados de recursos,

planificación y programas de

tareas, estimación de defectos.

OUTPUT

Diseño conceptual, resumen plan,

resumen del ciclo, patrones estimados

de tamaño y planeación de

tareas, programas de patrones de

planeación, registro de tiempos.

CICLO DE VIDA PSP

FASE DISEÑO DE PRODUCTO

INPUT

Tipificación requerimientos,

diseño conceptual, patrones de

estimaciones de tamaño, resumen

parte cíclico, seguimiento.

ACTIVIDAD

Especificaciones externas, diseño

modular, prototipos,

estrategia de desarrollo y

documentación, seguimiento.

OUTPUT

Diseño de programa, escenarios

operacionales, especificación de

funciones y lógica, resumen cíclico, seguimiento y estrategias de

pruebas y ciclo.

CICLO DE VIDA PSP

FASE REVISIÓN O VALIDACIÓN DEL DISEÑO

INPUT

Programa de diseño, escenarios

operacionales, especificación de

funciones y lógica, resumen cíclico, seguimiento y estrategia de

pruebas y ciclo.

ACTIVIDAD

Diseño de apariencia,

verificación de máquinas y lógica,

consistencia del diseño, rehúso,

estrategia de verificación,

detectar errores.

OUTPUT

Diseño de alto nivel, registro de

seguimiento, tiempos y defectos.

CICLO DE VIDA PSP

FASE DESARROLLO O IMPLEMENTACIÓN

INPUT

Diseño de alto nivel, registro de

seguimiento, tiempos y defectos, ciclo de desarrollo,

estrategia de pruebas, patrones

de operación y función.

ACTIVIDAD

Diseño de módulos, revisión de diseño, código, revisión de

código, compilación,

pruebas, aseguramiento de calidad y del ciclo.

OUTPUT

Módulos de SW, patrón de diseño,

lista de verificación de código y diseño, resumen del ciclo, patrón de reporte

de pruebas, registro de tiempo, defectos

y seguimiento.

CICLO DE VIDA PSP

FASE POSMORTEM, EVALUACIÓN CICLO

INPUT

Definición de problema y requerimientos, plan de proyecto, producto de software, patrón de

diseño, lista de verificación, diseño, resumen del ciclo, patrón de pruebas, registro de tiempo,

defectos y seguimiento.

ACTIVIDAD

Defectos previstos, removidos, tamaño,

tiempo del producto.

OUTPUT

Producto, listas de verificación, plan de

proyecto y ciclo, patrón de reporte

de pruebas y diseño, forma con

propuesta de mejora, registro

seguimiento pruebas y tiempo.

TSP Team Software Process

Definición

Objetivos

Estructura

Ciclo de Vida

Roles y Responsabilidades

DEFINICIÓN

TSP está formado por dos componentes primarios que abarcan distintos aspectos del trabajo en equipo :

Formación del equipo de trabajo

Gestión del equipo de trabajo

Es una metodología para dirigir el trabajo de mejora y desarrollo de software además de establecer un entorno donde el trabajo efectivo de equipo sea normal y natural.

OBJETIVOS DEL TSP

• Generar un marco basado en PSP

• Desarrollar productos en varios ciclos

• Establecer estándares para medir la calidad y el comportamiento

• Proporcionar métricas para equipos

• Evaluar roles y equipos

• Guías para solución de problemas en equipos.

ESTRUCTURA DE TSP

CICLO DE VIDA TSP

• Durante esta fase, y siendo el primer ciclo, se realiza una revisión de los objetivos del curso.

Lanzamiento

• Se establece la estrategia de desarrollo decidiendo que se producirá, y se identifica los riesgos.

Estrategia

• Asignación a cada miembro del equipo. Planeación

• Entrevistas con el cliente y se especifican. Requerimientos

CICLO DE VIDA TSP

• Diseño de alto nivel, donde se especifica y examina cada parte identificada. Diseño

• Revisión, compilación y prueba unitaria. Implementación

• Se integran todos los programas. Prueba

• Análisis del producto, Generación de las evaluaciones del equipo. Postmortem

ROLES Y RESPONSABILIDADES

Líder del Equipo Dirige al equipo, se asegura que todos reporten sus datos de los procesos y completen su trabajo tal y

como se planeó.

Gestor de desarrollo Guía al equipo en el diseño y desarrollo del producto.

Gestor de Planificación

Apoya y guía al equipo en la planificación y seguimiento del trabajo.

Gestor de Calidad/Proceso

Apoya al equipo en definir sus necesidades acerca del proceso, establecer y administrar el plan de calidad.

Administrador de Requerimientos/

Soporte

Dirige al equipo en el desarrollo de requerimientos de software, administra el plan de configuración

CMMI Capability Maturity Model

Integration

Definición

Representación Continua

Estructura de CMMI en Representación Continua

Representación Escalonada

Estructura de CMMI en Representación Escalonada

Componentes

DEFINICIÓN

CMMI es el sucesor de CMM.

El objetivo del proyecto CMMI es mejorar la usabilidad de modelos de madurez integrando varios modelos diferentes en un solo marco (framework).

Fue creado por miembros de la industria y el gobierno.

• Representación Continua (Continuous Representation)

• Escalonada (Staged Representation)

Tiene 2 representaciones:

REPRESENTACIÓN CONTINUA 6 NIVELES DEFINIDOS EN CMMI

• El proceso no se realiza, o no se consiguen sus objetivos. Incompleto

• El proceso se ejecuta y se logra su objetivo. Ejecutado

• El proceso se planifica, se revisa y se evalúa para comprobar que cumple los requisitos. Gestionado

• Se ajusta a la política de procesos que existe en la organización, alineada con las directivas de la empresa.

Definido

• Se controla utilizando técnicas cuantitativas. Cuantitativamente

Gestionado

• De forma sistemática se revisa y modifica o cambia para adaptarlo a los objetivos del negocio. Mejora continua.

Optimizando

REPRESENTACIÓN ESCALONADA (STAGED REPRESENTATION)

Establece 5 Niveles de Madurez (Maturity Level) para clasificar a las organizaciones, en función de qué áreas de procesos consiguen sus objetivos y se gestionan con principios de ingeniería.

Es lo que se denomina un modelo escalonado, o centrado en la madurez de la organización.

• 7 PA para el nivel de madurez o ML1

• 2 PA para el ML2

• 11 PA para el ML3

• 2 PA para el ML4

• 2 PA para el ML5

La selección de los Áreas de Proceso está prefijado, habiendo:

CALIDAD DEL PRODUCTO SOFTWARE

¿QUÉ ES LA CALIDAD DEL SOFTWARE?

• “Grado con el cual el cliente o usuario percibe que el software satisface sus expectativas” (IEEE 729-83).

• “Conjunto de propiedades y de características de un producto o servicio, que le confieren aptitud para satisfacer una necesidades explícitas o implícitas” (ISO 8402:1984)

¿QUÉ ES LA CALIDAD DEL SOFTWARE?

“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-1990).

“Concordancia del software producido con los requerimientos explícitamente establecidos, con los estándares de desarrollo prefijados y con los

requerimientos implícitos no establecidos formalmente, que desea el usuario” (Pressman,

1998)

¿QUÉ ES LA CALIDAD DEL SOFTWARE?

La calidad del software puede ser entendida como el grado con el cual el usuario percibe que el software satisface sus expectativas (IEEE 729-83).

El tipo y número de actividades de garantía de calidad que es necesario adoptar en un proyecto o en una organización depende del tamaño y complejidad de los productos software que se estén desarrollando.

Calidad

en uso

Calidad

externa

Calidad

interna

Calidad de

proceso

Proceso Producto

Efecto del

producto

Influye Influye Influye

Depende de Depende de Depende de

Contextos

de uso

proveedor usuario

¿CÓMO MEDIR LA CALIDAD DE UN PRODUCTO SOFTWARE?

Se emplea para ellos modelos , que especifican la calidad mediante la definición de un conjunto de atributos o características.

Se basa en descomponer la calidad del producto en características y estas en criterios que pueden ser medidos mediante métricas.

ACTIVIDADES DE CONTROL

Comprueban si un producto posee o no una determinada característica de calidad en el grado requerido.

Identificar defectos en el producto para corregirlos.

OBJETIVO

CONTROLES ESTÁTICOS El objetivo principal es analizar el objeto sin necesidad de ejecutarlo.

CONTROLES ESTÁTICOS MANUALES INFORMALES

• Examinar a mano e individualmente el objeto que se acaba de desarrollar.

• Se aplica a los requisitos, especificaciones de diseño y código según se desarrollan.

• Es más efectivo si se hace intercambiando el objeto a examinar con otro compañero.

Comprobación de escritorio (desk checking):

• Revisión del código de un programador por otros programadores (sus pares).

• Se puede poner en práctica creando un panel que se encarga de revisar periódicamente muestras de código.

Revisión por pares o iguales (peer review):

CONTROLES ESTÁTICOS MANUALES DISCIPLINADOS

El objetivo principal es conseguir que la responsabilidad del control de calidad no recaiga sólo sobre el propio desarrollador.

1. AUDITORÍAS:

Auditorías de proyecto

Auditorías de gestión de proyecto

PROCEDIMIENTO DE UNA AUDITORÍA

• Define los objetivos de la auditoria y su alcance

• Se elabora un Plan de Auditoria, dando respuesta a: Por qué se realiza, Para qué se realiza, Cuál es el producto que va a ser auditado, etc.

Planificación

• Se inicia con una reunión de apertura de la investigación.

• Se lleva a cabo mediante entrevistas y revisiones en las que se recopilan datos.

Llevar a cabo la investigación

• Se utilizan técnicas de análisis estadístico, por parte de los auditores.

• Se realiza una evaluación en paralelo de los resultados por un grupo de evaluadores.

Analizar los datos recogidos

Sugerir soluciones a los problemas encontrados y posibles mejoras.

Elaborar y presentar un informe de resultados

2. REVISIONES:

Se consigue que el peso de la evaluación técnica no recaiga sobre las mismas personas involucradas en la producción del software, pues no pueden ser totalmente objetivos.

Ofrece a los gestores, información fiable acerca de los aspectos técnicos del proceso de desarrollo de software.

Es una reunión formal donde se presenta el estado actual de los resultados de un proyecto a un usuario, cliente u otro tipo de persona interesada, y se realiza un análisis estructurado.

Características:

DIFERENCIAS ENTRE REVISIONES Y AUDITORÍAS:

Las revisiones se llevan a cabo desde las primeras

fases del desarrollo, mientras que las

auditorías se llevan a cabo en las fases finales.

El objetivo de las revisiones es detectar

defectos, mientras que el objetivo de las auditorías es certificar conformidad e identificar desviaciones.

TIPOS DE REVISIONES

Se diferencian por la forma en que se desarrolla la reunión de revisión.

Inspecciones

• Los participantes leen el documento, guiados por el autor del mismo, y comprueban en cada paso el cumplimiento de los criterios de una lista de comprobación.

Walkthrough (visita guiada):

• Se demuestra la funcionalidad del objeto revisado mediante la simulación de su funcionamiento con casos de prueba y ejemplos.

Se introducen al objeto los casos de prueba y se van registrando los resultados intermedios.

DIFERENCIAS:

WALKTHROUGH

Están planteados como una medida de ayuda al desarrollador.

Su objetivo fundamental es incrementar el entendimiento, comprender mejor el objeto.

Esta guiado por la estructura del producto revisado.

Se usan para asegurar la satisfacción de los criterios de

salida establecidos entre diferentes etapas del desarrollo

(revisiones de fase).

INSPECCIONES

Planteadas como una medida de ayuda al gestor.

El objetivo fundamental es detectar defectos.

Proceso guiado por la lista de comprobación.

Se planifican y procesan de una manera mucho más formal que

los walkthrough.

FASES EN LA INSPECCION

PLANIFICACION Objetivos, Criterios de finalización, Lugar y fecha, Disponibilidad de participantes (coordinador/moderador, secretario)

ORIENTACION INICIAL

Reunión de orientación para dar una idea del objeto

PREPARACION INDIVIDUAL

Antes de la realización de la inspección, una copia de la documentación asociada al objeto, y lista de comprobaciones checklist

FASES EN LA INSPECCION

REUNION DE INSPECCION

El presentador.- Punto por punto la lista de comprobación; Componente a componente del producto; Por grupos de puntos dentro de la lista de comprobación; Cualquier otra situación intermedia

Al final de la reunión de inspección, los participantes, valoran los resultados de la inspección: Se cierra la inspección sin que se hayan encontrado defectos; Defectos eliminados; Si se encuentran otros defectos se realiza otra inspección

FASES EN LA INSPECCION

SEGUIMIENTO Autor del objeto revisado se encarga de corregir los defectos encontrados

EVALUACION

Determina si se ha corregido todos los defectos y si han surgido nuevos problemas, el moderador se encarga de realizar la evaluación.

DOCUMENTOS GENERADOS EN UNA INSPECCION

Informe resumen.-

Conclusiones breves para la dirección (¿Qué se ha revisado?; ¿Quién lo ha revisado?; ¿Cual fue la

conclusión?)

Lista acciones pendientes.-

Informe para los autores del producto revisado explica que esta mal y se puede dar soluciones o

correcciones (no debe llegar a la dirección).

Informe de asuntos

relacionados.-

Para registrar problemas que salen a la luz durante la inspección ( no relacionados con el objeto

revisado)

Informe del proceso de inspección.-

Cuando algo ha salido mal en el proceso de inspección en si mismo

Informe final.- Para informar a la dirección el cierre de la

inspección.

Informes o documentos generados como resultado de una inspección son los siguientes:

FASES EN UN WALKTHROUGH

PLANIFICACION.-

• Similar a la planificación de una inspección con la diferencia que no es necesario asignar roles específicos a excepción del presentador( organizador del WALKTHROUGH)

PREPARACION INDIVIDUAL.-

• Cada revisor examina el objeto revisado en este caso no se entrega una lista de comprobación.

REUNION DE WALKTHROUGH.-

• Discusión de alternativas de diseño, encontrar errores.

FORMALIDAD EN LAS REVISIONES

• Es un evento público

• Se informa por escrito de los resultados

• Todos los participantes son responsables de la calidad de la revisión

Una revisión es formal cuando:

La ventaja de realizar revisiones formales es que los informes que se generan sirven con hitos para el proyecto y el hecho de ser algo público promueve una mejor preparación por parte de los participantes.

REVISIONES TECNICAS Y DE GESTION

Revisión de la

especificación de requisito

s

Revisión del

diseño

Revisión del

código

Revisión de las

pruebas

Revisión del

manual de

usuario

Las revisiones técnicas más comunes son:

OBJETIVOS DE LAS REVISIONES DEL PROYECTO SON:

Control de la progresión del proyecto.

Evaluación de los riesgos asociados al proyecto con relación al costo, escala de tiempo, recursos utilizados y calidad del

producto.

Evaluación general del producto.

Para que estos sea posible es necesario:

• Que exista un plan de desarrollo bien estructurado, con hitos bien definidos, que permita evaluar la progresión del proyecto

• Que los resultados del proyecto se encuentren bien documentados, y hayan sido examinados por la revisión técnica

REVISIÓN DE LA ESPECIFICACIÓN DE REQUISITOS

Es muy útil para facilitar el descubrimiento de los errores introducidos en la especificación de requisitos en fases tempranas del desarrollo.

ALGUNAS DE LAS PREGUNTAS QUE PODRÍAN ENCONTRARSE EN UNA LISTA DE COMPROBACIONES PARA LA ESPECIFICACIÓN DE REQUISITOS:

¿Se han especificado

todos los recursos hardware

necesarios?

¿Se han especificado las

interfaces externas

necesarias?

¿Existen contradicciones

en la especificación de

los requisitos?

¿Se han definido los criterios de

aceptación para cada una de las

funciones especificadas?

REVISIÓN DEL DISEÑO

El objetivo de estas revisiones es determinar y evaluar el estado en el que se encuentra el proceso de diseño, así como descubrir errores o contradicciones (entre la especificación de requisitos y el diseño o en las interfaces entre módulos)

ALGUNAS DE LAS PREGUNTAS QUE PODRÍAN ENCONTRARSE EN UNA LISTA DE COMPROBACIONES PARA EL DISEÑO SON LAS SIGUIENTES:

¿Hay uniformidad en el diseño?

¿Se han definido correctamente las interfaces entre módulos?

¿Se han definido correctamente las interfaces externas?

¿Cubre el diseño todas las funciones incluidas en la especificación de requisitos?

¿Cumple el diseño todos los requisitos no funcionales?

REVISIÓN DEL CÓDIGO

Su objetivo es determinar que el código se corresponde con el diseño detallado realizado.

Algunos de los aspectos que se examinan en una revisión de código son los siguientes:

adherencia a los estándares de codificación 20

comentarios

entradas y salidas

fórmulas

utilización de variables

estructura del programa

interfaces

REVISIÓN DE LAS PRUEBAS

Se pueden efectuar dos tipos de revisiones de las pruebas:

• Revisión del diseño de la prueba.

• Inspección de la prueba.

EL OBJETIVO DE LA REVISIÓN DEL DISEÑO DE LA PRUEBA ES COMPROBAR QUE EL DISEÑO REALIZADO PARA LA PRUEBA ESTÁ DE ACUERDO CON LOS OBJETIVOS QUE SE PERSIGUEN. SE DEBEN COMPROBAR ASPECTOS COMO: ¿Se han tenido en cuenta todos los objetivos a la hora de diseñar los casos de prueba?

¿Se han elegido los casos de prueba más adecuados para comprobar la consecución de dichos objetivos?

• Los objetivos de las inspecciones de las pruebas, por su parte, son:

Comprobar que la prueba se ha ejecutado correctamente, de acuerdo con el procedimiento de prueba especificado.

Análisis de los resultados obtenidos con cada prueba.

CONTROLES ESTÁTICOS AUTOMÁTICOS

Dentro de esta categoría tenemos el análisis estático automático y la verificación formal de programas.

La mayor parte del análisis estático automático del código lo realizan los compiladores, que pueden detectar desde expresiones sintácticamente incorrectas hasta incompatibilidades de tipo y otros errores de tipo semántico.

Otras técnicas de análisis estático automático de programas son:

• Análisis de Flujo

• Ejecución simbólica

ANÁLISIS DE FLUJO

Consiste en determinar el comportamiento de las variables del programa desde su inicialización hasta que termina la ejecución del programa.

CLASIFICANDO LAS VARIABLES EN:

REFERENCIADAS

Cuando se obtiene su valor en

memoria durante la evaluación de una expresión en una

sentencia.

DEFINIDAS

Cuando se obtiene un nuevo valor para

la variable como consecuencia de la ejecución de una

sentencia.

NO REFERENCIADAS

Cuando ya no se puede determinar

el valor de la variable a partir del flujo del programa.

EJECUCIÓN SIMBÓLICA

La mejor forma de analizarla es descomponerla en una estructura de árbol, donde cada hoja representa un camino de ejecución y cada ramificación representa un punto de decisión en el programa.

EJEMPLO Función en ADA que calcula la suma de los N elementos de un array entero A:

function SUM (A: INTARRAY; N: NATURAL) return INTEGER is

S: INTEGER := 0;

I: NATURAL := 1;

Begin

while I <= N loop

S := S + A(I);

I := I + 1;

end loop;

return (S);

End SUM;

RESULTADO DE LA EJECUCIÓN SIMBÓLICA

Y EN FORMA DE ÁRBOL

VERIFICACIÓN FORMAL

Consiste en demostrar matemáticamente la corrección de un programa con respecto a sus

especificaciones.

Es también necesario que la especificación se haya escrito en algún lenguaje formal. Por eso no siempre

es posible realizar este tipo de verificación.

Por lo general, esta técnica sólo se utiliza para sistemas críticos, debido al coste que conlleva.

GESTIÓN DE CALIDAD DEL

SOFTWARE

SISTEMA DE GESTIÓN DE CALIDAD ISO

9001:2000

GESTIÓN DE CALIDAD DEL SOFTWARE (SQM)

• Aspecto de la función general de la gestión que determina y aplica la política y objetivos de la calidad del software.

• Conjunto de actividades que dirigen y controlan una empresa en lo relativo a la calidad.

• Deben incluir el establecimiento de la política y los objetivos de la calidad.

SISTEMA DE CALIDAD

Conjunto de las actividades relativas a planificación, control, aseguramiento y mejora de la calidad dentro de una empresa.

Las actividades de garantía de calidad que se adoptan en un proyecto, depende mucho de la complejidad y tamaño de los productos de software.

SGC debe fijar la estructura de la organización, de las responsabilidades, de las actividades, de los recursos y de los procedimientos para llevar a cabo la gestión de calidad.

SISTEMA DE CALIDAD

SGC debe determinar los procedimientos y métodos a implantar para lograr una gestión de la calidad.

Define como implementar la garantía de calidad.

• Organización: Es este el nivel en el que normalmente se establece el sistema de calidad.

• Proyecto.

• Fase de desarrollo.

Se puede definir un sistema de calidad en 3 niveles:

SISTEMA DE CALIDAD

Establece también de que forma se reparten las tareas y las responsabilidades entre el personal.

Un sistema de gestión de la calidad es la forma en la que una empresa o institución dirige y controla todas las actividades que están asociadas a la calidad

PARTES QUE COMPONEN EL SISTEMA DE GESTIÓN

Estructura organizativa: departamento de calidad o responsable de la dirección de la empresa.

Cómo se planifica la calidad.

Los procesos de la organización.

Recursos que la organización aplica a la calidad.

Documentación que se utiliza.

SISTEMA DE GESTIÓN DE CALIDAD

SISTEMA DE GESTIÓN DE CALIDAD

ISO 9001:2000

• Especifica los requisitos para un SGC que pueden utilizarse para su aplicación.

• Se centra en la eficacia del SGC para asegurar la satisfacción del cliente.

• Promueve la adopción de un enfoque orientado a procesos para el desarrollo, implementación y la mejora de la eficacia de un SGC.

ISO 9001:2000

• Consta de 20 clausulas que definen que aspectos de un sistema de calidad deben estar presentes en una organización.

• No da detalles de cómo deben implementarse e institucionalizarse dichos aspectos.

• Asegura que la organización documenta todos sus procesos y procedimientos de acuerdo con los requisitos del estándar.

MODELO DE GESTIÓN DE CALIDAD

CONTROLES DINÁMICOS Y COSTOS DE

CALIDAD

CONTROLES DINÁMICOS

Requieren la ejecución del objeto

que se está probando o de un

modelo del mismo.

PRUEBA DEL

SOFTWARE

Es el proceso en que se ejecuta un sistema con el objetivo de detectar fallos.

• En proyectos grandes la prueba 50 - 60% del esfuerzo. • Es muy importante seleccionar bien las pruebas • Seleccionar casos de prueba que incidan en programa

complejos. • La prueba es disciplina profesional que requiere formación • El grupo de prueba debe ser independiente del de desarrollo y

debe adoptar una actitud positiva de destrucción creativa.

CARACTERÍSTICAS

DEPURACIÓN Es el proceso en el que se localiza el defecto que

es la causa de un fallo.

• Se determina la forma de corregirlo • Se evalúa el efecto de la corrección • Se lleva a cabo la corrección

PASOS

TIPOS DE

PRUEBAS • Estándar IEEE 1012-1986

PRUEBA MODULAR

PRUEBA DE INTEGRACIÓN

PRUEBA DE SISTEMA

PRUEBA DE ACEPTACIÓN

PRUEBA DE REGRESIÓN

PRUEBA MODULAR

• Conocida también

como prueba

unitaria o prueba

de componentes

• Consiste en la

prueba de cada

módulo aislado

del resto del

sistema

PRUEBA DE INTEGRACIÓN

Se realiza a medida que los diferentes módulos

del sistema se integran en el mismo

El objetivo de esta prueba es comprobar que las

interfaces entre los distintos módulos son

correctas.

COMPROBACIONES

Compatibilidad de tipos entre los

argumentos del procedimiento o función

y los parámetros de llamada

Corrección en la sintaxis en la

invocación de procedimientos y

funciones

Corrección y completitud de las

especificaciones de los módulos

PRUEBAS DE INTEGRACIÓN

Integración descendente

Módulo en

pruebas

Otros

módulos

Otros

módulos

Reales,

ya probados

Otros

módulos

simulados

(stubs)

PRUEBA DE SISTEMA

Se realiza cuando se han integrado todos los módulos

El objetivo es comprobar que el sistema satisface los

requisitos del usuario, tanto los funcionales como los no

funcionales

PRUEBA DE ACEPTACIÓN

• Se realiza una vez que el sistema se ha implantado en su entorno real de funcionamiento

• El objetivo es demostrar al usuario que el sistema satisface sus necesidades

PRUEBA DE REGRESIÓN

• Tiene como objetivo comprobar que toda nueva versión de un producto software es de no menos calidad que la versión anterior.

RELACIÓN ENTRE PRODUCTOS DE

DESARROLLO Y NIVELES DE

PRUEBA

MÉTODOS

DE CAJA

NEGRA

El objeto que se desea probar se ve

como una caja negra. (elección de

los casos de prueba no se basa en

el conocimiento la estructura del

objeto, sino en el conocimiento de

la funcionalidad deseada.

El objeto que se desea probar se ve como una caja negra. (elección de los casos de prueba no se basa en el conocimiento la estructura del objeto, sino en el conocimiento de la funcionalidad deseada.

MÉTODOS DE CAJA BLANCA O CAJA

TRANSPARENTE

El objeto que se prueba se ve como una caja blanca. (elección de los casos de prueba se basan en conocimiento que se tenga de la estructura del objeto, diseño detallado, diagramas de flujo de datos y de control, código fuente).

• Los basados en

métricas de

cobertura

• Los basados en

métricas de

complejidad

LOS MÉTODOS DE CAJA BLANCA SE PUEDEN CLASIFICAR, A SU VEZ, EN DOS GRUPOS:

• Una prueba de caja blanca exhaustiva requeriría

la generación de un caso de prueba por cada

posible camino.

• Como esto no es posible, por lo general, se

utilizan métricas que dan una indicación de la

calidad de un determinado conjunto de casos de

prueba en función del grado de cobertura del

grafo que consiguen.

Cobertura de:

• Sentencias

• Segmentos entre decisiones.

• Decisiones de ramificación

• Condiciones

• Todas las combinaciones de

condiciones

• Caminos

Las métricas más utilizadas son:

MÉTODOS BASADOS EN MÉTRICAS DE

COMPLEJIDAD

Complejidad ciclomática (arcos - nodos + 2 * número de componentes conexos)

Complejidad esencial (complejidad ciclomática - número de subgrafos propios de entrada y salida única)

Complejidad real (número de caminos ejecutados)

LAS MÉTRICAS DE COMPLEJIDAD MÁS UTILIZADAS EN LA GENERACIÓN DE CASOS DE PRUEBA SON LAS DE MACCABE:

METODOLOGÍA DE PRUEBA La prueba tiene su propio ciclo de vida.

Los diferentes tipos de prueba implica la realización de un conjunto de actividades estándar y salidas estándar

Para cada fase del proceso de desarrollo hay alguna actividad de prueba importante.

PLANIFICACIÓN DE LA PRUEBA

– El objetivo del proceso de prueba

– Los objetos que hay que probar

– Las característica que se prueban y las que no

– El método de prueba a utilizar

– Los recursos que se van a emplear

– El plan de tiempos

– Los productos a generar durante las pruebas

– El reparto de las responsabilidades

Es la creación de un plan de pruebas que registra:

DISEÑO DE LAS PRUEBAS

Cómo llevar a cabo la prueba para alcanzar

los objetivos deseados

De qué forma se van a utilizar los métodos de

prueba

Qué objetos se van a probar en cada una de

las pruebas

Qué criterios se van a utilizar para

determinar si el objeto pasa o no pasa la

prueba.

CONSISTE EN DAR INSTRUCCIONES SOBRE:

DETERMINACIÓN DE LOS CASOS DE PRUEBA

Consiste en especificar el conjunto de casos

de prueba a utilizar en función del diseño

realizado para la prueba, especificando:

– Qué objetos se van a probar

– Qué entradas se les van a dar y

– Cuáles son las salidas esperadas

PLANIFICACIÓN DEL PROCEDIMIENTO DE

PRUEBA

Consiste en fijar un conjunto de pasos para la

ejecución de la prueba, especificando:

• La secuencia exacta de ejecución. • Los requisitos que hay que cumplir para la ejecución. • Las condiciones de terminación de cada uno de ellos

EJECUCIÓN DE LA PRUEBA

• Consiste en ejecutar cada caso de prueba, (paso anterior), y registrar los incidentes o problemas encontrados durante el sistema.

COMPARACIÓN ENTRE LOS MÉTODOS DE

CONTROL DE CALIDAD

Hay dos maneras para mejorar la calidad de los

productos que desarrollamos:

Detectar los defectos lo antes posible

Cometer menos errores

Teniendo en cuenta que el proceso de detección

puede subdividirse en las siguientes fases:

Identificar síntomas

Deducir localización del defecto a partir de los

síntomas

Averiguar qué es lo que está mal

Decidir cómo arreglar el defecto

Arreglarlo

Verificar que se ha resuelto el problema

COMPARACIÓN ENTRE LOS MÉTODOS DE

CONTROL DE CALIDAD

Por otro lado, se pueden usar una serie de métricas para poder hacer una evaluación y comparación cuantitativa entre diferentes actividades de control de calidad.

En primer lugar, se deben tomar una serie de métricas directas:

Tamaño del objeto examinado en la actividad

Tiempo invertido en la actividad

Número de defectos detectados

A partir de estas métricas básicas, se puede calcular una serie de métricas derivadas muy interesantes

COMPARACIÓN ENTRE LOS MÉTODOS DE

CONTROL DE CALIDAD

Número de Escapes:

Son los defectos que estaban ahí y no han sido detectados hasta después de concluida la actividad. Para poder calcular esto es necesario conocer la fase en la que los defectos fueron introducidos y eliminados.

Eficacia de la tarea (Yield)

Es el porcentaje de defectos encontrados una actividad sobre todos los que estaban ahí al iniciarse ésta.

La fórmula para calcularla es:

MÉTRICAS DERIVADAS

tarea_ escapes tarea_ eliminados

_tareaeliminados100

Yield

MÉTRICAS DERIVADAS

Densidad de defectos encontrados

Se mide en número de defectos por unidad de tamaño del objeto examinado

La fórmula para calcularla es:

Eficiencia de la tarea (Tasa de Eliminación de Defectos)

Nos indica cómo de rápido se encuentra defectos en la actividad correspondiente.

La fórmula para calcularla es:

revisiones _en_ invertido _ tiempo

tarea_ sencontradoTED

revisado _ objeto _ tamaño

tarea_ sencontradoDensidad

Rapidez de la revisión

Es una métrica que se aplica sólo a las revisiones, y nos indica la cantidad de material cubierto por unidad de tiempo.

La fórmula para calcularla es:

Cabe decir que no es bueno ir demasiado rápido. Se recomienda no sobrepasar los 300 LOC/hora. Generalmente resulta interesante ver la correlación de esta métrica con la Eficacia (Yield), y comprobar cómo a medida que aumenta la rapidez decrece la eficacia.

revisioninvertidotamaño

revisadoobjetotamañoRapidez

__

__

MÉTRICAS DERIVADAS

Poder de Eliminación de Defectos (Defect Removal Leverage)

Nos indica el ratio de eficiencia entre dos actividades de detección de defectos. Dicho de otro modo, permite ver cuánto más/menos eficiente es una actividad con respecto otra.

La fórmula para calcularla es:

-

2_

1_PED

tareaPED

tareaPED

MÉTRICAS DERIVADAS

150

COSTOS DE CALIDAD

Representan la diferencia entre los costos reales de un

producto o servicio y el costo reducido si no hubiera la

posibilidad de un tener un servicio por debajo de los

estándares, fallas de productos, o defectos en su

manufactura.

• Costos de prevención

• Costos de evaluación

• Costos de falla interna

• Costos de falla externa

COSTOS DE CALIDAD

151

COSTOS DE PREVENCIÓN

Son los costos de todas las actividades específicamente diseñados para prevenir fallas de calidad en productos o servicios

– Revisión de nuevos productos

– Planeación de la calidad (manuales, procedimientos, etc.)

– Evaluación de capacidad de proveedores

– Esfuerzos de mejora a través de trabajo en equipo

– Proyectos de mejora continua

– Educación y entrenamiento en calidad… etc.

EJEMPLO:

152

Son los costos asociados con las actividades de medir,

evaluar y auditar los productos o servicios para

asegurar su conformidad a los estándares de calidad y

requerimientos de desempeño.

COSTOS DE EVALUACIÓN

– Inspecciones con el proveedor y en recibo

– Pruebas e inspecciones en proceso y al producto terminado

– Auditorias al producto, proceso o servicio

– Calibración de equipos de prueba y medición

– Costos de materiales de prueba

EJEMPLO:

153

COSTOS DE FALLA INTERNA

Son los costos resultantes de productos o servicios

no conformes a los requerimientos o necesidades del

cliente, antes del embarque del producto o la

realización del servicio.

• Desperdicio (maculatura) • Retrabajos • Reinspección y repetición de pruebas • Revisión de materiales no conformes • Reducción de precio por calidad reducida

EJEMPLO

154

COSTOS DE FALLA EXTERNA

Son los costos resultantes de productos o servicios

no conformes a los requerimientos o necesidades del

cliente, después de la entrega del producto o

durante y después de la realización del servicio.

• Proceso de quejas y reclamaciones • Devoluciones del cliente • Garantías • Campañas por productos defectivos

EJEMPLO

155

COSTOS TOTALES DE CALIDAD

Es la suma de los costos de prevención,

apreciación, falla interna y falla

externa

Los sistemas contables en general no

son capaces de identificar estos costos

Es muy difícil ir al detalle del costo de

calidad tal como un error de la

secretaria

Planificación de la Calidad

PLANIFICACIÓN

Es el proceso en el que se indica que la empresa puede probar que realiza sus planes de calidad, exponiendo un plan de calidad para cada producto.

• Los objetivos de la calidad

• Planificación de la calidad.

Incluye dos aspectos centrales:

PLAN DE CALIDAD

Es el documento o conjunto de documentos:

• Que establecen los objetivos de calidad,

• La especificación de los procesos operativos necesarios y

• La disponibilidad de los recursos apropiados para satisfacer tales objetivos, para la elaboración del producto que ocupa a la organización.

PLAN SQA

Proporciona un mapa para institucionalizar la garantía de calidad del

software.

Sirve como plantilla para actividades de SQA

instituidas para cada proyecto de software.

SECCIONES

Documentación

Gestión

Revisión y Auditoría

Pruebas

Otros

SECCIONES

DOCUMENTACIÓN

Situación de la SQA dentro de la

estructura organizativa

Las tareas y las actividades de

SQA y su emplazamiento a

lo largo del proceso del

software

Los papeles y responsabilidade

s organizativas relativas a la calidad del producto

SECCIONES

Describe cada uno de los productos de trabajo producidos como parte del proceso

de software.

Documentos del proyecto (plan del proyecto)

Modelos (DERs, jerarquías de

clases),

Documentos técnicos

(especificaciones, planes de prueba)

Documentos de usuario (archivos

de ayuda)

GESTIÓN

SECCIONES

REVISIÓN Y AUDITORIA

Identifica las revisiones y auditorías que se van a llevar a cabo por el equipo de ingeniería del software, el grupo de SQA y el cliente.

Proporciona una visión general del enfoque de cada revisión y auditoría.

SECCIONES

PRUEBAS

Hace referencia al Plan y Procedimiento

de Pruebas del Software

Define requisitos de mantenimiento de

registros de pruebas.

SECCIONES

• Identifica las herramientas y métodos que soportan actividades y tareas de SQA

• Define un enfoque de gestión de contratos

• Establece métodos para reunir, salvaguardar y mantener todos los registros

• Identifica la formación que se requiere para cumplir las necesidades del plan

• Define métodos para identificar, evaluar, supervisar y controlar riesgos.