Brevard County (Florida)
Administrative Procedures
 

7540D - COMPUTER SOFTWARE DEVELOPMENT (DISTRICT DEVELOPED OR PROPRIETARY)

Administrative Procedures

The purpose of a computer acquisition procedure is to formalize a uniform standard for computer software development throughout the District. This procedure mandates endorsement and support by the Superintendent. This computer software acquisition procedure covers all computer software developed by the District. The District can have more than one (1) type of District-developed computer software. The types of software will depend on its source. Each computer source will require its own software acquisition procedure. Sources/Types for District-sponsored/developed computer software include the following:

 

A.

District written/created software

     
 

B.

contract personnel written/created software

     
 

C.

vendor written turn-key software

     
 

D.

centralized District-sponsored/developed software

This procedure's objective is to provide acquisition uniformity for District-developed software. This also covers all proprietary software, including development and contracting. The sole ownership of the program's source coding ratifies the programs as proprietary. There will be procedure standards for proposing and recommending benchmarks, vendor selection, and contracting. Components of software will be approved for payment after passing the qualification criteria test. The purchase of object code only software is limited to the defined purchase agreement specifications that come with the software.

Software Procedures

Each type of software will have its own software procedure requirements. These are in addition to the general procedures for all software:

 

A.

District Written Proprietary Software

     
   

All programming will be done in the approved programming language. All programs written using District software, hardware, and any other District-owned resources belong to the District. Programming documentation and operation manuals will follow established standards (Form 7540G F1 required).

 

B.

Contract Written Proprietary Software

     
   

All contracted programmers will employ the same programming standards and procedures as do District employed programmers. Documentation, test data, and drafted work information will be the property of the District. The District is the sole owner of source-coded programs (Form 7540G F1 required).

     
 

C.

Turn-Key System Contracting

     
   

This is a vendor developed turn-key system, including development cost. The program(s) source code belongs to the District. The District will have the copyright and/or patent rights to the developed turn-key system software. The Superintendent can approve other contract arrangements. Any third-party, add-on software used will be identified. The limitations of the use of the third-party software will be defined. Its warranties, restrictions, and operations will be fully identified (Form 7540G F1 required).

     
 

D.

Centralized District-Sponsored/Developed Software

     
   

___________________________________________________________________

     
   

___________________________________________________________________

General Inventory Management Procedure for Software

Educational Technology (ET) is responsible for maintaining and enforcing a District-wide computer software inventory management program. The Assistant Superintendent of ET is responsible for maintaining and enforcing this procedure. A technology committee will be formed and chaired by the Assistant Superintendent of ET. A monthly update of any added or deleted software programs used on District hardware will be made to the computer software inventory management database. The approved computer software list is a screening device for current computer software acquisitions. The committee will be responsible for approving new software. The technology committee will maintain the approved computer software list. The technology committee can grant a waiver when special software needs arise. The special software items will be added to the software inventory management database but not placed on the approved computer software list. There is no requirement for this software to be supported by ET.

All departments will comply fully with this procedure. Software that is not identified by the software inventory management database will be flagged for each computer that is not in compliance. Any software that does not meet contractual agreements will be removed from all computers employing the software. Any employee intentionally placing a software virus on any District system will be reported to the Office of District Security and the Office of Human Resources/Labor Relations. All virus recovery costs may be charged to the employee. Court action will be pursued when appropriate.

Proprietary Developed Software

Proprietary developed software may be from more than one (1) source. Required software that is not listed on the software inventory management database or available for purchase or lease may need to be developed. When the developed proprietary software becomes operational, this information will be put into the software inventory management database file. The technology committee will make the decision if the software will be listed on the approved computer software list. The source of the software will be identified on the approved computer software list. This will allow potential users to contact the developers for information about the software. The District can have its proprietary software developed by more than one (1) method.

District-Written Proprietary Software

District-developed software will follow the District's procedure for District-designed/written software.

End-User Developed Software

