FACULTAD DE INGENIERA, ARQUITECTURA Y

URBANISMO
ESCUELA PROFESIONAL DE INGENIERA DE
SISTEMAS
Asignatura

Ingeniera de la Software

Administracin de la Calidad del Software

AUTORES:
- Flores Tello Jaime Nicols
- Martnez Panta Vctor Manuel
- Monja Sandoval Elmer Anthony

Pimentel Per
2016
1

PRESENTACION
Hoy en da donde el mundo es ms globalizado, donde todo lo que se realiza
es cada vez ms automatizado, donde el recurso ms valioso es el tiempo se
necesita estar a la vanguardia de la tecnologa y estar a nivel de la
competencia para poder subsistir en el mercado y aspirar hacer lderes del
mismo.
Los Autores de dicho trabajo buscan facilitar y agilizar las tareas con este
sistema en un negocio como es su administracin de la Calidad del Software.

INDICE:
PRESENTACION........................................................................................... 2
INDICE:........................................................................................................ 3
I.- ADMINISTRACION DE LA CALIDAD DEL SOFTWARE.....................................4
Objetivos:.................................................................................................... 4
1.1.-CALIDAD DE SOFTWARE.......................................................................5
1.2.-LAS REVISIONES DEL SOFTWARE.........................................................5
1.2.1.-Revisiones Tcnicas Formales..........................................................6
1.2.1.1.-Quienes participan en la reunin?.............................................7
1.2.1.2.-Registro e informe de la revisin.................................................7
1.2.1.4.-Directrices para la revisin..........................................................8
1.3.-ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE...............................9
1.3.1.-Surgimiento de SQA (Software Quality Assurance)................................9
1.3.2.-SQA no es lo mismo que SQC (Software Quality Control)....................10
1.3.3.-Funciones generales del SQA.........................................................11
1.3.4.-Consideraciones............................................................................ 12
1.4.-PLANIFICACIN DE LA CALIDAD DE SOFTWARE..................................13
1.4.1.-A Nivel De Las Normas ISO.............................................................13
1.4.2.-A Nivel De Gestin De Calidad.........................................................14
1.5.-CONTROL DE CALIDAD........................................................................14
1.6.-NORMAS DE CALIDAD.........................................................................15
1.6.1.-Estndares ISO 9000.......................................................................16
CONCLUSIONES:....................................................................................... 17
LINKOGRAFA............................................................................................ 18

I.- ADMINISTRACION DE LA CALIDAD DEL SOFTWARE

Objetivos:
*Introducir los conceptos esenciales del manejo de calidad y los estndares
ISO 9000.

*Discutir los procesos del manejo de calidad.

*Explicar como los estndares pueden ser usados en el proceso de manejo de

calidad.

1.1.-CALIDAD DE SOFTWARE
La calidad del software es el conjunto de cualidades que lo caracterizan y que
determinan su utilidad y existencia. Es medible y varia de un sistema o programa a
otro. Un software hecho para ejecutarse una sola vez no requiere el mismo nivel de
calidad mientras que un software para ser explotado durante un largo necesita ser
confiable, mantenible y flexible para disminuir los costos.
La calidad del software puede medirse despus de elaborado el producto. Pero esto
puede resultar muy costoso si se detectan problemas deriva dos de imperfecciones en
el diseo, por lo que es imprescindible tener en cuenta tanto la obtencin de la calidad
como su control durante todas etapas del ciclo de vida del software.
Callaos y Callaos (1996) proponen un concepto de calidad del software en el cual
estn involucrados tanto caractersticas internas como el contexto organizacional, lo
que genera un enfoque sistmico del concepto de Calidad del Software.

1.2.-LAS REVISIONES DEL SOFTWARE

Las revisiones del software, son el conjunto de actividades que suceden como
resultado del anlisis, el diseo y la codificacin y que sirven para depurar las
actividades de ingeniera del software.
Una revisin, tiene como objetivos:

Sealar la necesidad de mejoras en el producto

Continuar las partes de un producto en las que no es necesaria o no es

deseable una mejora

Conseguir un trabajo tcnico de una calidad ms uniforme, o al menos ms

predecible, que la que puede ser conseguida sin revisiones, con el fin de hacer
ms manejable el trabajo tcnico.

Las revisiones de software se usan como modelo para la amplificacin de defectos y

