My WebLink
|
Help
|
About
|
Sign Out
Home
Browse
Search
CRDSS_Task1_05-32_DesignAndImplementationYear1Summary
CWCB
>
Decision Support Systems
>
DayForward
>
CRDSS_Task1_05-32_DesignAndImplementationYear1Summary
Metadata
Thumbnails
Annotations
Entry Properties
Last modified
9/25/2011 10:18:52 AM
Creation date
5/30/2008 3:48:34 PM
Metadata
Fields
Template:
Decision Support Systems
Title
CRDSS Task 1.05-32 - Study of System Integration Issues Design and Implementation Coordination Year 1 Summary
Description
The following issues are addressed in this memorandum: 1)Have the work products defined in the scope of work been completed? 2)What decisions were made in coordinating system development and system integration? 3) Do any concerns about system integration exist for Year 2 of the project?
Decision Support - Doc Type
Task Memorandum
Date
1/9/1995
DSS Category
DMI Utilities
DSS
Colorado River
Basin
Colorado Mainstem
Contract/PO #
C153658, C153727, C153752
Grant Type
Non-Reimbursable
Bill Number
SB92-87, HB93-1273, SB94-029, HB95-1155, SB96-153, HB97-008
Prepared By
Riverside Technology inc.
There are no annotations on this page.
Document management portal powered by Laserfiche WebLink 9 © 1998-2015
Laserfiche.
All rights reserved.
/
5
PDF
Print
Pages to print
Enter page numbers and/or page ranges separated by commas. For example, 1,3,5-12.
After downloading, print the document using a PDF reader (e.g. Adobe Reader).
Show annotations
View images
View plain text
On-line Documentation Guidelines <br />Task Memorandum 1.05-12, the CRDSS on-line documentation, and the On-line Documentation <br />Guidelines chapter of the CRDSS Developers? Manual describe how on-line documentation is <br />implemented for the CRDSS. In general, each of the programs associated with a major CRDSS <br />Mosaic <br />component (models and database) has on-line documentation, UNIX man pages, and program <br />summaries available from a command line option. <br />-h <br />Revision Control Guidelines <br />Task Memorandum 1.05-20 and the CRDSS Configuration and Maintenance chapter of the CRDSS <br />Developers? Manual discuss revision control methods used within the CRDSS. Method s based on the <br />Revision Control System (RCS) have been employed by developers within the project for source code <br />and documentation. <br />Minimum Program Feature Guidelines <br />SIT meetings were used to discuss which features should be available in every program. This includes <br />the command line option to print program usage, the command line option to print program <br />-h -v <br />Mosaic <br />version. For GUI-based programs, this includes the ability to call up the proper documentation <br />for that program, the use of a status bar, and the use of a standard File menu. <br />Portability Guidelines <br />Task Memorandum 1.05-28 addresses portability guidelines. In general, all software for the CRDSS has <br />been developed with portability in mind. However, in order to be cost-effective, some applications as <br />developed cannot be ported from a workstation to a PC without some effort. This includes the MODSIM <br />interface (built on work from an existing workstation interface) and the VDB (uses GRASS, which is not <br />available on a PC). These applications require resources that a PC cannot provide at this time; however, <br />PCs equipped with X Window System software can display the graphics as the program runs on a <br />workstation. <br />All library routines and non-graphics-based code has been written in a portable fashion where possible. <br />Overall, the implementation of portable code has been according to the scope of work. Work in later <br />years of the project in which applications may run on PCs will provide an opportunity to fully verify that <br />the code is portable. <br />Benchmarking and Validation Guidelines <br />Specific benchmarking and validation for applications has been carried out under appropriate tasks (e.g., <br />under modeling tasks). Task Memoranda 1.05-2 and 1.05-22 describe how software is evaluated using <br />the Briefing Room concept. In general, software has been evaluated by RTi personnel to the extent <br />possible before being placed on the State?s Briefing Room machine, at which time the State can evaluate <br />the software. <br />4 <br />A275 .01.09.95 1.05-32. Malers <br />
The URL can be used to link to this page
Your browser does not support the video tag.