TEXAS DEPARTMENT OF TRANSPORTATION GENERAL...

TEXAS DEPARTMENT OF TRANSPORTATION GENERAL SERVICES DIVISION

SPECIFICATION NO. TxDOT 920-40-65 DATED: JUNE 2006

INTEGRATED FACILITIES MANAGEMENT SYSTEM

PUBLICATION

This specification is a product of the Texas Department of Transportation (TxDOT). It is the practice of TxDOT to support other entities by making this specification available through the National Institute of Governmental Purchasing (NIGP). This specification may not be sold for profit or monetary gain. If this specification is altered in any way, the header, and any and all references to TxDOT must be removed. TxDOT does not assume nor accept any liability when this specification is used in the procurement process by any other entity.

1. SCOPE: This solicitation is a specification for a Request for Offer (RFO) to provide programming services for an Integrated Facilities Management System. This involves integrating existing business automated database systems used by the TxDOT Maintenance Division (MNT) into a single comprehensive computer application.

1.1. The vendor designated project team members shall participate in Joint Application Development (JAD) work sessions with TxDOT Project Manager to determine and finalize detailed tasks on Attachment A – System Phase Tasks to accomplish the specified milestones on Attachment B – System Deliverables.

1.2. The vendor written software solution shall allow MNT division personnel to input data, query data and execute reports, implement management dashboards to allow division personnel to view data and reports easily and comply with all general system requirements as described in Para. 10.1.

1.3. The new system will include Information Systems Division (ISD) support but will be limited to supporting data interfaces, gateway, hardware, and software maintenance and upgrades.

1.4. MNT will be responsible for the administration and supervisory support of the new system.

2. DEFINITIONS OF ACRONYMS AND TERMS

2.1. ACRONYMS

2.1.1. ACA – Asset Condition Assessment: MNT internal asset condition assessment automated system that is used to track asset inventory details, observed defects and photographs, building perspective photographs, building elevation photographs.

2.1.2. AMRS – Asset Management & Reporting System: MNT internal real property asset management automated system that tracks and reports all real property asset data.

2.1.3. APRS – Automated Project Management System: MNT internal proposed project request automated system that tracks biennial project requests and allows staff to create a capital budget to be submitted to external agencies and entities.

1 - 19


2.1.4. CDMS – CAD Document Management System: MNT internal project design folder

request automated system that is used to track internal project design requests, create project folders implementing a standard file structure and allow ad hoc search of project folders.

2.1.5. CD – Compact Disc.

2.1.6. FTP – File Transfer Protocol.

2.1.7. GB – Gigabyte: A unit of information or computer storage equals to one billion bytes.

2.1.8. ISD – Information Systems Division.

2.1.9. JAD – Joint Application Development: A methodology that involves collaborative workshops between end-users and development personnel to jointly design and develop of a computer software application.

2.1.10. MNT – TxDOT Maintenance Division.

2.1.11. PCAS – Property Condition Assessment System: MNT internal property condition assessment automated system comprised of the original property condition assessment survey data compiled in 1995 from data collected by Law Engineering and PSP.

2.1.12. POC – Point-of-Contact.

2.1.13. PM – Project Manager (will be designated as Vendor PM or TxDOT PM.)

2.1.14. SDLC – Software Development Life Cycle: A structure imposed on the development of a software product that includes requirement analysis, specification, design and architecture, coding, testing, documentation, deployment and implementation and maintenance.

2.1.15. VBA – Visual Basic for Applications: The implementation of Microsoft’s® Visual Basic programming language which is built into all Microsoft® Office applications, some other Microsoft® applications such as Visio and supported by other non-Microsoft applications such as AutoCAD® and WordPerfect®.

2.1.16. WDE – Workgroup Development Environment: An established development and production environment for TxDOT districts, divisions and special offices to sustain internal workgroup business applications.

2.2. TERMS

2.2.1. Acceptance Testing – The process of testing system components and system functionality to determine whether the system is ready for implementation.

2.2.2. Ad Hoc Querying – A computer system component that allows users to customize a data query generally from a database in real time by selected data fields without the technical knowledge required to create SQL queries.

2.2.3. Deliverable Test Plan – A document used to communicate the results of system testing and communicates programming errors and problem resolution.

2 - 19


2.2.4. Functional Testing – The process of testing system components and system

functionality in order to validate the separate areas within a given system.

2.2.5. Interface Testing – The process of testing system components and system functionality in order to validate the transfer between two or more system components.

2.2.6. Management Dashboard – An application component that combines decision support data and graphics in a single environment to give users the key information needed to manage daily operations.

2.2.7. Switchboard – A graphical user interface that consists of screen icons (image maps) to simplify the accessing of common system functions, system data or other external application programs.

3. BACKGROUND AND CURRENT ENVIRONMENT

3.1. CURRENT PRODUCTION ENVIRONMENT: The MNT Division uses several non-integrated Microsoft® Access automated database systems serving specific facilities management business needs developed “in-house” by the division system analyst. The division created several gigabytes of business documents related to the automated systems without an interface to locate many of the documents. Databases and electronic business documents are implemented on various network server locations without direct integration and lack a common or intuitive file structure.

3.2. CURRENT PROCESSING ENVIRONMENT: The current processing environment includes Windows 2000 application server, workstations running Windows XP Professional SP2, Microsoft® Access 2002 for database and application development, Microsoft® Visio Professional 2000 and Microsoft® Word 2002 for technical documentation, Computer Associates (CA) Erwin for data modeling, data mapping, and data dictionary.

3.3. IMPLEMENTATION ENVIRONMENT: The developed application shall be developed for deployment into the TxDOT Workgroup Development Environment (WDE). Application development with .NET technology with the implementation of web services is the strategic direction for TxDOT application development. Physical Server Configuration consisting of the Windows 2000/2003 operating systems, shared dual 3GHz Intel processors, 3GB memory, 36.4 GB local storage and 200 GB for SAN storage. Virtual segments are limited to four per server consisting of 512MB for memory and disk storage of 30GB (10GB C drive, 20GB D drive). Database development tool is Microsoft® SQL Server 2000.

4. RESPONDENT QUALIFICATIONS: The respondent shall:

4.1. Be an established business providing business application software development services for a minimum of five years in the last seven years.

4.2. Have successfully completed a minimum of three Visual Basic.NET business solutions in the past five years.

4.3. Shall have at a minimum of three years SDLC experience in the past five years focusing on:

4.3.1. Software project management.

4.3.2. Creation, modification, documenting and deployment of windows-based Visual Basic.NET business solutions.

3 - 19


4.3.3. Design, data migration, data validation and implementation of Microsoft® SQL Server

2000 databases.

4.3.4. System, functional, and acceptance testing.

4.3.5. Training and knowledge transfer to technical and non-technical system users.

4.4. Provide an established offsite work location in the Austin Texas Metropolitan Area. This area is defined as being within a maximum of 25 miles outside of Austin city limits (Ref. Para 9.3. and 17). Storefront locations are not acceptable and do not meet this requirement.

4.5. Be in good financial standing, not in any form of bankruptcy, current in payment of all taxes and fees such as state franchise fees. TxDOT reserves the right to request the respondent’s latest financial statement.

5. REFERENCES: Respondent shall submit references that verify the qualifications and experience requirements for services completed within the past five years. A minimum of three references are required. References shall illustrate respondent’s ability to provide the services outlined in the specification. References shall include name, point-of-contact, telephone number, and dates services were performed. The response will be disqualified if TxDOT is unable to verify qualification and experience requirements from the respondent’s references. The response may be disqualified if TxDOT receives negative responses. TxDOT will be the sole judge of references. (Ref. Schedule 5).

6. KEY PERSONNEL QUALIFICATIONS AND SKILLS: The vendor shall designate the following key personnel with the required qualifications and skills:

6.1. PROJECT MANAGER: The Vendor PM:

6.1.1. Shall have a minimum of seven years of experience in the last ten years as a software development project manager.

6.1.2. Shall have a minimum of three years of experience within the last five years in .NET software development project management including:

6.1.2.1. Coordinating and managing software development, documentation and deployment of windows-based Visual Basic.NET applications.

6.1.2.2. Quality Assurance and Project Performance.

6.1.2.3. Knowledge transfer to end users and technical support staff.

6.1.3. May be a programmer or technical writer. If the Vendor PM is a programmer, the Vendor PM shall also have the qualifications listed in paragraphs 6.2. – 6.2.2.3. If the Vendor PM is a technical writer, the Vendor PM shall also have the qualifications listed in paragraphs 6.3. – 6.3.5.

6.2. PROGRAMMER: Programmer(s) shall have the following qualifications and skills:

6.2.1. Application Development

6.2.1.1. Minimum of five years of experience in the last seven years providing design, development and implementation of computer application software.

4 - 19


6.2.1.2. Minimum of three years of experience in the last five years in providing

services to develop and implement reports and charts using Microsoft® Visual Basic.NET architecture.

6.2.1.3. Minimum of three years of experience in the last five years in providing services to develop and implement Visual Basic.NET windows-based applications.

6.2.1.4. Minimum of one year experience developing and implementing management style dashboards.

6.2.2. Database Development

6.2.2.1. Minimum of three years of experience in the last five years in designing, developing and implementing Microsoft® SQL Server 2000 databases.

6.2.2.2. Minimum of two years of experience in the last five years in providing data verification and data migration from Microsoft® Access databases to Microsoft® SQL Server databases.

6.2.2.3. Minimum of one year of experience in the last three years creating and maintaining logical and physical data models using Computer Associates ERWIN data modeling tool.

6.2.3. A programmer may be a Vendor PM or technical writer. If the Vendor programmer is a Vendor PM, the programmer shall also have the qualifications listed in paragraphs 6.1 – 6.1.2.3. If the programmer is a technical writer, the programmer shall also have the qualifications listed in paragraphs 6.3. – 6.3.5.

6.3. TECHNICAL WRITER: The technical writer shall have the following qualifications and skills:

6.3.1. Minimum of three years of experience in the last five years preparing information technology system documentation by reviewing technical documents.

6.3.2. Minimum of three years of experience in the last five years preparing user manuals, training materials and other knowledge transfer documentation using Microsoft® Word or equivalent word processing software.

6.3.3. Minimum of three years of experience in the last five years preparing online help system documents.

6.3.4. Minimum of one year of experience in the last three years preparing professional documentation using Adobe® PDF.

6.3.5. Minimum of one year of experience in the last three years creating and preparing final documentation to a CD media.

6.4. A technical writer may be a Vendor PM or programmer. If the technical writer is a Vendor PM, the technical writer shall also have the qualifications listed in paragraphs 6.1. – 6.1.2.3. If the technical writer is a programmer, the technical writer shall also have the qualifications listed in paragraph 6.2. - 6.2.2.3.

7. KEY PERSONNEL REQUIREMENTS: The vendor shall provide key personnel with the following requirements:

5 - 19


7.1. PROJECT TEAM MEMBERS: All project team members shall have:

7.1.1. A minimum of three years of experience working in a cooperative team environment maintaining effective working relationships.

7.1.2. Effective written and oral communication skills in English with the ability to convey technical information in a clear and concise manner.

7.1.3. Basic computing skills using Microsoft® Windows XP operating system.

7.1.4. Basic FTP uploading and downloading skills.

7.1.5. The ability to work independently and meet short-term deadlines.

7.1.6. The ability to adhere to strict guidelines for implementation into all required deliverables.

7.2. VENDOR PM: Shall:

7.2.1. Be a permanent staff member.

7.2.2. Have supervisory capacity to direct other vendor designated project team members.

7.2.3. Ensure that TxDOT projects are considered to be a first priority.

8. PERSONNEL CONTINUITY AND REPLACEMENT

8.1. The vendor agrees to ensure the continuity of the Vendor PM, key personnel and team members assigned to the project. The vendor represents and warrants that the referenced personnel shall be available for the entirety of the project and shall remain available throughout the term of the purchase order.

8.2. TxDOT recognizes that events beyond the control of the vendor such as the death, physical or mental incapacity, long-term illness, or the voluntary termination of employment of the project manager may require that the vendor propose a replacement. In the event that such a replacement is necessary, vendor agrees that no replacement person shall begin work on the project without prior written approval from TxDOT.

