INDICE

INTRODUCCION .4

1.CALIDAD DE SOFTWARE.....5
1.1. Definicin de calidad ...5
1.2. Politica de calidad .6
1.3. Definicion de calidad de software..7
1.3.1. Control de calidad9
1.3.2. Aseguramiento de calidad11
2.MODELOS DE CALIDAD DE SOFTWARE13
2.1. Modelos de calidad de software a nivel de proceso.14
2.1.1. CMM (capability Maturity Model)14
2.1.2. Modelo Tickt.14
 2.1.3. Modelo de bootstrap..15
2.1.4. Personal software Process (PSP)..16
2.2. Modelos de calidad de software a nivel de product..18
2.2.1. Modelos de Gilb..18
2.2.2. Modelo CQM (Goal-Question-Metric).....19
2.2.3. Modelo McCall.19
2.2.4. Modelo Furps...20
2.2.5. Modelos de Boehm.20
2.2.6. Modelo SATC (Software Assurance Technology Center)21
2.2.7. Modelo de Dromey..22
3. Definicin de verificacin y validacin23
3.1. Definicin de verificacin y validacin23
3.2. Validacin y verificacin en el ciclo de vida..24
4. OBJETIVOS Y RESTRICCIONES25
4.1. OBJETIVOS.25
4.2. RESTRICCIONES...25
5. PLANIFICACION DE PRUEBA DE SOFTWARE...26
5.1. Planificacion26
5.2. Alcance.26
5.3. Plan de pruebas..26
5.3.1 Analizar los requerimientos de desarrollo de software.26
5.3.1.1. Matriz de trazabilidad...27
5.3.1.2. Caso de uso.27
5.3.1.3. Historias de usuario..27
5.3.2. Identificar las funcionalidades nuevas a probar..27
5.3.3. Definir la estrategia de prueba..27
5.3.3.1. Pruebas Unitarias..29
5.3.3.2. Pruebas de integracin.29
5.3.3.3. Pruebas de alto nivel.30
5.3.3.4. Depuracin..30
5.3.3.5. Mtodos de prueba30
5.3.3.5.1. De caja blanca (o estructurales)..30
5.3.3.5.2. De caja negra (o funcionales)30
5.4. Identificar los entornos (ambientes) requeridos.30
5.5. Establecer la metodologa y procedimientos de prueba33
5.6. RECURSOS .33
5.7. Documentacion...33
5.8. Matriz de responsabilidades33
5.9. Manejo de riesgos e identificacin de reiesgos.34
6. Medicin y mtricas del software35
6.1. Medicin del software.35

6.2. Verificacin y Validacin en el proceso de desarrollo de software37

6.3. Modelo V (SEBok, Software Testing-Concept and Operations)..37
7. Concluciones...41
8. Recomendaciones.........41
INTRODUCCIN

El software es un producto abstracto de la mente humana. A

travs de los aos, nos hemos dado cuenta de que no es
posible crear sistemas grandes y complejos sin seguir un
proceso definido que organice nuestro trabajo: la ingeniera
de software. De igual forma, la experiencia nos ha mostrado
que para entregar sistemas correctos y que satisfagan las
necesidades de nuestros clientes es necesario probar
nuestro software. Las empresas ms grandes y
experimentadas en desarrollo de software, tales como IBM,
Microsoft y otras, estn conscientes de esto y dedican cada
vez un mayor nmero de recursos a las reas de
aseguramiento de la calidad para sus proyectos de software,
muchas veces equiparando o incluso superando los recursos
destinados al desarrollo. El diseo, implementacin y la
ejecucin de pruebas de software no son tareas triviales,
puesto que exigen la aplicacin de estrategias y tcnicas
formales que permitan desarrollar pruebas adecuadas para
medir efectivamente la calidad del producto. Los ingenieros
de pruebas de software cuentan con habilidades tcnicas y
desarrollan en mayor medida la creatividad y la atencin
aldetalle, adems de tener la perspectiva del usuario final.

1. CALIDAD DE SOFTWARE
Los conceptos relacionados con la calidad de software tienen relacin
directa con la aplicacin de la calidad a un producto desarrollado a travs
de procesos de ingeniera de software. En tal sentido empezaremos dando
algunas definiciones de calidad y luego ampliaremos el concepto hacia
calidad de software.

1.1. Definicin de Calidad

Existen muchas definiciones de calidad y muchos trminos que se
utilizan en la gestin de la misma.

Para la ISO 8402 (International Standard Organization), complemento

de normas de las series de normas ISO 9000, define La Calidad como:
"El conjunto de caractersticas de una entidad que le confieren la
aptitud para satisfacer las necesidades establecidas e implcitas.
 Tambin podra decirse que es la conformidad con los requisitos y
el grado de excelencia. En un servicio la calidad se define como la
diferencia entre la percepcin del servicio y la expectativa que el
cliente tena del mismo. Calidad tambin es la satisfaccin del cliente.

La calidad la definen los clientes, por lo que la oferta deber estar de

acuerdo los lo que ellos definen (sus exigencias) y entonces deber
producirse exactamente lo que dichos clientes desean, en el plazo
convenido y al mnimo costo e incluso anticiparse a sus necesidades
satisfaciendo sus expectativas, lo que dar una ven taja competitiva
frente a la competencia.

La calidad no solo hace referencia a que un producto o servicio se

ajuste a las exigencias. La percepcin que los clientes tienen sobre su
empresa est basada en el producto o servicio que les suministra,
pero tambin en el contacto diario que mantienen con los directivos.
El concepto de calidad abarca no slo como se atienden las
exigencias de sus clientes sino tambin la forma en que se hace, cmo
se atiende el telfono, la rapidez con que se satisfacen consultas,
tener nuevos servicios cuando se los requiere, asegurarse que la
factura que sale de la empresa es la correcta. Cada contacto,
llamados momentos de la verdad con el cliente, muestra un reflejo de
la compaa a los ojos de ese cliente.

El recepcionista que atiende las llamadas, los agentes de seguridad

que controlan los accesos, los ascensoristas que transportan a la
gente y la orientan, los administrativos que envan las facturas, los
dictmenes de los abogados, todos deben involucrarse en el concepto
de calidad, en satisfacer las exigencias del cliente, en crear una
compaa con clase reconocida. La calidad es un concepto objetivo
que cada empleado puede comprender y evaluar, y sobre el cual
puede asumir responsabilidades.

La nica forma de alcanzar el objetivo de calidad es:

1. Comprender las exigencias de los clientes externos.

2. Conocer a fondo los procesos internos que le permitan satisfacer
esas exigencias.
3. Desarrollar un sistema y cultura empresarial que le aseguren que
los errores son evitados o eliminados

1.2. Poltica de Calidad

ISO 8402 la define como: "Directrices y objetivos generales de una
empresa relativos a la calidad, expresados formalmente por la
Direccin General". Es una de las vas para hacer operativa la
estrategia. Al desplegar verticalmente la poltica a travs de los niveles
jerrquicos de la organizacin:
Se proporciona orientacin precisa para que ejecutivos y mandos
elaboren planes concretos de accin.
Se cohesiona la organizacin para el cumplimiento de los
objetivos de calidad.
Se refuerza el compromiso del personal.
 La poltica de calidad debe ser:

Adecuada a la empresa.
Coherente con las necesidades y expectativas de sus clientes.
Muy simple y fcilmente comprensible para que sea comunicable
y entendida sin dificultad.

En cuanto a su contenido, debera hacer referencia a:

Los grandes objetivos de la empresa.

Los colectivos que en ella conviven: personal, accionistas,
clientes, proveedores.
La disponibilidad de los recursos necesarios; por ejemplo,
formacin.
La va a utilizar (ISO, Mejora Continua, etc.).

Es la totalidad de aspectos y caractersticas de un producto o servicio

que se refieren a su capacidad para satisfacer necesidades dadas en
la adecuacin de sus objetivos.

El Instituto de Ingeniera de Software (SEI) en su modelo CMM define

la calidad como:
El grado en el cual un sistema, componente o proceso cumple con
los requisitos especificados.
El grado en el cual el sistema, componente o proceso cumple con
las expectativas del cliente o usuario.

Figura 1.1 - Sistema de Gestin de Calidad

1.3. Definicin de Calidad de Software

La Calidad del Software es el conjunto de cualidades que lo
caracterizan y que determinan su utilidad y existencia.

Segn R. Pressman: La calidad del software se define como la

concordancia con los requisitos funcionales y de rendimiento
explcitamente establecidos, con los estndares y procesos de
desarrollo explcitamente documentados y con las caractersticas
implcitas que se espera de todo software desarrollado
profesionalmente.

No hay duda de que la anterior definicin puede ser modificada o

ampliada. De hecho, no tendra fin una discusin sobre una definicin
definitiva de la calidad del software. Para los propsitos de este
enfoque, la anterior definicin sirve para hacer hincapi en tres puntos
importantes:
1. Los requisitos del software son la base de las medidas de la
calidad. La falta de concordancia con los requisitos es una falta de
calidad.

2. Los estndares especificados definen un conjunto de criterios de

desarrollo que guan la forma en que se aplica la ingeniera del
software o del conocimiento. En caso de no seguirse esos
criterios, casi siempre habr falta de calidad.

3. Existe un conjunto de requisitos implcitos que a menudo no se

mencionan (por ejemplo, la necesidad de una interfaz intuitiva). Si
el software se ajusta a sus requisitos explcitos, pero falla en
alcanzar los requisitos implcitos, la calidad del software se
debilita.

Queda claro a partir de la definicin de calidad del software, que sta

