UNIVERSIDAD DE LAS FUERZAS ARMADAS

DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIN

CARRERA DE INGENIERA EN SISTEMAS E INFORMTICA
Ing. Mauricio Campaa Ortega MsC. CCNA. CCIA.
INGENIERA DE SOFTWARE II
CALIDAD DEL SOFTWARE
La integridad de un producto de software
depende de la accin combinada de tres tipos
de disciplinas:
Desarrollo
Gestin
Control

Dentro de las disciplinas de control se encuentra
la Garanta 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 terminologa utilizada.
Ser capaz de caracterizar la calidad de un producto de
software en trminos de un modelo de calidad.
Comprender en que consiste la Garanta 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 Garanta de Calidad.
Ser capaz de participar en una revisin o auditora.
Ser consciente de las medidas que puede tomar para construir
productos de mayor calidad.
Conocer los principales mtodos de evaluacin 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, mtodos, prcticas y
transformaciones que la gente usa para desarrollar
y mantener software y los productos de trabajo
asociados (planes de proyecto, diseo de
documentos, cdigo, pruebas y manuales de
usuario)
Proceso o conjunto de procesos usados por una
organizacin 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 fabricacin industrial, ya que el software tiene
ciertas caractersticas especiales:
El software es un producto mental, no restringido por las leyes
de la fsica o por los lmites de los proceso de fabricacin. Es
algo abstracto y su calidad tambin lo es.
Se desarrolla, no se fabrica. El coste esta fundamentalmente en
el proceso de diseo, no en la produccin. Y los errores se
introducen tambin en el diseo no en la produccin.
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 mayora se
construye a medida, en vez de ser construido ensamblando
componentes existentes y ya probados, lo que dificulta an ms
el control de su calidad. Aunque se ha escrito mucho sobre
reutilizacin de software, hasta ahora se han conseguido pocos
xitos tangibles.
CALIDAD DEL PRODUCTO DE
SOFTWARE
El mantenimiento del software es mucho ms 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 diseo o en el
proceso mediante el cual se tradujo el diseo en cdigo mquina
ejecutable.
Es engaosamente fcil 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 an muy joven, por
lo que las tcnicas de las que se disponen an no son totalmente
efectivas o no estn 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 definicin misma de la calidad del software: Es realmente
posible encontrar un conjunto de propiedades en un producto
software que de una indicacin de calidad? Para dar respuesta a
esta pregunta aparecen los Modelos de Calidad.
Modelos de Calidad: La calidad de define de forma jerrquica. Resuelven
la complejidad mediante la descomposicin. La calidad es un concepto
que se deriva de un conjunto de subconceptos.

La comprobacin de la calidad del software: Cmo 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: Cmo utilizar la informacin
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 tambin construir la calidad durante el
proceso de desarrollo del producto. Aparecen dos conceptos
importantes:
Gestin de Calidad: Determinacin y Aplicacin de las polticas
de calidad de la empresa (objetivos y directrices generales)
Garanta o Aseguramiento de Calidad: Conjunto de Actividades
planificadas y sistemticas necesaria para proporcionar
confianza en que el producto software satisfacerla los
requisitos dados de calidad.
DEFINICIN DE CALIDAD
Calidad es Conformidad con los requisitos y confianza en el
funcionamiento Deming.
Adecuacin para su uso. Jurn
Hacerlo bien a la primera o sea poner ms nfasis en la
prevencin. Crosby

Definiciones de calidad extrados de estndares internacionales
La calidad es la suma de todos aspectos o caractersticas de
un producto o servicio que influye en su capacidad para
satisfacer las necesidades, expresadas o implcitas. 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.




DEFINICIN DE CALIDAD
La calidad es algo relativo, depende de los requisitos o
necesidades que se desea satisfacer.

En un producto de software se tendrn tres visiones de la calidad:
Necesaria o requerida: La que quiere el cliente.
Programada o Especificada: La que se ha especificado
explcitamente y se intenta conseguir.
Realizada: la que se ha conseguido.

A la interseccin 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 intil de tiempo y dinero.

TERMINOLOGA BSICA
ERROR: como una incorreccin cometida por un humano
durante el proceso de desarrollo.
DEFECTO: es la consecuencia de un error. As por ejemplo
, si una funcin 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. tambin se llama DEFECTO a una
desviacin en el valor esperado para una cierta
caracterstica. Los defectos no tienen porque afectar al
funcionamiento del objeto defectuoso. Un programa poco
mantenible, por ejemplo, puede ser totalmente correcto.
FALLO (failure): la manifestacin de un defecto en el
software. Por ejemplo cuando a la funcin 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.
TERMINOLOGA BSICA
FALLAS (fault): son los defectos que an
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
situacin 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 jerrquico. Es un
concepto que se deriva de un conjunto de subconjuntos cada uno de los
cuales se va a evaluar a travs de un conjunto de indicadores o mtricas.
Tienen una estructura de tres niveles:
Representan la calidad desde el punto de vista del
usuario, son las caractersticas que componen la
calidad, tambin se los conoce como Atributos de
Calidad Externos.
Cada uno de los factores se descompone en un
conjunto de CRITERIOS de calidad, representan una
visin 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
Mtricas del Producto
Son medidas cuantitativas de ciertas caractersticas
del producto que cuando estn presentes dan una
indicacin del grado en que dicho producto posee un
determinado atributo de calidad.
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 caractersticas, atributos y
mtricas se derivan de la experiencia y de ah que existan mltiples
modelos.
MC CALL
MTODO 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:
Operacin del Producto.
Revisin del Producto.
Transicin 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
Operacin del Producto Facilidad de Uso
Integridad
Correccin
Fiabilidad
Eficiencia
Revisin del Producto Facilidad de
Mantenimiento
Facilidad de Prueba
Flexibilidad
Transicin del Producto Facilidad de reutilizacin
Interoperabilidad
Portabilidad
FACILIDAD DE MANTENIMIENTO
(Puedo arreglarlo?)
FACILIDAD DE PRUEBA
(Puedo probarlo?)
FLEXIBILIDAD
(Puedo modificarlo?)


