SOURCES SOUGHT
D -- Transform source code into another programming language
- Notice Date
- 1/31/2007
- Notice Type
- Sources Sought
- NAICS
- 541512
— Computer Systems Design Services
- Contracting Office
- Other Defense Agencies, Defense Security Cooperation Agency, Defense Budget and Contracts, 201 12th Street Suite 203, Arlington, VA, 22202-5408, UNITED STATES
- ZIP Code
- 00000
- Solicitation Number
- Reference-Number-DSAMSRFI
- Response Due
- 2/28/2007
- Archive Date
- 3/15/2007
- Description
- SOURCES SOUGHT: TRANSFORMATION OF FORTE COMPUTER CODE THIS IS A REQUEST FOR INFORMATION (RFI) ONLY. This request is for planning purposes only, and does not constitute an Invitation for Bids, a Request for Proposals, a Solicitation, a Request for Quotes, or an indication the Government will contract for the items contained in the RFI. This notice is not to be construed as an acquisition Request For Proposal (RFP), nor is any commitment on the part of the Government to award a contract implied, nor does the Government intend to pay for any information submitted as a result of this request. The Government does not reimburse respondents for any cost associated with submission of the information being requested or reimburse expenses incurred to interested parties for responses to this RFI. Any responses received will not be used as a proposal. Background This is the third Request for Information (RFI) that the Defense Security Cooperation Agency (DSCA) has issued regarding transformation of a software application written for the Sun Unified Development Server (UDS) environment, formerly known as Forte Transactional Object-Oriented Language (TOOL). DSCA is seeking to identify information technology vendors capable of transforming DSCA's source code into another programming language and is attempting to determine the target environments that are obtainable in the marketplace. The first request was issued on Jan 30, 2004, on DSCA's behalf, by the General Services Administration (GSA) Federal Technology Service and focused on cost and technical capabilities. The second request was issued by DSCA on June 2, 2006 and focused on the degree of vendor automation, particularly regarding screen transformation capability and prior volume of code transformed, and on corporation and employee nationality. This RFI seeks more explicit descriptions of the target architecture and environment and vendor preferences regarding certain terms and conditions of a potential future acquisition. Vendors can participate in this RFI regardless of whether they responded to the previous ones. Any future procurement will most likely be initiated in the Spring of 2007 with the objective of commencing work in or after October 2007. (Failure to respond to this RFI will not result in down-selection or otherwise prohibit a vendor from future competition.) DSCA's Challenge DSCA has a large software application, called the Defense Security Assistance Management System (DSAMS). This application supports several business areas associated with the U.S. Government's Foreign Military Sales (FMS) program such as preparation of the contracts between the U.S. and foreign governments and the planning, tracking, and financial management associated with bringing tens of thousands of foreign military personnel to Department of Defense (DoD) schools in the U.S. DSAMS has roughly 900,000 lines of UDS-based TOOL executable source code that compile into 1 client executable and 3 server executables. Other elements of the application include an Oracle 9i database management system (soon to be upgraded to Oracle 10g), custom reports developed using the Cognos Impromptu report generator, and interfaces programmed in Perl. The current production hardware system architecture consists of (a) a central HP RX7620 Integrity server (with Intel Itanium processors that provide hardware-based emulation to run RISC-based executables) running the HP-UX operating system, Oracle 9i RDBMS, UDS Runtime environment, most UDS-based DSAMS business logic (to include batch and on-line services), all Perl logic and (b) an Intel-based Windows server farm running the UDS Runtime environment, UDS-based DSAMS presentation and business logic, Impromptu, and Citrix Metaframe to deliver fat client services to end users Wintel desktops via Citrix ICA client connections. DSCA owns three versions of the DSAMS system. The Production version is run in a Defense Information Systems Agency (DISA) data center in Oklahoma City, OK. Also at that site is a Test and Training system used to formally test pending releases. Finally, at DSCA's software development center, the Defense Security Assistance Development Center (DSADC) in Mechanicsburg, PA, DSCA operates a Development server. Hardware and commercial software for DSAMS must thus be acquired in triplicate. DSCA wishes to migrate the UDS-based client and server portions of DSAMS to another language and runtime environment, while retaining the Oracle, Perl, and Impromptu elements of the system and the user experience of rich screens. The central application server and operating system for the transformed application code need not remain HP and Unix. The objective is to transform the UDS elements of the system at minimum cost and risk to a new, easily maintained environment that provides equal or improved performance and equivalent functionality. DSCA is prepared to consider vendors offering both highly manual and highly automated transformation approaches. However, our expectation is that a highly automated approach to code transformation will lead to minimum cost and defects and offer schedule advantages DSCA's Questions Distributed throughout the following narrative are 25 questions, prefaced by a question number of the form (Qnn). Vendors are requested to respond specifically to those 25 questions, by number. DSAMS Program Phasing DSAMS has been developed in three major phases: The first two phases, known as the Case Development and Case Implementation Modules, were completed in 1999 and 2000, respectively, and have been in production ever since. They are stable and their maintenance and enhancement levels are now low. The third phase, known as the Training Module, was deployed to the Army and Navy in October 2006. It is now in a post-deployment defect reduction phase. Current plans call for major enhancements to be developed in 2007 and 2008 that will allow deployment to the Air Force in October 2008. In between these dates, and subsequent to October 2008, DSCA expects to be making a large number of software changes as problems are discovered in production, known residual defects are removed, and users define new features that would be helpful. As designed, these three major modules, when compiled, result in one monolithic UDS application rather than two or more separately releasable pieces. In the future, DSCA would prefer a more granular application structure. This might require better configuration management tools than DSADC currently uses to manage the many pieces. DSCA would like to complete the transformation from UDS as soon as possible after October 2008. However, the ongoing construction of elements of the Training Module, necessary for Air Force deployment, creates a moving target for the transformation vendor. Presumably, the application must be frozen for some period to allow the vendor time to transform it and the government time to test and accept it. But that freeze must be much shorter than one year to allow DSCA to continue with necessary repairs and enhancements. Consequently, a highly automated approach to transformation is also desirable to minimize downtime for cut-over. One possible sequence of events might be the following: During late 2007 and all of 2008, the vendor can be perfecting the tools used for transformation, testing those tools on an interim version of the application, receiving interim feedback from DSCA on correctness of functionality, and ultimately completing a 100% transformation of that legacy code. This would be called the "Pilot" transformation. Then, around mid-2009, the legacy production application could be frozen, finally transformed, and tested, perhaps in a period of only a few months. This would be called the "Final" transformation. During the Final transformation and testing period, DSCA might be developing new enhancements or repairs to the application in the target environment, but not deploying them until after the final transformation has been accepted and placed in production. The above scenario is only one possible way to approach the problem of scheduling the transformation of a dynamic application. (Q01) Please recommend alternative scenarios that reflect the schedules and timelines that your tools and skills are capable of achieving. Specifically address the time required for a Pilot transformation on a UDS application of 900,000 lines. Specifically address the time required for a Final transformation, once a successful Pilot transformation has been achieved. DSCA is concerned about the need to handle the simultaneous demands of improving the Training Module while also supporting and managing the UDS conversion vendor and conducting the acceptance testing of transformed code. (Q02) Please describe the nature and amount of support that your firm will need from DSCA during the transformation process. This should include the degree of functional expertise, on-site presence, and incremental testing activities that you require. Also indicate whether your firm would need access to a dedicated version of the legacy system to which your firm could autonomously compare the transformed application for equivalency of function and performance. Target Language and Development Environment DSCA is not completely neutral on the preferred target environment, but assumes that the logical choices are either Java/J2EE or Microsoft .Net (in C#.Net, Visual Basic.Net, or a combination). In any event, DSCA would want to maintain the transformed code in a well-integrated and comprehensive Integrated Development Environment. What matters to DSCA is that the transformed code and the Integrated Development Environment allow for highly productive development and maintenance in an easily learned language and that the transformation itself be of low cost and low risk. DSCA believes that the .Net environment is likely to allow more subsequent productivity. But DSCA also values low transformation cost, vendor transformation experience, and high degrees of automation; so other target environments may reduce cost and risk. Consequently, DSCA does not want to mandate a target language and environment at this juncture. Rather it wants to determine what target languages, middleware, and development environments are available, what experience has been had with the .Net target, and the costs associated with adopting a specific target environment. At this point, DSCA is unsure whether it will specify a target language and environment in any subsequent acquisition or whether it will leave these elements to be part of a "best value" decision based more on cost, degree of automation, ease of maintenance, and vendor experience. Risk Management DSCA wants to minimize the risks associated with this transformation. Consequently respondents should comment on each of the following risk areas: DSCA wants to minimize the government?s cost, schedule, and technical risk associated with this transformation. DSCA's preference would be to have the job bid as a firm-fixed-price fixed-schedule award, payable after satisfactory acceptance testing of the Final transformation. (Q03) Please comment on whether your firm would be willing to accept a 100% payment only upon successful completion of the Final transformation acceptance test. (Q04) Please indicate whether your firm would accept a 50% payment at the successful completion of a Pilot transformation (where success is determined by DSCA acceptance testing) and 50% at the successful completion of the Final transformation. DSCA would also like to minimize technical risk by employing a vendor that has an actual track record of prior accomplishment with the target language being promised. However, it may be that the target language that DSCA ultimately deems most favorable requires a vendor with no prior experience. So DSCA would like to learn the degree to which target languages have actually been achieved. (Q05) Please describe the target languages that your firm can deliver and the degree of experience, in both application count and legacy code volume (lines of code), that your firm has with such languages as targets for a UDS transformation. DSCA would also like to reduce integration risk by having the vendor acquire some or all of the necessary hardware, commercial software (including middleware and development environments), and installing them on a turn-key basis in the DSADC Development environment or at least in their own development environment. (Q06) Please describe the degree to which your firm would serve as integrating contractor, delivering a turn-key solution to DSADC, rather than just performing a language conversion function. (Q07) Does your firm have, or would your firm supply, the full development target environment needed at your site for the transformation job, to include hardware and commercial software for the client, application server, and database server and database management system? DSCA would like to minimize risk that the transformed application performs noticeably worse than the legacy UDS application as regards on-line response time and batch cycle time. Consequently, DSCA intends to establish some performance benchmarks on the legacy that the vendor would be expected to match or exceed as an element of acceptance testing. (Q08) Please describe your methods for controlling performance risk and your willingness to demonstrate that the transformed code will perform as well as the legacy application. (Q09) How will the vendor determine what size application server should be provided to deliver this performance? Maintainability Maintainability of the application after transformation is an important issue for DSCA. DSCA expects to enhance the application continually over many years. To minimize costs and maximize corporate knowledge, DSCA uses an in-house maintenance team, augmented as necessary by outsourced support. DSCA expects to provide between 25% and 75% of maintenance in-house, depending on other DSADC missions and the demands for changes to DSAMS. To facilitate early assumption of maintenance duties by the current DSAMS maintenance staff, it would be easiest if attribute names, method names, class names, and embedded comments were preserved. (Q10) Please describe the degree to which this could occur. (Q11) Please indicate if the vendor anticipates employing extensive code refactoring in a manner that would change the object class organization (perhaps in return for improved performance or markedly lower code line count). (Q12) Please indicate if refactoring is an option DSCA can choose to accept or reject. (Q13) Please indicate if tools and/or documents could be furnished to assist the maintenance work force in navigating from the legacy program object class structure to the new one. Describe those tools or documents. DSCA wants to understand the costs of ownership of the development and run-time environment associated with the transformed software. (Q14) Please indicate the Integrated Development Environment (IDE) and run-time environment in which the transformed application would be maintained and operated. Or what commercially available IDEs would be suitable for maintaining the transformed system? (Q15) Please provide an itemized list of the estimated initial and recurring costs of any licenses for middleware, application server software, and development suites associated with the target environments you can deliver. Also recommend and provide estimated costs for any appropriate automated regression testing software and configuration management software. Architectural Issues Vendors may have tools that could migrate the UDS code to Java, .Net, or both. While presumably any target environment and any solution to infrastructure issues is possible with a sufficient expenditure of labor, DSCA seeks to learn about the specifics of the automated tools that might be used as regards the target environment. Consequently we request that the vendor respond to the following questions: (Q16) If your tool can convert the UDS code to Java, please indicate if you can convert specifically to a J2EE-compliant version of Java. What version of J2EE? Does this capability already exist in your tool or is some adaptation of your tool required? (Q17) If your tool can convert UDS to a .Net environment, would it be C#.Net, Visual Basic.Net, either, or some other language? Do these capabilities already exist in your tool or is some adaptation of your tool required? (Q18) Please indicate whether the application resulting from the use of your tool would be web-based in the sense that a user would employ a browser to access the application. Or would the resulting application employ a "fat client" that the users might access via Citrix as with the legacy version? If web-based, would you expect that the application could be moved from client/server to web architecture without additional design work and manual coding? (Q19) If a "fat client" design is to be used, please specify whether it would employ SWING and Abstract Windows Toolkit, JFace and the Standard Widget Toolkit, AJAX, third party widgets, or specific J2EE or .Net libraries not included in the base environment? If a "fat client" design is to be used, please describe what underlying technologies would be used to handle communications between client-side and server-side objects. (Q20) Certain DSAMS infrastructure services (e.g., highlighter, Data Manager) have been custom developed in UDS TOOL code for the legacy application. Some of these might have counterparts in the libraries available with the target environment. Please indicate whether the vendor would automatically transform the custom legacy infrastructure services or would replace them with the analogous library services. (Q21) Please indicate what protocols and standards would be employed in the transformed system? Would a Service Oriented Architecture be used? If so, would it comply with XML, SOAP, and WSDL standards? Would the middleware services (e.g., object brokers, messaging middleware) be provided by some underlying commercial off-the-shelf (COTS) runtime environment, perhaps provided by a specific COTS application server? (Q22) Please indicate if a specific operating system would be needed to run the transformed software or the development environment. DSAMS currently uses a custom Data Manager (one of the infrastructure elements cited in Q20 above) to provide mapping between objects and relational data entities. (Q23) Please indicate specifically how would you move data from the relational database management system to the object-oriented structure and back? How would data integrity be assured in the multi-user environment. What persistence mechanisms would be employed if a web-based presentation is used? Security As currently designed, DSAMS handles user authentication and role-based permission management using custom UDS code and Oracle tables. (Q24) Please indicate how user-related security services would be handled, to include password encryption. Would some or all of this be replaced by library routines? (Q25) As regards the user screens resulting from the transformation, please describe how defenses against data entry attacks such as buffer overflow or SQL injection would be handled. Would the vendor add protections via custom code or existing libraries? Or would the level of editing in the legacy application simply be preserved? Process for Responding 1. Vendors willing to respond to this RFI should send their responses, via e-mail or in writing, to DSCA's contracting officer, Ms. Lisa Davis at Lisa.Davis@dsca.mil or Defense Security Cooperation Agency, Suite 203, 201 12th Street South, Arlington, VA 22202) by February 28, 2007. 2. If a vendor did not respond to the first or second RFI, DSCA requests that, in addition to responding to the 25 questions, the vendor also provide the following information: (a)A corporate description. (b)Lists of major customers and dates of successful UDS code transformation. (c)Any existing GSA or DoD contract vehicles under which DSCA could contract for your services. 3. Vendors should respond to the 25 RFI questions using DSCA?s numbering system to allow DSCA to easily correlate responses to questions. 4. To be helpful in shaping DSCA's acquisition plans, responses should be received by February 28, 2007.
- Place of Performance
- Address: Arlington VA
- Zip Code: 22202
- Country: UNITED STATES
- Zip Code: 22202
- Record
- SN01223230-W 20070202/070131221936 (fbodaily.com)
- Source
-
FedBizOpps Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |