Department of State, Office of Acquisition (INF), P.O. Box 9115, Rosslyn Station, Arlington, VA 22219-0244

70 -- PART 1 OF 2/DATA REPOSITORY SOFTWARE SOL S-OPRAQ-96-R-0613 DUE 072996 POC Contact: Bob Wissman/703-875-6059 or Julie Odend'hal/703-875-6054 This is part one of a two part CBD notice. Part two of two is listed separately within this section of the CBD. This is a comined synopsis/solicitation for commercial items, prepared in accordance with the format in FAR Subpart 12.6, as supplemented with additional information included in this notice. This announcement constitutes the only solicitation; proposals are being requested and a written solicitation will not be issued. The solicitation, number S-OPRAQ-96-R-0613, is issued as a Firm Fixed Price request for proposal (RFP) using a full and open competition. The solicitation/contract will include all applicable provisions and clauses in effect through FAC 90-39. The Data Administration (DA) office of the Department of State (DoS) intends to procure repository software and associated training, installation, and implementation services to support data standardization. I. MANDATORY SOFTWARE REQUIREMENTS: 1. Platforms - Server: Windows NT server 4.0; Clients: Windows 3.11 or Windows NT; Communications between server and client must be based on TCP/IP; If RDBMS is required: Microsoft SQL Server 6.5 (preferably) or Oracle 7 Workgroup Server. 2. Extensibility - Ability to add, change, or delete any kind of entity type, attribute type, or relationship type in the repository's metamodel. 3. Versioning - Support the optional versioning of items: a. Create new versions of existing items; b. Create, automatically, a link between the original version and the new version; c. Allow user to control when an item will be versioned. 4. Partitioning - Ability for: a. Multiple logical partitions on one server; b. Same-name items to occur independently in different partitions 5. Multiple repositories - Software must support a production repository, a development repository, and an administrative repository, with potentially different metamodels in each and the ability to move items between them. Multiple repositories must co-exist on the same server. 6. Concurrent Operation - For multiple users, the software must: a. Support concurrency locks down to the item level -- an item being edited by one user must be locked against change by another; b. Allow reporting on items locked for edit by others. 7. Referential Integrity - Ability to handle its own referential integrity: a. Deletion of an item type must cause deletion of all items of that type; b. Deletion of an attribute type must cause deletion of all attributes of that type; c. Deletionof an item must cause deletion of all links to it (or the conversion of those links to dummy pointers); d. If the repository uses dummies (placeholder items to support referential integrity), the deletion of all parent items must cause the deletion of the dummy item. 8. Security - Ability to control access: a. By role, such as administrator vs. user; b. By specific user; c. By partition.9. Data entry - A GUI data entry facility that can: a. Find items by name, by text search of a specific attribute type, and by navigating through the relationships in the repository, from item to item; b. Add, delete, and update items; c. Populate and unpopulate attributes, with a list of the available attribute types presented on-screen; d. Set and remove links between items, with a list of the valid existing target items presented on-screen; e. Copy; f. Rename items, with all links adjusted accordingly; g. Cut and paste text between items, such as a description being copied from one item to another. 10. Reporting - Offer must include reports that reflect the DoS' metamodel and do the following: a. Document the repository's metamodel; b. Document currently-set partitions; c. Document current security settings - users, groups, rights, etc.; d. Item Detail Report: document all attributes of a particular item(s); e. Impact Analysis Report: list all information related to a given item to a level specified by the user. 11. Report Writer - A facility by which DoS can create its own reports. Report writer must support processing logic beyond SQL and allow storing of report specifications for reuse later. 12. Import - Ability to import data models from: a. LBMS' Systems Engineer; b. text files. 13. Documentation - Printed documentation for each software product offered, including two copies of the documents that describe installation, configuration and administration, plus 25 User Guides. 14. Warranty - All software offered must be warranted to conform to the vendor's assertions in its proposal and to its published specifications. The warranty shall extend for at least one year, beginning the first day of acceptance. II. DESIRABLE SOFTWARE REQUIREMENTS: 1. Rationalization Aids - a. Find similar items for comparison based on similar names, text search, keyword search, or relationships; b. Compare items on-screen, with differences highlighted; c. Dispose of items by (1) merging two items deemed identical, (2) renaming an item as a version of another, (3) linking two items deemed related; d. Do all of the above as one integrated operation, such that the find functions feed the comparison routines, which then feed the various dispositions. 2. Extensibility - a. Metamodel changes automatically reflected in the repository's data entry and administrative program(s); b. Text attributes of 3,000 bytes or more; c. Fixed-domain attribute types, restrictingdata entry to just the fixed domain, with lookup support; d. Mixed-case in text and string attributes; e. Date, time, integer, and decimal attribute types, with appropriate edit checks during data entry; f. Automatic recording of the identity of the person who last updated (or imported) each item and the date-time on which the update was made. 3. Partitioning - a. Have the ability to set links between items across partition boundaries; b. Allow users in Bureau A to see a consolidated view of items in their own partition plus items in the DoS partition, while excluding items in Bureau B's partition; c. Let users copy items and aggregates of items between logical partitions. 4. Views - Let users restrict their view of the repository during a session to just certain items. 5. Access by Business Name - Business name is the fully-spelled-out, mixed-case name of an item, not the repository access name. a. Data entry screens should feature business name; b. Lists of business names should be sorted by business name; c. All reports supplied by the vendor should feature the business name in the body of reports, in controlling sort orders, and in the user-input that create the reports. 6. Security - Control security at the application level. 7. Data Entry - a. Insert/overtype modes, word wrap, block move, and block delete; b. Item search from a list of business names; c. Item search by keyword value; d. Item search by browsing a diagram of related items; e. Re-type items, converting an item from one type to another preserving all attributes common to both types; f. On-line user-written Help for user-defined attribute types; g. Undo; h. Copy includes all links in and out. 8. Reports a.. Item Detail Report should have many ways to select items; b. Diagrammatic Reports should include: (1) ER diagrams for data modling items, and (2) database structure diagrams for physical databases. 9. Import Capabilities - from: a. ERwin; b. IEF/Compose; c. System Architect; d. Oracle; e. DB2; f. Microsoft Access; g. COBOL copybooks. All imports should include: a. Collision detection; b. Ability to recognize and ignore (not duplicate) unchanged items; c. Optional versioning of same-name items; d. Staging --ability for users to preview changes to the repository before committing them. 10. Export - Ability to generate DDL for creating tables in: a. DB2 ; b. Oracle; and ability to export data models to: c. Systems Engineer; d. IEF/Composer; e. ERwin; f. System Architect. 11. End-user browser - Provide user tool for non-technical business users to make simple queries. For portability, it should operate against an extract of the repository. III. FIXED PRICE TECHNICAL SUPPORT REQUIREMENTS: 1. Initial Installation - Vendor shall deliver and install the repository at DoS, 1800 N. Kent Street, Room 101, Arlington, VA 22209. For the server, the DoS shall supply a 90 MHz Intel Pentium with 64Mb of RAM, 5 GIG of available disk space, Microsoft NT Server 4.0, with a TCP/IP connection to the DoS' LAN, and Microsoft SQL Server 6.5 or Oracle 7 Workgroup Server, if required. For clients, the DoS shall supply two Pentium PCs with 16Mb RAM. Vendor shall demonstrate that all of the software in the offer is installed on the server and two clients,that all server capabilities can be run from the server, and that all client capabilities can be run from either client. For import software, DoS shall provide vendor with files to be imported from each source. The vendor shall demonstrate that the files can be imported and that the resulting data is consistent with the data in the tool that was the source of the import files. For CASE-toolexport software, vendor shall demonstrate that data previously imported to the repository can be re-exported to the CASE tool. For DDL-generation, vendor shall demonstrate that the generated SQL can correctly create tables in the target DBMS. 2. Training - Vendor shall provide: a. Administrator training at vendor provided site in the U.S. for two DA personnel in all components of the offered software, to cover installation, configuration, use, backup & restore, troubleshooting, and new-user set-up. If the repository is programmable, the training shall include the vendor's proprietary language and API. Training shall be a minimum length of three days; b. User training at vendor supplied site in the Washington metropolitan area for 15 DA personnel to be users of the software. Training shall be a minimum length of five days. 3. Maintenance - On an annual basis, the vendor shall supply maintenance releases of software and help-desk support within 24 hours of call during 8:00 AM to 5:00 PM Eastern Time Monday through Friday. 4. Fixed Hourly Rate Support Services - The vendor shall supply technical support services on an hourly basis at the direction of DoS. Please note that the vendor will be paid only for actual hours expended, not to exceed 480 hours. Sample tasks include configuring the metamodel, setting up reports, and recommending procedures to best integrate the repository with the modeling and standardization work of DoS. This is the end of part one of a two part CBD notice. Part two of two is listed separately within this section of the CBD.(0197)

Loren Data Corp. http://www.ld.com (SYN# 0458 19960716\70-0001.SOL)