Universidad de la Defensa Nacional

Instituto Universitario Aeronáutico

Calidad de Software
Actividades Obligatoria 1
Profesora: María Boggio
Alumno: Cristian A. Sanhueza

2020
 Instituto Universitario Aeronáutico

Facultad de Ciencias de la Administración

Ingeniería de Sistemas

Calidad de Software – Sistema Gestión de Calidad

Actividad Integradora Obligatoria Nro. 1

1. Herramientas de calidad:
a. Elabore un cuadro comparativo entre las diferentes Herramientas de la Calidad
empleando los siguientes criterios: Nombre de la herramienta, Beneficio de su uso.

Nombre de la Herramienta Beneficio de su Uso

Diagrama Causa Efecto – Diagrama de Espina  Su creación favorece el intercambio

de Pescado o Diagrama de Ishikawa
Diagrama de Paretto
de técnicas y experiencias.
 Permite identificar todas las causas
posibles del problema, incluso
aquellas que parecen más obvias.
 Permite prevenir problemas,
cuando se detectan causas
potenciales de un problema.
 Ayuda a determinar la raíz de cada
problema.
 Fomenta el trabajo grupal al
encontrar las deficiencias de
manera conjunta.
 Ayuda a focalizarse en las causas
del tema.
 Sintetiza los problemas en un
formato fácil de leer.
 Muestra las áreas en las que se
originan mayormente los problemas
y en las cuales, por lo tanto, deberá
prestarse mayor atención
 Ilustra las causas de los problemas
por orden de importancia y
frecuencia.
 Permite además comparar
frecuencia, costo y actuación ante
varias categorías de problemas.
 Muestra en un método sencillo y
gráfico, las principales deficiencias
de un sistema.
 Permite discriminar entre las
causas más importantes de un
problema (pocos y vitales) y las que
 triviales.
 Permite priorizar qué problemas
serán analizados primero.
 Es el primer paso para la
realización de mejoras.
 Se aplica a situaciones en donde se
pretende efectuar una mejora en
los componentes que determinan la
calidad del producto/servicio.
 Permite la comparación
antes/después, ayudando a
cuantificar el impacto de las
acciones tomadas.
 Promueve el trabajo en equipo.

Diagrama de flujos  Facilita la obtención de una visión

transparente del proceso,
mejorando su comprensión.
 Permite describir el proceso real y
no lo que se supone debería ser el
proceso.
 Da la oportunidad de realizar
pruebas sobre el diagrama, de los
procesos que se realizan, para
verificar que todas las operaciones
son posibles tal cual figuran en el
diagrama.
Histograma  Muestra los datos de una manera
simple.
 Representa gráficamente los datos
numéricos que permiten ver tres
propiedades: forma en la que se
distribuyen las observaciones,
tendencia central, dispersión.
 Permite trabajar conjuntamente con
los límites de especificación.
 Se puede presentar como un
gráfico definitivo en el reporte.
 Se puede utilizar para comparar
dos o más muestras o poblaciones.
Diagrama de correlación  Proporciona la posibilidad de
reconocer relaciones causa/efecto.
 Facilita el reconocimiento de
correlaciones.
 Ayuda a determinar relaciones
dinámicas o estáticas.

Checklist (hoja de verificación)
Gráfico de control
 Indica si dos variables o atributos
de calidad están relacionados.
 Permite registrar la información en
el momento en que se está
recabando.
 Presenta los datos de manera
directa y sencilla.
 Proporciona un medio para registrar
de manera eficiente los datos que
servirán de base para su
subsecuente análisis.
 Proporciona registros históricos que
ayudan a percibir los cambios en el
tiempo.
 Facilita el inicio del pensamiento
estadístico.
 Ayuda a traducir las opiniones en
hechos y datos.
 Se relaciona estrechamente con la
determinación de los límites de
control.
 Permite mostrar tendencias,
comportamiento anormal u otros
indicios sobre la evolución de un
proceso.
 Hacen posible considerar varias
características de calidad al mismo
tiempo y clasificar el artículo como
disconforme si no satisface
cualquiera de las especificaciones
 Mediante la inspección por
atributos pueden evitarse
mediciones costosas en recursos y
tiempo.
 Se obtiene información directa
acerca de la media del proceso y su
variabilidad.
 Facilita la determinación de puntos