para ilustrar la generacin y deteccin de errores durante los pasos de diseo
preliminar, diseo detallado y codificacin del proceso de ingeniera del software.

En cada paso del proceso de desarrollo de software, se presentan errores que

pasan inadvertidos y que producen un mayor nmero de errores si las revisiones
no lo detectan.
Los errores amplificados corresponden, a aquellos errores que pasan
inadvertidos desde pasos anteriores. De igual forma se representa el porcentaje
de eficiencia de la deteccin de errores.
Las revisiones software pueden ser:
a) Informales
No hay procedimientos definidos, por lo que la revisin se realiza de
la forma ms flexible posible.
Ventajas menor coste y esfuerzo, preparacin corta, etc.
Desventajas Detectan menos defectos
b) Semi -formales
Se definen unos procedimientos mnimos a seguir (walkthroughs)
b) Formales (Inspecciones)
Se define completamente el proceso
Revisin en detalle, por una persona o grupo distintos del autor, para:
Verificar si el producto se ajusta a sus Verificar si el producto
se ajusta a sus especificaciones o atributos de atributos de calidad y a
los estndares utilizados en la empresa
Sealar las desviaciones sobre los estndares y las
especificaciones
Recopilar datos que realimenten inspecciones posteriores
(defectos recogidos, esfuerzo empleado, etc.)

1.2.1.-Revisiones Tcnicas Formales

Una revisin tcnica formal (RTF) es un medio efectivo para mejorar la calidad
del software.
Los objetivos de la RTF son:

Descubrir errores en la funcin, la lgica o la implementacin de

cualquier representacin del software

Verificar que el software bajo revisin alcanza sus requisitos


Garantizar que el software ha sido representado de acuerdo con ciertos
estndares predefinidos

Conseguir un software desarrollado de forma uniforme

Hacer que los proyectos sean manejables

La RTF incluye:

Recorridos

Inspecciones

Revisiones cclicas

Evaluaciones tcnicas del software

Cada RTF debe estar debidamente planificada, controlada y atendida por el

grupo encargado de cada RTF.
Cada reunin debe tener las siguientes caractersticas:

Deben convocarse para la revisin entre tres y cinco personas

Se debe preparar por adelantado,

La duracin de la reunin de revisin, debe ser menor de dos horas

1.2.1.1.-Quienes participan en la reunin?

El jefe de revisin: quien lidera la reunin

Los revisores: uno de los cuales se encarga de registrar todos los

sucesos de la reunin.

El productor

1.2.1.2.-Registro e informe de la revisin

Como se mencion anteriormente, uno de los revisores es el encargado de
registrar todos los acontecimientos y conclusiones que van surgiendo
durante la RTF.

Al final de la reunin, hace un resumen de las conclusiones y genera una lista

de sucesos de revisin. Adems, prepara un informe sumario de la revisin
tcnica formal que responda a las siguientes preguntas:
Que fue revisado?
Quin lo revis?
Qu se descubri y cules son las conclusiones?

La lista de sucesos de revisin que se genera permite:

Identificar reas problemticas dentro del producto

Servir como lista de comprobacin para hacer las correcciones.

Adems, se adjunta, la lista de conclusiones al informe sumario.

1.2.1.4.-Directrices para la revisin

1. Revisar el producto, no al
productor

Se deben sealar los errores de forma constructiva y no

dificultar el proceso de revisin. Es importante mantener el
control de la reunin y descartar situaciones que se
escapen de control.

2. Fijar una agenda y

mantenerla

Se debe tener un plan de trabajo antes de la reunin. Se

debe seguir el orden del plan para que la reunin tenga
xito y cumplir con los tiempos asignados al plan.

3. Limitar el debate y las

impugnaciones

No se debe perder tiempo debatiendo situaciones que no

presenten unanimidad, es importante registrar el hecho y
dedicar otros tiempos para su debate.

4. Enunciar reas problemas,

pero no intentar resolver los
problemas que se pongan de
manifiesto.

La resolucin de problemas se debe programar para otros

espacios despus de la reunin de revisin.

5. Tomar notas escritas

Es buena idea utilizar diferentes herramientas para la toma

de notas, por ejemplo, pizarras, tableros, computador, para
que se pueda hacer seguimiento a la asignacin de
prioridades.

