D -- REQUEST FOR INFORMATION (REVISION 1 OF RFI DATED MAY 7, 2001)

Notice Date

June 12, 2001

Contracting Office

Department of Veterans Affairs (381), Austin Automation Center, 1615 E. Woodward St., Austin, TX 78772

ZIP Code

78772

Solicitation Number

N/A

Response Due

June 19, 2001

Point of Contact

POC: Justina Hamberg (fax # 512-326-6028)

Description

See RFI posted on Printed Issue of CBD dated May 7, 2001. This is a revision of that RFI to include requirement for accessibility standards. 1.0 INTRODUCTION The Austin Automation Center (AAC) within the U.S. Dept. of Veterans Affairs has a need for documenting the functionality and business rules of the PAID application. In determining how to fulfill this need, the AAC needs to know what commercially available software tool(s), if any, exist and what the approximate cost is to license and maintain the software. This is the objective of the Request for Information (RFI). In achieving the objective, it is important to clarify AAC's definition of documentation. Moreover, it is important to understand the purpose and reasons for creating documentation. For the purposes of this RFI, AAC assumes the purpose of creating documentation to be: the ability to quickly and accurately identify programs that need to be changed and the impact of those changes. By identifying components that need to be modified for a given maintenance or application enhancement activity, and the scope and impact of the modification up front, AAC can decrease project risk while increasing project quality. 2.0 REQUIREMENTS The PAID application is a combined batch and on-line processing system. The on-line portion is accomplished through CICS / COBOL code and the batch through most versions of COBOL (e.g. COBOL II, and/or COBOL 85) with JCL and Linkage sets. The following sections identify the requirements AAC feels need to be satisfied by the software tool acquired to address the Government's need described in Section 1.0. Only firms that currently have product(s) possessing the characteristics described below are invited to respond to this RFI. Responses should include: 1. Product literature that addresses the above characteristics and any other important technical aspect. 2. Price list or schedule for license and maintenance fees for all platforms supported. 3. Standard software license agreement. 4. Points of contact (including name, phone number, and fax number) that are knowledgeable about the technical aspects of the product(s) and the license agreement. This RFI is not a Request for Proposal, and nothing shall be construed herein or through the RFI process to commit or obligate the Government to further action as a result of this RFI. In addition, firms responding to this RFI shall bear all risk and expense of any resources used to provide the requested information. Responses to this RFI shall be addressed to the Contracting Officer either by fax (512-326-6028) or by mail. Telephonic inquiries will not be accepted. 2.1 Functionality Requirements 2.1.1 Mass change A tool that describes to an analyst the effect of a single or multiple changes on the entire system or on the "set" it is currently examining. For example, if you make a change in program A, what other programs will also need to be modified to support the change made in program A. 2.1.2 Process Analysis A tool that organizes various inputs (modules, JCL, Linkage sets, etc.) into a coherent whole for detail relational analysis. PAID Batch executes through a series of "Runs" as determined by the Linkage sets associated with each series, thus AAC would require the tool to assemble all pieces of each "Run" so that the pieces could be analyzed as a "set." 2.1.3 Global Search A tool that will be able to search through a "set" (as stated in 2.2) by various means. Examples: text, statements, programs, data files, variables, paragraphs & sections, literals, JCL, screens, fields, etc. Once search items are found, the tool needs to be able to display how the searched item is used wherever it was found (like a full window/screen editor), all items searched (within current search) need to be highlighted within the code for ease of recognition and analysis. 2.1.4 Pseudo execution A tool that will be able to simulate a step through execution of a COBOL module or a CICS module to assist in the logical analysis of existing code or in the analysis of new code and how it effects the whole "set." The simulation needs to be able to handle all variants of COBOL/CICS code (i.e. a simple decision (IF statement.), moderately complex decision (IF, ELSE), complex decision (IF, THEN, ELSE), nested sets of all the previous as well as 88s, and simple tables). 2.1.5 Module flow diagrams A tool that can examine an individual module and produce a visual trial (flowchart) and a pseudo code trail of an individual COBOL or CICS module, or an entire "set." Additionally, it is desirable that this feature extends itself to the lowest level of the code rather than stopping at paragraph names. 2.1.6 Pre-set analysis selections A tool that within its command options would have a "menu" of analysis "tools" for the "set." Examples: CALL parameters, Children of data items, Format of data items, Data trace, Literals, File usage, CICS statements, Parents of data items, Copy statements, Invalid MOVE/comparison statements, etc. The tool needs to be able to identify any loose or unutilized modules, so that efficiency can be tweaked to the best advantage. 2.1.7 Ad-hoc reports A tool that in addition to pre-defined (or canned) analysis tools and reports, can also provide the ability to create "user-defined" reports. 2.1.8 Historical data The tool will need to store historical data about the "set(s)" in its analysis venue. That is to say, once the tool is in use, that it has the ability to track any changes entered to the "sets" from the start day of use. This will contribute to the documentation trail as well as providing a functionality link with previous versions of the code being examined. 2.1.9 Windows and network compatibility A tool that is NT compatible. It also needs to be network compatible, that is to say that the tool will be loaded on each individual workstation, but the source code files, historical files, in essence all files that are not specifically the tool's in nature are to reside on a network drive so that all "users" (executing the tool) will have access to all related data. 2.1.10 Audit trail A tool that provides an audit trail maintained on all modules (to further enhance the documentation process) from the time of activation. 2.1.11 No Lines of Code Limitations A tool that does not have a limit on lines of code to be examined. 2.2 Accessibility Requirements 2.2.1 A tool that has a keyboard interface capability that would act in place of a pointing device (such as a mouse), so that if persons using the software are in capable of or have difficulty using a mouse that they can still operate the software. 2.2.2 A tool that does not disrupt or disable activated features of other products that are identified as accessibility features, where those features are developed and documented according to industry standards. The tool also shall not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer. 2.2.3 A tool that provides a visual marker (indication) of where some action may occur if a mouse click or keystroke takes place. This point on a screen indicating where an action will take place is commonly referred to as the "focus." This provision also requires that the focus be readable by other software programs such as screen readers used by computer users who are blind. 2.2.4 A tool that through the use of program code, makes information about the program's controls readable by assistive technology. Simply, information that can be delivered to or received from the user must be made available to assistive technology, such as screen reading software. Examples of controls would include button checkboxes, menus, and toolbars. For assistive technology to operate efficiently, it must have access to the information about a program's controls to be able to inform the user of the existence, location, and status of all controls. If an image is used to represent a program function, the information conveyed by the image must also be available in text. 2.2.5 If the tool uses bitmap images to represent a control or function (e.g. an icon), then the function for that "image" must remain constant throughout the execution of the tool. 2.2.6 A tool that uses the operating system's (OS) controls for displaying text. The OS is the "core" computer software that controls basic functions, such as receiving information from the keyboard, displaying information on the computer screen, and displaying their own information or processing the output of other computer programs. 2.2.7 A tool that does not override user selected contrast and color selections and other individual display attributes, like text size. When an application disables this system wide settings set by the OS, accessibility is reduced. 2.2.8 If the tool utilizes animated icons or animations, the information conveyed by these icons or animations should also be provided in a non-animated form, so that users of assistive technology can attain the same access to the application. 2.2.9 A tool that does not use color as the single method for indicating important information. Example: a program that used red and blue squares to identify the functions of printing and saving a file would not be in compliance as users that are color blind or have limited or no vision would be unable to distinguish these functions. Color can be used to enhance functions but not as the sole basis. 2.2.10 A tool that allows a wide range of color and or contrast settings choices where applied to systems that allow user selectable settings. That is a "wide range of color" is not available on systems that have monochrome screens, preferably if an OS allows adjustments in this area the tool or application should not interfere with these settings. 2.2.11 A tool that does not blink or flash text or icons in the 2 Hz -- 55 Hz frequency range.

Record

Loren Data Corp. 20010614/DSOL012.HTM (W-163 SN50O7D0)