es siempre relativa a los requisitos o necesidades que se desea
satisfacer. Por eso la evaluacin de la calidad del software siempre va
a implicar la comparacin entre los requisitos y el producto generado.
La Calidad del Software es medible y vara de un sistema a otro o de
un programa a otro. Por ejemplo: un software elaborado para el control
de naves espaciales debe ser confiable al nivel de "cero fallas"; un
software hecho para ejecutarse una sola vez no requiere el mismo
nivel de calidad; mientras que un producto de software para ser
explotado durante un largo perodo (10 aos o ms) necesita ser
confiable, mantenible y flexible para disminuir los costos de
mantenimiento y perfeccionamiento durante el tiempo de explotacin.

La Calidad del Software puede medirse despus de elaborado el

producto. Pero esto puede resultar muy costoso si se detectan
problemas derivados de imperfecciones en el diseo, por lo que es
imprescindible tener en cuenta tanto la obtencin de la calidad como
su control durante todas las etapas del ciclo de vida del software.

Existen varios factores que determinan la calidad del software y la

eficiencia de la organizacin, entre ellos estn la complejidad del
producto, las tecnologas y las personas, as como algunas
condiciones de entorno que tambin tienen su impacto, estas pueden
ser condiciones de gestin (plazo de entrega, restricciones dentro de
la organizacin), entornos de desarrollo y caractersticas del cliente,
 sin embargo, en el centro de todas ellas se encuentra el proceso. El
proceso es el nico factor de los controlables al mejorar la calidad del
software y su rendimiento en la organizacin. Analizando y mejorando
el proceso se puede obtener mejores productos.

Figura 1.2 - Determinantes de la calidad del software y de la efectividad de

la organizacin

Los ejes de desarrollo de software se relacionan con la calidad de la

siguiente forma:

1. Persona: PSP, TSP

2. Producto: McCall, Boehm, ISO/IEC 9126-1
3. Proceso: CMM, ISO/IEC 15504
4. Mejora continua del proceso: IDEAL, ISO/IEC 15504, SPI

Figura 1.3 - Dependencia entre Calidad de Producto y Calidad de Proceso

 1.3.1. Control de Calidad:
Para controlar la Calidad del Software es necesario, definir
los parmetros, indicadores o criterios de medicin.

El software posee determinados ndices medibles que son

las bases para la calidad, el control y el perfeccionamiento
de la productividad.

Una vez seleccionados los ndices de calidad, debe

establecerse el proceso de control, que requiere los
siguientes pasos:

1. Definir el software que va a ser controlado: clasificacin

por tipo, mbito de aplicacin, complejidad, etc., de
acuerdo con los estndares establecidos para el
desarrollo del software.

2. Seleccionar una medida que pueda ser aplicada al

objeto de control. Para cada clase de software es
necesario definir los indicadores y sus magnitudes.
3. Crear o determinar los mtodos de valoracin de los
indicadores: mtodos manuales como cuestionarios o
encuestas estndares para la medicin de criterios
parciales y herramientas automatizadas para medir los
criterios de clculo.

Los procedimientos pueden variar en cada organizacin,

pero lo importante es que estn escritos, personalizados,
adaptados a los procesos de la organizacin y, lo que es ms
importante, que se cumplan. La Calidad del Software debe
implementarse a lo largo de todo el ciclo de vida, debe correr
paralela desde la planificacin del producto hasta la fase de
produccin del mismo.
Para ello se cuenta con una serie de ayudas, a travs de
distintas actividades para la implantacin del control de
calidad en el desarrollo que son:
Aplicacin de metodologa y tcnicas de desarrollo
Reutilizacin de procesos de revisin formales
Prueba del software
Ajustes a los estndares de desarrollo
Control de cambios, mediciones y recopilacin de
informacin
Gestin de informes sobre el control de calidad

Para la fase de Planificacin, se pueden utilizar elementos y

herramientas propias de la Gestin de proyectos, como la:
Estimacin de la duracin, costo y esfuerzo para la
construccin del producto. En lo referido a la estimacin
habr que tener presentes las Mtricas de software
Planificacin de tareas que hay que realizar, asignacin
de personas, tiempo, costo y otros parmetros para
construccin del producto
 Para los procesos de Anlisis y Diseo deberemos contar con:
Sistemas de obtencin de requisitos
Mtricas de software
Herramientas de Generacin de Datos
Casos de Prueba

En los procesos de Construccin y pruebas deberamos usar:

Herramientas de Gestin de la Configuracin
Herramientas de Simulacin
Casos de Pruebas

Y, finalmente, para el proceso de Produccin, bsicamente

debemos utilizar:
Herramientas de monitoreo de resultados
Pruebas de produccin

Definir las regulaciones organizativas para realizar el control: quienes

participan en el control de calidad, cundo se realiza, qu documentos
deben ser revisados y elaborados, etc.

El Instituto de Ingeniera de Software (SEI) en su modelo CMM define

la calidad como:

El grado en el cual un sistema, componente o proceso cumple con

los requisitos especificados.
El grado en el cual el sistema, componente o proceso cumple con
las expectativas del cliente o usuario.

1.3.2. Aseguramiento de Calidad:

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. El aseguramiento pretende dar confianza en que el
producto tiene calidad.

Aseguramiento de calidad se enfoca en identificar y evaluar

los defectos que puedan afectar al software. Si los errores se
pueden identificar de forma temprana en el proceso de
software, las caractersticas del diseo de software se
pueden especificar de modo que eliminarn o controlarn los
peligros potenciales, al corregir los errores mucho antes en
cada etapa es decir durante el proceso, ahorrando
esfuerzos, tiempo y recursos.

Sridharan (Sridharan, 2000) indica que mientras el software

que se est desarrollando rene los requerimientos y su
desempeo sea el esperado, es preciso que se supervisen
las actividades de desarrollo del software y su rendimiento,
en distintas oportunidades durante cada fase del ciclo de
vida. Este es el papel del aseguramiento de la calidad del
software.

Hay tres aspectos muy importantes con relacin al

aseguramiento de la calidad del software: (Wiegers, 1990)

i) La calidad no se puede probar, se construye.

ii) El aseguramiento de la calidad del software no es una

tarea que se realiza en una fase particular del ciclo de
vida de desarrollo.

iii) Las actividades asociadas con el aseguramiento de la

calidad del software deben ser realizadas por personas
que no estn directamente involucradas en el esfuerzo de
desarrollo.

El aseguramiento de la calidad de software comprende una

gran variedad de tareas:

i) Participar en descripcin del proyecto de software.

ii) Auditar el producto de software para verificar el

cumplimiento del proceso de software definido.

iii) Asegurar que las divergencias en el trabajo de software

sean documentadas de acuerdo a los estndares
definidos.

iv) Almacenar cualquier inconformidad y reportarla a la

gerencia media.

v) Revisiones del software que se aplican durante cada

paso del desarrollo del mismo. Las revisiones del
software se aplican en varios momentos del desarrollo,
tanto en el anlisis como en el diseo y la codificacin, de
manera que puedan ser eliminados cuanto antes.
vi) 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.
 Figura 1.4 - Componentes del Aseguramiento de Calidad de Calidad
(SQA)

El grupo de aseguramiento de calidad participa en la revisin

de los productos seleccionados para determinar si se
conforman o no a los procedimientos, normas o criterios
especificados, siendo totalmente independiente del equipo
de desarrollo.

Las actividades a realizar por el grupo de aseguramiento de

calidad vienen gobernadas por el plan. Sus funciones estn
dirigidas a:

i) Identificar las posibles desviaciones en los estndares

aplicados, as como en los requisitos y procedimientos
especificados.

ii) Comprobar que se han llevado a cabo las medidas

preventivas o correctivas necesarias.

iii) Las revisiones son una de las actividades ms

importantes del aseguramiento de la calidad, debido a
que permiten eliminar defectos lo ms pronto posible,
cuando son menos costosos de corregir.

Es importante sealar que la calidad de un producto software no se

puede referir nicamente a obtener un producto sin errores. La
especificacin de la calidad del software debe ser ms detallada y
exacta, y el camino para ello es la formalizacin de la calidad mediante
un modelo de calidad.

Un modelo de calidad es un conjunto de buenas prcticas para el

desarrollo del software, enfocado en los procesos de gestin y
desarrollo de proyectos, cuyo objetivo es el desarrollo de productos de
calidad de manera consistente y predecible.

Existen distintos marcos de trabajo que nos ayudan a mejorar los

procesos de calidad de software. La finalidad de estos modelos es la
de mejorar los procesos de software, brindar pautas para efectuar
evaluaciones de la unidad informtica, determinar la potencialidad y
la efectividad de sus procesos, as como la madurez de la empresa.
Se busca mejorar los procesos de software, aumentar la productividad
la calidad reduciendo su costo.

2. MODELOS DE CALIDAD DE SOFTWARE

Los Modelos de Calidad son aquellos documentos que integran la mayor parte de las
mejores prcticas, proponen temas de administracin en los que cada organizacin
debe hacer nfasis, integran diferentes prcticas dirigidas a los procesos clave y
permiten medir los avances en calidad y lograr as innovar y mejorar continuamente para
poder crecer y ser ms competitivas.
Los Estndares de Calidad son aquellos que permiten definir un conjunto de criterios de
desarrollo que guan la forma en que se aplica la Ingeniera del Software. Los estndares
suministran los medios para que todos los procesos se realicen de la misma forma y son
una gua para lograr la productividad y la calidad en las empresas, disminuyendo costos
y tiempo en sus desarrollos.

Tambin los modelos permiten que las Empresas de Software realicen sus tareas y
funciones teniendo en cuenta la Calidad. Cualquier organizacin que se dedica a la
investigacin, produccin y comercializacin de software debe considerar la calidad, hoy
con ms razn, donde existe un mercado en el cual el cliente es cada vez ms exigente,
no slo en lo que se refiere al precio, sino, sobre todo, en cuanto a los servicios y a la
confiabilidad que brindan los productos de software. La calidad desempea un rol
determinante para la competitividad de la empresa.

