FundamentosDeCalidad SW

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS
UNIVERSIDAD DEL PERÚ, DECANA DE AMERICA

Facultad de Ingeniería de Sistemas e Informática
Programa de Titulación por Trabajo de Suficiencia Profesional 2018
Curso: Calidad del Software
1. Fundamentos de Calidad de Software
Lic. Luis Alarcón Loayza

Febrero -2019
1
Objetivo de la Clase:
• Comprender la función de Aseguramiento de Calidad (SQA)

y de Control de Calidad (SQC) que debe haber en un Centro
de Desarrollo de Software de una Empresa
• Revisar inicialmente todos los conceptos básicos que nos
permitan entender lo que es SQA y SQC y ejemplos.
• Conocer a alto nivel, como mejorar la calidad del producto
de software.
2
Agenda
Aseguramiento y Control de Calidad de SW
• ¿Por que es importante la Calidad del SW?

• ¿Qué es Calidad?
• Control de Calidad
• Aseguramiento de Calidad
• SQA: Objetivos y SQAP
• Técnicas y Practicas de SQA
• SQA en la Organización
• Ejemplos: aplicación de SQA
• Problemas que enfrenta el SQA
• Trabajo de SQA
Calidad de Software
3
¿Porque es importante asegurar la calidad del software?
La Calidad es una continua preocupación de todas las

empresas u organizaciones.
En las Organizaciones en General:
 La implantación del enfoque de Calidad en los procesos
de negocio, permite a las empresas controlar cada una de
sus actividades y por tanto, asegurar la mejora continua
y el éxito del negocio.
En las Organizaciones de TI /SI:
 La Ingeniería de Software persigue como objetivo
principal, la producción de Sistemas o Software de
Calidad, a bajo costo, a tiempo y sobre todo, a
satisfacción del usuario o cliente.
 La Calidad, es parte inherente de la Ingeniería de
Software.
4
La producción de Software de Calidad es parte de la Ing. Software.

/
 Leer : IEEE-SWEBOK: Capitulo XI Calidad de Software, y Capitulo V Pruebas de Software 5

Respondamos estas 02 preguntas:

1. ¿QUE TANTO SOFTWARE HAY EN LOS PRODUCTOS Y
SERVICIOS QUE HOY DIA UTILIZAMOS?
2. ¿CUAN CONFIABLE ES EL SOFTWARE QUE ESTA EN
ESTOS PRODUCTOS O SERVICIOS?
6
 Cada vez mas los productos o servicios que utilizamos y los

que tiene mayor demanda, depende del software (la salud, el
transporte, dispositivos móviles, dispositivos de comunicación,
equipos de música, autos, relojes, aviones, artefactos del hogar,
plantas industriales, etc.). El software esta en todo sitio.
 La calidad del software se ha convertido en un factor
determinante para el éxito de todos estos productos o servicios.
 Dentro de esta economía que no perdona, el éxito o el fracaso
usualmente dependen de una cosa: ¿De quién es el producto
de mejor calidad?
Impacto Económico del Software: EL SOFTWARE ESTA EN TODO SITIO

http://softwareimpact.bsa.org/eu/pdf/factsheets/EU_Spain_Software_Economic_Impact_FACTSHEET_es.pdf 7
Productos y su Diferenciación en cantidad de instrucciones
8
¿ES CONFIABLE EL SOFTWARE?
LAS CONSECUENCIAS DE LOS ERRORES DEL

SOFTWARE
 Los Sistemas Informáticos o Aplicaciones
de SW, nos facilitan la vida, pero cuando
FALLAN pueden traer consecuencias
catastróficas, incluso muerte y destrucción
a gran escala.
9
GRANDES ERRORES Y CONSECUENCIAS DEL SOFTWARE
Caso 1: Misión fallida: Ariane5
Ariane5,CoheteEuropeo
El 4 de junio de 1996 la Agencia Espacial

Europea lanzó el cohete Ariane 5.
39.0 segundos gira bruscamente y explota
36.7 segundos se desborda la memoria.
Costo aproximado: 7 mil millones de dólares

Pérdida aproximado: 500 millones de dólares
http://www.ima.umn.edu/~arnold/disasters/ariane.html
10
GRANDES ERRORES Y CONSECUENCIAS DEL SOFTWARE

Caso 1: El Lanzamiento del Ariane 5…
Vuelo 501, tuvo lugar el 4 de junio de 1996, fue la primera prueba de vuelo
del sistema desechable de lanzamiento del Ariane 5. No fue un éxito, la
lanzadera se destruyó 36.7 segundos después del lanzamiento debido a un
mal funcionamiento en el software de control, haciendo de este defecto del
software uno de los más caros de la historia.
El software del Ariane 5 reutilizó las especificaciones del Ariane 4,
pero la trayectoria de vuelo del Ariane 5 era considerablemente distinta y
superaba el rango para el cual el código reutilizado había sido diseñado. En
particular, la mayor aceleración del Ariane 5 provocó un fallo en los
ordenadores de respaldo ("back-up") y navegación inercial primarios, tras lo
cual las toberas de la lanzadera fueron dirigidas por datos espurios. Las
pruebas previas al vuelo nunca fueron ejecutadas sobre el código
reajustado bajo condiciones de vuelo simuladas del Ariane 5, por lo tanto el
error no fue descubierto antes del lanzamiento.
Fuente: Wikipedia.com
11
GRANDES ERRORES DEL SOFTWARE

Caso 2 : Sonda de la NASA Mars Climate Orbiter
Otro caso parecido, fue el de la sonda

de la NASA Mars Climate Orbiter, fue
lanzada a Marte, el 11 de diciembre de
1998 y 286 días después sobrevoló el
planeta rojo a 57 kilómetros de su
superficie en vez de los 150 previstos.
Consecuencia: Destrucción total de la
Sonda en la atmósfera marciana.
Causa del error: El culpable del error
en la trayectoria de la sonda fue el
'software' informático basado en la
Tierra. El fallo destruyó un proyecto de
327 millones de dólares.

Caso 3 : Quiebra de empresa de inversión Knight Capital
En agosto de 2012, un error de

programa casi provocó la quiebra de
la empresa de inversión Knight
Capital. La compañía perdió 500
millones de dólares en media hora
debido a que sus computadoras
comenzaron a comprar y vender
millones de acciones sin ningún tipo
de control humano. Como resultado,
el precio de las acciones de Knight
Capital cayó un 75% en dos días,
informa el portal popmech.ru.
13

Caso 4: La desactivación de los servidores del gigante
de Internet
La desactivación de los servidores del

gigante de Internet Amazon el verano
de 2012 privó a muchas personas de
sus datos almacenados en la nube. El
accidente, causado inicialmente por
una fuerte tormenta, se agravó
repentinamente debido a varios
errores del 'software' que provocaron
un fallo de programación en cadena.
14

