• Author / Uploaded
• Danny Torres

Citation preview

LA INGENIERIA DE REQUERIMIENTOS

-Alumno: Escobar Torres, Ricardo D. -Profesores: Prof. Lic. María Del Rosario Zorrilla A., Mg.

Prof. Lic. Juan Benito Torres -Tercer Año Sexto Semestre

1

TABLA DE CONTENIDO

Introducción ................................................................................................................................................. 3 LA INGENIERIA DE REQUERIMIENTOS ............................................................................................... 4 Concepto de Requerimientos ...................................................................................................................... 4 Características de los Requerimientos ....................................................................................................... 4 Dificultades para definir los requerimientos ............................................................................................. 4 Importancia de la Ingeniería de Requerimientos....................................................................................... 4 Personal involucrado en la Ingeniería de Requerimientos ....................................................................... 4 Documentación de requerimientos, tipos .................................................................................................. 4 Especificación de Requisitos de Software (SRS)...................................................................................... 5 Tipos de requisitos ...................................................................................................................................... 5 Validación de Requisitos ............................................................................................................................ 5 Técnicas y herramientas utilizadas en la Ingeniería de Requerimientos, concepto, características. ......... 5 Entrevistas.................................................................................................................................................... 5 Brainstorming .............................................................................................................................................. 6 Casos de Uso ............................................................................................................................................... 6 Prototipos ..................................................................................................................................................... 6 Proceso de Análisis Jerárquico (AHP) ....................................................................................................... 6 Cuadro Comparativo de ventajas y desventajas de cinco técnicas y herramientas utilizadas en la Ingeniería de Requerimientos..........................................................................................................................7 Conclusión ............................................................................................................................................. 8 Bibliografía y Webgrafía ....................................................................................................................... 9

2

Entender los requerimientos de un problema es una de las tareas más difíciles que enfrenta el ingeniero de software. Muchas veces se comete el error de que cuando se empieza por primera vez, se piensa que no parece tan difícil desarrollar un entendimiento claro de los requerimientos. ¿Y por qué no pensar de esa manera? o ¿acaso el cliente no sabe lo que necesita? La respuesta a estas preguntas es que no, en muchas de las ocasiones el cliente no sabe corresponder sus necesidades, y esto dificulta la labor del ingeniero del software. Es tan importante el estudio de la ingeniería del software para realizar un buen sistema de software, debido a que ella es la encargada de validar la calidad del mismo software. Y unos de los campos que abarca esta importante materia es la Ingeniería de Requisitos que es la encargada de establecer lo que el cliente desea de una manera técnica y precisa para los desarrolladores de software. En este proyecto daremos a entender algunos conceptos básicos, pero que nos servirán como fuente de entendimiento para las recolecciones de datos y la documentación de las mismas. Sin más que molestarlos, los invito a leer el contenido del mismo.

3

LA INGENIERIA DE REQUERIMIENTOS

CONCEPTO DE REQUERIMIENTOS Son descripciones de lo que el sistema debe hacer: el servicio que ofrece y las restricciones en su operación. La ingeniería de requerimientos proporciona el mecanismo apropiado para entender lo que desea el cliente.

CARACTERÍSTICAS DE LOS REQUERIMIENTOS Necesario: su omisión provoca una deficiencia en el sistema a construir, y además no pueden ser reemplazados por otras capacidades del producto o del proceso. Conciso: fácil de leer y entender. Completo: no necesita ampliar detalles en su redacción. Consistente: es contradictorio con otro requerimiento. No ambiguo: tiene una sola interpretación. Verificable: puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.

DIFICULTADES PARA DEFINIR LOS REQUERIMIENTOS Problemas de alcance: La frontera de los sistemas está mal definida o los clientes o usuarios finales especifican detalles técnicos innecesarios que confunden. Problemas de entendimiento: Los clientes o usuarios no están completamente seguros de lo que se necesita. Problemas de volatilidad: Los requerimientos cambian con el tiempo.

