Continuation of the Development and Financial … Report (Update sept 7... · Web viewThe BPWin...

Using the IDEF Model to Improve Business

Processes of the Transportation Agencies

Methodology for Transferring the Six-Year Improvement Program (SYIP) into the Statewide Transportation

Improvement Program (STIP) on the State Level: A continuation of the Development and Financial Constraint

of Virginia’s STIP

RACHEL K. JENNINGS

Graduate student

JAMES H. LAMBERT

Research Associate Professor

of Systems and Information Engineering

and Associate Director

Center for Risk Management of Engineering Systems

1

University of Virginia

2

ABSTRACT

The University of Virginia’s Systems and Information Engineering Department is

trying to expand the work done by Jennifer DeBruhl concerning the STIP Process

Development. The original document was created to show the transformation of the SYIP

into the STIP on the Federal level. We are trying to integrate into this Virginia’s process of

development of the STIP.

We are using a program created by Computer Associates called AllFusion, so that

the STIP Development Process is transformed from a data flow diagram into an IDEF0

(Integrated Definition for Function Modeling) diagram. The IDEF0 diagram allows us to

enter for each activity inputs, controls, mechanisms, and outputs. In order to gather

information for each activity, several interviews were conducted with VDOT employees

about their involvement with the STIP. Information from these interviews was transformed

into a worksheet that we were able to use to input information into the AllFusion model.

The purpose of this project is to gather a better understanding of the STIP and its

organization. Currently, VDOT employees have a difficult time explaining what other

divisions do for the STIP. We want VDOT and the public to understand how their

transportation projects are governed by the STIP and if their project is not in the STIP, it

will take months for it to be entered. The longest delay for the STIP is Air Quality Control.

The problem with this activity is that when a transportation project is modified in a slight

manner there is no current mechanism that lets the Environmental Division know that the

project they are working on to control emission levels is no longer valid. There needs to be

put into place a check system that once the project is modified, the Environmental Division

is immediately notified. In order for a project to start, the Air Quality Report must be

approved by the Federal government. If the project is not approved, then the project cannot

continue or start.

Another problem in the VDOT’s STIP development process is the lack of teamwork

in departments. There is a problem when departments are unwilling to share their work

with other departments. There needs to be put into place a check system that forces

departments to share their work.

3

INTRODUCTION

The University of Virginia’s Department of Systems and Information Engineering

has done research to support VDOT and VDRPT, and FHWA and FTA, in the process to

improve the Virginia Transportation Six-Year Program for Construction and Development

(SYIP) and the Statewide Transportation Improvement Program (STIP). This is a

continuation on the work performed by Jennifer DeBruhl, who wrote the Development and

Financial Constraint of Virginia’s STIP. Her work showed the federal level of

transforming the SYIP into the STIP. The University of Virginia is trying to add into this

document the state levels development of the STIP. Also, they are trying to transfer the

diagrams from being data flow diagrams into IDEF0 models. This will allow more

information, including inputs, controls, mechanisms, and outputs, into the model.

PROBLEM STATEMENT

In past years the STIP, a three-year programming document required by federal

regulations, was prepared by VDOT and VDRPT as an abridgment of the SYIP, which is

required by Virginia law. VDOT and VDRPT would in turn receive a joint letter from

FHWA and FTA giving federal approval of the Virginia STIP. Virginia's approach to the

STIP of past years has been inadequate to satisfy federal regulations, which require that

VDOT/VDRPT declare to FHWA and the FTA the federal dollars to be obligated in each

federal fiscal year by project. To be eligible for a federal obligation of funding, a project

needed to appear in each of the applicable (i) long-range plan, (ii) regional transportation

improvement program (TIP), and (iii) the Virginia STIP. In recent years, significant

projects appearing in the SYIP, and consequently in the STIP, could not be undertaken

because the financial constraint used in SYIP/STIP development was not meaningful. In

programming, objective and technical evidence were increasingly dominated by short-term

fiscal and other expediencies.

The FHWA, FTA, VDOT, and VDRPT reviewed the development process of the

Virginia STIP, with particular attention to the financial constraint specified by federal

regulation (23 CFR 450) (FHWA 2002). First, the review documented the processes

4

utilized to develop the Virginia SYIP and the Virginia STIP. Second, the review provided a

series of recommendations with accompanying implementation strategies in the categories

of timing, technology, format, financial, education, and process. The twenty-one

recommendations of the review are presented in Table 1.

While the 2002 report of FHWA et al. is definitive in characterizing the past and

future of the SYIP and STIP development processes, some additional background on the

research performed on this project is useful as follows.

The SYIP articulates an overall funding strategy for the Commonwealth. The SYIP

does not obligate federal funding. The SYIP reflects six-year funding and financing

strategies that are internal to the Commonwealth and which are typically not needed in the

federal oversight of the annual obligations of federal funds. In contrast, the STIP articulates

the intentions of VDOT and VDRPT to obligate federal funds to highways and transit by

federal fiscal year. The STIP document compiles project listings of the eleven MPO TIPs,

the SYIP, the federally funded Secondary System programs, federally funded forest

programs, and other participating programs. STIPs are required by federal regulations to be

submitted every two years, but the Virginia STIP has been submitted annually.

Currently, the TIPs are not generated in a common format, although some MPOs

use the relevant sections of the SYIP as their TIP. A particular challenge to harmonizing

the MPO TIPs is that the MPO that encompasses Northern Virginia (the Metropolitan

Washington Council of Governments) also encompasses parts of Maryland and the District

of Columbia.

Beginning with FY 03, the Virginia SYIP and the Virginia STIP are distinct

documents. A SYIP developed in an electronic environment will contain the data needed

for generation of the STIP. The Virginia STIP will no longer present the future allocation

of federal funds. For example, past STIP submissions represented an accrual of funds in

fiscal years, such as when $10 million is reserved in each of three years and associated to

an obligation of $30M in the 3rd year of the STIP. The STIP, a three-year program, is

amended multiple times between its biennial submissions/approvals. Amendments to the

STIP are straightforward when the amendment does not affect air quality. Thus,

amendments are typically neutral with respect to air quality, e.g., projects of alignments

and turning lanes. For FY 03, federal allocations that might have been available in 2002

5

were not ready until April 2003. Projects that had been removed in December 2002 due to

financial constraint were hurriedly resubmitted in 2003 to address the revised allocations.

The STIP of FY 03 (applicable through FY 04 and FY 05) was approved by FHWA and

FTA in recent months.

Current efforts of VDOT and VDRPT are addressing issues such as:

What is the best format for the compilation of the STIP, and its submission to

the FHWA and FTA, from the former SYIP, the Secondary System programs,

and the eleven MPO TIPs?

How can the STIP submission, which had been a stack of separate documents

in a variety of formats, be integrated and made available to the public?

What can be learned from other states?

How can the various planning and programming efforts be harmonized?

How can the need for SYIP/STIP revision be balanced with the need for a

stable platform in the near term?

How will innovative financing techniques be accommodated by the SYIP and

STIP processes?

How can the process of amending the STIP be streamlined?

Mr. Charles Rasnick of the Programming Division (VDOT) and Mr. Kenneth Lantz of

the Transportation and Mobility Planning Division (VDOT) are co-chairs of a committee of

VDOT, VDRPT, FHWA, and FTA that is implementing the twenty-one recommendations.

There are three subcommittees: (i) Procedures, chaired by Ms. Deborah Grant, (ii) Finance,

chaired by Mr. Robert Hofrichter, and (iii) Public-Involvement/Education, chaired by Mr.

Ben Mannell. An oversight group includes Mr. Jeffrey Southard (Chief of Planning and the

Environment, VDOT) and Ms. Barbara Reese (Chief Financial Officer, VDOT). In

December 2002, VDOT and VDRPT submitted the first actual STIP to the FHWA and

FTA for approval. In 2003, Mr. Rasnick undertook to compile the STIP electronically and

completed an initial version of an electronic SYIP. With respect to STIP development, a

memorandum of agreement between Virginia agencies and federal agencies will be in place

in the next weeks. Pre-allocation hearings in the Fall 2003 will serve as test beds of the

evolving SYIP/STIP public involvement process.

6

Table 1. Twenty-one recommendations of the FHWA/FTA/VDOT/VDRPT Review (FHWA 2002)

Timing:1. The schedule for the SYIP should be modified to better facilitate development of the STIP.2. Develop a standard STIP/TIP/SYIP development cycle and consider implementing a two-year

STIP/TIP cycle.

Technology:3. Provide the SYIP to the MPOs in an easy to use electronic format.4. Prepare the SYIP in an electronic environment that would facilitate development of the STIP and

the demonstration of financial constraint.

Format:5. Develop a standard STIP/TIP format in conjunction with Virginia MPOs.6. Develop and incorporate into the STIP a financial summary table including a narrative

discussion of the process and detailed annual allocations by program category and obligation. These annual allocations should align with project allocations and would support timely FHWA/FTA review and approval.

7. After development of an electronic format, consider the implementation of an e-STIP.

Financial:8. VDRPT and transit operators need to provide three years of programming for STIP/TIPs as

required in 23 CFR 450.9. Demonstrate financial constraint of individual TIPs as well as the STIP.10. Incorporate results of the VDOT Cost Estimate Task Force into the FY04 STIP.11. Account for innovative financial techniques in the STIP/TIPs (i.e., AC, FRANS, bonds, flex

funding, etc.) and their impact on current and future funding.

Education/Outreach:12. Educate the Commonwealth Transportation Board on the STIP process.13. Develop an educational component of this review for FHWA, FTA, VDOT, VDRPT, and other

partners.

Process:14. Establish a VDOT/VDRPT STIP Working Group to maintain communication between divisions

in the STIP process.15. Revise public involvement policy regarding the STIP to align with revised STIP development

procedures.16. Strengthen the MPO and Statewide planning processes to serve as the foundation for the

programming process by establishing priorities for implementation.17. Develop and maintain documented statewide planning and programming procedures. 18. Maximize programming of state/district-wide "line item" or "grouped" projects, as eligible.19. Develop standard STIP modification procedures to reduce FHWA/FTA involvement in minor

STIP modifications and amendments.20. Provide Virginia's MPOs with the information necessary to prepare an Annual Listing of

Projects as required by 23 CFR 450.21. Develop a three-year rather than a six-year STIP.

7

BACKGROUND INFORMATION ON THE IDEF0 MODEL

The IDEF0 (Integrated Definition for Function Modeling) is the technique that breaks

down the activities or functions of the organization or system into its component parts. It is

a graphical language that assists in identifying the functions that are performed, the various

elements needed to perform those function, and what is efficient and inefficient about the

system under study. Describing the SYIP and STIP processes in the BPWin has several

benefits. The high-level outputs of BPWin models are charts of activities and organizations

similar in appearance to those of the 11/02 Process Review. Underlying such charts (in

BPWin) are the characteristics of activities (objectives, titles of responsible individuals,

inputs, rules/controls including relevant legislation, mechanisms for data acquisition,

outputs, receiving individuals, key decisions, impacted activities, and days to complete).

BPWin is thus supporting a business analyst to describe STIP/SYIP and other processes

(e.g., cost estimation) consistently. Once the processes are described in BPWin, evolutions

of the processes are more easily communicated to the ITAD. The BPWin software is from

the same vendor as the model manager, data shopper, and related applications used by the

ITAD, and increasingly by the 'data stewards' across VDOT divisions. A business process

is generally of broader scope than its portion that is to be automated. Process description

helps to set priorities and make analysis of feasibility of what can be done toward

automation. Use of the IDEF standards (implemented by BPWin) may evolve to be a

common practice across the agency. For now, ITAD expects that IDEF standards will assist

understanding with the end users. The benefits of this project prepare VDOT personnel to

apply process descriptions (IDEF0 and IDEF3) to other critical processes of planning and

finance.

Figure 1: IDEF0 Description - Description of IDEF0 Format of Mapping

8

Activity or Function

Mechanisms

OutputsInputs

Controls

DEVELOPMENT OF METHODODLOGY

The effort consisted of the following tasks, the development of an IDEF Worksheet,

and the use of the AllFusion Program created by Computer Associates (CA).

Task 1: Recommendations for Public Involvement

Evaluated the public involvement activities associated with the development of

SYIP and STIP. The subtasks are the following:

Reviewed the 2003 pre-allocation hearings, CTB meetings, etc.

Reviewed the recent VTRC public involvement report and other literature

Reviewed progress of other states

Identified and characterized the relevant public involvement activities in the

SYIP/STIP process model (see Task 2)

Performed critical evaluation of the new public involvement process

Developed recommendations for evolution of the public involvement process for

the SYIP

Developed recommendations on how the STIP can receive public comment as a

separate document from the SYIP

Supported the STIP/SYIP committee currently working on a public involvement

plan

Reviewed outcome of the recent process review on public involvement (FHWA)

Made recommendations for the evolving public involvement policy of VDOT

(1995)

Task 2: BPWin Process Model of SYIP and STIP Development

Documented the business processes of the SYIP and STIP using the IDEF

standards, using BPWin software. The effort was built on outcomes of the STIP Process

Review (November 2002) and did not interfere/impede the work of the STIP

implementation team or duplicate work previously accomplished by the review team.

9

Furthermore, the effort was not duplicating ITAD effort. UVa (1) Imported existing SYIP

and STIP business processes into the BPWin software, requesting additional detail of

process activities as needed to meet the requirements of the process description format

(IDEF0 and IDEF3). (2) Described in narrative that was consistent with step (1) the

SYIP/STIP business process, providing documentation that is useful to educate the CTB

and others. [ITAD performed database development and implementation of STIP

functionality with iSYP. ITAD development of the STIP document reflected the standard

TIP format being developed by VDOT and subject to MPO concurrence.] The subtasks are

the following:

Documented SYIP and STIP relationships to other databases and activities to

include FMS II, PPMS, cost estimation system, etc.

Described a calendar-based process model for SYIP and STIP development using

BPWin software

Reviewed the current iSYP functions and help menus

Reviewed and benefit from ITAD application of BPWin to cost estimation

Described the STIP/SYIP business processes using BPWin (IDEF0 and IDEF3)

Built on the process descriptions of (i) the 11/02 FHWA/VDOT/VDRPT report on

'Development and Financial Constraint of Virginia's STIP' and (ii) the latest version

of the STIP calendar

Sought additional detail of activities, which was required for the BPWin process

model

Supported ITAD by adding a STIP module to the ISYP system by

December/January (the precise functionality of the iSYP extension is to be defined)

Demonstrated that the BPWin process model supports IT development of the

electronic STIP environment (e-STIP)

VDOT requested a narrative description of the SYIP and STIP processes for the

FHWA, CTB, et al. This component of Task 2 was a companion to the BPWin modeling--

both narrative and BPWin modeling involve characterization of the processes from

inception to completion, documenting the SYIP/STIP development processes, and

providing support for changes or streamlining of the processes. Preliminary progress to

10

date on Task 2 has been to meet on several occasions with ITAD staff for orientation to the

BPWin tool, to obtain and install the tool at UVa, to find that IDEF3 is the appropriate

level to describe a process that is a sequence of activities (calendar-based, as is the

SYIP/STIP development), to enter a sample of the SYIP/STIP activities into the tool

relying on the 11/02 FHWA report and a SYIP/STIP timeline from 10/21/03 for the

definitions of the activities, and to identify which of the activities are associated to 'public

involvement'.

Task 3: BPWin Process Model of Amendment Process

Documented in BPWin the sub-process for tracking STIP amendments and

maintaining fiscal constraint. The subtasks are the following:

Reviewed the recent MOA addressing the amendment process

Characterized in BPWin the IDEF0 and IDEF3 activities that constitute the

amendment process

Identified the process methods to track changes and document continued financial

constraint as changes are made

Provided narrative documentation of the amendment process

Identified opportunities to improve or support the amendment process.

Identified and prioritized those activities of the amendment process that are

candidates for automation by ITAD et al.

Used the BPWin result to describe evolution of the current process (fiscal

documentation is maintained by hand and modified in spreadsheets) to a process that

utilizes the iSYP/STIP database to generate understandable documentation of what is being

changed--the revised table C from the STIP document, etc.

IDEF Worksheet

A worksheet was created to display information gained from interviews from

persons working with or on the STIP process. The worksheet showed the data in a way so

11

that it could then be transformed into the IDEF0 format in the AllFusion program. This

worksheet is available in Appendix B of this document.

Each row in the IDEF Worksheet represents a new activity or role in the STIP

process. Each column is a different component of the activity. The ones used for the

IDEF0 model in the AllFusion program are: Activity, Inputs, Controls, Mechanisms, and

Outputs. The rest are to help our group better understand the role and purpose of the

activity in the STIP process. The STIP processes were broken down into different groups,

including: STIP Process, Amendment Process, Public Involvement, Construction Process,

MPO Process, and Environmental Process. This was done so that we could better

understand how the different tasks for the divisions at VDOT worked into the flow charts

created by Jennifer DeBruhl in the FHWA 2002 Document.

All the information in the worksheet was collected through interviews in person or

by phone conversation. The interviews were conducted with personnel working directly on

the STIP project in different divisions at VDOT. It was important to transfer the

information gained from these interviews into this format before entering into the

AllFusion program. This is so more information than can be entered into the program

could be in viewable format.

AllFusion Program

Information from the IDEF Worksheet was transferred into the AllFusion Program

created by Computer Associates (CA). This program displays the data flow diagrams

found in the Development and Financial Constraint of Virginia’s STIP into IDEF0 format.

These models can be found in Appendix C of this document.

Many benefits are possible with the transferring of data from data flow diagrams

into IDEF0 format. One is that each activity can be broken down into its own individual

activities. This allows one to view each main activity’s raw materials. Another benefit is

that one can view all the inputs, outputs, controls, and mechanisms that go into each

activity. The main goal of inserting all the information into this format was so the user

could better understand the organization of the STIP project and the programming that goes

into the STIP.

12

After developing this AllFusion program, many disadvantages were found. After

all the activities were entered, it was apparent that the diagrams were difficult to read. It

was even more difficult to read the inputs, controls, mechanisms, and outputs that went into

each activity. Another problem was that this program did not show the project life cycle in

the STIP. A new task for the team was now developed to study the project life cycle of the

STIP and to develop a method for displaying how a project starts and finishes in the STIP.

APPLICATION

To understand how VDOT will apply this project to their STIP process, we

interviewed Jennifer DeBruhl, the writer of the November 2002 document, to understand

why her document was originally written and what its purpose was, and we focused on the

sub-processes of the STIP, including the Environmental, Public Involvement, Construction,

and Amendment processes.

Mrs. DeBruhl is the Community Planner for the Federal Highway Administration

Virginia Division and main writer of Development and Financial Constraint of Virginia's

STIP. The STIP and SYIP started with nothing and it took nine months on finding

information on how things fit together. She developed the charts in the Appendices as

flowcharts, except the Revenue Estimates chart, which are inputs into the Revenue

Forecast. The STIP Development Process is a flow chart showing the SYIP developing

into the approved STIP. The boxes in the STIP Development Process are broken down

later into other flow charts or flow chart hierarchies. Some of her recommendations were

to pull the STIP away from the SYIP and to educate the CTP and public on what the STIP

is. The STIP does not have to be apart of the SYIP, it is a program that is parallel to the

SYIP but not exactly the same. Trying to force the STIP to be the same as the STIP forces

VDOT into a corner. Educating the public and the CTP would allow projects to move

more quickly through the STIP process because all the requirements and formats would

already be accomplished at the beginning. Instead of projects being turned down during

the STIP process because certain requirements are not meet, if the public and CTP

understand the STIP better than can be better prepared for entering projects into the

program.

13

Other interviews were conducted with personnel from other divisions in VDOT that

apply to the STIP. These interviews led to information for the many different sub-

processes in the STIP. An important sub-process of the STIP is the Amendment Process.

It is important to understand all the tasks involved in amending a project in the STIP, that

way a project can still be approved if details of it are changed. Another important sub-

process of the STIP is the Public Involvement. It is imperative to understand how the

public will voice its opinions on what projects should be completed in their areas. The

Construction Process is how the project will receive funding and how a company is

awarded the contract for the project. The final sub-process is the Environmental Process.

It is important to understand how air quality can stop a project from being started and how

federal standards can be meet so that the project can continue.

CONCULSIONS

The effort delivered:

Critical evaluation and recommendations for SYIP/STIP public involvement, as

accomplished in Task 1

BPWin models and narrative description of SYIP/STIP processes, as accomplished

in Task 2

BPWin models of amendment processes and recommendations for implementation,

as accomplished in Task 3

The effort prepared progress reports and a VTRC final report, developed and made

presentations to the STIP/SYIP committee. The deliverables of the project were interim and

final reports, presentations, and prototype spreadsheets to support SYIP/STIP development

by VDOT, VDRPT, MPOs, and localities. Documentation of progress was provided

through an internet web site at the University of Virginia

(http://www.virginia.edu/crmes/stip).

14

http://www.virginia.edu/crmes/stip

RECOMMENDATIONS

After studying Flow Chart Diagrams we recommend that the project life cycle of

the STIP be presented in a simulation format. This way one can view how a project is

started, what divisions it goes through, where the project can be amended or deleted, and

where a project finishes. Our recommendation is to use the Arena software to simulate this

process. After this is done, one can see where in the project life cycle changes need to be

made and how the different divisions can better communicate with each other.

15

REFERENCES

Buede, Dennis M. The Engineering Design of Systems. John Wiley & Sons, Inc. 2000.

Pgs 59-74.

Federal Highway Administration (FHWA et al. 2002), Federal Transit Administration,

Virginia Department of Transportation, and Virginia Department of Rail and Public

Transportation. Development and Financial Constraint of Virginia’s STIP. Federal

Highway Administration—Virginia Division. Richmond, Virginia. November 2002.

42 pages.

IDEF Family of Methods. http://www.idef.com/idef0.html Knowledge Based Systems,

Inc. College Station, TX. 2000.

16

http://www.idef.com/idef0.html

APPENDIX A

IDEF Worksheet Questions Webpage

The purpose of this document is to describe what parameters we need from you about each of your activities and/or roles that go into the STIP/SYIP integration. Please complete one of these forms for each of your activities and/or roles.

Each row on the worksheet represents a new IDEF0 (Integrated Definition for Function Modeling) activity. IDEF0 is the technique that breaks down the activities or functions of the organization or system into its component parts. It is a graphical language that assists in identifying the functions that are performed, the various elements needed to perform those functions, and what is efficient and inefficient about the system under study. (i.e. What are the roles you have in generating the STIP?) For more information on IDEF please go to www.idef.org

Figure 1: IDEF0 Description - Description of IDEF0 Format of Mapping

The columns contain the IDEF0 standards as well as supplementary material.

Your name: First Last

Your email address:

Title of your position:

Field 1: Name of Activity Name or title for activity or function.

17

http://www.idef.org/

Field 2: Inputs Something consumed or modified in the process. (i.e. schedules, costs, drafts)

Field 3: Controls A constraint on the operation of the process. Represents the objects that govern the manner in which inputs are transformed yet are not themselves transformed by the activity. Consists of legislation, regulations, and policies related to the system. (i.e. codes, restrictions)

Field 4: Mechanisms Something used to perform the process, but is not itself consumed. The elements that accomplish the actions of the process, such as people, manual or automated tools, established procedures for holding hearings, etc. (i.e. software applications, email exchange, etc.)

18

Field 5: Outputs Something resulting from the process. Shows what an activity produces or creates.

Field 6: ObjectiveThe goal of the function or activity.

Field 7: BPwin Diagrams Link to the activity in BPwin format. .

Field 8: Title of Responsible Person(s) Person(s) in charge of the function or activity.

Field 9: Key Decisions Possible choices for the outcome of the activity or function.

Field 10: Duration

19

Time/length of the activity.

Field 11: Transcripts/Interviews Link to a document that shows an outline description of the activity, interview, or a memo on the activity.

Field 12: External LinksLinks to sites outside the CRMES website that are pertinent to the activity.

Field 13: Diagrams/Models Diagram showing detail of the activity.

Field 14: Reviews Notes or reports available on the activity.

Field 15: Potential Recommendation Any recommendations on how to improve the activity.

Field 16: MiscellaneousAny other information or files available on the activity that did not fit into the fields above.

20

Please contact Professor Lambert with any further questions:

Email: [email protected] Office Phone: 434-982-2072 Office Assistant Phone: 434-924-0960

21

mailto:[email protected]

IDEF Worksheet Questions Coding

<HTML><HEAD><TITLE>IDEF Worksheet Questions</TITLE></HEAD><BODY><H1>IDEF Worksheet Questions</H1>

<BASE HREF="http://www.virginia.edu/crmes/stip/"><p>The purpose of this document is to describe what parameters we need from you about each of your activities <br> and/or roles that go into the STIP/SYIP integration. Please <br> complete one of these forms for each of your activites and/or roles.</p> <p>Each row on the worksheet represents a new IDEF0 (Integrated Definition for Function Modeling) activity. <br> IDEF0 is the technique that breaks down the activities or functions of the organization or system into its <br> component parts. It is a graphical language that assists in identifying the functions that are performed, the <br> various elements needed to perform those functions, and what is efficient and inefficient about the system <br> under study. (i.e. What are the roles you have in generating the STIP?) <br> For more information on IDEF please go to <a href="http://www.idef.org">www.idef.org</a></p> <p><img src="idef.gif" width="351" height="176"> <br> <strong><font size="2">Figure 1: IDEF0 Description - Description of IDEF0 Format of Mapping</font></strong></p> <p>The columns contain the IDEF0 standards as well as supplementary material. <br> <hr width="600" align="left"><FORM action="http://www.virginia.edu/crmes/stip/cgi-bin/uploadform.pl" METHOD="post" enctype="multipart/form-data"> <P> <b>Your name:</b> <font size="1">First</font> <INPUT TYPE="text" NAME="firstname" > <font size="1" face="Times New Roman, Times, serif">Last</font> <input type="text" name="lastname"> </P> <P> <b>Your email address:</b>

22

<INPUT TYPE="text" NAME="from" > </P> <P> <b>Title of your position:</b> <INPUT TYPE="text" NAME="position" > </P> <P> <b>Field 1: Name of Activity</b> <br><font size ="2">Name or title for activity or function.</font> <br> <INPUT TYPE="text" NAME="activity"></p> <P><b>Field 2: Inputs</b> <br> <font size="2">Something consumed or modified in the process. (i.e. schedules, costs, drafts)</font> <br> <TEXTAREA NAME="inputs" WRAP="physical" ROWS=5 COLS=70></TEXTAREA> <br> <br> <b>Field 3: Controls</b> <br> <font size="2">A constraint on the operation of the process. Represents the objects that govern the manner <br> in which inputs are transformed yet are not themselves transformed by the activity. Consists <br> of legislation, regulations, and policies related to the system. (i.e. codes, restrictions)</font> <br> <TEXTAREA NAME="controls" WRAP="physical" ROWS=5 COLS=70></TEXTAREA> <br> <br> <b>Field 4: Mechanisms</b> <br> <font size="2">Something used to perform the process, but is not itself consumed. The elements that accomplish <br> the actions of the process, such as people, manual or automated tools, established procedures for <br> holding hearings, etc. (i.e. software applications, email exchange, etc.)</font> <br> <TEXTAREA NAME="mechanisms" WRAP="physical" ROWS=5 COLS=70></TEXTAREA> <br> <br> <b>Field 5: Outputs</b> <br> <font size="2">Something resulting from the process. Shows what an activity produces or creates.</font> <br> <TEXTAREA NAME="outputs" WRAP="physical" ROWS=5 COLS=70></TEXTAREA> <br>

23

<br> <b>Field 6: Objective</b><br> <font size="2">The goal of the function or activity.</font> <br> <TEXTAREA NAME="objective" WRAP="physical" ROWS=5 COLS=70></TEXTAREA> <br> <br> <b>Field 7: BPwin Diagrams</b> <br> <font size="2">Link to the activity in BPwin format.</font> <br> <INPUT TYPE="file" NAME="bpwinfile"> <br> <br> <b>Field 8: Title of Responsible Person(s)</b> <br> <font size="2">Person(s) in charge of the function or activity. <br> <INPUT TYPE="text" NAME="responsible"> </font> <br> <br> <b>Field 9: Key Decisions</b> <br> <font size="2">Possible choices for the outcome of the activity or function. <br> <TEXTAREA NAME="decisions" WRAP="physical" ROWS=5 COLS=70></TEXTAREA> <br> <br> </font> <b>Field 10: Duration</b> <br> <font size="2">Time/length of the activity.</font> <br> <INPUT TYPE="textarea" NAME="duration" VALUE=""> <br> <br> <b>Field 11: Transcripts/Interviews</b> <br> <font size="2">Link to a document that shows an outline description of the activity, interview, or a memo on the activity.</font> <br> <INPUT TYPE="file" NAME="transcriptsfile"> <br> <br> <b>Field 12: External Links</b><br> <font size="2">Links to sites outside the CRMES website that are pertinent to the activity.<br> <TEXTAREA NAME="links" WRAP="physical" ROWS=5 COLS=70></TEXTAREA> </font> <br> <br> <b>Field 13: Diagrams/Models</b> <br> <font size="2">Diagram showing detail of the activity.</font> <br> <INPUT TYPE="file" NAME="diagramsfile"> <br>

24

<br> <b>Field 14: Reviews</b> <br> <font size="2">Notes or reports available on the activity.</font> <br> <INPUT TYPE="file" NAME="reviewsfile"> <br> <br> <b>Field 15: Potential Recommendation</b> <br> <font size="2">Any recommendations on how to improve the activity.<br> <TEXTAREA NAME="recommendations" WRAP="physical" ROWS=5 COLS=70></TEXTAREA> </font> <br> <br> <b>Field 16: Miscellaneous</b><br> <font size="2">Any other information or files available on the activity that did not fit into the fields above.<br> <TEXTAREA NAME="miscellaneous" WRAP="physical" ROWS=5 COLS=70></TEXTAREA> <br> <br> <input type="file" name="miscellaneousfile"> </font> <p></p> <input type="submit" value="Submit Questionnaire"></form> <p>Please contact Professor Lambert with any further questions: </p> <ul> <li>Email: <a href="mailto:[email protected]">[email protected]</a></li> <li>Office Phone: 434-982-2072</li> <li>Office Assistant Phone: 434-924-0960</li> </ul></BODY></HTML>

</html>

25

IDEF Worksheet Questions Methodology by Ryan Tiffany

This is a short explanation of how I came about writing the scripts for our server:

In order to effectively use forms on the internet, you need to be able to process the information from the forms and then receive that information. The most common way this is done is by Common Gateway Interface (CGI) Scripts or programs. The most common programming language used for these scripts is Perl.

When I started the task of trying to make a form for VDOT officials to send information on various IDEF activities to personnel in the Systems Department my original impulse was to just use an existing script that was available over the internet. Unfortunately, I could not find a script that did everything that was desired of our form.

For example, there were many forms that sent a forms information over email, but none that allowed file uploads -- and those that did allow file uploads didn't let you send an email to multiple addresses.

So...my next idea was to try to adjust some of the pre-existing scripts to fit our needs. I was able to do some tweaking but the more I tried, it just become increasingly evident that I needed to learn the basics of Perl programming if I ever wanted to be successful in this project.

So my next step was to buy a book called "Teach Yourself CGI in 24 Hours" by Rafe Colbourn. I worked with this book for a week but it was just a little too advanced for me. It did teach me important things regarding CGI scripts and where they need to be stored on a server.

A cgi-script often has a '.cgi' or '.pl' extension. It is stored in the default directory for CGI scripts on a server. This is almost always called '/cgi-bin'. There was no /cgi-bin already set up on our server, so I asked the people at ITC.virginia.edu if CGI scripts were allowed and they told me that if I set up a '/cgi-bin' and gave it the proper permissions (I’ll get to that in a sec...) then I would be able to process scripts.

When it comes to setting permissions, it is all pretty easy. Basically, when a file is uploaded to a server it is generally set so that only the owner can read and write to it, and everyone else can just read it. In order for others (i.e. any browser) to be able to execute it, you need to change the permissions. You can either telnet to a server to change the permissions or you can often use an FTP client to do the job.

Because this book soon started to get into too advanced programming, my next step was to buy a simpler book that could help me learn how to write a CGI script from step one. I bought a book called"Perl and CGI for the World Wide Web" by Elizabeth Castro. This book is partof a series of books called Visual Quick Start Guides. I had used other Quickstart guides to learn HTML programming,Javascript programming, and

26

Macromedia's Dreamweaver. I always found the books incredibly useful and great for absolute beginners.

The book gave me a great intro to Perl programming and I was quickly able to apply some of my previous C++ and Java knowledge (but believe me, I am just about as bad as it gets when it comes to programming). Using this book, I was able to create a script that accomplished all of the necessary tasks.

A Description of what our script does:

It takes information from the form located at www.virginia.edu/crmes/stip/IDEFform.htm

Once the user presses the submit button, they are brought to a new page that tells them what they just entered in the form.

All of the information is written to a log file on the server labeled by the user's name and the date. If any files were chosen to be uploaded they are also written to a folder on our server under the file's original name.

Each time a form is filled out the user gets an email thanking them for submitting a questionnaire.

A separate email is also sent to a Systems person that serves to notify him that a questionnaire was submitted. The email also includes the location of the logfile that was created and tells all of the information that the user entered (the same information can be found in the log file). The only important script located in the cgi-bin is called uploadform.pl - everything else is a testing script that I used along the way to figure out how to write the whole uploadform.pl file.

If you have any questions about any of this email me at [email protected]

Thanks,

Ryan Tiffany

27

APPENDIX B: IDEF WORKSHEET

STIP PROCESS* Denotes IDEF Field of Information

Initials of Author Activity Inputs* Controls* Mechanisms* Outputs* Objective

BPWin Diagrams

Title of responsible person(s) Key Decisions

Funding for construction

Start/ End Date

Interview Transcrip

t

External

LinksDiagrams/Models

Reviews

Potential Recommendations

ELI - 022304

Revenue Forecasting TBD TBD TBD

Estimates to VDOT by VDRPT

Calculation for Allocation of funds for construction and non construction purpose

Revenue Forecasting Process Model

FTA: annual apportionments for State RABA: Adjust apportionments

Estimates and Allocation of funds


1/01/04 -- 5/01/04**

ELI

Drawing a Six Year budget

Estimates from Revenue Forecast

Code of Virginia and Federal regulations

Rough Estimates, Public Hearings Estimates updated quarterly. VDOT/FHWA improving methodology

Drafted budget for SYP

Allocate funds over a period of six years TBD VDOT Allocations


ELI

Planning and Engineering Estimates

1993 review of award cost for projects, information from public hearing TBD TBD

Estimates for capital purchases, perating expenses, fixed facilities

Rough Estimates TBD PPMS TBD Drafted SYP

ELI

Draft Six Year Program

Estimates from Planning and Engineering estimates

Discrepancy in composite of allocations (Financial Planning and Debt Management Division) Breakdown of NHS funding TBD

Advertisement Schedule, cash forecast

Updated cost estimates in PPMS TBD

P & S, VDRPT

Estimates and Allocation of funds

Cost and Estimates, Public Hearings

ELI

Planning and Programming meetings

Advertisement Schedule TBD TBD TBD

Provide a forum for citizens and officers to meet TBD CTB TBD TBD

27



ELI

Agency Review of Program Allocations TBD TBD

Comprehensive, line by line, district by district TBD

Review of Cost estimation and Allocation TBD

Reviewed by VDOT leadership. Financial Planning and Debt Management Division runs forecast to determined if the program is balanced to cash

Determination of blanced cash in program TBD

ELI

Review Program with the Commonwealth Transportation Board TBD TBD TBD

Changes incorporated into tentative program

Review of program darft copies (again) TBD

CTB members TBD TBD

ELITentative Program

Agency and CTB review processes, public and local govt comments

Comments from public and govt

Incorportaion of urban, rail and public transportation, enhancement and real safety

Final Figures sent to Financial Planning and Debt Management Division, copies sent to CTB prior to their meeting after which document is made available for public comment TBD TBD TBD

Basically review of all projects TBD

ELI

Final Public Hearing TBD TBD

Held on same day: Morning in the western, Afternoon in the Eastern TBD TBD TBD TBD TBD TBD

28

AMENDMENT PROCESS

Initials of

Author Activity * Inputs * Controls*

Mechanisms * Outputs ObjectiveBPWin

Diagrams

Title of responsible person(s)

Key Decisions Duration

Transcripts/

Interviews

Miscellaneous

External


Reviews

Potential Recommendations

RPT - 012004

Need for an Amendment

Advertising, Change in cost of original project, New projects

Programming Division sends out Request for Amendment

To get the ball rolling on getting a new project into the STIP

see Diagrams/Models

http://www.access.gpo.gov/nara/cfr/waisidx_03/23cfr450_03.html

amendment.htm

RPT - 012504

Project revised w/ new estimate

Only done when the original project estimate has seen an increase of at least %10

The project revision is necessary to get reapproved and put into the STIP

see Diagrams/Models TBD

Amendment Review Process.doc


amendment.htm

RPT - 012504

MPO needs to ammend his/her TIP

Only done when a new project is being proposed

The MPO needs to amend his/her TIP so it accurately reflects information in the STIP

see Diagrams/Models

Regional MPO

30 day minimum, according to TIP meetings and the public review process.

Interview Transcript w Gene Wells.doc


amendment.htm

RPT - 021004

Letter of Approval is sent to Ken Lantz

Draft is constructed by VDOT staff member

Letter is sent via mail

Decision on approval

see Diagrams/Models

Ken Lantz, Transportation Planning Division Administrator

Approve amendment as is, Approve amendment w/ changes, Reject amendment

Duration of approval depends mostly on the commissioner

Nov 17,2003doc.doc


amendment.htm

Make Amenmdent Approval process more automatic/ electronic

RPT - 022304

Letter of Approval is sent to Jeff Southard




To gain a better scope of the amendment review process

see Diagrams/Models

Jeff Southard, Assistant Transportation Commissioner



Nov 17,2003doc.doc


amendment.htm


29
















RPT - 030104

Letter of Approval is sent to the VDOT Commissioner


Never sent on Friday



see Diagrams/Models

Philip Shucet, VDOT Commissioner



nov17a,2003doc.doc


amendment.htm


RPT - 030404

Letter of Approval is sent to Roberto Fonseca-Martinez




see Diagrams/Models

Roberto Fonseca-Martinez, FHWA Division Administrator



nov17a,2003doc.doc


amendment.htm


RPT - 030704

Amendment is approved

see Diagrams/Models


amendment.htm

RPT -

Money is authorized for project

see Diagrams/Models


amendment.htm

RPT -

New project enters the STIP

see Diagrams/Models


amendment.htm

30
















PUBLIC INVOLVEMENT

Initials of

Author Activity * Inputs*

Controls

* Mechanism

s*

OutputsObjectiv

eBPWin

Diagrams

Title of responsi

ble person(

s)

Key Decision

s Duration

Transcripts/

Interviews

Miscellaneous External Links

External Links

Diagrams/ Models

Review Documents Reviews

Potential Recommend

ations

RTS - 022004

SYP - Draft SYP (11): Review District/Division Input to See What Projects Can Be Added

Six Year Advertisement Schedule

Mail and Via the internet

Complete Draft Program

Determine if new projects need to be added to the Draft Program.

Utah's STIP Development Process.pdf - Detailed description of the process for development of the STIP and MPO documents in Utah

Development and Financial Constraint of Virginia's STIP (p.7-8).pdf

Draft SYP - Included in the Six Year program process

Public Involvement Techniques for Transportation Decision Making.htm - Identifies various techniques that can be useful in the implementation of public involvement.

Public Involvement Technique Summary

Public Involvement Toolkit (Minnesota)

RTS - 022204

SYP - Tentative Program (9) MPO (4) STIP (5): Pre-allocation Hearing

Public and Local Government Comments and Advertisement Schedule

Federal Gudelines under $450.212 of the Statewide Transportation Planning Rule Published under the Code of Federal Regulations

A meeting is held in each of the nine districts and oral comments are limited to 3 minutes

Changes to be implemented in the Draft Program

Provide a forum for citizens and officers to meet

District Administrators, CTB board, Fin.Plng and Debt Mgmt., L&D, public affairs

STIP Public Involvement Regulations and VDOT PI Policy.pdf - Includes the federal guidelines driving the public involvement process.

Development and Financial Constraint of Virginia's STIP (p.9, 12-14).pdf

Tentative - Included in the Six Year program process

Assessment of VDOT's Public Involvement Practices.pdf (Phase II report) - Provides reccommendations and feedback for the public involvement practices of VDOT.

Notes from Public Hearing Attended

Recommendations from VTRC Phase II report

RTS - 022304

SYP - Tentative Program (1): Tentative Program made available for public comment

CTB Approval and the Tentative Program

Full information is provided on projects listed via the internet

Draft of Final Program

Obtain feedback from the proposed schedule of projects planned

VDOT Residency Staff

Development and Financial Constraint of Virginia's STIP (p.9).pdf

Tentative - Included in the Six Year program process



31

http://www.virginia.edu/crmes/stip/Summary%20of%20FHWA%20Report.doc



http://www.fhwa.dot.gov/reports/pittd/cover.htm



http://www.virginia.edu/crmes/stip/tentprog.jpg



http://www.virginia.edu/crmes/stip/STIP.pdf



http://www.virginia.edu/crmes/stip/(7)%20public_document.doc



http://virginiadot.org/vtrc/main/online_reports/pdf/03-r17.pdf









http://www.virginia.edu/crmes/stip/Statewide+Planning+VDOT.pdf









http://www.virginia.edu/crmes/stip/draftprog.jpg






http://www.virginia.edu/crmes/stip/STIPDevprocessUtah.pdf



RTS - 022304

STIP (11) SYP - Urban (14) :Final Public Hearing

CTB Approval, the Tentative Program, and public and local comments


Held on same day: Morning in the western (Salem), Afternoon in the Eastern (Richmond)

Changes to be incorporated into the final program

Provide a forum to provide feedback on the Tentative Program

Resident Engineer CTB Management

Changes made to Program based on public input


STIP - Derived from the process for the STIP

RTS - 022504

SYP - Secondary Roads (1): Public Requests/ Public Comments

Public Input

Via the internet, Mail, and Conversations with public officials

Recommendations for Transportation Projects

Obtain public feedback for secondary road planning

County Staff, Board of Supervisors, and VDOT Residency Staff

Utah's STIP Development Process.pdf - Detailed description of the process for development of the STIP and MPO documents in Utah


Secondary - Included in the Six Year program process



RTS - 022604

SYP - Secondary Roads (11): Public Hearing (Draft Revision)

Draft SYP and Public priority

Secondary Road Act, 1977 State Legislation

Conducted between October and December

SYP revisions

Obtain public feedback for secondary road planning

Board of Supervisors



Secondary - Included in the Six Year program process

RTS - 022604

MPO (12): Public Hearing Review

SYP Program


Public Involvement Process conducted individually by each MPO.

Submission of TIP for Air Conformity Analysis and Approval

Obtain public feedback for development of the TIP



MPO - Derived from the process for the STIP and TIP

Assessment of VDOT's Public Involvement Practices.pdf (Phase II report) - Provides reccommendations and feedback for the public involvement practices of VDOT.

Recommendations from VTRC Phase II report

32







http://www.virginia.edu/crmes/stip/Mpo.jpg









http://www.virginia.edu/crmes/stip/Secondary.jpg
























http://www.virginia.edu/crmes/stip/STIP.jpg






CONSTRUCTION PROCESS

Initials of

Author Activity

* Inpu

ts * Controls*

Mechanisms

* Output

sObjecti

ve

BPWin Diagra

ms

Title of responsib

le person(s)

Key Decisions

Duration

Transcripts/

Interviews

Miscellaneous

External

LinksExternal


Review Documen

tsReviews

Potential Recommend

ations

RTS - 042904

Develop and Prepare estimates for the project

Intrinsic Cost estimate, List of Items

Items that are 65% of Bid price are analyzed

Made by a Rational Estimate that factor in location, market conditions, quotes, etc

Schedule of Items, Estimate to compare against Bidding

Make an estimate to compare against bids

Contract Engineer

Estimating Guideline Procedures - VDOT website

RTS - 042904

Get FHWA approval for Federal Funds

Estimated Cost

Must Fit Financial Constraint of the STIP

Federal Approval to continue to Bidding Process

Make sure that estimates fit with financial issues

Plan Review - VDOT website

RTS - 043004

Document and Advertise on Monthly Advertisement Schedule

Schedule of Items, Location and Decription

Must have 5 days to modify an estimate prior to advertisement

Via the internet or mail

Bids to compare against the estimate

Obtain bids to use in the selection of contractors

Contract Engineer

Document Production - VDOT website

RTS - 043004

Adjustments made to Bid

Contract Bids

Submit for federal reapproval if bid exceeds 7% over estimate or 20% under estimate

Federal Approval to award a contract

Re-check if new cost fits financial contraint of STIP

Bid Letting - VDOT website

RTS - 043004

Award Contract

Division Approval

Notice to Proceed - Issued 30-45 days after award of contract, contractor must begin construction within 10 days of receival.

Contract completion for Construction

Award a final contract for construction

District Administrator, Chief Engineer

Contract Engineer - VDOT website

33

http://www.virginiadot.org/business/const/internalprocesses.asp















MPO PROCESS

Initials of Author ActivityPowerpoint Presentations Flow Charts Flow Charts Word Documents

ELIMPO Process Information

SYIP Public Hearing Presentation MPO Flow Chart 1 MPO Flow Chart 2

Metropolitan Planning Transportation Improvement Program

ENVIRONMENTAL PROCESS

Initials of

AuthorActivit

y*

Inputs * Controls

* Mechanis

ms

* Output

s Objective

BPWin Diagra

ms

Title of responsible person(s)

Key Decisions Duration

Transcripts/ Interviews

Miscellaneous

External Link

s

External Link

s

Diagrams/

Models

Review Docum

entsReviews

Potential Recommend

ations

RKJ - 062404

Air Quality Conformity

Computer Models (travel demand and air quaility emmisions); Schedules; Costs

Clean Air Act (40 CFR 93, 40 CFR 51); National Evenrionmental Policy Act (NEPA); TEA-21

Travel Demand Forecasting (TT+); Mobile 6.2 (emission model); Conformity Analysis Tool (CAT); Post Processor

Conformity Report for LRP and TIPs in each ozone nonattainment/ maintenance area

Transportation Conformity - demonstrate compliance with an area's STIP as required by the Clean Air Act

Amy Costello, Air Quality Program Manager

Conforming (Suceed); Not Conforming (Fail) - not in compliance b/c too much emissions or conformity lapse (fail to pass w/in time constraint)

Technical/ internal review - 2 months; Public review - 2 wks - 20 dys; Federal Review/approval (EPA) - 45 dys; total 4 to 6 months

Ahmet Anday and Amy Costello Interview

Conformity Triggers

Standard Operating Procedures (DRAFT)

Conformity Standard Operating Procedures

Need to link planning and NEPA processes; put more resources in ISYP; need error checking; let people know their project will need air quality conformity

RKJ - 062404

Transportation Modeling for Air Quality Conformity

Projects contained within the STIP

National Air Quality Standards (NAQS); EPA aire quailty rules

TT+ Software

Vechicle Miles Traveled (VMT); Speeds

Meeting Air Quality Standards

Michael Hester, Air Quality Planning Manager

Pass or Fail

4 to 6 months

34

http://www.virginia.edu/crmes/stip/MPO%20Process%20Docs/Metropolitan%20Planning%20Transportation%20Improvement%20Program.doc



http://www.virginia.edu/crmes/stip/MPO%20Process%20Docs/MPOFlow2.doc

http://www.virginia.edu/crmes/stip/MPO%20Process%20Docs/MPOFlow1.doc

http://www.virginia.edu/crmes/stip/MPO%20Process%20Docs/SYIP%20Public%20Hearings.ppt

http://www.virginia.edu/crmes/stip/MPO%20Process%20Docs/SYIP%20Public%20Hearings.ppt

APPENDIX C: ALLFUSION PROGRAM SCHREENSHOTS

This screenshot represents the entire STIP Development Process. On the left side there is a list of all the activities that go into the STIP Development Process.

35

This screenshot shows the decomposition of the STIP Development Process. It also shows all the inputs, controls, mechanisms, and outputs for each activity.

36

This screenshot shows the decomposition of the activity Revenue Estimates and all the inputs and output that goes into this activity.

37

This screenshot is the decomposition of the activity Six Year Budget. It is a data flow diagram instead of an IDEF like the previous screen shots.

38

This screenshot is the decomposition of the activity Draft Program. This is also a data flow diagram.

39

This screenshot is the decomposition of the activity Tentative Program. This is also a data flow diagram.

40

This screenshot is a decomposition of the activity Project Cost Estimate. It is also a data flow diagram.

41

APPENDIX D: DATA MODELING REQUIREMENTS FOR COTS SYSTEMS

These Standards were found on the VDOT’s Intranet. Go to the Central Office website and scroll down to the bottom of the page on the left hand side one can find a listing of all the divisions’ websites. Go to Data Administration. After the browser opens go to the left hand side of the webpage and find a listing of all the links for other parts of the webpage and go to Guidelines, Polices link. After the site opens scroll down to Guidelines and the COTS standards is the second link.

If you refer to the highlighted section on page 2 of 3, you can see how the Computer Associates’ AllFusion program for IDEF models is an acceptable program with these standards. This shows that what the University of Virginia has been trying to capture using this IDEF model would fall into the Data Management Division.

TIMSC Policy 01-1

Data Modeling Requirements for COTS Systems

Findings Agency NeedsThe agency requires business data models, logical data models and associated Meta Data for all data processing systems. This requires that data captured and stored within Information Systems have a standardized set of data models.

Data Administration IssuesThe most valuable component of an Information System is the data it contains and its quality and relevance to the decision-making process. As such, VDOT's data needs to be managed just like any other asset of the organization. Mechanisms need to be put in place to manage the data that VDOT collects so that it is (1) utilized effectively, (2) it is accurate and timely, and (3) it is necessary for carrying out the mission of the agency.

VDOT has established a Data Administration group in the Data Management Division to routinely evaluate and manage its data stores in a comprehensive fashion. Institutional procedures are being prepared to determine what data needs to be collected, what is its purpose, how it should be captured, who is best suited to capture it, when it is no longer needed, and whether the value of gathering the information is worth the cost.

Commercial Off The Shelf (COTS) IssuesThe COTS system databases are normally proprietary and as such vendors are reluctant to provide VDOT with a Logical Data Model or Physical Data Model of the COTS system. This leaves VDOT without a clear understanding of the VDOT data elements in the COTS database. VDOT needs from each developer of a system which uses a COTS package a Business Process Model, a Logical Data Model, a mapping from the physical COTS data base to the Logical Data Model, and all associated Meta data.

42

RecommendationDetails

Policy

Any developer (contractor or VDOT development team) of a system that uses a Commercial Off The Shelf (COTS) application must provide to Data Administration for review a Business Process Model and associated metadata, Normalized Logical Data Model and associated metadata, and a mapping from COTS system physical database to each data element in the Normalized Logical Data Model. These three deliverables are required to meet the PMLG requirement “Redesign Core Business Processes” 2.5, “Develop Data Models” 4.4 and “Design Databases” 4.5. The normalized logical data model should only include data created by and used by VDOT in the pursuit of a VDOT mission and goals as defined in the Business Process Model. The normalized logical data model should not include elements used for managing or controlling the COTS system. Data Administration expects the COTS system users manual to explain all COTS related data elements. While this policy does not apply retroactively, all COTS systems are encouraged to provide a logical data model with the COTS system cross reference mapping to the logical data model.

The PMLG Design Databases 4.5 also requires an indexing strategy and database sizing estimates. The data base sizing estimates can be included as part of the Erwin model. There are fields in the Erwin model for table and column sizes. The indexing strategy should be included as a separate document.

ApplicabilityThis policy shall be applied to all future Information Systems. In

addition, it may be selectively applied by ITD and DMD to systems that are under development but have not yet reached a production stage.

Glossary

Information SystemAny transactional, decision support, operational or management information system that falls within the purview of TIMSC.

Logical Data Model Logical Data Models are graphical and textual representations of

analysis that identifies the data needed by the application system to achieve the mission, functions, goals, objectives, and strategies; and to manage and operate the application system. It describes the scope, boundaries, and types of data needed to support the functional activities at all levels of the system. The logical data model includes the identification, definition, and normalization of all entities, attributes, with their relationships used in the system. Examples of data models can be found at the following url http://0501codatawhse/da/dmodels.htm.

The business owner may be the best source of the information

43

needed to populate the logical data model with business definitions. The Erwin modeling tool is the current standard at VDOT. The logical data model can be created by reverse engineering the model from the physical database then changing the model to reflect the third normal form. If the physical database is already in third normal form no changes are necessary.

Business Process ModelBusiness process models (BPM) provide a framework for

identifying, defining, and organizing the functional strategies, rules and activities needed to manage and support the way an organization does, or wants to do business. It provides a graphical and textual framework for organizing activities into manageable groupings to facilitate their shared use and control throughout the agency. The BPM is required by PMLG “Redesign Core Business Process 2.5”.

Physical Data ModelThe Physical data model can be generated using the reverse

engineering capabilities of Erwin. This assumes the database is Oracle or some other compatible database. The Data Administration group will perform the reverse engineering if the development team does not have a copy of Erwin. The logical data model can be created by reverse engineering the model from the physical database then changing the model to reflect the third normal form. If the physical database is already in third normal form no changes are necessary.

Meta DataMeta Data is “data about data”, and it is critical to the success of

your decision support system.

Physical COTS database mapping to the LDMThe mapping should consist of at a minimum the physical table

name and attributes cross referenced to the logical table names and their attributes. There may be tables and attributes in the COTS system that do not map to the LDM but there should not be any LDM attributes that do not map to the physical data base.

Roles & Responsibilities

Data Management Division (DMD)DMD has been charged with the responsibility of the agency's data stores.

Data AdministrationThe Data Administrator within the DMD has the responsibility to ensure standards and policies are in place to meet the data requirements of the agency.

44

Benefits Once this policy has been adopted and Information Systems follow the policy - it will become possible to share data between systems and to link business data to the data warehouse. This will allow data warehouse systems to include the appropriate business data in the data warehouse for decision-making within the agency.

Time Frame This policy shall go into effect January 1, 2001.

Critical Success Factors

Operational procedures need to be developed in conjunction with individual information systems to support input of critical data to the data warehouse for decision making at the agency.

45

APPENDIX E: CONCURRENT ENGINEERING PROCESS FLOWCHART

The following flowchart was found at VDOT’s central office under Management Services Division. After clicking on the above link, go to Project Management. Then click on the link for Concurrent Engineering Process under Internet. Then click on the fourth link for the Instruction and Information Memorandum. The flowchart is found on the fifth page of this document. Can also go to the following website to find the document: http://www.extranet.vdot.state.va.us/locdes/electronic%20pubs/iim/IIM226.pdf.

This flowchart shows that Computer Associates’ AllFusion program for IDEF models would be an acceptable program to portray this flowchart into an IDEF. This shows that what the University of Virginia has been trying to capture using this IDEF model would fall under the Management Services Division.

46

http://www.extranet.vdot.state.va.us/locdes/electronic%20pubs/iim/IIM226.pdf

Continuation of the Development and Financial … Report (Update sept 7... · Web viewThe BPWin...

Documents

Transcript of Continuation of the Development and Financial … Report (Update sept 7... · Web viewThe BPWin...