Caso 5: Infraestructura: apagón en el noreste de
EE.UU.
En agosto del 2003 varios estados del
noreste de EE.UU. y la provincia
canadiense de Ontario se quedaron
sin luz debido a un corte
de energía resultado de un accidente
local. El accidente pasó desapercibido
a causa de un fallo del software de
vigilancia del funcionamiento de
General Electric Energy y provocó
una cadena de errores que origino el
gran apagón.
15

Caso 6: Transporte: Aerolínea American Airlines
En 2013, un error de programación

provocó el caos en la compañía
de Aviación American Airlines.
La unión de dos sistemas como
resultado de la fusión de varias
compañías aéreas originó un
fallo en el sistema de reserva de
pasajes. Concretamente, el
problema surgió cuando se intentó
unificar plataformas escritas en
diferentes lenguajes de
programación.
16

Caso 7: Automóviles Toyota
Toyota - Modelo Prius 2010
05/02/2010 Toyota retira 437 mil

autos híbridos con fallas técnicas, con
problemas en los frenos.
Pérdidas por 8,5 millones de dólares,

devolución a dueños.
Diagnóstico: Problema de un
programa de computación que
maneja los controles de los frenos
antibloqueo.
17

Caso 8: Otro caso -Toyota
Toyota Motor Corp
Retiro del Mercado 2,17 millones de vehículos
en Estados Unidos debido a problemas con el
acelerador, que podría quedar atascado en la
alfombrilla.
Con esto, Toyota ha retirado globalmente más
de 14 millones de vehículos para arreglar el
acelerador y otros defectos desde el 2009.
Fuente: 24Feb.2011
http://peru21.pe/noticia/718504/toyota-
retira17-mllns-vehiculos
18

Motivación - Caso 9: Microsoft
Evento de Presentación de Windows Vista
Año 2006
Desde un inicio la presentación de WV generó imagen
negativa en la audiencia mundial. Las ventas caen.
Los usuarios prefieren Windows XP.
Año 2009
Grave problema con la pantalla de WV, que hace la
laptop inutilizable
¿Windows 8, el ultimo gran fracaso de Microsoft?

Año 2012
Serios problemas de calidad enfrenta Microsoft por
quejas de su clientes, en el funcionamiento de sus
Móviles: Tablet MS y WindowsPhone con Windows 8.
http://www.enriquedans.com/2012/11/esta-microsoft-dandose-el-bofeton-del-siglo-con-windows-8.html
http://www.theguardian.com/technology/blog/2012/nov/09/microsoft-surface-cover-flaw
http://www.theverge.com/2012/11/18/3660974/htc-8x-lumia-920-reboot-freezing-battery-issues
19

Motivación - Caso 10: Therac - Canada
Therac–25
Instrumento médico usado para aplicar

radiación a pacientes con cáncer.
Junio 1985 a Enero 1987
Mensaje “Ninguna dosis”
Muerte y daños permanentes
Diagnóstico : Sobredosis de radiación
http://courses.cs.vt.edu/%7Ecs3604/lib/Therac_25/Therac_1.html
20
¿Porque es necesario asegurar la calidad del software ?
Grandes Errores del Software – Caso 10:

Rayos X letales del Therac 25
Una serie de pacientes recibieron una dosis
letal de radiación debido a un fallo de software.
El Therac - 25 era una máquina para radiación
terapéutica producida por la empresa Atomic
Energy of Canada Limited. Estuvo involucrada
con al menos, seis accidentes conocidos entre
1985 y 1987, en los cuales los pacientes
fueron objeto de una sobredosis masiva de
radiación, que en algunos casos fueron del
orden de centenas de “gray”. Al menos cinco
pacientes murieron por sobredosis. Estos
accidentes destacan los riesgos del control
software de sistemas críticos en términos de
seguridad (“safety-critical systems”).
Fuente: Wikipedia.com
Otras – grandes fallas de software :

https://actualidad.rt.com/actualidad/view/138158-catastrofes-programacion-culpa-software-computadora
21

Motivación - Caso 11: Argentina
Cajero Automatico tuvo una falla y entrego $ 60,000 demás
Lugar: Banco de la Nación – Sampacho, Argentina.

Fecha: 29-Abril-2009. Varias personas recibieron 4 veces mas de lo
solicitaban.
Diagnóstico: El sistema hizo una lectura equivocada de los billetes,
confundiendo los de 20 pesos por los de 100 pesos.
Muchos usuarios del cajero se encontraron que al tratar de retirar
una cifra, en realidad recibían mucho más de lo solicitado.
Ocurrió un viernes 11.00 pm. El Banco se entero gracias a un
vecino honesto que comunico el sábado temprano.
La noticia se propago tanto rápido. Un empleado del banco, señalo
que se ha registrado a una persona que concurrió 32 veces al cajero
a retirar dicho momento.
La maquina no registro el excedente que entrego.
http://www.puntal.com.ar/notiPortal.php?id=23052
22

Motivación - Caso 12: Chile
23

Motivación - Caso 13: Perú
Resultado de Examen de Docentes
Noviembre 2009 Software del MINEDU
Diagnóstico : Desplazamiento de las filas

del listado de los postulantes por puntaje
obtenido
Impacto político, marchas y protestas.
http://peru21.pe/noticia/371483/alegan-falla-tecnica-bajon-notas-prueba-
docente
24

Motivación - Caso 14: Perú
Cajero Automático
2009
Mujer retira S/.100 de Cajero Automático y la Máquina

le devuelve S/. 500 (5 veces lo que solicito)
Inédito: ¡¡ El Banco luego la denunció por ROBO !!

El Banco jamás reconoció su error o falla.
25

• Los errores del software le salen muy caro a Estados
Unidos: 59,500 millones de dólares al año.
• 50% de los fallos corresponde a los usuarios el resto a los
programadores y vendedores.
• Las pruebas al inicio del ciclo reducirían los costos por
fallos en 22,000 millones de dólares.
• 80% de los costos de desarrollo de programas se dedican
a detectar y corregir defectos.
• La Academia de Ciencias de Estados Unidos pidió al
Congreso una ley que atribuya a las casas de software
una responsabilidad civil por daños y perjuicios a las
empresa.
(*) Fuente México, Enero-2010, Sistema Nacional de Educación Superior.
Protección a los Consumidores: Fallos de Software y castigo por responsabilidad de los Desarrolladores
https://www.enriquedans.com/2009/05/los-fallos-del-software-y-la-responsabilidad-de-quien-lo-creo.html
Ejercicio Tarea 1: Próxima clase
Completar una lista de al menos 05 grandes fallas o

desastres ocasionados por un error de software en el Perú.
- Fecha
- Lugar / Organización donde ocurrió
- Descripción
- Causa probada o más probable
- Monto estimado de pérdida
- Usted: Qué se pudo hacer antes para evitarlo
Tarea 1:
Entrar a la pagina Web indicada, participe en clase explicando 02 de las 60 fallas de sistemas
informáticos mencionadas aquí, y que les haya impactado mas (ocasionados por errores de
software):
http://www.softwareqatest.com/qatfaq1.html
27
LA CRISIS DEL SOFTWARE

