Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.stsci.edu/ops/tof/tof_minutes/05-11-99_karla_list Дата изменения: Fri Jun 11 00:56:16 1999 Дата индексирования: Sat Mar 1 15:03:42 2014 Кодировка: Поисковые слова: comet

From owner-tof-limited@stsci.edu Tue May 11 11:29 EDT 1999
To: tof-limited@stsci.edu
Subject: draft list of goals

Hi TOFers,

I've combined three things here:

1) The high level goals we came up with last Thursday.
2) The first cut at priorities from Anuradha.
3) The sub goals and example tools are my attempt at
grouping our ideas with the goal they meet.

By noon on Wednesday, please send me comments on what good sub goals
and examples are not yet listed. I'll add those and we can use this
list as a starting point on Thursday.

- Karla


--------------
Observer goals
--------------
01) Intuitive - Critical
only reveal level of complexity needed
(make it simple for first time user)
objects in the system are meaningful to an astronomer
astronomer can specify what he really needs
(e.g. wavelength range, S/N, target name, timing)
traditional specification still possible for expert
HST tools should have consistent terminology and "look and feel"
consistent with other observatories
consistent with other well known software
have feedback loop - PIs can easily inform us of graphs, tables,
or diagnostics that are cryptic so they can be improved

02) Graphical - Critical
Observation visualization
(e.g. FOV (including bad pixels) against a sky image
to feedback or select position, orient, patterns,
offsets, guidestars)
Relationships (orient, timing links) represented graphically
Exposures can be manipulated graphically (lengthen, move)
Graphical ETC

03) Interactive - Critical
guided (wizard) approach overall
guided approach for individual tasks
(e.g. acquisition, measuring coordinates from DSS,
measuring coordinates from HST image)
anticipates questions
suggests improvements
(e.g. if you reorder exposures you can save time)
not just diagnostics - suggest fixes
(e.g. opening orient to 180-185 will yield guide stars)

04) Immediate - Critical
information available as it is created (not batched)
user can determine determine depth of search

05) Easy access to system - Critical
platform independence
easy to install
system kept up to date without the user having to do anything
you shouldn't be out of luck when network connection is down
(computing, data store on your machine)

06) Interfaces to on-line data - Critical
data in archives
catalogs (for target coordinates)
papers
existing proposals (first draft by analogy)

07) Insight into system on request - Critical
Not a black box
Overheads should be explained
Intermediate information should be provided

08) No unproductive work - Critical
interoperability between HST tools
(e.g. VTT access metric tool for geometric distortion)
target coordinates from on-line catalog imported automatically
no rework between stages (e.g. Phase 1 work -> Phase 2)
white box optimizer available (tells you why it did something)
tight feedback loop: report problem -> system change
most up to date software always available
when inputting an image, all data from header should be
brought in (e.g. post-costar)
the ETC should have a library of energy distribution models

09) All feedback/constraints available - Important
all problems in proposal reported so they can be fixed
all constraints and checks available (e.g. guidestars, moving
target, finder charts, duplication, bright object checking)

10) Answers to questions - Important
all documentation on-line and available in one place
documentation kept up to date
integrated documentation accessible to both tools and humans
good search mechanism (natural language)
search mechanism should have automatic feedback loop
(e.g. user can tell the system what it had a
problem finding and the mechanism can add that)
proactive human help when appropriate (system alerts PC)
human help available if needed
simulated data can be easily generated
impact of choices should be apparent
allows exploration (what-if mode) with undo feature
allows questions without iterating a full proposal, like:
how much visibility will I loose if I go to Sched 100%?
what orient does have guidestars?
when is this pointing in CVZ?
how much dark time can I get in May for this pointing?
how long is the SAA for this instrument?
how will my phase beat against the SAA?
should be able to ask: Why is this the default?
there should be annotated example/template proposals

11) Import/Export capability - Important
PI should be able with a different view (like a text
file) by importing and exporting

-----------------
Observatory goals
-----------------
12) Schedulable w/o manual intervention - Critical
clean proposals "roll down hill" to scheduling
hard proposals announce themselves
shorten pipeline to telescope
observations should craft themselves to calendars
within requests of PI (e.g. Trans on demand)

13) Safe to fly - Critical
Examples: Bright object checking

14) Many views available (including PI's) - Critical
There should be a compact view for review purposes
But people here should be able to view proposal
graphically as the PI does

15) No unnecessary constraints - Important
Give PI ability to specify what must be, should be, can be

16) Capture the why when possible - Important
source of data goes with data even into proposal
why option was chosen goes with option into proposal

17) No unproductive work - Important
button to collect and send trouble shooting information to
developers and/or PC

18) Report observatory changes to PIs - Nice to have
changes in observatory (new instruments, restrictions) which
affect proposals will be automatically reported to the PI
version of software used to create value tagged so notification
of update can be made (e.g. exposure time from ETC)

------------
System goals
------------
19) Maintainable/Enhancible - Critical
system captures expert knowledge

20) Extensible/Plug in able - Critical
open architecture or even open source

21) Reusable by other observatories - Important
tools should be exportable to other observatories
data should be open to other observatories for planning campaigns
tools from other observatories should be interoperable
(these goals can be supported with well defined
observatory objects)