IMPORTANCIA DE LA INGENIERÍA DE REQUERIMIENTOS La ingeniería de requerimientos establece una base sólida para el diseño y la construcción. Sin ésta, el software resultante tiene alta probabilidad de no satisfacer las necesidades del cliente.

PERSONAL INVOLUCRADO EN LA INGENIERÍA DE REQUERIMIENTOS Un participante es cualquier persona que tenga interés directo o que se beneficie del sistema que se va a desarrollar. Los roles más importantes pueden clasificarse como sigue: Usuario final: Son las personas que usarán el sistema desarrollado. Usuario Líder: Son los individuos que comprenden el ambiente del sistema o el dominio del problema en donde será empleado el software desarrollado. Personal de Mantenimiento: Su trabajo consiste en revisar y mejorar los procesos del producto ya finalizado. Analistas y programadores: Son los responsables del desarrollo del producto en sí. Personal de pruebas: Son quienes van a validar si los requerimientos satisfacen las necesidades del cliente.

DOCUMENTACIÓN DE REQUERIMIENTOS, TIPOS Requerimientos normales: Objetivos y metas que se establecen para un producto o sistema durante las reuniones con el cliente. Ejemplos: tipos de gráficos pedidos para aparecer en la pantalla, funciones específicas del sistema y niveles de rendimiento definidos.

4

Requerimientos esperados: Están implícitos en el producto o sistema y quizá sean tan importantes que el cliente no los mencione de manera explícita. Ejemplos: fácil interacción humano/máquina, operación general correcta y confiable, y facilidad para instalar el software. Requerimientos emocionantes: Estas características van más allá de las expectativas del cliente y son muy satisfactorias si están presentes. Por ejemplo, el software para un nuevo teléfono móvil viene con características estándar, pero si incluye capacidades inesperadas agrada a todos los usuarios del producto.

ESPECIFICACIÓN DE REQUISITOS DE SOFTWARE (SRS) Los requerimientos del sistema son descripciones más detalladas de las funciones, los servicios y las restricciones operacionales del sistema de software. El documento de requerimientos del sistema (llamado en ocasiones especificación funcional) tiene que definir con exactitud lo que se implementará. Puede formar parte del contrato entre el comprador del sistema y los desarrolladores del software.

TIPOS DE REQUISITOS Requerimientos funcionales: Son enunciados acerca de servicios que el sistema debe proveer, de cómo debería reaccionar el sistema a entradas particulares y de cómo debería comportarse el sistema en situaciones específicas. En algunos casos, los requerimientos funcionales también explican lo que no debe hacer el sistema. Requerimientos no funcionales: Son limitaciones sobre servicios o funciones que ofrece el sistema. Incluyen restricciones tanto de temporización y del proceso de desarrollo, como impuestas por los estándares. Los requerimientos no funcionales se suelen aplicar al sistema como un todo, más que a características o a servicios individuales del sistema.

VALIDACIÓN DE REQUISITOS La validación es el proceso que certifica que el modelo de los requerimientos es consistente con las intenciones de los clientes y los usuarios; ésta es una visión más general que el concepto común de validación, pues se produce en paralelo con la elicitación y la especificación, tratando de asegurar que tanto las ideas como los conceptos presentados en una descripción se identifican y explican con claridad La necesidad de validación aparece cuando:  

Se incorpora una nueva pieza de información al modelo actual. Cuando diferentes piezas de información se incorporan en un todo coherente.

TÉCNICAS Y HERRAMIENTAS UTILIZADAS EN LA INGENIERÍA DE REQUERIMIENTOS, CONCEPTO, CARACTERÍSTICAS.

ENTREVISTAS Las entrevistas son la técnica de elicitación más utilizada, y de hecho son prácticamente inevitables en cualquier desarrollo. En las entrevistas se pueden identificar claramente tres fases: preparación, realización y análisis, que se describen a continuación. Preparación de entrevistas Las entrevistas no deben improvisarse, por lo que conviene realizar las siguientes tareas previas:    