Cuando una empresa est funcionando y decide implantar un Modelo / Estndar de

Calidad del Software, es seal que la empresa tiene el propsito de hacerse cada vez
ms profesional homogenizando los criterios sobre los cuales se debe producir los
productos y los servicios de software, que brindarn satisfaccin a sus clientes

2.1 Modelos de calidad de software a Nivel Proceso:

2.1.1 CMM (CAPABILITY MATURITY MODEL).

El CMM tiene como objetivo evaluar los procesos en sus distintos niveles de madurez,
identificar los niveles a travs de los cuales una organizacin debe formarse para
establecer una cultura de excelencia en la ingeniera de software. El modelo de madurez
de procesos fue generado a travs de la experiencia colectiva de los proyectos ms
exitosos de software, generando as un conjunto de prcticas importantes que deben
ser implantadas por cualquier entidad que desarrolla o mantiene software.

Se ha convertido en un factor estndar de calidad de software para industrias

internacionales, donde se ha concebido como un modelo la capacidad de los procesos
en la organizacin, el objetivo es crear producto de calidad predecibles y consistentes,
este modelo integra la disciplinas de la Ingeniera de sistemas e Ingeniera de Software
de esta manera nos permite eliminar redundancias e inconsistencias

Niveles de capacidad:

1 Inicial. Las organizaciones en este nivel no disponen de un ambiente estable para

el desarrollo y mantenimiento de software. Aunque se utilicen tcnicas correctas de
ingeniera, los esfuerzos se ven minados por falta de planificacin. El xito de los
proyectos se basa la mayora de las veces en el esfuerzo personal, aunque a menudo
se producen fracasos y casi siempre retrasos y sobre costes. El resultado de los
proyectos es impredecible.
2 Repetible. En este nivel las organizaciones disponen de unas prcticas
institucionalizadas de gestin de proyectos, existen unas mtricas bsicas y un
razonable seguimiento de la calidad. La relacin con subcontratistas y clientes est
gestionada sistemticamente.
3 Definido. Adems de una buena gestin de proyectos, a este nivel las
organizaciones disponen de correctos procedimientos de coordinacin entre grupos,
formacin del personal, tcnicas de ingeniera ms detalladas y un nivel ms avanzado
de mtricas en los procesos. Se implementan tcnicas de revisin por pares (peer
reviews).
4 Gestionado. Se caracteriza por que las organizaciones disponen de un conjunto de
mtricas significativas de calidad y productividad, que se usan de modo sistemtico para
la toma de decisiones y la gestin de riesgos. El software resultante es de alta calidad.
5 Optimizado. La organizacin completa est volcada en la mejora continua de los
procesos. Se hace uso intensivo de las mtricas y se gestiona el proceso de innovacin.

2.1.2 Modelo Tickit:

TickIt es primordialmente una gua que presenta las estrategias

para lograr la certificacin en la produccin de software a travs de la interpretacin de
los estndares ISO.

El objetivo del programa TickIt era ayudar a las organizaciones de software a crear
sistemas de calidad que agregaran valor a sus empresas y que cumplieran con la norma
ISO 9001:2000, ya que es, adems de mejorar y regular el comportamiento de los
auditores que trabajan en el sector de la tecnologa.

Tickit se basa en la norma ISO 9001:200 y exige una revisin completa cada 3 aos
Adems, una de las principales metas estimular a los desarrolladores de software a
implementar sistemas de calidad, dando la direccin y guas necesarias para tal efecto
TickIT tiene como meta principal estimular a los desarrolladores a pensar:

Que calidad existen en el contexto de los procesos de desarrollo de software.

Como puede ser lograda la calidad.
Como los sistemas de informacin de calidad pueden ser mejorados en forma
continua.

2.1.3. Modelo bootstrap

El inters principal del modelo bootstrap es evaluar y mejorar la capacidad del software,
Mediante esta metodologa se tratar la mejora de procesos de software. Se podra decir
que la mejora de procesos es en parte mejor que la reingeniera. Esta metodologa
mediante prcticas, herramientas y estndares de calidad internacional; mide evala y
propone mejoras al proceso de desarrollo de software

Bootstrap surge como parte del programa estratgico europeo para investigacin en
tecnologa de informacin. Este proyecto al igual que otros, tiene como principio el
reducir costos y mejorar la calidad previendo problemas. Su objetivo es desarrollar un
mtodo para la evaluacin de procesos de desarrollo de software. Inicialmente se bas
en el modelo de madurez de CMM aadiendo conceptos de calidad de ISO 9000, y
luego incluyo conceptos para poder evaluar desarrollos de software, desde pequeas
industrias, hasta grandes corporaciones. Para lograr esto puso nfasis en los conceptos
de ISO 9000generando guas para mejoras en procesos de desarrollo de software,
analizando evaluaciones y mejoras de los procesos de desarrollo.

La metodologa bootstrap engloba tanto la evaluacin para establecer el diagnstico de

un proceso para desarrollo de software, el cual incluye la organizacin, los mtodos y
la capacidad de ingeniera, las herramientas y la tecnologa, 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 .A lo resultante de la evaluacin bootsrap le aade una segunda dimensin a
los niveles del CMM.

Los objetivos de la metodologa Bootstrap:

Proporcionar soporte para la evaluacin de la capacidad de los procesos
utilizando un conjunto de prcticas de Ingeniera de Software.
Dar soporte a la evaluacin, indicando como el estndar ha sido aplicada 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.
Ayudar a incrementar la eficacia de los procesos poniendo en prctica los
requisitos del estndar en la organizacin.

Durante la evaluacin bootstrap los procesos organizacionales son evaluados, consiste

en 4 etapas principales:

1.- Etapa Preparacin: Se planean los pasos de evaluacin y recoge la informacin

sobre el contexto. El enfoque es respecto de las necesidades especficas y los objetivos
de la organizacin, lo cual determina la definicin y el alcance de la evaluacin.
Esto incluye encontrar a quien entrevistar, que unidades organizacionales involucrar y
la documentacin a ser usada.
esta etapa se realizan las siguientes tareas:
Tener claros los objetivos
Seleccionar proyectos a evaluar
Definir personal de evaluacin
Hacer acuerdo de confidencialidad

2.- Etapa de Ejecucin: La informacin sobre los procesos de la organizacin es

recogida a travs de entrevista y evaluaciones de documentos disponibles. Esto se hace
a nivel organizacional y de proyecto. A los entrevistados siempre se les pide que apoyen
sus ideas con evidencias. Las tareas de esta etapa son
Una breve reunin de apertura
Completar cuestionarios con caractersticas generales
Revisin preliminar de la evaluacin
Reunin final

Proceso de mejora en bootstrap:

El proceso para obtener el plan de mejora consiste en, primero evaluar las necesidades
de la organizacin. Despus, hacer una revisin y anlisis de los resultados de la
evaluacin, teniendo en cuenta las fortalezas y debilidades, Luego definir las
capacidades a mejorar, considerando un periodo de tiempo de 18 a 24 meses. Despus
se definen prioridades de acuerdo a un anlisis de impactos.
Finalmente, en base a los resultados, modificar la organizacin, estableciendo un marco
de tiempos para su desarrollo y evaluacin.

2.1.4. Personal Software Process(PSP)

El Personal Software Process (PSP) est diseado para ser usado por medio de un
Ingeniero de Software individual y tiene como objetivo guiar el planeamiento y desarrollo
de los mdulos de software y es adaptable a otras tareas del personal. Es una tecnologa
de SEI (Software Engineering Institute) que trae disciplina las prcticas de los ingenieros
de software.

El PSP est basado en los principios de mejoramiento de proceso, el enfoque del PSP
es el ingeniero individual. Para fomentar el mejoramiento a nivel personal, ofrece la
administracin y control del proceso al Ingeniero, haciendo que estos usen una
propuesta estructurada y disciplinada

El proceso de PSP consiste de un conjunto de mtodos, formularios y scripts que

muestran a los ingenieros como planificar, medir y administrar su trabajo.
Se aplica en la mayora de las tareas de desarrollo de software.

El principio de PSP es que para producir sistemas de software de calidad. El PSP est
diseado para ayudar a profesionales a utilizar las mejores prcticas. Para hacer un
trabajo de ingeniera de software los ingenieros deben planear antes de confirmar o
empezar sus trabajos y deben medir el tiempo de cada paso en el trabajo, los defectos
a eliminar y el tamao de sus productos que producirn.

Finalmente. los ing. deben analizar los resultados de cada trabajo, para luego mejorar
sus procesos personales

El PSP provee una estructura acerca del proceso de software y un punto de partida con
el cual desarrollar sus propios procesos personales.
PSP ha sido adaptado a varias tareas de la ingeniera de software, tales como desarrollo
de requerimientos de software, especificaciones de software y casos de prueba.

Las 3 medidas bsicas utilizadas en PSP SON:

PSP0 Y PSP0.1 Baseline Personal Process
Provee una introduccin a PSP y establece una base inicial de tamao histrico, tiempo
y datos de defectos. El paso inicial provee una base para la medicin del progreso y un
fundamente definido a mejorar.

PSP1 y PSP1.1
Estn enfocados respecto a las tcnicas de administracin, y hace una estimacin del
tamao y esfuerzo del planeamiento programado y de los mtodos del seguimiento
programado.

PSP2 y PSP2.1 Personal Quality Management

Agregan mtodo de administracin de la calidad a PSP que comprende:
Revisiones de cdigo.
Diseo personal.
Notacin de diseo.
Plantillas de diseo.
Tcnicas de verificacin de diseo.
Medidas para administrar la calidad del proceso y del producto.

El objetivo de la administracin de calidad en el PSP es encontrar y eliminar todos los

