Embed Size (px)
Citation preview
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.