End-user developed software will follow the District's procedure for software development. Resources of the ET Department will be available as time permits from the various units as required. Monies may be budgeted to departments for such development. Some users can develop their own software. Depending on the area of operation, there can be different levels of skills available. Depending on the District culture, this activity by users can vary. At times it would not only be faster to accomplish the task, but possibly more economical.

 

A.

The Inception Process

     
   

The end-user department head is required to approve user-developed software within their jurisdiction. The user's department head should receive a memo, from the person requesting it, defining the need for the unavailable software. The department head can also be the originator of the memo. The memo will be part of the project documentation. This is required before any effort is spent in the development of the software.

     
   

User-developed software will be done at the user's own expense. ET will be contacted before any effort is spent producing end-user developed software. The user's manager will be informed what software is available that may assist the project. Also, user management will be informed of what is available from the software inventory management database. Not all District-used software is listed on the approved computer software list. Computer programs may be available that can be used as is or with some modification. Information is available about third-party add-on module software. This module software can be part of the program being developed and save programming time. When users are writing their software, they may find a need for third-party software. This software must meet District software acquisition procedure requirements.

     
 

B.

End-User Resources

     
   

Consulting resources will be provided by ET, as time is available. User management will determine what kind of assistance will be required. The amount of assistance available from ET should be known before pursuing the project. If ET does not have time available, they can provide vendor sources for user assistance. The payment for this service will be paid from the user's budget, unless other provisions have been made. ET will assist end-user management with vendor negotiations.

 

C.

Developing End-User Software

     
   

The user will employ an approved software compiler. The user should contact the help desk with any problems with the compiler software. If the help desk person cannot be of assistance, s/he will provide a person to whom the problem may be referred. Writing user computer programs will follow the procedures for programming methods provided by ET.

     
 

D.

End-User Software Documentation

     
   

A copy of the project, including source code, software, and the supporting documentation will be sent to the technology committee. The committee will examine and test the computer software under the leadership of the ET programming representative on the committee. They will determine if the new software warrants being listed on the approved computer software list.

     
 

E.

End-User Project

     
   

When the decision is made to proceed with development of the software, it will become a user project. The project may be a simple one (1) person effort, but it will have its own identity and contain a project documentation folder. The project work time and any expenses incurred will be recorded and placed in the folder. The software will use test data made available for program testing by the user. At no time will operation data files be used for testing. When such test data is needed, file or database information will be down loaded to the computer system that will use the data. At no time will the software testing be done online with any network operating system. Testing will be done at the District facilities using the District's resources. No test data or programs will be taken from the District site without the permission of the Assistant Superintendent of ET.

 

F.

End-User Software Completion

     
   

After testing is completed, all software documentation will be brought up-to-date. Test results will be part of the documentation. Any operation manuals needed for the operation of the software will be written and tested by users who do not have any knowledge about the new software. After extensive successful testing has been completed, the user may employ the software within their operation. The manager of the user department will write an authorizing memo to permit the software to be used in his/her department. The memo will contain information as to how well the software met its objective. A copy of the memo will be placed in the documentation folder and a copy sent to the technology committee which will update the software inventory management database from this information.

     
 

G.

End-User Software Installation

     
   

Installation is placing into operation the user-test software that either replaces existing programs or is completely new. When discontinued software is replaced by a new user system, the options include the following:

     
 

1.

Phased

     
   

In a phased installation, the new system is installed in a modular fashion or phases. When one (1) phase is identified as operational and accepted, the next part of the installation can begin.

     
 

2.

Direct

     
   

Direct installation is a complete, one (1) time conversion or installation. The old system is replaced completely by the new. User staff has to be totally involved with the installation and operation of the new system software.

 

3.

Parallel Conversion

     
   

This type of user installation is most often used. It is the safest and most preferred method of installing a new software system, but the most costly. If after comparing output results and the database status of both systems the results are compatible, the user installation is considered complete. When existing software is being replaced, new software installation can occur as phased or direct installation. This kind of installation has the advantage of users not having to unlearn an old system. The end users are familiar with the unit's objective and input problems -- this is the advantage of installing a new user-programmed system.

     
 