defectos antes de la primera compilacin.
Las revisiones son bastante efectivas para la eliminacin de la mayora de defectos
encontrados en la compilacin y las pruebas. Para reducir los defectos de las pruebas
son necesarios mejores diseos de calidad.

PSP3 Cyclic Personal Process

Este proceso est dirigido a la necesidad de escalar eficientemente sin sacrificar la
calidad o productividad. La productividad se define respecto de un rango de tamao
(mnimo o mximo). PSP3 introduce mtodos a utilizar cuando se desarrollan programas
a gran escala. En PSP los ingenieros utilizan datos para monitorear el trabajo y realizar
mejores planes. Se realiza una recopilacin de datos de cada etapa del proceso, del
tamao de los productos producidos y de la calidad de los productos. El tiempo que lleva
desarrollar un producto es determinado por medio del tamao del producto, los
ingenieros primero estiman el tamao de los productos que planean desarrollar.
Luego que los productos fueron realizados, los ingenieros miden el tamao de los
productos producidos:
Tiempo de desarrollo: Los minutos son la unidad de medida del tiempo de
desarrollo. Se evala el nmero de minutos de cada etapa de PSP.
Tamao: Provee una base para estimar el tiempo de desarrollo.
Defectos: es definido como un cambio que debe ser realizado en el diseo o
codificacin para que el programa compile correctamente.

Las principales medidas de calidad de PSP son:

Densidad de defectos: Se refiere a los defectos nuevos o modificados por lnea
de cdigo, encontrados en un programa.
Porcentaje de revisin: En el diseo de PSP y en las revisiones del cdigo, los
ing. revisan sus programas. A travs de PSP. Los ing. renen los daos de sus
revisiones y determinan que rpido se pueden revisar sus programas para
encontrar todos o la mayora de sus defectos.
Porcentaje de tiempo de desarrollo: Se refiere al porcentaje de tiempo dedicado
por el ing. en las etapas de desarrollo.
Porcentaje de defectos: Compara los defectos encontrados en una etapa
respecto de otra. Los principales porcentajes de defectos encontrados en la
compilacin y defectos encontrados en la revisin del cdigo divida en defectos
encontrados en la compilacin y defectos encontrados en la revisin de diseo.
Defectos de hora: Con los datos de PSP, los ingenieros pueden calcular el
nmero de defectos por hora. Esta medida se puede usar para guiar el
planeamiento personal.
 Figura 2.1

2.2. Modelos de calidad de software a nivel Producto

2.2.1 Modelo de 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.

La estructura del modelo Gilb pertenece a un grupo fijo el cual se compone de 4

dimensiones de calidad:
Capacidad de trabajos: Evala la capacidad natural del sistema para realizar su
trabajo.
Disponibilidad: Refleja la medida de la disponibilidad del sistema para realizar de
forma til el trabajo para el que fue diseado.
Adaptabilidad: Es la medida de capacidad de un sistema para ser modificado de
la manera correcta.
Usabilidad: Es la medida de la facilidad con que la gente ser capaz y estar
motivada para utilizar el sistema en la prctica.

2.2.2. Modelo CQM (Goal-Question-Metric)

Es una propuesta de objetivos y metas orientado a la definicin de modelos de calidad.

Se propone el paradigma GQM para evaluar la calidad de cada proyecto, este modelo
utiliza una propuesta para medir para definir un modelo de calidad hasta obtener las
mtricas respectivas con el anlisis e interpretacin de los datos de las mediciones
respectivas. Plantea el enfoque de medicin para evaluar la calidad del software basado
en la identificacin de objetivos a lograr.

El modelo CQM proporciona la estructura para obtener los objetivos cruciales del
proyecto. Consta de 3 etapas:
Listar los objetivos principales del desarrollo y mantenimiento del proyecto
Para cada objetivo, se deben obtener las preguntas que deben contestarse para saber
si se estn cumpliendo los objetivos.
Decidir que medir para poder contestar las preguntas de manera adecuada, es decir,
desarrollar un conjunto de mtricas que ayuden a responder la pregunta
Otro aspecto del modelo GQM es la interpretacin de datos recolectados en funcin de
las preguntas.

La idea fundamental del GQM es la medicin orientada a objetivos. De acuerdo a esto

el modelo GQM tiene tres niveles:
Nivel conceptual (Goal): Un objetivo y meta es definido para un propsito
especifico en base a las necesidades de la organizacin, teniendo distintas
razones, desde distintos puntos de vista relacionados en un ambiente en
particular
Nivel Operacional (Question): Es un conjunto de preguntas que son utilizadas
para caracterizar la forma de realizacin de una meta especifica.
Nivel Cuantitativo (Metric): Es un conjunto de datos que est asociado a toda
pregunta de manera cuantitativa. Para cuantificar una subcaracterstica se utiliza
un conjunto de mtricas. La interpretacin de mtricas es utilizada para
responder preguntas y concluir si la meta u objetivo se ha cumplido.

El modelo GQM es un enfoque til para decidir que medir, es un enfoque orientado a
metas, por lo tanto, permite a los que toman decisiones, elegir aquellas mtricas que se
relacionen a las metas ms importantes de los problemas ms urgentes.

2.2.3. Modelo McCall

El modelo de McCall fue el primero en ser presentado en 1977 y se origin motivado por
Air Forc y Dod. 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. los factores de calidad son demasiados abstractos para ser
medidos directamente, por lo que por cada uno de ellos se introduce atributos de bajo
nivel denominados criterios de calidad. algunos criterios de calidad son atributos
internos segn McCall que el atributo interno tiene un efecto directo en el atributo
externo correspondiente.

McCall propone tres perspectivas para agrupar los factores de calidad:

REVISIN DEL PRODUCTO HABILIDAD PARA SER CAMBIADO.

La revisin del producto incluye los siguientes factores de calidad:

1.- Mantenibilidad: Esfuerzo requerido para localizar y corregir fallas.
2.- Flexibilidad: Facilidad de realizar cambios.
3.- Testeabilidad: Facilidad para realizar el testing, para asegurarse que el producto no
tiene errores y cumple con la especificacin.
TRANSICIN DEL PRODUCTO ADAPTABILIDAD AL NUEVO AMBIENTE.
La transicin del producto incluye los siguientes factores de calidad:
1.- Portabilidad: Esfuerzo requerido para transferir entre distintos ambientes de
operacin.
2.- Reusabilidad: Facilidad de reusar el software en diferentes contextos.
3.- Interoperabilidad: Esfuerzo requerido para acoplar el producto con otros sistemas.

OPERACIN DEL PRODUCTO CARACTERSTICAS DE OPERACIN.

La operacin del producto incluye los siguientes factores de calidad:
1.- Correctitud: El grado en el que el producto cumple con su especificacin.
2.- Confiabilidad: La habilidad del producto de responder ante situaciones no esperadas.
3.- Eficiencia: El uso de los recursos tales como tiempo de ejecucin y memoria de
ejecucin.
4.- Integridad: Proteccin del programa y sus datos de accesos no autorizados.
5.- Usabilidad: Facilidad de operacin del producto por parte de los usuarios.

2.2.4. Modelo Furps

El modelo Furps, plantea dos categoras de requerimientos, las cuales son:

1.- Requerimientos funcionales: Especifican funciones que el sistema debe ser capaz
de realizar sin tomar restricciones a travs de entradas y salidas esperadas.
2.- Requerimientos no funcionales URPS: Describen atributos del sistema o atributos
del ambiente del sistema.

Furps se aplica realizando los siguientes pasos:

- Asignacin de prioridades
- Definicin de los atributos de calidad que pueden ser medidos

2.2.5. Modelos de Boehm

Los modelos de Boehm agrega algunas caractersticas a las existentes en los modelos
de MCCALL y representa una estructura jerrquica de caractersticas, cada una de las
cuales contribuye a la calidad total. Consiste en un modelo de descomposicin de
caractersticas de calidad en tres niveles:
Usos principales
Componente intermedios
componentes primitivos

Este modelo plantea factores de calidad formados por criterios de calidad y mtricas
respectivas.
El modelo de Boehm tiene como finalidad que a travs de la calidad de software:
Realiza lo que desea el usuario.
Utiliza recursos informticos de manera correcta y eficiente.
Sea fcil de utilizar y aprender.
Sea bien diseado, codificado, probado y mantenido.

Este modelo es similar al de McCall ya que presenta una jerarqua de caractersticas,

las mtricas directas e indirectas son usadas para determinar el nivel de acuerdo a un
criterio en particular que afecta a los principales factores de calidad. Factores tales
como:
Portabilidad
Confiabilidad
Facilidad de mantenimiento
 Facilidad de modificacin

2.2.6. Modelo SATC (Software Assurance Technology Center)

SATC desarrollo 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. Este modelo utiliza un amplio rango de medidas
o mtricas y; tiene atributos y mtricas asociadas a los procesos de desarrollo y al
software propiamente dicho. Este modelo define un conjunto de metas u objetivos
relacionados al producto de software y atributos del proceso que permiten realizar
indicaciones de la probabilidad de xito de los objetivos. Un conjunto de mtricas es
seleccionado o desarrollado, el cual medir los atributos seleccionados.
A partir del concepto de calidad del software, se deducen 4 metas u objetivos

1.- Calidad de los Requerimientos:

El objetivo de esta meta es que los documentos de requerimientos estn completos, no
ambiguos y entendibles.
Esta meta tiene los siguientes atributos:
Ambigedad: Requerimientos con mltiples significados.
Integridad: tems a ser especificados.
Facilidad de entender: Documento legible.
Trazabilidad: Trazabilidad de los requerimientos generales respecto del cdigo
y de las pruebas.

2.- Calidad del Producto:

Un objetivo importante de un proyecto de desarrollo de software es desarrollar cdigo y
documentacin que se correspondan con los requerimientos del proyecto. Esta meta u
objetivo tiene los siguientes atributos:
+ Estructura/Arquitectura: la evaluacin de un mdulo para identificar posibles
errores e indicar problemas potenciales en la facilidad de uso y facilidad de
mantenimiento
+ Reutilizacin: Utilizar el software en diferentes contextos o aplicaciones
+ Facilidad de mantenimiento: Es el esfuerzo requerido para localizar y corregir un
error en un programa
+ Documentacin: tener la adecuada documentacin del cdigo interno y la
documentacin externa.

3.- Efectividad de la implementacin:

El objetivo de la efectividad de la implementacin es maximizar la efectividad de los
recursos dentro de las actividades programadas en el proyecto. Los atributos de este
objetivo son:
+ Uso del recurso: El uso del recurso relacionado a la etapa apropiada del
proyecto.
+ Cumplimiento de los porcentajes: Avances realizados en los tems.

4.- Efectividad de la prueba:

Los objetivos de la prueba de efectividad es ubicar y reparar las fallas del software. Una
vez generado el cdigo, se realizan pruebas de unidades, pruebas finales y pruebas de
aceptacin.
2.2.7. Modelo de Dromey

El modelo de Dromey tiene el propsito de trabajar con una estructura que permite
construir y utilizar un modelo de calidad para evaluar las etapas de determinacin de los
requerimientos, diseo e implementacin.

Esta informacin es usada para elaborar, comparar y evaluar la calidad de los productos
de software. 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.

Las caractersticas de la calidad del modelo de Dromey son:

Eficiencia
Confiabilidad
Facilidad de mantenimiento
Portabilidad
Facilidad de uso
Funcionalidad

Dromey propone una matriz que relaciona las caractersticas de calidad respecto de la
Norma ISO 9126 Dicha matriz presenta un mapeo entre las caractersticas del producto
y los atributos de alto nivel, el cual es utilizado en las evaluaciones del producto.

Figura 2.2

Los pasos para la aplicacin del modelo de Dromey son:

1. Seleccionar el conjunto de atributos que se necesitan evaluar.
2. Realizar una lista de todos los componentes o mdulos del sistema.
3. Identificar las propiedades de calidad de cada componente.
4. Determinar cmo afecta cada propiedad en los atributos de calidad.
5. Evaluar el modelo de calidad.

3. DEFINICIN DE VERIFICACIN Y VALIDACIN

3.1. DEFINICIN DE VERIFICACIN Y VALIDACIN.

El proceso de desarrollo adoptado por un proyecto depender de los objetivos y metas

que tenga el proyecto. Existen distintos modelos de ciclo de vida que se han
desarrollado para conseguir diferentes objetivos, pero en cualquiera de ellos ser
necesario un proceso que asegure la calidad a travs de todo el ciclo de vida de
desarrollo del producto. Al final de cada fase del ciclo de vida debera comprobarse que
el trabajo realizado hasta ese momento cumple con todos los objetivos previstos.

Este es el punto clave, en el que tiene lugar la evaluacin del producto, donde se decide
si est o no preparado para pasar a la siguiente fase. De esta forma, si hay errores y
son detectados, ser ms eficiente corregirlos que si se descubriesen en etapas ms
avanzadas. Este tipo de comprobaciones a lo largo del ciclo de vida incluyen dos
actividades: la verificacin y la validacin.

La validacin y la verificacin son procesos de evaluacin de productos que son tiles

para determinar si se satisfacen las necesidades del negocio y si se estn construyendo
acorde a las especificaciones.
La verificacin y la validacin no son lo mismo, aunque a menudo se confunden. Boehm
expres la diferencia entre ellas de la siguiente manera:
- Verificacin: Se est construyendo el producto de la manera correcta?
- Validacin: Se est construyendo el producto correcto?
El papel de la verificacin implica comprobar que el software est de acuerdo con su
especificacin. Debera comprobarse que satisface sus requisitos funcionales y no
funcionales.

La validacin, sin embargo, tiene como objetivo asegurar que el sistema satisface las
expectativas del cliente. Va ms all de la comprobacin de que el sistema satisface su
especificacin para demostrar que el software hace lo que el cliente espera que haga,
ya que las especificaciones del sistema no siempre reflejan los deseos o necesidades
reales de los usuarios y los propietarios del sistema.

El objetivo ltimo del proceso de verificacin y validacin es comprobar que el sistema

est hecho para un propsito. Esto significa que el sistema debe ser lo suficientemente
bueno para su uso previsto. El nivel de confianza requerido depende de:

El propsito o funcin del sistema. El nivel de confianza necesario depende de lo crtico

que sea el software para una organizacin. Por ejemplo, el nivel de confianza del
software que se utiliza para controlar un sistema de seguridad crtico es mucho ms alto
que el requerido para un prototipo de un sistema software que ha sido desarrollado para
demostrar nuevas ideas.

Las expectativas del usuario. Una reflexin lamentable sobre la industria del software
es que a muchos usuarios no les sorprende cuando su software falla durante su uso.
Estn dispuestos a aceptar estos fallos del sistema cuando los beneficios de su uso son
mayores que sus desventajas. Sin embargo, la tolerancia de los usuarios a los fallos de
los sistemas est decreciendo en los ltimos aos. Actualmente es menos aceptable
entregar sistemas no fiables, por lo que las compaas deben invertir ms esfuerzo en
llevar a cabo las actividades de verificacin y validacin.

Entorno de mercado actual. Cuando un sistema se comercializa, los vendedores del

sistema deben tener en cuenta los programas competidores, el precio que sus clientes
estn dispuestos a pagar por el sistema y los plazos requeridos para entregar dicho
sistema. Cuando una compaa tiene pocos competidores, puede decidir entregar un
programa antes de que haya sido completamente probado y depurado, debido a que
quiere ser el primero en el mercado. Cuando los clientes no estn dispuestos a pagar
precios altos por el software, pueden estar dispuestos a tolerar ms defectos en l.
Todos estos factores pueden considerarse cuando se decide cunto esfuerzo debera
invertirse en el proceso de validacin y verificacin.

3.2. VALIDACIN Y VERIFICACIN EN EL CICLO DE VIDA

La validacin y la verificacin son procesos costosos y para algunos sistemas, tales
como los sistemas de tiempo real con complejas restricciones no funcionales, ms de la
mitad del presupuesto para el desarrollo del sistema puede invertirse en ambos
procesos. Es necesario que haya una planificacin cuidadosa para obtener el mximo
provecho de las inspecciones y pruebas, y controlar los costes de los procesos de
validacin y verificacin. Dicha planificacin debera comenzar en etapas tempranas del
proceso de desarrollo, como se ver, con la ayuda de los modelos de ciclo de vida.
Existen distintos modelos que representan el ciclo de vida del producto. El modelo en
cascada es uno de los ms sencillos en cuanto a su diseo. Es el enfoque metodolgico
que ordena rigurosamente las etapas del ciclo de vida del software, de forma que el
inicio de cada etapa debe esperar a la finalizacin de la inmediatamente anterior.
En este modelo, las pruebas se realizan al final del ciclo de vida del proyecto por lo que
los defectos son detectados cerca de la fecha de implementacin del producto o
sistema, lo que supone un coste muy elevado en la correccin de defectos. El modelo
en cascada es un modelo tradicional, pero existen otros modelos que se ajustan mejor
a los proyectos actuales y que se explican a continuacin.

4. OBJETIVOS Y RESTRICCIONES
4.1. OBJETIVOS.

El proceso de pruebas de software tiene 2 objetivos distintos:

a. Para demostrar al desarrollador y al cliente que el software satisface sus

requerimientos.
Para el software a medida, esto significa que debera haber al menos una prueba para
cada requerimiento de los documentos de requerimientos del sistema y del usuario.
Para productos de software genricos, significa que debera haber pruebas para todas
las caractersticas del sistema que se incorporaran en la entrega del producto. Pueden
tener una fase de pruebas de aceptacin explicita en la que el cliente comprueba
formalmente que el sistema entregado cumple su especificacin.

Este objetivo conduce a las pruebas de validacin, en las que se espera que el sistema
funcione correctamente usando un conjunto determinado de casos de prueba que
reflejan el uso esperado de aquel. Para las pruebas de validacin, una prueba con xito
es aquella en la que el sistema funciona correctamente.

b. Para descubrir defectos en el software en que el comportamiento de este es

incorrecto, no deseable o no cumple su especificacin. La prueba de defectos est
relacionada con la eliminacin de todos los tipos de comportamientos del sistema no
deseables, tales como:

Cadas del sistema.

Interacciones no permitidas con otros sistemas.
 Clculos incorrectos y corrupcin de datos.

Este objetivo conduce a la prueba de defectos, en los que los casos de prueba se
disean para exponer los defectos. Los casos de prueba pueden ser deliberadamente
oscuros y no necesitan reflejar cmo se utiliza normalmente el sistema. Para las pruebas
de defectos, una prueba con xito es aquella que muestra un defecto que hace que el
sistema funciona incorrectamente.

Puntos importantes a tomar en el objetivo

- Probar si el software no hace lo que debe
- Probar si el software hace lo que no debe, es decir, si provoca efectos secundarios
adversos.
- Descubrir un error que an no ha sido descubierto.
- Encontrar el mayor nmero de errores con la menor cantidad de tiempo y esfuerzo
posibles.
- Mostrar hasta qu punto las funciones del software operan de acuerdo con las
especificaciones y requisitos del cliente.

4.2. RESTRICCIONES.

