El Proceso De Software: Requerimientos

Presentación del tema: "El Proceso De Software: Requerimientos"— Transcripción de la presentación:

1 El Proceso De Software: Requerimientos
Lic. César Alcántara Loayza

2 Ciclo de Vida Mas información sobre ciclo de vida ver: SEI Interactive,   Features/1999/March/Background/Background.mar99.htm

3 Antecedentes Los reportes CHAOS del Standish Group desde 1994 y 1997 establecieron que lo que contribuye mas a las fallas en los proyectos están relacionados con los requerimientos. En Diciembre de 1997, El diario Computer Industry reportó sobre un estudio de Sequent Computer Systems, Inc. De cerca de 500 Gerentes de IT en los U.S. Y U.K. En los que el 76 por ciento habian experimentado fallas en los proyectos. La causa mas frecuente fue “requerimientos cambiantes del usuario."

4 Requerimiento Un requerimiento de software se puede definir como: una capacidad del software necesaria para que el usuario resuelva un problema o alcance un objetivo. Una capacidad de software debe ser encontrada o poseida por un sistema o componente de sistema para satisfacer un contrato, especificación, estandar u otra documentación formalmente impuesta. “una condición o capacidad que el sistema [en construcción] debe satisfacer“.

5 Gestión de Requerimientos
La Gestión de requerimientos es: Un forma sistemática de obtener, organizar y documentar los requerimientos de un sistema. Un proceso que establece y mantiene un acuerdo entre el cliente y el equipo de proyecto acerca de los cambios de requerimientos del sistema.

6 Gestión de requerimientos
Mejorar el control de proyectos complejos Mejorar la calidad del software y la satisfacción del cliente. Saber que debe construir y probar. Reduce los costos y demoras del proyecto. Mejora la comunicación del equipo.

7 Gestión de requerimientos
Es frecuentemente dificil decir como hace el sistema lo que se supone debe hacer. Esta dificultad se debe a la falta de un hilo visible y consistente a lo largo del sistema cuando ejecuta sus tareas. En el proceso unificado los casos de uso proporcionan aquel hilo (thread) definiendo el comportamiento que llevará a cabo el sistema.

8 Flujo de trabajo de Requerimientos

9 Problemas Requerimientos
Una lista de problemas relacionada con la gestión de los requerimientos: Los requerimientos no siempre son obvios y provienen de muchas fuentes. Los requerimientos no son siempre fáciles de expresar claramente con palabras. Existe muchos tipos diferentes de requerimientos en diferentes niveles de detalle. El número de requerimientos puede ser inmanejable si no es controlado.

10 Problemas Requerimientos
Los requerimientos están relacionados entre si, y con otros entregables del proceso en una variedad de formas. Los requerimientos tienen propiedad únicas o valores propios. Por ejemplo, ellos no son igualmente importantes tampoco igual de fáciles de hallar. Existen muchas partes interesadas y responsables, lo que significa que los requerimientos necesitan ser manejados por grupos de personas ínter funcionales. Los requerimientos cambian. Los requerimientos son sensibles al tiempo.

11 Analizar El Problema

12 Analizar El Problema Capturar un Vocabulario común.
Desarrollar la visión. Encontrar actores y casos de uso. Desarrollar un plan para la gestión de requerimientos.

13 Productos de las actividades
Glosario Visión Modelo de casos de uso Plan para la gestión de requerimientos. Atributos de los requerimientos

14 Flujo de trabajo El propósito del este flujo de trabajo es:
Obtener un acuerdo sobre el problema que se está resolviendo, Identificar a los stakeholders, Definir los límites del sistema, y Identificar restricciones impuestas sobre el sistema.

15 Flujo de trabajo El conjunto de Artefactos de Requerimientos captura y presenta información usada en la definición de las capacidades requeridas del sistema.

16 Comprender Necesidades De Los Stakeholders

17 Flujo de actividades Capturar un vocabulario común
Desarrollar la visión Obtener los requerimientos del stackeholder. Encontrar actores y casos de uso. Manejar dependencias. Revisar los cambios requeridos.

18 Productos de las actividades
Glosario Visión Requisitos de los stackeholders Modelo de casos de uso Especificaciones suplementarias Atributos de los requerimientos

19 Definir El Sistema

