Ensayo ingenieria de requisitos

2,204 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,204
On SlideShare
0
From Embeds
0
Number of Embeds
31
Actions
Shares
0
Downloads
80
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Ensayo ingenieria de requisitos

  1. 1. INSTITUTO TECNOLOGICO DE TUXTEPEC CATEDRATICO: LIC: María de los Ángeles Martínez M. ALUMNO: URIEL TEJEDA GUZMAN ISIDRO LUNA BELTRAN ISMAEL VELASCO MIGUEL CESAR E. ANTONIO PEREZ CHRISTIAN A. GARCIA RAMIREZ MONICA SANCHEZ CRISOSTOMO MATERIA: FUNDAMENTOS DE INGENIERIA DE SOFTWARE TEMA: INGENIERIA DE REQUISITOS GRUPO: “A" ING. SISTEMAS COMPUTACIONALESBLOG: http://djsoftwareyagami.blogspot.mx/ 1
  2. 2. INTRODUCCIONLa ingeniería de requisitos proporciona el mecanismo apropiado para entender loque el cliente quiere, analizar las necesidades, evaluar la posibilidad, negociar unasolución razonable, especificar la solución sin equívocos, certificar la definición ygestionar los requisitos.Los clientes pueden tener una idea vaga de lo que se requiere, tal vez tenganopiniones conflictivas acerca del sistema que se construirá, quizás suconocimiento técnico sea limitado y tenga un tiempo limitado para interactuar conel ingeniero de requisitos. Ninguna de estas situaciones es deseable, pero sonmuy comunes, y el equipo de software con frecuencia se ve obligado a trabajardentro de las condiciones que impone esta situación.La ingeniería de requisitos se lleva a cabo a través de siete funciones: Inicio,obtención, elaboración, negociación, especificación, validación y gestión. Esimportante destacar que algunas de las funciones de la ingeniería de requisitosocurren en paralelo y que todas deben adaptarse a las necesidades del proyecto.Todas están dirigidas a definir lo que el cliente quiere, y todas sirven paraestablecer una base solida respecto del diseño y la construcción de lo queobtendrá el cliente.En las secciones siguientes se examinara los pasos requeridos para iniciar laingeniería de requisitos; es decir para comenzar un proyecto de forma que semantenga en movimiento hacia una solución exitosa. 2
  3. 3. INGENIERÍA DE REQUISITOSA medida que pasan los años, la ingeniería del software ha introducido ypopularizado una serie de estándares para medir y certificar la calidad, tanto delsistema a desarrollar, como del proceso de desarrollo en sí. Se han publicadomuchos libros y artículos relacionados con este tema, con el modelado deprocesos del negocio y la reingeniería. Al mismo tiempo, un número creciente deherramientas automatizadas surgieron para ayudar a definir y aplicar un procesoefectivo para el desarrollo del producto software. Hoy en día la economíaglobalizada depende más de sistemas automatizados que en épocas pasadas;esto ha llevado a los equipos de desarrollo a enfrentarse con nuevos procesos yestándares de calidad. Una de las mayores deficiencias en la práctica deconstrucción del producto software es la poca atención que se presta a ladiscusión del problema. En general los ingenieros de desarrollo se centran en lasolución dejando el problema inexplorado y por ende descrito parcialmente. Unode los resultados más importantes de la aplicación del proceso de ingeniería es laespecificación de un sistema basado en computadora que se describe de maneragenérica en los siguientes niveles: vista global de todo el sistema, vista deldominio, vista del elemento y vista detallada, esta jerarquía está organizada demanera deductiva: de lo general a lo particular.Ingeniería de Requisitos, es el proceso de desarrollar una especificación deSoftware. Las especificaciones pretenden comunicar las necesidades del sistemadel cliente a los desarrolladores del sistema. Trata de los principios, métodos,técnicas y herramientas que permiten descubrir, documentar y mantener losrequisitos para sistemas basados en computadora, de forma sistemática yrepetible.Los principales beneficios de la Ingeniería de Requisitos son:* Permite gestionar las necesidades del proyecto en forma estructurada: Cadaactividad de la Ingeniería de Requisitos consiste de una serie de pasosorganizados y bien definidos. 3
  4. 4. * Mejora la capacidad de predecir cronogramas de proyectos, así como susresultados: La Ingeniería de Requisitos proporciona un punto de partida paracontroles subsecuentes y actividades de mantenimiento, tales como estimación decostos, tiempo y recursos necesarios.* Disminuye los costos y retrasos del proyecto: Muchos estudios han demostradoque reparar errores por un mal desarrollo no descubierto a tiempo, es sumamentecaro; especialmente aquellas decisiones tomadas durante la Especificación deRequisitos.* Mejora la calidad del software: La calidad en el software tiene que ver concumplir un conjunto de requisitos (Funcionalidad, Facilidad de Uso, Confiabilidad,Desempeño, etc.).* Mejora la comunicación entre equipos: La especificación de requisitos representauna forma de consenso entre clientes y desarrolladores. Si este consenso noocurre, el proyecto no será exitoso.* Evita rechazos de usuarios finales: La Ingeniería de Requisitos obliga al cliente aconsiderar sus requisitos cuidadosamente y revisarlos dentro del marco delproblema, por lo que se le involucra durante todo el desarrollo del proyecto.INICIO¿Cómo se inicia un proyecto de software? En algunos casos una conversacióninformal es todo lo que se necesita para precipitar un esfuerzo importante deingenieros del software. Pero en general. La mayoría de los proyectos comienzacuando se identifica una necesidad de negocios o se descubre un nuevo mercadoo servicio potencial. Los participantes de la comunidad de negocios (es decir, los 4
  5. 5. gerentes gente de mercadotecnia, gerentes del producto) definen un caso denegocios para la idea, tratan de identificar la amplitud y profundidad del mercado,hacen un análisis preliminar de factibilidad, e identifican una descripción funcionaldel ámbito del proyecto. Toda esta información está sujeta a cambios (unasituación probable), pero es suficiente para suscitar conversaciones con laorganización de ingeniería de software.Al inicio del proyecto los ingenieros de software hacen una serie de preguntaslibres de contexto. El objetivo es establecer una comprensión básica del problema,las personas que quieran una solución que se desea, y la efectividad de lacomunicación preliminar entre el cliente y el desarrollador.¿Cómo se inicia un proyecto de software? ¿Es un evento aislado que se convierteen el catalizador para un nuevo sistema o producto basado en computadora? ¿Ola necesidad evolucionada con el tiempo? No existen respuestas definitivas paraestas preguntas.En algunos casos, una conversación informal es todo lo que se necesita paraprecipitar un esfuerzo importante de ingeniería de ingeniería del software. Pero engeneral, la mayoría de los proyectos comienza cuando se identifica una necesidadde negocios o se descubre un nuevo mercado o servicio potencial. Losparticipantes de la comunidad de negocios (es decir, los gerentes, gente demercadotécnica, gerentes de producto) definen un caso de negocios para la idea,tratan de identificar la amplitud y profundidad del mercado, hacen un análisispreliminar de factibilidad,e identifican una descripción funcional del ámbito del proyecto. Toda estainformación esta sujetada a cambios (una situación probable), pero es suficientepara suscitar conversaciones con la organización de ingeniería del software.Al inicio del proyecto los ingenieros de software hacen una serie de preguntaslibres de contexto, las cuales se exponen en la sección 7.3.4. El objetivo esestablecer una comprensión básica del problema, las personas que quieren una 5
  6. 6. solución, la naturaleza de la solución que se desea, y la efectividad de lacomunicación preliminar entre el cliente y el desarrollador.OBTENCIONParece muy simple preguntarle al cliente, a los usuarios y otros interesados cualesson los objetivos para el sistema o producto, que es lo que se debe lograr, de queforma el producto satisface las necesidades del negocio y por último como seutiliza el sistema o producto día a día. Pero no es simple es muy difícil.Christel y kang identifican una serie de problemas que ayudan a entender porquees difícil la obtención de requisitos:Problemas de ámbito. El límite del sistema está mal definido o losclientes/usuarios especifican detalles innecesarios que pueden confundir, en lugarde clarificar los objetivos generales del sistema.Problemas de comprensión. Los clientes/usuarios no están seguros porcompleto de que es lo que se necesita, comprenden poco acerca de lascapacidades y limitaciones de su ambiente de computo, no comprenden del todoel dominio del problema, tienen dificultades al comunicar necesidades al ingenierode sistemas, omiten información que consideran “obvia”, especifican requisitosque chocan con las necesidades de oros clientes/usuarios, o especificanrequisitos ambiguos o inestablesProblemas de volatilidad. Los problemas cambian conforme transcurre el tiempo.Para ayudar a superar estos problemas, los ingenieros de requisitos debenrealizar en forma organizada la actividad de recopilación de requisitos. 6
  7. 7. ELABORACIONLa información conseguida con el cliente durante el inicio y la obtención seexpanden y se refinan durante la elaboración. Esta actividad de la ingeniería derequisitos se enfoca en el desarrollo de un modelo técnico refinado de lasfunciones, características y restricciones del software.La elaboración es una acción del modelado del análisis y se compone de una seriede tareas de modelado y refinamiento. La elaboración se conduce mediante lacreación y el refinamiento de escenarios del usuario que describen la forma enque el usuario final (y otros actores) interactúan con el sistema. Cada escenariodel usuario se analiza para obtener clases de análisis: entidades del dominio denegocios visibles para el usuario final. Se definen los atributos de cada clase deanálisis y se identifican los servicios que requiere cada clase. Se identifican lasrelaciones y la colaboración entre las clases y se produce una variedad dediagramas de UML complementarios.El resultado final de la elaboración es un modelo de análisis que define el dominiode la información, las funciones y el comportamiento del problema.También es relativamente común que diferentes clientes o usuarios proponganrequerimientos que entran en conflicto entre sí al argumentar que su versión es“esencial para las necesidades especiales del cliente”. El ingeniero derequerimientos debe conciliar estos conflictos por medio de un proceso denegociación. Se pide a los clientes, usuarios y otros interesados que ordenen susrequerimientos y después discutan los conflictos relacionados con la prioridad. Seidentifican y analizan los riesgos asociados con cada requerimiento. Se hacen“estimaciones” preliminares del esfuerzo requerido para su desarrollo y despuésse utilizan para evaluar el impacto de cada requerimiento en el costo del proyectoy sobre el tiempo de entrega.Mediante un enfoque iterativo, los requerimientos se eliminan, combinan omodifican de forma que cada parte alcance cierto grado de satisfacción. Una 7
  8. 8. especificación puede ser un documento escrito, un conjunto de modelos gráficos,un modelo matemático formal, una colección de escenarios de uso, un prototipo ocualquier combinación de éstos. La especificación es el producto de trabajo finalque genera la ingeniería de requerimientos. Sirve como base para las actividadesde ingeniería del software subsecuentes. Describe la función y el desempeño deun sistema basado en computadora y las restricciones que regirán su desarrollo.La calidad de los productos de trabajo procedentes de la ingeniería de requisitosse evalúa durante el proceso de validación. La validación de requisitos examina laespecificación para asegurar que todos los requisitos del software se hanestablecido de manera precisa; que se han detectado las inconsistencias,omisiones y errores y que éstos han sido corregidos, y que los productos detrabajo cumplen con los estándares establecidos para el proceso, proyecto yproducto. La función de gestión de los requerimientos es un conjunto deactividades que ayudan al equipo del proyecto a identificar, controlar y rastrear losrequisitos y los cambios a estos en cualquier momento mientras se desarrolla elproyecto. Muchas de estas actividades son idénticas a las actividades de lagestión de la configuración del software.NEGOCIACIONDados los recursos limitados del negocio, no resulta inusual que los clientes yusuarios pidan más de lo que se puede lograr. También es relativamente comúnque diferentes clientes o usuarios propongan requisitos que entran en conflictoentre sí al argumentar que se versión es “esencial para nuestras necesidadesespeciales”.El ingeniero de requisitos debe conciliar estos conflictos por medio de un procesode negociación. Se pide a los clientes, usuarios y otros interesados que ordenensus requisitos y después discutan los conflictos relacionados con la prioridad. Seidentifican y analizan los riesgos asociados con cada requisito. Se hacenestimaciones preliminares del esfuerzo requerido para su desarrollo y después se 8
  9. 9. utilizan para evaluar el impacto de cada requisito en el costo del proyecto y sobreel tiempo de entrega. Mediante un enfoque iterativo, los requisitos se eliminan,combinan o modifican de forma que cada parte alcance cierto grado desatisfacción.ESPECIFICACIÓNEn los contextos de los sistemas basado en computadora y en software, el terminoespecificación, tiene significados diferentes para personas distintas unaespecificación puede ser un documento escrito, un conjunto de modelos gráficosun modelo matemático formal, una colección de escenarios de uso, un prototipo ocualquier combinación de estosAlgunos sugieren que para un especificación se debe desarrollar y utilizar unaplantilla estándar de zum 97 argumentan que esto conduce que los requisitossean presentados de una manera más consciente y por ende mas entendible sinembargo algunas veces es necesario ser flexible mientras se desarrolla un aespecificación. Respecto de sistemas grandes el mejor enfoque podría ser undocumento escrito que combinara descripciones en el lenguaje natural y modelosgráficos, por otro lado en cuando a productos o sistemas más pequeños , podríaser que no se necesite mas que escenarios de uso cuando dichos sistemasresidan en ambientes técnicos que e comprendan bien, la especificación es elproducto de trabajo final que genera la ingeniería de requisitos, sirve como basepara las actividades de ingeniería de software subsecuentes.Describe la función y el desempeño de un sistema basado en computadora y lasrestricciones que giran su desarrollo. 9
  10. 10. VALIDACIONL a calidad de los producto de trabajos procedentes de la ingeniería de requisitosse evalúa durante un paso de validación, la validación de requisitos examina laespecificación para asegurar que todos los requisitos de software, se hanestablecido de manera precisa; que se han detectado las inconsistencias,omisiones y errores y que estos has sido corregidos, y que los productos detrabajo cumplen con los estándares establecidos para el procesos, proyecto yproducto.El mecanismo primario para la validación de requisitos es la revisión técnicaformal...El equipo de revisión que valida los requisitos incluye ingenieros desoftware, clientes, usuarios y otros interesados que examinan la especificación ybuscan errores en el contenido o la interpretación, áreas que tal vez requieran unaclasificación, información faltante, inconsistencias (que es un problema importantecuando se desarrollan sistemas o productos grandes), conflictos entre losrequisitos, o requisitos irreales (inalcanzables).A continuación se presenta un alista de verificación para la validación derequisitos;¿Los requisitos están establecidos de manera clara?¿Estos pueden malinterpretarse?¿La fuente de requisitos (ejemplos, un apersona una regulación o un reglamento)¿El requisito está restringido en términos cuantitativos?¿Cuales otros requisitos están relacionados con este?¿El requisito viola alguna restricción del dominio del sistema?¿El requisito se puede probar?¿Se ha creado algún índice para la especificación? 10
  11. 11. Validez: el sistema provee las funciones que soporta mejor las necesidades delcliente.Consistencia: no existen conflictos entre los requisitos.Completitud: están incluidas todas las funciones requeridas por el usuario.Realismo: los requisitos pueden ser implementados con el presupuesto ytecnologías disponibles.Verificable: los requisitos pueden ser verificados.Validación- revisionesTécnicas de validación de requisitosRevisiones (inspecciones)Un grupo de personas lee, analiza y discute el documento de ERS y las formas desolucionar los problemas detectados.Deben participar representantes del cliente y los usuarios.Las inspecciones pueden ser formales (documento concluido) o informales.Validacion – revisionesSe pueden usar listas de comprobación:Unicidad; esta cada requisito identificado de forma univocaComprensibilidad; se describen en el glosario los términos especializados otécnicos.Hay contradicciones.Están agrupados los requisitos relacionados.Trazabilidad; está establecido adecuadamente el origen de cada requisito. 11
  12. 12. Adaptabilidad; puede cambiarse un requisito sin impactar demasiado a los otros.Validación – prototipoPrototipos; si se desarrollo durante la e licitación de sigue con su desarrollo enesta fase. Selección de encargado de pruebas de prototipo Desarrollo de los escenarios de prueba Ejecución de los escenarios Documentación de problemasEscribir el manual de usuario fuerza a un análisis detallado de los requisitos y asírevelarse nuevos problemas.GESTIONLa gestión de requisitos es u conjuntó de actividades que ayudan al equipo deproyecto a identificar, controlar y rastrear los requisitos y los cambios a estos encualquier momento mientras se desarrolla el proyecto. Muchas de estasactividades son idénticas a las actividades de la gestión de la configuración delsoftware (GCS).La gestión de requisitos comienza con la identificación, cada requerimiento seasigna a un solo identificador, una vez identificados los requerimientos sedesarrollan las tablas de rastreabilidad.Entre las muchas tablas de rastreabilidad posibles están las siguientes; 12
  13. 13. TABLA DE RASTREABILIDAD DE LA SCARACTERISTICAS; muestra la maneraen que los requisitos se relacionan con las características del sistemas/productoobservables para el cliente.TABLA DE RASTREABILIDAD DE LA FUENTE; identifica la fuente de cadarequisitoTABLA DE RASTREABILIDAD DE DEPENDENCIA; indica la forma en que losrequisitos están relacionados entre si:TABLA D ERASTREABILIDAD DE SUBSISTEMA; establece categorías entre losrequisitos de acuerdo con los subsistemas que gobiernan.TABLA D ERASTREABILIDAD DE LA INTERFAZ; muestra la forma en que lorequisitos se relacionan con la interfaces internas y externas del sistema.En muchos casos estas tablas de rastreabilidad se mantienen como parte de labase de datos de los requisitos de forma que pueda buscárseles con rapidez paraentender como el cambio en un requisito afectara diferentes aspectos del sistemaque se construiráGestión de requisitos;Los requisitos cambian: cambios en la estrategia y prioridades del negocioCambios tecnológicosCambios en leyes o regulaciones.La gestión de requisitos consiste en gestionar los cambios en los requisitosacordados, las relaciones entre requisitos, las dependencias entre el documentoERS y otros documentos.Mas del 50% de los requisitos suelen cambiar durante la elaboración del ERS ydespués, durante el desarrollo del software. 13
  14. 14. Comprensión inicial del problema Requisitos iníciales Comprensión cambiada del problema Requisitos cambiadosLa gestión de requisitos implica la recolección, almacenamiento y mantenimientode grandes cantidades de información.Para ello existen herramientas CASE con; Base de datos para almacenar requisitos Facilidades de análisis y generación de documentos Facilidades de gestión de cambios Facilidad de trazabilidadAlgunos requisitos cambian más que otros.Requisitos estables; esencia los sistemas y su dominio de aplicaciónRequisitos volátiles; Específicos del sistema en un entorno particular para un cliente particular Las causas del cambio son variadas;Es importante poder identificar y almacenar los requisitos;Identificación de requisitos: Asignación no ambigua de identificadores Remuneración dinámica, identificación de registros de BD, Identificación simbólica. 14
  15. 15. Almacenamiento de requisitos: Se debe facilitar acceso rápido y en relación con los otros sistemas Documentos o BDGestión de los cambio; Identificación de los cambios Análisis del cambio Implementación del cambioGestión de requisitos – atributosPara una correcta gestión de los requisitos es necesario registrar diversosatributos para cada uno: ID único Especificación Clasificaciones según criterios establecidos Método de verificación Plan de aceptación Resumen Origen Historia de cambiosGestión de requisitos – trazabilidadLa trazabilidad de los requisitos consiste en poder recuperar el origen o predecir loefectos de los requisitos.Es fundamental para analizar el impacto de un cambio en los requisitos. 15
  16. 16. La trazabilidad de un requisito tiene dos direcciones;  Hacia atrás; para conocer los requisitos de un usuario e interesados que lo motivaron  Hacia adelante; para identificar los requisitos y entidades de diseño que lo satisfacen. 16
  17. 17. CONCLUSIONEn esta investigación se presentaron una serie de actividades y técnicas, que nopertenecen a un modelo de proceso en sí, sino, que son una alternativa al materialpublicado por diferentes autores y que, se consideraron como los másimportantes.Se debe recordar que la ingeniería de requisitos es una actividad que involucra aclientes, usuarios, equipo de desarrollo, administradores de proyectos, etc., por lotanto el proceso de ingeniería de requisitos no depende solamente de la formacomo se percibe el problema sino también del nivel de experiencia que tengan losinvolucrados.REFERENCIAS:Senn, james A. “análisis y diseño de sistemas de información”. McGraw Hill.Ortas, A. “aproximación a la ingeniería de requerimientos”.http://es.scribd.com/doc/27182020/Ingenieria-de-Software-Un-Enfoque-Practico-6th-edicion-Roger-pressman-1 17

×