fuera de control y sus causas.
 Proporcionan información de
problemas inminentes y permiten al
personal operativo tomar acciones
correctivas antes de que ocurra la
producción real de artículos

b. Para cada una de ellas plantee un caso asociado al software donde deba aplicar esa
herramienta de calidad. Haga las suposiciones que necesite.
c. Fundamente que la herramienta utilizada en cada caso es la adecuada.
HERRAMIENTA
Diagrama causa-efecto
Diagrama de Pareto
Diagrama de Flujo
Histograma
defectuosos.
APLICACIÓN FUNDAMENTO
Fallo inesperado sistema de Es adecuado el uso del
gestión y control de cámaras diagrama causa-efecto ya
de seguridad. que se parte del problema y
se buscan las posibles
causas, se debe trabajar con
un equipo de trabajo
multidisciplinario para que el
análisis sea más completo.
Continuando con el ejemplo Si en el análisis se detecta
anterior, se detecta en el que existe más de una
diagrama causa-efecto que causa para los fallos
existe más de una causa recurrentes en el sistema se
relacionada con el fallo del procede a recopilar
sistema. información para aplicar el
diagrama de Pareto.
Desarrollo de modulo para Cuando se trabaja en
aplicación web. desarrollos modulares con
un equipo de trabajo, este
diagrama es útil para
mostrar al equipo como se
pretende realizar la lógica de
programación de la
aplicación a nivel general,
sin detalles sobre el código
en sí.
Continuando con el sistema El histograma puede
de cámaras de seguridad, se colaborar a verificar si la
puede utilizar para falla del sistema de gestión
determinar la frecuencia de de cámaras de seguridad es
los fallos. debido a un método en

Diagrama de Correlación
Checklist
Gráfico de Control
2. Ejemplifique error, defecto y fallo con casos o situaciones cercanas a su experiencia.
Error: cualquier equivocación humana en un sistema de software que genera defectos. Por ejemplo,
cuando se escribe un código java y se necesita usar un bucle if anidado y se crea un desorden con los
Continuando con el ejemplo
se puede determinar con
este diagrama, si existen
dos eventos que causen la
falla del sistema.
Una empresa que realiza
software a medida con
estandares.
Desarrollo de grandes
proyectos colaborativos, por
ejemplo un sistema para
control y monitoreo de
distribución eléctrica.
particular o varios al mismo
tiempo, o en forma
escalonada ya que se puede
ver la tendencia de como
suceden dichos eventos.
Puede ocurrir que existan
dos eventos que sucedan en
simultáneo que ocasionen la
falla del sistema, por
ejemplo puede estar
relacionada con la interfaz
de usuario y alguna clase en
particular.
Este diagrama es útil cuando
una empresa realiza
software de gestión a
medida, donde ya se
encuentren las clases
desarralladas y solo reste
adaptarlas al nuevo sistema,
aquí es conveniente tener un
checklist para tildar los
avances como una manera
eficiente de autocontrol y
para detectar faltanes o
mejoras.
En el desarrollo de grandes
proyectos se deben llevar
índices de calidad para
medir los avances y
mantener el proceso de
desarrollo bajo control sin
que ocurran grandes
desvíos que puedan llevar al
fracaso del proyecto.
corchetes para cerrar cada bucle, se genera un error de código al momento de compilar, esto generara
un defecto.

Defecto: se presenta en el código y puede causar un fallo. Continuando con el ejemplo anterior, el
código que se tiene, es ahora defectuoso, ya que no es correcto, seguramente falta o sobra un corchete
en los bucles. En este caso, no se generara una falla del sistema en general porque se detectará en la
depuración, pero hay otros defectos que no son detectados en la depuración y pueden causar grandes
fallas difíciles de detectar.

Fallo: diferencia entre los resultados reales y esperados a nivel general en el sistema. Se trata de una
falla interna cuando aparece antes de liberar el producto, o externa, cuando aparece una vez que ya fue
entregado el producto al cliente. A diferencia de los conceptos anteriores, se trata de

3. Relacione el concepto de riesgo con el de testing de software.

