tema 7 la calidad del software

1
tema 7 la calidad del software
enrique barreiro departamento de
informática universidade de vigo escuela
superior de ingeniería informática ingeniería del
software de gestión
2
introducción
Somos lo que hacemos de forma repetitiva. La
excelencia, entonces, no es un acto, sino un
hábito. Aristóteles

• calidad del software concepto complejo
• el producto desarrollado cumple su
  especificación criterio insuficiente
• la especificación se centra en las
  características deseadas por el usuario, y se
  suelen olvidar otras importantes (por ejemplo,
  mantenimiento)
• difícil especificar detalladamente y de forma
  medible ciertas características de calidad
  (facilidad de uso, mantenimiento,...)
• cuando la especificación del software es
  incompleta, el usuario percibe falta de calidad
• diferentes atributos de la calidad
  (mantenibilidad, eficiencia, portabilidad,
  rendimiento, fiabilidad,...)
• administradores administración de la calidad
• responsabilidad de asegurar el nivel de calidad
  requerido en los productos
• definición de procedimientos y estándares y
  asegurar su cumplimiento
• implantar una cultura de la calidad motivación
  de cada persona responsable del desarrollo para
  lograr un alto nivel de calidad del producto

3
administración de la calidad

• tres actividades principales
• aseguramiento de la calidad
• establecimiento de un marco de trabajo de
  procedimientos y estándares corporativos que
  conduzcan a la obtención de software de alta
  calidad
• planificación de la calidad
• selección de procedimientos y estándares
  adecuados a partir de ese marco de trabajo y
  adaptación de éstos para un proyecto de software
  específico
• control de la calidad
• definición y aplicación de los procesos que
  aseguren que los procedimientos y estándares son
  seguidos por el equipo de desarrollo

4
administración de la calidad

• administración de la calidad
• comprobación independiente de los procesos de
  desarrollo
• los productos resultantes de los procesos se
  introducen en el proceso de administración de la
  calidad para asegurar su consistencia con
  estándares y objetivos de calidad
• equipo de aseguramiento y control independientes
  de los equipos de desarrollo
• responsabilidad de la administración de la
  calidad
• visión objetiva del proceso
• informan de problemas y dificultades a los
  administradores principales de la organización

Proceso de desarrollode software
D1
D2
D3
D4
D5
Proceso de administraciónde la calidad
Estándares yprocedimientos
Plan decalidad
Informes de revisión de la calidad
5
aseguramiento de la calidad y estándares

• actividades de aseguramiento de la calidad (SQA)
• definir un marco de trabajo para lograr la
  calidad del software definir o seleccionar
  estándares aplicables al proceso de desarrollo o
  a los productos de software
• importancia de los estándares
• ofrecen un conjunto de las mejores prácticas,
  evitando repetir errores anteriores y capturando
  el conocimiento de valor para la organización
• ofrecen un marco de trabajo alrededor del que se
  implementa el proceso de SQA
• ayudan a la continuidad del trabajo de unos
  ingenieros a otros
• desarrollo de estándares
• proceso largo y complicado
• organizaciones nacionales e internacionales
  diferentes (ANSI, IEEE, OTAN, Agencia Espacial,
  NASA, Departamento de Defensa de EE.UU., ...)
• los equipos de SQA de las empresas desarrollan un
  manual de estándares basado en estándares
  nacionales e internacionales

6
SQA estándares

• dos tipos de estándares
• estándares del producto se aplican al producto a
  desarrollar
• estándares de documentos (p.ej., estructura del
  documento de requerimientos a producir)
• estándares de documentación (encabezados estándar
  de comentarios para una definición de clase)
• estándares de codificación (cómo utilizar un
  lenguaje de programación)
• estándares del proceso definen los procesos a
  seguir durante el desarrollo
• definiciones de los procesos de especificación y
  análisis, diseño, validación, descripción de los
  documentos a generar en cada uno de estos
  procesos,...

7
SQA estándares

• es necesario evitar la percepción de los
  estándares como elementos burocráticos e
  irrelevantes
• involucración de los ingenieros de software en el
  desarrollo de los estándares del producto
  inclusión del por qué de las decisiones en el
  documento de estándares
• comprensión de los motivos de los estándares
• compromiso con su desarrollo y utilización
• revisión y modificaciones regulares para reflejar
  cambios en las tecnologías y las circunstancias
