Concepto: Contexto organizativo para Rational Unified Process.
En esta directriz se describen los servicios y las organizaciones de soporte externos a un proyecto que son necesarios para que finalice satisfactoriamente.
Relaciones
Elementos relacionados
Descripción principal

Introducción

Los proyectos no se ejecutan aisladamente, dependen del cuidado y la alimentación de las organizaciones de soporte. La naturaleza de dicho soporte se caracteriza en las siguientes secciones. Rational Unified Process (RUP) presupone que las clases de servicios descritas aquí estarán disponibles desde fuera del proyecto y que en todas las empresas habrá alguna capacidad equivalente para proporcionarlas, pero no prescribe la estructura o el funcionamiento de dichas entidades. Las descripciones siguiente se ha cogido de [ROY98] (q.v.).

La autoridad de proceso de ingeniería de programas (SEPA)

La autoridad de proceso de ingeniería de programas (SEPA) facilita el intercambio de información y orientación para el proceso, a y de los usuarios. Este rol es responsable ante el gestor general de la empresa de mantener una evaluación actual de la madurez del proceso de la empresa y su plan de mejoras futuras del proceso. La SEPA debe ayudarle a iniciar y evaluar periódicamente los procesos del proyecto. La catalización de la captura y la diseminación de las prácticas de software sólo se pueden conseguir cuando la SEPA conoce la mejora deseada y el contexto del proyecto. La SEPA es un rol necesario en cualquier empresa. Asume la responsabilidad y la contabilidad de la definición del proceso y su mantenimiento (modificación, mejora, inserción de tecnología). La SEPA podría ser un solo individuo, el gestor general o incluso un equipo de representantes. La SEPA debe ser una verdadera autoridad, competente y poderosa, no un puesto de personal impotente debido a una burocracia ineficaz.

La autoridad de revisión de proyectos (PRA)

La autoridad de revisión de proyectos (PRA) es la entidad organizativa responsable de garantizar que un proyecto de software cumple todas las políticas, prácticas y estándares de la unidad empresarial y organizativa. Un gestor de proyectos de software es el responsable de satisfacer los requisitos de un contrato o algún otro estándar de cumplimiento del proyecto, y también es responsable ante el PRA. El PRA revisa la conformidad del proyecto con las obligaciones contractuales y las obligaciones políticas de la organización del proyecto. El cliente supervisa los requisitos, los objetivos y los entregables del contrato, las revisiones mensuales de la gestión, el progreso, la calidad, el coste, la planificación y el riesgo. El PRA revisa los compromisos del cliente y la adherencia a las políticas y los entregables de la organización, el rendimiento financiero y otros riesgos y logros. Es recomendable que la PRA sea un solo individuo, que pueda delegar el trabajo de supervisión y revisión según sea necesario; es posible que las reuniones que convoca la PRA requieran el soporte de otros individuos del equipo de gestión ejecutivo de la empresa de desarrollo, de forma que, por lo menos mientras dure la reunión, la PRA se muestre como un equipo de personas. No obstante, es muy recomendable que la autoridad final de rendimiento dependa de una sola persona, que pide soporte cuando lo necesita.

La autoridad de entorno de ingeniería de software (SEEA)

La autoridad de entorno de ingeniería de software (SEEA) es responsable de automatizar el proceso de la empresa, mantener el entorno estándar de la organización, formar a los proyectos para que utilicen el entorno y mantener los activos reutilizables de toda la empresa. El rol de la SEEA es necesario para conseguir un rendimiento de capital invertido importante para un proceso común. Las herramientas, las técnicas y la formación sólo se pueden amortizar de forma eficaz en varios proyectos si alguien de la empresa (la SEEA) se encarga de dar soporte y administrar un entorno estándar. En muchos casos, el entorno se puede aumentar, personalizar o modificar, pero la existencia de una solución por omisión al 80% para cada proyecto es esencial para conseguir la institucionalización del proceso de la organización y un buen rendimiento del capital invertido en la herramienta.

Infraestructura

La infraestructura de una empresa proporciona soporte de recursos humanos, desarrollo e investigación independientes del proyecto y otros activos capitales de ingeniería de software. La infraestructura de una línea de software empresarial dada puede ir de una burocracia trivial a una burocracia muy afianzada. Los componentes típicos de la infraestructura de la empresa son los siguientes:

  • Administración de proyectos: sistema de contabilidad de horas; contratos, fijación de precios, términos y condiciones; integración de sistemas de información corporativa
  • Centros de conocimiento de ingeniería: mantenimiento y depósito de herramientas personalizados, soporte de propuestas y ofertas, desarrollo e investigación independientes
  • Desarrollo profesional: formación interna básica, captación de personal, mantenimiento de la base de datos de habilidades del personal, biblioteca de activos y literatura, publicaciones técnicas.