Ingeniera en Sistemas Computacionales

PLANEACION Y MODELADO
Integrantes del Equipo:
Jhonatan Israel Aguilar Garca Zuridiana Roxette Morales Santiago Yadira Jacqueline Lpez Daz Anna Isabel Garca Yera

Ingeniera de requerimientos es la disciplina para desarrollar una especificacin completa, consistente y no ambigua, la cual servir como base para acuerdos comunes entre todas las partes involucradas y en dnde se describen las funciones que realizar el sistema Boehm 1979.

Los requerimientos(necesidades) de proceso se llevan a cabo a travs de siete distintas funciones:

Inicio
Validacin

Especificacin

Obtencin

Negociacin

Gestin

Elaboracin

Inicio
En general, la mayora de los

proyectos se inician cuando se identifica una necesidad de negocios o se descubre un nuevo mercado o servicio potencial. de software hacen una serie de preguntas libres de contexto.
El objetivo es establecer una

Al inicio del proyecto los ingenieros

comprensin bsica del problema, las personas que quieren una solucin, la naturaleza de la solucin que se desea, y la efectividad de la comunicacin preliminar entre el cliente y el desarrollador.

Obtencin
Parece simple decir obtener los requisitos del sistema a crear, mediante preguntas y respuestas a

los clientes sin embargo se presentan los siguientes problemas:

Problemas

de mbito. Detalles tcnicos innecesarios que pueden confundir, en lugar de clarificar, los objetivos generales del sistema. Problemas de comprensin. Los clientes/usuarios no estn seguros por completo de qu es lo que se necesita, comprenden poco, omiten informacin, poca comunicacin de necesidades, especifican requisitos ambiguos o inestables. Problemas de volatilidad. Los problemas cambian con el tiempo.

Para superar estos problemas, los ingenieros de requerimientos deben realizar en forma organizada la recopilacin de requisitos.

Elaboracinel desarrollo de un Esta actividad se enfoca en

modelo de las funciones, caractersticas y restricciones del software. La elaboracin Es una accin del modelado del anlisis
Se describen la forma en que el usuario final

interactan con el sistema.

Se definen los atributos de cada clase de

anlisis y se identifican los servicios que requiere cada clase. se produce una variedad de diagramas de UML complementarios.
El resultado final de la elaboracin es un

modelo de anlisis que define el dominio de la informacin, las funciones y el comportamiento del problema.

Negociacin
A veces los clientes y usuarios piden ms de lo que se puede lograr, es relativamente comn que diferentes cliente o usuarios propongan requisitos que entran en conflicto entre s. Se concilian estos conflictos por medio de la negociacin. Se pide a los clientes que ordenen sus requisitos y despus discutan los conflictos relacionados con la prioridad. Se identifican y analizan los riesgos asociados con cada requisito. Se hacen estimaciones preliminares del esfuerzo requerido para su desarrollo y despus se utilizan para evaluar el impacto de cada requisito en el costo del proyecto y sobre el tiempo de entrega. Mediante un enfoque iterativo, los requisitos se eliminan, combinan o modifican de forma que cada parte alcance cierto grado de satisfaccin. Una negociacin eficaz no debe haber ni ganador ni perdedor. Ambas partes ganan porque se solidifica un trato con el que las dos pueden vivir.

Especificacin
La especificacin es el producto de trabajo final que genera

la ingeniera de requerimientos. Sirve como base para las actividades de ingeniera de software subsecuentes. Describe la funcin y el desempeo de un sistema basado en computadora y las restricciones que regir su desarrollo.

Validacin
La validacin de requerimientos

examina:

la especificacin para asegurar que

todos los requerimientos de software se han establecido de manera precisa. que se han detectado inconsistencias, omisiones y errores y que stos han sido corregidos. que los productos de trabajo cumplen con los estndares establecidos para el proceso, proyecto y producto.

El mecanismo primario para la

validacin de requerimientos es la revisin tcnica formal.

Gestin de requerimientos
La gestin de requerimientos es un conjunto de

actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los equipos y los cambios a stos en cualquier momento mientras se desarrolla el proyecto. La gestin de requisitos comienza con la identificacin. Cada requerimiento se asigna a un solo identificador. Una vez identificados los requisitos se desarrollan las tablas de rastreabilidad

 Entre las tablas de rastreabilidad tenemos las siguientes:

Tabla de rastreabilidad de las caractersticas: Muestra la manera en

que los requerimientos se relacionan con las caractersticas del sistema/producto observables para el cliente. Tabla de rastreabilidad de dependencia: Indica la forma en que los requisitos estn relacionados entre s. Tabla de rastreabilidad del subsistema: Establece categoras entre los requerimientos de acuerdo con los subsistemas que gobiernan. Tabla de rastreabilidad de la interfaz. Muestra la forma en que los requerimientos se relacionan con las interfaces internas y externas del sistema.

Los requerimientos del usuario. Los requerimientos del sistema.

Una especificacin del diseo del

software.

1.2.1 Requerimientos de los usuarios.

Los requerimientos de los usuarios para un sistema describen los requerimientos

funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema que no posean un conocimiento tcnico detallado.

Sin embargo, pueden surgir diversos problemas cuando se redactan en lenguaje natural:
Falta de claridad. Es difcil utilizar el lenguaje en forma

precisa y no ambigua sin detallar el documento y hacerlos fcil de leer. Confusin de requerimientos. No se distinguen claramente los requerimientos funcionales y no funcionales, las metas del sistema y la informacin para el diseo. Conjuncin de requerimientos. Diversos requerimientos diferentes se expresan de forma conjunta como un nico requerimiento.

1.2.2 Actores involucrados.

Dueos del sistema. Usuarios del sistema.
Usuario Interno

Empleados administrativos y de servicios Staff tcnico y profesional Supervisores mandos medios y ejecutivos Usuario Externo Clientes Surtidor o proveedor Socios Empleados

 Diseadores de sistemas.

Administrador de la base de datos. Arquitectos de redes. Arquitectos web. Artistas grficos. Expertos en seguridad. Especialistas en tecnologa.

Constructores de sistemas. Programador de aplicaciones. Programadores de sistemas. Programadores de bases de datos. Administradores de redes. Administradores de seguridad. Webmaster. Integradores de software.
Analistas de sistemas.

1.2.3 Especificacin del diseo de software.

Es una descripcin abstracta del diseo del software que es una base para un diseo e implementacin detallados. Esta especificacin agrega detalle a la especificacin de requerimientos del sistema.

Los requerimientos para el anlisis se

agrupan por categoras y se organizan en sub conjuntos, se estudia cada requerimiento en relacin con el resto, se examinan los requerimientos en su consistencia, completitud y ambigedad, y se clasifican en base a las necesidades de los clientes/usuarios.

1.3.1 Requerimientos para el anlisis.

La mayor parte de los defectos encontrados en el software

entregado se originan durante la obtencin de los requerimientos para el anlisis. En general, estos defectos tambin son los ms caros de reparar.

Para construir algo primero debe entenderse lo que debe ser

algo. El proceso de entender y documentar este algo se llama requerimientos para el anlisis. En general, los requerimientos expresan qu se supone debe hacer una aplicacin: por lo comn, no intentan expresar cmo lograr estas funciones.

 Requerimientos C y requerimientos D. Durante un tiempo se ha discutido quien es el dueo de

los requerimientos: el cliente o el desarrollador. Los anlisis de requerimientos se divide en dos niveles.

Requerimientos del cliente o Requerimientos c (Nivel 1)

documenta los deseos y necesidades del cliente y se expresa en un lenguaje claro para l.

La audiencia primaria para los requerimientos C es la comunidad del cliente y la secundaria es la comunidad del desarrollador.

Requerimientos del desarrollador o Requerimientos D

(Nivel 2) documenta los requerimientos de manera especfica y estructurada.

La audiencia primordial de stos es la comunidad del desarrollador y la secundaria la del cliente.

ERS (IEEE) Introduccin. Descripcin global. Requerimientos especficos. Informacin de apoyo.

