Fundamentos de Pruebas de Software

Introduccin:
1.1.1 DEFINICIONES DE CALIDAD

Propiedad o conjunto de propiedades inherentes a una cosa, que

permiten apreciarla como igual, mejor o peor que las restantes de su especie
(Real Academia Espaola).

Aptitud o adecuacin al uso (Juran).

1.1.2. DEFINICIONES FORMALES DE CALIDAD.

Luis Andres Arnauda Sequera Define la norma ISO 9000 Conjunto de

normas y directrices de calidad que se deben llevar a cabo en un proceso.

Philip Crosby: Calidad es cumplimiento de requisitos.

Joseph Juran: Calidad es adecuacin al uso del cliente.

Armand V. Feigenbaum: Satisfaccin de las expectativas del cliente.

SIGNIFICADO DE LA CALIDAD SEGN EL CONTEXTO

Transcendental: Calidad como sinnimo de superioridad o excelencia. Es un
significado utilizado a menudo por los consumidores.
Basada en el producto: La calidad viene definida por la cantidad en la que
un atributo deseable est presente en un producto o servicio.
Basado en el usuario: La calidad viene determinada por lo que el consumidor
desea.
Basado en el valor: La calidad como relacin entre la utilidad o satisfaccin
con el producto o servicio y su precio.
Basado en la produccin: La calidad se define como conformidad a las
especificaciones determinadas para la manufactura o realizacin de un
producto o servicio.

1.1.4. DEFINICIN DE SOFTWARE

el software es un conjunto de programas, instrucciones y reglas
informticas que permiten ejecutar distintas
tareas en una
computadora.

CALIDAD DE SOFTWARE
LA CALIDAD COMO PROCESO.
La calidad del software es aquel proceso en donde se verifica que el
software o aplicacin cumpla con los requerimientos o necesidades del
cliente, integrando la velocidad de respuesta de la aplicacin, el sistema
de seguridad y confiabilidad.
Existen 3 puntos importantes de la definicin de calidad de software:

Los requerimientos del software son los fundamentos desde los que se
mide la calidad.

Los estndares especficos definen un conjunto de criterios de desarrollo

que guan la forma de aplicacin de la ingeniera de software.

Existen requerimientos implcitos que no se mencionan.

1.2.3.

LA CALIDAD COMO CARACTERSTICA

Segn ISO 9000: la calidad es el conjunto de caractersticas

de una entidad que le confieren su aptitud para satisfacer las
necesidades expresadas y las implcitas.
Segn Roger Preesman: Calidad se define como una caracterstica o
atributo de algo.

1.2.3.

EL PROCESO DE ANLISIS DE LA CALIDAD

1. Control de Calidad

El control de calidad comprende aquellas actividades realizadas en una

empresa u organizacin para aplicar los principios de calidad en las actividades
realizadas en la empresa.


Es la actividad mediante la cual una empresa determina si el producto
que elabora o el servicio que presta cumple o no, con las especificaciones
contenidas en la Norma de calidad especfica para tal producto o servicio.

El control de calidad se ocupa de garantizar el logro de los objetivos de

calidad del trabajo respecto a la realizacin del nivel de calidad previsto para la
produccin y sobre la reduccin de los costos de la calidad.

Conjunto de tcnicas y actividades de carcter operativo, utilizadas

para verificar los requerimientos relativos a la calidad del producto o
servicio.
1. Garanta de Calidad
A nivel General:
Evaluacin de la calidad
Control de calidad
Correcciones internas
Segn ISO:
Conjunto de acciones planificadas y sistemticas necesarias para proporcionar
la confianza adecuada de que un producto o servicio satisfar los
requerimientos dados sobre calidad.

Coste de Calidad
Son todos los costos acarreados en la bsqueda de la calidad o en las
actividades relacionadas con la obtencin de la calidad.
Costes de prevencin:

Costes de evaluacin:

Planificacin de la calidad
Revisiones
formales

Equipo de pruebas

Formacin

Inspeccin en el proceso y entre

procesos

Calibrado y mantenimiento del

equipo

tcnicas

Costes de fallos internos

Costes de fallos externos

Retrabajo (revisin)

Reparacin

Anlisis de la modalidades
de fallos

Pruebas

Resolucin de quejas
Devolucin
productos

sustitucin

Soporte de lnea de ayuda

Trabajo de garanta

de

1.3. LA TENDENCIA DE LA CALIDAD

tendencia hacia la Gestin Total de Calidad (GTC)

1. Kaizen
sistema de mejora continua en el proceso. El objetivo es desarrollar un
proceso que sea visible, repetible y mensurable.
En el marco empresarial, se traduce a que todos los miembros de una
organizacin estn comprometidos con la revisin constante de los
procesos y la mejora permanenete.
KAISEN est basado en las cinco S
SEIRE

Organizacin: Cada cosa en su lugar y un lugar para cada

cosa.

SEITON

Reducir bsquedas: Facilitar el movimiento de las cosas,

servicios y personas

SEISO

Limpieza: Cuando todo est limpio, todo est ordenado y

se simplifican los procedimientos.

SEIKETSU

Estandarizacin y simplificacin de procesos: Mantener el

orden, organizacin y limpieza en el ambiente y las
personas.

SHITSUKE

Disciplina y buenos hbitos de trabajo: Basados en el

respeto a las reglas y a las personas (compaeros de
trabajo y clientes)

Atarimae hinshitsu (Calidad Funcional)

Examina lo intangible que afecta al proceso y trabaja para optimizar su

impacto en el proceso.
Calidad Funcional: es la calidad que ya se le asigna al producto o servicio
mismo, si son autos... depende de la marca del auto para asignarle
inconscientemente una calidad.

Kansei
Se centra en el usuario del producto. Examinando la forma en que el
usuario aplica el producto, kansei conduce a la mejora en el producto
mismo y potencialmente al proceso que lo creo.
Las necesidades bsicas que permitirn definir la estructura general del
planteamiento Kansei son como sigue (Nagamachi, 1995):

Obtener y cuantificar la respuesta del usuario en trminos kansei

(valoracin psicosociolgica).

Identificar las caractersticas de diseo de un producto desde la

percepcin del usuario.

Implementar la herramienta a partir de los datos anteriores.

Ajustar el diseo del producto a los cambios sociales y a los que se

producen en las preferencias de los usuarios con el paso del
tiempo.

Miryoku Teki hinshitsu

Orientado a la gestin que busca la oportunidad en reas relacionadas que se
pueden identificar observando la utilizacin del producto en el mercado,
Calidad Emocional: es lo que te hace sentir el usar tal o cual producto o
servicio

1.4. LA GARANTIA DEL SOFTWARE

La garanta de calidad del software (SQA), comprende un conjunto
de tareas y acciones sistemticas y planificadas que permiten
asegurar la calidad del software.

Actividad

Plan
SQA
proyecto

Caractersticas

para

el

El plan debe involucrar:

Evaluaciones, Auditorias, revisiones, estndares que
se pueden aplicar al proyecto.
Procedimientos para informacin, seguimiento de
errores y realimentacin.
El grupo SQA debe
informacin necesaria.

adems

documentar

la

Caractersticas
Actividad

Proceso de software del

proyecto

Se determina el proceso y se realiza la revisin de la

descripcin del proceso para poder establecer los
ajustes de acuerdo a las polticas de la organizacin.

El grupo SQA se encarga de revisar, documentar y

Ajustes al proceso del verificar que se han hecho los ajustes al proceso.
software
El grupo SQA esta en constante revisin del proceso
Auditoria
de
los software e informa peridicamente los resultados al
productos de software
gestor del proyecto.

Documentacin
productos software

Se debe documentar todas las desviaciones

de encontradas a nivel:

De procesos

De estndares y

Tcnicos

Se realiza seguimiento a los requisitos que no se

Registro de ajustes a ajustan y se elaboran los informes respectivos.
requisitos e informes

1.5. POR QUE SON IMPORTANTES LOS ESTANDARES DE

CALIDAD?
Mejoramiento del Producto: Las empresas que quieren cumplir con los estndares
de calidad lo hacen para mejorar sus productos, de esta manera se mejora la
percepcin de sus servicios en el mercado.
Proteccin al comprador: los estndares pueden jugar un rol
importante porque proveen informacin precisa acerca de los
productos
Proteccin al negocio: En casos de que sea acusada la empresa
por negligencias los estndares pueden respaldar a la
organizacin, al adherirse voluntariamente a la certificacin
demuestra seriedad y confiabilidad ante el mercado.

Incrementa la Disciplina Profesional: La existencia de

estndares en el software ayuda a mejorar procesos internos y a
practicar de manera responsable la ingeniera de software.

ASEGURAMIENTO
ASOCIADAS

DE

SOFTWARE

TCNICAS

El aseguramiento de calidad del software es el conjunto de

actividades planificadas y sistemticas necesarias para aportar la
confianza adecuada en que el producto (software) satisfacer los
requisitos dados de calidad.

TAREAS PARA EL ASEGURAMIENTO DE LA CALIDAD DE

SOFTWARE
Participar en descripcin del proyecto de software.
Asegurar que las divergencias en el trabajo de software sean
documentadas de acuerdo a los estndares definidos.
Almacenar cualquier inconformidad y reportarla a la gerencia media.
Revisiones del software que se aplican durante cada paso del
desarrollo del mismo, de manera que puedan eliminar defectos cuanto
antes.
Gestin de configuraciones de software (control de la documentacin
del software y de los cambios realizados). El proceso de control de
cambios contribuye directamente a la calidad del software.
Mtricas de software para el control del proyecto.
Verificacin y validacin del software a lo largo del ciclo de vida
(Incluye las pruebas y los procesos de revisin e inspeccin).

TCNICAS ASOCIADAS AL
CALIDAD DEL SOFTWARE.

ASEGURAMIENTO

DE

Mtricas de software para el control del proyecto.

Verificacin y validacin del software a lo largo del ciclo de vida.
La gestin de la configuracin del software.

2.

MODELOS DE CALIDAD DE SOFTWARE

Conjunto de buenas prcticas para el ciclo de vida del software, enfocado en los
procesos de gestin y desarrollo de proyectos
Un modelo de calidad describe sus caractersticas y relaciones.

LA

A nivel proceso
CMMI (Capability maturity model integration)
Es un modelo para la mejora y evaluacin de procesos para el desarrollo,
mantenimiento y operacin de sistemas de software.
Proporciona una nica gua unificada para la mejora de mltiples
disciplinas tales como: Ingeniera de Sistemas (SE), Ingeniera del
Software, Desarrollo Integrado del Producto y del Proceso (IPPD) y
la Fuente proveedora (A).
Existen 2 enfoques:
(1) Continuo Hace hincapi en la capacidad de ciertas reas para
realizar sus actividades.
(2) Escalonado Hace especial nfasis en el grado de madurez de los
procesos (a semejanza del SW-CMM).
Ambos enfoques reconocen que las reas de proceso se pueden agrupar
en 4 categoras
(1) Gestin de Proyectos
(2) Gestin de Procesos
(3) Ingeniera
(4) Apoyo
ENFOQUE CONTINUO
Seleccionar adecuadamente las mejoras que hay que realizar para
conseguir los objetivos del negocio definidos por la organizacin.
Permitir un anlisis comparativo dentro de la organizacin y entre
diferentes organizaciones
Realizar comparaciones entre el CMMi y el modelo de evaluacin de la
capacidad de los procesos de software
Este Enfoque utiliza niveles de capacidad (para cada AP) para medir el
mejoramiento del proceso.
0 Incomplete Cuando un objetivo o ms no estn satisfechos
1 Performed Cuando satisface todos los objetivos del rea de proceso
2 Managed Cuando tiene la infraestructura base para apoyar el proceso
3 Defined Adaptado desde el conjunto de procesos de medida
4 Quantitatively Managed Controlado con tcnicas estadsticas y