• utilización de herramientas para simplificar la
  aplicación de los estándares
• evitar la aplicación rigurosa y fundamentalista
  de los estándares del proceso
• el administrador puede cambiar los estándares del
  proceso según las circunstancias del proyecto
• colaboración entre administrador de proyecto y
  administrador de SQA para definir la forma de
  aplicar los estándares en cada proyecto

8
SQA estándares de documentación

• importancia de los documentos estandarizados
• documentos única forma tangible de representar
  el software y el proceso del software
• documentos estandarizados apariencia, estructura
  y calidad consistentes más fáciles de leer y
  comprender
• tres tipos de estándares
• estándares del proceso de documentación
• proceso a seguir para la producción del documento
• documentos de trabajo no es necesario aplicar
  procesos formales de calidad
• documentos formales (para desarrollos posteriores
  o a entregar al cliente) necesario adoptar un
  proceso formal de calidad
• estándares del documento
• estructura y presentación de los documentos
• deben tener un estilo y apariencia consistente, y
  los del mismo tipo deben tener una estructura
  consistente con los del proyecto y la
  organización
• estándares para el intercambio de documentos
• aseguran que todas las copias electrónicas de los
  documentos sean compatibles
• utilización de herramientas concretas para
  elaborar los documentos (hojas de cálculo,
  procesadores de texto, herramientas de
  diagramación,...)

9
SQA estándares de documentación
Proceso formal de producción de un documento
Crear borrador inicial
Rehacer documento borrador
Incorporar comentarios a la revisión
Revisar borrador
Etapa 1 creación
Documento aprobado
Comprobar borrador final
Producir borrador final
Corregir texto
Etapa 2 refinamiento
Documento aprobado
Producir patrones de impresión
Revisar arreglos
Arreglar texto
Imprimir copias
Etapa 3 producción
fuente I. Sommerville, Ingeniería de Software,
Pearson 2002
10
SQA estándares de documentación

• ejemplos
• estándares de identificación de documentos cada
  documento debe identificarse de forma única
• documentos formales identificador formal
  definido por el administrador de la configuración
• documentos informales identificador definido por
  el administrador del proyecto
• estándares de la estructura del documento
  secciones, numeración de páginas, encabezados,
  información de pies de página, numeración de
  secciones,...
• estándares de presentación de documentos tipos
  de letra y estilos, logotipos y nombres de la
  compañía, utilización del color,...
• estándares para actualizar los documentos
  utilización de una forma consistente para indicar
  los cambios en el documento (colores en la
  portada para indicar nuevas versiones,
  utilización de los márgenes para indicar párrafos
  modificados o agregados,...)

11

• Ejemplo estructura de documento de la ESA
• Documento de Requerimientos de Usuario
• Introduction
• Objetivo del documento
• Ámbito del software
• Definiciones, acrónimos y abreviaciones
• Referencias
• Resumen del documento
• Descripción general
• Perspectiva del producto
• Capacidades generales
• Restricciones generales
• Características de usuario
• Entorno operativo
• Supuestos y dependencias
• Requerimientos específicos
• Requerimientos de capacidad
• Requerimientos de restricciones

12

• Ejemplo plantilla de formulario de la ESA

• SOFTWARE CHANGE REQUEST SCR NO
• DATE
• ORIGINATOR
• RELATED SPRs
• SOFTWARE ITEM TITLE
• SOFTWARE ITEM VERSION/RELEASE NUMBER
• PRIORITY CRITICAL / URGENT / ROUTINE (underline
  choice)
• CHANGES REQUIRED
• RESPONSIBLE STAFF

13

• Ejemplo plantilla de formulario de la ESA

14
SQA calidad del proceso y del producto

• mejora de la calidad
• identificar productos de calidad
• examinar el proceso utilizado para desarrollarlos
• generalizar esos procesos para aplicarlos a otros
  proyectos
• fabricación relación clara entre calidad de
  proceso y del producto
• proceso fácil de estandarizar y supervisar
• una vez definido el proceso de fabricación se
  ejecuta una y otra vez para producir el mismo
  producto con el mismo nivel de calidad
• software existe relación, pero menos directa
• proceso más creativo que mecánico influencia de
  habilidades individuales y experiencia
• factores externos (novedad de la aplicación,
  presión comercial,...)
• el proceso puede ser inapropiado para un tipo de
  software