El riesgo es un problema potencial que podría hacerse realidad en el proyecto de desarrollo de
software. Es importante en la etapa de inicio del proyecto, identificar los problemas que podrían
dificultar los hitos del mismo, durante la ejecución del proyecto, se monitorizan los riesgos que
se identificaron relevantes y se analiza el progreso del proyecto para identificar nuevos riesgos.
Si un riesgo se hace realidad en el proyecto, entonces se realizan las acciones de resolución
propuestas en el plan de gestión de riesgo.
 Son muchas las cosas que pueden salir mal cuando se desarrolla software, es por ello que es
esencial establecer planes de contingencia.
En el caso de un software de mala calidad aumenta los riesgos tanto para el desarrollador como
para el usuario final, es decir que no son solo riesgos de que el proyecto fracase, sino que de
acuerdo a la envergadura del proyecto puede ser potencialmente dañino, es fundamental el rol
del test manager en la identificación y mitigación de riesgos relacionados con la calidad del
software, el Instituto de Ingeniería de Software (SEI por sus siglas en inglés) identifica siete
principios que ofrecen un marco conceptual para lograr una administración del riesgo efectiva:
1. Mantener una perspectiva global: Analizar el riesgo como sistema dentro del contexto
empresarial que se pretende resolver.
2. Tomar una visión de previsión: Analizar que riesgos futuros pueden traer los cambios o
correcciones actuales.
3. Alentar la comunicación abierta: Cualquier comunicación de un riesgo debe ser
considerada.
4. Integrar: Todo Riesgo considerado debe integrarse con el proceso del software
5. Enfatizar un proceso continuo: el equipo de desarrollo debe monitorizar los riesgos,
mitigarlos y vigilar los nuevos que aparezcan.
6. Desarrollar una visión de producto compartida: El equipo debe compartir la visión del
software a desarrollar para que haya mejor identificación y valoración del riesgo.
7. Alentar el trabajo en equipo: Es importante reunir todo el equipo cuando se realicen
actividades de administración del riesgo.

4. Suponga un sistema crítico:

a. Plantee el caso para proponer cinco requerimientos funcionales y dos no funcionales
para el mismo.
Supondremos un sistema de vigilancia y seguridad.
Requerimientos Funcionales del sistema:
i. Debe contar con un log de eventos, donde se indicará quien, como y cuando
realizó cambios.
ii. Debe poder realizar un respaldo automatizado tipo schedule de las carpetas que
los usuarios consideren importantes, esto será fijado con una frecuencia diaria,
semanal o mensual en el horario que el usuario especifique.
iii. Debe tener la capacidad de monitorizar la sobre carga de memoria o procesos
del sistema operativo.
iv. El entorno de trabajo debe ser amigable al usuario, con iconos intuitivos sin
mucha descripción.
v. La interfaz debe ser capaz de mostrar hasta 6 cámaras por cada monitor, con la
finalidad de no perder resolución.
 Requerimientos no Funcionales del Sistema:
i. Deberá validar las credenciales de usuario, tanto para servicios locales como
accesos remotos, el acceso remoto se dará únicamente con rol Supervisor y
Administrador.
ii. Las bases de datos serán del tipo relacional realizadas con db2.
iii. El acceso remoto será mediante VLAN mediante la verificación de las
credenciales.

b. ¿Qué particularidades tiene un sistema crítico cuando hablamos de errores, defectos y

fallos?
Un sistema crítico es aquel en donde un fallo puede ocasionar perdidas económicas
significativas, daños físicos o en el peor de los casos amenazas a la vida humana. Sus
particularidades son:
i. Confiabilidad, dentro de la cual se destacan:
1. Disponibilidad: La capacidad del sistema para proporcinar servicios
cuando son requeridos.
2. Fiabilidad: La capacidad del sistema para proporcionar servicios como
han sido especificados.
3. Seguridad: La capacidad del sistema para funcionar sin fallos
catastróficos.
4. Protección: La capacidad del sistema para protegerse a si mismo frente
a intrusiones accidentales o premeditadas.
ii. Reparabilidad
iii. Mantenibilidad
iv. Supervivencia
v. Tolerancia a Errores.
c. Investigue acerca de las condiciones o atributos para escribir requerimientos software,
por ejemplo, un requerimiento no debe ser ambiguo.
Las propiedades de los requerimientos de software son los siguientes:
i. Tamaño:
1. Para manejar con mayor facilidad un requisito, deberá tener un tamaño
adecuado:
a. Ni tan grande que sea inmanejable
b. Ni tan pequeño que no valga la pena seguirle la pista por
separado
ii. Completitud:
1. Significa que no hay omisiones que comprometan la integridad de los
requisitos
a. No faltan requisitos (propiedad global)
b. No faltan detalles en la especificación de cada requisito
(propiedad individual)
 iii. Consistencia (o coherencia)
