PROJECT APPROACH DOCUMENT - ProMilesproto.promiles.com/TxPROSRepository/files/txpros/PAD/Master_v2.0... · JAD Session Guidelines ... the Project Approach Document and described as

PROJECT APPROACH DOCUMENT

Texas Department of Transportation Motor Carrier Division (MCD)

Texas Permit Routing Optimization System

TxPROS

Version: 2.0 Revision Date: 06/28/2010

TxDOT Motor Carrier Division Project Approach Document TxPROS Project Version 2.0 June 28, 2010

Page 2

Contents Introduction......................................................................................................................... 3 Deliverable.......................................................................................................................... 3 Overview............................................................................................................................. 3 Successive Refinement Approach....................................................................................... 4 Rapid Application Development......................................................................................... 5 WBS, WBS Dictionary, and RAM ..................................................................................... 6 Meeting Guidelines............................................................................................................. 7 JAD Session Guidelines...................................................................................................... 8 Project Management Plan ................................................................................................. 10 Risk Management Plan ..................................................................................................... 10 Deliverables and Acceptance Testing............................................................................... 11 Deliverable Review Process ............................................................................................. 12

Review: ......................................................................................................................... 12 Disposition: ................................................................................................................... 12 Signoff: ......................................................................................................................... 12

Payment Process ............................................................................................................... 13 Authorizing Payment: ................................................................................................... 13 Processing Payment: ..................................................................................................... 13 Payment: ....................................................................................................................... 13

Project Changes ................................................................................................................ 14 Requests for Information .................................................................................................. 15 Issue and Defect Tracking ................................................................................................ 15 Reporting........................................................................................................................... 20 Prototype Environment ..................................................................................................... 21 TxPROS Pre-Production Software Release Process......................................................... 23 Limits of Authority ........................................................................................................... 24 Escalation Process............................................................................................................. 25 Revision History ............................................................................................................... 26


Page 3

Introduction This Project Approach Document (PAD) shall describe the methods and agreements ProMiles Software Development Corporation (PSDC) or (Vendor) and TxDOT will use and will have for the development of the TxPROS project.

Deliverable This document is the deliverable for item 1.1.1 of the TxPROS Statement of Work named the Project Approach Document and described as the document that identifies the agreements between Vendor and TxDOT on how the project will be approached and managed from the selection and utilization of resources through planning, designing, development and testing to training, marketing and implementation. It serves as a compliment to the project’s PMP and clarifies items in the RFO and RFO response. Limits of authority, as concerns decision-making on the part of team members, PMT Sponsor, Project Board and IRC, will also be addressed. Included will be the tracking and response process to project status, issues and defects (problem tracking) items as well as review and approval processes.

Overview Vendor and TxDOT agree that for most work on the TxPROS project they shall use the Successive Refinement Approach (SRA) and the Rapid Application Development (RAD) method. For those parts of the TxPROS project for which these methods are not appropriate, such facts shall be duly noted and agreed upon in writing by both parties and recorded in the project website. The SRA and the RAD are defined in the following sections. The Work Breakdown Structure (WBS), Work Breakdown Structure Dictionary (WBS Dictionary), and the Responsibility Assignment Matrix (RAM) will play key roles in the SRA process. The WBS and WBS Dictionary will be used to define successive refinements of the project’s tasks. Design Documents (DD), as described in the SOW, will be used to define the software developed for this project. These DD will be written after the JAD sessions based on information obtained from these sessions, the RFO, and the response to the RFO. These DD will define the software at appropriate levels based on the RAD method. As the software is refined using feedback from users, the DD will be updated to reflect new information and the changes suggested by the RAD process. By the end of the project, the information from the DD will be used to develop the Technical Documentation as described in the SOW.


Page 4

Development Plans, as described in the SOW, will be used to facilitate management of the project. These Plans will be created after the DD are written and will be used to develop the WBS and WBS Dictionary that will be used to monitor progress on the project. The TxPROS project will use a Pilot Area for implementing the GIS data. The PMT will identify this Pilot Area. After PSDC has successfully implemented the GIS data in this Pilot Area, and the TxDOT PMT has signed off on this, PSDC will implement the GIS data statewide. The Deliverables for these activities are described in the SOW. The implementation of the Pilot Area is an example of the use of the RAD method. It is further agreed by the Vendor and TxDOT that project documentation shall have a key role in the development of the project and that such documentation shall be used, in addition to the actual deliveries, to judge the success of the project and for payment purposes. Key documents for the TxPROS project include the Project Management Plan, the Communication Management Plan, and the Risk Management Plan. TxDOT will maintain these documents using input from Vendor as described below and in the RFO and Response. It is agreed that these documents will be added to and changed through out the project to reflect the current status of the project. It is also understood and agreed that this document shall be a working document subject to change as the work continues on the TxPROS project and as new methods and agreements are developed for Vendor and TxDOT to use while working together to complete the project.

