TRADUCCION DEL CAPITULO 2

Capítulo 1 hizo hincapié en la importancia de los requisitos. Se observó que los clientes, gerentes y
desarrolladores subestiman la ingeniería de requisitos. La AR se encuentra en una posición estratégica
para mejorar las prácticas en uso en los proyectos y en la organización. El analista puede tener un
impacto positivo en el éxito del proyecto, además de facilitar los resultados de mejora de la
organización mediante la realización de varias funciones. Haciendo rol contribuye explícitas de la RA
a un proceso más suave. El papel de la RA puede vincularse fácilmente a los objetivos de negocio,
tales como el aumento de la satisfacción del cliente con los productos de trabajo entregados; reducir el
tiempo de comercialización de los productos; cumplimiento de los objetivos de costos, cronograma y
calidad; y la utilización de los recursos humanos de la empresa con mayor eficacia. El papel de la RA
necesita ser entendida y valorada en la mente de los PM y las comunidades técnicas (tanto compu-
tación y de ingeniería). Tabla 2.1 resume las funciones de la RA, tomando nota de las fases del ciclo
de vida en que se realiza cada función
ROLES SUGERIDOS DE LA RA
1. Trabajar en colaboración con los clientes, usuarios y arquitectos de sistemas y
diseñadores para identificar las necesidades reales de un sistema o de desarrollo de
software esfuerzo planificado para definir el problema que necesita ser resuelto.
El concepto de las necesidades reales se explicó en el Capítulo 1. La experiencia ha demostrado que
el número uno del problema en la ingeniería de requisitos es la falta de identificación de las
necesidades reales antes de iniciar las actividades de desarrollo del sistema. Cualquiera que haya
tenido alguna experiencia en sistemas o desarrollo de software estará de acuerdo en que la
identificación de las necesidades reales es un problema significativo. Con respecto a esta función, el
RA necesita crear una conciencia del problema y también proporcionan una sugerido estrategia para
superar el problema. Este es un ejemplo concreto de una situación que sabemos que puede ser
mejorado, pero más a menudo que no actúan en este conocimiento. Estamos impacientes por empezar
a trabajar en el llamado verdadero trabajo de programación. Nos contentamos para permitir que el
esfuerzo de desarrollo para proceder sin tomar el esfuerzo adicional para evolucionar las necesidades
reales. Tenga en cuenta que he utilizado la palabra "evolucionar". Este trabajo involucra a más de los
requisitos de identificación. La tarea esencial es utilizar los requisitos establecidos articulados por los
clientes y usuarios como base, esta pareja con un entendimiento profundo de los objetivos de negocio,
e iterar evolucionando requisitos que cumplen los criterios para un buen requisito y dirección
priorizados necesidades reales de el sistema o software. Actividades que participan en la realización
de este trabajo son los siguientes:

 Identificación de las necesidades expresadas por los clientes y usuarios. Esto implica revisar
las cosas previamente escrito sobre el sistema propuesto, inter viendo los clientes y usuarios,
el estudio de la legislación pertinente, y así sucesivamente.
 El estudio de los objetivos de negocio para el esfuerzo propuesto.
 La colaboración con clientes y usuarios en una cooperativa conjunta o ambiente ron ción para
analizar los requisitos indicados, evolucionan mejor los requisitos, y dar prioridad a ellos (ver
las técnicas sugeridas que siguen).
 La participación de arquitectos de sistemas en el desarrollo de los requisitos. Iterar los
requisitos proyectos o propuestas se traducirá en una arquitectura candidato con mejores
requisitos y una arquitectura más robusta. Por ejemplo, los sistemas tienen que ser capaz de
adaptarse a las cambiantes necesidades empresariales. La arquitectura debe ser diseñado y
desarrollado de acuerdo, o de lo contrario el sistema entregado pronto será obsoleta.
  La utilización de una herramienta requisitos industria resistencia automatizado para apoyar