H.

User Follow-Up Procedures

     
   

The user developer of the software will forward a copy of the project documentation folder and the software -- both the source and object coded programs -- to the technology committee. The copies will include both a hard copy of the program software and the operating program on disk. A copy of the operations manual, for user operation, will be sent with the copy of the documentation folder. The technology committee may elect to make the user developed software available throughout the District by placing it on the approved computer software list. Other District units may use the software. The approved computer software list will identify who developed and first used the software. The ET Applications member of the technology committee will retain the software folder and the programs in a user developed software file. The file will contain user-developed software found on the approved computer software list and software that is not on the list, but is in the software inventory management database.

 

I.

Other Users' Involvement

     
   

If the software will be used as part of a system employed by other users, approval will be required by the technology committee and the ET Department. To insure that there will not be a problem with any integrated operating software or database, a copy of the software folder is sent to the manager of the ET Applications Group for their study. S/He will review the information with the manager of ET Computer Operations. The programming unit's representative on the committee must confirm that the software meets the District's information technology standards. Any ET unit manager may request a duplicate copy of the software folder. With the approval of the ET Manager of Applications, the help desk will support the software.

     
 

J.

Software Maintenance

     
   

End-user developed software will require maintenance at one (1) time or another during its lifetime. The user who wrote the original programs should do the maintenance. If the person who wrote the original program is no longer available, there are options to consider.

     
 

1.

Selected Maintenance Person

     
   

A selected maintenance person in the user department who has had programming experience should perform the maintenance. The experienced person should be familiar with the program language used for writing the original software programs.

     
 

2.

ET Applications Maintenance

     
   

Contact the ET Manager of Applications for his/her assistance. Depending on the involvement of the maintenance task, the state of the user program documentation and the availability of programmers will be considered before a decision can be made. If no one is available to perform the maintenance, assistance may be offered to a user department person assigned to do the maintenance.

 

3.

Vendor-Contracted Maintenance

     
   

Contract the maintenance with a vendor. The vendor can be paid by the hour or provide an estimated project cost. When considering the vendor route, the Manager of ET Computer Operations will be contacted to assist with the procurement of a vendor maintenance contractor. After the software maintenance has been completed and tested, the user software documentation will be updated. Any user operations procedures affected by the maintenance will require updating the user operations manual. A copy of all documented changes will be sent to the Manager of ET Computer Operations. A cover memo from the person who did the program maintenance will be sent with documentation. The memo will cover why and how the maintenance was done and any other information that would assist with any maintenance needs in the future.

ET Developed Software

ET developed software is the responsibility of the ET Department. Resources of the ET Department will be allocated on a prioritized basis. At times it would not only be faster, but also cost effective to utilize District-developed software.

 

A.

New Software Development Study

     
   

A study to be conducted for the development of new software requires a formal request by approved user management and/or ET managers. The request will provide the following information:

     
 

1.

When results of the study are to be expected.

     
 

2.

What software may be available that can be purchased and used as is or modified for this application? Will the sources be proprietary or what will have to be purchased or contracted for?

     
 

3.

When is the project to be completed and in operation?

     
 

4.

The amount of money allowed for the study.

     
 

5.

What user personnel are to be contacted?

     
 

6.

What will be the estimated cost to acquire the system and have it operational?

     
 

7.

If the software will require in-house development, what resource costs and calendar time will be needed?

     
   

After the requested information is returned and studied, the ET Applications Manager will summarize the information in a memo for applications software; the ET Operations and User Services Manager will summarize the information in a memo for operating systems and related software; both will be sent to the Assistant Superintendent of ET who will decide what course of action the ET will take with the project. The reply can be a memo or E-mail. These procedures are for projects that do not have their own budget-resources are provided from existing budgets. Major system projects, with their required software development, will be provided with its own budget when annual budgets are granted. Completed software will meet the following requirements before placed in service and listed in the software inventory management database:

     
 

1.

Have all programs been tested with appropriate software test data?

     
 

