Miguel Ángel Garzón Sanabria

Rene vera
1) ¿Cuál cree que es la diferencias entre la elicitación de requisitos en un enfoque
tradicional y en el enfoque ágil?

Gestión de proyectos ágiles

La gestión ágil de proyectos es una metodología diseñada para responder al cambio y producir y
entregar el trabajo en ráfagas cortas o 'sprints'. Un equipo ágil puede administrar un proyecto
dividiéndolo en varias etapas y entregando una parte utilizable del proyecto en cada etapa. La
gestión ágil de proyectos requiere una constante colaboración y comunicación entre los miembros
del equipo para responder a las demandas producidas por el cambio. Inicialmente desarrollada para
proyectos de software es también adaptable a otras industrias.
 "Nuestra más alta prioridad es satisfacer un equipo de desarrollo es la
al cliente a través de la entrega conversación cara a cara.
temprana y continua de software de  Software funcional es la principal
valor. medida de progreso.
 Recibe el cambio en requisitos, incluso  Los procesos ágiles promueven el
avanzado en el desarrollo. Los procesos desarrollo sostenible. Los
ágiles aprovechan el cambio para la patrocinadores, desarrolladores y
ventaja competitiva del cliente. usuarios deberían poder mantener un
 Entregar software funcional e con ritmo constante de manera indefinida.
frecuencia, de un par de semanas a un  La atención continua a la excelencia
par de meses, con una preferencia a la técnica y al buen diseño aumenta la
escala de tiempo más corta. agilidad.
 Los empresarios y desarrolladores  La simplicidad - el arte de maximizar la
deben trabajar juntos a lo largo de todo cantidad de trabajo no realizado - es
el proyecto. esencial.
 Desarrolla proyectos alrededor de  Las mejores arquitecturas, requisitos y
personas motivadas. Bríndales el diseños surgen de equipos auto
entorno y apoyo que necesiten, y confía organizados.
en que hagan el trabajo.  A intervalos regulares, que el equipo
 El método más eficiente y efectivo para reflexione sobre cómo ser más efectivo,
transmitir información hacia y dentro de para sintonizar y ajustar su
comportamiento".
Gestión de proyectos tradicional
La gestión de proyectos tradicional es un conjunto universal de prácticas que se implementan en
cada campo relacionado con proyectos. Se utiliza para proyectos que tienen resultados y vida
predecible. El objetivo es crear un producto dentro de un marco de tiempo específico dentro de un
presupuesto fijo.
Inicio:  Encontrar posibles obstáculos

 Establecer los resultados del proyecto

 Establecer los objetivos del proyecto
Planificación:

 Estimar el tiempo y presupuesto

 Planificación y asignación de recursos
 Preparación de redes
 Desarrollar un plan de proyecto

Ejecución:

 Llevar a cabo el plan

 Evaluación regular del proyecto
 Comunicación entre los miembros del
equipo
 Documentación del trabajo realizado

Control de calidad y monitoreo:

 Controlar el entorno para minimizar el

cambio
 Control y control de calidad
 Establecimiento de progreso
 Revisar el proyecto si es necesario

Clausura:

 Presentar el proyecto al cliente

 Garantizar la satisfacción del cliente
 Cierre de contrato y pagos
2) ¿Cree que en un entorno ágil ya no es necesario documentar los
requisitos?
Las organizaciones adaptables al cambio comprendieron esto y comenzaron a
gestionar sus proyectos mediante la adopción de los principios y metodologías
ágiles. Y así, en estos contextos, uno de los artefactos que más comúnmente
pueden sufrir los avatares de los nuevos rumbos es la documentación. Uno de los
valores de Agile Manifestó es "software de trabajo sobre documentación completa”.
Y sin embargo, existe la necesidad de documentar los requisitos. Si una función
desarrollada hace 6 meses está siendo modificada, yo (como desarrollador)
necesito un lugar al que acudir para hacer referencia a los requisitos existentes. Los
requisitos documentados son obviamente importantes también para los recursos de
control de calidad. Además, si surge una pregunta sobre un requisito en particular,
debe haber una única ubicación a la que se pueda hacer referencia para una
aclaración en lugar de requerir que analice a través de mi código o una cadena de
correos electrónicos para ver cómo se construyeron las cosas.

3) ¿Será que en el contexto ágil no aplican las técnicas de elicitación de