este trabajo.
La RA debe trabajar dentro de la organización del proyecto para ganar el apoyo de la PM en la
obtención de compromiso de invertir el tiempo añadido y el esfuerzo de determinar las necesidades
reales. Aquí hay una gran oportunidad para la RA para asumir la responsabilidad y, basándose en la
experiencia de la industria, a convencer a la gestión y los desarrolladores de proyectos para invertir
más tiempo y esfuerzo en el proceso de requisitos. Afortunadamente, los datos están disponibles para
ayudarnos a manejar por los hechos y no por intuición o la forma en la que siempre hemos hecho las
cosas. Consulte Requisitos Prácticas Efectivas [1, p. 62] para estos datos. Considere el uso de técnicas
de obtención de requisitos de colaboración que funcionan bien en sesiones de grupo. Ejemplos de
buenas técnicas de obtención requisitos son talleres requisitos, groupware basada electrónico o
herramientas de desarrollo de colaboración electrónicos, diagramas de flujo de datos de alto nivel,
diagramas IDEF0 de alto nivel (sobre todo para el modelado de negocio), y el uso de diagramas de
casos de alto nivel (sobre todo para distinguir requisitos que son fuera del sistema en comparación con
el comportamiento esperado del sistema). Todos ellos funcionan bien en una pizarra, son fáciles de
entender, y permitir a todos los presentes a participar. Ver Dean Leffingwell y Don Widrig Gestión de
Requisitos de software: un enfoque unificado [2] para buenas discusiones de estos y otras técnicas y
cómo usarlos. David Hay proporciona una comparación útil de las técnicas que se pueden utilizar en
Análisis Requisitos: A partir de vistas empresariales a la Arquitectura (ver [3, p 194.] Y la discusión
precedente).
Tabla 2.1 Funciones de RA y del ciclo de vida de las Actividades
RA rol sistema de sistema sistema de sistema s. integración, s. operaciones
iniciación análisis componente de prueba y y apoyo
y Diseño de diseño implementación evaluación

1.Trabajar en colaboración con los clientes, usuarios y X X A A

A A
arquitectos de sistemas y diseñadores para identificar
los verdaderos requisitos para un sistema o software
que planifique esfuerzos de desarrollo para definir el
problema que necesita ser resuelto.

2.Trabajar de manera efectiva con los clientes y usuarios

para gestionar requisitos nuevos y modificados para que X X
X X
el proyecto se mantenga bajo control. Instalar un
mecanismo de control de cambios.

3. Estar alerta a las nuevas tecnologías que pueden ayudar. X X

X

4. Facilitar el proyecto en la reutilización de artefactos y X X X X

X
la consecución de repetitividad.

5. Ayudar al proyecto y sus clientes en la aspiración a una

senda de crecimiento desde el primer lanzamiento o X X X X
X X
versión de un producto a través de un conjunto de versiones
Escenificadas al "último sistema de productos.
6. Asesorar al proyecto (y cliente) de los métodos, técnicas y X X
X
herramientas automatizadas que están disponibles para mejorar
los requisitos-relacionados de apoyo al trabajo del proyecto
y actividades.

7. Utilice las métricas para medir, rastrear y controlar los B X X X

X X
Requisitos relacionados con las actividades de trabajo en los
proyectos y resultados.

8. Ser capaz de facilitar las discusiones y mediar con los conflictos. X X X X

X X

9. Estudiar el dominio de la zona en la que el sistema o software X X

X
está siendo utilizado.

Las fases del ciclo de vida que se muestran en la fila de arriba no pretenden ser una recomendación para un modelo de ciclo de vida cascada.
Más bien, el uso de la terminología de fase es la intención de representar la actividad que se realiza; esta actividad es igualmente aplicable a
prácticamente todos los modelos de ciclo de vida (por ejemplo, espiral, el desarrollo rápido de aplicaciones, incrementar el proceso unificado
racional), aunque los nombres de las fases del ciclo de vida sean diferentes.
A-Continuar para identificar las necesidades reales de lanzamientos y versiones posteriores, manteniendo el control de configuración.
B-Sistema inicial o "proyecto o tarea de inicio" es un tiempo confuso. La RA experimentado será capaz de prestar asistencia. Por ejemplo, el
RA debe proporcionar una sesión informativa para el equipo del proyecto que incluye los temas señalados en la Tabla 5.4.
 2. Trabajar de manera efectiva con los clientes y usuarios para gestionar los requisitos