8.3. If TxDOT determines that the Vendor PM, a team member, or other key personnel are unable to perform in accordance with the service requirements or to communicate effectively, the vendor shall immediately remove that person.

8.4. The vendor shall request in writing and obtain written approval from TxDOT to add or remove personnel.

8.5. Replacement personnel shall meet minimum qualifications, have experience comparable to the person they are replacing and be provided at no additional cost to TxDOT. Prior to designating a replacement, the vendor shall submit the same required documentation as the key personnel being replaced within seven days for review and written approval by TxDOT. TxDOT may reject the replacement if references or past working performance is questionable or unfavorable. TxDOT will be the sole judge of the qualifications of the proposed replacement personnel.

6 - 19


9. VENDOR REQUIREMENTS: The vendor shall:

9.1. Adhere to the TxDOT Terms and Conditions identified on the solicitation.

9.2. Implement the resulting application system on or before July 31, 2007. TxDOT reserves the right to test the product 30 days prior to final acceptance.

9.3. Provide all the required personnel in an offsite work location in the Austin Metropolitan Area necessary to meet the requirements of the specified services throughout the term of the purchase order.

9.4. Provide all the required hardware and software necessary to develop and implement the software application described in this specification. All hardware and software shall meet TxDOT Core Architecture or be approved in writing by TxDOT.

9.5. Provide one copy of the software development tool and one copy of the online help tool used to develop and implement the resulting vendor written software application.

9.6. PROJECT MANAGEMENT: Manage the development and implementation of work by assuring all phases are approved in writing by TxDOT and accomplished without significant delays, problems or re-work. Delays due to changes both within and outside vendor’s control shall require written approval by TxDOT.

9.6.1. Participate in monthly project status reviews to ensure measurable progress is being achieved and project team is following standard procedures.

9.6.2. Control the work by documenting and reporting weekly progress and accomplishments of the project team.

9.6.3. Provide weekly uploads of project deliverables to the TxDOT provided FTP site.

9.6.4. Administer the work by establishing and maintaining communications with all groups related to the project. The activities of the vendor project team shall be directed, coordinated and communicated to ensure that project milestones are completed on schedule.

10. SERVICE REQUIREMENTS: The vendor shall perform the following:

10.1. GENERAL SYSTEM REQUIREMENTS

10.1.1. Design, develop and migrate existing data to a new Microsoft® SQL Server 2000 database and produce the required database documentation as described in Para. 4 of Attachment C - Documentation Requirements. The database deliverables shall be generated using the CA ERWIN Data Modeling tool.

10.1.2. The vendor written solution shall be developed with Visual Basic.NET 2005.

10.1.3. The vendor written solution shall comply with Attachment D – System Interface Requirements; Attachment E – System Coding Requirements; TxDOT Core Technology, Version 5.3, Revised March 2006; and TxDOT Data Architecture, Version 3.0, Revised February 2006.

10.1.4. The vendor written solution shall implement the required system functionality as described in Attachments F – P (Ref. Table of Contents for Attachment Titles).

7 - 19


10.1.5. The vendor written solution shall implement the application security access for user

roles and profiles as described on Attachment Q – System Access Security Criteria.

10.1.6. The developed system shall encompass any functionality approved by TxDOT as result of JAD sessions with the vendor designated project team members.

10.2. DATABASE DEVELOPMENT: Produce required logical data model, physical data model and data dictionary as outlined in the TxDOT Data Architecture document.

10.2.1. TxDOT will provide initial logical data model implementing functionality requirements. The vendor shall combine, modify and maintain data models into one comprehensive data model.

10.2.2. The vendor shall be responsible for modeling data entities that will be used to implement all the required functionality of the system.

10.2.3. The vendor shall create the SQL Server 2000 database and deploy to TxDOT WDE. Existing data structures to be implemented into the vendor written database solution are summarized on Attachment R – Existing Data Structures.

10.3. APPLICATION DEVELOPMENT: Design, develop, document and deploy a vendor written software application implementing Visual Basic .NET architecture satisfying the requirements described in Para. 10.1.

10.4. SYSTEM TESTING: The vendor shall participate in interface, functional and system testing of all deliverables as described in Para. 14.

10.5. DOCUMENTATION: The vendor shall develop required project documentation as described in Attachment C.

10.6. KNOWLEDGE TRANSFER AND TRAINING: The vendor shall develop and implement a training and knowledge transfer plan as described in Para. 10.11.

10.7. SYSTEM IMPLEMENTATION: The vendor shall coordinate its efforts with ISD in order to ensure compatibility between their software and TxDOT architectural environment including conversion programs, interface programs, and other tasks that are required for implementation of new software solution. The vendor shall develop and maintain an Implementation Plan as described in Para. 10.12.

10.8. PROJECT WORK PLAN: The vendor shall develop and maintain a project work plan using Microsoft® Project 2003 specifying project phases, milestones, project tasks, anticipated timelines and the appropriate resources to accomplish each task. The plan shall be updated and submitted electronically via email for deliverable approval, during monthly status reviews and with payment invoices.

10.9. CONFIGURATION MANAGEMENT PLAN: The vendor shall develop and maintain a configuration plan identifying how the various components of the system are associated and how the components shall be managed throughout their lifecycle.

10.10. CHANGE CONTROL PLAN: The vendor shall develop and maintain a change control plan to define how the project deliverables may be changed throughout the project. It shall include the procedures and entities involved with responsibility for approving changes to the project deliverables. The plan shall cover scope requirement changes and other changes that can affect project milestones.

8 - 19


10.11. TRAINING AND KNOWLEDGE TRANSFER PLAN: The vendor shall develop and maintain

Training and Knowledge Transfer Plan.

10.11.1. Power User Training: This training shall provide allow selected MNT personnel to train other MNT personnel to effectively use the system. Training sessions shall be relevant to personnel who will maintain system data and personnel whom will only access system data.

10.11.2. Technical Training: The vendor shall provide training to TxDOT technical personnel to transfer knowledge to operate, troubleshoot, enhance and maintain the vendor written application. The technical training shall include explanation of database structures including triggers, queries and constraints implemented. Documentation of user setups, including complete security and rights for individuals and groups, individual and module restrictions and reporting and validation privileges. It shall also cover known maintenance issues with the system.

10.12. IMPLEMENTATION PLAN: The vendor shall develop and maintain an implementation plan that describes how the application will be deployed, supported, and managed in the technical environment. The plan shall include a detailed implementation schedule that describes the tasks associated with implementation and any applicable information regarding implementation, such as dependencies, constraints and assumptions.

10.13. JOINT APPLICATION DEVELOPMENT (JAD) WORK SESSIONS

10.13.1. Initial JAD Work Session: TxDOT will hold a mandatory initial JAD work session seven days from the purchase order award date. This work session will be held in conjunction with the post award meeting (Ref. Para. 31). The vendor shall refine the Project Work Plan to include specific tasks developed during this work session and submit to TxDOT within three business days.

10.13.1.1. Service Requirements Review: The meeting will serve as an overview to deliverables, determine project logistics and review the project plan.

10.13.1.2. Existing Systems Overview: TxDOT will demonstrate existing automated systems to be replaced by the vendor written solution.

10.13.1.3. Database Development: During the JAD work session, the project team will discuss the TxDOT Data Architecture document and review data structures to be included in the project.

10.13.2. Deliverable JAD Work Sessions: The vendor shall participate in JAD work sessions to determine technical aspects, screen aspects and reporting aspects of system deliverables and throughout its development.

11. STATUS REPORTING AND REVIEWS: TxDOT will perform weekly progress checks and monthly project status reviews designed to ensure measurable performance has been achieved and standard practices are been adhered to.

11.1. MONTHLY STATUS REPORTS: The vendor shall submit Attachment S - Monthly Status Report via email due by 1:00 pm on the 1st working day of each month. The vendor shall submit an update Project Work Plan with each monthly status report. The Vendor PM and TxDOT PM shall meet in person to discuss the status report.

9 - 19


11.2. WEEKLY PROGRESS REPORTS: The vendor shall submit Attachment T – Weekly Progress

Check Report via email due on each Friday by 1:00 pm.

11.3. PROJECT MEETINGS: Meetings will be scheduled at a minimum of once a month or as needed and shall be conducted at the MNT work location in Austin. Vendor project team members shall be available to provide information reports, audits or other special reports as required by the TxDOT PM.

11.4. PROJECT DELIVERABLES: The vendor shall transmit all project deliverables to TxDOT in the specified FTP location for each weekly progress checks and monthly status reviews.

12. DATABASE DEVELOPMENT: The vendor shall design and develop the database solution as described in Para. 10.2. The database solution shall include:

12.1. Required data structures as described in Attachment R.

12.2. Creation of new data structures to satisfy the requirements of the system development phase.

12.3. The database deliverables described on Attachment B.

13. SYSTEM DEVELOPMENT: The vendor shall design and develop the application solution satisfying all the requirements described in Para. 10.1. The application solution shall include:

13.1.1. The system development deliverables described on Attachment A.

13.1.2. System functionality resulting from JAD work sessions.

14. SYSTEM TESTING: The vendor shall participate in system testing of every deliverable. All deliverables shall be tested and approved using Attachment U – Deliverable Test Plan. The Vendor PM shall initiate the testing activity.

14.1. The Vendor PM shall contact the TxDOT PM to arrange a testing date.

14.2. The Vendor PM shall submit Attachment U via email to the TxDOT PM.

14.3. The Vendor PM shall submit test deliverables two days prior to the arranged testing date.

14.4. The TxDOT PM will test submitted deliverables in the TxDOT WDE prior to the arranged testing date and make notations on the submitted Deliverable Test Plan.

14.4.1. TxDOT testing will include a project team of technical support and typical system users.

14.4.2. TxDOT will test the deliverables for two days before arranging a project meeting with the vendor.

14.5. Both parties shall meet at MNT work location to review the Deliverable Test Plan, discuss the results of the testing activity and determine any necessary problem resolutions.

15. SYSTEM IMPLEMENTATION: The vendor shall deploy the application solution upon system certification approval from TxDOT. The deployment process shall comply with the Implementation Plan developed by the vendor and will include ISD support. The vendor shall submit all source code, build documents, executable files, installation files and any other files that will be required to rebuild, troubleshoot, maintain and operate the vendor written solution.

10 - 19


16. TRAINING: The vendor shall provide training sessions to provide end user training and transfer of

technology knowledge as outlined in the vendor’s Training and Knowledge Transfer Plan (Para. 10.11.) and includes the training documentation such as the technical manual and user manual.

17. WORK LOCATION AND HOURS: The vendor designated project team members shall work in a vendor provided work location within the Austin Metropolitan Area. The vendor project team members shall be available for phone and email communications with TxDOT Monday through Friday, 8:00 a.m. through 5:00 p.m.

18. PERSONNEL DUTIES

18.1. Vendor PM: Shall:

18.1.1. Serve as the primary POC for TxDOT.

18.1.2. Coordinate, oversee and monitor the status and progress of all project work deliverables by prepare monthly status reports, weekly progress reports and maintain the project schedule.

18.1.3. Initiate testing, system implementation and training and knowledge transfer activities.

18.1.4. Transmit deliverables to the TxDOT approved FTP location weekly and upon final approval of the deliverable.

18.1.5. Submit payment invoices.

18.2. Programmer(s): Shall:

18.2.1. Perform delegated tasks involved with the database development phase as described in Para. 10.2.

18.2.2. Perform delegated tasks involved with the system development phase as described in Para. 10.3.

18.2.3. Participate in JAD work sessions as described in Para. 10.13.

18.2.4. Participate in system testing as described in Para. 14.

18.2.5. Correct and remedy any programming errors attributable to the vendor within a reasonable timeframe agreed upon between TxDOT and the vendor.

18.2.6. Develop required system documentation as described in Attachment C.

18.2.7. Participate in monthly status reviews and weekly progress checks as requested by TxDOT.

18.2.8. Participate in training and knowledge transfer activities as outlined in the Training and Knowledge Transfer Plan (Para. 10.11.)

18.2.9. Participate in system implementation of the vendor written solution.

18.3. TECHNICAL WRITER: Shall:

18.3.1. Develop required documentation following guidelines as described in Attachment C.

11 - 19


18.3.2. Develop online help system documentation.

18.3.3. Develop required documentation using TxDOT templates and guidelines.

18.3.4. Be responsible for documentation quality assurance.

18.3.5. Coordinate and organize all documentation activities with other vendor designated project team members.

18.3.6. Prepare all documentation for final delivery.

19. VENDOR DELIVERABLES

19.1. Attachment A describes the initial tasks to be performed to produce all the deliverables specified on Attachment B. Attachment A shall be refined by the vendor upon award of the contract and serves as a starting point.

19.2. All project deliverables will be reviewed and approved by the TxDOT PM before the deliverable is considered complete and useable.

19.3. Deliverables will be reviewed and approved by the TxDOT PM before the vendor submits payment invoices. The TxDOT PM may consider modification or exception during the review on a case by case basis.

19.4. All deliverables shall be virus free. If a virus is found, the deliverables will be returned to the vendor and shall resubmit deliverables certified virus free at no additional cost to TxDOT.

19.5. JAD work sessions will initiate each delivery task and continue through the milestone’s development life cycle to determine all of its specific requirements.

19.6. Each milestone shall be reviewed and approved by the TxDOT PM in the manner described in Para. 14.

20. TxDOT RESPONSIBILITIES: TxDOT will:

20.1. Provide a FTP location to facilitate the submittal of project deliverables during all phases of the project.

20.2. Approve all personnel used by the vendor.

20.3. Reserve the right to approve all hardware and software used by the vendor.

20.4. Document vendor performance and unacceptable performance may result in the cancellation of the purchase order.

20.5. Provide preliminary data models for each automated system implementing required functionality.

20.6. Provide Monthly Status Review template (Ref. Attachment S).

20.7. Provide Weekly Progress Checks template (Ref. Attachment T).

20.8. Provide Documentation templates for user manual and system documentation (Ref. Attachment C).

12 - 19


20.9. Provide Vendor Payment Invoice (Ref. Attachment V).

21. SUBCONTRACTING: Subcontracting is allowed under the following circumstances.

21.1. The vendor shall be the only contact for TxDOT and subcontractor(s).

21.2. Subcontractors providing service under the purchase order shall meet the same requirements and provide the same service and level of experience as required of the vendor.

21.3. No subcontract under the purchase order shall relieve the primary vendor of responsibility for the services.

21.4. The vendor shall maintain all project management, schedules, performance and responsibilities for subcontractors. The vendor shall be held solely responsible and accountable for the completion of all work for which the vendor has subcontracted.

21.5. TxDOT reserves the right to request the removal of vendor’s subcontractor staff deemed unsatisfactory by TxDOT.

21.6. Subcontracting shall be at the vendor’s expense.

21.7. If a respondent plans to subcontract all or a portion of the work to a Texas Certified HUB business, the respondent shall identify the proposed subcontractor(s) at the time of response submittal using the HUB Subcontracting Plan forms attached to this solicitation.

21.8. If a respondent plans to subcontract all or a portion of the work to a subcontractor who is not a HUB, the respondent shall identify the proposed subcontractor(s) at the time of response submittal.

21.9. TxDOT retains the right to check subcontractor's background and make a determination to approve or reject the use of submitted subcontractor(s). Any negative responses may result in disqualification of the subcontractor.

21.10. The vendor shall pay all subcontractor(s) in accordance with Texas Government Code §2251.022.

22. SOFTWARE DELIVERY AND INTELLECTUAL PROPERTY RIGHTS

22.1. DELIVERY: The vendor shall:

22.1.1. Deliver all custom and reuse software, if used, as machine readable source files, and linkable or executable modules, and printed source listings, in addition to installed and operating copies of the programs (baseline software or hardware configuration shall not be created such that only vendor could change).

22.1.2. Identify the tools required for the modification and compilation of the custom and reuse software programs.

22.1.3. Deliver source codes for all custom and reuse software programs developed under the purchase order with all needed support resources needed to edit, compile and link these programs on the central processors, including, but not limited to: CASE tools, compilers, editors, and function libraries used in the development of the programs.

13 - 19


22.1.4. Deliver all documentation concerning protocol for reuse and custom software, source

code, commented listings, descriptions of software structure, database utilization, and instructions necessary to convert the source code into an operational system.

22.2. SOFTWARE: The vendor shall not:

22.2.1. Create software that only the vendor could modify.

22.2.2. Create or utilize reuse software that is not in the public domain.

22.3. CUSTOMIZED SOFTWARE LICENSE: The vendor shall not place any legend on the custom or reuse software, which restricts TxDOT’s rights in such software unless the restrictions are set forth in a license agreement approved and executed by TxDOT.

22.4. OWNERSHIP

22.4.1. The vendor shall transfer to TxDOT or purchase for TxDOT all licenses to software acquired in conjunction with this project, including all original media, documentation, warranties, licenses, applications software, and developmental software used in developing custom applications.

22.4.2. In the event that custom software development is required, TxDOT will own the entire rights (including copyrights, copyright applications, copyright renewals, and copyright extensions), title and interests in and to the custom software development documentation, software, and any other intellectual properties created for custom software and versions thereof, and all works based upon, derived from, or incorporating works thereof, and in and to all income, royalties, damages, claims, and payments now or hereafter due or payable with respect thereto, and in and to all causes of action, either in law or in equity for past, present, or future infringement based on the custom software and copyrights arising there from, and in and to all rights corresponding to the custom software and versions thereof throughout the world. TxDOT shall retain ownership of all production and historical data produced by the proposed system.

22.4.3. OWNERSHIP

22.4.3.1. WORK IN PROGRESS: All work in progress items including data models, databases, application source code and objects, documentation or any other items developed to satisfy this specification shall be the property of TxDOT.

22.4.3.2. POST ACCEPTANCE: Upon acceptance by TxDOT of any of the deliverables, such deliverables shall become the property of and full ownership conveyed to TxDOT. Such deliverables shall include, but not limited to, physical and logical data models, project schedules, databases, programmed application, requirement documentation, software and any other items created by the work performed by the vendor. All copyrights, printing, reprinting, publishing, and republishing rights for any publications shall be in the name of or conveyed to TxDOT.

22.5. SOFTWARE LICENSING: The vendor offer shall include provisions for TxDOT to have escrow account access to, and receive, the source codes and data for any licensed products upon the failure or demise of the vendor’s company.

14 - 19


23. ACCEPTANCE OF GOODS AND SERVICES: All goods furnished and all services performed under

the purchase order shall be to the satisfaction of TxDOT and in accordance with the specification, requirements, terms and conditions of the specification and the agreement. TxDOT reserves the right to inspect the goods furnished or the services performed, and to determine the quality, acceptability and fitness of such goods or services. Prior to final acceptance, all documentation deliverables shall be provided by the vendor and approved in writing by TxDOT in accordance with Attachment C.

24. CONFIDENTIALITY: Vendor acknowledges that the source code, program, and related documentation constitute valuable trade secrets for TxDOT. Vendor shall not disclose, publish, or disseminate them to any third party who is not bound by a disclosure statement expressly covering TxDOT intellectual property and related documentation. The vendor, the vendor’s employees, subcontractors and their employees shall sign a disclosure statement.

25. BUSINESS CONTINUITY PLAN: The respondent shall provide a Business Continuity Plan which shall include the following:

25.1. Procedures that shall be implemented to fulfill all requirements of the purchase order in case of fire, theft, natural disaster, technical difficulty, work-force problems or other disruption of business.

25.2. A disaster recovery plan for recovery of the data for this service shall be maintained in case of fire, theft, natural disaster, or technical difficulty. The vendor shall be responsible for all cost of the disaster recovery plan. The disaster recovery plan may include the transfer of this service to a subcontractor as approved in writing by TxDOT.

26. INVOICING INSTRUCTIONS: Using Attachment V, the vendor shall submit an original correct, comprehensive and detailed invoice for payment every thirty days when milestones have been approved in writing by TxDOT. The invoice shall be mailed to the address shown on the purchase order and shall include the following:

26.1. Purchase order number.

26.2. Phase

26.3. Milestone.

26.4. Milestone rate.

26.5. Approved date.

26.6. Invoices that require correction(s) shall be re-submitted with a new invoice date.

27. PAYMENT REQUIREMENTS: Payment measurement for each invoice shall be based only on the number of milestone completed and approved in writing by TxDOT. The vendor shall note the negotiated rate for each approved milestone using Attachment V. Negotiated milestone rates are detailed on Schedule 1 – System Pricing Schedule.

28. RESPONSE SUBMISSION: Failure to provide the required information will result in disqualification of the response. The response submission shall be in the following format.

28.1. GENERAL FORMAT: The respondent shall submit one signed and dated original (marked “Original”) and five reproduced copies (marked “Copy”) in the following format:

15 - 19


28.1.1. The submission (Original and Copies) shall be in a three ring binder (not spiral bound)

and tab-indexed.

28.1.2. The submission (Original and Copies) shall be limited to one-sided white bond paper, font style Arial, size 10 point, with one-inch margins in the order shown below.

28.2. ORIGINAL RESPONSE: The respondent shall submit Section 1 through Section 10 with the original response.

28.2.1. Section 1 – Request for Offer: Signed and dated original. NOTE: If Addendums are issued as part of this solicitation, include the orginal signed and dated addendums in Section 1.

28.2.2. Section 2 – Schedule 1 - System Pricing: The respondent shall submit Schedule 1 to specify the estimated hours and overall cost needed to perform each phase of the project and estimated cost per phase. The schedule shall calculate the negotiated milestone rates by dividing the total milestone per phase by the estimated phase cost.

28.2.3. Section 3 - Schedule 2 – Company History and Profile: The respondent shall submit Schedule 2 to describe company details, contact person information and company overview details.

28.2.3.1. Statement indicating if the respondent has more than one office, office location(s), staff size per office and if the project is to be a joint venture or includes the use of subcontractors.

28.2.3.2. Statement indicating respondent is in good financial standing, not in any form of bankruptcy, current in payment of all taxes and fees.

28.2.4. Section 4 - Schedule 3 - Vendor Documentation of Work Capability: The respondent shall submit the provided schedule as documentation of work capability. The vendor may provide additional documentation that describes their ability to perform the services outlined in this specification.

28.2.5. Section 5 – Schedule 4 – Project Manager Profile & Documentation of Work Capability

28.2.5.1. The vendor shall submit Schedule 4 – Vendor Project Manager Profile & Documentation of Work Capability for each proposed PM to demonstrate the PM’s ability to provide the project management duties as described in Para. 6.1 and 8.2.

28.2.5.2. The vendor shall submit an example of a work schedule and plan managed by the Vendor PM.

28.2.6. Section 6 - Schedule 5 - Programmer Profile & Documentation of Work Capability

28.2.6.1. Profile and References: The vendor shall submit Schedule 5 - Programmer Profile & Documentation of Work Capability for each proposed programmer to demonstrate the programmer’s ability to provide the required duties as described in Para. 6.2.

16 - 19


28.2.6.2. Quality of Work Documentation: For each proposed programmer, the

vendor shall submit a one page examples of system coding, screen design, report design and system documentation to demonstrate the programmer’s quality of work.

28.2.7. Section 7 – Schedule 6 - Technical Writer Profile & Documentation of Work Capability

28.2.7.1. Profile and References: The vendor shall submit Schedule 6 - Technical Writer Profile and Documentation of Work Capability to demonstrate the technical writer’s ability to provide the required duties as described in 6.3.

28.2.7.2. Quality of Work Documentation: For each proposed technical writer, the vendor shall submit one-page examples of a user manual and online help documentation to demonstrate the technical writer’s quality of work.

28.2.8. Section 8 - Project Work Plan: The respondent shall submit an initial Project Work Plan to demonstrate how the required deliverables will be implemented by July 31, 2007. Attachment A may be used when creating the work plan.

28.2.9. Section 9 - Business Continuity Plan: The respondent shall submit a business continuity plan as described in Para. 25.

28.2.10. Section 10 - HUB Subcontracting Plan

28.3. CD REQUIREMENT: The respondent shall submit Section 1 through Section 10 on a CD with the signed and dated original response.