• por ejemplo, un estándar puede indicar que la
  especificación tiene que estar terminada y
  aprobada para implementar, pero puede hacer falta
  realizar prototipos.

15
control de la calidad

• control de calidad
• vigilar el proceso de desarrollo para asegurar
  que se siguen los procedimientos de SQA y
  estándares de calidad ajustándose al plan de
  calidad
• dos enfoques complementarios
• revisiones técnicas el software, documentación y
  procesos son revisados por un grupo de personas
• valoración normalmente automática, con algún
  tipo de herramienta
• el software y los documentos se procesan y se
  comparan con los estándares que se aplican a ese
  proyecto
• implica una medida cuantitativa de de algunos
  atributos del software (medición y métricas)

16
control de calidad revisiones técnicas formales
Se revisa UN producto (especificación, módulo,
listado,...)
Poca gente, preparación y duración breves
Decisión final - Aceptación - Rechazo -
Aceptación condicionada a pequeñas modificaciones
Participantes jefe de revisión, revisores
(ingenieros,programadores,...) y productor
17
revisiones técnicas formales

• objetivos
• descubrir errores en la función, lógica o
  implementación de cualquier representación del
  softwre.
• verificar el cumplimiento de los requisitos
• garantizar el cumplimiento de los estándares.
• conseguir un desarrollo uniforme del software
• obtener proyectos que hagan más sencillo los
  trabajos técnicos (análisis que permitan buenos
  diseños, diseños que permitan implementaciones
  sencillas, estrategias de pruebas que faciliten
  éstas,...)
• RTFs son un filtro que permite purificar las
  actividades de ingeniería de software.
• se aplican en diversos momentos del desarrollo
  para detectar defectos.
• diseño entre el 50 y el 60 de los errores del
  desarrollo.
• aprovecha la diversidad de un grupo de personas
  para
• señalar la necesidad de mejoras en el producto de
  ingeniería (diagramas del análisis, diccionario
  de datos, diseño, código, estrategia de
  pruebas,...)
• confirmar las partes en las que no es necesaria
  una mejora.
• conseguir un trabajo técnico de calidad más
  uniforme.
• efectividad se calcula que son efectivas en un
  75.

18
revisiones técnicas formales

• ejemplo

19
revisiones técnicas formales
Diseño preliminar
Diseño detallado
Codificación/prueba de unidad
6
SIN REVISIONES
10
37
94
4
Prueba integración
Prueba de validación
Prueba sistema
94
24
47
12
Diseño preliminar
Diseño detallado
Codificación/prueba de unidad
2
5
24
CON REVISIONES
3
15
10
1
Prueba integración
Prueba de validación
Prueba sistema
24
12
6
3
20
revisiones técnicas formales
DOCUMENTOS GENERADOS
LISTA DE SUCESOS DE REVISIÓN
INFORME SUMARIO DE REVISIÓN

• Directrices de la revisión
• Revisión del producto, no del productor
• Fijar una agenda y mantenerla
• Limitación del debate e impugnaciones
• No se resuelve el problema, sólo se identifica
• Limitar el número de participantes
• Desarrollar una lista de comprobaciones
• Destinar recursos y agenda para las RTF en la
  planificación
• Entrenamiento de los revisores
• Repaso de revisiones anteriores

• Comprobaciones en la revisión
• Análisis seguimiento de requisitos del sistema,
  consistencia y corrección de la representación.
• Diseño revisión de la arquitectura e inspección
  del diseño procedimental
• Codificación traducción correcta del diseño al
  código, errores mecanográficos, estándares de
  codificación, comentarios,...
• Prueba validación del plan o procedimiento de
  prueba que se haya establecido
• Mantenimiento consideración de las consecuencias
  del cambio, documentación del mismo, aceptación
  final del cambio

21
RTF ejemplo de informe sumario

• Identificación de la revisión
• Proyecto Controlador del CM en tiempo
  real Número revisión D-004
• Fecha 11/07/95 Lugar Edif. 4, Desp. 3 Hora
  1000AM
• Identificación del producto
• Material revisado Diseño detallado. Módulos de
  control de movimiento
• Productor Juan Pérez
• Breve descripción tres módulos para el control
  de movimiento en los ejes x, y,z
• Material revisado
• Descripciones del diseño procedimental módulos
  MOVIMX, MOVIMY, MOVIMZ