6. Limitar el nmero de
participantes e insistir en la
preparacin anticipada

Se debe limitar el nmero de revisores, los cuales deben

estar preparados para cada reunin y participar
activamente en el proceso de revisin.

7. Desarrollar una lista de

comprobacin para cada
producto que haya de ser
revisado.

Se deben desarrollar listas de comprobacin para los

documentos de anlisis, diseo, codificacin y pruebas.

8. Disponer recursos y una

agenda para las RTF

Cada RTF debe estar planificada e involucrar

modificaciones.

9. Capacitacin y
entrenamiento de los
revisores

Todas las personas que participen en el proceso de

revisin deben recibir un entrenamiento que se debe basar
en:

10. Revisar las revisiones

anteriores

El proceso

Psicologa humana

Son beneficiosas porque permiten descubrir problemas del

proceso de revisin.

1.3.-ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

1.3.1.-Surgimiento de SQA (Software Quality Assurance)
En los aos 50, el software comenz a encontrar su camino dentro de los
sistemas del DoD (del ingls Deparment of Defense of USA). Usualmente estos
proyectos estaban muy alejados de la planificacin, se pasaban del
presupuesto y tenan muchos problemas tcnicos. Frecuentemente no
funcionaban como se esperaba y muchos proyectos eran cancelados antes de
ser entregados. Durante este periodo los contratistas para el desarrollo de
software a menudo hacan estimaciones muy optimistas sobre el estado del
desarrollo del software. El DoD normalmente no era notificado de los
problemas en la planificacin, en la gestin del presupuesto y de problemas
tcnicos hasta muy avanzado el proyecto, cuando ya no eran capaces de
entender los problemas ni de evaluar el impacto de stos.

Para intentar resolver este problema se estableci la Verificacin y Validacin

Independientes (IV&V del ingls Independent Verification and Validation), un
proceso de ingeniera que empleaba metodologas rigurosas para evaluar la
correctitud y calidad del software a lo largo de su ciclo de vida.
El primer software en usar IV&V fue el programa del misil atlas a finales de los
aos 50. Desde el proyecto atlas se ha recolectado mucha informacin que
indica que los proyectos con IV&V se realizan o ejecutan mucho mejor que los
proyectos sin IV&V. Con el tiempo el rol del IV&V se convirti critico. La
actividad que llamamos SQA evoluciona directamente de la Verificacin y
Validacin Independientes(IV&V), muchas de las tareas que asociamos con
SQA son originarias de IV&V.
Luego durante los aos 70 la actividad de desarrollo de software comenz a
expandirse y las compaas de desarrollo de software fueron experimentando
los mismos pobres resultados que las agencias gubernamentales(DoD, NASA
etc.) en las dcadas tempranas. Las compaas tenan dificultad para entregar
el software dentro de los plazos, presupuesto y calidad planificados. Varios
proyectos desarrollados entre 1980 y 1990 fueron desastrosos, muchos
excedan ampliamente el presupuesto y la planificacin o entregaban software
de baja calidad que no se poda usar. Durante los 80 esta experiencia se
convirti en lo que conocemos como crisis del software, el tiempo consumido
en el mantenimiento exceda el tiempo insumido en la construccin de nuevos
productos de software.
Luego de la crisis del Software en los aos 80, SQA evoluciono hacia una
herramienta que las compaas de desarrollo de software utilizaban para
identificar de forma temprana los problemas de calidad en el proceso de
desarrollo. Mientras SQA era visto como un pequeo paso dentro del proceso
del desarrollo del software, muchos jefes de proyectos vieron beneficios
cuantificables a partir de integrar SQA dentro del proceso de desarrollo de
software.
En los 90 varias compaas de software ya tenan funciones de SQA dentro de
sus organizaciones.

1.3.2.-SQA no es lo mismo que SQC (Software Quality Control)

Generalmente cuando le preguntamos a un profesional de sistemas que es lo
que entiende por aseguramiento de la calidad del software, inmediatamente
comienza a hablar de testing, algunos de ellos incluyen a la validacin y
verificacin y luego empiezan a hablar de revisiones, las cuales son slo
extensiones del testing. Es decir, a menudo hay una confusin entre SQA y el
testing (el cual actualmente forma parte del rea de control de calidad del
software SQC).
Haciendo slo testing y revisiones no aseguramos la calidad de los productos,
sino aseguramos el cumplimiento de especificaciones tanto funcionales como
tcnicas. En el desarrollo de software la diferencia entre SQC y SQA no esta
clara y estos trminos a menudo se confunden, SQA se encarga de controlar el
cumplimiento del proceso, mientras que SQC son aquellas acciones del
10