28.4. COPIES: The respondent shall include only the following sections in the five reproduced copies:

28.4.1. Section 3: Schedule 2 - Company History and Profile

28.4.2. Section 4: Schedule 3 - Vendor Documentation of Work Capability

28.4.3. Section 5: Schedule 4 - Project Manager Profile & Documentation of Work Capability

28.4.4. Section 6: Schedule 5 - Programmer Profile & Documentation of Work Capability

28.4.5. Section 7: Schedule 6 - Technical Writer Profile & Documentation of Work Capability

28.4.6. Section 8: Project Work Plan

28.4.7. Section 9: Business Continuity Plan

29. RESPONSE EVALUATION PROCEDURE: Only a complete response meeting the items identified on Attachment X - Minimum Submittal Requirements and Qualifications will be considered. Failure to meet the minimum requirements will result in a response being declared non-responsive. TxDOT has sole discretion and reserves the right to reject any or all responses. TxDOT will use the following process to evaluate all responses.

29.1. STEP 1 - RESPONSE EVALUATION: A TxDOT evaluation committee will evaluate and score each response. All responses meeting the minimum requirements will be evaluated according to the respondent’s ability to best satisfy TxDOT’s requirements.

17 - 19


29.1.1. Response will be evaluated and scored based on the best value criteria listed in

Paragraph 29.1.4. and criteria listed on Attachment Y - Evaluation Criteria.

29.1.2. Evaluation of response information submitted provided with the solicitation will be 60% of the evaluation total.

29.1.3. The price submitted for the project will be 40% of the evaluation total.

29.1.4. Best value criteria to be used is as follows:

29.1.4.1. Responsiveness to the solicitation service requirements.

29.1.4.2. Key personnel strengths based on required profiles submitted relating to this specification.

29.1.4.3. Past experience in successfully providing this service.

29.1.4.4. Additional points will be given based on experience.

29.2. STEP 2 - INTERVIEW: TxDOT reserves the right to conduct a formal interview with the respondent(s). The selected respondent(s) shall present a demonstration or oral presentation that demonstrates the respondent’s ability to satisfy the requirements of this specification. The vendor PM, key technical and business personnel of the implementation team must attend for answering any TxDOT questions.

29.3. STEP 3 – BEST AND FINAL OFFER (BAFO): After oral presentations, TxDOT reserves the right to continue discussions or negotiations with selected respondent(s). TxDOT may determine to award the purchase order for the service without requesting a BAFO, if it is in the best interest of TxDOT. TxDOT reserves the right to request a BAFO from selected respondent(s). The respondent(s) shall submit a final price and any added value or incentives. If more than one respondent reaches this level, the negotiated terms, references, and BAFO will be the deciding factors in award.

30. AWARD: Award will be made to the most responsive, qualified respondent. TxDOT reserves the right to award on the basis of best value that meets the needs and requirements of this solicitation. TxDOT will be the sole judge of best value.

31. POST-AWARD MEETING: Vendor(s) shall attend a post-award meeting in Austin, Texas with TxDOT within seven calendar days after award of the purchase order. The purpose of the meeting will be to discuss the terms and conditions of the purchase order and to provide additional information regarding project work plans.

32. CONTRACT ADMINISTRATION: Upon issuance of purchase order, TxDOT will assign an individual who will be the designated TxDOT division representative for the purchase order. The designated TxDOT representative’s primary objective is contract administration which includes, but is not limited to, the following:

32.1. Monitoring the vendor’s progress and performance and ensuring services conform to established specification requirements.

32.2. Meeting with the vendor as needed to review progress, discuss problems and consider necessary action.

18 - 19


32.3. Identifying breach of contract by assessing the difference between contract performance and

non-performance.

32.4. Renewal Period of Purchase Order:

32.4.1. A minimum of 90 to 120 days before the expiration of the PO, the purchaser and the end user will determine if service contract is still needed. The end user must agree to renew the PO.

32.4.2. Sixty days prior to the PO expiration date, the purchaser will prepare and send the PO Renewal form letter to the vendor. This letter asks the vendor if they wish to renew the PO.

32.5. Other areas as identified by the Texas Building and Procurement Commission State of Texas Contract Management Guide, latest edition.

19 - 19


ATTACHMENT A

SYSTEM PHASE TASKS (for informational purposes only)

PHASE I – PROJECT INITIATION (JAD SESSION AND REFINED PROJECT MANAGEMENT DOCUMENTS) Review Project Work Plan Review Configuration Management Plan Review Change Control Plan Review Training and Knowledge Transfer Plan Review Implementation Plan Initial Joint Application Development Session PHASE II – DATABASE DEVELOPMENT Logical Model – 10% Complete Checkpoint Logical Model – 50% Complete Checkpoint Logical Model – 75% Complete Checkpoint Logical Model – 100% Complete & Final Approval Physical Model – 10% Complete Checkpoint Physical Model – 50% Complete Checkpoint Physical Model – 75% Complete Checkpoint Physical Model – 100% Complete & Final Approval Physical Database – ISD DBA Approval Data Conversion Plan Data Conversion – Test Sampling Data Conversion – Final Conversion Database Deliverable Implementation into WDE PHASE III – SYSTEM DEVELOPMENT AMRS Component – Screens & related system functions AMRS Component – Reports ACS Component – Screens & related system functions ACA Component – Reports APRS Component – Screens & related system functions APRS Component – Reports Space Utilization – Screens & related system functions Space Utilization – Reports Asbestos Abatement Component – Screens & related system functions Asbestos Abatement Component – Reports CDMS Component – Screens & related system functions CDMS Component – Reports Initial Application Switchboard Management Dashboard – Facility Dashboard Management Dashboard – Asset Statewide Summary Management Dashboard – Building Dashboard Management Dashboard – Asbestos Abatement Management Dashboard – Project Projects Management Dashboard – Condition Assessment Management Dashboard – Ad hoc Reporting Management Dashboard – PM Dashboard Business Document Search Component Facility Aerial Image Application Switchboard – Final (after all other components developed) Online Help System

1 - 2


Final Approval ATTACHMENT A – Cont.

PHASE IV – DOCUMENTATION REVIEW (FINAL DELIVERY FORMAT) User Manual Technical Manual Database Documentation All source contains in-line coding comments System Documentation PHASE V – FINAL SYSTEM TESTING & USER ACCEPTANCE All system functions approved All report return expected results and produce specified formats GUI follows guidelines and error free Seamless execution in WDE End User Acceptance PHASE VI – IMPLEMENTATION PHASE VII – TRAINING

2 - 2


ATTACHMENT B

SYSTEM DELIVERABLES

33. PHASE I – PROJECT INITIATION: This phase shall begin 14 working days following the successful award of the purchase order and the vendor shall submit refined and more detailed version of the following documentation and participate in the initial joint JAD work session.

33.1. Project Work Plan (Para. 10.8)

33.2. Configuration Management Plan (Para. 10.9)

33.3. Change Control Plan (Para. 10.10)

33.4. Training/Knowledge Transfer Plan (Para. 10.11)

33.5. Implementation Plan (Para. 10.12)

33.6. Initial JAD Work Session (Para. 10.13.1)

34. PHASE II – DATABASE DEVELOPMENT

34.1. DATA CONVERSION PLAN: A plan that describes the approach to migrate existing data to the new database schema including:

34.1.1. Testing a conversion sample of data

34.1.2. Initial data conversion

34.1.3. Final data conversion

34.2. LOGICAL DATA MODEL: A data model defines data entities, attributes and their relationships. It is sometimes referred to as an Entity/Relationship Diagram or ERD. An ERD plus descriptions of the entities and relationships represents a Logical Data Model. Data models also include identification of unique identifiers or keys for each implemented. TxDOT’s standard data modeling tool is ERWIN.

34.3. PHYSICAL DATA MODEL: The Physical Data Model is generated from the Logical Data Model and is specific to the target database platform where the physical database tables will reside. The Physical Data Model consists of tables (entities from the Logical Data Model), columns (attributes from the Logical Data Model), column formats and lengths, primary and foreign keys. Stored procedures and triggers may be part of the data model. TxDOT’s standard data modeling tool is ERWIN.

34.4. Microsoft® SQL Server 2000 physical database

35. PHASE III – SYSTEM DEVELOPMENT: This phase includes all the milestones involved in the development of the vendor written software application.

35.1. ATTACHMENT F: Application Switchboard Requirements

35.2. ATTACHMENT G: Management Dashboard Requirements

35.3. ATTACHMENT H: AMRS Requirements

1 - 2


ATTACHMENT B – Cont.

35.4. ATTACHMENT I: ACA Requirements

35.5. ATTACHMENT J: Space Utilization Requirements

35.6. ATTACHMENT K: Asbestos Abatement Requirements

35.7. ATTACHMENT L: CDMS Requirements

35.8. ATTACHMENT M: APRS Requirements

35.9. ATTACHMENT N: Ad Hoc Query Search Requirements

35.10. ATTACHMENT O: Business Document Search Requirements

35.11. ATTACHMENT P: Facility Aerial Maps

36. PHASE IV – DOCUMENTATION REVIEW: This phase includes the final review and acceptance of all system documentation from in-line code documentation to the User Manual. All documentation shall comply with the guidelines specified in Attachment C – Documentation Requirements.

37. PHASE V – IMPLEMENTATION: This phase includes the implementation of the vendor written software application on TxDOT’s WDE. The vendor shall submit all source code, build documents, executable files, installation files and any other files that will be required to rebuild, troubleshoot, maintain and operate the vendor written solution.

38. PHASE VI–FINAL TESTING & USER ACCEPTANCE

38.1. The vendor written software application shall pass a demonstration and initial final acceptance testing and complete a 30-day testing period by MNT for final acceptance. This testing period shall be used to determine if the vendor solution meets all requirements of the specification.

38.2. If the solution is executes successfully without logically and functional errors and meets all requirements of this specification, TxDOT will deem the solution acceptable.

38.3. If the solution fails to meet all requirements, the vendor shall make modifications, or repairs, or both, and the test shall be restarted. If the solution fails to meet all the requirements during the second 30-day testing period; the solution may be deemed unacceptable by TxDOT and declared cancelled.

39. PHASE VII – TRAINING: This phase includes the implementation of the Training/Knowledge Plan and includes hands-on training of TxDOT ISD and MNT technical staff and subject expert users.

2 - 2

ATTACHMENT C DOCUMENTATION REQUIREMENTS

1. GENERAL REQUIREMENTS

1.1. All documentation shall be generated and submitted in a format either supplied by or approved by TxDOT.

1.2. All documentation shall be generated on software programs meeting TxDOT Core Technology specifications or as approved by TxDOT.

1.3. Text based documentation shall be generated using Microsoft® Word.

1.4. Graphical documentation shall be generated using Microsoft® Visio 2000.

1.5. FINAL DELIVERY FORMAT: All deliverables shall be submitted for final approval in the following format.

1.5.1. Include a table of contents; be professional in appearance and provided in PDF format on CD digital media.

1.5.2. PDF documents shall be stored in a “production” document folder on the CD.

1.5.3. Source documents shall be stored in a “source” document folder on the CD.

2. USER TRAINING MANUAL: The vendor shall provide a “how-to” end user manual to document how to perform systems tasks and navigate through the system. This manual shall be:

2.1. Accessed from the vendor written solution.

2.2. Logically indexed.

2.3. Generated using the user manual template provided by TxDOT.

3. ONLINE HELP SYSTEM: The vendor shall develop and implement online help system typical of window based applications that can be accessed through the use of the menu system and accessed when the user presses the F1 key. Each screen developed shall have an overview help topic describing the functions of the screen, screen components and display instructions.

4. TECHNICAL MANUAL: The vendor shall provide a technical manual.

4.1. All technical documentation source documents shall be generated in Microsoft® Visio 2000. All text-based documentation shall be generated with Microsoft® Word.

4.2. SYSTEM MODULE SECTION: A chart depicting system modules and how they relate to the system’s data structures and screens. The document can be a context diagram or a class hierarchy document.

4.3. SYSTEM FUNCTION FLOWCHART: A chart that depicts how user interacts with system function, and how it relates to data structures and screens.

