Sesion 3 0 proceso sw requerimientos

1,429 views

Published on

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

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

No notes for slide

Sesion 3 0 proceso sw requerimientos

  1. 1. El Proceso De Software: Requerimientos Lic. César Alcántara Loayza
  2. 2. Ciclo de Vida Mas información sobre ciclo de vida ver: SEI Interactive, http://www.sei.cmu.edu/interactive/ Features/1999/March/Background/Background.mar99.htmCAL/ProcesoSW_Requerimientos
  3. 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."CAL/ProcesoSW_Requerimientos
  4. 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“.CAL/ProcesoSW_Requerimientos
  5. 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.CAL/ProcesoSW_Requerimientos
  6. 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.CAL/ProcesoSW_Requerimientos
  7. 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.CAL/ProcesoSW_Requerimientos
  8. 8. Flujo de trabajo de RequerimientosCAL/ProcesoSW_Requerimientos
  9. 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.CAL/ProcesoSW_Requerimientos
  10. 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.CAL/ProcesoSW_Requerimientos
  11. 11. Analizar El ProblemaCAL/ProcesoSW_Requerimientos
  12. 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.CAL/ProcesoSW_Requerimientos
  13. 13. Productos de las actividades  Glosario  Visión  Modelo de casos de uso  Plan para la gestión de requerimientos.  Atributos de los requerimientosCAL/ProcesoSW_Requerimientos
  14. 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.CAL/ProcesoSW_Requerimientos
  15. 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.CAL/ProcesoSW_Requerimientos
  16. 16. Comprender Necesidades De Los StakeholdersCAL/ProcesoSW_Requerimientos
  17. 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.CAL/ProcesoSW_Requerimientos
  18. 18. Productos de las actividades  Glosario  Visión  Requisitos de los stackeholders  Modelo de casos de uso  Especificaciones suplementarias  Atributos de los requerimientosCAL/ProcesoSW_Requerimientos
  19. 19. Definir El SistemaCAL/ProcesoSW_Requerimientos
  20. 20. Flujo de actividades  Desarrollar la visión  Capturar un vocabulario común  Encontrar actores y casos de uso  Manejar dependenciasCAL/ProcesoSW_Requerimientos
  21. 21. Productos del trabajo  Glosario  Modelo de casos de uso  Especificaciones suplementarias  Atributos de los requerimientosCAL/ProcesoSW_Requerimientos
  22. 22. Manejar Alcance Del SistemaCAL/ProcesoSW_Requerimientos
  23. 23. Flujo de Actividades  Desarrollar la visión  Manejar las dependencias  Priorizar los casos de uso  Revisar los cambios solicitadosCAL/ProcesoSW_Requerimientos
  24. 24. Productos del trabajo  Visión  Atributos de los requerimientosCAL/ProcesoSW_Requerimientos
  25. 25. Refinar Definición Del SistemaCAL/ProcesoSW_Requerimientos
  26. 26. Flujo de actividades  Detallar cada caso de uso  Detallar los requerimientos de SW  Modelar las interfaces del usuario  Prototipear las interfaces del usuarioCAL/ProcesoSW_Requerimientos
  27. 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 requerimientosCAL/ProcesoSW_Requerimientos
  28. 28. Manejo De Cambios En Los RequerimientosCAL/ProcesoSW_Requerimientos
  29. 29. Flujo de actividades  Manejar dependencias  Revisar solicitudes de cambio  Revisar los requerimientos  Estructurar el modelo de casos de uso  Registro de la revisiónCAL/ProcesoSW_Requerimientos
  30. 30. Productos del trabajo  Modelo de casos de uso  Atributos de requerimientosCAL/ProcesoSW_Requerimientos
  31. 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.CAL/ProcesoSW_Requerimientos
  32. 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.CAL/ProcesoSW_Requerimientos
  33. 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.CAL/ProcesoSW_Requerimientos
  34. 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.CAL/ProcesoSW_Requerimientos
  35. 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.CAL/ProcesoSW_Requerimientos
  36. 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.CAL/ProcesoSW_Requerimientos
  37. 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.CAL/ProcesoSW_Requerimientos
  38. 38. Conceptos G. Requerimientos  Equipos InterfuncionalesCAL/ProcesoSW_Requerimientos
  39. 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.CAL/ProcesoSW_Requerimientos
  40. 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.CAL/ProcesoSW_Requerimientos
  41. 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.CAL/ProcesoSW_Requerimientos
  42. 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.CAL/ProcesoSW_Requerimientos
  43. 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)CAL/ProcesoSW_Requerimientos
  44. 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.CAL/ProcesoSW_Requerimientos
  45. 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.CAL/ProcesoSW_Requerimientos
  46. 46. Requerimientos FURPS+ Los requerimientos funcionales pueden incluir: • Conjuntos de características, • Capacidades, y • Seguridad.CAL/ProcesoSW_Requerimientos
  47. 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.CAL/ProcesoSW_Requerimientos
  48. 48. Requerimientos FURPS+ Confiabilidad (Reliability) que se pueden considerar: • Frecuencia / severidad de fallas, • Recuperabilidad, • Predictibilidad, • Exactitud y • Tiempo medio entre fallas (MTBF).CAL/ProcesoSW_Requerimientos
  49. 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 recursosCAL/ProcesoSW_Requerimientos
  50. 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)CAL/ProcesoSW_Requerimientos
  51. 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 operacionalesCAL/ProcesoSW_Requerimientos
  52. 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.CAL/ProcesoSW_Requerimientos
  53. 53. Requerimientos FURPS+  Requerimientos físicos – especifica requerimientos de hardware (redes)  Formas  Tamaños  Pesos  MaterialCAL/ProcesoSW_Requerimientos
  54. 54. Tabla de Requerimientos LISTA DE REQUERIMIENTOS DEL SISTEMA: OVINSYSTEM Nro. Requerimiento Clasificación Atributos Prioridad Categoría Dificultad Visibilidad Riesgo FURPS+ Precedencia (A, M, B) (P, S, O) (A, M, B) (V,O) (A, M, B) R1 Registrar identificacion de ovinos. F A P M V M R2 Generar reporte de hembras y machos. F A P B V B R1 R3 Actualizar registro de empadre. F A P B V M R2 R4 Actualizar registros de preñadas. F A P B V M R3 R5 Registrar grado de preñez. F A P B V M R4 R6 Registrar ovejas transferidas. F A P B V B R5,R1 R7 Actualizar registro de nacimiento. F A P B V M R6 R8 Generar reporte de paricion. F A P B V B R9 Actualizar registro de corderos. F A P M V B R8 R10 Registro de pre-pruber. F A P B V M R9 R11 Registro de corderos por tipo de saca F A P B V M R10CAL/ProcesoSW_Requerimientos

×