cuantitativas
5 Optimizing Es mejora en variacin del proceso
..
Niveles de Capacidad del Enfoque Continuo de CMMI
(1) Process Management Las AP de Process Management son:
Organizational Process Focus (OPF)
Organizational Process Definition (OPD)
Organizational Training (OT)
Organizational Process Performance (OPP)
Organizational Innovation and Deployment (OID).
(2) Project Management Las AP de Project Management son:
Project Planning (PP)
Project Monitoring and Control (PMC)
Supplier Agreement Management (SAM)
Integrated Project Management (IPM)
Risk Management (RSKM)
Quantitative Project Management (QPM)
(3) Engineering Las AP de Engineering son:
Requirements Management (REQM)
Requirements Development (RD)
Technical Solution (TS)
Product Integration (PI)
Verification (VER)
Validation (VAL)
(4) SUPPORT Las AP de Support son:
Configuration Management (CM)
Process and Product Quality Assurance (PPQA)
Measurement and Analysis (M&A)
Organization Environment for Integration (OEI)
Decision Analysis and Resolution (DAR)
Causal Analysis and Resolution (CAR)
ENFOQUE ESCALONADO
Aquellas organizaciones que seleccionen el Enfoque Escalonado podrn:
1 - Proporcionar una secuencia contrastada de mejoras, que comienza con
prcticas de gestin bsica de proyectos e irn progresando por un camino
predefinido y probado de sucesivos niveles que servirn de base para el
siguiente nivel, teniendo como fin ltimo la optimizacin de todos y cada uno
de los procesos de la organizacin.

2- Permitir un anlisis comparativo dentro de la organizacin y entre diferentes

organizaciones al tener como punto de referencia los mismos niveles de
madurez.
3- Realizar una transposicin fcil desde el modelo SW-CMM al nuevo modelo
CMMi.

Hay 5 niveles de madurez. Cada nivel de madurez abarca un

conjunto de AP predefinidas.
Existen 5 niveles de madurez:
(1) Initial
(2) Managed
(3) Defined
(4) Quantitatively Managed
(5) Optimizing
NIVEL DE MADUREZ 1: INITIAL En este nivel los procesos son ad hoc. La
organizacin no provee un ambiente estable. El xito en estas organizaciones
depende de la competencia de la gente de la organizacin y no de la utilizacin de
procesos Las organizaciones de este nivel se caracterizan por abandonar los
procesos en momento de crisis y no son capaces de repetir sus xitos recientes.
(2)NIVEL DE MADUREZ 2: MANAGED En este nivel, una
organizacin ha cumplido todos los objetivos especficos y
genricos
de
las
AP
del
nivel
de
madurez.
Los proyectos de la organizacin aseguran que los requerimientos
son administrados y que los procesos son planeados, realizados,
medidos y controlados. En este nivel se administran los
requerimientos, procesos, productos y servicios.
(3)
(4)NIVEL DE MADUREZ 3: PERFORMED En este nivel, la empresa ha
cumplido con los objetivos de las AP asignadas a los niveles de
madurez 2 y 3. En este nivel, los procesos son caracterizados,
entendidos y descriptos en estndares, procedimientos,
herramientas y mtodos. Los procesos estndares de la
organizacin, lo cuales estn basados en el nivel de madurez 3,
son establecidos y mejorados. Estos procesos son usados para
establecer consistencia en la organizacin. Una distincin
importante entre el nivel de madurez 2 y 3 es el alcance de los
estndares,
las
descripciones
de
los
procesos
y
los
procedimientos.
(5)
(6)NIVEL DE MADUREZ 4: QUANTITATIVELY MANAGED En este nivel
de madurez, la organizacin ha cumplido con todos los objetivos
especficos de las AP asignadas en los niveles de madurez 2, 3 y 4.
Tambin ha cumplido con los objetivos genricos asignados en los
niveles de madurez 2 y 3. Los subprocesos son seleccionados de
manera que contribuyan al performance general de los procesos.

Estos subprocesos seleccionados son controlados a travs de

tcnicas estadsticas y cuantitativas. Los objetivos cuantitativos
son establecidos y usados como criterio en la administracin de
los procesos. Estos objetivos estn basados en las necesidades del
cliente, usuarios finales, organizacin e implementadores de
procesos. Una diferencia entre el nivel 3 y 4 de madurez radica
que en el nivel 4 los procesos son controlados de manera
cuantitativa mientras que en el nivel 3 se controlan de manera
cualitativa.
(7)
NIVEL DE MADUREZ 5: OPTIMIZING En este nivel de madurez, la
organizacin ha cumplido con los objetivos especficos de las AP
asignadas a los niveles de madurez 2, 3, 4 y 5. Tambin ha
cumplido con los objetivos genricos asignados a los niveles de
madurez 2, 3 y 4. Los procesos son mejoras de manera continua
basados en un entendimiento cuantitativo de los procesos. El nivel
de madurez 5 est enfocado respecto del proceso de
mejoramiento continuo a travs de nuevos mejoramientos
tcnicos. Los objetivos de mejoramiento cuantitativo de los
procesos son establecidos y revisados de manera continua segn
los objetivos de negocio de la organizacin. Estos objetivos de
mejoramiento son utilizados como criterio en el manejo de
mejoramiento de procesos.
CMM
CMM es un modelo que estudia los procesos de desarrollo de software de una organizacin y
produce una evaluacin de la madurez de la organizacin segn una escala de 5 niveles. La madurez
de un proceso es un indicador de la capacidad para construir un software de calidad.

Nivel 1: Inicial (Initial) Este nivel no provee un ambiente de

desarrollo y mantenimiento de software.
Nivel 2: Repetible (Repeatable) En este nivel se establecen
polticas para administrar un proyecto de software y
procedimientos para implementar las polticas establecidas. Se
realizan revisiones para detectar si el proceso est funcionando
correctamente.
Nivel 3: Definido (Defined) En este nivel se tiene un proceso de
software estndar en la organizacin para desarrollar y mantener
el software. Este est documentado y es implementado a lo largo
de toda la organizacin en distintos proyectos.
Nivel 4: Administrado (Managed) Este nivel plantea la calidad
y productividad respecto de las actividades del proceso de
software. El nivel 4 podra llamarse cuantitativo ya que en l
cualquier decisin es respaldada por una base cuantitativa.
Nivel 5: Optimizado (Optimized) La empresa est en un
proceso de mejoramiento continuo. El equipo es capaz de
anticiparse a cualquier problema que se avecine, mejorando en

forma continua y adaptndose a los cambios. Tiene como objetivo

prevenir.
Las Areas claves de Procesos por Nivel son:
Nivel 2: Repetible
o Administracin de la Configuracin del Software (Software
Configuration Management)
o Aseguramiento de la Calidad del Software (Software Quality
Assurance)
o Seguimiento del Proyecto de Software (Software Project Tracking and
Oversight)
o Planificacin del Proyecto de Software (Software Project Planning)
o Administracin de Requerimientos (Requirements Management)
o Administracin de Subcontratos de Software (Software Subcontract
Management)
Nivel 3: Definido
o Revisiones (Peer Reviews)
o Coordinacin de los Grupos (Intergroup Coordination)
o Ingeniera del Producto de Software (Software Product Engineering)
o Administracin del Software Integrado (Integrated Software
Management)
o Programa de Entrenamiento (Training Program)
o Definicin de los Procesos de la Organizacin (Organization Process
Definition)
o Enfoque de los Procesos de la Organizacin (Organization Process
Focus)
Nivel 4: Administrado
o Administracin de la Calidad de Software (Software Quality
Management)
o Administracin de los Procesos Cuantitativos (Quantitative Process
Management)
Nivel 5: Optimizado
o Administracin de los Cambios de Procesos (Process Change
Management)
o Administracin de los Cambios Tecnolgicos (Technology Change
Management)
o Prevencin de Defectos (Defect Prevention)
TickIT

:: programa TickIT como una respuesta a las quejas emitidas por

las organizaciones dedicadas a la elaboracin de software con
respecto a la calidad y consistencia de las evaluaciones para la
certificacin ante la norma ISO 9001:2000::::
Los objetivos principales de TickIT son, adems de desarrollar un
sistema de certificacin aceptable en el mercado, estimular a los
desarrolladores de software a implementar sistemas de calidad,
dando la direccin y guas necesarias para tal efecto.
Pieza A: Introduccin a TickIT y al proceso de la certificacin
Parte B: Direccin para los clientes, esto describe las ediciones
referentes a la certificacin del sistema de gerencia de la calidad
en el campo del software del punto de vista del cliente que est
iniciando un proyecto de desarrollo, y explica cmo el cliente
puede contribuir a la calidad de los productos y de los servicios
entregados.
Parte C: Direccin para los proveedores, esto presenta la
informacin y la direccin al software y al servicio del software que
proporcionan las organizaciones
Parte D: Direccin para los auditores
Parte E: Requisitos del sistema de gerencia de la calidad del
software - perspectiva de los estndares,
Parte F: Requisitos del sistema de gerencia de la calidad del
software - perspectiva de proceso,
BOOTSTRAP

La metodologa BOOTSTRAP engloba tanto la evaluacin para

establecer el diagnstico de un proceso para desarrollo de
software (el cual incluye a la planeacin, los mtodos y la
capacidad de ingeniera, las herramientas y la tecnologa), as
como la creacin de un plan de accin que defina los pasos, los
detalles de la implantacin y los marcos temporales para que la
organizacin aumente su capacidad de entrega de productos y
servicios de calidad. De acuerdo con los objetivos de la
metodologa BOOTSTRAP son:
Proporcionar soporte para la evaluacin de la capacidad de los
procesos utilizando un conjunto de prcticas de Ingeniera del Software.
Incluir estndares de Ingeniera del Software reconocidos
internacionalmente como fuentes para la identificacin de las prcticas a
considerar.

Dar soporte a la evaluacin, indicando cmo el estndar de

referencia ha sido aplicado en la organizacin evaluada.
Asegurar la fiabilidad y capacidad de repeticin de la evaluacin.
Identificar las fortalezas y debilidades de los procesos de la
organizacin evaluada.
Dar soporte a la creacin y aplicacin de un plan de mejora que
genere resultados aceptables y fiables, de forma que las acciones del
plan de mejora permitan alcanzar los objetivos de la organizacin.
Ayudar a incrementar la eficacia de los procesos poniendo en
prctica los requisitos del estndar en la organizacin.
BOOTSTRAP al ser una metodologa de evaluacin y mejora de procesos
de software se basa en evaluar el nivel de capacidad y de productividad
de una Unidad de Desarrollo Software
El modelo de proceso de software utilizado por BOOTSTRAP es un
modelo cclico,
BOOTSTRAP hace uso de cinco niveles de madurez para indicar el nivel
en el que se encuentra la organizacin, por lo que emplea diferentes
escalas para medir las fortalezas y debilidades y marcar las pautas de
mejora
Personal Software Process (PSP)
El proceso personal de software, es un conjunto de prcticas
disciplinadas para la gestin del tiempo y mejora de la productividad
personal de los programadores o ingenieros de software, en tareas de
desarrollo y mantenimiento de sistemas, mediante el seguimiento del
desempeo predicho frente al desempeo real.
OBJETIVOS
PSP pretende formar ingenieros de software con mtodos disciplinados
para mejorar su desarrollo personal de software. PSP le ayuda a los
desarrolladores a:

Mejorar sus habilidades de estimacin y planeacin.

Hacer compromisos que se puedan cumplir.

Administrar la calidad de sus procesos.


Reducir la cantidad de defectos en sus productos.
PROCESO
La entrada de PSP son los requerimientos; el documento de
requerimientos es completado y entregado al ingeniero.
PSP0, PSP0.1 (Introduce la disciplina y la medicin al proceso)
PSP1, PSP1.1 (Introduce estimacin y planeacin)
PSP2, PSP2.1 (Introduce manejo de calidad y diseo)
Los niveles son:

PSP 0:

Proceso actual.

Registro de tiempos.

Registro de defectos.

PSP 0.1 :

Estndares de cdigo.

Medicin de tamao.

PSP 1 - Inicial:

Estimacin de tamao.

Reporte de pruebas.

PSP 1.1:

Calendario de planeacin de tareas.

PSP 2 - Repetible:

Revisin de diseo y cdigo.

PSP 2.1:

Plantillas de Diseo.

(TSP).

LA IMPORTANCIA DE LOS DATOS EN PSP

La recoleccin de datos para PSP es soportada por cuatro elementos
importantes:

Guiones.

Mtricas.

Estndares.

Formatos.

En PSP hay cuatro mediciones esenciales:

Tamao El tamao de una parte del producto, medido en lneas

de cdigo (LOC) o piezas de software equivalentes (proxies) que
facilitan la medicin.

Esfuerzo El tiempo requerido para cumplir una tarea, se suele

medir en minutos.

Calidad La cantidad de defectos en el producto.

Agenda Una medicin de progresin del proyecto, comparacin
de lo planeado contra las fechas de cumplimiento actuales.

La aplicacin de estndares al proceso puede asegurar que los datos

sean precisos y consistentes. Los datos son registrados en formatos,
frecuentemente son registrados en aplicaciones para medir PSP.
Los desarrolladores de software usan otras medidas, que se derivan de
las esenciales, para entender su desempeo. Entre las medidas
derivadas estn:

Estimacin de precisin (tamao/tiempo).

Prediccin de intervalos (tamao/tiempo).

Tiempo en la fase de distribucin.

Distribucin de la inyeccin de defectos.

Distribucin de la remocin de defectos.

Productividad.

Porcentaje de reuso.

ndice de costo de desempeo.

Valor planeado.

Valor ganado.

Valor ganado predicho.

Densidad de defectos.

Densidad de defectos por fase.

Tasa de remocin de defectos por fase.

Apalancamiento de remocin de defectos.

Tasas de revisin.

Rendimiento (yield) de proceso.

Rendimiento (yield) de la fase.

Falla de costo de calidad (COQ).

Evaluacin (appraisal) COQ.

Tasa evaluacin/fallos COQ

PLANEACIN Y SEGUIMIENTO
El registro de tiempos, defectos, y tamaos es fundamental para planear
y realizar seguimientos a los proyectos de PSP, los datos histricos son
usados para mejorar la precisin estimacin.
PSP usa el mtodo PROBE para mejorar las habilidades de estimacin de
los desarrolladores para obtener ms planeaciones ms precisas. Para

hacer el seguimiento del proyecto PSP usa el mtodo del valor ganado
(EV).
PSP tambin usa tcnicas estadsticas, tales como correlacin, regresin
lineal, y desviacin estndar, para traducir datos en informacin til
para mejorar la estimacin, planeacin y calidad. Las frmulas
estadsticas son calculadas por las herramientas para PSP.
CALIDAD
Producir software de alta calidad es la meta de PSP, y la calidad es
medida en trminos de defectos. Para PSP, un proceso de calidad
debera producir software de pocos defectos que cumple con las
necesidades del usuario.
Segn PSP es ms econmico y efectivo remover defectos tan pronto
como sea posible. Se exhorta a los ingenieros de software a realizar
revisiones personales para cada fase del desarrollo. Por lo tanto PSP
incluye dos fases de revisin:

Revisin de diseo.

Revisin de cdigo.

PSP y otras metodologas

PSP es un proceso personal que puede ser adaptado a las necesidades
individuales de cada desarrollador. PSP no es especfico para para un lenguaje
de programacin o metodologa de diseo; por lo tanto puede usarse con
diferentes metodologas inclusive desarrollo gil de software

desarrollo gil es considerada una metodologa adaptiva, pero a pesar

de sus diferencias, TSP/PSP y desarrollo gil comparten varios conceptos
aproximaciones particularmente en cuanto a la organizacin del
equipo. Con ambos es posible:

Definir sus metas y estndares.

Estimar y agendar el trabajo.

Determinar agendas realistas y alcanzables.

Realizar planes y procesos de mejora.

Desarrollo gil y TSP/PSP comparten la idea que los miembros del equipo
se responsabilicen por su propio trabajo y trabajen juntos para acordar
un plan realista, crear un ambiente de confianza y responsabilidad. Sin
embargo, el TSP/PSP se diferencia del desarrollo gil en su nfasis en la
documentacin del proceso y el uso de datos para predecir y definir la
agenda del proyecto.
Frente a UML, PSP obtiene la informacin de la interaccin dinmica y
esttica, interna y externa capturando datos con formatos que se
asemejan a los formatos de los de casos de uso, los diagramas de
secuencias, y de clases. Basado en un diagrama UML se puede obtener
la informacin base para crear ciertos formatos de PSP.
El Team Software Process (TSP)
Es un proceso de desarrollo para equipos de ingenieros basado en CMMi.
En combinacin con el Personal Software Process (PSP), el llamado Team
Software Process (TSP) proporciona un marco de trabajo de procesos
definidos que est diseado para ayudarle a equipos de gerentes e
ingenieros a organizar y producir proyectos de software de gran escala,
que tengan tamaos mayores a varios miles de lneas de cdigo. El
objetivo del TSP es mejorar los niveles de calidad y productividad de un
proyecto de desarrollo de software de un equipo, con el fin de ayudarlos
a alcanzar los acuerdos de costos y tiempos en dicho desarrollo.
A diferencia de otros mtodos
Mejora el desempeo tanto de equipos como individuos.
Es disciplinado y gil.
Provee beneficios inmediatos y medibles.
Acelera las iniciativas de mejora de procesos organizacionales.
Como ya se mencion TSP es una metodologa para dirigir el trabajo de
mejora y desarrollo de software adems de que establece un entorno
donde el trabajo efectivo de equipo es normal y natural.
PAS
Actividad
Descripcin
O

Establecer
productos y
objetivos del

Revisar el proceso de lanzamiento e incorporar los

miembros del equipo.
Tratar los objetivos del proyecto con la direccin y

negocio

Asignar roles y
objetivos del
equipo

responder preguntas

Seleccionar los roles del equipo

Definir y documentar los objetivos del equipo

Producir un diseo conceptual del sistema

3

Determinar una
estrategia de
desarrollo

Determinar la estrategia
productos a realizar

de

desarrollo

los

Definir el proceso de desarrollo a utilizar

Producir el proceso y soportar los planes

Desarrollar el
plan general

Desarrollar el
plan de calidad

Desarrollar las estimaciones del tamao y el plan

general

Desarrollar el plan de calidad

Asignacin de trabajo a los miembros del equipo

6

Construir un
Planear las prximas etapas para cada miembro del
plan balanceado
equipo
Armar un plan balanceado para el equipo y para
cada miembro del equipo

Identificar y evaluar los riesgos del proyecto

Anlisis del
riesgo del
proyecto

Preparacin del
informe de
lanzamiento

Revisin de la
direccin

Definir las responsabilidades y puntos de control de

la evaluacin del riesgo.

Preparar un
direccin

informe

de

lanzamiento

para

Revisar las actividades de lanzamiento

planeamientos del proyecto con la direccin.

la

los

Discutir los riesgos del proyecto, responsabilidades y

acciones
planeadas
Practical Software Measurement (PSM)
Los procesos de medicin efectivos ayudan a los grupos de software a
entender sus capacidades y a desarrollar productos / servicios. Las
mediciones permiten detectar las tendencias, anticipar los problemas e
identificar las tendencias que pueden traer una consecuencia en los
procesos. Adems, provee un mejor control de costos, una reduccin de
riesgos, una mejora de la calidad y asegura que se cumplan los objetivos
del negocio
1) Administracin del proyecto: permite crear planes y seguir el estado /
progreso de los productos.
(2) Administracin del proceso: permite asegurar que los procesos de la
organizacin se realizan de manera correcta y son mejorados.
(3) Ingeniera del Producto: tiene como objetivo asegurar la aceptacin
del cliente y la satisfaccin del producto.
.Las 4 responsabilidades de la administracin del proceso de software
son:
(1) Definir el proceso

(2) Medir el proceso

(3) Controlar el proceso (asegura que la variabilidad sea estable y que
los resultados sean predecibles)
(4) Mejorar el proceso.
Los objetivos principales asociados a la medicin del proceso son:
(1) Recopilar datos que miden el performance de cada proceso
(2) Analizar el performance de cada proceso
(3) Conservar y usar los datos, analizarlos, emitir informes e identificar
oportunidades
de
mejora.
Las acciones necesarias para establecer y mantener el control de un
proceso de software son:
(1) Determinar si el proceso est o no bajo control
(2) Identificar las variaciones de performance que son provocadas por
anomalas del proceso
(3) Eliminar el origen de las causas y estabilizar el proceso.
Los objetivos principales asociados al mejoramiento de procesos son:
(1) Entender las caractersticas de los actuales procesos y los factores
que afectan la capacidad del proceso
(2) Planear, justificar e implementar acciones que modificarn los
procesos y permitirn mejorar las necesidades del negocio
(3) Evaluar el impacto y los beneficios obtenidos; y compararlos con los
costos de los cambios realizados en los procesos.
1- Definir el Proceso: Para ello, se debe identificar cada elemento del
proceso y entender la operacin del proceso.
2- Planificar las mediciones: La planificacin de las mediciones est
basada en entender el proceso de software definido.
3- Ejecutar el proceso de software Los procesos son ejecutados en
la organizacin de software.
4- Aplicar las mediciones Se pone en uso las mediciones que se
obtuvieron mientras se ejecutaba el proceso de software.
5- Controlar el proceso Si las mediciones del producto o atributos
del performance indican que el proceso vara de manera inesperada, se
realizarn ciertas acciones para eliminar las causas, se estabilizar la
variabilidad y, si es apropiado, el proceso volver a su nivel normal de
performance.

6- Mejorar el proceso Una vez que las mediciones indican que el