aseguramiento de la calidad que proporcionan un medio para controlar y medir

las caractersticas de un elemento, proceso o facilidad respecto a los requisitos
establecidos.
La siguiente tabla expone sintticamente las diferencias entre control de
calidad y aseguramiento de la calidad.

Control de calidad
Detecta problemas en los
productos de trabajo.
Verifica que los productos de
trabajo cumplan con los
estndares de calidad
especificados en el plan de
proyecto.
Revisa el contenido del producto

Aseguramiento de la calidad
Asegura la adherencia a los procesos,
estndares y planes.
Evala que los procesos, planes y
estndares utilizados en el proyecto
cumplan con los estndares
organizacionales.
Revisa procesos

En conclusin, el rol del SQA es auditar que los distintos equipos de la

organizacin, inclusive el de SQC siguen los procedimientos, estndares y
procesos establecidos. El equipo de SQA debera establecer mtricas para
medir la efectividad del proceso. Como complemento el rol de SQC es tomar
una actitud activa de verificacin y validacin del resultado o salida del proceso
implementado.

1.3.3.-Funciones generales del SQA

Describir los diferentes roles que puede jugar el equipo de SQA en una
organizacin nos dar una visin clara de las funciones que puede llevar a
cabo.
Como polica del proceso: el trabajo del equipo de SQA es asegurar que el
desarrollo sigue el proceso establecido. Entre sus funciones en este rol se
encuentran:

Auditar los productos del trabajo para identificar deficiencias.

Determinar el cumplimiento del plan de desarrollo del proyecto y del
proceso de desarrollo de software.
Juzgar el proceso y no el producto.

Como abogado del cliente: el trabajo del equipo de SQA es representar al

cliente. Entre sus funciones en este rol se encuentran:

Identificar la funcionalidad que al cliente le gustara encontrar.

Ayudar a la organizacin a sensibilizarse con las necesidades del
cliente.

11

Actuar como un cliente de prueba para obtener una alta satisfaccin del
cliente.

Como analista el trabajo del equipo de SQA es recabar informacin. Entre sus
funciones en este rol se encuentran:

Juntar muchos datos sobre todos los aspectos del producto y del
proceso.
Con esta informacin ayudar a mejorar los procesos y los productos.

Como proveedor de informacin el trabajo del equipo de SQA es revisar qu

es lo que est hecho y decir cules objetivos tcnicos realmente estn
cumplidos para que la gerencia pueda tomar mejores decisiones de negocios.
Entre sus funciones en este rol se encuentran:

Proveer informacin tcnica objetiva para que la gerencia pueda usarla

para tomar mejores decisiones.
Proveer informacin apropiada de las clases de productos y de los
riesgos asociados con estos.
Concentrarse ms en la reduccin de los riesgos que en el
cumplimiento del proceso.

Como responsable de la elaboracin del proceso el trabajo del equipo de

SQA es participar en la definicin de los planes, procesos, estndares y
procedimientos para asegurar que se ajustan a las necesidades del proyecto y
que pueden ser usados para realizar las evaluaciones de QA y cumplir los
requerimientos del proyecto y las polticas de la organizacin. Para cumplir este
rol el aseguramiento de la calidad debera comenzar en las fases tempranas
del proyecto.
Aqu conviene aclarar que no necesariamente las personas que definen la
metodologa a seguir pertenecen al equipo de QA. Definir la metodologa puede
llegar a ser o no una actividad del equipo de QA. Una estructura posible en el
proceso de mejora del software puede ser contar con un SEPG (Software
Engineering Process Group) totalmente independiente del equipo de QA,
encargado de definir la metodologa mientras que el equipo de QA se limita a
verificar que se cumpla dicha metodologa.

