Unidad 3

Unidad 3 – Aseguramiento de la Calidad
●
Conceptos de calidad
●
Factores que inciden en la calidad: fiabilidad,
disponibilidad y seguridad
●
Gestión de la calidad
●
Garantía de la calidad
●
Planificación de la calidad
●
Control de la calidad
●
Actividades de la SQA
●
Modelos de calidad
●
CMM
●
CMMI
●
Revisiones de software
●
Revisiones Técnicas Formales (RTF)
IS Unidad 3 - Luis Nieto - 2022 2

●
Pruebas del software
●
Pruebas de componentes
●
Pruebas del sistema
●
Pruebas de integración
●
Pruebas de entregas
●
Pruebas de rendimiento
●
Diseño de casos de prueba

Unidad 3 – Conceptos de calidad
●
Para productos tangibles, la calidad depende de
la similitud entre el producto desarrollado y su
especificación
●
El control de variación es la base del control de
calidad: se quiere reducir la variación entre los
productos que se fabrican

●
En el SW el esfuerzo se centra en controlar la
variación en:
●
el proceso que se aplica
●
los recursos que se consumen
●
los atributos de calidad del producto final
●
En el SW se quiere reducir la diferencia entre los
recursos planificados y los reales utilizados

●
Calidad: “característica o atributo de algo”
●
Como un atributo de un elemento, la calidad se
refiere a las características medibles: cosas
que se pueden comparar con estándares
conocidos: longitud, color, etc
●
El SW es más difícil de caracterizar que los
objetos físicos. Algunas propiedades:
complejidad, cohesión, número de puntos de
función, líneas de código, etc

●
satisfacción del usuario = producto
satisfactorio + buena calidad + entrega
dentro de presupuesto y tiempo
establecidos
●
La calidad es importante, pero si el usuario no
queda satisfecho nada más importa
●
Esta visión de la calidad establece que si el
producto SW proporciona un beneficio sustancial
a los usuarios finales, éstos pueden estar
dispuestos a tolerar problemas ocasionales de
rendimiento o fiabilidad
●
El costo de la calidad incluye todos los costos
acarreados en la búsqueda de calidad o en las
actividades relacionadas con la obtención de
calidad
●
Los costos de calidad están asociados con:
●
Prevención
●
Evaluación
●
Fallos

●
Prevención: planificación, revisiones técnicas
formales, equipo de pruebas y formación
●
Evaluación: actividades para tener una visión
más profunda de la condición del producto. Por
ejemplo: inspección del proceso, mantenimiento
del equipo, pruebas

●
Fallos: se dividen en:
●
Internos: se producen cuando se detecta un
error en el producto antes de su envío
(retrabajo o revisión, reparación, análisis de las
modalidades de fallos, etc)
●
Externos: debido a defectos encontrados una
vez enviado el producto al cliente (resolución
de quejas, devolución y sustitución de
productos, soporte de línea de ayuda, trabajo
de garantía)
●
Los costos relativos para encontrar y reparar un
defecto aumentan a medida que se cambia de
prevención a detección, y desde fallos internos a
externos.
40-1000
veces
Costo relativo de corregir un error
30-70
veces
15-40
veces
10 veces
3-6 veces
1 vez
Prueba de Prueba de En fase de

Requisitos Diseño Código
desarrollo sistema explotación
Unidad 3 – Fiabilidad, disponibilidad y
seguridad
●
Factores que inciden en la calidad:
●
Fiabilidad
●
Disponibilidad
●
Seguridad

seguridad
●
Fallo: cualquier falta de concordancia con los
requisitos del SW:
●
En el HW los fallos son más probables debido
al desgaste físico que al diseño
●
En el SW los fallos se producen por problemas
de diseño o de implementación
●
Fiabilidad: probabilidad de operación libre de
fallos en un entorno determinado y durante un
tiempo específico

seguridad
●
La fiabilidad del SW es un elemento importante
de su calidad general: si falla frecuentemente en
su funcionamiento, no importa si el resto de los
factores de calidad son aceptables
●
La fiabilidad del SW, a diferencia de otros
factores de calidad, puede ser medida o estimada
mediante datos históricos o de desarrollo

seguridad
●
Una medida de la fiabilidad es el tiempo medio
entre fallos (TMEF):
●
TMEF = TMDF + TMDR
●
TMDF: tiempo medio de fallo
●
TMDR: tiempo medio de reparación
●
Muchos argumentan que el TMDF es una medida
más útil que los defectos/KSLOC o defectos/PF
porque el usuario final se enfrenta a los fallos, no
al número total de errores
seguridad
●
Disponibilidad: probabilidad que el SW funcione
de acuerdo con los requisitos en un momento
dado:
●
Disp = [TMDF / (TMEF)] x 100%
●
La disponibilidad es una medida indirecta de la
facilidad de mantenimiento del SW

seguridad
●
Antes que se usara SW en sistemas críticos de
seguridad, los mismos se controlaban mediante
dispositivos electrónicos y mecánicos (no
programables)
●
Las técnicas de seguridad se diseñaban para
hacer frente a fallos aleatorios en estos
dispositivos

seguridad
●
Cuando se utiliza SW como parte del sistema de
control, la complejidad puede aumentar en un
orden de magnitud o más
●
La seguridad del SW se centra en la identificación
y evaluación de los riesgos potenciales que
podrían producir un impacto negativo y hacer
que falle el sistema completo

Unidad 3 – Gestión de la Calidad
●
La Gestión de la Calidad se estructura en 3
actividades principales:
●
Garantía de la calidad (SQA):
procedimientos y estándares que conducen a
SW de alta calidad
●
Planificación de la calidad: selección de
procedimientos y estándares adecuados
●
Control de calidad: inspecciones, revisiones
y pruebas a lo largo del proceso SW

