Ingeniería de requerimientos: tareas y etapas

CAPÍTULO 5

CAPÍTULO 6

CAPÍTULO 18

CAPÍTULO 17

Ingeniería de requerimientos

El aspecto amplio de tareas y técnicas que llevan a entender los requerimientos se denomina ingeniería de requerimientos.

Proporciona el mecanismo necesario para:

- Entender lo que necesita el cliente

- Analizar las necesidades

- Evaluar la factibilidad

- Negociar una solución razonable

- Especificar la solución sin ambigüedades

- Validar la especificación

- Administrar los requerimientos a medida que se transforman en un sistema funcional

Tareas de la ingeniería de requerimientos:

- Concepción

- Indagación

- Elaboración

- Negociación

- Especificación

- Validación

- Administración de los requerimientos

Establecer las bases

Validación de los requerimientos

Indagación de los requerimientos

Requerimientos de las negociaciones

Elaboración del modelo de los requerimientos

Desarrollo de casos de uso

Etapas requeridas para establecer las bases que permiten entender los requerimientos:

- Identificación de los participantes

- Reconocer los múltiples puntos de vista

- Trabajar hacia la colaboración

- Hacer las primeras preguntas

Los participantes trabajan juntos para identificar el problema, proponer elementos de la solución, negociar distintas visiones y especificar un conjunto preliminar de requerimientos para la solución.

Un caso de uso narra una historia estilizada sobre como interactúa un usuario final con el sistema en circunstancias específicas.

Elementos generales del modelo de los requerimientos:

- Elementos basados en el escenario

- Elementos basados en clases

- Elementos de comportamiento

- Elementos orientados al flujo

Las negociaciones desarrollan un plan de negocios que satisfaga las necesidades del participante y que al mismo tiempo refleje las restricciones del mundo real

A medida que se crea cada elemento de l modelo de requerimientos, se estudia para detectar inconsistencias, omisiones y ambigüedades.

Análisis de los requerimientos

El análisis de los requerimientos da como resultado la especificación de las características operativas del software.

Tipos de modelos:

- Modelos basados en el escenario de los requerimientos desde el punto de vista de distintos “actores” del sistema.

- Modelos de datos, que ilustran el dominio de información del problema.

- Modelos orientados a clases, que representan clases orientadas a objetos (atributos y operaciones) y la manera en la que las clases colaboran para cumplir con los requerimientos del sistema.

- Modelos orientados al flujo, que representan los elementos funcionales del sistema y la manera como transforman los datos a medida que se avanza a través del sistema.

- Modelos de comportamiento, que ilustran el modo en el que se comparte el software como consecuencia de “eventos” externos.

Modelado basado en escenarios

Modelado basado en clases

Modelos UML que proporcionan el caso de uso

Conceptos de modelado de datos

Lo que describe este tema está escrito arriba (en los tipos), creo que no es necesario detallarlo más.

Un enfoque estratégico para la prueba de software

El arte de la depuración

Pruebas del sistema

Pruebas de validación

Estrategias de prueba para webapps

Estrategias de prueba para software orientado a objeto

Estrategias de prueba para software convencional

Aspectos estratégicos

La prueba es un conjunto de actividades que pueden planearse por adelantado y realizarse de manera sistemática.

Una estrategia de software triunfara cuando quienes prueban el software:

- Especifican los requerimientos del producto en forma cuantificable

- Establecen de manera explicita los objetivos de las pruebas

- Entienden a los usuarios del software y desarrollan un perfil

- Desarrollan un plan de prueba que satisface

- Construyen software robusto

- Usan revisiones técnicas efectivas como filtro previo a las pruebas

- Realizan revisiones técnicas para valorar la estrategia de prueba y los casos de prueba

- Desarrollan un enfoque de mejora continuo para el proceso de prueba

Existen muchas estrategias que pueden usarse para probar al software algunas de ellas son:

- Prueba de unidad

Enfoca los esfuerzos de verificación en la unidad más pequeña del diseño de software: el componente o módulo de software.

- Pruebas de integración

Son una técnica sistemática para construir la arquitectura del software mientras se llevan a cabo pruebas para descubrir errores asociados con la interfaz.

El objetivo de probar es encontrar el mayor numero posible de errores con una cantidad manejable de esfuerzo aplicado durante un lapso realista.

Adopta los principios básicos para todas las pruebas de software y aplica una estrategia y tácticas que se usan para sistemas orientados a objetos.

En el nivel de validación o de sistema, desaparece la distinción entre software convencional, software orientado a objetos y webapps.

Es una serie de diferentes pruebas cuyo propósito principal es ejercitar por completo el sistema basado en computadora.

La depuración ocurre como consecuencia de las pruebas exitosas. Cuando un caso de prueba descubre un error, la depuración es el proceso que da como resultado la remoción del error.

Fundamentos de las pruebas del software

Visión interna y externa de las pruebas

Una buena prueba es aquella que tiene una alta probabilidad de encontrar un error.

- Comparabilidad: Saber con cuanta probabilidad se puede comprobar.

- Operatividad: Mientras mejor funcione, más eficientemente puede probarse.

- Observabilidad: Lo que se ve es lo que se prueba.

- Controlabilidad: Mientras mejor pueda controlar el software, más podrá automatizar y optimizar las pruebas.

- Descomponibilidad: Al controlar el ámbito de las pruebas, es posible aislar más rápidamente los problemas y realizar pruebas nuevas y más inteligentes.

- Simplicidad: Mientras haya menos que probar, más rápidamente se le puede probar.

- Estabilidad: Mientras menos cambios, menos perturbaciones para probar.

- Comprensibilidad: Mientras más información se tenga, se probará con más inteligencia.

- Prueba de caja negra: examina algunos aspectos fundamentales de un sistema con poca preocupación por la estructura lógica interna del software.

- Prueba de caja blanca: examen cercano de los detalles de procedimiento.

- Prueba de ruta o trayectoria básica: revisar el conjunto básico tienen garantía para ejecutar todo enunciado en el programa, al menos una vez durante la prueba.

- Ruta independiente: es cualquiera que introduce al menos un nuevo conjunto de enunciados de procesamiento o una nueva condición en el programa.

- Complejidad ciclomática: medición de software que proporciona una evaluación cuantitativa de la complejidad lógica de un programa.

- Prueba de condición: método de diseño de casos de prueba que revisa las condiciones lógicas contenidas en un módulo de programa.

- Prueba de flujo de datos: prueba de un programa de acuerdo con las ubicaciones de las definiciones y con el uso de variables en el programa.

- Prueba de bucle: técnica de prueba de caja blanca.

- Pruebas de caja negra: se enfocan en los requerimientos funcionales del software

- Partición de equivalencia: método de prueba de caja negra.

Lo que describe este tema está escrito arriba (en los tipos), creo que no es necesario detallarlo más.

Lo que describe este tema está escrito arriba (en los tipos), creo que no es necesario detallarlo más.

Lo que describe este tema está escrito arriba (en los tipos), creo que no es necesario detallarlo más.