4.4. APPLICATION SECURITY ACCESS CRITERIA: The vendor shall use Attachment Q – Security Access Criteria to document user security profiles and groups.

4.5. Backup Recommendation Plan

1 - 2


ATTACHMENT C – Cont.

4.6. NEW FEATURES IMPLEMENTATION PLAN: This document shall describe the steps to:

4.6.1. Implement new system screens or functions.

4.6.2. Rebuild the application in case of program corruption.

5. DATABASE DOCUMENTATION: The vendor shall generate the database documentation considered mandatory in the TxDOT Data Architecture document.

5.1. DATA DICTIONARY: The vendor shall provide a data dictionary generated from the data models.

5.2. LOGICAL DATA MODEL: The vendor shall provide an overall logical data model diagram and individual system module data model diagrams.

5.3. PHYSICAL DATA MODEL: The vendor shall provide an overall physical data model and individual system module data model diagrams.

6. SYSTEM DOCUMENTATION: The vendor shall generate the following system documentation for each screen, query, and report developed within the vendor written solution. The vendor shall use MNT internal documentation templates.

6.1. SCREEN SPECIFICATIONS: Each developed screen shall be documented with the MNT Screen Specification document.

6.2. QUERY SPECIFICATIONS: Each developed trigger or query shall be documented with the MNT Query Specification document.

6.3. REPORT SPECIFICATIONS: Each developed report shall be documented with the MNT Report Specifications document.

2 - 2


ATTACHMENT D

SYSTEM INTERFACE REQUIREMENTS

1. SCREEN DESIGN

1.1 COLORS: Application background color shall be white with dark blue lettering.

1.2 FONT: All applications screens shall use Arial font. Screen headings shall use point 12 and data fields shall use point 10.

1.3 RESOLUTION: All application screens shall be developed in 1024x768 screen resolution.

1.4 SCREEN CAPTION: The title bar of each application screen shall display the screen name and purpose such as Land Assets – Maintain Data.

1.5 LOOK AND FEEL: Application screens shall have an uncluttered look and feel. Application controls shall be equally sized, equally spaced and framed and sectioned into functional areas using box or framing controls.

1.6 APPLICATION CONTROLS

1.6.1 Control Alignment: Alphanumeric data shall be left aligned and numeric data shall be right aligned.

1.6.2 Control Tab Order: All application controls shall be ordered from top, down, left and right. Disabled or read-only controls shall not be in the tab order.

1.6.3 Editable Controls: Application controls that allow user editing shall be in the tab order, receive focus from user interaction, have a white background and dark blue lettering, using recessed controls and have access control shortcuts that are not duplicated on the screen.

1.6.4 Read-only Controls: Application controls that are used to display data and do not allow user interaction shall not be in the tab order, shall not receive focus from user interaction, have a flat look and formatted with a white background color and dark blue lettering.

1.6.5 Command Buttons: Application controls that the user interacts with to access a system function or perform a task.

1.6.5.1 Command buttons that access other screens that allow the user to change or edit data shall have a labeled followed by three dots such as “Open Building Records”.

1.6.5.2 Each screen shall have a command button that closes the screen and shall be set as the Cancel button of the screen.

1.6.6 Text Controls: Text edit controls shall allow multiple lines of data to be entered and display a vertical scroll bar.

1.6.7 List Controls: Application controls that display lists of data to select from shall be sorted alphabetically, by default display 8 list items and have a white background.

1 - 2


ATTACHMENT D – Cont.

2. APPLICATION SWITCHBOARD: The application switchboard shall be the primary navigation screen that allows the user to access all system functions. The screen prototype is depicted as Fig. 1 on Attachment W – System Prototype Figures.

2.1 Shall display the official TxDOT logo, a welcome prompt to the logged in user, the current date and time and current system version.

2.2 Shall contain menu system and command buttons to access system functions.

2.3 Shall be the primary application screen where all system functions are accessed.

2.4 Shall allow user so to choose how to navigate through the system.

2.5 The system shall support navigation through the use of graphical images and maps.

2.6 The system shall support navigation through menu systems and custom ad hoc query screens.

3. ONLINE HELP SYSTEM: The system shall implement an online help system typical of window based applications that can be accessed through the use of the menu system and accessed when the user presses the F1 key. Each screen developed shall have an overview help topic describing the functions of the screen, screen components and display instructions.

4. REPORT GUIDELINES

4.1 COLORS: All reports shall use black lettering unless report logic changes the coloring due to the business logic of the report.

4.2 FONT

4.2.1 First heading line shall be Arial point 14.

4.2.2 Second heading line shall be Arial point 12.

4.2.3 All other heading lines shall be Arial point 10.

4.2.4 Detail headings shall be Arial point 10 and formatted in bold.

4.2.5 Report data shall be Arial point 8.

4.3 Reports shall display the date and time report was generated.

4.4 Reports shall display report page numbers centered at the bottom of each page and displaying “Page x of x”.

4.5 All reports should have the option of being exported to spreadsheet and PDF formats.

2 - 2


ATTACHMENT E

SYSTEM CODING REQUIREMENTS

1. ERROR HANDLING: All program coding shall access a global error handling routine with a standard message.

2. GLOBAL SCOPE

2.1. All program global variables shall be declared within a global variable coding module.

2.2. All program global functions or sub procedures shall be declared and contained within a global coding module.

3. SOURCE CODE COMMENTS

3.1. VARIABLE AND CONSTANT DECLARATIONS: All variable declarations and constant declarations shall contain descriptive comments explaining their function, where they are implemented within the system and name of the system function and code that calls them.

3.2. CODING STATEMENTS: All coding statements shall contain descriptive comments explaining their functions, how they are called or implemented through the system and actors involved (user or system).

4. CODING MODULES

4.1. Shall be named to convey their purpose and location of action.

4.1.1. Coding modules that directly relate to a screen shall be named using the form name followed by a meaningful name such as frmAssetMaintenance_ViewMatchingBuildings.

4.1.2. Global coding modules shall be named with a “mod” prefix followed by a meaningful name that conveys the purpose of the module such as mod_UpdateExternalRecords.

4.2. Shall be named to convey their order of execution and purpose.

4.2.1. Order of Execution: The first portion of the name shall reflect its order of execution within the code execution.

4.2.2. Module Reference: The second portion of the name shall reflect the purpose of the sub procedure or function.

4.2.3. Code Description: The last portion of the name shall reflect the purpose of the coding statements.

4.2.4. The order of execution, module reference and code description shall be separated by underscores.

4.2.5. Example: Step01_modGenerateAssetReport_BuildTables

4.3. Shall implement For Loops instead of Do/While Loops.

4.4. Shall implement Case statements instead of multiple nested If Then Else statements.

4.5. GOTO statements are prohibited except for error handling.

1 - 2


ATTACHMENT E – Cont.

4.6. Shall implement input boxes to prompt users for information and shall convey simple instructions and have a clear and concise purpose. The input box shall ask for only one piece of data, be simplistic, not require lookup tables and display example data being requested.

5. EXAMPLES

5.1. GLOBAL ERROR ROUTINE

5.2. MODULE CODING

5.3. USER PROMPT

2 - 2


ATTACHMENT F

APPLICATION SWITCHBOARD REQUIREMENTS

1. SCOPE: Create new application switchboard that will serve as the primary navigation point for accessing all system data and functionality.

2. MAP NAVIGATION: The system shall allow users to locate system information using a series of image maps that creates an ad hoc query and allow access system functions. TxDOT will generate map images internally and submit to vendor for implementation into the vendor written solution.

3. MENU SYSTEM NAVIGATION: The system shall allow users to access all system functions through the custom menu system. The menu system shall be duplicated on all application screens.

4. QUICK JUMP NAVIGATION: The system shall allow users to access system functions through the use of hyperlink type navigation called “quick jumps”.

5. SCREEN DESIGN AND FUNCTIONALITY: The vendor shall participate in JAD work sessions to finalize the Application Switchboard design and system functions.

6. PROTOTYPE: Refer to Figure 1 on Attachment W – System Prototype Figures for the Application Switchboard prototype.

1 - 1


ATTACHMENT G

MANAGEMENT DASHBOARDS REQUIREMENTS

7. SCOPE: Create management dashboards to allow users to view summarized data and view related system functions. The vendor shall participate in JAD work sessions to finalize the required management dashboards, their design and system functions.

8. STATEWIDE ASSETS DASHBOARD: The dashboard shall summarize assets by occupancy type, total locations and GSF categories. The dashboard shall allow users to execute reports with “quick jumps”. JAD work sessions will be used to define the system reports and functions to be implemented on the dashboard.

9. FACILITY DASHBOARD: This dashboard shall summarize basic property information and allow access to facility system functions. Refer to Figure 2 on Attachment W – System Prototype Figures for the screen prototype.

10. BUILDING DASHBOARD: This dashboard shall summarize basic building information and allow access to building system functions.

11. REST AREA DASHBOARD: This dashboard shall summarize the Safety Rest Area program and allow access to rest area specific system functions.

12. ASBESTOS ABATEMENT DASHBOARD: This dashboard shall allow access to Asbestos Abatement related screens, system functions and display charts and reports described on Attachment K – Asbestos Abatement Requirements. Screen design elements will be determined as a result of JAD work sessions.

13. PROPOSED PROJECT DASHBOARD: This dashboard shall allow access to APRS related screens, system functions and reports described in Attachment M – APRS Requirements. Screen design elements will be determined as a result of JAD work sessions.

14. PROJECT DESIGN DASHBOARD: This dashboard shall allow access to CDMS screens, system functions and summarize current design project data as described on Attachment L – CDMS Requirements. Screen design elements will be determined as a result of JAD work sessions.

15. CONDITION ASSESSMENT DASHBOARD: This dashboard shall summarize ACA data, allow access to ACA screens and system functions as described in Attachment I – ACA Requirements. Screen design elements will be determined as a result of JAD work sessions.

16. REPORTING DASHBOARD: This dashboard shall allow access to standard reports and standard report ad hoc querying capabilities as described on Attachment N – Standard Reporting Requirements. The screen shall allow access to all the system’s reports.

17. PM DASHBOARD: This dashboard shall allow division users to access common applications, internet sites and business templates to efficiently perform their job duties. The current PM Dashboard consists of organized folders of shortcut icons. Screen design elements will be determined as a result of JAD work sessions.

1 - 1


ATTACHMENT H

AMRS REQUIREMENTS 18. SCOPE: Implement existing data structures and system functions and incorporate new data

structures for data summarization and reporting.

18.1. Data model and conversion of existing and new data structures into the vendor database solution.

Data

Tables Domain Lookup Tables

Common Application

Tables

Additional Tables

Required 9 12 2 6

18.2. Recreate application data entry screens and incorporate existing business functions to allow the Asset Management group to maintain and report AMRS data.

18.3. Recreate standard reports and create new reports implementing NET reporting technology. The standard reports are based on query structures, contain very little or no business logic and have simple filtering options through the use of input boxes.

18.4. Incorporate new functionality in the vendor written solution.

19. DEFINITIONS

19.1. AMRS: Asset Management & Reporting System – MNT internal database application system that tracks and reports all real property asset data.

19.2. GLO: General Land Office

19.3. GSF: Gross Square Footage

19.4. ROW: Right of Way

19.5. ROW ACRES: A unit of land measure positioned in the highway ROW.

19.6. VLM: Vehicle Lane Mile – internal ranking of facilities according to maintained vehicle lane miles.

19.7. COMMON APPLICATION TABLE: A table structure common to all modules of the system.

19.8. DATA TABLE: A table structure where system users maintain vital information.

19.9. DOMAIN LOOKUP TABLE: A table structure facilitates the selection of valid field values.

20. BUSINESS FUNCTION REQUIREMENTS

20.1. ASSET AD HOC FILTERING: The system shall allow the user to specify how to locate land and building records by incorporating the Asset Filtering Screen.

20.2. LAND ASSETS: The system shall allow the Asset Management personnel to do the following functions:

20.2.1. Maintain core land asset data.

1 - 3


ATTACHMENT H – Cont.

20.2.2. Maintain land appraisal data.