Unidad 3 – Garantía de la Calidad
●
Durante los años '50 y '60, la calidad era
responsabilidad únicamente del programador
●
Luego, durante los '70 se introdujeron estándares
de garantía de calidad para el SW en los
contratos militares
●
Estos estándares se extendieron rápidamente a
los desarrollos comerciales, con lo cual, muchos
de los que constituyen una organización tienen
responsabilidad sobre la garantía de calidad
●
Los responsables de SQA miran al SW desde el
punto de vista del cliente:
●
¿Satisface de forma adecuada el SW los
factores de calidad?
●
¿Se ha realizado el desarrollo de acuerdo con
estándares preestablecidos?

●
SQA es el proceso que define cómo lograr la
calidad del SW y cómo conoce la organización el
nivel de calidad requerido en el SW
●
Se pueden definir estándares para:
●
El producto
●
El proceso

●
Estándares para el producto: se aplican sobre
el producto SW que se comienza a desarrollar.
Incluyen estándares de documentación, de
codificación, etc
●
Estándares para el proceso: definen los
procesos a seguir durante el desarrollo del SW. Se
pueden incluir definiciones de procesos de
especificación, diseño y validación, así como una
descripción de los documentos que se deben
escribir en el curso de estos procesos
●
Los estándares de SW son importantes porque:
●
Están basados en el conocimiento de la mejor
o más apropiada práctica de la organización
●
Proveen un marco de trabajo alrededor del cual
se implementa el proceso de garantía de la
calidad
●
Ayudan a la continuidad cuando una persona
continúa el trabajo que llevaba a cabo otra
Unidad 3 – Planificación de la Calidad
●
Planificación de la calidad:
●
Proceso que define qué es “software de alta
calidad”, desarrollando un plan de calidad para
un proyecto
●
Se define la calidad del SW deseado y se
describe cómo valorar la misma
●
Se seleccionan los estándares organizacionales
apropiados para un producto y proceso de
desarrollo particulares

●
Estructura sugerida para un plan de calidad:
●
Introducción al producto: descripción del
producto, el mercado al que se dirige y las
expectativas de calidad
●
Planificación del producto: fechas de
terminación y las responsabilidades
importantes junto con los planes para la
distribución y el servicio

●
Estructura sugerida para un plan de calidad:
●
Descripción de procesos: procesos a utilizar
para el desarrollo y administración del
producto
●
Metas de calidad: metas y planes de calidad
para el producto
●
Riesgos y gestión de riesgos: riesgos clave
que podrían afectar a la calidad del producto y
las acciones para abordarlos
●
Hay una gran variedad de atributos de calidad
del SW a considerar en el proceso de
planificación de la calidad:
Seguridad Reutilización
Comprensión Flexibilidad
Portabilidad Modularidad
Protección Eficacia
Usabilidad Robustez
Fiabilidad Complejidad
Adaptabilidad Aprendizaje
●
En general, no es posible optimizar todos los
atributos para un sistema: el plan de calidad
define los atributos de calidad más importantes
para el producto a desarrollar

Unidad 3 – Control de la Calidad
●
El control de la calidad implica vigilar el proceso
de desarrollo para asegurar que se siguen los
procedimientos y los estándares de garantía de
calidad
●
Existen 2 enfoques complementarios que se
utilizan para comprobar la calidad:
●
Revisiones de la calidad
●
Valoración automática del software

●
Revisiones de la calidad: el SW, su
documentación y los procesos utilizados en su
desarrollo son revisados por un grupo de
personas:
●
Se comprueba que se hayan seguido los
estándares del proyecto, y que el SW y los
documentos concuerdan con los mismos
●
Se anotan las desviaciones de los estándares y
se comunican al gestor del proyecto

●
Valoración automática del software: el
software y los documentos producidos se
procesan por algún programa y se comparan con
los estándares que se aplican a ese proyecto de
desarrollo en particular
●
Esta valoración automática comprende una
medida cuantitativa de algunos atributos del
software

Unidad 3 – Actividades de la SQA
●
Actividades de SQA recomendadas por el SEI:
●
Planificar SQA para un proyecto
●
Describir el proceso SW
●
Revisar que las actividades de IS se ajustan al
proceso SW definido
●
Documentar las desviaciones
●
Auditar que los productos SW se ajusten como
parte del proceso SW
●
Registrar e informar lo que no se ajuste a los
requisitos
●
Planificar SQA para un proyecto. El plan se
desarrolla durante la planificación del proyecto y
se revisa por todas las partes interesadas
●
El plan identifica:
●
Evaluaciones a realizar
●
Auditorías y revisiones a realizar
●
Estándares que se pueden aplicar al proyecto
●
Procedimientos para información y
seguimiento de errores
●
Documentos producidos por el grupo SQA
●
Describir el proceso SW. El equipo de IS
selecciona un proceso para el trabajo que se va a
realizar
●
El grupo de SQA revisa que la descripción del
proceso se ajuste a la política de la empresa, los
estándares internos del SW, los estándares
impuestos externamente y a otras partes del plan
de proyecto del SW

●
Revisar que las actividades de IS se ajustan
al proceso SW definido. El grupo de SQA
identifica y documenta las desviaciones del
proceso y verifica que se han hecho las
correcciones
●
Documentar las desviaciones. Las
desviaciones se pueden encontrar en el plan del
proyecto, en la descripción del proceso, en los
estándares, etc

●
Auditar que los productos SW se ajusten
como parte del proceso SW. El grupo de SQA
revisa los productos seleccionados; identifica,
documenta y lleva el control de las desviaciones;
verifica que se han hecho las correcciones, e
informa periódicamente al gestor del proyecto
●
Registrar e informar lo que no se ajuste a
los requisitos. Los elementos que no se ajustan
a los requisitos están bajo seguimiento hasta que
se resuelven
●
Además de estas actividades, el grupo de SQA
coordina el control y la gestión de cambios y
ayuda a recopilar y analizar las métricas del SW

