Sqa Fases Tempranas

Aseguramiento de calidad en fases
tempranas del desarrollo

Carlos Andrs Jaramillo
Q-Vision S.A.
Gerente General
Profesor de la Especializacin en Desarrollo de Software de
la Universidad EAFIT
Tertulias de IS. Tema: Aseguramiento de la Calidad en Fases Tempranas. Marzo del 2006
Nos hicieron la entrega del producto, mucho
tiempo despus de la fecha pactada y nos costo el
triple de lo inicialmente estimado. Luego toco
estabilizarlo en produccin 6 meses ms. Ahora
funciona, pero no responde a lo que esperbamos;
y eso que tratamos de seleccionar la mejor oferta
tcnica
Testimonio de un cliente
Nos demoramos la mitad del proyecto esperando
que se pusieran de acuerdo e hicieron cambios hasta
la ultima hora. Despus de horas de mucho esfuerzo
no los dejamos satisfechos. Ahora el producto esta
corriendo en produccin, pero perdimos mucha plata
y eso que pusimos nuestro mejor director de
proyectos.
Testimonio de un proveedor de desarrollo
Le suenan familiares estos comentarios?
La trinidad de la calidad
F
u
n
c
i
o
n
a
l
i
d
a
d
Costo
C
a
l
e
n
d
a
r
i
o
Cuando
Terminaremos?
Cuanto Costara?
Cual es el avance
y cobertura?
El problema
xito
Cumple plazo, costo y
alcance; es operacional
Dificultad
No cumple plazo, costo y
alcance; no es operacional
Fracaso
No se completa
13%
30%
57%
xito Dificultad Fracaso
The Standish Group Report - 2004
Top 5 de errores clsicos que se
comenten en un proceso de desarrollo
de software
N 5
Pensar que el proceso de pruebas funcionales
garantiza la calidad del producto.
Top 5 de errores clsicos
Siempre queremos un software
Fcil de aprender y usar
De rpida ejecucin
Que tiene la funcionalidad apropiada
Que no contiene ningn error
A prueba de intrusos
Que funciona en todos los computadores
Que es fcil de modificar frente a nuevas necesidades
Aseguramiento continuo
De todos estos atributos, cul es el mas
relevante para un proyecto en
particular?
La calidad en un Producto de
software
Portabilidad Funcionalidad
Mantenibilidad Confiabilidad
Rendimiento Usabilidad
ISO/IEC
9126
Que tan fcil es
transferir a otro
ambiente?
Estn disponibles
y bien hechas la
funciones y reglas
del negocio?
Funciona sin errores?
Son frecuentes los
errores y los tolera?
Es fcil
modificarlo?
Cuanto tiempo
tarda? que
recursos utiliza?
Es fcil de
aprender, entender
y usar?
Enfoque para el gerenciamiento
de QA
Verificacin de
Artefactos
Verificacin
de requisitos
Seguimiento
de defectos
Rendimiento
VERIFICACIN VALIDACIN CONTROL
Mtricas, estadsticas e indicadores del proceso
Funcionalidad
Usabilidad
Gerencia
del proceso
Control de
Cambios y
versiones
Verificacin
del proceso de
desarrollo
Confiabilidad
Soportabilidad
N 4
No tener un mtodo de rastreo o seguimiento a los
cambios que ocurren y causan impacto en el
producto.
Por lo menos hay dos modelos (vistas) que siempre
deben estar presentes: Modelo de requisitos y Modelo de
implementacin
Control de cambios
Control de cambios
Modelo de negocio
Modelo de anlisis
Requisitos
Modelo de diseo Modelo de despliegue
Modelo de
implementacin
Modelo de pruebas
<<trace>>
<<trace>>
<<trace>>
<<trace>>
<<trace>>
<<trace>>
Caja negra
Caja Blanca
<<depend on>>
<<depend on>>
N 3
Pensar que en un proyecto se avanza por
calendario
Avance por calendario
- Se registra solo el avance por el paso de tiempo
Avance por Funcionalidad
- Se registra avance solo por desarrollo completado
Efecto
Medir el avance
0
20
40
60
80
100
Avance
50%
90%
Indicador de funcionalidad completa
- Esta completa
- Ha sido probada
- No posee defectos crticos
Medir el avance
Mdulo 1
40%
Modulo 2
15%
Mdulo 3
20%
Opcin 1
25%
Opcin 2
35%
Funcionalidad 1 Funcionalidad 2
Funcionalidad 3 Funcionalidad 4
Opcin 3
50%
Mdulo4
25%
Aplicacin
N 2
No estimar adecuadamente el tiempo y el esfuerzo
del proyecto
Mtodos de estimacin
Construccin Estabilizacin
Tiempo
C
o
m
p
l
e
t
i
t
u
d
Se puede predecir la fecha de finalizacin del proyecto?
Sabremos cuanto cuesta en tiempo y recursos la estabilizacin?
Sabremos cuantas personas necesitaremos?
Funcionalidad
completa
Mtodos de estimacin
Requerimientos
Requerimientos
Anlisis y Diseo
Anlisis y Diseo
Codificacin
Codificacin
Prueba
Prueba
Admin. Proyecto
Admin. Proyecto
Gestin Configur.
y Cambio
Gestin Configur.
y Cambio
Inicio
Inicio
Elaboracin
Elaboracin
Construccin
Construccin
Transicin
Transicin
Iteracin
Iteracin
Iteracin
Iteracin
Iteracin
Iteracin
Iteracin
Iteracin Iteraciones:
Disciplinas:
Alcances y
Objetivos
Alcances y
Objetivos
Arquitectura
Arquitectura
Versin
Beta
Versin
Beta
Versin
Final
Versin
Final
Entregas
Internas
Entregas
Internas
N 1
No dedicarle el tiempo suficiente a definir y verificar
los requisitos
Administracin de requisitos
1. Requisitos incompletos e incoherentes.
2. Mtodos de estimacin subjetivos.
3. No medir el avance
4. Cambios no controlados.
5. Insuficientes pruebas.
6. Inconsistencias en el diseo y la implementacin
7. Arquitectura superficial.
8. Falta de compromiso de parte de los usuarios.
9. No utilizacin de herramientas de apoyo.
10. Comunicacin ambigua en el equipo.
Principales factores del fracaso
Desde las primeras fases podemos mitigar el riesgo
identificando problemas a tiempo
COMO?
Direccionar los problemas
1. Verificacin de artefactos y requisitos
2. Mtodos de estimacin.
3. Dividir el producto en circuitos funcionales.
4. Control de cambios y Rastreabilidad
5. Testing durante todo el proceso.
6. Uso de UML
7. Desarrollo por iteraciones
8. Uso de herramientas de Ingeniera de software
Revisiones Tcnicas Formales
Un revisin es una reunin formal en la que se verifican
artefactos y actividades y se realiza un anlisis
estructurado de los mismos.
El objetivo bsico de las RTFs es detectar errores en la
especificacin antes de que se conviertan en defectos en
la implementacin.
Hay diversos tipos de revisiones de mayor o menor
Formalidad.
Los objetivos de la RTF son:
Descubrir errores.
Verificar que el software alcanza sus requisitos.
Garantizar que el software se desarrolla de acuerdo a ciertos
estndares predefinidos.
Conseguir un software desarrollado de manera uniforme.
Hacer que los proyectos sean ms manejables.
Ventajas de las Revisiones
a. Evaluar la capacidad de las especificaciones para satisfacer las
necesidades del usuario.
b. Los errores son detectados muy cerca al momento en que ellos se
introducen.
c. Mejoran la calidad del producto.
d. Disminuyen los costos del proyecto.
e. Permite avanzar desde un esquema de correccin de errores a un
esquema de prevencin de errores.
TIPOS DE RTFs
Distingue entre cinco tipos de revisiones en funcin del
producto a revisar y del objetivo:
Revisiones de gestin
Revisiones tcnicas
Inspecciones
Recorridos
Auditorias
Revisiones de gestin o
gerenciales
Evaluacin sistemtica del proceso de adquisicin,
suministro, desarrollo, operacin o mantenimiento de
software realizada por o en lugar de la gerencia, para
controlar el progreso, determinar el estado de los
planes y calendarios, confirmar requisitos y su
asignacin en el sistema, o evaluar la efectividad de
los enfoques gerenciales utilizados para lograr
adecuacin a los propsitos.
Su propsito es:
Monitorear el progreso.
Determinar el estado de los planes.
Evaluar la efectividad de las actividades de gestin para
conseguir sus objetivos.
Entre otros revisan:
Plan del proyecto
Cronogramas
Planes de gestin del riesgo
Planes Aseguramiento de calidad
Revisiones de gestin o
gerenciales
Revisiones Tcnicas
Evaluacin sistemtica de un producto de software
por un equipo calificado de personas, que examina la
adecuacin de un producto de software a su uso
previsto e identifica discrepancias respecto a
especificaciones y estndares. Revisiones tcnicas
tambin pueden proporcionar recomendaciones de
alternativas y examinar varias soluciones.
Revisiones Tcnicas
Evalan un producto software para determinar si:
El producto software se ajusta a sus especificaciones.
El producto software respeta los criterios o estndares
aplicados en el proyecto.
Los cambios en el producto software se implementan
adecuadamente.
SRS
Diseo
Documentacin de pruebas
Modelos y diagramas
Inspecciones
Examen visual de un producto de software para detectar
e identificar anomalas, incluyendo errores y
desviaciones de estndares y especificaciones. Las
Inspecciones son evaluaciones por pares dirigidas por
facilitadores imparciales que estn entrenados en
tcnicas de inspecciones (Grupos de QA).
La determinacin de acciones de solucin o
investigacin es un elemento obligatorio de una
inspeccin de software, aunque la solucin no debiera
ser determinada durante la reunin de inspeccin
Buscan anomalas mediante un examen que:
Verifica que el producto software cumple sus especificaciones
Verifica que el producto software cumple con sus atributos de calidad
especficos.
Verifica que el producto software se ajusta a los criterios y estndares
del proyecto
Identifica desviaciones de estndares y especificaciones
Requisitos
Diagramas y modelos
Diccionarios de datos
Inspecciones
Recorridos o Walkthrough
Tcnica de anlisis esttico en la que un diseador o
programador dirige miembros del equipo de
desarrollo y otras partes interesadas a travs de un
producto de software y los participantes formulan
preguntas y realizan comentarios acerca de posibles
errores, violacin de estndares de desarrollo y otros
problemas.
Sirve para evaluar un producto software:
Buscando anomalas
Mejorando el producto
Considerando implementaciones alternativas
Evaluando la conformidad con estndares y especificaciones
Modelos
Arquitectura
Cdigo
Recorridos o Walkthrough
Auditorias
Evaluacin independiente de un producto de
software, proceso de software, o conjunto de
procesos de software para evaluar el cumplimiento
de especificaciones, estndares, acuerdos
contractuales, costos, recursos y otros criterios.
Proporcionan una evaluacin independiente de conformidad
del producto software y los procesos de gestin con
regulaciones y estndares.
Informes y datos
Plan del proyecto
Planes de gestin del riesgo
Planes de garanta de calidad
Auditorias
El Modelo de Mejora del Proceso de Pruebas ( TPI - Test
Process Improvement ) se ha desarrollado partiendo del
conocimiento y la experiencia de las Pruebas de Control de
Software. El modelo TPI es un medio de ayuda para mejorar el
proceso de pruebas.
El modelo permite visualizar el nivel de madurez del proceso
de pruebas dentro de su organizacin. Partiendo de este
criterio, el modelo ayuda a definir pasos de mejora graduales y
controlados.
Utilizacin del TPI
Descripcin del modelo TPI
reas claves
Niveles de madurez
Puntos de verificacin Sugerencias de mejora
Matriz de
madurez de
pruebas
1. Estrategia de pruebas
2. Modelo del Ciclo de Vida
3. Momento de Incorporacin
4. Estimacin y Planeacin
5. Tcnicas de Diseo de
Pruebas
6. Tcnicas de Pruebas Estticas
7. Mtricas
8. Herramientas de Prueba
9. Entorno de Pruebas
10. Entorno de Oficina
reas claves
11. Compromiso y Motivacin
12. Funciones de Pruebas y capacitacin
13. Alcance de la Metodologa
14. Comunicacin
15. Informes
16. Manejo de Defectos
17. Administracin del Testware (elementos
de prueba)
18. Administracin del Proceso de pruebas
19. Revisin Estructurada
20. Pruebas de Caja Blanca
El modelo proporciona Niveles (de A a B a C). Como promedio, hay
tres niveles por cada rea. Cada nivel superior (donde C es mayor
que B, y B es mayor que A) es mejor que su nivel previo en trminos
de:
- Tiempo (ms rpido )
- Dinero (menor costo )
- Calidad (mejor).
Al usar niveles podemos evaluar sin ambigedades la situacin
prevaleciente del proceso de pruebas. Tambin incrementa la
posibilidad de recomendar mejoras graduales.
Niveles de madurez
Con el fin de determinar los Niveles, el modelo TPI se basa en un
instrumento de medicin objetiva. Los requisitos para cada nivel
estn definidos en forma de Puntos de Verificacin (Checkpoints):
son preguntas que necesitan ser respondidas afirmativamente para
poder calificar a dicho nivel.
Al igual que CMMI los Puntos de Verificacin son acumulables
Puntos de verificacin
Las Sugerencias de Mejora, que son diferentes tipos de ideas o
consejos que ayudan a alcanzar un cierto nivel de madurez
de pruebas.
A diferencia de los Puntos de Verificacin, no es obligatorio usar las
Sugerencias de Mejora. Cada nivel est provisto de varias
Sugerencias de Mejora.
Sugerencias de mejora
Dificultades para implementar estas
prcticas en el medio
Ver a la calidad como un costo y no como una inversin.
Falta de conocimiento y divulgacin de estas prcticas.
Herramientas de apoyo costosas.
Mentalidad corto-placista.
No se documentan aprendizajes de proyectos anteriores
(lecciones aprendidas).
Falta de compromiso de la alta gerencia.
Conclusiones
La calidad no es gratis.
Es mejor detectar errores a tiempo en la primeras fases
para evitar costos y sobreesfuerzos.
Cada problema de software tiene solucin.
El equipo de QA no solo sirve para testear.
La idea de que podemos planificar algo desconocido
fijando costo, plazo y alcance es un mito.

Sqa Fases Tempranas

Cargado por

Información del documento

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

Sqa Fases Tempranas

Cargado por

Copyright:

Formatos disponibles

Aseguramiento de calidad en fases

tempranas del desarrollo

También podría gustarte