1. Significa que no hay contradicciones entre requisitos (ni acoplamientos-
redundancias)
2. Contradicción ≠ Ambigüedad, pero las ambigüedades dificultan detectar
contradicciones
3. Una buena organización facilita la detección de contradicciones
iv. Claridad
1. Significa que no hay ambigüedad en la especificación de cada requisito
2. Utilizar un vocabulario controlado, y tabla de términos equivalentes
(sinónimos)
v. Comprobabilidad
1. Incluye dos tipos distintos de defectos que se desea descubrir y
eliminar:
a. Validación: defectos de interpretación (do the right thing)
b. Verificación: defectos de implementación (do the thing right)
2. Para validar y verificar un requisito es necesario que éste sea
comprobable (testable). Un requisito no comprobable o ambiguo tiene
escaso valor y debe ser rechazado.
vi. Condiciones de error
1. Para estar completa, la especificación del requisito debe tener en
cuenta las condiciones de error, es decir, qué ocurre con el requisito en
una situación con errores
2. Las condiciones de error son especialmente importantes para realizar
las pruebas, ya que al probar un requisito se fuerzan condiciones de
error, y es necesario prever qué debe ocurrir en estos casos. Caso típico:
datos de entrada incorrectos
vii. Trazabilidad de requisitos funcionales
1. Es la correspondencia entre cada requisito del software y…
a. Uno o más requisitos del usuario, u otras fuentes (trazabilidad
hacia atrás)
b. Una o varias partes del diseño o la implementación (trazabilidad
hacia adelante)
viii. Trazabilidad de requisitos no funcionales
1. La correspondencia con elementos del diseño y de la implementación es
mucho más difícil, ya que depende en mayor medida de la colaboración
entre varios elementos.
 d. Analice si los requerimientos que escribió en el punto a cumplen lo descripto en el
punto c.

Condiciones de
Requerimiento

Consistencia

Trazabilidad
Completitud
Tamaño

Claridad

Error
1 si si si no si si
2 si si si si si si
Funcional 3 si si si no si si
4 si si si si si si
5 si si si si si si
1 si si si si no si
No Funcional 2 si si si si si si
3 si si si si si si

5. Escriba un conjunto de buenas prácticas o “una receta” para escribir requerimientos de

software correctamente. Ejemplifique errores más comunes.
a. Descripción precisa y detallada, evitar excederse en descripciones superfluas.
b. No omitir las relaciones entre requerimientos, esto es, para cada requisito comprobar
que están presentes los demás requisitos relacionados.
c. Evitar los conflictos, redundancias y acoplamientos entre requisitos.
d. Evitar la ambigüedad.
e. Se deben poder testear facilmente.
f. Si se especifica un error, se debe especificar también el camino de salida.

Uno de los errores más comunes, es especificar la solicitud de una contraseña para ingresar al
sistema y no especificar que sucede ante reiterados intentos fallidos de acceso por ingresar
erróneamente el password.
Otro error es realizar descripciones muy escuetas que dejen muchos grados de libertad al
desarrollador.

6. Pensar y redactar 2 Casos de Prueba que ejerciten (verifiquen) diferentes requerimientos de

los que usted planteó en el punto anterior (a elección). Para ello tenga en cuenta los
siguientes elementos:
- Identificador (ID) del Caso de Prueba
- Nombre del Caso de Prueba
- Descripción con el detalle del propósito/objetivo del Caso de Prueba
- Pasos para su ejecución
- Datos de Prueba (o parámetros)
- Resultado esperado
- Otros elementos que considere relevantes o que agregan valor al Caso de Prueba (autor, tipo de
Caso de prueba, prioridad, trazabilidad...)
Qué características tienen estos casos de prueba con respecto a los requerimientos que prueban?
Explique claramente.

CASO DE PRUEBA
ID: CP_2020_001
Nombre del CP: Login/logout
Verificar el correcto funcionamiento del Login y Logout de los usuarios del
Descripción:
sistema, como así también los privilegios asignados.