Successive Refinement Approach The Successive Refinement Approach shall be used for most aspects of this project. Using this approach, Vendor will take the project tasks as listed in the SOW and the PMP and refine these tasks into smaller tasks until each task is described at an appropriate level for implementation. The subdividing of the tasks will follow analysis by Vendor and TxDOT and will take into account all information known at that time about the project and the task in question. It is expected that as each task is analyzed, the appropriate subtasks will become better know. Once a task has been divided appropriately for implementation, Vendor and TxDOT will assign the task to the appropriate personnel using the RAM and the WBS and then track progress on each individual subtask. Preliminary dates for task work and completion shall also be recorded at this time. The breakdown of tasks and subtasks shall be recorded in the WBS and WBS Dictionary. This process shall be continued until the project is completed and is signed off on.


Page 5

Rapid Application Development The Rapid Application Development (RAD) method shall be used for the development of the software for the TxPROS project. The RAD is a modern system development process in which prototype software is rapidly developed and then tested by the system users. As the users test the system, they work in concert with the developers to refine the system. When used successfully this system allows for the rapid development of highly user-friendly software. By testing the system as it is developed, the project managers can insure that initial faults in the design of the system can be rapidly identified and changed before the project reaches a point where such changes are difficult and time consuming. The RAD method is especially well suited to projects with extensive user interfaces and that are groundbreaking. The TxPROS project meets both of these requirements. RAD projects must be well managed or projects can suffer from several problems including creeping featurism, excessive delays, and failure to meet the original requirements. The TxPROS PMT is tasked with insuring that the project does not suffer from these problems and that the project respects the Milestone requirements laid out in the contract. The users testing the project will include MCD users, Vendor users, and where appropriate, industry users.


Page 6

WBS, WBS Dictionary, and RAM The WBS and WBS Dictionary shall be used to define the tasks of the project. The RAM shall be used to assign responsibilities from the WBS to the various entities and persons within the Vendor and TxDOT organizations. These documents shall start with the WBS and WBS Dictionary provided with the PMP and the SOW and shall be expanded using the SRA method described above. As additional information is learned about the various tasks described in earlier versions of the WBS and WBS Dictionary, these tasks will be more fully refined in later versions of these documents. Vendor and TxDOT agree that the various tasks will be fully described, to an appropriate level of detail, within the WBS. In addition to defining each task, the WBS will also be used for planning by including detailed time estimates for each task. The WBS will also be used to identify dependencies between tasks, and it will be used for scheduling and to determine critical paths within the project timeline. Vendor agrees that it is its responsibility to produce the WBS, WBS Dictionary, and the associated RAM for each stage of the project. TxDOT will review the submitted documents and work with Vendor to resolve differences. Vendor and TxDOT agree to use the Escalation Process as described in the Communication Management Plan in the event of differences within these documents. In addition, the risk for each item listed in the WBS will be reviewed and documented in the Risk Management Plan. Once Vendor has assigned a resource to a task in the WBS, it will record what resource was assigned to that task in the WBS and the Vendor will record anticipated and actual start times for that task. The WBS and WBS Dictionary will contain the following information: - WBS Element Number - WBS Element Name or Title - Dictionary Description

o High-level (n.n.n) or Intermediate-level (n.n.n.n) WBS will provide descriptions for Phase/task Level Elements (reference the SOW)

o Detailed-level (n.n.n.n.n….) WBS will provide descriptions for Task Level Elements. (reference the SOW)

- Deliverables (where appropriate) - Responsibility

o High-level (n.n.n) or Intermediate-level (n.n.n.n) WBS will provide general description (team/team leader)

o Detailed-level (n.n.n.n….) WBS will provide specific description (individual) for Task Level Elements. (reference the SOW)


Page 7

Meeting Guidelines The following Meeting Guidelines will be used as much as is possible during the TxPROS project to help ensure that the meetings held for this project are both productive and efficient. The person calling for the meeting shall be the meeting owner and is responsible for all meeting details. The Project Coordinator (PC) will be available to assist with meeting coordination and can send out electronic appointment to invitees. Non-emergency, special meetings shall be, when possible, scheduled at least 10 working days in advance. The meeting owner, or other designated person, shall create an agenda which shall be distributed to all invitees at least 5 working days in advance of the meeting and shall include the following:

• Meeting Date • Meeting Location • Meeting Start/Stop time • Meeting Purpose • Agenda Items:

o Time (duration) o Purpose o Responsibilities o Desired Outcome/Action

• Scheduled Attendees • Assigned Scribe