II Era III Era IV Era
I Era *Sist. Multiusuarios *Sist. Distribuidos *Potentes sistemas
*Por lotes *Tiempo Real *Incorporación de Inteligencia *Sistemas expertos
*Distribución limitada *Bases de Datos *Hardware de bajo costo *Redes neuronales
*Software a medida *Software como producto *Impacto en el consumo
1950 1960 1970 1980 1990 2000
«Crisis del Software»

Complejidad del software
-Muchos cambios en -Técnicas Interactivas -Aparecen las PC’s -Software complejo.

Hardware -Control en tiempo real -Cias. De Software venden -Muchos equipos
-Poca evolución del software -Mejora de los dispositivos Miles de dólares. controlados por SW.
-Desarrollo de software sin De almacenamiento. -Hardware estándar, el -Mayor % del PBI en
Planeación, y sin -Primeras casas de software Software marca la diferencia países desarrollados.
documentación -Problemas por el mantenimiento
28

Mas que de una crisis puntual se trata de una
enfermedad crónica.
Síntomas:
• los sistemas no responden a las expectativas de los usuarios.
• El software no es fiable y necesita de un mantenimiento permanente.
• El software se entrega muy a menudo con retrasos y con costos superiores a
los presupuestados (difíciles de predecir).
• A menudo el software se vuelve imposible de mantener carece de
transparencia y no se puede modificar o mejorar.
Consecuencias:
• Baja Calidad
• Baja Productividad
29

Problemática
Muchos se preguntaron en los 70’ y todavía siguen:
• ¿Porque sigue siendo un problema cumplir con los requerimientos?
• ¿Porqué lleva tanto tiempo terminar los programas?
• ¿ Porque es tan elevado el costo?
• ¿Porqué no podemos encontrar todos los errores antes de entregar el
software a nuestros clientes?
• ¿Porqué nos resulta tan difícil constatar el progreso conforme se desarrolla el
software?
• ¿Porque es alta la brecha de comunicación entre Desarrolladores y los
Usuarios?
Desafío de la Ingeniería de Software

• Mejorar la calidad del software, su fiabilidad y bajo costo.
30
Problemática
System Life Cycle Phases
1. Wild enthusiasm
2. Disillusionment
3. Total confusion
4. Search for the guilty
5. Punishment of the innocent
6. Promotion of nonparticipants
Source: High Tech joke Book, Oak Ridge Public Relations, Inc.
Fases del Ciclo de Vida de un Sistema

1. Entusiasmo Salvaje
2. Desilusionamiento
3. Total Confusión
4. Buscar a los culpables
5. Castigo de los inocentes
6. Promoción a los que no participan
31
PROBLEMÁTICA
Los costos de reparación de un Defecto de Software
Fuentes:
•Barrh Boehm, Software Engineering Economics, Prentice-Hall 1981
•National Institute of Standards & Technology, United States Department of Commerce,
"The Economic Impacts of Inadequate Infrastructure for Software Testing", May 2002
32
PROBLEMÁTICA
Brecha de Comunicación (Scharer’90)
33
PROBLEMÁTICA
Incumplimiento de Normas de Calidad Ejemplo: Perú
Muestra del bajo nivel de cumplimiento de la implementación de la NTP

ISO/IEC 12207, a pesar de su uso obligatorio (R.M.179-2004-PCM, Art.1º y 2º).
Leyenda:
 El 18.3 % cumplió,
 El 71.6% no lo efectuó,
 El 10.1% no responde
Fuente:
 Encuesta del INEI a
2,204 Entidades del
Estado. Publicado el
2012.
34
Conceptos y Terminologías
Relación entre Error, Defecto y Fallo
35
Error (error):
• Es una equivocación cometida por
un desarrollador. Algunos ejemplos de
errores son: un error de tipeo, una
malinterpretación de un requerimiento o
de la funcionalidad de un método.
• El estándar 829 de la IEEE coincide con
la definición de diccionario de error como
“una idea falsa o equivocada”. Por ende un
programa no puede tener o estar en un
error, ya que los programas no tienen ideas;
las ideas las tienen la gente.
36
Defecto (fault, defect):

• Un paso, proceso o definición de dato incorrecto
en un programa de computadora. ISO 9126.
• Una instrucción incorrecta, incumplimiento de los
requisitos de uso previsto. Un error puede conducir a
uno o más defectos.
• Un defecto se encuentra en un artefacto y puede
definirse como una diferencia entre la versión
correcta del artefacto y una versión incorrecta.
• De nuevo coincide con la definición de diccionario,
“imperfección”. Por ejemplo, un defecto es haber
utilizado el operador “<” en vez de “<=“.
37
Fallo (failure) :
• Un resultado incorrecto.
• En terminología IEEE, una falla es la discrepancia
visible que se produce al ejecutar un programa con un
defecto, respecto a la ejecución del programa correcto.
• Es decir, una falla es el síntoma de un defecto.
• La terminación dela capacidad de un producto de
realizar una función requerida o su incapacidad para
realizarla dentro de límites previamente especificados.
ISO 9126.
"Los errores del programador generan defectos en el

software que posteriormente se convierten en fallos si
dichos defectos no son detectados durante las pruebas".
38
Error Fault o Failure

Defecto
• Paso incorrecto en • Incapacidad de un
• Equivocación, sistema para
incorrecta acción programa de
computadora. funcionar.
humana
• Desviación de un
comportamiento
Colectivamente referido como: Incidencia

• Mencione 4 incidencias de software, precisando en cada

una: cual fue el Error, el Defecto y la Falla.
• Establezca en cada caso, las diferencias entre el Error, el
Defecto y la Falla, en cada caso.
40
¿Qué es Calidad? …
¿Cuál es de mejor calidad?
Hyunday Terracan
Lamborghini Gallardo
Volkswagen Escarabajo
41
Calidad es:
• ¿Lo que cuesta mas caro?

• ¿Lo que es más moderno?
• ¿Lo que usa una mejor tecnología?
42
Mitos populares de la calidad

 La calidad es un lujo.
 La calidad es intangible, no es medida.
 La calidad es costosa y reduce la productividad.
 La baja calidad significa malos trabajadores.
 La calidad es responsabilidad de Departamento de Calidad.