2.

Has all programming documentation been completed and approved by the ET Applications Manager?

     
 

3.

All operation manuals will be completed and approved by the users.

     
 

4.

Backup and recovery procedures will be completed, documented, and tested.

     
 

5.

Any required user training is completed, within two (2) weeks, before the software will be used.

     
 

6.

Requesting management has signed that the software is now accepted for operation.

     
 

B.

Software Maintenance

     
   

Updating current software being used by ET's operations or user application operations will require maintenance. A software maintenance request will be sent to the ET and contain the following information:

     
 

1.

The completion date needed for the required program changes.

     
 

2.

What software programs will be modified?

     
 

3.

What the modifications will contain. Any I/O changes will have attached the current and new I/O layouts.

     
 

4.

The charge codes for the systems and reprogramming time spent on the changes.

     
 

5.

What operations personnel will be contacted?

     
 

6.

What will be the estimated cost to modify the application programs?

     
   

After the requested information is returned and studied, the ET Applications Manager will schedule the software maintenance. Completed software maintenance will meet the following requirements before being placed in service:

     
 

1.

Have all programs tested with user provided software test data?

     
 

2.

Have all programming documentation been completed?

     
 

3.

All operation manuals will be updated and approved by the users.

     
 

4.

Backup and recovery procedures will be completed, documented, and tested.

     
 

5.

Any required user training is completed within two (2) weeks before the changes will be used.

     
 

6.

Requesting management has signed that the software is now accepted for operation.

Contract Written Proprietary Software

Software development may be contracted for user or ET operations. Unless the District has already a blanket vendor contract for software development, competitive bids will be solicited from three (3) or more software contracting vendors. The vendors will be provided with information for contract bid proposals. At a minimum, the request for bid proposals will contain the following information:

 

A.

Who the contact person will be for more information and for submitting their bid proposal.

 

B.

Will the contract call for maintenance or new programs?

     
 

C.

What type of application will be programmed? Examples would be billing, payroll, inventory control, etc.

     
 

D.

If maintenance programming is required, in what language is the software written?

     
 

E.

What language is desired for the new software to be written? If the vendor has an alternate one it would like to propose, what would be the benefits?

     
 

F.

Will the bids requested be for contract hour or a project? For projects bids, vendors who are interested will be provided with the detail information. It is advisable that the project be well defined before requesting project bids.

     
 

G.

The due date for bids.

     
 

H.

The expected start and finish dates.

     
 

I.

What are the skill levels of the people that will be working for the vendor?

     
 

J.

What is the dollar amount of their bid?

Requesting managers will contact the ET for assistance with the District protocol for such acquisitions. A large project with an unproven vendor is not advisable. Vendor confidence is built over time. The software-programming vendor will need to have other clients to qualify as a vendor and not be the District's employee. After the bids are received they will be reviewed. Any individual or accumulative purchase in excess of $25,000 will require approval by the Board and signature of the Superintendent. With budget money available, a contract and/or purchase order will be completed. The purchase order will reference the date of the Board's approval, if required. If a contract is drawn, the District's legal representative should review it before the authorized person signs it. Vendor programming can be done in one (1) of two (2) ways -- hourly billed programming or by project contract.

 

A.

Hourly Contracting

     
   

When the programming effort is paid by the hour, enough money should be available to complete the task. It would be wise to have a contingency reserve set aside. For new program development, running out of money presents a far greater problem than a maintenance task. A partly completed program is more difficult to finish by individuals who did not start the project. The purchase order will identify that the vendor will be paid for hours worked. Purchasing requisitions will identify how the vendor will bill, either lump sum or partial payments. If something other than a monthly check is issued, the arrangement should be made known to Accounts Payable.

     
 

1.

Programming

     
   

The programming can be done in-house or at the vendor's location. The programmers will submit a weekly report of hours worked by day. Each day, the work effort and persons contacted in regards to that days work effort would be recorded. If contact is not related to that day's work effort, why is it being billed? A daily log will be kept for the detail supporting information for the weekly report. The log may be manually kept and will be the property of the District. It will be submitted weekly to the District's contact person. The vendor (for its own records) may want to make a copy of this log.

 