Unidad 3 – Modelos de Calidad
calidad
●
El proceso SW es genérico: el ideal que debería
seguir una organización para conseguir productos
de calidad
●
En realidad, cada organización debe definir su
proceso SW para detectar si es adecuado o no y
cuánto dista del ideal

calidad
●
El peor de los casos (muy frecuente) es una
organización que no sigue proceso alguno para
construir SW, y por lo tanto, no hay una guía para
construir SW
●
Un equipo que sigue un proceso SW puede:
●
Coordinar mejor el trabajo de cada miembro
●
Seguir de un modo preciso los avances tanto
individuales como del equipo completo
calidad
●
Un proceso SW:
●
Ayuda a asegurar que cada elemento de
trabajo se asigne y se siga adecuadamente
●
Es un mecanismo para un aprendizaje
ordenado
●
Permite que cada proyecto nuevo sea
construido basado en su propia experiencia y
en anteriores

calidad
●
Ventajas al definir un proceso SW:
●
Se facilita la comunicación entre usuarios,
desarrolladores, gestores y clientes sobre el
proceso
●
Se gana una mejor comprensión de la gestión
●
Se brinda una base precisa para la
automatización del proceso
●
Se facilita la movilidad de las personas dentro
del proceso

calidad
●
Ventajas al definir un proceso SW:
●
Se facilita la reutilización del proceso: cada
proyecto nuevo no necesita redefinir
completamente su modo de trabajo
(estándares reutilizables)
●
Ayuda a la gestión del proceso: provee planes
claros y un modo preciso y cuantificado de
comparar el estado con los planes

calidad
●
Los procesos son difíciles de establecer, pero más
difíciles aún de cambiar
●
Los procesos deben cambiar continuamente para
ser mejorados
●
Conclusión: no es suficiente con definir el
proceso SW de una organización, sino que
además el mismo debe sufrir una mejora
permanente
Unidad 3 – CMM
●
El SEI desarrolló un marco de madurez del
proceso software, el cual permite a las
organizaciones determinar las capacidades de
sus procesos actuales y definir prioridades de
mejoras
●
Este marco de madurez definido por el SEI se
llama Modelo de Capacidad y Madurez o
Capability Maturity Model (CMM), y está
organizado en 5 niveles

Unidad 3 – CMM

Unidad 3 – CMM
●
Para cada nivel se definen Áreas Clave de
Proceso (KPA), las cuales proporcionan los
objetivos y prácticas a alcanzar en cada nivel
●
Se lo llama modelo de madurez porque propone
adoptar un conjunto de prácticas en forma
gradual: primero deben ponerse en práctica KPAs
pertenecientes a un nivel determinado, para
luego, sobre esta base, introducir las
correspondientes al nivel siguiente

Unidad 3 – CMM
●
Nivel 1 – Inicial
●
Representa una situación sin ningún esfuerzo
en la garantía de calidad y gestión del
proyecto, donde cada equipo puede desarrollar
SW de cualquier forma eligiendo distintos
métodos, estándares y procedimientos
●
El proceso software es ad-hoc y,
ocasionalmente, incluso caótico. El éxito
depende del esfuerzo individual
●
KPA: no tiene

Unidad 3 – CMM
●
Nivel 2 – Repetible
●
Están establecidos ciertos procesos básicos de
gestión de proyectos para seguir el costo, el
calendario y la funcionalidad
●
Hay la disciplina necesaria para repetir éxitos
conseguidos con anterioridad

Unidad 3 – CMM
●
Nivel 2 – Repetible
●
KPA:
– Gestión de configuración
– Garantía de calidad
– Gestión de la subcontratación
– Seguimiento de proyectos
– Planificación de proyectos
– Gestión de requisitos

Unidad 3 – CMM
●
Nivel 3 – Definido
●
Representa el hecho de que un desarrollador
ha definido tanto procesos técnicos como de
gestión
●
Por ejemplo se ha detallado un estándar para
la programación, y se hace cumplir por medio
de procedimientos tales como auditorías

Unidad 3 – CMM
●
Nivel 3 – Definido
●
KPA:
– Revisiones profundas
– Coordinación entre grupos
– Ingeniería de la producción de software
– Gestión integrada en el proceso
– Programa de formación
– Definición del proceso
– Focalización en el proceso

Unidad 3 – CMM
●
Nivel 4 – Gestionado
●
Comprende el concepto de medición y el uso
de métricas
●
Estas métricas proporcionan alguna indicación
del esfuerzo necesario para probar el código
●
Una organización de nivel 4 maneja numerosas
métricas, las cuales se utilizan para supervisar
y controlar un proyecto SW

Unidad 3 – CMM
●
Nivel 4 – Gestionado
●
KPA:
– Gestión de la calidad
– Gestión cualitativa del proceso

Unidad 3 – CMM
●
Nivel 5 – Optimizado
●
Representa la analogía del SW con los
mecanismos de control de calidad que existen
en otras industrias de mayor madurez
●
Un desarrollador de SW de nivel 5 puede
predecir resultados basado en la medición
tomada durante la ejecución de un proyecto

Unidad 3 – CMM
●
Nivel 5 – Optimizado
●
KPA:
– Gestión de cambio de proceso
– Gestión de cambio de tecnología
– Prevención de defectos

Unidad 3 – CMM
●
El CMM ha sido revisado y refinado por muchos
especialistas para ponerse de acuerdo en los
métodos más efectivos para alcanzar los
objetivos de cada nivel de madurez

Unidad 3 – CMMI
●
El modelo de capacidad y madurez
integrado (CMMI) es un modelo de referencia o
conjunto de prácticas enfocadas a mejorar los
procesos de una organización
●
El modelo utiliza el paradigma de mejora del
proceso ya que el mismo no solo refleja el estado
del arte del proceso SW, también permite
establecer metas y prioridades para la mejora del
proceso, estableciendo un plan centrado en la
medición y cuantificación objetiva de los mismos
Unidad 3 – CMMI
●
El propósito de CMMI para desarrollo es ayudar a
las organizaciones a mejorar sus procesos de
desarrollo de productos
●
Consiste en definir las mejores prácticas que
tratan las actividades de desarrollo
comprendiendo el ciclo de vida completo del
producto, desde la concepción hasta la entrega y
mantenimiento del mismo, adaptándose
completamente la aplicación del modelo a la
organización
Unidad 3 – CMMI
●
La estrategia adoptada por CMMI produce
beneficios operativos:
●
Reducción de costo y tiempo de entrega
●
Mayor productividad
●
Menores tiempos de desarrollo
●
Disminución del retrabajo y errores
●
Mayor calidad del producto y satisfacción del
cliente.