proceso llega a una normalidad, los datos de performance del proceso
pueden ser usados para las futuras acciones de cambiar el nivel de
performance.
Las 5 perspectivas de un proceso de medicin son:
(1) Performance que produce actualmente el proceso respecto de los
atributos medibles de calidad, cantidad, costo y tiempo.
(2) Estabilidad determinar el comportamiento del proceso
(3) Conformidad determinar si las fallas del proceso estn dentro del
rango requerido para el xito del negocio
(4) Capacidad determinar si el proceso es capaz de entregar
productos que se ajustan a los requerimientos
(5) Mejoramiento e inversin mejorar el performance del proceso y
reducir
la
variabilidad.
Los principales objetivos asociados a la medicin del proceso son:
(1) Recopilar datos que miden el performance de cada proceso
(2) Analizar el performance de cada proceso
(3) Conservar y usar los datos, analizarlos, emitir informes e identificar
oportunidades de mejora.
El Modelo de un Plan de Implementacin de Medicin contiene la
siguiente informacin:
Ttulo
1. Objetivo
2. Descripcin - Resea - Objetivos - Alcance
3. Implementacin - Actividades, productos y tareas - Resultados Recursos - Responsabilidades - Medicin y monitoreo - Suposiciones Manejo del Riesgo
4. Operacin
2.1.8.
SIX SIGMA
Six Sigma es una filosofa de calidad basada en la asignacin de metas
alcanzables a corto plazo enfocadas a objetivos a largo plazo. Utiliza las
metas y los objetivos del cliente para manejar la mejora continua a
todos los niveles en cualquier empresa.
PROPSITO DE SIX SIGMA
Tiene el objetivo de desarrollar procesos, productos y/o servicios
eficientes y minimizar los defectos asociados hasta un valor objetivo de
excelencia para lograr la satisfaccin del cliente con productos
novedosos a un precio competitivo.
ESTRUCTURA Y DISEO DE SIX SIGMA

Los esfuerzos de Six Sigma se dirigen a tres reas principales:

Mejorar la satisfaccin del cliente
Reducir el tiempo del ciclo
Reducir los defectos

2.2 A nivel proceso

2.2.1.Gilb
El modelo de Gilb plantea la creacin de una especificacin de requisitos
de calidad para cada proyecto que deben escribir conjuntamente el
usuario y el analista. Es un modelo que permite determinar una lista de
caractersticas que definen la calidad de la aplicacin.
Puede ser de 2 tipos: Originales y de modelos tradicionales.
2.2.2. Modelo GQM
El modelo GQM (objetivo-pregunta-mtrica /goal question - metric) de
Basili y Rombach (1998) es una propuesta de objetivos / metas
orientado a la definicin de modelos de calidad. Se propone el
paradigma GQM para evaluar la calidad de cada proyecto.
Consta de 3 etapas:
1- Listar los objetivos principales del desarrollo y mantenimiento del
proyecto
2- Para cada objetivo, se deben obtener las preguntas que deben
contestarse para saber si se estn cumpliendo los objetivos
3- Decidir qu medir para poder contestar las preguntas de manera
adecuada, es decir, desarrollar un conjunto de mtricas que ayuden a
responder la pregunta.