20 Flujo de actividades Desarrollar la visión
Capturar un vocabulario común Encontrar actores y casos de uso Manejar dependencias

21 Productos del trabajo Glosario Modelo de casos de uso
Especificaciones suplementarias Atributos de los requerimientos

22 Manejar Alcance Del Sistema

23 Flujo de Actividades Desarrollar la visión Manejar las dependencias
Priorizar los casos de uso Revisar los cambios solicitados

24 Productos del trabajo Visión Atributos de los requerimientos

25 Refinar Definición Del Sistema

26 Flujo de actividades Detallar cada caso de uso
Detallar los requerimientos de SW Modelar las interfaces del usuario Prototipear las interfaces del usuario

27 Productos del trabajo Especificaciones suplementarias Casos de uso
Especificación de los requerimientos de software Storybard del caso de uso Prototipo de interfases de usuario Atributos de requerimientos

28 Manejo De Cambios En Los Requerimientos

29 Flujo de actividades Manejar dependencias
Revisar solicitudes de cambio Revisar los requerimientos Estructurar el modelo de casos de uso Registro de la revisión

30 Productos del trabajo Modelo de casos de uso
Atributos de requerimientos

31 Técnica Gestión de Requerimientos
Analizar el problema Obtener un acuerdo sobre el problema a ser resuelto. Identificar los stackeholders. Definir los límites del sistema. Identicar restricciones a imponerse sobre el sistema. Comprender las necesidades del Stakeholder. Fuentes : Clientes, socios, usuarios finales, expertos del dominio, entre otros.

32 Técnica Gestión de Requerimientos
Es importante saber como determinar cuales deberian ser las fuentes, como tener acceso y como obtener información de ellas. Los individuos que sirven como fuente primaria de esta información son los llamados "stakeholders" en el proyecto. Las técnicas para obtener requerimientos incluyen entrevistas, tormenta de ideas, prototipeo conceptual, cuestionarios, y análisis competitivo. El resultado de obtener requerimientos es una lista de requisitos o necesidades que son descritos textual o gráficamente y que tienen prioridades relativas entre si.

33 Técnica Gestión de Requerimientos
Definir el sistema Significa traducir y organizar las necesidades comprendidas del stakeholder en una descripción significativa del sistema a desarrollar. El resultado de la definición del sistema es una descripción del sistema tanto en lenguaje natural como gráfico.

34 Técnica Gestión de Requerimientos
Manejar el alcance del sistema. El alcance de un proyecto esta definido por conjunto de requerimientos asignados a el. Manejando el alcance del proyecto fijamos los recursos disponibles (tiempo, personas y dinero) Es una actividad continua. Usando los atributos de los requerimientos, tales como prioridad, esfuerzo, y riesgo, como base para negociar la inclusión de un requerimiento es una técnica particularmente útil para gestional el alcance.

35 Técnica Gestión de Requerimientos
Refinar la definición del sistema. Inluye dos consideraciones clave: desarrollar una descripción mas detallada de la definición del alto nivel del sistema, y verificar que el sistema cumple con las necesidades del stakeholder y se comporta como está descrito.

36 Técnica Gestión de Requerimientos
Manejar el cambio de requerimientos. Independientemente de cuan cuidadosamente maneje sus requerimientos, ellos cambian. El cambio no es el enemigo, el cambio no gestionado si lo es. Establecer una base de inicio, mantener la pista histórica de cada requerimiento, determinar cuales dependencias son importantes seguir (trazar), establecer vínculos de trazabilidad entre items relacionados y mantener el control de versiones.

37 Conceptos G. requerimientos
Tipos de requerimientos Identificando los tipos de requerimientos, el equipo puede organizar un gran número de requerimientos en grupos significativos y mas manejables. Usualmente, un tipo de requerimiento puede ser partido, o descompuesto en otros tipos. Las reglas del negocio y las declaraciones de visión pueden ser tipos de requerimientos de alto nivel de los cuales se deriven los tipos de requerimiento de necesidades del usuario, de características y de producto.

38 Conceptos G. Requerimientos
Equipos Interfuncionales

39 Conceptos G. Requerimientos
Atributos multidimensionales Cada tipo de requerimiento tiene atributos, y cada requerimiento individual tiene diferentes valores de atributo. Por ejemplo, a los requerimientos pueden asignarsele prioridades, identificarse por la fuente y la lógica, delegarse a equipos especificos dentro de un área funcional, dar una denominación del grado de dificultad, o estar asociado con una iteración particular del sistema.

