INGENIERÍA DE REQUERIMIENTOS
von Andres Ugarte
1. ¿Cómo inicia un proyecto de software?
1.1. No hay respuestas definitivas a estas preguntas. En ciertos casos, un conversación casual es todo lo que se necesita para desencadenar un trabajo grande de ingeniería de software, Pero en general, la mayor parte de proyectos comienzan cuando se identifica una necesidad del negocio.
1.2. Validación
1.2.1. La calidad de los productos del trabajo que se generan como consecuencia de la ingeniería de los requerimientos se evalúa durante el paso de validación. La validación de los requerimientos analiza la especificación5 a fin de garantizar que todos ellos han sido enunciados sin ambigüedades; que se detectaron y corrigieron las inconsistencias, las omisiones y los errores, y que los productos del trabajo se presentan conforme a los estándares establecidos para el proceso, el proyecto y el producto.
2. Concepcion
2.1. Incluye site tare diferentes: concepción, indagación, elaboración, negociación, especificación, validación y a ministración.
2.2. Administración de los requerimientos.
2.2.1. Los requerimientos para sistemas basados en computadora cambian, y el deseo de modificarlos persiste durante toda la vida del sistema. La administración de los requerimientos es el conjunto de actividades que ayudan al equipo del proyecto a identificar, controlar y dar seguimiento a los requerimientos y a sus cambios en cualquier momento del desarrollo del proyecto.
3. ¿dónde se origina el puente?
3.1. Podria argumentarse que principia en los pies de los participantes en el proyecto (por ejemplo, gerentes, clientes y usuarios), done se definen las necesidades del negocio, se describen los scenarios de uso, se delinean las funciones y caracteristicas y se identifican las restricciones del proyecto.
4. Especificación
4.1. Puede ser un documento escrito, un conjunto de gráficos, un modelo matemático formal
5. Negociación
5.1. Buscar un acuerdo dentro de los requerimiento y la utlizacion de los recursos del negocio y sus limitaciones
6. Indignación
6.1. En verdad que parece muy simple: preguntar al cliente, a los usuarios y a otras personas cuáles son los objetivos para el sistema o producto, qué es lo que va a lograrse, cómo se ajusta el sistema o producto a las necesidades del negocio y, finalmente, cómo va a usarse el sistema o producto en las operaciones cotidianas.
7. Elaboración
7.1. Extraer información cliente, se expande y refina durante la ejecución del sistema
8. Problemas de volatilidad
8.1. Los requerimientos cambian con el tiempo
9. El diseño y construcción de software de computadora es dificil, creativo y sencillamente divertido. En realidad, elaborar software es tan atractivo que muchos desarrolladores de software quieren ir directo a él antes de haber tenido el entendimiento claro de lo que se necesita. Argu- mentan que las cosas se aclararán a medida que lo elaboren,
10. que los participantes en el proyecto podrán comprender sus necesidades sólo después de estudiar las primeras iteraciones del software, que las cosas cambian tan rápido que cualquier intento de entender los requerimientos en detalle es una pérdida de tiempo, que las utilidades salen de la producción de un programa que funcione y que todo lo demás es secundario.
11. Problemas del alcance
11.1. Se refiere a la mala definición en los los sistemas es decir que los clientes o usuarios especifican detalles técnicos innecesarios que confunden.