Este documento describe los conceptos clave de la ingeniería de software y la gestión de la calidad de software. Explica los modelos del ciclo de vida del software como la cascada, prototipo e incremental. También cubre temas como requisitos, diseño, construcción, verificación, validación y pruebas de software.
2. Conocer los conceptos de la Ingeniera de
Software y las diferentes técnicas para
realizar pruebas.
3. Modelos del ciclo de vida del Software
Cascada
En V
Prototipo
Incremental
Espiral
4. Verificación y Validación
Principios
Técnicas
Estrategias
Criterios de terminación
Herramientas de pruebas
6. Una forma conveniente de dividir los
proyectos es en fases.
Las actividades del ciclo de vida transforman
las necesidades del usuario en un producto de
software que satisfaga las necesidades.
7. Requerimientos
Diseño
Construcción
Operación y Mantenimiento
8. Se traducen las necesidades del cliente en un
documento formal, se describen los acuerdos
a los que se ha llegado con el cliente.
9. Es una necesidad del usuario para resolver un
problema o cumplir con un objetivo.
Es una condición que debe tener un sistema
para cumplir con un contrato, especificación
o estándar.
10. La salida de esta fase es el documento de
especificación de requerimientos del
software (SRS).
11. El SRS debe incluir la siguiente información:
Lo que el programa va hacer funcionalmente.
Formatos de entrada y de salida de los datos.
Excepciones, errores y desviaciones.
El entorno del sistema.
12. Esta actividad empieza cuando esta
disponible el documento de requerimientos.
Es el primer paso para llegar a una solución.
El diseño es el modelo para la solución.
El documento de requerimientos y de diseño
en conjunto describen el problema y la
organización de la solución.
13. La información que debe incluirse en el
documento de diseño es:
Especificación de la estructura de datos.
Funciones y Algoritmos.
Modularizacion.
Especificación de las Interfaces.
Información especifica del proyecto.
14. El proceso del diseño de sistemas de software
consta de dos niveles.
Diseño del sistema
Diseño detallado
15. Si los requisitos y el diseño se hacen
correctamente, la codificación es sencilla,
casi mecánica.
16. El primer paso en la verificación durante la
fase de construcción consiste en determinar
si el código es coherente con el diseño.
El código y el diseño deben exhibir la misma
estructura modular y tener las mismas
interfaces.
17. Las inspecciones del código o revisiones son
una herramienta muy útil y pueden mejorar
considerablemente la fiabilidad y reducir el
esfuerzo durante las pruebas.
La ejecución real del programa utilizando
datos de prueba debe llevarse a cabo de
manera ordenada.
18. Las funciones comunes en esta etapa son:
Identificación y corrección de errores
Modificaciones
Mejoras para agregar capacidades de rendimiento
19. Feasibility Req. Analysis &
System
Report Project Planning
Feasibility
Validation Validation
Requirements Document
And Project Plan
System Design Detailed Design
System Design
Verification Verification
Document
Detailed
Design Document
Coding
Programs Testing and
Verification Integration
Test Plan,
Test Report
And Manuals
Installation Operations and
Maintenance
Installation
Report
20. Es similar al modelo cascada, exceptuando
que este considera las actividades de pruebas
en fases previas del ciclo de vida.
21. Se consideran las siguientes pruebas para
cada fase del desarrollo:
Requerimientos -> Pruebas de Aceptación
Diseño de alto nivel -> Pruebas de
sistema/Integración
Diseño detallado -> Pruebas unitarias
22. Este modelo se utiliza generalmente para
desarrollar una aplicación rápida del software
antes o durante la fase de requerimientos.
El cliente utiliza el prototipo y proporciona
información al equipo de desarrollo en cuanto
a su fuerza y sus debilidades.
23. Este modelo permite construir el software en
las etapas elementales, en cada etapa se
añade funcionalidad.
Cada etapa consiste en el
diseño, código, pruebas y entrega.
24. Este modelo ofrece una orientación a los
riesgos durante el ciclo de vida.
Las actividades se organizan como un espiral
que tiene muchos ciclos.
25. La verificación es la demostración de la
consistencia, la integridad y la exactitud del
software en cada etapa del desarrollo del
ciclo de vida.
La validación es la determinación de la
exactitud del programa con respecto a las
necesidades del usuario.
26. Un tutorial es un método informal para la
evaluación del software.
Es un pequeño grupo de casos de prueba.
27. En la inspección se utiliza una lista de
verificación para encontrar los errores.
Si las listas de verificación han sido diseñadas
adecuadamente los errores se pueden
encontrar muy fácilmente.
28. Se verifica que el software cumpla con los
requerimientos.
Se trata de la operación de un sistema bajo
condiciones controladas y la evaluación de los
resultados.
29. Falta de comunicación
Complejidad del software
Errores de programación
Cambio de los requerimientos
Presiones de tiempo
Egos
Código mal documentado
Herramientas de desarrollo de software
30. El objetivo de una metodología de pruebas es
reducir el proceso de pruebas exhaustivas a
un proceso de pruebas finito.
Se debe tomar un subconjunto de datos del
dominio.
La parte mas crucial es encontrar un conjunto
de datos de prueba suficientes que cubra el
dominio pero pequeño para su uso.
31. Las pruebas deben realizarse de conformidad
con los planes y procedimientos.
Generar datos de prueba en todas las etapas.
Desarrollar un medio para el calculo de los
valores esperados para los datos de prueba.
Guardar, organizar y anotar las pruebas.
32. Los casos de pruebas no solo deben ser
escritos para valores de entrada validos.
Concentrar las pruebas en los módulos que
presentan mas errores.
Volver a realizar pruebas cuando se hagan
modificaciones.
33. Pruebas de caja negra
Pruebas de caja blanca
34. Son pruebas en el nivel mas simple para
probar funciones particulares o módulos de
código.
Generalmente las realiza el programador.
35. Se prueban las partes combinadas para
determinar si funcionan correctamente
juntas.
Las partes pueden se módulos de
código, aplicaciones individuales, etc.
36. Se trata de probar continuamente la
aplicación conforme se agregan nuevas
funcionalidades.
Se realizan en segmentos pequeños.
37. Proporciona la garantía final de que el
software cumple con todos los requisitos
funcionales y de comportamiento.
38. Se verifica que todos los elementos del
sistema completo (hardware, personas, bases
de datos, software) funcionen correctamente
y que se logre la función global del sistema.
39. Es la prueba final, basada en las
especificaciones del usuario final o cliente
durante un periodo de tiempo limitado.
A veces se realiza con datos reales.
40. Se realizan cuando se hacen cambios en el
sistema vigente.
Todas las partes afectadas por las
modificaciones deben ser probadas de nuevo.
41. Terminar cuando el tiempo programado para
las pruebas expira.
Terminan cuando los casos de prueba ya no
reportan errores.