2.

District Contact Person

     
   

The District's software vendor's contact person should examine each week's vendor billing information before approving payment. The daily detailed information will be examined weekly. As more time passes, it becomes harder to confirm detailed information. If need be, a contact may be made with the vendor to explain any questions that may arise. This action should not wait for too long. Vendors' memories are not any better than anyone else's.

     
 

3.

Vendor Payment

     
   

Paying the vendor requires a purchase order. The purchase order may be in the form of a blanket purchase order, which allows the purchase order to be paid by Accounts Payable in installments as approved by the person approving the purchase order. The vendor will submit a bill to the District contact person for payment. The bill will be confirmed to be correct. Approval will be noted, dated, and signed and then sent to the Accounts Payable. A copy of the bill will be made for filing. The dollar amount left that was allotted for the task will be noted on the copy before it is filed. If it appears that the task will not be completed before the allocated funds run out, this should be reported to the contact person's superior.

     
 

B.

Project Contracts

     
   

Contract programming by project is for a well-defined programming project with detailed acceptance criteria. No vendor timekeeping is required. The project will have a calendar finish date.

     
 

1.

Project Tasks

     
   

The tasks within the contracted project will be plotted on a Gantt chart. The completion date of each task will be reported in writing, dated, and signed by the vendor. It will be sent to the ET contact person for the project. If it is a user project, the information will be provided to the user vendor contact person. A copy of the Gantt chart will be signed and dated for each completed week of the project. The chart will represent the work plotted for the work week, Monday through Friday, and will be provided to the designated District contact person who will receive it by the following Wednesday.

 

2.

Project Contract

     
   

A contract will be drawn for the project. It will define in detail what is to be accomplished. After the legal representative of the District approves the contract, an authorized person will sign it. A purchase order with a copy of the contract attached will be sent to Purchasing. Purchasing will send a purchase order to the vendor who will need the purchase order number for a billing reference. Input and output documents will detail the I/O information furnished to the vendor. Printed program source and object codes will be provided no later than one (1) week after it is shown as completed on the Gantt chart. Test data will be provided by the user for detail testing of all conditions that can be expected. Examples of output testing will be provided to the District contact person along with a printed copy of the actual test data used.

     
 

3.

Liquidated Damages Clause

     
   

The contract will contain a liquidated damages clause. The clause will state the liquidated damages for each workday the project is late in its completion. If the user would benefit from an early completion date, a bonus could be written into the contract for each workday it is finished early. The bonus would be added to the contract after all other things are agreed upon. This is to avoid any padding of days by the vendor.

     
 

4.

Bill Payment

     
   

An invoice/bill will be sent to the District contact person. The District will have thirty (30) days to confirm that all conditions of the contract have been met. Any work added to the project by the District will be paid by issuing a separate purchase order and following the same procedure as the original project contract. When the project is accepted as complete, Accounts Payable will be notified by sending the invoice/bill to Accounts Payable with a noted approval, date, and approving authority signature. When the vendor is paid it will be with one (1) check for the purchase orders. If there are any disputes with the vendor that cannot be resolved, the legal representative of the District will be contacted for further resolution.

Turn-Key System Contracting

System contracting is for a major system effort with its own budget. This will be part of the annual budgeting procedure of the District. System contracting today is often for end-user system applications. If the new system requires hardware acquisitions, the software will be the driving force of the project. The system with its intended software will determine what hardware is needed.

 

A.

Computer Acquisitions

     
   

Computer hardware acquisitions will follow the procedures established -- AP 7540F - Computer Hardware Acquisitions. If older desktop computers and file servers that are currently in use are used, the hardware will be more obsolete when the system and programming effort is complete.

     
 

B.

Source of Contract

     
   

A system development may be contracted for user or ET operations. Unless the District has already a blanket vendor contract for software development, competitive bids will be solicited from three (3) or more vendors. The vendors will be provided with information for contract bid proposals. At a minimum, the request for system bid proposals will contain the following information:

     
 