Unidad 3 – CMMI
●
Al igual que CMM, fue creado por el SEI con la
colaboración de la industria, el gobierno y el
ámbito académico, con el fin de unir una gran
cantidad de modelos existentes
●
En la actualidad hay 3 áreas de interés cubiertas
por los modelos de CMMI:
●
Desarrollo (CMMI-DEV)
●
Adquisición (CMMI-ACQ)
●
Servicios (CMMI-SVC)
Unidad 3 – CMMI
●
CMMI-DEV: guías para medir, monitorizar y
administrar el proceso de desarrollo
●
CMMI-ACQ: guías para el proceso de adquisición
de productos y servicios
●
CMMI-SVC: guías para proporcionar servicios en
una organización y a clientes externos

Unidad 3 – Revisiones de Software
●
Las revisiones de software son un "filtro" para el
proceso de IS
●
Las revisiones se aplican en varios momentos del
desarrollo y sirven para detectar errores y
defectos que puedan ser eliminados
●
También, se necesitan revisiones porque aunque
la gente es buena descubriendo algunos de sus
propios errores, algunas clases de errores le
pasan por alto más fácilmente al que los origina
que a otras personas

●
Una revisión es una forma de aprovechar la
diversidad de un grupo de personas para:
●
Señalar la necesidad de mejoras (en el
producto) de una sola persona o un equipo
●
Confirmar las partes de un producto en las que
no es necesaria o no es deseable una mejora
●
Conseguir un trabajo técnico de una calidad
más uniforme, o al menos más predecible, que
la que puede ser conseguida sin revisiones

●
Existen muchos tipos diferentes de revisiones
que se pueden llevar adelante como parte de la
IS:
●
Una reunión informal es una forma de revisión
(si se discuten problemas técnicos)
●
Una presentación formal de un diseño de
software a una audiencia de clientes,
ejecutivos y personal técnico es una forma de
revisión

Unidad
Unidad
3 –3
Revisiones
– Revisiones
Técnicas
de Software
Formales
●
Una revisión técnica formal (RTF), a veces
denominada inspección, es el filtro más efectivo
desde el punto de vista de garantía de calidad
●
La RTF es un medio efectivo para mejorar la
calidad del SW
●
El objetivo primario de las RTF es encontrar
errores durante el proceso, de forma que no se
conviertan en defectos después de la entrega
Unidad 3 – Revisiones
Unidad 3 Técnicas
– RTF Formales
●
Los objetivos de una RTF son:
●
Descubrir errores en la función, la lógica o la
implementación de cualquier representación
del SW
●
Verificar que el SW alcanza sus requisitos
●
Garantizar que el SW ha sido representado de
acuerdo a estándares predefinidos
●
Conseguir un SW desarrollado de forma
uniforme
●
Hacer que los proyectos sean más manejables
Unidad 3 Técnicas
– RTF Formales
●
La RTF también sirve para promover la seguridad
y la continuidad, ya que varias personas se
familiarizarán con partes del SW que, de otro
modo, no hubieran visto nunca

Unidad 3 Técnicas
– RTF Formales
●
Cada RTF se lleva a cabo mediante una reunión
●
Cualquier reunión de revisión debe seguir las
siguientes restricciones:
●
Se deben convocar entre 3 y 5 personas
●
Se debe preparar por adelantado, pero sin que
requiera más de 2 horas de trabajo a cada
persona
●
La duración de la reunión debe ser menor de 2
horas

Unidad 3 Técnicas
– RTF Formales
●
Cada RTF se centra en una parte específica (y
chica) del SW total
●
Por ejemplo, en lugar de intentar revisar un
diseño completo, se hacen inspecciones a cada
módulo o pequeño grupo de módulos
●
Al limitar el centro de atención de la RTF, la
probabilidad de descubrir errores es mayor

Unidad 3 Técnicas
– RTF Formales
●
Quien desarrolló un producto (productor) informa al
jefe del proyecto que el mismo está terminado y que
requiere una revisión
●
Se evalúa la disponibilidad del producto, se generan
copias del mismo y se las distribuye a 2 o 3 revisores
para que se preparen por adelantado
●
Cada revisor revisa el producto, toma notas y se
familiariza con el trabajo

Unidad 3 Técnicas
– RTF Formales
●
Se establece una agenda para la reunión de
revisión que se suele convocar para el día
siguiente
●
La reunión de revisión se lleva a cabo por el jefe,
los revisores y el productor, registrando de forma
escrita todos los sucesos importantes que se
produzcan durante la reunión

Unidad 3 Técnicas
– RTF Formales
●
La RTF comienza con una explicación de la
agenda y una breve introducción a cargo del
productor
●
El productor explica el material, mientras que los
revisores exponen los resultados de sus
revisiones basándose en su preparación previa
●
Se registran los problemas o errores válidos que
se descubren
Unidad 3 Técnicas
– RTF Formales
●
Al final de la revisión, todos los participantes en la
RTF deben decidir si:
●
Aceptan el producto sin posteriores modificaciones
●
Rechazan el producto debido a los serios errores
encontrados (una vez corregidos, se hace otra
revisión)
●
Aceptan el producto provisoriamente (se han
encontrado errores menores que deben ser
corregidos, pero sin necesidad de otra revisión
posterior)

