Laserfiche WebLink
General Development Schedule <br />The CRDSS software is developed using a stepped approach designed to ensure that the core <br />functionality of the system is guaranteed before enhanced features are added. This applies to all <br />software components. <br />The CRDSS system consists of a main ? CRDSS menu? which will call other applications. This <br />CRDSS shell exists as a UNIX script to formalize the basic execution order of CRDSS programs (the <br />crdss crdssgui <br /> program). The graphical user interface (GUI) CRDSS shell exists as the program. <br />Some applications are stand-alone and can be developed independently of the schedules of other <br />components. For example, existing models such as the CRSM and MODSIM do not directly depend <br />on other CRDSS components and can be ported to the SGI workstations early in Phase II. Public <br />XMgr Mosaic <br />domain software such as and can be treated similarly. These applications can then be <br />?plugged in? to the CRDSS shell and are available for use. <br />Supporting applications (e.g., DMI utilities) and underlying supporting libraries (e.g., low-level DMI <br />library) are critical path products that bind together stand-alone applications. Consequently, <br />supporting software must quickly be made functional to a level that supports stand-alone applications <br />such as models. DMI utilities are first developed as transfer-only programs to read the CRDSS <br />database and create flat files for models. Ensuring this functionality enables modelers to develop <br />data sets and calibrate the models. No GUI or data-editing capabilities are implemented during this <br />stage. Existing GUIs (e.g., MODSIM's interface program) are evaluated to determine how much of <br />the existing code can be used. <br />GUI features discussed in Task Memoranda 1.05-15, 1.05-16, 1.05-17, and 1.05-18 have been added <br />to DMIs during Year 1, but only after core data transfer abilities were verified. The use of a GUI <br />builder for developing GUI components is discussed in Task Memorandum 1.05-15. <br />Control of Prototypes <br />Task Memorandum 1.05-24 discusses how recently-modified files are to be copied to machines at <br />RTi after each day's work. The current copy of the system is maintained as the development copy <br />and is the master copy of the system. Additionally, a ?frozen? version of code is maintained at RTi <br />as a copy of the prototype system that is to be loaded on the Briefing Room machine. This version is <br />tested and then loaded on the Briefing Room machine. Limitations in the prototype are explained in <br />release notes for the benefit of system reviewers. <br />RTi has responsibility for integrating the system into a complete prototype system and for tracking <br />different file revisions and product versions. RTi conducts QA/QC on software and data before they <br />are made available on the Briefing Room machine. This consists of tests of scenarios that are to be <br />expected on the Briefing Room machine. <br />Source code and libraries are not copied to the Briefing Room machine because the disk space <br />required to do so would be prohibitive. In general, only the executable programs and supporting files <br />needed to run the prototype CRDSS are loaded on the Briefing Room machine. State personnel <br />wishing to do development are given accounts on the CRDSS machines at RTi so that they can <br />access the source code and libraries. The latter policy is suggested to limit RTi's need to manage <br />2 <br />A275 01.08.95 1.05-22 Malers <br />