- Subsystem Design Documents --
The discussion
of Subsystem Design Documents (SDS's) reported in last
week's minutes was continued at this meeting. The purpose at this time was
to define the format sufficiently well so that the subsystem developers
could proceed. A model SDS from the IRAS/SDAS software system was used; this
was the SDS for the SOURCE DETECTION SUBSYSTEM. The following decisions were
made.
- A.
The sections employed in the document will closely parallel those
of the IRAS/SDAS example. The title page and signoff page will be
translated directly: document numbers specific to 2MASS will be
assigned and used in headers on all pages, with revision identifiers as
applicable. The title pages will read:
2MASS Production Processing System
Subsystem Design Specification
[subsystem name] Subsystem
< Rev. ?? >
[ date ]
Infrared Processing and Analysis Center
California Institute of Technology
Pasadena, California
and the signoff page will be similarly patterned after the one in the
model SDS. Persons signing off specific subsystems will be identified
later, but will obviously include the subsystem cognizant engineer.
- B.
There will be no CHANGE NOTICES PAGE; this information will be in
section 1.2, titled Version History. There will be no DISTRIBUTION page.
Section 1.1 will be titled Applicable Documents and will list the Level
1 Requirements Document, 2MAPPS Functional Requirements Document,
2MAPPS Functional Design Document, and any other applicable controlling
document (e.g., the Observatory/IPAC Interface Document in the case of
the TAPELOAD subsystem); version identifiers of all documents will be
included.
- C.
The main-level sections will be as follows:
1.0 Purpose
2.0 Input
3.0 Processing
4.0 Output
5.0 Testing
There will be no section 6. The Input and Output sections will
reference SIS's wherever applicable and will not duplicate the SIS
information beyond what is necessary for coherent discussion of
processing. If a section on terminology or symbolization is needed, it
can be added as an additional section under 1.0. An overview should be
given in section 1.0 that may be based on the FDD entry for the
subsystem; a reasonable tradeoff between duplication of the FDD section
and a self-contained overview should be attempted. Section 5.0 may
simply identify the files used for testing, including a file (or files)
containing the output from a correct execution; as with any section,
elaboration beyond the minimum is acceptable if time permits.
- D.
Each cognizant engineer may select a word processor of individual
choice, but the product is to be a 100% postscript file. This file will
be printed, signed off, and distributed, and it will also go on the
2MASS web site. As such, it will not support hypertext; this limitation
is acceptable at this time. Postscript files produced on PCs can be
moved to the unix file system via PCNFS (see J. Fowler if help is
needed in getting files from PCs to the unix file system).
- E.
The postscript file should contain several flowcharts: a subsystem-
level data-flow diagram, a subsystem-level functional-flow diagram, and
any relevant algorithm functional-flow diagrams. It would be nice if a
consistent set of flowchart symbols could be used; this will be
discussed at future Working Group meetings. A public-domain flowcharting
program will be set up for 2MASS use; this program is named Da Vinci,
and its use will also be the subject of future meetings. PC-based
flowcharting programs may be used as long as the flowcharts can be
inserted into the document to produce a self-contained postscript file.
- F.
If possible, a consistent use of fonts is desirable. It has been
found in the past that sometimes postscript files are generated which
cannot be printed properly on the IPAC printers because of font
incompatibilities, and the use of Times Roman eliminates this problem.
The team adopted 10-point Times Roman as the standard font.
- G.
NAMELIST definitions will be documented via SIS's (hence not in the
SDS's). The format will include columns with the following headings:
Name Description Dim Type Units Range Default
------ -------------------------- ------ ----- ----- ------- --------
- H.
The two main purposes of an SDS are to support design reviews and
to aid in subsystem design and maintenance; these should be considered
whenever questions arise regarding priorities and what subjects should
be included. A possibility that should be borne in mind is that someone
other than the original developer will be maintaining the software at
some future time; the most important things for this person to be aware
of should receive the highest priorities.