Software Requiments

7,904 views

Published on

Describe el proceso de Requerimientos de Software dentro del desarrollo de una aplicación.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,904
On SlideShare
0
From Embeds
0
Number of Embeds
313
Actions
Shares
0
Downloads
510
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Software Requiments

  1. 1. REQUERIMIENTOS DE SOFTWARE Cúmar Cueva
  2. 2. <ul><li>Maneja el Sistema de Requerimientos </li></ul><ul><li>Permite la solución de un problema del mundo real. </li></ul><ul><li>Son una combinación compleja de requerimientos de diferentes personas en diferentes niveles de una organización y entorno. </li></ul><ul><li>Es verificable </li></ul>REQUERIMIENTOS DE SOFTWARE
  3. 4. Requerimientos de Producto y Proceso <ul><li>Producto </li></ul><ul><li>Requerimientos del software a ser desarrollado (funcionalidades) </li></ul><ul><li>Proceso </li></ul><ul><li>Restricciones llevadas a cabo en el desarrollo del sotware. (Plataforma, etc) </li></ul>
  4. 5. Requerimientos Funcionales y No-Funcionales <ul><li>Funcionales </li></ul><ul><ul><li>Describen las funciones que el software cumplirá. (capacidades) </li></ul></ul><ul><li>No-Funcionales </li></ul><ul><li>Determinan como se obtendrá la solución. </li></ul><ul><li>Requerimientos de Calidad, rendimiento, mantenimiento, seguridad y otros </li></ul>
  5. 6. Propiedades Emergentes <ul><li>Requerimientos que no dependen de un solo componente. </li></ul><ul><li>Para su cumplimiento se evalúa la interoperabilidad de los componentes que le conforman. </li></ul>
  6. 7. Requerimientos Cuantificables <ul><li>Requerimientos claros </li></ul><ul><li>Evitar ambigüedad. </li></ul><ul><li>Si es posible cuantificarlos (%). </li></ul><ul><li>Esto impide una interpretación subjetiva de los requerimientos </li></ul>
  7. 8. Requerimientos del Sistema y del Software <ul><li>Requerimientos del Sistema </li></ul><ul><li>Requerimientos de todo el conjunto que forma el sistema. </li></ul><ul><li>Incluyendo los Usuarios </li></ul><ul><li>Requerimientos de Software </li></ul><ul><li>Sistema compuesto por software </li></ul><ul><li>Derivan de los requerimientos del sistema. </li></ul>
  8. 9. 2 PROCESO DE REQUERIMIENTOS
  9. 10. Modelado de Procesos <ul><li>Proceso de Requerimientos nace con la aplicación y se mantiene durante todo el ciclo de vida. </li></ul><ul><li>Debe adaptarse a la organización de la empresa. </li></ul><ul><li>Incluye actividades de: </li></ul><ul><ul><li>Análisis, especificaciones y validaciones. </li></ul></ul>
  10. 11. Actores del Proceso <ul><li>Define roles dentro del proceso de requerimientos. </li></ul><ul><li>Relaciones interdisciplinarias. </li></ul><ul><li>Usuarios </li></ul><ul><li>Clientes </li></ul><ul><li>Ingenieros de Software </li></ul><ul><li>Reguladores </li></ul>
  11. 12. Procesos de Manejo y Soporte <ul><li>Determina el manejo del Proyecto. </li></ul><ul><li>Establece relaciones entre: </li></ul><ul><li>Costos </li></ul><ul><li>Recursos Humanos </li></ul><ul><li>Entrenamiento </li></ul><ul><li>Herramientas </li></ul>
  12. 13. Procesos de Calidad y Mejoramiento <ul><li>Determina la relación entre costos y tiempo. </li></ul><ul><li>Se incluyen como parte la satisfacción del cliente. </li></ul><ul><li>Calidad del Software </li></ul><ul><li>Pruebas de Rendimiento </li></ul><ul><li>Usabilidad </li></ul>
  13. 14. 3 RECOLECCIÓN DE REQUERIMIENTOS <ul><li>Origen de los Requerimientos </li></ul>
  14. 15. Origen de los Requerimientos <ul><li>Diferentes Orígenes. </li></ul><ul><li>El reconocer su origen servirá para determinar su impacto en el proyecto. </li></ul><ul><li>Objetivos claros </li></ul><ul><ul><li>Conocimiento del área de origen </li></ul></ul><ul><li>Roles </li></ul><ul><li>Entorno de Operación y Organización </li></ul>
  15. 16. Técnicas de Elicitacion(Recolección) <ul><li>Como obtener los requerimientos. </li></ul><ul><li>Actividad cooperativa. </li></ul><ul><ul><li>Entrevistas -- Encuentros de grupo </li></ul></ul><ul><ul><li>Escenarios </li></ul></ul><ul><ul><li>Prototipos </li></ul></ul><ul><ul><li>Observación </li></ul></ul>
  16. 17. 4 ANALISIS DE REQUERIMIENTOS <ul><li>Detectar y Resolver conflictos </li></ul>
  17. 18. http://www.processimpact.com/goodies.shtml .
  18. 19. Clasificación de Requerimientos <ul><li>Clasificar los Requerimientos según categorías. </li></ul><ul><li>Basándose en criterios como: </li></ul><ul><ul><ul><li>Funcional – No Funcional </li></ul></ul></ul><ul><ul><ul><li>Si depende de otros </li></ul></ul></ul><ul><ul><ul><li>En Base a Prioridades </li></ul></ul></ul><ul><ul><ul><li>Alcance de los Requerimientos </li></ul></ul></ul><ul><ul><ul><li>Estabilidad / Volatibilidad </li></ul></ul></ul>
  19. 20. Modelado Conceptual <ul><li>Desarrollo de modelos del mundo real. </li></ul><ul><li>Su Elección depende de varios factores. </li></ul><ul><li>Flujo y Modelado de Datos </li></ul><ul><li>Modelos de Estado </li></ul><ul><li>Traceo de Eventos UML </li></ul><ul><li>Interacciones de Usuario </li></ul><ul><li>Modelo de Objetos </li></ul><ul><li>Modelo del Contexto del Software (inicio) </li></ul>
  20. 21. Diseño Arquitectónico y Asignación de Requerimientos <ul><li>Basado en el modelo conceptual. </li></ul><ul><li>Permite detectar errores que no pudieron ser vistos en al modelo anterior. </li></ul><ul><li>Se pueden detectar nuevos requerimientos </li></ul><ul><li>Análisis detallado de los requerimientos </li></ul><ul><ul><li>Deben cumplir su función. </li></ul></ul>
  21. 22. Negociación de Requerimientos <ul><li>Resolver conflictos entre requerimientos. </li></ul><ul><li>Decisiones pueden ser tomadas unilateralmente. </li></ul><ul><li>Se aconseja consultar con las partes implicadas (roles) </li></ul>
  22. 23. 5 ESPECIFICACIÓN DE REQUERIMIENTOS
  23. 24. Definición de la Documentación del Sistema <ul><li>Requerimientos del Sistema </li></ul><ul><ul><li>Requerimientos del Usuario </li></ul></ul><ul><li>Definido a alto nivel. </li></ul><ul><li>No maneja documentación técnica </li></ul><ul><li>IEEE Std 1016-1998 </li></ul><ul><li>http://standards.ieee.org/reading/ieee/std_public/new_desc/se/1016-1998.html </li></ul>
  24. 25. Especificación de los Requerimientos del Sistema <ul><li>Documentación referida al sistema en conjunto. </li></ul><ul><li>Abarca un contexto de aspectos de ingeniería. </li></ul><ul><li>Se basa en componentes del Software. </li></ul><ul><li>ISO/IEC 18019 </li></ul><ul><li>http://www.usabilitynet.org/tools/r_international.htm#18019 </li></ul>
  25. 26. Especificación de los Requerimientos del Software <ul><li>Documento que contiene las especificaciones del software. </li></ul><ul><ul><li>Función del Software y que No hará el Software. </li></ul></ul><ul><li>Permite un examen riguroso de los requerimientos. </li></ul><ul><li>Escrito en lenguaje natural. </li></ul><ul><li>Indicadores de Calidad del Software </li></ul><ul><li>(Mas común) </li></ul>
  26. 27. SRS <ul><li>IEEE Std 830-1998 IEEE </li></ul>http://standards.ieee.org/reading/ieee/std_public/description/se/830-1998_desc.html Template for software requirements specification
  27. 28. 6 VALIDACIÓN DE REQUERIMIENTOS
  28. 29. Revisión de Requerimientos <ul><li>Revisión de requerimientos (Documentacion) </li></ul><ul><li>Formar un Grupo representativo. </li></ul><ul><ul><li>Varios roles ( Customer, Engineering ) </li></ul></ul>
  29. 30. Creación de Prototipos <ul><li>Modelos de Validación </li></ul><ul><li>Hacen fácil la interpretación de la función del software. Mejor perspectiva. </li></ul><ul><li>Desarrollo costoso. </li></ul><ul><ul><li>Su costo puede ser asumido considerando los beneficios que este puede traer (tiempo de desarrollo) </li></ul></ul>
  30. 31. Validación del Modelo <ul><li>Examinar los aspectos de los requerimientos. </li></ul>Test de Aceptación <ul><li>Todo requerimiento debe ser comprobable una ves terminado. </li></ul><ul><li>Identificar y diseñar test para comprobar el cumplimiento de los requerimientos. </li></ul>
  31. 32. Proceso de Requerimientos
  32. 33. 7 CONSIDERACIONES PRÁCTICAS
  33. 34. Naturaleza Iterativa del Proceso de Requisitos <ul><li>Los requerimientos no son lineales. </li></ul><ul><li>Están propensos al cambio. </li></ul><ul><ul><li>Revisiones </li></ul></ul><ul><ul><li>Nuevas funcionalidades </li></ul></ul>Gestión del Cambio <ul><li>El manejo de requerimientos debe contemplar la forma en que se cambiarán los mismos. </li></ul><ul><li>Se describen los procedimientos y análisis que se deben dar para ello. </li></ul>
  34. 35. Atributos de los Requerimientos <ul><li>La sola descripción del requerimiento no basta. </li></ul><ul><li>Se debe adjuntar información relevante </li></ul><ul><li>Test de prueba </li></ul><ul><li>Medidas Cuantificables </li></ul>Requisitos de rastreabilidad <ul><li>Identificación del Origen del Requerimiento </li></ul><ul><li>Predecir sus efectos en el proyecto </li></ul>
  35. 36. Atributos Para Usuarios Para Desarrolladores Disponibilidad Mantenibilidad Eficiencia Portabilidad Flexibilidad Reusabilidad Integridad Capacidad de Testeo Interoperabilidad Fiabilidad Robustez Usabilidad
  36. 37. Requisitos de Medición <ul><li>Útil para tener una medida cuantificable de un requerimiento. </li></ul><ul><li>Esto determina el tamaño del requerimiento y por consecuencia su costo de desarrollo y de las tareas de mantenimiento. </li></ul>
  37. 38. Conclusiones <ul><li>Los requerimientos de software son el punto de partida para el desarrollo de una solución óptima. </li></ul><ul><li>Todo requerimiento que no sea consultado con el usuario, será una traba en el desarrollo del sistema. </li></ul><ul><li>Los requerimientos son medibles, cuantificables y comprobables. </li></ul>
  38. 39. Bibliografía <ul><li>Estándares de Ingeniería </li></ul><ul><li>http://electronics.ihs.com/ </li></ul><ul><li>Estándares de IEEE </li></ul><ul><li>http://standards.ieee.org </li></ul><ul><li>Estándares ISO </li></ul><ul><li>http://www.usabilitynet.org/ </li></ul><ul><li>SRS </li></ul><ul><li>http://www.microtoolsinc.com/Howsrs.php </li></ul>
  39. 40. REQUERIMIENTOS DE SOFTWARE Cúmar Cueva

×