Concept: Organizational Context for the Rational Unified Process
This guideline describes the support organizations and services external to a project that are necessary to its success.
Relationships
Related Elements
Main Description

Introduction

Projects do not run in isolation, they rely on care and feeding from their supporting organizations. The nature of that support is characterized in the following sections. The Rational Unified Process (RUP) assumes that the kinds of services described here will be available from outside the project and that in any organization there will exist some equivalent capability to provide them, but does not prescribe the structure or operation of these entities. The following descriptions are taken from [ROY98] (q.v.).

The Software Engineering Process Authority (SEPA)

The Software Engineering Process Authority (SEPA) facilitates the exchange of information and process guidance both to and from project practitioners. This role is accountable to the organization general manager for maintaining a current assessment of the organization's process maturity and its plan for future process improvements. The SEPA must help initiate and periodically assess project processes. Catalyzing the capture and dissemination of software practices can be accomplished only when the SEPA understands both the desired improvement and the project context. The SEPA is a necessary role in any organization. It takes on responsibility and accountability for the process definition and its maintenance (modification, improvement, technology insertion). The SEPA could be a single individual, the general manager, or even a team of representatives. The SEPA must truly be an authority, competent and powerful, not a staff position rendered impotent by ineffective bureaucracy.

The Project Review Authority (PRA)

The Project Review Authority (PRA) is the organizational entity responsible for ensuring that a software project complies with all organizational and business unit software policies, practices, and standards. A software project manager is responsible for meeting the requirements of a contract or some other project compliance standard, and is also accountable to the PRA. The PRA reviews the project's conformance to contractual obligations and the project's organizational policy obligations. The customer monitors contract requirements, contract milestones, contract deliverables, monthly management reviews, progress, quality, cost, schedule, and risk. The PRA reviews customer commitments as well as adherence to organizational policies, organizational deliverables, financial performance, and other risks and accomplishments. It is recommended that a single individual be nominated as the PRA; that individual may delegate the work of monitoring and review as required, and meetings in which the PRA engages may require the support of others from the development organization's executive management team, so that, at least for the duration of the meeting, the PRA appears as a team of people. It is strongly recommended however that ultimate authority for performance should rest with an individual, who calls for support as needed.

The Software Engineering Environment Authority (SEEA)

The Software Engineering Environment Authority (SEEA) is responsible for automating the organization's process, maintaining the organization's standard environment, training projects to use the environment, and maintaining organization-wide reusable assets. The SEEA role is necessary to achieve a significant return on investment for a common process. Tools, techniques, and training can be amortized effectively across multiple projects only if someone in the organization (the SEEA) is responsible for supporting and administering a standard environment. In many cases, the environment may be augmented, customized, or modified, but the existence of an 80% default solution for each project is critical to achieving institutionalization of the organization's process and a good ROI on capital tool investments.

Infrastructure

An organization's infrastructure provides human resources support, project-independent research and development, and other capital software engineering assets. The infrastructure for any given software line of business can range from trivial to highly entrenched bureaucracies. The typical components of the organizational infrastructure are as follows:

  • Project administration: time accounting system; contracts, pricing, terms and conditions; corporate information systems integration
  • Engineering skill centers: custom tools repository and maintenance, bid and proposal support, independent research and development
  • Professional development: internal training boot camp, personnel recruiting, personnel skills database maintenance, literature and assets library, technical publications.