Unidad 3 Técnicas
– RTF Formales
●
Una vez tomada la decisión, todos los
participantes terminan firmando, indicando así
que han participado en la revisión y que están de
acuerdo con las conclusiones del equipo de
revisión

Unidad 3 Técnicas
– RTF Formales
●
Al final de la reunión se prepara un informe, el cual
responde a 3 preguntas:
●
¿Qué fue revisado?
●
¿Quién lo revisó?
●
¿Qué se descubrió y cuáles son las conclusiones?
●
El informe es una página simple (con posibles
suplementos). Se adjunta al registro histórico del
proyecto y puede ser enviada al jefe del proyecto y a
otras partes interesadas

Unidad 3 Técnicas
– RTF Formales
●
Se deben establecer de antemano directrices
para conducir las RTF, distribuyéndolas después
entre los revisores, para ser consensuadas y,
finalmente, seguidas
●
Frecuentemente, una revisión incontrolada puede
ser peor que no hacer ningún tipo de revisión

Unidad 3 Técnicas
– RTF Formales
●
Revisar el producto, no al productor. Una
RTF involucra gente y egos. Se deben señalar los
errores educadamente; el tono de la reunión
debe ser distendido y constructivo; no debe
intentarse dificultar o batallar
●
Fijar una agenda y mantenerla. Un mal de las
reuniones de todo tipo es la deriva. La RTF debe
seguir un plan de trabajo concreto. El jefe de
revisión es el responsable de mantener el plan de
la reunión
Unidad 3 Técnicas
– RTF Formales
●
Limitar el debate y las impugnaciones. Cuando
un revisor ponga de manifiesto otro tipo de
problema, podrá no haber unanimidad sobre su
impacto. En lugar de perder el tiempo debatiendo la
cuestión, debe registrarse el hecho y dejar que la
cuestión se lleve a cabo en otro momento
●
Tomar notas escritas. A veces es buena idea que
el que registra tome las notas en una pizarra, de
forma que las declaraciones o la asignación de
prioridades pueda ser comprobada por el resto de los
revisores
Unidad 3 Técnicas
– RTF Formales
●
Enunciar áreas de problemas, pero no intentar
resolver cualquier problema que se ponga de
manifiesto. Una revisión no es una sesión de
resolución de problemas. La resolución de los
problemas debe ser pospuesta para después de la
reunión de revisión
●
Disponer recursos y una agenda para las RTF.
Para que las revisiones sean efectivas, se deben
planificar

Unidad 3 Técnicas
– RTF Formales
●
Limitar el número de participantes e insistir
en la preparación anticipada. 2 personas son
mejores que 1, pero 14 no son necesariamente
mejores que 4. Se ha de mantener el número de
participantes en el mínimo necesario
●
Desarrollar una lista de comprobación para
cada producto que haya de ser revisado.
Una lista de comprobaciones ayuda al jefe de
revisión a estructurar la reunión y ayuda a cada
revisor a centrarse en los asuntos importantes
Unidad 3 Técnicas
– RTF Formales
●
Repasar las revisiones anteriores. Las
sesiones de información pueden ser beneficiosas
para descubrir problemas en el propio proceso de
revisión. El primer producto que se haya revisado
puede establecer las propias directivas de
revisión
●
Llevar a cabo un buen entrenamiento de
todos los revisores. Por razones de efectividad,
todos los participantes en la revisión deben
recibir algún entrenamiento formal
Unidad 3 Técnicas
– RTF Formales
●
Como existen muchas variables (número de
participantes, tipo de productos de trabajo,
tiempo y duración, enfoque de revisión
específico) que tienen impacto en una revisión
satisfactoria, una organización deberá determinar
qué método funciona mejor en un contexto local

Unidad 3 – Pruebas del Software
software
●
El proceso de pruebas comienza con la prueba de
unidades: funciones, objetos, etc
●
Luego estas unidades se integran en subsistemas
y sistemas y se prueban las interacciones entre
los mismos
●
Finalmente, después de entregar el sistema, el
cliente puede llevar a cabo una serie de pruebas
de aceptación para comprobar que el mismo
funciona como se especificó
software
●
Este modelo de pruebas es apropiado para el
desarrollo de sistemas grandes, pero para
sistemas más chicos a veces se distinguen
menos etapas en el proceso:
Pruebas del Pruebas de

componente integración

software
●
Prueba de componentes (prueba unitaria)
●
Es un fragmento de código para verificar que
otro código, normalmente la implementación
de una característica, funciona correctamente.
– Por ejemplo, si se agrega un elemento a una
lista, las pruebas adecuadas garantizarán
que la misma crezca en uno y que el nuevo
elemento se inserte en la posición correcta.

software
●
●
Es una práctica común en el Desarrollo Guiado
por Pruebas (TDD) y Desarrollo Guiado por
Comportamiento (BDD), en los cuales primero
se escribe una prueba que falle, luego se
escribe el código de producción necesario para
que pase la prueba, y finalmente el código se
refactoriza para mejorar su calidad (el código
que se escribe es tal que sólo satisface una
prueba fallida y es sólo el necesario).

software
●
●
Las pruebas unitarias se agrupan en clases. A
cada una de estas clases se las llama caso de
prueba.
●
Un solo caso de prueba especifica el
comportamiento de un componente
representado por una clase.
●
La clase de prueba expresa la intención de
desarrollar un cierto componente, al cual se lo
denomina Sistema Bajo Prueba (System
Under Test o SUT).
software
●
●
Ejemplo: se quiere determinar si un
determinado conductor es válido o no teniendo
en cuenta:
– Su edad (debe tener 18 años o más)
– Si tiene carnet
– Si el impuesto de la patente está al día
– Si tiene seguro

software
●
●
Se podría pensar en una clase llamada
ConductorTest (clase de prueba)
●
ConductorTest probará las características de
un conductor, implementado mediante la clase
Conductor (SUT)
●
Las distintas pruebas unitarias para determinar
si un conductor es válido o no se agruparán en
la clase ConductorTest (todas estas pruebas
forman un caso de prueba)