Estudiar el dominio del problema: conocer la terminología básica del dominio del problema. Seleccionar a las personas a las que se va a entrevistar: se debe minimizar el número de entrevistas a realizar, por lo que es fundamental seleccionar a las personas a entrevistar. Determinar el objetivo y contenido de las entrevistas: para minimizar el tiempo de la entrevista Planificar las entrevistas

Realización de entrevistas   

Apertura: el entrevistador debe presentarse e informar al entrevistado sobre la razón de la entrevista. Desarrollo: Se deben evitar los monólogos y mantener el control por parte del entrevistador, contemplando la posibilidad de que una tercera persona tome notas durante la entrevista o grabar la entrevista en cinta de vídeo o audio, siempre que el entrevistado esté de acuerdo Terminación: se debe recapitular sobre la entrevista para confirmar que no ha habido confusiones en la información recogida.

5

Análisis de las entrevistas Una vez realizada la entrevista es necesario leer las notas tomadas, pasarlas a limpio, reorganizar la información, contrastarla con otras entrevistas o fuentes de información, etc. Una vez elaborada la información, se puede enviar al entrevistado para confirmar los contenidos. También es importante evaluar la propia entrevista para determinar los aspectos mejorables.

BRAINSTORMING El brainstorming o tormenta de ideas es una técnica de reuniones en grupo cuyo objetivo es la generación de ideas en un ambiente libre de críticas o juicios Las sesiones de brainstorming suelen estar formadas por un número de cuatro a diez participantes, uno de los cuales es el jefe de la sesión, encargado más de comenzar la sesión que de controlarla. Fases del brainstorming En el brainstorming se distinguen las siguientes fases:   



Preparación: la preparación para una sesión de brainstorming requiere que se seleccione a los participantes y al jefe de la sesión, citarlos y preparar la sala donde se llevará a cabo la sesión. Generación: el jefe abre la sesión exponiendo un enunciado general del problema a tratar, que hace de semilla para que se vayan generando ideas. Los participantes aportan libremente nuevas ideas sobre el problema semilla. Consolidación: en esta fase se deben organizar y evaluar las ideas generadas durante la fase anterior. Se suelen seguir tres pasos:  Revisar ideas  Descartar ideas  Priorizar ideas Documentación: después de la sesión, el jefe produce la documentación oportuna conteniendo las ideas priorizadas y comentarios generados durante la consolidación.

CASOS DE USO Los casos de uso son una técnica para la especificación de requerimientos funcionales propuesta inicialmente en y que actualmente forma parte de la propuesta de UML Los actores son personas u otros sistemas que interactúan con el sistema cuyos requerimientos se están describiendo. Un actor puede participar en varios casos de uso y un caso de uso puede estar relacionado con varios actores. Los casos de uso presentan ciertas ventajas sobre la descripción meramente textual de los requerimientos funcionales, ya que facilitan la elicitación de requerimientos y son fácilmente comprensibles por los clientes y usuarios. Además, pueden servir de base a las pruebas del sistema y a la documentación para los usuarios.

PROTOTIPOS Los prototipos permiten al desarrollador crear un modelo del software que debe ser construido. Existen principalmente dos tipos de prototipos: Prototipo rápido: es un mecanismo para lograr la validación pre-compromiso. Se utiliza para validar requerimientos en una etapa previa al diseño específico. . Prototipo evolutivo: Desde una perspectiva diferente, todo el ciclo de vida de un producto puede ser visto como una serie incremental de detallados prototipos acumulativos. Tradicionalmente, el ciclo de vida está dividido en dos fases distintas: desarrollo y mantenimiento. El punto de vista evolutivo del ciclo de vida del software considera a la primera entrega como un prototipo inicial en el campo. Modificaciones y mejoras subsecuentes resultan en nuevas entregas de prototipos más maduros. Este proceso continúa hasta que se haya desarrollado el producto final.

PROCESO DE ANÁLISIS JERÁRQUICO (AHP) Esta técnica tiene por objetivo resolver problemas cuantitativos, para facilitar el pensamiento analítico y las métricas. Consiste en una serie de pasos a saber: Encontrar los requerimientos que van a ser priorizados. 