Pasos para su ejecución: Resultado Esperado

1_ Ingresar usuario operador.
2_ Ingresar Contraseña errónea x 3
veces.
3_ Usuario bloqueado.
4_ Ingresar nuevamente con password
de prueba.
5_ Ingresar con password renovado
6_ Intentar cambiar la disposición de
elementos de operación.
7_Logout.
8_ Ingresar usuario administrador.
9_ Ingresar Contraseña errónea x 3
veces.
10_ Usuario bloqueado.
11_ Ingresar nuevamente con
password de prueba.
12_ Ingresar con password renovado
13_ Intentar cambiar la disposición de
elementos de operación.
14_Logout.
1_ Funcionamiento Textbox
2_ Verificar usuario bloqueado.
3_ Verificar que se envía nuevo
password de ingreso al supervisor.
4_Solicita al operador cambiar el
password.
5_Verificar acceso correcto al sistema
6_ No permitir mover elementos
7_ Salida exitosa del sistema.
8_ Funcionamiento Textbox
9_ Verificar usuario bloqueado.
10_ Verificar que se envía nuevo
password de ingreso al Jefe de Area.
11_Solicita al administrador cambiar
el password.
12_Verificar acceso correcto al
sistema
13_ Permitir mover elementos
14_ Salida exitosa del sistema.

Usuario: operador / Password: oper1

Datos de Prueba Usuario: Admin / Password:
Administrator
 CASO DE PRUEBA
ID: CP_2020_002
Nombre del CP: Verificar Acceso Remoto
Verificar el correcto funcionamiento del acceso remoto a través de la
Descripción:
VLAN Corporativa

Pasos para su ejecución: Resultado Esperado

1_ Conectarse a la VLAN 1_ Correcta Verificación de las
Credenciales de usuario.
2_ Ingresar nombre del Servidor 2_ Verifica correcta asignación al
nombre del servidor.

3_ Ingresar usuario y contraseña 3_ Verificar bloqueo de acceso

erróneos.

4_ Ingresar contraseña errónea. 4_Verificar bloqueo de usuario y

envío de correo al superior inmediato.

5_ Ingresar con password renovado 5_Verificar acceso correcto al sistema

Usuario: operador / Password: oper1

Usuario: Admin / Password:
Administrator
Datos de Prueba
Server: SSNQNCASSV20
 7. Describa las pruebas de software en metodologías tradicionales y en metodologías ágiles.
Compare.

Metodologías Tradicionales Metodologías Ágiles.

Las pruebas tradicionales siguen un Considerando que, el proceso de pruebas

enfoque de arriba hacia abajo y un modelo
más predictivo, en el que las pruebas se
ejecutan paso a paso.
Aquí, las pruebas se realizan una vez que
se completa / completa el proceso de
desarrollo de software.
ágiles sigue un enfoque iterativo y un
modelo adaptativo.
Las pruebas ágiles siguen una filosofía de
probar primero, en la que los defectos se
corrigen durante cada sprint y luego se
liberan.

El equipo prueba primero diferentes Aquí, el equipo trabaja en conjunto y

módulos del software por separado. colabora en un espacio de trabajo abierto.

Los requisitos establecidos en las pruebas Tiene requisitos fijos pero flexibles que se
tradicionales son concretos y no se adaptan fácilmente a los requisitos
modifican fácilmente. cambiantes de la empresa y los usuarios.

Si se implementan cambios o A diferencia de las pruebas tradicionales,

modificaciones, se realizarán en la próxima en las pruebas ágiles se implementan
versión del módulo. modificaciones durante el siguiente sprint
del ciclo de pruebas de software

Aquí, la prueba unitaria se ejecuta para El equipo ágil está integrado con el equipo
cada módulo seguido de la integración y la Scrum, lo que ayuda a obtener resultados
prueba del sistema. más precisos.

Las herramientas se consideran un lujo en Las herramientas se utilizan con frecuencia

las pruebas tradicionales, ya que la
atención se centra principalmente en
realizar pruebas manuales.
La gestión de riesgos es bastante adversa.
para mantenerse al día con el ritmo de
desarrollo y obtener resultados
rápidamente.
Asegura una gestión de riesgos eficiente,
eficaz y oportuna.