2.2.3. McCall
Se focaliza en el producto final, identificando atributos claves desde el
punto de vista del usuario.
Estos atributos se denominan factores de calidad y son normalmente
atributos externos, pero tambin se incluyen algunos atributos
posiblemente internos.
FURPS
Modelo FURPS El modelo FURPS propuesto por Robert Grady y Heweltt
Packard Co (HP) cuenta con 5 caractersticas de calidad del software:
(1) Funcionalidad
(2) Facilidad de uso
(3) Confiabilidad
(4) Performance
(5) Facilidad de soporte
Adems plantea 2 categoras de requerimientos, las cuales son:
1- Requerimientos funcionales (F): especifican funciones que el
sistema debe ser capaz de realizar, sin tomar restricciones fsicas a
consideracin, y se definen a travs de las entradas y salidas esperadas.
2- Requerimientos no funcionales (URPS): Usability (Facilidad de
uso), Reliability (Confiabilidad), Performance y Supportability (Facilidad
de soporte.
Modelo de Boehm
El segundo modelo de calidad ms conocido es el presentado por Barry
Boehm en 1978 este modelo introduce caractersticas de alto nivel,
caractersticas de nivel intermedio y caractersticas primitivas, cada una
de las cuales contribuye al nivel general de calidad
Comparacin de modelos McCall-Boehm
Aunque parezcan similares, la diferencia est en que McCall focaliza en
medidas precisas de alto nivel, mientras que Boehm presenta un rango
ms amplio de caractersticas primarias la mantenibilidad est ms
desarrollada en Boehm.
Modelo SATC (Software Assurance Technology Center)

SATC desarroll un modelo dinmico que permite la produccin de varios

proyectos en desarrollo. Los datos del proyecto son usados para realizar
proyecciones acerca de los riesgos y puntos de control del proyecto.
A partir del concepto de calidad del software, se deducen 4 metas u
objetivos:
1- Calidad de los Requerimientos:
2- 2- Calidad del Producto
3- 3- Efectividad de la implementacin:
4- 4- Efectividad de la prueba
2.2.6. Modelo de Dromey
El modelo de Dromey tiene el propsito de trabajar con una estructura
que permite construir y utilizar un modelo de calidad prctico para
evaluar las etapas de Determinacin de los requerimientos, diseo e
implementacin.
Dromey propone 3 modelos para cada etapa del proceso de desarrollo:
(1) Modelo de requerimientos
(2) Modelo de diseo
(3) Modelo de calidad de la implementacin.
2.2.7. Modelo C-QM C-QM
Provee un modelo de calidad comprensivo que puede ser aplicado
efectivamente para evaluar diversos aspectos de la calidad del software.
Este modelo consiste de factores de calidad, criterios y mtricas. La
estructura de C-QM tiene 3 capas: Factor, Criterio y Mtrica
Metodologa SQAE (Software Quality Assessment Exercise)
Esta metodologa fue desarrollada por MITRE Corporation y se basa en el
concepto de establecer una jerarqua en la cual los conceptos
relacionados al riesgo del ciclo de vida estn compuestos de factores
tangibles y medibles. Es una metodologa que permite cuantificar los
riesgos asociados al software.
2.2.8. WebQEM
WebQEM puede ser usada para evaluar diversos dominios de aplicacin
de acuerdo a los distintos puntos de vista y objetivos de evaluacin. La
definicin y la especificacin de los requerimientos de calidad son
actividades esenciales en el proceso de evaluacin. Una de las metas
principales de la evaluacin y comparacin de calidad de una Web,
radica en comprender el grado de cumplimiento de un conjunto de

caractersticas y subcaractersticas con respecto a los requerimientos de

calidad establecidos.
Las caractersticas de calidad planteadas son:
(1) Facilidad de Uso
(2) Funcionalidad
(3) Confiabilidad
(4) Eficiencia.
2.2.9. Modelos ad-hoc

3.

LA CALIDAD EN EL CICLO DE VIDA DEL

SOFTWARE
En ISO 9126 se reconocen seis factores de calidad que se pueden considerar tanto
internos como externos funcionalidad confiabilidad eficiencia usabilidad
mantenibilidad portabilidad

3.1. Caractersticas de calidad de uso

Eficacia productividad seguridad satisfaccin
Subcaractersticas de calidad

Subcaractersticas de funcionalidad
Subcaractersticas de confiabilidad
Caractersticas de calidad de uso

1. QU ES LA VERIFICACIN Y VALIDACIN DE
SOFTWARE?

Los objetivos de las actividades de verificacin y validacin son valorar y

mejorar la calidad de los productos del trabajo generados durante el
desarrollo y modificacin del software.
Hay dos tipos de verificacin: formal y del ciclo de vida. Esta ltima
consiste en el proceso de determinar el grado de los productos de
trabajo de una fase dada del ciclo de desarrollo cumplen con las
especificaciones establecidas durante las fases previas. La verificacin
formal es una rigurosa demostracin matemtica de la concordancia del
cdigo fuente con sus especificaciones.
La validacin es la evaluacin del software al final del proceso de
desarrollo del software para determinar su conformidad con los
requisitos IEEE.

VERIFICACIN

La verificacin se enfoca ms al proceso de evaluacin del sistema o

componentes ya que permite determinar si los productos de una
determinada fase del desarrollo satisfacen las condiciones impuestas en
el inicio de la etapa.

VALIDACIN
La validacin tambin es una evaluacin del sistema o de componentes,
solo que es en el transcurso o al final del proceso del desarrollo, donde
se determina si cumple con lo especificado.

OBJETIVOS Y RESTRICIONES
Este procedimiento tiene como finalidad entregar los pasos a seguir para
la aplicacin correcta de las estrategias y pruebas necesarias en el
sistema presente.
Las Fases en las que se realizarn las pruebas son:
1. Planificacin de las pruebas: Identificar los requisitos para las
pruebas. Desarrollar la estrategia de pruebas. Identificar los recursos
necesarios para realizar las pruebas. Generar el Plan de pruebas.
2. Diseo de las pruebas: Desarrollo de las pruebas. Identificar y
describir los casos de prueba.
3. Implementacin de las pruebas: Establecer el entorno de prueba.
Desarrollar las clases de prueba, los componentes de prueba y los datos
de prueba.
4. Ejecucin de las pruebas: Ejecutar los casos de prueba. Evaluar la
ejecucin del proceso de prueba. Verificar los resultados. Investigar los
resultados no esperados. Registrar los defectos.
5. Evaluacin de las pruebas: Evaluar la cobertura de los casos de
prueba. Evaluar la cobertura del cdigo. Analizar los defectos.
Determinar si se han alcanzado los criterios de las pruebas. Crear los
informes de evaluacin de las pruebas

PLANIFICACION
Anlisis de requisitos (Planificacin)

En esta fase se inicia la elaboracin del modelo jerrquico de requisitos

de prueba partiendo de los procesos funcionales que soporta el producto
o activo de software a evaluar.
Diseo del plan de pruebas (Preparacin)
En esta fase se identifica, acuerda y especifican los atributos y
caractersticas de calidad que se van a probar.
Ejecucin
En esta fase se ejecutarn los casos de prueba anteriormente diseados
de forma manual. Hay que seguir al detalle el guin establecido dejando
cierta libertad al tester para detectar situaciones anmalas no
contempladas.
Gestin de Incidencias (Defectos)
La gestin de incidencias es una parte implcita de la fase de ejecucin,
pero que al tener una alta importancia en las pruebas funcionales,
diferenciamos como una etapa independiente.
METRICAS Y MEDICIONES
Las mtricas son un buen medio para entender, monitorear,
controlar, predecir y probar el desarrollo de software y los
proyectos de mantenimiento.
En general, la medicin persigue 3 objetivos: ayudarnos a
entender qu ocurre durante el desarrollo, permitirnos controlar lo
que ocurre en nuestros proyectos y mejorar procesos y productos.

METRICAS DE SOFTWARE
Las mtricas del Software comprenden
actividades diversas, estas son algunas:

Aseguramiento y control de calidad

Modelos de fiabilidad
Modelos y evaluacin de ejecucin
Modelos y medidas de productividad

PROCESO DE MEDICION

un

amplio

rango

de

 FORMULACIN: La obtencin de medidas y mtricas del

software apropiadas para la representacin de software en
cuestin.
COLECCIN: El mecanismo empleado para acumular datos
necesarios para obtener las mtricas formuladas.
ANLISIS: El clculo de las mtricas y la aplicacin de
herramientas matemticas.
INTERPRETACIN: La evaluacin de los resultados de las
mtricas en un esfuerzo por conseguir una visin interna de la
calidad de la representacin.
REALIMENTACIN:
Recomendaciones
obtenidas
de
la
interpretacin de mtricas tcnicas trasmitidas al equipo de
software.
CLASIFICACIN DE LAS METRICAS DE SOFTWARE
MTRICAS DE COMPLEJIDAD: Son todas las mtricas de
software que definen de una u otra forma la medicin de la
complejidad; Tales como volumen, tamao, anidaciones, costo
(estimacin), agregacin, configuracin, y flujo.
MTRICAS DE CALIDAD: Son todas las mtricas de software
que definen de una u otra forma la calidad del software, Tales
como exactitud, estructuracin o modularidad, pruebas,
mantenimiento,
reusabilidad,
cohesin
del
mdulo,
acoplamiento del mdulo, etc. Estas son los puntos crticos en
el diseo, codificacin, pruebas y mantenimiento.
MTRICAS DE COMPETENCIA: Son todas las mtricas que
intentan valorar o medir las actividades de productividad de
los programadores o practicantes con respecto a su certeza,
rapidez, eficiencia y competencia.
MTRICAS DE DESEMPEO: Corresponden a las mtricas
que miden la conducta de mdulos y sistemas de un software,
bajo la supervisin del sistema operativo o hardware.
Generalmente tienen que ver con la eficiencia de ejecucin,
tiempo,
almacenamiento,
complejidad
de
algoritmos
computacionales, etc.
MTRICAS DEL SOFTWARE
A. MTRICAS TCNICAS: Se centran en las caractersticas de
software. Mide la estructura del sistema, el cmo est hecho.

B. MTRICAS DE CALIDAD: proporcionan una indicacin de cmo

se ajusta el software a los requisitos implcitos y explcitos del
cliente. Es decir cmo voy a medir para que mi sistema se adapte a
los requisitos que me pide el cliente.

C. MTRICAS DE PRODUCTIVIDAD: Se centran en el rendimiento

del proceso de la ingeniera del software. Es decir que tan
productivo va a ser el software que voy a disear.

D. MTRICAS ORIENTADAS A LA PERSONA: Proporcionan

medidas e informacin sobre la forma que la gente desarrolla el
software de computadoras y sobre todo el punto de vista humano
de la efectividad de las herramientas y mtodos.

E. MTRICAS ORIENTADAS AL TAMAO: Es para saber en qu

tiempo voy a terminar el software y cuantas personas voy a
necesitar.

F. MTRICAS ORIENTADAS A LA FUNCIN: Son medidas

indirectas del software y del proceso por el cual se desarrolla. En
lugar de calcularlas las LDC, las mtricas orientadas a la funcin se
centran en la funcionalidad o utilidad del programa.
DIFERENTES ENFOQUES DE MTRICAS
SIMPLE Y FCIL DE CALCULAR: debera ser relativamente
fcil de aprender a obtener la mtrica y su clculo no obligara
a un esfuerzo o a una cantidad de tiempo inusuales.
EMPRICA E INTUITIVAMENTE PERSUASIVA: la mtrica
debera satisfacer las nociones intuitivas del ingeniero de
software sobre el atributo del producto en cuestin.

 CONSISTENTE EN EL EMPLEO DE UNIDADES Y

TAMAOS: el clculo matemtico de la mtrica debera
utilizar medidas que no lleven a extraas combinaciones de
unidades.
INDEPENDIENTE DEL LENGUAJE DE PROGRAMACIN: las
mtricas deberan apoyarse en el modelo de anlisis, modelo
de diseo o en la propia estructura del programa. No deberan
depender de los caprichos de la sintaxis o semntica del
lenguaje de programacin.
UN MECANISMO EFICAZ PARA LA REALIMENTACIN DE
CALIDAD: la mtrica debera suministrar al desarrollador de
software informacin que le lleve a un producto final de
superior calidad. No obstante que la mayora de las mtricas
de software compensan las caractersticas anteriores, algunas
de las mtricas usualmente empleadas no cumplen una o dos
caractersticas.
V&V EN EL PROCESO DE DESARROLLO DE SOFTWARE
EL PROCESO V & V
Es el proceso de todo un ciclo vital, la V & V debe aplicarse en cada
etapa del software. Tiene dos objetivos principales.
El descubrimiento de defectos en el sistema.
La evaluacin de si el sistema es til y utilizable en una
situacin operacional o no.
. METAS DE LA V&V
La verificacin y la validacin deberan establecer la confianza de que el
software es adecuado al propsito
CONFIANZA DE LA V&V

Depende del propsito del sistema, las expectativas del usuario y el

entorno de marketing.
7.3.1. FUNCIN DEL SOFTWARE.
El nivel de confianza depende de lo crtico que es el sistema
para una organizacin.

7.3.2. EXPECTATIVAS DEL USUARIO.

Los usuarios pueden tener bajas expectativas para ciertas
clases de software.
7.3.3. ENTORNO DE MARKETING.
Introducir un producto en el mercado pronto puede ser ms
importante que encontrar defectos en el programa
VERIFICACIN DINMICA Y ESTTICA

PLANIFICACIN DE V &V
Se requiere una cuidadosa planificacin para sacar el mximo
de los procesos de inspeccin y pruebas. La planificacin
debera comenzar pronto en el proceso de desarrollo.
El plan debera identificar el balance entre la verificacin
esttica y las pruebas.
La planificacin trata de definir estndares para el proceso
de prueba en lugar de describir pruebas de productos.
V-MODELO
Es a proceso del desarrollo del software cul se puede presumir para ser
la extensin del modelo de la cascada. En vez de la mudanza abajo de

una manera linear, los pasos de proceso estn doblados hacia arriba
despus de codificacin fase, formar la forma de V tpica. El V-Modelo
demuestra las relaciones entre cada fase del ciclo vital del desarrollo y
su fase asociada de prueba.
FASE DE LA VERIFICACIN
ANLISIS DE REQUISITOS
En esta fase, los requisitos del sistema propuesto son recogidos
analizando las necesidades de los usuarios.
DISEO DEL SISTEMA
Los tcnicos analizan y entienden el negocio del sistema propuesto
estudiando el documento de las exigencias del consumidor.
DISEO DE LA ARQUITECTURA
Esta fase se puede tambin llamar como diseo de alto nivel. La lnea de
fondo en seleccionar la arquitectura es que debe realizar todo que
consista en tpicamente la lista de mdulos, breve funcionalidad de cada
mdulo, su interfaz relaciones, dependencias, base de datos tablas, los
diagramas de la arquitectura, tecnologa detallan el etc. El diseo de
prueba de la integracin se realiza en esta fase
DISEO DEL MDULO
Esta fase se puede tambin llamar como diseo bajo. El sistema
diseado est quebrado para arriba adentro a unidades ms pequeas o
se explica los mdulos y cada uno de ellas de modo que el programador
pueda comenzar a cifrar directamente.
FASES DE LA VALIDACIN
PRUEBA DE LA UNIDAD
la prueba de la unidad implica la primera etapa de prueba dinmica
proceso.
Implica el anlisis del cdigo escrito con la intencin de eliminar errores.
PRUEBA DE LA INTEGRACIN
En la integracin la prueba de los mdulos separados ser probada junta
para exponer averas en interfaces y en la interaccin entre los

componentes integrados. La prueba est generalmente caja negra pues

el cdigo no se comprueba directamente para saber si hay errores.
PRUEBA DEL SISTEMA
La prueba del sistema comparar las especificaciones de sistema contra
el sistema real.
PRUEBA DE ACEPTACIN DE USUARIO
PRUEBA DE ACEPTACIN:
Para determinarse si un sistema satisface sus criterios de la
aceptacin o no.
Para permitir al cliente determinarse si aceptar el sistema o no.
Para probar el software en el del mundo real por las
audiencias previstas.
PROPSITO DE LA PRUEBA DE ACEPTACIN:
Para verificar el sistema o los cambios segn las
necesidades originales.
PROCEDIMIENTOS PARA CONDUCIR LA PRUEBA DE
ACEPTACIN:
Defina los criterios de la aceptacin:

Requisitos de la funcionalidad y funcionamiento.

Requisitos de calidad del interfaz.
Requisitos de calidad totales del software.
Desarrolle un plan de la aceptacin:
Descripcin del proyecto.
Responsabilidades del usuario.
Descripcin de la aceptacin.
Ejecute el plan de prueba de aceptacin.

La Verificacin de requerimientos
Conjunto de actividades que aseguran que el software implemente
correctamente una funcin, La verificacin y la validacin abarcan una
amplia lista de actividades de aseguramiento de la calidad del software,
estas incluyen: Revisiones tcnicas formales, auditorias de calidad,

simulacin, factibilidad, revisin de documentacin, y pruebas de

diversos tipos.

VERIFICACIN DE REQUERIMIENTOS
REQUERIMIENTOS: Los requerimientos especifican qu es lo que el
sistema debe hacer (sus funciones) y sus propiedades esenciales y
deseables.
ANLISIS DE REQUERIMIENTOS
Conjunto de tcnicas y procedimientos que nos permiten conocer los
elementos necesarios para definir un proyecto de software. Es una tarea
de ingeniera del software que permite especificar las caractersticas
operacionales del software, indicar la interfaz del software con otros
elementos del sistema y establecer las restricciones que debe cumplir el
software.
COMO REALIZAR EL ANLISIS DE REQUERIMIENTOS
Esto se logra mediante la clasificacin, estructuracin y organizacin de
todo lo que el sistema debe de hacer.
1) Obtener informacin por diferentes medios de lo que los usuarios
desean y dejar escritas esas necesidades
2) Clasificar esas necesidades para poder estructurar los requerimientos
o necesidades del sistema.
3) Identificar los niveles de jerarqua del sistema y empezar a alojar los
requerimientos en el nivel que les corresponda.
4) Especificar los requerimientos de acuerdo al nivel de audiencia que se
requiera
5) Especificar completamente cada necesidad, sin ahorrar tiempo y
espacio en su descripcin.
6) Entender correctamente las necesidades y cuando afecten dos o mas
usuarios, para llegar a acuerdos entre las partes.
7) Manejar las expectativas y estar dispuesto a realizar cambios.
8) Involucrar a todos los que tengan inherencia en el proyecto (Jefes,
subalternos, usuarios en general)
9) Se debe mantener una perfecta comunicacin entre todos quienes
participan en el proceso de levantamiento de los requerimientos
Los requerimientos son el punto de acuerdo entre el usuario y el
proyecto de desarrollo de software, este entendimiento es necesario

para poder construir software que satisfaga las necesidades de los

