SlideShare ist ein Scribd-Unternehmen logo
1 von 7
Downloaden Sie, um offline zu lesen
RUP (PROCESO RACIONAL UNIFICADO)
RUP es un proceso para el desarrollo de un proyecto de un software que define
claramente quien, cómo, cuándo y qué debe hacerse en el proyecto. Como 3
características esenciales está dirigido por los Casos de Uso: que orientan el proyecto a la
importancia para el usuario y lo que este quiere, está centrado en la arquitectura: que
Relaciona la toma de decisiones que indican cómo tiene que ser construido el sistema y en
qué orden, y es iterativo e incremental: donde divide el proyecto en mini proyectos donde
los casos de uso y la arquitectura cumplen sus objetivos de manera más depurada

Como filosofía RUP maneja 6 principios clave:

Adaptación del proceso:

El proceso deberá adaptarse a las características propias de la organización. El tamaño del
mismo, así como las regulaciones que lo condicionen, influirán en su diseño específico.
También se deberá tener en cuenta el alcance del proyecto.

Balancear prioridades:

Los requerimientos de los diversos inversores pueden ser diferentes, contradictorios o
disputarse recursos limitados. Debe encontrarse un balance que satisfaga los deseos de todos.

Colaboración entre equipos:

El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber
una comunicación fluida para coordinar requerimientos, desarrollo, evaluaciones, planes,
resultados, etc.

Demostrar valor iterativamente:

Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada
iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se
refina la dirección del proyecto así como también los riesgos involucrados.

Elevar el nivel de abstracción:

Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del
software, lenguajes 4GL o esquemas (frameworks) por nombrar algunos. Éstos se pueden
acompañar por las representaciones visuales de la arquitectura, por ejemplo con UML.

Enfocarse en la calidad:
El control de calidad no debe realizarse al final de cada iteración, sino en todos los
aspectos de la producción.

EL CICLO DE VIDA DE RUP

RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias iteraciones en
número variable según el proyecto y en las que se hace un mayor o menor hincapié en los
distintas actividades.




En las iteraciones de cada fase se hacen diferentes esfuerzos en diferentes actividades

       Inicio: Se hace un plan de fases, se identifican los principales casos de uso y se
       identifican los riesgos. Se define el alcance del proyecto.
       Elaboración: se hace un plan de proyecto, se completan los casos de uso y se
       eliminan los riesgos.
       Construcción: se concentra en la elaboración de un producto totalmente operativo
       y eficiente y el manual de usuario.
       Transición: se Instala el producto en el cliente y se entrena a los usuarios. Como
       consecuencia de esto suelen surgir nuevos requisitos a ser analizados.


DESCRIPCIÓN DE LAS ACTIVIDADES

Dependiendo de la iteración del proceso el equipo de desarrollo puede realizar 7 tipos de
actividades en este:
FASE DE INICIO

Durante la fase de inicio las iteraciones hacen ponen mayor énfasis en actividades
modelado del negocio y de requisitos.

Modelado del negocio:

En esta fase el equipo se familiarizará más al funcionamiento de la empresa, sobre
conocer sus procesos.

    Entender la estructura y la dinámica de la organización para la cual el sistema va
     ser desarrollado.
    Entender el problema actual en la organización objetivo e identificar potenciales
     mejoras.
    Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento
     común de la organización objetivo.

Requisitos:

En esta línea los requisitos son el contrato que se debe cumplir, de modo que los usuarios
finales tienen que comprender y aceptar los requisitos que especifiquemos.

    Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que
     el sistema podría hacer.
    Proveer a los desarrolladores un mejor entendimiento de los requisitos del
     sistema.
    Definir el ámbito del sistema.
    Proveer una base para estimar costos y tiempo de desarrollo del sistema.
    Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y
     metas del usuario.
FASE DE ELABORACIÓN

