CSTART Engineering Process

From CSTART Wiki

The CSTART Engineering Process is a formally defined set of procedures and guidelines to facilitate effective engineering work on CSTART projects. The Engineering Process aims to strike a balance between keeping things simple, open and flexible, and ensuring design decisions are well researched, justified and documented. We don't want CSTART engineering work to be complete anarchy, but we don't want people to need to fill out endless streams of "TPS reports" when they just want to help out.

Contents 1 Overview 2 General Engineering Process 2.1 Overview 2.2 Project Proposal Phase 2.3 Systems Outline Phase 2.4 Design Phase 2.4.1 Design Task Tree 2.4.1.1 Leaf nodes 2.4.1.2 Non-leaf nodes 2.4.2 Collaborative Decision Making Process 3 Software Engineering Process 3.1 Overview

[edit] Overview

The CSTART Engineering Process is actually two processes: the General Engineering Process (GEP) and the Software Engineering Process (SEP). This separation reflects the very different nature of developing complex hardware and complex software.

[edit] General Engineering Process

[edit] Overview

The General Engineering Process applies to all engineering work which is not software related (for software engineering, see the "Software Engineering Process" section below). It consists of three distinct phases, the Project Proposal Phase, the Systems Outline Phase and the Design Phase. The Proposal Phase may be skipped for projects where it is considered unnecessary. If the Proposal Phase is included, it must necessarily be completed before the other phases can begin. Ideally the Systems Outline Phase should be completed before the Design Phase begins, but some blurring of the boundary between these phases is tolerable.

[edit] Project Proposal Phase

In this phase, proposals on approaches to a project are solicited from the community. A project proposal constitutes a broad outline of a possible "solution" to the "problem" posed by a project. A proposal should not, as a rule, include technical particulars such as a choice of power supply or structural materials. Instead, it should establish the overall project design which will dictate the requirements needed to decide upon technical particulars. Decisions to be made at the proposal level are such things as flight profiles (e.g. direct ascent vs lunar orbit rendezvous) and modular structure of a spacecraft (e.g. two module structure of Apollo vs three module structure of Soyuz or Shenzhou). Specific details (like what sort of propulsion systems are used for flight or which shapes spacecraft modules have) should come later (in the Design Phase.

A list of minimal requirements that a proposal must address should be decided on a per-project basis before the solicitation of proposals begins.

Proposals should be accepted up until a clearly defined cut-off date.

After the cut-off date, the community should vote on proposals, with the most popular proposal being chosen as the basis for the remainder of the Engineering Process.

[edit] Systems Outline Phase

Once a proposal has been accepted according to the process outlined in the Proposal Phase, the high level solution of the proposal is to be analysed to the extent required to produce a "systems outline". This involves the identification of all required systems and subsystems at a moderate level of detail (e.g. power system, communications system, navigation system, etc.), the minimum requirements that each system must necessarily meet, and the required interactions between each of the systems. The ultimate output of this phase should be a number of block-level functional diagrams related to the project. (IMPORTANT POINT: How can we make this open/collaborative?)

At the completion of this phase, a number of Working Groups for the project may be defined, with each WG's scope defined in terms of blocks on the functional diagrams.

[edit] Design Phase

In this phase, the "black box" systems identified in the Systems Outline Phase are actually designed in detail via the use of a process involving the concept of a Design Task Tree and a Collaborative Decision Making Process, both of which are outlined in the sections that follow. Typically, the vast majority of the time spent on engineering work for a project will be spent in the Design Phase.

[edit] Design Task Tree

Every project must have a design task tree. These trees consist of a large number of separate design tasks, arranged into a hierarchical tree structure. Design task trees are implemented as Wiki pages. The name of a Design Task Tree Wiki page must be of the form "<PROJECT NAME> Design Task Tree", e.g. CLLARE Design Task Tree.

The nodes in this tree may have different quantities and kinds of information attached to them, as described below.

[edit] Leaf nodes

Each leaf node in a Design Task Tree should correspond to a single design task which cannot be naturally separated into subtasks. A leaf node must link to a Wiki page which satisfies the following conditions:

• The Wiki page must be of the form "<PROJECT NAME> Design/<PAGE NAME>", e.g. CLLARE Design/CM-Earth Antenna.
• The Wiki page must includes the following:
  • A brief (1 or 2 sentence) summary of the design task.
  • A brief background (1 or 2 paragraphs) on the problem the design task seeks to solve.
  • A list of features/considerations that must be taken into account during the design task. These are specified in a written manner, and need not be overly precise/formal.
  • A list of requirements that any solution to the design task much meet. These must be specified numerically wherever appropriate and should be as precise/formal as necessary.
  • A list of available solutions. This is to include both existing "off-the-shelf" solutions and also proposed new solutions. Information about these solutions relevant to ensuring that the features and requirements of the design task are satisfied, or references to sources of such information, should be included too.
• The Wiki page may also include arbitrary amounts and kinds of supporting material/calculations.

There is a template for new leaf nodes to help ensure these conditions are met. The easiest way to create a new leaf node page is to use Mediawiki substitution on the template. For example, to create a new leaf node page for the CLLARE project, create a page which contains only the code "{{subst:Design Task Tree Leaf Node|CLLARE}}".

[edit] Non-leaf nodes

Each non-leaf node in a Design Task Tree should provide a logical, thematic categorisation of all the nodes which descend from it. A non-leaf node may link to a Wiki page which provides relevant information to this category.

[edit] Collaborative Decision Making Process

Decisions on design tasks are made only when the corresponding Design Task Tree leaf node is considered complete (IMPORTANT POINT: How do we determine when a node is complete in a democratic fashion?). Once this point is reached, a choice from amongst the listed available solutions is chosen by some sort of voting process.

Two proposals for the voting process are as follows: in the simplest option, members simply vote directly on solutions (IMPORTANT POINT: One vote for the "best" or preferential voting from 1-5, say?). In the more complicated option, members vote on how well each solution satisfies various criteria (simplicity, reliability, performance, etc.) and also vote on the relative importance of those criteria. The "winning" solution is that with the highest "score": a weighted sum of scores for each criteria. This second solution raises the problem of where the criteria come from. Do we have one fixed list of criteria for all decisions, or does the community need control over the criteria? If so, how do we give them that control?

Regardless of which of the two solutions above is chosen, the voting process has the following characteristic: the way in which a member has voted can be revised by that member as many times as they like, up until the point they click on an option specifying that their choice is "final". The idea here is that one does not make ones vote "final" until all the relevant analyses have been completed, all the numbers reviewed and one is quite sure they are not likely to change their mind. The utility of this flexible voting system is that people can get a rough idea of how a decision seems likely to be made early on without having to wait a potentially long time for the complete analyses to be done. This can aid people working on other, related decisions by giving them some idea of, e.g., what the power requirements for a subsystem are likely to be.

[edit] Software Engineering Process

[edit] Overview

Some of the software CSTART will produce, such as software which runs on computers onboard spacecraft, and software which runs on computers which communicate with, control or are otherwise critically involved in the management of, in-flight spacecraft, must necessarily be of exceptionally high quality, and thus cannot be developed in the usual ad hoc fashion of open source software. Proven software engineering principles will need to be applied (unit tests, code reviews, etc.) right from the beginning.

CSTART is currently accepting advice from software engineering experts on an appropriate software engineering principles. Have your say at the forums!