Ingeniería de Requerimientos.
El término Requirements Engineering es acuñado en 1977 a través de un reporte técnico por parte del TRW Defense and Space Systems Group en Estados Unidos, el cual hace énfasis en la problemática de la “pobre” definición de los requerimientos de software y el alto costo que esto implica en los proyectos.
Investigadores
en el área de software comienzan a formular metodologías, herramientas y
técnicas para la definición de requerimientos. Esta comunidad va tomando fuerza
y es en 1993 cuando surge el primer simposio en Ingeniería de Requerimientos
(RE, por sus siglas en inglés).
Anualmente
se realiza una conferencia para discutir los problemas relacionados con este
tema. La edición número 25 se llevará a cabo este año en Lisboa, Portugal, con
la participación de profesionales de la industria y reconocidos autores de
libros sobre ingeniería de software, como Ian Sommerville.
Las Metas de RE
La
ingeniería de requerimientos (RE) es un proceso sistemático y disciplinado para
la especificación y administración de éstos con las siguientes metas:
Entender el problema por el que surge la necesidad del software.
Conocer
los requerimientos relevantes y lograr un consenso entre los stakeholders
(personas interesadas en el software que toman decisiones sobre los requerimientos).
Documentar
las necesidades de los stakeholders.
La
fase de definición de requerimientos es sumamente importante, ya que se
necesita mucha disposición por parte del cliente o usuario, y de paciencia y
creatividad por parte de los analistas para lograr buenos resultados.
INGENIERIA DE REQUERIMIENTOS
Ingeniería
de Requerimientos
El
término Requirements Engineering es acuñado en 1977 a través de un reporte
técnico por parte del TRW Defense and Space Systems Group en Estados Unidos, el
cual hace énfasis en la problemática de la “pobre” definición de los
requerimientos de software y el alto costo que esto implica en los proyectos.
Investigadores
en el área de software comienzan a formular metodologías, herramientas y
técnicas para la definición de requerimientos. Esta comunidad va tomando fuerza
y es en 1993 cuando surge el primer simposio en Ingeniería de Requerimientos
(RE, por sus siglas en inglés).
Anualmente
se realiza una conferencia para discutir los problemas relacionados con este
tema. La edición número 25 se llevará a cabo este año en Lisboa, Portugal, con
la participación de profesionales de la industria y reconocidos autores de
libros sobre ingeniería de software, como Ian Sommerville.
Las
Metas de RE
La
ingeniería de requerimientos (RE) es un proceso sistemático y disciplinado para
la especificación y administración de éstos con las siguientes metas:
Entender
el problema por el que surge la necesidad del software.
Conocer
los requerimientos relevantes y lograr un consenso entre los stakeholders
(personas interesadas en el software que toman decisiones sobre los requerimientos).
Documentar
las necesidades de los stakeholders.
La
fase de definición de requerimientos es sumamente importante, ya que se
necesita mucha disposición por parte del cliente o usuario, y de paciencia y
creatividad por parte de los analistas para lograr buenos resultados.
4
pasos al definir los requerimientos
Las
actividades principales del proceso de definición de requerimientos pueden
dividirse en cuatro:
1
Extracción
Consiste
en una comunicación intensa con el cliente/usuario para establecer claramente
el problema que requiere una solución.
Diferentes
técnicas deben ser usadas en combinación para obtener la mayor cantidad de
información.
Algunas
técnicas: entrevistas, cuestionarios, prototipos (en papel) y sesiones de
lluvia de ideas, entre otros.
Inicia
una vez que se cuenta con la información obtenida.
Usa
técnicas de modelado y lenguajes como UML y BPMN para plasmar conceptos que son
parte del problema y que formarán parte de la solución.
Lo
ideal es que haya una iteración de las primeras dos actividades antes de pasar
a la especificación, aunque pueden repetirse en cualquier momento.
3
Especificación
El
objetivo es documentar los requerimientos en formatos establecidos.
Los
modelos generados en la etapa de análisis también forman parte de la
especificación.
Documentos
con el listado de requerimientos funcionales, no funcionales, reglas de
negocio, casos de uso y diagramas de estados y clases, por ejemplo, conforman
el paquete que especifica el software a ser construido.
4
Validación y verificación
La
información que ha sido documentada en la especificación debe ser validada por
el cliente, de forma que esté de acuerdo con lo establecido.
En
caso de que no esté completamente satisfecho, el ingeniero de requerimientos
debe negociar posibles extensiones.
La
parte de verificación sucede una vez que se tiene el software en
funcionamiento, es decir, hay una estrecha relación entre la verificación y las
pruebas, ya que debe confirmarse que el software realiza lo especificado en los
documentos.
La
administración de requerimientos es ortogonal a las actividades anteriores y
comprende cualquier medida que sea necesaria para estructurar los
requerimientos, mantener la consistencia después de los cambios y asegurar la
implementación.
Todos
los integrantes del equipo de desarrollo deben aportar sus conocimientos y
experiencia en cada actividad del proceso de levantamiento. Es cierto que un
ingeniero de requerimientos tendrá mayor dominio durante esta fase, pero es
importante que cada integrante opine y contribuya con preguntas, dudas y
cuestionamientos para presentarlas al cliente/usuario.
Cada
reunión con el cliente es valiosa y hay que tomar nota de todo lo que menciona.
Todo esto debe ser interpretado y plasmado en diagramas, prototipos o alguna
otra representación gráfica que permita al equipo ir analizando y consolidando
las ideas, a fin de aterrizarlas en una solución que sea factible.
El
proceso de levantamiento de requerimientos es iterativo y debe repetirse
cuantas veces sean necesarias para refinar aquellos que no son claros, están
incompletos o que no han sido validados por el cliente. Pero es cierto que los
factores tiempo y presupuesto determinan el momento en que la fase de
requerimientos acaba para comenzar el desarrollo. Es por esta razón que la
negociación con el cliente tiene que iniciar desde que el equipo ha
identificado los requerimientos esenciales y los que pueden omitirse o
implementarse en versiones posteriores.
AUTORES:
Eduardo Jafet Diaz Hernández
Los 4 pasos para definir requerimientos.
Las actividades principales del proceso de definición de requerimientos pueden dividirse en cuatro:
Extracción
Consiste en una comunicación intensa con el cliente/usuario para establecer claramente el problema que requiere una solución.
Diferentes técnicas deben ser usadas en combinación para obtener la mayor cantidad de información.
Algunas técnicas: entrevistas, cuestionarios, prototipos (en papel) y sesiones de lluvia de ideas, entre otros.
Análisis
Inicia una vez que se cuenta con la información obtenida.
Usa técnicas de modelado y lenguajes como UML y BPMN para plasmar conceptos que son parte del problema y que formarán parte de la solución.
Lo ideal es que haya una iteración de las primeras dos actividades antes de pasar a la especificación, aunque pueden repetirse en cualquier momento.
Especificación
El objetivo es documentar los requerimientos en formatos establecidos.
Los modelos generados en la etapa de análisis también forman parte de la especificación.
Documentos con el listado de requerimientos funcionales, no funcionales, reglas de negocio, casos de uso y diagramas de estados y clases, por ejemplo, conforman el paquete que especifica el software a ser construido.
Validación y verificación
La información que ha sido documentada en la especificación debe ser validada por el cliente, de forma que esté de acuerdo con lo establecido.
En caso de que no esté completamente satisfecho, el ingeniero de requerimientos debe negociar posibles extensiones.
La parte de verificación sucede una vez que se tiene el software en funcionamiento, es decir, hay una estrecha relación entre la verificación y las pruebas, ya que debe confirmarse que el software realiza lo especificado en los documentos.
La administración de requerimientos es ortogonal a las actividades anteriores y comprende cualquier medida que sea necesaria para estructurar los requerimientos, mantener la consistencia después de los cambios y asegurar la implementación.
Todos los integrantes del equipo de desarrollo deben aportar sus conocimientos y experiencia en cada actividad del proceso de levantamiento. Es cierto que un ingeniero de requerimientos tendrá mayor dominio durante esta fase, pero es importante que cada integrante opine y contribuya con preguntas, dudas y cuestionamientos para presentarlas al cliente/usuario.
Cada reunión con el cliente es valiosa y hay que tomar nota de todo lo que menciona. Todo esto debe ser interpretado y plasmado en diagramas, prototipos o alguna otra representación gráfica que permita al equipo ir analizando y consolidando las ideas, a fin de aterrizarlas en una solución que sea factible.
El proceso de levantamiento de requerimientos es iterativo y debe repetirse cuantas veces sean necesarias para refinar aquellos que no son claros, están incompletos o que no han sido validados por el cliente. Pero es cierto que los factores tiempo y presupuesto determinan el momento en que la fase de requerimientos acaba para comenzar el desarrollo. Es por esta razón que la negociación con el cliente tiene que iniciar desde que el equipo ha identificado los requerimientos esenciales y los que pueden omitirse o implementarse en versiones posteriores.
¿Cómo redactar los requerimientos de un sistema?
CLARIDAD Y NO AMBIGÜEDAD. Cada requerimiento debe especificar una necesidad simple; sea breve y simple, es importante no ser mal interpretado. Las frases simples son suficientes para un buen requerimiento.
- El Sistema debe proveer…
- El Sistema debe hacer cumplir con…
- El Sistema debe tener una interfaz con…
SCRUM
• El conjunto de buenas prácticas de Scrum se aplica esencialmente a la gestión del proyecto
• Es un framework, por lo que es necesaria su adaptación en cada organización o incluso en cada equipo
• El objetivo es obtener resultados rápidos con adaptación a los cambios de las necesidades de los clientes
• Las principales características de Scrum
• El desarrollo software mediante iteraciones incrementales
• Las reuniones a lo largo del proyecto
Scrum se basa en entregas parciales priorizadas por el beneficio que aporta al receptor final del producto
• Actividades estructurales
• Requisitos
• Análisis
• Diseño
• Evolución
• Entrega
• Dentro de cada actividad las tareas se organizan con un patrón de proceso denominado sprint
• El trabajo del sprint se adapta al problema y se define y modifica en tiempo real por el equipo Scrum
• Uso de patrones de proceso de demostrada eficacia en proyectos críticos, con plazos cortos y requisitos cambiantes
• Scrum define un ciclo de vida iterativo e incremental, que mejora la gestión del riesgo y aumenta la comunicación
• Se basa en tres pilares
• Transparencia
• Todos los aspectos del proceso que afectan al resultado son visibles para todos aquellos que administran dicho resultado
• Inspección
• Se debe controlar con la suficiente frecuencia los diversos aspectos del proceso para que puedan detectarse variaciones inaceptables en el mismo
• Revisión
• El producto debe estar dentro de los límites aceptables
• En caso de desviación se procederá a una adaptación del proceso y del material procesado
• Mecanismo de mejora continua, esto es, de control, para adaptarse y mejorar
Cada equipo Scrum tiene tres roles
• Scrum Master. Es el responsable de asegurar que el equipo Scrum siga las prácticas de Scrum. Sus funciones
• Ayudar a que el equipo y la organización adopten Scrum
• Liderar el equipo Scrum para buscar la mejora en la productividad y la calidad de los entregables
• Ayudar a la autogestión del equipo
• Gestionar e intentar resolver los impedimentos con los que el equipo se encuentra para cumplir las tareas del proyecto
• Product owner. Es la persona responsable de gestionar las necesidades que se quieren satisfacer mediante el desarrollo del proyecto. Sus funciones
• Recolectar las necesidades (historias de usuario)
• Gestionar y ordenar las necesidades
• Aceptar el producto software al finalizar cada iteración
• Maximizar el retorno de la inversión del proyecto
• Equipo de desarrollo. Tiene las siguientes características
• Autogestionado. El mismo equipo supervisa su trabajo (no existe el rol clásico de jefe de proyecto)
• Multifuncional. Cada integrante del equipo debe ser capaz de realizar cualquier función
• No distribuidos. Es conveniente que el equipo se encuentre en el mismo lugar físico
• Tamaño óptimo. Al menos tres personas, máximo nueve, sin contar al scrum master ni al product owner
Acciones de los patrones de proceso
• Retraso (pila de producto o product backlog): priorización de requisitos. Debe estar detallado de manera adecuada, estimado, emergente y priorizado
• Sprints: unidades de trabajo requeridas para alcanzar un requisito. Es cada iteración. Se recomiendan iteraciones cortas (1-4 semanas) y cuyo resultado será un producto software potencialmente entregable. El equipo de desarrollo selecciona las historias de usuario que se van a desarrollar en el sprint para conformar así la pila de sprint (sprint Backlog). La definición de cómo descomponer, analizar o desarrollar este sprint backlog queda a criterio del equipo de desarrollo. Además, la lista de tareas se mantendrá inamovible durante toda la iteración
• Reuniones Scrum: reuniones breves dirigidas por el maestro Scrum
• Demostraciones preliminares: entrega de un incremento al cliente
Suscribirse a:
Entradas (Atom)