• Codificación de los módulos
• Equipo de revisión
• Nombre Firma
• M. Pérez Pérez _______________

22
RTF ejemplo de lista de sucesos

• Número revisión D-004
• Fecha 11/07/95
• Jefe de revisión M. Pérez Pérez
• Lista de sucesos
• Los prólogos de los módulos MOVIMX, MOVIMZ no son
  consistentes con los estándares de diseño. Se
  debe establecer explícitamente el propósito del
  módulo y se debe especificar la declaración de
  los elementos de datos.
• El contador de bucle para la interpolación de los
  ejes X, Y, Z se incrementa una vez más de lo
  necesario para el control de paso del motor. El
  equipo de revisión recomienda otra comprobación
  de las especificaciones de paso del motor y la
  corrección (como sea preciso) del contador de
  bucle.
• Error de tipo en la referencia a la posición
  actual en X, X.POSICIÓN, en los módulos MOVIMX y
  MOVIMZ.
• Se debe ampliar una sentencia de seudocódigo. La
  sentencia converger a posición de control
  adecuada como en MOVIMX contenida en los módulos
  MOVIMY y MOVIMZ debe ser ampliada para los
  controles específicos de movimiento en Y y Z.
• El equipo de revisión recomienda una modificación
  del algoritmo de comparación de posición para
  mejorar el rendimiento en tiempo de ejecución. El
  diseñador tiene sus reservas sobre las
  modificaciones y analizará el posible impacto
  antes de implementar los cambios.

23
control de calidad métricas

• medición calcular un valor numérico para algún
  atributo de un producto o un proceso del software
• la comparación entre ellos y con los estándares
  de la organización permite controlar la calidad
• métrica cualquier tipo de medida relacionada con
  un sistema, proceso o documentación
• existen atributos imposibles de medir de forma
  directa
• por ejemplo mantenibilidad, complejidad,
  comprensión,...
• afectados por diversos factores
• no existen métricas directas necesario medir
  atributos internos del software y suponer que
  existe relación con los atributos que nos
  interesan

Número de parámetros del procedimiento
Proceso de software
Producto de software
Mantenibilidad
Complejidad ciclomática
Fiabilidad
Métricas de predicción
Métricas de control
Tamaño del programa en líneas de código
Portabilidad
Número de mensajes de error
Usabilidad
Decisiones administrativas
Extensión del manual de usuario
24
modelos de calidad del software

• Objetivo mejora de procesos software.
• Diversos modelos que buscan
• Determinar las fuerzas y debilidades en una
  organización
• Aglutinar esfuerzos para conseguir acuerdos sobre
  lo que es un buen proceso.
• Principales iniciativas
• ISO 9001 y 9000-3
• muy útil en compañías que además de software
  fabrican equipos
• define los procesos de calidad tanto en compañías
  de hardware como de software.
• muy utilizado en Europa.
• Capability Maturity Model (CMM) del Instituto de
  Ingeniería del Software
• el modelo más empleado y maduro
• valora el desarrollo de software en sistemas de
  gran complejidad
• visión completa del proceso de madurez
  organizacional
• incluye mecanismos para mejora continua de los
  procesos
• Bootstrap
• enfocado a pequeñas y medianas empresas
• valora la madurez global de una organización
• examina procesos individuales de software y
  valora la conveniencia y el impacto de nuevas
  tecnologías
• SPICE

25
modelos de calidad ISO 9000

• ISO 9000 estándar internacional que se utiliza
  en el desarrollo de sistemas de administración de
  calidad en todas las industrias
• conjunto de estándares que se aplican a una gran
  variedad de organizaciones (fabricación,
  servicios,...)
• ISO 9001 el estándar más general, aplicable a
  las organizaciones interesadas en el proceso de
  calidad del diseño, desarrollo y mantenimiento de
  productos
• ISO 9000-3 documento de ayuda que interpreta a
  ISO9000 para el desarrollo de software
• modelo genérico de un proceso de calidad
• describe varios aspectos de ese proceso y define
  qué estándares y procedimientos deben existir
  dentro de una organización
• organizaciones nacionales que certifican que los
  procesos de calidad de una empresa se ajustan a
  ISO9001

26
modelos de calidad ISO 9000
Modelos de calidad ISO 9000
instanciado como
Proceso de la calidad de la organización
documentos
Manual de calidad de la organización
se utiliza para desarrollar
instanciado como
Administración de la calidad del proyecto
Plan de calidad del proyecto 1
Plan de calidad del proyecto 3
Plan de calidad del proyecto 2
27
modelos de calidad ISO-9000