Meeting invitations, with agenda attached, should explain to each attendee that if the attendee does not feel they are the appropriate person for the meeting, they are asked to either delegate attendance to the meeting to the appropriate person or to advise the TxPROS PC of this fact. The attendees shall also be asked that if they feel additional individuals should be invited, they should advise the PC of this fact. A current copy of the Agenda Template, entitled TxPROS Standard Agenda Template shall be available at the Project Repository. Each meeting shall be followed by the distribution of the meeting notes to all attendees. Additionally, a copy of the meeting notes shall be given to the PC to be placed in the Project Repository. Project members can also call emergency meetings. These meetings should be, when possible, limited to 3 topics and every effort made to limit the time to 1 hour.


Page 8

Routine PMT meetings shall generally be held once a week. These meetings will be done via teleconference and shall be scheduled to be held on each Tuesday at 9:00AM central time. Agendas for these meetings are due the preceding Monday. Periodically the PMT may decide to conduct these meeting face to face at MCD Headquarters as team building opportunities. TxPROS PMT Milestone meetings will be scheduled at or about the completion of each TxPROS Milestone and shall be held at MCD Headquarters.

JAD Session Guidelines JAD sessions are a key part of the Joint Application Design/Development process. In order to insure the effectiveness of these sessions, the following guidelines will be followed as much as possible. For all JAD sessions the TxPROS PMT will meet to determine the subject matter to cover, the attendees necessary to provide the information and answers to the subject matter, and the time needed to cover such material. The TxDOT PMT will then create a detailed agenda with all of the items described in the previous meeting section. JAD session agendas shall be distributed to all invitees at least 5 working days in advance of the meetings. The TxDOT PMT shall be responsible to advise each attendee of materials and information they are expected to bring with them to the meetings. Follows is a template for the JAD session agenda:


Page 9

JAD sessions will be a scheduled, somewhat formal, workshop designed to create a predefined set of answers based on the session agenda. The moderators will make all due efforts to insure that the meeting largely follows the agenda, covers all subjects on the agenda, yet allows all attendees to have their voices heard. If the conversation of the meeting diverges significantly from the agenda, and the subject of the conversation is deemed important, that subject shall be placed in a ‘parking lot’ to be discussed at a later time. The moderators shall also insure, as much as is reasonably feasible, that the goals of the session, as described in the session agenda, are met. Such goals can include items such as decisions made, information shared, designs made or needs identified. Comprehensive notes shall be taken by the vendor Documentation Manager of each session to be edited into JAD session notes and summaries. The notes shall be recorded and distributed as described in the previous section. JAD session summaries are formal summaries made for the session using the following format: Summary area Description Session name, date, and location Table of participants Includes name, interest area, and role Discussion topics To be obtained from the agenda Consensus items A list of items, decisions, information, etc that were

formally agreed upon during the meeting Related items, yet to be resolved A list of items discussed, decisions made, or

information shared for which there was no formal agreement on resolution

Items identified for future sessions or parking lot

A list of subjects or items for which a decision was made that the subject should be discussed in a later session or moved to the parking lot

Lessons Learned A list of lessons learned from the session It is agreed that the Deliverables for any Milestone involving JAD sessions will include detailed notes for the repository for each such session along with the formal JAD session summaries. Detailed information for all JAD sessions can be found in the JAD Schedule and Personnel Assignments Document.


Page 10

Project Management Plan The Project Management Plan (PMP) will be the master control document for TxPROS. Vendor and TxDOT agree this document will be maintained throughout the project and in particular it shall be updated after the completion of each phase. Vendor and TxDOT agree that Vendor will provide TxDOT input on each of the activities involved with each phase. TxDOT agrees that they shall perform all needed updates based upon Vendor’s input and on other factors as TxDOT sees fit. TxDOT also agrees to provide Vendor with assistance and guidance on information that needs to be recorded in the PMP. Vendor will have access to the PMP at all times during the project. The following documents and reports shall be used as sources for the PMP updates and each of these documents shall be incorporated into the Project Repository for reference:

• SOW • WBS • WBS Dictionary • RAM • Risk Management Plan • Project Changes • Issue and Defect reports • Work-in-Progress reports • Completed Deliverables reports also known as the Deliverables Index • Communication Management Plan • Configuration Management Plan • Performance Plan

Risk Management Plan Vendor and TxDOT agree that the Risk Management Plan (RMP) is an essential tool for the management of the TxPROS project. Vendor and TxDOT agree that maintenance of this document throughout the project is essential. Vendor agrees to assist TxDOT in the identification and assessment of each risk for the project. Vendor agrees to use the methods and activities described in Section 2.2 of the RMP to monitor and analyze the various risks to the TxPROS project. Vendor further agrees to help provide the Risk Response Actions for each of these risks as described in section 2.3 of the RMP. Vendor and TxDOT will work together on assessing each risk item, and Vendor and TxDOT further agree that TxDOT shall maintain the Risk Management Plan with the above-described input from Vendor.


