“Pre-portada” (-2)  Ninguna de las ideas expresadas en   este curso debe considerarse una   verdad absoluta que es aplicab...
“Pre-portada” (-1)            Olvide usted que está en un curso de      Ingeniería del Software, imagine que tiene a un   ...
“Pre-portada” (0)  ¿cómo haría para solucionar        el problema?    para crear una solución, primero       es necesario ...
REQUISITOS / REQUERIMIENTOS           ¡todo lo que el cliente quiere,            exactamente lo que quiere,       a como d...
Requisitos / Requerimientos  ¿qué es un requisito?                              5
Requisitos / Requerimientos   Los requisitos expresan lo que el sistema debe hacer     para satisfacer las necesidades de ...
un requisito... ...es algo que el sistema debe sercapaz de hacer (o una restricciónque debe cumplir) para que pueda cumpli...
Requisitos / Requerimientos      Los requerimientos se concentran en       el cliente y el problema a resolver            ...
Requisitos / Requerimientos                ¡Los requisitos se               concentran en “qué”                   debe hac...
¿Qué Definen los Requisitos?  Los datos que            Las funciones        La información debe capturar y             que...
¿Qué Tipos de Requisitos?                                       Funcionales                    Dependiendo si             ...
Requerimientos Funcionales / NoFuncionales         Los requerimientos Funcionales                   Describen:   La funcio...
Requerimientos Funcionales / NoFuncionales             Ejemplos de Requerimientos                    Funcionales:         ...
Requerimientos Funcionales / NoFuncionales       Los requerimientos no Funcionales:   No se refieren directamente a las pr...
Requerimientos Funcionales / NoFuncionales              Propiedades Emergentes:    Son aquellas que resultan del sistema c...
Requerimientos Funcionales / NoFuncionales            Ejemplos de Requerimientos                 no Funcionales:          ...
Requerimientos Funcionales / NoFuncionales                Clasificación de Requerimientos no funcionales          (no inte...
Tipos de Requisitos (Clasificaciones)                                         Funcionales                     Dependiendo ...
Requerimientos de Usuario / de Sistema               Requerimientos de Usuario:    Son aquellos que están dirigidos a los ...
Requerimientos de Usuario / de Sistema   Documento de Especificación de Requerimientos                      (DER)       Es...
Requisitos / Requerimientos           nuevamente...          ¿por qué son         importantes los           requisitos?   ...
Requisitos     Se estima que un alto porcentaje de proyectos de             desarrollo de software fallan por:            ...
Requisitos    Hoy en día la Ingeniería de Requisitos     se considera una etapa clave en el            desarrollo de softw...
El Costo del Cambio (de requisitos)                                                                 Fase         Costo    ...
¿Por qué tienen éxito losproyectos de software?       Encuesta realizada a Gerentes Ejecutivos del área de                ...
¿Cuáles han sido las mayoresamenazas en un proyecto de software?      Encuesta realizada a Gerentes Ejecutivos del área de...
¿Por qué fallan losproyectos de software?      Encuesta realizada a Gerentes Ejecutivos del área de                 Desarr...
Requisitos / Requerimientos        bien... pero...     ¿cómo se obtienen       los requisitos?                            ...
Requisitos             ¿Ingeniería de Requisitos?       Proceso de establecimiento de los      servicios que debe proporci...
Procesos de la Ingeniería de Requisitos                                 Una visión:             Captura            Análisi...
Procesos de la Ingeniería de Requisitos             Captura           Análisis       Especificación    Validación    Es la...
Procesos de la Ingeniería de Requisitos       ¿Quién está detrás de la solicitud de este                  trabajo? (Client...
Procesos de la Ingeniería de Requisitos    ¿Cómo podría caracterizarse un buen resultado    generado por una solución? (¿C...
Procesos de la Ingeniería de Requisitos        En este punto, cuando el cliente ya está        hablando, uno se transforma...
Procesos de la Ingeniería de Requisitos     ¿Es usted la persona adecuada para contestar     esta pregunta? ¿Sus respuesta...
Procesos de la Ingeniería de Requisitos     ¿Cómo se soluciona el problema actualmente?     ¿Entre que bandas de costos se...
Procesos de la Ingeniería de Requisitos                     Recuerde:       Una vez que comprenda algo,     repitalo al cl...
Procesos de la Ingeniería de Requisitos                   Consejo:    Nunca vaya a una reunión de negocios o    a una entr...
Procesos de la Ingeniería de Requisitos          Captura    Análisis   Especificación   Validación                        ...
Procesos de la Ingeniería de Requisitos          Captura         Análisis   Especificación   Validación        Es la activ...
Procesos de la Ingeniería de Requisitos           Captura   Análisis          Especificación     Validación    Es la activ...
Requisitos / Requerimientos    ¿quiénes participan    en la ingeniería de     requerimientos?                             ...
Participantes en el Desarrollo de Software               CLIENTE /              EJECUTIVO /               USUARIO         ...
Participantes en el Desarrollo de Software                 CLIENTE                      USUARIO               EJECUTIVOS  ...
Participantes en el Desarrollo de Software                         Otros                  desarrolladores y               ...
Interesados / Actores / Protagonistas(Stakeholders)                                                      Instituciones    ...
Requisitos / Requerimientos         ¿problemas      con los requisitos?                   ¡DILBERT!                       ...
Requisitos (Problemas de los)     ¡Para poder desarrollar software se     necesitan usuarios, comprometidos, disponibles (...
Requisitos (Problemas de los)   El cliente / usuario no siempre sabe o tiene claro lo que quiere       El cliente / usuari...
Requisitos (Problemas de los)           El cliente / usuario no entiende a los analistas                    (Lenguaje técn...
Requisitos (Tres Leyes)(Según Demián Gutierrez)                        Primera Regla:                El usuario siempre ti...
Requisitos (Tres Leyes)(Según Demián Gutierrez)                     ¡Ley Cero!    Ante la duda, siempre consulte al usuari...
Gracias   ¡Gracias!               53
Nächste SlideShare
Wird geladen in …5
×

Clase 04a requerimientos introduccion

1.575 Aufrufe

Veröffentlicht am

Veröffentlicht in: Technologie
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.575
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
7
Aktionen
Geteilt
0
Downloads
115
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Clase 04a requerimientos introduccion

  1. 1. “Pre-portada” (-2) Ninguna de las ideas expresadas en este curso debe considerarse una verdad absoluta que es aplicable a todos los escenarios existentes Por el contrario, la aplicabilidad de estas ideas depende del contexto en el que se apliquen, del proyecto a desarrollar, del proceso de desarrollo, etc. 1
  2. 2. “Pre-portada” (-1) Olvide usted que está en un curso de Ingeniería del Software, imagine que tiene a un cliente enfrente, y que este cliente necesita un software... ¿cómo haría para solucionar el problema? Asumo que usted sabe programar al menos. Imagine y describa todo lo que ocurre desde que usted conoce al cliente hasta que termina el trabajo y le entrega su software 2
  3. 3. “Pre-portada” (0) ¿cómo haría para solucionar el problema? para crear una solución, primero es necesario tener claro y comprender el problema... 3
  4. 4. REQUISITOS / REQUERIMIENTOS ¡todo lo que el cliente quiere, exactamente lo que quiere, a como de lugar y a cualquier precio! Universidad de Los Andes Demián Gutierrez Febrero 2013 4
  5. 5. Requisitos / Requerimientos ¿qué es un requisito? 5
  6. 6. Requisitos / Requerimientos Los requisitos expresan lo que el sistema debe hacer para satisfacer las necesidades de sus clientes o usuarios “es un aspecto de un sistema o una descripción de aquello que el sistema es capaz de hacer a fin de cumplir su propósito” [Pfleeger, 1998] “Un requerimiento es un servicio que el sistema de software debe satisfacer o una restricción bajo la cual el sistema debe operar” [Sommerville 2002] si me lo preguntan, en lo personal, pienso que... 6
  7. 7. un requisito... ...es algo que el sistema debe sercapaz de hacer (o una restricciónque debe cumplir) para que pueda cumplir su propósito y satisfacer a sus usuarios 7
  8. 8. Requisitos / Requerimientos Los requerimientos se concentran en el cliente y el problema a resolver Definen (o deberían definir) sobre el sistema: Lo que el cliente quiere que haga... Todo lo que el cliente quiere que haga... Nada más que lo que el cliente quiere que haga... 8
  9. 9. Requisitos / Requerimientos ¡Los requisitos se concentran en “qué” debe hacer el sistema, no en “cómo” debe hacerlo! Es decir, dejen de pensar por los momentos en cómo los van a programar o implementar... 9
  10. 10. ¿Qué Definen los Requisitos? Los datos que Las funciones La información debe capturar y que debe que debe almacenar ejecutar producir La plataforma de operación del sistema Aplicación (Hardware / Software) La tecnología Restricciones Requisitos de Operación de información que debe usar Interacción Usuario / Atributos de Calidad Las interfaces Sistema con otros sistemas Seguridad, facilidad de La interfaz gráfica uso, documentación, usuario-sistema (GUI) 10 utilidad, etc.
  11. 11. ¿Qué Tipos de Requisitos? Funcionales Dependiendo si definen o no funcionalidad No Funcionales Tipos de Requisitos De Usuario Dependiendo de a quienes están dirigidos De Sistema 11
  12. 12. Requerimientos Funcionales / NoFuncionales Los requerimientos Funcionales Describen: La funcionalidad o los servicios que se espera que el sistema de software proveerá La interacción entre el sistema de software y su ambiente o contexto Como el sistema deberá actuar bajo ciertos estímulos o eventos 12
  13. 13. Requerimientos Funcionales / NoFuncionales Ejemplos de Requerimientos Funcionales: R-010: El sistema debe permitir el registro de nuevos usuarios en el foro, los nuevos usuarios deben ser aprobados o rechazados por un moderador antes de poder publicar mensajes R-200: Los usuarios deben poder intercambiar mensajes y comunicarse por medio del foro, toda la comunicación debe estar moderada para evitar conductas inapropiadas por parte de los usuarios, mensajes basura y publicidad no deseada 13
  14. 14. Requerimientos Funcionales / NoFuncionales Los requerimientos no Funcionales: No se refieren directamente a las propiedades funcionales del sistema, sino a sus propiedades emergentes o a restricciones adicionales en el sistema o en el proyecto de desarrollo de software. Definen restricciones adicionales al sistema, tales como: Proceso de desarrollo a utilizar, herramientas, lenguaje de programación, limitaciones de presupuesto, de tiempo, de interfaz, etcétera ¿Propiedades Emergentes? 14
  15. 15. Requerimientos Funcionales / NoFuncionales Propiedades Emergentes: Son aquellas que resultan del sistema como un todo y que es muy difícil o imposible atribuirle a un componente particular de éste. Por ejemplo, la fiabilidad, tiempo de respuesta, usabilidad, capacidad de almacenamiento, etcétera El todo no siempre es la simple suma de sus partes... 15
  16. 16. Requerimientos Funcionales / NoFuncionales Ejemplos de Requerimientos no Funcionales: R-430: El sistema debe ser utilizable por medio de una interfaz WEB R-233: Se debe utilizar RUP como proceso de desarrollo del software R-230: El tiempo de respuesta del sistema al solicitar un reporte nunca debe ser mayor a 10 segundos 16
  17. 17. Requerimientos Funcionales / NoFuncionales Clasificación de Requerimientos no funcionales (no interpretar literalmente, es sólo a modo de referencia) Fuente: Sommerville 2002 17
  18. 18. Tipos de Requisitos (Clasificaciones) Funcionales Dependiendo si definen o no funcionalidad No Funcionales Tipos de Requisitos De Usuario Dependiendo de a quienes están dirigidos De Sistema 18
  19. 19. Requerimientos de Usuario / de Sistema Requerimientos de Usuario: Son aquellos que están dirigidos a los usuarios y clientes del sistema (interesados en general). Se redactan usando lenguaje natural (generalmente) de forma “no técnica” con el objetivo de que el personal no técnico los pueda entender Requerimientos de Sistema: Son aquellos dirigidos a personal técnico: analistas, programadores, arquitectos, ingenieros, etcétera. Generalmente están escritos en un lenguaje mucho más técnico pero mucho más preciso que los requerimientos de usuario 19
  20. 20. Requerimientos de Usuario / de Sistema Documento de Especificación de Requerimientos (DER) Es el documento en el que usualmente se especifican los requerimientos de usuario Documento de Definición de Requerimientos (DDR) Es el documento en el que usualmente se especifican los requerimientos de sistema 20
  21. 21. Requisitos / Requerimientos nuevamente... ¿por qué son importantes los requisitos? 21
  22. 22. Requisitos Se estima que un alto porcentaje de proyectos de desarrollo de software fallan por: Requisitos incompletos Falta de participación del usuario Expectativas poco realistas Cambios en los requisitos y las especificaciones El sistema dejó de ser necesario 22
  23. 23. Requisitos Hoy en día la Ingeniería de Requisitos se considera una etapa clave en el desarrollo de software Actualmente, se considera que la satisfacción de los clientes es la mejor métrica de calidad de un sistema 23
  24. 24. El Costo del Cambio (de requisitos) Fase Costo ($) Requerimientos 0 Diseño 1 Arquitectónico Diseño 2 Detallado Codificación 3 Pruebas 5 de Unidades Validación 20 Puesta 100 en Marcha / Operación sin embargo, los métodos ágiles en general desafían este punto de vista Tomado del Taller de Ingeniería de Requisitos V 4.06, Ceisoft, Marzo 2006 24
  25. 25. ¿Por qué tienen éxito losproyectos de software? Encuesta realizada a Gerentes Ejecutivos del área de Desarrollo de Software y TICs Factores de éxito en el Proyecto % Respuestas 1 Usuarios involucrados con el proyecto 15,90% 2 Soporte de los Ejecutivos 13,90% 3 Requerimientos Claros 13,00% 4 Planificación Adecuada 9,60% 5 Expectativas Realistas 8,20% 6 Hitos pequeños y poco espaciados en el tiempo 7,70% 7 Personal competente 7,20% 8 Control sobre el proyecto por parte del personal 5,30% 9 Visión clara y objetivos 2,90% 10 Trabajo duro, personal enfocado y comprometido 2,40% 11 Otras 13,90% 100,00% ¡¡¡Dos de las tres primeras causas están asociadas a los requisitos!!! 25 Tomado del Standish Group Report (1995)
  26. 26. ¿Cuáles han sido las mayoresamenazas en un proyecto de software? Encuesta realizada a Gerentes Ejecutivos del área de Desarrollo de Software y TICs Factores que amenazaron el Proyecto % Respuestas 1 Falta de información de los usuarios 12,80% 2 Especificación de requerimientos incompleta 12,30% 3 Requerimientos y especificación compleja 11,80% 4 Falta de soporte ejecutivo 7,50% 5 Mala tecnología, mal uso de la tecnología 7,00% 6 Falta de recursos 6,40% 7 Expectativas poco realistas 5,90% 8 Objetivos poco claros 5,30% 9 Tiempos de desarrollo poco realistas (planificación) 4,30% 10 Tecnología nueva (desconocimiento) 3,70% 11 Otras 23,00% 100,00% ¡¡¡Las tres primeras causas están asociadas a los requisitos!!! 26 Tomado del Standish Group Report (1995)
  27. 27. ¿Por qué fallan losproyectos de software? Encuesta realizada a Gerentes Ejecutivos del área de Desarrollo de Software y TICs Factores que acabaron/cancelaron el Proyecto % Respuestas 1 Falta de información de los usuarios 13,10% 2 Especificación de requerimientos incompleta 12,40% 3 Falta de recursos 10,60% 4 Expectativas poco realistas 9,90% 5 Falta de soporte ejecutivo 9,30% 6 Requerimientos cambiantes 8,70% 7 Falta de planificación 8,10% 8 El proyecto no se necesito más 7,50% 9 Falta de gestión adecuada de IT 6,20% 10 Problemas tecnológicos 4,30% 11 Otras 9,90% 100,00% ¡¡¡Dos de las tres primeras causas están asociadas a los requisitos!!! 27 Tomado del Standish Group Report (1995)
  28. 28. Requisitos / Requerimientos bien... pero... ¿cómo se obtienen los requisitos? 28
  29. 29. Requisitos ¿Ingeniería de Requisitos? Proceso de establecimiento de los servicios que debe proporcionar un sistema, así como de las restricciones sobre las cuales debe operar Ingeniería => Enfoque Sistemático 29
  30. 30. Procesos de la Ingeniería de Requisitos Una visión: Captura Análisis Especificación Validación Otra visión (Según Pfleeger): Análisis Descripción Documentación del del Prototipado y Validación Problema Problema Definición y Elicitación y Análisis Especificación ... y hay otras... 30 (ver Sommerville cap. 6 / Pressman cap. 7)
  31. 31. Procesos de la Ingeniería de Requisitos Captura Análisis Especificación Validación Es la actividad por medio de la cual se obtienen (capturan) los requerimientos Observación Modelo de Entrevistas Directa Negocios Lectura / Análisis de Prototipos Otras... Documentos 31
  32. 32. Procesos de la Ingeniería de Requisitos ¿Quién está detrás de la solicitud de este trabajo? (Clientes) ¿Quién usará la solución? (Usuarios) ¿Cuál será el beneficio económico de una solución exitosa? ¿Existe otra fuente para la solución requerida? 32 Tomado de Pressman 2005 / cap 7
  33. 33. Procesos de la Ingeniería de Requisitos ¿Cómo podría caracterizarse un buen resultado generado por una solución? (¿Cómo sé que una solución es buena?) ¿Cuáles problemas debería atacar la solución? ¿Podría usted mostrar o describir el ambiente de negocios en el que se utilizará la solución? ¿Hay aspectos o restricciones especiales del rendimiento que afecten la manera de enfocar la solución? 33 Tomado de Pressman 2005 / cap 7
  34. 34. Procesos de la Ingeniería de Requisitos En este punto, cuando el cliente ya está hablando, uno se transforma en “pepito preguntón”: ¿Por qué? ¿Y por qué? ¿Qué es esto? ¿Y esto otro? ¿Cómo hacen esto? ¿Y esto otro? ¿Quién hace esto? ... 34 Opinión personal
  35. 35. Procesos de la Ingeniería de Requisitos ¿Es usted la persona adecuada para contestar esta pregunta? ¿Sus respuestas son oficiales? ¿Mis preguntas son relevantes para su problema? ¿Estoy haciendo demasiadas preguntas? ¿Alguien más puede proporcionar información adicional? ¿Debería preguntarle alguna otra cosa? 35 Tomado de Pressman 2005 / cap 7
  36. 36. Procesos de la Ingeniería de Requisitos ¿Cómo se soluciona el problema actualmente? ¿Entre que bandas de costos se debería mover una solución para ser rentable? ... otras de seguro ... ¿Se le ocurre alguna? 36 Opinión personal
  37. 37. Procesos de la Ingeniería de Requisitos Recuerde: Una vez que comprenda algo, repitalo al cliente con sus propias palabras, y si éste lo entiende, entonces usted estará seguro de que lo ha entendido correctamente 37 Opinión personal
  38. 38. Procesos de la Ingeniería de Requisitos Consejo: Nunca vaya a una reunión de negocios o a una entrevista de requerimientos sólo. ¡Dos es un número mágico! ¿Por qué cree usted que esto es así? Consejo: Tome notas / grabe la entrevista de ser posible, y mantenga las grabaciones para futuras referencias 38 Opinión personal
  39. 39. Procesos de la Ingeniería de Requisitos Captura Análisis Especificación Validación Inspecciones Es la actividad por medio de Documentos de la cual se extiende el Discusiones, Entrevistas, modelo de requisitos, se Talleres buscan y localizan Desarrollo de errores, inconsistencias, prototipos limitaciones, carencias, Muchas de las técnicas de la actividad etcétera... de captura 39
  40. 40. Procesos de la Ingeniería de Requisitos Captura Análisis Especificación Validación Es la actividad por medio de la cual se documentan (escriben / se ponen en “blanco y negro”) los requerimientos Documento Documento de Definición de de Especificación de Requerimientos Requerimientos ¡Si los requerimientos no están por escrito (de alguna manera), entonces NO SIRVEN! 40
  41. 41. Procesos de la Ingeniería de Requisitos Captura Análisis Especificación Validación Es la actividad por medio de la cual se VALIDAN los requerimientos con el cliente Muchas de las Discusiones / Inspecciones técnicas de la Entrevistas / de Documentos actividad Talleres de captura !Esta actividad es crítica. Si los requerimientos no se han validado, entonces NO SIRVEN! 41
  42. 42. Requisitos / Requerimientos ¿quiénes participan en la ingeniería de requerimientos? 42
  43. 43. Participantes en el Desarrollo de Software CLIENTE / EJECUTIVO / USUARIO ¿serán (Patrocina el desarrollo del sistema y el cliente y utiliza el sistema) el usuario la misma persona en todos los casos? DESARROLLADOR (Construye el Sistema) 43
  44. 44. Participantes en el Desarrollo de Software CLIENTE USUARIO EJECUTIVOS (Utiliza el (Patrocina el Sistema) desarrollo del sistema) Proporciona Tiene Financiamiento Necesidades Tiene Obligaciones Proporciona Contractuales Sistemas de Software DESARROLLADOR (Construye el Sistema) Pfleeger (1998) 44
  45. 45. Participantes en el Desarrollo de Software Otros desarrolladores y Usuarios participantes en el proyecto Otros entes, Clientes personas, instituciones, afectadas o interesadas en el sistema A todas las DESARROLLADOR personas (Construye involucradas o el Sistema) interesadas se les llama Stakeholder 45
  46. 46. Interesados / Actores / Protagonistas(Stakeholders) Instituciones Consumidores Gubernamentales Usuarios Comunidad analistas programadores Empresa Contratante diseñadores Líderes de proyecto Clientes Gerentes Proveedores Clientes de Consultores / arquitectos la Empresa asesores 46
  47. 47. Requisitos / Requerimientos ¿problemas con los requisitos? ¡DILBERT! 47
  48. 48. Requisitos (Problemas de los) ¡Para poder desarrollar software se necesitan usuarios, comprometidos, disponibles (e involucrados en el desarrollo)! 48
  49. 49. Requisitos (Problemas de los) El cliente / usuario no siempre sabe o tiene claro lo que quiere El cliente / usuario no se compromete con el proyecto Se dan malas interpretaciones en los requerimientos ¿Ha jugado usted alguna vez al “telefonito”? Usuario -> Cliente /Ejecutivo -> Analista -> -> Especificación -> Diseño -> Implementación -> Usuario Los requisitos cambian constantemente (El cliente / usuario cambia de idea constantemente) Fenómeno del “analista sabelotodo”: El analista cree que sabe que es lo que necesita el cliente y por lo tanto no le consulta 49
  50. 50. Requisitos (Problemas de los) El cliente / usuario no entiende a los analistas (Lenguaje técnico del analista) Los analistas no entienden al cliente / usuario (Lenguaje asociado al dominio del cliente / usuario) ¿qué es el dominio del cliente? ¿dominio de aplicación? Requisitos que: No reflejan las necesidades reales del cliente, son inconsistentes, incompletos, no factibles, etcétera Requisitos que el cliente no necesita realmente 50
  51. 51. Requisitos (Tres Leyes)(Según Demián Gutierrez) Primera Regla: El usuario siempre tiene la razón (Aunque se le puede intentar convencer de lo contrario) Segunda Regla: El cliente siempre tiene la razón, siempre y cuando esto no contradiga lo establecido en le primera regla Tercera Regla: Usted (el desarrollador) tiene la razón, siempre y cuando esto no contradiga la segunda o la primera regla ¿Conoce usted las tres leyes de la robótica de Asimov? 51
  52. 52. Requisitos (Tres Leyes)(Según Demián Gutierrez) ¡Ley Cero! Ante la duda, siempre consulte al usuario / cliente involucrado ¡Nunca dé nada por sentado! 52
  53. 53. Gracias ¡Gracias! 53

×