Herramientas de usuario
ingenieria_de_requisitos:resumenparcial1
Diferencias
Muestra las diferencias entre dos versiones de la página.
| Ambos lados, revisión anteriorRevisión previaPróxima revisión | Revisión previa | ||
| ingenieria_de_requisitos:resumenparcial1 [2024/01/10 16:58] – thejuanvisu | ingenieria_de_requisitos:resumenparcial1 [2024/01/10 18:51] (actual) – thejuanvisu | ||
|---|---|---|---|
| Línea 51: | Línea 51: | ||
| Es un conjunto de preguntas que el analista debe considerar para cada requisito individual. Estas preguntas están relacionadas con atributos de calidad. El problema de los checklist es que es imposible detectar defectos en los requisitos con estas. | Es un conjunto de preguntas que el analista debe considerar para cada requisito individual. Estas preguntas están relacionadas con atributos de calidad. El problema de los checklist es que es imposible detectar defectos en los requisitos con estas. | ||
| - | ===== Prototipos | + | ===== Prototipado |
| + | Se utilizan como herramienta para clarificar requisitos poco claros o para validarlos. Hay varios tipos de prototipado: | ||
| + | ==== Prototipado rápido o desechable ==== | ||
| + | Comienza con partes del sistema que no se comprende del todo con el objetivo de obtener requisitos más precisos. Una vez se ha terminado con el prototipo, este se desecha. | ||
| + | |||
| + | ==== Prototipado evolutivo ==== | ||
| + | Es útil cuando los requisitos están bien establecidos. A diferencia del prototipado rápido, aquí no se desecha el prototipo al final, se reutiliza ya sea modificándolo o como producto final. Es bastante útil en sistemas Orientados a objetos ya que permite el reúso de un paso al siguiente o de un proyecto a otro. Este tipo de prototipado es fácil de cambiar durante el desarrollo, haciendo que sea más probable alcanzar el sistema que los usuarios desean. | ||
| + | |||
| + | ==== Prototipado Operacional ==== | ||
| + | Se trata de una combinación del prototipado rápido y el operacional. Solo se implementan los requisitos que están claros usando técnicas de desarrollo de prototipado evolutivo a partir de los requisitos iniciales. Un técnico que actúa de prototipador visita los puestos de los usuarios y crea prototipos rápidos con las características que el usuario desea. Si alguno de estos prototipos rápidos no sirve se desecha, pero en caso de que sea correcto, se desinstala del puesto y se notifica al departamento de desarrollo la inclusión de los requisitos implementados en dicho prototipo. | ||
| ===== Triage ===== | ===== Triage ===== | ||
| + | También conocido como selección de requisitos, el triage consiste en seleccionar los requisitos cuidadosamente con el objetivo de maximizar los beneficios antes de decidir que requisitos se implementarán. Se suele tener en cuenta: | ||
| + | * La influencia de los requisitos en el producto final | ||
| + | * Gastos e ingresos | ||
| + | * Aspectos técnico-sociales | ||
| + | |||
| + | ==== Influencia de los requisitos en el triage ==== | ||
| + | * Escalabilidad: | ||
| + | * Estables: Son aquellos relacionados con la esencia del sistema y el dominio | ||
| + | * Volátiles: depende de las modas o necesidades: | ||
| + | * Mutables: Cambios en el entorno del sistema | ||
| + | * Emergentes: Aparecen con el uso del sistema | ||
| + | * Consecuentes: | ||
| + | * Compatibles: | ||
| + | * Propiedades a considerar: | ||
| + | * Importancia: | ||
| + | * Objetiva o subjetiva | ||
| + | * No pueden obtenerse de los usuarios, es necesario algún tipo de acción específica para su anotación | ||
| + | * Adecuadas referencias cruzadas | ||
| + | * Permiten identificar los requisitos que deben implementarse conjuntamente | ||
| + | * Si dos requisitos están relacionados la implementación de uno afecta al otro | ||
| + | |||
| + | ==== Evaluación del beneficio ==== | ||
| + | La selección de requisitos implica cuantificar todas las variables, se suelen utilizar valores monetarios para ayudar al cliente a ser consciente del coste, aunque se puede también cuantificar en tiempo. | ||
| + | * evaluación de gastos | ||
| + | * Evaluación de ingresos | ||
| + | * Contrato fijo, desarrollo interno o ingresos intangibles | ||
| + | * Debe ser el analista el que idee un método de cuantificación que permita la comparación de productos alternativos | ||
| ===== Trazabilidad ===== | ===== Trazabilidad ===== | ||
| + | Es el proceso que permite relacionar los requisitos con otros productos del proceso de desarrollo, así como los requisitos entre sí. La especificación de estos debe ser: | ||
| + | * Trazada: cada requisito debe estar relacionado con su origen | ||
| + | * Trazabilidad hacia atrás: Anotar cada requisito con su origen (Documento o cliente) | ||
| + | * Trazable: Cada requisito debe estar relacionado con los productos subsiguientes | ||
| + | * Trazabilidad hacia delante: Compleja ya que puede dar lugar a múltiples productos | ||
| + | * Con referencias cruzadas: Cada requisito debe poder relacionarse con otros requisitos | ||
| + | * Trazabilidad interna: Anotación de cada requisito donde se indicaría los requisitos relacionados (Herramientas CASE) | ||
| + | En la trazabilidad también se pueden utilizar matrices de estabilidad como buena práctica para llevar a cabo la actividad de forma eficiente. Es importante conocer los aspectos de los requisitos como su origen, necesidad, relación con otros requisitos y relación con otros elementos. | ||
ingenieria_de_requisitos/resumenparcial1.1704905916.txt.gz · Última modificación: 2024/01/10 16:58 por thejuanvisu
Herramientas de la página