• Serie ISO-9000 conjunto de normas de sistemas de
  calidad y guías asociadas que se publicaron a
  partir de 1987 por la ISO (Organización
  Internacional de Normalización).
• ISO9000 describe los elementos de garantía de
  calidad en términos genéricos que pueden
  aplicarse a cualquier negocio, con independencia
  de los productos o servicios ofrecidos.
• Obtención de certificado
• Auditores externos examinan el sistema de calidad
  y las operaciones de una compañía.
• Si es correcto, se recibe el certificado.
• Auditorías de seguimiento cada seis meses.
• Procesos documentados y practicados como se hayan
  descrito en el estándar.
• Ventajas comprensión, control y mejora de los
  procesos y la red de procesos.
• Inconveniente burocracia y papeleo.
• ISO9000 describe los elementos de un sistema de
  garantía de calidad
• estructura organizativa
• procedimientos
• procesos y recursos para implantar la
  planificación de la calidad
• control de calidad
• garantía de calidad
• mejora de la calidad
• ISO 9000 NO describe cómo debe implementar una
  organización estos elementos del sistema de
  calidad.
• Objetivo diseñar e implementar un sistema de
  garantía de calidad que cumpla los estándares y
  acople los productos, servicios y cultura de la
  empresa.

• ISO 9001
• Estándar aplicable a la Ingeniería del Software
• 20 requisitos de un sistema de garantía de
  calidad efectiva
• Responsabilidad de la gestión
• Sistema de calidad
• Revisión de contrato
• Control de diseño
• Control de datos y documentos
• Compras
• Control del producto suministrado por el cliente
• Identificación y posibilidad de seguimiento del
  producto
• Control del proceso
• Inspección y prueba
• Control de inspección, medición y equipo de
  pruebas
• Inspección y estado de prueba
• Control de producto no aceptado
• Acción correctora y preventiva
• Tratamiento, almacenaje, empaquetamiento,
• preservación y entrega.

ISO 9000-3 Guía para la aplicación de ISO 9001
en el desarrollo, suministro y mantenimiento de
software
28
relación entre modelos de calidad del software
29
modelos de calidad capability maturity model
(CMM)

• Software Engineering Institute (Carnegie Mellon
  University), 1986 modelo para evaluar el grado
  de madurez con que las organizaciones
  desarrollaban software.
• 1991 aparece el CMM, prácticamente en su forma
  actual
• basado en casos reales
• refleja las necesidades de los profesionales del
  desarrolol de software y de la mejora del
  proceso.
• está documentado
• su documentación está disponible
  (http//www.sei.cmu.edu/)
• punto de partida definición del proceso de
  software conjunto de actividades, métodos,
  prácticas y transformaciones que se usan para
  desarrollar el software y los productos a él
  asociados.
• madurez del proceso
• refleja la capacidad de una organización para
  producir software de calidad (cuanto más madura
  es una organización, mejor definido será el
  proceso de software).
• proceso del software maduro mayor productividad
  y mayor calidad del producto.
• las empresas van pasando por cinco niveles de
  madurez

30
modelos de calidad capability maturity model
(CMM)
Proceso poco estructurado, puede que caótico. El
éxito depende más del esfuerzo individual que de
una aproximación organizada del proceso software.
Existen conjuntos de métricas definidas a nivel
de las diferentes etapas del proceso, y se
dispone de datos al respecto. Los procesos y los
productos son controlados y seguidos de modo
cuantitativo.
La mejora del proceso software es continua y
existe una realimentación de los procesos, así
como un enfoque de mejora a nivel de ideas y de
tecnologías.
Procesos software bien definidos, estandarizados
e integrados, tanto en aspectos de gestión como
de ingeniería, a nivel de toda la organización.
Utilización de un proceso software estandarizado
para desarrollo y mantenimiento.
Procesos básicos de gestión referidos a un
seguimiento de funcionalidades, costes y plazos.
Se implanta una disciplina de trabajo para
repetir modos de trabajo que han dado resultados
positivos
31
bibliografía
Sommerville, I. Ingeniería de Software, cap.
24 Pressman, R.S. Ingeniería del Software. Un
enfoque práctico, cap. 8