Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

11271320110505163923 (1)

343 views

Published on

Published in: Investor Relations, Travel
  • Be the first to comment

  • Be the first to like this

11271320110505163923 (1)

  1. 1. CALIDAD DE SOFTWARE 2011-01 REQUERIMIENTOS
  2. 2. OBJETIVOS <ul><li>Llegar a un acuerdo formal con los clientes y usuarios sobre lo que el sistema debe hacer. </li></ul><ul><li>Proporcionar a los miembros del proyecto una idea clara de los requisitos del sistema. </li></ul><ul><li>Delimitar las fronteras del sistema. </li></ul><ul><li>Proporcionar las bases para la planificación del contenido técnico de las iteraciones. </li></ul><ul><li>Proporcionar las bases para estimar los costos y el tiempo de desarrollo del sistema. </li></ul><ul><li>Definir la interface gráfica del sistema. </li></ul>
  3. 3. ¿QUÉ ES UN REQUERIMIENTO? <ul><li>Descripciones que hace el usuario de los deseos o necesidades que tiene de un producto al equipo de desarrollo. </li></ul>
  4. 4. ¿DÓNDE IDENTIFICAR REQUERIMIENTOS? Analistas Clientes Actividades del negocio Socios Usuarios
  5. 5. ¿CÓMO CAPTURAR REQUERIMIENTOS? <ul><li>Entrevistas. </li></ul><ul><li>Cuestionarios. </li></ul><ul><li>Encuestas. </li></ul><ul><li>Sondeos. </li></ul><ul><li>Diagramas de procesos y workflows. </li></ul><ul><li>Casos de uso del negocio. </li></ul><ul><li>Diagramas de actividades de los procesos del negocio. </li></ul>
  6. 6. REQUERIMIENTO VS. REQUISITO <ul><li>Los requerimientos originan REQUISITOS que se deben cumplir para poder llegar a lograr los requerimientos. </li></ul>Requerimiento Necesidad Necesario para cubrir la necesidad Requisito
  7. 7. REQUISITOS <ul><li>Una descripción de algo que el sistema es capaz de hacer con el objeto de satisfacer las necesidades del cliente. </li></ul><ul><li>Una característica del Sistema </li></ul><ul><li>Propiedades o restricciones determinadas de forma precisa que deben satisfacerse. </li></ul>
  8. 8. ¿POR QUÉ SON IMPORTANTES LOS REQUISITOS? <ul><li>En 1994 el Standish Group hizo un estudio sobre 350 compañías y cerca de 8000 proyectos de software para averiguar cómo iban. </li></ul><ul><li>Los resultados fueron desalentadores: </li></ul><ul><li>El 31% de los proyectos de software fueron cancelados antes de completarse. </li></ul><ul><li>En las grandes compañías, sólo el 9% de los proyectos fue entregado en término y dentro del costo presupuestados; </li></ul><ul><li>En las pequeñas empresas sólo el 16% cumplió con los tiempos y costos definidos inicialmente. </li></ul>
  9. 9. ¿POR QUÉ SON IMPORTANTES LOS REQUISITOS? <ul><li>Los principales factores fueron: </li></ul><ul><li>Requisitos incompletos (13,1%). </li></ul><ul><li>Falta de compromiso del usuario (12,4%). </li></ul><ul><li>Falta de recursos (10,6%). </li></ul><ul><li>Expectativas no realistas (9,9%). </li></ul><ul><li>Falta de soporte ejecutivo (9,3%). </li></ul><ul><li>Requerimientos y especificaciones cambiantes (8,7%). </li></ul><ul><li>Falta de planeamiento (8,1%). </li></ul><ul><li>Fin de la necesidad del sistema (7,5%). </li></ul>
  10. 10. ¿POR QUÉ SON IMPORTANTES LOS REQUISITOS? <ul><li>Si cuesta $1 identificar y subsanar un problema debido a requerimientos, durante la etapa de definición ; </li></ul><ul><li>Puede costar $5 repararlo durante el diseño </li></ul><ul><li>$10 durante la codificación </li></ul><ul><li>$20 durante la prueba unitaria </li></ul><ul><li>y hasta $200 después de la entrega del sistema . </li></ul>
  11. 11. PROPÓSITO DE LOS REQUISITOS <ul><li>Permiten que los analistas expliquen cómo han entendido lo que el cliente y usuarios esperan del sistema. </li></ul><ul><li>Indican a los diseñadores qué funcionalidad y características va a tener el sistema resultante. </li></ul><ul><li>Establecen para los desarrolladores la especificación del comportamiento del sistema. </li></ul><ul><li>Indican a los testeadores qué demostraciones llevar a cabo para que el cliente se convenza de que el sistema que se le entrega es lo que había solicitado. </li></ul>
  12. 12. CLASIFICACIÓN <ul><li>FUNCIONALES </li></ul><ul><li>NO FUNCIONALES </li></ul>
  13. 13. REQUISITOS FUNCIONALES <ul><li>Especifica lo que debe hacer el sistema en relación a su entorno (usuarios u otros sistemas) sin tener en cuenta restricciones físicas. </li></ul><ul><li>Cómo debe reaccionar ante los estímulos que recibe </li></ul><ul><li>Cómo el sistema debe comportarse en situaciones particulares. </li></ul>
  14. 14. REQUISITOS FUNCIONALES <ul><li>Ejemplo: </li></ul><ul><li>El sistema deberá: </li></ul><ul><li>Actualizar la información de los profesores. </li></ul><ul><li>Consultar los horarios de los cursos. </li></ul><ul><li>Registrar reglas de evaluación. </li></ul><ul><li>Consultar la programación de los exámenes. </li></ul><ul><li>Cerrar un curso. </li></ul>
  15. 15. REQUISITOS NO FUNCIONALES <ul><li>Definen las propiedades y restricciones del sistema a construir o sobre el proceso que lo construirá </li></ul><ul><li>Los requisitos no funcionales, suelen ser mas críticos que los funcionales, dado que su incumplimiento puede hacer inútil el sistema. </li></ul>
  16. 16. REQUISITOS NO FUNCIONALES <ul><li>Estos están clasificados según el tipo de restricción que se quiera implementar </li></ul><ul><ul><li>Rendimiento del sistema: </li></ul></ul><ul><ul><ul><li>Fiabilidad, tiempo de respuesta, disponibilidad… </li></ul></ul></ul><ul><ul><li>Interfaces: </li></ul></ul><ul><ul><ul><li>Dispositivos de E/S, usabilidad, interoperabilidad… </li></ul></ul></ul><ul><ul><li>Proceso de desarrollo: </li></ul></ul><ul><ul><ul><li>Estándares, herramientas, plazo de entrega… </li></ul></ul></ul>
  17. 17. REQUISITOS NO FUNCIONALES <ul><li>A los requisitos no funcionales se les suele llamar coloquialmente “cualidades” del sistema y pueden dividirse en dos categorías: </li></ul><ul><li>Cualidades de ejecución , como la seguridad o la usabilidad, observables en tiempo de ejecución. </li></ul><ul><li>Cualidades de evolución , como la testabilidad, mantenibilidad, escalabilidad, determinadas por la estructura estática del software. </li></ul>
  18. 18. Los Requisitos Funcionales definen qué debe hacer un sistema Los Requisitos No Funcionales definen cómo debe ser el sistema .
  19. 19. ESPECIFICACIÓN DE REQUISITOS <ul><li>Los Requisitos …. </li></ul><ul><li>Se especifican en lenguaje natural, </li></ul><ul><li>Se expresan de forma individual </li></ul><ul><li>A menudo, se codifican (para facilitar su gestión) </li></ul>
  20. 20. ESPECIFICACIÓN DE REQUISITOS <ul><li>Los requisitos han de ser … </li></ul><ul><li>Claros y concretos : evitando ambigüedades e imprecisiones </li></ul><ul><li>Completos : Todas las necesidades deben estar reflejadas. </li></ul><ul><li>Consistentes : No debe existir contradicción entre requisitos. </li></ul><ul><li>Comprobables : Se debe poder determinar si se cumple o no. </li></ul>
  21. 21. ESPECIFICACIÓN DE REQUISITOS <ul><li>Los requisitos han de indicar… </li></ul><ul><li>Lo que se espera que haga el sistema (¿qué?), </li></ul><ul><li>Su justificación (¿por qué ha de ser así? ¿quién lo propuso?) </li></ul><ul><li>Los criterios de aceptación que sean aplicables (¿cómo se verifica su cumplimiento?). </li></ul>
  22. 22. ESPECIFICACIÓN DE REQUISITOS <ul><li>Los requisitos Funcionales ….. </li></ul><ul><li>Deben estar redactados de tal forma que sean comprensibles para usuarios sin conocimientos técnicos avanzados. </li></ul><ul><li>Deben especificar el comportamiento externo del sistema y evitar, en la medida de lo posible, establecer características de su diseño, </li></ul><ul><li>Deben priorizarse (al menos, se ha de distinguir entre requisitos obligatorios y requisitos deseables). </li></ul>
  23. 23. ESPECIFICACIÓN DE REQUISITOS <ul><li>Los Requisitos No Funcionales … </li></ul><ul><li>Han de especificarse cuantitativamente, siempre que sea posible (para que se pueda verificar su cumplimiento). </li></ul>
  24. 24. ESPECIFICACIÓN DE REQUISITOS <ul><li>MAL </li></ul><ul><li>Para facilitar el uso del editor gráfico, se podrá activar y desactivar una rejilla que permitirá alinear las figuras del diagrama. Cuando se ajuste la figura al tamaño de la pantalla, se reducirá el número de líneas de la rejilla para que no se dificulte la visualización del diagrama. </li></ul><ul><li>¿Por qué? </li></ul><ul><li>Mezcla de varios requisitos. </li></ul>
  25. 25. ESPECIFICACIÓN DE REQUISITOS <ul><li>BIEN </li></ul><ul><li>El editor permitirá el uso de una rejilla de líneas horizontales y verticales que aparecerán dibujadas tras el diagrama. </li></ul><ul><li>Justificación : La rejilla facilita la creación de diagramas cuidados en los que las figuras se puedan alinear con facilidad. </li></ul><ul><li>¿Por qué? </li></ul><ul><li>Preciso, conciso y justificado correctamente. </li></ul>
  26. 26. ESPECIFICACIÓN DE REQUISITOS <ul><li>MAL </li></ul><ul><li>El sistema será lo más fácil de utilizar posible. </li></ul><ul><li>El sistema proporcionará una respuesta rápida al usuario. </li></ul><ul><li>El sistema se recuperará automáticamente tras producirse un fallo. </li></ul><ul><li>¿Por qué? </li></ul><ul><li>Objetivos generales, vagos y abiertos a distintas </li></ul><ul><li>interpretaciones. </li></ul>
  27. 27. ESPECIFICACIÓN DE REQUISITOS <ul><li>BIEN </li></ul><ul><li>Un usuario experimentado debe ser capaz de utilizar todas las funciones del sistema tras un entrenamiento de 2 horas, tras el cual no cometerá más de 3 errores diarios en media. </li></ul><ul><li>Cuando haya hasta 100 usuarios accediendo simultáneamente al sistema, su tiempo de respuesta no será en ningún momento superior a 2 segundos. </li></ul>

×