Page 11

Deliverables and Acceptance Testing Acceptance testing of all deliverables is necessary for completion of all milestones and for payment. Acceptance testing shall be performed by TxDOT for each deliverable. PSDC shall submit a Deliverable Submission Document to TxDOT upon its completion of each deliverable. This document will include the following information:

• Date • Name of the Deliverable and SOW# • Description of the Deliverable (program, document, etc) • Objective of the Deliverable • Where or how to access the Deliverable • Deliverable Test Plan

The Name of the Deliverable will be the name as used in the SOW or in the WBS. The Description of the Deliverable will be a written description of what the deliverable is: i.e. plan, document, program, program component, or other. The Objective of the Deliverable will be a written description of what the deliverable is intended to do or perform for the project. This description will include what the deliverable is expected to provide to the project. Also included will be a description of how the deliverable fits within the project and will include a list of other project components the deliverable will directly and indirectly interact with. It is agreed that when any document changes are submitted within a deliverable, changed items will be highlighted in blue while new items will be highlighted in yellow to readily identify new topics or areas of change. The Deliverable Test Plan will describe methods to test the performance of the deliverable. If the deliverable is a program or interface component, the Test Plan will include a detailed checklist that can be used to test compliance. In these cases, the Test Plan will also include any scaffolding needed to perform the tests. If the deliverable is a document or plan, the test plan will include a description of what the document or plan needs to describe, how the document or plan should describe that, and a consideration of who the intended audience will be. If applicable, the Test Plan should have a checklist of objectives for the document or plan that can be verified. It is agreed that not all deliverables, due to their nature, need to or can have a test plan. The acceptance criteria of Section 5.4 of the PMP shall be the determining factor on whether or not a test plan is required for a deliverable. It is also agreed that Vendor will provide TxDOT with a Test Plan for all deliverables that need one and that TxDOT will be free to modify such Test Plans as it sees fit. Vendor agrees that a deliverable that requires a test plan is not considered submitted until the accompanying Test Plan is also delivered.


Page 12

For each deliverable, TxDOT will create and use a test document or plan to test said deliverable. TxDOT will be free to use the Test plan created by Vendor for such deliverable or to create their own test plan. After TxDOT has signed off on a deliverable, that fact will be noted in the Project Tracking tool, and TxDOT will record this fact in the WBS and the Project Status Report. TxDOT will create and use a Deliverable Signoff Document to communicate successful sign off on all deliverables both to Vendor and to the TxPROS management team. Except as is described in the Time of Payment section of the BAFO, a deliverable will not be accepted by TxDOT until the test plan for the deliverable has been executed and it is satisfactorily validated that the deliverable has successfully passed all requirements on the test plan.

Deliverable Review Process For each deliverable, vendor will submit the deliverable, associated deliverable Test Plan (if applicable), and the Deliverables Submission Document to the TxPROS Contract Manager with a copy to the TxPROS Project Coordinator and the Contract Administrator or to as many of these positions that are filled at that time. These documents shall also be archived within the Project Repository. The TxDOT TxPROS Project Management Team shall approve the deliverables using the following steps: Review: The TxPROS Business Project Manager (BPM) directs the TxPROS Project Management Team (PMT) and/or project members in the testing (if applicable), validation and review of the deliverables. Testing and review results are submitted to the BPM. Disposition: The BPM, Technical Project Manager (TPM) and PC review the results and agree on disposition for each deliverable. Should deliverables require rework prior to signoff; the TxPROS PMT will discuss each deliverable and the necessary revisions and determine next steps. The Contract Administrator completes a Deliverables Signoff Document. The Deliverables Signoff Document is routed to the BPM, TPM and/or Project Sponsor for review and signature. Signoff: The Deliverables Signoff Document must receive signature from the BPM and TPM before distribution. In the event that either or both are unavailable to review and provide signature, the Project Sponsor may review and sign. The Contract Administrator formally distributes the completed Deliverables Signoff Document to the TxPROS PMT.


Page 13

