Ingeniería de

software 5
Yadran Eterovic S. (yadran@[Link])
Aseguramiento de la Calidad del
Software
Conjunto de actividades para asegurar que el software cumplirá requisitos funcionales y
estándares de calidad:

• es importante poner atención a la calidad del proceso de desarrollo de software, a cómo se

lleva acabo el proceso

• … y a la calidad de los artefactos producidos durante el desarrollo: que sean correctos,

completos, inteligibles

Estas actividades son actividades del ciclo de vida, llevadas a cabo paralelamente a las
actividades de desarrollo

2
Perjuicios evitables

Los errores en el software pueden costar billones de dólares debido a daños a la

propiedad, pérdida de productividad, daños a las personas, y hasta pérdida de vidas

3
Atributos de calidad
La calidad del software es determinada por un número de factores, o atributos, de calidad:

• un atributo describe o caracteriza un aspecto de interés del software: tamaño, complejidad, …

Un atributo de calidad describe o caracteriza un aspecto relativo a la calidad del software —

típicamente, requisitos no funcionales:

• confiabilidad, robustez, eficiencia, interoperabilidad, mantenibilidad, testability, portabilidad,

reusabilidad, modularidad, cohesión, acoplamiento

• ISO (próx. diap.) e IEEE han desarrollado sus respectivos modelos de calidad

Una especificación cualitativa de un requisito no funcional—[Link]., “el sistema debe ser

confiable” o “el sistema debe ser fácil de mantener”—no es suficiente:

• necesitamos mediciones y métricas de calidad

4
Funcionalidad: Eficiencia:
Adecuación Tiempo
Exactitud Recursos
Interoperabilidad
Mantenibilidad:
Cumplimiento
Estabilidad
Seguridad
Analizabilidad
Confiabilidad: Modelo de calidad ISO 9126 Modificabilidad
Madurez Verificabilidad
Recuperabilidad
Portabilidad:
Tolerancia a fallas
Instalabilidad
Usabilidad: Reemplazabilidad
Aprendizaje Adaptabilidad
Inteligibilidad Cumplimiento
Operabilidad

5
Mediciones y métricas
Una medición de software es una evaluación objetiva y cuantitativa de un atributo del
software:

• [Link]., el tamaño de un módulo

Una métrica de software es una medición estándar (aunque no hay estándares oficiales):

• hay métricas para procesos, para proyectos, y para productos

Un indicador es un valor de medición o de métrica, que se considera que tiene una

implicación importante :

• [Link]., una función es considerada demasiado compleja si contiene diez o más condiciones
binarias atómicas

• son útiles como señales de advertencia y como objetivos de calidad 6

Utilidad de las mediciones y
métricas
Definirlas y recolectar los datos para calcularlas consume tiempo y recursos, y demanda un
esfuerzo considerable … sin embargo

Son evaluaciones cuantitativas del software, incluyendo especificación de requisitos, diseño,

implementación, y documentación, con diversas ventajas:
• definición y uso de indicadores

• asignación de recursos valiosos a áreas críticas

• comparación cuantitativa de proyectos y sistemas similares

• evaluación cuantitativa de mejoras

• evaluación cuantitativa de la tecnología

• evaluación cuantitativa de mejoramiento de procesos 7

Ejemplos de - tasa de requsitos que diversos revisores
interpretan de la misma manera
métricas de - tasa de requisitos correctos validados

calidad - número de módulos que llaman

De requisitos: a un módulo dado
- número de módulos que son
• no ambigüedad, completitud, corrección, consistencia llamados por un módulo dado
- relevancia de las funciones en
De diseño: un mismo módulo según el obje-
tivo del módulo
• fan-in, fan-out, cohesión, acoplamiento, modularidad, complejidad

De implementación y del sistema:

- número de líneas de código fuente
• líneas de código, complejidad ciclomática, confiabilidad, disponibilidad - número de rutas independientes
de control de flujo
Orientadas a objetos:

• complejidad ponderada de los métodos de una clase, profundidad del

- tiempo medio entre
árbol de herencia, acoplamiento entre clases
fallas
8
- tasa de disponibilidad
Técnicas de verificación y
validación
La verificación asegura que el proceso es ejecutado correctamente

La validación asegura que estamos desarrollando el producto correcto:

• validación estática revisa la corrección del producto sin ejecutarlo

[Link]., inspecciones, caminatas, y revisiones por pares

• validación dinámica ejecuta el producto o un prototipo

[Link]., testing (próx. clase)

9
Inspecciones

Se chequea el software contra una lista de errores, anomalías, y no cumplimiento de

estándares y convenciones comunes

Aplicabilidad: Todos los artefactos de software, incluyendo especificación de requisitos,

modelo de dominio, casos de uso, diagramas de diseño, código, diseño de la UI, plan de
pruebas, casos de prueba

