Introduction to the ASRI Project System

History

ASRI has conducted a number of space system development projects over the past ten years. In doing so, the need for a more organised approach to the development effort has become apparent. Consequently, in 2000, ASRI initiated an effort to develop a framework for the conduct of space engineering projects. This effort has resulted in the ASRI Project System.

Objectives and Scope

The ASRI Project System is intended to provide a framework for the definition and understanding of project objectives and the implementation of the project through:

• planning,
• organisation,
• performance monitoring, and
• assessment of results.

The ASRI Project System provides for the decomposition of a project into logical and manageable units and processes covering:

• project scope,
• product quality,
• time and scheduling,
• cost,
• organisation, and
• logistics.

The European Cooperation for Space Standardisation

Adoption of the ECSS by ASRI

To assist in the development of the ASRI Project System, ASRI has adopted the European Cooperation for Space Standardsation (ECSS) approach on a trial basis. The ECSS is an initiative established by the European Space Agency (ESA) to develop a single, coherent set of user-friendly standards for use in all European space activities.

The ECSS standards system has three branches, as shown in the ECSS documentation architecture below, with each branch headed by a Level 1 standard numbered 00. Within each branch are a number of Level 2 and Level 3 standards. The purpose of each branch is as follows:

• Management (M series) standards define the process requirements to be applied to the overall project activities during the life cycle.
• Product Assurance (Q series) standards define the requirements for management and performance of product assurance activities during a space project.
• Engineering (E series) standards are devoted to the products themselves and cover both the engineering process and technical aspects of parts, assemblies, equipments, sub-systems and systems used to accomplish, or associated with, space missions.

The ECSS does not dictate particular methodologies (for example, PRINCE 2, CMM, etc), nor implementation techniques or tools, nor organisational arrangements. This allows the ECSS standards to be adopted without necessarily having to change all corporate business processes.

Tailoring of the ECSS Standards for ASRI Use

Basis of Tailoring

Section 5.3 of ECSS-M-00A - Space Project Management - Policy and Principles states that tailoring of the ECSS standards to specific requirements shall be done according to criteria such as:

• project risks,
• the type of products resulting from the project,
• project category, and
• relevant industry policy.

Tailoring of the ECSS standards for ASRI use will be done according to these criteria.

Project Risks

ASRI's approach to risk management of space projects is based on the ECSS approach and on the Australia / New Zealand standard AS/NZS 4360:1999 - Risk Management.

Type of Products

The type of products developed and used in a space project is defined in Table 2 of ECSS-E-00A - Space Engineering - Policy and Principles and ranges from man-rated launch vehicles to LEO satellites to ground systems and test facilities. The primary and secondary references assigned to each class are used in the tailoring process.

ASRI space projects result in products of varying types, although never man-rated, hence no ASRI-specific guidance is possible on the determination of a product class.

Project Category

Section 5.3 of ECSS-M-00A - Space Project Management - Policy and Principles defines four project categories, ranging from a Category 1 project, in which loss of the mission would be unacceptable, to a Category 4 project, which is a minimum cost project where the mission is only worthwhile if the cost is kept down.

Quite obviously, most, if not all, ASRI space projects will fall into Category 4 where the management activities are reduced to a minimum. Consequently, where tailoring options are provided in an ECSS standard applicable to an ASRI space project, the options most applicable to a Category 4 project are to be implemented.

Industry Policy

This criterion is yet to be developed but is expected to be based on ASRI's corporate objectives as per the ASRI Constitution.

ASRI Project System Elements

Architecture

ASRI has adopted the ECSS documentation architecture as is ... with one major variation: Whereas the ECSS Engineering (E series) branch encompasses both the engineering process and technical aspects of the space system itself, ASRI defines the Engineering (E series) branch as being related only to the systems engineering process, including the management of the engineering process and the integration of engineering specialties, but not to the technical aspects of the space system itself. For this, a fourth branch is defined, the product-oriented System (S) branch.

Hence, the ASRI Project System architecture is comprised of three process thematic branches (M, Q and E) and one product thematic branch (S). The following examples illustrate the use of each branch:

• A budget or schedule would be assigned to the Project Management (M) branch.
• Quality assurance methods, plans or processes would be assigned to the Product Assurance (Q) branch.
• Documents relating to engineering management, or to the software engineering process, would be assigned to the Systems Engineering (E) branch.
• A drawing of a component would be assigned to the System (S) branch.

Process Thematic Branches

Within each of the three process thematic branches (M, Q and E), a number of processes are defined by the various Level 2 standards. More information about how ASRI implements each Level 2 standard is available via the following links:

• Project Management (M)
• Product Assurance (Q)
• Systems Engineering (E)

To support the implementation of the ECSS Level 2 process standards into the ASRI Project System, ASRI has commenced development of various process descriptions, such as Document Review, to specify how ASRI project teams should conduct development activities.

Product Thematic Branch

The product thematic branch (S) encompasses all descriptions of the space system itself, including, but not limited to:

• documents based on ASRI Project System templates, such as OCDs and SRSs;
• documents not based on ASRI Project System templates;
• component drawings;
• spreadsheets; and
• images.

Document Templates

To support the preparation of the various documents required by the ASRI Project System, ASRI has now commenced tailoring the ECSS into a set of document templates, also known as Data Item Descriptions (DIDs) or Data Requirements Definitions (DRDs), suitable for the volunteer and student-based nature of ASRI projects. Where an ECSS source document is not available, other standards and references are being used, particularly the now-superceded US military standard for software engineering, MIL-STD-498, for which an entire suite of DIDs are publically available.

Two templates, and a generic template (a "template for a template"), are now available:

• Project Proposal (PPR), for capturing the initial idea for a space system project, analysing it and then presenting the idea to the ASRI Board for consideration and further action; and
• Operational Concept Description (OCD), for eliciting mission requirements by describing how a space system would operate and interact with its environment.

Additional DIDs are currently under development including:

• Project Management Plan (PMP), used to express project structures, process, budgets and schedules;
• Systems Engineering Plan (SEP), used to describe how the project engineering effort will be managed;
• Product Assurance Plan (PAP), used to describe how product assurance activities will be managed and how quality targets will be met;
• Project Requirements Document (PRD), for expressing those ECSS-derived space project process requirements considered applicable to the project;
• Stakeholder Requirements Document (SRD), for expressing the requirements and expectations of stakeholders, including ASRI itself, of an ASRI space project;
• [Sub-] System Requirements Specification (SRS), for expressing the requirements that a system or sub-system has to meet;
• Interface Requirements Specification (IRS), for expressing the requirements that an interface has to meet;
• [Sub-] System Design Specification (SDS), for expressing a design solution that meets the requirements of the applicable SRS; and
• Interface Design Specification (IDS), for expressing a design solution that meets the requirements of the applicable IRS.

Please note that the first DID developed under the ASRI Project System, the Project Handbook (HBK), has been made redundant by the PMP, SEP and PAP.

Volunteers with industry knowledge and experience are needed to assist in the ongoing development of these and other DIDs.

Other Space System Development Resources

As well as the DIDs and process descriptions, The ASRI Project System hosts other resources intended to assist those involved in ASRI projects.

These resources are arranged according to the three-branch ECSS architecture:

• Project Management (M)
• Product Assurance (Q)
• Systems Engineering (E)

ASRI will be adding to these resources on a sporadic basis. Contributions are encouraged.