|
||
|
They must discuss the hardware, software, and networks that will be used, how the CITIS should handle data in different formats, and how the contractor should handle major changes in the NATO/NATO nations's computer infrastructure. The contractor also needs to decide, with the help of the NATO/NATO nations, how and to what extent to include supplier/subcontractor data and what type of data repository method makes the most sense for the program. Creation of a successful CITIS requires continuous communication between the CITIS developers and the CITIS users. Otherwise, the developers may create a system that satisfies the requirements, butdoesn't meet the user's actual needs. This is especially a problem if the requirements are not well defined in the contract. During the planning phase of the CITIS development process, contractors must determine their strategy in terms of the location/distribution of the program-specific data repository, the extent to which their suppliers/subcontractors will be included in the CITIS, and CITIS data availability.
A major decision that must be made early in the planning process is where the data will reside. This decision does not have to be made prior to solicitation release. If the NATO/NATO nations has already decided on the form of its program-specific data repository, it should be specified in the SOW, but if not, the contractor should propose a solution after contract award in the CALSIP and/or the System Design Document. The main options for program-specific data repository strategies include:
If supplier/subcontractor data is included in the CITIS, the contractor must develop a supplier data input strategy. This input method should be based on the extent and complexity of the CITIS. The four methods for incorporation of subcontractor data into the CITIS include:
Method 1 is almost never recommended because of the cost and effort required to scan in the data. Also, the resultant raster data is in a non-processable format, which will significantly reduce the usefulness of the subcontractor-supplied data. Methods 2 and 3 are both reasonable options when a relatively basic (lower cost) CITIS is desired, because they allow for reasonably simple incorporation of data into the CITIS databases. Digital delivery of subcontractor data to the prime contractor for download into CITIS would eliminate the need to interface with a potentially large number of different subcontractors' information management systems. If, however, a robust CITIS is planned, suppliers/subcontractors should be a part of the CITIS network, and their data should reside in-house. Method 4 should provide the greatest subcontractor data accuracy and timeliness, but these benefits may be outweighed by the typically higher cost and effort to implement the robust CITIS. In general, methods 2 and 3 should be the simplest, least costly methods to implement for incorporation of subcontractor data into the CITIS. For most defence programs, a large volume of technical data will be created by the contractor in support of the program. Before this data can be released for access through the CITIS, it must meet the programmatic requirements and pass the contractual restrictions. Only that data that meets all the requirements and restrictions should be made available through the CITIS.
The contract must address the questions of what constitutes data delivery, and who in the NATO/NATO nations will receive, inspect, and accept the data. The NATO/NATO nations will specify in the contract the delivery methods for each CDRL item, and if delivery includes CITIS, this delivery may be in the form of either in-place delivery, in which the data item is considered delivered once it becomes available on the CITIS, or it may be in the form of a physical data download by the NATO/NATO nations from the CITIS. The NATO/NATO nations contracting officer should decide, and the decision should be specified in the contract, whether the data inspection and acceptance can be performed electronically (e.g., some form of electronic signature or other means of indicating approval or disapproval), or whether it should be done in a traditional method. If an organization will serve as the approving official responsible for taking receipt of the data and then coordinating the inspection and acceptance, that organization should be identified in the SOW.
The selection of hardware and software used to create the CITIS is critical and must be thoroughly analysed before any attempt to develop CITIS is begun. The CITIS configuration should be determined only after analysis and comparison of the NATO/NATO nations', contractor's, and subcontractor's (if included in CITIS) infrastructures. Some important considerations include compatibility of operating systems, file formats, and hardware and telecommunications options. The CITIS designer should also consider future impacts to the CITIS system should NATO/NATO nations users upgrade their hardware or software.
One of the basic problems between different operating systems (e.g., DOS vs. UNIX) is the allowable length of file names. DOS is restricted to the 8.3 (8 character name plus 3 characters for the file extension) file naming convention, while UNIX allows much larger file names. Because of this problem, close attention should be paid to indexing and file management schemes. Before any CITIS development is performed, the contractor must determine how CITIS will handle data in different formats. A matrix should be developed during the CITIS planning stage showing which software tools will be used and how the NATO/NATO nations and contractor data will be stored and displayed. An ideal CITIS would be able to display and process data in any format, regardless of the software tool used to develop it. However, this ideal CITIS may be economically prohibitive and technologically challenging. In practice, the two primary options for data handling are:
The primary drawback to the first option is that the system operators may be required to reprocess data that has already been created. This translation process introduces the potential to lose data and/or format information. If the data has been created with a wide variety of applications, conversion to a single format is a serious weakness that may have a significant economic impact. Composite documents (which may include text, graphics, databases, and/or spreadsheets) are especially difficult to convert into a single format because some software packages may not reproduce the information accurately, and in some cases, not at all. The drawbacks to the second option include greater complexity of the CITIS system and the necessity for CITIS users to be trained on and become familiar with a variety of viewing/editing tools. The greater the number of formats the CITIS data viewer/editor must handle, the more complex and difficult to develop the system will be. Depending on the number of applications launched, software licensing costs could also become a major consideration. The solution to the data format problem may be the use of a neutral file format that allows data created with a variety of different software applications to be saved in a format that can be read by anyone possessing the associated file reader software. Some of the formats currently available are discussed in paragraph 5.5.2.3 below. Depending on the expected CITIS data usage (view, process, comment, etc.), the contractor may choose to translate appropriate data into a neutral format rather than attempting to retain information in its original file formats. These neutral formats, in general, can be created for files developed with a variety of different applications and can then be read by anyone possessing the associated reader software. Textual data (e.g., technical manuals and reports, graphics, spreadsheets, etc.) is particularly well suited for conversion to neutral file formats; databases and some engineering drawing formats should be retained in their original format or converted to a standardized format (e.g., convert from specific CAD format to IGES). Some examples of neutral file formats include platform-independent files and Standard Generalized Markup Language (SGML) files. Several industry-developed software products for creating platform-independent files have recently become available that allow users to save information created in a variety of software applications and formats, including text, graphics, and spreadsheets, into a platform-independent file format, which can then be viewed and printed by anyone possessing the associated reader software. Many applications also allow reader-software users to annotate data and copy information that can then be pasted into other word processing programs. Because of their flexibility in handling a wide range of software packages, contractors may want to explore these platform-independent file applications when determining standard CITIS file formats. SGML is the CALS standard for the exchange of text material for technical documents. It is a non-proprietary format that is not bound to any system software or platform. SGML can handle both text and graphics. A number of SGML authoring software packages are currently available as COTS software. As with the platform-independent files, SGML reader software is required to utilize data in an SGML format. Most SGML readers allow the user to, as a minimum, view, annotate, and print data. One of the current considerations when selecting SGML formats is that it is not yet widely used because of the present lack of Document Type Definitions (DTD) and Formatting Output Specification Instances (FOSI), which are needed to create or translate data into SGML formats. The neutral format reader software discussed above is especially appropriate for data that will be viewed and printed only. Some SGML readers, and the authoring versions of platform-independent file and SGML applications should allow users to perform most of the other data functions such as processing and updating the data.
When determining the infrastructure for CITIS, the program manager must decide whether the contractor or the NATO/NATO nations or both will provide the hardware and telecommunications for the NATO/NATO nations to interface with CITIS. Typically, the NATO/NATO nations will use its own computer hardware, including modems, and software to access the CITIS data, with the contractor providing only the software necessary to access CITIS. However, the program manager may choose to have the contractor provide computer hardware (e.g., complete PCS, terminals, etc.) and/or software to be located at NATO/NATO nations facilities and used exclusively for CITIS access. This option may be especially attractive for locations that could otherwise require infrastructure upgrades to access CITIS. Telecommunications involves the physical connection to CITIS via telephone or other type of lines. The CITIS access can be via regular phone lines, dedicated modem lines, high-speed optical lines, or networks, and will typically be a combination of these methods. If any new lines or networks will be required, the program manager must decide whether the NATO/NATO nations or the contractor will be responsible for line installation and maintenance. The NATO/NATO nations will typically pay for its own connection time charges (e.g., phone line usage) for use of its own telecommunications lines. The NATO/NATO nations may, however, require the contractor to establish an 800-number hotline that can be used by the specified number of concurrent CITIS users. Because of the rapidly changing computer hardware and software technology, it is reasonable to assume that at some point during the life of the CITIS, the NATO/NATO nations users will upgrade either their hardware or software or both. This upgrade can cause major problems for the CITIS developers if the existing CITIS has been created to be compatible only with NATO/NATO nations systems as they were at the beginning of the development effort. The NATO/NATO nations and the contractor should agree up-front as to what technology refreshments the NATO/NATO nations can expect the contractor to incorporate after the CITIS has been implemented. The NATO/NATO nations may also want to state explicitly that CITIS shall be upgraded to be compatible with any major changes in hardware and/or network configuration. Problems can occur when a CITIS user facility reconfigures its networks and then finds that it can no longer communicate properly with the CITIS. Obviously, there needs to be some control over and planning for the number of anticipated changes the contractor is required to incorporate/handle. Ideally, the CITIS will be developed to operate independently of users' operating systems and specific hardware and software. In reality, however, the hardware and software compatibility problems described above can and will occur. CITIS user group meetings can serve as an excellent forum for discussion of compatibility problems, technology advancements, and the advantages and disadvantages to upgrades to the CITIS. It is highly recommended that the NATO/NATO nations designate at least one person who is knowledgeable in computer hardware, software, and networks to be its CITIS administrator. This person will be trained in the specifics of how the CITIS system works and how it is set up at their facility. Ideally, a CITIS administrator would be selected for each of the NATO/NATO nations' CITIS locations. The CITIS administrator(s) should filter NATO/NATO nations complaints and issues before bringing them to the contractor, and should be responsible for making upgrades to local hardware and software work with CITIS. When a hardware or network incompatibility problem arises, it is often due to a change in the user's PC or network configuration. The local CITIS administrator should attempt to solve compatibility problems before contacting the CITIS developers, who may simply direct the problem back to the NATO/NATO nations as an internal facility problem. |
|
|
||