Payment Process Vendor may request payment for a completed Milestone by submitting the invoice, along with all supporting documentation (email, Deliverables Signoff Documents, etc.) indicating deliverable’s acceptance, as instructed in the TxDOT Purchase Order. Vendor shall submit invoice via email to the TxPROS Contract Manager with a copy going to the TxPROS Project Coordinator and Contract Administrator.* Invoice amount submitted for each Milestone will equal the corresponding “Payment %” from the TxPROS Payment Schedule applied against the balance of the total from line 1 of the Purchase Order less the cost of the TeleAtlas data ($1,434,900 - $188,900 = $1,246,000). The TeleAtlas data will be invoiced for and paid in conjunction with Milestone 5 as identified in the TxPROS Payment Schedule. * On 1/9/09, the TxPROS MCD PMT learned that FIN contacted vendor directly and requested they submit a copy of the invoice to FIN when submitting the invoice to MCD for approval. *On 5/25/10 POCN Rev#6 was issued changing the scope of the project to include permitting. With this change came additional Milestones and a change to the dollar amount of the contract. The new line item 1 amount is $1,654,700. Payments from Milestone 9b going forward have designated dollar amounts assigned. The annual maintenance amount increased from $125,000 to $146,500. The TxDOT TxPROS Project Management Team shall authorize the payment using the following steps: Authorizing Payment: Invoice and documentation received is reviewed by the Business Project Manager and Technical Project Manager. Request for payment must receive approval from both individuals in order to be processed for payment. In the event that either or both are unavailable to review and authorize, the Project Sponsor may review and authorize payment. The Contract Administrator completes a letter of authorization for payment. Processing Payment: Once payment is authorized, the Contract Administrator forwards the invoice, documentation and letter of authorization for payment to the Project Coordinator. The Project Coordinator records status for the project records and provides all documentation to the Motor Carrier Division purchaser for beginning the payment process. Payment: Payment request is forwarded by the Motor Carrier Division purchaser to the TxDOT Finance Division for processing, and payment is disbursed according to the TxDOT Terms & Conditions.


Page 14

Project Changes Vendor and TxDOT agree that a project of the scale of TxPROS cannot be completely and accurately scoped out before work commences. Vendor and TxDOT further agree that changes in the project will happen due to unforeseen developments and problems and those changes will also happen as additional information is discovered during the project. Because of these items, Vendor and TxDOT agree to the formal Project Change Procedure as outlined in section 4.1 of the PMP and section 1 of the Configuration Management Plan. Vendor and TxDOT agree that a project change can be initiated by either party. In order to initiate a Project Change the requesting party shall complete a Project Change Request form and submit the form to the other party. This Project Change Request shall include at the minimum the following information:

• Name of the request • List of deliverables or other aspects of the project that the change shall affect • A description of the change • A rationale for the change • Requestors initial assessment of the effect to the project the change will have

including but not limited to the following items: o Project schedule o Project functionality o Project costs

• Initial analysis of the effects to the project if the change is not accepted All change requests will be submitted to the Project Coordinator on the standard Change Request form available from the Project Repository. Change requests will be handled according to the Change Request Process identified in Section 4 of the PMP. After a Change Request has been accepted, it will be documented and any changes needed for the WBS, WBS Dictionary, RAM, or any other TxPROS document recorded.


Page 15

Requests for Information Vendor and TxDOT agree that Vendor will need information from TxDOT and possibly other Texas State Agencies. In order to obtain said information, Vendor will present a Request for Information (RFI) form to TxDOT. This RFI will detail the information requested, and if necessary the reason for the request. TxDOT agrees to provide requested information in a timely manner. Vendor agrees to treat all information obtained this way, unless otherwise directed, as confidential. All RFIs and their responses will be maintained in the project website. All RFI documents, including the requests and all responses as well as follow up requests, will be funneled through the Project Coordinator who will direct the document to the appropriate resource or resources and who will also ensure that the required responses are received for each document.

Issue and Defect Tracking Vendor agrees to provide and maintain a web-based Issue and Defect Tracking application for the development of the TxPROS project. Vendor will provide TxDOT with access to this application. This application will be separated into 2 categories: Defects and Issues. A Defect is defined as an error or bug in one of the deliverables. An Issue will be defined as a problem in the project that needs attention and resolution. Issues will be defined as Risks that are known events or have a probability of 95% or greater. Examples of Defect would include bugs or other errors in programs, grammatical or spelling errors in documents, cases where program functionality did not meet design specifications, or documentation that did not track with program functionality. Both Vendor and TxDOT will be able to add Defects and Issues to the Defect and Issue tracking application. This application will allow for authorized users to enter a description and severity level for each of the Defects and Issues. The severity level shall be established using the information is Section 2.2 of the RMP. The application will include the capability to upload text and images/screen shots to help identify the Defect or Issue. In the event that the item is a Defect, sufficient information shall be added to allow Vendor and TxDOT personnel to identify and reproduce, where possible, the Defect. Vendor programmers, writers, and other personnel will be able to add notes to each Defect or Issue. TxDOT reserves the right to determine that a Defect or Issue has been resolved. Vendor and TxDOT agree to use the Escalation Process as described in the document in the event of differences between the determination of the resolution of a Defect or Issue. It is agreed that the Issue and Defect Tracking application will automatically notify the poster and the receiver of the defect each time notes or information are added to the defect or issue or upon resolution of the defect or issue. It is further agreed that this tool shall have the capability to automatically escalate defects or


Page 16

