Ingeniería de Software

1. Ingeniería de Software Control y aseguramiento de la calidad

2. ¿Qué es QualityAssurance? • Es el proceso general de administración, aseguramiento y control de la calidad. • Incluye todos los aspectos que hacen a la calidad del software final y sus atributos: • SRS • Diseño • Desarrollo • Control de cambios • Planeamiento • Control de calidad

3. ¿Qué es control de calidad? • Un conjunto de actividades que se encargan de controlar que se consiga alcanzar los objetivos previstos • Éstas actividades se pueden dividir en dos grupos: • Validación • Verificación • El planeamiento y alcance de éstas actividades es responsabilidad de QA

4. ¿Qué es V&V? • Verificación: • “Estamos creando el producto correctamente?” • El producto debe conformar a su especificación de manera correcta • Validación: • “Estamos creando el producto correcto?” • El producto debe conformar a las necesidades del cliente • En la práctica es difícil ver el límite entre los dos grupos.

5. ¿Cuál es el objetivo de V&V? • Según IEEE-1012: • Facilitar la detección de errores en etapas tempranas • Mejorar la visibilidad de la calidad, los riesgos y el cumplimiento del proceso • Asegurar que se cumplan todas las actividades planificadas de manera eficiente, respetando calendario y recursos

6. ¿Qué es Validación? • Según IEEE-1012: • Es el proceso de chequear que el software: • Responde a los requerimientos de sistema especificados y resuelve el problema especificado correctamente • Es decir, el producto sea tal cual fue especificado • Herramientas: • Testing unitario manual/automatizado • Testing integral

7. ¿Qué es Verificación? • Según IEEE-1012: • Es el proceso de chequear que todos los artefactos: • Cumplen con los atributos de calidad esperados en todo el ciclo de vida. • Satisfacen los estándares de calidad y buenas prácticas durante todo el ciclo de vida • Establecen una base para asegurar que el resultado de cada actividad sea el input esperado para la actividad que lo requiera • Es decir, el proceso sea el esperado • Herramientas: • Checklists • Inspección de código

8. Características de V&V • Especifica acciones durante todo el ciclo de vida • Los procesos de Validación y Verificación funcionan mejor si están hechos en paralelo al desarrollo del producto, y no después. • Las actividades de V&V son complementarias.

9. Validación • El objetivo es encontrar fallas en el producto: • Hacerlo lo mas eficientemente posible • Encontrar la mayor cantidad de fallas • No detectar fallas que en realidad no lo son • Encontrar las mas importantes

10. Definiciones • Incidente: • Todo evento no esperado durante la ejecución de una prueba de software. • Clasificación • Equivocación: Una acción humana que produce un resultado incorrecto • Defecto: Error o mala práctica en el código • Falla: Resultado no esperado. Es la manifestación de uno o más defectos. • No toda incidencia es una falla • No todo defecto produce una falla en el momento del testing • Una equivocación lleva a uno o más defectos, que están presentes en el código • Un defecto lleva a cero, una o mas fallas • La falla es la manifestación del defecto • Una falla tiene que ver con uno o más defectos

11. Definiciones • Test case vs Test condition • Los casos de prueba son lotes de datos necesarios para que se dé una determinada condición de prueba • Las condiciones de prueba son descripciones de situaciones ante las que el sistema debe responder que quieren probarse • Economía de la Prueba: • Se puede invertir mucho esfuerzo en probar • Probar es el proceso de establecer confianza en que un programa hacelo que se supone que tiene que hacer • Ya que nunca voy a poder demostrar que un programa es correcto... • Continuar probando es una decisión económica

12. Tipos de prueba • Los tipos de prueba varían de acuerdo a la actividad del ciclo de vida.

13. Tipos de prueba • De acuerdo al conocimiento interno que se tenga, las prubas unitarias, de integración y funcionales se pueden clasificar en: • Prueba de caja negra • Prueba de caja blanca • Las pruebas de regresión, sistema y aceptación deben ser siempre de caja negra.