1.3.4.-Consideraciones
Para ser efectivo, el equipo que realiza SQA debe ser independiente de la
organizacin de desarrollo. Aunque tener un grupo de auditora independiente
es difcil de aplicar en organizaciones chicas donde hay pequeos ambientes
de desarrollos. Pero si la organizacin es madura y tiene una cultura orientada
a la calidad, la funcin de SQA puede estar embebida en el proceso. Cuando el
equipo de SQA esta embebido en el proceso, se deben resolver varios
inconvenientes para garantizar la objetividad:

12

Todo aquel que realice actividades de aseguramiento de la calidad

debera estar entrenado en el aseguramiento de la calidad.
Las actividades de aseguramiento de la calidad realizadas para un
producto deberan ser separadas de aquellas involucradas en el
desarrollo y mantenimiento del mismo.
Debe estar disponible un canal de comunicacin independiente en el
nivel apropiado de la gerencia para poder escalar las no conformidades
cuando sea necesario.

El equipo de SQA provee a la gerencia de informacin fehaciente, objetiva en

el momento adecuado. La clave aqu esta en que el grupo de SQA provee a la
gerencia de informacin tcnica objetiva. La gerencia necesita ver a la gente de
SQA como una fuente de informacin significativa que puede ayudarla a tomar
decisiones difciles. La Gerencia usa esta informacin para tomar decisiones de
negocio apropiadas. La objetividad en la evaluacin de calidad de los procesos
y productos es crtica para el xito del proyecto.
La objetividad se logra con independencia del equipo de SQA y sentido comn
o criterio. Hay diferentes maneras de realizar evaluaciones objetivas, entre las
que se incluyen:

Auditoras formales realizadas por un rea de SQA independiente de la

organizacin.
Revisiones de a pares que pueden se realizadas con distintos niveles
de formalidad.
Revisiones rigurosas en el lugar de desarrollo.
Revisiones distribuidas y comentarios del producto.

Teniendo en cuenta estas consideraciones podemos decir que la tarea del

equipo de SQA es un conjunto planificado de tareas, actividades y acciones
ejecutadas independientemente de la organizacin que desarrolla software,
que provee a la gerencia del proyecto informacin fehaciente en un momento
preciso que puede ser usada para tomar decisiones de negocio apropiadas.

1.4.-PLANIFICACIN DE LA CALIDAD DE SOFTWARE

1.4.1.-A Nivel De Las Normas ISO
Segn la norma ISO 9000:2000, la planificacin de la calidad es la parte de la
gestin de la calidad enfocada al establecimiento de los objetivos de la calidad
y a la especificacin de los procesos operativos necesarios y de los recursos
relacionados para cumplir los objetivos de calidad.
Segn la norma ISO/IEC 90003:2004, la planificacin de la calidad facilita el
modo de adaptar la planificacin del sistema de gestin de la calidad a un
proyecto especfico, producto o contrato. La planificacin de la calidad puede
incluir referencias genricas, el proyecto, el producto y/o el contrato especfico
de procedimientos, como apropiados. La planificacin de la calidad debera ser
13

revisada de nuevo junto con el progreso del diseo y desarrollo, y los

elementos, en cada fase, deberan ser completamente definidos al comienzo
de dicha fase.
La Planificacin de la Calidad del Software a nivel de proyectos debera
considerar lo siguiente:
1. Inclusin de los planes de desarrollo.
2. Los requisitos de calidad relacionados con los productos y/o procesos.
3. Los sistemas de gestin de la calidad adaptando y/o identificando los procesos
e instrucciones especficos apropiados para el mbito del manual de calidad y
algunas exclusiones expuestas.
4. Los procesos de proyectos especficos e instrucciones, tales
como, especificacin de pruebas del software, detallando los planes, diseos,
casos de pruebas y procesos para la unidad, integracin, sistemas y pruebas
de aceptacin.
5. Los mtodos, modelos, herramientas, convenios de lenguajes de
programacin, bibliotecas, marcos de trabajo y otros componentes reutilizables
para ser usados en los proyectos.
6. Los criterios para el comienzo y final de cada fase o proyecto.
7. Los tipos de anlisis y otras verificaciones y actividades de verificacin para ser
llevadas a cabo.
8. Los procesos de gestin de la configuracin junto con las actividades de
seguimiento y las medidas para ser llevados a cabo.
9. Las personas responsables de aprobar los procesos de salida para su uso
posterior.
10. La formacin necesaria para el uso de herramientas, tcnicas y la organizacin
de la formacin previa a la habilidad necesaria.
11. Los registros para ser mantenidos y la gestin de cambios, como por ejemplo,
para recursos, escalas de tiempo y cambios de contrato.

