View Document

IT Hardware and Software - Software Application Procedure

This is the current version of this document. You can provide feedback on this policy to the document author - refer to the Status and Details on the document's navigation bar.

Section 1 - Purpose / Objectives

(1) The purpose of this procedure is to outline the principles that govern the management of University Business and Research Software Applications:

  1. Software applications are selected, managed and utilised in a manner that achieves the objectives of the University.
  2. Removes unnecessary propagation and duplication of multiple systems performing similar functions.
Top of Page

Section 2 - Scope / Application

(2) This procedure applies to:

  1. Victoria University students
  2. Victoria University staff
Top of Page

Section 3 - Definitions

(3) Nil

Top of Page

Section 4 - Policy Statement

(4) Nil

Top of Page

Section 5 - Procedures

Roles/Responsibilities

Roles Responsibility
Business Owner
- Prepares a business case to upgrade or replace existing systems. (This includes risk impacts, compliance and Organisational impacts.)
- Determines the need to retain or replace a system including obtaining governance approval for capital funding.
- Periodically reviews the application to ensure it continues to support University compliance and business needs.
- Governs any changes to the Software Application to determine the impact to University operations. Approves the timing and installation of changes to production applications and notify affected users.
- Notifies affected users when the application is retired or significant changes are being proposed.
- Identify any training or professional development requirements for users of the system.
- Develop a business continuity plan to ensure continuity of business processes in the event of application failure.
Technical Custodian
- Maintain a Disaster Recovery Plan aligned with the business continuity plan.
- Manages the technical elements of the Software Application (database, Physical Infrastructure and operating system).
- Seeks approvals from the Business Owner to make appropriate changes to the technical environment.
- Reviews security controls at least once every 12 months. Works closely with the supplier of the product when upgrades are undertaken.
End user
- Victoria University staff and students

Procedures

Application Classification

(5) The ITS department will maintain a register of Software Applications with appropriate classifications according to the degree of importance to University operations. This classification will influence the amount of resources applied to maintain the Software Application.

(6) The table below defines the classification scheme:

Classification Criteria
Tier 1 — Mission Critical
- Software Application used widely by the University to provide a service.
- Supports University wide administrative, research, teaching and learning operations.
Tier 2 — Business Critical
- Software Application used by more than one Business Unit or Colleges.
- Used to support unique business processes that are not prevalent across the University.
Tier 3 - Departmental
- Software Application used exclusively by a single Business Unit or College to support business processes that are not available in either a Tier 1 or 2 classified system.

(7) A Software Application may still be allocated to Tier 1 - Mission Critical if it does not meet the criteria. Justifications include value to the University, strategic importance, reputational risks and external compliance.

Software Application Selection

(8) Any new Software Application must meet certain requirements.

  1. Functional and technical requirements of the University.
  2. A market comparison assessment must be undertaken to compare similar products.
  3. The application should not duplicate or have significant similarities with existing systems used by the University.
  4. A detailed business case must be developed to ascertain the total cost of ownership over 5 years including implementation costs.
  5. Where a commercially developed solution is not available in the market and business processes cannot be re-engineered, an internal software development project will be established for funding prioritisation.
  6. Where applicable, a commercially developed solution must be reviewed.
  7. A review will be undertaken by Production Support before a final decision is made.

Software Application Maintenance

(9) Any changes to the Software Application must be appropriately tested in a Test and UAT environment and approved for deployment into production by adhering to the Change Management Framework.

(10) The changes must take into consideration resource availability and the impact of the change to University operations. Where possible, both changes to the Software Application and underlying ICT infrastructure will be undertaken concurrently to minimise multiple outages.

Patch Management and Security Updates

(11) Software Application must be properly updated to reflect improvements and any changes or updates supplied by the supplier. In certain circumstances the updates improve performance and reduce system vulnerability.

(12) All security and patch updates released by the suppliers of infrastructure, database, middleware and applications will require certification from the Software Application Supplier. This is to ensure the patch or security update does not generate application issues.

(13) If the University detects a security threat from a proposed patch, a decision will be made with the Business Owner and ITS. The decision will take into consideration of business impact and the risks to the organisation. The supplier maintenance support contract is void until the patch is certified by the supplier.

Software Application Review

(14) All Software Applications should be reviewed at least once every 5 years to ensure the Software Application:

  1. Continues to support all the internal and external compliance requirements.
  2. Continues to meet the needs of the affected areas of the University.
  3. Continues to be cost effective for the University and does not present any risks that may impact operations.

(15) Software Application deemed unsuitable will undergo a Software Application assessment before a new product is purchased.

Software Application Retirement

(16) A Software Application no longer in use should be archived and removed from the University environment.

(17) A Software Application that is approaching "end of life" will need to be retired with a transition plan to either develop or select a new Software Application.

Top of Page

Section 6 - Guidelines

(18) Nil