1.

Identify contact person for more informational needs and for submitting bid proposal.

     
 

2.

Identify kind of application system. Identify areas of the District that will be affected.

     
 

3.

Identify language the new software will be written in. If the vendor has an alternate one it would like to propose, what are the benefits?

     
 

4.

Identify if the vendor, the information systems unit, or an end-user department will do the systems maintenance.

     
 

5.

Identify if the bids requested will be for contract hour or a systems project. For systems projects bids, vendors who are interested will be provided with a detail proposed system documentation. It is advisable that the project be very well defined before requesting project bids.

 

6.

Identify current computer hardware that will be used for the proposed system. Identify new hardware recommendations.

     
 

7.

The due date for bids.

     
 

8.

The expected start and finish dates.

     
 

9.

Identify the skill levels of the people that will be working for the vendor.

     
 

10.

Identify the costs for the bid. Bids are reviewed after they are received. Any individual or accumulative purchase in excess of $25,000 will require approval by the Board and signature of the Superintendent. With budget money available, a contract and/or purchase order will be completed. The purchase order will reference the date of the Board's approval, if required. If a contract is to be drawn, the District's legal representative will review it before the authorized person signs it.

     
 

C.

End-User Systems

     
   

User management will contact the ET Department for assistance with the District protocol for systems contracting. The ET Department will work with user management. ET staff may be contacted for their assistance.

     
 

D.

More Information

     
   

Vendors will want to study any current operations and require more information before a contract can be negotiated. The time required for this process depends on the complexity and size of the system involved.

     
 

E.

Vendor Staff Needs

     
   

The vendor's employees may require a desk and telephone. There will be a need for a conference room from time-to-time. If the District requires ID tags, they should be provided to each vendor employee assigned to the systems project.

 

F.

Vendor Contracting

     
   

Vendor systems contracting can be done in one (1) of two (2) ways: billed hours or a contract sum for systems project. Each has its own benefits and disadvantages.

     
 

G.

Hourly Contracting

     
   

The programming effort is paid by the hour. To ensure that there will be enough money budgeted for the system project, the vendor should provide some sort of estimate. Let them know this is needed for the budget request, even though the billing will be done on an hourly rate. It would be wise to have a contingency reserve set aside. A systems project running out of money presents a problem that may not be resolved until more funds are found or until the next budget year.

     
 

1.

Purchase Orders

     
   

The purchase order will identify what the vendor will bill for hours worked. Purchasing requisitions will identify how the vendor will be paid, either lump sum or monthly payments. If other than a monthly check is issued, the arrangement should be made known with Accounts Payable.

     
 

2.

Vendor Record Keeping

     
   

Vendor personnel will not always be working at the District site. Their work time will be recorded wherever they are. The systems analysts, programmers, and other vendor personnel will submit a weekly report of hours worked by day. Each one (1) of the people working on the project can command different hourly pay scales. They will record their work effort and persons contacted with regard to that day's job effort. If contact is not related to that day's work effort, why is it being billed? A daily log will be kept for the detailed information of every vendor's employee whose service will be billed. This is the supporting information for the weekly billing report. The log may be manually kept and a copy provided to the District. It will be submitted weekly to the District's contact person. The vendor, for his/her own records, may want to make a copy of this log. It would be helpful if any telephone or E-mail references were made in the log.

 

3.

Vendor Work Verification

     
   

The District's project contact person will examine each week's vendor billing information. It will be compared with the employee's logs before approving payment. The daily detailed information will be examined weekly. As more time passes, it becomes harder to confirm the detailed information. Any vendor contact should be made as soon as possible to explain any questions that may arise.

     
 

4.

Paying Vendor Contractor

     
   