usuarios.
TIPOS DE REQUERIMIENTOS
Ambiente fsico:
- Dnde esta el equipo que el sistema necesita para funcionar?
- Existe una localizacin o varias?
Hay restricciones ambientales como temperatura, humedad o
interferencia magntica?
Interfaces:
- La entrada proviene de uno o ms sistemas?
Usuarios y factores humanos:
- Quien usar el sistema?
- Habr varios tipos de usuario?
Funcionalidad:
- Qu har el sistema?
- Cundo lo har?
Documentacin:
- Cunta documentacin se requiere?
- Debe estar en lnea, en papel o en ambos?
Datos:
- Cul ser el formato de los datos, tanto para la entrada como
para la salida?
Cun a menudo sern recibidos o enviados?
Recursos
Qu recursos materiales, personales o de otro tipo se requieren
para construir, utilizar y mantener el sistema?
Seguridad:
- Debe controlarse el acceso al sistema o a la informacin?
- Cmo se podrn aislar los datos de un usuario de los de otros?
Aseguramiento de la calidad:
Cules son los requerimientos para la confiabilidad,
disponibilidad, facilidad de mantenimiento, seguridad y dems
atributos de calidad?
Caractersticas de los requerimientos
Los requerimientos permiten que los desarrolladores expliquen cmo
han entendido lo que el cliente pretende del sistema. Tambin, indican a
los diseadores qu funcionalidad y que caractersticas va a tener el
sistema resultante

Verificacin de Requerimientos
La verificacin formal es una rigurosa demostracin matemtica de la
concordancia del cdigo fuente con sus especificaciones. La validacin
es la evaluacin del software al final del proceso de desarrollo del
software para determinar su conformidad con los requisitos.
Verificacin: Estamos construyendo el producto correctamente? El
papel de la verificacin comprende comprobar que el software est de
acuerdo con su especificacin.
Validacin: Estamos construyendo el producto concreto? La validacin
es un proceso ms general. Se debe asegurar que el software cumple las
expectativas del cliente.
Dentro del proceso de Verificacin y validacin se utilizan dos tcnicas
de comprobacin y anlisis de sistemas:
1. Las inspecciones del software analizan y comprueban las
representaciones del sistema como el documento de requerimientos, los
diagramas de diseo y el cdigo fuente del programa. Se aplica a todas
las etapas del proceso de desarrollo.
2. Las pruebas del software consiste en contrastar las respuestas de una
implementacin del software a series de datos de prueba y examinar las
respuestas del software y su comportamiento operacional, para
comprobar que se desempee conforme a lo requerido.

ENTREVISTA
La entrevista es un mtodo para descubrir hechos y opiniones que
tienen los posibles usuarios y otros participantes dentro del sistema que
se est desarrollando. Los errores y malentendidos pueden ser
detectados y corregidos a travs de este mtodo, por lo cual resulta muy
til dentro de esta actividad de la ingeniera de requerimientos.

FASES DE LA ENTREVISTA
En fases de una entrevista se distinguen 3 puntos:
PREPARACION
REALIZACION
ANALISIS
Preparacin: El entrevistador debe documentarse e investigar la
situacin de la organizacin, analizando los documentos de la empresa
disponible.
Realizacin: Hay tres fases:
Apertura: Presentarse e informar al entrevistado sobre la razn de la
entrevista.
Desarrollo: Cumplir las reglas del protocolo, hay que llegar a un acuerdo
sobre como se va a registrar la informacin obtenida.
Terminacin: Se termina recapitulando la entrevista agradeciendo el
esfuerzo y dejando abierta la posibilidad de volver a contactar para
aclarar conceptos o bien citndole para otra entrevista.
Anlisis: Consiste en leer las notas, pasarlas en limpio, reorganizar la
informacin, contrastarlas con otras entrevistas o fuentes de
informacin, evaluar como ha ido la entrevista.
CLASIFICACION DE LAS ENTREVISTAS
Entrevistas cerradas: donde los entrevistados responden a un
conjunto predefinido de preguntas.
Entrevistas abiertas: donde no hay un programa predefinido.

Los buenos entrevistadores poseen dos caractersticas importantes:

1.- No tienen prejuicios, evitan ideas preconcebidas sobre los
requerimientos y estn dispuestos a escuchar a los entrevistados.
2.- Ayudan al entrevistado a empezar las discusiones con una pregunta,
una
Propuesta de requerimientos o sugiriendo trabajar juntos en un prototipo
del sistema.
EL ENTREVISTADO PUEDE PRESENTAR:
PASIVIDAD, INHIBICION

 NO ACEPTACION
RECHAZO
AGRESIVIDAD
EL ENTREVISTADOR DEBE POSEER:

TRATO CORDIAL
CONOCIMIENTO DE TECNICAS DE COMUNICACIN
ACTITUD PARA ESCUCHAR SIN PREJUICIOS
EXPERIENCIA PRCTICA
INTERS POR EL TEMA

DEFINICIN DE REQUERIMIENTOS
Para realizar con xito la definicin de los requerimientos es importante
conseguir que los requerimientos sean claramente definidos para
minimizar la ambigedad de los requerimientos, para esto es importante
tener en cuenta lo siguiente:
o Definir los requerimientos teniendo en cuenta la informacin
identificada con la perspectiva del usuario
Reutilizar requerimientos, revisando proyectos ya finalizados
para ver si contienen material potencialmente reutilizable
Se debe documentar los requerimientos de una forma clara y
correcta.

ESPECIFICACIN DE REQUERIMIENTOS:
Documento que reitera la definicin de los requerimientos en los
trminos tcnicos apropiados para el desarrollador del diseo de
un sistema.

Es la contrapartida tcnica al documento de definicin de

requerimientos y es escrito por los analistas de requerimientos.

Clasificacin de requerimientos
Requerimientos Funcionales: Describen la funcionalidad o los servicios
que se espera que el sistema proveer.

Estos requerimientos se utilizan para determinar que har el Software,

definiendo las relaciones de su operacin y su implementacin, sin
olvidar que deben ser explcitos tambin en lo que el sistema no debe
hacer y que validaciones se deben realizar, teniendo en cuenta cual ser
el comportamiento del sistema.

Requerimientos no funcionales: requerimientos que no se refieren

directamente a las funciones especficas que entrega el sistema,
sino a las propiedades emergentes de ste, como la fiabilidad, la
respuesta en el tiempo y la capacidad de almacenamiento.

Son restricciones de los servicios o funciones ofrecidos por el sistema.

Incluyen restricciones de tiempo, sobre el proceso de desarrollo y
estndares. Los requerimientos no funcionales a menudo se aplican al
sistema en su totalidad.
CLASIFICACION DE LOS REQUERIMIENTOS NO FUNCIONALES
Del producto: Especifican comportamiento del producto.
Organizacionales: se derivan de las polticas y procedimientos
existentes en la organizacin del cliente y del desarrollador.
Externos: cubre todos los requerimientos que se derivan de los factores
externos al sistema y de su proceso de desarrollo.
Requerimientos de dominio. requerimientos que provienen del
dominio de aplicacin del sistema y reflejan caractersticas y
restricciones de ese dominio. Estos pueden ser funcionales o no
funcionales.

Caractersticas de los requerimientos:

Permitir que el desarrollador explique cmo ha entendido lo que el
cliente pretende del sistema.
Indican a los diseadores que funcionalidades y caractersticas va
a tener el sistema resultante.

Los requerimientos indican al equipo de pruebas que

demostraciones llevar a cabo para convencer al cliente de que el
sistema que se le entrega es de hecho lo que haba ordenado
PREGUNTAS QUE DEVEN RESPONDER LOS REQUERIMIENTOS .
los requerimientos son correctos?. Cliente y desarrollador

deben revisarlos para asegurarse que no tienen errores.

los requerimientos son consistentes?. Es decir, los

requerimientos planteados son no conflictivos ni ambiguos?. Dos
requerimientos
son
inconsistentes
cuando
es
imposible
satisfacerlos simultneamente.
CLASIFICACION SEGN A QUIEN VA DIRIGIDO:
Requerimientos de Usuario

Declaraciones en lenguaje natural y en diagramas de los servicios

que se espera que el sistema provea y de las restricciones bajo las
cuales debe operar.
Requerimientos del sistema:

Establecen con detalle los servicios y restricciones del sistema.

El documento de requerimientos del sistema, algunas veces

denominado especificacin funcional, debe ser preciso.

IMPORTANCIA DE LA DEFINICIN FORMAL DE REQUERIMIENTOS

El anlisis y especificacin de requerimientos puede parecer una tarea
relativamente sencilla, pero las apariencias engaan. Puesto que el
contenido de comunicacin es muy alto, abundan los cambios por mala
interpretacin o falta de informacin.
TCNICAS DE REVISON DE SOFTWARE
. AD-HOC: forma rpida de obtener otra perspectiva para
encontrar problemas que el autor del proyecto no puede ver por s
mismo. La tcnica no sigue un proceso establecido y sus resultados no
se registran de una manera predefinida.
REVISIN DE PARES (PEER DESKCHECK): Involucra a una sola
persona (distinta al autor del proyecto) quien recibe una copia del
proyecto para su revisin. El revisor puede utilizar checklists u otras
tcnicas de anlisis que incrementen la efectividad del proceso.
REVISIN DE PARES MLTIPLE (PASSAROUND): Es una revisin de
pares realizada concurrentemente. El proyecto a revisar es distribuido
entre 3 y 15 personas quines revisan y dan su devolucin por separado.
PROGRAMACIN DE A PARES (PAIR PROGRAMMING): consiste en
dos desarrolladores trabajando en un mismo producto simultneamente,
en una sola computadora, compartiendo un teclado y un monitor. Uno

hace de controlador y es el que efectivamente programa; el otro es el

navegador que observa el trabajo del controlador e identifica errores.
PRESENTACIN (WALKTHROUGH): tcnica donde el diseador o
desarrollador gua a los miembros de un equipo a travs del proyecto a
revisar. Los participantes hacen preguntas o comentarios sobre posibles
anomalas, violacin de estndares u otros problemas. El autor toma un
rol dominante donde el objetivo es satisfacer sus necesidades en lugar
de los objetivos de calidad del equipo.
REVISIN EN EQUIPO (TEAM REVIEW): Comienza con una
planificacin seguida de una de preparacin donde los participantes
reciben el material necesario varios das antes. Luego el equipo (con
roles definidos) se rene para discutir los resultados donde participan el
lder de revisin (puede ser el propio autor del artefacto revisado),
registrador y moderador (no puede ser del propio autor). La ltima etapa
es la correccin de los defectos encontrados.
INSPECCIONES EN SOFTWARE: principal actividad de evaluacin
esttica ya que es la ms formal, sistemtica y rigurosa en cuanto a sus
procedimientos. Consta de siete etapas y roles bien definidos. Estos
equipos son formados por 4 o 5 compaeros de trabajo.

TCNICAS O MTODOS DE PRUEBA

FUNDAMENTOS PARA LA PRUEBA DE SOFTWARE

1.

DEFINICIONES Y CONCEPTOS
1.1. PROBAR
Actividad en la cual se somete a un sistema o uno de sus componentes a una evaluacin de los
resultados que arroja en base a la ejecucin de este en condiciones especificadas
1.2. PRUEBAS O TECNICAS DE SOFTWARE
Elemento crtico para la garanta de calidad del software y representa una revisin final de las
especificaciones, del diseo y de la codificacin.
El nico instrumento adecuado para determinar el status de la calidad de un producto software es el
proceso de pruebas.
El proceso de pruebas, sus objetivos y los mtodos y tcnicas usados se describen en el plan de
prueba

A
conti
n

nuaci
se

presentan algunas caractersticas de una buena prueba:

Una buena prueba debe centrarse en dos objetivos:

Probar si el software no hace lo que debe hacer.

Probar si el software hace lo que no debe hacer.

Una buena prueba no debe ser redundante. El tiempo y los recursos

son limitados, as que todas las pruebas deberan tener un propsito
diferente.
1.2.1. Quin se encarga de las pruebas de software?
Se distinguen pruebas tcnicas y pruebas funcionales. Las pruebas tcnicas son la responsabilidad de
los ingenieros de software que han desarrollado el producto, pero estos ingenieros nunca deben
hacerse cargo de las pruebas funcionales, por varias razones. El responsable para las pruebas
funcionales es el tcnico de pruebas, que dispone de los conocimientos y aptitudes necesarios para
esta tarea tan importante y especfica.
En proyectos a gran escala las pruebas funcionales son la responsabilidad de un equipo de pruebas,
que consiste de uno o varios tcnicos, un coordinador de pruebas y un gestor de pruebas o de calidad

2.

OBJETIVOS PRINCIPALES
Detectar un Error
Tener un buen caso de prueba
Descubrir un error no descubierto antes

PRUEBA DE SOFTWARE
En la etapa de prueba del software se crean una serie de casos de prueba que intentan destruir el
software desarrollado.

2.1. OBJETIVOS DE LA PRUEBA

El principal objetivo de una prueba es descubrir un error.
La prueba es el proceso de ejecucin de un programa con la intencin de descubrir u
error.
Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no
descubierto hasta entonces.

Una prueba tiene xito si descubre un error no detectado hasta entonces.

Disear pruebas que tengan la mayor probabilidad de

encontrar el mayor nmero de errores con la mnima cantidad
de esfuerzo y tiempo
2.2. PROCESO DE LA PRUEBA
El proceso de prueba tiene dos entradas:
Configuracin del software: Incluye la especificacin de requisitos del software, la
especificacin del diseo y el cdigo fuente.
Configuracin de prueba: Incluye un plan y un procedimiento de prueba

TAREAS A REALIZAR PARA PROBAR UN SOFTWARE

1) Diseo de las pruebas:

Identificacin de la tcnica o tcnicas de pruebas que se utilizaran

para probar el software.
2) Generacin de los casos de prueba:

Los casos de prueba representan los datos que se utilizaran como

entrada para ejecutar el software a probar. Los casos de prueba
determinan un conjunto de entradas, condiciones de ejecucin y
resultados esperados para un objetivo particular.
3) Definicin de los procedimientos de la prueba:
Especificacin de cmo se va a llevar a cabo el proceso, quien lo va a realizar, cuando,
como, etc.
4) Ejecucin de la prueba:
Aplicando los casos de prueba generados previamente e identificando los posibles fallos
producidos al comparar los resultados esperados con los resultados obtenidos.
5) Realizacin de un informe de la prueba:
Con el resultado de la ejecucin de las pruebas, que casos de prueba pasaron
satisfactoriamente, cules no, y que fallos se detectaron
2.3. CRITERIOS DE PUEBA
Generar casos de prueba efectivos que revelen la presencia de fallas es fundamental para el
xito del proceso de pruebas
Determinar un conjunto de casos de prueba tales que su ejecucin exitosa implique que no
hay errores en el software desarrollado
El nmero de casos de prueba necesarios para detectar los errores debe ser minimizado para
reducir costos

GARANTIAS DE LA PRUEBA DE SOFTWARE

Las pruebas no garantizan la ausencia de defectos

2.4. CARACTERISTICAS PARA UNA BUENA PRUEBA

Una prueba ha de tener una alta probabilidad de encontrar un fallo. Para alcanzar este
objetivo el responsable de la prueba debe entender el software e intentar desarrollar una
imagen mental de cmo podra fallar

3.

Una buena prueba debe centrarse en dos objetivos:

1) Probar si el software no hace lo que debe hacer
2) Probar si el software hace lo que no debe hacer
Una buena prueba no debera ser redundante. El tiempo y los recursos son limitados, as que
todas las pruebas deberan tener un propsito diferente.
Una buena prueba debera ser la mejor cosecha. Esto es, se debera emplear la prueba que
tenga la ms alta probabilidad de descubrir una clase entera de errores
Una buena prueba no debera ser ni demasiada sencilla ni demasiada compleja, pero si se
quiere combinar varias pruebas a la vez se puede enmascarar errores, por lo que en general,
cada prueba debera realizarse separadamente
PRINCIPIOS DE PRUEBA
Los principios de prueba son 6:
1) A todas las pruebas se les debera poder hacer un seguimiento hasta los requisitos del cliente.
2) Las pruebas deberan de planificarse mucho antes de que empiecen.
3) El principio de Pareto es aplicable a la prueba de software (el 80% de los errores se encuentra
en un 20% del programa).
4) Las pruebas deberan de comenzar con lo pequeo y progresar hacia lo grande.
5) No son posibles las pruebas exhaustivas.
6) Para ser ms eficaces, las pruebas deberan de ser realizadas por un equipo independiente.

FACILIDAD DE PRUEBA DEL SOFTWARE

Es simplemente la facilidad con la que se puede probar el programa de
computadora.
La siguiente lista de comprobacin proporciona un conjunto de caractersticas que llevan a un
software fcil de probar.
Operatividad.- Cuanto mejor funcione, ms eficientemente se puede probar.
Observabilidad.- Lo que ves es lo que pruebas.
Controlabilidad.- Cuanto mejor podamos controlar el software, ms se puede automatizar y
optimizar.
Capacidad de descomposicin.- Controlado el mbito de las pruebas, podemos aislar ms
rpido los problemas y llevara a cabo mejores pruebas de regresin.
Simplicidad.- Cuanto menos haya que probar, ms rpido podemos probarlo.
Estabilidad.- Cuanto menos cambios, menos interrupciones a las pruebas.
Facilidad de comprensin.- Cuanta ms informacin tengamos, ms inteligente sern las
pruebas.

Una buena prueba debe de tener los siguientes atributos:

4.

1. Debe de tener una alta probabilidad de encontrar un error.

2. No debe de ser redundante, el tiempo y los recursos para las pruebas son limitados.
3. debera de ser de la mejor cosecha.
4. No debera de ser ni demasiado sencilla ni demasiado compleja.

CLASIFICACION DE LOS METODOS DE PRUEBA:

Prueba de Caja Blanca
Prueba de Caja Negra
4.1. DISEO DE CASOS DE PRUEBA

Debemos disear pruebas que tengan la mayor probabilidad de

encontrar el mayor nmero de errores con la mnima cantidad de
esfuerzo y tiempo posible.

Cualquier producto de ingeniera puede probarse de una de estas dos

formas:
1) Conociendo la funcin especfica para la que fue diseado el producto (Caja Negra)
2) Conociendo el funcionamiento del producto. (Caja Blanca)

METODOS
Las tcnicas o mtodos de evaluacin dinmica proporcionan distintos criterios
para generar casos de prueba que provoquen fallos en los programas. Estas
tcnicas se agrupan en:

Tcnicas de cajas blancas o estructurales, que se basan en un minucioso examen de los detalles
procedimentales del cdigo a evaluar, por lo que es necesario conocer la lgica del programa.
Tcnicas de caja negra o funcionales, que realizan pruebas sobre la interfaz del programa a probar,
entendiendo por interfaz las entradas y salidas de dicho programa. No es necesario conocer la lgica
del programa, nicamente la funcionalidad que debe realizar.

PRUEBAS DE CAJA BLANCA O

ESTRUCTURALES
Este mtodo se centra en cmo disear los casos de prueba atendiendo al
comportamiento interno y la estructura del programa. Se examina as la lgica
interna del programa sin considerar los aspectos de rendimiento. El objetivo de
la tcnica es disear casos de prueba para que se ejecuten, al menos una vez,
todas las sentencias del programa, y todas las condiciones tanto en su
vertiente verdadera como falsa.
Se han definido distintos criterios de cobertura lgica, que permiten decidir qu
sentencias o caminos se deben examinar con los casos de prueba. Estos
criterios son

Cobertura de Sentencias: Se escriben casos de prueba suficientes para que cada sentencia en el
programa se ejecute, al menos, una vez.
Cobertura de Decisin: Se escriben casos de prueba suficientes para que cada decisin en el programa
se ejecute una vez con resultado verdadero y otra con el falso.
Cobertura de Condiciones: Se escriben casos de prueba suficientes para que cada condicin en una
decisin tenga una vez resultado verdadero y otra falso.
Cobertura Decisin/Condicin: Se escriben casos de prueba suficientes para que cada condicin en
una decisin tome todas las posibles salidas, al menos una vez, y cada decisin tome todas las posibles
salidas, al menos una vez.
Cobertura de Condicin Mltiple: Se escriben casos de prueba suficientes para que todas las
combinaciones posibles de resultados de cada condicin se invoquen al menos una vez.
Cobertura de Caminos: Se escriben casos de prueba suficientes para que se ejecuten todos los
caminos de un programa. Entendiendo camino como una secuencia de sentencias encadenadas desde la
entrada del programa hasta su salida.
1. TCNICA DE COBERTURA DE CAMINOS:

La aplicacin de este criterio de cobertura asegura que los casos de

prueba diseados permiten que todas las sentencias del programa sean
ejecutadas al menos una vez y que las condiciones sean probadas tanto
para su valor verdadero como falso.
Se escriben casos de prueba suficientes para que se ejecuten todos
algunos de los caminos de un programa.
Criterios:

CRITERIO DE COBERTURA DE TODOS LOS CAMINOS

No es muy prctico por la cantidad de rutas a probar.

Un programa puede tener un gran nmero de rutas a probar o
un nmero infinito.

CRITERIO DE COBERTURA DE SENTENCIA

Todos los caminos

Cobertura de Sentencias
Ramas
Predicados
Ruta Bsica

Una cobertura de sentencias se ha logrado si todos las

declaraciones han sido ejecutadas al menos una vez.
La cobertura de la sentencia completa es el criterio ms dbil
de la cobertura en las pruebas.
El problema bsico es seleccionar unos pocos caminos que
recorran todos los nodos de un control de flujo grfico (CFG)
para lograr la cobertura declaracin completa.

CRITERIO DE COBERTURA DE SENTENCIA

Una cobertura de sentencias se ha logrado si todos las

declaraciones han sido ejecutadas al menos una vez.
La cobertura de la sentencia completa es el criterio ms dbil
de la cobertura en las pruebas.
El problema bsico es seleccionar unos pocos caminos que
recorran todos los nodos de un control de flujo grfico (CFG)
para lograr la cobertura declaracin completa.

Ejemplos:
Asignaciones y llamados a mtodos
Break, continue, return, throw, etc.
Variables y miembros de declaraciones
asignacin: (int i = 0)

con

 CRITERIO DE COBERTURA DE RAMAS

Rama: es una arista saliente de un nodo.

Todo el nodo rectngulo debe tener como mximo una rama de

salida.
Todos los nodos de diamante tiene dos ramas de salida.
Cobertura de ramas completa significa la seleccin de un
nmero de caminos de manera que cada rama se incluye en al
menos una ruta.
Ejemplos:
if y else
switch-branches: case and default

CRITERIO DEL CAMINO BASICO

Una de las tcnicas empleadas para aplicar este criterio de