Eficacia: Solo para los problemas comunes incluidos en la lista

Participantes: Uno a tres integrantes del equipo técnico

Procedimiento: Similar a revisión por pares

10
Caminatas

Ejecuta el software manualmente usando datos de prueba simples:

• el desarrollador del software guía al equipo en la caminata; el equipo chequea el software

paso a paso a medida que leen en voz alta; la idea es provocar dudas y discusiones

Aplicabilidad: Casos de uso, diagramas de diseño, código, diseño de la UI, casos de prueba

Eficacia: Para entender funcionalidad y comportamiento complejos,

Participantes: Tres a cinco integrantes del equipo técnico, incluyendo el desarrollador

Procedimiento: próx. diap.

11
Procedimiento para caminatas
1. Se presenta una visión global del producto a los participantes

2. El desarrollador lee en voz alta el producto (un documento de requisitos, un módulo de

código, etc.) y lo explica;
… los otros participantes preguntan y levantan dudas;
… el desarrollador responde las preguntas y da justificaciones;
… se identifican y se registran las acciones a seguir;
… y se establece un plazo para que el desarrollador corrija los problemas

3. El desarrollador corrije los problemas, produce una lista resumen, y obtiene la

aprobación de los participantes 12
Revisiones por pares

El producto es revisado por pares, que siguen una lista de preguntas de revisión:
• las preguntas evalúan cualitativamente aspectos del producto
• esta evaluación depende del conocimiento, experiencia, etc. del revisor

Aplicabilidad: Todos los artefactos de software

Eficacia: Detección de problemas que requieren el juicio de perso-nas relativos a

corrección, eficiencia, amigabilidad, y otros atributos de calidad

Participantes: Tres a cinco revisores con la pericia y experiencia necesarias

Procedimiento: próx. diap.

13
Procedimiento para inspecciones
y revisiones por pares
1. Se presenta una visión global del producto a los revisores; cada unidad del producto es
asignada a dos revisores; se planifica una reunión de revisión para dos semanas más
2. Los revisores evalúan el producto contra una checklist y anotan sus respuestas
independientemente
3. En la reunión, los revisores presentan sus comentarios y sugerencias y el desarrollador
contesta preguntas y clarifica dudas; se identifican y se registran las acciones a seguir; y
se establece un plazo para que el desarrollador corrija los problemas
4. El desarrollador corrije los problemas, produce una lista resumen, y obtiene la
aprobación de los revisores (o se planifica una segunda reunión, en cuyo caso se repiten
los pasos anteriores)
14
Verificación y validación
a lo largo del ciclo de vida
En la fase de requisitos:
• detectar errores y anomalías en especificaciones de requisitos, modelo de dominio, casos de uso

En la fase de diseño:
• evaluar la corrección del diseño para cumplir con requisitos y restricciones

En la fase de implementación:
• evaluar corrección del código, interfaces e interacciones, cumplimiento de estándares y méricas
de calidad, uso del lenguaje de programación

15
Funciones de SQA

El objetivo global es asegurar que el proceso de desarrollo de software se lleva a cabo

como es requerido

… y que el sofware satisface los requisitos y estándares de calidad

Abarca una amplia variedad de actividades del ciclo de vida:

• definición de procesos y estándares

• gestión de la calidad

• mejoramiento de procesos

16
Definición de procesos y
estándares

Desarrollar y definir un marco de referencia para asegurar la calidad del software en toda
la organización:

• definición de procesos y metodologías de desarrollo de software y gestión de calidad

• definición de estándares, procedimientos y pautas para llevar a cabo las actividades de SQA

• definición de métricas e indicadores de calidad para mediciones y evaluación

17
Gestión de calidad

Adaptar e implementar el marco de referencia para cada proyecto de software de la

organización:

• Planificación de la calidad: Ocurre al comienzo de cada proyecto; produce un plan de calidad

para cada proyecto específico

• Control de calidad: Ocurre a lo largo de todo el proyecto; monitorea la ejecución del plan de
calidad, y también lo adapta para responder a cambios en la realidad

18
Mejoramiento de procesos

Es necesario mejorar continuamente el proceso (o los procesos), en todos sus aspectos,

para sobrevivir

En particular, los métodos ágiles mejoran de una versión a la siguiente, incluyendo el

descubrimiento de mejores formas de adoptar los propios métodos ágiles

Definición y ejecución de un proceso de mejoramiento de procesos (próxima diapositiva),

que se lleva a cabo continuamente e itera regularmente; [Link]., cada dos años

19
El proceso de mejoramiento de
procesos

1. Definición de métricas y métodos de recolección de datos

2. Recolección de datos para medir el proceso

3. Calcular métricas e indicadores

4. Recomendar acciones de mejoramiento

20
Aplicación de principios prácticos
(¿ágiles?)

