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
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 DEVISTA 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
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:

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:

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 utilizadasConsistencia
• 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 posibleSimplificidad
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:
EFICIENCIA

 La Relación Factores – Criterio desde el Punto de Vista de Revisión del
Producto
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
funciones de la forma más compresible posibleSimplicidad
• 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
FACILIDAD DE MANTENIMIENTO
Los criterios de McCall para el factor FACILIDAD DE MANTENIMEINTO se
descomponen en:

FACILIDAD DE PRUEBA
funciones de la forma más compresible posibleSimplicidad
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:

FLEXIBILIDAD
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
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
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
REUSABILIDAD
Los criterios de McCall para el factor REUSABILIDAD se descomponen en:

INTEROPRABILIDAD
• 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:

PORTABILIDAD
Auto
descripción
• 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:

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 CalidadParte 1
• Métricas ExternasParte 2
• Métricas InternasParte 3
• Métricas de Calidad en UsoParte 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
INTERNAY EXTERNA

MODELO DE CALIDAD PARA CALIDAD EN USO

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 deVida

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 DEVIDA 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 DEVIDA 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 DEVIDA 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 DEVIDA 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 DEVIDA 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 deVida
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 DELTSP
• 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.

CICLO DEVIDATSP
• 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 DEVIDATSP
• 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

ROLESY 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
La selección de los Áreas de Proceso está prefijado, habiendo:

¿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)

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)

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.

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 REVISIONESY 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

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

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 TECNICASY DE GESTION
Revisión
de la
especific
ació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

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

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.

CONTROLES
DINÁMICOSY
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
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
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_escapestarea_eliminados
_tareaeliminados
100

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.
revisiones_en_invertido_tiempo
tarea_sencontrado
TED
revisado_objeto_tamaño
tarea_sencontrado
Densidad

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.
 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ño
Rapidez
__
__

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

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
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.

Material monster is ii emco

Más contenido relacionado

La actualidad más candente

Destacado

Similar a Material monster is ii emco

Material monster is ii emco