issues and to notify TxPROS Project Management personnel via email at such time. The time period for such automatic escalation shall be configurable. The URL for the Issue and Defect Track application is: http://proto.promiles.com/TxPROSHelpDesk/logon.asp The following list describes the steps for submitting and tracking the process of resolution of the issues and defects. Note: The QA coordinator is the person assigned, as of the writing of this section of this document, to monitoring of the Issue and Defect Tracking application.

1. The user identifies an issue, defect, or possible enhancement (referred to as an issue in this document) and enters it into the help desk with the problem scope and category they believe it has. The initial status is “Open” and assigned to the QA coordinator.

2. The QA coordinator will review the issue. If he has any problems with the issue he will contact the user. If the issue has been identified as an enhancement, The QA coordinator will do the following: The QA coordinator will consult with the developer and if he and the developer feel the request is reasonable, not likely to have significant repercussions, and to take no more than 2 hours to implement, he will assign it to the developer for implementation and set the status to Open in Progress. If any of these criteria are not met, the request will stay as an enhancement and the status set to “Deferred to PMT”. The QA coordinator will present the information from the developer at the next PMT and the status determined. Any other issues, regardless of the category, that the QA coordinator has question or needs direction on will also be assigned the status of “Deferred to PMT”.

3. When The QA coordinator submits the issue to the developers, he will assign it a status of “Open – In Progress”, and will follow up with the developer until the issue is resolved and ready to test.

4. If it is determined that the issue refers to a future Milestone and is a longer term project, the status will be “Open-On Hold” and a projection date given. Work will continue on the issue, but the fix is not due until a later date.

5. If the developer has significant problems or concerns with the issue, he will assign it to “Open – Questions for QA” with notes to The QA coordinator of the problems he or she is having. Those issues will be communicated to The Vendor Project Manager and then on to the PMT and the status once again set to “Defer to PMT” if needed or “Open – In Progress” if sent back to the developer with more explanation.

6. Once the developer believes he or she has fixed the issue, he will change the status to “Open – In QA” and will post the fix to the test system.


Page 17

7. The QA coordinator will review the issue, test the fix, and if he believes it has

been addressed, he will change the status to “Complete – Ready to Test” for TxDOT to verify the fix addresses the issue submitted. If the issue is not fixed, he will send it back to the programmer and the status once again will be Open-in Progress. Once ready to test, The QA coordinator will assign the issue to the user to test.

8. TxDOT will review the issue and if it accepts the fix, it will change the status to “Complete – Pending Upcoming Release”.

9. If TxDOT does not accept the fix, it will change the status to “Open-Return to PSDC” and it is again assigned to the QA coordinator. The QA coordinator will further test the issue and send back in to development as “Open-In Progress if needed, or return to the user with an explanation and set again to “Complete-Ready to Test”.

10. On a weekly basis, PSDC will post the updates from the test system to the production test system. The QA coordinator must make sure that everything in the test system has been approved before the new build is done. The QA coordinator will change the status of the issues for which the fixes have been moved to the production test system to “Closed”. In the solution box for the issue The QA coordinator will explain how the issue was resolved, and the issue will be considered retired.

The QA coordinator is the “keeper” of the Issue and Defect Tracking application for TxPROS. He will review and track the progress of all issues entered. He will also make sure that the notes and statuses are current and that the notes and solutions provided are complete and comprehensive and also make sure that all PSDC users of this application understand the processes and procedures. The QA coordinator will make sure all items are tested before sending to TxDOT to review. Lastly, The QA coordinator will confirm all fixes are in the next build and set those statuses as closed.


Page 18

List of Statuses, who gets that notification, and the action associated: Step Status Goes to Action 1 Open The QA coordinator Evaluate and Assign 2 Defer to PMT Documentation Manager Discuss at next PMT 3 Open in Progress Programmer Assigned by QA Evaluate and Fix 4 Open on Hold Programmer Assigned by QA Evaluate and Fix 5 Open Questions for QA The QA coordinator Further research and

send back to PMT or back to Programmer with answers

6 Open in QA The QA coordinator Programmer sends to The QA coordinator to test the fix before sending to the user

7 Complete Ready to Test User TxDOT user that submitted the issue will test to verify issue is addressed

8 Open Return to PSDC The QA coordinator Reevaluate the issue, user not satisfied with the fix

9 Complete Pending Upcoming Release

The QA coordinator Post in the next build

10 Closed User The QA coordinator provides the solution and the user is notified the issue is closed.


Page 19

User enters issue assigns status: Open

QA Reviews

issue

If Enhancement

Submit issue to developer, status: Open – In Progress

Set status: Defer to PMT

Contact developer.Identify time

requirements and repercussions

If over 2 hours or repercussions

Not over 2 hours

Contact user

If problem with submission

Developer has problems with issue

Current Milestone

Set status: Open – on hold