43
Referentes de la Calidad
Autor Aporte
Walter Shewhart Ciclo de Shewart (PDCA): "El proceso metodológico básico para asegurar las actividades
fundamentales de mejora y mantenimiento: Plan-Do-Check-Act (mejora continua)
y el control estadístico de procesos
Edward Deming Catorce principios para la dirección: Qué se debe contemplar para la dirección de la
organización.
Joseph Juran Trilogía de Jurán: "(1) La planificación de la calidad, (2) Control de la calidad y (3) Mejora
de la calidad, son los instrumentos de la Dirección en la gestión de la calidad"
Kaoru Ishikawa Círculos de Calidad: "Grupos de voluntarios, estables en el tiempo que tienen como
objetivo mejorar la calidad de los procesos y el entorno de trabajo".
Creador de Diagramas de Ishikawa causa-efecto.
Taiichi Ohno Just In Time JIT: "Sistema de gestión de producción que permite entregar al cliente el
producto con la calidad exigida, en la cantidad precisa y el momento exacto"
Masaaki Imai Kaizen: "Significa mejora continua en Japonés"
Genichi Taguchi Ingeniería de la Calidad: "Métodos para el diseño y desarrollo de los procesos de
industrialización con el máximo de eficiencia"
Kiyoshi Suzaki Gestión Visual: "Es un sistema que propone que la información necesaria está al alcance de
las personas que la usan para su trabajo"
44
Definiendo la Calidad
DOS PUNTOS DE VISTA DE LA CALIDAD:
Producer view of quality
Customer view of quality
Quality Assurance closes the gap
45
Calidad del producto software

A diferencia de los productos de un proceso industrial:
 El Software es un producto mental, no físico (su calidad
también)
 Se desarrolla, no se fabrica. (Costo en el diseño-implementación,
no en la producción)
 El software no se deteriora con el tiempo.
 Es artesanal en gran medida. Se construye a medida, en vez de
ser construido ensamblando componentes existentes en serie.
 El mantenimiento del software es mucho más complejo
que el mantenimiento en fábrica. Fallos en el software implica
cambios en el diseño.
 El software con defectos no se rechaza. Se asume que es
inevitable que el software presente errores.
 Es engañosamente fácil realizar cambios sobre un producto
software.
46
DOS PUNTOS DE VISTA DE LA CALIDAD:
Operacionalmente, la palabra “calidad” está referida a productos.

Se dice que un producto es de calidad si este está libre de
defectos.
 Punto de Vista de Calidad del Fabricante: El punto de vista
del fabricante tiene que ver con el cumplimiento de 04
caracteristicas: Hacer lo correcto (el producto), Haciendolo de
manera correcta, Haciendolo bien la primera vez y Hacerlo a
tiempo sin exceder el costo.
 Punto de Vista de Calidad del Cliente: Es el cumplimiento
de los requisitos a satisfacción. Esta es la visión de la
organizacion responsable del Proyecto y de los Procesos,
como tambien de los Productos y Servicios adquiridos,
desarrollados y mantenidos por estos procesos.
47
IEEE
“El grado con el cual un sistema, componente o
proceso satisface las expectativas del usuario o
cliente .
Kaoru Ishikawa
“Calidad de un producto significa que éste es el
más económico, el más útil y siempre satisfactorio
para el consumidor”
Crosby
Cero defectos.
48
Walt Disney
“I do not worry whether something is cheap or
expensive. I only worry if it is good. If it is good
enough, the public will pay you back for it”
----
No me preocupa si algo es barato o caro. Sólo me

preocupa si es bueno. Si es lo suficientemente bueno,
el público (cliente) te pagará por ello.
49
Enfoques de Calidad
Calidad según Demming

Calidad, es la aplicación de los principios y técnicas
estadísticas (métricas) en todas las fases del
proceso de la producción, orientada a la
fabricación más económica de un producto (o
servicio) que es útil y que tiene mercado.
Es la conformidad con requisitos y confiabilidad en

el funcionamiento
50
Drucker
Un buen producto no es el que cumple con una
determinada especificación, sino es el que es bien
recibido por el cliente.
“Olvidar el precio de un producto es reconocer su calidad“

- Frederic Henry Royce, cofundador de Rolls Royce.
Calidad de Software
51
Grado en el que un conjunto de características

inherentes a un sistema, componente o proceso
cumple con los requisitos*.
Requisito : Necesidad o expectativa del
usuario o cliente, generalmente implícita u
obligatoria*.
*Tomado de NTP-ISO 9000:2001: Sistemas de Gestión de