software
●
Prueba de sistema
●
A medida que las pruebas de componentes son
exitosas, los mismos se integran y se realizan
pruebas a la integración.
●
Esta integración irá creciendo hasta
transformarse en el sistema final, en cuyo
momento se lo probará como un todo.
●
Se busca establecer que el sistema satisface
sus requerimientos funcionales, y no se
comporta de forma inesperada.

software
●
Objetivos del proceso de pruebas:
●
Demostrar al desarrollador y al cliente que el
SW satisface sus requerimientos
●
Descubrir defectos en el SW (comportamiento
incorrecto o no deseable, incumplimiento de su
especificación, etc)

software
●
Objetivos del proceso de pruebas:
●
Demostrar que el SW satisface sus
requerimientos → pruebas de validación
– Una prueba de validación exitosa demuestra
que el sistema funciona correctamente
●
Descubrir defectos en el SW → pruebas de
defectos
– Una prueba de defectos exitosa demuestra un
defecto en el sistema

software
●
Las pruebas:
●
No pueden demostrar que el SW está libre de
defectos
●
No pueden demostrar que se comportará en
todo momento como está especificado
●
Sólo pueden demostrar la presencia de
errores, no su ausencia
●
El objetivo de las pruebas es convencer a los
desarrolladores y a los clientes que el SW es lo
suficientemente bueno para uso operacional

software
●
Modelo general del proceso de pruebas:
Resultados de Informe de la
Casos de prueba Datos de prueba
la prueba prueba
Ejecutar el programa Comparar resultados

Diseñar casos de Preparar datos de
con los datos de con los datos de
prueba prueba
prueba prueba

software
●
Es imposible probar cada posible secuencia de
ejecución del programa, por lo que se deben
probar:
●
Todas las funciones accedidas desde menús
●
Todas las combinaciones de funciones
●
Todas las funciones con datos correctos e
incorrectos

software
●
Los gestores deciden quién será responsable de
las diferentes etapas de pruebas:
●
Generalmente, los programadores tienen la
responsabilidad de probar sus componentes
(pruebas unitarias)
●
Una vez que lo hacen, el trabajo se pasa a un
equipo de integración que integra los módulos
de diferentes desarrolladores y prueba el
sistema como un todo

Unidad 3 – Pruebas de Componentes
componentes
●
Pruebas de componentes (de unidad)
●
Consisten en probar los componentes
individuales en el sistema
●
Su objetivo es encontrar defectos en los
componentes del sistema

componentes
●
Tipos de componentes:
●
Funciones/métodos dentro de un objeto
●
Clases con varios atributos y métodos
●
Componentes formados por diferentes objetos
o funciones (se accede a su funcionalidad
mediante una interfaz)

componentes
●
Cuando se prueban métodos se los llama con
diferentes parámetros de entrada (correctos e
incorrectos)
●
Al probar las clases se deben cubrir todas sus
características:
●
Todos sus métodos
●
Asignación y consulta de todos sus atributos
●
Comportamiento del objeto en todos sus
posibles estados
componentes
●
Muchos componentes están formados por varios
objetos, accediendo a sus funcionalidades por
medio de sus interfaces
●
Las pruebas de estos componentes se ocupan
principalmente de probar que la interfaz del
componente se comporta de acuerdo con su
especificación

Unidad 3 – Pruebas del sistema
●
Las pruebas del sistema implican integrar y
probar 2 o más componentes que implementan
funciones o características del sistema:
●
En un desarrollo iterativo, estas pruebas
prueban un incremento que va a ser entregado
al cliente
●
En un desarrollo en cascada, estas pruebas
prueban el sistema completo

Unidad 3 – Pruebas del sistema
●
Para la mayoría de los sistemas complejos,
existen 2 fases distintas de pruebas del sistema:
●
●
Pruebas de entregas

Unidad
Unidad3 3– –Pruebas
Pruebasde
del
integración
sistema
●
●
Se tiene acceso al código fuente (pruebas de
caja blanca)
●
Cuando se descubre un problema, se intenta
encontrar el origen del mismo e identificar los
componentes que tienen que ser depurados
●
Se ocupan principalmente de encontrar
defectos en el sistema
Unidad 3 – Pruebas de integración
●
El proceso de integración implica construir un
sistema a partir de sus componentes y probar el
mismo para encontrar problemas que pueden
surgir debido a la integración
●
Las pruebas de integración comprueban que
estos componentes realmente funcionan juntos,
son llamados correctamente y transfieren los
datos correctos en el tiempo preciso a través de
sus interfaces

Unidad 3 – Pruebas de integración
●
La principal dificultad es la localización de los
errores
●
Esto implica que cuando se integra un nuevo
incremento, es importante volver a ejecutar las
pruebas para incrementos previos, así como las
nuevas pruebas requeridas para verificar la
nueva funcionalidad del sistema
●
Volver a ejecutar un conjunto existente de
pruebas se denomina pruebas de regresión
Unidad 3 – Pruebas de entregas
●
Pruebas de entregas
●
Se prueba una versión del sistema que podría
ser entregada a los usuarios (suelen ser de
caja negra)
●
Se valida que el sistema satisface sus
requerimientos y que es confiable
●
Cuando los clientes se involucran se las suele
llamar pruebas de aceptación
●
Pruebas de entregas
●
El principal objetivo es demostrar que el sistema
satisface sus requerimientos:
– Demostrar que el sistema entrega la
funcionalidad especificada
– Demostrar que el sistema tiene el rendimiento
especificado
– Demostrar que el sistema no falla durante su
uso normal