20.2.3. Maintain Land Deed Transaction data and determine the total acres, Highway ROW acres and Non-Highway ROW acres. This data is currently in spreadsheet format and will require a data structure.

20.2.4. Maintain GLO yearly recommendations. This will require a new table structure that shall include property identification number, recommendation year a recommendation comments.

20.2.5. Maintain disposed of land data in an archive table.

20.2.6. Maintain GLO Land utilization requirements.

20.2.7. Maintain and track multiple asset types for land records. This will require a new table structure that shall include the asset identification number, and asset type.

20.2.8. Maintain and display yearly Vehicle Lane Miles data. Current VLM data is stored in separate tables by years.

20.3. BUILDING ASSETS: The system shall allow the Asset Management personnel to do the following functions:

20.3.1. Maintain core building data.

20.3.2. Maintain building construction transaction data to track individual construction activities performed on the building.

20.3.3. Maintain and track multiple building usage types.

20.3.4. Maintain disposed building records in an archive table. This will require a new table structure.

20.4. NEW FUNCTIONALITY: The system shall incorporate the following new business functionality:

20.4.1. Create new data structure to calculate from a property condition scored from ACA data tables.

20.4.2. Create new data structure to calculate a building condition score from ACA data tables.

20.4.3. Display overall condition score data on core land and building screens.

20.4.4. Allow access to system Management Dashboards to access other asset related data.

20.5. REPORTS: The current automated system reporting is mainly executed through data mining and reporting to Microsoft® Excel. Current reports executed through AMRS are limited to several annual reports.

2 - 3


ATTACHMENT H – Cont.

20.5.1. Existing Reports

20.5.1.1. Annual GSF by District: A summary report that summarized gross square footage of buildings by district and statewide total.

20.5.1.2. Antiquities Report: A photograph report that displays buildings that turned xx in the current fiscal year.

20.5.1.3. Surplus Listing: A listing of land assets marked as surplus.

20.5.2. The vendor project team shall participate with TxDOT in JAD work sessions to develop asset-related reports.

3 - 3


ATTACHMENT I

ACA REQUIREMENTS 21. SCOPE: Implement existing data structures and system functions and incorporate new data structures for data

summarization and reporting into the vendor written solution.

21.1. Modify existing data model and conversion of existing and new data structures into the vendor database solution.

Data

Tables Domain Lookup Tables

Common Application

Tables

Additional Tables

Required 58 88 2 2

21.2. Recreate application data entry screens and incorporate business functions to allow the Asset Management group to maintain and report ACA data. The current automated system has about 58 entry screens.

21.3. Create new reports implementing .NET reporting technology. The automated system does not have any reports.

21.4. Incorporate new functionality into the vendor written solution.

22. DEFINITIONS

22.1. ACA: Asset Condition Assessment – MNT internal asset condition assessment application system that is used to track asset inventory details, observed defects and photographs, building perspective photographs, building elevation photographs.




23. BACKGROUND: The existing ACA automated system is a data collection system developed to facilitate data collection of asset condition assessment data. The data collection process will begin in April 2006 and end August 31, 2007. Each property location will have its own database and be returned by the vendor to TxDOT. The returned databases will need to be combined back into the ACA database. The automated system was developed in October 2005 and was developed using ISD Data Architecture guidelines, however, it will require some minor changes. It is estimated it to be about 85-90 percent in compliance.

24. EXISTING BUSINESS FUNCTIONS

24.1. Tracks property inspection data for each property asset.

24.1.1. Access gates

24.1.2. ADA Accessible Route

24.1.3. Excess Water Runoff

24.1.4. Fuel Tanks

24.1.5. Irrigation System

1 - 2


ATTACHMENT I – Cont.

24.1.6. Perimeter Fence

24.1.7. Utility Service

24.1.8. Vehicle Pavement

24.2. Tracks building inspection data for each building asset.

24.2.1. Electrical Systems

24.2.2. Mechanical Cooling Systems

24.2.3. Mechanical Heating System

24.2.4. Mechanical Air Conditioning & Ventilation Systems

24.2.5. Mechanical Dual Systems

24.2.6. Exterior Walls & Windows

24.2.7. Roofs

24.2.8. Foundation

24.2.9. Plumbing Heaters

24.2.10. Plumbing Lift Station

24.2.11. Fire Protection

24.2.12. Emergency Generators

24.2.13. Security Systems

24.2.14. Interiors

25. NEW FUNCTIONALITY

25.1. ACA database will need remodeling of primary keys to support the storing of the statewide inspection data. There will be 305 separate ACA databases that will need to be combined into one comprehensive ACA database.

25.2. CALCULATE PROPERTY CONDITION SCORE: The vendor shall participate in JAD work sessions to develop and implement the property condition score function.

25.3. CALCULATE BUILDING CONDITION SCORE: The vendor shall participate in JAD work sessions to develop and implement the building condition score function.

25.4. Yearly Score Update: The vendor shall participate in JAD work sessions to develop and implement a function to yearly update overall building and property conditions scores.

25.5. ASSET CONDITION DASHBOARD: The vendor shall participate in JAD work sessions to develop and implement the Asset Condition Dashboard that will summarize condition data by district and statewide.

25.6. REPORTS: The vendor shall participate in JAD work sessions to develop and implement condition assessment reports, or charts, or both.

2 - 2


ATTACHMENT J

SPACE UTILIZATION REQUIREMENTS 26. SCOPE: Implement existing data and business functions and incorporate new data structures for

data summarization and reporting into the vendor written solution.

26.1. Data model and conversion of existing data structures into the vendor SQL Server 2000 database solution.

Data Tables

Domain Lookup Tables

Common Application

Tables

Additional Tables

Required 2 1 0 2

26.2. Recreate entry screens and business functions to allow the Asset Management group to maintain and report data.

26.3. Recreate standard reports implementing NET reporting technology. The standard reports are based on query structures, have very little or no business logic coding and have simple filtering options through the use of input boxes.

26.4. Incorporate new functionality into the vendor solution.

27. DEFINITIONS




28. DATA RESTRUCTURING: The existing data structures do not allow for storage of multiple years of data. The location of the building floor plan is stored in another data structure. Also, TxDOT has collected gross square footage data that needs to be implemented into the space utilization component.

28.1. SPACE UTILIZATION BY FLOOR

28.1.1. Restructure main space utilization table to include a year field and set table keys to year, building and floor number.

28.1.2. Restructure the space utilization table to include a building plan location field. This will combine the existing building floor plan and office space tables.

28.2. SPACE UTILIZATION BY BUILDING: Incorporate the tracking of overall space utilization. The current system stores the overall space utilization information in the building record.

28.3. BUILDING GSF: Incorporate the GSF breakdown data into the space utilization module.

1 - 2


ATTACHMENT J – Cont.

29. BUSINESS FUNCTIONS

29.1. TRACK SPACE UTILIZATION

29.1.1. Summarize by Year: The system shall track space utilization by year allowing multiple years of data to be maintained and summarized.

29.1.2. Summarize by Floor: The system shall track space utilization by floor number.

29.1.3. Summarize by Building: The system shall track overall space utilization for each building.

29.2. TRACK GSF BREAKDOWN: The system shall allow for multiple years of GSF breakdown data.

29.3. DISPLAY BUILDING SPACE UTILIZATION SUMMARY: The system shall display GSF and Space Utilization information summarized for each building, refer to figure XX on Attachment W – System Prototype Figures.

29.4. REPORTS: The vendor shall participate in JAD work sessions to develop and implement space utilization reports, or charts, or both.

2 - 2


ATTACHMENT K

ASBESTOS ABATEMENT REQUIREMENTS 30. SCOPE: Implement existing data structures and business functions and incorporate new business

functionality into the vendor written solution. 30.1. Data model and conversion of existing data structures into the vendor SQL Server 2000

database solution.

Data Tables


Common Application

Tables

Additional Tables

Required 5 5 0 To be determined

30.2. Recreate entry screens and incorporate existing business functions to allow the Asbestos Abatement manager to maintain and report data.

30.3. Recreate standard reports implementing .NET reporting technology. The standard reports are based on query structures, have very little or no business logic coding and have simple filtering options through the use of input boxes.


31. DEFINITIONS

31.1. ASBESTOS ABATEMENT: Procedures to control fiber release from asbestos-containing materials in a building or to remove them entirely, including removal, encapsulation, repair, enclosure, encasement, and operations and maintenance programs.

31.2. ACM: Asbestos containing material.




32. DATA RESTRUCTURING: The existing data contains redundant information and needs to be data modeled according to the TxDOT Data Architecture document.

32.1. ASBESTOS ASSESSMENTS: This data structure contains the original 1993 asbestos assessment data including unit costs for abatement.

32.1.1. This table needs to be restructured to allow multiple years of assessments to be stored.

32.1.2. The abatement costs data should be external to the table since costs will change by year.

32.1.3. Develop an assessment identification number; the current table is composed of a 3 column composite key.

32.2. ASBESTOS LABORATORY SAMPLE ANALYSIS: This data structure contains laboratory results of each sample taken during the asbestos assessment. It has redundant or repeating fields from the Asbestos Abatement table.

1 - 2


ATTACHMENT K – Cont.

32.2.1. Implement the asbestos abatement identification field into this table.

32.2.2. Develop an asbestos laboratory sample identification number to uniquely identify the record.

32.3. ASBESTOS ABATEMENT TRANSACTION: This data structure contains duplicate data from the Asbestos Abatement table.

32.3.1. It needs to be normalized to only include abatement transactions.

32.3.2. It should be able to calculate abatement costs for the year the abatement was performed.

32.3.3. Develop an abatement transaction number; the current table has a composite key.

32.4. ASBESTOS ABATEMENT UNIT COST: This table structure is not normalized containing 1993 and 2000 data in separate columns.

32.4.1. It needs to be normalized according to the TxDOT Data Architecture document.

32.4.2. Shall store unit cost by year and be used to calculate abatement costs in the Asbestos Abatement Transaction table.

33. EXISTING BUSINESS FUNCTIONS

33.1. TRACK ASBESTOS ASSESSMENTS: The system shall track asbestos assessments for each building by assessment date.

33.2. TRACK ASBESTOS LABORATORY SAMPLES: The system shall track asbestos assessment laboratory sample results by assessment identification number and test date.

33.3. TRACK ASBESTOS ABATEMENT TRANSACTIONS: The system shall track asbestos abatement transactions including abatement details, remaining abatement units and costs involved. These data items are currently implemented in the Asbestos Abatement Transaction table.

33.4. TRACK ASBESTOS ABATEMENT SITE PLANS: The system shall track the physical file location of multiple site plans for each building relating to an asbestos assessment record.


34.1. MAINTAIN UNIT COST DATA: The system shall maintain unit costs by year.

34.2. TRACK COST DATA: The system shall track estimated repair costs and abatement costs.

35. REPORTING: The vendor shall participate in JAD work sessions to develop and implement asbestos abatement related reports and charts.

36. ASBESTOS ABATEMENT DASHBOARD: The vendor shall participate in JAD work sessions to develop and implement the Asbestos Abatement Dashboard.

2 - 2


ATTACHMENT L

CDMS REQUIREMENTS 37. SCOPE: Implement existing data structures and business functions and incorporate new business

functions into the vendor written solution. 37.1. Data model and conversion of existing data structures into the vendor SQL Server 2000

database solution.

Data Tables


Common Application

Tables

Externally Linked Table

3 0 4 1

37.2. Implement existing business functionality as described in Para. 3.

37.3. Recreate standard reports implementing .NET reporting technology. Standard reports are based on query structures, have very little or no business logic coding and have simple filtering options through the use of input boxes. Refer to Para. 3.3 for standard reports.


38. DEFINITIONS

38.1. CDMS: CAD Document Management System – MNT internal database application that is used to track internal project design requests, create project folders implementing a standard file structure and allow ad hoc searching of project folders.




39. EXISITING BUSINESS FUNCTIONS

39.1. RECORD MAINTENANCE: The system shall allow the system administrator(s) to create, modify and delete project request records. Non administrative users shall have the read-only access to project request data.

39.2. MAINTAIN PROJECT FOLDER FILE STRUCTURE: The system shall allow the system administrator(s) to add, modify and delete File Structure records.