la Calidad. Fundamentos y Vocabulario
*Coincide con definición de la “American Society for
Quality, 2000”
Calidad de Software
52
CULTURA DE CALIDAD
¿Cuál es nivel de cultura de calidad de las organizaciones TI?
Respuestas o frases comunes que denotan el nivel de cultura actual
de la calidad en muchas organizaciones de TI:
1. “El Proyecto esta avanzado en un 90%” (Reporte de un Jefe preocupado

porque se acerca la fecha fin y no quiere que vean su retraso. Pareto 80/20)
2. “Yo te paso la voz mas luego, está casi listo” (Cuando el aparente tiempo
corto que el Programador insinúa, se convierte en varios días, incluso una
semana)
3. “Ya está pruébalo!” (Respuesta del Programador luego de que el
sufrido Probador detecta y le reporta un error, obviamente la corrección
nunca ha sido probada por el Programador)
4. “El error esta en tu maquina, todo está OK” (Respuesta del Programador al
Probador luego que recibe la lista de defectos encontradas en sus programa.
5. “No existe esa incidencia” (Para justificar el largo tiempo que le viene
tomando corregir una falla que no puede superarla)
Calidad de Software
53
CULTURA DE CALIDAD
Complete una lista de al menos 09 frases "celebres” que

revelen la falta de cultura de calidad (nivel de calidad
existente en una organización de TI / SI).
Las frases deben ser de un Gerente (3), un Usuario (3) y un
Programador (3). Indique además, en que situación y/o razón se
empleo dicha frase. (no usar las frases mencionadas en clase)
Algunas razones que originan estas frases:

• Personas que no quieren asumir o reconocer sus errores o deficiencias.
• Personas que tratan de salir del paso, buscando argumentos
irresponsables.
• Personas que buscan la forma de echar la culpa de sus errores a otros,
etc.
Calidad de Software
54
CALIDAD DEL SOFTWARE
02 puntos de vistas para definir la Calidad del Software:
 Punto de vista del Cliente (Watts Humphrey dice:)

“El grado en que un cliente y/o usuario percibe que el producto
software satisface sus necesidades”.
 Punto de vista de la Industria de SW: (Roger Pressman, define:)
“Grado en el que un producto de software satisface su
especificación de requerimientos explícita e implícitamente
definidos”.
 Desde estas 02 perspectivas el glosario de la IEEE para
Ingeniería de Software lo define como:
“El grado con el cual un sistema, componente o proceso
cumple con los requerimientos y, con las necesidades y
expectativas del usuario”.
Calidad de Software
55
CALIDAD DE SOFTWARE
“Capacidad de un producto de software para satisfacer

las necesidades explicitas e implícitas cuando se usa en
determinadas condiciones” (ISO/IEC 25000:2005, Guía
para el uso de la nueva serie de Estándares
Internacionales llamados: Requisitos y Evaluación de
Calidad de Productos de Software - SQuaRE ).
 La ISO/IEC 25000 son normas basadas en la ISO/IEC 9126 y en ISO/IEC 14598 cuyo objetivo principal
es guiar el desarrollo de los productos de software mediante la especificación de requisitos y
evaluación de características de calidad.
56
CALIDAD DEL SOFTWARE
 Sin embargo, la calidad es un término subjetivo, dependerá
de quien es el “Cliente” y de su influencia global en el
contexto de las cosas. Una vista amplia de los “clientes” de
un proyecto de desarrollo de software, puede incluir: los
usuarios finales, probadores de aceptación usuaria, los
gestores del cliente, los testeadores, vendedores de la
organización, etc. Cada tipo de “Cliente" tendrán su propio
punto de vista.
 La Calidad del Software es, “disponer de un software
razonablemente libre de errores, entregado a tiempo y dentro
del presupuesto, cumpliendo con los requisitos y/o
expectativas, y ser fácil de mantener.”
 Mas allá de como se defina la calidad del software, para que
la definición tenga sentido esta debe ser medible (Tom De
Marco: “No se puede controlar lo que no se mide”).
Calidad de Software
57
EVOLUCION DE LA CALIDAD EN LAS ORGANIZACIONES
1. Énfasis en los Productos:
Calidad como cumplimiento de las
especificaciones
Control de Calidad como inspección o
pruebas.
2. Énfasis en los procesos de

Manufactura:
Asegurar la Calidad del producto
asegurando los procesos (evaluación)
Control estadística de los procesos
3. Calidad Total
Calidad como satisfacción del cliente
Calidad total de productos y servicios
Control total de la calidad como una
forma de Administrar una Organización
Calidad de Software
58
EVOLUCION DE LA CALIDAD EN ORGANIZACIONES
59
CONTROL DE CALIDAD (QC)
 Orientada al cumplimiento de los requisitos de la
calidad por un producto o servicio realizado.
(NTP-ISO 9000 Sistemas de Gestión de la Calidad.
Fundamentos y Vocabulario).
 Conjunto de técnicas y actividades, de carácter

operativo, utilizadas para verificar los requisitos
relativos a la calidad del producto o servicio.
calidadtotal@hotmail.com
 Un conjunto de actividades diseñadas para evaluar o

validar la calidad de los productos
desarrollados o fabricados. El Testing es un proceso
de Control de Calidad.
Calidad de Software
60
ASEGURAMIENTO DE LA CALIDAD (QA)
 Conjunto de actividades diseñadas para evaluar

los procesos que se utilizan para el desarrollo o
fabricación de los productos o entregables.
 Comprende las actividades planificadas y sistemáticas

implementadas como parte de un Sistema de Calidad
y que han demostrado ser necesarias para
proporcionar la confianza adecuada de que una
Empresa o Entidad cumplirá con los requisitos de
calidad (en sus productos o servicios).
ISO/IEC 12207:2008, Systems and software engineering - Software
life cycle processes. 4.34.
Calidad de Software
61
ASEGURAMIENTO DE LA CALIDAD (QA)
Es un conjunto de actividades planificadas y sistemáticas

relativas a la Calidad para asegurar que el Proyecto
utilice los procesos necesarios para cumplir con los
requisitos.
Guía de los Fundamentos de la Dirección de Proyectos - PMBOK.
 El Aseguramiento de la Calidad nace como una

evolución natural del Control de Calidad, que resultaba
limitado y poco eficaz para prevenir la aparición de
defectos. calidadtotal@hotmail.com
Calidad de Software
62
GESTION Y PLANIFICACIÓN DE CALIDAD
 Actualmente la calidad ha pasado a ser una política de

gestión empresarial donde el compromiso de todos los
niveles organizativos con la calidad, es clave para el éxito.
 Implica su planificación a mas alto nivel y la determinación
de que normas y estrategia de calidad son relevantes y
claves para una organización o proyecto. (ISO 9001).
 La calidad, se planifica durante el Plan de Gestión del
Proyecto
(Guía de los Fundamentos de la Dirección de Proyectos – PMBOK.)
Tarea 4: Próxima clase

• ¿ Cuantas Empresas en el Perú tienen certificación ISO 9001 el año 2015 y el 2016?
• Compare estas cifras con la de los países: Colombia Brasil y Chile. Haga un Ranking .
• Haga su comentario desde el punto de vista de la calidad.
Calidad de Software
63
ASEGURAMIENTO DE LA CALIDAD DEL
SOFTWARE
SQA
64
Gestión de la Calidad en Proyectos
de Software
 Debe partir de la Política de Calidad de la
organización o por iniciativa de la Gerencia de TI
alineado a la estrategia de la organización.
 Establecer un marco de proceso y estándares de la
organización que conduzcan a obtener software de
mejor calidad.
 Establecer el Plan de Aseguramiento de Calidad del
Software del Proyecto (SQAP).
 Si en la organización ya existe un Sistema de Calidad,
el SQAP deberá ser coherente con el mismo.
 Asegurar que los productos a obtener y la ejecución
de los procesos para su obtención, estén en
conformidad con los planes, procedimientos y
estándares establecidos. 65
Aseguramiento de Calidad del Software (SQA)
Objetivo general del SQA
Proporcionar la garantía o confianza de que los productos

de software y los procesos realizados durante el ciclo de
vida de un proyecto son conformes a los requerimientos
especificados, mediante la planificación previa, emitiendo, y
realizando un conjunto de actividades para generar la
confianza adecuada en que se está construyendo la calidad
dentro del software.
SQA es la definición de procesos y estándares que deben
conducir a la obtención de productos de alta calidad.
(*) Ver: SWEBOK – Capitulo XI Calidad de Software: 2.1 Aseguramiento de Calidad de SW
Calidad de Software
66
Aseguramiento de Calidad del Software (SQA)
Objetivos específicos de SQA
• Establecer planes, estándares y procesos que satisfagan

las políticas de la organización y se ajusten a las
necesidades de cada proyecto en particular.
• El Plan SQA define el medio (conjunto de actividades)
que será usado para asegurar que el software
desarrollado para un producto específico satisface las
exigencias del usuario y es de la máxima calidad posible
dentro de las restricciones del proyecto
• Revisar y auditar los productos y actividades
desarrolladas para verificar que ellos satisfacen los
procesos y estándares definidos.
Calidad de Software
67
Aseguramiento y Control de la Calidad en el RUP
Actividades del SQA
Analizando el diagrama, se aprecia que el esfuerzo de cada disciplina varía
según la fase del proyecto. Se incorporan nuevas actividades de SQA para
controlar la calidad de cada disciplina, cuando mayor esfuerzo se le dedica.
Fases
planificadas
68
Aseguramiento de calidad del Software (SQA)
Objetivos específicos de SQA
• Proveer las herramientas necesarias que den

soporte al proceso definido, facilitando su ejecución,
visualización, administración y seguimiento.
• Proveer al equipo de proyecto y a otros interesados,
los resultados sobre las revisiones, auditorías y
actividades.
• Medir la calidad del producto para aumentarlo y
medir la calidad del proceso para mejorarlo.
• Escalar problemas no resueltos dentro del equipo de
un proyecto hacia un nivel apropiado de
administración para su resolución.
Calidad de Software
69
Aseguramiento de Calidad del Software - SQA
engloba:
1. Métodos y técnicas de análisis, diseño, codificación y
prueba.
2. Revisiones, son técnicas formales que se aplican durante
cada fase del proceso de desarrollo de software.
3. Estrategias y plan de prueba a diversas escalas.
4. Control de los entregables (documentación) del software y
de los cambios realizados, mediante tecnicas de
verificación / validación.
5. Reportes de control de incidencias detectados por QA con
evidencias, aplicación de técnicas de pruebas con casos
de prueba.
6. Un procedimiento que asegure, siempre que sea posible,
un ajuste a los estándares de desarrollo del software.
Calidad de Software
70
Comparación QA y QC del SW
VER: Caso (Tarea-lectura):

Diferencia entre Aseguramiento de Calidad y Control de Calidad
• Autor: Dr. Norberto Figuerola (PMP – George Washington University), Experto ITIL y
Auditor ISO 20000. 71
Técnicas de Aseguramiento y Control de
Calidad de Software
Conocidos también como Procesos de SQA
Verificación
Validación
Revisión
Auditoria
(*) Revisar: NTP-ISO/IEC 12207: 2006 Procesos de Apoyo a los Procesos de Software
(*) Revisar: ISO/IEC 12207:2008 Procesos Específicos de Software. Revisar SWEBOK
Calidad de Software
Verificación Validación
• La verificación evalúa • La validación evalúa el
documentos, planes, producto mismo
código, requerimientos y (módulos o al producto
especificaciones integral)
• Por ejemplo: • Incluye la ejecución de las

• Requisitos o Especificaciones pruebas diseñadas (casos de
Inconsistentes prueba) para cubrir cada
uno de los requerimientos
• Revisiones de Diseño
específicos del sistema
• Inspecciones de Código
Estamos haciendo el producto Estamos haciendo el producto

correctamente correcto
Calidad de Software
Revisión
 Proceso que permite evaluar formalmente el estado de un proceso o
un producto (entregables). Se realiza a través de reuniones con los
interesados. Hay varios tipos de revisiones.
 Actividad emprendida para asegurar la conveniencia, adecuación
y eficacia del tema objeto de la revisión, para alcanzar ciertos
objetivos o requisitos establecidos. ISO 9000. (El objeto de una
revisión puede ser un proceso o el producto de un proceso).
 Los tipos de Revisiones pueden ser: (1) La Inspección, (2) Revisión
guiada, (3) Revisión técnica, (4) Revisión informal.
 Ejemplos de revisiones: Revision del plan de gestión de un
proyecto por la dirección, revisión del proceso de diseño,
revisión de los requisitos del cliente y revisión de no
conformidades, revisión de lo planificado.
74
Técnicas de Aseguramiento y Control
de Calidad de Software
Revisión
Las revisiones del software son un "filtro" para el proceso de Ingeniería del Software. Esto es, las revisiones se
aplican a varios momentos del desarrollo del software y sirven para detectar errores y defectos que pueden ser
eliminados. La revisión técnica-formal llamada Inspección, es el filtro más efectivo desde el punto de viste del
aseguramiento de la calidad y es un medio efectivo para mejorar la calidad del software.
• Realizarse las Revisiones según lo planificado
• Revisarse la adecuación o los cambios de los Datos de Inicio (partida) y dejar evidencia de ello.
• Cómo mínimo hay dos revisiones: De los Datos de Partida (la versión 1) y Revisión Final (versión n).
• Se recomienda hacer revisiones tras la Finalización de cada etapa o Iteración.
• Deben mantenerse registros de los resultados de las revisiones y de cualquier acción necesaria (proceso o
producto). Ejemplo de registros: Actas, Listas de Chequeo, Reporte de No conformidades, Evidencias.
UNA APROBACIÓN COLEGIADA (Visado del Proyecto) NO VALE, ya que técnicamente puede ser correcto,
pero no contrastable con los requisitos del Cliente o Usuario.
Ejemplos de Revisiones:
1. Revisión de Requisitos de Sistema (SRR)
2. Revisión Funcional del Sistema ó Revisión de Diseño del Sistema (SFR o SDR)
3. Revisión de Especificación Software (SSR)
4. Revisión del Diseño Preliminar o Arquitectura (PDR)
5. Revisión del Diseño Detallado (CDR)
6. Test Readness Review (TRR)
7. Auditoría de la Configuración Funcional ó de Configuración Fisica (FCA) o PCA)
75
Técnicas de Aseguramiento y Control
de Calidad de Software
Auditoria de Software
La Auditoría está enfocada en ver hacia atrás, para evaluar un sistema de control
vigente en funcionamiento, revisando hechos que han ocurrido o actividades
realizadas. De esta forma, se actúa con antelación a partir de la evidencia
documental examinada que dan soporte a sus conclusiones.
La auditoría implica una revisión exhaustiva en la que se analiza la efectividad

