An

1
Análisis de requisitos.

• Por Lic. Adrian Quisbert Vilela

2
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.

3
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.

4
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.

5
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.

6

• Indudablemente, los esfuerzos realizados en esta
  fase producen beneficios en las fases
  posteriores. Sin embargo se nos pueden plantear
  las siguientes dudasCuánto tiempo debe
  dedicarse al análisis del sistema?
• Quién debe hacerlo?.Por qué es una tarea
  tan difícil?

7
Administración de Requerimientos
8
Ingenieria de Software
Administración de Requerimientos
Ingeniería de Requerimientos
9
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
10
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

11
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

• HERRAMIENTATogether, ERWIN, Etc.

12
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

• ProcesosCasos de Uso, clases, etc., diagramas de
  flujos de datos, etc, DETERMINACION DE
  REQUERIMIENTOS. Standares de Calidad.

13
Ingenieria de Software
Administración de Requerimientos
Ingeniería de Requerimientos
14
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.

FuenteStandish Group Survey, 1999
15
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.

FuenteStandish Group Survey, 1999
16
Administración de Requerimientos

• 1. 24 Nunca son terminados o utilizables
• 2. 29 Cancelados
• 3. 6 concluidos mas de 200 tarde.
• 4. 16 concluidos 101-200 tarde.
• 5. 9 concluidos 51-100 tarde.
• 6. 8 concluidos 21-50 tarde.
• 7. 6 concluidos menos de 20 tarde.
• 8. 26 concluidos a tiempo.

17
Administración de Requerimientos
18
Administración de Requerimientos

• Los resultados muestran que la relación de
  costos entre reparar defectos durante la etapa
  de especificación de requerimientos es 200 veces
  menor que hacerlo en la de mantenimiento, dentro
  del ciclo de vida del software .

19
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).

20
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.

21
AR Requerimiento
Los errores de requerimientos son la clase más
frecuente de error.
22
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?

23
AR Concepto

• Proceso sistemático para
• encontrar,
• organizar,
• documentar,
• modificar y
• rastrear los cambios de requerimientos de una
  aplicación o sistema.

24
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

25
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

26
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

27
Ingeniería de Software
Administración de Requerimientos
Ingenieria de Requerimientos
28
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.

29
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.

30
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.

31
IR Importancia

• 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.

32
IR Proceso
33
IR Involucrados
34
IR Dificultades
35
IR Actividades

• Análisis del Problema.
• Evaluación y Negociación.
• Especificación (SRS).
• Validación.
• Evolución.

36
IR Análisis del Problema
37
IR Evolución y Negociación de Requerimientos
38
IR Especificación de Requerimientos (SRS)
39
IR Validación de Requisitos
40
IR Evolución de los Requerimientos
41
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

42
IEEE Referencias

• Estan en la IEEE Std 610.12
• Contrato
• Cliente
• Proveedor
• Usuario

43
IEEE Condiseraciones

• Naturaleza
• Ambiente
• Características de un SRS bueno
• Preparación del SRS
• Prototipación
• Plan del SRS
• Requisitos del proyecto.

44
Plantilla