14. Prueba de caja negra • Se valida que el resultado de una acción sea el esperado de acuerdo a la especificación. • Requiere, por lo tanto, una especificación verificable • En la teoría, una prueba de caja negra completa es imposible de realizar: se deberían probar todas las combinaciones de todos los valores posibles. • En la práctica, se definen conjuntos de datos de entrada posibles.

15. Prueba de caja negra • Conjuntos: • Clases o particiones de equivalencia • Conjunto de valores equivalentes • Condiciones de borde • Valores de tipos no esperados o incorrectos • Integridad del modelo de datos • Dominio • Entidad • Relación • Probando los valores específicos de cada conjunto encontrado se cubre toda la prueba • La cantidad de conjuntos y combinaciones utilizadas definen la calidad de la prueba

16. Prueba de caja blanca • Al igual que la prueba de caja negra evalúa el resultado. • A diferencia de este, aprovecha el conocimiento interno del código para dirigir la prueba. • El desarrollador al conocer la estructura interna puede dirigirse directamente a las partes del código más riesgosas.

17. Prueba de caja blanca • Test coverage: • Mide la calidad del test de acuerdo al porcentaje del código probado. • Grados de cobertura: • Sentencia • Decisión • Condición • A mayor complejidad ciclomática, mayor dificultad en maximizar el test coverage.

18. Tipos de test – Unit Test • Prueba componentes en forma independiente o en conjuntos reducidos. • A mayor cohesión, mayor capacidad de probar componentes independientemente. • Generalmente es realizado por el desarrollador, y se ejecuta de manera automatizada. • Se debería hacer para cada componente de código individual. • Se busca encontrar errores lo antes posible • Al ser un test de caja blanca, se busca maximizar el coverage.

19. Tipos de test – Prueba de regresión • Pruebas orientas a probar que la funcionalidad no modificada en una iteración o luego de un cambio siga funcionando. • Se realiza de manera manual, a partir de un plan de testing que especifique los casos de prueba que se deben ejecutar en casos de regresión. • Se complementa con los test unitarios, en la medida que, estos, se ejecuten automáticamente cada vez que se realice un cambio.

20. Tipos de test – Pruebas funcionales • Se prueba cada requerimiento por separado, probando los resultados esperados contra los actuales. • Es un test de caja negra. • Cada caso de prueba es un conjunto corto de acciones.

21. Tipos de test – Pruebas de sistema • Se prueba el sistema buscando que las relaciones entre los distintos requerimientos se cumplan y se tienen en cuenta los requerimientos no funcionales. • Tipos de prueba: • Pruebas exploratorias • Pruebas de camino básico • Pruebas de stress • Pruebas de rendimiento • Pruebas de usabilidad

22. Tipos de test – Pruebas de usuario • Prueba especificada por el sponsor, basada en la especificación de requerimientos, y ejecutada por él, con el objetivo de definir si el software cumple, o no, la especificación y en qué grado.

23. Verificación • El objetivo es asegurar que se sigue el proceso • Esto incluye asegurar que los resultados de una actividad sean los esperados • Herramientas: • Inspecciones de código manuales • Inspecciones de código automatizadas • Checklists

24. Inspecciones de software manuales • Actividad realizada por los desarrolladores con el objetivo de descubrir defectos y anomalías. • Las inspecciones no requieren software andando y pueden ser realizadas tanto contra el código, como contra el diseño. • Es una técnica que permite encontrar defectos en etapas tempranas que serían difíciles de encontrar en pruebas en ejecución.

25. Inspecciones de software manuales • Se espera la presencia de desarrolladores expertos. • Son complementarias al testing, no lo reemplazan. • Una sola inspección puede encontrar muchos defectos

26. Pre-condiciones • Se debe tener la especificación de requerimientos • Un checklist de errores comunes puede ayudar • Se debe tener la aceptación y conformidad del management, dado que estas tareas implican costos directos, pero reducen costos a futuro. • Las inspecciones de código no son herramientas para evaluar al personal