requisitos?
claro que se puede aplicar por que se requiere información de los requisitos o de lo
que el cliente desea que su sistema lo haga, igual que la metodología tradicional
aún se necesita información certera y coherente para el plantíamente de requisitos
para el desarrollo del proyecto .no obstante las metodologías agiles tratan de
optimizar el tiempo lo más posible evitando pasos innecesarios

4) ¿Qué técnicas de licitación aplican según el enfoque metodológico?

1. Entender el dominio de aplicación: Es importante investigar y examinar el
mundo real en el cual residirá el sistema. Los aspectos políticos, organizacionales
y sociales del entorno actual deben ser explorados, así Elicitación Análisis
Especificación Validación como las restricciones sobre el sistema y su desarrollo,
todo lo anterior conocido como modelado del negocio.
2. Identificar las fuentes de requisitos: Existe un conjunto de fuentes de requisitos
en cada proyecto de desarrollo de software. Usuarios y expertos abastecen de
información detallada acerca del problema y necesidades del usuario. Sin
embargo, cualquier persona con algún interés en el proyecto posee información
relevante a considerar para el desarrollo de la solución. Los procesos y sistemas
existentes representan, también, fuentes de requisitos, especialmente cuando se
trata de un remplazo o readaptación de sistemas. Además, la documentación
existente como manuales, formularios y reportes, incluso especificaciones de
requisitos anteriores, puede proveer información útil acerca de la organización y su
entorno, así como requisitos del nuevo sistema. Esta investigación considera las
fuentes humanas.
3. Analizar los interesados: Uno de los primeros pasos en el proceso es el análisis
e identificación de todas las personas relevantes que tienen un grado de interés en
el proyecto. Además de esto, se debe identificar los usuarios representantes clave.
4. Seleccionar las técnicas, enfoques y herramientas a usar: En la mayoría de los
proyectos se utilizan varias técnicas y herramientas, en muchos casos
complementarias, a lo largo del proceso de requisitos. Algunos autores plantean
mecanismos de selección.
5. Elicitar los requisitos a partir de los interesados y otras fuentes: Durante esta
actividad es importante establecer el nivel de alcance del sistema e investigar en
detalle las necesidades de los interesados en el proyecto, especialmente los
usuarios. Para apoyar este proceso, en muchas publicaciones se expone la
necesidad de contar con una estrategia de elicitación, es decir una guía para
identificar las fuentes correctas de requisitos e información del contexto, y obtener
los requisitos del sistema deseado de ellas (Saiedian & Dale, 2000

5) ¿En qué consiste la etapa de análisis de requisitos dentro

de la ingeniería de requisitos?
El punto de vista que de la fase del Análisis de Requisitos realiza la Ingeniería del
Software (IS) «clásica» establece los servicios que el sistema debe proporcionar y
las restricciones bajo las cuales debe operar. Se especifican las condiciones que
determinan qué debe hacer el sistema y cómo debe hacerlo, o sea requisitos:
Funcionales, que describen una funcionalidad o un servicio del sistema.
No funcionales, que suelen ser restricciones al sistema (p. e., tiempo de
respuesta) o para su proceso de desarrollo (utilizar un determinado lenguaje).
Por otra parte, los modelos de Ingeniería de los Requisitos añaden nuevos
factores a tener en cuenta que, de realizarse, garantizarán el desarrollo de un
sistema con un grado mucho tanto desde el punto de vista funcional como de su
usabilidad y de su accesibilidad.

6) ¿Que técnicas y/o herramientas son usadas para el análisis de