de los controles vigentes (diseño y ejecución) para obtener evidencias y
evaluarlas para asegurar que las tareas se estén llevando a cabo conforme los
parámetros acordados o normas establecidas.
Ejemplo: Evalúa la efectividad de la gestión de los riesgos, del análisis de los requerimientos,
la conformidad del código, la eficacia del software conforme a los requerimientos. Se enfoca
en el éxito o fracaso, así como en la atención de la causas raíz. El resultado de la Auditoria
siempre estará documentado conforme este progresa. Una herramienta que usa la Auditoria
es la Revisión.
Hay 2 tipos de Auditoria: Interna y Externa (ISO 9001)

Calidad de Software
Verification Validation
• Verification evaluates • Validation evaluatesthe
V eri
docum en
fic ation
ts, plans, code,
and
Vali dation?
product its
requirements, and
elf.
specifications
• Involves the execution of
tests designed to cover each
• For example, of the specific system
• Inconsistent Requirements requirements
• Design Walkthroughs
• Code Inspections
Practicas de SQA
• Por tanto, ¿cómo se hace en una industria?

Planning • Create a QA Plan/Test Strategy
Analysis • Specification Review
Design
Development • Develop test cases for testing (validation)
• Test cases execution on developed software

Testing and Integration testing
Deployment • Build validation/Shipment assurance

Practicas de SQA
• Esto podría ser mejorado como:

• Create a QA Plan / Test strategy
Planning
• Review project plan
Analysis • Specification Review /Audits
Design • Analyze Design / Audits
• Develop test cases for testing (validation)

