Investigacion Ingenieria de Software

Recopilación de Requerimientos

Se divide en 7 conceptos:

-Concepción. ¿Cómo inicia un proyecto de software? ¿Existe un solo evento que se convierte en el catalizador de un nuevo sistema o producto basado en computadora o la necesidad evoluciona en el tiempo? No hay respuestas definitivas a estas preguntas. En ciertos casos, una 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 o se descubre un nuevo mercado o servicio potencial.

-Indagación. 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. Pero no es simple: es muy difícil.

Se han identificado cierto número de problemas que se encuentran cuando

Ocurre la indagación:

• Problemas de alcance.

• Problemas de entendimiento.

• Problemas de volatilidad.

-Elaboración. La elaboración está motivada por la creación y mejora de escenarios de usuario que describan cómo interactuará el usuario final (y otros actores) con el sistema. Cada escenario de usuario se enuncia con sintaxis apropiada para extraer clases de análisis, que son entidades del dominio del negocio visibles para el usuario final.

-Negociación. No es raro que los clientes y usuarios pidan más de lo que puede lograrse dado lo limitado de los recursos del negocio. También es relativamente común que distintos clientes o usuarios propongan requerimientos conflictivos con el argumento de que su versión es “esencial para nuestras necesidades especiales”. 

-Especificación. En el contexto de los sistemas basados en computadora (y software), el término especificación tiene diferentes significados para distintas personas. Una especificación puede ser un documento escrito, un conjunto de modelos gráficos, un modelo matemático formal, un conjunto de escenarios de uso, un prototipo o cualquier combinación de éstos.

-Validación. 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ón 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.

-Administración de los requerimientos. 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.

Preguntas de Formulación

Antes de preocuparse por las preguntas de formulación que debe hacer, debe identificar quién será el objetivo de las preguntas. Necesitará identificar a las partes interesadas. Una parte interesada puede definirse como "cualquier persona que se beneficia directa o indirectamente del sistema que se está desarrollando" -Ian Sommerville.

En el mejor de todos los mundos, una persona será el centro de sus preguntas. Este individuo tendrá una experiencia empresarial adecuada, un buen conocimiento técnico y la autoridad para negociar las necesidades en términos de tiempo de entrega y recursos. Sin embargo, es más probable que se ocupe de un número de diferentes partes interesadas, cada una con un punto de vista diferente, a veces necesidades divergentes y conocimientos técnicos y de negocios sustancialmente diferentes. En general, las partes interesadas se basan en las siguientes categorías: gerentes de negocios, gerentes de producto, personas de marketing, clientes internos y externos, usuarios finales, consultores, ingenieros de productos, ingenieros de Web y personal de soporte y mantenimiento.

Definición de las Categorías de Usuario

-Gerentes y altos ejecutivos. Son los que se les permite controlar, controlar y, en general, gestionar los procesos institucionales. Son sistemas de apoyo a las personas y equipos que tienen que estar pendientes si las "cosas funcionan bien". Algunas características clásicas de estos tipos de usuarios requieren que organicen y resuelvan las decisiones semiestructuradas, realicen la gestión de riesgos bajo diversos escenarios y lleven a cabo la planificación con un horizonte a la escala de meses, trimestre o año.

-Operadores. Ellos son responsables de acceder a la información crítica de negocios y tener la capacidad de distribuir dicha información a las diferentes personas de la organización y los usuarios para asegurar la toma de decisiones basadas en información precisa, confiable y oportuna que puede afectar el desarrollo y el éxito del negocio.

Desarrollo de Casos de Uso

En ésta es posible identificar a los actores principales, y a los secundarios cuando se sabe más del sistema. Los actores principales interactúan para lograr la función requerida del sistema y obtienen el beneficio previsto de éste. Trabajan con el software en forma directa y con frecuencia. Los actores secundarios dan apoyo al sistema, de modo que los primarios puedan hacer su trabajo.

Una vez identificados los actores, es posible desarrollar casos de uso. Se sugieren varias preguntas que debe responder un caso de uso:

• ¿Quién es el actor principal y quién(es) el(los) secundario(s)?

• ¿Cuáles son los objetivos de los actores?

• ¿Qué precondiciones deben existir antes de comenzar la historia?

• ¿Qué tareas o funciones principales son realizadas por el actor?

• ¿Qué excepciones deben considerarse al describir la historia?

• ¿Cuáles variaciones son posibles en la interacción del actor?

• ¿Qué información del sistema adquiere, produce o cambia el actor?

• ¿Tendrá que informar el actor al sistema acerca de cambios en el ambiente externo?

• ¿Qué información desea obtener el actor del sistema?

• ¿Quiere el actor ser informado sobre cambios inesperados?