Requerimientos C

Requerimientos D

Aunque las audiencias principales para los requerimientos C y D son diferentes, los clientes y desarrolladores trabajan juntos para crear productos exitosos. Una manera de asegurar una buena comunicacin es hacer que representantes de los clientes trabajen junto con los desarrolladores.

 Cada requerimiento debe.

Expresarse de modo adecuado. Ser de acceso sencillo. Numerarse.

Acompaarse con pruebas que lo verifiquen.

Tomarse en cuenta en el diseo. Tomarse en cuenta en el cdigo. Probarse aislado.

Probarse junto con otros requerimientos.

Validarse con las pruebas despus de construir la aplicacin.

mapa conceptual tpico del proceso de requerimientos para el anlisis.

1. Identificar el cliente.

2. Entrevistar representantes del cliente. Identificar deseos y necesidades. Aprovechar herramientas de expresin. Bosquejar las GUI. Identificar el hardware.

Revisin con el cliente

3. Escribir requerimientos C en forma de documento estndar. 4. inspeccionar los requerimientos C. Para todas las etapas, supervisar mtricas por ejemplo: Tiempo indicado. Cantidad lograda. Pginas de requerimientos C. Minutos de interaccin con el cliente por pgina. Calidad autoevaluada (escala 1 a 10). Tasas de defectos en inspecciones. Con la aprobacin del cliente 5. Construir los requerimientos D.

1.3.2 Requerimientos para la negociacin.

En realidad, el cliente y el desarrollador entran en un

proceso de negociacin, en el cual se le debe pedir al cliente un balance de la funcionalidad, el rendimiento y otras caractersticas del sistema o producto frente al costo y el tiempo de colocacin en el mercado. El objetivo de esta negociacin es desarrollar un plan de proyecto que satisfaga las necesidades del cliente al mismo tiempo que refleja las restricciones del mundo real (por ejemplo, tiempo, gente, presupuesto) a las que est sometido el equipo de software.

 Las mejores negociaciones son aquellas que buscan un resultado del

tipo ganar-ganar esto es, el cliente gana al obtener el sistema o producto que satisface la mayora de sus necesidades, y el equipo de software gana al trabajar con presupuestos y lmites de tiempo realistas y alcanzables.
Bohem define un conjunto de actividades de negociacin en el inicio de

cada iteracin del proceso del software. En lugar de la actividad sencilla de comunicacin con el cliente, se definen las siguientes actividades:
1. 2.

3.

Identificacin de los interesados clave en el sistema o subsistema. Determinacin de las Condiciones ganadoras de los interesados. Negociacin de las condiciones ganadoras de los interesados para reconciliarlas en conjunto de condiciones del tipo ganar-ganar para todos los involucrados (incluido el equipo de software).

El arte de la negociacin. El aprendizaje del arte de la negociacin efectiva es una actividad que sirve a travs de la vida tcnica y personal. La consideracin de las siguientes directrices puede resultar muy valiosa: 1Reconocer que no es una competencia. Para ser exitoso, ambos lados deben de tener el sentimiento de haber ganado o logrado algo. Las dos partes tendrn que haber llegado a un acuerdo. 2Disear una estrategia. Decidir qu es lo que se deseara lograr; que es lo que la otra parte quiere alcanzar, y qu es lo que se va a hacer para que ambas cosas sucedan. 3Escuchar de manera activa. no se debe pensar en formular una respuesta mientras la otra parte est hablando. Es necesario escuchar es posible que se obtenga un conocimiento que ayudar a negociar de mejor manera la posicin propia. 4Enfocarse en los intereses de otra parte. Si se quieren evitar los conflictos no se debe de tomar una posicin inflexible. 5No dejar que se vuelva personal. Enfocarse en el problema que debe ser resuelto. 6Ser creativo. Cuando existen situaciones de estancamiento no se debe tener miedo de pensar fuera de los cnones. 7Estar listo para pactar. Una vez que se ha llegado a un acuerdo, no es necesario esperar: se debe pactar dicho convenio y seguir adelante.