Combinar los requerimientos en las filas y columnas de la matriz n x n de AHP.

6

   

Hacer algunas comparaciones de los requerimientos en la matriz Sumar las columnas Normalizar la suma de las filas Calcular los promedios

Estos pasos pueden aplicarse fácilmente a una cantidad pequeña de requerimientos, sin embargo, para un volumen grande, esta técnica no es la más adecuada. CUADRO COMPARATIVO DE VENTAJAS Y DESVENTAJAS DE CINCO HERRAMIENTAS UTILIZADAS EN LA INGENIERÍA DE REQUERIMIENTOS Técnica

Ventajas

TÉCNICAS

Y

Desventajas

Mediante ellas se obtiene una gran La información obtenida al cantidad de información correcta a principio puede ser redundante o través del usuario. incompleta. Entrevistas y Cuestionarios

Pueden ser usadas para obtener un pantallazo del dominio del problema. Son flexibles. Permiten combinarse con otras técnicas.

Lluvia de Ideas

Los diferentes puntos de vista y las confusiones en cuento a terminología, son aclarados por expertos.

Si el volumen de información manejado es alto, requiere mucha organización de parte del analista, así como la habilidad para tratar y comprender el comportamiento de todos los involucrados. Es necesaria una buena compenetración del grupo participante.

Ayuda a desarrollar ideas unificadas basadas en la experiencia de un experto. Ayudan a validar y desarrollar nuevos requerimientos. Prototipos

Permite comprender aquellos requerimientos que no estén muy claros y que sean de alta volatilidad.

Permite determinar el grado de importancia de cada requerimiento. Análisis Jerárquico

El cliente puede llegar a pensar que el prototipo es una versión del software que será desarrollado. A menudo, el desarrollador hace compromisos de implementación con el objetivo de acelerar la puesta en funcionamiento del prototipo Debe construirse un estándar claro de evaluación, que incluya la participación del cliente.

Ayuda a identificar conflictos en los requerimientos. Muestra el orden en que deben ser implementados los requerimientos.

Casos de Uso

Representan los requerimientos desde el punto de vista del usuario.

En sistemas grandes, toma mucho tiempo definir todos los casos de uso.

Permiten representar más de un rol para cada afectado.

El análisis de calidad depende de la calidad con que se haya hecho la descripción inicial.

Identifica requerimientos estancados, dentro de un conjunto de requerimientos.

7

Hemos dado a entender que las tareas de la ingeniería de requerimientos se realizan para establecer un fundamento sólido para el diseño y la construcción. La ingeniería de requerimientos ocurre durante las actividades de comunicación y modelado que se hayan definido para el proceso general del software. Pero a pesar de la importancia que tiene la Ingeniería de Requerimientos, ha costado mucho que se le preste la atención adecuada a esta actividad. Aún quedan muchos desafíos que deben ser mejorados, tales como la integración de requerimientos funcionales y no funcionales, la evaluación de especificaciones alternativas, la formalización de la SRS, entre otras. Entonces se concluye que entregar software de calidad, a tiempo y dentro del presupuesto, hará que nuestros clientes confíen y asegurará el crecimiento y madurez de la relación de negocio.

8

Monografás.com. (2010). INGENIERIA DE REQUERIMIENTOS INGENIERÍA DE SOFTWARE. Recuperado el 03 de Octubre de 2015 de http://www.monografias.com/trabajos6/resof/resof.shtml Pressman, Roger S. (2010). INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRÁCTICO (Séptima edición). México. Sedici (2010). INGENIERIA DE REQUERIMIENTOS. Recuperado el 03 de Octubre de 2015 de http://sedici.unlp.edu.ar/bitstream/handle/10915/4057/2__Ingenier%C3%ADa_de_requerimientos.pdf?sequence=4 Sommerville, Ian. (2011). INGENIERÍA DEL SOFTWARE (Novena edición). México.

9