1 Requerimientos desde la perspectiva del cliente
2 Derechos y responsabilidades de los usuarios
3 Derechos Esperar que el analista hable su idioma.Esperar que el analista conozca sobre su negocio y sus objetivos para el sistema. Esperar que el analista estructure la información que se brinda en una especificación de requerimientos de sw.
4 Derechos (cont…) Que se le explique acerca de los entregables obtenidos producto del proceso de requerimientos. Esperar que se le trate con respeto y mantener un ambiente colaborativo y profesional. Contar con analistas y desarrolladores que brinden ideas y alternativas para la implementación de su producto.
5 Derechos (cont…) Describir las características que harán del producto algo sencillo y fácil de usar. Que se le brinde la oportunidad de ajustar sus requerimientos y reutilizar componentes de SW. Recibir de buena fe, estimaciones de costos, impacto, compensaciones, al haber un cambio.
6 Derechos (cont…) Recibir el sistema conociendo sus necesidades funcionales y de calidad, y que se hayan conocido y aprobado.
7 Responsabilidades Educar al analista y desarrolladores acerca de su negocio y su “vocabulario especifico”. Aprovechar tiempo en proveer requerimientos, clarificarlos e interactuar con ellos. Ser especifico y preciso.
8 Responsabilidades Tomar decisiones oportunas sobre los requerimientos cuando se le soliciten. Respetar la opinión del desarrollador en el costo y la viabilidad de los requerimientos. En colaboración, establecer prioridades.
9 Responsabilidades Revisar el ERS y evaluar prototipos.Comunicar cambios apenas los sepa. Seguir el proceso organizacional de desarrollo para los cambios. Respetar el proceso de análisis en la ingeniería de requerimientos.
10 Análisis de Requerimientos
11 Analistas de Sistemas Llamados también:Analistas de negocios. Ingeniero de requerimientos Administrador de requerimientos Analista Básicamente, el análisis significa: Traducir las perspectivas de otros en una Especificación de Requerimientos de Software, donde se pueda contemplar si lo que los Stakeholders dicen es lo que realmente quieren.
12 El rol del analista Tiene la responsabilidad de:Obtener Analizar Documentar Validar Funge como canal de comunicación entre el cliente y los desarrolladores. El analista de requerimientos es un role, no necesariamente un titulo de trabajo, y se necesita habilidades, conocimiento y personalidad.
13 Las tareas del analistaDefinir los requerimientos del negocio. Identificar los Stakeholders y las Clases de Usuarios. Realizar el proceso de elicitación. Analizar los requerimientos. Escribir la ERS. Modelar los requerimientos
14 Las tareas del analista (cont…)Permitir la validación de los requerimientos. Facilitar la priorización. Administrar los requerimientos.
15 Las habilidades del analistaEscuchar efectivamente. Habilidad para entrevistar y cuestionar. Habilidad analítica. Habilidad de facilitación. Habilidades de observación y escritura. De organización y modelado. De relaciones interpersonales y creatividad.
16 Conocimiento esencial del analistaConocimiento de las técnicas de la ingeniería de requerimientos. Saberlas aplicar y conocer sobre las demás actividades del ciclo de desarrollo. Conocer acerca del dominio de la aplicación.
17 Conocimiento esencial del analista (cont)El analista “CRECE”, no hay un entrenamiento especifico, la experiencia es clave. Hay quienes fueron usuarios o son desarrolladores actualmente que tratan de asumir el papel del analista. No siempre se dan buenos resultados.
18 Necesidad de un ambiente colaborativoCompartir objetivos en común. Beneficios son para todas las partes involucradas. El analista como “puente” de comunicación debe tratar de establecerlo. Relación Ganar/Ganar.
19 Documentando Requerimientos
20 Documentando requerimientosSe puede hacer de varias formas: Lenguaje natural estructurado. Modelos gráficos Especificaciones formales usando modelos matemáticos Todos generan las SRS (Software Requirement Specifications)
21 Especificación de los requerimientos de software (SRS)Muchos actores dependen de los SRS: Clientes Administradores de proyecto Equipo de desarrollo Equipo de pruebas Equipo de mantenimiento Documentadores Personal de capacitación Staff legal Subcontratadores
22 SRS (cont.) Al escribir SRS se debe tener en cuenta las siguiente recomendaciones de legibilidad: Establecer niveles, secciones y requerimientos individuales (jerarquías) Utilizar sangrías Usar espacios en blanco Usar elementos visuales (negrillas, etc) Crear tablas de contenidos Numerar las figuras de las tablas Utilizar referencias cruzadas Usar hipervínculos Utilizar plantillas
23 Interfaces de usuario y SRSIncorporar diseños de la interfaz de usuario en los SRS tiene inconvenientes y beneficios. Inconvenientes: Los pantallas describen la solución no los requerimientos. Incluir IU puede retrasar la salida de los SRS Puede producir brechas funcionales. Las pantallas no sustituyen los req. Funcionales.
24 Interfaces de usuario y SRS (cont.)Beneficios Se puede visualizar mejor las soluciones o los requerimientos. Contar GUI permite medir o estimar tiempo o esfuerzo. Se debe analizar y llegar a un balance de cuando y cuanto las IU son importantes dentro de las SRS.
25 Plantillas para SRS Incluyen Introducción PropósitoConvenciones de documento Tipos de lectores y sugerencias de lectura Cronograma Referencias
26 Plantillas para SRS (cont.)2. Descripción global a. perspectiva del producto b. características del producto c. Tipos de usuarios y sus características d. Ambiente operacional e. Diseño e implementación de restricciones f. Documentación del usuario g. Supuestos y dependencias.
27 Plantillas para SRS (cont.)3. Características del sistema (para c/u) a. Descripción y prioridad b. Secuencia de estímulo / respuesta c. Requerimientos funcionales 4. Requerimientos externos de interfaz a. Interfaz de usuario b. Interfaz de hardware c. Interfaz de software d. Interfaz de comunicaciones
28 Plantillas para SRS (cont.)5. Requerimientos no funcionales a. requerimientos de rendimiento. b. requerimientos de seguridad c. requerimientos de acceso d. Atributos de Calidad de software 6. Otros requerimientos 7. Glosario 8. Modelos de análisis 9. Lista de inconvientes
29 Guía para escribir requerimientosEscriba oraciones completas con una gramática correcta. Utilice sujetos en la oración Sea consecuente con el glosario: cuide los sinónimos Ser detallista al escribir Explique el orden de cada comportamiento del sistema Identifique actores en cada situación Utilice apoyos visuales, como listas, tablas, etc. Enfatice lo más importante Evite el lenguaje ambiguo.
30 Diccionario de datos Es un depósito compartido que define el significado, el tipo de datos, longitud, formato, precisión necesaria, lista de valores permitida para todos los elementos de datos o atributos utilizados en la aplicación.
31 Administración de Requerimientos Principios y Prácticas
32 Se compone de: Control de cambios de la línea baseControl de versiones Seguimiento de estado de requerimientos Trazado (Tracing) de requerimientos Trazado de requerimientos: es la forma en que se pueden trazar los requerimientos a través de todo el ciclo de vida: requerimientos, diseño de esos requerimientos, código, casos de pruebas, ejecuciones de pruebas, artefactos de instalación, etc. Se pueden usar matrices de trazabilidad, pero las herramientas modernas proporcionan formas automatizadas de generar esta trazabilidad.
33 Los proyectos pueden responder a nuevos cambios o cambios en los requerimientos por varias vías:Cambios en la prioridad de los requerimientos Obtener staff adicional Aprobación de pago de horas extra Sacrificar calidad para cumplir con tiempos de entrega. (NO RECOMENDADO)
34 Requerimientos de la línea baseSon el conjunto de requerimientos funcionales y no funcionales que el equipo desarrollador se compromete a satisfacer en una entrega. Esta línea base da a los usuarios una idea clara de los que deben esperar de esa entrega. El SRS de la línea base debe contener sólo las especificaciones de los reqs de esta línea base. Línea base de los requerimientos: es la primera versión aprobada de los requerimientos. A partir de que la línea base se ha definido los cambios sobre los requerimientos deben hacerse por medio del procedimiento de gestión de cambios
35 Procedimientos de la administración de requerimientos (AR)Control de las versiones de los req. Los administradores de proyecto deben asegurarse de que todo el equipo este al tanto de los cambios en los requerimientos y se debe asegurar que todos trabajen con la última versión de éstos.
36 Atributos de los requerimientosCada req. es un objeto que posee atributos y propiedades que lo describen y lo conecta con los demás req, ej: Fecha creación Número de versión Autor (quien lo redactó o lo recopiló) Responsable de que el req. se satisfaga Dueño de req. (stakeholder) Estado del req. Origen o fuente del req. La razón detrás del req. Subsistemas al cual el req. esta situado. Producto liberado al cual el req. esta asociado. Método de verificación Implementación prioritaria Estabilidad: que tan probable sea que el req. cambie
37 Seguimiento de requerimientosLos administradores deben establecer mecanismos o iteraciones que les permitan saber la exactitud del avance de cada requerimiento. Se pueden establecer diferentes estados a los requerimientos: Propuesto Aprobado Implementado Verificado Atrasado Rechazado
38 Esfuerzo de la Administración de RequerimientosEl esfuerzo que se destina a un proyecto no siempre se puede medir solo con el tiempo. Algunas actividades para medir el esfuerzo son: Someter cambios o proponer nuevos req. Evaluar los cambio propuesto incluyendo el análisis de impacto en el rendimiento. Actualizar las versiones de los req. Actualizar la línea base Comunicar los cambios a las partes Dar seguimiento al estado de cada req. Almacenando información de rastreabilidad de cada req.
39 Los Cambios Ocurren
40 Muchas veces los desarrolladores no pueden estimar el impacto que un cambio en los requerimientos puede ocasionar al desarrollo de un proyecto. Los desarrolladores no son comúnmente buenos realizando estimaciones de tiempo y esfuerzo cuando un cambio ocurre. Un cambio destruye los cronogramas, producen atrasos, etc.
41 Una adecuada administración de req. debe:Estudiar a fondo los cambios antes de ser aprobados. Decidir cuando un cambio es apropiado en un momento dado. Los cambio aprobados deben ser comunicados a todas las partes. Los cronogramas deben permanecer actualizados
42 El proceso de control de cambiosDentro de este proceso existe un documento que es el que permite dar trazabilidad a los cambios. Este documento incluye: Introducción Próposito Alcance Definiciones Esta sección define el propósito del cambio y lo sitúa dentro del proyecto. Roles y responsabilidades : Especifica quienes interviene en el cambio propuesto y a quienes afecta este cambio. Estado del cambio : Se refiere a los pasos o al ciclo por el que el cambio debe caminar.
43 El proceso de control de cambios (cont)Criterios de entrada Este ítem se refiere a que las partes involucradas deben conocer la existencia de la solicitud de cambio y deben expresar su aprobación. Tareas Evaluación del cambio o solicitud Decisión tomada Realizar el cambio Notificación a las partes En este apartado se explica el análisis al que fue sometida la solicitud de cambio, se describen los impactos que la aprobación del cambio conlleva y cómo se van a enfrentar estos impacto.
44 El proceso de control de cambios (cont)Verificación Verificación del cambio Instalación de producto Explica el proceso de verificación al que el cambio es sometido. Criterios de salida Explica de que forma la solicitud de cambio sale del proceso de administración, ya sea aprobado, rechazado o cancelado. Reporte de control de estado de los req. Representan resúmenes de tareas y solicitudes de cambios. Apéndice: SRS de los req.
45 Lo más importante es comprender que los cambios ocurren y que el equipo desarrollador debe establecer mecanismos efectivos para realizar una buena administración de estos cambio. Una mala administración de cambios genera desorden, pérdida de tiempo y puede provocar el fracaso del proyecto.