Suficientemente bueno es suficiente

Simple y fácil de hacer

El apoyo de la gerencia es esencial

Un enfoque colaborativo y cooperativo entre todos los interesados es esencial

Valoramos más el software que funciona que la documentación completa

21
Pueden aplicarse siguiendo el estilo Requisitos
“cascada”, definiendo planes detallados funcionales:
para cada fase al inicio del proyecto - casos de uso
- relatos de usuario
Product Owner

Six sequential phases (CRISP-DM):

Patrones de
1. Business understanding – What does the business need? diseño:
- Estrategia
2. Data understanding – What data do we have / need? Is it clean?
- Fachada
3. Data preparation – How do we organize the data for modeling? - Adaptador
- Fábrica
4. Modeling – What modeling techniques should we apply? - Decorador
5. Evaluation – Which model best meets the business objectives?
6. Deployment – How do stakeholders access the results? Revisión del Sprint
Retrospectiva del
Sprint

Pueden aplicarse siguiendo el estilo “ágil, iterativo, incremental”, Arquitectura de

moviéndose de ida y vuelta entre las fases, de acuerdo con las necesidades software:
(muchas veces cambiantes) del proyecto, y repitiendo varias veces la - estratificada
secuencia abordando distintas necesidades en cada repetición - cliente-servidor
- publicador-suscriptor
22
Ejemplo [Link]

Un proyecto churn con tres entregables:

• un modelo churn voluntario
• un modelo churn de no pago y desconexión
• un modelo de propensión a aceptar una oferta para retención

En cascada, ejecutas completamente una de las 6 fases de CRISP-DM para los

tres modelos antes de pasar a la siguiente fase para cualquiera de los modelos

En ágil, ejecutas completamente las 6 fases de CRISP-DM para uno de los

modelos (una iteración) antes de iniciar la secuencia de 6 fases para otro
modelo (otra iteración)

… sin embargo, …
23
 Desafíos en data
science y soluciones
ofrecidas por la
ingeniería de software Código mejor estructurado, al aplicar
principios y patrones de diseño

Colaboración entre varios desarrolla-

¿Cómo manejamos cambios al mismo código hechos dores produciendo código, mediante
por diferentes desarrolladores? control de versiones

¿Cómo hacemos testing a nuevas funcionalidades? Código que puede “escalar”, usando
algoritmos y estructuras de datos
¿Cómo facilitamos que el código escrito por noso-
más eficientes y técnicas de caching
tros—código confuso escrito en varios lenguajes de
programación y distribuido entre múltiples archivos Poner modelos en producción
—pueda seguir siendo desarrollado por otros? usando arquitecturas de software y
manejo de excepciones

Testear eficazmente el software

usando test driven development
24
El patrón
Adaptador
Aumenta la compatibilidad entre interfaces
… [Link]., formatos de datos

… por lo tanto, es usado a menudo para leer

datos almacenados en diferentes formatos

… y convertirlos a un objeto de datos

estándar

… [Link]., Pandas tiene unos 20 adaptadores

para leer la mayoría de los tipos de archivos
a su Dataframe [Link]
25
 from [Link] import Dataset
El patrón class SequencesDataset(Dataset):

Fábrica def __init__(self, sequences: Sequences,

neg_sample_size=5):
[Link] = sequences
Desacopla los objetos (el uso de éstos) self.neg_sample_size = neg_sample_size

def __len__(self):
… de cómo son creados return [Link].n_sequences
(crear objetos puede ser complejo y
def __getitem__(self, idx):
ofrecer una fábrica simplifica el trabajo de pairs = [Link].get_pairs(idx)
los programadores y previene errores) neg_samples = []
for center, context in pairs:
Se puede definir mediante una interfaz o
clase abstracta neg_samples.append([Link].get_negative_samples(co
ntext))
… luego, producimos una subclase y la return pairs, neg_samples
equipamos con nuestra propia
implementación [Link]
26
 def log_time(func):

El patrón Decorador
"""Logs the time it took for func to execute"""
def wrapper(*args, **kwargs):
start = time()
val = func(*args, **kwargs)
end = time()
duration = end - start
Queremos hacer algo antes y/o después print(f'{func.__name__} took {duration} seconds to run')
de la ejecución de una función return val
return wrapper

… pero no queremos modificar la función @log_time

propiamente dicha def get_data(db, query):
"""Gets data from a SQL-based database"""
(especialmente si tenemos que modificar data = [Link](query)
return data
muchísimas funciones similarmente)
if __name__ == '__main__':
Básicamente, capturamos un cierto estado # Decorated function will print 'get_data took X seconds to run'
db = SQLDB()
antes de la ejecución de la función, y
query = 'SELECT * FROM foo'
luego capturamos un cierto estado data = get_data(db, query)
después de su ejecución
[Link]
27