nuevos y modificados para que el proyecto se mantiene bajo control. Instalar un
mecanismo de control de cambios.
El siguiente problema más grave de la ingeniería de requisitos (tras el fracaso para identificar las
necesidades reales) es la falta de control requisitos que se identifican después del desarrollo del
sistema (programación) comienza, tanto los nuevos requisitos y cambios en los requisitos existentes.
Aquí distinguimos entre los requisitos críticos (los que tendría un impacto en el precio, el horario, o el
esfuerzo de desarrollo si ha cambiado) y los requisitos de los no críticos, como una exigencia derivada
que define aún más el sistema que se está construyendo, pero sirve para aclarar una de mayor
requisito de nivel y no afecta el costo, horario, o la funcionalidad. Todos los interesados deberían
recibir a un requisito de "impacto no-" que aclara aún más el sistema. Una vez más, tenemos los datos
de experiencia en la industria para guiar nuestras acciones: un cambio del 20% de los requisitos dará
lugar a una duplicación de costos PROYECTO DE DESARROLLO [4]. Por lo tanto, es fundamental
que un mecanismo se puso en marcha para evaluar y adjudicar cambios en los requisitos. Sin un
mecanismo eficaz para controlar los cambios en los requisitos, el proyecto estará pronto fuera de
control en cuanto a horario y costo. Hay varias cosas que se deben hacer:

 La importancia del control de cambios en los requisitos se debe explicar a los clientes,
usuarios y desarrolladores para que se mantenga el compromiso de colaboración para el éxito
del proyecto.
 Los desarrolladores deben ser entrenados para no aceptar los requisitos de cambios no
autorizados. Todas las solicitudes de cambios, no importa lo trivial, deben ser canalizados a
través del mecanismo de control de cambios
 El mecanismo de control de cambios debe ser un equipo conjunto que incluye a los tomadores
de decisiones empoderadas que representan el cliente y el desarrollador. El equipo conjunto
debe cumplir con la frecuencia suficiente para tener un número razonable de las solicitudes de
cambio a considerar. Se recomienda una métrica meta de 0,5% los requisitos de la volatilidad
para guiar las decisiones tomadas por el equipo conjunto una vez a la línea de base de los
requisitos validados se ha establecida.1 "Whoa," usted dice, "que no es mucho!" ¡Muy bien!
Este es otro razones para invertir el tiempo necesario para desarrollar las necesidades reales
antes de iniciar las actividades de desarrollo.
 La asociación con su cliente, evolucionando formas de lidiar con el cambio. Sabemos que el
mundo está cambiando mientras estamos desarrollando el sistema. ¿Cuáles son algunas
maneras de lidiar con esto sin poner en peligro el éxito del proyecto? Considere el uso de
versiones, versiones y actualizaciones. Incrementos del paquete de requisitos de mejoras y
cambios en versiones posteriores o actualizaciones del sistema.
 Asegúrese de que el contrato prevé un tiempo adicional y el presupuesto para todos los
cambios. Este es un mecanismo para mantener buenas relaciones a lo largo del contrato de
trabajo a socio para el éxito. Los cambios cuestan tiempo y dinero. Esto debe ser reconocido
en la delantera y se refleja en el contrato.

3. ESTÉ ALERTA A LAS NUEVAS TECNOLOGÍAS QUE PUEDEN AYUDAR.

Un papel que a menudo subutilizado es asesorar a nuestros clientes en relación con la tecnología en
evolución. Si bien esto no es responsabilidad exclusiva de los analistas o ingenieros requisitos,
muchos involucrados en el desarrollo de sistemas para los clientes harían bien para pasar el tiempo y
el esfuerzo adicional de aprender sobre nuevas tecnologías y la forma en que se pueden aplicar a
nuestro trabajo. Los clientes se centran normalmente en lo que el sistema debe hacer. Podemos servir
mejor al estar familiarizados con las tecnologías que mejoran el funcionamiento del sistema está
diseñado necesaria evolución. Esto sugiere que los RA se beneficiará de tener diseñadores de sistemas
revisen sus productos de trabajo. Simultáneamente con los requisitos de elaboración, involucrar a un
pequeño equipo de diseñadores para revisar las necesidades reales de los impactos de costos,
calendario, tecnología y riesgo. Utilice-el proceso de estudios de comercio Análisis de Decisiones
Resolución (DAR) en CMMI alternativas terminología-evolucionando. Mantenga el cliente
involucrado en estas actividades, por lo que cuando se presente la oportunidad, el cliente está ahí para
colaborar con usted en la formulación de recomendaciones para las decisiones. Una excelente
referencia que describe el proceso de utilización de las nuevas tecnologías es la fusión rentes de
Everett M. Rogers of Innovations (4ª ed.) [5].

4. Facilitar la reutilización del proyecto de artefactos y repetibilidad lograr.

Ha habido mucha discusión en la literatura de la industria acerca de la reutilización. Reciclar tiene dos
significados: (1) para tomar objeto X (por ejemplo, un objeto, subrutinas, o COTS de software) que
fue hecho por Y y lo utilizan directamente en otro proyecto, y (2) para adaptar un producto del trabajo
desarrollado (una especificación , un plan o proceso, por ejemplo). Muchas organizaciones han
invertido en las estrategias de reutilización sólo para concluir que no son viables o práctico. Otros se
resisten a la reutilización porque creen que se opone a las soluciones sin precedentes e incorpora los
errores de los productos de trabajo reutilizados. Podemos considerar mismos requisitos que los
artefactos reutilizables. Los libros que tratan sobre los patrones de requisitos reutilizables incluyen
Patrones Modelo de datos: Convenios de pensamiento (para un punto de vista relacional) [6] por
David C. Hay, Patrones de Análisis (para un punto de vista orientado a objetos) por Martin Fowler
[7], y patrones de diseño de Eric Gamma, et al. [8]. Marcos de problemas de Michael Jackson
(descritos en su libro del mismo nombre [9]) están en esencia requisitos muy abstractos patrones que
se pueden conectar, anidadas, y construyen en los modelos del mundo real. El punto es que muchos de
los requisitos no son únicos; que ya han sido identificados en el medio ambiente y el problema de
espacio de otra persona. He encontrado en mis actividades de escritura que a partir de un producto de
ejemplo el trabajo me da ideas sobre el formato, la estructura, el contenido y los recursos para hacer
referencia o contacto. Un producto de ejemplo el trabajo es posible que desee considerar es un plan de
necesidades. Como se destaca en el capítulo 1, yo abogo por el desarrollo de un plan de necesidades
para cualquier esfuerzo de desarrollo del sistema o software. Esta idea puede ser nuevo para usted, y
sería muy útil e instructivo revisar uno desarrollado previamente con el fin de tener en cuenta su valor
potencial de su trabajo. Otro ejemplo de mi experiencia está reutilizando procesos documentados. Si
la organización u otro proyecto tiene un proceso documentado para hacer algo, ¿por qué no adaptar
según sea necesario y luego volver a utilizarlo, en lugar de crear su propio proceso? Otros que han
realizado el proceso en la práctica han incorporado su experiencia y las lecciones que han aprendido a
usarlo. Relacionado con esto está el valor de los exámenes por homólogos. Abogo por una revisión
por pares de cada producto de trabajo. (La extensión de la revisión por pares, el número de personas
que solicitó revisar el producto del trabajo y el tiempo invertido para realizar la revisión por pares e
informar sobre los defectos y hacer sugerencias nes-es una función de la importancia del producto del
trabajo.) Si se puede volver a utilizar el proceso de revisión por pares y listas de control de otra
organización, esto proporciona un salto de inicio en conseguir el proceso diseñado, aceptado,
desplegado, implementado, e institucionalizado.
Un ejemplo de reutilización de procesos.
Al enseñar requisitos cursos y tutoriales, siempre estoy interesado en saber cuántos de los
participantes están usando un proceso de requisitos documentados en su proyecto o en su
organización. Típicamente, esto resulta ser 15% a 20% de los participantes. Un proceso de
requerimientos de la muestra se proporciona en Requisitos Prácticas Efectivas [1, pp. 110-118]. Este
proceso se ha adaptado, desplegado, e implementado en más de 50 proyectos. Su integración con el
proceso de la arquitectura del sistema se describe más adelante en el libro [1, pp. 136-146].
Sugerencia: Sastre este proceso requerimientos de la muestra para su proyecto u organización.
Involucrar a las partes interesadas a hacer los cambios que mejor sirven a sus necesidades.
Proporcionar ambos diagramas de flujo y PD narrativos que se describen en Prácticas Requisitos
eficaces. Actualizar periódicamente el proceso documentado con las ideas de mejora continua y
sugerencias .
5. Ayudar al proyecto y sus clientes en la aspiración a un camino de crecimiento de la
primera liberación o la versión de un producto a través de una serie de lanzamientos por
etapas al sistema final o producto.
Esta función está relacionada con la función 3. La AR puede servir un papel importante y valioso en
ayudar a los clientes a imaginar y desarrollar una serie de lanzamientos y versiones de los productos.
Este enfoque es particularmente apropiado en la situación en la que los requisitos no se entienden bien
desde el principio, o las necesidades están cambiando rápidamente. Esto sugiere que un "enfoque de
desarrollo incremental" se debe utilizar, en que el sistema completo se implementa durante un período
de tiempo a través de incrementos de funcionalidad entregada. En cierto sentido, ningún sistema está
hecho nunca, así que tenemos que ayudar a todos a ver el desarrollo del sistema como un viaje.
Independientemente de la metodología de desarrollo de sistema utilizado (cascada, incremental
espiral, evolutivo, etc.), tiene que ser un proceso acordados para la gestión de cambios y determinar el
alcance de los proyectos individuales. No importa lo mucho debate y prueba que se hace, hay algunos
requisitos faltantes que no se descubrieron hasta que el sistema esté en producción.
6. Asesorar al proyecto (y cliente) de métodos, técnicas y herramientas automatizadas que
están disponibles para los mejores requisitos-relacionados de apoyo el trabajo del
proyecto y actividades.
Este es un papel importante. La experiencia ha demostrado que los métodos y las técnicas varían en su
aplicabilidad y eficacia y que las herramientas automatizadas menudo comprados por los proyectos y
las organizaciones no se utilizan o están subutilizados. Capítulo 11 de las Prácticas Requisitos
eficaces [1] informa de experiencia en el sector y ofrece una serie de recomendaciones. Capítulo 8 de
Prácticas Requisitos eficaces [1] recomienda que los métodos y técnicas que se utilizan por un
proyecto de ser familiar para los participantes del proyecto y probado en su respectiva industria. No es
aconsejable llevar a cabo un proyecto con, métodos y técnicas desconocidas no probadas. El trabajo
de desarrollo es lo suficientemente difícil sin introducir la complejidad de los métodos o técnicas que
no son familiares y no han sido utilizados con éxito en anteriores proyectos de la organización. A
nivel de proyecto, el equipo debe seguir con las herramientas, los procesos y las técnicas con las que
sus miembros están familiarizados. A nivel organizativo, el proyecto debe tratar de usar las
herramientas, procesos y técnicas que son conocidos y probados en la organización. Cuando los
contratistas se ponen en un esfuerzo existente, deben adaptarse a las herramientas que el cliente ya
tiene en su lugar (suponiendo que están trabajando con eficacia). Si se realizaron los últimos cinco
proyectos con la herramienta X, y todo el mundo está satisfecho con la utilidad de la herramienta, a
continuación, cuando llegue, hay buenas razones para utilizarlo. Tenga en cuenta que un problema de
recursos pueden estar involucrados. Idealmente, un RA sería un recurso apalancada, al pasar de un
proyecto a otro y tomando su experiencia con ella. Sin embargo, a menudo en la práctica, un equipo
de proyecto se construye (o ya existe) y alguien del equipo actual con el conocimiento de dominio
tiene la tarea de ser el RA. Aunque existen técnicas y herramientas probadas y verdaderas, que pueden
no estar familiarizados con esta persona, que requiere una curva de aprendizaje muy largo ya veces
doloroso, con desventajas significativas al proyecto. Esto aboga por la organización para proporcionar
un conjunto de asociaciones regionales experimentados que proporcionarán un alto retorno de la
inversión realizada para identificarlos, entrenarlos y darles experiencia. También recomiendo las
direcciones de los clientes difíciles de utilizar métodos específicos o técnicas que no están
familiarizados con el equipo del proyecto o no probada previamente en la práctica. Por ejemplo, un
cliente puede ordenar que se empleará un enfoque orientado (OO) el desarrollo a objetos (ver [10]
para las pautas reflexivas sobre este tema) o que una herramienta o instrumento privado automatizado
particular, se utilizarán. Es valioso para estar en condiciones de poder asesorar a su proyecto y su
cliente de los métodos, técnicas y herramientas automatizadas que mejor apoyen la situación
específica de desarrollo. Dibuje en la industria cia experimental y no pretender que "todo saldrá
bien.".
7. Usar las medidas para medir, rastrear y relacionan los requisitos de control de las
actividades de trabajo del proyecto y los resultados.
La literatura de la industria en relación con las métricas es enorme. Yo estimaría que tal vez el 20% de
los que proporciona consejo útil. Es fácil entrar en una situación de persona que forman las
actividades de medición por sí mismos, en lugar de ayudar a evaluar el trabajo del proyecto y tomar
las acciones correctivas. Recomiendo el uso de unos indicadores útiles. He desarrollado el siguiente
axioma en mi trabajo a lo largo de los años: Las cosas que se miden y rastreados y que la
administración presta atención a son los que mejoran. Esto sugiere que no es suficiente para tener
unos pocos útiles-que las métricas deben ser seguidos, y debe ser utilizado por la administración para
orientar las decisiones del proyecto. Hay un conjunto de medidas o indicadores que deben ser
utilizados por todos los proyectos. Ver Requisitos Prácticas Efectivas [1, pp. 255-261] para
sugerencias específicas. Hay otro nivel de sofisticación que se debe utilizar en los proyectos y las
organizaciones maduras. Tal como se utiliza aquí, "maduro" significa que los procesos se han
definido, documentado, implementado, usado, institucionalizada y mejorado continuamente durante
un período de por lo menos dos a cuatro años. Esto implica la gestión cuantitativa (QM) del costo,
horario, calidad y métricas de procesos y líneas de base en apoyo de los objetivos de negocio
específicos. Se está cumpliendo para ver los proyectos y las organizaciones pasar de la situación en la
que QM no se entiende bien a aquel en el que QM se utilice eficazmente para lograr los objetivos de
negocio. Esto es especialmente satisfactorio para los ingenieros de proceso, porque los ejecutivos
pueden conocer de primera mano el valor de la mejora de procesos para satisfacer las necesidades del
negocio.
8. Ser capaz de facilitar el debate y para mediar en los conflictos.
Este papel subraya los "don de gentes" de la RA. Hemos aprendido que el ser bien calificado
técnicamente es importante, pero que también es necesario tener fuertes así refinadas habilidades,
gente. La experiencia ha demostrado que dos cabezas piensan mejor que una, cada vez que nos
tomamos el tiempo para explorar ideas y enfoques con los demás, tenemos aún mejores ideas y
enfoques! Ergo, podemos colocar el punto de vista de que "nos conocemos mejor." Y podemos hacer
un buen uso de este principio al convertirse en buenos facilitadores y mediadores. Hay cursos dis-
ponibles para ayudar (por ejemplo, habilidades, trabajo en equipo, comunicación, relaciones y líder
negociación). Mucho se puede ganar mediante la práctica de estas habilidades en nuestro trabajo
diario. Tener una perspectiva de "ganar-ganar" es útil, de hecho, Barry Boehm et al. han desarrollado
un enfoque de desarrollo de los requisitos de ganar-ganar en el trabajo realizado en la Universidad del
Sur de California.
9. Estudia el dominio de la zona en la que se está utilizando el sistema o software.
Ser capaz de comprender, abstracto, y expresar ideas de forma rápida en el idioma de los usuarios. Si
la RA no entiende el dominio de usuario casi tan bien como los que hacen los usuarios, se corre el
riesgo de limitar su papel al de un tomador de pedidos. He visto diferentes grupos van y vienen cuya
especialidad era la comunicación, consenso edificio ing, y así sucesivamente. Llenar esos grupos fue
un conjunto de personas que fueron facilitadores capacitados, pero que no eran técnicamente
competente. Se movían de un proyecto a tan frecuentemente que nunca alcanzaron una comprensión
profunda de dominio. Por ejemplo, ¿qué pasaría si, en un proyecto de comunicaciones de red, la única
manera de un RA puede explicar cualquier concepto a los usuarios es dando analogías con la
construcción de aviones militares? Respuesta: reducida eficacia y credibilidad.
Resumen.
La RA realiza varias funciones importantes en un proyecto y en una organización. Nueve papeles
importantes fueron identificados y descritos en este capítulo. Los dos primeros son de suma
importancia y es esencial para el éxito del proyecto. En consecuencia, el estudio de estos, alcanzar la
competencia en ellos, y ayudar a su proyecto y la organización en la adopción, implementación e
institucionalización de las prácticas relacionadas. Las organizaciones deberían considerar la adopción
de medidas concretas para desarrollar y aprovechar sus asociaciones regionales, tales como (1) la
garantía de que los RA experimentados son asignados a cada proyecto; (2) proporcionar una
formación adecuada a las asociaciones regionales; (3) la asignación de los RA con experiencia para
guiar a los nuevos empleados, RA junior, y pasantes; y (4) que tiene un grupo de requisitos de
organización de trabajo para compartir conocimientos y proporcionar un recurso para la organización.
La RA debe ser un intérprete capacitado, experimentado y fuerte. Por desgracia, he visto muchos
casos en que el nuevo empleado o el pasante de verano es enviado "para obtener los requisitos." El
papel de la RA necesita ser entendida y valorada en la mente de los PM y la comunidad técnica. En
este punto, usted puede sentirse abrumado por sus responsabilidades, como sugiere la Figura 2.1. Esté
seguro de que con el estudio y la experiencia, se le proporcionará una contribución muy positiva a los
esfuerzos que usted apoya!.