Durante este tipo de pruebas, los Se ofrece una retroalimentación precisa y

comentarios se obtienen principalmente de eficiente, que proporciona una mejor
los usuarios finales una vez que se comprensión del proceso de prueba y
completa el proceso de prueba. asegura la calidad del producto.
La interacción entre los miembros del Lo más importante es que existe una
equipo es escasa ya que las pruebas se interacción continua entre los miembros del
ejecutan en fases. equipo.

Requiere documentación e informes Requiere documentación e informes

completos y extensos. mínimos.

Las pruebas tradicionales son un proceso
que requiere mucho tiempo y, por lo
general, cuesta más esfuerzos y dinero.
Aunque asegura la calidad del producto,
provoca retrasos en la entrega del
producto.
Las pruebas ágiles evitan el gasto excesivo
de tiempo, esfuerzos y dinero.
Garantiza una entrega rápida y la calidad
del software.

8. De acuerdo con los atributos de la calidad propuestos por la Norma ISO 9126 complete la
siguiente tabla en forma priorizada:

Atributo de la Calidad Atributo de la Calidad Atributo de la Calidad

Producto de Software
#1 #2 #3
Software de Gestión
comercial Funcionalidad Confiabilidad Usabilidad
MercadoPago.com Confiabilidad Rendimiento Funcionalidad
Aula virtual de un curso web Usabilidad Rendimiento Portabilidad
Sistema suscripción de un
diario digital Usabilidad Funcionalidad Eficiencia
Sistema de autogestión de
alumnos de una Universidad Confiabilidad Eficiencia Usabilidad

9. Proponga usted cinco ejemplos adicionales a los presentados en el punto anterior y priorice los
atributos según la norma ISO 9126. Justifique.

Atributo de la Calidad Atributo de la Calidad Atributo de la Calidad

Producto de Software
#1 #2 #3
Whatsapp Funcionalidad Confiabilidad Usabilidad
Despegar.com Confiabilidad Usabilidad Portabilidad
SAP Confiabilidad Funcionalidad Eficiencia
Sistemas SCADA Confiabilidad Disponibilidad Eficiencia
Google maps Eficiencia Confiabilidad Rendimiento
10. Investigue y describa cómo ha evolucionado el concepto de testing de software a lo largo de los
años.

• 1950 → Periodo orientado a la depuración (debugging): No había diferencia entre testear y

depurar, la persona que escribía el programa lo depuraba y lo probaba. Se enfocaban más en el
hardware.

• 1957-1978 → Periodo orientado a la demostración: Las pruebas aseguran que el software

satisface los requerimientos. En la bibliografía de la época ya resaltaban las diferencias del
debugging y el testing. Se comenzó a enfocar en las técnicas de Testing.

• 1979-1983 → Periodo orientado a la destrucción: Comenzaron a realizar pruebas para detectar

fallas en la impmentación. El concepto de testing ya estaba pulido, algunas bibliografías lo
definían como “el proceso de ejecutar un programa con la intención de encontrar errores”. (G.
Myers, The Art of Software Testing 1979).

• 1983-1995 → Periodo orientado a Evaluación: Testing para evaluar el producto durante el ciclo
de vida del software.

• 1995-2010 → Periodo orientado a Prevención: Testing para prevenir fallas en requerimientos,

diseño e implementación.

De acuerdo con esto, podemos mostrar la evolución del testing de software en 4 fases:

• Fase 0: No hay diferencia entre el testing y el debugging.

• Fase 1: El propósito del testing es mostrar que el software trabaja.

• Fase 2: El propósito del testing es mostrar que el software no trabaja.

• Fase 3: El propósito del testing no es demostrar que hay algo, sino reducir el riesgo percibido de
no funcionar a un valor aceptable.

• Fase 4: El testing no es un acto. Es una disciplina mental que dan como resultado un software
de bajo riesgo sin mucho esfuerzo de prueba.

11. Relacione la actividad de especificar requerimientos de software y la actividad de testing de

software.

Ambas actividades deben ir de la mano para lograr el funcionamiento correcto del software que se está
desarrollando, la captura de requerimientos debe ser lo suficientemente clara y concisa como para que
el Tester pueda interpretarla para poder validar lo que se ha desarrollado realizando las pruebas
pertinentes.