Development • Code Inspection/Review
• Unit Testing
• Test cases execution on developed software
Testing • Integration testing
• Test Automation (tools)
• Non-Functional Testing
Deployment • Build validation/Shipment assurance
Ejemplo: SQA en la Metodología de Desarrollo
SDLC
Aseguramiento de Calidad de Software (Paraguas)
Planning Design Testing
Analysis Development Maintenance
Plan de Calidad - SQAP

Ejecución (Verificación y Validación) Revisión y Auditoria
Medición y Análisis de resultados
Patrón de defectos EN EL CICLO DE VIDA
(Sin SQA y con SQA)
[] Organización con un equipo de QA

Fuentes: [] Organización sin un equipo de QA
•National Institute of Standards & Technology, United States Department of Commerce, 81
Patrón de Costo-defecto EN EL CICLO DE VIDA
(Sin SQA y con SQA)
[] Organización con un equipo de QA

Fuentes: [] Organización sin un equipo de QA
•National Institute of Standards & Technology, United States Department of Commerce, 82
IEE: Especificación incompleta o errónea; MCC: Mal interpretación del cliente; DDE: Desviación deliberada de la especificación;
IEP: Incumplimiento de estándares de programación; ERD: Error en la presentación de los datos; IMI: interfaz de modulo
inconsistente; ELD: Error en la lógica del diseño; PIE: Prueba incompleta o errónea; DII: Documentación imprecisa o incorrecta;
TLP: Error en la traducción del diseño a la programación; IHM: Interfaz ambigua o inconsistente; VAR: Varios
83
Aseguramiento y Control de la Calidad del SW - SQA
Resumiendo:
Tiene su foco de atención sobre los procesos.
El rol del aseguramiento de calidad es:
• Gestionar la calidad
• Monitorear y mejorar los procesos (actividades) de
desarrollo.
• Establecer el control de calidad o Testing a realizar,
planificando y evaluando su realización
SQA utiliza los resultados del control de calidad para
mejorar los procesos. Es una actividad “Preventiva”.
Tarea 5: Identifique 4 beneficios obtenidos en Proyectos
con el SQA
Calidad de Software
84
Aseguramiento de Calidad y el Proceso de Testing
¿Que es Testear o Pruebas?
Es el proceso de analizar el producto de software

o sus componentes, para detectar las diferencias
entre lo existente y las condiciones esperadas o
requeridas (funcional y no-funcional) y evaluar
las características o rasgos de cada componente
del mismo (IEEE).
85
¿Que es Testear o Pruebas?
• Es un proceso de Control de Calidad – Detectivo
• Es hacer una investigación empírica planificada, con el

objetivo de proveer información objetiva acerca de la
calidad de producto.
• Las pruebas (proceso dinámico), implican controlar un

sistema en situaciones controladas y realizar la evaluación
de los resultados.
• Las condiciones a controlar (casos de pruebas) deberán

incluir tanto condiciones normales como condiciones
anormales.
86
¿Que es Testear (Pruebas)?
Es un Proceso basado en una Metodología de Pruebas
La ejecución de las pruebas es sólo una parte del proceso de pruebas

El proceso de prueba incluye:
• Planificación y control (plan y estrategia)

• Selección de condiciones de prueba
• Diseño y ejecución de casos de prueba
• Comprobación de resultados (evaluación)
• Generación de informes del proceso de pruebas y del sistema sujeto
a pruebas (informe de incidencias, informe de revisión de casos de
prueba)
• Finalización y completar actividades de cierre (certificar)
La revisión de documentos, código fuente y la realización de análisis