40 Conceptos G. Requerimientos
En tipos de requerimientos mas detallados, los atributos de prioridad y esfuerzo pueden tener valores más específicos (e.g., tiempo estimado, lineas de código, etc.) con los cuales refinas mas el alcance. Historia de cambios A medida que los requerimientos evolucionan, es importante entender su historia: que ha cambiado, porque, cuando, y aún cual autorización.

41 Requerimientos Para facilitar su manejo se debería hacer:
Acordar un vocabulario común para el proyecto. Desarrollar una visión del sistema que describa el problema a ser resuelto, asi como sus características principales. Obtener las necesidades de los stakeholders en al menos cinco areas importantes: funcionalidad, facilidad de uso, confiabilidad, rendimiento, y soporte. Determinar que tipo de requerimientos usar. Seleccionar los atributos y valores para cada tipo de requerimiento.

42 Requerimientos Escoger los formatos en los que se describirán los requerimientos. Identificar a los miembros del equipo que serán los autores, contribuyentes, o simples revisores de uno o mas tipos de requerimientos. Establecer un procedimiento para proponer, revisar y resolver cambios en el requerimiento. Desarrollar un mecanismo para registrar las historia del requerimiento. Crear reportes de avance y situación para los miembros del equipo y la gerencia.

43 Requerimientos FURPS+
Existen muchas clases diferentes de requerimientos. Una forma de categorizar es descrita por el modelo FURPS+, Utilizando el acrónimo FURPS para describir las categorías principales de requerimientos con subcategorías como se muestra: Funcionality (funcionalidad) Usability (Facilidad de uso) Reliability (Confiabilidad) Performance, (Rendimiento) y Supportability (Soporte)

44 Requerimientos FURP+ El "+" en FURPS+ le ayuda a recordar que también incluye otros requerimientos como: Restricciones de diseño, Requerimientos de implementación, Requerimientos de interface y Requerimientos físicos.

45 Requerimientos FURPS+
Los Requerimientos Funcionales especifican acciones que un sistema debe ser capaz de ejecutar, sin considerar restricciones físicas. Estos se describen frecuentemente en un modelo de casos de uso y en los casos de uso. Los requerimientos funcionales especifican de esta forma el comportamiento de entrada y salida de un sistema.

46 Requerimientos FURPS+
Los requerimientos funcionales pueden incluir: Conjuntos de características, Capacidades, y Seguridad.

47 Requerimientos FURPS+
Facilidad de Uso (Usability) Puede incluir categorías como : Factores de tipo humano, Ergonómicos y estéticos, Consistencia en las interfaces de usuario, y Materiales de entrenamiento y documentación del usuario. Ayudas sensitivas al contexto y en línea. Asistentes.

48 Requerimientos FURPS+
Confiabilidad (Reliability) que se pueden considerar: Frecuencia / severidad de fallas, Recuperabilidad, Predictibilidad, Exactitud y Tiempo medio entre fallas (MTBF).

49 Requerimientos FURPS+
Performance Un requerimiento de rendimiento impone condiciones sobre los requerimientos funcionales. Por ejemplo, para una acción dada, pueden haber parámetros de rendimiento: Velocidad Eficiencia, Disponibilidad, Exactitud, Throughput, Tiempo de respuesta, Tiempo de recuperación, o Utilización de recursos

50 Requerimientos FURPS+
Soporte puede incluir: Sujeto a prueba, Que se pueda extender, Que se pueda adaptar, Que se pueda mantener, Que sea compatible, Que sea configurable, Que se pueda aplicar servicio, Que sea instalable, o Que se pueda localizar (internacionalizar)

51 Requerimientos FURPS+
El + indica: Restricciones de diseño Requerimientos de implementación: Estandares necesarios. Lenguajes de implementación. Políticas de integridad de datos. Ambientes operacionales

52 Requerimientos FURPS+
Requerimientos de intefaz especifican Un item externo con el cual el sistema debe interactuar. Restricciones en el formato, tiempos y otros factores, usados en la interacción.

53 Requerimientos FURPS+
Requerimientos físicos – especifica requerimientos de hardware (redes) Formas Tamaños Pesos Material

54 Tabla de Requerimientos