1.4.2.-A Nivel De Gestin De Calidad

Es la parte de la Gestin de la Calidad encargada de realizar el proceso
administrativo de desarrollar y mantener una relacin entre los objetivos y recursos
de la organizacin; y las oportunidades cambiantes del mercado.
El objetivo es modelar y remodelar los negocios y productos de la empresa, de
manera que se combinen para producir un desarrollo y utilidades satisfactorias.
Los aspectos a considerar en la Planificacin de la Calidad de Software son:
Modelos/Estndares de Calidad de Software a utilizar, Costos de la Calidad de
14

Software, Recursos humanos y materiales necesarios, entre otras.

El plan de calidad define los atributos de calidad ms importantes del producto a
ser desarrollado y define el proceso de evaluacin de la calidad.
En la Planificacin de la Calidad de Software se debe determinar:

Rol de la Planificacin.

Requerimientos de la Calidad de Software.

Preparacin de un Plan de Calidad de Software.

Implementacin de un Plan de Calidad de Software

Preparar un Manual de Calidad.

1.5.-CONTROL DE CALIDAD
7 Principios de Control de Calidad
Hacer pruebas muestra la presencia de defectos
Hacer pruebas exhaustivas es imposible
Hacer pruebas anticipadamente
Agrupacin de errores
Paradoja del pesticida
Hacer pruebas depende del contexto
Falacia de ausencia de errores

15

1.6.-NORMAS DE CALIDAD
Principales organismos de normalizacin

Los estndares ANSI/IEEE estn orientados al aseguramiento de la calidad a nivel del

proyecto:

Std. 730: proporciona la estructura de la documentacin del plan de

aseguramiento de la calidad.

Std.1061: definicin de mtricas para productos y para procesos, as como

procedimientos para la recogida de valores de mtricas.

Existen tambin estndares para otras actividades relacionadas con la calidad

como pruebas, verificacin y validacin, revisiones, etc. Los principales se
recogen en la siguiente tabla.

1.6.1.-Estndares ISO 9000

16

Aspectos positivos:

Es un elemento competitivo para las empresas.

Proporciona confianza a los clientes.

Ahorra tiempo y dinero una vez que est implantado.

Implantado en ms de 90 pases y en todo tipo de empresas

industriales y de servicios.

Proporciona cierta seguridad de que las cosas se hacen tal y como se

han dicho que se han de hacer.

Aspectos negativos:

Es costoso de implantar, especialmente en las pequeas empresas.

Muchas veces se hace por obligacin.

Puede existir diferentes interpretaciones de los apartados del estndar.

Existe publicidad engaosa.

CONCLUSIONES:
El manejo de la calidad del software se refiere a asegurar que el
software cumple con estndares requeridos.

17

 Los procedimientos de aseguramiento de calidad debern estar

documentados en un manual de calidad organizacional.
Un plan de calidad de un proyecto deber identificar los requerimientos
especficos de calidad.
Los estndares de software son la reunin de las mejores prcticas.
Las revisiones son el medio principal para la implementacin del
aseguramiento de la calidad.

18

LINKOGRAFA

http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-softwareii/materiales/tema1-pruebasSistemasSoftware.pdf

http://datateca.unad.edu.co/contenidos/301404/301404_ContenidoEnLinea/lecc
in_34__revisiones_del_software.html

http://es.slideshare.net/lidizzg/definicion-de-calidad-y-calidad-de-software

http://sedici.unlp.edu.ar/bitstream/handle/10915/3956/3__Aseguramiento_de_la_calidad_del_software.pdf?sequence=11

http://ocw.uc3m.es/ingenieria-informatica/desarrollo-de-sistemas-deinformacion-corporativos-1/documentos/calidad-del-software

http://www.lsi.us.es/docencia/get.php?id=359

http://dankocs2012.blogspot.pe/2012/12/planificacion-de-la-calidad-desoftware.html

http://www.liderdeproyecto.com/articulos/gestion_de_la_calidad.html

https://jorgemontanoblog.files.wordpress.com/2011/10/control-de-calidad-desoftware-final.pdf

19