Ingeniería del Software

Tema 5: Control y garantía del software

Índice
| Introducción
| Concepto de calidad
| Factores y métricas de calidad
| Revisiones del software
| Revisiones técnicas formales
| El estándar ISO 9001
| Gestión de la configuración del software
| Control de versiones
| Control de cambios
| Auditoría de la configuración

2 José M. García - ESI 04/05 04 de abril de 2005

Introducción

| Algunos programadores creen que la

calidad del software es algo en lo
que empiezan a preocuparse cuando
se ha concluido el programa. FALSO.
| La calidad del software (SQA o GCS)
es una actividad de protección que se
aplica a lo largo del proyecto.

3 José M. García - ESI 04/05 04 de abril de 2005

Introducción (II)
| La GCS engloba:
z Uso de técnicas formales para
especificación, diseño y codificación.
z Hacer revisiones técnicas formales en cada
fase (reuniones de trabajo).
z Aplicar estrategias de prueba.
z Control de documentos y de cambios.
z Procedimiento de ajuste a los estándares.
z Realizar informes sobre revisiones,
auditorías del software, pruebas, ... y
hacerlos públicos

4 José M. García - ESI 04/05 04 de abril de 2005

Concepto de calidad

| La calidad se refiere a la concordancia con

los requisitos funcionales y de rendimiento
establecidos inicialmente.
| Importante también para la calidad es que
haya concordancia con los estándares
especificados y con las características
implícitas de todo producto software.
| Si realizamos un producto con mala calidad
(“se cuelga”, da errores, es difícil de usar,
etc.) los clientes no quedan satisfechos.

5 José M. García - ESI 04/05 04 de abril de 2005

Concepto de calidad (II)

| El control de calidad es un conjunto

de inspecciones, revisiones y pruebas
utilizados a lo largo del proceso de
desarrollo de software para verificar
que se cumplen los requisitos fijados.
| La generación de buenos documentos
de lo que se va realizando es esencial
para facilitar el proceso de control y
para garantizar la calidad.

6 José M. García - ESI 04/05 04 de abril de 2005

Concepto de calidad (III)

| El coste de calidad incluye todos los costes

asociados a la búsqueda y obtención de la
calidad.
| Podemos dividirlos en costes asociados a:
z Prevención
z Evaluación
z Fallos
| Los costes relativos para encontrar y reparar
un defecto aumentan dramáticamente a
medida que se cambia de prevención a
detección y desde el fallo interno al externo.
7 José M. García - ESI 04/05 04 de abril de 2005
Concepto de calidad (IV)

| Entre los costes de prevención se

incluyen:
z planificación de la calidad,
z revisiones técnicas formales,
z equipo de pruebas,
z formación del equipo.

8 José M. García - ESI 04/05 04 de abril de 2005

Concepto de calidad (V)

| Entre los costes de evaluación se

incluyen:
z inspección del proceso y entre
procesos,
z mantenimiento del equipo,
z pruebas.

9 José M. García - ESI 04/05 04 de abril de 2005

Concepto de calidad (VI)

| Los costes de fallos son los costes que

desaparecerían si no surgieran defectos
antes del envío de un producto a los
clientes.
| Dos tipos:
z Internos: cuando se detecta antes del envío.
Revisión, análisis y reparación.
z Externos: detectados después del envío del
producto. Resolución de quejas, sustitución
del producto, soporte de ayuda, etc.

10 José M. García - ESI 04/05 04 de abril de 2005

Concepto de calidad (VII)
| Ejemplo: IBM dedicó 7.053 horas
inspeccionando 200.000 líneas de código
encontrando 3.112 errores graves. A 40$ por
hora = 282.120$ (91$ por error).
| Supongamos que no se hace inspección
porque los programadores han sido
cuidadosos y sólo hay un error cada 1.000
líneas (menor que la media) en el producto
enviado. Por tanto, quedan 200 errores sin
corregir después de la entrega, a un coste de
25.000$ por reparación el coste será de 5
millones de $, 18 veces más que en
detección
11 José M. García - ESI 04/05 04 de abril de 2005
Concepto de calidad (VIII)
| Coste de corregir un error

1000

100

10

1
Diseño Código Prueba de Prueba de En fase de
desarrollo sistema explotación

12 José M. García - ESI 04/05 04 de abril de 2005

Factores y métricas de
calidad
| Corrección. Grado en que un programa satisface los
requisitos.
| Fiabilidad. Grado en que se espera que un programa
lleve a cabo sus funciones esperadas.
| Eficiencia. Cantidad de recursos empleados para
llevar a cabo su misión.
| Integridad. Grado en que puede controlarse el acceso
al software o a los datos por personal no autorizado.
| Facilidad de uso. Esfuerzo requerido para usar el
software desarrollado.
| Facilidad de mantenimiento. Esfuerzo requerido
para localizar y reparar un error en el software.