ATRIBUTOS DEL MODELO DE Mc CALL
OPERACIN
INTEROPERABILIDAD
(Puedo comunicarlo con otro
sistema?)
PORTABILIDAD
(Podr utilizarlo en otra mquina?)
REUSABILIDAD
(Podr utilizar parte del software?)


CORRECCIN (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 Operacin 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
nmeros y en lugar de eso los multiplica. Es quizs el factor ms importante,
aunque puede no servir de nada sin los dems factores
Correccin
Hasta que punto se puede confiar en el funcionamiento sin errores del
programa. Por ejemplo, si el programa anterior suma dos nmeros, pero en
un 25 % de los casos el resultado que da no es correcto, es poco fiable.
Fiabilidad
Cantidad de cdigo y de recursos informticos (CPU, memoria) que precisa un
programa para desempear su funcin. Un programa que suma dos nmeros
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 simulacin completa de un
sistema para poder probar que funciona bien, en un
programa difcil de probar.
Facilidad de
Prueba
El coste de modificacin del producto cuando cambian sus
especificaciones.
Flexibilidad
Los factores de McCall desde el punto de vista de Revisin del Producto se
definen de la siguiente forma:
FACTORES DE Mc CALL
Hasta que punto se puede transferir un mdulo o
programa del presente sistema a otra aplicacin, y con
que esfuerzo.
Facilidad de
Reutilizacin
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 configuracin hardware o
entorno operativo a otro.
Portabilidad
Los factores de McCall desde el punto de vista de Transicin del Producto se
definen de la siguiente forma:
La Relacin Factores Criterio desde el Punto de Vista de
Operacin del Producto
FACTORES CRITERIOS MODELO DE Mc CALL
PUNTO DE VISTA FACTORES
Facilidad de Uso Facilidad de Operacin
Facilidad de Comunicacin
Facilidad de Aprendizaje
Integridad Control de accesos
Facilidad de auditora
Correccin Completitud
Consistencia
Trazabilidad
Fiabilidad Precisin
Consistencia
Tolerancia a fallos
Modularidad
Simplicidad
Eficiencia Eficiencia en Ejecucin
Eficiencia en
almacenamiento
CRITERIOS DE Mc CALL PARA EL FACTOR
FACILIDAD DE USO
Atributos del software que determinan la facilidad de
operacin del software
Facilidad de
Operacin
Atributos del software que proporcionan al usuario
entradas y salidas fcilmente asimilables
Facilidad de
Comunicacin
Atributos del software que facilitan la familiarizacin inicial
del usuario con el software y la transicin desde el modo
actual de operacin.
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 auditora
de los accesos al software.
Facilidad
de
Auditora
Los criterios de McCall para el factor INTEGRIDAD se descomponen en:
CRITERIOS DE Mc CALL PARA EL FACTOR
CORRECCIN
Atributos del software que proporcionan la implementacin
completa de todas las funciones requeridas.
Completitud
Atributos del software que proporcionan uniformidad en
las tcnicas y notaciones de diseo e implementacin
utilizadas.
Consistencia
Conocido como Rastreabilidad. Atributos del software que
proporcionan una traza desde los requisitos a la
implementacin con respecto a un entorno operativo
concreto.
Trazabilidad
Los criterios de McCall para el factor CORRECCIN se descomponen en:
Atributos del software que proporcionan el grado de
precisin requerido en los clculos y los resultados.
Precisin
Atributos de software que proporcionan uniformidad en las
tcnicas y notaciones de diseo e implementacin
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
mdulos altamente independientes.
Modularidad
Atributos del software que posibilitan la implementacin de
funciones de la forma ms 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
Ejecucin
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 Relacin Factores Criterio desde el Punto de Vista de
Revisin del Producto
FACTORES CRITERIOS MODELO DE Mc CALL
PUNTO DE VISTA FACTORES
Facilidad de Mantenimiento Modularidad
Simplicidad
Consistencia
Concisin
Auto descripcin
Facilidad de Prueba Modularidad
Simplicidad
Auto descripcin
Instrumentacin
Flexibilidad Auto descripcin
Capacidad de expansin
Generalidad
Modularidad
Atributos del software que proporcionan una
estructura de mdulos altamente independientes.
Modularidad
Atributos del software que posibilitan la implementacin de
funciones de la forma ms compresible posible
Simplicidad
Atributos de software que proporcionan uniformidad en las
tcnicas y notaciones de diseo e implementacin
utilizadas.
Consistencia
Atributos del software que posibilitan la implementacin de
una funcin con la menor cantidad de cdigo posible.
Concisin
Atributos del software que proporcionan explicaciones
sobre la implementacin de las funciones.
Auto
descripcin
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
mdulos altamente independientes.
Modularidad
Atributos del software que posibilitan la implementacin
de funciones de la forma ms compresible posible
Simplicidad
Atributos del software que proporcionan explicaciones
sobre la implementacin de las funciones.
Auto descripcin
Atributos del software que posibilitan la observacin del
comportamiento del software durante su ejecucin (para
facilitar las mediciones del uso o la identificacin de errores
)
Instrumentacin
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 implementacin de las funciones.
Auto
descripcin
Atributos del software que posibilitan la expansin del
software en cuanto a capacidades funcionales y datos.
Capacidad de
expansin
Atributos del software que posibilitan amplitud a las
funciones implementadas.
Generalidad
Atributos del software que proporcionan una estructura de
mdulos altamente independientes..
Modularidad
Los criterios de McCall para el factor FLEXIBILIDAD se descomponen en:
La Relacin Factores Criterio desde el Punto de Vista de
Transicin del Producto
FACTORES CRITERIOS MODELO DE Mc CALL
PUNTO DE VISTA FACTORES
Facilidad de Reutilizacin Auto descripcin
Generalidad
Modularidad
Independencia entre sistema y software
Interoperabilidad Modularidad
Compatibilidad de Comunicaciones
Compatibilidad de datos
Portabilidad Auto descripcin
Modularidad
Independencia entre sistema y
software
Independencia del hardware
Atributos del software que proporcionan explicaciones
sobre la implementacin de las funciones.
Auto descripcin
Atributos de software que proporcionan amplitud
a las funciones implementadas
Generalidad
Atributos del software que proporcionan una
estructura de mdulos 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
mdulos altamente independientes.
Modularidad
Atributos del software que posibilitan el uso de protocolos
de comunicacin e interfaces estndar.
Compatibilidad
de
Comunicaciones
Atributos del software que proporcionan representaciones
de datos estndar.
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 implementacin de las funciones.
Auto
descripcin
Atributos del software que proporcionan una estructura de
mdulos 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: TECNOLOGAS DE LA INFORMACIN
CALIDAD DE LOS PRODUCTOS SOFTWARE.
Modelo de Calidad
Parte 1
Mtricas Externas
Parte 2
Mtricas Internas
Parte 3
Mtricas de Calidad en Uso
Parte 4
calidad externa
e interna
funcionalidad fiabilidad usabilidad eficiencia mantenibilidad portabilidad
adecuacin
exactitud
interoperabilidad
seguridad de
acceso
cumplimiento de
la funcionalidad
madurez
tolerancia a
fallos
capacidad de
recuperacin
cumplimiento de
la fiabilidad
capacidad para
ser entendido
capacidad para
ser aprendido
capacidad para
ser operado
capacidad de
atraccin
cumplimiento de
la usabilidad
comportamiento
temporal
utilizacin 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 vrtices donde descansa un proceso de
mejora que trabaja sobre 3 niveles de la organizacin.
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
Definicin
Justificacin
Pasos para la Implantacin
Ciclo de Vida



DEFINICIN
Es un ciclo de vida del proceso de
software que se caracteriza por:
Ser
definido,
conciso
Altamente
prescriptivo
Rpido y
barato
JUSTIFICACIN DEL PSP
Los ingenieros de software rara vez basan su
trabajo en prcticas y metodologas establecidas
y son prcticamente escpticos a cambiar sus
hbitos de trabajo.
Los ingenieros estn en un crculo vicioso, "slo
creen en lo que han probado y no prueban otras
metodologas", por esta razn para poder
implantar PSP, se tuvo que obligarlos y se
tuvieron buenos resultados.
PASOS PARA IMPLANTACION PSP
Lo que sigue es optimizar la interaccin entre equipos y aqu entrara Team
Software Process, el TSP extiende y refina los mtodos 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 administracin, es necesario que los
administradores entiendan el PSP, saber como apoyarlos y como monitorear sus
avances, sin un adecuado monitoreo los ingenieros caern otra vez en los malos
hbitos.
La Capacitacin es sobre grupos o equipos, y sern grupos que as lo han sido y
seguirn siendo.
Los ingenieros deben ser entrenados por un instructor calificado de PSP.
CICLO DE VIDA PSP



7 niveles del PSP
PSP3
Proceso Personal Cclico
PSP2 y PSP2.1
Manejo Personal de calidad
PSP1 y PSP1.1
Proceso Personal de Planeacin
PSP0 y PSP0.1
Lnea Base del PSP
Identificar actividades: definicin, secuencia
Bases mejoras: planeacin, evaluacin, resultados
Documentar proceso Formas de:
Actividades (Scripts)
Tiempos (Logs Time)
Defectos (Defect Logs)
Resumir planes, resultados (Proyect plan summary)
PSP 0
Registrar tamao del producto y hacer un histrico:
Lneas de cdigo (LDC)
Puntos de funcin (PF)
Estandarizacin de la codificacin
Registrar problemas y mejoras de propuestas
PSP 0.1
Mejora la planeacin:
Con la estimacin de recursos
Introduccin de calendarizar, plasmar el plan con
nmeros, un presupuesto
PSP 1
Mejora la ejecucin:
Deteccin temprana de defectos, en base a la
prediccin de estos.
Revisiones de diseo
Revisiones de cdigo
Uso de checklists (Listas de verificacin
PSP 2
Mejora el diseo:
Al hacer uso de formas detalladas de diseo
(formas C76, C77)
PSP 2.1
Mejora el ciclo, mejora del proceso en trminos
de hacerlo repetible (cclico):
Para aplicacin a programas de mayor tamao
Registro del seguimiento de asuntos
importantes
Anlisis del resumen de la planeacin,
tiempos, tamaos y defectos por cada ciclo.
PSP 3
CICLO DE VIDA PSP
FASE PLANEACIN
(PLAN DE PROYECTO)
INPUT
Descripcin del
problema, resumen
del proyecto,
resumen cclico,
tamao estimado,
tiempo estimado,
formas de
planeacin.
ACTIVIDAD
Requerimientos,
tamao estimado,
desarrollo
estrategia,
estimados de
recursos,
planificacin y
programas de
tareas, estimacin
de defectos.
OUTPUT
Diseo conceptual,
resumen plan,
resumen del ciclo,
patrones estimados
de tamao y
planeacin de
tareas, programas
de patrones de
planeacin, registro
de tiempos.
CICLO DE VIDA PSP
FASE DISEO DE
PRODUCTO
INPUT
Tipificacin
requerimientos,
diseo conceptual,
patrones de
estimaciones de
tamao, resumen
parte cclico,
seguimiento.
ACTIVIDAD
Especificaciones
externas, diseo
modular,
prototipos,
estrategia de
desarrollo y
documentacin,
seguimiento.
OUTPUT
Diseo de
programa,
escenarios
operacionales,
especificacin de
funciones y lgica,
resumen cclico,
seguimiento y
estrategias de
pruebas y ciclo.
CICLO DE VIDA PSP
FASE REVISIN O
VALIDACIN DEL DISEO
INPUT
Programa de
diseo, escenarios
operacionales,
especificacin de
funciones y lgica,
resumen cclico,
seguimiento y
estrategia de
pruebas y ciclo.
ACTIVIDAD
Diseo de
apariencia,
verificacin de
mquinas y lgica,
consistencia del
diseo, rehso,
estrategia de
verificacin,
detectar errores.
OUTPUT
Diseo de alto
nivel, registro de
seguimiento,
tiempos y defectos.
CICLO DE VIDA PSP
FASE DESARROLLO O
IMPLEMENTACIN
INPUT
Diseo de alto
nivel, registro de
seguimiento,
tiempos y defectos,
ciclo de desarrollo,
estrategia de
pruebas, patrones
de operacin y
funcin.
ACTIVIDAD
Diseo de mdulos,
revisin de diseo,
cdigo, revisin de
cdigo,
compilacin,
pruebas,
aseguramiento de
calidad y del ciclo.
OUTPUT
Mdulos de SW,
patrn de diseo,
lista de verificacin
de cdigo y diseo,
resumen del ciclo,
patrn de reporte
de pruebas, registro
de tiempo, defectos
y seguimiento.
CICLO DE VIDA PSP
FASE POSMORTEM,
EVALUACIN CICLO
INPUT
Definicin de problema
y requerimientos, plan
de proyecto, producto
de software, patrn de
diseo, lista de
verificacin, diseo,
resumen del ciclo,
patrn de pruebas,
registro de tiempo,
defectos y seguimiento.
ACTIVIDAD
Defectos previstos,
removidos, tamao,
tiempo del
producto.
OUTPUT
Producto, listas de
verificacin, plan de
proyecto y ciclo,
patrn de reporte
de pruebas y
diseo, forma con
propuesta de
mejora, registro
seguimiento
pruebas y tiempo.
TSP
Team Software Process
Definicin
Objetivos
Estructura
Ciclo de Vida
Roles y Responsabilidades
DEFINICIN
TSP est formado por dos componentes primarios que
abarcan distintos aspectos del trabajo en equipo :
Formacin del
equipo de trabajo
Gestin del equipo
de trabajo
Es una metodologa para dirigir el trabajo de mejora y
desarrollo de software adems 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 estndares para medir la calidad y el
comportamiento
Proporcionar mtricas para equipos
Evaluar roles y equipos
Guas para solucin de problemas en equipos.
ESTRUCTURA DE TSP
CICLO DE VIDA TSP
Durante esta fase, y siendo el primer
ciclo, se realiza una revisin de los
objetivos del curso.
Lanzamiento
Se establece la estrategia de desarrollo
decidiendo que se producir, y se
identifica los riesgos.
Estrategia
Asignacin a cada miembro del equipo.
Planeacin
Entrevistas con el cliente y se especifican.
Requerimientos
CICLO DE VIDA TSP
Diseo de alto nivel, donde se especifica
y examina cada parte identificada. Diseo
Revisin, compilacin y prueba unitaria.
Implementacin
Se integran todos los programas.
Prueba
Anlisis del producto, Generacin de las
evaluaciones del equipo. Postmortem
ROLES Y RESPONSABILIDADES
Lder 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 Gua al equipo en el diseo y desarrollo del producto.
Gestor de
Planificacin
Apoya y gua al equipo en la planificacin 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 configuracin
CMMI
Capability Maturity Model
Integration
Definicin
Representacin Continua
Estructura de CMMI en Representacin
Continua
Representacin Escalonada
Estructura de CMMI en Representacin
Escalonada
Componentes
DEFINICIN
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.
Representacin Continua (Continuous Representation)
Escalonada (Staged Representation)
Tiene 2 representaciones:
REPRESENTACIN 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 evala
para comprobar que cumple los requisitos.
Gestionado
Se ajusta a la poltica de procesos que existe
en la organizacin, alineada con las
directivas de la empresa.
Definido
Se controla utilizando tcnicas cuantitativas.
Cuantitativamente
Gestionado
De forma sistemtica se revisa y modifica o
cambia para adaptarlo a los objetivos del
negocio. Mejora continua.
Optimizando
REPRESENTACIN ESCALONADA
(STAGED REPRESENTATION)
Establece 5 Niveles de Madurez (Maturity Level) para clasificar a
las organizaciones, en funcin de qu reas de procesos
consiguen sus objetivos y se gestionan con principios de
ingeniera.
Es lo que se denomina un modelo escalonado, o centrado en la
madurez de la organizacin.
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 seleccin 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
caractersticas de un producto o servicio,
que le confieren aptitud para satisfacer
una necesidades explcitas o implcitas
(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 explcitamente establecidos, con
los estndares de desarrollo prefijados y con los
requerimientos implcitos 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 nmero de actividades de garanta de
calidad que es necesario adoptar en un proyecto o
en una organizacin depende del tamao y
complejidad de los productos software que se estn
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
CMO MEDIR LA CALIDAD DE
UN PRODUCTO SOFTWARE?
Se emplea para ellos modelos , que
especifican la calidad mediante la definicin
de un conjunto de atributos o
caractersticas.
Se basa en descomponer la calidad del
producto en caractersticas y estas en
criterios que pueden ser medidos mediante
mtricas.
ACTIVIDADES
DE CONTROL
Comprueban si un producto posee o no una determinada
caracterstica de calidad en el grado requerido.
Identificar defectos en el producto para corregirlos.
OBJETIVO
CONTROLES ESTTICOS
El objetivo principal es analizar el objeto sin necesidad de
ejecutarlo.
CONTROLES ESTTICOS MANUALES INFORMALES
Examinar a mano e individualmente el objeto
que se acaba de desarrollar.
Se aplica a los requisitos, especificaciones de
diseo y cdigo segn se desarrollan.
Es ms efectivo si se hace intercambiando el
objeto a examinar con otro compaero.
Comprobacin
de escritorio
(desk checking):
Revisin del cdigo de un programador por
otros programadores (sus pares).
Se puede poner en prctica creando un panel
que se encarga de revisar peridicamente
muestras de cdigo.
Revisin por
pares o iguales
(peer review):
CONTROLES ESTTICOS MANUALES DISCIPLINADOS
El objetivo principal es conseguir que la responsabilidad del
control de calidad no recaiga slo sobre el propio
desarrollador.
1. AUDITORAS:
Auditoras de
proyecto
Auditoras de
gestin de
proyecto
PROCEDIMIENTO DE UNA AUDITORA
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, Cul es el producto que va a ser
auditado, etc.
Planificacin
Se inicia con una reunin de apertura de la investigacin.
Se lleva a cabo mediante entrevistas y revisiones en las que
se recopilan datos.
Llevar a cabo la
investigacin
Se utilizan tcnicas de anlisis estadstico, por parte de los
auditores.
Se realiza una evaluacin 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 evaluacin tcnica no recaiga sobre las mismas
personas involucradas en la produccin del software, pues no pueden ser
totalmente objetivos.
Ofrece a los gestores, informacin fiable acerca de los aspectos tcnicos del
proceso de desarrollo de software.
Es una reunin 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 anlisis estructurado.
Caractersticas:
DIFERENCIAS ENTRE REVISIONES Y AUDITORAS:

Las revisiones se llevan a
cabo desde las primeras
fases del desarrollo,
mientras que las
auditoras se llevan a
cabo en las fases finales.
El objetivo de las
revisiones es detectar
defectos, mientras que el
objetivo de las auditoras
es certificar conformidad
e identificar desviaciones.
TIPOS DE REVISIONES
Se diferencian por la forma en que se desarrolla la reunin de revisin.
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 comprobacin.
Walkthrough
(visita guiada):
Se demuestra la funcionalidad del objeto revisado mediante
la simulacin 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
Estn 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
satisfaccin 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
comprobacin.
Se planifican y procesan de una
manera mucho ms formal que
los walkthrough.
FASES EN LA INSPECCION
PLANIFICACION
Objetivos, Criterios de finalizacin, Lugar y fecha,
Disponibilidad de participantes
(coordinador/moderador, secretario)
ORIENTACION
INICIAL
Reunin de orientacin para dar una idea del
objeto
PREPARACION
INDIVIDUAL
Antes de la realizacin de la inspeccin, una copia
de la documentacin asociada al objeto, y lista de
comprobaciones checklist
FASES EN LA INSPECCION
REUNION DE
INSPECCION
El presentador.-
Punto por punto la lista de comprobacin;
Componente a componente del producto; Por
grupos de puntos dentro de la lista de
comprobacin; Cualquier otra situacin intermedia
Al final de la reunin de inspeccin, los
participantes, valoran los resultados de la
inspeccin: Se cierra la inspeccin sin que se hayan
encontrado defectos; Defectos eliminados; Si se
encuentran otros defectos se realiza otra
inspeccin
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
evaluacin.
DOCUMENTOS GENERADOS EN UNA INSPECCION
Informe
resumen.-
Conclusiones breves para la direccin (Qu se ha
revisado?; Quin lo ha revisado?; Cual fue la
conclusin?)
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 direccin).
Informe de
asuntos
relacionados.-
Para registrar problemas que salen a la luz durante
la inspeccin ( no relacionados con el objeto
revisado)
Informe del
proceso de
inspeccin.-
Cuando algo ha salido mal en el proceso de
inspeccin en si mismo
Informe final.-
Para informar a la direccin el cierre de la
inspeccin.
Informes o documentos generados como resultado de una inspeccin son
los siguientes:

FASES EN UN WALKTHROUGH
PLANIFICACION.-
Similar a la
planificacin de
una inspeccin
con la diferencia
que no es
necesario asignar
roles especficos
a excepcin del
presentador(
organizador del
WALKTHROUGH)
PREPARACION
INDIVIDUAL.-
Cada revisor
examina el
objeto revisado
en este caso no
se entrega una
lista de
comprobacin.
REUNION DE
WALKTHROUGH.-
Discusin de
alternativas de
diseo, encontrar
errores.
FORMALIDAD EN LAS REVISIONES
Es un evento pblico
Se informa por escrito de los resultados
Todos los participantes son responsables de la
calidad de la revisin
Una revisin 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
pblico promueve una mejor preparacin por
parte de los participantes.
REVISIONES TECNICAS Y DE GESTION
Revisin
de la
especific
acin de
requisito
s
Revisin
del
diseo
Revisin
del
cdigo
Revisin
de las
pruebas
Revisin
del
manual
de
usuario
Las revisiones tcnicas ms comunes son:

OBJETIVOS DE LAS REVISIONES DEL PROYECTO SON:

Control de la progresin del proyecto.
Evaluacin de los riesgos asociados al
proyecto con relacin al costo, escala de
tiempo, recursos utilizados y calidad del
producto.
Evaluacin 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 progresin del proyecto
Que los resultados del proyecto se encuentren bien documentados, y
hayan sido examinados por la revisin tcnica
REVISIN DE LA ESPECIFICACIN DE REQUISITOS
Es muy til para facilitar el descubrimiento
de los errores introducidos en la
especificacin de requisitos en fases
tempranas del desarrollo.
ALGUNAS DE LAS PREGUNTAS QUE PODRAN
ENCONTRARSE EN UNA LISTA DE COMPROBACIONES
PARA LA ESPECIFICACIN DE REQUISITOS:
Se han
especificado
todos los recursos
hardware
necesarios?
Se han
especificado las
interfaces
externas
necesarias?
Existen
contradicciones
en la
especificacin de
los requisitos?
Se han definido
los criterios de
aceptacin para
cada una de las
funciones
especificadas?
REVISIN DEL DISEO
El objetivo de estas revisiones es determinar y
evaluar el estado en el que se encuentra el
proceso de diseo, as como descubrir errores o
contradicciones (entre la especificacin de
requisitos y el diseo o en las interfaces entre
mdulos)
ALGUNAS DE LAS PREGUNTAS QUE PODRAN
ENCONTRARSE EN UNA LISTA DE COMPROBACIONES
PARA EL DISEO SON LAS SIGUIENTES:

Hay uniformidad en el diseo?
Se han definido correctamente las interfaces
entre mdulos?
Se han definido correctamente las interfaces
externas?
Cubre el diseo todas las funciones incluidas en la
especificacin de requisitos?
Cumple el diseo todos los requisitos no
funcionales?
REVISIN DEL CDIGO
Su objetivo es determinar que el cdigo se corresponde con el diseo detallado
realizado.
Algunos de los aspectos que se examinan en una revisin de cdigo son los
siguientes:
adherencia a los estndares de codificacin 20
comentarios
entradas y salidas
frmulas
utilizacin de variables
estructura del programa
interfaces
REVISIN DE LAS PRUEBAS
Se pueden efectuar dos tipos de
revisiones de las pruebas:
Revisin del diseo de la prueba.
Inspeccin de la prueba.
EL OBJETIVO DE LA REVISIN DEL DISEO DE LA PRUEBA ES
COMPROBAR QUE EL DISEO 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 disear los casos de
prueba?
Se han elegido los casos de prueba ms adecuados para comprobar la
consecucin 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.
Anlisis de los resultados obtenidos con cada prueba.
CONTROLES ESTTICOS AUTOMTICOS
Dentro de esta categora tenemos el anlisis esttico
automtico y la verificacin formal de programas.
La mayor parte del anlisis esttico automtico del cdigo lo
realizan los compiladores, que pueden detectar desde
expresiones sintcticamente incorrectas hasta
incompatibilidades de tipo y otros errores de tipo semntico.
Otras tcnicas de anlisis esttico automtico de programas
son:
Anlisis de Flujo
Ejecucin simblica
ANLISIS DE FLUJO
Consiste en determinar el
comportamiento de las variables del
programa desde su inicializacin hasta
que termina la ejecucin del programa.
CLASIFICANDO LAS VARIABLES EN:

REFERENCIADAS

Cuando se obtiene
su valor en
memoria durante la
evaluacin de una
expresin en una
sentencia.
DEFINIDAS

Cuando se obtiene
un nuevo valor para
la variable como
consecuencia de la
ejecucin de una
sentencia.
NO
REFERENCIADAS

Cuando ya no se
puede determinar
el valor de la
variable a partir del
flujo del programa.
EJECUCIN SIMBLICA
La mejor forma de analizarla es descomponerla
en una estructura de rbol, donde cada hoja
representa un camino de ejecucin y cada
ramificacin representa un punto de decisin en
el programa.
EJEMPLO
Funcin 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 EJECUCIN SIMBLICA
Y EN FORMA DE RBOL
VERIFICACIN FORMAL
Consiste en demostrar matemticamente la
correccin de un programa con respecto a sus
especificaciones.
Es tambin necesario que la especificacin se haya
escrito en algn lenguaje formal. Por eso no siempre
es posible realizar este tipo de verificacin.
Por lo general, esta tcnica slo se utiliza para
sistemas crticos, debido al coste que conlleva.
GESTIN DE
CALIDAD DEL
SOFTWARE

SISTEMA DE GESTIN
DE CALIDAD ISO
9001:2000


GESTIN DE CALIDAD DEL SOFTWARE
(SQM)
Aspecto de la funcin general de la gestin que
determina y aplica la poltica 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 poltica y
los objetivos de la calidad.
SISTEMA DE CALIDAD
Conjunto de las actividades relativas a
planificacin, control, aseguramiento y mejora de la
calidad dentro de una empresa.
Las actividades de garanta de calidad que se
adoptan en un proyecto, depende mucho de la
complejidad y tamao de los productos de
software.
SGC debe fijar la estructura de la organizacin, de
las responsabilidades, de las actividades, de los
recursos y de los procedimientos para llevar a cabo
la gestin de calidad.
SISTEMA DE CALIDAD
SGC debe determinar los procedimientos y mtodos
a implantar para lograr una gestin de la calidad.
Define como implementar la garanta de calidad.
Organizacin: 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 tambin de que forma se
reparten las tareas y las responsabilidades
entre el personal.
Un sistema de gestin de la calidad es la
forma en la que una empresa o institucin
dirige y controla todas las actividades que
estn asociadas a la calidad
PARTES QUE COMPONEN EL SISTEMA DE
GESTIN
Estructura organizativa: departamento de
calidad o responsable de la direccin de la
empresa.
Cmo se planifica la calidad.
Los procesos de la organizacin.
Recursos que la organizacin aplica a la
calidad.
Documentacin que se utiliza.
SISTEMA DE GESTIN DE CALIDAD
SISTEMA DE GESTIN DE CALIDAD
ISO 9001:2000
Especifica los requisitos para un SGC que
pueden utilizarse para su aplicacin.
Se centra en la eficacia del SGC para asegurar
la satisfaccin del cliente.
Promueve la adopcin de un enfoque
orientado a procesos para el desarrollo,
implementacin 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 organizacin.
No da detalles de cmo deben implementarse e
institucionalizarse dichos aspectos.
Asegura que la organizacin documenta todos
sus procesos y procedimientos de acuerdo con
los requisitos del estndar.
MODELO DE GESTIN DE CALIDAD
CONTROLES
DINMICOS Y
COSTOS DE
CALIDAD
CONTROLES DINMICOS
Requieren la ejecucin 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 formacin
El grupo de prueba debe ser independiente del de desarrollo y
debe adoptar una actitud positiva de destruccin creativa.
CARACTERSTICAS
DEPURACIN
Es el proceso en el que se localiza el defecto que es
la causa de un fallo.


Se determina la forma de corregirlo
Se evala el efecto de la correccin
Se lleva a cabo la correccin
PASOS
TIPOS DE PRUEBAS
Estndar IEEE 1012-1986
PRUEBA MODULAR
PRUEBA DE INTEGRACIN
PRUEBA DE SISTEMA
PRUEBA DE ACEPTACIN
PRUEBA DE REGRESIN
PRUEBA MODULAR
Conocida tambin
como prueba
unitaria o prueba
de componentes
Consiste en la
prueba de cada
mdulo aislado
del resto del
sistema
PRUEBA DE INTEGRACIN
Se realiza a medida que los diferentes mdulos del
sistema se integran en el mismo
El objetivo de esta prueba es comprobar que las
interfaces entre los distintos mdulos son correctas.
COMPROBACIONES
Compatibilidad de tipos entre los
argumentos del procedimiento o funcin y
los parmetros de llamada
Correccin en la sintaxis en la invocacin
de procedimientos y funciones
Correccin y completitud de las
especificaciones de los mdulos

PRUEBAS DE INTEGRACIN
Integracin descendente
Mdulo en
pruebas
Otros
mdulos
Otros
mdulos
Reales,
ya probados
Otros
mdulos
simulados
(stubs)
PRUEBA DE SISTEMA
Se realiza cuando se han integrado todos los mdulos
El objetivo es comprobar que el sistema satisface los requisitos
del usuario, tanto los funcionales como los no funcionales
PRUEBA DE ACEPTACIN
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 REGRESIN
Tiene como objetivo comprobar que toda nueva versin de un
producto software es de no menos calidad que la versin
anterior.
RELACIN ENTRE PRODUCTOS DE
DESARROLLO Y NIVELES DE PRUEBA
MTODOS
DE CAJA
NEGRA
El objeto que se desea probar se ve
como una caja negra. (eleccin 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. (eleccin de los
casos de prueba no se basa en el
conocimiento la estructura del objeto,
sino en el conocimiento de la
funcionalidad deseada.
MTODOS DE CAJA BLANCA O CAJA
TRANSPARENTE
El objeto que se prueba se ve como una caja blanca.
(eleccin de los casos de prueba se basan en
conocimiento que se tenga de la estructura del objeto,
diseo detallado, diagramas de flujo de datos y de
control, cdigo fuente).

Los basados en
mtricas de
cobertura
Los basados en
mtricas de
complejidad

LOS MTODOS DE
CAJA BLANCA SE
PUEDEN
CLASIFICAR, A SU
VEZ, EN DOS
GRUPOS:
Una prueba de caja blanca exhaustiva requerira la
generacin de un caso de prueba por cada posible
camino.
Como esto no es posible, por lo general, se utilizan
mtricas que dan una indicacin de la calidad de un
determinado conjunto de casos de prueba en funcin
del grado de cobertura del grafo que consiguen.

Cobertura de:
Sentencias
Segmentos entre decisiones.
Decisiones de ramificacin
Condiciones
Todas las combinaciones de
condiciones
Caminos
Las mtricas ms
utilizadas son:
MTODOS BASADOS EN MTRICAS DE
COMPLEJIDAD
Complejidad ciclomtica
(arcos - nodos + 2 * nmero
de componentes conexos)
Complejidad esencial
(complejidad ciclomtica -
nmero de subgrafos
propios de entrada y salida
nica)
Complejidad real (nmero
de caminos ejecutados)
LAS MTRICAS DE
COMPLEJIDAD MS
UTILIZADAS EN LA
GENERACIN DE
CASOS DE PRUEBA
SON LAS DE
MACCABE:
METODOLOGA DE PRUEBA
La prueba tiene su propio ciclo de vida.
Los diferentes tipos de prueba implica la realizacin
de un conjunto de actividades estndar y salidas
estndar
Para cada fase del proceso de desarrollo hay alguna
actividad de prueba importante.
PLANIFICACIN DE LA PRUEBA
El objetivo del proceso de prueba
Los objetos que hay que probar
Las caracterstica que se prueban y las que no
El mtodo 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 creacin
de un plan de
pruebas que
registra:
DISEO DE LAS PRUEBAS
Cmo llevar a cabo la prueba para alcanzar los
objetivos deseados
De qu forma se van a utilizar los mtodos 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:
DETERMINACIN
DE LOS CASOS
DE PRUEBA
Consiste en especificar el conjunto de casos de
prueba a utilizar en funcin del diseo realizado
para la prueba, especificando:
Qu objetos se van a probar
Qu entradas se les van a dar y
Cules son las salidas esperadas
PLANIFICACIN DEL PROCEDIMIENTO DE PRUEBA
Consiste en fijar un conjunto de pasos para la
ejecucin de la prueba, especificando:
La secuencia exacta de ejecucin.
Los requisitos que hay que cumplir para la ejecucin.
Las condiciones de terminacin de cada uno de ellos
EJECUCIN DE LA PRUEBA
Consiste en ejecutar cada caso de prueba, (paso anterior), y
registrar los incidentes o problemas encontrados durante el
sistema.
COMPARACIN ENTRE LOS MTODOS 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 deteccin
puede subdividirse en las siguientes fases:

Identificar sntomas
Deducir localizacin del defecto a partir de los
sntomas
Averiguar qu es lo que est mal
Decidir cmo arreglar el defecto
Arreglarlo
Verificar que se ha resuelto el problema

COMPARACIN ENTRE LOS MTODOS DE CONTROL
DE CALIDAD
Por otro lado, se pueden usar una serie de mtricas para
poder hacer una evaluacin y comparacin cuantitativa
entre diferentes actividades de control de calidad.

En primer lugar, se deben tomar una serie de mtricas
directas:

Tamao del objeto examinado en la actividad
Tiempo invertido en la actividad
Nmero de defectos detectados

A partir de estas mtricas bsicas, se puede calcular una
serie de mtricas derivadas muy interesantes


COMPARACIN ENTRE LOS MTODOS DE CONTROL
DE CALIDAD
Nmero de Escapes:

Son los defectos que estaban ah y no han sido detectados
hasta despus 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 frmula para calcularla es:



MTRICAS DERIVADAS
tarea _ escapes tarea _ eliminados
_tarea eliminados
100

Yield
MTRICAS DERIVADAS
Densidad de defectos encontrados

Se mide en nmero de defectos por unidad de tamao del objeto
examinado

La frmula para calcularla es:




Eficiencia de la tarea (Tasa de Eliminacin de Defectos)

Nos indica cmo de rpido se encuentra defectos en la actividad
correspondiente.

La frmula para calcularla es:


revisiones _en_ invertido _ tiempo
tarea _ s encontrado
TED
revisado _ objeto _ tamao
tarea _ s encontrado
Densidad
Rapidez de la revisin

Es una mtrica que se aplica slo a las revisiones, y
nos indica la cantidad de material cubierto por unidad
de tiempo.

La frmula para calcularla es:



Cabe decir que no es bueno ir demasiado rpido. Se
recomienda no sobrepasar los 300 LOC/hora.
Generalmente resulta interesante ver la correlacin de
esta mtrica con la Eficacia (Yield), y comprobar cmo a
medida que aumenta la rapidez decrece la eficacia.
revision invertido tamao
revisado objeto tamao
Rapidez
_ _
_ _

MTRICAS DERIVADAS
Poder de Eliminacin de Defectos (Defect
Removal Leverage)

Nos indica el ratio de eficiencia entre dos
actividades de deteccin de defectos. Dicho de
otro modo, permite ver cunto ms/menos eficiente
es una actividad con respecto otra.

La frmula para calcularla es:


-

2 _
1 _
PED
tarea PED
tarea PED

MTRICAS 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
estndares, fallas de productos, o defectos en su
manufactura.
Costos de prevencin
Costos de evaluacin
Costos de falla interna
Costos de falla externa
COSTOS DE CALIDAD
151
COSTOS DE PREVENCIN
Son los costos de todas las actividades
especficamente diseados para prevenir fallas de
calidad en productos o servicios
Revisin de nuevos productos
Planeacin de la calidad (manuales,
procedimientos, etc.)
Evaluacin de capacidad de proveedores
Esfuerzos de mejora a travs de trabajo en
equipo
Proyectos de mejora continua
Educacin 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 estndares de calidad y
requerimientos de desempeo.
COSTOS DE EVALUACIN
Inspecciones con el proveedor y en recibo
Pruebas e inspecciones en proceso y al
producto terminado
Auditorias al producto, proceso o servicio
Calibracin de equipos de prueba y medicin
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
realizacin del servicio.

Desperdicio (maculatura)
Retrabajos
Reinspeccin y repeticin de pruebas
Revisin de materiales no conformes
Reduccin 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, despus de la entrega del producto o durante
y despus de la realizacin del servicio.
Proceso de quejas y reclamaciones
Devoluciones del cliente
Garantas
Campaas por productos defectivos
EJEMPLO
155
COSTOS TOTALES DE CALIDAD
Es la suma de los costos de prevencin,
apreciacin, falla interna y falla externa
Los sistemas contables en general no
son capaces de identificar estos costos
Es muy difcil ir al detalle del costo de
calidad tal como un error de la secretaria
Planificacin de
la Calidad
PLANIFICACIN
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
Planificacin de la calidad.
Incluye dos aspectos centrales:
PLAN DE CALIDAD
Es el documento o conjunto de
documentos:
Que establecen los objetivos de calidad,
La especificacin de los procesos
operativos necesarios y
La disponibilidad de los recursos
apropiados para satisfacer tales objetivos,
para la elaboracin del producto que
ocupa a la organizacin.
PLAN SQA
Proporciona un mapa
para institucionalizar la
garanta de calidad del
software.
Sirve como plantilla para
actividades de SQA
instituidas para cada
proyecto de software.
SECCIONES
Documentacin
Gestin
Revisin y Auditora
Pruebas
Otros
SECCIONES
DOCUMENTACIN
Situacin 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,
jerarquas de
clases),
Documentos
tcnicos
(especificaciones,
planes de
prueba)
Documentos de
usuario (archivos
de ayuda)
GESTIN
SECCIONES
REVISIN Y AUDITORIA
Identifica las revisiones y auditoras que se van
a llevar a cabo por el equipo de ingeniera del
software, el grupo de SQA y el cliente.
Proporciona una visin general del enfoque de
cada revisin y auditora.
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 mtodos que soportan
actividades y tareas de SQA
Define un enfoque de gestin de contratos
Establece mtodos para reunir, salvaguardar y
mantener todos los registros
Identifica la formacin que se requiere para cumplir
las necesidades del plan
Define mtodos para identificar, evaluar, supervisar
y controlar riesgos.