| |
|
|
|
3 THE VLT SOFTWARE DEVELOPMENT PROCESS
3.1 WHAT AND WHEN
The VLT Software Management Plan [3] (SMP) provides a model for developing software: the major phases the project should undergo, which outputs every phase should provide, the methodologies to be used for each activity.
Actually, the SMP has been written considering the whole VLT Software, and it may be difficult to understand, from the current wording, what shall be done in the case of a specific subsystem or for an instrument. As a simple rule, take the model described in the SMP and apply it to the specific development: requirement, design (analysis and low-level design), implementation, etc. According to the complexity of the part you are dealing with, decide to which extent each rule in the SMP can be applied. Ask yourself the following questions:
Following the SMP, build the specific project plan, identifying all the outputs (documents and code) that must be provided. Using the SMP recommendations, define how each output shall be done. Check your plan against what is required in the Statement of Work, and review it with ESO to be sure that there are no misunderstandings.
The final products of the process are:
target software:
implementing function needed at the target installation for both normal and maintenance operations
Additional information can be found also in:
VLT-TRE-ESO-00000-0280 --- Definition of Preliminary Design Phase, PDR Data Package, Preliminary Design Review
VLT-TRE-ESO-00000-0397 --- Definition of Detailed Design Phase, FDR Data Package, Final Design Review
3.2 STANDARDS
The VLT Software Programming Standards [6] (PS) provides a set of rules to be used in the design and development of the VLT Software. It contains instructions for the organization of a software module, naming conventions, C language, script files, make, UNIX, VxWorks, etc.
The current applicable version [6] shall be integrated by the Makefile(5), vltDirectorStructure(5), getTemplate(7) manpages, distributed as part of the common software.
A new version is planned before the end-95 and other updates may follow in the future. One of the key aspects of the new version is the coverage of C++.
3.3 KEEPING CONTROL
The SMP requires that the software development is done using a configuration control system as described in the VLT Software Configuration Control Plan [4].
At present, for external developments, there is the possibility to use any system that implements the philosophy described in [4]. Such a system shall be described at the beginning of the project and proposed to ESO for approval.
ESO is currently working to improve the Configuration Control system in use, and it may be externally available in the future.
3.4 TESTING
The SMP requires that the software undergoes a test process based on three levels: module, integration and acceptance. Although still in a draft form, the basic test requirements are in the VLT Software Test Plan [5].
At present, ESO is developing a set of tools to support and document the test activity. The main idea is to standardize the way of preparing and invoking a test in order to allow automatic testing and to reduce test documentation. Some of the test tools may be externally available within end-95.
3.5 THE SOFTWARE MODULE
As defined in the Programming Standards[6], the software module is the basic item for the detailed design, development and integration of software.
The software module should not be confused with the VLT Module, as defined in the VLT Software Management Plan ([3]), that corresponds to a more functional organization of functions and is used during analysis. Normally, several software modules are needed to build a VLT Module.
How many software modules are needed, the scope of each one, its name, etc. are preliminarily defined in the functional specifications and refined in the detailed design. As a rule of thumb, each module should be rather small (10-20 functions) and be independently testable. High cohesion and completeness of the functions belonging to the module, and low, ideally null, coupling with other modules are basic requirements for every module.
A correct partition of the software of a project can help quite a lot especially during test and integration activity and is a basic requirement for future maintenance.
In the rest of this section, the term "module" and "software module" are equivalent.
3.5.1 Create a Software Module
Each software module is identified by a name and implemented as a directory structure. Decide a name (it must be unique in the VLT Software, in the example "xyz" will be used), and create the module:
REMARK for external people: before starting to use any module name, please check with the ESO software contact person that the name is a valid one, e.g., not already in use.
1. set the current directory to where you intend to develop the software. For instance, your HOME directory:
3.5.2 Populate a Software Module
a file xyzHelloWorld.c is created. If the environment variable EDITOR is defined to a valid editor, a window with such an editor should pop-up.
a file Makefile is created. If the environment variable EDITOR is defined to a valid editor, a window with such an editor should pop-up.
Now you can try to create other mains, functions, group them in libraries, scripts, tcl scripts and libraries, etc.
3.5.3 Some Examples
Have a look at the LCU and WS applications, used in the verification procedure (as described in the VLT Common Software Installation Manual). Each application is implemented as a VLT software module and provides also an example of use of the VLT Programming Standards. Please notice:
 Quadralay Corporation http://www.webworks.com Voice: (512) 719-3399 Fax: (512) 719-3606 sales@webworks.com |
| |
|
|
|