27. Procedimiento • Se debe especificar quiénes participan en la inspección y con qué responsabilidad. • Los participantes deben saber qué código se va a verificar y se debe estudiar con antemano • Se realiza la inspección del código o documentos seleccionados, y se anotan los defectos encontrados • Se arreglan los defectos encontrados • Se evalúa si se debe volver a hacer la inspección

28. Roles • Autor: • El responsable del código o documento a evaluar • Se debe entender que lo que se evalúa es el código o documento, NO al autor • Inspector: • Una o más personas que se encargan de encontrar errores • Lector: • Encargado de dirigir la lectura • Moderador: • Maneja el proceso y se encarga que no haya conflictos. • Reporta al responsable de la inspección. • Responsable de inspección: • Se encarga de planear y administrar las inspecciones y definir los roles de cada integrante

29. Inspecciones de código automatizadas • Se utilizan herramientas de software que procesan el código • Encuentran errores comunes, a partir de patrones definidos. • No reemplazan a las inspecciones manuales, pero ayudan a encontrar errores comunes más fácilmente, por ejemplo: • Manejo de excepciones • Chequeo de tipos de datos • Chequeo de inicialización de variables

30. Checklist • Herramienta de verificación manual, utilizada para saber si un artefacto cumple, o no, con ciertas condiciones. • Las condiciones incluyen condiciones de formalidad y contenido, condiciones impuestas por estándares de calidad, condiciones impuestas por la organización. • Se utiliza tanto para código como para documentación.

31. Ejemplo - Checklist de código • Se utiliza como ayuda para las inspecciones de código • Enumera defectos comunes, dependientes del lenguaje, que es probable encontrar • Cuanto más levemente tipado es un lenguaje, más chequeos se necesitan • Ejemplos: • Inicialización • Nombres de variables • Manejo de excepciones

32. Métricas y su relación con V&V • Inspecciones y Reusabilidad se pueden apoyar en: • Métodos ponderados por clase • Profundidad del árbol de herencia • Falta de cohesión de métodos • Acoplamiento entre objetos • … • Pruebas unitarias y verificabilidad / mantenibilidad se pueden apoyar en: • Test coverage • Complejidad ciclomática • Comentarios/Documentación • Cohesión / Acoplamiento • …

33. Planeamiento de pruebas

34. Planeamiento de pruebas

35. Planeamiento de pruebas • El proceso de prueba: Una descripción de las fases principales del proceso de prueba • Seguimiento de requerimientos: Se debe saber que requerimientos individuales se están probando • Elementos probados • Calendarización, incluyendo asignación de recursos • Procedimiento de registro de las pruebas: No alcanza con ejecutarlas, hay que registrar el resultado • Requerimientos de HW y SW: No todas las pruebas requieren del mismo HW o SW para ser ejecutadas

36. Estructura de un test case • Referencia: identificador, creador, versión, nombre, …, requerimientos que prueba, dependencias (con otros subsistemas por ej) • Ambiente: Configuración de HW y SW a utilizar • Inicialización: Prepara el escenario • Acciones: Acciones para ejecutar y completar la prueba • Finalización: “Resetea” el ambiente a un estado inicial no relacionado con el test case • Datos de entrada: Se especifican las diferentes particiones de los datos de entrada • Resultados • Resultado: Ok/Fallido • Salida esperada • Salida obtenida • Severidad: Impacto de la falla • Adjuntos: Screenshots, archivos log, …

37. Intervalo (que largo que fue, no?)

38. Herramientas CASE • CASE: ComputerAided Software Engineering Ingeniería de Software Asistida por Computadora • Desde “simples” modeladores para realizar análisis, hasta herramientas capaces de generar código fuente.

39. CASE: DB

40. CASE: Análisis

41. CASE: Desarrollo

42. CASE • Building continuo • Inspección automatizada (Sonar, findbugs, etc…) • Test coverage • Test automatizados • Formateo automático, control de inclusión de documentación

43. Preguntas

44. Sugerencias

45. Aplausos