39.3. CREATE PROJECT FOLDER: The system shall allow the system administrator(s) to create a project design folder in the division design area using project request information and File Structure table.

39.4. TRACK NETWORK RIGHTS: The system shall allow the system administrator(s) to track individual staff members that have full rights to the project folder.

39.5. VIEW PROJECT REQUEST RECORDS: The system shall allow users to view all project request data without the ability to add, modify or delete data.

1 - 2


ATTACHMENT L – Cont.

39.6. SIMPLE PROJECT QUERY: The system shall allow for simple querying from the menu system to display completed request records, incomplete request records and all request records.


40.1. AD HOC PROJECT QUERY: The system shall allow the user to create a custom ad hoc query to locate request records by selecting data fields, selecting how to match values and select data values from the Request table. Refer to Fig. 2 on Attachment W – System Prototype Figures.

40.1.1. Full Details Function: User shall have the option to see full details that displays the Project Request Screen.

40.1.2. Summary Details Function: User shall have the option to view summary details of matching projects displayed in a table format below the ad hoc query selection area.

40.1.3. User shall have the ability to view full details of the project request record.

40.1.3.1. User shall have the ability to view the project folder of the project request record.

40.1.3.2. User shall have the option to download matching project requests to a spreadsheet in the “download” directory.

40.2. REPORTING

40.2.1. Generate Project Listing: The system shall users to generate a project listing report using simple filtering through use of standard input boxes.

40.2.2. Generate Access Rights Summary Report: The system shall allow users to generate a report that displays for each user the projects they have been assigned full rights to.

2 - 2


ATTACHMENT M

APRS REQUIREMENTS 41. SCOPE: Implement existing data structures and business functions and incorporate new business

functions into the vendor written solution. 41.1. Data model and conversion of existing data structures into the vendor SQL Server 2000

database solution.

Data Tables


Common Application

Tables

Externally Linked Table

3 0 4 1

41.2. Recreate entry screens and business functions to allow the Facilities Management Budget group to maintain and report APRS data.

41.3. Recreate standard reports implementing NET reporting technology. The standard reports are based on query structures, have very little or no business logic coding and have simple filtering options through the use of input boxes.

42. DEFINITIONS

42.1. DIVISION CIP SUBMITTAL: The business process involves combining imported DDO project requests and internal budgeting data to determine which projects are approved for funding. Selected project request records are promoted to “division approved” with an indicator field in the Project Request table. Standard reports are used to build the report.

42.2. ADMINISTRATION CIP SUBMITTAL: The business process where division approved project request records are promoted to “administration” approved with an indicator field in the Project Request table. Standard reports are used to build the report.

42.3. DDO: District/Division/Special Office

43. BUSINESS FUNCTIONS

43.1. IMPORT DDO PROJECT REQUESTS: The system shall automate the importation of individual DDO Access databases that consists of project requests, project request asset records and project request photographs.

43.2. RECORD MAINTENANCE: The system shall allow users to input, modify and delete records.

43.3. REVIEW DDO PROJECT REQUESTS: The system shall users to generate a variety of standard reports that incorporate project request data and division data to facilitate the division approval process.

43.4. DIVISION CIP SUBMITTAL: The system shall allow the users to build the Division CIP Submittal Report which is a bound book that is submitted to TxDOT Administration for approval to submit to the Legislature.

43.5. ADMINISTRATION CIP SUBMITTAL: The system shall allow users to build the Administration CIP Report that includes project requests that have been approved by TxDOT Administration.

1 - 2


ATTACHMENT M – Cont.

43.6. LEGISLATIVE REPORT: The system shall allow users to build the Legislative CIP Report includes project request records that were approved as part of the Capital Improvement Program budget the upcoming biennium.

43.7. CREATE CIP PROJECTS: The system shall create project and detail charge numbers in a financial database (remain in Access, not part of this integration project). Legislative approved projects will become official project and detail charge numbers but are placed in a “proposed” status in the financial database.

44. REPORTS: The application consists of 38 standard reports that shall be recreated in the vendor written solution.

2 - 2


ATTACHMENT N

STANDARD REPORTING & AD HOC QUERY REQUIREMENTS

45. SCOPE: The vendor written solution shall incorporate:

45.1. A Standard Reporting Module that allows users to access all system reports, access standard reports and filter reports with ad hoc querying capabilities.

45.2. An Ad Hoc Query Module that allows users to locate database information using ad hoc querying capabilities.

46. JAD WORK SESSIONS: The vendor shall participate in JAD work sessions to develop and implement all technical aspects of the Standard Reporting Module.

47. REPORTING

47.1. STANDARD REPORTS SCREEN: The Standard Reporting Screen shall display all system reports grouped into functional areas of AMRS, ACA, APRS, CDMS, Space Utilization and Asbestos Abatement. Reports accessed from this area shall not have filtering capability.

47.2. FILTERED REPORTS SCREEN: The Filtered Report Screen shall allow users to select a standard report and construct a filter using ad hoc querying capabilities. Refer to Fig. 5 on Attachment W – System Prototype Figures for the initial prototype.

48. AD HOC QUERY FUNCTION: The vendor written solution shall incorporate a database information ad hoc querying function that allows users to locate data by performing ad hoc query sessions. The system shall encompass a querying screen to locate data from AMRS, ACA, APRS, CDMS, Space Utilization and Asbestos Abatement modules.

48.1. The results from the filtering process shall be displayed in a table format.

48.2. The user shall have the ability to download results from the filtering process to a Microsoft® Excel spreadsheet in the application download folder.

48.3. The user shall have the ability to view all the records resulting from the filter process on the appropriate data screen.

48.4. The user shall have the ability to view a selected record resulting from the filter process on the appropriate data screen.

1 - 1


ATTACHMENT O

BUSINESS DOCUMENT SEARCH REQUIREMENTS

49. SCOPE: The vendor written solution shall encompass a business document search function that will allow the user to search for specific types of business documents by specifying ad hoc selection criteria and display file locations of matching documents.

50. FILE STRUCTURE: MNT is currently developing and implementing a file structure to store business documents. The purpose of the new file structure is to implement an easy to use and intuitive file structure that describes the function and purpose of the business document. Refer to Fig. 6 on Attachment W – System Prototype figures for the preliminary file structure.

50.1. Store project photographs by project and year

50.2. Store asset condition photographs by asset and year

50.3. Store asset panoramic photographs by asset and year

50.4. Store asset facility aerial maps and facility location maps by asset

50.5. Store archived design files by asset, year, description and project

50.6. Store scanned land deed information

50.7. Store historical reports

50.8. Store site visit photographs

51. REQUIREMENTS

51.1. The vendor shall participate in JAD work sessions to develop and implement technical aspects of this search feature. The types of available searches will be developed during this work session.

51.2. Shall display matching folder locations in a table format allowing users to export results to a Microsoft Excel spread and save to the application download folder.

51.3. Shall use the standard operating system’s Window Explorer to display selected business documents.

1 - 1


ATTACHMENT P

FACILITY AERIAL MAP REQUIREMENTS

52. SCOPE: The vendor shall produce facility aerial maps using Google Earth or a similar technology for each property location.

53. REQUIREMENTS

53.1. Specify TxDOT building numbers for each building structure

53.2. Specify the latitude and longitude coordinates for the N.E. corner of the property using State Plane coordinates

53.3. Include typical map objects include scale legend and direction legend

53.4. Include the Property name and number

53.5. Specify border line denoting the property boundaries

53.6. Specify major highway names

53.7. Shall be jpg or tiff format

53.8. Resolution requirements shall be:

53.8.1. Jpg, jpeg or tiff format

53.8.2. Maximum resolution of 2100 pixels x 1600 pixels

53.8.3. Minimum of 300 dpi

53.8.4. Photograph shall not be fuzzy, dark or otherwise defective in producing a clear view of the subject matter

53.8.5. Photographs shall not exceed 2MB

54. PROTOTYPE: Refer to Fig. 7 on Attachment W – System Prototype Figures.

1 - 1


ATTACHMENT Q

SYSTEM ACCESS SECURITY CRITERIA – CLIENT SERVER APPLICATION Integrated Facilities Management System (IFMS) OPR: Maintenance Division (MNT)

User Type Job Name and Typical User Description

Database Role

Application Role Capabilities Constraints, Exceptions, and

Requirements

OPR designee - Original April 4, 2006 1 of 4

(MNT) Facilities Mgt. Section Asset Management Users Any MNT user needing access to IFMS application and database to support the Asset Management job functions.

MNT_USER_role

Asset group

Overview: Maintain Asset Management data Specification: Read access to all IFMS database non-AMRS tables and views. Update and Delete rights Application tables used for

summaries and reports AMRS Tables

Execute rights for stored procedures and functions

Constraint: MNT personnel only Exception: None Requirement: IFMS application

Network access to IFMS

Documents Area TxDOT network access

SQL Server access

General

(MNT) Facilities Mgt. Section Asbestos Management Users Any MNT user needing access to IFMS application & database to support the Asbestos Abatement job functions.

MNT_USER_role

Asbestos group

Overview: Maintain Asbestos Abatement data Specification: Read access to all IFMS database non-Asbestos Abatement tables and views. Update and Delete rights Application tables used for

summaries and reports Asbestos Abatement Tables





SQL Server access


ATTACHMENT Q



Database Role


Requirements


(MNT) Budgeting Users Any MNT user needing access to IFMS application & database to support the Biennial Budgeting job functions.

MNT_USER_role

Budgeting group

Overview: Maintain biennial budget project requests data Specification: Read access to all IFMS database non-APRS tables and views. Update and Delete rights Application tables used for

summaries and reports APRS Tables





SQL Server access

(MNT) Facilities Mgt. Section CAD Design Users Any MNT user needing access to IFMS application & database to support the CDMS job functions.

MNT_USER_role

CAD Design group

Overview: Maintain CDMS data Specification: Read access to all IFMS database non-CDMS tables and views. Update and Delete rights Application tables used for

summaries and reports CDMS Tables





SQL Server access


ATTACHMENT Q



Database Role


Requirements

(MNT) Division Users TxDOT employees with safety, human resources or management role, with job duties requiring access to OCC claims information.

Not Applicable

Division user group

Overview: Read access to data tables and domain tables Specification: Read access to all IFMS database tables and views. Update and Delete rights Application tables used for

summaries and reports Execute rights for stored procedures and functions




SQL Server access

Administrative

Administrator MNT personnel responsible for administering the IFMS application

MNT_USER_role

Admin group

Overview: Full access to all functions and data. Specification: Full access to all functions

and data.

MNT personnel only Exception: None Requirement: IFMS application



SQL Server access



ATTACHMENT Q



Database Role


Requirements

Technical Support

Support Personnel responsible for technical support of the application and/or the database

db_ddladmin

Admin Group

Overview: Update access Specification: Full support for IFMS application and database (without ability to assign security roles)

Constraint: MNT technical support person Exception: None Requirement:

IFMS application TxDOT network access VB.Net SQL Server access

User Support

MNT User Support MNT personnel responsible for supporting the IFMS application users

MNT_USER_role

Admin Group

Overview: Update access Specification: On-Line read access to all

tables and views in IFMS database


Update rights for all IFMS files

Constraint: MNT user support person Exception: None Requirement:

IFMS application Network access to IFMS

Documents Area TxDOT network access SQL Server access

Audit User

NA

NA

NA

NA

NA

Approved by: _____________________ ________________ Date



ATTACHMENT R

EXISTING DATA STRUCTURES 1. DATA STRUCTURE SUMMARY: ACA data is about 85-90% compliant to TxDOT Data Architecture

System Development Component

Data Tables

Common Tables

Domain Tables

New Tables

External Linked Tables

AMRS 9 2 12 0 0 ACA 58 0 88 2 0 Facility Space Utilization

2 1 0 2 0

Asbestos Abatement 5 0 5 0 0 CDMS 3 4 0 0 1 APRS 5 4 3 0 4 Totals 82 11 108 4 5

2. DATA STRUCTURE BREAKDOWN

Data Table System Component Table Type District County AMRS Common

Facility GLO Facility Utilization GLO Land Utilization Land Land Disposal Vehicle Lane Mile Ranking

AMRS Data