En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la
arquitectura, abarcan más los flujos de trabajo de requerimientos, modelo de negocios
(refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de
la arquitectura.

Análisis y Diseño

En esta actividad se especifican los requerimientos y se describen sobre cómo se van a
implementar en los sistemas

    Transformar los requisitos al diseño del sistema.
    Desarrollar una arquitectura para el sistema.
    Adaptar el diseño para que sea consistente con el entorno de implementación



                              FASE DE CONSTRUCCIÓN

Implementación

Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y demás. El
resultado final es un sistema ejecutable.

    Planificar qué subsistemas deben ser implementados y en qué orden debe ser
     integrados, formando el Plan de Integración.
    Cada implementador decide en qué orden implementa los elementos del
     subsistema.
    Si encuentra errores de diseño, los notifica.
    Se integra el sistema siguiendo el plan.

Pruebas

Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos
desarrollando, pero no para aceptar o rechazar el producto al final del proceso de
desarrollo, sino que debe ir integrado en todo el ciclo de vida.

    Encontrar y documentar defectos en la calidad del software.
    Generalmente asesora sobre la calidad del software percibida.
    Provee la validación de los supuestos realizados en el diseño y especificación de
     requisitos por medio de demostraciones concretas.
    Verificar las funciones del producto de software según lo diseñado.
    Verificar que los requisitos tengan su apropiada implementación.
Despliegue

Esta actividad tiene como objetivo producir con éxito distribuciones del producto y
distribuirlo a los usuarios. Las actividades implicadas incluyen:

      Probar el producto en su entorno de ejecución final.
      Empaquetar el software para su distribución.
      Distribuir el software.
      Instalar el software.
      Proveer asistencia y ayuda a los usuarios.
      Formar a los usuarios y al cuerpo de ventas.
      Migrar el software existente o convertir bases de datos.


                         DURANTE TODO EL PROYECTO

Gestión del proyecto

Se vigila el cumplimiento de los objetivos, gestión de riesgos y restricciones para
desarrollar un producto que sea acorde a los requisitos de los clientes y los usuarios.

      Proveer un marco de trabajo para la gestión de proyectos de software intensivos.
      Proveer guías prácticas realizar planeación, contratar personal, ejecutar y
       monitorear el proyecto.
      Proveer un marco de trabajo para gestionar riesgos.

Configuración y control de cambios

El control de cambios permite mantener la integridad de todos los artefactos que se crean
en el proceso, así como de mantener información del proceso evolutivo que han seguido.

Entorno

La finalidad de esta actividad es dar soporte al proyecto con las adecuadas herramientas,
procesos y métodos. Brinda una especificación de las herramientas que se van a necesitar
encada momento, así como definir la instancia concreta del proceso que se va a seguir.

En concreto las responsabilidades de este flujo de trabajo incluyen:

      Selección y adquisición de herramientas
      Establecer y configurar las herramientas para que se ajusten a la organización.
      Configuración del proceso.
      Mejora del proceso.
      Servicios técnicos.
ROLES EN RUP

Analistas:

        Analista de procesos de negocio.
        Diseñador del negocio.
        Analista de sistema.
        Especificador de requisitos.

Desarrolladores:

        Arquitecto de software.
        Diseñador.
        Diseñador de interfaz de usuario
        Diseñador de cápsulas.
        Diseñador de base de datos.
        Implementador.
        Integrador.

Gestores:

        Jefe de proyecto
        Jefe de control de cambios.
        Jefe de configuración.
        Jefe de pruebas
        Jefe de despliegue
        Ingeniero de procesos
        Revisor de gestión del proyecto
        Gestor de pruebas.

Apoyo:

        Documentador técnico
        Administrador de sistema
        Especialista en herramientas
        Desarrollador de cursos
        Artista gráfico.

Especialista en pruebas:

    Especialista en Pruebas (tester)
    Analista de pruebas
    Diseñador de pruebas
Otros roles:

        Stakeholders.
        Revisor.
        Coordinación de revisiones.
        Revisor técnico.
        Cualquier rol.
Notas:

    Para grandes organizaciones con un números equipos de ingenieros y la
     comunicación entre cada equipo es crítica por lo tanto es necesario que los
     artefactos sean completos y bastante comprensivos.
    En tanto que para pequeños proyectos no es recomendable presentarse tanto
     rigor en las preparaciones de los artefactos, la eficiencia del proceso depende
     más de las habilidades de cada trabajador.

Weitere ähnliche Inhalte

Was ist angesagt?

Proceso Unificado de Desarrollo
Proceso Unificado de DesarrolloProceso Unificado de Desarrollo
Proceso Unificado de DesarrolloFausto J Loja Mora
 
Metodologias de desarrollo de software
Metodologias de desarrollo de softwareMetodologias de desarrollo de software
Metodologias de desarrollo de softwarehernandezcris
 
Metodologias modernas para el desarrollo de software
Metodologias modernas para el desarrollo de softwareMetodologias modernas para el desarrollo de software
Metodologias modernas para el desarrollo de softwareDeisy Sapaico
 
Proceso del software
Proceso del softwareProceso del software
Proceso del softwareTensor
 
Metodologías Ágiles para el Desarrollo de Software y Metodologias Para el de...
Metodologías Ágiles  para el Desarrollo de Software y Metodologias Para el de...Metodologías Ágiles  para el Desarrollo de Software y Metodologias Para el de...
Metodologías Ágiles para el Desarrollo de Software y Metodologias Para el de...Joel Fernandez
 
Metodologias Rup Xp
Metodologias Rup XpMetodologias Rup Xp
Metodologias Rup Xpda4
 
Breve explicacion del Rup
Breve explicacion del RupBreve explicacion del Rup
Breve explicacion del Rupluisitoman
 
Metodologias De Desarrollo De Software
Metodologias De Desarrollo De SoftwareMetodologias De Desarrollo De Software
Metodologias De Desarrollo De Softwareguesta1695670
 
Proceso para el desarrollo de software Ponencia M.C.Ivet Espinosa Conde
Proceso para el desarrollo de software Ponencia M.C.Ivet Espinosa CondeProceso para el desarrollo de software Ponencia M.C.Ivet Espinosa Conde
Proceso para el desarrollo de software Ponencia M.C.Ivet Espinosa CondeSam Espinosa
 
METODOLOGÍAS RUP
METODOLOGÍAS RUPMETODOLOGÍAS RUP
METODOLOGÍAS RUPBiingeSof
 

Was ist angesagt? (18)

Proceso Unificado de Desarrollo
Proceso Unificado de DesarrolloProceso Unificado de Desarrollo
Proceso Unificado de Desarrollo
 
RUP Proceso Unificado de Rational
RUP Proceso Unificado de RationalRUP Proceso Unificado de Rational
RUP Proceso Unificado de Rational
 
Rup
RupRup
Rup
 
Metodologias de desarrollo de software
Metodologias de desarrollo de softwareMetodologias de desarrollo de software
Metodologias de desarrollo de software
 
Proceso del Software
Proceso del Software Proceso del Software
Proceso del Software
 
Metodologias modernas para el desarrollo de software
Metodologias modernas para el desarrollo de softwareMetodologias modernas para el desarrollo de software
Metodologias modernas para el desarrollo de software
 
Proceso del software
Proceso del softwareProceso del software
Proceso del software
 
Metodologías Ágiles para el Desarrollo de Software y Metodologias Para el de...
Metodologías Ágiles  para el Desarrollo de Software y Metodologias Para el de...Metodologías Ágiles  para el Desarrollo de Software y Metodologias Para el de...
Metodologías Ágiles para el Desarrollo de Software y Metodologias Para el de...
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
 
Metodologias Rup Xp
Metodologias Rup XpMetodologias Rup Xp
Metodologias Rup Xp
 
Disciplina de desarrollo rup
Disciplina de desarrollo rupDisciplina de desarrollo rup
Disciplina de desarrollo rup
 
Breve explicacion del Rup
Breve explicacion del RupBreve explicacion del Rup
Breve explicacion del Rup
 
Metodología Rup
Metodología RupMetodología Rup
Metodología Rup
 
Metodologias De Desarrollo De Software
Metodologias De Desarrollo De SoftwareMetodologias De Desarrollo De Software
Metodologias De Desarrollo De Software
 
Qué+es+ru..
Qué+es+ru..Qué+es+ru..
Qué+es+ru..
 
Proceso para el desarrollo de software Ponencia M.C.Ivet Espinosa Conde
Proceso para el desarrollo de software Ponencia M.C.Ivet Espinosa CondeProceso para el desarrollo de software Ponencia M.C.Ivet Espinosa Conde
Proceso para el desarrollo de software Ponencia M.C.Ivet Espinosa Conde
 
Rup
RupRup
Rup
 
METODOLOGÍAS RUP
METODOLOGÍAS RUPMETODOLOGÍAS RUP
METODOLOGÍAS RUP
 

Andere mochten auch

Rational unified process rup
Rational unified process rupRational unified process rup
Rational unified process rupJonathan Arana
 
LA INGENIERÍA DE SOFTWARE Y RUP
LA INGENIERÍA DE SOFTWARE Y RUPLA INGENIERÍA DE SOFTWARE Y RUP
LA INGENIERÍA DE SOFTWARE Y RUPKudos S.A.S
 
Metodología xp
Metodología xpMetodología xp
Metodología xpPiskamen
 
The Near Future of CSS
The Near Future of CSSThe Near Future of CSS
The Near Future of CSSRachel Andrew
 
Classroom Management Tips for Kids and Adolescents
Classroom Management Tips for Kids and AdolescentsClassroom Management Tips for Kids and Adolescents
Classroom Management Tips for Kids and AdolescentsShelly Sanchez Terrell
 
The Buyer's Journey - by Chris Lema
The Buyer's Journey - by Chris LemaThe Buyer's Journey - by Chris Lema
The Buyer's Journey - by Chris LemaChris Lema
 

Andere mochten auch (6)

Rational unified process rup
Rational unified process rupRational unified process rup
Rational unified process rup
 
LA INGENIERÍA DE SOFTWARE Y RUP
LA INGENIERÍA DE SOFTWARE Y RUPLA INGENIERÍA DE SOFTWARE Y RUP
LA INGENIERÍA DE SOFTWARE Y RUP
 
Metodología xp
Metodología xpMetodología xp
Metodología xp
 
The Near Future of CSS
The Near Future of CSSThe Near Future of CSS
The Near Future of CSS
 
Classroom Management Tips for Kids and Adolescents
Classroom Management Tips for Kids and AdolescentsClassroom Management Tips for Kids and Adolescents
Classroom Management Tips for Kids and Adolescents
 
The Buyer's Journey - by Chris Lema
The Buyer's Journey - by Chris LemaThe Buyer's Journey - by Chris Lema
The Buyer's Journey - by Chris Lema
 

Ähnlich wie RUP (20)

Qué es rup
Qué es rupQué es rup
Qué es rup
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
 
metodologia
metodologiametodologia
metodologia
 
Rup
RupRup
Rup
 
Rup disciplinas
Rup disciplinasRup disciplinas
Rup disciplinas
 
Quesrup 120217232753-phpapp02
Quesrup 120217232753-phpapp02Quesrup 120217232753-phpapp02
Quesrup 120217232753-phpapp02
 
Rup[1]
Rup[1]Rup[1]
Rup[1]
 
Rup
RupRup
Rup
 
Metodologiarup 100914104343-phpapp02
Metodologiarup 100914104343-phpapp02Metodologiarup 100914104343-phpapp02
Metodologiarup 100914104343-phpapp02
 
1. ciclo de_vida_de_software
1. ciclo de_vida_de_software1. ciclo de_vida_de_software
1. ciclo de_vida_de_software
 
Rup
RupRup
Rup
 
RUP
RUPRUP
RUP
 
Metodología de desarrollo de software
Metodología de desarrollo de softwareMetodología de desarrollo de software
Metodología de desarrollo de software
 
Modelos del software
Modelos del softwareModelos del software
Modelos del software
 
Metodologias
MetodologiasMetodologias
Metodologias
 
4.1 Proceso Unificado De Rational
4.1 Proceso Unificado De Rational4.1 Proceso Unificado De Rational
4.1 Proceso Unificado De Rational
 
Proceso Unificado De Rational
Proceso Unificado De RationalProceso Unificado De Rational
Proceso Unificado De Rational
 
Documentacion rational
Documentacion rationalDocumentacion rational
Documentacion rational
 
Documentacion rational
Documentacion rationalDocumentacion rational
Documentacion rational
 

RUP

  • 1. RUP (PROCESO RACIONAL UNIFICADO) RUP es un proceso para el desarrollo de un proyecto de un software que define claramente quien, cómo, cuándo y qué debe hacerse en el proyecto. Como 3 características esenciales está dirigido por los Casos de Uso: que orientan el proyecto a la importancia para el usuario y lo que este quiere, está centrado en la arquitectura: que Relaciona la toma de decisiones que indican cómo tiene que ser construido el sistema y en qué orden, y es iterativo e incremental: donde divide el proyecto en mini proyectos donde los casos de uso y la arquitectura cumplen sus objetivos de manera más depurada Como filosofía RUP maneja 6 principios clave: Adaptación del proceso: El proceso deberá adaptarse a las características propias de la organización. El tamaño del mismo, así como las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto. Balancear prioridades: Los requerimientos de los diversos inversores pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un balance que satisfaga los deseos de todos. Colaboración entre equipos: El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, etc. Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados. Elevar el nivel de abstracción: Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o esquemas (frameworks) por nombrar algunos. Éstos se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con UML. Enfocarse en la calidad:
  • 2. El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción. EL CICLO DE VIDA DE RUP RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en los distintas actividades. En las iteraciones de cada fase se hacen diferentes esfuerzos en diferentes actividades Inicio: Se hace un plan de fases, se identifican los principales casos de uso y se identifican los riesgos. Se define el alcance del proyecto. Elaboración: se hace un plan de proyecto, se completan los casos de uso y se eliminan los riesgos. Construcción: se concentra en la elaboración de un producto totalmente operativo y eficiente y el manual de usuario. Transición: se Instala el producto en el cliente y se entrena a los usuarios. Como consecuencia de esto suelen surgir nuevos requisitos a ser analizados. DESCRIPCIÓN DE LAS ACTIVIDADES Dependiendo de la iteración del proceso el equipo de desarrollo puede realizar 7 tipos de actividades en este:
  • 3. FASE DE INICIO Durante la fase de inicio las iteraciones hacen ponen mayor énfasis en actividades modelado del negocio y de requisitos. Modelado del negocio: En esta fase el equipo se familiarizará más al funcionamiento de la empresa, sobre conocer sus procesos.  Entender la estructura y la dinámica de la organización para la cual el sistema va ser desarrollado.  Entender el problema actual en la organización objetivo e identificar potenciales mejoras.  Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento común de la organización objetivo. Requisitos: En esta línea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos que especifiquemos.  Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que el sistema podría hacer.  Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema.  Definir el ámbito del sistema.  Proveer una base para estimar costos y tiempo de desarrollo del sistema.  Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario.
  • 4. FASE DE ELABORACIÓN En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan más los flujos de trabajo de requerimientos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la arquitectura. Análisis y Diseño En esta actividad se especifican los requerimientos y se describen sobre cómo se van a implementar en los sistemas  Transformar los requisitos al diseño del sistema.  Desarrollar una arquitectura para el sistema.  Adaptar el diseño para que sea consistente con el entorno de implementación FASE DE CONSTRUCCIÓN Implementación Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y demás. El resultado final es un sistema ejecutable.  Planificar qué subsistemas deben ser implementados y en qué orden debe ser integrados, formando el Plan de Integración.  Cada implementador decide en qué orden implementa los elementos del subsistema.  Si encuentra errores de diseño, los notifica.  Se integra el sistema siguiendo el plan. Pruebas Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos desarrollando, pero no para aceptar o rechazar el producto al final del proceso de desarrollo, sino que debe ir integrado en todo el ciclo de vida.  Encontrar y documentar defectos en la calidad del software.  Generalmente asesora sobre la calidad del software percibida.  Provee la validación de los supuestos realizados en el diseño y especificación de requisitos por medio de demostraciones concretas.  Verificar las funciones del producto de software según lo diseñado.  Verificar que los requisitos tengan su apropiada implementación.
  • 5. Despliegue Esta actividad tiene como objetivo producir con éxito distribuciones del producto y distribuirlo a los usuarios. Las actividades implicadas incluyen:  Probar el producto en su entorno de ejecución final.  Empaquetar el software para su distribución.  Distribuir el software.  Instalar el software.  Proveer asistencia y ayuda a los usuarios.  Formar a los usuarios y al cuerpo de ventas.  Migrar el software existente o convertir bases de datos. DURANTE TODO EL PROYECTO Gestión del proyecto Se vigila el cumplimiento de los objetivos, gestión de riesgos y restricciones para desarrollar un producto que sea acorde a los requisitos de los clientes y los usuarios.  Proveer un marco de trabajo para la gestión de proyectos de software intensivos.  Proveer guías prácticas realizar planeación, contratar personal, ejecutar y monitorear el proyecto.  Proveer un marco de trabajo para gestionar riesgos. Configuración y control de cambios El control de cambios permite mantener la integridad de todos los artefactos que se crean en el proceso, así como de mantener información del proceso evolutivo que han seguido. Entorno La finalidad de esta actividad es dar soporte al proyecto con las adecuadas herramientas, procesos y métodos. Brinda una especificación de las herramientas que se van a necesitar encada momento, así como definir la instancia concreta del proceso que se va a seguir. En concreto las responsabilidades de este flujo de trabajo incluyen:  Selección y adquisición de herramientas  Establecer y configurar las herramientas para que se ajusten a la organización.  Configuración del proceso.  Mejora del proceso.  Servicios técnicos.
  • 6. ROLES EN RUP Analistas:  Analista de procesos de negocio.  Diseñador del negocio.  Analista de sistema.  Especificador de requisitos. Desarrolladores:  Arquitecto de software.  Diseñador.  Diseñador de interfaz de usuario  Diseñador de cápsulas.  Diseñador de base de datos.  Implementador.  Integrador. Gestores:  Jefe de proyecto  Jefe de control de cambios.  Jefe de configuración.  Jefe de pruebas  Jefe de despliegue  Ingeniero de procesos  Revisor de gestión del proyecto  Gestor de pruebas. Apoyo:  Documentador técnico  Administrador de sistema  Especialista en herramientas  Desarrollador de cursos  Artista gráfico. Especialista en pruebas:  Especialista en Pruebas (tester)  Analista de pruebas  Diseñador de pruebas
  • 7. Otros roles:  Stakeholders.  Revisor.  Coordinación de revisiones.  Revisor técnico.  Cualquier rol. Notas:  Para grandes organizaciones con un números equipos de ingenieros y la comunicación entre cada equipo es crítica por lo tanto es necesario que los artefactos sean completos y bastante comprensivos.  En tanto que para pequeños proyectos no es recomendable presentarse tanto rigor en las preparaciones de los artefactos, la eficiencia del proceso depende más de las habilidades de cada trabajador.