Como se dijo, la habilidad del analista para interactuar con el cliente es fundamental; lo común es que el cliente tenga un objetivo general o problema a resolver, no conoce en absoluto el área (informática), ni su jerga, ni siquiera sabe con precisión qué debería hacer el producto software (qué y cuantas funciones) ni, mucho menos, cómo debe operar. En otros casos menos frecuentes, el cliente "piensa" que sabe precisamente lo que el software tiene que hacer, y generalmente acierta muy parcialmente, pero su empecinamiento entorpece la tarea de elicitación. El analista debe tener la capacidad para lidiar con este tipo de problemas, que incluyen relaciones humanas; tiene que saber ponerse al nivel del usuario para permitir una adecuada comunicación y comprensión.
Escasas son las situaciones en que el cliente sabe con certeza e incluso con completitud lo que requiere de su futuro sistema, este es el caso más sencillo para el analista.
La tareas relativas a captura, elicitación, modelado y registro de requerimientos, además de ser sumamente importante, puede llegar a ser dificultosa de lograr acertadamente y llevar bastante tiempo relativo al proceso total del desarrollo; al proceso y metodologías para llevar a cabo este conjunto de actividades normalmente se las asume parte propia de la Ingeniería de Software, pero dada la antedicha complejidad, actualmente se habla de una Ingeniería en Requisitos[3] , aunque ella aun no existe formalmente.
Hay grupos de estudio e investigación, en todo el mundo, que están exclusivamente abocados a la idear modelos, técnicas y procesos para intentar lograr la correcta captura, análisis y registro de requerimientos. Estos grupos son los que normalmente hablan de la Ingeniería en Requisitos; es decir se plantea ésta como un área o disciplina pero no como una carrera universitaria en si misma.
Algunos requisitos no necesitan la presencia del cliente, para ser capturados y/o analizados; en ciertos casos los puede proponer el mismo analista o, incluso, adoptar unilateralmente decisiones que considera adecuadas (tanto en requerimientos funcionales como no funcionales). Por citar ejemplos probables: Algunos requisitos sobre la arquitectura del sistema, requisitos no funcionales tales como los relativos al rendimiento, nivel de soporte a errores operativos, plataformas de desarrollo, relaciones internas o ligas entre la información (entre registros o tablas de datos) a almacenar en caso de bases o bancos de datos, etc. Algunos funcionales tales como opciones secundarias o de soporte necesarias para una mejor o más sencilla operatividad; etc.
La obtención de especificaciones a partir del cliente (u otros actores intervinientes) es un proceso humano muy interactivo e iterativo; normalmente a medida que se captura la información, se la analiza y realimenta con el cliente, refinándola, puliéndola y corrigiendo si es necesario; cualquiera sea el método de ERS utilizado. EL analista siempre debe llegar a conocer la temática y el problema a resolver, dominarlo, hasta cierto punto, hasta el ámbito que el futuro sistema a desarrollar lo abarque. Por ello el analista debe tener alta capacidad para comprender problemas de muy diversas áreas o disciplinas de trabajo (que no son específicamente suyas); así por ejemplo, si el sistema a desarrollar será para gestionar información de una aseguradora y sus sucursales remotas, el analista se debe compenetrar en cómo ella trabaja y maneja su información, desde niveles muy bajos e incluso llegando hasta los gerenciales. Dada a gran diversidad de campos a cubrir, los analistas suelen ser asistidos por especialistas, es decir gente que conoce profundamente el área para la cual se desarrollará el software; evidentemente una única persona (el analista) no puede abarcar tan vasta cantidad de áreas del conocimiento. En empresas grandes de desarrollo de productos software, es común tener analistas especializados en ciertas áreas de trabajo.
Contrariamente, no es problema del cliente, es decir él no tiene por qué saber nada de software, ni de diseños, ni otras cosas relacionadas; sólo se debe limitar a aportar objetivos, datos e información (de mano propia o de sus registros, equipos, empleados, etc) al analista, y guiado por él, para que, en primera instancia, defina el "Universo de Discurso", y con posterior trabajo logre confeccionar el adecuado documento ERS.
Escasas son las situaciones en que el cliente sabe con certeza e incluso con completitud lo que requiere de su futuro sistema, este es el caso más sencillo para el analista.
La tareas relativas a captura, elicitación, modelado y registro de requerimientos, además de ser sumamente importante, puede llegar a ser dificultosa de lograr acertadamente y llevar bastante tiempo relativo al proceso total del desarrollo; al proceso y metodologías para llevar a cabo este conjunto de actividades normalmente se las asume parte propia de la Ingeniería de Software, pero dada la antedicha complejidad, actualmente se habla de una Ingeniería en Requisitos[3] , aunque ella aun no existe formalmente.
Hay grupos de estudio e investigación, en todo el mundo, que están exclusivamente abocados a la idear modelos, técnicas y procesos para intentar lograr la correcta captura, análisis y registro de requerimientos. Estos grupos son los que normalmente hablan de la Ingeniería en Requisitos; es decir se plantea ésta como un área o disciplina pero no como una carrera universitaria en si misma.
Algunos requisitos no necesitan la presencia del cliente, para ser capturados y/o analizados; en ciertos casos los puede proponer el mismo analista o, incluso, adoptar unilateralmente decisiones que considera adecuadas (tanto en requerimientos funcionales como no funcionales). Por citar ejemplos probables: Algunos requisitos sobre la arquitectura del sistema, requisitos no funcionales tales como los relativos al rendimiento, nivel de soporte a errores operativos, plataformas de desarrollo, relaciones internas o ligas entre la información (entre registros o tablas de datos) a almacenar en caso de bases o bancos de datos, etc. Algunos funcionales tales como opciones secundarias o de soporte necesarias para una mejor o más sencilla operatividad; etc.
La obtención de especificaciones a partir del cliente (u otros actores intervinientes) es un proceso humano muy interactivo e iterativo; normalmente a medida que se captura la información, se la analiza y realimenta con el cliente, refinándola, puliéndola y corrigiendo si es necesario; cualquiera sea el método de ERS utilizado. EL analista siempre debe llegar a conocer la temática y el problema a resolver, dominarlo, hasta cierto punto, hasta el ámbito que el futuro sistema a desarrollar lo abarque. Por ello el analista debe tener alta capacidad para comprender problemas de muy diversas áreas o disciplinas de trabajo (que no son específicamente suyas); así por ejemplo, si el sistema a desarrollar será para gestionar información de una aseguradora y sus sucursales remotas, el analista se debe compenetrar en cómo ella trabaja y maneja su información, desde niveles muy bajos e incluso llegando hasta los gerenciales. Dada a gran diversidad de campos a cubrir, los analistas suelen ser asistidos por especialistas, es decir gente que conoce profundamente el área para la cual se desarrollará el software; evidentemente una única persona (el analista) no puede abarcar tan vasta cantidad de áreas del conocimiento. En empresas grandes de desarrollo de productos software, es común tener analistas especializados en ciertas áreas de trabajo.
Contrariamente, no es problema del cliente, es decir él no tiene por qué saber nada de software, ni de diseños, ni otras cosas relacionadas; sólo se debe limitar a aportar objetivos, datos e información (de mano propia o de sus registros, equipos, empleados, etc) al analista, y guiado por él, para que, en primera instancia, defina el "Universo de Discurso", y con posterior trabajo logre confeccionar el adecuado documento ERS.
No hay comentarios:
Publicar un comentario