B_Table Builidng Class Building Type GLO Facility Utilization Code GLO Historical Markers GLO Land Utilization Code GLO LT Appraisal Method GSC Facility Condition Code GSC Facility Construction Code Land Apprasial Type Land Usage Type

AMRS Domain

Facility Archive Facility Construction Transaction GLO Recommendation Land Archive Land Deed Transaction Land Usage

AMRS New

1 - 5


Data Table System Component Table Type Bldg_Elec_Distrb_Wire Bldg_Elec_Distrb_Wire_Dfct Bldg_Elec_Intr_Lght Bldg_Elec_Panl Bldg_Elec_Panl_Dfct Bldg_Elec_Trnsfrmr Bldg_Elvatr Bldg_Emrgncy_Gnrtr Bldg_Emrgncy_Gnrtr_Dfct Bldg_Extr_Wall Bldg_Extr_Wall_Dfct Bldg_Extr_Wndw Bldg_Extr_Wndw_Dfct Bldg_Fire_Prot Bldg_Fire_Prot_Dfct Bldg_Fndtn Bldg_Fndtn_Dfct Bldg_Intr_Finish Bldg_Intr_Finish_Dfct Bldg_Low_Slp_Roof Bldg_Mechnl_Air_Distrb_Dctwrk Bldg_Mechnl_Air_Distrb_Fan Bldg_Mechnl_Air_Hndlr_Dfct Bldg_Mechnl_Air_Hndlr_Unit Bldg_Mechnl_Boiler Bldg_Mechnl_Boiler_Dfct Bldg_Mechnl_Chll_Wtr_Cool Bldg_Mechnl_Chll_Wtr_Cool_Dfct Bldg_Mechnl_Cool_Twr Bldg_Mechnl_Cool_Twr_Dfct Bldg_Mechnl_Evap_Cool Bldg_Mechnl_Evap_Cool_Dfct Bldg_Mechnl_Pckg_Unit Bldg_Mechnl_Pckg_Unit_Dfct Bldg_Mechnl_Pump Bldg_Mechnl_Pump_Dfct Bldg_Mechnl_Spc_Heat Bldg_Mechnl_Spc_Heat_Dfct Bldg_Mechnl_Splt_Sys Bldg_Mechnl_Splt_Sys_Dfct Bldg_Mechnl_Wndw_Thruwall_Unit Bldg_Mechnl_Wndw_Thruwall_Unit_Dfct Bldg_Plmb_Heat Bldg_Plmb_Lift_Statn Bldg_Plmb_Lift_Statn_Dfct Bldg_Roof_Dfct Bldg_Roof_Eqpmt Bldg_Scrty_Sys Bldg_Steep_Slp_Roof

ACA DATA

2 - 5


Data Table System Component Table Type Photo Prop_Aces_Gate Prop_ADA_Acesible_Rte Prop_Excss_Wtr_Runoff Prop_Fuel_Tank Prop_Irrig_Sys Prop_Perim_Fnc Prop_Util_Srvc Prop_Veh_Pvmt

ACA DATA

Bldg_Clss_C_Rating Bldg_Elec_Distrb_Wire_Cnduit_Cond Bldg_Elec_Distrb_Wire_Dfct_Cond_Score Bldg_Elec_Distrb_Wire_Type Bldg_Elec_Intr_Lght_Type Bldg_Elec_Panl_AMPS Bldg_Elec_Panl_Cnts Bldg_Elec_Panl_Dfct_Age Bldg_Elec_Panl_Phs Bldg_Elec_Panl_VOLTS Bldg_Elec_Trnsfrmr_Mount_Type Bldg_Elec_Trnsfrmr_Owner Bldg_Elec_Trnsfrmr_Type Bldg_Elvatr_MF Bldg_Elvatr_Type Bldg_Emrgncy_Gnrtr_Bckup_Lght_Type Bldg_Emrgncy_Gnrtr_Fuel_Type Bldg_Emrgncy_Gnrtr_Test_Frqncy_Type Bldg_Extr_Wall_Dfct_Score Bldg_Extr_Wall_Type Bldg_Extr_Wndw_Type Bldg_Fire_Prot_Sprnklr_Cvrg_Area Bldg_Fndtn_Basemt_Type Bldg_Fndtn_Crwlspc_Type Bldg_Fndtn_Type Bldg_Intr_Finish_Dfct_Score Bldg_Low_Slp_Roof_Flash_Base Bldg_Low_Slp_Roof_Membrn Bldg_Low_Slp_Roof_Membrn_Srfc Bldg_Low_Slp_Roof_Parpt_Flash_Base Bldg_Low_Slp_Roof_Prime_Drn Bldg_Low_Slp_Roof_Scnd_Drn Bldg_Low_Slp_Roof_Slp_Type Bldg_Mechnl_Air_Distrb_Fan_Type Bldg_Mechnl_Air_Distrb_MS Bldg_Mechnl_Air_Hndlr_Heat_Src Bldg_Mechnl_Boiler_Enrgy_Src Bldg_Mechnl_Boiler_Type Bldg_Mechnl_Cool_Twr_Air_Spply_Type Bldg_Mechnl_Cool_Twr_Basn_Mtrl Bldg_Mechnl_Cool_Twr_MF

ACA DOMAIN

3 - 5


Data Table System Component Table Type

Bldg_Mechnl_Cool_Twr_Mtrl Bldg_Mechnl_Cool_Twr_Wtr_Trtmnt Bldg_Mechnl_Dfct_Age Bldg_Mechnl_Dfct_Cond_Score Bldg_Mechnl_Dual_Sys_Cmpnt_Type Bldg_Mechnl_Dual_Sys_Eqpmt_Type Bldg_Mechnl_Exhst_Dctwrk_Mtrl Bldg_Mechnl_Heat_Rjctn Bldg_Mechnl_Heat_Src Bldg_Mechnl_Mount_Type Bldg_Mechnl_Outsd_Air_Dctwrk_Mtrl Bldg_Mechnl_Pckg_MF Bldg_Mechnl_Pump_Dfct_Age Bldg_Mechnl_Pump_MS Bldg_Mechnl_Pump_Type Bldg_Mechnl_Refrgnt_Type Bldg_Mechnl_Rtrn_Air_Dctwrk_Mtrl Bldg_Mechnl_Spc_Heat_Enrgy_Src Bldg_Mechnl_Spc_Heat_Type Bldg_Mechnl_Splt_Sys_Dfct_Age Bldg_Mechnl_Spply_Air_Dctwrk_Mtrl Bldg_Mechnl_Wndw_Thruwall_Heat_Src Bldg_Mechnl_Wndw_Thruwall_Unit_Type Bldg_Plmb_Dfct_Age Bldg_Plmb_Dfct_Age_Dfct Bldg_Plmb_Heat_Capac_Unit Bldg_Plmb_Heat_Dfct Bldg_Plmb_Heat_Enrgy_Src Bldg_Plmb_Heat_Type Bldg_Roof_Dfct_Score Bldg_Scrty_Sys_Type Bldg_Steep_Slp_Roof_Drn_Type Bldg_Steep_Slp_Roof_Mtrl_Type Bldg_Steep_Slp_Roof_Slp_Type Bldg_Steep_Slp_Roof_Ventln_Type Prop_Aces_Gate_Type Prop_ADA_Acesible_Rte_Type Prop_Excss_Wtr_Drn_Type Prop_Excss_Wtr_Dschrg_Type Prop_Fuel_Tank_Cnts Prop_Fuel_Tank_Locn Prop_Fuel_Tank_Rplc_Dt_Type Prop_Fuel_Tank_Type Prop_Irrig_Sys_Type Prop_Veh_Pvmt_Type Prop_Wstwtr_Srvc_Type Prop_Wtr_Srvc_Type

ACA DOMAIN

Property Condition Score Building Condition Score

ACA NEW

4 - 5


Data Table System Component Table Type Building Space Utilization by Floor Building Floor Plan

SPACE UTILIZATION DATA

Building Floor Plan Type SPACE UTILIZATION DOMAIN

Building Space Utilization Building GSF

SPACE UTILIZATION NEW

Asbestos Abatement Transactions (asb2000) Asbestos Assessments Asbestos Assessment Lab Analysis Asbestos Siteplans Asbestos Unit Cost

ASBESTOS ABATEMENT DATA

Asbestos Actions Asbestos Damage Asbestos Site Plan Type Unit Cost Material Category

ASBESTOS ABATEMENT DOMAIN

Users District Counties Programs

CDMS COMMON

Project Request File Rights File Structure

CDMS DATA

Detail Charge Table from FPTS CDMS EXTERNAL LINK

Facility Type District County Facility

APRS COMMON

Project Request Project Request – Assets Project Request – BRB Project Request – Financing Details Project Request Photographs

APRS DATA

Project Types FM Budget Project Types System Reports

APRS DOMAIN

LAR Projects LBB Category Detail Charge Numbers LBB Expense Code

APRS EXTERNAL LINK

5 - 5


ATTACHMENT S MONTHLY STATUS REVIEW

PROJECT NAME: PROJECT DESCRIPTION: REPORTING PERIOD: VENDOR POINT OF CONTACT: OVERALL PROJECT STATUS COMMENTS:

ISSUE STATUS:

ACCOMPLISHMENTS DURING THIS REPORTING PERIOD:

PLANNED TASKS FOR NEXT REPORTING PERIOD:

TASK COMPLETION THIS REPORTING PERIOD:

Phase

Milestone

Percentage Completed

Anticipated Completion

Actual Completion

Status

1 - 1


ATTACHMENT T WEEKLY PROGRESS CHECK REPORT

PROJECT NAME: PROJECT DESCRIPTION: REPORTING PERIOD: VENDOR POINT OF CONTACT: OVERALL REVIEW OF WEEKLY PROGRESS:

ISSUE STATUS:

ACCOMPLISHMENTS DURING THIS REPORTING PERIOD:

PLANNED TASKS FOR NEXT WEEK PERIOD:

TASK COMPLETION THIS REPORTING PERIOD:

Phase

Milestone

Percentage Completed

Anticipated Completion

Actual Completion

Status

1 - 1


ATTACHMENT U

DELIVERABLE TESTING PLAN

PURCHASE ORDER: TESTING DATE: VENDOR PARTICIPANT: TESTING ACTIVITY NUMBER: TEST DESCRIPTION:

TEST OBJECTIVE:

TESTING TYPE DATABASE DEVELOPMENT GUI INTERFACE SYSTEM DEV. TESTING DATABASE DEVELOPMENT TEST CRITERIA CRITERIA COMMENTS

Logical Model in compliance Physical Model in compliance Data entity and attribute names use standard wording guidelines Database documentation approved Overall compliance of TxDOT Data Architecture document

GUI INTERFACE TEST CRITERIA CRITERIA COMMENTS

Compliance of MNT Interface Guidelines Can user navigate unassisted through interface screens Interface components (menus, toolbars, screen instructions and

labeling) functional

Interface components (menus, toolbars, screen instructions and labeling) error free

Interface components (menus, toolbars, screen instructions and labeling) easily understood

Screen Specification Document approved User Manual updated

SYSTEM FUNCTION TEST CRITERIA CRITERIA COMMENTS

Compliance of MNT Programming Guidelines Compliant Error handling Error-free data handling and processing Error free system calculations & processing Interfaces with other system functions System code documented in-line Function Process Document

TEST RESULT: APPROVED DELIVERABLE TEST INCIDENT REPORT REQUIRED OVERALL COMMENTS

DELIVERABLE TEST INCIDENT REPORT

OBSERVED BY:

1 - 2


IMPACT

MINOR MODERATE SIGNIFICANT

SYSTEM FUNCTION NAME:

SYSTEM FUNCTION PURPOSE:

INPUTS:

EXPECTED RESULTS:

ACTUAL RESULTS:

PROBLEM DEFINITION:

PROCEDURAL STEP:

PROBLEM RESOLUTION:

ESTIMATED RESOLUTION IN TERMS OF PROGRAMMING EFFORT (HOURS:MINUTES)

2 - 2

TEXAS DEPARTMENT OF TRANSPORTATION GENERAL...

Documents

Transcript of TEXAS DEPARTMENT OF TRANSPORTATION GENERAL...