●
Pruebas de entregas
●
Se debe intentar “romper” el SW:
– Elegir entradas que fuerzan que el sistema
genere todos los mensajes de error
– Diseñar entradas que hagan que los buffers
de entrada se desborden
– Repetir la misma entrada varias veces
– Forzar a que se generen salidas inválidas
– Forzar los resultados de los cálculos para
que sean muy grandes o muy pequeños
Unidad
Unidad33
– Pruebas
– Pruebas
dede
rendimiento
entregas
●
●
Una vez que un sistema se ha integrado
completamente, es posible probar las
propiedades emergentes del mismo, como el
rendimiento y la fiabilidad
●
Las pruebas de rendimiento se diseñan para
asegurar que el sistema puede procesar su
carga esperada

Unidad 3 – Pruebas de rendimiento
●
●
Al igual que otros tipos de pruebas, las pruebas
de rendimiento se ocupan tanto de demostrar
que el sistema satisface sus requerimientos
como de descubrir problemas y defectos en el
mismo
●
Las pruebas de rendimiento implican estresar
el sistema realizando demandas que están
fuera de los límites del diseño del SW

Unidad 3 – Pruebas de rendimiento
●
●
Objetivos:
– Sobrecargar el sistema provocando que se
manifiesten defectos normalmente ocultos
– Probar el comportamiento de fallo de

ejecución del sistema. Pueden aparecer
circunstancias a través de una combinación
no esperada de eventos en donde la carga
sobre el sistema supere la carga máxima
anticipada
Unidad 3 – Diseño de casos de prueba
●
En el diseño de casos de prueba se diseñan las
entradas y salidas esperadas para probar el
sistema
●
El objetivo es crear un conjunto de casos de
prueba que sean efectivos descubriendo defectos
en los programas y mostrando que el sistema
satisface sus requerimientos

●
Diseño de un caso de prueba:
●
Se selecciona una característica del sistema o
componente a probar
●
Se selecciona un conjunto de entradas que
ejecutan dicha característica, se documentan
las salidas esperadas, y si es posible se diseña
una prueba automatizada que pruebe que las
salidas reales y esperadas son las mismas

●
Enfoques que se pueden seguir para diseñar
casos de prueba:
●
Pruebas basadas en requerimientos
●
Pruebas de particiones
●
Pruebas estructurales
●
Pruebas de caminos
●
●
Se diseñan los casos de prueba para probar los
requerimientos del sistema
●
Se utiliza para las pruebas del sistema
●
Son pruebas de validación en lugar de pruebas
de defectos: se intenta demostrar que el
sistema ha implementado sus requerimientos
de forma adecuada
●
●
Los requerimientos deben poder probarse, por
lo que se los debe escribir de tal forma que se
pueda diseñar una prueba que permita
comprobar que los mismos se satisfacen

●
●
Los datos de E/S se pueden agrupar por
características comunes:
– Números positivos
– Números negativos
– Selecciones de menús
●
A estas características o categorías se las
denomina particiones o dominios

●
●
Se identifican todas las particiones para un
sistema o componente (los casos de prueba se
diseñan para que las E/S pertenezcan a estas
particiones)
●
Una buena práctica es elegir los límites de las
particiones junto con los valores cercanos al
punto medio de la partición (entradas válidas e
inválidas)

●
Pruebas estructurales
●
Con la estructura del programa, se diseñan
pruebas que ejecuten todas sus partes:
– Probar que cada sentencia se ejecuta al
menos una vez
●
También se las llama “pruebas de caja blanca"
●
La comprensión de la estructura del programa
ayuda a identificar particiones adicionales
●
Pruebas de caminos
●
Estrategia para las pruebas estructurales
●
Su objetivo es asegurar que cada camino
independiente en el programa o componente
se ejecuta al menos una vez:
– Si se prueba cada camino, todas las
sentencias del programa o componente se
habrán ejecutado al menos una vez

●
Pruebas de caminos
●
La cantidad de caminos en un programa es
proporcional a su tamaño
●
Como los distintos módulos se van integrando,
no se pueden usar estas pruebas (se las usa en
las pruebas de componente)

●
Pruebas de caminos
public boolean esValido(int edad, boolean carnet, LocalDate patente, boolean seguro) {
LocalDate hoy = LocalDate.now();
if (edad <= 17)
return false;
if (!carnet)
return false;
if (patente.isAfter(hoy))
return false;
if (!seguro)
return false;
else
return true;
}
●
Pruebas de caminos
●
Para probar todas las combinaciones:
Edad Carnet Patente Seguro Resultado Edad Carnet Patente Seguro Resultado
<=17 No Vencida No False >17 No Vencida No False
<=17 No Vencida Sí False >17 No Vencida Sí False
<=17 No Al día No False >17 No Al día No False
<=17 No Al día Sí False >17 No Al día Sí False
<=17 Sí Vencida No False >17 Sí Vencida No False
<=17 Sí Vencida Sí False >17 Sí Vencida Sí False
<=17 Sí Al día No False >17 Sí Al día No False
<=17 Sí Al día Sí False >17 Sí Al día Sí True

●
Pruebas de caminos
●
Las líneas de código fuente se pueden
representar en un grafo dirigido:
– Nodos: decisiones
– Aristas: flujo de control
– https://www.youtube.com/watch?
v=9N5vPeSWRfQ

●
Pruebas de caminos
public boolean valido(int edad, boolean carnet, LocalDate patente, boolean seguro) {
1 LocalDate hoy = LocalDate.now(); 1
2 if (edad <= 17)

2
3 return false;
4 if (!carnet) 3 4
5 return false;
5 6
6 if (patente.isAfter(hoy))
7 8
7 return false;
8 if (!seguro)
9 10
9 return false;
11
else
10 return true;
11}
●
Pruebas de caminos
●
La complejidad ciclomática V(G) es la cantidad
mínima de caminos independientes que
puede (en combinación lineal) generar todos
los posibles caminos a través de un método.
●
Formas de calcular V(G):
– V(G) = #aristas – #nodos + 2
– V(G) = #nodos predicado + 1
– V(G) = #regiones
– https://www.youtube.com/watch?v=iILl-n57IEs

●
Pruebas de caminos
●
Para el ejemplo:
– V(G) = #aristas - #nodos + 2
– V(G) = 14 – 11 + 2 = 5