estático (pruebas estáticas) también ayudan a prevenir la aparición de
defectos en el código. 87
Problemas que enfrenta el SQA
• El reto principal es que el Ingeniero de Calidad entienda el
proyecto y como el proyecto afectará al resto del sistema, en el
caso de incluir un nuevo modulo o producto.
• Una vez que se entiende el proyecto, deberá entender cada uno
de los requerimientos y como deben interactuar. (Se complica
con la complejidad de proyectos).
• La actividad de SQA debe estar involucrada desde el inicio de
un proyecto de SW, en la practica no es así, usualmente se deja
al último.
• El Equipo de Desarrollo consume el tiempo dispuesto para QA.
• Requerimientos mal definidos o no definidos, causan (en
muchos casos) que se tenga que iniciar de nuevo con las
pruebas de software.
• Desarrolladores no siempre tienen la mejor disposición para
cooperar con los Ingenieros de Calidad o de Pruebas.
88
AREA de SQA - en la organización de TI
• Muchas organizaciones han creado Áreas de SQA debido a
su necesidad de independencia y con el fin de disponer de un
nivel de servicio que garantice calidad.
• Otras constituyen Grupos SQA fuera del Departamento de
Desarrollo, para mayor transparencia.
• Estas personas (SQA) actúan como representantes interno
del Cliente (es su misión).
• Es responsabilidad del área o grupo SQA ayudar a lograr una
alta calidad en los programas o aplicaciones de software
determinadas (¿lo entienden los desarrolladores?).
• Este grupo tiene una serie de funciones (ver diagrama Vista
General de SQA y ejemplo de Organigrama de TI.
Calidad de Software
89
Vista general QC, QA, MPS
ACA AQA AMP
QA Mejora
Procesos
Métricas 1 Métricas 2 Métricas N

..
Evaluar la
Proyecto Proyecto Proyecto
Calidad
SW 1 SW 2 SW N
Proceso Producto
Análisis Diseño Construcción Pruebas
Calidad de Software
90
ÁREA de SQA - en la Organización de TI
Ejemplo Organización con SQA
Calidad de Software
91
Procesos
Procesos
de
de calidad
Calidad
Requeri-
Requeri-
Métricas
Métricas mientos
mentos
Reportes
Reportes Cambios
Cambios
SQA
Pruebas Planes
Planes
Riesgos Desvia-
Riesgos
ciones
Entrega-
bles
Calidad de Software
92
Participación en Aseguramiento de Calidad
Jefe de
Sistemas
10%
Gestor de
SQA
proyecto
100%
30%
Analistas
15%
Calidad de Software
93
Gestión de la Calidad
Incluye la planificación estratégica, la asignación de recursos y

otras actividades tales como la medición a través de indicadores. Se
enfoca a la mejora continua.
Gestión: Actividades coordinadas para dirigir y controlar una

organización – ISO 9000.
Sistema de Gestión: Sistema para establecer la política y los

objetivos y para alcanzarlos.
Sistema de Gestión de la Calidad: Sistema para dirigir

controlar una organización con respecto a la calidad- ISO 9000.
Calidad de Software
94
QUE LOGRAMOS CON LAS MEJORAS
tiempo,costos,alcance
Tiempo de lo que estimamos
Tiempo de lo real
Tiempo del proyecto con las mejoras
Calidad de Software
95
Clave del éxito:
Ningún modelo de mejora tiene
éxito si no se implementa
correctamente
Implementador
Calidad de Software
96
Calidad de Software
97
Calidad de Software
98
Calidad de Software
99
MISCELANEOS
Calidad de Software
100
¿Dónde se encuentra el error?
“Programa en Clipper”
If A > 1 && A < 5 Then
Sentencia 1
..
Sentencia N
“El fallo se manifestaba funcionalmente, no hay

error de lógica, ni error de compilación”
Calidad de Software
101
En Clipper si existe el error, && Significa

Comentario.
El error fue detectado mediante caja blanca,

un programador experto en lenguaje “C” fue
inducido al error en Clipper.
En C : No existiría error
Calidad de Software
102
Calidad de Software
103
Ambigüedad
Pregunta:¿el check es para responder "Si" o es para

responder "No“?
Calidad de Software
104
Departamento, Provincia, Distrito: Drowbox

Zona: Drowbox de “Urbanización”, “PJ”, “Asentamiento”
Vía : Drowbox de “Calle”, “Jr.”, “Av.”
Calidad de Software
105
Departamento, Provincia, Distrito: Drowbox

Zona: Drowbox de “Urbanización”, “PJ”, “Asentamiento”
Vía : Drowbox de “Calle”, “Jr.”, “Av.”
Pregunta: ¿Y dónde se registra el nombre de la Zona?
Calidad de Software
106
PREGUNTAS
Calidad de Software
107
PROYECTO DEL CURSO
Grupos de 2 o 3 alumnos
• Tomando como base un proyecto de desarrollo de
Sistemas de Información especifico, elaborar los
siguientes entregables:
 El Perfil del Proyecto (Project Charter)
 El Plan de Aseguramiento de Calidad (SQAP)
• El objetivo es planificar el desarrollo de un

Sistema, asegurando la calidad del proceso y del
producto, aplicando el SQA desde el inicio del
proceso de desarrollo (primeras etapas).
• El proceso deberá efectuarse utilizando una

Metodología de Desarrollo, alineada a los
requisitos exigidos por las Normas de Calidad de
SW que se establezcan (o decidan usar).
Calidad de Software
108
PROYECTO DEL CURSO
Establecer Grupos de Trabajo
Premisas a considerar:
• Considerar que las actividades de SQA o Testing serán asumidas por una
Emp. de Servicio o por el Área de SQA interna.
• Las normas o modelos de calidad a usar, serán las establecidas por la
organización (dueña del proyecto) o en todo caso por los responsables del
proyectos: (NTP/ISO, ISO´s, IEEE, o CMMI).
• La metodología de desarrollo es una exigencia de calidad y estándar.
Podrían usar: Métrica, RUP, SDLC, Agiles (XP, SCRUM, KANBAN),
cumpliendo los requisitos del modelo de calidad de procesos a usar.
• Los entregables del sistema deberán ajustarse o corresponder a las
normas y estándares establecidas y metodología de desarrollo.
• El Plan de Aseguramiento de Calidad (SQAP) incluirá: el Plan de
Verificación & Validación, el Plan Maestro de Pruebas y las Revisiones de
los Requerimientos Usuarios, las Especificaciones y el Diseño.
• Perfil del Proyecto incluirá: el Problema, los Requerimientos, el Alcance del
Proyecto, los Entregables a obtener por Fase o Iteración, el nivel de
conformidad de cada fase o iteración, el cronograma general del proyecto,
equipo responsable, plataforma y herramientas de desarrollo.
Calidad de Software
La 3

FundamentosDeCalidad SW

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

FundamentosDeCalidad SW

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS

UNIVERSIDAD DEL PERÚ, DECANA DE AMERICA

Curso: Calidad del Software

1. Fundamentos de Calidad de Software

Lic. Luis Alarcón Loayza

• Comprender la función de Aseguramiento de Calidad (SQA)

• ¿Por que es importante la Calidad del SW?

La Calidad es una continua preocupación de todas las

La producción de Software de Calidad es parte de la Ing. Software.

 Leer : IEEE-SWEBOK: Capitulo XI Calidad de Software, y Capitulo V Pruebas de Software 5

Respondamos estas 02 preguntas:

 Cada vez mas los productos o servicios que utilizamos y los

Impacto Económico del Software: EL SOFTWARE ESTA EN TODO SITIO

¿ES CONFIABLE EL SOFTWARE?

LAS CONSECUENCIAS DE LOS ERRORES DEL

GRANDES ERRORES Y CONSECUENCIAS DEL SOFTWARE

Caso 1: Misión fallida: Ariane5

El 4 de junio de 1996 la Agencia Espacial

Costo aproximado: 7 mil millones de dólares

GRANDES ERRORES Y CONSECUENCIAS DEL SOFTWARE

GRANDES ERRORES DEL SOFTWARE

Otro caso parecido, fue el de la sonda

GRANDES ERRORES DEL SOFTWARE

En agosto de 2012, un error de

GRANDES ERRORES DEL SOFTWARE

La desactivación de los servidores del

GRANDES ERRORES DEL SOFTWARE

GRANDES ERRORES DEL SOFTWARE

En 2013, un error de programación

GRANDES ERRORES DEL SOFTWARE

05/02/2010 Toyota retira 437 mil

Pérdidas por 8,5 millones de dólares,

GRANDES ERRORES DEL SOFTWARE

GRANDES ERRORES DEL SOFTWARE

¿Windows 8, el ultimo gran fracaso de Microsoft?

GRANDES ERRORES DEL SOFTWARE

Instrumento médico usado para aplicar

Junio 1985 a Enero 1987

Mensaje “Ninguna dosis”

Muerte y daños permanentes

Diagnóstico : Sobredosis de radiación

Grandes Errores del Software – Caso 10:

Otras – grandes fallas de software :

GRANDES ERRORES DEL SOFTWARE

Lugar: Banco de la Nación – Sampacho, Argentina.

GRANDES ERRORES DEL SOFTWARE

GRANDES ERRORES DEL SOFTWARE

Resultado de Examen de Docentes

Noviembre 2009 Software del MINEDU

Diagnóstico : Desplazamiento de las filas

Impacto político, marchas y protestas.

GRANDES ERRORES DEL SOFTWARE

Mujer retira S/.100 de Cajero Automático y la Máquina

Inédito: ¡¡ El Banco luego la denunció por ROBO !!

GRANDES ERRORES DEL SOFTWARE

GRANDES ERRORES DEL SOFTWARE

Ejercicio Tarea 1: Próxima clase

Completar una lista de al menos 05 grandes fallas o

LA CRISIS DEL SOFTWARE

1950 1960 1970 1980 1990 2000

«Crisis del Software»

-Muchos cambios en -Técnicas Interactivas -Aparecen las PC’s -Software complejo.

LA CRISIS DEL SOFTWARE

LA CRISIS DEL SOFTWARE