13 José M. García - ESI 04/05 04 de abril de 2005

Factores y métricas de
calidad (II)
| Flexibilidad. Esfuerzo requerido para modificar
un programa operativo.
| Facilidad de prueba. Esfuerzo requerido para
probar que un programa realiza la función
requerida.
| Portabilidad. Esfuerzo requerido para cambiar el
programa desde un hardware y/o software a otro.
| Reusabilidad. Grado en que un programa (o
partes del mismo) puede emplearse para otros
programas.
| Facilidad de interoperación. Esfuerzo requerido
para acoplar un sistema a otro.
14 José M. García - ESI 04/05 04 de abril de 2005
Revisiones del software
| “Filtro” para el proceso de ingeniería del
software.
| Se aplican en varios momentos durante el
desarrollo del software y sirven para
detectar errores y defectos que puedan así
ser eliminados.
| Ventaja: “Purifican” las actividades de
ingeniería del software.
| Inconveniente: Retardan el “flujo” de las
actividades del desarrollo.
| No todas son efectivas.

15 José M. García - ESI 04/05 04 de abril de 2005

Revisión Técnica Formal

| Revisión técnica formal (RTF). Es el

filtro más efectivo desde el punto de
vista de garantizar la calidad.
| Se puede definir como una actividad
llevada a cabo por los ingenieros del
software que busca y repara errores
en la actividad actual antes de pasar
a la siguiente actividad dentro de
nuestra planificación.

16 José M. García - ESI 04/05 04 de abril de 2005

Revisión Técnica Formal (II)

| Los objetivos de una RTF son:

z Descubrir errores en la función, la lógica o la
implementación de cualquier software.
z Verificar que el software alcanza sus
requisitos.
z Garantizar que el software cumple los
estándares.
z Conseguir uniformidad en el desarrollo.
z Hacer proyectos manejables (la complejidad
crece exponencialmente con el tamaño).

17 José M. García - ESI 04/05 04 de abril de 2005

Revisión Técnica Formal (III)

| En una reunión hay varias restricciones:

z No debe haber más de cinco personas.
z Debe prepararse por adelantado.
z No debe durar más de dos horas.
| Una RTF se hace de una pequeña parte
específica, no se revisa todo, sino partes
pequeñas (modularidad).
| La RTF la dirige el jefe de revisiones, que no
es el mismo que el jefe del proyecto.
| Un registrador apunta todo lo que se analiza
en la RTF.
18 José M. García - ESI 04/05 04 de abril de 2005
Estándar ISO 9001

| Estándar: (DRAE). Que sirve como tipo,

modelo, norma, patrón o referencia.
| ISO: International Organization for
Standardization.
| Adoptado por 130 países.
| Si un producto no tiene la etiqueta ISO 9001
los usuarios dudan de su calidad.
| Obtener la certificación ISO 9001 depende de
todos los integrantes de la empresa, aparte
de ser sinónimo de buenos productos.

19 José M. García - ESI 04/05 04 de abril de 2005

Gestión de la configuración

| Cuando se construye software, los

cambios son inevitables. Además, los
cambios aumentan el grado de
confusión entre los ingenieros del
proyecto.
| La gestión de la configuración del
software (GCS) es una actividad de
autoprotección que se aplica durante
el proceso de desarrollo de software.

20 José M. García - ESI 04/05 04 de abril de 2005

Gestión de configuración (II)

| Es un proceso de garantía de calidad

del software.
| Las actividades de GCS sirven para:
z Identificar el cambio.
z Controlar el cambio.
z Garantizar su adecuada
implementación.
z Informar del cambio a todos aquellos
que puedan estar interesados.
21 José M. García - ESI 04/05 04 de abril de 2005
Gestión de configuración (III)

| Hay que distinguir mantenimiento y GCS.

| El mantenimiento es un conjunto de
actividades de IS que se producen después
de que el software se haya entregado al
cliente y esté en funcionamiento.
| La GCS es un conjunto de actividades de
seguimiento y control que comienzan
cuando se inicia el proyecto y termina sólo
cuando el software queda fuera de
circulación.

22 José M. García - ESI 04/05 04 de abril de 2005

Gestión de configuración (IV)
| Necesidad de cambios:
z Modificación de requisitos.
z Cambio de prioridades.
z Cambio de estructura del equipo.
z Restricciones en presupuesto o planificación.
z Errores.
| Consecuencias de los cambios:
z Nuevos productos o versiones de antiguos.
| Problemas:
z Crecimiento del número de componentes
z Cambios constantes.