●
Pruebas de caminos
●
¿Para qué sirve el valor de la complejidad
ciclomática?
– Para probar todas las combinaciones se
necesitaban 16 casos de prueba diferentes
(16 es el número máximo de casos de
prueba para cubrir todas las líneas de
código).

●
Pruebas de caminos
●
C1: considerar que el conductor no tenga la edad
mínima necesaria (no hace falta analizar las otras 3
variables)
C2: considerar que el conductor no tenga carnet (no
hace falta analizar las otras 3 variables)
●
C3: considerar que el conductor tenga vencida la
patente (no hace falta analizar las otras 3 variables)
●
C4: considerar que el conductor no tenga seguro (no
hace falta analizar las otras 3 variables)
●
C5: considerar que el conductor tenga la edad, carnet,
no esté vencida la patente y que tenga seguro
●
Pruebas de caminos
●
La complejidad ciclomática representa la cantidad
mínima de casos de prueba para cubrir de forma
completa un fragmento de código).
●
Si se ejecutan todos estos caminos, se puede
asegurar que cada sentencia se ejecuta al menos
una vez, y que cada rama se ejecuta para las
condiciones verdadera y falsa.
●
Conclusión: no es necesario realizar los 16 casos
de prueba.

●
Pruebas de caminos
●
Otra forma de calcular la complejidad
ciclomática es según la cantidad de
condiciones simples y/o compuestas:
– Condición simple: expresión lógica sin
conectores “AND” u “OR”
– Condición compuesta: expresión lógica

con conectores “AND” u “OR”

●
Pruebas de caminos
●
Cálculo de la complejidad ciclomática:
– 1 más que el número de condiciones
(simples)
– Si hay condiciones compuestas, se cuenta el

número de condiciones simples en las
compuestas

●
Pruebas de caminos
●
Ejemplo: programa con 6 sentencias IF, 1 lazo
WHILE y todas expresiones condicionales
simples:
– Complejidad ciclomática = 8
●
Si una de las expresiones condicionales es de
la forma “IF A AND B OR C”, esto cuenta
como 3 expresiones simples (A, B y C):
– Complejidad ciclomática = 10

Unidad 3

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad 3

Cargado por

Copyright:

Formatos disponibles

Unidad 3 – Aseguramiento de la Calidad

IS Unidad 3 - Luis Nieto - 2022 2

IS Unidad 3 - Luis Nieto - 2022 3

IS Unidad 3 - Luis Nieto - 2022 4

IS Unidad 3 - Luis Nieto - 2022 5

IS Unidad 3 - Luis Nieto - 2022 6

IS Unidad 3 - Luis Nieto - 2022 8

IS Unidad 3 - Luis Nieto - 2022 9

Prueba de Prueba de En fase de

IS Unidad 3 - Luis Nieto - 2022 12

IS Unidad 3 - Luis Nieto - 2022 13

IS Unidad 3 - Luis Nieto - 2022 14

IS Unidad 3 - Luis Nieto - 2022 16

IS Unidad 3 - Luis Nieto - 2022 17

IS Unidad 3 - Luis Nieto - 2022 18

IS Unidad 3 - Luis Nieto - 2022 19

IS Unidad 3 - Luis Nieto - 2022 21

IS Unidad 3 - Luis Nieto - 2022 22

IS Unidad 3 - Luis Nieto - 2022 25

IS Unidad 3 - Luis Nieto - 2022 26

IS Unidad 3 - Luis Nieto - 2022 29

IS Unidad 3 - Luis Nieto - 2022 30

IS Unidad 3 - Luis Nieto - 2022 31

IS Unidad 3 - Luis Nieto - 2022 32

IS Unidad 3 - Luis Nieto - 2022 35

IS Unidad 3 - Luis Nieto - 2022 36

IS Unidad 3 - Luis Nieto - 2022 38

IS Unidad 3 - Luis Nieto - 2022 39

IS Unidad 3 - Luis Nieto - 2022 41

IS Unidad 3 - Luis Nieto - 2022 42

IS Unidad 3 - Luis Nieto - 2022 43

IS Unidad 3 - Luis Nieto - 2022 45

IS Unidad 3 - Luis Nieto - 2022 46

IS Unidad 3 - Luis Nieto - 2022 47

IS Unidad 3 - Luis Nieto - 2022 48

IS Unidad 3 - Luis Nieto - 2022 49

IS Unidad 3 - Luis Nieto - 2022 50

IS Unidad 3 - Luis Nieto - 2022 51

IS Unidad 3 - Luis Nieto - 2022 52

IS Unidad 3 - Luis Nieto - 2022 53

IS Unidad 3 - Luis Nieto - 2022 54

IS Unidad 3 - Luis Nieto - 2022 55

IS Unidad 3 - Luis Nieto - 2022 56

IS Unidad 3 - Luis Nieto - 2022 57

IS Unidad 3 - Luis Nieto - 2022 60

IS Unidad 3 - Luis Nieto - 2022 62

IS Unidad 3 - Luis Nieto - 2022 63

IS Unidad 3 - Luis Nieto - 2022 64

IS Unidad 3 - Luis Nieto - 2022 65

IS Unidad 3 - Luis Nieto - 2022 68

IS Unidad 3 - Luis Nieto - 2022 69

IS Unidad 3 - Luis Nieto - 2022 70

IS Unidad 3 - Luis Nieto - 2022 71

IS Unidad 3 - Luis Nieto - 2022 72

IS Unidad 3 - Luis Nieto - 2022 74

IS Unidad 3 - Luis Nieto - 2022 75

IS Unidad 3 - Luis Nieto - 2022 76

IS Unidad 3 - Luis Nieto - 2022 77

IS Unidad 3 - Luis Nieto - 2022 80

IS Unidad 3 - Luis Nieto - 2022 83

Pruebas del Pruebas de

IS Unidad 3 - Luis Nieto - 2022 85