Future milestone

Set status: Open – Questions for QA

Yes

Tim & Brian review issue

Set status: Defer to PMT

Not resolve problem

Resolve problem

Developer fixes issue sets status: Open – In QA

QA reviews fix

Sets status: Complete – Ready to Test

Fixed

Not Fixed

TxDOT reviews fix

Set status: Complete – Pending Upcoming Release

Accepted

No

Set status: Open - Return to PSDC

Not Accepted

PSDC posts fix to production systems. Set status: Closed

Follows is a flow chart of the Bug/Issue submission/review process:


Page 20

Reporting Vendor and TxDOT agree that the reporting process plays a key roll in the success of the TxPROS project. It is agreed that the Vendor will provide weekly status reports to the TxPROS Management Team. The TxPROS Management Team will then use these reports and the various other types of information available to it (such as Issue/Defect Tracking Application and the Project Status Application), to produce the status reports required for the TxPROS project. The reports Vendor will provide to the TxDOT Management Team will include the following elements: Report name Description Work-In-Progress The Work-in-Progress report will list progress in the

last week (or other appropriate time period) on each task in which work is currently progressing. The Work-in-Progress report will also include any known delays, any early or late starts, and any early or late finishes. Work-in-progress reports will be delivered to the MCD PMT as minutes following PMT meetings on the weeks when such meetings are held and will be delivered as a status report to the MCD PMT on weeks in which such meetings are not held.

Issue and Defect Reports Issue and Defect Reports will be generated out of the TxPROS bug tracking tool on a weekly basis or as needed. This report will list all open and resolved issues and defects along with statistic on such issues.

Completed Delivery Report The Completed Delivery Report is a WBS report containing all deliverables that will be maintained by PSDC and can be produced on an as-needed basis. This report will include the start date, completion date, and percent complete for each WBS item.


Page 21

Prototype Environment In order to facilitate the development of the TxPROS system, PSDC will maintain a prototype environment and a test environment for this project. This prototype environment will be used to facilitate large scale testing of the site by MCD and the industry. In order to insure effective utilization of this environment, this prototype environment will adhere to the following guidelines:

• The environment will have sufficient resources to allow usage by as many as 20 simultaneous users.

• The environment will be, as much as is feasible, active 24 hours a day, 7 days a week except when notified of down time or during scheduled updates.

• The environment will have the latest version of the software that has been accepted by MCD.

• PSDC will follow the update process described below. Follows is the process for posting fixes and updates to the two environments:

• PSDC developers will post fixes and updates to the test environment. • PSDC QA personnel will test these fixes and updates and if accepted they will

sign off on said fixes and updates and notify MCD personnel. • MCD personnel will verify such fixes and updates and if accepted they will sign

off on such fixes and updates. • On a scheduled basis, generally once a week, PSDC will move the software from

the test environment to the prototype environment using the following process:


Page 22

Flow chart of the process for moving the test environment into the prototype environment:


Page 23

TxPROS Pre-Production Software Release Process New Software Build Release for Restriction Manager: • Email containing the following:

a. To: Lois Johnson b. CC: Jesse Kirk c. Subject: Title of software, build/release number and date build was created if

different from build/release number (eg. Restriction Manager v. x.xx created mm/dd/yy).

d. Body of email: Include information on the specific map version and database build version that is used by this new build.

e. Body of email: Include any information regarding special directives for this build (such as requiring connection to a newly updated database) and any IT infrastructure changes necessary before the build can be implemented (such as server IP changes to the firewall rule, version of desktop Oracle client, etc.)

f. Body of email: Include any information regarding what was identified in unit testing OR verification that unit testing has been completed by PSDC and no user interface issues were detected.

g. Body of email: Include contact information of the support person at PSDC to call if there are questions from TxDOT regarding the installation.

h. Body of email: Identify the URL of the new build and the URL of the previous build (in case we need to revert to an earlier version). Include any specific steps we need to follow for reverting to an earlier version (i.e. uninstall entire application, remove via add/delete program, etc.).

i. Attachments: Include a document (release notes) detailing the updates made to the application. This should contain detailed info about each update, information about how the user interface behaves differently because of each update, how to use all new functionality (if applicable) and the associated help desk ticket number for each update (if applicable).

New Release for Routing or Reporting Web Sites: • Email containing the following (NOTE: this email should be sent 3 business days

before a new release is implemented): a. To: Kristy Schultz b. CC: Lois Johnson; Jesse Kirk c. Subject: Title of software, version number, creation date and date to be

implemented (eg. Routing v. x.xx, created mm/dd/yy, to be implemented mm/dd/yy).

d. Body of email: Include information on the specific map version (if applicable) and database version that is used by this new release.

