Anlisis de requisitos Por Lic Adrian Quisbert Vilela
Análisis de requisitos. Por: Lic. Adrian Quisbert Vilela
Introducción. Según vimos en el tema anterior, existen diversos modelos de ciclo de vida para el desarrollo de software, pero en todos ellos se puede observar la existencia de una fase denominada Análisis de requisitos. Entre las tareas que hay que realizar en esta fase están el estudio de las características y la función del sistema, la definición de los requisitos del software y del sistema del que el software forma parte, así como la planificación inicial del proyecto y, posiblemente, algunas tareas relacionadas con el análisis de riesgos.
CONT. Todas estas tareas deben realizarse al comienzo del proyecto, pero el principal problema que se nos presenta es que, en estos momentos iniciales, es difícil tener una idea clara - o, al menos, es difícil llegar a expresarla - de cuáles son los requisitos del sistema y del software, y llegar a comprender en su totalidad la función que el software debe realizar. Por esto, algunos de los modelos de ciclo de vida estudiados proponen enfoques cíclicos de refinamiento de los requisitos o incluso de todo el proceso de desarrollo de software.
CONT. Los requisitos es el primer paso del proceso de ingeniería del software. Es aquí donde se refina la declaración general del ámbito del software en una especificación concreta que se convierte en la base de todas las actividades de ingeniería del software que siguen. Algunos modelos de ciclo de vida distinguen una fase de análisis de requisitos y otra de especificación del sistema. En cualquier caso, el análisis del sistema concluye con la especificación de los requisitos del mismo.
Análisis de requisitos del sistema. El análisis de requisitos del sistema constituye el primer intento de comprender cuál va a ser la función y ámbito de información de un nuevo proyecto. El objetivo es conseguir representar un sistema en su totalidad, incluyendo hardware, software y personas, mostrando la relación entre los diversos componentes y sin entrar en la estructura interna de los mismos. En algunos casos se nos plantearán diferentes posibilidades y tendremos que realizar un estudio de cada una de ellas.
Indudablemente, los esfuerzos realizados en esta fase producen beneficios en las fases posteriores. Sin embargo se nos pueden plantear las siguientes dudas: ¿Cuánto tiempo debe dedicarse al análisis del sistema? ¿Quién debe hacerlo? . ¿Por qué es una tarea tan difícil?
Administración de Requerimientos
Ingenieria de Software Administración de Requerimientos Ingeniería de Requerimientos
Administración de Requerimientos La Ingeniería del Software abarca un conjunto de tres elementos clave: métodos, herramientas y procedimientos, que faciliten al gestor el control el proceso de desarrollo y suministren a los implementadores bases para construir de forma productiva software de alta calidad. Métodos Herramientas Procesos
Administración de Requerimientos Los métodos indican cómo construir técnicamente el software, y abarcan una amplia serie de tareas que incluyen la planificación y estimación de proyectos, el análisis de requisitos, el diseño de estructuras de datos, programas y procedimientos, la codificación, las pruebas y el mantenimiento. Ejemplo: • METODOLOGIA: Ciclo de Vida • METODO : Análisis y Diseño Orienta a Objetos (UML) • METODO : Análisis y Diseño Estructurado
Administración de Requerimientos Las herramientas proporcionan un soporte automático o semiautomático para utilizar los métodos. Existen herramientas automatizadas para cada una de las fases vistas anteriormente, y sistemas que integran las herramientas de cada fase de forma que sirven para todo el proceso de desarrollo. Estas herramientas se denominan CASE (Computer Assisted Software Engineering). Ejemplo: • HERRAMIENTA: Together, ERWIN, Etc.
Administración de Requerimientos Los procedimientos definen la secuencia en que se aplican los métodos, los documentos que se requieren, los controles que permiten asegurar la calidad y las directrices que permiten a los gestores evaluar los progresos. Ejemplo: • Procesos: Casos de Uso, clases, etc. , diagramas de flujos de datos, etc, DETERMINACION DE REQUERIMIENTOS. Standares de Calidad.
Ingenieria de Software Administración de Requerimientos Ingeniería de Requerimientos
Administración de Requerimientos El estudio de mercado The Chaos Report realizado por Standish Group Internactional, Inc en 1996, reportó que sólo un 16% de los proyectos de software son exitosos (terminan dentro de plazos y costos y cumplen los requerimientos acordados). Otro 53 % sobrepasa costos y plazos y cumple parcialmente los requerimientos. El resto ni siquiera llega a término. Fuente: Standish Group Survey, 1999
Administración de Requerimientos En 1995, se estima que las compañías y el gobierno de USA se gastaron 81. 000 millones de dólares en proyectos cancelados. Los proyectos terminados, pero cuyo plazo de ejecución ha sido superior al previsto, supondrán un coste de 59. 000 millones de dólares. Se estima que sólo el 16. 7% de los proyectos software fueron terminados en el plazo y presupuesto previstos. Fuente: Standish Group Survey, 1999
Administración de Requerimientos 1. 2. 3. 4. 5. 6. 7. 8. 24 % Nunca son terminados o utilizables 29% Cancelados 6% concluidos mas de 200% tarde. 16% concluidos 101 -200% tarde. 9% concluidos 51 -100% tarde. 8% concluidos 21 -50% tarde. 6% concluidos menos de 20% tarde. 26% concluidos a tiempo.
Administración de Requerimientos
Administración de Requerimientos “Los resultados muestran que la relación de costos Etapa entre reparar defectos durante la Especific. Requerimientos 1 etapa de 5 Diseño especificación de 10 Codificación requerimientos es 20 Test Unitario 200 veces menor 50 Test Aceptación que hacerlo en la 200 Mantenimiento de mantenimiento, dentro del ciclo de Costo Relativo de Reparación vida del software. ”
AR: Requerimiento (1) Condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. (3) Una representación documentada de una condición o capacidad como en (1) y (2).
AR: Requerimiento Expresan las necesidades del usuario, las reglas del negocio, la disponibilidad de tecnología, características requeridas, diseño, ambiente, especificaciones de hardware, performance, planes de control de calidad, casos de prueba, prototipos, etc.
AR: Requerimiento Ambiente Datos Interfaz Otros Humano Documentación Diseño Lógico Errores de Requerimientos “Los errores de requerimientos son la clase más frecuente de error. ”
AR: Requerimiento ¿Quién, cuándo y con qué documento solicitó este requerimiento? ¿Quién autorizó los cambios? ¿Qué requerimientos críticos no han sido implementados? ¿Cuántos cambios desde la última revisión del cliente? ¿Cuál es el impacto en las pruebas? ¿Cuál es el costo estimado de los cambios propuestos? ¿Podemos agregar una funcionalidad nueva sin aumentar los recursos? ¿Quién cambió la prioridad de este requerimiento? ¿Cuáles requerimientos pueden ser eliminados? Pospuestos? A quién afecta?
AR: Concepto n Proceso sistemático para w encontrar, w organizar, w documentar, w modificar y w rastrear los cambios de requerimientos de una aplicación o sistema.
AR: Requerimientos Son dinámicos, cambian durante la vida de un Proyecto No son obvios, provienen de fuentes diversas Hay diferentes tipos de requerimientos, con distinto nivel de detalle Cantidad inmanejable, si no se controla Relacionamientos entre sí y con otros productos del proceso de software Cada requerimiento tiene propiedades únicas. No son todos igualmente importantes ni igualmente fáciles de alcanzar Muchas partes intervinientes, distintos intereses
AR: Requerimientos Las comunicaciones están basadas en requerimientos bien definidos Los requerimientos pueden ser priorizados, filtrados y monitoreados Es posible realizar evaluaciones objetivas acerca del éxito de un proyecto Las inconsistencias se detectan fácilmente Con herramientas adecuadas: repositorio de requerimientos, con atributos y relaciones
AR: Cómo administrar Requerimientos Seguir la evolución de los requerimientos Asignar responsables de su manejo Rastrear los cambios que se producen Monitorear los cambios Analizar el impacto de los cambios Comunicar los cambios al equipo de desarrollo Relacionar requerimientos en forma jerárquica
Ingeniería de Software Administración de Requerimientos Ingenieria de Requerimientos
Ingeniería de Requerimientos “La ingeniería de requerimientos es un enfoque sistémico para recolectar, organizar y documentar los requerimientos del sistema, es también el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y equipo de proyecto” Relational Software.
IR: Características Verificable: ¿Se puede probar el requerimiento? Comprensible: ¿Se entiende el requerimiento? Trazable: ¿Está claro el origen del requerimiento? Adaptable: ¿Puede cambiarse el requerimiento sin gran impacto en otros requerimientos del sistema? Otras Necesario. Consiso. Completo. Consistente. No ambiguo. Verificable.
IR: Clasificación de Requerimientos Los requerimientos se pueden agrupar por tipo y atributo. Tipo: Requerimientos funcionales, de software, de performance, de testing, etc. Atributos: prioridad, estado, autor, responsable, costo, versión, relación con otros requerimientos.
IR: Importancia n n n Permite gestionar las necesidades del proyecto en forma estructurada. Mejora la capacidad de predecir cronogramas de proyectos. Disminuye los costos y retrasos del proyecto. Mejora la calidad del software. Mejora la comunicación entre equipos. Evita rechazos de usuarios finales.
IR: Proceso Estudio de Viabilidad Análisis de Requerimientos Definición de Informe de Viabilidad Modelo del Sistema Requerimientos Especificación Definición de Documento Requerimientos Especificación Requerimientos
IR: Involucrados
IR: Dificultades
IR: Actividades Análisis del Problema. Evaluación y Negociación. Especificación (SRS). Validación. Evolución.
IR: Análisis del Problema
IR: Evolución y Negociación de Requerimientos
IR: Especificación de Requerimientos (SRS)
IR: Validación de Requisitos
IR: Evolución de los Requerimientos
IEEE: IEEE Std. 830 Práctica recomendada para la la especificación de requerimientos de software. Modelo cuyo resultado, el documento de especificación de software es inequívoco y completo. Para:
IEEE: Referencias Estan en la IEEE Std 610. 12 n n Contrato Cliente Proveedor Usuario
IEEE: Condiseraciones Naturaleza Ambiente Características de un SRS bueno Preparación del SRS Prototipación Plan del SRS Requisitos del proyecto.
Plantilla
- Slides: 44