Idealmente algunas compaas deberan tener polticas para elegir este subconjunto de
pruebas en lugar de dejar esto al equipo de desarrollo. Estas polticas podran basarse
en polticas generales de pruebas, tal como una poltica en la que todas las sentencias
de los programas deberan ejecutarse al menos una vez. De forma alternativa, las
polticas de pruebas pueden basarse en la experiencia de uso del sistema y puede
centrarse en probar las caractersticas del sistema operacional. Por ejemplo:

1. Deberan probarse todas las funciones del sistema a las que se accede a travs de
mens.
2. Deben probarse todas las combinaciones de funciones (por ejemplo, formateado de
textos) a las que se accede a travs del mismo men.
3. En los puntos del programa en los que el usuario introduce datos, todas las funciones
deben probarse con datos correctos e incorrectos

5. PLANIFICACION DE PRUEBA DE SOFTWARE

Definiciones importantes
- Prueba (test): 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 especficas.
- Caso de prueba (test case): conjunto de entradas y condiciones que arrojan resultados
esperados desarrollados con un objetivo en partculas.

5.1. PLANIFICACIN

El plan de pruebas de software se elabora para atender los objetivos de calidad en un

desarrollo de sistemas, encargndose de definir aspectos como por ejemplo los mdulos
o funcionalidades sujeto de verificacin, tipos de pruebas, entornos, recursos asignados,
entre otros aspectos.

Cuando se piensa en su proceso de planificacin de pruebas, el mismo no deber

iniciarse con un documento. Es un proceso. Lo primero que se debe hacer es
comprender el contexto de su empresa o proyecto en particular. Comprender el contexto
es otra manera de decir comprender los valores, los procesos, las prcticas, las
filosofas, las polticas y las personalidades de aquellos con quienes se trabaja. Esto es
ms que los objetivos y requerimientos del proyecto: significa comprender cmo y por
qu funcionan la empresa y el equipo.

5.2. ALCANCE

Indica el tipo de prueba y las propiedades/elementos del software a ser probado.

Alcance del plan de pruebas, la cual muestra el alcance y el orden en que se realizaran.

5.3. PLAN DE PRUEBAS

El propsito del plan de pruebas es explicitar el alcance, enfoque, recursos requeridos,

calendario, responsables y manejo de riesgos de un proceso de pruebas. Note que
puede haber un plan global que explicite el nfasis a realizar sobre los distintos tipos de
pruebas (verificacin, integracin e integracin). Un plan de pruebas incluye:

5.3.1 Analizar los requerimientos de desarrollo de software

Para elaborar un plan de pruebas de software lo primero que debes hacer es entender
los requerimientos de usuario que componen la iteracin o proyecto, que son el sujeto
de la verificacin de calidad que se va a realizar.

Debers analizar toda la informacin de la ingeniera de requisitos, incluyendo la matriz

de trazabilidad, especificaciones y diseo funcional, requisitos no funcionales, casos de
uso, historias de usuario (si ests trabajando con metodologas giles), entre otra
documentacin.

Tambin es muy importante realizar entrevistas con el equipo encargado de la ingeniera

de requisitos para aclarar dudas y ampliar la informacin que sea necesaria.

5.3.1.1. Matriz de trazabilidad :Siguiendo la definicin establecida por el PMI, la matriz

de trazabilidad de requisitos es un cuadro que vincula los requisitos del proyecto desde
su origen hasta los entregables que lo satisfacen (Definicin de la gua del PMBOK 5).

La matriz de requisitos ayuda a asegurar que cada requerimiento agrega valor al

negocio.
5.3.1.2. Caso de uso: En el Lenguaje de Modelado Unificado (UML), un caso de uso es
una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de
sus servicios.
5.3.1.3. Historias de usuario: son descripciones cortas de una necesidad de un cliente
del software que estemos desarrollando. Su utilizacin es comn cuando se aplican
marcos de trabajo giles, tales como Scrum o el Extreme Programming (XP)

5.3.2. Identificar las funcionalidades nuevas a probar

A partir de la documentacin del anlisis de requisitos y de las entrevistas con el equipo

de ingeniera de requisito y desarrollo, debes identificar e incluir en el plan de pruebas
de software la lista de las funcionalidades (Caractersticas) totalmente nuevas.

Si ests trabajando con un sistema informtico nuevo, no tendrs problemas en

discernir, pues todas sern nuevas.

En el caso de desarrollos de software integrados a un sistema existente es necesario

revisar con los analistas de negocio y tambin con los arquitectos de software las
funcionalidades que forman parte del desarrollo de software, en todas las capas de la
arquitectura.

Qu hace un Arquitecto de Software?

Revisa las necesidades del negocio junto con los requerimientos no funcionales
y los relaciona con la solucin que se necesita implementar para cubrirlas.
Se asegura de la calidad de la solucin y de su mantenimiento en el tiempo.
Toma decisiones de diseo de alto nivel.
Dicta estndares tcnicos, de codificacin, herramientas y plataformas.

3.3 DEFINIR LA ESTRATEGIA DE PRUEBA

Describe la tcnica, patrn y/o herramientas a utilizarse en el diseo de los casos de

prueba.
Es recomendable seguir un marco de referencia para determinar los tipos de prueba,
como por ejemplo los tipos de pruebas de software definidos por el ISTQB.

Qu es el ISTQB?

Es una organizacin dedicada a la calificacin y certificacin de profesionales y

empresas en el rea de Pruebas e Software, que ha ganado bastante prominencia en
tiempos recientes. las siglas significan "Comit Internacional de Calificacin en Pruebas
de Software", en ingls, "International Software Testing Qualifications Board" (ISTQB).

Figura 5.1 Estrategia de Pruebas

 Figura 5.2 Niveles de Pruebas

Figura 5.3 - Pruebas

5.3.3.1. Pruebas Unitarias: Se concentran en probar cada componente individualmente

para asegurar que funcione de manera apropiada como unidad.
Herramientas para las pruebas unitarias:
- JUnit TestNG (versin mejorada de JUnit)
- PHPUnit
- CPPUnit
- NUnit (.Net)
- MOQ (creacin dinmica de objetos simuladores, mocks)
5.3.3.2. Pruebas de integracin: Las pruebas de integracin tienen dos objetivos
principales:
- Descubrir errores asociados con las interfaces de los mdulos.
- Ensamblar sistemticamente los mdulos individuales para formar subsistemas y al
final un sistema completo.

Existen dos enfoques:

- Big bang, combinar todos los componentes y probar el sistema como un todo.
- Integracin incremental, los componentes se integran y prueban poco a poco.

5.3.3.3. Pruebas de alto nivel

Pruebas de validacin, se enfocan en los requerimientos.

Prueba del sistema, se enfoca en la integracin del sistema (Hw, informacin,
personas).
Prueba de recuperacin, fuerza el software a fallar en diferentes formas y verifica que
ste se recupere adecuadamente.
Prueba de seguridad, verifica que los mecanismos de proteccin integrados en el
sistema realmente impidan irrupciones inapropiadas.
Prueba de resistencia, ejecutan un sistema de manera que se demanden recursos en
cantidades, frecuencias o volmenes anormales.
Prueba de desempeo, prueba el desempeo del software en tiempo de ejecucin
dentro del contexto de un sistema integrado.

5.3.3.4. Depuracin: La depuracin de programas es el proceso de identificar y corregir

errores de programacin. En ingls se conoce como debugging, porque se asemeja a
la eliminacin de bichos (bugs).
Herramientas de depuracin
Valgrind Valgrind es una herramienta que permite detectar fcilmente errores (bugs)
en el manejo de memoria e hilos (threads) Funciona con programas escritos en cualquier
lenguaje o mezclas de ellos gracias a que trabaja directamente con el cdigo binario.
Valgrind se ha empleado para detectar errores de memoria en numerosos proyectos
importantes: OpenOffice, Mozilla Firefox, MySQL, Perl,, PHP Yahoo! ,Messenger,
PACX-MPI, etc.
5.3.3.5. Mtodos de prueba
Existen dos mtodos bsicos para disear casos de prueba
5.3.3.5.1. De caja blanca (o estructurales)
Verifican la correcta implementacin de las unidades internas, las estructuras y sus
relaciones Hacen nfasis en la reduccin de errores internos
5.3.3.5.2. De caja negra (o funcionales)
Verifican el correcto manejo de funciones externas provistas o soportadas por el
software Verifican que el comportamiento observado se apegue a las especificaciones
del producto y a las expectativas del usuario.
PRUEBAS SIN ESTRATEGIA
-Motivacin
. Las pruebas son incomodas
. Las pruebas son aburridas
.Estoy seguro de que lo he codificado bien
-Probar todo un conjunto
. Fallas por todas partes
. Muy difcil de diagnosticar las causas de los fallos
. Muy costoso de arreglar
. Resultado ->productos finales defectuosos

5.4. Identificar los entornos (ambientes) requeridos

Posteriormente se definen y documentan las caractersticas de los entornos de

Hardware y Software necesarios para realizar la ejecucin de las pruebas de software.
Esta informacin se obtiene a partir del equipo de desarrollo y de los arquitectos de
software, quienes pueden suministrar los requisitos mnimos y ptimos para la operacin
del sistema.

Como mejor prctica, el ambiente de pruebas de software debera ser lo ms similar

posible al ambiente de produccin, sin embargo, no siempre es posible debido a
limitaciones de recursos (financieros). En estos casos debe estudiarse cuales son los
requisitos que aseguran un mnimo de confiabilidad de estas pruebas respecto al
entorno de produccin.

Adems, en esta seccin del plan de pruebas, tambin se definen los requisitos de
sistemas operativos, software y herramientas de las estaciones de trabajo de los
Testers.

Si el alcance del proyecto incluye pruebas de aplicaciones (Apps) para mviles, es

necesario definir los emuladores y telfonos inteligentes, con sus respectivos requisitos.

Caractersticas que deben tener los ambientes

