To be written . . .
[This section should include discussion of how choice of software affects operations, maintenance, and most importantly how well we reach our science goals.]
Purpose of this section. Describe the general approach of the Canada-France-Hawaii Telescope Corporation's software group. There are two main reasons for having this document. First, many of the goals, philosophies, and policies described below are believed, in general, to be the most appropriate for solving problems in our field. Choices made for a mature, ground based telescope may differ from those for a space program or industry, Second, we believe that having a group which shares as many common philosophies as possible - whatever they may be - makes for the most efficient working situation.
(Ways to get to the goals)
Since the company has limited money and resources, we must agree on a balanced approach to meeting as many of the goals as possible. Here is the general philosophy on meeting each of the 8 goals above:
Ideally, we would receive these requirements. In reality, it often falls on us to "extract" the requirements from the astronomer. As part of collecting the requirements, both priority, and a rough idea of how long it will be needed are important. Often, we'd rather implement the must-have list completely first because the overhead in maintaining "quick hacks" can become overwhelming later on.
This leads into why we determine how long something will be used as part of gathering requirements. If a solution doesn't have much potential to be re-used for something else in the future, and may only be used for a matter of weeks for a special purpose, sometimes a "hack" is appropriate.
The fact that requirements do change often in our field reflects not indeciveness on the part of scientists, but the nature of science itself. Having strict requirements that are static for years could severely limit discovery. As a result, flexibility in software implementations ranks high.
One way to meet this goal is to make sure that more than one person can always react to user requests for changes on any system. For the acquisition and analysis systems, the time scale for these changes or additions is the most demanding. We strive to meet this goal by (a) spreading knowledge, and (b) designing in a way to effect a change that is simple as possible.
[This applies mostly to the acquisition system. Way to rewrite it to be more encompassing?]
a. No immediate dependencies on anything outside the summit network. b. Redundancy where possible c. Often acceptable to cover (a) OR (b) at any given time. E.g., redundancy can be provided by a Waimea computer, such that when we're on the back-up, we're temporarily in violation of (a). (Due to the fact that we feel double failures are unlikely enough not to be worth trying to cover.)
a. Use stable, mature tools and languages. b. Avoid choices which require a specific commercial product. c. Where possible, use things which are widely known by software engineers or anyone else we are likely to be able to hire in the future.
. . .
Framework should be open, simple to learn.
Re-use existing framework, or upgrade it if it doesn't meet a new need.
[The rest of the sections need to go into a fair amount of detail about everything from X-Server ``depths'' to Status Servers . . . This is just a rough start for the section headers right now, and I know it is not well balanced/filled out yet. Please give feedback.]