Presentación de Jordi Martí y Lleonard del Río, Tecdencies, en EUG, dentro del ciclo

1. Ciclo conferencias “Gestión de Proyectos” (Abril-Junio 2012)
Ejemplos prácticos de calidad en el
software
2 de Mayo de 2012
jordi.marti@tecdencies.com
lleonard.delrio@tecdencies.com

2. En què consistirà la presentació?
 Tecdencies, Enginyeria de Software
 La qualitat en el software:
 No és fer proves en un moment donat del projecte, s’ha
d’aplicar en tot l’àmbit del Projecte …
 … però en aquesta sessió ens centrarem en la qualitat
del codi a desenvolupar: Des del dia 1 que es comença a
programar, fins que entreguem el producte.
2

3. En 10 segundos…
Integración
Proporcionar soluciones Tecdencies
basadas en componentes
y sistemas existentes e Servicios de ingeniería y
integrarlos con los sistemas desarrollo de soluciones
actuales de los clientes. software basados en personas,
Integración procesos y tecnología.
Proven Innovation
Innovar de forma segura Cómo
mediante tecnologías Expertos trabajando de forma directa
probadas. con Departamentos de SI, o ayudando
a las Consultoras TI a alcanzar la
excelencia en la prestación de sus
servicios.

4. Analysis / Design / Construction / Test / Deploy / Maintain
¿Estás seguro?
•¿Estamos capturando bien los requisitos?
•¿Estamos traduciéndolos bien en software?
•¿A qué nos compromete esta arquitectura? ¿No deberíamos estar usando SOA?
•¿Son estos patrones de diseño los correctos?
•¿Utilizamos las herramientas correctas?
•¿Las utilizamos correctamente?
•¿Qué proceso de pruebas utilizamos?
•¿Lo revisamos periódicamente?
•¿Inspeccionamos el código que generamos?
•¿Utilizamos estándares de codificación?
•…

5. Ingeniería del software
 Definición según el IEEE:
1. La aplicación de un enfoque sistemático, disciplinado y
cuantificable al desarrollo, operación y mantenimiento
del software; es decir, la aplicación de la ingeniería al
software
 Cualquier enfoque de ingeniería debe estar
sustentado en un compromiso con la calidad
Herramientas
Métodos
Proceso
Enfoque de calidad

6. SWEBOK
 El SoftWare Engineering Body Of Knowledge es un
proyecto de colaboración entre la IEEE Computer Society y
la Université du Québec à Montreal, con el fin de definir el
cuerpo de conocimientos de la ingeniería de software
 Sus objetivos:
 Caracterizar los conocimientos de ingeniería del software
 Aportar un acceso por temas al conocimiento de ingeniería del
software.
 Promover una visión consistente de la ingeniería del software en
todo el mundo.
 Clarificar el lugar y el entorno de la ingeniería del software con
respecto a otros disciplinas (computer science, gestión de
proyectos, computer engineering, matemáticas).
 Aportar una base para el desarrollo de un currículo material para
poder certificar y conceder licencia a profesionales.

7. Áreas de conocimiento (1/2)

8. Áreas de conocimiento (2/2)

9. KA: Prueba del software

10. KA: Calidad del software

11. Definición de calidad
Concordancia con
1. los requisitos funcionales y de
desempeño explícitamente
establecidos,
2. estándares de desarrollo
explícitamente documentados, y
3. características implícitas que se
esperan de cualquier software
desarrollado profesionalmente

12. CASO PRÁCTICO 1:
CARACTERÍSTICAS IMPLÍCITAS
1

13. Coste de la calidad
 Costes que genera la búsqueda de calidad o que
demanda el desarrollo de las actividades relacionadas
con la calidad
 Tipologías
 Costes de prevención: planificación de la calidad, revisiones
técnicas formales, equipo de pruebas y entrenamiento
 Costes de evaluación: inspección en el proceso, calibración y
mantenimiento de equipo y pruebas
 Costes de fallas: son los que no existen si no aparecen
defectos antes de enviar un producto a los clientes
 Costes de fallas internas: detectados en el producto antes del envío
 Costes de fallas externas: detectados después del envío

14. Mecanismos para encontrar defectos
 Posibilidades
 Herramientas Compilador, revisores de código, etc.
 Pruebas Pruebas unitarias, de integración, etc.
 Usuarios Esperar a que los usuarios los encuentren
 Revisiones Revisar el código fuente
 Etc.
Son inspecciones manuales:
Revisión, la realiza uno mismo
Inspección, la realiza una tercera REVISIÓN DE CÓDIGO [70-80 %]
persona
INSPECCIÓN DE CÓDIGO [50-70 %]
COMPILACIÓN [50 %]
PRUEBAS UNITARIAS [40-50 %]
PRUEBAS INTEGRACIÓN [45 %]
PRUEBAS DE REQUISITOS [45 %]
PRUEBAS DE ALGORITMO [8 %]

15. La importancia de las pruebas
COSTES DE DESARROLLO
Aún y así, la sensación es que
[30-50 %] (habitualmente)
el software no está
Pruebas de Software suficientemente probado
antes de ser distribuido
 Probar software es extremadamente difícil
 Las formas en las que puede comportarse un
programa no se pueden cuantificar
 La prueba se hace típicamente sin una
metodología clara y sin la necesaria
automatización o el soporte de herramientas

16. Principios de las pruebas
 Principio #1
 Todas las pruebas deben ser rastreables hasta los requisitos del
cliente
 Principio #2
 Las pruebas se deben planificar mucho antes de que comience el
proceso de prueba
 Principio #3
 El principio de Pareto es aplicable para las pruebas de software
 Principio #4
 Las pruebas deben comenzar “en lo pequeño” y progresar hacia
“lo grande”
 Principio #5
 Las pruebas exhaustivas no son posibles

17. Etapas de las pruebas
 Pruebas de UNIDAD
 “Pronto“ + propio desarrollador
 Verificar los elementos “testeables” más pequeños del software
 El comportamiento se deduce de los casos de uso
 Pruebas de INTEGRACIÓN
 Asegurar que los componentes actúan de la forma adecuada al combinarse para
la ejecución de un caso de uso
 Verificar paquetes (packages)
 Pruebas de SISTEMA
 Cuando el software funciona como un todo (o cuando subconjuntos de
comportamiento están implementados)
 Todo el sistema
 Pruebas de ACEPTACIÓN
 Acción final de las pruebas antes de desplegar el software
 Verificar que el software está a punto y puede ser usado por los usuarios finales

18. CASO PRÁCTICO 2: PRUEBAS CON
VISUAL STUDIO
18

19. ¡Gracias!