- Debe residir en un computador distinto al personal del desarrollador. Preferiblemente

en un servidor compartido por los equipos de pruebas de software.
- Utilizar nombres de dominio (no direcciones IP) distintos a los de produccin y
desarrollo para evitar confusin del personal de pruebas.
- Ser lo ms similarmente posible al ambiente de produccin, incluyendo:
o Aplicaciones locales, cliente servidor, web, etc.
o Configuracin de servidores.
o Manejadores de Bases de datos de produccin, de las mismas versiones.
o Configuracin de base de datos.
o Cuentas de usuario de sistema operativo, bases de datos y aplicaciones con la
misma configuracin y privilegios de acceso.
o Componentes de infraestructura deben ser similares (Ej. Clusters).
o Versiones de software.
o entre otros.

Tambin deben definirse los requisitos de hardware y software para los siguientes
componentes:

Herramienta de gestin de calidad de software.

Testlink

Testlink es un sistema de gestin de pruebas de software basado en la web, es de

cdigo abierto (Open Source) y dispone de una amplia comunidad de foristas y
voluntarios que publican guas e informacin sobre cmo utilizarlo.

Figura 5.3

Para organizar las pruebas de software, Testlink define tres unidades de informacin
bsicas que son el Proyecto de pruebas (Test Project), Plan de pruebas (Test Plan) y el
usuario (User), el resto de la informacin son relaciones entre estas bases.

Herramientas para automatizacin de pruebas.

Selenium

Es un framework para pruebas de aplicaciones Web, descargable de forma

gratuita desde su sitio web. Proporciona una herramienta de gabracin y
playback, que permite desarrollar pruebas sin necesidad de aprender un
lenguaje de Scripting.

Incluye caractersticas como grabacin, playback, seleccin de campos, auto

completar formularios, pruebas de recorrido (Walkthrough), debug, puntos de
control, scripts ruby y otros formatos.
 Figura 5.4

5.5. Establecer la metodologa y procedimientos de prueba

La metodologa de pruebas de software depender de la que se est utilizando para la

gestin del proyecto.

Si se est utilizando una metodologa predictiva, las pruebas de software comenzaran

con la estimacin del esfuerzo de pruebas, diseo y luego la ejecucin de las pruebas.
Si se estn utilizando metodologas giles de desarrollo de software, debe estar alineada
con el manifiesto gil.

Luego se seleccionar la metodologa de referencia, se documentan los procedimientos

para diseo y ejecucin, siguiendo el orden de los pasos definidos, flujos de procesos,
condiciones para tomar decisiones, y dems aspectos.

5.6. RECURSOS

Especifica las propiedades necesarias y deseables del ambiente de prueba, incluyendo

las caractersticas del hardware, el software de sistemas (p. ej. el sistema de operacin),
cualquier otro software necesario para llevar a cabo las pruebas, as como la colocacin
especfica del software a probar (p. ej. qu mdulos se colocan en qu mquinas de una
red local) y la configuracin del software de apoyo. La seccin incluye un estimado de
los recursos humanos necesarios para el proceso. Tambin se indican cualquier
requerimiento especial del proceso: actualizacin de licencias, espacio de oficina,
tiempo en la mquina de produccin, seguridad.

5.7. DOCUMENTACION

Explicita los documentos a entregarse al culminar el proceso previsto por el plan p. ej.
Subplanes, especificacin de pruebas, casos de prueba, resumen gerencial del proceso
y bitcora de pruebas.
Estndares internacionales
 IEEE 829.-estandar para documentar pruebas de software. Especifica 8 etapas
del proceso de documentacin.
Planeacin de las pruebas
Especificacin del diseo de prueba
Especificacin de los casos de prueba
Especificacin del procedimiento
Reporte de avance de los ciclos probados
Registro de prueba
Reporte de incidencias
Sumario de la prueba
5.8. Matriz de responsabilidades

Puede usarse una Matriz RACI o Matriz RAM como plantilla. Esta se define con perfiles
genricos o inclusive con el equipo de trabajo si ya se conoce cul es el que ser
asignado.

Las tareas del plan de pruebas deben estar alineadas con las habilidades y
conocimientos de cada persona.
Cronograma

Elaborado a partir de la estimacin de las actividades de Software Testing realizada

por el equipo.
Para elaborar un cronograma real, es importante definir actividades crticas como por
ejemplo los tiempos de instalacin de versiones en los entornos de pruebas, pruebas de
validacin de ambientes antes de comenzar a hacer las pruebas y las iteraciones por
incidencias, que es el tiempo invertido en volver a probar los casos de prueba fallidos
Premisas

Son las condiciones que deben cumplirse para que el cronograma sea realizable, estas
se determinan a partir de la documentacin de entornos y de los requisitos de personal.
Por ejemplo, disponibilidad de ciertos entornos, disponibilidad de personal con algn
conocimiento tcnico especifico, la metodologa que se va a utilizar, premias que deben
cumplirse para poder aplicarla, entre otros.

5.9. MANEJO DE RIESGOS E IDENTIFICACION DE RIESGOS

Al igual que un jefe de proyecto debe identificar riesgos y buscar soluciones durante la
etapa de desarrollo del software para conseguir los objetivos marcados, el test manager
debe identificar los riesgos relacionados con el proceso de pruebas, as como evaluar
la criticidad y probabilidad de los mismos. Gracias a este anlisis se podr generar un
plan de contingencia.
Explicita los riesgos del plan, las acciones mitigantes y de contingencia.
Falta de recursos y baja competencia en pruebas
Falta de los recursos necesarios para ejecutar las pruebas segn el plan
Tiempo reducido asigna
do a la fase de pruebas
Cambios frecuentes en la definicin de los objetivos y alcance del plan de pruebas
Falta de coordinacin entre los equipos de desarrollo y testing
Falta de experiencia con nuevas tecnologas, herramientas, lenguajes de
programacin,
Una caracterstica muy deseable de un equipo de pruebas es la pro-actividad, Incluso
antes de que el software comience a desarrollarse, el equipo puede involucrarse en las
distintas etapas de definicin para conocer ms en profundidad el proyecto, as como
comenzar a definir estrategias de pruebas.

Medidas a tomar para obtener los mejores resultados podran ser:

1. Intervencin temprana del equipo de pruebas en el proyecto

La inclusin del equipo de pruebas en las etapas iniciales del desarrollo del
producto ayudar a obtener mayor conocimiento del mismo as como permitir
detectar posibles defectos en etapas tempranas, por lo que el coste de
resolucin de los mismos ser inferior.

2. Preparacin de las pruebas

Antes de comenzar el desarrollo del producto, el equipo de pruebas podr
comenzar a disear el plan a seguir as como identificar futuras necesidades.
Herramientas a utilizar, configuracin de entornos,

3. Definicin de los criterios de entrada salida

No refirindose a los datos, sino los puntos de unin con otras plataformas e
integraciones con terceros. Es muy til definir y mantener las interfaces y
mecanismos de comunicacin con terceros para evitar futuros problemas.

4. Requerimientos de pruebas
Desde el equipo de pruebas, se fomentar el uso de estndares, tecnologas
abiertas, as como buenas prcticas de desarrollo (por ejemplo, TDD, integracin
continua, etc)

5. Gestin de defectos
Una tarea de gran importancia es el seguimiento y priorizacin de los defectos
encontrados. Estos deben ser incluidos en los planings de siguientes iteraciones
para que sean resueltos. Adems, deben ser trazados para conocer cundo y
en qu versin han sido resueltos.

Siguiendo estos puntos, conseguiremos reducir en gran medida los riesgos ms

comunes durante el desarrollo de software. Hay que tener en cuenta que se debe
trabajar en sincrona con los dems grupos implicados, desde la parte de gestin,
pasando por desarrollo, pruebas, despliegue, Unos dependen de otros y los
problemas de unos se propagan a otros.

6. Medicin y mtricas del software

6.1. Medicin del software

La medicin del software se refiere a derivar un valor numrico desde algn atributo del
software o del proceso de software. Comparando estos valores entre s y con los
estndares aplicados en la organizacin, es posible sacar conclusiones de la calidad del
software o de los procesos para desarrollo. Por ejemplo, supongamos que una
organizacin hace planes para introducir una nueva herramienta de prueba de software.
Las mediciones del software pueden utilizarse para:

1. Hacer predicciones generales acerca del sistema. Haciendo mediciones de las

caractersticas de los componentes del sistema y reuniendo stas, podremos derivar
una estimacin general de algunos atributos del sistema, como el nmero de fallos.
2. Identificar componentes anmalos. Mediante las mediciones podemos identificar los
componentes que se salgan de lo normal. Por ejemplo, podemos medir los componentes
para identificar los de complejidades ms altas, los cuales suponemos que sern los
que tengan ms errores, para centrarnos en ellos en el proceso de revisin.
Proceso de Medicin
Ayudar en el diseo de pruebas ms efectivas; es por eso que propone un proceso de
medicin, el cual se puede caracterizar por cinco actividades:
a) FORMULACIN: La obtencin de medidas y mtricas del software apropiadas para
la representacin de software en cuestin.
b) COLECCIN: El mecanismo empleado para acumular datos necesarios para
obtener las mtricas formuladas.
c) ANLISIS: El clculo de las mtricas y la aplicacin de herramientas matemticas.
d) INTERPRETACIN: La evaluacin de los resultados de las mtricas en un esfuerzo
por conseguir una visin interna de la calidad de la representacin.
e) REALIMENTACIN: Recomendaciones obtenidas de la interpretacin de mtricas
tcnicas trasmitidas al equipo de software.

Mtrica del software

Una mtrica de software es cualquier tipo de medida relacionada con un sistema,