e. Body of email: Include information regarding special directives for this release (such as requiring connection to a newly updated database), estimated down time expected for the implementation and any IT infrastructure changes necessary before implementation (such as server IP changes to the firewall rule, etc.)


Page 24

f. Body of email: Include information regarding what was identified in unit testing OR verification that unit testing has been completed by PSDC and no user interface issues were detected.

g. Body of email: Include contact information of the support person at PSDC to call if there are questions from TxDOT regarding the new release, to arrange a different implementation date or to arrange to revert to a previous version if problems are discovered in the new version.

h. Attachments: Include a document (release notes) detailing the updates made to the application. This should contain detailed info about each update, information about how the user interface behaves differently because of each update, how to use all new functionality (if applicable) and the associated help desk ticket number for each update (if applicable).

New Database Version: • Email containing the following (NOTE: this email should be sent 5 business days

before a new version is implemented): a. To: Lois Johnson b. CC: Jesse Kirk c. Subject: Database name, version number, creation date and date it will be

implemented (eg. GIS database v. x.xx, created mm/dd/yy, to be implemented mm/dd/yy).

d. Body of email: Include names of all TxPROS applications that will be impacted and provide related specific instructions for preparation for this implementation.

e. Body of email: Include information regarding special directives for this version, estimated down time expected for the implementation and any IT infrastructure changes necessary before the build can be implemented.

f. Body of email: Include verification that unit testing has been completed by PSDC and no database issues or application connection issues were detected.

g. Body of email: Include contact information of the support person at PSDC to call if there are questions from TxDOT regarding the new database or to arrange a different implementation date.

Attachments: Include a document (release notes) detailing the updates made to the database. This should contain detailed info for new tables/fields/entities added/removed/changed, information about how the user applications may behave differently based on these updates, and the associated help desk ticket number for each update (if applicable), and the updated DBDD and model.

Limits of Authority All limits of authority with regards to Change Requests, Risk Management Issues, Deliverable acceptance, Issue and Defect resolution and all other matters shall fall within the guidelines as described in the PMP.


Page 25

Escalation Process The following Escalation Process shall be used in the event of a disagreement between Vendor and TxPROS over any of the following items:

• Differences between the determination of the resolution of a defect or issue • Differences in a Change Request item (either the nature of the Change Request or

the acceptance or rejection of the request) • Instances of aging or other automatic escalations of defects or issues • Differences in a Work Item or a Risk Analysis • Other differences or disagreements

The Escalation Process consists of meetings between the following personnel to resolve the differences. At each step, if the personnel involved in the process at that time are not able to resolve the differences within a reasonable time, the differences will be escalated to the next higher group. The following are the groups of personnel who are involved:

1. TxPROS team members and Vendor team members 2. TxPROS project managers and Vendor project manager 3. TxPROS Project Management Team 4. TxPROS Executive Project Sponsor and Vendor senior management 5. TxPROS Board and Vendor senior management 6. TxPROS IRC and Vendor senior management 7. TxDOT senior managers and Vendor senior management 8. Contract claim

TxDOT and Vendor agree to use their best efforts and to work in good faith to resolve all issues without the necessity of a contract claim.


Page 26

Revision History

Version Date Name Description 0.1 9/4/2007 Tim Pilcher Initial draft released for TxDOT review

and approval. Needs additional information on the Limits of Authority.

0.2 10/1/2007 Tim Pilcher, Michelle Hudson

Update draft with feedback from Ray Hutchinson, Anna Hovenden, and Lois Johnson during a conference call on 9/24/2007. Additional updates from materials submitted by the above on 9/28/2007. Document reviewed and proofed by Michelle Hudson.

0.3 10/11/2007 10/22/2007

Lois Johnson, Ray Hutchinson

Updated draft with feedback discussed in 10/9/07 PMT conference call.

1.0 10/29/2007 Anna Hovenden Changed revision number and date to final status and posted to the project web.

1.1 12/30/2008 Michelle Hudson Addition of the description of the Issue and Defect Tracking application processes and work flows.

1.2 12/31/2008 Michelle Hudson Named individuals were removed from the Issue and Defect Tracking section and replaced with position titles per the PMT.

1.3 1/9/09 Anna Hovenden *On 1/9/09, the TxPROS MCD PMT learned that FIN contacted vendor directly and requested they submit a copy of the invoice to them when submitting the invoice to MCD for approval

1.4 2/26/09 Anna Hovenden Added “TxPROS Pre-Production Software Release Process”

1.5 6/28/10 Tim Pilcher, Michelle Hudson

Updated as part of MS9b to include RAD approach, JAD Sessions, Highlight change references, Contract amount changes, Reporting changes, the Prototype Environment, and validation that all references to the PAD in the Deliverables Dictionary are addressed.

1.6 6/28/2010 Michelle Hudson Resubmitted as part of MS9b with clarification to JAD Sessions statement.