La gestin de requisitos es un conjunto de actividades

que ayudan al equipo de trabajo a identificar, controlar y seguir los requisitos y los cambios en cualquier momento. Es esencial planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado. El proceso de gestin de requerimientos debera empezar en cuanto est disponible una versin preliminar del documento de requerimientos.

Dentro del proceso de gestin de requerimientos se establece 2 etapas importantes:

La planificacin de la gestin de requerimientos: La

planificacin es una primera etapa del proceso de gestin de requerimientos. Para cada proyecto la etapa de planificacin establece el nivel de detalle necesario en la gestin de requerimientos.
La identificacin de requerimientos. Cada requerimiento debe

de ser nico de tal forma que pueda ser remitido por otros requerimientos para que pueda utilizarse en las evaluaciones de rastreo. Un proceso de gestin del cambio. Actividades que evalan el impacto y coste de los cambios. Polticas de rastreo. Define las relaciones entre los requerimientos, y el diseo del sistema que se debe registrar y la manera en que estos registros se deben mantener. Ayuda de herramientas CASE. El procesamiento de grandes cantidades de informacin sobre los requerimientos.

 Gestin de cambio de los requerimientos: La ventaja de

utilizar un proceso formal para gestionar el cambio es que todos los cambios propuestos son tratados de forma consistente y que los cambios en el documento de requerimientos se hacen de forma controlada. Existen 3 etapas principales en un proceso de gestin de cambio:
Anlisis del problema y especificacin del cambio. Inicia con la

identificacin de un problema en los requerimientos o con una propuesta de cambio especfica. Durante esta etapa, el problema o la propuesta se analiza para ver que esta es vlida. Anlisis del cambio y clculo de costes. El efecto de un cambio propuesto se valora utilizando la informacin de rastreo y el conocimiento general de los requerimientos del sistema. Coste de hacer un cambio se estima en trminos de modificaciones al documento de requerimientos y, si es apropiado, al diseo e implementacin del sistema. Implementacin del cambio. Se modifica el documento de requerimientos y, en su caso el diseo e implementacin del sistema. Debe organizar el documento de requerimientos de modo que pueda hacer cambios en el sin tener que hacer grandes reorganizaciones o redactar nuevamente gran cantidad del mismo.

Algunos ejemplos por los cuales los requerimientos suelen cambiar pueden ser:
Cambios tecnolgicos.
Porque al analizar el problema, no se

hicieron las preguntas correctas a las personas correctas. Porque cambi el problema que se estaba resolviendo. Porque los usuarios cambiaron su forma de pensar o sus percepciones. Porque cambi el ambiente de negocios

Referencias:

Sommerville Ian, Libro Ingeniera de Software 6 edicin Ed. Pearson Educacin Herrera J. Lizka Johany, Ingenieria de Requerimientos Ingenieria del Software, http://www.monografias.com/trabajos6/resof/resof.shtml

Gomez Gallego Juan Pablo, Resumen de 4 primeros captulos de Engineering Requeriments Handbook (Ralph, R. Young ), Universidad Tecnolgica de Pereira, http://es.scribd.com/doc/270431/Ingenieria-requerimientos guest409adc, Unidad I Procesos de la ingeniera de Requerimientos, http://www.slideshare.net/guest409adc/unidad-i-requerimientos-presentation

Gutierrez Daz Jos Fructuoso, Planificacion y Modelado, Instituto Tecnologico de Pachuca. http://es.scribd.com/doc/64434948/Planificacion-y-Modelado#outer_page_34

Lpez Gonzlez Isis Imelda y Rivera Carrera Amalia Beatriz, Sistema de Control Presupuestal,Instituto Tecnolgico Superior de Misantla, 2009, http://es.scribd.com/doc/52247996/38/Analisis-y-Negociacion-de-Requisitos

Snchez Hernandez Miriam Zulma, Unidad I Planificacion y Modelado, http://es.scribd.com/doc/26752264/PlanificaciOn-y-Modelado-Procesos-de-La-Ingenieria