requisitos según las metodologías tradicionales, orientado a objetos y
ágiles?
1. Analizar los requisitos de información: El objetivo principal de esta tarea es
descubrir conflictos en los requisitos profundizando en el conocimiento del
problema y estableciendo las bases para un futuro diseño del sistema. En el caso
concreto de esta tarea, el objetivo es descubrirlos en los requisitos de
almacenamiento de información. La forma habitual de alcanzar estos objetivos es
mediante la construcción de modelos abstractos. Los productos resultantes de la
realización de esta tarea son el modelo estático del sistema.
2. Analizar los requisitos funcionales: Esta tarea es similar a la anterior, con la
diferencia de que se centra en los requisitos funcionales, expresados mediante
casos de uso, para analizar los requisitos funcionales lo habitual es construir
modelos funcionales y, si se considera oportuno, modelos dinámicos.
3. Analizar los requisitos no funcionales: Esta tarea tiene también como objetivo
descubrir conflictos en los requisitos, en este caso en los requisitos no funcionales.
Sin embargo, a diferencia de las dos tareas anteriores, normalmente estos
requisitos se tendrán en consideración durante el diseño de la arquitectura del
sistema (Ruiz, Corchuelo, Durán, Martín, & Pérez, 2000). Los productos
resultantes de esta tarea son aquellos conflictos que se hayan detectado al
realizar el análisis de los requisitos no funcionales.
4. Desarrollo de prototipos: El objetivo de esta tarea es el desarrollo de prototipos
que puedan utilizar se durante la elicitación o validación de los requisitos, y que
por lo tanto deben centrarse en la interfaz de usuario.

7) ¿Cómo debe ser el análisis de requisitos según el enfoque

metodológico?

Los enfoques orientados por aspectos asociados a la ingeniería de los requisitos

proponen mecanismos que facilitan la identificación, separación y clasificación de
intereses y la composición de intereses transversales. Para realizar el comparativo,
se estudiaron los siguientes enfoques: separación multidimensional de intereses,
aspectos en modelos de objetivos de requisitos (ARGM) identificación de aspectos
en los requisitos Theme/ Doc y AOSD con casos de uso. En 2.1 a 2.4 se presentan
generalidades de los enfoques que se analizarán en la sección 3.

2.1 Separación multidimensional de intereses (MDSOC)

Este enfoque es pionero en el tratamiento de los aspectos en la fase de requisitos.

Se basa en el enfoque de Puntos de Vista (Viewpoints) y su fortaleza está centrada
en el tratamiento de las reglas de composición de los intereses, así como en la
definición y manejo de conflictos. La orientación multidimensional permite analizar
el espacio de intereses del problema de forma homogénea. Para lograr esto define
un interés como la agrupación de requisitos funcionales y no funcionales de cada
punto de vista del sistema.

2.2 Aspectos en modelos de objetivos de requisitos (ARGM)

Este enfoque integra las propuestas I* y NFR (Non-Functional Requirements

Framework) agregando el concepto de aspectos. Utiliza un grafo en forma de V
(llamado V-Graph) que contiene en sus vértices superiores objetivos funcionales
(goals) y objetivos de calidad (softgoals) que pueden cruzar diferentes objetivos
funcionales; en su vértice inferior se ubican las tareas u operaciones que debe
realizar el sistema. Define un proceso sistemático e iterativo que va
descomponiendo los objetivos hasta llegar al nivel de las tareas. Durante el proceso
de descomposición se verifica el nivel de contribución de dichas tareas para el
cumplimiento de los objetivos de calidad, lo cual permitirá detectar los conflictos que
puedan presentarse y tomar acciones al respecto; si una tarea se encuentra
relacionada con más de un objetivo, se convierte en candidata a aspecto .

2.3 Identificación de aspectos en los requisitos: Theme/Doc

Theme/Doc es la primera fase del enfoque Theme que describe un proceso de

desarrollo orientado por temas. La aproximación se centra en el concepto de tema
que representa una pieza de funcionalidad, asunto o interés que se quiere modelar
de forma separada del sistema. Theme/Doc parte de una descripción textual de los
requisitos en la cual se realiza un análisis gramatical para detectar las relaciones
entre los requisitos y las acciones (minor actions); a partir de estas acciones se
derivan las acciones de mayor granularidad (major action) o asuntos que
representan la solución de software y que entran al proceso de diseño siguiendo las
características de Theme/UML .

2.4 AOSD con casos de uso (AOSD/UC)

Este enfoque trata los requisitos funcionales desde los casos de uso que
representan la función básica del sistema (peer use cases). Los requisitos no
funcionales se representan en casos de uso que extienden un caso de uso de
infraestructura, el cual se parametriza al igual que el actor que lo usa (los parámetros
representan el comportamiento que se cruzará en la funcionalidad de los casos de
uso base). En el análisis y el diseño los casos de uso se representan en una
estructura de composición que se identifica con el estereotipo <use case slice> y
agrupa elementos de modelo que colaboran para lograr los requisitos del sistema
(funcionales y no funcionales) .