Paying the vendor will require a purchase order. The purchase order may be in the form of a blanket purchase order, which allows the purchase order to be paid by Accounts Payable in installments as approved by the person signing the purchase order. The vendor will submit a bill to the District contact person for payment after it is confirmed to be correct. Approval will be noted, dated, and signed and then sent to Accounts Payable. A copy of the bill will be made for filing. The dollar amount left that was allotted for the task will be noted on the copy before it is filed. If it appears that the task will not be completed before the allotted funds run out, this should be reported to the contact person's superior.

     
 

H.

Project Contracts

     
   

Contract programming by project is for a well-defined programming project with detailed acceptance criteria. No vendor timekeeping is required. The project will have a calendar finish date.

     
 

1.

Gantt Charts

     
   

The tasks within the contracted project will be plotted on a Gantt chart. The completion date of each task will be reported in writing, dated, and signed by the vendor. It will be sent to the ET contact person. If it is a user project, the information will be provided to the end-user project contact person. A copy of the Gantt chart will be signed and dated for each completed week of the project. The chart will represent the work plotted for the work week, Monday through Friday, and will be provided to the designated District contact person who will receive it by the following Wednesday.

 

2.

Project Contract

     
   

A contract will be drawn for the project. It will define in detail what is to be accomplished. After the legal representative of the District approves the contract, an authorized person will sign it. A purchase order with a copy of the contract attached will be sent to Purchasing, which then sends a purchase order to the vendor who needs the purchase order number for a billing reference. Input and output documents will detail the I/O information furnished the vendor. Printed program source and object codes will be provided no later than one (1) week after it is shown as completed on the Gantt chart. Test data will be provided by the user for detail testing of all conditions that can be expected. Examples of output testing will be provided to the District contact person along with a printed copy of the actual test data used.

     
 

3.

Liquidated Damages Clause

     
   

The contract will contain a liquidated damages clause. The clause will state the liquidated damages for each workday the project is late in its completion. If the user would benefit from an early completion date, a bonus could be written into the contract for each workday it is finished early. The bonus would be added to the contract after all other things are agreed upon. This is to avoid any padding of days by the vendor.

     
 

4.

Vendor Payment

     
   

An invoice/bill will be sent to the District project contact person. The District will have thirty (30) days in which to confirm that all conditions of the contract have been met. Any added work to the project by the District will be paid by issuing a separate purchase order and following the same procedure as the original project contract. When the project is accepted as complete, Accounts Payable will be notified by sending the invoice/bill to Accounts Payable with a noted approval, date, and approving authority signature. When the vendor is paid, it will be with one (1) check for the purchase orders. If there are any disputes with the vendor that cannot be resolved, the legal representative of the District is contacted for further resolution.

Approved Computer Software List

The approved computer software list contains software that is approved for District acquisition, including approved software operating systems and District-developed software. To discourage the use of any unapproved software, help desk support will not be provided to any unauthorized software. The list is primarily a screening device for new software acquisitions. Authorized software can still be running that is not on the approved computer software list, but will be found on the software inventory management database. The software inventory management database lists all software that is permitted to be in use and by whom. There will be proprietary software that can be on the software inventory management database (i.e., software developed by members of the District and own by the District). Users who may have a problem with this software will contact the person(s) who developed the software. There will be a list of third party add on application software the District has purchased and is on the management software database. This software has very limited use and is not supported by the help desk. If help is required, the ET Department should be contacted.

Help Desk

The help desk will support purchased software as long as it is on the software inventory management database. The software inventory management database lists all software that is permitted to be used and by whom. This database would be the source with which users can be identified for help desk assistance. Also supported will be user-written software, with or without third party purchased add on software if it is on the approved software list. One (1) or more purchased add on third party products can be combined with an in-house written program. If the help desk has any problem with this kind of software, the caller will be referred to the ET Applications staff. The ET Applications staff will be the reference source for third party purchased add on applications software. This software is not intended to be a computer program unto itself. It is intended to be used within a main program; therefore, it will not be the responsibility of the technology committee to provide any approved list for this kind of software. This kind of software purchase by the ET Applications staff will be reported to the ET Applications Manager. This information is required to update the software inventory management database.

Approved 1/17/08