cobertura es la Prueba del Camino Bsico. Esta tcnica se basa en
obtener una medida de la complejidad del diseo procedimental de
un programa (o de la lgica del programa). Esta medida es la
complejidad ciclomtica de McCabe, y representa un lmite superior
para el nmero de casos de prueba que se deben realizar para
asegurar que se ejecuta cada camino del programa.
Los pasos a realizar para aplicar esta tcnica son:
1)
2)
3)
4)

Representar el programa en un grafo de flujo

Calcular la complejidad ciclomtica
Determinar el conjunto bsico de caminos independientes
Derivar los casos de prueba que fuerzan la ejecucin de cada
camino.

A continuacin, se detallan cada uno de estos pasos.

1) REPRESENTAR EL PROGRAMA EN UN GRAFO DE FLUJO

El grafo de flujo se utiliza para representar flujo de control lgico
de un programa. Para ello se utilizan los tres elementos
siguientes:

Nodos: representan cero, una o varias sentencias en secuencia. Cada nodo

comprende como mximo una sentencia de decisin (bifurcacin).
Aristas: lneas que unen dos nodos.

Regiones: reas delimitadas por aristas y nodos. Cuando se contabilizan las regiones
de un programa debe incluirse el rea externa como una regin ms.
Nodos predicado: cuando en una condicin aparecen uno o ms operadores lgicos
(AND, OR, XOR,...) se crea un nodo distinto por cada una de las condiciones
simples. Cada nodo generado de esta forma se denomina nodo predicado.

CALCULAR LA COMPLEJIDAD CICLOMATICA

La complejidad ciclomtica es una mtrica del software que proporciona una
medida cuantitativa de la complejidad lgica de un programa. En el contexto
del mtodo de prueba del camino bsico, el valor de la complejidad ciclomtica
define el nmero de caminos independientes de dicho programa, y por lo tanto,
el nmero de casos de prueba a realizar.
Formas de calcular la complejidad ciclomtica de un programa a
partir de un grafo de flujo:
I.
II.
III.

El nmero de regiones del grafo coincide con la complejidad ciclomtica, V (G).

La complejidad ciclomtica, V(G), de un grafo de flujo G se define como V(G)
= Aristas Nodos + 2
La complejidad ciclomtica, V(G), de un grafo de flujo G se define como V(G)
= Nodos Predicado + 1

DETERMINAR EL CONJUNTO BASICO DE CAMINOS INDEPENDIENTES

Un camino independiente es cualquier camino del programa que introduce, por
lo menos, un nuevo conjunto de sentencias de proceso o una condicin,
respecto a los caminos existentes. En trminos del diagrama de flujo, un
camino independiente est constituido por lo menos por una arista que no
haya sido recorrida anteriormente a la definicin del camino.
Se muestran algunas heursticas para identificar dichos caminos
Elegir un camino principal que represente una funcin vlida que no sea un
tratamiento de error. Debe intentar elegirse el camino que atraviese el mximo
nmero de decisiones en el grafo.
Identificar el segundo camino mediante la localizacin de la primera decisin en el
camino de la lnea bsica alternando su resultado mientras se mantiene el mximo
nmero de decisiones originales del camino inicial.
Identificar un tercer camino, colocando la primera decisin en su valor original a
la vez que se altera la segunda decisin del camino bsico, mientras se intenta
mantener el resto de decisiones originales.
Continuar el proceso hasta haber conseguido tratar todas las decisiones, intentando
mantener como en su origen el resto de ellas.

DERIVAR LOS CASOS DE PRUEBA QUE FUERZAN LA EJECUCION DE CADA

CAMINO

El ltimo paso es construir los casos de prueba que fuerzan la

ejecucin de cada camino.
TCNICAS DE CONTROL DE FLUJO
1) COBERTURA DE DECISION
2) COBERTURA DE CONDICIONES
3) TCNICA DE COBERTURA DE CICLOS

Como existen diferentes tipos de ciclos hay que tenerlos en

cuenta a la hora de analizarlos. Los tipos son:

Simple
Anidado
Concatenado
No estructurado

HERRAMIENTAS AUTOMTICAS PARA TCNICAS DE CAJA

BLANCA
Herramienta

Lenguaje

Coverage Pyton

Pyton

PHPUnit

PHP

JUnit

JAVA

CodeCover

JAVA, Cobol

JsCoverage

JavaScript

Ncover

Microsoft.Net

TCNICAS DE PRUEBAS FUNCIONALES DE

CAJA NEGRA
Estas pruebas permiten obtener un conjunto de condiciones de entrada que
ejerciten completamente todos los requisitos funcionales de un programa.
En ellas se ignora la estructura de control, concentrndose en los requisitos
funcionales del sistema y ejercitndolos.
La prueba de Caja Negra no es una alternativa a las tcnicas de prueba de
la Caja Blanca, sino un enfoque complementario que intenta descubrir
diferentes tipos de errores a los encontrados en los mtodos de la Caja
Blanca. Muchos autores consideran que estas pruebas permiten encontrar:
1.
2.

Funciones incorrectas o ausentes.

Errores de interfaz.

3.
4.
5.

Errores en estructuras de datos o en accesos a las Bases de Datos externas.

Errores de rendimiento.
Errores de inicializacin y terminacin.

Para desarrollar la prueba de caja negra existen varias tcnicas, entre ellas
estn:
1.

Tcnica de la Particin de Equivalencia: esta tcnica divide el campo de entrada en clases de

datos que tienden a ejercitar determinadas funciones del software.
Tcnica del Anlisis de Valores Lmites: esta Tcnica prueba la habilidad del programa para
manejar datos que se encuentran en los lmites aceptables.
Tcnica de Grafos de Causa-Efecto: es una tcnica que permite al encargado de la prueba validar
complejos conjuntos de acciones y condiciones.

2.
3.

EN QU CONSISTE EL MTODO DE LA CAJA NEGRA

1. Inputs (recursos): esto es de lo que disponemos.

2. Caja Negra: este es el lugar donde ocurre lo ms complicado o
misterioso, pero no tenemos ningn inters en averiguar cmo
funciona.
3. Outputs (las metas que queremos): este es nuestro resultado.
Desafortunadamente, hay un parmetro que no hemos mencionado an.
Es el entorno, del que necesitaremos saber:
Los procesos que se han necesitado para llegar al proceso de
transformacin de los inputs en outputs.
Las condiciones previas para obtener las soluciones o los xitos.
Los fenmenos externos que son impredecibles.
1.

POR QU Y DONDE SE UTILIZAN EL MTODO DE LA CAJA NEGRA

Si usamos este mtodo adquiriremos posibilidades lgicas, que pueden o

no ser el resultado del proceso existente, pero nos harn ms sensibles a
las nuevas o potenciales oportunidades. ste es el tpico mtodo
utilizado por:

Ingenieros
Fabricantes
Directores de proyectos
Investigadores / estadsticos

COMO SE APLICA EL METODO DE LA CAJA NEGRA

Describir cmo se transforman los inputs en outputs, o
Crear un modelo ms detallado, teniendo en mente cmo se construye el objeto y qu
contiene.

Para crear un modelo es necesario averiguar las respuestas de

nuestro objeto y as especificar los inputs. Esto significa que

tenemos que administrar algn input y leer el output, administrar

otro input, leer el output, administrar, leer, administrar, leer,
2.

CUAL ES LA META EN EL ANALISIS DE LA CAJA NEGRA?

La meta es describir un sistema que podamos utilizar, sin necesidad de saber cmo funciona esta.

PARTICIN EQUIVALENTE
Particin de equivalencia es una tcnica de pruebas de software que divide los
datos de entrada de una unidad de software en particiones de datos
equivalentes desde el que se pueden derivar los casos de prueba.
5.1 PROCEDIMIENTO DE PRUEBA
Un procedimiento de prueba especfica como realizar uno o varios casos de
prueba o parte de estos.
COMPONENTES DE PRUEBA Un componente de prueba automatiza uno o
varios procedimientos de prueba o parte de ellos.
PLAN DE PRUEBA
El propsito del plan de pruebas es dejar de forma explcita el alcance, el
enfoque, los recursos requeridos, el calendario, los responsables y el manejo de
riesgos de un proceso de pruebas
Las pruebas carecen de utilidad, tanto, s no se sabe exactamente
lo que se quiere probar, s no se est claro cmo se prueba, o si el
anlisis del resultado se hace a simple vista. Estas mismas ideas se
suelen agrupar diciendo que un caso de prueba consta de 3 bloques
de informacin:
1. El propsito de la prueba.
2. Los pasos de ejecucin de la prueba.
3. El resultado que se espera.
RUP propone definir casos de prueba de integracin para verificar
que los componentes interaccionan entre s de forma apropiada.
A partir de un caso de uso se pueden realizar pruebas de caja
negra, obtenindose varios casos de prueba que permiten:

Verificar el resultado de la interaccin entre los actores y el

sistema.

Comprobar que se satisfagan las precondiciones y pos

condiciones del caso de uso.

Comprobar que se siga la secuencia de acciones especificado

por el caso de uso.

Tambin se pueden realizar pruebas de caja blanca a partir de la

realizacin de un caso de prueba que permiten obtener casos de
prueba en los que se verifica la integracin ante los componentes
que implementan dicho caso de uso.
Como conclusin se podra decir que se pueden definir mltiples
casos de prueba de integracin para cada caso de uso en
dependencia de las condiciones de prueba que se tengan en
cuenta. El formato para describirlos podra ser:
5.3.1.

VARIANTE 1

1. Caso de uso: <Nombre>

2. Caso de prueba: <Nombre>
3. Entrada:<Descripcin textual de lo que ocurre en el
mundo real que hace necesario ejecutar el caso de
prueba, precisando la data de entrada y los comandos a
dar por el actor. Descripcin textual del estado de la
informacin almacenada>
4. Resultado:<Descripcin textual del estado en el que
queda la informacin y las alertas que puedan
generarse, una vez ejecutado el caso de uso con los
valores y el estado especificado en la entrada>
5. Condiciones:<Condiciones
que
deben
mientras se ejecuta el caso de prueba>
5.3.2.

cumplirse

VARIANTE 2

1. Caso de uso:<Nombre>
2. Rango de Valores de Entrada
3. Rango de Valores de Salida
Esta 2da variante se usa cuando hay varios casos de prueba
que verifican diferentes escenarios del mismo caso de uso.

Las pruebas del sistema se usan para probar que el sistema

funciona correctamente como un todo.
Como parte de estas pruebas hay que:

Probar la instalacin del software en la plataforma del

cliente.

Verificar el funcionamiento del software en diferentes

configuraciones.

Realizar pruebas negativas que busquen que el sistema

falle.

Realizar pruebas de tensin o estrs cuando hay

competencia por los recursos.

5.2
DEFECTO
Un defecto es una anomala del sistema, como por ejemplo un
sntoma de una fallo software o un problema descubierto en una
revisin. Un defecto puede ser utilizado para localizar cualquier
cosa que los desarrolladores necesitan registrar como sntoma
de un problema en el sistema que ellos necesitan controlar y
resolver.
5.3
EVALUACION DE PRUEBA
Una evaluacin de prueba es una evaluacin de los resultados
de los esfuerzos de prueba, tales como la cobertura del caso de
prueba, la cobertura del cdigo y el estado de los defectos.