23 José M. García - ESI 04/05 04 de abril de 2005

Elementos de GCS

| Los ECS (información creada como parte

del proceso de IS) se dividen en:
z Material no ejecutable:
• Documentos de especificación
• Documentos de diseño
• Listados de software o datos
• Manuales de usuario
z Material ejecutable:
• Código ejecutable
• Resultados de pruebas
• Sistemas operativos, compiladores, ...

24 José M. García - ESI 04/05 04 de abril de 2005

Línea base
| Una línea base es un punto de referencia en el
desarrollo del software que queda marcado por el
envío de uno o más elementos de configuración del
software y la aprobación del ECS obtenido
mediante una RTF.

ECS Error CAMBIO ECS V2

25 José M. García - ESI 04/05 04 de abril de 2005

Control de versiones

| El control de versiones es una

combinación de procedimientos y
herramientas para gestionar versiones de
los objetos de configuración creados
durante el proceso del software.
| Cada ECS tiene un conjunto de atributos
que lo definen, bien sea un número de
versión o una cadena de variables

26 José M. García - ESI 04/05 04 de abril de 2005

Control de versiones (II)

| Los atributos de la versión N serán los

mismos que los de la N+1, sólo habremos
de cambiar los atributos de fecha de
edición, número de versión, etc.

Nº VERSIÓN N Cambio VERSIÓN N+1

TIPO
AUTOR FECHA

CAUSA EFECTO

27 José M. García - ESI 04/05 04 de abril de 2005

Control de versiones (III)
| En el caso de optar por la variante
numérica disponemos para ello de los
grafos de evolución.
| Cada nodo es un objeto compuesto, es
decir, es una versión completa del software
(conjunto de ECS’s) y cada versión puede
contener diferentes variantes.
| Cuando se realizan cambios muy
significativos se cambia el primer número, si
son menos relevantes el segundo, y así
dependiendo del número de dígitos
considerado.
28 José M. García - ESI 04/05 04 de abril de 2005
Control de versiones (III)

1.3 1.4

1.0 1.1 1.2

2.0 2.1

1.1.1 1.1.2

29 José M. García - ESI 04/05 04 de abril de 2005

Control de cambios

| El control de cambios es un
conjunto de procedimientos humanos
y herramientas automáticas para
gestionar los cambios.
| Con estos procedimientos se
pretende que cualquier cambio que se
lleve a cabo en el proceso de
software repercuta lo menos posible
en el resto del proceso.

30 José M. García - ESI 04/05 04 de abril de 2005

Control de cambios (II)

| Cuando se trabaja en un proyecto y es

necesario un cambio que no estaba
planificado, se realiza una petición de
cambio y se procede a evaluar el esfuerzo
necesario, el impacto sobre otras funciones
y ECS y los posibles efectos secundarios,
generándose un informe.
| Los resultados se presentan a un equipo
(autoridad de cambio) que decide si se
acepta o se deniega en función de la
prioridad.
31 José M. García - ESI 04/05 04 de abril de 2005
Control de cambios (III)

| Si no se acepta se informa al
demandante y finaliza el cambio.
| Si se acepta, se da de baja el ECS
que se va a cambiar y se da de alta el
nuevo, respetándose siempre las
reglas de SQA (documentación,...).
| Evidentemente, tendremos que
asignar un nuevo número de versión.
32 José M. García - ESI 04/05 04 de abril de 2005
Auditoría de la configuración

| Hasta ahora no hemos descrito

ningún método que nos permita
evaluar si el cambio que realizamos
está correctamente implementado.
| La auditoría de la configuración
junto con las RTF tratan de verificar
en conjunto que el cambio se hace
correctamente.

33 José M. García - ESI 04/05 04 de abril de 2005

Auditoría de la configur. (II)

| Las RTF se centran en la corrección

técnica del elemento modificado.
| Una auditoría de configuración del
software completa la revisión técnica
formal al comprobar características
que generalmente no tiene en cuenta
la revisión.

34 José M. García - ESI 04/05 04 de abril de 2005

Auditoría de la configur. (III)

| Las tareas que se llevan a cabo son:

z Examinar cada ECS para detectar consistencia
con otros.
z Detectar omisiones, redundancias, colisiones,
efectos secundarios no deseados, ...
z Ver si se ha registrado y divulgado cada cambio.
z Comprobar si se han seguido los estándares.
z Garantizar la calidad y hacer un informe de ello.
| Si la auditoría es informal se incluye en la
RTF (ahorro de tiempo), pero si es formal se
hace independientemente.

35 José M. García - ESI 04/05 04 de abril de 2005