proceso o documentacin de software. Algunos ejemplos son las medidas que se
utilizan para calcular el tamao de un producto en lneas de cdigo; el nmero de fallos
encontrados en un producto de software entregado; y el nmero de personas/da
requeridas para desarrollar un componente del sistema.
Las mtricas son de control o de prediccin. Ambas pueden influir en la toma de
decisiones de gestin como muestra la siguiente figura:

Figura 6.1

Las mtricas de control suelen estar asociadas con los procesos, mientras que
las mtricas de prediccin lo estn a los productos. Ejemplos de las mtricas de
 control o de procesos son el esfuerzo y el tiempo promedio requerido para
reparar los defectos encontrados. Entre los ejemplos de mtricas de prediccin
tenemos la complejidad ciclomtica de un mdulo, la longitud media de los
identificadores de un programa, y el nmero de atributos y operaciones
asociadas con los objetos de un diseo.

CLASIFICACIN DE MTRICAS
a) 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.
b) 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 de mdulo, etc. Estas son los puntos
crticos en el diseo, codificacin, pruebas y mantenimiento.
c) 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.
d) 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.

6.2. Verificacin y Validacin en el proceso de desarrollo de software

El propsito de V & V es ayudar a la organizacin desarrolladora a construir durante el

ciclo de vida. Los procesos de V & V proporcionan una evaluacin objetiva de productos
y procesos a lo largo de ciclo vital. Esta evaluacin demuestra si los requisitos son
correctos, completos, precisos, consistentes y verificables.
Los procesos de V & V determinan si los productos de desarrollo de una actividad dada
se ajustan a los requisitos de esa actividad y si el producto satisface o no su uso previsto
y las necesidades del usuario.
La verificacin es un intento de asegurar que el producto este construido correctamente,
en el sentido de que la salida de una actividad cumpla con las especificaciones
impuestas en las actividades anteriores.
La validacin es un intento de garantizar que el producto cumple con su propsito
especfico. Tanto la verificacin y el proceso de validacin comienza temprano en la fase
de desarrollo o mantenimiento. Ellos proporcionar un examen de las principales
caractersticas del producto en relacin tanto con el predecesor inmediato del producto
como con las especificaciones a cumplir.
El propsito de planificar la V & V es asegurar que cada recurso, rol y responsabilidad
este claramente asignado.
Los documentos resultantes del plan de V & V deben describir los diversos recursos,
sus funciones y actividades, as como las tcnicas y herramientas usadas. Una
comprensin de los diferentes propsitos de cada actividad de V & V ayuda en la
planificacin cuidadosa de las tcnicas y los recursos necesarios para los propsitos. El
plan tambin se refiere a la administracin, comunicacin, polticas y procedimientos de
las actividades de V & V y su interaccin, as como reporte de defectos y requisitos de
documentacin.

PROCESO V & V
Es el proceso de todo un ciclo vital: La V & V debe aplicarse en cada etapa del software.

METAS DE LA V&V
La verificacin y la validacin deberan establecer la confianza de que el software es
adecuado al propsito. Esto NO significa que est completamente libre de defectos.
Sino que debe ser lo suficientemente bueno para su uso previsto y el tipo de uso
determinar el grado de confianza que se necesita.

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.

6.3. Modelo V (SEBok, Software Testing-Concept and Operations)

Existen un gran nmero de modelos de procesos de ciclo de vida del sistema, los cuales
podemos dividir en tres categoras:
1) Procesos pre especficos y secuenciales.
2) Procesos evolutivos y concurrentes (por ejemplo, el RUP, las variedades del modelo
V y modelos espirales)
3) Procesos interpersonales y no limitados (por ejemplo, desarrollo gil, Scrum, la
programacin extrema (XP) y los procesos basados en la innovacin).

Aqu nos centraremos especficamente en el modelo V, sus variaciones y sus

implicaciones generales para el diseo y desarrollo de sistemas.

Definicin de Modelo V
Es un modelo generalmente usado en algunas reas como ingeniera de software,
ingeniera de sistemas, ingeniera aeroespacial, ingeniera militar, aeronutica, TICs,
etc; sirve para ilustrar la naturaleza de las pruebas como una actividad el ciclo de vida
del sistema, y muestra cmo las pruebas pueden planificarse paso a paso.

Figura 6.2

Tipos de Modelo V
Das V-Modell.
Tambin llamado Modelo V Aleman es un modelo desarrollado por la Repblica Federal
Alemana en 1986, tuvo un origen militar en el desarrollo de software para sistemas de
informacin y armas.
La versin actual es V-Modell XT sus desarrolladores nos brindan lo siguiente:
1.1. Documentacin: Cubre todos los aspectos del V-Modell XT y est disponible en
formatos HTML y PDF.
1.2. Plantillas de producto: Las cuales nos ayudan a realizar mejor la planificacin e
implementacin de productos.
1.3. Herramientas: Viene con herramientas open source las cuales permiten adaptarnos
a las condiciones concretas del proyecto.
1.4. Ejemplos de proyectos: Incluye una muestra de proyectos en el mbito pblico,
militar e industrial.
Este modelo tiene su anlogo en USA el US government standard.

Figura 6.3

General Testing
En el desarrollo de software, el modelo V representa un proceso de desarrollo que
puede considerarse una extensin del modelo de cascada. En lugar de moverse hacia
abajo de manera lineal, las etapas de este proceso se doblan hacia arriba despus de
la fase de codificacin, para formar la V tpica. El modelo V muestra las relaciones entre
cada fase y su fase asociada de pruebas.

2.1- Fases de verificacin.

2.1.1- Anlisis de los requisitos:
En la fase de anlisis de requisitos, es el primer paso en el proceso de verificacin,
los requisitos del sistema se recogen mediante el anlisis de las necesidades
del usuario. Esta fase se ocupa de establecer lo que el sistema ideal tiene que
realizar. Sin embargo, no determina cmo se disear o construir el software.
2.1.2- Diseo del sistema:
El diseo de sistemas es la fase donde se analiza y comprende el negocio del sistema
propuesto estudiando el documento de requisitos de usuario. Ellos se dan cuenta de las
posibilidades y tcnicas por las que los requisitos del usuario se pueden implementar. Si
alguno de los requisitos no es factible, el usuario es informado del problema. Se
encuentra una resolucin y el documento de requisitos de usuario se edita en
consecuencia.
2.1.3- 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.
2.1.4- 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. Las
especificaciones del documento o del programa del diseo del nivel bajo contendrn
una lgica funcional detallada del mdulo, adentro pseudocdigo, tablas de la base de
datos, con todos los elementos, incluyendo su tipo y tamao todos los detalles del
interfaz.

2.2- Fases de validacin:

2.2.1- Prueba de unidad:
En el V-modelo del desarrollo del software, 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. Tambin
verifica que los cdigos sean eficientes y tengan estndares de la codificacin. La
prueba est generalmente caja blanca. Se hace usando el diseo de la prueba de unidad
elaborada durante la fase de diseo del mdulo.

2.2.2- Prueba de 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. Se hace usando el diseo de la prueba de la
integracin elaborada durante la fase de diseo de la arquitectura.

2.2.3- Prueba del sistema:

La prueba del sistema comparar las especificaciones de sistema contra el sistema real.
El diseo de la prueba del sistema se deriva de los documentos del diseo del sistema
y se utiliza en esta fase. La prueba del sistema est a veces automatizado usar las
herramientas de prueba. Una vez que se integren todos los mdulos varios errores
pueden presentarse. La prueba hecha en esta etapa se llama prueba del sistema.

2.2.4- Prueba de aceptacin del usuario:

Pone a prueba la fase de Anlisis de los Requisitos, consta de 2 etapas:

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

2.2.4.2- PROCEDIMIENTOS PARA CONDUCIR LA PRUEBA DE ACEPTACIN:

Defina los criterios de la aceptacin:
a) Requisitos de la funcionalidad y funcionamiento.
b) Requisitos de calidad del interfaz.
c) Requisitos de calidad totales del software.
d) Desarrolle un plan de la aceptacin:
e) Descripcin del proyecto.
f) Responsabilidades del usuario.
g) Descripcin de la aceptacin.
h) Ejecute el plan de prueba de aceptacin.

Figura 6.4

CONCLUSIONES
a) Una aplicacin probada reduce el riesgo de errores crticos en produccin.
b) El testeo de software es fundamental durante todo el ciclo de produccin de las
aplicaciones de software.
c) Las pruebas de Software ejecutan el software con el objetivo de establecer si se
ajusta a las especificaciones y si se adapta correctamente al ambiente de operacin.
Por lo tanto, el software testing no solo busca errores.
d) Si el cdigo es difcil de probar, entonces debera considerarse la re-escritura del
cdigo.
e) Los testers tienen que considerar el software y las funciones que realiza, sus
entradas y como se pueden combinar, y el ambiente en el que el software operar.
f) El desarrollo del testing se ha visto favorecido en ambientes acadmicos. Se
requiere traspasar este trabajo acadmico a ideas ms prcticas para su aplicacin
en el desarrollo de software.

Recomendaciones
1- Sobre calidad y software:
Recomendamos conocer la normativa que rige la calidad de los productos de
software para que nuestro software sobre sea del agrado de nuestros clientes.
2- Sobre modelos de calidad de software:
Recomendamos elegir un modelo adecuado para nuestro desarrollo segn el
proceso, el producto y el tiempo.
3- Sobre medicin y mtricas del software:
 Debemos conocer la medicin y mtricas para poder saber cul es el valor real
de nuestro producto de software y poder predecir su impacto en el mercado.

4- Sobre verificacin y validacin:

Recomendamos conocer de verificacin y validacin para poder realizar pruebas
efectivas.

5- Sobre el Modelo V:
Como ingenieros es necesario conocer este modelo en sus diferentes versiones
para poder aplicando en nuestros proyectos dependiendo del contexto y
nuestras necesidades.